Привіт, Хабре! Наша команда займається моніторингом верстатів та різних установок по всій країні. По суті, ми забезпечуємо можливість виробнику не ганяти ще раз інженера, коли «ой, воно все зламалося», а на ділі треба натиснути одну кнопку. Або коли зламалося не на обладнанні, а поряд.
Базова проблема така. Ось ви робите установку для крекінгу нафти, або верстат для машинобудування, або якийсь інший пристрій для заводу. Як правило, продаж сам по собі вкрай рідко можливий: зазвичай це контракт на постачання та обслуговування. Тобто ви гарантуєте, що залізяка працюватиме років 10 без перебоїв, а за перебої відповідаєте або фінансово, або забезпечуєте жорсткі SLA або щось подібне.
Це означає, що вам потрібно регулярно відправляти інженера на об'єкт. Як показує наша практика, від 30 до 80% виїздів зайві. Перший випадок можна було б розібратися, що трапилося, віддалено. Або попросити оператора натиснути пару кнопок і все запрацює. Другий випадок – «сірі» схеми. Це коли інженер виїжджає, ставить у регламент заміну чи складні роботи, а сам ділить компенсацію навпіл із кимось із заводу. Або просто насолоджується відпочинком з коханкою (реальний випадок) і тому любить виїжджати частіше. Завод не проти.
Установка моніторингу вимагає модифікації заліза пристроєм передачі, самої передачі, якогось озера даних їхнього накопичення, аналізу протоколів і середовища обробки з можливістю все подивитися і порівняти. Та й з цим усім є нюанси.
Чому не можна обійтись без віддаленого моніторингу?
Банально дорого. Відрядження для одного інженера - щонайменше 50 тисяч рублів (літак, готель, проживання, добові). Плюс не завжди виходить розірватися, і одна і та сама людина може бути потрібна в різних містах.
- У Росії її постачальник і споживач майже завжди досить далеко перебувають друг від друга. Коли ви продали виріб у Сибір, ви нічого, крім того, що вам скаже постачальник, про нього не знаєте. Ні як воно працює, ні в яких умовах експлуатується, ні, власне, хто там кривими руками яку кнопку натиснув - цієї інформації об'єктивно у вас немає, ви можете її знати тільки зі слів споживача. Це дуже ускладнює обслуговування.
- Необґрунтовані звернення та претензії. Тобто ваш замовник, який експлуатує ваш виріб, у будь-який момент може зателефонувати, написати, поскаржитися і сказати, що ваша штука не працює, вона погана, вона зламалася, приїжджайте терміново та лагодите. Якщо вам пощастило і це не просто не залили розхідник, то ви не дарма відправили фахівця. Часто буває так, що корисна робота займала менше години, а решта — підготовка відрядження, перельоти, проживання — все це зажадало купу часу інженера.
- Бувають явно необґрунтовані претензії, і щоб це довести, треба відправити інженера, скласти акт, звернутися до суду. Внаслідок цього процес затягується, і нічого хорошого ні для замовника, ні для вас це взагалі не несе.
- Суперечки виникають через те, що, наприклад, замовник неправильно експлуатував виріб, замовник з якихось причин має на вас зуб і не говорить про те, що ваш виріб працював неправильно, не в тих режимах, які заявлені у ТЗ та паспорті . При цьому протиставити йому ви нічого не можете або можете, але важко, якщо, наприклад, ваш виріб якось веде логування та запис тих режимів. Поломки з вини замовника - це відбувається взагалі часто-густо. У мене був випадок, коли дорогий німецький портальний верстат зламався через наїзд на стовп. Оператор не робив прив'язку до нуля, і там верстат встав. Причому замовник абсолютно чітко сказав: "А ми тут ні до чого". Але логірувалася інформація, і можна було ці логи підняти і зрозуміти, на якій програмі, що управляє, і в результаті чого стався цей самий наїзд. Це врятувало великі витрати постачальника у зв'язку з гарантійним ремонтом.
- Згадані «сірі» схеми — змова із сервісником. Сервісник їздить до замовника постійно той самий. Йому кажуть: «Слухай, Коль, давай знаєш як зробимо: ти напишеш, що у нас тут все поламалося, компенсацію отримаємо, або привезеш для ремонту якийсь зип. Ми все це тихою сапою реалізуємо, гроші поділимо». Залишається або вірити, або якось вигадувати якісь складні шляхи перевірки всіх цих висновків, підтверджень, що не додає ні часу, ні нервів, і нічого хорошого в цьому не відбувається. Якщо ви знайомі з тим, як автосервіси борються з шахрайствами за гарантією та скільки складнощів це накладає на процеси, то приблизно розумієте проблему.
Ну так все ж таки пристрої пишуть лог, правда? В чому проблема?
Проблема в тому, що якщо постачальники більш-менш розуміють, що лог потрібно постійно писати кудись (або зрозуміли за останні кілька десятків років), то далі культура не пішла. Лог часто потрібен для розбору випадків з дорогим ремонтом — це була помилка оператора або реальна поломка обладнання.
Щоб забрати лог, часто потрібно підійти фізично до обладнання, відкрити якийсь кожух, оголити сервісний роз'єм, підключити до нього кабель і забрати файли даних. Потім наполегливо гріпати їх кілька годин, щоб одержати картину ситуації. На жаль, але так відбувається майже скрізь (ну чи я маю однобоку точку зору, оскільки ми працюємо саме з тими виробництвами, де моніторинг тільки налагоджується).
Наші основні клієнти – виробники обладнання. Як правило, вони починають замислюватися про те, що варто якось зайнятися моніторингом або після якогось великого інциденту, або просто дивлячись на рахунки за відрядження за рік. Але частіше все ж таки йдеться про великий збій із втратою грошей або репутації. Прогресивні керівники, які замислюються про те, щоб «хоч би чого трапилося», рідкісні. Справа в тому, що зазвичай керівнику дістається старий «парк» сервісних контрактів, а ставити датчики на нове залізо він сенсу не бачить, бо знадобиться це лише за кілька років.
Загалом, у якийсь момент смажений півень все ж таки клює, і настає час модифікацій.
Сама собою передача даних не дуже страшна. На обладнанні зазвичай вже є датчики (або досить швидко ставляться), плюс вже пишуться логи і відзначаються сервісні події. Все це потрібно лише почати відправляти. Загальна практика - прямо в пристрій від рентген-апарата до автоматичної сівалки вставляється якийсь модем, наприклад з embed-SIM, і відправляє телеметрію через стільникову мережу. Місця, де немає стільникового покриття, як правило, знаходяться досить далеко і в останні роки рідкісні.
А далі починається те саме питання, що й раніше. Так, логи тепер є. Але їх треба кудись складати та якось їх читати. Загалом потрібна якась система візуалізації та аналізу інцидентів.
І тут на сцені з'являємося ми. Точніше, ми часто з'являємося раніше, оскільки керівники постачальників дивляться, як зроблено у колег, і відразу їдуть до нас радитися з приводу підбору заліза для відправки телеметрії.
ринкова ніша
На Заході шлях вирішення такої ситуації зводиться до трьох варіантів: Siemens-екосистема (дуже дорого, потрібно для великих вузлів, як правило, типу турбін), самописні мандули або хтось з локальних інтеграторів допомагає. У результаті до приходу всього цього на російський ринок утворилося середовище, де є Siemens зі своїми шматками екосистеми, Amazon, Nokia та кілька локальних екосистем на кшталт розробок 1С.
Ми зайшли на ринок як об'єднувальну ланку, що дозволяє збирати будь-які дані з будь-яких пристроїв за будь-якими (гаразд, майже будь-якими більш-менш сучасними) протоколами, обробляти їх разом і показувати їх людині в будь-якому потрібному вигляді: для цього у нас є круті SDK для всіх середовищ розробки та візуальний конструктор інтерфейсів користувача.
У результаті ми можемо зібрати всі дані з пристрою виробника, завести в сховище на сервері і зібрати панель моніторингу з алертами.
Ось так це виглядає (тут замовник зробив ще візуалізацію підприємства, це кілька годин в інтерфейсі):
І є графіки з обладнання:
Алерти виглядають так: на рівні верстата, якщо перевищили зусилля на виконавчому органі або виникло зіткнення, налаштовується набір параметрів, і система інформуватиме відділ чи ремонтні служби при виході за них.
Та й найскладніше — прогнозування виходу з ладу вузлів щодо їхнього стану для профілактики. Якщо розуміти ресурс кожного з вузлів, можна сильно скоротити витрати на тих контрактах, де йде оплата за простий.
Резюме
Ця історія звучала б досить просто: ну зрозуміли, що потрібно надсилати дані, моніторинг та аналіз, ну вибрали вендора та впровадили. Та й усе, всі щасливі. Якщо йдеться про самописні системи на своєму ж заводі, то, хоч як це дивно, системи швидко стають недостовірними. Йдеться про банальну втрату логів, неточні дані, збої в зборі, зберіганні та одержанні. Через рік-два після установки починають видаляти старі логи, що також не завжди добре закінчується. Хоча там практика з одного верстата за рік збирається 10 Гб. Вирішується це на п'ять років покупкою ще одного жорсткого диска за 10 тисяч рублів ... У якийсь момент з'ясовується, що первинне не саме обладнання, що передає, а система, яка дозволяє одержувані дані аналізувати. Важлива зручність інтерфейсу. Це взагалі біда всіх промислових систем: швидко розібратися у ситуації не завжди просто. Важливо, скільки даних видно у системі, кількість параметрів з вузла, здатність системи оперувати більшим обсягом та кількістю даних. Налаштування дашбордів, вбудована модель пристрою, редактор сцен (щоб малювати схеми розміщення на виробництвах).
Давайте наведу кілька прикладів, що це дає на практиці.
- Ось глобальна компанія-виробник промислового холодильного обладнання, яке використовується в основному в торгових мережах. 10% доходу компанії приносить надання послуг з обслуговування своєї продукції. Потрібно скоротити собівартість сервісних послуг і взагалі дати можливість нормально збільшувати постачання, тому що якщо продавати більше, то існуюча система сервісного обслуговування не впорається. Підключилися безпосередньо до платформи єдиного сервісного центру, модифікували пару модулів для потреб саме цього замовника, отримали зниження витрат на відрядження на 35% за рахунок того, що доступ до сервісної інформації надає можливість виявляти причини виходу з ладу без виїзду сервісного інженера. Аналіз даних за тривалі інтервали часу — прогнозувати технічний стан та за необхідності швидко виконувати обслуговування «за станом». Як бонус збільшилася швидкість реакції на запит: виїздів поменшало, інженери стали встигати швидше.
- Машинобудівна компанія, виробник електричного транспорту, що використовується в багатьох містах РФ та СНД. Як і всі вони хочуть скоротити витрати і при цьому прогнозувати техстан тролейбусного і трамвайного парків міста, щоб вчасно повідомляти техперсонал. Підключили, створили алгоритми збору та передачі технічних даних від рухомого складу до єдиного ситуаційного центру (алгоритми вбудовуються безпосередньо в систему управління приводами та працюють з даними CAN-шини). Віддалений доступ до даних про технічний стан, включаючи доступ в реальному часі до параметрів, що змінюються (швидкість, напруга, передача рекуперованої енергії та ін.) в режимі «осцилографа», дали доступ до віддаленого оновлення прошивки. Результат - зниження витрат на відрядження на 50%: прямий доступ до сервісної інформації надає можливість виявляти причини виходу з ладу без виїзду сервісного інженера, а аналіз даних за тривалі інтервали часу - прогнозувати технічний стан і при необхідності швидко виконувати обслуговування «за станом», включаючи об'єктивний аналіз позаштатних ситуацій. Реалізація контрактів розширеного життєвого циклу у повній відповідності до вимог Замовника та у встановлені терміни. Відповідність вимогам Технічного завдання експлуатанта, а також надання йому нових можливостей щодо контролю характеристик споживчого сервісу (якість кондиціонування, розгін/гальмування тощо).
- Третій приклад – муніципалітет. Потрібно економити електрику та підвищувати безпеку громадян. Підключили єдину платформу для контролю, керування та збору даних про підключене вуличне освітлення, віддалене керування всією інфраструктурою громадського освітлення та обслуговування його з єдиної панелі керування, що забезпечує вирішення наступних завдань. Фічі: затемнення або включення/вимкнення освітлення дистанційно, індивідуально або в групі, автоматичне повідомлення міських служб про збої в точках освітлення для більш ефективного планування ТО, надання в реальному часі даних про споживання енергії, надання потужних аналітичних інструментів для моніторингу та покращення системи вуличного освітлення на основі Big Data, надання даних про трафік, стан повітря, інтеграція з іншими підсистемами «Розумного міста». Результати - скорочення витрати електроенергії на вуличне освітлення до 80%, підвищення безпеки для мешканців за рахунок використання інтелектуальних алгоритмів управління освітленням (людина йде по вулиці - включити їй світло, людина на переході - включити яскравіше освітлення, щоб її було помітно здалеку), забезпечення міста додатковими сервісами (зарядка електромобілів, надання рекламного контенту, відеоспостереження та ін.).
Власне, я хотів сказати: сьогодні з готовою платформою (наприклад, нашою) налаштувати моніторинг можна дуже швидко і просто. Для цього не потрібні зміни в устаткуванні (або мінімальні, якщо датчиків та передачі даних досі немає), для цього не потрібні витрати на впровадження та окремі фахівці. Потрібно просто вивчити питання, витратити кілька днів на те, щоб зрозуміти, як це працює, і кілька тижнів на погодження, договір та обмін даними про протоколи. І після цього у вас будуть точні дані з усіх пристроїв. І все це можна робити по всій країні за підтримки інтегратора Техносерву, тобто гарантуємо хороший рівень надійності, нехарактерний для стартапу.
У наступному пості я покажу, як це з боку постачальника, з прикладу одного впровадження.
Джерело: habr.com