Моя Родина – АСУ ТП — смертельно больна
Если вы отправитесь на любой тематический АСУ ТП-форум или группу, вы к сожалению не найдете обсуждения стандартов, архитектуры РСУ, лучших практик для ISA101, ISA88, ISA95.
В лучшем случае вы найдете дискуссии на тему «являются ли АСУ-шники настоящими программистами когда пишут код на LAD/FBD» или «обязан ли монтажник/программист знать технологический процесс объекта на котором работает» и т.п.
Проще говоря — сообщество и особенно ИТ-сообщество разработчиков в сфере АСУ ТП отсутствует в принципе.
Справедливости ради стоит отметить, что профильные ИТ-шники встречаются в АСУ ТП. Обычно это молодые ребята, которые в институте действительно изучали алгоритмы, структуры данных и базы данных. Будучи еще студентами они случайно попадают в АСУ ТП, где не могут нормально применить свои навыки и с ужасом убегают в Web или Enterprise, потеряв в лучшем случае 1–3 года.
В чем же дело?
Безусловно причин у этой проблемы можно найти великое множество, но на мой взгляд их общим корнем является МЭК-стандарт в части разработки программного обеспечения (IEC 61131).
Основной целью стандарта было повышение скорости и качества разработки программ для ПЛК, а также создание языков программирования, ориентированных на технологов, обеспечение соответствия ПЛК идеологии открытых систем, исключение этапа дополнительного обучения при смене типа ПЛК.
Но на практике, помимо перечисленных плюсов, это привело к «эффекту-кобры» в сфере автоматизации, а именно:
Огромное количество сред разработки PLC / HMI / SCADA («зоопарк»). Каждый из производителей автоматики разрабатывает свою «уникальную» IDE и урезаный язык программирования.
Отсутствие специализации и разделения труда. Это тонкая проблема вытекающая из первой. Из-за того, что профильные программисты буквально не хотят работать на суррогатных языках программирования — работу вынуждены выполнять инженеры-КИП, электромеханики, монтажники, технологи — специалисты, которые рады бы делать свою любимую работу, но сложившийся отраслевой стандарт буквально заставляет их программировать.
Полное отсутствие культуры разработки инженерного ПО, отсутствие сообщества, унизительные заработные платы. Естественно, у тех, кто вынужден этим заниматься «потому что надо» это не вызывает ничего кроме раздражения «поскорей сделать эту ненавистную програмщину». Отсутствие архитектуры, комментариев, версификации это лишь стандартный набор того с чем вы будете иметь дело при доработке ПО для инженерных систем.
Сложный и объемный фронт работы Инженерам, которые не смотря на все это терпят, потому что любят свою работу (на Хабре есть отличная статья на эту тему).
Что же делать?
На мой взгляд необходима масштабная популяризация IOT оборудования — должно появляться как можно больше открытых GNU/Linux IOT-решений способных решать задачи автоматизации.
Со временем это выведет из употребления устаревшие IEC PLC.
Разработчики АСУ ТП смогут разрабатывать и отлаживать ПО с помощью современных языков программирования и IDE.
ИТ-шники будут оставаться в сфере, а значит неизбежно появятся реальные стандарты и качество.
Компании смогут изменить экономическую модель, что позволит платить Инженерам и Программистам АСУ ТП достойную заработную плату.
Если вы инжиниринговая компания и вас есть ресурсы — займитесь развитием IOT-решений для АСУ ТП!
