fortiss workshop november 20, 2015 munich, germany · 2015-12-21 · fortiss workshop november 20,...

FORTISS Workshop

November 20, 2015

Munich, Germany

Part III: Contract-Based Architectural Analysis

Stefano TonettaFondazione Bruno KesslerCenter for Scientific and Technological [email protected]

Parts of the material presented in these slides have been contributed by Alessandro Cimatti, Anthony Fernandes Pires, Cristian Mattarei, Marco Gario and other people in FBK

mailto:[email protected]

Outline

1. Component-based and contract-based design of system architectures

2. OCRA3. Trace-based semantics4. Architectural analysis with OCRA 5. Integration with AF36. Case studies

– SenseSpacecraftRate (FoReVer)– WBS ARP4761 (SafeCer) – contract-refinement, CBSA– WBS AIR6110 (Boeing) – safety process, contract-

refinement, CBSA

7. Ongoing directions

Contract-based Architectural Analysis - FORTISS Workshop Nov. 20, 2015 2

Outline




refinement, CBSA



Component-based design

• A component can be defined as a unit of composition with contractually specified interfaces

– Hides internal information

– Defines interface to interact with the environment

• Component-based design ideal for

– Separation of concerns

– Independent development

– Reuse of components

• First conceived for software, now popular also for system architectural design (SysML, AADL, AF3, Altarica, …)

4Nov. 20, 2015Contract-based Architectural Analysis - FORTISS Workshop

Hierarchical decomposition

• System A

• System A decomposed into subsystems B and C

• Subsystem B decomposed into equipments D and E

• Hierarchical decomposition preserves ports

5

A

B C

D E

Nov. 20, 2015Contract-based Architectural Analysis - FORTISS Workshop

Specifying components with contracts

• A component is immersed in an environment

• Its behavior is specified by contracts• Contract: assumptions + guarantees• Assumptions: properties expected to

be satisfied by the environment• Guarantees: properties expected to

be satisfied by the component in response

• Contracts used for proper – Stepwise refinement.– Reuse of components.– Compositional verification.

A

B C

D E


Stepwise refinement

• Specify components while designing– decomposing the specification

based on the decomposition of the architecture

• Early check of requirements– Ensure the correctness of the

decomposition– Does the contract of A follow

from the contracts of B and C?

• Independent refinement:– Based on above check, B and C

can be developed independently.

7

A

B C

D E


Component reuse

• Library of trusted components

– e.g. the SRA of the ESA

• Implementation + contracts

• Pluggable?

– compare contracts!

8

A

B C

D E

D E

C


Compositional verification

9

A

CD ED E C


Contract-based compositional

• Components interact with an environment.– Input/output data/events– Input controlled by environment, output controlled by

component• Compare it to SMV input variables.

• May be input enabled or possibly blocking.• Blocking an input means constraining the

environment.– The component can be used only in some environment

(assumptions!)

• Compositional rule is not just an implication!– Guarantees of subcomponents must be stronger.– Assumptions of subcomponents must be weaker.


Outline




refinement, CBSA



OCRA tool support

• OCRA=Othello Contract Refinement Analysis• Textual representation of the architecture and contracts• Built on top of nuXmv for infinite-state model checking• Integrated with CASE tools:

– AutoFocus3• Developed by Fortiss• For synchronous system architectures

– CHESS• Developed by Intecs• For SysML and UML modeling

– COMPASS• Developed by FBK and RWTH/AACHEN• Variant of AADL

• One of the few tools supporting contract-based design for embedded systems

• Publicly available at https://ocra.fbk.eu


https://ocra.fbk.eu/

Related Projects

• SafeCer (Apr. 2011 – Mar. 2015)– ARTEMIS project on Safety Certification of Software-Intensive

Systems with Reusable Components. – First development of OCRA– Used by Thales Comm., TTTECH, CAF, …

• FoReVer (Jan. 2012 – Mar. 2013)– ESA study on Functional Requirements and Verification

Techniques for the Software Reference Architecture.

• D-MILS (Nov. 2012 – Oct. 2015)– FP7 project on Distributed MILS for Dependable Information

and Communication Infrastructures.

• Collaboration with Boeing (2014 – 2015)• CATSY (Dec. 2014 – Apr. 2016)

– ESA study on Catalogue of System and Software Properties

Nov. 20, 2015Contract-based Architectural Analysis - FORTISS Workshop 13

http://www.safecer.eu/

https://es.fbk.eu/projects/forever/

http://www.d-mils.org/

OCRA language

COMPONENT system…

COMPONENT A…

COMPONENT B…


Component interface


COMPONENT systemINTERFACE

INPUT PORT x: continuous;OUTPUT PORT a: boolean;

…REFINEMENT…

COMPONENT A…

COMPONENT B…

Othello contracts

COMPONENT simple systemINTERFACE

INPUT PORT x: continuous;OUTPUT PORT v: boolean;

CONTRACT v_correctassume: always x>=0;guarantee: always (x=0 implies v);

REFINEMENT…

COMPONENT A…

COMPONENT B…


Component refinement




REFINEMENTSUB a: A;SUB b: B;

CONNECTION a.x := x;CONNECTION b.y := a.v;CONNECTION v:= b.v;

…


Contract refinement




REFINEMENTSUB a: A;SUB b: B;

CONNECTION a.x := x;CONNECTION b.vi := a.v;CONNECTION v:= b.vo;

CONTRACT v_correct REFINEDBY a.v_correct, b.pass;


Port types

• Port types are either– NuSMV types: boolean, enumeratives, ...

– nuXmv additional types: real, integer, and uninterpretedfunctions

– continuous, i.e. real-value ports evolving continuously in time.

– event, i.e. boolean-value port that is assigned only on discrete transitions.

• Port can be:– Input

– Output

– Parameter


Contract specification language

• Contracts’ assumptions and guarantees specified in an extension of LTL

• Both discrete-time and hybrid semantics are supported

• Increase usability with– Syntactic sugar

– English words instead of math symbols:• “always” (𝐺)

• “never” (𝐺¬)

• “eventually” (𝐹)

• “next” (𝑋)


From finite to infinite

• Use first-order predicates instead of propositions:

– 𝐺 𝑥 ≥ 𝑎 ∧ 𝑥 ≤ 𝑏

– 𝐺𝐹 𝑥 = 𝑎 ∧ 𝐺𝐹 𝑥 = 𝑏

• “next” to express changes/transitions:

– 𝐺 𝑛𝑒𝑥𝑡 𝑥 = 𝑥 + 1

– 𝐺(𝑛𝑒𝑥𝑡 𝑎 − 𝑎 ≤ 𝑏)


Continuous time

• The derivative of “x” is always less than 2:always der(x)<2

• Whenever “a” holds, the derivative of “x” is zeroalways (a implies der(x)<=2)

• Whenever “a” holds, “b” remain true until the derivative of “x” is less or equal to 5

always (a implies (b until der(x)<=5)

• Reaction timealways (e1 implies time_until(e2)<=5)

speedlimit

warning

STA

TETI

ME

𝐺(𝑠𝑝𝑒𝑒𝑑 > 𝑙𝑖𝑚𝑖𝑡 →𝐹(𝑤𝑎𝑟𝑛𝑖𝑛𝑔))


Outline




refinement, CBSA



Black-box component interface

• A component interface defines boundary of the interaction between the component and its environment.

• Consists of:– Set of input and output ports (syntax)

• Ports represent visible data and events exchanged with environment.

– Set of traces (semantics)• Traces represent the behavior, history of events and values on data

ports.

24

Component

Inp

ut

Ou

tpu

t


Component

Glass-box component structure

• A component has an internal structure.• Architecture view:

– Subcomponents– Inter-connections– Delegations

• State-machine view:– Internal state– Internal transitions– Language over the ports


Inp

ut

Ou

tpu

t

Component

Sub1

Sub2

Composite components and connections

• Components are composed to create composite components.

• Different kind of compositions:– Synchronous,– Asynchronous,– Synchronizations

• Connections map (general rule of architecture languages):– Input ports of the composite component– Output ports of the subcomponentsInto– Output ports of the composite component– Input ports of the subcomponents.


Contracts

• Properties of the component and its environment.• Can be seen as assertion for component interfaces.• Contracts used to characterize the correctness of

component implementations and environments.• Typically, properties for model checking have a “God”

view of the system internals. • For components instead:

– Limited to component interfaces.– Structure into assumptions and guarantees.

• Contracts for OO programing are pre-/post-conditions [Meyer, 82].

• For systems, assumptions correspond to pre-conditions, guarantees correspond to post-conditions.


Trace-based contract refinement

• The set of contracts 𝐶𝑖 refines 𝐶 with the connection 𝛾 ( 𝐶𝑖 ≼𝛾 𝐶) iff for all correct implementations 𝐼𝑚𝑝𝑖 of 𝐶𝑖 and correct environment 𝐸𝑛𝑣 of 𝐶:– The composition of {𝐼𝑚𝑝𝑖} is a correct implementation of C.– For all k, the composition of 𝐸𝑛𝑣 and 𝐼𝑚𝑝𝑖 𝑖≠𝑘 is a correct environment of 𝐶𝑘.

• Verification problem: – check if a given refinement is correct (independently from implementations).


Component

Sub

Sub

C

C1

C2

Proof obligations for contract refinement

• Given C1=<1,1>, … , C1=<n,n>, C=<,>• Proof obligations for 𝐶𝑖 ≼ 𝐶:

– 𝛾 1≤𝑗≤𝑛 𝛼𝑗 → 𝛽𝑗 → 𝛼 → 𝛽

– 𝛾 2≤𝑗≤𝑛 𝛼𝑗 → 𝛽𝑗 → 𝛼 → 𝛼1

– …

– 𝛾 1≤𝑗≤𝑛,𝑗≠𝑖 𝛼𝑗 → 𝛽𝑗 → 𝛼 → 𝛼𝑖

– …

– 𝛾 1≤𝑗≤𝑛−1 𝛼𝑗 → 𝛽𝑗 → 𝛼 → 𝛼𝑛

• Theorem: 𝐶𝑖 ≼𝛾 𝐶 iff the proof obligations are valid. [CT12]


Notes on assumptions

• Weak assumptions are represented with implications in the guarantees– Different assume-guarantee pairs may have inconsistent

weak assumptions (if x>0 then …, if x<0 then …)

• OCRA assumptions are strong– Define properties that must be satisfied by the

environment.

• Standard problem with weak/strong: how to break circularity?

– 𝐺 𝐴 → 𝐵 ∧ 𝐺 𝐵 → 𝐴 ⇒ 𝐺(𝐴 ∧ 𝐵) is false

– Induction-based mechanisms:

• 𝐵 ∧ 𝐺 𝐴 → 𝑋𝐵 ∧ 𝐴 ∧ 𝐺 𝐵 → 𝑋𝐴 ⇒ 𝐺(𝐴 ∧ 𝐵) is true


Outline




refinement, CBSA



Main Commands

• Main commands:– ocra_check_syntax

– ocra_check_refinement

– ocra_check_consistency

– ocra_check_implementation

– ocra_check_receptiveness

– ocra_compute_fault_tree

• Typical script:– set verbose_level 1

– set on_failure_script_quits 1

– set pp_list cpp

– ocra_check_syntax -i SenseSpacecraftRate.oss

– ocra_check_refinement

– quit

• Call: ocra –source SenseSpacecraftRate.cmd

• Results are shown in textual form or in XML to ease the integration within modeling tools


Discrete vs. hybrid

• OCRA is parametrized by the logic

• The expressions can be restricted and interpreted as discrete-time LTL or hybrid LTL

• Default is hybrid

• Set discrete-time to switch to LTL

• In discrete-time mode, smv can be used to specify the implementation of the leaf components


Contract refinement results

• For every component, for every refined contract, check refinement.

• For every proof obligation, check its validity:

– [OK] if valid

– [BOUND OK] if no counterexample found up to k

– [FAIL] if found counterexample


Hierarchical Safety Assessment


OCRA for design space exploration

• Parameters can be used to instantiate components with different configurations

• Component implementations are linked to OCRA components by means of a map file

– Easy to analyze the architecture with different implementations


Integration with testing


BUS

Collision sensor

E2E_Protect E2E_Check

Airbag Controller

System𝐶

𝐶𝑠

𝐶𝑃

𝐶𝐵𝐶𝐴

𝐶𝐶

cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

ccccccccccccccccccccccccccccccccccccccccccc

test suite

Outline




refinement, CBSA



OCRA vs. AF3

• Same component-based approach• Same separation of architecture and

implementations• OCRA is textual, AF3 is graphical• AF3 does not support

– Events– Distinction between component types and instances– Expressions in data connections (e.g., in:= outp1 or

outp2)– Infinite-domain variables– Continuous/hybrid syntax and semantics

• Different semantics– The value of data ports in AF3 may be not present


AF3 with OCRA Contracts

• AF3OCRA is a plugin to enable the OCRA contract-based analysis in AF3

• Contracts are written in textual form with syntax-driven editor embedded in AF3

• Contract view to navigate contract refinement tree• Automatic translation into OCRA preserving AF3

semantics• Mapping back of results• Supported:

– Check refinement– Check implementation

• Distributed with AF3 and with OCRA


OCRA Viewer with AF3

• Plugin further extended to work as OCRA viewer

• New import of OCRA files

– Full support of OCRA language

– Does not preserve the semantics!

– Only used to visualize the OCRA architectures

• AF3OCRA also generates the documentation

– As images, html, latex, …

– Can be used also for AF3!

• Not yet distributed


Outline




refinement, CBSA



SenseSpacecraftRate Example

• Two redundant sensors

• Two monitors monitoring if the value of each sensor is present

• A selector switching between the two sensors

• Contract refinement holds without assumptions

• Faulty extension in which the sensors may fail

• Contract refinement still holds assuming at most one fault at a time


SenseSpacecraftRate Example


Wheel Braking System (ARP4761)

• Different versions of WBS

• First OCRA model inspired by Damm et al. paper on virtual integration testing where safety requirements were formalized with temporal properties– Focused on real-time bounded response and fault

tolerance

• Propositional variant developed as benchmark for BDD-based verification

• Further extended and improved following the case study described in the ARP4761


WBS architecture

46

System component (SC)

WBS (WBS)

Normal WBS (NWBS)

Pe

dal

Po

s1(P

1)

Ped

al P

os2

(P2

)

BSCU

subBSCU2

(SB2)

Sele

ct S

wit

ch

Hyd

rau

lic (

HY

D)subBSCU

1(SB1)

BSC

U

Po

we

r(S

P)

Alternate WBS (AWBS)

Emergency WBS (EWBS)

Brake System Annunciation (BSA)

An

nu

nci

ate

dB

raki

ng

Loss

Valid

CM

D A

S

Bra

ke (

BA

)

Bra

ke (

BE)

CM

D A

S

Blu

e

Po

we

r(B

P)

Gre

enP

ow

er

(GP

)

Bra

ke (

BN

)

Bra

ke

CM

D A

S

Valid


AIR 6110 WBS case study


Proposed approach

V & VSafety Assessment

Fault extension Fault trees computation

Architecturedecomposition

& Contracts

• Automatic contractrefinement verification

• Automatic fault extension

• Automatic hierarchical fault tree generation

• Over-approximation

BehavioralImplementation

(Leaf components& System)

• Automatic compositional verification

• Automatic monolithicverification

• Failure modes defined by the user

• Generation of the extended system implementation

• Automatic flat fault tree generation

xSAP

OCRA

xSAP

OCRA OCRASemi-

automatic Generation

MODELING

ANALYSIS

nuXmv

OCRA

𝑀 ⊨ 𝜑

𝑀

𝑀 ⇝ 𝑀 𝐹 𝛿 𝐹 ∶ 𝑀 𝐹 ⊨ 𝜑∕


Proposed approach

V & VSafety Assessment

Fault extension Fault trees computation

Architecturedecomposition

& Contracts

• Automatic contractrefinement verification

• Automatic fault extension

• Automatic hierarchical fault tree generation

• Over-approximation

BehavioralImplementation

(Leaf components& System)

• Automatic compositional verification

• Automatic monolithicverification

• Failure modes defined by the user

• Generation of the extended system implementation

• Automatic flat fault tree generation

xSAP

OCRA

xSAP

OCRA OCRASemi-

automatic Generation

MODELING

ANALYSIS

nuXmv

OCRA

CBSA

𝑀 ⊨ 𝜑

𝑀

𝑀 ⇝ 𝑀 𝐹 𝛿 𝐹 ∶ 𝑀 𝐹 ⊨ 𝜑∕MBSA


Application on AIR6110 WBS

• Application on 5 WBS architectures versions


V & V: Compositional approach

• Contracts refinement (BDD algorithm) checked in 30-100s

• Detection of an unexpected flaw in Arch2

– Preclusion of the operation modes: Normal VS Alternate

– Arch2: the alternate circuit can be supplied by the accumulator while the normal circuit is operating

• Detection of the problem in Arch3 which leads to Arch4! (AIR6110, p.67)

– If application of the modification of Arch 4 concerning the placement of the accumulator

• Creation of architecture Arch2bis

• The previous property is verified


Arch2 accumulator position


Arch2bis accumulator position


Outline




refinement, CBSA



Integration with HyCOMP

• HyCOMP: model checker for networks of hybrid automata

• Input language: a hybrid variant of SMV with continuous variables and flow conditions

• Used as implementation language for OCRA with hybrid time semantics


A

B C

D E

Property AProperty BProperty CProperty DProperty E….….….

Requirement 1Requirement 2Requirement 3Requirement 4Requirement 5Requirement 6Requirement 7

….…..

Guided Formalization

Refinement

Refinement


….…..


….…..



System

Avionics

SW/HW

CATSY

Validation

Validation

Validation


Catalogue of System and Software Properties

• Catalogue of System and Software Properties (CSSP)– Predefined parametrized low-level properties– Used in the refinement– Either verified on the application behavioral models or

ensured by the platform

• Guided formalization based on CSSP– Taxonomy of requirements and – Formal property patterns– Specific patterns for low-level properties (deadline,

monitoring frequency, threshold, …)

• Validation of the formalization with – Queries to test the formalization– Traces to show possible executions– Explanation/debugging of the refinement


fortiss workshop november 20, 2015 munich, germany · 2015-12-21 · fortiss workshop november 20,...

Documents