Виконавча дирекція АППАУ

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

В программе клуба 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.

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

Отныне мощные библиотеки ресурсов по ТЕХНОЛОГИЯМ И РЕШЕНИЯМ УПРАВЛЕНИЯ ПРОИЗВОДСТВАМИ (кейс-стади, е-книги, вебкасти и т.д.) доступны для всех членов АППАУ. Благодаря этому ассоциация еще больше усилит свою кооперацию с брендами как ABB и Rockwell Automation, которые тоже являются членами MESA International, и сможет на новом уровне предоставлять участникам рынка АСУ важную информацию по теме интеграции АСУ ТП – АСУП и другим вопросам уровня MES.

Присоединяйтесь к АППАУ!

менеджменте, проектном управлении, маркетинге и т.д.

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

Что может взять отрасль АСУ из принципов и опыта разработчиков в стиле Agile? Об этом будет идти речь на круглом столе 11 июня.

В программе дискуссии:

• Принципы  и методики Agile – развитие в Украине, обзор, тенденции
• Что дает Agile – примеры реализаций от украинских ИТ-компаний
• Как Agile работает в других сферах управления
  
• Что такое Agile Project Management
  
• Первые шаги для новичков

Спикеры и докладчики ИТ-рынка – в процессе согласования. 

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

Приглашаются все желающие.

Модератор: Александр Юрчак, ген. директор АППАУ.

Встреча состоится в четверг, 11 июня, с 17:30 до 20:30 

Адрес: г. Киев, ул. Крещатик 27а, 2-й этаж, НСЖУ (Национальный Союз Журналистов Украины), ближайшее метро Театральная, схема здесь.

Участие по предварительной регистрации – по е-мейл: svitlana.gryntsevytch@gmail.com, тел. для справок: 050 447 60 78 

Стоимость участия – 100 грн, для членов АППАУ – 50 грн. 

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

В этом году семинар посетило рекордное количество посетителей – около 230 человек из более чем 10 стран мира. Кроме производителей сахара стран ЕАЭС в нем приняли участие поставщики оборудования для сахарной отрасли, проектные организации, представители научных организаций из Польши, Германии, Италии, Франции, России и Украины.

Также в рамках семинара состоялась церемония награждения победителей Конкурса Евразийской ассоциации сахара в номинации «Лучший сахарный завод Евразийского экономического союза 2014 года» по итогам работы сахарных заводов при переработке сахарной свеклы урожая 2014 года и сахара-сырца.

На 15-ти из 21-го заводов-победителей успешно эксплуатируется оборудование производства «Техинсервис», в частности:  

Диплом I степени:

• ОАО «Добринский сахарный завод» (вакуум-аппарат ТВА-75 (2014); реконструкция известково-газовой печи ИПШ-150, установка пресс-фильтра КФ-1200, модернизация известковой печи, система автоматизации фильтр-прессов (2013); установка 2 вакуум-аппаратов ТВА-75 3-го продукта (2012); поставка дозатора известняка, лебедки скипа (2011); внедрение систем автоматического управления различных станций (2006); реконструкция фильтров ФиЛС-100 1-й (10 шт.) и 2-й (9 шт.) сатурации с использованием секционных фильтровальных рамок и применением бесшовного фильтровального рукава, с САУ, установка 10-ти фильтров с эжекционным удалением осадка UFE-0.8, система автоматического управления станцией сокоочистки (2004)).

• ОАО «Ольховатский сахарный комбинат» (установка выпарного аппарата ТВП-673 и 6-ти комплектов фильтровальных элементов для фильтров ТF-95 (2012); реконструкция тепловой схемы, установка подогревателей на утфельном паре, реконструкция известкового отделения и станций фильтрации, внедрение 18-ти фильтров TF, внедрение систем автоматического управления, изготовление нержавеющих аппаратов для хроматографии, САУ фильтрами 1-й сатурации, САУ фильтрами 2-й сатурации, САУ контрольной фильтрацией, САУ жомопрессовым отделением (2005)).

• ООО «Ромодановосахар» (поставка газораспределительной системы для сатуратора 1-й сатурации (трубки Рихтера) (2009)).
• ОАО «Слуцкий сахарорафинадный комбинат», ОАО «Городейский сахарный комбинат», ООО «Олымский сахарный завод», ОАО «Лебедянский сахарный завод»

Диплом II степени:

• ЗАО «Грязинский сахарный завод» (установка вакуум-аппарата ТВА-40 3-го продукта (2012); пуск 5-тикорпусной выпарной станции с системой автоматизации, внедрение новой тепловой схемы (2010); САУ известняково-обжигательной печи, реконструкция известняково-обжигательной печи (2004)).
• ОАО «Елань-Коленовский сахарный завод» (реконструкция продуктового цеха, внедрение вакуум-аппаратов ТВА, системы автоматического управления диффузионным и жомопрессовым отделениями (2005); реконструкция известняково-обжигательных печей, установка 2-х вакуум-аппаратов ТВА-75 (без утфельной камеры) (2004)).
• ОАО «Заинский сахар» (установка 2-х комплектов реконструкции дозировки шихты (2012)).
• ЗАО «Уваровский сахарный завод» (установка и автоматизация 4-х вакуум-аппаратов ТВА-60 1-го продукта, автоматизация общих параметров продуктового отделения (2012)).
• ОАО «Ульяновский сахарный завод» (реконструкция известково-обжигательной печи (2012)).
• АО «Успенский сахарник» (установка 8-ми комплектов фильтровальных элементов для фильтров ТF-70, модернизация системы управления 8-ми фильтров TF-100 1-й сатурации (2012); автоматика сушки сахара (2008); установка центрифуг 1-го продукта Fives Cail с автоматикой «Техинсервис», реконструкция станций фильтрации, реконструкция тепловой схемы, внедрение 16-ти фильтров TF, пленочных выпарных аппаратов ТВП9-3250 и ТВП 12-4870, установка подогревателей на утфельном паре, реконструкция известкового отделения, внедрение системы автоматического управления всего завода (2005); внедрение трехпродуктовой схемы – 4-е вакуум-аппарата ТВА-60 (без утфельной камеры), тепловая схема продуктового отделения, смеситель утфеля и мелассы, система автоматики кристаллизатора охлаждения утфеля го продукта (2004); 5-ть вакуум-аппаратов ТВА-60 (без утфельной камеры), автоматизация продуктового цеха в рамках 1-го продукта (2003)).

Диплом III степени:

• ОАО «Земетчинский сахарный завод» (модернизация ПО 1-го продукта и  СКАДА-системы (2012); внедрение автоматики сушки сахара и вакуум-аппарата 2-го продукта с маточной системой (2010); внедрение САУ вакуум-аппаратами 3-го продукта, интеграция в общую систему управления цехом (2009); автоматика вакуум-аппарата 3-го продукта (2008); реконструкция продуктового отделения, внедрение системы автоматического управления продуктовым отделением, САУ вакуум-аппаратами 1-го продукта, САУ вакуум-аппаратами 2-го продукта, САУ общими измерениями продуктового цеха (2007)).
• ОАО «Кристалл-2» (Новокубанский) (САУ жомопрессовой воды (2013); установка и автоматизация вакуум-аппарата ТВА-60 комбинированного (II-III продукт) (2012); установка известково-обжигательной печи с системой автоматического управления, внедрение ТВА-60 с системой автоматического управления (2011); автоматизация конденсатного хозяйства, внедрено изменение в контур выпарной станции (2010); автоматика диффузии (2008); САУ фильтрами 1-й сатурации, САУ фильтрами 2-й сатурации, САУ вакуум-аппаратами 2-го продукта (2003); поставка 5-ти вакуум-аппаратов ТВА-60 (2001-2003); САУ выпарной станцией (2002); САУ вакуум-аппаратами 1-го продукта, реконструкция известняково-обжигательной печи (2001)).
• ЗАО «Тбилисский сахарный завод» (установка 4-х вакуум-аппаратов ТВА-60 для 1-го продукта (2004); поставка прямоточно-пленочного выпарного аппарата ТВП-2430х9, САУ выпарной станции, САУ фильтров 1-й сатурации (2003)).
• ЗАО «Сахарный комбинат «Отрадинский» (установка 5-ти фильтров ТF-150-50 1-й сатурации,  3-х  фильтров ТF-150-65 2-й сатурации, установка и пуск  кристаллизатора ТКВГ-500, установка 5-ти вакуум-аппаратов ТВА-75, автоматизация продуктового отделения (2011)).

На фото: Рудюк Л.С., технический директор «Техинсервис», и Пивкина В.В., главный технолог «Техинсервис», с главным технологом Скидельского сахарного комбината Трефиловой Е.И. на «Клубе технологов 2015» в Беларуси

• ОАО «Скидельский сахарный комбинат» (модернизация ПО выпарной станции, автоматизация 5-ти сиропных фильтров, ВКУ 2-го продукта, реконструкция производства лимонной кислоты с увеличением производительности до 3 000 тонн лимонной кислоты в год (2012); установка и запуск системы автоматизации, запуск 4-х вакуум-аппаратов 3-го продукта, установка мешалки маточного утфеля 3-го продукта, запуск 6-ти корпусной выпарной станции с установкой пленочного выпарного аппарата на 5-м корпусе, реконструкция системы автоматизации продуктового отделения и отделения кристаллизации сахара 3-го продукта, установка мешалки клеровки сахара 2-го продукта, установка и запуск системы автоматизации известково-обжигательной печи Ш-80 вместе с модернизацией известкового отделения, установка выгрузочного стола, транспортера подачи топлива и известкового камня (2010); реконструкция известково-обжигательной печи, внедрение САУ известково-обжигательной печью (2009); автоматика вакуум-аппарата 1-го продукта с маточной системой, внедрение ТВА-60 для маточного утфеля, мешалки приемные маточного утфеля 1-го и 2-го продукта, установка 7-ми фильтров ТФ-120 для 1-й фильтрации (2008); реконструкция тепловой схемы, внедрение пленочных выпарных аппаратов ТВП9-3250 и ТВП 12-4870, установка подогревателей на утфельном паре, установка вертикального кристаллизатора ТКВ-300 большой единичной мощности, внедрение нового цеха клеровки сахара-сырца (повышение мощности с 500 до 1100 т.), внедрение системы автоматического управления всего завода (2006); установка выпарных аппаратов ТВП-3250х12, подогревателя диффузионного сока ПДУ-170, 7-ми пластинчатых подогревателей сока перед выпарной станцией, 4-х пластинчатых теплообменников оттеков, 3-х трубчатых подогревателей, внедрение системы автоматического управления пленочным выпарным аппаратом, САУ станцией отвода конденсата пленочного выпарного аппарата, САУ регулировки нагрева подогревателей (2003); внедрение САУ дефекосатурацией, САУ камерными фильтр-прессами, САУ выпарной станции, САУ клеровального узла 2-го и 3-го продукта, клеровальный узел, модернизация 6-ти фильтров ФиЛС-100М 1-й сатурации, реконструкция известняково-обжигательной печи, ВКУ с нагревом диффузионного сока, оборотное водоснабжение (градирня) (2002)).
• ОАО «Викор» (Новопокровский)
• ОАО «Жабинковский сахарный завод» победил в номинации «За низкий расход условного топлива при переработке сахарной свеклы и сахара-сырца» (модернизация тепловой схемы, внедрение САУ известково-газовым отделением (2001); реконструкция известняково-обжигательной печи (1998)).

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

Справка:

В 2014 году сахарную свеклу перерабатывали 77 сахарных заводов государств-членов Евразийского экономического союза, доля производства сахара которых составила 18% от общего выпуска свекловичного сахара в мире.

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

• Состав участников получился сбалансированный  – члены АППАУ, и не только, была вся главная тройка: вендоры, интеграторы, крупные конечные заказчики. 
• Встреча происходила на базе кафедры электропривода местного горного университета.
• Главной темой была интеграция АСУ ТП – АСУП и вопросы вокруг состояния в этой области: барьеры, стандарты, решения
• АППАУ воспользовалась случаем, чтобы объявить свою новость – вступление в MESA International
• Спонсор мероприятия, Phoenix Contact, обеспечил достойное завершение – вся компания хорошо пообщалась и, можно сказать, сблизилась за дружеским ужином )

Самые интересные дискуссии

Общение разворачивалось вокруг вопросов, представленных в этой презентации. По-хорошему, уже ясно, что ISA 95 нужно представлять отдельно и основательно – семинар минимум на пол-дня не помешал бы. Однако вначале важно понять, с какой стороны заходить к этому – вот это мы и сделали.

Наиболее интересные моменты обсуждений и презентаций клуба 27 мая:

1.Материалы Aberdeen Group по темам, которые мы нашли – оказались как нельзя кстати. Но встал вопрос:  как это, особенно по уровню зрелости предприятий, применимо к нам.

2.Дискуссия с заказчиками (Arcelor Mittal, ДМДК и Метинвест) дала такой результат: 

• 100% мы прошли некоторые шаги на 1-ом начальном уровне (см рис ниже) – как а) ясные, формализованные требования по (автоматическому) сбору данных или б)  стандартизованные по предприятию KPI
• Более того – есть отдельные элементы 2-го уровня, – как архитектуры сетей по всему предприятию, стандарты качества и т.п.
• Однако другие элементы 1-го уровня – явно отстают ,  зачастую находятся на нулевом уровне. Речь о  выравнивание команд  ИТ – АСУ и др в программах постоянного улучшения,  стандартах для управления жизненным циклом промышленных АСУ,  ясных требованиях по операциям в рамках лучших практик MES/МОМ, а также формализованным стратегиям по АСУ и МОМ 
• Хорошо это или не очень? Должны ли предприятия последовательно проходить полностью 1-ый этап, прежде чем двигаться на следующий? Дискуссия по этому поводу вышла на резюме, что вопрос «должны – не должны» не стоит – это уже есть. Вопрос в другом – насколько эффективно «бежать впереди паровоза» в вопросах ИТ, оставив отдельные вопросы АСУ ТП в дремучем состоянии. Суждения разделились  – по мнению автора этих строк, такой подход вряд ли можно назвать эффективным.

3.Абсолютно в тему «выстрелил» короткий доклад Phoenix Contact с представлением ACRON – нового продукта компании для задач диспетчеризации на крупных предприятиях. Главное преимущество ACRON – начальная ориентация на сбор данных по самым разнородным интерфейсам по стыковке – интеграции данных с уровня SCADA или непосредственно с контроллеров, а также удобное быстрое формирование различных отчетов. Одним словом, все в духе Phoenix Contact – fast, easy, simple – и без привязки к какому либо одному бренду.  

Но самой интересной оказалась дискуссия по поводу баланса KPI. Вначале 3 группы представили, казалось бы близкие, если не одинаковые результаты – влияние АСУ ТП на себестоимость (KPI уровня MES-ERP) определяется на уровне учета затрат, как ресурсы и т.п. Однако на фоне представленных других статей себестоимости (см фото) – картинка получалась не четкой и слишком обобщенной. А главное – роль АСУ ТП, – так и не очевидной. Специалисты Arcelor Mittal, правда, отметили, что в их практике есть гораздо больше KPI на каждом уровне.

 

На фото –  Лев Ванян, ООО “Инновационно Технические Решения”, хорошо резюмировал общее мнение участников по тому, как сегодня выглядит баланс KPI 3-х уровней

Однако после представления слайдов ABB – Aberdeen Group на арену вышел главный производственный показатель OEE – Overall Equipment Effectiveness, – коэффициент эффективности установленного оборудования. Который, в свою очередь, состоит из 3-х показателей:

• Эксплуатационной готовности (бесперебойности)
• Производительности работы оборудования
• Качества выходной продукции

Очевидно, что АСУ ТП влияет на все 3 KPI. Расчет Aberdeen Group убедительно и наглядно демонстрирует, как небольшое увеличение ОЕЕ дает существенный рост прибыли. Проще говоря, управляя ОЕЕ (и именно через названные KPI, за которые отвечает АСУ ТП), вы управляете прибылью, ROI и другими показателями.

Похоже, эта раскладка понравилась всем участникам. Присутствующий директор АСУ крупного предприятия тут же заявил, что данные расчеты-объяснения необходимо предоставить всей команде финансистов и других важных лиц и забил «стрелку» с присутствовавшими менеджерами АВВ, от которых исходят эти материалы, включая калькуляторы ROI.

Выводы по клубу «Технический директор», 27 мая

Клуб удался – встреча получилась эффективной и приятной по всем параметрам. Выводы и направления действий: 

1. Объединение АСУ – острый вопрос, решение которого влияет на многие экономические показатели верхнего уровня. Его нужно обсуждать именно в командном стиле – АСУ ТП вместе с ИТ.
2. Степень нашей зрелости – самый начальный уровень, хотя отдельные прорывы есть на крупных и западных предприятиях. Но главная проблема в том, что целостного видения и подхода в этой области практически нет. Директора АСУ производств должны планировать стратегии АСУ ТП – в тесной связке с их вкладом и интеграцией на уровень MES – ERP. По крайне мере, иметь ясное видение, как это делать.
3. Стандарты интеграции есть –  это ISA 95 (уже есть на русском), который в свою очередь является частью более широких концепций, как MOM (Manufacturing Operation Management), поддерживаемых международными институциями – MESA International.
4. Однако на уровне знания этих стандартов – «поле не пахано», – вопросы просвещения стоят остро, и клуб это тоже продемонстрировал.
5. Позитив в том – что наши вендоры, – в том числе присутствовавшие на встрече члены АППАУ – Phoenix Contact и AББ Лтд уже имеют готовые наработки – как продукты, базирующиеся на этих стандартах, так и материалы просветительского характера. Нужно просто все это активнее пускать в работу. В общем – что мы вместе и делаем.

Ближайший клуб  “Технический директор” планируется в июле – мы пойдем на следующую итерацию в уже упомянутых расчетах ROI, добавляя к этому такую интересную вещь как расчеты TCO (полная стоимость владения). А пока переходим к теме AGILE – это логическое продолжение предыдущей темы. Ведь мы будем говорить не только о разработках, как и в случае ISA 95 / MES – корни и предпосылки те же, – в эпоху тотальной нестабильности все решает гибкость. Agile – это именно о гибких подходах, их принципах и о том, как они сегодня проникают во все сферы управления, производства и разработок. Приглашаем на Круглый стол АППАУ, 11 июня в Киев.