Технології індустрії 4.0

Сервіс Watson IoT Platform надає вбудовані можливості по перетворенню «сирих» даних, отриманих від пристроїв в оброблені дані, які сприймаються застосунками та іншими сервісами. Цей процес дещо подібний до перетворенню даних, яке відбувається в SCADA-програмах.  Крім того, процес перетворення дає можливість універсалізувати інтерфейс застосунків до пристроїв. Наприклад, прилад із датчиком температури може передавати значення в різних одиницях та діапазонах, однак клієнтським застосункам потрібно передавати вже реальні значення в конкретних одиницях. Для цього, Watson IoT Platform дає можливість трансформувати та нормалізувати зібрані дані для створення єдиної логічної моделі, щоб застосунок міг взаємодіяти з різними пристроями однаково.

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

 

Компонент керування даними платформи Watson IoT включає функції «device twin» та «asset twin». Функція device twin (двійник пристрою) дозволяє скористатися перевагами збору, перетворення та нормалізації різних форматів даних пристрою в єдину логічну модель. Функція asset twin (двійник активу) дозволяє групувати різні пристрої, щоб створити Thing (річ), що є структурою даних більш високого рівня. Речі можна також об’єднувати в річ ще вищого рівня. Клієнтський застосунок може взаємодіяти з логічною моделлю незалежно від формату даних, який використовується окремими пристроями чи речами.

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

Device twin (двійник пристрою) - це хмарне цифрове представлення фізичного пристрою, підключеного до Watson IoT Platform. Двійник пристрою є логічною моделлю подій, які публікуються пристроєм і на пристрій. Після створення двійника пристрою, зв'язок з ним доступний для інших застосунків, незалежно від того, в якому він зараз режимі - онлайн чи офлайн. Властивості пристрою, включаючи інформацію про поточний стан пристрою (device state), можна отримати за допомогою запиту HTTP або підписавшись на тему по MQTT.

Близнюки пристроїв дають можливість:

• Надати розробникам застосунків узгоджені інтерфейси, щоб отримати доступ до подієво-керованих пристроєм даних, наприклад через REST.
• Доступ до стану пристрою.
• Нормалізувати дані з пристроїв різних марок або моделей, які публікують дані в різних форматах.
• Фільтрувати непотрібні дані.

Щоб створити близнюка пристрою, потрібно означити наступні ресурси в платформі Watson IoT:

• Структуру подій, які надсилаються пристроєм. Структура вхідної події означується у фізичному інтерфейсі, типі події та ресурсах схеми подій.
• Властивості, які потрібно записати. Ці властивості означують логічну структуру стану пристрою, яка може бути спожита застосунками. Властивості означуються в логічному інтерфейсі і ресурсах логічної схеми
• відображення подій фізичного інтерфейсу на властивості логічного інтерфейсу. Для відображення подій у властивості використовується «mappings resource»

Наступна діаграма показує два різних температурних пристрої (Temperature Devices) в окремих місцях. Один пристрій повідомляє дані в градусах Цельсія, а інший - у градусах за Фаренгейтом. Дані надсилаються на платформу Watson IoT у форматах "t" і "temp". Платформа Watson IoT автоматично перетворює градуси Фаренгейта в градуси Цельсія. Формати температури "t" і "temp" нормалізуються в логічному форматі "temperature". Застосунок може запитувати стан будь-якого пристрою, звертаючись до значення параметра " temperature" або підписавшись на нього по MQTT.

рис.23. 

Для реалізації такої схеми, в хмарному сервісі створюються два типи пристроїв: TSensor та  TempSensor, для яких вказується свій фізичний інтерфейс (рис.24). Фізичний інтерфейс (Physical interface) використовується для моделювання інтерфейсу між фізичним пристроєм і платформою Watson IoT. З фізичним інтерфейсом можуть бути пов'язані кілька типів подій. Події (events) - це механізм, за допомогою якого пристрої публікують дані на платформу Watson IoT. Пристрій керує вмістом подій і призначає ім'я для кожної події, яку він відправляє. Кожна подія містить властивості (Property) - дані, що несуть частину корисного навантаження. Так, наприклад, пристрій tSensor вміщує властивість “t” (див.рис.24). Подія публікується пристроєм, використовуючи ресурс типу події (event type resource). Тип події повинен посилатися на ресурс схеми подій (event schema resource). Ресурс схеми означує структуру опублікованої події.

рис.24.

Останнє представлення стану фізичного пристрою, яке може включати в себе всі властивості, які були зіставлені з різних вхідних подій записується в State пристрою. Логічний інтерфейс (Logical interface) - програмна конструкція, до якої можуть підключитися або підписатися застосунки, щоб побачити стан пристрою. Логічний інтерфейс використовується для означення нормалізованого перегляду Стану пристрою в платформі Watson IoT. Логічний інтерфейс повинен бути пов'язаний зі схемою логічного інтерфейсу. Стан оновлюється у відповідь на вхідні події пристрою.

Asset twins (Двійники активів)  дозволяють розвити концепцію близнюків пристрою ще на один рівень вище. Двійник активу дозволяє агрегувати (об’єднувати) пристрої в єдине ціле, яке називається Thing (Річ). Річ, або двійник активу, є подібною концепцією до двійника пристрою, який об’єднує в єдине ціле групу пристроїв як єдину логічну модель. Можна агрегувати також Речі, щоб сформувати більш високі рівні абстракції. Наприклад, річ "Номер" може об'єднати такі пристрої:

• Пристрій з датчиком температури (термометр)
• Пристрій з датчиком вологості (гігрометр)

"Поверх" може об'єднати кілька "номерів".

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

Двійники активів дають можливість:

• Агрегувати декількох двійників Пристроїв або Речей для означення нових Речей.
• Доступ до стану Речі.
• Керувати активами в цілому, не піддаючись до керування їх конкретними складовими.
• Фільтрувати непотрібні дані.
• Нормалізувати інтерфейси Речі, щоб відділити застосунки від складності та деталізації того, як створені конкретні Речі.

Щоб створити близнюка активу, потрібно означити такі ресурси в платформі Watson IoT:

• Структуру Речі. Структура Речі означується схемою Речі (Thing schema), яка означує агреговані пристрої або речі.
• Структуру бажаного стану Речі, яка складається з властивостей, які потрібно записати. Ці властивості означують логічну структуру стану Речі, яка може бути використана застосунками. Властивості означуються в логічному інтерфейсі і ресурсах логічної схеми.
• Відображення властивостей логічного інтерфейсу. Для відображення подій у властивості використовується «mappings resource»

Наступна діаграма показує приклад, в якому датчики температури та вологості на різних пристроях публікують дані про температуру та вологість до платформи Watson IoT Platform. Два близнюки пристроїв, кожен з яких представляє фізичний пристрій, мають пов'язані логічні інтерфейси і створені в платформі Watson IoT. Дані, що публікуються з температурного пристрою відображаються в логічний інтерфейс "IThermometer". Дані, опубліковані з пристрою вологості, відображаються в логічний інтерфейс "IHygrometer". Логічні інтерфейси агрегуються у тип Речі «кімната» з логічним інтерфейсом "IRoom". Логічний інтерфейс "IRoom" означує властивості температури і вологості і дозволяє створювати власну логічну модель, агрегуючи пристрої в одну Річ, з якою може взаємодіяти застосунок.

рис.25.

На рис.26 показане логічне відображення між пристроями та застосунками на платформі Watson IoT при використанні логічних та фізичних інтерфейсів.

рис.26.

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

3.1.  Створення в Node-RED структури даних пристрою та їх імітації  

Згідно поставленої на початку задачі, в хмару до двійника пристрою необхідно передавати вимірювальні параметри привода. У таблиці 1. наведені змінні, які потрібні для контролю стану двійника та їх адреси по Modbus TCP/IP для ПЧ ATV630. 

Таб.1. Змінні, що зчитуються з перетворювача частоти.

Назва властивості	ADR Modbus	Призначення	Примітка
STA	3201	статус	див. автомат стану (рис.39)
RFR	3202	плинна частота, в 0.1 Гц
I	3204	струм, в 0.1 А
M	3205	номінальний момент на двигуні, в 0.001 Н*м
U	3208	напруга,  В
P	3211	потужність, %
TOTDRIVE	3244	час роботи привода
TOTMOTOR	3246	час роботи двигуна
ALMTIME	3235	час тривоги
ACTPWR	3293	Оціночна потужність активної електричної енергії
CMD	8501	слово команди	запис
REF	8502	задана частота в 0.1 Гц	запис

Для можливості відлагодження застосунку, спочатку необхідно створити імітаційну програму з боку Edge. Для цього в локальному Node-RED необхідно зробити Веб-інтерфейс для зміни значень полів.

                Добавте нову закладку на UI інтерфейс Node-RED з назвою “ATV SIM” в яку добавте групу з назвою «ATV».

Добавте фрагмент програми для реалізації імітації зміни значень полів ATV з UI, який показаний на рис.27. Зробіть розгортання, відкрийте графічний інтерфейс користувача і встановіть значення усіх змінних. У вікні налагодження повинні з’явитися усі поля з відповідними значеннями (див. рис.27).     

   

рис.27.              

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

3.2.  Передача даних пристрою до платформи Watson IoT

                При певній події необхідно передати збережені в контексту потоку дані ATV до хмари. Назвемо цю подію «STA_change» і вона в майбутньому буде ініціюватися при зміні значення стану. Зараз поки ініціювання передачі буде проводитися вручну. Модифікуйте фрагмент програми, що відправляла дані в хмару (див. п.2.3), як це показано на рис.28.

                   Зробіть розгортання проекту. Зробіть ініціювання відправки даних.

рис.28.

                Перейдіть  у вікно консолі цифрового двійника в хмарі, у вікні «State» повинно відобразитися останнє повідомлення.

 

3.3. Створення простого фізичного інтерфейсу.

Перейдіть  у вікно консолі IBM Watson IoT Platform. Перейдіть в закладку  Device Types, виберіть тип ATV630 і на закладці Interface -> Simple flow натисніть кнопку «Create Physical Interface» (рис.29)

рис.29.             

На вкладці Interface натисніть Add Property (рис.30).

рис.30.

Повинно з’явитися вікно з останнім повідомленням (рис.31), яке необхідно вибрати (виставити опцію).  Якщо повідомлення не з’являться, зробіть повторну відправку повідомлень.  Після вибору натисніть “Next”

рис.31.

У вікні добавлення властивостей (рис.32) можна змінити поля повідомлення за необхідністю. Натисніть Add для добавлення властивості до фізичного інтерфейсу.

рис.32.

Після завершення добавлення властивостей до інтерфейсу натисніть Done (рис.36)

рис.33.

На даному кроці ми створили простий фізичний інтерфейс, що повністю ідентичний логічному інтеррфейсу.  

3.4. Створення точки доступу API для застосунків

Для доступу застосунків до IoT необхідно створити API key.

У вікні консолі IBM Watson IoT Platform перейдіть на вкладку API Keys (рис.34), і натисніть кнопку Generate API Key.

рис.34.

 

У наступному вікні заповніть поле Desription і натисніть Next.

рис.35.

 У наступному вікні у дозволах (рис.36) виберіть  Standard Application і натисніть «Generate Key».

рис.36

Після генерування ключу доступу, у вікні що з’явилося (рис.37) скопіюйте маркер (Authentication Token) в текстовий файл, бо він не буде пізніше відображатися. Як варіант, можете його зберегти в описі ключа (Description). 

рис.37

Ознайомтеся з роботою вузлів IBM IoT APP в довіднику Node-RED.

3.5.  Використання вузлів IBM IoT APP для доступу в хмарному застосунку Node-RED

Перейдіть  в хмарний застосунок Node-RED.

Деактивуйте усі створені до цього потоки.

Створіть новий потік з назвою «IoT APP».

Ознайомтеся з роботою вузлів IBM IoT APP в довіднику Node-RED.

Реалізуйте фрагмент програми показаний на рис.38. В API Key та API Token впишіть відповідні значення зі створеної точки доступу API. Зробіть розгортання проекту. Під вузлом IBM IoT повинен з’явитися зелений кружечок з написом «Connected»

рис.38

Ініціюйте в локальному Node-RED (з боку Edge) відправку даних в хмару. За допомогою вікна відлагодження подивіться що повідомлення дійсно прийшло до Застосунку. 

Зробіть копію екрану.

Змініть у вузлі IBM IoT тип Input Type на  “Device Status”. Зробіть розгортання проекту.

На локальному Node-RED (з боку Edge) деактивуйте потік «Edge».  У вікні відлагодження повинно з’явитися повідомлення «Disconnect». Повторно активуйте потік «Edge» у локальному Node-RED.

Увага, кожного разу перед завершенням роботи рекомендується деактивовувати потоки хмарного Node-RED, що використовують IoT, інакше хмарний застосунок буде використовувати лімітований трафік!