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

Фиксация требований в диаграммах действий и контекста

Диаграммы операций помогают графически зафиксировать спецификацию и понять, как работает система. Иерархическая структура помогает анализировать даже большие системы. На верхнем уровне контекстная диаграмма описывает системную среду и ее взаимодействие с исследуемой системой с точки зрения операций обмена данными и управления. Затем можно разложить систему на схему операций с процессами и контрольными спецификациями (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 А. Эти операции необходимы только при накатывании окна, что соответствует отрицательному току в конкретной проводке данной модели. Схема активности DETECT DISPORDER 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 - это конечный автомат с иерархией и параллелизмом. Этот конечный автомат содержит основные состояния системы окна питания: up, auto-up, down, auto-down, rest и emergency. Он моделирует переходы состояний и учитывает приоритет команд водителя над командами пассажира. Это также включает аварийное поведение, которое активируется, когда программное обеспечение обнаруживает объект между окном и рамкой при движении вверх.

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

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

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

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

Этот конечный автомат содержит основные состояния системы окна питания: up, auto-up, down, auto-down, rest и emergency.

Интерактивное тестирование

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

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

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

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

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

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

Случай 1: Окно вверх.  Для наблюдения за поведением конечного автомата:

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

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

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

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

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

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

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

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

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

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

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

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

Для автоматического запуска этих входных векторов замените входные данные элемента управления дискретным событием на блок «Из электронной таблицы» с помощью файла. inputCntlCoverageIncrease.xlsx. Этот файл содержит несколько наборов входных данных. Для просмотра предварительно структурированной модели:

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

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

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

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

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

Можно использовать диаграмму операций управления окном мощности (Схема операций: Управление окном мощности) для разложения контроллера окна мощности контекстной диаграммы на части. На этой диаграмме показаны входные и выходные сигналы, представленные на схеме контекста, для упрощения трассировки их источников.

Внедрение системы управления окном питания

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

Требования, представленные в виде диаграммы активности, см. в разделе Диаграмма активности: Управление окном питания.

Дважды щелкните блок 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 модели:

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

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

В проекте перейдите в папку «Файлы» и нажмите «Проект». В папке 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 utility, в модели используется постоянный решатель времени ode23 (Bogacki-Shampine).

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

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

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

Ожидаемый ответ контроллера.  Для просмотра перемещения окна в окне «Ярлыки проекта» дважды щелкните SimHybridPlantLowOrder. Кроме того, можно запустить задачу. slexPowerWindowContinuousSim.

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

Детальное моделирование силовых эффектов

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

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

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

Дважды щелкните значок slexPowerWindowExampleмодель window_system/Power Эффекты - блок Visualization/detailed_window_system.

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

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

Для просмотра внедрения дважды щелкните значок slexPowerWindowExampleмодель window_system/Power Эффекты - блок Visualization/detailed_window_system/amplification_up.

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

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

Для просмотра реализации окна дважды щелкните значок slexPowerWindowExampleмодель window_system/Power Эффекты - блок 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)

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

В этой таблице перечислены измененные сигналы для определений данных «Схема активности: Обнаружение конца препятствия».

Для просмотра оконной подсистемы дважды щелкните значок slexPowerWindowExampleмодель window_system/Power Эффекты - блок Visualization/detailed_window_system/plant/window.

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

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

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

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

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

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

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

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

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

Для моделирования модели с помощью жесткого решателя:

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

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

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

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

Чтобы просмотреть содержимое блока «Реалистичный каркас - коммуникационный протокол», дважды щелкните значок SlexPowerWindowExample модель window_system/Realistic Арматура - связь Protocol/detailed_window_system_with_DAQ.

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

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

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

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

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

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

Чтобы видеть внедрение подсистемы выключателя, дважды щелкните по slexPowerWindowExample/driver_switch/Communication блоку выключателя контроля за окном Протокола/водителя.

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

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