Инженерные системы *

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

Компания «Нанософт», ведущий российский разработчик САПР/ТИМ-решений, объявляет о выходе версии nanoCAD BIM Вентиляция 26, разработанной специально для российских операционных систем Astra Linux 1.7 и 1.8, Alt Linux 10 и 11, AlterOS 2025, РЕД ОС 7.3 и 8.

nanoCAD BIM Вентиляция – BIM/ТИМ-решение на Платформе nanoCAD, предназначенное для проектирования и расчета моделей систем вентиляции и кондиционирования. Основные изменения версии 26 связаны с интеграцией с многопользовательской средой Collaboration Server, автоматизацией оформления документации с помощью шаблонов проектов и обновлением моделей непосредственно из IFC-файлов.

Несколько лет назад к нам обратились с задачей, которая на нефтяном промысле стояла давно и казалась почти рутинной. Печные змеевики, в которых нагревают скважинную жидкость, прогорают регулярно и довольно неожиданно. Замена занимает время: детали приходится заказывать и ожидать их поставки, простой обходился дорого. Хотелось понимать заранее, когда же примерно ждать прогара. Спросили, не получится ли что-то придумать по тем данным, которые уже есть. Мы подумали: а вдруг действительно получится.

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

Дрон может отлично выглядеть в спецификации, но оказаться бесполезным в реальных условиях. Например, заявленного времени полёта не хватит для инспекции ЛЭП, а выбранная камера не обеспечит нужную точность измерений. Чтобы избежать таких ошибок, стоит начинать с полётного задания и требований к полезной нагрузке. Разберём, как на их основе определить характеристики платформы, учесть ограничения эксплуатации и составить техническое задание на разработку БПЛА.

Специалисты iFixit разобрали недавний 14-дюймовый Apple MacBook Pro с сенсорным экраном PROLED XDR, оценив его ремонтопригодность на 5 из 10 баллов. Apple представила эту модель в конце прошлого месяца. Устройство использует чип M5 Pro или M5 Max, а также накопитель ёмкостью до 16 ТБ.

   Итак, после разработки одноплатного компьютера на RK3568, писал тут, возникла следующая задача — создать процессорный модуль на том же SoC.
Модульная архитектура предполагает разделение устройства на две части: вычислительный модуль с процессором, оперативной памятью и необходимыми цепями питания, а так же плату‑носитель (Carrier Board), которая обеспечивает подключение периферии и внешних интерфейсов.
На первый взгляд, такое решение дает некоторое преимущество: вычислительный модуль можно заменить другим совместимым по форм‑фактору и интерфейсам и при этом не перерабатывая всю плату устройства.
А в действительности все ли так просто? Давайте разбираться!
Поскольку стояла задача сделать модуль на процессоре ARM рассматривались варианты исполнения:
-COM Express,
-SMARC,
-Qseven.
   COM Express исторически широко применялся в системах на базе Intel и AMD, имеет применение под ARM. Различные типы модулей Mini 84x55 мм, Compact 95x95 мм, Basic 125x95 мм, Extended 155x110 мм. COM Express в версии Mini, где имеет один разъем на 220 контактов ограничивает RK3568, а в исполнении Compact где используются два разъема по 220 контактов избыточен. Сам стандарт мне нравится своей строгостью.
   Qseven размер платы 70x70mm, имеет краевой разъем на 230-контактов. Он включает меньший набор доступных интерфейсов и ограниченное количество контактов по сравнению с рассматриваемыми вариантами. Для поставленной задачи с RK3568 это потребовало бы отказаться от части периферии.
  Стандарт SMARC разработан в основных версиях SMARC1.0, SMARC2.0, SMARC2.1. За основу взята версия SMARC2.1, габаритные размеры платы модуля, могут быть  в двух вариантах 82x50 мм и 82x80 мм, а для подключения имеет краевой разъем на 314 контактов.

Важный момент стандарта SMARC2.1

Компания «Нанософт» провела в Москве четвертый ежегодный форум «СИЛА ПЛАТФОРМЫ», посвященный проектированию и цифровизации в строительстве и производстве. Мероприятие состоялось 15 октября в кластере «Ломоносов» и объединило более 130 спикеров и 1450 гостей. Трансляцию форума посмотрели несколько тысяч онлайн-слушателей. Они могли участвовать в дискуссиях, оставляя комментарии и задавая вопросы в чате.

Москва, 9 ноября – ИА Нефтегаз.РУ. Ключевыми темами обсуждений стали применение искусственного интеллекта (ИИ) в работе инженеров, перенос данных на цифровые платформы, автоматизация рабочих процессов, а также использование российского ПО в отечественных проектах и перспективы его дальнейшего развития.

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

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

Кейсы нефтегазовых компаний

Информационное моделирование объектов месторождения. В секции «Строительство и девелопмент» Институт «ТатНИПИнефть» представил опыт применения технологий информационного моделирования (ТИМ) на нефтегазовых объектах.

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

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

Как перейти с планово-предупредительного ремонта на обслуживание по фактическому состоянию, когда нормативная база требует ППР, а завода-изготовителя уже нет? Сколько времени даёт система предиктивной аналитики, чтобы остановить агрегат до аварии? И почему предиктивная аналитика начинается не с алгоритма, а с того, как организованы измерения на объекте?

Эти вопросы и многие другие прозвучали на Всероссийской научно-практической конференции «Мониторинг и предиктивная аналитика состояния объектов нефтегазового комплекса», прошедшей 29 октября 2026 года в РГУ нефти и газа им. И.М. Губкина. Мероприятие прошло совместно с семинаром «Диагностика оборудования и трубопроводов компрессорных станций».

Завод считает Максима своим кадровым успехом. Его заметили еще в вузе, дали наставника, несколько лет учили за счет предприятия. Теперь он сам запускает новые детали и помогает новичкам. Только оставаться здесь он больше не хочет и уже оплатил переобучение. Он уходит не за большей зарплатой, а за понятным путем к ней. К кому на заводе идти с этим результатом? Подбор нашел хорошего кандидата, наставник научил работать, руководитель дает задачи. Каждый сделал то, за что отвечает. А за весь путь инженера, включая его желание остаться, спросить не с кого.

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

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

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

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

Привет, это Рамиль Максютов со второй частью цикла про плавки в ДСП-3. Первая часть тут: https://habr.com/ru/articles/1105616/
В этой статье на данных из первой части учим CatBoost предсказывать минимальную дозу ферромарганца для выплавки отливки из стали 35Л в дуговой сталеплавильной печи с основной футеровкой.

Компания «Нанософт», ведущий российский разработчик САПР/ТИМ‑решений, объявляет о выходе TDMS Фарватер Web версии 26.1 — технического обновления оснащенной веб‑интерфейсом системы документооборота и управления проектированием в строительстве. Обновление системы повышает безопасность и прозрачность в рамках проектных задач, позволяет работать в XML с ведомостями объемов работ и заданиями на проектирование, а также расширяет интеграционные и аналитические возможности — от отчетов из дашбордов до отправки уведомлений и документов на внешние адреса.

Если вы хоть раз отлаживали датчик давления на насосной станции или читали регистры частотника через преобразователь USB-RS485, то почти наверняка держали в руках Modbus Poll. Удобная вещь: быстрый опрос регистров, наглядные таблицы. Но это Windows-only, это платно, и это всё-таки только опросчик - без наглядных схем для удобства пусконаладки и тестирования.

Мне захотелось то же самое, но кроссплатформенное, локальное и с возможностью собрать себе маленький операторский экран: цветные аварийные строки, гейджи, окно закреплённых параметров, вычисляемые тэги. Так появился mbSCADA - open-source проект на чистом Rust с UI на Tauri 2 (в дальнейшем переедем на egui, чтобы выглядело более нативно). Проект пишется с помощью ИИ, поскольку я не прогер (каюсь), так что моих познаний в С и Python а так же в языках PLC будет недостаточно дабы кодить это собственными силами, однако я точно знаю что требуется мне от инструмента. Это clean-room реализация: мы не читали исходники Modbus Poll, но формат его конфигурационных файлов .mbp/.mbw поддерживаем byte-exact, чтобы ваши наработанные проекты импортировались без боли.

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

Зачем ещё один опросчик

В 80% бытовых задач интеграции нужен не монстр вроде полноценной SCADA, а «Modbus Poll с плюшками» - опросить десяток устройств, покрасить аварии, построить экран для оператора и выгрузить архив в CSV, который потом откроют в чём угодно.

При этом требования к инструменту жёстче, чем кажется: он должен запускаться без установки (портабельные версии удобны и неприхотливы к устройству пользователя), не лезть в сеть (никакой телеметрии и облаков — просто нет) а еще собственно полноценно поддерживать Modbus как TCP так и RTU иначе вся затея не имеет смысла. Отсюда и формат проекта: один бинарник ~6 МБ, всё локально, проект — файл рядом.

И да,проект принципиально открытый чтобы любой желающий мог пользоваться и при желании вносить свой вклад, лицензия - MIT. Собирается одним cargo build либо устанавливается через установщик / открывается AppImage.

Совместимость с Modbus Poll: byte-exact импорт

Поскольку на моем месте работы накопился большой багаж файлов Modbus Poll, то во избежании переписывания всего этого добра - работа с «родными» файлами Modbus Poll стала обязательным требованием. В репозитории живёт отдельный крейт mb-format, который парсит .mbp и .mbw и умеет обратную операцию: write(parse(bytes)) == bytes. Это свойство покрыто тестами и проверено на реальных файлах от Modbus Poll 10.5 — раундтрип байт в байт совпадает с оригиналом.

Сохранённые mbSCADA-проекты остаются совместимыми с оригиналом — можно готовить конфигурацию на ноутбуке с Linux, а отдавать коллегам, которые продолжают жить в Modbus Poll.

Опросы читаются все штатные: 01/02/03/04 (coil/discrete/input/holding), записи 05/06/0F/10. Поддержаны разрядности и порядки слов - включая u16_swapped (перестановка слов в 32-битных значениях)

Заменит ли ИИ разводчиков печатных плат? После презентации GPT-6 Astra в профильных чатах не проходит и дня без спора. Я посмотрел, что на самом деле показали, что получилось у тех, кто повторил тест, и какие аргументы чаще всего звучат: библиотеки компонентов, DRC, топология, настройки проекта. Отдельно разобрал плату Quilter и свой опыт с ИИ‑автоматизацией.

Что стоит за «98% соединений» и «неделей вместо квартала»? Почему завод вернул плату с 58 замечаниями? И кому ИИ поможет больше: стартапу из трёх человек или опытному специалисту? Читайте и спорьте в комментариях.

Изучите принципы проектирования железобетонных конструкций на практике. С помощью пошагового тест-драйва вы пройдете полный цикл работы в nanoCAD Конструкции PS: от создания геометрии и армирования до оформления чертежей раздела КЖ.

Кому это будет полезно?

1. Всем, кто работает с nanoCAD Конструкции PS или еще только изучает программу, – быстрое освоение функционала и решение практических задач.

2. Инженерам-конструкторам – выполнение армирования и выпуск чертежей раздела КЖ в одной программе.

3. Руководителям проектных отделов – ускорение подготовки комплекта чертежей марки КЖ.

4. Студентам – готовый пример для курсовой и понятный вход в освоение программы.

Привет, Хабр! Эта история началась с того, что меня позвали пообщаться на тему работы в металлургическую компанию. Спросили коротко: «Готов?». Я оценил свои силы, масштаб задачи и ответил прямо — готов зайти сразу на позицию Head of AI, чтобы выстроить процесс от и до.

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

Спойлер: красивого хэппи-энда не будет. Моё MVP до высшего руководства так и не донесли, а меня в итоге просто развернули на пороге. Но не пропадать же добру? Проект получился слишком интересным, чтобы просто похоронить его на жестком диске.

Эта статья посвящена исключительно генератору. Мы разберем, как он устроен «под капотом», какие неочевидные ошибки я в нем допустил, и как проверить, что синтетика не врет сама себе. Обучение CatBoost и создание работающего микросервиса-советника мы оставим для второй части.

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

Оглавление

Как объединить три промышленных котла Viessmann в единую систему мониторинга и управления, заменив часть штатной автоматики на отечественное оборудование? На примере реального проекта показываем модернизацию котельной: интеграцию контроллера ОВЕН КТР-121, преобразование протоколов LonWorks и Modbus через LM-Gate, настройку панели оператора СП-307 и передачу данных в OwenCloud с уведомлениями об авариях через Telegram.

Ключевая ошибка в ожиданиях неискушённых пользователей от LLM состоит в непонимании того, как именно получается ответ.

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

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

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

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

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

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