A Model Checker for AADL - Informatik 2

A Model Checker for AADL

M. Bozzano1, A. Cimatti1, J.-P. Katoen2,V.Y. Nguyen2, T. Noll2, M. Roveri1, R. Wimmer3

1 Fondazione Bruno Kessler, Italy2 RWTH Aachen University, Germany3 Albert-Ludwigs-University Freiburg, Germany

1CAV 2010 - Edinburgh, July 19, 2010

• System-Software Co-EngineeringFrom component to system-level design

Motivations

2

Issues with current state of the practice• SW verified in isolation from the target HW• Limited support for specifying fault models and degraded modes of operation• Safety and reliability models are separate from design models• Different formalisms and analysis techniques for evaluating different aspects• Limited support for analyzing timed and probabilistic properties• No coherent approach to analyze effectiveness of FDIR (Fault Detection,

Identification and Recovery)

The COMPASS Project

CAV 2010 - Edinburgh, July 19, 2010 3

• Correctness, Modeling, and Performance of Aerospace Systems

• Consortium funded by European Space Agency:– RWTH, Aachen, Germany– FBK-irst, Trento, Italy– Thales Alenia Space, France

• Integrated system-software co-engineering• A general-purpose specification formalism:

the SLIM (System-Level Integrated Modelling) language• A comprehensive methodology based on formal methods• A toolset implementing the methodology• Demonstration and evaluation on industrial-size case-studies

from the aerospace domain

The SLIM Language• An extension of AADL

– Architecture Analysis and Design Language– Design language standardized by SAE (Soc. Automotive Engineers)– + EMA = Error Model Annex

• Designed to cover:• Degraded modes of operation• Qualitative and quantitative (probabilistic) properties• Probabilistic faults and recovery• Observability requirements• Property language covering functional correctness, safety and

performability• Timed and continuous behavior

• Formal semantics defined in terms of– Networks of Event-Data Automata (NEDA)– Labeled Transition Systems (LTS)


The SLIM Language


• Features:– Component-oriented (HW, SW, composite)

The SLIM Language


• Features:– Component-oriented (HW, SW, composite)– Hierarchy of super- and sub-components

The SLIM Language


• Features:– Component-oriented (HW, SW, composite)– Hierarchy of super- and sub-components– Event and data ports

The SLIM Language


• Features:– Component-oriented (HW, SW, composite)– Hierarchy of super- and sub-components– Event and data ports– Functional behavior

The SLIM Language


• Features:– Component-oriented (HW, SW, composite)– Hierarchy of super- and sub-components– Event and data ports– Functional behavior– Probabilistic error behavior (AADL Error Model Annex)

The SLIM Language


• Features:– Component-oriented (HW, SW, composite)– Hierarchy of super- and sub-components– Event and data ports– Functional behavior– Probabilistic error behavior (AADL Error Model Annex)– Hybrid behavior (not in AADL)

Overview of the flow

CAV 2010 - Edinburgh, July 19, 2010

11

Nominal Models

FaultModels

ModelExtension

Verification

ValidationExtended

Model

Requirements

ObservabilityRequirements

FaultTrees

FMEATables

FDIREffectiveness

Traces

Performability Measures

Analysis

Requirements Validation

•Validate system requirements before detailed design and implementation

–“Are we capturing the right system?”

•Available functionalities:

–Property simulation

–Check logical consistency

–Check property assurance

•Assertions (properties are strict enough)

•Possibilities (properties are not too strict)

•Based on the RAT tool


Functional Correctness


• Correctness verification– “Are we building the system right?”

• Available functionalities:– Model Simulation– Property Verification

• Check that a specification is correct wrt a property• E.g. “always (voltage >= 5.8)”

• Based on NuSMV

Safety Analysis


• Safety analysis– Evaluate hazards and risks– Check system behavior in presence of faults

• Available functionalities:– Fault Tree Analysis (FTA)– Failure Modes and Effects Analysis (FMEA)

• Based on the FSAP tool

Safety Analysis

• Fault Tree Analysis (FTA)– Find the minimal combinations of

faults that may cause a top event• E.g.: “Which combinations of faults may

cause alarm to be raised”


Safety Analysis

• Failure Modes and Effects Analysis (FMEA)– Inductive technique: analyze the impact of faults on

a set of system properties• E.g. “What are the consequences of a battery failure: i) on

the output voltage of the power generator? ii) on the output alarm?”


Diagnosability Analysis

• FDIR effectiveness analysis– Fault Detection

• “Is it always possible to detect a fault?”– Fault Isolation

• “Is it possible to identify the fault responsible for an event?”– Fault Recovery

• “Is it always possible to recover from a fault?”

• Diagnosis feasibility• “Is there a diagnoser for a given property?”

• Diagnoser synthesis• “Find a good sensors configuration”


Probabilistic Verification

• Probabilistic versions of qualitative analyses– Check of probabilistic properties

• E.g. “Which is the probability of the alarm being raised?”– Probabilistic FDIR

• Probabilistic Fault Detection– “Which is the probability of detecting a fault?”

• Probabilistic Fault Isolation– “Which is the probability of identifying a fault?”

• Probabilistic Fault Recovery– “Which is the probability of recovering from a fault?

• Based on probabilistic model checking


Performability Analysis


• Performability Analysis– What is the probability and time to failure under

degraded operations?• E.g. “Which is the probability that both batteries die within

96 hours”

• Based on probabilistic model checking

The COMPASS Toolset: Architecture

20

Software-level view

• GUI developed following a MVC paradigm• GUI based on GTK• AADL parser based on ANTLR• Python 260 files, 82KLOC• Loose integration with the backends

– Channel-based control– Input/output via files


SCREEN SHOTS


Main view


Specifying fault models


Property templates


Simulation


Model Checking


Performability


FMEA


Fault Tree Generation


Dynamic Fault Tree Evaluation


Industrial Evaluation• Thorough evaluation by industrial partners• Several case studies developed

– Thermal regulation function– Thermal line class 3– Satellite modes and FDIR procedures

• Positive evaluation• Code delivered to and accepted by ESA

– Package includes comprehensive documentation• Licensing: we are looking forward to it…

– However, we are waiting for lawyers (as usual) – More intricate than expected– Distinction between EU and NON-EU member states

• Contact us if interested in forthcoming distribution


Conclusions• The SLIM language:

– A unified modeling language, amenable to V&V– Equipped with a formal semantics– Covers most of AADL + Error Annex– Some features proposed as extensions to AADL Standard

• The COMPASS Toolset:– Supports for System-Software Co-Engineering– Integrates formal methods techniques and tools to

address• functional correctness• Safety (FTA, FMEA)• Performability• FDIR effectiveness

http://compass.informatik.rwth-aachen.de/


EXAMPLES


An Example• A redundant

power system

• Power switches from primary to backup mode (and back) when batt1 (batt2) is empty


Modeling nominal behaviordevice Battery

features

empty: out event port;

voltage: out data port real;

end Battery;

device implementation Battery.Imp

subcomponents

energy: data continuous initially 100.0;

modes

charged: initial mode

while energy' = -0.01 and energy >= 20.0;

depleted: mode while energy' = -0.03;

transitions

charged -[then voltage := energy/50.0 + 4.0 ]-> charged;

charged -[empty when energy<=20]-> depleted;

depleted -[ then voltage := energy/50.0 + 4.0 ]-> depleted;

end Battery.Imp;


The ‘Battery’ component

- >=

=

Modeling error behaviorerror model BatteryFailure

features

ok: initial state;

dead: error state;

end BatteryFailure;

error model implementation BatteryFailure.Imp

events

fault: error event occurrence poisson 0.001;

transitions

ok-[fault]-> dead;

end BatteryFailure.Imp;


The ‘Battery’ error model

fault

The Complete Power Systemsystem Power

features


end Power;

device implementation Power.Imp

subcomponents

batt1: device Battery.Imp in modes (primary);

batt2: device Battery.Imp in modes (backup);

connections

data port batt1.voltage -> voltage in modes (primary);

data port batt2.voltage -> voltage in modes (backup);

modes

primary: initial mode

backup: mode;

transitions

primary -[batt1.empty]-> backup;

backup -[batt2.empty]-> primary;

end Power.Imp;


The ‘Power’ system

The Complete Power System


Modeling Observabilitysystem PowerSystem

features


alarm: out data port bool initially false observable;

end PowerSystem;

system implementation PowerSystem.Imp

subcomponents

pow: system Power.Imp;

connections

data port pow.voltage -> voltage;

modes

normal: initial mode;

critical: mode;

transitions

normal –[when voltage < 4.5 then alarm:=true]-> critical;

critical –[when voltage > 5.5 then alarm:=false]-> normal;

end PowerSystem.Imp;


The complete ‘Power’ system with an alarm

MORE DETAILS ON SLIM


The SLIM language

• A component-based paradigm– Interface characterizes type– finite-state automaton characherizes interaction

• Support for first class objects– software (e.g. processes and threads)– hardware (e.g. memories and processors)

• Nominal model


From nominal to error models

• The error model expresses how faults may affect normal operation and may lead the system into a degraded mode of operation.

• It is modeled as a (probabilistic) finite state automaton, where transitions may occur due to error events which may be annotated with a rate that indicates the expected number of occurrences per time unit.

• Transitions can also occur because of error propagations from other components.

• The nominal and error models are linked through a so-called fault injection.


DESCRIPTION OF CASE STUDIES


ICS1: Thermal regulation

• The thermal regulation function of a satellite system has been specified at functional level (i.e., without modeling any behavioral parts).

• It consists of five sub-functions and nine kinds of thermal components (including five passive ones such as optical solar reectors, multi-layer insulation, shields, etc.).

• Two implementations of the Acquisition function have been tested to experiment with the SLIM capabilities.


ICS2: Thermal line class3

• This system has been modeled from a behavioral point of view.

• It consists of the same components (except the passive ones) as those used for the functional approach.

• The behavior of the components has been modeled, and some injected faults have been defined.

• Figure 6.1 shows the result of a simulation with a fault injection.


ICS3: Satellite mode and FDIR

• It consists of the satellite mode automaton (containing three modes) during the Transfer Orbit (TO) phase, the Attitude and Orbit Control System (AOCS) mode automaton (six modes) and the complete AOCS equipment for a telecommunication satellite.

• In addition, the sequence of actions for configuring the equipment of each AOCS mode has been modeled.

• The dynamic evolution of the model is triggered by events that are received by the satellite, ranging from the launcher separation event to the end of TO.


A detailed list of functions


Property validation


Corresponding CTMC


ADDITIONAL INFORMATION ON THE COMPASS PROJECT


A new book on related topics

Design and Safety Assessment of Critical Systems by Marco Bozzano and Adolfo Villafiorita


The COMPASS Project• Correctness, Modeling, and

Performance of Aerospace Systems

• Funded by ESA/ESTEC under Contract No. 21171/07/NL/JD(Feb.2008 – March 2010)

• http://compass.informatik.rwth-aachen.de/


The COMPASS Project

• Correctness, Modeling, and Performance of Aerospace Systems

• Consortium:– RWTH, Aachen, Germany– FBK-irst, Trento, Italy– Thales Alenia Space, France

• Funded by ESA/ESTEC under Contract No. 21171/07/NL/JD(Feb.2008 – March 2010)


COMPASS Backends

• Built upon state-of-the-art tools:– The Requirements Analysis Tool (RAT)

• http://rat.fbk.eu– The NuSMV model checker

• http://nusmv.fbk.eu– The FSAP (Formal Safety Analysis Platform)

• http://fsap.fbk.eu– The Markov Reward Model Checker (MRMC)

• http://www.mrmc-tool.org– The Symbolic Bisimulation Tool Sigref

• http://sigref.gforge.avacs.org/


FROM HERE ON, JUNK


• System-Software Co-EngineeringFrom component to system design

Motivations


• Issues for modeling and verification:– Heterogeneity: software versus hardware components– Timed, hybrid, and probabilistic behavior– Errors and degraded modes of operation– Safety versus Performability

• SW verified in isolation from the target HW• Limited support for specifying fault models and

degraded modes of operation• Safety and reliability models are separate from

design models• Different specification formalisms and analysis

techniques for evaluating different system aspects• Limited support for analyzing timed and

probabilistic properties• No coherent approach to analyze effectiveness of

FDIR (Fault Detection, Identification and Recovery)

Weaknesses and limitations


The SLIM Language

• The input language: SLIM– System Level Integrated Modelling Language

• Designed to cover:• Timed and continuous behavior• Probabilistic faults and recovery• Degraded modes of operation• Qualitative and quantitative (probabilistic) properties• Observability requirements• Property language covering functional correctness, safety

and performability


The SLIM Language


• Additional features:– Specialized component categories:

• Hardware components• Software components• Composite components

– Component type• Defining the interface

– Component implementation• Defining the internal structure

– Dynamic system re-configuration

SLIM Semantics

• Defined in terms of NEDA and LTS – Networks of Event-Data Automata– Labeled Transition Systems

• For more information:– “Codesign of Dependable Systems: A Component-

Based Modelling Language" – MEMOCODE 2009


SLIM versus AADL


• A few AADL features left out of SLIM:• E.g. properties, flow specifications, in/out ports, …

• SLIM extensions to AADL (+ EMA):• Initialization (or default) values for components• Mode history (upon component re-activation)

(only for threads in AADL)• Specification of observability requirements• Invisible error states and events may appear in error model implementation• Error state history (upon component re-activation)

• Formal semantics defined in terms of– Networks of Event-Data Automata (NEDA)– Labeled Transition Systems (LTS)

Model Extension

• Automated fault injection mechanism:– Association between nominal and error models

• E.g. BatteryFailure model associated to Battery device– Definition of failure effects

• E.g. voltage:=0 in state dead

• Model extension process:– The result of a set of failure injections

• The extended model is still a SLIM model


Available Functionalities


• Requirements Validation• “are we capturing the right system?”• Property simulation, logical consistency, property assurance• The RAT tool

• Functional Correctness• “always (voltage >= 5.8)”

• Safety Analysis• Evaluate hazards and risks• Check system behavior in presence of faults• Fault Tree Analysis (FTA)

• “Which combinations of faults may cause alarm to be raised”• Failure Modes and Effects Analysis (FMEA)

• “What are the consequences of a battery failure: i) on the output voltage of the power generator? ii) on the output alarm?”

• Diagnosability Analysis (and Synthesis)• “will the system be able to diagnose faults?”

• Probabilistic Verification

• Performability Analysis• performance and dependability combined

The COMPASS Toolset


The COMPASS toolset


The COMPASS toolset: Screenshots



• FDIR effectiveness analysis– Fault Detection

• “Is it always possible to detect a fault?”• Reduces to a model checking problem:

– E.g. “always (fault -> eventually! alarm)”

– Fault Isolation• “Is it possible to identify the fault responsible for an event?”• Reduces to fault tree analysis – one fault tree for each event

– Perfect isolation = fault tree with a single cut set of order one

– Fault Recovery• “Is it always possible to recover from a fault?”• Reduces to a model checking problem

– E.g. ”always (fault -> eventually! recovery)”



• Check if there exists a diagnoser wrt a given diagnosability property


– Reduces to a model checking problem using the twin-plant construction [Cimatti et al. 2003]

– System is diagnosable if there is no critical pair


• Synthesis problem

– Synthesize a set of observables such that the system is diagnosable wrt a given diagnosability property

– Reduces to a model checking / planning problem (under partial observability)



• Diagnosability analysis (and synthesis)(under partial observability)

– Given a diagnoser, evaluate effectiveness of FDIR (Fault Detection, Isolation and Recovery)

– Check if there exists a diagnoser wrt to a given diagnosability property

– Synthesize a diagnoser such that the system is diagnosable wrt a given diagnosability property


A Model Checker for AADL - Informatik 2

Documents

Transcript of A Model Checker for AADL - Informatik 2