Разработка Modbus PC/HMI для оборудования в России: регистры, аварийные сигналы и журналы

Проект Modbus PC/HMI для российского оборудования должен начинаться с одного базового интерфейса с контролем версий. Он должен записывать как номер регистра, отображаемый в руководстве, так и начальный адрес PDU, тип данных, порядок байтов в регистре, порядок слов в регистрах, масштабирование, единицу измерения, недопустимое значение, права доступа, обработку исключений, конечный автомат сигналов тревоги и поля корреляции журналов. Успешное соединение доказывает лишь то, что сообщения могут передаваться; это не доказывает, что значения, сигналы тревоги или контрольные журналы верны.

Компания Beijing Winge Technology Co., Ltd. предоставляет услуги по разработке промышленных ПК/ЧМИ, протокола Modbus и системной интеграции под названиями Winge Technology и Winge. Следующий материал поддерживает определение объема работ для команд в России; Текст и документы пользовательского интерфейса на русском языке являются языковыми ресурсами проекта и не меняют протокол устройства. Данная страница не претендует на наличие российского офиса, российских клиентов или реализованных проектов в России.

До разработки зафиксируйте входные данные и правила адресации

Укажите как минимум точную модель устройства, версию встроенного ПО, режим Modbus RTU или TCP, последовательные или сетевые параметры, адрес подчиненного устройства или идентификатор устройства, коды поддерживаемых функций, карту регистров, образцы кадров, блокировки записи и предполагаемый рабочий процесс. Спецификация Modbus определяет регистры как 16-битные слова и сначала отправляет старший байт для многобайтовых адресов и элементов данных. Порядок слов 32-битного значения, охватывающего два регистра, его масштаб, единица измерения и бизнес-значение все равно должны быть подтверждены из документации устройства. Адреса PDU начинаются с нуля, тогда как в руководстве к устройству может быть указана другая нумерация; запишите оба вместо того, чтобы выводить адрес из обозначений, таких как «40001».

Таблица интерфейсов регистров, аварийных сигналов и журналов

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

Область интерфейса	Поля, требующие подтверждения	Подтверждение приемки
Подключение и адресация	режим RTU/TCP; параметры последовательного порта или сети; адрес ведомого устройства или Unit Identifier; код функции; номер из руководства; начальный адрес PDU; непрерывный диапазон чтения	Сохранить конфигурацию, исходные запросы и ответы; подтвердить соответствие отображаемых номеров фактическим смещениям в сообщениях
Данные регистров	Coil, Discrete Input, Input Register или Holding Register; целое со знаком или без знака, float или текст; количество, порядок байтов, порядок слов, масштаб, смещение, единица, недопустимое значение и права чтения/записи	Сопоставить исходные 16-битные слова, объединенные и инженерные значения с известными входами; отдельно записать границы, отрицательные значения и маркеры недействительных данных
Опрос и запись	интервал опроса, группировка чтения, тайм-аут, повторные попытки, число одновременно подключенных устройств, роль записи, блокировка, контрольное чтение и состояние по умолчанию после перезапуска устройства	Записать частоту запросов, тайм-ауты и переподключения; проверить авторизацию, блокировки, ответ на запись, контрольное чтение и восстановление после отключения питания
Исключения протокола и состояние связи	Отсутствие ответа, ошибка CRC или кадра, разрыв соединения, устаревшие данные и ответы об исключении с использованием исходного кода функции плюс 0x80 и кода исключения; определить состояние пользовательского интерфейса и политику повторных попыток отдельно	Инъецировать недопустимую функцию, адрес и значение, тайм-аут и разрыв соединения; проверить исходные кадры, флаги качества, число повторных попыток и конечное состояние
Конечный автомат аварийных сигналов	поле-источник, условие срабатывания, приоритет, задержка или подавление дребезга, состояния «активен», «подтвержден», «восстановлен» и «подавлен», источник времени и ключи ресурсов для русского и других языков интерфейса	Последовательно проверить нормальное состояние, срабатывание, подтверждение, восстановление и дребезг; сопоставить интерфейс, таблицу событий и записи уведомлений
Журналы и отслеживаемость	Идентификатор корреляции, идентификатор устройства и соединения, код и адрес функции, необработанный кадр или исключение, декодированное значение, пользователь и роль, версии программного обеспечения и прошивки, временная метка, часовой пояс и кодировка экспорта.	Проследить действие в интерфейсе через транзакцию Modbus, переход аварийного сигнала и результат; воспроизвести цепочку из экспорта по идентификатору корреляции, скрыв учетные данные и чувствительные поля

Слои программного обеспечения, результаты работ и приемка

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

Приемка должна охватывать штатное чтение и запись, а также инъекцию отказов на согласованном устройстве или взаимно принятом симуляторе: недопустимую функцию, адрес и значение, тайм-аут, ошибку последовательного кадра, разрыв и восстановление соединения, устаревшие данные, дребезг аварийного сигнала, подтверждение и восстановление, несанкционированную запись и перезапуск устройства. Интервал опроса, число устройств, длительность прогона, допуск синхронизации времени и допустимые расхождения данных фиксируются в базовой версии проекта. Успешная проверка на симуляторе не заменяет проверку целевого устройства и полевого канала связи.

Язык и условия развертывания проекта в России

Для передачи российскому проекту подтвердите объем документа на русском/английском языке, список терминологии пользовательского интерфейса, кириллицу для отображения и ввода, кодировку CSV или отчета, форматы даты, чисел и единиц измерения, часовой пояс проекта, целевую версию Windows/Linux и границу между удаленной и локальной интеграцией. Ответственные стороны должны подтвердить условия кибербезопасности, удаленного доступа, отраслевых разрешений и другие условия соответствия для фактического места развертывания из текущих первичных источников. На этой странице не делается никаких предположений о российских правилах, сертификации, налогах, времени доставки или местной поддержке.

Часто задаваемые вопросы

Если в руководстве устройства указано 40001, должно ли приложение запрашивать адрес 40001?

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

Что следует проверить в первую очередь, если регистр можно прочитать, но значение неверно?

Проверьте смещение регистра, тип данных, знак, порядок байтов в каждом регистре, порядок слов в регистрах, масштаб, смещение, единицу измерения и соглашение о недопустимых значениях. Затем сравните необработанные 16-битные слова и объединенное значение с известным вводом или дисплеем устройства. Успех коммуникации не подтверждает семантику поля.

Как следует связать исключения Modbus, сигналы тревоги оборудования и журналы операций?

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

Связанные услуги, опубликованный пример и спецификации

Спецификации организации Modbus и руководства по внедрению: проверьте имеющиеся в настоящее время руководства по прикладным протоколам и последовательным линиям.

Спецификация прикладного протокола Modbus V1.1b3: проверьте модель данных, кодировку, адресацию, функциональные коды и ответы на исключительные ситуации.

Разработка протокола Modbus RTU/TCP: просмотрите существующие входные данные службы Winge, результаты и объем приемки.

Пример PC-приложения для промышленного энкодера и двух протоколов STM32: использовать только опубликованные границы PC-приложения, диагностики связи, журналов событий и поставки; не делать выводов о совместимости с Modbus или опыте проектов в России.

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