SIST EN 9320:2015
(Main)Aerospace series - Programme Management - General guidelines for acquisition and supply of open systems
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
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
2
---------------------- 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.
3
---------------------- 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.
4
---------------------- 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]
5
---------------------- 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]
6
---------------------- 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]
7
---------------------- 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.
8
---------------------- 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.
9
---------------------- 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),
10
---------------------- 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.
11
---------------------- 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.