Verification of Real Time Systems

1
Verification of Real Time Systems

• CS 5270 Lecture 1
• Hugh Anderson
• (Helped by P.S. Thiagarajan)

2
Basic Info

• Hugh Anderson
• S15 06-12 Tel Ext. 6903
• hugh_at_comp.nus.edu.sg
• www.comp.nus.edu.sg/hugh
• Course web page
• www.comp.nus.edu.sg/cs5270
• We will be using the IVLE system once I set it
  up.

3
Office Hours

• Anytime I have an open-door policy.
• Oh also - a buy me coffee policy ?
• (Actually lets call that a join me for coffee
  policy)
• Or use email and fix an appointment.

4
Grading (Tentative)

• Assignments    20
• Projects              20
• Mid-Term       10
• Final                50

5
Course Material

• My notes and slides
• Selected Parts of
• Hard Real-Time Computing Systems Predictable
  Scheduling Algorithms and Applications Giorgio
  C. Buttazzo
• Real-Time Systems Design Principles for
  Distributed Embedded Applications Hermann Kopetz
• Real-Time Systems Scheduling, Analysis and
  Verification Albert M.K. Cheng
• Concepts, Algorithms and Tools for Model
  Checking Lecture notes by Joost-Peter Katoen
• Research Articles.

6
Assignments still not fixed

• Take-home assignments
• 2 (?)
• Lab Assignments
• 2 (?)
• UPPAAL tool based so have a look at Uppaal at
  http//www.uppaal.com/.
• Individual

7
Motivation do we need any?

• Ubiquity of processors, Ariane-5
• Software versus hardware
• Abstraction and software engineering

8
What is the Course About?

• Real Time Computing Systems.
• Key features and issues
• Modeling, analysis
• Verification

9
Broad Outline

• Introduction to Real Time Systems
• Timed Automata
• Verification Tools and Techniques.
• Time-triggered architectures and protocols.

10
What are Real Time Computer Systems?

• Real Time Computer System
• Correct functioning depends on
• the values of the results produced.
• AND
• the physical times at which the results are
  produced.
• Real Time Computer System is embedded in a
  larger physical system.

11
What are real time systems?

• The state of the system evolves with time.
• Position, velocity, acceleration
• Pressure, temperature, level, concentration
• The state needs to be sensed and controlled by
  the computer system.

12
Control Function
13
Real time

• System time and external physical time are the
  same!
• At least must have a predictable relationship.

14
Computational Timing Constraints

• The computing system must sense, compute and
  actuate in a timely fashion.
• Many sensors and many actuators.
• Many control functions!
• Must schedule computational tasks for different
  control functions in a timely fashion.
• Computations must finish on time.
• Performance

15
Types of Real Time Systems

• Hard / Soft
• Hard
• Must meet timing constraints always.
• Reactor control, automotive electronics
• Soft
• Must meet timing constraints often.
• Transaction Processing system
• Multi-media streaming applications.
• Hard/Soft determined externally.
• Our focus will be on Hard Real Time Systems.

16
Characteristics of Hard Real Time Computing
Systems.

• Timeliness
• Peak Load Handling
• The system should not fail at peak load
  conditions
• Predictability
• Fault Tolerance
• Maintainability

17
Impact on System Architecture

• Must avoid non-determinism (why?).
• Sources of non-determinism
• Direct Memory Access (DMA) by peripheral devices.
• Contention for system bus.
• Cache
• Interrupts generated by I/O devices.
• Memory Management (paging)
• Dynamic data structures, recursion, unbounded
  loops (language level).

18
Applications

• Chemical and Nuclear Plant Control
• Railway Switching Systems
• Automotive applications
• Flight control
• ..

19
Current State

• Ad hoc techniques, heuristic approaches.
• Code written in assembly language
• Programmed timers
• Low level device handling
• Direct manipulation of task and interrupt
  priorities.
• Goal Optimized predictable execution on simple
  architectures.

20
Drawbacks

• Tedious programming
• Code quality depends on the programmer
• Difficult to understand and maintain.
• Verification of timing constraints is practically
  impossible.
• System could collapse in rare, unforeseen
  circumstances, leading to disasters.

21
Laws of Real Time Systems Buttazzos Book

• If something can go wrong, it will go wrong.
  (Murphys law)

22
Laws of Real Time Systems

• If something can go wrong, it will go wrong.
  (Murphys law)
• Any software bug will tend to maximize damage.

23
Laws of Real Time Systems

• If something can go wrong, it will go wrong.
  (Murphys law)
• Any software bug will tend to maximize damage.
• The worst software bug will be discovered 6
  months after the field test.

24
Laws of Real Time Systems

• If something can go wrong, it will go wrong.
  (Murphys law)
• Any software bug will tend to maximize damage.
• The worst software bug will be discovered 6
  months after the field test.
• A system will stop working at the worst possible
  time.

25
Laws of Real Time Systems

• If something can go wrong, it will go wrong.
  (Murphys law)
• Any software bug will tend to maximize damage.
• The worst software bug will be discovered 6
  months after the field test.
• A system will stop working at the worst possible
  time.
• Sooner or later the worst possible combinations
  of circumstances will occur.

26
Formal Methods (Myths?!)

• Common in hardware design buildings, bridges,
  VHDL chip design and so on.
• It is a common misconception that FM is hard to
  use and slows things down. Most studies show the
  reverse is true.
• Design phase slower, implementation and
  integration faster Overall FASTER.
• CICS, banking, by wire systems.

27
FM for real time systems

• Model real time systems precisely,
  mathematically, formally
• External events
• System events
• Verify timing properties
• Propagate timing constraints down to the system
  level.
• Verify implementation meets the specification at
  each level.

28
Assurance Modelling
29
Assurance Synthesis
30
What methods can we offer?

• Transition systems accepting states automata
• Timed automata
• To capture high level descriptions.
• Verification tools and methods
• Time triggered architectures.
• A mix of these two paradigms.

31
State Transition Systems

• TS is the 4-tuple (S, Act, ?, Sin)
• S --- A set of States
• Act --- A set of actions
• ? ? S ? Act ? S ---- Transition Relation
• Sin ? S ---- Initial states
• TS have graph view, and often
• S and Act are finite sets.
• Sin has only one element.
• The transition relation is deterministic.

32
Finite State Automata

• Finite State Automata (FSAs) are a basic
  computational model.
• FSAs Regular Languages
• Temporal Logics.
• Starting point for many system design
• methodologies.
• SDL, UML, POLIS,
• Verification tools (SPIN, SMV) available.

33
A Railway System
34
The Gate/Train TS graph view
open
approach
left
Fin-Close
proceed
close
brake
proceed
Gate
Train
35
The Gate Controller TS
approach
open
left
close
Fin-Close
proceed
36
The Signal Space
open
Gate
Fin-close
close
open
Fin-Close
Gate Controller
approach
close
proceed
left
37
Transition system

• To model the entire system, construct the
  parallel composition
• Gate Train Controller
• (This is another TS)

38
Parallel composition
39
Timing Considerations

• The untimed description is not enough!
• From the time approach is sent, proceed must
  be received within 5 time units.
• From the time close is sent, fin-close must
  be received within 3 time units.
• From the time close is received it takes at
  least 2 time units before fin-close is sent out.

40
Timed Automata

• Automata clock variables.
• Model finite state (control) systems with timing
  constraints.
• Rich theory (too rich?).
• Practical tools.
• Emerging applications.
• Lot more needs to be done for applications.

41
The Basic Idea
proceed
Approach
42
The Basic Idea
proceed
Approach x
x 5
From the time approach was sent proceed must
be received within 5 time units.
43
The Basic Idea
f

• act is an action (or event, or signal).
• Y is a set of clock variables being reset to 0.
• f is a clock constraint.
• f x c x c x lt c x gt c f1 ? f2
• c is a rational number (integer OK for model)

44
The Gate/Train Automata
open
Fin-Close
2 x 4
close x
repair
x gt 4
Gate
45
The Gate/Train Automata
left
Approach y
proceed
brake
y lt 5
y 5
proceed
Train
46
Time-Triggered Architectures

• A method for organizing real-time computing
  systems.
• Main Application domain
• Automotive electronics.
• But also used in AIRBUS 380,
• See http//www.tttech.com/technology/articles.htm
  
• FlexRay is a closely related industry standard
• BMW, Daimler-Benz, Philips Semiconductor, Bosch,

47
The Main Idea

• Event-triggered
• Timed automata
• CAN (Controller Area Network)
• Meeting of 3 people
• Everyone speaks whenever he/she has something to
  say.
• Must wait for the currently speaker to finish
  before a new speaker can start.
• Imagine a meeting of 40 people!

48
The Main Idea

• Time-triggered
• Every speaker is assigned a predetermined time
  slot.
• After one round, the speaker gets a slot again.
• Also, a topic-schedule has been worked out in
  advance.
• Top1, Top2, Top4 in the first round.
• Top1, Top3 and Top5 in the second round
• Top2, Top4 and Top5 in the third round.
• Ensure no one breaks the rules!

49
Time-Triggered Architecture
50
Time-Triggered Architecture

• Basic unit NODE
• Node
• A processor with memory
• I-O subsystem
• Operating system
• Application software
• Time-triggered communication
• controller

51
Time-Triggered Architecture

• Communication (TTA Protocol)
• Nodes connect to each other via two independent
  channels.
• The communication subsystem executes a periodic
  Time Division Multiple Access (TDMA) schedule.
• Read a data frame state information from CNI
  (Communication Node Interface) at predetermined
  fetch instant and deliver to the CNIs of all
  receiving nodes at predetermined delivery
  instants.

52
Time-Triggered Architecture

• Communication
• All the TTPs in a cluster know this schedule.
• All nodes of a cluster have the same notion of
  global time.
• fault-tolerant clock synchronization.
• TTA BUS topolgy.

53
Next week

• Hard real time architectures
• Clocks, timing, and synchronization