use of the rational unified process for development of ...borres/mastersarchive/rune-thesis.pdfthere...

Use of the Rational Unified Process for development of safety-related computer systems

Hovedfagsoppgave i informatikk

Rune Fredriksen 24.mai 2002

Høgskolen i Østfold Avdeling for infomatikk ogautomatisering

Contents

1 Introduction 3

2 IEC61508 62.1 Structure of the standard . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Definitions and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Safety integrity and functional safety . . . . . . . . . . . . . . . . 72.3.2 Safety lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 A risk-based approach . . . . . . . . . . . . . . . . . . . . . . . . 82.3.4 ALARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.5 SIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Confidence of safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Use of the standard (example) . . . . . . . . . . . . . . . . . . . . . . . 11

2.6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6.2 Perform Software Risk Analysis . . . . . . . . . . . . . . . . . . . 112.6.3 Determine SIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6.4 Define Software Safety Integrity Requirements . . . . . . . . . . 122.6.5 Define Software Functional Requirements . . . . . . . . . . . . . 122.6.6 Initiate Risk Control Measures . . . . . . . . . . . . . . . . . . . 122.6.7 Assess Residual Risk . . . . . . . . . . . . . . . . . . . . . . . . . 132.6.8 Comments to the example . . . . . . . . . . . . . . . . . . . . . . 13

3 The Rational Unified Process 143.1 Dynamic aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Inception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.3 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.4 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Static aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

i

3.2.3 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.4 Disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.1 Develop software iteratively . . . . . . . . . . . . . . . . . . . . . 193.3.2 Manage requirements . . . . . . . . . . . . . . . . . . . . . . . . 203.3.3 Use component-based architectures . . . . . . . . . . . . . . . . . 203.3.4 Visually model software . . . . . . . . . . . . . . . . . . . . . . . 203.3.5 Verify software quality . . . . . . . . . . . . . . . . . . . . . . . . 213.3.6 Control changes to software . . . . . . . . . . . . . . . . . . . . . 213.3.7 Other key features of the Rational Unified Process . . . . . . . . 21

4 Method 224.1 Defining the IEC61508 requirements process selection criteria . . . . . . 24

4.1.1 Process related . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.3 Verifiable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Defining the RUP relevant process selection criteria . . . . . . . . . . . . 264.3 Evaluation of the application of the requirements towards RUP . . . . . 264.4 Implementation of the IEC61508 requirements within RUP . . . . . . . 26

5 Selection of relevant IEC61508 requirements 285.1 IEC61508-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2 IEC61508-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 IEC61508-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4 Summary of the requirements selection . . . . . . . . . . . . . . . . . . . 33

6 IEC61508 requirements relation to RUP 346.1 Consideration of relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2 General requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.2 Scope definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2.3 Hazard and risk analysis . . . . . . . . . . . . . . . . . . . . . . . 366.2.4 Safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.5 Operation and maintenance . . . . . . . . . . . . . . . . . . . . . 386.2.6 Safety validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2.7 Installation and commissioning plan . . . . . . . . . . . . . . . . 406.2.8 Modification and retrofit . . . . . . . . . . . . . . . . . . . . . . . 416.2.9 Decommissioning or disposal impact plan . . . . . . . . . . . . . 416.2.10 Verification plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2.11 Functional Safety Assessment . . . . . . . . . . . . . . . . . . . . 43

6.3 Requirements for electric/electronic/programmable electronic safety-relatedsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3.1 Safety lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ii

6.3.2 E/E/PES safety requirements specification . . . . . . . . . . . . 456.4 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.4.1 Software safety lifecycle requirements . . . . . . . . . . . . . . . 456.4.2 Software safety requirements specification . . . . . . . . . . . . . 466.4.3 Software safety validation planning . . . . . . . . . . . . . . . . . 476.4.4 Tool selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.4.5 Programming language selection . . . . . . . . . . . . . . . . . . 496.4.6 Coding standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4.7 Source code review . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4.8 Module testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.4.9 Integration testing . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4.10 Discrepancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.5 Summary of relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7 Safety RUP 557.1 Conceptual issues in an IEC61508 perspective . . . . . . . . . . . . . . . 55

7.1.1 The safety lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 557.1.2 A unified approach . . . . . . . . . . . . . . . . . . . . . . . . . . 557.1.3 The spirit of the standard . . . . . . . . . . . . . . . . . . . . . . 56

7.2 Conceptual issues in a RUP perspective . . . . . . . . . . . . . . . . . . 567.2.1 Develop software iteratively . . . . . . . . . . . . . . . . . . . . . 567.2.2 Manage requirements . . . . . . . . . . . . . . . . . . . . . . . . 577.2.3 Use component-based architectures . . . . . . . . . . . . . . . . . 577.2.4 Visually model software . . . . . . . . . . . . . . . . . . . . . . . 577.2.5 Verify software quality . . . . . . . . . . . . . . . . . . . . . . . . 587.2.6 Control changes to software . . . . . . . . . . . . . . . . . . . . . 587.2.7 Summary of conceptual issues . . . . . . . . . . . . . . . . . . . . 58

7.3 Safety Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.3.2 Relation to other disciplines . . . . . . . . . . . . . . . . . . . . . 597.3.3 Workflow of the Safety discipline . . . . . . . . . . . . . . . . . . 607.3.4 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.4 SIL levels, techniques and measures . . . . . . . . . . . . . . . . . . . . . 617.4.1 A normative guide . . . . . . . . . . . . . . . . . . . . . . . . . . 627.4.2 SIL and Safety RUP . . . . . . . . . . . . . . . . . . . . . . . . . 62

8 Discussion 638.1 Why? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638.2 The method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.3 The results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.4 The work that has been done . . . . . . . . . . . . . . . . . . . . . . . . 658.5 Relation to other work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.5.1 The dependability-explicit development model . . . . . . . . . . 66

iii

8.5.2 CORAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.6 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

9 Conclusions 679.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.3 Can RUP be used for development of safety critical systems? . . . . . . 67

iv

List of Figures

1.1 Focus of thesis is on establishing a generic ”safety RUP” . . . . . . . . . 41.2 Conceptual overview of thesis approach . . . . . . . . . . . . . . . . . . 5

2.1 Safety lifecycle from IEC61508 . . . . . . . . . . . . . . . . . . . . . . . 82.2 ALARP Principle from IEC61508 . . . . . . . . . . . . . . . . . . . . . . 9

3.1 The Iterative Modelgraph . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Overview of the method . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Requirements model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Basic process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4 Process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1 E/E/PES Safety Lifecycle(in realization phase) . . . . . . . . . . . . . . 44

v

List of Tables

1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

2.1 IEC61508 example: Identified hazards . . . . . . . . . . . . . . . . . . . 122.2 IEC61508 example: Assigned SIL . . . . . . . . . . . . . . . . . . . . . . 12

4.1 RUP relevant process selection criteria . . . . . . . . . . . . . . . . . . . 27

5.1 IEC61508-1 requirements consideration . . . . . . . . . . . . . . . . . . . 295.2 IEC61508-2 requirements consideration . . . . . . . . . . . . . . . . . . . 305.3 IEC61508-3 requirements consideration . . . . . . . . . . . . . . . . . . . 33

6.1 Summary of IEC61508 requirements relation to RUP . . . . . . . . . . . 54

vi

Definitions

Expression DefinitionActivity A unit of work that a role (worker) may

be asked to perform [16].Artifact A piece of information that is

produced, modified, or used by a process,defines an area of responsibility, and issubject to version control. An artifactcan be a model, a model element or adocument [16].

Baseline A reviewed and approved release ofartifacts that constitutes an agreed-onbasis for evolution or development andthat can be changed only through a formalprocedure, such as change or configurationcontrol [16].

Core Workflow Rational Unified Process v20001ARelease Notes Terminology change:”Core Workflow” to ”Discipline”See definition of Discipline.

Discipline The sequence of activities performed in abusiness that produces a result ofobservable value to an individual actorof the business [16].

EUC Equipment Under Control, e.g. the systemunder consideration.

Functional safety Part of the overall safety relating tothe EUC and the EUC control system whichdepends on the correct functioning of theE/E/PE safety-related systems,othertechnology safety-related systems andexternal risk reduction facilities[11].

vii

Harm Physical injury or damage to the healthof people either directly, or indirectlyas a result of damage to property or tothe environment [11].

Hazard Potential source of harmIteration A distinct sequence of activities with a

baselined plan and valuation criteriaresulting in a release (internal orexternal [16].

Requirement A description of a condition or capabilityof a system; either derived directly fromuser needs or stated in a contract,standard, specification or other formallyimposed document [16].

Risk The combination of the probability ofoccurrence of harm and the severity ofthat harm [11].

Role A definition of the behavior andresponsibilities of an individual, or aset of individuals working together as ateam, within the context of a softwareengineering organization [16].

Safety Freedom from unacceptable risk[11].

Safety functions Function to be implemented by an E/E/PEsafety-related system, other technologysafety-related system or external riskreduction facilities, which is intended toachieve or maintain a safe state for theEUC, in respect of a specific hazardousevent [11].

Safety integrity Probability of a safety-related systemsatisfactorily performing the requiredsafety functions under all the statedconditions within a stated period of time[11].

Safety Integrity Discrete level (one out of a possibleLevel four) for specifying the safety integrity

requirements of the safety functions to beallocated to the E/E/PE safety-relatedsystems, where safety integrity level 4

viii

has the highest level of safety integrityand safety integrity level 1 has thelowest [11].

Safety-related Designated system that both: (1)implementsSystem the required safety functions necessary to

achieve or maintain a safe state for theEUC; and (2) is intended to achieve, onits own or with other E/E/PEsafety-related systems or external riskreduction facilities, the necessary safetyintegrity for the external safetyfunctions [11].

SIL See Safety Integrity Level.Worker Rational Unified Process v20001.03.00

Release NotesTerminology change: ”Worker” to ”Role”See definition of Role

Table 1: Definitions

ix

Preface

There exists no silver bullet1 when it comes to engineering a safety-critical system.”Applying” safety to a finished programmable system has been a common approach tobuilding a safety-critical system. This approach has been criticized as being both time-and cost-consuming and it is a questionable approach to achieve safety.

The Rational Unified Process (RUP) does not address safety, or even dependabilityissues, in its default configuration. There is one apparent issue that justify a closerlook at RUP: It is rapidly becoming an industry standard for developing software sys-tems. There will be thousands of systems developed with RUP - regardless of what thesafety community might think of the object-oriented approach, semi-formal methodsand development processes that does not include safety issues.

This thesis is a first step towards what might be a closer look at the connection be-tween the framework of RUP and how safety might be included in an industry standarddevelopment process.

1Of all the monsters that fill the nightmares of our folklore, non terrify more than werewolves, becausethey transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver thatcan magically lay them to rest [13]

1

Acknowledgements

I would like to thank my supervisor, associate professor Rune Winther at Østfold Uni-versity College for his advise, inspirational guidance, support and patience throughevery phase of my work with this thesis - from the first idea to the last comment.

I would also like to thank

• the employees at Kongsberg Simrad have provided valuable initial discussions andinterest in the topic of my thesis

• Børre Stenseth at Østfold University College and Monica Kristiansen at Institutefor Energy Technology/Halden Reactor Project have delivered fruitful commentsto the earlier versions of the thesis

• all my colleagues at Institute for Energy Technology/Halden Reactor Project formotivation and inspiration

• my parents, Terje and Kari Fredriksen, for all support and motivation

Last, but not least, I would like to thank my 1-year-old nephew Vegard for teachingme again about the importance of making a better world.

Rune Fredriksen, Halden, May 24. 2002.

2

Chapter 1

Introduction

This thesis attempts to provide a theoretical basis for using Rational Unified Process(RUP) for development of safety-related computer systems. By using the requirementsand concepts of IEC61508 on how to ”apply safety”, this basis hopefully provide agood starting point for further investigation into how a development process based ona semi-formal method (UML) may contribute to safety assessment.

The goal of this thesis is to evaluate how RUP may be used in development ofa safety-critical computer system and to propose a configuration/changes of RUP toconform to IEC61508. This is done by developing some conceptual and practical changesto RUP that should be considered when making an instance of RUP in a company.

The thesis is inspired by the ideas about the need for a development model focusedat the production of dependable systems and a systematic and structured frameworkthat integrates dependability concerns as presented by Kaaniche et al. [14].

The connection between the Unified Development Process (UDP) [12], the RationalUnified Process (RUP) [16], a standard instance of a RUP process (Acme1 RUP), thechanged/configured process in this thesis (Safety RUP), and an instance of the SafetyRUP (Acme Safety RUP) is shown in Figure 1.1 to provide the reader with the focus ofthis thesis (the grey area). This includes the influence from RUP and IEC61508 on theproposed Safety RUP and the influence of Safety RUP on an instance of the suggestedprocess framework.

The first chapter introduces the IEC61508 - a standard for developing safety-criticalsoftware and a framework for developing domain-specific safety standards. The standard

1[from Greek ‘akme’, highest point of perfection or achievement]This term, specially cherished by American hackers and explained here for the benefit of our overseas

brethren, comes from the Warner Brothers’ series of ”Roadrunner” cartoons. In these cartoons, thefamished Wile E. Coyote was forever attempting to catch up with, trap, and eat the Roadrunner. Hisattempts usually involved one or more high-technology Rube Goldberg devices - rocket jetpacks, cata-pults, magnetic traps, high-powered slingshots, etc. These were usually delivered in large wooden crateslabeled prominently with the Acme name - which, probably not by coincidence, was the trade name ofthe animation rotation board used by cartoonists since forever. Acme devices invariably malfunctionedin improbable and violent ways. [22]

3

Figure 1.1: Focus of thesis is on establishing a generic ”safety RUP”

provides an integrated approach to achieve and assess the functional safety of a systemand all of its components. IEC61508 is accepted as a generic basis for standards in allindustrial sectors and is the basis for newer reference literature like [25] [18] [24] withindevelopment of safety-critical system.

The Rational Unified Process (RUP) described is a software engineering processdeveloped and marketed by Rational Software. It provides a disciplined approach toassigning and managing tasks and responsibilities within a development organization.Its goal is to ensure the production of high-quality software that meets the needs of itsend users within a predictable schedule and budget [16].

The evaluation of IEC61508 and RUP seeks to identify the requirements of a devel-opment process that defines all relevant safety activities, explores synergy effects, appliesto requirements from customer, government and certification authorities, defines rolesand responsibility related to safety, defines safety specific milestones and is acceptablewith regards to time and economic constraints - a process that also should be scalable.

The conceptual overview of the process towards Safety RUP is shown in Figure 1.2.The results of the thesis are the considerations made about the Conceptual issues andthe Safety discipline which an instance of the Safety RUP should be based on.

The proposed changes to RUP are developed by using the requirements of thisanalysis, and presented in the same way as RUP itself is presented. The applicationof the method in this thesis was done with the assumption that the standard itselfis used as reference material when applying the Safety RUP, or when considering thesuggestions in this thesis.

4

Figure 1.2: Conceptual overview of thesis approach

5

Chapter 2

IEC61508

IEC61508 is a standard for developing safety-critical software and a framework fordeveloping domain-specific safety standards. The standard has an integrated approachto achieve and assess the functional safety of a system and all of its components. Thecommittee that developed IEC61508 was one of the first to acknowledge: 1) that safetyis a system issue, and 2) the need for a harmonized approach to safety managementacross all system components.

2.1 Structure of the standard

The standard is published in seven parts as shown below. Only the first four partscontain normative requirements.

• IEC 61508-1:1998, Functional safety of E/E/PE safety-related systems Part 1:General requirements

• IEC 61508-2:2000, Functional safety of E/E/PE safety-related systems Part 2:Requirements for E/E/PE safety-related systems

• IEC 61508-3:1998, Functional safety of E/E/PE safety-related systems Part 3:Software requirements

• IEC 61508-4:1998, Functional safety of E/E/PE safety-related systems Part 4:Definitions and abbreviations

• IEC 61508-5:1998, Functional safety of E/E/PE safety-related systems Part 5:Examples of methods for the determination of safety integrity levels

• IEC 61508-6:2000, Functional safety of E/E/PE safety-related systems Part 6:Guidelines on the application of IEC 61508-2 and IEC 61508-3

• IEC 61508-7:2000, Functional safety of E/E/PE safety-related systems Part 7:Overview of techniques and measures

6

In this thesis we will primarily work with parts 1-3.

2.2 Purpose and scope

The primary purpose of IEC61508 is to provide a ”unified approach” for all safetylifecycle activities that is rational and consistent. As such, the standard covers alllifecycle phases for all system components, from concept through decommissioning. Thestandard promotes a broad range of principles, techniques, and measures to achieve andassess functional safety; a fundamental premise being the risk-based determination ofsafety integrity levels (SILs).

The secondary purpose of IEC61508 is to facilitate the development of industryspecific standards, which has been successfully achieved. EN50128:1997, the MISRAGuidelines, and the SEMSPLC Guidelines are examples of application specific standardsderived from IEC16508.

IEC61508 applies to any safety-related software which, as defined by Parts 1 and 2,includes: (a) software that is part of a safety-related system; (b) software that is usedto develop a safety-related system; and (c) the operating system, system software, com-munication software, human computer interface (HCI) functions, utilities, and softwareengineering tools used with (a) or (b) above.

2.3 Definitions and concepts

The IEC61508 provides some definitions: ”safety” is defined as freedom from unaccept-able risk, ”risk” is defined as the combination of the probability of occurrence of harmand the severity of that harm, ”harm” is defined as physical injury or damage to thehealth of people either directly, or indirectly as a result of damage to property or to theenvironment, and ”a hazard” is defined as the potential source of harm. This impliesthat to say something about safety, you have to identify hazards and their effects andshow how these hazards are handled within the system - or not.

2.3.1 Safety integrity and functional safety

Two major concepts of IEC61508 are safety integrity and functional safety. Safetyintegrity is defined as the probability of a safety-related system satisfactorily performingthe required safety functions under all stated conditions within a stated period of time.Functional safety is defined as the ability of a safety-related system to carry out theactions necessary to achieve a safe state for the equipment under control or to maintaina safe state for the equipment under control.

The standard requires assessment of the risk posed by the equipment under control(EUC), decision on whether the risk should be reduced, decision on what level of riskis tolerable (recognition that perfect safety cannot be achieved), and determination ofhow to go about reducing the risk.

7

2.3.2 Safety lifecycle

IEC61508 addresses the safety requirements in all lifecycle stages, from concept to de-commissioning. The safety lifecycle in Figure 2.1 is a model for identifying the activitiesappropriate to assessment of safety-related systems.

2.3.3 A risk-based approach

The standard requires a risk-based approach when developing a safety-critical system. Arisk-based approach means not merely following a procedure and assuming that ”safety”will result, but one have to identify the risks, determine how and by how much to reducethe risks, justify the decisions, reduce the risks, demonstrate this reduction, and acceptresponsibility for all decisions.

Figure 2.1: Safety lifecycle from IEC61508

8

2.3.4 ALARP

The principles of ”tolerable risk” and ALARP (see Figure 2.2) facilitate risk reduction.The ALARP (As Low As Reasonably Practicable) principle is based on an assumptionthat there might be situations where it is acceptable that an accident with negligibleconsequences could occur frequently, or where a potentially critical or catastrophic ac-cident cannot be assumed to have zero probability. The acceptability of a given levelof risk is determined by the benefits associated with that risk, and by the effort thatwould be required to reduce it.

Figure 2.2: ALARP Principle from IEC61508

2.3.5 SIL

Safety Integrity Levels (SILs) provide targets for risk reduction. Although SIL is basedon risk it is not a measure of risk - it is the probability of failure of a system or function.SIL define the categories of rigour of safety management. The allocated SIL influencesthe processes used in the development of safety-related systems or functions.

Using the processes implied by a SIL does not mean that the reliability representedby the SIL has been achieved. Achieving the SIL does not imply that the system is safe,and meeting the requirements of a SIL offers confidence, not proof that the system issafe.

9

Interaction between SILs and the risk management process [9] can be summarizedas follows: (1) Perform Software Risk Analysis, (2) Determine Software SIL, (3) DefineSoftware Safety Integrity Requirements, (4) Define Software Functional Safety Require-ments, (5) Initiate Risk Control Measures, (6) Assess Residual Risk

IEC61508 is based on controlling the factors through techniques and methods thatinfluence achievement of safety integrity in software. These include: choice of engineer-ing technique, software architecture, and rigour of quality assurance approach. This isthe approach described by Parts 2 and 3 of the standard that index these factors againstthe required safety integrity level. [4]

2.4 Confidence of safety

IEC61508 states that one should require confidence of safety in advance, not retrospec-tively so that we must demonstrate it. It dispel the belief that ”if we do it well it willbe safe” - in other words one should not rely on that correct functionality will providesafety.

In this context one should: (1) specify safety requirements independently of func-tional requirements, (2) be clear about how and when they are to be implemented,(3) ensure that they can be validated independently, (4) validate them, (5) employ(independent) assessment.

2.5 Compliance

The term shall used in a requirement indicates that the requirement is strictly to befollowed if conformance to the standard is to be claimed.

Where should (or it is recommended that) is used, this indicates that among severalpossibilities one is recommended as particularly suitable, without mentioning or exclud-ing others, or that a certain course of action is preferred but not necessarily required.

Normative elements set out the provisions to which it is necessary to conform inorder to be able to claim compliance with the standard. The text in a normativeelement usually contains both shall and should.

In IEC 61508, the following contain normative elements: part 1 (excluding annexes);part 2 (including annexes); part 3 (including annexes A and B, excluding annex C); andpart 4 (excluding the annex). There are no normative requirements in parts 5, 6 and 7of the standard.

Informative elements of the standard provide additional information intended toassist its understanding or use, but with which it is not necessary to conform in order tobe able to claim compliance. The text in an informative element cannot contain shall.Notes and footnotes are always informative[10].

10

2.6 Use of the standard (example)

To effectively implement IEC61508 one must understand the interaction between SILsand the risk management process. A high-level hypothetical example shows how theseconcepts are implemented. The example follows the structure of the example in [9], butthis example is not as extensive and considers a different device.

The activities that must be performed are:

• Perform Software Risk Analysis

• Determine SIL

• Define Software Safety Integrity Requirements

• Define Software Functional Requirements

• Initiate Risk Control Measures

• Assess Residual Risk

2.6.1 Assumptions

The equipment under control is a medical radiation treatment device. It includes anaccessory which maintains a database. Software controls are:

• RR - release radiation

• TB - target beam

• DD - determine dosage

• MD - maintaining the patient treatment profile database

Functions RR and TB operate in real time; DD and MD do not. The device operatesin demand mode.

To simplify the example only the RR function is commented further in the example.

2.6.2 Perform Software Risk Analysis

The following hazards were identified for the first functions in Table 2.1.

2.6.3 Determine SIL

Using the worst case scenario from the above table, the following SILs are assigned inTable 2.2

11

Software Function Hazard Consequences SeverityRadiation release erroneous release injury to healthy tissue Critical(RR) of radiation - burns

- overdose - damaged tissueerroneous release therapy ineffective Negligibleof radiation- underdoseerroneous release therapy ineffective Negligibleof radiation- incorrect time not intended exposure Critical

Table 2.1: IEC61508 example: Identified hazards

Function SILRadiation release (RR) 3

Table 2.2: IEC61508 example: Assigned SIL

2.6.4 Define Software Safety Integrity Requirements

This requirement become part of the Software Safety Requirements Specification.

• The Radiation Release function must operate correctly as specified 99.99 percentof the time. It must not release radiation except under the exact conditionsspecified.

2.6.5 Define Software Functional Requirements

This requirement become part of the Software Safety Requirements Specification.The Control Radiation Release function shall:

• a - verify the beam type through two independent means before operation

• b - verify the beam strength through two independent means before operation

• c - verify the beam duration through two independent means before operation

• d - be disabled during maintenance, testing, and upgrades

• e - verify against an established data table that the proposed beam type, strength,and duration are a valid and medically feasible combination

2.6.6 Initiate Risk Control Measures

Based on the SIL for each function, the following techniques and measures will beimplemented.

12

• A CASE tool will be used that supports requirements analysis, architecture spec-ification, and design

• Function block diagrams and descision/truth tables, perhaps as an output of theCASE tool, will be used to clarify requirements

• The SADT methodology will be followed

2.6.7 Assess Residual Risk

Based on the SIL for each function and the device technology, the following verification,validation, and assessment techniques will be utilized.

• Functional, performance, and interface testing will be performed

• Static analysis techniques will be used to verify the integrity of the software/design

• A HAZOP will be performed to verify that the device performs correctly in theoperational environment

2.6.8 Comments to the example

This example does of course not provide a full understanding of IEC61508, but servesthe purpose to give a small piece of insight on how the standard works in practice. Theexample shows from which analysis the SIL is assigned and how this affects the furtherrisk assessment.

13

Chapter 3

The Rational Unified Process

The Rational Unified Process (RUP) is a software engineering process developed andmarketed by Rational Software. It provides a disciplined approach to assigning andmanaging tasks and responsibilities within a development organization. Its goal is toensure the production of high-quality software that meets the needs of its end userswithin a predictable schedule and budget [16].

RUP is delivered through a web-enabled, searchable knowledge base. The process ismeant to enhance team productivity and deliver software best practices via guidelines,templates and tool mentors for all critical software lifecycle activities. The knowledgebase allows development teams to gain the full benefits of the industry-standard UnifiedModeling Language (UML) [3] [23].

RUP can be described in two dimensions (or axes): (1) the horizontal axis representstime and shows the dynamic aspect of the process - cycles, phases, iterations, andmilestones, (2) the vertical axis represents the static aspect of the process - activities,artifacts, roles, and disciplines. The entire model is shown in figure 3.1

3.1 Dynamic aspect

In RUP the software lifecycle is broken into cycles, where each cycle is the work neededfor a new generation of the product. These cycles are divided into four consecutivephases: (1) Inception, (2) Elaboration, (3) Construction, and (4) Transition. Each phaseis concluded with a well-defined milestone - a point in time where critical decisions musthave been made and key goals must have been achieved.

3.1.1 Inception

The goal of the inception phase is to achieve concurrence among all stakeholders on thelifecycle objectives for the project.

The primary objectives should include the following: (1) scope and boundary con-ditions, (2) primary scenarios of behaviour, (3) exhibit one candidate architecture, (4)

14

Figure 3.1: The Iterative Modelgraph

estimate overall cost and schedule, (5) detailed estimates for the elaboration phase, and(6) estimate risks (the sources of unpredictability).

The essential activities of the inception phase are as follows: (1) formulate scopeof the project, (2) plan and prepare a business case, (3) evaluate alternatives for riskmanagement, staffing, project plan, trade-offs between cost, schedule and profitability,and (4) synthesize a candidate architecture, evaluate trade-offs in design and assessmake/buy/reuse decisions.

The outcome of the inception phase is creation of these artifacts: (1) a vision docu-ment, (2) the use-case model survey, (3) an initial project glossary, (4) an initial businesscase, (5) an initial risk assessment, and (6) a project plan.

3.1.2 Elaboration

The main purpose of the elaboration phase is to analyse the problem domain, establisha sound architectural foundation, develop the project plan, and eliminate the project’shigh risk elements.

The primary objects of the elaboration phase include the following: (1) define,validate and baseline the architecture, (2) baseline the vision, (3) baseline a high-fidelityplan for the construction phase, and (4) demonstrate that the baseline architecture willsupport this vision for a reasonable cost in a reasonable time.

The essential activities of the elaboration phase are as follows: (1) the vision is

15

elaborated, (2) the process, the infrastructure, and the development environment areelaborated, and the process, tools and automation support are put into place, (3) thearchitecture is elaborated, and (4) potential components are evaluated and integratedagainst the primary scenarios.

The outcome of the elaboration phase are as follows: (1) a use-case model (atleast 80% complete), (2) supplementary requirements that capture the non-functionalrequirements and any requirements that are not associated with a specific use-case,(3) a software architecture description, (4) an executable architectural prototype, (5)a revised risk list, (6) a revised business case, (7) a development plan for the overallproject, (8) an updated development case, and optionally (9) a preliminary user manual.

3.1.3 Construction

During the construction phase, all remaining components and application features aredeveloped and integrated into the product, and all features are tested thoroughly.

Primary construction phase objectives include the following: (1) minimize develop-ment costs, (2) achieve adequate quality as rapidly as practical, and (3) achieve usefulversions as rapidly as practical.

The essential activities of the construction phase are as follows: (1) resource manage-ment, resource control, and process optimisation, (2) complete component developmentand testing, and (3) assessment of product releases.

The outcome of the construction phase is a product ready to put in the hands ofits users. At minimum, it consists of the following: (1) the software product integratedon the adequate platforms, (2) the user manuals, and (3) a description of the currentrelease.

3.1.4 Transition

The purpose of the transition phase is to move the software product to the user com-munity.

The transition phase includes the following: (1) beta testing, (2) conversion ofdatabases, (3) training of users and maintainers, and (4) rollout of the product tothe marketing, distribution and sales teams.

The primary objectives of the transition phase include the following: (1) achieve userself-supportability, (2) achieve stakeholder concurrence, and (3) achieve final productbaseline.

The essential activities of the transition phase are as follows: (1) deployment-specificengineering, (2) tuning activities, and (3) assessing the deployment baselines against thevision and acceptance criteria for the product.

16

3.2 Static aspect

In RUP a process describes who is doing what, how, and when. RUP is representedusing four primary modeling elements: (1) Roles - the who, (2) activities - the how, (3)artifacts - the what, and (4) disciplines - the when.

3.2.1 Roles

A role defines the behaviour and responsibilities of an individual, or a group of individ-uals working together as a team. You could regard a role as a ”hat” an individual canwear in the project. One individual may wear many different hats. The responsibilitieswe assign to a role include both to perform a certain set of activities as well as beingowner of a set of artifacts.

3.2.2 Activities

An activity of a specific role is a unit of work that an individual in that role may be askedto perform. The activity has a clear purpose, usually expressed in terms of creating orupdating some artifacts, such as a model, a class, or a plan. Every activity is assignedto a specific role. The granularity of an activity is generally a few hours to a few days,it usually involves one role, and affects one or only a small number of artifacts. Anactivity should be usable as an element of planning and progress; if it is to small, it willbe neglected, and if it is to large, progress would have to be expressed in terms of anactivity’s parts.

3.2.3 Artifacts

An artifact is a piece of information that is produced, modified, or used by a process.Artifacts are the tangible products of the project, the things the project produces or useswhile working towards the final product. Artifacts are used as input to roles to performan activity, and are the result or output of such activities. In object-oriented terms, asactivities are operations on an active object (the role), artifacts are the parameters ofthese activities.

3.2.4 Disciplines

A mere enumeration of all roles, activities and artifacts does not constitute a process. Adiscipline is a sequence of activities that produces a result of observable value. In UMLterms, a discipline can be expressed as a sequence diagram, a collaboration diagram,or an activity diagram. There are nine predefined disciplines in RUP: (1) Businessmodeling, (2) Requirements, (3) Analysis & design, (4) Implementation, (5) Test, (6)Deployment, (7) Project management, (8) Configuration and change management, and(9) Environment.

These disciplines are described in more detail below.

17

Business modeling

The goals of Business modeling are as follows: (1) to understand the structure andthe dynamics of the organization in which a system is to be deployed (the target or-ganization), (2) to understand current problems in the target organization and identifyimprovement potentials, (3) to ensure that customers, end users, and developers havea common understanding of the target organization, and (4) to derive the system re-quirements needed to support the target organization.

Requirements

The purpose of the Requirements discipline is: (1) to establish and maintain agreementwith the customers and other stakeholders on what the system should do, (2) to providesystem developers with a better understanding of the system requirements, (3) to definethe boundaries of (delimit) the system, (4) to provide a basis for planning the technicalcontents of iterations, (5) to provide a basis for estimating cost and time to developthe system, and (6) to define a user-interface for the system, focusing on the needs andgoals of the users.

Analysis & Design

The purposes of Analysis & Design are: (1) to transform the requirements into a designof the system-to-be, (2) to evolve a robust architecture for the system, and (3) to adaptthe design to match the implementation environment, designing it for performance.

Implementation

The purposes of Implementation are: (1) to define the organization of the code, in termsof implementation subsystems organized in layers, (2) to implement classes and objectsin terms of components (source files, binaries, executables, and others), (3) to test thedeveloped components as units, and (4) to integrate the results produced by individualimplementers (or teams), into an executable system.

Test

The purposes of the Test discipline are: (1) to verify the interaction between objects,(2) to verify the proper integration of all components of the software, (3) to verify thatall requirements have been correctly implemented, and (4) to identify and ensure defectsare addressed prior to the deployment of the software.

Deployment

The Deployment Discipline describes the activities associated with ensuring that thesoftware product is available for its end users. The Deployment Discipline describesthree modes of product deployment: (1) the custom install, (2) the ”shrink wrap”

18

product, and (3) access to software over the internet. In each instance, there is anemphasis on testing the product at the development site, followed by beta-testing beforethe product is finally released to the customer. Although deployment activities peak inthe Transition Phase, some of the activities occur in earlier phases to plan and preparefor deployment.

Project Management

The purpose of Project Management is: (1) to provide a framework for managingsoftware-intensive projects, (2) to provide practical guidelines for planning, staffing,executing, and monitoring projects (3) to provide a framework for managing risk.

Configuration and Change Request Management

Configuration and Change Request Management (CM and CRM) involves: (1) identi-fying configuration items, (2) restricting changes to those items, (3) auditing changesmade to those items, and (4) defining and managing configurations of those items.

Environment

The purpose of the environment activities is to provide the software development orga-nization with the software development environment-both processes and tools-that willsupport the development team.

3.3 Best practices

RUP describes how to deploy ”best practices” that are commonly used in industryby successful organizations. These best practices are: (1) develop software iteratively,(2) manage requirements, (3) use component-based architectures, (4) visually modelsoftware, (5) verify software quality, and (6) control changes to software.

These practices are described in more detail below.

3.3.1 Develop software iteratively

Given today’s sophisticated software systems, it is not possible to sequentially firstdefine the entire problem, design the entire solution, build the software and then testthe product at the end. An iterative approach is required that allows an increasingunderstanding of the problem through successive refinements, and to incrementally growan effective solution over multiple iterations. The Rational Unified Process supports aniterative approach to development that addresses the highest risk items at every stagein the lifecycle, significantly reducing a project’s risk profile. This iterative approachhelps you attack risk through demonstrable progress - frequent, executable releases thatenable continuous end user involvement and feedback. Because each iteration ends

19

with an executable release, the development team stays focused on producing results,and frequent status checks help ensure that the project stays on schedule. An iterativeapproach also makes it easier to accommodate tactical changes in requirements, featuresor schedule. [6]

3.3.2 Manage requirements

The Rational Unified Process describes how to elicit, organize, and document requiredfunctionality and constraints; track and document tradeoffs and decisions; and easilycapture and communicate business requirements. The notions of use case and scenar-ios proscribed in the process has proven to be an excellent way to capture functionalrequirements and to ensure that these drive the design, implementation and testing ofsoftware, making it more likely that the final system fulfills the end user needs. Theyprovide coherent and traceable threads through both the development and the deliveredsystem. [6]

3.3.3 Use component-based architectures

The process focuses on early development and baselining1 of a robust executable archi-tecture, prior to committing resources for full-scale development. It describes how todesign a resilient architecture that is flexible, accommodates change, is intuitively un-derstandable, and promotes more effective software reuse. The Rational Unified Processsupports component-based software development. Components are non-trivial modules,subsystems that fulfill a clear function. The Rational Unified Process provides a system-atic approach to defining an architecture using new and existing components. These areassembled in a well-defined architecture, either ad hoc, or in a component infrastructuresuch as the Internet, CORBA, and COM, for which an industry of reusable componentsis emerging. [6]

3.3.4 Visually model software

The process shows you how to visually model software to capture the structure andbehavior of architectures and components. This allows you to hide the details and writecode using ”graphical building blocks.” Visual abstractions help you communicate dif-ferent aspects of your software; see how the elements of the system fit together; makesure that the building blocks are consistent with your code; maintain consistency be-tween a design and its implementation; and promote unambiguous communication. Theindustry-standard Unified Modeling Language (UML), created by Rational Software, isthe foundation for successful visual modeling. [6]

1The activities related to making a baseline

20

3.3.5 Verify software quality

Poor application performance and poor reliability are common factors which dramat-ically inhibit the acceptability of today’s software applications. Hence, quality shouldbe reviewed with respect to the requirements based on reliability, functionality, appli-cation performance and system performance. The Rational Unified Process assists youin the planning, design, implementation, execution, and evaluation of these test types.Quality assessment is built into the process, in all activities, involving all participants,using objective measurements and criteria, and is not treated as an afterthought or aseparate activity performed by a separate group. [6]

3.3.6 Control changes to software

The ability to manage change - making certain that each change is acceptable, andbeing able to track change - is essential in an environment in which change is inevitable.The process describes how to control, track and monitor changes to enable successfuliterative development. It also guides you in how to establish secure workspaces foreach developer by providing isolation from changes made in other workspaces and bycontrolling changes of all software artifacts (e.g., models, code, documents, etc.). Itbrings a team together to work as a single unit by describing how to automate integrationand build management. [6]

3.3.7 Other key features of the Rational Unified Process

In addition to the six best practices, there are three important features of RUP thatmust be mentioned:

• The role of use cases in driving many aspects of the development

• Its use as a process framework that can be tailored and extended by an adoptingorganization

• The need for software development tools to support the process

Use cases play the same role in RUP as scenarios or threads do in other object-oriented development methods. The use cases defined for the system are the foundationsfor the rest of the development process disciplines, especially requirements, design testand management. Use cases are also key to business modeling.

The Rational Unified Process can be used ”as is”, but it is also a process frameworkthat the adopting organization can modify, adjust, and expand to accommodate thespecific needs, characteristics, constraints, and history of its organization, culture, anddomain.

To be effective, a process must be supported by adequate tools. The Rational UnifiedProcess is supported by a vast palette of tools that automate steps in many activities[16] [20].

21

Chapter 4

Method

This chapter is an outline of the method used in this thesis to evaluate whether theRational Unified Process is usable for development of safety-related computer systemsaccording to the IEC61508 standard.

The evaluation process is divided into four phases:

• Identification of the IEC61508 requirements process selection criteria

• Identification of the RUP relevant process selection criteria

• Evaluation of the application of the requirements towards RUP

• Implementation of the IEC61508 requirements within RUP

An overview of the method is shown in Figure 4.1. This figure shows how thesephases provide a selection of IEC61508 requirements that are relevant to consider againstRUP.

The requirements are refined as shown in 4.2. The grey scribbled part shows thescope of the Safety RUP after the selection of requirements have been done.

22

Figure 4.1: Overview of the method

Figure 4.2: Requirements model

23

4.1 Defining the IEC61508 requirements process selectioncriteria

Since IEC61508 includes a large number of requirements, and not all of them are pro-cess related, we need to identify those requirements in IEC61508 relevant for RUP.This is done by defining different selection criteria to limit the requirements to processrequirements. Process requirements are requirements that ”put constraints upon thedevelopment process of the system” [15].

The requirements related to the development process might be divided into twoclasses: the requirements that are measurable (verifiable requirements) and those thatare not (intentions/spirit of the standard).

In addition to being process related, the selected requirements should be necessary,i.e. describe something no other requirement does.

In addition we must consider which of these requirements that are not relevantwithin the framework of RUP. These will not be considered for further refinement inthis thesis. RUP is basically a development process that covers a part of the timeframethat the safety lifecycle of IEC61508 considers. See the chapters on IEC61508 and RUPfor a further explanation of the RUP development process and the safety lifecycle ofIEC61508.

We will now describe each of the selection criteria in more detail.

4.1.1 Process related

Kotonya describes in [15] a process as ”an organised set of activities, which transformsinput to output”. Kotonyas definition of of a process is more general, but compatiblewith the process definition implied by RUP, so this will not represent a problem whenselecting process related requirements.

Figure 4.3: Basic process model

To select the relevant requirements of IEC61508 a process model combining a role-action model and an entity-relation model seems appropriate. Role-action models showthe roles of different people involved in the process and the actions that they take.Entity-relation models show the process inputs, outputs and intermediate results andthe relationship between them.

24

Figure 4.4: Process model

In this combined model the requirements related to the process is limited to therequirements that consider:

• input entities to activities

• activities to be performed

• roles that perform the activities

• intermediate entities

• output entities from activities

Note that both input and output entities in RUP terminology would be called ar-tifacts. These are not necessarily deliverables, but are e.g. models or documents thatupdated during the entire process lifecycle.

4.1.2 Necessary

A requirement is necessary in relation to the process description if it changes or in anyother way influences the entities, activities or roles mentioned above.

4.1.3 Verifiable

A requirement is verifiable if the impact of the requirement on the process is of such anature that it is possible through testing to verify that the requirement has been met.

These were the general process selection criteria, the next section contains the RUPrelated selection criteria.

25

4.2 Defining the RUP relevant process selection criteria

Since IEC61508 and RUP have a different focus it is reasonable to expect that not allprocess related criteria in IEC61508 are relevant in relation to RUP. We have thereforechosen to define explicitly a set of RUP relevant process selection criteria in Table 4.1.

The results from using these criteria are found in Chapter 5.

4.3 Evaluation of the application of the requirements to-wards RUP

When all relevant IEC61508 requirements have been identified, each of the requirementswill be considered against RUP by going through the following questions:

• Is this requirement met by the default configuration of RUP?

• Is this requirement in contradiction with RUP?

• How should this requirement be implemented within RUP?

A negative finding for the first question is not as problematic as the second question.If there are requirements in IEC61508 that contradict RUP it won’t be possible to definea development process compliant with both RUP and IEC61508. If we find requirementsthat are not met by the default configuration of RUP this only becomes a problem ifwe are not able to identify a RUP-compliant ”fix”. The third question will mainly bediscussed in a separate chapter.

4.4 Implementation of the IEC61508 requirements withinRUP

The results from the selection forms a basis for a discussion on how to implement eachof the requirements and the philosophy of IEC61508 within the framework of RUP andwhat changes and configurations that must me made to RUP to implement IEC61508.

This discussion is the basis for a suggested approach on how to use of the RationalUnified Process for assessment of safety-related computer systems as shown in Figure1.1.

26

Exclusion criteria DefinitionConcept Requirements that state conceptual questions, e.g. that are

of importance at the level of RUP but do not specify newentities, activities or roles.

Conformance Requirements that state how the requirements of the stan-dard must be followed, but do not specify new entities, ac-tivities or roles.

Content Requirements that will have impact on the quality of the en-tity to be produced but do not specify new entities, activitiesor roles.

Design Requirements that apply to the product to be produced, andnot to the process itself.

Hardware Requirements that are clearly hardware related.High-level Requirements that clearly are on a higher level than RUP.Low-level Requirements that clearly are on a lower level than RUP.Not covered Requirements that are beyond the scope of IEC61508. This

might sound a little strange, but IEC61508 contains require-ments that state the limits of the standard, e.g. requirement7.11.2: ”The specification to meet the safety functions re-quirements and safety integrity requirements for other tech-nology safety-related systems is not covered in this stan-dard”.

Not process Requirements that are not process related. That will bethe case e.g. when IEC 61508 states in a requirement thatsomething (e.g. hardware issues) are beyond the scope ofthe standard.

Time Requirements that are beyond the timeframe of RUP will beconsidered to not have relevance for this assessment, but areference to the planning documents required for this phaseswill be made.

Table 4.1: RUP relevant process selection criteria

27

Chapter 5

Selection of relevant IEC61508requirements

This chapter contains an overview of the results from the pre-selection process.It is shown how each requirement(or group of requirements) from the standard is

classified due to its type(entity, activity or role), with a short description, whetherit is considered to have process relevance, and a comment code that shows how thisrequirement is evaluated further in this thesis.

The comment codes that don’t refer to a section in the thesis are the same as theselection criteria from Chapter 4.

5.1 IEC61508-1

IEC61508-1 General Requirements contains requirements that basically calls for theproduction of documents and provide the requirements on how this documentationshall be produced and what it shall contain (to claim conformance to the standard).

IEC61508-1 nr. Type Description Process relevance Comment code

5.2.1-5.2.11 Entity Information None Content6.2.1-6.2.5 Entity, Management None High-level

Activity,Role

7.1.4.1- Conformance None Conformance7.1.4.87.2.2.1- Entity Information Single Thesis sec. 6.2.17.2.2.67.3.2.1- Entity Information Single Thesis sec. 6.2.27.3.2.5

28


7.4.2.1- Activity HR Analysis Single Thesis sec. 6.2.37.4.2.127.5.2.1- Activity, Requirements Single Thesis sec. 6.2.47.5.2.7 Entity7.6.2.1- Requirements Low-level7.6.2.13 allocation7.7.2.1- Entity Operation and Single Thesis sec. 6.2.57.7.2.2 maintenance7.8.2.1- Activity, Safety Single Thesis sec. 6.2.67.8.2.2 Entity validation7.9.2.1- Activity, Installation and Single Thesis sec. 6.2.77.9.2.2 Entity commissioning Single7.10.2 See IEC61508-27.11.2 None Not covered

in IEC615087.12.2 Not process7.13.2 Activity Installation and Single See 6.2.7

commissioning7.14.2 Activity Safety Single See 6.2.6

validation7.15.2 Activity, Operation, Single See 6.2.5

Entity maintenance,and repair

7.16.2.1- Activity, Modification Single Thesis sec. 6.2.87.16.2.7 Entity and retrofit7.17.2.1- Activity, Decommissioning Single Thesis sec. 6.2.97.17.2.7 Entity or disposal7.18.2.1- Activity, Verification Single Thesis sec. 6.2.107.18.2.4 Entity

8.2.1-8.2.14 None Thesis sec. 6.2.6(ex. 8.2.8) Activity, Functional Single Thesis sec. 6.2.11

Entity SafetyAssessment

Table 5.1: IEC61508-1 requirements consideration

5.2 IEC61508-2

IEC61508-2 Requirements for electrical/electronic/programmable electronic safety-relatedsystems contains mostly requirements that are related to hardware issues and are con-

29

sidered beyond the scope of this thesis. There are some requirements that are systemrelated without being directly related to hardware - these are treated as relevant re-quirements for this thesis.


7.1.3.1- E/E/PES safety Single Thesis sec. 6.3.17.1.3.5 lifecycle7.2.3.1- Entity E/E/PES safety Single Thesis sec. 6.3.27.2.3.3 requirements

specification7.3.2.1- E/E/PES safety None Hardware7.3.2.2 validation

planning7.4.2.1- E/E/PES design None Hardware7.4.2.8 and development7.4.3 Random HW faults None Hardware

7.4.4.1- Probability of None Hardware7.4.4.7 HW failure7.4.5.1- Architectural None Hardware7.4.5.6 constrains Hardware7.4.6 Proof and None Hardware

diagnostic tests7.4.7.1- Avoidance of None Hardware7.4.7.6 failures7.4.8.1- Control of None Hardware7.4.8.3 systematic faults7.4.9.1- E/E/PES None Hardware7.4.9.7 implementation7.5.2.1- E/E/PES None Hardware7.5.2.7 integration7.6.2.1- E/E/PES operation None Hardware7.6.2.5 and validation7.7.2.1- E/E/PES safety None Hardware7.7.2.5 validation7.8.2.1- E/E/PES None Hardware7.8.2.4 modification7.9.2.1- E/E/PES None Hardware7.9.2.10 verification


The reason for including IEC61508-2 is to make sure that all relevant requirements

30

within the three parts of IEC61508 that must be followed to claim conformance to thestandard (IEC61508-1, IEC61508-2 and IEC61508-3) are considered.

5.3 IEC61508-3

IEC61508-3 Software Requirements contains requirements related to the productionof software. These are the requirements that place constraints on how to use RUP,constraints on choices to be made in RUP etc. The requirements states which questionsto ask related to the development process, and places some constraints on the answers.


6.2.1-6.2.3 Software quality None Not processmanagement system

7.1.2.1- Activity, Software safety Single Thesis sec. 6.4.17.1.2.8 Entity lifecycle Single

requirements7.2.2.1- Activity, Software safety Single Thesis sec. 6.4.27.2.2.11 Entity requirements Single7.3.2.1- Activity, Software safety Single Thesis sec. 6.4.37.3.2.5 Entity validation planning Single7.4.2.1 Role Design method Concept Concept7.4.2.2- Design method None Design7.4.2.12 None7.4.3.1- Software Single See 6.3.17.4.3.3 architecture7.4.4.1 Tools and None Not process

programminglanguages

7.4.4.2 Tools and Single Thesis sec. 6.4.4programming

languages7.4.4.3 Tools and Single Thesis sec. 6.4.5



languages7.4.4.5 Tools and Single Thesis sec. 6.4.6



31


languages7.4.5.1 Detailed design None Not process

anddevelopment

7.4.5.2 Detailed design None Low-leveland

development7.4.5.3 Detailed design None Low-level

anddevelopment

7.4.5.4 Detailed design None Designand

development7.4.5.5 Detailed design None Design

anddevelopment

7.4.6.1 Code implementation None Design7.4.6.2 Activity Code implementation Single Thesis sec. 6.4.77.4.7.1 Activity Module testing Single Thesis sec. 6.4.87.4.7.2 Module testing None See 6.4.87.4.7.3 Entity Module testing Single Thesis sec. 6.4.87.4.7.4 Entity Module testing Single Thesis sec. 6.4.87.4.8.1- Activity, Integration Single Thesis sec. 6.4.97.4.8.5 Entity testing Single7.5.2.1- Programmable None Hardware7.5.2.8 electronics

integration7.7.2.1 Software None Thesis sec. 6.4.3

safety validation7.7.2.2 Activity, Software Single See 6.2.6

Entity safety validation7.7.2.3 Software None See 6.2.6

safety validation7.7.2.4 Software None See 6.2.6

safety validation7.7.2.5 Activity Software Single Thesis sec. 6.4.10

safety validation7.7.2.6 Software None Low-level


32



safety validation7.8.2.1- Software None See 6.2.87.8.2.10 modification7.9.2.1- Activity Software Single See 6.2.107.9.2.13 Entity verification


5.4 Summary of the requirements selection

The selection process has resulted in a basis for discussing how RUP may be imple-mented to provide a process that can be used to claim conformance to IEC61508. Therequirements that have been considered not relevant are of such nature that they willnot affect the development of the product that is produced with RUP.

33

Chapter 6

IEC61508 requirements relationto RUP

This chapter contains the considerations of the selected IEC61508 requirements towardsRUP.

6.1 Consideration of relation

The relation of each group (IEC61508 structure) of requirements selected are consideredagainst RUP by asking the following questions:

• Are these requirements met by the default configuration of RUP?

• Are these requirements in contradiction with RUP?

• How should these requirements be implemented within RUP?

The first question, whether these requirements are met by the default configurationof RUP, is answered as a simple check on whether the information required by eachgroup (IEC61508 structure) of requirements are met in the default configuration ofRUP.

The second question, whether the requirements are in contradiction with RUP, isanswered by considering if the information/activities required by each group of re-quirements must be specified by an approach that is incompatible with RUP, if theinformation/activities required by each group of requirements is specified by a differentapproach than RUP, but allows the RUP approach , or if the information/activities re-quired by each group of requirements are specified with the same approach or is possibleto add to RUP.

The third question, how the requirement should be implemented within RUP, is an-swered by a suggestion on how to follow the IEC61508 requirements within the frame-work of RUP. This discussion will be continued in the next chapter.

34

In the following subchapters is a thorough discussion of these questions for eachgroup of requirements.

6.2 General requirements

The titles of the subchapters 6.2.1-6.2.10 are the same as for the corresponding sectionsof chapter 7 of IEC61508-1. 6.2.11 corresponds with chapter 8 of IEC61508-1.

6.2.1 Concept

The objective of the concept activity is to develop a level of understanding of theEUC and its environment sufficient to enable the other safety lifecycle activities to besatisfactorily carried out, and to document this information. The requirements for theconcept activity are given in IEC61508-1 7.2.2.1-7.2.2.6.

During the required activities of this process the following information should beachieved:

• A thorough familiarity of the EUC

• The EUC’s required control functions

• The likely sources of hazards

• Information about the identified hazards

• Information about current safety regulations

• Hazards due to interaction with other EUC’s

Are these requirements met by the default configuration of RUP?

The information required by these requirements are not met by RUP.

Are these requirements in contradiction with RUP?

These requirements only calls for additional information and is therefore not in contra-diction with RUP.

How should these requirements be implemented within RUP?

These requirements can be implemented within RUP as an activity - Define Context -that is performed by a role - Safety Manager - and the result is an artifact - Conceptdefinition.

35

6.2.2 Scope definition

A scope definition document has to be produced. The objective is to determine theboundary of the EUC and the EUC control system, in addition to specify the scope ofthe hazard and risk analysis. The requirements for this document are given in IEC61508-1 7.3.2.1-7.3.2.5.

During the required activities of this process the following information should beachieved:

• The physical environment to be included in the scope of the hazard and riskanalysis

• The external events to be taken into account in the hazard and risk analysis

• The subsystems which are associated with the hazards

• The type of accident-initiating events that need to be considered (e.g. componentfailures, human error etc.)






These requirements can be implemented within RUP as an activity - Define Scope - thatis performed by a role - Safety Manager - and the result is an artifact - Scope definition.

6.2.3 Hazard and risk analysis

A hazard and risk analysis document has to be produced and updated throughout theoverall safety lifecycle. There are three objectives with the hazard and risk analysis:

• To determine the hazards and hazardous events of the EUC and EUC controlsystem

• To determine the event sequences leading to the hazardous events

• To determine the EUC risks associated with the hazardous events

The requirements for this document are given in IEC61508-1 7.4.2.1-7.4.2.12.Some important features of the hazard and risk analysis are the following:

36

• The hazard and risk analysis shall use information from the overall scope definition

• A further hazard and risk analysis shall be performed if the basis for the analysisis changed

• Consideration shall be given for the elimination of hazards

• The analysis shall cover all foreseeable circumstances

• The event sequences leading to a hazardous event shall be determined

• The likelihood of each hazardous event shall be evaluated

• The potential consequences shall be determined

Either qualitative or quantitative hazard and risk analysis techniques may be usedto meet the requirements for the hazard and risk analysis. The factors that can be usedto evaluate the appropriateness of the techniques are mentioned in IEC61508-1 7.4.2.9.

The expected form of the results of the hazard and risk analysis are mentioned inIEC61508-1 7.4.2.10.






These requirements can be implemented within RUP as an activity - Plan Hazard andrisk analysis - that is performed by a role - Safety Manager - and the result is an artifact- Hazard and risk analysis plan.

6.2.4 Safety requirements

A safety requirements specification document has to be produced. The objective isto develop a specification for the overall safety requirements in order to achieve therequired functional safety. The requirements for this document are given in IEC61508-17.5.2.1-7.5.2.7.

Some important features of the safety requirements specification are:

• A specification of the safety functions needed to obtain the required functionalsafety

37

• The necessary risk reduction for each hazardous event

• References to other standards where such are used to directly determine risk re-duction

• Failures that place demand on other E/E/PES


The information required by these requirements are not provided by RUP.




These requirements can be implemented within RUP as an activity - Specify safetyrequirements - that is performed by a role - Safety Manager - and the result is anartifact - Safety requirements specification.

6.2.5 Operation and maintenance

An overall operation and maintenance plan has to be produced. The objective is todevelop a plan for operating and maintaining the E/E/PE safety-related systems. Therequirements for this document are given in IEC61508-1 7.7.2.1-7.7.2.3.

The operation and maintenance plan shall specify the following:

• Routine actions of maintenance

• Actions and constraints necessary

• Results from functional audits and tests

• Information about hazardous events

• Scope of the maintenance activities

• Actions to be taken in the event of hazards occurring

• Contents of the chronological documentation of operation and maintenance



38




These requirements can be implemented within RUP as an activity - Plan operationand maintenance - that is performed by a role - Safety Manager - and the result is anartifact - Operation and maintenance plan.

6.2.6 Safety validation

A safety validation plan has to be produced. The objective is to develop a plan tofacilitate the validation of the E/E/PE safety-related systems. The requirements for thisdocument are given in IEC61508-1 7.8.2.1-7.8.2.2. The process shall be implementedand documented according to IEC61508-3 7.7.2.2, 7.7.2.3 and 7.7.2.4.

The safety validation plan shall specify the following:

• Details of when the validation shall take place

• Details of who shall carry out the validation

• Specification of the relevant modes

• Specification of E/E/PES to be validated for each mode

• The technical strategy for validation

• The measures, strategy and procedures used for allocation of safety functions

• Specific reference to each safety requirement

• The required environment for validation

• The pass and fail criteria

• The policies and procedures for evaluating the results of the validation





39


These requirements can be implemented within RUP as an activity - Plan safety vali-dation - that is performed by a role - Safety Manager - and the result is an artifact -Safety validation plan.

6.2.7 Installation and commissioning plan

A installation plan and commissioning plan has to be produced. The objective is todevelop a plan for the installation and a plan for the commissioning of the E/E/PEsafety-related systems. The requirements for these documents are given in IEC61508-17.9.2.1-7.9.2.2.

The contents of the installation plan shall specify:

• The installation schedule

• Those responsible for the installation

• The procedures for the installation

• The sequence in which the various elements are integrated

• Criteria for when a part is ready for installation and when installation is complete

• procedures for the resolution of failures and incompatibilities

The contents of the commissioning plan shall specify:

• The commissioning schedule

• Those responsible for different parts of the commissioning

• The procedures for the commissioning

• The relationships to the different steps in the installation

• Relationships to the validation





40


These requirements can be implemented within RUP as an activity - Plan installation -that is performed by a role - Safety Manager - and the result is an artifact - Installationplan, and as an activity - Plan commissioning - that is performed by a role - SafetyManager - and the result is an artifact - Commissioning plan.

6.2.8 Modification and retrofit

A modification and retrofit plan has to be produced prior to any modification or retrofitactivity. The objective is to develop a plan for the modification and retrofit of theE/E/PE safety-related systems to ensure that functional safety for the E/E/PE safetyrelated system is appropriate, both during and after the modification and retrofit phasehas taken place. The requirements for this document are given in IEC61508-1 7.16.1-7.16.2.7. The modification must be performed according to IEC61508-3 7.8.2.1-7.8.2.10.

Important issues in modification and retrofit planning are:

• The definition of an authorized request for modification or retrofit

• An impact analysis

• Chronological documentation of all modifications and retrofits






These requirements can be implemented within RUP as an activity - Plan modificationand retrofit - that is performed by a role - Safety Manager - and the result is an artifact- Modification and plan.

6.2.9 Decommissioning or disposal impact plan

A decommissioning and disposal impact plan has to be produced. The objective isto develop a plan for the decommissioning and disposal of the E/E/PE safety-relatedsystems. The requirements for this document are given in IEC61508-1 7.17.2.1-7.17.2.7.

Important issues in decommissioning or disposal planning are:

• The definition of an authorized request for decommissioning or disposal

41

• An impact analysis

• Procedures for shutting down or dismantling

• Chronological documentation of all decommissioning or disposal






These requirements can be implemented within RUP as an activity - Plan decommis-sioning and disposal - that is performed by a role - Safety Manager - and the result isan artifact - Decommissioning or disposal plan.

6.2.10 Verification plan

A verification plan has to be produced. The objective is to develop a plan for theverification of the E/E/PE safety-related systems. The requirements for this documentare given in IEC61508-1 7.18.2.1-7.18.2.4. The verification must be performed accordingto IEC61508-3 7.9.2.1-7.9.2.13.






These requirements can be implemented within RUP as an activity - Plan verification -that is performed by a role - Safety Manager - and the result is an artifact - Verificationplan.

42

6.2.11 Functional Safety Assessment

A functional safety assessment plan has to be produced. The objective is to develop aplan for the functional assessment of the E/E/PE safety-related systems. The require-ments for this document are given in IEC61508-1 8.2.8.

The contents of the functional safety assessment plan includes:

• Information about who that will undertake the functional safety assessment

• The output from the functional safety assessment

• The scope of the functional safety assessment

• The safety bodies involved

• The level of independence of those undertaking the functional safety assessment

• The level of competence of those undertaking the functional safety assessment




These requirements might on different levels be in contradiction with RUP. How andwhen is the subject of the next chapter in this thesis.


These requirements can be implemented within RUP as an activity - Plan functionalsafety assessment - that is performed by a role - Safety Manager - and the result is anartifact - Functional safety assessment plan.

6.3 Requirements for electric/electronic/programmable elec-tronic safety-related systems

The titles of the subchapters 6.3.1-6.3.2 reflects the corresponding software-related sec-tions of chapter 7 of IEC61508-2.

6.3.1 Safety lifecycle

The objectives of IEC61508-2 7.1.3.1-7.1.3.5 are to structure, in a systematic manner,the phases in the E/E/PES safety lifecycle (Figure 6.1) that shall be considered in orderto achieve the required functional safety of the E/E/PE safety-related systems, and to

43

Figure 6.1: E/E/PES Safety Lifecycle(in realization phase)

document all information relevant to the functional safety of the E/E/PE safety-relatedsystems throughout the E/E/PES safety lifecycle.

The specified safety lifecycle must be followed to claim conformance to IEC61508,or if another E/E/PES safety lifecycle is used it shall be specified during functionalsafety planning and all the objectives and requirements of each subclause of part 7.1 ofIEC61508 shall be met.


RUP does not contain a safety lifecycle as specified in IEC61508.


There are no clear contradictions, but one issue to be addressed is how to match av-model approach to the iterative process model of RUP. This is discussed in 7.2.1.

44


One way to implement these requirements in accordance with IEC61508, is to integrateeach of the predefined disciplines in RUP with the E/E/PES safety lifecycle. Anotherapproach would be to redefine the E/E/PES safety lifecycle to an iterative safety life-cycle. This is discussed further in 7.1.1.

6.3.2 E/E/PES safety requirements specification

A E/E/PES safety requirements specification has to be produced. The objective is todevelop a specification for safety requirements of the E/E/PE safety-related systems.The requirements for this document are given in IEC61508-2 7.2.3.1-7.2.3.3.






These requirements can be implemented within RUP as an activity - Specify safetyrequirements - that is performed by a role - Safety Manager - and the result is anartifact - E/E/PES safety requirements specification.

6.4 Software requirements

The titles of the subchapters 6.4.1-6.4.10 reflects the corresponding software-relatedsections of chapter 7 of IEC61508-3, but the titles are not the same because not allrequirements are relevant. The titles are chosen to reflect the contents of the require-ments.

6.4.1 Software safety lifecycle requirements

The objective of these requirements are to structure the development of the softwareinto defined phases and activities. This structure and its related requirements are givenin IEC61508-3 7.1.2.1-7.1.2.8.

Important issues are:

• A safety lifecycle shall be selected and specified

• Quality and safety assurance procedures shall be included in the safety lifecycle

45

• Each phase of the safety lifecycle shall be divided into elementary activities withthe scope, inputs and outputs for each phase

• It is acceptable to tailor the depth, number and work-size of the phases of theV-model

• It is acceptable to order the software project differently to the organisation ofthis standard (ie. use another software safety lifecycle model) provided all theobjectives and requirements of this clause are met

• For each lifecycle phase, appropriate techniques and measures shall be used

• The results shall be documented

• If at any stage of the software safety lifecycle, a change is required pertaining toan earlier lifecycle phase, then that earlier safety lifecycle phase and the followingphases shall be repeated


These requirements are not satisfied by RUP.


Selecting and specifying a safety lifecycle with defined scope, inputs and outputs in notin contradiction with RUP. However, an issue to be discussed further is the use of aniterative vs. a V-model development process. See 7.2.1 of this thesis.

Which methods and techniques that are appropriate are discussed in relation to thedifferent SIL levels in 7.4.

The requirement on how the safety lifecycle phases shall be repeated are also dis-cussed in 7.2.1 of this thesis.


How this should be implemented in RUP is suggested in 7.2.1, 7.4 and 7.2.1.

6.4.2 Software safety requirements specification

The objectives of these requirements are to specify requirements for software safety interms of the required safety functions and the requirements for software safety integrity,to specify the software requirements for the required safety functions for each E/E/PEsafety-related system needed to implement the required safety functions and to specifythe software requirements for software safety integrity for each E/E/PE safety-relatedsystem necessary to achieve the safety integrity level for each safety function.

46

In addition to be sufficiently detailed to allow the design and implementation toachieve the required safety integrity, and to allow an assessment of functional safety tobe carried out, the specification of the requirements for software safety shall consider:

• safety functions

• configuration or architecture of the system

• hardware safety integrity requirements (programmable electronics, sensors, andactuators)

• software safety integrity requirements

• capacity and response time performance

• equipment and operator interfaces


These requirements are not implemented by RUP.


These requirements are not in contradiction with RUP, but the software safety require-ments specification should interact with the Requirements Discipline. How this mightbe done is discussed in 7.2.2.


How this should be implemented in RUP is suggested in 7.2.2

6.4.3 Software safety validation planning

The objective of these requirements are to develop a plan for validating the softwaresafety. The software safety validation must provide results according to IEC61508-37.7.2.8

The plan for validating the software safety shall consider the following:

• when the validation shall take place

• who shall carry out the validation

• the relevant modes of the EUC operation

• identification of the safety-related software which needs to be validated for eachmode of EUC operation before commissioning commences

47

• the technical strategy for the validation (for example analytical methods, statis-tical tests etc. (see IEC61508-3 7.3.2.3)

• the measures (techniques) and procedures that shall be used for confirming thateach safety function conforms with (1) the specified requirements for the softwaresafety functions , and (2) the specified requirements for software safety integrity(see

• specific reference to the specified requirements for software safety

• the required environment in which the validation activities are to take place

• the pass/fail criteria (see IEC61508-3 7.3.2.5

• the policies and procedures for evaluating the results of the validation, particularlyfailures






These requirements can be implemented within RUP as an activity - Plan softwaresafety validation - that is performed by a role - Safety Manager - and the result is anartifact - Software safety validation plan.

6.4.4 Tool selection

The objective of these requirements are to select a suitable set of integrated tools,including languages, compilers, configuration management tools, and when applicableautomatic testing tools, in accordance with the required safety integrity level. The avail-ability of suitable tools (not necessarily those used during initial system development) tosupply the relevant services over the whole lifetime of the E/E/PE safety-related systemshould be considered. The tool selection must be performed according to IEC61508-37.7.2.7.



48


These requirements can not be said to be in contradiction with RUP because RUP doesnot require a specific set of tools, but RUP does suggest tools that may not be applicableat all SIL levels. See 7.4.


These requirements may be implemented in RUP by following the guidance in theappendix of IEC61508-3 on which techniques to use at the different SIL levels. See 7.4.

6.4.5 Programming language selection

The objective of these requirements are to provide requirements for the programminglanguage to be selected.

To the extent required by the safety integrity level, the programming language se-lected shall:

• have a translator/compiler which has either a certificate of validation to a rec-ognized national or international standard, or it shall be assessed to establish itsfitness for purpose

• be completely and unambiguously defined or restricted to unambiguously definedfeatures

• match the characteristics of the application

• contain features that facilitate the detection of programming mistakes

• support features that match the design method




These requirements can not be said to be in contradiction with RUP because RUPdoes not require a specific programming language, but RUP does suggest programminglanguages that may not be applicable at all SIL levels. See 7.4.


These requirements may be implemented in RUP by following the guidance in theappendix of IEC61508-3 on which programming language or subset of programminglanguages to use at the different SIL levels. See 7.4.

49

6.4.6 Coding standards

The objective of these requirements are to provide requirements for the coding standardto be selected:

Coding standards shall be:

• reviewed as fit for purpose by the assessor

• used for the development of all safety-related software

In addition the coding standards shall

• specify good programming practice

• proscribe unsafe language features (for example, undefined language features, un-structured designs, etc)

• specify procedures for source code documentation




These requirements can not be said to be in contradiction with RUP because RUP doesnot require a specific coding standard, but RUP does generate code that may not beapplicable at all SIL levels. See 7.4.


These requirements may be implemented in RUP by following the guidance in theappendix of IEC61508-3 on which coding standard to use at the different SIL levels.See 7.4.

6.4.7 Source code review

The objective of these requirements are to provide requirements for writing source code.The source code shall:

• be readable, understandable and testable

• satisfy the specified requirements for software module design

• satisfy the specified requirements of the coding standards

• satisfy all relevant requirements specified during safety planning

Each module of software code should be reviewed.

50




These requirements can not be said to be in contradiction with RUP because RUP doesnot require a source code review.


These requirements can be implemented within RUP in the Test discipline as an activity- Perform source code review - that is performed by a role - Safety Manager - and theresult is an artifact - Source code review.

6.4.8 Module testing

The objective of these requirements are to provide requirements for module testing.These requirements are:

• each software module shall be tested as specified during software design

• the test shall show that each software module performs its intended function anddoes not perform unintended functions

• the results of the software module testing shall be documented

• the procedures for corrective actions on failures of tests shall be specified




These requirements can not be said to be in contradiction with RUP because RUP doesnot require a module testing.


These requirements can be implemented within RUP in the Test discipline as an activity- Perform module testing - that is performed by a role - Safety Manager - and the resultis an artifact - Module test.

51

6.4.9 Integration testing

The objective of these requirements are to provide requirements for integration testing.The integration testing shall specify:

• the division of the software into manageable integration sets

• test cases and test data

• types of tests to be performed

• test environment, tools, configuration and programs

• test criteria on which the completion of the test will be judged

• procedures for corrective actions on failures of tests




These requirements can not be said to be in contradiction with RUP because RUP doesnot require integration testing.


These requirements can be implemented within RUP in the Test discipline as an activity- Perform integration testing - that is performed by a role - Safety Manager - and theresult is an artifact - Integration test.

6.4.10 Discrepancies

The objective of these requirements are to provide requirements for discrepancies.When discrepancies occur between expected and actual results, the analysis made

and the decisions taken on whether (1) to continue the validation, or (2) to issue a changerequest and return to an earlier part of the development lifecycle, shall be documentedas part of the results of the software safety validation.




These requirements can not be said to be in contradiction with RUP because RUP doesnot require information about discrepancies.

52


These requirements can be implemented as part of the software safety validation.

6.5 Summary of relations

Table 6.1 provide a summary of the results whether the requirements are met by thedefault configuration of RUP and whether they are compliant with RUP. The tablealso shows that it should be possible to define an instance of RUP within the scope ofIEC61508 by adding to and modifying RUP.

Table 6.1 uses the following legends:

• Are these requirements met by the default configuration of RUP? (assessment’Met by RUP’)

• Are these requirements not met, but can be met by adding e.g. artifacts to RUP?(assessment ’Added’)

• Are these requirements not met, but can be met by modifying RUP? (assessment’Modified’)

• Are these requirements not met, and can not be met by adding or modifying RUP?(assessment ’Contradiction’)

53

Section Description IEC61508 nr(part) Assessmentrequirements

6.2.1 Concept 7.2.2.1-7.2.2.6 (1) Added6.2.2 Scope definition 7.3.2.1-7.3.2.5 (1) Added6.2.3 Hazard and risk analy-

sis7.4.2.1-7.4.2.12 (1) Added

6.2.4 Safety requirements 7.5.2.1-7.5.2.7 (1) Added6.2.5 Operation and mainte-

nance7.7.2.1-7.7.2.2 (1) Added

6.2.6 Safety validation 7.8.2.1-7.8.2.2 (1) Added6.2.7 Installation and com-

missioning7.9.2.1-7.9.2.2 (1) Added

6.2.8 Modification andretrofit

7.16.2.1-7.16.2.7 (1) Added

6.2.9 Decommissioning anddisposal impact plan

7.17.2.1-7.17.2.7 (1) Added

6.2.10 Verification plan 7.18.2.1-7.18.2.4 (1) Added6.2.11 Functional safety as-

sessment8.2.8 (1) Modified

6.3.1 Safety lifecycle 7.1.3.1-7.1.3.5 (2) Modified6.3.2 E/E/PES Safety re-

quirements specification7.2.3.1-7.2.3.3 (2) Added

6.4.1 Software safety lifecyclerequirements

7.1.2.1-7.1.2.8 (3) Modified

6.4.2 Software safety require-ments specification

7.2.2.1-7.2.2.11 (3) Modified

6.4.3 Software safety valida-tion planning

7.3.2.1-7.3.2.5 (3) Added

6.4.4 Tool selection 7.4.4.2 (3) Modified6.4.5 Programming language

selection7.4.4.3 (3) Modified

6.4.6 Coding standards 7.4.4.5 (3) Modified6.4.7 Source code review 7.4.6.1 (3) Added6.4.8 Module testing 7.4.7.1 (3) Added6.4.9 Integration testing 7.4.8.1-7.4.8.4 (3) Added6.4.10 Discrepancies 7.7.2.5 (3) Added

Table 6.1: Summary of IEC61508 requirements relation to RUP

54

Chapter 7

Safety RUP

This chapter contains a suggestion on how to start implementing a Safety RUP. I wouldlike to stress that the Safety RUP is not just an ”add-on” to RUP, but rather an exten-sion that ”communicates” with other parts of RUP and that provide some conceptualissues to have in mind when performing the Safety RUP. This chapter contains foursections:

• A section on conceptual issues in an IEC61508 perspective.

• A section on conceptual issues in a RUP perspective.

• A section that describes a suggested Safety Discipline.

• A section that discusses how to handle the SILs.

7.1 Conceptual issues in an IEC61508 perspective

This section presents some issues of IEC61508 that is on a higher level than RUP, butthat are important in the process of implementing IEC61508.

7.1.1 The safety lifecycle

The construction of the safety lifecycle is very important in IEC61508. The process ofdefining the safety lifecycle itself provides an insight on how to claim conformance toIEC61508.

7.1.2 A unified approach

The primary purpose of IEC61508 is to provide a ”unified approach” for all safetylifecycle activities that is ”rational and consistent”. As such, the standard covers alllifecycle phases for all system components, from concept through decommissioning [9].

55

7.1.3 The spirit of the standard

It is important to follow the spirit of the standard - not only the letter of the standard.IEC61508 has a strong focus on the fact that just following the standard does notnecessarily result in better safety.

7.2 Conceptual issues in a RUP perspective

The ”best practices” defined in RUP defines the preferred conceptual basis for the RUPdevelopment process. These are met by requirements of IEC61508 that at first sightmight seem as a contradiction.

7.2.1 Develop software iteratively

RUP and IEC61508 require two different process models:

• RUP requires an iterative development process

• IEC61508 recommends, but does not require, a safety lifecycle V-model

RUP describes a development lifecycle with four phases (Inception, Elaboration,Construction, and Transition). Inside these phases the development is done in smalliterations. This is a spiral process. Spiral development is a family of software devel-opment processes characterized by repeatedly iterating a set of elemental developmentprocesses and managing risk so it is actively being reduced [1].

IEC61508-3 7.1.2.4 does more than suggest that the proper safety lifecycle model isthe V-model. The V-model identifies the major elements of the development processand indicates the sequential nature of much of the work. The V-model emphasizes atop-down approach to design and a bottom-up approach to testing. In descriptions ofthe V-model it is explained that such a model is just an approximation to the develop-ment process: in practice the various stages are not always performed in such a strictlysequential manner. There are usually some iterations, with a series of operations per-formed repeatedly until a satisfactorily result is obtained. A degree of parallelism isalso possible [25].

Sommerville describes in [24] this general model or paradigm of software develop-ment as the waterfall approach. In the waterfall approach the activities are representedas separate process phases such as requirements specification, software design, imple-mentation, testing and so on. After each stage it is ”signed off” and development goeson to the following stage.

A ”basic fallacy” of the waterfall model is that it assumes a project goes throughthe process once - and puts the system test, and therefore user testing at the endof the construction process. A ”second fallacy” is that it assumes that one builds awhole system at once, combining the pieces for an end-to-end system test after all

56

implementation design, most of the coding, and much of the component testing hasbeen done [13].

DOD-STD-2167 is based on the waterfall model. On the other hand, the majorreworking DOD-STD-2167A allows, but does not mandate, more recent models such asthe spiral model [13]. This is also the case with IEC61508 which allows other models,but does not contain information on how to apply them according to IEC61508.

7.2.2 Manage requirements

RUP and IEC61508 do both focus on the importance of requirements. RUP has defineda requirement management process represented in the Requirements Discipline. Thereare no specific contradictions in how to manage the requirements, but when specifyinga common requirements process one might consider consulting [15].

7.2.3 Use component-based architectures

A component-based software architecture enables the reuse of or customization of ex-isting components from thousands of commercially available sources [16].

IEC61508 requires that components should be identified as new or existing. Thestandard encourages conducting architectural analysis, analysis of alternatives, and fea-sibility studies to determine the optimum combination of design features needed toachieve the specified SIL. All interface designs should be analyzed to maximize theircontribution to safe and reliable performance. Evidence must be supplied to justify theuse of previously developed software; especially proof is needed that the software hasbeen certified for use in the current application domain at the same specified SIL (orhigher). Lacking this, previously developed software must undergo the same degree ofvalidation and verification activities as custom developed software [9].

A thorough discussion on how to use and assess safety-related software of unknownpedigree (SOUP) is provided in [5] and [21].

7.2.4 Visually model software

A model is a simplification of reality that describes a system from a particular perspec-tive. Models are built so that we can understand the system we are building better,and we build models of complex systems because we cannot comprehend such systemsin their entirety.

Modeling is important because it helps the development team visualize, specify,construct, and document the structure and behaviour of a system’s architecture [16] [2].For UML modeling of real-time systems see Douglass’ books [7] and [8].

IEC61508 is not primarily focused on ”how”, but on ”what”. Therefore IEC61508does not advocate use of visual modeling, but has a general positive approach to alltechniques that enhances the understanding of the system.

57

7.2.5 Verify software quality

As development progresses the cost of fixing problems are getting higher. For thisreason, it is important to assess continuously the quality of a system with respect to itfunctionality, reliability, application performance, and system performance.

Verifying a system’s functionality involves creating tests for each scenario, each ofwhich represents some aspect of the system’s desired behaviour [16].

IEC61508 does expects testing on a more rigid and formal level than RUP. RUPaddresses the concept of verification of software quality, but the choice of verificationtechniques provided in RUP is probably not useful for claiming conformance to toIEC61508 on a higher SIL than 1.

7.2.6 Control changes to software

A number of key challenges have to be resolved when you are developing software-intensive system. One problem is the management of change. When there are manydevelopers working on a project, the communication, traceability and management ofactivities and artifacts of great importance [16].

Again IEC61508 expects a more rigid and formal approach than the one provided byRUP and the choice of techniques provided in RUP in this field is probably not usefulfor claiming conformance to to IEC61508 on a higher SIL than 1.

7.2.7 Summary of conceptual issues

Although there are some major issues to be delt with when designing a developmentprocess that is based on RUP and that one is able to claim conformance to IEC61508with, the concept is not impossible. There are some pitfalls to be avoided - i.e. thatknowledge in practical use of IEC61508 is critical, but the overall assessment of theconceptual issues is acceptable.

7.3 Safety Discipline

As we have seen in Chapter 6 there are a number of additions that has to be made toobtain a ”Safety RUP” compliant with IEC61508. In this subchapter we will addressthese additions to RUP at a higher level, suggesting that they are combined to form a”safety discipline”.

The Safety Discipline is a suggestion of a discipline to be included in RUP at the samelevel as the other disciplines. The Safety Discipline, however, has a slightly differentapproach because it is not defined as detailed as the other disciplines because of itsrelation to IEC61508.

An effort to specify the Safety Discipline itself is considered part of the Safety RUPsolution described in this thesis. The issues to be addressed are identified in Chapter 6,

58

and the required activities are taken care of in the Safety Discipline. How this is doneis described in the next subsection.

This subchapter is structured in the same way as a typical discipline in RUP, i.e.purpose, relation to other disciplines, workflow, guidelines.

7.3.1 Purpose

The purpose of the Safety discipline is:

• to define the concept of the system

• to define the scope of the system

• to perform hazard and risk analysis when required

• to specify safety requirements of the system

• to plan operation and maintenance of the system

• to perform safety validation of the system

• to plan installation and commissioning of the system

• to plan modification and retrofit of the system

• to plan decommissioning or disposal of the system

• to verify the system

• to specify E/E/PES safety requirements

• to perform software safety validation of the system

7.3.2 Relation to other disciplines

The Safety discipline is related to other disciplines. These are:

• The Business modeling discipline provides requirements needed to support thetarget organization (e.g. ”our systems must never harm people”)

• The Requirements discipline provides primary input to the Safety discipline, andthe Requirements discipline gets primary input from the Safety discipline (e.g.safety requirements)

• The Analysis & Design discipline provides primary input to the Safety discipline,and the Analysis & Design discipline gets primary input from the Safety discipline(e.g. architecture requirements)

59

• The Implementation discipline provides primary input to the Safety discipline,and the Implementation discipline gets primary input from the Safety discipline(e.g. choice of programming language)

• The Test discipline provides primary input to the Safety discipline, and the Testdiscipline gets primary input from the Safety discipline (e.g. choice of testingtechnique)

• The Deployment discipline provides primary input to the Safety discipline, andthe Deployment discipline gets primary input from the Safety discipline (e.g. re-quirements to the documentation of installation procedure)

• The Project Management discipline provides primary input to the Safety disci-pline, and the Project Management discipline gets primary input from the Safetydiscipline (e.g. staffing issues due to requirement of independent reviews)

• The Configuration & Change discipline provides primary input to the Safety dis-cipline, and the Configuration & Change discipline gets primary input from theSafety discipline (e.g. documentation of the process itself)

• The Environment discipline provides primary input to the Safety discipline, andthe Environment discipline gets primary input from the Safety discipline (e.g.conceptual process requirements or tool requirements)

The other disciplines in RUP must be configured to receive input from the Safetydiscipline.

The following additions should be made to the Test discipline:

• An activity - Perform source code review - that is performed by a role - SafetyManager - and the result is an artifact - Source code review

• An activity - Perform module testing - that is performed by a role - Safety Manager- and the result is an artifact - Module test

• An activity - Perform integration testing - that is performed by a role - SafetyManager - and the result is an artifact - Integration test

7.3.3 Workflow of the Safety discipline

These activities/artifacts correspond with the selected requirements in Chapter 6 andshould be performed according to the related IEC61508 requirements.

The Safety Discipline will contain the following activities/artifacts:

• Define concept/Concept definition (See 6.2.1)

• Define scope/Scope definition (See 6.2.2)

60

• Plan hazard and risk analysis/Hazard and risk analysis plan (See 6.2.3)

• Specify safety requirements/Safety requirements specification (See 6.2.4)

• Plan operation and maintenance/Operation and maintenance plan (See 6.2.5)

• Plan safety validation/Safety validation plan (See 6.2.6)

• Plan installation/Installation plan (See 6.2.7)

• Plan commissioning/Commissioning plan (See 6.2.7)

• Plan modification and retrofit/Modification and retrofit plan (See 6.2.8)

• Plan decommissioning or disposal/Decommissioning or disposal plan (See 6.2.9)

• Plan verification/Verification plan (See 6.2.10)

• Plan functional assessment/Functional assessment plan (See 6.2.11)

• Specify E/E/PES safety requirements/E/E/PES safety requirements specification(See 6.3.2)

• Plan software safety validation/Software safety validation plan (See 6.4.3)

Each of these activities are assigned to the Role Safety Manager as suggested in 6.This does not necessarily mean that one person has to perform all these activities, butthat a Role has this responsibility. All RUP activities in RUP are assigned to roles inthis way.

7.3.4 Guidelines

When applying the Safety RUP, guidelines should be developed describing how to im-plement this process. A further discussion of this is, however, considered to be beyondthe scope of this thesis. The reason for not including such guidelines is that providingdetailed guidelines would be time-consuming and it would not contribute to keepingfocus in this thesis.

7.4 SIL levels, techniques and measures

This section discusses the concept of how suggested techniques and measures match agiven SIL level and how this relation affect the results in this thesis.

61

7.4.1 A normative guide

IEC61508-3 provides a normative guide to the selection of techniques and measures.With each technique or measure there is a recommendation for safety integrity levels(SILs) 1 to 4. These recommendations are as follows:

• HR: the technique or measure is highly recommended for this safety integritylevel. If this technique or measure is not used then the rationale behind not usingit should be detailed during the safety planning and agreed with the assessor

• R: the technique or measure is recommended for this safety integrity level as alower recommendation to a HR recommendation

• —: the technique or measure has no recommendation for or against being used

• NR: the technique or measure is positively not recommended for this safety in-tegrity level. If this technique or measure is used then the rationale behind usingit should be detailed during the safety planning and agreed with the assessor

The ranking of the techniques and measures is linked to the concept of effectivenessused in IEC61508-2. For all other factors being equal, techniques which are ranked HRwill be more effective in either preventing the introduction of systematic faults duringsoftware development or (for the case of the software architecture) more effective incontrolling residual faults in the software revealed during execution than techniquesranked as R.

7.4.2 SIL and Safety RUP

To claim a given SIL level one must either follow the recommendations in IEC61508and argue that safety has been obtained by following these recommendations, or onecould make the argument by establishing a ”safety case” based on other arguments andproofs. A major issue in IEC61508 is making this argument for why your choices withinthe framework of IEC61508 does provide a given Safety Integrity Level.

The assessment provided in this thesis is a top-down approach that does not reachthe level of detail where I consider it to be relevant to discuss how the techniques andmeasures suggested in the appendix IEC61508 comply to the specific guidelines of RUP.This is a question that should be considered for each system to be developed, anddiscussed in the relevant documents of that specific project.

However - at this point it seems that the Safety RUP will provide a framework thatcan be extended and modified in such a way that it is possible to establish a developmentprocess that is in conformance with IEC61508 at all SIL levels. The reason for this isthat there are no contradictions between IEC61508 and RUP at this abstraction level.

62

Chapter 8

Discussion

This section provides a discussion of the results of this thesis.

8.1 Why?

One aspect that I have not discussed in this thesis - until here - is: should we use RUPfor development of safety-critical systems? The title of the thesis is ”use of the RationalUnified Process for development of safety-related computer systems” and the focus ishow and is it possible instead of is this the right way to use RUP and IEC61508?.

Some of the reasons for evaluating this approach were:

• A common use argument - RUP is a de facto industry-standard developmentframework that is widely used - also for producing safety-related systems

• A research argument - this approach might provide valuable results for furtherresearch

• A communicating safety argument - the need for safety is communicated to thereader

First consider the common use argument - this is an argument that is based on theassumption that the main problem is that developers often do not assess safety at all.The need for safety is not known, or is at least not taken seriously by many developers,and thus safety will not be an issue. Integrating safety assessment in a commonly usedindustry standard - or at least provide some information on how to do it, will hopefullylead some developers to include safety in their development processes. As an integratedpart of the development process - safety will not only add to the value of the product,but will also provide status for the implementing organisation.

To contradict this argument: one could argue that the fact that a lot of peopleare using a process - is not an argument specifically for safety. There could be (andmost certainly is) other interests represented by different stakeholders. The reasons

63

for widespread common use might just as well be economical, time-related or that thisprocess is hyped at the moment.

The research argument is the easiest to acknowledge. Since the NATO conference onSoftware Engineering in 1968 [19] there has been a quest for the silver bullet of SoftwareEngineering. The situation is very much the same within the safety community. Atpresent there are those that argue that there might not be a silver bullet, just someusable techniques and measures that provide evidences and hopefully a comprehensiveargument that provides a convincing safety case.

As this is an argument for looking into the problem, it certainly is no argumentfor proving that this is a good approach. One of the main reasons that there are somuch confusion in software engineering about what is good and what is not, is theinherent complexity of software itself. Since software itself is complex, the techniquesand methods used to develop software are also complex. Simple techniques are likely tobe simple because they do not address the complexity to an acceptable degree.

The communicating safety argument is an argument that discussing safety issueswith different communities will ”spread the word” about basic concepts as hazard andrisk identification. This will lead to a better understanding of potentially dangeroussystems, and hopefully to higher safety in those systems.

To communicate safety terms and use of tools are easy. To apply this to obtainsafety is difficult. One of the messages from IEC61508 is that safety assessment is noteasy.

8.2 The method

The method suggested (described in 4) provides a simple, but structured way to selectand analyse the requirements of IEC61508.

A problem that must be carefully considered when using the method, is that theunderlying assumption that only a subset of the requirements of the standard is sufficientfor compliance to the standard. This is of course not the case. When the method wasapplied in this thesis, the entire standard is always considered as the main source forstandard related information.

The application of the method in this thesis was done with the assumption that thestandard itself is used as reference material when applying the Safety RUP, or whenconsidering the suggestions in this thesis.

8.3 The results

The results of the thesis contain suggestions on how RUP might be modified to allowan IEC61508 compliant development process. These results were provided in someconceptual and practical changes of RUP called the Safety RUP (presented in chapter7).

64

The idea of establishing a Safety discipline is inspired by the identification of threeclasses of processes present when producing dependable systems suggested in [14]:

• The system creation process

• Dependability processes

• Other supporting processes

In this thesis RUP provides the system creation process and parts of the othersupporting processes, while IEC61508 provides the dependability processes.

It is easy to make an argument that the Safety RUP approach is questionable. Atthis point the Safety RUP is nothing more than a vague description - and in this thesisI ask the question whether it should be anything more. The basis for such an argumentis that finishing the final version of Safety RUP is an important part of Safety RUPitself. The message is: we tell you what to do - but not how to do it, and the ownershipof the process itself is important. Furthermore - this approach is consistent with how Ifeel that IEC61508 should be implemented.

The Safety RUP is probably a good solution for those already using RUP or that isnot already using a well-defined development process. I do not think this approach isthe ”silver bullet” for developing safety-critical systems in compliance with IEC61508because of the complexity of IEC61508 that is not easily mapped to RUP. However -this solution is better than not doing any structured safety assessment within RUP.Through the development and use of the Safety RUP one get an understanding of therequirements that must be fulfilled even if this is not an optimal solution.

8.4 The work that has been done

During the process of making this thesis, a lot of small and some greater discoveriesabout RUP and IEC61508 has been made. They are not all documented here becauseof the goal and content of the thesis, but as a short summary I would like to add thatdespite the impressive verbiage of IEC61508 it is important to try to read between thelines of the standard: what did the writers of this clause think when they wrote this?

A lot of concrete requirements of both the process and conceptual issues are definedin IEC61508, but still it is important to try to discover the true spirit of the standard.This will provide helpful guidance when considering how to solve a specific problem.

8.5 Relation to other work

This thesis uses a ”top-down” approach to analyse the relation between safety and RUP.The starting point is the concepts and requirements of the standard, and its relation tothe overall framework of RUP.

65

8.5.1 The dependability-explicit development model

Kaaniche et al. presents in [14] the dependability-explicit development model - a devel-opment model focused at the production of dependable systems. This model explicitlyincorporate the means for dependability (i.e., fault prevention, fault tolerance, faultforecasting, and fault removal).

We share the view that there is a need for a systematic and structured frameworkthat integrates dependability concerns at the very early stages of the development pro-cess, but instead of combining an established framework (like RUP) and a standard (likeIEC61508) Kaaniche et al. provide more generalized descriptions and a more generalapproach.

8.5.2 CORAS

The CORAS project [17] is using a ”bottom-up” approach to analyse the relation be-tween security and semi-formal modeling. With focus on how risk assessment may beperformed in relation to semi-formal modelling, e.g. UML, the CORAS project assessesthe basic building blocks of RUP.

Although the two approaches are different, they are also in a sense complementary.The results of this thesis and the results from the CORAS project will hopefully providecomplementary results. The CORAS project provides suggestions on how to use thetechniques and measures suggested in IEC61508 (although in a security context), whilethis issue is considered to be the baseline of low level in this thesis.

8.6 Further work

A suggestion for further work could be to refine the work done in this thesis to provideinput to the development of RUP. This work could be based on IEC61508 and theCORAS project to provide a generic safety/dependability approach.

Another suggestion is to implement the Safety RUP and to document feedback fromthat experience. It would probably result in some valuable input, both on the practicaluse of RUP when developing a safety-critical system, but also more general on the useof IEC61508 in a ”non-waterfall” development process.

66

Chapter 9

Conclusions

This chapter provides the conclusion on the method used, the results and an answer towhether RUP can be used for assessment of safety-critical systems.

9.1 Method

The main conclusion is that the method used to find out how RUP may be used forassessment of safety-related computer systems was acceptable and provided results asa basis for further work.

9.2 Results

The results of the thesis is a suggestion on how to use the requirements of IEC61508within the framework of RUP. These results are provided in some conceptual and prac-tical changes of RUP called the Safety RUP (presented in chapter 7).

9.3 Can RUP be used for development of safety criticalsystems?

The answer on this question is: yes, but there are some important conceptual andpractical issues to be considered by the developer before this approach is acceptable.

67

Bibliography

[1] Barry W. Boehm. A spiral model of software development and enhancement. IEEEComputer, 21(5):61–72, May 1998.

[2] Grady Booch. Object-Oriented Analysis and Design with Applications. Addison-Wesley, second edition edition, 1994.

[3] Grady Booch et al. The Unified Modeling Language User Guide. Addison-Wesley,1999.

[4] J. Brazendale. IEC 1508 Functional safety: Safety related systems, Proceedings2nd IEEE International Software Engineering Standards Symposium Aug. 1995,pp. 8-17. IEEE Computer Science Press, 1995.

[5] P K D Froome C Jones, R E Bloomfield and P G Bishop. Methods for assessing thesafety integrity of safety-related software of unknown pedigree (soup). TechnicalReport 337/2001, Adelard, London, UK, 2001.

[6] Rational Software Corporation. Rational unified process - best practices for soft-ware development teams. A Rational Software White Paper, 1998.

[7] Bruce Powel Douglass. Real-Time UML. Addison-Wesley, 1998.

[8] Bruce Powel Douglass. Doing Hard Time. Addison-Wesley, 1999.

[9] Debra S. Herrmann. Software Safety and Reliability. IEEE Computer Society, 1999.

[10] IEC. http://www.iec.ch/61508.

[11] IEC. Functional safety of electrical/electronic/programmable electronic safety-related systems (iec61508), 1997.

[12] Ivar Jacobson et al. The unified software development process. Addison Wesley,1999.

[13] Frederick P. Brooks Jr. No silver bullet. IEEE Computer, 20(4), April 1987.

68

[14] Mohamed Kaaniche and others(Eds.). A dependability-explicit model for the de-velopment of computing systems. SAFECOMP 2000, LNCS 1943, pages 107–116,2000.

[15] Gerald Kotonya and Ian Sommerville. Requirements engineering. John Wiley &Sons Ltd., 1998.

[16] Philippe Kruchten. The Rational Unified Process - An Introduction. Addison-Wesley, 1999.

[17] Ketil Stølen. A framework for risk analysis of security critical systems. In supple-ment of the 2001 International Conference on Dependable Systems and Networks,pages pages D4 – D11, July 2-4 2001. Gothenburg, Sweden.

[18] Nancy G. Leveson. Safeware. Addison-Wesley, 1995.

[19] P.Naur and editors B.Randell. Software engineering, report on a conference. Tech-nical report, NATO Scientific Affairs Division, Garmisch, 1968.

[20] Leslee Probasco. The ten essentials of rup. Rational Software White Paper, 2000.

[21] P K D Froome R E Bloomfield and P G Bishop. Justifying the use of software of un-certain predigree (soup) in safety-related applications. Technical Report 336/2001,Adelard, London, UK, 2001.

[22] Eric S. Raymond. The Jargon File. http://tuxedo.org/jargon/html/index.html,2001.

[23] James Rumbaugh et al. The Unified Modeling Language Reference Manual.Addison-Wesley, 1999.

[24] Ian Sommerville. Software Engineering. Addison-Wesley, 6th edition edition, 2001.

[25] Neil Storey. Safety-Critical Computer Systems. Addison-Wesley, 1996.

69

use of the rational unified process for development of ...borres/mastersarchive/rune-thesis.pdfthere...

Documents