Mathematical Modeling of Real-Time Systems

By Manuel I. Capel-TuñónUniversity of Granada, Spain.

mcapel@ugr.es

Prepared for the MAMOTEP’01

July 2001. Presov (Slovak Republic)

Overview– A class of methods for structured

requirements analysis and specification of reactive systems will be introduced.

– Integration between SA and behavioral formal descriptive methods.

– And also a procedure for the systematic transformation of structured schemes into CSP+T process terms which formally document real time systems

Structured Analysis Methods in a nutshell

Consist of a set of techniques and modelling tools useful to clarify the system user requirements

Produce a model based on a “double view of the system” :– from the information processing capability – from the control state evolution over time

Applicable to a wide range of systems: business, manufacturing, process control, communications, house automation, medical, military systems, etc.

Formal system specification

Timing constraints are specified

in a later phase of the system

requirements specification

The processes are not formally

specified,

neither is any data formal

specification carried out

The system timing constraints

are specified at same time that

system functional requirements

A formal specification of every

process behaviour is carried out

Compatible with data algebraic

specifications

Structured Analysis Methods CSP+T Formal Specification

Objectives:

To bring Software Engineering procedures to real-time systems formal development,

correct-by-construction system designs by systematic transformation of high level schemes.

To explore timed process algebra technology -a promising way to close the gap between design specifications and executable programs-

Modeling & Validation Characteristics

real time systems are very complex to specify, because of their reactive nature

properties that must satisfy these systems: – concurrent properties (safety, liveness, etc.)– timing constraint restrictions

is necessary to elaborate 2 models:– model of the system– model of the environment

q the specification methods have to include a model of time

Introduction to the development of real time systems

Abstraction

( R ) ( S ) ( D ) ( I )

Milestones

Phases:

R

Time, cost

Architectural Design

SI

Detailed Design

RequirementAnalysis

FAD

DD

System Implementation

The waterfall life-cycle model

is not an iterative life-cycle model

the completion of a phase exhausts all the

activities referred to in this phase

does not contemplate the use of prototypes

excludes the evolutionary development of a

system

Limitations of the waterfall life-cycle model

An evolutionary life-cycle model

Test

System feasibility

System specification

Prototype 1

Prototype N

Operational system

Enhancement 1

Enhancement N

System retirement

Design

Implementation

Systemlife cycle

Specification

The requirements model

LogicalLevel

ConceptualLevel

SpecificationLevel

What the desired system is, before describing how to produce it.

The behavioural model allows a dynamical analysis of the system

RT/SA methods must allow timing constraint specification

System Requirements Analysis

How does the system behave with respect

to stimuli from the environment?

The perfect technology hypothesis is

established.

Functional requirements must be structured

in primitive system functions.

Design phase

Architectural Design– Structuring in components: Information- hiding

modules, Tasks

– Interconnection of the system components Detailed Design

– Algorithmically defines each system component

– Design guaranteeing the safety properties (mutual exclusion, deadlock absence...).

The system specification process

Initial

System

Requeriments

Determine

System

Architecture

Sub-system-1 specification

Sub-system

Integration

& Testing

Integration

issues

Determine

Sub-system

Requeriments

Determine

Sub-system

Design

Sub-system-2 specification

Sub-system

Integration

& Testing

Integration

issues

Determine

Sub-system

Requeriments

Determine

Sub-system

Design

Sub-system-N specification

Sub-system

Integration

& Testing

Integration

issues

Tested Nth

Sub-system

Tested 2nd

Sub-system

System

in service

System user

requeriments

Other development phases

Coding phase– a concurrent programming language should be used

–or a sequential language and a real time kernel

Software validation phase– non-determinism implies that the number of tests

depends exponentially on the size of the program

–it is necessary to develop a model of the system environment

Real Time Structured Analysis

Hierarchy of transformation

schemes named essential model

Describes system requirements

irrespective of the system

operation

Produces a system specification

following a top-down strategy

and successive refinement

Data/Control Stores

one-on-one zero-or-many divides into

The entity relations

Flows

TransformationProcesses

Terminators

SystemContext Diagram

Transformation

Scheme

TransformationScheme

ProcessSpecification

(PSPEC)

StateTransitionDiagram

(STD)

is a

Data Flow Diag.

The System Context Diagram Highest scheme of the system

requirements essential model.Terminator entities mark the

limits of the essential modelThe system environment is

assumed to be unstructured The associated data dictionary

may contain: terminators, flows and stores.

tea bagcontrolsystem

0

scales

operator

robot arm

new tea bagweight limits

tea bagweight

robot armcommands

new position

start/stop

Data Flow Diagrams

Passive entities:– Flows,

– Data Stores (DS)

Active entities:– Data Transformation

Processes (DTPs)

– Control Transformation Processes (CTPs)

– Control Stores (CS)

control teabag boxing

check forfull box

weighteabag

tea bag count

read position

wrong

weight

box

full

E/DE/D

arm

position

start/stop

robot armcommands

new position

new teabagweight limits

teabagweight

Elements of representation:

The State Transition Diagram

is used to show the dynamic

behaviour of the system

any input/output event flow

results in the occurrence of a

condition/action in its STD

each STD defines a unique

control state in the associated

transformation process

authorized user

D:verify_logonE:get_user_comm.

E:verify login

Login on

choose menu option

transition

condition

actions

Editing data

displaying

logout

E:verify_logonD:get_user_comm.

displayE:display dataD:get_user_co

quit display

D:display dataE:get_user_co

edit

E:edit dataD:get_user_co D:edit data

E:get_user_co

quit edit

Synchronizing control processes

actions, within a STD, can be used to synchronize different control processes

discrete/continuous event flows may be used

continuous event flows towards terminators are prohibited

(a)

tank full

reaction over

reacting

reaction timer expires

SIGNAL reaction over

Controlreaction

Controltank

reaction over

(b)Controlheater

Controlfan

hot

heater on

heater onand blowing

cooled down

Lower: hot

hot enough

Raise: hot

fan off

fan on

on OR hot

switch on

off OR NOT hot

switch off

Limitations of RT/SA method in the analysis of systems

does not provide a clear description of the

dynamics of the modeled system

does not consider objects as another class of

analysis entities within the essential model

lacks subsystem identification criteria for

distributed systems

Behavioural Analysis

External events identification Initial object determination Completes the STD

specification of the control processes

Develops system scenarios Builds the event sequence

diagram

The Behavioural Model

Construction of the event sequence diagram

Environment inputs:– start/stop,

– teabag weight

– new position

– new teabag limits

Conditions:– start/stop

– wrong weight

– box full

External events definition:

control teabag boxing

check forfull box

weighteabag

tea bag count

read position

wrong weight 4

box full 8

Enable3, 13

/ Disable9Enable2,7,12

/ Disable5,10

arm

position

start1

/ stop14

robot armCommands6, 11

new position

new teabagweight limits

teabagweight

Communicating Sequential Processes

A useful design method inspired by the C.A.R. Hoare’s CSP theory

The communication encapsulates synchronization, scheduling and data transfer,

– it is unbuffered and provides a “rendez-vous” synchronisation mechanism,

– it may be efficiently implemented in multicomputers.

Process A Process B

datawriter reader

Process thread A thread B synchronization

Communication:

Synchronization:

PA

data flow

PB

PA! d || PB ? x

d

dPendingmessage

Maintaining parallelism from analysis to implementation stages.

Multithreading does not guarantee well-

structured programs

For parallel programming, the concept

of process is more safe than that of

“thread”

Parallel programs consisting of

processes are scaleable, portable on

multiprocessor systems The CSP theory provides a formal

handle on problems like deadlock, livelock and process starvation.

-identification-name-description

-geometric parallelism-communic. structure-process interface

sequential language + multithreading

Analysis identification of processes

Design Parallel models (paradigms)

ImplementationParallel language

or

Time constrained specificationsusing CSP+T (i)

Process instantiation event :–Proccesses need instantiation before they can be executed

–The event occurs within a unique global time framework

The time capture operator :–Serves to record the time at which an event is observed.

–Allows us to define timing relationships which depend on a preceding event

P’ = 1. a STOP

< >

< 1. , t.a >

< 1. >

t [1, )

P’ = 1. {u,v,x,y}avSTOP

Marked variables capture the time associated to events:

< 1. , ta.a >

< 1. >

ta [1, )

<>

u = v = x = y = 1

v = ta

Time constrained specificationsusing CSP+T (ii)

While the event enabling interval E lasts the process is able to engage in that event.

These intervals are defined over a set of marked variables.

Its use influences the parallel composition of processes. < 1. , v.a, s.b >

P’ = 1. avbE.c STOP E= {t / rel (3,v) t rel(5,v)}

< >

< 1. , ta.a > v= ta

< 1. >

s ]ta + 5, )

s [ta+3, ta + 5]

STOP

< 1. , v.a, s.b, u.c >

STOP

Generation of a CSP+T specification from the essential model

1) Prepare the schemes obtained of the RT/SA for transformation

2) Transform the schemes of lower level to CSP+T processes

3) Build a process for each DS, CS, DTP, CTP or continuous data flow that appear in a scheme.

4) Define a process which models the complete scheme

5) Repeat steps (3) and (4) until obtaining a process which models the System Context Diagram

Process term interface calculation

DO1

O2

f

f

Applying Rule I .1

{Interface (pr(O1))} U {f ! x}

{Interface (pr(O2))} U {f ! x}

{Interface (pr(D))} U {f ? x}

C1

eventApplying Rule I .2

{Interface (pr(D))} U {event}

{Interface (pr(C1))} U {event}

Modelling State Transition Diagrams

qi

qk

conditionaction

Qi= c (a Qk)

Qk

c

a

Rule D.1 Rule D.4

Substitute c by cmc or a by ama

if c or a are marker events

Substitute c by I(e).c or a by I(e).a

if c or a are restricted events

Rule D.5 P2= wrong_weight tdisable_WTBarm_pos?posP3

..

.

.

P4 = I1(wrong_weight, x1).arm_movement t P5

Teabag monitoring system example

// compute x1 = f(arm_position, tpos)

Modeling Data and Control Processes

Rule E.1:

1) Pre-calculate the interface pr(P) by the application of the rules I

R Q

enable/disable

Example of rule application

C

R Q

T

Include control signals by Rule E.2:

pr(Q) = enable Q ^ DIS

DIS = disable pr(Q)

pr(R) = enable R ^ DIS

DIS = disable pr(R)

2) Write pr(P) = T \ {(T) - interface(pr(P))}

Modeling Data and Control Processes

Rule E.1:

1) Pre-calculate the interface pr(P) by the application of the rules I

R Q

enable/disable

Example of rule application

Include control signals by Rule E.2:

pr(Q’) = enable Q ^ DIS

DIS = disable pr(Q’)

pr(R’) = enable R ^ DIS

DIS = disable pr(R’)

Interface(pr(P))= {f1, f2}

f1

f2

P

2) Write pr(P) = T \ {(T) - interface(pr(P))}

Modeling continuous data flows

P Q

f Rule C.1:

pr(f) = f ? x S

S = f ? x S | f ! x S

pr(f)

f ? x

S

SS

f ? x f ! x

Teabag monitoring system example

SYNC0 = arm_posit’ ? x U1

U1 = (arm_posit’ ? x | arm_posit ! x U1)

SYNC0

arm_posit’

arm_posit

A complete specification

The problem:Design a closed loop control

system for controlling an AC engine which must be able to maintain a constant air flow through a filter.

The system should address its own safety if the synchronization signal fails or the triac overheats.

220 v

50 Hz

TriacExcitation

AC outputtime controlable

The System Context Diagram

System

Sync

Generator

TriacFlow

sensor

flow

ºC sensor

overheat

ref

oheatf

syncf

texct

sync

0

Initial decomposition of the system

PID computation process requirements:

– Read flow sensor values, 10 times per second.

– Compute the new reference value: timeval.

Open Loop Control process:– Divides into 2 new processesoverheat

ref

oheatf syncf

texct

sync

flow

timeval

OpenLoop

Control

PIDComput

ation1.2

1.1

The open loop control process

Timeval: time in ms. to wait before generating a new excitation of the TRIAC.

No excitation generated during a complete AC voltage cycle (10 ms.) causes the loss of the synchronization signal.

The maximum permissible

error limit is 1 millisecond.syncftexct

synctimeval

disable

overheat

oheatf

Overheat

watchdogExcitation

generation2.1

2.2

The excitation generation process

x:= timeval

sync 11 ms.syncf

x ms.texct

1) Applying rule D.1:

Q1 = timeval ? x Q2

Q2 = [t, t+11].sync t Q3

Q2 = ]t+11, ].syncf Q1

Q3 = [t+x-0.1, t+x+0.1].textc Q1

2) Applying rule D.2:

Q2 = I1(t).sync t Q3 | Q2 = I2(t).syncf Q1

3) Applying rule E.2:

DIS = disable STOP4) Applying rule J.1:

EG = (init t Q1) || DIS

The overheat watchdog control process

disable

overheat

oheatf

Overheat

watchdog

2.2

overheatoheatf, disable

Applying rule D.1:OW = Q0 = overheat ot (oheatf (I0(ot).disable Q0))

I0(ot) = [ot, ot+1000

PID computation data transformation process

The data transformation PID is abstracted in:

timeval:= pid(valref, valflow)

1) Applying rule D.1 :

PID = init t Q4

Q4 = I4(t).flow ? valflow t Q5

Q5 = ref ? valref(timeval’ ! pid(valref,valflow)Q4)

2) Applying rule C.1 :

SYNC0 = timeval’ ? x Q6

Q6 = timeval’ ? x Q6 | timeval ! x Q6

ref

flow

timevalPID

Computation1.2

Integration of transformation schemes (i)

disable

overheat

oheatf

Overheat

watchdog2.2

OW = Q0

syncftexct

sync

timeval

Excitation

generation2.1

EG = (init t Q1) || DIS

OLC = OW || EG \ {init, disable}

disable

Integration of transformation schemes (ii)

ref

oheatfOLC\{disable} || PID\{init} || SYNC0

overheatsyncf

texct

sync

timeval

OpenLoop

Control

1.1

flow

PIDComput

ation

1.2

(SYSTEM = )\{timeval}

timeval

Structured Analysis methods:

Summary & Conclusions The disadvantages of a non-evolutionary software development life-

cycle have been studied:

–lack of iteration and non-overlapping between successive phases

–a working system only becomes available late in the life cycle

–reuse and facility of system maintenance and evolution are not encouraged

The fundamental techniques regarding RT/SA method for specifying system user requirements have been reviewed:

–Functional and control decomposition proposed by the essential model

– The environmental model, which includes specific criteria for system structuring and object identification

–The system dynamics analysis provided by the behavioural model

Formal System Specification with CSP+T:

Summary & Conclusions Communicating processes are a sound basis for developing

efficient, scalable, modular and portable parallel programs in distributed real time systems

The specification of such systems using the CSP+T formal description language to develop reliable parallel software has been carried out

The method is engineering oriented and also provides a sound theoretical foundation which can be used in formal verification of programs and to obtain running prototypes of complex RT systems