Один датчик. Четыре имени. Ноль данных

Страницы:  1

Ответить
 

Professor Seleznov


Один датчик. Четыре имени. Ноль данных
Почему ИИ, EAM и цифровые двойники ломаются ещё до старта
pic
TL;DR
На любом объекте старше 15 лет один прибор живёт под 4–6 разными именами в разных системах. Между ними нет моста. Именно здесь тонут проекты цифровизации — не потому что плохой ИИ, а потому что данные не готовы.
Пятница. Поздно. Скрипт третий час парсит выгрузку из SCADA 2014 года. Кодировка CP1251 с BOM. Разделитель — точка с запятой, кроме строки 14 287, где кто-то вручную поставил запятую.
В этой строке — датчик давления. В SCADA он PT-2214. В конфиге PLC — AI_CH07_RACK3. В паспорте — серийник завода. В EAM — инвентарный номер. В исполнительной документации 2003 года — PIT-101, потому что так было до первой реконструкции.
Один датчик. Пять систем. Пять имён. Ни одного совпадения.
Заглядывает сменный КИПовщик: «Ну что, ИИ строите?» Смотрит на экран и уходит. Он здесь двадцать лет. Он знает.
Почему так
Никто специально ничего не ломал. Объект просто жил.
В 1990-х пришёл первый PLC — подрядчик назвал каналы по адресам. В 2003-м сделали SCADA — интегратор придумал теги заново. В 2011-м внедрили EAM — бухгалтерия завела инвентарные номера, про теги SCADA не спрашивала. В 2019-м была реконструкция — часть тегов переименовали, часть нет.
В итоге истина о том, что такое PT-2214 и где он стоит, нигде не зафиксирована. Она живёт в голове трёх КИПовщиков, двое из которых уже на пенсии.
Как это убивает проекты
Предиктивный ТОиР. Модель видит аномалию по тегу P-1503. Диспетчер идёт в журнал ТОиР искать историю. Там этот насос записан под инвентарным номером. Связи нет. Алерт считают ложным. Модель отключают.
Модель работала. Идентификаторы — нет.
Цифровой двойник. Подрядчик строит модель по проектной документации 2003 года. На сдаче выясняется: реактор меняли в 2011-м, байпас переврезали в 2017-м, 14 датчиков из модернизации 2019-го отсутствуют.
Модель красивая. Но это двойник установки, которой нет с 2011 года.
Что нужно сделать до старта
Всё начинается не с платформы, не с ИИ и не с 3D. Всё начинается с одной таблицы:
Объект SCADA-тег PLC-адрес. Инв. № Серийник Проектное имя Датчик PT-2214 AI_CH07_RACK3 5400123778 SN-8847-XR PIT-101
Это маппинг идентификаторов. Без него любая надстройка работает с обрывками реальности.
Строится он в несколько шагов: инвентаризация источников → извлечение с трассируемостью (каждое значение знает свой файл и строку) → нормализация → разрешение конфликтов → связывание объектов в граф.
Конфликты — отдельная история. Когда в PLC написано Pt100, а в паспорте ТСМ 50М — это не ошибка парсера. Это сигнал: кто-то менял прибор и не обновил документацию. Такие места нельзя «усреднять» автоматически. Нужен инженер. Иногда — выезд на объект.
Скан ≠ данные
Многие «проекты оцифровки» заканчиваются на уровне: отсканировали, OCR, разложили по папкам. Называется «архив оцифрован».
Но предиктивной модели нужны не тексты, а связи. PDF со словами «PT-2214» не отвечает на вопрос: какой PLC-канал, какой инвентарный номер, какая история поверки.
OCR делает текст доступным для поиска. Нормализация делает объект доступным для систем. Это разные задачи.
Что мы делаем
Мы берём инженерный архив действующего объекта — в любом состоянии — и превращаем его в структурированную базу, готовую для загрузки в СУИД, EAM, предиктивные системы и цифровые двойники.
Не консалтинг «как надо». Руки на документах, конфигах, бэкапах SCADA и папках, про которые не знал никто, кроме Петровича.
Нефтегаз, нефтехимия, энергетика, суда. Опыт на реальных объектах.
Если стоите перед запуском ИИ-проекта или внедрением EAM и понимаете, что данные не готовы — напишите. Разберёмся.
Если работали с Honeywell Experion или Yokogawa — расскажите в комментариях, как решали задачу идентификаторов. Сравним грабли.
-Источник
 
Loading...
Error