SCADA для малого бізнесу: коли вистачить Raspberry Pi

Що саме треба бачити

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

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

Де Raspberry Pi справді доречний

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

Чому саме він, а не промисловий контролер: вартість заліза тут не головна економія. Головна — те, що на ньому звичайний Linux, а отже вся звична розробка, звичні бібліотеки, звичне оновлення. Ціна володіння виходить нижчою не через залізо, а через людей, які вміють із цим працювати.

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

Де він уже не підходить

Коли від системи залежить безпека людей або цілісність обладнання. Якщо збій керування означає не «не порахували виручку», а «насос працював без води» — потрібен промисловий контролер із відповідною сертифікацією, і це не місце для економії.

Коли реакція має бути в реальному часі, тобто в межах мілісекунд. Linux загального призначення таких гарантій не дає в принципі.

Коли обʼєктів стає багато. Десяток Pi у щитках — це вже парк, який треба оновлювати, моніторити й комусь обслуговувати. З якогось моменту дешевше винести логіку на сервер, а на обʼєкті лишити простіший і надійніший пристрій.

Що робити, коли обладнання нічого не віддає

Найдорожчий сценарій — закритий пристрій без документованого інтерфейсу. Варіантів зазвичай три. Замінити контролер на той, що вміє Modbus, — найчистіше й найдорожче. Знімати сигнали фізично: лічильник імпульсів, датчик струму на лінії насоса, сухий контакт. Це дає менше даних, але часто достатньо: факт роботи й тривалість.

Третій варіант — попросити дані в постачальника обладнання. Іноді інтерфейс є, просто про нього не написано в паспорті. Питання коштує одного листа й економить тижні.

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

З чого почати, щоб не переплатити

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

Другий крок — сповіщення про те, що зламалось. Не звіт, а повідомлення: «пост 3 не відповідає двадцять хвилин». Воно окупається швидше за будь-яку аналітику, бо скорочує простій.

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

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