В этом примере показано, как смоделировать планирование задач управляющего приложения с помощью блоков SimEvents. SimEvents расширяет Simulink с возможностью моделирования и моделирования архитектурных компонентов системы реального времени.
Верхняя часть модели включает две области блоков:
Функциональные компоненты включают две системы с обратной связью. Каждый имеет пропорциональный контроллер, работающий на объекте.
Архитектурные компоненты включают блоки SimEvents, моделирующие задачи и планировщик этой системы управления.
Этот пример моделирует контроллер как модель экспортированной функции Simulink. Он преобразует выполнение контроллера в программную задачу, которую операционная система периодически планирует и выполняет. Задача может быть разделена на несколько сегментов (или подзадач). Из-за зависимостей данных эти сегменты должны выполняться в последовательном порядке.
Задача задается следующими параметрами:
ID: Уникальный идентификатор задачи.
Период: как часто задача создается для выполнения.
Приоритет: Приоритет задачи (меньшее значение указывает на более высокий приоритет).
Список выполняемых сегментов (функций): Исполняемые файлы, сопоставленные с каждым сегментом задачи. Эти исполняемые файлы представлены функциями Simulink экспортированной модели функции.
Длительность выполнения сегмента: время завершения сегмента задачи, если он выполняется на процессоре без прерывания.
Нужен дисковый ресурс ввода/вывода для каждого сегмента: Требуется ли сегмент задачи использование защищенного мьютексом общего ресурса (жесткого диска).
Для примера блок Task 2 задает задачу для второго контроллера (блок Controller2). Задача включает два сегмента, «t2_run» и «t2_write,», смоделированные как функции Simulink в seSwcController2 модели. В этих сегментах «t2_write» требует использования защищенного мьютексом общего ресурса.
Планировщик операционной системы моделируется следующими компонентами:
Создание задачи: Блокируйте задачу 1 и задачу 2 создают задачи и управляют состояниями задачи. Сущность SimEvents представляет образец задачи. Свойства задачи (такие как ее приоритет) моделируются как атрибуты сущности.
Очередь задач: После создания экземпляра задача присоединяется к очереди готовых задач, которая моделируется блоком очереди задач ОС Entity Queue. Чтобы симулировать политику планирования, основанную на неупреждающем приоритете, блок очереди сконфигурирован для сортировки задач по атрибуту taskPriority.
Центральный процессор: Процессор системы моделируется как блок Entity Server CPU. Он принимает сущности из очереди задач ОС и обрабатывает сущность в течение длительности, заданной параметром Segment execution parameter. В конце этой задержки вызывается соответствующая функция Simulink этого сегмента задачи, как часть действия Service complete блока.
Блокировка/разблокировка Mutex: Прежде чем сегмент задачи войдет в блок CPU, он должен получить необходимый ресурс в предыдущем блоке Lock Mutex. После того, как сегмент задачи завершает и выходит из блока CPU, ресурс освобождается в блоке Unlock Mutex.
Управление состояниями задачи: Блоки под маской Задачи 1 и Задачи 2 управляют состоянием выполнения задач. После завершения сегмента задачи, если у задачи есть последующие сегменты для выполнения, задача направляется назад в очередь задач ОС. В противном случае этот образец задачи завершается и отбрасывается.
Блок CPU сконфигурирован с двумя ядрами. Симуляция модели генерирует следующий график Ганта.
Задача более высокого приоритета, Задача 2 (красные планки), запланирована на ядро 1 (y = 1).
Задача нижнего приоритета, Задача 1 (синие полосы), запланирована на ядро 2 (y = 2).
Во втором сегменте задачи 2 используется mutex DiskLock. Зеленые полосы указывают на использование (y = 3).
Измените следующие параметры и исследуйте, как изменяются расписания задач и эффективность контроллера с переопределенными архитектурными параметрами.
В блоке CPU сконфигурируйте параметр Capacity, чтобы изменить количество ядер.
В блоках Task 1 и Task 2 сконфигурируйте такие параметры, как Period и Priority, чтобы изменить спецификации задачи.
Например, если мы изменим Need disk i/o ресурс для каждого параметра сегмента блока Task 1 на [0 0 1], t1_write сегмент Controller 1 должен получить mutex DiskLock, прежде чем он начнет запускаться. Симуляция генерирует график Ганта, которая иллюстрирует это изменение.
Обе задачи имеют сегменты, которые используют mutex DiskLock, на что указывают зеленые полосы (y = 3).
Третий сегмент задачи 1 теперь должен выполняться последовательно со вторым сегментом задачи 2 (см. Y = 1), поскольку оба сегмента совместно используют mutex DiskLock.
Entity Generator | Сервер сущности | Очередь | Приобретатель ресурсов | Пул ресурсов | Ресурс Releaser
