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

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

Agile – як відповідь на виклики ринку

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

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

Сергій Батюк, технічний директор «Клінкманн-Україна» описав портрет типового Системного інтегратора і наголосив, що питань до технічних компетенцій наших інтеграторів немає. А от щодо методів управління проектами та розробки ПЗ – питань чимало. Інтегратори АСУ ТП перебувають в умовах, коли середовище замовника не стабільне, технічне завдання ніколи не буде на 100% без змін і при цьому реалізація потрібна «на вчора»м Сергій Георгійович вірно відмітив, що це є «родова ознака проектів АСУ ТП». Так буде завжди. Відповідно рішення багатьох проблем з якістю, термінами та бюджетом лежать не в площині «гарний чи поганий замовник», а в площині власних методів та підходів до управління проектами.

Завершуючи вступ, ми відмітили, що динаміка розвитку ІТ значно вища і в той же час ІТ-технології все більше й більше проникають в світ низової автоматики, контролерів та SCADA-систем. Отже, щоб «вирівнятись» з ІТ у всіх відношеннях, потрібно брати за приклад не тільки технології, але й методи та підходи до розробки ПЗ та управління проектами.

Доповіді експертів з ІТ

Олена Прихнич, – співзасновник та бізнес-тренер агентства Е5, що спеціалізується в консалтингу по методам SCRUM, розповіла про принципи та переваги стилю Agile для розробки програмного забезпечення. Зокрема, Олена розкрила деякі так звані «артефакти» (особливості) SCRUM для розробників – як «спрінти», беклог продукту, скрам майстер, ретроспектива, тощо.  Метод SCRUM – один з багатьох методів Agile, але який домінує з великим відривом в розробках програмного забезпечення. Головні переваги для бізнесу – це швидкість отримання результату, швидка адаптація до змін, кращий контроль якості процесу розробки – через розуміння стану на кожен момент. Згідно статистики, кількість успішних розробок методами SCRUM в рази вища в порівнянні з класичним методом розробки «водопаду».

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

Власне, мова про проект, але в якому домінують всі ознаки Agile/SCRUM. В основі розробки – багато ітераційних циклів (спринтів), які в свою чергу розбиваються на 6 етапів. Тут є класичні етапи проектного управління – як Ініціація та Планування, де SOW – Statement of Work, – це той же Статут. Але є й інші – наприклад, з’являється Візія проекту, що включає в себе високорівневий дизайн, а також описання умов (загального контексту) бізнесу. Цікава також кінцівка – у вигляді запуску в експлуатацію, також включенні фази підтримки. Євген також підкреслив, що Agile в даному кейсі “продавав і сам себе”. Тобто, спочатку замовник не був готовий до роботи по цій технології і даний формат, – не більш ніж гнучка, гібридна модель різних методів управління.  Також через складність завдань та вимоги замовника довелось розширити набір регламентних документів. В цьому проекті регламенти включають 8 головних типів документів, – певний мікс методів SCRUM, класичного проектного та продуктового менеджменту.

Олександр Жебряков, – консультант датського агентства Ciklum Consulting був переконливий в своєму головному меседжі: «Agile – це не просто метод чи набір методів, це – філософія бізнесу». Ключовим в Agile є значний ріст ефективності роботи крос-функціональних команд через кращі комунікації, залучення та відповідальність. В цьому Agile кращий від класичних методів проектного управління, адже методі крос-функціональної командної роботи відомі й там. До вже зазначених принципів   Agile, що прозвучали в попередньому виступі, Олександр додав таку річ як потоки цінностей (values stream). А його приклади «про муки прожект менеджера», якому весь час не вистачає або ресурсу, або-та повноважень та впливу – здались релевантними до нашої аудиторії.

Автор цього звіту представив підходи Agile Project Management від Terrasoft (на жаль, представники компанії не змогли виступити). Terrasoft вдало інтегрує елементи Agile в класичний формат прожект менеджменту (на рис. нижче номерами вказані головні відмінності від класичного проектного управління). В самій розробці продуктів (Execution) є спринти, беклог, ретроспектива, демо, а трудовитрати обліковуються в story points. На етапі Ініціації з’являється така цікава річ як Дорожня карта проекту, на етапі планування (Elaboration) – Концепція (дуже близько до Візії в кейсі JBS), цікаво виглядає новий етап «Перехід до експлуатації» (Transition) ну і власне сама «Експлуатація» має речі, яких часом дуже бракує в АСУ ТП – «вивчені уроки» та «активацію підтримки проектного рішення».

Принаймі, наші опитування кінця 2014 р. не виявили якихось практик в управлінні досвідом клієнта серед гравців ринку АСУ ТП. В Terrasoft орієнтація на розвиток та управління досвідом інтегрована на рівні декількох практик. Крім вказаних елементів цікаво виглядають зміни структури управління проектом. Замість класичного прожект менеджера, команду очолює CSE – Customer Success Executive. В його відповідальності не 1 проект, а цілий пул проектів – це дає додаткові можливості в маневруванні ресурсами та автономність в вирішенні цих питань. Друга відмінність від класичного ПМ – його бачення переходить з рамок життєвого циклу проекту – на життєвий цикл клієнта. Тобто, CSE зацікавлений не просто в хороших результатах окремо взятого одного проекту – в його інтересах отримання нових і нових проектів від даного замовника. Звіт про  недавню конференцію Terrasoft, де згадуються і про практики Agile – див. тут.

Богдан Дучак з юридичної компанії Juscutum завершив представлення Agile висвітленням питань в юридичній площині. Це теж очевидна ознака зрілості Agile на ринку ІТ – як інакше можна інтерпретувати те, що механізми Agile прописуються в контрактах. Богдан вірно вказав на головне протиріччя багатьох класичних договорів – штрафи за недотримання ТЗ та результатів проекту, в той час як ці ТЗ та результати будуть на 100% змінюватись по ходу проекту. Досвід та практики Juscutum передбачають справді гнучкі підходи до регулювання конфліктних ситуацій, де одним з самих дієвих механізмів є (не тільки) фіксація «входу та виходу», – але й – а) фіксація механізмів роз рулювання конфліктних ситуацій, б) фіксація найбільш ефективних механізмів розробок та робіт проекту в тих аспектах, де залучається замовник.

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

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

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

 

При цьому я спираюсь на конкретну платформу, і дуже мало (не те щоб зовсім, але не достатньо) віддаю часу алгоритміці та підходам в розробці та наладці прикладного ПЗ для контролерів. Очевидно це у більшій мірі із-за того, що я, ще в студентські роки не проходив курсу на кшталт “розробки алгоритмів для систем керування в реальному часі”, та навіть не знаю, чи такі існують. Однак, постійно підробляючи програмістом (#читопрограмером) та наладчиком систем АСУТП, я, сам того не усвідомлюючи, вбирав від своїх колег кращі, на мою думку, практики, та відшліфовував свій стиль програмування.  Однак, дивлячись на молоде покоління, я бачу, що ті проходять такий саме шлях як і я, роблять ті самі помилки, зустрічаються з тими саме проблемами. 

І на цьому місці моєї писанини я уявляю, як Ви, потужний #суперпрограміст_АСУТП зі стажем (не сумніваюся ні грама), втрачаєте інтерес до нижченаписаного, адже ви цей шлях пройшли!  Тоді задумайтесь над тим, що можливо вам колись прийдеться доробляти програму зеленого програміста,… хоча я здогадуюсь чим це закінчиться – все викинете і поставите/напишете своє! Тоді … може вас нажахає ситуація, коли ви будете працювати в парі з молодим програмістом?! Аааа, Ви його навчите самі?! А може є сенс скоротити шлях молодого бійця ще до цього та визначити разом кращі практики? 

Я вважаю, що є сенс на першій ітерації принаймні спробувати виписати #суб’єктивно_кращі_практики, тобто визначити типові підходи до розробки прикладного ПЗ для систем керування на базі програмованих контролерів. Буде закид – можливо будуть коментарі, а це кращий зі спосіб вдосконалення і шляху до об’єктивності! Отже, цей матеріал можливо буде цікавим як молодим #почтипрограмістам так і дуже досвідченим #суперпрограмістам. Першим для навчання, другим в контексті “Ну-ну, чого я там не бачив? Хоч потролю!”. Саме конструктивного тролінга,  шановні програмісти-аси, я від вас і чекаю.     

Хтось із вас, очевидно #непрограмістів_контролерів_асутп (а може вони) скаже, що класичні комп’ютерні  #програмісти можуть похвалитися своїм високим пілотажем в даному питанні. У них же там такі дисципліни по програмуванню, алгоритмам і багато-чого корисного (без сарказму)! Але чомусь у мене виникають сумніви щодо калькування їх підходів у практику програмування контролерів в АСУТП. Чому? На це є багато причин, які пов’язані зі специфікою як систем керування так і типом об’єкту автоматизації (#техпроцес), і ось деякі з них: 

• функціонування системи в реальному часі, 
• перевага МЕК-овських мов програмування, 
• специфічність задач, 
• необхідність відлагодження програми без зупинок процесу, а отже і програми, 
• зміна коду по місцю #не_автором_програми
• далі думку можна розвивати для важливості і ексклюзивності наших асутпшних програмістів, але це якраз пункт для них, тому тут закінчу перелік 

То, можливо, необхідна своя дисципліна “розробка алгоритмів для контролерів АСУТП” а може вона вже є?

Хто зна? Що мені попадалося. Не можу сказати, що я досліджував дану проблему, все-таки не наукову статтю пишу, і не в науковому журналі, і не для науковців, і … ну ви зрозуміли. Деякі класичні алгоритми бачив у відомій книжці Ендрю Парра (доречі, в Інтернеті є перекладена російською версія). Приклади там реалізовані ще на ПЛК епохи 80-х та 90-х, але не повірите, практично нічого не змінилося! Кльова книга –  рекомендую для прочитання. 

 

Деякі підходи ми зі співавторами писали в методичках до курсового проекту, не так щоб багато, але трохи було. Немалий набір рекомендацій щодо побудови програми та її відлагодженні (наприклад з використанням примітивних імітаційних моделей) викладені і в нашому посібнику “Програмування промислових контролерів в середовищі Unity PRO” (це типу реклами). 

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

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

1. Загальні рекомендації.

Чи використовуєте Ви коментарі?

Завжди все коментуйте і документуйте. Щось змінили на об’єкті – запишіть. Нікого не здивував подібною заявою? Згадайте це, коли на наступний рік після гарячих пусконаладок будете правити свою програму. Ваша дисциплінарність повинна заставляти вносити правки не тільки в код програми  (навіть з коментарями), а і в свій щоденник (лог) проекту. Усі свої шишки, непорозуміння треба занотовувати, хоч кривим текстом з купою помилок (типу “клапан чогось дьоргався потім перстав, я так і не пньяв чому”, помилки не виправляти! – примітка до редактору), але обов’язково фіксувати. Це буквально 15-30 хвилин роботи, а економія при повторній наладці/відлагодженні/тиражуванні суттєва.    

Чи робите ви план робіт, алгоритм, чи продумовуєте структуру?

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

Як ви розробляєте програму для ПЛК нового для вас типу?

Дайте вгадаю – так як і для старого! Ну там же ж МЕК і все те саме! Ага! Новий ПЛК – нові проблеми, часто пов’язані саме з тим, що старі методи вирішення старих проблем не підходять для даного ПЛК. Як з цим можна боротися? Я підхожу до цього так: перед написанням програми з малознайомим ПЛК спочатку роблю міні-проект з достатнім функціоналом, щоб врахувати особливості даного ПЛК. Якщо необхідно перевірити роботу бібліотеки (наприклад контуру регулювання), реалізовується весь контур, включаючи обмін зі SCADA/HMI. Та це просто еджайл!  

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

Необхідно врахувати первинний запуск (холодний старт), операції при зупинках, аварійну обробку. І взагалі, варто задуматись про те, що система може перебувати у декількох станах, і алгоритми роботи можуть від цього принципово змінюватися. Звичайно не варто вводити стан, коли директор проходить біля ПЛК і треба поблимати лампочками, типу наповнити рівні в танках і сховати на СКАДі всі аларми. Хоча, треба над цим подумати… 

Як далеко Ви можете зайти, щоб прискорити роботу програми та зменшити її обсяг?

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

“Наш ПЛК розрахований рівно на стільки функцій, як прописано в ТЗ. Так що прийдеться його міняти на інший.”Знайома ситуація? 

Вибирайте та компонуйте ПЛК заздалегідь більшими ресурсами по пам’яті, ЦПУ, входам/виходам. Пам’ятайте, що здешевлення системи у більшості випадків приводить до негативних наслідків, в тому числі вищеописаних. Не забувайте ще про те, що робОти (не рОботи) у вас теж, як правило, при цьому прибавляється. 

2. Структура програми користувача.

Які  структурні одиниці для ПЛК Ви знаєте?

Згідно МЕК 61131 (біблія для АСУТПшного програміста, доречі хто з вас її читав?) є окремі незалежні куски програми, як POU (Program Organization Unit):

• програми (секції);
• функції;
• функціональні блоки;

У деяких ПЛК є ще неМЕКовські одиниці типу підпрограми та процедури.

Для ПЛК невеликої канальності,  як правило, ділити програму не можна, максимум – використовувати підпрограми. А чи враховуєте Ви можливості конкретної моделі при реалізації програми?    

А ви користуєтесь багатозадачністю? 

Не слід плутати багатозадачність з логічним структуруванням програми. Багатозадачність дає можливість економити перш за все часові ресурси контролера, забезпечуючи реальний час з використанням великих за обсягом програм. Так, наприклад, якщо всю програму написати в одну циклічну задачу (тобто ту, яка виконується відразу після того як виконується, відразу після того як виконується …), то цикл може бути  таким великим, що швидкість обробки не буде задовольняти умови керування певними процесами. “Ну, так, можна через певні куски коду виконувати одну і ту саму процедуру керування” скажете Ви. Проблема в тому, що у більшості випадків оновлення входів і виходів ПЛК проводиться на початку або в кінці задачі. Тому, наприклад, 10 раз змінюючи вихідну змінну за цикл, вона все одно на вихід запишеться тільки один раз в кінці циклу (примітка для #суперпрограмерів: я знаю про різні там периферійні входи/виходи та безпосереднє читання та запис). Ось тут і потрібна багатозадачність, щоб деякі алгоритми викликати частіше, і входи/виходи, які в них використовуються теж оновлювати частіше. Для багатозадачних середовищ (multitask), задачі можуть виконуватися циклічно, періодично, або за подією.  Останні, як правило, мають найвищий пріоритет і повинні виконатися миттєво при виникненні якоїсь події. 

“Ці кляті контури регулювання з’їдають 90% часу задачі, програма не встигає керувати дискретними клапанами для швидких функцій. Що робити?”  

Для початку визначіться, з якою періодичністю необхідно викликати регулятори. Для простоти можна вважати, що усі наприклад 20-ть регуляторів повинні викликатися з періодичністю 1 с. Тоді можна створити #типушедулер, який буде викликати по 2 регулятори з періодичністю 100 мс, але на кожний цикл інші. Так за десять циклів (протягом 1 сек) викличуться всі контури, але тривалість кожного циклу буде як тривалість виконання 2-х регуляторів. Я називаю цей механізм #розмазування_по_циклам.  Звичайно, для частої обробки контурів такий механізм не згодиться і прийдеться… вибирати інший контролер, або добавляти ще парочку. 

Ви знаєте що таке декомпозиція? 

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

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

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

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

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

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

Як об’єднати всі ці структурні  частини?

Декомпозицію зробили, а тепер треба робити агрегування. Основну програму можна реалізувати як виклики менших програм чи функцій, які при необхідності можна у будь який момент часу відключити. Цей підхід я бачив практично у всіх #чужих_програмах. Це просто дуже зручно, функціональний кусок програми відключається в одному рядку для текстових мов, або порожнім контактом в LD, або інверсією в потрібному місці контакту EN в FBD (пам’ятаєте що це таке?).  

Ви користуєтесь в основній програмі вхідними та вихідними змінними ПЛК?  

Маєте право. У цьому плані усі програмісти діляться на дві групи: 

1. ті, які використовують проміжні внутрішні змінні та десь в програмі відображають їх на зовнішні
2. ті, які користуються в програмі тільки посиланнями на оригінальні змінні входів та виходів (типу %I чи %IW) 

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

Для ПЛК великої та середньої канальності всі проміжні перетворення можна робити в окремих структурних одиницях.  При використанні проміжних перетворень структуру програми можна представляти як послідовність виконань: 

• секція/функція обробки входів, 
• секції/функції основної програми, 
• секція/функція обробки виходів.

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

“Що це дає?” – спитають ортодоксальні #варонедублювальщики, які все таки наперекір мені дочитали до цього місця. Ось деякі можливі переваги:

• незалежність програми від фізичного підключення каналу: часто на об’єкті місце підключення фізичних каналів змінюється по різним причинам (проектна помилка, згорів канал, #ойпроблемакопіпаста тощо);
• швидка заміна каналів при переключенні на резервний;
• можливість налагодження програмним шляхом: вхідні і вихідні змінні просто “відключаються” від внутрішніх простим відключенням секцій, і далі роби з цими “дублями” що хочеш, хоч змінюй засобами налагодження, хоч програмно імітуй;
• незалежний зв’язок SCADA/HMI з PLC: не забувайте, що просте переключення каналу тягне за собою зміну адреси і в СКАДА, звичайно якщо Ви не використали запропонований підхід, в якому  при переприсвоєнні адреси “дублів” залишаються без змін; 

Ложка дьогтю (на радість ортодоксальним #варонедублювальщикам):

• йде дублювання змінних (надлишок пам’яті): так, наприклад, замість однієї %I у вас з’являється ще й %M

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

“Якщо умова не виконується тоді відключити виклик функції ПІД-регулятору”. Ви добре подумали?

Платформа сильно накладає свої #депендент-штучки на реалізацію контурів регулювання. Тим не менше, хоча б задумайтесь про можливі наслідки. У Вашого ПЛК є чудова функція реалізації ПІД-регулятору, і Ви не можете не нарадуватися усілякими реалізованими смакотами типу безударність переходу, антинасиченість, режим слідкування в каскаді, можливість заморозки складових!? Так чого ви його тоді до біса відключаєте?! Уявіть собі, що Ви ПІД-регулятор, який повинен безударно перейти в автомат з ручного режиму, і це при тому, що вас тільки-но розбудили!? Та Ви навіть не знали, в якому значенні був клапан в ручному режимі! Замість включення/відключення використовуйте спеціальний режим, наприклад слідкування. Якщо такого режиму у регулятору немає, забезпечте його попередню ініціалізацію, перед введенням в дію. Принаймні про це теж треба думати.

Ну що, стомились? – далі в наступному випуску буде про вибір мови та підходи до програмування.

Коментарі та ваші кращі практики дуже навіть вітаються  – почуємось в он-лайн просторі:))

Продовження публікації за цим посиланням 

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

Дискусія після виступів ІТ-експертів

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

Сергій Ярчук, директор BMS Group, вважає, що – «звичайно є. Це абсолютно інший рівень вимог до людей, потрібні їх набагато більше залучення та само мотивація. Якщо цього немає, – agile не буде працювати». Лев Ванян, директор ІТР, додає до цього ремарку про «неадекватних замовників», які зруйнують будь-який agile. 

Олександр Жебряков, Ciklum Consulting, коментує це – «Це дійсно розповсюджені тези, я б навіть сказав міфи серед СЕО багатьох організацій. Візьмемо приклад мотивації та залучення персоналу. Коли ми (консультанти) приходимо, вони нам кажуть – скажіть кого треба прибрати, а кого поставити і опишіть їх профіль. Насправді ми бачимо проблему скоріше не в людях, а в процесах. І ще точніше – в процесах комунікацій, які в свою чергу є породженням застарілої лінійно-функціональної структури. Зміни agile якраз направлені на те, щоб знизити між-функціональні бар’єри між відділами».

Далі звучить питання про важливість Lessons Learnt (уроки проекту)  – «що тут важливого, щоб обговорювати з людьми – можете привести приклад?»

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

 «Чи є обмеження Agile по відношенню до традиційних методів в АСУ ТП?» – з цим запитанням ведучий звернувся до Євгена Антонова, JBS,  який має досвід і АСУ ТП, і ІТ. – «Все залежить від рівня функціональних вимог, – відповів Євген. – Якщо цей рівень визначений чітко і він високий, то Agile може покращити ситуацію та вирішувати ваші проблеми. Наприклад, в таких випадках дуже добре працює інструмент беклогу продукту. Якщо ж цих вимог набагато менше (типово – коли доля «заліза» зростає і є інші вимоги), – то скоріше всього це й буде обмеженням для використання Agile».  Олександр Жебряков не погоджується – «В нас був проект з клієнтом Юкон, що виробляє електронні вироби й де доля «заліза» переважає. Їх конструкторське бюро розробляє (тільки) низькорівневий софт в Києві, яке використовується при виробництві тепловізорів та біноклів. А їх виробництва розкидані по 3-м країнам. Ми їх перевели успішно на Agile.»

Олександр Грошев висловив сумнів, чи дійсно працює Agile в інфраструктурних проектах. Сергій Батюк опонує посилаючись на власний досвід, що це працює. «По іншому ми й не можемо працювати – адже, ми працюємо завжди в умовах нечіткої постановки завдань. А це і є передумова Agile. Крім того, ми традиційно крос-функціональні – програмісти працюють з технологами, проектувальниками, монтажниками і т.д. Ну й наші проекти АСУ ТП – сьогодні все-ж це більш програмні проекти».

 «Проте, як ви відчули – що конкретно можуть покращити методи Agile- SCRUM в типових проблемах проектів АСУ ТП» – питає ведучий. –«І якщо ви кажете, що ви вже Agile, – то як ви вирішуєте масу проблем АСУ ТП, про які говорили на початку?». Чіткої відповіді не прозвучало – принаймі,  від самих учасників ринку АСУ ТП.

Широка панорама – контекст проектної культури та відповідності KPI бізнесу  

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

Тому я спробую розширити картинку та поставити додаткові запитання інтеграторам. Спочатку ще раз процитую Олександра Жебрякова. «Головне – це фокус на KPI бізнесу. Якщо ви їх досягаєте без Agile, то він вам і не потрібен.  Приклади типових KPI – швидкість випуску продукту на ринок, задоволеність клієнтів та персоналу, продуктивність праці, тощо. Якщо ви їх досягаєте й ви щасливі, то навіщо вам щось змінювати?». Звідси 3 блоки питань:

• На мою думку, суть дискусії (яку очевидно потрібно продовжувати)  треба повернути в цю сторону – «а які власне KPI наші інтегратори мають чи планують в своїй операційній діяльності?». Чи вимірюється та зростає задоволення замовника? Як оцінюється їх досвід? Те саме – по персоналу? Чи скорочується час виконання проектів? Чи зменшується кількість помилок? Чи виходить більше стандартизованих, типових рішень? Чи збільшується загальна кількість проектів? А прибутковість на проект – як з цим?… Перелік можна продовжувати. 
• Друга теза – а як змінюється в нас, власне, рівень проектної культури в АСУ ТП? Протягом останніх 10 років ІТ-галузь масово впроваджувала Agile/SCRUM, учасники інших галузей, включно з великими промисловими підприємствами так само масово – стандарти PMI/PMbok, десятки інших в Україні переходять на Agile/Lean й сотні наших управлінців вивчають Agile в дорогих бізнес-школах… Зрештою PMI офіційно визнає, адаптує та включає в свої положення  Agile Project Management. А куди просунулись за цей час гравці АСУ ТП? Які стандарти чи інструменти запровадили в свої практики для того, щоб краще управляти змінами в нестійкому (за визначенням!) середовищі промислових АСУ? 
• Що є бенчмарком (прикладом-рівнем для наслідування) сьогодні? Тобто на який професійний рівень власне орієнтуються гравці ринку АСУ ТП і чи вивчають вони цю планку в своїй рідній галузі? Недавня поїздка до партнерів в Санкт-Петербург показала, що російські інтегратори успішно адаптують PMBok до середовища АСУ ТП, й вимірюють навіть такі цікаві показники як «залучення персоналу»… CSIA (американська асоціація інтеграторів промислових АСУ) роками теж адаптує PMbok, і де основою є V-подібний цикл розробки-впровадження.  В то же час інтегратори цієї ж асоціації на рівні MES/MOM вже переходять на Agile Project Management (включно з методами SCRUM). Ну і власне Agile в різних обличчях є основою сучасних production & operation models й включений в різні положення стандартів MESA International.
  

В той же час в Україні… Я не знаю жодного системного інтегратора АСУ ТП, який має хоча б 2-х сертифікованих прожект менеджерів (по PMI). Ми чуємо багато критики на впровадження стандартів PMI на великих промислових підприємствах – це просто перетворюється в чергову бюрократію. В той же час, наші спроби  в  АППАУ розібратись, що та як використовують інтегратори – радше невдалі, – “все покрыто мраком” )

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

Можливі напрямки подальших дій

1. Дискусія корисна, але незакінчена – її варто продовжити. Це вже відбувається в наших групах в соц. мережах (ще одна цитата – «agile – це все про комунікації», – а де ви спілкуєтесь з колегами?). Перш за все варто отримати чіткі відповіді про обмеження SCRUM та застосування інших методів Agile в проектах з високою питомою вагою “заліза”. Але також краще зрозуміти в чому обмеження класичного V-подібного циклу розробки, – якщо він дійсно є головним для планування.

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

3. Не треба щоразу винаходити велосипед – вивчайте кращі практики та кейси. Той же SCRUM вже в арсеналі Agile Project Management. Показані на зустрічі кейси JBS та Terrasoft чудово це демонструють. Можливо, просто варто більш детально в цьому розібратись. І просто пробувати. Зрештою нічого іншого допоки  ми не побачили – SCRUM (включно з вищенаведеним посиланням на automationworld.com) проникає всюди, тому що це “найбільш практична та легка в освоєнні технологія покращення взаємодії команд” (Є. Антонов)

Якщо запитання вище прозвучали дещо жорстко, то є дві приємні новини. Перша про те, що насправді рівень зрілості й серед учасників ринку АСУ – різний. Через кілька днів після нашого клубу виявилось, що 2 компанії (саме з учасників ринку пром АСУ) вже активно впроваджують Agile в своїх проектах. Другий позитив в тому, що Agile – як дух, властивий будь-якій спільності – люди прагнуть до обмінів та комунікацій. Насамкінець нашої зустрічі, викладач КПІ Грудзинський Юліан Євгенійович підійшов та передав велику підбірку е-книг по Agile – віднині доступна для всіх членів АППАУ.

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

Публікації по темі:

– Let’s be Agile – звіт з круглого столу АППАУ, ч.1

– Agile в промышленной автоматизации – от интуитивных подходов к осознанным практикам

– Является ли бизнес АСУ ТП проектно-ориентированным?

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

В дискуссии приняли участие около 20 человек, представителей организаций АППАУ, ТРЦ «Океан-плаза», Производственной группы «Техинсервис», AББ Лтд, КиевПромЭлектроПроект, ООО Данфосс, КСК-Автоматизация, БМС Груп, Блюменбеккер, Микрол, Украинского клуба недвижимости, и других.

Ключевые вопросы дискуссии, которые озвучил ведущий Юрчак Александр, касались 3 позиций:

1. каким образом достичь максимальной энергоэффективности с помощью BMS  – это один из главных вопросов в фокусе заказчиков сегодня на всех рынках, в том числе и в зданиях
2. как добиться лучшей синергии между игроками рынка – нестыковок сегодня очень много
3. что делать с проектированием и проектировщиками – это самое узкое место согласно предыдущим дискуссиям, которые АППАУ вела в он-лайн группах.

Мнения экспертов

Михаил Кордюков – был нашим главным спикером по направлению HVAC (ОВК) и инженерным системам. основные тезисы Михаила:

• Главный потенциал энергоэффективности – именно в системах ОВК, встроенных в сбалансированную архитектурную форму. Сейчас до 55% потерь тепла в зданиях приходится на системы вентиляций. Применив качественную рекуперацию в вентиляционных системах, можно в 2 раза уменьшить нагрузку на котельную и в 3 раза на систему кондиционирования. Современные вентиляционные системы потребляют электрической энергии в 5..6 раз меньше, чем традиционные. Современная система кондиционирования потребляет энергии в 2 раза меньше, чем традиционная. Поэтому без грамотного внедрения современных технологий (ATA, HRV, DX) достичь высокой энергоэффективности нельзя. Если на объекте уже установлена устаревшая система HVAC, то с помощью BMS улучшить ее можно всего на 2..5%
• Нынешние подходы многих девелоперов и инженерно-строительных организаций к этому – устаревшие. Например, лидер рынка KAN ставит в новые здания технологии 30-летней давности.
• BMS нужны – от коттеджей и до крупных зданий, однако нужно по максиму использовать и локальные системы управления. Практически все современные здания оснащены системами управления, только они локальные – каждая управляет своей частью здания, а общей, интегрированной нет.
• Главные факторы высокой энергоэффективности – в грамотном проектировании всего объекта в целом. На стадии архитектурной концепции здания необходимо сбалансировать все его составляющие: стротельную конструкцию, инженерные системы, системы управления – это и будет синергия. А  когда все разделы проекта никак не взаимосвязаны, каждая работает сама по себе, то потребительские качества такого здания – неудовлетворительные.

Геннадий Кабальский, менеджер проектов Производственной группы «Техинсервис», которая реализовала уже много BMS в Украине, акцентирует больше на необходимости комплексного подхода в начале проекта строительства:

• Пресловутый «зоопарк» в управлении зданиями начинается с того, что генподрядчик смотрит только на цену и отдает на откуп подрядчикам выбор и установку инженерных систем здания. В результате – интегратору «сводить» это все вместе потом бывает очень сложно.  Комплексный подход и видение единого центра информации и контроля-управления нужны изначально. 
• По идее, все это должно закладываться на этапе проектирования. Однако, по факту – у нас не те проектировщики (например, у строителей этим вопросам внимания вообще не уделяется), либо проект на BMS делается потом, когда большая часть оборудования уже установлена.
• Лучшее решение – это отдельный проект BMS на ранней стадии строительства, но пока заказчики к этому не готовы

Игорь Кирпиченко, главный инженер ТРЦ «Океан-плаза», комментируя дебаты по вопросам интеграции под-систем в единую BMS, подтверждает, что благодаря BMS от ПГ «Техинсервис» у него практически нет проблем с контролем-мониторингом всех инженерных систем.  Как говорит Игорь: «Комплексность и единый центр управления – это на самом деле очень важно в подобных реализациях».

Александр Грошев, зам директора компании «Блюменбеккер»: 

• Эксплуатирующие организации не вовлечены в процесс проектирования. Отсюда проблемы, в том числе и с целостной системой управления. Эксплуатирующая организация, а лучше Интегратор должны быть вовлечены в процесс проектирования. В процесс выдачи задания заводу-изготовителю – как минимум. Опыт промышленных предприятий здесь кстати. Кроме того, это позволит убрать зоопарк протоколов и решений, что существенно удешевит разработку и внедрение BMS, и существенно снизит эксплуатационные издержки.
• На данном этапе решения из АСУТП промышленных предприятий должны более активно продвигаться в рынок BMS (Шины на базе TCP/IP, web-ТЕХНОЛОГИИ, беспроводные технологии). К системам управления зданиями пора начать относиться как к АСУТП больших промышленных объектов. Опыт того же дата-центра или OCEAN Plaza тому подтверждение.

Сергей Ярчук, БМС Груп, сделал SWОТ-анализ для рынка BMS. Важные заключения этого анализа:

• Рынок еще молодой, поэтому много путаницы – даже в терминологии. Например, BMS (Buildig Management Systems) и BAS (Building Automation Systems) – это разные вещи, первое, как правило, включает в себя второе. А есть еще масса продуктовых и технологических сегментов внутри. Не только заказчики, но и интеграторы это путают.
• Существует не менее 7 видов операторов (категорий игроков) рынка. Есть очень много вопросов, насколько слаженно они между собой взаимодействуют.
• Опыт Европы показывает следующее: по каждому протоколу BMS есть своя ассоциация, которая состоит и финансируется в первую очередь производителями систем, а также в нее входят все операторы рынка. Ассоциации очень активны, они ведут ВСЮ работу по продвижению решений: выставки, журналы, обучение, перевод литературы, стандарты, сертификация партнеров и многое другое.

• Главные проблемы нашего рынка касаются: 

– слабых компетенций инвестора  и его зависимости от генподрядчика

– конкуренции между интегратором и поставщиком HVAC (борьба за автоматику) 
– отсутствия проектантов по HVAC (в проектных организациях и у интеграторов) 
– плохой подготовки проектов или их отсутствие с начала (необходимость переделывать и т.д.) 

Виктор Пырков, зам. ген. директора Данфосс ТОВ, был наверно самым ярким и убедительным спикером этого вечера:

• большинство ответов на вопросы по энергоэффективности заложены в стандарте ДСТУ Б EN 15232:2011. Это полное соответствие европейскому стандарту по системам управления зданиями EN 15232. Если проектировать по этому стандарту, то все будет «в порядке» – и с энергоэффективностью, и с управлением зданием
• энергетический паспорт на здание разрабатывают на стадии проектирования. Реальную энергоэффективность видно только во время эксплуатации. Это означает, что здания, формально соответствующие классу А энергоэффективности таковыми не являются. Устранить это несоответствие может энергоаудит, результатом которого является  энергетический сертификат. В Украине уже действуют адаптированные к европейским стандарты по энергоэффективности, в том числе и по определению влияния автоматизации инженерных систем здания на энергоэффективность
• в целом, проблемы с проектировщиками действительно есть. Однако заказчикам и другим игрокам нужно требовать от них соблюдения стандарта EN 15232 и других подобых – ведь сегодня, это уже часть украинских стандартов, норм и правил (ДСТУ, ДБН).
• Активное участие в дискуссиях также приняли Демчина Б.С. директор «Микрол» и Громадский Ю.С,. директор КиевПромЭлектроПроект.  

Главные выводы

Итак, дискуссия экспертов не только подтвердила все наши начальные предположения, которые были сделаны в ранних обсуждениях он-лайн, – но также внесла дополнительную ясность в ряд вопросов. И важно, – что это было сделано совместно. Итоговые выводы:

• Ключевая проблема рынка BMS – в уровне проектирования и проектировщиках. У нас не только нет «правильных проектов», – проблема в том, что даже те проектировщики, которые проектируют инженерные системы и частично закладывают условия к BMS, не пользуются стандартом ДСТУ Б EN 15232:2011.
• Одна из причин такого положения – в том, как разворачиваются строительные проекты, где доминируют Инвестор, Генподрядчик и Строительная организация. Вся тройка далека от понимания BMS, в то время как за качественный проект BMS на ранней стадии другим игрокам (например, специализированным Интеграторам) заказчик платить не готов – такой культуры рынка у нас нет. Это специфика этого рынка и, как правильно отметили участники круглого стола, – в этом его ключевое отличие от промышленных рынков.
• Однако и сами игроки должны не только жаловаться на «отсталость или незрелость рынка», но самим быть более проактивными. Главный рычаг воздействия на рынок – это стандарт ДСТУ Б EN 15232:2011, обязательный для применения сегодня в строительстве новых зданий в соответствии с ДБН В.2.5-67 и ДБН В.2.5-28, а также Законом Украины «Про будівельні норми». Наши лидеры Siemens & Schneider Electric – явно не дотягивают до лидерского уровня продвижения и влияния на отрасль – и, прежде всего, в плане последовательности своих действий. Чего стоит сам факт незнания этого стандарта большинством участников рынка, хотя эти бренды продвигают EN 15232 уже много лет. 
• Напротив, Danfoss, его подходы и уровень продвижения, его влияние и позиции на рынке автоматического оборудования систем тепло- и холодоснабжения, может служить настоящим бенчмарк (примером для подражания) для всех участников рынка промышленных АСУ.
• Что же делать? – мы  обсудили ряд опций по образованию рынка и улучшению влияния на ключевых игроков, а также некоторые возможные консолидированные действия. Детальный отчет с презентациями экспертов, а также рекомендации по развитию АППАУ предоставит своим членам и участникам этого круглого стола.

Какой же главный результат этой дискуссии? Наверное, впервые в АППАУ, буквально за 3 недели мы создали «отраслевой прецедент» – через доведение до коллективного сознания ряда негативных фактов состояния конкретного рыночного сегмента, мы ясно увидели проблемы отраслевого взаимодействия и поняли, как действовать. По сути, – это была наглядная иллюстрация нашего тезиса «как не стать вымирающим динозавром», изложенного в недавней публикации об итогах Форума лидеров АСУ.  Игроки рынка должны значительно улучшить свою позицию «субъекта» рынка. Это значит – проактивно и консолидировано воздействовать на главные целевые группы, которые сегодня являются «узким местом» развития рынка BMS – инвесторов, ген. подрядчиков и проектантов. И уже ясно, с помощью каких средств и аргументов.

 

Наши следующие встречи экспертов – см программу семинаров АППАУ на EIA-2015

                                               *********

Отдельные отзывы – комментарии после проведения встречи.

Сергей Власов, Украинский клуб недвижимости, о низком уровне понимания и коммуникаций со стороны игроков рынка BMS: «Не следует относиться к девелоперам как к каким-то неучам, у которых за спиной три класса образования и курилка. Времена малиновых пиджаков прошли 15 лет назад, последние закончились в 2008 году, Подавляющее большинство крупных девелоперов из ТОП-50, это люди с двумя высшими образованиями и степенью MBA. А сегодня на рынок уже выходят ребята поколения Y, или Google (пока они доросли до уровня глав департаментов, но это ненадолго), а они мыслят и действуют совсем в другой плоскости – и с таким подходом за ними вообще не угнаться.» 

Сергей Ярчук, БМС Груп: «Для меня вчера был самый главный вывод от эксперта по стандартизации – и именно в технической части. Фактически,  эти стандарты на 70% относятся к генподрядчику, девелоперу (инвестору) и проектанту технологического оборудования. Мы и ранее это знали, но еще раз увидел ярко – ключевое отличие от АСУ ТП – в БМС интегратор отнюдь не главный стейкхолдер, он не имеет влияния на этих участников рынка даже зная стандарты».

 

АББ пропонує кейс про управління навантаженнями з функцією Ekip Power Controller для низьковольтних автоматичних вимикачів ABB SACE Emax 2. 

Замовник

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

Виклик 

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

Трансформаторна підстанція будівлі складається з 4 силових трансформаторів СН/НН. Для кожного з трансформаторів на стороні 0,4 кВ у якості ввідних апаратів були встановлені повітряні автоматичні вимикачі SACE Emax 1.2. Ідея полягає в тому, щоб керувати навантаженнями системи опалення, вентиляції та кондиціонування повітря (ОВКП) в простий та повністю автоматизований спосіб.

Рішення від АВВ

Для досягнення цієї мети компанія АВВ пропонує нову функцію керування електричними навантаженнями – Ekip Power Controller. Дана функція безпосередньо входить до програмного забезпечення електронних розчеплювачів апаратів SACE Emax 2, основною функцію яких залишається максимальний струмовий захист. Таким чином, відпадає необхідність у використанні складних систем управління і спеціального програмного забезпечення.

Для реалізації системи досить мати один автоматичний вимикач, який має дану функцію, встановлений в якості основного низьковольтного комутаційного апарату. Таким чином, в даному випадку тільки один з чотирьох ввідних апаратів Emax 1.2 повинен бути оснащений функцією Ekip Power Controller. Саме цей автоматичний вимикач «вирішує», коли і які навантаження повинні бути відключені згідно із заданими параметрами та загальним обсягом електроспоживання всієї установки (сумарна енергія, що протікає через всі чотири ввідних апарати).

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

Річна економія – 11 000 Євро

Завдяки функції Ekip Power Controller здійснюється управління навантаженнями системи ОВКП та досягається економія потужності до 400 кВт і до 11 000 Євро* в рік. 

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

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

Більше про можливості подібних пристроїв можна дізнатися з керівництва “Застосування автоматичних вимикачів АВВ в цифрових системах автоматизації”

Про виклики

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

·       Виклик №1: готовність замовника. Чи достатньо росту тарифів, щоб власники та управляючі директори стали свідомими важливості технологічного інжинірингу і були б готові сповна платити за якісний проект? Чи мають вони достатньо інформації, прикладів, кейсів, методик окупності, тощо?

·      Виклик №2: готовність виконавця. Чи є хтось серед гравців ринку (включно з АСУ), хто вже сьогодні готовий проектувати нові будівлі по «новим правилам» (EN 15232)? Адже на круглому столі ми прийшли до висновку, що частина спеціалізованих проектних організацій його не знає та не застосовує, в той час як більшість гравців ринку АСУ просто не знеє.

·      Виклик №3: просування напрямку BMS.   Якщо відповідь на попередні питання радше негативна, то наступне питання про готовність широко просувати концепції, методики, кейси по BMS до широких кругів зацікавлених осіб. Зараз ситуація така, що в технічному  комітеті (№302), який і прийняв європейський стандарт EN 15232 до використання в Україні жодного представника ринку АСУ немає.  Спроби інших великих гравців інакше ніж поодинокими не назвеш – особливо на фоні домінуючих парадигм “промоушен – це за брендами, ми тут ні при чому”… Тому чи не є ситуація з розповсюдженням та знанням цього стандарту наслідком ізольованих та не системних дій всієї спільноти гравців АСУ?

·      Виклик №4: модернізація існуючих будівель. Тут про проектування нового мова не йде – як і про заміну технологічного обладнання та інженерних систем, крім можливо котельного обладнання. Тоді  що потрібно робити?  Точніше, чи  дає що- небудь для гравців ринку АСУ  енергоаудит, який рекомендують першим кроком і  який, як правило, більше говорить про  утеплення, та найпростіші заходи типу «лампочки та лічильники»?

·      Виклик №5: розширення – адаптація інстальованих систем під задачі енергоефективності. Це очевидний хід для багатьох гравців, хто вже поставив своє обладнання та системи. Що потрібно зробити щоб збільшити та покращити ефект від вже інстальованих систем BAC–BMS?

·      Виклик №6: масштабування на інші будівлі – перш за все, в промисловості. В промисловому секторі потенціал енергозбереження в рази більший, ніж в комерційній нерухомості – згідно оцінкам потенціалу енергозбереження в Новій енергетичній стратегії України, перший сягає до 900 млрд грн. (по курсу  на січень), в той час як другий – тільки до 100 млрд грн. Однак який в цих сумах потенціал ринку АСУ – теж відкрите питання. Що сьогодні пропонують великі бренди , чи є в них нові ініціативи, і як вони залучають до них різних партнерів?

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

Чи працюють старі підходи?

Отже, питання руба – чи готові гравці ринку АСУ та BMS приймати ці та подібні виклики? Технологічно, – щодо розробки та інтеграції різноманітних архітектур АСУ, очевидно, ніяких сумнівів ні у кого не виникає. А от щодо підходів по розвитку ринку – питання є і багато.

1. Категорія питань – методологічна та просвітницька

По ідеї, гравці, які позиціонують себе як постачальники обладнання та рішень на ринку BMS мають демонструвати солідну базу методичних напрацювань. Без цього доказувати ринку та власникам будівель, що дорога автоматика щось дасть крім «прибамбаців» та дещо кращого контролю даних – не вдасться. Ми бачимо, що подібні напрацювання вже зроблені на ринку частотних перетворювачів. Однак цього ще дуже мало на рівні BMS – так само як  і в близьких до цього по духу АСОДУ чи системах управління активами підприємства. Окремі пости на нашому сайті про реалізації Групи «Техінсервіс» не змінюють загальної картини – досить бідної на хороші, дискусійні статті, методичні керівництва, інші кейси про рішення тощо. Але очевидно, що головним матеріалом для просвіти ринку має бути головна «методика» –  сам стандарт EN-15232, який чітко визначає всі головні речі – від функцій автоматизації і до методів оцінки їх впливу на енергоефективність.

2. Рівень інтеграції, співпраці та діалогу між гравцями ринку

Тут теж чимало запитань. Як гравці ринку АСУ збираються впливати на власників чи генпідрядників, якщо в ланцюжку створення цінності вони стоять майже останні? Адже рівень їхньої кооперації залишає бажати кращого. Вендори – «самі по собі», інтегратори та проектувальники – так само. Тобто, ефективних та яскравих в бізнесі пар «Вендор – Інтегратор» чи «Технологічна компанія – Інтегратор», які діють злагоджено та системно по відношенню до нових ринків чи сегментів ми бачимо, насправді, мало. Принаймі – відкритої інформації про це вкрай мало. Наш кейс 2011 року про одну з перших реалізацій на ринку ЦОД пари «Техінсервіс- Шнейдер Електрик» дуже стисло, але все ж натякає на необхідний рівень співпраці. Від визначення архітектури АСУ, аргументації переваг й до комерційних перемовин партнери пройшли разом.

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

3. Рівень демонстрації економічного ефекту

Один з учасників нашого круглого столу, який представляв якраз ринок власників комерційної нерухомості і дещо далекий від нюансів АСУ, написав мені потім «самое часто повторяемое слово на этой встрече— – стандарты (ДБНы, нормы, сети, etc.). А какое самое частое слово на заседаниях девелоперов? Правильно – «окупаемость». Где точка сборки? – и почему вы об этом не говорите?»

Як не гірко визнавати, але питання окупності систем АСУ гостре і не розв’язане до цього часу. Те, що розділ ТЕО є обов’язковим в проектуванні АСУ ТП в промисловості зовсім не означає, що хтось вимірює справжній економічний ефект після впровадження системи. В системах BMS з ростом тарифів на енергію ця невідповідність стає дуже гостро, – власники тут є дуже приземленими та практичними і відповідь про окупність потрібна негайно.

Отже, наша велика дискусія – яка почалась не 18 березня, а значно раніше – продовжується. Питання ті самі – як ми бачимо спільні виклики і чи готові ми їх приймати, практикуючи старі бізнес-підходи. Підходи, що беруть коріння з 90-их і  які базуються на самоізоляції, недовірі, вузькому баченню проблематики ринку та перекладення відповідальності за загальні проблеми на когось. Можливо колись так все й працювало. Питання – чи працює це зараз? Наша відповідь радше негативна.

А як ви думаєте?

П.С. Очна дискусія буде продовжена на наших семінарах на виставці ЕІА-2015, 22-24 квітня, – запрошуємо, буде цікаво. 

 

 

 

О ценности профессиональных выставок много сказано и написано. Только здесь за несколько дней можно решить множество бизнес-задач: оценить реальное состояние рынка, продемонстрировать все возможности оборудования «в действии», лично пообщаться с тысячами потенциальных клиентов, понять их первоочередные задачи и потребности, протестировать новые идеи — и это далеко не полный перечень. НО… насколько эффективно участники используют этот инструмент, решили в полевых условиях выставок elcomUkraine и EIA-2015 узнать организаторы — компания «Евроиндекс» — совместно с Ассоциацией Предприятий Промышленной Автоматизации Украины. Самый эффективный участник будет определен 21 – 24 апреля в ходе работы выставок в результате конкурсного отбора.

Экспертная комиссия проведет детальный анализ стендов участников, месседжей, степени вовлеченности в диалог, оригинальности и зрелищности представления компании, а также выработает рекомендации и наградит самых подготовленных. В состав экспертной комиссии войдут представители «Евроиндекса», АППАУ, ММГ, журнала «Мир автоматизации», «ПТА-Экспортроника», “Украина Электро”. Церемония награждения победителей состоится 24 апреля, в завершающий день работы выставок elcomUkraine и EIA-2015.

Если у Вас еще нет пригласительного – скачайте его по этой ссылке.

Выставки elcomUkraine и EIA пройдут 21 – 24 апреля в выставочном центре «КиевЭкспоПлаза». Полная информация — на сайтах www.elcom.ua и www.asutp.euroindex.ua. 

покупается самая дешевая система, если доказана ее функциональность и соответствие техническому заданию.

Для вновь строящегося объекта ROI считается для всего объекта (машины, технологической линии).

Общеизвестно, что  экономический эффект от внедрения АСУТП считается по следующим направлениям:

• Снижение процента брака или повышение производительности.
• Обеспечение стабильного качества продукции путем управления и оптимизации основных технологических параметров техпроцесса.
• Энергоэффективность (эффективность сжигания топлива, снижение затрат электроэнергии и прочее)
• Безопасность персонала, производства и окружающей среды
•  Экологические характеристики (например, по выбросам CO)
• Задачи учета выработки и потребления энергоресурсов для последующего решения задач оптимизации. Собственно, задачи оптимизации не являются частью собственно АСУТП. Но на основании их результатов разрабатывается комплекс мер по повышению энергоэффективности.

Очевидно, что порядок перечисления направлений не отражает их важности и приоритетов для каждого конкретного заказчика.

Кроме того, в мировом сообществе идет активная дискуссия об экономической эффективности от внедрения AMS (Asset Management System)  систем. В случае их применения экономическая эффективность достигается за счет:

• Повышения эксплуатационной готовности оборудования путем выполнения мероприятий на базе превентивной диагностики оборудования.
• Снижения эксплуатационных расходов путем отказа от ППР и проведение работ по данным системы превентивной диагностики.

По данным наших коллег эффективность от внедрения таких систем (сокращения затрат на склад запасных частей, ремонтов и простоев оборудования) исчисляется миллионами доларов в год (для крупных нефтехимических предприятий)

Как оказалось, самым сложным является получение текущих данных о затратах по каждому из направлений для выработки плана мероприятий. Например, данные о существующих простоях и связанных с ними потерях практически не доступны. Это делает невозможным доказательство экономического эффекта.

Самым простым является расчет ROI для применения преобразователей частоты и различных систем оптимизации сжигания топлива по составу отходящих газов (это может быть просто котельная, разного рода печи и тд). 

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

На мой взгляд, одной из насущных проблем является доказательство влияния ПРАВИЛЬНО СПРОЕКТИРОВАННЫХ (а следовательно и несколько более дорогих АСУТП) на ROI всего объекта. 

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

Было бы интересно исследовать влияние простоев оборудования по вине некачественных АСУТП на ROI всего объекта. Но здесь нужно участие соответствующих экономистов.

Таким образом вырисовываются следующие темы обсуждения:

1. Реальное влияние качества АСУ ТП на ROI всего объекта.
2. Знакомство с лучшими практиками в области оптимизации потребления энергоресурсов на энергоемких производствах.
3. Возможный экономический эффект от внедрения AMS в текущих условиях Украины.

Надеюсь, эти темы будут в обсуждении семинара АППАУ «Вклад АСУ ТП в экономические показатели предприятий», 21 апреля  на выставке EIA-2015

                                                                                                          Александр Грошев, независимый эксперта

инсайтов и лучших презентаций – посмотрим на некоторые из них, представленные на Форуме лидеров АСУ в феврале. Вопрос в том, чтобы понять, почему они были лучшие (пусть это и моя субъективная точка зрения – опросов никаких не делали).

Планирование производства: реалии vs технологии,  (Дмитрий Сериков, EQ System)

Доклад хорошо представил разрыв между декларируемыми целями каждого производителя и его реальными привычками- методами планирования. На примерах и своем опыте Дмитрий ярко раскрыл 5 ключевых вызовов наших планировщиков – замедленная реакция на изменение окружающей среды, слабая точность прогнозов, недостаточная оптимизация процессов, слабая связь между продажами – производством – и логистикой, а также плохое извлечение уроков из полученного опыта, их систематизацию. Ключевые преимущества системы Asprova воспринимались далее с доверием – ведь уже понятно, зачем они нужны. Итак, самый сильный момент этой презентации – глубокий, системный инстайт в реалии «планирования» отечественных производителей. Второй момент – простота и наглядность слайдов, – они совсем не перегружены текстом и деталями. Третье – хорошее сопровождение, истории и собственый опыт. Посмотреть презентацию можно здесь.

Тренды автоматизации – виртуальные и реальные, (Сергей Батюк, Клинкманн-Украина)

Сергей взял одну из самых «горячих» и в то же время, сомнительных тем – насколько так называемые «мега-тренды»  (интернет-технологии, беспроводная связь, дистанционное обслуживание и т.п.) являются актуальными для украинских предприятий. Сергей Георгиевич полностью ушел от «стандратов» – слайды были совершенно «не классические», с многими текстами и т.п. Однако, это неожиданно оказалось сильным местом этого доклада. Как это не банально прозвучит – но все  зависит о компетентности докладчика и глубины дискустируемых им вопросов. Публика с большим удовольствием следила з ходом мысли – неожиданным, местами провокационным и, в то же время, убедительным с точки зрения аргументов. В целом, тезис «реальные тренды = уже доказавшие свою потребность, а виртуальные – в зависимости от контекста» – показался очень важным. «Контекст» Сергей Батюк определил как «важнее, не ЧТО автоматизировать, а КОМУ это надо». Другими словами, с точки зрения первичности качества управленческих решений и бизнес-результатов – новые технологии очень даже затребованы сегодня.

Итак, этот доклад выделяли оригинальность, контрастность (противопоставление и резкое смещение акцентов), а также высокая компетентность докладчика. Посмотреть презентацию – здесь.

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

Несмотря на разные темы, общее во всех этих докладах:

• Реальная «привязка к местности» – они говорят о важном, о наболевшем, о том, что касается нашего рынка и наших клиентов
• Аутентичность – свой стиль и своя точка зрения, пусь иногда спорная, но не повторяющая избитые  штампы
• Глубина – коллеги глубоко прорабатывают вопросы, которые обсуждают
• Личная заинтересованность предметом дискуссии

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

Новых интересных спикеров мы увидим скоро на выставке EIA-2015 – пожелаем им успеха и таких же лидерских качеств!

Ну и приглашаем всех желающих на наши семинары (участие бесплатно) – чем больше мы их поводим, тем интересснее темы и дискуссии ) Будет интересно и в этот раз – детали уже на следующей неделе.

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

Скачать притгласительный на выставку ЕИА-2015 можно по этой ссылке.

На сегодняшний день выставка «EIA» – единственное отраслевое событие для рынков электроники и промышленной автоматизации проводится одновременно с крупнейшей в Украине выставкой elcomUkraine – энергетика, электротехника, энергоэффективность, Green Expo – альтернативная электроэнергетика и Технопривод. Выставки охватывают рынки и отрасли, которые тесно взаимосвязаны и пересекаются между собой, создавая уникальную площадку для встречи специалистов и ведущих игроков рынка.

Ассоциация Предприятий Промышлденной Автоматизации Украины (АППАУ) активно готовится к выставке: ассоциация будет представлена собственным стендом (В983), а также совместно с компанией “Евроиндекс” выступает организатором кокурса “Эффективный участник”, проводит серию семинаров:

• 21 апреля, 11:00 – 13:30 – семинар «Вклад АСУ ТП в экономические показатели предприятий»
• 22 апреля, 11:00 – 13:30 – «Эксплуатационная готовность и безопасность систем управления»
• 23 апреля, 10:30 – 13:00 – «Экспортеры – на виход».

Чтобы принять участие – достаточно скачать пригласительный на выставку, распечатать его и предъявить на стойке регистрации.

Ждем вас!