Счетчики электроэнергии, управляемые вентили и задвижки, расходомеры, датчики вибрации, устройства телемеханики.
Все, что может генерировать данные или управляться удаленно и имеет интерфейс RS-232, RS-485 и RS-422 — работает через данные преобразователи.
Общий смысл их использования — обычно заключается в следующем: пробросить интерфейсы RS-232,RS-485 и RS-422 через существующую локальную сеть, подключить устройство или прибор имеющий один из последовательных интерфейсов к ПК (серверу, SCADA) через Ethernet, подключится к прибору имеющему последовательный интерфейс через Internet для удаленного управления и т.п.
Цены на данные преобразователи не сильно высоки, младшие модели можно взять за 100-200$. Но учитывая что на любом автоматизированном производстве таких устройств может быть установлено сотни а то и тысячи — вырисовывается довольно лакомый кусочек для отечественных «импортозамещальщиков».
Им то я сегодня и попытаюсь помочь.
Что будем делать?
Во первых — разберемся в теории, как оно устроено внутри
Во вторых — вычленим минимальный функционал для запуска работы в режиме Real Com Mode (то есть по сути для проброса виртуального COM порта до устройства через Ethernet)
В третьих — ради интереса разберем протокол поиска и конфигурирования устройства через утилиту NPort Administration Suite. Получим полное понимание, как создать pin-to-pin аналог железки, которую можно воткнуть вместо существующей MOXA Nport при этом получив полную поддержку со стороны родного ПО и драйвера.
Ну и на последок — попробуем посчитать, сколько индусов писало код прошивки MOXA.
Часть 1. Вводная
Итак, у нас на столе подопытный (на самом деле их было несколько, поэтому не удивляйтесь если увидите в статье различные идентификаторы моделей и различные MAC адреса)
На нем есть порт Ethernet и два порта RS-422/RS-485 — это физически.
А в программном плане — на устройстве открыты:
UDP порт 4800 — он отвечает за ловлю пакетов поиска устройства и отдает данные о самом устройстве в утилиту конфигурирования.
TCP порт 4900 — на него приходят команды конфигурирования устройства. Через этот порт настраивается время устройства, имя, IP адрес, режим работы, скорости и настройки портов и прочие базовые параметры, которые можно настроить через основной интерфейс утилиты NPort Administration Suite
TCP порт 80 — отвечает за работу WEB интерфейса
TCP порты 966, 967, (и 968, 969 у 4х портовых устройств) — это порты управления передачей. По ним бегают команды открытия/закрытия соответствующего COM порта, установка скорости порта, проталкивание данных, мониторинг заполненности буфера передачи / приема и тд. Порт 966 отвечает за работу первого порта соответственно.
TCP порты (по умолчанию) 950, 951, (и 952, 953 у 4х портовых устройств) — это порты непосредственной передачи данных. То есть то, что непосредственно должно оказаться на RS-232/485/422 порте у устройства — передается в данные порт. Только данные, управление потоком в данном порту идет по 966, 967, 968, 969 портам соответственно.
Надеюсь общая картинка понимания работы устройства в голове сложилась. Давайте перейдем к следующей части:
Часть 2. Эмулируем MOXA
Наверняка многим уже стало понятно, что для того чтобы прикинутся MOXA Nport в минимальной конфигурации — необходимо на своем железе поднять TCP сервер на 2х портах: 966 для управления передачей и 950 для непосредственно передачи данных. Естественно придется корректно отвечать и обрабатывать запросы драйвера по 966 порту, но как показал анализ средствами wireshark — запросов не так много и они простейшие.
Дабы не перегружать текст статьи выкладками с описанием запросов и ответов — подготовил и выложил отдельно в виде pdf файла описание всех разобранных запросов, ответов и передаваемых параметров.
Скачать: Описание разбора протокола MOXA.pdf
То есть данный набор знаний позволяет реализовать устройство, которое может работать в паре с родным драйвером и передавать данные как MOXA. Половина работы выполнена, но есть один момент — как поменять конфигурацию? Было бы здорово использовать для этих целей родную утилиту NPort Administration Suite.
Часть 3. Ищем и находим
В первых двух частях было описано что нужно сделать, но ни слова не было о том, как получить данные для реализации протоколов.
В этой части копнем немного глубже и посмотрим, как же проводился анализ самого обмена.
Мы знаем, что на устройстве открыт UDP порт 4800, давайте подключим устройство, запустим NPort Administration Suite, Wireshark и посмотрим что происходит при поиске устройств родной утилитой.
Смотрим отправленные пакеты
Видим, что NPort Administration Suite отправляет бродкаст на адрес 255.255.255.255 то есть надеется, что пакет разлетится по всей сети.
В payload пакета содержатся данные
01 00 00 08 00 00 00 00, где:
01 00 – код функции
00 08 – размер пакета в байтах в формате Big Endian.
00 00 00 00 – не определено
Данный запрос отправляется несколько раз, видимо в надежде что хотя бы один из них достигнет цели.
На данный запрос отзываются все MOXы.
Конкретно наша ответила:
81 00 00 18 00 00 00 00 12 03 00 80 32 03 00 90 e8 26 4a ab c0 a8 7f fe
81 00 – код функции
00 18 – размер пакета в байтах (24)
00 00 00 00 – не определено
12 03 00 80 32 03 – модель MOXA Nport device, в данном случае NPort 5232. Данная величина является константной для конкретной модели MOXA Nport device. Значение должно соответствовать одному из пунктов списка из справочника NPort Administrator.
00 90 e8 26 4a ab – MAC адрес MOXA Nport device
c0 a8 7f fe – IP адрес MOXA Nport device ( 192.168.127.254 )
Вроде все элементарно просто, смущает только значение 12 03 00 80 32 03, отвечающее за интерпретацию конкретной модели устройства.
Но, так как данное значение сверяется с каким то эталонным справочным — значит оно должно где то хранится.
Немного изучив директорию с ПО — находим, что в NPort Administrator Suite v1.22 данные значения хранятся в файле C:\Program Files\NPortAdminSuite\bin\dsci.dll
Посидев с Wireshark и устройством несколько дней — получаем полный лог обмена и понимание какие коды функций что получают в ответ. Для удобства восприятия — все найденное описано в том же pdf файле, ссылка на который указана в статье ранее.
Для полноты понимания картины — лишь напомню, что по UDP 4800 идет получение первичных сведений о устройстве, все параметры которые требуют настройки и установки — настраиваются посредством запросов на TCP порт 4900.
Правильно обработав все поступающие запросы на 4800 и 4900 порты — мы сможем полноценно прикинуться устройством, так что даже родное ПО не заметит подвох.
Часть 4. Считаем индусов*
В ходе анализа протокола — меня не покидало ощущение, что различные куски протокола обмена писали разные люди, слишком отличаются значения функций и их интерпретации.
Так например:
UDP порт 4800 коды функций начинаются с:
Запрос 01 00 .. ..
Ответ 81 00 .. ..
Запрос 10 00 .. ..
Ответ 90 00 .. ..
Запрос 16 00 .. ..
Ответ 96 00 .. ..
Запрос 29 00 .. ..
Ответ a9 00 .. ..
TCP порт 4900 коды функций начинаются с:
Запрос 00 01 .. ..
Ответ 00 01 .. ..
Запрос 02 01 .. ..
Ответ 02 01 .. ..
и тд
TCP порты 966, 967, 968, 969 коды функций начинаются с:
Запрос 10 .. ..
Ответ 10 4f 4b
Запрос 11 .. ..
Ответ 11 4f 4b
и тд
То есть используется уже одно байтовый идентификатор функции, а не двухбайтовый как ранее.
Тут кстати вылез забавный момент. По портам 966, 967, 968, 969 ответ на установку параметров всегда состоит из 3х байт.
Первый — это номер функции, а остальные 2 это 4f 4b или есть посмотреть в таблицу ASCII — «O» «K»
Ну OK с ним, идем далее.
Вторая замеченная особенность — мешанина Big и Little Endian в пределах одного ответа.
Пример ответа:
9a 00 00 24 00 00 00 00 01 52 00 80 9a 52 00 90 e8 3b 89 9c 75 00 04 00
01 00 0f 00 09 00 17 00 36 00 00 00
9a 00 – код функции
00 24 – размер пакета в байтах (36)
00 00 00 00 – не определено
01 52 00 80 9a 52 – модель MOXA Nport device
00 90 e8 3b 89 9c - MAC адрес MOXA Nport device
75 00 - год: 1900 + данное число (1900 + 117 = 2017)
04 00 - месяц: к числу нужно прибавить 1 - в данном случае май
01 00 – не определено
0f 00 – день (15)
09 00 – часы (9)
17 00 – минуты (23)
36 00 – секунды (36)
00 00 – не определено
Размер пакета кодируется одним образом, а все числовые значения (год, месяц, день ...) другим. Отсюда можно сделать вывод, что обработку пользовательской части начиная с 75 00 04 00…… писал другой программист.
Подведем итог: Минимум 3 разных человека писали протокол обмена, 1 писал обработку пользовательской части данных и еще как минимум 1 писал обработчик WEB интерфейса. По моим подсчетам над проектом трудилось примерно 5 программистов.
А сколько насчитали вы?
*Под понятием «Индус» в данном случае подразумевается наемный работник, выполняющий свои обязанности за еду и ипотеку, способный кодить отсюда и до обеда не особо вникая в глобальные планы компании работодателя.
PS Данная статья написана по материалам, которые были в проработке в 2017 году, поэтому многие данные содержат датировку именно этим годом. Протоколы разбирались в рамках рабочего проекта, но благо разум победил над маркетингом и дело не пошло дальше стадии единичного рабочего прототипа. Публикую все наработки по данному проекту в открытом доступе, так как считаю что данная информация будет полезна сообществу разработчиков.
PPS Оригинал статьи как всегда в моем личном блоге
Комментариев нет:
Отправить комментарий