В системах управления как правило все занчительно проще, с точки зрения типов:
На вход идет число — значение с датчика, на выход тоже число — команда упрвления, все число, даже если это логическое да или нет 0,1. Для упрощения можно считать что все числа — реальные двойной точности.
А «идеи возникшие позже», это разные схемы обработки этих чисел.
Тут дело в том, что схему алгоритма можно запустить на исполнение без генерации года Си. Графический язык SimInTech может выполнять расчеты, сам по себе. А IDE Delphi все переводит в ОО Паскаль, а потом только компилирует и выполняет. Как то так.
И еще, в IDE Delphi функции все таки нужно писать на Паскале. А в графическом языке — не надо, можно все нарисовать.
Я так полагаю, что раз встроенных механизьмов реализции методоллогии ООП нет в С, а нужно делать из костылей и велосипедов, то это не ООП. А если стандратные средства поддерживают методологию ООП из коробки, то ООП. Наверное так как то, но это не точно ;)
С точки зрения пользователя СFront это ООП, а С — нет.
В стандарте MЭК 60880 «Атомные станции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категории А». Используется понятие Проблемно-ориентированный язык (application oriented language): компьютерный язык, специально разработанный для определенного типа применений и используемый лицами, являющимися специалистами в данном типе применений. [МЭК 62138, 3.3]
В этом же стандарте есть понятие Автоматизированная генерация кода (automated code generation): функция автоматизированных инструментов, позволяющая преобразовывать проблемно-ориентированный язык в форму, пригодную для компиляции или выполнения.
Таким образом схему графического языка SimInTech вполне можно рассматривать как программу на проблемно ориентированном языке. (графическом языке программирования)
Мне тоже типизированный Паскаль нравится больше.
Но с Си на контроллерах управления, мне кажется это исторически сложилась такая практика, контроллеры более слабые, чем десктопные процессоры, поэтому гибкость Си позволяла реализовать «всякие трюки», а потом в критических системах это осталось, типа работает — не трогай. Вчера сделали на Си работало значит и сегодня будем продолжать тоже.
Да принцип работы именно такой.
Но то что это совсем не ООП не соглашусь. Например: Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере статьи КД1, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.
Язык Си не является объектно-ориентированным языком. И значит все что будет описано ниже это костыли и велосипеды.
ООП включает в себя три столпа: инкапсуляция, наследование, полиморфизм. Ниже я покажу как этих вещей можно добиться в С. habr.com/ru/post/263547
Пример определения из ООП Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере КД, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.
На самом деле нет, давление в баках при заполнении растет, нивелирный напор изменяется, если баки на разной высоте и разной конфигурации. В предельном случае в один плоский с большим сечение горизонтальным сечением, у него при наполнение давление практически не меняется другой высокий с малым сечением у него давление начинает расти за счет нивелирного напора. Как в алгебраических уравнениях это учитывать? Тут фишка в том, что это реальная конфигурация реального вертолета взятая как она есть для эксперимента. Уравнения дольше бы составлял.
Так расчет здесь не статический, а динамически и методы регулирования и оптимизации из ТАУ, в результате получены необходимые конструктивные размеры. Задача была проверить саму возможность. Можно сделать все трубы одинаковые, тогда заполнение баков будет не равномерное — конструкция рабочая, но не оптимальная. Поэтому как пример пойдет.
Потому, что обеспечивает заданное соотношение расходов в заданной конфигурации турбопроводов. Задача методами оптимизации подобрать конструктивное решение, она выполнена. Можно было ввести еще и общую массу трубопроводов (для вертолета чем меньше тем лучше), тогда вариант 2 (найден оптимизацией) с меньшим диаметром выигрывает.
Почему единственного? Если начальные условия 70 мм и идти к уменьшению то найдется другое сочетаине диаметров которое обеспечит зданное сочетание расходов. Тут даже два метода дают разные наборы значений. В локальном минимуме теоретически может остатся интегратор, но поскольу их здесь шесть и они друг друга качают из-за связей между баками на графиках 6 и 7 это видно.
Конечно сам задача, не реальна, просто численный эксперимент. Но модель использованая для эксперемента воплне реальная. В реальной задачи было изменение высоты полета, а так же учет всех температур, давления за бортом и т.д. и т.п. Но если посмотреть на результат, то видно что даже в такой постановке получились два характерных диаметра 10 и 15.
В реальной задаче подбирались расходы воздуха для охлаждения отсеков с аппаратурой управления при разных режимах работы, там как раз воздуховоды могут быть разными. Но там модель секретная. Поэтому эксперемент с более солжной моделью.
Это не связано с возможностями Simulink, просто как только вы представили объект в виду передаточной функции согласно методам ТАУ, у вас конструкторские параметры которые можно оптимизировать, перестали быть явными переменными в формулах. (см. комментарии выше) Например для двигателя, в статье про регулирование газотурбинного двигателя Simulink может подобрать оптимальную величину Кгтд, но каким для этого Кгтд будут величины Мт, Мк, Gto и No Simulinк и любой другой софт использующий методы ТАУ определить не сможет. Поскольку они явно не прописаны в передаточной функции. И этому же одному оптимального значению передаточной функции Кгтд может соответствовать разный набором параметров Мт, Мк, Gto и No.
Нет задвижками не прокатит. Задвижками можно побирать шайбы. Ставим в модель задвижку моделируем. получаем по степени открытия задвижки диаметр шайбы, для местного сопротивления. Здесь же в модели, диаметр учитывается в месте с длинной трубопоровода для расчета гидравлического сопротивления всего трубопровода. Просто в компьютерной модели есть возможность задать диаметр друбопровода не постоянным, а переменным и менять его прямо в процессе моделирования переходного процесса. Что и было продемонстрировано.
Тут дело в том, что если объект представить в виде передаточной функции для того что бы анализировать в Matlab или Simulink, то как правило пропадают те реальные физические параметры объекта, которы можно менять методами оптимизации. Например для двигателя, ранее был пример передаточной функции, где ее (передаточной функции) параметры вычисляются как:
Если мы будем оптимизировть К гтд Т гтд в матлабе, то это нам не даст конкретных значений физических параметров объекта, типа диаметров.
Поэтому в учебниках приводят модель объекта в виде передаточных функций (как некую физическую и не изменяемую сущность) и начинают оптимизировать регулятор.
На вход идет число — значение с датчика, на выход тоже число — команда упрвления, все число, даже если это логическое да или нет 0,1. Для упрощения можно считать что все числа — реальные двойной точности.
А «идеи возникшие позже», это разные схемы обработки этих чисел.
И еще, в IDE Delphi функции все таки нужно писать на Паскале. А в графическом языке — не надо, можно все нарисовать.
С точки зрения пользователя СFront это ООП, а С — нет.
Проблемно-ориентированный язык (application oriented language): компьютерный язык, специально разработанный для определенного типа применений и используемый лицами, являющимися специалистами в данном типе применений. [МЭК 62138, 3.3]
В этом же стандарте есть понятие
Автоматизированная генерация кода (automated code generation): функция автоматизированных инструментов, позволяющая преобразовывать проблемно-ориентированный язык в форму, пригодную для компиляции или выполнения.
Таким образом схему графического языка SimInTech вполне можно рассматривать как программу на проблемно ориентированном языке. (графическом языке программирования)
Но с Си на контроллерах управления, мне кажется это исторически сложилась такая практика, контроллеры более слабые, чем десктопные процессоры, поэтому гибкость Си позволяла реализовать «всякие трюки», а потом в критических системах это осталось, типа работает — не трогай. Вчера сделали на Си работало значит и сегодня будем продолжать тоже.
Но то что это совсем не ООП не соглашусь. Например:
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере статьи КД1, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.
ООП включает в себя три столпа: инкапсуляция, наследование, полиморфизм. Ниже я покажу как этих вещей можно добиться в С.
habr.com/ru/post/263547
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Когда я ставлю на схему блок, в примере КД, я как раз получаю классический пример инкапсуляции. Пользователь указывает сигнал с какого датчика он хочет получить в миливольтах, и задает параметры для пересчета и получает значения в единицах измерения, например в град Цельсия.
Классическое из ООП объединение данных и методов их обработки.
В реальной задаче подбирались расходы воздуха для охлаждения отсеков с аппаратурой управления при разных режимах работы, там как раз воздуховоды могут быть разными. Но там модель секретная. Поэтому эксперемент с более солжной моделью.
Если мы будем оптимизировть К гтд Т гтд в матлабе, то это нам не даст конкретных значений физических параметров объекта, типа диаметров.
Поэтому в учебниках приводят модель объекта в виде передаточных функций (как некую физическую и не изменяемую сущность) и начинают оптимизировать регулятор.