Real-Time Systems Development by the Formal Approach - course notes -

1. Real-Time Systems Development by the Formal Approach - course notes - Dr. Vered Gafni

2. The course is about development ofreal-time systemsby formal methods Interaction with the environment Reactive (real-time) computation Environment < d’’ < d < d’ Non-terminating computation

3. The course is about development of real-time systems by formal methods Abstract (formal) specification of a set of allowed computations (by Temporal Logic) Requirements Program Executable (formal) specification of a set of computations (by -automata)

4. שעות הקורס: 16.00 – 18.30 == הפסקה אחת באמצע. • אתר הקורס: www.cs.tau.ac.il/~gafni • תרגילים במשך הסמסטר: כ 6, חובת הגשה, ללא ציון וללא החזרה, פתרונות יוצגו באתר/יסקרו בכיתה, לפי הצורך. • החומר התיאורטי של הקורס מצוי במאמרים (ימצאו באתר). • הקורס יכלול עבודת תכנות מצומצמת בשפות דרישות ותכנון. • סיום קורס – עבודת-בית, משקלה בציון הכללי 70%; בחינה, משקלה בציון הכללי 30%. • כל המושגים יוגדרו, מניסיון עבר ללא רקע בלוגיקה ואוטומטים, די קשה. • שאלות בשיעור, לפעמים אדחה תשובות משיקולי עכוב/תועלת. • בכל מקרה, שאלות שוטפות: gafni@post.tau.ac.il מקודמות בברכה. מידע כללי

5. Real-Time Systems Control of a physical process implemented by a digital computer

6. Nowadays embedded systems Large Scale Composed of multi, concurrent, subsystems • Several viewpoints: • functionality, • Performance,… involve several disciplines (e.g., aerodynamics, mechanical, control) Reliability is critical Example: Fly by Wire

7. RTS: Distributed/Synchronous Systems

8. Return to the basic model… 4 concurrent interacting processes: How to describe their operation (computations) along time ?

9. Controlled process & Physical environment Controlled system: a set of properties {P1,…,Pn} Behavior: Time  Physical Domain Property: {Behaviors } RoomTemp = { Time [-10, 50] } Time = R0 Lights = { Time  ColorReq } Color: {red, green}, Rqst: event

10. Controller: Control of Process Properties A controlassertion of a property P is CPP that satisfies: - State constraints, e.g., { fP | t`tt``. mf(t)M }CP - Temporal constraints, e.g.,{fP | t. v(t)=5  t’. t<t’t+3  f(t’)=9}CP “after 5 sec. 25  temp 30” “light initially green, and after each ‘req’ - within 1sec – becomes red for 3 sec.”

11. Digital Controller On going reaction to unpredictable process & command behavior Real-time reaction (within hard deadlines) Multiple async. processes

12. Digital Controller: multi-process, multi-stage

13. The Controller Behavior • Separation of Concerns • Reactive – conditions, events, durations, responses, • Functional - computations This course: Specification, Design &Verification of the controller reactivebehavior

14. Development Process

15. Ideas requirements design testing code Conventional Development Practice

16. Example: Railroad crossing • Gate closed as long as a train is in XR. • No more than one train in XR at a time. • - Trains not stopped for more than 12 sec. • - Gate open a.l.aXR is emptyfor morethan 10 sec. Requirements: • At startup, open the gate. • Upon train entrance, close the gate. • When the gate becomes closed turn the signal “pass”. • Upon train exit, open the gate. Design:

17. Testing • Show that the code satisfies systemrequirements. • Generate and run simulation scenarios. • Upon detection of incorrect controller • behavior, • - look for the cause. • - correct – requirements or design – • and run again. Ideas requirements design testing Program your understanding of the design code

18. Why Another Process ? • Present applications of RTS are huge and intricate, thus • become difficult to understand and test; on the other hand, • they are safety critical. • Requirements and design • are expressed in free text • (or pseudo-formal text). •  misunderstanding, • ambiguity, inconsistency. •  Testing and debugging are • empirical, provide partial • coverage, and rely on • mental activities. • low confidance, • time consuming.

19. Some Famous failures (I) ESA Ariane 5 Flight 501 self-destruction 40 sec. after takeoff. • A conversion from 64-bit floating point to 16 bit integer with a value larger than possible with Arian 4. The overflow caused a hardware trap.

20. Some Famous failures (II) • The 2003 North America blackout was triggered by a local outage that went undetetected. • A race condition in General Electric’s monitoring software prevented an alarm. • The MIM-104 Patriot bug, which resulted in the deaths of 28 Americans in Dharan, Saudi Arabia (February 25, 1991). • The radar classifies detections according to a trajectory model it builds in real time. (“in t mils the missile should be in position x”) • Due to rounding of the clock values, it accumulates inaccuracies. After several hours this inaccuracy is critical. • The Pentium bug • Incorrect floating-point division, cost Intel ~ $400M

22. Testing becomes the bottleneck of development

24. Formal Development Process • What’s new ? • Specification & Design are • expressed in formal languages. • Assumptions & Requirements • Formal consistency • check • Formal verification

25. The Formal Development Framework

26. Railroad crossing assumptions • Gate closed as long as a train is in XR. • No more than one train in XR at a time. • - Trains not stopped for more than 12 sec. • - Gate open a.l.aXR is emptyfor morethan 10 sec. Requirements: • Design: • At startup, open the gate. • Upon train entrance, close the gate. • When the gate becomes closed • turn the signal “pass”. • Upon train exit, open • the gate. • In order to design the program we need know environment behaviors such as: • Min. delay between successive trains. • The time it takes a train to cross • Gate close/open duration • ….. • These are the assumptions.

27. About Assumptions and Requirements Requirement Assumption Component Specified w.r.t. system interface Given behaviors of the env’, the system does nothing to produce them, and cannot refuse them. Behaviors the system is responsible to produce

28. Contracts: Formal Specification Format Contract GateSaftey is Assume: - At startup no train is already in XR - Gate changes its position only in response to controller commands - Trains obey semaphore commands Promise: - Gate closed as long as a train is in XR. . This assumption should be guaranteed by another contract Contract GateFunctionality is Assume: - No train enters XR while another train is still inside. Promise: - Gate open whenever XR isemptyfor morethan 10 sec.

29. Consistency Verification Yes: inconsistent Requirements  - requirements    ? Assumptions  -assumptions No: consistent • Mathematical proof - rather than testing. • Consistency - Assumptions & requirementsare consistent,

30. Combining Assertions (I) x: integer y: integer C • Usually an assertion restricts only part of the variables’ behaviors act: bool A-1: always x>0 • Assertions combined by conjunction, asserting • A-1 and A-2 yields C behaviors: A-1  A-2 A-2: act is never true cont. more than 3 sec.

31. Combining Assertions (II) x: integer y: integer C • Usually an assertion restricts only part of the variables’ behaviors act: bool A-1: always x>0 • Assertions combined by conjunction, asserting • A-1 and A-2 yields C behaviors: A-1  A-2 A-2: When act is true x=-5

32. Formal Verification after 5 sec. 25  temp 30 Controller • Requirements specification: • ‘after 5 sec. 25  temp 30’  {   ‘after 5 sec. 25  temp 30’ } • Controller program: • P[‘after 5 sec. 25  temp 30’]  {    is a run of P } • Verification: • prove that: {    is a run of P }  {   ‘after 5 sec. 25  temp 30’ } 32

33. Verification Requirements Assumptions Design • It is proved (rather than tested) that: • Assumptions & requirementsare consistent, • Assuming the assumptions, the design satisfies requirements. Model checking - A (mathematical) proof: Assumption  Design  Requirements Hence correct classification Is critical (otherwise wrong analysis results)

34. Model Checking Program Yes: Correct  - program  Assumptions No: incorrect + counter example  -assumptions  Requirements  - requirements • Mathematical proof - rather than testing. • Program verification • - Assuming the assumptions, the design satisfies requirements. Classification Is critical Model checking - Assumption  Design  Requirements 34

35. Thinking formal !!! • System (S) - A (infinite) set of behaviors. • Property (P) - A (infinite) subset of S • Assumptions (A), Requirements (R) - Finite sets of properties. • Design (D) - A (infinite) subset of S • Verification - A (mathematical) proof that the design behaviors that respect the assumptions are included in the promises • (ADR).

36. Thinking formal !!! • System (S) - A (infinite) set of behaviors. • Property (P) - A (infinite) subset of S • Assumptions (A), Requirements (R) - Finite sets of properties. • Design (D) - A (infinite) subset of S • Verification - A (mathematical) proof that the design behaviors that respect the assumptions are included in the promises • (ADR).

37. Historical Sketch* Motivation around 1960: • Decision problems in logic and circuit design : • 1960 – 1969: • Proof of the core results by: J. Richard Buchi (1924 -1984) Boris A. Trakhtenbrot Robert McNaughton Michael O. Rabin • Amir Pnueli proposes modal logic as reactive systems formalism • from around 1980: • Revival of the theory and development of automated model-checking • David Harel proposes State-charts as a synchronous design formalism • in the nineties: • Model-checking in industrial use, • Development of infinite games as a methodology • 2000 – • Compositional verification • BMC, SAT,… • Hybrid systems *after W. Thomas, lectures on Automata and Reactive Systems2002/03

38. Course Plan