requirements speci cation for rt systemsasghar/lecnotes/slides5.pdf · requirements speci cation...

RequirementsSpecification for RTSystems

Reactive Systems

•Complex control-driven systems

that interact with discrete events in

the environments in which they are

embedded

•Behaviour cannot be captured by

specifying the corresponding

outputs resulting from every

possible set of inputs.

•The behaviour needs to be specified

A Bokhari, 4aa3, Fall 2008 1

by a relationship of the inputs,

outputs and system-state over time.

• Include RT systems, communication

devices, control plants, airplane

avionics etc.

No particularly dominant approach for

requirements specification

Three general classifications of

specification techniques -

informal: cannot be completely

translated into a rigorous

mathematical notation and

associated rules (English,


Flowcharting)

cannot be properly analysed, not

suitable for RT systems

semi-formal: have some kind of

structure but do not have strong

mathematical basis (UML)

formal: have rigorous mathematical

basis

Advantages and limitations

of formal methods:

•Use existing mathematical

approaches (propositional logic,

predicate calculus, set theory) or


their extensions

•More scientific aproach to

development

•Result in error discovery in earliest

stage of software development cycle

•Most RT specifications usually

based on some sort of formalism

•Formal methods perceived to be

difficult to use and Error prone

• Increase early life cycle costs

•Delay projects

•Use of formal methods in RT

systems is advocated for absolute

correctness and safety, yet they


cannot guarantee either

•Formal techniques do not provide

good ways to reason about

alternative designs or architectures.

•Mathematical correctness in

specifications may not translate into

real world correctness in the finished

system.

General uses:

Formal methods do not take an

all-encompassing role in system

development rather individual

techniques are used for parts of the


development life cycle.

Consistency checking: behavioural

requirements described using a

math based notation

Model Checking: used to verify if a

given property e. g. liveness or

deadlock freeness, is satisfied under

all conditions

Theorem Proving: axioms of system

behaviour are used to derive a proof

that the system will behave in a

given way.

Example:


Consider the requirements of a

nuclear monitoring system:

1. if the interrupt A arrives, then task

B stops executing

2. Task A begins executing upon

arrival of interrupt A

3. Either task A is executing and task

B is not, or task B is executing and

task A is not, or both are not

executing.

Let

p: Interrupt A arrives


q:Task B is executing

r:Task A is executing

The requirements can be writtens as:

p ⇒ ¬q

p ⇒ r

(r∧¬q)

∨(q

∧¬r)

∨(¬q

∧¬r)

•Difficulties in dealing with precise

temporal behaviour

•Does task A continue executing

after arrival of interrupt A and if so

how long?

•However consistency can be checked

by constructing a truth table.


Z:

•A formal specification language

based on set theory and predicate

calculus

• Schema calculus used for system

decomposition; small pieces of

specification called schemas

• Schemas combined into final

specification

•No support for defining timing

constraints

•Extensions include Object-Z

Temporal Logic: One possibility to


prove that a system meets

specifications is to use temporal logic

•A first order logic that can express

relative ordering of events

•Proof is constructed by using

axioms and inference rules manually

- tideous and error prone.

•Temporal logic does not have

capability to express absolute timing

charactristics

• It can specify that an action B will

follow an action A,

for example, TRAIN-APPROACH

followed by DOWN-GATE but


cannot specify that DOWN-GATE

will occur within a certain time

period say 5 second after the

ocurrence of TRAIN-APROACH

event

Real Time Logic (RTL)

•Two parts to a RT system

specification

•Describe it structurally and

functionally by specifying its

mechanical, electrical and electronic

components

This specifies how the components


work

•Describe the behaviour of the

system in response to actions and

events - sequence of events allowed

by system

Example:

Anti-lock breaking system

Structural-functional specification

describes the breaking system

components, sensors and how they are

interconnected

The behavioural specification shows

only the response of each component


to internal or extenal events

A behavioural specification without

the structural details is often sufficient

for verifying the satisfaction of many

timing constraints. Also to reduce

complexity, the specification language

is restricted to handle only timing

relations

Event Action Model

captures the data dependancy and

temporal ordering of computational

actions in response to events in RT

systems.


Basic Concepts

Action: a schedulable unit of work

Primitive action: atomic, consumes

bounded amount of time

Composite action: partial ordering of

primitive or other composite

actions. An action can apear more

than once in a composite action.

Notaion A;B indicates sequential

action A followed by B

A||B indicates the parallel execution of

actions A and B

State Predicate: An assertion about

the stae of the specified system


(GATE-IS-DOWN )

Event is a point in time that is

significant in describing the system

behaviour. It has four types:

1. External Event: caused by actions

outside the specified system

2. Start Event: marks the beginning

of an action (DOWN-GATE start)

3. Stop Event: marks the end of an

action

4. Transition Event: marks the

change in certain attribute of the

system (GATE-IS-DOWN

becomes true)

Timing Constraint: an assertion


about the absolute timing of system

events

RTL Features:

Function @: assigns time values to

event occurrences

@(TrainApproach, i) = x

RTL Constants: events, actions,

integers - denoted by capital letters

to distinguish from other variables

A subaction: Bi is denoted by A.Bi

Start event: denoted by ↑

Stop event: denoted by ↓


External event: denoted by Ω

Example

Specification in English:

When the train approaches the train

sensor, and is detected by the sensor,

a signal is sent to the gate controller

to initiate the lowering of the gate

at the railroad crossing.

The gate will be moved to the down

position within 30 seconds from the

time the train approach is detected

by the sensor.


The gate needs at least 15 seconds

to lower itself to the down position.

Specification in RTL:

∀x@(TrainApproach, x) ≤ @(↑ Downgte, x)∧

@(↓ Downgate, x) ≤ @(TrainAproach, x)+30

∀y@(↑ Downgate, y)+15 ≤ @(↓ Downgate, y)

Finite State Machine

A finite state machine is an abstract

machine that defines

• a finite set of conditions of

existence (called states),


• a set of behaviors or actions

performed in each of those states,

• and a set of events which cause

changes in states according to a

finite and well-defined rule set.

M = S, i, T,Σ, δ

Where S is a finite, non-empty set of

states

i is the initial state (i ∈ S)

T is the set of terminal states (T ⊆ S)

Σ is a set of alphabet of symbols

representing events that cause

transitions from one state to another

δ is a transition function δ : S × Σ → S


Example

(Textbook figure 4.2)

Disadvantages:

• Internal aspects of modules cannot

be shown

•How to break functions into

subfunctions?

• Intertask communication for

multiple FSMs

•Explosion of states

Several extensions of FSM to


ma lo td mc ee ed

TAK NAV TAK TAK TAK TAK TAK

NAV NAV NAE NAA LAN NAV NAV

NAE NAE NAE NAE NAE NAA NAE

NAA NAA NAE NAA NAA NAA NAV

LAN LAN LAN LAN LAN LAN LAN


describe, analyse and simulate

multicomponent RT systems

Two examples:

Communicating real-time state

machines (CRSM)

Statecharts

CRSM

•Designed as a single, complete and

executable specification language

•Components represented by

separate machines

•Communication only through

message passing (synchronous


one-to-one)

Basic Features

• Specification closed (environment

and computer system, senders and

receivers of all messages included)

•CSRM - a FSM with guarded

commands for transitions

•General form of transition:

g → c[τ ]

Where, g is a boolean guard over

the variables of the machine

c is an I/O or internal command


τ is a timing constraint

The guard may be omitted,

indicating a default value of true.

•CRSMs communicate using

unidirectional channels

• a channel is given a unique name

and is associated with a message or

event type (name(type))

• examples of transitions:

(count = 1) → Train Leaving?|

count := 0|Open Gate!

Where, ?, indicates receiving a

message;

!, indicates sending a message


Transitions are separated by |

• examples of channels:

Position(x y coordinates)

Deposite(character)

Open Gate

• name(target)? is the syntax of an

input command that receives an

event/message over channel

“name”, where “target” is a variable

compatiable with event type.

•To send a message or generate an

event over a channel an output

command with syntax

name(message)! is used


• I/O can only occur if channel names

match and “target” and “message”

have compatiable types.

Example

Consider a real time version of

producer/comsumer processes

interacting via a bounded buffer. (Fig

4.1, shaw)


Statecharts

•Extension of classical FSM

• statecharts = FSM + depth +

orthogonality + broadcast

communication

• Labelled boxes denote states

• directed edges indicate transitions

between states

•Transitions are labelled by

expressions of the form:

event[guard]/action

•A transition occurs when the

associated event(s) occur and


guard(s) evaluate to true

•Depth is represented by the

insideness of states

•Broadcast communication

represented by a labelled arrow

•Orthogonality represented by a line

(dashed?) between states

•Excellent for representing embeded

systems (concurrency, modularity)

• commercial products allow graphical

design, simulation, code generation

Statemate


A commercial product commonly used

tool for specification and analysis.(

Lavi fighter plane)


do:activity

Super State

event(attribute:Type)[guard]/action

Initial State Simple State

Transition

Sub state 1

Sub state 2

Sub state 3

Sub state 4

State A

Final State

ConcurrentCompositeState


Petri Nets

•Have rigorous mathematical

foundations and a graphical

representation

•Tools available for simulation and

verification of desirable properties

•Concurrency is inharently built-in

•Extention TPN can take care of

timing constraints

Consider a race between two cars,

when a starter receives ready signal

from each car, he gives a starting

signal and the cars begin to race.


Essential conditions and actions:(ref Valk:

Petri nets for systems engineering)

a) List of conditions:

p1: car a; preparing for start

p2: car a; waiting for start

p3: car a; running

p4: ready sign of car a

p5: start sign for car a

p6: starter; waiting for ready sign

p7: starter; start sign given

p8: ready sign of car b

p9: start sign for car b

p10: car b; preparing for start

p11: car b; waiting for start


p12: car b; running

b) List of actions:

t1: car a; send ready signal

t2: car a; start race

t3: starter; give start sign

t4: car b; send ready sign

t5: car b; start race

Note: Two disjoint sets of elements:

Passive

conditions, places, resources,

waiting pools, channels etc.

Active

events, transitions, actions,


execution of statements,

transmission of messages etc.

We want to build an operational

model for the example. Note that

initially car a and car b are preparing

for start. In the initial state m1 of the

system p1 = p10 = True. Also the

starter is waiting for ready sign, so

p6 = True. We can thus obtain the

following global state vector:

m1 = [p1 = T, p2 = F, p3 = F, p4 = F,

p5 = F, p6 = T, p7 = F, p8 = F,

p9 = F, p10 = T, p11 = F, p12 = F ]

In this initial state, two of the actions


(t1, t4) may occur:

By t1, car a gives the ready signal

(p1 = F, p2 = T, p4 = T )

The resulting state m2 is given by:

m2 = [p1 = F, p2 = T, p3 = F, p4 = T,

p5 = F, p6 = T, p7 = F, p8 = F,

p9 = F, p10 = T, p11 = F, p12 = F ]

Locality of action: only a few

conditions got affected by these

actions, rest of the conditions

remained untouched.

Action t1 may occur if (p1 = T ) and

(p2 = p4 = F )

Behaviour of a transition

exclusively depends on its locality,


defined as the totality of its input and

output objects together with the

element itself.

In state m2, t4 may occur to

transform m2 to m3:

m3 = [p1 = F, p2 = T, p3 = F, p4 = T,

p5 = F, p6 = T, p7 = F, p8 = T,

p9 = F, p10 = F, p11 = T, p12 = F ]

Locality of t4 is [t4, p10, p8, p11]

t1 and t4 share no conditions in

marking m1 and may occur

cocurrently taking the system directly

from state m1 to m3

Transitions with disjoint locality

occur concurrently.


Graphical Representation

Passive elements are represented by

rounded graphical symbols such as

ellipses or circles, called places

Active elements are represented by

rectangles, called transitions

Arcs connect each transition with a

set of places that represent its locality

Additionally, there may be inscriptions

such as names, tokens, expressions,

guards.

Each graphical representation has an

equivalent algebraic representation

Definition: A net is a triple


N = (P, T, F ) where

•P is a set of places

•T is a set of transitions, disjoint

from P

•F is a flow relation

F ⊆ (P × T ) ∪ (T × P ) for the set of

arcs.

• If P and T are finite, the net is said

to be finite.

The net discussed in the example can

be represented graphically by Figure 1


Figure 1:


Figure 2: Occurrence sequence of tran-

sitions


Figure 3: Flow chart Petri net equiva-

lents


Figure 4: Resource Sharing Example


Real-time Communication

•Data flow from sensors and control

pannels

•Between procesors in the central

cluster of processors

•From processors to actuators

•Communication overhead adds to

the computer response time

•Need to have an upper bound on

communication overhead

•Even in case of multimedia and

videoconferencing this upper bund is

important to ensure quality of

service


•Need communication protocols

•Real time protocols ensure message

delivery by certain deadline

Sources of message delay:

•Transforming the messge into

packets

•Waiting for access to

communication media

•Messege propagation time

•Reproducing message from packets

Two catagories of RT traffic:


1. Constant Rate: Fixed sized packets

at periodic intervals

2. Variable rate: Fixed sized packets at

irregular intervals or variable sized

packets at regular intervals

Bursty traffic makes greater demands

on buffer space.

Communication Media

Electricl Medium

Optical Fibers

Wireless


Network Topologies

BusShared network

RingPoint-to-point network

Mesh

Hybrid

Sending Messages

Circuit Switching

Packet Switching

Wormhole Routing

Protocols


Contention Based:

CSMA (Carrier Sensed Multiple

Access)

• tij - propagation delay between

nodes i, j

•Node ’m’ tramsmits from time t1 to

t2

•Node ’n’ sees transmission on the

net that ends at t2 + tmn


•Node ’q’ sees transmission on the

net that ends at t2 + tmq

•Node ’n’ starts transmitting at

t2 + tmn + ε

•This transmission is not seen by ’q’

until t2 + tmn + ε + tnq

•The node ’q’ can start transmission

of a packet any time between

(t2 + tmn) and (t2 + tmn + ε + tnq)

thinking that the net is free

although it is not

•Result - packets collide and must be

retransmitted after random wait.

•Most common and has a high

bandwidth


•Effcient when end to end

transmission delay is much less than

the average time for transmission of

a packet and the load not very high

•Unbounded in nature

•How to implement priorities?

1.VTCSMA(Virtual-time Carrier

Sensed Multiple Access)

Protocol

2.Token Ring Protocol (IEEE

802.5)

VTCSMA allows priorities for different

classes of packets


At any given time, a node that has a

set of packets to transmit has a

knowledge of:

•The state of the channel

•Priorities of the packets waiting for

transmision in its buffer

•Time according to the synchronized

clock

•Has no information about the

priorities of packets waiting for

transmission at other nodes

• If priorities can be calculated as

function of curent time as well as

some other parameters, some global


ordering of priorities may be posible.

•VTCSMA does just that.

•Two clocks at each node (Real and

Virtual)

•When the channel is busy the VC

freezes

•When the channel is free VC is reset

according to a predetermined

formula and runs faster than RC


IEEE 802.5 Token Ring Protocol

•Transmission of packets on the net

controlled by a token (a small data

packet 1-2 bytes long)

•A node is allowed to start

transmission only if it holds the

token (only one token in the net)

•A node may hold the token for at

most a preset token-holding-time

(default 10 ms)

•Packets are sent to the next

neighbour where they are

retransmitted (destination node

copies before retransmission)


•Only one node can transmit - no

collisions

•There are bounded delays -

propagation delay in the medium,

token transmission time, token

capture delay, network interface

latency

•Deterministic

•Priorities can be enforced

•Data packet format: SD(starting

delimitor), AC(access control),

ED(ending delimiter),

DA(destination address), SA(source

address), message, error-control,

ED(ending delimiter), FS(frame


status)

•AC (access control) field of a

packet contains 3 bit fields for

current and reserved priorities

•As a packet passes by a node, it can

look at the current and reserved

priority settings of the access

control field

• If the current setting of reserved

field is equal to or greater than the

highest priority packets that this

node is waiting to transmit, it does

not make any changes (another

node has already reserved its turn

for packets of equal or higher


priority)

• If the setting is lower to the priority

of packets that this node is holding,

then it sets the reserved priority field

to the highest priority of its packets.

•The node holding the token, sends

the token to the node that last

changed the reserved field settings.

Example:

•Consider a net with five nodes whith

highest priorities of packets waiting

for transmission at each as follows:

n1 = 2, n2 = 4, n3 = 1, n4 = 6, n5 = 8


• Lower the index the higher the

priority i. e. n3 has the highest

priority

•Assume n1 is currently transmitting,

it writes 2 in priority reservation field

•When packet passes by n2, n4, n5,

they do not change the settings but

n3 does

•When n1 is done it generates a

token with priority 1 and sends it to

node n3

•The token cannot be captured by

any other node except node 3, as

others have priorities lower than 1.


requirements speci cation for rt systemsasghar/lecnotes/slides5.pdf · requirements speci cation...

Documents