Анализ САУ гребной дизель-электрической установки

В данной статье рассмотрена модель корабельного привода который состоит из дизельной установки, генератора и электродвигателя вращающего винт, модель построена с помощью Engee

Высокоуровневый высокопроизводительный язык

В данной статье рассмотрена модель корабельного привода который состоит из дизельной установки, генератора и электродвигателя вращающего винт, модель построена с помощью Engee

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

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

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

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

Представьте: пациент приходит на приём. Врач выслушивает жалобы и назначает обследование. Температура, общий анализ крови, рентген грудной клетки, УЗИ, мазок из горла – стандартная карточка. Часть из этого действительно нужна. Часть – назначается по привычке, «чтобы не пропустить».
Теперь вопрос: можно ли математически доказать какие симптомы несут реальную информацию о диагнозе, а какие – просто "шум"? Можно ли взять таблицу пациентов и получить на выходе точный ответ – вот эти три признака обязательны, этот четвёртый заменяем, а пятый почти бесполезен?
Оказывается, можно. И для этого не нужны нейросети, градиентный бустинг или сотни тысяч записей. Достаточно бинарной матрицы, красивой идеи из теории множеств и нескольких строк кода.
Сразу сделаю честную оговорку: я не врач и не претендую на медицинскую точность. Таблица пациентов в этой статье составлена по общедоступным представлениям из интернета – какие симптомы обычно сопровождают грипп, бронхит, пневмонию. Настоящие врачи составят такую матрицу куда точнее – на основе реальной клинической практики, статистики, протоколов. Моя цель другая: показать как математика может помочь врачу структурировать знания и найти в них закономерности. Не заменить клиническое мышление – а дать ему инструмент.
Медицина здесь – удобный и понятный пример. Тот же подход работает в промышленной диагностике, в анализе анкет, в задачах отбора признаков для машинного обучения, в системах поддержки принятия решений. Математика универсальна – меняется только предметная область.
В этой статье мы возьмём таблицу из 12 пациентов и 7 симптомов, переберём все возможные комбинации признаков, найдём те наборы которые позволяют однозначно поставить диагноз – и посчитаем вектор значимости каждого симптома. Реализацию сделаем в среде Engee на языке Julia.

В данной статье будем реализовывать оптимальный фильтр Калмана с помощью среды моделирования Engee.
Структура навигационной системы будет представлять собой комбинацию бесплатформенной навигационной системы + спутниковой навигационной системы (СНС).

Солнечные панели до сих пор вызывают скептицизм, и во многом этот скептицизм оправдан: КПД современных фотоэлектрических модулей редко превышает 17–25 %, а это означает, что большая часть солнечного излучения, падающего на поверхность панели, просто рассеивается в виде тепла, не превращаясь в электроэнергию. Если добавить к этому потери в инверторе, соединительных кабелях и аккумуляторах, реальная эффективность всей системы оказывается ещё скромнее – и скептики получают очередной повод для сомнений.
Одним из наиболее распространённых инструментов борьбы с этими потерями стали MPPT-контроллеры, которые в реальном времени отслеживают точку максимальной мощности на вольт-амперной характеристике панели и удерживают режим работы вблизи неё вне зависимости от температуры, облачности и уровня освещённости. Это действительно работает – но лишь до тех пор, пока панель хоть как-то освещена, потому что никакой алгоритм не способен извлечь энергию из излучения, которое на панель просто не попадает. Если в девять утра панель жёстко закреплена под углом на юг, а Солнце ещё висит низко на востоке, MPPT-контроллер честно выжмет максимум из скудного косого света – но этот максимум будет несопоставимо меньше того, что могла бы дать панель, повёрнутая прямо на Солнце.
Именно здесь появляется идея солнечного трекера – механической системы, которая поворачивает панель вслед за Солнцем на протяжении всего светового дня, удерживая угол падения излучения близким к перпендикулярному. Идея выглядит логично, однако инженерный подход требует большего, чем просто красивая концепция: трекер – это механика, приводы, датчики, система управления, и всё это означает дополнительную стоимость, обслуживание и новые точки отказа. Поэтому прежде чем браться за проектирование, необходимо ответить на вполне конкретный вопрос – насколько велик выигрыш в энергии и оправдывает ли он усложнение системы?

Представьте: 80-я минута, счёт 1:1. Нападающий соперника получает мяч на фланге и уходит в рывок вдоль бровки. Защитник бежит рядом, чуть левее — между нападающим и центром поля. Где-то в центре полузащитник соперника уже прицеливается для прострела.
И в этот момент защитник должен принять решение — молниеносно, без калькулятора, без времени на раздумья: я контролирую ситуацию или мне нужна помощь партнёра?
Опытный защитник решает это интуитивно. Но что именно стоит за этой интуицией? Оказывается — вполне конкретная математика. Причём такая, которую проходят в школе.
У защитника есть зона контроля — сектор пространства, в котором он способен среагировать на действия нападающего. Её размер определяется тремя физическими факторами: временем реакции, скоростью бега и углом периферийного зрения. Пока нападающий находится внутри этого сектора — защитник держит ситуацию под контролем. Как только нападающий выходит за его границу — контроль потерян, нужна подстраховка.
Задача, которую мы разберём в этой статье, даёт конкретный ответ на конкретный вопрос: окажется ли нападающий в зоне контроля защитника в момент приёма паса — и когда защитнику нужно звать партнёра?
Для решения не понадобится ничего сверхъестественного: уравнения прямых, расстояние между точками, три геометрических условия. Весь необходимый аппарат вы уже проходили — просто, возможно, не думали, что он помогает принимать решения на футбольном поле.
В конце статьи мы реализуем модель в среде Engee на языке Julia — с визуализацией зоны контроля в начальный момент и через время t1.

Беспилотные летательные аппараты – конвертопланы способны осуществлять вертикальный взлет, а также посадку в вертолетном режиме и полет в самолетном режиме с использованием управления ориентацией и величинами тяг двигателей. В рамках данной статьи будет проводиться моделирование движения БПЛА квадрокоптерного типа с возможностью поворота двигателей на опорах. Двигатели поворачиваются синхронно на угол ε. Моделирование будем проводить с использованием структурных схем engee. Модель можно посмотреть на официальном сайте.
Можно перечислить следующие преимущества данной схемы БПЛА по сравнению с классической жесткой схемой квадрокоптера:
· Радиус действия — благодаря возможности наклона двигателей, такой БПЛА способен двигаться со значительными горизонтальными скоростями с более низким коэффициентом лобового сопротивления (по сравнению к классическим квадрокоптером) и тем самым сильно увеличивается радиус действия. Для возможности горизонтального полета на высоких скоростях БПЛА содержит поверхности которые способный создавать подъёмную силу (на рисунке 1 данные поверхности присутствуют на штангах крепления двигателей).
· Высокая скорость и маневренность — так как двигатели могут поворачиваться на угол от 0 до то у данного БПЛА увеличивается запас устойчивости при наборе скорости и при воздействии ветра. Также высокая маневренность обеспечивается наличием четырёх управляющих закрылков с помощью которых в зависимости от алгоритма управления можно менять как угловое так и пространственное положение конвертоплана (например наклонив синхронно на малый угол все закрылки поменять высоту)

В данной статье приведен один из возможных вариантов математического обеспечения для исследования динамики неуправляемого движения спускаемых аппаратов, созданное наоснове обобщения опыта проектирования, отработки и эксплуатации аппаратов типа «Венера» и «Марс» второго и третьего поколений. Приводятся обобщенные данные, характеризующие динамику спуска в атмосферах планет типа «Венера 9-16», «Вега-1,2» и «Марс-3,6». При данном моделирования рассматривается процесс посадки на Венеру и заданы параметры её атмосферы.

В данной статье расскажу про связь конструкции электро-механической измерительной головки и механического компенсационного акселерометра.
Скрипты и модель для данной статьи можно посмотреть на сайте engee (https://engee.com/community/ru/catalogs/projects/model-mekhanicheskogo-akselerometra)
С первого взгляда данные датчики совсем не похожи, как и измеряемые ими величины. Но при этом амперметр конвертирует силу тока в движение стрелки, а акселерометр преобразует ускорение при линейном движении в ток. Если в измерительной головке утяжелить стрелку (для увеличения момента инерции относительно оси вращения) то при линейном ускорении с контактов амперметра можно снимать ток который будет пропорционален линейному ускорению которому подверглась измерительная головка.

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

Эта статья — подробный разбор того, как мы смоделировали современный стандарт профессиональной цифровой радиосвязи Digital Mobile Radio (DMR) на отечественной инженерной платформе Engee.
Digital Mobile Radio (DMR) — это не просто «цифровая рация». Это международный открытый стандарт, который за счёт использования двухслотового TDMA позволяет удвоить ёмкость канала по сравнению с аналоговыми системами, сохраняя ту же полосу частот (12.5 кГц). DMR поддерживает не только голос, но и передачу данных, текстовых сообщений, GPS и обеспечивает надёжную, энергоэффективную связь для промышленности, служб быстрого реагирования и бизнеса.
Если вы хотите заглянуть «под капот» цифровой радиосвязи и понять, как отечественный инструмент позволяет решать сложные задачи верификации протоколов, добро пожаловать!

Привет, Хабр!
Сегодня говорим про мониторинг жизненно важных показателей (ЖВП) человека. ЖВП — это метрики, по которым можно понять, всё ли в порядке с нашим организмом: температура тела, давление, дыхание, ну и наш сегодняшний герой — пульс.
Когда речь заходит о мониторинге сердечной активности, первое, что приходит в голову — это ЭКГ. Электрокардиография уже давно считается золотым стандартом в медицине. Однако при всех её достоинствах у ЭКГ хватает минусов: запись короткая, провода и датчики сковывают движения, есть риск раздражения и даже заражения при повреждении кожи, да и ощущения от процедуры так себе — в целом комфорт сомнительный.

Привет, Хабр! В предыдущей части мы рассматривали базовые методы цифровой обработки изображений для задачи сегментации спутникового снимка.
В этой статье рассмотрим ещё парочку методов решения этой задачи, всё ещё «классических», то есть без применения машинного обучения или нейросетей. Помогут нам во всём разобраться, как и в прошлый раз, язык программирования Julia и среда технических расчётов Engee!

Привет, Хабр!
При разработке технических систем часто приходится описывать управляющую логику, зависящую от множества факторов: времени, событий, текущего состояния устройства и действий пользователя. Например, кофемашина может переключаться между режимами ожидания, приготовления напитка и очистки, а квадрокоптер – переходить в режим посадки при низком уровне заряда или в аварийный при неисправности.
Со временем логика системы начинает разрастаться: появляются дополнительные режимы работы, усложняются условия переходов между ними, возникает необходимость корректно реагировать на ошибки. В какой-то момент код превращается в клубок из вложенных if-else, флагов, и переменных, описывающих состояние системы, что не только затрудняет её поддержку и расширение, но и снижает надёжность.
Одним из решений этой проблемы может стать подход на основе конечных автоматов. В этой статье я покажу, как можно разработать управляющую логику фитнес-браслета с использованием удобного инструмента визуального проектирования и при этом не дать ей выйти из-под контроля.

Что такое цифровая обработка изображений? Зачем нам вообще знать про алгоритмы обработки, когда есть фотошоп и фильтры в телефоне? Или всё можно отдать нейросети и получить крутой результат? И при чём тут Julia, наконец? Будем разбираться!
Мы запускаем серию статей про обработку изображений с использованием языка Julia и вычислительной среды Engee. Задача – ответить на часто встречающиеся вопросы вроде актуальности этого направления компьютерной науки, задач, решаемых методами обработки изображений, применения и реализации стандартных и «умных» алгоритмов.
В первой части ознакомимся с основами на примере сегментации спутникового снимка.

Статья-шпаргалка о типах данных в Julia: от примитивных, до параметрических абстрактных. Рассказывается, почему range умеет работать как массив, почему Vector{Int64} не является подтипом Vector{Real}, но является подтипом Vector{<:Real}, чем отличается неизменяемая структура от изменяемой структуры с неизменяемыми полями

Как загрузить GPU инженерными вычислениями? Давайте я расскажу, как с помощью Julia наконец смог втащить высокопроизводительные вычисления в свою немудрёную инженерную работу. Это был долгий путь, но мне кажется, что Julia стала моим лучшим другом в мире GPU/HPC.