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

Класифікація програмних засобів АСУТП.Як ми вже згадували, у типовій архітектурі SCADA-системи явно проглядаються два рівні:

· рівень локальних контролерів , що взаємодіють з об'єктом управління за допомогою датчиків та виконавчих пристроїв;

· рівень оперативного управління технологічним процесом, основними компонентами якого є сервери, робочі станції операторів/диспетчерів, спеціалістів АРМ.

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

Рисунок 5.2 – Класифікація програмних засобів системи управління.

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

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

Вибір операційної системи програмно-технічних засобів верхнього рівняАСУТП визначається прикладним завданням (ОС загального користування чи ОСРВ). Але найбільшу популярність та поширення набули різні варіанти ОС Windows. Ними оснащені програмно-технічні засоби верхнього рівня АСУТП, представлені персональними комп'ютерами (ПК) різної потужності та конфігурації – робочі станції операторів/диспетчерів та спеціалістів, сервери баз даних (БД) тощо.

Така ситуація виникла внаслідок цілого ряду причин та тенденцій розвитку сучасних інформаційних та мікропроцесорних технологій.

Ось кілька основних аргументів на користь Windows:

· Windows має дуже широке поширення у світі, в тому числі і в Казахстані, у зв'язку з чим легко знайти спеціаліста, який міг би супроводжувати системи на базі цієї ОС;

· Ця ОС має безліч додатків, що забезпечують вирішення різних завдань обробки та подання інформації;

· ОС Windows і Windows-додатки прості в освоєнні і мають типовий інтуїтивно зрозумілий інтерфейс;

· Програми, що працюють під керуванням Windows, підтримують загальнодоступні стандарти обміну даними;

· Системи на базі ОС Windows прості в експлуатації та розвитку, що робить їх економічними як з точки зору підтримки, так і при поетапному зростанні;

· Microsoft розвиває інформаційні технології (ІТ) для Windows високими темпами, що дозволяє компаніям, які використовують цю платформу "йти в ногу з часом".

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

Для функціонування системи управління необхідний ще один тип ПЗ - прикладне програмне забезпечення(ППО). Відомі два шляхи розробки прикладного програмного забезпечення систем керування:

· Створення власного прикладного ПЗ з використанням засобів традиційного програмування ( стандартні мовипрограмування, засоби налагодження тощо);

· Використання для розробки прикладного ПЗ існуючих (готових) інструментальних засобів.

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

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

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

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

Нижче наведено перелік найбільш популярних у Росії та Казахстані SCADA-пакетів.

· Trace Mode/Трейс Моуд (AdAstrA) - Росія;

· InTouch (Wonderware) – США;

· FIX (Intellution) – США;

· Genesis (Iconics Co) – США;

· Factory Link (United States Data Co) – США;

· RealFlex (BJ Software Systems) – США;

· Sitex (Jade Software) - Великобританія;

· Citect (CI Technology) – Австралія;

· WinCC (Siemens) – Німеччина;

· RTWin (SWD Real Time Systems) – Росія;

· САРГОН (НВТ – Автоматика) – Росія;

· MIK $ Sys (МІФІ) - Росія;

· Cimplicity (GE Fanuc) – США;

· RSView (Rockwell Automation) - США та багато інших.

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

Основні функції системи SCADA.Програмне забезпечення типу SCADAпризначено для розробки та експлуатації автоматизованих системкерування технологічними процесами. Резонно поставити запитання: а що ж первинне – розробка чи експлуатація? І відповідь у разі однозначний – первинним є ефективний человеко-машинный інтерфейс (HMI), орієнтований користувача, т. е. на оперативний персонал, роль якого у управлінні є визначальною. SCADA – це новий підхід до проблем людського фактора в системах управління (згори вниз), орієнтація в першу чергу на людину (оператора/диспетчера), її завдання та функції, що реалізуються.

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

А що дала SCADA-система розробникам? З появою SCADA вони отримали ефективний інструмент для проектування систем управління, до переваг якого можна віднести:

· Високий ступінь автоматизації процесу розробки системи управління;

· Участь у розробці фахівців у галузі автоматизованих процесів (програмування без програмування);

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

Перш ніж говорити про функціональні можливості SCADA, пропонується поглянути на функціональні обов'язки самих операторів/диспетчерів. Які ж ці обов'язки? Слід одразу відзначити, що функціональні обов'язки операторів/диспетчерів конкретних технологічних процесів та виробництв можуть бути суттєво різними, та й самі поняття «оператор» та «диспетчер» далеко не рівнозначні. Тим не менш, серед різноманіття цих обов'язків виявилося можливим знайти загальні, притаманні даній категорії працівників:

· реєстрація значень основних технологічних та госпрозрахункових параметрів;

· Аналіз отриманих даних та їх зіставлення зі змінно-добовими завданнями та календарними планами;

· Облік та реєстрація причин порушень ходу технологічного процесу;

· Ведення журналів, складання оперативних рапортів, звітів та інших документів;

· Надання даних про хід технологічного процесу та стан обладнання у вищестоящі служби і т.д.

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

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

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

З появою в операторній/диспетчерській комп'ютерах було природною частину функцій, пов'язаних із збиранням, реєстрацією, обробкою та відображенням інформації, визначенням нештатних (аварійних) ситуацій, веденням документації, звітів, перекласти на комп'ютери. Ще за часів перших керуючих обчислювальних машин із монохромними алфавітно-цифровими дисплеями на цих дисплеях зусиллями ентузіастів-розробників уже створювалися «псевдографічні» зображення - прообраз сучасної графіки. Вже тоді системи забезпечували збирання, обробку, відображення інформації, введення команд та даних оператором, архівування та протоколювання ходу процесу.

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

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

Вихід із ситуації було знайдено у створенні методів «програмування без реального програмування», доступних розуміння як програмісту, а й інженеру-технологу. В результаті з'явилися програмні пакети для створення інтерфейсу "людина-машина" (Man/Humain Machine Interface, MMI/HMI). За кордоном це програмне забезпечення отримало назву SCADA (Supervisory Control And Data Acquisition – супервізорне/диспетчерське управління та збір даних), оскільки призначалося для розробки та функціональної підтримки АРМ операторів/диспетчерів в АСУТП. А в середині 90-х абревіатура SCADA (СКАДА) впевнено з'явилася й у лексиконі російських фахівців із автоматизації.

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

Таким чином, базовий набір функцій SCADA-систем зумовлений роллю цього програмного забезпечення в системах управління (HMI) та реалізований практично у всіх пакетах. Це:

· Збір інформації з пристроїв нижнього рівня (датчиків, контролерів);

· прийом та передача команд оператора/диспетчера на контролери та виконавчі пристрої (дистанційне керування об'єктами);

· Мережева взаємодія з інформаційною системою підприємства (з вищими службами);

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

· оповіщення експлуатаційного персоналу про аварійні ситуації та події, пов'язані з контрольованим технологічним процесом та функціонуванням програмно-апаратних засобів АСУ ТП з реєстрацією дій персоналу в аварійних ситуаціях.

· Зберігання отриманої інформації в архівах;

· Подання поточних і накопичених (архівних) даних у вигляді графіків (тренди);

· Вторинна обробка інформації;

· Формування зведень та інших звітних документів за створеними на етапі проектування шаблонів.

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

· він має бути інтуїтивно зрозумілий та зручний для оператора/диспетчера;

· Поодинока помилка оператора не повинна викликати видачу помилкової команди управління на об'єкт.

Диспетчерське управління та збирання даних (SCADA Supervisory Control And Data Acquisition) є основним і в даний час залишається найбільш перспективним методом автоматизованого управління складними динамічними системами (процесами) у життєво важливих та критичних з точки зору безпеки та надійності областях. Саме на принципах диспетчерського управління будуються великі автоматизовані системи в промисловості та енергетиці, на транспорті, у космічній та військовій областях, у різних державних структурах.

За останні 10-15 років за кордоном різко зріс інтерес до проблем побудови високоефективних та високонадійних систем диспетчерського управління та збору даних. З одного боку, це пов'язано зі значним прогресом у галузі обчислювальної техніки, програмного забезпечення та телекомунікацій, що збільшує можливості та розширює сферу застосування автоматизованих систем. З іншого боку, розвиток інформаційних технологій, підвищення ступеня автоматизації та перерозподіл функцій між людиною та апаратурою загострило проблему взаємодії людини-оператора із системою управління. Розслідування та аналіз більшості аварій та пригод в авіації, наземному та водному транспорті, промисловості та енергетиці, частина з яких призвела до катастрофічних наслідків, показали, що якщо у 60-х роках помилка людини була початковою причиною лише 20% інцидентів (80%, відповідно, за технологічними несправностями та відмовими), то в 90-х роках частка людського фактора зросла до 80%, причому, у зв'язку з постійним удосконаленням технологій та підвищенням надійності електронного обладнання та машин, частка ця може зрости.

Основною причиною таких тенденцій є старий традиційний підхід до побудови складних автоматизованих систем управління, який застосовується часто й у час: орієнтація насамперед застосування нових технічних (технологічних) досягнень, прагнення підвищити рівень автоматизації і функціональні можливостісистеми та, водночас, недооцінка необхідності побудови ефективного людино-машинного інтерфейсу (HMI Human-Machine Interface), тобто. інтерфейсу, орієнтованого користувача (оператора). Невипадково саме останні 15 років, тобто. період появи потужних, компактних та недорогих обчислювальних засобів, припав пік досліджень у США з проблем людського фактора в системах управління, у тому числі щодо оптимізації архітектури та HMI-інтерфейсу систем диспетчерського управління та збору даних.

Вивчення матеріалів із проблем побудови ефективних і надійних систем диспетчерського управління показало необхідність застосування нового підходу розробки таких систем: human-centered design (чи top-down, зверху-вниз), тобто. орієнтація в першу чергу на людину-оператора (диспетчера) та її завдання, замість традиційного та повсюдно застосовуваного hardware-centered (або bottom-up, знизу-вгору), в якому при побудові системи основна увага приділялася вибору та розробки технічних засобів (обладнання та програмного забезпечення). Застосування нового підходу в реальних космічних та авіаційних розробках та порівняльні випробування систем у Національному управлінні з аеронавтики та дослідження космічного простору (NASA), США, підтвердили його ефективність, дозволивши збільшити продуктивність операторів, на порядок зменшити процедурні помилки та звести до нуля критичні (некоректуємо помилки операторів.

Визначення та загальна структура SCADA

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

Прообразом сучасних систем SCADA ранніх стадіях розвитку автоматизованих систем управління були системи телеметрії і сигналізації.

Всі сучасні SCADA-системи включають три основні структурні компоненти:

Remote Terminal Unit (RTU)віддалений термінал, здійснює обробку завдання (управління) як реального часу. Спектр його втілень широкий від примітивних датчиків, що здійснюють знімання інформації з об'єкта, до спеціалізованих багатопроцесорних відмовостійких обчислювальних комплексів, що здійснюють обробку інформації та управління в режимі жорсткого реального часу. Конкретна її реалізація визначається конкретним застосуванням. Використання пристроїв низькорівневого оброблення інформації дозволяє знизити вимоги до пропускної спроможності каналів зв'язку з центральним диспетчерським пунктом.

Master Terminal Unit (MTU), Master Station (MS)диспетчерський пункт керування (головний термінал); здійснює обробку даних та управління високого рівня, як правило, у режимі м'якого (квазі-) реального часу; одна з основних функцій забезпечення інтерфейсу між людиною-оператором та системою (HMI, MMI). Залежно від конкретної системи MTU може бути реалізований у найрізноманітнішому вигляді від одиночного комп'ютера з додатковими пристроями підключення до каналів зв'язку до великих обчислювальних систем (мейнфреймів) та/або об'єднаних в локальну мережуробочих станцій та серверів. Як правило, і при побудові MTU використовуються різні методи підвищення надійності та безпеки роботи системи.

Communication System (CS)комунікаційна система (канали зв'язку), необхідна передачі даних з віддалених точок (об'єктів, терміналів) на центральний інтерфейс оператора-диспетчера і передачі сигналів управління на RTU (або віддалений об'єкт залежно від конкретного виконання системи).

Функціональна структура SCADA

Існує два типи керування віддаленими об'єктами в SCADA:

автоматичне,
ініційований оператором системи.

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

людина-оператор,
комп'ютер взаємодії з людиною,
комп'ютер взаємодії із завданням (об'єктом),
Завдання (об'єкт управління).

Функції людини-операторау системі диспетчерського управління, як набір вкладених циклів, у яких оператор:

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

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

Особливості SCADA як процесу управління

Особливості процесу управління у сучасних диспетчерських системах:

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

Основні вимоги до диспетчерських систем управління

До SCADA-систем пред'являються такі основні вимоги:

надійність системи (технологічна та функціональна);
безпека керування;
точність обробки та подання даних;
простота розширення системи.

Вимоги безпеки та надійності управління у SCADA включають такі:

ніяка одинична відмова обладнання не повинна викликати видачу помилкового вихідного впливу (команди) на об'єкт управління;
жодна поодинока помилка оператора має викликати видачу помилкового вихідного впливу (команди) на об'єкт управління;
всі операції з управління повинні бути інтуїтивно-зрозумілими та зручними для оператора (диспетчера).

Області застосування SCADA-систем

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

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

В даний час у розвинених зарубіжних країнах спостерігається справжнє піднесення з впровадження нових та модернізації існуючих автоматизованих систем управління у різних галузях економіки; у переважній більшості випадків ці системи будуються за принципом диспетчерського управління та збору даних. Характерно, що в індустріальній сфері (в обробній та добувній промисловості, енергетиці та ін) найбільш часто згадуються саме модернізація існуючих виробництв SCADA-системами нового покоління. Ефект від застосування нової системиуправління обчислюється, залежно від типу підприємства, від сотень тисяч мільйонів доларів на рік; наприклад, для однієї середньої теплової станції він становить, за підрахунками фахівців, від 200 000 до 400 000 доларів. Велика увага приділяється модернізації виробництв, що становлять екологічну небезпеку для довкілля(хімічні та ядерні підприємства), а також відіграють ключову роль у життєзабезпеченні населених пунктів (водопровід, каналізація тощо). З початку 90-х років у США розпочалися інтенсивні дослідження та розробки у галузі створення автоматизованих систем управління наземним (автомобільним) транспортом ATMS (Advanced Traffic Management System).

Тенденції розвитку технічних засобів диспетчерського управління

Загальні тенденції

Прогрес у галузі інформаційних технологій зумовив розвиток усіх трьох основних структурних компонентів систем диспетчерського управління та збору даних RTU, MTU, CS, що дозволило значно збільшити їх можливості; так, число контрольованих віддалених точок у сучасній SCADA-системі може досягати 100 000.
Основна тенденція розвитку технічних засобів (апаратного та програмного забезпечення) SCADA міграція у бік повністю відкритих систем. Відкрита архітектура дозволяє незалежно вибирати різноманітні компоненти системи від різних виробників; в результаті розширення функціональних можливостей, полегшення обслуговування та зниження вартості SCADA-систем.

Віддалені термінали (RTU)

Головна тенденція розвитку віддалених терміналів – збільшення швидкості обробки та підвищення їх інтелектуальних можливостей. Сучасні термінали будуються на основі мікропроцесорної техніки, працюють під управлінням операційних систем реального часу, при необхідності об'єднуються в мережу, безпосередньо або через мережу взаємодіють із інтелектуальними електронними датчиками об'єкта управління та комп'ютерами верхнього рівня.
Конкретна реалізація RTU залежить від сфери застосування. Це може бути спеціалізовані (бортові) комп'ютери, зокрема мультипроцесорні системи, звичайні мікрокомп'ютери чи персональні ЕОМ (РС); Для індустріальних і транспортних систем існує два конкуруючі напрями в техніці RTU індустріальні (промислові) PC та програмовані логічні контролери (у російському перекладі часто зустрічається термін промислові контролери) PLC.

Індустріальні комп'ютериявляють собою, як правило, програмно сумісні зі звичайними комерційними РС машини, але адаптовані для жорстких умов експлуатації буквально для встановлення на виробництві, цехах, газокомпресорних станціях і т.д. Адаптація відноситься не тільки до конструктивному виконанню, але і до архітектури та схемотехніки, оскільки зміни температури навколишнього середовища призводять до дрейфу електричних параметрів. Як пристрої поєднання з об'єктом управління дані системи комплектуються додатковими платами(Адаптерами) розширення, яких на ринку існує велика різноманітність від різних виробників (як, втім, і самих постачальників промислових РС). В якості операційної системи в промислових PC, що працюють у ролі віддалених терміналів, все частіше починає застосовуватися Windows NT, у тому числі різні розширення реального часу, спеціально розроблені для цієї операційної системи (докладніше див. нижче).

Промислові контролери (PLC)є спеціалізовані обчислювальні пристрої, призначені для управління процесами (об'єктами) в реальному часі. Промислові контролери мають обчислювальне ядро і модулі введення-виводу, що приймають інформацію (сигнали) з датчиків, перемикачів, перетворювачів, інших пристроїв і контролерів, і здійснюють управління процесом або об'єктом видачею сигналів керуючих на приводи, клапани, перемикачі та інші виконавчі пристрої. Сучасні PLC часто поєднуються в мережу (RS-485, Ethernet, різні типи індустріальних шин), а програмні засоби, що розробляються для них, дозволяють у зручній для оператора формі програмувати та керувати ними через комп'ютер, що знаходиться на верхньому рівні SCADA-системи диспетчерському пункті управління (MTU). Дослідження ринку PLC показало, що найбільш розвиненою архітектурою, програмним забезпеченням та функціональними можливостями мають контролери фірм Siemens, Fanuc Automation (General Electric), Allen-Bradley (Rockwell), Mitsubishi. Цікавим є також продукція фірми CONTROL MICROSYSTEMS промислові контролери для систем моніторингу та управління нафто- та газопромислами, трубопроводами, електричними підстанціями, міським водопостачанням, очищенням стічних вод, контролю забруднення навколишнього середовища.

Багато матеріалів та досліджень з промислової автоматизації присвячено конкуренції двох напрямків PC та PLC; кожен із авторів наводить велику кількість доводів за і проти кожного напряму. Тим не менш, можна виділити основну тенденцію: там, де потрібна підвищена надійність та керування в жорсткому реальному часі, застосовуються PLC. Насамперед це стосується застосування у системах життєзабезпечення (наприклад, водопостачання, електропостачання), транспортних системах, енергетичних та промислових підприємствах, що становлять підвищену екологічну небезпеку. Прикладами можуть бути застосування PLC сімейства Simatic (Siemens) в управлінні електроживленням монорейкової дороги в Німеччині або застосування контролерів компанії Allen-Bradley (Rockwell) для модернізації застарілої диспетчерської системи аварійної вентиляції та кондиціювання на плутонієвому заводі 4 в Лос-Аламосі. Апаратні засоби PLC дозволяють ефективно будувати системи відмови від стійкості для критичних додатків на основі багаторазового резервування. Індустріальні РС застосовуються переважно в менш критичних областях (наприклад, в автомобільній промисловості, модернізація виробництва фірмою General Motors), хоча зустрічаються приклади і відповідальніших застосувань (метро у Варшаві управління рухом поїздів). За оцінками експертів, побудова систем з урахуванням PLC, зазвичай, є менш дорогим варіантом проти індустріальними комп'ютерами.

Канали зв'язку (CS)

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

Тенденцією розвитку CS як структурного компонента SCADA-систем можна вважати використання не тільки великої різноманітності виділених каналів зв'язку (ISDN, ATM та ін.), але також і корпоративних комп'ютерних мережта спеціалізованих індустріальних шин.

У сучасних промислових, енергетичних та транспортних системах велику популярність завоювали індустріальні шини спеціалізовані швидкодіючі канали зв'язку, що дозволяють ефективно вирішувати задачу надійності та завадостійкості з'єднань на різних ієрархічних рівнях автоматизації. Існує три основні категорії індустріальних шин, що характеризують їх призначення (місце в системі) і складність інформації, що передається: Sensor, Device, Field. Багато індустріальних шин охоплюють дві або навіть всі три категорії.

З усього різноманіття індустріальних шин, що застосовуються по всьому світу (тільки по Німеччині їх встановлено в різних системах близько 70 типів), слід виділити промисловий варіант Ethernet і PROFIBUS, найбільш популярні в даний час і, мабуть, найбільш перспективні. Застосування спеціалізованих протоколів у промисловому Ethernet дозволяє уникнути властивого цій шині недетермінізму (через метод доступу абонентів CSMA/CD), і водночас використовувати його переваги як відкритого інтерфейсу. Шина PROFIBUS в даний час є однією з найбільш перспективних для застосування у промислових та транспортних системах керування; вона забезпечує високошвидкісну (до 12 Мбод) завадостійку передачу даних (кодова відстань = 4) на відстань до 90 км. На основі цієї шини побудовано, наприклад, систему автоматизованого управління рухом поїздів у варшавському метро.

Диспетчерські пункти керування (MTU)

Головною тенденцією розвитку MTU (диспетчерських пунктів управління) є перехід більшості розробників SCADA-систем на архітектуру клієнт-сервер, що складається з 4-х функціональних компонентів.

1. User (Operator) Interface(Інтерфейс користувача/оператора) виключно важлива складова систем SCADA. Для неї характерні: а) стандартизація інтерфейсу користувача навколо декількох платформ; б) дедалі більшого впливу Windows NT; в) використання стандартного графічного інтерфейсу користувача (GUI); г) технології об'єктно-орієнтованого програмування: DDE, OLE, Active X, OPC (OLE for Process Control), DCOM; д) стандартні засоби розробки додатків, найбільш популярні серед яких, Visual Basicдля Applications (VBA), Visual C++; е) поява комерційних варіантів програмного забезпечення класу SCADA/MMI для широкого спектра завдань. Об'єктна незалежність дозволяє інтерфейсу користувача представляти віртуальні об'єкти, створені іншими системами. Результат розширення можливостей оптимізації HMI-інтерфейсу.

2. Data Management(управління даними) відхід від вузькоспеціалізованих баз даних у бік підтримки більшості корпоративних реляційних баз даних ( Microsoft SQL, Oracle). Функції управління даними та генерації звітів здійснюються стандартними засобами SQL, 4GL; ця незалежність даних ізолює функції доступу та управління даними від цільових завдань SCADA, що дозволяє легко розробляти додаткові програмиз аналізу та управління даними.

3. Networking & Services(мережі та служби) перехід до використання стандартних мережевих технологій та протоколів. Служби мережного керування, захисту та керування доступом, моніторингу транзакцій, передачі поштових повідомлень, сканування доступних ресурсів (процесів) можуть виконуватись незалежно від коду цільової програми SCADA, розроблена іншим вендором.

4. Real-Time Services(Служби реального часу) Звільнення MTU від навантаження перерахованих вище компонентів дає можливість сконцентруватися на вимогах продуктивності для завдань реального та квазі-реального часу. Дані служби є швидкодіючими процесорами, які управляють обміном інформацією з RTU і SCADA-процесами, здійснюють управління резидентною частиною бази даних, оповіщення про події, виконують дії з управління системою, передачу інформації про події на інтерфейс користувача (оператора).

Операційні системи

Незважаючи на суперечки серед фахівців з систем управління на тему що краще UNIX або Windows NT? , ринок однозначно зробив вибір на користь останньої. Вирішальними для швидкого зростання популярності Windows NT стала її відкрита архітектура та ефективні засобирозробки додатків, що дозволило численним фірмам-розробникам створювати програмні продукти на вирішення широкого спектра завдань.

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

Рішення фірми VenturCom стали стандартом де-факто створення відповідальних додатків жорсткого реального часу на платформі Windows NT. При розробці інтерфейсу для додатків реального часу розробники фірми пішли шляхом модифікації модуля Windows NT шару апаратних абстракцій (HAL Hardware Abstraction Layer), що відповідає за вироблення високопріоритетних системних переривань, що заважають задачі здійснювати управління в жорсткому реальному часі. Програмний продукт Component Integrator компанії VenturCom є засобом прискореної розробки та впровадження програм реального часу для Windows NT; він поставляється у вигляді інтегрованого пакета, що складається з інструментів для створення вбудованих додатків (ECK Embedded Component Kit) і власне розширень реального часу (RTX 4.1), що дозволяють програмам, створюваним для роботи під Windows NT, працювати в режимі реального часу.

Компанія RadiSys застосувала інший підхід до розробки розширень реального часу: Windows NT завантажується як низькопріоритетне завдання під добре перевіреною і відомою ось уже років 20 операційною системою реального часу iRMX. Усі функції обробки та управління реального часу виконуються як високопріоритетні завдання під iRMX, ізольовані у пам'яті від програм та драйверів Windows NT механізмом захисту процесора. Даний підхід має ту перевагу в порівнянні з рішенням VenturCom, що завдання реального часу не залежить від роботи Windows NT: у разі збою чи катастрофічної системної помилкиу роботі Windows NT керуюча задача реального часу продовжуватиме працювати. Це рішення дозволяє інформувати основне завдання про проблеми, що виникли в роботі NT, і залишати лише за нею право продовження роботи або зупинення всієї системи.

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

Прикладне програмне забезпечення

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

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

Апаратно-програмний комплекс диспетчерського контролю (АПК-ДК) є останньою реалізацією функції диспетчерського контролю на сучасному технічному рівні.

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

Таким чином, система АПК-ДК має подвійне призначення та забезпечує:

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

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

Стан перегінних пристроїв систем ЖАТ контролюють автомати контролю сигнальних точок (АКСТ), виконані з урахуванням спеціалізованих контролерів. Найбільше поширення має блок АКСТ-СЧМ, що представляє собою генератор частоти, що формує циклічні восьми імпульсні частотні посилки, що посилаються в лінію зв'язку у відповідності зі станом контрольованих об'єктів. При восьми вихідних імпульсах завдяки маніпуляції за тривалістю імпульсів та пауз (інтервалів) АКСТ-ЧМ дозволяє контролювати стан семи дискретних датчиків (реле) та двох порогових датчиків.

Малюнок 3.1 – Структурна схема системи АПК ДК

Під час проектування АПК-ДК визначається перелік параметрів, контрольованих кожним АКСТ-СЧМ.

Для автоблокування параметри вибирають з наступного переліку: відсутність основного живлення на сигнальній точці; відсутність резервного харчування; перегорання основної нитки лампи червоного вогню; перегорання резервної нитки лампи червоного вогню; перегорання нитки лампи вогню, що дозволяє; встановлений напрямок руху; сход ізолюючого стику; пропадання постійної напруги блоку БС-ТАК; зайнятість блоку ділянки; несправність АКСТ-СЧМ або лінії ДСМ; зникнення обох фідерів живлення на об'єктах з акумуляторним резервом; аварійна відмова.

При проектуванні для кожного АКСТ-ЧМ встановлюється частота, що несе (частота налаштування генератора), оскільки всі АКСТ перегону працюють по загальній фізичній лінії з частотним поділом каналів.

На одному фізичному ланцюзі може працювати до 30 АКСТ-ЧМ з наступним поділом частот.

На станціях (лінійних пунктах) приймається та аналізується інформація від АКСТ-СЧМ відповідними концентраторами (промисловий комп'ютер). Структурно система складається з пристрою знімання даних та віддаленого від нього на відстань близько 1 км робочого місця маневрового диспетчера. Зв'язок здійснюється по чотирипровідній лінії.

Як пристрій знімання даних використовується MicroPC, що містить:

1) процесорну плату 5025;
2) дві плати дискретного введення-виведення 5600;
3) чотири OPTO RAС, які спеціально підключені до дискретних датчиків.

Слід зазначити, що для контролю над роботою лише однієї половини сортувальної станції, що включає три парки (парк прийому, сортувальний парк і парк відправлення), необхідно контролювати близько півтори тисячі об'єктів. Якщо помножити це число вартість одного модуля оптронної розв'язки фірми Crayhill, то отримаємо цифру близько 15000 доларів США. Цифра для розробників на сьогодні, на жаль, не мала. Тому розробниками було прийнято рішення за допомогою стандартних модулів УСО організувати вхідну матрицю. Ціна відразу впала на порядок, обійшлися 96 модулями I/O типу G4IDC5. Довелося розробити і виготовити саму матрицю, проте витрати на це виявилися незрівнянно меншими, ніж якби завдання було вирішено "в лоб". Оптронна матриця являє собою модульну структуру, кожен з модулів якої дозволяє підключати 16 дискретних сигналів постійного або змінного струму напругою від 12 до 30 В. . Робоче місце маневрового диспетчера реалізовано на ПЕОМ типу IBM AT з багатотермінальною відеоплатою, що підтримує роботу чотирьох моніторів. Після визначення апаратних засобів у розробників постало питання про вибір операційної системи (ОС), під керівництвом якої функціонуватиме система ДК. Виходячи з вимог до функцій системи ДК можна дійти висновку, що ця ОС повинна

мати, як мінімум, наступні можливості:

- Підтримка багатозадачності;
- Розрахований на багато користувачів режим;
- масштабованість;
- висока продуктивність;
- робота у режимі реального часу;
- надійна та максимально швидка передача великих обсягів даних по низькошвидкісному та не дуже якісному каналу зв'язку;
- Простота підключення різних апаратних пристроїв;
- робота на обмежених системних ресурсах;
- надійна файлова система;
- Можливість віддаленої зміни версій програм;
- Можливість інтеграції з іншими системами.

Всі перераховані вище властивості мають ОС QNX, що і

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

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

Дуже потужним є реалізований QNX механізм обміну повідомленнями, з урахуванням якого система ДК була реалізована технології клієнт - сервер, що підвищує надійність роботи і що дозволяє з незначними витратами збільшувати як кількість пристроїв знімання даних, і споживачів інформації. Підтримка розрахованого на багато користувачів режиму потрібна у зв'язку з тим, що в системі одночасно можуть працювати кілька користувачів. Підключення додаткових робочих місць користувачів планується на базі локальної мережі, одним з вузлів якої буде робоче місце маневрового диспетчера. Підтримка в QNX декількох мережевих стандартів дає можливість для вибору: Ethernet, Arcnet, Token Ring і т.д.

Вимога високої продуктивності та роботи в режимі реального часу стає зрозумілою, якщо взяти до уваги кількість контрольованих датчиків та задану частоту знімання їх показань – не менше 5 разів на секунду. Причому зміни станів кількох десятків датчиків відбуваються практично при кожному опитуванні. Проблему надійної передачі даних каналу зв'язку розробникам вдалося вирішити за допомогою об'єднання в мережу QNX пристрої знімання та робочого місця диспетчера, що дозволило використовувати системний мережевий протокол і реалізувати цей обмін незалежним від середовища передачі даних для прикладних програм. Мережа по послідовному каналу досить стійко працює при швидкості передачі в 4800 бод. Для збільшення пропускної здатності мережі ми використовували реалізований мережним драйвером механізм стиснення/розтискання даних, який є прозорим для прикладних програм.

Не обійшлося і без певних складнощів. ОС QNX гарантує, якщо при передачі повідомлення якесь завдання виявиться заблокованою, то система через деякий час автоматично зніме блокування, повернувши код помилки. На жаль, цей механізм не завжди спрацьовує. Завдання може зависнути в такому стані на невизначено довгий час. Розробникам довелося відстежувати та виправляти цю ситуацію програмним способом. На їхню думку, можливо, це пояснюється наявністю помилки в мережному драйвері Net.fd версії 4.22 і при переході на версію 4.23 вдасться її позбутися. Бажання створити систему, яка не прив'язана жорстко до конкретних апаратних засобів, призводить до необхідності написання драйверів пристроїв. Той, хто писав і налагоджував драйвери пристроїв під DOS, знає – особлива незручність завдає те, що інтерфейс ОС для драйверів та прикладних програм різний. Що стосується QNX, то написання та налагодження драйверів нічим не відрізняється від написання та налагодження інших програм. Програмний інтерфейс загальний всім програм. Досить швидко були написані драйвери для плати Octagon 5600 та багатоекранної відеокарти. Так як до складу QNX входить велика кількість менеджерів пристроїв і різних драйверів, то в багатьох випадках можна просто скористатися сервісом, а не розробляти власне програмне забезпечення. Для підключення модему та організації мережі між пристроєм знімання та робочим місцем диспетчера використовувався стандартний менеджер послідовних каналів.

Внаслідок того, що QNX має невеликий розмір та модульну структуру, стало можливим встановити цю ОС на Micro PC. Ядро ОС, модуль мережі підтримки, менеджер вбудованої файлової системиі прикладні програмивдалося розмістити всього в 256Кб флеш-пам'яті та 100Кб статичного ОЗУ. При роботі потрібно трохи більше 1Мб оперативної пам'яті. Інсталяція програмного забезпечення на Micro PC здійснювалася за допомогою зручного засобу EKit - пакета для встановлення QNX у системи, що вбудовуються. Можливість віддаленої зміни версій програм у нашому випадку вкрай необхідна, оскільки Micro PC у робочому режимі немає ні екрана, ні клавіатури, ні дисковода. Прозорий доступ до файлів у мережі QNX значно полегшує роботу, а менеджер вбудованої файлової системи Efsys дозволяє перепрограмувати флеш-пам'ять та статичну ОЗУ за допомогою звичайної команди копіювання файлів. Після перезапису є можливість програмного перезавантаження віддаленого комп'ютераіз оновленою версією. З організацією програмного перезапуску у розробників виникли проблеми. Спроба його здійснення практично завжди призводила до того, що машина, що перезапускається, зависала намертво. Це утруднення вдалося обійти встановивши параметр скасування "гарячої" перезавантаження під час генерації образу ОС. Однією з основних завдань, поставлених перед проектувальниками системи ДК, було завдання передбачити можливість її інтеграції з наявними. програмними розробками. Як одну з таких розробок можна навести систему ведення графіка виконаного руху, реалізовану іншими розробниками в середовищі Windows NT. Враховуючи негативний досвід, отриманий під час реалізації власних протоколів під DOS, було прийнято рішення застосовувати для стикування виключно стандартні протоколи. Де-факто такими стандартними протоколами є сімейство протоколів TCP/IP, що стало ще одним вагомим аргументом на користь системи, що забезпечує їх підтримку. Пакет TCP/IP для QNX надає розробнику не лише можливість програмувати на рівні Socket API, але й використовувати переваги мережевої файлової системи (NFS), викликів віддалених процедур (RPC) у стандарті ONC, багатьох корисних служб, наприклад telnet і ftp. Система ДК, реалізована на базі передових апаратних та програмних технологій, сприяє отриманню диспетчером достовірної інформації та значно полегшує управління оперативною роботою станції. Ведення протоколу роботи дозволяє виявити "вузькі місця" і уникнути непотрібних матеріальних витрат. У перспективі постає завдання автоматичного формування численних документів, які досі заповнюються вручну.

технологічними процесами

У типовій архітектурі SCADA-системи явно проглядаються два рівні:

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

рівень оперативного управління технологічним процесом, основними компонентами якого є сервери, робочі станції операторів/диспетчерів, спеціалістів АРМ.

Розрізняють базовеі прикладнепрограмне забезпечення (рис.1).

Рис. 1. Класифікація програмних засобів управління.

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

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

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

Вибір операційної системи залежить від жорсткості вимог реального часу. Для завдань, критичних до реакції системи управління, нині застосовуються такі операційні системи реального часу, як OS-9,QNX, VxWorksУ системах із менш жорсткими вимогами до реального часу можливе застосування версій Windows NT/CE, точніше їх розширення реального часу.

OS-9відноситься до класу Unix-подібних операційних систем реального часу і пропонує багато звичних елементів середовища Unix. Усі функціональні компоненти OS-9, включаючи ядро, ієрархічні файлові менеджери, систему вводу/виводу та засоби розробки, реалізовані у вигляді незалежних модулів. Комбінуючи ці модулі, розробник може створювати системи з різною конфігурацією - від мініатюрних автономних ядер, орієнтованих на ПЗУ контролерів, до повномасштабних розрахованих на багато користувачів систем розробки.

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

Операційна система QNXрозроблення канадської фірми QNX Software Systems Ltd. є одним із найбільш широко використовуваних систем реального часу. QNX гарантує час реакції в межах від кількох десятків мікросекунд до кількох мілісекунд (залежно від швидкодії ПЕОМ та версії QNX). Крім того, висока ефективність QNX у задачах управління в реальному часі забезпечується такими властивостями, як багатозадачність (до 250 задач на одному вузлі), вбудовані в ядро системи мережеві можливості, гнучке управління перериваннями та пріоритетами, можливість виконання завдань у захищеному та фоновому режимах.

Операційна система QNX знайшла застосування як у нижньому рівні АСУТП (ОС для контролерів), і верхньому рівні (ОС для програмного забезпечення SCADA).

Операційна система реального часу VxWorksпризначена для розробки програмного забезпечення вбудованих комп'ютерів, що працюють в системах «жорсткого» реального часу. До операційної системи VxWorks додається інструментальне середовище Tornado фірми Wind River Systems із засобами розробки прикладного програмного забезпечення. Його розробка ведеться на інструментальному комп'ютері серед Tornado для подальшого виконання на цільовому комп'ютері (контролері) під управлінням VxWorks.

ОС VxWorks підтримує цілий рядкомп'ютерних платформ, включаючи Intel 386/486/Pentium, PowerPC, DEC Alpha. До платформ, що підтримуються інструментальним середовищем Tornado, відносяться Sun (Solaris), HP 9000/400,700, DEC Alpha, PC (Windows 95 та NT) та інші.

Операційна система Windowsзнайома всім як настільна система. Але це, перш за все, стосується платформ Windows 3.хх/95, в яких дійсно відсутня підтримка реального часу. Ситуація різко змінилася з появою Windows NT. Сама по собі Windows NT не є операційною системою реального часу через ряд її особливостей. Система підтримує апаратні (а не програмні) переривання, відсутня пріоритетна обробка відкладених процедур та ін Але наприкінці ХХ століття низка фірм зробили серйозні спроби перетворити Windows NT на ОС жорсткого реального часу. І ці спроби увінчалися успіхом. Компанія VenturCom розробила модуль Real Time Extension (RTX) – підсистему реального часу (РВ) для Windows NT. Ця підсистема має свій планувальник з 128 пріоритетами переривань, який залежить від NT. Максимальний час реакції на переривання становить 20-80 мкс незалежно від завантаження процесора. Тепер при кожному перериванні від таймера пріоритет передається критичним завданням за часом. А в час, що залишився від їх роботи, можуть виконуватися «повільні» процеси: введення/виведення, робота з диском, мережею, графічним інтерфейсом тощо.

32-розрядна WindowsCEбула створена компанією Microsoft для малих комп'ютерів (калькуляторів), але в силу ряду переваг стала претендувати на роль стандартної ОС реального часу. До цих переваг відносяться:

відкритість та простота стикування з іншими ОС сімейства Windows;

час реакції близько 500 мкс;

значно менші порівняно з іншими ОС Windows вимоги до ресурсів пам'яті та можливість побудови бездискових систем.

А в 1999 році компанією Direct by Koyo Windows CE була вперше встановлена на платформу мікроPLC.

Вибір операційної системи програмно-технічних засобів верхнього рівняАСУТП визначається прикладним завданням (ОС загального користування чи ОСРВ). Але найбільшу популярність та поширення набули різні варіанти ОС Windows (Windows NT/2000). Ними оснащені програмно-технічні засоби верхнього рівня АСУТП, представлені персональними комп'ютерами (ПК) різної потужності та конфігурації – робочі станції операторів/диспетчерів та спеціалістів, сервери баз даних (БД) тощо.

Ось кілька основних аргументів на користь Windows:

Windows має дуже широке поширення у світі, зокрема й у Росії, у зв'язку з чим легко знайти фахівця, який міг супроводжувати системи з урахуванням цієї ОС;

ця ОС має безліч додатків, що забезпечують вирішення різних завдань обробки та подання інформації;

ОС Windows і Windows-програми прості в освоєнні і мають типовий інтуїтивно зрозумілий інтерфейс;

Програми, що працюють під керуванням Windows, підтримують стандарти обміну даними;

системи на базі ОС Windows прості в експлуатації та розвитку, що робить їх економічними як з погляду підтримки, так і при поетапному зростанні;

Microsoft розвиває інформаційні технології (ІТ) для Windows високими темпами, що дозволяє компаніям, які використовують цю платформу "йти в ногу з часом".

У 90-х роках стала вельми поширеною ОС реального часу QNX. Є безліч прикладів використання QNX на всіх рівнях ієрархічної структури АСУТП (від контролерів до серверів та робочих станцій). Але в останні роки активність компанії на ринку SCADA-систем значно знизилася, що призвело до зниження кількості продажів цього програмного продукту. Пояснюється це тим, що ще 1995 року компанія QNX Software Systems Ltd. оголосила про «догляд» у вбудовані системи.

З погляду розробки системи управління переважна така програмна архітектура, у якій ПЗ усіх рівнів управління реалізовано в єдиній операційній системі. У цьому випадку автоматично знімаються всі питання, пов'язані з вертикальною взаємодією різних програмних компонент системи управління. Але на практиці це не так. Досить часто в системах контролю та управління, що розробляються, нижній і верхній рівні реалізуються в різних ОС. І найбільш характерною є ситуація, коли на рівні контролера використовується ОС реального часу, а на рівні оператора/диспетчера SCADA-система функціонує під WindowsNT. Без спеціалізованих рішень щодо організації взаємодії між підсистемами тут не обійтися.

Для функціонування системи управління необхідний ще один тип ПЗ - прикладнепрограмне забезпечення(ППО).

Відомі два шляхи розробки прикладного програмного забезпечення систем керування:

створення власного прикладного програмного забезпечення з використанням коштів

традиційного програмування (стандартні мови

програмування, засоби налагодження тощо);

використання для розробки прикладного ПЗ існуючих

(Готових) інструментальних засобів.

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

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

З точки зору сфери застосування готові інструментальні засоби можна розділити на два класи:

кошти, орієнтовані розробку програм управління зовнішніми пристроями, контролерами - CASE-системи ( Computer Aided Software Engineering);

кошти, орієнтовані забезпечення інтерфейсу оператора/ диспетчера із системою управління – SCADA-системи ( Supervisory Control And Data Acquisition- Диспетчерське управління та збір даних).

Контролеру потрібно програма, відповідно до якої він взаємодіє з об'єктом. В одних випадках йдеться тільки про збір даних з об'єкта, в інших – про логічне управління (наприклад, виконання блокувань). Нарешті, одне з основних застосувань контролера - реалізація функцій безперервного керування окремими параметрами чи технологічним апаратом (процесом) загалом.

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

У 1992 році Міжнародна електротехнічна комісія (МЕК, IEC - International Electrotechnical Commission,) взяла під контроль процеси, пов'язані з розвитком цього прикладного ПЗ. Було висунуто вимоги відкритості системи, виконання яких дозволило б уніфікувати програмні засоби та спростити розробку:

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

наявність комунікаційних засобів (інтерфейсів) для взаємодії коїться з іншими компонентами системи управління;

можливість портації ядра системи на низку програмно-апаратних

платформ.

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

Назви деяких з цих пакетів наведені нижче:

RSLogix 500, RS Logix 5, RSLogix 5000 фірми Rockwell Software для програмування контролерів різних сімейств Allen-Bradley;

DirectSOFT для контролерів сімейства Direct Logic фірми Koyo;

пакети PL7і Concept - програмне забезпечення для програмування контролерів різних сімейств компанії Schneider Electric;

пакети STEP 5, STEP 7 Micro, STEP 7 для програмування контролерів сімейств S5 та S7 фірми Siemens;

пакет Toolbox для конфігурування контролерів сімейства Moscad;

пакет TelePACE для програмування контролерів серій

TeleSAFE Micro 16 та SCADAPack фірми Control Microsystems.

Стандартом МЕК 1131-3 визначено п'ять мов програмування контролерів: три графічні (LD, FBD, SFC) та дві текстові (ST, IL).

LD(Ladder Diagram) – графічна мова діаграм релейної логіки. Мова LD застосовується для опису логічних виразів різного рівня складності.

FBD(Function Block Diagram) – графічна мова функціональних блокових діаграм. Мова FBD застосовується для побудови комплексних процедур, що складаються з різних функціональних бібліотечних блоків – арифметичних, тригонометричних, регуляторів тощо).

SFC(Sequential Function Chart) – графічна мова послідовних функціональних схем. Мова SFC призначена для використання на етапі проектування ПЗ і дозволяє описати «скелет» програми - логіку її роботи на рівні послідовних кроків та умовних переходів.

ST(Structured Text) – мова структурованого тексту. Це мова високого рівня, по мнемоніці схожа на Pascal і застосовується для розробки процедур обробки даних.

IL(Instruction List) – мова інструкцій. Це мова низького рівня класу асемблера і застосовується для програмування ефективних оптимізованих процедур.

Наприкінці 90-х років з'явилися відкриті програмні продукти ISaGRAF, InControl (Wonderware), Paradym (Intellution), призначені для розробки, налагодження та виконання програм управління дискретними, так і безперервними процесами.

Нині вже можна сказати, що переважна більшість контролерів та систем керування обслуговується програмними продуктами, що реалізують стандарт МЕК 1131-3.

Широке застосування у Росії знайшов пакет ISaGRAF французької компанії CJ International.

Основні можливості пакету:

Підтримка всіх п'яти мов стандарту МЕК 1131-3 плюс реалізація мови Flow Chart як засобу для опису діаграм станів. При цьому ISaGRAF дозволяє змішувати програми та процедури, написані різними мовами, а також вставляти кодові послідовності з однієї мови в коди, написані іншою мовою.

Наявність багатофункціонального відладчика, що дозволяє під час

роботи прикладного завдання переглядати стан програмного

коду, змінних, програм та багато іншого.

Підтримка різноманітних протоколів промислових мереж.

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

Набір драйверів для роботи з контролерами фірм-виробників: PEP Modular Computers, Motorola Computer Group та ін.

Наявність додаткових інтерактивних редакторів для опису змінних, констант та конфігурацій вводу/виводу.

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

Повне документування етапів розробки.

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

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

Нижче наведено перелік найпопулярніших у Росії SCADA-пакетів.