Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Огляд автоматизованих систем збору інформації та управління
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2025
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
Розділ 2. Огляд літературних джерел
2.1. Огляд автоматизованих систем збору інформації та управління
2.1.1. Вступ в АСУ
Автоматизована система керування (АСК), Автоматизована система управління (АСУ) — автоматизована система, що ґрунтується на комплексному використанні технічних, математичних, інформаційних та організаційних засобів для управління складними технічними й економічними об'єктами. АСУ являє собою систему управління, яка орієнтована на широке й комплексне використання технічних засобів і економіко-математичних методів для розв'язування інформаційних завдань управління. І являє собою сукупність економіко-математичних методів, технічних засобів (ЕОМ, пристроїв відображення інформації, засобів зв'язку та інші) і організаційної структури, що забезпечують раціональне керування складними об'єктами і процесами.
Починаючи з 1963 року в країні створено і функціонує приблизно 2500 АСУ різного рівня і проблемної орієнтації, у тому числі 500 АСУ підприємств і організацій, 36 міністерств і відомств, 62 територіальних організацій і т. ін. (застарілі дані) [ ].
Створені за тридцятилітню історію впровадження ЕОМ у сферу управлінської діяльності численні АСУ різняться призначенням, проблемною орієнтацією, місцем застосування, автоматизованими функціями і т. ін. З метою підвищення ефективності витрат на розвиток діючих систем та проектування нових, усунення паралелізму і дублювання в проведенні наукових досліджень і проектно-конструкторських робіт, створення типових проектних рішень і типових АСУ зроблено їх класифікацію.
Призначення АСУ - для автоматизації процесів збирання та пересилання інформації про об'єкт керування, її перероблення та видавання керівних дій на об'єкт керування [ ].
Задачі АСУ - дає змогу розв'язувати задачі перспективного та оперативного планування виробництва, оперативного розподілу завантаження обладнання, оптимального розподілу обладнання та використання ресурсів і інше.
АСК належить до класу людино-машинних систем і складається з функціональної і забезпечувальної частин.
2.1.1.1. Функціональна частина АСУ
Функціональна частина включає систему моделей планово-економічних і управлінських задач, забезпечувальна частина — інформаційну і технічну бази, математичне забезпечення, економіко-організаційну базу та інше.
Інформаційна база АСУ — це розміщена на машинних носіях інформації сукупність всіх масивів даних, необхідних для автоматизації керування об'єктом або процесом.
Програмне забезпечення - спеціальне математичне забезпечення включає пакети прикладних програм, що здійснюють організацію й обробку даних з метою реалізації необхідних функцій управління в рамках певних економіко-математичних та організаційних моделей.
Технічна база — комплекс технічних засобів збору, передачі, обробки, накопичення і видачі даних, а також пристроїв, що безпосередньо впливають на об'єкти управління. Математичне (програмне) забезпечення АСК поділяється на системне і спеціальне. Перше включає операційні системи (ОС), призначені для управління роботою пристроїв обчислених машини, організації черговості виконання обчислених робіт, контролю й управління процесом обробки даних, а також для автоматизації роботи програмістів. За допомогою операційних систем здійснюється також звернення до ЕОМ з віддалених абонентських пунктів.
В загальному випадку сучасна АСУ виконує такі функції:
вимірювальну та телевимірювальну — автоматизація відбору, збору, первинної обробки та перетворення , передачі, зберігання, відображення і запису вимірюваної інформації;
обчислювальну — вчасне і з прогнозованою достовірністю оброблення інформації в усіх аспектах, що цікавлять систему управління;
слідкувальну — відстеження і формування всієї необхідної для управління зовнішньої та внутрішньої інформації;
запам'ятовувальну — забезпечення безупинного накопичення, систематизації, збереження і відновлення всієї необхідної інформації;
комунікаційну — забезпечення доставки потрібної інформації в задані пункти;
інформаційну — реалізація швидкого доступу, пошуку і видачі потрібної інформації;
регулювальну — здійснення інформаційно-керуючого впливу на об'єкт управління і його ланки при відхиленні їхніх параметрів функціонування від заданих значень;
оптимізаційну — забезпечення розрахунків оптимізації в міру зміни цілей, критеріїв та умов функціонування об'єкту управління;
прогностичну — визначення основних тенденцій, закономірностей та показників розвитку об'єкту управління;
аналізаторну — визначення основних показників техніко-економічного рівня виробництва і господарської діяльності;
документувальну — забезпечення формування всіх обліково-звітних, планово-розпорядницьких, конструкторсько-технологічних та інших форм документів.
2.1.1.2. Класифікація АСУ
Найвищою класифікаційною ознакою АСУ є предметна сфера її застосування: економіко-організаційна, технологічна і проектно-конструкторська. Згідно з цим безліч АСУ поділяється на три класи: економіко-організаційні (АСУП), управління технологічними процесами (АСУ ТП), проектно-конструкторські (САПР).
Економіко-організаційні АСУ містять міжгалузеві АСУ (автоматизована система планових розрахунків, автоматизована система фінансових розрахунків, автоматизована система державної статистики, автоматизована інформаційно-пошукова система науково-технічної інформації, автоматизована інформаційно-управляюча система Держкомітету зі стандартів і т. ін.), виробничі АСУ (галузеві автоматизовані системи управління, АСУ акціонерних товариств і концернів, автоматизовані системи управління підприємствами та організаціями (АСУП), територіально-адміністративні АСУ (територіальні АСУ областей, АСУ міського господарства, адміністративних районів, територіально-виробничих комплексів).
До складу автоматизованих систем управління виробничими процесами належать системи, які призначені для управління безперервним виробництвом, автоматизованими потоковими лініями, комплексними лініями агрегатів і верстатів, верстатами з числовим програмним управлінням (ЧПУ). Останнім часом верстати з ЧПУ об'єднуються в оброблювані модулі і разом з транспортно-нагромаджувальними системами створюють гнучкі виробничі системи (ГВС).
Системи автоматизованого проектування використовуються для проектування деталей і вузлів машин, елементної бази, виробничого і технологічного проектування.
Нагромаджений досвід упровадження і використання автоматизованих систем довів порівняно високу ефективність багатьох із них. Економічний ефект від експлуатації передових галузевих АСУ протягом 1988-1989 рр. становив 10-20 млн. крб. (застарілі дані).
Крім прямого економічного ефекту впровадження галузевих АСУ мало великий вплив на зміну характеру діяльності управлінського персоналу міністерств і відомств. У результаті автоматизації процесів інформаційного обслуговування підвищилась інформованість управлінського персоналу.
Досить ефективні інші автоматизовані системи управління (АСУП, АСУ ТП, САПР).
Розрізняють також такі типи АСК: системи організаційного (або адміністративного) керування (АСОК) і керування технологічними процесами (АСК ТП). До АСОК входять автоматизовані системи керування підприємством (АСКП), галузеві автоматизовані системи керування (ГАСК) і спеціалізовані автоматизовані системи керування функціональних органів управління господарством. До останніх належать автоматизовані системи планових розрахунків (АСПР), державної статистики (АСДС), керування матеріально-технічним постачанням (АСК МТП), керування науково-технічним процесом (АСК НТП) та інші.
2.1.2. АСУТП і диспетчерське керування
2.1.2.1. Історичний розвиток АСУТП
Безперервну в часі картину розвитку АСУТП можна розділити на три етапи, обумовлені появою якісно нових наукових ідей і технічних засобів. У ході історії міняється характер об'єктів і методів керування, засобів автоматизації й інших компонентів, що становлять зміст сучасної системи керування.
Перший етап відбиває впровадження систем автоматичного регулювання (САР). Об'єктами керування на цьому етапі є окремі параметри, установки, агрегати; рішення завдань стабілізації, програмного керування, спостереження переходить від людини до САР. У людини з'являються функції розрахунку завдання й параметри настроювання регуляторів.
Другий етап - автоматизація технологічних процесів. Об'єктом керування стає розосереджена в просторі система; за допомогою систем автоматичного керування (САУ) реалізуються усе більше складні закони керування, вирішуються завдання оптимального й адаптивного керування, проводиться ідентифікація об'єкта й станів системи. Характерною рисою цього етапу є впровадження систем телемеханіки в керування технологічними процесами. Людина усе більше віддаляється від об'єкта керування, між об'єктом і диспетчером вибудовується цілий ряд вимірювальних систем, виконавчих механізмів, засобів телемеханіки, мнемосхем й інших засобів відображення інформації.
Третій етап - автоматизовані системи керування технологічними процесами - характеризується впровадженням у керування технологічними процесами обчислювальної техніки. Спочатку - застосування мікропроцесорів, використання на окремих фазах керування обчислювальних систем; потім активний розвиток людино-машинних систем керування, інженерної психології, методів і моделей дослідження операцій й, нарешті, диспетчерське керування на основі використання автоматичних інформаційних систем збору даних і сучасних обчислювальних комплексів.
2.1.2.2. Роль диспетчерського керування в АСУТП
Від етапу до етапу мінялися й функції людини (оператора/диспетчера), покликаного забезпечити регламентне функціонування технологічного процесу. Розширюється коло завдань, розв'язуваних на рівні керування. Диспетчер, обмежений прямою необхідністю керування технологічним процесом, наповнює набір завдань якісно новими завданнями, що раніше мали допоміжний характер або були застосовані до іншого рівня керування.
Диспетчер у багаторівневій автоматизованій системі керування технологічними процесами одержує інформацію з монітора ЕОМ або з електронної системи відображення інформації й впливає на об'єкти, що перебувають від нього на значній відстані за допомогою телекомунікаційних систем, контролерів, інтелектуальних виконавчих механізмів.
Основою, необхідною умовою ефективної реалізації диспетчерського керування, що має яскраво виражений динамічний характер, стає робота з інформацією, тобто процеси збору, передачі, обробки, відображення, подання інформації.
Від диспетчера вже потрібно не тільки професійне знання технологічного процесу, основ керування їм, але й досвід роботи в інформаційних системах, уміння приймати рішення (у діалозі з ЕОМ) у позаштатних й аварійних ситуаціях і багато чого іншого. Диспетчер стає головною діючою особою в керуванні технологічним процесом.
Говорячи про диспетчерське керування, не можна не торкнутися проблеми технологічного ризику. Технологічні процеси в енергетиці, нафтогазовій й ряді інших галузей промисловості є потенційно небезпечними й при виникненні аварій приводять до людських жертв, а також до значного матеріального й екологічного збитку.
Статистика говорить, що за тридцять років число врахованих аварій подвоюється приблизно кожні десять років. В основі будь-якої аварії за винятком стихійних лих лежить помилка людини.
У результаті аналізу більшості аварій і подій на всіх видах транспорту, у промисловості й енергетику були отримані цікаві дані. В 60 - х роках помилка людини була первісною причиною аварій лише в 20% випадків, тоді як до кінця 80-х частка "людського фактора" стала наближатися до 80 %.
Одна із причин цієї тенденції - старий традиційний підхід до побудови складних систем керування, тобто орієнтація на застосування новітніх технічних і технологічних досягнень і недооцінка необхідності побудови ефективного людино - машинного інтерфейсу, орієнтованого на людину (диспетчера).
Таким чином, вимога підвищення надійності систем диспетчерського керування є однієї з передумов появи нового підходу при розробці таких систем: орієнтація на оператора/диспетчера і його завдання.
2.1.2.3. Концепція SCАDA
Концепція SCАDA (Supervisory Control And Data Acquisition - диспетчерське керування й збір даних) визначена всім ходом розвитку систем керування й результатами науково-технічного прогресу в АСУТП. Застосування SCADA-технологій дозволяє досягти високого рівня автоматизації в рішенні завдань розробки систем керування, збору, обробки, передачі, зберігання й відображення інформації.
Дружність людино-машинного інтерфейсу (HMI/MMI), надаваного SCADA - системами, повнота й наочність інформації, що представляє на екрані, доступність "важелів" керування, зручність користування підказками й довідковою системою й т.д. - підвищує ефективність взаємодії диспетчера із системою й зводить до нуля його критичні помилки при керуванні.
Слід зазначити, що концепція SCADA, основу якої становить автоматизована розробка систем керування, дозволяє вирішити ще ряд завдань, довгий час вважалися нерозв'язними: скоротити строки розробки проектів по автоматизації й прямі фінансові витрати на їхню розробку.
У цей час SCADA є основним і найбільш перспективним методом автоматизованого керування складними динамічними системами (процесами).
Керування технологічними процесами на основі систем SCADA стало здійснюватися в передових західних країнах в 80-і роки. Область застосування охоплює складні об'єкти электро- і водопостачання, хімічні, нафтохімічні й нафтопереробні виробництва, залізничний транспорт, транспорт нафти й газу й ін.
У Росії диспетчерське керування технологічними процесами опиралося, головним чином, на досвід оперативно-диспетчерського персоналу. Тому перехід до керування на основі SCADA-систем став здійснюватися трохи пізніше. До труднощів освоєння в Росії нової інформаційної технології, який є SCADA-системи, ставиться як відсутність експлуатаційного досвіду, так і недолік інформації про різні SCADA-системи. У світі налічується не один десяток компаній, що активно займаються розробкою й впровадженням SCADA-систем. Кожна SCADA-система - це "know-how" компанії й тому дані про ту або іншу систему не настільки великі.
Велике значення при впровадженні сучасних систем диспетчерського керування має рішення наступних завдань:
вибору SCADA-системи (виходячи з вимог й особливостей технологічного процесу);
кадрового супроводу.
Вибір SCADA-системи являє собою досить важке завдання, аналогічну прийняттю рішень в умовах багатокритеріальності, ускладнену неможливістю кількісної оцінки ряду критеріїв через недолік інформації.
Підготовка фахівців з розробки й експлуатації систем керування на базі програмного забезпечення SCADA здійснюється на спеціалізованих курсах різних фірм, курсах підвищення кваліфікації. У цей час у навчальні плани ряду технічних університетів почали вводитися дисципліни, пов'язані з вивченням SCADA-систем. Однак спеціальна література по SCADA-системах відсутній, є лише окремі статті й рекламні проспекти.
2.1.3. Компоненти систем контролю й керування
Багато проектів автоматизованих систем контролю й керування (СКУ) для великого спектра областей застосування дозволяють виділити узагальнену схему їхньої реалізації, представлену на рис.2.1.
EMBED Visio.Drawing.11
Рис. 2.1. Узагальнена схема системи контролю й керування
Як правило, це трирівневі системи, тому що саме на цих рівнях реалізується безпосереднє керування технологічними процесами. Специфіка кожної конкретної системи керування визначається використовуваної на кожному рівні програмно - апаратною платформою.
2.1.3.1. Рівень виникнення інформації,
Нижній рівень - рівень об'єкта - включає різні датчики для збору інформації про хід технологічного процесу, електроприводи й виконавчі механізми для реалізації регулюючих і керуючих впливів. На цьому рівні формується первинна інформація, котра поступає в систему АСУТП, а також на цей рівень адресуються керуючі впливи.
2.1.3.2. Рівень контролю та управління технологічним процесом
Датчики поставляють інформацію локальним програмувальним логічним контролерам – ПЛК (PLC - Programming Logical Controller), які можуть виконувати наступні функції:
збір й обробка інформації про параметри технологічного процесу;
керування електроприводами й іншими виконавчими механізмами;
рішення завдань автоматичного логічного керування й ін.;
передача та прийом інформації на (з) вищий рівень.
Оскільки інформація в контролерах попередньо обробляється й частково використається на місці, істотно знижуються вимоги до пропускної здатності каналів зв'язку. З цієї ж причини можна вважати цей рівень як достатньо автономний, який при відсутності зв’язку з верхнім рівнем здатний тривалий час без втрати інформації працювати автономно.
У якості локальних PLC у системах контролю й керування різними технологічними процесами в цей час застосовуються контролери як вітчизняних виробників, так і закордонних. На ринку представлені багато десятків і навіть сотні типів контролерів, здатних обробляти від декількох змінних до кількох сотень змінних.
До апаратно-програмних засобів контролерного рівня керування пред'являються тверді вимоги по надійності, часу реакції на виконавчі пристрої, датчики й т.д. Програмувальні логічні контролери повинні гарантовано відгукуватися на зовнішні події, що надходять від об'єкта, за час, певний для кожної події.
Для критичних із цього погляду об'єктів рекомендується використати контролери з операційними системами реального часу (ОСРЧ). Контролери під керуванням ОСРЧ функціонують у режимі реального часу.
На цьому рівні може здійснюватись також контроль за перебігом технологічного процесу та його елементи керування процесом. Для цього тут можуть бути широко застосовані засобами візуалізації, такі як мікроSCADA (див. рис. 2.1).
Розробка, налагодження й виконання програм керування локальними контролерами здійснюється за допомогою спеціалізованого програмного забезпечення, широко представленого на ринку.
До цього класу інструментального ПО ставляться пакети типу ISaGRAF (CJ International France), InConrol Wonderware , (Invensys Systems Inc. USA), Paradym 31 (Intellution, USA), SYSWIN 3.4 (OMRON Europe B.V., Japan) що мають відкриту архітектуру.
Основною мережевою інфраструктурою на цьому рівні є один промислових мережевих інтерфейсів типу «польова шина» - FieldBus - (PROFIBUS, CAN, INTERBUS, MODBUS, LON і т.д.).
Інформація з локальних контролерів може направлятися в мережу диспетчерського пункту безпосередньо, а також через контролери верхнього рівня (див. рис.2.1). Залежно від поставленого завдання контролери верхнього рівня (концентратори, інтелектуальні або комунікаційні контролери) реалізують різні функції. Деякі з них перераховані нижче:
збір даних з локальних контролерів;
обробка даних, включаючи масштабування, нормування, фільтрацію і т.д.;
підтримка єдиного часу в системі;
синхронізація роботи підсистем;
організація архівів по обраних параметрах;
обмін інформацією між локальними контролерами й верхнім рівнем;
робота в автономному режимі при порушеннях зв'язку з верхнім рівнем;
резервування каналів передачі даних й ін.
2.1.3.3. Рівень людино-машинних інтерфейсів та диспетчерського управління та контролю
Верхній рівень - диспетчерський пункт (ДП) - включає, насамперед, одну або кілька станцій керування, що представляють собою автоматизоване робоче місце (АРМ) диспетчера/оператора. Тут же може бути розміщений сервер бази даних, робочі місця (комп'ютери) для фахівців і т.д. Часто тут в якості робочих станцій використовуються ПЕВМ типу IBM PC різних конфігурацій. Станції керування призначені для відображення ходу технологічного процесу й оперативного керування. Ці завдання й покликані вирішувати SCADA-системи. SCADА - це спеціалізоване програмне забезпечення, орієнтоване на забезпечення інтерфейсу між диспетчером і системою керування, а також комунікацію із зовнішнім світом.
Програмне забезпечення таких систем представлено спеціалізованими продуктами, основними з яких є:
InTouch Wonderware фірми Invensys Systems Inc. (США);
TraceMode фірми AdAstraResearch Group (Росія);
iFIX фірми (Intellution) GE Fanuc International Inc.(США);
GENESIS32 фірми Iconics Inc.(США);
RSView32 Rockwell Automation (США);
WinCC фірми Siemens (Німеччина);
CitectSCADA фірми Citect Pty Ltd (Австралія);
FactoryLink фірми MASS Group, Inc. (Manufacturing Automation & Software Systems Group).
Спектр функціональних можливостей визначений самою роллю SCADA у системах керування й реалізований практично у всіх пакетах:
автоматизована розробка, що дає можливість створення ПО системи автоматизації без реального програмування;
засоби виконання прикладних програм (RunTime Server);
збір первинної інформації про контрольовані технологічні параметри від контролер них пристроїв нижнього рівня та давачів;
попередня обробка та нормування первинної інформації;
реєстрація алярмів й історичних даних;
зберігання інформації в тому числі архівної з можливістю її пост-обробки (як правило, реалізується через інтерфейси до найбільш популярних баз даних);
реєстрація подій, пов’язаних з ходом виконання технологічного процесу а також з діями обслуговуючого персоналу, відповідального за експлуатацію та обслуговування системи;
вироблення сигнальних повідомлень для експлуатаційного та обслуговуючого персоналу про виявлені аварійні події, пов’язані з контрольованим технологічним процесом і функціонуванням програмно-апаратних засобів АСУТП та реєстрація дій персоналу в аварійних ситуаціях;
графічне представлення ходу технологічного процесу а також необхідної вхідної та архівної інформації в зручній для користувача формі - візуалізація інформації у вигляді мнемосхем, графіків і т.п.;
прийом команд оператора і передача їх в адрес контролерів нижнього рівня і виконавчих механізмів;
формування всіх видів звітних документів на основі архівної інформації;
можливість роботи прикладної системи з наборами параметрів, розглянутих як "єдине ціле" ("recipe" або "установки");
обмін інформацією з автоматизованими системами управління підприємством
безпосереднє автоматичне управління технологічним процесом у відповідності з заданими алгоритмами та параметрами.
Розглядаючи узагальнену структуру систем керування, варто ввести ще одне поняття - MicroSCADA. MicroSCADA - це системи, що реалізують стандартні (базові) функції, або обмежений набір функцій, котрі властиві SCADA-системам верхнього рівня, але орієнтовані на рішення завдань автоматизації в певній галузі або на вузькій ділянці технологічного процесу. На противагу їм SCADA-системи верхнього рівня є універсальними.
2.1.3.4. Інтерфейси зв’язку та комунікаційне ПО в SCADA
Усі компоненти системи керування об'єднані між собою каналами зв'язку. Забезпечення взаємодії SCADA-систем з локальними контролерами, контролерами верхнього рівня, офісними й промисловими мережами покладено на так зване комунікаційне ПО та інтерфейси зв’язку. Це досить широкий клас апаратно-програмних засобі, вибір якого для конкретної системи керування визначається багатьма факторами, у тому числі й типом застосовуваних контролерів і використовуваної SCADA-системою. Структура цих засобі в якійсь мірі відповідає рівневій структурі сучасної системи контролю та керування (див. рис. 2.1). Засоби зв’язку та комунікаційне ПО повинні відповідати сучасній вимозі часу – гарантованість доставки даних, що реалізується у передачі даних у форматі VTQ (Value, Time, Quality - значення, час, якість), відповідно до якого кожна одиниця даних, що пересилає клієнтові інформації, супроводжується мітками часу і якості даних.
На контролерному рівні в основному застосовуються інтерфейси зв’язку, протоколи взаємодії та драйвери пристроїв, котрі відповідають загальній концепції «»польової шини» - FieldBus. В таблиці 2.1 подано найбільш розповсюджені інтерфейси зв’язку та протоколи взаємодії пристроїв контролерного рівня.
Розповсюджені протоколи та інтерфейси, розроблені в 1977-2002 р.
Таблиця 2.1.
Як видно з табл. 2.1, не дивлячись на те, що Міжнародна електрична комісія приступила до розробки єдиного стандарту промислової мережі, у ході якої планувалося сформулювати основні вимоги до промислових комунікацій, цей проект дотепер не реалізований. Як і багато років тому, створювані сьогодні АСУ ТП орієнтовані на різні стандарти, протоколи, принципи програмного керування і найчастіше навіть типи фізичних ліній зв'язку і радіоканалів. Велика кількість на ринку неузгоджених між собою стандартів в питаннях мережевої взаємодії привело до того, що організацію робіт над проектом створення АСУТП не можна назвати типовий - кожен новий проект має свою специфіку.
Подібний, до ситуації з інтерфейсами взаємодії та протоколами, ми маємо стан речей і в питаннях комунікаційних драйверів пристроїв контролерного рівня.
Оскільки сучасні SCADA-системи не можуть обмежувати вибір розробником АСУТП апаратури нижнього рівня, тому надають великий набір драйверів або серверів вводу-виводу і мають добре розвиті засоби створення власних програмних модулів або драйверів нових пристроїв нижнього рівня. Для приєднання драйверів вводу-виводу до SCADA використовуються два механізми - обмін по внутрішньому (відомому тільки фірмі розроблювачу) протоколу і стандартний DDE (Dynamic Data Exchange).
У першому випадку самі драйвери розробляються з використанням стандартних мов програмування. Питання, однак, у тім, що для розробки драйверів для деяких систем досить тільки специфікацій доступу до ядра системи, що поставляються фірмою-розроблювачем у штатному комплекті (система Trace Mode), а для інших необхідна наявність спеціальних пакетів розробки (системи FactoryLink, InTouch), або ж, узагалі, розробку драйвера потрібно замовляти у фірми-розроблювача SCADA. В загальному випадку для цього методу інтеграції пристроїв в систему характерні такі проблеми:
для кожної SCADA-системи пишеться свій драйвер для устаткування, що поставляє на ринок або розробником системи або системним інтегратором АСУТП по правилах, визначених розробником;
у загальному випадку, два пакети системи не можуть мати доступ до одного драйвера в один момент часу, оскільки кожний з них підтримує обмін саме зі своїм драйвером.
Тому дотепер DDE залишається основним механізмом, використовуваним для зв'язку з зовнішнім світом у SCADA-системах. Але він є не зовсім придатним для взаємодії з пристроям вводу-виводу в реальному масштабі часу через свої обмеження по продуктивності і надійності. Замість DDE компанія Microsoft запропонувала більш ефективний і надійний засіб передачі даних між процесами - OLE (Object Linking and Embedding - включення і вбудовування об'єктів). На базі OLE побудований новий стандарт OPC (OLE for Process Control), орієнтований на ринок промислової автоматизації.
Основна мета OPC стандарту полягає у визначенні механізму доступу до даних з будь-якого пристрою з додатків. OPC дозволяє виробникам устаткування поставляти програмні компоненти, які стандартним способом забезпечать клієнтів даними із ПЛК. При широкому поширенні OPC - стандарту з'являться наступні переваги:
OPC дозволять визначати на рівні об'єктів різні системи керування й контролю, що працюють у розподіленому гетерогенному середовищі;
OPC - усунуть необхідність використання різного нестандартного устаткування й відповідних комунікаційних програмних драйверів;
у споживача з'явиться більший вибір при розробці додатків.
Новий стандарт, по-перше, дозволяє поєднувати на рівні об'єктів різні системи керування і контролю, що функціонують у розподіленому гетерогенному середовищі; по-друге, OPC усуває необхідність використання різного нестандартного устаткування і відповідних комунікаційних програмних драйверів. Стандарт OPC підтримується практично у всіх представлених універсальних SCADA відомих фірм. З погляду SCADA-систем поява OPC-серверів означає розробку програмних стандартів обміну з технологічними пристроями. Оскільки виробники цілком розбираються у своїх пристроях, тому ці специфікації є для них керівництвом до розробки відповідних серверів. OPC інтерфейс допускає різні варіанти обміну: одержання "сирих" даних з фізичних пристроїв, з розподіленої системи керування або з будь-якого додатку. На ринку з'явилися інструментальні пакети для написання OPC-компонентів, наприклад, OPC-Toolkits фірми FactorySoft Inc., що включає OPC Server Toolkit, OPC Client Toolkit, приклади OPC-програм.
На рівні людино-машинних інтерфейсів та диспетчерського управління для ефективного функціонування різнорідному середовищі SCADA-система забезпечується високим рівнем мережного сервісу. Вона підтримує роботу в стандартних мережних середовищах (ARCNET, ETHERNET і т.д.) з використанням стандартних протоколів (NETBIOS, TCP/IP і ін.).
2.2. Промисловий контролер та структури вводу-виводу
Довільна SCADA (Supervisory Control And Data Acquisition) включає промисловий контролер, котрий є елементом сучасного інженерного рішення, на якому ми зупинемось детальніше.
На сьогоднішній день вироблено декілька типових конфігурацій промислових контролерів, для пояснення котрих використаємо інформацію системи OpenLine, OMRON [ ].
2.2.1. Структура промислового ПЛК централізованого типу
Типова конфігурація промислового контролера централізованого типу показана на рис. 2.2. По такій схемі побудовані практично всі ПЛК (програмований логічний контролер) а також IBM PC сумісні контролери. В якості пристрою зв’язку з об’єктом (УСО) в таких системах використовуються вбудовані в контролер спеціальні модулі вводу-виводу, котрі мають з одного боку інтерфейс зв’язку внутрішньою шиною контролера (це може бути ISA, VME, PCI, PC/104 або деяка спеціалізована магістраль), а з другого — декілька (зазвичай кратне восьми) каналів для підключення зовнішніх сигналів. Корпус контролера дозволяє конструктивно нарощувати кількість модулів вводу-виводу різного типу, обмеження в кількості модулів визначається типом корпусу. Не дивлячись на широке розповсюдження такого рішення, у нього є певні недоліки. Головний з них полягає у тому, що центральній процесор ПЛК змушений займатись не тільки задачами управління у відповідності з убудованою програмою і мережевою взаємодією з пристроями вищих рівнів системи збору та управління, але і процедурами вводу-виводу (див. модуль в/в на рис. 2.2).
EMBED Visio.Drawing.11
Рис. 2.2. Внутрішня структура промислового ПЛК з модулями вводу-виводу централізованого типу
Причому алгоритми роботи з різними модулями вводу-виводу можуть суттєво відрізнятись один від одного, особливо в залежності від типу модуля. Наприклад, ряд модулів може використовувати лінії переривання, в той час як інші можуть вимагати додаткового налаштування контролера прямого доступу до пам’яті (ПДП).
Але в кожному випадку для роботи такої системи необхідна наявність в ПЛК додаткових програмних компонентів — драйверів модулів вводу-виводу, специфічних для кожного типу застосованих модулів.
2.2.2. Структура системи вводу-вводу на базі ПЛК розподіленого типу
В той же час на ринку широкого застосування набули модулі віддаленого збору даних. Це дозволяє створювати розподілені системи збору даних. Треба сказати, що розвитку таких систем в великій мірі сприяли процеси уніфікації протоколів взаємодії та широке розповсюдження і розвиток інтерфейсів зв’язку типу «польова шина» (FieldBus).
На рис. 2.3 показана структура системи с використанням віддалених УСО, підключених до контролера за допомогою одного з відомих промислових мережевих інтерфейсів типу «польова шина» (PROFIBUS, CAN, INTERBUS, MODBUS, LON і т.д.). До переваг такої конфігурації відносяться масштабованість, можливість використання УСО від різних виробників, зниження завантаженості центрального контролера процедурами обслуговування каналів вводу-виводу. Оскільки процес вводу-виводу здійснюється контролером віддаленого УСО. Це відбувається завдяки тому, що, як правило, стани каналів вводу-виводу кожного з контролерів УСО відображається в єдиному вікні двохпортової пам’яті адаптера мережі, встановленого в центральному контролері. Таким чином, процесор здійснює управління каналами вводу-виводу через вікно пам’яті, користуючись так званим образом процесу.
EMBED Visio.Drawing.11
Рис. 2.3. Структура системи вводу-виводу на базі ПЛК розподіленого типу
За таким принципом побудовані практично всі класичні системи розподіленого вводу-виводу. На нашому ринку широко представлені розподілені контролери фірми MOXA Technologies Co., Ltd. [ ].
В основу системи OpenLine покладена аналогічна ідея побудови віртуального образу процесу. Однак в якості каналоутворюючого інтерфейсу був вибраний не FieldBus, а дещо видозмінена підмножина системної шини IBM PC - ISA, «рідної» магістралі процесора системи OpenLine (рис. 2.4). Здавалось би така конфігураціє є ближче до класичної централізованої структури системи вводу-виводу. Але всі відмінності починаються дещо далі. В якості абонентів цієї локальної шини виступають не модулі УСО, а мікроконтролери бази вводу-виводу. Кожен з цих контролерів має свою двохпортову пам’ять, котру він «публікує» на локальній шині OpenLine. Вміст цієї пам’яті відображає стан модулів, котрі в даний момент знаходяться в цій базі. Все проблеми взаємодії с модулями вводу-виводу бере на себе контролер бази, а процесом управління займається центральний контролер, котрий працює з вікнами двохпортової пам’яті, так само як і у випадку роботи з адаптером промислової мережі. Таке «гібридне» рішення має декілька переваг. Система стає відносно недорогою в порівнянні з класичною розподіленою системою, оскільки не містить спеціалізованого адаптера промислової мережі. В той же час OpenLine вільна від основних недоліків централізованих систем – необхідності оперувати модулями, котрі містять велику кількість каналів. В системі OpenLine можна встановити довільну кількість вхідних і вихідних каналів (загальною кількістю не більше 128), кратне двом, що дозволяє максимально зменшити надлишковість системи. Розділення функцій вводу-виводу і управління, властиве рішенням на основі Fieldbus, реалізовано в системі OpenLine не менш красиво, що суттєво спрощує процес доступу центрального процесора до каналів вводу-виводу і зводиться по-суті до його роботи з вікнами пам’яті, де розміщені образи процесів. В той же час система OpenLine має додаткову перевагу перед класичними Fieldbus рішеннями – це властивість контролерів баз вводу-виводу автоматично визначати склад і стан модулів, встановлених в базу, без необхідності ручного конфігурування як це є у більшості розподілених систем.
EMBED Visio.Drawing.11
Рис. 2.4. Модифікована структура системи вводу-виводу на базі ПЛК розподіленого типу
2.3. Відкриті технології програмування в сучасних АСУТП
Функціонування контролерів під керуванням власного локальних ПО повинно бути тісно ув'язане з ПО систем більш високого рівня. Усі сучасні програмовані логічні контролери ПЛК володіють розвитими програмними засобами. Програмування контролера має на увазі опис у пам'яті ПЛК алгоритму функціонування контрольованої і керованої технологічної системи або її частини.
Розглянемо методи технологічного програмування, котрі реалізують сучасні CASE системи [ ]. Використання засобів програмування, котрі підтримують відкриті стандарти дає очевидні переваги.
Опублікований в 1993 році Міжнародною Електротехнічною Комісією (МЕК) стандарт IEC 1131-3 [ ] визначає базу для створення програмного забезпечення керуючих систем. Призначення IEC 1131-3 — стандартизація існуючих мов ПЛК у вигляді базових специфікацій, котрі не обмежують виробників в можливості представлення максимально комфортного середовища розробки користувачам.
Стандатр IEC 1131-3 описує синтаксис та семантику 5-ти мов програмування ПЛК, котрі закріпились в якості основних за більш ніж 35-літню історію їх використання в області автоматизації промислових об’єктів.
SFC (Sequential Function Chart – діаграми функціональних послідовностей) – мова, яка представляє процес у вигляді набору процедурних кроків і логічних переходів. Логіка переходів, визначена умовою (виражається на мовах ST або LD) відображається у графічному виді. Кроки обробки описуються текстовими засобами SFC або за допомогою інших мов стандарту (мови ST, IL, LD, FBD). SFC представляє засоби опису послідовно-паралельних алгоритмів. SFC, розширена можливостями текстової мови ST, зручна для побудови алгоритмів логічного (по подіях) керування і дуже схожа на діаграми загальновідомої мови блок-схем (Flow Chart), а також проста для сприйняття.
LD (Ladder Diagram) – це графічне представлення логічних рівнянь, поєднуючих контакти (входи) и витки (виходи). Мова LD дозволяє описувати роботу з булевими даними, розміщуючи графічні символи LD в схему програми, котра дуже нагадує електричну схемпристрою на реле. Мова отримала свій розвиток в часи переходу з реле на мікро-ЕОМ, оскільки знімала у потенційного користувача психологічний бар’єр - боязнь комп’ютерів і дозволяла їм застосовувати здобутий дсвід. Із-за своєї функціональної обмеженості і зі зміною поколінь користувачів значення мови зменшується, поступаючись місцем FBD и SFC. Але з виходом на ринок простих і дешевих програмованих пристроїм, так званих програмованих реле, з можливістю їх програмування прямо на екрані вбудованого LCD дисплею засобами LD (наприклад фірми AllenBradley), її роль зростає.
FBD (Functional Block Diagram - функціональні блок-схеми) - графічна мова, в котрій процес представлено у виді функціональних блоків (котрі нагадують мікросхемо), що виконують елементарні функції обробки сигналів і управління, такі як ПІД-регулятор, лічильник, лінійний перетворювач, фільтр, суматор, нуль-орган, компаратор і т.д., з’єднаних «проводами» в функціональну схему, дуже подібну на електронну. FBD в свою чергу ідеально підходить для побудови алгоритмів цифрової і аналогової обробки сигналів, до яких зводиться більшість задач управління на рівні цехової площадки, таких як задачі регулювання и захисту. Функціональні блоки і схеми на мові FBD добре сприймаються інженерами і є звичними для них, оскільки реалізують на новому рівні старі и добре відомі їм принципи аналогового і цифрового управління, оскільки нагадують знайомі пнемо - і електронні схеми а також знімають обмеження на апаратну реалізацію. Це єдина (в її розширеному варіанті) самодостатня мова стандарту IEC 1131-3, котра забезпечує побудову довільного алгоритмe цехової автоматизації.
ST (Structured Text - структурований текст) - структурна мова високого рівня, розроблена для процесів автоматизації. Ця мова по синтаксису орієнтована на Паскаль. Загалом використовується для створення складних процедур, котрі не можуть бути легко виражені за допомогою графічних мов. По замовчуванню ST є мовою опису дії внутрішніх кроків та умов переходів мови SFC.
IL (Instruction List) – тестова мова низького рівня. Подібна до мови Ассемблер. В рамках стандарту до архітектури конкретного процесора не прив’язана. Самостійного значення не має, використовується для опису дій всередині кроків мови SFC.
Стандарт IEC 1131-3 виявився настільки потрібним, що ще до його кінцевого прийняття МЭК виробниками і користувачами ПО, орієнтованого на IEC 1131-3, вже була створено незалежна організація PLCOpen, котра взяла на себе функції підтримки стандарту на ринку. В результаті діяльності PLCOpen на ринку ПО появилась серія сертифікованых засобів програмування ПЛК. Ці засоби достатньо широко і успішно поширюються в промисловості.
Головною цілллю діяльності PLCOpen декларується забезпечення сумісності програмних продуктів для ПЛК на базі стандарту IEC 1131-3. До цього часу цією організацією сертифіковано більш ніж 10 програмних продуктів, котрівідповідають вимогам стандарту IEC 1131-3. В якості найбільш поширених IEC 1131-3-сумісних CASE-систем (САПР ПО) можна вказати системы PDS7 (Philips, Нидерланды), Step7 (Siemens, Германия), PL7, Concept (Schneider Electric), ULTRALOGIK (Prosoft, Росія), ISaGRAF (CJ International+AlterSys, Франция, Канада).
2.4. Релейно-контактні схеми в ПЛК
В підрозділі подамо опис базових дій і понять для написання основних релейно-контактних програм (Ladder Diagram - LAD), що використовується для уведення програми в контролер і її виконання. Наведено команди, які використаються для побудови базової структури релейно-контактної схеми (РКС) й керування її виконанням. Повний набір команд для контролера C200HX фірми ОMRON описаний в інструкції по програмуванню.
2.4.1. Основний алгоритм
Існує кілька основних операцій при написанні програми для ПЛК. Приведемо їх:
1. Зробіть список всіх вхідних/вихідних пристроїв і точок входів/виходів, які їм привласнені, і приготуйте таблицю, у якій показані ці присвоєння.
2. Якщо в ПЛК є модулі, яким виділені слова в областях, відмінних від ІR (внутрішні реле), або у виділених словах ІR функція кожного біта визначається типом модуля, приготуйте такі ж таблиці, у яких буде показано, які слова використаються для модулів, і яке значення біт у слові. До цих модулів ставляться спеціальні модулі входів/виходів і модулі зв'язку.
3. Визначте, які слова можна використати як робочі терміни, і приготуйте таблицю, у якій буде показаний їхній розподіл.
4. Також приготуйте таблицю номерів ТС (таймери/лічильники) і номерів переходів, щоб розподілити їх відповідності з планом використання. Не забувайте, що функцію номера ТС можна задати тільки один раз в програмі; Кожен з номерів переходів 01..99 можна використати тільки один раз. (Номер ТС описаний в п. 5-14 інструкції по програмуванню контролера).
5. Використайте інструментарій і створіть релейно-контактну схему.
6. Уведіть програму в ПЛК. При використанні программатора це зажадає перетворення програми в мнемонічну форму.
7. Перевірте програму на синтаксичні помилки й виправте їх.
8. Виконаєте програму для перевірки на помилки виконання й виправте їх.
9. Після установки всієї системи й готовності її до роботи виконаєте програму і якщо буде потреба зробіть точне налагодження.
10. Створіть резервну копію програми.
2.4.2. Термінологія команд
При релейно-контактному програмуванні використовується два базові типи команд:
команди, які відповідають умовам на РКС і використовуються у формі команд тільки для перетворення програми в мнемокод;
команди, які розташовуються з правого боку РКС і виконуються за результатами умов командних ліній, які ведуть до них.
Більшість команд мають мінімум один або більше пов'язаних з ними операнди. Операнди вказують або містять дані, з якими повинна виконуватися команда. Операнди іноді вводяться як чисельні значення, але зазвичай є адресами слів або біт з області даних, в яких зберігаються необхідні дані. Наприклад, команда MOVE, що має як операнд джерела IR000, перемістить вміст IR000 в задане місце. Дане місце теж задається як операнд. Біт, адреса якого задана як операнд, називається бітовим операндом; слово, адреса якого задана як операнд, називається умовним операндом. Якщо поточне значення введене як константа, їй передує # для вказівки того, що це не адреса.
2.4.3. Структура пам'яті програм
Максимальний обсяг програми користувача змінюється залежно від розміру UM (пам’ять користувача), виділеного для розширених DM (пам’ять даних) і зон коментарів до входів/виходів (рис. 4.1). Приблизно 10.1К слів доступні для релейно-контактної програми, коли 3К слів виділені для додаткових DM і 2К слів виділені для коментарів до входів/виходів, як показано нижче.
Рис. 2.5. Структура пам'яті програм контролера C200HX
2.4.4. Базові релейно-контактні схеми
Релейно-контактна схема складається з однієї вертикальної лінії з лівого боку з відгалуженнями, що відходять вправо. Вертикальна лінія зліва називається шиною, відгалуження - командними лініями (або сходинками). На командній лінії розташовуються умови, що ведуть до "правосторонніх" команд. Логічні комбінації цих умов визначають, коли і як виконуються "правосторонні" команди. На рисунку 4.2 приведений приклад релейно-контактної схеми.
Рис. 2.6. Приклад РКС
Як показано на діаграмі, командні лінії можуть розгалужуватися і знову з'єднуватися. Дві поряд розташовані вертикальні лінії називаються умовою. Умова без діагональної рискою називається нормально відкритою умовою і відповідає командам LOAD, AND або OR. Умова з діагональною рискою - нормально закритою умовою і відповідає командам LOADNOT, ANDNOT або ORNOT. Число над кожною умовою вказує бітовий операнд команди. Цей стан біта визначає умову виконання наступних команд. Як виконується кожна команда відповідно до умов, описано далі. Перед розглядом цього слід пояснити базові терміни.
Зауваження - При індикації релейно-контактної схеми з допомогою ПЗ з правого боку відображатиметься друга шина, і вона буде сполучена зі всіма "правосторонніми" командами. Вона не міняє релейно-контактну схему у функціональному плані. Між "правосторонніми" командами і правою шиною не можна помістити ніякі умови, тобто всі "правосторонні" команди мають бути сполучені безпосередньо з правою шиною.
2.4.4.1. Базові терміни
Нормально відкриті і нормально закриті умови
Кожна умова на РКС може перебувати в стані або 1, або 0 залежно від стану бітового операнда, пов'язаного з ним. Нормально відкрита умова = 1, якщо бітовий операнд = 1 і = 0, якщо бітовий операнд = 0.
Нормально закрита умова = 1, якщо бітовий операнд = 0 і = 0, якщо бітовий операнд = 1. Тобто, Ви використовуєте нормально відкриту умову, якщо бажаєте виконання команд, коли біт = 1, і нормально закрита умова, якщо бажаєте виконання команд, коли біт = 0 (рис. 2.7).
Рис. 2.7. Приклад виконання умов в РКС
Умови виконання
У релейно-контактному програмуванні логічна комбінація умов 1 і 0 перед командою визначає загальну умову, при якій вона виконується. Дана умова (або 0, або 1) називається умовою виконання команди. Всі команди, за винятком команди LOAD, мають умови виконання.
Бітові операнди
Операндами для будь-якої команди РКС можуть бути будь-які біти в областях IR, SR, HR, AR, LR або ТС. Це означає, що умови на релейно-контактній схемі можуть визначатися бітами входів/виходів, прапорцями, робочими бітами, таймерами, лічильниками і так далі. Команди LOAD і OUTPUT можуть також використовувати біти області TR, але тільки в спеціальних прикладних задачах.
Логічні модулі
Шляхи відповідності умов і команд визначаються співвідношенням між умовами всередині командних ліній, які їх з'єднують. Будь-яка група умов, які працюють спільно для вироблення умови виконання, називається логічним модулем. Хоча релейно-контактну схему можна скласти без аналізу окремих логічних модулів, розуміння роботи логічних модулів необхідне для ефективного програмування і в разі, коли програми повинні вводитися у вигляді мнемокоду.
2.4.4.2. Мнемокод
Релейно-контактну схему не можна безпосередньо ввести в ПЛК з програматора, потрібне відповідне ПЗ для ПЛК (інструментальний засіб для розробки РКС, відлагодження, завантаження програми та інш.). Для введення з програматора необхідно перетворити релейно-контактну схему в мнемокод. Мнемокод відображає ту ж інформацію, що і релейно-контактна схема, але у формі, яку можна ввести прямо в ПЛК. Ви можете програмувати безпосередньо в мнемокодах, але початківцям, або при складних програмах це не рекомендується. Отже, незалежно від того, чи використовується програмуючий пристрій, програма завантажується в ПК в мнемокоді. Тому важливо розуміти і мнемокод.
Через важливість програматора як периферійного пристрою і важливості мнемокоду в розумінні програми, разом з релейно-контактною схемою ми вводимо і описуємо мнемокоди. Пам'ятаємо, що при роботі з ПЗ, знання мнемокоду не потрібне.
Структура пам'яті програм
Програма вводиться по адресах пам'яті програм. Адреси в пам'яті програм дещо відрізняються від адрес в інших типів пам'яті, оскільки кожна адреса необов'язково містить однаковий об'єм даних. Точніше, кожна адреса містить одну команду і всі визначники і операнди (детально описані далі), потрібні для команди. Оскільки деякі команди не вимагають операндів, тоді як інші вимагають до трьох операндів, адреси пам'яті програм можуть бути довжиною 1..4 слова.
Адреси пам'яті програм починаються з 00000 і продовжуються до тих пір, поки не буде зайнятий весь об'єм пам'яті програм. Перше слово кожної адреси задає команду. Визначники, які використовуються командою, також містяться в першому слові. Крім того, якщо команда вимагає тільки один бітовий операнд (без визначника), бітовий операнд також програмується в тому ж рядку, що і команда. Решта слів, які потребуються командою, містять операнди, які визначають використовувані дані. При перетворенні в мнемокод тільки релейно-контактні команди записуються в такій же формі, одне слово в рядку, як вони появляються в символах РКС. Приклад мнемокодів приведений в таблиці 2.2. Команди що використовуються описані далі в інструкції.
Приклад мнемокодів
Таблиця 2.2
Стовпці адреса і команда таблиці мнемокодів заповнена лише для слів команд. Для всіх інших рядків два ліві стовпці залишаються незаповненими. Якщо команда не вимагає визначника або бітового операнда, стовпець операнд залишається пустим для першого рядка. Рекомендуємо закреслювати всі незайняті комірки стовпців (для всіх слів команд, що не вимагають даних), щоб швидко проглянути стовпець для перевірки, чи не опущена яка-небудь адреса.
При програмуванні адреси нумеруються автоматично, і немає необхідності вводити адресу, якщо тільки з якої-небудь причини немає необхідності помістити команду в якому-небудь іншому місці. При перетворенні в мнемокод краще всього починати з адреси пам'яті програм 00000, якщо немає особливих причин розміщувати програму у іншому місці.
2.4.4.3 Команди РКС
Релейно-контактні команди - такі команди, які відповідають умовам на релейно-контактній схемі. Релейно-контактні команди, або незалежно, або в комбінації з блоковими командами, описаними далі, утворюють умови виконань, в залежності від яких виконуються всі інші команди.
LOAD і LOADNOT
Першими умовами, які розпочинають будь-який логічний модуль релейно-контактної схеми, є команди LOAD і LOADNOT. Ці команди займають один рядок в мнемокоді. У наступному прикладі "Команда" може бути будь-якою "правосторонньою" командою, які описані далі в даній інструкції (рис. 2.8, табл.2.3).
Рис. 2.8. Приклад виконання команди LOAD і LOADNOT в РКС
Приклад мнемокодів команди LOAD і LOADNOT
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора