Synchronous programming

Transcription

1 Synchronous programming Critical Real Time Embedded Software David Lesens Wednesday, 06 October 200 Synchronous programming Eugene Asarin Mehdi Dogguy David Lesens 06/0/200 p2 Master 2 Critical System Synchronous programming David LESENS

2 Overview Critical real-time embedded software Principles of the approach Introduction Formal semantics SCADE Model validation 06/0/200 p3 Master 2 Critical System Synchronous programming David LESENS 06/0/200 p4 Master 2 Critical System Synchronous programming David LESENS 2

3 Where can we find software? Windows, Linux PowerPoint Latex Compilers Mathematical software (e.g. computation of π) Mobile phone Space Nuclear plant Airplane Software is is everywhere Are all all these pieces of of software the same? 06/0/200 p5 Master 2 Critical System Synchronous programming David LESENS There is software and software Our topic is Critical Real Time Embedded Software 06/0/200 p6 Master 2 Critical System Synchronous programming David LESENS 3

4 What is embedded software? Windows, Linux PowerPoint Latex Compilers The software has its own objective We can buy the software Mathematical software (e.g. computation of π) Mobile phone Space launcher Nuclear plant Airplane The software is part of the system We can only buy the system 06/0/200 p7 Master 2 Critical System Synchronous programming David LESENS Compute the first 0,000 digits of Pi pi= /0/200 p8 Master 2 Critical System Synchronous programming David LESENS 4

5 Real time? Transformational systems Inputs available on execution start Outputs delivered on execution end Interactive systems React to their environment To their own speed Reactive systems React to their environment To a speed imposed by the environment e.g. Mathematical computation e.g. Windows, Powerpoint e.g. Control / Command of a spacecraft 06/0/200 p9 Master 2 Critical System Synchronous programming David LESENS Critical? What does it mean? 06/0/200 p0 Master 2 Critical System Synchronous programming David LESENS 5

6 06/0/200 p Master 2 Critical System Synchronous programming David LESENS Critical? What does it mean? Intuitively, a critical system is a system which failure can have severe impacts Nuclear Aeronautic Automotive Railway Space 06/0/200 p2 Master 2 Critical System Synchronous programming David LESENS 6

7 Software criticality levels Standards define precisely software criticality levels: For instance: DO78B and DO78C for airborne systems ECSS for space systems European Committee for Space Standardization 06/0/200 p3 Master 2 Critical System Synchronous programming David LESENS Software criticality categories ECSS-Q-80C Software criticality category A B C D Definition Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Catastrophic consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Critical consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Major consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Minor or Negligible consequences 06/0/200 p4 Master 2 Critical System Synchronous programming David LESENS 7

8 Software criticality categories ECSS-Q-80C Software criticality category A B C D Definition Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Catastrophic consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Critical consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Major consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Minor or Negligible consequences 06/0/200 p5 Master 2 Critical System Synchronous programming David LESENS Software criticality categories ECSS-Q-80C Software criticality category A B C D Definition Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Catastrophic consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Critical consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Major consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Minor or Negligible consequences 06/0/200 p6 Master 2 Critical System Synchronous programming David LESENS 8

9 Software criticality categories ECSS-Q-80C Software criticality category A B C D Definition Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Catastrophic consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Critical consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Major consequences Software that if not executed, or if not correctly executed, or whose anomalous behaviour could cause or contribute to a system failure resulting in: Minor or Negligible consequences 06/0/200 p7 Master 2 Critical System Synchronous programming David LESENS Severity Catastrophic hazards Critical hazards Marginal hazards Negligible hazards Consequence ECSS-Q-40B i) loss of life, life-threatening or permanently disabling injury or occupational illness, loss of an element of an interfacing manned flight system; ii) loss of launch site facilities or loss of system; iii) severe detrimental environmental effects. i) temporarily disabling but not life-threatening injury, or temporary occupational illness; ii) major damage to flight systems or loss or major damage to ground facilities; iii) major damage to public or private property; or iv) major detrimental environmental effects minor injury, minor disability, minor occupational illness, or minor system or environmental damage less than minor injury, disability, occupational illness, or less than minor system or environmental damage 06/0/200 p8 Master 2 Critical System Synchronous programming David LESENS 9

10 Severity Catastrophic hazards Critical hazards Marginal hazards Negligible hazards Consequence ECSS-Q-40B i) loss of life, life-threatening or permanently disabling injury or occupational illness, loss of an element of an interfacing manned flight system; ii) loss of launch site facilities or loss of system; iii) severe detrimental environmental effects. i) temporarily disabling but not life-threatening injury, or temporary occupational illness; ii) major damage to flight systems or loss or major damage to ground facilities; iii) major damage to public or private property; or iv) major detrimental environmental effects minor injury, minor disability, minor occupational illness, or minor system or environmental damage less than minor injury, disability, occupational illness, or less than minor system or environmental damage 06/0/200 p9 Master 2 Critical System Synchronous programming David LESENS Severity Catastrophic Hazardous / Severe-Major Major Minor No Effect DO78B differs lightly from the ECSS Consequence Failure conditions which would prevent continued safe flight and landing Failure conditions which would reduce the capability of the aircraft or the ability of the crew to cope with adverse operating conditions to the extent that there would be: () a large reduction in safety margins or functional capabilities, (2) physical distress or higher workload such that the flight crew could not be relied on to perform their tasks accurately or completely, or (3) adverse effects on occupants including serious or potentially fatal injuries to a small number of those occupants Failure conditions which would reduce the capability of the aircraft or the ability of the crew to cope with adverse operating conditions to the extent that there would be, for example, a significant reduction in safety margins or functional capabilities, a significant increase in crew workload or in conditions impairing crew efficiency, or discomfort to occupants, possibly including injuries Failure conditions which would not significantly reduce aircraft safety, and which would involve crew actions that are well within their capabilities. Minor failure conditions may include, for example, a slight reduction in safety margins or functional capabilities, a slight Failure conditions which do not affect the operational capability of the aircraft or increase crew workload 06/0/200 p20 Master 2 Critical System Synchronous programming David LESENS 0

11 Wikipedia Vocabulary Security is the degree of protection against danger, loss, and criminals. Reliability is the ability of a person or system to perform and maintain its functions in routine circumstances, as well as hostile or unexpected circumstances. Safety is the state of being "safe" (from French sauf), the condition of being protected against [ ] consequences of failure, damage, error, accidents, harm or any other event which could be considered non-desirable. It can include protection of people or of possessions. 06/0/200 p2 Master 2 Critical System Synchronous programming David LESENS Wikipedia Safety & Security in Software Engineering The key difference between security and reliability is that security must take into account the actions of people attempting to cause destruction. Safety The software must not harm the world Security The world must not harm the software 06/0/200 p22 Master 2 Critical System Synchronous programming David LESENS

12 Example : The First Computer Bug 06/0/200 p23 Master 2 Critical System Synchronous programming David LESENS Example 2: The Patriot Missile Failure On February 25, 99, during the Gulf War, an American Patriot Missile battery in Dharan, Saudi Arabia, failed to track and intercept an incoming Iraqi Scud missile. The Scud struck an American Army barracks, killing 28 soldiers and injuring around 00 other people. A report of the General Accounting office, GAO/IMTEC-92-26, entitled Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia reported on the cause of the failure. It turns out that the cause was an inaccurate calculation of the time since boot due to computer arithmetic errors. 06/0/200 p24 Master 2 Critical System Synchronous programming David LESENS 2

13 Failure in space Trident Sea launch 06/0/200 p25 Master 2 Critical System Synchronous programming David LESENS Overview Critical real-time embedded software Principles of the approach Introduction Formal semantics SCADE Model validation 06/0/200 p26 Master 2 Critical System Synchronous programming David LESENS 3

14 NASA's Climate Orbiter was lost September 23, 999, due to a software bug One engineering team used metric units while another used English units 06/0/200 p27 Master 2 Critical System Synchronous programming David LESENS Why is System (to Software) Engineering complicated? Thermal control Mission management Flight control Communication Solar wings Spacecraft design Software development Power management Propulsion 06/0/200 p28 Master 2 Critical System Synchronous programming David LESENS 4

15 The V development cycle System requirements System qualification System design Subsystem requirements Validation tests System integration Subsystem validation Software development Subsystem design Subsystem development Integration tests Unitary tests Subsystem integration testing Unitary testing 06/0/200 p29 Master 2 Critical System Synchronous programming David LESENS Costs of critical software development Specification 0% Design 0% Development/TU 25% Integration tests 5% Validation 50% 06/0/200 p30 Master 2 Critical System Synchronous programming David LESENS 5

16 Late detection of errors System requirements System qualification System design Subsystem Error requirements System integration Error detection Subsystem validation Subsystem design Subsystem development Subsystem integration testing Unitary testing Delay for the error detection 06/0/200 p3 Master 2 Critical System Synchronous programming David LESENS Cost of error correction Cost of error correction Put more effort on early phases Phase of error discovery 06/0/200 p32 Master 2 Critical System Synchronous programming David LESENS 6

17 Verification with model driven engineering System requirements System qualification System design System integration Early detection of errors Automatic code generation Software requirements Software design Software development Software integration testing Unitary testing Software validation 06/0/200 p33 Master 2 Critical System Synchronous programming David LESENS Formal Model Driven Engineering shall allow An early verification of the specification via a strong and intuitive semantic ensuring Consistency Completeness Non ambiguity A behavioural validation within a simulation environment Automatic generation of certified code Formal proof 06/0/200 p34 Master 2 Critical System Synchronous programming David LESENS 7

18 Overview Critical real-time embedded software Principles of the approach Introduction Formal semantics SCADE Model validation 06/0/200 p35 Master 2 Critical System Synchronous programming David LESENS There are two ways of of constructing a software design. One way is is to to make it it so simple that there are obviously no deficiencies. And the other way is is to to make it it so complicated that there are no obvious deficiencies. Professor C. C. A. A. R. R. Hoare The 980 Turing award lecture 06/0/200 p36 Master 2 Critical System Synchronous programming David LESENS 8

19 Wikipedia Formal semantics of programming languages In In theoretical computer science, formal semantics is is the field concerned with the rigorous mathematical study of of the meaning of of programming languages and models of of computation 06/0/200 p37 Master 2 Critical System Synchronous programming David LESENS Syntax Is it only what you say that matters? And not so much how it is said? A good syntax shall be Clear Unambiguous Intuitive 06/0/200 p38 Master 2 Critical System Synchronous programming David LESENS 9

20 Statement groups In C, C++, Java if ( light == red ); { Cancel_lift_off(); } In Ada if light = red then; Cancel_lift_off; end if; Legal statement No warning The call to Cancel_lift_off is always executed Illegal statement No compilation 06/0/200 p39 Master 2 Critical System Synchronous programming David LESENS Named notation In C, C++, Java struct date { int day, month, year; }; In Ada type Date is record Day, Month, Year : Integer; end record; 06/0/200 p40 Master 2 Critical System Synchronous programming David LESENS 20

21 Named notation In C, C++, Java struct date today = { 2,, 5 }; What does it mean? In Ada Today: Date := ( Day => 2, Month =>, Year => 5 ); Notation usable also for function call 06/0/200 p4 Master 2 Critical System Synchronous programming David LESENS Using distinct types In C++ int badcount, goodcount; int b_limit, g_limit; badcount++; if ( badcount == b_limit ) { goodcount++; if ( goodcount == b_limit ) { Do we really mean that? 06/0/200 p42 Master 2 Critical System Synchronous programming David LESENS 2

22 Using distinct types In Ada type Goods is new Integer; type Bads is new Integer; badcount, b_limit : Goods goodcount, g_limit: Bads badcount := badcount+; if badcount = b_limit then goodcount := goodcount+; if goodcount = b_limit then Illegal Bad typing Strong typing is a good rule of critical software 06/0/200 p43 Master 2 Critical System Synchronous programming David LESENS Formal languages Programming languages are more or less formal Ada is more formal than Java Java is more formal than C++ C++ is more formal than C C is more formal than Matlab The risk of errors is less important with a formal language 06/0/200 p44 Master 2 Critical System Synchronous programming David LESENS 22

23 case State is when State => Guard := X < 3; Guard2 := X > 3; if (EVENT and (Guard or Guard2)) then if (Guard) then X := 5; State := State2; else if (Guard2) then X := 6; end if; State := State3; end if; end if; when State2 => if (EVENT) then X := 7; State := State; end if; when State3 => if (EVENT and EVENT) then X := 8; State := State; end if; end case; An other very simple example Simple? Yes But what does this piece of code do? Code (even Ada) is not an adequate way to communicate with system engineer 06/0/200 p45 Master 2 Critical System Synchronous programming David LESENS The same very simple example SCADE SCADE A graphical language with a high level of abstraction facilitates the communication 06/0/200 p46 Master 2 Critical System Synchronous programming David LESENS 23

24 Overview Critical real-time embedded software Principles of the approach Introduction Formal semantics SCADE Model validation 06/0/200 p47 Master 2 Critical System Synchronous programming David LESENS Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p48 Master 2 Critical System Synchronous programming David LESENS 24

25 Wikipedia Need of deterministic algorithm In computer science, a deterministic algorithm is an algorithm which, in informal terms, behaves predictably Given a particular input, it will always produce the same output, and the underlying machine will always pass through the same sequence of states 06/0/200 p49 Master 2 Critical System Synchronous programming David LESENS Wikipedia Determinism and ECSS ECSS-Q-80C Handling of critical software The supplier shall define and apply measures to assure the dependability and safety of critical software. These measures can include: prohibiting the use of language commands and features that are unpredictable; use of formal design language for formal proof; 06/0/200 p50 Master 2 Critical System Synchronous programming David LESENS 25

26 Synchronous languages Semantics = synchronous hypothesis Existence of a global clock Software cyclically activated Inputs read at the cycle beginning Outputs delivered at cycle end (read / write forbidden during the cycle) The cycle execution duration shall theoretically be null No cycle overflow Mono-tasking Ensures the determinism 06/0/200 p5 Master 2 Critical System Synchronous programming David LESENS Asynchronous versus synchronous Asynchronous system Start of an execution cycle End of an execution cycle Inputs can be received at any time I I O I O Outputs can be emitted at any time Synchronous system Inputs shall be available at cycle start I O Outputs are emitted at cycle end 06/0/200 p52 Master 2 Critical System Synchronous programming David LESENS 26

27 Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p53 Master 2 Critical System Synchronous programming David LESENS SCADE Safety Critical Application Development Environment A textual language: Lustre Formal language for reactive synchronous system A graphical language Semantics equivalence SCADE Lustre Adapted to data flow and automata A software toolbox Graphical editor, simulator, proof tool Automatic documentation and certified code generation Synchronous approach 06/0/200 p54 Master 2 Critical System Synchronous programming David LESENS 27

28 Syntax & Semantics checker SysML Gateway Simulink Simulator Interactive Batch Documentation generator Traceability tool SCADE editor Formal proof Qualified code generator CC Model Test Coverage Ada 06/0/200 p55 Master 2 Critical System Synchronous programming David LESENS Time in Scade Global clock (known by all processes) Time = discrete sequence of tick t 0, t, t 2, etc. At each tick t i a cycle is running Variable = flow which takes at each tick a unique value Example: integer variable x t 0 t t 2 t 3 t 4 t 5 x /0/200 p56 Master 2 Critical System Synchronous programming David LESENS 28

29 Operators An operator acts on flows of values (and not on values) Example Operator «+»: int n x int n int n t 0 t t 2 t 3 t 4 t 5 x x + x /0/200 p57 Master 2 Critical System Synchronous programming David LESENS Temporal operators The PRE operator takes as input a data flow (i.e. a variable) and returns its value at the previous tick. At initial tick, its value is undefined. The operator takes as input an initialisation value and a data flow of the same type. It returns an identical data flow, except for the initial value. 06/0/200 p58 Master 2 Critical System Synchronous programming David LESENS 29

30 Example t 0 t t 2 t 3 t 4 t 5 x PRE x null > x > PRE x /0/200 p59 Master 2 Critical System Synchronous programming David LESENS Follow by operator FBY( x, n, init ) = init ( PRE ( PRE x ) ) n times t 0 t t 2 t 3 t 4 t 5 x > PRE x FBY(x,3,9) /0/200 p60 Master 2 Critical System Synchronous programming David LESENS 30

31 SCADE at a glance: Data Flow Data flows Inputs on the left X Y A U V B T Outputs on the right L C Z Local variables L D M Imported operator Procedure call 06/0/200 p6 Master 2 Critical System Synchronous programming David LESENS Textual versus graphical ( x, y ) = A(); B( x, y ); C( y ) X A Y B false C 06/0/200 p62 Master 2 Critical System Synchronous programming David LESENS 3

32 Basic operations (/2) Less Less or equal Greater Greater or equal Different I O I2 O2 Addition O3 O4 O5 I I2 I3 Subtraction Multiplication Division Integer division Modulo Unary minus MOD O O2 O3 O4 O5 O6 O7 O8 O9 Equal O6 Convert to real REAL O0 06/0/200 p63 Master 2 Critical System Synchronous programming David LESENS Basic operations (2/2) And Or I O I O I2 I2 I3 O2 I3 O2 Mutual exclusion I Not O I O Different O2 I2 I3 O2 I2 O3 Equal 06/0/200 p64 Master 2 Critical System Synchronous programming David LESENS 32

33 Mutual exclusion operator #: bool x bool x x bool bool e n times e /0/200 p65 Master 2 Critical System Synchronous programming David LESENS e Returns true if at most one of its inputs is true #(e, e2, e3) Delays Generally not used I D PRE O I PRE PRE O2 D D2 Input I FBY O3 initial value I D FBY 2 O4 Output D Delay 06/0/200 p66 Master 2 Critical System Synchronous programming David LESENS 33

34 Node and function y = f( x ) Function and nodes are represented by a rectangle A node has an internal state A function has no internal state Input parameters on on the left Output parameters on on the right x f y 06/0/200 p67 Master 2 Critical System Synchronous programming David LESENS Imported function / node Imported function extern void C( C( bool Y ); ); Imported node extern void C_reset( outc_c *outc ); ); extern void C( C( bool Y, Y, outc_c *outc ); ); Context to to be be defined by by the developer 06/0/200 p68 Master 2 Critical System Synchronous programming David LESENS 34

35 Data structure DTG_Data T_ DT G_ dat a Xp Xm Yp Ym Xp := DTG_data.Xp Xm := DTG_data.Xm Yp := DTG_data.Yp Ym := DTG_data.Ym Xp Xm Yp T_ DT G_ dat a DTG_Data Ym DTG_data.Xp := Xp DTG_data.Xm := Xm DTG_data.Yp := Yp DTG_data.Ym := Ym 06/0/200 p69 Master 2 Critical System Synchronous programming David LESENS Variables representation Input Output Input Local_v ariable Local_v ariable Local_v ariable Output Local_v ariable Input Output Input Local_v ariable Local_v ariable Local_v ariable Local_v ariable Output 06/0/200 p70 Master 2 Critical System Synchronous programming David LESENS 35

36 Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p7 Master 2 Critical System Synchronous programming David LESENS Browser Main window (graph) 06/0/200 p72 Master 2 Critical System Synchronous programming David LESENS Messages 36

37 Creating a new project 06/0/200 p73 Master 2 Critical System Synchronous programming David LESENS Browser Main window (graph) 06/0/200 p74 Master 2 Critical System Synchronous programming David LESENS Messages 37

38 Packages Definitions of Scade operators Imported operators Constants Types Sensors Packages Inside or outside a package 06/0/200 p75 Master 2 Critical System Synchronous programming David LESENS Management of types (/3) 06/0/200 p76 Master 2 Critical System Synchronous programming David LESENS 38

39 Management of types (2/3) 06/0/200 p77 Master 2 Critical System Synchronous programming David LESENS Management of types (3/3) 06/0/200 p78 Master 2 Critical System Synchronous programming David LESENS 39

40 Integers and reals Integers Binary 0b000 Octal 0563 Decimal 9637 Hexadecimal 0xAF6C Encoding short, int, long Float, double Shall be defined by the user 06/0/200 p79 Master 2 Critical System Synchronous programming David LESENS Defining a constant 06/0/200 p80 Master 2 Critical System Synchronous programming David LESENS 40

41 Changing an object properties 06/0/200 p8 Master 2 Critical System Synchronous programming David LESENS Keyword list Scade keywords abstract, activate, and, assume, automaton, bool, case, char, clock, const, default, div, do, else, elsif, emit, end, enum, every, false, fby, final, flatten, fold, foldi, foldw, foldwi, function, guarantee, group, if, imported, initial, int, is, last, let, make, map, mapfold, mapi, mapw, mapwi, match, merge, mod, node, not, numeric, of, onreset, open, or, package, parameter, pre, private, probe, public, real, restart, resume, returns, reverse, sensor, sig, specialize, state, synchro, tel, then, times, transpose, true, type, unless, until, var, when, where, with, xor + Targeted programming language keywords 06/0/200 p82 Master 2 Critical System Synchronous programming David LESENS 4

42 Quick check The quick check performs syntax and semantics verification It It shall be be frequently used 06/0/200 p83 Master 2 Critical System Synchronous programming David LESENS Symbol editor Edition of the symbol Use of the symbol 06/0/200 p84 Master 2 Critical System Synchronous programming David LESENS 42

43 Display types / variable names / 06/0/200 p85 Master 2 Critical System Synchronous programming David LESENS Generation of documentation 06/0/200 p86 Master 2 Critical System Synchronous programming David LESENS 43

44 Report customization 06/0/200 p87 Master 2 Critical System Synchronous programming David LESENS Code generation customization 06/0/200 p88 Master 2 Critical System Synchronous programming David LESENS 44

45 File management Scade6Training.xscade ImportedOperator.xscade OutsidePackageOperator.xscade ActivationPackage.xscade ArrayPackage.xscade AutomatonPackage.xscade Cours.xscade Genericity.xscade ProbePackage.xscade Proof.xscade 06/0/200 p89 Master 2 Critical System Synchronous programming David LESENS Documentation 06/0/200 p90 Master 2 Critical System Synchronous programming David LESENS 45

46 Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p9 Master 2 Critical System Synchronous programming David LESENS IF operator x = if b then y else z If b is true, x takes the value y, else, x takes the value z Note: Does not mean If b is true, execute y, else, execute z 06/0/200 p92 Master 2 Critical System Synchronous programming David LESENS 46

47 If versus IfBlock int intifwithnodes(bool cond) { int intyf, yg; yg; yf=f (); (); yg=g(); if if (cond) { y = yf; yf; } else { y = yg; } return y; y; } Both branch are executed void IfBlockWithNodes(bool cond) { int inty; y; if if (cond) { y = f f (); ();} else { y = g (); ();} } Only one branch is is executed 06/0/200 p93 Master 2 Critical System Synchronous programming David LESENS When Block int intcase(t_enum enumerated) { switch (enumerated) { case black :: y = ; ; break; case red :: y = 2; 2; break; case green :: y = 3; 3; break; } return y; y; } 06/0/200 p94 Master 2 Critical System Synchronous programming David LESENS 47

48 Condition Activation conditions Activation condition Condition true = Block activated Condition false = Previous outputs used (was condact in Scade 5) or Default values Init values before first use Counter 5 Activ ateoutput Restart condition Condition true = Internal memory reset 06/0/200 p95 Master 2 Critical System Synchronous programming David LESENS Activation: Example (/3) x = a + b, initial default value 5, activation condition c y = a + b, default value 5, activation condition c Default values c 0 0 Computed values 0 a b x y Last computed values 06/0/200 p96 Master 2 Critical System Synchronous programming David LESENS Default value 48

49 Activation: Example (2/3) 06/0/200 p97 Master 2 Critical System Synchronous programming David LESENS if if (Activate) { Output_default_initial_value = A(); A(); Output_default_value = A(); A(); } else else { if if (init) (init) Output_default_initial_value = 5; 5; } Output_default_value = 5; 5; init init = false; Last computed values BOOLEAN_ACTIVATED::B/Activate/: true BOOLEAN_ACTIVATED::B/Output_default_initial_value/: 20 Introduce an an internal state BOOLEAN_ACTIVATED::B/Output_default_value/: 20 Default value /0/200 p98 Master 2 Critical System Synchronous programming David LESENS 49

50 Activation and restart Output PRE 0 Condition Activation // restart condition Previous value Condition A c t i v a t i o n P a c k a g e Activation A c t i v a t i o n P a c k a g e Counter 5 Activ ateoutput Computed value Condition Default value Restart A c t i v a t i o n P a c k a g e Counter 4 RestartOutput Re-initialization 06/0/200 p99 Master 2 Critical System Synchronous programming David LESENS Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p00 Master 2 Critical System Synchronous programming David LESENS 50

51 SCADE at a glance: Automaton Initial state Parallel states Guard <SM> Strong transition <SM2> Action 'SYNCHRO Z = 4.2; STATE_ 2 Y = (-) Weak transition INIT2 5 times true S STATE2_ <SM3> STATE2 times <SM4> STATE_2 STATE_3 2 S STATE2 3 L D M X Y = 2 L > 2 and Y < (-4) STATE2 2 History INIT3 0 Y X X * STATE5_ last 'Y + Y STATE5_ Y > 2 Y < (-4) STATE5_2 last 'Y - 3 S 06/0/200 p0 Master 2 Critical System Synchronous programming David LESENS <SM6> <SM5> Y Final state STATE2_2 4 S STATE2 4 emit 'SYNCHRO; Synchronization Data flow and automata A node is composed of Equations (data-flow) Automata (event driven) An automaton is composed of States Transitions A state is composed of Equations Automata step cmd Counter CL CL = 5 step2 2 cmd 2 Counter CL CL = 3 <SM> step3 3 cmd 06/0/200 p02 Master 2 Critical System Synchronous programming David LESENS 5

52 Principles of Automata Semantics equivalence There exists a data-flow model semantically equivalent to any automaton Automaton scheduling At most one transition fired per cycle Exactly one active state per cycle (except then parallel states are defined) 06/0/200 p03 Master 2 Critical System Synchronous programming David LESENS States A state can be An initial state / a final state Hidden / nested protection <SM> Initial f alse <SM2> isactiv e <SM3> inactiv e inactiv e inactiv e Final start start2 true isactiv e activ e activ e Nested 06/0/200 p04 Master 2 Critical System Synchronous programming David LESENS 52

53 Automaton simulation Active state Graph Watch 06/0/200 p05 Master 2 Critical System Synchronous programming David LESENS Transitions A transition can have a weak pre-emption have a strong pre-emption be synchronized It can have A guard An action It has a priority It can be with or without a history 06/0/200 p06 Master 2 Critical System Synchronous programming David LESENS 53

54 Graphical transitions State Strong without history Synchronized without history Weak with history State4 State5 true State7 true true State2 State3 State6 06/0/200 p07 Master 2 Critical System Synchronous programming David LESENS * * true * Weak without history Strong with history Synchronized with history Strong and weak transitions Strong transition The transition is triggered before the state execution The guard can not depend on the current value of a data Weak transition (or weak delayed ) The state is executed before the transition triggering The guard can depend on the current value of a data 06/0/200 p08 Master 2 Critical System Synchronous programming David LESENS 54

55 Strong and weak transition Strong transition Weak transition 06/0/200 p09 Master 2 Critical System Synchronous programming David LESENS Example (/2) Strong transition Weak transition inactiv e inactiv e * stop * stop * start activ e * start activ e last 'count last 'count count count start T stop T count strong count weak /0/200 p0 Master 2 Critical System Synchronous programming David LESENS

56 Example (2/2) The behaviours of the two following models are equivalent <SM> <SM> step step cmd cmd Counter CL Counter CL last 'CL = 5 CL = 5 step2 step2 2 2 cmd cmd Previous value 06/0/200 p Master 2 Critical System Synchronous programming David LESENS Synchronized transition A synchronized transition Has no guard Is triggered as soon as all nested automata reach a final state 06/0/200 p2 Master 2 Critical System Synchronous programming David LESENS 56

57 Example Start received o Still in protection state Start2 received o Final states reached Transition inactive triggered 06/0/200 p3 Master 2 Critical System Synchronous programming David LESENS Transition history Transition without history The state resumes its execution The memories are reset Transition with history The state resumes its execution The memories are not reset Two types of memories PRE : local to the state LAST : common to the node 06/0/200 p4 Master 2 Critical System Synchronous programming David LESENS 57

58 Transition with history Restart Resume 06/0/200 p5 Master 2 Critical System Synchronous programming David LESENS Shared memory Data flow point of view Access to the last value of a flow in its scope pre expression Mode automata point of view Access to values computed in other states last x ( x is a named flow, not an expression utilization of ) 06/0/200 p6 Master 2 Critical System Synchronous programming David LESENS 58

59 With history last 'count * last 'count inactiv e start * stop activ e 0 0 count count A u t o m a t o n P a c k start LAST memory A u t o m a t o n P a c k shared stop between the A u t o m the states a t o n P a c k inactiv e pre count 0 count start * stop * activ e pre count 0 count PRE memory local to to the the state 06/0/200 p7 Master 2 Critical System Synchronous programming David LESENS Internal A u t o m memory a t o not reset start n P a c k A u t o m a t o n P a c k stop A u t o m a t o n P a c k Default actions in state inactiv e * stop By By default the the variable keeps its its previous value AutomatonPackage::AutomatonStro start * activ e AutomatonPackage::AutomatonStro last 'count count AutomatonPackage::AutomatonStro Initial value (replaces -> ) 06/0/200 p8 Master 2 Critical System Synchronous programming David LESENS 59

60 Modifying the default action inactiv e AutomatonPackage::AutomatonStro * start * activ e stop Modification of of the the default behaviour AutomatonPackage::AutomatonStro last 'count count Generated documentation Name Type count int Properties default last 'count - last 5 06/0/200 p9 Master 2 Critical System Synchronous programming David LESENS AutomatonPackage::AutomatonStro Signals A signal can be Present true Absent false A signal can not be An input / output Boolean value A Boolean value keeps its previous value then non updated in a state <SM> State S next State2 S2 next State3 A u t o m a t o n P a c k a g e ::A u t o m a S A u t o m a t o n P a c k a g e ::A u t o m a S2 A u t o m a t o n P a c k a g e ::A u t o m a S3 S3 06/0/200 p20 Master 2 Critical System Synchronous programming David LESENS 0 60

61 Composition and communication A signal can be Emitted in a state Emitted on a transition A transition can be triggered by a signal 06/0/200 p2 Master 2 Critical System Synchronous programming David LESENS Factor A factor specifies on many time a condition must be true In a data flow view In a guard (automaton) arg 5 DataFlowTimesOut State <SM> AutomatonPackage::AutomatonFactor/arg/: true arg f alse 5 times arg AutomatonTimesOut A uto mato np ackage::a uto mato nfacto r/dataflo wtimesou DataFlow true State2 AutomatonTimesOut AutomatonPackage::AutomatonFactor/AutomatonTimes Automaton 06/0/200 p22 Master 2 Critical System Synchronous programming David LESENS 6

62 Time-out with factor true Step Step_ true Step2 Step_2 true Step3 Step_3 true Step4 Step_4 5 times true DURATION times true ( duration = 20 ) 0 times true 5 A u t o m a t o n P a c k a g e : Step 20 A u t o m a t o n P a c k a g e : Step 2 0 A u t o m a t o n P a c k a g e : Step 3 06/0/200 p23 Master 2 Critical System Synchronous programming David LESENS Fork Common guard true State S Specific guard trigger true State2 v alue = v alue = 2 2 true State3 S2 3 S3 Priority true State4 S4 06/0/200 p24 Master 2 Critical System Synchronous programming David LESENS 62

63 Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p25 Master 2 Critical System Synchronous programming David LESENS Arrays definition Restrictions Static size First element = index 0 Definitions type VECTOR = real ^ 4 ; type MATRIX_2_3 = real ^ 3 ^ 2 ; 2 lines, 3 columns typedef real LINE_3[3]; typedef LINE_3 MATRIX_2_3 [2]; 06/0/200 p26 Master 2 Critical System Synchronous programming David LESENS 63

64 Editing array types Array type Type name Array size Generated code typedef _real array_2[2]; typedef array_2 array_[3]; typedef array_ T_MATRIX_3_2 ArrayPackage; 06/0/200 p27 Master 2 Critical System Synchronous programming David LESENS Array access Dynamic Array 5 [] 2 index Static Array5=[2,4,6,8,0], Index=3 Dy namicprojection Index = 3 Output = 8 Index = 0 Output = 2 Default value for for index out of of range Array 5 [2] Assignment Array 5 [0] StaticProjection AssignOf StructureElement Output = 6 newvalue = 3 Output = [3,4,6,8,0] newvalue 06/0/200 p28 Master 2 Critical System Synchronous programming David LESENS 64

65 Some operators on arrays Constructor Value repetition [5.0, 6.0, 9.0,.0] 4 2 Vector4 06/0/200 p29 Master 2 Critical System Synchronous programming Rev erse_vector4 David LESENS 2 Matrix_3_2 Matrix_2_3 Vector2 Vector6 Data to to Vector Transpose of of an an Array Scalar to to Vector Slice of of a vector Concatenation of of Arrays Reverse of of a Vector Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p30 Master 2 Critical System Synchronous programming David LESENS 65

66 Iterations Equivalent to for in C Map / Mapi / Mapw / Mapiw Fold / Foldi / Foldi / Foldiw 06/0/200 p3 Master 2 Critical System Synchronous programming David LESENS Map FirstInt5 map<<5>> MapInt5 SecondInt5 for for (i (i = 0; 0; i i < 5; 5; i++) { MapInt5[i] = FirstInt5[i] + SecondInt5[i]; } MAP: Apply the the operator successively on on each element of of the the input vector(s) element[i].element [i] Size of of the the input vector 06/0/200 p32 Master 2 Critical System Synchronous programming David LESENS 66

67 Fold InputInt a fold<<5>> FoldInt FirstInt5 FoldInt = InputInt; for for (i (i = 0; 0; i i < 5; 5; i++) { FoldInt = FoldInt + FirstInt5[i]; } First element of of the the iteration FOLD: Apply recursively the the operator on on input vector element[i].element[i+] 06/0/200 p33 Master 2 Critical System Synchronous programming David LESENS Mapfold Operator add_2 Input sum InputInt a mapfold<<5>> add_2 MapFoldInt Input2 sum2 FirstInt5 MapFold2Int5 MapFoldInt = InputInt; Recursion for for (i (i = 0; 0; i i < 5; 5; i++) { add_2_arraypackage(mapfoldint, FirstInt5[i], &MapFoldInt, &MapFold2Int[i]); } Succession Nodes used with a mapfold iterator should duplicate their output We obtain both results at at the the same time 06/0/200 p34 Master 2 Critical System Synchronous programming David LESENS 67

68 Mapi = Map with iterator as input FirstInt5 i mapi<<5>> MapiInt5 Only one input for for (i (i = 0; 0; i i < 5; 5; i++) { MapiInt5[i] = i i + FirstInt5[i]; } The index of of the the iteration is is the the first argument of of the the node 06/0/200 p35 Master 2 Critical System Synchronous programming David LESENS Foldi = Fold with iterator as input InputInt ai foldi<<5>> FoldiInt No No vector in in input FoldiInt = InputInt; for for (i (i = 0; 0; i i < 5; 5; i++) { FoldiInt = i i + FoldiInt; } The input flow is is the the iterator 06/0/200 p36 Master 2 Critical System Synchronous programming David LESENS 68

69 Mapw / Foldw = Partial operators Capability to stop an iteration on a Boolean condition computed by the operator Operator add Input Input2 sum The iteration can be be stopped 0 condition As As soon as as the the condition is is false, the the iteration is is topped 06/0/200 p37 Master 2 Critical System Synchronous programming David LESENS Mapw = Map partial operator ConditionBool Default value after the the Iteration stop FirstInt5 SecondInt5 mapw<<5>> 64 add 4 MapwExitIndexInt MapwInt5 MapwExitIndexInt = 0; 0; for for (i (i = 0; 0; i i < 5; 5; i++) { if if (ConditionBool) { The iteration can be be stopped add(firstint5[i], SecondInt5[i], &ConditionBool, &MapwInt5[i]); MapwExitIndexInt = i i + ; ; } else { MapwInt5[i] = 4; 4; } } Default value after the the Iteration stop It is recommended to not use this operator (WCET) 06/0/200 p38 Master 2 Critical System Synchronous programming David LESENS 69

70 Mapwi = Mapi + Mapw ConditionBool Default value after the the Iteration stop i mapwi<<5>> add 67 MapwiExitIndexInt FirstInt5 MapwiInt5 06/0/200 p39 Master 2 Critical System Synchronous programming David LESENS 4 MapwiExitIndexInt = 0; 0; The iteration can be be stopped for for (i (i = 0; 0; i i < 5; 5; i++) { if if (ConditionBool) { The iterator is is the the first argument add(i, FirstInt5[i], & ConditionBool, &MapwiInt5[i]); MapwiExitIndexInt = i i + ; ; } else { outc->mapwiint5[i] = 4; 4; } } Default value after the the Iteration stop It is recommended to not use this operator (WCET) Foldw = Fold partial operator ConditionBool InputInt a foldw<<5>> add 74 FoldwExitIndexInt FirstInt5 FoldwInt FoldwInt = InputInt; for for (i (i = 0; 0; i i < 5; 5; i++) { if if (( ConditionBool )){ break; } The iteration can be be stopped add(foldwint, FirstInt5[i], & ConditionBool, &tmp); FoldwInt = tmp; } 06/0/200 p40 Master 2 Critical System Synchronous programming David LESENS 70

71 Foldwi = Foldi + Foldw ConditionBool InputInt i a foldwi<<5>> 80 add FoldwiExitIndexInt FoldwiInt5 FoldwiInt5 = InputInt; tmp = ConditionBool; for for (i (i = 0; 0; i i < 5; 5; i++) { if if (( ConditionBool) { break; } add(i, FoldwiInt5, & ConditionBool, &tmp); FoldwiInt5 = tmp; } FoldwiExitIndexInt = i; i; The iteration can be be stopped The input flow is is the the iterator 06/0/200 p4 Master 2 Critical System Synchronous programming David LESENS Iteration summary Map = Successive application Fold = Recursive application Mapfold = Map + Fold Mapi = Map with iterator as input Foldi = Fold with iterator as input Mapw = Map partial operator Mapwi = Mapi + Mapw Foldw = Fold partial operator Foldwi = Foldi + Foldw 06/0/200 p42 Master 2 Critical System Synchronous programming David LESENS 7

72 Example Without loop With loop 06/0/200 p43 Master 2 Critical System Synchronous programming David LESENS Example 2: cross product Compute scalar product Compute vector norm Compute cross product 06/0/200 p44 Master 2 Critical System Synchronous programming David LESENS 72

73 Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p45 Master 2 Critical System Synchronous programming David LESENS Sensors Sensor: Global system input Input temperature Output heater Sensor temperature commanded_heater heater aimed_temperature extern _int aimed_temperature ProbePackage; 06/0/200 p46 Master 2 Critical System Synchronous programming David LESENS 73

74 Probes Probe: Global system output temperature commanded_heater heater Probe aimed_temperature typedef struct {/* context */ */ _bool heater; /* /* outputs */ */ _bool commanded_heater; /* /* probes */ */ } C_controller ProbePackage; 06/0/200 p47 Master 2 Critical System Synchronous programming David LESENS Overview Synchronous model Introduction to the Scade language Editing a Scade model Activation conditions Automata Arrays Iterations Global flows: Sensors and probes Genericity 06/0/200 p48 Master 2 Critical System Synchronous programming David LESENS 74

75 Generic operator definition GenericSquare Specialization arg square_out argint GenericSquare squareint Input Output Name arg square_out Type 'T 'T argreal 2 GenericSquare squarereal Name Generic Type 'T numeric Definition of of a generic numeric type 06/0/200 p49 Master 2 Critical System Synchronous programming David LESENS Generic operator instantiation int intgenericsquare_int (( int intarg )){ int intsquare_out; square_out = arg * arg; return square_out; } real GenericSquare_real (( real arg )){ real square_out; square_out = arg * arg; return square_out; } void Specialization( int intargint; real argreal; int intsquareint; real squarereal; )){ *squarereal = GenericSquare_real (( argreal ); ); *squareint = GenericSquare_int (( argint ); ); } 06/0/200 p50 Master 2 Critical System Synchronous programming David LESENS 75

76 Definition of parameters Definition of of a generic size ( parameter ) 06/0/200 p5 Master 2 Critical System Synchronous programming David LESENS Parameter instantiation REAL_RESULT = 0.0; for for (i (i = 0; 0; i i < 3; 3; i++) { REAL_RESULT = REAL_RESULT + (*LEFT)[i] * (*RIGHT)[i]; } return REAL_RESULT; 06/0/200 p52 Master 2 Critical System Synchronous programming David LESENS 76

77 Overview Critical real-time embedded software Principles of the approach Introduction Formal semantics SCADE Model validation 06/0/200 p53 Master 2 Critical System Synchronous programming David LESENS Software validation Correct software No runtime errors Satisfaction of real time constraints Compliance with the expected results Solutions Manual review Dynamic testing A code level At model level Semantics checking Abstract interpretation Formal proof Costly Error prone Costly Non exhaustive 06/0/200 p54 Master 2 Critical System Synchronous programming David LESENS 77

78 Semantics verification (/2) Semantics of a SCADE model Syntax Typing verification Types compatibility Example: Integer real Non uninitialized variables Temporal causality 06/0/200 p55 Master 2 Critical System Synchronous programming David LESENS Temporal causality SCADE is an equational language The evaluation order depends only on data flows x = y; y = z; x = y; y = z; z = x; y = z evaluated first x = y evaluated secondly Impossible computation of the evaluation order x = y = z = x = Causality problem 06/0/200 p56 Master 2 Critical System Synchronous programming David LESENS 78

79 Semantics verification (2/2) A SCADE model with a correct semantics is: Complete Consistent Implementable The good properties of a specification Semantics check to be systematically performed But does the software behave as expected? 06/0/200 p57 Master 2 Critical System Synchronous programming David LESENS Software validation Correct software No runtime errors Satisfaction of real time constraints Compliance with the expected results Solutions Manual review Dynamic testing A code level At model level Semantics checking Abstract interpretation Formal proof Costly Error prone Costly Non exhaustive 06/0/200 p58 Master 2 Critical System Synchronous programming David LESENS 79

80 What is testing? Compare the observed behaviour with the expected behaviour Several levels of test Unitary / integration / validation / system qualification Host / target Real equipment / simulator White box / Black box At code or model level 06/0/200 p59 Master 2 Critical System Synchronous programming David LESENS Objectives of unitary tests Robustness Absence of runtime error Functional validity Comparison with the expected results Contractual objectives Coverage Intuitively satisfactory Measurable But not a proof of exhaustiveness 06/0/200 p60 Master 2 Critical System Synchronous programming David LESENS 80

81 Unitary tests: Coverage Procedure Procedure f(x f(x : : in in real; real; y: y: in in real; real; z z : : out out real) real) if if (x (x > >.0).0) or or (x (x < < -.0) -.0) then then z z := := y/x; y/x; else else z z := := y; y; if if z z < < then then z z = = 2.0; 2.0; Coverage branch decision path (x=2.0, y=6.0), (x=-.0,y=.0) + (x=-2, y=3.0) + (x=2.0, y=.0), (x=0.5,y=2.0) 06/0/200 p6 Master 2 Critical System Synchronous programming David LESENS Coverage of a SCADE model Warning Both branches are executed whatever the value of inc PRE 0 2 inc = true = false Counter 06/0/200 p62 Master 2 Critical System Synchronous programming David LESENS 8

82 Integration test Validated by Unitary Tests Module A Module B Do they work together? y = f( x, x 2 ) ou y = f( x 2, x ) Module A Module B Validation of interfaces in white box 06/0/200 p63 Master 2 Critical System Synchronous programming David LESENS Limit of the white box approach The presence of a spy may modify the real time behaviour What happens if the debugger / simulator has a bug? 06/0/200 p64 Master 2 Critical System Synchronous programming David LESENS 82

83 Validation Black box tests Control of the inputs Observations of the outputs Non intrusive On host or on target Tests on target are more expensive 06/0/200 p65 Master 2 Critical System Synchronous programming David LESENS Software validation Correct software No runtime errors Satisfaction of real time constraints Compliance with the expected results Solutions Manual review Dynamic testing A code level At model level Semantics checking Abstract interpretation Formal proof Costly Error prone Costly Non exhaustive But proof can not completely replace testing 06/0/200 p66 Master 2 Critical System Synchronous programming David LESENS 83

84 Software testing Test coverage Error states Concrete semantics Non detected failure Tested execution OK Possible execution Program testing can be used to show the presence of bugs, but never to show their absence! Edgser W. Dijkstra 06/0/200 p67 Master 2 Critical System Synchronous programming David LESENS Principle of the proof Non computable Concrete semantics Error states Abstract semantics Computable and sound abstraction Verified In order to reason or compute about a complex system, some information must be lost Patrick Cousot 06/0/200 p68 Master 2 Critical System Synchronous programming David LESENS 84

85 Proof limitation Concrete semantics Error states Abstract semantics Warning False alarms! Computable but incomplete 06/0/200 p69 Master 2 Critical System Synchronous programming David LESENS Example () Warning int a[000]; for (i = 0; i < 000; i++) { for (j = 0; j < 000 i; j++) { // 0 <= i <= 999 // 0 <= j <= 999 a[i+j] = 0; 999 } i Error } states Non conclusive j 06/0/200 p70 Master 2 Critical System Synchronous programming David LESENS 85

86 Example (2) Safe int a[000]; for (i = 0; i < 000; i++) { for (j = 0; j < 000 i; j++) { // 0 <= i and 0 <= j // i+j <= 999 a[i+j] = 0; 999 } i Error } states Conclusive j 06/0/200 p7 Master 2 Critical System Synchronous programming David LESENS Safety et liveness properties Safety Bad things never happen Liveness Some thing good will eventually happen in the future Concrete semantics Error states State to be reached Abstract semantics 06/0/200 p72 Master 2 Critical System Synchronous programming David LESENS The proof tool of SCADE can not prove liveness properties 86

87 Interest of the liveness properties Liveness property / timed property Example: if an error is detected, the software shall raise an alarm toward the user Liveness: the alarm will mandatorily be raised (one day or another) But when? Not acceptable for a critical real time piece of software Timed property: the alarm will mandatorily be raised second after the failure occurence Safety property 06/0/200 p73 Master 2 Critical System Synchronous programming David LESENS Formal proof Mathematical exhaustive demonstration that a piece of software/code satisfied a property Rarely the case! A piece software generally satisfies a property only in a correct environment 06/0/200 p74 Master 2 Critical System Synchronous programming David LESENS 87

88 The software is part of a complex system Environment Vehicle Equipment Equipment Equipment Bus Processor On On board Software board Computer Computer 06/0/200 p75 Master 2 Critical System Synchronous programming David LESENS Formal proof principles Software under validation Properties to be satisfied Software environment ( correct environment) software properties Environment in open or close loop 06/0/200 p76 Master 2 Critical System Synchronous programming David LESENS 88