Событие является конструкцией, которая представляет действие, переход или условие. Можно транслировать события из иерархии модели. События могут соединить блоки, которые обнаруживают важные условия с разделом, чтобы запланировать выполнение раздела, когда условия происходят. Редактор расписаний позволяет вам создавать и управлять разделами и планировать выполнение вашей модели. Можно связать событие с апериодическим разделом, который запланирован, на основе приоритета, для выполнения, когда событие транслируется. Начиная с R2020b, события редактора расписаний могут быть отправлены из Stateflow® графики при помощи send
ключевое слово. События упрощают создание системы и обеспечивают большую гибкость во время планирования.
Каждая модель в иерархии модели имеет свою собственную панель Events в редакторе расписаний, которая содержит все события, существующие в модели и дочерних элементах модели. Когда вы открываете Редактор расписаний и обновляете схему, все разделы и события, существующие в модели, появляются в Редакторе расписаний. Через панель Events можно:
Создайте событие.
Удаление события.
Переименуйте событие.
Получите событие.
Привязать событие к разделу.
Отменить привязку события из раздела.
Вы можете запланировать выполнение апериодического раздела на основе вещания конкретного события в диаграмме Stateflow, как показано ниже:
На панели Events в редакторе расписаний отображается дерево событий. На каждом мероприятии можно увидеть вещателей и прослушиватели этого мероприятия.
Когда событие связано с разделом, имя события появляется в левой части раздела и в, Trigger столбце Order таблицы.
Уникальные имена применяются для событий в модели и в иерархии модели. В рамках иерархии модели имя модели заполняет имя события. Для примера, если модель-ссылка с именем ModelName
содержит событие, E1
, затем это событие появляется следующим ModelName.E1
в редакторе спецификаций.
Связать события. Событие и раздел могут быть связаны вместе, чтобы указать, что раздел выполняется, когда событие транслируется. Раздел может быть связан только с одним событием.
Выполнение на основе приоритета. Если связанный с событием раздел планируется запустить перед секцией, управляющей событием, то выполнение связанного с событием раздела прерывает выполнение раздела, управляющего событием. Если запущенный раздел планируется запустить после раздела, управляющего событием, то инициированный раздел выполняется, когда планировщик достигает своего положения в порядке выполнения.
listenerPartition
является апериодическим разбиением и прослушивателем события, Event1
. Предположим, что Event1
происходит из диаграммы Stateflow, присутствующей в модели, и является частью раздела, называемого, broadcastPartition
. Когда broadcastPartition
начинает выполняться, Event1
происходит, что затем запускает выполнение listenerPartition
.
Хит Таймс. Вы можете запустить апериодический разбиение в заданное время попадания. Если раздел имеет время хита и привязывается к событию, то время хита заменяется заданным событием. Точно так же, если раздел связан с событием и время хита добавлено, то связанное событие удаляется из раздела. Переменные могут также задать время попадания для апериодических разделов. В случае неоднозначной переменной и имен событий, событиям предоставляется приоритет.
В этом примере показано, как можно использовать события для планирования выполнения апериодических разделов через диаграмму Stateflow. Можно отправлять события из Stateflow и использовать эти события для управления выполнением разделов в модели с помощью событий в редакторе расписаний.
Откройте модель
В этом примере мы моделируем цифровое регулирование скорости двигателя внутреннего сгорания. В этой модели скорость вращения двигателя измеряется с помощью двух избыточных датчиков Холла, и мы моделируем отказ датчиков Холла.
Модель в основном содержит следующие основные компоненты:
Системные входы: Входы и сигналы для упражнения системы.
Engine: Упрощенное представление двигателя внутреннего сгорания.
Состав: Цифровой контроллер, предназначенный для развертывания на Engine управления Модуля (ECU) с Окружения выполнения (RTE).
Кривошипный двойной датчик Холла: Эмуляция двух избыточных датчиков, sensor A
и sensor B
.
Услуги RTE: Эмуляция услуг, предоставляемых Engine Control Модуля.
open_system("ex_engine_speed_control_system");
Системные входы
Системные входы для этой модели разработаны с использованием блока Редактор. The ex_engine_speed_control_external_inputs.mat
файл содержит следующий сценарий:
Необходимая скорость вращения установлена равной 2000 rpm
для всей симуляции.
В t = 01 sec
, контроллер скорости включен. В результате Hall sensor A
используется для вычисления скорости вращения и увеличения скорости вращения двигателя до 2000 rpm
.
В t = 06 sec
, инъецируется отказ первого датчика Холла. В результате Hall sensor B
теперь используется для вычисления скорости вращения, скорость вращения двигателя остается на 2000 rpm
.
В t = 11 sec
, инжектируется отказ второго датчика. В результате контроллер скорости отключен, скорость вращения двигателя падает к нулю.
В t = 15 sec
, отказ sensors A
и B
решается.
В t = 21 sec
команда включения регулировки скорости возвращается к нулю в течение одной секунды и обратно к единице. В результате скорость вращения двигателя увеличивается до 2000 rpm
.
Engine
Динамика двигателя представлена Передаточной Функцией, которая получает команду дросселя и преобразует его в крутящий момент, и Интегратором Второго Порядка, чтобы интегрировать движение.
Состав
ex_engine_speed_controller_composition
реализует цифровой алгоритм управления. Он содержит следующие компоненты:
ComputeRPM_A
и ComputeRPM_B
: Апериодические разделы, зарегистрированные как аппаратные прерывания. Hall sensors A
и B
запускает эти перегородки, когда вал двигателя вращается на каждый шаг 10 степеней.
computeThrottle
и actuatorProcessing
: Периодические разделы, выполняемые через 0.001 сек computeThrottle
опрашивает RTE в каждый временной шаг.
monitorMalfunction
: Периодическое разбиение на части 0,01 с. Контролирует выходные сигналы ComputeRPM_A
и ComputeRPM_B
идентифицировать потенциал оборудования отказов. Если обнаружен отказ, он вызывает функцию, предоставленную RTE, чтобы зарегистрировать отказ.
checkForRecovery
: Апериодический раздел, который запускается RTE после обнаружения отказа. При обнаружении checkForRecovery
вызывается RTE со скоростью 1 сек. вызывает функцию, предоставляемую RTE, если обнаружено восстановление.
Используя Редактор расписаний, события checkForRecovery
, tringCrankA
, и trigCrankB
создаются и привязываются к апериодическим разделам checkForRecovery
, ComputeRPM_A
, и ComputeRPM_B
соответственно. Эти события транслируются из верхней модели.
Кривошипный двойной датчик Холла
Датчики Холла моделируются с помощью блоков Hit Crossing, которые генерируют вызов функции каждый раз, когда вал двигателя вращается на шаги 10 степеней. Когда диаграмма Stateflow запускается, она отправляет события trigCrankA
и trigCrankB
, которые были связаны для выполнения апериодических разбиений, ComputeRPM_A
и ComputeRPM_B
соответственно.
Услуги RTE
The RTE Services
Подсистема эмулирует функциональности, доступные в Среде Выполнения, на которой разворачивается код, сгенерированный с помощью цифрового контроллера. В целях симуляции эти сервисы эмулируются с помощью функций Simulink.
sendFailureStatus
и recoverFailureStatus
вызываются соответственно monitorMalfunctions
и checkForRecovery
разделы при обнаружении отказа или восстановления. Глобальные статусы отказа хранятся с помощью блоков Data Store Memory в целях симуляции.
getFailureMode
вызывается computeThrottle
чтобы проверить, был ли обнаружен отказ в одном из датчиков.
getTimeA
и getTimeB
симулируйте часы RTE.
Check for Recovery
моделирует логику, чтобы определить, когда checkForRecovery
должна срабатывать апериодическая перегородка цифрового контроллера. Триггер осуществляется путем трансляции события checkForRecovery
.
Откройте Редактор расписаний
Чтобы открыть Редактор спецификаций, на вкладке Моделирование в Разделе проекта, нажмите Редактор спецификаций. Выполнение схемы обновления компилирует модели и показывает существующие разделы в редакторе расписаний.
Панель « События» в редакторе расписаний
События, транслируемые send
ключевое слово в Stateflow показано на панели «События» редактора расписаний, эти события связаны с апериодическими разделами, так что эти разделы могут быть запущены из верхней модели. На панели «События» можно развернуть каждое событие, чтобы увидеть прослушиватели и вещателей этого события. Значок, обозначающий вещатель события и значок, обозначает прослушиватель. В этом примере отправитель события checkForRecovery
- диаграмма Stateflow в RTE Services
подсистема, отправитель событий trigCrankA
и trigCrankB
- диаграмма Stateflow в двойном зале кривошипов - > Sensor A и Sensor B .
На панели Order перегородки расположены в порядке приоритета выполнения. Начиная с ComputeRPM_A
и ComputeRPM_B
чувствительны к времени, их приоритет самый высокий. Поэтому, когда события trigCranA
и trigCrankB
являются широковещательными, соответствующими разделами ComputeRPM_A
и ComputeRPM_B
выполняются немедленно. В противоположность этому апериодическое разбиение checkForRecovery
менее чувствителен к времени и ниже в порядке приоритета. Поэтому, когда событие checkForRecovery
широковещательная передача, выполнение соответствующего раздела checkForRecovery
отложено до тех пор, пока не будут выполнены все разделы с более высоким приоритетом.
Вы можете просмотреть это соединение событий в модели Simulink, это соединение передает поток выполнения между блоком, транслирующим событие, и другим блоком, слушающим это событие. Чтобы просмотреть это подключение, на панели инструментов Simulink, на вкладке Debug, выберите Information Overlays в разделе Diagnostic. В раскрывающемся меню выберите в разделе « Блоках» пункт «Спецификация соединителей».
Результаты симуляции
Щелкните Просмотр результатов (View Results) в Данные моделирования Inspector в модели, чтобы просмотреть результаты симуляции.
Можно использовать Редактор расписаний, чтобы сгенерировать тестовую обвязку для модели с событиями. Использование событий с тестовыми обвязками помогает избежать сложной проводки между блоком тестовой последовательности и всей системой.
Сгенерированная тестовая обвязка получает собственный Редактор расписаний, который позволяет легко отправлять события через тестовую обвязку. Через планировщик тестовых обвязок можно протестировать модель в различных сценариях, инициируя события в определенное время.
Панель «События» также позволяет связывать существующие события с другими апериодическими разделами. Вы можете сделать это, перетащив событие через допустимый апериодический раздел или добавив раздел непосредственно с помощью выпадающего списка. Можно заказать разделы, события которых являются триггером, в таблице Order относительно других разделов. Можно также создавать события в редакторе расписаний. Щелкните значок плюс. Дважды нажатие кнопки Добавить строку, чтобы создать новое событие. Вы можете использовать это событие для отправки из Stateflow, чтобы запланировать выполнение апериодического раздела.
События в редакторе расписаний не могут использоваться в моделях с экспортами функций.
События не поддерживают генерацию кода и не влияют на сгенерированный код.
События в редакторе расписаний используют следующие инструкции:
Событие не может быть вызвано до обработки этого события.
Повторяющиеся имена событий в родительской модели, вызванные присвоением двух моделей-ссылок того же имени, не разрешены.
Бесконечное закольцовывание не разрешено.
Раздел не может вызвать событие, которое запускает само себя.