Даний посібник описує концепції використання взаємопов’язаного набору рекомендацій, структур даних та програм до розробки прикладного програмного забезпечення (ПЗ) для програмованих пристроїв, таких як промислові контролери (PLC/PAC) але не обмежених ними, з урахуванням типових вимог до систем керування, сучасних світових стандартів (ISA, IEC, ISO) та тенденцій (Industry 4.0, IIoT). Ці концепції (надалі називається Каркасом або PAC Framework) дає можливість швидко розробляти ПЗ для PLC/PAC та SCADA/HMI в складі АСКТП з функціоналом, достатнім для будь-яких типів процесів та виробництв: неперервних (Continues), дискретних (Discrete) та періодичних (Batch). Каркас може бути використаний для будь яких програмованих пристроїв. Посібник рекомендується для розробників прикладного ПЗ промислових контролерів та SCADA/HMI.

1. Чернетка 25.03.18
1
PAC Framework V1.01
Функціональний каркас для
розробки прикладного програмного
забезпечення для промислових
контролерів
Олександр Пупена (pupena_san@ukr.net)
Роман Міркевич (roman.mirkevich@gmail.com)
Олег Клименко (frank._.s@bigmir.net)
Володимир Полупан(serunder@mail.ru)
Даний посібник описує концепції використання взаємопов’язаного набору рекомендацій,
структур даних та програм до розробки прикладного програмного забезпечення (ПЗ) для
програмованих пристроїв, таких як промислові контролери (PLC/PAC) але не обмежених ними, з
урахуванням типових вимог до систем керування, сучасних світових стандартів (ISA, IEC, ISO) та
тенденцій (Industry 4.0, IIoT). Ці концепції (надалі називається Каркасом або PAC Framework) дає
можливість швидко розробляти ПЗ для PLC/PAC та SCADA/HMI в складі АСКТП з функціоналом,
достатнім для будь-яких типів процесів та виробництв: неперервних (Continues), дискретних
(Discrete) та періодичних (Batch). Каркас може бути використаний для будь яких програмованих
пристроїв.
Посібник рекомендується для розробників прикладного ПЗ промислових контролерів та
SCADA/HMI.

2. Чернетка 25.03.18
2
1. Основні ідеї
Запропоновані концепції мають за мету швидку розробку прикладного ПЗ для контролерів
АСКТП з урахуванням максимальної кількості типових вимог до функціональності та можливої
інтеграції з іншими підсистемами.
Каркас передбачає:
 використання єдиних принципів розробки ПЗ для програмованих контролерів IEC
61131 (і не тільки) для різних типів об’єктів середньої (порядку >100 каналів) та
великої канальності та алгоритмічної складності;
 використанняєдиних підходів доорганізації ієрархії керування;
 узгоджений набір типів даних, класів функцій/функціональних блоків для будь-яких
об’єктів;
Каркас може бути реалізований на будь-яких апаратних та програмних засобах і мовах
програмування, які мають можливість та ресурси для його реалізації. Запропоновані
інтерфейси та структури за необхідності можуть бути змінені та доповнені не порушуючи
загальної ідеології.
1.1 Передумови створення та основні ідеї
Вимоги до функціональності каркасу сформовані у результаті аналізу вимог до
функціонування АСКТП різного призначення, проблем їх введення в дію та експлуатації. Серед
них варто виділити наступні:
1. проблеми інтеграції з MES/MOM та іншими підсистемами;
2. низька спостережність роботи об’єкта навіть при достатній кількості вимірювальних
даних;
3. «статична» діагностика процесу без прив’язки до типу продукції та особливостей умов
(характерно для Batch-процесів);
4. погана реалізація самодіагностики та неврахування відмов в самій системі АСКТП;
5. недостатньо продуманий механізм функціонування тривог та подій;
6. складність, значні затрати часу на налагодження системи;
7. складність, значні затрати часу на вияв факту несправності та усунення причин;
8. складність, значні затрати ресурсів на навчання персоналу;
Нижче ці проблеми та ідеї їх вирішення розглядається більш детально.
1.1.1. Інтеграція з MES/MOM та іншими підсистемами
Проблеми інтеграції з засобами рівня MES/MOM та іншими підсистемами перш за все лежать
не в площині комунікаційного обміну (зараз ці проблеми вирішується, наприклад, шляхом
використання стандартних протоколів, OPC, технологій EDDL, FDT/DTM, FDI і т.п) а у
функціональному представленні сутностей (об’єктів) нижнього рівня для верхнього та взаємної
координації засобів одного рівня. У більшості існуючих рішень на верхній рівень (SCADA/HMI)
передається "сирі" дані, які попередньо необхідно оброблювати. У зв’язку з недостатньою
кількістю інформації (наприклад про дані що не відображаються) та порівняно невеликою
швидкістю обміну між контролерами та SCADA/HMI, деякі важливі KPI (Key performance
indicators, ключові показники ефективності) та статистичні чи агреговані дані на 2-му рівні, які
потребуються 3-му (MES/MOM) важко обрахувати, або їх значення не може бути забезпечено з
заданою точністю.
Додатковою проблемою також є відсутність (як правило) інформації про достовірність даних.
Так, наприклад, ігнорується відмова каналу ПЛК при відображенні на SCADA/HMI та передачі
недостовірних даних на верхні рівні MES/MOM.
У той же час, обчислювальні ресурси засобів керування, зокрема промислових контролерів,
значно виросли. Тому попередню обробку даних варто робити безпосередньо в засобах
автоматизації рівня керування процесом чи машиною (та навіть польового рівня). У

3. Чернетка 25.03.18
3
запропонованій концепції пропонується використовувати ідеї та модель ієрархії обладнання зі
стандартів ISA-88/95/106 та RAMI4.0 (модель Industry 4.0), відповідно до яких, інформація по
кожному обладнанню представляється своїм набором структур в пристрої, що керує/контролює
цим обладнанням. Це дає можливість робити розрахунки саме за місцем проведення вимірювань та
керування конкретним обладнанням а також робить систему більш гнучкою стосовно варіантів
функціонального розподілення. Використовується принцип функціонального розподілення (IEC
TR 62390), який передбачає розділення всього застосунку (Application) на функціональні блоки і
може бути використаний в різних парадигмах керування (централізована або децентралізована IEC
61131 та розподілена IEC 61499). Прикладом такого підходу є використання структур та функцій,
що відповідають за керування двигуном, безпосередньо в системах управління електроприводами
(PDS, частотні перетворювачі).
Для реалізації ідей, покладених у основу вищезазначених стандартів інтеграції необхідна
підтримка їх на рівні програмно-технічних засобів. Як показує практика, підтримка наведеного в
стандартах функціоналу в конкретних засобах SCADA/HMI сильно відрізняється. Це приводить до
того, що більшу частину функціоналу приходиться реалізовувати самостійно, що найпростіше і
гнучкіше зробити в самому програмованому контролері, якщо використовується парадигма IEC
61131 або гібридна.
1.1.2. Спостережність роботи об’єкта (ситуаційна обізнаність)
Сучасні дослідження в області побудови та експлуатації людино-машинних інтерфейсів в
АСКТП показали необхідність формування контексту для кращої ситуаційної обізнаності. Іншими
словами, відображення числового значення часто не супроводжується його контекстом
(місцезнаходження в межах норми, порівняння з середнім і т.п.) що погано впливає на
спостережність.
Супроводження контекстною інформацією вимагає використання структурованих а не
"плоских" змінних, які би містили усю необхідну у будь-якому місці інформацію про технологічну
змінну. Для прикладу – це стан технологічного параметру (наявність тривог різного рівня,
достовірність значення, стан обслуговування і т.п), межі норми, мінімум/максимум величини і т.п.
Контекст може використовуватися як на засобах ЛМІ, так і в функціях обробки програм
контролера.
У той же час є велика кількість невикористаних ресурсів пристроїв усієї системи. Стрімке
впровадження перетворювачів частоти та інших інтелектуальних засобів в АСКТП разом з
тотальним розповсюдженням промислових мереж (польових шин) дає можливість отримувати
велику кількість додаткових даних про стан процесу без додаткових витрат. Це дає можливість
аналізувати проходження процесу на більш високому рівні.
Наприклад, з перетворювача частоти можна отримати інформацію в реальному часі про
споживану потужність, момент, напруги та струми в даний час, та розраховувати KPI, за яким
можна судити про його ефективність роботи. Незначні несправності як правило не проявляються в
процесі роботи, однак збільшують енерговитрати та зрештою все одно приводять до нештатних
зупинок. Розрахунок KPI та порівняння його з нормою дає можливість звернути увагу на
несправність ще до аварійної зупинки.
Можливе збільшення ситуаційної обізнаності використання порівняння з еталонною
моделлю. Наприклад, баланс за рівнем в ємності та витратами, або порівняння тиску з напірною
характеристикою насосу при вказаних обертах.
Наведені вище можливості можна порівняно легко реалізувати при використання принципів
об’єктно-орієнтованого програмування та розробки загальної гнучкої концепції.
1.1.3. Діагностика процесу (Alarm Management) та обладнання і усунення несправностей
Тривогова підсистема.

4. Чернетка 25.03.18
4
Проблеми невдалої розробки тривогової підсистеми та способи боротьби з ними добре
описані в ANSI/ISA–18.2. Зокрема найбільш типовими є затоплення повідомленнями (alarm
flooding) викликане несправним обладнанням або невірними налаштуваннями тривогової
підсистеми. Реалізація функцій тривогової підсистеми сильно залежить від можливостей
SCADA/HMI. Так, типовим невикористаними можливостями пакета SCADA/HMI (або відсутністю
такої можливості взагалі) є тимчасове виведення тривоги з обслуговування. Це нерідко приводить
до нівелювання функцій підсистеми тривог взагалі. Можливість виведення каналу з експлуатації
значно б спростило обслуговування системи, так як несправний канал не приводив би до обробки
тривог. Крім того, факт виведення каналу може оброблятися в інших частинах програми,
наприклад обробка керування клапаном з кінцевим вимикачем, який тимчасово виведений з
експлуатації.
Додатковою проблемою є узгодження підсистеми тривог SCADA/HMI та керування
світлозвуковою сигналізацією. Враховуючи велику залежність реалізації тривогової підсистеми від
можливостей SCADA/HMI є сенс винести більшість функцій обробки тривог на рівень контролера.
Додатковим аргументом до цього є необхідність використання функцій блокування на рівні ПЛК
та означення додаткового стану поведінки логіки керування.
Для періодичних багато-рецептурних виробництв, характерне простоювання обладнання між
виробничими періодами, та зміна вимог до проходження процесу в залежності від рецепту. Тобто
класичний підхід для АСКТП неперервних процесів, в якому формування уставок для
технологічних тривог проводиться під час розробки ПЗ (та навіть в процесі налаштування) не
підходить для даного випадку. Наприклад, контроль значення температури на виході
теплообмінника повинен проводитися тільки під час проходження процесу
нагрівання/охолодження продукту (не під час простою чи мийки), а аварійні та попереджувальні
значення залежать від типу продукту. Для вирішення цієї задачі, підсистема тривог повинна
адаптуватися під вимоги в залежності від типу продукту, стану обладнання та процесу, що у
більшості випадків простіше зробити на рівні контролеру, аніж SCADA/HMI. Враховуючи, що для
керування періодичними виробництвами розроблений та неодноразово перевірений стандарт ISA-
88, є сенс базуватися на його базисах.
Діагностика обладнання.
"Плоский" (неструктурований) простір змінних, які використовувалися в ПЛК ще 20-му
столітті, нерідко є базою для програмного забезпечення і по сьогодні, хоч сучасні засоби дають
можливість використовувати елементи об’єктно-орієнтованого програмування. "Плоскі" змінні
вміщують тільки значення технологічного параметру, хоч для правильного керування процесом
необхідно мати весь його контекст. Як зазначалося вище, дуже важливою властивістю
технологічної змінної є достовірність даних, яка визначається рядом показників, серед яких є
відмова каналу. Сучасні ПЛК дають доволі багато можливостей програмної діагностики, тим не
менше, значні затрати (не передбачені на початку життєвого циклу) на написання програми
додаткової обробки достовірності в функціях керування у більшості випадків приводять до
нехтування цими можливостями і відсутністю програмної діагностики взагалі. Це не стосується
АСКТП для функціонально-небезпечних процесів.
Достовірність можна відобразити в статусі кожного каналу, та змінної яка пов’язана з цим
каналом. Передаючи статус достовірності разом зі значенням в усі частини АСКТП, додатково до
процесних станів можна ввести стан "недостовірності" (наприклад відмова каналу), в якому можна
прописати окрему логіку обробки. Це цілком відповідає усім сучасним реалізаціям автомату станів
в пристроях автоматизації процесів. Слід зазначити, що обробка недостовірності проводиться в тих
самих програмних блоках, де обробляється технологічна змінна. Наприклад, якщо
використовується функція стабілізаційного регулювання температури на виході теплообмінника,
то при відмові каналу її значення може перейти в крайні положення, або (що ще гірше) залишитися
без змін. При наявності властивості недостовірності, буде згенерована окрема тривога саме для
цього параметру (наприклад, "Відмова каналу вимірювання температури теплообмінника") а
функція стабілізації переведе клапани в безпечний для цього випадку стан. Слід відмітити, що така

5. Чернетка 25.03.18
5
структура програми вимагає стано-орієнтованого підходу навіть для функцій регулювання.
Усунення несправностей
Відсутність контекстної діагностики процесу, обладнання та системи керування приводить до
значної затрати часу на вияв факту та причини несправності. Наприклад, при обриві вхідного
аналогового каналу може формуватися тривога надмірно низького рівня. При цьому елементарний
програмний аналіз міг би дати результат, що канал є недостовірним. Треба відмітити, що такий
рівень часто присутній в сучасних АСКТП. Тим не менше, несправність каналу може бути
викликана рядом причин: наприклад несправністю вимірювального каналу до ПЛК, чи
несправністю електроніки каналу в самому ПЛК. Сучасні ПЛК, надають можливість глибокої
програмної діагностики каналів, з виявленням причин несправності. Ця додаткова інформація дає
можливість набагато швидше усунути несправність.
Іншою проблемою є усунення дефектних частин ПЛК та заміна технічних засобів з одними
характеристиками на інші. Наявність в складі підприємства запасних модулів контролерів, як
правило, характерна тільки для найбільш критичних позицій. Іншими словами, для усунення
несправності інколи необхідно очікувати новий модуль протягом кількох місяців, що недопустимо
для всіх процесів. Враховуючи, що часто виходять з ладу канали (або групи каналів) а не весь
модуль, а при цьому в ПЛК є наявні вільні (невикористані) канали такого ж типу, доречним би
було надати можливість "перекидання каналів". Зміна технічних засобів нерідко потребує зміни
діапазону вимірювання, що також необхідно передбачити в АСКТП.
1.1.4. Налагодження системи
При налагодженні системи виникають ряд труднощів, пов’язаних з реалізацією АСКТП.
Налагодження програми та системи в цілому потребують забезпечення виконання наступних
вимоги:
1) необхідність зміни стану вхідної змінної незалежно від значення фізичного каналу для
перевірки роботи алгоритму;
2) необхідність швидкої реакції імітованих сигналів датчиків при перевірці роботи
алгоритму без наявного процесу (наприклад датчики кінцевого положення клапанів, при
їхвідкритті) для перевірки роботи алгоритму;
3) необхідність зміни значення вихідного каналу, незалежно від стану програми при
перевірці вихідних каналів.
Для виконання перших 2-х вимог за класичного підходу до налагодження програми
(покрокова перевірка виконання дій, оформлених в таблиці, тощо) потребується велика кількість
рутинної роботи, що виконується постійно. У світі комп’ютерного програмування використовують
для цього програмні тести, однак в АСКТП ці механізми недостатньо пророблені. Третя вимога
потребує участь розробника ПЗ для контролерів для виконання операцій форсування, зміни
значення невикористаного каналу, тощо. Допомогти в цьому може програмна імітація та
форсування, що доступні з засобів ЛМІ.
1.1.5. Навчання персоналу
Нерідко навчанню персоналу взагалі не приділяється увага. Проблема пов’язана з
необхідністю навчання роботи персоналу безпосередньо на реальному об’єкті. При цьому,
більшість ситуацій неможливо змоделювати вручну, так як вони цілком залежать від проходження
реального процесу. Критичні ситуації змоделювати на реальному об’єкті взагалі не дозволяється.
Як варіант подолання цих обмежень є використання імітаційного моделювання
безпосередньо в програмі контролеру, що дасть можливість також простіше робити налагодження
програмної частини системи без наявного об’єкту. Крім того, в складі програмних пакетів для
розробки ПЗ контролерів великої та середньої складності як правило є імітатори ПЛК, що дає
можливість "розгорнути" систему управління у будь якому місці. Детально про такий підхід

6. Чернетка 25.03.18
6
можна прочитати за посиланням http://enuftir.nuft.edu.ua/jspui/bitstream/123456789/12221/1/50-54.pdf
1.2 Базові технології каркасу
Запропоновані концепції базуються на реалізації в ПЛК об’єктної моделі обладнання,
відповідно до понять ISA-88, ISA-95 та ISA-106. Кожен апаратурний об’єкт (Equipment Entity)
представляє собою функціональний блок або функцію, та набір даних, що дозволяє реалізовувати
обмін з верхнім рівнем. Структура даних та поведінка функції/ФБ сумісна з означеною в ISA-88,
тобто базується на автоматах станів та режимах (станово-базисне керування), а також інтерфейсі,
означеному в даному стандарті. Процедурні елементи та базове керування теж базується на
стандартних поняттях. Тобто каркас представляє собою:
 взаємопов’язані бібліотечні елементи, які забезпечують реалізацію базового набору
модулів керування (Control Module) та ряду агрегатів (Equipment Module),
незалежно від об’єкта керування,
 а також означення механізму їх імплементації в об’єкти вищого рівня.
1.2.1 Станово-орієнтоване керування (state based control)
Поняття станів
У основі концепції каркасу лежить парадигма керування і створення ПЗ, що базується на
поняттях станів. У кожен момент часу об’єкт та система керування знаходиться в певному стані, в
залежності від якого може змінюватися не тільки величина сигналів керування, а і самі алгоритми.
Особливо яскраво це проявляється в періодичних та дискретних виробництвах, де одне і те саме
обладнання в різний момент часу працює в різних умовах та з різним типом матеріалу. Для
неперервних процесів це менш типово, однак в моменти пуску, зупину, зміни обладнання
(наприклад переключення насосів), нештатних ситуацій (тривоги), зміни режиму, необхідно також
передбачати іншу поведінку системи і алгоритми роботи. У таких випадках, першочергово для
розроблювальної програми керування означується автомат з кінцевої кількості станів (скінчений
автомат), що включає:
- самі стани та необхідні дії (або окремі алгоритми) при їх активності,
- та переходи (умови переходів) між ними.
Скінчені автомати можна описувати формулами, таблицями або діаграмами. Для практичного
використання в програмуванні систем керування знайшли застосування таблиці (наприклад
барабанний регулятор, DRUM-controller), спеціалізовані мови програмування (SFC, Grafcet). У
текстових мовах (наприклад ST) такий автомат добре описується структурою CASE, де в якості
змінної CASE є умовний номер стану (кроку). Формальних методів описів (моделей) доволі багато:
мережі Петрі, скінчені автомати Мура, Мілі. Програмування на базі станів також називають
станово-орієнтованим, автоматним, або case-програмуванням.
Самі прості і зрозумілі для більшості автомати станів, які використовуються у всіх системах
керування, - це режими роботи регуляторів. У даному випадку слово "режим" не протиставляється
слову "стан", і розуміється як підвид стану. Враховуючи що кожен регулятор в автоматизованих
системах передбачає втручання людини, він повинен мати автоматичний та ручний режим, який
означує джерело звідки буде змінюватися значення, що йде на виконавчий механізм. Переходи між
цими станами (режимами) відбуваються за команди оператору (хоча можуть проводитися і
програмним шляхом). Деякі системи можуть потребувати окремого режиму ручного керування за
місцем, тому в такому випадку станів (режимів) вже буде три: ручний (дистанційний,
диспетчерський), автоматичний та місцевий (ручний за місцем). Назва режиму не має значення, але
той факт, що в кожному режимі необхідно передбачити логіку (алгоритм) роботи контуру
регулювання не має викликати сумнівів. Для цих трьох станів (режимів) треба означувати
поведінку регулятору при суперечливих командах за місцем і дистанційному. Навіть на цьому
простому прикладі, означення окремих станів (режимів) не є тривіальними і передбачає
обов’язкове означення поведінки регулятору в кожному з них, що лягає на плечі проектанта (як

7. Чернетка 25.03.18
7
правило не програміста). Враховуючи, що обладнання запускається і зупиняється, необхідно також
передбачувати в якому зі станів (режимів) воно буде знаходитися під час пуску.
Другий загальновживаний приклад використання станів – це керування тривогами. У
більшості випадків кожна тривога описуються класичним набором станів:
 нормальний (Alarm OFF), коли немає тривоги за даною змінною;
 непідтверджена активна тривога (Alarm ON not ACK), коли тривога виникла а
оператор її ще не квітував;
 підтверджена активна тривога (Alarm ON ACK), коли умова активності тривоги
виконується, але оператор її підтвердив (квітував)
 непідтверджена неактивна тривога (Alarm OFF not ACK), коли умова активації
тривоги вже не виконується, але оператор ще не зробив квітування.
Означення самих станів (їх може бути більше або менше) потребується для того, щоб
забезпечити правильні дії. Так, наприклад, аварійна сирена (оповіщувач) може бути увімкненою до
тих пір, поки оператор не зробив квітування, навіть якщо умова активності тривоги не виконується.
Світлова сигналізація у свою чергу може миготіти для непідтверджених тривог, та горіти постійно
для активних підтверджених.
рис.1.1. Приклад означення поведінки тривоги в автоматі станів.
Слід зазначити, що описані вище приклади стосуються усіх типів процесів та виробництв.
Для періодичних процесів необхідність в означенні станів ще більш очевидна, бо одне і те саме
обладнання в кожен момент часу має робити різні керівні діяльності, наприклад наповнення
апарату, дозування інгредієнтів, нагрівання, мийка, тощо. Ці періоди роботи, які характеризуються
одним набором діяльностей зручно відокремлювати в окремий стан (крок, етап), при активності
якого активуються ті чи інші алгоритми керування. Цей механізм є одним із фундаментальним в
стандарті ISA-88 (Batch Control).
Таким чином, кожен об’єкт (обладнання, програма, регулятор тощо) характеризується певним
станом, в залежності від якого система керування виконує той чи інший алгоритм. Дуже важливим
є розуміння того, що один і той самий об’єкт характеризується набором станів з точки зору різних
аспектів. Так, наприклад, запірний клапан може характеризуватися наступними наборами станів і
підстанів:
- положення: відкритий, закритий, відкривається, закривається, невизначений;
- тривоги (кожна тривога описується своїм автоматом станів тривог): не закрився, не
відкрився, довільний зсув, помилка датчиків положення;
- блокування: заблокований, незаблокований;
- режим роботи: ручний, автоматичний
Ці набори (автомати станів) можуть бути взаємопов’язані і впливати один на одного.
Наприклад, одна з тривог може привести до блокування клапана, тобто переводу в спеціально
означений стан "заблокований". У цьому стані вихід на керування клапаном буде відключеним, і

8. Чернетка 25.03.18
8
при цьому режим буде насильно триматися в ручному, поки не буде відправлена команда на
розблокування. Однак, в той же час, положення буде вказувати на дійсне положення клапану
згідно датчиків кінцевого положення та команд керування.
Поняття режимів
Слова "Режим" і "Стан" у конкретному випадку можуть означувати різні особливості
діяльності. З одного боку, вони обидва описуються автоматом станів. Однак "Стан" як правило
вказує на плинну ситуацію, а "Режим" – на особливості поведінки алгоритмів керування. Тому
"ручний/автомат" та "заблоковано/незаблоковано" прийнято називати режимами, так як вони
означують особливості керування. У ручному режимі команди на клапан відправляє оператор. У
заблокованому режимі на клапан завжди подається команда закриття (або відкриття). Наявність
двох "автоматів режимів" (це теж автомат станів, але слово "стан" не використовується, щоб
протиставити режими станам), також потребує їх узгодження, бо їх дії конфліктують між собою.
Тому необхідно означити пріоритети, наприклад дії в режимі "заблоковано" мають вищий
пріоритет ніж в режимі "ручний".
Режими і стани означені в системі керування для різних об’єктів теж як правило взаємодіють
між собою. Так, наприклад, для усієї установки можуть бути означені режими: ручний,
автоматичний та налагоджувальний. При цьому зміна режиму в "налагоджувальний" може
змінювати пріоритет режимів "ручний/автомат" та "заблоковано/незаблоковано".
Для означення набору станів в програмі користувача потребуються стільки змінних, скільки
автоматів станів. Для прикладу з дискретним клапаном треба змінні:
- положення: (5 значень);
- тривоги (кожна тривога описується своїм автоматом станів тривог, тому потребується
окрема змінна): не закрився (4 значення), не відкрився (4 значення), довільний зсув(4
значення), помилка датчиків положення (4 значення);
- блокування (2 значення): заблокований, незаблокований;
- режим роботи (2 значення): ручний, автоматичний
Враховуючи що системи керування передбачають наявність SCADA/HMI, стани кожної
тривоги в програмі користувача ПЛК можна означити тільки 2 значеннями. Навіть при такій
постановці, кількість змінних є дуже великою, а значень станів при цьому досить небагато (часто
2). Тому є сенс "упаковувати" їх в одне слово статусу, біти якого будуть представляти стан/режим
певного автомату. Такий підхід використовується, наприклад, при керуванні перетворювачами
частоти та севроприводами по мережі (IEC 61800-7: профілі PROFIDRIVE, CIA402, CIP Motion,
SERCOS). У даному каркасі усі біти станів об’єктів пакуються в одну змінну (поле структури) з
назвою STA. Приклад такого упакування показаний в 1.4.
Поняття команд
Поведінка автоматів для станів та режимів залежить від об’єкту керування, логіки алгоритму
керування та команд оператору чи суміжної системи. Враховуючи, що команд може бути багато,
зручно використовувати слово команди, числове значення якого буде вказувати на необхідну дію.
Обробник команд може не реагувати на ті команди, які недоступні в даному стані/режимі.
Поширювання режимів/станів
В ієрархічних та розподілених системах керування певні сутності (обладнання, процедури)
залежать одна від одної. Це передбачає взаємозалежність станів та режимів. У багатьох випадках
ця залежність може бути означена і в автоматах станів. Наприклад, переведення установки в
ручний режим, може привести до переведення в ручний кожного виконавчого механізму
установки. Або стан "пауза" загальної процедури керування всією установкою може привести до
такого самого стану всіх етапів.
1.2.2. Поняття обладнання (устаткування, Equipment) згідно стандартів ISA-88, ISA-95 та
ISA-106

9. Чернетка 25.03.18
9
Ієрархія обладнання
Згідно стандартів ISA-88, ISA-95, ISA-106 та їх аналогів IEC для опису діяльностей
підприємства використовуються декілька типів виробничих моделей. Активний стан, виробничі
можливості, вимоги до виготовлення продукту та інших операційних діяльностей усього
підприємства або його частин проводиться через фізичну модель обладнання (Equipment,
устаткування). Ця модель показує наявне на підприємстві обладнання з точки зору його рольового
призначення у певній операційній діяльності, наприклад виготовлення продукції. Обладнання
верхніх двох шарів ієрархічної моделі використовуються для операційної діяльності на
організаційно-економічному рівні керування (рис.1.2). На обладнанні згрупованому в дільниці
виготовляється певний вид продукції. Робочі центри забезпечують певний вид діяльності
переробки сировини (умовно) в напівфабрикат (умовно). Саме робочі центри є "датчиками" і
"виконавчими механізмами" для рівня MES/MOM і в той же час системою керування для рівня
АСКТП. Тому вони знаходяться в області діяльності як ISA-95 так і інших стандартів та кращих
практик області АСКТП. Контролери та SCADA знаходяться в зоні діяльності починаючи з цього
рівня вниз. Для безшовної інтеграції з рівнем MES/MOM та використання кращих практик,
викладених в ISA-88 та ISA-106 при автоматизації різних типів процесів, каркас базується на
моделі обладнання цих стандартів.
Принцип організації технологічних процесів впливає і на способи керування ними. Для
періодичних процесів зі змінною рецептурою принципи керування означені стандартом ISA-88, в
якому робочі центри є технологічними комірками, які виготовляють (напів-)продукт невеликими
партіями (batch). У стандарті передбачено, що уся послідовність дій з сировиною означується
рецептурою, яка може змінюватися операційним персоналом без зміни програми керування в
АСКТП. Ці дії (процедури) відбуваються в апаратах періодичної дії (Unit), які можуть
об’єднувати навколо себе агрегати (Equipment Module) та модулі керування (Control Module).

10. Чернетка 25.03.18
10
Модель для неперервних та дискретних процесів включає дещо інші типи обладнання. Однак
в даному каркасі буде використовуватися ієрархія, що дана в ISA-88. Для кращого розуміння ідей
використаний в каркасі рекомендується ознайомитися зі стандартом ISA-88 або його аналогом IEC
61512. Нижче будуть дані тільки деякі основні положення.
Слід наголосити, що в даній моделі обладнання розглядається саме с позиції рольового
призначення. Тобто, насос в даній ієрархії розглядається як будь яке обладнання, що виконує
функцію перекачування в конкретному місці розташування технологічного процесу. Тобто це те
обладнання, яке на апаратурно-технологічній схемі або схемі автоматизації має своє умовне
позначення. Якщо цей насос при певних обставинах змінюється на обладнання, априклад іншого
виробника, то з точки зору даної моделі, це буде той самий насос. Для того щоб враховувати
конкретні екземпляри обладнання (зі своїм серійним номером) в ISA-95 передбачена інша модель –
активів (Asset). У каркасі наразі не використовується модель активів.
Технологічна комірка
Технологічна комірка (Process cell), що описана в стандарті ISA-88 відповідає робочому
центру (Work Center) означеному в IEC/ISO 62264 та ANSI/ISA 95 (див.рис.1.2). У той час, як
робочий центр може бути означений для різних типів виробництв, технологічна комірка означена
тільки в термінах періодичної обробки, що характерно для стандарту ISA-88. Технологічна комірка
представляє собою логічне угруповання, яке вміщує обладнання, що необхідне для виробництва
Рис.1.2 Загальна модель ієрархії обладнання (фізична модель
підприємства) для ISA-95 та ISA-88

11. Чернетка 25.03.18
11
однієї або декількох партій (напів)продукту. Вона означує діапазон логічного керування одним
набором технологічного обладнання в межах дільниці.
Наявність технологічної комірки дає можливість планувати на основі неї виробництво і
розробити стратегію керування усім процесом. Технологічна комірка включає апарати (units),
агрегати (equipment modules) та модулі керування (control modules) що потрібні для створення
однієї або більше партій. Ідея ISA-88 передбачає, що для технологічної комірки існує рецепт
(recipe), в якому вказується що саме і з використанням якого саме обладнання буде робитися в
межах неї. Цей рецепт означується технологами і включає процедуру приготування для партії
(напів)продукту (procedure) та додаткові параметри. Процедура технологічної комірки у свою
чергу ділиться на менші процедури апарату (unit procedure), які можуть ділитися на етапи
(phase) таким чином формуючи так звану "технологічну програму" приготування.
Апарат періодичної дії
Апарат періодичної дії, або просто Апарат (Unit) складається з агрегатів та модулів
керування. Модулі керування та агрегати, які входять до апарату можуть бути налаштовані як його
частина або можуть тимчасово ним заволодіватися (allocation) для виконання конкретних завдань.
У апараті можуть бути проведені один або декілька основних процесів таких як хімічна
реакція, кристалізація і розчинення. Як незалежне угруповання, він поєднує в собі все необхідне
обладнання для фізичної обробки та керування, що потребується для виконання цих дій. Апарат, як
правило, зосереджений на основній частині технологічного обладнання, такого як змішувальна
ємність, або реактор. Фізично він включає в себе, або може заволодівати послугами всього логічно-
пов'язаного обладнання, необхідного для завершення основних процесів обробки в ньому. Апарати
працюють відносно незалежно один від одного.
Нагадаємо, що апарат, який описаний в стандарті ISA-88, відповідає типу робочого апарату
(Work Unit), означеного в IEC/ISO62264 та ANSI/ISA 95. Він означує чотири типи робочих
апаратів: апарати періодичної дії, апарати неперервної дії, дискретні робочі комірки (work cell) та
апарати зберігання (storage unit). Унікальність апарату періодичної дії є в тому, що він не може
обробляти одночасно декілька партій.
Апарат періодичної дії як правило містить всю партію матеріалу (весь обсяг) або працює в
деякому місці послідовності обробки цієї партії. Тим не менше, в деяких випадках він може
містити або працювати тільки з частиною партії (частиною обсягу).
Зазвичай, в один момент часу апарат періодичної дії містить тільки одну партію, і в цих
випадках фізичний поділ між партіями є звичайним явищем. Величина партії при цьому
визначається економічними вимогами і фізичними обмеженнями апарату. Однак, у деяких
процесах поділ відповідно до апарату є не таким очевидним, і використовується логічна межа між
окремими партіями. Така ситуація часто зустрічається в гібридних процесах, що складаються з
періодичних та неперервних процесів. У гібридних процесах в рамках технологічної комірки
використовуються обидва типи технологічного обладнання: апаратів періодичної та неперервної
дії. У апаратах неперервної дії процес є загальним для двох або більше партій які знаходяться в
межах апарату в один момент часу.
Робочий апарат може бути спеціалізованим для різних типів виробництв і функцій. У
технологічній комірці періодичної дії може навіть знадобитися більш ніж один тип робочого
апарату, таких як апарати зберігання або апарат неперервної дії. Якщо спеціально не вказано інше,
робочий апарат, згаданий далі в якості «апарату» є апаратом періодичної дії і не відноситься до
інших видів роботи робочих апаратів, зазначених у IEC/ISO 62264 та ANSI/ISA 95.
З точки зору "технологічної програми", закладеної в рецепті, процедура апарату повинна
починатися і закінчуватися в тому самому апараті. Таким чином, поділ на процедури апарату
визначається можливостями усіх апаратів, які доступні в технологічній комірці.
Агрегат
Агрегат (Equipment module) може виконувати кінцеву кількість конкретних незначних

12. Чернетка 25.03.18
12
технологічних діяльностей, таких як, наприклад, дозування і зважування. Він поєднує в собі все
необхідне обладнання для проведення фізичних процесів та обладнання для керування,
необхідного для виконання цієї діяльності. Агрегат, як правило, зосереджений на частині
технологічного обладнання, такого як насосний агрегат. Функціонально, сфера дії агрегату
означується кінцевими задачами, для яких він створений. З точки зору керування періодичними
процесами, агрегат може виконувати мінімальну технологічну дію, яка задається в рецепті, тобто
етапом.
Фізично агрегат може бути складений з модулів керування і підпорядкованих агрегатів
(subordinate equipment modules). З точки зору ієрархії обладнання, агрегат може бути частиною
апарату або автономним угрупованням обладнання всередині технологічної комірки. Якщо
угруповання обладнання проектується як автономне, а не в складі якогось апарату, то воно може
бути доступне тільки в зв’язці з якимось одним обладнанням, або з декількома, тобто з
використанням різних наборів обладнання. Наприклад, насосний агрегат, що забезпечує подачу
речовини з декількох ємностей на фасування може вважатися спільним (common) ресурсом, так як
почергово задіюється в керуванні різними танками. Спільні агрегати можуть займатися для
використання одночасно тільки одною технологічною програмою (ресурс з ексклюзивним
використанням) або декількома (ресурс із колективним користуванням).
Агрегат – це найнижчий рівень обладнання, які "видимі" для рецептурного керування.
Модуль керування (Control Module)
Модуль керування (Control module, CM), як правило, - це набір датчиків, виконавчих
механізмів, інших модулів керування і зв’язаного з ними технологічного обладнання, що, з точки
зору керування, працює як єдине ціле. Модуль керування також може бути складений з інших
модулів керування. Наприклад, модуль керування колектором подачі речовини може бути
означений як сукупність декількох модулів керування дискретними клапанами (виконавчі
механізми + датчики). Модулі керування можуть бути частиною агрегату або безпосередньо
підпорядкованими апарату чи технологічній комірці. Фізична модель не передбачає, що модуль
керування може одночасно безпосередньо входити в апарат і бути частиною агрегату. Якщо
одиничний модуль керування є безпосередньою частиною апарату, тоді він не може бути частиною
жодного агрегату.
Деякі приклади модулів керування:
— регулюючий пристрій що керується уставкою, який складається з передавача,
регулятора, і регулюючого клапану;
— орієнтований на стан пристрій, що керується уставкою, який складається з
автоматичного запірного клапана (on/off) з встановленими на ньому кінцевими
вимикачами за положенням;
— модуль керування колектором, що містить блок з кількох автоматичних запірних
клапанів (on/off) і координує подачу на один або декілька напрямків, в залежності від
уставки спрямованої на модуль;
— модуль керування витратою, що регулює витрату речовини в кільцевому колекторі
системи живлення, яка може бути частиною технологічної комірки і не бути частиною
якого-небудь апарату.
У новій версії стандарту ISA-88.00.01-2010 є дві моделі обладнання: фізична і об’єктна.
Об'єктна модель передбачає, що обладнання (Equipment Entity) включає в себе також функції
керування, навіть якщо вони є частиною програми керуючого пристрою (наприклад контролеру), а
не фізичного обладнання. У контексті даного каркасу обладнання завжди представляється саме з
цієї позиції.
З точки зору ISA-88 модулі обладнання виконують базові функції керування (Basic Control).
1.2.3. Основи керування періодичними виробництвами згідно ISA-88

13. Чернетка 25.03.18
13
Специфіка керування періодичними виробництвами
Даний каркас розроблявся з урахуванням реалізації складних алгоритмів керування
періодичними процесами. Порівняно з неперервним виробництвом, періодичне значно обмежене в
часі (години, доби) від моменту пуску до завершення, оскільки вся продукція разом проходить
послідовні стадії обробки (нерідко в одному апараті). Крім того кількість продукції (і відповідно
сировини) обмежена величиною партії, яка як правило залежить від ємності обладнання, в якій
вона готується. Для виготовлення однієї й тієї ж партії може використовуватися різне обладнання,
що потребує планування використання цього типу ресурсу.
Порівняно з дискретним виробництвом, сировина не може ідентифікуватися однозначно,
оскільки з однієї й тієї ж ємності з сировиною може виготовлятися декілька різних партій та навіть
типів продуктів. Тобто сировина може ідентифікуватися в межах партій, але тільки логічним
визначенням.
Серед наведених вище типів виробництв періодичне є найбільш гнучким, але потребує більш
складних алгоритмів керування. На рис.1.3 показаний один з варіантів реалізації обладнання
періодичного виробництва. Одна виробнича площадка може мати багато однотипного обладнання,
що здатна виконувати певний набір технологічних операцій. Якщо цей набір задовольняє
параметрам означеним для продукту в рецепті, то це обладнання може використовуватися для його
приготування. Однак для кожного продукту означений свій перелік послідовностей операцій, тобто
своя «технологічна програма». Найбільш гнучким і ефективним буде використання такого способу
керування цим обладнанням, коли будь який продукт може вироблятися на будь якому обладнанні,
яке здатне виконувати технологічні операції.
Для неперервних виробництв технологія визначається ще перед проектуванням обладнання і
принципово не змінюється протягом життєвого циклу роботи системи. Звичайно, в певній мірі
можуть змінюватися параметри технологічного процесу, зокрема при зміні параметрів сировини чи
вимог до якості продукції. Для такої ситуації достатньо, щоб в системі керування для однієї і тієї
самої програми змінювалися завдання або певні коефіцієнти. Однак в періодичному виробництві,
одне і те саме обладнання може використовуватися для приготування різних продуктів. Тому при
проектуванні обладнання визначаються певним набором технологічний операцій та праматерів їх
виконання, а при розробці технології продукту оперують саме цими операціями та їх
послідовностями виконання. Тобто принциповою відмінністю для періодичних виробництв є
необхідність в означенні цієї послідовності а не тільки значень параметрів.
Рис.1.3. Гнучке використання обладнання в періодичних процесах.
технологічне
програма
обладнанняозначення
продукту

14. Чернетка 25.03.18
14
Нижче наведемо основні вимоги до системи керування періодичними процесами та
виробництвом в комплексі.
1. Система керування повинна передбачати можливість створення та модифікації означення
продукту (не тільки параметрів а і послідовності обробки) без втручання в програмне та
технічне забезпечення, тобто без її зміни. Модифікація послідовності обробки повинна
бути доступна як перед запуском виробництва продукту, так і під час його вироблення.
2. Система керування повинна передбачати використання одного і того самого обладнання
для приготування будь якого продукту, технологічні операції якого здатне виконувати це
обладнання.
3. У означенні продукту повинна міститися також логіка обробки технологічної (тобто не
пов’язаної з помилками роботи обладнання) нештатної ситуації. Наприклад, якщо
величина pH речовини протягом заданого часу не дійшла до заданого значення,
включається технологічна програма додаткової обробки.
4. Система керування повинна передбачати можливість виконання як автоматичних так
ручних операцій, передбачених в означенні продукту. Наприклад, система повинна
очікувати внесення закваски в танк з молоком, з підтвердженням оператором даної
операції.
5. Система керування повинна передбачати ручного введення значень вимірювань,
наприклад результатів лабораторних аналізів.
6. Система керування повинна давати можливість використання спільних ресурсів для різних
апаратурних послідовностей. Наприклад один і той же насос може використовуватися для
різних груп танків і при цьому для різних продуктів.
7. Система керування повинна давати можливість розробляти план-графіки для вироблення
продукту з урахуванням специфіки обладнання.
8. Система керування повинна давати можливість відстеження історії приготування
конкретної партії продукту, формування звітів по партіям.
9. Система керування повинна передбачати її інтегрування з верхнім рівнем ієрархії.
Таким чином класичний підхід побудови систем керування, при якому вся логіка
технологічного процесу жорстко задається в ПЛК (PLC) чи вузлі DCS для керування періодичним
виробництвом не підходить. Для керування такими процесами визначені стандарти групи ISA-88 та
їхні аналоги МЕК.
Означення технологічного процесу
ISA-88 базується на 2-х основних моделях – це означення продукту та означення обладнання.
Означення обладнання описано вище. Інші моделі слугують тільки для універсалізації обміну між
компонентами.
Стандарт ISA-88 базується на таких основних принципах:
 відокремлення логіки приготування продукту від керування обладнанням, тобто логіка
приготування продукту визначається в означенні продукту а не в системі керування;
 модульність моделей означення продукту та обладнання, що дозволяє будувати
ієрархічні моделі та реалізовувати їх взаємопов’язаними блоками одного засобу або на
різних засобах автоматизації;
 система керування повинна передбачати як автоматичні так і ручні операції
 керування базується на станах (автоматі станів)
Означення продукту в термінах ISA-88 називається рецептом (recipe). Він включає в себе
опис ресурсів які необхідні для вироблення продукту та означення послідовності технологічних
операцій. Необхідна сировина, її кількість, що потребується для виготовлення певної кількості
продукту є частиною формули (Formula). Устаткування, яке необхідне для вироблення продукції
вказується у вимогах до обладнання (Equipment Requirements).
Означення послідовності обробки для продукту називається означенням технологічного

15. Чернетка 25.03.18
15
процесу (process definition). Частини означення періодичного процесу можуть бути організовані в
ієрархічному порядку, як показано на рисунку 1.4. Розглянемо це на прикладі приготування
морозива.
Означення процесу складається з однієї або декількох технологічних стадій (Process stages),
що організовуються у впорядковані набори, які можуть відбуватися послідовно, паралельно, або
змішано. Технологічна стадія є частиною означення процесу, яка зазвичай працює незалежно від
інших технологічних стадій. Це зазвичай призводить до запланованої послідовності хімічних або
фізичних змін в оброблюваному матеріалі. Типовими технологічними стадіями в процесі
вироблення морозива можуть бути:
- зробити суміш
- ароматизувати суміш
- заповнити пінту
- упакувати
Кожна технологічна стадія складається з упорядкованого набору однієї або декількох
технологічних операцій. Технологічні операції (Process operations) представляють основні
технологічні діяльності. Технологічна операція зазвичай призводить до хімічної або фізичної зміни
оброблюваного матеріалу. Типовими технологічними операціями для технологічної стадії
вироблення суміші для морозива можуть бути наступні:
- змішати інгредієнти
- пастеризувати
Кожна технологічна операція складається з упорядкованого набору однієї або декількох
технологічних дій, які здійснюють обробку, необхідну для технологічної операції. Технологічні дії
(Process actions) описують незначні діяльності по обробці, що об'єднуються для створення
технологічної операції. Типовими технологічними діями для технологічної операції «змішати
інгредієнти» можуть бути наступні:
Рис.1.4. Модель означення технологічного процесу (процесна модель) для
періодичних виробництв.

16. Чернетка 25.03.18
16
- наповнити водою ємність на ¾ від загального об’єму,
- одночасно добавляти стабілізатор в пропорції 1/100,
- одночасно добавляти підсолоджувач в пропорції 1/100,
- одночасно перемішувати
- добавити молоко 1/10 від загального об’єму
- добавити вершки 1/20 від загального об’єму
- добавити яєчний порошок 1/10 від загальної маси
Нижче ми розглянемо, що на різних етапах означення продукту, тобто рецептів, і на різних
рівнях керування модель має дещо різний вигляд. Однак основна ідея залишається та сама.
Означення технологічного процесу в кінцевому етапі формує процедуру (Procedure).
Поняття процедурної моделі та зв'язок з моделлю обладнання
Декомпозиція в моделі обладнання на рівні є невипадковою. Ключовим фактором для цього
слугує модель означення продукту, тобто рецепт. Для можливості виконання означення
технологічного процесу на конкретному обладнанні, загальний або місцевий рецепт перетворюють
на майстер рецепт (master recipe), який враховує модель обладнання. На рис.1.5 показана
перетворення процесної моделі в процедурну модель майстер рецепту. Технологічна процедура по
виготовленню продукту може виконуватися в конкретній технологічній комірці як процедура
технологічної комірки (process cell procedure). Технологічні стадії виконуються в конкретних
апаратах, як процедури апарату (unit procedure), які в свою чергу складаються з послідовностей
операцій. Найменші дії, які описуються в рецептах – це етапи (phase).
Як вже зазначалося, декомпозиція означення продукту в майстер-рецепті проводиться з
урахуванням наявного обладнання, а означення обладнання - з урахуванням можливого виконання
етапів, операцій та процедур апаратів та технологічної комірки даним набором обладнання. При
створенні системи керування для технологічної комірки, визначають компонувальні блоки
(наприклад етапи) з яких можна буде формувати процедури майстер-рецептів. Розглянемо як в
загальному відбувається перетворення загального рецепту на майстер-рецепт на прикладі.
При створенні системи керування для наявного обладнання (або при побудові підприємства
чи цеху) визначають набір технологічних дій, операцій та процедур які може виконувати дане
обладнання. Так, наприклад, на підприємстві є цех з ємностями (танками), в яких можна готовити
суміші, перемішуючи їх, підігріваючи та охолоджуючи в певних температурних діапазонах.
Рис.1.5. Перетворення процесної моделі в процедурну модель майстер-рецепту

17. Чернетка 25.03.18
17
Ємності зроблені з нержавіючої сталі і передбачають мийку, що дозволяє виготовлювати в них
харчові продукти. Ємності мають зв'язок з пастеризаційною установкою і фасувальними
апаратами. Таким чином в ємності можуть проходити певні послідовні операції, включаючи набір
сировини, підігрів, охолодження, перемішування (з різною частотою), злив на фасування з
попереднім охолодженням, мийка. З точки зору ієрархії обладнання, така ємність означується в
моделі як апарат (Unit), тому що саме в апараті проходять послідовно основні технологічні
перетворення. Цех з танками та охолоджувачами спільно з пастеризатором (теж апарат) і
фасувальними апаратами можуть розглядатися як технологічна комірка, яка може проводити такі
стадії (процедури технологічної комірки) як пастеризація сировини, формування сумішей з їх
додатковим підігрівом/охолодженням, сквашуванням і т.д, а також фасування продукції в певні
види упаковок.
У цьому прикладі насосні агрегати, мішалки, підігрівники та охолоджувачі не виконують
ніяких послідовних операцій, тому не являються апаратами. Однак вони виконують технологічні
дії (етапи). Так, наприклад, насосний агрегат разом з частотним перетворювачем може
забезпечувати подачу продукції на фасування з заданим тиском в трубопроводі, відповідно до типу
продукту, що визначний в рецепті. Такий об’єкт добре підходить в означенні обладнання як
агрегат (equipment module, EM). Насосний агрегат не належить жодному апарату, так як
знаходиться на загальній лінії фасування, тому він є безпосередньою частиною технологічної
комірки. Мішалка, як частина танку, забезпечує виконання такого етапу, як перемішування, тому з
точки зору ISA-88 теж може бути агрегатом.
Усі наведені вище елементи виконують певні дії, які можуть бути означені в рецепті. Іншими
словами, вони виконують процедурне керування. Тому при розробці системи керування згідно
ISA-88 буде формуватися набір бібліотечних елементів, які звуться компонувальними блоками
(building blocks), які можуть реалізувати на конкретному обладнанні ці дії. Людина, яка формує
майстер-рецепт (наприклад технолог), буде набирати для нього "технологічну програму", тобто
процедуру рецепту, з цих готових компонувальних блоків. Враховуючи, що ці елементи будуть
однотипними для однотипного обладнання, у майстер рецепті буде вказуватися тільки сама
процедура та вимоги до обладнання. А при виконанні рецепту, процедури рецепту будуть
викликати однойменні процедури в конкретному обладнанні, запускаючи їх на виконання.
Для реалізації вимірювання та керування на конкретному обладнанні використовуються
різноманітні клапани з датчиками кінцевого положення, датчики вимірювання температури, рівня,
тиску, пускачі двигунів, перетворювачі частоти і т.п. які забезпечують роботу апаратів та агрегатів.
Якщо в рецептах означене тільки набір процедур (процедурне керування), то в обладнанні повинні
бути прописані дії з цим обладнанням. Такі дії виконуються модулями керування (control module,
CM), а самі дії відносяться до базового керування (basic control). Якщо процедурне керування
означене в рецепті (як означення продукту) і в обладнанні (як ресурс для виконання через
компонувальні блоки), базове керування стосується тільки обладнання і по суті робить зв'язок
універсальних процедур з конкретним обладнанням.
На рис.1.6 показаний приклад майстер рецепту для приготування морозива, який описаний
вище в означенні технологічного процесу. У даному випадку процедури апарату можуть
виконуватися як в різних апаратах так і в одному. Так, наприклад, якщо апарат може готовити
суміш і ароматизувати її, то це може бути один і той самий апарат. Однак на тому ж виробництві
можуть бути апарати що проводять ці процедури окремо, тому в майстер рецепті вони теж
прописані як окремі процедури апарату. Усі операції в апараті проходять послідовно, а етапи
можуть проходити паралельно. За етап перемішування може відповідати окремий агрегат, який
входить в апарат як обладнання.

18. Чернетка 25.03.18
18
Виконання рецепту
Отже, загальний та місцевий рецепти створюються без означення конкретики обладнання,
хоч і мають в своїй структурі певні вимоги до нього. Майстер рецепт створюється з місцевого
рецепту (хоч може створюватися без нього) з урахуванням наявного на виробництві обладнання та
його можливостей. Ці можливості визначаються набором заздалегідь створених компонувальних
блоків, що реалізовують процедури в керуванні обладнанням. Формуючи продеру рецепту з таких
блоків-процедур, технолог практично означує, які саме процедури необхідно виконувати на
обладнанні і в якій послідовності. Слід звернути увагу, що така система передбачає наявність в
системі керування обладнанням реалізованих процедур як мінімум на рівні етапів (phase).
Майстер-рецепт по своїй суті є шаблоном, в якому задана множина обладнання, що може
бути використане при виробництві даного типу продукту. Його створює технолог для конкретного
типу продукту, що може виготовлятися в конкретній технологічній комірці. Однак, при виконанні
рецепту необхідно додатково:
 вказати кількість продукту, що необхідно зробити (величина партії) згідно цього
рецепту
 конкретизувати обладнання, що буде використовуватися при виготовленні саме даної
партії
 вести архівування по технологічним процесам виготовлення партії, з можливістю
подальшого відслідковування
Для цього з майстер рецепту створюється керівний рецепт (control recipe), який являється
унікальним для кожної партії продукту. Керівний рецепт отримує унікальний ідентифікатор, у
ньому вказується шлях проходження продукту і є «маркером» для ведення архіву партії.
Поняття типів керування
Рис.1.6. Приклад процедури майстер рецепту морозива