Henrik Schiøler Konstruktion, modellering og validering af sikkerhedskritiske SW systemer

2 Why CISS ? zIncreasing demands in electronic equipments for yuser friendliness, yflexibility, ysmall size and weight ylow power consumption yconnectivity everywhere at all times drive the needs for higher levels of software realization !

3 Why CISS ? zThis applies not least to portable systems with wireless communication facilities as well as medical equipments.

4 Why CISS ? zApplication areas ymobile and wireless communication products yautomotive and avionic systems yconsumer electronics (e.g. audio and video) ymedico-technical equipment yBuilding automation ysmart devices ytoys and games ytextiles

5 Who is CISS ? Institute of Computer Science Institute of Computer Science Institute of Electronic Systems Institute of Electronic Systems Modelling and Validation; Programming Languages; Software Engineering Modelling and Validation; Programming Languages; Software Engineering Embedded Systems Communication; HW/SW Power Management Embedded Systems Communication; HW/SW Power Management Distributed Real Time Systems Control Theory; Real Time Systems; Networking. Distributed Real Time Systems Control Theory; Real Time Systems; Networking. UCb ICT Companies

6 Typical Activities zCo-financed R&D projects and case-studies zIndustrial training and education zSeminars, workshops and networks of knowledge transfer and exchange zPh.D. and industrial Ph.D. projects zVisiting Guest researchers zStudent projects

7 Theory and Methodology Technology Applications, Solutions, Benefits Innovation, 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 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 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: ??

UPPAAL Modelling and Verification of Real Time systems UPPAAL2k > 2000 users > 45 countries UPPAAL2k > 2000 users > 45 countries See !!!! See !!!!

35 Timed Automata n m a Alur & Dill 1990 Clocks: x, y x 3 x := 0 Guard Boolean combination of integer bounds on clocks and clock-differences. Reset Action perfomed on clocks Transitions ( n, x=2.4, y= ) ( n, x=3.5, y= ) e(1.1) ( n, x=2.4, y= ) ( m, x=0, y= ) a State ( location, x=v, y=u ) where v,u are in R Action used for synchronization

36 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 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. Cruise Control Cruise Control Speed Control Speed Control User Engine engineOn engineOff on off resume brake accelerator clearSpeed recordSpeed enablecontrol disablecontrol dSpeed cSpeed acc

38 User Engine

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 Problem Area Running System REVIEWS

43 Modelbased Validation Design ModelSpecification Verification & Refusal Analysis Validation FORMAL METHODS Implementation Testing UML

44 Modelbased Validation Design ModelSpecification Verification & Refusal Analysis Validation FORMAL METHODS Implementation Testing UML Automatic Code generation

45 Modelbased Validation Design ModelSpecification Verification & Refusal Analysis Validation FORMAL METHODS Implementation Testing UML Automatic Code generation Automatic Test 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 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)

52 Structural model representation Consider the system as a set of components, each imposing a relation, f i between a set of variables z j. System:

53 Structural model representation 2 Systems structural graph is a tripartite directed graph:

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

55 Design Tool for Structural Analysis (DTSA)

56 DTSA

57 Contact Info (hjemmeside) (Kim G. Larsen, leder) (Henrik Schiøler, m.f.u) (Peter Koch, m.f.u) (Arne Skou, m.f.u)