СПКД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.

Мнемоника	Код	Реализуемая функция
Read Coil Status	01	Считать описание регистров дискретного выхода
Read Input Status	02	Считать входные данных
Read Holding Registers	03	Считать холдинг регистры
Read Input Registers	04	Считать входные регистры
Force Single Coil	05	Записать значение в регистр дискретного вывода
Preset Single Register	06	Установить значение регистра
Force Multiple Coils	15	Записать значение в несколько регистров дискретного вывода
Preset Multiple Registers	16	Установить значения нескольких регистров

Из структуры пакетов можно сделать вывод о линейном принципе организации адресного пространства контроллера (драйвера сервера 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. 

Мнемоника	Код запроса	Код ответа	Реализуемая функция
DataRead	01h	41h	Чтение одного данного из БД удаленного узла
DataWrite	02h	62h	Запись одного данного в БД удаленного узла
DataFind	03h	43h	Поиск адреса данного в БД удаленного узла
AddrCheck	04h	44h	Проверка существования адреса в БД удаленного узла
InfoRead	05h	45h	Чтение структуры БД удаленного узла
BlockRead	06h	46h	Чтение массива данных из БД удаленного узла
BlockWrite	07h	67h	Запись массива данных в БД удаленного узла
DataChanges	08h	68h	Передача удаленным узлом значений измененных данных
SetTime	11h	71h	Установка системной даты и времени в удаленном узле
GetTime	32h	52h	Чтение системной даты и времени из удаленного узла
Message	13h	63h	Передача сообщения удаленному узлу

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

1   ...   6   7   8   9   10   11   12   13   14

хорошо

   1

Ваша оценка: