Головна » Прес-Центр » Статті та публікації » Можливості взаємодії SCADA системи zenon із зовнішнім програмним забезпеченням
23.07.2014
Постановка завдання. У промисловості є класи об'єктів керування, при автоматизації яких основне значення має якість керування, а не швидкодія. Розробка систем керування для таких об'єктів пов'язана з великими витратами часу на вибір і реалізацію алгоритму керування. При цьому реалізація алгоритму може бути виконана на рівні логічного контролера або SCADA системи на базі програмного логічного контролера, скриптів, VBA, VSTA або інших технологій.
Безпосередньо розробка алгоритмів та їхня первинна перевірка виконується у спеціалізованому програмному забезпеченні, такому як: MATLAB, LabVIEW, Mathematica, Maple та інші. Пряме перенесення алгоритмів на програмовний логічний контролер або SCADA систему вимагає великих тимчасових витрат, що пов'язано з особливостями реалізації мов програмування як програмного забезпечення, так і засобів автоматизації.
З цього випливає, що на етапі розробки доцільно використовувати як пристрій виконання алгоритму керування персональний комп'ютер з відповідним програмним забезпеченням, а як пристрій керування програмовний логічний контролер або модулі віддаленого введення-виводу. При цьому доступ до програмовного логічного контролера або модулів віддаленого вводу-виводу може бути організований як безпосередньо (якщо даний контролер підтримується програмним забезпеченням), так і за допомогою SCADA системи, яка володіє необхідним набором драйверів.
Одним із лідерів ринку SCADA систем є zenon, що випускається австрійською компанією COPA-DATA. Дана система обдає широким функціоналом, великим вибором драйверів (понад 300), пройшла сертифікацію компанії Microsoft та відповідає вимогам багатьох міжнародних стандартів. Розглянемо можливості SCADA системи zenon Supervisor 7.10 щодо взаємодії із зовнішнім програмним забезпеченням MATLAB R2012b.
Визначальною особливістю SCADA Zenon є вертикальна відкритість. Завдяки передовим технологіям, впровадженим у даний програмно-технічний комплекс, всі потоки інформації, зібрані на рівні датчиків та виконавчих механізмів, можуть бути оперативно оброблені та передані у зовнішні MES- та ERP-системи, де здійснюється аналіз та планування сучасного виробництва.
До складу SCADA системи zenon входить комунікаційний шлюз zenon Process Gateway. Він призначений для встановлення зв'язку з системами високого рівня та включає наступні модулі: DEC Slave, DNP3 Slave, ICCP/TASE.2, IEC61870-5-01/104 Slave, Modbus Slave, OPC DA Server, OPC UA Server, SNMP Server, SQL Online. Модулі не залежать від SCADA системи, вимагають окремого ліцензування та можуть бути розроблені та розширені окремо від неї.
Модуль DEC Slave дозволяє здійснювати двонаправлений обмін із системами зберігання даних S-DEC, які працюють під керуванням операційної системи UNIX. Обмін даними побудовано з урахуванням протоколу TCP.
Модуль DNP3 Slave дозволяє здійснювати двонаправлений обмін даними між компонентами АСУ ТП. При комунікації використовується послідовний інтерфейс чи Ethernet.
Модуль ICCP/TASE.2 дозволяє здійснювати двонаправлений обмін даними відповідно до стандарту МЕК 60870-6. Стандарт визначає базовий протокол передачі простих повідомлень для дистанційного контролю між двома системами. Для обміну даними можна використовувати послідовний інтерфейс або Ethernet.
Модуль IEC61870-5-01/104 Slave дозволяє здійснювати двонаправлений обмін даними відповідно до стандарту МЕК 61870-5-104. Для обміну даними можна використовувати послідовний інтерфейс або Ethernet.
Модуль Modbus Slave дозволяє здійснювати двонаправлений обмін даними відповідно до протоколів Modbus RTU та Modbus TCP/IP. Для обміну даними можна використовувати послідовний інтерфейс або Ethernet.
Модуль OPC DA Server дозволяє здійснювати двонаправлений обмін даними з OPC DA клієнтами версій 1.X, 2.X. Передача даних побудована з урахуванням технологій OLE, COM/DCOM компанії Microsoft.
Модуль OPC UA Server дозволяє здійснювати двонаправлений обмін даними, що не залежить від апаратно-програмної платформи клієнта, а також типу його мережі. Транспортний механізм обміну даними побудований на базі SOAP, XML, HTTP та сервісів.
Модуль SNMP Server дозволяє здійснювати двонаправлений обмін даними, заснований на базі архітектури UDP/TCP.
Модуль SQL Online дозволяє здійснювати односпрямований запис до бази даних SQL. При цьому модуль стежить за тим, щоб у базі даних завжди знаходилися актуальні значення.
Якщо у споживача є готове рішення, що виступає в мережі провідним пристроєм або сервером іншої технології, то zenon дозволяє без перешкод підключитися до нього за допомогою відповідного драйвера: DNP3 Driver Next Generation, IEC 60870-5-10X V2-0 driver, OPC UA Client driver, SNMP Driver, SQL Driver, Write variable value in SQL.
Для організації двонаправленого зв'язку з програмами SAP/RP ERP в систему інтегровано модуль SAP Interface. Завдяки цьому користувачі, які займаються плануванням бізнес-процесів, можуть в онлайн режимі взаємодіяти з рівнем виробництва підприємства.
Також для обміну даними зі SCADA системою zenon може бути використаний механізм взаємодії додатків DDE, що є стандартним для сімейства операційних систем Microsoft Windows.
Проаналізувавши перерахований перелік рішень, можна дійти невтішного висновку, що найбільш підходящими поставленої завдання є технології DDE, OPC DA і SQL, які й будуть розглянуті далі.
Dynamic Data Exchange (DDE) – це механізм обміну даними між різним програмним забезпеченням, що використовується у Windows. Ця технологія підтримує як одноразову передачу даних, так і безперервну.
Механізм DDE реалізує клієнт-серверну архітектуру. Як клієнт може виступати будь-яке програмне забезпечення, що дозволяє відправляти запити до сервера, а як сервер – програмне забезпечення, що вміє приймати запити від клієнта і посилати дані у відповідь на запит. Один сервер може мати один або кілька клієнтів.
Дані доступні серверу DDE адресуються за допомогою теми “Topic” та розділу “Item”. Сервер може включати кілька тем, кожна з яких може мати кілька розділів. Обмін даними між клієнтом та сервером організовуються на основі транзакцій. Розглянемо два основні типи транзакцій. Транзакція запиту даних “Транзакція 1” починається із запиту від клієнта до сервера, в якому мають бути вказані назва сервера “Додаток 1”, назва теми “Topic 1”, назва розділу “Item 1”. У відповідь на запит сервер повертає дані пов'язані з темою та розділом "Дані 1". На цьому транзакція завершується. Транзакція передачі даних “Транзакція 2” складається тільки із запиту від клієнта до сервера, в якому вказується назва сервера “Додаток 1”, назва теми “Topic 1”, назва розділу “Item 1” та дані “Дані”.
SCADA система zenon може працювати як DDE сервер і як DDE клієнт. Оскільки зовнішнє програмне забезпечення MATLAB може бути лише у ролі DDE клієнта, розглянемо процес налаштування SCADA системи zenon як DDE сервера.
Для цього в SCADA системі zenon створимо внутрішню змінну "DDEVariableOutput" цілого типу "INT".
Щоб дана змінна була доступна DDE серверу і, отже, зовнішньому програмному забезпеченню в її налаштуваннях необхідно встановити прапор “Permanently read variable” (Постійне опитування змінної), при цьому значення змінної DDE сервера оновлюватиметься кожні 500 мілісекунд.
Доступ до змінних SCADA системи zenon можливий лише під час роботи середовища виконання (Runtime). При формуванні запиту з боку DDE клієнта як ім'я сервера має бути встановлено значення “ZENVIS”. Змінні доступні для DDE сервера перебувають у темі “VARIABLE”, а назва розділу збігається з ім'ям змінної “DDEVARIABLEOUTPUT”, регістр символів у назві змінної значення немає.
Далі наведено приклад програми на мові MATLAB, що дозволяє отримати значення змінної “DDEVariableOutput” та задати їй нове значення:
OPC Data Access – це найбільш широко використовувана технологія стандарту OPC, призначена для надання єдиного інтерфейсу керування об'єктами автоматизації, технологічними процесами та організації обміну даними між програмним забезпеченням розробленим під сімейство операційних систем Microsoft Windows. Вона побудована на базі технологій OLE, COM/DCOM і здійснює читання, запис та моніторинг змінних у реальному часі, що являють собою контрольовані параметри. Операції читання та запису можуть виконуватися синхронно, асинхронно, по оновленню даних та спонтанно.
Технологія OPC DA має клієнт-серверну архітектуру. Як OPC клієнт може виступати будь-яке програмне забезпечення, що підтримує один з інтерфейсів: “Custom” або “Automation”.
Інтерфейс “Custom” використовується в клієнтах, що розробляються компілюваними мовами програмування (С, C++). Такі клієнти працюють з OPC серверами безпосередньо за допомогою COM інтерфейсу.
Інтерфейс Automation побудований на базі технології OLE Automation, яка дозволяє звертатися до COM-компонентів з інтерпретованих мов програмування (MATLAB, Maple, Mathcad, VBScript). Такі клієнти використовують інтерфейс OPC Automation interface для зв'язку з обгорткою OPC Automation Wrapper, яка за допомогою COM інтерфейсу безпосередньо працює з OPC серверами.
Як OPC сервер може виступати спеціалізоване програмне забезпечення, що має COM інтерфейс і забезпечує доступ до об'єктів автоматизації та програмного забезпечення за допомогою інтерфейсу програмування додатків “Native API”.
У більшості OPC сервери розробляються виробниками апаратного та програмного забезпечення, щоб надати доступ до їх даних зовнішнього програмного забезпечення. Для цього OPC сервера включають набори драйверів, за допомогою яких вони отримують доступ до даних апаратного або програмного забезпечення і COM інтерфейс, що дозволяє отримати доступ до цих даних з будь-якого зовнішнього програмного забезпечення. Цей підхід дає можливість працювати з даними з різних джерел, абстрагуючись від процесу формування.
Розглянемо взаємодію програмного забезпечення OPC сервера із клієнтами. Вихідно OPC сервер знаходиться у вимкненому стані. За запитом клієнта сервер запускається, після чого між ними встановлюється з'єднання. Далі виконується ініціалізація клієнта.
Під час ініціалізації відбувається налаштування доступу до даних. Клієнт запитує сервер список елементів “Item”, до яких має доступ OPC сервер. Сервер повертає “ItemID” доступних елементів, які є текстові, унікальні в межах сервера, ідентифікатори, однозначно пов'язані з його елементами.
У свою чергу кожен елемент є об'єктом, що містить дані пристрою або програмного забезпечення, до яких надає доступ OPC сервер. Крім самих даних, об'єкт містить мітку часу та інформацію про їхню якість (як точно відповідають дані сервера даним пристрою або програмного забезпечення).
Далі клієнт створює групи “Group”, налаштовує їх властивості, і вміщує у яких елементи, із даними яких він взаємодіяти. Групи створюються за сервера і може бути приватними “private” чи загальними “public”. Приватні групи доступні лише клієнту, який створив їх, спільні групи доступні всім клієнтам. Для кожного клієнта сервер створює копію спільної групи. Тобто за фактом, кожна конкретна група, що належить конкретному клієнту, фізично розташовується за сервера, а логічно – за клієнта. З груп формуються ієрархічні структури, які об'єднують дані пов'язані загальної логікою походження чи використання.
Групи мають властивості, що дозволяють керувати оновленням даних OPC сервера:
Після завершення етапу ініціалізації клієнт отримує доступ до даних елементів сервера OPC. Обмін даними може відбуватися як у синхронному, так і асинхронному режимах. Після того, як останній клієнт відключиться від OPC сервера, він вимкнеться.
На малюнку наведено типову структуру взаємодії "Додатки" клієнта з OPC серверами. Програмовні логічні контролери підключені до "OPC сервера 1", панелі людино-машинного інтерфейсу до "OPC сервера 2", а SCADA система zenon до "OPC сервера N". "Додаток" за допомогою "OPC клієнта" підключений до всіх OPC серверів. Елементи OPC серверів додані до груп таким чином, щоб зручно було визначити до якого пристрою або програмного забезпечення вони відносяться.
SCADA система zenon може функціонувати як OPC сервер та як OPC клієнт. Оскільки зовнішнє програмне забезпечення MATLAB може бути лише у ролі OPC клієнта, розглянемо процес налаштування SCADA системи zenon як OPC сервера.
OPC DA Server хоч і входить до складу zenon Process Gateway є окремим програмним забезпеченням "zenon OPC Server", яке реєструється в операційній системі Microsoft Windows під ім'ям "zenOPCSrv.Server.1" і запускається під час роботи середовища виконання на запит від OPC клієнта . Цей сервер є локальним і тому доступний для додатків тільки того персонального комп'ютера, на якому працює середовище виконання, крім того, він не може бути запущений в операційних системах Microsoft Windows CE.
Якщо zenon OPC сервер недоступний через клієнт OPC, його необхідно зареєструвати. Для цього потрібно запустити "zenon Startup Tool" від імені адміністратора, вибрати у вікні інструментів "Tools" пункт "OPC server" і задати в рядок "Command line parameters" (Командний рядок параметрів) параметр "/RegSrvD" (перед параметром необхідно додати пробіл ).
zenon OPC сервер надає доступ до змінних всіх проектів, що виконуються середовищем виконання. Кожній змінній проекту SCADA системи zenon відповідає елемент, що має ідентифікатор виду <PROJECT.Variable>, де PROJECT – ім'я проекту, а Variable – ім'я змінної у цьому проекті. Елементи, які відповідають змінним різних проектів, не можуть перебувати в одній групі, тому для кожного проекту необхідно використовувати окрему групу. З іншого боку, оскільки SCADA система zenon і zenon OPC сервер працюють одному комп'ютері, сервер ігнорує властивість групи “час опитування” і виконує оновлення даних відразу після зміни.
Створимо в SCADA системі zenon внутрішню змінну "OPCVariableOutput" цілого типу "INT". Для організації доступу до OPC сервера змінна не потребує додаткових налаштувань у zenon. Тому після запуску середовища виконання вона відразу буде доступна клієнту OPC.
Далі наведено приклад програми на мові MATLAB, що дозволяє отримати значення змінної "OPCVariableOutput" і задати їй нове значення (для того, щоб у MATLAB працював OPC Toolbox, необхідно за допомогою команди "opcregister('install')") встановити OPC клієнт:
В автоматизованих системах керування технологічними процесами (АСК ТП) бази даних використовуються для обміну даними з програмовними логічними контролерами, зберігання списків подій та тривог, а також вихідних даних для побудови історичних трендів. Серед існуючих систем керування базами даних (СКБД) найбільшого поширення набули реляційні, що підтримують формальний непроцедурний мову програмування SQL.
Мова SQL використовується для створення структур баз даних, отримання доступу до даних, зміни даних та детально описаний у стандарті ANSI. Однак розробники СКБД, що широко використовуються, виконують самостійне розширення мови програмування SQL, що забезпечує підтримку нестандартних типів даних і додаткових можливостей серверів, а також погіршує сумісність і перехід між продуктами різних виробників. У зв'язку з цим доступу до СКБД найчастіше використовуються стандартизовані інтерфейси ODBC і OLE DB.
Open Database Connectivity (ODBC) є програмним інтерфейсом, що забезпечує доступ до різних СКБД за допомогою спеціальних драйверів, що надаються розробниками, які реалізують правильне формування запитів до баз даних.
Розглянемо взаємодію програмного забезпечення з базою даних за допомогою інтерфейсу ODBC. Перед тим, як програма зможе отримати доступ до джерела даних, необхідно створити ім'я джерела даних Data Source Name (DSN). Ця операція виконується за допомогою "Адміністратора джерела даних ODBC", який є системною утилітою, що постачається у складі операційних систем Microsoft Windows.
При створенні DSN вибирається тип доступу до джерела даних: користувач (доступний поточному користувачеві), системний (доступний всім користувачам) і файловий (налаштування DSN зберігаються в окремому файлі). Вибирається драйвер, котрим виконується створення джерела даних, тобто із яким СКБД він буде пов'язаний. Налаштовуються параметри драйвера. Задається ім'я джерела даних DSN, що є унікальним текстовим ідентифікатором.
Доступ до джерела даних “Програми” здійснюється за допомогою “Бібліотеки доступу до ODBC”. Бібліотека на запити “Програми” здійснює виклики функцій ODBC API, формуючи таким чином SQL-команди для джерела даних з відповідним ім'ям DSN. SQL-команди передаються “Диспетчеру драйверів ODBC”, який перенаправляє їхньому відповідному драйверу пов'язаному з DSN. У відповідь на виклик функції “Додаток” отримує дані або результат виконання SQL-команди.
Таким чином, "Додаток" може працювати з даними "Microsoft SQL Server" за допомогою DSN "СКБД 1", з "Microsoft Access" за допомогою DSN "СКБД 2" та "MySQL" за допомогою DSN "СКБД 3".
Object Linking and Embedding Dat abase (OLE DB) є набір інтерфейсів, заснований на COM-технологии. Він повинен був прийти на зміну інтерфейсу ODBC, проте на сьогоднішній день обидва рішення мають більшу поширеність. Головною відмінністю OLE DB від ODBC є додавання в першу підтримку СКБД, які не використовують мову SQL, а також додавання підтримки неструктурованих джерел даних.
Розглянемо взаємодію програмного забезпечення з базою даних у вигляді інтерфейсу OLE DB. Перед тим, як споживач даних “Програма” зможе отримати доступ до джерела даних, необхідно налаштувати властивості каналу передачі. Ця операція виконується безпосередньо в “Додатку” за допомогою інструментів, що надаються COM-компонентом.
Під час налаштування вибирається постачальник “provider”, який може бути постачальником даних “OLE DB Data Provider” (надає доступ до власних даних) або постачальником служб “OLE DB Data Service” (надає певні послуги і не має власних даних). Вказуються параметри з'єднання з джерелом даних та права доступу до них.
Доступ до джерела даних із “Програми” здійснюється за допомогою “Бібліотеки доступу до OLE DB”. Бібліотека на запити "Додатки" створює COM-об'єкти, отримує інтерфейси та викликає їх методи, формуючи тим самим команди. Команди обробляються відповідним провайдером, який запитує дані у джерела, формує записи, заповнює їх отриманими даними та повертає додатку.
Таким чином, "Додаток" може працювати з даними "Microsoft SQL Server" за допомогою "Постачальника 1", з текстовими файлами за допомогою "Постачальника 2", з повідомленнями електронної пошти за допомогою "Постачальника 3" та джерелами даних, які підтримують тільки інтерфейс ODBC за допомогою " Постачальника N”.
SCADA система zenon дозволяє використовувати для зв'язку з СКБД обидва описані інтерфейси. Розглянемо використання інтерфейсу OLE DB, що підтримується модулем SQL Online, що входить до складу zenon Process Gateway.
Модуль SQL Online призначений для односторонньої передачі до СКБД актуальних значень змінних. Для його використання не потрібно внесення змін до проекту, достатньо під час роботи середовища виконання виконати його налаштування за допомогою zenon Process Gateway. Після цього в базі даних буде створено дві таблиці “ONLINE_VARIABLES” та “ONLINE_VALUES”.
У таблиці “ONLINE_VARIABLES” зберігається ім'я змінної та її ідентифікатор.
| № | Стовпець | Тип даних | Розмір масиву | Опис |
|---|---|---|---|---|
| 1 | VARIABLE | int | 4 | Ідентифікатор змінної (ключ) |
| 2 | NAME | varchar | 128 | Ім'я змінної |
У таблицю “ONLINE_VALUES” зберігаються поточні значення змінних, вибраних під час налаштування zenon Process Gateway, штампи часу та слова стану у форматі SCADA системи zenon.
| № |
Стовпець |
Тип даних |
Розмір масиву |
Опис |
|---|---|---|---|---|
| 1 | VARIABLE | int | 4 |
Ідентифікатор змінної (ключ) |
| 2 | VALUE | varchar | 64 | Поточне значення у вигляді рядка |
| 3 | VALUE_NUM | float | 1 | Поточне значення у вигляді речовинного числа |
| 4 | TIMESTAMP | int | 4 | Тимчасовий штамп поточного значення у форматі UNIX |
| 5 | TIMESTAMP2 | datetime | 1 | Часовий штамп поточного значення у форматі Дата/Час |
| 6 | STATUS | int | 4 | Слово стану поточного значення |
Щоб отримати поточне значення змінної із СКБД, зовнішнє програмне забезпечення має віднімати з таблиці “ONLINE_VARIABLES” ідентифікатор змінної, після чого відповідно до нього з таблиці “ONLINE_VALUES” має бути раховано поточне значення.
Розглянемо використання модуля SQL Online практично. Для цього в SCADA системі zenon створимо внутрішню змінну "SQLPVariableOutput" цілого типу "INT". Далі запустимо середовище виконання та “zenon Startup Tool”.
Для запуску zenon Process Gateway необхідно у вікні інструментів "Tools" вибрати пункт "Process Gateway" і задати в рядок "Command line parameters" параметр "/ini:<ім'я файлу налаштувань>.ini" (перед параметром необхідно додати пробіл). Як ім'я файлу налаштувань служить ім'я створеної змінної — "SQLPVariableOutput". Якщо zenon Process Gateway раніше не запускався, рядок параметрів можна залишити порожнім.
Після запуску zenon Process Gateway необхідно вибрати бібліотеку "AccessSQL.dll", що відповідає модулю SQL Online.
У вікні конфігурації модуля вибирається СКБД, в яку повинні зберігатися змінні, а так само самі змінні середовища виконання.
Вікно властивостей каналу даних відповідає стандартному вікну інтерфейсу OLE DB. Як джерело даних виберемо постачальник драйвера ODBC “Microsoft OLE DB Provider for ODBC Drivers”.
Перед виконанням налаштування каналу передачі даних необхідно виконати параметризацію ODBC драйвера. Для цього необхідно створити ім'я джерела даних DSN. Під час підготовки статті у цьому питанні автори зіштовхнулися з низкою особливостей, пов'язаних із використанням 64-розрядної операційної системи:
Для отримання доступу до 64-розрядної версії “Адміністратора джерела даних ODBC” необхідно створити ярлик з наступною адресою
Після запуску адміністратора джерела даних ODBC потрібно створити джерело даних на основі драйвера Microsoft Access Driver (*.mdb), задати його ім'я та створити файл бази даних. Далі аналогічним чином необхідно створити ім'я джерела даних у 32-розрядній версії адміністратора і вибрати створений файл бази даних.
Створене 64-розрядне джерело даних необхідно вказати в налаштуваннях з'єднання OLE DB. Після завершення налаштування модуля SQL Online zenon Process Gateway автоматично створить таблиці “ONLINE_VARIABLES” та “ONLINE_VALUES”, після чого поточні дані вибраних змінних SCADA системи zenon стануть доступними для диспетчера драйверів ODBC.
Далі наведено приклад програми мовою MATLAB, що дозволяє отримати значення змінної “SQLPVariableOutput”:
Відображення таблиць “OLINE_VARIABLES” та “ONLINE_VALUES” у програмному забезпеченні Microsoft Access до та після зміни значення змінної:
SCADA система zenon підтримує як односпрямований, і двонаправлений доступом до значенням змінних через СКБД. Для реалізації двонаправленого доступу використовується драйвер "SQL Driver". На відміну від модуля SQL Online драйвер використовує одну таблицю для отримання даних через СКБД, а другу таблицю для передачі даних. Нижче на малюнку наведено процес обміну даними між SCADA системою zenon та програмним забезпеченням MATLAB.
СКБД містить дві таблиці: перша “ZRECEIVE” – прийому даних, друга “ZSEND” – передачі даних. У початковий момент поточне значення змінної SQLVariableOutput типу INT відповідає 13. У момент виникнення події зміни значення змінної (наприклад, завдання оператором значення 66 через числовий індикатор) нове значення передається драйверу, який у свою чергу поміщає його в таблицю ZZEND”.
Зовнішнє програмне забезпечення MATLAB виконує опитування таблиці “ZSEND”, у результаті відбувається вичитування з неї значення змінної 66. У цьому цикл передачі значення змінної завершується. Однак слід підкреслити, що на даному етапі значення змінної SQLVariableOutput в SCADA системі zenon відповідає 13, а в MATLAB відповідає 66.
Під час роботи SQL Driver виконує циклічне опитування таблиці ZRECEIVE. Після того, як MATLAB помістить значення змінної 66 в таблицю, драйвер зчитує і видаляє її вміст, а отримане значення буде присвоєно змінної SQLVariableOutput. Якщо таблиці перебуває кілька значень однієї й тієї ж змінної, буде використано значення з найбільшим ідентифікатором. На цьому етапі значення змінної “SQLVariableOutput” у SCADA системі zenon стає рівним 66, і цикл передачі значення змінної завершується.
Розглянемо використання драйвера "SQL Driver" на практиці. При додаванні драйвера через його налаштування можна створювати імена джерел даних DSN. Однак у зв'язку з тим, що необхідно мати джерело даних для 32-розрядного диспетчера драйверів ODBC "SQLVariableOutput_x86" і для 64-х розрядного "SQLVariableOutput_x64", їх зручніше додати за допомогою "Адміністратора джерел даних ODBC".
Під час налаштування драйвера вибирається джерело даних, задається таблиця, з якої драйвер вичитуватиме дані “Receive table” та таблиця, в яку драйвер записуватиме дані “Send table”.
Далі в драйвері створюються змінні СКБД, кожній з яких задається ім'я "Name" ("Benennung"), тип даних "Data type" ("Datentyp)" та унікальний числовий ідентифікатор "Memory number" ("Merker"), який дозволяє драйверу організувати зв'язок між змінними SCADA системи zenon та змінними СКБД.
Для створення змінних SCADA системи zenon на основі опису змінних СКБД використовується операція імпорту “Import variable from driver…”. У вікні імпорту вибираються необхідні змінні, після чого середовище розробки автоматично створить змінні SCADA системи zenon відповідного типу даних та виконає налаштування їхньої адресації.
Щоб SCADA система zenon могла працювати з СКБД, в останній необхідно створити дві таблиці з іменами, заданими в налаштуваннях драйвера "ZRECEIVE" та "ZSEND".
Таблиця “ZRECEIVE” використовуватиметься отримання даних із СКБД, а таблиця “ZSEND” – передачі даних у СКБД. Обидві таблиці мають однакову структуру.
| № | Стовпець | Тип даних | Опис |
|---|---|---|---|
| 1 | ID | Лічильник | Лічильник з автоматичним збільшенням (ключ) |
| 2 | NAME | Текстовий | Ім'я змінної |
| 3 | DATUMZEIT | Дата/Час | Штамп часу DD.MM.YYYY HH:mm:ss |
| 4 | ZEIT_MS | Числовий | Мілісекунди штамп часу |
| 5 | WERT | Текстовий | Значення змінної |
| 6 | STATUS | Числовий | Слово стану (64-біта) |
У разі використання в налаштуваннях драйвера функції резервування “Redundancy”, таблиця “ZRECEIVE” має бути розширена:
| № | Столбец | Тип даних | Опис |
|---|---|---|---|
| 1 | ACK_SRV | Числовий | 1 – сервер прочитав дані |
| 2 | ACK_SB | Числовий | 1 – standby сервер прочитав дані |
| 3 | INSERZEIT | Дата/Час | Час додавання рядка (обчислюється функцією Now) |
Далі наведено приклад програми мовою MATLAB, що дозволяє отримати значення змінної “SQLVariableOutput”:
Далі на малюнку наведено послідовність змін значень змінних у таблицях “ZRECEIVE” та “ZSEND”, що виконується під час роботи програми:
З розглянутих рішень можна зробити такі висновки:
Бойко Олег Олександрович, Національний гірничий університет, кафедра автоматизації та комп'ютерних систем, асистент.
Голінько Олександр Анатолійович, компанія СВ АЛЬТЕРА, інженер з автоматизації.
Проценко Станіслав Миколайович, Національний гірничий університет, кафедра автоматизації та комп'ютерних систем, доцент.