Заміну зношуваних деталей на промислових установках призначали за паспортом або досвідом інженера, а не за фактичним зносом, через що завод або міняв ще робочий витратний матеріал, або ризикував аварійною зупинкою.
Розгорнули платформу, яка збирає телеметрію із заводських шаф через захищене вихідне з'єднання раз на 60 секунд, пов'язує показання з фізичними величинами за налаштовуваним довідником і кілька разів на добу перераховує залишковий ресурс деталі, дату заміни і дату замовлення разом із достовірністю прогнозу.
Завод і сервісна компанія дивляться на одну дату заміни, пораховану за одними показаннями, і сервіс встигає підготувати деталь і виїзд до того, як обладнання стане.
Витратна деталь має справний вигляд аж до миті, коли зупиняє цех
На металургійному, цементному чи хімічному виробництві невелика зношувана деталь може визначати роботу цілої установки. Поки вона справляється, її майже не помічають. Відмова означає екстрену зупинку, штрафи за простій і додаткове навантаження на сусіднє обладнання.
Планову заміну при цьому часто призначають за паспортом, календарем або досвідом інженера. Фактичний режим роботи конкретної деталі залишається в паперових журналах обхідників, а сервісні звіти з'являються заднім числом. Завод не хоче міняти ще робочу витратну деталь і переплачувати. Сервісна компанія не хоче чекати на аварію. Без спільної картини обидві сторони сперечаються про той самий знос, спираючись на різні дані.
Завдання платформи починається з простого на вигляд запитання: скільки ресурсу лишилося в деталі, яка зараз працює всередині установки? Окремого датчика з готовою відповіддю немає. Її доводиться виводити з температури, тиску, частоти, часу роботи та інших непрямих сигналів.
Спершу треба почути обладнання всередині закритого контуру
На кожному майданчику стоять шафи керування з датчиками. Відкривати до них вхід із зовнішньої мережі завод не повинен, тому напрямок зв'язку розвернуто: шафа сама встановлює з'єднання із захищеного контуру і відрекомендовується шлюзу платформи. Після цього шлюз отримує її план опитування і запитує регістри за Modbus.
Незареєстровану шафу не опитують. Новий датчик, доданий через систему, потрапляє до плану без перезапуску шлюзу. Раз на 60 секунд чергова порція показань іде на сервер; кілька разів на добу платформа перераховує знос і прогноз.
Заводу не потрібно відкривати назовні порти або надавати платформі вхід до виробничої мережі. З'єднання завжди встановлюється зсередини захищеного контуру.
Телеметрія зберігається окремо від звичайних даних порталу. Для часових рядів використовується TimescaleDB, для компаній, користувачів, заявок і налаштувань - реляційна база. Показання більше не залежать від того, чи дійшов обхідник до шафи і чи встиг переписати число в журнал.
Один і той самий регістр на двох шафах може означати різне
Шафи збирають під конкретні установки. В однієї п'ять датчиків температури, в іншої один; адреси регістрів і сенс значень теж різняться. З Modbus приходять голі 16-бітні числа, які самі по собі інженеру нічого не кажуть.
Платформа пов'язує регістр із фізичною величиною, одиницею вимірювання і правилом перерахунку. У системі передбачено сім типів величин, серед них тиск, температура, частота, відсотки та дискретні стани. Лінійний перерахунок перетворює значення регістра на кПа, °C, Гц або %, а статусні коди отримують зрозуміле розшифрування. На екрані інженер бачить "перепад тиску 2,4 кПа", а не "регістр = 842".
Цей словник не зашитий назавжди в код. Адміністратор додає нову величину до довідника і описує карту конкретної шафи налаштуваннями. Наступна нестандартна конфігурація підключається без окремого доопрацювання платформи.
Прогноз належить деталі, а не установці взагалі
У кожної зношуваної деталі є власний період життя: дата встановлення і дата зняття. Тому ресурс рахується за даними, накопиченими саме за час її роботи на об'єкті. Після заміни нова деталь починає свою історію з нуля, не успадковуючи знос попередньої.
Кілька разів на добу система обробляє телеметрію і оцінює ресурс за двома незалежними фізичними механізмами. Для планування береться консервативний сценарій - той, за яким заміна знадобиться раніше. На виході інженер отримує чотири пов'язані результати:
| Результат розрахунку | Для чого він потрібен |
|---|---|
| Залишковий ресурс у відсотках | Зрозуміти поточний стан і побачити його за кольоровою індикацією |
| Прогнозована дата заміни | Поставити сервісний виїзд у план |
| Дата замовлення | Встигнути отримати деталь з урахуванням терміну постачання |
| Достовірність прогнозу | Відрізнити стійку оцінку від розрахунку на неповних даних |
Паспортний ресурс залишається жорсткою межею. Якщо фактичне напрацювання його перевищило, платформа сама створює заміну, а інженер зобов'язаний виїхати і встановити нову витратну деталь. Прогноз допомагає діяти раніше, але не скасовує встановлену межу експлуатації.
Так стан кількох секцій може виглядати в порталі; значення нижче ілюструють інтерфейс, а не метрики проєкту:
Невизначеність показується поруч із прогнозом
Ціна помилки тут працює в обидва боки. Надто рання тривога відправляє в утиль ще робочу деталь. Надто пізня залишає виробництво перед ризиком аварійної зупинки. Тому одна гарна дата без оцінки якості даних створювала б хибну впевненість.
Кожен прогноз отримує рівень достовірності: високий, середній або низький. Якщо даних недостатньо, портал показує це прямо. Інженер бачить не лише результат моделі, а й наскільки впевнено на нього можна спиратися під час планування закупівлі та виїзду.
Шлюз свідомо не зберігає локальну копію показань при обриві зв'язку. Пропущений період залишається видимим в історії і знижує достовірність прогнозу. Після відновлення з'єднання опитування продовжується автоматично, але відсутні заміри не вигадуються і не відновлюються заднім числом.
Це обмеження було прийнято явно, а не сховано всередині реалізації. Платформа відрізняє відсутність даних від нормального режиму роботи і не видає попередню точність там, де часовий ряд обірвався.
На одній платформі працюють сервіс і незалежні заводи
Виробник обладнання обслуговує кілька компаній, але завод не повинен бачити дані сусіднього майданчика. Структура починається з компанії, всередині неї містяться об'єкти, на об'єктах - одиниці обладнання, а в кожної одиниці - датчики і часові ряди. Права перевіряються сервером при кожному запиті.
П'ять ролей розділені між двома сторонами. У сервісу є адміністратор, штатний і виїзний інженери; у клієнта - адміністратор компанії і співробітник. Завод бачить лише свої майданчики, персонал сервісу працює з усіма об'єктами в межах своєї ролі. Самостійної реєстрації немає: закриту систему наповнюють адміністратори.
Один користувач може перебувати в кількох компаніях. Інженеру холдингу, який відповідає за кілька заводів, не доводиться заводити окремий обліковий запис для кожної юридичної особи.
Сигнал про знос продовжується сервісною заявкою
Співробітник заводу подає заявку прямо з панелі обладнання. На боці виробника вона стає сервісним звітом із виконавцем і статусом. Інженер виконує роботу, списує використані запчастини і закриває звіт; результат з'являється в клієнтському порталі. Заявка не розчиняється між листами і дзвінками.
Показання надходять на панелі та графіки в міру збору, тому завод і сервіс дивляться на один поточний стан. Для кожної установки задаються свої пороги тиску і температури: універсального набору немає, оскільки конфігурації та робочі режими різняться. Перевищення бере участь в оцінці зносу і водночас надсилає відповідальним листа. Таке саме сповіщення приходить при новій сервісній заявці.
Частина налаштувань і регламентних операцій виконується через портал тим самим захищеним каналом. Там, де фізична робота на обладнанні не потрібна, інженер змінює параметри без окремої поїздки на майданчик.
Історія відповідає на запитання "хто змінив поріг"
Кожна дія, яка змінює дані, потрапляє до журналу незалежно від автора: людини чи автоматичного сценарію. Записуються зміна порога, зміна конфігурації і навіть налаштування, внесене на самому пристрої в обхід порталу. Телеметрія в цей журнал не дублюється - для неї існує база часових рядів.
Адміністратор відбирає записи за користувачем, дією і часом. При розборі спірного звернення він відновлює стан та історію так, як їх бачив користувач у той момент. Замість листування про те, хто змінив параметр, залишається конкретний запис з автором і часом.
До картки кожної одиниці додається її документація: паспорти, креслення, PDF і docx, аудіо та відео. Інженер відкриває потрібний матеріал поруч із поточними показаннями і сервісною історією конкретної шафи.
Заміна стає подією, яку можна планувати
Завод і сервісна компанія отримують спільну картину фактичної експлуатації. Дата заміни перестає бути суперечкою за паперовими журналами, а дата замовлення заздалегідь потрапляє в поле зору закупівлі. Завод знижує ризик позапланової зупинки і штрафів за простій; сервіс планує виїзди і наявність деталей до аварійного звернення.
Платформа при цьому не обіцяє знати майбутнє з однаковою точністю в усіх ситуаціях. Прогноз обмежений повнотою телеметрії, коректністю карти датчиків, фізичними моделями і паспортною межею. Достовірність поруч із результатом показує, де рішення вже спирається на стійку історію, а де інженеру потрібно враховувати прогалини.
Щодня система накопичує режими роботи і фактичні терміни життя деталей. Наступний крок - використати цю історію для підключення додаткових датчиків і навчання нейромережевих моделей, які уточнюють властивості матеріалів там, де інженерних формул уже недостатньо. Цей шар може розвиватися поверх працюючого збору, сервісного циклу і сховища без перезбирання всієї платформи.
Олександр
Це реальний проєкт, поданий знеособлено. Впізнавані деталі - галузь, конкретику, усе, за чим можна визначити замовника, - ми навмисно змінюємо; ім'я та комерційні таємниці замовника не розкриваємо. Незмінною лишається суть: яке завдання розв'язували і яким інженерним підходом. Кейс написано, щоб показати проблему та її вирішення - що і як ми робимо.