Факап инженера АСУ ТП, как мы перепутали физические COM-порты на подстанции

Коротко о статье

Статья описывает реальный случай потери связи с приборами учёта на подстанции из-за перепутанных COM-портов. Приводится порядок диагностики, который помогает избежать подобных ошибок.

Главное

• Проблема: полная потеря удалённого доступа к приборам учёта на ТП-100.
• Первые действия: пинг устройств, выезд на место, проверка индикации, питания, кабелей.
• После восстановления порта на коммутаторе две из трёх линий связи остались нерабочими.
• Анализ трафика показал: TxCnt растёт, RxCnt равен нулю — приборы не отвечают.
• Гипотеза об обрыве кабеля не подтвердилась, при проверке выяснилось, что перепутаны COM-порты.
• Причина: порты 2 и 3 перепутаны местами, у приборов разные скорости (19200 и 9600 бод).

Термины и технологии

• RS-485/422
• COM-порт
• MOXA NPort IA5450A
• Modbus RTU
• TCP
• Satec EM133
• СЭТ-4ТМ
• NETcat Pro2

Кому полезно: Инженерам АСУ ТП, работающим с сетевой инфраструктурой и системами учёта.

По теме на сайте

• Обучение ПОДКЛЮЧЕНИЕ ПЛК К ПК ЧЕРЕЗ ВИРТУАЛЬНЫЙ COM-ПОРТ

Первоисточник: habr.com

Выжимка составлена редакцией сайта с помощью ИИ по тексту статьи.

В практике инженера АСУ ТП диагностика интерфейса 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 минут ↓

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

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

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

Источник: https://habr.com/ru/articles/1038028/

Источник: статья в сообществе ВКонтакте