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”

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

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. Запис звітної інформації засобами контролера

Використання моделі устатковання в 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. Налаштування обладнання та Станів для нього.

ВИРОБНИЧІ КПЕ: АКТУАЛЬНИЙ СТАН ТА ПЕРСПЕКТИВИ РОЗВИТКУ В УКРАЇНІ

В документі детально представлені головні положення стандарту ISO 22400, описаний їх загальний стан в Україні, вказані типові помилки при застосуванні КПЕ, визначені головні виклики експертної спільноти щодо подальшого впровадження на підприємствах України.

Продовжувати читання ВИРОБНИЧІ КПЕ: АКТУАЛЬНИЙ СТАН ТА ПЕРСПЕКТИВИ РОЗВИТКУ В УКРАЇНІ

Аналітичний звіт “Вертикальна інтеграція”

Новий аналітичний звіт «Вертикальна інтеграція. Виклики та перспективи» інтегрує всі попередні напрацювання проекту aCampus по відповідним стандртам, – в першу чергу по МЕК 62264 та ISO 22400.

Продовжувати читання Аналітичний звіт “Вертикальна інтеграція”

Стан обізнаності ринку про IEC 62264 за результатами опитування

Технічним комітетом 185 «Промислова автоматизація» разом з партнерами проведено опитування стосовно стану обізнаності зі стандартами ISA-95/IEC-62264, щодо використання систем керування виробництвом рівня MOM/MES, а також проведено оцінку важливості різних бізнес-драйверів. Незважаючи на малу кількість респондентів (8 осіб), що у свою чергу характеризує низьку зацікавленість ринку до стандарту, ми наводимо основні результати (див. таблиці 1-14) для поверхневої оцінки стану. З огляду на те, що не всі особи залишили свої контактні дані (останнє питання), це дещо зменшує довіру до їх відповідей, тому таблиці розбиті на дві частини. До опитування також долучився представник білоруської молочної компанії «Савушкін продукт», який є передовим підприємством харчової промисловості в Білорусі. Їх відповіді позначені літерою «Б».

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

На думку опитуваних, найбільш вагомими бізнес-драйверами є якість та простежуваність, а також швидке та оптимальне планування.  Якість та простежуваність – відповідність нормативним вимогам, визначення затрат на обслуговування для покращення продукту, безпечність для клієнтів та відстеження впливу небезпечних предметів на персонал (біля 90-100% опитуваних вважають показник важливим, оцінка 4-5 в діапазоні 0..5). Вдосконалене планування є ключовим бізнес-драйвером для компаній з дорогими запасами, трудомістким виробництвом, але швидкими змінами клієнтів та змінним попитом (біля 90-100%).

Трохи менш пріоритетними респонденти виділили швидке прогнозоване виконання замовлення та ефективність активів.  Автоматизована доступність прогнозування – швидко реагувати на замовлення  відповідно до стану виробництва (60-70%). Ефективність активів – орієнтація на максимізацію ефективного та економічного використання активів у виробництві продукції (60-70%)

Іншим бізнес-драйверам надали високі пріоритети від 40%-50% респондентів.

Скорочений час циклу  – час, який необхідний для виготовлення продукту з моменту розміщення замовлення (біля 50%). Оптимізація ланцюжка постачань – ведення бізнесу кожним учасником ланцюжку з використанням останньої і якісної інформації від інших учасників, щоб якнайкраще збалансувати попит і пропозицію (біля 50%). Гнучке виробництво – можливість змінювати налаштування виробничих активів для швидкого задоволення попиту на ринку (біля 40%).

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

В рамках опитування нас цікавила наявність різних систем керування виробництвом рівня MOM/MES на підприємствах респондентів. Серед опитаних найбільшої популярності досягли самописні модулі керування виробництвом (наприклад для «1С Предприятие»), які наявні на підприємствах у (75-100%) опитаних (див. таблицю 8). Розмова з представниками багатьох підприємств дає ту саму картину, що підтверджує реальність даних цифр. На нашу думку це пов’язано насамперед з двома пов’язаними причинами: тотальне впровадження 1С на рівні керування бізнес-процесами та наявністю програмістів в штаті, які й супроводжують і відповідно можуть доробити додатковий функціонал.      

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

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

За результатами опитування системи керування складом (WMS) практично відсутні на українських підприємствах.

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

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

Серед програмних засобів автоматизації підприємств (ERP-рівня) зазначали такі як SAP, 1C, Парус та власні розробки. Підтримку стандартів IEC цими засобами назвали біля 50% респондентів (MES або ERP). Відповіді сильно  розподілені, однак принаймні 50% кажуть про відсутність підтримки на всіх рівнях керування. Нам здається ця кількість дещо занижена.

Приблизно така сама ситуація в оцінці ступені інтегрування рівня MES та ERP. Системи «частково інтегровані» та «зовсім незалежні» приблизно поділилися 50% на 50%. Тільки один респондент (який не залишив своїх координат) відповів про повну інтеграцію з використанням власних стандартів.

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

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

Необхідність стандартизації відчувають біля 60% респондентів.

Хоч респондентів достатньо мало і нічого не можна сказати про репрезентативність вибірки, спробуємо зробити хоча б аналіз того, що маємо. Найбільш вагомими бізнес-драйверами, що можуть слугувати аргументом на користь використання інтегрування L4 та L3 взагалі, та з використанням IEC 62264, є контроль якості та простежуваність і швидке оптимальне планування. При цьому для реалізації функцій MOM лідирує спосіб «дописати модуль власними силами». На рівні АСКТП українські підприємства принаймні частково автоматизовані. Принаймні 50% говорять про відсутність інтегрування на всіх рівнях, і більше половини – про необхідність стандартизації. Зрештою, ми маємо і так відому картину – інтегрування потребується і стандарти в цьому можуть допомогти.         

Стандарт IEC 62264 як джерело знань: досвід впровадження в навчальний процес та на тренінгових курсах

Окрім своїх прямих цілей – забезпечення інтегрування рівнів MOM та ERP, стандарт IEC 62264 також може бути використаний для навчальних цілей. У даній статті розповідається про власний досвід авторів використання стандарту в навчальному процесі кафедри АКТСУ в Національному університеті харчових технологій та курсах підвищення кваліфікації.  

Ще з 2000-х років кафедра АКТСУ (тоді АКІТ) зробила багато дій щодо впровадження дисциплін, присвячених системам MES в навчальний процес. Свій важливий внесок в це у різні часи зробили «Індасофт-Україна»,  IT-Enterprise та інші організації, надавши промислові програмні пакети та допомагаючи навчальними матеріалами. Однак для кращого розуміння основ MES необхідний узагальнений матеріал, який би не залежав від постачальника рішень. Матеріали MESA на той час були сильно узагальненими, тому зрештою ми вийшли на стандарт ISA-95, який означував моделі представлення виробничого підприємства. Перше ознайомлення зі стандартом було невдале, він був малозрозумілим. Причин на те було декілька:

  • ми зосереджувалися на першій та другій частині першої версії, в якій було багато складних для розуміння додатків (чого варта тільки модель Perdue)
  • здебільшого уважно вичитували саме російську перекладену версію аналогічного стандарту IEC; радимо Вам не робити цього, так як переклад на нашу думку дуже не вдалий; звичайно що наш переклад може здатися Вам також не вдалим, але принаймні термінологію всередині стандарту ми узгоджували, щоб уникнути плутанини;
  • ми були недостатньо підготовлені у виробничих процесах, які відбуваються на підприємстві;
  • у нас не було досвіду впровадження модулів MES/MOM;
  • стандарт написаний не мовою автоматників, а мовою IT та виробничників;

Тим не менше, отримавши усі необхідні копії оригінальних версій стандартів ми поступово почали їх освоювати. Відкриттям стала третя та четверті частини стандарту. Якщо перші дві частини націлені на інтегрування рівня ERP та MES/MOM, то третя та четверта частина показують на функціонування MOM зсередини та дають необхідну інформацію для розуміння цих процесів. Це стало передумовою використання стандарту в якості прототипу посібника.

Цього року бельгійська фірма Brighteye залучила кількох викладачів кафедри до створення навчального контенту для підготовки інтеграторів MOM на ПЗ Momentum (в минулому, MESControl). Особливістю даного курсу було навчання саме інтеграторів АСКТП. Тобто необхідно було розробити повний курс з лекційним та лабораторним матеріалом, який би варто прослухати розробникам самим 🙂 . Складність цього завдання була в тому, що навчального матеріалу на той момент практично не було, але є довідникова система, яка, як виявилося, закриває необхідний матеріал відсотків на 80, що достатньо для його вивчення. У випадку проблемних питань спеціалісти Brighteye  надавали необхідну допомогу. Тим не менше, при досить слабкій на той момент підготовці викладачів в MES/MOM, це стало серйозним викликом. Головним висновком з точки зору навчальної діяльності став той факт, що розуміння функцій MOM приходило тільки при читанні відповідних розділів стандартів і визначення та перевірка їх відповідників у конкретному програмному забезпеченні. Відсутність одного з компонентів (стандарту або ПЗ) не мало б такого ефекту. Це можна вважати формулою навчання MOM. Слід відмітити, що Momentum  розроблений з урахуванням стандарту ISA-95 (IEC 62264). Там є певні розбіжності, зокрема в термінології, але зробивши певний mapping, все більш-менш почало співпадати зі стандартом. Таким чином, усі розділи теоретичних частин курсу починалися з означення частини стандарту. Так, наприклад, модулі Momentum розповідалися  у контексті виробничих операцій (рис.1).

Рис 1. Відображення (mapping) модулів Momentum на керування виробничими операціями

У такому саме контексті показувалися функції Momentum через модель діяльностей (рис.2).

Рис 2. Відображення (mapping) функцій Momentum на модель діяльностей MOM

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

Паралельно розроблений лабораторний курс почав впроваджуватися на кафедрі АКТСУ НУХТ при практично тому самому лекційному матеріалі, що був минулого року. 

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

  • поняття сегментів продукту;
  • як відбувається простежуваність продукту (внутрішня) на рівні підприємства та поза його межами (зовнішня);
  • за якими принципами відбувається налаштування планування;
  • як фізично відбувається розрахунок  КПЕ (ключових показників ефективності, KPI); стандартний OEE (ISO 22400) та відповідні вкладені КПЕ в Momentum реалізований простим конфігуруванням, інші КПЕ реалізуються також досить легко без необхідності програмування;
  • як працює керування операціями контролю якості;
  • як функціонально (не інформаційно) зв’язуються рівні MOM та ERP через передачу замовлень та звітів;
  • як зв’язуються рівні MOM та АСКТП.

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

  • навчання починати від знайомих функцій: у даному випадку для автоматників це значить рухатися знизу MOM, тобто з рівня АСКТП; 
  • перший день є швидким стартом, який дає можливість оглянути усі основні діяльності MOM і може проводитися як незалежний міні-курс;
  • п’ятиденний курс повинен закрити усі діяльності, щоб почати розробляти систему MOM з типовими функціями;
  • під курс повинно бути розроблене віртуальне виробництво, з якого можна збирати дані і відправляти команди та параметри;
  • мінімальне використання кодування.

Окрім додаткових знань, отриманих від створення та викладання курсу, можна відмітити ще ряд додаткових висновків:

  • функціональність MOM можна зрозуміти за 5-дневний курс як інтеграторам так і керівному виробничому персоналу;
  • MOM можна впроваджувати і на невеликих підприємствах;
  • використання принципів ISA-88 (IEC-61512) значно спрощує інтеграцію АСКТП з MOM; зокрема дуже доречним є використання автоматів станів та процедур.       

Розроблені курси були адаптовані та проведені для кількох груп слухачів представників інтеграторів. Проводив курси Максим Романов, консультант Brighteye. Його оцінка «формули» курсу: «Подача материала в соответствии со структурой стандарта во первых отсекает некомпетентную критичность, во-вторых даёт уверенность в правильной структуре курса и материала, в комплексном охвате темы». У найближчому планується розробка курсу по IEC 62264, з елементами практики на одному із програмних продуктів класу MOM. Практика показала,  що саме такий підхід дасть можливість найкраще зрозуміти функції MOM та їх взаємодію з усіма рівнями керування. Обраний програмний пакет не обов’язково має бути Brighteye. Зрештою, курс повинен бути достатньо гнучким, щоб підлаштуватися під будь-які програмні засоби, що відповідають IEC 62264.  Слідкуйте за новинами на www.i4u.in.ua

Олександр Пупена