Research Laboratory for Proactive Technologies |||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology ISP 0012 Software dynamics Tarkvara dnaamika upgraded in 2015 Prof. Leo Motus Research Laboratory for Proactive Technologies Dept of Computer Control, Tallinn University of Technology 1 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 2 Goals of the course To explain the essence of: new types of computing systems that apply proactive, ubiquitous, pervasive, autonomous, interactive, mobile, distributed, grid, cloud, fog, and other computing methods the new requirements to computing systems, emerged from new applications To describe: How computer science has responded to those changes A specific time-aware, interaction-centred model of computation To empasise: The importance of time (and situation) awareness Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 3 The course focuses on: Pointing to non-classical models of computation in particular, stream-based, and interaction-centred computing, as compared to conventional computing Possibilities for achieving time deterministic behaviour of event driven software Main sources of time constraints, and reasons for introducing quantitative time restrictions Increasing the situation awareness of computation A formalism for early detection of the incoherence in requirements, specifications and design, and emergent behaviour Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 4 The students performance is assessed based on individual contribution Hands-on exercises comprises in tasks solved by small groups The solution is to be publicly explained. Successfully solved task provides access to examination The course concludes with written examination paper 10 questions, maximum number of points is 100; each question could provide from 0 to 10 points 0-50 points failed (0); points weak (1); points satisfactory (2); points good (3); points very good (4); points excellent (5) All books, papers, files and other supporting information sources can be used at all checks. Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 5 Expected from students 1.Read selected chapters of the recommended text-books and referred publications (homework) 2.Study thoroughly, try to understand the difference from conventional (Turing computable functions based) computation, discuss with others the material presented at lectures, and/or questions given (homework) 3.Attend at least 70% of the lectures 4.Participate in solving the hands-on exercise, and in public presentation of the solved toy-project in due time Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 6 A selection of textbooks 1.L. Motus and M.G. Rodd (1994) Timing Analysis of real-time software, Elsevier Science 2.H. Simon (1996) The Science of the Artificial, MIT Press 3.D.Goldin, S.A. Smolka, P. Wegner (2006) Interactive Computation. The new paradigm, Springer 4.H. Kopetz (1997) Real-time systems: Design principles for distributed embedded applications, Kluwer Academic Publishers 5.References to journal and/or conference papers given at the lectures. Contents Examples, that would prefer non-classical models of computation Evolution of computer applications: Transformational computing systems Reactive computing systems Proactive computing systems Appropriate models of computation Turing computation (classical model of computation) Non-classical models of computation A prototype of a non-classical model of computation Behavioural analysis of systems static and dynamic properties Verification issues in typical 21. century computing systems 7 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 8 It is impossible to begin to learn that which one thinks one already knows Epictetus Greek stoic philosopher, 55 135 AD Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 9 A generic real-time (embedded) system Controlled object Humans Computer system Microprocessor, multiprocessor, LAN,WAN, etc Car breaking system, chemical processes, car assembly, NEC applications, mirror- universe applications, etc Conventional computation (ballistic computation) Usually a computing process is defined as p: dom p val p dom - domain of definition, val - value range. This definition is sufficient for data processing systems with completely known causal relations Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 10 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 11 Adding situational information enables formal analysis of behaviour (also in non-ballistic computation) 12 Difference between transformational and reactive / proactive systems dom pval p p In transformational computing p: dom p val p (string processing) Reactive and proactive computingp: T(p) x dom p val p (stream processing) T(p) enumerable set Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 13 Why are reactive and proactive applications uncomfortable for computer science? Violation of traditional canons: non-terminating, or on-going processing of one, or more data-streams forced concurrency violates the non-interference principle absence of pre-determined order of activities (caused by proactivity), or dynamic change of the order by the environment Introductions of new constraints: timing of interactions, quantitative ordering, forced concurrency Selfish components with dynamically changing behaviour: the environment, proactive components Examples of contemporary computing systems, whose behaviour can be more thoroughly analysed if non-classical models of computation are applied Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 14 15 Pulse detonation engine (1) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 16 Thrust Electromagnetic Gate closed Electromagnetic Gate Open Thrust nozzle Air Intake Pressure level RAM simulation Air tank Operating line Test/studies combustion Expansionon Intake p x (t) Pulse detonation engine (2) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 17 Self-reconfiguring robot (1) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 18 Self-reconfiguring robot (2) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 19 Porsche 911 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 20 Fly-by-wire airplane Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 21 Intelligent dust for environment monitoring Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 22 Monitoring environment from the air Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 23 Tiny unmanned aerial vehicles (mosquito) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 24 Unmanned aerial vehicles (predator) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 25 Illustrating a mote of intelligent dust Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 26 Evolution of intelligent dust Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 27 An ant developed by Rodney Brooks Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 28 The first generation car (from pre-computer period) engine moving parts petrol power transmission steering system breaks variety of materials Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 29 The third generation car (with computers) Engine, power transmission, steering system, breaks, etc. are computer controlled Interactions between many aggregates are not built in hardware, but are driven-by-wire The background development-- in addition to modified mechanical design and added processors: 1. Control theory was substantially modified 2. Data-stream processing, forced concurrency, time constraints were introduced into software 2-30 processors Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 30 Typical distributed computer control systems (power station control room) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 31 Co-operation of robots (Furuta) Passing the double inverted pendulum Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 32 Typical remote condition monitoring system Monitored object Central maintenance and management system Condition monitoring device ? Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 33 What are the common features in above examples? All the applications are software-intensive, i.e. their functionality is determined by software Applications comprise interacting components that can also directly interact with their environments Part of the components are passive (slaves), part are active (or proactive) managers Joint behaviour of components cannot be fully predefined nor deduced from the design description (because of incompletely known causal relations, countable number of freely chosen alternatives, autonomy) Requirements and design fixes only general goals, physical, logical, and time constraints. Research Laboratory for Proactive Technologies |||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Evolution of computer applications up to the 21 century 34 Evolution of computer applications Evolution of computer applications: Transformational computing systems Seriously starting from 1939 (Konrad von Zuse, Johan von Neumann) Reactive computing systems (a subclass of embedded systems) Starting from 1950-es, as the first embedded systems Proactive computing systems (as a subclass of embedded systems) Embedded Systems (starting from 1995, a.k.a. Cyber-Physical Systems) is a class of computing systems where computers interact directly with their environment. 35 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Non-classical models of computation Models of Turing computation The universe of computing systems and models of computation 36 Transformational systems Reactive systems Proactive systems Embedded systems = Cyber-Physical systems Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 37 Models of computation (examples) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology From the paper by L.Motus, M.Meriste, W.Dosch (2005) Time-awareness and Proactivity in Models of Interactive Computation, in Electronic Notes in Theoretical Computer Science, vol. 141, (2005), 69-95,Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 38 ARTEMIS JU Embedded Computing Systems Initiative Over 98% of all computing chips are actually hidden or "embedded" in all sorts of things that do not even look like computers. Computers are moving away from the desktop and can be found in everyday devices like credit cards, mobile phones, cars and planes. Innovations made possible by embedded systems make our lives healthier and more interesting, our transport safer, and our energy use more sustainable. Over 4 billion embedded processors were sold inlast year and the global market is worth 60 billion with annual growth rates of 14%. 39 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Transformational computing systems (1) 40 Since 1939: sequential, batch, finite time computing; business data processing, number chrunching, financial transactions, scientific computation, etc Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 41 Transformational computing systems (2) Conventional computation means finding a solution to any problem by transforming a given input value to output values by means of an algorithm, while nobody interferes with the transformation process (ballistic computations) do p: dom p val p dom p val p Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Reactive computing systems (1) Since 1960-es: deterministic time constraints, reactive (interactive with its environment), distributed, concurrent computing 42 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Reactive computing systems (2) A reactive system reacts to external stimuli. The expected behaviour of a reactive system is determined by allowable sequence of input stimuli and output responses. Various preconditions on actions, locations, and timing constraints may be imposed on systems inputs and outputs Hence programs in reactive systems should have internal memory that extends to several consecutive executions of a program Reactive systems form a separate subclass of embedded systems that implement a closed loop control system with feedback through the environment Reactive systems usually cannot modify their functionality and structure on-line 43 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Proactive computing systems (1) Proactive computing systems extend reactive systems with more autonomy and advanced capabilities of the components, e.g.: They can analyse the impact of ambient status on probability of achieving their goals by cognitive perception, and They are armed with permit and capability to modify their functionality, to reorganise systems structure, and/or to modify the interim goals in order satisfy systems main goal. Proactive behaviour is very seldom generated in direct and deterministic response to external stimuli but the stimuli are usually interpreted in combination with the situational information, systems historical memory, and any other available information 44 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Proactive computing systems (2) Typically proactive behaviour becomes important in more complex and more demanding applications such as networked reactive systems that often exhibit emergent behaviour and require on-line, dynamic verification. 45 dom pval p p: T(p) x dom p val p Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 46 A generic real-time (embedded) system Controlled object Humans Computer system Microprocessor, multiprocessor, LAN,WAN, etc Car breaking system, chemical processes, car assembly, NEC applications, mirror- universe applications, etc 47 Difference between transformational and reactive / proactive systems dom pval p p In transformational computing p: dom p val p (string processing) Reactive and proactive computingp: T(p) x dom p val p (stream processing) T(p) enumerable set Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 48 From reactive to proactive system (an example of Jaguar (a car) cruise control, last century) Traditional cruise control: Maintains a fixed vehicle speed, as set by the driver, by controlling the throttle (typical reactive behaviour) Problem in congested traffic when speeds vary widely the system is not effective Autonomous intelligent cruise control (introduction of proactive behaviour) : traditional cruise control a radar sensor in the front of the car control of throttle and breaks (according to radar) See additional details in J. Gray & D. Caldwell (eds), 1996 Research Laboratory for Proactive Technologies |||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Research Laboratory for Proactive Technologies |||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 49 String-processing models of computation (Turing machine paradigm) State machine paradigm (as a presentation of an algorithm) has been canonised in computer science since 1960-s. It has been extremely fruitful for processing data strings Input (i) Output (o) initial statefinal state Isolated from the rest of the world Research Laboratory for Proactive Technologies |||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 50 Stream-processing on models of computation Interaction-centred model of computation: output (o1)output (o2)output (o3)output (o4) initial state input (i0) input (o1,i1) input (o1,o2,i2)input (o2,o3,i3) This paradigm cannot be reduced to Turing machines and conventional algorithm theory. The paradigm emerged in 1930, re-emerged in 1980-s and is gaining popularity due to its suitability for handling contemporary computer applications. Compare sequential interaction machine it with persistent Turing machine (i.e. Turing machine with memory), as described in Turing machines, transition systems, and interaction by D.Goldin, S.Smolka, P.Attie, and E.Sonderegger, in Information and Computation vol. 194, issue 2, 2004, pp Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 51 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 52 Milners comments on evolution of the computer science Object-oriented programming partly breaks the sequential world of von Neumanns architecture 1.In von Neumann architecture concurrent activity and co- existence of active objects (agents) could not be expressed in programs operating system helps a little 2.The metaphor of an agent (active object) brings programming ontology much closer to the real world 3.Agent is becoming from a convenient metaphor to a major concept in computer science Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 53 Milners comments on evolution of the computer science (2) Old computingNew computing Prescription Description Hierarchical design Heterarchical phenomena Determinism Non-determinism End result Continuing interaction . (extension) (intension) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 54 Interaction centred models of computation (examples) have been around for more than 20 years: (and stem from the Turings choice machine (1936)) without time constraints Milner (1976, 1980, 1999), focusing on calculus of communicating systems Wegner (1995), Wegner and Goldin (1999), revision of foundations of computing with time constraints (sophisticated time ) Quirk and Gilbert (1977) Motus and colleagues (1983, 1986, 1994) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 55 Observations and interactions A new role as suggested by R. Milner A Calculus of Communicating systems by R. Milner (1980, LNCS no.92): The only way to observe a system is to interact with it. To make two components to interact means to let them observe each other. In many cases one cannot observe the internal interactions (e.g. transitions between states) in a component. Because of that the future observations on a component may not be predictable (see the example on next slide) H. Simon has called this phenomenon emergent behaviour (The Science of the Artificial) Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 56 Language equivalence of finite state acceptors (1) from Milners book on CCS Acceptor S b c d a Acceptor T S 0 = (acd)*ab T 0 = (acd)*ab S and T are language-equivalent acceptors a c a b d 1 1 2 Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 57 a b c d Observable behaviours of S and T are not equivalent ? Box SBox T a b c d s0s0 a b c d t0t0 Press button a a a b c d s1s1 t 1 T fails with button b b s2s2 b No operation Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 58 Can we be sure that S and T are not observation- equivalent ? No, because T could have responded differently to a button (e.g. moved to state t 1 ). Without additional information about why and how T reacts to button a, we cannot demonstrate that S and T are, or are not equivalent. If the additional information is not available, we should declare S and T to be not equivalent for obvious pragmatic reasons. Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 59 Milner provided methods for the new wave of interactive computing CCS, -calculus and the related studies: R.Milner Communication and mobile systems: the -calculus, Cambridge Univ. Press, 1999 explain why and how state transition and interactions are related in a state machine provide means for studying input/output streams (observations in the case when only incomplete information about the inner states of interacting partners is available) The -calculus is a model of computation for mobile systems that is based on primitive notion of interaction Siin pooleli Research Laboratory for Proactive Technologies ||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology 60 L.Motus, 2004 Timing analysis of embedded systems 61 Empirical Computer Science Wegners research group Why empirical ? Computable functions (in sense of Turing machine) are too weak a model for interactive problem solving, the alternative formalisms will depend upon the factors that are uncontrolled by the designer Turing machines are extended by - sequential interaction machines (SIM) - multi-stream interaction machines SIM notion is formalised by Persistent Turing Machine ( Turing Machines, Transition Systems, and Interaction by D.Goldin, S.Smolka, P.Attie, and P.Wegner) See also a presentation in 1999 Co-inductive Models of Finite Computing Agents by P.Wegner and D.Goldin L.Motus, 2004 Timing analysis of embedded systems 62 Algorithmic computation Turing machine with behaviour: (i, o) Interactive computation Sequential Interaction Machine with behaviour: {(i 1, o 1 ),(i 2, o 2 ),... } plus constraints (if needed) Multi-stream Interaction Machine with behaviour: (i 11,o 11 ),(i 12,o 12 ), plus constraints (if needed) (i k1,o k1 ),(i k2,o k2 ),... Stream-based view of computation (1) Wegners research group {} L.Motus, 2004 Timing analysis of embedded systems 63 Stream-based view of computation (2) Wegners research group Interactive computation is described by histories of observable interactive behaviour (streams) Histories are (can be) formed by externally triggered input-output actions Interaction machines cannot be modelled by Turing machines Expressiveness of different models: algorithmic sequential IM multi-stream IM L.Motus, 2004 Timing analysis of embedded systems 64 Some general observations Wegners research group The hypothesis interactive computing agents are more expressive than algorithms opens up a research area that had been considered closed Sequential Interaction Machines are not expressible by, or reducible to computations of Turing Machines Multi-stream Interaction Machines express a behaviour that is not expressible by SIM-s First order logic cannot model interactive computation UML, for instance is sufficiently expressive to describe interactive computation (Goldin, et al 2001) L.Motus, 2004 Timing analysis of embedded systems 65 Interaction centred models of computation (examples) have been around for more than 20 years: (and stem from the Turings choice machine (1936)) without time constraints Milner (1976, 1980, 1999), focusing on calculus of communicating systems Wegner (1995), Wegner and Goldin (1999), revision of foundations of computing with time constraints (sophisticated time) Quirk and Gilbert (1977) Motus and colleagues (1983, 1986, 1994) L.Motus, 2004 Timing analysis of embedded systems 66 Real world, computer science, and stream processing On-going computation is becoming a norm for computer applications from the point of view of the environment a program is not terminating The on-going computation is not a constructive paradigm In artificial systems a non-terminating program can often be presented as a terminating, repeatedly activated program (the inner view of the non-terminating program) Stream processing can, in many cases, represent such a program Potential danger is that stream elements contain too little information (typically timing constraints are missing) L.Motus, 2004 Timing analysis of embedded systems 67 A generic real-time system Controlled object Humans Computer system Microprocessor, multiprocessor, LAN,WAN, etc Breaking system, chemical processes, car assembly, etc L.Motus, 2004 Timing analysis of embedded systems 68 A gap between computer science and real- time systems Has been reduced by introducing interactive computing principles, e.g. change the paradigm (and, may be emphasis) of modelling real-time software study the actual requirements to and problems of designing and implementing real-time software choose minimal, but sufficient complexity of time model develop a mathematically correct computational model which supports formal analysis L.Motus, 2004 Timing analysis of embedded systems 69 Examples of computational models and paradigms Paradigm (in this context) -- a generic architecture of an ideal computing system, or of some parts of this system; quite often - - a pattern for thinking. Computational model -- a framework for specification, design and implementation of a computer system, reflecting the selected paradigm and based preferably on a formal theory Paradigms -- a non-terminating program; O-O architecture; agent-based program Computational models -- state-transition machine; CCS, multi- stream interaction machine L.Motus, 2004 Timing analysis of embedded systems 70 The paradigm used in LIMITS for real-time systems A real-time system is a collection of interacting dynamic systems, one of which is a computer system. Software for this computer system is a collection of loosely coupled, repeatedly activated, terminating programs Conventionally used paradigm -- software for a real-time system is a single, non-terminating program plus liveness, safety, and fairness properties imposed upon it. L.Motus, 2004 Timing analysis of embedded systems 71 Pragmatics of a new paradigm? to make explicit the implicitly present timing requirements, or constraints ( i.e. to focus on timing); for instance, invisible common knowledge: conventional computational algorithms are applicable in a static environment only (e.g Turing machine concept is valid, in real- time systems, only within given time limits) the static environment assumption holds within the limits determined by quantitative time constraints, given by experts (coherence and contradiction problems) different parts of an environment may have different dynamic characteristics, hence different time constraints L.Motus, 2004 Timing analysis of embedded systems 72 Early attempts of processing timed streams W.Quirk and R.Gilbert The formal specification of the requirements of complex real-time systems, AERE, rep.no.8602 P.Caspi and N.Halbwachs (1982) Proc. International Conference on Parallel Processing, P.Caspi and N.Halbwachs (1986) Acta Informatica, vol.22, Papers on stream processing: W.Dosch Deriving Control and Data States for an Interactive Stack Using History Abstraction W.Dosch Refining Infinite Stream Behaviours by Bound Functions L.Motus, 2004 Timing analysis of embedded systems 73 How to get closer to time-sensitive behaviour of software? Estimate the occurrence pattern (and major characteristics) of events in the external environment estimate the acceptable response time to the driving events and the required processing power estimate potential interference of various driving events and algorithms reacting to them, determine time constraints enabling to manage the interference provide sufficient computing and communication power to satisfy the time constraints, and/or select algorithms that manage with the given computing power. L.Motus, 2004 Timing analysis of embedded systems 74 Available paths for achieving time deterministic behaviour (1) 1.The use of formal mathematical methods is inevitable 2. Three different approaches applied to the software development process, especially if combined in pairs [ (i) & { (ii) or (iii)}] have demonstrated practical usefulness (i) schedulability analysis and program execution scheduling theory (e.g. RMA -rate monotonic analysis) (ii) formal theories focusing on proving particular properties of a program (e.g. dual-language approach) (iii) formal theories focusing on compositional proving in the software development process (e.g. single- language) L.Motus, 2004 Timing analysis of embedded systems 75 Available paths (2) Schedulability analysis, scheduling theory, run-time scheduling: conventionally used starting from the physical design stage is based on combinatorics, empirical beliefs and knowledge regarding the future system (e.g. defining the priority of tasks), on actually measured time characteristics, and on requirements for other resources) is relatively easy to apply, widely used in practice if the acceptable schedule cannot be found, large parts of the practically implemented software must be modified, or the hardware configuration modified. L.Motus, 2004 Timing analysis of embedded systems 76 Available paths (3) Formal theory focusing on particular properties of a program: usually it is a general deductive framework, that considers a particular program (or their complex) as a subject of a special theory (e.g. obtained by adding specific axioms to general theory) expected properties (or their absence) are stated and proven in the special theory as theorems theorem formulation and their proofs assumes good education and practical experience in using formal methods examples -- temporal logic, Hoomans compositional proofs L.Motus, 2004 Timing analysis of embedded systems 77 Available paths (4) Formal theories focusing on (compositional) proof of universal properties for a class of application: common properties for a class of applications and methods for proving their presence become important theorems can be proven for the whole class of applications, the case of particular programs is reduced to checking the assumptions of proven theorems most of the theoretical complexities can be hidden from the end user, interpretation of results and exceptions needs some understanding examples -- Calculus of Communicating Systems, Q-model L.Motus, 2004 Timing analysis of embedded systems 78 Why bother about proactive, time- sensitive computing? George Bernard Shaw The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. W. Edwards Deming Learning is not compulsory. Neither is survival L.Motus, 2004 Timing analysis of embedded systems 79 Why are some computer systems time-critical? (1) 1. A computer system has to influence/monitor/control objectively existing physical processes in the real world. 2. To do that the computer systems behaviour has to be matched to the dynamics of real world processes 3. The underlying theory (e.g. mathematics, control theory, etc) is based on an assumptions of a static environment with certain invariant properties. 4. The actual non-linear phenomena are, in many cases, approximated with several linear models which should be substituted dynamically. L.Motus, 2004 Timing analysis of embedded systems 80 Why are some computer systems time-critical? (2) 5. Switching between linear models should be done automatically 6. Many simultaneously on-going physical processes in the real world should be addressed concurrently, with strict response times defined by the environment and goals of the computer system (forced concurrency) 7. Mapping from the continuous time real world onto the computer with discrete time imposes/assumes certain regularity of refreshing input and output variable values. L.Motus, 2004 Timing analysis of embedded systems 81 Influence of input/output regularity Digital controller ADC DAC Sensor Actuator Plant, G(s). Input L.Motus, 2004 Timing analysis of embedded systems 82 Input/output is at regular intervals L.Motus, 2004 Timing analysis of embedded systems 83 Input/output irregularity is inserted Research Laboratory for Proactive Technologies |||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Basic time-related properties and hypotheses about the nature of time in real-time systems Derived from the analysis of operational real-time systems L.Motus, 2004 Timing analysis of embedded systems 85 Excerpts from earlier statements about time William Shakespeare What seest thou else In the dark backward abysm of time? Ronald Reagan You aint seen nuthin yet G.J.Whitrow about A.Einstein From the moment when he came to question the traditional idea of time, only five days were needed to write his paper.... L.Motus, 2004 Timing analysis of embedded systems 86 Time correctness of inter-process communication implies coherence of time constraints imposed on the communication partners correct order of data production and consumption of the partners (especially in the case of simultaneous copies) valid start instants of interactions satisfaction of constraints imposed upon transport and non- transport delays possibility of time-selective consumption of data L.Motus, 2004 Timing analysis of embedded systems 87 Time-selective communication Basic idea: data received by the consumer process must be of certain, prefixed age is a reflection of data delays assumed by control theory has heretical consequences for conventional programming -- some messages may never be consumed, some messages are consumed many times becomes explicit when a paradigm of one non-terminating program is substituted by a more realistic paradigm (terminating, repeatedly activated programs) L.Motus, 2004 Timing analysis of embedded systems 88 The assumption of static environment related to algorithms The assumption is that the theory and preconditions on which an algorithm is based will not change during the execution of the algorithm -- i.e. the axioms, the inference rules, the object for which this algorithm produces results It is believed that any algorithm can be implemented on a Turing machine. If the assumption of static environment does not hold, the operations or interim data necessary for correct termination of the algorithm may be corrupted on the tape L.Motus, 2004 Timing analysis of embedded systems 89 Some examples of time as used in computational models 1. Linear, topologic time -- conventional data processing systems 2. Linear, metric, discrete, strictly increasing time (Real-time temporal logic by Ostroff, many other temporal logics, process algebras and timed Petri nets) 3. Branching, topologic or metric, discrete (some temporal logics) 4. A set of linear, discrete, increasing, metric times; plus a set of reversible, discrete, metric times, and many relative times (virtual time and time warp system) etc L.Motus, 2004 Timing analysis of embedded systems 90 Minimum complexity of time required in real-time system Three philosophical concepts of time should simultaneously be present: - fully reversible time (like in physics) - strictly increasing time (like in thermodynamics) - relative time (like in psychology) At least one strictly increasing time must be metric Most of the existing computational models use oversimplified time which explains their only partial success in real-time systems L.Motus, 2004 Timing analysis of embedded systems 91 Concepts of time -- examples 1. Fully reversible time - virtual time and time warp mechanism based simulation systems (a multitude of events with local timestamps, synchronised in global time with the possibility of undoing things if necessary (Jefferson(1983)) 2. Strictly increasing time - all basic activities of real-time systems are not reversible (processes in nature cannot be reversed) 3. Relative time with moving origin - for describing inter-process/inter-cycle communication L.Motus, 2004 Timing analysis of embedded systems 92 An example of time in the Q-model each process functions in increasing (thermodynamic) time, which advances in grains inside each grain the time is fully reversible inside each grain a process has a relative time (in addition to a fully reversible time) for each pair of communicating processes there is a separate relative time (in addition to all other times) L.Motus, 2004 Timing analysis of embedded systems 93 Time models used by OMG (1) 1. OMG document formal/02/05/07 Enhanced View of Time, version OMG document formal/02/05/06 CORBA services: Time Service Specification, version OMG document ptc/02/03/02 UML TM Profile for Schedulability, Performance, and Time, specification, version 1.0 Accessible from L.Motus, 2004 Timing analysis of embedded systems 94 Time models used by OMG (2) These models provide a framework for modelling time constraints imposed upon UML model components, and can be used by UML model processors, or other independent tools Models of physical time include, but not limited to: universal time, mission time, discrete and continuous time, global and localised, relative and absolute time combined with synchronisation references, intervals, durations. L.Motus, 2004 Timing analysis of embedded systems 95 Time models used by OMG (3) Timing specifications are constraints placed on model elements. The following timing specifications are to be modelled, at minimum: deadlines, periods, frequencies, jitter and their stochastic properties, intervals, durations, and latencies response times, response delay times,and execution times step-to-step and end-to-end time budgets, estimates and actuals along with their statistical properties Inter-arrival times, time budgets, estimates and actuals along with their statistical properties. L.Motus, 2004 Timing analysis of embedded systems 96 Time models used by OMG (4) Timing Facilities and Services refer to mechanisms that enable to apply and to assert time concepts. The following means to model timing facilities and services are included: time resolution, jitter and its stochastic properties, synchronisation offset and residual explicit timer objects, clocks, watchdog timers OS timing services clock synchronisation policies such as probabilistic and stochastic. L.Motus, 2004 Timing analysis of embedded systems 97 Topics discussed further in this course How to make timing requirements to software explicit? What are the actual timing requirements to real-time systems? Time-aware interaction-centred model of computation for real- time systems Model-based timing analysis of real-time systems The coming topics have been selected from the book Timing analysis of real-time software by Motus and Rodd. L.Motus, 2004 Timing analysis of embedded systems 98 Alternative models used for real-time systems (1) a) Focusing on processing the infinite behaviours State-transition machines: - finite automata, state-charts, attribute automata - Petri nets (timed, coloured, high level, extended) generate the infinite sequences of events (behaviours) some properties of those sequences are then studied. Process algebras and temporal logics: analyse more elaborate properties of those infinite sequences. L.Motus, 2004 Timing analysis of embedded systems 99 Alternative models used for real-time systems (2) b) Focusing on individual processing elements and their interactions Communicating abstract processes: Each process is a mapping and mappings are interacting according to explicitly defined rules Abstract data types and object-oriented approach: Central are data types, not mappings of data, each data type has a permissible set of operations (mappings) attached to it. L.Motus, 2004 Timing analysis of embedded systems 100 Abstract data type just for your information Schach (1996) p. 170 an object is an instantiation (instance) of an abstract data type, plus the concept of inheritance Sommerville (1992) p.136 Abstract data type technique is algebraic specification where an object class, or data type, is specified in terms of the relationships between operations defined on that type: sort informal description of the sort and its operations operation signatures (names and types of parameters) axioms defining the operations over the sort L.Motus, 2004 Timing analysis of embedded systems 101 An example of time-aware interaction centred model of computation The Q-model L.Motus, 2004 Timing analysis of embedded systems 102 The Q-model preview (1) The Q-model follows the paradigm of communicating abstract processes The Q-model is based on the innovative ideas of W.J.Quirk and R.Gilbert for extending the definition of a process. Usually a process is defined as p: dom p val p dom - domain of definition, val - value range. This definition is sufficient for data processing systems with completely known causal relations L.Motus, 2004 Timing analysis of embedded systems 103 The Q-model preview (2) In real-time systems processes are often started independently of each other by events from outside of the computer system, or by time constraints which approximate the incompletely known causal relations. The processes will be started repeatedly, either periodically or aperiodically. Correctness of a process execution depends on the age of input data. Consequently it is important to know, at least, the age of input and output data, process activation and execution times, and interaction start times for interacting processes. L.Motus, 2004 Timing analysis of embedded systems 104 The Q-model (1) L.Motus, 2004 Timing analysis of embedded systems 105 The Q-model (2) Enables to incorporate timing constraints starting from the specification and ending with the maintenance (throughout the whole life-cycle) Combines analytical (formal) and simulation (informal) approaches for verifying time correctness Supports co-operation between software, control and systems engineers Encourages the insertion of safety, reliability, fault- tolerance features into the specification and supports the analysis of their influence on the system L.Motus, 2004 Timing analysis of embedded systems 106 Q-model and data flow models A data flow model is a semi-formal (structured) example of abstract communicating processes approach -- no assumptions are made about mappings, the semantics of data flows are usually not strictly defined. The Q-model adds activation time instants (and other constraints) to mappings, and explicitly synchronises the execution of mappings. As a consequence, the data in a system becomes time-labelled, semantics of data flows can be strictly defined, use of time- selective interaction becomes possible. As a by-product, it becomes possible to analyse the time- correctness of the system. L.Motus, 2004 Timing analysis of embedded systems 107 Q-model and object-oriented approach Object-oriented approach is a semi-formal (structured) implementation of abstract data type paradigm Q-model enables to time-label all the data, and provide operations with time constraints (requirements or actual invocation times, execution times, data consumption times) and formally verify the coherence of those constraints. Q-model can be related to an object model. Q-model captures the information from dynamic and functional models of OMT, and many views of the UML model. L.Motus, 2004 Timing analysis of embedded systems 108 Q-model and HRT-HOOD HRT- HOOD is a time-constraint object-oriented design tool for hard real-time ADA systems. Temporal parameters and non- functional requirements are specified at physical architecture design stage Q-model includes temporal parameters and non-functional requirements in earlier stages of life cycles. HRT-HOOD - period of execution (cyclic), min arrival interval (for sporadic objects), offset time for related objects, deadlines Q-model - period of execution (sporadic,cyclic), execution time, data consumption time, equivalence and simultaneity intervals for processes and clusters. L.Motus, 2004 Timing analysis of embedded systems 109 Concluding remarks on comparing models of computation (1) 1.Majority of widely used formal and semi-formal (structured) methods neglect timing issues. For instance, data-flow (e.g. Yourdan + extensions) and object-oriented (e.g OMT, unified method (UML)), and Z methods. 2.Other methods do analyse timing properties -- timed Petri nets, temporal logics, many process algebras but rely on trivial time models and are therefore are not able to analyse all the required timing properties. 3.HRT-HOOD relies on a trivial time model L.Motus, 2004 Timing analysis of embedded systems 110 Concluding remarks on comparing models of computation (2) The Q-model and LIMITS tool are based on sophisticated time models (similar to those later were suggested by OMG) and are capable of performing timing analysis of interactions. LIMITS can, in principle, analyse class models that are transformed to Q-model and return the necessary corrections to the class model. In general, any model that is based on trivial time model can easily be transformed to the Q-model. Difficulty is that the transformation to and from the Q-model is not unique (because of the different information content in models see MSc thesis by O.de Voogd). L.Motus, 2004 Timing analysis of embedded systems 111 References for some of the mentioned models 1.Data-flow approach to real-time systems - P.Ward and S.Mellor Structured Development for Real-time Systems, vol.1, Prentice-Hall, 1985, 156 pp. 2.HRT- HOOD : A Structured Design Method for Hard Real- time Ada Systems, A.Burns, A.Wellings, Elsevier, 1995, 313 pp 3. OMT -- Object-Oriented Modeling and Design, J.Rumbaugh, M.Blaha, W.Premerlani, F.Eddy, W.Lorensen, 1991, Prentice-Hall, 500 pp. 4.Transformations between data flow diagrams and Q- models, MSc thesis by O.de Voogd ( in room II-309) L.Motus, 2004 Timing analysis of embedded systems 112 The Q-model (1) L.Motus, 2004 Timing analysis of embedded systems113 The Q-model (2) dom p val p p p: dom p val pdescribes processing of a string p: T(p) x dom p val p describes processing of a stream L.Motus, 2004 Timing analysis of embedded systems114 The Q-model (2) ij : T(p i ) x T(p j ) x val p i proj val pi dom p j dom p j val p i ij val p k kjkj L.Motus, 2004 Timing analysis of embedded systems 115 The Q-model processes (1) dom p i -- domain of definition is formed by other mappings of the system, i.e from elements of val p k, k=1, , n ; No other data is available in the Q-model All the elements (and their components) of dom p and val p are time labelled, and may be given explicit validity periods; as soon as the validity period has expired, the data element is defined as unreliable and the mapping should not be execute with this data element. The process p must be executed (i.e. it has to identify an element in val p) each time the time-set T(p) activates it. Resource sharing problems are neglected in the Q-model -- each activation of a process has its own processor L.Motus, 2004 Timing analysis of embedded systems 116 The Q-model processes (2) Properties of process time-set T(p): 1. Elements of T(p) must be well-ordered, no partial order is allowed 2. Since each well-ordered set has a minimal element, it is recommended that processes of a given system consider 0 as a common minimal element. 3. The non-Zeno property is assumed -- in any finite time interval a process may be activated only finite number of times Zeno from Elea ( BC) Eesti keeles Zenon Eleasest L.Motus, 2004 Timing analysis of embedded systems 117 The Q-model processes (3) How to specify/define a time-set T(p) : 1. Explicitly list all its elements 2. Refer to a triggering event in the environment or in the computer system 3. Refer to a time-set that is already defined for another process All the processes, in principle, are activated repeatedly. This allows cyclic and sporadic activation of a process, and in some cases, a prefixed number of activations. L.Motus, 2004 Timing analysis of embedded systems 118 Cyclic and sporadic activation of processes (1) time t0t0 t1t1 t2t2 t3t3 t max t min trtr trtr t r fluctuation interval L.Motus, 2004 Timing analysis of embedded systems 119 Cyclic and sporadic activation of processes (2) 1. A unified handling of strictly cyclic and sporadic activation of processes is recommendable 2. The average inter-activation interval coincides with the precise period of strictly cyclic processes 3. In the case of sporadic activation, the additional fluctuation is permitted (quantitatively defined as ignorance interval (or fluctuation interval) around the average activation instant). 4. For long term forecasts this simplification works well, problems can emerge with short term forecasts. L.Motus, 2004 Timing analysis of embedded systems 120 The Q-model processes (4) Unbounded number of repeated executions of a process is possible only if processes execution time has a finite upper bound (or the processor has infinite computing power). All the temporal parameters in the Q-model are given by interval (worst-case) estimates. For instance, execution time of a process p is p,t) [ p p)] (p) and (p) are functions determined by empirical and/or theoretical knowledge of the nature of process p. Interval estimates reflect our ignorance regarding the exact values, and understanding of the indeterminacy of the reality. L.Motus, 2004 Timing analysis of embedded systems 121 The Q-model processes (5) State of a process A state transition paradigm assumes that a process is described as a series of state transitions (from initial state to terminal state). The same is true when describing dynamic systems in control theory. The Q-model assumes that the details of inner behaviour of a process are not observable (or rather, not of interest). Therefore visible values of a process state variables may change only after the process has terminated. This reduces the complexity (number of states) and allows to describe and analyse a system without fixing algorithms L.Motus, 2004 Timing analysis of embedded systems 122 State of a Q-model process time State value Execution of process A (A, t 0 ) t0t0 t1t1 t2t2 s(A,t 0 ) s(A,t 1 ) s(A,t 2 ) L.Motus, 2004 Timing analysis of embedded systems 123 The Q-model processes (6) Process types in the Q-model: - Common process maps all the elements of its domain always into one and the same value range (unconditional mapping) - Selector process is a mapping whose execution depends on predefined input and output decision mechanisms; it can select only some of the variables from an element of its domain, it may have more than one value range. Although no assumptions about algorithms are required, it is useful to know/assume/estimate some details of I/O decision mechanisms at the specification of a selector process. L.Motus, 2004 Timing analysis of embedded systems 124 Samples of Q-model processes Common processes: reading a measurement from the sensor combining measurements from several sensors (sensor fusion) executing an order (e.g. close a valve) Selector processes: validating the sensor reading (valid/invalid) granting an eating place to a philosopher (five philosophers problem related to resource sharing) executing an order and checking its feasibility L.Motus, 2004 Timing analysis of embedded systems 125 Val p of Q-model processes. Common process p2p2 p3p3 p1p1 dom p 1 = val p 2 x val p 3 L.Motus, 2004 Timing analysis of embedded systems 126 Val p of Q-model processes. Selector process Output selector p1p1 Out 1 Out 3 Sample of val p 1 structure Out 2 Out 1 Out 2 Out 3 val p 1 L.Motus, 2004 Timing analysis of embedded systems 127 Process interaction in the Q-model Channel implements producer - consumer type of interaction. Channel transmits data and synchronisation signals.The producer produces its state values, the channel stores the produced state values and forms message as required by the consumer. The Q-model channel implements point-to-point, one-way communication between two processes. Formally a channel is a mapping from producers value range to consumers domain: ij : val p i x T(p i ) x T(p j ) proj val pi dom p j L.Motus, 2004 Timing analysis of embedded systems 128 The producer-consumer paradigm based interaction The producer-consumer interaction = message exchange without waiting for completion or an acknowledgement. A channel receives a message from the producer, transforms it into the message as required by the consumer (a time- sequence of producers state values) The reliability of message exchange without waiting for receipt is feasible, if: publicly accessible global (universal) time is maintained messages are equipped with their validity time L.Motus, 2004 Timing analysis of embedded systems 129 Reliability of message exchange without waiting for receipt References 1.MacLeod I.M. and Rodd M.G. (1982) Inter-process communication primitives for distributed process control, Proc. 3rd IFAC/IFIP Symposium on Software for Computer Control, Pergamon Press 2. Kopetz H. and Kim K.H. (1990) Temporal uncertainties in interaction among real-time objects. Institut fr Technische Informatik, technische Universitt Wien, Austria, Research report no. 10/90 L.Motus, 2004 Timing analysis of embedded systems 130 The Q-model channels (1) Time selectivity of a channel is realised by the consumer defined channel function: K( ij,t) T p i ),t T(p j ). A more practical presentation of the channel function is in backward relative time K( ij,t) = [ ], where is the latest and is the earliest state value accessible via the channel ij. To enable time-selective communication, all the state values must be time-labelled and each channel must have its own relative backward time. L.Motus, 2004 Timing analysis of embedded systems 131 Relative time as used in a channel function (Q-model) processes time K( ij,t) = [1,0] sync semisync async L.Motus, 2004 Timing analysis of embedded systems 132 The Q-model channels (2) Types of channels Different types of channels are needed to connect processes with different time-sets and different communication requirements; in practice five types of channels are used: 1. Synchronous channel, if T(p i ) = T(p j ) 2. Semi-synchronous channel, if T(p i ) T(p j ) 3. Asynchronous channel, if T(p i ) and T(p j ) are independent 4. Synchronous null channel, to activate two processes at the same time 5. Semi-synchronous null channel, for sequential activation of two processes L.Motus, 2004 Timing analysis of embedded systems 133 The Q-model channels (3) Incoming channels are connected to input ports: - if two or more channels carry the same message (variable-wise), they can be connected to one and the same input port, they are OR-ed - if two or more channels carry different messages (variable-wise), they should be connected to different input ports. Selector process has numbered output ports for different messages (states), common process has always only one output port. More structural restrictions can be introduced during analysis. L.Motus, 2004 Timing analysis of embedded systems 134 Time parameters related to channels For each channel a data consumption interval (a delay with respect to process activation instant) is defined/specified: ( ij, t) ij ), ( ij )], ij ) is less or equal ij ) Each consumer may define/specify for each incoming channel a channel function, which determines the age of producer states comprising the message accessible from this channel. With each channel is related a set of transport and processing delays; depending on the channel type these delays determine the synchronisation precision, and/or time required for data transmission through the channel. L.Motus, 2004 Timing analysis of embedded systems 135 Functioning of a Q-model channel producer consumer send Receive (optional) send Circular buffer (of the channel) pipi pjpj ij pipi pjpj L.Motus, 2004 Timing analysis of embedded systems 136 Operations and activities in the channel (an example) 1. Length of the circular buffer is determined by the channel function and contains ( +1) elements (one element = one set of producers state variables) 2. send ( or write) command will shift the content of the buffer by one element, if the buffer is full, the oldest element is overwritten 3. Receive(or read) will not change the buffer 4. Each time ( - + 1) elements are read. 5. At the cold start the buffers are filled. 6. Control of the sequence of write and read operations depends on the channel type. L.Motus, 2004 Timing analysis of embedded systems 137 Possible delays in a channel A channel is implemented as a separate process -- let us study a chain of processes producer - channel - consumer. A channel receives a new state value from the producer, stores it in a circular buffer, receives a request for data from the consumer, forms a message according to the channel function, sends the formed message to the consumer. Delays are related to detection of the consumer request, forming the message, send of the message; and in many cases synchronisation with the producer. Transport delay, processing delay, non-transport delay L.Motus, 2004 Timing analysis of embedded systems 138 Functioning of the null channel The null channel actually implements a limited broadcast (multicast) -- one to many communication -- typically activation of a group of synchronous processes. Two different delays exist: null channel delay -- time required to detect the synchronising event and to warn the processors that run the synchronised processes time required to activate a process on a particular processor Null channel delaysimultaneity L.Motus, 2004 Timing analysis of embedded systems 139 Application of null channel (synchronous clusters) n s s ss s a s Synch. cluster 1 Synch. Cluster 2 L.Motus, 2004 Timing analysis of embedded systems 140 Application of semi-synchronous null channel ss s a Semi-synchronous cluster p1p1 p2p2 p3p3 p4p4 p5p5 L.Motus, 2004 Timing analysis of embedded systems 141 Semi-synchronous cluster p1p1 p2p2 p3p3 p4p4 p5p5 Simultaneity interval Research Laboratory for Proactive Technologies |||||||||||||||||||||||||||||| ||||||||||||||||||||||||||||||||||||||||| Dept. of Computer Control, Tallinn University of Technology Examples of systems described in the Q-model L.Motus, 2004 Timing analysis of embedded systems143 Representation of ports and process types (iv) I/O Selector Process (iii) Output Selector Process (ii) Input Selector Process (i) Port on Common Process 1 P 1 P 1 P P 1 2 0 L.Motus, 2004 Timing analysis of embedded systems144 Part of a system with a selector process p 4 1 p 0 p p2p2 p3p3 L.Motus, 2004 Timing analysis of embedded systems145 Example of behaviour of a common process ( 21,t k ) assignment of new state value p 1 t k (p 1,t k ) input of data preparation computations ( 1,t k ) s(p 1,t k ) L.Motus, 2004 Timing analysis of embedded systems 146 Practical synchronisation in the Q-model The only means of synchronisation in the Q-model is exchange of messages via channels. Synchronous and simultaneous activation of processes: through multicast communication via synchronous or synchronous null channels; equivalence and simultaneity intervals; minimum granularity of system time; synchronous clusters; Semi-synchronous activation of processes: communication via semi-synchronous or semi-synchronous null channels; equivalence and simultaneity interval. L.Motus, 2004 Timing analysis of embedded systems 147 Summary of the Q-model temporal and other attributes (1) Common process: - process time-set T(p), if necessary - interval estimate for process execution time (p i,t) - list of input ports and channels connected to them - interval estimate for data consumption time ( ij,t) - list of input variables for each channel/port - list of output variables for a process - equivalence interval, if necessary L.Motus, 2004 Timing analysis of embedded systems 148 Summary of the Q-model temporal and other attributes (2) Selector process: - input decision mechanism and equivalence interval - list of alternative states plus list of variables for each state - output decision mechanism, or output port selection probabilities - interval estimates of execution time for each state - interval estimates for data consumption time for each input channel - list of input ports and channels connected to them - list of input variables for each channel L.Motus, 2004 Timing analysis of embedded systems 149 Summary of the Q-model temporal and other attributes (3) For a channel: - producer process, if necessary the output port number - consumer process, input port number - channel type - channel function - simultaneity interval for synchronous and semi-synchronous channels and for both types of null channels For a synchronous and semi-synchronous clusters: - equivalence and simultaneity intervals (if required) L.Motus, 2004 Timing analysis of embedded systems150 Example:a cascade controller physical actuator sensor B act B1&B2 CONTROLLED OBJECT A L.Motus, 2004 Timing analysis of embedded systems151 The Q-model of a cascade controller B1E K1 A K2 K3 act B K5 K4 B2 E - inputs from the object A - control algorithm B 1 - allowable changes to the actuator B act - simulates the actuator B 2 - measures the current position of the actuator K i - channels, types will be specified later L.Motus, 2004 Timing analysis of embedded systems152 Q-model processes for the cascade controller ProcessEx. timeIn Chan. Out Chan. Timeset EN/AnoneK1T(E) A4K1K2N/A B12K2, K5K3T(B1) B2 1 K4K5N/A B ACT 3K3K4N/A L.Motus, 2004 Timing analysis of embedded systems153 3 design versions CHANNEL NAME VERS.TYP E ONE FUNCT.VERS. TYPE TWO FUNCT. THREE FUNCT K1 ss [0,0] s [1,1] s [0,0] K2 ss [0,0] s [1,1] s [0,0] K3 ss [0,0] s [1,1] s [0,0] K4 ss [0,0] s [1,1] s [0,0] K5 a [0,0] s [1,1] s [0,0] L.Motus, 2004 Timing analysis of embedded systems154 Time diagram for Version 1 B1 A ACT B process B2 time L.Motus, 2004 Timing analysis of embedded systems155 Time diagram for Version 2 e B1 A ACT B process B2 time L.Motus, 2004 Timing analysis of embedded systems156 Alternate design versions Channel name Version 4 Version 5 Version 6 K1 s ss s K2 a a a K3 ss ss ss K4 ss a ss K5 a s s L.Motus, 2004 Timing analysis of embedded systems157 Cascade Controller as a Petri-net MEASUREMENTS A1A B3 B ACT CB1B2.. L.Motus, 2004 Timing analysis of embedded systems158 Petri-net firing diagram A1 A C ACT B1 B3 B2 B TIME L.Motus, 2004 Timing analysis of embedded systems 159 Comparison of the Q-model and Petri Net descriptions of a controller Advantages of Petri Nets: - graphical representation of dynamic synchronisation of control (or data) flow - in timed Petri Net a natural rate can be estimated (the fastest possible execution of the net) Advantages of the Q-model: - analytical proof of detailed timing properties (including the fastest and slowest execution) - unified description of control and data flow - autonomy of each element and ease of analysing many alternative designs on the same model L.Motus, 2004 Timing analysis of embedded systems 160 Verification of a system described in the Q-model Testing is of little use in verifying timing correctness of software -- analogy with an attempt to identify the properties of a random process by separately studying realisation samples of the process. Verification is carried out in three logical steps: - analysis of separate elements, channels and processes - analysis of interaction between pairs of processes - analysis of the group behaviour of processes. Iterations between the steps are possible. L.Motus, 2004 Timing analysis of embedded systems 161 Separate elements of a specification (1) 1. Process execution time 0 < (p) (p) < < Data consumption delay 0 < ( ij ) ij p j 3. A channel function, as given in a relative backward time: K( ij,t) = [ 0 4. A process timeset may be defined for each process, check that each process has an individual timeset or a pointer to an existing timeset. L.Motus, 2004 Timing analysis of embedded systems 162 Separate elements of a specification (2) Process timeset: 1. All the processes may be executed repeatedly. For each process an execution period may be given, some processes have regular periods, some have random periods (these are called aperiodic processes). 2. Usually a timeset is defined by fixing: - an average period for process activation t a (p) - an estimate of allowable fluctuation (with respect to t a (p)) in process start time t r (p), that reflects our ignorance, or tolerance, about the exact activation instant L.Motus, 2004 Timing analysis of embedded systems 163 Separate elements of a specification (3) Process timeset (continued): 3. The two parameters determine - minimum time between two consequtive activations t min (p) = t a (p) - t r (p) - maximum time between two consequtive activations t max (p) = t a (p) + t r (p) The given values of t a (p) and t r (p), or respectively t min (p) and t max (p) cannot be checked formally, the only check is that 0 < t min (p) t max (p) < L.Motus, 2004 Timing analysis of embedded systems 164 Separate elements of a specification (4) Correct ordering of process copies: 1. The number of copies n = [ (p)/t min (p)] + 1, and [.] denotes the integer part 2. A process copy activated at t 1 terminates before a copy activated at t 2, t 1 and t 2 are two consequtive elements of process timeset, t 1