Обновление прошивки устройств при помощи стандарта Modbus

В настоящее время в рамках оптимизационных мероприятий в энергосистемы внедряется все больше цифрового оборудования. Коммерчески доступное и цифровое оборудование часто случаях имеет последовательный интерфейс Modbus RTU для подключения к локальному контроллеру, который, в свою очередь, взаимодействует с бэкэндом или системами SCADA через мобильную сеть связи.
Однако для массового управления цифровым оборудованием важным является возможность обновления прошивки. В настоящее время такая функция недоступна для оборудования с интерфейсом Modbus RTU из-за отсутствия стандарта.
Концепция обновления прошивки через Modbus RTU, представленная в статье, является де-факто стандартом Alliander и доступна для внедрения и использования всеми производителями. В статье рассматривается open-source подход.

Случай, который рассматривается в статье - это ситуация, когда необходимо обновить прошивку подключенного устройства Modbus. Процесс обновления прошивки использует тип связи «master/slave» через последовательный интерфейс RS-485. Шлюз является master-устройством Modbus, а устройство Modbus - slave. Прошивка устройства Modbus представляет собой двоичный файл, который создается производителем, он доступен на шлюзе. Шлюз должен доставить двоичный файл устройству Modbus. После получения двоичного файла устройство Modbus проверит и активирует новую прошивку. На рисунке ниже эта концепция представлена ​​в виде UML-диаграммы.

Стандарт Modbus является регистро-ориентированным, поэтому передача файла по протоколу Modbus фактически представляет собой передачу данных путем записи в регистры хранения. Поскольку двоичный файл прошивки может быть достаточно большим, передача файла будет осуществляться циклически, блок за блоком. Каждый блок представляет собой фрагмент файла, ограниченный максимальным размером полезной нагрузки кадра Modbus в 246 байт. Шлюз записывает блоки данных в регистры, а устройство Modbus собирает их для создания исходного двоичного файла.

Весь процесс обновления прошивки контролируется с помощью записи управления обновлением прошивки (Firmware Upgrade Control Record) и записи состояния обновления прошивки (Firmware Upgrade Status Record), в которые шлюз записывает команды управления, а устройство Modbus сообщает о своем состоянии. Обратите внимание, что, поскольку Modbus является протоколом типа «master/slave», шлюз должен запрашивать у устройства Modbus его состояние, считывая, таким образом, регистр состояния обновления прошивки на устройстве Modbus.

Целостность данных в двоичном файле имеет решающее значение и проверяется на двух уровнях. Протокол Modbus предоставляет команду записи блока с кодом функции 16 (шестнадцатеричное значение: 0x10) с проверкой целостности с помощью 2-байтовой CRC на каждый фрейм. Таким образом, проверяется каждый фрейм. Для устройства Modbus настоятельно рекомендуется окончательная проверка целостности всего двоичного файла, она также может включать проверку подлинности с помощью цифровой подписи.

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

В данной концепции используются общие блоки данных Modbus ADU (Application Data Unit) для последовательных линий с блоками данных PDU (Protocol Data Unit), использующими два функциональных кода: 03 (0x03) для чтения нескольких регистров хранения и 16 (0x10) для записи нескольких регистров хранения.

Шлюз управляет процессом на устройстве Modbus с помощью Firmware Upgrade Control Record (записи управления обновлением прошивки), которая состоит из записи в три регистра хранения Modbus на устройстве Modbus, начиная с предопределенного адреса <fw_ctl_writing_address>. Она имеет структуру, показанную ниже.

Обращаем внимание, что отправка команды фактически означает запись в три регистра с кодом функции 16 (0x10), начиная с адреса <fw_ctl_writing_address>. В этой концепции адрес по умолчанию равен 0x4200, но может быть сконфигурирован в зависимости от возможностей устройства Modbus.

Шлюз проверяет состояние устройства Modbus с помощью Firmware Upgrade Status Record (записи о состоянии обновления прошивки), считывая три регистра хранения Modbus на устройстве Modbus, начиная с предопределенного адреса <fw_ctl_reading_address>.
Он имеет структуру, показанную ниже.

Запрос состояния через регистр управления обновлением прошивки фактически означает запрос на считывание трех регистров с кодом функции 3 (0x03) по адресу <fw_ctl_reading_address>. В этой концепции адрес по умолчанию равен 0x4210, но может быть сконфигурирован в зависимости от возможностей устройства Modbus.

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

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

Например, после очень короткой (автоматической) проверки в конце состояния DATA RECEIVE устройство может перезагрузиться и вернуться в состояние ACTIVATED или IDLE (нормальный режим работы). Выбор наилучшей стратегии будет зависеть от производителя.

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

Firmware Upgrade Data Record (запись данных обновления прошивки) используется шлюзом для записи фрагментов двоичного файла в виде блоков данных на устройство Modbus. Она определяется как блок Modbus, содержащий регистры на устройстве Modbus, с начальным адресом <fw_data_address> (предопределенное значение по умолчанию: 0x4300). Она имеет структуру, показанную ниже, и используется только для записи данных со шлюза на устройство Modbus с кодом функции 16 (0x10).

Весь блок данных, состоящий из N слов, передается как один фрейм. Блок данных Modbus (PDU) содержит функциональный код (0x10), начальный адрес <fw_data_address>, количество регистров хранения Modbus N+2, размер в байтах (2N+4), а также указатель файла и блок данных (см. таблицу выше). Максимальный размер для N составляет 121, то есть 242 байта.

Указатель файла - это счетчик байтов (32-битное беззнаковое целое число) двоичного файла на стороне шлюза, а также служит уникальным идентификатором пакета на устройстве Modbus. Он начинается с 0x0000 и увеличивается на 2N после каждой успешной передачи блока данных. Размер блока данных в байтах всегда равен 2N, за исключением последнего. Если размер файла нечетное число байтов, последний регистр PDU содержит один байт значимых данных (MSB) и один байт фиктивных данных, т.е. 0x00. Устройство Modbus знает размер и игнорирует этот байт.
После получения подтверждения без ошибок (ACK) от устройства Modbus шлюз должен запросить у устройства Modbus информацию о состоянии, используя запись состояния обновления прошивки.

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

Кроме того, протокол Modbus требует, чтобы каждый фрейм, отправленный master-устройством, приводил к ответу от slave-устройства.

Если такой ответ не возвращается в течение временных ограничений реализации Modbus (так называемый тайм-аут), в рамках этой концепции рекомендуется, чтобы шлюз проверял количество полученных байтов на стороне устройства Modbus и действовал соответствующим образом.
Количество повторений, допустимых в случае возникновения тайм-аутов или ошибок CRC более одного раза подряд, зависит от реализации и может быть задано. Рекомендуется установить одно повторение в качестве значения по умолчанию.

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

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

Теплообменник локально подключен через последовательный интерфейс Modbus RTU к локальному шлюзу. Шлюз использует мобильную связь для подключения к бэкэнд-системам, размещенным в облачной среде.
Операторы бэкэнд-систем отслеживают параметры и собирают данные измерений (давление, температура, расход, положение клапана и т. д.). При необходимости операторы адаптируют управление, настраивают устройство и периодически обновляют прошивку шлюза и прошивку теплообменника.

В свою очередь, команда ЦПР РТСофт создает промышленное ПО, которое решает реальные производственные и экономические задачи вашего предприятия. У нас большой опыт работы в том числе и в электроэнергетике, металлургии и нефтехимии: делаем дизайн и интеграцию эффективных программных решений для промышленных компаний и корпораций.
Если у вас возникают задачи по интеграции разных систем управления, переходу на открытые архитектуры или обеспечению совместимости оборудования от разных производителей, напишите на почту info@list.dev.rtsoft.ru - и мы обязательно постараемся помочь вам с решением.