Synchronous programming

Size: px
Start display at page:

Download "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

SCADE Suite in Space Applications

SCADE Suite in Space Applications SCADE Suite in Space Applications at EADS David Lesens 09/10/2008 Overview Introduction Historical use of SCADE at EADS Astrium ST Why using SCADE? The Automatic Transfer Vehicle (ATV) M51 and Vega R&T

More information

Certification of a Scade 6 compiler

Certification of a Scade 6 compiler Certification of a Scade 6 compiler F-X Fornari Esterel Technologies 1 Introduction Topic : What does mean developping a certified software? In particular, using embedded sofware development rules! What

More information

Specification and Analysis of Contracts Lecture 1 Introduction

Specification and Analysis of Contracts Lecture 1 Introduction Specification and Analysis of Contracts Lecture 1 Introduction Gerardo Schneider gerardo@ifi.uio.no http://folk.uio.no/gerardo/ Department of Informatics, University of Oslo SEFM School, Oct. 27 - Nov.

More information

The Kiel Reactive Processor

The Kiel Reactive Processor The Kiel Reactive Processor Reactive Processing beyond the KEP Claus Traulsen Christian-Albrechts Universität zu Kiel Synchron 2007 29. November 2007 Claus Traulsen The Kiel Reactive Processor Slide 1

More information

A Static Analyzer for Large Safety-Critical Software. Considered Programs and Semantics. Automatic Program Verification by Abstract Interpretation

A Static Analyzer for Large Safety-Critical Software. Considered Programs and Semantics. Automatic Program Verification by Abstract Interpretation PLDI 03 A Static Analyzer for Large Safety-Critical Software B. Blanchet, P. Cousot, R. Cousot, J. Feret L. Mauborgne, A. Miné, D. Monniaux,. Rival CNRS École normale supérieure École polytechnique Paris

More information

RATP safety approach for railway signalling systems

RATP safety approach for railway signalling systems RATP safety approach for railway signalling systems ReSIST summer School 007 Pierre CHARTIER Summary. Introduction. Hardware fault detection. 6 Introduction Global railway system Rolling stock Environment

More information

The Model Checker SPIN

The Model Checker SPIN The Model Checker SPIN Author: Gerard J. Holzmann Presented By: Maulik Patel Outline Introduction Structure Foundation Algorithms Memory management Example/Demo SPIN-Introduction Introduction SPIN (Simple(

More information

Know or Go Practical Quest for Reliable Software

Know or Go Practical Quest for Reliable Software Know or Go Practical Quest for Reliable Software Dr.-Ing. Jörg Barrho Dr.-Ing. Ulrich Wünsche AVACS Project meeting 25.09.2014 2014 Rolls-Royce Power Systems AG The information in this document is the

More information

Introduction to Programming

Introduction to Programming Introduction to Programming SS 2012 Adrian Kacso, Univ. Siegen adriana.dkacsoa@duni-siegena.de Tel.: 0271/740-3966, Office: H-B 8406 Stand: April 25, 2012 Betriebssysteme / verteilte Systeme Introduction

More information

[Refer Slide Time: 05:10]

[Refer Slide Time: 05:10] Principles of Programming Languages Prof: S. Arun Kumar Department of Computer Science and Engineering Indian Institute of Technology Delhi Lecture no 7 Lecture Title: Syntactic Classes Welcome to lecture

More information

Comprehensive Static Analysis Using Polyspace Products. A Solution to Today s Embedded Software Verification Challenges WHITE PAPER

Comprehensive Static Analysis Using Polyspace Products. A Solution to Today s Embedded Software Verification Challenges WHITE PAPER Comprehensive Static Analysis Using Polyspace Products A Solution to Today s Embedded Software Verification Challenges WHITE PAPER Introduction Verification of embedded software is a difficult task, made

More information

University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities

University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities II.2 Life Cycle and Safety Safety Life Cycle: The necessary activities involving safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when

More information

Sources: On the Web: Slides will be available on:

Sources: On the Web: Slides will be available on: C programming Introduction The basics of algorithms Structure of a C code, compilation step Constant, variable type, variable scope Expression and operators: assignment, arithmetic operators, comparison,

More information

Real Time Programming: Concepts

Real Time Programming: Concepts Real Time Programming: Concepts Radek Pelánek Plan at first we will study basic concepts related to real time programming then we will have a look at specific programming languages and study how they realize

More information

Informatica e Sistemi in Tempo Reale

Informatica e Sistemi in Tempo Reale Informatica e Sistemi in Tempo Reale Introduction to C programming Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa October 25, 2010 G. Lipari (Scuola Superiore Sant Anna)

More information

Best Practices for Verification, Validation, and Test in Model- Based Design

Best Practices for Verification, Validation, and Test in Model- Based Design 2008-01-1469 Best Practices for Verification, Validation, and in Model- Based Design Copyright 2008 The MathWorks, Inc. Brett Murphy, Amory Wakefield, and Jon Friedman The MathWorks, Inc. ABSTRACT Model-Based

More information

Software testing. Objectives

Software testing. Objectives Software testing cmsc435-1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating

More information

PATRIOT MISSILE DEFENSE Software Problem Led to System Failure at Dhahran, Saudi Arabia

PATRIOT MISSILE DEFENSE Software Problem Led to System Failure at Dhahran, Saudi Arabia --.- /Initcd Stdcs General Accounting Offiw Ikport to the Chairman, Subcommittee on Investigations and Oversight, Committee on Science, Space, and Technology, House of Rcprcsentativcs PATRIOT MISSILE DEFENSE

More information

Compliance and Requirement Traceability for SysML v.1.0a

Compliance and Requirement Traceability for SysML v.1.0a 1. Introduction: Compliance and Traceability for SysML v.1.0a This document provides a formal statement of compliance and associated requirement traceability for the SysML v. 1.0 alpha specification, which

More information

CS 141: Introduction to (Java) Programming: Exam 1 Jenny Orr Willamette University Fall 2013

CS 141: Introduction to (Java) Programming: Exam 1 Jenny Orr Willamette University Fall 2013 Oct 4, 2013, p 1 Name: CS 141: Introduction to (Java) Programming: Exam 1 Jenny Orr Willamette University Fall 2013 1. (max 18) 4. (max 16) 2. (max 12) 5. (max 12) 3. (max 24) 6. (max 18) Total: (max 100)

More information

Software Engineering. Computer Science Tripos 1B Michaelmas 2011. Richard Clayton

Software Engineering. Computer Science Tripos 1B Michaelmas 2011. Richard Clayton Software Engineering Computer Science Tripos 1B Michaelmas 2011 Richard Clayton Critical software Many systems must avoid a certain class of failures with high assurance safety critical systems failure

More information

The Lustre Language Synchronous Programming Pascal Raymond, Nicolas Halbwachs Verimag-CNRS

The Lustre Language Synchronous Programming Pascal Raymond, Nicolas Halbwachs Verimag-CNRS The Lustre Language Synchronous Programming Pascal Raymond, Nicolas Halbwachs Verimag-CNRS Data-flow approach 2 A program = a network of operators connected by wires Rather classical (control theory, circuits)

More information

First Java Programs. V. Paúl Pauca. CSC 111D Fall, 2015. Department of Computer Science Wake Forest University. Introduction to Computer Science

First Java Programs. V. Paúl Pauca. CSC 111D Fall, 2015. Department of Computer Science Wake Forest University. Introduction to Computer Science First Java Programs V. Paúl Pauca Department of Computer Science Wake Forest University CSC 111D Fall, 2015 Hello World revisited / 8/23/15 The f i r s t o b l i g a t o r y Java program @author Paul Pauca

More information

Static Analysis of the Mars Exploration Rover Flight Software

Static Analysis of the Mars Exploration Rover Flight Software Static Analysis of the Mars Exploration Rover Flight Software Guillaume Brat Kestrel Technology brat@email.arc.nasa.gov Roger Klemm California Institute of Technology roger.klemm@jpl.nasa.gov Abstract

More information

FROM SAFETY TO SECURITY SOFTWARE ASSESSMENTS AND GUARANTEES FLORENT KIRCHNER (LIST)

FROM SAFETY TO SECURITY SOFTWARE ASSESSMENTS AND GUARANTEES FLORENT KIRCHNER (LIST) FROM SAFETY TO SECURITY SOFTWARE ASSESSMENTS AND GUARANTEES FLORENT KIRCHNER (LIST) M loc 12 ONBOARD SOFTWARE SIZE 10 Volt (2011) F-35 (2012) 8 6 787 (2010) F-35 (2010) 4 2 F-22 (2005) 0 WHY DO WE TRUST

More information

Software Testing & Analysis (F22ST3): Static Analysis Techniques 2. Andrew Ireland

Software Testing & Analysis (F22ST3): Static Analysis Techniques 2. Andrew Ireland Software Testing & Analysis (F22ST3) Static Analysis Techniques Andrew Ireland School of Mathematical and Computer Science Heriot-Watt University Edinburgh Software Testing & Analysis (F22ST3): Static

More information

INTRODUCTION TO FLOWCHARTING

INTRODUCTION TO FLOWCHARTING CHAPTER 1 INTRODUCTION TO FLOWCHARTING 1.0 Objectives 1.1 Introduction 1.2 Flowcharts 1.3 Types of Flowcharts 1.3.1 Types of flowchart 1.3.2 System flowcharts 1.4 Flowchart Symbols 1.5 Advantages of Flowcharts

More information

Moving from CS 61A Scheme to CS 61B Java

Moving from CS 61A Scheme to CS 61B Java Moving from CS 61A Scheme to CS 61B Java Introduction Java is an object-oriented language. This document describes some of the differences between object-oriented programming in Scheme (which we hope you

More information

Software Safety Basics

Software Safety Basics Software Safety Basics (Herrmann, Ch. 2) 1 Patriot missile defense system failure On February 25, 1991, a Patriot missile defense system operating at Dhahran, Saudi Arabia, during Operation Desert Storm

More information

VALLIAMMAI ENGINEERING COLLEGE SRM NAGAR, KATTANKULATHUR 603 203 DEPARTMENT OF COMPUTER APPLICATIONS QUESTION BANK IN REVISED BLOOM S TAXONOMY

VALLIAMMAI ENGINEERING COLLEGE SRM NAGAR, KATTANKULATHUR 603 203 DEPARTMENT OF COMPUTER APPLICATIONS QUESTION BANK IN REVISED BLOOM S TAXONOMY ACADEMIC YEAR: 0 7 VALLIAMMAI ENGINEERING COLLEGE SRM NAGAR, KATTANKULATHUR 0 0 SEMESTER: ODD BRANCH: MCA YEAR: I SEMESTER: I SUBJECT CODE AND NAME: MC70 Problem Solving and Programming NAME OF THE FACULTY

More information

Embedded Systems. Review of ANSI C Topics. A Review of ANSI C and Considerations for Embedded C Programming. Basic features of C

Embedded Systems. Review of ANSI C Topics. A Review of ANSI C and Considerations for Embedded C Programming. Basic features of C Embedded Systems A Review of ANSI C and Considerations for Embedded C Programming Dr. Jeff Jackson Lecture 2-1 Review of ANSI C Topics Basic features of C C fundamentals Basic data types Expressions Selection

More information

Outline. hardware components programming environments. installing Python executing Python code. decimal and binary notations running Sage

Outline. hardware components programming environments. installing Python executing Python code. decimal and binary notations running Sage Outline 1 Computer Architecture hardware components programming environments 2 Getting Started with Python installing Python executing Python code 3 Number Systems decimal and binary notations running

More information

Real-Time Component Software. slide credits: H. Kopetz, P. Puschner

Real-Time Component Software. slide credits: H. Kopetz, P. Puschner Real-Time Component Software slide credits: H. Kopetz, P. Puschner Overview OS services Task Structure Task Interaction Input/Output Error Detection 2 Operating System and Middleware Applica3on So5ware

More information

Automated Model-Based Testing of Embedded Real-Time Systems

Automated Model-Based Testing of Embedded Real-Time Systems Automated Model-Based Testing of Embedded Real-Time Systems Jan Peleska jp@tzi.de University of Bremen Bieleschweig Workshop 7 2006-05-05 Outline Technologie-Zentrum Informatik Objectives Basic concepts

More information

Syntax Check of Embedded SQL in C++ with Proto

Syntax Check of Embedded SQL in C++ with Proto Proceedings of the 8 th International Conference on Applied Informatics Eger, Hungary, January 27 30, 2010. Vol. 2. pp. 383 390. Syntax Check of Embedded SQL in C++ with Proto Zalán Szűgyi, Zoltán Porkoláb

More information

PROBLEM SOLVING SEVENTH EDITION WALTER SAVITCH UNIVERSITY OF CALIFORNIA, SAN DIEGO CONTRIBUTOR KENRICK MOCK UNIVERSITY OF ALASKA, ANCHORAGE PEARSON

PROBLEM SOLVING SEVENTH EDITION WALTER SAVITCH UNIVERSITY OF CALIFORNIA, SAN DIEGO CONTRIBUTOR KENRICK MOCK UNIVERSITY OF ALASKA, ANCHORAGE PEARSON PROBLEM SOLVING WITH SEVENTH EDITION WALTER SAVITCH UNIVERSITY OF CALIFORNIA, SAN DIEGO CONTRIBUTOR KENRICK MOCK UNIVERSITY OF ALASKA, ANCHORAGE PEARSON Addison Wesley Boston San Francisco New York London

More information

PRACTICE BOOK COMPUTER SCIENCE TEST. Graduate Record Examinations. This practice book contains. Become familiar with. Visit GRE Online at www.gre.

PRACTICE BOOK COMPUTER SCIENCE TEST. Graduate Record Examinations. This practice book contains. Become familiar with. Visit GRE Online at www.gre. This book is provided FREE with test registration by the Graduate Record Examinations Board. Graduate Record Examinations This practice book contains one actual full-length GRE Computer Science Test test-taking

More information

Glossary of Object Oriented Terms

Glossary of Object Oriented Terms Appendix E Glossary of Object Oriented Terms abstract class: A class primarily intended to define an instance, but can not be instantiated without additional methods. abstract data type: An abstraction

More information

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com Reduce Medical Device Compliance Costs with Best Practices mark.pitchford@ldra.com 1 Agenda Medical Software Certification How new is Critical Software Certification? What do we need to do? What Best Practises

More information

Simulink Modeling Guidelines for High-Integrity Systems

Simulink Modeling Guidelines for High-Integrity Systems Simulink Modeling Guidelines for High-Integrity Systems R2015a How to Contact MathWorks Latest news: www.mathworks.com Sales and services: www.mathworks.com/sales_and_services User community: www.mathworks.com/matlabcentral

More information

The Course. http://www.cse.unsw.edu.au/~cs3153/

The Course. http://www.cse.unsw.edu.au/~cs3153/ The Course http://www.cse.unsw.edu.au/~cs3153/ Lecturers Dr Peter Höfner NICTA L5 building Prof Rob van Glabbeek NICTA L5 building Dr Ralf Huuck NICTA ATP building 2 Plan/Schedule (1) Where and When Tuesday,

More information

Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center

Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center May, 2009 Thomas Schultz Director of Product Strategy, Coverity, Inc. Executive Summary Development organizations that create

More information

Attaining EDF Task Scheduling with O(1) Time Complexity

Attaining EDF Task Scheduling with O(1) Time Complexity Attaining EDF Task Scheduling with O(1) Time Complexity Verber Domen University of Maribor, Faculty of Electrical Engineering and Computer Sciences, Maribor, Slovenia (e-mail: domen.verber@uni-mb.si) Abstract:

More information

SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-178B LEVEL A & B

SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-178B LEVEL A & B SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-78B LEVEL A & B TABLE OF CONTENTS. INTRODUCTION..... PURPOSE..... RELATED DOCUMENTS..... GLOSSARY... 9.. CONVENTIONS..... RELATION WITH OTHER PLANS....6. MODIFICATION

More information

System Modelingg Models of Computation and their Applications Axel Jantsch Laboratory for Electronics and Computer Systems (LECS) Royal Institute of Technology, Stockholm, Sweden February 4, 2005 System

More information

The C Programming Language course syllabus associate level

The C Programming Language course syllabus associate level TECHNOLOGIES The C Programming Language course syllabus associate level Course description The course fully covers the basics of programming in the C programming language and demonstrates fundamental programming

More information

SPAZIO IT. Spazio IT Open Source & AVIONICs. Open Source & Avionics. December 2014

SPAZIO IT. Spazio IT Open Source & AVIONICs. Open Source & Avionics. December 2014 Spazio IT Open Source & AVIONICs SPAZIO IT Open Source & Avionics Maurizio Martignano Spazio IT Soluzioni Informatiche s.a.s Via Manzoni 40 46030 San Giorgio di Mantova, Mantova http://www.spazioit.com

More information

Abstract Interpretation-based Static Analysis Tools:

Abstract Interpretation-based Static Analysis Tools: Abstract Interpretation-based Static Analysis Tools: Proving the Absence of Runtime Errors and Safe Upper Bounds on the Worst-Case Execution Time and Safe Upper Bounds on the Stack Usage Christian Ferdinand

More information

Formal verification of contracts for synchronous software components using NuSMV

Formal verification of contracts for synchronous software components using NuSMV Formal verification of contracts for synchronous software components using NuSMV Tobias Polzer Lehrstuhl für Informatik 8 Bachelorarbeit 13.05.2014 1 / 19 Problem description and goals Problem description

More information

Static Analysis. Find the Bug! 15-654: Analysis of Software Artifacts. Jonathan Aldrich. disable interrupts. ERROR: returning with interrupts disabled

Static Analysis. Find the Bug! 15-654: Analysis of Software Artifacts. Jonathan Aldrich. disable interrupts. ERROR: returning with interrupts disabled Static Analysis 15-654: Analysis of Software Artifacts Jonathan Aldrich 1 Find the Bug! Source: Engler et al., Checking System Rules Using System-Specific, Programmer-Written Compiler Extensions, OSDI

More information

Building Confidence in the Quality and Reliability of Critical Software

Building Confidence in the Quality and Reliability of Critical Software Building Confidence in the Quality and Reliability of Critical Software Jay Abraham, MathWorks Jon Friedman, MathWorks Abstract. Software in critical civilian and military aerospace applications, including

More information

ARIZONA CTE CAREER PREPARATION STANDARDS & MEASUREMENT CRITERIA SOFTWARE DEVELOPMENT, 15.1200.40

ARIZONA CTE CAREER PREPARATION STANDARDS & MEASUREMENT CRITERIA SOFTWARE DEVELOPMENT, 15.1200.40 SOFTWARE DEVELOPMENT, 15.1200.40 1.0 APPLY PROBLEM-SOLVING AND CRITICAL THINKING SKILLS TO INFORMATION TECHNOLOGY 1.1 Describe methods and considerations for prioritizing and scheduling software development

More information

Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification

Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification Introduction Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification Advanced Topics in Software Engineering 1 Concurrent Programs Characterized by

More information

Integrating System Safety and Software Assurance

Integrating System Safety and Software Assurance Integrating System Safety and Software Assurance Systems Certification and Integrity Directorate of Aviation Engineering Directorate General Technical Airworthiness 1 Overview Integration of software assurance

More information

Computer Programming. Course Details An Introduction to Computational Tools. Prof. Mauro Gaspari: mauro.gaspari@unibo.it

Computer Programming. Course Details An Introduction to Computational Tools. Prof. Mauro Gaspari: mauro.gaspari@unibo.it Computer Programming Course Details An Introduction to Computational Tools Prof. Mauro Gaspari: mauro.gaspari@unibo.it Road map for today The skills that we would like you to acquire: to think like a computer

More information

Methods and Tools For Embedded Distributed System Scheduling and Schedulability Analysis

Methods and Tools For Embedded Distributed System Scheduling and Schedulability Analysis Methods and Tools For Embedded Distributed System Scheduling and Schedulability Analysis Steve Vestal Honeywell Labs Steve.Vestal@Honeywell.com 18 October 2005 Outline Background Binding and Routing Scheduling

More information

Object Oriented Software Design

Object Oriented Software Design Object Oriented Software Design Introduction to Java - II Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa October 28, 2010 G. Lipari (Scuola Superiore Sant Anna) Introduction

More information

The programming language C. sws1 1

The programming language C. sws1 1 The programming language C sws1 1 The programming language C invented by Dennis Ritchie in early 1970s who used it to write the first Hello World program C was used to write UNIX Standardised as K&C (Kernighan

More information

State of the art Software Modeling. Tony Elliston. SIGADA 2004 Atlanta

State of the art Software Modeling. Tony Elliston. SIGADA 2004 Atlanta State of the art Software Modeling Tony Elliston SIGADA 2004 Atlanta TNI Europe Limited Market our own software modelling tools: CP-Hood and Stood. Distributor for TNI Software range of products. TNI Europe

More information

Operating Systems 4 th Class

Operating Systems 4 th Class Operating Systems 4 th Class Lecture 1 Operating Systems Operating systems are essential part of any computer system. Therefore, a course in operating systems is an essential part of any computer science

More information

A Quality Requirements Safety Model for Embedded and Real Time Software Product Quality

A Quality Requirements Safety Model for Embedded and Real Time Software Product Quality A Quality Requirements Safety Model for Embedded and Real Time Product Quality KHALID T. AL-SARAYREH Department of Engineering Hashemite University Zarqa 13115, Jordan khalidt@hu.edu.jo Abstract safety

More information

Introduction to Computers and Programming. Testing

Introduction to Computers and Programming. Testing Introduction to Computers and Programming Prof. I. K. Lundqvist Lecture 13 April 16 2004 Testing Goals of Testing Classification Test Coverage Test Technique Blackbox vs Whitebox Real bugs and software

More information

Real-Time Systems Prof. Dr. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur

Real-Time Systems Prof. Dr. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Real-Time Systems Prof. Dr. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture No. # 26 Real - Time POSIX. (Contd.) Ok Good morning, so let us get

More information

KITES TECHNOLOGY COURSE MODULE (C, C++, DS)

KITES TECHNOLOGY COURSE MODULE (C, C++, DS) KITES TECHNOLOGY 360 Degree Solution www.kitestechnology.com/academy.php info@kitestechnology.com technologykites@gmail.com Contact: - 8961334776 9433759247 9830639522.NET JAVA WEB DESIGN PHP SQL, PL/SQL

More information

Introduction to SPIN. Acknowledgments. Parts of the slides are based on an earlier lecture by Radu Iosif, Verimag. Ralf Huuck. Features PROMELA/SPIN

Introduction to SPIN. Acknowledgments. Parts of the slides are based on an earlier lecture by Radu Iosif, Verimag. Ralf Huuck. Features PROMELA/SPIN Acknowledgments Introduction to SPIN Parts of the slides are based on an earlier lecture by Radu Iosif, Verimag. Ralf Huuck Ralf Huuck COMP 4152 1 Ralf Huuck COMP 4152 2 PROMELA/SPIN PROMELA (PROcess MEta

More information

From Control Loops to Software

From Control Loops to Software CNRS-VERIMAG Grenoble, France October 2006 Executive Summary Embedded systems realization of control systems by computers Computers are the major medium for realizing controllers There is a gap between

More information

Object Oriented Software Design

Object Oriented Software Design Object Oriented Software Design Introduction to Java - II Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa September 14, 2011 G. Lipari (Scuola Superiore Sant Anna) Introduction

More information

System modeling. Budapest University of Technology and Economics Department of Measurement and Information Systems

System modeling. Budapest University of Technology and Economics Department of Measurement and Information Systems System modeling Business process modeling how to do it right Partially based on Process Anti-Patterns: How to Avoid the Common Traps of Business Process Modeling, J Koehler, J Vanhatalo, IBM Zürich, 2007.

More information

Static Analysis of Dynamic Properties - Automatic Program Verification to Prove the Absence of Dynamic Runtime Errors

Static Analysis of Dynamic Properties - Automatic Program Verification to Prove the Absence of Dynamic Runtime Errors Static Analysis of Dynamic Properties - Automatic Program Verification to Prove the Absence of Dynamic Runtime Errors Klaus Wissing PolySpace Technologies GmbH Argelsrieder Feld 22 82234 Wessling-Oberpfaffenhofen

More information

C++ Programming Language

C++ Programming Language C++ Programming Language Lecturer: Yuri Nefedov 7th and 8th semesters Lectures: 34 hours (7th semester); 32 hours (8th semester). Seminars: 34 hours (7th semester); 32 hours (8th semester). Course abstract

More information

MPLAB Harmony System Service Libraries Help

MPLAB Harmony System Service Libraries Help MPLAB Harmony System Service Libraries Help MPLAB Harmony Integrated Software Framework v1.08 All rights reserved. This section provides descriptions of the System Service libraries that are available

More information

Load balancing Static Load Balancing

Load balancing Static Load Balancing Chapter 7 Load Balancing and Termination Detection Load balancing used to distribute computations fairly across processors in order to obtain the highest possible execution speed. Termination detection

More information

Introduction to Formal Methods. Các Phương Pháp Hình Thức Cho Phát Triển Phần Mềm

Introduction to Formal Methods. Các Phương Pháp Hình Thức Cho Phát Triển Phần Mềm Introduction to Formal Methods Các Phương Pháp Hình Thức Cho Phát Triển Phần Mềm Outline Introduction Formal Specification Formal Verification Model Checking Theorem Proving Introduction Good papers to

More information

Software Engineering using Formal Methods

Software Engineering using Formal Methods Software Engineering using Formal Methods Model Checking with Temporal Logic Wolfgang Ahrendt 24th September 2013 SEFM: Model Checking with Temporal Logic /GU 130924 1 / 33 Model Checking with Spin model

More information

Boolean Expressions, Conditions, Loops, and Enumerations. Precedence Rules (from highest to lowest priority)

Boolean Expressions, Conditions, Loops, and Enumerations. Precedence Rules (from highest to lowest priority) Boolean Expressions, Conditions, Loops, and Enumerations Relational Operators == // true if two values are equivalent!= // true if two values are not equivalent < // true if left value is less than the

More information

ARIZONA CTE CAREER PREPARATION STANDARDS & MEASUREMENT CRITERIA SOFTWARE DEVELOPMENT, 15.1200.40

ARIZONA CTE CAREER PREPARATION STANDARDS & MEASUREMENT CRITERIA SOFTWARE DEVELOPMENT, 15.1200.40 SOFTWARE DEVELOPMENT, 15.1200.40 STANDARD 1.0 APPLY PROBLEM-SOLVING AND CRITICAL THINKING SKILLS TO INFORMATION 1.1 Describe methods of establishing priorities 1.2 Prepare a plan of work and schedule information

More information

In this lecture you will learn:

In this lecture you will learn: Data Types and Variables Imed Hammouda Department of Software Systems Tampere University of Technology Objectives In this lecture you will learn: What is a data type and how types are represented in C++.

More information

MULTIPLE CHOICE. Choose the one alternative that best completes the statement or answers the question.

MULTIPLE CHOICE. Choose the one alternative that best completes the statement or answers the question. Exam Name MULTIPLE CHOICE. Choose the one alternative that best completes the statement or answers the question. 1) The JDK command to compile a class in the file Test.java is A) java Test.java B) java

More information

PL/SQL Overview. Basic Structure and Syntax of PL/SQL

PL/SQL Overview. Basic Structure and Syntax of PL/SQL PL/SQL Overview PL/SQL is Procedural Language extension to SQL. It is loosely based on Ada (a variant of Pascal developed for the US Dept of Defense). PL/SQL was first released in ١٩٩٢ as an optional extension

More information

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References Outline Computer Science 331 Introduction to Testing of Programs Mike Jacobson Department of Computer Science University of Calgary Lecture #3-4 1 Denitions 2 3 4 Implementation and Evaluation 5 Debugging

More information

Object Oriented Software Design II

Object Oriented Software Design II Object Oriented Software Design II Introduction to C++ Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa February 20, 2012 G. Lipari (Scuola Superiore Sant Anna) C++ Intro February

More information

Automatic Test Data Generation for TTCN-3 using CTE

Automatic Test Data Generation for TTCN-3 using CTE Automatic Test Data Generation for TTCN-3 using CTE Zhen Ru Dai, Peter H. Deussen, Maik Busch, Laurette Pianta Lacmene, Titus Ngwangwen FraunhoferInstitute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee

More information

Using UML Part Two Behavioral Modeling Diagrams

Using UML Part Two Behavioral Modeling Diagrams UML Tutorials Using UML Part Two Behavioral Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,

More information

We will learn the Python programming language. Why? Because it is easy to learn and many people write programs in Python so we can share.

We will learn the Python programming language. Why? Because it is easy to learn and many people write programs in Python so we can share. LING115 Lecture Note Session #4 Python (1) 1. Introduction As we have seen in previous sessions, we can use Linux shell commands to do simple text processing. We now know, for example, how to count words.

More information

INF5140: Specification and Verification of Parallel Systems

INF5140: Specification and Verification of Parallel Systems INF5140: Specification and Verification of Parallel Systems Lecture 7 LTL into Automata and Introduction to Promela Gerardo Schneider Department of Informatics University of Oslo INF5140, Spring 2007 Gerardo

More information

Simulation & Synthesis Using VHDL

Simulation & Synthesis Using VHDL Floating Point Multipliers: Simulation & Synthesis Using VHDL By: Raj Kumar Singh - B.E. (Hons.) Electrical & Electronics Shivananda Reddy - B.E. (Hons.) Electrical & Electronics BITS, PILANI Outline Introduction

More information

Unified Static and Runtime Verification of Object-Oriented Software

Unified Static and Runtime Verification of Object-Oriented Software Unified Static and Runtime Verification of Object-Oriented Software Wolfgang Ahrendt 1, Mauricio Chimento 1, Gerardo Schneider 2, Gordon J. Pace 3 1 Chalmers University of Technology, Gothenburg, Sweden

More information

Introduction to Software Paradigms & Procedural Programming Paradigm

Introduction to Software Paradigms & Procedural Programming Paradigm Introduction & Procedural Programming Sample Courseware Introduction to Software Paradigms & Procedural Programming Paradigm This Lesson introduces main terminology to be used in the whole course. Thus,

More information

Software Testing. Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program.

Software Testing. Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program. Software Testing Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program. Testing can only reveal the presence of errors and not the

More information

Flip-Flops, Registers, Counters, and a Simple Processor

Flip-Flops, Registers, Counters, and a Simple Processor June 8, 22 5:56 vra235_ch7 Sheet number Page number 349 black chapter 7 Flip-Flops, Registers, Counters, and a Simple Processor 7. Ng f3, h7 h6 349 June 8, 22 5:56 vra235_ch7 Sheet number 2 Page number

More information

Embedded Software Development with MPS

Embedded Software Development with MPS Embedded Software Development with MPS Markus Voelter independent/itemis The Limitations of C and Modeling Tools Embedded software is usually implemented in C. The language is relatively close to the hardware,

More information

Crash Course in Java

Crash Course in Java Crash Course in Java Based on notes from D. Hollinger Based in part on notes from J.J. Johns also: Java in a Nutshell Java Network Programming and Distributed Computing Netprog 2002 Java Intro 1 What is

More information

Pemrograman Dasar. Basic Elements Of Java

Pemrograman Dasar. Basic Elements Of Java Pemrograman Dasar Basic Elements Of Java Compiling and Running a Java Application 2 Portable Java Application 3 Java Platform Platform: hardware or software environment in which a program runs. Oracle

More information

Sequence Diagrams. Massimo Felici. Massimo Felici Sequence Diagrams c 2004 2011

Sequence Diagrams. Massimo Felici. Massimo Felici Sequence Diagrams c 2004 2011 Sequence Diagrams Massimo Felici What are Sequence Diagrams? Sequence Diagrams are interaction diagrams that detail how operations are carried out Interaction diagrams model important runtime interactions

More information

Jorix kernel: real-time scheduling

Jorix kernel: real-time scheduling Jorix kernel: real-time scheduling Joris Huizer Kwie Min Wong May 16, 2007 1 Introduction As a specialized part of the kernel, we implemented two real-time scheduling algorithms: RM (rate monotonic) and

More information

Context-Bounded Model Checking of LTL Properties for ANSI-C Software. Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole

Context-Bounded Model Checking of LTL Properties for ANSI-C Software. Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole Context-Bounded Model Checking of LTL Properties for ANSI-C Software Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole Model Checking C Model checking: normally applied to formal state transition

More information

INF5140: Specification and Verification of Parallel Systems

INF5140: Specification and Verification of Parallel Systems Motivation INF5140: Specification and Verification of Parallel Systems Lecture 1 Introduction: Formal Methods Gerardo Schneider Department of Informatics University of Oslo INF5140, Spring 2009 Outline

More information

Computer Programming I

Computer Programming I Computer Programming I COP 2210 Syllabus Spring Semester 2012 Instructor: Greg Shaw Office: ECS 313 (Engineering and Computer Science Bldg) Office Hours: Tuesday: 2:50 4:50, 7:45 8:30 Thursday: 2:50 4:50,

More information

Topics. Introduction. Java History CS 146. Introduction to Programming and Algorithms Module 1. Module Objectives

Topics. Introduction. Java History CS 146. Introduction to Programming and Algorithms Module 1. Module Objectives Introduction to Programming and Algorithms Module 1 CS 146 Sam Houston State University Dr. Tim McGuire Module Objectives To understand: the necessity of programming, differences between hardware and software,

More information