Облік архітектурних особливостей автоматизованих систем при виборі SCADA

1. Розподіл функцій між елементами системи
2. комунікаційна інфраструктура
3. рівень використання
4. Критичність до тимчасової втрати даних і управління
5. інші фактори

Стаття опублікована в журналі ИСУП №1 / 2011

Прошин Дмитро Іванович, к.т.н., начальник відділу Департаменту «Програмне забезпечення»
Гур'янов Лев Вячеславович, к.т.н., провідний спеціаліст Департаменту «Програмне забезпечення»

SCADA (Supervisory Control And Data Acquisition: диспетчерське управління і збір даних) - це назва класу систем для комплексної автоматизації промислового виробництва. Термін «SCADA» має двояке тлумачення. Часто під SCADA-системою мають на увазі програмно-апаратний комплекс. В даний час найбільш поширеним є розуміння SCADA як програмного комплексу, що забезпечує виконання функцій диспетчерського управління та збору даних, а також інструментальних засобів для розробки цього програмного забезпечення.

У попередній статті [1] автори розглянули критерії для вибору інструментальних засобів побудови SCADA-систем. У даній статті розглядаються аспекти вибору SCADA в залежності від архітектури і призначення автоматизованих систем контролю і управління.

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

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

• Розподілені системи (DCSРСУ), що характеризуються побудовою розподіленої системи вводу-виводу і децентралізацією обробки даних (малюнок 1)
• Зосереджені автоматизовані системи, всі функції в яких виконуються в рамках однієї робочої станції / сервера / контролера (малюнок 2).

Серед розподілених і клієнт-серверних систем в залежності від характеристик комунікаційної інфраструктури будемо розрізняти системи:

• Працюючі зі швидких і надійним каналах зв'язку (рисунок 1)
• Використовують повільну і ненадійну зв'язок (малюнок 2).

Беручи до уваги розподіл супервизорного функцій між користувачами системи, отримаємо ще дві групи автоматизованих систем:

• Однопользовательские. Все управління і моніторинг ведеться на одній робочій станції (наприклад, АРМ диспетчера) (рисунок 2)
• Розраховані на багато користувачів. Система надає безліч АРМ, кожне з яких виконує свою функцію (малюнок 1).

Залежно від ступеня відповідальності можна виділити наступні автоматизовані системи:

• Критичні до тимчасової втрати даних і управління (рисунок 1)
• Некритичні до тимчасової втрати даних і управління (рисунок 2).

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

Розподіл функцій між елементами системи

Розподілена (DCSРСУ) система управління характеризується наявністю декількох децентралізованих вузлів вводу-виводу і обробки даних. Існує кілька підходів до створення подібних систем. Кожен з підходів характеризується своєю собівартістю ПО, що включає як вартість розробки SCADA-проекту, так і вартість самого SCADA-інструментарію.

Малюнок 1 - АСУ ТП установки риформінгу

Перший підхід полягає в застосуванні окремих середовищ розробки для кожної з розподілених частин системи. Для програмування контролерів в цьому випадку використовується спеціалізоване ПО, що поставляється виробником контролера, наприклад, Isograph, CodeSys, Klogic. Для зв'язку з верхнім рівнем (SCADA-сервером) використовується або OPC-технологія, або стандартні відкриті протоколи типу Modbus.
Застосовуючи цей підхід, необхідно пам'ятати, що база даних тегів для кожного розподіленого вузла (контролера / сервера) створюється і налаштовується індивідуально. При зміні однієї з баз необхідно відстежувати цілісність посилань і в інших базах. При збільшенні кількості тегів в системі забезпечення цілісності баз тегів стає дуже трудомісткою завданням. Не кажучи вже про те, що розбиратися в декількох різних системах програмування і проводити їх налагодження окремо вкрай незручно.
Якщо Ви все ж використовуєте різні засоби для програмування контролера і створення SCADA-проекту верхнього рівня, то необхідно переконатися в підтримці відповідних протоколів обміну між контролером і SCADA-сервером, наприклад, в наявності відповідних OPC-серверів і OPC-клієнтів. Необхідно враховувати характер і формат даних для обміну з контролером. Наприклад, відсутність можливості передати сигнальну інформацію з контролера призведе до необхідності (можливо повторного) відстеження подій і тривог в SCADA-сервері. В рамках даного підходу також можливі проблеми з підтримкою програмного резервування джерел даних в SCADA-сервері, оскільки реалізовані відкриті протоколи можуть не підтримувати резервування в потрібному обсязі.
Незважаючи на всі ці складності, такий підхід має право на існування завдяки таким достоїнств:

• Незалежність від апаратних платформ і легка взаємозамінність окремих елементів
• Низька вартість ПО. Вартість середовищ розробки часто вже включена у вартість придбаного контролера або невисока
• Застосування типових середовищ розробки. Виробники контролерів адаптують для роботи зі своїми пристроями такі популярні середовища розробки, як Isograph, CodeSys, Klogic. При цьому, якщо користувач мав досвід роботи з подібним ПО, йому немає потреби вивчати його повторно.

Другий підхід, більш популярний, полягає в застосуванні інтегрованих SCADA, в яких середовище розробки об'єднує в себе кошти для програмування контролерів, серверів і графічних станцій. Це досягається за рахунок підтримки свого середовища виконання контролерів і власного (спеціалізованого) протоколу обміну між серверами і контролерами.

Переваги такого підходу очевидні:

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

Малюнок 2 - АИИС ТУЕ

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

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

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

комунікаційна інфраструктура

Значний вплив на вибір SCADA надає комунікаційна інфраструктура автоматизованої системи і, зокрема, якість каналів зв'язку між контролерами і серверами. Мала пропускна здатність каналу зв'язку і імовірно висока ціна за передану інформацію накладають вимоги підтримки епізодичного (сеансового) характеру обміну даними між контролером і сервером, а також необхідність збереження історії в контролері.
Оскільки циклічний режим обміну даними в таких випадках є неприйнятним, в системі повинні бути реалізовані спорадичні (в довільні моменти часу) режими обміну з ініціативи контролера і SCADA-сервера.
Додатковою вимогою до SCADA є підтримка «історичних» інтерфейсів і протоколів обміну між SCADA-сервером і контролером, тобто обмін даними повинен включати в себе можливість надійної передачі цілого тренда за вказаний часовий період. Наприклад, якщо в якості основного стандарту обміну даними прийнятий OPC, то необхідно переконатися в підтримці OPC HDA специфікації контролером і SCADA-сервером. У інтегрованої SCADA необхідно упевнитися, що внутрішній протокол обміну також володіє необхідними властивостями.

рівень використання

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

Зазвичай виділяють клієнтів двох видів:

• Web-клієнт, який надає можливість моніторингу і управління системою через звичайний Web-браузер
• Локальний клієнт, для функціонування якого необхідно встановлювати спеціалізований програмний компонент - клієнт - від виробника SCADA.

Переваги у використанні Web-клієнта наступні:

• Мінімальні налаштування і адміністративні дозволу для роботи в Intranet / Internet мережах
• Легка інтеграція в загальну інформаційну систему підприємства (web-портал)
• Значне зниження витрат на технічне обслуговування кінцевих АРМов, так як для функціонування клієнта потрібен тільки Web-браузер
• Використання різних платформ, де можливе функціонування тільки web-браузера. Наприклад, моніторинг / управління системою через надолонний або планшетний комп'ютер.

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

З приходом нових технологій, таких як ASPNET і SilverLight, Web-орієнтовані SCADA набирають все більшої популярності.

Локальні клієнти, на відміну від Web-клієнтів, гарантують своєчасну доставку на сервер, що управляють, і мають підвищену інтерактивністю.
Однак не слід забувати, що ці клієнти вимагають установки додаткового програмного забезпечення на кожен «клієнтський» комп'ютер і функціонують тільки в рамках конкретних операційних систем.

Критичність до тимчасової втрати даних і управління

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

інші фактори

Крім архітектурних особливостей автоматизованої системи при виборі SCADA також необхідно враховувати наявність в ній:

• системи звітів
• Необхідних форматів імпорту і експорту даних
• Можливості збереження і ведення бази тегів в стандартній СУБД
• Вбудованої системи тривог і подій
• Засобів ведення трендів і архівування історії зміни параметрів
• Розвинених графічних можливостей для візуалізації
• скриптовой підсистеми
• Можливості масштабування системи на потрібну кількість тегів.

Успішний, багаторічний досвід побудови SCADA-систем в різних галузях промисловості дає нам право рекомендувати до застосування програмні засоби, розроблені НПФ «КОЛО»:

У таблиці 1 показані приклади систем в різних областях промислової автоматизації та обрані для їх реалізації SCADA.

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

1. Прошин Д.І., Гур'янов Л.В. Проблеми вибору інструментальних засобів побудови SCADA-систем, ИСУП №1 2010 р