(Slides) Software Requirements For Safety-Related Systems

Outline
Introduction
Development of the overall safety requirements
Verification
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
Verification
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
Verification
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
Verification
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
Verification
Software Process
Further readings
Realisation Phase

Outline
Introduction
Safety Lifecycle
Verification
Software Process
Further readings

Outline
Introduction
Safety Lifecycle
Verification
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 specification 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 specification 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 identification 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 identification 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 satisfies 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 specific reference to the specific 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 flow 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 verification 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 specified during

software design and consequentely documented;
software integration tests must be specified 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 specified

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 specified 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
Verification 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
Verification
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

(Slides) Software Requirements For Safety-Related Systems

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

(Slides) Software Requirements For Safety-Related Systems

Cargado por

Copyright:

Formatos disponibles

Outline

Software Requirements for

Vittorio Giovara Software Requirements for Safety-Related Systems

Creative Common Licence v3.0 Attribution - ShareAlike

You can read more about this licence here

Corrections, suggestions, contributions and

Document revision 1.0

Vittorio Giovara Software Requirements for Safety-Related Systems

Vittorio Giovara Software Requirements for Safety-Related Systems

These slides provide a schematical overview of the Functional

Vittorio Giovara Software Requirements for Safety-Related Systems

International Electrotechnical Commission

Vittorio Giovara Software Requirements for Safety-Related Systems

Vittorio Giovara Software Requirements for Safety-Related Systems

Vittorio Giovara Software Requirements for Safety-Related Systems

Software configuration management

appliance of administrative and technical controls

Vittorio Giovara Software Requirements for Safety-Related Systems

select and specify a safety lifecycle;

Vittorio Giovara Software Requirements for Safety-Related Systems

the software developer must consider the following:

Vittorio Giovara Software Requirements for Safety-Related Systems

all releveants modes of operation of the software must be

Vittorio Giovara Software Requirements for Safety-Related Systems

the software developer should consider the following:

Vittorio Giovara Software Requirements for Safety-Related Systems

the software safety requirements specification should

Vittorio Giovara Software Requirements for Safety-Related Systems

the planning for validating the software safety must

Vittorio Giovara Software Requirements for Safety-Related Systems

planning must be carried out to specify the steps, both

the planning for validating the software safety should

Vittorio Giovara Software Requirements for Safety-Related Systems

Vittorio Giovara Software Requirements for Safety-Related Systems

the design method must possess features that facilitate:

Vittorio Giovara Software Requirements for Safety-Related Systems

when the software is implemented with both safety and

Vittorio Giovara Software Requirements for Safety-Related Systems

a suitable set of integrated tools must be selected for the

Vittorio Giovara Software Requirements for Safety-Related Systems

the source code must:

each software module must be tested as specified during

Vittorio Giovara Software Requirements for Safety-Related Systems

depending on the nature of the software development,

the coding standards should be reviewed and used for the

the validation activities must be carried out as specified

the software must be exercised by a simulation of:

Vittorio Giovara Software Requirements for Safety-Related Systems

if the compliance with the requirements for sofware safety

The objective of the requirements of this part is, to the extent

Vittorio Giovara Software Requirements for Safety-Related Systems

the software verification planning must refer to criteria,

after specifying the software system design, verification

Vittorio Giovara Software Requirements for Safety-Related Systems

the verification of software must be planned concurrently

Vittorio Giovara Software Requirements for Safety-Related Systems

evidence should be documented to show that the phase

after each verification, the correspondent documentation

Vittorio Giovara Software Requirements for Safety-Related Systems

Please see as reference

Original document localized at

Vittorio Giovara Software Requirements for Safety-Related Systems

También podría gustarte