1. Safety-Critical Systems 4 Formal Methods / Modelling

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.
Formal Methods should be part of education of every computer scientist and software engineer, just as the appropriate branch of applied maths is a necessary part of the education of all other engineers. – John Rushby (FAA/NASA)

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.  Domain Expert(s) Text Validation Consistency Implement. Validation
Verification
(Testing)
Consistency
Validation
Model
Informal
Verification
Consistency
(another) Model 
Formal
Verification

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

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_______
known:PNAME
birthday: NAME ‌→ DATE
_____________________
known = dom birthday
___AddBirthday________
∆BirthdayBook
name?:NAME
date?:DATE
name? /€ known
birthday’ =birthdayU{name?‌→date?}
___FindBirthday____________
ΞBirthdayBook
name?:NAME
date!:DATE
_________________________
name?€ known
date! = birthday(name?)
___Remind________________
Ξ BirthdayBook
today?:DATE
cards!:PNAME
cards!={n:known|birthday(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 versus Decomposition: versus  View point:
Functional
Object-based
Decomposition:
versus 
Black Box
Glass Box
View point:
versus
Textual
Blabla 
GFHP 
Graphical
Representation:
versus

17. Tools for Validation & Verification
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, …

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

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

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

21. Language of Statemate Finite State Machines (FSM): S1 S2 Hierarchy:
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. S1 S2 E1 E2
“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.
S12_S3
S22
S21 S1 E1 E2 E3 S2 H
S1_S2 E1 E2 F1 F2 S1 S2
S11
S12
S21
S22
Concurrency:
“Processes that may execute in parallel on multiple
processors or asynchronously on a single processor.”
IEEE 729

22. Formal Methods Home assignments: 11.2 Textual specification
Z-language
Please to by
5 of April 2005
References: I-Logix, KnowGravity