Matlab *

В первых двух частях туториала мы рассматривали построение архитектуры системы и проектирование на системном уровне и заодно посмотрели на System Composer. Сама по себе архитектура системы — это отлично, но надо сделать так, чтобы она была связана с разработанной системой. Отсутствие такой связи в традиционных инструментах использующих SysML или UML, кстати, и послужила причиной создания System Composer. Дело в том, что многие компании уже используют для разработки парадигму модельно-ориентированного проектирования (МОП), и им приходилось использовать сторонние инструменты для системной инженерии, что было неудобно. System Composer был создан, чтобы устранить этот разрыв. В этой заключительной части туториала я покажу, как использовать System Composer совместно с тулчейном MathWorks для модельно-ориентированного проектирования.

В данной публикации представлена транскрипция вебинара «Разработка электрической сети самолета с использованием модельно-ориентированного проектирования». Вебинар проводил Михаил Песельник, инженер ЦИТМ Экспонента.)

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

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

Этот текст является продолжением предыдущих публикаций:

1. Простой регулятор на базе нечеткой логики. Создание и настройка.
2. Нечеткая логика в красивых картинках. Поверхности отклика для разных функций принадлежности.
3. Создание регулятора на базе нечеткой логики с многоканальной настройкой.
4. Простая нечеткая логика слеплена «из того что было» для газотурбинного двигателя.
5. Нечеткая логика против ПИД. Скрещиваем ежа и ужа. Авиадвигатель и алгоритмы управления АЭС.

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

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

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

Далее под катом – ПИД-регулятор, нечёткая логика и конечные автоматы для управления газотурбинным двухроторным двигателем (ГТД). Тем, кто впервые планирует познакомиться с работой нечеткой логики, рекомендую начать со статьи «Простой регулятор на базе нечеткой логики. Создание и настройка»

Аннотация, или о досуге молодых ученых

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

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


На рисунке выше приведено общее число подтвержденных случаев COVID-19 в логарифмическом масштабе для России и трех европейских стран, входящих в топ-5 по числу зараженных. Объяснение далее в тексте.

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

Продолжаем изучать нечеткую логику вместе с книгой Гостева В.И. «Нечеткие регуляторы в системах автоматического управления».

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

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

Как оказалось, это затягивающее занятие (построение поверхности отклика) доставляет не просто эстетическое удовольствие, а еще раз доказывает на практике известное философское утверждение «красота спасет мир».

Поэтому разбор очередной задачи из книги Гостева В.И. у меня распался на две части:

1. Анализ влияния параметров функции принадлежности для фазификации входных переменных на работу регулятора на базе нечеткой логики.
2. Непосредственное решение задачи.

Далее, под катом, первая часть.
Внимание! Для тех, кто впервые касается темы нечеткого регулирования, рекомендую начать вот с этой статьи: Простой регулятор на базе нечеткой логики. Создание и настройка

Всем привет. Я часто применяю в своей работе принципы системной инженерии и хотел бы поделиться этим подходом с сообществом.

Системная инженерия – без стандартов, а по-простому, это процесс разработки системы как достаточно абстрактных компонентов, без привязки к конкретным образцам устройств. В ходе данного процесса устанавливаются свойства компонентов системы и связи между ними. Дополнительно требуется сделать систему непротиворечивой и оптимальной, а также соответствующей требованиям. В этом туториале я покажу приемы системной инженерии на примере проектирования достаточно простой системы контроля доступа (СКУД).

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



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

Далее под катом:

Рассматриваются проблемы обеспечения точности расчета и скорости вычислений при создании достоверной математической модели реальной технической системы методами структурного моделирования для цифровых двойников. Описывается опыт создания достоверной модели стенда системы кондиционирования воздуха (СКВ). Даются примеры методик достижения необходимой точности модели для разных типов агрегатов системы.

В предыдущих статьях про модельно-ориентированное проектирование Как не повторить Чернобыль, Электропривод с бесколлекторным двигателем постоянного тока, и Создание достоверной модели, на примере авиационного теплообменника, я показал на примерах, что не все методики модельно-ориентированного проектирования (МОП) одинаково полезны.

Начиная свою инженерную деятельность в атомной отрасли, я привык, что первым этапом проектирования является создание модели объекта. Модель объекта в атомной отрасли, является обязательной частью проекта. Средства моделирования для АЭС проходят аттестацию, где экспертиза определяет их применимость для расчетного моделирования процессов АЭС. И если есть модель объекта, то модель системы управления естественно разрабатывается совместно в виде комплексной модели. Именно это и является в моем представление методом модельно-ориентированного проектирования.

По моему мнению, моделирование одной только системы управления без создания модели объекта является ущербным. Поэтому, когда вы слушаете рассказы поставщиков моделирующего софта для разработки ПО, необходимо понимать о чем идет речь: о новых передовых методиках разработки систем или о модельно-ориентированном проектировании в понимании авиационного стандарта DO-331.

Нужно помнить, что МОП в авиационных стандартах отражает устаревший и консервативный подход к модельно-ориентированной разработке ПО. И в этом подходе, даже если ваша модель – это только набор UML диаграмм, где собраны требования к ПО, это все равно будет модельно-ориентированное проектирования в терминах DO-331.

Предлагаю перевод статьи «DO-331 Model based development for engineer and manager», публикуемый мной с любезного разрешения автора Vance Hilderman (vance.hilderman@afuzion.com) Vance Hilderman www.afuzion.com

Данный текст позволит сориентироваться в основных положениях стандарта DO-331, терминах и понятиях, которые в нем используются.

Продолжая тему «Какие ваши доказательства?», посмотрим на проблему математического моделирования с другой стороны. После того как мы убедились, что модель соответствует сермяжной правде жизни, можно отвечать на основной вопрос: «а что, собственно, мы тут имеем?». Создавая модель технического объекта, мы, как правило, хотим убедиться, что этот объект будет соответствовать нашим ожиданиям. Для этого и проводятся динамические расчёты процессов и результат сравнивается с требованиями. Это и есть цифровой двойник, виртуальный прототип и прочее. модные шняги, которые на стадии проектирования решают задачу, как сделать так, чтобы мы получили то, что планировали.

Как же нам быстро убедится что наша система это именно то что мы проектируем, полетит ли или поплывет ли, наша конструкция? А если полетит то как высоко? А если поплывет, то как глубоко?

1. Введение. Конкурентный корутинизм

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

Стандарт С++ включил в свой состав долгожданную поддержку многопоточности [1]. Но не будем ни восхищаться этим, ни критиковать сей факт, т.к. работа с потоками отягощена таким множеством условий, оговорок и особенностей, что без реальных примеров, выявляющих проблемы многопоточности, обсуждение многопоточного программирования будет не только поспешным, но и достаточно предвзятым. Поэтому далее в основном не о потоках, а об автоматах, имея в виду, конечно, и первые.

Приветствую вас, глубокоуважаемые!

«… истинное место судна хотя и неизвестно, но оно не случайно, оно есть, но неизвестно в какой точке» Алексишин В. Г. и др. Практическое судовождение, 2006. стр. 71

«С двух краев галактики вышли пешеходы...» (С) Сергей Попов (Астрофизик)

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

• расстояние между двумя географическими точками
• определение точки по известной, расстоянию до нее и азимутальному углу
• определение положения точки по измеренным дальностям до известных точек (TOA, TOF)
• определение положения точки по измеренным временам прихода сигнала (TDOA)

Все это на C#, Rust и Matlab, на сфере и эллипсоидах, с картинками, графиками, исходным кодом — под катом.

А это, релевантная КДПВ:

1. Введение

Услышав из авторитетных уст, что «автоматы — вещь событийная» [3], понял, что конечные автоматы заклеймили окончательно. Судите сами: в библиотеке Qt реализована событийная модель автоматов [1], в UML — они же [2], смотрим на автоматы пакета расширений Simulink-Stateflow системы MATLAB [4] (далее просто Stateflow) и там о событиях и т.д. и т.д. В таком контексте утверждение д.т.н. А.А. Шалыто трактовать по-другому сложно, т.к. ничего иного уже не может быть, потому что быть не может.

Но, если вспомнить теорию конечных автоматов (ТКА), то в ней о событийных автоматах нет ни слова! Но чтобы противоречить теории нужны веские аргументы. А есть ли основания сомневаться в профессионализме Д. Харелла, как создателя нотации, на которой базирует свои идеи язык UML, пакет Stateflow, которые в свою очередь небезызвестны А.А. Шалыто? Ведь, UML, Stateflow, SWITCH-программирование и иные варианты автоматного программирования существуют и в той или иной мере успешно работают.

Так можно ли снять «клеймо событийности» с модели конечных автоматов, отделив «котлеты от мух»? Т.е. разделить теорию автоматов и вычислительные модели, подобные модели Д.Харела. И считать, что последние, хотя и используют терминологию теории автоматов, представляют, судя по их реализации, развитие модели блок-схем программ.

Я использовал MATLAB более 25 лет. (А до этого я даже использовал MATRIXx, земля ему пухом.) Это не первый язык, на котором я научился программировать, но это тот язык, с которым я достиг математического совершеннолетия. Знание MATLAB было полезным для моей карьеры.

Тем не менее, невозможно игнорировать рост Python в научных вычислениях. MathWorks должен чувствовать то же самое: они не только добавили возможность вызывать Python напрямую из MATLAB, но и заимствовали некоторые его языковые функции, такие как более агрессивную передачу для компонентов бинарных операторов.

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

В 2000 году профессор Пармского университета Анджело Фарина предложил оригинальный метод одновременного измерения импульсной характеристики и нелинейных искажений с помощью гармонического сигнала экспоненциально изменяющейся частоты (далее ESS – exponential sine sweep).

Для получения этих характеристик необходимо записать воздействие ESS-сигнала на испытуемое устройство и найти взаимную корреляционную функцию записанного сигнала с исходным ESS-сигналом, но промодулированным по амплитуде (подробнее об этом можно узнать в публикациях А.Фарина).

Важной практической задачей является использование Matlab/Simulink с реальной аппаратурой которая позволит принять сигнал из реального мира. Это очень полезно для отладки алгоритмов. В данной работе представлена технология подключения к Simulink устройств АЦП производства АО «ИнСис». Для подключения используется DLL, которая видна в Simulink как компонент sm_adc. Для работы с аппаратурой используется отдельная консольная программа. Связь с DLL производится через разделяемую память. По данной технологии могут быть подключены любые АЦП на любых несущих модулях АО «ИнСис». В работе представлена система из генератора A7_DAC и модуля сбора FMC128E/FM412x500M.

Данная работа демонстрировалась на конференции «Технологии разработки и отладки сложных технических систем» 27-28 марта 2018 года.

При обсуждении предыдущей статьи про модельно-ориентированное проектирование возник резонный вопрос: если мы используем данные эксперимента, а можно ли поступить еще проще, засунуть данные в System Identification и получить модель объекта, не заморачиваясь с физикой вообще? Не изучая всякие многоэтажные формулы Навье-Стокса, Бернулли и прочих Штангель циркулей с Рабиновичами? Испытали объект – получили результат.



Мы же представляли модель ракеты ФАУ2 в виде одной передаточной функции, можно посмотреть здесь… И, вроде, все работало. Зачем же нам нужно сначала изучать математический анализ и дифференциальные исчисления, когда есть волшебная кнопка, получающая модель из испытаний?

Привет!

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

Те, кто работает с данными, отлично знают, что не в нейросетке счастье — а в том, как правильно обработать данные. Но чтобы их обработать, необходимо сначала проанализировать корреляции, выбрать нужные данные, выкинуть ненужные и так далее. Для подобных целей часто используется визуализация с помощью библиотеки matplotlib.



Встретимся «внутри»!

Привет!

Тут мы опишем работу некоторого поля а затем сделаем пару красивых фичей (тут все ОЧЕНЬ просто).



Что будет в этой статье.

Общий случай:

1. Опишем базу, а именно работу с векторами (велосипед для тех, у кого нет под рукой numpy)
2. Опишем материальную точку и поле взаимодействия

Частный случай (на основе общего):

1. Сделаем визуализацию векторного поля напряженности электромагнитного поля (первая и третья картинки)
   
2. Сделаем визуализацию движения частиц в электромагнитном поле
   

Встретимся под катом!