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.
מקודמות [email protected]בכל מקרה, שאלות שוטפות: 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