operational profile development

Operational Profile Development: A White Paper Peter B. Lakey CCOperational Profile Development Prelude This white paper specifies a procedure for developing a computing system operational profile and illustrates the implementation of the procedure through an example. Before illustrating the procedure for constructing an operational profile a brief explanation of the inherent benefits of operational profile testing is provided. The thesis is that if a project applies an operational profile testing methodology, even if it never actually measures the reliability of the system or ever intends to calculate software system reliability, significant benefits can be realized. The reliability of a software system depends on the correctness and completeness of the specification of its behavior and the thoroughness of testing based on that correct specification. Simply stated, if a project employs operational profile testing, the specification will be more complete and correct than it would have been otherwise and the testing will be more thorough than it would have been otherwise. Therefore, applying operational profile testing results in a more reliable system than not applying it. The operational profile is a formal representation of the required behavior of a computing system at its interfaces. Precisely, it is a finite state machine representation of the computing system specification. The process of constructing the profile guides project system analysts in explicitly considering all inputs the system will be required to process under all conditions. It is a rigorous process that ensures an accurate specification. Experience has proven that specifications derived from this approach are significantly better than collections of requirements produced by projects that do not define the profile. Software reliability measurement (prediction, estimation, assessment) assumes an operational profile exists. If it does not exist, if the documented specification does not represent actual required behavior, then the implementation will be wrong. The degree to which it is wrong is relative, but it definitely will be incorrect. Any specification that is wrong results in a system that is less than highly reliable. The system will not do, cannot do, what it should actually do because the specification is wrong. Even if the software code is 100% correct, system reliability is compromised because the specification is incorrect. The relevance of the specification cannot be overstated. It is easy to assume an operational profile exists. In fact, developing an accurate operational profile is the most difficult aspect of the software reliability methodology. Most of the effort should be focused here. Substantial benefits will be derived. The operational profile is, by definition, a black box specification of the interaction between a system and its external environment. Precisely, it specifies all required responses to all input variable values under all possible operating conditions, at some level of abstraction1. In a typical system product development cycle, the profile cannot be explicitly defined for the purpose of software reliability testing until the interfaces to the software system are documented, usually late in the system design process. That is, the physical (or logical) design of the system must be completed before the profile is complete. Because OP definition is a non-trivial task, it should be started as early in the system development process as possible. Waiting until the software specification is complete to initiate OP definition is too late for most projects and likely would result in ineffective OP testing. The profile should be developed iteratively at multiple levels of abstraction, starting with a high level functional description of software system behavior and culminating with an explicit specification of detailed logic associated with all defined system interfaces. This approach leads to a structured and well-defined set of requirements documenting what the system should do and how it should do it. 1 Fully specifying every possible variable value is not possible for most systems because the input space is infinite. The input space must be stratified to transform an infinite state space into a finite state machine for the profile to be tractable.

Copyright Unpublished: Cognitive Concepts LLC Free to Use and Re-Distribute 2

Procedure 1. Identify computing system boundary Determine the scope of the computing system and draw a line between it and its external

interfaces. 2. Identify all interfaces to the computing system Determine all endpoints that either provide inputs to the computing system and/or receive

outputs from the system. 3. Identify all input variables to the computing system Determine every discrete input (from each interface) that transmits messages or data to the

system. Also determine the data type for each input. 4. Identify the range of possible values for each input Determine every possible value that could sent from the input source for each variable

connected to the computing system. Stratify the variable into value ranges that correspond to behavior variants; i.e. invoke different responses based on variable value.

5. Identify all global state variables for the computing system Determine every global variable that is relevant to fully specifying the required behavior of the control system. Also determine the data type and value range for each global variable.

6. Identify all outputs from the computing system Determine all output messages and associated data type and value range that are sent to computing system end points.

7. Specify required behavior for all discrete variants of computing system input For each input value variant do the following: a) Specify global variable constraints b) Specify required response (in terms of output variable values) for each unique global variable condition c) Specify global variable value updates

8. Convert behavior specification to finite state machine Apply state machine generation algorithm (as specified in this section) to the set of rules defined in Step 7.

9. Assign probability values Apply any suitable method to assign probability values to all transitions in the state machine. A functional profile can be developed that describes the interaction between system actors and the computing system. This profile identifies the actors that interact with the system by providing inputs to and/or receiving responses from it. The functional profile captures this interaction in a general sense. Once the set of functions for the computing system is determined, an architecture for the system can be defined that distributes the functions among processes, sometimes referred to as modules or subsystems. Whatever the term used, these are major design elements that carry out one or more major functions. A typical computing system can be characterized by a data space and a process space. These are fundamental building blocks of the operational profile definition, as the example will show.


Figure 1. Basic Computing System Elements

Ultimately, the operational profile is a specification of black box behavior of a computing system. Precisely, it specifies the required response to all values of all inputs to the system under all known combinations of operating conditions. This interface is indicated by item 1. For most computing systems, the operational profile is large and complex. There are many, many inputs and outputs and countless combinations of operating conditions. An attempt to develop the profile all at once can be overwhelming and is likely to be an ineffective endeavor. An effective approach is to divide and conquer by defining the profile one module at a time and combining them into a large profile. In the figure, the data space represents the operating conditions. The process space represents the required responses based on the state of the system captured in the data space. The concept is important because it holds not only at the black box computing system level, but also at the process (module) level. The behavior of a subsystem (indicated by item 2) can be specified by identifying the subset of the system’s inputs and outputs that are relevant to it and the subset of operating variables that impact the required responses to the subsystem inputs. The aggregate specification is exactly the same at the system level, but it is significantly more tractable and manageable at the subsystem level. In developing an operational profile, a project is encouraged to identify each of the subsystems that contribute to overall system behavior, and specify the profile for the subsystem. As a general rule, each subsystem should have a manageable number of inputs, outputs and operating variables. For each subsystem the inputs are identified, the operating conditions that influence expected responses are specified, and the expected responses to each of the inputs based on operating conditions is defined. The subsystem specification is reviewed by a project team and approved. The details of the subsystem profile are updated iteratively as more detailed information becomes available on the input interfaces. This iterative operational profile development procedure is now illuminated with a generic example. Example: Vehicle Control Unit for Electronically-controlled Automobile Assume that a project has an objective of implementing operational profile testing for the computing system that controls several elements of automobile behavior electronically. The control system processes sensor data from major system components and sends control commands back to those components as well as vehicle status information to an electronic display for the driver. Typical input sources include operator commands, operator display controls, vehicle sensors and other ancillary devices. Typical output destinations include actuators and the operator display panel. See Figure 2.

DATASPACE

Process 1

Process 2

Process 3

Computing System Boundary

I/0LAYER

SYSTEMACTORS

Subsystem boundary1

2


Figure 2. Vehicle Control System Interface

Functional Description The vehicle control system responds to operator commands to control the vehicle. The primary operating commands are gear selection (forward, reverse, neutral, low, 4WD, etc.), acceleration commands, steering and braking. Based on the driver commands and the state of the sensors distributed throughout the system, the controller sends actuator commands to the engine, transmission, braking and steering. Generally speaking, the vehicle control system constantly monitors driver commands and adjusts actuator commands to maintain vehicle state according to driver intent. Computing System Architecture Assume that the control system is implemented as 5 major computing components: a vehicle controller (VCM) that acts as the master decision maker, an engine control module (ECM) to regulate power and fuel efficiency, a brake control module (BCM) to enforce safe and effective braking behavior, a climate control module (CCM) that is responsible for passenger comfort, and a display panel module (DPM) that provides information on vehicle status and other passenger preferences such as music and navigation. In addition to those behavior modules there are two global variable arrays: an I/O List (IOL) and a Global Variable List (GVL). Early in system design the requirements associated with each major system component can be specified. A system architecture can be developed, as the one illustrated in Figure 3. A basic description of each module is provided here. This can be considered the Functional Description. Note, the components and their associated descriptions are purposely simplistic for clarity and brevity. There are obviously many more control elements in a modern automobile than what is described in this example. Vehicle Control Module The VCM is responsible for managing the vehicle responses to operating commands at the system level. It determines the state of vehicle level operating characteristics and makes decisions based on sensor data inputs. It orchestrates the behaviors of the other control modules by accepting information from them and directing them how to respond based on specific environmental conditions encountered. While the VCM communicates with all of the other components, it is the only one that is allowed to update the GVL. Conversely, it is the only module that does not interact with the I/O List global variable.

Sensors

Driver Commands

Other DevicesControl System

Actuators

Display


Figure 3. Vehicle Control System Architecture

Engine Control Module (including transmission control) The ECM is responsible for sending commands to power the vehicle and monitoring the status of a number of engine and transmission variables to determine how to optimize system performance and efficiency. The primary commands it sends are gear, torque and speed, to control when and how fast the car travels and regulate the rate of acceleration. The ECM monitors actual engine torque and speed and vehicle speed as well as fuel consumption and a number of other operating characteristics. Brake Control Module The BCM controls the brakes for the vehicle’s front and rear wheels electronically. It responds to input commands from the operator to set and release brakes. It monitors and regulates the amount of pressure available in the braking system. It also implements the antilock braking operations. The BCM also reports any anomalous conditions it senses within the braking system to the VCM. Climate Control Module The CCM regulates the temperature within the vehicle cab. It responds to basic operator control commands for heat and cooling settings and the magnitude of those commands. It accepts sensor feedback data indicating the actual climate conditions to ensure they conform to driver expectations. Display Panel Module The DPM is responsible for reporting information to the driver’s display panel. It mainly reports vehicle status. The information displayed is selected through an operator’s menu. The DPM does not control any vehicle operating functions, it only provides information. Input/Output List The IOL is a global data type that keeps track of all current values of all input and output commands. Global Variable List The GVL is a global data type that keeps track of the current state of all system operating variables.

INPUTOUTPUTLIST

GLOBALVARIABLELIST

ECM

Vehicle Control System

OperatorControls

BCM

CCM

DPM

VCMVehicleSensors

VehicleActuators

DisplayPanel


Overall behavior. Generically, the requirements for a control module can all be specified using the three building blocks shown in Figure 4: Inputs, Outputs and State Variables. This is true not only for the Vehicle Control System example here, but for virtually any software system. This is true at the module level and at the system level. Inputs, Outputs and State Variables are the essential ingredients.

Figure 4. Control Module Specification Elements

A generic specification format is defined below. General Compact Specification Format Initial State:

Operating Variable (OV) 1 Value Operating Variable 2 Value Operating Variable N Value Input 1: OV Variable 1 Constraint OV Variable 2 Constraint OV Variable N Constraint Behavior 1: OV Variable X Value = a // if applicable OV Variable Z Value = n // if applicable [Action] // This is the required response in IF-THEN-ELSE format. OV Variable 1 Update OV Variable 2 Update OV Variable N Update Behavior N: OV Variable X Value = a // if applicable OV Variable Z Value = n // if applicable [Action] OV Variable 1 Update OV Variable 2 Update OV Variable N Update Input 2: Same concept Input N: Same concept

NOTE: The entire specification can be documented using the simple compact construct above

Input 1

Input 2

Input 3Module

Output 1

Output 2

Global Variable List


The system stores inputs it receives in the Input/Output List and sends output messages from the IOL continuously (assume a rate of 20 milliseconds) during vehicle operation, after the engine is turned on. Each operating cycle the IOL updates the values of each of its input variables after receipt and updates the values of each of its output variables before control command delivery. Each of the primary control modules in Figure 3 receives input data from the IOL, instructions from the VCM and global state conditions from the GVL and, after processing that information, sends output commands to the IOL as well as global variable update requests to the VCM. They do this every cycle. The Vehicle Control Manager takes global variable update requests from each of the primary control modules and determines whether to grant those requests based on the current status of the GVL. If the requests are granted, the VCM updates the global state. If not, it leaves the global state as it is. The VCM keeps track of overall vehicle state. That is the general operation of the Vehicle Control System. Technical Specifications The next step is to create technical specifications for each of the elements of the control system. These specifications are the basis of the operational profile. Refer to a companion white paper on Operational Profile Testing for details on defining a specification. Here we simply provide an example specification for each of the vehicle controller subsystems, which include inputs, outputs, and sample behaviors. [Note: It is not necessary to enumerate all the requirements in this example because the concept is the same regardless of the number of them. Sufficient details are provided to convey the procedure.] Engine Control Module The interfaces to the ECM are illustrated in Figure 5. This is followed by a sample of the possible inputs and associated behavior requirements.

Figure 5. Engine Control Module Interface Definition

Sample Requirements 1. Select Reverse

Global Variable Constraints: Brake Status = Set Current Gear <> Reverse Engine Fault Status = False

Gear Selection ECM Transmission CmdSpeed Command

Engine SpeedEngine Torque

Fuel LevelFuel Pressure

Oil LevelOil Pressure

Oil Temperature

Engine Temperature

Throttle Request

Transmission Temp

Vehicle Speed Torque Command

Fuel Level StatusFuel Pressure Status

Oil Level StatusOil Pressure Status

Oil Temp Status

Engine Temp Status

Trans Temp Status

Global VariablesBrake StatusCurrent GearEngine Fault StatusTo Actuators

To VCM

Engine Fault Status


Response Send command to set transmission to Reverse Global Variable Update: Current Gear = Reverse

2. Select Forward Global Variable Constraints: Brake Status = Set Current Gear <> Forward Engine Fault Status = False Response Send command to set transmission to Forward Global Variable Update: Current Gear = Forward

3. Select Neutral Global Variable Constraints: Brake Status = Set Current Gear <> Neutral Response Send command to set transmission to Neutral Global Variable Update: Current Gear = Neutral

4. Select Park Global Variable Constraints: Brake Status = Set Current Gear <> Park Response Send command to set transmission to Park Global Variable Update: Current Gear = Park

5. Increase/Decrease Throttle Global Variable Constraints: No Constraints // no restrictions on this command but response is dependent Response IF (Current Gear = Neutral OR Park) Send Engine Speed command based on throttle request and send Engine Torque Command = 0 IF (Current Gear = Reverse) send command to set Engine Speed and Torque to negative values IF (Current Gear = Forward) send command to set Engine Speed and Torque to positive values Global Variable Update: No Updates resulting from this input


6. Vehicle Speed Not Equal to Commanded Speed // commanded speed is implied Global Variable Constraints: Brake Status = Released Current Gear = Forward or Reverse // vehicle must be able to move Response Send Engine Speed command based on throttle request and current vehicle speed Send Engine Torque command based on throttle request and current engine speed Global Variable Update: No Updates resulting from this input

7. Engine Speed Below Commanded Speed // engine speed commanded by control system Global Variable Constraints: No Restriction // vehicle RPM can be adjusted in any gear Response Send command to increase torque to achieve commanded engine speed Global Variable Update: No Updates resulting from this input

8. Engine Speed Equal to Commanded Speed // engine speed commanded by control system Global Variable Constraints: No Restriction // vehicle RPM can be adjusted in any gear Response Send command to adjust torque to achieve maintain engine speed Global Variable Update: No Updates resulting from this input

9. Engine Speed Above Commanded Speed // engine speed commanded by control system Global Variable Constraints: No Restriction // vehicle RPM can be adjusted in any gear Response Send command to decrease torque to achieve commanded engine speed Global Variable Update: No Updates resulting from this input

10. Engine Speed Deviation // engine not properly responding to speed commands Global Variable Constraints: No Restrictions on Input // Engine Speed Fault can occur in any gear Response Update Engine Fault Status to Include Speed Deviation Error Global Variable Update: Engine Fault Status = Speed Deviation Error

11. Engine Torque Deviation // engine not properly responding to torque commands


Global Variable Constraints: No Restrictions on Input // Engine Speed Fault can occur in any gear Response Update Engine Fault Status to Include Torque Deviation Error Global Variable Update: Engine Fault Status = Torque Deviation Error

12. Engine Temperature Normal Global Variable Constraints: No Restrictions on Input // Engine Temperature is constantly monitored Response Update Engine Temperature Status to Normal // This variable is just stored and displayed Global Variable Update: Engine Temperature Status = Normal // Maintain status of engine temp in GVL

13. Engine Temperature High Global Variable Constraints: No Restrictions on Input // Engine Temperature is constantly monitored Response Update Engine Temperature Status to High and pass to VCM // Make VCM aware of temp Global Variable Update: Engine Temperature Status = High // Maintain status of engine temp in GVL Engine Fault Status Includes Temperature High

14. Fuel Level Normal Global Variable Constraints: No Restrictions on Input // Fuel Level is anything but low Response Send Fuel Level to VCM // This variable is just stored and displayed Global Variable Update: Fuel Level Status = Normal // Maintain status of Fuel Level in GVL

15. Fuel Level Low Global Variable Constraints: Fuel Level Not High // Can’t go from High to Low Response Update Engine Temperature Status to Low and pass to VCM // Make VCM aware of fuel Global Variable Update: Fuel Level Status = Low // Maintain status of fuel level in GVL

16. Fuel Pressure Normal Global Variable Constraints: No Restrictions on Input // Fuel Pressure is anything but low


Response Send Fuel Pressure to VCM // This variable is just stored and displayed Global Variable Update: Fuel Pressure Status = Normal // Maintain status of Fuel Pressure in GVL

17. Fuel Pressure Low Global Variable Constraints: No constraints // Fuel Pressure constantly monitored Response Update Fuel Status to Low and pass to VCM // Make VCM aware of Fuel Pressure Global Variable Update: Fuel Pressure Status = Low // Maintain status of fuel pressure in GVL Engine Fault Status includes Fuel Pressure low // Maintain this as a fault condition

18. Oil Pressure Normal Global Variable Constraints: No Restrictions on Input // Oil Pressure is anything but low Response Send Oil Pressure to VCM // This variable is just stored and displayed Global Variable Update: Oil Pressure Status = Normal // Maintain status of Fuel Pressure in GVL

19. Oil Pressure Low Global Variable Constraints: No constraints // Oil Pressure constantly monitored Response Update Oil Pressure Status to Low and pass to VCM // Make VCM aware of Oil Pressure Global Variable Update: Oil Pressure Status = Low // Maintain status of Oil pressure in GVL Engine Fault Status includes Oil Pressure low // This is as a fault condition

20. Oil Temperature Normal Global Variable Constraints: No Restrictions on Input // Oil Temperature is constantly monitored Response Update Oil Temperature Status to Normal // This variable is just stored and displayed Global Variable Update: Oil Temperature Status = Normal // Maintain status of Oil temp in GVL

21. Oil Temperature High Global Variable Constraints: No Restrictions on Input // Oil Temperature is constantly monitored


Response Update Oil Temperature Status to High and pass to VCM // Make VCM aware of temp Global Variable Update: Oil Temperature Status = High // Maintain status of Oil temp in GVL Engine Fault Status Includes Oil Temperature High

22. Transmission Temperature Normal Global Variable Constraints: No Restrictions on Input // Trans Temperature constantly monitored Response Update Trans Temperature Status to Normal // This variable is just stored and displayed Global Variable Update: Transmission Temperature Status = Normal // Maintain status of Transmission temp in GVL

23. Transmission Temperature High Global Variable Constraints: No Restrictions on Input // Trans Temperature is constantly monitored Response Update Trans Temperature Status to High and pass to VCM // Make VCM aware of temp Global Variable Update: Transmission Temperature Status = High // Maintain status of Transmission temp in GVL Engine Fault Status Includes Transmission Temperature High

Brake Control Module The interfaces to the BCM are illustrated in Figure 6. This is followed by a sample of the possible inputs and associated behavior requirements.

Figure 6. Brake Control Module Interface Definition

Sample Requirements 1. Zero Brake Command // driver foot is off the brake

Global Variable Constraints: None // there is no restriction on driver brake selection

Vehicle Speed

BCM

Brake Pressure

Op Braking Cmd

Brake Temperature

Front Brake CmdRear Brake CmdAntilock Brake Cmd

Brake Press StatusBrake Fault Status

Brake Temp Status

To Actuators

To VCM

Global VariablesEngine Speed StatusEngine Fault StatusWheel Lock StatusBrake Wear Status

Brake Extension


Response Apply zero brake pressure to front and rear brakes // regardless of vehicle speed Global Variable Update: No Updates // no global variables affected by this

2. Small Brake Command // driver applies small amount of pressure to brake Global Variable Constraints: None // there is no restriction on driver brake selection Response Apply small brake command to front and rear brakes // regardless of vehicle speed Global Variable Update: No Updates // no global variables affected by this

3. Medium Brake Command // driver applies medium amount of pressure to brake Global Variable Constraints: None // there is no restriction on driver brake selection Response Apply medium brake command to front and rear brakes // regardless of vehicle speed Global Variable Update: No Updates // no global variables affected by this

4. Full Brake Command // driver applies full amount of pressure to brake

Global Variable Constraints: None // there is no restriction on driver brake selection Response Apply full brake command to front and rear brakes // regardless of vehicle speed Global Variable Update: No Updates // no global variables affected by this

5. Vehicle Speed Reduced as Expected // vehicle speed slows in proportion to brake request Global Variable Constraints: Brake Wear Status = Normal // there is no noticeable wear on the brakes Response Continue applying brake pressure as commanded // based on observed vehicle speed Global Variable Update: No Updates // no global variables affected by this

6. Vehicle Speed Reduced as Expected // vehicle speed slows in proportion to brake request Global Variable Constraints: Brake Wear Status = Normal // there is no noticeable wear on the brakes Response


Continue applying brake pressure as commanded // based on observed vehicle speed Global Variable Update: No Updates // no global variables affected by this

7. Vehicle Speed Reduction Not as Expected // indication of adverse weather conditions Global Variable Constraints: Brake Wear Status = Normal // there is no noticeable wear on the brakes Response Invoke Antilock braking system // based on observed vehicle speed Global Variable Update: Wheel Lock Status = True // no global variables affected by this

8. Brake Pressure Normal Global Variable Constraints: No Restrictions on Input // Brake Pressure observed is as expected Response Send Brake Pressure to VCM // This variable is just stored in controller Global Variable Update: Brake Pressure Status = Normal // Maintain status of Fuel Pressure in GVL

9. Brake Pressure Low Global Variable Constraints: No constraints // Brake Pressure constantly monitored Response Update Brake Pressure Status to Low and pass to VCM // Make VCM aware of Brake Pressure Global Variable Update: Brake Pressure Status = Low // Maintain status of Oil pressure in GVL Brake Fault Status includes Pressure low // This is as a fault condition

10. Brake Temperature Normal Global Variable Constraints: No Restrictions on Input // Brake Temperature constantly monitored Response Update Brake Temperature Status to Normal // This variable is just stored and displayed Global Variable Update: Brake Temperature Status = Normal // Maintain status of Brake temp in GVL

11. Brake Temperature High Global Variable Constraints: No Restrictions on Input // Brake Temperature is constantly monitored Response Update Brake Temperature Status to High and pass to VCM // Make VCM aware of temp Global Variable Update:


Brake Temperature Status = High // Maintain status of Brake temp in GVL Brake Fault Status Includes Brake Temperature High 12. Brake Extension Normal // This means brakes are not excessively worn

Global Variable Constraints: Brake Wear Status = Normal Response Update Brake Wear Status to Normal // This variable is just stored in the GVL Global Variable Update: Brake Wear Status = Normal // Maintain status of Brake wear in GVL

13. Brake Extension Excessive Global Variable Constraints: No Restrictions on Input // Brake extension is constantly monitored Response Update Brake Wear Status to Excessive and pass to VCM // Make VCM aware of Brake Wear Global Variable Update: Brake Wear Status = Excessive // Maintain status of Brake wear in GVL Brake Fault Status Includes Brake Wear Excessive

Climate Control Module The interfaces to the CCM are illustrated in Figure 7. This is followed by a sample of the possible inputs and associated behavior requirements.

Figure 7. Climate Control Module Interface Definition

Sample Requirements 1. Select Heat Off // system will disable heat commands

Global Variable Constraints: Heat Select <> Off Response Set Heat Control Command to 0 // Heating element turned off Global Variable Update: Heat Selection Status = Off

CCMClimate Commands

Cab TemperatureClimate Requests

Climate Sensor Status Climate Fault StatusComponent Status

Global VariablesCooling Selection StatusHeating Selection StatusTemperature Set Point Climate Control Selections


2. Select Heat Low // selected via knob on control panel Global Variable Constraints: Heat Select <> Low Response IF (Cab temperature >= temperature set point) THEN set heat control command to 0 ELSE set Heat Control Command to Low Global Variable Update: Heat Selection Status = Low

3. Select Heat Medium Global Variable Constraints: Heat Select <> Medium Response IF (Cab temperature >= temperature set point) THEN set heat control command to 0 ELSE set Heat Control Command to Medium Global Variable Update: Heat Selection Status = Medium

4. Select Heat High Global Variable Constraints: Heat Select <> High Response IF (Cab temperature >= temperature set point) THEN set heat control command to 0 ELSE set Heat Control Command to High Global Variable Update: Heat Selection Status = High

5. Select Cooling Off // system will disable cooling commands Global Variable Constraints: Cooling Select <> Off Response Set Cooling Control Command to 0 // Heating element turned off Global Variable Update: Cooling Selection Status = Off

6. Select Cooling Low // selected via knob on control panel Global Variable Constraints: Cooling Select <> Low Response IF (Cab temperature <= temperature set point) THEN set cooling control command to 0 ELSE set Cooling Control Command to Low Global Variable Update:


Cooling Selection Status = Low 7. Select Cooling Medium

Global Variable Constraints: Cooling Select <> Medium Response IF (Cab temperature <= temperature set point) THEN set cooling control command to 0 ELSE set Cooling Control Command to Medium Global Variable Update: Cooling Selection Status = Medium

8. Select Cooling High Global Variable Constraints: Cooling Select <> High Response IF (Cab temperature <= temperature set point) THEN set cooling control command to 0 ELSE set Cooling Control Command to High Global Variable Update: Cooling Selection Status = High

9. Increase Temperature Set Point Global Variable Constraints: Heat Control Command <> Off OR Cooling Control Command <> Off // must be a climate selection Response IF (Cab temperature < temperature set point) THEN apply heat control setting command ELSE IF (Cab temperature > temperature set point) THEN apply cooling control command ELSE set climate control commands to 0 Global Variable Update: Adjust Temperature Set Point according to Selection

10. Decrease Temperature Set Point Global Variable Constraints: Heat Control Command <> Off OR Cooling Control Command <> Off // must be a climate selection Response IF (Cab temperature < temperature set point) THEN apply heat control setting command ELSE IF (Cab temperature > temperature set point) THEN apply cooling control command ELSE set climate control commands to 0 Global Variable Update: Adjust Temperature Set Point according to Selection

11. Cabin Temperature Rises Global Variable Constraints:


No constraints Response IF (Cab temperature < temperature set point) THEN apply heat control setting command ELSE IF (Cab temperature > temperature set point) THEN apply cooling control command ELSE set climate control commands to 0 Global Variable Update: Adjust Temperature Set Point according to Selection

12. Cabin Temperature Drops Global Variable Constraints: No constraints Response IF (Cab temperature < temperature set point) THEN apply heat control setting command ELSE IF (Cab temperature > temperature set point) THEN apply cooling control command ELSE set climate control commands to 0 Global Variable Update: Adjust Temperature Set Point according to Selection

13. Climate Component Failure Global Variable Constraints: No constraints Response Send notice to VCM of component failure status Global Variable Update: Climate Control Fault Status = component failure

14. Climate Sensor Failure Global Variable Constraints: No constraints Response Send notice to VCM of sensor failure status Global Variable Update: Climate Control Fault Status = sensor failure

Display Panel Module The interfaces to the DPM are illustrated in Figure 8. This is followed by a sample of the possible inputs and associated behavior requirements.


Figure 8. Display Panel Module Interface Definition

Sample Requirements 1. Select Vehicle Status Display // Subsystem simply navigates display screens

Global Variable Constraints: Display Selection <> Vehicle Status Display Response Display Vehicle Status Global Variable Update: Display Selection = Vehicle Status Display

2. Select Vehicle Mileage Display Global Variable Constraints: Display Selection <> Vehicle Mileage Display Response Display Vehicle Mileage Global Variable Update: Display Selection = Vehicle Mileage Display

3. Select Vehicle Entertainment Display Global Variable Constraints: Display Selection <> Vehicle Entertainment Display Response Display Vehicle Entertainment Options Global Variable Update: Display Selection = Vehicle Entertainment Display

4. Select AM/FM Station Global Variable Constraints: Display Selection = Vehicle Entertainment Display Response Display Selected AM/FM Station Global Variable Update: Entertainment Selection = AM/FM Station

5. Select Auxiliary Input

DPMDisplay Commands

Display Selections Global VariablesDisplay SelectionVehicle Fault StatusVehicle Fault Detected


Global Variable Constraints: Display Selection = Vehicle Entertainment Display Response Display Auxiliary Input Selection Global Variable Update: Entertainment Selection = Auxiliary Input

6. Vehicle Fault Detected Global Variable Constraints: No Constrains Response Display Vehicle Fault Information immediately Global Variable Update: No change // temporary display dialogue indicating fault

Vehicle Control Module The interfaces to the VCM are illustrated in Figure 9. The Vehicle Control Module is different from the others in that it is strictly a global state variable manager. It takes state variable update requests from the other modules and determines, based on the values of all the global state variables, whether or not to grant those update requests. So the inputs to the module are simply update requests and current state of each variable. The outputs of the module are changes to specific global variable values. Sample requirements are not provided for the VCM since it does not actually send any command outputs.

Figure 9. Vehicle Control Module Interface Definition

This concludes the specifications for each of the vehicle controller subsystems. Each of the subsystems can be designed, implemented and tested based on their respective specifications. That is a logical and manageable approach to system development. All of the subsystem documentation can then be integrated to produce the system level operational profile. Vehicle Control System Operational Profile The illustration in Figure 10 shows the integrated set of interfaces for the Vehicle Control System as a whole. The necessary elements of the operational profile are contained in the figure.

VCMGVL Status Updates

Status Update RequestsGlobal VariablesNot ApplicableCurrent GVL Status


Figure 10. Vehicle Control System Interface Specification

At the system level, the behavior specification rules are very similar to those at the subsystem level. The main difference is that no state variable information is sent as output; it’s maintained internally. To re-iterate, an operational profile is a formal specification of the behavior of a computing system at its interface. Figure 10 depicts the interfaces of the computing system that controls a vehicle as specified in the example. The operational profile can be represented as a finite state machine. To create the finite state machine the rules of behavior need to be specified for all values of all input variables under all relevant combinations of global state variable conditions. The example description contained sample rule specifications for each of the vehicle control modules. As a collection, they make up all of the rules of behavior of the control system. Each rule specifies the input value, the global variable constraints, the required system response, and the global variable updates. The set of rules, as a whole, imply a finite state machine. In order to generate the operational profile structure, the algorithm documented below should be applied. In simple terms, it contains instructions for discovering all relevant states and establishing the transitions among all of those states. This will result in a finite state machine specification of the vehicle control system.

Gear Selection Vehicle ControllerTransmission CmdSpeed Command

Engine SpeedEngine Torque

Fuel LevelFuel Pressure

Oil LevelOil Pressure

Oil Temperature

Engine Temperature

Throttle Request

Transmission Temp

Vehicle Speed

Torque Command

Global VariablesBrake StatusCurrent GearEngine Fault StatusEngine Temp StatusFuel Level StatusFuel Pressure StatusOil Level StatusOil Pressure StatusOil Temp StatusTrans Temp StatusEngine Speed StatusBrake Temp StatusBrake Pressure StatusBrake Fault StatusCooling Selection StatusHeating Selection StatusTemperature Set PointClimate Fault StatusDisplay Selection

Vehicle Speed Brake Pressure

Op Braking Cmd

Brake TemperatureBrake Extension

Front Brake CmdRear Brake Cmd

Antilock Brake Cmd

Cab TemperatureClimate Requests

Display Selections

Climate CommandsDisplayCommands


Finite State Machine Creation – Pseudo Code Integer: InputCount = TotalCount; // total number of inputs Integer: StateCount; // total number of states Array: StateList; // initial is only one state: Initial State; A State, by definition, is a UNIQUE SET OF GLOBAL VARIABLE VALUES Boolean Array: StateList.Status; Integer: i; // local variable to track inputs Set CurrentState = InitialState Select (CurrentState); For (i = 1 to InputCount) { Select Input Specification(i); IF [state constraints(Input(i)) <> state constraints(Initial State)] THEN skip Input Specification(i) ELSE // this means input IS relevant from the current state With input(i): behavior 1 Evaluate ToState // To state = Global Variable settings after OV updates Set Transition: input(i): behavior 1 From(CurrentState) -> ToState; Assign [Action] IF (ToState <> StateList) THEN // ToState is NOT identical to an identified State Add ToState(i:1) to StateList array; // ToState is a new unique state Set ToState(i:1):Status to Not Processed // ToState still needs to be processed With input(i): behavior N Evaluate ToState Set Transition: input(i): behavior N From(CurrentState) -> ToState; Assign [Action] IF (ToState <> StateList) THEN Add ToState to StateList array; Set ToState(i:N).Status to False } Set (CurrentState.Status = True) Note: State Constraints <> means the OV constraints are not satisfied by the current state for the given input; i.e. Input is not possible. Do While (NextStateIndex == NotProcessed) Select NextStateIndex; Set CurrentState = NextStateIndex; Select (CurrentState); For (i = 1 to InputCount) { Select Input Specification(i); IF [state constraints(Input(i)) <> state constraints(Initial State)] THEN skip Input Specification(i) ELSE // this means input IS relevant from the current state With input(i): behavior 1 Evaluate ToState // To state = Global Variable settings after OV updates Set Transition: input(i): behavior 1 From(CurrentState) -> ToState; Assign [Action] IF(ToState <> StateList) THEN // ToState is NOT identical to an identified State Add ToState(i:1) to StateList array; Set ToState(i:1):Status to False With input(i): behavior N Evaluate To State Set Transition: input(i): behavior N From(CurrentState) -> ToState; Assign [Action] IF(ToState <> StateList) THEN Add ToState to StateList array; Set ToState(i:N):Status to False } Set (CurrentState.Status = True)


A high level view of the state machine is illustrated in Figure 11.

Figure 11. Vehicle Control System Finite State Machine Diagram

The state machine is a structure. One more step is required to complete the operational profile – assigning probabilities to the transitions in the model. This transforms the finite state machine into a Markov Chain. A project can choose whatever method it desires in order to assign probabilities on the transitions. Keep in mind that most complex computing system will require fairly large state machine to cover the required behaviors: thousands of states and at least an order of magnitude more transitions. To create transition probabilities values for such a model can only be practically accomplished through automation. This implies that a test automation tool should be employed for that purpose. Further details on how to develop an operational profile and generate tests based on that profile are provided in a companion white paper on Operational Profile Testing.

Neutral

Forward

Reverse

ReleaseBrakes

SetBrakesTurn on/offAC

ReleaseBrakes

SetBrakesIncrease/DecreaseSpeed

ReleaseBrakes

SetBrakesIncrease/DecreaseSpeed

SelectForward

SelectNeutral SelectForward SelectReverse

SelectReverse

SelectNeutral