Сбор данных бд

Когда говорят про сбор данных бд, многие сразу думают про SQL-запросы и выгрузку CSV. В энергетическом оборудовании, особенно в работе с высоковольтными компонентами, всё сложнее. Данные часто размазаны по старым системам учета, чертежам в CAD и даже бумажным паспортам оборудования. Вот с этого и начнем.

Почему в энергетике сбор данных — это особый вызов

Возьмем нашу компанию, OOO Шэньхэн Энергетическое Оборудование. Мы производим оборудование для передачи и распределения электроэнергии, и каждый трансформатор или выключатель имеет десятки параметров: от электрических характеристик до данных о материалах и условиях испытаний. Эти данные исторически копились в разных местах. Конструкторские спецификации — в одной системе, результаты заводских испытаний — в Excel-файлах у инженеров, сертификаты на материалы — в папках на сетевом диске. Первая ошибка, которую многие совершают — пытаются сразу всё автоматизировать и загнать в единую базу. На практике это приводит к тому, что половина полей остаётся пустыми, потому что старые данные просто не соответствуют новой структуре.

Был у нас проект по созданию единого каталога компонентов. Казалось бы, что сложного: взять номенклатуру из ERP-системы и дополнить техническими параметрами. Но оказалось, что в ERP для одной и той же детали могло быть три разных кода, в зависимости от года поставки. А технические параметры, например, температура перегрева обмотки, вообще хранились только в протоколах испытаний в PDF. Пришлось признать, что сбор данных бд здесь — это на 70% работа по аудиту и очистке источников, и только потом — техническая выгрузка.

Ещё один нюанс — данные по отказам и наработке на отказ. Их сбор вообще часто начинается с телефонных звонков клиентам. Потому что в договорах не всегда прописана обязанность предоставлять такие отчёты в структурированном виде. Мы пытались внедрить форму на сайте https://www.chshpower.ru, куда сервисные инженеры могли бы заносить информацию с объектов. Но столкнулись с тем, что в полевых условиях, на подстанции, не до заполнения форм. Чаще всего данные приходят раз в квартал сжатым файлом в почте. И это реальность, с которой приходится работать.

Инструменты и подходы: что работает, а что нет

Главный вывод за последние годы: универсального инструмента нет. Для сбора данных с контроллеров и систем телеметрии на оборудовании мы используем специализированные шлюзы, которые пишут напрямую в TimescaleDB. Это относительно чистая история. А вот для исторических данных по проектированию пришлось писать парсеры под конкретные форматы чертежей. И здесь не обошлось без костылей: некоторые старые файлы читались только через виртуальную машину со старой версией AutoCAD.

Очень осторожно надо подходить к облачным ETL-инструментам. Они хороши для стартапов, но когда речь идет о данных по высоковольтному оборудованию, часто есть требования по хранению внутри периметра. Поэтому наш стек довольно консервативен: Python-скрипты для извлечения, локальный сервер с PostgreSQL для консолидации сырых данных, и только потом очищенное и обезличенное — уходит дальше. Кстати, обезличивание — отдельная боль. В паспортах могут фигурировать данные конкретной электростанции, и это коммерческая тайна.

Один из самых полезных, но недооцененных этапов — это создание 'словаря полей' перед началом сбора. Не технической схемы БД, а именно глоссария на человеческом языке: что мы понимаем под 'номинальным током', в каких единицах измерения, как обрабатываем случаи, когда значение указано как '>1000'. Без такого словария инженеры из производства и из сервиса будут говорить на разных языках, и в базе окажется полная каша. Мы на этом обожглись в первом же проекте.

Реальный кейс: от хаоса к аналитике

Расскажу про конкретный пример. Была задача проанализировать зависимость частоты отказов модулей ввода-вывода от партии комплектующих. Звучит просто. Но чтобы собрать данные для анализа, потребовалось: 1) выгрузить из ERP список всех отгруженных шкафов управления с серийными номерами и датами производства; 2) найти в файловой системе соответствующие каждой партии акты входного контроля электронных компонентов (они сканировались и складывались по папкам, но не индексировались); 3) получить от сервисной службы отчеты по замененным модулям, где серийные номера часто указывались с ошибками.

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

Сейчас мы для новых продуктов сразу заводим в базу 'цифровой паспорт', куда с этапа производства начинают стекаться ключевые данные. Но и здесь есть подводные камни. Например, автоматическая запись результатов испытаний. Датчик может на миллисекунду 'зависнуть' и записать аномальное значение. Если не предусмотреть фильтрацию на этапе сбора, в БД попадёт мусор, который потом исказит все расчёты надёжности. Пришлось внедрять простые правила валидации прямо на уровне скрипта, который принимает данные с испытательного стенда.

Взаимодействие с другими отделами: человеческий фактор

Самая большая проблема в сборе данных — не техническая, а организационная. Люди, которые владеют информацией, не всегда видят в её структурировании пользу для себя. Конструктору проще обновить чертёж, чем заполнить ещё и таблицу атрибутов в PLM-системе. Менеджеру по продажам важнее закрыть сделку, чем аккуратно проставить в CRM все технические параметры оборудования, которое запросил клиент.

Мы пытались решить это административными методами — ввели KPI по заполненности полей в CRM. Результат был плачевным: поля заполнялись чем попало, лишь бы система 'зелененькая' была. Гораздо лучше сработал обратный подход: показать, как собранные данные облегчают жизнь тому, кто их предоставляет. Например, когда сервисный инженер видит, что по серийному номеру он сразу может получить всю историю испытаний и предыдущих ремонтов прямо на планшет в поле, у него появляется мотивация правильно вносить данные о новом вмешательстве. Это долгий путь, но он работает.

Сайт https://www.chshpower.ru в этой экосистеме играет роль скорее витрины и точки входа для запросов. Но даже здесь мы постепенно приходим к тому, что каталог оборудования должен генерироваться напрямую из той самой базы данных, которую мы с таким трудом наполняем. Чтобы изменение в конструкторской документации автоматически меняло спецификацию на сайте. Пока это идеал, к которому стремимся. Промежуточное решение — синхронизация раз в сутки через набор скриптов, который, конечно, иногда ломается.

Взгляд в будущее и итоговые мысли

Сейчас много говорят про цифровые двойники и предиктивную аналитику. Всё это строится на качественных исторических данных. Наш опыт в OOO Шэньхэн Энергетическое Оборудование показывает, что фундамент для таких продвинутых штук закладывается скучной, рутинной работой по стандартизации процессов сбора на самых ранних этапах. Нельзя построить цифровой двойник трансформатора, если у вас нет полных и достоверных данных о материалах каждой партии обмотки.

Если резюмировать, то успешный сбор данных бд в промышленности — это всегда компромисс. Компромисс между идеальной структурой и реальной скоростью получения данных, между желанием автоматизировать всё и необходимостью ручной верификации, между потребностями аналитиков и возможностями тех, кто данные создаёт. Главное — начать с конкретной, небольшой, но бизнес-критичной задачи. Не 'соберите все данные', а 'давайте соберём данные, чтобы понять, почему в последней партии вырос процент брака'. Такой подход даёт осязаемый результат и поддерживает мотивацию.

В конечном счёте, база данных — это не самоцель, а инструмент. Инструмент для принятия решений, для улучшения продукции, для понимания своих активов. И как любой инструмент, она требует навыка и понимания контекста. Слепое следование textbook-подходам к сбору данных без учёта специфики производства высоковольтного оборудования приведёт только к созданию ещё одного 'кладбища данных', которым никто не будет пользоваться. А нам такое не нужно.