Функції Fledge Control

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

Функції контролю

Підтримуються два типи функцій керування

• Змінювати значення в пристрої за допомогою південного сервіса та плагіна.
• Попросити пристрій виконати дію.

Точка Встановлення

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

Операція

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

Шляхи Контролю

За допомогою Fledge керування заданим значенням може бути викликано кількома шляхами

• Як результат сповіщення в самому Fledge.
• У результаті запиту через публічний REST API Fledge.
• У результаті контрольного повідомлення, що надходить із північної системи в північний плагін і направляється далі до південного сервіса.

Використання сповіщення в самому екземплярі Fledge забезпечує найшвидшу відповідь на крайове сповіщення. Усю обробку для цього виконує сам Fledge.

Як і у випадку з функціями входу та виходу даних у Fledge, також можна побудувати трубопроводи фільтрів у шляхах керування, щоб змінити поведінку та обробити дані на шляху керування. Трубопроводи в шляху керування, як визначено між різними кінцевими точками операцій керування, і визначені таким чином, що той самий трубопровод може використовуватися кількома шляхами керування. Дивитись ControlPipelines

Контроль на основі межі

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

Як приклад того, як може працювати контроль на основі краю, розглянемо наступний випадок.

У нас є верстат, який контролюється Fledge за допомогою плагіна OPC/UA south для зчитування даних із верстатів, що керують ПЛК. Як частину цих даних ми отримуємо актив, який містить температуру двигуна, який запускає інструмент. Ми можемо припустити, що цей актив називається MotorTemperature і містить одну точку даних під назвою temperature.

У нас також є блок вентиляторів, який може охолоджувати цей двигун, який керується через інтерфейс Modbus. Modbus містить одну котушку, яка вмикає та вимикає вентилятор, і регістр, який контролює швидкість вентилятора. Ми налаштовуємо fledge-south-modbus як сервіс під назвою MotorFan із картою керування, яка відображатиме котушку та реєструватиме її в парі заданих точок.

{
    "values" : [
                   {
                       "name" : "run",
                       "coil" : 1
                   },
                   {
                       "name"     : "speed",
                       "register" : 1
                   }
               ]
}

Якщо виміряна температура двигуна перевищує 35 градусів Цельсія, ми хочемо ввімкнути вентилятор на 1200 об/хв. Для цього ми створюємо нове сповіщення. Сповіщення використовує правило порогове значення та активується, якщо актив MotorTemperature, точка даних temperature перевищує 35.

Вибираємо зі списку плагін доставки setpoint і налаштовуємо його.

setpoint_3

• У Service ми встановлюємо назву сервіса, яку будемо використовувати для керування вентилятором, у даному випадку MotorFan
• У Trigger Value ми встановлюємо контрольне повідомлення, яке ми будемо надсилати до сервісу. Це увімкне вентилятор і встановить швидкість 1200 об/хв
• У Cleared Value ми встановлюємо контрольне повідомлення, яке ми будемо надсилати, щоб вимкнути вентилятор, коли значення падає нижче 35 градусів.

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

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

Підміна даних

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

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

Параметри замінюються за допомогою простого механізму макросу, ім’я активу та точка даних у активі вставляється у значення, оточене символом $. Наприклад, щоб замінити значення точки даних temperature активу MotorTemperature у параметр speed set point, ми повинні визначити наступне в Trigger Value

{
    "values" : {
         "speed"  : "$MotorTemperature.temperature$"
}

Зауважте, що ми відокремлюємо назву активу від назви точки даних за допомогою символу крапки.

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

Простим варіантом є використання макромеханізму, щоб додати пару нулів до температури, температура 21 градус призведе до швидкості вентилятора 2100 об/хв.

{
    "values" : {
         "speed"  : "$MotorTemperature.temperature$00"
}

Це працює, але є трохи примітивним і обмеженим. Інший варіант – додати дані до активу, який ініціює сповіщення. У цьому випадку ми могли б додати фільтр виразів, щоб створити нову точку даних із бажаною швидкістю вентилятора. Якби ми додали фільтр виразів і дали йому вираз desiredSpeed = temperature > 20 ? temperature 50 + 1200 : 0*, тоді ми створимо нову точку даних в активі під назвою desiredSpeed. Значення desiredSpeed дорівнюватиме 0, якщо температура буде 20 градусів або нижче, однак для температур вище воно буде 1200 плюс 50 температур.

Цю нову бажану швидкість можна використовувати для встановлення температури в плагіні сповіщень setpoint.

{
    "values" : {
         "speed"  : "$MotorTemperature.desiredSpeed$"
         }
}

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

Налаштування систем керування межею

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

Щоб зрозуміти затримку, притаманну шляху керування, ми повинні спочатку почати дослідження цього шляху, щоб виявити, де може виникнути затримка. Для цього буде вибрано простий випадок одного південного плагіна, який збирає дані, необхідні для контрольного рішення в Fledge. Контрольне рішення буде прийнято в правилі сповіщень і доставлено через плагін fledge-notify-setpoint іншому південному сервісу.

Загалом чотири сервіса Fledge будуть задіяні в шляху керування

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

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

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

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

Вище показано стандартну конфігурацію південного сервіса. У цьому випадку дані не будуть надіслані до південного сервіса, доки не буде 100 показань, збережених у буфері південного сервіса, або найстаріший показник у буфері південного сервіса перебував у буфері протягом 5000 мілісекунд. У цьому прикладі ми зчитуємо 1 нове зчитування щосекунди, тому будемо надсилати дані до сервіса зберігання кожні 5 секунд, коли найстаріше зчитування в буфері було там протягом 5000 мс. Коли він надсилає дані, він надсилає всі дані, які він буферизував, у цьому випадку 5 показань як один блок. Якщо найстаріше зчитування є тим, яке ініціює сповіщення, ми ввели 5-секундну затримку в шлях керування.

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

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

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

Тип сповіщення використовується для визначення того, коли сповіщення доставляються до каналу доставки, у випадку керування межами це може бути плагін setpoint або плагін operation. Fledge реалізує три варіанти типу сповіщення

• One shot: одноразове сповіщення надсилається один раз, коли сповіщення запускається, але не надсилається повторно, якщо сповіщення запускається під час послідовних оцінок. Якщо оцінка не запускається, сповіщення очищається та надсилається знову під час наступного запуску правила сповіщення. Сповіщення про один знімок можуть бути додатково налаштовані з максимальною частотою повторення, напр. не більше одного разу протягом 15 хвилин.
• Toggle: сповіщення про перемикання надсилається, коли спрацьовує правило сповіщення, і не надсилатиметься повторно, доки правило не спрацює, точно так само, як і одноразовий тригер. Однак у цьому випадку, коли правило сповіщення вперше припиняє активацію, надсилається очищене сповіщення. Це знову ж таки можна змінити шляхом додавання максимальної частоти повторення.
• Retriggered: повторно запущене сповіщення надсилатиметься, коли спрацює правило сповіщення. Швидкість, з якою надсилається сповіщення, можна контролювати максимальною частотою повторення, напр. надсилати сповіщення кожні 5 хвилин, доки умова не спрацює.

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

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

Однак дуже важливо розуміти, що час повторного запуску визначає, коли сповіщення можуть бути доставлені, це не пов’язано з інтервалом між читаннями. Як приклад, припустімо, що ми маємо час повторного запуску 1 секунду, а показання надходять кожні 2 секунди, що викликає надсилання сповіщення.

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

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

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

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

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

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

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

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

Наскрізний контроль

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

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

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

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

Приклад того, як північний плагін може визначити це відображення, показано нижче

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

Крім того, диспетчер може надіслати запит на основі активів, які отримує південний сервіс. У наступному прикладі, знову взятому з північного плагіна OPCUA, ми надсилаємо значення EngineSpeed, яке є цілим числом на сервері OPCUA, яке Fledge надає сервісу, яка приймає актив pump0014.

Під час перегляду сервера OPCUA, який Fledge пропонує через північний сервіс, ви побачите вузол із назвою для перегляду EngineSpeed, після написання якої плагін північний надсилатиме повідомлення диспетчерському сервісу та зрештою спонукатиме південний сервіс приймати pump0014 щоб це значення було записано в елемент EngineSpeed. Цей південний Сервіс не обов’язково повинен бути сервісом OPCUA, це може бути будь-який південний сервіс, який підтримує контроль.

Також можна змусити диспетчера відправити запит на контроль усім сервісам, які підтримують контроль. У випадку північного плагіна OPCUA це вказано шляхом пропуску інших типів призначення.

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

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

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

Виклик керування API

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

/fledge/control/request/{name}

Де {name} – це символічне ім’я, яке визначається користувачем, який налаштовує запит API.

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

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

Визначення контрольних точок входу API

Контрольна точка входу має такі атрибути

• Тип керування, запис або операція
• Місце призначення для контролю. Це кінцевий пункт призначення, усі запити на керування направлятимуться через диспетчер керування. Призначенням може бути сервіс, актив, скрипт або трансляція.
• Ім'я операції, якщо типом є операція.
• Набір постійних пар ключ/значення, які надсилаються або як елементи для запису, або як параметри, якщо типом точки входу є операція. Константи завжди передаються до виклику диспетчера з визначеними тут значеннями.
• Набір пар ключ/значення, які визначають змінні, які можна передати в контрольну точку входу в запиті. Наведене тут значення представляє значення за замовчуванням, яке використовується, якщо відповідний ключ не вказано в запиті, зробленому через публічний API.
• Набір імен користувачів для користувачів, яким дозволено робити запити до цієї точки входу. Якщо це поле порожнє, користувачі не можуть викликати точку входу API, якщо не ввімкнено анонімний доступ. Дивись нижче.
• Позначка з анонімним ключем, яка вказує, чи відкрита точка входу для всіх користувачів, у тому числі користувачів, які не автентифіковані за допомогою API. Він може приймати значення «true» або «false».
• Анонімний прапор дійсно призначений для ситуацій, коли жоден користувач не ввійшов у систему, тобто автентифікація не є обов’язковою. Це також виконує подвійну мету, дозволяючи виклику API керування бути відкритим для всіх користувачів. Не рекомендується встановлювати для цього прапорця значення «true» у робочих середовищах.

Щоб визначити нову точку входу керування, до URL-адреси надсилається запит POST

/fledge/control/manage

With a payload such as

{
      "name"           : "FocusCamera1",
      "description"    : "Perform a focus operation on camera 1",
      "type"           : "operation",
      "operation_name" : "focus",
      "destination"    : "service",
      "service"        : "camera1",
      "constants"      : {
                              "units"    : "cm"
                         },
      "variables"      : {
                              "distance" : "100"
                         },
      "allow"          : [ "john", "fred" ],
      "anonymous"      : false
}

Наведене вище визначить точку входу API, яку можна викликати за допомогою запиту PUT до URL-адреси

/fledge/control/request/FocusCamera1

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

Корисне навантаження, надіслане диспетчеру, завжди міститиме всі змінні та константи, визначені в точці входу API. Значення для констант завжди беруться з початкового визначення, тоді як значення змінних можна надати у загальнодоступному API або, якщо вони опущені, використовуватимуться значення за замовчуванням, визначені під час визначення точки входу.

Графічний інтерфейс користувача

Доступ до функцій GUI здійснюється через підменю API Entry Points меню Control на лівій панелі меню. Якщо вибрати цей параметр, відобразиться наступний екран.

Додавання точки входу Control API

Натиснувши на пункт Add + у верхньому правому куті, ви зможете визначити нову точку входу.

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

Потім ми вводимо пункт призначення, у цьому випадку сервіс, вибравши його зі спадного списку. Ми також можемо ввести назву сервіса.

Ми можемо додати постійні та змінні параметри до точки входу через панель Parameters на сторінці додавання запису

Натискання елементів + Add new variable або +Add new constant додасть пару полів для введення, щоб ви могли ввести назву та значення для змінної або константи.

Ви можете видалити змінну або константу, натиснувши піктограму x поруч із записом.

Панель Execution Access дозволяє контролювати, хто може виконувати кінцеву точку. Якщо вибрати кнопку перемикання Anonymous, будь-який користувач зможе запустити API. Це не рекомендується у виробничому середовищі.

Розкривний список Allow Users надасть можливість дозволити обмеженим користувачам запускати точку входу та надасть список визначених користувачів у системі на вибір.

Нарешті, у полі Description можна надати текстовий опис операції.

Натиснувши Save, ви збережете нову точку входу в API. Нова точка входу буде відображена на результуючому екрані разом з іншими, які були визначені раніше.

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

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

Сервіс Контролю Диспетчера

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

Запити на пересилання

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

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

Скрипти автоматизації

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

• Виконайте запит на запис. Нова операція запису визначається на кроці, і вона може мати форму будь-якого з трьох стилів пересилання, підтримуваних диспетчером; напишіть до названого сервіса, напишіть до сервіса як надання активу або напишіть до всіх південних сервісів.
• Виконайте запит на операцію для однієї або всіх південних сервісів. Як і в запиті на запис вище, визначено три напрямки визначення цільового південного сервіса.
• Затримка виконання скрипту. Додайте затримку між виконанням кроків скрипту.
• Оновіть конфігурацію Fledge. Змінити значення елемента конфігурації в системі.
• Виконати інший скрипт. Механізм для виклику іншого іменованого скрипту, іменований скрипт виконується, а потім продовжить виконання скрипту виклику.

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

З кожним кроком також може бути пов’язана умова, якщо вказано, що умова має бути істинною, щоб крок було виконано. Якщо він оцінюється як false, тоді крок не виконується, і виконання переходить до наступного кроку скрипту.

Умови кроку

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

speed != 0

до кроку призведе до виконання кроку, якщо значення в параметрі під назвою speed, яке було в оригінальному запиті до диспетчера, мало 7значення, відмінне від 0.

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

Конфігурація

Сервіс контролю диспетчера має невелику кількість елементів конфігурації, які доступні в категорії конфігурації Dispatcher у загальному пункті меню «Configuration» в інтерфейсі користувача.

Існують дві підкатегорії: Server і Advanced.

Конфігурація Сервера

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

Продвинута Конфігурація

• Minimum Log Level: Дозволяє визначити мінімальний рівень, на якому логи записуватимуться в системний журнал.
• Maximum number of dispatcher threads: Потоки диспетчера використовуються для виконання скриптів автоматизації. Кожен скрипт використовує один потік протягом усього часу виконання скрипту. Тому цей параметр визначає, скільки скриптів можна виконувати паралельно.

Контрольні трубопроводи

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

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

Правила картографування

Для запису заданого значення ім’я активу завжди буде встановлено на reading, створений актив матиме набір точок даних, по одній для кожної операції запису заданого значення, яка має бути виконана. Ім’я точки даних – це ім’я контрольної точки, яку потрібно записати, а значення точки даних – це значення, яке потрібно встановити.

Наприклад, якщо для запису заданого значення потрібно встановити значення Pump Speed на 80, а параметр Pump Running на значення True, тоді зчитування, яке буде створено та передано до фільтра, матиме asset_code reading та дві точки даних, одна називається Pump Speed зі значенням 80, а інша називається Pump Running зі значенням True.

Цим показанням можна маніпулювати за допомогою фільтра так само, як і в будь-якому іншому трубопроводі. Наприклад фільтр можна використовувати для масштабування швидкості насоса. Якщо потрібно було помножити швидкість насоса на 10, тоді визначений вираз буде Pump Speed 10* .

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

Наприклад, якщо для операції Start Fan потрібен параметр Fan Speed, тоді зчитування з asset_code Start Fan з однією точкою даних під назвою Fan Speed буде створено та передано через трубопровід фільтра.

Типи Даних

Значення всіх заданих точок і параметрів усіх операцій передаються в керуючих сервісах і між сервісами як представлення рядків, однак вони перетворюються на відповідні типи, коли проходять через трубопровод фільтра. Якщо значення можна представити як ціле число, воно буде таким і для значень з плаваючою комою.

Примітка

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

З'єднання трубопроводів

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

Тип	Квнцеві точки	Опис
Будь-який	Обидва	Трубопровід може з'єднуватися з будь-яким джерелом або пунктом призначення. Це використовується тільки в ситуаціях, коли точний збіг для кінцевої точки не може бути задоволений.
API	Джерело	Джерелом запиту є виклик API до публічного API екземпляра Fledge.
Актив	Призначення	Дані будуть надіслані до сервісу, який відповідає за приймання названого активу.
Broadcast	Призначення	Запити будуть надіслані всім південним службам, які підтримують контроль.
Повідомлення	Джерело	Запит виник від названого повідомлення.
Розклад	Джерело	Запит виник з розкладу.
Скріпт	Джерело	Запит походить від скрипта або надсилається до скрипта.
Сервіс	Обидва	Запит або надходить від названого сервісу, або надсилається до названого сервісу.

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

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

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

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

Моделі виконання трубопроводів

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

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

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

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

Управління трубопроводом контролю

Графічний інтерфейс користувача Fledge надає механізм для керування трубопроводом контролю, його можна знайти у підменю «Control» під пунктом «pipelines».

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

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

Користувач має ряд дій, які можна виконати на цьому екрані.

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

Наразі єдиною операцією, яка підтримується, є видалення.

• Натисніть опцію «Додати» у верхньому правому куті, щоб визначити новий трубопровід.

Додавання Трубопроводу Контролю

Якщо натиснути опцію додавання, відобразиться екран додавання нового трубопроводу контролю.

• Name: Назва трубопроводу. Це має бути унікальне ім’я, яке використовується для ідентифікації трубопроводу.
• Execution: Модель виконання для запуску цього трубопровода. У більшості випадків моделі Shared виконання достатньо.
• Source: Джерело керування з яким слід співвідносити цей трубопровід.
• Filters: Фільтри в трубопроводі. Натисніть Add new filter, щоб додати новий фільтр до трубопроводу. Якщо натиснути на посилання Add filter, відобразиться діалогове вікно, у якому можна вибрати та назвати плагін фільтра. Якщо натиснути «Далі» у цьому діалоговому вікні, відобразиться конфігурація вибраного фільтра, у цьому випадку ми вибрали

Тоді фільтр слід налаштувати так само, як і для трубопроводу даних.

Після натискання кнопки Done діалогове вікно зникне та відобразиться вихідний екран із новим трубопроводом. У списку фільтрів. Більше фільтрів можна додати, натиснувши на посилання Add new filter. Якщо в трубопроводі є кілька фільтрів, можна змінити їх порядок, перетягнувши по списку.

• Destination: Призначення контролю, з яким цей трубопровід співвідноситься.
• Enabled: Дозволити виконання трубопроводу

Нарешті натисніть кнопку Save, щоб зберегти новий трубопровід контролю.