1、 ASD-STAN STANDARD NORME ASD-STAN ASD-STAN NORM ASD-STAN prEN 9223-104:2016 Edition P1 2016-10 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATION Rue Montoyer 10 - 1000 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8131 - www.asd-stan.org ICS: Descriptors:
2、ENGLISH VERSION Programme Management Configuration Management Part 104: Configuration Control Programm-Management Konfigurationsmanagement Teil 104: Konfigurationslenkung Management de Programme Gestion de la Configuration Partie 104 : Matrise de la configuration This “Aerospace Series” Prestandard
3、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 experts of the concerned Domain following member comments.
4、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 review by users and formal agreement of ASD-STAN, the ASD-STAN
5、prEN 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 giving the EN the status of a national standard an
6、d by withdrawing any national standards conflicting with the EN. ASD-STAN Technical Committee approves that: “This document is published by ASD-STAN for the needs of the European Aerospace Industry. The use of this standard is entirely voluntary, and its applicability and suitability for any particu
7、lar use, including any patent infringement arising therefrom, is the sole responsibility of the user.” ASD-STAN reviews each standard and technical report at least every five years at which time it may be revised, reaffirmed, stabilized or cancelled. ASD-STAN invites you to send your written comment
8、s or any suggestions that may arise. All rights reserved. No parts of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of ASD-STAN. Order detai
9、ls: E-mail: salesasd-stan.org Web address: http:/www.asd-stan.org/ Edition approved for publication Comments should be sent within six months after the date of publication to ASD-STAN General Domain prEN 9223-104:2016 (E) 2 Contents Page 1 Scope . 5 2 Normative references . 5 3 Terms and definitions
10、. 5 4 Configuration control place in the overall programme Configuration Management 5 4.1 Configuration control process overview . 5 4.2 The Configuration Control process nature . 6 4.3 Tasks associated with configuration control . 8 5 Configuration control principles 9 5.1 General . 9 5.2 Allocatio
11、n of an item to an authority. 9 5.3 Technical changes, deviations permits and concessions shared provisions 9 5.4 Technical changes process 9 5.5 Deviation permit process . 10 5.6 Concessions handling process 10 5.7 Data necessary for decision making . 11 5.8 Request for an engineering change, a dev
12、iation permit or a concession . 12 5.9 Area affected and related management authority 13 5.10 Technical changes, deviations and concessions annulment 16 6 Evolution of configuration control throughout the programme lifecycle 17 6.1 Change of responsible authority 17 6.2 Configuration control activit
13、ies within a programme lifecycle 17 7 Specific cases . 19 7.1 Items common to several programmes . 19 7.2 Shared-programme management . 20 (informative) Document management prerequisite necessary for Configuration Annex AManagement control 21 (informative) Marking and traceability prerequisite neces
14、sary for Configuration Annex BManagement control 22 (informative) Example of technical change handling process 23 Annex CC.1 Introduction 23 C.2 Request elaboration . 23 C.3 Change request investigation 23 C.4 Change detailed design 25 C.5 Technical change implementation on product and production pr
15、ocess 26 (informative) Nonconformity handling process and relationship with configuration Annex Dcontrol . 27 D.1 General principles and scope 27 D.2 Immediate actions - Detection 28 D.3 Investigation and application of the decision . 30 D.4 Nonconformity handling process 30 prEN 9223-104:2016 (E) 3
16、 Foreword This standard was reviewed by the Domain Technical Coordinator of ASD-STANs General Domain. After inquiries and votes carried out in accordance with the rules of ASD-STAN defined in ASD-STANs General Process Manual, this standard has received approval for Publication. prEN 9223-104:2016 (E
17、) 4 Introduction The finality of Configuration Management is to assure during the whole product lifecycle1): consistency and commonality of the technical information among all actors; traceability of this technical information. For that purpose, Configuration Management organizes and implements the
18、following activities: selection of items and technical information that shall be submitted to Configuration Management, under clearly established responsibility (configuration identification); capture, keeping this information and making it available (configuration status accounting); verification a
19、nd validation of the coherence of this information at defined steps of the product lifecycle (configuration verifications, reviews and audits); technical changes and gaps processing in order to keep the consistency of this information (configuration control). 1)See EN ISO 9000. prEN 9223-104:2016 (E
20、) 5 1 Scope The present document is declined from the principles described in the EN 9223-100, it: is based on internationally-recognised concepts; proposes organisational principles and implementation processes for configuration management from both viewpoints: “programme” and “company”, with empha
21、sis on the “programme” viewpoint; deals with configuration control but not contract management methods. It is up to each person responsible for a programme to define the detailed methods of application and tailoring as necessary. 2 Normative references The following documents, in whole or in part, a
22、re 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. EN 9100, Quality Management Systems Requirements for A
23、viation, Space and Defense organizations EN 9223-100, Programme Management Configuration Management Part 100: A guide for the application of the principles of configuration management2)EN 9223-105, Programme Management Configuration Management Part 105: Glossary2)EN ISO 9000, Quality Management Syst
24、em Fundamentals and Vocabulary ISO 10007:2003 Quality management system Guidelines for configuration management 3 Terms and definitions For the purposes of this document, the terms and definitions given in EN ISO 9000, ISO 10007:2003 and EN 9200 apply. The specific terms needed to understand and to
25、use the document are the object of definitions appearing in EN 9223-105. 4 Configuration control place in the overall programme Configuration Management 4.1 Configuration control process overview As a rule, configuration control begins when the configuration baseline has been identified and then ver
26、ified, reviewed and audited. 2)Published as ASD-STAN Prestandard at the date of publication of this standard. http:/www.asd-stan.org/ prEN 9223-104:2016 (E) 6 Figure 1 Place of the configuration control process in Configuration Management processes 4.2 The Configuration Control process nature The co
27、nfiguration management process is composed of a set of actions and decisions (product and responsibilities-trees), set up in order to keep and improve consistent relationships between the configurations and the products trees: maintaining identification (updates of functional, allocated and product
28、configuration baselines, etc.); maintaining qualifications (verification of non-regression); maintaining links between the different configurations of a same item such as, links between index of definition file and index of the technical requirement specification. Configuration control is mainly a d
29、ecisional process (preparing decision and decision making, and control of decisions implementation) meant to guarantee the overtime consistency for configuration items and associated data. As such, for a given authority, configuration control exclusively concerns items and data selected during the c
30、onfiguration identification process. This set of items and data establishes the authoritys field of competence. The process is implemented as soon as the first configuration baseline is established. It addresses any effects on the configuration of (see Figure 3): needs for technical changes (includi
31、ng those following the detection of defects); technical events and anomalies. prEN 9223-104:2016 (E) 7 Within this framework, configuration control relies on an organization that: associates customers, industrial partners and suppliers to jointly carry out tasks and responsibilities; attributes a ma
32、king authority to each configuration item; attributes power delegations throughout the network of customers, partners and suppliers, according to the decisions of selection; uses mandatory or existing document management systems, (see Annex A); uses mandatory or existing technical data management sy
33、stems; uses mandatory or existing product lifecycle management systems; specifies modalities of tracking of changes as described in the Configuration Management plan. Technical events and anomalies detected and characterized throughout the product lifecycle are processed in a specific way, including
34、 as necessary (but not limited to) the following actions: describing conformity issues (actually stated or foreseeable); investigating the causes and assessing the effects; designing and implementing curative actions (e. g. rework or repairs); designing corrective and/or preventive actions; confirmi
35、ng and identifying nonconformity; issuing requests for: o concessions on the considered item; o technical changes and deviations on subsequent items. Such requests are outputs from the above described processes, and should be submitted to the competent Configuration Management authority and forms in
36、puts for the configuration control process (see Figure 3). The final consequences on the configuration may be: technical changes introduced in the updated approved configuration, the applicable configuration, and the as-built configuration; decided and implemented deviations; accepted and recorded c
37、oncessions. Possible consequences on the contractual baseline are covered by the provisions specific to contract management (amendment, endorsement or equivalent). The configuration control process is more precisely described (hereafter). Control process for concessions and deviation permits as well
38、 as the associated competence criteria, should be based on the same basic requirements. prEN 9223-104:2016 (E) 8 Figure 2 Configuration control and other interface processes 4.3 Tasks associated with configuration control 4.3.1 Identifying process The following tasks apply to all items, whether sele
39、cted or not as configuration items, even though these tasks cannot be considered as Configuration Management activities. Nonetheless, an efficient configuration control process cannot be carried out without their rigorous implementation. The Configuration Management plan shall specify details of imp
40、lementation. 4.3.2 Document management tasks The setting up of a system of identifiers permit to identify changes within a document, although it does not belong to configuration management activities (indeed, an item or a document shall have an identifier, whether it is considered as a configuration
41、 item or not). 4.3.3 Product marking Products or batches/lots marking shall permit to link these items to any control decision. Thus: this marking, thanks to the documentation of associated configuration status, can lead to know all the control decisions (change index, deviation or concession markin
42、g); serialisation marking also guarantees the traceability necessary to maintenance (interchangeability); marking ensuring interchangeability must be implemented on the specimen or on its associated accompanying documents. Marking rules could be clarified in the configuration management plan. prEN 9
43、223-104:2016 (E) 9 5 Configuration control principles 5.1 General For a specific authority, configuration control over an item encompasses the configuration documentation and associated data, “identified” as a whole. In order to define its scope of intervention, each authority3)assumes the decision
44、to recognise configuration items and data for which it has been delegated configuration management authority. 5.2 Allocation of an item to an authority The allocation of an item to an authority, and reciprocally, is deduced from an analysis based on the configuration data and items, as potentially i
45、mpacted by a control decision. This allocation rule shall be clarified in the configuration management plan. 5.3 Technical changes, deviations permits and concessions shared provisions In the following clauses, provisions common to technical changes, deviation permits and concessions and provisions
46、specific to each category will be distinguished. Each technical change, deviation permit and concession experiences its own life cycle and is subject to a decision-making process. Management process: indicates involved entities and actors (who does what?); describes process flow (how?) and the decis
47、ions to be made (what?); is tailored as the programme progresses. Two pieces of information are particularly important in the technical changes, deviation permits and concessions management procedure: the request which generally replaces the statement of need (see 5.8); the file which, from the requ
48、est, is step by step supplemented with any necessary elements (see 5.7). A simplified example of the logical progression of technical change management is presented in Annex C. NOTE In case of acknowledged emergency, and subject to previous collection of any necessary pieces of advice, this process
49、may be conducted according to a specific procedure generally called “emergency procedure”. 5.4 Technical changes process Any technical change shall meet an identified specific need (see 5.8). Any technical change exhibits the following features: once approved, the technical change is intended to stand unmodified (any cancellation or modification would require another technical change to be approved); 3)Several authority levels exist; each authority is responsible for the configur
