state behavior, its sample rate, and the continuous behavior of the window
movement. There are 
<a href="matlab:powerwindowscript(`highlight thresholds`);">threshold values</a>
established to generate the window frame
top and bottom, i.e., <font face="Courier">endStop</font>, events and the event when an
obstacle is present, i.e., <font face="Courier">obstacle</font>.
</p>

<p>
Before simulation, a continuous time solver has to be selected. You can
do so by selecting the <font face="Courier">Simulation</font> menu, then the
<font face="Courier">Simulation parameters</font> item
and next the <font face="Courier">Solver</font> tab.
You can change the solver parameter there or 
change to the Bogacki-Shampine solver by clicking
<a href="matlab:powerwindowscript(`ode23`);">here</a>.
</p>

<p>
A structured analysis of a system results in a functional decomposition
of the system, a data dictionary with the specifics of the system signals,
and the timing constraints. Another aspect is the implementation architecture,
which is not discussed here.
</p>

<h4><a name="Activity Diagrams"></a>Activity Diagrams</h4>

<p>
Activity diagrams are a means to graphically capture the specification and
gain understanding of system operation. A hierarchical structure facilitates
analysis of even large systems. At the top-level, a <i>context diagram</i>
describes the system environment its interaction with the system under study
in terms of (i) data exchange and (ii) control operations.
The system is then decomposed into an activity diagram with processes and
control specifications (called a CSPEC).
The processes guide the hierarchical decomposition:
Each process is specified by another activity diagram or a primitive
specification (called a PSPEC). A PSPEC can be given in a number of 
representations with a formal semantic, e.g., a S<font size=-1>IMULINK</font>
block diagram.
</p>

<p>
The following figure represents the context diagram of a power window system.
The square boxes capture the environment. In this case, the driver, passenger
and the 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 be sent
to the window actuator (e.g., the driver command has priority over the passenger
command). In addition, the state of the window system is monitored to establish
when the window is fully opened and closed and to detect whether an object is
present between the window and frame.    
</p>
<p>
<b>CONTEXT DIAGRAM:</b> POWER WINDOW SYSTEM
<blockquote>
    <blockquote>
        <p>
		<img src="context.jpg" width="438" height="275" alt="" border="2" align="">
		</p>
    </blockquote>
</blockquote>
</p>

<p>
The power window controller is depicted by a circle (also referred to as `bubble`).
This is the graphical notation for a process.
Processes capture the transformation of input data into output data.
In case of a primitive process, control may also be generated. CSPECs typically
consist of combinational or sequential logic to infer output control signals
from input control.
</p>

<p>
Let`s rearrange the SIMULINK model</a> to resemble the activity
diagram by
<ul>
<li><a href="matlab:powerwindowscript(`context plant`);"><b>combining the plant behavior</b></a>
into one subsystem,
</li>
<li><a href="matlab:powerwindowscript(`context switches`);"><b>combining the driver and passenger switches</b></a>
in two subsystems,
</li>
<li><a href="matlab:powerwindowscript(`context control`);"><b>putting the control in one subsystem</b></a>, and
</li>
<li><a href="matlab:powerwindowscript(`context connect`);"><b>connecting the new subsystems</b></a>.
</li>
<li><a href="matlab:powerwindowscript(`resize for context diagram`);">resize for context diagram</a>.
</li>
</ul>
</p>

<p>
Now, the power window controller of the context diagram can be decomposed into
parts by using an activity diagram as shown below.
The input and output signals present in the context diagram are shown here again
so they can be easily traced to their origins.
</p>
<p>
<b>AD 1:</b> POWER WINDOW CONTROL
<blockquote>
    <blockquote>
        <p>
		<img src="AD1.jpg" width="567" height="346" alt="" border="2" align="">
		</p>
    </blockquote>
</blockquote>
</p>

<p>
The power window control consists of three processes and a CSPEC.
Two of the processes validate the driver and passenger input to ensure their
input is meaningful given the state of the system (e.g., if the window
is completely opened, the `window down` command is not sensible).
The remaining process detects whether the window is completely opened
or completely closed and whether an object may be present.
The CSPEC takes the control signals and infers whether the window
should be moved up or down (e.g., if an object is present, the window
should be moved down for about one second or until an endstop is reached).
</p>

<p>
In SIMULINK,
<a href="matlab:powerwindowscript(`AD1`);">open the power window control</a>
subsystem and note that the
Stateflow chart with the discrete event control forms the CSPEC, represented
by the tilted thick bar in the bottom right corner. 
The threshold detection mechnisms are encapsulated in the
<a href="matlab:powerwindowscript(`position detection`);">detect_obstacle_endstop</a>
subsystem.
</p>   

<p>
Now,
<a href="matlab:powerwindowscript(`include data validation`);"><b>add data validation functionality</b></a>
for the driver and passenger commands
to ensure correct operation (e.g., when the 
window has reached its top, the up command should be blocked). 
Each of the validation process can be decomposed in new subsystems.
Let`s have a look at
the validation of the driver`s commands (validation of the passenger`s commands
is similar). First, it has to be checked whether the `up` or `down` commands
can be executed. The `down` command is only allowed when the window is
not completely opened. The `up` command is only allowed when the window
is not completely closed and no object is detected.
The third process ensures that only one of the three commands
(`neutral`, `up`, `down`) is sent to the controller. Note that in an 
actual implementation,
it may well be possible that both `up` and `down` are true simultaneously
(e.g., because of switch bouncing effects).  
</p> 

<p>
<b>AD 1.1:</b> VALIDATE DRIVER
<blockquote>
    <blockquote>
        <p>
		<img src="AD11.jpg" width="525" height="325" alt="" border="2" align="">
		</p>
    </blockquote>
</blockquote>
</p>

<p>
Each of the processes in the VALIDATE DRIVER activity chart is
primitive and specified by a PSPEC. These PSPECs are given below
according to the previous discussion. Note that in the MAKE EXCLUSIVE
PSPEC the `down` command takes precedence over the `up` command,
for safety reasons.
</p>

<p>
<table border=0 cellspacing=0 cellpadding=5 bgcolor="#ffe4b0" width="100%">
<tr>
<td colspan=4>
<div class=PSPEC>
<b>PSPEC 1.1.1:</b> CHECK DOWN
</div>
</td></tr><tr><td width="5"></td><td valign="top" width="1">
CHECKED_DOWN
</td><td valign="top" width="1">
=
</td><td halign="left">
DOWN <b>and</b> <b>not</b> RESET
</td></tr>
</table>
</p>

<p>
<table border=0 cellspacing=0 cellpadding=5 bgcolor="#ffe4b0" width="100%">
<tr>
<td colspan=4>
<div class=PSPEC>
<b>PSPEC 1.1.2:</b> CHECK UP
</div>
</td></tr><tr><td width="5"></td><td valign="top" width="1">
CHECKED_UP
</td><td valign="top" width="1">
=
</td><td halign="left">
UP <b>and</b> <b>not</b> RESET
</td></tr>
</table>
</p>

<p>
<table border=0 cellspacing=0 cellpadding=5 bgcolor="#ffe4b0" width="100%">
<tr>
<td colspan=4>
<div class=PSPEC>
<b>PSPEC 1.1.3:</b> MAKE EXCLUSIVE
</div>
</td></tr><tr><td width="5"></td><td valign="top" width="1">
VALIDATED_DOWN
</td><td valign="top" width="1">
=
</td><td halign="left">
CHECKED_DOWN
</td></tr><tr><td width="5"></td><td valign="top" width="1">
VALIDATED_UP
</td><td valign="top" width="1">
=
</td><td halign="left">
CHECKED_UP <b>and</b> <b>not</b> CHECKED_DOWN
</td></tr><tr><td width="5"></td><td valign="top" width="1">
VALIDATED_NEUTRAL
</td><td valign="top" width="1">
=
</td><td halign="left">
(NEUTRAL <b>and</b> <b>not</b> (CHECKED_UP <b>and</b> <b>not</b> CHECKED_DOWN))
<b>or</b> <b>not</b> (CHECKED_UP <b>or</b> CHECKED_DOWN)
</td></tr>
</table>
</p>

<p>
The PSPECS are given by
</p>

<p>
The internals of the VALIDATE PASSENGER process are exactly the same as the
VALIDATE DRIVER process. The only difference between the two are the 
different input and output. The VALIDATE PASSENGER is given below.
</p>

<p>
<b>AD 1.2:</b> VALIDATE PASSENGER
<blockquote>
    <blockquote>
        <p>
		<img src="AD12.jpg" width="525" height="325" alt="" border="2" align="">
		</p>
    </blockquote>
</blockquote>
</p>

<p>
<table border=0 cellspacing=0 cellpadding=5 bgcolor="#ffe4b0" width="100%">
<tr>
<td colspan=4>
<div class=PSPEC>
<b>PSPEC 1.2.1:</b> CHECK DOWN
</div>
</td></tr><tr><td width="5"></td><td valign="top" width="1">
CHECKED_DOWN
</td><td valign="top" width="1">
=
</td><td halign="left">
DOWN <b>and</b> <b>not</b> RESET
</td></tr>
</table>
</p>

<p>
<table border=0 cellspacing=0 cellpadding=5 bgcolor="#ffe4b0" width="100%">
<tr>
<td colspan=4>
<div class=PSPEC>
<b>PSPEC 1.2.2:</b> CHECK UP
</div>
</td></tr><tr><td width="5"></td><td valign="top" width="1">
CHECKED_UP
</td><td valign="top" width="1">
=
</td><td halign="left">
UP <b>and</b> <b>not</b> RESET
</td></tr>
</table>
</p>

<p>
<table border=0 cellspacing=0 cellpadding=5 bgcolor="#ffe4b0" width="100%">
<tr>
<td colspan=4>
<div class=PSPEC>
<b>PSPEC 1.2.3:</b> MAKE EXCLUSIVE
</div>
</td></tr><tr><td width="5"></td><td valign="top" width="1">
VALIDATED_DOWN
</td><td valign="top" width="1">
=
</td><td halign="left">
CHECKED_DOWN
</td></tr><tr><td width="5"></td><td valign="top" width="1">
VALIDATED_UP
</td><td valign="top" width="1">
=
</td><td halign="left">
CHECKED_UP <b>and</b> <b>not</b> CHECKED_DOWN
</td></tr><tr><td width="5"></td><td valign="top" width="1">
VALIDATED_NEUTRAL
</td><td valign="top" width="1">
=
</td><td halign="left">
(NEUTRAL <b>and</b> <b>not</b> (CHECKED_UP <b>and</b> <b>not</b> CHECKED_DOWN))
<b>or</b> <b>not</b> (CHECKED_UP <b>or</b> CHECKED_DOWN)
</td></tr>
</table>
</p>

<p>
The third process in the POWER WINDOW CONTROL activity diagram is the one
to detect 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
electro-motor 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 an object is present, there is a slight deviation
from this value. To ensure the window force on the object is less than 
100 [N], the control switches to its emergency operation when a current
is detected that is less than -2.5 [A] (this is only necessary in case
the window is rolling up, which corresponds to a negative current in the
particular wiring of this model). This functionality is embodied by the
DETECT OBSTACLE ENDSTOP activity diagram and the process specifications
given below.
</p>

<p>
<b>AD 1.3:</b> DETECT OBSTACLE ENDSTOP
<blockquote>
    <blockquote>