вторник, 7 июня 2011 г.

Transparent Ready - Протокол Modbus TCP

Протокол Modbus TCP или Modbus TCP/IP по сути является переносом, ставшего уже стандартом де-факто протокола Modbus для последовательной линии, на стек протоколов TCP/IP. Modbus TCP предоставляет сервис обмена сообщениями между Клиентами (Client) и Серверами (Server) в сети на основе стека протоколов TCP/IP. Клиент-серверная модель предусматривает 2 типа сообщений (строго говоря стандарт предусматривает 4 типа, однако 2 из них является лишь производными от основных) - запрос (Request) и ответ (Response). Т.е. в нормальном режиме обмена сообщениями каждому запросу должен соответствовать ответ.

Существует 2 типа устройств, которые так или иначе могут учавствовать в обмене Modbus-сообщениями:
  • клиенты, генерирующие запросы и сервера, пересылающие ответы;
  • устройства, обеспечивающие взаимосвязь различных сегментов сети, построенных на разных физических уровнях - примером такого устройства может служить мост между сетями Ethernet и RS485.
Рассмотрим основные составные части Modbus-сообщения, определенные в стандарте. Простейшим элементом является Protocol Data Unit(PDU) (Элемент Данных Протокола), который является общим для всех низлежащих коммуникационных уровней. При формировании Modbus-сообщения с учетом конкретной шины или сети к PDU обычно добавляются некоторые доп. данные (адресная информация, контроль ошибок), которые вместе образуют Application Data Unit (ADU) (Элемент Данных Приложения).
В момент формирования клиентом Modbus-запроса строится соответствующий сети ADU. Код функции, указанный в запросе, сообщает серверу какое действие он должен сообщить.
Modbus-сообщение протокола Modbus TCP имеет несколько иной вид.
Как видим, в случае Modbus TCP протокола в ADU появляется некий MBAP (MODBUS Application Protocol) заголовок, о котором мы будем говорить чуть дальше. Также видно, что ADU не имеет поля контроля ошибок. Это связано с тем что контроль ошибок осуществляется низлежащими протоколами (Ethernet, IP, TCP) в сетевом стеке. Еще один момент, который следует упомянуть - адресация устройств осуществляется на основе соответствующего поля протокола IP, тогда как в MBAP заголовке остается лишь вспомогательная информация.
Давайте подробнее рассмотрим MBAP-заголовок:
Поле Длина Описание Клиент Сервер
Transaction Identifier (Идентификатор Транзакции) 2 байта Идентификация MODBUS запроса/ответа Определяется клиентом Копируется из полученного запроса
Protocol Identifier (Идентификатор Протокола) 2 байта =0 для протокола MODBUS Определяется клиентом Копируется из полученного запроса
Length (Длина) 2 байта Количество последующих байт Определяется клиентом (только запрос) Определяется сервером (ответ)
Unit Identifier (Идентификатор устройства) 1 байт Идентификатор устройства, подключенного к другой шине Определяется клиентом Копируется из полученного запроса

Рассмотрим каждое поле подробнее:
Transaction Identifier - поле используется для однозначного сопоставления запроса и ответа при значительной интенсивности запросов и ответов, сервер копирует это поле из полученного запроса и вставляет в соответствующее поле ответа;
Protocol Identifier - поле используется при преобразовании протокола MODBUS в какой либо другой протокол (UniTel и др.), используется шлюзами, мостами и др. преобразующими устройствами;
Length - поле, содержащее количество байтов в сообщении, начиная со следующего поля (Unit Identifier). Помогает собрать сообщение в единое целое в случае фрагментации сообщения по разным IP-пакетам;
Unit Identifier - поле используется для пересылки Modbus TCP сообщения через шлюз или мост к устройству в сети Modbus RS-485 или Modbus+;
Все ADU протокола Modbus TCP пересылаются на удаленный TCP-порт 502. Здесь следует отметить, что порт № 502 зарезервирован под протокол Modbus и зарегистрирован в организации IANA (Internet Assigned Numbers Authority). Это исключает использование этого порта другими протоколами и приложениями и является важным условием для совместимости устройств, поддерживающих Modbus TCP.
Что-бы иметь полное представление о механизмах обработки Modbus-сообщений, давайте рассмотрим модель Modbus-компонента, охватывающую функционал клиента и сервера.
Конечное Modbus-устройство может использовать как один из интерфейсов (клиент, сервер) так и совмещать в себе оба.
Modbus-клиент обеспечивает возможность пользовательскому приложению формировать запросы к удаленным устройствам и контроллировать их выполнение.
Интерфейс Modbus-клиента определяет механизм, по которому запросы от пользовательского приложения передаются Modbus-клиенту. Интерфейс Modbus-клиента не рассматривается в стандарте и его реализация зависит от производителя конкретного устройства.
Modbus-сервер включается в работу при поступлении запроса от внешнего устройства. Основной функцией этой части модели является выполнение действий, содержащихся в запросе (чтение или запись данных, запрос состояния и т.д.) Все действия, происходящие на этом уровне полностью независимы от пользовательского приложения. Обычным поведением этой части модели является прослушивание 502-го порта на наличие поступивших запросов и обработка оных при поступлении.
Внутренний Modbus-интерфейс предоставляет доступ к внутренним данным пользовательского приложения. Протокол Modbus предполагает доступ к 4-м областям объектов. Это совершенно не означает что существует 4 области переменных. Эти области могут находится в одном адресном простаранстве либо устройство может поддерживать лишь одну адресную область, другими словами стандарт не оговаривает каким образом запросы из сети адресуются к тому или иному блоку памяти в устройстве.
Вернемся к типам поддерживаемых объектов. Всего их четыре. Они представлены в нижеследующей таблице.
Область Тип объекта Тип доступа Комментарий

Discrete Inputs (дискретные входы)
Одиночный бит Чтение Этот тип данных обычно связан с входами/выходами (адереса - %Ixx, 10001+xx)
Coils (ячейки или катушки) Одиночный бит Чтение/запись
Этот тип данных управляется пользовательским приложением (адереса - %Mxx, 00001+xx)
Input Registers (входные регистры) 16-битное слово Чтение Этот тип данных обычно связан с входами/выходами (адереса - %IWxx, 30001+xx)
Holding Registers (регистры хранения) 16-битное слово Чтение/Запись Этот тип данных управляется пользовательским приложением (адереса - %MWxx, 40001+xx)
Управление TCP соединениями является важной частью модели, т.к. без установленного TCP-соединения не может производится обменModbus-запросами. Управление соединениями может происходить автоматически без вмешательства пользовательского приложения либо в ручном режиме, когда пользовательское приложение управляет установлением и разрывом каждого из соединений. Как уже было сказано выше, TCP-порт 502 зарезервирован под Modbus-протокол и в обязательном порядке должен прослушиваться сервером на предмет установления нового соединения или нового запроса. Однако это также не исключает использование дополнительных свободных портов для обмена Modbus-запросами. В этом случае и клиент и сервер должны иметь возможность общаться через нестандартные порты.
Контроль доступа в протоколе Modbus TCP осуществляется на уровне соединений. Это означает что если включен контроль доступа и удаленному IP-узлу запрещен доступ к серверу, то сервер отбросит такую попытку соединения, тем самым исключив попытку посылки Modbus-запроса от конкретного узла.
В параметрах стека задаются необходимые параметры для осуществления соединения - IP-адрес, если необходимо удаленный порт и др.
Рассмотрим подробнее процесс установления соединения. Как мы уже говорили, обмен Modbus-запросами требует установленного TCP-соединения между Modbus-клиентом и Modbus-сервером. Процесс установления соединения может контроллироваться пользовательским приложением (больше возможностей, однако необходимо знание механизмов TCP-протокола) или, что более распространено, модулем управления соединениями и быть полностью скрытым от пользователя. Т.е. при необходимости передать запрос модуль управления соединениями сам установит нужное соединение.
Количество одновременно установленных соединений зависит от конкретного устройства и не регламентируется стандартами.
Как правило, каждое Modbus-устройство обладает двумя пулами соединений (connection pool) - приоритетный и неприоритетный.
К приоритетному пулу относятся соединения, которые не разрываются по инициативе сервера. Для того что-бы соединение было отнесено к приоритетному пулу, IP-адрес устройства, запрашивающего соединение, должен быть внесен в приоритетный список сервера. Такие IP-адреса называются помечеными (marked). Любое новое соединение от помеченого устройства должно быть установлено сервером, однако также должено существовать ограничение на максимальное кол-во соединений с одного помеченого IP, дабы избежать использования всего пула одним устройством.
В неприоритетный пул направляются соединения с непомеченых IP-адресов. Если в пуле нет свободных соединений, то самое старое соединение закрывается, предоставляя возможность создания нового соединения.
Когда Modbus-клиенту необходимо передать удаленному серверу запрос, блоку управления соединениями передается сформированное ADU. Блок управления соединениями проверяет существует ли нужное соединение и, если необходимо, проходит процедуру его создания. Каждое клиентское соединение имеет свой порт с номером большим 1024. Блок управления соединениями пытается установить соединение с 502-м портом сервера. В свою очередь блок управления соединениями сервера прослушивает порт 502 и при появлении новых запросов на соединение относит их к одному из пулов и устанавливает, либо отклоняет.
По созданному соединению передается требуемое ADU.
Дабы не перегружать статью кодами Modbus-функций, я приведу ссылку на официальную спецификацию протокола с описанием всех кодов функций.
В конце статьи рассмотрим пример использования Modbus-запросов в среде Unity с контроллерами M340 Schneider-Electric.
В примере мы будем считывать с удаленного устройства 5 внутренных регистров с помощью функции ReadVar().

Комментариев нет:

Отправить комментарий