Software Requirements for Safety-related Systems

Outline
Introduction
Development of the overall safety requirements
Veriﬁcation
Further readings

Software Requirements for
Safety-Related Systems

Vittorio Giovara

Politecnico di Torino

Software Engineering

16/04/2008

Vittorio Giovara Software Requirements for Safety-Related Systems

Outline
Introduction
Veriﬁcation
Further readings

Creative Common Licence v3.0 Attribution - ShareAlike
You are free
to copy, distribute, display, and perform the work
to make derivative works
to make commercial use of the work
Under the following conditions
Attribution. You must give the original author credit.
Share Alike. If you alter, transform, or build upon this work,
you may distribute the resulting work only under a license
identical to this one.
For any reuse or distribution, you must make clear to oth-
ers the license terms of this work.
Any of these conditions can be waived if you get permission from
the copyright holder.

Outline
Introduction
Veriﬁcation
Further readings

You can read more about this licence here
http://creativecommons.org/licenses/by-sa/3.0/

Corrections, suggestions, contributions and
translations are welcome!

Document revision 1.0


Outline
Introduction
Verification
Further readings

1 Introduction
The International Electrotechnical Commission
Safety Lifecycle
Software Process
2 Development of the overall safety requirements
Overview
Specification
Planning
Design and Development
Validation
3 Verification
Objective
Functional Requirements
Non-functional requirements
4 Further readings


Outline
Introduction
Safety Lifecycle
Veriﬁcation
Software Process
Further readings

IEC-61508

These slides provide a schematical overview of the Functional
and non-Functional Requirements for software programs
adherent to the IEC- 61508 standard for safety-related software
systems.


Outline
Introduction
Safety Lifecycle
Verification
Software Process
Further readings

What is IEC?

International Electrotechnical Commission
The IEC is a not-for-profit, non-governmental international standards
organization that prepares and publishes International Standards for
all electrical, electronic and related technologies - collectively known
as electrotechnology. IEC standards cover a vast range of
technologies from power generation, transmission and distribution to
home appliances and office equipment, semiconductors, fibre optics,
batteries, solar energy, nanotechnology and marine energy as well as
many others. The IEC also manages conformity assessment
schemes that certify whether equipment, systems or components
conform to its International Standards. The IEC publishes standards
with the IEEE and develops standards jointly with the ISO as well as
the ITU.

Outline
Introduction
Safety Lifecycle
Veriﬁcation
Software Process
Further readings

Realisation Phase


Outline
Introduction
Safety Lifecycle
Veriﬁcation
Software Process
Further readings


Outline
Introduction
Safety Lifecycle
Veriﬁcation
Software Process
Further readings

The V model


Outline Overview
Introduction Specification
Development of the overall safety requirements Planning
Verification Design and Development
Further readings Validation

Software configuration management

appliance of administrative and technical controls
throughout the software safety lifecycle;
guarantee of achievement of all the required software
safety rules;
mantainance of all the configuration items for the saftety
related system;
documentation of formal releases.


Outline Overview

Lifecycle requirements

select and specify a safety lifecycle;
integrate safety and quality assurance procedures into
lifecycle activities;
divide into elementary activities every phase, specifying
scope, inputs and outputs for each phase;
use appropriate techniques and measures for each
lifecycle phase;
document the results of each activity of the software safety
lifecycle;
repeat any previous phase if a phase is changed in the
software safety lifecycle.


Outline Overview


the software developer must consider the following:
1 safety functions;
2 configuration or architecture of the system;
3 hardware safety integrity requirements;
4 software safety integrity requirements.
the specified requirements for software safety must be
expressed and structured so that they are:
1 clear, precise, unequivocal, verifiable, testable, mantainable
and feasable, commensurate with the safety integrity level;
2 traceable back to the specification of the safety
requirements of the safety-related system;
3 free of terminology and description which are ambiguous
and/or not understood by those who will utilize the
document at any stage of the software safety lifecycle.


Outline Overview

all releveants modes of operation of the software must be
detailed in the specified requirements for software safety;
the software requirements specification must specify and
document any safety-related or relevant constraints
vetween the hardware and the software;
the software safety requirements specification must
express the required safety properties of the product, but
not of the project.


Outline Overview

Non-Functional Requirements

the software developer should consider the following:
1 capacity and response time performance;
2 equipment and operator interfaces.
the speciﬁcation of the requirements should be detailed to
allow following phases to achieve the required safety
integrity;
the software developer should establish procedure for
resolving any disagreeents over the assignment of the
software safety integrity level;
when the system is perfoming non-safety functions, the
software requirements should clearly identify the running
functions;


Outline Overview

the software safety requirements speciﬁcation should
consider the following:
1 software self-monitoring;
2 monitoring of the programmable electronics hardware,
sensors and actuators;
3 periodic testing of safety functions while the system is
running;
4 enabling saftey functions to be testable when the software
is operational.


Outline Overview


the planning for validating the software safety must
1 identiﬁcation of the relevant modes of the software
requirement operation, including:
- preparation for use including setting and adjustment;
- start up; teach; automatic; manual; semi-automatic; steady
state of operation;
- re-setting; shut down; mantainance;
- reasonably foreseeable abnormal conditions.
2 identiﬁcation of the safety-related software which needs to
be validated for each mode of operation before
commissioning commences;
3 the pass/fail criteria;
4 the policies and procedures for evaluating the results of the
validation, particularly failures;


Outline Overview

planning must be carried out to specify the steps, both
procedural and technical, that will be used to demonstrate
that the software satisﬁes its saftey requirements;
the technical strategy for the validation of safety-related
software must include the following information:
1 choice of manual or automated techniques or both;
2 choice of static or dynamic techniques or both;
3 choice of analytical or statistical techniques or both;
the pass/fail criteia for accomplishing software must
include:
1 the required input signals with their sequences and their
values;
2 the anticipated output signals with their sequences and
their values;
3 other acceptance criteria (like memory usage, timing and
value tolerance).

Outline Overview


the planning for validating the software safety should
1 details of when the validation shall take plaace;
2 details of those who will carry out the validation;
3 the technical strategy for the validation;
4 speciﬁc reference to the speciﬁc requirements for software
safety;
5 the required environment in which the validation activities
are to take place.


Outline Overview

Objectives
- create a software architecure that fulfils the specified
requirements for the software safety with respect to the required
safety integrity level;
- review and evaluate the requirements placed on the hardware
architecture of the safety-related system;
- select a suitable set of tools, like languages and compilers for
the required integrity level;
- design and implement software that fulfils the specified
requirements for the software safety with respect to the required
safety integrity level, which is capeable of being safely modified;
- verify that the requirements for software safety have been
achieved.


Outline Overview


the design method must possess features that facilitate:
1 abstraction, modularity and other features to control
complexity;
2 the expession of:
- functionality
- information ﬂow betwwn components
- sequencing and time related information
- timing constraints
- concurrency
- data structures and their properties
- design assumptions and their dependencies
3 comprehension by developers and others who need to
understand the design;
4 veriﬁcation and validation;


Outline Overview

when the software is implemented with both safety and
non-safety functions, then all of the software must be
treated as safety-related;
when the software is implemented with safety functions of
different safety integrity levels, then all of the software must
be treated as belonging to the highest safety integrity level;
the software design must include (accordingly with the
safety integrity level) self-monitoring of control flow and
data flow; on failure detection appropriate actions must be
taken;
if standard or previously developed software is used in the
design phase, then it must be clearly identified and respect
the requirements of the current system;


Outline Overview

a suitable set of integrated tools must be selected for the
required safety integrity level; such tools include:
- languages
- compilers
- configuration
- management tools
- automatic testing tools (when applicable)
the programming language chosen for the desing must:
1 have a translator/compiler with a certificate validation to a
recognised national or internation standard;
2 be completely and unambiguously defined or restricted to
clearly defined fetures;
3 match the characteristics of the application;
4 contain features that facilitate the detection of programming
mistakes;
5 support features that match the design method.


Outline Overview

the source code must:
1 be readable, understandable and testable;
2 satisfy the specified requirements for software module
design;
3 satisfy the specified requirements of the coding standards;
4 satisfy all relevant requirements specified during safety
planning.
the specified software integration tests must specify the
following:
1 the division of the software into manageable integration
sets;
2 tests cases and test data;
3 types of tests to be perfomed;
4 test environment, tools, configuration and programs;
5 test criteria on which the completion of the test will be
judged;
6 procedures for corrective action on failure of test.

Outline Overview

each software module must be tested as speciﬁed during
software design and consequentely documented;
software integration tests must be speciﬁed concurrently
during the design and development phase.


Outline Overview


depending on the nature of the software development,
responsibility for conformance with software design
requirements can rest with the supplier alone or with the
user alone or with both; the division o responsability should
be determined during safety planning;
testability and the capacity for safe modification should be
considered during the design activities in order to facilitate
implementation of these properties in the final system;
software modification should be allowed with modularity,
information hiding or encapsulation;
the design should include software functions to execution
proof test and all diagnostic tests;
each module of software code should be reviewed;

Outline Overview

the coding standards should be reviewed and used for the
development of all safety-related software;
the coding stardards should specify good programming
practice, proscribe unsafe language features and specify
procedures for source code documentation;
appropriate software system integration tests should be
specified to ensure that the software systems satisfies the
specified requirements safety;
the result of software integration testing should be
documented, stating the test results and whether the
objectives and criteria of the test have been met;
in software integration, any modification or change to the
software should be subject to an impact analysis in order
to determine the impact on the other sofware modules and
the necessary re-verification and re-design activities.

Outline Overview


the validation activities must be carried out as speciﬁed
during sofware safety validation planning;
the result of software safety validation must be
documented and mad available, outlining:
1 a chronological record of the validation activities;
2 the version of the software safety validation plan being
used;
3 the safety function being validated, together with reference
to the software afety validation plan;
4 tools and equipment used together with calibration data;
5 the results of the validation activity;
6 discrepancies between expected and actual results.
testing must be the main validation method for software;
animation and modelling may be used to supplement the
validation activities;

Outline Overview

the software must be exercised by a simulation of:
1 input signals present during normal operation;
2 anticipated occurrences;
3 undesired condtion requiring system action.
all equipment used for validation must be qualified
according to a specification traceable to an internatation or
national standard;
equipment used for validation must be qualified
appropriately and any tools used (hardware or software)
must be proved suitable for the purpose.


Outline Overview


if the compliance with the requirements for sofware safety
has already been established, then the validation shouldn’t
be repeated;
when discrepancies occur between expected and actual
results, the analysis made and the decisions taken should
be documented as part of the results of the software safety
validation;
the tests should show that all the speciﬁed requirements
for software requirements are correctly performed and the
software system doesn’t preform unintended functions;
the documentated results should state either that the
software has passed the validation or the reason for its
failure.

Outline
Introduction Objective
Development of the overall safety requirements Functional Requirements
Veriﬁcation Non-functional requirements
Further readings

The objective of the requirements of this part is, to the extent
required by the safety integrity level, to test and evaluate the
outputs from a given software safety lifecycle phase to ensure
correctness and consistency with respect to the outputs and
standards provided as input to that phase.


Outline
Further readings

the software verification planning must refer to criteria,
techniques and tools addressing
1 the evaluation of the safety integrity requirements;
2 the section and documentation of verifiaction strategies,
activities and techniques;
3 the selection and utilisation of verification tools;
4 the evaluation of verification results;
5 the corrective actions to be taken.
after specifying the software safety requirements,
verification must
1 consider whether the specified requirements adequately
fulfil the requirements for functionality, safety integrity and
any other requirements for safety planning;
2 consider whether the software safety validation planning
adequately fulfils the specified software requirements.
3 check for incompatibilies between the specified safety
requirements and the software validation planning.

Outline
Further readings

after specifying the software system design, verification
must
1 consider whether the specified tests for integrtion
adequately fulfil the specified software system design;
2 consider whether the attributes of each major component of
the specified software system design are adequate with
respect to
- feasability for further verification
- testability for further verification
- readability by the development and verification team
- safe modificiation to permit further evolution
3 check for incompatibilies between the description of the
software system design and the specified tests of the
software system integration;


Outline
Further readings

the verification of software must be planned concurrently
with the development for each pahse of the software safety
lifecycle and this infomration shall be documented;
the verification activities must include:
1 verification of software safety requirements;
2 verification of software architecture;
3 verification of software system design;
4 verification of software module design;
5 verification of code;
6 data verification;
7 software module testing;
8 software integration testing;
9 programmable electronics integration testing;
10 software safety requirements testsing (validation).


Outline
Further readings

evidence should be documented to show that the phase
being verified has completely been satisfied;
all essential information from each phase of the software
safety lifcycle need for execution of the following phase
should be available and verofied; outputs include:
1 adequacy of the specification, design description or code in
the current phase for:
- functionality
- safety integrity
- performance
- readability by the development team
- testability for further verification
- safe modificiation to permit further evolution
2 adequacy of the validation planning and/or tests specified
for the current phase;
3 check for incompatibilies between the tests specified in the
current and the previouse phase and the outputs within the
current phase.

Outline
Further readings

after each verification, the correspondent documentation
should include:
1 identification of items to be verified;
2 identification of the information against which the
verification has been done;
3 non conformances.
the source code should be verified by static methods to
ensure conformance to the specified design of the
software module, the requred coding standards and the
requirements of safety planning.


Outline
Introduction
Veriﬁcation
Further readings

Please see as reference
http://www.iec.ch/
http://en.wikipedia.org/wiki/Standards_
organization
International Standard, IEC 61508, Functional safety of
electrical/electronic/programmable electronic safety-related
systems, Part 3, First edition, 1998

Original document localized at
http://www.scribd.com/people/view/59403


Software Requirements for Safety-related Systems

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (18)

Similaire à Software Requirements for Safety-related Systems

Similaire à Software Requirements for Safety-related Systems (20)

Plus de Vittorio Giovara

Plus de Vittorio Giovara (12)

Dernier

Dernier (20)

Software Requirements for Safety-related Systems