Verification of Real Time Systems - PowerPoint PPT Presentation

About This Presentation
Title:

Verification of Real Time Systems

Description:

Verification of Real Time Systems CS 5270 Lecture 1 Hugh Anderson (Helped by P.S. Thiagarajan) Basic Info Hugh Anderson S15 #06-12 ; Tel Ext. 6903 hugh_at_comp.nus.edu ... – PowerPoint PPT presentation

Number of Views:208
Avg rating:3.0/5.0
Slides: 54
Provided by: dcs2
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com