Добрый день, коллеги и хабровчане!

В практике инженера АСУ ТП диагностика интерфейса RS-485/422 обыденное дело. Но что делать, если удаленный опрос приборов учета лег, линии прозвонены, сеть работает а связи все равно нет? Рассказываю реальный кейс о том, как из-за невнимательности при первичной диагностике мы перепутали подключение COM-портов, и что в итоге получилось.

Проблема

У нас в эксплуатации находится система учёта энергоресурсов на 1000+ приборов. Парк оборудования очень разношёрстный: Satec EM133, Satec PM175, Satec BFMII, СЭТ-4ТМ, Меркурий 234, ТЭМ-104, ВИС.Т, СТД(ВТД), различные импульсные вычислители, датчики давления, температуры, протечки - настоящий зоопарк. И всё это хозяйство необходимо постоянно поддерживать в работоспособном состоянии, чем и занимается инженер "асушник".

В один прекрасный осенний день приходит к нам инженер группы энергоучёта и говорит, что не может достучаться до приборов учёта электроэнергии, расположенных на трансформаторной подстанции 6/0,4 кВ (далее пусть будет ТП-100 для красоты). Приборы установлены на высокой стороне. У ТП-100 есть высокая и низкая сторона: 6 кВ и 0,4 кВ соответственно. Мы, как ответственные работники, принимаем вызов и обещаем разобраться.

Итак, имеем полную потерю удаленного доступа к приборам учета ТП-100. Сразу оговорюсь, что наша система учёта не относится к системам управления: никакого удалённого управления и риска для здоровья обслуживающего персонала тут нет. Наш учет на 90% технический, и всего 10% приборов - коммерческие. Для группы учёта доступ к приборам нужен два раза в месяц : 1 и 15 числа. Времени у нас было достаточно.

Фиксируем проблему: нет данных с приборов учета и доступа к сетевому оборудованию. 

Первые действия

За годы работы выработался механизм решения проблем такого рода, по нему мы и пошли:

1. Пропинговать устройства:

Пример - ping "норм":

Пример – ping "не норм":

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

Проверка на месте

На месте проводим тривиальные действия:

1. Проверка индикации

2. Проверка соединения кабельных линий

3. Проверка акб/ибп

4. Проверка питания

5. Проверка целосности кабельных линий (визуальная)

6. Проверка, есть ли питание на приборах учета

7. Потыкать COM-порты (как оказалось позже, это была ошибка)

Фото расключения MOXA NPort IA5450A

После локальной проверки все было нормально, пациент жив, и даже дышит. Дальше нужно было проверить внешнюю сеть ЛВС (локальную вычислительную сеть), а именно - работоспособность порта на коммутаторе и кабель от преобразователя интерфейсов MOXA NPort IA5450A до этого самого коммутатора (у нас там, вроде, стоит Cisco).

Так как ЛВС находится в ведении IT-службы, направили им запрос. Вызов принят. Первичная проверка показала, что наш порт на коммутаторе неактивен. Выяснилось, что после каких-то своих регламентных работ айтишники просто отключили порт. Порт подняли.

Проверяем ping - пошел! Мы уже радостно потирали руки, но после тщательной проверки удаленного доступа к приборам выяснилось, что две из трех линий связи так и не ожили. То есть часть учета работает, а часть нет. Не работали линии, которые подключены к 2 и 3 COM-порту. 

Проверка линий трафика

Как вы поняли, мы опять собрались на ТП-100, чтобы уже решить это вопрос. Первичный скрининг всего сетевого оборудования ничего не показал. Все исправно. Хорошо. Решили дополнительно проверить, а что там с трафиком через преобразователь интерфейсов, который по сути просто заворачивает старичка Modbus RTU в TCP - пакет и после пробрасывает в ЛВС

Скрин трафика портов:

Что мы видим? Данный скриншот сделан уже на работающем устройстве (скрин без трафика я, к сожалению, не сохранил). Тогда же мы видели в меню Monitor -> Async для 2 и 3 портов следующую картину: TxCnt растет (трафик уходит), а в RxCnt - по нулям (ответа нет).

Это была наша первая ошибка. Было очевидно, что сервер опроса честно отправляет запросы (TxCnt), а прибор учета не отвечает (RxCnt нет). Стоило задуматься, но мы благополучно пропустили этот момент.

Отдельно уловили интересный момент при работе прибора Satec EM133. Они имеют информативную индикацию работы опроса/ответа Rx/Tx, понаблюдав за которой, становится понятно, что NPort он же master шлет команды от сервера, а slave он же прибор молчит, индикация  Rx не горит. Вот тут был уже второй явный сигнал, что сервер опрашивает приборы, а они не отвечают. Но мы опять это упустили.

Гипотеза об обрыве кабеля

Тут у меня появились первые подозрения, что опрос идет, Tx индикация активности мигает каждые 10 секунда в соответствии с настойками опроса. Появилась гипотеза, что одна из жил неисправна. В этот же день на ТП-100 работали электрики из электроизмерительной лаборатории, и нас доблестно пригласили поковырять свои линии и проверить свои гипотезы. Все допуски были получены.

Мы захватили свой NETcat Pro2 для позвонки витой пары. Прозвонка состояла из следующих действий: закорачивали жилы на одном конце, и при подключении тестера, он должен показывать это закорачивание, а если не показывал значит где-то обрыв между тестером и концом линии. Ка́бель (шлейф) идущий к приборам мы откинули. Если откидываете шлейф, помните, что магистраль остается целой и тестер покажет полную длину. Он и увидел закорачивание, что логично.

Схема подключение приборов (подключение шлейфом) учета: 

Фото распаячной коробки (XR4). Тут мы закорачивали жилы.

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

Очень странно. Имеем обрыв между шкафом и первой коробкой на длине около 6 метров. Тут вступает в дело начальник той самой электроизмерительной лаборатории, человек опытный. Говорит нам, ну-как дайте я проверю своим " флюком" (fluke 17). Ищет землю и подключается. Результат тот же, обрыв на участке между шкафом и первой коробкой.

Затем он задает вопрос: а вы уверены, что закорачиваете именно тот кабель, который измеряете? Так как мы все перепробовали, решили проверить его теорию. Начали мерить другой кабель, и о чудо, тестер показал замыкание жил. Тут у меня в голове начали появляется флешбеки:

-> .... не горящая лампочка Rx, горящая Tx

-> .... на одно линии висят приборы Satec EM133 на другой - СЭТ-4ТМ

-> .... а скорость (боды) у них разная: 19200 и 9600

Появилась мысли, а что, если COM-порты просто перепутали местами? Поменяли COM-порты. Работает. Похоже, когда делали первичный скрининг, перепутали подключение COM-портов.

Конфигурации скорости портов:

2 и 3 порты были перепутаны местами. Естественно, ответы мы не получили: для прибора Satec EM133 скорость составляет 19200 бод, а для СЭТ-4ТМ - 9600 бод.

Выводы

Для себя после этой истории я сформировал следующий порядок диагностики:

1. Проверка сетевого соединения (ping)

2. Проверка конфигураций ПО (проверка соединения и опроса с помощью заводского ПО)

3. Проверка конфигураций сетевого оборудования 

4. Проверка конфигураций полевого оборудования 

5. Проверка питания, ИБП и всех физических соединений

6. Проверка схемы подключений, в том числе COM-портов

7. Проверка кабельный линий и коммутации ЛВС

8. Далее ремонт или замена по ситуации

Когда ищешь проблему 5 часов вместо 5 минут ↓

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

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

Спасибо всем, кто дочитал до конца! Будет интересно почитать в комментариях о ваших похожих простых проблемах и непростых решениях.