ISO/TR 15497:2000

TECHNICAL ISO/TR
REPORT 15497
First edition
2000-11-01
Road vehicles — Development guidelines
for vehicle based software
Véhicules routiers — Guide pour le développement de logiciels installés à
bord de véhicules
Reference number
©
ISO 2000
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2000 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of technical committees is to prepare International Standards. Draft International Standards adopted
by the technical committees are circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting a vote.
In exceptional circumstances, when a technical committee has collected data of a different kind from that which is
normally published as an International Standard ("state of the art", for example), it may decide by a simple majority
vote of its participating members to publish a Technical Report. A Technical Report is entirely informative in nature
and does not have to be reviewed until the data it provides are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this Technical Report may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TR 15497 was prepared by the United Kingdom Motor Industry Software Reliability Association (MISRA) as
guidelines published in 1994, and was adopted (without modifications except those stated in clause 2 of this
International Standard) by Technical Committee ISO/TC 22, Road vehicles,Subcommittee SC3, Electrical and
electronic equipment.
Road vehicles — Development guidelines for vehicle based
software
1 Scope
This Technical Report provides safety-related guidelines for the development of vehicle based software.
2 Recommendations
The technical recommendations are those made in the following publication (reproduced on the following pages),
which is adopted as a Technical Report:
Development Guidelines for Vehicle Based Software, Motor Industry Software Reliability Association (MISRA),
United Kingdom, 1994.
For the purposes of international standardization, the modifications outlined below shall apply to the specific clause
and paragraphs of the MISRA publication.
Page i to iv (of the MISRA publication)
This is information relevant to the MISRA publication only.
Page 73-75
Clause 6
Substitute the following for the corresponding references.
[10] ISO 9001, Quality systems — Model for quality assurance in design, development, production, installation and
servicing.
1)
[15] ISO 11748 (all parts) — , Road vehicles —— Technical documentation of electrical and electronic systems.
[25] ISO 11898, Road vehicles — Interchange of digital information — Controller area network (CAN) for high-
speed communication.
[26] ISO 11519 (all parts), Road vehicles — Low-speed serial data communication.
[29] ISO 14230 (all parts), Road vehicles — Diagnostic systems — Keyword Protocol 2000.
Insert the following reference.
[24] EMC standards and technical reports applicable to road vehicles:
ISO 7637 (all parts), Road vehicles — Electrical disturbance by conduction and coupling ;
ISO /TR 10305, Road vehicles — Generation of standard EM field for calibration of power density meters from
20 kHz to 1 000 MHz ;
ISO/TR 10605, Road vehicles — Electrical disturbances from electrostatic discharge ;
1) To be published.
iv © ISO 2000 – All rights reserved

ISO 11451 (all parts), Road vehicles — Vehicle test methods for electrical disturbances by narrowband
radiated electromagnetic energy ;
ISO 11452 (all parts), Road vehicles — Component test methods for electrical disturbances by narrowband
radiated electromagnetic energy.
3 Revision of the MISRA publication
It has been agreed with the Motor Industry Software Reliability Association that ISO/TC 22/SC 3 will be consulted
in the event of any revision or amendment of the MISRA publication. To this end, the British Standards Institution
(BSI) will act as a liaison body between MISRA and ISO.
CV10 0TU
All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system or transmitted in any form or by any means, electronic, mechanical or
photocopying, recording or otherwise without the prior written permission of the
ISBN 0 9524156 0 7
vi © ISO 2000 – All rights reserved
A catalogue record for this book is available from the British Library.
British Library Cataloguing in Publication Data.
Publisher.
© The Motor Industry Research Association, 1994, 2000
http://www.misra.org.uk
Warwickshire
Nuneaton
Watling Street
by The Motor Industry Research Association
First published November 1994
The Motor Industry Software Reliability Association
Soft ware
i
November 1994
Vehicle Based
For
Guidelines
Development
Foreword
of Trade and Industry and the Engineering and Physical Sciences Research Council, I am pleased
In this programme we have been concerned to ensure that the results of research should not be
therefore sought the involvement of user organizations so that the work based on an
understanding of their real industrial needs, and so that the results will be credible to their peers.
The MISRA Study, with its combination of vehicle and equipment manufacturers, has admirably
The voluntary nature of the guidelines is important. They were produced voluntarily, for the
benefit of both the industry and the public. Their adoption will also be voluntary. This has
encouraged the MISRA consortium to develop guidelines which offer genuine benefits for their
The renowned cost-consciousness of the automotive industry might be thought by some to
diminish its contribution to technological development. On the contrary: while this industry is
properly cautious in the interests of safety, the fiercely competitive market and the public
exposure of any problems ensures that the commercial value of new technology is thoroughly
evaluated. This sector is a hard proving-ground for technology. So, while many of the issues on
which the MISRA consortium has concentrated are specific to vehicles, other sectors might do
ii
viii © ISO 2000 – All rights reserved
DTI-EPSRC Safety Critical systems
Bob Malcolm
well to see what they might glean from the trends here.
users, rather than burdensome restrictions.
realized that ambition.
buried in learned papers, but promulgated in ways which will affect practice in industry. We have
to support the publication of these guidelines.
As coordinator of the Safety Critical Systems Research Programme, supported by the Department

(continued)
Foreword
The motorist gains many benefits, including enhanced safety features, from advances in vehicle
The development of software is a specialized and often complex area where much relies on an
effective approach by those directly involved. I welcome MISRA’s initiative and efforts in
developing these safety related guidelines and advice under a joint DTI, EPSRC and industry
funded programme. The guidelines reflect a responsible and serious industry attitude to safety
Department of Transport
The use of electronic systems in vehicles has increased significantly over recent years and will
continue to increase. Much time and resources are being committed by vehicle manufacturers to
sources.
The vehicle owner expects his vehicle to be reliable and safe, and this includes the electronic
systems. Electronic systems are dependent on the software provided by the manufacturer. The
greater complexity of such systems is increasing the need to maintain software quality and
reliability. This has resulted in the need for a unified approach to software design. It is therefore
pleasing that an independent group has produced these guidelines on vehicle-based software
K B Barnes
iii
SMMT
Head of Engineering
which will be of benefit to the Motor Industry and also more importantly the motorist.
deal with the compatibility of such systems in particular the problem of interference from external
Chief Mechanical Engineer
BSc CEng FIMechE Malcolm Fendick
issues.
electronics.
Acknowledgements
The MISRA consortium would like to thank the following organizations for their support of the
AP Borg & Beck
Department of Transport
Ford Motor Company Ltd
Jaguar Cars Ltd
(C)
Rover Group Ltd
(C)
(PM, C)
The Society of Motor Manufacturers and Traders Ltd
(C)
Key
C
The MISRA consortium would like to thank the following individuals for their contributions to
Roger Rivett
Heather Storey
Ian Stothers
iv
x © ISO 2000 – All rights reserved
Marco Zasiura Dave Newman John Fox
Anthony Wood Tony Moon Simon Farrall
Brian Whitfield Tom Monk Paul Edwards
David Ward Josh McCallin Nick Dunn
Lloyd Thomas Chris Marshall John Comfort
Paul Manford Tom Buckley
Keith Longmore Colin Bowles
Chris Shakespeare Ian Kendall Nick Bennett
Steve de la Salle Edward Jones Terry Beadman
Peter Jesty Nigel Barrett
Mike Radford Keith Hobley Neil Andrewartha
Dave Perry Nick Heatley Klaus Allen
Frank O’Neill Vivien Hamilton Alex Abbot
these Guidelines:
consultant
project manager PM
controlling member of the MISRA consortium CM
The University of Leeds
The Motor Industry Research Association
The Centre for Software Engineering Ltd
(CM)
Rolls-Royce and Associates Ltd
(CM) Lucas Electronics
(CM) Lotus Engineering
(CM)
(CM)
Department of Trade and Industry
(CM) Delco Electronics
(CM)
(CM) AB Automotive Electronics Ltd
study that produced these Guidelines:

Contents
1. Introduction 1
................................ ................................ ................................ ..........
1.1 1
................................ ................................ ......
1.2 1
................................ ................................ ................
1.3 1
................................ ................................ .......................
1.4 2
................................ ................................ ................................ .........
1.5 3
................................ ................................ ..........
1.5.1 Scope 3
................................ ................................ ................................ .....
1.5.2 3
................................ ................................ ................................ .......
1.6 5
................................ ................................ ..........................
2. 7
................................ ................................ ................................ ......
2.1 7
................................ ................................ ................................ ..........
2.2 7
................................ ................................ .............................
3. 8
................................ ................................ ................................ ........
3.1 8
................................ ................................ ................................ ...
3.1.1 8
................................ ................................ ....................
3.1.2 9
................................ ................................ ........................
3.1.3 9
................................ ...................
3.1.4 13
................................ ................................ .............................
3.1.5 14
................................ ................................ ................................ .....
3.2 14
................................ ................................ ................................ ..........
3.2.1 Introduction 14
................................ ................................ ............................
3.2.2 15
................................ ................................ ........................
3.2.3 18
................................ ..............................
3.2.4 19
................................ ................................ ........
3.3 22
................................ ................................ ...................
3.3.1 22
................................ ................................ ......
3.3.2 25
................................ ................................ ..........
3.3.3 28
................................ .................
3.3.4 30
...............................
3.3.5 32
................................
3.4 33
................................ ................................ ................................ ..........
3.4.1 33
................................ ................................ .............
3.4.2 36
................................ ................................ .........
3.4.3 37
................................ ................................ ...............................
3.4.4 38
................................ ...........................
3.4.5 38
................................ ...........................
3.4.6 41
................................ ................................ ..............
3.4.7 43
................................ ................................ .......................
3.4.8 43
................................ ................................ ...................
3.4.9 45
................................ ......................
3.4.10 46
................................ ..............................
v
Tools and techniques for design
Design for verification and validation
Fault management
System security
On-board diagnostics
Communications and multiplexing
Optimization and adaptive control
Modelling
Floating point arithmetic
Real-time implications
Design
Tools and techniques for requirements specification
Verification and validation of software requirements
magnetic compatibility Noise and electro
Vehicle control systems
Whole vehicle architecture
Requirements specification
Development approaches
Human factors in safety analysis
Safety analysis
Integrity
Reuse
Assessment
Planning for verification and validation
Lifecycle plans
Project definition
Project planning
Software lifecycle
List of abbreviations
Definitions
Definition of terms
Fundamental concepts
Uses
Scope and uses of the Guidelines
Background
The MISRA consortium
omer Benefits to the end cust
Statement of mission and objectives
Page
Contents (continued)
3.5 47
................................ ................................ ................................ .......
3.5.1 47
................................ ................................ ....................
3.5.2 48
................................ ..........................
3.5.3 48
................................ ..........................
3.6 49
................................ ................................ ................................ ..........
3.6.1 49
................................ ................................ ................................ ...
3.6.2t 49
................................ ................................ ...........................
3.6.3 Integration test 49
................................ ................................ .......................
3.6.4 51
................................ ................................ .............................
3.6.5 51
................................ ..............................
3.7 Product support 52
................................ ................................ ................................ ...
3.7.1 52
................................ ................................ .............
3.7.2 53
................................ ................................ .............
4. 55
................................ ................................ ............................
4.1 55
................................ ................................ .................
4.2 56
................................ ................................ .....................
4.3 56
................................ ...............................
4.3.1 Introduction 56
................................ ................................ ............................
4.3.2 57
................................ .........................
4.3.3 57
................................ .......................
4.3.4 nt 58
................................ ................................ .......
4.3.5 58
................................ ................................ .......
4.4 59
................................ ................................ .................................
4.4.1 59
................................ ................................ ....
4.4.2 59
................................ ................................ ...............................
4.4.3 59
................................ ................................ ......
4.4.4 60
................................ ................................ .....
4.4.5 60
................................ ................................ ........
4.5 62
................................ ................................ ................
4.6 63
................................ ................................ ................................ .....
4.6.1 Introduction 63
................................ ................................ ............................
4.6.2 63
................................ ................................ ..............................
4.6.3 65
................................ ................................ .........
4.6.4 67
................................ ................................ .....
5. 70
................................ ................................ ................................
5.1 70
................................ ................................ ................................ ..........
5.2 70
................................ ................................ ................................ ...
5.3 71
................................ ................................ .................................
5.4 71. . . .
5.5 72
................................ ................................ ..............
6. 73
................................ ................................ ................................ ..........
7. 76
................................ ................................ ................................ ..........
vi
xii © ISO 2000 – All rights reserved
Index
References
Formal mathematical methods
Fuzzy logic
Object orientation
rks Neural netwo
General
Emerging technologies
Commercial considerations
Technical considerations
Definitions
Subcontracting
Documentation requirements
Software process metrics
Changes during production
Assessment of compliance
Checklists
Standards and accreditation
Quality assurance
The physical environment
Human error manageme
Individual differences and job design
Teams and organizational structure
Human factors in software development
Education and experience
sponsibilities Management re
Software quality planning
Software maintenance
Off-board diagnostics
Tools and techniques for testing
System test
Dynamic tes
General
Testing
Programming tools and techniques
Verification and validation of code
Codes of practice
Programming
TECHNICAL REPORT ISO/TR 15497:2000(E)

1.1.1The purpose of these Guidelines is to provide assistance to the automotive industry in the
1.1.2ere has been much recent growth in the quantity and complexity of electronic controls
on motor vehicles. The greater the complexity, the harder it is to maintain the software
quality and reliability the customer has come to expect. A unified approach to software
development, using agreed techniques, is desirable across the automotive industry. This
will enable the driver or owner to have continued confidence in complex electronic
1.2
1.2.1exposure to software in applications with safety implications is increasing. It
may be through vehicles that the majority of the public will encounter such software.
1.2.2The record of the automotive industry in regard to software is good. The application of
1.3
1.3.1The MISRA consortium was formed in response to the UK Safety Critical Systems
Research Programme, supported by the Department of Trade and Industry and the
Engineering and Physical Sciences Research Council, and consisted of eight controlling
1.3.2The consortium initially conducted a survey of existing work, both in the automotive
1.3.3The consortium then formed eight subgroups to research specific issues relati ng to
· ·
·
· ·
· ·
·
software in control systems
human factors in software development. noise, EMC and real-time
subcontracting of automotive software integrity
verification and validation
systems
software metrics diagnostics and integrated vehicle
automotive software:
sector and in other industrial sectors.
members, four consultants and a project manager (see Acknowledgements page).
The MISRA consortium
in its products as the complexity increases.
these Guidelines will maintain the industry’s confidence in the quality of the software used
Therefore, it is vital that such software is both correct and perceived to be correct.
The public
Benefits to the end customer
systems.
Th
creation and application within a vehicle system of safe, reliable software.
Statement of mission and objectives 1.1
1. Introduction
(continued)
Introduction
1.3.4Each group produced a report [1]–[8] that provides more detailed supporting information,
1.3.5
1.3.6The eight reports and the survey report are available separately [1]–[9]. These reports
provide additional background, more detailed recommendations and additional references
1.3.7For the sake of brevity, the Guidelines do not always justify recommendations. The eight
1.4
1.4.1There are impor tant differences between software and other forms of automotive
(a)
(c)
(d)
(e)
1.4.2
sectors:
(a) Production volumes are high (leading to manufacturing variation), related
mechanical components are subject to wear and maintenance levels are difficult to
Passenger car drivers receive little or no training compared with other users of
computer-based products and services. Therefore automotive software requires an
emphasis on failure management techniques based on the controllability of the
(c)
as simulations. These are available to test systems and software extensively and
2 © ISO 2000 – All rights reserved
safely before they reach the customer.
Traditional automotive test environments use real vehicles and components, as well
vehicle.
(b)
parameter optimization, adaptive control and on-board diagnostics.
assure. Therefore automotive software has an emphasis on data driven algorithms,
in other industrial There are differences between automotive applications and applications
It is intangible.
Software errors are systematic, not random.
It is perceived to be easy to change.
It has a much greater capacity to contain complexity. (b)
ageing aspects.
Software is primarily a design, with no manufacturing variation, wear, corrosion or
engineering and components:
Background
reports [1]–[8] contain the background material and justifications where appropriate.
that will be invaluable to the specialists in the field.
The results of the survey were continually updated throughout the study [9].
and recommendations that have been incorporated into these Guidelines.

(continued)
Introduction
1.5
1.5.1
1.5.1.1The boundaries between software and system design are not precise and there are many
interrelated aspects. These Guidelines take a broad view of software, recognizing that
many concerns attributed to software reliability are as much systems issues as they are
1.5.1.2The Guidelines make recommendations on system issues that are considered to influence
1.5.1.3The Guidelines are forward looking, supporting both today’s developments and the
1.5.1.4The discipline of software engineering is already well supported by academia, text books
1.5.1.5The eight specific issues for which guidance is given can be seen as aspects that provide a
1.5.2
1.5.2.1
1.5.2.2
·
·
·
·
·
·
·
as a foundation for a standard.
to provide the basis of assessment
guidance for management on resource requirements
guidance for company quality procedures
the basis for training requirements within the automotive industry
as an introduction to issues of automotive software reliability
guidance for creating contracts and specifications for software procurement
The following uses are intended:
in the creation, procurement and maintenance of embedded vehicle software.
This document is intended to be used by software engineers, managers and others involved
Uses
as shown in Figure 1.
link between the established automotive engineering disciplines and software engineering,
and standards. Further guidance in this field is not appropriate at this time.
vehicle features that are envisaged over the next decade.
software development.
related to software engineering.
Scope
Scope and uses of the Guidelines

Introduction)
OMTESRUS
C
KETIRNAGM
ERTRWAOINP
EGLNIESSCEHuman
ATA
CHRFactors
LCINCin SoftwareRE
Sub-AAUDevelop-SL
PContractingCNmentIofSU
FIntegrityAutomotive
RS
Software
ETSBI
OOSMnSoftware ine
SD
and
ControlM
OAgY
nSystemsH
TE
C
SR
US
SoftwareNoise, EMC
CMetricseDiagnostics
D
E
A
E
SystemsL
C
EI
VRM
AGSRNINUFRACTUE
S
C
SURSTEOM
Figure 1. Scope of the MISRA Guidelines

4 © ISO 2000 – All rights reserved
Vehicle
integrated
and
and Real-Tim
Validatio
Engineerin
Softwar
Verificatio
(continued
(continued)
Introduction
1.5.2.3Many of the recommendations are interrelated and overlap. In some instances, due to
1.5.2.4Not all the recommendations will apply in any one situation, so it is not anticipated that
any project will, or can, conform to all the recommendations. Reasons for deviation from
relevant parts of the Guidelines should be properly justified in the associated
1.6
1.6.1It is assumed a nd recommended that the users of this document operate a Quality
Management System capable of meeting the requirements of ISO 9001 [10] as assessed
1.6.2The users should have a working knowledge of the relevant software engineering
1.6.3Users of these Guidelines should be aware of present and emerging standards. Standards
·
the work of the ISO/TC22/SC3/WG11, Automotive Electronic Control
·
·
·
1.6.4ith these Guidelines or with any standard does not of itself confer immunity
1.6.5These Guidelines are not intended to be prescriptive or proscriptive. As an element of
flexibility it is important to allow users to adopt an approach that best matches their
processes and organizational strengths. Hence the term “should” is normally used
throughout in preference to “must” or “shall”. No particular significance should be
1.6.6
1.6.7
For the sake of readability there are no cross-references in this document.
the relevant recommendations increases.
Techniques, activities and their rigour increase with integrity level. Equally, the weight of
attached to the use of alternative wording.
from legal obligations.
Compliance w
the IEE guidelines for the documentation of computer software [17].
the IEEE software engineering standards collection [16]
Systems — Technical Documentation, working party [15]
Commission (IEC) [13, 14]
the emerging generic standards in preparation by the International Electrotechnical
of particular importance include:
practices.
under the guidelines in ISO 9000-3 [11] (e.g. TickIT [12]).
Fundamental concepts
documentation. The Guidelines make recommendations on assessment of compliance.
their generic nature, they may appear not to be in the optimum order within the document.

(continued)
Introduction
1.6.8Several basic principles associated with safety engineering and safety related systems
(a)
The greater the risk, the greater the need for
(c) Software robustness, reliability and safety, like quality, should be built in rather
than added on.
(d) The requirements for human safety and security of property can be in conflict.
(e)
(g) Safety considerations should apply across the design, manufacture, operation,
6 © ISO 2000 – All rights reserved
servicing and disposal of products.
It is necessary to demonstrate robustness, not rely on the absence of failures. (f)
hould consider both random and systematic faults. System design s
Safety must take precedence.
information. (b)
Safety, like justice and democracy, must be seen to be present.
design need to be understood:
2.
2.1Definitions
2.1.1
2.1.2
2.2
controller area network
DIS
EC
ECU
EMI
IEC
IEE
IEEE
I/O input and output
ISO
keyword protocol
OSI
visual display unit VDU
vehicle area network VAN
ty of Automotive Engineers (US) Socie SAE
read-only memory ROM
random-access memory RAM
quality assurance QA
open systems interconnection
on-board diagnostics OBD
KWP
International Organization for Standardization
d Electronics Engineers (US) The Institute of Electrical an
The Institution of Electrical Engineers
International Electrotechnical Commission
electromagnetic interference
electromagnetic compatibility EMC
electronic control unit
European Commission
nal standard draft internatio
curriculum vitae CV
computer aided software engineering CASE
California Air Resources Board (US) CARB
CAN
List of abbreviations
Terms specific to the automotive industry are defined in the text.
The terminology used in these Guidelines is taken from [13, 14, 18].
Definition of terms
3.
3.1Project planning
3.1.1
3.1.1.1 The use of software has man y benefits in terms of cost, flexibility and functionality.
3.1.1.2
3.1.1.3The project objectives should be clearly laid down before the start of a project. For
example, the nature of a project will be different for a volume production system when
3.1.1.4The project definition should consist of a list of features and functions to be implemented.
It should be agreed and documented by the appropriate authorities of the vehicle
manufacturer and made available to the design and development teams before detailed
3.1.1.5The project definit ion should also include any known legislative requirements, project
assumptions and nonfunctional requirements (e.g. the use of an existing engine and/or
3.1.1.6It is particularly important to lay down and agree which features are fixed and which are
customer options.
3.1.1.7
3.1.1.8
3.1.1.9Computer-based tools to be used during the project should be ident ified, and provision
made for their procurement and resourcing at the project definition stage. Such tools are
·
·
·
CASE tools
·
rapid prototyping tools.
·
8 © ISO 2000 – All rights reserved
modelling and simulation tools
calibration development aids
configuration management tools
likely to include:
commercial points of view. The later changes are made, the greater the incremental risk.
Any changes made to the project definition will lead to increased risk from both safety and
inition should be subject to strict change control. The project def
ECU in a new vehicle).
work begins.
compared to a research and development prototype.
software system level [2, 6].
The recommendations in this section can be applied both at a vehicle system level and at a
containing software are only used where these benefits are required.
However, because of the problems associated with complexity, it is important that systems
Project definition
Software lifecycle
3.1.2
3.1.2.1An appropriate development approach should be defined and documented (e.g. by
producing a Software Development Plan, a Quality Plan, a Safety Plan and a
(a)
(c)
(d) management reviews of the effectiveness of the procedures in (b) and
(e)
3.1.2.2The project team should progressively produce a Software Development Plan with clearly
·
·
·
·
·
·
3.1.2.3The Safety Plan [14] should aim to ensure that verification and validation are performed
throughout the project. These activities should be performed with a rigour appropriate to
3.1.2.4Appropriate lifecycle plans should be defined before t he start of a project for the system
3.1.2.5Each individual system should have its own lifecycle that should be compatible with the
3.1.3
3.1.3.1The verification and validation activities should be defined to establish a level of
confidence in the software that corresponds the integrity requirements of the system. See
Figure 4.
nd validation Planning for verification a
project definition and the overall vehicle plan. An example is shown in Figure 3.
and the software. Figure 2 shows an example lifecycle.
the integrity level.
in-service support of the software.
verification and validation (including testing)
integration
programming
design
specification
defined phases that, comprehensively and cost-effectively, cover the:
specific software deliverables together with their authors and readers.
processes in (c).
planned
management processes to ensure compliance with the procedures in (b).
procedures to be followed. (b)
project organization.
Configuration Management Plan). The design material should define:
Lifecycle plans
Software lifecycle
(continued)
Software lifecycle)
s
d
s
s
t
n
y
ns
e
y
s
nee
nss
g
n
n
g
n
t
tn
t
s
"
e
e
10 © ISO 2000 – All rights reserved
Figure 2. An example lifecycl
and Support
Operation, Maintenanc
Production "Job # 1
Validation Safety
Test Validation Vehicle
Acceptance Tes Reliability
Integratio Tes Environmental
Reviews
Test Module Tes Functional
and
Verificatio
Programmin Analysis
Acceptance Desig
Design and Implementatio
Plannin
Requirement Requirement Validatio and
Softwar Hardwar Verificatio
Definition
Process
Related System
Development
Identification of Safet
Softwar
Requirement Desig
Safet Systems
Specificatio
Assessmen
System Requirement
Integrity
Analysi
Concept
Hazar
Safety Analysi
(continued
Software lifecycle)
g
n
it
s
e
T
n
oi
t
a
dil
a
V
t
n
e
t
Validationn
I
neProduction Intentoc
itn
ca
un
de
to
nri
Pa
M
e
r
a
wt
f
o
S
g
n
it
s
yet
Til i
n
boiitt
aa
pdi
l
maVehicle PrototypoesVg cne i
teplsInytegration/Calibrationtce
Toy t
cdo
renfiaPl
ne
origta
naiwctimffi
romt
esa rVndg
noera
snPi
gsmim
yseltepnas
Dng yioAsslm e, Detaileed DesigntDeel slcyaivrCompSonent Developmehnt ulete
ocvr etDftine oo h
ceClrmmpAi
em
Tta
x
se
yn
A S
.
3RequConceirement pt Designs Capture
Ue
r
u
C
gi
VtESoftware DevelopmentFehicle Developmen

(continued
Software lifecycle)
l
n
n
,
w,
.
,
,
.
,
sw.
tt
l
t,
T.
,
,
T.
,
,
t
,egarevoC noisiceD
.
n
12 © ISO 2000 – All rights reserved
Figure 4. Software verification and validatio
etc
Tes White-box
Branch, Condition
Structural, Path
esting, etc Stress
Performance
Functional
esting, etc Stress
Performance Tes Black-box
Functiona
Tes System/Acceptance Tes Dynamic - Module/Integration
, etc Control and Data Flo
Analysi
Static Analysis, Formal Proof
Rapid Prototyping, etc
CASE Modelling
Formal Specification
Argument, etc
Code Inspection, Peer Review
Revie
Walkthrough, Fagan Inspection
Animatio Techniques Static
Validatio Verification
Software Quality Contro
(continued
3.1.3.2The purpose of software verification [6] is to ensure tha t each phase of the software
development process maintains the attributes of the previous one without introducing
errors. The outputs of each phase should be technically evaluated, by analysis and/or
3.1.3.3Safety verification is specifically concerned with the safety requirements and should
proceed concurrently with the normal design and implementation process. Each phase of
3.1.3.4
3.1.3.5The purpose of software validation [6] is to determi ne whether the software satisfies its
intention and mainly consists of performing tests, but it should also involve analysis and
3.1.3.6Safety validation should be carried out to confirm specifically that all the safety
3.1.3.7
3.1.3.8To be effective, it is recommended that verification and validation are carried out by a
person or team exhibiting a degree of independence from the design and implementation
3.1.4
3.1.4.1It is recommended that a company nominates a suitably qualified [19] and independent
assessor and/or auditor to perform product assessment, in order to act as an advocate for
3.1.4.2An assessment process should be performed to demonstrate that the risks associated with
3.1.4.3The higher levels of integrity should require greater independence of assessment in order
to ensure that there is no bias from the development team, nor misplaced pressure from
management.
the final system are at an acceptable level [14].
the level of confidence in the safety delivered to the end customer [2].
Assessment
appropriate to the integrity requirements of the software and system.
A validation plan should be established for the software, system and vehicle.
requirements have been met.
take place until it has been integrated with the rest of the system and often the vehicle.
mathematical techniques where appropriate. Full validation of the software cannot usually
A verification plan should be established covering each phase of the software lifecycle.
next development phase.
the development should also be verified with respect to safety before progressing on to the
inspection with respect to its inputs, including standards and guidelines.
Software lifecycle
(continued)
3.1.4.4
·
·
·
3.1.4.5The degree of confidence in a piece of software depends on the quality and the extent of
3.1.4.6Preparing for assessment is a task that should begin at the start of a project; this also
information has been omitted or overlooked. Early liaison with the assessor is
.
3.1.5
3.1.5.1 ponents containing software to be used in a
project should be assessed to the required integrity level, and such reuse of existing
3.1.5.2The software that is intended for reuse should be fully compliant with the requirements of
3.1.5.3Software that is intended for reuse, as with all software, should have a standard of
documentation such that its functions and interactions are easily understood by people
3.1.5.4Software that has performed faultlessly for a number of years in the field may well offer a
greater level of confidence in the final product than a wholly new program, provided it is
.
3.2
3.2.1
3.2.1.1Each system in a vehicle needs to have a level of integrity because there are requirements
that it should not cause:
·
·
·
·
·
14 © ISO 2000 – All rights reserved
undue financial loss to either the manufacturer or the owner.
damage to property or the environment (e.g. emissions).
undue traffic disruption
legislation to be broken
harm to humans
Introduction
Integrity
used within the limitations of its design and is not modified
who may not have been the original authors.
the new system that it is intended to be used in.
software should be considered on a case by case basis.
” or commercially available com “Off the shelf
Reuse
recommended
avoids the possibility of arriving at the point of assessment and finding that a vital piece of
testing of the software.
the available information. This should cover the specification, design, implementation and
different company or division.
different department or section
different person
The degree of independence [14] should be achieved by one or more of:
Software lifecycle
(continued)
3.2.1.2By achieving the required level of integrity, the risks associated with each of the
requirements listed above should be reduced to an acceptable level [14]. Higher levels of
integrity are achieved by the increased use of specialized methods and design
requirements. This leads to an increasing cost, both of the development and of the end
product.
3.2.1.3use of integrity levels permits a reasoned argument for assessing the degree of
3.2.1.4The recommendations and processes described in this section seek to enable a developer
to:
(a)
adopt a suitable development process in order to achieve the confidence level
3.2.1.5The system design may reduce the integrity level required for particular subsystems. For
example, a failure mode set to a safe state by a hardware interlock of a suitable integrity
level would remove that potential failure from the software hazard list. The hazard
3.2.1.6Once an integrity level for the software has been determ ined, an appropriate development
3.2.1.7The higher levels of integrity require more information and more rigorous application of
3.2.2
3.2.2.1A preliminary safety analysis [20] should be carried out as part of the requirements
analysis phase, which becomes more detailed as the design progresses. Safety analysis is
highly iterative and should be considered as a continuous process during requirements
3.2.2.2:
·
the high level safety requirements necessary to reduce the risk associated with eac
...