OpenSCADAWiki: Home Page Uk/Doc/DAQ ...

Home | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
 
English (1 Кб) English
Russian (1 Кб) Российский

 (2 Кб) Сторінку заморожено, актуальна тут.


1793

Збір даних у OpenSCADA

Автор: Роман Савоченко


Оглавление

Вступ

Збір даних SCADA(Supervisory Control and Data Acquisition)-системи є її невід'ємною частиною, яка займається отриманням даних із джерел різноманітного походження. Природа даних, з якими працює SCADA, характеризується сигналами базових типів значень (цілі, реальні, логічні та рядок). Сигнали змінюються у часі та мають історією, життя. У теорії управління технологічними процесами (ТП) під сигналом мається на увазі значення давача установки ТП у коді АЦП, "сирий" сигнал або у реальному значені. Сигнали можуть поєднуватися у групи за смисловим навантаженням, які часто називаються параметрами. Наприклад, розвинуті джерела даних можуть надавати структури параметрів із визначеним набором пов'язаних сигналів. Крім безпосередньо збору даних до функції цього механізму також входить і передача дій на виконавчі пристрої управління ТП; зазвичай це засувки, насоси та регулюючі клапани. Сукупно це обладнання отримало назву Пристрій Сполучення із Об'єктом (ПСО).


Джерела даних характеризуються великим розмаїттям, яке можна умовно поділити на три групи:


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


У термінах системи OpenSCADA надаються наступні об'єкти для обслуговування механізму збору даних:


Для врахування особливостей різних пристроїв збору даних, а також різних механізмів взаємодії у OpenSCADA передбачено підсистему "Збір Даних", яка є модульною. У якості модуля підсистеми виступає драйвер для сполучення із джерелом даних окремого типу. Кожний модуль може містити конфігурацію декількох пристроїв цього типу у вигляді об'єктів "Контролер" системи OpenSCADA. Загальну схему об'єктів підсистеми "Збір даних" зображено на рисунку 1.


Схема підсистеми "Збір Даних". (44 Кб)
Рис. 1. Схема підсистеми "Збір Даних".

1. Методи збору даних

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


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

1.1. Простий синхронний механізм збору

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


Диаграмма последовательности взаимодействия при синхронных запросах. (10 Кб)
Рис. 2. Діаграма послідовності взаємодії при синхронних запитах.

У відповідності із діаграмою вище ми отримуємо наступну послідовність запитів отримання даних та їх передачі:


У OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних".

1.2. Простий асинхронний механізм збору

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


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


У якості прикладу розглянемо промисловий ПЛК Siemens S7-315 при опитувані його по шині ProfiBus (1,5 Мбіт/с). Середній час обробки MPI-запиту цим контролером становить 30 мс. Якщо використовувати синхронний механізм для кожного сигналу, тобто один запит на кожний сигнал, то протягом однієї секунди ми зможемо отримати біля 33 сигналів. А якщо застосувати асинхронний механізм, тобто у одному MPI-пакеті отримувати до 220 байт або 110 сигналів цілочисельного типу на 16-розрядів, то ми зможемо за одну секунду отримати до 3630 сигналів. Як можна бачити, ефективність асинхронного механізму у цьому випадку складає 110 разів, а саме значення максимальної ємності MPI-пакету.


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


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


Диаграмма последовательности взаимодействия при асинхронных запросах. (15 Кб)
Рис. 3. Діаграма послідовності взаємодії при асинхронних запитах.

У відповідності з діаграмою вище ми отримуємо наступну картину:


В OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних".

1.3. Пакетний механізм збору

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


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


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


Диаграмма последовательности взаимодействия при асинхронных запросах в пакетного механизма. (16 Кб)
Рис. 4. Діаграма послідовності взаємодії при асинхронних запитах пакетного механізму.

У відповідності з діаграмою вище ми отримаємо наступну поведінку пакетного механізму при асинхронних запитах:


В OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних".

1.4. Пасивний механізм збору

Пасивний механізм збору даних характерний ініціативою надання даних в SCADA-систему із боку джерела даних. Цей механізм є достатньо рідкісним явищем, однак може мати місце у випадку певних умов або обмежень у можливості використання прямих механізмів збору даних, рис. 5. Прикладом такої ситуації можуть слугувати географічно розосереджені системи збору даних за посередництвом мобільних мереж GPRS/EDGE. У таких мережах наділення клієнтських вузлів окремими/реальними IP-адресами або формування корпоративної мобільної мережі може виявитися коштовним задоволенням, тому доступніше виявляється ініціатива сеансу передачі даних з клієнтських динамічних IP-адрес на одну реальну IP-адресу серверу SCADA-системи. Хоча можлива робота і через мережеву СУБД-посередника. Дії на модифікацію передаються джерелу даних в момент сеансу передачі даних джерелом.


Проміжним варіантом є ініціатива встановлення TCP-підключення від джерела даних та типові запити надалі від сервера по цьому підключенню, що вхідний транспорт OpenSCADA Transport.Sockets наразі підтримує.


Диаграмма последовательности взаимодействия при пассивном механизме работы. (12 Кб)
Рис. 5. Діаграма послідовності взаємодії у пасивному механізмі роботи.

У відповідності з діаграмою вище ми отримуємо наступну поведінку пасивного механізму:


У OpenSCADA такий механізм ще не використано, однак принципова можливість його реалізації у системі є, наприклад, через запис за посередництвом стандартних протоколів "ModBus", "OPC-UA".

2. Віртуальні джерела даних

Крім збору фізичних даних актуальною є функція віртуального збору даних. Віртуальні дані представляють собою дані, отримані всередині системи як незалежно, так і на основі фізичних даних. Практично механізми формування віртуальних даних реалізуються разом з механізмом користувацьких обчислень. В середині промислових контролерів та SCADA-систем використовуються різні мови програмування. У випадку з контролерами у якості таких мов часто використовуються мови низького рівня (асемблери), однак останнім часом все частіш використовуються мови високого рівня (C, Pascal та інші), а також формальні мови IEC 61131-3 (схеми потоків станів SFC, блокові схеми FBD, релейні схеми LD та текстові ST, IL). У випадку із SCADA-системами обчислювання частіше забезпечуються мовами програмування високого рівня та формальними мовами.


У системі OpenSCADA можуть бути реалізовані інтерфейси програмування та віртуальних джерел даних на основі різних мов у окремих модулях підсистеми "Збір Даних". На поточний час доступні модулі віртуальних обчислювачів:


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


Модуль JavaLikeCalc надає до системи OpenSCADA механізм створення динамічних користувацьких функцій та їх бібліотек на Java-подібній мові. Опис функції на Java-подібній мові зводиться до обв'язки параметрів функції алгоритмом. Крім цього модуль наділено функціями безпосередніх обчислень шляхом створення обчислювальних контролерів із асоційованою обчислювальною функцією. Модулем надається механізм прекомпіляції контекстно-залежних функцій, що використовується для вбудовування користувацьких алгоритмів безпосередньо до контексту різних компонентів OpenSCADA. Наприклад, це механізм шаблонів параметрів підсистеми "Збір Даних" та рушій середовища візуалізації та управління (СВУ).


Модуль BlockCalc надає до системи OpenSCADA механізм створення користувацьких обчислень. Механізм обчислень ґрунтується на формальній мові блокових схем. Мови блокового програмування ґрунтуються на понятті блокових схем (функціональних блоків). Причому в залежності від сутності блоку блокові схеми можуть бути: логічними схемами, схемами релейної логіки, моделлю технологічного процесу та інше. Сутність блокової схеми полягає в тому, що вона містить перелік блоків та зв'язки між ними. З формальної точки зору блок — це елемент (функція), яка має входи, виходи та алгоритм обчислення. Виходячи із концепції середовища програмування, блок — це кадр значень, асоційований з об'єктом функції. Входи та виходи блоків треба поєднувати для отримання цільної блокової схеми.


З метою наповнення API користувацького програмування користувацькими функціями створені наступні спеціалізовані модулі статичних функцій API користувацького програмування:


Загальна структура компонентів середовища програмування. (82 Кб)
Рис. 6. Загальна структура компонентів середовища програмування.

3. Логічний рівень обробки даних

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


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


Функціонально "Логічний рівень" призначено для надання у системі OpenSCADA механізму вільного формування об'єктів параметрів, контейнерів сигналів, потрібної структури.


Експлуатаційним призначенням "Логічного рівня" є:


Концепція "Логічного рівня" заснована на шаблонах параметрів, для яких у підсистемі "Збір Даних" передбачено контейнер бібліотек шаблонів (рис. 1). Кожна бібліотека містить шаблони параметрів, які можуть використовуватися модулями підсистеми "Збір Даних" для реалізації параметрів на основі шаблонів. Модулями системи OpenSCADA, які використовують шаблони у своїй роботі, є:


Загальний механізм роботи "Логічного рівня" на прикладі модуля LogicLev EN RU зображено на рисунку 7.


Механізм роботи "Логічного рівня" на прикладі модуля LogicLev. (32 Кб)
Рис. 7. Механізм роботи "Логічного рівня" на прикладі модуля LogicLev EN RU.

Виходячи із зображення видно, що параметри контролеру логічного рівня виконують функцію відображення інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 1 та 4) та довільне формування параметрів на основі шаблонів 1, 2 та інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 2, 3 та 5).


Структура параметрів з шаблоном в основі має структуру, зображену на рисунку 8.


Структура параметрів, з шаблоном в основі. (15 Кб)
Рис. 8. Структура параметрів, з шаблоном в основі.

Як можна бачити із структури, параметр логічного рівня складається із об'єкту функції, атрибутів та конфігурації шаблону. Об'єкт функції це екземпляр виконання функції шаблону з набором входів/виходів та програмою обчислення шаблону на одній із мов користувацького програмування, зазвичай це Java-подібна мова користувацького програмування модуля JavaLikeCalc. Утім шаблон може бути взагалі без програми, надаючи тільки структуру прокидання входів/виходів. Атрибути у структурі зображують перелік атрибутів результуючого параметру у відповідності із шаблоном. Конфігурація у структурі надає конфігурацію властивостей шаблону та його зовнішніх зв'язків.


Логіку роботи логічного рівня параметрів можна записати наступним чином:


Шаблон параметрів в цілому надає наступне:


На рисунку 9 наведено зображення вкладки конфігурації шаблону параметрів підсистеми "Збір Даних" у вигляді таблиці з конфігурацією входів/виходів та тексту програми користувацького програмування.


Вкладка конфігурації шаблону параметрів підсистеми "Збір Даних". (141 Кб)
Рис. 9. Вкладка конфігурації шаблону параметрів підсистеми "Збір Даних".

Вкладкою входу/виходу шаблону параметра передбачені наступні властивості спеціалізованого призначення: "Атрибут", "Доступ" та "Значення".


Властивість "Атрибут" виступає ознакою відображення входу/виходу шаблону на результуючий атрибут параметра. Передбачено наступні варіанти цієї властивості:


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


Поле "Значення" описує передвстановлене значення для постійних та шаблон конфігурації зовнішніх зв'язків. Шаблон конфігурації зовнішніх зв'язків використовується в цілях опису механізму групування та автоматичного розподілу зовнішніх зв'язків. Структура шаблону конфігурації зовнішніх зв'язків специфічна для кожного модуля підсистеми "Збору Даних", який використовує механізм шаблонів. У випадку з модулем логічного рівня розподіл відбувається над зовнішніми атрибутами параметрів з шаблоном конфігурації зовнішнього зв'язку виду: {Параметр}|{атрибут}. Де "Параметр" використовується для об'єднання параметрів та розташування на форму конфігурації, а атрибут для асоціативного зв'язування атрибутів при призначені параметру.


У якості прикладу використання шаблону на рис.10 приведемо зображення параметру модуля логічного рівня "F3". На рис.10 представлено вкладку "Конфігурація шаблона" для конфігурації, включаючи зв'язування, шаблону параметру. На рис.11 представлено вкладку "Атрибути" з переліком атрибутів та їх значень, створених за посередництвом шаблону.


Вкладка "Конфігурація шаблону" параметру "F3" модуля логічного рівня. (81 Кб)
Рис. 10. Вкладка "Конфігурація шаблону" параметру "F3" модуля логічного рівня.

Вкладка "Атрибути" параметру "F3" модуля логічного рівня. (109 Кб)
Рис. 11. Вкладка "Атрибути" параметру "F3" модуля логічного рівня.

4. Резервування джерел даних

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


Горизонтальне та вертикальне резервування. (56 Кб)
Рис. 12. Горизонтальне та вертикальне резервування.

У випадку з підсистемою "Збір Даних" системи OpenSCADA резервування даних (рис.12) виконує функції:


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


Налаштування резервування починається з додання резервних станцій в перелік системних станцій OpenSCADA на вкладці "Підсистема" підсистеми "Транспорти" (рис.13). Причому додавати тут потрібно не тільки резервні станції до поточної, але й саму цю поточну станцію з її зовнішньою адресою, тобто своєрідна петля. В подальшому ці налаштування будуть збережені у загальну БД резервованої системи, а сама БД з цього моменту буде використовуватися при створені всіх резервних станцій. Відповідно важливо на цьому етапі внести всі потрібні зміни до загальну БД довкола проекту в цілому!


Вкладка "Підсистема" підсистеми "Транспорти". (67 Кб)
Рис. 13. Вкладка "Підсистема" підсистеми "Транспорти".

Далі на конкретній станції, з копією загальної БД, налаштовуємо її специфічні параметри у вкладці "Резервування" головної сторінки (рис.14), які будуть збережені у конфігураційному файлі.


Вкладка "Резервування" головної сторінки. (80 Кб)
Рис. 14. Вкладка "Резервування" головної сторінки.

Після цього вся конфігурація резервування збору даних здійснюється зі вкладки "Резервування" підсистеми "Збір Даних" (рис.15), а якщо встановити параметр "Передача локальних первинних команд" (рис.14) то ця конфігурація, як і будь яка інша конфігурація загального характеру, може здійснюватися на одній з станцій, а внесенні зміни потраплять й на всі резервні, звісно якщо вони будуть доступні.


Вкладка "Резервування" підсистеми "Збір Даних". (124 Кб)
Рис. 15. Вкладка "Резервування" підсистеми "Збір Даних".

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


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


Для об'єкту контролера підсистеми "Збір Даних" передбачено режими резервування "Асиметричне" та "Тільки порушення". Асиметричне резервування працює з тією конфігурацією контролеру віддаленої станції, яка є і не намагається її узагальнювати, для якого працюють всі раніш описані функції та властивості резервування. Резервування "Тільки порушення" передбачає фактичну роботу без резервування, але з придушенням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.

Посилання

Страницы, ссылающиеся на данную: HomePageUk/Doc


 
Много файлов (16).[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]