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

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

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

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

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

В чем же дело?

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

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

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

1. Огромное количество сред разработки PLC / HMI / SCADA («зоопарк»). Каждый из производителей автоматики разрабатывает свою «уникальную» IDE и урезаный язык программирования.

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

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

4. Сложный и объемный фронт работы Инженерам, которые не смотря на все это терпят, потому что любят свою работу (на Хабре есть отличная статья ^[1] на эту тему).

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

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

• Со временем это выведет из употребления устаревшие IEC PLC.

• Разработчики АСУ ТП смогут разрабатывать и отлаживать ПО с помощью современных языков программирования и IDE.

• ИТ-шники будут оставаться в сфере, а значит неизбежно появятся реальные стандарты и качество.

• Компании смогут изменить экономическую модель, что позволит платить Инженерам и Программистам АСУ ТП достойную заработную плату.

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

Автор: Глазько Андрей

Источник ^[2]