Эта штука, концентратор Меркурий-225.2, предназначена для сбора данных с электросчетчиков того же производителя, передаваемых по силовым проводам по протоколу PLC-II. (Как-то я до сих пор не знаю, базируется ли этот протокол на каком-либо стандарте. Хотелось бы верить.)
Концентратор доступен по rs-485 или по USB. Во втором случае это тот же самый последовательный интерфейс, только через преобразователь FTDI. Проблем с физическим подключением никаких — поддержка FTDI давно есть и во FreeBSD, и в линуксах.
Интересно, что помешало прикрутить ethernet и какой-нибудь внятный протокол. Странные люди, сами лишают себя приличной аудитории.

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

Исходные данные: подключены три концентратора с адресами 3186, 3169, 319E. Именно в такой последовательности. Адреса написаны на бумажках, наклеенных на копуса устройств.
Для эксперимента используется штатная программа Netmonitor версии 2.2.rc2. Питание подано только на первый в цепочке концентратор, остальные висят мертвым грузом. В конфигурации Netmonitor прописаны все три устройства, поэтому он будет пытаться получить доступ ко всем концентраторам.
Где-то в силовой сети висит счетчик M203.2T LBO, имеющий адрес 05301037, также прописанный в конфигурации Netmonitor.

Запрос:02.11.2009 21:43:28.34964 (+1040.2344 seconds)

75 C6 CC FF FF 86 31 01 80 7F
Первые три байта — crc24 (проверено соответствующим алгоритмом из документации, все так и есть. Кстати, тоже младший байт впереди)
Потом идут два байта адреса хоста. Почему-то FFFF
Далее два байта адреса первого концентратора (3186), как и обещяно — младшим байтом вперед.
01 — длина пакета
Заголовок кончился — как и написано в доке — 8 байт.
80 — команда Чтение конфигурации
7F — контрольная сумма пакета (в данном случае 80 — 1)

Ответ:02.11.2009 21:43:28.38064 (+0.0313 seconds)

EF 8E 1D 86 31 FF FF 02 80 08 87
Все то же самое, только сначала идет адрес устройства, а потом адрес хоста.
Пакет имеет длину 2 байта.
80 — повтор команды
08 — результат. В данном случае это байт конфигурации.
87 — контрольная сумма пакета (80+08-1)

Запрос:02.11.2009 21:43:28.44264 (+0.0625 seconds)

16 1E B3 FF FF 69 31 01 80 7F
65 72 D6 FF FF 9E 31 01 80 7F
Это два аналогичных запроса к двум оставшимся концентраторам. Ответов на них нет — приборы выключены.

Следующий запрос к живому концентратору:
75 C6 CC FF FF 86 31 01 1D 1C
1D — очистка регистров концентратора. Netmonitor в этом месте вываливает окно с предупреждением.
Не очень понятно, зачем это нужно. Надеюсь, в дальнейшем проясниться.

Ответ:02.11.2009 21:43:28.16164 (+0.0938 seconds)

19 17 11 86 31 FF FF 01 1D 1C
Концентратор подтвердил выполнение команды.

Запрос:02.11.2009 21:43:29.47464 (+0.3125 seconds)

83 5F C0 FF FF 86 31 02 90 00 8F
90 — просим от концентратора списки подчиненных узлов (счетчиков, стало быть)
00 — номер страницы списка (в соответствии с документацией, концентратор отдает списки страницами, длиной до 32 адресов по 4 байта каждый. То есть страница может иметь длину от 0 до 128 байт, кратную 4-м)

Ответ:02.11.2009 21:43:29.53664 (+0.0625 seconds)

0E 68 8E 86 31 FF FF 06 90 00 37 10 30 05 0B
90 00 — повтор команды с адресом страницы.
37 10 30 05 — а вот и наш счетчик младшим байтом вперед (05301037)
0B — контрольная сумма (90+00+37+10+30+05-1) && 00FF — похоже

Запрос:02.11.2009 21:43:29.84964 (+0.3125 seconds)
75 C6 CC FF FF 86 31 01 80 7F
Опять запрос байта состояния
Ответ:02.11.2009 21:43:29.88064 (+0.0313 seconds)
EF 8E 1D 86 31 FF FF 02 80 08 87

Запрос:02.11.2009 21:43:29.94264 (+0.0625 seconds)
16 1E B3 FF FF 69 31 01 80 7F
65 72 D6 FF FF 9E 31 01 80 7F
Нет ответа от выключенных концентраторов

Запрос версии прошивки концентратора (код 83)
75 C6 CC FF FF 86 31 01 83 82

Ответ:02.11.2009 21:43:30.84964 (+0.0313 seconds)
5F 41 79 86 31 FF FF 1A — заголовок ответа
Тело ответа длиной 26 байт (1A) + контр.сумма 1 байт
83 64 63 20 76 2E 30 2E 35 72 63 34 20 EE F2 20 32 32 2E 30 37 2E 32 30 30 38 BA
dc v.0.5rc4 от 22.07.2008
(в кодировке cp1251 !)

Запрос:02.11.2009 21:43:31.58364 (+0.7344 seconds)
75 C6 CC FF FF 86 31 01 81 80
81 — запрос времени/даты

Ответ:02.11.2009 21:43:31.61464 (+0.0313 seconds)
DB DA 36 86 31 FF FF 08
81 1B 2F 17 00 01 0A 09 F5
1B — сек.
2F — мин.
17 — часы
00 — день недели (понедельник)
01 — день (-1)
0A — месяц (-1)
09 — посл. две цифры года
То есть: 2009-11-02 23:47:27

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

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

В следующей серии — анализ протокола концентратора при считывании данных со счетчика.

 

4 Responses to Протокол концентратора Меркурий-225.2

  1. boangri:

    Что используется в качестве снифера послед. порта?

  2. admin:

    Free Serial Port Monitor v.3.31 HHD Software
    под виндами
    Это первое, что под руку попалось.

  3. Евгений:

    Здравствуйте!
    Подскажите пожалуйста как использовали код на C, который приводится для расчета CRC24, что именно писали вместо аргументов *octets и len.

    Проблема следующая пытаюсь разобраться в коде CRC24 генерируемого концентратором 225.11, который работает по технологии PLC-I. Использовал предоставленный код, как только не извращался, значения CRC так и не сходятся. Хочу понять что и как записывается в аргументах функции crc_octets.

  4. alid:

    Могу поделиться наработками, на которых в свое время остановился (мы остановились на проводном варианте). Там много что еще доделывать надо, но контрольная сумма считалась правильно.

Добавить комментарий

Set your Twitter account name in your settings to use the TwitterBar Section.