SIST EN 16603-10-24:2017
(Main)Space engineering - Interface management
Space engineering - Interface management
This standard describes a standard process and methodology for interface management throughout the life cycle, in terms of identification, requirements specification, definition, approval and control, implementation, verification and validation of interfaces, within a space programme or project and in accordance with the other relevant ECSS standards.
Raumfahrttechnik - Schnittstellenmanagement
Ingénierie spatiale - Gestion des interfaces
Vesoljska tehnika - Upravljanje vmesnika
Ta standard opisuje standardni postopek in metodologijo upravljanja vmesnikov v celotnem življenjskem ciklusu, kar zadeva identifikacijo, specifikacijo zahtev, opredelitev, odobritev in nadzor, izvajanje, preverjanje in potrjevanje vmesnikov v okviru vesoljskega programa ali projekta in v skladu z drugimi ustrezni standardi ECSS.
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vesoljska tehnika - Upravljanje vmesnikaRaumfahrttechnik - SchnittstellenmanagementIngénierie spatiale - Gestion des interfacesSpace engineering - Interface management49.140Vesoljski sistemi in operacijeSpace systems and operationsICS:Ta slovenski standard je istoveten z:EN 16603-10-24:2017SIST EN 16603-10-24:2017en,fr,de01-oktober-2017SIST EN 16603-10-24:2017SLOVENSKI
STANDARD
SIST EN 16603-10-24:2017
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16603-10-24
August
t r s y ICS
v {ä s v r
English version
Space engineering æ Interface management
Ingénierie spatiale æ Gestion des interfaces
Raumfahrttechnik æ Schnittstellenmanagement This European Standard was approved by CEN on
t t August
t r s xä
C 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 and CENELEC memberä
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CENæCENELEC Management Centre has the same status as the official versionsä
CEN and CENELEC members are the national standards bodies and national electrotechnical committees 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á Serbiaá Slovakiaá Sloveniaá Spainá Swedená Switzerlandá Turkey and United Kingdomä
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels y any means reserved worldwide for CEN national Members and for CENELEC Membersä Refä Noä EN
s x x r uæ s ræ t vã t r s y ESIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 2 Table of contents European foreword . 4 Introduction . 4 1 Scope . 6 2 Normative references . 7 3 Terms, definitions and abbreviated terms . 8 3.1 Terms from other standards . 8 3.2 Terms specific to the present standard . 8 3.3 Abbreviated terms. 10 3.4 Nomenclature . 10 4 Principles . 11 4.1 Type of interfaces . 11 4.2 Interface management process. 11 4.2.1 General description . 11 4.2.2 Interface management planning . 12 4.2.3 Interface identification . 12 4.2.4 Interface requirements specification . 13 4.2.5 Interface definition . 14 4.2.6 Interface approval and control . 14 4.2.7 Interface verification and validation . 17 4.3 Interface management life cycle . 17 4.3.1 Generic interface management life cycle . 17 4.3.2 Space element – Launch segment interface management life cycle . 19 4.3.3 Space segment - Ground segment interface management life cycle . 20 4.3.4 Interface management life cycle involving OTS products . 21 5 Requirements . 22 5.1 Interface management planning . 22 5.2 Interface identification . 22 5.3 Interface requirements specification . 23 5.4 Interface definition . 23 SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 3 5.5 Interface control and approval . 25 5.6 Interface verification and validation . 25 Annex A (normative) Interface Requirements Document (IRD) - DRD . 26 Annex B (normative) Interface Control Document (ICD) – DRD . 29 Annex C (normative) Interface Definition Document (IDD) or Single-end Interface Control Document – DRD . 33 Annex D (informative) Proposed content of an "Interface Identification Document (IID)" . 36 Annex E (informative) Reference interface data list . 38 Bibliography . 53
Figures Figure 4-1 Interface management process – overview of the main process steps . 12 Figure 4-2: Interface Change Management Process implementation . 16 Figure 4-3: Generic interface management life cycle . 18 Figure 4-4: Typical space to launch segment interface life cycle . 19 Figure 4-5: Typical space to ground segment interface life cycle . 20 Figure 4-6: Typical interface management life cycle involving OTS . 21
: Examples of interface data grouping in ICDs . 32
Tables Table E-1 : Identified interface natures and corresponding ECSS disciplines . 39
SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 4 European foreword This document (EN 16603-10-24:2017) has been prepared by Technical Committee CEN-CENELEC/TC 5 “Space”, the secretariat of which is held by DIN. This standard (EN 16603-10-24:2017) originates from ECSS-E-ST-10-24C. 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 February 2018, and conflicting national standards shall be withdrawn at the latest by February 2018. 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. This document has been prepared under a standardization request given to CEN by the European Commission and the European Free Trade Association. This document has been developed to cover specifically space systems and has therefore precedence over any EN covering the same scope but with a wider domain of applicability (e.g. : aerospace). 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, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 5 Introduction The management and control of interfaces is crucial to the success of space programmes and projects. Interface management is a process to assist in controlling product development when efforts are divided amongst different parties (e.g. agencies, contractors, geographically dispersed technical teams). Interface control is also needed to define, achieve and maintain compliance between products and actors that interoperate. The application of this standard to a project is expected to bring the following benefits: • a consistent, coherent and commonly used approach – including documentation – throughout industry and across different projects; • effective and efficient product interface management; • minimize the risk of interface incompatibilities; • high confidence in achieving successful product operations for the intended use.
SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 6 1 Scope The objective of interface management is to achieve functional and physical compatibility amongst all interrelated items in the product tree. The goal of this standard is to define a common and systematic process to meet the objective.
This standard describes a standard process and methodology for interface management throughout the life cycle, in terms of identification, requirements specification, definition, approval and control, implementation, verification and validation of interfaces, within a space programme or project and in accordance with the other relevant ECSS standards. In line with the definition of the Space System breakdown in Figure 2-1 of ECSS-S-ST-00-01, this standard is applicable to the following interfaces, where a contractual relationship exist among parties: • within the Space Segment • within the Ground Segment • between the Space Segment and the Ground Segment • between Space Segment and Launch Segment only for ICD aspects in conformance to the launcher user manual. This standard does not ensure that all the specificities of interfaces within the Launch Segment are covered. This standard is applicable to development of products at all different levels in the product tree. It is applicable to both the customer and the supplier of the product during all project phases (0 to F) and follows the generic ECSS customer/supplier pattern. This standard may be tailored for the specific characteristics and constrains of a space project in conformance with ECSS-S-ST-00. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 7 2 Normative references The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revision of any of these publications do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the more recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.
EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS - Glossary of terms EN 16003-10 ECSS-E-ST-10 Space engineering - System engineering general requirements EN 16003-10-02 ECSS-E-ST-10-02 Space engineering - Verification EN 16003-10-06 ECSS-E-ST-10-06 Space engineering - Technical requirements specification EN 16001-10 ECSS-M-ST-10 Space project management - Project planning and implementation EN 16001-40 ECSS-M-ST-40 Space project management - Configuration and information management EN 16002-10-09 ECSS-Q-ST-10-09 Space product assurance - Nonconformance control system
SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 8 3 Terms, definitions and abbreviated terms 3.1 Terms from other standards a. For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 apply, in particular for the following terms: 1. approval 2. baseline 3. configuration baseline 4. customer 5. interface 6. supplier b. For the purpose of this Standard, the following term and definition from
ECSS-E-ST-10-06 applies: 1. verification requirements c. For the purpose of this Standard, the following terms and definitions from ECSS-M-ST-40 apply: 1. change request 2. change proposal 3.2 Terms specific to the present standard 3.2.1 controlled ICD ICD formally issued subject to configuration control process 3.2.2 external interface interface between items under different programme responsibilities 3.2.3 frozen ICD ICD formally issued subject to configuration control process and signed by interface responsible and all the involved actors NOTE 1 A “frozen” ICD reflects the design baseline that is considered, for the interface related aspects, to be final and complete allowing start of manufacturing, integration, implementation and testing activities. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 9 NOTE 2 Change of a “frozen” ICD can occur but it usually implies a major cost or schedule impact. 3.2.4 interface actor responsible for the design, development and verification of one interface end
The interface actors are all parties involved in the interface ends definition, design, development. 3.2.5 interface control document (ICD) document defining the design of the interface(s) 3.2.6 interface definition document (IDD) document defining the design of one interface end 3.2.7 interface end one side of an interface
An interface end is the point of interaction of one of the elements of an interface. 3.2.8 interface identification document document defining the index of all identified interfaces
3.2.9 interface plane plane that distinguishes the two interface ends that interface with each other 3.2.10 interface requirement document (IRD) document defining the requirements for an interface or a collection of interfaces. 3.2.11 interface responsible responsible for the requirement specification, definition, development and verification of the interface
The interface responsible is the customer or his delegate, as an example for space segment to launch segment interface, it is the entity procuring both or its delegates. 3.2.12 internal interface interface between items within the same programme responsibility 3.2.13 preliminary ICD draft ICD circulated and iterated during interface definition phase before issuing a controlled ICD SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 10 3.3 Abbreviated terms For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01 and the following apply: Abbreviation Meaning CCSDS Consultative Committee for Space Data Systems CR change request CP change proposal ECSS European Cooperation for Space Standardization ICD interface control document IDD interface definition document IID interface identification document IRD interface requirements document OTS off-the-shelf
3.4 Nomenclature The following nomenclature applies throughout this document: a. The word “shall” is used in this Standard to express requirements. All the requirements are expressed with the word “shall”. b. The word “should” is used in this Standard to express recommendations. All the recommendations are expressed with the word “should”. NOTE
It is expected that, during tailoring, recommendations in this document are either converted into requirements or tailored out. c. The words “may” and “need not” are used in this Standard to express positive and negative permissions, respectively. All the positive permissions are expressed with the word “may”. All the negative permissions are expressed with the words “need not”. d. The word “can” is used in this Standard to express capabilities or possibilities, and therefore, if not accompanied by one of the previous words, it implies descriptive text. NOTE
In ECSS “may” and “can” have completely different meanings: “may” is normative (permission), and “can” is descriptive. e. The present and past tenses are used in this Standard to express statements of fact, and therefore they imply descriptive text.
SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 11 4 Principles 4.1 Type of interfaces In a Space System there can be three major types of interfaces. • interfaces within the Space Segment, Ground Segment or Launch Segment. • interfaces between the different Segments of the Space System.
• interfaces between the Support Segment and the Space Segment, Ground Segment or Launch Segment. Refer to Figure 2-1 of ECSS-S-ST-00-01 for details on Space System breakdown. In addition, a distinction can be made between internal and external interfaces. The notion of internal or external depends on the position and role of an actor in the customer supplier chain.
An internal interface is an interface under the control of a given actor. An external interface is an interface outside the control of a given actor. For example, an interface between two suppliers of the same customer is considered external by the suppliers and internal by the customer. 4.2 Interface management process 4.2.1 General description The interface management process is applied at all levels of the supplier/customer chain. The standard describes the process at one level, between one customer and its lower tier suppliers. The customer or his delegate is responsible for the definition, development and verification of the interface. In addition to the interface responsible, the interface actors are all the parties involved in the interface end definition, design, development. This process can impact the similar activities done at higher or lower levels. As per ECSS-S-ST-00-01, the term “product” is used in the standard as a generic term which defines any component, equipment or element. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 12 Annex E provides a non-exhaustive list of interface data, that can be used as a basis for interface specification, definition and control. Figure 4-1 provides an overview of the interface management process.
Figure 4-1 Interface management process – overview of the main process steps 4.2.2 Interface management planning
At the beginning of the project, each customer defines the approach, the requirements, the responsibilities and the planning for the management of the interfaces. 4.2.3 Interface identification At the beginning of the project, each customer identifies the interfaces under his responsibility. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 13 This process is repeated by each actor at each level of the customer/supplier chain. The interface identification is based on product architecture definition, i.e.: • Product functions identification/definition • Product decomposition into elements • Functions allocation to elements Then the interface identification is further detailed according to the product architecture decomposition. The identified interfaces can be compiled into a list, including identification of the involved suppliers, as well as the references to the applicable technical documentation. The output of the interface identification process can be documented in an Interface Identification Document (IID). An example of an IID is given in the informative Annex D. The IID is a living document which is populated and updated during the interface life cycle, with the references to IRD, ICD, IDD, CR when they become baselined. The IID becomes therefore the repository that defines and governs the interface baseline status and their unique identification. 4.2.4 Interface requirements specification Following the interfaces identification, each customer defines the requirements for each interface. The establishment of interface requirements is part of the requirement engineering process as defined in ECSS-E-ST-10 clause 5.2. The interface requirements on the identified interfaces are derived from the higher level requirements and functional, logical and physical architectural decomposition, as well as the verification requirements. An interface requirement defines the functional, performance, electrical, environmental, human, and physical requirements that exist at a common boundary between two or more products. When the interface requirements specification is completed and baselined, it defines all the design requirements to be adhered to by the supplier who is responsible for the design, development and verification of the interface ends. The output of the interface requirements specification process is documented in IRDs or in technical requirement specifications. An IRD applies to the entire interface, including all interface ends. For each interface requirement, applicability for involved interface end is specified (e.g. one interface end, all interface ends). The use of an IRD as a self-standing document is not mandatory, however it facilitates consistency of the interface requirements among all involved actors.
SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 14 IRDs are useful when separate actors are developing components of the system or when the system places requirements on other systems outside programme/project control. 4.2.5 Interface definition Interface definition is the process of developing a design solution compliant with the applicable interface requirements that ensures compatibility between the involved products. The definition of an interface is the result of the design activities performed by the customer or his delegate who is responsible for the interface as a whole and by the actors who are responsible for their interface ends. The inputs for this activity are the IRD(s) provided by the customer and the various interface end definitions of the products as provided by the suppliers. The definition of the product interface end can be provided in the form of Interface Definition Document (IDD) or “single-end” Interface Control Document (ICD).
The ”single-end” ICD is sometimes referred as “unit ICD” or “equipment ICD”. The interface definition process is an iterative and converging process, where the number of modifications decreases over time. The output of the interface definition process is documented in ICD ready to be formally agreed by all parties. The interfaces can be grouped according to contractual, discipline or product decomposition (product tree). As part of this process, evolutions may happen leading to an update of IRD(s) 4.2.6 Interface approval and control Following the interface definition process, the interface control is formalized by issuing the ICD(s) in two steps: 1. controlled ICD 2. frozen ICD The controlled ICD reflects an evolving interface definition, which converges from supplier preliminary design to final one.
The frozen ICD reflects interface baseline considered to be final and complete allowing start of manufacturing, integration, implementation activities. Both steps are formally issued and subject to configuration control process.
The controlled ICD is signed by the interface responsible only, while the frozen ICD is signed by the interface responsible and all the involved actors, to reflect acceptance.
Signature of all involved parties can be anticipated on controlled ICD. Any evolution needs to be controlled, and modification approved by all actors. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 15 Since the controlled ICD reflects an evolving interface definition, the evolutions can be controlled in a less formal way, avoiding unnecessary delays and unjustified programmatic impact. The changes to the IRD and ICD are managed through the generic change control process defined in ECSS-M-ST-40, as follows. A Change Request (CR) is generated by the interface responsible and used to support the Interface Change Management process.
In case the modification is initiated by a supplier:
• When the ICD is in controlled status (not yet signed), this initiation is done by any means agreed between the supplier and the customer. • When the ICD is in frozen status (signed), this initiation is done through a Change Proposal (CP), to be referenced in the CR. The CR defines in detail a technical change proposal to an existing and baseline ICD (including any already approved CRs affecting the interface). The CR description includes a graphic or textual description of the change in sufficient detail to permit a clear evaluation, including: • Modification from original to new content • Deletion of existing content • Addition of new content • Effectivity (i.e. point in time or in production series when the change becomes effective) • Urgency, indication of whether this change is critical or routine (if dedicated procedures are defined by the project to manage urgency) The CR is analyzed and discussed by all involved actors.
For the controlled ICD, the change process is considered completed by the signature of the CR by interface responsible and all the involved actors. For the controlled ICD, there is no need that suppliers produce a CP unless it is justified, since the ICD modification is normally the results of detailed design activities, which improve interface data definition, rather than a real design change. For the frozen ICD, each supplier provides their impacts by a CP, to be approved by the Customer before implementation. When agreed and signed by all parties, CR becomes an accepted modification of the interface baseline, to be incorporated in a new issue of the ICD. Until the new ICD issue is released, the interface definition baseline consists of the current ICD plus the agreed CRs. A typical workflow interface change management process is shown in Figure 4-2. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 16
Figure 4-2: Interface Change Management Process implementation SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 17 4.2.7 Interface verification and validation Interface requirements are subject to the same verification process as defined in ECCS-E-ST-10-02, as any other requirements. This process is done in three steps: 1. Early verification of compatibility of the ICD with the interface requirements, resulting in a signed version of the ICD by both supplier and customer (part of the approval process). 2. Stand-alone interface end demonstration of compliance with the ICD taking into account the verification requirements associated to interface requirements, performed under the responsibility of the supplier of the relevant product (to be done prior to the delivery of each product). 3. Joint verification of the interface in terms of functions and performances, involving the different interfacing products, performed under responsibility of the customer (with supplier support) during the integration of the various products, taking into account the verification requirements from higher levels. The verification logic can include any combination of joint and stand-alone verification activities. Interface validation is the activity to demonstrate that the interface is able to accomplish its intended use in the intended operational environment, and can be performed as part of interface management or as part of any higher level product validation activity.
4.3 Interface management life cycle 4.3.1 Generic interface management life cycle Figure 4-3 shows a generic life cycle referred to a typical interface involving customer and two suppliers.
In case more than two levels of customer/supplier are involved, this process is repeated recursively by each actor at each level of the customer/supplier chain. This life cycle applies to product categories C and D as defined in ECSS-E-ST-10-02 Table 5-1. The life cycle starts with the identification of the interfaces by the customer (typically between customer SRR and PDR). After Customer PDR, the Interfaces Requirements applicable to Suppliers are identified and specified by the customer either in a self-standing IRD or embedded in a technical specification applicable to supplier, prior to suppliers’ contract start. After the supplier's requirements are baselined, the customer establishes the preliminary interface definition, circulating it among the involved actors. SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 18 The suppliers provide IDDs and relevant technical design data. The preliminary ICD is consolidated, formally issued and becomes the controlled ICD for Suppliers’ PDR. After this stage, changes of the controlled ICD are possible in accordance with the simplified interface control process defined in clause 5.5. Prior to the Suppliers’ CDRs, under the responsibility of the customer, suppliers and customer consolidate the controlled ICDs to become frozen, and approved by all parties
The approved frozen ICD is considered the final ICD, ready to permit the suppliers to start manufacturing, integration, implementation, or verification activities. After reaching this stage, changes of the frozen ICD are possible in accordance with the interface control process defined in clause 5.5.
Figure 4-3: Generic interface management life cycle SIST EN 16603-10-24:2017
EN 16603-10-24:2017 (E) 19 4.3.2 Space element – Launch segment interface management life cycle Figure 4-4 shows a life cycle r
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.