180 likes | 194 Views
This research explores the use of safety-interfaces for performing safety analysis in component-based systems. It investigates techniques for generating safety interfaces, as well as methods for using them in safety analysis. The study includes case studies and related publications.
E N D
People involved • Simin Nadjm-Tehrani – RTSLAB, Linköpings universitet • Jonas Elmqvist – RTLSAB, Linköpings universitet • Marius Minea – “Politehnica” University of Timisoara, Romania • Master thesis students: • Jerker Hammarberg: High-Level Development and Formal Verification of Reconfigurable Hardware • Anders Granh: Code Generation from High-level Models of Reactive and Security-intrinsic Systems • Andreas Eriksson: Model Based Development of an Airbag Software • Markus Nilsson: A tool for automatic formal analysis of fault tolerance
Verification bench Component Environment Out Out In In Alarm Observer property p Pattern: Functional verification Model of the environment Model of the system Checks if property p is satisfied
Non-occurence of catastrophic events Patterns for safety analysis?
Software/Digital hardware Traditional FTA/FMEA Top event • FTA: • FMEA: What are the consequences of some particular component’s failure?
Fault mode signals Verification bench Component Environment Out Out In In Alarm Observer property p Pattern: Fault mode modelling Model of a fault
Verification bench HS1B_Closed H - ECU PLD1 Valve HS1C_Closed Valve HS1Sensors Observer Alarm PLD2 HS2Sensors Valve HS2B_Closed HS2C_Closed Valve ShutOffLow Case study: Hydraulic leakage detection system
? Digital components Faults? Automatic Fault Tree Generation Automatic generation
Upgrades? Verification bench Component Environment Out Out In In Alarm Observer property p Pattern: Fault mode modelling Fault mode signals
C2 C1 C´4 C4 C3 Building Systems from Components • Component-Based Development (CBD) is an emerging trend in system development: • develop systems out of software components (COTS) and hardware components • Problem: no component models address safety! C5 C6 C7
Components & Interfaces • A component is an independent entity (SW or HW) that communicates through well-defined interfaces • Interfaces should provide all information needed for composition • How should the analytical interface look like in order to capture safety? I is the interface of the component M is a model of the behavior of the component C I M
Safety Analysis and CBD • Traditional safety analysis is performed on the composed system • Our approach: • Interfaces captures information about the behaviour of the components in presence of faults in the system C1 ? ? p p + S satisifies satisifies C2
Current work • Techniques for component-based safety analysis using safety-interfaces • Methods for generating safety interfaces • Methods for using safety interfaces for safety analysis • Case studies?!
Related Publications • J. Elmqvist, S. Nadjm-Tehrani and M. Minea, “Safety Interfaces for Component-Based Systems”, 24th International Conference on Computer Safety, Reliability and Security (SAFECOMP05), September, 2005. • J. Elmqvist and S. Nadjm-Tehrani, “Intents, Upgrades and Assurance in Model-Based Development”, 2nd RTAS Workshop on Model-Driven Embedded Systems (MoDES’04), May, 2004 • J. Elmqvist and S. Nadjm-Tehrani, “Intents and Upgrades in Component-Based High-Assurance Systems”, in Model-driven Software Development, Volume II of Research and Practice in Software Engineering, Springer-Verlag. • Jerker Hammarberg, “High-Level Development and Formal Verification of Reconfigurable Hardware”, 2003 • Jonas Elmqvist, “Analysis of Intent Specification and System Upgrade Traceability”, 2004 • Anders Granh, “Code Generation from High-level Models of Reactive and Security-intrinsic Systems”, 2004 • Andreas Eriksson, “Model Based Development of an Airbag Software”, 2004 • Markus Nilsson, “A tool for automatic formal analysis of fault tolerance”, 2005
Airbag Software • Characteristics • Porting from 16 bit (128kb ROM) processor to 32 bit processor (256kb ROM) • Current code not portable, design not documented • Studied tools: • Rhapsody in C, Interrupt driven framework • MISRA compatible • Code size roughly twice as big as the hand written C • Scade • Useful for algorithmic parts of the model, e.g. Crash detection • Assurance aided by formal verification
Tiger XS • Characteristics • Security intrinsic communication platform • Secure applications to run on multiple hardware (PDA, phone, …) • Security assurance via inspections of generated code • Multiple OS, preferably no system calls • Studied tools • Rhapsody • Heavy duty • Not suitable for integration with legacy • Visual state • Cumbersome to define user defined data types
Simulink Gateway NuSMV Theorem Prover Lustre Design Verifier Properties Model Model Tool chain Possible now Perhaps in future Simulink SCADE State Machines