This is part one 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 will design the controller from a set of requirements, build a plant model to test the controller, and finally 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.
The power window system enables you to determine how the passenger-side window responds when the driver or passenger uses their window controls. One of the goals of this exercise is to design a power window system at a very low cost. To do this we use current sensors to provide our sensor inputs. No position sensors are used in this design.
This first part looks at the design of the event-driven controller from a set of requirements. The controller is implemented with Stateflow. You may choose to jump ahead to the sections on plant modeling and controller verification from the links below.
Jump ahead to Part 2 - Building the Plant Model
Figure 1 shows the complete power window system implemented in Simulink. Each of the blocks will be described in the three parts of the case study.
Figure 1: Complete power window system modeled in Simulink. Click image to see enlarged view.
The performance requirements for the system are listed below. These are used to design the control system, 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.
The following sections provide a description of the event-driven controller that has been implemented in Stateflow. Figure 2 shows the complete high-level Sstateflow chart.
Figure 2: Controller implemented in Stateflow. Click image to see enlarged view.
NOTE: Bold text in the description below indicates a reference to a specific state, truth table, or graphical function.
The Stateflow chart used to implement the power window controller must determine the proper window motion based upon the following input values and the specified system requirements. The up and down motion of the power window switches are treated as separate inputs to the controller.
Input 1: Driver-side window switch pressed up
Input 2: Driver-side window switch pressed down
Input 3: Passenger-side window switch pressed up
Input 4: Passenger-side window switch pressed down
Input 5: Motor armature current (sensor input)
The four window control buttons are represented by logical data values 0/1 signifying on/off. The motor armature current is represented by a fixed-point data value. With these input values, the controller determines whether the window moves up, down, or not at all.
The system monitors the load on the motor to detect obstacles. When the window encounters an obstacle, the applied force on the window increases the load on the motor and hence the armature current. By monitoring for sharp increases in the armature current, the system can detect obstacles in the window's path.
The chart has a parent state named Logic, which contains four exclusive states called Stop, Move, EmergencyDown, and EndStop. As the names suggest, these handle the control logic for the window to stop, move, move down in an emergency, or detect the endstops. Events based on time or user inputs cause changes in state. The time-based events, called temporal logic events, invoke safety-critical features for obstacle detection and hardware protection. The user-driven events are as follows.
1) UP: Window up event
2) DOWN: Window down event
3) NEUTRAL: Window hold event
4) ENDSTOP: End of range detected event when window is fully open or closed
5) OBSTACLE: Window obstacle event
A brief description of how these events occur as well as the four major states follows.
The events in this controller are broadcast from the truth table called switches and the graphical function called obstacles (in the state Move). The purpose of switches is to broadcast the UP, DOWN, and NEUTRAL events based upon a button or combination of buttons pressed. The purpose of the obstacles function is to decide if an obstacle is present or if the window is fully open or fully closed. This decision is based upon the magnitude and rate of change of the armature current. If an obstacle is present, the OBSTACLE event is broadcast, and if the window reaches a fully open or fully closed position, the ENDSTOP event is broadcast. A diagram of the truth table is shown in Figure 3. As you can see, the driver's inputs take precedence over the passenger's. This basically means that if the driver and passenger both press their window buttons, the passenger input will be ignored.
Figure 3: Switches truth table.
The final graphical function, called go, does not broadcast any events to the Stateflow chart. The purpose of go is to set the chart output values, which correspond to the direction of window motion. For example, if the controller decides that the window should move up, its passes the value 1 to the first output port. Likewise, the value 1 is sent to the second output port if the controller decides that the window should move down.
The Stop state is active whenever the window is not moving. This is the first state that is activated when the simulation begins, since by default the window is not moving at the start of simulation. A transition from Stop to Move occurs if a validated UP or DOWN event is broadcast. An UP event is invalid if it occurs when the window is already fully closed. Likewise, a DOWN event is invalid if it occurs when the window is fully open.
Figure 4: Algorithm showing how a transition from Stop to Move occurs. Click image to see enlarged view.
The Move state is active whenever the window is in motion. This state implements several of the power window requirements related to object detection and automated window movement. At each time step, Move checks whether the window has run into an obstacle or reached a fully open or fully closed position. If an object is detected, the OBSTACLE event is broadcast and a state transition from Move to EmergencyDown occurs. If an end position is detected, the ENDSTOP event is broadcast and a state transition from Move to EndStop occurs.
Move has two parallel states named Direction and Mode. Parallel states can be active simultaneously. The Direction state checks whether the window is in motion and traveling up or down. The Mode state implements the auto-up and auto-down capability of the window. If a window button is held for a duration from 0.2 to 1 second in either direction, the window should automatically open or close completely, unless interrupted by a new window command or an obstacle. If the user presses a window button for the duration specified above, the Auto state is entered. If the button is pressed for a duration that does not land within this range, the Manual state is entered. If the Manual state is active, a transition from Move to Stop is executed when the user releases the button.
Figure 5: Algorithms for transitioning out of the Move state. Click image to see enlarged view.
In the EmergencyDown state, the windowmoves down about 10 [cm] if an obstacle is detected. When this state is activated, the go function is called to move the window down.
Figure 6: Emergency down algorithm. Click image to see enlarged view.
EndStop first determines whether the window is fully opened or closed, then commands the window to move in the opposite direction for a fraction of a second to relieve the force on the window. Once the window has moved the required amount, a state transition from EndStop to Stop occurs.
Figure 7: Algorithm for endstop detection. Click image to see enlarged view.
Now that we have designed a controller we can do some basic open-loop testing on the controller using switches, constants, and slider blocks. This is effective to a point, but to really verify that your controller will work with the hardware, you need to model the complete closed-loop system. To do this you need an accurate plant model. Part 2 will look at a multidomain approach to model the electromechanical components of the plant. Once you have an accurate plant model, you can test your controller in a closed-loop simulation or generate C code for the whole system (plant and controller) and test it in real time in a rapid prototyping and/or hardware-in-the-loop simulation setup.
Continue to Part 2 - Building the Plant Model
To read more about Model-Based Design, including user stories:
The key products used in part one of this case study include: