СПКД123 / СПДК / Задачи АСУТП / Лекция 11. Диспетчерские пункты АСУТП. Протоколф информационных обменов

Лекция 11. Диспетчерские пункты АСУТП. Протоколы информационных обменов

Содержание лекции:

• Характеристики информационных обменов ДП АСУТП

• Режимы взаимодействия клиента и сервера 

• Протокол Modbus – сообщения, функции, адресация

• Протокол Telegramm/2P –сообщения, функции, адресация

1. Характеристики информационных обменов ДП АСУТП

Рассматривая диспетчерский пункт АСУТП, можно выделить два вида информационных обменов между ДП и прочими системами (рис. 11.1). 1а) Связь с подключенными контроллерами автоматики и систем телемеханики. 1б) Связь с соседними АСУТП. 1в) Связь с вышестоящими АСУТП (центральным диспетчерским пунктом). 2а) Передача отчетных данных о состоянии технологического процесса в АСУПХД. 2б) Передача отчетных данных на более высокий уровень.  Рис. 11.1. Информационные обмены, внешние по отношению  к ДП АСУТП Физически подключение контроллеров к ДП АСУТП осуществляется либо по последовательным каналам связи, используя соединения «точка-точка» (см. рис. 11.2а), либо все контроллеры и ДП подключаются к общей шине передачи данных, реализуя схему «точка-многоточие» (см. рис. 11.2б). (Для физической проводной линии используются протоколы физического уровня RS-232, RS-485 соответственно, для удаленного подключения используются модемы, работающие по выделенной линии тональной частоты или локальная/глобальная сеть). Также широко распространена ситуация, когда контроллеры образуют иерархическую структуру, и к ДП АСУТП подключается единственный контроллер, находящийся на вершине иерархии, к нему по последовательным каналам связи или по шине передачи данных подключены остальные контроллеры (см. рис 11.2в, г). Такой выделенный контроллер играет одну или несколько следующих ролей:

• Концентратор данных. Контроллер проводит опрос всех подключенных к нему устройств, и формирует свою базу данных – объединение данных баз данных контроллеров нижнего уровня. ДП АСУТП направляет все запросы на получение данных к БД концентратора данных, фактически – кэшу технологических данных.

• Преобразователь протокола. Так, для коммуникации между контроллерами может использоваться нестандартный протокол, разработанный их производителем. Контроллер – преобразователь протокола преобразует запросы коммуникационной подсистемы ДП АСУТП, использующей некоторый стандартный протокол, к «внутреннему» протоколу сети контроллеров, и обратно – ответы контроллеров к стандартному протоколу.

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

Любое иерархическое объединение контроллеров («узлов» технологической сети передачи данных) подразумевает возможность коммуникации между ними, и даже если используются только соединения «точка-точка», все контроллеры осуществляют маршрутизацию пакетов и запросы ДП могут адресоваться к каждому из контроллеров в отдельности. Как правило, взаимодействие между двумя любыми контроллерами можно рассматривать как клиент-серверное, выделяя «ведомого» (master) и «ведущего» (slave).  Рис. 11.2. Варианты взаимного подключения ДП – контроллеры.

2. Режимы взаимодействия клиента и сервера

Выделяют три режима передачи информации между клиентом и сервером: периодический опрос, периодический опрос изменений, спонтанная передача изменений. Протокол передачи данных может реализовывать (в своей прикладной части) один или несколько данных режимов.  POLL (периодический опрос). С заданной периодичностью клиент отправляет запрос на получение набора значений (частный случай – всех) сигналов сервера.  PRBX (periodical report by exception, периодическое получение измененных данных). С заданной периодичностью клиент отправляет запрос на получение значений сигналов сервера, изменившихся с момента последней передачи (или двухфазное взаимодействие: сначала отправляется запрос на определение наличия измененных данных, в случае наличия – второй запрос на их получение).  SRBX (spontaneous report by exception, спонтанное получение измененных данных). При изменении значения сервер спонтанно, т.е. без предшествующего запроса со стороны клиента, отправляет пакет с идентификатором и собственно значением измененного сигнала. Особенностью режимов передачи изменений является необходимость проведения периодического опроса всех значений при начальной инициализации клиента (а также при разрыве и восстановлении связи) для синхронизации своей базы данных с базой данных источника данных.

3. ^ Протокол Modbus – сообщения, функции, адресация

Modbus – исключительно простой протокол, он реализует только периодический опрос целочисленных и логических значений. Взаимодействие между клиентом и сервером – полностью синхронное, т.е. в ответ на полученный запрос сервер выдает ответ на него, накопления запросов с последующей их обработкой и выдачей серии ответов не предусматривается. Существует два режима, влияющие на формирование пакетов: ASCII и RTU. В первом случае используются только символы с диапазоном значений 0-127 (таблица ASCII), числа передаются в символьном виде, вводятся стартовая и стоповая последовательности. RTU режим использует 8 бит данных и является намного более эффективным.  Фрейм канального уровня состоит из четырех частей: байта адреса ведомого узла, байта – функционального кода, массива прикладных данных и 16-ти битной контрольной суммы. Рис. 11.3. Структура фрейма канального уровня протокола Modbus. В зависимости от прикладной функции, структура блока прикладных данных варьируется и содержит информацию, необходимую для выполнения определенного запроса или, в ответе, результат выполнения запроса или код ошибки. Пример структур запроса/ответа для функции 03 (считать холдинг регистры) приведен на рис. 11.4. Рис. 11.4. Структура прикладного запроса/ответа. Табл. 11.1. Наиболее часто используемые прикладные функции протокола Modbus.

Из структуры пакетов можно сделать вывод о линейном принципе организации адресного пространства контроллера (драйвера сервера Modbus). Протоколом также определено, что общая область адресов (диапазон от 0 до 65535) разбивается на 4 подобласти: по адресам от 0 до 9999 располагаются сигналы дискретного вывода (coils), от 10000 до 29999 – сигналы дискретного ввода (input statuses), от 30000 до 39999 – входные регистры (input registers), адреса выше 40000 соответствуют регистрам состояний (holding registers). 

4. ^ Протокол Telegramm/2P – сообщения, функции, адресация

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

• Информационный фрейм (STX). Предназначен для обмена прикладными данными.

• Фрейм квитирования (ACK). Используется для подтверждения удаленным узлом приема информационного блока, соответствия контрольной суммы.

• Запрос установления связи (ENQ). В случае, когда узел диагностирует отсутствие связи, он с заданной периодичностью отправляет в линию данный фрейм.

• Квитирование установления связи (SYN). При получении запроса установления связи, узел отправляет данный фрейм, после чего оба узла переходят в рабочий режим наличия связи.

Структуры этих пакетов показаны на рис. 11.5.  Рис. 11.5. Структура фреймов канального уровня протокола Telegramm/2P. Также определяется ряд периодов ожидания (тайм-аутов) канального уровня: ACK Timeout – максимальное время ожидания прихода фрейма-подтверждения; Char Timeout – максимальная задержка приема символа фрейма; ENQ Timeout – периодичность отправки запроса на установление связи; NOP Timeout – максимальное время неактивности, после чего узел должен отправить в линию пустой запрос. Эти тайм-ауты настраиваются в зависимости от качества линии связи и обычно составляют единицы секунд (сотни миллисекунд для Char Timeout). Когда узел находится в рабочем режиме, то он готов передавать прикладную информацию. Но, если нет приема и нечего передавать в течение заданного промежутка времени, то узел передает пустое сообщение (NOP – STX фрейм, не содержащий данных). Обработка пустых блоков полностью соответствует обработке STX-фреймов, т.е. требует квитирования в течение заданного промежутка времени. На время ожидания квитирования передача следующих STX-фреймов блокируется. В случае, если какое-либо из времен ожидания превышено, узел несколько раз повторяет отправку того же STX фрейма, в случае неудачи всех попыток переходит в состояние поиска связи. На прикладном уровне определены два вида сообщений: 

• ROUT-сообщения. Предназначены для передачи другому узлу информации об изменении состояния сети (пропадании или восстановлении связи с каким-либо узлом). Код команды (CMD CODE) определяет, несет ли пакет сообщение информацию о пропадании или установлении связи с узлом (NODE ID).

• NOS-сообщения. Используются для упаковки прикладных запросов/ответов – выполнения функций пользовательских программ. Каждый отправленный NOS-запрос требует, по результатам своей обработки удаленным узлом, возвращения NOS-ответа. Структура NOS-сообщений является единой, независимо от содержания. Каждое сообщение состоит из заголовка и массива данных (наличие которого не обязательно). 

Рис. 11.6. Структура пакетов прикладного уровня. Протоколом определены 11 прикладных функций, приведенные в табл. 11.2. На каждый полученный запрос должен быть отправлен ответ, однако допускается передача множества запросов с последующей последовательной отправкой соответствующего количества ответов. Запрос отправляет клиент, ответ – сервер, за исключением передачи удаленным узлом измененных значений – в этом случае, сервер отправляет запрос, а клиент прикладной ответ – подтверждение получения измененных данных. Табл. 11.2. Прикладные функции протокола Telegramm/2P. 

На рис. 11.8 показана структура прикладного запроса на чтение блока данных и ответа на него, сформированного сервером.  Рис. 11.7. Структура прикладного запроса/ответа BlockRead. Структура информационной базы контроллера (или ее интерфейсной части, к которой происходит адресация), трехуровневая: адресация к некоторой ячейке данных происходит с указанием типа, элемента (т.о., двухуровневая адресация к массиву сигналов определенного типа) и адреса – индекса элемента в данном массиве.