Промышленное программирование *

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

Привет всем!

Ко мне часто обращаются молодые инженеры с вопросом: «А зачем вообще идти в аспирантуру?» Я обычно рассказываю, какие плюсы и минусы есть у такого шага — как учёба прокачивает навыки, помогает упорядочить знания и освоить грамотную постановку экспериментов. Но выбор каждому нужно делать самому, стоит ли прокачивать такие навыки или нет.

И вот во время одного такого разговора, погрузившись в воспоминания о собственных научных делах, я случайно наткнулся в интернете на хакатон. И угадайте, по какой теме? По диагностике асинхронных электродвигателей — прямо в точку! Своего рода - мой незакрытый гештальт во время собственного обучения.

Решили с товарищем поучаствовать. Правда, мы были вдвоём, а в команде могло быть до 9 человек. Спойлер: мы не взяли первое место и даже не попали в шорт‑лист из 9 команд — заняли 16‑е место из 35.

Да, это не история про успех, а про опыт — тот самый, который, как известно, «сын ошибок трудных». Главный урок прост: да, быть экспертом и действовать в одиночку — это неплохо. Но настоящая суперсила — в команде!

А теперь — обо всём по порядку…

Сезон Heavy Digital длился на Хабре с 30 января по 15 марта. В нём приняли участие 48 материалов о цифре в промышленности, набравших в сумме сотни комментариев и более двухсот тысяч просмотров.

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

Что ж, пора подвести итоги сезона и посмотреть, что эти сорок с лишним текстов добавили к дискуссии о заводской цифре на Хабре.

17 марта в Российском новом университете прошёл пресс-завтрак на тему «Гражданские беспилотники: от аэрофотосъёмки до сельского хозяйства». Цель мероприятия была связана с донесением до широких масс через приглашенных журналистов мысли о том, что БПЛА, даже в современных и очень непростых условиях, это отнюдь не только военные коптеры и дроны-разведчики, а средства передвижения и перемещения полезной нагрузки с огромным потенциалом для самых разных сфер и отраслей экономики.

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

В целом работа шла хорошо, до того момента, пока не звонил телефон. Часто при разговоре могло звучать название объекта, либо его цифровая маркировка.

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

Тут и выявилась проблема отсутствия единого понимания о расположении объектов на территории завода. Которую, как уже упоминалось выше, можно было выразить вопросом: «Где это находится?». Вопрос как выяснилось непростой и важный, особенно для предприятия площадью несколько квадратных километров с множеством объектов, в режиме круглосуточной стройки, словно муравейник, с числом строителей, как в небольшом провинциальном городке нашей необъятной страны.

Оценка величины зерна является одной из базовых задач количественной металлографии, поскольку размер зерна напрямую связан с комплексом механических свойств металла: прочностью, пластичностью, ударной вязкостью, склонностью к хрупкому разрушению и стабильностью свойств после термической обработки. В промышленной практике для определения величины зерна широко применяются стандарты ASTM E112, ISO 643 и ГОСТ 5639.

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

В данной статье рассматривается практическая реализация системы автоматизированного анализа зеренной структуры стали на Python с использованием OpenCV. Цель разработки состояла не в замене стандартизованных методов их упрощённой цифровой имитацией, а в создании воспроизводимого инструмента, который позволяет приблизить лабораторный анализ к количественной обработке изображений и обеспечить прослеживаемость результата.

Приходят к нам мужики из цеха и говорят эту фразу.

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

Во-вторых, конвертер, который надо фотографировать. Если что, то конвертер — это такая печка в виде большого горшка восемь метров высотой. Мы туда заваливаем металлолом и заливаем жидкий чугун, затем всё это продувается кислородом, а потом на выходе получается сталь. Смысл операции — при температурах выше 1 600 градусов продуть кислородом на сверхзвуке так, чтобы он связал ненужные нам примеси.

Чего хотят цеховые: каждый раз, когда сталь готова, этот горшок наклоняется, и из него выливается расплав в ковш на железнодорожной платформе.

И им нужно заглянуть в Ородруин. В смысле посмотреть на горловину, чтобы узнать насколько она зарастает шлаком и чугуном.

Кстати, она еще и бороду снаружи отращивает.

Пока конвертер наклоняется к платформе, горловина сзади красиво подсвечивается расплавом. Если мы сможем повесить камеру под 45 градусов и ловить точный момент во время наклона, то они будут очень счастливы. Данные наклона есть в АСУТП и, соответственно, в шине, потому что мы знаем положение механизма.

Мы сделали синхронизацию через шину: как только градус доходит до расчётного, камера делает фотографию, определяет степень зарастания и отправляет её в диспетчерскую цеха.

Заодно мы стали разбираться, зачем им это, и из этого пошла ещё серия проектов.

В результате нашей командой мы реально повлияли на количество выплавляемой в стране за год стали: парой шажков — тут, парой — там, но в итоге прямо значимо. Сейчас расскажу.

Перекличка эпох. Буквально недавно я опубликовал очередную cool-story о лихих математиках из лихих 90-х, как получил живое свидетельство алгоритмов управления прямиком из тех легендарных времен.

Заливаем алгоритмы, созданные 20 лет назад для АСУ ТП нефтепровода, в современные контроллеры .

По работе сейчас нужно сделать стенд-демонстратор. Задача – показать, как, используя среду математического моделирования, можно заливать одни и те же технологические алгоритмы АСУ ТП в контроллеры от разных производителей и на разных аппаратных платформах. Идея в том, чтобы спроектировать алгоритм в SimInTech один раз, а потом, при смене контроллера (привет санкциям и старушке Шапокляк фон дер Ляйен), уже ничего не нужно проектировать заново: ни этот же самый алгоритм, ни создавать его заново в другой среде разработки. Открываем SimInTech с готовым проектом – и пожалуйста:

«…нажми на кнопку – получишь результат,

И твоя мечта осуществится.

Что ж ты не рад?

Тебе больше не к чему стремиться!»

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

«…а ещё вчера все вокруг говорили: Siemens – друг, Siemens наш немецкий друг…»

На этом месте возник у меня вопрос: а что, собственно, взять в качестве примера для стенда-демонстратора? Первая мысль, конечно, обратиться к текущим проектам в которых нас привлекают как консультантов:

О создании системы ситуационно-аналитического центра рассказывает Александр Таскаев, директор департамента интеллектуальных систем автоматизации компании САТЕЛ.

Вчера я 4 минуты стоял в подъезде и смотрел, как два лифта одновременно поехали вверх. Все два. На табло — 12, 15, 18. Я на первом. Мне на шестой. И я подумал: вот я кучу лет пишу софт, оптимизирую запросы к базе данных, кеширую всё что движется — а эти две коробки на тросах не могут разобраться, кто из них должен спуститься за мной.

Потом я погрузился в тему. И выяснил, что они не «не могут разобраться». Они математически не способны найти идеальное решение. Вообще никто не способен. Задача диспетчеризации группы лифтов — NP-трудная. То есть буквально: не существует алгоритма, который гарантированно найдёт оптимальный маршрут за разумное время.

И вот уже 60 лет лучшие инженеры мира решают эту задачу эвристиками. По сути — догадками.

«Внедрение нейросетей на производстве — это часто скрытая война»

Камиль Гадеев

Автоматизация производства — это не только написание кода. За каждым успешным внедрением стоит невидимая работа: убедить людей, преодолеть сопротивление, выстроить доверие. Именно об этом — несколько историй в ретроспективе.

В статье байки из реальных проектов: типография, мебельная фабрика, ремонт автомобилей и др. О том, как скандал стал лучшей рекламой новой программы, как найти «звезду» в коллективе и почему склад — это болевой нерв производства.

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

Эта статья продолжает цикл воспоминаний разработчика тренажёрных комплексов. Несколько лет назад наша команда столкнулась с задачей создания эмулятора автоматизированной системы управления технологическим процессом (АСУ ТП) для одной из тепловых электростанций. Задача выглядела стандартной и несложной: воспроизвести логику контроллеров, разработать мнемосхемы и запустить модель.

Однако реальность внесла свои коррективы. Исходных данных не хватало, сроки были крайне ограниченными, ресурсов недостаточно, а первая версия интерфейса HMI, созданная на собственном проверенном, но морально устаревшем инструменте проектирования, не соответствовала требуемым характеристикам производительности и масштабирования.

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

Снаружи Лёха это 3-4 метровая арка с вертикальной камерой. Она сканирует лист дерева - шпон. Также есть лампа чтобы не было затенений. Свет ложится полоской линией. Так, чтобы Алексею было удобнее работать.

Мишаня же выглядит как молодой мужчина. Крупный брюнет, в спецовке, весельчак-приколист. Михаил поставил камеру над другим станком. Обычная камера, не самого высокого разрешения. Сделал на c#, с использованием openCv, программу, сканирующую шпон. И связал с контроллером. Осталась корректировка программы китайского станка. Промышленная программа у китайского станка также китайская. Так что предстоит битва.

Как упоминалось в “Часть 7. Внедрение (Развертывание), ввод в эксплуатацию” , посвященной данной стадии производства, это, пожалуй, самая сложная с эмоциональной точки зрения фаза. Милые разговоры и посиделки с Заказчиком за чашкой чая с мечтами о том, как теперь то он заживет, без болей и забот с новым Продуктом – закончились. Больше никто не хочет “годить” и “входить в положение”, забрала упали и идут бои местного значения между командой разработки и клиентом, каждый за свою правду о сложившемся положении. Поэтому команда внедрения должна обладать такими качествами, как стрессоустойчивость, терпеливость и снисходительность. Процессы чаще всего обустроены следующим способом:

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

Фаза Разработки, как мы упоминали ранее, в своей основе чаще всего использует итерационный подход, обеспечивающий выполнение однотипных циклов, в результате которых целевой продукт постепенно прирастает новой функциональностью.

Это история про проект RIIOT. Про мосты между Spring Boot и протоколом 1979 года. Про реактивные потоки, которые несут данные от датчиков к экрану оператора быстрее, чем он успевает моргнуть. И про то, как мы научились не бояться железа.

Была такая производственная история на металлургическом комбинате несколько лет назад, которой я занимался.

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

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

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

Тут все стоявшие единой кучкой стали ныть что ей же три года, как они могут брать её в работу, да и документов на неё уже нет.

Как создавать пользовательские типы данных в открытой АСУТП? Зачем объединять скорость, температуру и статус двигателя в одну переменную?

В ИТ-команде «Северстали» мы занимаемся разработкой компонентов для открытой АСУТП. В этой статье разберём, как создавать и применять пользовательские типы данных в нашей среде разработки Flogic. 

В этой статье вы узнаете, как структурировать данные, повысить читаемость кода и переиспользовать тип переменных по всему проекту.

Продолжаем цикл статей о движении двигателестроительных компаний по пути импортозамещения зарубежного ПО. Сегодня снова расскажем о применении среды математического моделирования Engee в процессах разработки систем управления газотурбинными двигателями.

Если мы говорим, что само по себе двигателестроение - это наукоёмкая отрасль, и работают в ней буквально десяток компаний в мире, то разработка электронных блоков управления этими двигателями - ещё более узкая отрасль промышленности. В России этим занимаются только пара-тройка компаний и одна из них - пермская ОДК-СТАР из контура Объединённой Двигателестроительной Корпорации. Проектирование систем управления двигателями - их непосредственная специализация, а номенклатура продукции включает системы автоматического управления не только авиационными двигателями, но также и ракетными, морскими двигателям и промышленными турбинами.

АСУТП — основа современной промышленной автоматизации и инфраструктуры
управления. SCADA-система (Supervisory Control and Data Acquisition) является
частью, которая обеспечивает интерфейс между операторами и оборудованием, а
также сбор и анализ данных в реальном времени. Обычно это программный пакет,
предназначенный для обеспечения работы системы и/или разработки таких систем, —
сухое определение, которое заставляет вспоминать предмет ТАУ (теория
автоматического управления) и ПИД-регулятор. Ничего интересного — одни формулы.
Такие мысли мне тоже приходили в голову в момент распределения после завершения
учебы в университете. Так получилось, что на последнем курсе устроился работать
в классическую IT-контору, но не остался там надолго и пошёл пробовать себя на
молочный завод — в тогда ещё молодой отдел АСУТП. Что из этого вышло, далее попытаюсь
рассказать в этой статье.