Досвід використання стандарту IEC 61512 в проектах та в навчанні

Слід відмітити досить важливу річ, яку потрібно розуміти тим, хто має на меті впровадити систему керування порційним виробництвом згідно стандарту IEC 61512: стандартними засобами АСКТП (SCADA/HMI + контролер) без використання спеціалізованого пакету, або модулю SCADA-програми чи MES/MOM) це зробити дуже важко. Це розуміння повинно бути і у замовника, оскільки впровадження повноцінного функціоналу потребує додаткових затрат.

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

1. Власний досвід впровадження у проектах.

З 2017-го року ми (www.i4u.in.ua) почали впроваджувати елементи стандарту в свої проекти. Протягом цього періоду (з 2017-го по сьогодні) ми зробили з десяток проектів, де в тій чи іншій мірі використовувалися діяльності систем керування відповідно до вимог, означених в стандарті. На сьогоднішній день у нас є свій каркас (PAC Framework) що є власним стандартом для розробки ПЛК та SCADA/HMI, що базується на IEC 61512. Також у нас є бачення, як можна доповнити цей каркас для реалізації усіх функцій стандарту IEC 61512. Відмітимо також, що тільки кілька з цих об’єктів були частиною порційного виробництва, інші хоч і вміщували періодичні процеси, належали до неперервного або дискретного виробництва. Нижче наводяться результати впровадження елементів стандарту в проектах, у яких ми виступали у якості програмістів АСКТП.

Проектування програми керування. Використання стандарту впливає на всі стадії та етапи життєвого циклу. Ми мали відношення та вплив тільки на розробку прикладного ПЗ. Після отримання технічного завдання і схеми автоматизації ми обговорювали разом як найкраще виділити процедури та апаратурні об’єкти (устатковання + функції керування). Враховуючи, що проекти стосувалися тільки однієї технологічної комірки, а на рівні модулів керування правила були означені каркасом (PAC Framework), залишалося виділити тільки технологічні вузли (Unit) та модулі устатковання (Equipment Module). Задача була не тривіальною,  мала ітераційний характер однак з досвідом ми навчилися це робити.

Означення процедур зводилося до визначення правильного набору найменших елементів – етапів. Усе що відносилося до опису технології, мало початок і закінчення в межах якогось набору устатковання і більше не могло ділитися на елементи з означеним автомату станів – ставало етапом.  З процедурами технологічних вузлів було простіше, бо це означувалося наявністю таких вузлів. Коли етапів було багато, а в технологічному вузлі різні процедури повинні були задіюватися у різних рецептах, ми їх об’єднували в операції (наприклад мийка технологічного вузла). У стандарті процес виділення процедурних елементів і устатковання показана у пункті 6.1.3 «Інженерія (проектування та розробка) технології і систем керування» та графічно показана на рис.1.

рис.1. Вибір процедурних елементів і апаратурних об’єктів згідно стандарті

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

У нас були і невдалі рішення щодо означення об’єкту рівня устатковання або процедурного елементу. Це значно ускладнювало подальшу роботу. Надмірна обережність щодо обмеження внесення змін в програму привела зрештою до постійних проблем зі змінами у майбутньому. Тому, у випадку невдалого вибору рішення з виділення апаратурних об’єктів та процедур варто внести зміни в програму ще на ранніх стадіях розробки ПЗ.    

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

Згідно IEC-61512 для устатковання може (хоч і не обов’язково) використовуватися поширення режимів. Виявилося, що це досить зручний механізм з точки зору експлуатації, так як переведення технологічного вузла в один із режимів (ручний/автоматичний/блокування) приводило до відповідної зміни режиму усього підлеглого устатковання.

До ознайомлення зі стандартом один із програмістів нашої команди мав досвід розробки програми керування об’єктами, де один і той самий виконавчий механізм, або їх група використовувалися у алгоритмах різних програмних об’єктів. Необхідно було вирішити ряд питань: визначення того, кому належить даний об’єкт, як забезпечити обмеження одночасного доступу в програмі, а також одночасно з якою процедурою він повинен переходити в автоматичний та ручний режим. Рішення було знайдено, але його пошук і перевірка зайняли багато часу. У стандарті ця задача має стандартне вирішення через механізм надання (allocation) спільного ресурсу. Яким це чином робиться стандарт не описує, але сам підхід використання надання вже  є великою частиною вирішення цієї задачі. Зрештою, керування та контроль зайнятості ресурсу може вирішуватися зміною та перевіркою звичайної властивості об’єкту, що ми неодноразово використовували у своїх проектах. У каркасі PAC Framework ми також використовуємо механізм Allocation. Технологічні змінні займають для себе спільний ресурс з ексклюзивним доступом – канал контролера. Це дає змогу «перекидати» канали, не змінюючи програму в ПЛК. Незалежно від об’єкта керування нижній рівень модулів керування (CM) включає в себе три під-рівні (рис.2).

рис.2. Ієрархія CM

У стандарті кожний апаратурний об’єкт відповідає за процедурне (технологічне) і базове керування, що є його частиною, а взаємодія між процедурами відноситься до координаційного керування. Це спрощує побудову розподіленої системи керування. На одному з об’єктів (система поливу теплиць) в системі керування було закладено більше десятка ПЛК, кожен з яких відповідав за певну функціональну частину установки. Представник замовника (інжинірингова компанія) пропонував зробити з усіх ПЛК крім одного – центрального, – розподілені засоби вводу/виводу. Враховуючи потенційну можливість надмірного об’єму необхідної пам’яті та часу циклу, а також можливі проблеми з живучістю, ми вирішили побудувати систему за іншим принципом – функціонально розподілену. Відверто кажучи, для нас це був перший досвід, де в межах однієї технологічної комірки будувалася розподілена система з такою кількістю зв’язаних між собою ПЛК. Однак, зробивши відображення (mapping) ієрархії устатковання відповідно до IEC-61512 на ці ПЛК, все стало логічним і зрозумілим. Така структура зробила з кожної ділянки самостійну підсистему, що схоже на підходи DCS та відповідає принципам розподіленості в кібер-фізичних системах Індустрії 4.0. Взаємодія між апаратурними об’єктами в ПЛК була реалізована через промислову мережу (команди, статуси, властивості Allocation). Автономність контролерів зробила можливим перевіряти кожен функціональний вузол окремо і надало живучості системи. Механізм Allocation дав змогу вирішити проблему одночасності доступу до того самого апаратурного об’єкту. Звісно, там були інші трудності, пов’язані з проблемами відлагодження взаємодії на рівні рецепту «на дому», оскільки потребувало наявності всіх ПЛК. Однак, це є ціною усіх розподілених систем керування на базі ПЛК. 

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

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

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

Процедурне керування відповідає базовим принципам об’єктно-орієнтованого програмування. Одна і та сама процедура може бути використана в багатьох екземплярах.

У PAC Framework ми означили свій рушій (engine) для процедури, який забезпечує базову функціональність автомату станів, описану в IEC-61512. У свою чергу кожен стан вміщує кроки, змінну часу виконання кроку, змінну часу стану процедури а також налаштування уставок максимальних та мінімальних інтервалів виконання. По суті, усі необхідні базові налаштування були завжди під рукою, достатньо було їх використати у потрібному місці. З самого початку ми вагалися, чи закладати в процедури функціональність, яка початково не була затребуваною. Дуже скоро ми неодноразово переконалися в тому, що треба обов’язково
реалізовувати весь функціонал з самого спочатку .

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

Майстер-рецепти та керівні рецепти. Багато рецептурних виробництв не потребують зміни процедури, а тільки зміни параметрів, яка в термінах IEC-61512 зветься формулою. У цьому випадку класичним для систем АСКТП є використання рецептів, які є наборами записів з певною назвою, що за необхідності записуються у задані параметри процесу. Ми вирішили, що і для цього випадку використання двох типів рецептів — майстер-рецепту та керівного рецепту матиме переваги. Зокрема, можна змінити керівний рецепт під час його використання, не змінюючи прототип в «бібліотеці». За потребою можна  замінити налаштування майстер-рецепту параметрами з керівного. Ми застосовували цей механізм на всіх об’єктах, які потребували рецепти, як зі зміною так і без зміни процедури.

На одному з об’єктів цукрової промисловості (вакуум-апарати) параметри керівного рецепту а також вся інформація про запуск та зупинку варки (партії) фіксувалися в базу даних. Цей досить простий механізм дав можливість проаналізувати коли і за яких технологічних параметрів проходила варка (рис.3).

рис.3. Фіксації параметрів керівних рецептів

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

У наших проектах практично не було необхідності означувати режими для процедурних елементів, бо не потребувалася ця функціоанальність. У той же час, означення станів для процедурного керування дала можливість реалізувати чіткі алгоритми поведінки, в залежності від ситуації. Отримавши в ТЗ опис алгоритму, який по суті не визначав і 50% усіх ситуацій, ми задавали питання технологам, «а що буде коли … ?». Зрештою, ми створювали таблиці з переліком станів процедурних елементів, дій, які необхідно робити в цих станах, і умови переходу в інші стани. Заповнивши такі таблиці ми отримували добре формалізований алгоритм, який можна було змінювати достатньо просто і на папері і в програмі.

Стани і режими для базового керування використовувалися нами і до знайомлення зі стандартом. Однак, як виявилося, стано-орієнтоване програмування для багатьох програмістів АСКТП є диковинкою а інколи і неприйнятною ідеологічно. Це дуже дивно, так як важко побудувати програму з послідовностями дій без означення станів. Кроки – як один із елементів стану (підстан) використовується нами повсякмістно. Хоч стандарт не потребує означення кроків в середині процедурного і базового керування, ми вважаємо це хорошою практикою.

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

Для режимів і станів ми використовуємо правила поширення. Як і в багатьох випадках, стандарт тільки оговорює факт можливості поширення, але це вже спричинює необхідність означення цих правил. Так, наприклад, аварійні стани поширюються на апаратурні об’єкти вгору за ієрархією, а режим – вниз. Це значить, що усі тривоги відслідковуються на рівні всієї технологічної комірки (для кожної категорії відповідно до ISA-18.2) а зміна технологічного вузла в режим «ручний» приводить до переведення в ручний режим усіх підлеглих апаратурних об’єктів.          У першому проекті, розробленому згідно IEC-61512 ми використовували стандартний автомат станів, який означений в 1-й частині стандарту. У цьому автоматі процедура переходить зі стану “Idle” в стан “Running”, і якщо процедура завершилася – в стан “Complete”. Враховуючи, що об’єкт мав складні алгоритми запуску і завершення нам не вистачало додаткових проміжних станів, які ми добавили в автомат (рис.4). До речі, ми були не першими, подібні модифікації зустрічаються у статтях, а також  у версії ISA-88 2010-го року.

рис.4. Фрагмент зміненого автомату станів

Використання анімації стану при візуалізації (кольором або підсвічуванням) дало можливість значно підвищити ситуаційну обізнаність.

рис.5. Фрагмент дисплею запуску рецепту

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

Під час впровадження перших проектів ми мали певний негативний досвід, який врахували в наступних проектах. Зокрема, перший проект містив повний набір операторських команд зі стандарту: START, STOP, PAUSE, RESTART, HOLD, RESUME, ABORT, RESET (рис.6). Оператори часто плуталися, наприклад натискали ABORT замість STOP. Окрім надмірної кількості команд, було ще кілька причин:

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

У наступних проектах ми об’єднали команди, що схожі за призначенням (START, RESTART, RESUME), ввели обмеження на доступ до особливої команди ABORT, прибрали команди HOLD та PAUSE в процедурах, де вони не були передбачені.   

Звіти по виробництву партії, простежуваність. Однією із найбільших переваг впровадження стандарту – це спрощення реалізації формування архіву та звітів по виробництву партії, яка допомагає внутрішній простежуваності процесів виробництва. Стандарт вказує на те, які дані слід зберігати, яким чином організовувати логічне зв’язування записів. Четверта частина стандарту «Batch Control Part 4: Batch Production Records» детально описує необхідну структуру записів при потребі обміну записами між різними підсистемами. У своїх проектах у нас не було необхідності такого обміну, тому ми реалізовували архівування в зручному і достатньому для нас вигляді.

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

У одному з проектів архівування даних проводилося безпосередньо на ПЛК. Це може здатися дивним, але виявилося, що зберігати дані по партії в ПЛК зручніше ніж в SCADA/HMI. Інша справа –  формування звітів за цими даними. У тому проекті файли за необхідності копіювалися на ПК, де аналізувалися в Excel з використанням скриптів VBA. Тоді це було найшвидшим рішенням, але зараз у нас є інше бачення рішення для такого типу задач. У іншому проекті усі дані окрім рецептурних писалися в SCADA класичними способами: тренди додатково включали номер кроку, журнали подій включали події змін станів процедурних елементів. У окрему таблицю БД додатково зберігався запис керівного рецепту. Це дало можливість достатньо просто реалізувати онлайн звіти, як показані на рис.7. Тренди виводилися за вказаний період з початку до кінця виготовлення партії.

рис.7. Онлайн звіт по варці.

Зробивши кілька проектів з використанням елементів стандарту означених в IEC-61512 ми зробили наступні висновки:

  • стандарт повинні знати усі спеціалісти з автоматизації технологічних процесів та виробництв, так як він вміщує методологічні засади побудови алгоритмічного та програмного забезпечення систем керування;
  • впровадження стандарту не обов’язково повинно бути повним, не всі виробництва цього потребують 
  • ми виділили основні ключові моменти, які повинні стати базовими для всіх систем: відділення процедурного керування від базового, означення режимів і станів, означення чіткого автомату станів для процедурних елементів, означення ієрархії устатковання, наявність керівних рецептів та майстер-рецептів для рецептурного виробництва;    
  • реалізація стандарту можлива без використання спеціалізованого ПЗ, хоча останнє може значно зменшити трудозатрати та збільшити функціональність; 
  • реалізація стандарту можлива навіть з використанням ресурсів ПЛК «середньої канальності» (наприклад S7 1200, Modicon M241) 
  • за умови використання керівних рецептів простежуваність процесів в межах технологічної комірки реалізовується досить просто стандартними засобами SCADA та PLC

2. Про досвід впровадження інших колег.

Нам, на жаль, особисто не відомі колеги, які впроваджували свої системи керування згідно стандарту IEC 61512. Враховуючи наші активні пошуки, ми можемо зробити два припущення: 1) таких людей в Україні мало і вони не є публічними, що, до речі, дуже характерно для автоматників; 2) таких людей в Україні немає, або вони працюють виключно за кордоном. 

Ми чули певні відгуки автоматників, що обслуговували такі системи. Зокрема, вони виділяли зручність і багатофункціональність. Двічі нам зустрічалося наслідування чужих проектів, що базувалися на  IEC 61512. Дотепним був той факт, що ці проекти протиставлялися стандарту IEC 61512. Тобто, на нашу фразу «Такі системи робляться за стандартом ISA-88 (IEC 61512)» відповідали приблизно так «То все теорія, а от подивіться як роблять практики!». Це черговий раз показує скептичне відношення спеціалістів з автоматизації до стандартів, при цьому наслідуючи готові чужі реалізації. 

Тим не менше, один наш колега по цеху, Ярослав Люлько із ТОВ Сілоджик Груп, мав досвід впровадження хоч і не самого IEC 61512, то хоч специфікації PackML (вірніше концепції OPL що на ній основана), яка у свою чергу базується на ISA-TR88.00.02 Machine and Unit States: An Implementation Example of ISA-88 (2008). Ми взяли в нього інтерв’ю, яке повністю можна прочитати за посиланням . Також про технічні деталі впровадження Ви можете подивитися на відео запису з його виступу на ТДА16-2 . Нижче коротко наведемо основний зміст інтерв’ю.

Основне призначення впровадження системи керування згідно концепції OPL на вказаному підприємстві – було контроль роботи лінії на предмет виявлення вузьких місць. Лінія включала різне устатковання: рецептурні станції, дозувальні станції, CIP-станції, пакувальні машини, печі, охолоджуючі тунелі і ін. Використання PackML зрештою потрібне було для розрахунку виробничих KPI, зокрема OEE. Для цього для технологічного устатковання було забезпечено  передачу:  

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

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

Ярослав виділяє наступні переваги використання PackML:

  1. термінологія: коли різні розробники розуміють певні поняття однаково;
  2. певний ієрархічний порядок проекту: швидко орієнтуєшся у чужому коді;
  3. модульність: розробка програми базується на комбінації певних модулів (шматків коду, блоків);
  4. інтегрованість: підхід до проекту з думкою про те, що він має бути готовим як до горизонтальної так і до вертикальної інтеграції.
  5. економія часу: «замовник зекономив би велику кількість часу та ресурсів, якби всі Unit`и на його виробничих лініях були розроблені згідно стандарту PackML»

Ярослав використовує певний «скелет» для своїх проектів ПЛК.  Код цього проекту взаємодіє з даними стандарту PackML заповнюючи їх, або ж, у разі необхідності, до звертаючись до них (деталі за посиланням ).

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

Ярослав вважає, що автоматнику обов’язково потрібно знати основи стандарту ISA-88 (IEC-61512). «У стандарті зібрані найкращі практики світових лідерів автоматизації, тому треба використовувати ці напрацювання. Як результат –  проекти будуть більш структуровані, гнучкі та функціональні».

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

3. Використання в навчальному процесі.

Ми усвідомлюємо той факт, що стандарт не може впроваджуватися в Україні автоматниками без підготовки та перепідготовки спеціалістів. З 2016-го року на кафедрі АКТСУ Національного університету харчових технологій у навчальний процес був впроваджений курс по керуванню порційним виробництвом, матеріали якого доступні за посиланням. У 2017-му та 2018-их роках ми також проводили 2-дневні курси по підготовці спеціалістів по ISA-88 (IEC-61512), матеріали для яких доступні за цим посиланням. У цьому підрозділі ми поділимося досвідом проведення цих курсів, та думками щодо подальшого їх вдосконалення.

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

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

  1. Явні скептики використання стандартів після курсів почали відноситися до даного стандарту як до кращих практик.
    • Кілька досвідчених спеціалістів, які розробляли багато великих та складних проектів, відкрили для себе автомат станів. Це було видно за їх реакціями і відгуками. Якби дати оцінку корисності підходів, які дає стандарт, автомат станів мабуть зайняв би перше місце.   
    • Важко сприймався, але з часом ставав нормою для слухачів принцип відокремлення технології від устатковання, і відповідно процедурного керування від базового.
    • На курсах були слухачі, що мали певні представлення про Batch Control. Їх цікавили питання підходів щодо визначення процедурних елементів та виділення устатковання (апаратурних об’єктів). На той час у нас не було такого досвіду, наразі є певні напрацювання, однак вони потребують певної формалізації.
    • На курсах необхідно піднімати складні питання, які краще допомагають зрозуміти сутність ключових понять. Наприклад, було питання типу: «Чи є пастеризатор технологічним вузлом порційного типу і чому?», навколо якого піднялася цікава дискусія.
    • Слухачі пропонували цікаві пропозиції, які перекликаються з викладеними в розділі 4 даної книги. Це черговий раз доводить необхідність таких семінарів, де спеціалісти можуть спільно вирішити ряд насущних задач.   
    • На курсах було мало практичних занять, з іншого боку – він був пересичений лекційним матеріалом. З цього можна зробити висновок, що курс треба робити більшим (4 або 5 днів) але обов’язково з практичними заняттями.

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

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *