Хмарні технології в структурі ІОТ

Принципи 

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

Гетерогенність. 

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

Безпека.

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

Гіпер-масштабні розгортання. 

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

 Гнучкість. 

Гетерогенні потреби ринку IoT вимагають відкритого складу послуг і компонентів. Еталонна архітектура побудована на принципі композитності, що дозволяє створювати рішення IoT шляхом поєднання ряду будівельних блоків і дозволяє використовувати різні технології першої або третьої сторони окремі концептуальні компоненти. Ряд точок розширення дозволяє інтегруватися з існуючими системами та програми. Високомасштабна, керована подіями архітектура з посередницькою комунікацією є основою вільно пов'язаної склад послуг і модулів обробки. 

Поняття даних 

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

Моделі пристроїв і даних 

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

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

Записи та потоки даних 

Рішення IoT розроблені з урахуванням фундаментального аспекту: пристрої, що періодично передають записи даних, які представляються, аналізуються і зберігаються як множинні і безперервні потоки даних. Повідомлення, події, телеметрія, оповіщення та прийом є термінами, які зазвичай використовуються при описі потоків даних IoT. Записи даних зазвичай виписуються за часом, сортуються за часом і асоціюються принаймні з одним джерелом. Наприклад, запис телеметрії може містити час вимірювання і час, коли дані приймаються, і може бути пов'язаний з ім'ям пристрою, де проводиться вимірювання, до шлюзу, де збирається телеметрія, концентратора, де телеметрія поглинається і т.д. 

Поглинання - це процес завантаження записів даних у сховище через шлюз, наприклад, Azure IoT Edge і Azure IoT Hub. Записи даних можна приймати одночасно або масово. Зміст потоків може бути даними реального часу або минулим трафіком, що повторюється. Повідомлення та події є взаємозамінними термінами, які використовуються при посиланні на записи даних, що генеруються підключеними пристроями. Термін телеметрія використовується спеціально для повідомлень, що несуть дані, повідомлені датчиками пристрою, наприклад, поточна температура, що надходить з датчика температури на пристрій. Записи телеметрії можуть містити одну або кілька точок даних. Наприклад, пристрій з одним датчиком вологості і одним датчиком температури може посилати вологість і температуру вимірювання в одному повідомленні або в окремих повідомленнях. Пристрої можуть мати декілька встановлених датчиків і можуть посилати записи з вимірами, повідомленими всіма датчиками або тільки значення, які змінилися з часу останньої телеметрії, що були надіслані, наприклад, для зменшення кількості переданих даних.

Взаємодія пристрою 

Еталонна модель приймає принципи комунікації для пристроїв, які потенційно розгортаються в ненадійному фізичному просторі. Застосовуються наступні принципи: 

• Пристрої не приймають небажані мережні з'єднання. Всі з'єднання та маршрути встановлені при налаштуванні. 

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

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

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

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

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

Загальний шаблон для інформування пристроїв із обмеженим енергоспоживанням про важливі команди під час відключення є за допомогою використання каналу зв'язку поза смугою, такого як протоколи стільникових мереж і послуги. Так наприклад, SMS-повідомлення може бути використано для "пробудження" пристрою і доручення йому встановити вихідну мережу підключення до свого «домашнього» шлюзу. Після підключення пристрій отримає команди та повідомлення.

Комунікаційні протоколи

 Сьогодні для сценаріїв пристроїв доступно багато протоколів зв'язку, кількість яких зростає. Вибір з тих, що використовуються в системах гіпермасштабу, щоб забезпечити безпечні операції, забезпечуючи при цьому можливості та гарантії, обіцяні обраними протоколами, вимагають значної експертизи у побудові розподілених систем. Проте існує величезна кількість існуючих пристроїв, для яких вже було зроблено вибір протоколу, і ці пристрої повинні бути інтегровані в рішення. У цій еталонній моделі обговорюються переважні варіанти вибору протоколу зв'язку, пояснюються потенційні компроміси з ними виборів, а також явно дозволяє розширюваність, адаптацію та локальну обробку протоколів на місцевому шлюзі (IoT Edge), шлюз протоколу, заснований на хмарі, або під час обробки потоку.