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

These general guidelines cover the open system acquisition and supply processes.
There is an increasing requirement for systems designed and produced by industry, particularly in the aeronautic, space and defence fields, to be used with other systems designed, produced, acquired and operated independently.
The concept of open systems is touched upon in many systems engineering documents. This document deals specifically with this subject. To this end, through the various processes applied, it provides information to stakeholders (buyers, suppliers, designers, subcontractors, supervisors, etc.) on the best practice to be adopted.
The specific nature of openness for a system is defined by all the following properties:
-   Interchangeability,
-   Interoperability,
-   Upgradability,
-   Reusability,
-   Reversibility,
-   Flexibility,
-   Affordability.
These properties are defined in the glossary for these general guidelines.
These general guidelines are largely based on the structure and system life cycle processes described in standard ISO/IEC 15288:2008.
The characteristics of openness also relate to:
-   The products or services offered by the company (target systems resulting from use of company processes).
-   The company’s processes (project systems). Several stakeholders, with their own assignments, cultures, jobs and geographical locations, different working methods, modelling frameworks, standards, tools and aids, etc. are involved in the activities, which are sometimes multidisciplinary, of the internal and external processes of a company. These diverse elements are not necessarily all suited to working together without causing certain risks, a loss of autonomy, effectiveness and/or efficiency, etc. A company must, for example, develop its ability and capacity in terms of interoperability both internally (between the systems of which it is made) 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.

Luft- und Raumfahrt - Programm-Management - Allgemeiner Leitfaden für Erwerb und Lieferung von offenen Systemen

Série aérospatiale - Management de Programme - Recommandations générales pour l’acquisition et la fourniture de systèmes ouverts

Ces recommandations générales traitent des processus d’acquisition et de fourniture de systèmes ouverts.
Les systèmes conçus et réalisés par l’industrie, en particulier dans les domaines aéronautique, spatial et de défense, sont de plus en plus souvent amenés à être utilisés conjointement avec d’autres systèmes conçus, réalisés, acquis et exploités de façon indépendante.
Le concept de l’ouverture des systèmes est abordé dans nombre de documents d’ingénierie système. Ce document traite spécifiquement de ce sujet. À ce titre, au travers des différents processus appliqués, elle éclaire les acteurs concernés (acquéreurs, fournisseurs, concepteurs, sous-traitants, tutelles, …) sur les bonnes pratiques à mettre en œuvre.
La caractéristique d’ouverture pour un système se définit par l’ensemble des propriétés suivantes :
   Interchangeabilité,
   Interopérabilité,
   Évolutivité,
   Réutilisabilité,
   Réversibilité,
   Flexibilité,
   Abordabilité.
Les définitions de ces propriétés sont précisées dans le glossaire de ces recommandations générales.
Ces recommandations générales s’appuient largement sur la structure et les processus de cycle de vie des systèmes décrits dans la norme ISO/CEI 15288:2008.
Les caractéristiques d’ouverture concernent aussi bien :
   Les produits ou services proposés par l’entreprise (systèmes cibles résultant du fonctionnement des processus de l’entreprise).
   Les processus de l’entreprise (on parle alors de "systèmes pour faire"). Plusieurs acteurs avec leur mission, leur culture, leur métier et leur situation géographique, différentes méthodes de travail, cadres de modélisation, normes, outils supports, etc. sont impliqués dans des activités, quelquefois pluridisciplinaires, des processus internes ou externes d’une entreprise. Chacun de ces éléments hétérogènes n’est cependant pas nécessairement apte à travailler avec d’autres sans entraîner certains risques, une perte d’autonomie, d’efficacité et/ou d’efficience, etc. Une entreprise doit, par exemple, développer son aptitude et sa capacité en termes d’interopérabilité aussi bien interne (entre les systèmes qui la composent) qu’externe (avec d’autres partenaires), dont, à titre illustratif :
   Capacités de chaque partie prenante impliquée, de chaque métier concerné à entretenir une relation efficiente et de confiance avec les autres parties prenantes en tenant compte d’objectifs à la fois de délais, de coûts et de qualité,
   Capacités à échanger, à communiquer et à utiliser de manière autonome, sans erreur et de manière dynamique, les flux nécessaires (données, informations, connaissances, matières, énergies) tout au long du cycle de vie du système à faire,
   Capacités à piloter, synchroniser et gérer des tâches communes, à partager et à utiliser de manière efficiente et pertinente des ressources (humaines, machines ou applicatives) et des services.

Aeronavtika - Vodenje programov - Splošne smernice za nabavo in dobavo/oskrbo odprtih sistemov

Te splošne smernice zajemajo nabavo in dobavo/oskrbo odprtih sistemov.
Vse pogosteje se pojavlja potreba, da se sistemi, ki jih načrtuje in izdela industrija, zlasti na področjih aeronavtike, prostorske ureditve in obrambe, uporabljajo z drugimi sistemi, ki so načrtovani, izdelani nabavljeni in upravljani neodvisno. Koncepta odprtih sistemov se dotikajo številni dokumenti s področja sistemskega inženiringa. Ta dokument obravnava posebej to temo. V ta namen prek različnih uporabljenih postopkov deležnikom (kupcem, dobaviteljem, projektantom, podizvajalcem, nadzornikom itd.) zagotavlja informacije o najboljši praksi.
Posebno naravo odprtosti sistema opredeljujejo vse naslednje lastnosti:
 medsebojna zamenljivost,
 interoperabilnost,
 nadgradljivost,
 možnost ponovne uporabe,
 reverzibilnost,
 prilagodljivost,
 dostopnost.
Te lastnosti so opredeljene v glosarju za te splošne smernice.
Te splošne smernice v veliki meri temeljijo na strukturi in procesih življenjskega cikla sistemov, opisanih v standardu ISO/IEC 15288:2008.
Značilnosti odprtosti se nanašajo tudi na:
 Izdelke ali storitve, ki jih ponuja družba (ciljni sistemi, ki izvirajo iz uporabe procesov družbe).
 Procese družbe (projektni sistemi). V dejavnosti notranjih in zunanjih procesov družbe, ki so včasih multidisciplinarne, je vključenih več deležnikov s svojimi lastnimi zadolžitvami, kulturo, delovnimi mesti in geografskimi lokacijami, različnimi delovnimi metodami, okviri modeliranja, standardi, orodji in pomočmi itd. Vsi ti različni elementi niso nujno primerni za sodelovanje, ne da bi povzročili nekatera tveganja, izgubo avtonomnosti, učinkovitosti in/ali uspešnosti itd. Družba mora, na primer,
razviti svojo sposobnost in zmožnost v smislu notranje (med sistemi, ki jo sestavljajo) in zunanje (z drugimi partnerji) interoperabilnosti, tudi na primer prek:
 zmožnosti, da vsak vključen deležnik in oddelek ohrani učinkovite in zaupanja polne odnose z drugimi deležniki, ob upoštevanju ciljev glede roka, stroškov in kakovosti,
 zmožnosti avtonomne izmenjave, komunikacije in uporabe potrebnih tokov (podatkov, informacij, znanja
materialov, energije), in sicer brez napak in dinamično v celotnem življenjskem ciklu ciljnega sistema,
 zmožnosti usklajevanja, sinhronizacije in vodenja skupnih nalog ter učinkovite in ustrezne delitve in uporabe virov (človeških virov, strojev ali aplikacij) ter storitev.

General Information

Status
Published
Publication Date
16-Dec-2014
Technical Committee
Drafting Committee
Current Stage
6060 - Definitive text made available (DAV) - Publishing
Due Date
17-Dec-2014
Completion Date
17-Dec-2014

Buy Standard

Standard
EN 9320:2015
English language
44 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST EN 9320:2015
01-marec-2015
Aeronavtika - Vodenje programov - Splošne smernice za nabavo in dobavo/oskrbo
odprtih sistemov
Aerospace series - Programme Management - General guidelines for acquisition and
supply of open systems
Luft- und Raumfahrt - Programm-Management - Allgemeiner Leitfaden für Erwerb und
Lieferung von offenen Systemen
Série aérospatiale - Management de Programme - Recommandations générales pour
l’acquisition et la fourniture de systèmes ouverts
Ta slovenski standard je istoveten z: EN 9320:2014
ICS:
35.080 Dokumentiranje razvoja Software development and
programske opreme in system documentation
sistemov (sistemska
dokumentacija)
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
SIST EN 9320:2015 en,fr,de

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST EN 9320:2015
---------------------- Page: 2 ----------------------
SIST EN 9320:2015
EUROPEAN STANDARD
EN 9320
NORME EUROPÉENNE
EUROPÄISCHE NORM
December 2014
ICS 35.080; 49.020
English Version
Aerospace series - Programme Management - General
guidelines for acquisition and supply of open systems

Série aérospatiale - Management de Programme - Luft- und Raumfahrt - Programm-Management -

Recommandations générales pour l'acquisition et la Allgemeiner Leitfaden für Erwerb und Lieferung von offenen

fourniture de systèmes ouverts Systemen
This European Standard was approved by CEN on 28 June 2014.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European

Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national

standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.

This European Standard exists in three official versions (English, French, German). A version in any other language made by translation

under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same

status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,

Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,

Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United

Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels

© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9320:2014 E

worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
Contents Page

Foreword ............................................................................................................................................................. 3

1 Scope ..................................................................................................................................................... 4

2 Normative references ........................................................................................................................... 5

3 Terms and definitions and abbreviated terms ................................................................................... 5

4 Acquisition process.............................................................................................................................. 8

5 Supply process ................................................................................................................................... 12

6 Life cycle model management process ............................................................................................ 13

7 Infrastructure management process ................................................................................................ 13

8 Budget management process ........................................................................................................... 14

9 Resource management process ....................................................................................................... 14

10 Quality management process ............................................................................................................ 16

11 Project planning process ................................................................................................................... 16

12 Project control and assessment process......................................................................................... 17

13 Decision-making process .................................................................................................................. 18

14 Risk management process ................................................................................................................ 18

15 Configuration management process ................................................................................................ 21

16 Information management process .................................................................................................... 23

17 Measuring process ............................................................................................................................. 25

18 Requirement establishment and analysis process ......................................................................... 28

19 Architecture design process ............................................................................................................. 35

20 Execution process .............................................................................................................................. 37

21 Integration process ............................................................................................................................. 37

22 Verification process............................................................................................................................ 38

23 Validation process .............................................................................................................................. 40

24 Qualification process ......................................................................................................................... 41

25 Operating process .............................................................................................................................. 41

26 Maintenance process ......................................................................................................................... 43

27 Withdrawal from service process ..................................................................................................... 43

Bibliography ..................................................................................................................................................... 44

---------------------- Page: 4 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
Foreword

This document (EN 9320:2014) has been prepared by the Aerospace and Defence Industries Association of

Europe - Standardization (ASD-STAN).

After enquiries and votes carried out in accordance with the rules of this Association, this Standard has received

the approval of the National Associations and the Official Services of the member countries of ASD, prior to its

presentation to CEN.

This European Standard shall be given the status of a national standard, either by publication of an identical text

or by endorsement, at the latest by June 2015, and conflicting national standards shall be withdrawn at the latest

by June 2015.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent

rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.

According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following

countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech

Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece,

Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,

Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

---------------------- Page: 5 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
1 Scope
These general guidelines cover the open system acquisition and supply processes.

There is an increasing requirement for systems designed and produced by industry, particularly in the

aeronautic, space and defence fields, to be used with other systems designed, produced, acquired and operated

independently.

The concept of open systems is touched upon in many systems engineering documents. This document deals

specifically with this subject. To this end, through the various processes applied, it provides information to

stakeholders (buyers, suppliers, designers, subcontractors, supervisors, etc.) on the best practice to be adopted.

The specific nature of openness for a system is defined by all the following properties:

 Interchangeability,
 Interoperability,
 Upgradability,
 Reusability,
 Reversibility,
 Flexibility,
 Affordability.
These properties are defined in the glossary for these general guidelines.

These general guidelines are largely based on the structure and system life cycle processes described in

standard ISO/IEC 15288:2008.
The characteristics of openness also relate to:

 The products or services offered by the company (target systems resulting from use of company processes).

 The company’s processes (project systems). Several stakeholders, with their own assignments, cultures,

jobs and geographical locations, different working methods, modelling frameworks, standards, tools and

aids, etc. are involved in the activities, which are sometimes multidisciplinary, of the internal and external

processes of a company. These diverse elements are not necessarily all suited to working together without

causing certain risks, a loss of autonomy, effectiveness and/or efficiency, etc. A company must, for example,

develop its ability and capacity in terms of interoperability both internally (between the systems of which it is

made) 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.
---------------------- Page: 6 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable

for its application. For dated references, only the edition cited applies. For undated references, the latest edition

of the referenced document (including any amendments) applies.
ISO 9001:2008, Quality management systems — Requirements

ISO 9241-210:2010, Ergonomics of human-system interaction — Part 210: Human-centred design for interactive

systems

ISO 10007:2003, Quality management systems — Guidelines for configuration management

ISO 10303-1:1994, Industrial automation systems and integration — Product data representation and exchange —

Part 1: Overview and fundamental principles

ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes

ISO/IEC 9126-1:2001, Software engineering — Product quality — Part 1: Quality model

IEEE 830:1998, IEEE Recommended Practice for Software Requirements Specifications

IEEE 1471:2000, IEEE Recommended Practice for Architectural Description for Software — Intensive Systems

3 Terms and definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
affordability

ability of a system to have acceptable operational performance for an acceptable cost of ownership, resulting

from a compromise after negotiation between the Parties
[SOURCE: IEEE 1471:2000]
3.1.2
architecture

fundamental organisation of a system described by its components, the relationship between these components

and with the environment, and the principles guiding its representation and its development. The relationships

between the components are described in the interfaces
3.1.3
capacity

capacity is represented by the consistent integration of a Policy, an Organisation, human resources, training,

Support and Equipment
3.1.4
component

product that cannot be broken down from the point of view of a specific application

[SOURCE: ISO 10303-1:1994]
---------------------- Page: 7 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
3.1.5
flexibility

ability of a system to continue to fulfil its mission by dynamically or statically adapting to anticipated or

foreseeable changes that may occur in its environment
3.1.6
interchangeability

ability of a hardware or software component to be replaced, with no change to the components connected to it,

by another that meets the same requirements
3.1.7
interface

an interface is the part of a system or piece of equipment that communicates with another system or piece of

equipment
3.1.8
interoperability

interoperability can be defined as the ability of systems to exchange, with no loss or ambiguity, various object

flows (data, information, knowledge, materials, energy, etc.), then to be capable of using these objects

independently to fulfil their own assignments or to fulfil a shared assignment for a given purpose with no change

to their structure, behaviour or operation
3.1.9
key interface

the interface of a module that needs to be interoperable, easy to change, replaced or isolated due to its

complexity, obsolescence or the costs involved
3.1.10
operational assignment

operational assignments are the parts of department activities that may be repetitive, planned and of limited duration

3.1.11
product life cycle

this covers all the situations the product goes through during its life from statement of requirement to withdrawal

from whatever service is provided
[SOURCE: NF X 50-100:1996]
3.1.12
reusability

for a hardware or software component, ability to be used, unchanged, in a system or subsystem other than the

one for which it was originally developed

For a system or subsystem, ability to use, unchanged, hardware or software components which were not

originally developed for it
3.1.13
reversibility

ability of a system, subsystem or component to be modified and updated by a manufacturer other than the one

that produced it
3.1.14
open system

assembly including software and hardware elements and operating procedures, designed by humans. These

elements interact to satisfy the requirements (including interface requirements) defined, published and

maintained by general consensus by a group

Modular construction created so that its modules are defined precisely and have public interfaces allowing

independent suppliers to provide new capacities and innovative modules
[Modular Open System Architecture]
---------------------- Page: 8 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
3.1.15
openness

the characteristic of openness for a system is defined by all the following properties:

 Interchangeability,
 Interoperability,
 Upgradability,
 Reusability,
 Reversibility,
 Flexibility,
 Affordability.
3.1.16
system of systems (SoS)
the characteristics of a system of systems are:
 Operational independence of the systems,
 Managerial independence of the systems,
 Emergence of new services,
 Upgradable configurations,
 Geographic distribution of the systems,
3.1.17
technical facts
key technical event, anticipated or unexpected, in the life cycle of a product
3.1.18
upgradability

potential ability of a system, subsystem or component to respond to changes in operational requirements and

anticipated or foreseeable technical changes without affecting the basis of its structure

3.1.19
validation

comparative assessment to confirm that the requirements of stakeholders are properly satisfied. If discrepancies

are found, they are recorded and lead to corrective action. Validation is ratified by the stakeholders

[SOURCE: ISO/IEC 15288:2008]
3.1.20
verification

demonstration, through assessment of the product, that the system has been designed correctly, i.e. that it

complies with the specifications according to which the product was made
[SOURCE: ISO/IEC 15288:2008]
---------------------- Page: 9 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
3.2 List of abbreviations
NCOIC Network Centric Operations Industry Consortium
OTS Off-The-Shelf
IADT Inspection Analysis Demonstration Test
OS Open System
MMI Man Machine Interface
SoS System of Systems
SMART Specific, Measurable, Achievable, Realistic and Time-constrained.
STEP Standard for the Exchange of Product model data
TRL Technology Readiness Level
IRL Integration Readiness Level
SCOPE Systems Capabilities, Operations, Programmes and Enterprises
UML Unified Modelling Language
SysML System Modelling Language
4 Acquisition process

The organisations are producers and consumers of systems, which may make products or perform services.

These systems are produced by some or implemented or consumed by others within the context of the

relationship between buyers (those who purchase and consume or use) and suppliers (those who produce and

sell). Buyer/supplier relations are maintained through contracts. Acquisition of an open system requires specific

activities to be carried out to optimise signature of contracts to obtain a product/service that satisfies the

openness requirements.

The purpose of the process described in this chapter is to characterise these activities. The level of detail of

each activity depends on the complexity of the system to be acquired.
4.1 An acquisition strategy is established
4.1.1 Define an openness strategy

Define the openness level required depending on, for example, the maturity scale defined using the SCOPE

model developed by the NCOIC. To establish this openness level, it is important to:

 Be aware of the operational environment into which the system to be acquired will be integrated,

exhaustively and explicitly identify the systems of the operational environment with which the system to be

acquired should interoperate, characterise the flows between these systems.

 List the rules and standards applied by the technical systems of this operational environment.

 Define the openness objectives.

 Rate these openness objectives for the system to be acquired in accordance with the environment.

---------------------- Page: 10 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
4.1.2 Define an acquisition strategy

The way in which the system is acquired (related to the quantity and/or the complexity of the system in question)

can have a direct effect on the system openness. A short-term acquisition for a system with a short life cycle may

be unique. On the other hand, acquisition in stages or long-term acquisition for a system with a long life cycle

entails requirements in terms of openness, including upgradability, and can cause openness problems linked to

changes in the environment in which it is integrated, for example unplanned changes to the other systems in its

environment. It is therefore necessary to establish an acquisition strategy depending on the system life cycle model

and the changes anticipated in the system environment (regular upgrades, midlife upgrades, etc.).

It is necessary to:
 Define the life cycle model.

 The more important the openness characteristics, for example interoperability, the more complex the

system’s life cycle will be.
 Describe the acquisition increments leading to the solution.

 The acquisition increments must be organised depending on the openness requirements identified (for

example planning the main changes anticipated taking into account the maturity of the technology

implemented – TRL).

Contractual requirements specific to reversibility will be defined when the acquisition strategy is defined.

4.2 A supplier is selected and the selection justified
4.2.1 Define selection criteria

To facilitate the production of an open system, the prime contractor (supplier) should have experience in the

design of open systems. The selection criteria proposed may be:
 the maturity of the supplier (according to SCOPE).
 a scale based on the supplier’s experience:
 0: no open system design listed,
 1: design of open systems in a different field,
 2: design of open systems in the field,

 3: recognised as an open system manufacturer (several references in several fields).

 The quality of presentation of the response to the call for tenders (structured presentation promoting a

systems engineering strategy, etc.)
 The open systems of the suppliers are certified (for example by the NCOIC).
4.2.2 Justify the choice of supplier

Each supplier is assessed/graded in accordance with predefined criteria. Within the context of an open system,

as well as the cost/performance aspects, the supplier's experience must also be taken into consideration.

---------------------- Page: 11 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
4.3 Communication with the supplier is maintained

Continuously discuss the open system requirements and its interfaces (external and internal).

The needs of the Client in terms of the requirements for the system openness aspects that the Industrial

Contractor must satisfy and apply during production and industrialisation of the system should therefore be

stipulated in detail in the contract. This may relate to current and future operational changes to be taken into

account, predicted technical developments and changes to OTS components.
4.4 A contract is drawn up
4.4.1 State the acceptance criteria for openness

The open system level, in terms of interoperability, upgradability, interchangeability, reusability, flexibility,

reversibility and affordability, must be clearly defined in the form of requirements and acceptance criteria must be

formulated for each of these requirements. The contract must refer to these requirements associated with

openness, in line with the predefined acquisition strategy. A requirement must be Measurable, Useful, Simple

and Traceable (MUST). To define these requirements, a detailed description of the system’s operational

environment will be used (current operational environment and probable future operational environment). To

encourage interoperability, the system’s interfaces with its environment must be precisely characterised from an

operational and functional point of view. If rules, standards or OTS components need to be used, they need to

be characterised:

 Either define a catalogue of rules, standards and OTS components to be used and keep it up-to-date,

 Or draw up the requirements relating to the use of rules, standards and OTS components with an

associated priority: critical, essential, important, useful, optional, etc. (see essential, important, desirable or

IEEE 830:1998 essential, conditional and optional).
4.4.2 Stipulate the legal conditions

From an architectural point of view, the openness is characterised by the use of product rules and standards and

OTS components. To ensure that the openness requirements expressed by the Client comply with Industrial

Contractor and third party intellectual property rights, a strategy on the choice of these rules, standards and OTS

components must be defined in close collaboration with legal experts: rules, public or proprietary standards, free

of charge or chargeable, etc.

For a SoS, every effort will be made to ensure a certain level of consistency between the various contracts. This

means that the systems to be integrated into the SoS must comply with the interoperability rules and that the

partners (Client and Prime Contractor) of the different SoS must exchange both technical and non-technical

information (coordination between programmes, agreement between partners) and follow standardised systems

engineering processes and activities when they are called upon to collaborate.

Of the various openness characteristics, reversibility is not a technical characteristic but a contractual and legal

aspect. The guidelines present reversibility within the framework of French law. They will need to be adapted for

other jurisdictions.

The contractual clauses relating to reversibility will be negotiated. Reversibility may be dealt with in a conditional

part of contracts.

Particular attention will be paid to determining the elements of contracts specific to reversibility:

 a duration,
 advance notification of enforcement of the reversibility clause,

 a reversibility plan set up as soon as service provision commences and which must be updated regularly

(similar to the service continuity plan in the banking field),
---------------------- Page: 12 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)

 the transfer of intellectual property rights (patents, drawings, models, etc.), copyright for software,

 the scope of the actions in relation to reversibility,
 gradual stoppage of services,
 maintenance or gradual reduction of performance commitments,

 transfer of information and data on maintenance history (reliability, failure rate),

 transfer of spare parts management: parts inventory, list of orders in progress, stock rotation management rules,

 expertise (know-how, etc.).
 skills transfer,
 transmission of written procedures, condition of installations,
 Staff re-employment,
 Training.
 Reversibility acceptance phase,
 Contractual guarantees,
 Payment of price.
4.4.3 Define the means for checking openness characteristics

The requirements of the openness tests to be performed must be laid down in a contract and their results

produced in the presence of both parties. The following methods can be used:
 The development of scenarios by simulation and/or experimentation,

 The assessment methods based on inspection, analysis, demonstrations and tests (IADT),

 Operational acceptance tests and verification of service rendered.

These methods are cross-functional and apply to models, prototypes, demonstration models, first-offs and so on.

Resources, such as test benches, simulation environments and scenarios, must be specified.

4.5 A product or service conforming to the contract terms is accepted

If the openness characteristics have been demonstrated and validated (performance of the activities defined

in 4.4.3) and the product/service delivered satisfies all the requirements laid down in the contract, it can be

contractually accepted.

The penalties associated with the non-conformity of an openness characteristic are dealt with in the same way

as the other penalties. Depending on the ranking of the openness objectives laid down by the buyer, the

penalties will be defined in the contract.

It is worth noting that defining guarantee criteria for system openness is not necessarily easy as the openness

characteristics of a product/service depend on the products/services with which it interacts. Thus, the

interoperability of a system is closely linked to the technological stability of the operational environment.

Alternatively, it needs to be looked at in terms of risk. The instability of the environment will be managed by

change requests and addenda to the original contract.
---------------------- Page: 13 ----------------------
SIST EN 9320:2015
EN 9320:2014 (E)
4.6 The contract is closed

Ownership of the system is transferred when the contract is closed. In the end, the reversibility clause may be

invoked, as long as it has been clearly defined in the contract and is not unfair.

5 Supply process

The organisations are producers and consumers of systems, which may make products or perform services. Within

this context, the supply process from the supplier side mirrors the acquisition process from the buyer side.

The purpose of the process described in this chapter is to characterise these activities. The level of detail of

each activity depends on the complexity of the system to be supplied.
5.1 A buyer or a market for a product/service is identified and a proposal made

More and more systems must have good openness properties in order to be marketable. It is therefore important

to have good knowledge of the environment of the product/service when conducting market research:

operational environment, industry practice, standards. It is then possible to work out a project strategy which will

provide answers to the following questions: What is the target market (mass production or confidential), what is

the market segment (quasi-monopo
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.