+ All Categories
Home > Documents > Safety Critical Systems 4 Formal Methods / Modelling T 79.5303.

Safety Critical Systems 4 Formal Methods / Modelling T 79.5303.

Date post: 28-Dec-2015
Category:
Upload: shana-green
View: 216 times
Download: 1 times
Share this document with a friend
Popular Tags:
33
Safety Critical Systems 4 Formal Methods / Modelling T 79.5303
Transcript

Safety Critical Systems 4Formal Methods / Modelling

T 79.5303

Formal Methods Formal methods have been used for safety and security-critical purposes during last decades for e.g:- Certifying the Darlington Nuclear Generating Station plant shutdown system.

- Designing the software to reduce train separation in the Paris Metro.

- Developing a collision avoidance system for United States airspace.

- Assuring safety in the development of programmable logic controllers.

- Developing a water level monitoring system.

- Developing an air traffic control system.

-

Need for Formal Methods

• To mathematically describe the system – both software and hardware/functionality

• To mathematically describe the properties for validation/verification – possiblity to prove

• Enables simulation ( validation)

• Enables automatic verification

Formal Methods and Safety-Critical Systems

- Formal Methods are used in expressing requirements, design and analysis of a safety critical software and hardware. The use of mathematical techniques reduce possible personal interpretation - There exists a need for using formal methods from writing requirements to verifying the system that they are fulfilling those- Many difficulties are related to misunderstanding requirements/specification.

Semi-formal Requirements/Specification

Requirements should be unambiguous, complete, consistent and correct. - Natural language has the interpretation possibility. More accurate description needed.- Using pure mathematic notation – not always suitable for communication with domain expert. - Formalised Methods are used to tackle the requirement engineering. (Structured text, formalised English).

Domain Expert(s)

Text

Validation

Consistency

Validation

ModelInformal

Verification

Consistency

Implement.

Validation

Verification(Testing)

Consistency(another) Model

FormalVerification

Method

Method (system engineering) consists of:

1) Underlying model of development (process)

2) Language (expressing formal specification)

3) Defined, ordered steps (phases)

4) Guidance for applying steps in a coherent manner (instructions)

Formal Methods/ Model orientated

These languages involve the explicit specification of a state model - system‘s desired behaviour with abstract mathematical objects as sets, relations and functions.- VDM (Vienna Development Method

ISO standardised).- Z-language - B-Method

Formal Methods/ Property orientated

Property orientated include axiomatic and algebraic methods.

- Axiomatic use first order predicate logic to express pre/post conditions over abstract data types (Larch/ADA, Sternol)

- Algebraic methods are based on multi and order sorted algebras and relate properties of the system to equations over entities of the algebra (Act One, Clear and OBJ).

Formal Methods/Process orientated

Process algebras have been developed to meet the needs of concurrent systems.

- Theories behind Hoare‘s Communicating Sequential Processes (CSP) and Milner‘s Calculus of Communicating Systems (CCS).

- Protocol specification language LOTOS is based on combination of Act One and CCS.

Formal Language/Method selection criteria

Good expressiveness

Core of the language will seldom or never be modified after its initial development, it is important that the notation fulfils this criterion.

Established/accepted to use with Safety Critical Systems

Possibility of defining subset/coding rules to allow efficient automatic processing by tools.

Support for modular specifications – basic support is expected to be needed.

Temporal expressiveness

Tool availability

Formal Methods/ Z-language Z-language bases on first order predicate logic and

set theory.

- The specification expressed in Z-notation is divided into smaller parts – schemas

- These schemas describe the statical and dynamical characteristics of the system:

static: possible states, invariantsdynamic: possible operations, pre/post states

- Z is an excellent tool for modelling data, state and operations

Simple example of Z notation

___BirthdayBook_______ known:PNAME birthday: NAME → DATE_____________________ known = dom birthday_____________________

___AddBirthday________∆BirthdayBookname?:NAMEdate?:DATE_____________________name? /€ knownbirthday’ =birthdayU{name? →date?}_____________________

___FindBirthday____________ΞBirthdayBookname?:NAMEdate!:DATE_________________________name?€ knowndate! = birthday(name?)_________________________

___Remind________________Ξ BirthdayBooktoday?:DATEcards!:PNAME_________________________cards!={n:known|birthday(n)=today?}_________________________

Formal Methods/ B-method

B is quite well-known. Although not as established as Z, B figures in some remarkable success stories of industrial applications of formal methods, e.g. by MATRA and B Toolkit/UK. - B-method uses Abstract Machine Notation (AMN) for specification and implementation.

Formal Methods/ B-method

- Like Z, B is based on set theory and provides a rich set of operations.

- B includes facilities for modular specifications, although not as powerful as those of Z.

- The temporal expressiveness of B is poor. Only relations between a state and the next can be expressed.

Modelling Requirements

• Models needed for communication with domain experts (simulation)

• Automatic verification (model checker, theorem proving)

Some Modeling Styles

Black Box

Glass Box

View point: versus

Functional Object-based

Decomposition: versus

Textual

Blabla

GFHP

Graphical

Representation: versus

Verification and Validation

- Verification – Are we building the system right?

- Validation – Are we building the right system?

Verified software process

Model Verification

e.g.„A point may never move

when a route is locked.“ Challenger

Proof

e.g. challenger is false in the following case:•User: set route A•System: steer point 1 left •HW: point 1 at left•User: set point 1 right •System: steer point 1 right

CONFLICT!!!

Domain Expert

VerifierVerification Support ToolRequirements

Model

RequirementsModelingLanguage

Languages of Logic– Propositional Logic

Statements– (1st Order) Predicate Logic (FOPL)

Statements quantified (, ) over things (objects!)– Linear Temporal Logic (LTL)

Statements quantified (, , G, F, H, P) over things and time

– Computational Tree Logic (CTL)Statements quantified (, , G, F, H, P, , ) over things, time and worlds (modal logic)

– Enhanced Regular Expression Logic (ERE)Statements about occurrence patterns (seq, sel, itr, par) of events and conditions causing actions

•Note: The list above is neither complete nor it does necessarily imply any hierarchy!

S

S

tS

tS

tSSSS SSSS

SSSS

SSSS

(Some) Languages of Logic

Objects,

TimeG, F, H, P

Worlds,

Propositional

Logic

Predicate

Logic

ModalLogic

Temporal Logic(LTL)

CTL

ERE?

DL

Verification Technologies

Model Checking Theorem Proving

Objects,

TimeG, F, H, P

Worlds,

Propositional

Logic

Predicate

Logic

Modal

Logic

Temporal Logic (LTL)

CTL ERE

?

DL

Tools for Validation & Verification• Tools for Validation

– Static analysers derive implicit information about a model (or a program)

• Examples: KeY, VDMTools (IFAD), …– Simulators for executable specifications

• Examples: UML (Cassandra), MATLAB/Simulink, Statemate, …

• Tools for Verification– Model checkers for “brute force” enumeration of states

• Examples: Alloy, SATO, SMV/NuSMV, SPIN, Statemate, UPPAAL, Validas, …

– Theorem provers provide support for algebraic proofs of model properties

• Examples: ACL2, Alloy, eCHECK (Prover Technologies), KIV, PVS (SRI Inc.), TRIO-Matic, VSE II, …

Statemate modelling

• Based on Harel state charts from 80‘s

• Functional decomposition

• Used years in aviation and car industry

• Mainly for simulating and validating functionality (Test cases)

• Model checker for verification

Language of Statemate

Finite State Machines (FSM):

A virtual machine that can be in any one of a set offinite states and whose next states and outputs are functions of input and the current state.

Hierarchy:

Structure:A state may consist of states which consists of states….Priority Rule:Priority is given to the transition whose source and target states have a higher common ancestor state.

Concurrency:

“Processes that may execute in parallel on multipleprocessors or asynchronously on a single processor.” IEEE 729

S1 S2E1

E2

S1_S2

E1E2 F1F2

S1 S2

S11

S12

S21

S22

“History Connector”

S12_S3

S22S21

S1

E1

E2

E3

S2H

Functional Decomposition

• Functional decomposition breaks down complex systems into a hierarchical structure of simpler parts.

• Breaking a system into smaller parts enables users to understand, describe, and design complex systems.

• Functional decomposition consists of the following steps:

– Define the system context.

– This will help define the system boundaries.

– Describe the system in terms of high-level functions and their interfaces.

– Refine the high-level functions and partition them into smaller, more specific functions.

Functional Decomposition

Hierarchy Level 0(„Context-Diagram“)

External Data Sink

External Data Source

Hierarchical Structured Activity Chart

Bottom-Up

Top-Down

Hierarchy Level 1

Hierarchy Level 2

System Development and Validation with STATEMATE

closing the Loop via linear ‘Testbench Models’

System Validation: Generating Test-Data from Requirement Scenarios

(Waveform Diagram derived from Trace-File)

Operational Input Operational Output

Operational Input

Operational Output

Requirement 2

Requirement 1

Formal MethodsHome assignments: 11.2 What problems are associated with specifications written in natural language?

11.18 Explain what is meant by a 'schema' in Z, and describe its basic form.

Please email to herttua @uic.asso.fr by 27 of March 2008

References: I-Logix, KnowGravity,ITT


Recommended