Использование Simulink и Stateflow в моделировании
При использовании Stateflow®, Simulink® требуется для входов, выходов и структурирования. Только Stateflow может выполнить разнообразную обработку формул. При использовании Simulink переменные комплексного состояния могут быть реализованы с помощью методов, таких как использование блока Switch Case.
Simulink или Stateflow могут использоваться для моделирования конкретных частей управления, однако применение любого продукта в рабочем процессе разработки основано на понимании пользователем базовых алгоритмов и, в конечном счете, сводится к организации, чтобы определить, какой инструмент лучше всего подходит для их потребностей. Определение, следует ли использовать Simulink или Stateflow для проекта, должно определяться группой людей в соответствии с задачей. Должна также быть задана реализация в Stateflow с использованием переходов состояний или с графиками потока.
В большинстве случаев Stateflow менее эффективен в отношении оперативной памяти. Поэтому Simulink имеет преимущество в расчетах, которые используют простые формулы. В сложение Simulink более выгоден для ситуаций, когда переменные состояния управляются простыми триггерами и блоком Relay. При оценке того, использовать ли Simulink или Stateflow в проекте, должны быть приняты во фактор эти темы:
Увеличение ОЗУ: Всегда должно быть доступно ОЗУ для визуализации входов, выходов и внутренних переменных Stateflow.
Обработка ошибок уравнения: Когда общие вычислительные формулы используются внутри, пользователь разрабатывает способы, чтобы предотвратить переполнение.
Разделение и разделение функций: При выполнении вычислений, которые используют Simulink вне Stateflow, существует вероятность, что они могут разделиться, таким образом снижая читаемость. Существуют также случаи, когда читаемость может улучшиться. Об этом может быть трудно судить.
Существуют случаи, когда Stateflow имеет более эффективный код, чем Simulink для оптимальных выражений, которые близки к коду, но большинство из них приводит к модели, которую трудно понять. Если код уже существует, более выгодно использовать S-функции вместо моделирования Stateflow. Stateflow может отметить расчеты, где заданы конкретные расположения, или расчеты, использующие циклы for, более эффективно, чем Simulink, но в последние годы также стало удобно использовать MATLAB® язык для описания. При необходимости рассмотрите использование языка MATLAB для моделирования.
Для моделей Stateflow, при работе с состояниями, как описано ниже, читаемость улучшается, описывая их как переходы состояния:
Различные выходные значения являются выходными для идентичных входов.
Существует несколько состояний (в качестве руководства, три или более).
Состояния со значимыми именами вместо простых чисел.
Внутри состояния требуется инициализация (первый раз) и дифференциация во время выполнения (после второго раза).
Для образца в схемах триггера для входов выводятся различные значения. Переменные состояния ограничены 0 и 1. Однако значимое имя не может быть добавлено к каждому состоянию просто путем сохранения логических чисел типов. Также нет различия между инициализацией и выполнением в состоянии. Таким образом, из четырех выше применяется только один триггер, поэтому Simulink более выгоден.
В Stateflow ситуации, которые могут быть представлены как состояния, реализуются как переходы состояния и условные ветви, которые не являются состояниями, реализуются как блок-схемы. Таблицы истинности классифицируются как условный метод реализации ветви. При проектировании состояний как переходов состояний при помощи Stateflow, Classic должен быть выбран в качестве типа конечного автомата так, чтобы он был реализован как программное обеспечение во встроенные микро контроллеры системы управления.
HDL Coder™ поддерживается Stateflow. При использовании HDL Coder Mealy или Moore должны быть выбраны; Moore режим более подходит, когда требуется защита от внутренних электрических утечек.
Примечание
HDL Coder случаи использования не описаны в этих рекомендациях.
Функциональность Simulink
В этом разделе приведены сведения об использовании Simulink для моделирования.
Блоки с переменными состояния
Блоки с переменными состояния в основном сгруппированы в Simulink и дискретные типы.
Для большинства из этих блоков пользователь может задать атрибуты состояния и начальные значения с помощью параметров блоков. Условная подсистема может иметь переменные состояния, в зависимости от шаблона структуры.
В этом примере блок Unit Delay имеет атрибуты состояния.
В этом примере Tapped Delay блок не имеет атрибутов состояния.
См. руководство: jc_0640
Синтаксис ветви с переменными состояния
Блок Switch и условные подсистемы ведут себя по-разному, когда используются переменные состояния.
В зависимости от настройки строения, когда существует любая переменная состояния, блок Switch обычно выполняет подсистему A, когда выполняется условие порта управления. Если условие не удовлетворено, оно выполняет только подсистему B, не вычисляя подсистему A. Однако, когда подсистема A содержит переменную состояния, вычисление для переменной состояния в подсистеме A обрабатывается, даже когда условия порта управления не удовлетворены.
В условной подсистеме подсистема A вычисляется, когда условие удовлетворено. Когда это не выполнено, подсистема B вычисляется вместо подсистемы A, независимо от существования каких-либо переменных состояния в подсистеме A.
Действие сброса в перерасчете может быть задано с помощью параметра {Порт действия}.
Поведение подсистемы A при использовании блока Switch и условного потока управления представлено в следующих таблицах. Ознакомьтесь с этим поведением, чтобы определить, какая структура, Switch блок или условная подсистема наиболее подходят для целевого назначения.
Эта таблица показывает поведение подсистемы A
| Управляйте условием порта | (в подсистеме A) Переменные состояния | Выключатель | Условная подсистема |
| Держаться | Нет | Выполненный | Выполненный |
| Да | |||
| Не удерживать | Нет | Не выполнено | Не выполнено |
| Да | Минимально обработанный * Выполненные вычисления, связанные с переменными состояния |
В этой таблице приведены сроки инициализации подсистемы А.
| Порт действия | Инициализировать | |
| Выключатель | － | Только первый раз |
| Условная подсистема | Держаться | Только первый раз |
| Сброс | При возвращении условием |
См. инструкции:
Подсистемы
Подсистема используется для компиляции различных блоков и подсистем.
Подсистемы также могут использоваться в других целях. Методы использования, которые не являются функциональными подсистемами, включают:
Отображение маски подсистемы используется для описания контура или отображения документов фиксированной формы, таких как «classified»
Открытые функции (функции обратного вызова в свойствах блоков) подсистемы используются для запуска нескольких инструментов или отображения пояснительного текста отдельно от модели
Подсистемы, настройка которых изменилась на подсистему маски (подсистема, которая была просто установлена на
NoReadOrWrite) пользователем с правами администратора на внесение изменений, но другие пользователи не могут видеть содержимое.
Эти нетипичные подсистемы находятся вне рамок руководства и, в случае исключения, должны быть включены в список исключений, управляемый в рамках проекта.
См. инструкции:
Атомарные подсистемы и виртуальные подсистемы. Существует два типа подсистем: Виртуальная подсистема и Атомарные подсистемы. Основное различие между этими подсистемами заключается в том, рассматривается ли подсистема как один модуль выполнения. Виртуальная подсистема является блоком подсистемы по умолчанию.
В модели граница для Виртуальной Подсистемы является тонкой по сравнению с границей для Атомарной подсистемы, которая является толстой и жирной.
Виртуальные подсистемы
Блок, который обеспечивает визуальное представление, известен как «виртуальный блок». Например, блок Mux, который компилирует несколько сигнальных линий, блок From, который выдает сигнал, и блок Goto, который соответствует виртуальному блоку. Поскольку блок подсистемы в настройке по умолчанию представляет собой только визуальную иерархическую структуру, эти блоки считаются виртуальными блоками. Подсистема упоминается как виртуальная подсистема.
Рассмотрим подсистему, которая консультирует внешний результат вычисления в подсистеме, как показано в следующем примере. Эта система вычисляется из этих четырех уравнений.
temp1 = in1 + in2
temp2 = in3 + in4
out1 = in1 + in2 + temp2
out2 = temp1 + in3 + in4
Атомарные подсистемы
Атомарная подсистема отсоединяется от внешней системы и не подлежит трансграничной оптимизации. Атомарные подсистемы не используют результаты внутренних вычислений каждой подсистемы. Поэтому промежуточное выходное значение будет использовать результат вычисления, который задерживается на сеанс.
temp1 = in1 + in2
temp2 = in4 + in5
out1 = in1 + in2 + in3
out2 = in4 + in5 + in6
in3 = temp2
in6 = temp1
Атомарные подсистемы запрещают прямую ссылку промежуточных результатов вычисления на другие подсистемы.
Примечания к атомарным подсистемам:
Атомарные подсистемы могут выбирать настройки функции C-source.
Как объяснено выше, внутренний раздел атомарной подсистемы станет инкапсулированным (объективированным).
В зависимости от зависимости до и после статическая секция ОЗУ должна быть закреплена внутри подсистемы для выхода сигнала.
Атомарные подсистемы (включая сложение настроек функции) следует использовать с осторожностью. Настройка фактора не будет просто иметь имя фактора, вставленное в код С Следует признать, что он описан как математически независимая система и условия, при которых может использоваться атомарная подсистема, должны быть рассмотрены.
Включите связь со слоем структуры; необходимо определить правило операции по каждому проекту и определить его связь с правилами руководства.
Имя сигнала
Сигналы могут быть названы и называются именами сигналов. Когда сигнал назван, это имя сигнала отображается как метка. Обновления меток отражаются в названии сигнала и также отображаются.
Имя сигнала может быть распространено на сигнальную линию через линию разветвленного сигнала или блок порта и отображено как имя сигнала.
См. инструкции:
Код может быть сгенерирован путем связи имени сигнала с объектом сигнала (объектом Simulink или mpt объект). Настройка типа сконфигурирована через словарь данных, установка класса памяти опциональна. Рекомендуемые настройки типа данных для этих блоков включают:
См. руководство jc_0644: Настройка типа.
Векторные сигналы/сигнал пути
Отдельные скалярные сигналы, которые составляют вектор, должны иметь общие функции, тип данных и модулей.
Сигналы, которые не удовлетворяют условиям как вектор, могут быть сгруппированы только как сигнал шины. Блок Bus Selector должен использоваться только с входами сигнала шины. Он не должен использоваться для извлечения скалярного сигнала из вектора сигнала.
Следующая таблица является примером векторного сигнала.
| Типы векторов | Размер |
|---|---|
| Вектор-строка | [1 n] |
| Вектор-столбец | [n 1] |
| Подсистема скорости колеса | [1 номер колеса] |
| Вектор гидроцилиндра | [1 номер цилиндра] |
| Вектор местоположения на основе 2-мерных координационных точек | [1 2] |
| Вектор местоположения на основе 3-мерных координационных точек | [1 3] |
Следующая таблица является примером сигнала шины.
| Тип шины | Фактор |
|---|---|
| Шина датчика | Векторы силы |
| Местоположение | |
| Вектор скорости колеса [ | |
| Ускорение | |
| Давление | |
| Шина контроллера | Шина датчика |
| Шина привода | |
| Последовательная шина данных | Температура циркулирующей воды |
| Скорость вращения двигателя, дверь переднего пассажирского сиденья открыта |
См. инструкции:
Перечисленные типы
Перечисленные данные типа относятся к данным, которые ограничены определенным числовым значением.
Тип блоков, которые могут использоваться в перечисляемом типе в Simulink, ограничен.
Чтобы использовать перечисляемый тип, необходимо задать тип перечисления при помощи .m файл в MATLAB. Для получения дополнительной информации об определении типов данных перечисления смотрите Использование перечисленных данных в моделях Simulink.
Функциональность Stateflow
В этом разделе приведены сведения об использовании Stateflow для моделирования.
Операторы, доступные для Stateflow
Для получения дополнительной информации об операторах Stateflow, смотрите Поддерживаемые операции для данных графика (Stateflow).
См. инструкции:
Различия между переходом состояния и Графика потока
Stateflow может представлять и переход состояния, и графика потока.
Stateflow позволяет проектировать график потока в диаграмму переходов состояний.
Действие входа представлено как график потока в состоянии, которое начинается с перехода по умолчанию и переходит к соединениям через переходные линии, как показано ниже. Начиная с внутренней переходной линии, позволяет, во время действия, быть представленным в график потока.
График потока не может поддерживать свое активное состояние между обновлениями. В результате график потока всегда заканчивается в оконечном соединении (соединительном соединении, которое не имеет допустимых исходящих переходов).
Напротив, диаграмма переходов состояний сохраняет свое текущее состояние в памяти, чтобы сохранить локальные данные и активное состояние между обновлениями. В результате диаграмм переходов состояний могут начать выполняться там, где они остановились на предыдущем временном шаге. Это означает, что переходы состояний подходят для моделирования реактивных или диспетчерских систем, которые зависят от истории.
Эта таблица определяет точки начала и конца для графика и диаграммы переходов состояний потока.
| Начальная точка | Конечная точка | |
| Блок- график | Переход по умолчанию | Все выводы из состояния соединяются с соединительным соединением. |
| Диаграмма переходов состояний | Переход по умолчанию | Любое завершение должно быть подключено к состоянию |
Этот рисунок показывает различие между общим графиком потока и диаграммы переходов состояний
Смесь графиков потока и диаграмм переходов состояний с самопереходом имеет более строгие ограничения.
См. инструкции:
Отступление
Этот пример показывает поведение переходов с соединениями, которые заставляют поведение обратного отслеживания в графики потока. График использует неявное упорядоченное расположение исходящих переходов.
Первоначально состояние A активно, и условия перехода c1, c2 и c3 верны. Условия перехода c4 ложны.
Корень графика проверяет, есть ли допустимый переход от состояния А.
Существует допустимый сегмент перехода, отмеченный условием перехода c1 от состояния A к соединительному соединению, поэтому:
Условие перехода c1 верно, поэтому действие a1 выполняется.
Условие перехода c3 верно, поэтому действие a3 выполняется.
Условие перехода c4 не верно, и, следовательно, поток управления возвращается в состояние A.
Корень графика проверяет, есть ли другой допустимый переход от состояния A.
Существует допустимый сегмент перехода, отмеченный условием перехода c2 от состояния A к соединительному соединению, поэтому:.
Условие перехода c2 верно, поэтому действие a2 выполняется.
Условие перехода c3 верно, поэтому действие a3 выполняется.
Условие перехода c4 не верно, и, следовательно, поток управления возвращается в состояние A.
График засыпает.
Чтобы решить эту проблему, рассмотрите добавление безусловных линий перехода к оконечным соединениям. Оконечные соединения позволяют потоку закончиться, если либо c3, либо c4 не верно. Этот проект оставляет состояние A активным, не выполняя ненужных действий.
См. инструкции:
Поток Графика вне состояния
График потока, сопоставленная с состоянием, может быть записана внутри или вне состояния; однако будьте внимательны к порядку выполнения и обратному отслеживанию.
Следующий график потока, который оценивает переход от a до b после выполнения графика потока за пределами состояния, по-видимому, выполняет переход за тот же период, что и при более новом вычислении. Однако линия перехода к b не оценивается, если точка окончания достигается путем вычисления перехода вне состояния. Это диаграмма переходов состояний, которое всегда остается в.
Правильно выполнено, как показано ниже, условие перехода не позиционируется при завершении внешнего графика потока, позволяя оценивать линию перехода от a до b после выполнения графика потока. Это позволяет графику внешнего потока выполняться перед переходом и оцениваться с использованием самого последнего значения в момент перехода. Обратите внимание, что этот график содержит мертвый путь, где условие перехода никогда не будет удерживаться, что может вызвать ошибку при изменении спецификации в будущем. Используйте эту структуру графика с осторожностью.
Напротив, следующий график потока находится внутри состояния, что означает, что внутренний график потока всегда вычисляется при выполнении состояния а и может быть описан как легко понятная структура без мертвых путей. Однако следует отметить, что в качестве эффективности характеристики, когда состояние a выполняется, переход от a до b оценивается в цикле, следующем за циклом, в котором вычисляется внутренний график потока. Из-за этой характеристики время выполнения вычислений и переходов для внешнего графика потока может быть отключено. Используйте с осторожностью.
См. инструкции:
Переменные указателя
Эта выборка кода из модели sf_custom. Чтобы открыть модель, введите следующее в командной строке MATLAB:
open_system('sf_custom')Insf_custom моделищелкните Открыть my_header.h. #include "tmwtypes.h"
extern real_T my_function(real_T x);
/* Definition of custom type */
typedef struct {
real_T a;
int8_T b[10];
}MyStruct;
/* External declaration of a global struct variable */
extern MyStruct gMyStructVar;
extern MyStruct *gMyStructPointerVar;
sf_custom моделищелкните Открыть my_function.c.#include "my_header.h"
#include <stdio.h>
/* Definition of global struct var */
MyStruct gMyStructVar;
MyStruct *gMyStructPointerVar=NULL;
real_T my_function(real_T x)
{
real_T y;
y=2*x;
return(y);
}
gMyStructVar не определен в Stateflow. Как правило, функции my_function вызываются из источника C для использования в Stateflow. Однако прямая ссылка на глобальные переменные, открытые источником C, также доступна из Stateflow.
Инициализация
В этом разделе приведены сведения об использовании значений инициализации.
Настройка начального значения в инициализации
Когда сигнал должен быть инициализирован, начальные значения должны быть установлены правильно.
Когда начальные значения заданы внутри блока, используйте список начальных значений, который включает аннотации, чтобы можно было визуально подтвердить исходные значения.
Случаи, которые требуют начальных значений, включают:
Когда переменные состояния определены И используются блоки, которые имеют переменные состояния.
Используйте настройки внутренних блоков.
Используйте значения внешних входов.
Когда переменные состояния определены И начальные значения активированы для блока, когда выполняется определенное строение.
Установите начальные значения в блоках Merge.
Используйте сигналы, зарегистрированные в словаре данных.
Когда заданы настройки сигнала (с ОЗУ), которые можно ссылаться извне.
Используйте сигналы, зарегистрированные в словаре данных.
Начальные значения сигналов, зарегистрированных в словаре данных
Установите начальные значения для сигналов, зарегистрированных в словаре данных.
Дискретные группы блоков, такие как Unit Delay и Data Store Memory, имеют переменные состояния.
В случае автоматической генерации кода имя, тип и начальное значение сигнала могут быть установлены для переменных состояния путем согласования его с сигналом в словаре данных (сопоставленном с объектами сигнала Simulink). При использовании сигнала, заданного в словаре данных для переменной состояния, соответствующие начальные значения должны соответствовать тому же значению.
При использовании сигнала, заданного в словаре данных для переменной состояния
Для дискретных блоков, таких как Unit Delay и Data Store Memory, настройки выполняются не при использовании сигналов, определенных в словаре данных для выходной линии блока, а для переменных состояния внутри блока. Даже когда имя сигнала словаря данных присваивается сигнальной линии, ОЗУ резервируется в дубликате, что является потерей ОЗУ.
Пример - Исправление
Сигнал задан для переменных состояния внутри блока. Имя сигнала задано, и параметры блоков имя состояния должно разрешиться к объекту сигнала Simulink.
Пример - Неправильный
Сигнал задается для выходного сигнала блока, который имеет переменные состояния. Имя сигнала задано, и имя параметров блоков состояния должно разрешиться к объекту сигнала Simulink не выбрано.
Объекты сигнала, которые определены в Рабочей области, могут автоматически ассоциироваться с объектами сигнала и именами сигналов с таким же именем при помощи disableimplicitsignalresolution(modelname). Однако для переменных состояния внутри блока они связаны с переменными состояния внутри блока и одноимённым именем сигнала. Если глобально установленный сигнал сопоставлен с двумя переменными одновременно, лучше выполнить настройки так, чтобы переменные состояния внутри блока и метка сигнала на сигнальной линии имели различные имена, в противном случае модель не может быть моделирована.
Блок, чье внешнее входное значение является начальным значением
При установке начального значения во время инициализации init вызывается функция, чтобы установить сигнал либо на значение внутри блока, либо на начальное значение, заданное в словаре данных. Затем выполняется пошаговая функция (исполнительная функция потока данных). Здесь, внешнее входное значение устанавливается как начальное значение. При моделировании будьте внимательны к функциям выполнения и времени выполнения для инициализации. Это показано на следующем изображении.
Следующее изображение
Начальные настройки значения в системном строении, которые включили бы параметры инициализации
Существуют системные строения, где в зависимости от их настроек включаются параметры инициализации для комбинаций условных подсистем и блоков Merge. Когда в комбинациях тезисов требуются начальные значения, выполняется любой из следующих методов моделирования:
Исключение - когда существуют последующие блоки с начальными значениями, и настройки для каждого блока не нужны, чтобы четко показать начальное значение сигнала.
Пример - Исправление
Начальное значение, установленное в блоке Merge.
Пример - Исправление
Начальное значение установлено в mpt объект.
Пример - Неправильный
Несмотря на требование установки начального значения, оно нигде не показано.
