- Email: [email protected]
A Behavioral Analysis and Modeling Method for Real-Time Systems
A BEHAVlORAL ANALYSIS AND MODELING METHOD FOR REAL-TIME SYSTEMS Hassan Gomaa George Mason University Center for Software Systems Engineering Department of Information and Software Systems Engineering Fairfax, VA 22030-4444, USA Phone: (703) 993 1652 / 1640 E-mail: [email protected]
ABSTRACf This paper describes a method for analyzing and modeling real-time systems called Concurrent Object-Based Real-Time Analysis (COBRA) . COBRA is an alternative approach to Real-Time Structured Analysis, Object-Oriented Analysis, and lackson System Development, for analyzing and modeling real-time systems. It blends concepts from all three methods. A COBRA behavioral model can be mapped to an object-oriented design.
Thus the model is a concurrent processing model, which supports the maximum potential concurrency in the system .
1 INTRODUCfION This paper describes the Concurrent ObjectBased Real-Time Analysis (COBRA) method for analyzing and modeling the problem domain for real-time systems. It uses the same graphical notation as Real-Time Structured Analysis (RTSA) IYourdon89] to allow it to be used with existing CASE tools. The main features of COBRA arc:
d) A behavioral approach, called Behavioral Scenario Analysis, for determining how the objects and functions within a system or subsystem interact with each other. The approach uses event sequencing scenarios, which emphasize the use of control objects that execute state transition diagrams and show the state-dependent system response to incoming events from the external environment.
a) Guidelines for developing the environmental model (based on the system context diagram) b) A decomposition approach for decomposing a system into subsystems, which may potentially be distributed IGomaa89al. A set of subsystem structuring criteria are provided. Where the subsystems are to be mapped to distributed nodes, additional criteria are provided for mapping to these nodes. This aspect of COBRA is described in IGomaa92] .
This paper describes the structuring criteria for determining objects and functions in real-time systems and then describes the Behavioral Scenario Analysis approach . 2 MODELING OBJECfS IN TilE PROBLEM DOMAIN
Some Object-Oriented Analysis (OOA) methods provide criteria for determining objects in the problem domain ICoad91, ShJaer88]. For the domain of real-time systems, the following criteria are considered most relevant for determining objects in the problem domain.
c) Structuring criteria for determining the objects and functions within a subsystem. This approach is oriented towards real-time and concurrent systems by modeling each object and function as a potentially concurrent task.
43
a) External Device I/O objects. For every physical entity in the real-world that is relevant to the domain, there should be a corresponding software object in the system. In real-time systems, it is usually the case that real-world physical entities interface to the system via sensors and actuators. Hence the software objects that model these I/O devices are referred to as external device I/O objects.
activated by a control object to perform a given action. Usually this is a "one-shot" action. i.e., it performs the action once and then voluntarily stops. Conceptually, such a function executes during the transition from one state to another. c) Periodic function_ A periodic function is activated at regular intervals to perform some action. The frequency with which a periodic function is activated is application dependent.
b) Control objects. A control object is an active abstract object in the problem domain that has different states and controls the behavior of other objects. A control object is defined by means of a state transition diagram.
d) Periodic state-dependent function. A periodic state-dependent function is activated by a control object to perform some action that needs to be done at regular intervals. It is activated on entry into a state, and de-activated on leaving a state, usually the same state.
c) Data abstraction objects. For every entity in the application domain that need to be "remembered", there should be a corresponding data abstraction object. These objects model the real world entities by encapsulating the data that needs to be "remembered" as well as supporting the operations on that data.
4 BEHAVlORAL SCENARIO ANALYSIS Behavioral Scenario Analysis is an iterative approach to help determine how the objects and functions within a subsystem interact with each other. Scenarios are developed showing the sequence of internal events that follow the arrival of an external event and the eventual system response, which is frequently state dependent.
d) Algorithm objects. An algorithm object encapsulates an algorithm used in the problem domain. e) User role objects. User role objects model roles played in the application domain by users.
4.1 STEPS IN BEHAVlORAL SCENARIO ANALYSIS
3 MODELING FUNCfIONS IN THE PROBLEM DOMAIN
The main steps in the Behavioral Scenario Analysis strategy are as follows:
In addition to modeling objects in the problem domain, it is necessary to model the functions that interact with these objects. Certain functions can be immediately associated with objects. For example if a device I/O object is determined. then the functions that deal with reading from or writing to the device are associated with the device I/O object. However with other. usually internal. functions. it is often not obvious which object or objects they should be associated with. In a real·time system. there is the added complication that timing considerations are typically associated with functions and only indirectly with objects.
1) Building the Scenario a) Develop state transition diagram for the system or subsystem. This necessitates determining the externally visible states of the system / subsystem. and the events that arrive directly or indirectly from the external environment to cause the system / subsystem to change state. b) Use the state transition diagram to develop one or more scenarios. Each scenario consists of a typical sequence of external events that the system experiences. 2) Executing the Scenario
a) Asynchronous Function. An asynchronous function is activated by another object or function to perform some action . Often. it is activated by a device input object.
As each event is executed in sequence. the following steps are performed: a) For each event that leads to a state transition, determine the input from the external environment that is required to
b) Asynchronous state-dependent function . An asynchronous state-dependent function is
44
generate this event, the device I/O object needed to read this input and generate the appropriate signal event flow to the control object, which executes the state transition diagram.
(1) Idle. The engine is switched off. (2) Initial. When the driver turns the engine on, the car enters Initial state. (2) Accelerating. When the driver engages the cruise control lever in the ACCEL position (transition Accel), the car enters Accelerating state and accelerates automatically.
b) For ea cb state transition, determine all tbe actions that result from this change in state, as well as the state-dependent functional data transformations required to perform these actions.
(3) Cruising. When the driver releases the lever (transition Cruise), the current speed is saved as the cruising speed and the car enters Cruising state. In this state, the speed of the car is automatically maintained at tbe cruising speed.
c) For each triggered or enabled object or function, determine what outputs it generates. d) Show tbe external event and the subsequent internal events on both the state transition diagram and a partial data flow / control flow diagram, which is referred to as an event sequence diagram. The events are numbered to show the sequence in which they are executed.
(4) Cruising Off. When the driver presses the brake (transition Brake Pressed). the car enters Cruising Off state and returns to manual operation, with automatic control suspended.
3) Completing the Scenarios. It is necessary to ensure that the executed scenarios have:
(5) Resuming. When the driver engages tbe cruise control lever in the RESUME position (transition Resume), the car automatically accelerates or decelerates to the last cruising speed. When it reaches the desired speed, tbe car returns to Cruising state (transition Reached Cruising) .
a) Driven the state transition diagram through every state and state transition at least once. b) Each action has been performed at least once, so that each state-dependent functional data transformation has been either triggered or enabled and subsequently disabled.
Based on the state transition diagram. one or more scenarios, each consisting of a sequence of external events, are developed for the subystem. A typical scenario consists of tbe following sequence of external events:
4-2 EXAMPLE OF STATE-DEPENDENT BEHAVlORAL SCENARIO ANALYSIS The Behavioral Scenario Analysis approach is best illustrated by means of a detailed example. The following example of a Cruise Control System shows the main points of this strategy.
a) Driver engages the cruise control lever in the ACCEL position. b) Driver releases the cruise control lever in order to cruise at a constant speed.
4-2.1 BUILDING THE SCENARIO
c) Driver presses the brake to disable cruise control.
An initial attempt is made at determining the objects in the Cruise Control system. A control object Cruise Control is required. which will execute the controlling state transition diagram for the system . External device input objects are Cruise Control Lever. Engine. Brake, Throttle and Shaft.
d) Driver engages the cruise control lever in the RESUME position to resume cruise control. In addition. assume that the state transition diagram is in Initial state at the start of the scenano.
Next. the state transition diagram is developed. A simplified std is shown in Figure 1, which shows the main states of the cruise control object. the most frequently used transitions, and the events that cause these transitions. The states are:
4.2.2 EXECUTING THE SCENARIO The sequence of events in the scenario are numbered and shown on a partial data flow / control flow diagram called an event sequence
45
diagram (Figure 2). The event sequence is described next, and shown on Figures 1 and 2.
Based on this analysis, the data flow / control flow diagram showing all the objects and functions that participated in the scenario is shown in FlgW'e 2. The transformations represent objects and functions that are all at the same level of decomposition. At this stage a restructuring could be made so that the data / control flow diagrams would be at two levels of decomposition. Introducing additional levels of decomposition can clarify the presentation of the model, although it does not correspond to the way the problem was solved.
1) The driver engages the cruise control lever in the ACCEL position. The device input object, Cruise Control Lever, reads this input, shown as event 1 on Figure 2.
2) The Cruise Control Lever object sends the Accel event flow to the Cruise Control object (event 2 on Figure 2). The Cruise Control object executes the Cruise Control state transition diagram (Figure 1).
S COMPARISON WITH OTHER METHODS.
3) As a result of the transition, Increase Speed is enabled. Increase Speed is a periodic statedependent function, which adjusts the throttle value periodically so that the speed of the vehicle gradually increases. This is shown as event 3 on Figures 1 and 2.
COBRA uses the RTSA notation and emphasizes the use of state transition diagrams. However it differs from RTSA [Yourdon89] in its emphasis on concurrency and on determining objects in the problem domain. COBRA is similar to Jackson System Development (JSD) [Cameron86] in that it models entities and functions using concurrent processes. However it provides criteria for determining the objects in the problem domain and uses state transition diagrams, which are often more useful for real-time systems than ISO entity structure diagrams. Like OOA, COBRA uses object structuring criteria. However, unlike OOA, it emphasizes concurrency and flnite state machines rather than data modelling, and hence is more applicable to real-time systems. In addition, COBRA provides a comprehensive approach for behavioral analysis.
4) The next external event results from the driver deciding to release the cruise control lever. Cruise Control Lever reads this external input (event 4 in Figure 2). 5) Cruise Control Lever sends the Cruise event flow to Cruise Control (event 5 in Figure 2) . This input event causes Cruise Control to transition into Cruising state (event 5 in Figure 1), which results in three actions.
6) The flrst action is to disable Increase Speed (event 6), since the vehicle must no longer accelerate. 7) The second action is to trigger Select Desired Speed (event 7), which reads the Current Speed data store and stores this value as the Desired Speed.
6 CONCLUSIONS This paper has described the Concurrent Object-Based Real-Time Analysis method for analyzing and modeling real-time systems. After the COBRA behavioral model has been completed.. it may be mapped to an objectoriented design using the concurrent task structuring criteria IGomaa84] and the information hiding module structuring criteria IParna.s84] pro..ided by the ADARTS method IGomaa89b] .
8) The third action is to enable the function Maintain Speed (event 8), which continuously reads Current Speed and Desired Speed and adjusts the throttle value to maintain the cruising speed. 9) The next external event occurs when the driver presses the brake because of some obstacle ahead. The Brake device input object is needed to read Brake Input (event 9) .
7 REFERENCES
10) Brake generates a Brake Pressed event
flow (event 10) . As a result, the std transitions from Cruising to Cruising orr state.
ICameron 86] Cameron 1, "An Overview of IS0', IEEE Transactions on Software Engineering", February 1986. ICoad91] Coad, P. & Yourdon, E., ObjectOriented Analysis, Second Edition, Prentice Hall, 1991
11) The action associated with this transition is to disable the Maintain Speed transformation. The vehicle is now back under driver control.
46
[Gomaa 84) Gomaa H, "A Software Design Method for Real Time Systems", Communications ACM, September 1984. [Gomaa 89a) Gomaa H, "A Software Design Method for Distributed Real Time Applications", Journal of Systems and Software, March 1989. [Gomaa 89b) Gomaa H, "Structuring Criteria for Real Time System Design", Proc. 11th International Conference on Software Engineering, May 1989. [Pamas 84) Parnas D et al., "The Modular Structure of Complex Systems", Proc. 7th IEEE International Conference on Software Engineering, Orlando, F1orida, March 1984. [Shlaer 88) S. Shlaer and S. MeUor;Object Oriented Systems Analysis", Prentice Hall, 1988. [Yourdon 89) Yourdon E., Modern Structured Analysis, Prentice Hall, 1989.
I
I I
In.....!
Il"'" 00
I
Idle
I
l
"6ml
i!.D«-
3 ElIabIe "In= ... SJmOd·
Olf
JQ B[.
I
Aoodcn
1
I Il8£_ I ' Enaboc
cr.w .. Olf
I
Speed"
J
.1
. R........ CI1usq'
I
fZ2Z~
\\ o-bic . MuIL&m
Ra.mq
1~
Bs;as;~~ w~m&
16 D~c.c
I
° tu:S\llm LruUUlil
\7 E.oabI< • MuIL&m
J
,Cm 'S
47
S~·
I I
er.·1D1
t
1
Current Speed
\" \
I )
/
Off
\
15 Reached \ CruIsing 3 Enable \ e DlNbIe
Thronle Poslllon
\ Figure 2: Cruise Control System Event Sequence Diagram
Shs"
Brake Input
Input
Brake "Rel_d
Control Cruise Control Input
Requea1
Figure 3: Decomposition of Cruise Control System
48
ABSTRACf This paper describes a method for analyzing and modeling real-time systems called Concurrent Object-Based Real-Time Analysis (COBRA) . COBRA is an alternative approach to Real-Time Structured Analysis, Object-Oriented Analysis, and lackson System Development, for analyzing and modeling real-time systems. It blends concepts from all three methods. A COBRA behavioral model can be mapped to an object-oriented design.
Thus the model is a concurrent processing model, which supports the maximum potential concurrency in the system .
1 INTRODUCfION This paper describes the Concurrent ObjectBased Real-Time Analysis (COBRA) method for analyzing and modeling the problem domain for real-time systems. It uses the same graphical notation as Real-Time Structured Analysis (RTSA) IYourdon89] to allow it to be used with existing CASE tools. The main features of COBRA arc:
d) A behavioral approach, called Behavioral Scenario Analysis, for determining how the objects and functions within a system or subsystem interact with each other. The approach uses event sequencing scenarios, which emphasize the use of control objects that execute state transition diagrams and show the state-dependent system response to incoming events from the external environment.
a) Guidelines for developing the environmental model (based on the system context diagram) b) A decomposition approach for decomposing a system into subsystems, which may potentially be distributed IGomaa89al. A set of subsystem structuring criteria are provided. Where the subsystems are to be mapped to distributed nodes, additional criteria are provided for mapping to these nodes. This aspect of COBRA is described in IGomaa92] .
This paper describes the structuring criteria for determining objects and functions in real-time systems and then describes the Behavioral Scenario Analysis approach . 2 MODELING OBJECfS IN TilE PROBLEM DOMAIN
Some Object-Oriented Analysis (OOA) methods provide criteria for determining objects in the problem domain ICoad91, ShJaer88]. For the domain of real-time systems, the following criteria are considered most relevant for determining objects in the problem domain.
c) Structuring criteria for determining the objects and functions within a subsystem. This approach is oriented towards real-time and concurrent systems by modeling each object and function as a potentially concurrent task.
43
a) External Device I/O objects. For every physical entity in the real-world that is relevant to the domain, there should be a corresponding software object in the system. In real-time systems, it is usually the case that real-world physical entities interface to the system via sensors and actuators. Hence the software objects that model these I/O devices are referred to as external device I/O objects.
activated by a control object to perform a given action. Usually this is a "one-shot" action. i.e., it performs the action once and then voluntarily stops. Conceptually, such a function executes during the transition from one state to another. c) Periodic function_ A periodic function is activated at regular intervals to perform some action. The frequency with which a periodic function is activated is application dependent.
b) Control objects. A control object is an active abstract object in the problem domain that has different states and controls the behavior of other objects. A control object is defined by means of a state transition diagram.
d) Periodic state-dependent function. A periodic state-dependent function is activated by a control object to perform some action that needs to be done at regular intervals. It is activated on entry into a state, and de-activated on leaving a state, usually the same state.
c) Data abstraction objects. For every entity in the application domain that need to be "remembered", there should be a corresponding data abstraction object. These objects model the real world entities by encapsulating the data that needs to be "remembered" as well as supporting the operations on that data.
4 BEHAVlORAL SCENARIO ANALYSIS Behavioral Scenario Analysis is an iterative approach to help determine how the objects and functions within a subsystem interact with each other. Scenarios are developed showing the sequence of internal events that follow the arrival of an external event and the eventual system response, which is frequently state dependent.
d) Algorithm objects. An algorithm object encapsulates an algorithm used in the problem domain. e) User role objects. User role objects model roles played in the application domain by users.
4.1 STEPS IN BEHAVlORAL SCENARIO ANALYSIS
3 MODELING FUNCfIONS IN THE PROBLEM DOMAIN
The main steps in the Behavioral Scenario Analysis strategy are as follows:
In addition to modeling objects in the problem domain, it is necessary to model the functions that interact with these objects. Certain functions can be immediately associated with objects. For example if a device I/O object is determined. then the functions that deal with reading from or writing to the device are associated with the device I/O object. However with other. usually internal. functions. it is often not obvious which object or objects they should be associated with. In a real·time system. there is the added complication that timing considerations are typically associated with functions and only indirectly with objects.
1) Building the Scenario a) Develop state transition diagram for the system or subsystem. This necessitates determining the externally visible states of the system / subsystem. and the events that arrive directly or indirectly from the external environment to cause the system / subsystem to change state. b) Use the state transition diagram to develop one or more scenarios. Each scenario consists of a typical sequence of external events that the system experiences. 2) Executing the Scenario
a) Asynchronous Function. An asynchronous function is activated by another object or function to perform some action . Often. it is activated by a device input object.
As each event is executed in sequence. the following steps are performed: a) For each event that leads to a state transition, determine the input from the external environment that is required to
b) Asynchronous state-dependent function . An asynchronous state-dependent function is
44
generate this event, the device I/O object needed to read this input and generate the appropriate signal event flow to the control object, which executes the state transition diagram.
(1) Idle. The engine is switched off. (2) Initial. When the driver turns the engine on, the car enters Initial state. (2) Accelerating. When the driver engages the cruise control lever in the ACCEL position (transition Accel), the car enters Accelerating state and accelerates automatically.
b) For ea cb state transition, determine all tbe actions that result from this change in state, as well as the state-dependent functional data transformations required to perform these actions.
(3) Cruising. When the driver releases the lever (transition Cruise), the current speed is saved as the cruising speed and the car enters Cruising state. In this state, the speed of the car is automatically maintained at tbe cruising speed.
c) For each triggered or enabled object or function, determine what outputs it generates. d) Show tbe external event and the subsequent internal events on both the state transition diagram and a partial data flow / control flow diagram, which is referred to as an event sequence diagram. The events are numbered to show the sequence in which they are executed.
(4) Cruising Off. When the driver presses the brake (transition Brake Pressed). the car enters Cruising Off state and returns to manual operation, with automatic control suspended.
3) Completing the Scenarios. It is necessary to ensure that the executed scenarios have:
(5) Resuming. When the driver engages tbe cruise control lever in the RESUME position (transition Resume), the car automatically accelerates or decelerates to the last cruising speed. When it reaches the desired speed, tbe car returns to Cruising state (transition Reached Cruising) .
a) Driven the state transition diagram through every state and state transition at least once. b) Each action has been performed at least once, so that each state-dependent functional data transformation has been either triggered or enabled and subsequently disabled.
Based on the state transition diagram. one or more scenarios, each consisting of a sequence of external events, are developed for the subystem. A typical scenario consists of tbe following sequence of external events:
4-2 EXAMPLE OF STATE-DEPENDENT BEHAVlORAL SCENARIO ANALYSIS The Behavioral Scenario Analysis approach is best illustrated by means of a detailed example. The following example of a Cruise Control System shows the main points of this strategy.
a) Driver engages the cruise control lever in the ACCEL position. b) Driver releases the cruise control lever in order to cruise at a constant speed.
4-2.1 BUILDING THE SCENARIO
c) Driver presses the brake to disable cruise control.
An initial attempt is made at determining the objects in the Cruise Control system. A control object Cruise Control is required. which will execute the controlling state transition diagram for the system . External device input objects are Cruise Control Lever. Engine. Brake, Throttle and Shaft.
d) Driver engages the cruise control lever in the RESUME position to resume cruise control. In addition. assume that the state transition diagram is in Initial state at the start of the scenano.
Next. the state transition diagram is developed. A simplified std is shown in Figure 1, which shows the main states of the cruise control object. the most frequently used transitions, and the events that cause these transitions. The states are:
4.2.2 EXECUTING THE SCENARIO The sequence of events in the scenario are numbered and shown on a partial data flow / control flow diagram called an event sequence
45
diagram (Figure 2). The event sequence is described next, and shown on Figures 1 and 2.
Based on this analysis, the data flow / control flow diagram showing all the objects and functions that participated in the scenario is shown in FlgW'e 2. The transformations represent objects and functions that are all at the same level of decomposition. At this stage a restructuring could be made so that the data / control flow diagrams would be at two levels of decomposition. Introducing additional levels of decomposition can clarify the presentation of the model, although it does not correspond to the way the problem was solved.
1) The driver engages the cruise control lever in the ACCEL position. The device input object, Cruise Control Lever, reads this input, shown as event 1 on Figure 2.
2) The Cruise Control Lever object sends the Accel event flow to the Cruise Control object (event 2 on Figure 2). The Cruise Control object executes the Cruise Control state transition diagram (Figure 1).
S COMPARISON WITH OTHER METHODS.
3) As a result of the transition, Increase Speed is enabled. Increase Speed is a periodic statedependent function, which adjusts the throttle value periodically so that the speed of the vehicle gradually increases. This is shown as event 3 on Figures 1 and 2.
COBRA uses the RTSA notation and emphasizes the use of state transition diagrams. However it differs from RTSA [Yourdon89] in its emphasis on concurrency and on determining objects in the problem domain. COBRA is similar to Jackson System Development (JSD) [Cameron86] in that it models entities and functions using concurrent processes. However it provides criteria for determining the objects in the problem domain and uses state transition diagrams, which are often more useful for real-time systems than ISO entity structure diagrams. Like OOA, COBRA uses object structuring criteria. However, unlike OOA, it emphasizes concurrency and flnite state machines rather than data modelling, and hence is more applicable to real-time systems. In addition, COBRA provides a comprehensive approach for behavioral analysis.
4) The next external event results from the driver deciding to release the cruise control lever. Cruise Control Lever reads this external input (event 4 in Figure 2). 5) Cruise Control Lever sends the Cruise event flow to Cruise Control (event 5 in Figure 2) . This input event causes Cruise Control to transition into Cruising state (event 5 in Figure 1), which results in three actions.
6) The flrst action is to disable Increase Speed (event 6), since the vehicle must no longer accelerate. 7) The second action is to trigger Select Desired Speed (event 7), which reads the Current Speed data store and stores this value as the Desired Speed.
6 CONCLUSIONS This paper has described the Concurrent Object-Based Real-Time Analysis method for analyzing and modeling real-time systems. After the COBRA behavioral model has been completed.. it may be mapped to an objectoriented design using the concurrent task structuring criteria IGomaa84] and the information hiding module structuring criteria IParna.s84] pro..ided by the ADARTS method IGomaa89b] .
8) The third action is to enable the function Maintain Speed (event 8), which continuously reads Current Speed and Desired Speed and adjusts the throttle value to maintain the cruising speed. 9) The next external event occurs when the driver presses the brake because of some obstacle ahead. The Brake device input object is needed to read Brake Input (event 9) .
7 REFERENCES
10) Brake generates a Brake Pressed event
flow (event 10) . As a result, the std transitions from Cruising to Cruising orr state.
ICameron 86] Cameron 1, "An Overview of IS0', IEEE Transactions on Software Engineering", February 1986. ICoad91] Coad, P. & Yourdon, E., ObjectOriented Analysis, Second Edition, Prentice Hall, 1991
11) The action associated with this transition is to disable the Maintain Speed transformation. The vehicle is now back under driver control.
46
[Gomaa 84) Gomaa H, "A Software Design Method for Real Time Systems", Communications ACM, September 1984. [Gomaa 89a) Gomaa H, "A Software Design Method for Distributed Real Time Applications", Journal of Systems and Software, March 1989. [Gomaa 89b) Gomaa H, "Structuring Criteria for Real Time System Design", Proc. 11th International Conference on Software Engineering, May 1989. [Pamas 84) Parnas D et al., "The Modular Structure of Complex Systems", Proc. 7th IEEE International Conference on Software Engineering, Orlando, F1orida, March 1984. [Shlaer 88) S. Shlaer and S. MeUor;Object Oriented Systems Analysis", Prentice Hall, 1988. [Yourdon 89) Yourdon E., Modern Structured Analysis, Prentice Hall, 1989.
I
I I
In.....!
Il"'" 00
I
Idle
I
l
"6ml
i!.D«-
3 ElIabIe "In= ... SJmOd·
Olf
JQ B[.
I
Aoodcn
1
I Il8£_ I ' Enaboc
cr.w .. Olf
I
Speed"
J
.1
. R........ CI1usq'
I
fZ2Z~
\\ o-bic . MuIL&m
Ra.mq
1~
Bs;as;~~ w~m&
16 D~c.c
I
° tu:S\llm LruUUlil
\7 E.oabI< • MuIL&m
J
,Cm 'S
47
S~·
I I
er.·1D1
t
1
Current Speed
\" \
I )
/
Off
\
15 Reached \ CruIsing 3 Enable \ e DlNbIe
Thronle Poslllon
\ Figure 2: Cruise Control System Event Sequence Diagram
Shs"
Brake Input
Input
Brake "Rel_d
Control Cruise Control Input
Requea1
Figure 3: Decomposition of Cruise Control System
48