Transcript Safety-Critical Systems

Safety Critical Systems 4
Formal Methods / Modelling
T 79.5303
Formal Methods
Formal methods have been used for safety and securitycritical 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)
Validation
Validation
Validation
Text
Informal
Verification
Consistency
Model
Formal
Verification

Verification
(Testing) Implement.
Consistency
(another) Model
Consistency
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, invariants
dynamic: 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________
∆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?}
_________________________
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
versus
Decomposition:
Functional
Object-based
versus
View point:
Black Box
Glass Box
Representation:
Blabla

GFHP

Textual
versus
Graphical

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.“
Requirements
Modeling
Language
Verification
RequirementsSupport Tool
Model

Challenger
Domain Expert
Proof
Verifier
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!!!
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
S
S
S
t
S
t
S
S S
S
•Note: The list above is neither complete nor it does necessarily imply any
hierarchy!
t
(Some) Languages of Logic
CTL
ERE?
Time
G, F, H, P
Temporal
Logic
(LTL)
Modal
Logic
Propositional
Logic
Worlds
, 
DL
Objects
, 
Predicate
Logic
Verification Technologies
Model Checking
Theorem Proving
CTL
ERE?
Time
G, F, H, P
Temporal
Logic (LTL)
Worlds
, 
Moda
l
Logic
Propositiona
l
Logic
D
L
Objects
, 
Predicate
Logic
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):
E1
S1
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.
S2
E2
“History Connector”
Hierarchy:
S12_S3
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.
S1
E3
S2
E1
S21
H
S22
E2
S1_S2
Concurrency:
“Processes that may execute in parallel on multiple
processors or asynchronously on a single processor.”
IEEE 729
S1
S2
S11
E2
S12
E1
S21
F2
S22
F1
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
External Data
Source
External Data
Sink
Hierarchy Level 0
(„Context-Diagram“)
Top-Down
Hierarchy Level 1
Hierarchy Level 2
Bottom-Up
Hierarchical Structured Activity Chart
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
Requirement 2
Requirement 1
Operational Input
Operational Output
Operational Output
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 @uic.asso.fr by
27 of March 2008
References: I-Logix, KnowGravity,ITT