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

Получение требований в схемах действия и контекста

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

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

Схема контекста: система окна со стеклоподъемником

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

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

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

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

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

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

Схема действия: подтвердите драйвер

Каждый процесс в ПОДТВЕРЖДАТЬ диаграмме операций ДРАЙВЕРА примитивен и задан следующим 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 смотрите Реализацию Схемы Действия: Подтвердить.

Схема действия: подтвердите пассажира

Внутренности ПОДТВЕРЖДАТЬ процесса PASSENGER совпадают с ПОДТВЕРЖДАТЬ процессом ДРАЙВЕРА. Единственной разницей является различный ввод и вывод.

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 см. Схему Действия: Подтвердите Пассажира.

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

Третий процесс в схеме действия УПРАВЛЕНИЯ ОКНОМ СО СТЕКЛОПОДЪЕМНИКОМ обнаруживает присутствие препятствия или когда окно достигает своей верхней части или нижней части (ENDSTOP). Механизм обнаружения основан на токе якоря привода окна. Во время нормального функционирования этот ток в определенных границах. Когда окно достигает своей верхней части или нижней части, электродвигатель чертит большой ток (больше чем 15 А или меньше чем-15 А), чтобы попытаться выдержать его скорость вращения. Точно так же во время нормального функционирования ток составляет приблизительно 2 А или-2 А (в зависимости от того, открывается ли окно или закрывается). Когда существует объект, существует небольшое отклонение от этого значения. Чтобы сохранить силу окна на объекте меньше чем 100 Н, управление переключается на свою неотложную операцию, когда это обнаруживает ток, который меньше-2.5 А. Это операции необходимы только, когда окно свертывается, который соответствует отрицательному току в конкретном проводном соединении этой модели. ОБНАРУЖИТЬ схема действия OBSTACLE 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 см. Схему Действия: Обнаружьте Препятствие Endstop.

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

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

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

Для связанной схемы действия см. Схему Контекста: Система Окна со стеклоподъемником.

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

Для связанной схемы действия см. Схему Действия: Подтвердите Драйвер.

Для связанной схемы действия см. Схему Действия: Подтвердите Пассажира.

Для связанной схемы действия см. Схему Действия: Обнаружьте Препятствие Endstop.

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

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

Реализация схемы действия: управление окном со стеклоподъемником

Эта тема описывает высокоуровневую спецификацию управления дискретного события для управления окном со стеклоподъемником.

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

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

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

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

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

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

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

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

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

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

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

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

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

Случай 1: Окно.  Наблюдать поведение конечного автомата:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация схемы действия: обнаружьте препятствие Endstop

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

В slexPowerWindowExample модель, блок power_window_control_system/detect_obstacle_endstop реализует эту схему действия в непрерывном варианте Различного блока 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 см.

Подробное моделирование эффектов степени

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

Эта таблица приводит измененные сигналы для Схемы Действия: Обнаружьте Препятствие определения данных Endstop.

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

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

Оценка закона о надзоре

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

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

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

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

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

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

Если вам установили программное обеспечение 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.

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

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

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

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

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

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

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

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

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