7. Збір даних

Пупена О.М.
Клименко О.М.
Міркевич Р.М.

Повернутись на початок

Попередня діяльність передбачає обмін даними в реальному часі з устаткованням з метою керування та контролю виконання на них завдання. Окрім цього, для задач аналізу в стандарті передбачається також збір даних основного виробництва (Production Data Collection) – набір діяльностей, що займаються збором, архівуванням, упорядкуванням та керуванням виробничими даними для конкретних робочих процесів або конкретних виробничих запитів. Виробничі системи керування, як правило, оперують:

  • даними про процес, таким як кількість (вага, штуки тощо), властивість (швидкість, температура тощо);
  • інформацією про устатковання, такими як стан контролера, датчика, пускача, тощо.

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

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

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

Рисунок 35 – Інтерфейси моделі збору даних основного виробництва

Завдання збору даних основного виробництва можуть включати:

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

Збір даних може бути реалізований через формування таблиць в реляційних базах даних. У Momentum, наприклад, за цю діяльність відповідає окремий сервер DMS (Data Mining Server). При конфігуруванні означуються пакети (Package), які будуть відповідати однойменним таблицям в базі даних (рис.36). Для кожного пакету конфігуруються поля, які відповідають полям записів в таблиці бази даних.    

Рисунок 36 – Приклад налаштування пакетів даних

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

Рисунок 37 – Приклад налаштування збору даних для пакетів

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

Рисунок 38 – Приклад налаштування збору даних для робочих центрів

8. Аналіз ефективності.

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

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

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

На рис. 39 показана взаємодія з іншими діяльностями керування основним виробництвом.

Рисунок 39 – Інтерфейси моделі діяльності аналізу ефективності основного виробництва

Аналіз ефективності основного виробництва може включати кілька етапів:

  • підготовку звітів про результати діяльності та вартість;
  • оцінку обмежень на потужність та якість;
  • проведення випробувань на працездатність, де це необхідно для визначення потужності;
  • порівняння різних виробничих ліній та створення середніх або цільових показників виробничих циклів;
  • порівняння та протиставлення показників виробничих циклів;
  • порівняння виробничих циклів для виявлення “золотих”;
  • визначення того, чому “золоті” виробничі цикли є винятковими;
  • порівняння виробничих циклів із визначеними «золотими»;
  • надання змін до процесу та процедур на основі результатів аналізу для подальшого вдосконалення процесу;
  • прогнозування результатів виробничого циклу на основі поточних та минулих показників; це може включати генерацію виробничих показників;
  • співвіднесення вимог в сегментах продукту з дійсними умовами проходження процесу на момент виробництва.

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

KPI. Типовими і найпростішими способами аналізу є формування показників ефективності,  відображення їх на консолях керування з ціллю оцінки оператором. На додаток до формально означеної моделі даних про ефективність, означеної в IEC 62264-2, є додаткова інформація про операції, що надає підсумки ефективності в минулому, вказівки на майбутнє виконання або показники можливих майбутніх проблем. У сукупності ця інформація визначається як KPI (КПЕ, ключові показники ефективності). Для формування таких показників необхідна інформація про виробничі цикли, статуси устаткування, дані про використання ресурсів, які надаються з функції збору даних (див.рис.39). Крім того, для розрахунку KPI потребуються їх означення, які можуть бути закладені як в ресурсах так і в означенні продукту. Нагадаємо, що перелік рекомендованих KPI затверджено в стандартах ISO 22400, який також прийнято в Україні методом підтвердження. З деякими деталями ви можете ознайомитися на сайті www.tk185.appau.org.ua            

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

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

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

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

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

На прикладі Momentum розглянемо, як може проводитися процес формування та виведення показників ефективності для робочого центру. Перш за все, в сервері DMS для конкретного робочого центру створюються пакети, що використовуються для KPI, зокрема (див.рис.38):

  • Availability Package;
  • Performance Package;
  • Quality Package;
  • Golden Runs Package

Ці пакети забезпечують розрахунок та збереження даних за відповідними показниками. Ця інформація доступна як за запитом з іншої підсистеми Momentum, так і з панелі  оператору, на якому OEE доступні з вбудованих Dashboard і містять наступну інформацію (рис. 40):

  • Availability (Доступність), продуктивність (Performance), якість (Quality) і OEE
  • Total operation duration (Загальна тривалість операції)
  • Active period (Активний період)
  • Speedloss (Втрата швидкості)
  • Downtime (Простої)
  • Час початку і закінчення періоду
  • Loss reasons (причини втрати)

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

Рисунок 40 – Приклад відображення OEE в Momentum

Для аналізу причин поганої ефективності можна використати інше вікно робочого центру – Performance (рис.41). На таких графіках можна побачити як в часі змінювалася продуктивність операції. Ця діаграма складається з 2 ліній:

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

Ця діаграма може мати кілька горизонтальних прямих ліній:

  • Max rate – представляє максимальну продуктивність робочого центру;
  • Scheduled rate – показує заплановані (очікувані) показники; він розраховується як кількість операцій, поділена на планову кількість;
  • Speed ​​loss – коли середня продуктивність падає нижче цього рівня, цей період вважається періодом втрати швидкості;
  • Downtime – коли середня продуктивність падає нижче цього рівня, цей період вважається періодом простою;
Рисунок 41 – Приклад аналізу ефективності в Momentum

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

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

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

Простежуваність ресурсів має два компоненти – стеження та простежування.

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

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

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

Аналіз процесів забезпечує зворотній зв’язок щодо конкретних виробничих процесів у кількох виробничих циклах або партіях. Ця інформація використовується для оптимізації або модифікації конкретних виробничих процесів. Діяльність включає аналіз поганих виробничих циклів для визначення першопричини та аналіз виробничих циклів виняткової якості для визначення оптимальних умов експлуатації. Аналіз процесів часто включає SPC/SQC аналіз та моделювання процесів і використовує інформацію, зібрану з декількох видів діяльності, які вимірюють робочі параметри.

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

6. Диспетчерування та керування виконанням

Пупена О.М.
Клименко О.М.
Міркевич Р.М.

Повернутись на початок

Діяльності календарного детального планування не включають в себе роботи по керуванню ресурсами, вони тільки передбачають їх використання в певні моменти часу. Для виконання запланованих завдань необхідно їх направити на робочі центри, в яких виділити необхідні ресурси та забезпечити запуск та завершення усіх робіт, передбачених і не передбачених в означенні роботи. Згідно стандарту IEC 62264-3 це включає дві взаємопов’язані діяльності: диспетчерування та керування виконанням.      

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

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

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

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

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

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

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

Диспетчерування виробництвом взаємодіє з іншими діяльностями через різні інтерфейси (див.рис.30).

Рисунок 30 – Інтерфейси моделі діяльності диспетчеризації виробництва

Як видно з рис.30 диспетчерування передбачає відправлення виробництву на виконання списку завдань (Job List). Завдання визначають конкретні елементи роботи, які слід виконувати в робочих центрах та робочих вузлах. Кожен пункт списку завдань повинен включати час або подію для початку діяльності.

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

На рисунку 31 показаний приклад календарного плану робіт та списку завдань, представлених у форматі діаграми Ганта. Список завдань тут показаний у вигляді набору завдань для цеху у певний відрізок часу. У той же час список завдань може бути означений для певної групи ресурсів на певний відрізок часу, наприклад на рис.30 показаний у вигляді детального календарного плану робочого центру.

Рисунок 31 – Зразок списку завдань

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

Рисунок 32 – Диспетчерування роботи засобів виробництва змішаного типу

У той час як диспетчерування передбачає тільки формування в конкретний момент часу списку завдань для робочих центрів та виділення необхідних ресурсів для цього, керування їх виконанням відповідно до OEC 62264 виконують інші діяльності. Керування виконанням виробництва (Production execution management) означується як сукупність видів діяльностей, що спрямовують на виконання роботи, що вказані в списку завдань. Це включає вибір, запуск цих робіт та переміщення (наприклад, партій матеріалу, підпартій матеріалу або партій) за допомогою відповідної послідовності дій з метою фізичного виготовлення продукту. Фактичне виконання роботи (ручне або автоматичне) є частиною функцій рівня 2.

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

На рисунку 33 показані як керування виконанням виробництва взаємодіє з іншими підсистемами.

Рисунок 33 – Інтерфейси моделі керування виконанням виробництва

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

Завдання керування виробництвом включають в себе керування та контроль виконанням робіт та ініціювання діяльності рівня 2 (АСКТП) відповідно до означеного завдання. Зокрема це передбачає створення настанов для роботи на основі шаблонів означення робіт, що є частиною завдання, та координування виконання.

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

Рисунок 34 – Вікно керування робочими центрами

Читати далі

5. Детальне календарне планування.

Пупена О.М.
Клименко О.М.
Міркевич Р.М.

Повернутись на початок

Слід розрізняти поняття «Планування» (Planning) та «Календарне планування» (Scheduling). Планування означується як діяльність з уточнення дій або операцій для досягнення поставленої мети та резервування достатньої кількості ресурсних потужностей для досягнення мінімальних цілей. Календарне планування означується як діяльність з розподілу дій та операцій на конкретні ресурси в конкретний час з урахуванням різних фактичних обмежень та оптимізації декількох параметрів оцінки.

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

Рисунок 16 – Схематичне співвідношення планування та календарного планування

Відмінності між плануванням (об’ємним) та календарним плануванням у видах результатів, які пов’язані з різними аспектами концепцій часу. При плануванні (Planning) основними результатами будуть цільові кількості, які застосовуються протягом певного періоду часу. Результати планування представлені в дискретному масштабі часу як періоди. Прикладами результатів планування можуть бути “50 000 одиниць товару цього місяця”, “продажі на $480 000 наступного місяця”, “підсумок понаднормових годин на наступний тиждень” тощо. Результати календарного планування (Scheduling) представляють конкретні строки дій, наприклад, час початку та час завершення операції, час видачі запасів, час доставки тощо. Результати інформації про послідовність операцій представлені у безперервній шкалі відносного або абсолютного часу. Прикладами результатів календарного планування можуть бути “9:00 понеділка виконання робочого замовлення 2345”, “9:00 в середу виконуйте профілактичне обслуговування на E887e”.

У результаті календарного планування на 4-му рівні (ERP) формується виробничий календарний план (Operations schedule) для конкретного виробничого майданчику (див.рис.17). Цей план складається з виробничих замовлень (Operation request) на певний продукт чи інші операції (може включати кілька операцій різної категорії, наприклад обслуговування).

Виробничі замовлення  можуть включати:

  • запланований час початку операції, зазвичай використовується, якщо план керується системою календарного планування;
  • запланований час завершення операції, зазвичай використовується, якщо MOM контролює дотримання термінів виконання;
  • пріоритет замовлення, зазвичай використовується, якщо точна почерговість виробництва не запланована ззовні.
Рисунок 17 – Календарний план на виробничий майданчик

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

  • “змішаний” виробничий календарний план може містити змішані або спеціалізовані виробничі замовлення,
  • “змішане” виробниче замовлення може містити змішані або спеціалізовані вимоги до сегмента,
  • “змішані” вимоги до сегмента можуть обробляти декілька специфікацій ресурсів, які зазвичай з’являються в спеціалізованому сегменті.

На рисунку 18 показані вимоги до сегмента:

  • рухи матеріалу, необхідні для виконання відповідної операції (категорія операцій з виробничими запасами);
  • ресурси для основного виробництва; інформація про матеріал повинна містити відпущений матеріал та інші матеріали, перенесення яких не потрібно було б уточнювати (рідина, наявна у нерухомих трубах);
  • ресурси, пов’язані з якістю, які залучаються під час або в кінці виробничої операції.
Рисунок 18 – Приклад виробничих замовлень на змішані операції

У системі Momentum, виробничі замовлення (називаються Customer Order) можна отримати з системи ERP або добавляти вручну. При цьому вибирається кінцевий продукт,  необхідна його кількість, очікуваний та максимальний час завершення виготовлення (рис.19).

Рисунок 19 – Приклад виробничого замовлення в Momentum

Згідно стандарту, кожне виробниче замовлення відправляються у вигляді набору робочих замовлень (Work request) на певний цех (див. рис.20).

Робочі замовлення  можуть включати:

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

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

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

Рисунок 20 – Приклад створення календарного плану виконання робіт на цех

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

Завдання націлені на конкретний робочий центр. Якщо цей робочий центр є порційного типу (технологічна комірка), то завдання відповідає конкретній партії продукту (Batch), як це означено в IEC 61512 [8].  

Календарний план робіт пов’язує фізичну та/або хімічну обробку (процеси) з конкретним виробничим устаткованням або класами виробничого устатковання, з конкретними стартами або початковими подіями. Зазвичай цей зв’язок виконується через завдання (job order). Календарний план робіт може посилатися на конкретний персонал або класи персоналу. Завдання має наступні атрибути:

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

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

Для прикладу, в Momentum, при плануванні, виробничі замовлення спочатку діляться на робочі замовлення (Work Order) відповідно до сегментів продуктів. Це процес відбувається автоматично. Далі робочі замовлення плануються на певні робочі центри, відповідно до процесів, які вони можуть виконувати (рис.21). Це може відбуватися як автоматично так і вручну. Примітка: у попередній версії стандарту IEC 62264 «Job Order» мало назву «Work Order».

Рисунок 21. Приклад календарного плану виконання робіт

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

Рисунок 22. Стани робочих замовлень

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

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

Рисунок 23 – Інтерфейси моделі діяльності детального календарного планування виробництва

Задачі детального календарного планування виробництва можуть включати:

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

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

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

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

Підсистема календарного планування одна з найскладніших, оскільки може використовувати різні обчислювальні алгоритми та нерідко включають методи «ноу-хау». Сьогодні ряд компаній використовують методи APS-планування, які передбачають багаторівневе календарне планування на усіх рівнях керування з перерахунком. Така підсистема присутня також в вітчизняній ERP/MES ITenterprise, яка успішно використовується на багатьох підприємствах.

У системі Momentum автоматичне планування створює робочі замовлення і розподіляє їх по робочих центрам (називаються операціями). Коли розрахунок замовлення йде автоматично  відкривається вікно Schedule automatically, де ви можете переглядати робочі завдання і маніпулювати критеріями планування (рис.24). Автоматичне планування дозволяє встановити критерії оптимізації і угруповування. Планувальник оптимізує рішення на основі обраних критеріїв і їх важливості.

Рисунок 24 – Приклад вікна вибору критеріїв автоматичного планування

Процес планування виглядає наступним чином:

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

Поточний крок планування і всі інші кроки можна побачити в файлі журналу під час проведення  планування (рис.25).

Рисунок 25 – Приклад вікна відображення статусу розрахунку календарного плану для вибраного виробничого замовлення

Календарний план виробництва може бути поділений або об’єднаний для відправлення на диспетчерування. Ліва частина рисунку 26 ілюструє, як один календарний план поділяється на декілька, а права – як кілька календарних планів виробництва з різних джерел можуть бути об’єднані в один. Як приклад, декілька денних календарних планів робіт можна отримати з календарного плану на тиждень. Так само можливе об’єднання декількох  календарних планів для зменшення кількості запусків чи очищення устатковання.

Рисунок 26 – Поділ та об’єднання календарних планів виробництва до календарних планів робіт

Рисунок 27 показує приклад календарного плану робіт устатковання, представленого у форматі діаграми Ганта. Така форма є досить зручною для представлення календарного плану і використовується у більшості MES/MOM, зокрема в Momentum (див.рис.21). У даному випадку на рис.27 кожен прямокутник (завдання) на рисунку має певне забарвлення, відповідно до робочого замовлення, в якому воно приймає участь.

Рисунок 27 – Календарний план робіт

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

Рисунок 28 – Взаємодія детального календарного планування

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

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

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

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

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

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

Читати далі

4. Означення продукту

Клименко О.М.
Пупена О.М.
Міркевич Р.М.

Повернутись на початок

Керування означенням продукту – це набір діяльностей, які керують інформацією рівня 3, що потребується для виготовлення продукту, включаючи виробничі інструкції. Вона повинна бути відомою як на рівні 4 для потреб планування так і на рівні 3 для детального календарного планування, диспетчерування та керування виконанням (рис.10).

Рисунок 10 – Інтерфейси моделі керування означенням продукту

Завдання керування означеннями продукту можуть включати:

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

Існує три основні області інформації, необхідні для виробництва конкретного продукту, які мають кілька точок перетину (див. рис.11). Виробнича інструкція для продукту (Product production rules) – це інформація, яка містить вказівки на те, яким чином виготовити продукт. Прикладами виробничої інструкції є загальний, місцевий або майстер рецепт (означені в МЕК 61512-1), дані про продукт ПП (прикладний протокол), означений в ISO 10303-1, стандартна операційна процедура (SOP), стандартні умови експлуатації (SOC), маршрутизація або складання кроків на основі виробничої стратегії. Відомість матеріалів (Bill of material) – це список усіх матеріальних ресурсів, необхідних для виготовлення продукту із зазначенням кількості. До списку можуть входити сировина, проміжні матеріали, вузли, деталі та витратні матеріали. У відомості матеріалів не вказується місце та час використання матеріалів, проте цей документ може бути організований ієрархічно, що відображає деякі етапи виготовлення продукту. До складу відомості матеріалів часто входить матеріал, який не пов’язаний з виробництвом продукту, наприклад, допоміжні матеріали для відвантаження або включена документація. Відомість матеріалів – це частина відомості ресурсів. Виробнича відомість – це підмножина відомості матеріалів, яка пов’язана з виробництвом. Відомість ресурсів (Bill of resources) – це перелік усіх ресурсів, необхідних для виробництва продукту. До ресурсів можуть входити матеріальні ресурси, персонал, технологічне устатковання, енергетичні ресурси та витратні матеріали. Відомість ресурсів не містить конкретних етапів виробництва, проте цей документ також може бути організований ієрархічно, що відображає деякі етапи виробництва.

Рисунок 11 – Означення інформації про основне виробництво

Сегмент продукту (Product Segment) – це інформація, яка відображає точки перетину між виробничою інструкцією продукту та відомістю ресурсів. Сегмент продукту описує завдання та задачі, що складаються з одного або декількох робочих елементів, які зазвичай виконуються в одному місці. Сегмент продукту – це найбільш детальний вигляд процесу керування матеріальними ресурсами, трудовими ресурсами, використанням ресурсів, затратами та якістю з метою керування виробництвом з точки зору бізнес систем. Сегмент продукту ідентифікує, посилається або відповідає сегменту процесу. Цей взаємозв’язок проілюстрований на рисунку 12.

Рисунок 12 Відношення сегмента продукту до сегмента процесу

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

Сегменти продукту можуть відповідати:

  • стадіям технологічного процесу МЕК 61512-1, технологічні операції, процедури апарата або операції з виробництва партії;
  • виробничим операціям для неперервного виробництва;
  • етапам збірки та дій збірки для дискретного виробництва;
  • іншим типам ідентифікованих часових інтервалів для інших видів виробництва.

Сегменти продукту можуть включати в себе інші сегменти, як це показано на рис.13. Кожен прямокутник відповідає окремому сегменту продукту.

рис.13. Вкладеність сегментів продуктів

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

Таким чином, сегменти продукту формують означення ланцюга послідовностей сегментів процесу для створення конкретного продукту. Ці сегменти процесу можуть, наприклад, включати в себе  робочі центри, в яких буде вироблятися продукт, задіяний персонал та матеріали. У свою чергу, сегменти продуктів посилаються на шаблони означення роботи (Work master) та за необхідності на виробничу інструкцію, необхідну для реалізації.     Для прикладу, у середовищі Momentum сегменти продуктів діляться на типи, в залежності від їх особливостей (див.рис.14). Так, сегмент типу Consumer Unit (споживча одиниця) потребує матеріали, що виробляються в сегменті типу Intermediate (напівпродукт) та матеріли з сегменту Packaging material.

Рисунок 14 – Типи та зв’язки сегментів продукту

Кожен сегмент продукту має велику кількість параметрів, які вказують на правила та ресурси його створення (рис.15), зокрема:

  • Recipe – сегменти продукту і відповідно матеріали, які необхідні для виробництва відповідного продукту, тобто інгредієнти.
  • Inventory – зони зберігання, де зберігається продукт і всі партії матеріалу цього продукту для обраної зони зберігання.
  • <Process Name> – крок процесу, з яким пов’язано означення продукту. Тут ви визначаєте, які робочі центри використовуються і які параметри застосовуються для визначення продукту.
  • Equipment requirements – нижньорівневе устатковання, необхідне для виробництва цієї версії.
Рисунок 15 – Приклад сегмента продукту в Momentum

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

Керування означенням продукту може також включати керування іншою інформацією про продукт спільно з виробничою інформацією:

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

Читати далі

3. Означення устатковання

Клименко О.М.
Пупена О.М.
Міркевич Р.М.

Повернутись на початок

Наведені вище діяльності виконуються з прив’язкою до різних виробничих ресурсів. Для основного виробництва потрібні матеріали (з чого і що виготовляється), устатковання (на чому відбувається виробництво) та персонал. Для стандартів IEC 61512 та IEC 62264 спільним є представлення моделі рольової ієрархії устатковання (рис.3). Відповідно до цієї ієрархії кожне устатковання (equipment, обладнання) виконує певну роль у процесі виготовлення продукції. Ієрархія устатковання є однією із наскрізних моделей для інтегрування усіх рівнів керування. Вона дає можливість зробити декомпозицію (розбивку на менші елементи) усіх діяльностей, та зосереджуватися на них при реалізації. У цьому розділі зосередимося на цьому типі ресурсів.

Рисунок 3. Рольова ієрархія устатковання підприємства

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

Принципи виділення устатковання для нижніх рівнів описано у роботі [8]. Функції рівня MOM оперують, як правило на рівнях від робочих вузлів до цехів, або виробничих майданчиків. У той же час діяльність 4-го рівня керування (ERP) зосереджена навколо підприємства та виробничих майданчиків. Підприємство (Enterprise) займає найвищий рівень в ієрархії устатковання, функції якого зосереджені на організаційних та фінансових питаннях. Виробниче підприємство також відповідає за означення повного переліку того, які продукти, як і на яких виробничих майданчиках можуть і будуть виготовлятися. Виробничий майданчик (Site) – це фізичне, географічне або логічне об’єднання виробничих потужностей в межах одного підприємства. Підприємство може мати кілька виробничих майданчиків, які можуть знаходитися в різних локаціях, що об’єднані територіально і організаційно. Як правило, об’ємне ERP-планування проводиться для завантаження виробничих майданчиків, або цехів. Але на рівні 4 може відбуватися також оперативне календарне планування з використанням устатковання нижчого рівня. Тобто, як правило, календарний графік-план виконання операцій (наприклад, виготовлення конкретної продукції) рівня ERP спускається на виконання для виробничого майданчика.               

Цех (Area) – є частиною виробничого майданчику, який може виготовляти певний набір продуктів, напівпродуктів або серівісів. Цеха, як правило, мають чітко означені виробничі потужності, які використовуються для оперативно-календарного планування рівня 3 (MOM) та рівня 4 (ERP). Операції виробничого майданчика при детальному плануванні формують робочі замовлення, які виконуються в конкретних цехах.      

Робочі центри (Work Centers) – це елементи ієрархії технологічного устатковання в межах цеху, які роблять або зберігають певний напівпродукт. Робочі центри мають чітко означені продуктивності та потужності, і вони використовуються для функцій рівня 3. Потужність та продуктивність робочих центрів також часто використовуються як вхід для бізнес-процесів рівня 4. Саме в робочих центрах проводяться необхідні заплановані завдання, для яких означуються роботи, які треба проводити. У свою чергу, робочі центри мають устатковання для виконання завдань, які називають робочими вузлами (Work Unit). Планування та виконання операцій повинно враховувати тип виробництва, яке використовується в конкретному робочому центрі. Стандарт передбачає використання конкретних термінів для робочих центрів та робочих вузлів, які застосовуються до порційного, неперервного чи дискретного виробництва, а також для зберігання та переміщення матеріалів. Загальні терміни «робочий центр» та «робочий вузол» використовуються в стандарті лише в тих випадках, коли його тип для цілі обговорення не має значення.

У стандарті передбачені наступні типи робочих центрів і робочих вузлів (див.рис.3):

  • Виробничий вузол (Production Unit) і технологічний вузол (Unit) для неперервного виробництва;
  • Виробнича лінія (Production Line) та робоча комірка (Work Cell) для операцій дискретного виробництва;
  • Технологічна комірка (Process Cell) та технологічний вузол (Unit) для операцій порційного виробництва;
  • Зона зберігання (Storage Zone) та вузол зберігання (Storage Unit) для операцій збереження та переміщення матеріалів.

Виробничий вузол, як правило, включає все технологічне устатковання, що необхідне для сегменту неперервного виробництва, яке працює відносно автономно. Він, як правило, перетворює, відокремлює або реагує на один або кілька вхідних матеріалів для виготовлення проміжних або кінцевих продуктів. Виробничий вузол часто виділяють за основним технологічним процесом або сімейством напівпродуктів, що виготовлюються на ньому. Приклад налаштування виробничого вузла для MOM Momentum (BrightEye) показаний на рис.4. Для нього вказуються технологічні процеси, які можуть виконуватися, виробнича продуктивність (задається двома параметрами Capacity та Time period), buffer Duration, що вказує на додаткове ємнісне запізнення між подачею матеріалу на вхід та формування виходу. Ці параметри враховуються при детальному календарному плануванні. Зокрема технологічний процес дає можливість вибрати робочий центр, який забезпечує його проходження на певному етапі виготовлення конкретного продукту, а часові налаштування  – максимальну продуктивність та затримки.

Рисунок 4. Приклад налаштування робочого центру типу Виробничий вузол (Production unit)

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

Рисунок 5. Приклад налаштування робочого центру типу Виробнича лінія (Production line)

Технологічні комірки та технологічні вузли використовуються для проведення технологічних процесів порційного виробництва. Якщо існує достатня гнучкість для маршрутизації продукту в межах технологічної комірки, тоді для рівня MOM також означуються і технологічні вузли. Означення технологічних комірок та технологічних вузлів наводяться в МЕК-61512-1. Технологічну комірку часто виділяють за основним технологічним процесом або сімейством напівпродуктів, що виготовлюються на ньому. Технологічні комірки та технологічні вузли мають чітко означені виробничі продуктивності та потужності порційного виробництва, які використовуються функціями Рівня 3. На рис.6 показаний приклад налаштування технологічної комірки, для якої означуються мінімальні і максимальні розміри партій та тривалість партії (Batch Time). Ці налаштування використовуються при детальному календарному плануванні для розрахунку необхідного часу для виробництва партії, і кількість необхідних партій.

Рисунок 6. Приклад налаштування робочого центру типу Технологічна комірка (Process Cell)

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

Таблиця 1 – Приклади зони зберігання та вузла зберігання

Зона зберігання Вузол зберігання
Склад Стійка/стелаж /слот
Парк причепів Причіп, контейнер
Група танків Танк, секція труби, колектор, буфер
Група силосів Силос, секція труби, колектор, буфер
Причал, пристань Корабель, корабельний трюм, контейнер, бочка, танк
грузова станція, депо Залізничний вагон
Зона тимчасового зберігання Піддон, бочка

На рис.7 наведений приклад налаштування зони та вузла зберігання. Для вузла зберігання вказується місткість а також правила зберігання (фіксації руху речовини): Storage Rule = FIFO/LIFO/Proportional. Це дасть змогу правильно проводити планування та фіксацію переміщення речовини.

Рисунок 7. Приклад налаштування зони зберігання (Storage zone) та вузлу зберігання (Storage Unit)

Стандарт передбачає можливість розширення, тобто наявності в ієрархії устатковання інших типів робочих центрів, наприклад  лабораторія (використовується в операціях з контролю якості), парк мобільного технологічного устатковання, склад невикористаного технологічного устатковання (використовується в операціях з технічного обслуговування), транспортний центр. Коли додається новий тип, він повинен підтримувати ті ж зв’язки в ієрархії, що і означені типи робочих центрів (у межах цеху та містять робочі вузли). Набір взаємопов’язаного устатковання в рольовій ієрархії покажемо на прикладі молочного підприємства «Happy Milk», який виготовляє різноманітну молочну продукцію. Виробнича частина підприємства складається з різних виробничих і обслуговуючих виробництво цехів (рис.8). Бордовим кольором виділені назви процесів, що проробляються з матеріалами, чорним – використовуване устатковання.

Рисунок 8. Спрощена схема матеріальних потоків виробничих потужностей “Happy Milk”.

Сировина (сире молоко з ферм) надходить на підприємство в молоковозах на RECEPTION. Перед відвантаженням сировина перевіряється в лабораторіях, після чого надходить на пост відвантаження в танки сирого молока RAW Tank1 і RAW Tank2, які є вузлами зберігання. Молоко як сировина використовується для різних типів молочної продукції. В цеху RECEPTION & STORAGE проводиться його попередня очистка, термізація (виробничий вузол PAST), нормалізація і обробка для тимчасового зберігання в танках. Оброблене молоко різної жирності зберігається в танках зберігання (holding tanks), які є вузлами зберігання, звідки подається в інші цехи заводу. Цех включає в себе станцію CIP (технологічна комірка) для очищення устатковання цеху а також молоковозів. Цех MILKPROD призначений для виробництва продуктів з незбираного молока: молока і йогуртів різної жирності. Продукція розфасовується в різні види упаковок (у робочих комірках – фасувальних автоматах), після чого укладається в коробки (у робочих комірках – палетайзери), які передаються на склад. Крім цього цеху на підприємстві є і інші виробничі цехи, наприклад з виробництва сиру, масла, сухого молока. У зоні зберігання SHIPMENT (склад) упакована продукція вантажиться на палети і зберігається до моменту відвантаження. На рис.9 показаний фрагмент ієрархії устатковання з наведеного прикладу, реалізований у MOM-системі Momentum. Верхні три рівні (від підприємства до цеху) використовуються в основному для навігації, означення місцезнаходження, календарів та робочих годин. Інші рівні обмежуються в Momentum як правило робочими центрами та нижньорівневим устаткованням. Останні використовуються для зв’язку робочих центрів з рівнем АСКТП (на рис.9 «EQ_PAST1»). Параметри устатковання можуть мати за джерело даних змінні з Серверів OPC UA (на рис.9 FIQ1).

Рисунок 9. Приклад ієрархії устатковання “Happy Milk”

Продовження…

Принципи функціонування систем керування основним виробництвом через призму стандарту IEC-62264

Пупена О.М.
Клименко О.М.
Міркевич Р.М.

Вступ

Аналіз українського ринку [1] показав, що автоматизація виробничих операцій на вітчизняних підприємствах в найкращому випадку досягає 50%. При цьому більшість з цих операцій  автоматизовані за принципом дописування функцій на рівні АСКТП, в системах ERP (в кращому випадку) чи бухгалтерських системах типу «1С» (у гіршому). Інші реалізації, що зроблені в програмних продуктах класів MES, EAM/ТОіР, LIMS, важко інтегруються з іншими підсистемами, оскільки у більшості випадків одна з сторін не підтримує стандарт IEC-62264.

Така картина виглядає досить дивною, враховуючи що стандарти IEC-62264 вже з 2000-го року використовуються у всьому світі як єдиний каркас для цифрового підприємства. Ряд експертів вважають [1] ,що не зважаючи на дійсну необхідність і цінність стандартів IEC-62264, їх впровадження лежить у більшій мірі в області компетенцій постачальників інструментального програмного забезпечення класів MOM/ERP аніж інтеграторів. Тоді виникає питання, чи наразі потрібен IEC-62264? Ми вважаємо, що навіть за таких обставин стандарт може принаймні використовуватися для наступних цілей:

1. Враховуючи, що функції MOM можуть бути реалізовані в різних системах керування, зокрема в кінцевих засобах автоматизації (відповідно до ідеології розподіленості в Індустрії 4.0), IEC-62264 наряду з IEC-61512 вказує на правила їх функціональної організації. Це значить, що розробники сучасних I4.0 систем повинні будувати свої системи зі знаннями стандартів, які входять в базові (наприклад, відповідно до RAMI4 [1]).  Таким чином, стандарт IEC-62264 можна розглядати не тільки в якості уніфікації обміну між рівнями ERP та MOM/MES, а ще як правила побудови підсистем MOM взагалі.

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

З першого вересня 2019 з подання технічного комітету ТК-185 «Промислова автоматизація» ці стандарти діють на території України [2]-[6]. Вони прийняті методом підтвердження, тобто в англомовному варіанті. Практика прийняття методом підтвердження прискорює використання стандарту з юридичної точки зору, але його дійсне впровадження вимагає розуміння суті розробниками систем. Завдяки проекту aCampus членами ТК-185 перша частина стандарту була перекладена українською мовою, чорнова версія перекладу доступна за посиланням [7].  Представлення функціонування MOM зсередини наведено третій та четвертій частинах цього стандарту, переклад якої ще не зроблений. У даному посібнику функції MOM, які прийнято відносити до MES розглянуті саме через призму цих частин стандартів, що дасть змогу людям, які не обізнані в MES, зрозуміти призначення та організацію її діяльності.  

1. Функціональна структура MOM

Виробництво (Manufacturing) – це не тільки процес виготовлення продукції (Production). До виробничих діяльностей також відносяться операції по:

  • технічному обслуговуванню устатковання (Maintenance), зокрема ремонти, діагностування і т.п.;
  • керуванню якістю (Quality), зокрема проведення аналізів матеріалів, перевірка відповідності стандартам і т.п ;
  • керуванню запасами (Inventory), зокрема постачання сировини, логістика і т.п.;
  • та інші.  

Цими операціями на підприємстві як правило займаються різні служби (підрозділи) і для їх автоматизації часто використовуються різні програмні продукти. Але ці операції взаємопов’язані через спільні ресурси та завдання. Згідно стандарту IEC 62264 для кожної з наведених вище категорій виробничих операцій означена модель діяльностей (функцій). Це означає, що керування кожною з операцій зводиться до виконання наступних взаємопов’язаних діяльностей (рис.1):

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

Лінії зі стрілками на рис.1 вказують на інформаційні потоки між діяльностями.

Рисунок 1 – Загальна модель діяльностей керування виробничими операціями

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

Цикл керування операцією відбувається у наступній послідовності:

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

Виконання послідовності супроводжується наступними діяльностями:

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

Показана на рис.1 модель діяльностей, а також деталізація цієї моделі, що означені в частинах 3 та 4 стандарту IEC 62264 не призначені для реального впровадження виробничої інформаційної системи. Вони більше використовуються в якості каркасу для таких систем.

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

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

2. Модель керування операціями основного виробництва

На рис.2 показана модель керування операціями основного виробництва. Як зазначено вище, керування операціями основного виробництва – це категорія, що складається з видів діяльностей, безпосередньо пов’язаних з виготовленням продукції. Пояснимо керівні діяльності для цієї категорії операції. IEC 62264-3 означує вісім діяльностей в межах операцій основного виробництва:

  • Керування означенням  продукту;
  • Контроль виробничих ресурсів;
  • Детальний план-графік основного виробництва;
  • Диспетчерування виробництва;
  • Керування виконанням основного виробництва;
  • Збір даних основного виробництва;
  • Стеження за виробництвом;
  • Аналіз ефективності основного виробництва.

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

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

Детальне календарне планування. Бізнес-система (ERP) надає календарний план виробництва, але він має бути адаптований та конкретизований до місцевих умов. Тому для виконання загального плану проводиться детальне календарне планування. Воно використовує конкретні ресурси місцевого рівня (наприклад виробничого майданчику, цеху), враховуючи місцеві потужності. Ця адаптація до місцевих умов необхідна на рівні 3, оскільки системи планування рівня 4 для всього підприємства не має детальної інформації, необхідної для керування виробництвом на необхідному рівні точності. При детальному календарному плануванні також існує можливість порівняння планів з фактичними результатами, які рідко проводяться на рівні 4. Ця діяльність також може об’єднувати або розділяти замовлення, щоб краще відповідати місцевим потужностям.

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

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

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

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

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

Детальніше ці діяльності розглядаються у наступних розділах посібника на прикладі однієї з платформ MOM.  

Читати далі

3. Підходи до реалізації функцій рецептурного керування

Олександр Пупена,
Роман Міркевич,
Олег Клименко

Перейти до початку посібника

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

3.1. Майстер рецепти та керівні рецепти  

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

Майстер рецепт не може бути безпосередньо використаний при виробництві партії продукту і на це є ряд причин. Для кожної партії продукту індивідуально необхідно:

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

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

3.2. Принципи реалізації рецептів з однією процедурою  

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

Рис. 20. Приклад процедури керівного рецепту з посиланням на реалізовану процедуру в устаткованні

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

  • BATCHID – унікальний ідентифікатор партії продукту, використовується для простежування виготовлення партії. Застосовні лише для керівного рецепту. Зазвичай генерується при створенні та запуску керівного рецепту на виконання з часу та дати.
  • MSRECIPE_ID – унікальний ідентифікатор майстер рецепту, використовується для посилання на шаблон як при виготовленні партії так і  при простежуванні.  
  • Змінна стану та змінна часу стану – використовується для керування виконанням процедури технологічної комірки керівного рецепту (запуск, зупин, утримування), і зазвичай відповідає. Застосовні лише для керівного рецепту.
  • Параметри формули – вміщує необхідний набір полів, які відповідають за параметри виготовлення продуктів. Міститься як в майстер рецепті так і в керівному. При запуску керівного рецепту копіюються з відповідного майстер рецепту. Одним із параметрів може бути номер необхідної процедури технологічної комірки.
  • Статистична інформація (опційно) – вміщує набір інформації на основі якої будуть генеруваться звіти, наприклад, кількість виготовленої продукції, інформацію про перебіг технологічного процесу і т.д. Генерується керівним рецептом в процесі його виконання.
  • Вимоги до необхідного устатковання – технологічне устатковання на якому можна виконати конкретний майстер рецепт.

Таким чином, процедура технологічної комірки буде реалізована в програмі контролера, а рецепт матиме ідентифікатор, який посилається на дану процедуру. При необхідності приготування конкретного продукту потрібно вибрати майстер рецепт, який посилатиметься на необхідну процедуру. У складнішому випадку, майстер рецепт означує «технологічну програму» через послідовність процедур. Формат опису такої процедури може бути різним, в тому числі і з використанням мови PFC. Зрештою, він може вміщувати усі типи процедурних елементів (див.рис.21). Повні вимоги до структури керівного та майстер рецепта і мова PFC описані в стандарті IEC 61512-2 і виходить за рамки даного посібника. Приклад такої реалізації з використанням спеціалізованого модуля показаний в лабораторному практикумі [13] та продемонстровано на відео [14]

Рис. 21. Приклад процедури керівного рецепту з повною ієрархією рецептурних процедур

3.3. Приклад реалізації простих рецептів

Якщо рецептурна процедура технологічної комірки посилається на аналогічну апаратурну, рецепти можна реалізувати в ПЛК через структурні змінні. На Рис. 22. для прикладу представлена структура для спрощеного майстер рецепту. Усі майстер рецепти організовані в масив. Номер елемента в масиві є ідентифікатором конкретного майстер рецепта (аналог MSRECIPE_ID), за яким відбувається звернення. Усі інші поля майстер-рецепту по суті є параметрами формули.

Рис. 22. Приклад структури майстер рецепта

На Рис. 23. представлений приклад структури керівного рецепта, який включає формулу. При створенні даного рецепта в його поля формули копіюються відповідні поля майстер рецепта. Параметри формули керівного рецепта можна змінювати в процесі виконання і відповідно ці зміни ніяк не відображаються на майстер рецепті. У цьому керівному рецепті є поля BATCHID, структурне поле CFG для конфігурування параметрів процедури, структурне поле CTRL для керування процедурою, час та дата запуску процедури рецепта і час та дата завершення процедури рецепта (у структурі CFG). Додатково в цю ж структуру можна вписувати необхідні поля зі статистичною інформацією (наприклад значення лічильників при старті та завершенні рецепту). Зрештою, значення цієї структури можна записувати в базу даних для виведення на звіти та можливої реалізації внутрішньої простежуваності.

Рис. 23. Приклад структури керівного рецепта

Навіть при такій простій реалізації рецептів, в якій вся процедура технологічної комірки є частиною устатковання, є сенс ділити її на менші процедурні елементи (етапи) для більшої гнучкості програми. Наприклад, можна вручну завершувати виконання одного етапу і починати виконання іншого. При цьому процедура технологічної комірки буде залишатися в стані ВИКОНУЄТЬСЯ, а етапи будуть проходити по своєму автомату станів. У свою чергу, зміна станів кожного етапу може фіксуватися в журналах і трендах для аналізу історії приготування партії. Наприклад на Рис. 24 зображено як процедура приготування добрив розділяється на декілька етапів перемішування, мийка, наповнення і т.д, кожен з яких може керуватися через окреме вікно. Даний підхід полегшує пусконалагоджувальні роботи, оскільки можна перевіряти програму керування незалежними частинами.

Рис. 24. Розділення процедури на етапи

4. Підходи до реалізації функцій звітів порційного виробництва

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

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

Реалізація підсистеми звітності з використанням керівних рецептів стає можливою навіть з використанням класичних засобів автоматизації, без використання спеціалізованих модулів. Наприклад, на одному з об’єктів цукрового виробництва [9] для звітності в системі керування вакуум-апаратами було використано ПЛК та SCADA без спеціалізованих модулів. За наведеним вище принципом для кожного керівного рецепту створювався окремий запис (структурна змінна), який включав в себе BATCHID партії, початок та кінець процесу варки, ID технологічного вузлу та додаткову інформацію (наприклад, час перебування в стані HOLDING). При завершенні варки (відповідно і виконання керівного рецепту) у таблицю бази даних заносився цей запис, що давало можливість передивлятися історію варок звичайним переглядачем таблиць в БД (див. рис.25).

Рис. 25. Приклад реалізації історії «варок»

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

Рис. 26. Приклад реалізації онлайн-звіту по конкретному керівному рецепту

У проекті автоматизації тепличного комплексу [11] архівування даних проводилося безпосередньо на контролері. Це може здатися дивним, але виявилося, що зберігати дані по партії в ПЛК зручніше, ніж в SCADA/HMI. Інша справа – формування звітів за цими даними. У цьому проекті файли за необхідності копіювалися на ПК (через FTP), де аналізувалися в Excel з використанням скриптів VBA. Тоді це було найшвидшим рішенням, але зараз у нас є інше бачення формування звітів для такого типу задач. У цьому проекті ПЛК циклічно записував значення змінних стану процедурних та апаратурних елементів в текстовий файл, для їх простежуваності і подальшого аналізу. Також при зміні стану процедурних елементів, зокрема керівного рецепту, контролер генерував подію, яка записувалась в журнал на карту пам’яті ПЛК. У подальшому даний файл (Рис. 27) можна було аналізувати і обробляти спеціальним VBA макросом, або аналізувати через візуальний інтерфейс Excel. У тексті даного файла зберігались час події, BATCHID партії а також символьна назва певного етапу поливу.  Як видно з даних записів, BATCHID унікальне для конкретної мийки, при подальшому аналізі саме воно повинне бути критерієм для виділення необхідної інформації.

Рис. 27. Запис звітної інформації засобами контролера

2. Використання процедурного керування згідно стандартів IEC-61512

Олександр Пупена,
Роман Міркевич,
Олег Клименко

Перейти до початку посібника

Для кращого розуміння подальшого матеріалу варто ознайомитися з основами порційного виробництва, наприклад з роботи [1].

2.1. Процедури

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

Таким чином, головним принципом побудови систем керування порційним виробництвом згідно стандарту IEC 61512 є початкове розділення функцій керування на дві взаємопов’язані групи: 

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

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

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

Щоб пов’язати технологію з устаткованням, використовуються елементи технологічних дій – процедури. Технологія порційного виробництва продукту або напівпродукту передбачає виконання «технологічної програми», яка складається з кроків, кожен з яких передбачає виконання певної процедури, наприклад: 1) наповнили; 2) охолодили до 15 °С; 3) вкинули фермент в пропорції 1:100 … Ця технологія означується в рецепті, який вміщує також параметри (формулу) та іншу інформацію. По суті, «технологічна програма» в рецепті є також процедурою. Тобто рецептурна процедура складається з менших процедур, а ті, в свою чергу, посилаються на конкретні екземпляри в устаткованні, яке може їх виконувати. Так відбувається зв’язок рецепту з устаткованням. Найменші процедури називаються етапами.       

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

2.2. Автомат станів та режими процедур

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

Стандарт пропонує один із варіантів набору станів та умов переходу між ними (див. Рис. 13). Перехід від стану до стану відбувається за командою, або за внутрішньою умовою завершення (для перехідних станів). Як рецептурна процедура, так і процедури, з якої вона складається, описуються автоматом станів. Наприклад, коли запускається рецептурна процедура (оператор натискає «ЗАПУСТИТИ»), вона переходить зі стану «ПРОСТІЙ» в стан «ВИКОНУЄТЬСЯ», і перша процедура в ній (етап) також переходить в стан «ВИКОНУЄТЬСЯ». Якщо необхідно призупинити технологічний процес за командою оператора, або за відсутністю сировини чи енергії процедура рецепту переходить в стан «ПРИЗУПИНЯЄТЬСЯ», що призведе до переходу в такий же стан усіх активних етапів.

Рис. 13. Варіант автомату станів процедурного елементу, означеного в стандарті IEC 61512

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

2.3. Ієрархія процедур

Як зазначалося вище, процедури мають ієрархічну структуру. Ієрархія процедур показує яким чином менші процедури реалізують виконання процедур вищого рівня (Рис. 14). Процедура, що означує приготування партії продукту є процедурою технологічної комірки (у стандарті її називають просто «процедурою»). Найменші процедури, які не можуть включати в себе інші, називаються етапами. Таким чином, процедури вищого рівня включають процедури нижчого, тобто координують їх роботу. Принципи взаємодії в цій ієрархії дещо схожі на ієрархію устатковання, яка розглянута вище. Процедура технологічної комірки виконується в межах однойменного устатковання, яке є робочим центром порційного типу (див.рис.11). В межах технологічної комірки можна виготовляти одну або кілька партій (Batch) одночасно. Виготовлення партії у порційному виробництві потребує технологічних вузлів (апаратів), в яких послідовно відбуваються виконання крупних технологічних дій – процедур апаратів. Ті у свою чергу можуть складатися з операцій, а ті – з етапів. Наявність процедур технологічної комірки і етапів в ієрархії є обов’язковою умовою, інші – за необхідності.       

Рис. 14 Ієрархічне представлення процедурних елементів

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

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

2.4. Реалізація процедур в ПЛК

Згідно нашої практики розробки та впровадження, програмна реалізація процедури в ПЛК включає наступні змінні:

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

На Рис. 16. представлений фрагмент програмного коду реалізації процедури керування станцією водопідготовки. З даного фрагменту видно, що процедура виконує базове керування технологічним устаткованням через команди на виконавчі механізми (#VLVD1.CMD:=2 – команда на закриття клапана), а також координацію процедур нижчого рівня, які входять до її складу (наприклад “PHCTRL”.PH_BDWASHIRF200[#i].CMD_START := TRUE – це команда на запуск процедури PH_BDWASHIRF200). Відповідно до стану процедур нижчого рівня, процедура вищого рівня посилає їм команди керування та змінює свій стан. В залежності від стану в якому знаходиться процедура змінюються алгоритми керування, наприклад в стані ПРОСТОЮ (#CTRL.STA_IDLE = TRUE) не виконується нічого, окрім закриття клапанів.

Рис. 16. Фрагмент програми реалізації процедури керування станцією водопідготовки

2.5. Практика використання процедур  

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

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

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

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

  1. Можна означити як вести себе при кожному стані (при паузі, при аварії).
  2. Одне технологічне устатковання може виконувати декілька процедур, як одночасно так і послідовно. 
  3. Кожну процедуру можна виконувати окремо, а потім з них будувати загальну програму виготовлення продукту, яка відповідатиме технологічному процесові;
  4. Багато різного устатковання може виконувати один і той самий тип процедури, але реалізовувати його зовсім по різному (навіть з точки зору ступені автоматизованості);
  5. Можна вести статистику по технологічним діям (порахувати скільки часу процедура виконувалась в конкретному устаткованні);
  6. В процедуру можна ввести ручні операції, тобто певна процедура може завершитись лише в результаті підтвердження оператора. Так в проекті поливу теплиць приготування розчину добрив виконувалось з залученням ручних операцій по додаванню суміші добрив. Після кожної ручної операції оператор вносив в систему кількість доданих сумішей і підтверджував їх додавання. Після цього система самостійно рахувала і набирала необхідну кількість води. Вся ця інформація заносилась в архіви та звіти по кожному поливі.
  7. Процедури можуть взаємно блокуватись – одна блокує або дозволяє виконання інших. Наприклад в проекті станції водопідготовки необхідно було блокувати запуск СІР-мийки, якщо відбувалось виготовлення продукції, і навпаки.

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

Подібні рішення ми використовували на ряді підприємств, де не було потреби у змінній рецептурі, але використовувались періодичні процеси. Зокрема, процедурне керування разом з рядом іншими підходами IEC 61512 використовувалось в цукровому виробництві, де наша команда працювала в субпідряді ТОВ «САУТКОМ» [9]. На Рис. 17  зображено приклад інтерфейсу оператора для керування процедурою уварювання утфелю у вакуум-апараті. Варка відбувається в декілька кроків, послідовність яких можна змінювати за необхідності. Кожен крок можна запускати окремо, якщо це дозволено технологією. Програма досить просто реалізується, коли кожен крок процедури технологічної комірки є окремим етапом зі своїм автоматом станів. Команди «СТАРТ» та «СТОП» інтуїтивно зрозумілі. Етап «Утримування на воді» реалізує однойменну команду. Команда «Переривання» є налагоджувальною і доступна тільки в режимі для наладки.

Рис. 17. Інтерфейс оператора для керування процесом уварювання утфелю

Ці ж підходи були використані в ряді об’єктів «ЛВТ Інжиніринг», ПЗ для яких розробляла наша команда [10][11]. На рис.18 показаний налагоджувальний інтерфейс процедури рівня технологічного вузлу та етапів. Кожну процедуру можна запустити і зупинити, деякі мають ще команду та відповідний стан «ПАУЗА». У даному випадку одночасне виконання кількох етапів блокується.    

Рис. 18. Інтерфейс налагодження для процедури технологічного вузла «Робота фільтру» та етапів.

На рис.19 наведений інтерфейс керування етапом «Полив» для АСКТП тепличного комплексу. Особливістю даного проекту в тому, що система складається з 15 ПЛК, кожен з яких відповідає за своє устатковання і має власний набір процедур. Один з ПЛК виконував роль координатора, який спрямовував дії процедур. Оператор також може запускати процедури окремо, використовуючи відповідний інтерфейс (рис.19)

Рис. 19. Інтерфейс керування для етапу «Полив»

Читати далі…

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

Олександр Пупена
Параграф з посібника «Розробка людино-машинних інтерфейсів та систем збору даних з використанням програмних засобів SCADA/HMI»

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

Для ряду об’єктів повинно бути передбачене управління установками згідно з календарним графіком та астрономічним часом. Наприклад, у системах керування водо- та теплопостачанням може знадобитися вмикання та вимикання насосів згідно з встановленим графіком. Це задача для спеціальних підсистем SCADA/HMI, які називаються планувальниками (Scheduler).

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

Планувальники як правило надають наступні можливості в середовищі виконання:

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

У Citect підсистема календарного керування базується на механізмі ієрархії устатковання (Equipment) . Для устатковання повинні бути зконфігуровані Стани (Equipment States), у властивостях яких вказано що саме необхідно робити при активації та активності цього Стану. Їх налаштування розглянуто в кінці статті.

Для устатковання, яке повинно керуватися з планувальника повинна бути виставлена в TRUE властивість «Заплановано» (Scheduled).

Для реалізації графічного інтерфейсу на одній із дисплейних сторінок необхідно розмістити ActiveX компонент «Scheduler» (рос.лок.«Планировщик»), який  є на палітрі компонентів Citect. Він не потребує конфігурування в середовищі розробки, це може знадобитися хіба що для прив’язки певних властивостей до змінних. Уся діяльність налаштовується у Планувальнику у режимі  виконання (рис.1). На ньому доступні кілька вкладок, які дають можливість налаштовувати календарний план (у вигляді дня, тижня, місяця, хронології), контролювати кінцевий стан планування. Можна також додавати спеціальні дні в календарі, для яких можна окремо конфігурувати поведінку устатковання. 

У дереві відображається все доступне для планування устаткування (що має властивість Scheduled=TRUE). При виділенні устатковання, у календарному плані можна подивитися, встановити та змінити дату та час переходу на конкретний стан.   

Рис.1. Зовнішній вигляд планувальника в Citect

Устатковання може перебувати у різних режимах, які відображаються відповідним символом:

  • Автоматичний  (automatic) – режим в якому стан задається планувальником відповідно до означеного календарного плану;
  • Заміщення (Override), також називається ручним – коли станом керує оператор через контекстне меню. 

 У контекстному меню устатковання є відповідні команди переходу в режим, та у стан (у режимі Override). Перехід у режим та стан доступний також через функцію Cicode  «EquipSetProperty». Функція «EquipGetProperty» дає можливість отримати активний режим та стан.

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

Про стани, режими, механізми поширення станів та режимів відповідно до IEC 61512 можете прочитати за посиланням.

Для устатковання, яке необхідно використовувати у підсистемі календарного планування необхідно вказати перелік Станів, для кожного з яких треба вказати (рис.2):

  • дію при вході в стан (Entry Action, рос.лок «Действие ввода») – дія, яка буде виконуватися, в момент переходу в цей Стан.
  • затримку (Delay, рос.лок. «Задержка») – час, який повинен пройти після активації стану до виконання дії; це може знадобитися тоді, коли прийшов час на активацію кількох одиниць обладнання, і треба уникнути одночасності, наприклад для зменшення сплесків струмів при вмиканні кількох двигунів;
  • повторювану дія (Repeat Action, рос.лок. «Действие повтора») – дія, яка буде повторюватися з вказаним періодом при активності стану;  
  • період (Period) – час, через який буде виконуватися повторювана дія;
  • пріоритет (Priority) – число, що вказує пріоритет стану, якщо кілька станів виникають одночасно (при поширенні станів); 

Режим DR (DR Mode) дає можливість задати кілька станів з різними діями на основі вибраного режиму споживання (Demand and Response); можна змінювати також через функцію EquipSetProperty;       

рис.2. Налаштування обладнання та Станів для нього.

Модулі керування CM

Олександр Пупена,
Роман Міркевич,
Олег Клименко

Перейти до початку посібника

1.11. Модулі керування CM  

Клапан, який розглядається у прикладах вище, виконує функцію керування фізичним устаткованням. З точки зору  рольової ієрархії IEC 61512, що наведена на рис.11, він займає найнижчий рівень устатковання – модулів керування (Control Module, CM). Згідно стандарту є певні вимоги щодо приналежності устатковання до певного рівня, але на них ми зупинимося пізніше. Наразі будемо вважати так: все, що має відношення до засобів КВПіА, які показуються на схемах автоматизації можна віднести до модулів керування. Наприклад, датчики, виконавчі механізми та регулюючі органи, регулятори, частини контролерів та засобів SCADA/HMI що виконують конкретну функцію в контурах контролю, керування та регулювання. Устатковання не обов’язково є фізичним об’єктом, це може бути певне об’єднання взаємопов’язаних функцій. Типовим прикладом є ПІД-регулятор, який реалізований у вигляді виклику програмного бібліотечного функціонального блоку, або – весь контур регулювання, в який він входить.

Стандарт дозволяє включати одні модулі керування в інші. Тобто, контур регулювання може бути представлений модулем керування, який може включати в себе датчики, задатчики, функціональний блок регулятора, виконавчий механізм, оповіщувач і т.п., які у свою чергу також є CM. Розділення чи об’єднання CM робиться виключно з позицій зручності. Наприклад, у каркасі [8], незалежно від типу технологічного процесу, яким керує АСКТП, на рівні модулів керування пропонується виділяти типові об’єкти 3-х рівнів (Рис.12):

  • 0-й (LVL0) канали контролеру – для діагностики каналу, прив’язки логічних каналів до фізичних, форсування входів/виходів:
    •  DICH – дискретні входи,
    •  DOCH – дискретні виходи,
    •  AICH – аналогові входи,
    •  AOCH – аналогові виходи,
    •  COMCH – комунікаційні канали
  • 1-й (LVL1) – технологічні змінні для повної обробки інформації з процесу, включаючи прив’язку до каналу, фільтрацію, масштабування, інверсію і т.п.; для зручності відлагодження процесу; для функцій імітаційного моделювання; для функцій технологічної сигналізації;
    •  AIVAR – аналогові вхідні,
    •  AOVAR – аналогові вихідні,
    •  DIVAR – дискретні вхідні,
    •  DOVAR – дискретні вихідні:
  • 2-й (LVL2) – для зручності налагоджування процесу; для функцій імітаційного моделювання; для функцій технологічної сигналізації; для ведення статистики:
    • виконавчі механізми (запірні клапани, регулюючі клапани, двигуни, насоси);
    • контури регулювання та керування: для функцій керування зі зворотним зв’язком.
Рис. 12. Ієрархія модулів керування в програмному забезпеченні

Така трирівнева архітектура передбачає модель взаємодії між рівнями CM:

  • обробка усіх елементів незалежно від рівня проводиться паралельно, тобто вкладеності виклику функцій та функціональних блоків немає, модель підлеглості реалізовується через механізм надання, або звичайними програмними зв’язками;
  • 2-й рівень (виконавчий механізм, регулятор) не може взаємодіяти безпосередньо з 0-м (каналом);
  • усі елементи вищого рівня можуть взаємодіяти з будь-якими елементами нижчих, за винятком 0-го рівня (див. попередній пункт);
  • вищий рівень може змінювати стан нижчого: змінювати його значення, переключати в різні режими (форсування, імітація), змінювати налаштування тривог і т.д.;
  • елемент 1-го рівня (змінні) може заволодіти (allocation) елементом нульового (канали);
  • 0-й рівень (канал) має інформацію про те, хто ним володіє;
  • 1-й рівень (змінна) має інформацію про те, ким він володіє;
  • при реалізації об’єктів на різних пристроях (в розподілених системах) механізм взаємодії між ними відбувається через пару СЛОВО СТАНУ – СЛВО КОМАНДИ, а при реалізації в тому ж пристрої дозволяється використовувати як безпосередню зміну значення у підлеглого об’єкту (прямий доступ), так і через взаємодію СЛОВО СТАНУ – СЛВО КОМАНДИ.

Детальніше про реалізація багаторівневості модулів керування описані у роботі [8].

Читати далі