Без категорії

Кафедра Автоматизації технологічних процесів веде свою історію з 1965 р., коли була відділена від кафедри електротехніки, до 2001 р. мала назву – кафедра автоматизації будівельного виробництва. В 2001 р. перейменована на кафедру автоматизації технологічних процесів, входить в склад факультету автоматизації та інформаційних технологій.

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

Кафедру очолює професор Скіданов Володимир Михайлович.

Бажаємо успіхів в питаннях просвіти та підготовки кадрів!

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

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

№1 – «ринок розвивають великі бренди-вендори» (а не замовники)

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

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

Якою є нова парадигма: так само, як і в розвинутих країнах – стратегію розвитку власних технологій та систем автоматизації має визначати сам замовник. Разом з близькими та досвідченими інтеграторами, а потім вже – з брендами.  Так я це вже робить Максим Романов з Arcellor Mittal.

№2 – домінування «заліза» бренду над рішеннями 

В чому це проявляється: це є, очевидно, наслідком дії попередньої парадигми. Але також того, що наші інтегратори мають дуже слабкий маркетинг та мало думають за своє позиціонування, а також за формулювання пропозиції цінності.  На західних ринках картина інша – ми бачимо потужні позиції інжинірингових підрозділів АВВ, Emerson, Siemens, а  та також чисельних технологічних компаній (Danielli, Air Liquide і маса інших). Саме вони «правлять бал» у замовників в великих проектах.

Чому це шкідливо: очевидно, що замовникам потрібні рішення – а не компоненти. Коли й сьогодні великий замовник повторює – «та не потрібні мені ваші ще 50 контролерів, – потрібне конкретне рішення для такої й такої проблеми…»  стає прикро – і за вендорів, і особливо за інтеграторів. Те саме видно й по більшості конференцій – ми ніяк не можемо вийти з парадигм Product Push.

Якою є нова парадигма: Рішення під конкретні завдання і які дають необхідний (економічний)  ефект. Кінцівка цієї фрази важлива – в силу вищесказаного, дуже мало інтеграторів може яскраво демонструвати ефект впровадження АСУ ТП на показники якості, (енерго) ефективності, продуктивності, безпеки тощо. Тобто, відповідати на ключові виклики, які сьогодні стоять перед кожним українським підприємством.  Гарний приклад правильної інжинірингової позиції – Група «Техінсервіс», – вони абсолютно самодостатні в співпраці з замовниками. 

№3 – «все залежить від держави» (або «мої проблеми буде вирішувати хтось»)

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

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

Якою є нова парадигма: паростки нових парадигм видно серед членів АППАУ – Олександр Пупена, Максим Савельєв, Павло Галкін – вони представлять нові підходи та нові формати освіти та просвіти, які не покладаються виключно на роль держави, – а на власні сили, партнерів та спільноту. Серед вендорів виділимо тут Klinkmann (буде Сергій Батюк), Phoenix Contact та Siemens (теж побачимо доповідь).

№4 – «технології важливіші за сучасні принципи та стандарти»

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

Чому це шкідливо: тому, що: 

1. замовники, ВУЗ-и та інші гравці давно стомились  розбиратись з зоопарками (шин, протоколів, форматів даних, псевдо-переваг, нормативів та правил безпеки, обслуговування тощо). АСУ ТП – чи не єдина галузь в Україні, що немає ні своїх технічних комітетів при Держстандарті, ні своїх представників хоча б при існучих комітетах. 
2. тому, що великі підприємства все-одно підходять до питань уніфікації – і коли вони не знають сучасних принципів (=стандартів) – вони починають «винаходити велосипед». Зайве говорити про втрати часу, грошей та ресурсів – мине ще кілька років, і все прийдеться змінювати.

Якою є нова парадигма: «технологія – це просто інструмент» – кажуть відомі експерти по управлінню. Набагато важливіше зрозуміти, для чого вона і що стоїть за нею – принципи, стандарти, бізнес-процеси, KPI, знання та навички персоналу – що разом формують ту саму культуру підприємства, про яку так нарікають багато вендорів чи інтеграторів.  З інноваторів ринку, яких ми побачимо на конференції 15 жовтня знову згадаємо Arcellor, але також згадаємо чимало західних філій в Україні, – які (на жаль мовчки) давно впроваджують принципи ОЕЕ, ТСО та інших техніко-економічних концепцій, що мають відношення до АСУ ТП.

№5 –  «в замовників немає грошей, отже нічого й говорити про розвиток»

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

Чому це шкідливо: тому, що саме зараз прийшов час яскраво демонструвати ефект від «заліза». Замовникам – генеральним, фінансовим, технічним директорам – потрібно яскраво та переконливо демонструвати які будуть показники ROI, окупності, зменшення собівартості продукції тощо. Все це дуже пов’язно з показниками середнього рівня KPI – як ті самі ОЕЕ, ТСО, зменшення браку, ріст продуктивності, зниження складських запасів, економія енергії і т.п. і т.д. І тільки на 3-му рівні йдуть показники АСУ ТП – функціональність, надійність, швидкість, зручність, продуктивність системи  тощо і окремих її частин. Невміння зв’язати всі 3 рівні – є наразі критичним для більшості гравців.

Якою є нова парадигма: чітко показувати, який вклад вносить мій «дівайс-софт-система» – в економічні показники підприємства.  Чітку орієнтацію на таку позицію все частіше займають члени АППАУ інтегратори «ВДТ-Автоматизація» та НПП «Тріада», хоча, якщо чесно – з розрахунками важко у всіх. Серед вендорів назвемо EQ Systems.

                                                                                ********

Отже, для всіх, хто прагне розвивати ринок АСУ ТП –

• Меседж №1 – боротись треба з причинами, а не наслідками. Парадигми є основою нашої поведінки та дій. Тому якомога більше акцентуйте на шкідливості старих парадигм, та показуйте приклади нових.
• Меседж №2 – людей з новими парадигмами насправді вже багато серед нас – тому об’єднуємось:  рухатись разом швидше та цікавіше:))   
• Меседж №3 – засадничі принципи (стандарти) – основа розвитку. Все інше похідне – тому потрібно якомога швидше організувати роботу навколо пріоритетних стандартів галузі.

Почуємось та побачимось на конференції 15 жовтня.

 

Юрчак О.В.  ген директор АППАУ

Мощность цеха составляет 150 т/сутки.

Цех по производству смол КФС и МФС на Коростенском заводе МДФ

Весь производственный процесс полностью механизирован и автоматизирован по последнему слову техники, что позволяет чётко придерживаться заданной рецептуры и получать качественную и экологически безопасную смолу класса Е-1 и Е-0.

Комплекс состоит из следующих секций:

• узел разгрузки карбамида из вагонов-хопперов; 
• склад карбамида;
• узел разгрузки карбамидоформальдегидного концентрата (КФК) из ж/д цистерн;
• склад КФК;
• склад КФС;
• цех по приготовлению КФС и МФС.

«Проект прошел полную приемку и сдан в эксплуатацию. Экологическая экспертиза подтвердила его полное соответствие международным требованиям безопасности и действующим техническим регламентам. Срок исполнения проекта «под ключ», вместе с пусконаладочными работами, составил 12 месяцев», – отметил Генеральный директор Производственной Группы «Техинсервис» Игорь Щуцкий.

Следует отметить, что все проектные работы осуществило собственное проектное бюро, а технологическое оборудование и металлоконструкции цеха изготовлены на Гребенковском машиностроительном заводе (ГМЗ), входящем в состав Техинсервис ПГ.                

Подразделение автоматизации Techinservice Intelligence разработало «под ключ» систему автоматического управления SimpleChem_Resin. Данная АСУТП позволяет готовить КФС различных рецептур в полном автоматическом режиме.

Операторская цеха КФС и МФС на Коростенском заводе МДФ

Принт-скрины системы автоматического управления SimpleChem_Resin для Коростенского завода МДФ

С уверенностью можно сказать, что разработанный Техинсервис ПГ проект цеха по производству КФС и МФС для Коростенского завода МДФ открывает широкие возможности организации экологически чистого производства смол и способствует повышению экономической эффективности всего предприятия.

Источник: www.techinservice.com.ua

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

1.Чому «стандарти» (є пріоритетом №1 в стратегіях АППАУ)?

Маємо, як мінімум, 3 «залізні» аргументи :

• Стандарт,  як спосіб найефективнішого досягнення поставленої цілі чи виконання конкретної дії, – має бути сучасним. Як ви думаєте, чи можна досягти високого рівня кібер-безпеки в енергетиці, використовуючи ГОСТ-и 60-х років минулого століття?
• Готовий стандарт – це економія власних сил та часу. Чи ефективно щоразу «винаходити велосипед», коли кращі світові фахівці працюють над конкретними, складними питаннями десятиліття? Уявіть, що контролери від різних виробників були б зі своїми мовами програмування – а не стандарту МЕК 61131-3. В Україні, на жаль, в ряді випадків ми все ще продовжуємо грати в цю гру.
• Стандарт – це інтеграція в міжнародну спільноту і очевидно, що це must be для всіх, хто використовує імпортне обладнання, працює з іноземними підрядниками і т.п. Для України перехід на європейські стандарти – це також must be згідно угоди про асоціацію з ЄС.

2.Які стандарти промислової автоматизації є найпріоритетнішими для України?

В широкому контексті – на державному рівні чи на рівні всієї спільноти, – питання відкрите. В більш вузькому – членів АППАУ, – домінує думка, що треба починати з стандартів ISA 88,95,99. Саме вони є в центрі уваги світової спільноти, про них найбільше говорять на конференціях та в медіа-просторі, вони є основою для інтеграції систем та для завдань інформаційної безпеки. Наші ВУЗ-и рекомендують також додати в цей перелік ISA 5.1.  Для інтеграторів важливим є ГОСТ 34, який часто цитують як найбільш “надійний” для управління життєвим циклом АСУ. Хоча він зовім не новий (редакція 1992 року), необхідність його користування в тому, що часто-густо інтегратори та замовники не притримуються жодних фахових стандартів.

3.«Найпопулярніші»  не означає «пріоритетні». Чим саме ці стандарти можуть бути корисні  для України?

ISA 88 (МЕК 61512) – стандарт про моделювання  та ясний розподіл (структурування) на рівні технічного завдання описання фізичного об’єкту, технологічного процесу та системи управління. Таким чином, стандарт є базовим для комунікацій між спеціалістами АСУ ТП та іншими залученими фахівцями, що є типовою проблемою – в тому числі й в Україні. Також він задає правила для різних типів процесів і йде в парі з наступним – ISA 95.

ISA 95 (МЕК 62264) – стандарт, що стосується інтеграції систем управління по 4-м рівням загальноприйнятої ієрархії АСУ. Саме цей стандарт допоможе вирішити замовникам проблему «зоопарків», яка за останні 10 років вже набула ваги, і яку ряд замовників намагається вирішити, створюючи свої власні «стандарти». Інтеграція систем управління, згідно опитуванням АППАУ 2013 року є одним з ключових пріоритетів нашого ринку, а з точки зору економічних та управлінських викликів – це має пряме відношення до ефективнішого управління підприємствами. Отже, впровадження цього стандарту – пряма відповідь на виклик ефективного управління та є суттю однієї з 5 стратегій АППАУ по розвитку ринку.

ISA 99 (МЕК 62443) – стандарт про кібер-безпеку. З 2001 року цей стандарт фігурує серед найпріоритетніших в світі промислової автоматизації – і по зрозумілим причинам. Війна та загрози тероризму – це реалії України з 2014 року, – тому стандарт вкрай необхідний сьогодні і нам. Цей напрямок – також одна зі стратегій АППАУ, і цей стандарт є відповіддю на багато питань «як зробити кібер-безпеку надійною та сучасною».

4.Що можуть дати ці стандарти конкретно кожному гравцеві ринку?

• Кінцевим замовникам:економити значні кошти та ресурси на розробці власних корпоративних стандартів.
• ВУЗ-ам: оновити програми навчання, зробити їх сучасними та відповідним кращим світовим стандартам
• Інтеграторам: за рахунок уніфікації та оптимізації підвищити ефективність розробок, – зокрема в програмному забезпеченні (американці нарахували економію в 30-50%)
• Вендорам: отримати ще один – і дуже потужний маркетинговий аргумент на користь своїх продуктів.  Для стандартів як ISA 95, 99 це – очевидно.
• Всій спільноті – говорити однією мовою, спростити комунікації, прискорити інтеграцію в світовий простір

5.Як проходять процеси гармонізації цих та інших стандартів в Україні?

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

• Навіть в найкритичніших питаннях національної безпеки – питання стандартизації вкрай запущені, – див звіт на цю тему з останніх семінарів АППАУ 
• В Україні немає 1-го координатора процесу гармонізації, що стосується ринку промислових АСУ. На «верхньому рівні» є декілька ДП (дочірніх державних підприємств) серед яких легко заплутатись, але найголовніше – їхні відповіді та реакція на запити типово «совкові».  Ні публічних звітів, ні нормального сайту, ні публікацій про стандарти, ні навіть пристойного е-мейлу чи телефону з  відповідальним. Разом з тим, вони фінансуються за наш кошт – платників податків…
• Серед  4 технічних комітетів (62,65,73 та 90-ий – серед 155 технічних комітетів по стандартизації), що мають пряме відношення до промислової автоматизації, ми не знайшли жодного відповідального за стандарти ISA 88, 95, 99
• Звернення в Мінекономрозвитку, яке мало б координувати роботу між різними ДП та технічними комітетами, та володіти всією інформацією –  також (поки що) нічого не дають
• Немає єдності в питаннях стандартів серед ВУЗ-ів, а великі бренди –імпортери ведуть себе пасивно в цих питаннях. Чому – до кінця незрозуміло.
• Навіть ті стандарти, які вже гармонізовані (як ДСТУ EN-15232 за 2011 р.) – є маловідомими та не використовуються навіть тими гравцями, кому вони справді потрібні
• Наше відставання від Росії (та інших країн) в цих питаннях зростає. Незважаючи на нібито «ізольованість» та «свій шлях» в розвитку, наші сусіди куди більш енергійні та цілеспрямовані в цих питаннях.  В них вже є затверджені ISA-95, є чимало гармонізованих стандартів в області безпеки, що діють на національному рівні, велика увага приділяється популяризації цих стандартів, ведуться роботи по іншим важливим напрямкам.

З позитиву. Деякі стандарти вже гармонізовані – як вже згаданий ДСТУ EN-15232, є МЕК 61850 і очевидно інші. Звичайно ж,  всі знають про мови програмування згідно МЕК 61131-3, хоча навряд чи цей стандарт офіційно гармонізований. Але знову ж – де знайти всю інформацію, що ще є – невідомо по причинам вказаним вище. Є велика надія на нову команду Мінекономрозвитку, що зараз ініціює ряд змін в напрямку гармонізації. Відомо вже, що один з їх перших кроків стосується саме публічного викладу всіх існуючих стандартів на «світ божий».Уточнення щодо ролі АППАУ. Наразі ми беремо на себе роль каталізатора процесів в цих питаннях, – в перспективі також промоутера та  координатора, – але не більше! На безпосереднє виконання – хоча б переклад, –  сил, часу та ресурсів в нас поки що немає.

6.Де можна знайти початкову інформацію?

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

• Що таке ISA 99  
• Що таке ISA 95 і навіщо він потрібен    
• Що таке IEC 61850
• Введення в ISA 88
  

Є також маса інших просвітніх презентацій та документів англійською, та самі стандарти ISA 88 (англ.) та 95 (рос.), – можемо надавати їх по запиту.

7.Що робить АППАУ, щоб прискорити впровадження сучасних стандартів?

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

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

8.Чи потрібно щось робити до повного перекладу та сертифікації цих стандартів в Україні?

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

9.Чи будуть ці стандарти обов’язковими для виконання?

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

10.Як можна допомогти АППАУ та самому собі в реалізації стратегії переходу на європейські стандарти?

Наші рекомендації – очікування:

• Інтеграторам: почати з ISA-88 – кращі комунікації, оптимізація та уніфікація на рівні ТЗ та програмного коду, – давно назрілі питання. Починайте впроваджувати та інформуйте спільноту про свої здобутки.
• ВУЗ-ам: впроваджуйте елементи вказаних стандартів в учбові програми. Інформуйте колег та нас про свої напрацювання, – це зекономить ресурси інших колег.li>
• Замовникам: якщо ви плануєте чи переглядаєте свої корпоративні стандарти у вказаних областях – саме час подумати про ISA 88, 95, 99. Залучайте членів АППАУ до їх адаптації під ваші вимоги – окремі експерти в нас вже є.
• Вендорам: подумайте як ви інтегруєте елементи вказаних стандартів в  ваших промоцій них матеріалах. Також будемо вдячні за популяризацію та демонстрацію елементів цих стандартів у ваших продуктах. А також просимо залучати до вирішення питань ваших європейських колег, відповідальних за сертифікацію МЕК – вони є в кожній великій компанії. В них є досвід, знання та зв’язки – так необхідні нам сьогодні.

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

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

P.S. будемо говорити про стандарти 27 травня на засіданні клубу «Технічний директор»,  в Дніпропетровську – реєстрація триває.

                                                                                                                                              Ген. директор АППАУ Юрчак О.В.

развития. Согласно Правил клуба презентации вендоров или интеграторов в стиле рекламы своих продуктов запрещены, а приветствуются представления международных стандартов, конкретных кейсов – примеров и лучших практик с демонстрацией вклада реализованных АСУ в экономику предприятия. 

В программе клуба 27 мая:

• Об АППАУ: цели – стратегия, роль клуба «Технический директор» – ген. директор АППАУ Юрчак А.В.
• Опыт крупных предприятий ГМК по интеграции различных систем управления (краткие представления – состав уточняется и  дискуссия)
• Выступления членов АППАУ – предложения для интеграции АСУ. Роль стандарта ISA-95 в интеграции систем управления.
• Определение ключевых вызовов по интеграции АСУ ТП в Украине (общая дискуссия)
• Фуршет, не формальное общение. 

Приглашаются:  руководители отделов и департаментов АСУ ТП промышленных предприятий 

Спонсор мероприятия: компания «Phoenix Contact», модератор дискуссии – Юрчак А.В.

Дата и время проведения: 27 мая, с 16 до 20 часов

Место проведения: г. Днепропетровск,  Национальный горный университет, пр. К. Маркса, 19, аудит. 5/34

Условия участия: бесплатно для заказчиков из пром. предприятий и членов АППАУ. Для других желающих – стоимость участия составляет 200 грн с человека.

3.Вибір мови та підходи до програмування.

Яка мова краще? 

О! Це саме те професійне питання на форумах, що збирає багатьох програмістів, які починають тролити один одного! Ну що ж, далі йде суто суб’єктивна моя думка (хе, наче в попередніх пунктах була об’єктивною).  

Вибирайте мову програмування в залежності від: 

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

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

У якихось стандартах (не пам’ятаю яких) виділені різні типи технологічних процесів: неперервні (Continues), періодичні (Batch), дискретні (Discrete). Для неперервних процесів, зокрема для реалізації контурів регулювання підходить FBD/CFC (повноцінний), для періодичних SFC/Grafcet, для дискретних LD/IL, ST – універсальний.  І тут треба сказати про дуже важливий момент – реалізація мов на стільки відрізняється, що в деяких ПЛК, по суті повноцінно використовується тільки одна, а інші для програмістів перестають існувати взагалі. Програмісти! Суперечки щодо мов не мають змісту, поки ви не приземлите їх на конкретну платформу! 

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

 Звичайно найбільш універсальні це текстові мови типу ST чи IL. Однак, коли справа йде про швидкість відлагодження та інтуїтивну зрозумілість, ці мови поступаються графічним. Так, наприклад з одного погляду на  LD в онлайн режимі можна зрозуміти який “контакт не пропускає далі струм і чому не спрацьовує котушка”, іншими словами яка умова не виконалася, щоб спрацював дискретний вихід.  Тому для великої кількості взаємопов’язаних умов по”І” чи “АБО”, мова LD можливо буде самим підходящим варіантом.

 

 

Мова FBD (з тим функціоналом що в деяких ПЛК мають CFC) доволі наглядно зображають контури регулювання. Нижче на рисунках видно як виглядять однакові програми на мовах FBD та ST.

 

 

 

А ось, як це може виглядіти в онлайні. Відповідно в FBD та ST. 

Для Batch процесів (про бачки, Batch звичайно не від слова бачок, тим не менше) – найбільш підходить  SFC/Grafcet, але можна використати так званий автоматний підхід.

Ви знаєте що таке автоматний підхід?

Не знаєте? Ні, до АК немає ніякого відношення. Хоч може він і не автоматний?…  Я впевнений, що Ви ним користуєтеся … хоч я бачив таких, що  не користуються. 

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

1. простоювання
2. умова кнопка “пуск” – наповнення продукту 1 до середнього рівня
3. умова сер.рівень – наповнення продукту 2 до верхнього рівня
4. умова верхній рів. – нагрівання
5. умова досягла температура – витримка
6. умова досяг час – злив до нижнього рівня

Як повинна вести себе програма при зливі і відключенні датчика верхнього рівня? Правильно, ніяк, тобто продукт далі повинен зливатися. А знаєте, як веде себе програма у 100% студентських лабораторних роботах при першій перевірці на LD чи ST? (І тут у мене зараз ухмилка на всю морду ліца) Вона відкриває кран наповнення 2-го продукту! Чому? Та тому що спрацьовує середній рівень який відкриває клапан 2-го продукту, і вже не спрацьовує верхній, по якому його закривали. Тобто алгоритм керування в даному випадку повинен бути прив’язаний не тільки до датчиків, а і до стану(кроку) процесу.

 У мові SFC/Grafcet, сама мова будується на понятті кроку. Якщо ж ви користуєтесь іншою мовою, можна ввести додаткову змінну кроку. Тоді умова відкриття 2-го клапану звучала б десь так: “Якщо крок=2 і датчик_середнього_рівня=ВКЛ тоді  клапан2=ОТКЛ; клапан2=ВКЛ; крок=3”  

Якщо так просто можна реалізувати автоматний підхід, навіщо тоді SFC/Grafcet? 

Це можуть оцінити тільки користувачі сильних реалізацій SFC/Grafcet, коли він (SFC) є в складі даного ПЛК, і коли є необхідність в реалізації управління складними періодичними процесами. Слід не забувати про такі необхідні речі як:

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

Типовою помилкою при цьому є написання всієї програми тільки в кроках секцій SFC. Пам’ятайте, що є речі, які не залежать від активності кроку, тому їх треба писати незалежно на інших мовах, або в постійно діючому кроці! Ще одним можливим недоглядом є відсутність програмної реалізації ініціалізації мережі SFC/Grafcet. Якщо умова переходу принципово не виконується, ваша програма зависне на цьому кроці! Що тоді повинна робити експлуатація!? Дайте здогадаюсь – перегрузити ПЛК! Це недопустимо! Зробіть екстрену кнопку ініціалізації SFC, не будьте байдужі до проблем експлуатації, у експлуатаційників хороша пам’ять і вони бувають злими!    

У скількох місцях ваша програма змінює значення однієї і тієї ж змінної? 

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

Ви любите цикли? 

Цикли – дуже потрібна річ, але не настільки, щоб тулити їх усюди. 

По-перше, новачки так і хочуть, щоб програма в циклі не пішла далі поки не спрацює умова. І вони довго не можуть зрозуміти чому спрацьовує сторожовий таймер, який їх просто нервує. Перехід до розуміння циклічності виконання ПЛК як правило проходить доволі важко, це ж зміна парадигми від “клацнув воно щось зробилося і зупинилося” до “вічно щось повинно виконувати, причому те саме”. Якщо вже треба підрахувати щось з використанням ітерацій, може є сенс кожну ітерацію запускати в наступному виклику задачі? Досвідчені скажуть “Так цикли ж не для цього потрібні!”. Так, згоден, але ж я звертався не до досвідчених! Цикли можуть знадобитися для інших задач, наприклад програмної обробки для однотипних об’єктів. Тому…

По-друге.  Якщо ви звикли до усіляких відлагоджувальних точок зупину, щоб подивитися, а що там всередині на n-й ітерації, то … треба згадати що при цьому зупиняється ПЛК, і … управління процесом теж! Так, є і інші механізми відлагодження, але є ще ефект #платфородепендента. Просто пам’ятайте про це, коли у вас буде вибір робити цикл з 5-ма ітераціями чи викликати їх окремо. 

По-третє. Якщо Вам, скажімо, треба буде деякі елементи в процесі наладки виключати з циклу? Так, додаткові іфи спасуть ситуацію. Просто черговий раз подумайте.

Якщо у Вас склалося враження наче я #циклофоб, то мушу Вас заспокоїти, що це зовсім не так. Хоча, цикли мені робили і погану послугу, вірніше я собі ними,..  ну Ви зрозуміли.

Ви користуєтесь стрибками по міткам?    

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

4.Робота зі змінними.

А скільки у вашій програмі глобальних змінних, може варто їх опустити на рівень локальних? 

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

Ох, знову набивати уставки! Та скільки можна?!

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

Буратино дали три яблока. Два он съел. Сколько яблок осталось у Буратино? Думаете одно? Ничего подобного. Никто не знает сколько у него уже было яблок до этого. Мораль — всегда обнуляйте переменные!

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

 Як Ви називаєте змінні ПЛК?

На моєму першому об’єкті змінні називалися так: “VitrataSokuNaDruhuSaturaciju”. Все зрозуміло? Ну звичайно, навіть тим, хто не знає що таке ПЛК. Однак подумайте, як буде виглядіти формула з 10-ма змінними подібного типу, скільки прийдеться працювати мишкою і буферизувати зображення у своїй голові.  Не налякав? То може ви швидко зможете знайти потрібну змінну серед декількох сотень, чи тисяч, не користуючись пошуком? 

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

Для кожного типу об’єкту автоматизації може використовуватися свої підходи. Крім особливостей об’єкту можуть бути вироблені  корпоративні підходи (однакові у всіх програмістів однієї фірми). Комусь подобається угорська нотація, комусь система KKS, комусь своя власна (а чому б ні?). Головне – системність найменування! 

Мені ближче робити наскрізне найменування відповідно до функціональних позначень на схемах автоматизації. Що значить наскрізне? Це значить, що берете Ви схему автоматизації і бачите там датчик “TT1a”, що підключається до ПЛК. Як ви думаєте, як в мене змінна називається? Вгадали – “TT1a”. Ви скажете, “а якщо там додаткові перетворення йдуть з цілого в дійсні, а ще є фільтрація (а це обов’язково повинно бути для аналогових сигналів), там же ж не одна змінна?!” Так, але суфікси та префікси використовувати ніхто не забороняє (рекомендую ознайомитися з ISA 5.1), наприклад “TT1a_raw”. А Ви не здогадуєтесь яке ім’я я дам заданому значенню для цієї температури? Точно, “TT1a_SP”. Але на цьому наскрізність не закінчується, так само я дам назву тегу в SCADA, причому набирати мені буде ліньки, тому я просто скопіпащу/імпортую/злінкую (вибрати доступне). Тепер у мене у всіх програмах та ще й на схемах (можна і на принципові схеми ті самі дод. позначення ввести) ідентифікація змінних процесу однакова. Це не я видумав, перейняв традиції програмістів інтеграторів-цукровиків.         

Важкі комунікації? Може прийшов час переглянути адресацію мережних змінних?

Якщо змінних у вас багато, а обмін скажімо зі СКАДОю важкий, то треба  групувати змінні за адресами. Тобто розміщувати комунікаційні змінні в суміжних адресах. СКАДі простіше витягувати змінні групою, ніж по одній. Так, наприклад, якщо використовується Modbus, то зчитування 2-х числових змінних з адресами 1 та 200 займе більше часу ніж зчитування 50-ти змінних від 10 до 59. Чому? Так працює протокол Modbus і більшість протоколів промислових мереж.  

5.Налагодження програми.

“Мені тут треба одну змінну змінити. Зупиняйте свої сталелитейні процеси. Я перевантажує ПЛК і будемо пробувати” 

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

Перш за все звикайте до думки, що у вас немає можливості зупиняти контролер. Принаймні при найменшому чиху в програмі. А отже НЕ НАЖИМАЙТЕ КНОПКУ СТОП НА ПАНЕЛІ ІНСТРУМЕНТІВ тільки тому, що треба змінити кусок кода. Ви працюєте з промисловими контролерами, відлагодження програми яких без зупинки ПЛК є однією з головних необхідностей! А погані звички СТОПати, залишаються надовго і це не дуже добре.     

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

Як перевірити роботу програми без об’єкту?

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

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

 

 

 

3. Вибір мови та підходи до програмування.

Яка мова краще? 

О! Це саме те професійне питання на форумах, що збирає багатьох програмістів, які починають тролити один одного! Ну що ж, далі йде суто суб’єктивна моя думка (хе, наче в попередніх пунктах була об’єктивною).  

Вибирайте мову програмування в залежності від: 

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

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

У якихось стандартах (не пам’ятаю яких) виділені різні типи технологічних процесів: неперервні (Continues), періодичні (Batch), дискретні (Discrete). Для неперервних процесів, зокрема для реалізації контурів регулювання підходить FBD/CFC (повноцінний), для періодичних SFC/Grafcet, для дискретних LD/IL, ST – універсальний.  І тут треба сказати про дуже важливий момент – реалізація мов на стільки відрізняється, що в деяких ПЛК, по суті повноцінно використовується тільки одна, а інші для програмістів перестають існувати взагалі. Програмісти! Суперечки щодо мов не мають змісту, поки ви не приземлите їх на конкретну платформу! 

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

 Звичайно найбільш універсальні це текстові мови типу ST чи IL. Однак, коли справа йде про швидкість відлагодження та інтуїтивну зрозумілість, ці мови поступаються графічним. Так, наприклад з одного погляду на  LD в онлайн режимі можна зрозуміти який “контакт не пропускає далі струм і чому не спрацьовує котушка”, іншими словами яка умова не виконалася, щоб спрацював дискретний вихід.  Тому для великої кількості взаємопов’язаних умов по”І” чи “АБО”, мова LD можливо буде самим підходящим варіантом.

 

 

Мова FBD (з тим функціоналом що в деяких ПЛК мають CFC) доволі наглядно зображають контури регулювання. Нижче на рисунках видно як виглядять однакові програми на мовах FBD та ST.

 

 

 

А ось, як це може виглядіти в онлайні. Відповідно в FBD та ST. 

Для Batch процесів (про бачки, Batch звичайно не від слова бачок, тим не менше) – найбільш підходить  SFC/Grafcet, але можна використати так званий автоматний підхід.

Ви знаєте що таке автоматний підхід?

Не знаєте? Ні, до АК немає ніякого відношення. Хоч може він і не автоматний?…  Я впевнений, що Ви ним користуєтеся … хоч я бачив таких, що  не користуються. 

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

1. простоювання
2. умова кнопка “пуск” – наповнення продукту 1 до середнього рівня
3. умова сер.рівень – наповнення продукту 2 до верхнього рівня
4. умова верхній рів. – нагрівання
5. умова досягла температура – витримка
6. умова досяг час – злив до нижнього рівня

Як повинна вести себе програма при зливі і відключенні датчика верхнього рівня? Правильно, ніяк, тобто продукт далі повинен зливатися. А знаєте, як веде себе програма у 100% студентських лабораторних роботах при першій перевірці на LD чи ST? (І тут у мене зараз ухмилка на всю морду ліца) Вона відкриває кран наповнення 2-го продукту! Чому? Та тому що спрацьовує середній рівень який відкриває клапан 2-го продукту, і вже не спрацьовує верхній, по якому його закривали. Тобто алгоритм керування в даному випадку повинен бути прив’язаний не тільки до датчиків, а і до стану(кроку) процесу.

 У мові SFC/Grafcet, сама мова будується на понятті кроку. Якщо ж ви користуєтесь іншою мовою, можна ввести додаткову змінну кроку. Тоді умова відкриття 2-го клапану звучала б десь так: “Якщо крок=2 і датчик_середнього_рівня=ВКЛ тоді  клапан2=ОТКЛ; клапан2=ВКЛ; крок=3”  

Якщо так просто можна реалізувати автоматний підхід, навіщо тоді SFC/Grafcet? 

Це можуть оцінити тільки користувачі сильних реалізацій SFC/Grafcet, коли він (SFC) є в складі даного ПЛК, і коли є необхідність в реалізації управління складними періодичними процесами. Слід не забувати про такі необхідні речі як:

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

Типовою помилкою при цьому є написання всієї програми тільки в кроках секцій SFC. Пам’ятайте, що є речі, які не залежать від активності кроку, тому їх треба писати незалежно на інших мовах, або в постійно діючому кроці! Ще одним можливим недоглядом є відсутність програмної реалізації ініціалізації мережі SFC/Grafcet. Якщо умова переходу принципово не виконується, ваша програма зависне на цьому кроці! Що тоді повинна робити експлуатація!? Дайте здогадаюсь – перегрузити ПЛК! Це недопустимо! Зробіть екстрену кнопку ініціалізації SFC, не будьте байдужі до проблем експлуатації, у експлуатаційників хороша пам’ять і вони бувають злими!    

У скількох місцях ваша програма змінює значення однієї і тієї ж змінної? 

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

Ви любите цикли? 

Цикли – дуже потрібна річ, але не настільки, щоб тулити їх усюди. 

По-перше, новачки так і хочуть, щоб програма в циклі не пішла далі поки не спрацює умова. І вони довго не можуть зрозуміти чому спрацьовує сторожовий таймер, який їх просто нервує. Перехід до розуміння циклічності виконання ПЛК як правило проходить доволі важко, це ж зміна парадигми від “клацнув воно щось зробилося і зупинилося” до “вічно щось повинно виконувати, причому те саме”. Якщо вже треба підрахувати щось з використанням ітерацій, може є сенс кожну ітерацію запускати в наступному виклику задачі? Досвідчені скажуть “Так цикли ж не для цього потрібні!”. Так, згоден, але ж я звертався не до досвідчених! Цикли можуть знадобитися для інших задач, наприклад програмної обробки для однотипних об’єктів. Тому…

По-друге.  Якщо ви звикли до усіляких відлагоджувальних точок зупину, щоб подивитися, а що там всередині на n-й ітерації, то … треба згадати що при цьому зупиняється ПЛК, і … управління процесом теж! Так, є і інші механізми відлагодження, але є ще ефект #платфородепендента. Просто пам’ятайте про це, коли у вас буде вибір робити цикл з 5-ма ітераціями чи викликати їх окремо. 

По-третє. Якщо Вам, скажімо, треба буде деякі елементи в процесі наладки виключати з циклу? Так, додаткові іфи спасуть ситуацію. Просто черговий раз подумайте.

Якщо у Вас склалося враження наче я #циклофоб, то мушу Вас заспокоїти, що це зовсім не так. Хоча, цикли мені робили і погану послугу, вірніше я собі ними,..  ну Ви зрозуміли.

Ви користуєтесь стрибками по міткам?    

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

4. Робота зі змінними.

А скільки у вашій програмі глобальних змінних, може варто їх опустити на рівень локальних? 

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

Ох, знову набивати уставки! Та скільки можна?!

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

Буратино дали три яблока. Два он съел. Сколько яблок осталось у Буратино? Думаете одно? Ничего подобного. Никто не знает сколько у него уже было яблок до этого. Мораль — всегда обнуляйте переменные!

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

 Як Ви називаєте змінні ПЛК?

На моєму першому об’єкті змінні називалися так: “VitrataSokuNaDruhuSaturaciju”. Все зрозуміло? Ну звичайно, навіть тим, хто не знає що таке ПЛК. Однак подумайте, як буде виглядіти формула з 10-ма змінними подібного типу, скільки прийдеться працювати мишкою і буферизувати зображення у своїй голові.  Не налякав? То може ви швидко зможете знайти потрібну змінну серед декількох сотень, чи тисяч, не користуючись пошуком? 

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

Для кожного типу об’єкту автоматизації може використовуватися свої підходи. Крім особливостей об’єкту можуть бути вироблені  корпоративні підходи (однакові у всіх програмістів однієї фірми). Комусь подобається угорська нотація, комусь система KKS, комусь своя власна (а чому б ні?). Головне – системність найменування! 

Мені ближче робити наскрізне найменування відповідно до функціональних позначень на схемах автоматизації. Що значить наскрізне? Це значить, що берете Ви схему автоматизації і бачите там датчик “TT1a”, що підключається до ПЛК. Як ви думаєте, як в мене змінна називається? Вгадали – “TT1a”. Ви скажете, “а якщо там додаткові перетворення йдуть з цілого в дійсні, а ще є фільтрація (а це обов’язково повинно бути для аналогових сигналів), там же ж не одна змінна?!” Так, але суфікси та префікси використовувати ніхто не забороняє (рекомендую ознайомитися з ISA 5.1), наприклад “TT1a_raw”. А Ви не здогадуєтесь яке ім’я я дам заданому значенню для цієї температури? Точно, “TT1a_SP”. Але на цьому наскрізність не закінчується, так само я дам назву тегу в SCADA, причому набирати мені буде ліньки, тому я просто скопіпащу/імпортую/злінкую (вибрати доступне). Тепер у мене у всіх програмах та ще й на схемах (можна і на принципові схеми ті самі дод. позначення ввести) ідентифікація змінних процесу однакова. Це не я видумав, перейняв традиції програмістів інтеграторів-цукровиків.         

Важкі комунікації? Може прийшов час переглянути адресацію мережних змінних?

Якщо змінних у вас багато, а обмін скажімо зі СКАДОю важкий, то треба  групувати змінні за адресами. Тобто розміщувати комунікаційні змінні в суміжних адресах. СКАДі простіше витягувати змінні групою, ніж по одній. Так, наприклад, якщо використовується Modbus, то зчитування 2-х числових змінних з адресами 1 та 200 займе більше часу ніж зчитування 50-ти змінних від 10 до 59. Чому? Так працює протокол Modbus і більшість протоколів промислових мереж.  

5.Налагодження програми.

“Мені тут треба одну змінну змінити. Зупиняйте свої сталелитейні процеси. Я перевантажує ПЛК і будемо пробувати” 

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

Перш за все звикайте до думки, що у вас немає можливості зупиняти контролер. Принаймні при найменшому чиху в програмі. А отже НЕ НАЖИМАЙТЕ КНОПКУ СТОП НА ПАНЕЛІ ІНСТРУМЕНТІВ тільки тому, що треба змінити кусок кода. Ви працюєте з промисловими контролерами, відлагодження програми яких без зупинки ПЛК є однією з головних необхідностей! А погані звички СТОПати, залишаються надовго і це не дуже добре.     

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

Як перевірити роботу програми без об’єкту?

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

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

Олександр Пупена, викладач, Київ 

Публікації по темі: Послання зеленим і недосвідченим #почтипрограмістам ПЛК від #читопрограмера-читовиклада. Ч.1

 

 

 

Использование в данном контексте термина “рецептура”, как последовательности выполнения определенных действий для изготовления конечного продукта, возможно, и не очень удачно, но стало на сегодняшний день стандартом де-факто.

Иногда такой тип производств называют процессным. Понятно, что на предприятиях используется самое разнообразное оборудование, системы управления строятся на основе различных вычислительных средств. Для обеспечения их совместного функционирования необходимо, чтобы все эти системы соответствовали единым стандартам, использовали унифицированный способ записи рецептур,  отображения текущего состояния оборудования и т.д. Тенденция развития корпоративных систем привела к пониманию, что для эффективного управления такими сложными производствами нужен единый стандарт, и в конце 80 х гг. ХХ века была начата работа по созданию стандарта ANSI/ISA 88 (часто также используется сокращение S88). Разработчик стандарта – комитет SP88 международной организации ISA, объединившей конечных пользователей и поставщиков оборудования и решений для периодического производства. В 1995 г. стандарт был одобрен сообществом ISA и получил официальный статус. За прошедшие годы ISA 88 получил широкое распространение и стал признанным стандартом реализации систем управления периодическим производством. Несмотря на кажущуюся очевидность востребованности, для признания стандарта S88 потребовались годы. Но в результате стандарт стал широко применяться на практике и получил дальнейшее развитие в виде стандарта ISA 95. В настоящее время стандарт развивается и совершенствуется, большой объем информационных материалов можно найти на официальном сайте организации www.isa.org. В статье сделана попытка проанализировать имеющиеся материалы по практическому использованию стандарта S88 при решении различного рода задач как самостоятельно, так и в связке с другими нормативными документами. При подготовке статьи использовались материалы ассоциации ISA, World Batch Forum, ассоциации MESA International, а также материалы специализированных Internet сайтов. К сожалению, на нашем рынке ISA 88 пока недостаточно популярен, переводных материалов по применению стандарта практически нет, статьи в специализированных изданиях носят единичный характер. Настоящая статья ставит своей целью не предоставить детальное описание стандарта, а осветить основные подходы, заложенные в нем, и зародить интерес к более подробному изучению сути вопроса. За рамками статьи сознательно оставлены вопросы программной реализации, а также сравнение существующих систем управления периодическим производством. Предпочтение отдано более “концептуальным” темам, ориентируясь в которых, заинтересованный специалист без труда выберет средство реализации.

Структура стандарта ISA-88

Стандарт ISA-88 разрабатывался на базе существовавшего на тот момент стандарта NAMUR N33 и был призван помочь в решении нескольких фундаментальных проблем, таких как отсутствие единой модели рецептурного производства, сложность согласования требований, трудности интеграции решений различных поставщиков, сложное управление рецептурным производством. Для решения этих проблем необходимо было определить единые модели, терминологию, структуру данных и язык описания процесса. Структура стандарта соответствует поставленным задачам и включает четыре части: 

• ISA88.01 1995, Batch Control Part 1: Models and Terminology – определяет стандартные модели и терминологию для формализации требований к системам управления периодическим производством, его эквивалент – IEC 61512 1; 
• ANSI/ISA 88.00.02 2001, Batch Control Part 2: Data Structures and Guidelines for Languages – определяет модели данных для управления производством, структуры данных для обмена информацией, а также форму записи рецептуры;
• ANSI/ISA 88.00.03 2003, Batch Control Part 3: General and Site Recipe Models and Representation – определяет модели для представления обобщенных рецептур и обмена такими рецептурами между подразделениями предприятия, а также между предприятием и его партнерами;
• ANSI/ISA 88.00.04 2006, Batch Control Part 4: Batch Production Records – определяет модели данных и ориентировочную модель системы для записи, хранения, извлечения и анализа данных о ходе периодического производства. 

Кроме того, готовится к выходу пятая часть стандарта Implementation Models & Terminology for Modular Equipment Control, цель которой состоит в определении методов формализации интеграции производственного и упаковочного оборудования, а также корпоративных информационных систем. Также на основе концепций стандарта ISA 88 разработаны конструкции XML для обмена данными в системах управления периодическим производством – BatchML.

Основные понятия и модели ISA-88 

Прежде всего, стандарт ISA 88 определяет понятие периодического процесса (batch process) – это процесс, результатом которого является производство конечного количества продукта путем выполнения над некоторым количеством исходных материалов (сырья) упорядоченной последовательности воздействий за ограниченный период времени с использованием одной или более единиц оборудования. Это определение однозначно указывает на наличие ограниченного интервала времени (периода) изготовления конечного количества продукта (то есть партии) и тем самым отделяет  периодический производственный процесс от непрерывного или дискретного процесса. Термин “партия” (“batch”) имеет значения: во-первых, “материал, который производится в результате одной стадии batch process”, а во-вторых – некая сущность, определяющая производство материала на любой стадии процесса. Под термином “рецептура” (“recipe”) определяется минимально необходимый набор информации, которая уникальным образом определяет требования к производству конкретного продукта. Для управления периодическим производством необходимы три сущности (и именно их охватывает стандарт):

• формальное определение процесса изготовления партии продукта – рецептуры (recipe); 
• информация об оборудовании, которым нужно управлять (модель оборудования);
• формальное определение управляющих воздействий. 

Чуть более подробно остановимся на модельных представлениях, описанных в стандарте. Стандарт ISA 88.01 определяет физическую и процедурную модели производства. Физическая модель  в целом определяет производственную ячейку оборудования, необходимого для производства партии продукции. Основным понятием здесь является модуль – основная единица оборудования, выполняющего главный шаг процесса. Физическая модель (модель оборудования) в общем случае включает семь уровней:

1. блок управления (Control Module); 
2. агрегат (Equipment Module); 
3. установка (Unit); 
4. ячейка про цесса (Process Cell); 
5. производственный участок (Area); 
6. производство (Site); 
7. предприятие (Enterprise). 

Ячейка процесса (Process cell) – единственный обя зательный уровень модели. Она включает все установ ки, агрегаты и блоки управления, требуемые для про изводства одной или нескольких партий. Ячейка процесса может включать линии (train), состоящие из оборудования, необходимого для изготовления определенной партии. При изготовлении партии необязательно используется все оборудование, входящее в линию, в то же время одна линия может быть задействована одновременно в изготовлении нескольких партий и/или продуктов. Ячейка процесса может включать более одной линии, при этом линия не может вклю чать оборудования, не входящего в ячейку процесса. Ячейки процесса служат основой для планирования и управления производством продукции. Процедурная модель (модель ТП) в общем случае включает четыре уровня:

• фаза (Phase); 
• производст венная операция (Operation); 
• процесс (Unit Procedure); 
• технология (Procedure). 

Технология (Procedure) на стратегическом уровне определяет по следовательность мероприятий, которые необходимо выполнить для производства партии. Она состоит из требуемого числа процессов (Unit Procedure). А про цесс, в свою очередь, состоит из связной последова тельности производственных операций, выполняемых на одной установке, и  моделирует один из ос новных шагов (стадий) создания партии. Предпола гается, что в каждый момент времени на установке выполняется только одна операция, при этом каждая операция полностью завершается в пределах установки. Тем не менее множество процессов одной технологии может выполняться на нескольких установках одновременно, а каждый процесс на своей установке. Применимость моделей стандарта ISA- 88 как к крупным производствам со сложными ТП и структурой оборудования, так и к простым по структуре предприятиям неоднократно проверена на практике. Определяемые стандартом модели позволяют встраивать простые процессы в процессы более высокого уровня, наличие которых не предполагалось изначально. Данный факт дает возможность небольшим предприятиям благодаря применению стандарта ISA-88 получить больше возможностей в части кооперации с крупными предприятиями – заказчиками их продукции. Подходы, аналогичные модели оборудования стандарта ISA- 88, и ее развитие в стандарте ISA -95 могут использоваться и при описании не только производственных технологических объектов и структур. При практической реализации иерархия моделей стандарта используется как этапность для внедрения системы управления. Внедрение происходит снизу вверх: сначала блоки управления, затем модели оборудования, затем фазы оборудования и далее до моделей процедур. Этот процесс внедрения может быть прекращен на любой стадии, как только будут выполнены требования к системе управления. При этом на каждой из стадий внедрения (на каждом из уровней модели) достигаются вполне определенные результаты, что дает возможность оценить экономическую эффективность каждого из этапов внедрения в отдельности. 

Совместное использование ISA-88 и ISA-95 

На современном производственном предприятии АСУ ТП должны взаимодействовать не только с аналогичными системами, но и с системами управления верхнего уровня, в том числе MES и ERP. Если обмен данными с MES еще может быть описан в рамках ISA 88, то передача данных от MES к ERP требует уже других стандартов. Один из наиболее известных стандартов обмена информацией между MES и корпоративными информационными системами – стандарт ISA-95. На первый взгляд, ISA-95 и ISA-88 прекрасно дополняют друг друга, так что складывается впечатление, что вместе они охватывают все производственные системы – от MES до локальных систем управления. Но в то же время между двумя стандартами существуют серьезные различия, касающиеся моделей оборудования, функциональных и информационных моделей. Без учета таких различий трудно рассчитывать на положительный результат при совместном использовании стандартов.

Рис. 1. Взимное наложение охвата функций ISA-88 и ISA-95

Рассмотрим сначала, чем отличаются модели оборудования в ISA-95 и ISA-88. В основе иерархической модели оборудования ISA-95 лежат физическая модель ISA-88 и модель производственного предприятия университета Пердью PERA (Purdue Enterprise Reference Architecture). От первой взята общая структура модели, а от второй – деление модели на уровни управления. Кроме того, в модель ISA-95 добавлены элементы для производств дискретного и непрерывного цикла, а также для складского хранения. В модели же ISA-88 учитывалось только периодическое производство, хотя имеется достаточно много примеров ее использования на производствах другого типа. Так как стандарт ISA-95 ориентирован в первую очередь на организацию обмена информацией между корпоративными и производственными системами, в модель оборудования ISA-95 не входят модули оборудования и управления. Теми же обстоятельствами обусловлены различия в функциональных моделях стандартов. Цель создания функциональной модели ISA-88 – описать ход производственного процесса, в то время как в ISA-95 отдельные функции рассматриваются, прежде всего, как источники информации, передаваемой между MES и системами верхнего уровня. Большинство функций ISA-88 и ISA-95 можно сопоставить друг другу (рис. 1), правда, при этом нужно учитывать, что функции ISA-95 более “общие”. Причина этого все та же – приоритет batch процессов в ISA-88. Например, один из элементов модели ISA-88 – управление рецептурными данными (Recipe Management). Но на производствах другого типа для описания последовательности этапов производственного процесса могут использоваться стандартные процедуры (Standard Operation Procedure, SOP) или сборочные инструкции. Поэтому вместо управления рецептурными данными в ISA-95 говорится об управлении определениями продукции (Production Definition Management). Рецептурные же данные рассматриваются как частный случай определения. С другой стороны, в ISA-88 значительно больше внимания уделяется функциям, работающим на уровнях 0 (уровень физических процессов), 1 (уровень средств измерения и исполнительных механизмов) и 2 (уровень мониторинга, автоматизированного и диспетчерского управления процессами производства), таким как “Управление оборудованием” (Unit Supervision) и “Управление процессом” (Process Control). ISA-95, напротив, лишь вскользь упоминает подобные функции.

Основное внимание в ISA-95 уделено взаимодействию систем управления и корпоративных информационных систем, поэтому передаются только данные, нужные системам верхнего уровня для планирования и контроля производственного процесса. ISA-88 описывает данные, необходимые для совместной работы систем управления, а также для детального планирования работы. Например, при описании потенциальной производительности (Production Capability Information) в ISA-95 используется информация об оборудовании, материалах и персонале. Из трех понятий только одно – оборудование – применяется в ISA-88. Но в системе, реализованной в соответствии с ISA 88, оборудование может быть описано гораздо более подробно, с делением на отдельные модули. Для каждого модуля, в свою очередь, можно хранить информацию о возможной производительности и использовать ее при выборе маршрута материала в реальном времени. Но системам верхнего уровня ничего об этом известно не будет, они будут получать информацию о производительности единицы оборудования в целом. Из вышесказанного становятся понятны возможности совместного применения ISA-95 и ISA-88. MES, реализованная в соответствии с ISA-95 может “знать”, какие данные можно получить от систем управления периодическими процессами, соответствующими ISA-88. С другой стороны, разработчики системы управления могут предположить, какие данные потребуется передавать на верхний уровень. Знание стандартов, умение их применять и находить точки соприкосновения необходимо и для постановки задачи на разработку интегрированной системы управления, и для технического проектирования такой системы.

Применение ISA-88 для производственных процессов другого типа

Несмотря на то, что ISA- 88 разрабатывался для периодического производства, стандарт довольно успешно применяется и для непрерывного и дискретного производства. Можно назвать довольно много отличий непрерывного производства от периодического, среди которых и более высокий расход ресурсов, и меньшая номенклатура выпускаемой продукции, и большая продуктивность непрерывных производственных процессов. Однако с точки зрения управления непрерывный производственный процесс очень похож на периодический процесс с нулевым временем простоя при смене рецептуры, длительными интервалами между сменой рецептов и отсутствием остановки материальных потоков. С дискретными производственными процессами ситуация сложнее, общих черт с периодическим производством здесь еще меньше. Но и здесь вполне можно определить единицы оборудования, модули оборудования и управления. Вопрос лишь в том, насколько оправданно использование ISA-88 в “неродной” для него области. Производственные процессы, в том числе периодические, зачастую тесно связаны с производственными процессами другого типа. Например, после выпуска партии таблеток (периодический процесс) их необходимо расфасовать по упаковкам (дискретный процесс). В этом случае удобно было бы описать обе производственные линии на одном и том же языке, например, на языке ISA-88. При наличии такого описания гораздо проще обеспечить взаимодействие систем управления производственными линиями. Именно в подобных случаях применение ISA-88 к процессам, отличным от batch, выглядит оправданным. Особого внимания заслуживает использование ISA-88 для управления безостановочными (non stop) производственными процессами. Такие процессы могут быть как непрерывными, так и дискретными: их отличительная особенность – недопустимость прерывания производственного процесса, обусловленная физическими особенностями процесса (производство стекла) или требованиями оптимального использования оборудования (розлив и упаковка). Главное препятствие к применению ISA-88 – правило, согласно которому в одной единице оборудования в каждый момент времени используется только одна рецептура.  Очевидно, что в случае безостановочного процесса это правило не реализуемо, иначе при переходе с одного вида продукции на другой неизбежно возникали бы остановки, недопустимые в нашем случае по определению. Поэтому для безостановочных процессов правила ISA-88 были модифицированы следующим образом:

• единица оборудования завершает выполнение главной фазы обработки в тот момент, когда на ее входе появляется последний элемент старой партии; 
• старая рецептура используется до тех пор, пока элементы старой партии не выйдут за пределы единицы оборудования; 
• перемещение последнего элемента старой партии отслеживается; 
• сигнал об окончании партии посылается в тот момент, когда первый элемент новой партии выходит за пределы единицы оборудования. 

 

Рис.2. Пример использования NS-88

Пусть имеется участок производственной линии, состоящий из двух аппаратов. Первый аппарат заполняет упаковочную емкость, а второй – закрывает ее крышкой (рис. 2). Рассмотрим, как будет работать линия в ходе смены партии с B1 на B2. При этом вы полняются следующие действия: 

Следовательно, измененные правила (их еще называют NS88 – non stop S88) позволяют формализовать непрерывные процессы и тем самым значительно расширяют сферу применения ISA-88.

Заключение

Ключевым аспектом ISA-88 является то, что стандарт поддерживается большинством крупных поставщиков оборудования, поэтому и специалистам производственных предприятий, и системным интеграторам, и разработчикам оборудования необходимо иметь как минимум общее представление о самом стандарте и его применении. Физическая модель ISA-88 может применяться для иерархического представления технологического оборудования, когда каждая единица оборудования делится на модули, состоящие в свою очередь из более мелких модулей. Такое деление позволяет структурировать описание производства, а также может служить в качестве основы для разработки системы кодирования этапов производства. Наличие иерархической модели позволяет также четко определить модули ПО системы управления и связи между ними и избежать “спагетти эффекта”. Модульный подход к построению системы управления имеет множество преимуществ. Например, система управления единицей оборудования может быть заменена или модифицирована без особого влияния на другие модули. Достаточно только потратить некоторое время и средства на создание структурированного описания и разработку модулей. В дальнейшем затраты окупятся за счет возможностей повторного использования и увеличения гибкости систем управления оборудованием.

Авторы:  И.С. Решетников (ООО “Газпромремонт”), А. П. Козлецов (ООО “АМастер”), Д.Е. Анисимов (ООО Ктмпания “ТЕРСИС”

Источник: “Автоматизация в промышленности”, апрель 2010

 

Бенчмаркинг широко используется  в бизнесе – как стратегия и как инструмент, а особенно он полезен в ситуациях «дезориентации», – когда сложно понять, что же является наиболее эффективным способом или практикой в конкретной области.  

Типичный контекст дезориентации –  «высокий уровень технологий vs реалии рынков» 

Этот контекст наблюдали совсем недавно на семинарах EIA-2015. Практически каждый день мы видели ситуации, которые неподготовленного слушателя могут полностью обескураживать

• Методики ROI / TCO давно есть, активно применяются в ряде отраслей, но в АСУ ТП заказчики редко считают и разбираются в этом (ситуация 1-го семинара)
• Технологии безопасности и эксплуатационной готовности на порядок превышают уровень (требования) законодательной нормативной базы (2-ой семинар)
• Готовые предложения по сертификации, по маркетингу и продажам, помощи экспортерам давно есть – но рынок реагирует очень вяло (3-ий день)

Конфуз во всех этих случаях один и тот же, в виде вопроса это формулируется как «… тогда кому и зачем это надо?». Под «это» мы подразумеваем любое предложение – методику, технологию, услуги – продукты и т.п.  Эти примеры показательны и достойны обобщения – в большинстве случаев хай-тек технологии сегодня значительно превышают уровень среды.

Ответ во всех этих случаев один и тот же – «ищите свой бенчмарк». В случае ROI / TCO, решений по безопасности не надо далеко ходить. Многие западные компании, имеющие свои заводы в Украине, давно применяют свои корпоративные стандарты, – которые, естественно, отвечают лучшим мировым стандартам.  

Например, в апрельском номере журнала «Мир автоматизации» приведена интересная публикация о «Карлсберг-Украина», где есть целый ряд вещей, выходящих за рамки представлений о «среднерыночной температуре» по всему украинскому рынку. Здесь есть стандарты по окупаемости, которые рассчитывает и знает каждый руководитель тех. служб, а решения АСУ активно внедрятся для задач по энергоэффективности. Завод, в свою очередь, является примером для других заводов Карслсберг по всему миру – его показатели по энергоэффективности на 2-ом месте. 

Общая методика бенчмаркинга

Итак, если вы хотите достичь высоких показателей в какой-либо области, следуйте таким правилам:

1.Установите свои цели и области для сравнения: что и где вы хотите достичь? В примере выше – это область энергоэффективности.

2.Определите ключевой показатель эффективности (KPI):  в примере выше – это потребление электроэнергии на единицу произведенной продукции.

3.Определите организацию для бенчмарка  – если ваша организация работает в пивоваренной отрасли, то смело можете брать за бенчмарк «Карлсберг-Украина»:)  

4.Сравните их метрики – KPI на фоне своих: какой ваш расход электроэнергии? – на заводе «Карлсберг» это 5,7-5,9 кВт/час на 1 гекталитр (100 литров).

5.Сравните эффективность: вот здесь самое интересное – нужно понять, почему есть такая разница (особенно если она значительная).

6.Разработайте и внедрите программу достижения:  в данном примере указаны 3 стратегии достижения высокой энергоэффективности, – возможно, у вас подобных нет, либо они не на том уровне. Но вы можете быть даже лучше – бенчмарк предполагает принцип, с которым японцы вышли на американский рынок автомобилей в 70-ых годах прошлого столетия, – «сделай то же самое, но чуть лучше».

7.Установите систему постоянного мониторинга улучшений – теперь внедряйте программу и контролируйте ее выполнение. 

Примеры бенчмарк от АППАУ

В АППАУ мы постоянно занимаемся мониторингом – исследованием  лучших практик в области промышленной автоматизации. В этом часть нашей миссии – определение и доведение до рынка лучших практик и стандартов. 

Что мы сегодня можем предлагать как бенчмарк – примеры для подражания и наследования? Вот несколько таковых в области готовых стандартов:

• Общие стандарты по промышленной автоматизации: первая тройка – это ISA 88, 95, 99. В этой публикации мы объяснили, почему актуальны именно эти стандарты, и как мы их продвигаем.
• Стандарт качества в области системной интеграции: на протяжении нескольких лет мы продвигаем стандарт CSIA
• Стандарты в области проектного управления (тоже очень важная область для интеграторов): из двух подобных систем – IMPA (европейская ассоциация) и PMI (американская), мы двигаем последнюю – просто потому, что знаем партнера, который может быстро поставить в вашей организации эти стандарты («Спайдер-Украина»).
• Стандарты в разработках и общеуправленческих методах: все больше мы склоняемся к методам Agile (гибкие методы). Agile – сегодня практически стандарт в ИТ-отрасли (SCRUM и подобные). Его освоение поможет интеграторам быть более эффективными. Но сила Agile в его универсальности, – он может быть применим и в других областях. 

Еще раз о том, зачем  нужны стандарты. Прежде всего, для экономии собственных сил и ресурсов. Проще говоря, когда в очередной раз вы захотите что-либо усовершенствовать в своей организации, задумайтесь – возможно, это уже есть в мире. Так стоит ли «изобретать велосипед»? Может проще взять за основу готовый стандарт? 

А это идеи для сравнения и размышления, по-нашему опыту это сегодня лучшие практики и примеры в Украине и на пространстве стран СНГ

• Производственная группа «Техинсервис» – лучший представитель инжиниринговой группы в Украине нового поколения, демонстрирующая в полной мере компетенции и экспертизу в области машиностроения, промышленной автоматизации, технологического проектирования и строительства «под ключ». Они же могут служить примером экспортера в инжиниринге – сегодня компания поставляет свои услуги в десяток стран мира, включая Западную Европу.
• «Укртранснафта» – хороший пример создания и ведения комплекса корпоративных стандартов в области автоматизации, – от ТЗ на проект, архитектуры АСУ и до задач по обслуживанию.
• Филиал Danfoss в Украине – лучший пример маркетинга и продвижения среди близких к пром. автоматизации отраслей. Отличный сайт и контент, работа в соц. сетях, лоббирование на уровне гос. стандартов и т.п. маркетинговые ходы обеспечили компании идейное лидерство в своей отрасли.
• Сайт Phoenix Contact  – лучший среди западных поставщиков промышленной автоматизации в Украине, де-факто, уже стоящий на пороге е-коммерции. Это признают многие клиенты.

Также можно рассматривать общие примеры для подражания игрокам промышленных АСУ. Например, ИТ отрасль – хороший пример консолидации (несколько ассоциаций), гибкости, быстрой реакции на изменения окружающей среды, а также лоббирования своих интересов на государственном уровне. 

К этой же области сравнений можно отнести наш первый публичный опыт оценки качества месседжей – как умения явно и ярко представлять свои достижения и конкурентные преимущества.

Бенчмарком могут быть лидеры соседних рынков – например, в области системной интеграции РФ для меня таковыми являются «Инсист-Автоматика» (г. Омск), «Ракурс» (г. Санкт-Петербург), «РТ-Софт» (г. Москва). 

Бенчмарком могут быть и конкретные имена. Например, из наших членов ассоциации большое уважение вызывает активность Александра Пупены в области просвещения рынка или публичная представленность и активность Олега Михайлова, ген. директора Phoenix Contact (включая соц сети). Очень интересным нам кажется опыт Максима Романова, нач. департамента АСУ «Арселор Миттал» с проведение хакатонов на своем предприятии. И этот список можно продолжать…

Безусловно, многие из этих примеров не претендуют на полноценный бенчмарк – мы их и преподносим здесь пока как «идеи для размышления». Полноценное бенчмаркинговое исследование включает много критериев, требует квалификации  и серьезной подготовки. Например, известный украинский поставщик в области СRM, компания Terrasoft в течение ряда лет фигурирует в тех или иных мировых бенчмаркинговых исследованиях в своей области.  В апреле 2015 они вошли в исследование Gartner в сегменте СЕС (сustomer engagement centre). Одно попадание на такой уровень – это уже признание. Это все равно как попасть в финал Оскара или финал Лиги чемпионов. В примере интеграторов выше стоит отметить аналогичное признание на мировом уровне «Инсист-Автоматики» как лучшего Системного интегратора мира в 2013 г.

                                                                                              ***********

Однако ничто не мешает каждому из нас двигаться маленькими шагами – даже и без глобальных сравнений. Указанные примеры лучших практик и достижений нужны в каждой области – и именно как ориентир для следующего шага в развитии. С этого года мы активно мониторим все бенчмаркинговые показатели в области нашей дорожной карты развития.

А какой бенчмарк в своей области вы можете предложить? Или вам нужен, но вы не находите? – Присылайте нам свои истории, примеры и вопросы –  мы с удовольствием будем их продвигать. 

И не забывайте, что в составе АППАУ ваши бенчмарки будут быстрее создаваться и реализовываться:)

А. В. Юрчак

В качестве основного источника были использованы несколько отчетов Aberdeen Group – ведущего консалтингового агентства из США, на результаты исследований которого ссылаются многие мировые бренды промышленной автоматизации. Зная огромную разницу между уровнями производства «там» и «здесь», все же интересно провести некоторые параллели – тем, более что Aberdeed Group дает ясные рекомендации для «отстающих».

Методика Aberdeen Group

Методика базируется на бенчмаркинговых сравнениях опрашиваемых компаний в рамках 2-х главных фреймоворков (моделей). Что такое бенчмарк и бенчмаркинг – мы писали совсем недавно. В результате – в каждой области сравнения, компания анализирует Лучших (Best-in-Class, их 20%), Середнячков (Average – 50%) и Отстающих (Laggards – 30%). Итак, вот эти модели, по  которым идет сравнение:

1. PACE (Pressure, Actions, Capabilities, Enablers) – Рыночное давление, Действия (в ответ на это давление), Способности, Ускорители (технологии). Ключевая особенность этой модели в том, что все 4 элемента должны быть сбалансированы.

Pressure – Actions – Capabilities – Enablers

Например, если для интегратора давление рынка состоит в сокращении сроков реализации проектов и лучшем управлении Качеством-Бюджетом, то очевидной реакцией на это должна быть Стратегия по внедрению у себя стандартов проектного управления. Технологии  (enablers) для этого давно известны (софт как MS Project management), но, как правило, проблема всегда с Capabilities – людьми, их навыками и знаниями, а также с внедрением в своей компании соответствующих процедур и процессов. 

А вот другой пример нашего применения этой модели из форума лидеров в феврале. Мы аргументировали, что без изменений на уровне Технологий и Способностей, стратегия компаний как «фокус на экономических показателях» – пустой звук. И снова же – проблемы здесь на уровне Capabilities (к сожалению, перевод как “Способности” далеко не лучшим образом передает значение этого слова).

Справедливо и обратное – все разговоры о модных сегодня Internet of Things, Industry 4.0 и т.п. похожи на попытки “поставить ракетный двигатель на телегу”:  без фундаментальных изменений на уровне Организации (Люди, Бизнес-процессы, Стратегии…) шансов на внедрение  мало.

 2.Конкурентный фреймворк – Aberdeen Group

Здесь идет более глубокий анализ Стратегий игроков – Aberdeen Group пытается понять, почему «лучшие – лучшие».  По-сути, речь об областях создания реальных конкурентных преимуществ на уровне тех же Capabilities & Enablers. Aberdeen Group выделяет 5 областей конкурентных сравнений

Опрашивая сотни и тысячи предприятий (преимущественно в США) Aberdeen Group затем резюмирует, почему и насколько «Лучшие» в этих областях отличаются от «Середнячков» и «Отстающих».

Посмотрим, как Aberdeen Group применила эту методику к вопросам интеграции АСУ. Мы нашли 2 отчета на эту тему – датированные 2008 (1) и 2011 гг (2). На них также ссылаются и включают в свои материалы АВВ, Rockwell Automation, Honeywell и другие мировые бренды. Мы также видели несколько интересных презентаций на эту тему с упоминанием стандарта  ISA-95 (3).

Цели и KPI современного производства

Ссылаясь на ответы респондентов, Aberdeen Group больше всего акцентирует на  2-х вызовах предприятий – снижении себестоимости производства и быстрой реакции в условиях изменчивой рыночной среды. Если первое связано с ростом глобальной конкуренции, то причин второго много – волатильность рынков, ошибки в планировании, сезонность спроса, кризисные явления, региональные отличия, новые регуляторные ограничения и т.п.

Отсюда – 3 главных KPI и вот как Aberdeen Group оценивает их в категории “Лучшие”:

1. Своевременная поставка – 97% 

2. Коэффициент эффективности установленного оборудования (ОЕЕ) – 87%

3. Использование сырья и материалов – 97%

Эти данные (2008) намного лучше средних показателей по рынку. В отчете 2011 г также звучат 2 других показателя:

4. успешный вывод новых продуктов: у лучших 94%, в то время как у «отстающих» – всего 49%, и

5. рассогласование «план-факт» реальной операционной маржи по отношению к корпоративному плану – у лучших это +5%, в отстающих -3%.

Интересно понять, какие промежуточные KPI имеют «Лучшие». По-сути, именно благодаря им, «Лучшие» имеют такие результаты.

• «Лучшие»  в 2 раза опережают остальных в операциях по автоматическому сбору данных, их хранению и аналитике
• Они в 4 раза лучше в том, что касается стандартизации KPI по измерению и оптимизации различных важных производственных показателей
• Они в 2,5 раза лучше в установлении связи и интеграции производственных KPI – с таковыми на уровне управления всем производством
• Они также на 50% лучше других в автоматизации производств, на 17% – в системах управления качеством и на 55% – в использовании продвинутых систем планирования производствами (APS).

И вот что делают лучшие не так, как другие:

• Случаи создания Управляющего Исполнительного комитета ((Executive streering committee) по управлению производственными стратегиями развития в лучших на 50% больше, чем в «отстающих». 
• АСУ ТП и автоматический сбор данных – основные блоки для построение систем управления производством. Лучшие имеют показатели автоматического сбора данных в 2 раза лучше, чем отстающие, так как инвестировали в эти системы и под-системы.
• Лучшие внедрили системы управления в реальном времени, реагирующие на внешние события и позволяющие быстро вносить оптимальные изменения в производственные процессы, системы обслуживания и качества, логистику и складское хозяйство. Они делают это под зонтиком Управления Операционным производством (Manufacturing Operation Management, – МОМ*).

Советы для «отстающих»

Немного зная наши рынки – и не только в области промышленной автоматизации, но и в других производственных и непроизводственных сферах, – не вызывает сомнения наша общая принадлежность к «отстающим». Впрочем, не мы одни такие – практически сюда попадут все в категории «развивающиеся страны». Поэтому интересно взглянуть, какие советы дает Aberdeen Group для этой категории:

1.Создайте Исполнительный комитет, наделенный функциями и соответствующими полномочиями в областях

• Производственные Стратегии – определение необходимых изменений, порядок и приоритеты инвестиций
• В комитет входят представители как производства, так и АСУ- ИТ-служб – они разделяют ответственность по реализации  этих стратегий

2.Ясно определите ключевые KPI – как результаты реализации этих стратегий. Один из ключевых должен быть снижение себестоимости  продукции. Стратегии, которые, как правило, ведут к этому – создание команд и программ непрерывного улучшения, прозрачность всех производственных данных и операций, оптимизация активов и лучшее управление исходными сырьем – энергией.

3. Стандартизируйте по всему предприятию

• технологические и бизнес-процессы в производстве
• Измерение KPI
• Обработку исключительных событий

По сути, эти рекомендации – часть модели зрелости в данной области. Модель зрелости ясно говорит о том, что нужно делать, когда «вы только учитесь ходить» и что – «когда вы уже на уровне мастера спорта».

Ключевые вопросы дискуссии 

Нам кажется, наработки Aberdeen Group  весьма полезны для наших дискуссий об интеграции АСУ ТП – АСУП. По сути – при их внимательном рассмотрении, – мы уже находим много ответов на свои вопросы о приоритетах и порядке развития в этой области. Одновременно, эти и другие материалы ставят много новых вопросов на уровне всего сообщества – например, банального вопроса о состоянии «автоматического сбора и прозрачности данных по всему предприятию». Если этого нет – то в чем смысл инвестиций в масштабные ИТ-системы, как MES и производственные модули ERP ? И сколько нужно человек, чтобы эти данные “собирать ручками”?

27 мая на Клубе “Технический директор”  в Днепропетровске  – и далее, в других городах, – мы как раз и будем обсуждать эти вопросы

1. Производственные стратегии 

• Каковы их цели и приоритеты сегодня
• Как сегодня они разрабатываются, кто за них отвечает, включают ли они стратегии АСУ ТП и современные концепции как MES/MOM и подобные? 

2. Есть ли в этих стратегиях ясный и полный баланс KPI уровня бизнес – с производственными, включая показатели на уровне АСУ ТП?

3. Насколько слаженно работают команды АСУ и ИТ по их внедрению этих стратегий?

4. На каком уровне находится автоматический сбор данных с нижних уровней АСУ ТП с их дальнейшей передачей «наверх»? Это – must be условие начального уровня, без которых эффективность ИТ-систем резко падает.

5. Насколько процессы измерения производственных данных, их сбора и передачи, а также их аналитика в соответствующих KPI – стандартизированы по всему предприятию? Это также условие начального уровня развития.

Кажутся ли вам эти вопросы релевантными?  – речь, прежде всего, о сегментах наших крупных промышленных предприятий? С теми,  кто сможет – часть вопросов начнем обсуждать уже 27 мая в Днепропетровске.

 

                                                                                               Юрчак А.В., ген. Директор АППАУ

 

* Примечание: МОМ (Manufacturing Operation Management) – другая, более современная аббревиатура MES. Некоторые авторы считают, что речь просто о «ребрендинге» – так как по большому счету принципы и идеология MES не изменились. Другие – включая Aberdeen Group полагают, что практика MES не доказала свою эффективность (по отношению к инвестициям), а с учетом новых стандартов (как ISA-95) и технологий, лучше переходить на расширенный концепт МОМ.

Полезная информация: 

1.Manufacturing Operation Management. Next generation of manufacturing system. Aberdeed Group, 2008

2.Operational Intelligence. Aligning Plant and corporate IT, Aberdeed Group, 2011

3.Transforming Operation strategies to deliver more agility and flexibility using ISA-95, Rod Parry, Factory IT, 2012.