Лекции по курсу «Управление Техническими Системами» читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность!

Данные лекции готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется.

В предыдущих сериях:
1. Введение в теорию автоматического управления.
2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13

В следущих сериях:
3.2. Типовые звенья систем автоматического управления (регулирования). Классификация типовых звеньев. Простейшие типовые звенья.
3.3. Апериодическое звено 1–го порядка (инерционное звено). На примере входной камеры ядерного реактора.
3.4. Апериодическое звено 2-го порядка.
3.5. Колебательное звено.
3.6. Инерционно-дифференцирующее звено.
3.7. Форсирующее звено.
3.8. Инерционно-интегрирующее (звено интегрирующее звено с замедлением).

В этом разделе мы будем изучать частотные характеристики. Тема сегодняшней статьи:
3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ

Будет интересно, познавательно и жестко.

Продолжение статьи "Введение в моделирование динамики квадро-, гекса- и октокоптеров".

В этой части автор Александр Щекатуров, рассказывает основные принципы создания системы управления и ее моделирования в структурном виде. Всем кто одолел первые части лекций по теории управления в технических система, все будет ясно и понятно (ну почти). Лекции на хабре лежат по ссылкам:

1. Введение в теорию автоматического управления.
2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13

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

Лекции по курсу «Управление Техническими Системами», читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки», факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.

Данные лекции только готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется.

В предыдущих сериях:

1. Введение в теорию автоматического управления
2. Математическое описание систем автоматического управления 2.1 — 2.3
3. Математическое описание систем автоматического управления 2.3 — 2.8

В это части будут рассмотрены:

2.9. Использование обратных преобразований Лапласа для решения уравнений динамики САР (звена).
2.10. Весовая и переходная функции звена (системы).
2.11. Определение переходного процесса в системе (САР) (звене) через весовую и переходную функции.
2.12. Mетод переменных состояния.
2.13. Переход от описания переменных «вход-выход» к переменным состояния.

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

Что бы разбавить зубодробительную математику лекций Козлова Олега Степановича "Управление в технических системах", публикуем здесь пример применения знаний из этих лекций на практике.

В данной статье, Александр Щекатуров, ученик Олега Степановича описывает создание модели октокоптера, попутно раскрывая секреты и демонстрируя приемы работы в среде структурного моделирования физических систем.

В настоящей статье приведено описание логически завершённой, но всего лишь части полной работы по моделированию, но этой части достаточно для введения в тему динамического моделирования БПЛА коптерного типа.

Здесь опущено моделирование эффектов прецессии, принимается что и реактивный момент каждой ВМГ равен нулю, а именно: каждая ВМГ имеет два двигателя и винта, вращающихся с одинаковой скоростью в противоположные стороны. Не моделируются отказы оборудования и предполагается что объект находится только в воздухе (в штатном режиме полёта), режимы посадки и взлёта, аварийные ситуации, захват груза и разгрузка — в приведённой модели не реализованы, а также не рассматриваются вопросы подробного моделирования датчиков, фильтрации сигналов и шумов, изгиб рамы коптера и/или винтов, работа на запредельных нагрузках, написание драйверов к той или иной аппаратуре и т.д. и т.п., — всё это темы более расширенной статьи или даже книги.

Лекции по курсу «Управление Техническими Системами», читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки», факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.

Данные лекции только готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется.

В предыдущих сериях:
1. Введение в теорию автоматического управления
2. Математическое описание систем автоматического управления 2.1 — 2.3

В это части будут рассмотрены:
2.4 Основные виды входных воздействий
2.5. Основные положения и свойства интегральных преобразований Лапласа
2.6. Основные свойства преобразований Лапласа
2.7. Способы нахождения обратных преобразований Лапласа
2.8 Некоторые способы нахождения оригинала по известному изображению

Будет интересно познавательно и жестко.

На рисунке 3D график функции косеканс куба, к теме лекции отношения не имеет, но чертовски красив.

Продолжение цикла статей про модельно ориентированное проектирование. В предыдущих сериях:

• Модельно-ориентированное проектирование – как не повторить Чернобыль
• Модельно ориентированное проектирование. Электропривод с бесколлекторным двигателем постоянного тока
• Модельно ориентированное проектирование. Создание достоверной модели, на примере авиационного теплообменника
• Блеск и нищета модельно ориентированного проектирования по авиационным стандартам DO-331

В этой серии, авторы Ю. Н. Калачев и А.Г. Александров, представляют математическую модель активного выпрямителя в среде структурного моделирования.

Публикую первую часть второй главы лекций по теории автоматического управления.
В данной статье рассматриваются:

2.1. Получение уравнений динамики системы. Статическая характеристика. Уравнение динамики САУ (САР) в отклонениях
2.2. Линеаризация уравнений динамики САУ (САР)
2.3. Классический способ решения уравнений динамики

Лекции по курсу «Управление Техническими Системами», читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки», факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.

Данные лекции только готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется.

Первая часть: «Введение в теорию автоматического управления. Основные понятия теории управления техническим системами»

В комментариях к предыдущему тексту «Введение в теорию автоматического управления», один из читателей усомнился в необходимости изучать этот предмет и задал вопрос:
— Кто такая ТАУ – человек или лошадь? И зачем она нужна?

Такой принципиальный вопрос не может остаться без ответа принципиального ответа.

Прежде чем переходить от введения в ТАУ к зубодробительной математике, покажем на примере, что может ТАУ в очумелых руках специалиста. Спойлер: ТАУ может все!

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

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

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

Лекции по курсу «Управление Техническими Системами», читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки», факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.

Данные лекции только готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика привествуется.

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

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

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

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

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

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

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

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

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

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

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

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

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



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

«Если на клетке слона прочтёшь надпись «буйвол», не верь глазам своим» Козьма Прутков

В предыдущей статье о модельно-ориентированном проектировании было показано, зачем нужна модель объекта, и доказано, что без этой модели объекта про model based design можно говорить только как о маркетинговой пурге, бессмысленной и беспощадной. Но при появлении модели объекта у грамотных инженеров всегда возникает резонный вопрос: какие есть доказательства, что математическая модель объекта соответствует реальном объекту.

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

В предыдущей статье про модельно ориентированное проектирование было показано, что не все методики одинаково полезны. И объясняется как делать правильно, что бы не было потом мучительно больно. Но в конце статье был поставлен вопрос, провокационный как Шарон Стоун на допросе у следователей: модельно ориентированное проектирование это конечно хорошо, но как доказать, что модель соответствует объекту? Какие ваши доказательства?


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

Далее под катом
Калачев Ю. Н., Ланцев В.Ю., Окулов Е.В.
Электропривод с бесколлекторным двигателем постоянного тока
(практика применения моделирования и кодогенерации в АО «Аэроэлектромаш»)

В продолжение темы ООП в графических языках программирования разберемся более подробно с model-based design. Что такое модельно-ориентированное проектирование (МОП), как его правильно готовить и с чем его едят.

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

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

В первой части я попытался показать, что черная кошка ООП в темной комнате графических языков существует, даже если это не кошка, а полудохлый кот живодера Шредингера, который то есть, то его нет. Был показан пример реализации методологии объектно-ориентированного программирования, когда программа – это не код на языке С++ или Java, а диаграмма Simulink, SimInTech, SimulationX или SCADE Esterel, — любая графическая нотация описания алгоритма.

В рекламных материалах Мatlab Simulink часто используют термин МОП — Модельно Ориентированное Проектирование (Model-based design). Во многих текстах они подчёркивают, что графическая схема алгоритма это модель, что, конечно, верно. Однако в первоначальном определении МОП, модель – это прежде всего модель объекта, к которому разрабатывают систему управления, включая управляющее программное обеспечение. Подробнее методолгия МОП описана здесь. Таким образом, разрабатывая систему управления по методологии МОП можно и нужно использовать методологию ООП для разработки управляющего ПО. И что бы окончательно закрыть вопрос с моделями, вот вам картинка с отличиями одного от другого. Если все понятно, то можно дальше не читать.

Объектно-ориентированное программирование (ООП) – концепция, которая призвана облегчить разработку сложных систем, за счет введения новых понятий, более приближенных к реальному миру, чем функциональные и процедурные языки программирования. Как пишет википедия, «Обычный человеческий язык в целом отражает идеологию ООП, начиная с инкапсуляции представления о предмете в виде его имени и заканчивая полиморфизмом использования слова в переносном смысле, что в итоге развивает выражение представления через имя предмета до полноценного понятия – класса.»

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