Mathematical Modeling of Real-Time Systems

1. Mathematical Modeling of Real-Time Systems 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 By Manuel I. Capel-TuñónUniversity of Granada, Spain.mcapel@ugr.es

2. 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.

3. 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 Formal system specification CSP+T Formal Specification Structured Analysis Methods

4. 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-

5. 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

6. Abstraction Requirement Analysis R F Phases: AD Architectural Design DD Detailed Design SI System Implementation cost Time, ( D ) ( R ) ( S ) ( I ) Milestones Introduction to the development of real time systems The waterfall life-cycle model

7. Limitations of 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

8. An evolutionary life-cycle model System feasibility System specification Prototype 1 Prototype N Operational system Enhancement 1 Enhancement N System retirement Design Specification System life cycle Test Implementation

9. Conceptual Model Conceptual Level behaviour functionality abstraction Logical Level functional decomposition control design Behavioural Model Specification Level behaviour functionality The requirements model • 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

10. 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.

11. 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...).

12. The system specification process System user requeriments Determine System Architecture Sub-system Integration & Testing Initial System Requeriments Integration issues System in service Sub-system-1 specification Tested 2nd Sub-system Determine Sub-system Design Sub-system Integration & Testing Determine Sub-system Requeriments Integration issues Sub-system-2 specification Tested Nth Sub-system Sub-system-N specification Sub-system Integration & Testing Determine Sub-system Design Determine Sub-system Requeriments Integration issues

13. 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

14. Data/Control Stores Terminators Flows Transformation Processes StateTransition Diagram (STD) Process Specification (PSPEC) Transformation Scheme one-on-one zero-or-many 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 System Context Diagram Data Flow Diag. Transformation Scheme The entity relations divides into is a

15. tea bag scales weight robot arm commands tea bag control robot arm system 0 new tea bag weight limits new position start/ stop operator The System Context Diagram • Highest scheme of the system requirements essential model. • Terminator entities mark the limits of the essential model • The system environment is assumed to be unstructured • The associated data dictionary may contain: terminators, flows and stores.

16. teabag weight tea bag count weigh check for wrong teabag box full box weight full E/D E/D new teabag weight limits control tea bag boxing arm read position position new start/ position stop robot arm commands Data Flow Diagrams Elements of representation: • Passive entities: • Flows, • Data Stores (DS) • Active entities: • Data Transformation Processes (DTPs) • Control Transformation Processes (CTPs) • Control Stores (CS)

17. E:verify login Login on condition logout authorized user transition D:verify_logon E:verify_logon E:get_user_comm. D:get_user_comm. actions choose menu option display E:edit data E:display data D:get_user_co edit D:get_user_co quit edit Editing data displaying D:edit data E:get_user_co quit display D:display data E:get_user_co 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

18. reaction over Control reaction Control tank tank full reacting reaction over reaction timer expires SIGNAL reaction over (b) hot Control heater Control fan heater on fan off hot enough cooled down on OR hot off OR NOT hot Raise: hot Lower: hot switch on switch off heater on and blowing fan on Synchronizing control processes (a) • 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

19. 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

20. Control description system structuring criteria external events State -Transition Diagram(s) (STDs) Event Sequence Diagram system scenarios 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

21. teabag weight tea bag count weigh check for weight 4 wrong teabag full box full 8 box new teabag weight limits Enable3, 13 / Disable9 Enable2,7,12 / Disable5,10 control tea bag boxing arm read position position new start1 position / stop14 robot arm Commands6, 11 Construction of the event sequence diagram External events definition: • Environment inputs: • start/stop, • teabag weight • new position • new teabag limits • Conditions: • start/stop • wrong weight • box full

22. Communicating Sequential Processes Communication: • 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. data writer reader Process A Process B Synchronization: PA! d || PB ? x PA PB d data flow d thread A thread B synchronization Process Pending message

23. Analysis identification of processes 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 Design Parallel models (paradigms) -geometric parallelism -communic. structure -process interface Implementation Parallel language or sequential language + multithreading

24. < > P’ = 1.   a  STOP < 1. > < 1. >  < 1. , t.a> ta [1, ) t  [1, ) Marked variables capture the time associated to events: P’ = 1.  {u,v,x,y}avSTOP  <> u = v = x = y = 1 < 1. , ta.a> v = ta 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

25. Time constrained specificationsusing CSP+T (ii) P’ = 1. avbE.c STOP • 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. E= {t / rel (3,v)  t  rel(5,v)}  < > < 1. > < 1. , ta.a> v= ta s  [ta+3, ta + 5] < 1. , v.a, s.b> s  ]ta + 5, ) < 1. , v.a, s.b, u.c> STOP STOP

26. 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

27. {Interface (pr(O1))} U {f ! x} {Interface (pr(O2))} U {f ! x} {Interface (pr(D))} U {f ? x} Process term interface calculation Applying Rule I .1 f D O1 f event Applying Rule I .2 O2 {Interface (pr(D))} U {event} {Interface (pr(C1))} U {event} C1

28. Rule D.1 Rule D.4 qi Qi= c (a  Qk) Substitute c by cmc ora by ama if c or a are marker events c condition action qk a Qk Teabag monitoring system example Rule D.5 P2= wrong_weight tdisable_WTBarm_pos?posP3 . . . . P4 = I1(wrong_weight, x1).arm_movement t  P5 // compute x1 = f(arm_position, tpos) Substitute c by I(e).c or a by I(e).a if c or a are restricted events Modelling State Transition Diagrams

29. Rule E.1: 1) Pre-calculate the interface pr(P) by the application of the rules I R Q enable/ disable 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) T R Q C Modeling Data and Control Processes Example of rule application 2) Write pr(P) = T \ {(T) - interface(pr(P))}

30. Rule E.1: 1) Pre-calculate the interface pr(P) by the application of the rules I R Q enable/ disable Include control signals by Rule E.2: f1 P pr(Q’) = enable  Q ^ DIS DIS = disable  pr(Q’) pr(R’) = enable  R ^ DIS DIS = disable  pr(R’) Interface(pr(P))= {f1, f2} f2 Modeling Data and Control Processes Example of rule application 2) Write pr(P) = T \ {(T) - interface(pr(P))}

31. f P Q Teabag monitoring system example pr(f) Rule C.1: f ? x arm_posit pr(f) = f ? x  S S = f ? x  S | f ! x  S SYNC0 S f ? x f ! x S S SYNC0 = arm_posit’ ? x U1 U1 = (arm_posit’ ? x | arm_posit ! x U1) arm_posit’ Modeling continuous data flows

32. 220 v 50 Hz Triac Excitation time controlable AC output 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.

33. Flow sensor ºC sensor Triac The System Context Diagram ref Sync Generator sync syncf System oheatf 0 texct overheat flow

34. ref sync timeval PID Comput ation 1.2 Open Loop Control flow 1.1 texct overheat syncf oheatf 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 processes

35. overheat sync timeval disable Overheat watchdog 2.2 Excitation generation 2.1 texct oheatf syncf 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.

36. x:= timeval 11 ms. sync syncf x ms. texct The excitation generation process 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  STOP 4) Applying rule J.1: EG = (init  t  Q1) || DIS

37. overheat oheatf, disable The overheat watchdog control process overheat disable Overheat watchdog 2.2 oheatf Applying rule D.1: OW = Q0 = overheat  ot  (oheatf (I0(ot).disable  Q0)) I0(ot) = [ot, ot+1000

38. The data transformation PID is abstracted in: timeval:= pid(valref, valflow) ref timeval 1) Applying rule D.1 : PID Comput ation PID = init  t  Q4 Q4 = I4(t).flow ? valflow  t  Q5 Q5 = ref ? valref(timeval’ ! pid(valref,valflow)Q4) 1.2 flow 2) Applying rule C.1 : SYNC0 = timeval’ ? x  Q6 Q6 = timeval’ ? x  Q6 | timeval ! x  Q6 PID computation data transformation process

39. timeval overheat EG = (init  t Q1) || DIS OW = Q0 sync disable Overheat watchdog OLC = OW || EG \ {init, disable} 2.2 Excitation generation disable 2.1 texct oheatf syncf Integration of transformation schemes (i)

40. ref sync timeval timeval Open Loop Control PID Comput ation 1.1 1.2 texct overheat syncf flow oheatf OLC\{disable} || PID\{init} || SYNC0 )\{timeval} ( SYSTEM = Integration of transformation schemes (ii)

41. 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

42. 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