002

Забыть нельзя использовать

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

 

«навороченные» протоколы, нередко происходит «с тяжелым вздохом сожаленья»… Давайте посмотрим, реально ли исправить ситуацию? Может быть, нужно просто «правильно расставить запятые»?

 


В контексте семиуровневой модели OSI спецификацией MODBUS определяется уровень интерфейса приложения (7 — Application), описание остальных уровней, кроме уровня физического доступа к среде передачи (1 — Physical), определяемого «классическим» EIA/TIA_485, при этом не требуется. В соответствии со спецификацией на шине должно присутствовать одно ведущее (master) и одно или несколько ведомых (slave) устройств. Передача данных осуществляется между ведущим и ведомым в формате «запрос —  твет». Передача данных от одного ведомого к другому не поддерживается. Единицей информации является либо регистр, либо бит, адресуемые по номерам. Определено четыре пространства номеров: два для битов и два для регистров (одно — доступные только для чтения и одно — доступные для чтения и записи).

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

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

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

3. Протокол MODBUS — сканирующий и, как следствие, он довольно неэффективно использует полосу пропускания канала. Современные протоколы полевых шин событийные (точнее, событийно_сканирующие).

Предлагаемая «расстановка запятых»

А если принять, что спецификацией MODBUS определяется не седьмой (Application), а третий (Network) уровень модели OSI, и «надстроить» над ним, отдельным уровнем, недостающий функционал? Тогда мы  получим полевую шину, для которой уже имеется широчайший выбор качественной, проверенной временем,  дешевой периферии, шлюзов и всякой «мелочевки», отработанная методология применения и другие  вкусности». И при этом есть возможность строить сети нового типа, лишенные основных не достатков  классического» MODBUS!

Передача данных между ведомыми

А почему, собственно говоря, один ведомый не может «подслушивать» ответы других ведомых и, таким образом, получать данные напрямую, без навязываемой «классическим» MODBUS двойной пересылки и буферизации? Данные по шине передаются пакетами (в терминах протокола это PDU — protocol data units). В  режиме MODBUS RTU пакеты разделены паузами в 3,5…4 символа. В режиме ASCII пакеты разделяются  символами «:» (начало) и «Ctrl» (конец). Благодаря этому можно достаточно легко выделить в потоке передаваемых данных отдельные PDU. Все PDU соответствуют шаблону {Адрес ведомого, Номер функции,  CRC}. Это позволяет при «подслушивании» провести первичную фильтрацию и сразу отбросить большую часть «неинтересных» PDU. Далее необходимо отличать между собой PDU запроса и PDU ответа (форматы  некоторых PDU приведены на рисунке). Поскольку запрос и ответ в потоке всегда идут подряд, один за другим, и во многих случаях оба содержат полезную информацию, имеет смысл хранить в буфере не менее двух последних принятых PDU. Функции 3 и 4 (читать Input registers и читать Holding registers) Длина запроса  о этим функциям всегда восемь байт (то есть четная), а длина ответа из_за поля «Byte Count» всегда  нечетная. Функциям 1 и 2 (читать биты — Inputs и Coils) Длина запроса также равна восьми байтам, но здесь не все так просто. При запросе одним пакетом от 17 до 24 бит (три байта данных) длина ответа также будет равна восьми байтам и длины запроса и ответа совпадут. В этом случае поле «Byte Count» PDU ответа должно быть равно трем, а оно совпадает по позиции со старшим байтом номера начального бита в PDU запроса. Таким образом, если в этом байте пакета значение отлично от трех и длина пакета равна восьми, то это достоверно PDU запроса. Таким образом, проблема имеется только для «трехбайтных запросов» (запросы на 17...24 бит), начинающихся с бита c номером в диапазоне 0х300…0х3FF (номера старше 767). Конечно, для проблемных PDU можно еще проверить, есть ли в позиции «Count High» не ноль и в позиции «Count Low» значение вне диапазона 17…24. Можно выполнить еще некоторые проверки, но следует признать, что гарантировать 100 % расшифровку обращений к битам в диапазоне 0x300…0x3FF при «подслушивании», нельзя. Что ж, даже если ограничиться «input registers», «holding registers» и первыми 768 битами (0…0x2FF), это немало!

Резервирование мастера

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

предусмотреть резервирование ведущего устройства и тем самым убрать «единую точку отказа». Один или несколько резервных ведущих могут «слушать поток», фиксировать его структуру и «таймировать паузы». Если, например, выявлена пауза более трех секунд, это, скорее всего, означает отказ ведущего, и резервный ведущий может попытаться восстановить обмен по шине, перехватив контроль линии и сформировав поток с ранее зафиксированной структурой. Если через некоторое время после этого на шине будут выявлены коллизии, можно попытаться вернуть контроль линии основному ведущему, сформировав паузу, например, две с половиной секунды. Альтернативной реализацией может быть не фиксация структуры потока, а некое API, реализованное поверх регистровой модели MODBUS, позволяющее другим устройствам «подписаться» на нужные им данные у резервного мастера, уже после перехвата им контроля линии. Или, наоборот, структура потока, при управлении линией от резервного мастера может быть в нем запрограммирована или настроена через некий интерфейс человеком (наладчиком) на этапе ввода системы в эксплуатацию.

Событийная передача данных

Эту фишку, на наш взгляд, тоже достаточно просто реализовать «поверх» MODBUS. Правда, потребуется поддержка новой функциональности как ведущим, так и ведомым (но, заметим, необязательно всеми ведомыми). Введем, по аналогии с цифровыми форматами хранения видеоинформации, понятия P-фрейма (опорного) и I-фрейма (инкрементного или событийного). P-фреймами в протоколе MOD BUS будут являться стандартные пакеты чтения групп регистров, которые в новом режиме передачи данных можно будет запрашивать существенно реже, чем это было нужно ранее. I-фреймы предлагается получать следующим образом:

  • Ведущий обращается к ведомому на чтение двух специальных регистров (например, с номерами 0xFFFE и 0xFFFF).
  • Ведомый возвращает в этих регистрах номер регистра, изменившего свое значение со времени последнего обращения, и его новое значение.
  • Если, по мнению ведомого, ничего не менялось, он отправляет ведущему просто номер и текущее значение одного из регистров, на свое усмотрение :).
  • Ведущий обрабатывает полученный номер регистра/значение и запрашивает следующий I-фрейм (или P-фрейм, если посчитает нужным).
  • Если ведущий получил I-фрейм с ошибкой, он может запросить Р-фрейм (стандартный пакет чтения группы регистров), что обеспечит быстрое восстановление после ошибок, возникающих в канале.
  • Для того чтобы отправлять в I-фреймах не все подряд, а только данные, «интересные» ведущему, ведомый может трактовать P-фреймы как запросы на подписку получения I-фреймов :).

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

Проверка теории практикой

Данная методика была нами применена для разработки модуля местной индикации/сигнализации. Разработанный модуль подключается в существующую MODBUS_сеть и без вмешательства в ее настройки выполняет опрос (подслушивание) до 12 регистров на любом (до 12 :)) количестве ведомых устройств, индикацию их текущего состояния и сигнализацию определенных значений как аварийных. При «пропадании потока» модуль перехватывает роль ведущего шины и самостоятельно опрашивает нужные ему устройства. На сегодняшний день проведены лабораторные испытания, показавшие как минимум возможность использования такого модуля в сети MODBUS совместно с контроллерами «РАУТ_Автоматик» и «ОВЕН» (это то оборудование, которое оказалось под рукой, задачу протестировать модуль на совместимость со всем и вся мы пока себе не ставили). Также пока не тестировался режим нескольких резервных ведущих и режим событийной передачи по шине. Работы продолжаются. Возможно, об этом — в следующем номере. :)