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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение