Raspberry Pi на обʼєкті: коли це нормально, а коли ні

Коли це нормально

Коли пристрій збирає й передає дані, але нічим не керує. Шлюз, що опитує лічильники по Modbus і відправляє показники в систему, — гарний випадок: якщо він зависне на десять хвилин, ви втратите десять хвилин графіка, а не зіпсуєте продукт.

Коли поруч є кому перезапустити. Обʼєкт із персоналом, куди можна доїхати за годину, — прийнятний ризик.

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

Коли категорично ні

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

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

Три речі, які вбивають Pi на обʼєкті

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

Карта памʼяті. Постійний запис логів убиває картку за місяці. Лікується перенесенням записів у памʼять і рідкісним скиданням на диск — або нормальним накопичувачем замість картки.

Температура й пил. Щиток на вулиці влітку — це не кімнатні умови. Корпус, вентиляція й фільтр коштують дешевше за один виїзд.

Як робити правильно

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

І головне: пристрій має сам повідомляти, що з ним не так. Той, що мовчки перестав надсилати дані, гірший за той, що надсилає помилку.

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