common certification language: conceptual model d4.4 version 1 · refers to the models and...

Collaborative Large-scale Integrating Project

Open Platform for EvolutioNary Certification Of Safety-critical Systems

Common Certification Language: Conceptual Model

D4.4 version 1.4

Work Package: WP4: Common Certification Language

Dissemination level: PU

Status: Draft – ready for WP review

Date: March 25th, 2015

Responsible partner: Dr Katrina Attwood, University of York

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 2013-04-26 ToC

V0.2 2013-05-26 First draft version, released for WP and PB review simultaneously

V0.3 2013-06-06 Comments from reviewers incorporated; Ready for PB approval

V0.4 2013_06_07 Revised Future Work and Conclusion sections following PB comment

V0.5 2013-06-10 Approved by PB

V1.0 2013-06-14 Release for the EC

V1.1 2013-12-10 Review after finishing the First OPENCOSS Prototype evaluation (TECNALIA)

V1.2 2014-04-06 Integration of Argumentation metamodel, Katrina’s notes and Huáscar’s inputs to new metamodel updates

V1.3 2014-10-15 Revision after finishing the Second OPENCOSS Prototype

V1.4 2015-02-02 Revision after finishing the Third OPENCOSS Prototype

V1.5 2015-03-25 Final version of deliverable for project. Addition in Section 7 of proposed changes to model which were not implemented, and minor editorial changes throughout the document

Names Organisation

Huascar Espinoza, Alejandra Ruiz, Angel Lopez, Idoya del Río, Mari Carmen Palacios

TECNALIA Research & Innovation

Jerôme Lambourg AdaCore

Yaping Luo, Martijn Klabbers, Luc Engelen Eindhoven University of Technology

Jose Luis de la Vara, Sunil Nair, Rajwinder Kaur Panesar-Walawege

Simula Research Laboratory

Katrina Attwood, Philippa Ryan Conmy, Tim Kelly, Oleg Lisagor, Thomas Richardson

University of York

Giorgio Tagliaferri RINA

Eric Verhulst Altreonic

Paolo Panaroni Intecs

Maurice Assouline Atego France

Sascha Baumgert IKV

Common Certification Language: Conceptual model D4.4

FP7 project # 289011 of 111

TABLE OF CONTENTS

1 Executive Summary 7

2 Introduction to the Common Certification Language and its role in OPENCOSS 8 2.1 Purpose of this document 10 2.2 Overview of document structure 10

3 The Common Certification Language: Modelling Approach 11 3.1 Overview 11 3.2 Inter-Model relationships in conventional MDA approaches 13 3.3 Abstraction hierarchy and Vertical (inter-model) relationships in OPENCOSS 14 3.4 Horizontal relationships in OPENCOSS 18 3.5 “Partial Mapping” in OPENCOSS 19

4 The CCL Vocabulary 21 4.1 Vocabulary Structure 21 4.2 Vocabulary Content 22 4.3 Vocabulary Mapping 23 Structured Expressions for Assurance Argumentation 24 4.4 24

5 The CCL Metamodel 26 5.1 Overview 26 5.2 Relationship with version 2 of the CCL Metamodel 27 5.3 Dependencies between CCL Metamodel Packages 27 5.4 Reference Assurance Framework (Refframework) Metamodel 29

5.4.1 Scope and Purpose 29 5.4.2 Model Definition 29

5.5 Assurance Project (AssuranceProject) Metamodel 40 5.5.1 Scope and Purpose 40 5.5.2 Model Definition 40

5.6 Baseline Metamodel 45 5.6.1 Scope and Purpose 45 5.6.2 Model Definition 45

5.7 Assurance Asset (AssuranceAsset) Metamodel 58 5.7.1 Scope and Purpose 58 5.7.2 Model Definition 58

5.8 Artefact Metamodel 61 5.8.1 Scope and Purpose 61 5.8.2 Model Definition 61

5.9 Process Metamodel 65 5.9.1 Scope and Purpose 65 5.9.2 Model Definition 65

5.10 Vocabulary Metamodel 69 5.10.1 Scope and Purpose 69 5.10.2 Model Definition 69

5.11 Mappings Metamodel 73 5.11.1 Scope and Purpose 73 5.11.2 Model Definition 74

5.12 Argumentation Metamodel 77 5.12.1 Scope and Purpose 77 5.12.2 Model Definition 77

5.13 Property Metamodel 91



5.13.1 Scope and Purpose 91 5.13.2 Model Definition 91

5.14 General Metamodel 94 5.14.1 Scope and Purpose 94 5.14.2 Model Definition 94

6 The CCL within OPENCOSS 97 6.1 General 97 6.2 The CCL and Compositional Certification (WP5) 97 6.3 The CCL and the Evolutionary Evidence Chain (WP6) 99 6.4 The CCL and Transparent Certification and the Compliance-Aware Process (WP7) 100

7 Future Work 101

8 Conclusions 106

9 Abbreviations and Definitions 107

10 References 108

11 Appendix A: Evolution of this document from version 2 of D4.4 109



List of Figures

Figure 1. The CCL Approach (3-layered structure) ...................................................................................... 12 Figure 2. OPENCOSS Model Framework ...................................................................................................... 15 Figure 3. Inter-model Relationships Example .............................................................................................. 17 Figure 4. Horizontal (“translation”) relationship between models at the same abstraction layer

(reproduced from [2]) ............................................................................................................................. 18 Figure 5. Metamodel Views ......................................................................................................................... 26 Figure 6. CCL Metamodel Packages ............................................................................................................. 28 Figure 7. Reference Assurance Framework Metamodel (Part 1: Core Model Elements) ........................... 32 Figure 8. Reference Assurance Framework Metamodel (Part 2: Inheritance Relationships) ..................... 33 Figure 9. Assurance Project Metamodel (Part 1: Core Model Elements) .................................................... 44 Figure 10. Assurance Project Metamodel (Part 2: Inheritance Relationships) ............................................ 44 Figure 11. Baseline Metamodel (Part 1: Core Model Elements) ................................................................. 48 Figure 12. Baseline Metamodel (Part 2: Inheritance Relationships) ........................................................... 49 Figure 13. Assurance Asset Metamodel ...................................................................................................... 60 Figure 14. Artefact Metamodel (Part 1: Core Model Elements).................................................................. 63 Figure 15. Artefact Metamodel (Part 2: Inheritance Relationship) ............................................................. 63 Figure 16. Process Metamodel (Part 1: Core Model Elements) .................................................................. 67 Figure 17. Process Metamodel (Part 2: Inheritance Relationships) ............................................................ 67 Figure 18. Conceptual Vocabulary Metamodel ........................................................................................... 70 Figure 19. Vocabulary Implementation Metamodel ................................................................................... 71 Mappings Metamodel ................................................................................................................................. 76 Figure 20. ......................................................................................................................................................... 76 Figure 21. Assurance Case class diagram ..................................................................................................... 78 Figure 22. Argumentation Class Diagram .................................................................................................... 79 Figure 23. Relationships view diagram ........................................................................................................ 80 Figure 24. Argumentation Class Example .................................................................................................... 82 Figure 25. InformationElementCitation Class Example ............................................................................... 84 Figure 26. Claim Class Example .................................................................................................................... 86 Figure 27. ArgumentReasoning Class Example ............................................................................................ 87 Figure 28. AssertedInference Class Example ............................................................................................... 88 Figure 29. Choice Class Example .................................................................................................................. 88 Figure 30. AssertedEvidence Class Example ................................................................................................ 89 Figure 31. AssertedContext Class Example .................................................................................................. 90 Figure 32. AssertedChallenge Class Example ............................................................................................... 90 Figure 33. AssertedCounterEvidence Class Example ................................................................................... 91 Figure 34. Property Metamodel diagram .................................................................................................... 93 Figure 35. General Metamodel diagram...................................................................................................... 96



List of Tables

Table 1. Change Requests for Metamodel which were not Incorporated during OPENCOSS 101 Table 2. Developments from Version 2 109



1 Executive Summary

Work Package 4 is working towards the development of a harmonised terminological and conceptual understanding of safety assurance across and within the OPENCOSS target domains. The outputs from the WP will be twofold. Firstly, we will produce standardised models addressing key concerns of the project’s main technical challenges: safety argumentation, evidence characterisation and compliance management. These models can be characterised for each standard or domain. Secondly, we will produce a means by which the terminology used for core assurance concepts can be harmonised and compared. Taken together, these outputs will serve as an enabling technology for the approaches to compositional argumentation, evidence management and process compliance to be developed in WPs 5-7. The project refers to the models and vocabulary together as the “Common Certification Language” (CCL). This document presents the final metamodel for the CCL, together with a discussion of the modelling approach adopted by the project and the “partial mapping” technique by which the complexities of the domains are related. This is the fifth iteration of the deliverable, and has been produced to reflect decisions taken and observations made during the development and evaluation of the third version of the prototype tooling for OPENCOSS and to record proposed changes to the CCL which arose during prototype testing, were not incorporated during OPENCOSS but which might serve as a useful input to future research in the area.



2 Introduction to the Common Certification Language and its role in OPENCOSS

OPENCOSS seeks to reduce the costs inherent in recurrent safety certification or re-verification of systems and software (in the broad range of meaning of ‘systems’, taking account of the need to re-verify versions of systems throughout development and in-service modification), when specific or generic components or subsystems are reused across projects, organisations or domains. The project aims to achieve this by

facilitating the informed reuse of safety assurance assets and design assets such as code.1 One obstacle to the cost-effective reuse of such assets is the fact that the terminology and concepts used to describe and manage safety assurance across the OPENCOSS target domains are not consistent: there is no “common approach” to safety assurance and no standardised terminology and concepts used to describe it (for a further discussion of this point, see §3.3.2 of [17]). This is more than simply a matter of terminological inconsistency. The requirements of the standards – in terms of which characteristics must be demonstrated and which artefacts must be produced – can vary considerably. It is difficult to reuse the artefacts associated with safety assurance, since these are produced for a particular defined context, according to the requirements of domain-specific standards. They may also be designed with fault-management for specific safety scenarios. This means that assurance artefacts often need to be produced again in order to secure approval in the reuse context. The OPENCOSS approach aims to reduce much of this repeated assurance effort, by promoting a flexible approach to reuse which is fully cognizant of the similarities and differences between approaches to safety

assurance across the target domains.2 There are two important aspects to this work. Firstly, we need to establish a clear understanding of the terminology used in each of the domains and the standards, in order to clarify where there is conceptual commonality between them and where concepts can be compared and mapped. For example, there is some degree of overlap between concepts such as ‘fault’, ‘hazard’ and ‘mishap’ and what constitutes a ‘component’ or a ‘subsystem’, but there are also gaps between the definitions of these concepts across the standards. Secondly, we need to understand how the concepts work in terms of their relationship with one another to define the objectives of the standards – i.e. the intent which informs requirements and process activities, and the artefacts they result in -, in order to come to a clearer understanding of the role played by each activity and artefact in the overall assurance effort. Only then can we understand whether reuse of the artefacts is reasonable or determine what further analysis is required to justify claims of compliance. For example, we need to understand the reasons why fault analysis is performed and the point in the development of the system at which it is applied (and hence the degree of detail involved). This second aspect of the work is vital in assessing to what extent the reuse of safety assurance assets is appropriate in specific contexts in both argument-based and compliance-based (i.e. matrix-driven approaches, where no explicit argument is provided) assurance schemes. In a compliance-based approach, understanding of the objectives driving production of the required artefacts will enable us to identify and

1 For the purposes of this document, “safety assurance asset” refers to any of the artefacts produced during the development, assessment and justification of a safety-critical project. This includes, for example, requirements statements, analysis results, test results, test plans, designs, specifications, safety argument fragments etc. 2 We are fully aware of the boldness and ambition of this claim, given the scale of assurance projects, in terms of the sheer volume of assets involved, and the complexity of the mutual dependencies between them. The scalability of the proposed technique will, obviously, be assessed using the targeted case studies proposed by the OPENCOSS consortium, particularly the cross-domain IMA reuse example from Thales.



claim equivalence between assurance assets required in different domains, and thus to reduce work where there is clear overlap. It will also enable us to perform informed gap analysis on the standards, and mitigate against the danger of inappropriate reuse where a given artefact does not appropriately match the

requirements of the reuse context. In an argument-based approach (i.e. one in which the safety argument3 is explicitly used to present and justify the evidence provided), understanding of the objectives will enable us to state clearly what can be claimed for a given artefact and accounted for in the reuse domain. The compositional argument approach to be adopted in OPENCOSS (described in [1]) will rely on the ability to characterise pre-existing argument modules in terms of the intent of the applicable standards. Clearly, this characterisation will rely on a clear understanding and statement of the assurance objectives of each standard, and of the assurance assets used to evince the claims made to demonstrate their satisfaction. Although the preceding discussion focuses on the issue of cross-domain reuse (a principal concern of the OPENCOSS project, reflected in the cross-domain industrial case from Thales), there is also a need for a common understanding of safety assurance concepts within individual domains, to support reuse across projects (as reflected in the ALSTOM and CRF industrial cases, which focus on the railway and automotive domains respectively). Here, the most immediately obvious differences are at the terminological level. The use of terminology within the standards themselves is not always consistent, and there may also be differences between regulatory documents within a single domain (for example, between aerospace standards and the JARs4). There may also be differences between company-specific practices and documentation and the regulatory documentation5, or between the terminology deployed by different partners in a supply chain (each of which may themselves be working to a separate local practice mapped to, but distinct from, the standards). OPENCOSS seeks to provide a structured and harmonised way to store and communicate knowledge about safety assurance artefacts and concerns. A consistent terminology is one means by which we can enable different actors in the assurance effort to communicate effectively. We should also note, however, that the terminological discrepancies may themselves mask differences in the conceptual understanding of core assurance concepts, even within domains, i.e. across different regulatory documents or different partners within the supply chain. Again, a clear conceptualisation of safety assurance for the domain will assist in communication and effective knowledge management and transfer. The terminology is indeed a first and important issue. But it goes deeper. For example SIL levels are about reducing the residual risk. This depends on the usage pattern (continuous vs. occasional) and what is considered a safe state (i.e. aircraft must stay in the air, trains be brought to a safe stop, automobiles depend on maintenance of driver control). Thus, metrics as defined in the safety standards do not map directly, and straightforward reuse is not possible because the normative requirements are different at a fundamental level. Work Package 4 is working towards the development of a harmonised terminological and conceptual understanding of safety assurance across and within the OPENCOSS target domains. The outputs from the WP will be twofold. Firstly, we will produce standardised models addressing key concerns of the project’s main technical challenges: safety argumentation, evidence characterisation and compliance management. These models can be characterised for each standard or domain. Secondly, we will produce a means by

3 The concept of the safety argument is defined and described in detail in [1]. 4 JARs are the Joint Airworthiness Requirements: a set of unified, detailed aviation requirements which have been agreed by the Civil Aviation Authorities of certain European countries as providing an acceptable basis for showing compliance with their national airworthiness regulations. The intention is to minimize problems with certification on international joint ventures and also to facilitate the export and import of aviation products, including software-intensive systems. 5 It should be noted that, in many cases, industrial projects are required to work not directly to the applicable standards, but to Company-defined practices, which are themselves derived from and mapped to the standards. There is a great potential for ‘mismatch’ between standards terminology and the terminology used in project documentation.



which the terminology used for core assurance concepts can be harmonised and compared. The metamodels produced in WP4 are supplemented with a further model, which is under development in WP5, and addresses issues relating to the structuring and expression of assurance arguments. Taken together, these outputs will serve as an enabling technology for the approaches to compositional argumentation, evidence management and process compliance to be developed in WPs 5-7. The project refers to the models and vocabulary together as the “Common Certification Language” (CCL).

2.1 Purpose of this document

In order to achieve consistency in the characterisation of domain-, standard- and project-specific models and the presentation of terminology in the Common Certification Language, there is a need to provide a generic framework within which the models can be developed. This is achieved by the development of a Metamodel to define the generic concepts and relationships relevant to safety assurance which are to be captured in the characterised models. The purpose of this document is to present and describe the generic CCL Metamodel and to outline the modelling approach adopted in the project. The theoretical basis for the approach is outlined in [2], and is not repeated here, although the theory remains unchanged. The metamodel is presented in Section 5 of this document, and further detail is given of the “mapping” approach to be adopted. Appendix A provides details of the degree of change between this iteration and version 2 of the deliverable. Changes made in this document reflect the inclusion of material to support cross-domain reuse and the development of the Vocabulary. Please note that the finer-grained definitions of concepts produced in the OPENCOSS Vocabulary are not (apart from a short example) presented in this deliverable. A sample vocabulary for ISO 26262 produced for the automotive case study is stored in the prototype tooling. A section has also been added to record proposed changes to the CCL which arose during prototype testing, were not incorporated during OPENCOSS but which might serve as a useful input to future research in the area

2.2 Overview of document structure

The remainder of this document is structured as follows. Section 3 presents an overview of the modelling approach adopted in the OPENCOSS, highlighting important differences between this approach and conventional model-driven approaches. Section 4 provides a brief account of the CCL vocabulary (also referred to as the Thesaurus). Section 5 presents the CCL Metamodel. Section 6 discusses the role of the CCL in the OPENCOSS project, in terms of its interactions with the work being undertaken in the other technical workpackages (WPs 5-7). Section 7 captures change requests for the Metamodel which were not enacted during the OPENCOSS project, but which are stored as a potential input to future work using the model. The report’s conclusions are outlined in Section 8. Abbreviations and references are detailed in Sections 10 and 11 respectively. Appendix A provides an account of the changes between this document and the previous iteration of the deliverable (version 2, February 2013), in the interests of future version control of the metamodel during the incremental development phases of OPENCOSS.



3 The Common Certification Language: Modelling Approach

In this section, we describe the modelling approach which has been adopted for the CCL, and the “partial mapping” technique which is used to capture the complex relationships between model elements and terms.

3.1 Overview

One of the principal objectives of OPENCOSS is to reduce the rework costs associated with the re-development of assurance assets in reuse situations [3]. This concept of reuse of assurance assets relies on a clear understanding of three inter-related aspects of assurance: compliance management, safety argumentation and evidence characterisation. We clarify these concepts below:

Compliance Management encompasses the process and activities which are required to be carried out in order to demonstrate compliance to a standard/best practice/company standards by means of a series of defined deliverables specified in, for example, a compliance matrix. This is also referred to as “process-focussed” safety, and may be handled by the use of argumentation.

Safety Argumentation is the process by which the safety of a system is explicitly justified against a series of safety goals, derived from the objectives or requirements of a given standard. This is also referred to as “product-focussed” safety.

Evidence Management (also referred to as Evidence Characterisation): both approaches depend on the presentation of evidence - assurance artefacts which support the claims made in the safety

argument, or which can be used to fill out a compliance checklist.6 The third central aspect is an approach to the characterisation of assurance assets (“evidence”) which will facilitate informed reuse and limited rework.

These three core aspects of the OPENCOSS approach are at the heart of the CCL. Figure 1 summarises the approach in terms of a three-layered structure, capturing Conceptual, Standard-specific and Project-specific layers of abstraction. We will elaborate further on what these layers mean – in terms of the relationships between models – in due course, but a short summary is in order here.

6 As discussed in Section 3.4 of [2], the compliance-based approach is by no means as crude as the brief description here might suggest: at the heart of the approach is an implied “argumentation” process by which the adequacy of the assurance artefacts presented is queried and justified, albeit implicitly.



Figure 1. The CCL Approach (3-layered structure)

At the “Conceptual Layer” in Figure 1, the metamodels for the CCL are defined. These models address the three main project concerns– compliance management, safety argumentation and evidence characterisation. Also at this level, a Mapping metamodel is defined. This model captures the mechanisms by which the mappings between elements in the other metamodels (and, by extension, in models developed in conformance with those models) and the items in the Thesaurus are linked. Also at the conceptual level, a “CCL propositional language” metamodel is defined. This metamodel is presented as the “Vocabulary Metamodel” in this document, and will be used to define the structure and characterisation of propositional statements in the argument claims and requirements which will be used in the compositional certification approach to be developed in Work Package 5, as well as to define the structure of entries in the CCL Thesaurus. At the “Standard-specific” layer in Figure 1, standard-specific and domain-specific models are identified. These are models of the relevant assurance aspects of the applicable standards and guidance from the target domains, together with company and industry ‘best practice’ standards, to which assurance projects are developed and with which they need to demonstrate compliance. An initial list of potential domain-specific material of relevance to OPENCOSS is presented in Section 7 of [2]. These models will be developed in such a way as to conform to the metamodels defined at the conceptual level, and will be expressed using terminology from the CCL Vocabulary appropriate to the domain and standard. Also at this level, the CCL Vocabulary (or “Thesaurus”) is identified. At the “Project-specific” level of Figure 1, the project-specific process, assets and assurance artefacts, which are the actual target of the reuse effort in OPENCOSS, are captured. Metadata concerning these artefacts and the processes used to create them is stored in the OPENCOSS Platform. This metadata is stored according to the metamodels specified at the conceptual level via the domain-specific models.



It is important to note that the relationships between the models at these conceptual layers – and, indeed, the arrangement of the layers themselves, are more complex than the raw summary in Figure 1 suggests. This complexity is discussed further in Section 3.3 below. At the heart of the relationship – and, indeed, the source of the necessary flexibility in the OPENCOSS approach – is the concept of “mapping”. In the OPENCOSS approach, “mappings” capture information about the relationships between models at different levels of abstraction, and also – through the CCL Thesaurus and models – between models at the same level of detail – specifically, standards-level and project-level models. Two types of “mapping” are required in OPENCOSS. In the first case, we require an approach to “mapping” between models created using the CCL Metamodel. We refer to this as “Inter-model” mapping. Two types of “inter-model” mapping are required: vertical mappings – between models at different levels in the abstraction hierarchy – and horizontal mappings – between models at the same level of abstraction. In the second case, we require an approach to manage the “mappings” between terms and expressions presented in the vocabulary. NOTE: There is an important difference between the concept of mapping in OPENCOSS and the more common usage in model-driven architecture (MDA) approaches, where vertical mappings between models are thought of in terms of instantiation or conformance. This distinction, and the rationale for it, is discussed in detail in Section 3.3 below. There is some difference between the OPENCOSS approach and that commonly understood in MDA approaches, so we begin by summarizing the more usual approach, in order to ensure a shared understanding and to allow the discussion in Section 3.3 to highlight the differences in OPENCOSS.

3.2 Inter-Model relationships in conventional MDA approaches

The OMG’s MDA Framework defines a metamodelling approach to the description of systems. Models are used to define the elements which can exist in a system: classes are defined in the model and instances of those classes occur in the system. A metamodel is used to define the elements which can exist in the model: for example, the UML metamodel defines elements such as “class”, “package” etc. which can be used to build models. The OMG uses a four-layered architecture, which defines instances, models, metamodels and metametamodels. The layers in the OMG architecture model are defined as follows (from [4]):

Layer M0: Instances (an actual real-world system) At this layer, there is the running system in which the actual (“real”) instances exist. When modelling a ‘real world’ system (rather than software, e.g. an actual monitoring system), the instances at the M0 layer are the items in the system itself (e.g. an actual sensor). When modelling software, the instances are the software representations of the real-world items (e.g. a sensor value).

Layer M1: System Model The M1 layer is the first modelling layer, and contains a model of the real-world system instantiated at M0. The model is represented using some modelling language, such as UML or SysML. At M1, the concepts of the system are defined, e.g. ‘Customer’, ‘Order’. Abstract properties are also defined, e.g. the ‘Customer’ concept might have the properties ‘name’, ‘identification number’, ‘address’, ‘date of birth’.

Layer M2: Metamodel – a Model of the System Model The metamodel presented at the M2 layer provides the concepts used to create the model presented at M1 (i.e. M2 presents the “language” model). Each UML system model at the M1 layer conforms to the UML metamodel at Layer M2, which defines model elements such as “Class”,



“Relationship”. In a sense, the metamodel defines what a ”compliant” model should be (in terms of its obligations and rules) and is similar to a model syntax by analogy to a programming language syntax. For example, the ‘Customer’ concept is defined at M1 as a ‘Customer’ class, which conforms to the ‘Class’ concept defined at M2.

Layer M3: Metametamodel – a Model of M2 The metametamodel presented at the M3 layer provides the concepts used to create the

metamodel presented at M2. Within the OMG, the MOF7 is the standard M3 metametamodel (or “M3 language”). It defines how a model syntax is to be specified and, in a sense, is similar to the old Backus Naur Form (BNF) used to express the syntax of programming languages. The UML conforms to the MOF.

We refer to a layered architecture of this kind, in which models are presented at different levels of

abstraction8 as an abstraction hierarchy. The relationships between the models at different levels of abstraction in the OMG MDA Framework are instantiation relationships. In conventional model-driven approaches. instantiation has strict obligations

and rules9. At each layer, the elements in the higher-level model directly prescribe what instances of those elements at the next layer down look like and how they relate to one another. Instances at level Mn are of the types defined at level Mn+1. Instances which do not conform exactly to the higher-level specification are not feasible. For example, an instance at M0 of the ‘Customer’ class defined at M1 which has a ‘name’ property and an ‘address’ property but no ‘date of birth’ property cannot be an instance of the ‘Customer’ class and must be defined by some other class, or be non-compliant. Similarly, the elements that exist at the M1 layer are instances of the language concepts ‘Class’, ‘Relationship’ etc. defined at M2. Strict instantiation of models implies that each element defined at M1 should be instantiated by at least one element at M0.

3.3 Abstraction hierarchy and Vertical (inter-model) relationships in OPENCOSS

As indicated in Figure 1 above, the OPENCOSS approach – like the OMG MDA Framework – presents models at different layers of abstraction. The relationships between the models are not strictly hierarchical, however, as indicated in Figure 2. Instead, the approach matches the complexity of the pragmatic state of the practice – there is considerable overlap (but not exact equivalence) between the safety standards and the company-specific documentation, and a blurring of the nature of their relationships with the project-level models (the dotted lines in Figure 2 indicates this blurring). The precise role of the company-specific standard may differ between individual organisations and domains (for example, an ISA in one domain may wish and need to take it into account, whereas that may not be necessary elsewhere).

7 MOF = The Meta-Object Facility, an OMG standard for model-driven engineering. The MOF standard is available for download at http://www.omg.org/spec/MOF/2.0/. The document contains a clear account of the intentions of MOF and its relationship with the UML. 8 As used in this document, the term “abstraction” refers to a grouping principle whereby entities are grouped in a hierarchy according to the amount of detail with which they are expressed. Entities expressed at similar levels of detail are grouped together in layers. More abstract, generic layers are placed near the top of the hierarchy, with the amount of detail increasing as the layers go down through the hierarchy. 9 For clarification, note that this strict concept of model instantiation does not apply in the OPENCOSS framework. As will become clearer in the following sections, there is neither a strict hierarchy between the models nor a point-to-point instantiation relationship between them, but the relationships are “looser” in the sense of partial overlaps.

http://www.omg.org/spec/MOF/2.0/



Figure 2. OPENCOSS Model Framework

Three abstraction layers are defined in the OPENCOSS Model Framework. The focus of each of these layers is described below. Note that although the Standard-Specific Model (a model of an individual safety standard) and the Industry Model (a model of, for example, a company best-practice guidance document) are conceptually at the same level in the OPENCOSS Framework – each of them being modelled according to the Reference Assurance Framework concept in the CCL metamodel -, there is some relationship between them.

Level 0: CCL Metamodel At this level, the abstract concepts which can be used to define models in the high-integrity systems and software engineering domains are defined. The CCL Metamodel has three essential aspects, which were developed separately but have been combined: engineering process (including some concepts from safety engineering), safety standards and evidence management (relating the use of artefacts from the engineering process to the approval process). The CCL Metamodel also includes metamodels orthoganal to those three principal models, relating to the mappings mechanisms used in OPENCOSS and the structure of the vocabulary.

Level 1: Safety Standard Metamodel At this level, concepts from the CCL Metamodel are used to structure models of the safety standards and domain-specific guidance against which systems will be certified. For example, the



CCL Metamodel concept ”Reference Artefact” is represented in the Safety Standard Model for DO-

178B as ”PSAC” (Plan for Software Aspects of Certification).10

Level 1b: Internal Industry Model (also known as Company Standard Model)11 It is common in industrial practice for projects to be developed not directly in accordance with the

safety standards, but in accordance with internal company standards12 or guidance which reflect –

and often elaborate – the content of the standards.13

Level 2: Project Model At this level, the Project Model is developed. Note that, in practice, it is common to do this not in direct consultation of the standards, but in accordance with the Internal Industry Model/Company Standard Model. For further discussion of this relationship, see below.

As will be clear from the discussion above and from Figure 2, the relationships between the models in the OPENCOSS Framework differ in nature from the strict instantiation relationships in the OMG architecture model. Strict instantiation can be applied between the Levels 0 and 1 of the OPENCOSS Framework. The relationship between the CCL Metamodel and the Standard Model is one of instantiation - every element in the Standard Model is a strict instance of its exemplar in the CCL Metamodel, and the relationships established in the CCL Metamodel are reflected fully in the relationships used in the Standard Model. This is a straightforward type:instance relationship. For example, the Reference Artefact “DO-178B:PSAC” defined in the Standard Model for DO-178B conforms to the “Reference Artefact” type established in the CCL Metamodel. Similarly, the relationship between the Industry Model at Level 1b and the CCL Metamodel should be treated as an instantiation. The relationship between the Internal Industry Model (Level 1b) and the Standard Model (Level 1) is more complex, however. As stated above, the industry guidance and company standards against which a project is actually developed reflect the safety standard(s), in that they provide an interpretation of the standard for a given project. This maps to the safety standard, but cannot be treated as a strict instantiation of it, since a degree of elaboration or interpretation is often involved, as, for example, in the case of requirements with complex interdependencies (”if you are doing this activity, you will also need to do this one”) or where activities are recommended but not mandated. Similarly, the industry model will typically need to map to several standards simultaneously, and resolve inconsistencies between them, since the projectmust demonstrate compliance with multiple standards. The mapping between the two models at Levels 1 and 1b is often more “fuzzy” in nature. For example, the “Company A PSAC” described above as part of the Internal Industry Model might not fully reflect the requirements and expectations of what a PSAC will contain, as defined in the Standard Model for DO-178B: Company A might need to ”tailor”, i.e. define additional sections for inclusion in the report, in order perhaps to satisfy some parallel requirement

10 Note that the standards vary in the degree of prescription they include concerning the content/format/purpose of individual artefacts. In the railway domain, for example, the CENELEC standards very often prescribe a template for artefact content (of which the company version is simply an instantiation). In other domains, the standard simply gives the name of an artefact and its function – as is the case with the DO-178B PSAC. Here, the relationship is not one of instantiation, since the company standard is necessary to indicate the template, and provides the basis for the instantiation. 11 Note that the “company standard” is not treated by ISAs or regulators as a strict standard. The term is used here as a shorthand for “Company interpretation(s) of standards”. 12 Note that these often cover other issues in addition to safety – i.e. organisational issues, quality assurance etc. 13 In discussion with ALSTOM, for example, it has become clear that projects work in accordance with locally-defined “Writing Guides”, which reflect the requirements of applicable standards. The precise nature of these guides, and their relationship with the standards, will be explored during data-gathering with ALSTOM.



from another standard. “Company A PSAC”, then, cannot be described as an instantiation of “DO:178B” PSAC, but as another object of type “Reference Artefact” (from the CCL Metamodel). The relationship might usefully be described as a ”refinement”. A partial mapping between the two elements – indicating which aspects are the same, and which are different, needs to be detailed, in order to provide justification for Company A’s claim that “Company A PSAC” complies with the standard. In principle, the relationship between the Project Model (Level 2) and the Internal Industry Model (Level 1b) ought to be one of straightforward instantiation: all of the assurance assets produced by a project ought to conform to a company’s standard. A project might produce assets by using company standards as a template, or by copy/paste, in which case the project artefacts should be treated as instances of elements in the Internal Industry Model. In such a case, “Project Y: PSAC” can be treated as an instance of type “Company A: PSAC”. In practice, however, this relationship is likely to be more complex: some “tailoring” or editing of the template, or embellishment (enrichment) of the expected content is likely to occur. Once again, a mapping between the elements must be declared, and the similarities and differences between “Project Y: PSAC” and “Company A: PSAC” must be declared. This detail, together with the detailing of the partial mapping between “Company A: PSAC” and “DO-178B:PSAC” is required, in order to provide the means by which the trustworthiness of an assertion – in a compliance matrix or an argument - that “Project Y: PSAC” conforms with DO-178B can be evaluated. Figure 3 summarises the running example presented in this section:

Figure 3. Inter-model Relationships Example

All of the elements presented in models throughout the OPENCOSS Framework conform to the concepts and relationships defined in the CCL Metamodel, as indicated in Figure 2 above. The situation might be further complicated if, for example, a project includes some information relating to the contents of the PSAC in another artefact. In terms of safety, it is not important where information is



stored or how it is written (i.e. in which specific document it appears), but it is essential that all relevant and necessary information is available and correct. In this sense, the PSAC should be seen not as an “atomic” safety artefact, but rather as a collection of artefacts which must be available to the project (no matter where). It is up to the project to provide the mapping.

3.4 Horizontal relationships in OPENCOSS

In addition to the vertical relationships between models in the OPENCOSS abstraction hierarchy, horizontal mappings between models and artefacts at the same level of abstraction must be provided. These mappings are required to enable the OPENCOSS tooling to provide informed guidance as to the similarities and differences between artefacts at the project level (in the context of the various standards), in order to facilitate reuse and provide an indication of the amount of rework required for an assurance artefact to be reused. Figure 4 illustrates this horizontal relationship in the light of the OPENCOSS Framework:

Figure 4. Horizontal (“translation”) relationship between models at the same abstraction layer (reproduced from [2])

At the bottom left of the diagram, an assurance artefact for a particular component has been developed according to the norms established in the standards-level model for Standard A. This standards-level model conforms to the generic metamodel established at the conceptual level, and is expressed using language from the Thesaurus particular to Standard A. The model captures the texts of requirements, descriptions of artefacts, processes etc. using the language of Standard A. Also at the standards level, a model of Standard B has been developed, which also conforms to the generic metamodel and is expressed using language from the Thesaurus particular to Standard B. Within the OPENCOSS Platform, the metamodels, standard-level models and Thesaurus are used to establish discrepancies and similarities between the two standards models in terms of the concerns from the metamodel, and also to indicate the degree of overlap between the terminology used to describe particular concepts. Based on this gap analysis, the OPENCOSS Platform is able to query the metadata stored with the assurance asset to establish the degree to which it can be used to meet the requirements of the target standard, and to advise the safety engineer as to what changes or additions are required to the assurance artefact to facilitate reuse. In practice, the inter-model mappings will not be single-point-to-single-point. In order to establish whether there is a degree of similarity between a given artefact developed for one context and the required artefact

Generic metamodel

Instantiation of metamodel

(for Standard A)

Model of evidence/

argument for Component A

Instantiation of metamodel

(for Standard B)

Model of evidence/

argument for Component A'

Conforms to Conforms to

Conforms toConforms to

'Translation to'



in the reuse context, it is necessary to interrogate the chain of requirements relating to that artefact, both in terms of its physical nature (i.e. are there sections of the Company A PSAC which do not match the requirements for a PSAC as defined in the DO-178B PSAC model?) and in terms of the use to which it is put in the assurance (here, the requirements of the various standards models with respect to the artefact (and, if necessary, to artefacts with which it is linked) are bought into play). The horizontal mapping serves to answer questions such as: if I have a PSAC for DO-178B Level A (original context), what additional information or effort do I require in order to claim that I have Safety Plan for a system developed to ISO 26262 ASIL C (reuse context)? In most cases, the answer will be that there is material missing against the requirement in the reuse domain, and therefore the mapping is only partial.

3.5 “Partial Mapping” in OPENCOSS

In order to address the complexities of the relationships required in the OPENCOSS Framework and Vocabulary, we have developed a nuanced model of “mapping”, which we call “partial mapping” (see [19]). The model is described in detail in Section 5.9 below, and builds on linguistic theories relating to translation which are outlined in some detail in Section 3 of [2] and are not repeated here. The objective of the partial mapping approach is to enable (and, indeed, enforce) the explicit record of information concerning the degree of “map” that can be achieved between elements, resulting from a gap analysis between the original and reuse contexts. This is done by the explicit use of a justification for the mapping (the MapJustification) which takes the form of an account of the similarities and differences between the

elements and a justification as to why a particular degree of “mapping” has been claimed.14 Note that, in discussing the “partial mappings” we are not conceiving of a point-to-point relationship between those elements in models which can take part in the mapping. In order to establish the justification for the map, it is necessary to traverse the full context of the element. This usually means engaging in a full consideration of the chain of requirements relating to the artefact, in order to establish the similarities and differences in terms of content, structure and objective (in terms of the element’s contribution to the assurance of the system in both contexts). Essentially, three types of mapping are identified in OPENCOSS:

Full Map – the elements in the mapping are identical. In a reuse scenario, this implies that the characteristics of the element in its original context (its form, its required content and its objectives fully satisfy the requirements of the context in which it is to be reused).

Partial Map – there is some similarity between the elements, but they are not identical (and there may be significant differences, depending on the context and requirements). In this case, a clear record of the similarities and differences is necessary, to ensure that the guidance provided by the OPENCOSS tooling is meaningful. Some quantitative indication of the ”degree of map” could be provided by the tooling, but this needs to be justified explicitly. This would be of paramount practical importance to answer such questions as: ”If I have an artefact conforming to Standard A, what has to be done to have the corresponding mapped artefact conforming also to Standard B?”

No map – there is insufficient similarity between the elements to permit a mapping to take place.

In each case, a clear record of the similarities and differences is necessary, to ensure that the guidance provided by the OPENCOSS tooling is meaningful. For a full map, this justification is likely to form part of the support for the assurance argument, since it concerns the adequacy and suitability of the evidence supplied in support of a claim.

14 Note that, in many respects, the MapJustification should be conceived as an argument on the mapping.



For a partial map, qualitative and also some quantitative indication of the ”degree of map” could be provided by the tooling, but this needs to be justified explicitly. The “gap” between the original context and the reuse context should be recorded, and structured thinking about the suitability of reuse enforced. Some guidelines on how to fill the “gap” may prove extremely useful. Typically, this requires some extra effort. Good guidelines should help engineers minimise this effort while preserving the intent of the standard. Consider, for example, the case of a software architecture definition which, in order to comply with the standard in the reuse domain (standard B), requires evidence of having been independently reviewed, but which was not independently reviewed in order to meet the applicable standard in the original development context (standard B). The a-posteriori enforcement of a new, independent review seems to be the most reasonable and cost-effective approach to meet standard B. Now consider the case of reusing source code which was originally written by a junior programmer (as required for compliance to the original standard), in a context where the standard requirement states that the code should have been written by a senior programmer. Is it reasonable, in this case, to expect the developer to throw away the code and write it again? Or would it be better (and, potentially, safer) to enforce a code review by a senior programmer as an “improvement action” to fill the “gap” between the standards’ expectations? For a ‘no map’ relationship, a clear justification of the “gap” between the candidate element and the requirements of the target context is required to ensure that inappropriate reuse does not (inadvertently) take place. Figure 3 above illustrates the use of justifications to facilitate partial mappings between model elements. The three types of mapping identified here apply to the mapping relationships between terms (words and expressions) in the OPENCOSS Thesaurus. Current thinking about the use of the Thesaurus in OPENCOSS is explained in Section 4 below. Here, it suffices to state that the mechanism for mapping between terms is identical to that used to map between model elements. It will be clear from this discussion that the mappings mechanism in OPENCOSS is very different in quality to the straightforward instantiation relationships in the OMG MDA Framework. One consequence of this is that fully automated mapping between the models is unlikely: the user will be required to think about, and supply information to support, the mappings in the model instances he creates. The “buy back” is that this information should enable the OPENCOSS tooling to provide detailed guidance as to the nature of the rework considerations (actually what is missing to go from an original context A to a reuse context B) to be taken into account when reusing assurance artefacts, and in creating and checking compositional arguments. Tooling should be provided to assist the engineer in assessing and supporting the partial matches, however.



4 The CCL Vocabulary

As indicated in the Introduction (Section 2), there are two main aspects to the OPENCOSS approach. Firstly, we need to establish a clear understanding of the terminology used in each of the domains and the standards, in order to clarify where there is conceptual commonality between them and where concepts can be compared and mapped. For example, there is some degree of overlap (hopefully!) between basic concepts such as ‘fault’, ‘hazard’ and ‘mishap’ and what constitutes a ‘component’ or a ‘subsystem’, but there are also gaps (sometimes subtle gaps) between the definitions of these concepts across the standards. Secondly, we need to understand how the concepts work in terms of their relationship with one another to define the objectives of the standards – i.e. the intent which informs requirements and process activities, and the artefacts they result in -, in order to come to a clearer understanding of the role played by each activity and artefact in the overall assurance effort. Only then can we understand whether reuse of the artefacts is reasonable or have a clear view of what additional effort and analysis work may be required to justify claims of compliance. For example, we need to understand the reasons why fault analysis is performed and the level of abstraction or the design stage at which it is applied.

4.1 Vocabulary Structure

The OPENCOSS Common Certification Language (CCL) provides a Thesaurus-type vocabulary, which defines and records key concepts relevant to safety assurance within the target domains and the relationships between them. The theoretical basis for the design and use of the vocabulary is presented in Section 3.3 of [2]. The vocabulary will be used to provide the terms and concepts used to characterise 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 within and between domains. In practice, several vocabularies will be instantiated – each being associated with a given ReferenceAssuranceFramework or AssuranceProject. OPENCOSS provides tooling for the specification of vocabularies based on standards, company and project terminology for each of the three domains, although only the automotive standard glossary, derived from 26262 has been developed at any length in OPENCOSS. The vocabularies are structured as concept hierarchies, along the lines of an English language Thesaurus (for example, [21]), with terms being grouped according to general concept types. A concept type is a general category, by which related concepts at lower levels of detail can be grouped. The following extract from the OPENCOSS vocabulary for the ISO 26262 automotive standard (here exported in XML format) illustrates this general structuring principle: <?xml version ="1.0" encoding = "UTF-8"?> <vocabulary id="26262_vocab_test" name = "26262 Sample Vocabulary" description = "This is a sample of the 26262 vocabulary prepared during the OPENCOSS project, to illustrate the structure of the vocabulary."> <category name = "hazards" description =""> <term name="hazard" refersto=""> <definition>A condition or state, caused by malfunctioning behaviour in an item, which has the potential to lead to harm</definition> <note>Definition derives from ISO 26262 Part 1 section 1.57</note> </term> </category>



<category name="fault" description=""> <term name="fault" refersto=""> <definition>An unwanted condition which can cause failure of an element or an item</definition> <note>Definition derives from ISO 26262 Part 1 section 1.42</note> </term> <category name = "systemmatic fault"> <term name="systemmatic fault" refersto="fault"> <definition>A fault which causes a failure which appears deterministically and which can only be prevented by applying fault accommodation measures in the development process or design. </definition> <note>Definition derives from ISO 26262 Part 1 section 1.131</note> </term> <category name="intermittent fault" description=""> <term name="intermittent fault" refersto="fault"> <definition>a fault which occurs repeatedly and then disappears</definition> <note>Definition derives from ISO 26262 Part 1<note> </term> </category> <category name="transient fault" description=""> <term name="transient fault" refersto="fault"> <definition> a fault which occurs sporadically and then disappears</definition> </term> </category> </category> </vocabulary> The OPENCOSS vocabularies also provide definitions of terms in semi-formal structured English, as can be seen in the example above. The notion of the semi-formal definition is derived from the OMG’s Semantics of Business Vocabulary and Business Rules [22], which is an OMG standard for the preparation of controlled or semi-controlled vocabularies for a given domain and for modelling the relationships between domain concepts in intuitive natural language, although OPENCOSS does not implement the full SBVR standard. Where terms defined elsewhere in the vocabulary are used in the definitions, cross-references are provided. In order to facilitate comparison across domains, concept types are defined fairly generically across the domains, resulting in a commonality of general structure in the vocabularies, although the low-level terms grouped under each generic concept might differ substantially between domains. Linguistic relations are used to indicate the relationships between terms, as indicated in the conceptual metamodel in Section 5.10 below.

4.2 Vocabulary Content

It will be noted that relevant standards for the target domains of OPENCOSS each include a small glossary of domain-specific terms and definitions presented as a standard glossary or ‘definition of terms’.



Wholesale use of these glossaries in the OPENCOSS vocabulary has not been possible, for the following reasons:

The standards – including glossaries – are subject to copyright. It is therefore not permissible for OPENCOSS to make wholesale use of the text of the standards – which includes definitions of terms – and make it available in tooling.

The terminology defined in the standards glossaries is only a fraction of that used in the standard. It does not map completely with that required for the OPENCOSS project, in terms of the use of terms in model instantiations and – above all – in safety argumentation (a principal use case for the OPENCOSS vocabulary work). This issue is discussed at greater length in [20], where the requirements for OPENCOSS vocabulary in terms of the argumentation aspects of the project are outlined in detail.

In order to obtain candidate terms for the OPENCOSS standard vocabularies, in order to reduce the burden of effort on a manual vocabulary developer, use has been made of basic Natural language Processing techniques built into the Natural Language Toolkit which has been developed for Python [23]. The intention is to reduce the total vocabulary of the standard into a meaningful subset (in the OPENCOSS ISO 26262 example, some 1000 terms are defined) which adequately characterises the language usage of the standard. The basic algorithm for the technique is as follows:

1. Convert the text of the standard into .txt format for processing and tokenize the resulting string to have a set of word tokens over which to operate.

2. Produce a frequency distribution of all of the word tokens over the entire text. 3. Select the most frequently used word tokens – as a rough heuristic, a word occurring more then

three times over the text can be taken as “frequent”. 4. Identify the most frequent collocations in the document. A collocation is a bigram comprising two

word tokens which occur adjacent to one another frequently in the text. 5. Identify the longest words in the text, since these are often domain-specific terms. As a rough

heuristic, words with more than 7 letters have been taken as significant. 6. Identify the hapax legomena in the text. Hapax legomena are words which occur only once in a

complete document. They might have been missed by the long-words search, and might also carry some significance in the domain.

7. Combine the resulting word lists and covert to a set using Python’s built-in method, in order to reduce duplication.

The result of this technique is a basic list of terms which can then be sifted through by the person responsible for the manual development of the glossary. Terms which are not considered to be of significance in the domain (some of the frequent words fall into this bracket) are discarded, while in other cases gerunds, verbal forms and adjectives found by the NLP techniques are converted into nominal (noun) forms for the vocabulary. Although the technique is not foolproof, use on the construction of the 26262 glossary found a false positive rate of about 30%, which is considered good for NLP. The time saved by this technique in constructing a working glossary, as compared with manual extraction, was considerable. All definitions, of course, are supplied manually, thus the vocabulary developer requires some considerable domain expertise.

4.3 Vocabulary Mapping

It should be noted that there has been a considerable shift in thinking about the use of the Thesaurus within the project since the writing of D4.3 [2]. In that document, the assumption was that the OPENCOSS Project would provide a series of core, agreed definitions of terminology relating to safety assurance across the target domains, and mappings would be provided to these core definitions from the standard-specific



and project-specific usage of the terms. The concept of “partial mapping” was intended to be applied here, to indicate how far a project- or standard-specific term matched the core definition. , Analysis of the gap was to be used to provide some indication of – and guidance about – the possibility of reuse. It has recently been acknowledged that the overhead to OPENCOSS of producing this “core vocabulary” is considerable – the time and effort required to agree on even a small vocabulary of terminology in the pSafeCert project, for example, and the complexity of the domains concerned for OPENCOSS suggests that this would be a very time-consuming and a socio-politically challenging task. A slightly revised model of the Thesaurus is therefore proposed here. In this revised model, the Thesaurus is not used to provide a conceptual “layer” through which translation between terms takes place. Instead, the concept of “partial mappings” is applied directly between terms within the artefacts and models presented in the OPENCOSS Framework, and the nature of the pair-wise mappings (in terms of the similarities and differences between the terms) is explicitly captured in MapJustifications, where required. The broad structure of the OPENCOSS Thesaurus – in terms of the conceptual groupings by which terms are arranged – is provided by the concepts provided in the CCL Metamodel. These conceptual groupings will be further refined by the provision of categories based on a more fine-grained conceptualisation at Levels 1 and 1b.

4.4 Structured Expressions for Assurance Argumentation

A further use case for the vocabulary aspects of OPENCOSS is to provide a means for regularizing the structure of expressions used in claims in assurance argumentation. This work has been written up in detail in [20], but a short summary is provided here for completeness. Having a common syntactic structure for argument claims makes it easier for a reader to parse claims, and avoids issues such as confusion over the scope of a given term in a sentence. It is quite common in “engineering language” for there to be uncertainties over the interpretation of the scope of qualifiers, as in the phrase “failure modes and effect analysis”, where “analysis” serves to qualify both “failure mode” and “effect” and where “failure” qualifies both “mode” and “effect”; a non-specialist reader (or a machine) would be likely to look only for the most limited range, and associate “analysis” only with “effect” and “failure” only with “mode”. Structured expressions can be used to characterise the types of concepts which are discussed at a particular point in an argument, and the relevant features which can be asserted about them. Typically, a structured expression comprises a fixed verb phrase, which carries the ain sense of the claim, while noun phrases, providing the subject and object over which the verb phrase ranges, are parameterisable. For example, a very simple structured expression in an assurance case claim might take the form “{fault of type systematic fault} is adequately mitigated by {fault mitigation technique}”, where both “fault of type systematic fault” and “fault mitigation technique” are broad parameters. Simple expression structures can be combined to form larger syntactic units, for example: form “{fault of type systematic fault} is adequately mitigated by {fault mitigation technique} which addresses {hazard}”. In the OPENCOSS approach proposed in WP5, a series of generic structures are defined and used to refine the logical structures summarised in argument fragment templates captured in patterns such as those defined in D5.3 [20], by specifying the types of concept which are in focus at particular points in the argument. The generic concept types which are used to structure the OPENCOSS vocabulary (see Section 4.1 above) are used to reference the variable parameters. Thus, in this example, “fault”, “fault mitigation technique” and “hazard” are all high-level concept types common across the domain vocabularies. These expressions can then be instantiated to form claims in specific arguments, by supplying variables from the terms listed under the relevant concept types in the vocabulary. Since OPENCOSS defines both domain- and



project-specific vocabularies, we can instantiate claims at two levels of abstraction, meaning that we can use the concept types to specify detailed patterns at the domain level, for instantiation by a project. OPENCOSS has provided automated support for this stage, with the concept types in the vocabulary model being used to present a series of potential instantiations of a given parameter from which an argument writer can choose.



5 The CCL Metamodel

5.1 Overview

In this section, we present the metamodel created for the OPENCOSS Common Certification Language and definitions of the concepts that it includes. The metamodel is presented below in a series of “views”, each of which represents a self-contained aspect of the whole. The general objectives and relationships of the views are captured in Figure 5. Note that there is not a 1:1 relationship between the views introduced here and the metamodels presented in the following subsections, although the overall intent of the models accords with that in Figure 5. The metamodels are presented in Sections 5.3 to 5.12 below. The presentation scheme has been adopted from the OMG’s Structured Assurance Case Model (SACM) [7]. Section 5.2 comprises a brief discussion of the developments between the models presented here and the intermediate CCL metamodel presented in D4.3 [2]. Further details of the differences between D4.3 and the present document are given in the comparison matrix in Appendix A.

Figure 5. Metamodel Views



It will be clear from Figure 5 that the CCL metamodel comprises two conceptual aspects: project-specific assurance assets are mapped to a generic framework, reflecting an abstract understanding of assurance. On the left-hand side of the upper box, three “generic” metamodels are presented, metamodels for Vocabulary, Mappings and Safety Standards. These metamodels are detailed in Sections 5.8, 5.9 and 5.3 below. These three metamodels provide the structuring concepts for the remainder of the models to be developed in OPENCOSS. The Vocabulary Metamodel provides the abstract structure of the vocabulary to be used in the Thesaurus and the standards models, and through which individual project assets are compared and assessed. The Safety Standards Metamodel (also referred to in this document as the Reference Assurance Framework Metamodel) provides the concepts and relationships between assets developed for a safety-critical project and its assurance effort, and thus provides the abstract structure for models of individual standards and company-specific practices. The Mappings Metamodel indicates the mechanisms by which the mappings between models and terminology in OPENCOSS are conceptualised – as discussed in Section 3.5 above. The right-hand side of the upper box presents three metamodels. These capture the core concepts and relationships between the activities undertaken and assets produced during a specific assurance project. These three metamodels are detailed in Sections 5.4-5.7 and 5.10 below. The Process Metamodel details high-level concepts relating to the processes performed as part of a project and the artefacts which are produced by them. The Argumentation Model describes how features of a generic assurance argument are linked together, with particular reference to the use of assurance assets as evidence to demonstrate compliance. As indicated in Figure 5, the three models are closely linked to one another and, by means of a mapping, to the core concepts from the Reference Assurance Framework Model. Two further Metamodels are provided – the Describable Element Metamodel and the Recordable Assurance Asset Metamodel. These metamodels detail the inheritance of characteristics for the elements specified elsewhere.

5.2 Relationship with version 2 of the CCL Metamodel

The CCL Metamodel presented in this section represents a revision of the second version of the CCL Metamodel which was presented in version 2 of D4.4 (issued in February 2014). The version presented in this deliverable is the basis for the third and final prototype of the OPENCOSS tools, and should be treated as the definitive version of the CCL Metamodel, both for conceptual and implementation purposes. The most significant changes between this and the metamodel presented in version 2 of D4.4 are as follows:

Significant Changes to the RefFramework and Assurance Project Metamodels and inclusion of new Baseline Metamodel, to accommodate the development of baseline frameworks and projects;

Addition of and explanation of MapJustification, ComplianceMaps and EquivalenceMaps top the Mappings Metamodel, in order to support cross-domain reuse;

Simplification of the Vocabulary Conceptual Metamodel and inclusion of the Vocabulary Implementation Metamodel.

5.3 Dependencies between CCL Metamodel Packages

From a more precise perspective, the CCL metamodel has been organised in the packages shown in Figure 6. The dashed arrows indicate dependency of the source package regarding the target package. As a metamodel implementation matter, these relationships have been defined by avoiding circular dependencies. This means that the top-level packages are fully independent from other packages, and the lower level packages have more or less dependency from the other packages. In the following sections, we describe each of these packages.



Figure 6. CCL Metamodel Packages



5.4 Reference Assurance Framework (Refframework) Metamodel

5.4.1 Scope and Purpose

The Reference Assurance Framework Metamodel captures the high-level concepts and relationships required to model a Reference Assurance Framework a framework against which the safety aspects of a given system are developed and assessed. Note that in [2], the concept of a Reference Assurance Framework was referred to as a “Safety Standard”: this concept has been refined in the present document, to reflect the fact that a given project does not necessarily develop directly to a safety standard (see discussion in Section 3.3 above). The Reference Assurance Framework concept encompasses, for example, company standards and best practice documentations (e.g. the Alstom, Thales or Fiat processes to develop safety-critical systems), as well as documents which have the de facto status of standards (e.g., IEC 61508, ISO 26262, DO-178C, EN 50126), but are not – legally – such as, for example, the Aerospace Recommended Practice (ARP) documents (e.g. ARP 4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems) [8].

5.4.2 Model Definition

The class diagram for the Reference Assurance Framework Metamodel is shown in Figures 7 and 8 below. In the following subsections, we define the model elements.

5.4.2.1 RefFramework

This class corresponds to a framework to which the lifecycle of a critical system might have to show compliance (for example, a framework based on IEC61508). Superclass

DescribableElement Attributes

scope: String The scope of the reference framework

rev: String The revision (version) of the reference framework

purpose: String The purpose of the reference framework

publisher: String The publisher of the reference framework

issued: Date The issue date of the reference framework

Relationships

ownedRequirement: RefRequirement [0..*] The (compliance) requirements defined in a reference assurance framework.

ownedActivities: RefActivity [0..*] The reference activities defined in a reference assurance framework.

ownedRole: RefRole [0..*] The roles defined in a reference assurance framework.

ownedArtefact: RefArtefact [0..*] The reference artefacts defined in a reference assurance framework.

ownedTechnique: RefTechnique [0..*] The references techniques defined in a reference assurance framework.



ownedCriticlevel: RefCriticalityLevel [0..*] The criticality levels defined in a reference assurance framework.

ownedApplicLevel: RefApplicabilityLevel [0..*] The applicability levels defined in a reference assurance framework.

Semantics A Reference Assurance Framework is the main container to model concepts against which the safety and system engineering aspects of a given system are developed and assessed, for example, safety standards such as IEC 61508, ISO 26262, DO-178C, EN 50126, company standards and best practice documentation (e.g., the Alstom, Thales or Fiat process to develop safety-critical systems), as well as documents which have the de facto status of standards, such as, for example, the Aerospace Recommended Practice (ARP) documents (e.g. ARP 4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems) [8].

5.4.2.2 RefActivity

This class corresponds to the units of behaviour that a reference assurance framework defines for the system lifecycle and that must be executed to demonstrate compliance [9]. Superclass

DescribableElement

RefAssurableElement Attributes

objective: String The objective of the reference activity

scope: String The scope of the reference activity

Relationships

ownedRequirement: RefRequirement [0..*] The requirements that must be fulfilled after (including during) the execution of a reference activity.

role: RefRole [0..*] The roles responsible for the realisation of a reference activity.

requiredArtefact: RefArtefact [0..*] The reference artefacts necessary for the execution a reference activity. These reference artefacts correspond to the input of the reference activity.

producedArtefact: RefArtefact [0..*] The reference artefacts generated or changed in a reference activity. These reference artefacts correspond to the output of the reference activity.

ApplicableTechnique: RefTechnique [0..*] The reference techniques used for the execution of a reference activity.

subActivity: RefActivity [0..*] The more fine-grained reference activity which is part of the reference activity.

precedingActivity: RefActivity [0..*] The preceding reference activity that must be executed before the reference activity.

applicability: RefApplicability [0..*] The reference applicability specification of a reference activity.

ownedRel: RefActivityRel [0..*] The activity relationship owned by the reference activity.

Semantics A Reference Activity is the first-class modeling entity of process specifications. It defines a phase, activity, tasks, or action, depending on the activity granularity level, defined in a standard or company process. It



also relates a number of concepts such as the artefact required and produced, roles involved in activities, techniques used and levels of applicability according to criticality levels.

Graphical Notation

Preceding Activity (Activity2 precedes Activity1):

Figure 7. Reference Assurance Framework Metamodel (Part 1: Core Model Elements)



Figure 8. Reference Assurance Framework Metamodel (Part 2: Inheritance Relationships)

5.4.2.3 RefActivityRel

This class corresponds to the existence of a relationship between two reference activities. Attributes

type: ActivityRelKind The type of relationship between two reference activities.

Relationships

source: RefActivity [1] The reference activity that corresponds to the source of a reference activity relationship.

Target: RefActivity [1] The reference activity that corresponds to the target of a reference activity relationship.

Semantics A Reference Activity Relationship models different kinds of relationships between two reference activities. The semantics of the relationships are defined by the ActivityRelKind enumeration.

5.4.2.4 RefRole

This class corresponds to the types of agents [9] that execute a reference activity. Superclass

DescribableElement

RefAssurableElement Semantics A Reference Role models any agent involved in the execution of a reference activity. Graphical Notation

5.4.2.5 RefArtefact

This class corresponds to the types of units of data that a reference assurance framework defines and that must be created and maintained during system lifecycle to demonstrate compliance. Reference artefacts are materialised in assurance projects by means of (concrete) artefacts [10]. This means that these artefacts have the same or a similar structure (syntax) and/or purpose (semantics) [11]. Please note that an artefact is not necessarily to be interpreted as a document. An artefact should be an atomic and coherent piece of information. Documents can therefore be conceived as being “practical containers” for many artefacts, which can be read sequentially (but need not necessarily be). An electronic project repository, for example, might allow for navigation and search over artefacts without the need for traditional (i.e. printed) documents. We refer to this as a “model-centric” approach. Superclass

DescribableElement


reference: String The description of any reference to a given reference artefact.

Relationships

ownedRel: RefArtefactRel [0..*] The reference artefact relationships owned by a reference artefact.

property: Property [0..*] The reference artefact properties corresponding to the actual artefact can have property values.

constrainingRequirement: RefRequirement [0..*] The requirements at which a reference artefact is targeted.

applicableTechnique: RefTechnique [0..*]



The techniques used to create a reference artefact. Semantics The Reference Artefact models units of data that a reference assurance framework defines and that must be created and maintained during system lifecycle to demonstrate compliance. Reference artefacts are materialised in assurance projects by means of (concrete) artefacts. This means that these artefacts have the same or a similar structure (syntax) and/or purpose (semantics). Graphical Notation

Produced Artefact:

Required Artefact:

5.4.2.6 RefArtefactRel

This class corresponds to the existence of a relationship between two reference artefacts [10]. A reference artefact relationship is materialised by relating two artefacts of an assurance project (i.e., by means of an artefact relationship), and characterizes those artefact relationships that have the same or similar structure (syntax) and/or purpose (semantics) [[11]]. Superclass


maxMultiplicitySource: Int The maximum number of times that an artefact that materialises the source of a reference artefact relationship can be used as the source of artefact relationships that materialise the reference artefact relationship.

minMutiplicitySource: Int The minimum number of times that an artefact that materialises the source of a reference artefact relationship must be used as the source of artefact relationships that materialise the reference artefact relationship.

maxMultiplicityTarget: Int The maximum number of times that an artefact that materialises the target of a reference artefact relationship can be used as the target of artefact relationships that materialise the reference artefact relationship.

minMultiplicityTarget: Int The minimum number of times that an artefact that materialises the target of a reference artefact relationship must be used as the target of artefact relationships that materialise the reference artefact relationship.

modificationEffect: ChangeEffectKind The effect that the modification (or deletion) of an artefact that materialises the target of a reference artefact relationship has on the artefact that materialises the source of the reference artefact relationship.

revocationEffect: ChangeEffectKind



The effect that the revocation of an artefact that materialises the target of a reference artefact relationship has on the artefact that materialises the source of the reference artefact relationship.

Relationships

source: RefArtefact [1] The reference artefact that corresponds to the source of a reference artefact relationship.

target: RefArtefact [1] The reference artefact that corresponds to the target of a reference artefact relationship.

Semantics The Reference Artefact Relationship models a relationship between two reference artefacts. A reference artefact relationship is materialised by relating two artefacts of an assurance project (i.e., by means of an artefact relationship), and characterizes those artefact relationships that have the same or similar structure (syntax) and/or purpose (semantics)

5.4.2.7 RefTechnique

This class corresponds to specific ways to create a reference artefact. Superclass

DescribableElement


aim: String The purpose of a reference technique.

Relationships

none Semantics The Reference Technique models a method used during the system development lifecycle to create an artefact.

5.4.2.8 RefRequirement

This class corresponds to the criteria (e.g., objectives) that a reference assurance framework defines (or prescribes) to comply with it. Superclass

DescribableElement


reference: String The reference of the requirement in the reference framework documents.

assumptions: String The statements considered as preconditions to meet the reference requirement.

rationale: String Any rationale to justify the need to meet the reference requirement.

image: String A placeholder for an image capturing the reference requirement description from the reference framework documents.

annotations: String Any complementary annotation clarifying the means to meet the requirement.

Relationships

subRequirement: RefRequirement [0..*] A more fine-grained reference requirement of which this reference requirement is composed.

ownedRel: RefRequirementRel [0..*] The reference requirement relationships owned by a reference requirement.



applicability: RefApplicability [0..*] The reference applicability tuple (composed of applicability level, criticality level and assurable element – such as a technique, a requirement or an activity) of which a reference requirement is composed.

Semantics The Reference Requirement models the criteria (e.g., objectives) that a reference assurance framework defines (or prescribes) to comply with it.

5.4.2.9 RefRequirementRel

This class corresponds to the existence of a relationship between two requirements. Attributes

type: RequirementRelKind The kind of a requirements relationship.

Relationships

source: RefRequirement [1] The reference requirement that corresponds to the source of a reference requirement relationship.

Target: RefRequirement [1] The reference requirement that corresponds to the target of a reference requirement relationship.

Semantics A Reference Requirement Relationship models different kinds of relationships between two reference requirements. The semantics of the relationships are defined by the RequirementRelKind enumeration.

5.4.2.10 RefCriticalityLevel

This class corresponds to the categories of criticality that a reference assurance framework defines and that indicate the relative level of risk reduction being provided (e.g., SIL 1, 2, 3, and 4 for IEC61508). Superclass

DescribableElement Semantics This Reference Criticality Level models the categories of criticality that a reference assurance framework defines and that indicate the relative level of risk reduction that needs to be provided (e.g., SIL 1, 2, 3, and 4 for IEC61508).

5.4.2.11 RefApplicabilityLevel

This class corresponds to the categories of applicability that a reference assurance framework defines (e.g., a given technique can be mandated in EN50128). Superclass

DescribableElement Semantics This Reference Applicability Level models the categories of applicability that a reference assurance framework defines (e.g., a given technique can be mandated in EN50128).

5.4.2.12 RefIndependencyLevel

This class corresponds to the kind of categories of applicability related to the independency required to perform an activity or to achieve and compliance objective that a reference assurance framework defines (e.g., the level of independence of the person performing a verification activity mandated in DO-178C). Superclass

RefApplicabilitylevel Semantics This Reference Independency Level models the kind of categories of applicability related to the independency required to perform an activity or to achieve and compliance objective that a reference



assurance framework defines (e.g., the level of independence of the person performing a verification activity mandated in DO-178C).

5.4.2.13 RefRecommendationLevel

This class corresponds to the kind of categories of applicability related to the level of recommendation of a given activity, artefact or compliance requirement that a reference assurance framework defines (e.g., the degree of recommendation to use the methods that ISO 26262 assigns to each ASIL within a conformity requirement). Superclass

RefApplicabilitylevel Semantics This Reference Recommendation Level models the kind of categories of applicability related to the level of recommendation of a given activity, artefact or compliance requirement that a reference assurance framework defines (e.g., the degree of recommendation to use the methods that ISO 26262 assigns to each ASIL within a conformity requirement).

5.4.2.14 RefControlCategory

This class corresponds to the kind of categories of applicability related to the data control category associated to the configuration management controls placed on the data. (e.g., the CC1 and CC2 control categories defined in DO-178C). Superclass

RefApplicabilitylevel Semantics This Reference Control Category models the kind of categories of applicability related to the data control category associated to the configuration management controls placed on the data. (e.g., the CC1 and CC2 control categories defined in DO-178C).

5.4.2.15 RefCriticalityApplicability

This class corresponds to the assignation, in a reference assurance framework, of an applicability level for a given criticality level to a reference applicability. Attributes

comment: String The comments that are embedded in applicability tables, which can imply constraints on the applicability specification.

Relationships

applicLevel: RefApplicabilityLevel [1] The applicability levels of the criticality applicability.

criticLevel: RefCriticalityLevel [1] The criticality level of the criticality applicability.

Semantics The Reference Criticality Applicability models the pair of an applicability level for a given criticality level to a RefApplicability.

5.4.2.16 RefApplicability

This class corresponds to the reference applicability tuple (composed of applicability level, criticality level and assurable element – such as a technique, a requirement or an activity) a reference requirement is composed of. Superclass

NamedElement Attributes



comments: String The comments that are embedded in applicability tables, which can imply constraints on the applicability specification.

Relationships

applicTarget: BaseAssurableElement [0..1] The assurable element – such as a technique, a requirement or an activity, to which a reference applicability applies to.

applicCritic: RefCriticalityApplicability [0..*] The pair of criticality and applicability levels applied to the targeted assurable element.

Semantics This Reference Applicability models the reference applicability tuple (composed of applicability level, criticality level and assurable element – such as a technique, a requirement or an activity) of which a reference requirement is composed.

5.4.2.17 RefApplicabilityRel

This class corresponds to the existence of a relationship between two reference applicability specifications. Attributes

type: ApplicabilityKind The kind of an applicability relationship.

Relationships

source: RefApplicability [1] The reference applicability that corresponds to the source of a reference applicability relationship.

Target: RefApplicability [1] The reference applicability that corresponds to the target of a reference applicability relationship.

Semantics A Reference Applicability Relationship models different kinds of relationships between two reference applicability specifications. The semantics of the relationships are defined by the ApplicabilityKind enumeration.

5.4.2.18 RefAssurableElement (Abstract)

This class factorises various model elements used to specify assurance concepts, including reference activities, techniques, artefacts, roles, and requirements. Relationships

equivalence: RefEquivalenceMap [0..*] The equivalence map to which an assurable element is mapped.

Semantics The Reference Assurable Element model elements used to specify assurance concepts, including reference activities, techniques, artefacts, and requirements.

5.4.2.19 RefEquivalenceMap

This class specifies a single mapping between two or more assurable elements. Relationships

target: BaseAssurableElement [0..*] The reference assurable element which a map is targeting.

Semantics The Reference Equivalence Map models a single mapping between two or more assurable elements.

ActivityRelKind (enumeration)

See definition in General Metamodel.



ChangeEffectKind (enumeration)


RequirementRelKind (enumeration)


ApplicabilityKind (enumeration)

See definition in General Metamodel. Property See definition in Property Metamodel. EquivalenceMap See definition in Mapping Metamodel. DescribableElement See definition in General Metamodel. NamedElement See definition in General Metamodel.

5.5 Assurance Project (AssuranceProject) Metamodel


The Assurance Project Metamodel defines the assets produced during the development, assessment and justification of a safety-critical system, including those associated with justifying the safety of the system

and – in the regulated domains – seeking regulatory approval for its entry into service.1 The Metamodel describes both tangible assets – artefacts such as documents, plans and so forth -, and intangible ones, such as personnel, techniques and the like. The Assurance Project Metamodel links directly to the Artefact, Process and Argumentation Metamodels.


The class diagram for the Assurance Project Metamodel is presented in Figures 9 and 10 below. The model elements are described in the following subsections.

5.5.2.1 AssuranceProject

This class corresponds to an individual or collaborative enterprise that aims to manage the lifecycle of a critical system/component and to assure its safety or other properties of the system/component [12]. Superclass

1 Of the OPENCOSS target domains, avionics and railway are regulated (i.e. there is a need for formal approval by a certification body before a product can enter service). There is no formal regulatory procedure in the automotive domain, and it is therefore inappropriate to refer to “certification” in that domain. Automotive manufacturers are, however, obliged to demonstrate compliance to various safety standards, so the industry can most properly be described as self-regulatory.




createdBy: String The name of the person in charge of creating the Assurance Project.

responsible: String The name of the person in charge of managing the life cycle of the Assurance Project.

date: Date The date of creation of the Assurance Project.

version: String The current version of the Assurance Project.

Relationships

permissionConf: PermissionConfig [0..*] A reference to PermissionConfig, which is the set of parameters that define the access and permission configuration for the Assurance Project. Only one of the PermissionConfig must be “active” for the Assurance Project.

baselineConfig: BaselineConfig [0..*] A reference to baselineConfig, which is what is planned to do or to comply with, in the Assurance Project. Only one of the BaselineConfig must be “active” for the Assurance Project.

assetsPackage: AssetsPackage [0..*] A reference to AssetsPackage, which is what has been done in a specific assurance project (project-specific Artefacts models, and Argumentation models, and Process models). Only one of the AssetsPackage must be “active” for the Assurance Project.

Semantics An Assurance Project models the whole set of elements of a safety assurance project for a system or component, its lifecycle, and any project baseline information that may be shared by the different functional modules.

5.5.2.2 PermissionConfig

This class corresponds to an individual configuration to support profile creation to enable restricted access to OPENCOSS functionality and data. Superclass


isActive: Boolean This flag indicates if the current PermissionConfig is active for its use during the lifecycle of an Assurance Project.

Relationships None.

Semantics A Permission Configuration models the whole set of parameters to configure the users permission for managing the access to OPENCOSS data. This has not implemented yet. The CCL metamodel will evolve in the future to consider the concrete parameters for configuration.

5.5.2.3 BaselineConfig

This class corresponds to an individual configuration of what is planned to do or comply with, in a specific assurance project. Superclass


isActive: Boolean



This flag indicates if the current BaselineConfig is active for its use during the lifecycle of an Assurance Project.

Relationships

refFramework: BaseFramework [0..*] The set of BaseFrameworks that are part of the BaselineConfig. E.g., a BaseFramework can correspond to the tailoring of DO-178C (Standard of Sw for Avionics) and another BaseFramework to the tailoring of DO-254 (Standard of Hw for Avionics)

complianceMapGroup: MapGroup [0..1] The MapGroup used to refer to a set of Compliance Maps which are valid for the current BaselineConfig.

Semantics A Baseline Configuration models what is planned to do or comply with, in a specific assurance project. A Baseline Configuration has a set of Baseline Models. Each Baseline Model results from importing (copying) a Reference Framework model and adding information about its Selection in the current project (it answers to the question: does a given Reference Framework model element apply to the current Assurance Project?).

5.5.2.4 AssetsPackage

This class corresponds to an individual configuration of what has been done in a specific assurance project. Superclass


isActive: Boolean This flag indicates if the current AssetsPackage is active for its use during the lifecycle of an Assurance Project.

Relationships

processModel: ProcessModel [0..*] The set of ProcessModels which are part of the current AssetsPackage

artefactsModel: ArtefactModel [0..*] The set of ArtefactModels which are part of the current AssetsPackage

argumentationModel: Case [0..*]

The set of Cases (argumentation models) which are part of the current AssetsPackage Semantics An Assets Package models what has been done in a specific assurance project. This is a pointer to project-specific Artefacts models, Argumentation models, and Process models. The mapping of these three models with Baseline Models is modelled using the concept of Compliance Map. BaseFramework See definition in Base Assurance Framework Metamodel. MapGroup See definition in Mapping Metamodel. ProcessModel See definition in Process Metamodel. ArtefactModel See definition in Artefact Metamodel. Case See definition in Argumentation Metamodel.



DescribableElement See definition in General Metamodel. NamedElement See definition in General Metamodel.

Figure 9. Assurance Project Metamodel (Part 1: Core Model Elements)

Figure 10. Assurance Project Metamodel (Part 2: Inheritance Relationships)

5.6 Baseline Metamodel


The Baseline Metamodel captures what is planned to be done or to be complied with, in a specific assurance project. Each Baseline Model results from importing (copying) a Reference Framework model and adding information about its Selection in the current project (it provides answers to the question: does a given Reference Framework model element apply to the current Assurance Project?).


The class diagram for the Baseline Metamodel is shown in Figures 11 and 12 below. In the following subsections, we define the model elements.

5.6.2.1 BaseFramework

This class corresponds to a framework to which the lifecycle of a critical system might have to show compliance (for example, a framework based on IEC61508). Superclass


scope: String The scope of the base framework

rev: String The revision (version) of the base framework

purpose: String The purpose of the base framework

publisher: String The publisher of the base framework

issued: Date The issue date of the base framework

Relationships

ownedRequirement: BaseRequirement [0..*] The (compliance) requirements defined in a baseline framework.

ownedActivities: BaseActivity [0..*] The reference activities defined in a baseline framework.

ownedRole: BaseRole [0..*] The roles defined in a baseline framework.

ownedArtefact: BaseArtefact [0..*] The reference artefacts defined in a baseline framework.

ownedTechnique: BaseTechnique [0..*] The references techniques defined in a baseline framework.

ownedCriticlevel: BaseCriticalityLevel [0..*] The criticality levels defined in a baseline framework.

ownedApplicLevel: BaseApplicabilityLevel [0..*] The applicability levels defined in a baseline framework.

refFramework: RefFramework [0..1] The RefFramework used to create the BaseFramework.

Semantics



A Baseline Framework is the main container to model concepts against which the safety and system engineering aspects of a given system are developed and assessed, for example, safety standards such as IEC 61508, ISO 26262, DO-178C, EN 50126, company standards and best practice documentation (e.g., the Alstom, Thales or Fiat process to develop safety-critical systems), as well as documents which have the de facto status of standards, such as, for example, the Aerospace Recommended Practice (ARP) documents (e.g. ARP 4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems) [8].

5.6.2.2 BaseActivity

This class corresponds to the units of behaviour that a baseline framework defines for the system lifecycle and that must be executed to demonstrate compliance [9]. Superclass

DescribableElement

BaseAssurableElement

BaselineElement Attributes

objective: String The objective of the base activity

scope: String The scope of the base activity

Relationships

ownedRequirement: BaseRequirement [0..*] The requirements that must be fulfilled after (including during) the execution of a base activity.

role: BaseRole [0..*] The roles responsible for the realisation of a base activity.

requiredArtefact: BaseArtefact [0..*] The base artefacts necessary for the execution a base activity. These base artefacts correspond to the input of the base activity.

producedArtefact: BaseArtefact [0..*] The base artefacts generated or changed in a base activity. These base artefacts correspond to the output of the base activity.

ApplicableTechnique: BaseTechnique [0..*] The base techniques used for the execution of a base activity.

subActivity: BaseActivity [0..*] The more fine-grained base activity which is part of the base activity.

precedingActivity: BaseActivity [0..*] The preceding base activity that must be executed before the base activity.

applicability: BaseApplicability [0..*] The base applicability specification of a base activity.

ownedRel: BaseActivityRel [0..*] The activity relationship owned by the base activity.

Semantics A Base Activity is the first-class modeling entity of process specifications. It defines a phase, activity, tasks, or action, depending on the activity granularity level, defined in a standard or company process. It also relates a number of concepts such as the artefact required and produced, roles involved in activities, techniques used and levels of applicability according to criticality levels.

Graphical Notation



Preceding Activity (Activity2 precedes Activity1):

Figure 11. Baseline Metamodel (Part 1: Core Model Elements)



Figure 12. Baseline Metamodel (Part 2: Inheritance Relationships)

5.6.2.3 BaseActivityRel

This class corresponds to the existence of a relationship between two base activities. Attributes

type: ActivityRelKind The type of relationship between two base activities.

Relationships

source: BaseActivity [1] The base activity that corresponds to the source of a base activity relationship.

Target: BaseActivity [1] The base activity that corresponds to the target of a base activity relationship.

Semantics A Base Activity Relationship models different kinds of relationships between two base activities. The semantics of the relationships are defined by the ActivityRelKind enumeration.

5.6.2.4 RefRole

This class corresponds to the types of agents [9] that execute a base activity. Superclass

DescribableElement


BaselineElement Semantics A Base Role models any agent involved in the execution of a base activity. Graphical Notation

5.6.2.5 BaseArtefact

This class corresponds to the types of units of data that a baseline framework defines and that must be created and maintained during system lifecycle to demonstrate compliance. Base artefacts are materialised in assurance projects by means of (concrete) artefacts [10]. This means that these artefacts have the same or a similar structure (syntax) and/or purpose (semantics) [11]. Please note that an artefact is not necessarily to be interpreted as a document. An artefact should be an atomic and coherent piece of information. Documents can therefore be conceived as being “practical containers” for many artefacts, which can be read sequentially (but need not necessarily be). An electronic project repository, for example, might allow for navigation and search over artefacts without the need for traditional (i.e. printed) documents. We refer to this as a “model-centric” approach. Superclass

DescribableElement



reference: String The description of any reference to a given base artefact.

Relationships

ownedRel: BaseArtefactRel [0..*] The base artefact relationships owned by a base artefact.

property: Property [0..*] The base artefact properties corresponding to the actual artefact can have property values.



constrainingRequirement: BaseRequirement [0..*] The requirements at which a base artefact is targeted.

applicableTechnique: BaseTechnique [0..*] The techniques used to create a base artefact.

Semantics The Base Artefact models units of data that a reference assurance framework defines and that must be created and maintained during system lifecycle to demonstrate compliance. Base artefacts are materialised in assurance projects by means of (concrete) artefacts. This means that these artefacts have the same or a similar structure (syntax) and/or purpose (semantics). Graphical Notation

Produced Artefact:

Required Artefact:

5.6.2.6 BaseArtefactRel

This class corresponds to the existence of a relationship between two base artefacts [10]. A base artefact relationship is materialised by relating two artefacts of an assurance project (i.e., by means of an artefact relationship), and characterizes those artefact relationships that have the same or similar structure (syntax) and/or purpose (semantics) [[11]]. Superclass


maxMultiplicitySource: Int The maximum number of times that an artefact that materialises the source of a base artefact relationship can be used as the source of artefact relationships that materialise the base artefact relationship.

minMutiplicitySource: Int The minimum number of times that an artefact that materialises the source of a base artefact relationship must be used as the source of artefact relationships that materialise the base artefact relationship.

maxMultiplicityTarget: Int The maximum number of times that an artefact that materialises the target of a base artefact relationship can be used as the target of artefact relationships that materialise the base artefact relationship.

minMultiplicityTarget: Int The minimum number of times that an artefact that materialises the target of a base artefact relationship must be used as the target of artefact relationships that materialise the base artefact relationship.

modificationEffect: ChangeEffectKind The effect that the modification (or deletion) of an artefact that materialises the target of a base artefact relationship has on the artefact that materialises the source of the base artefact relationship.



revocationEffect: ChangeEffectKind The effect that the revocation of an artefact that materialises the target of a base artefact relationship has on the artefact that materialises the source of the reference base relationship.

Relationships

source: BaseArtefact [1] The base artefact that corresponds to the source of a base artefact relationship.

target: BaseArtefact [1] The base artefact that corresponds to the target of a base artefact relationship.

Semantics The Base Artefact Relationship models a relationship between two base artefacts. A base artefact relationship is materialised by relating two artefacts of an assurance project (i.e., by means of an artefact relationship), and characterizes those artefact relationships that have the same or similar structure (syntax) and/or purpose (semantics)

5.6.2.7 BaseTechnique

This class corresponds to specific ways to create a base artefact. Superclass

DescribableElement



aim: String The purpose of a base technique.

Relationships

none Semantics The Base Technique models a method used during the system development lifecycle to create an artefact.

5.6.2.8 BaseRequirement

This class corresponds to the criteria (e.g., objectives) that a baseline framework defines (or prescribes) to comply with it. Superclass

DescribableElement



reference: String The reference of the requirement in the baseline framework documents.

assumptions: String The statements considered as preconditions to meet the base requirement.

rationale: String Any rationale to justify the need to meet the base requirement.

image: String A placeholder for an image capturing the base requirement description from the baseline framework documents.

annotations: String Any complementary annotation clarifying the means to meet the requirement.

Relationships

subRequirement: BaseRequirement [0..*] A more fine-grained base requirement of which this base requirement is composed.



ownedRel: BaseRequirementRel [0..*] The baseline requirement relationships owned by a baseline requirement.

applicability: BaseApplicability [0..*] The base applicability tuple (composed of applicability level, criticality level and assurable element – such as a technique, a requirement or an activity) of which a base requirement is composed.

Semantics The Base Requirement models the criteria (e.g., objectives) that a baseline framework defines (or prescribes) to comply with it.

5.6.2.9 BaseRequirementRel

This class corresponds to the existence of a relationship between two requirements. Attributes

type: RequirementRelKind The kind of a requirements relationship.

Relationships

source: BaseRequirement [1] The base requirement that corresponds to the source of a base requirement relationship.

Target: BaseRequirement [1] The base requirement that corresponds to the target of a base requirement relationship.

Semantics A Base Requirement Relationship models different kinds of relationships between two base requirements. The semantics of the relationships are defined by the RequirementRelKind enumeration.

5.6.2.10 BaseCriticalityLevel

This class corresponds to the categories of criticality that a baseline framework defines and that indicate the relative level of risk reduction being provided (e.g., SIL 1, 2, 3, and 4 for IEC61508). Superclass

DescribableElement Semantics This Base Criticality Level models the categories of criticality that a baseline framework defines and that indicate the relative level of risk reduction that needs to be provided (e.g., SIL 1, 2, 3, and 4 for IEC61508).

5.6.2.11 BaseApplicabilityLevel

This class corresponds to the categories of applicability that a baseline framework defines (e.g., a given technique can be mandated in EN50128). Superclass

DescribableElement Semantics This Base Applicability Level models the categories of applicability that a baseline framework defines (e.g., a given technique can be mandated in EN50128).

5.6.2.12 BaseIndependencyLevel

This class corresponds to the kind of categories of applicability related to the independency required to perform an activity or to achieve and compliance objective that a baseline framework defines (e.g., the level of independence of the person performing a verification activity mandated in DO-178C). Superclass

BaseApplicabilitylevel Semantics



This Base Independency Level models the kind of categories of applicability related to the independency required to perform an activity or to achieve and compliance objective that a baseline framework defines (e.g., the level of independence of the person performing a verification activity mandated in DO-178C).

5.6.2.13 BaseRecommendationLevel

This class corresponds to the kind of categories of applicability related to the level of recommendation of a given activity, artefact or compliance requirement that a baseline framework defines (e.g., the degree of recommendation to use the methods that ISO 26262 assigns to each ASIL within a conformity requirement). Superclass

BaseApplicabilitylevel Semantics This Base Recommendation Level models the kind of categories of applicability related to the level of recommendation of a given activity, artefact or compliance requirement that a baseline framework defines (e.g., the degree of recommendation to use the methods that ISO 26262 assigns to each ASIL within a conformity requirement).

5.6.2.14 BaseControlCategory

This class corresponds to the kind of categories of applicability related to the data control category associated to the configuration management controls placed on the data. (e.g., the CC1 and CC2 control categories defined in DO-178C). Superclass

BaseApplicabilitylevel Semantics This Base Control Category models the kind of categories of applicability related to the data control category associated to the configuration management controls placed on the data. (e.g., the CC1 and CC2 control categories defined in DO-178C).

5.6.2.15 BaseCriticalityApplicability

This class corresponds to the assignation, in a baseline framework, of an applicability level for a given criticality level to a base applicability. Attributes

comment: String The comments that are embedded in applicability tables, which can imply constraints on the applicability specification.

Relationships

applicLevel: BaseApplicabilityLevel [1] The applicability levels of the criticality applicability.

criticLevel: BaseCriticalityLevel [1] The criticality level of the criticality applicability.

Semantics The Base Criticality Applicability models the pair of an applicability level for a given criticality level to a Base Applicability.

5.6.2.16 BaseApplicability

This class corresponds to the base applicability tuple (composed of applicability level, criticality level and assurable element – such as a technique, a requirement or an activity) a base requirement is composed of. Superclass




comments: String The comments that are embedded in applicability tables, which can imply constraints on the applicability specification.

Relationships

applicTarget: BaseAssurableElement [0..1] The base assurable element – such as a technique, a requirement or an activity, to which a base applicability applies to.

applicCritic: BaseCriticalityApplicability [0..*] The pair of criticality and applicability levels applied to the targeted base assurable element.

Semantics This Base Applicability models the reference applicability tuple (composed of applicability level, criticality level and base assurable element – such as a technique, a requirement or an activity) of which a base requirement is composed.

5.6.2.17 BaseApplicabilityRel

This class corresponds to the existence of a relationship between two reference applicability specifications. Attributes

type: ApplicabilityKind The kind of an applicability relationship.

Relationships

source: BaseApplicability [1] The base applicability that corresponds to the source of a base applicability relationship.

Target: BaseApplicability [1] The base applicability that corresponds to the target of a base applicability relationship.

Semantics A Base Applicability Relationship models different kinds of relationships between two base applicability specifications. The semantics of the relationships are defined by the ApplicabilityKind enumeration.

5.6.2.18 BaselineElement (abstract)

This class factorises various model elements used to specify baseline flags to indicate if the model element has been selected to be active in the concrete assurance project, including base activities, techniques, artefacts, roles, and requirements. Attributes

isSelected: Boolean The flag to indicate if the model element has been selected to be active in the associated assurance project.

selectionJustification: String A string to specify why a model element has been or not selected to be active in the associated assurance project.

Semantics A Baseline Element models any model element that can have a baseline flags to indicate if the model element has been selected to be active in the concrete assurance project, including base activities, techniques, artefacts, roles, and requirements.

5.6.2.19 BaseAssurableElement (Abstract)

This class factorises various model elements used to specify assurance concepts, including base activities, techniques, artefacts, roles, and requirements. Relationships

equivalence: BaseEquivalenceMap [0..*] The equivalence map to which an assurable element is mapped.



refAssurableElement: RefAssurableElement [0..1] The reference assurable element from which a base assurable element has been created.

Semantics The Base Assurable Element model elements used to specify assurance concepts, including base activities, techniques, artefacts, and requirements.

5.6.2.20 BaseEquivalenceMap

This class specifies a single equivalence mapping between two or more assurable elements. Superclass

EquivalenceMap Relationships

target: RefAssurableElement [0..*] The reference assurable element which a map is targeting.

Semantics The Base Equivalence Map models a single mapping between two or more assurable elements.

5.6.2.21 BaseComplianceMap

This class specifies a single compliance mapping between an assurable element and an assurance asset. Superclass

ComplianceMap Relationships

target: AssuranceAsset [0..*] The assurance asset element which a map is targeting.

Semantics The Base Compliance Map models a single compliance mapping between an assurable element and an assurance asset.

ActivityRelKind (enumeration)


ChangeEffectKind (enumeration)


RequirementRelKind (enumeration)


ApplicabilityKind (enumeration)


Property See definition in Property Metamodel. DescribableElement See definition in General Metamodel. NamedElement See definition in General Metamodel.



RefFramework See definition in Assurance Reference Framework Metamodel. RefAssurableElement See definition in Assurance Reference Framework Metamodel. AssuranceAsset See definition in Assurance Asset Metamodel. ComplianceMap See definition in Mapping Metamodel. EquivalenceMap See definition in Mapping Metamodel.



5.7 Assurance Asset (AssuranceAsset) Metamodel


The concept of an Assurance Asset (i.e. an assurance asset whose qualities and lifecycle can be recorded and analysed) is identified, to handle the tangible assurance assets defined in the Assurance Project Metamodel. The Assurance Asset Metamodel provides classes for the recording of lifecycle events associated with these assets, and for the record of rationale and judgements concerning them.


The class diagram for the Manageable Assurance Asset Metamodel is presented in the Figure below. We define the model elements in the following subsections.

5.7.2.1 AssuranceAssetsModel

This class corresponds to model of assurance assets which can be part of an assurance project. Superclass

DescribableElement Relationships

assuranceAsset: AssuranceAsset [0..*] The set of assurance assets that are part of the AssuranceAssetsModel

Semantics An Assurance Assets Model represents the root model element to create assurance assets.

5.7.2.2 AssuranceAsset (abstract)

This class corresponds to an assurance asset whose qualities and lifecycle can be recorded and analysed. Attributes

None Relationships

None Semantics An Assurance Asset models any asset from assurance projects whose qualities and lifecycle can be recorded and analysed (e.g., an artefact or an activity).

5.7.2.3 ManageableAssuranceAsset

This class corresponds to assurance assets that can be evaluated and whose lifecycle might have to be recorded. Superclass

AssuranceAsset Relationships

evaluation: AssuranceAssetEvaluation [0..*] The assurance asset evaluations that specify the outcome of evaluating a manageable assurance asset.

lifecycleEvent: AssuranceAssetEvent [0..*] The assurance asset events of which the lifecycle of a manageable assurance asset consists.

Semantics A Manageable Assurance Asset models any assurance assets that can be evaluated and whose lifecycle might have to be recorded.



5.7.2.4 AssuranceAssetEvaluation

This class corresponds to the specification of the result of making some judgement regarding a manageable assurance asset [12]. Superclass

ManageableAssuranceAsset


criterion: String The criterion used to evaluate a manageable assurance asset.

criterionDescription: String The description of the criterion used to evaluate a manageable assurance asset.

evaluationResult: String The result that is specified for the evaluation of a manageable assurance asset.

rationale: String Semantics An Assurance Asset Evaluation models any result of making some judgement regarding a manageable assurance asset.

5.7.2.5 AssuranceAssetEvent

This class corresponds to relevant happenings in the lifecycle of a manageable assurance asset [7]. This serves to maintain a history log for assurance assets. Superclass

AssuranceAsset


type: EventType The type of happening of an assurance asset event.

time: Date The time when an assurance asset event occurred.

Relationships

resultingEvaluation: AssuranceAssetEvaluation [0..1] The assurance asset evaluation in which an assurance asset event results.

Semantics An Assurance Asset Evaluation models any relevant happenings in the lifecycle of a manageable assurance asset [7]. This serves to maintain a history log for assurance assets.

5.7.2.6 EventKind (enumeration)

This enumeration corresponds to types of events that can occur in the lifecycle of a manageable assurance asset [7, 12]. Literals

Creation When a manageable assurance asset is brought into existence.

Modification When a change is made in some characteristic of a manageable assurance asset.

Evaluation When a manageable assurance asset is evaluated.

Approval When a manageable assurance asset is approved (as valid).



Revocation When a manageable assurance asset is revoked.

Figure 13. Assurance Asset Metamodel

5.8 Artefact Metamodel


Artefacts are individual units of data managed in an assurance project. The Artefact Metamodel defines the metadata about artefacts which should be captured as part of the OPENCOSS repository. In most – though not all – cases, the classes of metadata and relationships established in this Metamodel can be used to support reasoning about the use of artefacts as evidence of standards compliance or in support of an assurance argument. The Artefact Metamodel links directly to the Process and Argumentation Metamodels.


The class diagram for the Artefact Model is presented in the Figures below. We define the model elements in the following sections.

5.8.2.1 ArtefactModel

This class corresponds to a model of artefacts which are used in a given assurance project. Superclass


repoUrl: String The URL of a SVN repository where the Artefact resources are stored.

repoUser: String The User name of a SVN repository where the Artefact resources are stored.

repoPassword: String The Password of a SVN repository where the Artefact resources are stored.

repoLocalPath: String The local path of a local repository (alternative to SVN repository) where the Artefact resources are stored.

repoUsesLocal: Boolean A flag indicating if the Artefacts of the Artefact Model are stored in a local repository instead of a SVN repository.

Relationships

artefact: ArtefactDefinition [0..*] The set of Artefact Definitions that belongs to the Artefact Model.

Semantics An Artefact Model specifies the root element of a model representing a set of Artefacts. This concept embeds the access parameters to the repository of artefact resources (e.g., files). Currently, the parameters are related to two kind of artefact repositories: SVN or local hard disk repositories.

5.8.2.2 Artefact

This class corresponds to an artefact instance which is part of a given assurance project. An Artefact has concrete objects (called Resources), which correspond to tangible files or other information resources. Superclass

DescribableElement

ManegeableAssuranceAsset



Attributes

versionID: String The version number or ID of the Artefact.

date: Date The date of creation of the current Artefact version.

changes: String The list of changes describing any update regarding the previous Artefact version.

isLastVersion: Boolean A flag to indicate if the Artefact version is the last one.

isTemplate: Boolean A flag indicating if the Artefact is a Template to create the actual Artefact to be used in the assurance project.

isConfigurable: Boolean A flag indicating if the Artefact can be configured for specific usage contexts or situations.

Relationships

artefactPart: Artefact [0..*] The part of the Artefact which can represent document sections or any element composing the whole Artefact.

precedentVersion: Artefact [0..1] A pointer to the precedent version of an Artefact.

resource: Resource [0..*] The Resource elements which represente tangible objects of an artefact. For instance, the set of architectural model files of an Architecture Design document.

propertyValue: Value [0..*] A set of attributes and their values characterising an Artefact (e.g. Confidence properties).

ownedRel: ArtefactRel [0..*] The artefact relationships owned by an artefact.

Semantics An Artefact specifies the instance of artefacts characterised for a version and a set of resources modelling tangible artefact resources. Artefacts are subject to traceability for change management and to characterisation by means of property values. An Artefact can be composed of other artefacts or artefact parts.

5.8.2.3 Resource

This class corresponds to a model of a tangible object representing the artefact. Superclass

Describable Element Attributes

location: String The path or URL string specifying the location of the resource.

format: String The format of the resource (e.g., MS Word).

Semantics A Resource models tangible objects representing the Artefact, such as files or other electronic resources.

Figure 14. Artefact Metamodel (Part 1: Core Model Elements)

Figure 15. Artefact Metamodel (Part 2: Inheritance Relationship)

5.8.2.4 Value

This class corresponds to the value of an attribute of an artefact [10]. Attributes

name: String The name of the attribute value of an artefact for which a value is specified (for instance, average confidence).

value: String The value of an attribute of an artefact (i.e., the property).

Relationships

propertyReference: Property [0..1] The attribute of an artefact for which a value is specified. An attribute corresponds to objective, factual characteristic of an artefact [11, 10, 12]

Semantics A Value models the value of an artefact’s property. It can represent a maximum, minimum, average, etc. value. This information must be indicated in the name of the value.

5.8.2.5 ArtefactRel

This class corresponds to the existence of a relationship between two artefacts. This is the main mechanism for establishing bilateral traceability between artefacts, for example the relationship by which a test verifies a requirement and a requirement is verified by a test. Superclass

Describable Element Attributes

modificationEffect: ChangeEffectKind The effect that the modification of the target of an artefact relationship has on the source of the artefact relationship.

revocationEffect: ChangeEffect The effect that the revocation of the target of an artefact relationship has on the source of the artefact relationship.

Relationships

target: Artefact [1] The artefact that correspond to the target of an artefact relationship.

source: Artefact [1] The artefact that correspond to the source of an artefact relationship.

Semantics An Artefact Relationship models the relationship between two artefacts. This is the main mechanism for establishing bilateral traceability between artefacts, for example the relationship by which a test verifies a requirement and a requirement is verified by a test. Property See definition in Property Metamodel. ChangeEffectKind See definition in General Metamodel. DescribableElement See definition in General Metamodel. NamedElement See definition in General Metamodel.



5.9 Process Metamodel


The Process Metamodel captures the high-level concepts relating to the processes to be performed as part of a project and the artefacts which are produced by them. There are links to the Assurance Project Metamodel – and through that to the Argumentation metamodel – through the concept of an Artefact.


The class diagram for the Process Model is presented in the Figures below. We define the model elements in the following sections.

5.9.2.1 ProcessModel

This class corresponds to a model of process execution (snapshot of a development or assurance process at some point in its execution) which are used in a given product lifecycle. Superclass


ownedActivity: Activity [0..*] The set of Activities that belongs to the Process Model.

ownedParticipant: Participant [0..*] The set of Participants that belongs to the Process Model.

ownedTechnique: Technique [0..*] The set of Techniques that belongs to the Process Model.

Semantics A Process Model specifies the root element of a model representing a set of Process elements. The Process model corresponds to the actual execution of a process with data related to the results to the process execution.

5.9.2.2 Activity

This class corresponds to a unit of work performed in a product lifecycle [12, 9]. Superclass

DescribableElement

ManageableAssuranceAsset Attributes

startTime: Date The actual date/time when an activity started.

endTime: Date The actual date/time when an activity finished.

Relationships

requiredArtefact: Artefact [0..*] The artefacts necessary for the execution of an activity. These artefacts correspond to the input of the activity.

producedArtefact: Artefact [0..*] The artefacts generated or changed in an activity. These artefacts correspond to the output of the activity.



subActivity: Activity [0..*] The subactivities executed as part of an Activity which can represent activity instances or any action composing the whole Activity.

precedingActivity: Activity [0..*] A set of pointers to the Activities executed before this activity.

technique: Technique [0..*] The Technique used in the Activity to generate the produced Artefacts.

assetEvent: AssuranceAssetEvent [0..*] A set of Assurance Asset Events generated during the Activity execution.

ownedRel: ActivityRel [0..*] The activity relationships owned by an Activity.

participant: Participant [0..*] The set of participants being part of the Activity, either executing it or verifying it.

Semantics An Activity models a unit of work performed in a product lifecycle. An Activity is a specification of an activity already executed.

5.9.2.3 ActivityRel

This class corresponds to existence of a relationship between two activities. This is the main mechanism used to describe the interdependence of activities. Attributes

type: ActivityRelKind The type of relationship between two activities.

Relationships

target: Activity [1] The artefact that correspond to the target of an activity relationship.

source: Activity [1] The artefact that correspond to the source of an activity relationship.

Semantics An Activity Relationship models the relationship between two activities. This is the main mechanism for establishing bilateral traceability between activities.

5.9.2.4 Participant

This class corresponds to the parties involved in a product lifecycle [12]. Superclass

DescribableElement

AssuranceAsset Relationships

triggeredAssetEvent: AssuranceAssetEvent [0..*] The set of AssuranceAssetEvent generated by the Participant.

Semantics A Participant models the parties involved in a product lifecycle.

Figure 16. Process Metamodel (Part 1: Core Model Elements)

Figure 17. Process Metamodel (Part 2: Inheritance Relationships)



5.9.2.5 Person

This class corresponds to individuals that are involved in a product lifecycle [7]. Superclass

Participant Attributes

email: String The email address of a person.

Relationships

organization: Organization [0..*] The organization for which a person works.

Semantics A Person models individuals that are involved in a product lifecycle.

5.9.2.6 Tool

This class corresponds to the software tools used in a product lifecycle [7]. Superclass


version: String The version in use of a tool.

Semantics A Tool models software tools used in a product lifecycle.

5.9.2.7 Organization

This class corresponds to groups of people (companies, societies, associations, etc.) that are involved in a product lifecycle [12]. Superclass


address: String The place where an organization is located.

Relationships

subOrganization: Organization [0..*] The organization to which an organization belongs.

Semantics An Organization models groups of people (companies, societies, associations, etc.) that are involved in a product lifecycle. Artefact See definition in Artefact Metamodel ActivityRelKind See definition in General Metamodel. AssuranceAssetEvent See definition in AssuranceAsset Metamodel. ManageableAssuranceAsset See definition in AssuranceAsset Metamodel. DescribableElement



See definition in General Metamodel. NamedElement See definition in General Metamodel.

5.10 Vocabulary Metamodel


The Vocabulary Metamodel serves two principal purposes:

It provides for the expression of vocabulary to be used in modelling the argument claims and requirements in assurance assets defined in the models of assurance frameworks to be produced at Level 1 and 1b of the OPENCOSS framework and in the project assets to be defined at Level 2. This is achieved simply in the Vocabulary Metamodel presented here by the definition of a ‘Term’ concept, which captures the syntactic structure of terms and expressions used.

It is used to provide the structure for the CCL Thesaurus, in which core terms are defined and then mapped within and across standard- and project-specific models.

Please note that the metamodel for structured expressions is to be detailed in the final version of D5.6 and is not repeated here.


The conceptual class diagram for the Vocabulary Metamodel is presented in Figure 18, and is described in the following subsections. The implementation metamodel, which is a simplification of the conceptual metamodel, is described in Figure 19 below and the subsequent subsections.

Figure 18. Conceptual Vocabulary Metamodel

Figure 19. Vocabulary Implementation Metamodel

Concept Definitions Concept: Any unit of meaning which can be described or defined by a unique combination of

characteristics [22]. A Concept is represented/reified by the Term class and defined by the Definition class.

ConceptType: A container class which classifies things on the basis of their similarities. Each Concept belongs to one or more ConceptType. This is akin to the “ConceptType” relation in SBVR [22]. The ConceptTypes provide the basic structure of the Vocabulary in that Terms are arranged according to the ConceptTypes of the Concepts they represent.

ConceptRelation: A container for the types of relation between Concepts, which are used to model the

comparison between two Concepts in two different Vocabularies or to structure a Vocabulary in terms of the relationships between Concepts grouped within a ConceptType.

SemanticRelation: A container for the finer relationships between the meanings of Concepts within a

ConceptType, used to structure Terms of the same ConceptType in a Vocabulary. Four types of SemanticRelation are defined, as follows:

Hyponymy: A SemanticRelation by which the meaning of one Concept is more specific than that of

another Concept. In other words, a hyponym is used to designate a member of a general class. For example, ‘systematic fault’ and ‘intermittent fault’ are both hyponyms of ‘fault’. This might be referred to as a “type-of” relationship.

Hypernymy: A SemanticRelation by which the meaning of one Concept is more general than another

Concept. In other words, a hypernym designates the general category, of which its hyponyms are members or subdivisions. For example, ‘fault’ is a hypernym of ‘systematic fault’ and ‘intermittent fault’. This might be referred to as a “supertype-of” relationship.



Meronymy: A SemanticRelation by which one Concept is a constituent part of a general whole captured in another Concept. For example, “wheel” is a meronym of “automobile”. This might be referred to as a “part-of” relationship.

Holonymy: A SemanticRelation by which one Concept is an aggregation of other Concepts. For

example, “automobile” is a holonym of “wheel”, “chassis” etc. This might be referred to as a “contains” relationship. Term: The word or phrase which represents (or reifies) a Concept, typically a noun or noun-phrase.

Terms are thus the basic domain vocabulary, and are stored in the Vocabulary. A Term may be thought of as providing a label for a Concept, an unambiguous means by which the Concept can be referenced. Each Term has two Boolean attributes, PreferredLabel and AlternativeLabel. If the PreferredLabel attribute is set true, then the Term serves as the primary means by which a Concept is referred to and the principal key to represent that Concept in the Vocabulary. If the AlternativeLabel is set true, the term serves as an alternate means to reference the Concept, there being a PreferredLabel elsewhere in the Vocabulary. This mechanism allows for the unambiguous recording of exact synonym relationships between terms.

DefinedTerm and UndefinedTerm: We identify two subtypes of Term. DefinedTerms are those which are

included in the Vocabulary and which should be used with a single “reserved” meaning in project artefacts. Each DefinedTerm is represented in the Vocabulary by a VocabularyEntry. UndefinedTerms are those which have no “reserved” meaning in the project, and which are not therefore defined in the Vocabulary. Terms of all kinds can be used in Definitions.

Vocabulary: An aggregation of the VocabularyEntries which identify and define DefinedTerms for a

particular domain. The broad structure of the Vocabulary is provided by the ConceptTypes, and relationships between the Concepts represented by DefinedTerms are captured by SemanticRelations.

VocabularyEntry: Each DefinedTerm has a VocabularyEntry which encapsulates the information stored

concerning the DefinedTerm in the Vocabulary. Each VocabularyEntry comprises exactly one Lemma and exactly one Definition.

Lemma: A string representing the noun or noun-phrased used to designate a DefinedTerm. The Lemma

serves as the key to identify the DefinedTerm in the Vocabulary. Definition: A string which contains an unambiguous description of the Concept represented by a

DefinedTerm. The nouns and noun-phrases used in Definitions may be either DefinedTerms or UndefinedTerms.

Implementation Definitions Term The Term class defines the language primitives (words and expressions) which are used to construct the names and definitions of entities in the CCL Thesaurus and to populate the models to be developed at Levels 1, 1b and 2. Terms are the linguistic labels used to represent/reify instances of Concepts. Superclass


definition: string - prose definition of the concept, expressed in phrases.

notes: string – prose information relating to the concept, which are not directly incorporated in the definition

examples: string – prose descriptions of how the concept is used in an assurance project



synonyms: string – list of other Terms which have identical definitions and applications to the term being modelled

sourceOfDefinition: string – an indication of the source of the definition and the term (i.e. a particular standard or wordlist). It is important to give precise location information here, to mitigate the issues of inconsistent language within the source documents.

Relationships

isA [0..*] – a Term is an instance of a broader concept, captured by another Term (cf. Definition of hypernymy above)

hasA [0..*] – A Term represents a broader concept which comprises several other concepts represented by Terms (cf. Definition of holonymy above)

refersTo [0..*] – A Term refers to another Term (for example in the definition attribute) Category The CCL Thesaurus will be structured according to the grouping of Terms by the concepts they represent (and the relationships between these concepts). A term may belong to more than one Category, depending on its usage. See discussion of ConceptType above. Superclass

Describable Element Relationships

subCategories [0..*] – a category may optionally be further subdivided into subcategories. terms [0..*] - a Term may be a member of a Category

Vocab This class defines the set of Terms which is used in a given Assurance Project or Reference Assurance Framework. The vocabulary includes single words and phrases and their definitions (modelled in the CCL as an attribute of Term), and defines the scope of the conceptual categories by which it is structured. Superclass

Describable Element Relationships

categories [0..*] – a vocab may be structured according to Categories (see discussion of ConceptType above).

5.11 Mappings Metamodel


As discussed in Section 3.5 above, the Mappings Metamodel captures the nature of the vertical and horizontal mappings between the different levels of model in the OPENCOSS Framework and between the concepts and vocabulary used in these models and in the CCL Thesaurus. As such, it provides the “translation mechanism” (between models and between terminology) that is at the heart of the CCL technique. As noted in Section3.5, a rich variety of mapping types are required, to reflect the various degrees of inexactness in the relationships between the terms and concepts. Although the metamodels are presented in this report at a very generic, implementation-independent level, it is worth commenting here about the Platform-level tooling which the Mappings Metamodel is intended to support. The imprecise and inexact nature of most of the mappings means that a tool cannot provide for fully-automated translation of an assurance artefact between a source domain and a target domain. Nor can it provide automatic reconfiguration of the evidence to suit the new domain. Instead, the intention is to provide intelligent, expert guidance to the human safety engineer, to support him in the



decision as to whether or not reuse of the artefact in the target context is appropriate. The mappings will be used to provide targeted queries as to whether there is overlap in the requirements and intentions of both standards at the terminological level and the conceptual level, and where mismatches occur, as well as querying whether there are missing requirements in the reuse context which must be explicitly satisfied.


The class diagram for the Mappings Metamodel is presented in the Figure below. In the following subsections, we describe the model elements.

5.11.2.1 MapModel

This class corresponds to a model of mapping elements. Superclass


mapModel: Map [0..*] The set of Map elements of a MapModel.

mapGroupModel: MapGroup [0..*] The set of MapGroups that belong to the MapModel.

Semantics A Map Model specifies the root element of a model representing a set of mapping elements.

5.11.2.2 MapGroup

This class corresponds to a group of Map elements. Superclass

DescribableElement Semantics A Map Group specifies a group of Map elements.

5.11.2.3 Map

The Map class is the container class for the types of mapping relationship which need to be instantiated in the CCL models at Levels 1, 1b and 2. These relationships capture the similarities between elements which can be mapped to one another, and also capture the differences between them. Superclass


type: MapKind The nature of the mapping, in terms of coverage between the source and target elements.

Relationships

mapGroup: MapGroup [0..1] The MapGroup to which the Map belongs.

mapJustification: MapJustification [0..1] A Justification text describing to which extent and under which conditions two elements map.

Semantics The Map class is the container class for the types of mapping relationship which need to be instantiated in the CCL models at Levels 1, 1b and 2. These relationships capture the similarities between elements which can be mapped to one another, and also capture the differences between them. Generally, we anticipate that mappings will be to elements of the same type (i.e. a Claim will map to a Claim, a Requirement to a



Requirement and so on), but this assumption will be tested in practice. A given mappable element can serve either as a source or a target in the mapping, and plural relationships are permitted by the model. It is essential for the nature of the overlaps and gaps to be detailed, in order to facilitate the expert guidance on element reuse which the OPENCOSS Platform will seek to provide. The MapJustification attribute – which represents a note node on the mapping link – has been defined in order to provide for the recording of this detail.

5.11.2.4 EquivalenceMap

This class defines a justified (partial or total) equivalence between two AssuranceAssets. Superclass

Map Semantics An Equivalence Map models a justified equivalence between two assurance assets. It is used to indicate potential (partial or full) reuse of assurance assets based on the attached justification and additional conditions.

5.11.2.5 ComplianceMap

This class captures mapping between elements used to demonstrate compliance of an assurance asset regarding reference model elements. Superclass

Map Semantics A Compliance Map specifies the mapping between elements used to demonstrate compliance of an assurance asset regarding reference model elements.

Figure 20. Mappings Metamodel

5.11.2.6 MapJustification

This class corresponds to a textual justification of the mapping type, detailing the similarities between the source and target elements and salient areas of difference. The description here should be qualitative, not quantitative. Attributes

explanation: String The placeholder for the textual justification.

Semantics A Map Justification specifies a textual justification of the mapping type, detailing the similarities between the source and target elements and salient areas of difference. The description here should be qualitative, not quantitative.

5.11.2.7 MapKind (enumeration)

This enumeration corresponds to types of Maps that can occur in modelling mapping. It models the nature of the mapping, in terms of coverage between the source and target elements. Literals

full A full mapping represents complete coverage of the source element in the target.

partial A partial mapping – which may be quantified in the implementation – indicates incomplete coverage.

nomap A mapping of type ’no map’ indicates that there is no similarity between the source and target elements.

DescribableElement See definition in General Metamodel. NamedElement See definition in General Metamodel.



5.12 Argumentation Metamodel


The Argumentation Metamodel describes how features of a generic assurance argument are linked together, and how evidence can be used to support the reasoning presented in the argument. The Argument Metamodel was developed in WP5 of OPENCOSS during the argument patterns research, and a version was shown in D5.3 [20]. However, all future OPENCOSS work will refer to the models found in the last iteration of this document. The CCL Argumentation Metamodel is based on sections of the existing OMG Structured Assurance Case Metamodel (SACM) [7]. Extensions and alterations to the SACM have been made as follows:

Additions to the metamodel to include concepts for Modular Argumentation (basic

concepts to be extended later with richer Agreements/Contract concepts).20

Replacement of the EvidenceItem concept by the Artefact concept and link to the

Artefact Metamodel

Making explicit some relationships which were specified with OCL constraints in

the SACM specification. The idea is to embed those specification constraints

directly in the Metamodel using SACM’s concept of AssertedRelationship.


The Argumentation Metamodel has been split into a series of Metamodel diagrams, which are presented below (Figs below) . The first aspect to indicate is the modifications made on the SACM argumentation metamodel in order to include concepts for the modular argumentation and for patterns. The modifications proposed here try on one hand to impact the minimum as possible on the actual meta-model and at the same time include the concepts for the modular GSN. Some modifications have been made also with the idea to facilitate the task of implementation the meta-model. The changes made in order to fulfil needs for modular argumentation and patterns are highlighted in green while, the changes made in order to make it connect with other parts of the CCL metamodels are highlighted in blue.

20 Note that there are ongoing discussions in the OMG concerning the extension of the SACM to encompass concepts relating to modular assurance arguments. OPENCOSS is represented in these discussions by the University of York, Tecnalia and Simula. The CCL Argumentation Metamodel will be extended and revised as necessary in future iterations, to ensure that it remains “in step” with the evolving standard.



Figure 21. Assurance Case class diagram



Figure 22. Argumentation Class Diagram



Figure 23. Relationships view diagram

This section describes the classes introduced in s 18-20:.

5.12.2.1 AssuranceCase class

An AssuranceCase element. Superclass ModelElement Attributes

• id: String A globally unique identified to the current assurance case

• name: String A comprehensive name to the current assurance case.

Associations • hasEvidences:Evidences[0..*]

The evidence components of the assurance case. • hasArgument:Argumentation[0..*]

The argument components of an assurance case. Semantics The AssuranceCase element represents a justified measure of confidence that a system will function as intended in its environment of use. Assurance cases can be parts of bigger assurance case. This is the case of modular approaches where an assurance case module is included on a higher-level assurance case. When a component is integrated in a system, so does its assurance case and a component related the assurance case can be included on the system assurance case. GraphicalNotation None

5.12.2.2 Agreement class

It is a specialisation of an AssuranceCase element. Superclass AssuranceCase Attributes none Associations

• between: Argumentation[2..*] The argument components, which conform the parts of the agreement.

Semantics The Agreement element represents agreements between parts (Argumentation). Agreements are done between two or more Argumentation parts. It includes the premises and promises validated when both Argumenatation are integrated. GraphicalNotation

5.12.2.3 ArgumentationElement class (abstract)

An ArgumentationElement is the top-level element of the hierarchy for argumentation elements. Superclass ModelElement Attributes

• description: String



A description of the Argumentation entity. • content: String

Supporting content of the Argumentation entity. Semantics The ArgumentationElement is a common class for all elements within a structured argument. GraphicalNotation None

5.12.2.4 Argumentation Class

The Argumentation Class is the container class for a structured argument. It can be understand either as the whole argumentation of an assurance case or by an argumentation module. These modules can content another modules. Superclass ModelElement Attributes

• location: String It identifies where a module of an argumentation is stored in order to be reused.

Associations • consistOf:ArgumentElement[0..*]

The ArgumentElements contained in a given instance of an Argumentation. • contains:Argumentation[0..*]

The nested Argumentation contained in a given instance of an Argumentation. Semantics Structured arguments represented using the Argumentation Metamodel are composed of ArgumentElements. Argumentation elements can be nested, in this case we can talk about argumentation modules that contain elements of argumentation. For example, arguments can be established through the composition of Claims (propositions) and the AssertedInferences between those Claims. Another example can be seen as an argumentation module which contains a composition of Claims as before but in this case, this argumentation module is composed by a set of Claims, InformationElementCitations and/or ArgumentElementCitation. Graphical Notation

Figure 24. Argumentation Class Example

5.12.2.5 ArgumentElement Class (Abstract)

The ArgumentElement Class is the abstract class for the elements of any structured argument represented using the Argumentation Metamodel. Superclass ArgumentationElement Semantics



ArgumentElements represent the constituent building blocks of any structured Argument. For example, ArgumentElements can represent the Claims and their structure made within a structured Argument. GraphicalNotation None

5.12.2.6 ReasoningElement Class (Abstract)

The ReasoningElement Class is the abstract class for the elements that comprise the core reasoning of any structured argument represented using the Argumentation Metamodel – Assertions and ArgumentReasoning (the description of inferential reasoning that exists between Claims). Superclass ArgumentElement Semantics The core of any argument is the reasoning that exists to connect assertions of that argument. Reasoning is captured in the SACM through the linking of fundamental claims and the description of the relationships between the claims. ReasoningElements represent these two elements. GraphicalNotation None

5.12.2.7 Assertion Class (Abstract)

Assertions are used to record the propositions of Argumentation (including both the Claims about the subject of the argument and structure of the Argumentation being asserted). Propositions can be true or false, but cannot be true and false simultaneously. Superclass ReasoningElement Semantics Structured arguments are declared by stating claims, citing evidence and contextual information, and asserting how these elements relate to each other GraphicalNotation None

5.12.2.8 InformationElementCitation Class

The InformationElementCitation Class enables the citation of a source that relates to the structured argument. The citation is made by the InformationElementCitation class. The declaration of relationship is made by the AssertedRelationship class (an AssertedContext or an AssertedEvidence relationship). Superclass ArgumentElement Attributes

• url: String An attribute recording a URL to external evidence.

• toBeInstantiated: Boolean It indicates whether the element needs to be instantiated specifically for the actual argumentation as it is part of a pattern or it just specifies the pattern.

• type: InformationElementType It indicates the typology of the information used.

Associations • artefact:Artefact[0..*]

The artefacts referenced by the current InformationElementCitation object. Artefact is a concept described in the Evidence model.

Semantics It is necessary to be able to cite sources of information that support, provide context for, or provide additional description for the core reasoning of the recorded argument. InformationElementCitations allow



the citation of this information within the structured argument, thereby allowing the relationship between this information and the argument to also be explicitly declared. The url attribute is to be used only when the argumentation aspects of the SACM are complied with. If compliance is claimed against both the argumentation and evidence packages, then the association to Evidence::Artefact shall be used to reference evidence by means of a URL. Graphical Notation type=”context” type=”solution”

Example

Figure 25. InformationElementCitation Class Example

5.12.2.9 ArgumentElementCitation Class

The ArgumentElementCitationt Class cites an Argumentation, or an ArgumentElement within another Argumentation, for use within the current Argumentation. Superclass ArgumentElement Attributes

• type: CitationElementType It indicates the typology of the information used.

Associations • citesElement:ArgumentElement[0..*]

References an ArgumentElement within another Argument. Semantics Within the actual Argumentation (package), it is sometimes useful to be able to cite elements of another Argumentation (i.e., ArgumentElements). For example, in supporting a Claim it may be useful to cite a Claim or InformationElementCitation declared within another Argumentation. It can also be useful to be able to cite entire Argumentations. For example, in supporting a Claim it may be useful to cite an existing (structured) Argumentation. This concept is key to understand the modular argumentation. There are times when it becomes necessary to be able to make a reference from the argument of one case module to some defined context that exists within the boundary of another, or to a Claim that is supported within another argumentation structure. Graphical Notation

5.12.2.10 Claim Class

Claims are used to record the propositions of any structured Argumentation. Propositions are instances of statements that could be true or false, but cannot be true and false simultaneously. Superclass Assertion ManagableAssuranceAsset (from AssuranceAsset model)

ProcCon Measurements on

Processor A

SWAccReport Evidence

artefact report

type=”context” type=”solution” type=”claim”



Attributes • assumed: Boolean

An attribute recording whether the claim being made is declared as being assumed to be true rather than being supported by further reasoning

• toBeSupported: Boolean An attribute recording whether further reasoning has yet to be provided to support the Claim (e.g., further evidence to be cited).

• public: Boolean An attribute recording whether the preposition described in the claim is publicly visible to other arguments and this way is able to be references in other structures of argumentation.

• toBeInstantiated: Boolean An attribute recording whether the claim needs to be instantiated for the actual argumentation or is just the specification of a pattern

Associations • choice:Choice[0..1]

References a ChoiceElement. A claim can be decomposed in a choice of options Semantics The core of any argument is a series of claims (premises) that are asserted to provide sufficient reasoning to support a (higher-level) claim (i.e., a conclusion). A Claim that is intentionally declared without any supporting evidence or argumentation can be declared as being assumed to be true. It is an assumption. However, it should be noted that a Claim that is not ‘assumed’ (i.e., assumed = false) is not being declared as false. A Claim that is intentionally declared as requiring further evidence or argumentation can be denoted by setting toBeSupported to be true. Claims are related with InformationElementCitation through the AssertedEvidence relationship. Claims are also related to another claims in a decomposition structure. The AssertedInference relationship is also used to refer to such relationships.. Also if a claim is referenced by a CitedElement, then this is done by the AssertedInference relationship. This is the case in modular argumentation when in an argumentation module a claim described in another argumentation module is cited. In this case the claim reference should have the public attribute equal true. Invariants Self.assumed and self.toBeSupported cannot both be true simultaneously Graphical Notation assumed=false assumed=true assumed=false toBeSupported=false toBeSupported=false toBeSupported=true toBeInstantiated=false toBeInstantiated=false toBeInstantiated=false

assumed=false assumed=false assumed=false toBeSupported=false toBeSupported=false toBeSupported= true toBeInstantiated=true toBeInstantiated=false toBeInstantiated=true public=true Example

A

SystemClaim {System} is acceptably safe to operate under given {conditions}



Figure 26. Claim Class Example

5.12.2.11 EvidenceUseAssertion Class

A sub-type of Claim used to record propositions (assertions) made regarding an InformationElementCitation being used as supporting evidence to the Argument. This is intended to be used as an interface element to external evidence. An evidence use assertion is a minimal assertion (proposition) about an item of evidence, and there is no supporting argumentation being offered within the current structured argument. Superclass Claim Semantics Well-supported arguments are those where evidence can be cited that is said to support the most fundamental claims of the argument. It is good practice that these fundamental claims of the argument state clearly the property that is said to exist in, be derived from, or be exhibited by the cited evidence. Where such claims are made these are said to be basic EvidenceUseAssertions.

5.12.2.12 ArgumentReasoning Class

ArgumentReasoning can be used to provide additional description or explanation of the asserted inference or challenge that connects one or more Claims (premises) to another Claim (conclusion). ArgumentReasoning elements are therefore related to AssertedInferences and AssertedChallenges. It is also possible that ArgumentReasoning elements can refer to other structured Arguments as a means of documenting the detail of the argument that establishes the asserted inferences. Superclass ReasoningElement Attributes

• toBeSupported: Boolean An attribute recording whether further reasoning has yet to be provided to support the reasoning (e.g., further evidence to be cited).

• toBeInstantiated: Boolean An attribute recording whether the reasoning needs to be instantiated for the actual argumentation of is just the specification of a pattern

Associations • hasStructure:Argument[0..1]

Optional reference to another structured Argument to provide the detailed structure of the Argument being described by the ArgumentReasoning.

Semantics The argument step that relates one or more Claims (premises) to another Claim (conclusion) may not always be obvious. In such cases ArgumentReasoning can be used to provide further description of the reasoning steps involved. An ArgumentReasioning can be related with an InformationElementCitation through the AssertedContext relationship. Graphical Notation



Example

Figure 27. ArgumentReasoning Class Example

5.12.2.13 AssertedRelationship Class (Abstract)

The AssertedRelationship Class is the abstract association class that enables the ArgumentElements of any structured argument to be linked together. The linking together of ArgumentElements allows a user to declare the relationship that they assert to hold between these elements. Superclass Assertion Associations

• hasSource:ArgumentationElement[0..*] Reference to the ArgumentationElement(s) that are the source (start-point) of the relationship.

• hasTarget:ArgumentationElement[0..*] Reference to the ArgumentationElement(s) that are the target (end-point) of the relationship.

Semantics In the SACM, the structure of an argument is declared through the linking together of primitive ArgumentElements. For example, a sufficient inference can be asserted to exist between two claims (“Claim A implies Claim B”) or sufficient evidence can be asserted to exist to support a claim (“Claim A is evidenced by Evidence B”). An inference asserted between two claims (A – the source – and B – the target) denotes that the truth of Claim A is said to infer the truth of Claim B.

5.12.2.14 AssertedInference Class

The AssertedInference association class records the inference that a user declares to exist between one or more Assertion (premises) and another Assertion (conclusion) or between Argument modules in order to define the argumentation architecture or structure. It is important to note that such a declaration is itself an assertion on behalf of the user. Superclass AssertedRelationship Attributes

• multiplicity: AssertedMultiplicityExtension An attribute used while specifying patterns to indicate whether the inference is multiple, optional or one to one.

• cardinality: String An attribute used while specifying patterns to record the number of times the inference should be instantiated afterwards.

Semantics The core structure of an argument is declared through the inferences that are asserted to exist between Assertions (e.g., Claims). For example, an AssertedInference can be said to exist between two claims (“Claim A implies Claim B”). An AssertedInference between two claims (A – the source – and B – the target) denotes that the truth of Claim A is said to infer the truth of Claim B. An AssertedInference can relate a claim with another claim for example for decomposition needs. An AssertedInference can relate a claim with an ArgumentElementCitation when that cited element references a Claim in another argumentation structure or module. Invariants context AssertedInference

S1 Argument by addressing all identified operating hazards

Argument by addressing all identified operating

hazards



inv SourceMustBeClaimOrArgumentElementCitation : self.source->forAll(s|s.oclIsTypeOf(Claim)) or t.ocllsTypeOf(InformationElementCitation)) inv TargetMustBeClaimOrAssertedRelationshipOrArgumentElementCitation : self.target -> forAll(t|t.oclIsTypeOf(Claim) or t.oclIsTypeOf(AssertedRelationship) or t.ocllsTypeOf(ArgumentElementCitation)) Graphical Notation multiplicity=normal multiplicity=optional multiplicity=multi Example

Figure 28. AssertedInference Class Example

5.12.2.15 Choice Class

This class is a subtype of the AssertedInference Class. It is used to denote possible alternatives in satisfying an inference. Superclass AssertedInference Attributes

• sourceMultiextension: AssertedMultiplicityExtension An attribute used while specifying patterns to indicate whether the source of the inference is multiple, optional or one to one.

Semantics

It is used to denote possible alternatives in satisfying an inference. It can represent 1-of-n and m-of-n selection, an annotation indicating the nature of the choice to be made. Graphical Notation Example

Figure 29. Choice Class Example

5.12.2.16 AssertedEvidence Class

The AssertedEvidence association class records the declaration that one or more items of Evidence (cited by InformationItems). It provides information that helps establish the truth of a Claim. It is important to note that such a declaration is itself an assertion on behalf of the user. The information (cited by an InformationItem) may provide evidence for more than one Claim. Superclass AssertedRelationship Attributes

• multiplicity: AssertedMultiplicityExtension

Control system is relatively safe to operate under given environment

All identified hazards eliminated /sufficiently mitigated

Software developed to I.L. appropriate to hazards involved

System X is relatively safe to operate

Interactions between system functions are non-hazardous

All system functions are independent (no interactions)



An attribute used while specifying patterns to indicate whether the inference is multiple, optional or one to one.

• cardinality: String An attribute used while specifying patterns to record the number of times the inference should be instantiated afterwards.

Semantics Where evidence (cited by InformationItems) exists that helps to establish the truth of a Claim in the argument, this relationship between the Claim and the evidence can be asserted by an AssertedEvidence association. An AssertedEvidence association between some information cited by an InformationElementCitation and a Claim (A – the source evidence cited – and B – the target claim) denotes that the evidence cited by A is said to help establish the truth of Claim B. An AssertedEvidence can relation an InformationElementCitation with a Claim Invariants context AssertedEvidence

inv SourceMustBe InformationElementCitation : self.source-

>forAll(s|s.oclIsTypeOf(InformationElementCitation))

inv TargetMustBeClaimOrAssertedRelationship : self.target->forAll(t|t.oclIsTypeOf(Claim) or t.oclIsTypeOf(AssertedRelationship))

Graphical Notation multiplicity=normal multiplicity=optional multiplicity=multi Example

Figure 30. AssertedEvidence Class Example

5.12.2.17 AssertedContext Class

The AssertedContext association class declares that the information cited by an InformationElementCitation provides a context for the interpretation and definition of a Claim or ArgumentReasoning element. Superclass AssertedRelationship Attributes

• multiplicity: AssertedMultiplicityExtension An attribute used while specifying patterns to indicate whether the context reference is multiple, optional or one to one.

• cardinality: String An attribute used while specifying patterns to record the number of times the context should be instantiated afterwards.

Semantics Claim and ArgumentReasoning often need contextual information to be cited in order for the scope and definition of the reasoning to be easily interpreted. For example, a Claim can be said to be valid only in a defined context (“Claim A is asserted to be true only in a context as defined by the information cited by InformationItem B” or conversely “InformationItem B is the valid context for Claim A”). A declaration (AssertedContext) of context (InformationItem) for a ReasoningElement (A – the contextual InformationItem – and B – the ReasoningElement) denotes that A is asserted to be valid contextual information for B (i.e., A defines context where the reasoning presented by B holds true). An AssertedContext can relation an InformationElementCitation with a ReasoningElement An AssertedContext can relation an InformationElementCitation with an ArgumentElementCitation when that cited element reference a ReasoningElement in another argumentation structure or module.



Invariants context AssertedContext inv SourceMustBeInformationElementCitation :self.source->forAll(s|s.oclIsTypeOf(InformationElementCitation)) inv TargetMustBeReasoningElementOrArgumentElementCitation : self.target -> forAll(t|t.oclIsTypeOf(ReasoningElement) or t.ocllsTypeOf(ArgumentElementCitation)) Graphical Notation multiplicity=normal multiplicity=optional multiplicity=multi Example

Figure 31. AssertedContext Class Example

5.12.2.18 AssertedChallenge Class

The AssertedChallenge association class records the challenge (i.e., counter-argument) that a user declares to exist between one or more Claims and another Claim. It is important to note that such a declaration is itself an assertion on behalf of the user. Superclass AssertedRelationship Semantics An AssertedChallenge by Claim A (source) to Claim B (target) denotes that the truth of Claim A challenges the truth of Claim B (i.e., Claim A leads towards the conclusion that Claim B is false). This concept is used in a review process in order to indicate the weakness of an assertion associated with a claim. Invariants context AssertedChallenge inv SourceMustBeClaim : self.source->forAll(s|s.oclIsTypeOf(Claim)) inv TargetMustBeClaimOrAssertedRelationship : self.target->forAll(t|t.oclIsTypeOf(Claim) or t.oclIsTypeOf(AssertedRelationship)) Graphical Notation Example

Figure 32. AssertedChallenge Class Example

5.12.2.19 AssertedCounterEvidence Class

AssertedCounterEvidence can be used to associate evidence (cited by InformationElements) to a Claim, where this evidence is being asserted to infer that the Claim is false. It is important to note that such a declaration is itself an assertion on behalf of the user. Superclass AssertedRelationship Semantics

SW is safe SW is from a

reputable supplier

Supplier reputation is not guarantee of

safety



An AssertedCounterEvidence association between some evidence cited by an InformationNode and a Claim (A – the source evidence cited – and B – the target claim) denotes that the evidence cited by A is counter-evidence to the truth of Claim B (i.e., Evidence A suggests the conclusion that Claim B is false). Invariants context AssertedCounterEvidence inv SourceMustBeInformationElement : self.source->forAll(s|s.oclIsTypeOf(InformationElement)) inv TargetMustBeClaimOrAssertedRelationship : self.target->forAll(t|t.oclIsTypeOf(Claim) or t.oclIsTypeOf(AssertedRelationship)) Graphical Notation Example

Figure 33. AssertedCounterEvidence Class Example

5.13 Property Metamodel


The Property Metamodel defines model elements to represent various statements related to the fundamental properties of assurance assets. The properties have a data type, a measurement unit and a value. The Property Value model element has not defined in this metamodel, since it belongs to the assurance asset annotated. Currently, CCL only annotates Artefacts. An example of artefact property is Custodian of the artefact.


The class diagram for the Property Metamodel is presented in Figures below. The model elements are described in the following subsections.

5.13.2.1 PropertyModel

This class corresponds to model of properties which can be part of an assurance project. Superclass

SW is safe SW is from a

reputable supplier

The failure

records from the last 20 years




hasProperty: Property [0..*] The set of Properties that are part of the PropertyModel

Semantics An Property Model represents the root model element to create properties.

5.13.2.2 Property

This class corresponds to a fundamental property of assurance assets. Superclass


datatype: DataTypeKind The type of the data used to represent the values of a Property.

enumValues: String The list of values modelled as strings (separated by a comma) which belong to the value space of Enumeration data type

unit: String The measurement unit corresponding to the property values.

Semantics A Property models a fundamental property of Assurance Assets such as an Artefact. The properties have a data type, a measurement unit and a value. The Property Value model element has not defined in this metamodel, since it belongs to the assurance asset annotated. See for instance the Value metaclass in the Artefact Metamodel.

5.13.2.3 DataTypeKind (enumeration)

This enumeration corresponds to types of property values. Literals

Enumeration The value space characterized for a list of qualitative values.

String The value space characterized by a string.

Integer A value space characterized by Integer numbers.

Float A value space characterized by Real numbers.



Figure 34. Property Metamodel diagram

5.14 General Metamodel


This metamodel factorises a number of metaclasses which are shared by various other metamodels in CCL.


The class diagram for the Describable Element Metamodel is presented in the figure below. We define the model elements in the following sections.

5.14.2.1 NamedElement (abstract)

This class corresponds to the classes of the CCL metamodels for which an ID and a name can be specified. Attributes

id: String The ID of the NamedElement

name: String The name of the NamedElement

Semantics A Named Element models an element that can have an ID string and a Name string.

5.14.2.2 DescribableElement (abstract)

This class corresponds to the classes of the CCL metamodels for which a description can be specified. Superclass


description: String The description of the describable element

Semantics A Describable Element models an element that can have a Description string.

5.14.2.3 ActivityRelKind (enumeration)

This enumeration corresponds to the possible relationships that can exist between two (reference) activities. Literals

Decomposition An activity is decomposed into several sub-activities.

Precedence The execution of an activity precedes the execution of another.

5.14.2.4 ChangeEffectKind (enumeration)

This enumeration corresponds to the possible effects that a change in some (reference) artefact can have in a related (reference) artefact. Literals

None



A change has no effect.

Revoke A change causes revocation [7, 12]

Modify A change causes the need for some modification.

Validate Some validation is necessary to determine the effect of a change.

5.14.2.5 RequirementRelKind (enumeration)

This enumeration corresponds to the possible relationships that can exist between two requirements. Literals

AND Both requirements must be fulfilled [13].

OR At least one of the requirements must be fulfilled [13].

XOR Only one of the requirements can be fulfilled [14].

Requires The fulfilment of one requirement depends on the fulfilment of another requirement [13].

Contributes To Fulfilment of a requirement contributes to the fulfilment of another. This relationship also implies that the former requirements corresponds a decomposition of the latter. It is the opposite relationship to “refined to” [15].

5.14.2.6 ApplicabilityKind (enumeration)

This enumeration corresponds to the possible relationships that can exist between two applicability specifications. Literals

AND Both applicability specifications must be fulfilled [13].

OR At least one of the applicability specifications must be fulfilled [13].

XOR Only one of the applicability specifications can be fulfilled [14].



Figure 35. General Metamodel diagram

6 The CCL within OPENCOSS

In this section, we discuss the wider intentions of OPENCOSS in terms of the use of the CCL. The intention is to outline the current understanding of the “services” that the CCL will provide to the work being undertaken in the other technical workpackages (WPs 5 – 7). Note that the discussion in this section – which is at a very generic level – has not been revised since the issue of [2].

6.1 General

Although an essential part of the OPENCOSS approach, the CCL is not intended to be “user-facing” in the sense of being itself visible to the final user of the OPENCOSS Platform: rather, the CCL is an enabling technology, which provides services to the other aspects of the OPENCOSS approach. In general, what the CCL provides is a clear definition of terminology and concepts (at both a generic level and mapped to domain-specific usage) and a clear understanding of the essential relationships between these concepts, which need to be understood for informed reuse of assurance assets. Each of these can be used by the approaches to be developed in the other workpackages, to characterise reusable assurance assets and inform the approaches with which they are concerned. In so far as the end user ‘sees’ the CCL at all, it is in terms of the feedback the CCL can be used (by the Platform technologies) to give him concerning the shortfalls in mappings between various different reusable assets. We envisage some kind of “smart advice” offered in terms of where and how assets might be reused, and what the required dependencies are, as outlined in the example presented in Section 5 above. The following sections provide a brief discussion of the scope of the services to be provided by the CCL – in terms of the terminology, concepts and mappings it will define – for each of the technical workpackages, WPs 5-7.

6.2 The CCL and Compositional Certification (WP5)

In Workpackage 5, the challenge is to provide a means to facilitate the reuse of certification assets by using 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 components, with safety-related functions often being partitioned across diverse components. It will be the task of WP5 to clarify assumptions and interdependencies between assurance assets in such a way as to make explicit to what

extent asset reuse (and, to a lesser extent, component reuse22) is possible in isolation from the original system context. The approach will involve the development of freestanding argument modules, with references to associated evidence as characterised using the framework developed in WP6 (see below). These will be composed to form an overall system safety argument. This process is represented in Figure 33, in which three different sets of certification assets are taken for three different components, and then combined (with system specific arguments and assurance) to form a complete system safety case. In Figure 34, we show that we intend to use the OPENCOSS framework in order to map certification assets from one domain to another, and then again combine with other assets to form a system safety case. Although the methodology for the composition of argument modules has not yet been fully developed, it will rely on the

22 Please note that, even if it is impossible to reuse certification assets associated with a component, it may still be possible to reuse that component. New data about that component will need to be generated instead. However, the assurance data itself may make it possible to assess compatibility.



definition of claim interfaces on argument modules, which can be compared for matches, mismatches and

missing details.23

Figure 33: Modular safety case composition

Figure 34: Cross-domain modular safety case composition

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

Precision in Claims: the CCL will provide 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. This will facilitate the development of tightly

23 Please note that nothing said here implies the use of any particular notation for the representation of arguments, whether a graphical notation like GSN or anything else. The only proviso – which is inevitable in the safety domain- is that the arguments are presented using informal logic (though they may rely on evidence developed and presented using formal methods). Not that the primitive logical forms and relationships used in argumentation (e.g. premise, claim, conclusion, implication, assertion etc.) are common to argumentation techniques in any domain, and have been thoroughly defined, deployed and explored in the literature of philosophy and linguistics (see, for a recent example, [7]. The Argumentation section of the OMG’s SACM metamodel [8] provides a clear definition of these primitive types in UML and natural language, and relates its discussion to the safety domain.

Component A Cert Assets

Component C Cert Assets

Component B Cert Assets Component

A Cert Assets

Component B Cert Assets


System safetycase

Composed to form

SystemSpecific

Cert Data

Component A' Cert Assets



Component A' Cert Assets



System safetycase

Composed to form

Component A Cert Assets

OPENCOSS mapping technology

SystemSpecific

Cert Data



defined safety argument modules and interface specifications, ensure consistency of expression throughout the compositional argument structure, and will de-risk the composition of argument and evidence artefacts originally defined with respect to the requirements of diverse domains and standards by making the underlying concepts at work in the assurance and argument processes clear.

Standards models for compliance: the CCL can be used to generate models of individual standards, thus facilitating the development of compliance arguments and providing a means for determining how compliant a component is.

Mapping of terms and concepts: the CCL will provide a means by which requirements, objectives and assumptions can be mapped from one domain to another.

Support for developing argument patterns: the CCL will contain generic concepts for items such as evidence characteristics and objectives. These can be used as a framework for developing reusable argument patterns and templates, e.g. for specific analysis types or decomposing certain types of requirement. This is helpful for both composition (as modules are similarly structured) as well as ensuring compelling arguments.

6.3 The CCL and the Evolutionary Evidence Chain (WP6)

In Workpackage 6, the challenge is to provide a means to characterise evidence artefacts, and to de-risk their reuse or evolution by making clear precisely what they offer to, and depend on, in terms of a generic assurance framework. It is essential that the original artefacts and conditions relating to the production and recording of evidence artefacts – and their precise contribution to the support of an implicit or explicit

assurance (or compliance) claim24 – be stored, so that reuse of the evidence can be informed, and the nature (and potential shortcomings) of its relevance and guarantees on the reuse context can be assessed. The CCL will provide support for this approach as follows:

By providing a standardised lexicon for the concepts of safety assurance/compliance demonstration, and definitions for generic concepts relating to the characteristics of evidence. By expressing these characteristics in general terms, using the conceptual definitions provided by the CCL, the process of assuring safe reuse of evidence can be made considerably easier. Information can be preserved in an evidence repository with a consistent, transparent interface to the arguments and processes developed in WPs 5 and 7 respectively.

By providing standardised models of safety standards across the OPENCOSS target domains. This will, for example, make explicit the intention underlying particular safety processes and artefacts, in the context of specific standards, and will clarify where there are equivalences and divergences between the standards. This should enable WP6 to formulate informed answers to such questions as “what is the purpose of this evidence item or analysis process, in the context of this standard, and what evidence do I have which fulfils the same objectives?”, “what are the shortcomings of this evidence, with respect to the compliance approach mandated in this standard?” etc..

24 Although the language of argumentation is used here, the observations made are equally valid, whether assurance is demonstrated by means of a safety/assurance argument or by means of a compliance checklist. In order to assess the appropriateness of reusing evidence artefacts in a checklist-based approach to compliance, it is necessary to perform some “argument-style thinking”, in terms of querying issues such as the relevance, completeness and coverage of the evidence against the requirements of the reuse context. This issue is discussed further in Section 3.4 above.



6.4 The CCL and Transparent Certification and the Compliance-Aware Process (WP7)

Workpackage 7 aims to ensure that an awareness of compliance/certification issues permeates through the development process for safety-critical systems, throughout the lifecycle. It is the role of WP7 to model and understand processes and their required contribution to the assurance of the product. WP7 will also define metrics to indicate, for example, a project’s progress towards particular compliance objectives. The CCL will provide support to this approach as follows:

By providing a standardised lexicon of safety and project concepts which will help in ensuring consistent process description across an individual project.

By providing standardised models of safety standards across the OPECOSS target domains, which will help clarify the intention of process activities in terms of their contribution to standards compliance.



7 Future Work

This document represents the final version of the CCL Metamodel, which provides the basis for the third and final prototype version of the tooling which has been developed elsewhere in the tooling. During the validation of the tooling in the testing and case study phases of the project, some requests for modification to the metamodel arose. Where it was not possible to evaluate and implement these changes in the timespan of the project, the change requests were simply logged, as a reference for any potential future work outside the project. The change requests are recorded in Table 1 below, for reference:

ID STATUS CCL METAMODEL ISSUE

1 Proposed package Need a concept for packing for composition

2 Proposed Reference Reference across concepts inside package

3 Proposed General Differentiate between "To modify" and "Modified" in ChangeEffectKind

4 Proposed Mapping Metamodel

Status needed for compliance maps (e.g., approved)?

5 Proposed Mapping Metamodel

Link with argumentation (e.g., for compliance argument)? Circular references have to be checked

6 Proposed Assurance Asset Need for linking AssuranceAssetEvaluation and the

Artefact where it's recorded (change in Evidence Metamodel; (feedback at

training in York; comment 24 address it)

7 Proposed Assurance Asset Doubt: Not sure why we decided to make AssuranceAssetEvaluation part

of ManageableAssuranceAsset instead of AssuranceAssetEvent

8 Proposed Assurance Asset No need for 'Approval' EventKind; simply another type of 'Evaluation'

(feedback at training in York)

9 Proposed Reference Framework

RefRequirements can be assigned to RefActivity only by means of

ownedRequirement


ownedRequirement of RefActivity seems to be inconsistent with, for

example, constrainingRequirement of RefArtefact


Not sure about the need for/meaning of objective for RefActivity. Isn't it a

RefRequirement?




It must be possible to specify the source (e.g., clause in the text of a

safety standard) from which an element is created; this has some

impacts (e.g., need for RefArtefactProperty as specialization

of Property)


Association between RefTechnique and RefRequirement


Association between RefRole and RefArtefact


The multiplicity of RefActivity-->applicableTechnique must be '0..*'


The multiplicity of criticLevel must be '0..1' (see for instance ERTMS

standard), maybe even 0..* for allowing a usr to specify that a given

RefApplicabilityLevel applies to several RefCriticalityLevels (see EN50129

tables)


The multiplicity of applicTarget must be '0..*' (or '1..*')


No need for RefApplicaiblityRel and ApplicabilityKind (change in General

metamodel); just another RefApplicabilityLevel; this also solves

some issues with accepted combinations of techniques and role

independence


Add RefApplicabiltiyCategory, which will have RefApplicabilityLevels; most

standards are like this


In line with comment 19, do we need RefCriticalityCategories? For example, what if someone decides to create a reference framework for IEC61508 +

DO-178? EN 50128 and ISO 26262 also have criticality "categories" for

functions (SIL) and tools


Add 'RefApplicabilityOwner' as abstract metaclass for RefRequirement

and RefActivity?

22 Proposed Evidence 'Need for specifying the ArtefactDefinition of an Artefact that is

part of another

23 Proposed Evidence Why is ArtefactDefinition a ManageableAssuranceAsset?



24 Proposed Evidence Association between Artefact and AssuranceAsset whose information is

recorded in an artefact; define 'RecordableAssuranceAsset'?; this has implications for Ia but we can ignore

them for the time being

25 Proposed Baseline Reflect changes in Reference Framework Metamodel

26 Proposed Process Association between Technique and Tool

27 Proposed Process Change 'requiredArtefact' and 'producedArtefact' for input and

output (also in Reference Framework and Baseline)

28 Proposed Argumentation Association between ArgumentElement and

BaselineElement? (see comment 5)

29 Proposed Argumentation No need for confidenceImpactType


Association between RefArteactRel (recordedIn) and RefActefact


RefActivity linked to RefArtefactRel (creates)


Need for keeping track of the fact that some RefArtefactRelationships can depend on RefCriticalityLevels? -->

RefArtefactRelationship as RefAssurableElement


Rename "requiredArtefact" and "producedArtefact" as "input" and

"output", respectively (see comment 27)


Rename "role" as "participant"


For consistency, rename "ownedActivities" as "ownedActivity"


Sub-RefApplicabilityLevels necessary? They're standard-specific


Need for clarification of all RefRequirement attributes


Competence and Responsibility for RefRole --> New attributes?

Association with RefRequirement?

39 Proposed Assurance Asset Why should ArtefactRel, ArtefactProperty inherit from

Assurance Asset ?



40 Proposed BaseXXX BaseActivity, BaseArtefact, BaseRequirement are implemented

but not defined in D4.4 (part of Baseline)

41 Proposed Participant It's strange that the Tool class inherit from "Participant". If necessary,

maybe try a different wording, e.g. "Actor"

42 Proposed Resource This entity is implemented in the prototype 2 but missing in D4.4


ConstrainedRefElement class for abstracting all classes related to RefRequirements (RefActivity,

RefArtefact…)


Extend change information of RefArtefactRel with

targetModificationEffect and targetRevocationEffect


Deletion if RefRequirementRel, keeping subRequirements; for

consistency, relationships between requirements should be specified with RefApplicabilities (e.g., as relationships between techniques); the relationship

an also depend on the criticality


Should the "requires" relationship between requirements be managed as

proposed in the previous comment?


Association between RefActivity and RefRequirement changed to

Precondition and Postcondition?


Inclusion of "RefAssurableElementSet", associated

with RefApplicability (e.g., for specifying relaitonships between sets

of roles for EN 50128)


Association between ReApplicabilty and RefApplicabiityLevel; in some

standards, the associations of levels is independent of the criticality level

(e.g., ERTMS); NOTE: ensure consistency with 16


Removal of RefActivityRel; the two "hardcoded" relationships seem to be

enough


Inclusion of subRefTechnique? (e.g., for IEC 61508)




RefTechnique as RefApplicability owner? (for "subtables")


Postconditions for reuse in equivalence maps: association

between RefEquivalenceMap and RefAssurableElement (0..*)?

54 Proposed Baseline "Check" baseRequirements --> change in compliance map, so that it isn't

necessary to select a claim or artefact? (more flexible/new way to use the

platform)

55 Proposed Baseline It would be better the compliance of an activity depends on the compliance status of all the artefacts required as input of the activity itself: currently

even if an input artefact is not compliant the activity could be

compliant

Table 1. Change Requests for Metamodel which were not Incorporated during OPENCOSS



8 Conclusions

This document has presented a unified conceptual and implementation metamodel for the Common Certification Language. This model is the basis for the tooling developed in WPs 4 (CCL Editor), 5 (Compositional Argument tooling), 6 (Evidence Management tooling) and 7 (Process Management tooling), as well as to help in the integration of tooling in the OPENCOSS Platform. We have also presented an account of the modelling approach adopted by the project. The Metamodel provides the basis of a Framework, around which specific safety standards, assurance concepts, projects, industrial standards can be described in a well-structured, well-ordered and, hence, comparable way. A supporting approach – captured in the Mappings Metamodel – allows us to take concepts and objectives from one context and map them to another. Mappings may frequently be partial, incomplete or even non-existent. These complex relationships form the basis for the informed guidance on the suitability of assurance asset reuse that the OPENCOSS Platform will afford to users. The report also indicates how the Metamodel relates to other technical research work packages in OPENCOSS. This discussion requires validation from work package leaders. Finally, we have summarised potential future changes to the Metamodel, as a guide for future work outside OPENCOSS.



9 Abbreviations and Definitions

CCL Common Certification Language GSN Goal Structuring Notation JAR Joint Airworthiness Requirements MDA Model-Driven Architectures MOF Meta-Object Framework OMG Object Modelling Group PSAC Plan for Software Aspects of Certification SACM Structured Assurance Case Metamodel UML Unified Modelling Language XML Extensible Markup Language



10 References

[1] OPENCOSS Project, Detailed Requirements for the Compositional Certification Approach, Deliverable 5.1, Issue 1, November 2012

[2] OPENCOSS Project, Intermediate Common Certification Language Conceptual Model, Deliverable 4.3, January 2013

[3] OPENCOSS Grant Agreement no 289011, Annex 1: Description of Work, OPENCOSS Consortium, September 2011

[4] A. Kleppe, J. Warmer and W. Bast, MDA Explained – The Model Driven Architecture: Practice and Promise (Addison-Wesley, 2003 and reprints)

[5] OPENCOSS Project, Baseline for the Common Certification Language Deliverable 4.1, Issue 1, April 2012

[6] Protogé Ontology Editor and Knowledge-Base Framework. Open-source Toolset. Available for download at http://protege.stanford.edu

[7] Object Modelling Group, Structured Assurance Case Metamodel (SACM), Beta 2 Version, June 2012. Available for download from http://www.omg.org/technology/documents/modernization_spec_catalog.htm

[8] Aerospace Recommended Practice 4754, Certification Considerations for Highly-Integrated or Complex Aircraft Systems http://standards.sae.org/arp4754/

[9] Panesar-Walawege, R.K., Sabetzadeh, M., Briand, L.: Supporting the verification of compliance to safety standards via model-driven engineering: Approach, tool support and empirical evaluation. Information and Software Technology 55(5): 836-864, 2013

[10] Olivé, A.: Conceptual Modeling of Information Systems. Springer, 2007 [11] Cleland-Huang, J., Gotel, O., Zisman, A. (eds.): Software and Systems Traceability. Springer, 2012 [12] Oxford Dictionaries: http://oxforddictionaries.com [13] Carlshamre, P., Sandahl, K., Lindvall, M., Regnell, B., Natt och Dag, J.: An Industrial Survey of

Requirements Interdependencies in Software Product Release Planning. In: RE’01 [14] Berntsson-Svensson, R., Gorschek, T., Regnell, Torkar, R., Shahrokni, A., Feldt, R.: Quality

Requirements in Industrial Practice - An Extended Interview Study at Eleven Companies. IEEE Transactions on Software Engineering 38(4): 923-935, 2012

[15] Dahlsted, A.G., Persson, A.: Requirements Interdependencies: State of the Art and Future Challenges. In: Aurum, A., Wohlin, C. (eds.) Engineering and Managing Software Requirements, Springer, pp. 95-116, 2005

[16] Sun, L., Kelly, T.: Elaborating the Concept of Evidence in Safety Cases. In: SSS 2013 [17] OPENCOSS Project, Baseline for the Common Certification Language, Deliverable 4.1, Issue 1, April

2012 [18] Web Ontology Language (OWL), WC3 Recommendation, 10th February 2004,

http://www.w3.org/TR/owl-ref/ [19] Katrina Attwood and Philippa Conmy, ‘Nuanced Term-Matching to Assist in Compositional Safety

Assurance’, First ASSURE Workshop, San Francisco, May 2013 [20] OPENCOSS Project, Compositional Certification Conceptual Framework, Deliverable 5.3 version 1,

November 2013 [21] Lloyd, S (ed), Roget’s Thesaurus of English Words and Phrases Penguin, 1982 [22] Object Modeling Group, Semantics of Business Vocabulary and Business Rules (SBVR), 2008 [23] S. Bird, E. Klein and E. Loper, Natural Language Processing with Python, O’Reilly 2009

http://standards.sae.org/arp4754/

http://www.w3.org/TR/owl-ref/



11 Appendix A: Evolution of this document from version 2 of D4.4

This document is an increment on version 2 of D4.4 (issued in February 2014), which presented an interim CCL conceptual model. The developments from that document are summarised briefly in Table 2.

D4.4 v 1 Section Degree of Change in this Document

Comment

1 Executive Summary slight emendation to reflect the status of the metamodel

2 Introduction to the Common Certification Language and its role in OPENCOSS

no change

2.1 Purpose of this document minor changes to reflect the status of the metamodel

2.2 Overview of document structure

minor changes to reflect the status of the document

3 The Common Certification Language: Modelling Approach

minor formatting changes only

3.1 Overview minor formatting changes only

3.2 Inter-Model relationships in conventional MDA Approaches


3.3 Abstraction hierarchy and Vertical (inter-model) relationships in OPENCOSS


3.4 Horizontal relationships in OPENCOSS


3.5 “Partial Mapping” in OPENCOSS


4 The CCL Thesaurus considerable changes to reflect the development of the Vocabulary. New subdivisions, and discussion of vocabulary structure and population

5 The CCL Metamodel Changes to reflect the addition of cross-domain functionality and the vocabulary

5.1 Overview minor formatting changes only

5.2 Relationship with the Interim CCL Metamodel

section renamed (to “Relationship with version 2 of the CCL Metamodel”), and brief discussion of the salient changes presented.




Comment

5.3 Reference Assurance Framework Metamodel

Additional attributes and relationships included to incorporate the concept of Baseline assets and models.

5.4 Assurance Project Metamodel Additional attributes and relationships included to incorporate the concept of Baseline assets and models

5.5 Managed Assurance Asset Metamodel

minor typographical changes

5.6 Baseline Metamodel New section Please note that section and numbering from Section 5.6 onwards, and Figure numbering from Figure 11 onwards, differs from the previous version of the deliverable.

5.6 Artefact Metamodel Minor typographical changes

5.7 Process Metamodel Minor typographical Changes

5.8 Vocabulary Metamodel Fully revised conceptual and implementation models.

5.9 Mappings Metamodel Additional attributes and relationships added to reflect cross-domain functionality

5.10 Argumentation Metamodel Minor typographical changes

Please note that, although this work is also reported in D5.3, D4.4 should be taken to be the current reference version of all of the CCL metamodels – including the Argumentation Metamodel – going forward

5.11 Describable Evidence Metamodel

unchanged

5.12 Recordable Assurance Asset Metamodel

unchanged Note that this metamodel is included, even though it is not directly implemented in the OPENCOSS tooling

6 The CCL within OPENCOSS unchanged

6.1 General unchanged

6.2 The CCL and Compositional Certification (WP5)

unchanged

6.3 The CCL and the Evolutionary Evidence Chain (WP6)

unchanged

6.4 The CCL and Transparent Certification and the Compliance-Aware Process

unchanged

7 Future Work Changes to reflect the final status of the CCL metamodel, and the inclusion of unenacted change requests




Comment

8 Conclusions minor changes to reflect the current status of the metamodel

9 Abbreviations and Definitions some additions

10 References some additions

11 Appendix A: Evolution of this document from D4.3

Retitled “Evolution of this document from version 2 of D4.4” and revised to reflect the current metamodel

Table 2. Developments from Version 2