Добрый день, коллеги и хабровчане!
В практике инженера АСУ ТП диагностика интерфейса 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 числа. Времени у нас было достаточно.
Фиксируем проблему: нет данных с приборов учета и доступа к сетевому оборудованию.
Первые действия
За годы работы выработался механизм решения проблем такого рода, по нему мы и пошли:
Пропинговать устройства:
Пример - ping "норм":
Пример – ping "не норм":
Как вы уже догадались, у нас оказался второй вариант. Решено выдвинуться на место происшествия. Для проведения первичных мероприятий берем с собой сопровождающего из электроцеха, как-никак за ЭБ кто то должен следить.
Проверка на месте
На месте проводим тривиальные действия:
Проверка индикации
Проверка соединения кабельных линий
Проверка акб/ибп
Проверка питания
Проверка целосности кабельных линий (визуальная)
Проверка, есть ли питание на приборах учета
Потыкать 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 бод.
Выводы
Для себя после этой истории я сформировал следующий порядок диагностики:
Проверка сетевого соединения (ping)
Проверка конфигураций ПО (проверка соединения и опроса с помощью заводского ПО)
Проверка конфигураций сетевого оборудования
Проверка конфигураций полевого оборудования
Проверка питания, ИБП и всех физических соединений
Проверка схемы подключений, в том числе COM-портов
Проверка кабельный линий и коммутации ЛВС
Далее ремонт или замена по ситуации
Когда ищешь проблему 5 часов вместо 5 минут ↓
Кейс простой, но очень наглядный, что работать надо с умом, двигаясь от простого к сложному. Мы же в самом начале пропустили одно простое действие, и получили несколько сложных задач на ровном месте.
Надеюсь, наш пример будет полезен инженерам, особенно тем, кто постоянно работает с сетевой инфраструктурой, промышленной автоматизацией и системами диспетчеризации.
Спасибо всем, кто дочитал до конца! Будет интересно почитать в комментариях о ваших похожих простых проблемах и непростых решениях.