Кому потрібен стандарт IEC 61512?

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

У життєвому циклі систем керування порційними виробництвами залучені різні стейкхолдери (зацікавлені особи). На нашу думку стандарт IEC 61512 відноситься до інших інженерів так само, як відноситься до них схема автоматизації (P&ID). Тобто деталі стандарту повинні бути відомі усім автоматникам, а основи – усім хто задіяний в життєвому циклі порційного виробництва, побудованого відповідно до його вимог.

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

Усі учасники життєвого циклу.

  1. Наявність єдиного стандарту дає можливість розмовляти однією мовою і мислити одними категоріями усім учасникам життєвого циклу. Досвід показує, що непорозуміння між учасниками проекту можуть привести до значного затягування термінів реалізації або невдалої реалізації і проблеми подальшого супроводження. У нашій практиці неодноразово зустрічалися випадки, коли у головного проектанта змішувалися поняття режимів, станів і методів доступу в один незрозумілий і заплутаний конгломерат, що приводило до необхідності неодноразової переробки.
  2. Стандарт дає готові підходи до побудови ієрархії устатковання та процедурного керування, що впливає не тільки на розробку системи керування а і на проектування об’єкта взагалі. Тобто прийняття стандарту на усіх рівнях дозволяє проектувати «залізо» за правилами гнучкого виробництва.
  3. Побудова систем на базі парадигм Індустрії 4.0. Стандарт є одним з базових, що входять до різних платформ І4.0, зокрема німецької (RAMI 4.0). Це значить, що побудова сучасних систем неможлива без знання стандарту.        

Експлуатаційний персонал (оператори та відповідальні за основне виробництво).

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

  1. Наявність єдиного стандарту на підприємстві робить його експлуатацію простішою, так як використовуються однакові правила.
  2. Можлива реалізація стандарту, при якому можна переносити рецепти між різними технологічними комірками.
  3. Стандарт організовує виконання ручних дій. Тобто самі дії залишаються ручними, але ініціювання їх виконання може проводитись відповідно до рецепту, а підтвердження результату є умовою завершення певного технологічного кроку.   
  4. Автоматична фіксація усіх дій в журнал. Не потрібно вести виробничі журнали, так як усі дії (у тому числі ручні) пишуться в архів виготовлення партії.
  5. Гнучке керування станом процедури керівного рецепту. Нерідко системи керування розробляють таким чином, коли неможливо «проштовхнути» процедуру на інший крок. Згідно стандарту така можливість передбачена через зміну режиму та станів. Крім того стандарт передбачає в ручному режимі запуск будь якого етапу за необхідності.
  6. Вибір устатковання за потребою. У випадку непередбачуваних причин оператор може вибрати інше устатковання ніж було вибрано початково.
  7. Можливість гнучкого планування виробництва. Хоч у стандарті не означені методи планування, навіть при ручному календарному плануванні за історією партії можна визначити інтервали часу для приготуванні різних продуктів у різному устаткованні.           

Технологи.

  1. Реалізація системи керування згідно стандарту дає можливість технологу:
    • швидше впроваджувати нові продукти на виробництво
    • максимально використовувати усе доступне устатковання
    • швидко аналізувати технологічні процеси, які проходили при виготовленні конкретної партії продукту
    • створювати нові версії майстер-рецептів на основі найкращих керівних рецептів простим копіюванням
    • виводити старі рецепти з обслуговування без їх видалення
    • швидко проводити прослідковуваність процесів виготовлення конкретної партії     
  2. Чіткість означення технологічної процедури. Використання автомату станів та режимів (навіть без повної реалізації стандарту) дає можливість чітко означити поведінку системи керування технологічним процесом за різних ситуацій
  3. Використання формальних способів означення рецептів. Використання стандартних мов означення рецепту (навіть без повної реалізації стандарту) спрощує взаєморозуміння між технологом і автоматником   

Усі спеціалісти з автоматизації, задіяні в розробці та наладці системи.

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

Програмісти АСКТП.

  1. Стандарт означує стійку структуру програми. Правильно побудована прикладна програма зменшує кількість помилок і спрощує її відлагодження. Хоч стандарт явно не вказує на правила побудови прикладної програми у ньому є певні вимоги, які вказують на них. Наприклад, речення «підлеглі апаратурні об’єкти повинні мати можливість виконати свою задачу(-чі) незалежно і асинхронно, дозволяючи апаратурним об’єктам вищого рівня координувати діяльність своїх підлеглих» вказує на те, що ієрархічно організовані функції повинні виконуватися паралельно а не вкладено;   
  2. Спрощення колективної розробки. У великих проектах можуть приймати участь кілька програмістів. Стандарт означує правила декомпозиції об’єкта з точки зору устатковання та процедурного керування. Це дає змогу розділити роботу як по горизонталі, тобто на одному ієрархічному рівні, так і по вертикалі, коли функції або функціональні блоки розробляють різні люди. 
  3. Єдиний стандартизований інтерфейс на усі проекти. Наявність означених автоматів станів передбачає розробку чітко означених інтерфейсів функцій/ФБ, які відповідають стандарту. По суті, велика частина роботи по означенню інтерфейсів вже зроблена в стандарті.         
  4. Використання стано-орієнтованого програмування. Для реалізації цього стандарту використання стано-орієнтованого програмування є обов’язковим. Практика показує, що цей стиль вимагає чітких правил, що значно зменшує можливу невизначеність роботи програми, кількість помилок та спрощує процедуру перевірки.        
  5. Означені принципи архітектури об’єктів. Програмісту не потрібно придумувати власні правила виділення об’єктів,  декомпозиція проводиться колективом розробників за правилами, що означені в стандарті.
  6. Спрощення побудови розподілених систем керування. Асинхронність виклику процедур та функцій базового керування дають можливість повністю розподіляти їх між різними засобами автоматизації. Це також дуже важливо для роботи згідно ідеології Індустрії 4.0, що передбачає інтелектуальність устаткування різного рівня. Взаємодія через пару COMMAND/STATUS дає можливість побудувати систему з використанням архітектур IIoT (Industrial Internet of Things).    
  7. Використання правил надання (Alloction). Означення механізму надання вирішує конфлікти доступу до спільних ресурсів. Навіть без повної реалізації стандарту, його розуміння вже дає відповіді на питання правил розподілу ресурсів.
  8. Спрощення реалізації KPI. Використання процедур та устатковання на базі станів спрощує реалізацію розрахунку KPI, так як умови початку і кінця зміни стану або режиму явно відслідковуються. Явне виділення об’єктів устатковання дає можливість робити розрахунок складових KPI (наприклад кількості, сумарного часу) на першому рівні ієрархії (контролери).      

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

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