Как да изградите система за мониторинг и анализиране на вашите вградени устройства в IoT

Тази публикация очертава готварска книга, която използвахме за създаването на система за наблюдение на свързана вградена система. Използвахме го, за да създадем такова, което може да наблюдава всички видове устройства (дори тези, които работят с Bare-Metal и RTOS), и решихме, че би имало смисъл да помагаме на другите да изграждат подобни системи. Тази готварска книга може лесно да се използва за наблюдение на оперативните данни на устройството, както и на действителните ви данни за приложението. След внедряване на IoT система трябва да се уверите, че всичко работи както трябва и да затворите контура за обратна връзка от полето. Предстои ви да ви покажем как да изградите един, използвайки инструменти с отворен код почти безплатно. Имаме и публикация, която очертава необходимостта от такава система (Check It Out).

Нека се съсредоточим върху три неща:

  1. Код на устройството и шлюза, който предава данни към централизиран бекенд.
  2. Резервни дни и база данни за обработка и съхраняване на данните.
  3. Frontend за показване на данните.

След като тези три градивни блока са налице, въздействието върху наблюдаваните данни и свързването им към вашите операционни процеси е сравнително лесно лесно.

1. Устройство и инструмент за регистриране на шлюза

Когато мислите за помощната програма за регистриране, хоствана на крайните ви устройства и шлюзове, нещата, които се появяват, са:

  • Трябва да има малък отпечатък.
  • Никога не разбивайте устройството ми.
  • Консумирайте малко мощност.
  • Не е разрушително за кода на приложението.

Устройствата ви означават вашия код. Трудно е да се обобщи тази тема, тъй като много зависи от комуникационния канал, използван за връзка с интернет. Ние отваряме инструмент за регистриране, който регистрира събития от вашите крайни устройства и го изпраща към вашия шлюз / бекенд. Ако използвате nRF52 с BLE GATT и шлюз, ние ви предоставяме и проба, която работи извън кутията. Отидете в нашия GitHub, за да започнете.

1. jumper-ulogger - представлява рамка за регистриране на отпечатъци под 500B памет, която интегрирате в крайното си устройство (с примери за пренасяне към nRF52 устройство и CC3200).
2. jumper-logging-agent - е услугата, която работи на шлюза.
3. jumper-ble-logger - пример за услуга на регистриращ агент за BLE GW.

Ако имате някакви проблеми или въпрос, изпратете ни бележка на info@jumper.io.

2. Backend и база данни

Тук трябва да обърнете внимание по-внимателно, защото тук има някои добри неща :-) Препоръчвам да използвате следните набори от инструменти, за да направите тази работа:

  • База данни от ключова стойност за съхранение на моментна снимка на състоянието на устройството (тествахме Firebase на Google и DynamoDB на Amazon). Това е вашето сенчесто устройство.
  • База данни от времеви серии, която съхранява данни за исторически устройства и данни за заявки за отчети и графики (тествахме InfluxDB).
  • Без сървър инфраструктура по избор за минимално необходима обработка (използвахме AWS Lambda и Google Cloud Functions, използвайки рамката без сървър).

Нека го разбием с помощта на пример. Кажете, че управлявате автопарк от 10 000 устройства и искате да наблюдавате живота на батерията и силата на сигнала на устройството. Ако не сте чувствителни към честотна лента и консумация на енергия, може да решите да изпращате данните на устройството в бекенда възможно най-често. Съобщение за данни към сървъра ще изглежда така: (време, ниво на батерията, сила на сигнала). Ако сте загрижени за широчината на честотната лента, което е нещо, за което установихме, че е много често срещано, може да разделите съобщенията между живота на батерията и силата на сигнала, за да предотвратите изпращането на дублиращи се данни към бекъна. Възможно е дори да не изпратите времето на събитието, тъй като можете автоматично да маркирате времето в бекенда.

В първия случай, когато непрекъснато изпращате всички данни от устройството в бекенда, нямате нужда от БД ключ-стойност. Просто съхранявате съобщението директно в базата данни от времеви серии.

Във втория случай ще изпращате данни в частични съобщения, съдържащи подмножество от данните, които наблюдавате. Това е мястото, където започва DB-ключ-стойност. БД-ключ-стойност поддържа актуално отражение на състоянието на вашето устройство. Всеки път, когато се получи частично съобщение, неговите данни се актуализират в БД-ключ-стойност. След това актуализираното състояние на устройството се извлича от DB-ключ-стойност и се съхранява в базата данни от времеви серии. Препоръчваме тази архитектура, тъй като е по-вероятно да мащабира, отколкото просто да използва DB от времеви серии. БД от времеви серии са наистина добри за вмъкване на данни и обработка на сложни заявки. Това не се увеличава толкова добре, когато става въпрос за изпълнение на много малки заявки. От друга страна, DB-тата с ключова стойност са наистина страхотни.

В крайна сметка използвахме Google Firebase за магазина ключ-стойност по множество причини. Ние всъщност изградихме на него всички двигатели на приложенията, автентификация и БД, така че използването му за данните на устройството беше лесен избор.

Що се отнася до DB от времеви серии, в крайна сметка използвахме InfluxDB, хостван на сървърите на InfluxData за 160 долара на месец. Не е супер евтино, но мащабира до 10 000 устройства (не зависи от натоварването на данните). Това е по-малко от 0,25 долара годишно на устройство. Сладка! Недостатъкът на InfluxDB е, че трябва наистина да внимавате по отношение на полетата с данни, които определяте като индекси. Базата данни може лесно да страда от проблеми с производителността поради прекомерно индексиране.

Пробвахме и Keen.io. Keen е по-добър, когато става въпрос за запитване на данни. Недостатъкът е ценообразуването. Трябва да отбележа, че обсъдихме няколко проблема с ценообразуването поради някои грешки, които допуснахме при вмъкването на данни в Keen, и намерихме техния екип за поддръжка за много отзивчив и справедлив.

Лепилото, което събира всичко, е резервният код, който се използва за удостоверяване и съхраняване на DB. Ние сме много опитни, когато става въпрос за мащабиране на резервни системи. Нашата препоръка е проста - не създавайте резервни системи. Използвайте опции без сървър. Ние проектирахме обикновена микро-услуга, която получава съобщение от устройство, съхранява актуалните данни на устройството в DB с ключова стойност и съхранява пълните данни в БД от времеви серии. Да - по-скъпо е от това да управляваш собствената си инфраструктура. Но времето, което ще инвестирате в поддържането на сървъри, когато достигнете дори 3000 устройства, ще компенсира разходите в полза на архитектурата без сървър.

Frontend

Тук няма нужда да измисляте и колелото. Keen предоставя интерфейс за генериране на графики и вграждането им в други уебсайтове. Използвахме Grafana като интерфейсна платформа, тъй като тя е в комплект с плана на InfluxDB $ 160 / m. Grafana също така свърза друг солиден избор за вашата по-дългосрочна DB - elastsearch.

Подробна системна схема

резюме

Избирането на управлявани и без сървър опции ни помогна да създадем система, която да се справи с товар до 10 000 устройства. Мащабирането нагоре от там изисква само добавяне на повече случаи на база данни. Ако търсите още по-лесен избор - отидете с еластична изследователска версия, която се предоставя като услуга от Amazon.

Вземете виртуална лаборатория Jumper за тестов завъртане

Ако качеството на продукта е важно за вас и се борите с тестването на вашия вграден системен софтуер IoT, погледнете виртуалната лаборатория Jumper. Jumper Virtual Lab е виртуален клон за производство, който ви позволява да разработвате, тествате и прилагате непрекъснат процес на интеграция във вашата вградена система с лекота с виртуални устройства. Започнете да използвате Jumper безплатно сега.

Споделете мислите си

Чувствайте се свободни да споделите мислите си и да се свържете с нас в секцията за коментари или на feedback@jumper.io.