Тестування Fledge

Після встановлення ви можете протестувати Fledge. Наскрізний тест складається з трьох типів тестів:

• Південна сторона (South), тобто тестування збору інформації з мікросервісів South і пов’язаних плагінів
• Північна сторона (North), тобто тестування завдань, які надсилають дані на північ історикам, базам даних, корпоративним і хмарним системам
• Сторона Схід/Захід (East/West), тобто тестування взаємодії зовнішніх програм із Fledge через REST API.

У цьому розділі описано, як тестувати Fledge у цих трьох напрямках.

Перші перевірки: Статус Fledge

Перш ніж ми почнемо, давайте переконаємося, що Fledge запущений і працює, і що у нас є завдання і сервіси для виконання тестів. Спочатку виконайте команду fledge status, щоб перевірити, чи Fledge вже запущено. Результатом виконання команди може бути:

• Fledge not running. - це означає, що ми повинні почати Fledge з fledge start
• Fledge starting. - це означає, що ми запустили Fledge, але початкова фаза ще не завершена. Ви повинні трохи почекати (від кількох секунд до приблизно хвилини), щоб побачити, як Fledge запускається.
• Fledge running. - а також додаткові рядки з інформацією про безвідмовну роботу та іншу інформацію. Це означає, що Fledge запущений і працює, отже, він готовий до використання.

Коли у вас запущений Fledge, перевірте додаткову інформацію, надану командою fledge status:

$ fledge status
Fledge v1.8.0 running.
Fledge Uptime:  9065 seconds.
Fledge records: 86299 read, 86851 sent, 0 purged.
Fledge does not require authentication.
=== Fledge services:
fledge.services.core
fledge.services.storage --address=0.0.0.0 --port=42583
fledge.services.south --port=42583 --address=127.0.0.1 --name=Sine
fledge.services.notification --port=42583 --address=127.0.0.1 --name=Fledge Notifications
=== Fledge tasks:
fledge.tasks.purge --port=42583 --address=127.0.0.1 --name=purge
tasks/sending_process --port=42583 --address=127.0.0.1 --name=PI Server

Проаналізуємо результат команди:

• Fledge running. - Мікросервіс Fledge Core запущено на цій машині, і він відповідає на команду статусу як running, оскільки інші базові мікросервіси також запущені.
• Fledge uptime: 282 seconds. - Це простий час безвідмовної роботи за секунду, наданий мікросервісом Core. Це еквівалент методу ping, викликаного через REST API.
• Fledge records: - Це підсумкова кількість записів, отриманих від датчиків і пристроїв (південь), надісланих до інших сервісів (північ) і видалених із буфера.
• Fledge authentication - Цей рядок описує, чи має користувач або програма пройти автентифікацію в ogLAMP, щоб працювати з REST API.

У наступних рядках наведено список модулів, які працюють у цій установці Fledge. Вони розділені крапками й описані таким чином:

• Префікс fledge завжди присутній і ідентифікує модулі Fledge.
• Наступний термін описує тип модуля: services для мікросервісів, tasks для завдань тощо.
• Наступний термін є назвою модуля: core, storage, north, south, app, alert
• Останній термін — це назва плагіна, який виконується як частина модуля.
• Можуть бути доступні додаткові аргументи: це аргументи, які ядро передає модулю під час його запуску.

• === Fledge services: - Цей блок містить список мікросервісів, запущених на платформі Fledge.
  • fledge.services.core це сам мікросервіс Ядра
  • fledge.services.south --port=44180 --address=127.0.0.1 --name=COAP - Цей мікросервіс South є прослуховувачем даних, які надсилаються до Fledge через протокол CoAP
• === Fledge tasks: - Цей блок містить список завдань, які виконуються на платформі Fledge.
  • fledge.tasks.north.sending_process ... --name=sending process це завдання North, яке готує та надсилає дані, зібрані модулями South, до OSIsoft PI System у форматі OMF (OSIsoft Message Format).
  • fledge.tasks.north.sending_process ... --name=statistics to piце завдання North, яке готує та надсилає внутрішню статистику до OSIsoft PI System у форматі OMF (OSIsoft Message Format)..

Привіт, Туманний Світ

Вихід команди fledge status дає вам уявлення про модулі, що працюють на вашій машині, але давайте спробуємо отримати більше інформації від Fledge.

Fledge REST API

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

Це короткий перелік методів, доступних адміністраторам. Більш детальний список буде доступний найближчим часом: - ping забезпечує безперебійну роботу мікросервісу Fledge Core - statistics надає набір статистичних даних платформи Fledge, таких як зібрані, надіслані, видалені, відхилені дані тощо. - asset надає список активів, показання яких буферизуються у Fledge. - category надає список конфігурації модулів і компонентів у Fledge.

Корисні Інструменти

Системні адміністратори та розробники, можливо, вже мають свої улюблені інструменти для взаємодії з REST API, і вони, ймовірно, можуть використовувати ті самі інструменти з Fledge. Якщо ви не знайомі з жодним інструментом, ми рекомендуємо один із цих:

• Якщо ви знайомі з оболонкою Linux і командними рядками, є найпростішим і найкориснішим доступним інструментом. Він постачається з кожним дистрибутивом Linux або ви можете легко додати його, якщо він недоступний у стандартній установці.
• Якщо ви віддаєте перевагу інтерфейсу, схожому на браузер, ми рекомендуємо . Postman — це програма, доступна в Linux, MacOS і Windows, яка дозволяє зберігати запити, результати та виконувати набір запитів одним клацанням миші.

Привіт Світ!

Давайте виконаємо метод ping. По-перше, ви повинні визначити IP-адресу, де працює Fledge. Якщо ви встановили Fledge на своїй локальній машині, ви можете використовувати localhost. Крім того, перевірте IP-адресу машини, на якій встановлено Fledge.

Примітка Ця версія Fledge не має жодних налаштувань безпеки за замовчуванням, тому ви можете отримати доступ до точки входу для API REST за допомогою будь-якої зовнішньої програми, але у вашому операційному середовищі можуть бути налаштування безпеки, які забороняють доступ до певних портів із зовнішнього боку. програми. Якщо ви отримуєте помилку під час використання методу ping, а команда fledge status повідомляє, що все запущено, імовірно, ви зіткнулися з проблемою безпеки.

Стандартним портом для REST API є 8081. Використовуючи curl, спробуйте цю команду:

$ curl -s http://localhost:8081/fledge/ping ; echo
{"uptime": 10480, "dataRead": 0, "dataSent": 0, "dataPurged": 0, "authenticationOptional": true, "serviceName": "Fledge", "hostName": "fledge", "ipAddresses": ["x.x.x.x", "x:x:x:x:x:x:x:x"], "health": "green", "safeMode": false}

echo в кінці рядка просто використовується для додавання додаткового нового рядка до виводу.

Якщо ви використовуєте Postman, виберіть метод GET і введіть http://localhost:8081/fledge/ping у полі введення адреси URI. Якщо ви отримуєте доступ до віддаленої машини, замініть localhost правильною IP-адресою. Результат має бути приблизно таким:

Це перше повідомлення, яке ви можете отримати від Fledge!

Привіт із південної півкулі світу Fledge

Давайте спробуємо щось більш захоплююче. Основне завдання Fledge — збирати дані з межі (Edge) (ми називаємо це South), буферизувати їх у нашому механізмі зберігання, а потім надсилати дані до хмарних істориків і корпоративних серверів (ми називаємо їх North). Ми також пропонуємо інформацію для локальних або мережевих програм, які ми називаємо East або West. Щоб вставити дані, вам може знадобитися датчик або пристрій, який генерує дані. Якщо ви хочете спробувати Fledge, але у вас під рукою немає датчика, не хвилюйтеся, у нас є інструмент, який може генерувати дані так, ніби це датчик.

fogbench: короткий вступ

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

Примітка: ці інструкції передбачають, що ви завантажили та встановили плагін CoAP South із .

$ git clone https://github.com/fledge-iot/fledge-south-coap
$ cd fledge-south-coap
$ sudo cp -r python/fledge/plugins/south/coap /usr/local/fledge/python/fledge/plugins/south/
$ sudo cp python/requirements-coap.txt /usr/local/fledge/python/
$ sudo python3 -m pip install -r /usr/local/fledge/python/requirements-coap.txt
$ sudo chown -R root:root /usr/local/fledge/python/fledge/plugins/south/coap
$ curl -sX POST http://localhost:8081/fledge/service -d '{"name": "CoAP", "type": "south", "plugin": "coap", "enabled": true}'

Залежно від середовища ви можете викликати fogbench одним із таких способів:

• У середовищі розробки використовуйте скипт scripts/extras/fogbench у вашому сховищі проекту (не забудьте встановити змінну середовища FLEDGE_ROOT із шляхом до папки сховища проекту).
• У середовищі, розгорнутому за допомогою sudo make install, використовуйте скипт bin/fogbench.

Інструмент fogbench можна викликати так:

$ /usr/local/fledge/bin/fogbench
>>> Make sure south CoAP plugin service is running & listening on specified host and port
usage: fogbench [-h] [-v] [-k {y,yes,n,no}] -t TEMPLATE [-o OUTPUT]
                [-I ITERATIONS] [-O OCCURRENCES] [-H HOST] [-P PORT]
                [-i INTERVAL] [-S {total}]
fogbench: error: the following arguments are required: -t/--template

...або, точніше, коли ви викликаєте fogbench з аргументом --help або -h:

$ /usr/local/fledge/bin/fogbench -h
>>> Make sure south CoAP plugin service is running & listening on specified host and port
usage: fogbench [-h] [-v] [-k {y,yes,n,no}] -t TEMPLATE [-o OUTPUT]
                [-I ITERATIONS] [-O OCCURRENCES] [-H HOST] [-P PORT]
                [-i INTERVAL] [-S {total}]

fogbench -- a Python script used to test Fledge (simulate payloads)

optional arguments:
  -h, --help            show this help message and exit
  -v, --version         show program's version number and exit
  -k {y,yes,n,no}, --keep {y,yes,n,no}
                          Do not delete the running sample (default: no)
  -t TEMPLATE, --template TEMPLATE
                        Set the template file, json extension
  -o OUTPUT, --output OUTPUT
                        Set the statistics output file
  -I ITERATIONS, --iterations ITERATIONS
                        The number of iterations of the test (default: 1)
  -O OCCURRENCES, --occurrences OCCURRENCES
                        The number of occurrences of the template (default: 1)
  -H HOST, --host HOST  CoAP server host address (default: localhost)
  -P PORT, --port PORT  The Fledge port. (default: 5683)
  -i INTERVAL, --interval INTERVAL
                        The interval in seconds for each iteration (default:
                        0)
  -S {total}, --statistics {total}
                        The type of statistics to collect (default: total)

The initial version of fogbench is meant to test the sensor/device interface
of Fledge using CoAP

Щоб використовувати fogbench, вам потрібен файл шаблону. Шаблон — це набір елементів JSON, які використовуються для створення випадкового набору значень, які імітують дані, створені одним або кількома датчиками. Fledge поставляється з файлом шаблону під назвою fogbench_sensor_coap.template.json. Шаблон знаходиться тут:

• У середовищі розробки перегляньте data/extras/fogbench у папці сховища проекту.
• У середовищі, розгорнутому за допомогою sudo make install, перегляньте $FLEDGE_DATA/extras/fogbench.

Файл шаблону виглядає так:

$ cat /usr/local/fledge/data/extras/fogbench/fogbench_sensor_coap.template.json
[
    { "name"          : "asset_1",
      "sensor_values" : [ { "name": "dp_1", "type": "number", "min": -2.0, "max": 2.0 },
                          { "name": "dp_1", "type": "number", "min": -2.0, "max": 2.0 },
                          { "name": "dp_1", "type": "number", "min": -2.0, "max": 2.0 } ] },
    { "name"          : "asset_2",
      "sensor_values" : [ { "name": "lux", "type": "number", "min": 0, "max": 130000, "precision":3 } ] },
    { "name"          : "asset_3",
      "sensor_values" : [ { "name": "pressure", "type": "number", "min": 800.0, "max": 1100.0, "precision":1 } ] }
]

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

Дані, що надходять з Півдня

Тепер у вас має бути вся інформація, необхідна для тестування мікросервісу CoAP South. У командному рядку введіть:

• $FLEDGE_ROOT/scripts/extras/fogbench -t $FLEDGE_ROOT/data/extras/fogbench/fogbench_sensor_coap.template.json, якщо ви перебуваєте в середовищі розробки, зі змінною середовища FLEDGE_ROOT встановлено шлях до папки репозиторію проекту
• $FLEDGE_ROOT/bin/fogbench -t $FLEDGE_DATA/extras/fogbench/fogbench_sensor_coap.template.json, якщо ви перебуваєте в розгорнутому середовищі з FLEDGE_ROOT і FLEDGE_DATA встановленими правильно.
  • Якщо ви встановили Fledge за замовчуванням (тобто /usr/local/fledge), наберіть /usr/local/fledge/bin/fogbench -t data/extras/fogbench/fogbench_sensor_coap.template.json.

У середовищі розробки результатом вашої команди має бути:

$ $FLEDGE_ROOT/scripts/extras/fogbench -t $FLEDGE_ROOT/data/extras/fogbench/fogbench_sensor_coap.template.json
  >>> Make sure south CoAP plugin service is running
   & listening on specified host and port

  Total Statistics:

  Start Time: 2023-04-14 11:15:50.679366
  End Time:   2023-04-14 11:15:50.711856

  Total Messages Transferred: 3
  Total Bytes Transferred:    720

  Total Iterations: 1
  Total Messages per Iteration: 3.0
  Total Bytes per Iteration:    720.0

  Min messages/second: 92.33610341643583
  Max messages/second: 92.33610341643583
  Avg messages/second: 92.33610341643583

  Min Bytes/second: 22160.6648199446
  Max Bytes/second: 22160.6648199446
  Avg Bytes/second: 22160.6648199446

Щиро вітаю! Ви щойно вставили дані у Fledge з мікросервісу CoAP South. Якщо говорити точніше, вихідні дані інформують вас про те, що вставлені дані складаються з 10 різних повідомлень із загальною кількістю 720 байтів, у середньому 92 повідомлення за секунду та 22 160 байтів за секунду.

Якщо ви хочете трохи напружити Fledge, ви можете вставити ту саму вибірку даних кілька разів, використовуючи аргумент -I або --iterations:

$ $FLEDGE_ROOT/scripts/extras/fogbench -t data/extras/fogbench/fogbench_sensor_coap.template.json -I 100
  >>> Make sure south CoAP plugin service is running & listening on specified host and port
  Total Statistics:

  Start Time: 2023-04-14 11:18:03.586924
  End Time:   2023-04-14 11:18:04.582291

  Total Messages Transferred: 300
  Total Bytes Transferred:    72000

  Total Iterations: 100
  Total Messages per Iteration: 3.0
  Total Bytes per Iteration:    720.0

  Min messages/second: 90.53597295992274
  Max messages/second: 454.33893684688775
  Avg messages/second: 323.7178365566367

  Min Bytes/second: 21728.63351038146
  Max Bytes/second: 109041.34484325306
  Avg Bytes/second: 77692.28077359282

Тут ми вставили той самий набір даних 100 разів, тому загальна кількість вставлених байтів становить 72 000. Продуктивність і швидкість вставки змінюються з кожною ітерацією, і fogbench представляє мінімальні, максимальні та середні значення.

Перевірка того, що всередині Fledge

Ми можемо перевірити, чи Fledge зберіг те, що ми вставили з мікросервісу South, за допомогою asset API. Від curl або Postman використовуйте цю URL:

$ curl -s http://localhost:8081/fledge/asset ; echo
  [{"count": 11, "assetCode": "asset_1"}, {"count": 11, "assetCode": "asset_2"}, {"count": 11, "assetCode": "asset_3"}]

Вихід точки входу активу надає список активів, буферизованих у Fledge, і кількість збережених елементів. Результатом є масив JSON з двох елементів:

• count : кількість входжень активу в буфер.
• assetCode : назва датчика або пристрою, який надає дані.

Feeding East/West Applications

Припустімо, що нас цікавлять дані, зібрані для одного з активів, перелічених у попередньому запиті, наприклад fogbench_temperature. Точку входу asset можна використовувати для отримання точок даних для окремих активів, просто додавши код активу до URI:

$ curl -s http://localhost:8081/fledge/asset/asset_2 ; echo
  [{"reading": {"lux": 75723.923}, "timestamp": "2023-04-14 11:25:05.672528"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}, {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}]

Давайте подивимося на вихід JSON у більш читабельному форматі:

[
 {"reading": {"lux": 75723.923}, "timestamp": "2023-04-14 11:25:05.672528"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"},
 {"reading": {"lux": 50475.99}, "timestamp": "2023-04-14 11:24:49.767983"}
]

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

• reading : структура JSON, яка є набором точок даних, наданих датчиком. У цьому випадку лише точка даних під назвою lux:
• lux : значення вимірювача lux
• timestamp : мітка часу, створена датчиками. У цьому випадку, оскільки ми вставили 10 разів те саме значення та один раз нове значення за допомогою fogbench, результатом є 10 позначок часу з тим самим значенням і одна позначка часу з іншим значенням.

Ви можете витягнути ще більше в даних і взяти лише частину показань. Наприклад, туман, ви можете вибрати lux і обмежитися останніми 5 показаннями:

$ curl -s http://localhost:8081/fledge/asset/asset_2/lux?limit=5 ; echo
  [
   {"timestamp": "2023-04-14 11:25:05.672528", "lux": 75723.923},
   {"timestamp": "2023-04-14 11:24:49.767983", "lux": 50475.99},
   {"timestamp": "2023-04-14 11:24:49.767983", "lux": 50475.99},
   {"timestamp": "2023-04-14 11:24:49.767983", "lux": 50475.99},
   {"timestamp": "2023-04-14 11:24:49.767983", "lux": 50475.99}
  ]

Ми покращили вихідні дані JSON для вас, щоб їх було легше читати.

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

Надсилання вітань Північній півкулі

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

Транслятор OMF

Fledge поставляється з плагіном North під назвою OMF Translator. OMF — це формат повідомлень OSIsoft, прийнятний PI Connector Relay OMF. PI Connector Relay OMF надається OSIsoft і використовується для живлення OSIsoft PI System.

• Доступна інформація щодо OSIsoft
• Інформація про OMF доступна
• Доступна інформація щодо OSIsoft PI System

OMF Translator заплановано як завдання Півночі, яке виконується кожні 30 секунд (час може змінюватися, ми встановили його на 30 секунд для полегшення тестування).

Приготування PI System

Щоб протестувати завдання та Північний плагін, спочатку потрібно налаштувати систему PI. Тут ми припускаємо, що ви вже знайомі з PI і у вас є сервер Windows із встановленим і запущеним PI. Мінімальна інсталяція повинна включати систему PI System і PI Connector Relay OMF. Переконавшись, що все встановлено та працює належним чином, слід отримати IP-адресу системи Windows.

Налаштування OMF Translator Plugin

Fledge використовує той самий плагін OMF Translator для надсилання даних, що надходять із модулів Півдня і буферизуються у Fledge.

Примітка У цій версії в систему PI System можна надсилати лише південні дані.

Якщо вам цікаво дізнатися, які категорії доступні у Fledge, просто введіть:

$ curl -s http://localhost:8081/fledge/category ; echo
{
  "categories":
  [
    {
      "key": "SCHEDULER",
       "description": "Scheduler configuration",
       "displayName": "Scheduler"
    },
    {
      "key": "SMNTR",
      "description": "Service Monitor",
      "displayName": "Service Monitor"
    },
    {
      "key": "rest_api",
      "description": "Fledge Admin and User REST API",
      "displayName": "Admin API"
    },
    {
      "key": "service",
      "description": "Fledge Service",
      "displayName": "Fledge Service"
    },
    {
      "key": "Installation",
      "description": "Installation",
      "displayName": "Installation"
    },
    {
      "key": "General",
      "description": "General",
      "displayName": "General"
    },
    {
      "key": "Advanced",
      "description": "Advanced",
      "displayName": "Advanced"
    },
    {
      "key": "Utilities",
      "description": "Utilities",
      "displayName": "Utilities"
    }
  ]
}

Для кожного плагіна ви побачите відповідну категорію, наприклад. Для fledge-south-coap зареєстрованою категорією буде { "key": "COAP", "description": "CoAP Listener South Plugin"}. Конфігурація для перекладача OMF, який використовується для потокової передачі даних Півдня, спочатку вимкнена, все, що ви можете побачити про налаштування, це:

$ curl -sX GET   http://localhost:8081/fledge/category/OMF%20to%20PI%20north
{
  "enable": {
    "description": "A switch that can be used to enable or disable execution of the sending process.",
    "type": "boolean",
    "readonly": "true",
    "default": "true",
    "value": "true"
  },
  "streamId": {
    "description": "Identifies the specific stream to handle and the related information, among them the ID of the last object streamed.",
    "type": "integer",
    "readonly": "true",
    "default": "0",
    "value": "4",
    "order": "16"
  },
  "plugin": {
    "description": "PI Server North C Plugin",
    "type": "string",
    "default": "OMF",
    "readonly": "true",
    "value": "OMF"
  },
  "source": {
     "description": "Defines the source of the data to be sent on the stream, this may be one of either readings, statistics or audit.",
     "type": "enumeration",
     "options": [
       "readings",
       "statistics"
      ],
    "default": "readings",
    "order": "5",
    "displayName": "Data Source",
    "value": "readings"
  },
...}
$ curl -sX GET   http://localhost:8081/fledge/category/Stats%20OMF%20to%20PI%20north
{
  "enable": {
    "description": "A switch that can be used to enable or disable execution of the sending process.",
    "type": "boolean",
    "readonly": "true",
    "default": "true",
    "value": "true"
  },
  "streamId": {
    "description": "Identifies the specific stream to handle and the related information, among them the ID of the last object streamed.",
    "type": "integer",
    "readonly": "true",
    "default": "0",
    "value": "5",
    "order": "16"
  },
  "plugin": {
    "description": "PI Server North C Plugin",
    "type": "string",
    "default": "OMF",
    "readonly": "true",
    "value": "OMF"
  },
  "source": {
    "description": "Defines the source of the data to be sent on the stream, this may be one of either readings, statistics or audit.",
    "type": "enumeration",
    "options": [
      "readings",
      "statistics"
     ],
    "default": "readings",
    "order": "5",
    "displayName": "Data Source",
    "value": "statistics"
  },
...}

На цьому етапі було б гарною ідеєю ознайомитися з інструмент, він дуже допоможе вам у виборі та використанні даних через REST API. Можливо, ви пам’ятаєте, ми обговорювали це в розділі.

По-перше, ми можемо побачити список усіх запланованих завдань (процес надсилання даних до PI Connector Relay OMF є одним із них). Команда:

$ curl -s http://localhost:8081/fledge/schedule | jq
{
  "schedules": [
    {
      "id": "ef8bd42b-da9f-47c4-ade8-751ce9a504be",
      "name": "OMF to PI north",
      "processName": "north_c",
      "type": "INTERVAL",
      "repeat": 30.0,
      "time": 0,
      "day": null,
      "exclusive": true,
      "enabled": false
    },
    {
      "id": "27501b35-e0cd-4340-afc2-a4465fe877d6",
      "name": "Stats OMF to PI north",
      "processName": "north_c",
      "type": "INTERVAL",
      "repeat": 30.0,
      "time": 0,
      "day": null,
      "exclusive": true,
      "enabled": true
    },
  ...
  ]
}

...що означає: «покажи мені всі завдання, які можна запланувати». jq зробив результат більш зрозумілим. Є кілька завдань, нам потрібно визначити те, що нам потрібно, і отримати його унікальний ідентифікатор. Ми можемо досягти цього за допомогою потужності jq: спочатку ми можемо вибрати об’єкт JSON, який показує елементи завдання надсилання:

$ curl -s http://localhost:8081/fledge/schedule | jq '.schedules[] | select( .name == "OMF to PI north")'
{
  "id": "ef8bd42b-da9f-47c4-ade8-751ce9a504be",
  "name": "OMF to PI north",
  "processName": "north_c",
  "type": "INTERVAL",
  "repeat": 30,
  "time": 0,
  "day": null,
  "exclusive": true,
  "enabled": true
}

Давайте подивимося, що ми дізнались:

• id є унікальним ідентифікатором розкладу.
• name – зручна назва розкладу.
• type це тип розкладу, у цьому випадку розклад, який запускається через регулярні проміжки часу.
• repeat вказує інтервал 30 секунд.
• time вказує, коли має виконуватися розклад: оскільки тип INTERVAL, цей елемент не має значення.
• day вказує день тижня, коли розклад має запускатися, у цьому випадку це буде постійно кожні 30 секунд
• exclusive вказує на те, що в будь-який час має виконуватися лише один екземпляр цього завдання.
• processName це ім'я завдання, яке потрібно виконати.
• enabled вказує, увімкнено чи вимкнено розклад.

Тепер давайте визначимо плагін, який використовується для надсилання даних до PI Connector Relay OMF.

$ curl -s http://localhost:8081/fledge/category | jq '.categories[] | select ( .key == "OMF to PI north" )'
{
  "key": "OMF to PI north",
  "description": "Configuration of the Sending Process",
  "displayName": "OMF to PI north"
}

Ми можемо отримати конкретну інформацію, додавши назву завдання до URL-адреси:

$  curl -s http://localhost:8081/fledge/category/OMF%20to%20PI%20north | jq .plugin
{
  "description": "PI Server North C Plugin",
  "type": "string",
  "default": "OMF",
  "readonly": "true",
  "value": "OMF"
}

Тепер отриманий результат не говорить багато: це тому, що плагін ніколи не було ввімкнено, тому конфігурація ще не завантажена. Спочатку ввімкніть розклад. З попереднього запиту запланованих завдань ми знаємо, що ідентифікатор ef8bd42b-da9f-47c4-ade8-751ce9a504be:

$ curl  -X PUT http://localhost:8081/fledge/schedule/ef8bd42b-da9f-47c4-ade8-751ce9a504be -d '{ "enabled" : true }'
{
  "schedule": {
    "id": "ef8bd42b-da9f-47c4-ade8-751ce9a504be",
    "name": "OMF to PI north",
    "processName": "north_c",
    "type": "INTERVAL",
    "repeat": 30,
    "time": 0,
    "day": null,
    "exclusive": true,
    "enabled": true
  }
}

Після ввімкнення плагін буде виконано всередині завдання OMF to PI north протягом 30 секунд, тому вам доведеться зачекати до 30 секунд, щоб побачити нову повну конфігурацію. Приблизно через 30 секунд ви повинні побачити щось на зразок цього:

$ curl -s http://localhost:8081/fledge/category/OMF%20to%20PI%20north | jq
{
  "enable": {
    "description": "A switch that can be used to enable or disable execution of the sending process.",
    "type": "boolean",
    "readonly": "true",
    "default": "true",
    "value": "true"
  },
  "streamId": {
    "description": "Identifies the specific stream to handle and the related information, among them the ID of the last object streamed.",
    "type": "integer",
    "readonly": "true",
    "default": "0",
    "value": "4",
    "order": "16"
  },
  "plugin": {
    "description": "PI Server North C Plugin",
    "type": "string",
    "default": "OMF",
    "readonly": "true",
    "value": "OMF"
  },
  "PIServerEndpoint": {
    "description": "Select the endpoint among PI Web API, Connector Relay, OSIsoft Cloud Services or Edge Data Store",
    "type": "enumeration",
    "options": [
    "PI Web API",
    "Connector Relay",
    "OSIsoft Cloud Services",
    "Edge Data Store"
  ],
    "default": "Connector Relay",
    "order": "1",
    "displayName": "Endpoint",
    "value": "Connector Relay"
  },
  "ServerHostname": {
    "description": "Hostname of the server running the endpoint either PI Web API or Connector Relay",
    "type": "string",
    "default": "localhost",
    "order": "2",
    "displayName": "Server hostname",
    "validity": "PIServerEndpoint != \"Edge Data Store\" && PIServerEndpoint != \"OSIsoft Cloud Services\"",
    "value": "localhost"
  },
  "ServerPort": {
    "description": "Port on which the endpoint either PI Web API or Connector Relay or Edge Data Store is listening, 0 will use the default one",
    "type": "integer",
    "default": "0",
    "order": "3",
    "displayName": "Server port, 0=use the default",
    "validity": "PIServerEndpoint != \"OSIsoft Cloud Services\"",
    "value": "0"
  },
  "producerToken": {
    "description": "The producer token that represents this Fledge stream",
    "type": "string",
    "default": "omf_north_0001",
    "order": "4",
    "displayName": "Producer Token",
    "validity": "PIServerEndpoint == \"Connector Relay\"",
    "value": "omf_north_0001"
  },
  "source": {
    "description": "Defines the source of the data to be sent on the stream, this may be one of either readings, statistics or audit.",
    "type": "enumeration",
    "options": [
      "readings",
      "statistics"
    ],
    "default": "readings",
    "order": "5",
    "displayName": "Data Source",
    "value": "readings"
  },
  "StaticData": {
    "description": "Static data to include in each sensor reading sent to the PI Server.",
    "type": "string",
    "default": "Location: Palo Alto, Company: Dianomic",
    "order": "6",
    "displayName": "Static Data",
    "value": "Location: Palo Alto, Company: Dianomic"
  },
  "OMFRetrySleepTime": {
    "description": "Seconds between each retry for the communication with the OMF PI Connector Relay, NOTE : the time is doubled at each attempt.",
    "type": "integer",
    "default": "1",
    "order": "7",
    "displayName": "Sleep Time Retry",
    "value": "1"
  },
    "OMFMaxRetry": {
        "description": "Max number of retries for the communication with the OMF PI Connector Relay",
        "type": "integer",
        "default": "3",
        "order": "8",
        "displayName": "Maximum Retry",
        "value": "3"
    },
  "OMFHttpTimeout": {
    "description": "Timeout in seconds for the HTTP operations with the OMF PI Connector Relay",
    "type": "integer",
    "default": "10",
    "order": "9",
    "displayName": "HTTP Timeout",
    "value": "10"
  },
  "formatInteger": {
    "description": "OMF format property to apply to the type Integer",
    "type": "string",
    "default": "int64",
    "order": "10",
    "displayName": "Integer Format",
    "value": "int64"
  },
  "formatNumber": {
    "description": "OMF format property to apply to the type Number",
    "type": "string",
    "default": "float64",
    "order": "11",
    "displayName": "Number Format",
    "value": "float64"
  },
  "compression": {
    "description": "Compress readings data before sending to PI server",
    "type": "boolean",
    "default": "true",
    "order": "12",
    "displayName": "Compression",
    "value": "false"
  },
  "DefaultAFLocation": {
    "description": "Defines the hierarchies tree in Asset Framework in which the assets will be created, each level is separated by /, PI Web API only.",
    "type": "string",
    "default": "/fledge/data_piwebapi/default",
    "order": "13",
    "displayName": "Asset Framework hierarchies tree",
    "validity": "PIServerEndpoint == \"PI Web API\"",
    "value": "/fledge/data_piwebapi/default"
  },
  "AFMap": {
    "description": "Defines a set of rules to address where assets should be placed in the AF hierarchy.",
    "type": "JSON",
    "default": "{ }",
    "order": "14",
    "displayName": "Asset Framework hierarchies rules",
    "validity": "PIServerEndpoint == \"PI Web API\"",
    "value": "{ }"
  },
  "notBlockingErrors": {
    "description": "These errors are considered not blocking in the communication with the PI Server, the sending operation will proceed with the next block of data if one of these is encountered",
    "type": "JSON",
    "default": "{ \"errors400\" : [ \"Redefinition of the type with the same ID is not allowed\", \"Invalid value type for the property\", \"Property does not exist in the type definition\", \"Container is not defined\", \"Unable to find the property of the container of type\" ] }",
    "order": "15",
    "readonly": "true",
    "value": "{ \"errors400\" : [ \"Redefinition of the type with the same ID is not allowed\", \"Invalid value type for the property\", \"Property does not exist in the type definition\", \"Container is not defined\", \"Unable to find the property of the container of type\" ] }"
  },
  "PIWebAPIAuthenticationMethod": {
    "description": "Defines the authentication method to be used with the PI Web API.",
    "type": "enumeration",
    "options": [
      "anonymous",
      "basic",
      "kerberos"
    ],
    "default": "anonymous",
    "order": "17",
    "displayName": "PI Web API Authentication Method",
    "validity": "PIServerEndpoint == \"PI Web API\"",
    "value": "anonymous"
  },
  "PIWebAPIUserId": {
    "description": "User id of PI Web API to be used with the basic access authentication.",
    "type": "string",
    "default": "user_id",
    "order": "18",
    "displayName": "PI Web API User Id",
    "validity": "PIServerEndpoint == \"PI Web API\" && PIWebAPIAuthenticationMethod == \"basic\"",
    "value": "user_id"
  },
  "PIWebAPIPassword": {
    "description": "Password of the user of PI Web API to be used with the basic access authentication.",
    "type": "password",
    "default": "password",
    "order": "19",
    "displayName": "PI Web API Password",
    "validity": "PIServerEndpoint == \"PI Web API\" && PIWebAPIAuthenticationMethod == \"basic\"",
    "value": "****"
  },
  "PIWebAPIKerberosKeytabFileName": {
    "description": "Keytab file name used for Kerberos authentication in PI Web API.",
    "type": "string",
    "default": "piwebapi_kerberos_https.keytab",
    "order": "20",
    "displayName": "PI Web API Kerberos keytab file",
    "validity": "PIServerEndpoint == \"PI Web API\" && PIWebAPIAuthenticationMethod == \"kerberos\"",
    "value": "piwebapi_kerberos_https.keytab"
  },
  "OCSNamespace": {
    "description": "Specifies the OCS namespace where the information are stored and it is used for the interaction with the OCS API",
    "type": "string",
    "default": "name_space",
    "order": "21",
    "displayName": "OCS Namespace",
    "validity": "PIServerEndpoint == \"OSIsoft Cloud Services\"",
    "value": "name_space"
  },
  "OCSTenantId": {
    "description": "Tenant id associated to the specific OCS account",
    "type": "string",
    "default": "ocs_tenant_id",
    "order": "22",
    "displayName": "OCS Tenant ID",
    "validity": "PIServerEndpoint == \"OSIsoft Cloud Services\"",
    "value": "ocs_tenant_id"
  },
  "OCSClientId": {
    "description": "Client id associated to the specific OCS account, it is used to authenticate the source for using the OCS API",
    "type": "string",
    "default": "ocs_client_id",
    "order": "23",
    "displayName": "OCS Client ID",
    "validity": "PIServerEndpoint == \"OSIsoft Cloud Services\"",
    "value": "ocs_client_id"
  },
  "OCSClientSecret": {
    "description": "Client secret associated to the specific OCS account, it is used to authenticate the source for using the OCS API",
    "type": "password",
    "default": "ocs_client_secret",
    "order": "24",
    "displayName": "OCS Client Secret",
    "validity": "PIServerEndpoint == \"OSIsoft Cloud Services\"",
    "value": "****"
  }
}

Ви можете переглянути описи, щоб зрозуміти, чим можна керувати за допомогою цього плагіна. Конфігурація за замовчуванням має бути нормальною, за винятком ServerHostname, яка, звичайно, має вказувати на IP-адресу машини та порт, який використовує PI Connector Relay OMF. PI Connector Relay OMF 1.0 використовував протокол HTTP з портом 8118 і версією 1.2 або вищою, використовує HTTPS і порт 5460. Якщо припустити, що порт 5460, а IP-адреса 192.168.56.101, ви можете встановити нове ім'я хосту сервера з цим методом PUT:

$ curl -sH'Content-Type: application/json' -X PUT -d '{ "ServerHostname": "192.168.56.101" }' http://localhost:8081/fledge/category/OMF%20to%20PI%20north | jq
"ServerHostname": {
  "description": "Hostname of the server running the endpoint either PI Web API or Connector Relay",
  "type": "string",
  "default": "localhost",
  "order": "2",
  "displayName": "Server hostname",
  "validity": "PIServerEndpoint != \"Edge Data Store\" && PIServerEndpoint != \"OSIsoft Cloud Services\"",
  "value": "192.168.56.101"
}

Ви можете зауважити, що елемент value є єдиним, який можна змінити в URL (інші елементи є заводськими налаштуваннями).

Тепер ми готові надсилати дані на північ, до системи PI.

Посилання даних до PI System

Останнім кроком є запуск PI Connector Relay OMF на Windows Server. Результат може виглядати як цей знімок екрана, де ви можете побачити вікно налагодження Connector Relay ліворуч і PI Data Explorer праворуч.

Зачекайте кілька секунд ... і вуаля! Показання та статистика знаходяться в системі PI:

Щиро вітаю! Ви пройшли наскрізне випробування Fledge, починаючи з півдня з даними датчиків через програми Fledge і East/West і, нарешті, на північ до Historians.