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

У вас дома есть умная розетка? Или датчик протечки воды под раковиной? Если есть — вы уже знаете, что такое интернет вещей. Небольшой девайс висит на стене, следит за температурой или влажностью, а когда что-то идёт не так — шлет уведомление на смартфон.

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

В этой статье разберем, как СИБУР внедрял промышленный интернет вещей: почему отказались от кабелей, как адаптировали датчики к морозам -56°С, какие параметры контролируют на заводе и зачем понадобилась собственная платформа вместо готового решения.

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

Три основных типа карьерных самосвалов в России

В российской добывающей отрасли применяются три доминирующих класса машин, каждый из которых имеет собственные особенности измерения веса:

Классические карьерные самосвалы с жёсткой рамой, такие как БелАЗ 7555–7513 и CAT 777–793, оснащаются гидропневматической подвеской с датчиками давления. Эти датчики служат для оценки веса полезной нагрузки через измерение давления в подвеске. Однако их данные сильно зависят от темпа движения и амплитуды раскачки кузова, что создает шумы и неточности при динамическом движении. В качестве инженерного дополнения к измерению веса для таких моделей важно применять алгоритмы фильтрации и компенсации динамических колебаний, а также дополнять данные от датчиков давления весовыми сенсорами, установленными на шасси, для повышения точности оценки нагрузки и снижения влияния факторов движения. Для БелАЗ и CAT, реализованы высокоточные системы взвешивания с погрешностью в диапазоне до ±0,1–1%. Однако, из-за сильных вибраций и динамических пиков в процессе работы, количество данных с аномальными колебаниями составляет примерно 20–35%. Благодаря строгой конструкции и стабильной гидравлической и электронной схемам, такие системы обеспечивают относительно меньшую дисперсию и более предсказуемую точность, особенно при использовании фильтров и компенсационных алгоритмов.

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

В первой части мы узнали, что главной хитростью автоматизаторов тех лет оказалось реле. Именно с помощью этих простых устройств делали ооочень непростые вещи. Но ХХ век шел вперед и инженеры сталкивались вызовами, масштаб которых раньше сложно было представить. 

Если когда-нибудь у вас в руках было электромагнитное реле, то вы знаете этот приятный щелчок, когда оно срабатывает. За этим звуком — целая эпоха.

Задолго до того как умный чайник получил Wi-Fi, а на заводах развернули первые SCADA, инженеры XX века строили умные системы на реле, шаговых искателях и Булевой алгебре. 

Без микропроцессоров, без языков верхнего уровня, без OTA-обновлений. Только электромеханика.

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

Статья о небольшой эпопее с поиском ошибки в работе WiFi на плате ESP32-C3 SuperMini, с которой пришлось разбираться в процессе отладки кода прошивки для контроллера батареи АКБ (О контроллере батареи ИБП (вопрос к читателям Хабра) и О контроллере батареи ИБП (часть 2)).

Симптоматика проблемы с WiFi следующая: после включения питания и начала авторизации по WiFi плата ESP32-C3 SuperMini через какое-то время зависает, вплоть до срабатывания сторожевого таймера. Поиск решения проблемы в интернете не помог, но было замечено, что в эти моменты на плате очень сильно нагревается стабилизатор напряжения 3.3V, да так, что даже рука не терпит, тогда как при работе тестовых примеров (где WiFi работает нормально) такого эффекта не наблюдается.

Из-за этого решил копать именно в этом направлении.

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

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

Но по прошествии многих десятилетий проблема чисто технических ошибок в программном обеспечении так и остаётся нерешённой по сей день, однако подход, предложенный в языке Rust, меняет всё.

Открытая АСУТП хороша тем, что её можно и нужно адаптировать под себя. Но что делать, когда встроенного функционала не хватает? Когда вам нужна уникальная логика, алгоритм или расчёт?

Ответ — создавать свои функциональные блоки. Именно этот шаг превращает вашу АСУТП из «коробочного» решения в по-настоящему гибкую систему, заточенную под ваши процессы. В этой статье, продолжая наш цикл о построении открытой АСУТП, мы на практике подробно разберём один из двух основных вариантов разработки пользовательских функциональных блоков.

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

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

Эти внутренние стандарты автоматизации редко показывают публике, но именно они превращают сотни заводов в один живой организм, где каждая линия, каждая установка подчиняется общей инженерной логике.

Там, где другие строят с нуля, Nestlé просто открывает шаблон. Где кто-то ищет «как сделать», Iberdrola просто следует собственному кодексу автоматики.

И чем сложнее технологии, тем ценнее становится не оборудование — а порядок.

Митапы про микросервисы, хайп вокруг новых фреймворков, кеш и перекрашенные кнопки — привычная рутина современного айтишника…

Но мы-то знаем: есть и другое IT. Там пишут код, от которого зависят тонны синтетических материалов или выплавленной стали, скорость производственной линии и бесперебойная работа энергосети. Это мир Heavy Digital. И он становится всё больше.

Мы захотели выяснить, почему всё больше IT-специалистов осознанно выбрали работу на заводах и в промышленных гигантах. Что за мотивы ими движут, какие задачи вызывают настоящий драйв и чувство сопричастности к чему-то большому? Мы собрали эти и другие вопросы и приглашаем всех причастных к IT в промышленности ответить на них в ветке «Я эксперт в Heavy Digital».

А ещё мы хотим узнать мнение тех, кто слышал о Heavy Digital и только стоит на пороге выбора. Чтобы понять ваши ожидания и страхи, мы создали ветку опроса «Я пока не в Heavy Digital».

Спойлер: в конце ветки для экспертов у вас будет возможность рассказать о самом запоминающемся профессиональном вызове. Авторы 10 лучших историй смогут получить ачивку «Герой Heavy Digital» в своем профиле на Хабре.

Готовы? Тогда выбирайте свою ветку — и вперёд!

Статья начинает цикл материалов по разработке электроприводов, подходов и технических нюансов, которые используются при их проектировании. Охватим большую часть силовой электроники для электропривода, промышленные сети (PROFINET, EtherCAT, CC-Link, EtherNet/IP (CIP) и др.), энкодеры (абсолютные: Hiperface DSL, SSI, BISS и др., а также инкрементные). Датчиковое и бездатчиковое векторное ориентированное управление  (sensored/sensorless FOC - EKF/MRAS/SMO/HFI), рассмотрим электродвигатели PMSM (СДПМ), ACIM (асинхронный ЭД), BLDC (бесколлекторный двигатель постоянного тока) и другие их виды. 

С 11 по 22 ноября 2025 года в Российском новом университете пройдут тренинги предпринимательских компетенций. Мероприятие организовано Московским физико-техническим институтом совместно с Российским новым университетом в рамках федерального проекта «Платформа университетского технологического предпринимательства».

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

Копились и другие проблемы.

Например, пользователи стали продвинутыми и жаловались на дружелюбность интерфейса. На самом деле тяжело представить в одном предложении слова «дружелюбность интерфейса» и нашу старую систему заявок на транспорт.

Всё это работало только под IE/Edge, не поддерживало Хромиум, конфликтовало с требованиями ИБ.

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

Мы давно задумывались о рефакторинге или миграции, суть споров сводилась к самопису или «коробке».

Мы всё проанализировали и решили, что надо взять готовую «коробку», которую потом нужно будет допилить процентов этак на 10.

В итоге оказалось, что сначала мы допилили процентов на 20, а потом от исходной «коробочной» версии осталось процентов 10, и вся разработка переехала к нам внутрь.

Сейчас я расскажу о дьявольском опыте использования чужой «коробочной» версии как фреймворка для своей разработки. Забегая вперёд — второй раз мы в это не полезли бы.

Привет, Хабр! Одна из задач при управлении роботами-манипуляторами – расчет обратной кинематики. Данный вид кинематики позволяет вычислить углы наклона суставов робота (joints) таким образом, чтобы захват (grip) робота пришел в заданные трехмерные координаты с правильным углом наклона. Для многих роботов уже есть алгоритмы и формулы вычисления обратной кинематики, мы (команда Zebrains) столкнулись с отсутствием готового решения для робота xArm 2.0.

В статье мы подробно опишем с какими сложностями столкнулись при управлении данным роботом, как получили формулы для расчета двух видов кинематики для данного робота и поделимся кодом на C++. В проекте использовался ROS2, ноды которого были написаны на C++.

Сегодня сложно представить технологическую компанию, которая бы всерьёз занималась разработкой и не использовала инженерные расчёты. CFD-, FEA-, тепловые, а также одномерные (1D) симуляции давно стали повседневными инструментами.

При этом расчёты могут быть очень дорогим удовольствием: бывает расчет требует сотни часов машинного времени, а также участия нескольких специалистов. А значит, результаты – это не просто «файлы», а важный и ценный актив компании.

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

Если расчёты – это актив, то ими нужно активно управлять. Расскажу, как подойти к этому шаг за шагом.

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

Вы видели такие токарные автоматы? Это шестишпиндельный 1Б240-6 револьверного типа. Очень старый девайс, полностью механический, на концевиках и реле. Никаких тебе ЧПУ, лазеров и шаговых двигателей, только хардкор. Это просто потрясающая механическая симфония.

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

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

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

2010 год: я работал на одном промышленном предприятии. За пару лет до моего прихода они закупили комплект автоматики у другого подобного предприятия. Как это часто бывает, сначала какая-то организация делает автоматику для решения своих задач, а затем, видя успешность своего решения, начинает продавать это решение себе подобным.

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

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

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

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

И рассматривая наработанные материалы группы, я понимал что они с самого начала всё делали неправильно. То есть люди они были может быть и не плохие, но вот теорию знали не всю и особенно не понимали практические моменты производства, испытаний и эксплуатации. Реакция людей когда им говорят, что они не понимают сути вопроса бывала разная — от истерик до ступора, ведь весь их результат работы ничтожен и нужно начинать заново — тут редко у кого нервы выдержат. И руководство обычно задавало мне вопрос — А почему об этом вы говорите только сейчас?

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

В DevelSCADA используется версия протокола OPC UA, так как он на данный момент является наиболее популярным и кросплатформенным. Так же протокол OPC UA имеет множество механизмов по защите соединения, что может быть актуальным при работе по незащищенном каналам связи (к примеру через сеть интернет).