Архітектура IoT-рішення на реальному прикладі

Ми продовжуємо розповідати про компаніях-розробниках рішень (ISV). У цьому випуску технічний директор компанії «ИНПРОСИСТЕМ» AlexandrSurkov розповідає про досвід розробки архітектури охоронної IoT-системи СеСМИК.


Багато вважають, що поняття «Інтернету речей» нерозривно пов'язане з мережею, якою ми користуємося щодня. Можна уявити собі картину, де безліч пристроїв, об'єднаних в єдине ціле через глобальну мережу, обмінюються даними між собою і серверами і створюють цифрову картину світу. У даній статті я розповім про те, як ми робили систему, що об'єднує сотні датчиків.


Поняття «інтернет» варто розглядати значно ширше. В даному випадку це загальна для пристроїв мережу. Вона може містити 10 пристроїв, а може і 10 000. Може бути дротова, а може бути бездротова. Може розташовуватися в одній кімнаті, а може охоплювати кілька країн. Все залежить від завдань, які ставляться перед системою.

При цьому створення навіть невеликої мережі пристроїв супроводжується безліччю труднощів.

Постановка завдання

Нам було поставлено завдання по розробці системи охорони периметра. Периметр — це паркан, що оточує деякий об'єкт. Його довжина нічим не обмежена.

Система створювалася з нуля. До моменту початку проектування існував прототип датчика, здатного збирати коливання периметра, проаналізувавши які, можна було чітко визначити факт подолання або руйнування паркану. Досвідченим шляхом ми визначили, що датчики потрібно ставити приблизно через кожні 10 метрів.

Крім датчиків планувалися ще керуючі пристрої з реле та керовані пристрої з «сухим контактом». Система повинна працювати у вуличних умовах при широкому діапазоні температур і погодних явищ.

Отже, є:
  • 3 типи пристроїв;
  • Мінімум 100 пристроїв на кілометр;
  • Кількість кілометрів не обмежена;
  • Система повинна мати вуличне виконання.


Відразу можна виділити головні питання по архітектурі:
  • Організація передачі даних і живлення;
  • Розподіл потоків інформації: де і як аналізувати дані;
  • Безпеку рішення: які протоколи використовувати;
  • Як керувати такою кількістю пристроїв.


Загальна схема рішення

Clemens Vasters написав прекрасну статтю про те, з чим стикається розробник системи «Інтернету речей». Ці ж проблеми довелося вирішувати і нам.

Багато рішення диктувалися ГОСТами та іншими вимогами до таких систем. Але багато чого довелося придумувати самим.

Спершу потрібно було зрозуміти, як розподілити інформаційні потоки в системі. Для аналізу коливань використовувалася як тимчасова, так і частотна складова. Діапазон частот від 0 до 500 герц. Значить, заміри потрібно робити 1000 разів в секунду. Кожне вимірювання робляться за 3 осях по 10 біт на кожну.
Разом 3*10*1000 = 30 кілобіт в секунду тільки від одного датчика. На кілометр (100 датчиків) це вже 3 мегабіти.

Передати ці дані можна, але як їх обробляти? Периметр в 10 км давав би вже 30 мегабіт даних за секунду. Виходить, що навантаження на сервер зростає із збільшенням кількості пристроїв.

Було прийнято рішення, що кожен датчик буде обробляти дані сам і віддавати тільки факти тривог. Це значно знизило обсяг даних і розподілило обчислювальне навантаження.

Організація мережі була обрана дротова з-за того, що бездротова вимагає батареї. Так як система у нас реального часу, то термін життя батареї буде дуже маленький. Крім того, негативні температури сильно зменшують ємність живильних елементів. Та й заглушити бездротовий зв'язок відносно легко, а це вже є дуже істотним недоліком системи безпеки.

Гости забороняють прокладати по огорожі 220В, тому «харчуватися» наші пристрої будуть від постійної напруги.

В якості архітектури мережі ми вибрали шину. Це дозволило не тягнути дріт до кожного датчика.

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

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

Інші виконавчі пристрої так само, як і датчики, які підключаються до шини.

У підсумку виходить така схема:



Вибір протоколів і способів взаємодії

Тепер необхідно було визначитися з тим, як саме будуть передаватися дані. Кожен пристрій у системі бере участь у 2-х типах обміну:
  • команда від сервера — відповідь сервера;
  • асинхронне подія від пристрою до сервера.


Команди використовуються для зміни стану пристрою і його налаштування. Події генеруються у разі, якщо у пристрої з'являється інформація для сервера (наприклад, тривога від датчика)

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

В якості шини вибір стояв в основному між RS485 і CAN. Тільки ці два стандарти дозволяли підключити безліч пристроїв на досить великих відстанях.

В результаті аналізу ми обрали CAN. Параметри мережі обрали наступні:
  • Максимум 500 метрів;
  • Максимум 100 пристроїв;
  • Швидкість 50 кбіт.


На нашу думку, це є оптимальним балансом швидкості, щільності пристроїв і довжини мережі для нашої системи.

У шлюзі використовується мікроконтролер з двома драйверами CAN на борту, що дозволило зробити 2 флангу і закрити одним шлюзом 1 км.

У CAN є ще й інші переваги: завадостійкість, дозвіл колізій і гарантована доставка пакетів адресату. Крім того, він має досить сильну модель діагностики помилок в мережі.

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

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

А хотілося реалізувати систему за принципом PlugAndPlay:
  • Підключення і відключення пристроїв без відключення живлення;
  • Автоматичне визначення зміни конфігурації системи;
  • Система повинна почати працювати одразу після складання
.

У підсумку нам вдалося зробити те, що було задумано, написавши свій простий, але досить потужний протокол. Так як мова йде про маленьку пропускної здатності шини і невеликої обчислювальної потужності мікроконтролерів, то тип протоколу був обраний байтовий. З-за оптимізації пропускної здатності протокол вийшов досить сильно пов'язаним з CAN, але нам вдалося зробити його теоретично переноситься на інші стандарти.

Протокол дозволяє:
  • виявляти «на льоту» підключені пристрої;
  • виявляти відключення пристроїв;
  • працювати в режимі запит-відповідь;
  • передавати асинхронні події;
  • передавати потокові дані з пристрою.


Налагодивши обмін між пристроєм та шлюзом, залишилося розібратися з сервером.

Шлюз, що має вихід Ethernet. Це найбільш універсальна технологія передачі даних. Мережа може бути організована як завгодно: оптичними каналами, бездротовими каналами, звичайною кручений парою — при цьому ми завжди зможемо підключитися до цієї мережі, використовуючи оптичні перетворювачі і точки доступу. Це дозволяє замовнику проектувати інфраструктуру мережі будь-якої складності і протяжності.

Передача даних була організована з допомогою Сокетів Берклі на базі TCP/IP. Таке рішення дозволяє серверу гарантовано отримувати інформацію від будь-якого датчика і не залежати від програмних платформ. Протокол поверх TCP/IP ми розробили так само свій. Він теж байтовий, для оптимізації роботи на стороні мікроконтролера. У байтових протоколів є великий мінус: складність з подальшою модифікацією. Однак текстовий протокол для микроконтроллерного пристрою занадто надмірний.

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

В результаті ми отримали гнучку модульну систему, керовану через єдиний центр — сервер. Він так само має свій протокол, який дозволяє підключатися до нього і отримувати події в системі. Це дозволяє використовувати нашу систему як складову частину великого комплексу і масштабувати її практично до нескінченності.



Питання безпеки

З безпекою системи виявилося все досить просто. Справа в тому, що всі мережі, які знаходяться на об'єктах, що охороняються, самі по собі є охоронюваними об'єктами. Таким чином всі мережі, з якими працює система, стають «довіреними».

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

Тому ніякими особливими способами захисту інформації ми не користувалися, обмежившись лише базовими принципами.

Що далі?

Незважаючи на те, що система вже сформувалася, ми продовжуємо активно її розвивати і шукати нові способи застосування.

Одним з напрямків розвитку системи є машинне навчання. Використовуючи ці алгоритми, можна фільтрувати регулярні перешкоди, такі як шум від вантажівок, поїздів та літаків. В експериментах для цього напрямку нам дуже сильно допомагає Azure Machine Learning. Він містить безліч готових рішень для машинного навчання, що дозволяє досить швидко отримати результати.
Аналіз коливань огорожі далеко не єдиний спосіб використання технологій, закладених в нашу систему. Контроль вібрацій висотних будівель, трубопроводів і газопроводів, крихких вантажів, вібродіагностика турбін і рухомих частин різних конструкцій — далеко не повний список можливостей.

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

Дуже перспективними нам здаються нові технології IoT від Microsoft. Єдина платформа Windows теоретично здатна заощадити багато часу, так як можна написати загальний для різних апаратних платформ код.

А для обробки даних використовувати Azure IoT Suite. За заявами розробників, він містить у собі інструменти, що дозволяють не тільки об'єднувати і управляти безліччю IoT пристроїв, але і обробляти великі об'єми даних з них. Це ми і збираємося перевірити в найближчому майбутньому.

Висновок

Коли ми починали розробку системи, поняття "Інтернету речей" ще не набрав такої популярності. Досвіду було небагато, з багатьма речами ми зіткнулися в перший раз. Зараз, коли про цієї концепції багато пишуть і розповідають, стало ясно, що обрано правильний шлях.

Робота була складною та довгою. Створення першої комерційної версії системи зайняло приблизно 3 роки. Перший пішов на розробку інженерних зразків окремих пристроїв. Ще рік був витрачений на розробку системи в цілому. Третій рік йшла доведення і налагодження.

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

Зараз система змонтована і працює на багатьох об'єктах в Росії і за кордоном. Найбільший з них складається з декількох периметрів загальною протяжністю понад 15 км. В проектуванні знаходяться і більш масштабні об'єкти.

Більш детальну інформацію можна отримати на сайті системи.

Джерело: Хабрахабр
  • avatar
  • 0

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.