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

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

Идея открыть исходный код закладывалась с самого старта проекта, но была реализована поэтапно. Первым шагом в 2023 году стало открытие фронтенда (cdbs-app) под лицензией MIT. В 2026 году, с релизом v0.3.2, в статус Open Source под лицензиями GNU AGPL v3.0 и PostgreSQL License перешли все оставшиеся части платформы, полностью закрывая этот долг перед сообществом. Теперь это полноценное, независимое и технологически продвинутое решение для инженерных команд.

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

Разберём, как с помощью точных методов мат. моделирования (MIP, CP-SAT) собрать систему распределения парка по заказам, которая не гоняет технику через весь город и может закрыть почти на 19% больше заказов, чем жадная логика «бери ближайшую заявку».

Материал будет полезен специалистам по математической оптимизации и разработчикам, которые ищут очередной практический кейс MIP/CP-SAT (будут тонкости). А диспетчерам и управленцам компаний-арендодателей спецтехники, возможно, будет интересно узнать, во сколько на самом деле обходится распределение «на глаз».

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

В этой статье — про бесконтактное измерение температуры расплавленного металла, основанное на приеме теплового излучения в мм‑диапазоне. Центр компетенции по мм‑волновой технике «ДОК» провел очередной этап промышленных испытаний СВЧ‑радиометра МРИТ-76 — прибора для непрерывного бесконтактного контроля температуры расплавленного металла по его собственному тепловому излучению.

Методы replaceUsing и replaceOn обеспечивают более удобный способ перезаписи, а каталог теперь проверяет каждую операцию, а не только фиксацию.

Выпуск Delta Lake 4.3 состоялся в июне 2026 года, и он основан на Apache Spark 4.1.0 и 4.0.1. Если прочитать примечания к выпуску от начала до конца, вы увидите длинный список изменений, охватывающих Delta Spark, ядро, UniForm, Sharing и Flink, который легко принять за релиз с исправлениями, дополненный описанием каталога обновлений.

Два момента заслуживают вашего внимания, и они находятся на противоположных концах стека. Первый — небольшой и сразу полезный: replaceUsingнаконец replaceOn-то API DataFrame получает возможность выборочной перезаписи, которая не является replaceWhere. Второй — структурный: теперь каждая операция с таблицей, управляемой каталогом, проходит через API Unity Catalog Delta , а не только фиксация изменений. В Delta 4.2 фиксации изменений были скоординированы с каталогом. В Delta 4.3 остальная часть интерфейса, загрузка таблиц, CREATE, CTAS, REPLACE, и запись метаданных, объединены в один проверенный путь.

В этой статье рассматривается версия 4.3 с точки зрения разработчика конвейера: какие изменения в коде вы вносите, какие изменения происходят под вашим контролем и что следует проверить перед обновлением. Приводятся примеры testing.defaultдля каталога и схемы, а также пример компании CH Enterprise. Ссылки на исходный код находятся внизу.

Мы идём по тёмному цеху, освещение мерцает, где‑то капает вода, пар свистит, вырываясь из небольшого отверстия в трубопроводе. Старые пульты управления, покрытые пылью, копотью и паутиной. Проходя мимо пультовой, улавливаешь запах сигарет и кофе — верные, вечные спутники оперативной смены. Слева, на высоте метров десяти, работают котлы, издавая звук, схожий с рёвом Роковой горы в самом сердце Мордора. Весь путь пропитан хтоническим ужасом — не хватает только своего Фредди Крюгера или Джейсона Вурхиза. Хотя кто знает, что тут по ночам происходит.

И вот мы приходим к нашему месту «жертвоприношений» — тренажёрному классу для обучения операторов ТЭЦ. За стеной — цех с четырьмя энергетическими котлами БКЗ, за окном — минус 35, а впереди — две недели установки софта, наладки, ввода в эксплуатацию и обучения инструкторов. Хоть и кажется, что вся эта компьютерная техника с красивыми картинками здесь чужеродна…

Станция мониторинга микроклимата спальни из этой статьи — часть дипломной работы. Собрана она на плате NapiSci, учебном конструкторе для процессорного модуля NAPI-C (Rockchip RK3308). В статье — что входит в базовую комплектацию платы, что студент добавил сверх нее под конкретную задачу, как данные со станции и с носимого модуля сходятся на сервере и превращаются в гипнограмму, и какие реальные баги пришлось ловить при отладке на живом железе. В конце — что из этого получилось у станции конкретно, и приглашение талантливым студентам обращаться за бесплатными учебными платами для дипломных работ.

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

QEMU — это не просто виртуализация с KVM. Его главная cуперсила — способность запускать программы, скомпилированные для одной архитектуры, на совершенно другом процессоре. Безо всякой поддержки со стороны хоста. Например, запустить прошивку для ARM-микроконтроллера на x86-ноутбуке.

Как это работает? Под капотом QEMU скрывается JIT-компилятор под названием TCG (Tiny Code Generator). В этой статье мы разберем его устройство на практических примерах для RISC-V и посмотрим, как инструкции превращаются из одного машинного кода в другой, как формируются блоки трансляции, и зачем там нужны longjmp и цепочки блоков.

Начну со сцены, которую видел каждый, кто эксплуатировал платёжный сервис хотя бы год.

Клиент нажимает «Оплатить». Приложение отправляет POST /payments. Проходит пять секунд, и HTTP-клиент падает по таймауту. Ретрай-политика, которую кто-то настроил год назад по гайду, ждёт двести миллисекунд и отправляет запрос ещё раз. Через минуту клиент видит в выписке два списания.

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

Первый вывод: надо выключить retry на POST. Хорошо, выключили. Теперь у нас платежи, про которые никто не знает, прошли они или нет. Поддержка разбирает их руками. Ущерб никуда не делся, он просто переехал на другой счёт.

Второй вывод: надо добавить заголовок Idempotency-Key. Добавили. Дедупликацию сделали в middleware поверх Redis. Через полгода двойное списание случается снова. Потому что Redis пережил failover и потерял ключи. Или потому что повтор пришёл через сутки из файла клиринга, а в файле никакого HTTP-заголовка нет.

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

Retry сам по себе всего лишь тактика. Он работает там, где контракт уже есть. Без контракта retry не делает систему устойчивее. Он делает её быстрее ломающейся.

Переход строительной отрасли на отечественные ТИМ/BIM-решения поставил перед застройщиками, техническими заказчиками и проектными организациями практический вопрос: способны ли российские программные продукты обеспечить полноценное информационное моделирование без использования зарубежного программного обеспечения и сохранить привычные процессы взаимодействия участников проекта?

В статье представлен практический опыт реализации одного из первых в России проектов по комплексной разработке всех основных разделов проектной документации многоквартирного жилого комплекса с использованием отечественной ТИМ/BIM-платформы nanoCAD BIM Строительство и nanoCAD Инженерный BIM¹ (далее – nanoCAD BIM). На момент подготовки статьи проект успешно прошел экспертизу и получил разрешение на строительство.

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

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

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

Нельзя: вторая заплатка ломает то, что починила первая.

Во времена, когда Nokia владела Qt, инженеры были отважнее. Они разработали и релизнули QMediaPlayer в Qt5Multimedia для проигрывания медиа файлов на основе подгружаемых плагинов. Архитектура позволяла сначала выпустить API, а реализацию конкретного бекенда добавить позже. Поэтому API уже существовал даже там, где полноценного воспроизведения видео ещё не было.

С учётом того, что публичный API нельзя изменить или удалить в мажорной версии, кто готов проделать такое еще раз?

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

Лоток длиной 6 м уже закреплён под потолком. Монтажники вентиляции доходят до этого участка и обнаруживают: воздуховод по проекту должен пройти через лоток. Кабелей пока нет, потолок открыт. Часть готовой работы всё равно придётся переделать.

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

WebSocket принято считать очевидным выбором, когда сервер должен постоянно отправлять клиенту свежие данные. Но что произойдёт, если вместо обычного веб-приложения у нас SCADA, а клиентов становится 1000?

Был собран тестовый стенд с OpenPLC, Modbus TCP и ASP.NET Core. Сравнивались Short Polling, Long Polling и WebSocket при 1, 10, 30, 50, 100, 500 и 1000 одновременных клиентах.

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

Wi‑SUN (Wireless Smart Ubiquitous Network) — открытый стандарт для построения масштабных субгигагерцовых mesh‑сетей. Не нашёл описание данной технологии на хабре, только пара мелких упоминаний, но мне эта штука показалась очень интересной.

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

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

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

Без таких конструкций невозможно представить современное проектирование. Поэтому для нашего примера — двухэтажного коттеджа — необходимо было смоделировать многослойные конструкции в nanoCAD BIM Строительство.

В этой статье мы детально рассмотрим многослойные конструкции стен, однако принцип моделирования таких конструкций в nanoCAD BIM Строительство универсален и применим также к другим элементам здания, например к перекрытиям.

Сам проект имеет интересную предысторию. «Коробка» дома уже была возведена на участке, но в процессе строительства возникла необходимость пристроить к дому веранду и гараж. В связи с этим принято решение смоделировать коттедж в новом продукте — nanoCAD BIM Строительство.

Здесь мы столкнулись с ограничением: в текущей версии nanoCAD BIM Строительство отсутствует прямая, «коробочная» возможность создавать многослойные стены как единую интеллектуальную конструкцию (рис. 1). Процесс моделирования сводится к последовательному построению отдельных стен, каждая из которых будет соответствовать одному слою конструкции с заданными характеристиками.