Как общаются машины: протокол Modbus


    Протокол Modbus — самый распространенный промышленный протокол для M2M-взаимодействия. Является стандартом де-факто и поддерживается почти всеми производителями промышленного оборудования.

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

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

    История Modbus


    Modbus был представлен в 1979 году компанией Modicon (ныне Schneider Electric). Это был открытый стандарт, работающий по интерфейсу RS-232. Позже появилась реализации протокола для интерфейсов RS-485 и Modbus TCP. Протокол быстро набрал популярность, и многие производители стали внедрять его в своих устройствах.

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

    В описании стандарта Modbus используются терминология, унаследованная от языков релейной логики. Так, например, некоторые регистры называются катушками (англ. coil).

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




    • RS-232/422/485 — последовательные интерфейсы, широко распространенные в промышленности. Интерфейсы RS-422/485 обеспечивают дальность сигнала до 1200 метров. Используются протоколы Modbus RTU/ASCII
    • Сети TCP/IP — физическим каналом передачи данных могут любые ethernet-интерфейсы. Используется протокол Modbus TCP

    Логический уровень



    Различия протоколов Modbus

    Modbus ASCII


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

    Modbus RTU


    В протоколе Modbus RTU данные кодируются в двоичный формат, и разделителем пакетов служит временной интервал. Этот протокол критичен к задержкам и не может работать, например, на модемных линиях. При этом, накладные расходы на передачу данных меньше, чем в Modbus ASCII, так как длина сообщений меньше.

    Modbus TCP


    Структура пакетов схожа с Modbus RTU, данные также кодируются в двоичный формат, и упаковываются в обычный TCP-пакет, для передачи по IP-сетям. Проверка целостности, используемая в Modbus RTU, не применяется, так как TCP уже имеет собственный механизм контроля целостности.

    Формат пакета



    Форматы пакета разных реализаций Modbus

    Все устройства Modbus взаимодействуют, следуя модели master-slave. Запросы может инициировать только master-устройство, slave-устройства могут только отвечать на запросы, и не могут самостоятельно начинать передачу данных. В зависимости от реализации протокола, заголовки пакета различаются. Вот основные составляющие пакета, которые важно знать:

    ADU (Application Data Unit) — пакет Modbus целиком, со всеми заголовками, PDU, контрольной суммой, адресом и маркерами. Отличается, в зависимости от реализации протокола.

    PDU (protocol data unit) — основная часть пакета, одинаковая для всех реализаций протокола. Содержит сам payload.

    Адрес устройства — адрес получателя, то есть slave-устройства. В одном сегменте Modbus-сети могут находится до 247 устройств. Только slave-устройства имеют различающиеся адреса, master-устройство не имеет адреса. Адрес «0» используется для широковещательных запросов от master, при этом, slave-устройства не могут отвечать на эти широковещательные пакеты.

    Контрольная сумма — алгоритмы проверки целостности пакетов. В Мodbus RTU и ASCII используется 2 байта контрольной суммы. В Modbus RTU применяется алгоритм CRC16, в Modbus ASCII — более простой и менее надежный LRC8. В Modbus TCP контрольная сумма не добавляется в ADU, так как целостность проверяется на уровне TCP.

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

    Регистры и функции Modbus


    В упрощенном виде, структура запросов Modbus состоит из кода функции (чтение/запись), и данных, которые нужно считать или записать. При этом, коды функции различаются для разных типов данных. Разберем, какие бывают регистры, и функции для работы с ними.


    • Discrete Inputs — дискретные входы устройства, доступны только для чтения. Диапазон адресов регистров: с 10001 по 19999. Имеют функцию «02» — чтение группы регистров
    • Coils — дискретные выходы устройства, или внутренние значения. Доступны для чтения и записи. Диапазон адресов регистров: с 20001 по 29999. Имеет функции: «01» — чтения группы регистров, «05» — запись одного регистра, «15» — запись группы регистров
    • Input Registers — 16-битные входы устройства. Доступны только для чтения. Диапазон адресов регистров: с 30001 по 39999. Имеют функцию: «04» — чтение группы регистров
    • Holding Registers — 16-битные выходы устройства, либо внутренние значения. Доступны для чтения и записи. Диапазон адресов регистров: с 40001 по 49999. Имеют

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

    Примеры работы


    Для примера работы с протоколом Modbus TCP воспользуемся максимально простой консольной утилитой modbus-cli, написанной на языке Ruby. Она позволяет легко читать и писать данные в регистры Modbus.

    Попробуем прочесть состояние счетчиков переданных пакетов на промышленном коммутаторе Advantech EKI-5524SSI. Для начала необходимо определить адреса регистров, хранящие нужную информацию, для этого заглянем в документацию устройства. Описание регистров находятся в разделе «Modbus Mapping Table»:


    Описание значений регистров в документации коммутаторов EKI

    Видно, что значение переданных пакетов для одного порта хранится в четырех регистрах, и для первого порта это регистры с 38193 по 38197. Также дано описание формата хранения данных, из которого следует, что целое число переданных пакетов хранится шестнадцатеричном формате, и значение 11223344 пакетов будет записано как 0xAB4130, справа налево.

    Составим запрос:

    $ modbus read 192.168.0.17 38193 4
    38193   0x0000
    38194   0x0000
    38195   0x0000
    38196   0x3459
    

    read — команда чтения. Программа сама понимает, какую конкретно команду чтения использовать в зависимости от адреса регистра, в нашем случае будет использована команда «04», для чтения 16-битных регистров.

    192.168.0.17 — IP-адрес устройства.

    38193 — начальный адрес регистра.

    4 — смещение относительно начального адреса. Мы читаем четыре регистра для порта 1, как следует из даташита.

    Получаем ответ, содержащий значения четырех регистров. Видим, что число пакетов невелико: 0x3459, то есть 13401, — коммутатор был включен недавно.

    Недостатки протокола Modbus


    Справедливости ради, стоит упомянуть и о недостатках протокола. Так как он разрабатывался более 40 лет назад, когда производительность процессоров была существенно ниже и протоколы разрабатывались без учета защиты данных, он имеет рад минусов:

    • Протокол не предусматривает аутентификацию и шифрование передаваемых данных. Поэтому, при использовании Modbus TCP необходимо использовать дополнительные VPN-тоннели.
    • Slave-устройство не может инициировать передачу данных, поэтому master должен постоянно опрашивать ведомые устройства
    • Slave-устройство не может обнаружить потерю связи с Master. Эта проблема напрямую следует из предыдущей.

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

    Оборудование с поддержкой Modbus


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

    ADAM-6000 и WISE-4000 — модули удаленного ввода-вывода



    Модули серии ADAM-6000 и WISE-4000 позволяют удаленно управлять цифровыми и аналоговыми входами/выходами по протоколу Modbus TCP. Используются для управления периферийными устройствами и сбора данных в режиме slave. Могут работать в паре с программируемым логическим контроллером, или подключаться напрямую к SCADA-серверу.⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀

    EKI-1200 — Modbus-шлюзы для преобразования интерфейсов



    Для преобразования протоколов Modbus RTU/ASCII в Modbus TCP, используются Modbus шлюзы. Устройства серии EKI-1200 имеют на борту до четырех последовательных интерфейсов RS-232/422/485, и два Ethernet-порта. Они позволяют объединить в одну сеть устройства с разными протоколами. Например, подключить slave устройство, поддерживающее только Modbus RTU, по интерфейсу RS-485 к сегменту сети Modbus TCP.

    APAX-5000, ADAM-3600, WISE-5000 — контроллеры автоматизации


    Контроллеры поддерживают функции Modbus RTU в качестве slave/master и клиента/сервера Modbus TCP.



    Примеры применения


    Система мониторинга теплиц


    Решение Advantech для мониторинга интегрирует устройства TPC-1070H, ADAM-6024, ADAM-6050, ADAM-6060 и программное обеспечение WebAccess в машинном шкафу рядом с сельскохозяйственными угодьями. Соединяясь с различными чувствительными устройствами, модули ADAM-6000 могут в режиме реального времени получать данные об окружающей среде и контролировать переключение оборудования, чтобы гарантировать, что теплица находится в оптимальной среде для роста растений. Благодаря особой функции Advantech — графической логике условий (GCL), пользователи могут определять свои собственные правила логики управления и загружать эти правила в модули ввода / вывода Ethernet ADAM-6000, а затем модули автоматически выполняют логические правила, как автономные модули. контроллер. Еще одна особенность — Peer-to-Peer (P2P) использует наиболее открытую и гибкую сеть Ethernet, чтобы не только упростить процесс внедрения без контроллера, но и сэкономить затраты на аппаратное оборудование.

    Все полученные данные затем передаются через Ethernet на компьютер с сенсорной панелью TPC-1070H. Благодаря системе охлаждения без вентилятора и передней панели, соответствующей стандарту IP65, TPC-1070H представляет собой прочную и компактную конструкцию, подходящую для изменяемой операционной среды, а его мощные вычислительные возможности способны обрабатывать большие объемы данных. Для управления устройствами Advantech WebAccess позволяет инженерам или менеджерам просматривать, контролировать и настраивать систему мониторинга через интрасеть или Интернет с помощью обычного веб-браузера с любого устройства, включая планшеты и смартфоны.



    Мониторинг системы нагрева воды солнечной энергией


    Инжиниринговая компания должна была иметь возможность контролировать количество солнечной энергии, температуры и расход воды в системе нагрева воды на солнечной энергии для бассейна олимпийских размеров, обеспечиваемого их недавно разработанной солнечной панелью. Они также должны были иметь возможность непосредственно отслеживать эти значения и их аварийные сигналы на ЖК-панелях и сохранять эти значения для дальнейшего использования.

    Модули Adam от Advantech предоставили заказчику решение, в котором использовались модули сбора данных, подключенные через RS485, и двухпроводная шина для передачи данных со всех датчиков. Эта системная архитектура имеет два основных преимущества: во-первых, она позволяет в любое время добавлять в систему большее количество датчиков модулей сбора данных, и, во-вторых, очень легко добавлять дополнительные метки в программное обеспечение для мониторинга и записи этих значений на ПК.

    Advantech
    110,40
    Наша миссия — создание умной планеты.
    Поделиться публикацией

    Комментарии 34

      +1
      Добавьте еще один недостаток протокола Modbus.
      При работе в последовательной сети он требует назначение уникальных Slave ID для каждого ведомого устройства. И из-за этого у него определенные сложности с динамической конфигурацией сети (сложно выявить конфликт работы двух устройств с одинаковым Slave ID на одной последовательной линии связи).
        0
        Странно, кстати, почему не выпускают новый обратно совместимый стандарт лишенный этих проблем. Провижининг и передачу по инициативе slave можно было добавить, полагаю.
          0
          да как бы и полной совместимости иногда нет у разных производителей
            0
            совместимость хромает в основном у наших производителей, буржуи стараются придерживаться стандартов.
              0
              У буржуев иногда нет нужных параметров. Приходится брать Овен и писать половину на протоколе Овен, половину на Модбасе
                0
                Подскажите, а что приходится на ОВЕН писать?
                Конфигурируете модули по ОВЕН, а опрашиваете по Modbus?
                  0
                  смешано
                  В зависимости от того, что реализовано/нереализовано в каждом из протоколов.
                  Например, чтение показаний и статуса OwenUnpackError по Овен, а инициализация и записи в регистры по Модбасу.
        +1
        Всегда удивляла стоимость простых шлюзов для MODBUS.
        Как-то раз возникла необходимость удалённо мониторить некоторые контроллеры. Цена на простейшие преобразователи RTU (RS-485) -> TCP/IP для передачи данных на сервер просто сумасшедшая. 280$ за простейшую коробочку по ссылке из статьи. Отечественные производители не отстают.
        В итоге купил Orange Pi, шнурок rs485-USB и опциональный USB-модем. На github'е нашёл утилиту для преобразования RTU -> TCP. Для сбора данных, дашборда (с мобильным приложением даже) и графиками поднял сервер с OpenHAB. От силы потратил 50$ + 10$ в месяц за простейший сервер с OpenHAB и VPN.
        Нет, конечно, можно порассуждать о надёжности, безопасности и прочем. Но для простейшего кейса домашней автоматизации или мониторинга на этапе пуска-наладки какого-нибудь магазина/музея/школы этого решения хватает с горой. И колоссальная экономия.
          0
          для дома может быть, но для коммерческой эксплуатации другие требования к надежности, электроизоляции и т.д.
            0
            Не только. Важно также и малое время восстановления системы, и доступность комплектующих в течении продолжительного времени.
              0
              Для постоянного промышленного использования, т.е. когда диспетчеризация на года, то да. Но есть и кратковременные задачи, на которые так сильно раскошеливаться не согласится заказчик. Не только домашняя автоматизация.
            0
            я бы сказал что баксов 100-130, вот например непростой преобразователь, не сочтите за рекламу пожалуйста, а можно и намного дешевле найти, особенно если не смотреть изделия предназначенные для промышленного применения.
              0
              У всяких sbc есть важное преимущество — бОльшие возможности по доступу к сети. Тот же Orange Pi или сравнимый с ним имеет и Ethernet-порт, и wi-fi, и достаточно USB-портов, чтобы воткнуть модем. Это, кстати, тоже важный момент, так как зачастую от комнаты с оборудованием до ближайшего роутера может быть не проложен кабель, или интернета нет вообще и единственный вариант — мобильный интернет.
              +1
              Есть дешевые шлюзы. Вполне так промышленные от нормальных производителей можно найти за $80 (себе такой покупал), а уж китайцы тоже вроде промышленные на Алиэкспрессе вообще за $40.
                0
                Можно собрать свой шлюз на esp8266.
                github.com/MaxKravt/WiFi-Modbus-TCPtoRTU
              +1
              А можно еще один пример, на схеме условной простейшей схеме измерения температуры, от первичного преобразователя (скажем от выводов термопары) до контрол-рума — где и как появляются регистры.
                0

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

                  0
                  переварят, главное закрывать порт после завершения операции
                    0
                    Shpiler
                    Нет никаких проблем подключить разные протоколы типа «запрос-ответ», давно и успешно используем разнородные в плане протокола подключения где это обосновано. Только убедитесь, что запросы и ответы в Вашем протоколе не будут восприняты другими устройствами как запросные (корректные или не корректные — не суть). Для ModBusRTU достаточно, чтобы первый байт Ваших запросных и ответных посылок не совпадал с адресом ModBus-устройств (первый байт посылок) и не был бы широковещательным.
                      0
                      Для ModBusRTU достаточно, чтобы первый байт Ваших запросных и ответных посылок не совпадал с адресом ModBus-устройств (первый байт посылок) и не был бы широковещательным.
                      Вредный совет.
                      В протоколе Modbus начало передачи определяется паузой на линии. И если на одной и той же линии сидят устройства с какими нибудь бинарными протоколами, то вполне вероятна ситуация, когда Modbus устройство ловит паузу в бинарном протоколе и считает это моментом передачи мастера. Ну а дальше все зависит от везения.
                      Лучше реализовать расширение протокола Modbus (у него есть зарезервированные коды функций, которые можно использовать как раз для таких случаев). Уж если все равно нужно писать, но тут хоть будет гарантия от различных «неждачиков».
                        0
                        Вредный совет.

                        rsashka, не совсем так. Я не стал указывать на необходимость соблюдения таймаутов по причине того, что вопрос был о другом. Человек, реализовавший протокол ModBusRTU должен знать и о таймаутах. И хотя бы открывал wiki, где сказано:
                        Сообщения разделяются по паузе в линии. Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов.
                          0
                          паузу в бинарном протоколе
                          А бывают такие, что предполагают паузу внутри посылки? Даже не могу представить где это может иметь смысл.

                            0
                            А если у них протоколы разные, то почему скорости должны быть одинаковыми? ;-)
                              0
                              Ну, например, потому что так было задумано :)
                              картинки с примером
                              Все подчиненные устройства сидят на одном порту, соответственно параметры порта общие для всех подключенных к нему устройств. А вот адрес и таймауты — для каждого свои (а так же некоторые специфичные для протокола параметры — тоже свои). PS: на значения таймаутов и совпадение адресов не обращайте внимания, картинки только для примера.




                                0
                                Конечно, можно повесить на одну физическую линию устройства с разным протоколами. И можно так задумать, что будут разными не только протоколы устройств, но и скорости работы у разных классов устройст. Точно по этой же причине, «потому что так задумано» ;-)
                                Ведь смена скорости порта практически мгновенная операция, и причин для этого можно найти много (например для помехозащищенности, что бы скорость передачи могла подстраиваться в зависимости от внешних помех).
                                  0
                                  в теории, разные скорости можно использовать как расширение — по 255 устройств на каждой скорости (9600, 14400…)?
                                    0
                                    В теории можно, но лучше так не делать. Тем более при определленой разнице в скоростях, даже обычные символы низкоскоростных устройоств могут восприниматься как стартовые сигналы для высокоскоростных.
                                    Конечно, должно сложиться много условий (определенная комбинация данных или наведенная помеха), но ведь и не заряженное ружье иногда стреляет.
                                      0
                                      Я к чему это все веду. Зоопарк китайских устройств зачастую не имеет одинаковых скоростей, например, счетчик 100А 380В только 2400, а контроллер pt100 минимум 9600. Если поступать по правильному, то заводить на каждую скорость по отдельному порту, но ведь жаба?
                                        0
                                        Если честно, то я не встречал устройств, у которых не настраивается скорость передачи. Но если такое все же может быть. Ну что ж, если нельзя, но по другом никак, то значит можно ;-)
                                          0
                                          было, как раз с али оба экземпляра
                        +1
                        Если ваше устройство по своему хотению будет что-то передавать в сеть, то в Modbus это чревато непредсказуемыми коллизиями, т.к. мастер в этой сети, считает себя единственным инициатором передачи пакетов. В Profibus, например, передается маркер от мастера к мастеру на право передачи.
                        Лучше поддержку Modbus повесить. Для встраиваемых систем есть свободная библиотека Free Modbus. Я использую ее для своих проектов.
                        0
                        del
                          0
                          Еще есть hart прямо по токовой петле гоняет данные. Profibus где может быть куча мастеров по очереди. Да и шины типа can где все узлы могут периодически отсылать данные (для датчиков лучше чем modbus).

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое