Событие является конструкцией, которая представляет действие, переход или условие. Можно транслировать события из иерархии модели. События могут соединить блоки, которые обнаруживают важные условия с разделом, чтобы запланировать выполнение раздела, когда условия происходят. Редактор расписаний позволяет вам создавать и управлять разделами и планировать выполнение вашей модели. Можно связать событие с апериодическим разделом, который запланирован, на основе приоритета, для выполнения, когда событие транслируется. Начиная с 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, чтобы запланировать выполнение апериодического раздела.
События в редакторе расписаний не могут использоваться в моделях с экспортами функций.
События не поддерживают генерацию кода и не влияют на сгенерированный код.
События в редакторе расписаний используют следующие инструкции:
Событие не может быть вызвано до обработки этого события.
Повторяющиеся имена событий в родительской модели, вызванные присвоением двух моделей-ссылок того же имени, не разрешены.
Бесконечное закольцовывание не разрешено.
Раздел не может вызвать событие, которое запускает само себя.