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

А расскажу-ка я сегодня вам немного про АСУТП. Вернее, не совсем. Когда говорят "АСУТП", на ум обычно приходят какие-нибудь производственные площадки, "серьезные" ПЛК типа Siemens или Allen-Bradley с алгоритмами на МЭКовских языках программирования, мнемосхемы в SCADA-системах по всем правилам ГОСТ, и огромные тома проектов под все это дело... Нет, сегодня речь пойдет не о том. Сегодня мы поговорим о "ненормальном" АСУТП. А именно, о системах телемеханики.

Так уж сложилась, что мое детство, юность и начало карьеры прошли в регионе, где есть нефть. А раз есть нефть, то ее добывают. Для обывателя процесс добычи нефти обычно сразу ассоциируется со станками-качалками, такими, как на фото:

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

Начнем с, казалось бы, просто, с замеров. Очевидная идея: а давайте поставим на каждую скважину расходомер и будем смотреть, что он насчитал. Тут всплывает две проблемы: во-первых, из скважины кроме водонефтяной смеси поступает еще и попутный газ, и его по-хорошему нужно считать отдельно. Во-вторых, расходомер — штука, стоящая денег, требующая регулярного обслуживания и метрологических поверок.

Поэтому светлые умы в былые годы придумали такую штуку, как групповая замерная установка. Суть проста. С группы скважин ("куста") трубы сходятся в одно место где-нибудь неподалеку. Там стоит страшная штука под названием "Переключатель скважин многоходовой", которая поток с одной из скважин пропускает через расходомер, а со всех остальных — сразу в общую трубу ("коллектор"). Кроме непосредственно расходомера обеспечивается еще сепарация нефти и газа и разные другие вспомогательные процессы.

Самый простой расходомер — объемный, тупо считающий объем жидкостей, протекающий через него. В современном мире обычно используются более сложные массомеры, которые считают массу жидкости, ее плотность и температуру. Знание не только массы, но и плотности с температурой позволяет "на лету" посчитать, сколько же в смеси нефти, а сколько воды. Казалось бы, все просто. Оператор, придя на куст скважин, сначала проверяет, что все насосы работают и чувствуют себя хорошо, а потом поочередно переключает отводы переключателя скважин и смотрит на табло прибора поток жидкости с каждой из них, записывает результаты и передает их диспетчеру либо технологу.

Однако гонять туда-сюда операторов постоянно долго и неэффективно, поэтому в этом дело проникла автоматизация. 

Знакомьтесь, вот эта мыльница — это промышленный контроллер ICP DAS I-7188XC. Он основан на SoC с процессорным ядром Am186 (клон Intel 80186), несет в себе 128 килобайт оперативной памяти, 512 килобайт флешки, и DOS-подобную операционную систему. Софт для него пишется на древнем компиляторе Borland C 3.1 тоже под DOS. А теперь со всей этой фигней мы попытаемся взлететь. На самом деле, подобных довольно скромных ресурсов вполне достаточно очень даже много для чего.  Контроллер может быть и другим, вот, например, ПЛК фирмы Schneider Electric под названием SCADAPack, представляющий из себя более серьезное устройство, но суть в целом остается та же.

Сам по себе контроллер является "мозгом" системы, а во всей своей красе он себя проявляет, когда к нему на шину мы подсаживаем модули ввода-вывода, которые и обеспечивают его взаимодействие с внешним миром. Модули могут быть дискретные входные (DI), дискретные выходные (DO), аналоговые входные (AI), аналоговые выходные (AO) и всякие другие.

Дискретные оперируют состояниями "да/нет", например, замкнут ли концевик или реле, или нет. аналоговые, соответственно, нужны для значений в заданном диапазоне, как правило, это диапазон 4-20 миллиампер. Например, если мы подключим к аналоговому входу манометр с пределом измерения 6 мегапаскалей, то 0 мегапаскалей на его шкале будет соответствовать ток 4 миллиампера, максимуму шкалы - 20 миллиампер, а если у нас что-то пошло не так, то ток на входе будет болтаться около нуля, и мы легко диагностируем обрыв провода. Используя простую математическую пропорцию мы можем легко получить требуемое значение.

Дискретные входы могут использоваться группами, например, на упомянутый выше ПСМ обычно ставится специальная штука либо с герконами или микропереключателями, которая по 4-м проводам сообщает нам, на какой из труб сейчас стоит ПСМ, передавай ее номер в двоичном коде, один провод - один бит. Иногда при пусконаладке провода путают местами, и тогда начинается занимательный квест типа "погоняй ПСМ по кругу, запиши все значения и вычисли, какие именно биты перепутали". И надейся, что перепутали только два провода, а не все 4. Когда контроллеру нужно перевести отвод, он подает единичку на нужный выход DO, реле замыкает контакт, что в свою очередь вызывает замыкание контактов магнитного пускателя, насос гидропривода начинает громко гудеть и через несколько секунд перещелкивает отвод. Тут важно выдержать правильные тайминги: отпустите слишком рано — отвод не переведется, подержите слишком долго — есть риск сжечь насос. Такие истории бывали :)

Если у нас старый объемный расходомер, то там, как правило, просто стоит магнитик на стрелке и геркон где-то рядом, и когда стрелка проходит через верх шкалы (каждые 50 литров), контроллеру на DI вход приходит импульс. Современные массомеры отдают данные уже по разным протоколам, например, Modbus RTU или HART. Работает или нет скважинный насос, диагностируется просто: на силовой кабель вешается индикатор тока, когда по кабелю течет ток, мы имеем сигнал на DI-входе, когда нет — нет. Иногда это приводит к интересным глюкам, например, когда ремонтники приезжают на объект и подключают свой сварочный аппарат к фидеру остановленного насоса, то контроллер бывает очень сильно удивлен.

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

Так же на DI-входы заводятся различные сигналы датчиков охранной и пожарной сигнализации, датчиков превышения загазованности на площадке, и прочее. На входы AI - сигналы с манометров с разных мест. Шкафы автоматики всегда оснащаются ИБП, наличие внешнего питания и и уровень заряда аккумулятора — тоже один из сигналов, например, когда нет внешнего питания, не смысла дергать гидропривод, а когда аккумулятор близок к нулю, лучше на всякий случай почаще сохранять текущий замер в архив на флешке. Еще нередко можно встретить ТЭНы: зимы бывают суровые, а блок-боксы не отапливаются, либо шкаф вообще может висеть на улице посреди поля..

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

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

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

Кроме замерных установок для нефтяных насосов есть и другие типы объектов. Например, существует такой процесс, как "Поддержка пластового давления" (ППД), когда под землю под давлением закачивается вода, "выдавливая" нефть с другой стороны. Технологам важно знать, сколько воды и где было закачано — поэтому всё примерно так же, расходомеры считают расход и объем, а контроллер ведет архив замеров.

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

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

И дальше встает следущий вопрос: а как передать все эти данные на диспетчерский пункт, и более того — как получать команды оттуда? Вариант "послать оператора с флешкой" не рассматриваем. Вариант "использовать  GPRS/3G/4G" — тоже. В принципе, иногда его действительно использовали, но в большинстве случаев объекты находятся в таких глухих местах, где покрытия сотовой сети нет вообще, а если даже есть, то оно такое, что передать данные вы просто не сможете. Расстояние от кустов до диспетчерского пункта на промысле могло достигать 100 километров. В наше время есть всякие LoRaWan, но в те времена, про которые я рассказываю, эта технология еще не получила широкого распространения.

Уже был дальнобойный WiFi промышленного стандарта 802.11a, мы его даже испытывали и использовали для некоторых задач (видеонаблюдение), но подобные варианты были все-таки больше пригодны для соединения точка-точка, а не для покрытия территорий в большом радиусе.  Поэтому работало всё по-другому.

Знакомьтесь. Это голосовая радиостанция Motorola GM340. Самая обычная. УКВ-диапазон. Дальность до 50 километров. Подобные радиостанции вы можете встретить, например, в полицейских машинах, на железных дорогах, и много-много где еще. Радиостанция передает голос, значит, чтобы передавать данные, нам нужен модем. Есть, например, микросхема FX909. Модуляция GMSK, скорость при работе через хорошую радиостанцию до 19.2 килобит в секунду. Микросхема стоит внутри модема, который крепится на DIN-рейку, одним портом подключается к радиостанции (один провод для звука на прием, один провод для звука на передачу, один провод, чтобы включить передатчик радиостанции, а четвертый не помню для чего), а другим концом - в RS-232 или RS-485 порт контроллера. Передача полудуплексная, то есть одновременно можно или передавать, или принимать. Радиостанции нужно некоторое время на переходные процессы внутри передатчика, поэтому схема работы немного усложняется: переключили радиостанцию на передачу, немного подождали, передали пакет данных, выключили передатчик, и ждем ответа. Соответственно, каждый запрос по факту занимает времени больше, чем сама передача данных в нем, поэтому карта регистров контроллера максимально оптимизировалась так, чтобы можно было считать как можно больше данных за как можно меньшее количество запросов.

Были и эксперименты со сжатием, и лучше всего себя в этом показался самый обычный RLE-алгоритм, попробуйте догадаться, почему :) В эфире передача данных слышалась как мелодичный писк. Протоколом обмена был Modbus, в котором ряд "кастомных функций" (это не самодеятельность, такое допускается протоколом) был зарезервирован для вычитывания архива. Сервер опроса поочередно опрашивал все объекты и считывал регистры текущего состояния контроллера с основной информацией о том, что происходит и какие сигналы активны, а потом вычитывал, что появилось нового в кольцевом архиве с момента последнего опроса. Таким образом, даже при пропадании связи на долгое время, данные, рано или поздно, все равно доходили куда надо. На одном нефтепромысле могла быть сотня-две установок, опрос всего этого хозяйства, как правило, укладывался в 3-4 минуты.

С ближней радиосвязью (от скважинных шкафов к замерной установке или от замерных установок к электрозадвижкам) все чуть-чуть проще, как я уже говорил, там использовались другие модемы и другой диапазон, а сами антенны были преимущественно направленные. Иногда это давало интересные эффекты, например, как-то раз мы мучались с выводом на связь одной из скважин, которая на связь не хотела выходить ну никак из-за холма, мешающего прямой видимости. Потом одно неловкое движение, кронштейн крепления антенны лопается со звуком "шпыньк", сама антенна повисает, печально смотря вниз... и вдруг контроллер начинает мигать, показывает, что начался обмен данными, а напарник по рации подтверждает, что таки да — данные на куст начали приходить. И никакой магии — неподалеку от скважины пролегал небольшой овраг, тянущийся как раз до замерной установки. Радиосигнал, попадая в этот овраг, поочередно отражался от его стен, и таким образом вполне себе долетал до точки назначения, как по волноводу.

Радиосвязь — штука тонкая и капризная. Иногда она зависит от погодных условий. Иногда от помех, например, от различного силового оборудования, линий ЛЭП, и других вещей. А еще она требует особого внимания при монтаже. Помнится, заказчики захотели вывести на верхний уровень (читай "получать данные в систему диспетчеризации") один объект. С контроллером-то проблем почти не было (на самом деле было, но не будем об этом), а вот с радиоканалом это была самая эпичная пусконаладка на моей памяти — на объект мы ездили раза три-четыре, если не больше. Сначала оказался бракованным модем, потом оказался плохо спаянным разъем кабеля между модемом и радиостанцией, потом нашли непропай в разъеме антенны, потом оказался перебит антенный кабель... Причем сам куст находился довольно далеко от базы нефтепромысла, а дорога до него была такая, что проезд даже на Ниве требовал неслабого мастерства водителя и отваги экипажа. Хотя, бывало и хуже. Например, особый шарм имеет пусконаладка зимой. Зимы у нас снежные, поэтому застрять в сугробах можно легко и надолго. Иногда гораздо проще доехать на лыжах или мотособаке, иногда до шкафа автоматике приходилось добираться ползком.

Ну и отдельно можно рассказать о перепрошивке. Как я уже говорил, объекты могли располагаться в очень глухих и далеких местах, до куда нужно ехать в лучшем случае на внедорожнике, а в худшем случае — на вездеходе, снегоходе или лыжах. Естественно, вставал вопрос обновления прошивок на контроллерах, ибо, понятное дело, прошить железку всегда можно подключившись к ней ноутбуком, но вот объезжать все объекты было долго и муторно. В итоге была реализована и функция удаленной перепрошивки. Пакетами по 250 байт прошивка отправлялась по радиоканалу на контроллер и сохранялась с отдельную область flash-памяти. Когда все пакеты были получены, сверялась контрольная сумма, и если все нормально, то программа копировалась в основную область флешки. Как я уже говорил, в контроллере использовалась DOS-like ОС и файловая система FAT12, поэтому положить .exe-файл куда надо особой сложности не предоставляло. Была своеобразная романтика: в холодную метель сидеть на диспетчерском пункте, перепрошивать по-одному контроллеры, слушая пиликанье радиостанции, и спорить, кто же поедет на объект, если вдруг контроллер не перезапустится после перепрошивки... С контроллерами SCADAPack все было еще проще, возможность перепрошивать железку через тот же порт, что и шел обмен данными без каких-либо дополнительных манипуляций по месту у них есть из коробки, а поскольку радиомодем — это, по сути дела, удлинитель COM-порта, то обновление прошивки с базы делалось легко и непринужденно.

И в итоге, когда мы собрали данные со всех датчиков, вторичных преобразователей и вспомогательных контроллеров, переварили их внутри кустового контроллера и отправили их по радиоканалу, они попадают на сервер опроса. Сервер опроса — это сервер (спасибо, Капитан Очевидность!), на котором крутится OPC-сервер (это уже ПО) и база данных. OPC-сервер имеет список контроллеров для опроса и драйвера (библиотеки, которые знают, по какому протоколу кого опрашивать и что считывать/записывать), поочередно опрашивает устройства по радиоканалу, получает данные и архивы и выдает их во внешний мир в виде понятном виде (в виде так называемых OPC-тегов).

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

OPC-протокол — штука вполне стандартная для АСУТП, существует его старый вариант, такой как OPC DA, основанный на COM, в результате чего он практически целиком и полностью Windows-only и нередко глючит из-за фаерволов и прочего сетевого софта. Есть так же новый его вариант OPC UA, который работает поверх TCP и использует бинарную- либо XML-сериализацию.

После того, как данные оказались в тегах или в базе данных, начинается то, ради чего всё затевалось — отображение их для всех желающих, обычно это диспетчеры и технологи. В ряде случаев это специальный софт, генерирующий различные отчеты по данным из БД, в других случаях это так называемая SCADA-система, суть которой в том, что все данные по всем объектам отображаются диспетчеру на красивой мнемосхеме  реальном времени. Диспетчер может ткнуть в нужный объект на карте, загружается мнемосхема этого объекта, OPC-сервер переключается на внеочередной опрос этого объекта, заставляя радиостанцию радостно запищать, и спустя пару секунд на мнемосхеме появляются значения замеров и индикация того, что же собственно происходит на объекте. Там же диспетчер  может ткнуть на кнопочку чтобы отправить команду, один клик мышкой — и где-то в ста километрах начинает гудеть гидропривод, открываться задвижка, двигатель ЭЦН добавляет оборотов, или начинает  пищать сирена в лесу, говоря прохлаждающемуся рядом оператору о том, что нужно выйти на связь.

Так же есть задачи выгрузки данных в сторонние системы, в лучшем случае там что-нибудь типа экспорта в CSV, в особо мудреных случаях может быть квест вида "запиши данные в таблицы чужой базы данный и ничего там не сломай" :)

OPC-сервер, логгер, конфигуратор и всё остальное изначально были написаны на Delphi, что в принципе не удивительно, поскольку проект тянул свою родословную аж с середины 2000-х годов. Когда возникло желание сбросить груз легаси и переписать всё по-нормальному, новую версию и новые компоненты начали разрабатывать на C#, просто потому, что уже в те годы Delphi как язык и как технология начал стабильно загибаться, и находить  разработчиков, согласных на нем писать, стало всё сложнее и сложнее, не говоря уж о доступности требуемых библиотек.

В качестве SCADA изначально использовали продукт одного именитого бренда, потом же стало понятно, что с новым курсом доллара лицензия на это дело слишком дорогая, даже в рамках целого проекта, и к тому же хотелось больше гибкости для затачивания для собственных нужд. В результате была начата работа над своей SCAD'ой, работающей в браузере, что во-первых автоматически снимало кучу головной боли касательно визуализации, а во-вторых позволило запускать HMI даже на тонких клиентах, планшетах, и т.д., чему были очень рады некоторые заказчики. Кстати, волна "импортозамещения" так же коснулась и контроллерного уровня, сейчас каждый второй интегратор клепает свои "ПЛК", хотя некоторые вообще не заморачиваются.

Кому-то все описанное выше может показаться интересным и захватывающим, но я лично ушел из АСУТП и ни капельки не жалею. А причин сразу несколько.

Первая — это постоянные разъезды и командировки. Даже после долгой разработки чего-либо, рано или поздно все равно придется приехать на объект запускать всё это дело. Да, в процессе разработки ты будешь тестировать это на симуляторах и стендах, но часть железок, по традиции, сымитировать или притащить на стенд не получится (слишком большие/слишком дорогие/еще не закупленные/etc.) и реальной жизни твой контроллер с ними встретится только на объекте.

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

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

Вторая  причина — технологическое отставание и спектр задач. Поддержка систем контроля версий  даже в в средах разработки SCADA и ПЛК от именитых вендоров типа Siemens появилась только тогда, когда они уже с десяток лет использовались в IT-индустрии. Поддержка написания юнит-тестов в некоторых продуктах имеется, но я ни разу на своей жизни не видел и не слышал, чтобы ей пользовались и юнит-тесты действительно писались. CI/DI — аналогично.  За слово "рефакторинг" могут дать в морду, ибо какой там рефакторинг, сроки горят, работать надо. Ну и повальное велосипедостроение. Зачастую можно вообще наткнуться на что-то типа

Ничего удивительного. По моим наблюдениям, многие «железячники» считают, что производство устройства — это искусство, подвластное избранным, а вот написать к нему код он сможет сам, так, на коленке. Это ж вообще мелочь. Получается работающий тихий ужас. Они очень обижаются, когда им на пальцах объясняют, почему их код дурно пахнет, потому что… ну… они ж железку сделали, че тут, программа какая-то (отсюда)

...и что самое плохое, любые попытки хоть как-то всё это изменить встречаются в штыки. Да, когда ты пишешь код для чего-то с повышенными требованиями надежности, консервативность — не самое плохое качество. Но только если она в разумных пределах и идет на пользу, а не наоборот.

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

Имел я дело и "классическими" АСУТПшными проектами с ПЛК именитых вендоров, разработка для которых ведется на МЭК'овских языках, но там все еще хуже — а именно, лично для меня (прошу не кидать камнями, это лишь мнение) по сравнению с теми же C++/C#/Python эти МЭКовские языки кажутся детскими кубиками против Lego Mindstorms.

А третья причина банальна: деньги и плюшки. С деньгами в АСУТП не очень. Буквально пару дней назад на Хабре в комментариях это описали очень даже метко

из комментариев

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

Во-вторых, тут проявляет себя очень печальное явление, как жадность: казалось бы, software developers из "большого IT" — это тоже инженеры-программисты (холивар на тему можно ли называть формошлепов инженерами через 3...2...1...)... Но при этом так уж сложилось, что их зарплаты в наше время в нашей стране существенно выше других представителей инженерного дела, таких как электроники, проектировщики, наладчики, и т.д.  АСУТПшные предприятия, как правило, гораздо ближе к инжирингу, чем к IT,  зачастую руководство там вообще не понимает рыночную стоимость программистов, и в итоге все сводится к  «почему это мы этим должны платить в два раза больше, да ну нафиг».

Очень красноречиво это демонстриет скриншот, который я взял из легендарной статьи:

суровая правда жизни

Отсюда же вытекает отношение к работникам и всякий административный маразм типа рабочего дня только с 9 утра (в то время как приличные IT-компании давно уже перешли на гибкий график), отпуска только по графику, нелюбовь к удаленке, требования к совмещению на одной должности сразу нескольких специализаций (и программист, и проектировщик, и наладчик, и на дуде игрец) и подобное. 

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

На этом всё. Если я что-то упустил или что-то интересно — спрашивайте, постараюсь вспомнить и ответить в комментариях.