Документация

Захват требований в деятельности и контекстных схемах

Диаграммы активности помогают вам графически захватить спецификацию и понять, как работает система. Иерархическая структура помогает с анализом даже больших систем. На верхнем уровне контекстная схема описывает окружение системы и ее взаимодействие с исследуемой системой с точки зрения операций обмена данными и управления. Затем можно разложить систему на схему действий с процессами и спецификациями управления (CSPEC).

Процессы управляют иерархическим разложением. Каждый процесс задается с помощью другой схемы действий или примитивной спецификации (PSPEC). Можно задать PSPEC в ряде представлений с формальным семантическим, таким как Диаграмма Simulink. В сложение контекстные схемы графически захватывают контекст системных операций.

Контекстная схема: Система окна со степенью

Рисунок представляет контекстную схему системы степени. Квадратные коробки захватывают окружение, в этом случае, драйвер, пассажира и окно. И драйвер, и пассажир могут отправить команды в окно, чтобы переместить его вверх и вниз. Контроллер выводит правильную команду для передачи приводу окна (например, команда драйвера имеет приоритет над командой пассажира). В сложение схема контролирует состояние оконной системы, чтобы установить, когда окно полностью открыто и закрыто, и обнаружить, есть ли объект между окном и системой координат.

Кружок (также известный как пузырь) представляет контроллер окна со степенью. Кружок является графическим обозначением для процесса. Процессы захватывают преобразование входных данных в выходные данные. Примитивный процесс также может сгенерировать. CSPEC обычно состоят из комбинационной или последовательной логики, чтобы вывести выходные сигналы управления из входного управления.

Для реализации в окружение Simulink, смотрите Внедрение Контекстной Схемы: Система Степени.

Схема действия: Степень окна управления

Управление окном степени состоит из трех процессов и CSPEC. Два процесса подтверждают вход драйвера и пассажира, чтобы убедиться, что их вход является значимым, учитывая состояние системы. Например, если окно полностью открыто, MOVE DOWN команда не имеет смысла. Оставшийся процесс определяет, полностью ли открыто или полностью закрыто окно и присутствует ли объект. CSPEC принимает управляющие сигналы и выводит, перемещать ли окно вверх или вниз (например, если объект присутствует, окно перемещается вниз примерно на одну секунду или пока оно не достигает конечной остановки).

Для реализации в среде Simulink смотрите Реализацию Схемы Деятельности: Управление Окна Степени.

Схема действия: валидация драйвера

Каждый процесс в графике действия VALIDATE DRIVER является примитивным и определяется следующим PSPEC. В MAKE EXCLUSIVE PSPEC по соображениям безопасности DOWN команда имеет приоритет над UP команда.

PSPEC 1.1.1: CHECK DOWN
  CHECKED_DOWN = DOWN and not RESET

PSPEC 1.1.2: CHECK UP
  CHECKED_UP = UP and not RESET

PSPEC 1.1.3: MAKE EXCLUSIVE
  VALIDATED_DOWN    = CHECKED_DOWN
  VALIDATED_UP      = CHECKED_UP and not CHECKED_DOWN
  VALIDATED_NEUTRAL = (NEUTRAL and not (CHECKED_UP and not CHECKED_DOWN))
                        or not (CHECKED_UP or CHECKED_DOWN)

Для реализации в среде Simulink смотрите Внедрение Схемы Деятельности: Валидация.

Схема деятельности: валидация пассажира

Внутренние элементы процесса VALIDATE PASSENGER аналогичны процессу VALIDATE DRIVER. Единственное различие - это различные входные и выходные параметры.

PSPEC 1.2.1: CHECK DOWN
  CHECKED_DOWN = DOWN and not RESET

PSPEC 1.2.2: CHECK UP
  CHECKED_UP = UP and not RESET

PSPEC 1.2.3: MAKE EXCLUSIVE
  VALIDATED_DOWN    =  CHECKED_DOWN
  VALIDATED_UP      =  CHECKED_UP and not CHECKED_DOWN
  VALIDATED_NEUTRAL = (NEUTRAL and not (CHECKED_UP and not CHECKED_DOWN))
                        or not (CHECKED_UP or CHECKED_DOWN)

Для реализации в среде Simulink смотрите Схему деятельности: Валидация пассажира.

Схема действия: Обнаружение торца препятствия

Третий процесс в схеме активности POWER WINDOW CONTROL обнаруживает наличие препятствия или когда окно достигает верхней части или низа (ENDSTOP). Механизм обнаружения основан на токе якоря оконного привода. Во время нормальной операции этот ток находится в пределах определенных границ. Когда окно достигает своей верхней части или низа, электромотор потребляет большой ток (более 15 А или менее -15 А), чтобы попытаться сохранить свою скорость вращения. Точно так же во время нормальной операции ток составляет около 2 А или -2 А (в зависимости от того, открывается или закрывается окно). Когда есть объект, происходит небольшое отклонение от этого значения. Чтобы сохранить силу окна на объекте менее 100 Н, управление переключается на его аварийную работу, когда обнаруживает ток, который меньше -2,5 А. Эти операции необходимы только когда окно накатывается, что соответствует отрицательному току в конкретной проводке этой модели. Схема действия ОБНАРУЖИТЬ ПРЕПЯТСТВИЕ ENDSTOP воплощает эту функциональность.

CSPEC 1.3: DETECT OBSTACLE ENDSTOP
  RESET = OBSTACLE or ENDSTOP

PSPEC 1.3.1: DETECT ENDSTOP
  ENDSTOP = WINDOW_POSITION > ENDSTOP_MAX

PSPEC 1.3.2: DETECT OBSTACLE
  OBSTACLE = (WINDOW_POSITION > OBSTACLE_MAX) and MOVE_UP for 500 ms

Для реализации в окружение Simulink, смотрите Схему действия: Обнаружение конца препятствия.

Определения данных

Функциональное разложение однозначно задает каждый процесс своим разложением или примитивной спецификацией (PSPEC). В сложение он также должен формально задать сигналы в схемах активности. Используйте определения данных для этих спецификаций.

Следующие таблицы являются определениями данных для сигналов, используемых в схемах деятельности.

Связанная схема деятельности смотрите Контекстную схему: Система Степени.

Связанная схема деятельности смотрите Схему действия: Управление Окна степени.

Связанная схема действия приведена в разделе «Схема действия: валидация драйвера».

Связанная схема деятельности смотрите Схему деятельности: Валидация пассажира.

Связанная схема действия смотрите Схему действия: Обнаружение остановки препятствий.

Проект модели итератируется, когда мы исследуем более детальные реализации. Для получения информации о том, как итерация проекта модели происходит при введении дополнительной детализации, смотрите Итерация по проекту.

Исследуйте проект контроллера окна степени

Реализация схемы деятельности: Управление Окна со Степенью

В этой теме описывается спецификация управления дискретными событиями высокого уровня для управления окна со степенью.

Можно смоделировать управление дискретным событием окна с помощью диаграммы Stateflow. Диаграмма Stateflow является конечным конечным автоматом с иерархией и параллелизмом. Этот конечный автомат содержит основные состояния системы окна со степенью: вверх, автоматически вверх, вниз, автоматически вниз, отдых и аварийная ситуация. Он моделирует изменения состояния и учитывает приоритет команд драйвера над командами пассажира. Это также включает аварийное поведение, которое активируется, когда программное обеспечение обнаруживает объект между окном и системой координат во время движения вверх.

Начальная модель Simulink для управления окна со степенью, slexPowerWindowControl, является контроллером дискретных событий, который запускается с заданной частотой дискретизации.

В этой реализации откройте подсистему управления окна со степенью и заметьте, что диаграмма Stateflow с управлением дискретным событием образует CSPEC, представленный наклоненной толстой планкой в правом нижнем углу. Подсистема detect_obstacle_endstop инкапсулирует механизмы обнаружения порога.

Управление дискретным событием является моделью Stateflow, которая расширяет диаграмму переходов состояний понятие с иерархией и параллелизмом. Изменения состояния из-за команд пассажира инкапсулируются в супер состоянии, которое не соответствует активной команде драйвера.

Рассмотрите управление пассажирским окном. Пассажир или драйвер может перемещать это окно вверх и вниз.

Этот конечный автомат содержит основные состояния системы окна со степенью: вверх, автоматически вверх, вниз, автоматически вниз, отдых и аварийная ситуация.

Интерактивная проверка

Управляйте входом.  The slexPowerWindowCntlInteract модель включает этот управляющий вход в качестве переключателей. Дважды кликните эти переключатели, чтобы вручную управлять ими.

Протестируйте конечный автомат, который управляет окна со степенью, запустив входные тестовые векторы и проверив, что он достигает необходимого внутреннего состояния и генерирует выход. Окно степени имеет следующие внешние входные параметры:

Каждый вход состоит из вектора с этими входами.

Сгенерируйте входные сигналы пассажира и драйвера путем отображения сигналов вверх и вниз в соответствии с этой таблицей:

Входы явно генерируют neutral событие из up и down события, сгенерированные нажатием кнопки управления окна со степенью. Входы вводятся как таблица истинности в нейтральной, вверх, вниз карте пассажира и нейтральной, вверх, вниз карте драйвера.

Экспериментальные результаты интерактивной проверки

Дело 1: Window Up.  Чтобы наблюдать поведение конечного автомата:

Случай 2: Автоматическое обновление окна.  Если вы нажимаете на переключатель окна физического пассажира в течение короткого периода времени (менее секунды), программное обеспечение активирует поведение автозапуска, и окно продолжает двигаться вверх.

Случай 3: Приоритет на стороне драйвера.  Переключатель драйвера для окна пассажира имеет приоритет над командами драйвера. Чтобы наблюдать поведение конечного автомата в этом случае:

Покрытие модели

Валидация Подсистемы Управления.  Проверьте управление дискретным событием окна с помощью инструмента model coverage. Этот инструмент помогает вам определить, в какой степени тест модели использует условные ветви контроллера. Это помогает оценить, все ли переходы в управлении дискретными событиями приняты, учитывая тест, и стали ли все предложения в условии, которое включает конкретный переход. Несколько предложений могут включать один переход, например, переход от аварийного обратного к нейтральному происходит, когда произошло или 100 такты или если достигнута конечная остановка.

Чтобы достичь полного покрытия, каждое предложение оценивает как true и false для используемых тестов. Процент переходов, которые выполняются в тесте, называется его model coverage. Покрытие модели является мерой того, насколько тщательно тест упражняет модель.

Используя программное обеспечение Simulink Coverage, можно применить следующий тест к контроллеру окна со степенью.

С помощью этого теста все коммутаторы неактивны во время 0. На регулярных шагах 1 с состояние одного или нескольких коммутаторов изменяется. Для примера через 1 с активизируется переключатель вниз драйвера. Чтобы автоматически запустить эти входные векторы, замените ручные переключатели предписанными последовательностями входов. Чтобы увидеть предварительно построенную модель:

Для slexPowerWindowCntlCoverage модель, отчет показывает, что этот тест обрабатывает 100% результатов решения от нейтрального, вверх, вниз блока карты драйвера. Однако тест достигает только 50% покрытия для нейтрального, вверх, вниз блока карты пассажира. Это покрытие означает общее покрытие для slexPowerWindowCntlCoverage составляет 45%, в то время как общий охват slexPowerWindowControl модель составляет 42%. Некоторые из факторов, способствующих уровням охвата, включают:

Увеличение покрытия модели.  Чтобы увеличить общий охват до 100%, необходимо учесть все возможные комбинации настроек драйвера, пассажира, препятствия и эндстопа. Когда вы удовлетворены поведением управления, можно создать систему окна со степенью. Для получения дополнительной информации см. «Создание модели с использованием Модельно-ориентированного проектирования».

Этот пример увеличивает покрытие модели для валидации управления дискретными событиями окна. Чтобы начать, в примере используются входы от slexPowerWindowCntlCoverage в качестве базового уровня для покрытия модели. Затем, чтобы дополнительно реализовать управление дискретным событием окна, это создает больше входных наборов. Файл электронной таблицы, inputCntlCoverageIncrease.xlsx, содержит эти входные наборы, использующие по одному входному набору на листе.

В примере slexPowerWindowSpreadsheetGeneration Служебная функция, который создает шаблон электронной таблицы из моделей контроллеров, slexPowerWindowControl, создает inputCntlCoverageIncrease.xlsx. В inputCntlCoverageIncrease.xlsxфункция использует имена блоков в моделях контроллеров в качестве имен сигналов. slexPowerWindowSpreadsheetGeneration определяет имена листов. The slexWindowSpreadsheetAddInput Служебная функция заполняет inputCntlCoverageIncrease.xlsx с данными сигнала.

Имена листов этих входных наборов и их описания:

Чтобы автоматически запустить эти входные векторы, замените входы в управление дискретным событием на блок From Spreadsheet с помощью файла, inputCntlCoverageIncrease.xlsx. Этот файл содержит несколько входных наборов. Чтобы увидеть предварительно построенную модель:

Зачем использовать модельно-ориентированное проектирование?

В Модельно-ориентированное Проектирование системная модель находится в центре процесса разработки, от разработки требований до реализации проекта и проверки. Используйте основанную на модели разработку для:

Реализация контекстной схемы: система окна со степенью

Требования, представленные в виде контекстной схемы, см. в Контекстной схеме: Система степени питания.

Создайте модель Simulink, чтобы напоминать контекстную схему.

Можно использовать схему действия управления степени окном (Activity Diagne: Степень Window Control), чтобы разложить степень контроллер окна контекстной схемы на части. Эта схема показывает входные и выходные сигналы, присутствующие в контекстной схеме для более легкого отслеживания их источников.

Реализуйте систему управления окна со степенью

Чтобы удовлетворить полным требованиям, управление окна со степенью должно работать с валидацией входов драйвера и пассажира и обнаруживать конечную остановку.

Требования, представленные как схема деятельности, смотрите в Схеме деятельности: Управление Окна степени.

Дважды кликните блок slexPowerWindowExample/power_window_control_system, чтобы открыть следующую подсистему:

Реализация схемы деятельности: валидация

Требования, представленные в качестве схем деятельности, см. в Схеме деятельности: Валидация драйвера и Схема деятельности: Валидация пассажира.

Схема действия добавляет функциональность валидации данных для команд драйвера и пассажира, чтобы гарантировать правильность операции. Например, когда окно достигает верхней части, программное обеспечение блокирует up команда. Реализация разлагает каждый процесс валидации в новых подсистемах. Рассмотрите валидацию команд драйвера (валидация команд пассажира аналогична). Проверьте, может ли модель выполнить up или down команды, согласно следующим:

Третий процесс схемы действия проверяет, чтобы программное обеспечение отправляло только одну из трех команд (neutral, up, down) контроллеру. В фактической реализации оба up и down может быть одновременно верно (для примера, из-за эффектов скачка переключателя).

Из подсистемы power_window_control_system это подсистема validate_driver_state:

Из подсистемы power_window_control_system это подсистема validate_passenger_state:

Реализация диаграммы активности: Обнаружение торца препятствия

Требования, представленные как схема деятельности, смотрите в Схеме деятельности: Обнаружение остановки препятствий.

В slexPowerWindowExample модель, блок power_window_control_system/detect_obstacle_endstop реализует эту схему деятельности в непрерывном варианте блока Variant Subsystem. Во время итераций проектирования можно добавить дополнительные варианты.

Дважды кликните slexPowerWindowExample модель power_window_control_system/detect_obstacle_endstop/Continuous/verify_position блок:

Гибридная динамическая система: комбинируйте управление дискретными событиями и непрерывный объект

После того, как вы разработали и проверили управление дискретными событиями, интегрируйте его с поведением объекта в непрерывном времени. Этот шаг является первой итерацией проекта с самой простой версией объекта.

В проекте перейдите к Files и нажмите Project. В папке configureModel запустите slexPowerWindowContinuous утилита для открытия и инициализации модели.

Блок window_system использует блок Variant Subsystem, чтобы позволить изменять уровни точности в моделировании объекта. Дважды кликните window_system/Continuous/2nd_order_window_system блок, чтобы увидеть непрерывный вариант.

Объект моделируется как дифференциальное уравнение второго порядка с пошаговыми изменениями во входе:

Эта фаза позволяет анализировать взаимодействие между поведением состояния дискретного события, его частотой дискретизации и непрерывным поведением движения окна. Существуют пороговые значения, чтобы сгенерировать систему координат окна сверху и снизу:

Дважды кликните slexPowerWindowExample моделируйте power_window_control_system/detect_obstacle_endstop/Continuous/verify_position блок, чтобы увидеть непрерывный вариант.

Когда вы запускаете slexPowerWindowContinuous configureModel утилиты, модель использует решатель непрерывного времени ode23 (Богацки-Шампайн).

Структурный анализ системы приводит к:

Структурный анализ может также включать архитектуру реализации (вне возможностей этого обсуждения).

Реализация также добавляет механизм управления, чтобы удобно переключаться между присутствием и отсутствием объекта.

Ожидаемый ответ контроллера.  Чтобы просмотреть движение окна, в Project Shortcuts, дважды кликните мышью SimHybridPlantLowOrder. Также можно запустить задачу slexPowerWindowContinuousSim.

Позиционные возможности показывают ожидаемый результат от контроллера. После 30 см модель генерирует obstacle событие и диаграмма Stateflow переходит в свою emergencyDown состояние. В этом состоянии windowDown выводится до тех пор, пока окно не опустится примерно на 10 см. Поскольку переключатель окна пассажира все еще включен, окно снова начинает двигаться вверх, и этот процесс повторяется. Остановите симуляцию и откройте возможности положения, чтобы наблюдать процесс колебаний. В случае чрезвычайной ситуации управление дискретным событием катится вниз по окну приблизительно 10 см.

Детальное моделирование степеней

После первоначального анализа управления дискретными событиями и непрерывной динамики можно использовать подробную модель объекта управления для оценки эффективности в более реалистичной ситуации. Лучше всех моделей проекта на таком уровне детализации в степень области, другими словами, как энергетические потоки. В этом может помочь несколько доменных blocksets MathWorks.

Чтобы учесть энергетические потоки, добавьте более подробный вариант, состоящий из силовой электроники и системы мультитела, к подсистеме window_system варианта.

Чтобы открыть модель и исследовать более подробный вариант объекта, в проекте запустите configureModel slexPowerWindowPowerEffects.

Дважды кликните slexPowerWindowExample model window_system/Power Effects - Visualization/detailed_window_system блок.

Степень электронную подсистему.  Модель должна усилить сигналы управления, сгенерированные контроллером дискретных событий, чтобы быть достаточно мощной, чтобы привести в действие двигатель постоянного тока, который перемещает окно.

Модули усиления моделируют это поведение. Они показывают, что переключатель либо соединяет двигатель постоянного тока с напряжением батареи, либо с землей. При обратном соединении батареи система генерирует отрицательное напряжение, и окно может двигаться вверх, вниз или оставаться неподвижным. Окно всегда вращается на максимальной степени. Другими словами, ни один контроллер двигателя постоянного тока не применяет предписанную скорость.

Чтобы увидеть реализацию, дважды кликните slexPowerWindowExample model window_system/Power Effects - Visualization/detailed_window_system/amplification_up блок.

Система мультитела.  Эта реализация моделирует окно с использованием блоков Simscape Multibody.

Чтобы увидеть реализацию привода, дважды кликните slexPowerWindowExample model window_system/Power Effects - Visualization/detailed_window_system/actuator блок.

Чтобы увидеть реализацию окна, дважды кликните slexPowerWindowExample model window_system/Power Effects - Visualization/detailed_window_system/plant блок.

Эта реализация использует блоки Simscape Multibody для тел, соединений и приводов. Модель окна состоит из:

Рисунок показывает перемещение механических деталей.

Итерация в проекте.  Важным эффектом более подробной реализации является отсутствие возможности измерения положения окна. Вместо этого модель измеряет ток двигателя постоянного тока и использует его, чтобы обнаружить торцы и увидеть, присутствует ли препятствие. Следующий этап разработки системы анализирует управление, чтобы убедиться, что оно не вызывает чрезмерной силы, когда присутствует препятствие.

В исходной системе проект удаляет препятствие и обнаружение остановки на основе положения окна и заменяет его текущей реализацией. Это также соединяет процесс с контроллером и измерения положения и силы. Чтобы отразить различные используемые сигналы, необходимо изменить определение данных. В сложение заметьте, что из-за степени эффектов модулей теперь являются усилителями.

PSPEC 1.3.1: DETECT ENDSTOP
  ENDSTOP = ARMATURE_CURRENT > ENDSTOP_MAX

PSPEC 1.3.2: DETECT OBSTACLE
  OBSTACLE = (ARMATURE_CURRENT > OBSTACLE_MAX) and MOVE_UP for 500 ms

PSPEC 1.3.3: ABSOLUTE VALUE
  ABSOLUTE_ARMATURE_CURRENT = abs(ARMATURE_CURRENT)

В этой таблице приведен дополнительный сигнал для определений данных Контекстной схемы: Системы Степени.

В этой таблице перечислены измененные сигналы для определений данных Activity Diagna: Detect Brestacle Endstop.

Чтобы увидеть подсистему окна, дважды кликните slexPowerWindowExample model window_system/Power Effects - Visualization/detailed_window_system/plant/window блок.

Реализация использует интерполяционную таблицу и добавляет шум, чтобы позволить оценить робастность управления. Чтобы увидеть реализацию подсистемы трения, дважды кликните slexPowerWindowExample model window_system/Power Effects - Visualization/detailed_window_system/plant/window/friction блок.

Оценка закона о контроле

Идеализированный непрерывный объект позволяет доступ к окну положения для endStop и obstacle генерация событий. В более реалистичной реализации модель должна генерировать эти события из доступных физических переменных. Для систем окна со степенью эта физическая переменная обычно является током якоря, Ia, двигателя постоянного тока, который управляет червячной передачей.

Когда окно движется, этот ток имеет приблизительное значение 2 A. Когда вы включаете окно, модель потребляет переходный ток, который может достигнуть значения приблизительно 10 A. Когда ток превышает 15 A, модель активирует обнаружение конечной остановки. Модель потребляет этот ток, когда скорость вращения двигателя сохраняется на почти 0, несмотря на положительное или отрицательное входное напряжение.

Обнаружить присутствие объекта сложнее в этой настройке. Поскольку безопасность ограничивает силу окна не более 100 Н, ток якоря, намного меньший 10 А, должен обнаружить объект. Однако это поведение конфликтует с переходными значениями, достигнутыми во время нормальной операции.

Реализуйте закон управления, который отключает обнаружение объектов во время достигнутых переходных значений. Теперь, когда система обнаруживает ток якоря более 2 А, она рассматривает объект как присутствующий и входит в emergencyDown состояние управления дискретным событием. Откройте окно возможностей силы (измерения указаны в ньютонах), чтобы проверить, что приложенная сила остается меньше 100 Н, когда объект присутствует, и окно меняет свою скорость на противоположную.

В действительности возможны и осуществляются гораздо более сложные законы о контроле. Для примера можно реализовать методы обучения на основе нейронной сети feedforward управления, чтобы эмулировать характеристики трения каждого отдельного транспортного средства и изменения с течением времени.

Визуализация системы в движении

Если у вас установлено программное обеспечение Simulink 3D Animation, можно просмотреть геометрию системы в движении через мир виртуальной реальности. Если блок VR Sink еще не открыт, в slexPowerWindowExample/window_world/Simulink_3D_Animation View дважды кликните блок VR Sink.

Чтобы симулировать модель с жестким решателем:

Реалистичное измерение якоря

Ток якоря, используемый в управлении окна со степенью, является идеальным значением, которое доступно из-за использования модели привода. В более реалистичной ситуации компоненты сбора данных должны измерить это текущее значение.

Чтобы включить компоненты сбора данных, добавьте более реалистичный вариант измерения к подсистеме window_system варианта. Этот реалистичный вариант измерения содержит блок формирования сигнала, в котором ток выводится на основе измерения напряжения.

Чтобы открыть модель и сконфигурировать реалистичное измерение, в проекте запустите задачу configureModel slexPowerWindowRealisticArmature.

Чтобы просмотреть содержимое блока Realistic Armature - Communications Protocol, дважды кликните SlexPowerWindowExample модель window_system/Realistic якорь - коммуникационные Protocol/detailed_window_system_with_DAQ.

Напряжение измерения находится в области значений аналого-цифрового преобразователя (АЦП), который дискретизирует на основе заданного количества бит. Вы должны масштабировать полученное значение на основе значения резистора и области значений АЦП.

Включите эти операции в качестве расчетов с фиксированной точкой. Для достижения необходимого разрешения при заданной области значений требуется 16 бит вместо 8.

Изучите тот же сценарий:

Протоколы связи

Подобна степень окну выхода управлению, оборудование должно генерировать события входа. В этом случае оборудование являются оконными переключателями в дверных и центральных панелях управления. Локальные процессоры генерируют эти события и затем передают их контроллеру окна через шину CAN.

Для включения этих событий добавьте вариант, содержащий вход от шины CAN и компонентов switch, которые генерируют события, доставляемые на шине CAN, в подсистемы переключателя драйвера и варианта переключателя пассажира. Чтобы открыть модель и сконфигурировать коммуникационные протоколы CAN, запустите задачу configureModel, slexPowerWindowCommunicationProtocolSim.

Чтобы увидеть реализацию подсистемы switch, дважды кликните блок slexPowerWindowExample/driver_switch/Communication Protocol/Driver window control switch.

Наблюдайте структуру, которая очень похожа на систему управления окном. Эта структура содержит:

Можно добавить эффекты связи, такие как другие системы, использующие шину CAN, и более реализм, подобный описанным фазам. Каждая фаза позволяет анализировать контроллер дискретных событий во все более реалистичной ситуации. Когда у вас достаточно деталей, вы можете автоматически сгенерировать код контроллера для любой конкретной целевой платформы.