Table Of ContentCertifiable Software Applications 1
Certifiable Software
Applications 1
Main Processes
Jean-Louis Boulanger
First published 2016 in Great Britain and the United States by ISTE Press Ltd and Elsevier Ltd
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as
permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced,
stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers,
or in the case of reprographic reproduction in accordance with the terms and licenses issued by the
CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the
undermentioned address:
ISTE Press Ltd Elsevier Ltd
27-37 St George’s Road The Boulevard, Langford Lane
London SW19 4EU Kidlington, Oxford, OX5 1GB
UK UK
www.iste.co.uk www.elsevier.com
Notices
Knowledge and best practice in this field are constantly changing. As new research and experience
broaden our understanding, changes in research methods, professional practices, or medical treatment
may become necessary.
Practitioners and researchers must always rely on their own experience and knowledge in evaluating and
using any information, methods, compounds, or experiments described herein. In using such information
or methods they should be mindful of their own safety and the safety of others, including parties for
whom they have a professional responsibility.
To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any
liability for any injury and/or damage to persons or property as a matter of products liability, negligence
or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in
the material herein.
For information on all our publications visit our website at http://store.elsevier.com/
© ISTE Press Ltd 2016
The rights of Jean-Louis Boulanger to be identified as the author of this work have been asserted by him
in accordance with the Copyright, Designs and Patents Act 1988.
British Library Cataloguing-in-Publication Data
A CIP record for this book is available from the British Library
Library of Congress Cataloging in Publication Data
A catalog record for this book is available from the Library of Congress
ISBN 978-1-78548-117-8
Printed and bound in the UK and US
Introduction
This introduction is shared across the different volumes of this series on the
development of certifiable software applications.
Developing a software application is a difficult process that requires teamwork.
The complexity of software applications is ever increasing and the amount has grown
from a few tens of thousands to a few million. In order to be able to manage this
complexity, development teams are of significant importance. The involvement of
development teams in a software application, the internationalization of companies for
a better distribution of work teams (multisite companies, use of outsourcing, etc.) – all
these factors combined make it difficult to manage the complexity of a software
application.
The complexity of developing a software application is further intensified by
the race to obsolescence. The obsolescence of the hardware components entails
the implementation of specific strategies (saving equipment, repository of tool
sources, etc.) and mastering reproducibility and maintainability of the software
application.
Another challenge is the requirement to demonstrate the safety of a software
application. The demonstration of safety relies on the development of specific
techniques (diversity, redundancy, fault tolerance, etc.) and/or controlling defects in
the software application.
Even though the relationships related to systems and hardware architectures are
introduced in these volumes, only the software aspect shall be discussed in detail
[BOU 09].
xii Certifiable Software Applications 1
This book series is a concrete presentation of the development of a critical
software application. This approach is based on quality assurance as defined in ISO
9001 [ISO 08] and various industry standards such as DO 178 (aeronautics), IEC
61508 (programmable system), CENELEC 50128 (railway), ISO 26262
(automotive) and IEC 880 (nuclear). It must be noted that this book series is only a
complement to other existing books such as the one written by Ian Sommerville
[SOM 07].
Reader’s guide
Volume 1 is dedicated to the establishment of quality assurance and safety
assurance. The concept of a software application and the relationship with the
system approach are addressed here. This chapter, therefore, discusses the
fundamentals including the management of requirements.
Volume 2 describes the support processes, such as qualification tools,
configuration management, verification and validation. Volume 2 is essential to
understand what is necessary to develop a certifiable software application.
Volume 3 describes all the activities to be performed in the downward phase of
the V cycle to produce a version of the software application. Activities such as
specification, the establishment of an architecture and design of a software
application are discussed here. This volume concludes with the presentation of
production code of software application.
Volume 4 discusses the ascending phase of the V cycle along with a description
of various stages of testing (unit tests, modular tests, component testing, integration
tests and testing of the entire software) and various other associated tests. All these
activities lead to the production of a version of the software application.
Acknowledgments
This book is a compilation of all my work carried out with the manufacturers to
implement systems that are safe and secure for people.
1
System, Equipment and Software
1.1. Introduction
It is impossible to speak of software without referring to the system; in fact
software does not exist without at least one execution platform that involves
equipment and this equipment is integrated into a system. Contrary to popular belief,
software is seldom reusable, generic or independent.
Very often, only one of the listed properties of the software is related to its
independence with regard to the rest of the system; therefore, it may seem easy to
modify just this one property; however, this is a gross miscalculation, as a software
version is validated for a particular version of equipment and thus any change
requires revalidation and analysis of impacts with respect to the equipment and the
complete system.
The first chapter aims to put the software in the context of user equipment or
systems and thus to reiterate the relationships and constraints that must be taken into
account to develop a piece of software.
1.2. Impact on dependability
Automation of a number of command systems (railways, aerospace, automotive,
etc.) and/or process controls (production, etc.) and replacement of poorly-integrated
digital or analog systems (based on relay, for example) with high integration
systems have led to a considerable expansion in the field of system dependability
while taking into consideration the characteristics and specificities of computer
systems.
2 Certiffiable Software Applications 1
Depeendability [LAAP 92, LIS 96, VII 888] involves ffour characteeristics –
reliabilitty, availabilityy, maintainability and safeety (these conncepts are disccussed in
Chapter 3).
The system safetyy includes appplications which necessitate proper coontinuous
operationn, either due tto the human lives involveed (transport, nnuclear, etc.) or due to
the high investments at stake in thhe event of a calculation faailure (space, chemical
production process, eetc.), or even due to the cost of inconvvenience that could be
caused ddue to failurees (banking pprocess, reliabbility of transsport, etc.). Itt must be
noted thhat in recent years, there is also a coonsideration of the impacct on the
environmment.
Thouugh system saafety is an immportant subject which is allways at the fforefront,
the otherr three subjectts (RAM: Relliability, Availability and MMaintainabilityy) are just
as imporrtant and may require great efforts. Let’s take the exammple of mainteenance; it
is necesssary to provission for mainttenance from the time of designing (for example,
considerr dismantling capacity), aand continue maintaining the system until its
deactivattion. Deactivaation (Figure 11.1) does not mmean the remmoval of the syystem, but
decommmissioning folloowed by a commplete decommmissioning off all the systemm parts.
Figure 1..1. Lifecycle off a system
In the context of FFigure 1.1, thee maintenancee phase conceerns all the eleements of
the systeem. The softtware is a unnique componnent as it is quite easy too modify
and prodduce a new veersion, and it iis presumed tthat its mainteenance must bbe easy as
well.
System, Equipment and Software 3
Software maintenance requires skills (trained personnel), means (machines,
operating systems, tools, etc.), procedures and complete documentation of software
and sources.
From the early stages of study (Figure 1.1 – requirement analysis) of such
systems, the problems related to validation have always been a main concern of the
designer: proper designing of mechanisms enable to respond to failures, to verify
the design (simulations, tests, proofs, etc.) and to estimate, in a convincing manner,
the relevant magnitudes measuring dependability performances.
1.3. Command and control system
Figure 1.2 shows an example of a rail system. The Operation Control Centre
(OCC – top left picture1) allows control over the entire line and sends commands to
the trains as well as to the signaling management system (bottom left picture
represents a manual operation control center).
Figure 1.2. The system in its environment2
1 The top left photograph shows an old generation OCC (in this case, a drone), but the new
OCCs are designed based on the traditional PCs and have developed from using physical
technology (Optical Control Panel) to display lines using video projector.
2 Pictures by Jean-Louis Boulanger.
4 Certiffiable Software Applications 1
The ooperation conttrol center3 seends commandds to the field through a sett of relays
(bottom middle picturre shows an exxample of a rooom containinng the relays aassociated
with thee signaling). IIn response too the commannds, the field equipment adopts the
required behavior (botttom right phooto shows the operating signnals).
Figurre 1.2 introduuces the compplexity associaated with the concrete systeem and it
demonsttrates that a coomplex systemm is not basedd on software, but on equipmment that
contains one or more pieces of sofftware. Each oof these progrrams is associated with
safety obbjectives that ccan be differeent.
The ssoftware involved in supervvision activities does not haave as much iimpact on
the safety of people as the softwware related tto the automaated control of trains.
Thereforre, in the coontext of systtems requirinng certificatioon (aviation, railways,
nuclear, programmablle electronic bbased system, etc.), a safety level [BOUU 11b] is
associateed to each sofftware. This saafety level is aassociated witth a scale rangging from
non-critiical to high criticality. Thhe concept oof safety leveels and the scales are
discussed in Chapter 77.
Figurre 1.3 helps to identify thhat the systemm to be developed is relatted to an
environmment that reaccts to commannds. It is, therrefore, necessary to acquiree a vision
of the prrocess status tto control andd dispose conttrol means to send commannds to the
environmment.
Figure 1.3. System in its environment
3 The piccture shows a mmanual operatinng control centeer, but the operaating control ceenters have
been commputerized for oover several yeaars, and are refeerred to as PMII ([BOU 11a] CChapter 8),
PIPC andd PAING ([BOUU 09] Chapters 4 and 5).
System, Equipment and Software 5
The environment may consist of a physical element (motor, pump, etc.), but as a
rule, there is an interaction with humans (operators, users, maintenance operators,
etc.).
During the requirement analysis phase, it is essential to clearly identify all actors
(operator, maintenance worker, client, etc.) and all the elements that interact with the
system. The requirement analysis phase is essential and remains the source of many
lapses and misunderstandings [BOU 06]. The requirement analysis must be viewed
in relation to requirements engineering [BOU 14, HUL 05, POH 10]; Chapter 6
describes the management of requirements.
Figure 1.4 shows an example of modeling a control system of a railway crossing.
This system enables one to control the intersection of at least one road and a railway
track. The system interacts with different actors that include an OCC, road users
(truck, car, etc.), railway users (train, high-speed train, freight train, maintenance
train, etc.) and operators in charge of the operation and/or maintenance.
Figure 1.4. Example of system model in its environment
A class diagram [OMG 11, ROQ 06] has been used to model the fact that
Decentralized Radio Based Control System consists of a crossing which in itself is
constituted by a railway track and a road. For more information on this, and for a
more detailed presentation of the model developed and the methodology used, see
[BOU 07].
