Henrik Schiøler

Konstruktion, modellering og validering

af

sikkerhedskritiske SW systemer

2

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 !

3

Why CISS ?

This applies not least to portable systems with

wireless communication facilities

as well as medical equipments.

4

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

5

Who is CISS ?

Institute ofComputer Science

Institute ofComputer Science

Institute ofElectronic Systems

Institute ofElectronic Systems

BRICS@AalborgModelling and Validation;Programming Languages;

Software Engineering

BRICS@AalborgModelling and Validation;Programming Languages;

Software Engineering

Embedded SystemsCommunication;

HW/SWPower Management

Embedded SystemsCommunication;

HW/SWPower Management

Distributed Real Time Systems

Control Theory;Real Time Systems;

Networking.

Distributed Real Time Systems

Control Theory;Real Time Systems;

Networking.

UCb

ICT CompaniesICT Companies

6

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

7

Th

eory

an

d

Th

eory

an

d

Met

hod

olog

yM

eth

odol

ogy

Tec

hn

olog

yT

ech

nol

ogy

Applications, Solutions, BenefitsApplications, Solutions, Benefits

Innovation, Ideas, PervationInnovation, Ideas, Pervation

8

Topics

9

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

10

Safety Critical Software SystemsSafety Critical Software Systems

Clusters

Model Based Development of Embedded Software

Intelligent Sensor Networks

Embedded & RT Platform LAB

Embedded System Validation & Testing

HW/SW Co-Design, Design Space Exploration

Safety Critical Software Systems

“THE” CISS Development Handbook

11

SW Development of

Info-tech. Systems

Functional demands

• Development cost/resources

• Time to market

Info-tech. system

12

Embedded systems

Functional demands

• Development cost/resources

• Time to market

Embedded Info-tech. system

Performance demands

• Timeliness

• Reliability

Technological resource bounds

• CPU speed

• Memory

• Power

• Comm. bandwidth

13

Functional Safety

14

Safety Integrity Levels (SIL)

15

Safety Lifecycle

16

Realization

17

SW Safety Lifecycle

18

SW Design and Development

19

Safety Integrity

20

SW Safety Integrity

21

Requirement Specification

22

SW Architectural Design

23

Detailled Design

24

Language and tools

25

Module and IntegrationTesting

26

Integration and Validation

27

Performance modelling

28

Performance Modelling

29

Performance Modelling

• Scheduling Theory

• Timed Petri Nets

• Timed Automata

• Deterministic Network Analysis

30

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

31

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

32

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

33

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: ??

UPPAALUPPAAL

Modelling and Verification of Real Time systems

UPPAAL2k > 2000 users > 45 countries

UPPAAL2k > 2000 users > 45 countries

See www.uppaal.com

!!!!

See www.uppaal.com

!!!!

35

Timed Automata

n

m

a

Alur & Dill 1990

Clocks: x, y

x<=5 & y>3

x := 0

Guard Boolean combination of integer boundson clocks and clock-differences.

ResetAction perfomed on clocks

Transitions

( n , x=2.4 , y=3.1415 ) ( n , x=3.5 , y=4.2415 )

e(1.1)

( n , x=2.4 , y=3.1415 ) ( m , x=0 , y=3.1415 )

a

State ( location , x=v , y=u ) where v,u are in R

Actionused

for synchronization

36

Cruise ControlWhen 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 re-enables the system.

buttons

37

Model Structure

The CONTROL system is structured as two processes.

The main actions and interactions are as shown.

The CONTROL system is structured as two processes.

The main actions and interactions are as shown.

CruiseControl

CruiseControl

SpeedControl

SpeedControl

UserUser

EngineEngine

engineOnengineOffonoffresumebrakeaccelerator clearSpeed

recordSpeedenablecontroldisablecontrol

dSpeedcSpeedacc

38

UserUser EngineEngine

39

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

40

System Structure

41

UPPAAL model

42

Traditional Software Development

The Waterfall Model

Analyse

Design

Implementation

Testing Costly in time-to-market and money Errors are detected late or never Application of FM’s as early as possible

ProblemArea

Runni

ng

Syst

em

REVI

EWS

REVI

EWS

43

Modelbased Validation

Design Model SpecificationVerification & Refusal

AnalysisValidation

FORMAL

METHODS

Implementation

Testing

UML

44

Modelbased Validation

Design Model SpecificationVerification & Refusal

AnalysisValidation

FORMAL

METHODS

Implementation

Testing

UML

AutomaticCode generation

45

Modelbased Validation

Design Model SpecificationVerification & Refusal

AnalysisValidation

FORMAL

METHODS

Implementation

Testing

UML

AutomaticCode generation

AutomaticTest generation

46

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)

47

Control Systems

48

Reliable (Fault tolerant) Control

49

Reliable (Fault tolerant) Control

50

Reliable (Fault tolerant) Control

51

Structural Analysis

Problem:Given a system, consisting of a set of components,we would like to develope a method to analyse thesystem 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)

52

Structural model representation

Consider the system as a set of components, each imposing a relation ,fi between a set of variables zj.

fiz1 zp

System:

53

Structural model representation 2

Systems structural graph is a tripartite directed graph:

x1

y2 y3y1

f1 f3f2 f4 f5 f6 f7 f8 f9 f10

x2 x3 x4 x5 x6 x7

u2u1

54

Matching concept

The main purpose of developing a matching algorithm is to identify the over-determined part of the system.

Kf1f2

f3

f4f5

x 1x 2

x 3x 4

The principle of matching algorithm:

55

Design Tool for Structural Analysis (DTSA)

56

DTSA

57

Contact Info

• http://ciss.auc.dk (hjemmeside)

• kgl@cs.auc.dk (Kim G. Larsen, leder)

• henrik@control.auc.dk (Henrik Schiøler, m.f.u)

• pk@kom.auc.dk (Peter Koch, m.f.u)

• ask@cs.auc.dk (Arne Skou, m.f.u)