Событие является построением, которое представляет действие, переход или условие. Можно широковещательно передать события из иерархии модели. События могут соединить блоки, которые обнаруживают важные условия с разделом, чтобы запланировать выполнение раздела, когда условия происходят. Редактор Расписания позволяет вам создавать и управлять разделами и планировать выполнение своей модели. Можно связать событие с апериодическим разделом, который планируется, на основе приоритета, для выполнения, когда событие будет широковещательно передано. Начиная в R2020b, события Schedule Editor могут быть отправлены от графиков Stateflow® при помощи send ключевое слово. События упрощают системное создание и обеспечивают больше гибкости во время планирования.
Каждая модель в иерархии модели имеет свою собственную панель Events в Редакторе Расписания, который содержит все события, существующие в модели и дочерних элементах модели. Когда вы открываете Редактор Расписания и обновляете схему, все разделы и события, существующие в модели, появляются в Редакторе Расписания. Через панель Events вы можете:
Создайте событие.
Удалите событие.
Переименуйте событие.
Получите событие.
Свяжите событие с разделом.
Развяжите событие от раздела.
Можно запланировать выполнение апериодического раздела на основе широковещательной передачи конкретного события в диаграмме Stateflow как показано ниже:
Панель Events в Редакторе Расписания показывает вам дерево события. Под каждым событием вы видите вещательные компании и прослушиватели того события.
Когда событие связано с разделом, имя события появляется на левой стороне раздела и в, столбец Trigger таблицы Order.
Уникальные имена осуществляются для событий в модели и в иерархии модели. В иерархии модели имя модели предварительно ожидает имя события. Например, если модель - ссылка под названием ModelName содержит событие, E1, затем то событие появляется как ModelName.E1 в редакторе расписания.
Свяжите События. Событие и раздел могут быть связаны, чтобы указать, что раздел выполняется, когда событие широковещательно передается. Раздел может только быть связан с одним событием.
Основанное на приоритете Выполнение. Если ограниченный событием раздел, как планируют, запустится перед разделом, управляющим событием, то ограниченное событием выполнение раздела вытесняет выполнение раздела, управляющего событием. Если инициированный раздел, как планируют, будет выполняться после раздела, управляющего событием, то инициированный раздел выполняется, когда планировщик достигает своего положения в порядке выполнения.
listenerPartition апериодический раздел и прослушиватель события, Event1. Предположим тот Event1 прибывает из диаграммы Stateflow, существующей в модели, и часть названного раздела, broadcastPartition. Когда broadcastPartition начинает выполняться, Event1 происходит, который затем инициировал выполнение listenerPartition.
Поразите Времена. Можно инициировать апериодический раздел в заданные времена хита. Если раздел поразил времена и связан с событием, времена хита заменяются заданным событием. Аналогично, если раздел связан с событием, и времена хита добавляются, то связанное событие удалено из раздела. Переменные могут также задать времена хита для апериодических разделов. В случае неоднозначной переменной и имен событий, событиям дают приоритет.
В этом примере показано, как можно использовать события, чтобы запланировать выполнение апериодических разделов через диаграмму Stateflow. Можно отправить события от Stateflow и использовать те события, чтобы управлять выполнением разделов в модели при помощи событий в Редакторе Расписания.
Откройте модель
В этом примере мы симулируем цифровую регулировку скорости двигателя внутреннего сгорания. В этой модели скорость вращения механизма измеряется с помощью двух избыточных датчиков Холла, и мы симулируем отказ датчиков Холла.
Модель, в основном, содержит следующие основные компоненты:
Системные Входные параметры: Входные параметры и сигналы осуществить систему.
Механизм: Упрощенное представление двигателя внутреннего сгорания.
Состав: Цифровой диспетчер намеревался развернуться на Блоке управления двигателем (ECU) со Средой выполнения (RTE).
Проверните Двойной Датчик Холла: Эмуляция двух избыточных датчиков, sensor A и sensor B.
RTE Services: Эмуляция сервисов обеспечивается Блоком управления двигателем.
open_system("ex_engine_speed_control_system");
Системные входные параметры
Системные входные параметры для этой модели созданы с использованием блок Signal Editor. 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.
Механизм
Движущие силы механизма представлены Передаточной функцией, которая получает команду дросселя и преобразует ее в крутящий момент и Интегратор Второго порядка, чтобы интегрировать движение.
Состав
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 соответственно. Эти события широковещательно передаются от топ-модели.
Проверните двойной датчик Холла
Датчики Холла моделируются с помощью блоков Пересечения Хита, которые генерируют вызов функции каждый раз, когда вал механизма вращается шагом 10 градусов. Когда диаграмма Stateflow инициирована, она отправляет события trigCrankA и trigCrankB, которые были обязаны выполнить апериодические разделы, ComputeRPM_A и ComputeRPM_B соответственно.
RTE Services
RTE Services подсистема эмулирует функциональности, доступные на Среде выполнения, на которую код сгенерированная форма развертывается цифровой контроллер. В целях симуляции те сервисы эмулированы с помощью Функций Simulink.
sendFailureStatus и recoverFailureStatus называются соответственно monitorMalfunctions и checkForRecovery разделы, когда отказ или восстановление обнаруживаются. Глобальные состояния отказа хранятся с помощью Блоков памяти Хранилища данных для целей симуляции.
getFailureMode вызван computeThrottle проверять, был ли отказ обнаружен в одном из датчиков.
getTimeA и getTimeB симулируйте часы RTE.
Check for Recovery симулирует логику, чтобы определить когда checkForRecovery апериодический раздел цифрового контроллера должен быть инициирован. Инициирование сделано путем широковещательной передачи события checkForRecovery.
Откройте редактор расписания
Чтобы открыть Редактор Расписания, на вкладке Modeling в Разделе Проекта, нажимают Schedule Editor. Выполнение Схемы Обновления компилирует модели и показывает вам существующие разделы в Редакторе Расписания.
Панель Событий в редакторе расписания
События широковещательно передаются send ключевое слово в Stateflow показывают в панели Событий Редактора Расписания, эти события связаны с апериодическими разделами, так, чтобы эти разделы могли быть инициированы от топ-модели. В панели Событий можно расширить каждое событие, чтобы видеть прослушиватели и вещательные компании того события. Значок,
указывает на вещательную компанию события и значка,
указывает на прослушиватель. В этом примере, отправителе события checkForRecovery диаграмма Stateflow в RTE Services подсистема, отправитель событий trigCrankA и trigCrankB диаграмма Stateflow в Заводной рукоятке Двойной Холл-> Датчик A и Датчик B.
В панели Порядка разделы располагаются в порядке очередности выполнения. Начиная с ComputeRPM_A и ComputeRPM_B время чувствительные, их приоритет является самым высоким. Поэтому, когда события trigCranA и trigCrankB широковещательно передаются, соответствующие разделы ComputeRPM_A и ComputeRPM_B сразу выполняются. В отличие от этого апериодический раздел checkForRecovery время меньше чувствительный, и ниже в порядке приоритетов. Поэтому, когда событие checkForRecovery широковещательно передается, выполнение соответствующего раздела checkForRecovery задерживается до всех разделов с более высоким приоритетом полное выполнение.
Можно просмотреть эту связь события в модели Simulink, эта связь передает поток выполнения между блоком, широковещательно передающим событие и другим блоком, слушая то событие. Чтобы просмотреть эту связь, на Панели инструментов Simulink, на вкладке Debug, выбирают Information Overlays в разделе Diagnostic. В выпадающем меню выберите Schedule Connectors 
в разделе Blocks.
Результаты симуляции
Кликните по выставленным для обозрения Результатам в Инспекторе Данных моделирования в модели, чтобы просмотреть результаты симуляции.
Можно использовать Редактор Расписания, чтобы сгенерировать тестовую обвязку для модели с событиями. Используя события с тестовыми обвязками помогает вам избежать комплексного проводного соединения между тестовым блоком последовательности и целой системой.
Сгенерированная тестовая обвязка получает свой собственный Редактор Расписания, который позволяет вам легко отправить события через тестовую обвязку. Через планировщик тестовой обвязки можно протестировать модель согласно различным сценариям инициирующими событиями в конкретные моменты времени.
Панель Событий также позволяет вам связывать существующие события с другими апериодическими разделами. Можно сделать это путем перетаскивания события по допустимому апериодическому разделу, или путем добавления раздела непосредственно с помощью выпадающего списка. Можно заказать разделы, которые имеют события как их Триггер в таблице Order относительно других разделов. Можно также создать события в Редакторе Расписания. Щелкните плюс значок. Дважды щелкните по Add Row, чтобы создать новое событие. Можно использовать это событие, чтобы отправить из Stateflow, чтобы запланировать выполнение апериодического раздела.
События в Редакторе Расписания не могут использоваться в моделях с экспортами функций.
События не поддерживают генерацию кода и не влияют на сгенерированный код.
События в Редакторе Расписания используют следующие инструкции:
Событие не может быть сгенерировано, прежде чем то событие обработало.
Дублирующиеся имена события в родительской модели, вызванной путем давания двум моделям - ссылкам того же имени, не позволены.
Цикличное выполнение Бога не позволено.
Раздел не может сгенерировать событие, которое инициировало себя.