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

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

Бронзу среди экспортеров Украины в Национальном бизнес-рейтинге присвоено компании «Техинсервис ПГ» согласно сумме показателей внешнеэкономической деятельности: «Объем экспорта/импорта», «Динамика роста в сравнении с предыдущим годами», «Диверсификация (количество товарных позиций), «Количество стран-контрагентов», по основному виду деятельности КВЭД 847420 «Машины, оборудование и механические устройства; их части».

 

Деятельность Техинсервис ПГ оценивалась и ранжировалась независимыми экспертами в соответствии с полным списком предприятий Украины по официальным данным государственной статистики.

Национальный бизнес-рейтинг (НБР) создан в 2002 году по инициативе Торгово-промышленной палаты Украины и редакции международного каталога «Торгово-промышленная Украина» с целью предоставления достоверной информации инвесторам, банкам и другим заинтересованным лицам о состоянии современной предпринимательской деятельности в Украине. НБР систематически определяет перечень предприятий-лидеров экономики Украины исключительно по актуальным статистическим данным.

Поздравляем Техинсервис ПГ с заслуженной наградой!

Однак перший виступ відразу викликав сумніви – чи потрібні вони, ці сучасні рішення українським підприємствам? Бєгун Василь Васильович, – доцент Інституту проблем математичних машин та систем, колишній нач. цеху на ЧАЕС був переконливий як в своїй розповіді про принципи та стандарти безпеки, так і тому, що в українська нормативна база в цій області повністю відсутня. Фактично, стандарти в області безпеки та експлуатаційної готовності застарілі, а частіше всього просто не діють – їх замінили ручні перевірки та інспекції від десятків держ. органів, які отримали повноваження на подібний контроль.  Майже сотня цих органів має право на перевірку підприємства, а 44 з них мають право на його зупинку. «Корупційний рай» створювався в країні останні 10-15 років, і сьогодні він ще  в роботі – або ще більше в роботі, – кому як подобається. Висновки Бєгуна В.В. невтішні

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

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

Далі виступали представники брендів – вони ж постачальники системних рішень.

«ВДТ-Автоматизація» представляв провідний інженер Володимир Денисюк. Фірма –  член АППАУ, офіційний дистрибутор та інтегратор світового лідера в області автоматизації та бренду №1 в США – компанії Rockwell Automation. Володимир почав з нагадування про стандарт SIL (Safety Integrity Level), який є де-факто робочим стандартом безпеки в більшості цивілізованих країн (вкл. з Російською Федерацією) – але на жаль, ще не в Україні. Далі було повне представлення лінійки продуктів від Rockwell Automation що відповідають різним рівням цього стандарту – від SIL1 й до SIL3. 

 

Щоб не вдаватись в деталі, скажемо, що Rockwell Automation дійсно є одним з найстаріших та найвідоміших брендів в області промислової автоматизації, що мають цілий портфель продуктів для експлуатаційної готовності та безпеки. Наприклад, їх конкурент Schneider Electric сертифікував частину своїх продуктів на SIL3 тільки в другій половині 2000-их, – тоді як в Rockwell Automation ця сертифікація існує значно раніше і для більшого портфелю продуктів.

Сергій Батюк, технічний директор «Клінкманн-Україна» представив рішення по експлуатаційній готовності в системах SCADA.  Бренд Wonderware, що представляє «Клінкманн-Україна»  має такі самі лідерські позиції в області SCADA, як скажімо Rockwell Automation в PLC. Для безперебійності роботи систем верхнього рівня Wonderware пропонує всі можливі тут види резервування – холодне, гаряче, зеркалювання (дублювання).  Так само рівні системи, де застосовується це резервування можуть бути різними – 

 

Підсумки стану в області експлуатаційної готовності та безпеки підвела панельна дискусія

Експерти відзначили наступне:

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

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

P.S. Презентації долповідей можна отримати за зверненням на info@appau.org.ua

 

презентация Крега Ресника из ARC о недавнем опросе конечных заказчиков промышленных АСУ. Вкратце представим ее основные тезисы.

Результаты опроса

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

1. В полном перечне наиболее важных трендов, которые осознают респонденты, ARC выделяет тренд единой инфраструктуры предприятия, а также других интеграционных процессов с ИТ-приложениями и инструментами. В последние входят аналитические системы, системы хранения, обработки и визуализации данных, отчетность, управление качеством. Также упоминаются все «мега-тренды» – Cloud, Mobile, Wireless, IIoT, M2M, Industry 4.0

2. Интересные ответы респондентов по ROI – большинство из них считает приемлемым срок окупаемости в  2 года или меньше (28%), и столько же – 3 года (28%). Только 12% думают, что приемлемым может быть срок 7 лет. 

3. После главных критериев заказчика как ROI и окупаемость, респонденты рассматривают ряд других важных показателей как: 

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

Эти последние требования к АСУ ТП могут показаться несколько неожиданными – ведь мы уходим в область сценарного планирования и прогнозирования, что типично ассоциируется с ролями систем BI/ERP.  С другой стороны, если отталкиваться от реалий, что именно АСУ ТП является источником производственных данных и может обеспечивать их доставку в реальном времени, то вероятно ARC правы. Их резюме об ожидаемом пользователями Single Version of the Truth (единственном источнике правды  о реальном состоянии производства), – доступном для всех заинтересованных лиц от ген. директора до инженера по обслуживанию, – невозможна без промышленных АСУ.

   

Конференция CSIA-2015 собрала более 500 участников, – из них 80 вне США. Зона СНГ – РФ была представлена (как обычно) единственным участником, – российским Интегратором «Инсист-Автоматика».

4. Очень интересными выглядят ответы респондентов об оценке инвестиций в промышленные АСУ в контексте задач стратегического роста:

• Автоматизация является обязательным условиям для задач мониторинга и управления производственными активами (assets management)
• Устройства и решения пром. автоматизации обеспечивают лучшие показатели коммуникаций и обмена данными – включая мобильные и беспроводные технологии. Это тоже – обязательно сегодня для управления производствами
• Заказчики смотрят на решения, которые позволяют объединять задачи АСУ ТП (и разных типов процессов) – с задачами управления энергоснабжения 
• Они нуждаются в более точных «подсказках» и инсайтах с производства, чтобы переходить с реактивного управления к предиктивному. Это касается, в первую очередь, обслуживания установленного парка оборудования.

5. Какие сервисы ожидают заказчики от системных интеграторов – среди доброго десятка заявленных ARC обращает внимание на наиболее перспективные:

• Удаленный мониторинг и управление активами
• Решения по улучшениям в области ОЕЕ, MES и лучшей эксплуатационной готовности
• Поддержка и обслуживание существующего парка
• Лучшее партнерство с локальными заводскими командами
• Заказчики ищут сертифицированного Интегратора, глубоко знающего их производство-технологии и способного обеспечить целый комплекс функций

Резюмируя ответы на этот вопрос, ARC рекомендует интеграторам как можно быстрее переходить к модели ‘product-as-a-service’, везде, где это возможно, а также дает целый ряд других рекомендаций более  узкого характера.

6. В заключение ARC приводит перечень всех способностей Системных интеграторов, выделяя как наиболее актуальные:

• Сетевые технологии и Кибер-безопасность
• Интеграционные сервисы и МОМ/MES
• Продвинутое управление непрерывными процессами (Advanced Process Control) и  а также другие

 

Традиционно конференцию поддерживают ведущие мировые бренды промышленной автоматизации. На фото – на стенде АВВ.

Параллели – точки привязки, подобные тренды и отличия 

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

• Умение вычислять, мониторить и презентовать экономические показатели (ROI, окупаемость, ОЕЕ…) – актуально сегодня и для наших интеграторов. Другое дело, что многие из KPI «среднего уровня» только-только входят на производство, что мы недавно видели на семинаре в Днепропетровске.
• В область компетенций и ожидаемых сервисов от интеграторов попадают многие пром-ИТ «штучки»  – от вертикальной сетевой интеграции и отдельных приложений обработки данных, – до полномасштабных MES/MOM систем. Спрос на такие услуги в нас тоже давно существует – и хотя он пока малый и сужен к отдельным узким сегментам (как диспетчеризация активов или энергоресурсов), в технологическом плане это уже рядом с уровнем MES/MOM. Это требует новых компетенций и сервисов.
• Наш рынок тоже активно дискутирует возможности быстрого ввода новых технологий – прежде всего, в области мобильных приложений,  wireless и удаленного управления. Их хотя здесь, еще очень много манипуляций и непонимания специфичных требований промышленных приложений, – движение идет.

 

Победитель конкурса «Лучший месседж» на выставке EIA-2015 – компания Phoenix Contact,  с месседжем ‘Go2Web’. Здесь Phoenix Contact демонстрирует свое превосходство не только области удобства пользования своим сайтом, – но прежде всего, по целому портфелю высококачественных  устройств и решений в области коммуникаций.

 

Напротив, в чем есть значительные отличия, и где (по уровню зрелости) мы еще далеко отстаем:

• Отношение к Системному интегратору – как к надежному партнеру, которого выбирают «надолго и всерьез», не идет ни в какое сравнение с нашей культурой «тендерования», чаще всего – коррумпированной, тупой и бессмысленной с экономической точки зрения. Ведь в чем глубокий смысл менять интегратора как перчатки и чаще всего по критерию цены? И особенно на фоне низкой культуры расчета ROI?
• «Там» есть также  другое отношение к начальной оценке и выбору качеству услуг – ищут именно сертифицированного Интегратора. И стандарты сертификации СSIA  являются при этом бенчмарком. Выступающий на конференции европейский (французский) Lafarge подтвердил такую же политику  и дефицит сертифицированных Интеграторов для решения своих глобальных задач в разных регионах. В нас – Украине, России и других странах СНГ – заказчики очень(слишком?) медленно идут к осознанию критериев качества и сертификации.
• Также совершенно новым для нас являются модели ‘product-as-a-service’ – вот эту тему в АППАУ мы уж точно еще не поднимали ) Хотя примеры рядом – недавняя поездка в Санкт-Петербург ясно показала, что российские интеграторы (ГК «Ракурс») уже осваивают и продвигают эту модель. 

Вызовы для интеграторов

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

Это дает надежду роста, но вместе с тем, интеграторы должны ясно осознавать вызовы, о которых АППАУ много говорит в этом году – остановимся на 3-х главных:

1. Заказчики ищут глубокие технологические компетенции + комплекс услуг. С точки зрения реализации, каждый руководитель понимает, что это стратегический актив интегратора, тесно связанный с человеческими ресурсами. Во время кризиса важно удержать персонал, а возможно (ввиду падения стоимости кадров) и приобретать – наращивать новый.
2. Тренд интеграции с ИТ все более вырисовывается – от инфраструктурных решений до MOM/MES. Наши попытки «сагитировать» некоторых крупных СИ входить в эти нишы и развивать их пока не закончились успехом. Но на это нужно обращать внимание – по нашей информации, туда уже активно движутся интеграторы с ИТ-отрасли. И не надо забывать, что вес на крупных предприятиях все больше смещается от руководителей АСУ ТП – к директорам ИТ.
3. Интеграторы должны изменять также отношения к стандартам – критериям качества. АППАУ последние 4 года часто поднимает вопросы о стандартах качества – от проектирования и проектного управления, – до качества услуг. В качестве ориентира (бенчмарк) мы приводим CSIA. Однако пока мы не видим какого-либо значимого отклика на эти призывы. Между тем не надо забывать, что глобальные компании присутствуют и в Украине. И они ведут себя точно также как вышеупомянутый Lafarge. Другой пример, – еще в 2007 году автор этих строк видел аналогичные требовании со стороны местного филиала Danone – «мы будем с вами работать, если вы попадете в список сертифицированных интеграторов, с которыми мы работаем по всему миру».

Что вы думаете о вызовах и перспективах развития наших интеграторов?

Об этом также будем дискутировать на вебинаре 8 июля, – приглашаем, регистрация по ссылке

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

 

 

 

которая охватывает все области технологических процессов металлургии.

METEC является крупнейшей и наиболее знаковой мировой  международной выставкой по теме металлургического производства. Выставка METEC сфокусирована на проблемах отрасли, на ней рассматриваются тенденции и наиболее перспективные направления дальнейшего развития металлургии. Лучшие специалисты со всего мира встречаются здесь для обмена идеями и опытом. Выставка проводится один раз в четыре года и является событием, определяющим дальнейшее направления развития металлургии на следующие четыре года. METEC проводится совместно с технологическими выставками  NEWCAST 2015 (выставка готовой продукции),  GIFA 2015 (выставка, посвященная литейному производству), Therm process 2015 (выставка, посвященная вопросам  термической обработки). В рамках выставок будут проходить многочисленные семинары, международные конгрессы, лекции, презентации и мастер-классы.

ООО “ВДТ – Автоматизация”, которая входит в группу компаний TeraWatt Group, не могла оставить без внимания столь знаковое для отрасли событие. Наш стенд будет находиться в зале №3 под номером B52. Будем рады видеть вас среди наших гостей!

Более детально о выставке вы можете узнать на ее странице http://www.metec-tradefair.com/

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

Проблемы разработки ПО в АСУ ТП

Сравнивать в лоб Waterfall (метод водопада), V-образный цикл или подобные с Agile для отечественных разработчиков АСУ ТП было бы некорректно. Просто по той причине, что (по нашей информации) процессы разработки редко где стандартизированы настолько, чтобы говорить о целостном и полном применении тех или иных методов разработки. К сожалению, уровень зрелости разработчиков в АСУ ТП не сильно вырос за последние 20 лет, и в целом ситуация может сильно изменяться от фирмы к фирме. 

Этот низкий уровень зрелости в большинстве фирм также характеризуется следующими проблемными ситуациями:

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

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

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

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

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

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

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

Детализируя предпосылки к переходу на гибкие практики и методы Agile, отметим здесь те, которые как раз касаются основополагающих принципов Agile. Они указаны в Манифесте Agile – легко заметить, что многие интеграторы по своему духу и принципам работы ближе к ним, чем к громоздким и сложным правилам PMbok. Напомним эти принципы: 

1. Люди и взаимодействие важнее процессов и инструментов: редко какой интегратор имеет жесткие, формализованные бизнес- процессы разработки или применяет скрупулезно правила проектного управления. Обычно все достаточно ситуативно и  происходит в тесном взаимодействии разработчиков-программистов, проектантов и специалистов других направлений. 
2. Работающий продукт важнее исчерпывающей документации – как мы раньше отмечали, – интеграторы никогда и «не заморачивались» подобными работами, – результат и работающая система для них всегда были важнее. 
3. Сотрудничество с заказчиком важнее согласования условий контракта – хотя это может показаться и невыгодным для поставщика системы, но большинство интеграторов идут с готовностью на уступки и изменения, если заказчик на этом настаивает/ 
4. Готовность к изменениям важнее следования первоначальному плану – вся фишка в том, что детальное планирование (как это предусмотрено правилами  проектного управления в стиле водопада или V-образного цикла) у интеграторов практически отсутствует. И причина здесь не только в низком уровне проектной культуры. Гораздо больше проблем – на стороне заказчика и тех, кто управляет всем большим проектом. Что бы вы тщательно не спланировали в MS Project или другой среде – изменения всегда будут. Еще и потому, что Системный Интегратор идет всегда последним в цепочке поставщиков и подрядчиков крупного проекта и часто становится «жертвой» сдвига сроков.  

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

Есть ли уже точки пересечения и примеры в промышленной автоматизации?

Как оказалось, Agile уже давно присутствует в стандартах и практиках промышленной автоматизации. Эта статья википедии ссылается на ирландскую фирму Hal Software, которая в  2013 году ввела термин Agile Automation. Под ним компания как раз и понимает набор методов, инструментов и практик Agile для использования в промышленной автоматизации. Эта же ссылка упоминает, что еще в 2008 год GAMP-5 (Good Automation Manufacturing Practices) упоминал Agile programming среди набора рекомендуемых методов и моделей. Среди преимуществ Agile Automation источник называет сокращение цикла разработки ПО, а также улучшенные возможности для тестирования АСУ. А в контексте предыдущих наших разговоров о стандартизации уже очень интригующе звучит упоминание в этой статье стандартов ISA 88 и 95. Оказывается все это взаимоувязано.

Эксперт ведущего консалтингового агентства США в области промышленной автоматизации Maverick technologies пишет в свежей статье, что  «Основой разработки в стиле agile в промышленных системах управления являются итерационные процессы создания работающего ПО и его тестирования в режиме симуляции, и затем – тесного сотрудничества с заказчиком по возможным улучшениям.»

Важно отметить, что требования просто к разработке нового софта и к ведению проектов в стиле Agile – разные. Но снова же – наша критика на жесткость правил классического проектного управления а-ля-PMbok может иметь в основе устаревшие парадигмы – ведь сегодня уже существует Agile Project Management. Возможно, именно это направление развития нужно брать за основу нашим интеграторам.

Ну и очень похоже на то, что многие методы agile являються основой cовременного гибкого производства и разработки приложений на уровне MES – об этом часто пишет Automation World. 

Пример Terrasoft

Небольшой пример Agile в действии автор этих строк видел на последней конференции Terrasoft буквально на прошлой неделе. Terrasoft – украинская компания, – лидер CRM-рынка стран СНГ, опережающая в этой области такие бренды как Microsoft, Oracle и другие. За 14 лет своего существования, компания сумела построить мощный коллектив разработчиков ПО и сегодня экспортирует свои продукты в Западную Европу и США.

Презентации директоров R&D, Продуктового и Проектного департаментов на упомянутой конференции как раз касались демонстрации своего опыта в контексте дискуссии «Waterfall vs Agile».  Интересны следующие особенности:

• SCRUM полностью освоен и является основным методом разработки ПО в департаменте  R&D. Переход на  SCRUM позволил сократить сроки разработки новых релизов ПО и улучшить качество программных продуктов компании.
• Многие элементы SCRUM используются и в реализации проектов – например, оценка трудоемкости проектов ведется не в нормо-часах, а в так называемых story points (показатели сложности задач). Присутствует ряд других элементов SCRUM.
• В то же время планирование и разворачивание проекта ведется по классической технологии проектного управления – с этапами и соответствующими инструментами, как устав и т.п.

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

Вопросы к обсуждению 11 июня

Похоже, в четверг нас ожидает интересная дискуссия. Кроме ликбеза по SCRUM и его возможностей в разработке ПО и управлении проектами, мы ожидаем от докладчиков (приглашаются спикеры из ИТ-индустрии) разъяснений по поводу:

• где пределы и ограничения SCRUM и подобных  методов Agile в управлении проектами
• какие выгоды применения SCRUM – интересны будут примеры
• главные барьеры украинских компаний в освоении методов Agile
• как начинать и сколько  длится освоение этих методов.

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

Приглашаем всех желающих на нашу дискуссию 11 июня.

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

 

Ежегодно выставка объединяет промышленные предприятия и их партнеров из Украины, стран Европы, СНГ, Азии. 

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

Тематика выставки 2015 г.:

• Инновации в промышленности
• Машины, механизмы
• Тяжелое машиностроение
• CAD/CAM
• КИП
• Электротехника
• Промышленная электроника
• Комплектующие изделия и материалы
• Гидравлика
• Станки
• Инструмент
• Автотранспортная и дорожностроительная техника, сервис
• Энергетика и энергосбережение
• Металлургия, металлообработка
• Литейное оборудование и технологии
• Абразивные материалы
• Сварка
• Химическая промышленность
• Промышленная санитария.

АППАУ будет представлена собственным стендом, примет участие в Круглом столе “Выход на новые рынки. Проблемы и перспективы для украинских предприятий”, который состоится 26 мая с 10:00 до 12:00. Будем рады видеть вас среди участников!

Даты проведения: 26-28 мая 2015 г.

Место проведения: Украина, г. Запорожье, Выставочный комплекс «Козак-Палац» 

(адрес: ул. Победы, 70-б)

Детальная информация на сайте выставки

Аудиторія в 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 в промышленной автоматизации – от интуитивных подходов к осознанным практикам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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