1

Real-Time Systems Developmentby the

Formal Approach  

- course notes - 

Dr. Vered Gafni

1

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’< d

1

Requirements

Program

Abstract (formal) specification of a set of allowed computations(by Temporal Logic)

Executable (formal) specification

of a set of computations1by -automata1

The course is about development of

real-time systems

by formal methods

1

מידע כללי

== הפסקה אחת באמצע.18.30 – 16.00שעות הקורס: 1.

www.cs.tau.ac.il/~gafniאתר הקורס: 2.

, חובת הגשה, 6 תרגילים במשך הסמסטר: כ 3.בכיתהיסקרובאתריוצגופתרונותהחזרהוללאציוןללאלפיהצורך

החומר התיאורטי של הקורס מצוי במאמרים )ימצאו באתר(.4.

הקורס יכלול עבודת תכנות מצומצמת בשפות דרישות ותכנון.5.

, משקלה בחינה; 70%, משקלה בציון הכללי עבודת-בית– סיום קורס 6..30%בציון הכללי

, די אוטומטים ולוגיקהכל המושגים יוגדרו, מניסיון עבר ללא רקע ב7.קשה.

שאלות בשיעור, לפעמים אדחה תשובות משיקולי עכוב/תועלת.8.

מקודמות gafni@post.tau.ac.ilבכל מקרה, שאלות שוטפות: 9.בברכה.

1

Real-Time Systems

Control of a physical process implemented by a digital computer

1

Several viewpoints:-functionality,-Performance,…

Nowadays embedded systemsComposed of multi, concurrent, subsystems

involve several disciplines (e.g., aerodynamics, mechanical, control)

Large Scale

Reliability is critical

Example: Fly by Wire

1

RTS: Distributed/Synchronous Systems

1

Return to the basic model…

4 concurrent interacting processes:

How to describe their operation

)computations( along time ?

Command Environment

Controller

Controlled Process

Physical Environment

Behavior: Time Physical Domain

Property: { Behaviors }

time

temp'

behaviors

-10

50

Lights = { Time ColorReq }

Color: {red, green},

Rqst: event

RoomTemp = { Time [-10, 50] }

Controlled process & Physical environment

Time = R0

Controlled system:

a set of properties {P1,…,Pn}

1

“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 CPP that satisfies:

- State constraints, e.g., { fP | t`tt``. mf)t(M }CP

- Temporal constraints, e.g., {fP | t. v)t(=5 t’. t<t’t+3 f)t’(=9}CP

11

Digital Controller

Controller

Transfer Function

compare

Controlled Process

sensor actuator

correction

state

command error

Discrete time

Continuous time

Non-zero time

On going reaction to unpredictable process & command behavior

Real-time reaction )within hard deadlines(

Multiple async. processes

11

Digital Controller: multi-process, multi-stage

correction

state

cmd errcmd

state

cmd

state

cmd errcmd errcmd err

correction

errerr

11

deadline

event reaction

Separation of Concerns

• Reactive – conditions, events, durations, responses,

• Functional - computations

This course:

Specification, Design &Verification

of the controller reactive behavior

The Controller Behavior

11

Development Process

11

Conventional Development Practice

Ideas

code

requirements

testing

design

11

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:

11

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

testingdesign

Program your understanding of the design

11

• 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.

1

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.

Some Famous failures (I)

1

• 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

Some Famous failures (II)

11

11

• Testing becomes the bottleneck of development

11

11

Formal Development Process

What’s new ?

• Specification & Design are expressed in formal languages.

• Assumptions & Requirements

• Formal consistency check

• Formal verification

The Formal Development Framework

Formal development

Implementation

Interface

Program

Specification

Requirements Assumptions

Verification

Consistency

Ass. ÇImp. Req.

Temporal logic

Automata

11

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.

11

About Assumptions and Requirements

Specified w.r.t. system interface

Component

AssumptionRequirement

Given behaviors of the env’, thesystem does nothing to producethem, and cannot refuse them.

Behaviors the system is responsible to produce

11

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

1

Consistency Verification

Mathematical proof - rather than testing.Consistency - Assumptions & requirements are consistent,

-assumptions

- requirements

Ç ?

Assumptions

Requirements

Yes: inconsistent

No: consistent

1

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

Cx: integer

y: integeract: bool

xAll behaviors s.t. t.x)t(>0

actAll possible behaviors

yAll possible behaviors

A-2: act is never true cont. more than 3 sec.

xAll possible behaviors

actAll behaviors s.t.

t1,t2. )t. )t1tt2( act)t((

)t2-t1( 3sec

yAll possible behaviors

xAll behaviors s.t. t.x)t(>0

actAll behaviors s.t.

t1,t2. )t. )t1tt2( act)t((

)t2-t1( 3sec

yAll possible behaviors

11

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

Cx: integer

y: integeract: bool

xAll behaviors s.t. t.x)t(>0

actAll possible behaviors

yAll possible behaviors

A-2: When act is true x=-5

xAll behaviors s.t.

t.)act)t( x)t(=-5(

actAll possible behaviors

yAll possible behaviors

xAll behaviors s.t.

t.)x)t(>0 )act)t( x)t(=-5(

actAll possible behaviors ?

t. act)t( ???

yAll possible behaviors

11

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

11

Verification

• It is proved )rather than tested( that:Assumptions & requirements are consistent,

Assuming the assumptions, the design satisfies requirements.

Assumptions

Requirements

Design

Model checking - A )mathematical( proof :

Assumption Ç Design Requirements

Hence correct classification

Is critical (otherwise wrong

analysis results)

11

Model Checking

Model checking - Assumption Ç Design Requirements

Classification Is criticalMathematical proof - rather than testing. Program verification

- Assuming the assumptions, the design satisfies requirements.

-assumptions

- programÇ

Assumptions

Program Yes: Correct

No: incorrect

+counter example

- requirements

Requirements

11

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ÇDR(.

Thinking formal

11

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ÇDR(.

Thinking formal

11

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 Systems 2002/03

Historical Sketch

11

Course Plan

Semantic Model

SystemOntology

SystemDesign

Formal SystemSpecification(properties)

Formal verification

NL Specification

ConsistencyCheck