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

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

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

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

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

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, терминах и понятиях, которые в нем используются.

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

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

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

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

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

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

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

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

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

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

В предыдущей статье "Скрещивание ужа и ежа.." мы проверяли применимость методов настройки систем автоматического управления к «реальным» моделям. В это статье попробуем оптимизировать не систему управления, а сам «физический» объект.

Для настройки регуляторов существует большое количество средств, методик и обеспечивающих оптимизацию законов регулирования. Если мы используем средства моделирования (типа Matlab Simulink), то можно сразу посмотреть на процесс оптимального управления непосредственно «вживую», на графиках. Возникает вопрос, если у нас есть метод для оптимизации параметров системы управления, можно ли оптимизировать не коэффициенты ПИД регулятора, а сам объект управления? Другими словами, не подбирать регуляторы для явно неудачной системы, а подобрать параметры самой системы. Ведь для компьютерной модели что коэффициенты ПИД, что размеры конструкции – это просто переменные, которые можно менять.

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

В этой статье мы будем экспериментировать с «настоящей» моделью авиационного двигателя. Обвесив ее «реальными» моделями аппаратуры и алгоритмов управления от атомной станции.

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

В этой статье мы создадим модель регулятора на базе стандартной библиотеки структурного моделирования (без использования готовой библиотеки блоков нечёткого регулирования).
В качестве объекта управления будет использована модель газотурбинного двигателя из учебника В.И. Гостева «Нечеткие регуляторы в системах автоматического управления»
Выполним сравнение с ПИД и ПДД регуляторами.

Нечеткая логика для управления

Текст подготовлен на основе материалов книги Гостева В.В. «Нечеткие регуляторы в системах автоматического моделирования». Как все серьезные публикации по теме, данная книга перегружена математическими выкладками и тяжела для неподготовленного читателя. Между тем, сами по себе принципы создания и использования нечеткой логики достаточно просты и наглядны. Данный текст – попытка перевести пример из книги с математического языка на инженерный.
Показана возможную последовательность проектирования регулятора на базе нечеткой логики, путем последовательного усложнения логических правил и подбором параметров методами оптимизации.

Постановка задачи

Рассмотрим синтез цифрового ПИД-регулятора и нечеткого регулятора для системы управления ракетой по углу атаки. Методом математического моделирования определим процессы в системе и дадим сравнительную оценку качества системы при использовании синтезированных регуляторов.

Введение