Expert Group 20: System Architecture

EDSTAR - European Defence Standards Reference System

Expert Group 20: System Architecture

Final Report

Brussels, November, 2014

Page 2

Table of contents

0. LIST OF EXPERT GROUP MEMBERS .................................................................................................. 3

1. INTRODUCTION ..................................................................................................................................... 4

2. REFE RENCES AND TERMINOLOGY .................................................................................................. 6

2.1. ACRONYMS ............................................................................................................................................ 6 2.2. REFERENCES AND TERMINOLOGY RELATED TO ARCHITECTURE ................................................................ 7

3. SCOPE .................................................................................................................................................. 11

3.1. INITIAL REFERENCES OF THE WORK ....................................................................................................... 11 3.2. CONSOLIDATION OF THE SCOPE ............................................................................................................ 12

4. RATIONALE FOR SELECTING A STANDARD/STANDARDS-LIKE DOCUMENT AS “BEST PRACTICE”........................................................................................................................................... 13

4.1. ADOPTED WORK PROCESS .................................................................................................................... 13 4.2. RATIONALE FOR SELECTION CRITERIA ................................................................................................... 15 4.3. FINAL EXPERTS’ REVIEW PROCESS ........................................................................................................ 16

5. RECOMMENDATIONS ON APPLICATION AND TAILORING OF A STANDARD ............................ 17

5.1. LIST OF DOCUMENTS ............................................................................................................................ 17 5.2. METHODOLOGY OF PRESENTATION ....................................................................................................... 17 5.3. CLASSIFICATION CRITERIA .................................................................................................................... 19

5.3.1. Process .................................................................................................................................. 19 5.3.2. Method ................................................................................................................................... 30 5.3.3. Description/Formalism ........................................................................................................... 40 5.3.4. Evaluation .............................................................................................................................. 44 5.3.5. Vocabulary ............................................................................................................................. 45

6. RECOMMENDATIONS FOR FUTURE STANDARDIZATION ............................................................. 47

7. CONCLUSION....................................................................................................................................... 49

ANNEX A – LIST OF BEST PRACTICE STANDARDS REFERENCES ASSOCIATED TO THE DOMAIN ............................................................................................................................................................... 51

ANNEX B – FINAL EXPERTS' CHARACTERISATION AND SELECTION .............................................. 52

ANNEX C – ARCHITECTURE LANGUAGES ............................................................................................ 58

ANNEX D – SYSTEM ARCHITECTURE STANDARDS RECOMMENDED BY EDSTAR EG 09 “ARMOURED LAND VEHICLE TECHNOLOGY”................................................................................ 59

Page 3

0. List of Expert Group Members

CEN Member

Name Company / MoD Contact

FR Mr. Jean-Luc GARNIER

Convenor

Thales [email protected]

FR Mr. Guillaume BOURDEAU

Secretariat

BNAE [email protected]

FR Mr. Jacques BLANQUART MBDA [email protected]

FR Mr. Régis DUMOND DGA [email protected]

IT Mr. Roberto MATTEUCCI IVECO - OTO MELARA

[email protected]

IT Ten. Col Mario SCARSELLATO

Esercito Italiano - Italian Army

[email protected]

IT Ten. Col Simone GARIGILIO

Esercito Italiano - Italian Army

[email protected]

mailto:[email protected]







Page 4

1. Introduction

The European Commission requested the European Committee for Standardization (CEN) to

establish Workshop 10 in order to improve the efficiency and enhance the competitiveness of

European Defence Industry. The European Handbook for Defence Procurement (EHDP) was

prepared by Experts Groups reporting to CEN Workshop 10. This document is a guide

designed as a tool for anyone involved in the European defence procurement contractual

negotiations.

The primary target audiences for the Handbook are:

The staff producing procurement specifications and invitations to tender in the

ministries of defence,

the staff responding to those requirements in defence companies.

EHDP is designed to provide Defence Procurement Agencies and Defence Industries with a

preferential list of selected recommended standards qualified as best practice that should be

included in contracts together with concise recommendations for an optimum use of those

standards in such a Defence Procurement context.

EHDP became EDSTAR, European Defence Standards Reference System, on July 1st,

2011, after European Commission handed it over to EDA.

Those types of resulting informative data could be used in the acquisition process by MoD

and in the development process by Industry so as to build systems faster, better and

cheaper.

The aim of a recommendation is to develop good practices in the domain addressed by the

Expert Group and to assist the final user in using recommended best practices standards in

the best cost-effective way.

The increasing number of standards necessitates the harmonisation of European practices

used by defence procurement stakeholders.

The objective is to deploy a common approach through Nations Procurement

agencies about an optimized utilization of civil and military standards, including

possible limitations of civilian standards with respect to military applications and to

provide a useful guide to all stakeholders involved in defence procurement process

Description of how to implement standards successfully in armament contracts

The overall result will be a better use of standards in armament contracts

During the drafting process, recommendations are designed to allow EDSTAR final users to

be provided with the right information for timely and quickly acquiring the best control in

writing standards clauses related to the selected material, in armaments contracts. That’s

why the volume of recommendations will be accordingly fully compatible with respect to

Page 5

EDSTAR vocation and purpose.

During its 13th of December 2012 meeting, the EDA Materiel Standardization Group (MSG)

endorsed the EDSTAR JMC proposal and agreed to launch a request for a new set of best

practice standards in the domain of “System Architecture” to be added to the European

Defence Standards Reference System.

A group of experts (see paragraph 0) volunteered to support the initiative, the EG 20 was

constituted and the study launched at the 19th June, 2013, kick-off meeting.

Working period: June 2013 – October 2014

Page 6

2. References and Terminology

2.1.Acronyms

AAP Allied Administrative Publication NATO

ANSI American National Standards Institute

BNAE Bureau de Normalisation de l'Aéronautique et de l'Espace FR

CEN European Committee for Standardization European

DEF STAN UK Defence Standardization

DoDAF Department of Defense Architecture Framework

EDA European Defence Agency European

EDSTAR European Defence Standards Reference System European

EG 20 Expert Group on System Archicheture

EHDP European Handbook for Defence Procurement European

EIA Electronic Industries Alliance

EN European Standards European

HLA High Level Architecture

IDEA International Defence Enterprise Architecture Specification

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineer

INCOSE International Council on Systems Engineering

ISMS Information Security Management System

ISO International Organization for Standardization International

JMC Joint Maintenance Committee European

JTC / SC joint technical committee / Subcommittee

LAVOSAR Open System Architecture Standardisation for Vehicle Mission Systems

MITRE Mitre Corporation

MOD Ministry of Defence

MODAF British Ministry of Defence Architecture Framework

MODEM MoD Ontological Data Exchange Model for architecture frameworks

MSG Materiel Standardization Group European

NAF NATO Architecture Framework

NATO North Atlantic Treaty Organization

OCCAR Organisation for Joint Armament Cooperation

OMT Object Model Template

RTI Run-Time Infrastructure

SAE Society of Automotive Engineers

SDO Standardization Development Organisation

SE Systems Engineering

Page 7

SISO Simulation Interoperability Standards Organisation

SLCM System Life Cycle Management

SMS Service Management System

STANAG NATO - Standardization Agreement NATO

TOGAF The Open Group Architecture Framework

TR Technical Report

UPDM Unified profile for DoDAF and MODAF

2.2.References and terminology related to Architecture

System

A system is an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.

[INCOSE SE Handbook, v3.2, 2010]

NOTE: People have to be thought as organization and personnel

Sub-System

A subsystem is defined as a group of assemblies, designed together to form a major part of a system, complete in its own right and performing a specific function or functions.

Example: A radar antenna in the A400M airplane.

[OCCAR_EA, Derived from NATO AECT 100, Environmental Guidelines for Defence

Materiel]

Building block

A building block is made up of the system, one or more end products, two or more subsystems for each end product, and the ensemble of enabling products. Each end product and each enabling product includes one or more of the following: hardware, software, firmware, personnel, facilities, data, materials, services, and processes. The following information can be associated with each element within the building block:

a) configuration identification;

b) the costs to be collected;

c) identifications of interfacing elements inside and outside the building block;

d) specifications relevant to the element;

e) definition of work to be done;

f) other relevant agreement information.

[ANSI/EIA-632-1998]

NOTE: a building block could be a component of a larger system

Page 8

Equipment

Integrated set of parts and components

NOTE 1: An equipment accomplishes a specific function.

NOTE 2: An equipment is self-contained and classified as such for the purposes of separate manufacture, procurement, drawings, specification, storage, issue, maintenance or use.

NOTE 3: The term "unit" is synonymous with the term "equipment"

[prEN 16601-00-01 – to be published]

Organisation

An Organisation is a group of people and facilities with an arrangement of responsibilities, authorities and relationships.

[ISO 9000:2000]

Environment

The surroundings (natural or man‐made) in which the system‐of-interest is utilized and supported; or in which the system is being developed, produced or retired.

[INCOSE 2010]

NOTE 1: the surroundings can be land, sea, air, flora and fauna, and the presence of people and other external (natural and man-made) systems.

NOTE 2: Negative environmental interactions that we may have include production of waste and contamination, use of natural resources, water use and disposal, loss of species and habitats, soil erosion and damage to landscape. Positive interactions include landscape restoration and habitat creation.

[UK MOD Sustainability and Environmental Appraisal Tools Handbook Environment

Management]

Systems engineering

Interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life.

[ISO/IEC/IEEE 24765: 2010]

NOTE: includes the definition of technical performance measures; the integration of engineering specialties; and the engineering activities supporting lifecycle processes that balance cost, performance, and schedule objectives

System architecture and architecting

System architecture is an architecture covering an entity elaborated with a systemic (system-wide) approach.

Architecture : (system) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

Page 9

[ISO-42010:2011]

NOTE 1: A systemic approach refers to something that is spread throughout, system-wide, affecting a group or system, such as a body, economy, market or society as a whole.

Source: Wikipedia, 25/10/2103

NOTE 2: Principles have to be thought to cover all the activities supporting the whole system life cycle.

This definition can be refined by:

Architecture an intrinsic quality or property of a system consisting of the arrangement and interrelationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system.

[MITRE Thoughts on Architecting, 31/01/08]

Architecting is the process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle

[ISO/IEC/IEEE 42010:2011]

NOTE 1: The architecting outcomes provide a frame in which products can be built, procured and acquired. They enable systems developed to work together to implement the overall entity.

NOTE 2: Term “Architecting” covers any necessary activity related to architecture.

NOTE 3: There are others available definition of Architecting

Enterprise

Enterprise: one or more organisations sharing a definite mission, goals, and objectives to offer an output such as a product or service.

[ISO-15704:1999]

The term ‘‘enterprise’’ in the context of ‘‘enterprise architecture’’ can be used to denote both an entire enterprise — encompassing all of its information and technology services, processes, and infrastructure — and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

[TOGAF V9.1]

Enterprise architecture

Enterprise Architecture [See most of the Architecture Frameworks]: Architecture seen / analysed / worked with an Enterprise view. I.e. strategic view of a “subject-of-interest”.

NOTE: The role of an enterprise architecture is to provide decision support, in the context of the enterprise strategy, for the use of resources (including processes and procedures) in the enterprise. In other words, the architecture is defining how resources will be used to support enterprise strategy and benefit the enterprise goals and objectives. Enterprise architecture touches every part of the organisation.

[adapted from NAF V3.0, Chapter 1, Page V]

Page 10

Modular architecture

A modular architecture is an architecture where the system is partitioned into modules standardized in terms of physical and low-level functional characteristics and where the elements are uniquely identified and consistently used across all products and views within the architecture.

NOTE: Modular architecture is built to minimize coupling between the elements of the architecture aiming at replacing or adding any module with limited impacts on the rest of the system. It can be applied to both hardware and software and it can refer to design strategies (e.g. components autonomy, reusability, maintainability, upgrading and obsolescence management).

Source: EG 20

Federated architecture

In a federated architecture, each system part is dedicated to a specific goal or mission. Most of the time, the federated parts are not developed for a dedicated architecture. However they comply with global behavioral rules defined for a specific implementation.

Source: EG 20

Integrated architecture

In integrated architecture, system parts are designed and organized for a whole identified usage optimizing one or several concerns like performance, costs, size, etc.

Source: EG 20

Distributed architecture

In distributed architecture, system parts are loosely coupled, generally spread geographically and are operated separately.

Source: EG 20

Open architecture

An architecture is open when the external interfaces of its core architecture are publically defined (physically and functionally).

NOTE 1: a good open architecture allows adding, upgrading and swapping of additional architectural items without compromising the main integrity of the core part. But –of course- the performance can be significantly altered (positively or negatively).

NOTE 2: Knowledge of the external interface is sufficient for a third party to develop and add architectural parts to the core architecture.

NOTE 3: From LAVOSAR (working process – to be published):

Comprehensive best practice architecture with all necessary views from which a target architecture for a specific system can be derived and which is maintained by an open, public consensus process of an open forum.

Source: EG 20

Page 11

3. Scope

3.1.Initial references of the work

Architecture framework and architecting activities are now key-requirements when willing to

acquire a system able to achieve capability evolution over time and interoperability. During

the last 10 years, this domain has followed a maturation ladder which has led to a large

diversity of frameworks and documents including NATO and ISO references.

The mandate received from EDSTAR JMC requested a new set of best practice standards in

the domain of “System Architecture” to be added to the European Defence Standards

Reference System, giving the following areas as a general outline reference for the domains

of identification of standards:

“System” to be understood as anything worked / used with a systemic approach.

System architecture and architecting (Architecture système et activités d’architecture)

Open architecture (Architecture ouverte)

Modular architecture (Architecture modulaire)

Integrated / built-in architecture (Architecture intégrée)

Federate architecture (Architecture fédérée)

Distributed architecture (Architecture distribuée)

Enterprise architecture (Architecture d’entreprise)

The work performed by EG 20 Experts provides a contribution in the identification of a set of

standards and standard-like documents associated with a robust set of system architecture

concepts and definitions.

The EG 20 kick-off meeting took place on the 19th June, 2013, with the participation of

10 delegates including experts from 3 Nations (DE, FR, IT) plus EDSTAR representatives. In

the follow-on meetings German experts and one French expert withdrew and the Group

manpower strength downsized to 4 experts. In the later stages of the work two other

delegates from the Italian MoD, joined as background support to the Italian Industry

representative but without attending the meetings.

This new situation limited to a large extent, not so much the diversity of expertness but

rather, man-hours available to support the study effort and an overall review of the scope

was needed in order to meet the deadline given for the delivery of the report.

Page 12

3.2. Consolidation of the scope

In order to meet the man power constraints, the Group agreed to continue to refer to the

general frame indicated by the EDSTAR JMC (see 3.1 Initial references of the work) but to

redefine its activity for the identification of suitable standards on the base of the following

approach:

Give priority to standards related to defence domains.

Concentrate on generic standards and reference documents, avoiding addressing

standards related to specific technological aspects of systems or to specific

operational domains (land, naval, air, space, C4ISR, joint, coalition, etc.).

Select standards and standard-like documents that are fully or partially relevant to

architecture and architecting following a consistent path in terms of vocabulary and

processes.

Do not address languages and tools for system architecture because the EG 20

considered these topics not to be references for selection. Nevertheless, a list of main

architecture languages has been made available in ANNEX C.

Do not consider books, industry or other references for specific domains or

technologies, due to the lengthy effort required to synthesize their content and

classify their scope.

Do not consider standards which are not enough mature or are nearing

obsolescence.

Limit the selection of standards to those which are readily identifiable and accessible

during the study period.

Page 13

4. Rationale for selecting a standard/standards-like document as “Best Practice”

4.1.Adopted work process

Once the perimeter of the activity was identified and agreed, the activity of the Group

developed along the following steps and actions:

Sharing of common references and terminology – The definitions applicable to System

Architecture were analysed and discussed. The agreed references and terminology have

been recorded in chapter 2 above.

Identification of Standards - On the base of the new scope set for the development of

the analysis, each expert gathered from the respective company databases and other

known sources of standards or standard-like documents potentially suitable for best

practice selection.

Further Contributions – A set of system architecture standards was recommended

by the EG 09 Armoured Land vehicle Technology. The proposed options have been

analysed by EG 20 but found, although not unanimously, to be very specific to the

land sector only and hence outside their scope of work as indicated above. None-

the-same, they have been reported in Annex D for further future EDSTAR follow-on

work on system architecture.

Characterisation of each candidate document – in order to aggregate the identified

documents under a coherent frame suitable for further detailed analysis, the group

identified and agreed on specific criteria with respect to scope and domain and to

relevance for "system architecture”. A dedicated spreadsheet was constructed for

coherence of classification comprising the following headings (columns):

Commonality of use of the given standard by the participating nations France (Fr) and

Italy (It)

Relevance of the selected document in respect of system architecture:

F: Full document, the whole document is relevant

P: partial, only a part of the document is relevant

Two macro areas :

1a - System architecture and architecting

1b -Enterprise architecture

Page 14

Scope, i.e. Ways to Structure the architecture of the systems:

2a. Integrated architecture (Architecture intégrée)

2b. Modular architecture (Architecture modulaire)

2c. Federate architecture (Architecture fédérée)

2d. Distributed architecture (Architecture distribuée)

2e. Open architecture (Architecture ouverte)

Classification, five criteria:

Process

Method

Description / Formalism

Evaluation

Vocabulary

A set of four categories (imposed by EDSTAR methodology):

HS - Horizontal/transversal standards (fundamental/generic/systems/method)

MS - Management/organization standard/conformity assessment

IS - Interop/Interface standards

TS - Technical/performance standards

Typology of application:

Usage

Domain

Basic characteristics providing added-value to system architecting:

Interoperability

Integration

Reusability

Quality factors of standards – e.g. Efficiency, Security, Maintainability …

The above criteria provided the mean to identify the added-value of documents in terms of

benefits for the acquisition of system architectures

Final experts' characterisation and selection

The final result of the complete standard review process is reported on the related

spreadsheet, named EG 20 internal standards candidate-list, see ANNEX B enclosed.

EG 20 analysed more than sixty standards or standard-like documents. After the review,

24 documents were selected as recommendation for use as Best Practice Standards.

Page 15

Rejected standards or standard-like documents are kept in the EG 20 internal standards

candidate-list in order to:

Keep the history and evidences of the work done

Provide an answer if questions are raised on particular non-selected documents.

4.2.Rationale for selection criteria

Criteria for this standard selection have been studied according to a classic set of questions

that can be asked about any kind of activities. In particular this questioning can be found in

the Zachman’s model1 when it comes to Architecture Framework. In particular questions

could be formalised as follow:

Why? I.e. why are Architecture related activities done?

When? I.e. when do these activities have to be done?

Who? I.e. who is involved in these activities?

What? I.e. what are the inputs and outputs?

Where? I.e. where can/may/must these activities be done?

With what? I.e. what are the means/resources to perform these activities?

From this set of questions, EG 20 analysed how standards could answer the questions and

the relevance regarding the objectives of the standard selection. The following criteria were

identified:

Process: processes formalise when and why architecture-related activities have to

be done over life cycles.

Method: methods describe how these activities are to be done and who is

concerned or involved in them.

Description or formalism: formalisms express what is to be described in architecture

artefacts.

Vocabulary and languages: they provide with what terminology and syntax activities

can be performed.

NOTE: As anticipated in Scope Consolidation subchapter 3.2 the EG 20 study does

not address languages for architecture-description or modelling to a significant

extent. Nevertheless, the team identified some of them in Annex C – Architecture

Languages.

Repositories and reference systems: Architecture repositories and Architecture

reference system were identified by EG20 as an important criterion to qualify where

architectures, libraries of patterns and building blocks, and architecting standards

can be exposed as references for projects within organisation. However, this topic

1 See http://www.zachman.com/about-the-zachman-framework

http://www.zachman.com/about-the-zachman-framework

Page 16

was not considered as a concern related to acquisition.

NOTE: for this reason, architecture frameworks and references like FEAF and

AGAF where not analysed.

Evaluation: is an additional criterion identified by EG20 as being transverse to the

previous one since anything (activities, outcomes, resources, means, etc) can be

evaluated as long as it can be analysed with regards to the requirements.

4.3.Final experts’ review process

The process followed to arrive at the identification of the best practice standards is based on

the guidelines provided by EDSTAR document titled ”EG Guidance 20 June 2013_ Guidance

for Expert Groups on the selection of standards and the provision of associated

recommendations” (see EDSTAR website2: Framework document - guidance on selection of

standards for expert groups – version June 2013)”; and the experts' review and relevance

analysis following the characterisation process of each candidate documents.

At the end of this selection step, EG 20 compiled the EDSTAR final spreadsheet with a focus

on comments. In this column, EG 20 evidenced the major characteristics which lead to the

selection of the best practice documents.

2 http://www.eda.europa.eu/EDSTAR/Libraries/Standards_Docs/Framework_paper_for_Expert_Groups_on_selection_of_standards_and_the_provision_of_associated_recommendations.sflb.ashx

http://www.eda.europa.eu/EDSTAR/Libraries/Standards_Docs/Framework_paper_for_Expert_Groups_on_selection_of_standards_and_the_provision_of_associated_recommendations.sflb.ashx

Page 17

5. Recommendations on application and tailoring of a standard

5.1.List of documents

This list gives the page number of the standard and standard-like document selected in this

report.

ANSI/EIA 632:1999 ..............................................................................................................21 EN 60812 .............................................................................................................................39 HFM-RTO-155......................................................................................................................42 INCOSE Systems Engineering Handbook V3.2 ........................................................ 25, 32, 46 ISO 15704 ...................................................................................................................... 31, 43 ISO/CEI TR 24748-1 ............................................................................................................30 ISO/CEI TR 24748-2 ...................................................................................................... 26, 30 ISO/IEC 15289 .....................................................................................................................22 ISO/IEC 15408 .....................................................................................................................37 ISO/IEC 20000-1 ............................................................................................................ 28, 46 ISO/IEC 26702 ............................................................................................................... 22, 30 ISO/IEC 27000 – series ............................................................................................ 35, 44, 46 ISO/IEC 90005:2008 ............................................................................................................26 ISO/IEC/IEEE 24765 ............................................................................................................45 ISO/IEC/IEEE-15288 ............................................................................................................19 ISO/IEC/IEEE-42010 ...................................................................................................... 40, 45 NATO Architecture Framework, Version 3 ...................................................................... 41, 45 prEN 9277 ............................................................................................................................27 prEN 9320 ................................................................................................................ 27, 34, 46 SEBoK - System Engineering Body of Knowledge ................................................... 26, 33, 46 STANAG 4603.......................................................................................................... 23, 42, 45 STANAG 4728 AAP-48:2013 ................................................................................................20 The Open Group Architecture Framework (TOGAF) ...................................................... 25, 30 UPDM formal/2013-08-04 .....................................................................................................43

5.2. Methodology of presentation

Just as several other EDSTAR expert groups, EG 20 described each standard or standard-

like document following the undermentioned breakdown:

- Scope

- Why chosen as best practice?

- Classification criteria

- How to use it?

- What is missing?

However the selected standards offer several alternatives for ordering priorities. EG 20 opted

for two basic classification criteria:

Page 18

The first classification criterion adopted consists in grouping the selected standards

according to the work process classification indicated at the previous subchapter 4.1

I.e. Process; Method; Vocabulary; Description/Formalism and Evaluation.

The second criterion applies to each of the classes adopted in the previous

subchapter and further re-organises the selected standards in three major families

according to the strength of reference. I.e. G=Guidance; A= to be Applied;

F = Future evolution expected.

NOTE: No document was identified in the F category.

When a given standard addresses several criteria, the dominating one is evidenced first in

the line and in bold letters.

The summary characterisation map is given in the following figure.

Figure 1: EG 20 Characterisation MAP for identified standards - Summary Table

NOTE: The dominating criterion not shown in the map is identified in the table detailing each

standard or standard-like document.

ProcessISO/IEC/IEEE-15288

STANAG 4728 AAP-48

ANSI/EIA-632

ISO/CEI/IEEE 15289

ISO/CEI TR 90005

prEN 9277

MethodISO/IEC TR 24748-1 ISO/CEI 26702 (from IEEE 1220)

ISO IEC 15408 ISO/IEC TR 24748-2

EN 60812 TOGAF V9

ISO 15704

INCOSE SE Handbook VocabularyISO/IEC 27000 series SEBoK ISO/IEC/IEEE 24765

prEN 9320

ISO/IEC/IEEE-42010 STANAG 4603 ISO 20000 - series

NAF V3

UPDM

Evaluation HFM-RTO-155

Description/Formalism

Page 19

5.3.Classification Criteria

5.3.1.Process

5.3.1.1.Strength of reference: A

Recommendation(s)

Standard (or set of standards): Identification, scope and information on the source

ISO/IEC/IEEE-15288: 2008: Systems and software engineering -- System life cycle processes

Scope: This International Standard establishes a common framework describing the life cycle of systems created by humans. It defines a set of processes and associated terminology. These processes can be applied at any level in the hierarchy of a system’s structure. Selected sets of these processes can be applied throughout a system's life cycle to manage and perform its stages. This is accomplished through the involvement of all interested parties, with the ultimate goal of achieving customer satisfaction. This International Standard also provides processes that support the definition, control and improvement of the life cycle processes used within an organization or a project. Organizations and projects can use these life cycle processes when acquiring and supplying systems. This International Standard concerns those systems that are man-made and may be developed with one or more of the following: hardware, software, data, humans, processes (e.g., processes providing service to users), procedures (e.g., operator instructions), facilities, materials and naturally occurring entities. When a system element is software, the software life cycle processes documented in ISO/IEC 12207:2008 may be also considered to implement that system element. The two standards are harmonized for concurrent use on a single project or in a single organization.

Source: http://www.iso.org/iso/

Why chosen as best practice?

In this Standard describing the processes sustaining the life cycle of a system, one process is formalised for Architectural Design. It explains how the architecture is defined during the design and how the design can consolidate the Architecture. Note: in this Standard, a system is anything worked with a systemic approach. It could be an enterprise, a system of systems, an equipment, a piece of equipment, a tangible or intangible product, a piece of software or hardware, etc.

Classification criteria: PROCESS

How to use it (them)?

This Standard should be used as complement of ISO/IEC/IEEE-42010 to get a core explanation of what Architecting means in terms of activities.

What is missing?

In the ISO/IEC/IEEE-15288:2008 version, Architecture is seen as the result of the Architectural Design which is a very limited view of what Architecture is. A new update of the 15288 is under writing in order to add an “Architecture Definition” process in addition to a “Design Definition” process. The Standard and its new coming version provide a very high-level of description of the Architecture related activities (a couple of pages only) which is far from being sufficient to explain the work of the Architect. Document like TOGAF (See http://www.opengroup.org/architecture/togaf ) provides much more substantial information; but this description is currently limited to Enterprise Information Systems.

http://www.iso.org/iso/

http://www.opengroup.org/architecture/togaf

Page 20

Recommendation(s)


STANAG 4728 AAP-48:2013: Allied Administrative Publication 48 – NATO System lifecycle processes

Scope: STANAG 4728 AAP-48:2013 refers to ISO/IEC/IEEE-15288:2008 Section 1.1 “Scope”. AAP-48 serves as guidance for implementing NATO's System Life Cycle Management (SLCM) Policy. It establishes a common framework for describing and implementing life cycle management for NATO armament systems. NATO Policy for SLCM confirms the usage of ISO/IEC/IEEE-15288 as a basis to implement SLCM. The purpose of AAP-48 is to provide guidance on the implementation of SLCM, which is used to mitigate risk, reduce acquisition times and to identify, quantify and control Life Cycle Cost, from the earliest possible opportunity. SLCM will ensure that the processes used across projects are consistent, harmonized, and that there is effective sharing and co-ordination of resources, information and technologies. This publication defines a set of stages, processes and associated terminology. Complemented by the enabling frameworks and tailored accordingly, these stages and processes are used to achieve the identified stakeholders’ requirements and support an organisations specific needs of attaining customer satisfaction

Source: http://nsa.nato.int/

Why chosen as best practice? This Standard complements the ISO/IEC/IEEE-15288:2008 with: ‐ “Through-Life Traceability Management” and “Support” processes. ‐ NATO references (AAPs, AACPs, AQUAPs, and STANAGs) to be considered in the

scope of this Standard. ‐ Additional text is also provided to NATO specificities in relation with the NATO

references.


How to use it (them)? This Standard should be used as complement of ISO/IEC/IEEE-42010 and ISO/IEC/IEEE-15288:2008 to get a core explanation of what Architecting means in terms of activities

What is missing? Same as ISO/IEC/IEEE-15288:2008, in the AAP-48:2013, Architecture is seen as the result of the Architectural Design which is a very limited view of what Architecture is. As a new update of the 15288 is under writing to add an “Architecture Definition” process in addition to a “Design Definition” process, the AAP-48 will certainly incorporate these additions. The Standard and its new coming version provide a very high-level of description of the Architecture related activities (a couple of pages only) which is far from being sufficient to explain the work of the Architect. Document like NAF and TOGAF provides much more substantial information; but this description is currently limited to Enterprise Information Systems.

http://nsa.nato.int/

Page 21

Recommendation(s)


ANSI/EIA 632:1999: Processes for Engineering a System Scope: The purpose of this Standard is to provide an integrated set of fundamental processes to aid a developer in the engineering or reengineering of a system. Use of this Standard is intended to help developers: a) Establish and evolve a complete and consistent set of requirements that will enable

delivery of feasible and cost-effective system solutions;

b) Satisfy requirements within cost, schedule, and risk constraints;

c) Provide a system, or any portion of a system, that satisfies stakeholders over the life of

the products that make up the system.

NOTE - The term product is used in this standard to mean: a physical item, such as a satellite (end product), or any of its component parts (end products); a software item such as a stand-alone application to run within an existing system (end product); or a document such as a plan, or a service such as test, training, or maintenance support, or equipment such as a simulator (enabling products). d) Provide for the safe and/or cost-effective disposal or retirement of a system

Source: http://standards.sae.org/

Why chosen as best practice? This Standard is recommended to complement the ISO/IEC/IEEE-15288 regarding mainly the following topics: product, building block, enabling product, enterprise and business application of the engineering activities.


How to use it (them)? This document should be used as complement of the ISO/IEC/IEEE-42010 and ISO/IEC/IEEE-15288 to get a core explanation of what Architecting and design mean in terms of activities.

What is missing? This document does not really explain what architecture is. The term “architecture” is limited to “system architecture” and is mainly understood as the result of design activities. I.e. detailed architecture.

http://standards.sae.org/

Page 22

Recommendation(s)


ISO/IEC 26702:2007 – IEEE Std 1220-2005 Application and management of the systems engineering process

Scope: The concept of systems engineering embodied in this standard provides an approach for product development in a system context. It is not meant to describe what an organizational entity called systems engineering does or a job position for which a systems engineer is responsible. Rather, it encompasses what all organizational entities and all enterprise and project personnel must accomplish to produce a quality, competitive product that will be marketable, will provide an acceptable return on investment to the enterprise, will achieve stakeholder satisfaction, and will meet public expectations. Source: http://www.iso.org/iso/

Why chosen as best practice? This document is a detailed description of an implementation of the ISO 15288:2002. It is a Standard for application and management of the systems engineering process. It covers process and methodology in the field of system engineering.

Classification criteria: PROCESS, METHOD

How to use it (them)? This document should be used to set up and manage a system engineering process. This involves developing, producing, testing, and supporting an integrated set of products (hardware, software, people, data, facilities, and material) and processes (services and techniques) that is acceptable to stakeholders, satisfies enterprise and external constraints, and considers and defines the processes for developing, producing, testing, handling, operating, and supporting the products and life cycle processes

What is missing? The document covers all engineering activities and not specifically architecture part.

Recommendation(s)


ISO/IEC 15289:2011: Systems and software engineering -- Content of life-cycle information products (documentation)

Scope: This International Standard provides requirements for the identification and planning of the specific information items (information products, documentation) to be developed and revised during systems and software life cycles, and in-service processes. It specifies the purpose and content of all identified systems and software life-cycle; and in-service management information items (documentation). The information item contents are defined according to generic document types, and the specific purpose of the document. Source: http://www.iso.org/iso/

Why chosen as best practice? This International Standard identifies records and information items based on analysis of



Page 23

references in ISO/IEC 15288:2008 (IEEE Std 15288-2008), ISO/IEC 12207:2008 (IEEE Std 12207-2008), ISO/IEC 20000-1:2005 and ISO/IEC 20000-2:2005. It provides a complete outline of a consistent set of information items associated to a life-cycle process.


How to use it (them)? This document should be used to address the technical information needed by those involved in system, service and software life cycle processes, to specify information in an agreement process or a two-party situation, to develop information items that provide evidence for process assessment and to guide process improvement activities.

What is missing? The document covers all engineering activities and not specifically architecture part.

Recommendation(s)


STANAG 4603:2008 - Modelling and simulation architecture standards for technical interoperability: High Level Architecture (HLA)

Scope: The aim of this agreement is to facilitate system-level interoperability within and between all Level 3 (Command and Staff), Level 2 (Tactical), and Level 1 (Individual and Crew) operational, training and analytical modelling and simulation systems developed by, and located in, different NATO Nations. The STANAG also addresses the transition from HLA Version 1.3 developed by the U.S. Department of Defense to the IEEE 1516 series of standards.

Source: http://nso.nato.int/nso/zPublic/stanags/4603eed01.pdf

Why chosen as best practice? System-level interoperability within the chain of command, training, analytical modelling and simulation systems in single locations or in federated locations across NATO Nations is a must for command functions in an age of network enabled operations.

Following the order of preference given by EN 16341, beyond standards and other standard-like documents, which are referenced in laws, ordinances and statutory provisions, International Military Alliances Standards (STANAG) are to be considered as the best next option.

Furthermore, STANAG 4603 promulgated in July 2008, has incorporated the evolutionary process of the IEEE 1516.3 and Simulation Interoperability Standards Organisation (SISO) ensuring high interoperability and reuse of models and simulations across the Alliance, extended XML support, fault tolerance support services, encoding helpers, support for transportability (e.g QoS, IPv6..) standardised time representation. This new version ensures interoperability between RTIs (Run-Time Infrastructures).

Classification criteria: PROCESS, DESCRIPTION, VOCABULARY

How to use it? HLA provides the way to engineer modelling and simulation infrastructure sustaining the systems architecting activities.

http://nso.nato.int/nso/zPublic/stanags/4603eed01.pdf

Page 24

STANAG 4603 is intended to facilitate system-level interoperability within and between Command, Tactical and Operational, training and analytical modelling and simulation systems developed by, and located in, different NATO Nations. It is based on a general purpose high-level architecture (HLA), for distributed computerized simulation systems. Using HLA, computer simulations can interact (that is, communicate data, and synchronize actions) with other computer simulations regardless of computing platforms. The interaction between simulations is managed by a Run-Time Infrastructure (RTI). HLA is an interoperability standard for distributed simulation used to support analysis, engineering and training in a number of different domains such as: Defence, Space, Air Traffic Management, Energy, Off-shore, Railway and car industry, Manufacturing, Health care.

What is missing? HLA is defined as a set of services, provided by a C++ or Java API. There is no standardisation on-the-wire protocol. Participants in a federation must use RTI libraries from the same provider and usually also of the same version in order for applications to interoperate.

Page 25

5.3.1.2.Strength of reference: G

Recommendation(s)


The Open Group Architecture Framework (TOGAF) – The Open Group Scope: The Open Group Architecture Framework (TOGAF) provides a system / enterprise architecture development method and an organisational model to structure Enterprise reference systems and Architecture repositories. Its method is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets. At the enterprise level, it gives information to set up content frameworks, architecture repositories, and product/system portfolios. It explains how to manage skills and competences, tools, organisation. Source: http://www.togaf.org/togaf9/

Why chosen as best practice? TOGAF provides a generic framework focusing on a methodology that could be combined with other frameworks (e.g. NAF), addressing formalisms or processes. TOGAF helps also to "demystify" and de-risk the architecture development process.

Classification criteria: PROCESS, METHOD

How to use it (them)? TOGAF method helps defining processes and methods to allow architectures development, usages and maintenance. It gives due consideration both to current requirements and to the likely future needs of the business. TOGAF landscape has to be populated with the enterprise libraries of standards and best practices, architecture repositories and product / system portfolios according to the business domains and projects.

What is missing? The primary focus of TOGAF is to manage information system and software-intensive system. TOGAF needs to be complemented with other frameworks and methods that are aimed at specific vertical business domains, at specific horizontal technology areas or at specific application areas.

Recommendation(s)


INCOSE Systems Engineering Handbook V3.2

See § 5.3.2 Method

Page 26

Recommendation(s)


ISO/IEC TR 24748-2:2011: Systems and software engineering — Life cycle management —Part 2: Guide to the application of ISO/IEC 15288 (System life cycle processes)

See § 5.3.2 Method

Recommendation(s)


SEBoK - System Engineering Body of Knowledge V1.3, 2014

See § 5.3.2 Method

Recommendation(s)


ISO/IEC 90005:2008: Guidelines for the application of ISO 9001 to system life cycle processes

Scope: This Technical Report provides guidance for organisations in the application of ISO 9001:2000 for the acquisition, supply, development, operation and maintenance of systems and related support services. It does not add to or otherwise change the requirements of ISO 9001:2000. The guidelines provided in this Technical Report are not intended to be used as assessment criteria in quality management system registration or certification. Source: http://www.iso.org/iso/

Why chosen as best practice? This document adopts ISO/IEC 15288 systems life cycle processes as a starting point for system development, operation or maintenance and identifies the equivalent requirements in ISO 9001:2000 that have a bearing on the implementation of ISO/IEC 15288.


How to use it (them)? This document should be used to take benefits of both ISO 9001 and ISO 15288. It ensures good understanding and consistency in their implementation.

What is missing? This Technical Report provides guidance for software intensive systems. For guidance in software development, operation and maintenance see the companion document ISO/IEC 90003.


Page 27

Recommendation(s)


prEN 9277: Aerospace series - Program management. Guide for the management of system engineering

Scope (from the report): The purpose of this standard is: ‐ To help the acquirer and the Organization to establish management requirements for

Systems Engineering (SE) activities, ‐ To help the supplier to construct the elements of the management plan (explain how to

reply in particular to the management requirements). This standard applies to various levels of the product tree for the products that can be considered as systems: ‐ in the general case of supplier who, with the help of one or more suppliers, develops a

system on behalf of an acquirer, ‐ in the case of an integrated team (sharing of SE roles, responsibilities and risks). Source: http://www.asd-stan.org/

Why chosen as best practice? This document provides guidelines about the “Organisational Project-Enabling Processes” and the “Project Processes” described in the ISO/IEC/IEEE-15288:2008.


How to use it (them)? This standard constitutes a guide illustrating the requirements and possible responses for Systems Engineering management. It can be used as a check-list which should be adapted or completed according to the specific context of each project. The management requirements described in the Guide are to be related to: ‐ Key-requirements elaborated or refined during the Architecting activities. ‐ Stakeholders’ views (e.g. Acquirer view) of the Architecture. ‐ The Architecting activities performance to get a project consistency.

What is missing? This guide does not identify the Architecting activities as providing inputs for Systems Engineering management. It is only stating Stakeholders’ needs to be satisfied by Systems Engineering activities and their management. The “Enterprise Functions” listed in this document do not include currently Architecting or Architecture Definition. However since the list of “Enterprise Functions” is defined with an “Etc”, extension is allowed.

Recommendation(s)


prEN 9320: Aerospace series – Programme Management – General guidelines for acquisition and supply of open systems

See § 5.3.2 Method

http://www.asd-stan.org/

Page 28

Recommendation(s)


ISO/IEC 20000-1:2011 Information technology — Service management — Part 1: Service management system requirements Scope: Currently ISO/IEC 20000 series is organized into 11 parts: ‐ Part 1: Service management system requirements

‐ Part 2: Guidance on the application of service management systems

‐ Part 3: Scope definition and applicability of ISO/IEC 20000-1

‐ Part 4: Process Reference Model

‐ Part 5: Exemplar Implementation Plan for ISO/IEC 20000-1

‐ Part 6: Requirements for bodies providing audit and certification of service

management systems

‐ Part 7: Guidance on the application of ISO/IEC 20000-1 to the cloud

‐ Part 8: Guidance on the application of service management systems for smaller

organizations

‐ Part 9: Guidance on the application of ISO/IEC 20000-1 to cloud services

‐ Part 10: Concepts and Terminology

‐ Part 11: Guidance on the relationship between ISO/IEC 20000-1 to related

frameworks

Part 1 is a service management system (SMS) standard. It specifies requirements for the service provider to plan, establish, implement, operate, monitor, review, maintain and improve a SMS. The requirements include the design, transition, delivery and improvement of services to fulfil agreed service requirements. Source: www.iso.org

Why chosen as best practice? Service can be considered following different axes:

‐ In-service operation of a system ‐ Service as an object of a contract (“System as a Service” or “Systemic analysis of a

service usage”). ‐ Service as a system element (Service is considered as a design paradigm)

Service is to be considered as an architectural element for each different assertion. Service Management is consequently seen either as an operational process (system-external activity) using a system or as a system-internal function. ISO/IEC 20000-1:2011 specifies this activity, process or function.

Classification Criteria: PROCESS, VOCABULARY

How to use it (them)? ISO/IEC 20000-1:2011 can be used by:

‐ an organization seeking services from service providers and requiring assurance that their service requirements will be fulfilled;

‐ an organization that requires a consistent approach by all its service providers, including those in a supply chain;

‐ a service provider that intends to demonstrate its capability for the design, transition, delivery and improvement of services that fulfil service requirements;

‐ a service provider in order to monitor, measure and review its service management processes and services;

http://www.iso.org/

Page 29

‐ a service provider in order to improve the design, transition, delivery and improvement of services through the effective implementation and operation of the SMS;

‐ an assessor or auditor as the criteria for a conformity assessment of a service provider's SMS to the requirements in ISO/IEC 20000-1:2011.

What is missing? The ISO/IEC 20000 series mainly addresses the Information Technology Domain. An extension and transposition is necessary to address more generic operational process or system function. Note: this transposition has been done within some NATO programs. Wording of ISO/IEC 20000 is significantly different from the major references of Systems Engineering and Architecture Frameworks.

Page 30

5.3.2.Method


Recommendation(s)


ISO/IEC 26702:2007 – IEEE Std 1220-2005: Application and management of the systems engineering process

See § 5.3.1 Process


Recommendation(s)


The Open Group Architecture Framework (TOGAF) – The Open Group


Recommendation(s)


ISO/IEC TR 24748-1:2010: systems and software engineering - Life cycle management - Part 1: Guide for life cycle management ISO/IEC TR 24748-2:2011: Systems and software engineering — Life cycle management —Part 2: Guide to the application of ISO/IEC 15288 (System life cycle processes)

Scope: This Technical Reports series provides guidance for life cycle management of systems and software based on ISO/IEC 15288 and ISO/IEC 12207. The TR 24748-1:

‐ addresses system concepts and life cycle concepts, models, stages, processes, process

application, key points of view, adaptation and use in various domains;

‐ establishes a common framework for describing life cycles, including their individual

stages, for the management of projects in order to provide or acquire either products or

services;

‐ defines the concept and terminology of a life cycle;

‐ supports the use of the life cycle processes within an organization or a project.

Organizations and projects can use these life cycle concepts when acquiring and

supplying either products or services;

‐ provides guidance on the adaptation of a life cycle model and the content associated with

a life cycle or a part of a life cycle;

‐ describes the relationship between life cycles and their use in ISO/IEC 15288 (systems

aspects) and ISO/IEC 12207 (software aspects);

‐ shows the relationships between life cycle concepts and the hardware, human, services,

process, procedure, facility and naturally occurring entity aspects of projects;

‐ describes how its concepts relate to detailed process standards, for example, in the

areas of measurement, project management and risk management;

Page 31

‐ complements domain-specific application guidance in ISO/IEC TR 19760 and ISO/IEC

TR 15271.

NOTE When published, ISO/IEC TR 24748-2 and ISO/IEC 24748-3 will cancel and replace ISO/IEC TR 19760 and ISO/IEC TR 15271, respectively.

TR 24748-2 is a guide for the application of ISO/IEC 15288:2008. It addresses system, life cycle, process, organizational, project, and adaptation concepts, principally through reference to ISO/IEC TR 24748-1 and ISO/IEC 15288:2008. It then gives guidance on the application of ISO/IEC 15288:2008 about the aspects of strategy, planning, application in organizations, and application on projects. ISO/IEC TR 24748-2 is intentionally aligned with both ISO/IEC TR 24748-1 and ISO/IEC TR 24748-3 (Guide to the application of ISO/IEC 12207) in its terminology, structure and content. Source: http://www.iso.org/iso/

Why chosen as best practice? This Guide explains how a life cycle can be managed for a particular case of system / Project; and therefore how life cycle activities can be organized.

Classification criteria: METHOD, PROCESS

How to use it (them)? This Guide should be used to profile the life cycle of a system or software to be architected.

What is missing? These Guides are in line with the ISO/IEC/IEEE-15288:2008. In this 15288:2008 version, the description of the architecture development is limited to the “Architecture design” process. New update of the ISO/IEC TR 24748-1, -2 and -3 will start in 2015 to align this Guide with the new release of the 15288 (expected to be issued in 2016). The update will introduce new processes on: Business and Operational Analysis, and Architecture Definition.

Recommendation(s)


ISO 15704:2000: Industrial automation systems -- Requirements for enterprise-reference architectures and methodologies ISO 15704/A1:2005: AMENDMENT 1: Additional views for user concerns

Scope : This International Standard defines the requirements for enterprise-reference architectures and methodologies, as well as the requirements that such architectures and methodologies must satisfy to be considered as a complete enterprise reference architecture and methodologies. The scope of these enterprise-reference architectures and methodologies covers those constituents deemed necessary to carry out all types of enterprise creation projects as well as any incremental change projects required by the enterprise throughout the whole life of the enterprise, including a) Enterprise creation,

b) Major enterprise restructuring efforts, and


Page 32

c) Incremental changes affecting only parts of the enterprise-life cycle.


Why chosen as best practice? This Standard addresses Enterprise Architecture and Enterprise processes with two meanings: ‐ The Enterprise in charge of Development of the “System-of-Interest”. In this case, the

Enterprise is the organization including all the Stakeholders of the “System-of-Interest”.

‐ The Enterprise as the Operational organization including the “System-of-Interest” and its

human and technical ecosystem in charge of performing the operational process.

Classification criteria: METHOD, DESCRIPTION

How to use it (them)? This Standard provides simple foundation to perform Enterprise Architecting with a clear set of terms, concepts and framework components. It could be used as an introduction for larger methods like TOGAF.

What is missing? This Standard is currently not aligned with newer references like ISO/IEC/IEEE-42010:2011, TOGAF, NAF, etc. The amendment 1 is not in line with newer references addressing human views in architecture like HFM-RTO-155:2008.

Recommendation(s)



Scope: The objective of the INCOSE Handbook is to provide a description of key-process and activities performed by systems engineers. It defines the discipline and practice of systems engineering (SE) for student and practicing professional alike. This handbook provides an authoritative reference to understand the discipline in terms of content and practice. Source: http://www.incose.org/

Why chosen as best practice? This document is consistent with ISO/IEC 15288:2008 – Systems and software engineering – System life cycle processes to ensure its usefulness across a wide range of application domains – man‐made systems and products, as well as business and services.

Classification criteria: METHOD, PROCESS, VOCABULARY

How to use it (them)? This document should be used to reference practices and methods that have proven beneficial to the SE community at large and that can add significant value in new domains if appropriately selected and applied.

What is missing? In this version, this document covers other issues beyond architecture and the separation is not very well identified.


http://www.incose.org/

Page 33

NOTE: regarding the fact that version 4 will be aligned with the next version of ISO 15288, we can expect a dedicated chapter to architecture.

Recommendation(s)



Scope: The SEBoK provides a compendium of the key-knowledge sources and references of systems engineering that are organized and explained in order to assist a wide variety of users. It is a living document, accepting community input continuously, with regular refreshes and updates. The SEBoK is organized into 7 parts, with a Glossary of Terms and a list of Primary References. ‐ Part 1 discusses the SEBoK's scope and structure, including its hierarchy of parts,

knowledge areas, and topics. Part 1 also includes a lengthy discussion of SEBoK Users

and Uses, including five use cases.

‐ Part 2 Systems

‐ Part 3 Systems Engineering and Management

‐ Part 4 Applications of Systems Engineering

‐ Part 5 Enabling Systems Engineering

‐ Part 6 Related Disciplines

‐ Part 7 Systems Engineering Implementation Examples

Source: www.sebokwiki.org

Why chosen as best practice? This document is a set of best practices, definitions and artefacts in the field of system engineering and including architecture subject. It covers process and methodology definition in the field of system and enterprise architecture.

Classification Criteria: METHOD, PROCESS, VOCABULARY

How to use it (them)? This document is not a reference document and should be used as a support to benefit from previous best practices, definitions and artefacts in related domains. The content needs to be adapted to specific situations.

What is missing? Architecture activity is not identified in each part of the body of knowledge but is rather seen as fully integrated in the system engineering process. As a body of knowledge, the different contributions are not always fully consistent.

http://www.sebokwiki.org/

Page 34

Recommendation(s)


prEN 9320 : Aerospace series – Programme Management – General guidelines for acquisition and supply of open systems

Scope (from the report): This document deals specifically with the concept of open systems. To this end, through the various processes applied of the system life cycle as defined in the ISO/IEC 15288, it provides information to stakeholders (buyers, suppliers, designers, subcontractors, supervisors, etc.) on the best practice to be adopted. Source: http://www.asd-stan.org/

Why chosen as best practice? This document is consistent with ISO/IEC 15288:2008 and adds general guidelines to cover open system acquisition and supply processes. It is a guide to face increasing requirement for systems designed and produced by industry. The proposed standard helps to develop interoperability both internally (within the systems) and externally (with other partners), including, by way of an example: - Ability of each stakeholder and each department involved to maintain efficient and trusting relationships with other stakeholders, taking into account deadline, cost and quality objectives, - Ability to exchange, communicate and use the necessary flows (data, information, knowledge, materials, energy) autonomously, without error and dynamically throughout the life cycle of the target system, - Ability to coordinate, synchronise and manage common tasks and share and use resources (human, machine or application) and services efficiently and appropriately.

Classification criteria: METHOD, PROCESS, VOCABULARY

How to use it (them)? This document should be used as a guide in support of ISO/IEC 15288, and in relation with other systems designed, produced, acquired and operated independently, to answer the increasing requirement for systems designed and produced by industry in the aeronautic, space and defence fields, and to be used with other systems designed, produced, acquired and operated independently. It applies during all of a system life cycle including the architecture activity.

What is missing? No specific guideline is identified for architecture but it is included in the global system engineering approach.

http://www.asd-stan.org/

Page 35

Recommendation(s)


ISO/IEC 27000 – series :

- ISO/IEC 27000, Information security management systems — Overview and vocabulary

- ISO/IEC 27001, Information security management systems — Requirements - ISO/IEC 27002, Code of practice for information security controls - ISO/IEC 27003, Information security management system implementation

guidance - ISO/IEC 27004, Information security management — Measurement - ISO/IEC 27005, Information security risk management - ISO/IEC 27006, Requirements for bodies providing audit and certification of

information security management systems - ISO/IEC 27007, Guidelines for information security management systems

auditing - ISO/IEC TR 27008, Guidelines for auditors on information security controls - ISO/IEC 27010, Information security management for inter-sector and inter-

organizational communications - ISO/IEC 27011, Information security management guidelines for

telecommunications organizations based on ISO/IEC 27002 - ISO/IEC 27013, Guidance on the integrated implementation of ISO/IEC 27001

and ISO/IEC 20000-1 - ISO/IEC 27014, Governance of information security - ISO/IEC TR 27015, Information security management guidelines for financial

services - ISO/IEC TR 27016, Information security management — Organizational

economics Scope: The ISO and IEC jointly publish a set of standards describing organizational Information Security Management System (ISMS) and the security controls such systems contain. In the ISMS context, the word system denotes a set of explicit, standard, repeatable processes and activities for security management, not a type of technology solution. The ISMS family of standards includes standards that:

a. define requirements for an ISMS and for those certifying such systems; b. provide direct support, detailed guidance and/or interpretation for the overall

process to establish, implement, maintain and improve an ISMS; c. address sector-specific guidelines for ISMS; and d. address conformity assessment for ISMS.

The terms and definitions provided in this International Standard:

- cover commonly used terms and definitions in the ISMS family of standards; - do not cover all terms and definitions applied within the ISMS family of standards;

and - do not limit the ISMS family of standards in defining new terms for use.


Why chosen as best practice? ISO 27000 series is a family of Information Security management standards. The traditional


Page 36

view of information security includes the three cornerstones of information security: confidentiality, integrity, and availability, also known as the CIA of information security. Confidentiality, integrity, and availability are security objectives when the intent of confidentiality is to ensure that only authorized personnel may access information or, to the contrary, ensure that information is not disclosed to unauthorized persons or entities (e.g., automated system or service). ISO 27000 series tries to guide an organization in the management of information security and the three cornerstones of security by implementing an effective ISMS. PDCA (Plan, Do, Check and Act) provides the methodology to implement an ISMS. ISO 27002 (formerly ISO 17799) provides the foundation for an effective ISMS, and ISO 27001 provides guidance on how to implement an ISMS via the PDCA process.

Classification criteria: METHOD, EVALUATION, VOCABULARY

How to use it (them)? The series is deliberately broad in scope, covering more than just privacy, confidentiality and IT or technical security issues. It is applicable to organizations of all shapes and sizes. All organizations are encouraged to assess their information security risks, then implement appropriate information security controls according to their needs, using the guidance and suggestions when relevant. Given the dynamic nature of information security, the ISMS concept incorporates continuous feedback and improvement activities, summarized by Deming's "plan-do-check-act" approach, that seek to address changes in the threats, vulnerabilities or impacts of information security incidents. In addition, the 27000 series includes separate standards for implementing ISMS (ISO/IEC 27003), measuring information security management (ISO/IEC 27004), information security risk management (ISO/IEC 27005), and information security governance (ISO/IEC 27014). Standards with specific applicability to auditing including ISO/IEC 27007 and 27008 on auditing ISMS and information security controls, respectively, and ISO/IEC 27006 that specifies requirements for ISMS auditors and certification bodies.

What is missing? ISO 27001 defines methods and practices for implementing information security into an organization with detailed steps. They aim at ensuring reliable and secure communication and data exchange in organization. In addition, it highlights a risk approach to the accomplishment of its objectives. This standard dives deep into the means to implement its sub-goals. This puts managers who are seeking clarifications on implementation, at an advantage. However, it fails to achieve the goal of integrating into a larger system. It is standalone in nature, and does not function as a complete solution for ISMS.

Page 37

Recommendation(s)


ISO/IEC 15408 - Information technology -- Security techniques -- Evaluation criteria for IT security:

- ISO/IEC 15408-1 : Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 1: Introduction and general model

- ISO/IEC 15408-2 : Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 2: Security functional components

- ISO/IEC 15408-3 : Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 3: Security assurance components

Scope: ISO/IEC 15408-1 (also called Common Criteria or CC) establishes the general concepts and principles of IT security evaluation and specifies the general model of evaluation given by various parts of ISO/IEC 15408 which in its entirety is meant to be used as the basis for evaluation of security properties of IT products. It provides an overview of all parts of the ISO/IEC 15408 series. It describes the various parts of ISO/IEC 15408; defines the terms and abbreviations to be used in all ISO/IEC 15408 parts; establishes the core concept of a Target of Evaluation (TOE); the evaluation context; and describes the audience to which the evaluation criteria are addressed. An introduction to the basic security concepts necessary for evaluation of IT products is given. It defines the various operations by which the functional and assurance components given in ISO/IEC 15408-2 and ISO/IEC 15408-3 may be tailored through the use of permitted operations. The key concepts of protection profiles (PP), packages of security requirements and the topic of conformance are specified and the consequences of evaluation and evaluation results are described. ISO/IEC 15408-1 gives guidelines for the specification of Security Targets (ST) and provides a description of the organization of components throughout the model. Source: http://www.iso.org/iso/

Why chosen as best practice? ISO/IEC 15408 is a useful guide for the development of products and systems with IT security functions and a guide for procurement of commercial products and systems with security functions. Common Criteria provide an added advantage to its security evaluation: they endow international recognition and trust in the quality of the security product.

Classification criteria: METHOD

How to use it (them)? ISO/IEC 15408 is composed of three parts : - Part 1 - Introduction and General Model that defines general concepts and principles of

IT security evaluation and presents a general model of evaluation. This part also includes the constructs in order to express IT security objectives, the selection and the definition of IT security requirements, and to write high-level specifications for products and systems. In addition, it provides the usefulness of each part of the CC in terms of each of the target


Page 38

audiences. - Part 2 - Security Functional Requirements. This part establishes a set of security

functional components as a standard way of expressing the security requirements for IT products and systems. The catalogue is organized into classes, families, and components.

- Part 3 - Security Assurance Requirements. This part establishes set of assurance components that can be used as a standard way of expressing the assurance requirements for IT products and systems. Part 3 catalogue is organized into the same class - family - component structure. Part 3 also defines evaluation criteria for PPs and STs. Part 3 presents the seven Evaluation Assurance Levels (EALs), which are predefined packages of assurance components that make up the CC scale for rating confidence in the security of IT products and systems.

This document should be used as a complement of the ISO/IEC 18045 to get a methodology for security evaluation adapted for IT domain. ISO/IEC TR 19791 provides guidance and criteria for the security evaluation of operational systems. It provides an extension to the scope of ISO/IEC 15408 by taking into account a number of critical aspects of operational systems not addressed in ISO/IEC 15408 evaluation. The principal extensions that are required address evaluation of the operational environment surrounding the target of evaluation, and the decomposition of complex operational systems into security domains that can be separately evaluated. ISO/IEC TR 19791:2010 provides:

a) a definition and model for operational systems; b) a description of the extensions to ISO/IEC 15408 evaluation concepts needed to

evaluate such operational systems; c) a methodology and process for performing the security evaluation of operational

systems; d) additional security evaluation criteria to address those aspects of operational systems

not covered by the ISO/IEC 15408 evaluation criteria.

What is missing? ISO/IEC 15408 needs to provide a more effective and efficient evaluation methodology. This standard has also to provide mechanisms in order to reduce the cost of evaluation.

Page 39

Recommendation(s)


EN 60812:2006 Analysis techniques for system reliability – Procedure for failure mode and effects analysis (FMEA)

Scope: This standard describes Failure Mode and Effects Analysis (FMEA) and Failure Mode, Effects and Criticality Analysis (FMECA. It gives guidance as to how they may be applied to achieve various objectives by: - providing the procedural steps necessary to perform an analysis; - identifying appropriate terms, assumptions, criticality measures, failure modes; - defining basic principles; - providing examples of the necessary worksheets or other tabular forms. All the general qualitative considerations presented for FMEA will apply to FMECA, since the latter is an extension of the other. Source: http://webstore.iec.ch

Why chosen as best practice? EN 60812 provides an exhaustive nature of the results (failure modes, causes, effects) which involves a systematic approach of the identification of failure modes; it represents the current understanding, at a given moment, of the functioning and failure modes of a system. FMEA approach as described into IEC 60812 can be used to develop a basis of information to define, improve, correct and validate a design, process or method right through from its design to the end of its service life.

Classification criteria: METHOD

How to use it (them)? EN 60812 is a rigorous method for structured systems analysis. It can be used for analysing all kinds of systems, and is often used in the design of hardware, software and process systems. The method is structured around a partition of the system into elements with well-defined function, inputs and outputs. For each element a range of possible failure modes are postulated and analysed for potential effects.

What is missing? FMEA approach is strongly dependent of the structural and functional understanding of the system under study, and hence also on the quality of the preliminary system analysis that has been performed; it is therefore necessary to take particular care during the system analysis phase.

http://webstore.iec.ch/

Page 40

5.3.3.Description/Formalism


Recommendation(s)


ISO/IEC/IEEE-42010:2011: Systems and software engineering — Architecture description

Scope: This International Standard specifies the manner in which architecture descriptions of systems are organized and expressed. A conceptual model formalises relationships between architecture viewpoints, architecture frameworks and architecture description languages for use in architecture descriptions. This International Standard also provides motivations for terms and concepts used; presents guidance on specifying architecture viewpoints; and demonstrates the use of this International Standard with other standards. Source: http://www.iso.org/iso/

Why chosen as best practice? This document provides the core ontology related to Architecture Description: - Definitions of terms and concepts: Architecting, Architecture, Architecture description,

Architecture framework, Architecture view, Architecture viewpoint, Concern, Environment, Model kind, Stakeholder.

- A metamodel to express the relations between the concepts.

Classification criteria: DESCRIPTION, VOCABULARY

How to use it (them)? Terms and concepts of this document are normally agreed by the Architect Community. They could be considered as key-vocabulary to write or understand the framework for architecture description.

What is missing? This standard provides 10 concepts while several tens are generally necessary for architecture description. Ontologies under work, like IDEAS and MODEM, give an order of magnitude for the needed concepts. NOTE: this standard could be complemented by ISO 42030 addressing architecture evaluation. References: - [MODEM, 2013]: Ontological Data Exchange Model (MODEM),

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/63980/20130117_MODAF_MODEM.pdf

- [IDEAS, 2009] International Defence Enterprise Architecture Specification, 30/03/2009, http://www.ideasgroup.org/foundation/

Note: “ISO/IEC-42030 Systems and software engineering — Architecture evaluation” is under writing. This document will provide the core ontology related to Architecture Evaluation in extension of the ISO/IEC/IEEE-42010:

- Definitions of terms and concepts: Architecture evaluation, Architecture evaluation framework, Architecture evaluation objective, Criterion, Value Determination, etc.

- A metamodel to express the relations between the concepts.




http://www.ideasgroup.org/foundation/

Page 41

Recommendation(s)


NATO Architecture Framework, Version 3, Annex 1 to AC/322-D(2007)0048 Scope: The purpose of the NATO Architecture Framework (NAF) is to provide guidance in the description of architectures. Architectures have many stakeholders who have a diversity of needs. The NAF provides an organizing structure for the information contained in an architecture that addresses the needs of these various stakeholders. The application of the NAF will enable architectures to contribute to acquire and fielding cost-effective and interoperable military capabilities. Source: http://nsa.nato.int/

Why chosen as best practice? NAF provides the formalism, rules and products useful to develop and present architecture descriptions that ensure a common denominator in understanding, comparing, and integrating architectures. Furthermore, this ensures a common denominator for understanding, comparing, and integrating architectures.

Classification criteria: DESCRIPTION, VOCABULARY

How to use it (them)? This document should be used to define a common terminology and a set of views.

What is missing? The NAF does not address significantly methodological aspects and does not cover the complete architecture lifecycle and related processes at the requested level of detail.

http://nsa.nato.int/

Page 42

Recommendation(s)


HFM-RTO-155:2008: NATO Human view handbook

Scope: The Human View Handbook enables an understanding of the human role in systems/enterprise architectures. It provides a basis for decisions to stakeholders by providing a structured linkage from the engineering community to the manpower, personnel, training, and human factors communities. It provides a way to manage human system integration into the mainstream acquisition and system engineering process by promoting early and often consideration of human roles. It provides early coordination of task analysis efforts by both system engineering and human factors teams. An accepted Human View enables consistency and commonality across service elements and international forces. By capturing the necessary decision data in the Human View and integrating this view with the rest of the architecture framework, the improved framework provides a complete set of attributes of the system data. Source: https://www.cso.nato.int/

Why chosen as best practice? This document gives definitions of terms, concepts and architecture views enabling the description of Human Views in the Enterprise and System Architectures.

Classification criteria: FORMALISM

How to use it (them) This document can be considered as a guide for third parties offering modelling languages and tools addressing Human Views. However the description is not formal enough to be considered as a specification, either for directly tool development, or exchange of human views between tools. This document is also helpful for Architect as a baseline to ask contributions from the subject matter experts in order to get description of Human Factors.

What is missing? The human views described in this document are not aligned with the NAF formalism. Consequently, currently, no commercial NAF tool (other AF tool) provides an implementation of this description. I.e. this description is sometime (generally partially) used by Industry for extension of the AF formalism. Consequence is a lack of interoperability and possibly a lack of understanding regarding the human views.

Recommendation(s)




https://www.cso.nato.int/

Page 43


Recommendation(s)


ISO 15704:2000: Industrial automation systems -- Requirements for enterprise-reference architectures and methodologies ISO 15704/A1:2005: AMENDMENT 1: Additional views for user concerns

See § 5.3.2 Method

Recommendation(s)


UPDM formal/2013-08-04 – Version 2.1: Unified profile for DoDAF and MODAF (UPDM) (shortly ISO/DPAS 17729)

Scope : UPDM 2.1 provides a profile to enable the extraction of specified and custom views from an integrated architecture description. These views include a system's viewpoint (DoDAF Systems View) along with associated systems implementation standards (DoDAF/MODAF Technical View) within the context of the business or enterprise viewpoint (DoDAF/MODAF Operational View. The profile provides the modelling of operational capabilities, services, system activities, nodes, system functions, ports, protocols, interfaces, performance, and physical properties and units of measure. In addition, the profile enables the modelling of related architecture concepts such as DoD's doctrine, organization, training material, leadership & education, personnel, and facilities (DOTMLPF) and the equivalent UK Ministry of Defence Lines of Development (DLOD) elements.

Source: http://www.omg.org/spec/UPDM/2.1/

Why chosen as best practice? This document provides a comprehensive formalism for the implementation of modelling languages and modellers. The formalism is currently built as a profile (syntax and semantic) close to DoDAF and MODAF.

Classification criteria: FORMALISM

How to use it (them)? This Standard is a specification for third parties offering modelling languages and tools. However this is also a helpful reference document for the users of these languages and tools. It gives a formal description of the formalism allowing better understanding of the user manuals (when existing!) of the languages and tools.

What is missing? UPDM is a compromise between DoDAF and MODAF, with OMG extension. It is not built over IDEAS and MODEM (new foundation for NAF). Consequently this formalism is neither totally compliant with DoDAF, nor MODAF, nor NAF. Some constructs are UML-oriented and not always satisfying for System and Enterprise Architects. However UPDM is becoming more and more popular for architecting in the Software-Intensive domain.

http://www.omg.org/spec/UPDM/2.1/

Page 44

5.3.4.Evaluation


Ø


Recommendation(s)


ISO/IEC 27000 – series :

- ISO/IEC 27000, Information security management systems — Overview and vocabulary

- ISO/IEC 27001, Information security management systems — Requirements - ISO/IEC 27002, Code of practice for information security controls - ISO/IEC 27003, Information security management system implementation

guidance - ISO/IEC 27004, Information security management — Measurement - ISO/IEC 27005, Information security risk management - ISO/IEC 27006, Requirements for bodies providing audit and certification of

information security management systems - ISO/IEC 27007, Guidelines for information security management systems

auditing - ISO/IEC TR 27008, Guidelines for auditors on information security controls - ISO/IEC 27010, Information security management for inter-sector and inter-

organizational communications - ISO/IEC 27011, Information security management guidelines for

telecommunications organizations based on ISO/IEC 27002 - ISO/IEC 27013, Guidance on the integrated implementation of ISO/IEC 27001

and ISO/IEC 20000-1 - ISO/IEC 27014, Governance of information security - ISO/IEC TR 27015, Information security management guidelines for financial

services - ISO/IEC TR 27016, Information security management — Organizational

economics

See § 5.3.2 Method

Page 45

5.3.5.Vocabulary


Recommendation(s)


ISO/IEC/IEEE-42010:2011: Systems and software engineering — Architecture description

See § 5.3.3 Description/Formalism

Recommendation(s)


NATO Architecture Framework, Version 3, Annex 1 to AC/322-D(2007)0048

See § 5.3.3 Description/Formalism

Recommendation(s)





Recommendation(s)


ISO/IEC/IEEE 24765:2010: Systems and software engineering — Vocabulary

Scope: This International Standard provides a common vocabulary applicable to all systems and software engineering work falling within the scope of ISO JTC 1/SC 7. The scope of each concept defined has been chosen to provide a definition that is suitable for general application. In those circumstances when a restricted application is concerned, a more specific definition might be needed. Terms have been excluded if they were: 1. considered to be parochial to one group or organization;

2. company proprietary or trademarked;

3. multi-word terms whose meaning could be inferred from the definitions of the component

words;

4. terms whose meaning in the information technology (IT) field could be directly inferred

from their common English meaning.


Why chosen as best practice? This Standard is providing definitions related to Architecture and Architecting activities.


Page 46

Classification criteria: VOCABULARY

How to use it (them)? This Standard provides the definitions of all the generic terms used in any activity sustaining the whole Systems and Software life cycles. Consequently it can be considered as a basis to understand the Architecting and its context.

What is missing? The Standard is referring significantly to ISO/IEC/IEEE-15288:2008; but does not refer to major Architecture-related standards like ISO/IEC/IEEE-42010 and ISO 15704. It is not aligned with ISO-external reference like TOGAF, NAF or DoDAF.

Recommendation(s)



See § 5.3.2 Method

Recommendation(s)



See § 5.3.2 Method

Recommendation(s)


prEN 9320 : Aerospace series – Programme Management – General guidelines for acquisition and supply of open systems

See § 5.3.2 Method

Recommendation(s)


ISO/IEC 20000-1:2011 Information technology — Service management — Part 1: Service management system requirements


Recommendation(s)


ISO/IEC 27000 – series

See § 5.3.2 Method

Page 47

6. Recommendations for Future Standardization

This current report provides the selection of standards related to both system architecture

and the related activities. The selected standards address totally or partially the targeted

topics; but in any case they are considered as necessary for either performance of the

activities or understanding of architectures.

For the development of this report, the EG 20 only considered the references addressing

generic systems and domains. The shortcomings related to each standard selected are

reported in the respective descriptive table at the previous paragraph 5.3 under the heading

“What is missing”.

Future EDSTAR works are recommended to extend the standard selection in order to cover:

1. Domain-specific architecture and related activities with a particular attention to

open architecture for operating platforms

2. Contributions of the disciplines and specialities to enrich architecture and sustain

related system activities (e.g. architecture description and evaluation with

perspectives like security, safety, human factor, cost, risk, value, performance,

etc.)

3. Architectural quality aspects. I.e. today these quality aspects (Modularity,

openness, etc.) that are currently addressed per domain (E.g. MOSA in Naval

Domain, IMA in avionics, Open System in IT dominant Systems).

EG 20 didn’t identify upgrade of existing reference (no F document in the standard strength

of reference).

EG 20 recommends development of new standards and guides for System Architecture and

related activities. These references with due attention to avoid duplication with existing

standards (NATO) could be developed by SDO (Standardization Development Organisation),

for example:

1. Standard covering the foundation of the Architecture Frameworks. This could be

thought as an extension of IDEAS and MODEM with terms and concepts

addressing any kind of systems with physical and non-functional aspects. Aim is

enabling interoperability between framework and providing a formalised semantic

description of necessary terms and concepts.

2. Standardisation of Architecture principles leading architecting.

Page 48

3. Method for description and evaluation of System Architecture. This can be

considered as an extension of the NAF V4 methodology currently under

development.

4. Technical report explaining how Architecture frameworks can be combined and

extended for particular concerns like physical description and non-functional

aspects. Alignment of vocabulary is necessary to achieve this combination.

5. Guide for the selection of views in Architecture description.

6. Technical Reports, Acronyms, References and Terminology describing in a

consistent and accepted way best practice, architecture kinds, frameworks and

related components, architecture life cycles with regards to systems, products,

and product-lines.

NOTE: Some of these recommendations were also identified in 2014 by the ISO JTC1/SC7

Architecting Guidance Study Group. Some EG 20 members were part of this Study Group.

Page 49

7. Conclusion

This report has attempted to identify a basic selection of “best practice” standards which

could support System Architectures and related activities. Its objective is to facilitate the

acquisition and supply of defence systems.

In this report, Architecture is intended as a key-description of systems to direct and to secure

their whole life cycle within the respective operational environments. In this context, the

function of Architecting is something more than just Designing, it aims at leveraging roles and

responsibilities within projects and organisations through the identification of the function of

the Architect and the added-value of Architecting within projects.

In the above rather complex and extended landscape the Expert Group 20, contrary to initial

expectations, could count only on the contribution of 2 nations, 6 active experts and 12

month to deliver the study.

Although the experts involved in the study showed a strong background in System

Architecture and significant experiences in Defence and Civilian activities, both nationally

and internationally, time constraint and overall limited men-hours made a redefinition of the

initial scope of work inevitable.

The balanced compromise reached by the team has been to limit the study activity to generic

standards thus excluding sector dependent (land, naval, etc.), discipline related (software,

hardware, etc.) and domain specific (safety, security, languages, protocols etc.) standards.

Notwithstanding the above constraints the EG 20 identified more than 60 suitable references

from main Standardisation Bodies and used in Industry in the areas of Systems Engineering

and Architecture Frameworks.

The process followed by the team to reduce the identified suitable references to “EU Best

Practice” standards started with a preliminary characterisation of each candidate standard

essentially based on 5 parameters: Process, Method, Description/Formalism, Evaluation and

Vocabulary. The evaluation and selection was finalised by following the guidelines provided

by EDSTAR document EN 16341 (“Selection of standards and standard-like documents for

defence products and services - Order of preference”).

At the end 24 standards have been proposed for System Architecture Best Practice. This

selection supports scope of application and limitations applicable to systems, projects and

programs and provides a consistent set of references enabling to perform Architecture

activities, to contract architectural works, to understand Architecture content and to make

decision.

The remaining standards, not coherent with the new scope identified by the EG 20 and an

Page 50

additional list of standards related to land systems and recommended for review by the EG

09 have nonetheless been enclosed in the EG 20 report as annexes for consideration in

future System architecture follow-on standard selection work.

The consolidated work has been reported in the standard EDSTAR final Excel spreadsheet

for ease of handling in connection with the transposition to the EDSTAR European Union

Best Practice collection of Standards.

A consistent collateral activity has been carried out in the initial phases of the study in trying

to identify common references and terminology and in trying to identify common cross-

national and cross-sector understanding. Commonly shared definitions and vocabulary have

been identified among the participating members and included in the report. Further activity

in this area is in any case strongly recommended in order to identify and standardise more

widespread understandings.

Recommendations for future follow-on work are given in the previous chapter 6 and include

options for both standards in domain-specific areas not covered in this report and standards

supporting quality factors such as security and safety of systems. Further work is also

recommended for “framework/umbrella” standards/maps which should help tying up several

dimensions of architecting in order to ensure consistency and interconnection of functions

and standards throughout a given architecture.

As a final analysis the EG 20 team has felt useful to provide the following more general

recommendations and considerations:

A considerable effort is spent at the beginning of the study in order for the

participants to acquaint with the scope of the study, to reach a common

understanding of the required effort and to distribute the tasks. The preparatory

action should devote more efforts to formulate precise requirements and to calibrate

the scope according to the manpower available.

Standardisation experts recognised internationally and in their companies have a

low level of availability in time and in travelling resources. Consequently, their

contributions tend to be limited to the most essential delivery of information. Future

consideration should be given to a more centralised management and coordination

function, a more consistent component of internet networking with respect to

meetings and the availability of coordinated national networks of experts with a solid

interface and local coordinating reference.

Page 51

Annex A – List of Best Practice Standards references associated to the domain

ICS Doc Id EGno Exp

Groups

Title

Original Title

Category

Standardizatio

n Body

Standard Location

Standard strength

of referenc

e

Issue Date Summary Previous Version

Comments Keywords Langua

ge

SEE ATTACHED EXCEL SPREADSHEET Standard strength of reference (G=Guidance; A= to be applied; F = Future evolution expected)

Page 52

Annex B – Final experts' characterisation and selection

scope Classification Criteria

Category

Ad

ded

-val

ue

fact

ors

: d

o it

imp

rove

/ P

rom

ote

…?

Y/N

Fran

ce

Ital

y

Do

c Id

Titl

e

Stan

dar

diz

atio

n B

od

y

R

ele

van

ce:

F /

P

1a

1b

2

a 2

b

2c

2d

2e

P

roce

ss

Me

tho

d

De

scri

pti

on

/Fo

rmal

ism

Ev

alu

atio

n

Vo

cab

ula

ry

HS

MS

IS

TS

Usa

ge

Do

mai

ns

Sy

s. In

tero

pe

rab

ility

Sy

st. I

nte

grat

ion

Sy

st. R

eu

sab

ility

Qu

alit

y fa

cto

rs (

larg

er

list,

no

t lim

ite

d t

o

arch

ite

ctu

ral)

N x

ISO/IEC 10746-2 ITU-T Rec. X.902

ISO/IEC 10746 Information technology — Open Distributed Processing — Reference model Part 2: Foundations

ISO

x

x

N x


ISO/IEC 10746 Information technology — Open Distributed Processing — Reference model Part 3: | ISO/IEC 10746-3: Architecture

ISO

x

x

N x


ISO/IEC 10746 Information technology — Open Distributed Processing — Reference model Part 4: | ISO/IEC 10746-4: Architectural semantics

ISO

x

x

N x

ISO 19439 Enterprise integration -- Framework for enterprise modelling

ISO

x x

x

Page 53

N x

ISO 19440 Enterprise integration -- Constructs for enterprise modelling

ISO

x x

x

N x

ISO 14258 Industrial automation systems -- Concepts and rules for enterprise models

ISO

x x

x

Y x

EIA 632 Processes for Engineering a System EIA P

x

x

x

generic generic

x

Y x

formal/2013-08-04

Unified profile for DoDAF and MODAF (UPDM)

ISO

x

x

Y

HFM-155 NATO Human view Handbook

x

Y

IEC 60812 Ed 2 Analysis techniques for system reliability - Procedure for failure mode and effects analysis (FMEA)

IEC

x

N

SAE-AS 5506 ARCHITECTURE ANALYSIS & DESIGN LANGUAGE (AADL)

F

x

x x x x x

x

x

x

digital processing

generic

Y

INCOSE-TP-2003-002-03.2.2.

System Engineering Handbook: A Guide for System Life Cycle Processes and Activities -- ver. 3.2.2

ISO/IEC/ INCOSE

x

x x

x

x

x

x

Efficiency / maintainability

Y x

ISO 15704 Industrial automation systems -- Requirements for enterprise-reference architectures and methodologies

ISO

x x

x

Y

ISO 20000-series Information technology - Service management - Part 1 : service management system requirements.

F

x x

x

x

x

x x

Information system + Business management

information system

x x x affordability, effectiveness

N x

ISO/IEC-42030 Systems and software engineering — Architecture evaluation

ISO F

x x

x x

x

generic generic

testability

Y

ISO IEC 15408 Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model

x

Y x

ISO/CEI 26702 (from IEEE 1220)

Standard for application and management of the systems engineering process

ISO P

x

x x

x x

generic generic

efficiency

Y

ISO/CEI TR 24748-1 systems and software engineering - Life cycle management - Part 1 : Guide for

ISO

x

x

x

Page 54

life cycle management

N ?

ISO/CEI TR 24774 Software and systems engineering - Life cycle management - Guidelines for process description

ISO

x

x

x

Y x

ISO/CEI TR 24748-2 Systems and software engineering — Life cycle management —Part 2: Guide to the application of ISO/IEC 15288 (System life cycle processes)

ISO

P

x

x x

x

generic generic

efficency

N

ISO/CEI 26514 systems and software engineering - requirements for designers and developers of user documentation

ISO

x

x

N

ISO/CEI 15939 Systems and software engineering — Measurement process

ISO

x

x

x

x

Y x

ISO/CEI TR 90005 Systems engineering — Guidelines for the application of ISO 9001 to system life cycle processes

ISO P

x

x

x

generic generic

Y x

ISO/CEI/IEEE 15289

systems and software engineering – content of systems and software life cycle process information products (documentation)

ISO

P

x

x

x x

generic generic

efficiency, reusability

N

ISO/CEI TR 24748-3 Systems and software engineering — Life cycle management —Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle processes)

ISO

x

x

Y

ISO/IEC 27000 - series

Information technology - Security techniques - Information security management systems - Overview and vocabulary

F

x x

x

x x

x x

Information system security

systems

Security

Y x

ISO/IEC IEE 24765 Systems and software engineering — Vocabulary

ISO

x

x

Y x x ISO/IEC-15288 Systems and software engineering --

System life cycle processes ISO

P

x

x

x x

generic generic

efficiency

N

ISO/CEI 12207 Information technology. Software life cycle processes

ISO

x

x

Page 55

N x

ISO/IEC 15414 ITU-T Rec. X.911

ISO/IEC 10746 Information technology — Open Distributed Processing — Reference model

ISO F

? ?

x x

x

generic

information system

x x

quality of service

N x


ISO/IEC 10746 Information technology — Open Distributed Processing — Reference model Part 1: Overview

ISO

x

x

Y x x ISO/IEC-42010 Systems and software engineering —

Architecture description ISO

F

x x

x

x

x

generic generic

x

Y

NAF NATO Architecture Framework NATO

x

x

N

EN 4660 series Aerospace series - Modular and Open Avionics Architectures - Part 001 : architecture

Y x

prEN 9277 / RG Aéro 000 77

Program management. Guide for the management of system engineering

BNAE / ASD EN

P

x

x

x

Y

prEN 9320 Aerospace series - Programme Management - General guidelines for acquisition and supply of open systems

P

x

x x

x

x

x

acquisition generic

x x affordability

N

x DEF STAN 23-09, Part 0, Issue 3

Generic Vehicle Architecture (GVA) Part 0: GVA Approach

UK DSTAN

x

x

x

x

maintanability

N


Generic Vehicle Architecture (GVA) Part 1: Infrastructure

UK DSTAN

x

x x

x

x

Efficiency; Robustness

N


Generic Vehicle Architecture (GVA) Part 2: Human Machine Interface

UK DSTAN

x

x

x x

x

x

Efficiency

N

x SAE J1939 201308 Recommended Practice for a Serial

Control and Communications Vehicle Network

SAE

x

x

x

x x

Efficiency; Robustness

N

x DDS API v1.2 Data Distribution Service (DDS) OMG

x

x

x

x

x

Efficiency / maintainability

N

x DDSI v2.1 Real-time Publish-Subscribe Wire

Protocol DDS Interoperability Wire Protocol

OMG

x

x

x

x x

x

x

Efficiency / Security

Page 56

Y

SEBoK Systems Engineering Body of Knowledge (SEBoK) ver. 1.2

INCOSE - IEEE

P

x x

x x

x

x

System engineering

generic

x x Efficiency / maintainability

N

IEC/TS 61000-5-8 HEMP protection methods for the distributed infrastructure

IEC

N

IEC 61000-4-25 HEMP immunity test methods for equipment and systems

IEC

N

IEC/TS 61000-5-9 System-level susceptibility assessments for HEMP and HPEM

IEC

Y

STANAG 4603 Modelling And Simulation Architecture Standards For Technical Interoperability: High Level Architecture (Hla)

P

x x

x

x

x

x x x

Y x

STANAG 4728 AAP-48

system lifecycle management P

x

x

x x

generic generic

efficiency

N

ISO/IEC TR 13335/1

Information Technology — Security Techniques — Management Of Information And Communications Technology Security — Part 1: Concepts And Models For Information And Communications Technology Security Management

N

ISO IEC 17799 Information Technology. Code of practice for information security management.

N

ISO/IEC 19793 Information technology - Open Distributed Processing - Use of UML for ODP system specifications

F

x x

x x

x

x

IT generic

x x x

Openness, modularity

N

ISO/IEC 15414 Information technology - Open distributed processing - Reference model - Enterprise language

P

x x

x x

x

x

IT generic

x

N

KAOS

N

GORE

N

SAE J1739 March 2009

POTENTIAL FAILURE MODE AND EFFECTS ANALYSIS IN DESIGN (DESIGN FMEA), POTENTIAL FAILURE MODE AND EFFECTS ANALYSIS IN MANUFACTURING AND

Page 57

ASSEMBLY PROCESSES (PROCESS FMEA)

N

MARTE

N

Profil UML AADL

N

ARP4754A

N

ARP4761

Y

TOGAF The Open Group Architecture Framework

x x

TOTAL 60 documents

24 Yes

Page 58

Annex C – Architecture Languages

Recommendation(s)


Architecture Languages Scope: List of languages to support MBSE (Model Based System Engineering) Approach

The AADL standard defines a language describing both the software architecture and the execution platform architectures of performance-critical, embedded, real-time systems; the language is known as the Architecture Analysis & Design Language (AADL). AADL (but also B, xFFBD) is a formal proof language that allow test of consistency The Systems Modelling Language (SysML) is a general-purpose graphical modeling language for systems engineering applications. SysML supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities. SysML belongs to a list of pseudo formal modeling languages like UML, BPMN (business process modeling), SADT (Structured Analysis and Design Technique), Modelica (object-oriented, equation based language) and IDEF with application to some specific domains. Source: http://standards.sae.org/ SAE – AS 5506 Rev B (2012) OMG SysML v1.3 (2012) OMG BPMN v2.0 (2011)

Classification criteria: none

Why chosen as best practice? The selection of an architecture language allows the capture of architecture requirements, the analysis of critical parameters and an easier integration of elements including software and hardware.

How to use it (them)? This is a list of well know languages that could be used for an architecture work.

What is missing? There is not a unique standard for architecture description language and each one has a specific advantage. This doesn’t allow easy interoperability between architecture descriptions if the language chosen is different.

http://standards.sae.org/

Page 59

Annex D – System architecture standards recommended by EDSTAR EG 09 “Armoured Land Vehicle Technology”.

Introductory note In consideration of the coherence of this subject with the activity of the EDSTAR Expert Group EG 20 "System Architecture", the considerations and recommendation by EG 09 under this heading have been transmitted to EG 20 for further evaluations from their experts and to be included in their final report for coherence of indexing in the EDSTAR Structure. The material transmitted by EG 09 has been duly received and analysed by the EG 20 experts. The reasoning and debate which ensued was centred mainly on the coherence of the proposed standards with the EG 20 scope and perimeter of action (see paragraph 3 – how the scope was consolidated) and the final considerations, although not unanimous, have been not to include them in the EG 20 Study Report, mainly on the base of their being too Sector Specific. It was in any case agreed to include the material elaborated by EG 09 as an annex to this EG 20 Report with the Recommendation to EDSTAR to activate, at a next opportunity, a follow-on study on System Architecture with a more consistent frame of experts and so to be able to address a wider and more in depth scope for this important standardisation domain. The material received for the EG 09 group of experts is as follows: E.1 General At a certain level of design, the System Architecture is defined by the Systems Engineering team and expressed in a Product Breakdown Structure. This is project specific by definition and it would be wrong for the EG 09 Working Group to dictate a boilerplate set of text to describe a system scenario without some common context. However a common level of system abstraction is being developed in support of the definition of Vehicle Electronic Architectures. The drive for modularity and reuse necessitates the development of a common understanding of the building blocks, plus the establishment of a shared interface definition for physical, logical and functional connections.

DEF STAN 23-09 (Parts 0, 1, and 2) Issue 3 – Generic Vehicle Architecture. The UK MoD has taken the bold step of publishing its developing Generic Vehicle Architecture (GVA) standard early to cope both with an urgent need and lay the foundations for future development. While this standard is still maturing, and will undergo further development, it appears to be the most concise and more crucially, publicly available standard at this time. The US DoD has published a GVA standard at http://victory-standards.org/. However this is restricted to US DoD sponsored programmes and is therefore not publically available. Future iterations of this standard will include the definition of HUMS data and the specification of supporting infrastructure. Both these sections will significantly rationalize the development of generic components to support weapon system development. Another feature of GVA is that it forms part of a wider suite of generic architecture standards ranging from the soldier operating the vehicle to the base from which the vehicle operates. The public availability of this standard makes it the candidate for best practice in this area. This status needs to be reviewed in the event that NATO Land Group 2 ratifies the NATO GVA standard.

SAE J1939 201308 - Recommended Practice for a Serial Control and Communications Vehicle Network.

Page 60

This standard has been specifically developed for vehicle Serial Control and Communications; and has been applied to both heavy and off highway vehicles, as well as diesel engines. These three COTS equipment areas form the backbone of hardware used in the Protected Mobility range of vehicles. It is extremely likely therefore that any future military vehicles will have at least one major component using this protocol. This protocol is also one of the preferred CAN protocols referred to in the GVA standard. While STANAG 4628 – Controller Area Network (CAN) Protocols for Military Applications lists a number of standards that might be applicable, the STANAG does not make a recommendation as to best practice or establish a preference for one protocol over another. STANAG 4628 does include a reference to J1939. The other protocols may be on a fighting vehicle but there are no guarantees that they will be present. Furthermore it is anticipated that the use of CAN bus between non-automotive components requiring a complex data exchange (e.g. commander’s display panel) will be gradually superseded in the next 5 years by the introduction of a data distribution system over Ethernet. CAN bus will remain in service for components for which the data exchange requirements are less demanding (e.g. traverse and elevation controls). J1939 is a best practice protocol because it will, in all probability, be present in the automotive components on the platform.

DDS API v1.2 – Data Distribution Service, DDSI v2.1 – DDS Interoperability Wire Protocol. These two protocols are extremely useful and adaptable, especially in situations in which there are complex data exchanges between individual components. The protocol allows components to be designed with high levels of abstraction and reduces the dependency for the application layers to be aware of the underlying transport mechanisms. While it does impose a burden on the hardware development to incorporate suitable intercommunication mechanisms such as Ethernet; the flexibility this brings to architectural design will outweigh the additional hardware cost. DDS is a best practice protocol due to its public availability and open-ness.

NOTE: Further information on these standards are given in the separate EXCEL sheet named EDSTAR EG09 FINAL REPORT ANNEX E.

Documents

Expert Group 20: System Architecture