Автоматика.
    Автоматизация.
        Электротехнические
            комплексы и системы.

УДК 681.5

ОСОБЛИВОСТІ ПРОЕКТУВАННЯ КОМП’ЮТЕРНО-ІНТЕГРОВАНИХ СИСТЕМ УПРАВЛІННЯ

Пупена О.М, Ельперін І.В, Ладанюк А.П.

Актуальність. Одним із основних напрямків розвитку сучасних систем автоматизації є створення інтегрованих систем управління виробництвом, які вирішують задачу інтеграції традиційних АСУТП і АСУП з метою створення єдиного інформаційного простору підприємства для об’єктивної і оперативної оцінки стану підприємства, оперативного прийняття своєчасних і ефективних управлінських рішень, а також ліквідації інформаційних та організаційних бар’єрів між управлінським та технологічним рівнями [1]. Серед основних проблем створення інтегрованої системи управління на підприємстві є забезпечення сумісного функціонування технічного та програмного забезпечення, яке традиційно використовується в системах різного рівня. На сьогоднішній день проблему сумісності гетерогенних програмно-технічних засобів вирішують за допомогою використання відкритих технологій [2,3].

Однак функціонування системи в цілому залежить від правильної організації її побудови та ефективного використання всіх ресурсів її складових. Це накладає допоміжні вимоги при проектуванні комп’ютерно-інтегрованих систем управління (КІСУ) - правильний вибір структури управління, способу інтеграції і т. ін [4]. Таким чином виникає потреба розробити проектну документацію, яка стосується, зокрема, процесів обміну інформаційними потоками між окремими елементами інтегрованої системи управління. Особливістю цієї частини проекту системи автоматизації є те, що вона повинна включати інформаційне, програмне та технічне забезпечення обміну різною за змістом і призначенням інформацією між робочими станціями і технічними засобами, які знаходяться на різних рівнях управління. Це можуть бути: задачі обміну інформації при вирішення питань координації на рівні управління технологічними процесами, задачі корегування роботи АСУТП на базі обробки технологічної інформації на рівні організаційно-економічного керування виробництвом, задачі розрахунку техніко-економічних показників роботи виробництва з використанням оперативної технологічної інформації і т. і.

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

В залежності від ситуації процес проектування може йти по різному. Можна виділити дві типові ситуації:

-       проект для всієї системи управління розробляється "з нуля";

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

При розробці всієї системи "з нуля" ПД КІСУ є початковою для проектів АСУТП, тобто проект АСУТП розробляється з урахуванням вимог до нього з боку проекту КІСУ.

При вдосконаленні системи, додатковими вихідними даними при проектуванні КІСУ являються обмеження, пов’язані з існуючими підсистемами. Таким чином в цьому випадку ПД АСУТП є додатковим джерелом для розробки проекту КІСУ, а ПД КІСУ – завданням для вдосконалення системи автоматизації підсистеми.

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

Проектна документація КІСУ повинна показати:

-       функціонування КІСУ як розподіленої системи управління;

-       апаратну реалізацію КІСУ в контексті промислових та комп’ютерних мереж;

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

-       функціонування системи в контексті програмної взаємодії;

Виходячи з цих вимог, на наш погляд, проектна документація комп’ютерно-інтегрованої системи управління може включати:

 - системний аналіз об’єкта;

 - графове представлення схеми інформаційних потоків;

 - загальну структурну схему управління;

 - схеми з’єднань пристроїв комп’ютерних та промислових мереж;

 - схеми мережевих інформаційних потоків;

 - план розміщення мережевих комунікацій та мережевого обладнання;

Розглянемо варіант виконання цих розділів проекту на прикладі розроблення комп’ютерно-інтегрованої системи управління цукровим виробництвом, основні відділення якого автоматизовані з використанням сучасних мікропроцесорних засобів автоматизації: промислових контролерів (ПЛК); автоматизованих робочих місць (АРМ) на базі промислових або офісних ПЕОМ з встановленим відповідним програмним забезпеченням (наприклад SCADA-проограм); мікропроцесорних операторських панелей (ОП); частотних перетворювачів (ЧПР) для управління асинхронними двигунами. Для наочності в системі управління використовуються ПЛК різних виробників.

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

-         у сокоочистному відділенні - автоматичну координацію процесу фільтрації соку 1-ї сатурації та процесу дефекосатурації;

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

-         централізоване диспетчерське управління основним продуктовим потоком;

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

Графове представлення інформаційних потоків. Основою розробки є результат системного аналізу об’єкта управління, формальним представленням якого може бути схема інформаційних потоків у вигляді потокового орієнтованого графа. Вершинами графа є реалізація функцій системи (процес рішення і отримані результати), а дуги показують інформацію (аргументи функцій), яку треба передати для реалізації функції.

В графовій моделі показуються лише ті функції, які будуть використовуватись у мережевому обміні між окремими елементами і технічними засобами системи управління. Однак на початку розробки проекту бажано розглянути більш детальну графову модель інформаційних потоків, що дозволить візуально представити поставлену задачу, та допомогти в організації її вирішення. При описі функцій системи (вершин графа) і інформації, яка буде передаватись для їх реалізації (дуги графа), можуть бути наведені додаткові умови. Наприклад, для функції “управління” може бути наведена деталізація і характеристики окремих параметрів; для функцій моніторінгу за значеннями технологічних параметрів може бути наведений їх перелік з указанням діапазону вимірювання, дискретністю опитування і т.ін. Таку інформацію краще наводити у табличній формі.

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

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

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

Таблиця 1.

Специфікація.

У наведеному прикладі показано, що для того щоб забезпечити моніторинг роботи сокоочистного відділення і автоматичну координацію управління процесом фільтрації соку 1-ї сатурації вибрана промислова мережа Uni-Telway (М2). Для реалізації задач координації роботи по матеріальному потоку сокоочистного і дифузійних відділень, а також централізованого диспетчерського управління основним продуктовим потоком використовується комп’ютерна мережа Ethernet (М1), яка зв’язує АРМи різних відділень і координуючу станцію АРМ диспетчера. Передача технологічної і енергетичної інформації на рівень організаційно-економічного управління відбувається за допомогою технологічного сервера. Безумовно, можуть бути запропоновані і інші варіанти реалізації функцій системи.

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

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

-       пристрої та спосіб їх об’єднання у мережу;

-       мережеве обладнання та його настройки.

В графічній частині на схемі показуються:

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

-       спосіб підключення пристроїв до мережі: плата або модуль, рознім в платі/модулі/пристрої, клеми і т.д. з їх маркуванням; якщо рознім (або клемна колодка) у пристрою єдиний і не маркується, можна використати умовне позначення (наприклад X1 - для розніму, XT1 - для клемної колодки);

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

-       по можливості стан перемикачів, перемичок, тощо;

-       для кращої наочності назву мережі/мереж;

-       специфікація приладів та умовні скорочення.

Для наочності можна спростити та не показувати деякі деталі підключення, які потім можна вказати в текстовій частині.

Для маркування мережевих пристроїв можна використати наступні скорочення: ПК, PC – офісний або промисловий комп’ютер, який входить до складу відповідного АРМа ; ПЛК, PLC – програмований логічний контролер або PC-сумісний контролер; КП – коробка підключення, КК – комунікаційна карта, КАМ – комунікаційний адаптер мережі(перетворювачі); ОП – операторська панель; ЧПР – частотний перетворювач; ТС – сервер БД. Для маркування кабелів можна використати скорочення КМ – кабель мережі. Маркування повинно бути унікальним і єдиним для всього проекту, щоб можна було однозначно ідентифікувати обладнання або його частини в інших частинах проекту.

Рис. 3 Схема з’єднань пристроїв обчислювальних мереж 2,3.

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

Таблиця 2.

Специфікація до схеми з’єднань.

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

При маркуванні можна пунктиром виділяти АСУ відділенням (підсистема), мережеве обладнання можна маркувати як КМ1-1 (кабель мережі 1, 1), КП1-2 (коробка підключення для мережі 1, 2) і т.п.

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

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

Схема мережевих інформаційних потоків повинна:

-         дати уявлення про обмін даними в мережі;

-         слугувати інструментом для вияву конфліктних ситуацій, вирішення оптимальної стратегії зв’язку, зменшення надлишкових потоків і т.д.;

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

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

Для грамотної побудови такої схеми проектант повинен розуміти основні принципи роботи мережевого обладнання, протоколів обміну, ПЗ вузлів і т.д. На ній він повинен показати:

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

-       блоки даних, якими оперує інформаційний потік як на стороні початкових так і кінцевих даних;

-       мережеві сервіси, через які протікають інформаційні потоки;

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

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

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

Дані. З точки зору графового представлення інформаційних потоків дані – це аргументи функцій та їх рішення на локальному та віддаленому вузлі. Кожний інформаційний потік починається та закінчується таблицею даних, або командами. Даними на кресленні можуть бути змінні контролера, змінні SCADA, записи в базах даних і т.д., які як правило об’єднані (згруповані) між собою по принципу: один блок даних спільний для одного інформаційного потоку. Таке об’єднання дозволяє візуально представити весь процес обміну, а інколи допомагає згрупувати змінні для зменшення навантаження на мережу. В блоках даних вказуються назви змінних, або групи змінних, таблиці змінних, таблиці, масиви, тощо. Якщо кількість змінних така, що їх представлення на схемі приведе до погіршення її читабельності, то можна поставити три крапки в середині блоку і вказати кінцеву змінну. Це має сенс, якщо вони представляють собою певний масив, і всі змінні в середині масиву можна ідентифікувати. В противному випадку необхідно позначити блок змінних, а в пояснювальній записці вказати перелік змінних, які відносяться до цього блоку.

Інформаційні потоки. Кожний потік має номер, який вказаний в певній геометричній фігурі на лінії потоку. Фігура вказує на тип сервісу. Наприклад для клієнт/серверних моделей сервісів, з боку клієнта (той, хто ініціює запит) вказується напрямок передачі даних, а з боку сервера – кружок. У всіх інших випадках можна вказувати просто кружок. При двосторонньому обміні (читання/запис однакових змінних), при використанні одного і того ж сервісу, два і більше потоки можна показувати  як один. При цьому зі сторони клієнта вказується двостороння стрілка а в текстовій частині інформація уточнюється. 

Шлях проходження інформаційних потоків. На кресленні вказуються логічні шляхи проходження потоку. Кожний потік починається з даних. Початком потоку можна вважати бік його ініціювання. Далі вказується програмне забезпечення, що відповідає за обмін (драйвери пристроїв, бібліотеки обміну і т.д.) в порядку слідування потоку. Якщо ці складові приховані від проектанта і вважаються внутрішньою закритою складовою програмно-технічного засобу, то її вказувати не потрібно. Вказуються лише ті частини ПЗ, які неоднозначні і можуть бути замінені на альтернативні. Наприклад, робота з базою даних може йти як через власні  або фірмові драйвери, так і через відкриті ODBC або OLEDB. Вказувати частини ПЗ, що відповідають за обмін, надзвичайно важливо, оскільки це дає уявлення про його реалізацію.

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

 тип_ком_обл : номер_плати . номер_каналу      

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

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

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

Інформаційний потік закінчується аналогічно, як і починався. Тому "початок" потоку є умовним і не обов’язково починається зі сторони клієнта.

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

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

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

Використання даних підходів можливе як при проектуванні реальних комп’ютерно-інтегрованих систем управління так і в навчальному процесі. На сьогоднішній день вони використовуються при виконанні студентами курсових і дипломних проектів за спеціальністю 7.092502 “Комп’ютерно-інтегровані технологічні процеси і виробництва” на кафедрі автоматизації та комп’ютерно-інтегрованих технологій Національного університету харчових технологій.

Рис.4. Схема мережевих інформаційних потоків.

1.                  Пупена О.М., Ельперін І.В. Інтеграція систем управління. // Харчова і переробна промисловість. 2005, №1 с.9-11.

2.                  Баталин Г.Н., Васютинский В.В. Создание распределенных систем сбора данных на основе стандарта ОРС. // Промышленные контролеры АСУ. 2005, №10 с.25-30

3.                  Пупена О.М., Ельперін І.В., Ладанюк А.П. Використання концепції ОРС в сучасних системах автоматизації. // Автоматизація виробничих процесів. 2003, №1 с.65-70

4.                  Трегуб В.Г., Ладанюк А.П. Структуризація системи управління при проектуванні сучасних систем автоматизації цукрових виробництв. // Цукор України, 2005, №4 с.34-36