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