Для последовательной передачи цифровых данных существует три формы связи:

А) симплексная связь предполагает наличие одного передатчика и одного приемника; информация передается в одном направлении, связь осуществляется через отдельную пару проводов;

Б) полудуплексная связь допускает двунаправленную передачу данных, но не одновременно; связь осуществляется по кабелю, состоящему из двух или четырех проводов;

В) дуплексная связь обеспечивает одновременную двунаправленную передачу данных, а связь осуществляется также по кабелю, состоящему из двух или четырех проводов.

Для каждой из указанных выше форм связи необходимо, чтобы приемное устройство было готово принять и идентифицировать каждый набор данных, переданный передатчиком. Существуют два способа решения этой задачи. При асинхронной передаче каждому пакету данных предшествует старт-бит , а по окончании передачи этого пакета данных следует стоп-бит . Таким образом, приемник четко определяет начало и конец сообщения. Однако из-за необходимости постоянной проверки старт- и стоп-битов скорость передачи при данном виде связи ограничена и, как правило, не превышает 1200 бит/с.

Асинхронная передача используется в условиях неуверенного приема и высокого уровня помех. Синхронная передача не требует старт- и стоп-битов, передатчик и приемник синхронизированы . Начало приема-передачи данных предварительно синхронизируется синхроимпульсом, а затем каждое слово пакета данных распознается как блок из семи или восьми бит. Синхронная передача данных может обеспечивать скорость более 1200 бит/с и наиболее часто применяется для передачи таких потоков данных, как программные файлы.

Современные интеллектуальные датчики и элементы управления наряду с традиционным интерфейсом RS-232C могут иметь также в своем составе подсистему последовательного ввода-вывода на базе интерфейса RS-485 . Программируемые логические контроллеры большинства производителей в качестве средств организации территориально-распределенных систем сбора данных и управления содержат ту или иную реализацию интерфейсов RS-422А/RS-485 .

RS-232C – широко распространенный стандартный последовательный интерфейс. Он может быть использован для синхронной передачи данных со скоростью до 20 000 бит/с на расстояние до 15 метров; на более длинные дистанции скорость передачи уменьшается. интерфейс RS-449 – это более поздний стандарт, он обладает улучшенными по сравнению с RS-232 характеристиками по скорости и расстоянию передачи; здесь достижима скорость до 10 000 бит/с на расстояние до 1 км. Уровни напряжения, соответствующие стандарту RS-232, составляют +12 В для логического “0“ и –12 В для логической “1“. интерфейс RS-232 является в настоящее время стандартным для СОМ -портов персональных компьютеров. Поскольку подавляющее большинство микропроцессоров построено на ТТЛ -структуре (транзисторно-транзисторная логика), где уровень логического нуля составляет 0 В, а логической единицы +5 В, то, очевидно, что уровни сигналов необходимо преобразовывать для согласования. Последнее достигается использованием интегральных микросхем – преобразователей уровня, таких как: МС1488 для преобразования ТТЛ-уровней в уровни RS-232 и МС1489 для преобразования уровней RS-232 в ТТЛ-уровни.

Интерфейс RS-485 (EIA–485 ) – один из наиболее распространенных стандартов физического уровня связи (канал связи + способ передачи сигнала).

Сеть, построенная на интерфейсе RS-485, представляет собой приемопередатчики, соединенные при помощи витой пары – двух скрученных проводов. В основе интерфейса RS-485 лежит принцип дифференциальной (балансной ) передачи данных. Суть его заключается в передаче одного сигнала по двум проводам. Причем по одному проводу (условно A ) идет оригинальный сигнал, а по другому (условно B ) – его инверсная копия. Таким образом, между двумя проводами витой пары всегда есть разность потенциалов (рис. А1.1).

Рисунок А1.1

Такой способ передачи обеспечивает высокую устойчивость к синфазной помехе, действующей на оба провода линии одинаково. Если сигнал передается потенциалом в одном проводе относительно общего, как в RS-232, то наводки на этот провод могут исказить сигнал относительно хорошо поглощающего наводки общего («земли»). Кроме того, на сопротивлении длинного общего провода будет падать разность потенциалов общих точек как дополнительный источник искажений. При дифференциальной передаче таких искажений не происходит, поскольку в витой паре наводка на оба провода одинакова. Таким образом, потенциал в одинаково нагруженных проводах изменяется одинаково, при этом информативная разность потенциалов остается без изменений.

Аппаратная реализация интерфейса – микросхемы приемопередатчиков с дифференциальными входами/выходами (к линии) и цифровыми портами (к портам UART-контроллера). Существуют два варианта такого интерфейса: RS-422 и RS-485 .

RS-422 – дуплексный интерфейс. Прием и передача обеспечиваются по двум отдельным парам проводов. На каждой паре проводов может быть только по одному передатчику.

RS-485 – полудуплексный магистральный аналог интерфейса RS-422. Прием и передача выполняются по одной паре проводов с разделением во времени. В сети может быть много передатчиков, так как они могут отключаться в режиме приема.

Все устройства подключаются к одной витой паре одинаково: прямые выходы (A ) к одному проводу, инверсные (B ) - к другому.

Входное сопротивление приемника со стороны линии обычно составляет 12 кОм. Поскольку мощность передатчика не беспредельна, это создает ограничение на количество приемников, подключенных к линии. Согласно стандарта RS-485, c учетом согласующих резисторов, передатчик может вести до 32 приемников. Однако, применяя микросхемы с повышенным входным сопротивлением, можно подключать к линии значительно большее количество устройств (более 100 приборов). При этом приборы подключаются к линии параллельно, а контроллер (компьютер) должен быть снабжен дополнительным устройством – преобразователем последовательного порта RS-485/ RS-232 .

Максимальная скорость связи в RS-485 может достигать 10 Мбит/сек, а максимальная длина линии связи – 1200 м. Если необходимо организовать связь на расстоянии, превышающем 1200 м, или подключить большее число устройств, нежели допускает нагрузочная способность передатчика, то применяют специальные повторители (репитеры ).

Диапазон напряжений логических “1“ и “0“ в передатчика RS-485 составляют, соответственно, +1,5...+6 В и –1,5...–6 В, а диапазон синфазного напряжения передатчика – (–1...+3 В).

Значения параметров определены таким образом, что любое устройство, входящее в состав измерительной информационной системы, сохраняет работоспособность при наличии на его клеммах, подключенных к линии связи, помехи общего вида, напряжение которой находится в диапазоне от –7 до +7 В.

Для параллельной передачи данных в измерительных информационных системах часто используется стандартный интерфейс IEEE-488 (Institute of Electrical and Electronics Engineers ), называемый также HP-IB (Hewlett-Packard Interface Bus) или GPIB (General Purpose Interface Bus – интерфейсная шина общего применения). Международная электротехническая комиссия (МЭК ) рекомендовала данный стандарт в качестве международного, по этой причине на постсоветском пространстве он носит название цифрового интерфейса МЭК.

интерфейс IEEE-488 был разработан для программируемых и непрограммируемых электронных измерительных приборов и преобразователей. Он рассчитан на асинхронный обмен информацией, ориентирован на сопряжение устройств, располагаемых относительно друг друга на расстоянии до 20 м, и обеспечивает работу в ИИС приборов различной сложности, допускает прямой обмен информацией между ними, дистанционное и местное управление приборами. Описываемый интерфейс имеет магистральную структуру (рис. А1.2).

Магистраль интерфейса состоит из 24 сигнальных линий, восемь из которых – линии заземления, а остальные линии разбиты на три группы. Первая группа, состоящая из восьми двунаправленных сигнальных линий, является шиной данных . Она предназначена для передачи данных и команд между различными приборами, присоединенными к интерфейсу. Другая группа из пяти сигнальных линий – шина общего управления , по ней передаются сигналы управления и состояния. Последняя группа из трех линий используется для управления передачей данных (шина квитирования ).

Приборы, подсоединенные к интерфейсу, могут работать как приемники либо источники сообщений. В каждый момент времени только одно устройство может быть источником информации, тогда как приемниками сообщений могут работать одновременно несколько устройств. Одно из устройств на магистрали является контроллером интерфейса.

Общее количество приемников и источников информации в IEEE-488 не должно превышать 31 при однобайтовой адресации, а число параллельно подключаемых приборов – 15 (включая управляющий контроллер).

В стандарте IEEE-488 высокому уровню сигнала в линии соответствует значение напряжения, равное или больше 2 В, а низкому уровню – значение, равное или меньше 0,8 В.

Приложение А2

Руководство пользователя

1. Введение
1.1. Область применения………………………………………………………………. 3
1.2. Краткое описание возможностей………………………………………………..... 3
1.3. Уровень подготовки пользователя………………………………………………... 3

2. Назначение и условия применения АСУ ТП «ВП»……………………………………. 4

3. Решение системы АСУ ТП «ВП» ………………………………………………………. 5

4. Запуск системы…………………………………………………………………..……… 6

1. Введение.

1.1. Область применения

Требования настоящего документа применяются при:

· предварительных комплексных испытаниях;

· опытной эксплуатации;

· приемочных испытаниях;

· промышленной эксплуатации.

1.2. Краткое описание возможностей

Программный продукт «Весовой поток» предназначен для проведения аналитической работы, автоматизирования и оптимизирования процессов документооборота и межведомственной логистики различных отделов предприятия. Система также обеспечивает возможность оперативного контроля и корректировки работы технических процессов на предприятиях, связанных с использованием весового оборудования на элеваторах, нефе - и газохранилищах, железнодорожных товарных станциях и прочих промышленных объектах.

Программное обеспечение и аппаратно - программный комплекс АСУ ТП «Весовой Поток» имеют модульную структуру.

При работе с отчетностью зачастую используются: программное обеспечение «OLE 1C» с функцией online-синхронизации (позволяет инициацию взвешивания из системы бухучета) и программное обеспечение "SAP RFC" с функцией online-синхронизации (формирует взвешивания в систему бухучета), которые предоставляет следующее:

· проверка возможности проезда ТС на территорию предприятия;

· создания документа в «1С» на факт взвешивания ТС на предприятии;

· возвращение данных об остатке денежных средств на счете контрагента в системе «1С».;

· поиск документа по номеру транспортного средства и возвращение номера документа. Если документов несколько, то порядок вывода определяется разработчиком, функция всегда возвращает один документ;

возвращение информации о документе; возвращение элемента справочника; внесение в документ веса товара; выдача списка документов на дату.

1.3. Уровень подготовки пользователя

Пользователь должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP, XP-7), навык работы с MS Office, а также обладать следующими знаниями:

· знать соответствующую предметную область;

· знать принцип действия автомобильных весов;

· уметь навыки подключения периферийных устройств.

2. Назначение и условия применения АСУ ТП «ВП».

Диспетчеризация производства, транспорта, автодорог, успешно применимая во многих областях деятельности, начиная от коммерческих дорог и переправ, автоматических паркингов, заканчивая автоматизацией работы газодобывающей отрасли.

Программно-аппаратный комплекс АСУ ТП «Весовой Поток» предназначен для автоматизации промышленных весовых систем (авто весов, вагонных весов и т. д) и документооборота, конфигурации с учетом отраслевой принадлежности предприятия и особенностей учета.

Все системы обладают возможностью легкой интеграции в другие системы, например, бухгалтерские системы учеты (1С, «Турбобухгалтер» , SAP, ВААNи т. д.) Системы также оснащены опцией дистанционного/удаленного контроля. Все наши проекты включают в себя самые прогрессивные и уникальные программно-аппаратные решения с использование RFID-технологий (радиочастотная идентификация), активные и пассивные.

АСУ ТП «Весовой Поток» включает в себя установку систем безопасности и видеонаблюдения, СКУД на промышленных объектах различного назначения и любого уровня сложности, с интеграцией их в технологические процессы предприятия и документооборот, а так же использование современных RFID-технологий, (активные/пассивные).

3. Решение системы АСУ ТП «ВП»

Типовые варианты комплектации систем АСУ ТП «Весовой поток»

Варианты идентификации событий. «Событие» - важная составляющая часть, позволяющая организовать работу системы без человека, что исключает «риски», связанные с деятельностью не добропорядочных сотрудников.

1. Интеллектуальная видео аналитика - система распознавания транспортных средств, номеров ТС/вагоны/контейнеры;
2. RFID - радиочастотная идентификация (активная или пассивная);
3. Различные датчики - индукционные, тепловые датчики;
4. Ввод данных о событие человеком

Исполнительные устройства: - любые цифровые устройства, в конструкции которых заложены порты подключения (COM USB, RS 232/ 485, сеть IP и пр.);
- любые аналоговые устройства с функциями включения/выключения (светофоры / двигатели/лампочки/шлагбаумы/заслонки и пр.);
- цифровые датчики / анализаторы электронные и с сухими контактами.

Программные компоненты АСУ ТП «ВП»
У нас существует несколько модулей АСУ ТП ВП - кратко их функционал описан в спецификации, более детально в руководстве. Ниже приведены основные программные компоненты Системы АСУ ТП «Весовой поток». Каждый модуль несет определенные основные функции:

1. Сервер - ПО АСУ ТП "Весовой поток"
Центральный север весов (WEB, SQL, УРБД)

2. Весовая программ - АСУ ТП "Весовой Поток" Модуль авто весовая/жд весовая
3. Использование различных устройств - АСУ ТП "Весовой Поток" Модуль контролер +
в системе

4. Корректировки, видимые/невидимые - АСУ ТП «ВП» Модуль Лаборатория

5. Дополнительное рабочее место - АСУ ТП «ВП» Модуль дополнительное рабочее место
(возможность подключения удаленно либо по сети к АРМ ПВК)

4. Запуск системы

https://pandia.ru/text/80/223/images/image002_125.jpg" width="672 height=361" height="361">

Рис. 2. Интерфейс АСУ ТП «Весовой поток»

Интерфейс состоит из следующих элементов:

1.Меню навигации. Служит для настройки и управления системой.

2.Кнопки переключения между весами. Служат для переключения отображения состояния разных весов и индикации активных в данный момент весов, в случае если к системе подключено более одних весов.

3.Меню оператора. Служит для управления взвешиванием, документами и системой контроля доступа. Переключает внешний вид и функции панели оператора.

4.Панель оператора. Служит для управления взвешиванием, документами и системой контроля доступа. Внешний вид и функции зависят от выбранной в данный момент закладки в меню оператора (поз 3). При запуске системы отображается панель управления весами (как на рис. 2).

5.Календарь. Служит для выбора результатов взвешивания, отображаемых на панели протокола взвешиваний (поз. 7) по дате и отображения текущей даты.

6.Кнопка «Записать документ». Служит для создания нового документа.

7.Панель протокола взвешиваний. Служит для отображения результатов взвешивания за определенную дату, выбранную в календаре (поз. 5).

8.Панель видео. Отображает видео, транслируемое с камер видеонаблюдения.

Меню навигации (рис.3) располагается в верхнем левом углу монитора и состоит из следующих разделов: «Файл», «Конфигурация», «Модули», «Окна», «О программе».

https://pandia.ru/text/80/223/images/image004_81.jpg" align="left" width="120" height="76">

Рис. 4. Меню «Файл».

Меню «Конфигурация» (рис. 5)

Предоставляет доступ к служебным параметрам системы

«Дизайнер печатных форм» - служит для регистрации макетов документов

«Настройки системы» - служит для конфигурирования системы в соответствии с необходимыми параметрами

https://pandia.ru/text/80/223/images/image006_48.jpg" align="left" width="171" height="92 src=">

Рис. 6. Меню «Модули».

Меню «Окна» (рис. 7)

Отображает список открытых окон и позволяет переключаться между ними

https://pandia.ru/text/80/223/images/image008_40.jpg" width="675 height=356" height="356">

Промышленные сети передачи данных - это один из основных элементов современных АСУ ТП. Появление промышленных коммуникационных протоколов положило начало внедрению территориально распределенных систем управления, способных охватить множество технологических установок, объединить целые цеха, а иногда и заводы. Сегодня сфера промышленных коммуникаций развиваются семимильными шагами: известно более 50 стандартов коммуникационных сетей, специально адаптированных для промышленного применения, каждый год появляются новые прогрессивные технологии передачи данных. Это не удивительно, ведь именно коммуникационные сети в большей степени определяют качество, надежность и функциональные возможности АСУ ТП в целом.

Сети передачи данных, используемые в АСУ ТП, можно условно разделить на два класса:

1. Полевые шины (Field Buses);
2. Сети верхнего уровня (операторского уровня, Terminal Buses).

1. Полевые шины

Главной функцией полевой шины является обеспечение сетевого взаимодействия между контроллерами и удаленной периферией (например, узлами ввода/вывода). Помимо этого, к полевой шине могут подключаться различные контрольно-измерительные приборы и исполнительные устройства (Field Devices), снабженные соответствующими сетевыми интерфейсами. Такие устройства часто называют интеллектуальными (Intelligent Field Devices), так как они поддерживают высокоуровневые протоколы сетевого обмена.

Как уже было отмечено, существует множество стандартов полевых шин, наиболее распространенными из которых являются:

1. Profibus DP;
2. Profibus PA;
3. Foundation Fieldbus;
4. Modbus RTU;
5. HART;
6. DeviceNet.

Несмотря на нюансы реализации каждого из стандартов (скорость передачи данных, формат кадра, физическая среда), у них есть одна общая черта - используемый алгоритм сетевого обмена данными, основанный на классическом принципе Master-Slave или его небольших модификациях. Современные полевые шины удовлетворяют строгим техническим требованиям, благодаря чему становится возможной их эксплуатация в тяжелых промышленных условиях. К этим требованиям относятся:

1. Детерминированность. Под этим подразумевается, что передача сообщения из одного узла сети в другой занимает строго фиксированный отрезок времени. Офисные сети, построенные по технологии Ethernet, - это отличный пример недетерминированной сети. Сам алгоритм доступа к разделяемой среде по методу CSMA/CD не определяет время, за которое кадр из одного узла сети будет передан другому, и, строго говоря, нет никаких гарантий, что кадр вообще дойдет до адресата. Для промышленных сетей это недопустимо. Время передачи сообщения должно быть ограничено и в общем случае, с учетом количества узлов, скорости передачи данных и длины сообщений, может быть заранее рассчитано.

2. Поддержка больших расстояний. Это существенное требование, ведь расстояние между объектами управления может порой достигать нескольких километров. Применяемый протокол должен быть ориентирован на использование в сетях большой протяженности.

3. Защита от электромагнитных наводок. Длинные линии в особенности подвержены пагубному влиянию электромагнитных помех, излучаемых различными электрическими агрегатами. Сильные помехи в линии могут исказить передаваемые данные до неузнаваемости. Для защиты от таких помех применяют специальные экранированные кабели, а также оптоволокно, которое, в силу световой природы информационного сигнала, вообще нечувствительно к электромагнитным наводкам. Кроме этого, в промышленных сетях должны использоваться специальные методы цифрового кодирования данных, препятствующие их искажению в процессе передачи или, по крайней мере, позволяющие эффективно детектировать искаженные данные принимающим узлом.

4. Упрочненная механическая конструкция кабелей и соединителей. Здесь тоже нет ничего удивительного, если представить, в каких условиях зачастую приходится прокладывать коммуникационные линии. Кабели и соединители должны быть прочными, долговечными и приспособленными для использования в самых тяжелых условиях (в том числе в агрессивных атмосферах, в условиях повышенного уровня вибраций, влажности).

По виду физической среды передачи данных полевые шины делятся на два типа:

1. Полевые шины, построенные на базе оптоволоконного кабеля. Преимущества использования оптоволокна очевидны: возможность построения протяженных коммуникационных линий (протяженностью до 10 км и более); большая полоса пропускания; нечувствительность к электромагнитным помехам; возможность прокладки во взрывоопасных зонах. Недостатки: относительно высокая стоимость кабеля; сложность физического подключения и соединения кабелей. Эти работы должны выполняться квалифицированными специалистами.
2. Полевые шины, построенные на базе медного кабеля. Как правило, это двухпроводной кабель типа “витая пара” со специальной изоляцией и экранированием. Преимущества: приемлемая цена; легкость прокладки и выполнения физических соединений. Недостатки: подвержен влиянию электромагнитных наводок; ограниченная протяженность кабельных линий; меньшая по сравнению с оптоволокном полоса пропускания.

Примером модуля, обеспечивающего подключение контроллера Simatic S7-300 к сети Profibus DP c оптоволоконным кабелем, является коммуникационный процессор CP 342-5 FO. Для подключения S7-300 к сети Profibus DP c медным кабелем можно использовать модуль CP 342-5.

2. Сети верхнего уровня

Сети верхнего уровня АСУ ТП служат для передачи данных между контроллерами, серверами и операторскими рабочими станциями. Иногда в состав таких сетей входят дополнительные узлы: центральный сервер архива, сервер промышленных приложений, инженерная станция и т.д. Но это уже опции.

Какие сети используются на верхнем уровне АСУ ТП? В отличие от стандартов полевых шин, здесь особого разнообразия нет. Фактически, большинство сетей верхнего уровня, применяемых в современных АСУ ТП, базируется на стандарте Ethernet (IEEE 802.3) или на его более быстрых вариантах Fast Ethernet и Gigabit Ethernet. При этом, как правило, используется коммуникационный протокол TCP/IP. В этом плане сети операторского уровня очень похожи на обычные ЛВС, применяемые в офисных приложениях. Широкое промышленное применение сетей Ethernet обусловлено следующими очевидными моментами:

1) Промышленные сети верхнего уровня объединяют множество операторских станций и серверов, которые в большинстве случаев представляют собой персональные компьютеры. Стандарт Ethernet отлично подходит для организации подобных ЛВС; для этого необходимо снабдить каждый компьютер лишь сетевым адаптером (NIC, network interface card). Многие современные контроллеры имеют коммуникационные модули для подключения к сетям Ethernet (например, коммуникационный процессор CP 343-1 позволяет подключить S7-300 к сети Industrial Ethernet).

2) На рынке существует большой выбор недорого коммуникационного оборудования для сетей Ethernet, в том числе специально адаптированного для промышленного применения.

3) Сети Ethernet обладают большой скоростью передачи данных. Например, стандарт Gigabit Ethernet позволяет передавать данные со скоростью до 1 Gb в секунду при использовании витой пары категории 5. Как будет понятно дальше, большая пропускная способность сети становится чрезвычайно важным моментом для промышленных приложений.

4) Использование на верхнем уровне АСУ ТП сети Ethernet обеспечивает возможность простой состыковки сети АСУ ТП с локальной сетью завода (или предприятия). Как правило, существующая ЛВС завода базируется на стандарте Ethernet. Использование единого сетевого стандарта позволяет упростить интеграцию АСУ ТП в общую сеть предприятия.

Однако у промышленных сетей верхнего уровня АСУ ТП есть своя специфика, обусловленная условиями промышленного применения. Типичными требованиями, предъявляемыми к таким сетям, являются:

1. Большая пропускная способность и скорость передачи данных. Объем трафика напрямую зависит от многих факторов: количества архивируемых и визуализируемых технологических параметров, количества серверов и операторских станций, используемых прикладных приложений и т.д. В отличие от полевых сетей жесткого требования детерминированности здесь нет: строго говоря, неважно, сколько времени займет передача сообщения от одного узла к другому - 100 мс или 700 мс (естественно, это не важно, пока находится в разумных пределах). Главное, чтобы сеть в целом могла справляться с общим объемом трафика за определенное время. Наиболее интенсивный трафик идет по участкам сети, соединяющим серверы и операторские станции (клиенты). Это связано с тем, что на операторской станции технологическая информация обновляется в среднем раз в секунду, причем передаваемых технологических параметров может быть несколько тысяч. Но и тут нет жестких временных ограничений: оператор не заметит, если информация будет обновляться, скажем, каждые полторы секунды вместо положенной одной. В то же время, если контроллер (с циклом сканирования в 100 мс) столкнется с 500-милисекундной задержкой поступления новых данных от датчика, это может привести к некорректной отработке алгоритмов управления.

2. Отказоустойчивость. Достигается, как правило, путем резервирования коммуникационного оборудования и линий связи по схеме 2*N так, что в случае выхода из строя коммутатора или обрыва канала, система управления способна в кратчайшие сроки (не более 1-3 с) локализовать место отказа, выполнить автоматическую перестройку топологии и перенаправить трафик на резервные маршруты.

3. Соответствие сетевого оборудования промышленным условиям эксплуатации. Под этим подразумеваются такие немаловажные технические меры, как: - защита сетевого оборудования от пыли и влаги; - расширенный температурный диапазон эксплуатации; - увеличенный цикл жизни; - возможность удобного монтажа на DIN-рейку; - низковольтное питание с возможностью резервирования; - прочные и износостойкие разъемы и коннекторы.

Функции промышленного сетевого оборудования практически не отличаются от офисных аналогов, однако, ввиду специального исполнения, стоит оно несколько дороже. На рисунке 1 приведены для примера фотографии сетевых коммутаторов промышленного исполнения, обеспечивающих поддержку резервированной топологии сети.

Рис.1 Промышленные коммутаторы SCALANCE X200 производства Siemens (слева) и LM8TX от Phoenix Contact (справа): монтаж на DIN-рейку

Говоря о промышленных сетях, построенных на базе технологии Ethernet, часто используют термин Industrial Ethernet, намекая тем самым на их промышленное предназначение. Сейчас ведутся обширные дискуссии о выделении Industrial Ethernet в отдельный промышленный стандарт, однако на данный момент Industrial Ethernet - это лишь перечень технических рекомендации по организации сетей в производственных условиях, и является, строго говоря, неформализованным дополнением к спецификации физического уровня стандарта Ethernet.

Есть и другая точка зрения на то, что такое Industrial Ethernet. Дело в том, что в последнее время разработано множество коммуникационных протоколов, базирующихся на стандарте Ethernet и оптимизированных для передачи критичных ко времени данных. Такие протоколы условно называют протоколами реального времени, имея в виду, что с их помощью можно организовать обмен данными между распределенными приложениями, которые критичны ко времени выполнения и требуют четкой временной синхронизации. Конечная цель – добиться относительной детерминированности при передаче данных. В качестве примера Industrial Ethernet можно привести:

• Profinet;
• EtherCAT;
• Ethernet Powerlink;
• Ether/IP.

Эти протоколы в различной степени модифицируют стандартный протокол TCP/IP, добавляя в него новые алгоритмы сетевого обмена, диагностические функции, методы самокорректировки и функции синхронизации. При этом канальный и физический уровни Ethernet остаются неизменными. Это позволяет использовать новые протоколы передачи данных в существующих сетях Ethernet с использованием стандартного коммуникационного оборудования.

Протоколы связи в АСУ ТП

В современных системах автоматизации, в результате постоянной модернизации производства, все чаще встречаются задачи построения распределенных промышленных сетей с использованием гибких протоколов передачи данных.

Прошли те времена, когда где-нибудь в аппаратной ставился огромный шкаф с оборудованием, к нему тянулись километры толстых пучков кабелей, ведущих к датчикам и исполнительным механизмам. Сегодня, в подавляющем большинстве случаев, на много выгоднее установить несколько локальных контроллеров, объединенных в единую сеть, тем самым сэкономив на установке, тестировании, вводе в эксплуатацию и техническом обслуживании по сравнению с централизованной системой.

Для организации промышленных сетей используется множество интерфейсов и протоколов передачи данных, например Modbus, Ethernet, CAN, HART, PROFIBUS и пр. Они необходимы для передачи данных между датчиками, контроллерами и исполнительными механизмами (ИМ); калибровки датчиков; питания датчиков и ИМ; связи нижнего и верхнего уровней АСУ ТП. Протоколы разрабатываются с учетом особенностей производства и технических систем, обеспечивая надежное соединение и высокую точность передачи данных между различными устройствами. Наряду с надежностью работы в жестких условиях все более важными требованиями в системах АСУ ТП становятся функциональные возможности, гибкость в построении, простота интеграции и обслуживания, соответствие промышленным стандартам.

Наиболее распространённой системой классификации сетевых протоколов является теоретическая модель OSI (базовая эталонная модель взаимодействия открытых систем, англ. Open Systems Interconnection Basic Reference Model ). Спецификация этой модели была окончательно принята в 1984 году Международной Организацией по Стандартизации (ISO). В соответствии с моделью OSI протоколы делятся на 7 уровней, расположенных друг над другом, по своему назначению — от физического (формирование и распознавание электрических или других сигналов) до прикладного (API для передачи информации приложениями). Взаимодействие между уровнями может осуществляться, как вертикально, так и горизонтально (Рис. 1). В горизонтальном взаимодействии программам требуется общий протокол для обмена данными. В вертикальном - посредством интерфейсов.

Рис. 1. Теоретическая модель OSI.

Прикладной уровень

Прикладной уровень - уровень приложений (англ. Application layer ). Обеспечивает взаимодействие сети и приложений пользователя, выходящих за рамки модели OSI. На этом уровне используются следующие протоколы: HTTP, gopher, Telnet, DNS, SMTP, SNMP, CMIP, FTP, TFTP, SSH, IRC, AIM, NFS, NNTP, NTP, SNTP, XMPP, FTAM, APPC, X.400, X.500, AFP, LDAP, SIP, ITMS, Modbus TCP, BACnet IP, IMAP, POP3, SMB, MFTP, BitTorrent, eD2k, PROFIBUS.

Представительский уровень

Представительский уровень (англ. Presentation layer ) - уровень представления данных. На этом уровне может осуществляться преобразование протоколов и сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные преобразует в формат, понятный приложениям. К этому уровню традиционно относят следующие протоколы: HTTP, ASN.1, XML-RPC, TDI, XDR, SNMP, FTP, Telnet, SMTP, NCP, AFP.

Сеансовый уровень

Сеансовый уровень (англ. Session layer ) управляет созданием/завершением сеанса связи, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия. Используемые протоколы: ASP, ADSP, DLC, Named Pipes, NBT, NetBIOS, NWLink, Printer Access Protocol, Zone Information Protocol, SSL, TLS, SOCKS.

Транспортный уровень

Транспортный уровень (англ. Transport layer ) организует доставку данных без ошибок, потерь и дублирования в той последовательности, как они были переданы. Разделяет данные на фрагменты равной величины, объединяя короткие и разбивая длинные (размер фрагмента зависит от используемого протокола). Используемые протоколы: TCP, UDP, NetBEUI, AEP, ATP, IL, NBP, RTMP, SMB, SPX, SCTP, DCCP, RTP, TFTP.

Сетевой уровень

Сетевой уровень (англ. Network layer ) определяет пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, за определение кратчайших маршрутов, коммутацию и маршрутизацию, за отслеживание неполадок и заторов в сети. Используемые протоколы: IP, IPv6, ICMP, IGMP, IPX, NWLink, NetBEUI, DDP, IPSec, ARP, RARP, DHCP, BootP, SKIP, RIP.

Канальный уровень

Канальный уровень (англ. Data link layer ) предназначен для обеспечения взаимодействия сетей на физическом уровне. Полученные с физического уровня данные проверяет на ошибки, если нужно исправляет, упаковывает во фреймы, проверяет на целостность, и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня — MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. Используемые протоколы: STP, ARCnet, ATM, DTM, SLIP, SMDS, Ethernet, FDDI, Frame Relay, LocalTalk, Token ring, StarLan, L2F, L2TP, PPTP, PPP, PPPoE, PROFIBUS.

Физический уровень

Физический уровень (англ. Physical layer ) предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Используемые протоколы: RS-232, RS-422, RS-423, RS-449, RS-485, ITU-T, xDSL, ISDN, T1, E1, 10BASE-T, 10BASE2, 10BASE5, 100BASE-T, 1000BASE-T, 1000BASE-TX, 1000BASE-SX.

Как вы могли заметить, многие протоколы упоминаются сразу на нескольких уровнях. Это говорит о недоработанности и отдаленности теоретической модели от реальных сетевых протоколов, поэтому привязка некоторых из них к уровням OSI является условной.

В мировой практике, среди сетей общего применения, наиболее широко распространен протокол HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста» ). Относится к прикладному и представительскому уровням теоретической модели OSI. HTTP базируется на технологии «клиент-сервер», то есть существует потребитель (клиент), который инициирует соединение и посылает запрос, и поставщик (сервер), который ожидает соединения для получения запроса, производит необходимые действия и возвращает обратно сообщение с результатом. Основным типом НТТР-клиента является браузер, например Mozilla Firefox, Opera или Microsoft Internet Explorer. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.

Рис. 2. Технология клиент сервер.

На базе HTTP разработаны расширенные протоколы: HTTPS (англ. Hypertext Transfer Protocol Secure ), поддерживающий шифрование, и HTTP-NG (англ. HTTP Next Generation ), увеличивающий быстродействие Web и расширяющий возможности промышленного применения.

Положительные стороны: простота разработки клиентских приложений, возможность расширения протокола путем добавления собственных заголовков, распространенность протокола.

Отрицательные стороны: большой размер сообщений, по сравнению с двоичными данными, отсутствие навигации в ресурсах сервера, невозможность использования распределенных вычислений.

создание удаленных диспетчерских пунктов, Web-приложения для SCADA систем, программное обеспечение промышленных контроллеров, организация видеонаблюдения.

На сегодняшний день протокол HTTP и его модификации поддерживаются оборудованием и программным обеспечением большинства производителей. Рассмотрим некоторые из них.

В оборудовании компании Korenix серий JetNet, JetRock, JetPort, JetI/O, JetBox (построение сетей на базе промышленного Ethernet), JetWave (беспроводные решения) протоколы семейства HTTP используются для организации доступа, конфигурирования и управления устройствами.

Компания ICPDAS для работы с протоколом HTTP предлагает следующее оборудование и программное обеспечение. Контроллеры серии ХРАК, WinPAC, WinCon, LinPAC, ViewPAC работают под управлением операционных систем Windows и Linux, с встроенным HTTP-сервером. Программные пакеты InduSoft (SCADA), ISaGRAF, Web HMI, VXCOMM, MiniOS7 Studio, также используют HTTP-сервер для связи и взаимодействия с устройствами.

Управляемые коммутаторы, встраиваемые компьютеры, оборудование промышленных беспроводных сетей, производства компании Моха, не обходятся без использования протоколов семейства HTTP.

Рис. 3. Совместимость протоколов семейства Modbus.

Для организации взаимодействия между элементами автоматизации в промышленных сетях передачи данных широко применяется коммуникационный протокол Modbus. Существуют три основные реализации протокола Modbus, две для передачи данных по последовательным линиям связи, как медным EIA/TIA-232-E (RS-232), EIA-422, EIA/TIA-485-A (RS-485), так и оптическим и радио: Modbus RTU и Modbus ASCII, и для передачи данных по сетям Ethernet поверх TCP/IP: Modbus TCP.

Различие между протоколами Modbus ASCII и Modbus RTU заключается в способе кодирования символов. В режиме ASCII данные кодируются при помощи таблицы ASCII, где каждому символу соответствует два байта данных. В режиме RTU данные передаются в виде 8-ми разрядных двоичных символов, что обеспечивает более высокую скорость передачи данных. ASCII допускает задержку до 1 секунды в отличии от RTU, где сообщения должны быть непрерывны. Также режим ASCII имеет упрощенную систему декодирования и управления данными.

Протоколы семейства Modbus (Modbus ASCII, Modbus RTU и Modbus TCP/IP) используют один прикладной протокол, что позволяет обеспечить их совместимость. Максимальное количество сетевых узлов в сети Modbus - 31. Протяженность линий связи и скорость передачи данных зависит от физической реализации интерфейса. Элементы сети Modbus взаимодействуют, используя клиент-серверную модель, основанную на транзакциях, состоящих из запроса и ответа.

Обычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов — «подчиненных» (slaves) устройств. Главное устройство инициирует транзакции (передаёт запросы). Подчиненные устройства передают запрашиваемые главным устройством данные, или производят запрашиваемые действия. Главный может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство формирует сообщение и возвращает его в ответ на запрос, адресованный именно ему.

Области промышленного применения:

Простота применения протоколов семейства Modbus в промышленности обусловило его широкое распространение. На сегодняшний день, оборудование практически всех производителей поддерживает протоколы Modbus.

Компания ICPDAS предлагает широкий спектр коммуникационного оборудования для организации сетей на базе протоколов семейства Modbus: серия I-7000 (шлюзы DeviceNet, серверы Modbus, адресуемые коммуникационные контроллеры); программируемые контроллеры серий ХРАК, WinPAC, WinCon, LinPAC, ViewPAC.

Операторские панели производства компании Weintek, частотные преобразователи Control Techniques для связи с контроллерами также используют протокол Modbus.

Традиционно протоколы семейства Modbus поддерживаются OPC серверами SCADA систем (Clear SCADA, компании Control Microsystems, InTouch Wonderware, TRACE MODE)для связи с элементами управления (контроллерами, ЧРП, регуляторами и др.).

Рис. 4. Сеть Profibus.

В Европе широкое распространение получила открытая промышленная сеть PROFIBUS (PROcess FIeld BUS). Изначально, прототип этой сети был разработан компанией Siemens для своих промышленных контроллеров.

PROFIBUS объединяет технологические и функциональные особенности последовательной связи полевого уровня. Она позволяет объединять разрозненные устройства автоматизации в единую систему на уровне датчиков и приводов. Сеть PROFIBUS основывается на нескольких стандартах и протоколах, использует обмен данными между ведущим и ведомыми устройствами (протоколы DP и PA) или между несколькими ведущими устройствами (протоколы FDL и FMS).

Сеть PROFIBUS можно ассоциировать с тремя уровнями модели OSI: физический, канальный и уровень приложений.

Единым протоколом для доступа к шине для всех версий PROFIBUS является реализованный на втором уровне модели OSI протокол PROFIBUS-FDL. Данный протокол использует процедуру доступа с помощью маркера (token). Так же, как и сети на базе протоколов Modbus, сеть PROFIBUS состоит из ведущих (master) и ведомых (slave) устройств. Ведущее устройство может управлять шиной. Когда у ведущего (master) устройства есть право доступа к шине, оно может передавать сообщения без удаленного запроса. Ведомые устройства - это обычные периферийные устройства, не имеют прав доступа к шине, то есть они могут только подтверждать принимаемые сообщения или передавать сообщения ведущему устройству по его запросу. В минимальной конфигурации сеть может состоять либо из двух ведущих, либо из одного ведущего и одного ведомого устройства.

Одни и те же каналы связи сети PROFIBUS допускают одновременное использование нескольких протоколов передачи данных. Рассмотрим каждый из них.

PROFIBUS DP (Decentralized Peripheral - Распределенная периферия) — протокол, ориентированный на обеспечение скоростного обмена данными между ведущими DP-устройствами и устройствами распределённого ввода-вывода. Протокол характеризуется минимальным временем реакции и высокой стойкостью к воздействию внешних электромагнитных полей. Оптимизирован для высокоскоростных и недорогих систем.

PROFIBUS PA (Process Automation - Автоматизация процесса) — протокол обмена данными с оборудованием полевого уровня, расположенным в обычных или взрывоопасных зонах. Протокол позволяет подключать датчики и приводы на одну линейную шину или кольцевую шину.

PROFIBUS FMS (Fieldbus Message Specification - Спецификация сообщений полевого уровня) - универсальный протокол для решения задач по обмену данными между интеллектуальными сетевыми устройствами (контроллерами, компьютерами/программаторами, системами человеко-машинного интерфейса) на полевом уровне. Некоторый аналог промышленного Ethernet, обычно используется для высокоскоростной связи между контроллерами и компьютерами верхнего уровня.

Все протоколы используют одинаковые технологии передачи данных и общий метод доступа к шине, поэтому они могут функционировать на одной шине.

Положительные стороны: открытость, независимость от поставщика, распространенность.

Области промышленного применения: организация связи датчиков и исполнительных механизмов с контроллером, связь контроллеров и управляющих компьютеров, связь с датчиками, контроллерами и корпоративными сетями, в SCADA системах.

Основную массу оборудования использующего протокол PROFIBUS составляет оборудование компании SIEMENS. Но в последнее время этот протокол получил применение у большинства производителей. Во многом это обусловлено распространенностью систем управления на базе контроллеров Siemens.

Рис. 5. Сеть Profibus на базе оборудования ICP DAS.

Компания ICPDAS для реализации проектов на базе PROFIBUS предлагает ряд ведомых устройств: шлюзы PROFIBUS/Modbus серии GW, преобразователи PROFIBUS в RS-232/485/422 серии I-7000, модули и каркасы удаленного ввода/вывода PROFIBUS серии PROFI-8000. В настоящие время инженерами компании ICPDAS ведутся интенсивные разработки в области создания PROFIBUS ведущего устройства.

Скачать документ

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР

ИНТЕРФЕЙС
ДЛЯ АВТОМАТИЗИРОВАННЫХ
СИСТЕМ УПРАВЛЕНИЯ
РАССРЕДОТОЧЕННЫМИ ОБЪЕКТАМИ

ОБЩИЕ ТРЕБОВАНИЯ

К.И. Диденко, канд. техн. наук; Ю.В. Розен; К.Г. Карнаух; М.Д. Гафанович, канд. техн. наук; К.М. Усенко; Ж.А. Гусева; Л.С. Ланина; С.Н. Кийко

ВНЕСЕН Министерством приборостроения, средств автоматизации и систем управления

Член Коллегии Н.И. Гореликов

УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 30 марта 1984 г. № 1145

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР

до 01.01.90

Несоблюдение стандарта преследуется по закону

Настоящий стандарт распространяется на интерфейс, регламентирующий общие правила организации взаимодействия локальных подсистем в составе автоматизированных систем управления рассредоточенными объектами, использующими магистральную структуру связи (в дальнейшем - интерфейс).

В части физической реализации стандарт распространяется на интерфейсы агрегатных средств, использующих для передачи сообщений электрические сигналы.

1. НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

1.1. Интерфейс предназначен для организации связи и обмена информацией между локальными подсистемами в составе автоматизированных систем управления технологическими процессами, машинами и оборудованием в различных отраслях промышленности и непромышленной сфере.

сопряжение с оперативно-технологическим персоналом;

сопряжение с управляющими вычислительными комплексами верхнего яруса в иерархических системах.

2. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ

2.1. Интерфейс реализует бит-последовательный синхронный способ передачи цифровых сигналов данных по двухпроводному магистральному каналу.

2.2. Суммарное затухание сигнала между выходом передающей и входом принимающей станции должно быть не более 24 дБ, при этом затухание, вносимое линией связи (магистральным каналом и отводами), должно быть не более 18 дБ, вносимое каждым устройством связи с линией, - не более 0,1 дБ.

Примечание. При использовании кабеля типа РК-75-4-12 максимальная длина линии связи (включая длину отводов) - 3 км.

(Новая редакция, Изм. № 1).

2.5. Для представления сигналов должна применяться двухфазовая модуляция с фазоразностным кодированием.

2.6. Для кодовой защиты передаваемых сообщений должен применяться циклический код с производящим полиномом X 16 + X 12 + X 5 + 1.

2.7. В целях устранения случайных ошибок должна быть предусмотрена возможность повторной передачи сообщений между теми же локальными подсистемами.

2.8. Передача сообщений между локальными подсистемами должна осуществляться посредством ограниченного набора функциональных байтов, последовательность которых устанавливается форматом сообщения. Интерфейс устанавливает два типа форматов сообщений (черт. 1).

Формат 1 имеет фиксированную длину и предназначен для передачи только интерфейсных сообщений.

Формат 2 включает переменную по длине информационную часть, предназначенную для передачи данных.

Формат 2 в зависимости от скорости передачи (низкоскоростной или высокоскоростной диапазон) должен иметь вид 2.1 или 2.2 соответственно.

Типы форматов сообщений

Формат 1

2.9. Форматы сообщений должны включать следующие функциональные байты:

синхронизирующий СН;

адрес вызываемой локальной подсистемы АВ;

код выполняемой функции КФ;

собственный адрес локальной подсистемы АС;

число байтов данных в информационной части ДС, ДС1 или ДС2;

информационные байты ДН1 - ДНп;

байты контрольных кодов КБ1 и КБ2.

2.8, 2.9.

2.9.1. Синхронизирующий байт СН служит для обозначения начала и конца сообщения. Синхронизирующему байту присвоен код?111111?.

2.9.2. Байт адреса подсистемы АВ определяет локальную подсистему, которой направляется сообщение.

2.9.3. Байт выполняемой функции КФ определяет операцию, которая выполняется в данном цикле связи. Назначение разрядов внутри байта КФ приведено на черт. 2.

Структура байта КФ

2.9.4. Коды КФ и соответствующие им выполняемые операции указаны в таблице.

Обозначение байта	Код функции								Выполняемая операция
									Групповая передача (с общей адресацией)
									Запись-чтение
									Централизованный опрос контроллеров
									Передача управления магистральным каналом
									Возврат управления магистральным каналом. Сообщение с общим адресом не принято
									Возврат управления магистральным каналом. Сообщение с общим адресом принято
									Децентрализованный опрос контроллеров. Отсутствие запроса на захват канала. Сообщение с общим адресом не принято
									Запрос на захват магистрального канала. Сообщение с общим адресом не принято
									Запрос на захват магистрального канала. Сообщение с общим адресом принято
									Передача маркера
									Подтверждение приема сообщения
									Подтверждение выдачи сообщения
									Подтверждение приема и последующей выдачи сообщения. Ответы на централизованный опрос
									Отсутствие запроса на захват канала. Сообщение с общим адресом не принято
									Отсутствие запроса на захват канала. Сообщение с общим адресом принято
									Запрос на захват канала. Сообщение с общим адресом не принято
									Запрос на захват канала. Сообщение с общим адресом принято

Нулевой разряд определяет вид сообщения (вызов-ответ), передаваемого по магистральному каналу.

Разряд 1 принимает единичное значение при занятости подсистемы (например формирование буфера данных).

Разряд 2 принимает единичное значение в том случае, если в данном цикле передается сообщение формата 2.

Разряд 3 принимает единичное значение в повторно посылаемом сообщении одной и той же локальной подсистеме в случае обнаружения ошибки или отсутствия ответа.

(Измененная редакция, Изм. № 1).

2.9.5. Собственный адрес локальной подсистемы, формирующей сообщение АС, выдается для того, чтобы сообщить вызываемой подсистеме адрес ответа и проконтролировать правильность ее выбора.

2.9.6. Байт ДС определяет длину информационной части в формате 2.1, при этом величина двоичного кода байта ДС определяет количество байтов ДН. Исключение составляет код????????, который обозначает, что передается 256 информационных байтов.

Байты ДС1, ДС2 определяют длину информационной части в формате 2.2.

(Измененная редакция, Изм. № 1).

2.9.7. Байты данных ДН представляют информационную часть сообщения формата 2. Кодирование данных должно устанавливаться нормирующими документами на сопрягаемые локальные подсистемы.

2.9.8. Контрольные байты КБ1, КБ2 образуют контрольную часть и используются для определения достоверности передаваемых сообщений.

3. СТРУКТУРА ИНТЕРФЕЙСА

3.1. Интерфейс обеспечивает возможность построения рассредоточенных систем с магистральной структурой связи (черт. 3).

Структура соединения локальных подсистем

Л C 1 - ЛCn - локальные подсистемы; МК - магистральный канал; PC - резистор согласующий

3.2. Все сопрягаемые локальные подсистемы должны подключаться к магистральному каналу, через который осуществляется обмен информацией.

3.3. Для сопряжения локальных подсистем с магистральным каналом в их составе должны быть предусмотрены контроллеры связи. Контроллеры связи должны осуществлять:

преобразование информации из формы представления, принятой в локальной подсистеме, в форму, которая требуется для передачи по магистральному каналу;

добавление и выделение знаков синхронизации;

распознавание и прием сообщений, адресованных данной локальной подсистеме;

формирование и сравнение контрольных кодов для определения достоверности принимаемых сообщений.

3.4. Обмен сообщениями между локальными подсистемами должен быть организован в виде циклов. Под циклом понимается процедура передачи в магистральный канал одного сообщения формата 1 или 2. Несколько взаимосвязанных циклов образуют процесс передачи.

3.5. Процесс передачи должен быть организован по асинхронному принципу: на посылаемые в магистральный канал вызовы локальная подсистема должна получать ответы (за исключением групповых операций).

4. ФУНКЦИИ ИНТЕРФЕЙСА

4.1. Интерфейс устанавливает следующие виды функций, отличающиеся по уровням управления, которые занимают локальные подсистемы в процессе обмена сообщениями:

пассивный прием;

прием и ответ;

децентрализованное управление магистральным каналом;

запрос захвата магистрального канала;

централизованное управление магистральным каналом.

(Измененная редакция, Изм. № 1).

4.2. Состав интерфейсных функций, реализуемых локальной подсистемой, определяется составом задачи, решаемой данной подсистемой и ее функциональными характеристиками.

4.3. Тип локальной подсистемы определяется функцией наиболее высокого уровня из числа предусмотренных. Локальная подсистема считается активной относительно той функции, которую она исполняет в текущем цикле.

4.4. В соответствии с составом реализуемых интерфейсных функций различаются следующие типы локальных подсистем:

пассивная управляемая подсистема;

управляемая подсистема;

управляющая подсистема;

инициативная управляющая подсистема;

ведущая подсистема.

4.4.1. Пассивная управляемая подсистема выполняет только опознание и прием адресованных ей сообщений.

4.4.2. Управляемая подсистема осуществляет прием адресованных ей сообщений и формирует ответное сообщение в соответствии с принятым кодом функции.

4.4.3. Управляющая подсистема должна обладать способностью:

принимать управление обменом по магистральному каналу в централизованном и децентрализованном режимах;

формировать и передавать сообщения по магистральному каналу;

принимать и анализировать ответные сообщения;

возвращать или передавать управление магистральным каналом после окончания процесса передачи.

(Измененная редакция, Изм. № 1).

4.4.4. Инициативная управляющая подсистема помимо функции по п. 4.4.3 должна обладать способностью формировать сигнал запроса для захвата магистрального канала, принимать и посылать соответствующие сообщения при выполнении процедуры поиска запрашивающей подсистемы.

4.4.5. Ведущая подсистема координирует работу всех локальных подсистем в режиме централизованного управления магистральным каналом. Она осуществляет:

арбитраж и передачу управления магистральным каналом одной из управляющих локальных подсистем;

центральное управление всеми локальными подсистемами;

контроль работы активной управляющей локальной подсистемы;

передачу сообщений с общим адресом для всех (или нескольких) локальных подсистем.

К магистральному каналу может быть подключена только одна подсистема, имеющая активную функцию ведущей.

(Измененная редакция, Изм. № 1).

5. ПОРЯДОК ОБМЕНА СООБЩЕНИЯМИ

5.1. Каждый цикл передачи сообщения по магистральному каналу должен начинаться с синхронизации всех сопряженных по интерфейсу подсистем.

5.1.1. Для выполнения синхронизации ведущая или активная управляющая подсистема должна передать в магистральный канал синхронизирующий байт СН. Допускается передавать последовательно несколько синхронизирующих байтов. Дополнительные синхронизирующие байты в формат сообщения не включаются.

5.1.2. После выполнения синхронизации всех подсистем ведущая или активная управляющая подсистема передает в магистральный канал сообщение формата 1 или 2, включая их собственные байты СН.

5.1.3. Все байты, за исключением контрольных КБ1 и КБ2, передаются в магистральный канал, начиная с младшего разряда.

Байты КБ1, КБ2 передаются со старшего разряда.

5.1.4. Для исключения из передаваемого в магистральный канал сообщения последовательности битов, совпадающих с кодом байта СН, каждое сообщение должно быть преобразовано таким образом, что после 5 следующих друг за другом символов «1» должен включаться один дополнительный символ «0». Принимающий подсистемой этот символ должен соответственно исключаться из сообщения.

5.1.5. После передачи сообщения, включая оконечный байт СН, передающая подсистема должна передать еще не менее 2 байтов СН для завершения операций приема, после чего цикл передачи заканчивается.

5.2. Процедура управления магистральным каналом определяет последовательность операции по активизации одной из управляющих подсистем для выполнения процесса передачи сообщений. Подсистемы, сопряженные по интерфейсу, могут функционировать в режиме централизованного управления магистральным каналом.

5.2.1. Процедура централизованного управления магистральным каналом предусматривает наличие ведущей подсистемы, которая осуществляет координацию взаимодействия подсистем путем управления передачей управления магистральным каналом.

5.2, 5.2.1. (Новая редакция, Изм. № 1).

5.2.2. При передаче управления магистральным каналом ведущая подсистема назначает активную управляющую подсистему для выполнения процесса передачи сообщений. Для этого ведущая подсистема должна направить выбранной управляющей подсистеме сообщение формата 1 с кодом функции КФ6.

5.2.3. Управляющая подсистема после принятия сообщения с кодом функции КФ6 должна стать активной и может выполнить в одном процессе передачи несколько циклов обмена сообщениями. Количество циклов обмена должно контролироваться и ограничиваться ведущей подсистемой.

5.2.4. После выполнения передачи управления магистральным каналом ведущая подсистема должна активизировать в себе функцию пассивного приема и включить контрольный отсчет времени. Если в течение установленного времени (время ожидания ответа не должно быть более 1 мс) назначенная активной подсистема не начинает передачу сообщений по магистральному каналу, ведущая подсистема повторно направляет управляющей подсистеме сообщение формата 1 с кодом функции КФ6 и признаком повторной передачи.

5.2.5. В случае, если и при повторном обращении управляющая подсистема не начинает передачу сообщений (не становится активной), ведущая подсистема определяет ее как неисправную и реализует предусмотренные для такой ситуации процедуры.

5.2.6. По окончании процесса передачи активная управляющая подсистема должна выполнить функцию возврата управления магистральным каналом. Для этого она должна направить ведущей подсистеме сообщение с кодом функции КФ7 или КФ8.

5.2.7. Процедура децентрализованного управления магистральным каналом предусматривает последовательную передачу функции активной другим управляющим подсистемам путем передачи маркера. Подсистема, принявшая маркер, является активной.

5.2.8. Для начального захвата маркера все подсистемы, сопряженные по магистральному каналу, должны включать интервальные таймеры, причем значения временных интервалов должны быть у всех подсистем различные. Подсистеме, имеющей более высокий приоритет, должен присваиваться меньший временной интервал.

5.2.9. Если по истечении собственного временного интервала подсистемы магистральный канал оказывается свободным, данная подсистема должна считать себя владельцем маркера и начинать процесс передачи как активная управляющая подсистема.

5.2.10. После завершения процесса передачи активная управляющая подсистема должна передать управление магистральным каналом следующей управляющей подсистеме с адресом АВ = АЦ + 1, для чего она должна выдать маркер, активизировать в себе функцию пассивного приема и включить контрольный отсчет времени.

В качестве маркера используется сообщение формата 1 (черт. 1) с кодом функции КФ13 и адресом АВ.

Если в течение установленного времени получившая маркер подсистема не начинает процесс передачи, передававшая его подсистема должна предпринять попытку передать маркер подсистемам с последующими адресами АВ = АС + 2, АВ = АС + 3 и т.д. до тех пор, пока маркер не будет принят. Адрес подсистемы, принявшей маркер, должен запоминаться данной подсистемой как последующий до проведения повторного начального захвата.

5.2.11. Любая активная подсистема, обнаружившая несанкционированный выход в канал связи, должна выполнить действия по п. 5.2.8.

5.2.12. В режиме децентрализованного управления магистральным каналом все подсистемы должны иметь активную функцию пассивного приема. В случае утери маркера (например, при отказе активной управляющей подсистемы) должен срабатывать механизм начального захвата маркера (пп. 5.2.8, 5.2.9) и функционирование должно восстанавливаться.

5.2.13. Любая подсистема, владеющая маркером и получившая активную функцию ведущей, может захватить централизованное управление магистральным каналом и сохранять его до отмены присвоенной ей активной функции ведущей.

5.2.7 - 5.2.13. (Введены дополнительно, Изм. № 1).

5.3. В режиме централизованного управления передача управления магистральным каналом может быть организована по запросам от инициативных управляющих подсистем.

5.3.1. Подсистемы должны иметь активную функцию запроса захвата магистрального канала для организации передачи управления по запросам.

5.3.2. Возможны два способа организации поиска подсистемы, запрашивающей доступ к магистральному каналу, - централизованный и децентрализованный.

5.3, 5.3.1, 5.3.2. (Новая редакция, Изм. № 1).

5.3.3. При централизованном опросе ведущая подсистема должна последовательно опросить все подключенные к магистральному каналу инициативные управляющие подсистемы. Ведущая подсистема должна направить каждой инициативной управляющей подсистеме сообщение формата 1 с кодом функции КФ5.

Инициативная управляющая подсистема должна направить ведущей подсистеме ответное сообщение с одним из кодов функции КФ21 - КФ24 в зависимости от своего внутреннего состояния. Последовательность операций в процедуре централизованного опроса приведена на черт. 4.

5.3.4. Децентрализованный опрос обеспечивает быстрый процесс определения инициативных управляющих подсистем, установивших запрос доступа к магистральному каналу. Ведущая подсистема должна обратиться только к первой по очереди инициативной управляющей подсистеме с сообщением формата 1 и кодом функции КФ9.

Каждая инициативная управляющая подсистема должна воспринимать адресованное ей сообщение и посылать в магистральный канал свое сообщение, адресованное следующей по очереди подсистеме. В формируемом сообщении должен передаваться один из кодов функции КФ9 - КФ12, характеризующий состояние данной подсистемы. Процедура децентрализованного опроса иллюстрируется черт. 5.

5.3.5. Ведущая подсистема после запуска децентрализованного опроса активизирует функцию пассивного приема и принимает все сообщения, посылаемые инициативными управляющими подсистемами. Это позволяет ведущей подсистеме после окончания децентрализованного опроса иметь информацию о запросах доступа к магистральному каналу у всех инициативных управляющих подсистем.

Процесс централизованного опроса подсистемы

Процесс децентрализованного опроса подсистемы

Последняя в цепи децентрализованного опроса инициативная управляющая подсистема должна адресовать свое сообщение ведущей подсистеме, что означает конец процедуры децентрализованного опроса.

5.3.6. В случае, если какая-либо подсистема не выдает сообщения в магистральный канал после обращения к ней, ведущая подсистема должна активизироваться и послать ей повторное сообщение, идентичное предыдущему. В случае отсутствия ответа (или ошибок) на повторный вызов ведущая подсистема запускает децентрализованный опрос со следующей по очереди подсистемы, а данная подсистема из опроса исключается.

5.4. Процедура передачи данных может выполняться в виде одного из следующих процессов:

групповой записи;

записи-чтения.

5.4.1. Групповая запись должна выполняться ведущей подсистемой. При выполнении групповой записи ведущая подсистема выдает в магистральный канал сообщение формата 2, в котором в качестве адреса АВ записан код 11111111 (255) и код функции КФ1.

5.4.2. Все подсистемы, реагирующие на групповой адрес, должны принять сообщение из магистрального канала и зафиксировать состояние, означающее, что сообщение с общим адресом принято. Ответные сообщения при групповой записи принимающими подсистемами не выдаются.

5.4.3. Подтверждение приема группового сообщения осуществляется в процессе централизованного или децентрализованного опроса, а также при возврате управления магистральным каналом, для чего в коды функций КФ7, КФ8, КФ9 - КФ12 и КФ21 - КФ24 включен бит соответствующего состояния.

5.4.4. В процессе записи ведущая подсистема или активная управляющая подсистема посылает в магистральный канал сообщение формата 2 с кодом функции КФ2, предназначенное для приема конкретной управляемой подсистемой, адрес которой указан в байте АВ. После выдачи сообщения активная управляющая подсистема включает контрольный отсчет времени и ждет ответное сообщение.

5.4.5. Адресованная подсистема опознает свой адрес и принимает посылаемое ей сообщение. В том случае, если сообщение принято без ошибки, принимающая подсистема должна выдать в магистральный канал ответ в виде сообщения формата 1 с кодом функции КФ18.

5.4.6. В случае, если в принятом сообщении обнаружена ошибка, принимающая подсистема не должна выдавать ответ.

5.4.7. Активная управляющая подсистема при отсутствии ответа в течение интервала контрольного времени должна повторно выполнить передачу того же сообщения.

5.4.8. При отсутствии ответа на повторное сообщение данная подсистема считается неисправной и активная управляющая подсистема должна выполнить предписанную для такой ситуации процедуру (включение сигнализации, исключение подсистемы из обращения, включение резерва и т.д.).

5.4.9. В режиме централизованного управления магистральным каналом диалог управляющей и управляемой подсистем должен постоянно контролироваться ведущей подсистемой, выполняющей в это время функцию пассивного приема сообщений.

(Новая редакция, Изм. № 1).

5.4.10. Процесс чтения должен начинаться посылкой активной управляющей подсистемой сообщения формата 1 с кодом функции КФ3.

5.4.11. Подсистема, которой адресовано это сообщение, в случае исправного его приема, должна выдать ответное сообщение формата 2 с кодом функции КФ19.

5.4.12. В случае, если вызываемая подсистема не может выдать данные в течение установленного времени ожидания, то она должна после принятия сообщения с функцией чтения зафиксировать признак занятости подсистемы и приступить к формированию массива данных для выдачи.

5.4.13. Данная управляемая подсистема должна запомнить адрес обратившейся к ней активной управляющей подсистемы (для которой готовятся данные) и в ответных сообщениях другим управляющим подсистемам устанавливать признак занятости.

5.4.14. Для считывания подготовленных данных активная управляющая подсистема должна вновь обратиться к управляемой подсистеме с сообщением формата 1 с кодом функции КФ3. Если данные к этому времени подготовлены, то управляемая подсистема должна выдать ответное сообщение формата 2 с кодом функции КФ19.

Признак занятости подсистемы должен сниматься только после передачи ответного сообщения формата 2.

5.4.15. Если ответное сообщение принято активной управляющей подсистемой без ошибки, то процесс чтения на этом завершается.

5.4.16. При обнаружении ошибки или отсутствии ответа активная управляющая подсистема повторяет обращение, а затем предпринимает меры, аналогичные приведенным в пп. 5.4.7, 5.4.8.

5.4.17. Запись-чтение представляет собой совмещение процессов по пп. 5.4.4 - 5.4.15.

5.4.18. Активная управляющая подсистема посылает в магистральный канал сообщение формата 2 с кодом функции КФ4.

5.4.19. Адресованная подсистема должна принять направленное ей сообщение и сформировать ответное.

5.4.20. Ответное сообщение в данном процессе должно быть представлено форматом 2 (содержать считываемые данные) и иметь код функции КФ20.

5.4.21. Контроль достоверности передаваемых сообщений и предпринимаемые активной управляющей подсистемой действия должны быть аналогичны приведенным для процессов записи и чтения.

6. ФИЗИЧЕСКАЯ РЕАЛИЗАЦИЯ

6.1. Физически интерфейс реализуется в виде линий связи, образующих магистральный канал, и контроллеров связи, обеспечивающих непосредственное подключение к линиям связи.

6.2. Контроллеры связи должны выполняться в виде функциональных узлов, входящих в состав подсистемы, или в виде конструктивно обособленных устройств.

6.3. Правила сопряжения и взаимодействия контроллеров связи с функциональной частью подсистемы данным стандартом не регламентируются.

6.4. Для линий связи магистрального канала должен применяться коаксиальный кабель с волновым сопротивлением 75 Ом.

6.5. Коаксиальный кабель должен быть нагружен на обоих концах согласующими резисторами сопротивлением (75 ± 3,75) Ом. Мощность согласующих резисторов должна быть не менее 0,25 Вт.

Согласующие резисторы должны подключаться к концам линий связи при помощи ВЧ-соединителей.

Заземление или соединение линий связи с корпусами устройств в сопрягаемых подсистемах не допускается.

6.6. Затухание по линии связи магистрального канала должно быть не более 18 дБ для скорости 500 кбит/с.

6.7. Суммарное затухание, вносимое каждым ответвлением от линии связи магистрального канала, не должно превышать 0,1 дБ, включая затухание, определяемое качеством точки стыковки, затухание на ответвлении и затухание, зависящее от входных-выходных параметров схем согласования.

6.8. Ответвления от линии связи магистрального канала должны выполняться коаксиальным кабелем с волновым сопротивлением 75 Ом. Длина каждого ответвления - не более 3 м. Суммарная длина всех ответвлений входит в суммарную длину магистрального канала. Подключение к линии связи должно осуществляться при помощи ВЧ-соединителей. Отключение любой из подсистем не должно приводить к разрыву линии связи.

6.9. Контроллеры связи должны содержать приемо-передающие усилители, обеспечивающие:

чувствительность по приему, не хуже......................................................... 240 мВ

уровень выходного сигнала.......................................................................... от 4 до 5 В

выходное сопротивление.............................................................................. (37,50 ± 1,88) Ом

6.10. Формирование электрических сигналов для передачи в магистральный канал осуществляется модуляцией тактовой частоты сигналами передаваемого сообщения. Каждому биту передаваемого сообщения соответствует полный период тактовой частоты, причем передний и задний фронты передаваемого сигнала должны совпадать с переходом через ноль тактовой частоты (черт. 6). Соответствие символов, принимаемых из магистрального канала, значащим состояниям устанавливается следующим образом:

символу «0» соответствует противоположная фаза относительно предыдущего символа,