$\begin{figure}\vbox{\include{epsf} }\end{figure}$

Requirements Analysis Document
(Final Version)

Joseph Mongiat, Binh Lai, Matthew Martin, Travis Ratcliff, Hong Suk Jung

Anti-Lock Braking System
ABS 4

December 7, 2001

1. Introduction

Increasing safety is of primary importance when designing modern vehicles. This interest is the driving force behind control features such as adaptive cruise control, night vision technology, air bag technology, and anti-lock braking systems. All of these systems exploit embedded software to reduce cost, and allow complex control with respect to a given system. The following requirements document is for an anti-lock braking system. This document is divided into introduction, overview, requirements, uml-analysis, and promela specifications sections.

This document will address the overall problem to be solved as stated in the problem description. This section will cover a software controlled anti-lock braking system that will sense the deceleration rate per wheel, and allow the driver of the vehicle to maintain steering control at maximum brake force. Controlling the fluid pressure on each wheel's fluid pump will perform this action. The system will control a valve that allows pressure to be added to the wheel's calipers, or pressure to be decreased off the wheel's calipers.

This document will also address anti-lock braking systems functionality in the overview section. Upon a non-skidding braking situation, the anti-lock braking system will not be engaged, and conventional braking shall be performed. Once the controller detects that skidding is imminent, or the wheelspeed is approaching zero rapidly, the ABS will start to remove brake fluid to alleviate braking pressure just enough to prevent skidding, and then provide braking pressure by replacing the fluid once the 'skidding' is removed. This pulsing on reducing and adding pressure will continue as long as the system detects the skidding scenario. The driver will not be responsible for any action other then steering, and applying the brakes; no manual pumping is necessary.

This document will address an outline of the necessities for completion of the problem's solution in the requirements section. This is a detailed list of constraints that the system will perform under. This will address the speed sensing rate for formulation of the deceleration rate, maximum pumping rate for the ABS system, and failure response. The details of each requirement will be examined in the requirements analysis.

The pictorial explanation of the problem's solution will be examined in the UML Analysis section. The Unified Modeling Language(UML), will be used to model the solution to the problem. The diagrams that will be examined are as follows: use cases diagram, class diagram, state diagram, and sequences diagrams. The use case diagram is used to show how the driver, speed sensor, and brake fluid reservoirs interact with the system to accomplish the desired goal of preventing skidding in the braking action. The class diagram will be used to show the static view of the objects that will be used to solve the separate software tasks, and how they are associated with one another. The state diagram and sequence diagrams will look at the dynamic aspect of the classes' relationships. The sequence diagram will show the message passing and timing information between these classes that the system will rely on to accomplish the desired goals.

1.1 Problem Description

A common safety feature of today's automobile is the implementation of an anti-lock braking system. The system is designed to prevent the wheel lock-up associated with hard braking situations, which can lead to loss of steering control and dangerous skidding. The ABS system works by alleviating brake fluid pressure for a given wheel's caliper and diverting it temporarily toward a secondary reservoir. This action happens when the deceleration rate, for a given wheel, passes a threshold point. Once this correction is made, the appropriate fluid pressure is re-established on that wheel. This oscillation of backing off pressure during hard braking (when skid is imminent) allows the driver to use full braking force, and still achieve maximum steering control.

1.2 Motivation

The primary motivation of ABS is to increase the driver's ability to control the direction of the vehicle under hard braking conditions. This translates into a decrease in serious accidents that are related to loss of vehicle during hard braking situations. This also translates into an attractive selling point for auto-makers. The secondary motivation falls under manufacturing and repair costs. Using embedded micro-controller software allows for software upgrades in the future if needed. This is extremely beneficial in controlling upgrade and re-design costs. Implementing the control system into software reduces moving parts, which reduces repair and assembly costs.

Summary of Motivations:
- Improved Safety: Control of braking vehicle
- Allows Upgrades: Re-flash memory, new e-prom, new controller board.
- Reduced Costs: Less moving parts, fewer parts to assemble.

2. Overview

ABS was first invented and applied in the aircraft industry and then was introduced to automobile industry in the early 1970's. However, it had not been used popularly until the middle of the 1980's due to technical difficulties and high cost. ABS functions in place of the traditional brake system at times of wheel lock-up. A quick test sequence checks all the components of the system. If ever the test sequence fails, the normal brake system is in control. Although the normal brake system can give instant and efficient braking, it can cause the wheels to be lock up, therefore, the driver can not steer and would lose control of the car. If any of the wheels happen to be skidding, the driver must recognize wheel-skid and manually 'pump the brakes' to avoid a skid. The advantage of ABS lies in its ability to allow the driver retain steering control in order to keep the car moving in the direction that the wheels are turned towards, rather than skidding in the direction of the car's forward momentum.
ABS has the classic design of an embedded system.

controller.
sensor, wheel speed.
actuators (valve and ABS reservoir) at each wheel.

ABS functions independently at each wheel. The control unit gets the speed via wheelspeed sensors at each wheel in order to calculate the deceleration. If there exists a case of rapid deceleration, ABS will be activate prior to wheel lock-up. Pressure on caliper is released by opening a valve, which interfaces with the wheel cylinder, letting oil flow into a small reservoir.
Anti-lock brakes function well on wet paved surfaces and icy or packed snow-covered roads. Stopping times will be longer on gravel or fresh snow, although operators will not experience the dangerous lockup of wheels and loss of steering control usually associated with conventional braking.

3. Requirements

3.1 General Requirements

The general responsibilities of the ABS are the following:

Receive on/off signals from the brakes, and use them for engaging and disengaging the ABS system
Run a System diagnostic test sequence at ignition and determine if any errors are present in the system
Run a basic test each time the on brake signal is captured, and determine if any errors are present
Terminate system execution if any failure occurs form either test. The termination shall not affect normal braking behavior of the vehicle
Relay information to the car's main computer concerning any failures in the system
Send a message to the car's main computer that will turn on an ABS error light on the driver's console if an error occurs in the system
Provide a method for returning the system to working order if a system failure occurs
Receive rotational speed data from four wheelspeed sensors
Calculate rotational deceleration from the wheelspeed data, and determine if wheel lock-up is imminent
If it's determined that wheel lock-up is imminent, take action to prevent wheel lock-up
Disable ABS engagement if the speed of the car is below 15 mph, or enable for speeds of 15 mph and above

3.2 Detailed Requirements

This section gives a more in depth description of the requirements described previously.

3.2.1 System Test

The system test must determine if any errors are present in the ABS. If any errors are present, the ABS must shut itself off and send a message to the car's main computer that an error has occurred in the system and to turn an ABS failure light on the driver's console. Normal breaking must not be affected by the termination of the ABS. The system test will also exhibit these conditions:

The system test will engage when the car is turned on
The system test will engage each time the brakes are applied
The test that is engaged when the car is turned on is a different test sequence than the test that is engaged each time that the brake is applied

3.2.2 Returning ABS to Working Order

If a failure occurs in the ABS, the system will not be able to function. In order to restore the ABS to working order, the car must be taken to a service technician for inspection. A service technician will be able to read the messages sent to the main computer from the ABS pertaining to the system failure. After the technician has determined the cause of the error and has remedied the failure, he will send a reset command to the controller to restore the remove the system from a failure state.

3.2.3 State of the Brakes

The same signal that is used to turn on the brake lights is read by the ABS system in order to determine whether or not the brake has been pressed engaged. The ABS will then only be able to become engaged if this signal shows the brakes are being used.

3.2.4 Information from the Wheelspeed Sensors

The ABS will receive information from a wheelspeed sensor for each wheel. Each wheelspeed sensor will send the speed of the wheel it is monitoring in meters/second.

3.2.5 Analyze the Data from the Wheelspeed Sensors

The ABS will use the information from the wheelspeed sensors to determine if wheel lock-up is imminent. The determination of wheel lock-up is accomplished by taking the derivative of the wheelspeed and then testing against a threshold. This calculation is done for each wheel hundreds of times per second.

3.2.6 Wheel Lock-Up Prevention

When the speed of the car is over 15 mph, the ABS must try to prevent wheel lock-up in hard braking situations where when lockup may occur. If the ABS determines that wheel lock-up is likely, the following actions are performed 10 times per second until the ABS determines that wheel lock-up is no longer possible:

A pressure release valve is activated to divert some of the brake fluid into a small reservoir
The brake fluid in the small reservoir is pumped back into the main fluid reservoir

4. UML Analysis

4.1 Use Cases

Use cases are used to help capture the goals of a system. They are also used to show relationships between actors and the system. Actors are the people or systems that interact with the ABS system. These include the Driver, the Wheelspeed Sensors, and the ABS Reservoir. These actors are outside of the ABS System, but they are needed to achieve the goals of our system.

**Figure 1:** ABS System Use Case
$\begin{figure} \epsfig{file=USE_V2.0.eps, height = 3.5in} \end{figure}$

$\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...xtends: None}] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...xtends: None}] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...xtends: None}] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...xtends: None}] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...m[{Extends: }] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ... System Test}] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...xtends: None}] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...xtends: None}] % \end{description} \end{minipage}\end{center} \end{minipage} }$ $\fbox{ \begin{minipage}[t]{5in} \begin{center}\begin{minipage}[t]{5in}\begin{de... ...eck for Skid}] % \end{description} \end{minipage}\end{center} \end{minipage} }$

4.2 Object Model

The Object model is used to organize the system into classes that are interconnected through associations. This shows the static structure of the ABS system and it also organizes and decomposes the system into more manageable subsystems.

4.2.1 Class Diagram

The Class Diagram is a graphical representation of the object model. A class describes a group of objects with similar properties called attributes, and common behavior called operations. The class diagram also shows the relationships between the different classes of the system.

**Figure 2:** ABS System Class Digram
$\begin{figure} \epsfig{file=Class_V2.4.eps, width=6in} \end{figure}$

4.2.2 Data Dictionary

This subsection defines all of the objects, attributes, and operations of all the classes in the class diagram.

ABS Controller: a microcomputer that functions as the "brain" of the ABS. The computer receives wheel-end performance data from each wheelspeed sensor. When the wheels try to lock, the computer delivers commands to operate the hydraulic actuator to control brake pressure. The computer also monitors brake pedal position, detects and prevents potential wheel lockup conditions while maintaining optimum braking performance, stores and displays diagnostic codes, and alerts the operator of a system malfunction by turning on the system lamp
- Deceleration_Threshold: If the deceleration rate is over this value, then the ABS will become engaged.
- testPass: This attribute represents the ABS self testing result.
- Vehicle_Speed: The current velocity of the vehicle.
- Brake_Off(): An external signal used to determine when the brakes are not being applied.
- Brake_On(): An external signal used to determine when the brakes are being applied.
- Wait(): This method makes the ABS to wait for a Brake_On signal.
- Calculate_Deceleration: This method calculates the deceleration rate based upon the speed retrieved from the wheelspeed sensor and updates the Deceleration_Rate stored inside the data structure WheelType for the wheel specified.
- Power_Up(): When the driver turns the engine on, this method will be called and the ABS system will be initiated.
- Power_Off(): When the driver turns the engine off, this method will be called and the ABS will be turned off.
- Reset(): Method initiated by a technician to restore the ABS to working order.
ABS Fail Light: This is an indicator on the driver's console that is illuminated upon an ABS failure.
- IsOn: An attribute that indicates if the ABS Fail Light is currently illuminated.
- IsOn(): This method returns the value of the attribute IsOn.
- TurnOn(): This method turns the ABS fail light on. If the light is already on, it does nothing.
- Reset(): After an ABS failure, this method is used by a technician to reset the ABS to working order.
Brake Pressure Valve: This class implements the rate of brake application.
- Increase_Pressure: This method causes the brake fluid in the small brake fluid reservoir to be pumped back into the main brake fluid reservoir.
- Decrease_Pressure: This method causes brake fluid to be diverted into the small brake fluid reservoir.
Test Sequence: This class implements the status test of the ABS each time the engine is ignited or the brakes are applied.
- Run_Braking_Test(): This method does a test on all the ABS components to ensure that they are working properly each time the brakes are applied.
- Run_Initial_Test(): This method does an initial test on the ABS components to ensure that they are working properly each time the engine is started.
Wheelspeed Sensor: a magnetic sensor that uses trigger wheel rotation to produce a weak alternating current.
- Wheelspeed: An attribute that specifies the current speed of a wheel.
- Get_Wheelspeed: This function is used to determine the current speed of a wheel.

4.3 Dynamic Model

4.3.1 State Diagram

The State Diagram is used to model the behavior of the system. It serves as a aid in visualizing how the system acts for different scenarios. The following figure is the state diagram for the ABS. It contains five concurrent state machines, and a description of each state machine is contained in the following subsections.

**Figure 3:** ABS System State Diagram
$\begin{figure} \epsfig{file=State_V2.4.eps, width=6.5in, height=6.5in} \end{figure}$

**Figure 4:** ABS Fail Light State Diagram
$\begin{figure} \begin{center} \epsfig{file=fail.eps} \end{center}\end{figure}$

4.3.2 ABS Fail Light

The ABS Fail Light state machine is composed of two states. The initial state is the Light Off state and the second state is the Light On state. A Turn_On event causes a transition to the Light On state from the Light Off state and a Reset event causes a transition from the Light On state to the Light Off state. Both of these events are triggered by messages sent from the ABS Controller.

**Figure 5:** Wheelspeed Sensor State Diagram
$\begin{figure} \begin{center} \epsfig{file=whlspd.eps} \end{center}\end{figure}$

4.3.3 Wheelspeed Sensor

The Wheelspeed Sensor state machine is composed of a single state named Idle. A Get_Wheelspeed event, which is triggered by a message sent from the ABS Controller, results in a transition from the Idle state to itself. The Get_Wheelspeed event also results in a Return Wheelspeed message being sent back to the ABS Controller.

**Figure 6:** Test Sequence State Diagram
$\begin{figure} \begin{center} \epsfig{file=test.eps, width=3in} \end{center}\end{figure}$

4.3.4 Test Sequence

The Test Sequence state machine contains three states - Idle, Running Initial Test, and Running Braking Test. The initial state, Idle, has a couple of transitions that can occur as a result of events that are triggered by messages sent from the ABS Controller. The first of such transitions can take place when a Run_Initial_Test event happens. This transition is to the Running Initial Test. The second transition from the Idle state occurs when a Run_Braking_Test event takes place, and the transition is to the Run Braking Test state. Finally, a transition back to the Idle state occurs from both the Running Initial Test and Running Braking Test states when a Return Test Result event happens.

**Figure 7:** Brake Pressure Valve State Diagram
$\begin{figure} \begin{center} \epsfig{file=valve.eps, width=3in} \end{center}\end{figure}$

4.3.5 Brake Pressure Valve

The Brake Pressure Valve state machine is composed of three states - Idle, Increasing Pressure, and Decreasing Pressure. The Idle state is the initial state, and there are two transitions that can occur from this state. The first is taken to the Decrease Pressure state if a Decrease_Pressure event occurs. The second transition is taken to the Increase_Pressure state if an Increase_Pressure event occurs. Both the Increase_Pressure and Decrease_Pressure events are triggered by messages sent from the ABS Controller. Also, when the actions that need to be performed in the Increasing Pressure or Decreasing Pressure states are done, a transition back to the Idle state is taken.

**Figure 8:** ABS Controller State Diagram
$\begin{figure} \begin{center} \epsfig{file=controller.eps, width=6in} \end{center}\end{figure}$

4.3.6 ABS Controller

The initial state of the ABS Controller machine is the Idle state. A transition to the Waiting for Test Result state is taken if a Power_On event occurs. This event also causes a Run_Initial_Test message to be sent to the Test Sequence machine.

From the Waiting for Test Result state, two transitions are possible. One transition is taken to the ABS Failed state if the Waiting for Test Result state finishes its execution and the variable testPass evaluates to false. This transition also results in a Turn_On message being sent to the ABS Fail Light machine. The second transition from the Waiting for Test Result state occurs if the state is done with its execution and the testPass variable evaluates to true. This transition is to the Wait state.

The Wait state can take two transitions. One of these transitions is taken to the Braking state if a Brake_On event takes place. This event also results in a Run_Braking_Test message to be sent to the Test Sequence machine. The other transition is taken to the Idle state if a Power_Off event occurs.

The ABS Failed state has one transition that is taken to the Idle state if a Reset event occurs.

The Braking state will take a transition to the Wait state if a Brake_Off event occurs. Another transition, which is to the Idle state, can be taken from the Braking state if a Power_Off event occurs.

While in the Normal Braking state, a transition to the Pumping state will be taken if the Deceleration_Rate is less than the Threshold. This transition also results in a Decrease_Pressure message being sent to the Brake Pressure Valve state machine.

The Pumping state takes a transition to the Normal Braking state when it is finished with its execution. This transition results in a Increase_Pressure message being sent to the Brake Pressure Valve machine.

4.3.7 Sequence Diagrams

4.3.8 Braking Sequence Diagram

This diagram shows the interaction between the objects of the ABS during a braking sequence. What first happens in this diagram is that the ABS Controller receives a Brake_On() signal which in turn causes the Controller to send a Run_Braking_Test() signal to the Test Sequence. If the Test Sequence determines that an error is present within the system, the Controller sends a Turn_On() signal to the ABS Fail Light and then terminates it's execution. On the other hand, if the Test Sequence finds no errors in the system, then the Controller sends a Get_Wheelspeed() signal to all the Wheelspeed sensors. The Controller then calculates the deceleration rates of each wheel, and if any of those deceleration rates are above or equal to the threshold, then the Controller sends a Decrease_Pressure() signal to the Brake Pressure Valve for the respective wheel. The process of getting the wheelspeed of each wheel and then calculating the deceleration rates for those wheels continues until a Brake_Off() signal is sent to the Controller.

**Figure 9:** Braking Sequence Diagram
$\begin{figure} \epsfig{file=brakingSequenceDiagram_V3.1.eps, width=6.5in} \end{figure}$

4.3.9 Power Up Sequence Diagram

The 'Power up and Off' sequence diagram shows an actor (Driver) providing a signal 'Power_Up'. The sequence flows through a system test with both a 'pass' and 'fail' scenario. The sequence ends with the driver providing a Power_Off signal.

**Figure 10:** Power Up and Off for ABS System
$\begin{figure} \epsfig{file=PowerUpOff_ver2.0.eps, width=5.5in} \end{figure}$

5. Promela Specification for System

Model checking is used to study the behaviors of reactive systems. It can determine if something always or never happens, if a state can be reached at all, if a series of states form an infinite loop, or it can even run a model in simulation. In the case of this system, model checking is used to study the behavior of the state diagrams. In order to perform proper model checking there are typically three steps that need to be followed: 1) create a finite state model of the system design, 2) specify critical correctness properties, and 3) validate the model with respect to the specifications. Promela and Spin have been chosen to perform the above steps for this system. Encoding the state diagrams for the ABS system into Promela does the first step. Once the diagrams are encoded, running the Promela code through SPIN can perform the last two steps. By using Promela and SPIN, it is possible to simulate the executions of the system. This allows an exhaustive analysis of the model and also the ability to test for safety and liveness properties.

5.1 Model Checking and Promela Overview

5.2 Promela Model

/* ABS Controller States */
mtype {Idle, Waiting, ABSfailed, Wait, Braking, ABSpumping};

/* Brake Pressure Valve States */
mtype {vIdle, IncreaseValve, DecreaseValve};

/* ABS Fail Light States */
mtype {Off, On};

/* ABS Controller Events */
mtype {Power_On, Power_Off, Brake_On, Brake_Off, Engage_ABS, Disengage_ABS};

/* Fail Light Events */
mtype {Turn_On, Reset};

/* Wheelspeed Sensor Events */
mtype {Get_Wheelspeed};

/* Test Sequence Events */
mtype {Run_Test, OK, Fail};

/* Brake Pressure Valve Events */
mtype {Increase_Pressure, Decrease_Pressure};

/* Technician Events */
mtype {tReset};

mtype controllerState;
mtype valveState;
mtype lightState;

chan controllerEvent = [0] of {mtype};
chan valveEvent = [0] of {mtype};
chan lightEvent = [0] of {mtype};
chan wheelspeedEvent = [0] of {mtype};
chan testEvent = [0] of {mtype};
chan technicianEvent = [0] of {mtype};

/*************************************************************
Purpose: Simulation of the ABS environment
         Generates random signals that the system would experience.
	 This is designed to run continuously

*************************************************************/

init
{
  do
  :: timeout ->
       if
       :: controllerEvent!Power_On -> printf("turned on power\n");
       :: controllerEvent!Power_Off -> printf("power turned off\n");
       :: controllerEvent!Brake_On -> printf("brake pressed\n");
       :: controllerEvent!Brake_Off -> printf("brake released\n");
       :: controllerEvent!Engage_ABS -> printf("engaging ABS\n");
       :: controllerEvent!Disengage_ABS -> printf("disengaging ABS\n");
       :: technicianEvent!tReset -> printf("technician reset\n");
       fi;
  od;
}
   
/**************************************************************
Purpose: Simulates the ABS Controller Class (4.2.1 Class Diagram)
	 Class Diagram.
         All sub states can be cross-referenced by the 4.3.1 
         State Diagram. 

*************************************************************/ 

active proctype ABScontroller()
{
  controllerState = Idle;

  do
  :: (controllerState == Idle) -> printf("in Idle\n");
         controllerEvent?Power_On -> testEvent!Run_Test;
	 printf("Power_On event\n");
         controllerState = Waiting;

  :: (controllerState == Waiting) -> printf("in Waiting\n");
         if
	 :: testEvent?OK -> printf("Test Pass\n");
	        controllerState = Wait;
	 :: testEvent?Fail -> printf("Test Fail\n");
	        lightEvent!Turn_On;
	        controllerState = ABSfailed;
         :: controllerEvent?Power_Off -> printf("Power Off\n");
		controllerState = Idle; 
	 fi;

  :: (controllerState == Wait) -> printf("in Wait\n");
         controllerEvent?Brake_On -> testEvent!Run_Test;

	 if
	 :: testEvent?OK -> controllerState = Braking;
	 :: testEvent?Fail -> lightEvent!Turn_On;
	        controllerState = ABSfailed;
	 :: controllerEvent?Power_Off -> printf("Power Off\n");
		controllerState = Idle;
	 fi;

  :: (controllerState == Braking) -> printf("in Braking\n");
         if
	 :: controllerEvent?Brake_Off -> controllerState = Wait;
	 :: controllerEvent?Engage_ABS;
                valveEvent!Decrease_Pressure;
	        controllerState = ABSpumping;
	 :: controllerEvent?Power_Off -> printf("Power Off\n");
		controllerState = Idle;
	 fi;

  :: (controllerState == ABSpumping) -> printf("in ABS Pumping\n");
         if
	 :: controllerEvent?Disengage_ABS;
                valveEvent!Increase_Pressure;
	        controllerState = Braking;
	 :: controllerEvent?Brake_Off -> controllerState = Wait;
	 :: controllerEvent?Power_Off -> printf("Power Off\n");
		controllerState = Idle;
	 fi;

  :: (controllerState == ABSfailed) -> printf("in ABS Failed\n");
         technicianEvent?tReset -> lightEvent!Reset;
	     controllerState = Idle;
  od;
}

/*******************************************************************
Purpose: Simulates the ABS Fail Light Class (4.2.1 Class Diagram)
         Waits on a Turn_On signal, and then waits until Reset.
          
********************************************************************/

active proctype ABSfailLight()
{
  lightState = Off;

  do
  :: (lightState == Off) -> printf("in Off\n");
         lightEvent?Turn_On -> lightState = On;

  :: (lightState == On) -> printf("in On\n");
         lightEvent?Reset -> lightState = Off;
  od;
}

/*******************************************************************
Purpose: Simulates the Test Sequence Class (4.2.1 Class Diagram)
         This 'class' simulates two testing methods with runnning 
         the same method 'Run_Test' for each. Real system will have two.

*******************************************************************/

active proctype TestSequence()
{
  do
  :: testEvent?Run_Test -> printf("Running test\n");
        if
        :: testEvent!OK;
        :: testEvent!Fail;
        fi;
  od;
}

/****************************************************************
Purpose: Simulates the Brake Pressure Valve (4.2.1 Class Diagram)
         Waits for one of two signals: DecreaseValve, IncreaseValve 

**************************************************************/

active proctype BrakePressureValve()
{
  valveState = vIdle;

  do
  :: (valveState == vIdle);
         if
	 :: valveEvent?Decrease_Pressure;
	        valveState = DecreaseValve;
         :: valveEvent?Increase_Pressure;
	        valveState = IncreaseValve;
         fi;

  :: (valveState == DecreaseValve);
         printf("Decreasing Pressure") -> valveState = vIdle;

  :: (valveState == IncreaseValve);
         printf("Increasing Pressure") -> valveState = vIdle;
  od;
}

6. Spin Analysis of UML Diagrams via Promela Specifications

6.1 Assertion Check

Assertion checks are used as a spot check for a particular point of time in a system. They provide a means for us to check that certain conditions are met at a point in execution of our system. They are an excellent tool provided for checking properties of our system, but they are limited, since they can only check the system at the point where they are inserted into the promela model.

Assert that when the ABS is engaged, the ABS fail light is not on.

assert(lightState == Off)

:: (controllerState == ABSpumping) -> printf("in ABS Pumping");
         assert(lightState == Off);
	 
         if
	 :: controllerEvent?Disengage_ABS;
              valveEvent!Increase_Pressure;
	      controllerState = Braking;
	 :: controllerEvent?Brake_Off -> controllerState = Wait;
	 :: controllerEvent?Power_Off -> printf("Power Off");
              controllerState = Idle;
	 fi;

The following figure shows the output that XSpin produced after running the assertion check. As you can see, the check produced no errors, therefore our assertion is valid, and the property holds true for our system design.

**Figure 11:** Assertion Verification in XSpin
$\begin{figure} \begin{center} \epsfig{file=assertion.eps, width=5.5in} \end{center}\end{figure}$

The XSpin text output also showed no errors, and no assertion violations for this assertion check.

(Spin Version 3.4.10 -- 30 October 2001)
	+ Partial Order Reduction

Full statespace search for:
	never-claim         	- (not selected)
	assertion violations	+
	cycle checks       	- (disabled by -DSAFETY)
	invalid endstates	+

State-vector 64 byte, depth reached 65, errors: 0
     178 states, stored
      75 states, matched
     253 transitions (= stored+matched)
       0 atomic steps
hash conflicts: 0 (resolved)
(max size 2^19 states)

2.542 	memory usage (Mbyte)


real        0.0
user        0.0
sys         0.0

6.2 Reachability Analysis

Reachability Analysis is used to verify that all states in our model of the system can be reached through some pattern of execution. If a there is a state that cannot be reached, that means that our model is incorrect. In that case, the state may be of no use to our system, and might be discarded. Another reason may be that the state is missing transitions or events that would cause our system to enter it. In that case we would need to modify our model to correct this. This process is then iterated until we reach the final result that all of our states are reachable in our system.

**Figure 12:** Reachability Analysis Results in XSpin
$\begin{figure} \begin{center} \epsfig{file=msc.eps, height=5in} \end{center}\end{figure}$

In the previous figure, the labels correspond to the states in our promela model. If you compare these state names with the states in our state machine, you will see that all states are reachable, and therefore reachability for our model is verified.

6.3 Model Checking

Model checking is used to study the behavior of a system. In this section we verify safety critical properties of the ABS by using XSpin. Verification of safety critical properties is very important for systems in which people's lives are at stake, and testing and validation are not enough.

If the ABS fails, then the ABS failure light will eventually be turned on.

[](p -> <>q)
#define p (controllerState == ABSfailed)
#define q (counter > 0)

active proctype ABScontroller()
{
  controllerState = Idle;

  do
  :: (controllerState == Idle) -> printf("in Idle");
         if
	 :: controllerEvent?Power_On -> testEvent!Run_Test;
	        printf("Power_On event");
                controllerState = Waiting;
	 :: controllerEvent?Power_Off;
	        controllerState = Idle;
         fi;

  :: (controllerState == Waiting) -> printf("in Waiting");
         if
	 :: testEvent?OK -> printf("Test Pass");
	        controllerState = Wait;
	 :: testEvent?Fail -> printf("Test Fail");
	        lightEvent!Turn_On;
	        controllerState = ABSfailed;
         :: controllerEvent?Power_Off -> printf("Power Off");
		controllerState = Idle; 
	 fi;

  :: (controllerState == Wait) -> printf("in Wait ");
         controllerEvent?Brake_On -> testEvent!Run_Test;

	 if
	 :: testEvent?OK -> controllerState = Braking;
	 :: testEvent?Fail -> lightEvent!Turn_On;
	        controllerState = ABSfailed;
	 :: controllerEvent?Power_Off -> printf("Power Off ");
		controllerState = Idle;
	 fi;

  :: (controllerState == Braking) -> printf("in Braking ");
         if
	 :: controllerEvent?Brake_Off -> controllerState = Wait;
	 :: controllerEvent?Engage_ABS;
                valveEvent!Decrease_Pressure;
	        controllerState = ABSpumping;
	 :: controllerEvent?Power_Off -> printf("Power Off ");
		controllerState = Idle;
	 fi;

  :: (controllerState == ABSpumping) -> printf("in ABS Pumping ");
         if
	 :: controllerEvent?Disengage_ABS;
                valveEvent!Increase_Pressure;
	        controllerState = Braking;
	 :: controllerEvent?Brake_Off -> controllerState = Wait;
	 :: controllerEvent?Power_Off -> printf("Power Off ");
		controllerState = Idle;
	 fi;

  :: (controllerState == ABSfailed) -> printf("in ABS Failed ");
         technicianEvent?tReset -> lightEvent!Reset;
	     controllerState = Idle;
  od;
}

active proctype ABSfailLight()
{
  lightState = Off;

  do
  :: (lightState == Off) -> printf("in Off ");
         lightEvent?Turn_On -> lightState = On;
	 counter = 0;

  :: (lightState == On) -> printf("in On");
         counter++;
         lightEvent?Reset -> lightState = Off;
  od;
}

This figure shows that the safety critical property is valid and verified.

**Figure 13:** LTL Property Verification in XSpin
$\begin{figure} \begin{center} \epsfig{file=ltl1.eps, height=3.5in}\end{center} \end{figure}$

About this document ...

Requirements Analysis Document
(Final Version)

This document was generated using the LaTeX2HTML translator Version 98.1 release (February 19th, 1998)

The command line arguments were:
latex2html -split 1 -no_navigation -show_section_numbers do-requirements.tex.

The translation was initiated by Joseph James Mongiat on 2001-12-07

Joseph James Mongiat
2001-12-07

Requirements Analysis Document (Final Version)

Requirements Analysis Document
(Final Version)