Power Window
Automobiles use electronics for control operations such as:
Opening and closing windows and sunroof
Adjusting mirrors and headlights
Locking and unlocking doors
These systems are subject to stringent operation constraints. Failures can cause dangerous and possibly life-threatening situations. As a result, careful design and analysis are needed before deployment.
This example focuses on the design of a power window system of an automobile, in particular, the passenger-side window. A critical aspect of this system is that it cannot exert a force of more than 100 N on an object when the window closes. When the system detects such an object, it must lower the window by about 10 cm.
As part of the design process, the example considers:
Quantitative requirements for the window control system, such as timing and force requirements
System requirements, captured in activity diagrams
Data definitions for the signals used in activity diagrams
Other aspects of the design process that this example contains are:
Managing the components of the system
Building the model
Validating the results of system simulation
Generating code
MATLAB® and Simulink® support Model-Based Design for embedded control design, from initial specification to code generation. The power window control project shows how you can use MathWorks® tools and the Model-Based Design process to go from concept through implementation for an automobile power window system. It uses projects to organize the files and other model components.
Power Window Control Project
This example shows how to use a project to model a power window system for an automobile. The project uses Model-Based Design and these large-scale modeling techniques.
Model blocks to separate the hierarchy into separate models.
Variant Subsystems blocks to model and switch between different design choices.
Libraries to capture algorithms for reuse in variant subsystems.
Projects to manage the files required for the system development.
Design Requirements
In this example, consider the passenger-side power window system of an automobile. This system can never exert a force of more than 100 N on an object when closing the window.
When the model detects such an object, the model must lower the window by about 10 centimeters.
For more information on the design requirements, see Power Window.
Explore the Project
Upon visual inspection of the project, you can see features used to organize the example. These features are used to organize the project:
Folders
File Classification
Shortcuts
Folders
The project is organized into these folders:
configureModel
- MATLAB® files that control the main system model variant configurationdata
- Images required by the projecthmi
- Files that animate the power window responsemodel
- Main system model, controller model, models for testing the controller, and libraries that support these modelstask
- MATLAB files that simulate the model for the different model configurations and generate coverage reports for the controllerutilities
- MATLAB files to initialize the model, to generate spreadsheet input, to add data to the generated spreadsheet, and manage the project environment at startup and shutdown
File Classification
Files in Projects have different classifications visible in the Labels pane. Each label describes the specific role a file contributes to the body of the project.
Configuration
- Files that configure the project or model.PrjConfig
- Files that configure the project by adding its files to the path at startup and removing them at shutdownDesignConfig
- Files that determine which model configuration is active at a given timeDesign
- Main system model and its referenced control modelDesignSupport
- Files such as libraries, data, and model simulationSimulation
- Files that simulate the model for a specific configurationTest
- Control coverage, the control interaction, and the test harness modelsVisualization
- Files that animate the motion of the power window
Shortcuts
Project shortcuts provide quick access to project files that are used most often. Some shortcuts contain general tasks, such as adding the project to the path at startup and removing it at shutdown. In addition, project shortcut groups help organize the shortcuts.
Interactive Testing - Files used for interactive testing of the controller
Main Model - File for top-level Simulink model
Model Coverage - Files used for model coverage of the controller
Simulation - Files used for simulation of model variant configurations
Explore Simulink Models in Project
The Simulink models for this project are located in the model
folder.
Main System Model
Models for Testing
Main System Model
The main system model is slexPowerWindowExample
. This model consists of driver_switch
and passenger_switch
subsystem blocks, which generate the inputs to the power_window_control_system
block. The power_window_control_system
block validates the states of the passenger and driver inputs. This block also determines if obstacle is blocking the path of the window. The referenced controller produces the window motion command signals sent to the active variant of the window system. The window_system
block output is the feedback to the control system block.
To visualize the results of simulation, the Simulation Data Inspector logs the output data and Simulink 3D Animation™ animates the motion of the window.
Model Variants
The main system model in this project uses Variant Subsystem blocks to allow for multiple implementations within a subsystem. You can change the active implementation programmatically prior to simulation. The main model contains four Variant Subsystem blocks, each with variant choices that can be programmatically modified. Those four variant subsystems are:
slexPowerWindowExample/driver_switch
slexPowerWindowExample/passenger_switch
slexPowerWindowExample/window_system
slexPowerWindowExample/power_window_control_system/detect_obstacle_endstop
Each variant choice is associated with a variant control. The variant choice is active when its variant control evaluates to true
.
You can control the combinations of variant choices to create model variant configurations using the files under the DesignConfig
classification. Model variant configurations include:
Power Window Controller Hybrid System Model
Power Window Controller and Detailed Plant Model
Power Window Controller With Data Acquisition Effects
Power Window Controller With Controller Area Network (CAN) Communication
Power Window Controller Hybrid System Model
This model variant uses Stateflow® and Simulink to model both discrete event reactive behavior and continuous time behavior. The models uses a low-order plant model to validate the roll-up and roll-down behavior. You can simulate this variant configuration using the SimHybridPlantLowOrder
shortcut. This shortcut activates only the variant subsystem corresponding to this model configuration. Since this model does not take into account power effects, the only output logged is position. The Simulation Data Inspector displays the logged position data.
Power Window Controller and Detailed Plant Model
This model variant shows a more detailed plant model that includes power effects in the electrical and mechanical domains. This variant validates that the force exerted by the window on a trapped object never exceeds 100 N. This model variant requires Simscape™ Multibody™ and Simscape™ Electrical™ licenses. You can simulate this variant configuration using the SimHybridPlantPowerEffects
shortcut. Unlike the Power Window Controller Hybrid System Model, this variant configuration takes into account the power effects. The Simulation Data Inspector displays the logged data from armature current, position, and force exerted by the power window.
Power Window Controller With Data Acquisition Effects
This model variant shows additional effects due to implementation that affect the control. The phenomena included are signal conditioning to measure the armature current and quantization of the measurement. This model variant requires Simscape Multibody, Simscape Electrical, DSP System Toolbox™, and Fixed-Point Designer™ licenses. You can simulate this variant configuration using the SimHybridPlantPowerEffects+ControlDAQEffects
shortcut. As with the Power Window Controller and Detailed Plant Model, the Simulation Data Inspector displays the logged data from armature current, position, and force exerted by the power window.
Power Window Controller With CAN Communication
This model variant shows the use of a CAN to communicate the commands to control window movement. The switches that may be located in the center console of the vehicle and that produce the commands are included in this model variant. This model variant requires Simscape Multibody, Simscape Electrical, DSP System Toolbox, and Fixed-Point Designer licenses. You can simulate this variant configuration on a machine running windows OS using the SimCANCommunication
shortcut.
Models for Testing
To test the state machine that controls the power window, you can run the project shortcuts for testing. Model shortcuts for testing the controller include:
InteractiveExample
CoverageExample
IncreaseCoverageExample
InteractiveExample
This model shortcut opens the model slexPowerWindowCntlInteract
. This model contains the power window controller, which is a state machine. This model also contains inputs to the controller that are selected with manual switch blocks.
The power window controller has four external inputs:
Passenger Input
input consists of a vector with three elements:
neutral
: Passenger control switch is not depressed.up
: Passenger control switch generates the up signal.down
: Passenger control switch generates the down signal.
Driver Input
input consists of a vector with three elements:
neutral
: Driver control switch is not depressed.up
: Driver control switch generates the up signal.down
: Driver control switch generates the down signal.
Window Frame Endstops
input consists of a vector with two elements:
0
: Window moves freely between top or bottom.1
: Window is stuck at the top or bottom because of physical limitations.
Obstacle Present
input consists of a vector with two elements:
0
: window moves freely between top or bottom1
: window has obstacle within its frame
You can interactively test the controller by simulating the model and selecting the desired combination of inputs via the manual switch blocks. After selecting inputs, you can verify the internal controller state and controller output against the desired result for the specific set of inputs.
CoverageExample
This model shortcut opens the model slexPowerWindowCntlCoverage
. The model contains a state machine power window controller with Repeating Sequence block inputs.
You can use the Simulink Coverage Model Coverage tool to validate the discrete event control of the window. The Model Coverage tool determines the extent to which a model test case exercises the conditional branches of the controller. The tool evaluates whether all transitions in the discrete event control are taken given the test case. The tool also evaluates whether all clauses in a condition that enables a particular transition have become true. One transition may be enabled by multiple clauses, for example, the transition from emergency back to neutral occurs when either 100 ticks have occurred or when the endstop is reached.
IncreaseCoverageExample
This model shortcut opens the model slexPowerWindowCntlCoverageIncrease
. This model contains the power window controller that is a state machine. This model also contains a From Spreadsheet block that provides multiple sets of inputs to the controller. These input sets combine with the one from the CoverageExample model to exercise more of the logic in the power window controller:
Logged
: Logged from theCoverageExample
.LoggedObstacleOffEndStopOn
: Logged from theCoverageExample
with ability to hit endstop.LoggedObstacleOnEndStopOff
: Logged from theCoverageExample
with obstacle in window.LoggedObstacleOnEndStopOn
: Logged from theCoverageExample
with obstacle in window and ability to hit endstop.DriverLoggedPassengerNeutral
: Logged from theCoverageExample
for only the driver. Passenger takes no action.DriverDownPassengerNeutral
: Driver lowering window. Passenger takes no action.DriverUpPassengerNeutral
: Driver raising window. Passenger takes no action.DriverAutoDownPassengerNeutral
: Driver lowering window for 1 second (auto-down). Passenger takes no action.DriverAutoUpPassengerNeutral
: Driver raising window for 1 second (auto-up). Passenger takes no action.PassengerAutoDownDriverNeutral
: Passenger lowering window for 1 second (auto-down). Driver takes no action.PassengerAutoUpDriverNeutral
: Passenger raising window for 1 second (auto-up). Driver takes no action.
The model coverage shortcut GenerateIncreasedCoverage
uses the multiple input sets with the Simulink Coverage Model Coverage tool to validate the discrete event control of the window and generate a coverage report for the multiple input sets.
Quantitative Requirements
Quantitative requirements for the control are:
The window must fully open and fully close within 4 s.
If the up is issued for between 200 ms and 1 s, the window must fully open. If the down command is issued for between 200 ms and 1 s, the window must fully close.
The window must start moving 200 ms after the command is issued.
The force to detect when an object is present is less than 100 N.
When closing the window, if an object is in the way, stop closing the window and lower the window by approximately 10 cm.
Capturing Requirements in Activity and Context Diagrams
Activity diagrams help you graphically capture the specification and understand how the system operates. A hierarchical structure helps with analyzing even large systems. At the top level, a context diagram describes the system environment and its interaction with the system under study in terms of data exchange and control operations. Then you can decompose the system into an activity diagram with processes and control specifications (CSPEC).
The processes guide the hierarchical decomposition. You specify each process using another activity diagram or a primitive specification (PSPEC). You can specify a PSPEC in a number of representations with a formal semantic, such as a Simulink block diagram. In addition, context diagrams graphically capture the context of system operation. Use the data definitions for the specifications.
Context Diagram: Power Window System
The figure represents the context diagram of a power window system. The square boxes capture the environment, in this case, the driver, passenger, and window. Both the driver and passenger can send commands to the window to move it up and down. The controller infers the correct command to send to the window actuator (e.g., the driver command has priority over the passenger command). In addition, diagram monitors the state of the window system to establish when the window is fully opened and closed and to detect if there is an object between the window and frame.
The circle (also known as a bubble) represents the power window controller. The circle is the graphical notation for a process. Processes capture the transformation of input data into output data. Primitive process might also generate. CSPECs typically consist of combinational or sequential logic to infer output control signals from input control.
For implementation in the Simulink environment, see Implement Context Diagram: Power Window System.
Power Window System Data Definitions
Signal | Information Type | Continuous/ Discrete | Data Type | Values |
---|---|---|---|---|
DRIVER_COMMAND | Data | Discrete | Aggregate |
|
PASSENGER_COMMAND | Data | Discrete | Aggregate |
|
WINDOW_POSITION | Data | Continuous | Real | 0 to 0.4 m |
MOVE_UP | Control | Discrete | Boolean |
|
MOVE_DOWN | Control | Discrete | Boolean |
|
Activity Diagram: Power Window Control
The power window control consists of three processes and a CSPEC. Two processes
validate the driver and passenger input to ensure that their input is meaningful given the
state of the system. For example, if the window is completely opened, the MOVE
DOWN
command does not make sense. The remaining process detects if the window
is completely opened or completely closed and if an object is present. The CSPEC takes the
control signals and infers whether to move the window up or down (e.g., if an object is
present, the window moves down for about one second or until it reaches an
endstop).
Power Window Control Data Definitions
Signal | Information Type | Continuous/ Discrete | Data Type | Values |
---|---|---|---|---|
DRIVER_COMMAND | Data | Discrete | Aggregate |
|
PASSENGER_COMMAND | Data | Discrete | Aggregate |
|
WINDOW_POSITION | Data | Continuous | Real | 0 to 0.4 m |
MOVE_UP | Control | Discrete | Boolean |
|
MOVE_DOWN | Control | Discrete | Boolean |
|
Activity Diagram: Validate Driver
Each process in the VALIDATE DRIVER activity chart is primitive and specified by the
following PSPEC. In the MAKE EXCLUSIVE PSPEC, for safety reasons the
DOWN
command takes precedence over the UP
command.
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)
Validate Driver Data Definitions
Signal | Information Type | Continuous/ Discrete | Data Type | Values |
---|---|---|---|---|
DRIVER_COMMAND | Data | Discrete | Aggregate |
|
PASSENGER_COMMAND | Data | Discrete | Aggregate |
|
WINDOW_POSITION | Data | Continuous | Real | 0 to 0.4 m |
MOVE_UP | Control | Discrete | Boolean |
|
MOVE_DOWN | Control | Discrete | Boolean |
|
Activity Diagram: Validate Passenger
The internals of the VALIDATE PASSENGER process are the same as the VALIDATE DRIVER process. The only difference is the different input and output.
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)
For implementation in the Simulink environment, see Activity Diagram: Validate Passenger.
Validate Passenger Data Definitions
Signal | Information Type | Continuous/ Discrete | Data Type | Values |
---|---|---|---|---|
NEUTRAL | Data | Discrete | Boolean |
|
UP | Data | Discrete | Boolean |
|
DOWN | Data | Discrete | Boolean |
|
CHECKED_UP | Data | Discrete | Boolean |
|
CHECKED_DOWN | Data | Discrete | Boolean |
|
Activity Diagram: Detect Obstacle Endstop
The third process in the POWER WINDOW CONTROL activity diagram detects the presence of
an obstacle or when the window reaches its top or bottom (ENDSTOP
). The
detection mechanism is based on the armature current of the window actuator. During normal
operation, this current is within certain bounds. When the window reaches its top or
bottom, the electromotor draws a large current (more than 15 A or less than –15 A) to try
and sustain its angular velocity. Similarly, during normal operation the current is about
2 A or –2 A (depending on whether the window is opening or closing). When there is an
object, there is a slight deviation from this value. To keep the window force on the
object less than 100 N, the control switches to its emergency operation when it detects a
current that is less than –2.5 A. This operations is necessary only when the window is
rolling up, which corresponds to a negative current in the particular wiring of this
model. The DETECT OBSTACLE ENDSTOP activity diagram embodies this functionality.
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
For implementation in the Simulink environment, see Activity Diagram: Detect Obstacle Endstop.
Detect Obstacle Endstop Data Definitions
Signal | Information Type | Continuous/ Discrete | Data Type | Values |
---|---|---|---|---|
ENDSTOP_MIN | Data | Constant | Real | 0.0 m |
ENDSTOP_MAX | Data | Constant | Real | 0.4 m |
OBSTACLE_MAX | Data | Constant | Real | 0.3 m |
Implement Activity Diagram: Power Window Control
This topic describes the high-level discrete-event control specification for a power window control.
You can model the discrete-event control of the window with a Stateflow® chart. A Stateflow chart is a finite state machine with hierarchy and parallelism. This state machine contains the basic states of the power window system: up, auto-up, down, auto-down, rest, and emergency. It models the state transitions and accounts for the precedence of driver commands over the passenger commands. It also includes emergency behavior that activates when the software detects an object between the window and the frame while moving up.
The initial Simulink model for the power window control, slexPowerWindowControl
,
is a discrete-event controller that runs at a given sample rate.
In this implementation, open the power window control subsystem and observe that the Stateflow chart with the discrete-event control forms the CSPEC, represented by the tilted thick bar in the bottom right corner. The detect_obstacle_endstop subsystem encapsulate the threshold detection mechanisms.
The discrete-event control is a Stateflow model that extends the state transition diagram notion with hierarchy and parallelism. State changes because of passenger commands are encapsulated in a super state that does not correspond to an active driver command.
Consider the control of the passenger window. The passenger or driver can move this window up and down.
This state machine contains the basic states of the power window system: up, auto-up, down, auto-down, rest, and emergency.
Interactive Testing
Control Input
The slexPowerWindowCntlInteract
model includes this control input
as switches. Double-click these switches to manually operate them.
Test the state machine that controls a power window by running the input test vectors and checking that it reaches the desired internal state and generates output. The power window has the following external inputs:
Passenger input
Driver input
Window up or down
Obstacle in window
Each input consists of a vector with these inputs.
Passenger Input
Element | Description |
---|---|
neutral | Passenger control switch is not depressed. |
up | Passenger control switch generates the up signal. |
down | Passenger control switch generates the down signal. |
Driver Input
Element | Description |
---|---|
neutral | Driver control switch is not depressed. |
up | Driver control switch generates the up signal. |
down | Driver control switch generates the down signal. |
Window Up or Down
Element | Description |
---|---|
0 | Window moves freely between top or bottom. |
1 | Window is stuck at the top or bottom because of physical limitations. |
Obstacle in Window
Element | Description |
---|---|
0 | Window moves freely between top or bottom. |
1 | Window has obstacle in the frame. |
Generate the passenger and driver input signals by mapping the up and down signals according to this table:
Inputs | Outputs | |||
---|---|---|---|---|
up | down | up | down | neutral |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The inputs explicitly generate the neutral
event from the
up
and down
events, generated by pressing a power
window control switch. The inputs are entered as a truth table in the passenger neutral,
up, down map and the driver neutral, up, down map.
Case 1: Window Up
To observe the state machine behavior:
Open the
slexPowerWindowCntlInteract
model.Run the simulation and then double-click the passenger up switch.
If you press the physical window switch for more than one second, the window moves up until the up switch is released (or the top of the window frame is reached and the
endstop
event is generated).Double-click the selected passenger up switch to release it.
Simulate the model.
Setting the endstop switch generates the endstop event.
Case 2: Window Auto-Up
If you press the physical passenger window up switch for a short period of time (less than a second), the software activates auto-up behavior and the window continues to move up.
Press the physical passenger window up switch for a short period of time (less than a second).
Ultimately, the window reaches the top of the frame and the software generates the
endstop
event. This event moves the state machine back to its neutral state.Simulate the model.
Case 3: Driver-Side Precedence
The driver switch for the passenger window takes precedence over the driver commands. To observe the state machine behavior in this case:
Run the simulation, and then move the system to the
passenger up
state by double-clicking the passenger window up switch.Double-click the driver down switch.
Simulate the model.
Notice how the state machine moves to the driver control part to generate the window down output instead of the window up output.
Double-click the driver control to driver up. Double-click the driver down switch.
The driver window up state is reached, which generates the window up output again, i.e.,
windowUp = 1
.To observe state behavior when an object is between the window and the frame, double-click the obstacle switch.
Simulate the model.
On the next sample time, the state machine moves to its
emergencyDown
state to lower the window a few inches. How far the software lowers the window depends on how long the state machine is in theemergencyDown
state. This behavior is part of the next analysis phase.If a driver or passenger window switch is still active, the state machine moves into the up or down states upon the next sample time after leaving the emergency state. If the obstacle switch is also still active, the software again activates the emergency state at the next sample time.
Model Coverage
Validation of the Control Subsystem
Validate the discrete-event control of the window using the model coverage tool. This tool helps you determine the extent to which a model test case exercises the conditional branches of the controller. It helps evaluate whether all transitions in the discrete-event control are taken, given the test case, and whether all clauses in a condition that enables a particular transition have become true. Multiple clauses can enable one transition, e.g., the transition from emergency back to neutral occurs when either 100 ticks have occurred or if the endstop is reached.
To achieve full coverage, each clause evaluates to true and false for the test cases used. The percentage of transitions that a test case exercises is called its model coverage. Model coverage is a measure of how thoroughly a test exercises a model.
Using Simulink Coverage™ software, you can apply the following test to the power window controller.
Position | Step | ||||||
---|---|---|---|---|---|---|---|
0 | 1 | 2 | 3 | 4 | 5 | 6 | |
Passenger up | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Passenger down | 0 | 0 | 0 | 1 | 0 | 1 | 1 |
Driver up | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
Driver down | 0 | 1 | 0 | 0 | 1 | 1 | 0 |
With this test, all switches are inactive at time 0. At regular 1 s steps, the state of one or more switches changes. For example, after 1 s, the driver down switch becomes active. To automatically run these input vectors, replace the manual switches by prescribed sequences of input. To see the preconstructed model:
Open the
slexPowerWindowCntlCoverage
model.Simulate the model to generate the Simulink Coverage coverage report.
For the slexPowerWindowCntlCoverage
model, the report reveals that
this test handles 100% of the decision outcomes from the driver neutral, up, down map
block. However, the test achieves only 50% coverage for the passenger neutral, up, down
map block. This coverage means the overall coverage for
slexPowerWindowCntlCoverage
is 45% while the overall coverage for the
slexPowerWindowControl
model is 42%. A few of the contributing
factors for the coverage levels are:
Passenger up block does not change.
Endstop and obstacle blocks do not change.
Increase Model Coverage
To increase total coverage to 100%, you need to take into account all possible combinations of driver, passenger, obstacle, and endstop settings. When you are satisfied with the control behavior, you can create the power window system. For more information, see Create Model Using Model-Based Design.
This example increases the model coverage for the validation of the discrete-event
control of the window. To start, the example uses inputs from
slexPowerWindowCntlCoverage
as a baseline for the model coverage.
Next, to further exercise the discrete-event control of the window, it creates more input
sets. The spreadsheet file, inputCntlCoverageIncrease.xlsx
, contains
these input sets using one input set per sheet.
In the example, the slexPowerWindowSpreadsheetGeneration
utility
function, which creates a spreadsheet template from the controller model,
slexPowerWindowControl
, creates the
inputCntlCoverageIncrease.xlsx
. In
inputCntlCoverageIncrease.xlsx
, the function uses the block names in
the controller model as signal names.
slexPowerWindowSpreadsheetGeneration
defines the sheet names. The
slexWindowSpreadsheetAddInput
utility function populates
inputCntlCoverageIncrease.xlsx
with signal data.
The sheet names of these input sets and their descriptions are:
Sheet Name | Description |
---|---|
| Inputs logged from
|
| Inputs logged from |
| Inputs logged from |
| Inputs logged from |
| Inputs logged from |
| Driver is putting down window and passenger takes no action |
| Driver is putting up window and passenger takes no action |
| Driver is putting down window for one second (auto-down) and passenger takes no action |
| Driver is putting up window for one second (auto-up) and passenger takes no action |
| Passenger is putting down window for one second (auto-down) and driver takes no action |
| Passenger is putting up window for one second (auto-up) and driver takes no action |
To automatically run these input vectors, replace the inputs to the discrete-event
control with the From Spreadsheet block using the file,
inputCntlCoverageIncrease.xlsx
. This file contains the multiple input
sets. To see the preconstructed model:
Open the
slexPowerWindowCntlCoverageIncrease
model.To generate the Simulink Coverage coverage report for multiple input set, double click the Run Coverage subsystem in the model.
For the
slexPowerWindowCntlCoverageIncrease
model, the report reveals that using multiple input sets has successfully raised the overall coverage for theslexPowerWindowControl
model from 42% to 78%. Coverage levels are less than 100% because of missing input sets for:Passenger up state
Driver up and down states
Passenger automatic down and automatic up states
Create Model Using Model-Based Design
Implement Context Diagram: Power Window System
For requirements presented as a context diagram, see Context Diagram: Power Window System.
Create a Simulink model to resemble the context diagram.
Place the plant behavior into one subsystem.
Create two subsystems that contain the driver and passenger switches.
Add a control mechanism to conveniently switch between the presence and absence of the object.
Put the control in one subsystem.
Connect the new subsystems.
To see an implementation of this model, open the
slexPowerWindowExample
model.
You can use the power window control activity diagram (Activity Diagram: Power Window Control) to decompose the power window controller of the context diagram into parts. This diagram shows the input and output signals present in the context diagram for easier tracing to their origins.
Implement Power Window Control System
To satisfy full requirements, the power window control must work with the validation of the driver and passenger inputs and detect the endstop.
For requirements presented as an activity diagram, see Activity Diagram: Power Window Control.
Double-click the slexPowerWindowExample/power_window_control_system block to open the following subsystem:
Implement Activity Diagram: Validate
For requirements presented as activity diagrams, see Activity Diagram: Validate Driver and Activity Diagram: Validate Passenger.
The activity diagram adds data validation functionality for the driver and passenger
commands to ensure correct operation. For example, when the window reaches the top, the
software blocks the up
command. The implementation decomposes each
validation process in new subsystems. Consider the validation of the driver commands
(validation of the passenger commands is similar). Check if the model can execute the
up
or down
commands, according to the
following:
The model allows the
down
command only when the window is not completely opened.The model allows the
up
command only when the window is not completely closed and no object is detected.
The third activity diagram process checks that the software sends only one of the
three commands (neutral
, up
,
down
) to the controller. In an actual implementation, both
up
and down
can be simultaneously true (for
example, because of switch bouncing effects).
From the power_window_control_system subsystem, this is the validate_driver_state subsystem:
From the power_window_control_system subsystem, this is the validate_passenger_state subsystem:
Implement Activity Diagram: Detect Obstacle Endstop
For requirements presented as an activity diagram, see Activity Diagram: Detect Obstacle Endstop.
In the slexPowerWindowExample
model, the
power_window_control_system/detect_obstacle_endstop block implements this activity diagram
in the continuous variant of the Variant Subsystem block. During design iterations, you
can add additional variants.
Double-click the slexPowerWindowExample
model
power_window_control_system/detect_obstacle_endstop/Continuous/verify_position
block.
Hybrid Dynamic System: Combine Discrete-Event Control and Continuous Plant
After you have designed and verified the discrete-event control, integrate it with the continuous-time plant behavior. This step is the first iteration of the design with the simplest version of the plant.
In the project, navigate to Files and click
Project. In the configureModel folder, run the
slexPowerWindowContinuous
utility to open and initialize the
model.
The window_system block uses the Variant Subsystem block to allow for varying levels of fidelity in the plant modeling. Double-click the window_system/Continuous/2nd_order_window_system block to see the continuous variant.
The plant is modeled as a second-order differential equation with step-wise changes in its input:
When the Stateflow chart generates
windowUp
, the input is 1.When the Stateflow chart generates
windowDown
, the input is –1.Otherwise, the input is 0.
This phase allows analysis of the interaction between the discrete-event state behavior, its sample rate, and the continuous behavior of the window movement. There are threshold values to generate the window frame top and bottom:
endStop
Event when an obstacle is present, that is,
obstacle
Other events
Double-click the slexPowerWindowExample
model
power_window_control_system/detect_obstacle_endstop/Continuous/verify_position block to
see the continuous variant.
When you run the slexPowerWindowContinuous
configureModel utility,
the model uses the continuous time solver ode23 (Bogacki-Shampine).
A structure analysis of a system results in:
A functional decomposition of the system
Data definitions with the specifics of the system signals
Timing constraints
A structure analysis can also include the implementation architecture (outside the scope of this discussion).
The implementation also adds a control mechanism to conveniently switch between the presence and absence of the object.
Expected Controller Response. To view the window movement, in Project Shortcuts, double-click
SimHybridPlantLowOrder
. Alternatively, you can run the task
slexPowerWindowContinuousSim
.
The position scope shows the expected result from the controller. After 30 cm, the
model generates the obstacle
event and the Stateflow chart moves into its emergencyDown
state. In this
state, windowDown
is output until the window lowers by about 10 cm.
Because the passenger window up switch is still on, the window starts moving up again
and this process repeats. Stop the simulation and open the position scope to observe the
oscillating process. In case of an emergency, the discrete-event control rolls down the
window approximately 10 cm.
Detailed Modeling of Power Effects
After an initial analysis of the discrete-event control and continuous dynamics, you can use a detailed plant model to evaluate performance in a more realistic situation. It is best to design models at such a level of detail in the power domain, in other words, as energy flows. Several domain-specific MathWorks blocksets can help with this.
To take into account energy flows, add a more detailed variant consisting of power electronics and a multibody system to the window_system variant subsystem.
To open the model and explore the more detailed plant variant, in the project, run
configureModel slexPowerWindowPowerEffects
.
Double-click the slexPowerWindowExample
model window_system/Power
Effects - Visualization/detailed_window_system block.
Power Electronics Subsystem. The model must amplify the control signals generated by the discrete-event controller to be powerful enough to drive the DC motor that moves the window.
The amplification modules model this behavior. They show that a switch either connects the DC motor to the battery voltage or ground. By connecting the battery in reverse, the system generates a negative voltage and the window can move up, down, or remain still. The window is always driven at maximum power. In other words, no DC motor controller applies a prescribed velocity.
To see the implementation, double-click the
slexPowerWindowExample
model window_system/Power Effects -
Visualization/detailed_window_system/amplification_up block.
Multibody System. This implementation models the window using Simscape™ Multibody™ blocks.
To see the actuator implementation, double-click the
slexPowerWindowExample
model window_system/Power Effects -
Visualization/detailed_window_system/actuator block.
To see the window implementation, double-click the
slexPowerWindowExample
model window_system/Power Effects -
Visualization/detailed_window_system/plant block.
This implementation uses Simscape Multibody blocks for bodies, joints, and actuators. The window model consists of:
A worm gear
A lever to move the window holder in the vertical direction
The figure shows how the mechanical parts move.
Iterate on the Design. An important effect of the more detailed implementation is that there is no window position measurement available. Instead, the model measures the DC motor current and uses it to detect the endstops and to see if an obstacle is present. The next stage of the system design analyzes the control to make sure that it does not cause excessive force when an obstacle is present.
In the original system, the design removes the obstacle and endstop detection based on the window position and replaces it with a current-based implementation. It also connects the process to the controller and position and force measurements. To reflect the different signals used, you must modify the data definition. In addition, observe that, because of power effects, the units are now amps.
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)
This table lists the additional signal for the Context Diagram: Power Window System data definitions.
Context Diagram: Power Window System Data Definition Changes
Signal | Information Type | Continuous/ Discrete | Data Type | Values |
---|---|---|---|---|
ARMATURE_CURRENT | Data | Continuous | Real | –20 to 20 A |
This table lists the changed signals for the Activity Diagram: Detect Obstacle Endstop data definitions.
Activity Diagram: Detect Obstacle Endstop Data Definition Changes
Signal | Information Type | Continuous/ Constant | Data Type | Values |
---|---|---|---|---|
ABSOLUTE_ARMATURE_CURRENT | Data | Continuous | Real | 0 to 20 A |
ENDSTOP_MAX | Data | Constant | Real | 15 A |
OBSTACLE_MAX | Data | Constant | Real | 2.5 A |
To see the window subsystem, double-click the
slexPowerWindowExample
model window_system/Power Effects -
Visualization/detailed_window_system/plant/window block.
The implementation uses a lookup table and adds noise to allow evaluation of the
control robustness. To see the implementation of the friction subsystem, double-click
the slexPowerWindowExample
model window_system/Power Effects -
Visualization/detailed_window_system/plant/window/friction block.
Control Law Evaluation
The idealized continuous plant allows access to the window position for
endStop
and obstacle
event generation. In the more
realistic implementation, the model must generate these events from accessible physical
variables. For power window systems, this physical variable is typically the armature
current, Ia
, of the DC motor that drives the worm gear.
When the window is moving, this current has an approximate value of 2 A. When you switch the window on, the model draws a transient current that can reach a value of approximately 10 A. When the current exceeds 15 A, the model activates endstop detection. The model draws this current when the angular velocity of the motor is kept at almost 0 despite a positive or negative input voltage.
Detecting the presence of an object is more difficult in this setup. Because safety concerns restrict the window force to no more than 100 N, an armature current much less than 10 A should detect an object. However, this behavior conflicts with the transient values achieved during normal operation.
Implement a control law that disables object detection during achieved transient
values. Now, when the system detects an armature current more than 2 A, it considers an
object to be present and enters the emergencyDown
state of the
discrete-event control. Open the force scope window (measurements are in newtons) to check
that the force exerted remains less than 100 N when an object is present and the window
reverses its velocity.
In reality, far more sophisticated control laws are possible and implemented. For example, you can implement neural-network-based learning feedforward control techniques to emulate the friction characteristic of each individual vehicle and changes over time.
Visualization of the System in Motion
If you have Simulink
3D Animation™ software installed, you can view the geometrics of the system in motion via
a virtual reality world. If the VR Sink block is not yet open, in the
slexPowerWindowExample/window_world/Simulink_3D_Animation View
model,
double-click the VR Sink block.
To simulate the model with a stiff solver:
In a project, run the task,
slexPowerWindowPowerEffectsSim
. This batch job sets the solver to ode23tb (stiff/TR-BDF2).In the
slexPowerWindowExample
model passenger_switch/Normal block, set the passenger up switch to on.In the
slexPowerWindowExample
model driver_switch/Normal block, set the driver up switch to off.Simulate the model.
Between 10 ms and 1 s in simulation time, switch off the slexPowerWindowExample/passenger_switch/Normal block passenger up switch to initiate the auto-up behavior.
Observe how the window holder starts to move vertically to close the window. When the model encounters the object, it rolls the window down.
Double-click the
slexPowerWindowExample
model passenger_switch/Normal block driver down switch to roll down the window completely and then simulate the model. In this block, at less than one second simulation time, switch off the driver down switch to initiate the auto-down behavior.When the window reaches the bottom of the frame, stop the simulation.
Look at the position measurement (in meters) and at the armature current (Ia) measurement (in amps).
Note
The absolute value of the armature current transient during normal behavior does not exceed 10 A. The model detects the obstacle when the absolute value of the armature current required to move the window up exceeds 2.5 A (in fact, it is less than –2.5 A). During normal operation, this is about 2 A. You might have to zoom into the scope to see this measurement. The model detects the window endstop when the absolute value of the armature current exceeds 15 A.
Variation in the armature current during normal operation is due to friction that is included by sensing joint velocities and positions and applying window specific coefficients.
Realistic Armature Measurement
The armature current as used in the power window control is an ideal value that is accessible because of the use of an actuator model. In a more realistic situation, data acquisition components must measure this current value.
To include data acquisition components, add the more realistic measurement variant to the window_system variant subsystem. This realistic measurement variant contains a signal conditioning block in which the current is derived based on a voltage measurement.
To open a model and configure the realistic measurement, in the project, run the
configureModel task slexPowerWindowRealisticArmature
.
To view the contents of the Realistic Armature - Communications Protocol block,
double-click the SlexPowerWindowExample
model window_system/Realistic
Armature - Communications Protocol/detailed_window_system_with_DAQ.
The measurement voltage is within the range of an analog-to-digital converter (ADC) that discretizes based on a given number of bits. You must scale the resulting value based on the value of the resistor and the range of the ADC.
Include these operations as fixed-point computations. To achieve the necessary resolution with the given range, 16 bits are required instead of 8.
Study the same scenario:
In the slexPowerWindowExample/passenger_switch/Normal block, set the passenger up switch.
Run the simulation.
After some time, in the slexPowerWindowExample/passenger_switch/Normal block, switch off the passenger up switch.
When the window has been rolled down, click the slexPowerWindowExample/passenger_switch/Normal block driver down switch.
After some time, switch off the slexPowerWindowExample/passenger_switch/Normal block driver down switch.
When the window reaches the bottom of the frame, stop the simulation.
Zoom into the armature_current scope window and notice the discretized appearance.
Communication Protocols
Similar to the power window output control, hardware must generate the input events. In this case, the hardware is the window control switches in the door and center control panels. Local processors generate these events and then communicate them to the window controller via a CAN bus.
To include these events, add a variant containing input from a CAN bus and switch
components that generate the events delivered on the CAN bus to the driver switch and
passenger switch variant subsystems. To open the model and configure the CAN communication
protocols, run the configureModel task,
slexPowerWindowCommunicationProtocolSim
.
To see the implementation of the switch subsystem, double-click the slexPowerWindowExample/driver_switch/Communication Protocol/driver window control switch block.
Observe a structure that is very similar to the window control system. This structure contains a:
Plant model that represents the control switch
Data acquisition subsystem that includes, among other things, signal conditioning components
Control module to map the commands from the physical switch to logical commands
CAN module to post the events to the vehicle data bus
You can add communication effects, such as other systems using the CAN bus, and more realism similar to the described phases. Each phase allows analysis of the discrete-event controller in an increasingly realistic situation. When you have enough detail, you can automatically generate controller code for any specific target platform.
Automatic Code Generation for Control Subsystem
You can generate code for the designed control model,
slexPowerWindowExample
.
Display the sample rates of the controller. In the Simulink Editor, on the Debug tab, select Information Overlays > Sample Time > Colors. Observe that the controller runs at a uniform sample rate.
Right-click the power_window_control_system block and select C/C++ Code > Build This Subsystem.
References
Mosterman, Pieter J., Janos Sztipanovits, and Sebastian Engell, “Computer-Automated Multiparadigm Modeling in Control Systems Technology,” IEEE Transactions on Control Systems Technology, Vol. 12, Number 2, 2004, pp. 223–234.