37
07/03/22 COSC-4301-01, Lecture 20 1 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

Embed Size (px)

Citation preview

Page 1: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 1

Real-Time Systems, COSC-4301-01, Lecture 20

Stefan Andrei

Page 2: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 2

Reminder of the last lecture

Visual formalism, statecharts, and STATEMATE: Statecharts

Page 3: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 3

Overview of This Lecture

Visual formalism, statecharts, and STATEMATE: Visual formalism and STATEMATE

Page 4: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 4

Finite-state machine vs Statechart (Lecture 18)

Lacks modularity Exponential state

explosion Cannot specify

absolute time and time intervals

Modular and hierarchical features

Refinement: a state decomposed into lower-level states

Clustering: set of states combined into a higher-level state

Page 5: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 5

Applications of Statecharts (Lecture 18) Specifying reactive systems.

Reactive systems are complex-driven mechanisms that interact with discrete occurrences in the environment in which they are embedded.

Examples of reactive systems: Real-time computer systems, communication devices, control

plants, VLSI circuits, airplane avionics. The reactive behavior of real-time systems cannot be

captured by specifying the outputs for every possible set of inputs.

Instead, this behavior has to be described by specifying the relationship of inputs, outputs, the system state over time.

Page 6: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 6

The Statechart language Provides graphic features (labeled boxes) to denote

states (or sets of states) and transitions between states. A transition from one state to another state takes place

when the associated events and conditions are enabled. A state can be decomposed into lower-level states via

refinement, and a set of states can be combined into a higher-level state via clustering.

This hierarchical specification approach makes it possible for the specifier to zoom-in and zoom-out of a section of the Statechart specification, thus partially remedying the exponential-state explosion problem in classical FSMs.

Page 7: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 7

More Statechart Features

Furthermore, AND and OR clustering relations, together with the notions of state exclusivity and orthogonality, can support concurrency and independence in system specification.

To develop a comprehensive tool capable not only of system specification, [Harel et al.; 1990] extended the work on Statecharts to derive high-level languages for structural and functional specification.

Page 8: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 8

Languages for structural and functional specification

The language module-charts is used to describe a structural view with a graphical display of the components of the system.

The language activity-charts is used to describe a functional view with a graphical display of the functions of the system.

They also added mechanisms that provide a friendly user interface, simulated system executions, dynamic analysis, code generation, and rapid prototyping.

The entire specification and development is known as STATEMATE.

Page 9: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 9

Statecharts In Statecharts, labeled boxes denote states and directed

edges indicate transitions between states. A transition takes place when the associated events and

conditions are enabled. An expression labeling a transition is of the form

event[condition]/action, where event is the event enabling the transition, condition

is the condition which must hold for event to enable transition, and action is the action that is executed at precisely the time when the transition is taken.

Usually, events and conditions can be treated as inputs and actions as outputs, as in traditional FSMs.

However, these three parts of the transition label are optional.

Page 10: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 10

Selected list of special events, conditions, and actions Extensions to FSMs include the use of

variables in the label of a transition, logical comparisons in conditions, and assignments in actions.

Page 11: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 11

Special events, conditions, and actions Figure 5.1 from [Cheng; 2005], page 136

Page 12: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 12

Examplestarted(ignition)[in(countdown) and

not active(emergency)] /

start(launchy);

a := b + c + 1;

d := a + 2; This label for a transition indicates that when the system is

in the countdown state, the emergency state is not active, and the triggering event “started(ignition) occurs”, then both the action “start(launch)” and the two assignments a := b + c + 1; d := a + 2; are executed in parallel.

Note that the expressions to the right of the “:=” must be side-effect free (e.g., if a=1, b=2, c=3, then after the transition is taken, a=6, d=3).

Page 13: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 13

Specifications of the behavior of the pedals for an automobile Figure 5.2 from [Cheng; 2005], page 137

Page 14: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 14

Specifications of the behavior of the pedals for an automobile Both specifications show that the automobile can be

in one of three states: stop move slow

Figure (a) shows that: When accelerator is applied, the transition from the state

“stop” to the state “speedup” occurs. The transition from the state “speedup” to the state “slow”

occurs when the brake is applied provided that the condition in the bracket is true (accelerator is not applied) etc.

Page 15: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 15

OR-Decomposition By clustering the states “speedup” and “slow” into a new state

“move”, we obtain an equivalent specification in Figure (b). The transition labeled “apply hand brake” leaving state

“move” is a high-level interrupt and denotes an exit from “move”.

Whether the system is in the state “speedup” OR “slow” does not matter. This transition takes the system from either state to “stop”.

Note that the transition labeled “apply accelerator” from state “stop” to the outside of state “move” seems ambiguous.

However, the internal default arrow attached to state “speedup” means the system enters state “speedup” (if the transition “apply accelerator” from outside state “move” is taken).

Page 16: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 16

AND-Decomposition: concurrency Is another way to reduce the number of

states. Consider the two-process mutual exclusion

problem: only one process is allowed in the critical section (C1, C2) at any given time.

Page 17: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 17

Statechart A of Mutex Solution

N1,N2

T1,N2

C1,T2

N1,T2

C1,N2 T1,T2 T1,T2 N1,C2

T1,C2

The first solution is a finite-state machine.

Page 18: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 18

Statechart B of Mutex Solution

mutex

n1

t1

c1

n2

t2

c2

P1 requests P2 requests

P2 not in c2 P1 not in c1

P1 P2

The second solution applies AND-decomposition to reduce the number of states.

Page 19: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 19

Comments over the two specifications In the second specification, if the system is in the state “mutex”, then it must be in both states “process 1” and “process 2”.

In the first specification, the initial entrance is to state “N1, N2”, whereas in the second specification, the unspecified entrance to “mutex” is solved by the default arrows to enter the pair “n1, n2”.

Transitions in “process 1” and “process 2” take place concurrently as governed by the transition labels.

Therefore, if “p1 requests” is true, then the system will be in state pair {t1, n2}.

So “process 1” and “process 2” are called orthogonal state components obtained by AND-decomposition.

Orthogonality feature can reduce the state-explosion problem.

Page 20: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 20

Delays and timeouts The event expression timeout(event, number)

represents the event that happens right after the specified number of time units have passed since the occurrence of the specified event.

In a real-time system, it is often required to specify that the system stays in state for a certain period of time.

This can be done graphically by a box (i.e., state) with a squiggle (i.e., a resistor-like notation), and a numerical bound is specified next to it.

The syntax for the duration specification is Δt1 < Δt2, where either Δti may be omitted.

A generic event stands for timeout(entered state, bound), where state is the source of the transition and bound is the specified bound.

Page 21: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 21

Condition and selection entrances To reduce the number of line drawings in a large

entrance to substates of a superstate, Statecharts employ two connectives represented by a circle.

The conditional connective C replaces two or more arrows from outside a state to this state’s substates.

This is done by drawing one arrow from outside a state to the C-connective (a circle with a C in it) and then drawing arrows from the connective to their respective substates.

The selection connective S also replaces two or more arrows from outside a state to this state’s substates.

Here, the state to be entered is selected by the value of a generic event and this value is one of the values labeling the substates.

Page 22: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 22

Condition and selection entrances. Example A robotic arm operator can move the robot arm “up”,

“down”, “left”, “right”, “forward” or “backward” by pressing one of the corresponding six buttons.

These six events can be modeled by six substates within a “move” state.

There is an arrow enters the “move” state from outside this state to the S-connective (a circle with an ‘S’ in it), but no arrows need to be drawn from this connective to the six states.

Page 23: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 23

Un-clustering

If the Statechart description is large, we can uncluster it by keeping the parts of interest large.

This is done by drawing parts of the Statechart outside of their natural boundaries.

This technique is useful for describing a large system.

However, unclustering should not be used often since it can create a tree-like structure.

Page 24: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 24

Semantics At the time of its development, Statecharts were

only a specification language with no underlying basis for formal analysis or verification.

It was not associated with any logics or algebras, and hence was often regarded as a semi-formal specification language.

Later, [Harel, Naamad; 1996] presented a semantics for Statecharts.

The behaviour of a Statechart can be defined by a simulation of the sequence of steps allowed.

Page 25: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 25

Semantics (cont) The start of a step can be triggered by one or more

events. Given the current state, we select a maximal set of

compound transitions to fire from the currently enabled set of transitions.

A compound transition is a sequence of enabled and thus executable transitions.

All the executions of a step or transition are performed in parallel.

Statecharts use the instantaneous broadcasting of events as the communication mechanism among states at any level.

Page 26: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 26

Activity-charts The language activity-charts describes the functional

decomposition of a system. It is a conceptual modeling language which

graphically shows activities or functions with rectilinear shapes.

Solid arrows indicate the flow of data items whereas dashed arrows represent the flow of control items.

Basic (or atomic) activities cannot be decomposed into lower-level activities and may be described as code in a programming language such as C.

An activity takes in input items and produces output items while it is active.

Page 27: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 27

Activity-charts (cont)

Data-stores represent buffers where databases or data structures can be stored in an activity.

Control activities appear as empty boxes in an activity chart and show the behavioral view of the system.

A control activity can control other related activities by sensing their statuses and giving commands to them.

The language of Statecharts is used to describe the contents of these control activities.

Page 28: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 28

Module-charts The language module-charts describes the system

modules (the physical components), the environment modules (external to the system), and the flow of data and control signals among these modules.

Therefore, module-charts provide a structural view of the system.

Rectilinear shapes denote modules and rectangles with dashed lines signify storage modules.

Environment modules are also represented by rectangles with dashed lines but they are outside the specified system.

Page 29: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 29

Module-charts (cont) As in the states in Statecharts, sub-modules in

module-charts may appear inside a module and several levels of encapsulation may exist.

Labeled arrows and hyper-arrows represent the flow of information between modules.

Example: module-chart of a simplified car CAR is the main component, which is decomposed into

several sub-modules, two of which are brake-system and engine-system.

The brake-system module is further decomposed into 3 sub-modules: signal processor, anti-lock braking unit, normal-braking unit.

The brake-pedal, hand-brake, accelerator, and wheel-sensors are treated as external or environment modules.

Page 30: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 30

Module-chart of a simplified car Figure 5.5 from [Cheng; 2005], page 141

Page 31: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 31

Statemate Is a commercial specification tool for the designer to

specify a system under development (SUD). The tool consists of the three graphical modeling

languages (Statecharts, activity-charts, module-charts) and the forms language.

The forms language allows the designer to enter this information for specific elements of the specification.

This information includes the actions associated with the entrance to and exit from a state, the type/structure of data items, and the definitions of compound events and conditions.

Page 32: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 32

The forms language. Example The form for a data item has fields for name,

synonym, description, definition, “consists of”, “attribute name”, and “attribute value”.

The “consists of” field is used to structure data items into components, and the “attribute value” field is used to associate the attributes with the data items.

Page 33: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 33

Available tools As a commercial product, STATEMATE has been used

for more applications than experimental specification and analysis tools.

One of the first and most notable and widely publicized application was the mission specific avionics system for the Israel Aircraft Industries’ Lavi fighter aircraft.

Part of the avionics system is specified in Statecharts. Other published applications include cruise control,

processing modeling, and communication protocols. More details about STATEMATE can be found at

http://www.ilogix.com (MAGNUM – for embedded systems; Rhapsody – based on UML).

Page 34: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 34

Summary

Visual formalism, statecharts, and STATEMATE Visual formalism and STATEMATE

Page 35: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 35

Reading suggestions

Chapter 5 of [Cheng; 2002]

Page 36: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 36

Coming up next

Final Exam: Chapters 1, 2, 3, 4, 5, and 6 of [Cheng; 2002] Chapters 1, 3, 10, and 11 of [Kopetz; 1997] Chapters 1 and 2 of [Stankovic, Spuri,

Ramamritham, Buttazzo; 1998] Chapter 10 of [Priestley; 2004] Chapters 4 and 6 of [Huth and Ryan; 2004]

Page 37: 11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei

04/20/23 COSC-4301-01, Lecture 20 37

Thank you for your attention!

Questions?