Моя Родина – АСУ ТП — смертельно больна

Коротко о статье

Статья о кризисе сообщества АСУ ТП: отсутствии обсуждения стандартов и архитектуры, оттоке ИТ-специалистов и причинах, связанных с МЭК-стандартом IEC 61131. Автор предлагает развивать открытые GNU/Linux IOT-решения для автоматизации.

Главное

• На тематических форумах и в группах АСУ ТП не обсуждают стандарты, архитектуру РСУ и практики ISA101, ISA88, ISA95.
• Профильные ИТ-специалисты, попадая в АСУ ТП, не могут применить навыки и уходят в Web или Enterprise.
• Корень проблемы автор видит в МЭК-стандарте IEC 61131 в части разработки ПО.
• Стандарт привёл к «эффекту-кобры»: множество сред разработки PLC/HMI/SCADA и урезанных языков.
• Из-за отсутствия специализации программированием вынуждены заниматься инженеры-КИП, электромеханики, монтажники, технологи.
• Автор предлагает популяризировать IOT-оборудование и открытые GNU/Linux IOT-решения для задач автоматизации.

Термины и технологии

• АСУ ТП
• РСУ
• ISA101
• ISA88
• ISA95
• IEC 61131
• LAD/FBD
• PLC / HMI / SCADA
• GNU/Linux IOT

Кому полезно: Инженерам АСУ ТП, КИП, разработчикам и руководителям инжиниринговых компаний.

По теме на сайте

• Статья Большинство коллег первые свои программы пишут на LAD/FBD, но со временем часть
• Статья Тизер вебинара _На что обратить внимание при заказе АСУ ТП на молочном предприятии Стандарт ISA88_
• Статья IEC 61131-3 без скуки: как выбрать язык ПЛК под задачу

Первоисточник: habr.com

Выжимка составлена редакцией сайта с помощью ИИ по тексту статьи.

Если вы отправитесь на любой тематический АСУ ТП-форум или группу, вы к сожалению не найдете обсуждения стандартов, архитектуры РСУ, лучших практик для ISA101, ISA88, ISA95.

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

Проще говоря – сообщество и особенно ИТ-сообщество разработчиков в сфере АСУ ТП отсутствует в принципе.

Справедливости ради стоит отметить, что профильные ИТ-шники встречаются в АСУ ТП. Обычно это молодые ребята, которые в институте действительно изучали алгоритмы, структуры данных и базы данных. Будучи еще студентами они случайно попадают в АСУ ТП, где не могут нормально применить свои навыки и с ужасом убегают в Web или Enterprise, потеряв в лучшем случае 1-3 года.

В чем же дело?

Безусловно причин у этой проблемы можно найти великое множество, но на мой взгляд их общим корнем является МЭК-стандарт в части разработки программного обеспечения (IEC 61131).

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

Но на практике, помимо перечисленных плюсов, это привело к «эффекту-кобры» в сфере автоматизации, а именно:

1. Огромное количество сред разработки PLC / HMI / SCADA («зоопарк»). Каждый из производителей автоматики разрабатывает свою «уникальную» IDE и урезаный язык программирования.
2. Отсутствие специализации и разделения труда. Это тонкая проблема вытекающая из первой. Из-за того, что профильные программисты буквально не хотят работать на суррогатных языках программирования — работу вынуждены выполнять инженеры-КИП, электромеханики, монтажники, технологи — специалисты, которые рады бы делать свою любимую работу, но сложившийся отраслевой стандарт буквально заставляет их программировать.
3. Полное отсутствие культуры разработки инженерного ПО, отсутствие сообщества, унизительные заработные платы. Естественно, у тех, кто вынужден этим заниматься «потому что надо» это не вызывает ничего кроме раздражения «поскорей сделать эту ненавистную програмщину». Отсутствие архитектуры, комментариев, версификации это лишь стандартный набор того с чем вы будете иметь дело при доработке ПО для инженерных систем.
4. Сложный и объемный фронт работы Инженерам, которые не смотря на все это терпят, потому что любят свою работу.

Что же делать?

На мой взгляд необходима масштабная популяризация IOT оборудования — должно появляться как можно больше открытых GNU/Linux IOT-решений способных решать задачи автоматизации.

• Со временем это выведет из употребления устаревшие IEC PLC.
• Разработчики АСУ ТП смогут разрабатывать и отлаживать ПО с помощью современных языков программирования и IDE.
• ИТ-шники будут оставаться в сфере, а значит неизбежно появятся реальные стандарты и качество.
• Компании смогут изменить экономическую модель, что позволит платить Инженерам и Программистам АСУ ТП достойную заработную плату.

Если вы инжиниринговая компания и вас есть ресурсы — займитесь развитием IOT-решений для АСУ ТП!

Источник: https://habr.com/ru/articles/736320/

🔗 Моя Родина – АСУ ТП — смертельно больна