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

Сегодня я хочу показать и рассказать вам, как, подключив к ESP32-S3 тепловизионную матрицу MLX90640, можно запустить веб-сервер для стриминга теплового изображения с определением в реальном времени того, какие сущности попали в поле зрения тепловизора.

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

Данная система является полностью автономной, и инференс TensorFlow Lite-модели происходит прямо на борту микроконтроллера.

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

Эта история начинается для главного героя там, где заканчивается привычный мир поверхностных и скоростных релизов, «игрушечных» проектов и вечной гонки за охватами и востребованностью. В свой первый рабочий день на заводе он оказался вовлечён в расследование аварийного инцидента и увидел, как цифровые решения управляют дронами, предотвращают аварии и распределяют ресурсы. Если вам интересно — заходите под кат.

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

Цель работы. Изучить возможность применения и адаптации большой языковой модели OpenThinker2-32B, как дополнительного и вспомогательного инструмента, применяемого для повышения эффективности работы автоматизированных систем прогнозируемого обслуживания многостадийных технологических процессов для малых и средних промышленных предприятий. Это позволит решить следующие задачи: выполнить анализ исторических данных; с помощью алгоритмов, разработанных на основе теории свидетельств Демпстера-Шафера снизить факторы неопределенности произвести прогнозирование отказов, а также подготовить экспертные рекомендации по оптимизации расписаний и процессов технического обслуживания промышленного оборудования. Также необходимо разработать алгоритмы информационного взаимодействия для каждой из задач, и определить положение большой языковой модели в предложенной концепции конвергентной архитектуры автоматизированной системы прогнозируемого обслуживания для повышения точности прогнозов и возможности ее интеграции с экспертными, аналитическими, прогнозными системами и системами поддержки принятия решений.

В этой части цикла, посвященного разработке электропривода, мы сосредоточимся на его электронной составляющей. Рассмотрим топологии силовых узлов AC/DC, DC/DC и DC/AC электропривода, подбор электронных компонентов, а также ключевые нормативные стандарты, которых необходимо придерживаться при проектировании. Отдельный раздел будет посвящен выбору вычислительной платформы для управляющей платы — FPGA, DSP, SoC и другие варианты. Кроме того, затронем вопросы функциональной безопасности (safety) в электронике и требования к безопасной работе электропривода.

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

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

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

20 ноября в «Точке кипения» на Малом Конюшковском переулке прошел отраслевой слёт «Молодёжные инженерные команды (МИК). Развитие талантов для дроносферы будущего», который стал ключевой точкой для подведения итогов двух лет работы федерального проекта под эгидой Минобрнауки «Кадры для БАС». На одной площадке встретились представители федеральных властей, ректоры ведущих вузов и руководители профильных компаний, чтобы оценить достижения и определить новые цели проекта на 2026 год.

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

Теперь представьте то же самое, но не в квартире, а на нефтехимическом заводе площадью в несколько квадратных километров. Там не десять розеток, а тысячи труб, насосов, реакторов. И за каждым нужно следить. Именно для этого и придумали промышленный интернет вещей — 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++.