Safety Critical Systems 4 Formal Methods Modelling

1
Safety Critical Systems 4Formal Methods /
Modelling

• T 79.5303

2
Formal Methods and Safety-Critical Systems

• Formal Methods are used in expressing
  requirements, design and analysis of a safety
  critical software and hardware.
• There exists a need for using formal methods from
  writing requirements to verifying the system
  fullfilling those.

3
(No Transcript)
4
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)

5
Semi-formal Requirements/Specification

• Requirements should be inambigious, complete,
  consistent and correct.
• Natural language has the intepretation
  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).

6

7
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 fucntions.
• VDM (Vienna Development Method) ISO
  standardisied.
• Z-language
• B-Method

8
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 varities of OBJ)

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

10
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

11
Formal Methods/ Z-language

• Z-language bases on first order predicate logic
  and set theory.
• The specification expressed in Z-notation is
  divived into smaller parts schemas
• These schemas describe the statical and
  dynamical characteritics of the system
• static possible states, invariants
• dynamic possible operations, pre/post states
• Z is an exellent tool for modelling data, state
  and operations

12
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?
• _________________________

13
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, eg by MATRA and (B Toolkit/UK)
• B-method uses Abstract Machine Notation (AMN)
  for specification and implementation.

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

15
Modeling Requirements

• Models needed for communicating with domain
  experts (simulation)
• Automatic verification (model checker, theorem
  proving)

16
Some Modeling Styles
17
Model Verification
18
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!

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

22
Statemate modeling

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

23
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
24
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.

25
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
26
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_eurolock.org by
• 23 of March 2006
• References I-Logix, KnowGravity