1、ASD-STAN STANDARD NORME ASD-STAN ASD-STAN NORM prEN 9320 Edition P 1 November 2013 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATIONRue Montoyer 10 - 1000 Brussels - Tel. 32 2 775 8126 - Fax. 32 2 775 8131 - www.asd-stan.orgICS: Descriptors: ENGLISH VERSION Ae
2、rospace series Programme Management General guidelines for acquisition and supply of open systems Srie arospatiale Management de Programme Recommandations gnrales pour lacquisition et la fourniture de systmes ouverts Luft- und Raumfahrt Programm-Management Allgemeiner Leitfaden fr Erwerb und Lieferu
3、ng von offenen Systemen This “Aerospace Series“ Prestandard has been drawn up under the responsibility of ASD-STAN (The AeroSpace and Defence Industries Association of Europe - Standardization). It is published for the needs of the European Aerospace Industry. It has been technically approved by the
4、 experts of the concerned Domain following member comments. Subsequent to the publication of this Prestandard, the technical content shall not be changed to an extent that interchangeability is affected, physically or functionally, without re-identification of the standard. After examination and rev
5、iew by users and formal agreement of ASD-STAN, it will be submitted as a draft European Standard (prEN) to CEN (European Committee for Standardization) for formal vote and transformation to full European Standard (EN). The CEN national members have then to implement the EN at national level by givin
6、g the EN the status of a national standard and by withdrawing any national standards conflicting with the EN. Edition approved for publication 1st November 2013 Comments should be sent within six months after the date of publication to ASD-STAN Engineering Procedures Domain Copyright 2013 by ASD-STA
7、N prEN 9320:2013 (E) 2 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
8、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 programs . 18 15 Configuration management process 21 16 Information management process 23 17 Measuring process . 25 18 Requ
9、irement 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 pro
10、cess . 43 Bibliography . 44 prEN 9320:2013 (E) 3 Foreword This standard was reviewed by the Domain Technical Coordinator of ASD-STANs Engineering Procedures Domain. After inquiries and votes carried out in accordance with the rules of ASD-STAN defined in ASD-STANs General Process Manual, this standa
11、rd has received approval for Publication. prEN 9320:2013 (E) 4 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 us
12、ed 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 stakeho
13、lders (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, Affordabi
14、lity. 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 t
15、he company (target systems resulting from use of company processes). The companys 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
16、 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,
17、 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 wi
18、th 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 coor
19、dinate, synchronise and manage common tasks and share and use resources (human, machine or application) and services efficiently and appropriately. prEN 9320:2013 (E) 5 2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensa
20、ble 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 Pa
21、rt 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:2
22、008, 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
23、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,
24、 resulting from a compromise after negotiation between the Parties 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 relations
25、hips between the components are described in the interfaces 3.1.3 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.4 capacity capacity is repr
26、esented by the consistent integration of a Policy, an Organisation, human resources, training, Support and Equipment 3.1.5 component product that cannot be broken down from the point of view of a specific application SOURCE: ISO 10303-1:1994 prEN 9320:2013 (E) 6 3.1.6 flexibility ability of a system
27、 to continue to fulfil its mission by dynamically or statically adapting to anticipated or foreseeable changes that may occur in its environment 3.1.7 interchangeability ability of a hardware or software component to be replaced, with no change to the components connected to it, by another that meet
28、s the same requirements 3.1.8 interface an interface is the part of a system or piece of equipment that communicates with another system or piece of equipment 3.1.9 interoperability interoperability can be defined as the ability of systems to exchange, with no loss or ambiguity, various object flows
29、 (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.10 key interface the interface of a mod
30、ule that needs to be interoperable, easy to change, replaced or isolated due to its complexity, obsolescence or the costs involved 3.1.11 operational assignment operational assignments are the parts of department activities that may be repetitive, planned and of limited duration 3.1.12 product life
31、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.13 reusability for a hardware or software component, ability to be used, unchanged, in a system or subsystem other
32、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.14 reversibility ability of a system, subsystem or component to be modified and updated by a manufacturer other than
33、 the one that produced it prEN 9320:2013 (E) 7 3.1.15 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 consen
34、sus 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 3.1.16 openness the characteristic of openness for a system is defined by
35、all the following properties: Interchangeability, Interoperability, Upgradability, Reusability, Reversibility, Flexibility, Affordability. 3.1.17 system of systems (SoS) the characteristics of a system of systems are: Operational independence of the systems, Managerial independence of the systems, E
36、mergence of new services, Upgradable configurations, Geographic distribution of the systems, 3.1.18 technical facts key technical event, anticipated or unexpected, in the life cycle of a product 3.1.19 upgradability potential ability of a system, subsystem or component to respond to changes in opera
37、tional requirements and anticipated or foreseeable technical changes without affecting the basis of its structure 3.1.20 validation comparative assessment to confirm that the requirements of stakeholders are properly satisfied. If discrepancies are found, they are recorded and lead to corrective act
38、ion. Validation is ratified by the stakeholders SOURCE: ISO/IEC 15288:2008 prEN 9320:2013 (E) 8 3.1.21 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 SOU
39、RCE: ISO/IEC 15288:2008 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.
40、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
41、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 rela
42、tions 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
43、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 develop
44、ed 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 interope
45、rate, characterise the flows between these systems. List the rules and standards applied by the technical systems of this operational environment. prEN 9320:2013 (E) 9 Define the openness objectives. Rate these openness objectives for the system to be acquired in accordance with the environment. 4.1
46、.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, acquisi
47、tion 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 en
48、vironment. 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 charac
49、teristics, for example interoperability, the more complex the systems 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.1.3 Defin
