Automotive Power Window System

Part 3 - Verifying the Controller Behavior Against Requirements


This is part three of a three-part case study that models an automotive passenger power window system using Model-Based Design with Simulink, Stateflow, SimMechanics, and SimPowerSystems. We designed the controller from a set of requirements, then built a plant model to test the controller. We can now verify that the controller meets the requirements. You can easily apply this design approach to other electromechanical or mechatronic systems such as those found in automotive body electronics applications.

Using the Signal Builder block in Simulink, we can build test-cases and simulate the model with the different cases to see if the system outputs meet the requirements. With blocks from the Simulink Model Verification library you can also verify that your outputs stay within certain bounds. To review the sections on control design or plant modeling, use the links below:

Jump back to Part 1 - Designing the Controller

Jump back to Part 2 - Building the Plant Model

Contents

Simulating the System and Verifying Requirements Are Met

Figure 1 shows the complete power window system implemented in Simulink. Some of the of the blocks will be described in this part of the case study.

Figure 1: Complete power window system modeled in Simulink. Click image to see enlarged view.

System Requirements

The performance requirements for the system are recapped below. These were used to design the controller, which uses fault detection algorithms to protect the window hardware and any obstacles in the window's path. It also uses mode logic to decide when the window should be moved and in which direction.

 1) Window must be fully opened or closed within 5[s].
 2) The motor must shut off after 5[s] of continuous movement in any
 direction, as a fail safe protection for the window mechanism, motor,
 and drive.
 3) The window must start moving no later than 0.2[s] after the
 command is issued.
 4) The window must stop when it reaches a fully opened or fully
 closed position.
 5) If the up or down command is issued for a duration of 0.2[s] -
 1[s], the window must be fully opened or closed, unless interrupted by
 a new window command or an obstacle.  This requirement represents the
 automatic-up and automatic-down capability of the power window.
 6) The window must be able to detect an obstacle with a force less
 than 100[N].
 7) The window must be lowered by approximately 10[cm] if an obstacle
 is detected.
 8) Obstacle detection has priority over both driver-side and
 passenger-side controls.
 9) Driver-side controls have priority over passenger-side controls.

Inputs for Testing

Five external inputs affect the power window system. The first four inputs correspond to the power window buttons available to the driver and passenger, and are listed below:

The final external input represents an obstacle such as a box with fragile contents, which can be introduced into the window's path.

Three test cases with different input combinations are constructed using the Signal Builder block. These test cases allow us to verify that the model meets specified performance criteria.

Test Case 1

The input set shown in Figure 2 tests requirements 1,2,3, and 4.

Figure 2: Test case 1. Click image to see enlarged view.

The sections below show the relevant output signals and explain how the requirements are met. The horizontal axes represent time, the vertical axes depend on what is being viewed.

Requirement 1 - Window must be fully opened or closed within 5[s].

We can see in Figure 3 that the window starts moving up at approximately T = 1[s] and stops moving by T=5.5[s]. The distance traveled is shown in meters on the vertical axis. The distance traveled matches the distance between the open and closed positions.

Figure 3: Window position vs. time. Click image to see enlarged view.

Requirements 2 and 4 - The motor must shut off after 5[s] of continuous movement in any direction, as a fail safe protection for the window mechanism, motor, and drive. The window must stop when it reaches a fully opened or fully closed position. (We will test the fully opened case.)

Figure 4 shows armature current on the vertical axis. We can see that the armature current increases at about T = 1[s], starts subsiding at about T = 5.5[s], and subsides by T = 6[s]. T = 5.5[s] corresponds to the time when the window reaches its end point and stops moving (requirement 4). T = 6[s] corresponds to the point when the motor shuts off.

Figure 4: Motor armature current vs. time. Click image to see enlarged view.

Requirement 3 - The window must start moving no later than 0.2[s] after the command is issued.

Figure 5 shows the window position on the vertical axis. Looking closely at the time range from T = 0.5[s] to 1.5[s] we can see that the window starts moving less than 0.2 seconds after the input signal which occurs at T = 1[s]

Figure 5: Window position vs. time. Click image to see enlarged view.

Test Case 2

The input set shown in Figure 6 tests requirement 5.

Figure 6: Test case 2. Click image to see enlarged view.

The section below shows the window position over time and explains how this requirement is met.

Requirement 5 - If the up or down command is issued for a duration of 0.2[s] - 1[s], the window must be fully opened or closed, unless interrupted by a new window command or an obstacle. This requirement represents the automatic-up and automatic-down capability of the power window.

In Figure 7 we can see the window moves up and stops because of the first 'up' command. At T = [2] it receives a down command that lasts less than 0.2 [s], so it only moves down a very small distance. The next command at T = 4.5 [s] is an 'up' command lasting 0.5 [s]. This is in the desired range for auto movement and results in 'auto-up' movement until T = 7.6[s] when it hits an obstacle. Obstacle behavior will be verified in a later section.

Figure 7: Window position vs. time. Click image to see enlarged view.

Test Case 3

The input set shown in Figure 8 tests requirements 6,7,8, and 9.

Figure 8: Test case 3. Click image to see enlarged view.

Requirements 6 and 7 - The window must be able to detect an obstacle with a force less than 100[N]. The window must be lowered by approximately 10[cm] if an obstacle is detected.

The requirement on force can be checked with an assertion block, labeled 'check_requirement_6' in the diagram of the system. This will send a message to the MATLAB workspace any time the limit of 100[N] is violated. In Figure 9, in which force is represented on the vertical axis, we can see that the force on the window does not exceed 100[N] during the time period from T = 2[s] to T = 6[s] when the obstacle is present. Figure 10, in which the window position is represented on the vertical axis, shows us that the window lowers 10[cm] after the obstacle is encountered at T = 3.5[s], satisfying requirement 7.

Figure 9: Force vs. time. Click image to see enlarged view.

Figure 10: Window position vs. time. Click image to see enlarged view.

Requirements 8 and 9 - Obstacle detection has priority over both driver-side controls and passenger-side controls. Driver-side controls have priority over passenger-side controls.

In Figure 10, we can see that the window moves down after detecting the obstacle, even though the driver is commanding the window to move up. This satisfies requirement 8. At T = 6[s] the passenger issues a down command, making the window move down. At T = 7[s] the driver issues an up command making the window move up, and overriding the passenger command. This satisfies requirement 9.

Conclusion and Next Steps

We have shown that the power window system adheres to the requirements as tested. Additional test cases can be used to test for better coverage. Using Model-Based Design, as we've done here, you can design and test your controller with a plant model in a closed loop. The level of fidelity of your plant model will depend on your system requirements. Once you have verified that your controller meets the system requirements, you can test it in real time in the different configurations explained below.

Rapid Control Prototyping

Using Simulink Coder and xPC Target, you can generate C code from your controller and run the compiled code in real time on a PC-compatible system. You can then connect this prototype controller to an actual power window system using standard PC I/O cards. This would allow more realistic real-time testing.

On-Target Rapid Prototyping and Deployment

Using Embedded Coder, you can generate, test, and deploy production C code on real-time production ECUs. You can test the code in an on-target rapid prototyping setup using an appropriate ECU such as the Embedded Target for Motorola MPC555 as your target processor.

Hardware-in-the-Loop Simulation

Using Simulink Coder and xPC Target you can generate C code from the plant model and run the compiled code on a PC-compatible system, so that you can simulate the plant in real time while you connect it to either a prototype controller or ECU.

Additional Information

To read more about Model-Based Design, including user stories:

The key products used in this part of the case study include: