Transcript Zones From infinte to finite

Konstruktion, modellering og validering
af
sikkerhedskritiske SW systemer
Henrik Schiøler
Why CISS ?
 Increasing demands in
electronic equipments for
user friendliness,
flexibility,
small size and weight
low power consumption
connectivity everywhere at
all times
drive the needs for higher
levels of
software realization !
2
Why CISS ?
 This applies not least to
portable systems with
wireless
communication
facilities
as well as medical
equipments.
3
Why CISS ?
 Application areas
mobile and wireless
communication products
automotive and avionic
systems
consumer electronics (e.g.
audio and video)
medico-technical
equipment
Building automation
smart devices
toys and games
textiles
4
Who is CISS ?
ICT Companies
Institute of
Computer Science
BRICS@Aalborg
Modelling and Validation;
Programming Languages;
Software Engineering
UCb
Institute of
Electronic Systems
Distributed
Real Time Systems
Control Theory;
Real Time Systems;
Networking.
5
Embedded Systems
Communication;
HW/SW
Power Management
Typical Activities
 Co-financed R&D projects and
case-studies
 Industrial training and
education
 Seminars, workshops and
networks of knowledge
transfer and exchange
 Ph.D. and industrial Ph.D.
projects
 Visiting Guest researchers
 Student projects
6
Technology
Theory and
Methodology
Applications, Solutions, Benefits
Innovation, Ideas, Pervation
7
Topics
8
Clusters
Model Based Development of Embedded Software
Intelligent Sensor Networks
Embedded & RT Platform LAB
Safety Critical Software Systems
Embedded System Validation & Testing
HW/SW Co-Design, Design Space Exploration
9
Clusters
Model Based Development of Embedded Software
Intelligent Sensor Networks
Embedded & RT Platform LAB
Safety
Safety Critical
Critical Software
Software Systems
Systems
Embedded System Validation & Testing
HW/SW Co-Design, Design Space Exploration
10
SW Development
of
Info-tech. Systems
Functional demands
Info-tech. system
• Development
cost/resources
• Time to market
11
Embedded systems
Functional demands
Performance demands
• Timeliness
• Reliability
Embedded Info-tech.
system
Technological resource bounds
• CPU speed
• Development
cost/resources
• Time to market
• Memory
• Power
• Comm. bandwidth
12
Functional Safety
13
Safety Integrity Levels (SIL)
14
Safety Lifecycle
15
Realization
16
SW Safety Lifecycle
17
SW Design and Development
18
Safety Integrity
19
SW Safety Integrity
20
Requirement Specification
21
SW Architectural Design
22
Detailled Design
23
Language and tools
24
Module and IntegrationTesting
25
Integration and Validation
26
Performance modelling
27
Performance Modelling
28
Performance Modelling
• Scheduling Theory
• Timed Petri Nets
• Timed Automata
• Deterministic Network Analysis
29
Scheduling Theory
• Well established
• Covers a variety of scheduling principles; RMA,DMA, EDF,…
• Works for both preemptive and non preemptive scheduling
• Takes critical instants into account; Priority Ceiling.
• Does not cover other IPC patterns, e.g. prod./cons.
(message passing)
• Tools available: TimeWIZ, RapidRMA, TIMES, ..
30
Timed Automata
• Well established
• General setup
• Does not directly cover scheduling problems
• Assertions verifiable
• May be computationally intractable – especially for
asynchronous communication (message passing)
• Tools available: UPPAAL, Kronos, ..
31
Timed Petri Nets
• Well established
• Mentioned in 61508
• Very general
• Assertions hardly verifiable for other than D-nets, M-nets
• Tools available: TPN-tools, TimeNET
32
Deterministic Network
Calculus
• Well established for buffer and delay dimensioning in network
communication
• May be used for modelling message-passing in real time
systems – transaction response times
• Abstract, overapproximating, conservative (good for safety ?)
• Computationally tractable
• Min/Plus, Max/Plus filtering theory
• Tools available: ??
33
See
www.uppaal.com
!!!!
UPPAAL
Modelling and Verification
of Real Time systems
UPPAAL2k
> 2000 users
> 45 countries
Timed Automata
Alur & Dill 1990
Clocks: x, y
Guard
n
Action
used
for synchronization
Boolean combination of integer bounds
on clocks and clock-differences.
Reset
x<=5 & y>3
Action perfomed on clocks
a
State
( location , x=v , y=u )
x := 0
Transitions
m
where v,u are in R
a
( n , x=2.4 , y=3.1415 )
( m , x=0 , y=3.1415 )
e(1.1)
( n , x=2.4 , y=3.1415 )
( n , x=3.5 , y=4.2415 )
35
Cruise Control
When the car ignition
is switched on and
the on button is
pressed, the current
speed is recorded
and the system is
enabled: it maintains
the speed of the car
at the recorded
setting.
Pressing the brake,
accelerator or off
button disables the
system. Pressing
resume or on reenables the system.
buttons
36
Model Structure
The
CONTROL
system is
structured as
two
processes.
User
engineOn
engineOff
on
off
resume
brake
accelerator
The main
actions and
interactions
are as
shown.
Cruise
Control
clearSpeed
recordSpeed
enablecontrol
disablecontrol
Speed
Control
Engine
dSpeed
cSpeed
acc
37
User
Engine
38
The CARA System
Computer Assisted
Resuscitation System
Purpose:
automate delivery of
intravenous fluids to
injured persons in
catastrophic situations
Comprises: software to:
monitor patient’s
blood pressure
control a high-output
infusion pump
39
System Structure
40
UPPAAL model
41
Traditional Software Development
The Waterfall Model
Problem
Area
Analyse
Design
Implementation
 Costly in time-to-market and money
 Errors are detected late or never
 Application of FM’s as early as possible
42
Testing
Modelbased Validation
Analysis
Validation
Design Model
Specification
Verification & Refusal
Implementation
Testing
43
Modelbased Validation
Analysis
Validation
Design Model
Specification
Verification & Refusal
Automatic
Code generation
Implementation
Testing
44
Modelbased Validation
Analysis
Validation
Design Model
Specification
Verification & Refusal
Automatic
Code generation
Automatic
Test generation
Implementation
Testing
45
Safety Research Activities
• Model based validation (UPPAAL)
(K. G. Larsen, A. Skou)
• Model based testing
(B. Nielsen)
• Realiable control systems
(J. Stoustrup)
• Structural analysis for complex systems
(R. I-Zamanabadi)
• Impact of Scheduling Policies on Controller Performance
(H. Schiøler, A. P. Ravn, J. Dalsgaard)
• Reliability Resource Reservation Protocol (RRSVP)
(H. Schiøler)
46
Control Systems
47
Reliable (Fault tolerant) Control
48
Reliable (Fault tolerant) Control
49
Reliable (Fault tolerant) Control
50
Structural Analysis
Problem:
Given a system, consisting of a set of components,
we would like to develope a method to analyse the
system and determine the possibility of detecting
different faults under the following conditions,
• System parameters are not known
• Linear as well as nonlinear dynamics
• Complexity (large systems)
51
Structural model
representation
Consider the system as a set of components, each
imposing a relation ,fi between a set of variables zj.
fi
z1
zp
System:
52
Structural model
representation 2
Systems structural graph is a tripartite directed graph:
u1
f1
x1
f3
f2
x2
u2
y1
f4
f5
x3
x4
53
y2
f6
y3
f7
x5
f8
x6
f9
x7
f10
Matching concept
The main purpose of developing a matching algorithm is
to identify the over-determined part of the system.
The principle of matching algorithm:
K
f1
f2
x2
x1
f3
f4
f5
x4
54
x3
Design Tool for Structural Analysis
(DTSA)
55
DTSA
56
Contact Info
• http://ciss.auc.dk (hjemmeside)
• [email protected] (Kim G. Larsen, leder)
• [email protected] (Henrik Schiøler, m.f.u)
• [email protected] (Peter Koch, m.f.u)
• [email protected] (Arne Skou, m.f.u)
57