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

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

Пристрої, підключення пристроїв, польовий шлюз (Edge Devices), Cloud Gateway Пристрої можуть бути підключені безпосередньо або опосередковано через шлюз поля (IoT edge device). І пристрої, і польові шлюзи можуть реалізовувати функції розвідки краю. Це дає можливість агрегування та скорочення даних необробленої телеметрії раніше транспортування до бекенда та можливості прийняття рішень на місцевому рівні. Нижче наведено концептуальне представлення різних варіантів підключення пристроїв до рішень IoT. Позначена цифра відповідає чотирьом основним схемам підключення, визначеним таким чином: 

1. Пряме підключення пристрою до хмарного шлюзу: для пристроїв, що підтримують ІP, які можуть встановлювати безпечні з'єднання за допомогою Інтернет. 

2. З'єднання через польовий шлюз (IoT Edge Device): для пристроїв, що використовують специфічні для промисловості стандарти (наприклад, протокол обмеженого застосування [CoAP8 ] або OPC UA), технології комунікації малого діапазону (такі як Bluetooth або ZigBee), а також для пристроїв, обмежених ресурсами, які не можуть розміщувати стек TLS/SSL, або пристрої, які не підключаються до Інтернету. Цей варіант також корисний, коли виконується агрегація потоків і даних на польовому шлюзі перед переходом до хмари. 

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

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

Пряма комунікація між пристроями і пристроєм дозволяє здійснювати керування локальною мережею та інформаційний потік, або спільні операції, коли кілька пристроїв виконують скоординовані дії. Чисто місцеві взаємодії виходять за рамки цієї архітектури і охоплені такими галузевими стандартами, як AllJoyn, UPnP / DLNA та інші. Важливо розуміти термінологію та ключові компоненти, які використовуються для опису підключення пристроїв до Azure IoT.

 Пристрої 

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

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

Польовий Шлюз (Edge Devices) Польовий шлюз, або крайовий пристрій, є спеціалізованим пристроєм або програмним забезпеченням загального призначення, що діє як комунікаційний агент і, потенційно, як локальний пристрій управління системою і пристроєм обробки даних концентратора. Польовий шлюз може виконувати локальну обробку і управління функціями для пристроїв і може фільтрувати або агрегувати телеметрію пристрою і таким чином зменшують обсяг даних, що передаються до бекенда в хмарі. Область Польового шлюзу поля включає в себе сам шлюз і всі приєднані до нього пристрої. Як випливає з назви, Польові шлюзи діють поза призначеними засобами обробки даних і зазвичай розташовуються між пристроями.

Шлюз хмари (хмарний шлюз) Шлюз хмари дає можливість віддаленого зв'язку з пристроями, або з крайовими пристроями, які потенційно перебувають у декількох різних сайтах. Шлюз хмари буде або доступним через загальнодоступний Інтернет, або накладання мережевої віртуалізації (VPN) або приватні мережні підключення до центрів обробки даних Azure, щоб ізолювати шлюз хмари та всі його прикріплені пристроїв або крайніх пристроїв з іншого мережевого трафіку. Він, як правило, керує всіма аспектами зв'язку, включаючи управління з'єднанням на рівні транспортного протоколу, захист шляху зв'язку, аутентифікації пристрою та авторизації до системи. Шлюз дотримується збору та пропускної квоти, а також збирає дані, які використовуються для виставлення рахунків, діагностики та інших завдань моніторингу.

Телеметричні та інші повідомлення від пристроїв вводяться в хмару, а обмін повідомленнями здійснюється за допомогою шлюзу. Дані стійко буферизуються, що не тільки розв'язує відправник від приймача, але і дозволяє множину споживачів даних. Зазвичай трафік із сервісу сервера на пристрої (наприклад, сповіщення та команди) реалізовано за допомогою шаблону "Вхідні". Навіть коли пристрій перебуває в автономному режимі, повідомлення, надіслані до нього, будуть довго зберігатися в черзі (папка "Вхідні" для пристрою) і доставлятися після підключення пристрою. Важливим є врахування можливого часу затримки подій, особливо для чутливих до часу команд, таких як "відкрити автомобіль або домашні двері" або "запустити автомобіль або машину". Шаблон папки "Вхідні" зберігатиме повідомлення в тривалий час (для заданої тривалості TTL), після чого термін дії повідомлень закінчується. Брокерська комунікація через описані структури дозволяє розв'язувати край з компонентами хмари у залежності від часу виконання, швидкості обробки та поведінкових контрактів. Це також дає можливість композиції видавцям і споживачам, необхідним для побудови ефективних, масштабних, керованих подіями рішень. 

Концентратори подій Azure.

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

Концентратори подій також можуть використовуватися в сценаріях IoT, крім Hub IoT, для вторинні телеметричні потоки (тобто телеметричність без пристрою) або збір даних з інших системних джерел (таких як подачі погоди або соціальні потоки). Концентратори подій не пропонують ідентифікацію пристрою або можливості команд і керування, тому це може бути придатним тільки для додаткових потоків даних, які можуть корелювати з телеметрією пристрою на сервері, але ні як основний шлюз для підключення пристроїв. Концентратори подій Azure підтримують підтримку AMQP 1.0 з додатковими параметрами Підтримка WebSocket, а також протоколи HTTPS. Підтримка додаткових протоколів поза AMQP, MQTT і HTTP може бути реалізована за допомогою протокольного шлюзу модель адаптації. CoAP є прикладом протоколу, який може використовувати цю модель.

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

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

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

 • Пряме підключення з рівня пристрою / програмного забезпечення

• Зв'язок через агентів 

• Використання компонентів клієнта, інтегрованих у прикладний/програмний рівень пристрою або шлюзу 

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

Агенти. Агент - це компонент програмного забезпечення, встановлений на пристрої або польовому шлюзі, який виконує дії від імені іншої програми або компоненти управління. У IoT агенти зазвичай контролюються і діють на компоненти працює на хмарі backend. Наприклад, у випадку команди, надісланої пристрою, агент отримає можна виконати безпосередньо на пристрої. Агенти можуть бути власними агентами, спеціально написаними для конкретного програмного рішення, або агентами на основі стандартів реалізації окремих стандартів, таких як OMA LWM2M. В обох випадках для розробників пристроїв зручно інтегрувати і покладатися на інкапсульовані можливості агентів; однак існують певні обмеження. Як правило, агенти представляють собою замкнуту систему, обмежену можливостями, наданими агентом для набору підтримуваних платформ. Переносимість на інші платформи або налаштування та розширення за межі наданої функціональності зазвичай не є можливо. 

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