detailed requirements for the common certification language d4 · practices, user needs and...

Collaborative Large-scale Integrating Project

Open Platform for EvolutioNary Certification Of

Safety-critical Systems

Detailed requirements for the common

certification language

D4.2

Work Package: WP4: Common Certification Language

Dissemination level: PU

Status: Final

Date: 03rd

August 2012

Responsible partner: RINA Services s.p.a.

Contact information: [email protected]

PROPRIETARY RIGHTS STATEMENT

This document contains information, which is proprietary to the OPENCOSS Consortium. Neither this document nor

the information contained herein shall be used, duplicated or communicated by any means to any third party, in

whole or in parts, except with prior written consent of the OPENCOSS consortium.

Contributors

Document History

Version Date Remarks

V0.1 May 31, 2012 ToC

V0.2 July 25, 2012 Version ready for peer-review

V0.3 August 01, 2012 Version ready for PB review

V1.0 August 03, 2012 Final version

Names Organisation

Vincenzo Manni, Giorgio Tagliaferri RINA Services s.p.a.

Fran Ruiz, Huáscar Espinoza TECNALIA Research & Innovation

Luna Yaping Luo Eindhoven University of Technology

Alberto Melzi Centro Ricerche Fiat

Inspearit

Katrina Attwood, Oleg Lisagor University of York

Fabien Belmonte, Laurent de la Beaujardière Alstom Transport

Adrian Larkham Atego

D4.2

FP7 project # 289011 of 59

TABLE OF CONTENTS

Abbreviations and Definitions ................................................................................................................ 5

Executive Summary................................................................................................................................ 6

1 Introduction ............................................................................................................................... 7

1.1 Purpose .................................................................................................................................... 7

1.2 Scope ........................................................................................................................................ 8

1.3 Usage Scenarios of CCL .......................................................................................................... 10

1.3.1 Scenario 1: Safety Argumentation and Compliance Management ..........................11

1.3.2 Scenario 2: Evidence Chain Repository .....................................................................11

1.3.3 Scenario 3: Process Assurance and Transparency ....................................................12

1.4 Overview ................................................................................................................................ 13

2 Requirements for the Common Certification Language ............................................................. 15

2.1 External interface requirements ............................................................................................ 17

2.1.2 Interface requirements .............................................................................................17

2.2 Features of the Common Certification Language .................................................................. 20

2.2.1 Feature 1: Capture of consistent assurance concepts ..............................................20

2.2.2 Feature 2: Analysis of consistent assurance concepts ..............................................22

2.2.3 Feature 3: Representation of safety-related concepts .............................................25

2.2.4 Feature 4: Management of safety-argument contracts ...........................................29

2.2.5 Feature 5 Evidence management .............................................................................33

2.2.6 Introduction/purpose of the feature ........................................................................33

2.2.7 Feature 6: Compliance Management .......................................................................34

2.3 Features of the CCL editor ..................................................................................................... 36

2.4 Performance requirements .................................................................................................... 36

2.4.1 Level of abstraction of domain-specific assurance concepts ...................................37

2.5 Design constraints .................................................................................................................. 37

2.5.1 Meta-modelling language to specify CCL ..................................................................38

2.5.2 Reuse of existing OMG language concepts ...............................................................38

2.5.3 Planning for future re-use of CCL ..............................................................................38

3 Traceability of requirements .................................................................................................... 39

4 Conclusions .............................................................................................................................. 41

5 References ............................................................................................................................... 43

6 Annex: Considerations for the specification of requirements ..................................................... 47

6.1 Requirement specification: development process overview ................................................ 47

6.2 Requirements Management and the other requirement processes ..................................... 49

6.2.1 Requirements Elicitation ...........................................................................................50

6.2.2 Requirements Analysis ..............................................................................................51

6.2.3 Requirements Specification ......................................................................................51

6.2.4 Requirements Validation...........................................................................................52

6.3 Characteristics of well-formed requirements ........................................................................ 52

6.4 Requirement pitfalls ............................................................................................................... 54

7 Annex: Glossary ....................................................................................................................... 56

D4.2


List of Figures

Figure 1 – Scope of interest of the OPENCOSS CCL .......................................................................................... 9

Figure 2 - Usage Scenarios of CCL ................................................................................................................... 10

Figure 3 – Use of CCL for Safety Argumentation and Compliance Management ........................................... 11

Figure 4 – Use of CCL for the Evidence Chain Repository ............................................................................... 12

Figure 5 – Use of CCL for Process Assurance and Transparency .................................................................... 13

Figure 7 - Status of a CCL requirement .......................................................................................................... 16

Figure 8 - Conceptual Synthesis ...................................................................................................................... 20

Figure 9 - Template of the CCL performance requirements ........................................................................... 36

Figure 10 - Context for developing CCL Requirements Specification ............................................................. 49

Figure 11 – The Role of Requirements Management in Evolutionary Development ..................................... 50

Figure 12 - Key Processes of Requirements Engineering ................................................................................ 50

List of Tables

Table 1 - Characteristics of well-formed requirements .................................................................................. 54

D4.2


Abbreviations and Definitions

API Application Programming Interface

ARM Argumentation Metamodel

CCL Common Certification Language

CENELEC Comité Européen de Normalisation Electrotechnique (European Committee for

Electrotechnical Standardization)

COTS Commercial-Off-The-Shelf

DoW Description of Work

EC European Commission

EN European Standard

EU European Union

FMEA Failure Modes and Effects Analysis

GSN Goal Structuring Notation

HLR High Level Requirement

HW Hardware

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

ISO International Standards Organization

ISA Independent Safety Assessor

MOF Meta-Object Facility

OMG Object Management Group

OPENCOSS Open Platform for EvolutioNary Certification Of Safety-critical Systems

OWL Web Ontology Language

RA Requirements Analysis

R&D Research and Development

RM Requirements Management

SAEM Software Assurance Evidence Metamodel

SBVR Semantics of Business Vocabulary and Business Rules

SIL Safety Integrity Level

SoS Systems of Systems

SW Software

UML Unified Modeling Language

V&V Verification and Validation

WP Work Package

XMI XML Metadata Interchange

XML eXtensible Markup Language

D4.2


Executive Summary

This document represents the second deliverable of OPENCOSS WP4. This WP aims at defining a common

conceptual and notational framework for specifying certification assets (the Common Certification

Language), as a means to get mutual recognition agreement and to be employed to discuss abstract

notions from different domains.

In theory using a common conceptual framework for different certification standards enables management

of claims, evidences and arguments in a common format, sharing patterns of certification assessment, and

allowing cost-effective re-certification between different standards.

In the light of these considerations, this deliverable focuses on the definition of the features of the CCL and

its external interfaces with other potential components of the OPENCOSS platform.

In addition to this, the list of functional and non-functional requirements associated to each feature of the

Common Certification Language is defined, as well as any potential constraint impacting the architecture of

this framework. Finally an analysis of the potential direct and indirect relationships between the elicited

requirements is described.

Therefore, D4.2 represents a crucial input from which part of the future work in WP4 will be performed.

In particular, the conceptual model that is going to be defined in D4.3 as the semantics of the Common

Certification Language will have to meet the driving requirements defined by D4.2.

D4.2


1 Introduction

1.1 Purpose

Safety assurance and certification are amongst the most expensive and time-consuming tasks in the

development of safety-critical embedded systems. European innovation and productivity in this market is

curtailed by the lack of affordable (re)certification approaches. Major problems arise when evolutions to a

system entail reconstruction of the entire body of certification arguments and evidence. Further, market

trends strongly suggest that many future embedded systems will be comprised of heterogeneous, dynamic

coalitions of systems of systems. As such, they will have to be built and assessed according to numerous

standards and regulations. Current certification practices will be prohibitively costly to apply to this kind of

embedded systems.

The OPENCOSS project aims to devise a common certification framework that spans different vertical

markets for railway, avionics and automotive industries, and to establish an open-source safety

certification infrastructure. The infrastructure is being realised as a tightly integrated solution, supporting

interoperability with existing development and assurance tools. The ultimate goal of the project is to bring

about substantial reductions in recurring safety certification costs, and at the same time increase product

safety through the introduction of more systematic certification practices. Both will boost innovation and

system upgrades considerably.

In this context, WP4 aims at defining a Common Certification Language (CCL), which will work as a means

to get mutual recognition agreement between two different views and conceptual approaches:

• The safety case-based approach, promoting safety certification as a judgment based on a body of

material that should consist of claims, evidence and argument. The argument makes the case,

based on the evidence, that the claims are satisfied.

• The standard-based approach, indicating a level of rigor in the processes and workflows used to

build the final system and specifying the intermediate artifacts to be produced (requirements,

specifications, test plans, etc.), the kinds of reviews, and analyses that should be performed, and

the documentation that should record all of these.

The CCL will provide a common language for these two approaches and will be employed to discuss

abstract notions from different domains of safety-critical embedded systems, with the aim of providing a

structured way for argumentative reasoning about safety requirements and constraints across multiple

schemes.

It will be also used to build domain-specific libraries of certification meta-models, which will act as a

knowledge database providing information about safety-related standards.

Finally the use of a common conceptual framework for different certification standards should enable

management of claims, evidences and arguments in a common format, sharing patterns of certification

assessment, thus paving the way for cost-effective re-certification between different standards.

This deliverable (D4.2), in particular, takes advantage of the relevant state-of-the-art and currently best

practices, user needs and high-level requirements from the different application domains captured in WP2

and in section 6 of D4.1 [Ref. 6]; based on these information, the purpose of D4.2 is to define the

functional and non-functional requirements allowing the Common Certification Language:

• to be employed to discuss abstract notions from different domains of safety-critical systems,

D4.2


• to be used to build domain-specific libraries of certification models, acting as a knowledge

database,

• to be used for the management of claims, evidences and arguments using a common notation,

• to promote the adoption of patterns of certification assessment,

• to be used to perform compliance checks against safety-related standards,

• to support a component-based modelling formalism to specify certifiable components, and their

evidential interface, as a notation to represent a compositional certification approach.

1.2 Scope

As identified in deliverable D2.1 [Ref. 4], the OPENCOSS project aims to develop technology, provide

guidance on compliance assessment, safety argumentation and certification as well as to support the reuse

of safety assurance assets, associated with particular reusable system components – across system

development projects within and across safety-critical domains.

Several types of reuse can be envisaged:

a) providing guidance about how to comply with standards and regulations. This includes the

definition of a structured conceptual and tool framework to store knowledge about standards,

their interpretations, and the strategies/decisions to comply with standards,

b) reusing argumentation and evidence for a next version of a safety critical system, within a project

or organisation,

c) reusing a safety case for a component or a subsystem of a new system, possibly across domains,

d) reusing (part of) a safety case in order to show compliance to another standard,

e) reusing (part of) a safety case in order to show compliance to another country-level set of rules,

f) reusing and improving a safety case in order to regain confidence, for example after a catastrophic

accident,

g) reusing (part of) a safety case for a system in another domain,

h) providing transparency about the safety assurance and certification processes by improving the

awareness of the level of compliance and safety assurance process evolution to the different

stakeholders in manufacturer, supplier, and assessor companies. This also includes the definition of

functionalities to provide metrics and estimation about the costs, effort and time incurred in these

processes.

One of the approaches by which the OPENCOSS will facilitate the reuse of safety assurance assets is the

Common Certification Language (CCL). CCL shall enable the OPENCOSS platform to have a common

“certification language”, as a means to get mutual recognition of and to discuss abstract notions from

different domains. Using a common conceptual framework for different certification standards facilitates

the management of claims, evidences and arguments in a common format, allows patterns of certification

assessment to be shared, and supports cost-effective re-certification between different standards.

One major challenge for CCL is how to derive specific solutions from the general case in relation to the

wide variety, partial inconsistency, semantic discrepancy and various “national flavours” of the existing

standards across the avionics, railway, and automotive domains. As illustrated in Figure 1, the proposed

approach should follow a layered strategy to manage complexity.

D4.2


Co

nce

ptu

al le

vel

Top Level GoalThe ‘aircraft’ is acceptably safe for

operations

Argument based on a comprehensive safety case to reduce risk via a safe design, safe operation and safe

environment

ContextAcceptably Safe

ContextSOIU

Top Level GoalThe ‘aircraft’ is acceptably safe for

operations


environment


ContextSOIU

Goal 3Safety management arrangements are such that the

interface between the ‘aircraft’, its operating infrastructure and the environment in which the ‘ai rcraft’

is operated is maintained adequately safe.

Goal 2‘Aircraft’ operations are managed and carried out with appropriate

safety

Goal 4Co-ordinated safety management activities

ensure that all risks remain broadly acceptable or tolerable and ALARP, or

management action is initiated

Goal 1The design and build of the

‘aircraft’ is such that the aircraft may be operated safely.








safety


safety











Top Level GoalThe ‘aircraft’is acceptably safe for

operations


environment


ContextSOIU

Top Level GoalThe ‘aircraft’is acceptably safe for

operations


environment


ContextSOIU




Goal 2‘Aircraft’operations are managed and carried out with appropriate

safety





‘aircraft’is such that the aircraft may be operated safely.








safety


safety











Sta

nd

ard

-sp

eci

fic

Pro

ject

-sp

eci

fic

Safety assurance &

certification processes

Safety cases

& evidence

repository

Process execution

assessment

CCL provides the core

concepts organized in

semantically related groups

Compliance managementSafety Argumentation

Evidence Characterization

IEC 61508EN 50126

ISO 26262

Gu

ida

nce

National

Rules

Re

qu

ire

me

nts

FAR 25

EN 50128

EN 50129

EN 50159

ARP4761

ARP4754

DO297

DO178

DO254

UE rules

ERMTSUE

216/2008

CS 25

IR 21 PART 21

Cert. Project

Railways X

Cert. items

Railways X.1

Cert. Project

Avionics Y

Cert. items

Avionics X-Y.1

Re

-use

Definition of certification scope

Cert. items

Railways X.2Cert. items

Avionics Y.2

Figure 1 – Scope of interest of the OPENCOSS CCL

The CCL should identify shared safety principles and concepts as an "intersection set" of safety principles

from different standards. This is the first layer in Figure 1, called the conceptual level. As identified in

deliverable D4.1 [Ref. 6], the CCL should address three conceptual levels:

• specification of safety argumentation

• specification of evidence characterization

• specification of compliance management

Reuse of safety assurance assets is hampered by the fact that there is no agreement between the

terminology used in the standards and safety culture in each of the OPENCOSS target domains. There are

significant differences between the fundamental concepts of assurance, in terms of the embedded

assumptions about process, evidence and system characteristics embedded in claims of compliance and/or

safety. A simple word-for-word translation between the requirements of standards in different domains is

possible in some cases. Instead, the CCL should provide a terminological and conceptual synthesis at the

conceptual layer to address some of the discrepancies between the safety standards and safety cultures in

the various OPENCOSS domains.

The standard-specification layer should use the CCL to build domain-specific libraries of certification

models, which should act as a knowledge database, providing information about safety-related standards

(e.g., EN50126, ISO 26262, DO-178 B/C). Any generic product could be first assessed against these libraries.

Further standard library refinements enable more specific requirements, considering application domains

and then even national aspects. Of course, the "cross acceptance" of the first layers is also a legal issue,

OPENCOSS shall start from the technical point of view and point out some normative issue that should be

addressed for making practicable in the actual regulatory schemes.

D4.2


The final layer defines project-specific certification activities, both from the process and the product-

centric safety assurance perspectives.

1.3 Usage Scenarios of CCL

CCL is the backbone of the OPENCOSS Platform. CCL provides the set of common concepts and their

relationships that will be used to automate a number of OPENCOSS activities. In this sense, CCL is just a

kind of exchange data scheme that will be implemented and used in different ways. We envisaged at least

three ways of usage scenarios for CCL (Figure 2):

1. CCL as the specification language for argumentation and to demonstrate compliance with

standards/regulations. Argumentation will be concretized in (compositional) safety cases, and

compliance demonstration will be concretized with means to specify standards/regulations and

their interpretations as well as with means to measure the level of compliance of a given safety

assurance project with its prescribed standards/regulations.

2. CCL as the data scheme to create a repository of traceable evidences (evolutionary evidential

chain). While this is strongly linked to the previous usage scenario, the way such an evidential

chain repository will be implemented would need to consider some data management

functionalities such as change management, traceability management, among others.

3. CCL as the language to specify prescribed processes (activities, roles, artifacts) and means to

specify quantitative information about the assurance and certification processes. This includes the

mechanisms to measure the level of compliance of the actual safety-critical engineering processes

with the prescribed process.

CCL (Conceptual Model)

Multiple CCL Usage Scenarios

Imp

lem

en

tati

on

Safety Argumentation &

Compliance Management

Evidence Chain

Repository

Process Assurance and

Transparency

Conceptual Concerns

Figure 2 - Usage Scenarios of CCL

This set is defined for explanation purposes only. We do not claim that it is fully complete since the

understanding of them may evolve during the CCL design activities. The three scenarios are linked between

them (e.g., safety argumentation includes “evidence models” that are linked to specific evidence databases

that manage evidence life cycle, traceability, and evolution) and there may be concepts that are

used/shared at more than one implementation scenario (e.g., the “artifact” concept must be handled by

the three implementation scenarios).

D4.2


In the following, we describe these scenarios by referring its implementation to a set of preliminary

architectural modules for the OPENCOSS platform.

1.3.1 Scenario 1: Safety Argumentation and Compliance Management

This is the main scenario since it supports the central concept of the OPENCOSS platform: the safety case

development and maintenance. This scenario shall support two different concerns or functionality groups

(depicted in green in ):

1. Safety Case Specification. It includes the definition of safety goals including those related to

conformance with standards and regulations, safety arguments and link to evidence

characterization models. It may include further specification and implementation mechanisms to

manage reuse of arguments and more formalized arguments.

2. Compositional Certification. It includes the functionality to manage argumentation modularity,

assumptions, guarantees, as well any other concept to support more formalized argument

composition.

Candidate (combination of) implementation approaches are Models (e.g., Eclipse EMF models), Ontologies

(e.g., OWL), SBVR (for formalization of textual propositions in arguments), among others.

Safety Argumentation and

Compliance Management Concepts

Common Certification Language (CCL) Editor

Safety CaseSpecification

Compositional Certification

Modular Safety Argumentation

Information

Figure 3 – Use of CCL for Safety Argumentation and Compliance Management

1.3.2 Scenario 2: Evidence Chain Repository

This CCL usage scenario is related to the definition of the information repository to manage evidences. The

rationale behind defining a separate scenario for evidence management is that evidences are sensitive

information to be managed by the OPENCOSS platform. Evidence is sensitive because:

• It relates to work products resulting from the safety-critical development life cycle. This

information needs special care in terms of visibility to external users (e.g., security access)

D4.2


• Evidences may be obtained by automatic communication with external (engineering) tools and

this may imply special care to maintain the evolution of evidence versions, changes, etc.

Three functionality groups may impact on the CCL definition:

1. Traceability Management. Links between evidences and parts of evidences shall be maintained in

a proper way. Traceability can have many semantic variants (parent/children, dependency,

reference, etc) and CCL must support these different concepts of traceability.

2. Change Impact Analysis. This is related to the management of changes in evidence and its impact

in other evidences but also in arguments. CCL shall provide concepts to support e.g., delta

certification efforts.

3. Evidence Life-cycle manager. This functionality manages creation, state, and ownership (among

others) of evidences. CCL shall include concepts to capture this information as part of the evidence

characterization information.

Evidence Characterization

Concepts

Evidential Chain ManagementC

omm

. M

anag

er

Dat

a M

anag

er

Traceability Manager

Change Impact Manager S

ecur

ity

Man

ager

Evidence ManagementInformation

Evidence Life-Cycle Manager

Figure 4 – Use of CCL for the Evidence Chain Repository

1.3.3 Scenario 3: Process Assurance and Transparency

This scenario deals with CCL concepts that support the transparency and compliance-awareness during the

execution of the various processes in engineering and certifying safety-critical systems. The goal is to

connect the engineering development process with the safety assurance and certification processes in a

way that OPENCOSS platform users and other engineers involved in the development process are aware of

the costs, efforts and level of compliance of processes with standards. Two basic functionality groups are

essential for CCL:

1. Process Compliance Manager. This implies mechanism to inform OPENCOSS users about their

obligations to comply with standards (activities to realize, work products to produce, roles to

respect, etc.). At the same time, existing tools for process management may create argumentation

and evidence and this may be directly linked from process management tools to the OPENCOSS

platform information. For instance, one company using BPMN tools to specify, orchestrate and

execute processes would need to connect the tool information with the OPENCOSS safety

assurance and certification information. To do so, CCL must support the link/association to

process-specific concepts (activities, roles, artifacts, etc.)

D4.2


2. Metrics and Estimations Manager. This functionality group provides support to create customized

metrics and algorithms to produces estimations on the various aspects of safety assurance and

certification. CCL shall create conceptual means to quantitatively and qualitatively measure

attributes of concepts such as arguments, evidence, etc.

Process Assurance Concepts

Safety Process Assurance and Transparency

ALM/PLM Cloud

Process Compliance Manager

Metrics and Estimations Manager

Certif. ProcessModels

Figure 5 – Use of CCL for Process Assurance and Transparency

1.4 Overview

This deliverable defines the detailed requirements for the Common Certification Language. The status of

each requirement will pass through several steps, as indicated in Figure 7, and will be assigned a priority

using the MoSCoW technique [Ref. 7]. Anyway, elicitation of requirements is an intrinsic iterative process

which is not, in general, self-terminating. Requirements evolve at an uneven pace and tend to generate

further requirements from the definition processes.

Thus, it is possible that the current proposed version of requirements specification will be changed or

expanded further. Moreover, the requirements for the CCL editor will be completed at a more advanced

stage of WP4.

This deliverable is organized as follows:

• Section 2 contains both the functional and non-functional requirements of the CCL, organized in a

structured way. In particular,

o Section 2.1 describes the relationships and dependencies between the Common

Certification Language and the potential other components of the OPENCOSS platform

o Section 2.2 defines the features of the Common Certification Language, for each of which

an introduction describing its purpose and the reasons and/or intentions for its definition

is inserted, followed by the list of specific low-level functional requirements

o Section 2.3 is dedicated to the definition of the CCL editor and its main functionalities (this

section will be completed at a more advanced stage of WP4)

o Section 2.4 defines the performance and quality metrics for the CCL (interoperability,

expressiveness etc.)

o Section 2.5 presents the potential design constraints impacting the architecture of the CCL

D4.2


• Section 3 aims at underlying the relationships and dependencies between the CCL features and

their associated requirements, so as to facilitate the analysis of the impact of any specific change in

the CCL on the rest of this framework.

• Section 4 contains the conclusions

• Section 5 contains the list of relevant references for this deliverable

• Section 6 is an Annex containing relevant considerations for the specification of requirements. In

particular,

o Section 6.1 describes the development process overview for the specification of

requirements

o Section 6.2 presents the requirements management process and its relationships with the

other requirements processes: elicitation, analysis, specification and validation.

o Section 6.3 summarizes the characteristics of well-formed requirements and describes the

strategy adopted to ensure that the CCL requirements have these characteristics

o Section 6.4 describes the common pitfalls in the requirements’ specification process.

• Section 7 contains the glossary used for the elicitation of the requirements of the Common

Certification Language.

D4.2


2 Requirements for the Common Certification Language

In this section the list of the requirements for the Common Certification Language is presented. As stated

in 6.1, the requirements development process, in general, interfaces with:

• stakeholders

• the technical community.

• the environment.

All these “actors” influence each other and have an impact on the functionalities of the CCL.

As a consequence, an iterative/evolutionary development approach for this deliverable has been adopted

and the list of features/requirements contained in this version of the deliverable could be modified in

following deliveries.

Here below the main processes of requirements engineering presented in 6.2 are considered and tailored

for the formulation of the requirements for the Common Certification Language.

In particular, CCL Requirements Elicitation has been performed on the basis of the content of D2.1 [Ref. 4].

With regard to Requirements Analysis and Specification, the requirements for the CCL have been

clustered on the basis of high-level features and presented in this deliverable taking advantage of the

schema proposed in section A.5 of [Ref. 1]. In particular, the following template has been used to describe

the functional requirements associated to any feature:

Figure 6 - Template for the definition of the CCL functional requirements

The ID of any functional requirement follows the following template:

ID: XX_YY

With

XX= feature number

YY= ascending number associated to the requirement

The field “Description” is used to summarize the purpose of the functional requirement, while the field

“Rationale” contains the reasons or intentions leading to the definition of the functional requirement.

Aiming to define well-formed requirements and to avoid potential misunderstandings in their future

implementation, their description has been done following the strategy described in section 6.3 for

obtaining well-formed requirements. In addition to this, a glossary of the relevant terms used for the

definition of the requirements is presented in section 7. It has to be noted that this glossary is inherited

D4.2


from deliverable D2.1 [Ref. 4]: it has been inserted in this deliverable to make it self-referencing and to

make it easier for the reader to understand the meaning of the crucial terms used along the deliverable.

The following field (“Stakeholders”) is used to indicate the potential stakeholders of the functional

requirement; a number of direct and indirect stakeholder groups have been identified for the OPENCOSS

project and its principal product, the OPENCOSS platform. These stakeholders are analysed in detail in

Section 6.2 of deliverable D2.1 [Ref. 4].

In addition to this, throughout the OPENCOSS project the field “Status” of any requirement can go through

the states “Proposed”, “Approved”, “Implemented”, “Rejected”or “Future Enhancement”, as shown in

Figure 7, and a new version of the deliverable could be envisaged in the course of the project (e.g. at the

end), once the requirements will be selected and consolidated into the common platform.

Figure 7 - Status of a CCL requirement

Finally a priority is assigned to each requirement, using the MoSCoW prioritisation technique.

According to [Ref. 7], the MoSCoW categories are as follows:

• M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to

be considered a success.

• S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible.

This is often a critical requirement but one which can be satisfied in other ways if strictly

necessary.

• C - COULD: Describes a requirement which is considered desirable but not necessary. This will be

included if time and resources permit.

• W - WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a

given release, but may be considered for the future

Focusing the attention on Requirements Validation, a first review of the requirements contained in this

deliverable will be carried out validating them against the characteristics defined in section 6.3; this activity

will be conducted during the internal review of the deliverable itself. The establishment of how a

requirement will be verified (i.e. the description of its acceptance tests) will be done after its approval and

is consequently not contained in this first version of the deliverable, where the status of all requirements is

set to “Proposed”.

D4.2


2.1 External interface requirements

2.1.1.1 Introductory

Within the OPENCOSS Project, the Common Conceptual Language will serve as an enabling technology,

providing a means by which other aspects of the Platform and Approach developed within the project are

able to facilitate the reuse of assurance assets. Although the CCL itself will be delivered as a tangible asset,

in the form of a series of interconnected models, it is important to realise that the theoretical approach it

provides to reuse is also a crucial deliverable of the project, and must be communicated to future users of

the OPENCOSS Platform. It is important to realise that – because of the imperfect and possibly subjective

nature of the mappings between assurance concepts that the CCL will capture – the final OPENCOSS

Platform will not be able to provide a completely automated solution to the reuse of assurance assets

across or within domains. Instead, the Platform will provide very detailed information concerning the

appropriateness, limitations and possible extent of reuse, which will support human engineers in the

development of assurance cases and compliance packs for future systems, and assessors in appraising

these. This decision-support is founded on the concept of concept-matching between assurance cases, the

extent of which it is the business of the CCL to indicate. Therefore, it is essential that future users of the

Platform have a good understanding of the theoretical basis of the CCL approach, in order to be able to

interpret and make use of the services the Platform will offer.

At this early stage in the OPENCOSS project – while both the Platform and the overall OPENCOSS Approach

are still very much in the conceptual stage -, it is difficult to formulate detailed requirements on the CCL’s

external interfaces. In particular, it should be noted that the realisation of the CCL – in terms of tooling – is

very much undecided: this is the focus of Task T4.3, and is out of scope of the current version of this

deliverable. Nor is the nature of the end user’s actual interaction with the CCL itself at all clear – it is

currently unclear whether there will be any direct interaction at this level, beyond the detailed feedback

outlined in the previous paragraph. Nonetheless, focussing on the conceptual aspects of the CCL, it is

possible to indicate some requirements on the CCL, which are hopefully sufficiently detailed to permit

further development of the conceptual model, while at the same time remaining sufficiently abstract that

they do not pose artificial constraints on future tooling and approaches developed either in T4.3 or

elsewhere in the Project. These requirements will be elaborated as the work on the project progresses,

and will be refined in future iterations of this deliverable.

2.1.2 Interface requirements

This section contains the list of the interface requirements; the template presented in Figure 6 is used in

this section, but a different ID is used in this specific case, so as to distinguish the interface requirements

from the functional ones. In particular, they will be identified using the following strategy:

ID: INT_XX

With

XX= ascending number

D4.2


2.1.2.1 Readability of the CCL conceptual model by a safety engineer

INT_01

Description The conceptual model of the CCL shall be readable by a human safety engineer with

adequate training in the selected modelling approach and the rationale of the CCL.

Rationale Although it is not yet clear whether the end user of the OPENCOSS Platform or

approach will have a need for direct contact with the CCL, it is clear that this

requirement is necessary for validation, development and editing of the model.

Stakeholders Developer, Safety Engineer

Status Proposed

Priority M

2.1.2.2 Readability of the CCL conceptual model by other tools

INT_02

Description The conceptual model of the CCL shall be machine-readable

Rationale There is likely to be a need for the CCL to interface with tooling to be supplied by the

OPENCOSS Platform

Stakeholders OPENCOSS Platform, Developer

Status Proposed

Priority M

2.1.2.3 Representation technique of the CCL conceptual model

INT_03

Description The conceptual model of the CCL shall be presented using an implementation-

independent representation technique

Rationale Since the interface requirements from tools yet to be developed elsewhere in the

project are not yet clear, the CCL should be represented as generically as possible, for

the time being

Stakeholders OPENCOSS Platform

Status Proposed

Priority M

2.1.2.4 Presentation of the feedback provided by the CCL

INT_04

Description The feedback to be provided by the CCL shall be presentable (either directly, or by

machine intervention) in a manner which is readily intelligible to a human safety

engineer with adequate training in the selected modelling approach and the rationale

of the CCL.

Rationale It is not currently clear whether the feedback will be mediated through the “CCL

editor” or some other tool, but there is a clear need for the human user to be able to

understand the feedback and its import.

Stakeholders User

Status Proposed

Priority M

D4.2


2.1.2.5 Reuse of an artefact in a given context: qualitative indication

INT_05

Description The feedback to be provided by the CCL should include a qualitative indication of the

possibility of reuse of a given artefact in a given context.



understand the feedback and its import.

Stakeholders User

Status Proposed

Priority M

2.1.2.6 Reuse of an artefact in a given context: quantitative indication

INT_06

Description The feedback to be provided by the CCL should include quantitative feedback on the

extent to which reuse of an artefact is possible in a given context.



understand the limitations on potential reuse.

Stakeholders User

Status Proposed

Priority M

2.1.2.7 Guidance on the limitations on reuse of an artefact in a context

INT_07

Description The feedback to be provided by the CCL should include guidance on the limitations

on reuse of an artefact in a given context.



understand the limitations on potential reuse.

Stakeholders User

Status Proposed

Priority M

2.1.2.8 Provision of the rationale for the indications of reusability

INT_08

Description The feedback to be provided by the CCL should include a clear statement of rationale

for the indications of ‘reusability’ given.



understand the limitations on reuse, the acceptability of reuse and the rationale for

the guidance given.

Stakeholders User

Status Proposed

Priority M

D4.2


2.2 Features of the Common Certification Language

2.2.1 Feature 1: Capture of consistent assurance concepts

2.2.1.1 Introduction/purpose of the feature

At the heart of the OPENCOSS project is the reuse of safety assurance assets between projects in different

domains, although it also considers reuse within the same domain.

The term “safety assurance asset” refers to any of the reusable artefacts which are produced in the

development, assessment and justification of a safety-critical product. In general terms, this implies any of

the artefacts which might be used in the demonstration of the safety of the product – either in a safety

argument approach or a simple compliance checklist -, including requirements statements at different

levels of detail, analysis results, test results, test plans, designs and specifications and safety argument

fragments (claims, modules, lines of reasoning etc.). Assets are originally developed in a source domain, and will be reused in a target domain; each of these

domains is governed by linguistic and conceptual norms – the language and concepts of the safety

standards, safety practices, interpretations and best practice within the domain.

As a consequence, problems related to the translation of language tokens from the source context to the

target context, as well as significant differences between the fundamental concepts of assurance (in terms

of the embedded assumptions about process, evidence and system characteristics embedded in claims of

compliance and/or safety) make it a challenge a “word-for-word” translation between the requirements of

standards in different domains.

In the light of the situation described above, it becomes important for the Common Certification Language

to define a set of generic and domain-specific terms; matching of the domain-specific terms and concepts,

allowing cross-domain and intra-domain re-use of safety assets, is thus achieved mapping each domain-

specific term/concept (known as the “signifier”) with the term/concept (known as the “signified”) it

denotes, and thus a mapping between signifiers is achieved with respect to the (conceptual) signifier (see

Figure 8) . However, it has to be underlined that the extent to which full matching between terms and

concepts can be achieved is highly variable, depending on the precise cultural assumptions governing

usage in the individual domains, and how far a meaningful synthesized term or concept can be defined to

preserve and match these assumptions.

Common concept, represented in

synthesised term (signified)

Term/concept used in domain A

(signifier)

Term/concept used in domain B

(signifier)<<total or partial

mapping of terms, wrt the underlying

concept>>

<<total or partial coverage of concept>>

<<total or partial coverage of concept>>

Figure 8 - Conceptual Synthesis

D4.2


The OPENCOSS CCL, therefore, will provide a metamodel which will define and record key concepts

relevant to safety assurance within the target domains and the relationships between them. This

metamodel will be used to provide the terms and concepts used in the project to characterize reusable

assets (“evidence assets”, “argumentation assets” and “process assets”) within the project, such that

safety engineers can take an informed decision about the appropriateness and implications of reusing a

given asset between domains.

In addition to this, a series of mappings, indicating the relationships between terms and concepts used in

the OPENCOSS domains of interest and the synthesized terms shall be provided.

Nevertheless, it has to be noted that the establishment of the mappings between terms and concepts from

a domain to another is relatively straightforward when referring to “real” things, but becomes problematic

when considering constructed terms within a specific domain, which have no intrinsic meaning, when

withdrawn from that context.

In terms of the CCL, the “solution” to this problem is to relate the source term to some higher-level

conceptual term, which provides some mapping to a term in the target language.

Anyway, mapping to a higher-level conceptual term only provides a workable solution if the higher-level

conceptual term is at a reasonable level of detail, as compared with the original term: too abstract, and the

‘translation’ between domains will be only superficial; too detailed, and there is a risk of being bogged

down in unnecessary linguistic niceties.

2.2.1.2 Associated functional requirements

2.2.1.2.1 Capture of consistent generic assurance concepts

01_01

Description The CCL shall capture consistent generic definitions of core assurance concepts

relevant to safety assurance from across the target domains

Rationale These assurance concepts will allow the definition a set of generic terms in the

“signified” layer (see Figure 8), that will be used for mapping a signifier from a specific

domain A to a signifier belonging to another domain B and to make it feasible to take

an informed decision about the appropriateness and implications of reusing a given

asset between domains or within the same domain.

This strategy is of particular importance whenever no simple word-to-word

translation between the requirements of standards and/or fundamental concepts of

assurance (in terms of the embedded assumptions about process, evidence and

system characteristics embedded in claims of compliance and/or safety) is possible.

Stakeholders Safety Engineer, ISA

Status Proposed

Priority M

D4.2


2.2.1.2.2 Capture of consistent domain-specific assurance concepts

01_02

Description The CCL shall capture consistent domain-specific definitions of core assurance

concepts relevant to safety assurance

Rationale Domain-specific assurance concepts are characterized by embedded assumptions

about process, evidence and system that typically make it a challenge to re-use them

in another domain; this critical situation is emphasized by the fact that each domain

is governed by linguistic and conceptual norms – the language and concepts of the

safety standards, safety practices, interpretations and best practice within the

domain.

Consequently it becomes of vital importance to succeed in understanding the context

related to a domain-specific safety concept and to speculate on its potential mapping

to generic definitions of those core assurance concepts described in 2.2.1.2.1.


Status Proposed

Priority M

2.2.1.2.3 Capture of relationships between assurance concepts

01_03

Description The CCL shall capture the essential relationships between assurance concepts, in

terms of required relationships and dependencies between them

Rationale Distributed organizations, especially multinationals, often decide on global policies

for governance. These would address regulatory compliance, but also other aspects

of governance, including operational management, quality management, risk

management, product and service standardization, and documentation. The policies

have to be adopted by operational units, taking account of local conditions, including

regulation, culture and work practices.

The effect is that global policies for governance – including those for regulatory

compliance – have the role of regulations at local level.

Consequently, it becomes necessary to record the relationships and dependencies

between generic, domain-specific and enterprise-specific assurance concepts.

In addition to this, relationships and dependencies between the assurance concepts

is likely to indicate dependencies between aspects of the argument, which must be

preserved in a compositional structure. This is the means by which argument

modules are characterised.


Status Proposed

Priority M

2.2.2 Feature 2: Analysis of consistent assurance concepts


As indicated in Section 2.1 above, it is envisaged that the CCL will serve as an enabling technology for the

OPENCOSS Platform in its role of supporting human safety engineers and assessors in making decisions

about the appropriate reuse of assurance artefacts within or across domains. Reuse is hampered by the

fact that there is no agreement between the terminology used in the standards and safety culture in each

of the OPENCOSS target domains: indeed, often, the same term will be used in subtly different ways in

more than one document across (or sometimes within) domains. This kind of mismatch is, however, more

than simply a matter of terminology: examinations of standards and safety practices within the domains

D4.2


reveal that the expectations as to what must be demonstrated in order for safety to be assured differ

markedly. There are significant differences between the fundamental concepts of assurance, in terms of

the embedded assumptions about process, evidence and system characteristics embedded in claims of

compliance and/or safety. No simple word-for-word translation between the requirements of standards in

different domains is possible.

It is our intention that the CCL should provide some alleviation of the discrepancies between the safety

standards and safety cultures in the various OPENCOSS domains, by providing terminological and

conceptual synthesis at the conceptual layer. As outlined in Section 2.1, and to be discussed in greater

detail in the technical deliverable 4.3, however, complete matching between the concepts and terms used

in the different domains will rarely, if ever be possible – the mappings are themselves subjective and

coverage is likely to be imperfect.

The CCL will, however, be able to supply considerable guidance to the safety engineers and assessors as to

the appropriateness of reusing a given artefact in a particular context. This will provide a major benefit of

the OPENCOSS Platform and Approach in industrial use. In this section, we detail some of the analysis

results that will be made available to the user as a result of the use of the CCL.

It is important to note that some of these requirements are likely to be refined into requirements on

tooling to be developed in WP4, 5 or 6 as the project progresses. In the absence of detailed decisions on

tooling provision at the present time, they have been expressed generically as requirements on things the

conceptual model of the CCL should support. It is likely that the requirements will be further decomposed

and refined in future iterations of this deliverable and the requirements documents for WPs 5 and 6.


2.2.2.2.1 Analysis of matches between assurance concepts from different domains

02_01

Description The conceptual model of the CCL shall support the detailed comparison of assurance

concepts from distinct domains or standards.

Rationale It is a requirement of OPENCOSS that we are able to “translate” assurance artefacts

between projects developed according to different standards or the norms of

different domains. The CCL needs to provide the underlying conceptual mapping by

which this translation can be achieved.

Stakeholders User, developer

Status Proposed

Priority M

2.2.2.2.2 Relationships between standard/company/domain and the CCL

02_02

Description The CCL shall allow the establishment of relationships between

standard/company/domain specific terms and the conceptual synthesis of terms

provided by the CCL.

Rationale This is a refinement of the previous requirement, making clear that the CCL needs to

provide detailed mappings between its conceptual layer and the domain-specific

models.

Stakeholders Developer, user

Status Proposed

Priority M

D4.2


2.2.2.2.3 Analysis of the match between concepts from distinct domains or standards

02_03

Description The conceptual CCL shall indicate where there is an imperfect match between

concepts from distinct domains or standards.

Rationale The CCL should give an engineer sufficient information to facilitate the decisions

he/she makes in preparing an argument, so the CCL needs to provide full information

to inform that decision – i.e. it should be clear which elements of the two concepts

match, and the degree to which they match.


Status Proposed

Priority M

2.2.2.2.4 Indication of the nature of the match between concepts from distinct domains or standards

02_04

Description The CCL shall provide a means for indicating the nature of the match between

concepts from distinct domains or standards, where a “satisfactory” match is

detected.


he/she makes in preparing a safety argument/compliance argument, so the CCL

needs to provide full information to inform that decision. I.e. it should be clear which

elements of the two concepts match, and the degree of the match.


Status Proposed

Priority M

2.2.2.2.5 Automated provision of guidance as to the aspects of two concepts from different domains or

standards not matching

02_05

Description The conceptual model of the CCL shall support the provision (automated) of guidance

to a safety engineer as to the aspects of a concept which do not match precisely

between a source and a reused concept


he/she makes in preparing a safety argument/compliance argument, so the CCL

needs to provide full information to inform that decision. I.e. it should be clear which

elements of the two concepts match, and the degree of the match. This will facilitate

the provision of automated advice as to what remains to be done to make an asset

reusable.


Status Proposed

Priority M

D4.2


2.2.3 Feature 3: Representation of safety-related concepts


OPENCOSS aims to define a common conceptual and notational framework language (CCL) to support a

structured way for argument-based reasoning about safety requirements and constraints, for the

description of the safety/certification processes and the safety analysis techniques used by the

manufacturers for the demonstration of compliance to safety standards.

In addition to this, a main goal of the CCL is to facilitate the reuse of safety assurance assets, associated

with particular reusable system components within and across the automotive, avionics and railway

domains. To this regard, from the return of experience of the manufacturers involved in the OPENCOSS

project, it is extremely important for the Common Certification Language to support the reuse of a

component/system within a domain, but in a new specific “environment” (e.g. cross-country reuse in the

railway domain), characterized by specific normative constraints/objectives different from those present in

the original one. The CCL shall be capable of capturing them, to identify those constraints addressing the

same need and to compare them with respect to attributes of equivalence, inclusion, partial inclusion or

disjuncture.

What is also evident is that re-use of both safety-related assets and components/sub-systems requires a

clearer description of the claims, assumptions, context etc. on which any process of compliance to a safety

standard is based.

Finally, the CCL will be used for an analysis of the completeness of the safety-related documentation

created for a project, thus paving the way for the future implementation of specific functionalities allowing

what-if analyses regarding the correctness and the confidence vested in any safety argument.

On the basis of these considerations, a detailed list of functional requirements for the CCL related to the

representation of safety-related concepts is provided below.


2.2.3.2.1 Description of requirement coverage

03_01

Description The CCL shall provide support for satisfying safety and certification requirements

(standard, functional, non-functional, process, conformity, etc.) by evidences.

Rationale The coverage matrix between requirements and evidences is one essential part of the

safety demonstration.


Status Proposed

Priority M

2.2.3.2.2 Capture of specific safety normative constraints/objectives

03_02

Description The CCL shall provide support to capture specific normative constraints/objectives

within one industrial domain. (These specific national constraints may be written in

different national languages).

Rationale This requirement is requested to perform cross-country certification. Indeed,

National Safety Authorities impose specific normative constraints. The user has to

identify the constraints that address the same need before comparing them.


Status Proposed

Priority M

D4.2


2.2.3.2.3 Comparison of safety normative constraints/objectives

03_03

Description The CCL shall provide support to compare the constraints/objectives that address the

same need and coming from different specific normative constraints/objectives. This

comparison shall be with respect to attributes of equivalence, inclusion, partial

inclusion or disjuncture.

Rationale This requirement is requested to perform cross-country certification. Indeed,

National Safety Authorities impose specific normative constraints. The user has to

take into account the most restrictive constraints to get a cross-country certificate.

This requirement leads to the definition of two relations:

• Safety requirement equivalence between two specific constraints (Two safety

requirements coming from different national authorities are equivalent when

both address the same need or characteristic but possibly with different

constraints on it);

• Most/Less/Partial/Disjoint restriction constraints between two equivalent

requirements.


Status Proposed

Priority M

2.2.3.2.4 Description of safety assurance processes

03_04

Description The CCL shall provide a means to build a structured description of safety and

certification assurance processes derived from the domain-specific standards

Rationale Argument modules are developed in the context of the

requirements/expectations/culture of a particular standard or group of domain-

specific standards. If the modules are to be successfully composed, it is important to

understand the overall process within which the claims, argument and evidence are

put forward.

Focusing the attention on the automotive domain, it is possible to distinguish

between the processes related to the functional safety management for producing

the evidences of certifications and the supporting ones, related to some specific

phases of producing evidences during the development of HW and SW elements from

external sources or dealing with the general management of the requirements.


Status Proposed

Priority M

D4.2


2.2.3.2.5 Description of safety analysis techniques

03_05

Description The CCL shall provide a means for the consistent description of safety analysis

techniques

Rationale Characterisation of the techniques by means of which the evidence artefacts are

derived (FMEA, FTA and/or others recommended by the standards) is important to be

able to describe the purpose and limitations of the analysis, since this may set

boundaries on what can be claimed for the evidence in a reuse or compositional

context.


Status Proposed

Priority M

2.2.3.2.6 Support of the different types of safety arguments

03_06

Description The CCL shall support qualitative and quantitative safety arguments

Rationale Safety and certification demonstration will require qualitative (DAL...) and

quantitative arguments (extract of FMEA)


Status Proposed

Priority M

2.2.3.2.7 Description of safety claims, assumptions, context and evidence

03_07

Description The CCL should provide a means for the consistent expression of claims, assumptions,

context and evidence citations in a safety argument structure

Rationale When reusing safety claims, the unavoidable conditions to be met for ensuring their

validity shall be taken into account (assumptions, context etc.).

In addition to this, the validity of any safety claim directly depends on the safety

analyses applied and any other safety process subsequently applied (Verifications,

Validation, Confirmation measures etc).

Consequently, the CCL should facilitate the traceability and description of all the

aspects related to a safety claim.


Status Proposed

Priority M

2.2.3.2.8 Description of safety requirements

03_08

Description The CCL should provide a means for the consistent expression of safety requirements

Rationale Arguments are targeted towards the demonstration of the satisfaction of safety

requirements, which can be specified with a structured ensemble of attributes.

Considering for example the automotive domain, Table 2 of standard ISO 26262

contains the definition for the safety requirements related to the functional safety

concept and to the technical safety requirements. It is therefore important to be able

to ensure consistency between the expression of requirements as claims between

modules, to ensure that modules for composition can be seen to cover compatible

requirements.

Stakeholders Safety Engineer

D4.2


Status Proposed

Priority M

2.2.3.2.9 Hazard expression

03_09

Description The CCL shall provide a consistent means for the expression of hazards

Rationale Arguments are, in general, hazard-directed. It is important that hazards can be

consistently expressed, both in terms of argument claims and in characterising the

context in which the modules are originally developed.


Status Proposed

Priority M

2.2.3.2.10 Determination of the Integrity Level in the different domains

03_10

Description The CCL shall provide a consistent means for the specification of process leading to

the definition of the Integrity Level of a system/component.

Rationale Every domain considered by OPENCOSS project (automotive, avionics and railways)

has a peculiar definition of the process to be followed for the specification of the

integrity level of a system/component.

As a consequence, it becomes important for the CCL to provide a structured way to

record, analyse and present the data required for the specification of the Integrity

Level.


Status Proposed

Priority M

2.2.3.2.11 Description of the concepts from hazard-directed arguments

03_11

Description The CCL shall describe concepts allowing to allocate and decline safety hazard

requirements to the system, items and components (of equivalent concept in other

domains) and structure hazard-directed safety arguments

Rationale This relates to Tim Kelly’s paper on the three types of argument (safety, confidence

and compliance). Many of these concepts can be taken directly from the ARM

model, though there may need to be some extension to the model there.


Status Proposed

Priority M

2.2.3.2.12 Guarantee the completeness of the argumentation for certification

03_12

Description The CCL shall guarantee that for a normative standard the argumentation is complete

Rationale Certification tipically depends on two pilars: correctness and completness in front of

certification requirements whose answers are coming through normative standards.

Consequently, it becomes important at least to have a guarantee that all the required

documentation for certifying a component/system as safe has been produced.


D4.2


Status Proposed

Priority M

2.2.3.2.13 Confidence in a safety argument

03_13

Description The CCL should describe concepts relating to the confidence vested in a safety

argument

Rationale It is essential that an argument developer or reviewer has a means to assess the

confidence vested in an argument, either between claims, between modules or in the

wider structure as a whole. This facilitates assessment of the cogency and

appropriateness of the argumentation being made, and also the choice of

appropriate composition.


Status Proposed

Priority S

2.2.4 Feature 4: Management of safety-argument contracts


The challenge of WP5 is to provide a means to facilitate the reuse of certification assets within a safety

argument framework. The safe operation of the system as a whole will rely on complex assumptions and

guarantees about the behaviour of the aggregated hardware and software components, with safety-

related functions often being partitioned across several discreet components, often of varying types. Each

component will have associated assurance information – in the form of evidence and argumentation -,

which should be reused to form an overall safety case for the (new) system context in which the reused

components are composed. It is the role of WP5 to clarify the assumptions and interdependencies

between the original assurance information, in such a way as to make explicit to what extent the reuse of

assurance artefacts is possible in isolation from the original system context. The approach will involve the

development of freestanding argument modules, with associated evidence, which will be composed to

form an overall system safety argument. The composition will rely on the definition of public interfaces

between argument modules, and the presentation of ‘safety argument contracts’ to capture the rely-

guarantee relationships between these argument modules, in terms of their contribution to confidence in

overall system safety.1

The CCL will provide support for this approach in the following ways:

• By providing a clearly-defined, standardized lexicon in which the semantics of the terms and

concepts referred to in individual argument claims and elements of reasoning can be expressed.

• By providing a means by which system-level requirements and assumptions can be expressed as

generic concepts, and the satisfaction of dependencies on the integration of a component can be

queried and assured in the reuse context, in terms of the “conceptual mapping” between the

translated assets.

1 Please note that the subject here is safety argument contracts, as opposed to “design contracts”.

Although the notion of design contracts inspired the thinking behind the contract-based approach to safety

argumentation, the similarities are superficial. Concepts such as “correct-by-construction”, for example,

though very meaningful in the design world, have no application in the development of safety cases.

D4.2


• By providing a clearly-defined reference argument model, defining the primitive elements of an

argument (e.g. claim, premise, conclusion, assertion etc.), the logical relationships between them

(e.g. deductive implication etc.) and the generic form in which they should be expressed.2


2.2.4.2.1 Contracts representation

04_01

Description The CCL shall provide a means for the consistent expression of language used in

safety-argument contracts as defined by WP5.

Rationale Development of a consistent lexicon will facilitate the development of well-scoped

interface specifications and will de-risk the composition of argument and evidence

artefacts originally defined with respect to the requirements of diverse domains

and/or standards, by making the underlying concepts at work in the assurance and

argument processes clear.

Stakeholders WP5, Safety Engineer, ISA

Status Proposed

Priority M

2.2.4.2.2 Characterization of safety argument modules

04_02

Description The CCL shall provide a language to facilitate the characterisation of safety argument

modules, as defined by WP5. This will take the form of a reference argument model,

defining the primitive elements of an argument and the relationships between them.

Rationale There is a need for a clear and agreed understanding of the role of the constituent

argument modules making up a compositional argument structure clear, so that their

contribution to confidence in the overall safety of the system can be made clear.

Stakeholders WP5, Safety Engineer, ISA

Status Proposed

Priority M

2.2.4.2.3 Modular safety case concepts

04_03

Description The core concepts covered by CCL shall include the concepts related to compositional

safety case development.

Rationale This is necessary to ensure that WP5 work is fully integrated within the overall

project. Whilst it is impossible to enumerate the concepts at this stage, examples of

‘candidates’ include: “safety case module”, “module interface” and “safety case

contract”.

Stakeholders WP5

Status Proposed

Priority M

2 Note that [Ref. 37] provides a reference argument model, which can be used as the basis for the CCL’s

contribution here. Some work is required (in WPs 4 and 5) to validate this model and possibly to extend it

in terms of the types of assertion widely used in safety arguments.

D4.2


2.2.4.2.4 Characterisation of safety case module interfaces

04_04

Description The CCL shall provide means for characterising argument claims and provide a

standard set of claim types.

Rationale Safety case modules interfaces will include declaration of claims that the module

provides and relies upon. Such publicly visible claims of different modules can be

linked by safety contracts. CCL characterisation of the argument claims (and,

specifically, claims declared on module interfaces) will allow for some consistency

checks to be performed over safety case contracts. The characterisation shall include

type of the claim and CCL is expected to propose a set of claim types (possibly, based

on OMG’s ARM/SAEM)

Stakeholders System / safety case integrator, component / safety case module developer

Status Proposed

Priority M

2.2.4.2.5 Characterisation of safety case assumptions

04_05

Description The CCL shall provide means for characterising safety case assumptions and provide a

standard set of assumptions types.

Rationale Safety case modules interfaces may include declaration of assumptions that the

argument or evidence contained within the module relies upon. The adequacy of

composition of different modules clearly relies on the compatibility of the

assumptions. In order to enable OPENCOSS infrastructure to provide assistance to the

users in establishing whether the modules assumptions are compatible, the CCL shall

provide means for characterising assumptions. Note that this is not the same as

formulation of the assumption itself (just as claim characterisation is not the same as

claim formulation). The characterisation shall include type of the assumption and CCL

is expected to propose a set of assumption types.

Stakeholders System / safety case integrator , component / safety case module developer

Status Proposed

Priority M

2.2.4.2.6 Characterisation of safety case context

04_06

Description The CCL shall provide means for characterising safety case context.

Rationale Safety case modules interfaces may include declaration of context that the module

(or part thereof) relates to. The adequacy of composition of different modules relies

on the compatibility of contexts declared within those modules. To enable OPENCOSS

infrastructure to provide assistance to the users in establishing whether the module

contexts are compatible, CCL shall provide means for characterising contexts. It

should be possible to extend the CCL in the future with the set of context types.

Stakeholders System / safety case integrator , component / safety case module developer

Status Proposed

Priority M

Note that similar requirement applies to evidence cited within a safety case module. However, this is

covered in Feature 5.

D4.2


2.2.4.2.7 Characterisation of other relevant aspects of safety case modules interfaces

04_07

Description It should be possible to extend CCL to provide means for characterising aspects of

safety case modules interfaces that are not related to publicly visible claims,

assumptions, context or evidence cited within the module.

Rationale Whilst it is expected that safety case module interface will consist of claims,

assumptions, contexts or evidence (and characterisations thereof) there is still

significant uncertainty in the future compositional certification framework developed

by WP5.

Stakeholders WP5

Status Proposed

Priority S

2.2.4.2.8 Means for the specification of consistency rules and warnings regarding the characterisation

of safety case modules interfaces

04_08

Description The CCL shall provide means for specification of (hard) rules and (soft) warnings over

characterisations of interfaces of composed safety case modules

Rationale Such rules will be used to highlight invalid or suspect composition of modules based

on the characteristics (e.g. types) of the claims, assumptions, contexts and cited

evidence declared on modules’ interfaces and the details of the composition (i.e. the

safety case contract)

Stakeholders System / safety case integrator

Status Proposed

Priority M

2.2.4.2.9 Provision of a library of rules and warnings regarding the characterisation of safety case

modules interfaces

04_09

Description The CCL shall include an initial library of the rules and warnings over characterisations

of interfaces of composed safety case modules that can be used to highlight invalid or

suspect composition of modules.

Rationale Such rules will be used to highlight invalid or suspect composition of modules based

on the characteristics (e.g. types) of the claims, assumptions, contexts and cited

evidence declared on modules’ interfaces and the details of the composition (i.e. the

safety case contract)

Stakeholders System / safety case integrator

Status Proposed

Priority M

D4.2


2.2.5 Feature 5 Evidence management

2.2.6 Introduction/purpose of the feature

WP4 aims to define a common conceptual and notational framework language (CCL) for specifying

certification assets. These assets are usually provided on the basis of a safety case approach or a standard-

based approach. The CCL will have to support provision of working with evidence with both approaches, as

well as cross-domain certifications expressed in a certain context. The context is given by both the system

and domain, including the standards used in that domain for which the evidence was gathered. In case of

cross domain reuse of assets, this implies that CCL will have to support determination of the requirements

of a safety standard that are fulfilled by a set of evidence on the basis of the requirements fulfilled for base

standard and the target other standard(s).

Based on this, CCL will need evidence for safety certification to determine the results of a cross-domain

certification assessment. Therefore, CCL should provide features of evidence management to support for

evidence exchange with other WPs.


2.2.6.1.1 Evidence characterization

05_01

Description The CCL shall provide a language to facilitate the characterisation of evidence

artefacts, which should include the taxonomy of properties of evidential artefacts,

evidence specification etc.

Rationale Evidence characterisation is at the heart of the OPENCOSS vision, since the informed

reuse of evidence artefacts requires a clear sense of the nature of the evidence and

the type of assurance claims it can support. The structure of such evidence

characterization provides the basis for logical design of easily-constructed tools for

storing, cross-referencing, evaluating and reporting the elements of evidence for

safety assurance and certification in OPENCOSS.

Stakeholders Safety Manager, Argument Author, Assessor, Argument Developer

Status Proposed

Priority M

2.2.6.1.2 Evidence reuse

05_02

Description The CCL shall provide support for the reuse of evidence artefacts (singly or in groups)

Rationale Evidence is developed and presented in a particular way, to provide ‘tailored’ support

for the claims relating to the safety of a particular system in a particular operational

context and the requirements of a particular regulatory regime. Evidence reuse is to

support argumentation in a different context. It requires re-evaluation of the nature

of the claims that can be supported by that evidence, as well as of the role of those

claims within the overall argument structure for the reuse context, in which the

regulatory requirements to which compliance must be demonstrated may differ

subtly or substantially from the original.

Stakeholders Argument Developer

Status Proposed

Priority M

D4.2


2.2.6.1.3 Support identifying evidence

05_03

Description The CCL should support identifying evidence from an imported electronic safety

dossier.

Rationale Evidence can be diverse as various things may be produced as evidence, such as

documents, expert testimony, test results, measurement results, records related to

process, product and people, etc. The CCL shall identify the evidence from all the

documents imported into the electronic safety dossier.

Stakeholders Project Manager

Status Proposed

Priority M

2.2.6.1.4 Informed reuse evidence

05_04

Description The CCL shall provide a means for the storage of information concerning the evidence

artefacts.

Rationale To manage reuse across domains, ensuring that it is clear what the evidence 'does' in

each domain.

Stakeholders Argument Developer

Status Proposed

Priority M

2.2.6.1.5 Evidence assessment

05_05

Description The CCL shall support the determination of the adequacy of evidence in a way (1) that

could be used to assess any type of evidence, (2) that would allow comparison of the

adequacy of different pieces or sets of evidence (i.e., would allow someone to know

if a piece or set of evidence is better or worse than another, for a particular purpose),

and (3) whose rationale can be documented.

Rationale The CCL will allow us to determine how the infrastructure can analyse or support

analysis of evidence to determine its adequacy and the degree of confidence in the

evidence. When reusing safety evidence, CCL will ensure its validity under

unavoidable condition.

Stakeholders Argument Developer, Assessor

Status Proposed

Priority M

2.2.7 Feature 6: Compliance Management


Compliance management of safety critical systems is based on the standards. That is: (a) what the

standards define and (b) how compliance/conformance with the standards is to be demonstrated.

Standards can prescribe the quality of processes or products, or describe performance targets and goals.

The standard-driven way of ensuring quality is by imposing a level of rigor in the processes and workflows

used to build the final system and by specifying the intermediate artefacts to be produced.

Standards are often formulated at an abstract level and, therefore, the interpretation of the standard in

relation to an individual system or application has a key role in determining the degree of compliance.

D4.2


Interpretations are necessary on two levels: (1) clarification of the general intent of the

assessors/authorities, and (2) an understanding of how the practices/requirements from standards must

be interpreted for development and its process.

The diversity of the regulatory standards, in the leeway they provide for interpretation, in the several

domains, and sometimes in the diverse countries, offers a challenge for reuse of compliance arguments.

In this section, we describe the CCL requirements to the purpose of trying to do the compliance tasks more

cost-effective and more “structured” and “formal”. This includes two kinds of goals: (a) specify standards

and related information in a structured way to allow standards to be stored in a form that can be

retrieved, categorized, associated with other standards, searched and browsed, (b) manage the

demonstration of compliance with standards.

2.2.7.2 Knowledge Management about Standards/Regulations

2.2.7.2.1 Specification of Standards/Regulations

06_01

Description The CCL shall provide a common way to store standards, what they prescribe, and

their interpretations in a form that can be retrieved, categorized, associated with

other standards, searched and browsed.

Rationale This feature allows sharing the knowledge of standards in a common and electronic

way. A basic scenario is to allow a safety manager for a safety-critical product

development company to create a new entry for a standard/regulation or new

requirement within a standard/regulation. As he/she works through the regulation,

he/she documents interpretations of what it means for the company. In making this

interpretation, he/she refers to earlier interpretations of other standards/regulations

in the same categories. This information can be also read by other actors such as an

safety assessor in order to establish a communication with the company and to

recommend or to request changes of any registered interpretation.

Stakeholders Safety Manager, Argument Author, ISA, Argument Developer

Status Proposed

Priority M

2.2.7.2.2 Comparison of Standards/Regulations

06_02

Description The CCL shall provide conceptual means to compare standards/regulations including

specification of conflicts/disharmonies and similarities/harmonies.

Rationale Part of the work inherent in interpreting new standards and assessing their impact is

to compare them with other, related standards. There may be overlaps: compliance

solutions already in place may be extensible or adaptable to meet the new standard’s

requirements. There may be conflicts: the enterprise may have to make judgments

on how to balance conflicting requirements of different standards, and will have to

justify these as judgments to the respective assessors. The CCL shall make explicit

the high-level conceptual understanding of ‘compliance’ and its structure, in order to

facilitate the understanding of the harmonies and disharmonies embedded in the

standards/regulations.


Status Proposed

Priority M

D4.2


2.2.7.3 Management of Compliance Demonstration

2.2.7.3.1 Level of compliance

06_03

Description The CCL shall allow recording information related to the level of compliance of a

given safety assurance project related to standards/regulations.

Rationale The CCL shall allow recording information related to standards/regulation compliance

in order to provide understanding of (a) the impact of the requirements/practices

from standards on the development process, (b) the status of the compliance, (c)

how to map items from one standard to other, (d) decisions on how to demonstrate

compliance.

Stakeholders Safety Manager, Argument Author, ISA, Argument Developer

Status Proposed

Priority M

2.2.7.3.2 Compliance Arguments

06_04

Description The CCL shall provide concepts to make compliance arguments explicit, as a means

for inputting and modelling possible consistency issues in standards and

interpretations.

Rationale There are already practical examples of using safety cases for compliance

demonstration. This includes the use of arguments to demonstrate compliance with

standard requirements/objectives. CCL shall provide means to support an argument-

based compliance demonstration beyond/in addition to a pure “checklist” approach.


Status Proposed

Priority M

2.3 Features of the CCL editor

The features of the CCL editor shall be completed at a more advanced stage of the OPENCOSS project.

2.4 Performance requirements

This section defines the performance requirements associated to the functional requirements of the

Common Certification Language defined in section 2.2, using the following framework:

Figure 9 - Template of the CCL performance requirements

The ID of any performance requirement follows the template:

D4.2


ID: XX_YY_ZZ

With

XX= feature number

YY= number of the functional requirement to which it applies

ZZ= ascending number associated to the performance requirement

The field “Description” is used to summarize the purpose of the performance requirement, while the field

“Rationale” contains the reasons or intentions leading to its definition.

As for the classification of the functional requirements, the field “Status” can go through the states

“Proposed”, “Approved”, “Implemented”, “Rejected” or “Future Enhancement” (see Figure 7).

Finally a priority is assigned to each requirement, using the MoSCoW prioritisation technique [Ref. 7].

2.4.1 Level of abstraction of domain-specific assurance concepts

01_02_01

Description The domain-specific assurance concepts shall be represented at a suitable level of

abstraction, comparable to that of the generic assurance concepts.

Rationale The necessity to create mappings between domain-specific assurance concepts and the

reference generic ones makes it necessary to represent them using a common level of

abstraction. Were this not the case, the two following situations would happen:

• If the level of abstraction is excessive, the mapping and consequent re-use of

assurance concepts within a specific domain and/or across different domains

will be only superficial;

• If the level of abstraction is too detailed, there is the high risk of being bogged

down in unnecessary linguistic niceties.

Reference

requirement

01_02

Status Proposed

Priority M

2.5 Design constraints

Design constraints typically impose limitations on the design of the system (in our specific case, the

Common Certification language) or the processes we use to build it.

During system design, it is as important to identify each design constraint as it is to elicit requirements,

since the design constraints place an overall boundary around the system design process.

While the sources are varied, design constraints typically originate from:

• restriction of design options,

• conditions imposed on the development process (e.g. compatibility with specific commercial

systems),

• regulations and imposed standards.

This section contains the list of the design constraints related to the Common Certification language. The

template presented in Figure 6 is used in this section, but a different ID is used in this specific case, so as to

distinguish the design constraints from the functional requirements for the CCL. In particular, they will be

identified using the following strategy:

D4.2


• ID: DES_CONSTR_XX

• With

• XX= ascending number

2.5.1 Meta-modelling language to specify CCL

DES_CONTR_01

Description CCL specification shall be released via OMG modelling languages (e.g. UML, MOF,

OWL) and shall be accompanied by an OMG XMI representation of the models

(including machine-readable copy).

Rationale Since one of the goals is the standardization of CCL and OMG (Object Management

Group) is the main targeted standardization body for this purpose, the CCL artefacts

shall be made compatible with OMG languages.

This impacts mainly the meta-modelling language for CCL (both for the conceptual

models and for the actual meta-model to be used by the CCL Editor). Commonly this

is done by class diagrams (UML or MOF). However, there should be constraints on

the use of these languages to avoid conflicts in interpreting meta-models. This shall

be concretized in a set of rules on the meta-modelling language (e.g., multiple

associations are not allowed, etc.).

Stakeholders Tool developers, OMG, OMG partners

Status Proposed

Priority M

2.5.2 Reuse of existing OMG language concepts

DES_CONTR_02

Description CCL shall reuse existing OMG modelling languages (e.g. SAEM, ARM, MRC) as much as

possible but dependency shall be reduced to cases where it is actually necessary.

Rationale Proposals shall use or depend on other specifications only where it is actually

necessary. While re-use of existing specifications to avoid duplication will be

encouraged, proposals should avoid gratuitous use. This will avoid conflicts on CCL

evolution.


Status Proposed

Priority M

2.5.3 Planning for future re-use of CCL

DES_CONTR_03

Description CCL shall factor out concepts that could be used in different contexts and specify

their models, interfaces, etc. separately. Such minimalism fosters reuse and avoids

functional duplication.

Rationale Since CCL is intended to be implemented by different kinds of tools (e.g. editors,

databases, API for data exchange, etc.) its concepts must be factorized and organised

in semantically-related packages (an example of first level of concepts organisations

is: evidence characterisation, safety argumentation, and compliance with standards

and regulations).


Status Proposed

Priority M

D4.2


3 Traceability of requirements

Feature Req. ID Requirement Name Traceability

Capture of

consistent

assurance

concepts

01_01 Capture of consistent generic assurance

concepts

01_02 Capture of consistent domain-specific assurance

concepts

01_03 Capture of relationships between assurance

concepts

Analysis of

consistent

assurance

concepts

02_01 Analysis of matches between assurance

concepts from different domains

02_02 Title to be added

02_03 Analysis of the match between concepts from

distinct domains or standards

02_04 Indication of the nature of the match between

concepts from distinct domains or standards

02_05 Automated provision of guidance as to the

aspects of two concepts from different domains

or standards not matching

Representation

of safety-related

concepts

03_01 Description of requirement coverage

03_02 Capture of specific safety normative

constraints/objectives

03_03 Comparison of safety normative

constraints/objectives

03_04 Description of safety assurance processes

03_05 Description of safety analysis techniques

03_06 Support of the different types of safety

arguments

03_07 Description of safety claims, assumptions,

context and evidence

03_08 Description of safety requirements

03_09 Hazard expression

03_10 Determination of the Integrity Level in the

different domains

03_11 Description of the concepts from hazard-

directed arguments

03_12 Guarantee the completeness of the

argumentation for certification

03_13 Confidence in a safety argument

Management of

safety-argument

contracts

04_01 Contracts representation

04_02 Characterization of safety argument modules

04_03 Modular safety case concepts

04_04 Characterisation of safety case module

interfaces

04_05 Characterisation of safety case assumptions

04_06 Characterisation of safety case context

D4.2


04_07 Characterisation of other relevant aspects of

safety case modules interfaces

04_08 Means for the specification of consistency rules

and warnings regarding the characterisation of

safety case modules interfaces

04_09 Provision of a library of rules and warnings

regarding the characterisation of safety case

modules interfaces

Evidence

management

05_01 Evidence characterization

05_02 Evidence reuse

05_03 Support identifying evidence

05_04 Informed reuse evidence

05_05 Evidence assessment

Compliance

Management

06_01 Specification of Standards/Regulations

06_02 Comparison of Standards/Regulations

06_03 Level of compliance

06_04 Compliance Arguments

Performance

requirement

Req. ID Requirement name Traceability

01_02_01 Level of abstraction of domain-specific assurance

concepts

Design constraint Constraint ID Constraint name DES_CONTR_01 Meta-modelling language to specify CCL

DES_CONTR_02 Reuse of existing OMG language concepts

DES_CONTR_03 Planning for future re-use of CCL

D4.2


4 Conclusions

This deliverable has developed the relevant state-of-the-art and currently best practices, user needs and

high-level requirements from the different application domains captured in WP2 and in section 6 of D4.1

[Ref. 6], in order to create detailed technical requirements related to the CCL, which will provide a

common language for getting mutual recognition agreement between the safety case-based and the

standard-based approaches.

In particular, three main usage scenarios of the Common Certification Language have been identified and

considered for the definition of its functional requirements:

1. CCL as the specification language for structured argumentation and to demonstrate compliance

with standards/regulations. Argumentation will be concretized in (compositional) safety cases, and

compliance demonstration will be concretized with means to measure the level of compliance of a

given safety assurance project with its prescribed standards/regulations (at least at quantitative

level).

In addition to this, domain-specific libraries of certification meta-models, acting as a knowledge

database providing information about safety-related standards and their interpretations will be

built.

2. CCL as the data scheme to create a repository of traceable evidences (evolutionary evidential

chain). While this is strongly linked to the previous usage scenario, the way such an evidential

chain repository will be implemented would need to consider some data management

functionalities such as change management, traceability management, among others.

3. CCL as the language to specify prescribed processes (activities, roles, artifacts) and means to

specify quantitative information about the assurance and certification processes.

In addition to this, another key factor considered for the definition of the main features and technical

requirements of the Common Certification Language is the concept of reuse, that can occur in the

following cases:

1. reuse the argumentation and evidence for a next version of a safety critical system, within a

project or organisation

2. reuse a safety case for a component or a subsystem of a new system, possibly across domains,

3. reuse (part of) a safety case in order to show compliance to another standard,

4. reuse (part of) a safety case in order to show compliance to another country-level set of rules,

5. reuse and improvement of a safety case in order to regain confidence, for example after a

catastrophic accident,

6. reuse (part of) a safety case for a system in another domain.

In the light of the situation presented above, the Common Certification Language will have to facilitate a

transparent and structured presentation of the safety requirements, safety assurance processes, safety

analysis techniques, evidences and any other safety asset eligible for re-use.

On the basis of the return of experience of the manufacturers involved in T4.1, this goal will be achieved as

long as the CCL will be capable of capturing and providing engineers with means to describe the context,

the assumptions about process, evidence and system characteristics embedded in claims of compliance

and/or any other safety asset.

Moreover, what has been immediately evident from the very beginning of WP4 and described in detail in

the deliverable D4.1 [Ref. 6] is that re-use of any safety asset produced in the development, assessment

and justification of a safety-critical product or, in general terms, of any artefact which might be used in the

demonstration of the safety of the product, is affected by the linguistic and conceptual norms – the

D4.2


language and concepts of the safety standards, safety practices, interpretations and best practice within

the domain.

As a result of this situation, problems related to the translation from the source context to the target

context, as well as the significant differences between the fundamental concepts of assurance make it a

challenge a “word-for-word” translation across domains.

Consequently the Common Certification Language will have to define a set of generic and domain-specific

terms; matching of the domain-specific terms and concepts, allowing cross-domain re-use of safety assets,

will be thus achieved with respect to this list of reference terms and concepts. However, it has to be

underlined that the extent to which full matching between terms and concepts can be achieved is highly

variable, depending on the precise cultural assumptions governing usage in the individual domains, and

how far a meaningful synthesized term or concept can be defined to preserve and match these

assumptions.

Focusing the attention on the architectural aspects of the Common Certification Language, instead, it is

important to realize that although the CCL itself will be delivered as a tangible asset, in the form of a series

of interconnected models, the final layout of this enabling technology is still under discussion.

At this early stage in the OPENCOSS project – while both the Platform and the overall OPENCOSS Approach

are still very much in the conceptual stage -, it is difficult to formulate a complete and exhaustive list of

detailed requirements on the CCL. In particular, the realisation of the CCL in terms of tooling is very much

undecided: this is the focus of Task T4.3, and is out of scope of the current version of this deliverable. Also

the nature of the end user’s actual interaction with the CCL itself is still undefined – it is currently unclear

whether there will be any direct interaction at this level.

Anyway, the fact that the current list of requirements cannot be considered as complete is also a direct

consequence of the fact that, as analysed in detail in section 6, requirements typically change over the life

of any project due to changes in technology, stakeholders’ needs and environment and emerge as

knowledge is obtained during development. As a consequence, an iterative/evolutionary development

approach for this deliverable has been adopted and the list of features/requirements/constraints

contained in this version of the deliverable will be probably modified and extended in following deliveries.

In conclusion, the list of features and requirements provided in this deliverable will drive the definition of

the conceptual domain model (and metamodel) representing the semantics of the Common Certification

Language developed in T4.2. The current set of requirements will be refined in parallel with the evolution

of both the OPENCOSS Approach and Platform, adopting an iterative approach capable of keeping the pace

with the main decisions and technical agreements taken along the lifecycle of the project and reflecting

the changes in technology, stakeholders’ needs and environment.

D4.2


5 References

Ref. 1. IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998

Ref. 2. IEEE Guide for Developing Systems Requirements Specification, IEEE Std 1233-1998

Ref. 3. Ian F. Alexander and Neil Maiden, “Scenarios, Stories, Use Cases: Through the Systems

Development Life-Cycle” (Wiley, London etc, 2004)

Ref. 4. OPENCOSS deliverable D2.1 – “Business Cases and User Needs”

Ref. 5. OPENCOSS deliverable D2.2 – “High-level requirements”

Ref. 6. OPENCOSS deliverable D4.1 – “Baseline for the Common Certification Language”

Ref. 7. “A Guide to the Business Analysis Body of Knowledge”, version 2.0

Ref. 8. Ferdinand de Saussure, “Cours de linguistique gènèrale”, ed. C. Bally and A. Sechehaye, with

the collaboration of A. Riedlinger (payot, Lausanne and Paris, 1916). Translated into English by

W. Baskin as Saussure, Course in General linguistics (Fontana/Collins, Glasgow, 1977)

Ref. 9. John Lyons, “Semantics” vol I (Cambridge University Press, Cambridge, 1977)

Ref. 10. Stan Bühne, Günter Halmans, Klaus Pohl, Matthias Weber, Henning Kleinwechter, Thomas

Wierczoch, 2004, “Defining Requirements at Different Levels of Abstraction”, Proceedings of

the 12th IEEE International Requirements Engineering Conference (RE’04).

Ref. 11. M. Christel, and K. Kang, "Issues in Requirements Elicitation," Software Engineering Institute,

Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-92-TR-012,

1992. http://www.sei.cmu.edu/library/abstracts/reports/92tr012.cfm

Ref. 12. A. Durán Toro, B. Bernárdez Jiménez, A. Ruiz Cortés, and M. Toro Bonilla, “A Requirements

Elicitation Approach Based in Templates and Patterns”

Ref. 13. A. Durán, B. Bernárdez, M. Toro, R. Corchuelo, A. Ruiz, and J. Pérez, “Expressing Customer

Requirements Using Natural Language Requirements Templates and Patterns”, in IMACS/IEEE

CSCC’99 Proceedings, Athens, 1999. IMACS/IEEE.

D4.2


Ref. 14. IEEE Guide for Developing System Requirements Specifications. IEEE/ANSI Standard 1233–

1996, Institute of Electrical and Electronics Engineers, 1996.

Ref. 15. S. Raghavan, G. Zelesnik, and G. Ford, “Lecture Notes on Requirements Elicitation”,

Educational Materials CMU/SEI–94–EM–10, Software Engineering Institute, Carnegie Mellon

University, 1994.

Ref. 16. Chung L., “Representing and Using Non-Functional Requirements: A Process Oriented

Approach”, Ph.D. Thesis, Dept. of Comp.. Science. University of Toronto, June 1993. Also tech.

Rep. DKBS-TR-91-1.

Ref. 17. Dardenne A., van Lamsweerde A, Fickas, S., “Goal Directed Requirements Acquisition”, Science

of Computer Programming, Vol. 20 pp: 3-50, Apr. 1993.

Ref. 18. Leite, J.C.S.P. et.al. ”Enhancing a Requirements Baseline with Scenarios.”, Requirements

Engineering Journal, 2(4):184-198, 1997.

Ref. 19. Rational et al, “Object Constraint Language Specification”, 1997. Http://www.rational.com.

Ref. 20. VanLamsweerde, A, “Goal-Oriented Requirements Engineering: A Guided Tour” Proc of the 5th

IEEE Int. Symp. on Requirements Engineering, pp:249-262, 2001.

Ref. 21. D. Firesmith, “ Prioritizing Requirements”, Journal of Object Technology, Volume 3, No.8,

September 2004

Ref. 22. Nancy R. Mead, “Requirements Elicitation Introduction”, Software Engineering Institute

Carnegie Mellon University, 2008-2009.

Ref. 23. A.M. Hickey, A.M. Davis, “Elicitation Technique Selection: How Do Experts Do It?”, Proceedings

of the 11th IEEE International Requirements Engineering Conference, 2003.

D4.2


Ref. 24. Clegg, Dai; Barker, Richard (2004-11-09), ”Case Method Fast-Track: A RAD Approach.”,

Addison-Wesley

Ref. 25. Carlshamre, Par, and Regnell, Bjorn, “Requirements Lifecycle Management and Release

Planning in Market-Driven Requirements Engineering Processes”, Proceedings of the 11th

International Workshop on Database and Expert System Applications, IEEE, 2000

Ref. 26. Christensen, Mark J. and Thayer, Richard H., “The Project Manager’s Guide to Software

Engineering Best Practices”, IEEE Computer Society, 2001, ISBN 0-7695-1199-6

Ref. 27. Davis, Alan M., and Leffingwell, Dean A., “ Making Requirements Management Work for You”,

CROSSTALK, April 1999, http://www.stsc.hill.af.mil/crosstalk/1999/04/davis.asp

Ref. 28. Sutcliffe, Alistair G.; Maiden, Neil A. M.; Minocha, Shailey; and Manuel, Darrel, “Supporting

Scenario-Based Requirements Engineering”, IEEE Transactions on Software Engineering , Vol.

24, No. 12, December, 1998, http://csdl.computer.org/comp/trans/ts/1998/12/e1072abs.htm

Ref. 29. Davis, Alan M., “The Art of Requirements Triage”, IEEE Computer, March 2003,

http://www.computer.org/computer/homepage/0303/Davis/

Ref. 30. Haumer, Peter ; Pohl, Klaus ; and Weidenhaupt, Klaus, “Requirements Elicitation and

Validation with Real World Scenes “, IEEE Transactions on Software Engineering, Vol. 24, No.

12, December, 1998.

Ref. 31. Sud, Rajat R. and Arthur, James, “Requirements Management Tools: A Qualitative

Assessment”, Department of Computer Science, Virginia Tech, Blacksburg, VA 24060 USA,

2003, http://eprints.cs.vt.edu:8000/archive/00000658/01/RM_Tools.pdf

Ref. 32. Clark, R. and Moreira, A., "Constructing Formal Specifications from Informal Requirements",

Software Technology and Engineering Practice, IEEE Computer Society Press, 1997, pp. 68-75.

Ref. 33. Malan, R., and Bredemeyer, D., “Defining Non-Functional Requirements”,

http://www.bredemeyer.com/ papers.htm

D4.2


Ref. 34. Malan, R. and Bredemeyer, D., “Functional Requirements and Use Cases”,

http://www.bredemeyer.com/ papers.htm

Ref. 35. Mylopoulos, J., Chung, L., and Nixon, B., "Representing and Using Non-Functional

Requirements: A Process-Oriented Approach", IEEE Transactions on Software Engineering,

Special Issue on Knowledge Representation and Reasoning in Software Development, Vol

18(6), 1992, pp. 482-497.

Ref. 36. Sommerville, I. and Sawyer, P., “Requirements Engineering, A Good Practice Guide”, John

Wiley and Sons, 2000.

Ref. 37. Argumentation Metamodel (Beta 1 version; OMG, August 2010)

D4.2


6 Annex: Considerations for the specification of

requirements

6.1 Requirement specification: development process overview

The requirements development process, in general, interfaces with three external agents [Ref. 2]:

• the customer, hereinafter referred to as “stakeholder”;

• the technical community.

• the environment.

The term “system” used in the following sections indicates the Common Certification Language.

Stakeholder

In requirements engineering, the term ‘Stakeholder’ is used to refer to a person, organisation or system

which has an interest in the system under development [Ref. 3]. Stakeholders are directly affected by the

product, in terms of being users or investors, or are people or organisations whose input is required in

order to finalise the requirements for the product.

Stakeholders may not understand the process of establishing requirements or may be not familiar with the

vocabulary and representation techniques that are used to specify requirements, so it will be necessary to

provide them with a representation of the Requirement Specification in a language that they understand

and that is complete, concise and clear.

It is common to think of a layered model of stakeholders, where typical stakeholder types are grouped

according to the nature of their interest in the system under development. Alexander and Maiden [Ref. 3]

refer to this as an “onion model”, since the stakeholders are visualised as belonging to a series of different

“skins”, each of which represents a different type of interest, and each of which is encompassed in a wider

context.

A number of direct and indirect stakeholder groups have been identified for the OPENCOSS project and its

principal product, the OPENCOSS platform. These stakeholders are analysed in detail in Section 6.2 of

deliverable D2.1 [Ref. 4].

Stakeholders provide their objective, needs, or problems to the Requirement Specification process.

Early the stakeholder has an idea of a system of some use for him. At this point any initial concept of the

system may be imprecise and unstructured. Often this requirements are expressed in initiating documents

similar to the following:

• concept of operations: focuses on the goals, objectives, and general desired capabilities of the

potential system without indicating how the system will be implemented to actually achieve the

goals;

• system concept: includes concept of operations information, but will also include a preliminary

interface design for the system and other explicit requirements;

• marketing specification: includes a features list for a new system and will identify the scope of the

features and their priority (which are mandatory or highly desirable) to provide an edge in the

marketplace. It also includes a context or boundary defining how the new system must interact

with existing systems. A cost/benefit analysis and required delivery schedule may be provided;

• request for proposal (RFP): may include one or more of the above initiating documents. Its

purpose will be to solicit bids for consideration from several sources to construct a system, or may

simply require assistance to generate system initiating documents;

D4.2


• external system interfaces: the definition of all interfaces external to the system is one of the

most important activities to be accomplished prior to the generation of the Requirement

Specification. An approved definition of the system’s external universe reasonably bounds or

restricts what the system is required to do internally. All known elements of each separately

defined interface should be described. There are many types of possible interfaces external to the

system and a single system may have several interfaces of differing types.

The stakeholder typically gives a feedback:

• updating its objectives, problems, or needs;

• modifying requirements concerning technical interchange communications;

• identifying new requirements.

Considering the specific case of the Common Certification Language, the high-level requirements defined

in D2.2 [Ref. 5], together with the analysis contained in section 6 of D4.1 [Ref. 6], have been considered as

the starting point for the definition of the CCL features and its requirements (see Figure 10) .

Environment

The environment can influence or place a constraint on the system requirements. The analyst should be

aware of these influences on system capabilities and, together with the stakeholders, should specify

environmental influences that affect system requirements.

These influences can be classified into categories, as follows:

• Political: laws and regulation of state may influence system requirements. Example of laws are

copyright, patent and trademark laws. Example of regulations are environmental hazards, waste,

system safety and health.

• Market: marketing research may help in matching the customer’s needs and this may influence the

development of the systems specification. Also demand-fulfilling may influence requirements

specification because it affects system distribution and accessibility requirement. Finally

competition may influence requirements specification by getting ideas for new requirement from

competitor’s system.

• Standards and technical policies: requirement may be influenced directly by stakeholder who have

to conform to standard and technical policies issued by government or industries. Example are

safety standards, electrical standard.

• Cultural: human behavior pattern may affect system requirement in the use of the system.

• Organizational: requirements are influenced by organization in which they are developed. Example

of this influence are marketing, internal politics, technical policies, and internal standards.

• Physical: includes natural and man-made influences such as temperature, radiation, moisture,

pressure, and chemicals.

Technical Community

The technical community is composed of those involved in the activities of system design, implementation,

integration, test, manufacturing, deployment, operations, and maintenance. All elements of the technical

community should be involved in the Requirements Specification development process as early as possible

to reduce the possibility that new requirements or changes to the original requirements may be discovered

later in the system life cycle.

Technical representation of requirements may include interchange or communications that clarify or

confirm requirements.

D4.2


The technical community provides feedback during various activities that can cause modification,

additions, and/or deletions to the requirement collection. Requirements are then redefined to support

subsequent phases (development, implementation, testing).

In the specific case of the CCL requirements specification process, the Partners participating in the

definition of the conceptual domain model representing the semantics of the CCL (task 4.2) have been

directly involved in the activities related to D4.2.

Figure 10 - Context for developing CCL Requirements Specification

6.2 Requirements Management and the other requirement processes

Requirements typically change over the life of any project due to changes in technology, stakeholders’

needs and environment and emerge as knowledge is obtained during development. As a consequence,

there is an evident necessity to adopt an iterative/evolutionary development approach and to define a

requirement management process (RM). RM is the process of eliciting, documenting, organizing, and tracking changing requirements and

communicating this information across the project team to ensure that iterative and unanticipated

changes are maintained throughout the project lifecycle.

A widely accepted interpretation of RM is illustrated in Figure 11. The definition of a system is segmented

into a series of deliveries (releases), each with more functionality added, resulting in the evolution of the

envisioned product over time. However, detailed planning and requirements development focuses on

each release.

D4.2


Figure 11 – The Role of Requirements Management in Evolutionary Development

Although the focus of RM is on managing changes to requirements, it is the glue that ties the other

requirements processes together over time (see Figure 12).

Figure 12 - Key Processes of Requirements Engineering

6.2.1 Requirements Elicitation

Requirements elicitation is the starting point for a project, and is where stakeholders are identified and

relationships established between them.

Elicitation seeks to discover all of potential sources of requirements including:

• Goals – The overall high-level objectives that the system needs to satisfy

• Stakeholders – Multiple stakeholders typically have differing viewpoints which must be weighed

and managed to avoid conflicting requirements, or an inappropriate bias toward a particular

stakeholder view

D4.2


• Operational environment – Not addressing requirements derived from the operational

environment can severely impact feasibility, cost, and design choices

• Organizational environment – Impact of the structure, culture, and internal policies of the

organizations involved needs to be assessed in determining requirements

• Law/Regulations – In many cases regulation drives or constrains what is possible

Requirements sources rarely have explicit requirements detailed to a level appropriate for making design

decisions. The requirements must be derived as a result of interacting with stakeholders and reviewing

other sources, and getting concurrence from stakeholders about how well the statements represent their

thoughts. Techniques include:

• Interviews

• Scenarios

• Prototypes

• Facilitated meetings

• Observations

6.2.2 Requirements Analysis

The main objectives of Requirements Analysis (RA) are:

• To detect and resolve requirements conflicts

• To discover the bounds of the system and how it interacts with its environment

Analysis generates requirements attributes that are used to manage the project thereafter. Analysis

activities include:

• Classifying requirements – Grouping requirements into logical entities for planning, reporting, and

tracking. Classification can be done on a number of dimensions including source, type, priority,

risk, scope, volatility…

• Prioritizing requirements – Establishing the relative importance and risk of each requirement, and

specifying an implementation priority

• Requirements negotiation – Another name for conflict resolution. Addresses problems with

requirements where conflicts occur between stakeholders wanting incompatible features, or

conflicts between requirements and resources, or between capabilities and constraints.

It is important to note that these activities are not sequential and do not always precede requirements

specification.

6.2.3 Requirements Specification

Key practices of this process are:

• Uniquely identify each specific requirement to make referencing them easier

• Strive for the minimum possible number of documents to minimize maintenance as the project

progresses

• Establish a single source for requirement storage (each requirement is stored once in a single place

and can be referenced many times). This repository may be a master document, or it may be a

database from which the necessary documents can be generated. The larger the project, the

greater the need for a tool to support requirements specification.

• Follow a standard or recommended guide for adopting a structure for the document.

• Adhere to standard rules for writing good requirements statements

D4.2


6.2.4 Requirements Validation

It is concerned with examining the requirements to certify that they meet the stakeholders’ intentions, and

to ensure that they define the right system. Validation addresses specific requirements and the

requirements collection as a whole.

Key activities of requirements validation are:

• Conduct requirements reviews to validate that requirements are correct, unambiguous, complete,

consistent, ranked for importance and/or stability, verifiable (testable), modifiable, and

traceable. Review teams should include end user representatives and customer representatives, in

addition to the developer participants. Use quality checklists as an aid to the review process.

• Plan how each requirement will be verified (i.e. establish acceptance tests).

6.3 Characteristics of well-formed requirements

A well-formed requirement is a statement of system functionality that can be validated.

A requirement must be met or possessed by a system to solve a customer problem or to achieve a

customer objective.

A well-formed requirement is qualified by measurable conditions and bounded by constraints.

This means that requirements can be taken from stakeholder needs and can be derived from technical

analysis.

On the basis of what stated in [Ref. 1] and [Ref. 2], the following table (Table 1) contains a list of

characteristics belonging to well-formed requirements and the strategy adopted in order to ensure that

the CCL requirements have these attributes.

Characteristics of a well-formed requirement

Attribute Description Strategy for CCL requirements definition Correct A requirement is correct if, and

only if, is one that the product to

be developed shall meet.

CCL requirements will be compared with the real

scenarios described in D2.1 [Ref. 4] and with the use

cases developed in WP1 to ensure that they are in

line with customer needs.

Unambiguous Each requirement should be

stated in such a way that it can

be interpreted in only one way,

either by who creates it or by

who uses it.

CCL requirements will be defined using the natural

language, which is prone to misleading

interpretations. In order to mitigate this risk, a

structured natural language is adopted. In particular,

all requirements are written using the active tense,

clearly stating the subject and the object of any

sentence. Moreover, the terms “shall”, “should” and

“may” are used to indicate respectively mandatory,

desirable and optional requirements. In addition to

this, the glossary contained in D2.1 [Ref. 4]

represents the reference repository of the terms used

for the elicitation of requirements contained in this

deliverable. This glossary is reported in section 7 for

completeness; specific terms necessary for the

description of the requirements contained in this

deliverable have been added to this list.

Finally, negative statements and compound

D4.2


statements are avoided.

Complete A requirement specification is

complete if, and only, it includes

the following elements:

• all relevant requirements

whether relating to:

o functionality,

o performance,

o design

constraints,

o external

interfaces,

o any external

requirements

imposed by a

system

specification.

• definition of the

responses of the

subsystem to all classes

of input data in all

realizable classes of

situations, to both valid

and invalid input values.

• full labels and references

to all figures, tables, and

diagrams in the

requirements

specification and

definition of all terms

and units of measure.

CCL requirements are presented in this deliverable

following the structure proposed in section A.5 of

[Ref. 1].

In addition to this, labels and references to all figures,

tables, and diagrams in the requirements specification

and definition of all terms and units of measure have

been adopted.

Consistent A requirement specification is

internal consistent if, and only if,

no subset of individual

requirements described in it

conflict.

Every CCL requirement will be manually inspected

and analysed with regard to its relationships and

dependencies with the other features and

requirements.

Ranked for

importance

and/or

stability

A requirements specification is

ranked for importance and/or

stability if each requirement in it

has an identifier to indicate

either the importance or stability

of that particular requirement.

Typically, all of the requirements

that relate to a product are not

equally important. Some

requirements may be essential,

especially for life-critical

applications, while others may be

desirable.

Each requirement in the

specification should be identified

Every CCL requirement is uniquely identified, is

assigned a status (“Proposed”, “Approved”,

“Implemented”, “Rejected” or “Future Enhancement”

(see Figure 7)) and a priority, using the MoSCoW

prioritisation technique [Ref. 7].

D4.2


to make these differences clear

and explicit.

Verifiable A requirement is verifiable if, and

only if, there exists some finite

cost-effective process with which

a person or machine can check

that the product meets the

requirement. In general any

ambiguous requirement is not

verifiable.

The requirements specification for CCL avoids the use

of statements such as “works well”, “good human

interface”, and “shall usually happen.”, which cannot

be verified in practice.

The requirements are written with concrete and

measurable quantities, where possible.

In addition to this, the implementation of the CCL

requirements will be benchmarked with the aid of the

industrial use cases defined in WP1, which will be

used as reference proof-of-concept of the entire

OPENCOSS platform.

Modifiable A requirements specification is

modifiable if, and only if, its

structure and style are such that

any change to the requirements

can be made easily, completely,

and consistently while retaining

the structure and style.

The CCL requirements are organized and classified

following the structure of this deliverable and written

in such a way to avoid redundancy. Whenever

redundancy will be necessary, the specification will

include explicit cross-references to make it

modifiable.

Every requirement is expressed separately, not

intermixed with other requirements. Finally the

traceability matrix described in section 3 will facilitate

the analysis of the impact of any specific change in

the CCL on the rest of this framework.

Traceable A requirement specification is

traceable if the origin of each of

its requirements is clear and if it

facilitates the referencing of each

requirement in future

development or enhancement

documentation.

CCL requirements are uniquely identified using a

specific template. In addition to this, the traceability

matrix described in section 3 facilitates the

identification of the requirements being affected by

any modification to the CCL requirements

specification.

Table 1 - Characteristics of well-formed requirements

6.4 Requirement pitfalls

As stated in IEEE std 1233 [Ref. 2], when building well-formed requirements the following pitfalls should be

avoided:

• Design and implementation: avoid to include design and implementation decisions along with the

requirements statements. If this information may be important, it should be documented and

communicated in some other form of documentation in order to aid in design and

implementation.

• Over-specification:

o Requirements should express what the system should do, not an exact commercial system

set or a system that can be bought rather than made;

o Requirements should never state tolerances for items deep within the conceptual system

(it is similar to give an implementation of the system);

o Requirements should state a need of the customers/user of the system and never

implement solutions.

D4.2


• Over-constrained: Requirements shouldn’t have unnecessary constraints.

• Unbounded:

o Requirements shouldn’t make relative statements. (These requirements cannot be verified

and may only need to be restated. For example, the requirement to “minimize noise” may

be restated as “noise levels should not exceed...”)

o Requirements shouldn’t be open-ended (frequently stated as “including, but not limited

to...” or lists ending in “etc.”)

o Requirements shouldn’t make subjective or vague statements (frequently contain terms

such as “user friendly”, “quick response time”, or “cost effective”).

• Assumptions:

o Requirements should be based on documented assumptions. (The assumption should be

documented as well as the requirement.)

o Requirements shouldn’t be based on the assumption that a particular standard or system

undergoing development will reach completion. (The assumption and an alternative

requirement should be documented.)

D4.2


7 Annex: Glossary

This Annex describes the concepts that are used for the elicitation of the requirements for the Common

Certification Language. The concepts and related description contained here are the same provided in the

deliverable D2.2 [Ref. 5]; additional definitions of some terms used for the description of the requirements

of the Common Certification Language have been added in this deliverable.

The glossary has been inserted in this document to make it self-referencing and to make it easier for the

reader to understand the meaning of the crucial terms used along the deliverable.

Concept Description Source

Architecture The fundamental organization of

a system embodied in its

components, their relationships

to each other and to the

environment, and the principles

guiding its design and evolution.

IEEE1471

Assessment Process of analysis to determine

whether the Design Authority

and the Validator have achieved

a product at meets the specified

requirements and to form a

judgement to whether the

product is fit for its purpose

CEI EN 50128:2002-04

Assessor Person or agent appointed to

carry out the assessment

CEI EN 50128:2002-04

Certification Legal recognition by the

certification authority that a

product, service, organization or

person complies with the

requirements. Such certification

comprises the activity of

technically checking the product,

service, organization or person

and the formal recognition of

compliance with the applicable

requirements by issue of a

certificate, license, approval or

other documents as required by

national laws and procedures. In

particular, certification of a

product involves: (a) the process

of assessing the design of a

product to ensure that it

complies with a set of standards

applicable to that type of product

so as to demonstrate an

acceptable level of safety; (b) the

process of assessing an individual

product to ensure that it

DO-178B:1992, DO-297:2007

D4.2



conforms with the certified type

design; (c) the issuance of a

certificate required by national

laws to declare that compliance

or conformity has been found

with standards in accordance

with items (a) or (b) above.

Compliance A demonstration that a

characteristic or property of a

product satisfies the stated

requirements

CEI EN 50126:2000-03

Component A self-contained part,

combination of parts,

subassemblies or units, which

performs a distinct function of a

system.

DO-178B:1992

Context The set of external factors

(normative, legal, physical etc.)

that have a direct/indirect impact

on the system

D4.2

Design Authority Body responsible for the

formulation of a design solution

to fulfill the specified

requirements and for overseeing

the subsequent development and

setting to work of a system in its

intended environment

CEI EN 50128:2002-04

Element part of a product that has been

determined to be a basic unit or

building block

CEI EN 50128:2002-04

Error a deviation from the intended

design which could result in

unintended system behaviour or

failure

CEI EN 50128:2002-04

Failure The inability of a system or

system component to perform a

required function within specified

limits. A failure may be produced

when a fault is encountered.

DO-178B:1992

Fault An abnormal condition which

could lead to an error or a failure

in a system. A fault can be

random or systematic.

CEI EN 50128:2002-04

Function A mode of action or activity by

which a product fulfills its

purpose.

CEI EN 50129:2004-01

Hazard a real or potential condition that

can cause injury, illness or death

to personnel; damage to or loss

of a system, equipment or

MIL Std 882d Definitions Section

D4.2



property; or damage to the

environment

Hazard analysis The process of identifying

hazards and analyzing their

causes, and the derivation of

requirements to limit the

likelihood and consequences of

hazards to a tolerable level.

CEI EN 50129:2004-01

Hazard log The document in which all safety

management activities, hazards

identified, decisions made and

solutions adopted, are recorded

or referenced.

CEI EN 50129:2004-01

Maintainability The probability that a given

active maintenance action, for an

item under given conditions of

use can be carried out within a

stated time interval when the

maintenance is performed under

stated conditions and using

stated procedures and resources.

IEC 60050(191) referred to in CEI

EN 50126:2000-03

Maintenance The combination of all technical

and administrative actions,

including supervision actions,

intended to retain a product in,

or restore it to, a state in which it

can perform a required function

IEC 60050(191) referred to in CEI

EN 50126:2000-03

May Is permissible CEI EN 50129:2004-01

Reliability The ability of a (sub)system or

component to uphold a certain

performance level during a

certain period of time and under

certain circumstances. Reliability

is regarded as the behaviour of a

(sub)system or component in the

presence of errors.

ISO 9126-1:2001

Re-use This term is applied to both data

(artifacts, evidences, parts of

argumentation/data) and

physical components and can

happen within the same domain,

across different domains, within

the same domain but in different

environments (for example

countries), when there is an

update in the standard and/or to

the component

D4.2

Risk The probable rate of occurrence

of a hazard causing harm and the

degree of severity of the harm.

CEI EN 50126:2000-03

D4.2



Safety Freedom from unacceptable

levels of risk of harm

CEI EN 50129:2004-01

Safety Integrity Level (SIL) One of a number of defined

discrete levels for specifying the

safety integrity requirements of

the safety functions to be

allocated to the safety related

systems. Safety Integrity Level

with the highest figure has the

highest level of safety integrity.

CEI EN 50126:2000-03

Safety-related Carries responsibility for safety CEI EN 50129:2004-01

Shall Is mandatory CEI EN 50129:2004-01

Should Is recommended CEI EN 50129:2004-01

System A collection of components

organized to accomplish a

specific function or set of

functions. The term system

encompasses individual

applications, systems in the

traditional sense, subsystems,

systems of systems, product

lines, product families, whole

enterprises, and other

aggregations of interest.

IEEE1471

System lifecycle The activities occurring during a

period of time that starts when a

system is conceived and end

when the system is no longer

available for use, is

decommissioned and is disposed.

CEI EN 50126:2000-03

Technical safety report Documented technical evidence

for the safety of the design of a

system/sub-system/equipment.

CEI EN 50129:2004-01

Validation Confirmation by examination and

provision of objective evidence

that the particular requirements

for a specific intended use have

been fulfilled.

CEI EN 50126:2000-03

Verification The activity of determination, by

analysis and test, at each phase

of the life-cycle, that the

requirements of the phase under

consideration meet the output of

the previous phase and that the

output of the phase under

consideration fulfils its

requirements.

CEI EN 50129:2004-01

detailed requirements for the common certification language d4 · practices, user needs and...

Documents