Промышленная инженерия

Олег Линьков, Webformula | Май 2026

Когда я начал разбираться в производстве риса, ожидал найти аграрную архаику. Нашёл производственную систему, в которой оптическая сортировка зерна, контроль температуры шлифовки и молекулярный состав крахмала связаны в единую технологическую цепочку. И где 40 операторов управляют переработкой 40 000 тонн зерна в год — соотношение 1:1000.

Разберём, как это устроено изнутри.

Сварка, которая не ведет себя прилично: зачем промышленности моделирование

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

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

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

Боль №1: деталь повело
Это брак, правка, сорванные сроки. Моделирование позволяет заранее оценить поведение конструкции.

Боль №2: остаточные напряжения
Деформации можно увидеть. Остаточные напряжения коварнее. Они влияют на трещины, усталостную прочность, коррозию и ресурс. Особенно опасно для сосудов, трубопроводов, рам. CAE покажет опасные зоны.

Боль №3: подбор методом «а давайте попробуем»
Факторов много: ток, скорость, тепловложение, последовательность швов. Изменение одного лечит одно, но калечит другое. Моделирование не заменяет технолога, а даёт инструмент для сравнения вариантов.

На практике моделирование позволяет ответить на приземленные вопросы: как сильно поведет изделие? Где будут максимальные напряжения? Можно ли уменьшить правку? Это язык производства. Не «красивая картинка», а «мы нашли проблему и знаем, как ее уменьшить».

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

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

Двигатель с постоянными магнитами на поверхности ротора (SPMSM) — прост и предсказуем. Магнитный зазор равномерен, индуктивности по обеим осям одинаковы, момент создаётся единственным способом. Управлять им несложно.

Двигатель с интерполированными постоянными магнитами IPMSM (Interior Permanent Magnet Synchronous Motor) — устроен принципиально иначе. Магниты утоплены в тело ротора, что нарушает симметрию магнитной цепи. Возникает анизотропия: магнитное сопротивление ротора различается по двум взаимно перпендикулярным направлениям. Следствие — дополнительный источник момента, реактивный, существующий исключительно за счёт разницы индуктивностей по осям d и q.

Именно эта анизотропия делает IPMSM привлекательным для тягового привода. Широкий диапазон ослабления поля, высокая удельная мощность, возможность использовать реактивный момент для снижения токовой нагрузки — всё это следствие одного конструктивного решения: магниты внутри, а не снаружи.

Реализовать потенциал IPMSM позволяет стратегия MTPA — Maximum Torque Per Ampere. Она находит оптимальное распределение вектора тока статора между осями d и q: такое, при котором заданный момент достигается при минимальной амплитуде тока. Меньший ток — меньше потерь в меди, меньше нагрев, меньше нагрузка на инвертор.

В настоящей статье рассматривается физика анизотропии IPMSM, математическая модель машины в системе координат d‑q и стратегия MTPA как задача оптимизации с аналитическим решением. Модель реализована в системе моделирования Engee и верифицирована сравнением режимов FOC и MTPA на параметрах макетного образца IPMSM.

Осенью 2025 года в ЦИТМ «Экспонента» обратились инженеры АО «Концерн «НПО «АВРОРА» - флагмана отечественного судостроения, предприятия с полувековой историей и серьезным портфелем гражданских и специальных проектов. Коллеги поставили перед нами задачу: провести комплексную оценку среды Engee как платформы для модельно-ориентированного проектирования программного обеспечения для программируемых логических интегральных схем (ПЛИС) и микроконтроллеров (МК). Цель проекта – заменить зарубежные решения в реальных промышленных задачах, а далее мы расскажем подробно, как проходила эта работа, какие технические вызовы пришлось преодолевать и к каким выводам пришли инженеры с обеих сторон.

Внедрили MES, а производство как работало, так и работает? Интегратор обещал прозрачность, а руководство предприятия получило гору отписок в духе «некогда сканировать»? Разбираемся, что с этим делать.

Когда мы разрабатываем настольную операционную систему, очень легко попасть в архитектурную ловушку: начать строить систему вокруг одного типа приложений. Исторически так и происходило: Windows запускала Windows‑приложения, macOS запускала macOS‑приложения и Linux — Linux‑приложения. Но пользователь живет не в этом мире. Ему неважно, на каком языке написана программа, под какую платформу она создавалась и какая у нее экосистема. Он хочет, чтобы нужные приложения запускались у него быстро и максимально удобно.

Привет, Хабр! Меня зовут Илья Клементьев, я старший инженер‑программист в отделe разработки сервисов настольной ОС в YADRO. Современные ОС постепенно двигаются в сторону универсальных хостов — то есть систем, которые способны запускать приложения из разных программных экосистем. В статье я расскажу, как можно запускать Android‑ и Windows‑приложения внутри Linux, какие технологии для этого используются и как устроена многоуровневая архитектура системы с виртуальной машиной и контейнерами.

Для того чтобы определить вероятные положения летательного аппарата в окрестностях траектории необходимо использовать комплексную обработку данных полученных с различных источников, в рамках данной статьи предполагается что в основу расчета берем усредненные параметры участка траектории ЛА, известные координаты РЛС которые определяют его положение, дисперсии для каждой РЛС (в рамках данного моделирования берем две, но в произвольном случае может быть любое количество)

Подобные расчеты требуются для того чтобы определить как близко могут пролететь самолеты один относительно другого в сложных навигационных условиях (например в условиях заглушенного сигнала GPS), область вероятного положения в каждый момент времени при движении летательного аппарата будет представлять собой серию эллипсоидов, параметры данных эллипсоидов будут вычисляться с помощью скрипта на языке Engee

Изучите принципы информационного моделирования на практике.

Разбираем возможности с помощью демонстрационного архитектурного проекта в nanoCAD BIM Строительство: двухэтажного загородного дома «с нуля».

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

Сегодня в блоге ЛАНИТ мы бы хотели поделиться, как продукт для лесной отрасли на основе алгоритмов компьютерного зрения прошел путь от пилотной версии до гибкой бизнес-системы и выжил в условиях, когда у сотрудников клиента нет связи, а поставщики не всегда добросовестно измеряют объемы древесины.

Привет! Я Владимир Потехин, разработчик в Т-Банке в ИТ-хабе Нижнего Новгорода. Моя статья — первая в спецпроекте «20 в 20» к 20-летию Т-Банка. Двадцать специалистов из двадцати городов расскажут свои истории в серии статей, чтобы показать, как выглядит наша распределенная ИТ-карта. За эти годы Т-Банк сильно вырос, вместе с ним выросла и инженерная среда: команды работают в разных городах, но остаются частью одного большого процесса.

Я много времени уделяю работе с опенсорсом и искренне за него радею. Люблю опенсорс за ощущение общего дела: когда код не просто пишешь, а вместе с другими улучшаешь, обсуждаешь, докручиваешь и делаешь полезнее.

В крупной компании есть объективное ограничение: не каждый проект можно вынести за периметр. Даже хорошо изолированный от бизнес-логики код часто несет на себе груз внутренней инфраструктуры, договоренностей, данных и открыть его невозможно даже при большом желании.

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

Можно ли из смарт-камеры сделать полноценную систему машинного зрения? Можно, нужно подружить её C-библиотеку Hikrobot IDMVS SDK с OpenCV через Python. О том, как это сделать — расскажу на примере кейса печати маркировки на мешках строительной смеси: как мы проверяли синхронность печати кодов маркировки, искали белые квадраты, попадали в них кодами, дублировали по 4 кода на один мешок.

nanoCAD GeoniCS, nanoCAD Облака точек и другие специализированные инструменты помогают «Северо-Западной энерго-ресурсной компании» (СЗЭРК) быстро создавать топопланы, проектировать инфраструктуру и проходить государственную экспертизу.

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

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

Проблема была в следующем: сотрудник вводит одну величину, а по ней ищет другие в таблицах. Пока человек найдёт нужное значение в таблице, внесёт его в ячейку Excel — и так ещё 4 раза на один расчёт — проходит реально много времени. А если он ошибётся (что вполне вероятно при рутине)? Расчёты придётся переделывать.

Мной были модернизованы печи: PZ-810, PZ-803, советские ростовские печи шахтного типа, печи элеваторного типа, сейчас производится модернизация печей с горизонтальной загрузкой.

Модернизация печи сводится к замене электроники, устанавливается свой контроллер сбора данных.

Полгода прошло с первой статьи https://habr.com/ru/articles/969230/ , вариометр летает и сигнализирует о наборе высоты и о потере высоты, пилоты довольны. Код сыроват конечно. EMA фильтр стоит, линейная архитектура стоит, записи высот в полете нет и экспорта нет. Как-то работает. Но можно качественнее сделать. А вот когда лень переписывать с нуля, знакомая херня? Но решился.

Развернул Hermes Agent, закинул на аккаунт DeepSeek4 40 юаней, это 430 рублей, и начал диалог в терминал. Работал в диалоге с консолькой, ну просто магия. Без промптов. "Сделай FSM вместо ифов, добавь зуммер в стиле Браунигер, компенсацию акселерометра по трём осям с учётом гравитации, а не по модулю, трек полёта на флешпамять кольцевым буфером с CRC, WiFi экспорт через вебморду."

Автор: Александр Никулин, архитектор цифровых двойников ГК "ПЛМ Урал"

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

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

Факт 1.  Максимально циничная и максимально честная фраза, услышанная мною от одного из топ-менеджеров компании Siemens. В переводе на русский она звучит как «Деньги все расставляют по своим местам».

Факт 2.  Более 25 лет на просторах всемирной сети существует шутка, потрясающе точно отражающая реальный мир. В споре двух ученых, один воскликнул: «Вспомни историю человечества! Первая обезьяна, которая взяла в руки палку и начала работать, стала человеком!». Второй же ученый сочувственно взглянул на своего коллегу и сказал: «Не хочу обижать старика Дарвина, но, когда первая обезьяна взяла в руки палку, работать начала вторая».

Теперь вернемся к цифровым двойникам. Четвертая промышленная революция (Индустрия 4.0) постулирует цифровой двойник как основу жизненного цикла изделия. Причем в качестве изделия может выступать как физический объект, так и технологический процесс, логистический процесс и даже конкретный индивид. (да-да, цифровой двойник клиента уже реальность: имитация поведения, предпочтений и реакций на внешние воздействия в реальном времени. Все уже используется для вашего… разумеется удобства).

В AI-first разработке в продукт прилетает всё больше pull request от людей с разной глубиной контекста. Формально такие PR могут выглядеть нормально, но ревью всё чаще упирается не в синтаксис, а в попытку понять, что именно этот набор изменений делает с системой.

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

Возможно, на мой предвзятый взгляд, нынче автоматным программированием (АП) называют любое программирование, в которое вводят состояния (а параллельным – где используют потоки). Но не все, что с колесами – машина, а с крыльями – самолет. И далеко не всегда то, что «выглядит» как автомат, «плавает» как автомат и «крякает» как автомат им является. Это ясно, если руководствоваться математическим определением конечного автомата (КА). Только соответствие этому позволяет  считать программирование автоматным. Подробнее же об АП рассказано в [1].

Среди существующих программных подходов некоторые на взгляд программистов относятся к категории АП. Это, например, варианты диаграмм Харела (Statecharts) и языков на них основанных. Например, UML (Unified Modeling Language). Именно этой теме посвящена статья на Хабре, которая описывает проектирование на базе КА  в среде Engee[2].  В последней есть библиотека «Конечные автоматы» – «лучший инструмент для визуального проектирования сложной управляющей логики» [3].

Разберем данную статью, создав аналог рассмотренного в ней решения, но только на языке С++ и в среде ВКПа – классическом варианте технологии автоматного программирования. Это позволит объективно сравнить подходы, а вам, «хабравчане», останется только составить уже свое мнение о разных вариантах АП.

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