Download presentation

Presentation is loading. Please wait.

Published byBryana Churches Modified over 2 years ago

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

2
2 The course is about development of real-time systems by formal methods Reactive (real-time) computation Environment < d Interaction with the environment Non-terminating computation < d

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

4
4 מידע כללי 1.שעות הקורס : – == הפסקה אחת באמצע. 2.אתר הקורס : 3. תרגילים במשך הסמסטר : כ 6, חובת הגשה, ללא ציון וללא החזרה, פתרונות יוצגו באתר / יסקרו בכיתה, לפי הצורך. 4.החומר התיאורטי של הקורס מצוי במאמרים ( ימצאו באתר ). 5.הקורס יכלול עבודת תכנות מצומצמת בשפות דרישות ותכנון. 6.סיום קורס – עבודת - בית, משקלה בציון הכללי 70%; בחינה, משקלה בציון הכללי 30%. 7.כל המושגים יוגדרו, מניסיון עבר ללא רקע בלוגיקה ואוטומטים, די קשה. 8. שאלות בשיעור, לפעמים אדחה תשובות משיקולי עכוב/תועלת. 9.בכל מקרה, שאלות שוטפות: מקודמות

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

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

7
7 RTS: Distributed/Synchronous Systems

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

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

10
10 after 5 sec. 25 temp 30 Controller: Control of Process Properties light initially green, and after each req - within 1sec – becomes red for 3 sec. A control assertion of a property P is C P P that satisfies: - State constraints, e.g., { f P | t` t t``. m f(t) M } C P - Temporal constraints, e.g., {f P | t. v(t)=5 t. t

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

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

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

14
14 Development Process

15
15 Conventional Development Practice Ideas code requirements testing design

16
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.a XR is empty for more than 10 sec. 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. Requirements: Design:

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

18
18 Present applications of RTS are huge and intricate, thus become difficult to understand and test; on the other hand, they are safety critical. Why Another Process ? 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
19 ESA Ariane 5 Flight 501 self-destruction 40 sec. after takeoff.Ariane 5 –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. Some Famous failures (I)

20
20 The 2003 North America blackout was triggered by a local outage that went undetetected.2003 North America blackout A race condition in General Electrics 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).MIM-104 Patriot 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 bugPentium bug Incorrect floating-point division, cost Intel ~ $400M Some Famous failures (II)

21
21

22
22 Testing becomes the bottleneck of development

23
23

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

25
The Formal Development Framework

26
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.a XR is empty for more than 10 sec. 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. Requirements: 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
27 About Assumptions and Requirements Specified w.r.t. system interface Component Assumption Requirement Given behaviors of the env, the system does nothing to produce them, and cannot refuse them. Behaviors the system is responsible to produce

28
28 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.. Contract GateFunctionality is Assume: - No train enters XR while another train is still inside. Promise: - Gate open whenever XR is empty for more than 10 sec. This assumption should be guaranteed by another contract Contracts: Formal Specification Format

29
29 Consistency Verification Mathematical proof - rather than testing. Consistency - Assumptions & requirements are consistent, -assumptions - requirements ? Assumptions Requiremen ts Yes: inconsistent No: consistent

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

31
31 Combining Assertions (II) Usually an assertion restricts only part of the variables behaviors A-1: always x>0 Assertions combined by conjunction, asserting A-1 and A-2 yields C behaviors: A-1 A-2 C x: integer y: integer act: bool x All behaviors s.t. t.x(t)>0 actAll possible behaviors y A-2: When act is true x=-5 xAll behaviors s.t. t.(act(t) x(t)=-5) actAll possible behaviors y xAll behaviors s.t. t.(x(t)>0 (act(t) x(t)=-5) actAll possible behaviors ? t. act(t) ??? yAll possible behaviors

32
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 }

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

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

35
35 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). Thinking formal !!!

36
36 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). Thinking formal !!!

37
37 Motivation around 1960: Decision problems in logic and circuit design : 1960 – 1969: – Proof of the core results by: J. Richard Buchi ( ) 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 Systems 2002/03 Historical Sketch*

38
38 Course Plan

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google