От «недиагностируемого утюга» к цифровому двойнику

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

История 40-летней работы двух поколений инженеров над диагностикой электровозов: от переносного комплекса «Доктор-030» до облачной системы OKTA (Спецификация 8F41). В статье описаны этапы развития, причины отказа от готовых ПЛК и экономический эффект удалённого управления.

Главное

• В 90-х электровоз в технических кругах считали недиагностируемым: проще было дождаться поломки или чинить по пробегу.
• К 1995 году появился первый в стране переносной диагностический комплекс «Доктор-030» весом 15 кг, запоминавший историю измерений.
• С 2004 по 2015 год электроника разрабатывалась на PIC-контроллерах, что дало полный контроль над железом.
• В 2012 году в промышленные комплексы встроили iPad, получив человеческий интерфейс, Wi-Fi и визуализацию в реальном времени.
• Опыт с Raspberry Pi выявил проблемы: сбои при длительной работе, долгая загрузка до 5-7 минут, выход SD-карт из строя.
• К 2023 году сформулированы пять системных проблем, включая бумажные журналы, географию и информационные острова.

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

• OKTA
• Спецификация 8F41
• Доктор-030
• RS 458
• Raspberry Pi
• m-tag
• RFID

Кому полезно: Инженеры АСУ ТП, занимающиеся диагностикой и автоматизацией промышленного оборудования.

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

• Статья Мобильный сторож на Raspberry pi (h.264)
• Статья Введение в OpenSCADA. Работа с шиной I2C и GPIO Raspberry Pi
• Статья Архитектура доступа: как работают RFID, реле и ПЛК в современных СКУД

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

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

В прошлой статье я рассказывал о гибридных метках m-tag и том, как мы решали проблему маркировки оборудования в локомотивном депо. Сегодня история побольше — как за 40 лет два поколения инженеров прошли путь от полного отсутствия диагностики электровозов до создания системы OKTA (Спецификация 8F41).

Дисклеймер

Данная статья описывает СВОЙ опыт внедрения технологических решений в рамках деповского ремонта и не затрагивает бортовые системы самодиагностики локомотивов, появившиеся в последнее время. Все плюсы и минусы, касаемые применения тех или иных технических решений — являются результатом опытной эксплуатации и носят оценочных характер применимый к решениям только нашей организации.

Масштаб проблемы для IT-специалистов

Прежде чем погружаться в историю, поясню масштаб проблемы на понятном для IT языке. Представьте production-сервер, который нельзя мониторить, логи пишутся от руки в тетрадку, а при падении никто не знает причину — только «вчера работал, сегодня не работает». Теперь умножьте это на тысячи единиц оборудования стоимостью в десятки миллионов рублей каждая, от которых зависят человеческие жизни и грузопотоки целой страны. Добавьте сюда работу в условиях от -50 до +50°C, постоянную вибрацию, электромагнитные помехи и необходимость диагностики без остановки движения. Это и есть диагностика локомотивов.

Начало: когда электровоз был «утюгом»

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

Историческая справка

Этой проблемой с 1983 года занимается еще мой отец — на тот момент молодой специалист, недавно окончивший вуз. Он был одним из первых, кто не согласился с подходом «ждём поломки» или пробега и начал разрабатывать методы диагностики для «недиагностируемого». Я подключился к этой работе в 2000 году, когда стало понятно, что нужно соединить фундаментальные наработки отца с современными цифровыми технологиями. Вместе — это 40 лет борьбы за превращение «утюга» в управляемую и предсказуемую систему.

1995: Первый прорыв — «Доктор-030»

К 1995 году мы создали то, чего раньше не существовало — первый в истории переносной диагностический комплекс для электроподвижного состава. До этого мобильной диагностики локомотивов у нас в стране не было вообще.

«Доктор-030» — чемоданчик весом 15 кг, но внутри целая лаборатория:

• Контроль электрических цепей и машин постоянного тока
• Накопление статистики по каждому локомотиву
• Отслеживание деградации параметров с учётом пробега
• Прогнозирование отказов на основе трендов

Революционная идея — прибор запоминал историю измерений! Мы понимали: чтобы предсказать отказ, нужно видеть динамику. Данные хранились локально — об облаках тогда не мечтали, но это был прорыв.

2004-2015: Эра собственной электроники

С 2004 по 2015 год мы разрабатывали электронику собственными силами на базе PIC-контроллеров. Каждая плата проектировалась с нуля, программирование велось на ассемблере и Си, отладка занимала месяцы. Но это давало полный контроль над железом. Изготовление плат заказывали в Зеленограде, а монтаж и наладка осуществлялись уже на месте. Общее количество сотрудников, занятых в производстве, достигло 30 человек.

2004 — Комплексная система контроля (КСК)

Создали первую сетевую систему. Несколько диагностических постов, проводная связь по RS 458, данные стекаются на ПК мастера. Впервые появились штрих-коды для маркировки. Те самые наклейки, которые отклеивались через месяц, но мы начали понимать важность уникальной идентификации.

2006 — Специализированные рабочие места (СРМ)

Простое наблюдение: слесарь бегает между диагностикой и верстаком, теряя время и контекст. Решение — объединить всё в одном месте. Создали гибрид «два в одном».

2008 — Мобильные диагностические комплексы

После универсального «Доктора» пошли вглубь:

• Контроль пантографа (критично для токосъёма)
• Контроль давления (безопасность тормозов)
• Углублённая диагностика электрики

2012 — Система ОКО и революция iPad

ОКО — Оперативный Контроль Объектов

Смелое решение — встроить iPad в промышленные комплексы. Коллеги крутили пальцем у виска: «Планшеты в депо?».

Получили:

• Человеческий интерфейс вместо кнопок
• Wi-Fi вместо проводов
• Визуализацию в реальном времени

И да, в редких случаях воровство планшетов, но это скорее было исключение.

2015-2023: Урок Raspberry Pi

В 2015 году решили попробовать Raspberry Pi. Первые эксперименты пошли на ура. Но для промышленных комплексов начались проблемы:

• Ubuntu для Raspberry конфликтует с промышленными устройствами (обнаружены были проблемы с потерей сигнала bluetooth и HAT GSM (4G) модулем др.)
• Непредсказуемые сбои при длительной работе (копание в логах не дало результата)
• Время загрузки всей системы занимало до 5-7 минут, что очень долго для «холодного» старта
• SD карты — отдельная боль. Даже применяя рекомендованные производителем, они могли выходить из строя по непонятным причинам. А это сразу командировка и дополнительные расходы
• Высокая сложность локализации проблемы

Почему не Siemens или ICP DAS?

Пробовали. И Siemens SIMATIC, и модули ICP DAS. В некоторых проектах они работают. Но когда потребовалась гибкость, они уперлись в потолок:

• Ограниченная работа с дисплеями: Попробуйте вывести изображение одновременно на сенсорный терминал и 60-дюймовую панель для цеха. ПЛК про это не слышали.
• Слабая интеграция с облаком: Классические ПЛК созданы для изолированных сетей. REST API? WebSockets? MQTT? Забудьте.
• Закрытая экосистема: Интегрировать OpenCV для машинного зрения? Только через костыли. Каждый новый модуль — тысячи евро.
• У Siemens есть Railigent, у Alstom — HealthHub, но они созданы под западные стандарты. После 2022 года, эти решения стали еще менее актуальными.

2023: Момент истины и увеличение требований к диагностическому оборудованию.

К 2023 году накопилось понимание системных проблем:

Проблема 1: Бумажные журналы — фикция
Слесарь знает «правильные» значения и пишет их. При крушениях записи, как правило бесполезны.

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

Проблема 3: Информационные острова
Каждое депо, теоретически, может накапливать собственную статистику ремонтов в локальных БД, но на практике не делается даже это.

Проблема 4: “Безликость” диагностируемых аппаратов
Какой прок снимать десятки параметров если их не к чему “привязать”?

Проблема 5: Персональная ответственность
Идентифицируя слесаря, мы знаем ответственного за ремонт, а АСУ знает все о его продуктивности и правильно рассчитывает ФОТ.

Электронный измерительный инструмент

Пришлось заново изобрести уже привычный измерительный инструмент, так как везде потребовалась обратная связь с ним. Важным требованием было проведение «слепых» измерений, это когда слесарь не видит текущее значение на экране измерительного устройства и не может вручную выставить нужное значение. Оно отображается на информационной панели, но после подтверждения на измерителе. Решение проблемы №1

Кабинеты ремонта: пошаговая революция

• Защищённый экран 50-60 дюймов показывает поочередно, каждый шаг, согласно технологической карте.
• Универсальный терминал с камерой, RFID, UHF — всё в одном устройстве. Фотофиксация создаёт доказательную базу.

Нужно больше онлайна

У нас всегда было понимание того, что в случае потери связи с облачной БД или ПК мастера, оборудование должно уметь работать в offline режиме, накапливая данные. Во всех итерация развития, этот принцип оставался незыблемым. Но как обычно, аппетит приходит во время еды…
Если раньше требовалось одно обращение к БД, для сохранения итогового протокола, то теперь:

• Идентификация слесаря с проверкой его допуска (разряда) для данного вида работ Решение проблемы №5.
• Идентификация диагностируемого аппарата с проверкой наличия его в АСУ
• Выбор соответствующей активной диагностической карты
• Сканирование штрих-кода и запрос к БД, для заменяемых комплектующих (прокладки, шпильки, губки и т.д.). Это действие может совершаться на разных этапах ремонта, в зависимости от технологического процесса
• Передача результатов фотофиксации особо критичных узлов аппарата
• Передача итогового протокола измерений
• Ping-статус текущего состояния

Фактически, современные требования к процессу ремонта и диагностики, сделали обязательным нахождение в режиме online — 24/7. Решение проблемы №3

2025: Новая архитектура и рождение OKTA

Начало 2025 года стало поворотным. После всех экспериментов поняли — нужна принципиально новая архитектура, способная удаленно управлять нашим оборудованием.

Именно работа над новой архитектурой привела к формулированию концепции OKTA.

Спецификация 8F41/OKTA

8 — оптимальный набор параметров контроля (анализ 30 лет измерений показал: именно эти дают 95% информации)

F — Fusion, слияние всех потоков данных

4 — четыре основных комплекса:

1. Стационарные стенды
2. Мобильные комплексы
3. Система «Метрика» (паспортизация)
4. Гибридные метки m-tag. Решение проблемы №4

1 — единый цифровой паспорт

Архитектура ОКТА, на примере диагностического кабинета

Все основные модули, независимо друг от друга, управляются непосредственно из облака OKTA в режиме онлайн (Решение проблемы №2), позволяет:

• Управлять и настраивать стенд удаленно, изменяя алгоритмы поведения при проведении замеров
• Вносить изменения в технологический процесс (изменять картинки, уставки, описание задачи и т.д.)
• Контролировать работоспособность (статус) самого кабинета (работает/простой/выключен)

Экономика без маркетинга

Командировки:
10 стендов — час удалённой настройки против 30 человеко-дней командировок. При 100 стендах и средней командировке 50 тыс. руб. — экономия 5 млн на одном обновлении.

Обучение:
Новичок выходит на 80% производительности за 5 дней против месяца. При найме 10 человек/год — экономия 13 человеко-месяцев квалифицированного труда.

Маркировка с завода

Важное понимание: маркировку нужно внедрять на заводе-изготовителе. Особенно для расходников — как в автопроме:

• Индивидуальная упаковка
• Штрих-код на каждом пакете
• Полная прослеживаемость

Универсальность подхода

8F41 родилась в депо, но подход универсален:

• Нефтегаз: вибрация, коррозия, герметичность, давление…
• Энергетика: температура, нагрузка, изоляция, гармоники…
• Автопром: геометрия, момент затяжки, толщина покрытия…

Чему научились за 40 лет

Для тех, кто пойдёт похожим путём:

1. Дорогое промышленное «железо» — не гарантирует успешную реализацию всего проекта
2. Слушайте конечных пользователей (слесарей), а не только начальство
3. Версионируйте всё, включая конфигурации оборудования
4. Валидируйте временные метки параноидально
5. Резервируйте данные троекратно
6. Делайте интерфейсы для людей
7. Фотофиксация спасёт от 90% разборок «кто виноват»

Текущий статус

Система в активной разработке. Ядро готово, интерфейсы отлажены, m-tag интегрированы. Идёт пилотное внедрение.

Сегодня мы знаем о каждом контакторе больше, чем он сам о себе знает. И это только начало.

P.S. Ищем обратную связь от сообщества:

• Какие ещё отрасли могли бы использовать подобный подход?
• Какие метрики диагностики вы считаете критичными в вашей области?
• Есть опыт внедрения предиктивной аналитики в промышленности?

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

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