Safety Critical Systems 4 Formal Methods Modelling - PowerPoint PPT Presentation

About This Presentation
Title:

Safety Critical Systems 4 Formal Methods Modelling

Description:

dynamic: possible operations, pre/post states ... Theorem provers provide support for algebraic proofs of model properties ... – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 34
Provided by: CT5
Category:

less

Transcript and Presenter's Notes

Title: Safety Critical Systems 4 Formal Methods Modelling


1
Safety Critical Systems 4Formal Methods /
Modelling
  • T 79.5303

2
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.

3

4
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

5
(No Transcript)
6
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.

7
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).

8

9
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)

10
Formal Methods/ Model orientated
  • These languages involve the explicit
    specification of a state model - systems desired
    behaviour with abstract mathematical objects as
    sets, relations and functions.
  • VDM (Vienna Development Method ISO
    standardised).
  • Z-language
  • B-Method

11
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).

12
Formal Methods/Process orientated
  • Process algebras have been developed to meet the
    needs of concurrent systems.
  • Theories behind Hoares Communicating
    Sequential Processes (CSP) and Milners Calculus
    of Communicating Systems (CCS).
  • Protocol specification language LOTOS is based
    on combination of Act One and CCS.

13
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

14
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, invariants
  • dynamic possible operations, pre/post states
  • Z is an excellent tool for modelling data, state
    and operations

15
Simple example of Z notation
  • ___BirthdayBook_______
  • knownPNAME
  • birthday NAME ?? DATE
  • _____________________
  • known dom birthday
  • _____________________
  • ___AddBirthday________
  • ?BirthdayBook
  • name?NAME
  • date?DATE
  • _____________________
  • name? / known
  • birthday birthdayUname???date?
  • _____________________
  • ___FindBirthday____________
  • ?BirthdayBook
  • name?NAME
  • date!DATE
  • _________________________
  • name? known
  • date! birthday(name?)
  • _________________________
  • ___Remind________________
  • ? BirthdayBook
  • today?DATE
  • cards!PNAME
  • _________________________
  • cards!nknownbirthday(n)today?
  • _________________________

16
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.

17
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.

18
Modelling Requirements
  • Models needed for communication with domain
    experts (simulation)
  • Automatic verification (model checker, theorem
    proving)

19
Some Modeling Styles
20
Verification and Validation
  • Verification Are we building the system right?
  • Validation Are we building the right system?

21
Verified software process
22
Model Verification
23
Languages of Logic
  • Propositional LogicStatements
  • (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!

24
(Some) Languages of Logic
CTL
ERE?
Time G, F, H, P
Temporal Logic (LTL)
Worlds ?, ?
Modal Logic
DL
Predicate Logic
Objects ?, ?
Propositional Logic
25
Verification Technologies
26
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,

27
Statemate modelling
  • Based on Harel state charts from 80s
  • Functional decomposition
  • Used years in aviation and car industry
  • Mainly for simulating and validating
    functionality (Test cases)
  • Model checker for verification

28
Language of Statemate
Finite State Machines (FSM) A virtual machine
that can be in any one of a set of finite states
and whose next states and outputs are functions
of input and the current state.
History Connector
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 multiple processors or asynchronously
on a single processor.
IEEE
729
29
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.

30
Functional Decomposition
External Data Sink
Hierarchy Level 0 (Context-Diagram)
External Data Source
Top-Down
Hierarchy Level 1
Hierarchy Level 2
Bottom-Up
Hierarchical Structured Activity Chart
31
System Development and Validation with STATEMATE
closing the Loop via linear Testbench Models
32
System Validation Generating Test-Data from
Requirement Scenarios(Waveform Diagram derived
from Trace-File)
Operational Output
Operational Input
33
Formal Methods
  • Home 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 _at_uic.asso.fr by
  • 27 of March 2008
  • References I-Logix, KnowGravity,ITT
Write a Comment
User Comments (0)
About PowerShow.com