Инвентаризация OT-активов: реестр PLC и датчиков без остановки

Зачем нужен реестр OT-активов и почему его нет «по умолчанию»

В OT почти всегда есть устройства, которые работают годами и при этом выпадают из поля зрения. Часть из них ставили подрядчики, часть меняли «на время», часть переезжала между линиями. В итоге в цеху могут одновременно жить новые PLC и HMI, старые промышленные ПК, камеры, шлюзы, датчики и небольшие коммутаторы, о которых вспоминают только по факту: «главное, что все крутится».

Обычно пропадают из учета удаленные датчики и исполнительные модули, камеры «под локальные задачи», HMI после модернизаций, промышленные ПК в шкафах, а также небольшие шлюзы и преобразователи интерфейсов (RS-485/Ethernet и похожие).

Закупочные списки и проектные схемы не равны реальности на площадке. Закупка говорит, что «купили 20 датчиков», но не отвечает, где они стоят и какие из них заменили. Схема показывает «как должно быть», но не отражает временные обходы, добавленные порты, смену IP, или то, что часть устройств давно отключена, но физически остается в шкафу.

«Без остановки производства» означает ограничения: нельзя трогать работающие контроллеры, нельзя устраивать агрессивные сканы, доступ в некоторые зоны возможен только в короткие окна, а иногда - только в сопровождении эксплуатации. Поэтому реестр собирают аккуратно: наблюдением, сверкой на месте и безопасным сетевым обнаружением.

Реестр нужен и ИБ, и эксплуатации, но цели разные. ИБ важно понимать, что защищать и где риск: что критично, что доступно извне, что давно без обновлений. Эксплуатации важно быстро находить владельца, документацию и запасные части, чтобы чинить без «раскопок». Один актуальный список становится источником правды для обоих.

На практике инвентаризация OT-активов начинается не с идеала, а с простого вопроса: какие устройства обеспечивают выпуск продукции сегодня, и кто за них отвечает.

Подготовка: границы, роли и правила, чтобы не застрять

Реестр OT-активов чаще буксует не на сборе данных, а на спорах: что считать активом, кто отвечает и где заканчивается зона контроля. Снимите эти вопросы заранее в коротких договоренностях на 1-2 страницы.

Сначала зафиксируйте границы. Удобно описывать их так, как вы реально управляете производством: площадка - цех - линия. Добавьте технические границы: подсети, шкафы управления, отдельные сегменты видеонаблюдения, точки удаленного доступа. Сразу решите, что делать с подрядчиками: их контроллеры и ноутбуки в шкафу - это ваши активы, чужие, или «временные, но учитываемые».

Роли и ответственность

Дальше распределите роли, иначе реестр станет «ничейным». Обычно вовлечены четыре группы: АСУ ТП (знают оборудование и режимы), эксплуатация (держат работоспособность), ИТ (сеть, адресация, учетные системы), ИБ (требования, риски, контроль). Часто отдельно нужен владелец за камеры и СКУД (охрана/видео), потому что эти устройства живут рядом с технологией, но по другим правилам.

Чтобы не усложнять, закрепите минимум:

• кто заводит новую запись (например, АСУ ТП или эксплуатация)
• кто подтверждает данные (владелец участка/линии)
• кто отвечает за сетевые поля (ИТ)
• кто назначает критичность (ИБ вместе с владельцем процесса)

Формат учета и правила обновления

На старте достаточно таблицы, если в ней есть единый идентификатор актива и понятные статусы (черновик, подтверждено, выведено из эксплуатации). Позже ее можно перенести в систему учета, но не стоит ждать «идеального инструмента».

Согласуйте простые правила: как именуете активы, где храните фото шильдика/шкафа, как отмечаете спорные устройства и как часто сверяетесь (например, раз в квартал и после каждого изменения на линии). Без этого реестр быстро устареет и перестанет помогать и ИБ, и эксплуатации.

Безопасность работ: как не уронить производство

Главное правило для OT: лучше собрать меньше данных, чем получить простой линии. Инвентаризация должна идти по заранее согласованным безопасным действиям, а не по принципу «попробуем просканировать и посмотрим».

То, что обычно можно делать пассивно, без влияния на трафик и контроллеры:

• снять зеркало порта (SPAN) и анализировать трафик точечно
• читать конфиги сетевого оборудования и таблицы MAC-адресов на коммутаторах
• сверять документацию, шкафные таблички, серийники и версии прошивок по месту
• собирать логи с инженерных станций и серверов SCADA, если это не нагружает систему

Активный опрос бывает нужен (например, чтобы уточнить модель PLC или версию HMI), но его делают только в окнах обслуживания и малыми шагами. Начните с одного сегмента и одного типа устройств, ограничьте частоту запросов и заранее определите способ быстро остановить работу. Если окна нет, лучше закрыть пробелы пассивными источниками.

С технологами проще договориться, если заранее обозначить «красные линии»:

• не отправлять запросы на PLC/RTU без согласованного теста на стенде или в окне
• не менять настройки коммутаторов, маршрутизацию и VLAN без плана отката
• не трогать I/O и датчики, влияющие на безопасность, без допуска и сопровождения
• останавливать любую активность при первых признаках нестабильности (ошибки, таймауты, рост нагрузки)

Риск полезно фиксировать прямо в реестре или рядом: где сканирование запрещено, почему (критическая линия, устаревшее оборудование, нет окна, нет ответственного) и какая безопасная альтернатива согласована (зеркало порта, чтение конфигов, обход). Это избавляет от «героических» попыток собрать все сразу и помогает планировать следующие итерации.

Инвентаризация обходом: что реально собрать на месте

Обход по месту часто дает больше, чем кажется. Он позволяет быстро собрать первый слой реестра без риска для линии: вы не трогаете конфигурации, не сканируете сеть, а фиксируете факты. Это особенно важно, потому что часть устройств вообще не попадает в ИТ-документацию.

Начните с маршрута: цех -> шкаф управления -> стойка/панель -> поле (датчики, камеры, исполнительные механизмы). Идите вместе с человеком, который «знает где что стоит»: электрик КИПиА или наладчик. На этом шаге часто всплывают «серые» устройства: маленькие неучтенные коммутаторы в шкафу, медиаконвертеры, бытовые Wi-Fi роутеры «для удобства», отдельные PoE-инжекторы для камер.

Что имеет смысл собрать и сразу занести в черновик:

• марка и модель (PLC, HMI, камера, датчик), серийный номер, год выпуска (если видно)
• точное место: цех, линия, шкаф, ячейка; для поля - участок и понятное описание точки установки
• маркировки кабелей и клеммников, номер автомата/предохранителя (если виден)
• внешние признаки: модем/радиоканал, USB-накопитель, второй сетевой порт, антенны
• признаки владения: наклейки подрядчика, записи в журнале обслуживания, контакты на дверце шкафа

Фотофиксация ускоряет работу: общий кадр шкафа, затем крупно шильдик и подключение. Снимки важно подписывать сразу (например, «Цех 2, шкаф ШУ-17, PLC-1»), иначе через неделю это превращается в набор картинок без привязки.

После обхода сделайте быструю сверку с документами: схемы, ведомости, паспорта, журналы ТО. Схемы обычно показывают «как должно быть», а обход - «как есть». Разница и будет списком задач на уточнение.

Сетевое обнаружение: что собрать без агрессивного сканирования

Если обход дает ответ «что стоит в шкафу», то сетевое обнаружение помогает понять «что реально говорит по сети» и где это подключено. Это полезно, потому что устройства переезжают между портами, а наклейки и схемы не всегда успевают за реальностью.

Начинайте с пассивных источников, которые не трогают конечные устройства и не создают нагрузку. Обычно уже достаточно доступа к сетевому оборудованию и журналам:

• таблицы MAC-адресов на коммутаторах (какой MAC на каком порту и в каком VLAN)
• ARP-таблицы на L3-устройствах (сопоставление IP и MAC)
• DHCP-логи и резервации (если DHCP используется)
• логи межсетевых экранов/маршрутизаторов (кто с кем общается и по каким портам)
• зеркалирование трафика на SPAN-порт и разбор в анализаторе (точечно и по согласованию)

Пассивные данные важно интерпретировать аккуратно, чтобы не смешать IT и OT. В цехе часто есть отдельные VLAN/сегменты, NAT на промышленных шлюзах, «прыгающие» адреса за прокси и даже односторонние каналы. В таких случаях один IP может скрывать несколько устройств, а внешние логи покажут только шлюз. Поэтому фиксируйте «точку видимости»: где именно сняты данные (какой коммутатор/фаервол, какой интерфейс).

Активное обнаружение допустимо, но только в пределах согласованных правил. Самый безопасный подход - короткие проверки по белому списку адресов и времени: подтвердить «живость» (ICMP ping или ARP-probe), аккуратно проверить пару известных портов без перебора, прочитать стандартные баннеры там, где это не ломает устройство. И всегда останавливаться при первом признаке нестабильности.

Чтобы сводить результаты без дубликатов, держите связку IP + MAC + порт коммутатора + место установки. Камера на линии может сменить IP после замены, но MAC и порт в шкафу часто остаются, и это помогает не плодить записи.

Владельцы и ответственность: без этого реестр не работает

В реестре OT-активов «железо» важно, но еще важнее люди. Без владельца записи быстро устаревают: контроллер заменили, пароль сменили, порт перекинули, а в таблице все по-старому. Поэтому сразу учитывайте не только устройство, но и ответственность за него.

Владельца лучше искать не по фамилии «кто рядом», а по устойчивой опоре: подразделение и роль. Для PLC это часто АСУ ТП или служба КИПиА, для камер - служба безопасности или ИТ, для датчиков - участок или цех. Если обслуживание на аутсорсе, владельцем все равно остается ваша сторона (тот, кто принимает работу и отвечает за последствия), а подрядчика стоит фиксировать как обслуживающую организацию.

Полезно разделять две ответственности: кто эксплуатирует (обслуживает, выезжает, чинит) и кто разрешает изменения (прошивки, логика, сетевые настройки, замена на аналог). Если эти роли смешаны, изменения начинают проходить «по звонку», и реестр перестает быть источником правды.

Чтобы реестр помогал в аварии, добавьте короткую цепочку контактов для эскалации:

• основная роль (например, «инженер АСУ ТП смены»)
• дежурный телефон или диспетчерская точка входа
• ответственный руководитель (кто принимает решение об остановке/обходе)
• вендор/сервисная компания (если есть договор)

Правило простое: «нет владельца - нет эксплуатации». Если актив найден (например, «потерянный» датчик на линии), но непонятно чей он, закрывайте пробел сразу:

• назначьте временного владельца на 2-4 недели (часто это начальник участка)
• поставьте задачу подтвердить назначение или передать актив другому подразделению
• запретите изменения без явного согласования владельца
• если владелец не находится, решите судьбу актива: вывести из эксплуатации или легализовать

Небольшой пример: HMI стоит в шкафу, но к нему подключены две линии. Эксплуатация - у цеха, изменения логики - у АСУ ТП, сеть - у ИТ. Если это разнести в реестре, спор «кто виноват» превращается в понятный порядок действий.

Критичность и риски: как приоритизировать без сложных методик

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

Простая шкала критичности 1-3

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

• 3 (высокая): риск травм, стоп линии, крупный брак, нарушение требований.
• 2 (средняя): частичная потеря производительности, локальный брак; обходные процедуры есть, но они дорогие.
• 1 (низкая): влияет на удобство и мониторинг; есть простая замена.

Чтобы оценка была честной, смотрите не на устройство само по себе, а на зависимости. Простой датчик давления может быть уровнем 3, если без него PLC переводит линию в аварийный стоп. Камера может быть уровнем 2 или 3, если участвует в контроле качества и без нее продукт нельзя отгружать.

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

Что делать сначала, а что позже

В первую очередь берите активы уровня 3 и все, у чего есть удаленный доступ или сервисный порт без контроля. Дальше действуйте по понятному порядку: закрепить владельца и контакт на смене, проверить ЗИП или план замены, зафиксировать безопасное обслуживание (окна, допуски), учесть удаленный доступ и учетные записи, а обновления и проверки для уровня 2 поставить в план. Уровень 1 можно оставить на потом.

Пример: PLC управляет насосами, HMI только отображает, а датчик уровня дает команду на отключение. Тогда датчик и PLC получают 3, HMI чаще всего 2. Это сразу показывает, куда направить инженера и ИБ в первую неделю.

Минимальный набор полей реестра для ИБ и эксплуатации

Хороший реестр в OT не обязан быть идеальным с первого дня. Важнее, чтобы запись однозначно находилась, имела владельца и помогала быстро принять решение при инциденте или простое.

Поля, без которых реестр быстро превращается в «кладбище записей»

Держите минимум как короткий «паспорт» устройства. Если информации нет, фиксируйте это явно, а не оставляйте пусто.

• Идентификация: тип (PLC, HMI, камера, датчик), производитель, модель, серийный номер (или инвентарный номер), имя/тег на площадке.
• Сеть: IP (если есть), MAC (если есть), сегмент/VLAN, физическая точка (шкаф/стойка), порт коммутатора (если известен), основные протоколы/сервисы (например, OPC UA, Modbus/TCP) - только то, что точно известно.
• Эксплуатация: место установки (цех, участок), линия/узел, назначение (что контролирует/измеряет), владелец (подразделение), обслуживающая сторона (АСУ ТП, подрядчик), статус (в работе/резерв/списан).
• ИБ: критичность (1-3 или низкая/средняя/высокая), тип доступа (только локально/есть удаленный), точки удаленного доступа (если установлено), дата последней проверки/инвентаризации.
• Качество данных: уровень уверенности (точно/со слов/предположительно) и «задача на уточнение» с ответственным и сроком.

Как хранить «неизвестное», чтобы оно не потерялось

Договоритесь о значениях вроде «не определено» и «требует проверки». Если у датчика не виден серийный номер, так и пишите: «S/N: не определено», а рядом создайте задачу: «сфотографировать шильдик при ближайшей остановке» и назначьте ответственного. Так реестр остается честным и пригодным для работы уже сейчас.

Пошаговый план: от нуля до живого реестра за несколько итераций

Чтобы сделать инвентаризацию OT-активов без остановки производства, удобнее идти короткими циклами: сначала черновик, потом подтверждение на месте, затем сверка по сети. Так вы быстрее получите рабочую картину и не увязнете в попытке сделать «идеально» с первого раза.

Итерация 1: собрать основу и быстро проверить реальность

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

Дальше проверьте самые важные зоны: узлы, где простой дорогой (например, линия розлива или участок упаковки). Во время обхода фиксируйте то, что можно увидеть безопасно: модели PLC/HMI, серийные номера, где стоит устройство, к чему подключено, кто обычно «ходит» к этому шкафу.

Итерация 2: найти расхождения и закрепить ответственность

После обхода сделайте сетевую сверку осторожными методами: пассивное наблюдение, чтение таблиц коммутаторов, зеркалирование порта (если разрешено), анализ ARP/MAC в пределах выделенных сегментов. Цель не «просветить всю сеть», а найти расхождения: «есть в сети, нет в реестре» и наоборот.

Дальше закройте организационные дыры. Хороший реестр держится на владельцах и простых правилах обновления. Логика процесса обычно такая: собрать черновик из документов, подтвердить приоритетные зоны обходом, сверить с сетью, назначить владельца и критичность, а затем ввести обновление по событиям (ремонт, замена, перенос, прошивка) и короткие плановые сверки.

Например, если камера в цехе видна в сети, но ее никто не «владеет», договоритесь о границах: эксплуатация отвечает за питание и крепеж, ИТ (или АСУ ТП) - за сеть, служба безопасности - за хранение и доступ к видео. Это резко снижает число «потерянных» устройств.

Типичные ошибки и ловушки при учете PLC, HMI и датчиков

Самая частая ошибка - начать «с сети» и сразу сканировать всю промышленную сеть активными инструментами. Даже если сканирование кажется «легким», оно может создать лишний трафик, задеть старые PLC или перегрузить коммутатор в шкафу. Для OT лучше сначала согласовать правила, а сбор делать через обход, пассивные источники и точечные проверки по окнам.

Вторая ловушка - свалить IT и OT в один список без явной отметки сегмента и назначения. Потом в реестре рядом оказываются офисный принтер и HMI линии розлива, и никто не понимает, что относится к цеху, а что - к бухгалтерии. Это бьет по приоритизации и по реакции на инциденты.

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

Четвертая ловушка - не фиксировать владельца и контакты. Когда датчик температуры начинает «шуметь», ИБ не знает, к кому идти, а эксплуатация не понимает, кто разрешал изменения. Контакт владельца часто решает это за минуты.

Пятая ошибка - не планировать обновления. Реестр устаревает после первого же ремонта.

Если хотите избежать большинства проблем, держите базовые правила в одном месте: любые сетевые проверки только по согласованию и с ограничениями; отдельные поля для OT/IT, сегмента и точки установки; сверка «закуплено» против «установлено и включено»; владелец плюс дежурный контакт на каждый актив; четкие события, после которых запись обязана обновляться.

Пример: в цеху заменили HMI на аналогичную модель, но IP и имя узла остались «временными». Если это не попало в реестр, ночью мониторинг увидит «новое устройство», а бригада потратит время на поиск ответственного вместо устранения проблемы.

Быстрая проверка качества реестра (чеклист на 10 минут)

Реестр полезен только тогда, когда по нему можно быстро найти устройство и понять, насколько больно будет, если оно остановится. Эта быстрая проверка показывает, «живой» ли реестр после инвентаризации, без долгих разборов.

Чеклист на 10 минут

Выберите 5-10 самых важных узлов (например, главная линия, упаковка, участок учета сырья) и проверьте пять вещей:

• Покрытие: по каждой критичной линии есть хотя бы основные контроллеры, HMI, ключевые камеры и датчики, а не только «то, что попалось».
• Ответственные: у каждого актива указан владелец со стороны производства и обслуживающая сторона (АСУ ТП, КИПиА, ИТ, подрядчик). Формулировка «цех» без роли - это не ответственность.
• Поиск: для сетевых устройств есть минимум, чтобы их найти без гаданий (IP или MAC плюс сегмент/цех или коммутатор/шкаф). Для не сетевых датчиков - хотя бы шкаф и клемма или петля.
• Критичность: задана грубо, но понятно, и согласована с эксплуатацией, а не только с ИБ.
• Актуальность: есть дата последней проверки и понятный триггер обновления (замена, ремонт, модернизация, перенос на другой сегмент).

Если проваливаются два и более пункта, реестр пока больше похож на список наблюдений, чем на рабочий инструмент.

Пример сценария: цех с PLC, HMI, камерами и «потерянными» датчиками

На линии розлива числятся 2 PLC, 3 HMI, 12 камер и около 40 датчиков. Часть датчиков и одну камеру ставили подрядчики во время модернизаций, а документы остались в почте у разных людей. Остановку линии никто не согласует, поэтому работу начинают с того, что можно сделать безопасно и быстро.

Сначала делают обход. Идут не по всему цеху подряд, а по понятным точкам: шкафы управления, стойки с видеорегистраторами, места, где датчики чаще всего вызывают простои. В шкафу видно модель PLC, состав модулей ввода-вывода, маркировку кабелей и часто - наклейку с подрядчиком. На местах камер фиксируют направление, высоту, рядом стоящее оборудование и куда уходит кабель.

Параллельно включают сетевое обнаружение без агрессивного сканирования: смотрят таблицы ARP/MAC на коммутаторах, списки клиентов на видеорегистраторе, DHCP-выдачи (если есть). Так находят «лишнюю» камеру: в сети виден еще один MAC с типичным для камер OUI, но физически ее никто не помнит. Заодно всплывает неизвестный коммутатор в шкафу: по MAC-адресам видно, что часть камер подключена не туда, куда считалось.

Дальше назначают владельцев: PLC и датчики - служба КИПиА, HMI - производство (как пользователь) и КИПиА (как обслуживающий), видео - подрядчик по видеонаблюдению, но точка подключения и питание - зона ответственности цеха.

После первой итерации уже видно главное: что критично для простоя (PLC и датчики уровня), где есть удаленный доступ (HMI с сервисным VPN или камера с проброшенным портом), какие устройства «не по схеме» (лишняя камера, неизвестный коммутатор), что проверять первым при инциденте (учетные записи, прошивки, резервные копии) и кому звонить, если что-то ломается или требует отключения.

Следующие шаги: как превратить разовую работу в постоянный процесс

Реестр быстро устаревает, если он не встроен в обычные работы. После любой замены PLC, прошивки, переноса HMI, добавления камеры или датчика запись должна обновляться так же обязательно, как закрывается заявка на ремонт.

Рабочее правило: «нет обновления в реестре - нет приемки работ». Владелец актива подтверждает изменения, а ответственный за реестр проверяет, что критичные поля заполнены и не появляются «серые» устройства.

Дальше обычно всплывают забытые учетные записи, временные подключения и устройства без маркировки. Начните с вещей, которые дают эффект без большого проекта: привести в порядок удаленные доступы, ввести физическую маркировку (уникальный ID на шкафу/панели и тот же ID в реестре), определить базовый комплект ЗИП для критичных узлов, и настроить короткий ежемесячный контроль по 5-10 самым критичным активам и сегментам.

И еще одна практичная мысль: данным нужен «дом». Даже если стартовали с таблицы, нужны контроль версий, права доступа и резервные копии. Минимум - отдельное хранилище с бэкапом и понятной схемой, кто может править, а кто только смотреть.

Если реестр и связанные изменения требуют опоры на инфраструктуру (серверы, рабочие станции, сеть, поддержка), это проще делать вместе с системным интегратором. В Казахстане такие задачи часто закрывают на базе решений и оборудования GSE.kz (производство и интеграция ИТ-систем), чтобы учет жил годами и не превращался в разовую кампанию.