Перейти до контенту
Усі відповіді

IoT/SCADA-платформа для невеликого виробництва: що потрібне

Словосполучення «IoT/SCADA-платформа» продають як одну річ, а насправді це сім окремих шарів, і кожен можна зробити, купити або не робити взагалі. Для цеху на кілька ліній, насосної станції чи мережі обʼєктів самообслуговування більшість цих шарів дуже тонкі, а один-два — критичні. Нижче — з чого платформа складається насправді, що з цього потрібно невеликому виробництву, а що лише збільшує рахунок.

Сім рівнів: від регістра контролера до телефона

Перший рівень — обладнання і його інтерфейс. Контролери лінії, частотники, лічильники й датчики віддають дані здебільшого по Modbus: RTU по двопровідній шині RS-485 або TCP по звичайній мережі. Є документована карта регістрів — усе інше питання часу. Немає — це найдорожча частина проєкту, і дізнатись про це варто до купівлі обладнання.

Другий — шлюз на обʼєкті. Пристрій, що опитує шину й перетворює регістри на події та показники: промисловий шлюз Modbus RTU/TCP, контролер із Linux або невеликий компʼютер у щитку. Третій — транспорт телеметрії: як дані їдуть на сервер і що з ними, коли каналу немає. Четвертий — історія: база, у якій показники лежать роками і з якої можна відповісти на питання «що було в березні».

Пʼятий — візуалізація: екран зі станом обʼєктів і графіками. Шостий — тривоги: правило «пост не відповідає двадцять хвилин» або «температура вища за поріг», яке перетворюється на повідомлення людині. Сьомий — доступ з телефона: той самий стан обʼєкта, відкритий з дороги. На невеликому виробництві саме тривоги й телефон дають найбільший ефект, а мнемосхеми відкриваються раз на місяць.

Офлайн-робота і буфер: обʼєкт не має залежати від сервера

Платформу проєктують в офісі, де інтернет є завжди, а ставлять на майданчик, де мобільний канал зникає щотижня. Тому перше архітектурне рішення: обʼєкт працює сам. Лінія не зупиняється, бо сервер недоступний; оплата приймається, цикл запускається, подія пишеться локально. Сервер — місце, куди дані доходять, а не місце, де вони народжуються.

Друге рішення — буфер на диску шлюзу, а не в памʼяті: живлення на обʼєкті падає частіше за звʼязок. Події нумеруються на обʼєкті, і сервер ігнорує повтори — інакше після кожного обриву в історії зʼявляються дублікати. Показники, що оновлюються щохвилини, можна втрачати; події з грошима й зупинками — ні.

У мережі мийок самообслуговування SamWash, яку ми супроводжуємо, термінали побудовані саме так: приймають оплату без звʼязку й досилають транзакції, коли канал повертається. Через цю систему пройшло 14 мільйонів платіжних транзакцій, і для виробничої лінії принцип той самий: обрив звʼязку — звичайна подія, а не аварія. Докладніше про буфер, дрейф годинника й дедуплікацію — в окремій відповіді про телеметрію там, де звʼязок падає.

Коробкова SCADA чи своя платформа

Промислова SCADA з коробки добра там, де оператор сидить перед екраном і реагує в секундах: мнемосхеми, аварійні сценарії, сертифікація. Вона коштує як саме обладнання, ліцензується за кількістю тегів або клієнтів і тягне за собою Windows-сервер, інтегратора й річну підтримку. Для цеху, де на дані дивляться вранці й у разі тривоги, більшість цього не використовується.

Своя платформа — це опитувач по Modbus, база часових рядів, кілька правил тривог і вебсторінка. Її сила не в дешевизні заліза, а в тому, що вона говорить мовою вашого бізнесу: показує не «регістр 40012», а «лінія 2 простояла 47 хвилин», і звʼязує телеметрію з виробленими одиницями, виручкою чи витратою матеріалу. Її слабкість — вона вимагає людини, яка розуміє, як система зупиняється і як повертається.

Третій варіант, на практиці найчастіший: відкриті компоненти, зібрані під задачу — збирач даних і база часових рядів готові, правила й екрани свої. Без ліцензії за тег і без ілюзії, що «коробка все зробить». Чесне порівняння своєї системи з готовою — в окремій відповіді.

Коли вистачить Raspberry Pi, а коли ні

Raspberry Pi в щитку доречний, коли задача — опитувати шину, накопичувати й відправляти далі. На ньому звичайний Linux, звичні бібліотеки Modbus, звичне оновлення, і ціна володіння нижча не через залізо, а через людей, що вміють із ним працювати. Умови, за яких він живе роками: система на картці в режимі читання, дані в окремому сховищі або одразу на сервері, автоматичний перезапуск і — головне — Pi не є єдиним місцем, де дані існують.

Він не підходить, коли від системи залежить безпека людей або цілісність обладнання: якщо збій означає не «не порахували», а «насос працював без води», потрібен промисловий контролер із сертифікацією. Не підходить там, де реакція має бути в мілісекундах: Linux загального призначення таких гарантій не дає. І стає тягарем, коли обʼєктів десятки: парк Pi у щитках треба оновлювати й моніторити, і з якогось моменту дешевше винести логіку на сервер, а на обʼєкті лишити простіший шлюз.

Окрема засторога про RS-485 на компʼютері: USB-перетворювач додає затримки, частина кадрів Modbus RTU «розпадається», і це виглядає як випадкові таймаути. Лікується перетворювачем з апаратним керуванням напрямком і розумними таймаутами. Що ще ламається на шині — у відповіді про RS-485 на обʼєкті.

Безпека: Modbus ніколи не дивиться в інтернет

У Modbus немає ані шифрування, ані паролів: будь-хто, хто дістався до шини або до TCP-порту, може читати й писати регістри. Тому пристрої ніколи не виставляються в інтернет напряму. Шлюз на обʼєкті сам ініціює зʼєднання з сервером через VPN або захищений канал, а вхідних портів на обʼєкті немає взагалі. Це найважливіше правило, і його найчастіше порушують, бо «так простіше налаштувати».

Друге — ролі. Оператор бачить стан і квитує тривоги, технік бачить діагностику, власник — зведення по обʼєктах, і ніхто з телефона не пише в регістри керування без окремого підтвердження. Третє — журнал дій: хто змінив поріг тривоги або поставив лінію на паузу і коли. Без цього кожен інцидент перетворюється на суперечку.

Четверте — оновлення. Механізм оновлення шлюзів із відкотом має бути закладений від початку, інакше кожне оновлення — це виїзд на обʼєкт.

Як рахувати вартість

Вартість платформи складається з трьох частин, і залізо — найменша. Перша — інтерфейс обладнання: документований Modbus підключається швидко, закритий пристрій означає заміну контролера, зовнішні датчики або відмову від цієї ділянки. Один цей факт зсуває кошторис більше, ніж усе інше в специфікації.

Друга — кількість обʼєктів і людей: у мережі з десяти майданчиків зʼявляються ролі, порівняння між точками, зведена звітність і обслуговування парку шлюзів. Третя, найчастіше недооцінена, — супровід: пороги міняти, тривоги підкручувати, пристрої додавати. Система без господаря через рік показує стан, якому ніхто не вірить.

Порядок, щоб не переплатити: спершу збір даних у базу — даних, яких не збирали, заднім числом не буде. Потім тривоги: вони окупаються швидше за будь-яку аналітику. І лише потім екрани з графіками. Конкретну суму без обстеження не назве ніхто чесний: вона залежить від того, що стоїть у щитку.

Типові помилки

Почати з дашборда. Красивий екран без надійного збору даних показує те, чого немає. Купити обладнання без карти регістрів, а потім шукати, як із нього дістати дані. Виставити Modbus TCP в інтернет «тимчасово». Зробити сервер єдиним місцем, де дані існують, і втратити добу подій при першому довгому обриві.

Проєктувати тривоги без гістерезису й затримок — і отримати сто повідомлень за ніч, після чого їх вимикають усі. Тягнути RS-485 зіркою замість лінії. Прошити Pi на звичайну картку в режимі запису й дивуватись, чому через рік він не піднявся після відключення світла.

І остання, найдорожча: вважати, що платформа — це проєкт із датою завершення. Обладнання змінюється, пороги пливуть, людей питають нові речі. Платформа, у якої є господар, живе роками; платформа, яку «здали», через рік стає екраном, на який ніхто не дивиться.

Часті питання

Чим IoT-платформа відрізняється від SCADA
SCADA виросла з диспетчеризації: оператор, екран, реакція в секундах, керування. IoT-платформа — зі збору даних із розкиданих пристроїв через ненадійні канали. Невеликому виробництву потрібне і те, і те: опитування по Modbus, як у SCADA, і буфер із досиланням, як у IoT.
Modbus RTU по RS-485 чи Modbus TCP
RTU по RS-485 — дешево, одна вита пара на десятки метрів і до кількох десятків пристроїв на шині, але потребує правильної топології й термінаторів. TCP прибирає проблеми шини й додає свої: комутатори, живлення, адресація, по пристрою на кожен вузол. Компроміс, що часто працює: короткі сегменти RS-485 усередині шаф і Ethernet між ними через шлюз RTU/TCP.
Чи потрібен сервер на обʼєкті, чи вистачить хмари
Опитувати шину RS-485 із хмари неможливо — на обʼєкті потрібен шлюз. Усе інше — історія, екрани, тривоги — може жити на сервері в хмарі або у вас. Якщо обʼєкт має працювати при відсутності звʼязку, логіка запуску й локальний буфер мають бути на місці незалежно від того, де сервер.
Скільки обʼєктів витримає одна така платформа
Опитування кількох десятків контролерів — не навантаження ані для шлюзу, ані для сервера. Межа зазвичай не в продуктивності, а в обслуговуванні: парком із десяти пристроїв у щитках хтось має займатись, і саме це визначає момент, коли логіку варто централізувати, а на обʼєкті лишити простіший пристрій.

Ще відповіді

Оновлено: 2026-10-01