Upload
roger-daniels
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Mathematical Modeling of Real-Time Systems
By Manuel I. Capel-TuñónUniversity of Granada, Spain.
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