Ecss M ST 40c Rev.1 (6march2009)

ECSS-M-ST-40C Rev.
1
6 March 2009
Space project management

Configuration and information management
ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands
ECSSMST40CRev.1 6March2009
Foreword This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associationsforthepurposeofdevelopingandmaintainingcommonstandards.Requirementsinthis Standardaredefinedintermsofwhatshallbeaccomplished,ratherthanintermsofhowtoorganize and perform the necessary work. This allows existing organizational structures and methods to be appliedwheretheyareeffective,andforthestructuresandmethodstoevolveasnecessarywithout rewritingthestandards. This Standard has been prepared by the ECSSMST40 Working Group, reviewed by the ECSS ExecutiveSecretariatandapprovedbytheECSSTechnicalAuthority.
Disclaimer ECSSdoesnotprovideanywarrantywhatsoever,whetherexpressed,implied,orstatutory,including, butnotlimitedto,anywarrantyofmerchantabilityorfitnessforaparticularpurposeoranywarranty that the contents of the item are errorfree. In no respect shall ECSS incur any liability for any damages,including,butnotlimitedto,direct,indirect,special,orconsequentialdamagesarisingout of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty,businessagreement,tort,orotherwise;whetherornotinjurywassustainedbypersonsor propertyorotherwise;andwhetherornotlosswassustainedfrom,oraroseoutof,theresultsof,the item,oranyservicesthatmaybeprovidedbyECSS.
Publishedby:
Copyright:
ESARequirementsandStandardsDivision ESTEC, P.O. Box 299, 2200 AG Noordwijk The Netherlands 2009 by the European Space Agency for the members of ECSS
Change log
ECSSM40A 19April1996 ECSSM40B 20May2005 ECSSMST40C 31July2008
Firstissue
Secondissue
Thirdissue This issue combines the contents of ECSSM40B and ECSSM50B. Itsupersedesthesetwostandards. The descriptive text of the previous standards has been combined and rewrittentodeleteduplications. TherequirementsofECSSM40BandECSSM50Bhavebeenmaintained withfollowingmainchanges: Requirements on product tree and DRD were deleted and moved to ECSSMST10C. Configuration management plan DRD from ECSSM40B and Information/documentationmanagementplanfromECSSM50Bwere merged into the Configuration management plan DRD in the current Standard.
Thirdissuerevision1 ChangeswithrespecttoversionC(31July2008)areidentifiedwith revisiontracking.
Table of contents
Change log .................................................................................................................3 Introduction................................................................................................................7 1 Scope.......................................................................................................................8 2 Normative references .............................................................................................9 3 Terms, definitions and abbreviated terms..........................................................10
3.1 3.2 3.3 Terms from other standards .....................................................................................10 Terms specific to the present standard ....................................................................10 Abbreviated terms .................................................................................................... 12
4 Configuration management principles ...............................................................14

4.1 Overview ..................................................................................................................14 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 Configuration and information/documentation activities ............................. 14 Configuration management process and objectives................................... 14 Information/documentation management process and objectives ............. 15 Configuration management plan ................................................................ 16 Configuration management interfaces........................................................ 16 Overview.....................................................................................................18 Configuration identification ......................................................................... 20 Configuration control .................................................................................. 24 Configuration status accounting ................................................................. 26 Configuration verification ............................................................................ 27 Configuration management process audit.................................................. 27 Configuration management approach for operational phase ..................... 27 Implementation of information/documentation management...................... 28
Management and planning.......................................................................................16
Implementation of configuration management ......................................................... 18
5 Configuration management requirements .........................................................33

5.1 5.2 General.....................................................................................................................33 Management and planning.......................................................................................33
ECSSMST40CRev.1 6March2009 5.2.1 5.2.2 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.3.7 Configuration management plan ................................................................ 33 Configuration management interfaces........................................................ 34 Configuration identification ......................................................................... 34 Configuration control .................................................................................. 39 Configuration status accounting ................................................................. 41 Configuration verification ............................................................................ 42 Audit of the configuration management system ......................................... 43 Configuration management approach for operational phase ..................... 43 Implementation of information/documentation management...................... 44
Implementation of configuration management ......................................................... 34
Annex A (normative) Configuration management plan - DRD.............................49 Annex B (normative) Configuration item list - DRD..............................................56 Annex C (normative) Configuration item data list (CIDL) - DRD..........................58 Annex D (normative) As-built configuration list - DRD ........................................60 Annex E (normative) Software configuration file (SCF) - DRD ............................62 Annex F (normative) Configuration status accounting reports -DRD.................65 Annex G (normative) Change request - DRD ........................................................68 Annex H (normative) Change proposal - DRD ......................................................70 Annex I (normative) Request for deviation - DRD.................................................72 Annex J (normative) Request for waiver - DRD ....................................................74 Annex K (informative) Configuration item selection ............................................76 Annex L (informative) Technical data package description ................................78 Annex M (informative) Digital signature ..............................................................100 Bibliography...........................................................................................................103 Figures
Figure 4-1 Configuration management...................................................................................15 Figure 4-2 Configuration management interface (inputs)....................................................... 17 Figure 4-3 Configuration management interface (outputs)..................................................... 18 Figure 4-4 Implementation of configuration management...................................................... 20 Figure 4-5 Configuration identification....................................................................................21 Figure 4-6 CI product tree structure ....................................................................................... 22
ECSSMST40CRev.1 6March2009 Figure 4-7 Configuration control.............................................................................................25 Figure 4-8 Implementation of information/documentation management ................................ 28 Figure 4-9 TDP contents ........................................................................................................30 Figure 4-10 Delivery process for TDP ....................................................................................31 Figure 4-11 Project phases and baseline definitions.............................................................. 32 Figure L-1 TDP ZIP file........................................................................................................... 79 Figure L-2 : ZIP archive.......................................................................................................... 80 Figure L-3 : XML schema tree................................................................................................ 80 Figure M-1 Digital signature .................................................................................................101
Tables
Table G-1 : Change request scope and content .................................................................... 69 Table H-1 : Change proposal scope and content................................................................... 71 Table I-1 : Request for deviation scope and content.............................................................. 73 Table J-1 : Request for waiver scope and content ................................................................. 75 Table L-1 : data_package.......................................................................................................82 Table L-2 : data_definition_exchange .................................................................................... 82 Table L-3 : item_properties ....................................................................................................87 Table L-4 : element ................................................................................................................ 88 Table L-5 : database .............................................................................................................. 98 Table L-6 : Additional information on Table L-1 to Table L-5 ................................................. 99
Introduction
This document defines the configuration management information/documentationrequirementsforspaceprojects. and
The document is structured into two main parts, the first part presenting the processesandthesecondoneprovidingthedetailedrequirements. In addition, the expected configuration and information/documentation management documentation is specified in the annexed document requirementsdefinitions(DRDs).
1 Scope
The scope of this standard is to describe the processes and provide the requirements for managing the information/documentation and configuration ofproductswithinaspaceprogrammeorproject. The requirements specified herein apply to, and affect the supplier and customeratalllevels. Thisstandardmaybetailoredforthespecificcharacteristicsandconstraintsofa spaceprojectinconformancewithECSSSST00.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references,subsequentamendmentsto,orrevisionsofanyofthesepublications donotapply.However,partiestoagreementsbasedonthisECSSStandardare encouragedtoinvestigatethepossibilityofapplyingthemostrecenteditionsof the normative documents indicated below. For undated references the latest editionofthepublicationreferredtoapplies. ECSSSST0001 ECSSMST10 ECSSQST1009 ECSSQST20 ECSSsystemGlossaryofterms Space project management Project planning and implementation SpaceproductassuranceNonconformancecontrol system SpaceproductassuranceQualityassurance
3 Terms, definitions and abbreviated terms

3.1 Terms from other standards
ForthepurposeofthisStandard,thetermsanddefinitionsfromECSSSST00 01apply,inparticularforthefollowingterms: configuration configuration baseline configuration control configuration document configuration identification configuration item configuration management
3.2
Terms specific to the present standard

3.2.1 change control
activity for control of changes or departures to the product after formal approvalofitsconfigurationbaseline NOTE AdaptedfromISO10007.
3.2.2
class 1 change
changethataffectsapprovedtechnicalspecifications,includinginterfacesofthe samelevel,andassociatedtermsofthebusinessagreementbetweenacustomer andhissupplier
3.2.3
class 2 change
changethatdoesnotfulfilclass1changecriteria
3.2.4
configuration control board
person or a group of persons assigned responsibility and authority to make decisionsontheconfiguration NOTE1 This configuration control board is called dispositioningauthorityinISO10007. NOTE2 Relevantinterestedpartieswithinandoutsidethe organization are represented on the configuration controlboard.
10
NOTE3 AdaptedfromISO10007.
3.2.5
configuration definition document
document that defines the physical configuration and establishes the item or material identification code (part or identifying number) at any level in the productstructure NOTE AdaptedfromASMEY14.100.
3.2.6
configured item
anylevelofproductwhosefunctionalorphysicalcharacteristicsarerecordedin aretrievable,consistentmanner
3.2.7
departure
inability of a product to meet one of its functional performance or technical requirements NOTE1 Twotypesexist: planned departure resulting in request for deviation,and unplanned departure resulting in request for waiver. NOTE2 Departures do not change the engineering documentation.
3.2.8
information/documentation management
processforensuring timely and effective creation, collection, review, delivery, storage,andarchivingofprojectinformation
3.2.9
information system
set of resources, procedures and data required in support of project managementprocesses
3.2.10
metadata
metadata are structured, encoded data that describe characteristics of in formationbearing entities to aid in the identification, discovery, assessment, andmanagementofthedescribedentities NOTE Adapted from Committee on Cataloguing Task ForceonmetadataSummaryReport.
3.2.11
product item
elementoftheproducttreehavingauniqueidentifier
3.2.12
self-signed certificate
certificateautogeneratedbythesigner
3.2.13
technical data package
ZIPfilecontainingstructuredcollectionoffileswiththeirrelatedmetadata,to beexchangedbetweeninformationsystems
11
NOTE AdaptedfromISO10303AP232TDPdefinition.
3.2.14
technical description
technical definition in terms of documentation of a product, e.g. functional or performance, and design requirements, test and verification documentation, analyses,drawings,partsandmateriallists,processesandtooling.
3.3
Abbreviated terms
ForthepurposeofthisStandard,theabbreviatedtermsfromECSSSST0001 andthefollowingapply:
Abbreviation
ABCL AR CAD CAGE CCB CD CDR CI CIDL CM CP CR CSA DB DCB DRD DRL DUNS DXF EIDP FCB FCV FTP H/W ICD IDM IEC IETF IS
Meaning
asbuiltconfigurationdatalist acceptancereview computeraideddesign commercialandgovernmententity configurationcontrolboard compactdisk criticaldesignreview configurationitem configurationitemdatalist configurationmanagement changeproposal changerequest configurationstatusaccounting designbaseline developmentconfigurationbaseline documentrequirementsdefinition documentrequirementslist datauniversalnumberingsystem drawingexchangeformat enditemdatapackage functionalconfigurationbaseline functionalconfigurationverification filetransferprotocol hardware interfacecontroldocument informationdocumentationmanagement InternationalElectrotechnicalCommission internetengineeringtaskforce informationsystem
12
ISO ITU JPEG LZW MOB MS NATO NCR OTS PA PCB PCV PDF PDR PI PMP PRR QR RFD RFW RID ROM SCF SMTP SRR STEP S/W TDP TIFF TRR TS WBS XML InternationalOrganizationforStandardization InternationalTelecommunicationUnion jointphotographicexpertsgroup LempelZivWelch missionobjectivebaseline Microsoft NorthAtlanticTreatyOrganization nonconformancereport offtheshelf productassurance productconfigurationbaseline physicalconfigurationverification portabledocumentformat preliminarydesignreview productitem parts,materialsandprocesses preliminaryrequirementsreview qualificationreview requestfordeviation requestforwaiver reviewitemdiscrepancy readonlymemory softwareconfigurationfile simplemailtransferprotocol systemrequirementsreview standardfortheexchangeofproduct software technicaldatapackage taggedimagefileformat testreadinessreview technicalspecification workbreakdownstructure extensiblemarkuplanguage
13
4 Configuration management principles

4.1 Overview
4.1.1 Configuration and information/documentation activities
Configuration and information/documentation management are interrelated processes for managing projects. The main activities of these processes, depictedinFigure41,are: managementandplanning; implementationofCMactivities,i.e.configurationidentification,control, statusaccounting,andverificationandaudit; implementation of IDM activities, i.e. creation, collection, review, delivery,storageandretrieval,andarchiving.
4.1.2
Configuration management process and objectives
Configuration management is the process for establishing and maintaining a consistent record of a products functional and physical characteristics compared to its design and operational requirements. Configuration management is applied throughout the entire life cycle of the product and allowsoneto: knowatanytimethetechnicaldescriptionofaproductusingapproved documentation; recordandcontroltheevolutioninthetechnicaldescriptionofaproduct (e.g.systemanditsproducts); provide traceability of the evolution of the products technical description; ensuretheconsistencyoftheinternalinterfaces; verify and demonstrate to all actors that documentation is and remains theexactimageoftheproductsitdescribes; identifythecurrentconfigurationbaselineandtheasbuiltconfiguration of a product, to record discrepancies detected during production, deliveryoroperationanddispositionedforfurtheruse; enableanyactortoknowtheoperationalpossibilitiesandlimitationsof eachproductitemand,incaseofnonconformance,toknowwhichitems areaffected.
14
NOTE:
Corrective actions are improvements on the process itself as a consequence of lessons learned and any feedback provided on the project
Figure41Configurationmanagement
4.1.3
Information/documentation management process and objectives
Information/documentationmanagementistheprocessforensuringtimelyand effectivecreation,collection,review,delivery,storage,andarchivingofproject information. To achieve this objective, all recorded project information is managedelectronically. Information/documentation management is applied throughout the entire life cycleoftheprojectandallowssomeoneto ensure the correctness, accessibility, rapid availability, reliability and security of information provided to all the actors both internal and externaltotheproject; ensure the coherence of the overall project information, thus facilitating effectiveandefficientuseoftheinformation; ensurethatalltheactorswhoneedaccesstoinformationareawareofits availability,themeansofaccess,andrelatedmethodsandprocedures; supporttheprogramme/projectreporting.
15
4.2
Management and planning

4.2.1 Configuration management plan
The customer defines the configuration management requirements for a programmeorproject.Theserequirementsareapplicabletoalltheactorsofthe programme or project as defined by the customer at each level towards his supplier(s). Each supplier produces a configuration management plan (CM plan) responding to his customers configuration management requirements. The CM plan is submitted to the customer for approval. Upon customer approval,thesupplierexecuteshisownCMplanandensuresthathislowertier suppliersexecutetheirCMplan. ThepurposeoftheCMplanistodefinetheprocessandresourcesformanaging the configuration of the product in a controlled and traceable manner throughouttheprogrammeorprojectlifecycle.Italsodescribesthemeansfor an efficient comparison between the predicted (asdesigned) and the actual (asbuilt) configuration of the delivered product. It defines the relationship with the project management, system engineering and quality management process. It either provides all elements necessary to ensure that the implementation of theinformation/documentationmanagementmeetsallcustomerrequirements, and that it is in line with the programme or project organization and managementstructure. The customer defines the programme or project phase during which the CM planispreparedandapproved. Each actor assigns a person responsible for implementing configuration management activities and for implementing information/documentation management activities within his programme or project team. His role, responsibilitiesandauthoritiesaredescribedintheCMplan.
4.2.2
Configuration management interfaces
Configuration management and Information/documentation management are integral parts of project management. Configuration management interfaces with engineering, product assurance, manufacturing and production and contributes to programme or project organization and their schedule for execution by identifying all constraints related to the business agreement provisions. Information/documentation management interfaces with configurationmanagementanditcontributestoprogrammeorprojectactivities by provision of all the necessary information through the information system. The information system is a repository of information where the project disciplinesimplementdataandactivateprocesses.Theseinterfacesareusedto establishtheconfigurationmanagementprocess. NecessaryinputsforconfigurationmanagementaredepictedinFigure42. Figure43summarizestheoutputsprovidedbyconfigurationmanagementand Information/documentationmanagementtootherprojectactivities.
16
Otherproject management activities Managementrequirementsandschedule Logistic/Maintenanceplan Requestforchanges RIDs
Configurationmanagement Product assurance Requestforchanges Projectdocumentation RIDs Engineering Information/documentation management Engineeringrequirements Producttree Requestforchanges Projectdocumentation RIDs
Figure42Configurationmanagementinterface(inputs)
17
Otherproject management activities CIs+Configurationitemlist Dispositionedchanges(CPs,RFDs,RFWs) Configurationstatusaccountingreports Validatedbaseline CMproposedcorrectiveactions ValidatedCMsystem
Configurationmanagement Product assurance CIs+Configurationitemlist Baselinecontent(agreedsetof documents) Dispositionedchanges(CPs,RFDs, RFWs) Configurationitemdatalist/Software configurationfile Asbuiltconfigurationlistdefinition Validatedbaseline ValidatedCMsystem Reliableandsecureinformation Engineering Information/documentation management CIs+Configurationitemlist Baselinecontent(agreedsetof documents) Dispositionedchanges(CPs,RFDs, RFWs) Configurationitemdatalist/Software configurationfile Validatedbaseline Reliableandsecureinformation
Figure43Configurationmanagementinterface(outputs)
4.3
Implementation of configuration management

4.3.1 Overview
Implementation of configuration management comprises definition, organization,executionandsupervisionofthefollowingactivities,asdepicted inFigure44: Configurationidentification

toidentifytheproductarchitecture; to select configuration items and to define their configuration documents; toestablishmeansforidentifyingproductsanddocumentation; todefineidentificationrequirementsforsoftwaremedia; to establish configuration baselines for the purpose of requirementsanddesignmanagement.
18
Configurationcontrol
toestablishandimplementachangecontrolprocessforindividual productsandsystems,andtheirinternalandexternalinterfaces; to record and control the configuration of a product at any time duringitsevolution; torecordthedifferentconfigurationsofaproduct; to define and maintain software libraries or repositories where current and historic software baselines are stored in a controlled environment; to store and maintain software products and relevant media includingbackupcopiesinacontrolledenvironment.
Configurationstatusaccounting
to provide a product definition by reference to approved and recordedconfigurationstatuses; to enable access to software libraries according to established privileges.
Configurationverificationandaudit
to verifyand demonstrate that the product meets its documented functional,performanceandphysicalcharacteristics; to verify that the configuration management system is effective and meets the programme or project configuration management requirements.
Implementation of information/documentation management comprises the activitiesdepictedinFigure48anddescribedinclause4.3.8.
19
Figure44Implementationofconfigurationmanagement
4.3.2
4.3.2.1
Configuration identification
Overview
Configurationidentification,asdepictedinFigure45,incrementallyestablishes and releases controlled documentation for the purpose of identifying configurationcharacteristicsofaproductuntilitisfullydefinedwithrespectto its intended functional, performance and physical characteristics, thereby ensuringthecontinuousintegrityoftheproductconfiguration. Configuration identification also provides the basis for evolution through controlledchangesandstatusaccountingofaproductthroughoutitslifecycle. Itensuresthatallprogrammeorprojectdisciplinesareprovidedwithidentical documentationfortheiruse. Byapplyingproductitemidentifierstotheproduct,configurationidentification enablestraceabilityfromtheproducttoitsdefiningdocumentation. Theproductitemidentifierisrepresentedthroughtheitemidentificationcode established by the governing configuration definition document. The product itemidentifiercanbe a. b. c. the same code applied for identifying the configuration definition document, acodecontainingthiscode,or adifferentcodedefinedwithintheconfigurationdefinitiondocument.
20
NOTE To avoid the possible existence of the same product item identifier for different product item(s),acommonpracticeistoprefixtheproduct item identifier with an enterprise identifier, such asaDUNSnumber,orNATOCAGEcode.
Individual unit identification of a product can also include an additional identifier,suchasaserial(orfabrication)number,orlot(orbatch)number.
Figure45Configurationidentification 4.3.2.2 Configuration item
Configuration items, as defined in ECSSSST0001, fall into two categories, whichare:
4.3.2.2.1
Developed configuration item
This is a configuration item subject to development and fully or partially designedfortheprogrammeorproject.Itsconfigurationmanagementconforms to the programme or project configuration management requirements and is carriedoutbythesupplierresponsibleforitsdevelopment.
4.3.2.2.2
Non-developed configuration item
Thisisaconfigurationitembeingastandardizedorofftheshelfproductthat is not developed specifically for the programme or project. It is subject to supplier definition documentation and configuration management. This CI category also includes any product that has been developed and qualified for another programme or project with comparable requirements and which is usedwithoutmodification. ConfigurationmanagementofnondevelopedCIsconformstotheprogramme or project configuration management requirements to the extent necessary for itsintegrationintothenexthigherlevelconfigurationitem.
21
4.3.2.3
Selection of configuration items
The product tree, as defined in ECSSMST10, is used for the selection of configuration items and serves as a basis for the programme or project work breakdownstructure. Configuration items are identified at various levels of the product tree, as depicted in Figure 46, and defined at least by a technical specification. Configurationitemassignmentprovidesthemeansforconfigurationcontrolof theproduct.EachCIbecomesalsoaconfigureditemduringitsdevelopment. Selection of configuration items starts at the early definition phase of a programmeorprojecttobuildamanageablesetofhardwareorsoftwareitems. TheresponsibilityforidentifyinganitemasaCIrestswiththecustomer,unless delegatedbyhimtothesupplier. No fixed rules govern the selection of configuration items. The process for selectingconfigurationitemsreliesongoodsystemengineeringjudgment,and configuration management experience, supported by cost tradeoff considerations.
Customer/supplierlevel System Supplier/lowertiersupplierlevel
CI
CI
CI(*)
(*)inbothlevels
CI
CI
CI
Figure46CIproducttreestructure 4.3.2.4 Configuration baseline
Configuration baselines represent the approved status of requirements and designatkeymilestonesoftheprogrammeorprojectandprovidethepointof departureforfurtherevolution(seeFigure411).Theseconfigurationbaselines areapplicabletobothhardwareandsoftware. A configuration baseline comprises the documentation that describes the characteristics of a product. This documentation is formally designated as the configurationreferenceatakeypointintheproductlifecyclecorrespondingto a major product definition event. Any subsequent change of a product characteristic proposed for this documentation is subject to a formal change
22
procedure involving all the actors and disciplines concerned before it can be incorporated. During the life cycle of the product, configuration baselines are elaborated in thefollowingsequence: Mission objective baseline (MOB) is established at PRR based on the approved functional specification. This baseline establishes the purpose of the system, its associated constraints and environments, the operationalandperformancescapabilitiesforeachphaseofitslifecycle, andthepermissibleflexibility. Functional configuration baseline (FCB) is established at SRR based on theapprovedsystemtechnicalspecification.Thisbaselineestablishesthe systemscharacteristicsintermsofitstechnicalrequirements,aswellas thecriteriaandcorrespondinglevelsofqualificationandacceptance. Development configuration baseline (DCB) is established at PDR based on approved technical specifications (TS). This baseline establishes the products characteristics in terms of technical requirements and design constraints,aswellastheirverificationconditions. NOTE FCB and DCB are also named Requirements baselinesindifferentstandards.
Designbaseline(DB)isestablishedatCDRbasedontheapproveddesign documentation. Productconfigurationbaseline(PCB)isestablishedatFCV/PCVforserial production, or QR/AR for prototypes based on the approved set of documents containing all the functional and physical characteristics requiredforproduction,acceptance,operation,supportanddisposal.
Thelogbook,asinECSSQST20,isestablishedatsuccessfulcompletionofthe acceptancereviewandismaintainedduringtheutilizationanddisposalphases. Details relevant to the configuration management approach during these phasesareprovidedinclause4.3.7.
4.3.2.5
Identification marking
Eachitem,H/WandS/Wisuniquelyidentifiedbyaspecificidentificationcode. The identification code is assigned to a product to distinguish it during its entirelife.Therulesfortheidentificationcodingsystemareestablishedinthe CMplan. AconfiguredH/Witemisidentifiedbyapartnumberand,ifnecessary,aserial or lot number such that every single item has a unique identifier. In this context,bulkmaterialistreatedasapart.AconfiguredS/Witemisidentified by a unique code and version number. When the configured item is a configurationitem,itsidentificationalsoincludesaCIidentifier.Thesedifferent product identification data are applied on the product itself or, when not possible,linkedtotheproduct.
23
4.3.2.6
Digital file and media identification
Configuration identification also provides the means for maintaining traceabilityfromaproducttoitsdesigndefinitiondataresidentinanelectronic database(digitalfiles). Suchdata,representedbydigitalfiles,arecomposedbyavarietyofsubsetdata, which are merged in a controlled manner in order to represent the product designdefinitionconcernedintheintendedconfiguration. Configuration management for these sets of data and their integration into a complete product design definition is an existing application of software CM processes(e.g.librarymanagement). Digital files defining the configuration characteristics of a product item are therefore subject to the same configuration management principles applicable toconfigurationdocumentation. The application of configuration identification rules to digital data are applicablefor digitaldataidentification, digitaldatastorage, maintenanceofdigitaldatarelatingtotheproduct, version control of digital data and the related change management process, controlledaccesstodigitaldata,and digitaldatatransmittal.
4.3.3
4.3.3.1
Configuration control
Overview
Configuration control, as depicted in Figure 47, is the process for controlling the evolution of, or departures from agreed baselines. It includes the preparation, justification, evaluation, disposition and implementation of engineeringandcontractualchanges,deviationsandwaivers.
24
Figure47Configurationcontrol 4.3.3.2 Change procedure
Configuration control ensures that all changes, deviations and waivers to agreed configuration baselines, including their released and approved documentationareprocessedandcontrolledinatraceablemanner. The configuration control process ensures that the following activities are covered: preventionofchangesaffectingdegradationofproductcapability; involvementofallactorsintheconcernedanalysisanddecisionprocess ofchanges; control that authorized changes or deviation are implemented, verified andrecorded; preventionoftheimplementationofunauthorizedchangesordeviations.
Changecontrolproceduresareappliedfollowingtheestablishmentofthefirst baseline. All released baseline documentation, thereafter, is subject to configuration control, including submission to the customer for higherlevel approval or review, as necessary. As such, no formal change can be generated without an approvedbaseline. Achangecanbeeither initiated by the customer(e.g. evolution of requirements) followed by a replyfromthesupplierwithinadefinedtimelimit,or proposed by the supplier (e.g. self initiated improvement of design) followedbyaresponsefromthecustomer.
4.3.3.3
Configuration control board
Configurationcontrolboards(CCB)areestablishedateachprojectlevelasthe relevant authority for all changes. The CCB is convened by the configuration manager in agreement with the project manager. The CCB consists of
25
permanentrepresentativesofallprogrammeorprojectdisciplinesnecessaryfor the review and evaluation of changes. The members of the CCB are with decisionmakingauthority. Achangeinitiatedbythecustomercanonlybeimplementedafterexamination andapprovalofthesuppliersresponse,e.g.changeproposal.
4.3.3.4
Classification of changes and departures
The classification of a change or departure defines the type of approval and release cycle required according to criteria with regard to impacts on cost, schedule, technical specification and other technical or contractual characteristics. Every change is classified by the CCB as a class 1 or class 2 change and departureasmajororminor.Thechangeordeparturecanbereclassifiedbythe nexthigherlevelCCB. Accordingtoitseffects,achangeproposaloradeparturerequestisprocessed throughthedifferentlevelsoftheorganization.Theappropriateleveltodecide itsdispositionisthelevelforwhichtheeffectsofthechangeordeparturehave norepercussionsonthecommitmentsmadetothecustomer.Thedispositionis, however,transmittedtothecustomerforinformation.
4.3.3.5
Interface control
Interface control is part of the configuration control activity and defines the process necessary to freeze and implement interface data, and the control of changes affecting the interfaces. The interface control process is under the responsibilityofsystemengineeringsupportedbyconfigurationmanagement. TheCMactivityprovidesthemeanstoidentify,trackandreportonthestatus ofapprovedinterfaces. Control of interfaces is performed through the interface control document(s) (ICDs), which is/are prepared to cover all aspects relevant to interfaces (e.g. mechanical, electrical, thermal and software). Configuration management provides the necessary assistance and support in recording the status of the interfacedataandinverifyingtheircomplianceagainstrequirements.
4.3.4
4.3.4.1
Configuration status accounting

Overview
Configurationstatusaccountingcomprisesthecreationandorganizationofthe knowledge base necessary for performing configuration management. It providesthesourceofconfigurationinformationtosupportallprogrammeor projectdisciplinesandactivitiesthroughtheestablishmentandmaintenanceof a record of approved configuration documentation (e.g. data sets) and relatedidentificationnumbers, the status of proposed changes to and requested departures from the establishedconfiguration, theimplementationstatusofapprovedchangesanddeviations,and
26
the actual configuration of all units of configured items being in the operationalinventory.
Togetherthesecomprisetheconfigurationstatusaccountingreport.
4.3.4.2
As-designed and as-built data list
The CIDL is a document generated for reporting the current design status of each product configuration item. This document is provided at the PDR with the establishment of the development configuration baseline and maintained duringthelifecycleoftheproductCI. The CIDL itself and the data included serve as a point of departure for the controlofsubsequentperformance,designandbuildchanges. When software product CIs are involved, a software configuration file is also preparedinordertoprovidemoreextensiveinformationrelevanttoinstallation anduseofthedescribedproduct. TheCIDListhesourceforthepreparationoftheABCL,whichisthedocument used to report the asbuilt and astested status for each serial number of productCI.
4.3.5
Configuration verification
Configuration verification is the process to verify the current configuration statusoftheanalyzedproductandresultsintheestablishmentofconfiguration baselines as defined in clause 4.3.2.5. This activity is performed during programme or project reviews, which are defined in ECSSMST10 together withtheirobjectives. Attheendofeachreview,thedocumentsanddatasetsthatidentifythecurrent configuration baseline are updated to be in conformance with the review dispositionsandthenpresentedtothecustomerforapproval.
4.3.6
Configuration management process audit
The effectiveness of the configuration management system is measured by audits to verify the proper application of configuration management requirementsduringthelifecycleoftheproductasspecifiedbythecustomer. AuditsareconductedinaccordancewithrequirementsdefinedinECSSMST 10.
4.3.7
Configuration management approach for operational phase
Theactivitiesperformedbyconfigurationmanagementduringtheoperational phase (phase E and F of a project) are those required by the set of reviews establishedbyECSSMST10. If necessary, a dedicated CM plan can be prepared to describe the process to meettheobjectivesoftheoperationalphase.
27
During this phase the functions of CM are continued from previous project phases.
4.3.8
Implementation of information/documentation management

Overview
4.3.8.1
Implementation of information/documentation management comprises the activitiesasdescribedinthefollowingsubclauses.
4.3.8.2
Creation and revision
During this phase the content of a document is established and the documentation reference is assigned. This activity is performed under the responsibilityoftheorganizationassignedintheDRL.Attributesinadditionto the documentation reference can be included as needed (e.g. DRL/DRD reference, CI Identifier, authorities involved in the review process). For configuration controlled documents, the configuration control process defined inthisstandardisapplied. In this phase the document bears the status In Preparation. It is considered preliminary and is therefore not used for binding agreements. The same logic appliesforanewversionofadocumentunderpreparation.
Figure48Implementationofinformation/documentationmanagement
28
4.3.8.3
4.3.8.3.1
Review
Review activity
When the document is complete, it is submitted for review and approval as required.ThereviewprocessistheninitiatedasspecifiedwithintheCMPlan. InthisphasethedocumentbearsthestatusInReview. Thesamerestrictionregardingitsuseappliesasforthecreation/revisionphase, and is therefore not to be used for binding agreements. The review authority either confirms that the content complies with the applicable requirements,or statestheidentifieddiscrepanciestogetherwiththeproposedresolution.Inthe latter case, the document is returned to the creation/revision phase for incorporationofcommentsandresolutionoftheidentifieddiscrepancies. Duringthereviewprocessadocumentcanbewithdrawn(ifitdidnotpass thereviewcycleandismaintainedortracedforhistoricalpurposesonly)orget the status obsolete or superseded(when it has been released but supersededbyanewdocument).
4.3.8.3.2
Approval and release
Approvalcanbegiveneitherbyelectronicsignatureorbyprocessasdefinedin theCMPlan. Electronicsignatureorapprovalbyprocessensuresthat a. b. thedocumenthasnotbeenmodifiedafteritsapproval(i.e.integrity),and theauthorcannotdenyhisresponsibilityforthecontentofthedocument (i.e.nonrepudiation).
At the end of the review phase once all required approvals are given, the documentreachesthestatusReleased. Once released the document is valid for use and therefore ready for distribution.Afterthedocumentisreleased,anymodificationtothedocument impliesanewversion.
4.3.8.4
Delivery
Documents are delivered in line with the procedures defined by the CM Plan takingintoaccountthelevelofconfidentialityapplicabletoeachdocument.The statusofthedocumentisnotchangedduringdelivery. DocumentsaredeliveredusingTechnicalDataPackage(TDP)formatwhich defines the way to exchange content files and their related metadata and to structurethemwithinfolders. TheTDPisaZIPfilecontainingdocumentfile(s)andmetadatadescribingthese documents. Metadata used in the TDP are a subset of the ISO 10303 STEP AP232metadataaddedbysomespecificmetadatadefinedinAnnexL. Themetadataarestoredinthedatapackage.xmlfile.SeeFigure49.
29
Figure49TDPcontents
Thedeliveryprocessissummarizedinthefollowingdiagram.Themainsteps are: a. b. c. d. theoriginatingorganizationexportscontentfilesandmetadatafromits InformationSystem(IS)toTDP; the originating organization provides TDP to recipient organization via e.g.email,ftp,CDROM; the recipient organization opens and controls the compliance of the TDP; therecipientorganizationimportstheTDPintoitsInformationSystem.
30
Figure410DeliveryprocessforTDP 4.3.8.5 Storage and retrieval
Storageandretrievaloverlapswiththeotherphasesdefinedabove.Thestatus ofthedocumentisnotchangedduringstorageandretrieval. Theinformationsystemisdeployedinordertohandlemetadataandstaticand dynamiccontent.Thereproducibilityandintegrityofthestoredinformationis ensuredfortheprogramme/projectlifecycle.
4.3.8.6
Archiving and retrieval
Archiving is the last phase of the information process. It ensures that project information/documentationis: preservedfromdamageorloss, accessibleandretrievableforuse,and accesscontrolledtoauthorizedpersonnel.
31
Figure411Projectphasesandbaselinedefinitions
32
5 Configuration management requirements

5.1 General
In this ECSS Standard, in order to facilitate reading and traceability, the paragraphnumberinginthisclauseisconsistentwiththeparagraphnumbering ofclause4.
5.2
Management and planning

5.2.1
5.2.1.1
a.
Configuration management plan

General
Each supplier shall provide for customers approval a configuration management plan in conformance with Annex A, configuration managementplanDRD. Internal procedures called up in the configuration management plan shallbemadeavailableforcustomerreviewuponrequest.
b.
5.2.1.2
a.
Information security
Information shall only be classified when imposed by national or internationallaws,orbyprogramme/projectrequirements,ortoprotect company/organizationalinterests. Information shall be protected against unauthorized access and accordingtotheconfidentialityclasses. The information access and confidentiality classes shall be agreed betweencustomerandsupplier. Thelistofauthorizedpersonnelhavingaccesstotheinformationsystem shallbeagreedbetweenthecustomerandsupplier.
b. c. d.
5.2.1.3
a. b.
Classification
Customer and suppliers shall indicate within the CM Plan the classificationclassestobeappliedandthedocumentationsetaffected. Classificationclassesshallbeclearlyindicatedonthedocuments.
33
c. d. Classifiedinformationshallbeaccessibleonlytopersonshavingtheright authorizationsandprivileges. Classified information shall be used only in a secure environment or location. NOTE e. f. g. h. Forexample:arealimitedinaccess.
The assigned classification shall be maintained only as long as the informationrequiresprotection. The responsibility for classifying information shall rest solely with the originatingorganization. Destruction of classified information and the method used for destructionshallberecorded. Classifiedinformationshallbedowngradedordeclassifiedonlywiththe priorwrittenconsentoftheoriginatingorganization.
5.2.2
a.
Configuration management interfaces
Configuration management processes shall interface with project managementandplanning,takingintoaccountthecontractualprovision and schedule organization for the definition and phasing of CM activities. Configuration management processes shall interface with engineering and product assurance for agreeing the technical information for which theCMprocesscontrols. Configuration management processes shall interface with IDM for defining rules for documentation identification and processing, control anddistribution. Configuration management processes shall interface with IDM to support Engineering, Product Assurance (PA), manufacturing and production by providing the information/documentation in time and in adequateformatfortheiractivities. Configuration management processes shall interface with logistic and maintenanceprocessestodetermineuptowhichlevelofproducttheCM processshallbeapplied.
b.
c.
d.
e.
5.3
Implementation of configuration management

5.3.1
5.3.1.1
a. 1.
Configuration identification
Configuration item
by its complete design documentation if it is developed for space application;
Aconfigurationitemshallbedefinedinrelationtothefollowingcriteria:
34
2. by its procurement specification, including the list of its performances and interface characteristics, if it is an offtheshelf (OTS)product; byreferencetoitsgoverningstandard,ifitisaproductdefinedby astandard.
3.
5.3.1.2
a.
Configuration item selection
Basedoncustomerinput,thesuppliershallidentifyintheproducttree, the configuration items and their applicable specifications, and agree thesewithitscustomer. NOTE1 Detailed guideline for selecting configuration itemsisgiveninAnnexK. NOTE2 ForproducttreeseeECSSMST10.
b.
Thesuppliershallpreparethelistofconfigurationitemsitsuppliesand keep this under configuration control in conformance with Annex B, configurationitemlistDRD. The configuration item list shall be provided at the PDR for customer approval.
c.
5.3.1.3
a.
Configuration baseline
The supplier shall agree with its customer which documentation shall constituteeachconfigurationbaseline. NOTE1 For hardware products, configuration baselines includethefollowingdocuments: thefunctionalspecification; thetechnicalspecification; generalspecifications(e.g.environment, radiation,designrules,interfaces,andPMP); procurementspecificationforOTSitems; standardizationdocument; engineering drawings (e.g. interface control drawings, parts and assembly drawings, and installationdrawings)andassociatedlists; theinterfacecontroldocument; theconfigurationitemsdatalist; theinstallation/user/operating/maintenance manual; testspecifications; testprocedures; applicableengineeringchanges; applicabledeviations.
35
NOTE2 For software products, configuration baselines includethefollowingdocuments: software system technical specification, when applicable; softwarerequirementsdocument(SRD); softwaredesigndocument; interfacecontroldocument; softwareconfigurationfile(SCF)(includingthe sourcecodelisting); softwarereleasedocument; theinstallation/user/operating/maintenance manual; the configuration description of the developmenttools(e.g.compilers,andlinkers); softwarevalidationtestingspecifications; softwaretestprocedures; maintenanceprocedures; applicableengineeringchanges; applicabledeviations. b. The baseline documentation shall reflect the actual configuration of the product,atanygivenpointoftheproductlifecycle.
5.3.1.4
a.
Baseline establishment
Baselines shall be established at the conclusion of each technical review asthestartingpointforconfigurationcontrolasdefinedbelow: 1. The starting point of configuration control for functional specification is at conclusion of the preliminary requirements review(PRR),establishingthemissionobjectivebaseline. The starting point of configuration control for system technical specifications (TS) is at conclusion of the system requirements review(SRR),establishingthefunctionalconfigurationbaseline. The starting point of configuration control for product technical specifications (TS) and ICDs is at conclusion of the preliminary design review (PDR), establishing the development configuration baseline. This represents freezing of performance and design requirementsandcontrolofdevelopmentalmodels. NOTE 4. Forexample:EM,EQM,andmockups.
2.
3.
The starting point of configuration control of the product design forPFM/FMmodelmanufacturingforqualificationpurposesisat theconclusionoftheCDR,establishingthedesignbaseline. Thestartingpointofconfigurationcontrolofthequalifiedproduct designforserialproductionisattheconclusionofthePCV,orfor
5.
36
prototype(s) at QR/AR, establishing the product configuration baseline. 6. 7. b. Thestartingpointofconfigurationcontroloftheusermanualisat conclusionofthequalificationreview(QR). Thestartingpointforissueandmaintenanceofthelogbookisat conclusionoftheacceptancereview(AR).
The supplier shall maintain the configuration baselines through out the programmeorprojectlifecycle.
5.3.1.5
a. b.
Identification marking
Any product item shall be identified to guarantee its traceability throughouttheprogrammeorprojectlifecycle. FordevelopedhardwareCI,thefollowinginformationshallbeincluded: 1. 2. 3. 4. CIidentifier Partnumber Serialorlotnumber Modelidentifier NOTE 5. 6. For example: EM, STM, and FM (not for ground systems).
Manufactureridentifier Productnameorabbreviation.
c.
For developed software CIs, the following shall be included in the header: 1. 2. 3. 4. 5. 6. CIidentifier Softwareidentifier Versionandrevisionnumber Releasedate Manufactureridentifier productnameorabbreviation.
d.
For OTS and standard products, the following information shall be includedasaminimum: 1. 2. 3. 4. Partnumber Serialorlotnumber Manufactureridentifier Productnameorabbreviation.
e.
Allproductitems,notdefinedasconfigurationitem,shallbemarkedor labelledincludingthefollowinginformation: 1. 2. Partnumber Serialorlotnumber,whenapplicable
37
3. f. Manufactureridentifier.
All product items subject to major nonconformances shall receive supplemental identification to provide a link to the departure authorizationdocument. For media containing software, the following information shall be includedasaminimum: 1. 2. 3. 4. 5. 6. 7. 8. 9. CIidentifier; S/Widentifier; Versionandrevisionnumber; Dateofgeneration; Manufactureridentifier; Productnameorabbreviation; SCFreferenceincludingissueanddate; Totalnumberofdeliveredmediaperinformationset(1of...); Copyorserialnumberofdataset.
g.
h.
When the physical dimensions of the item restricts full identification marking,thefollowingshallapply: 1. 2. 3. Selectaminimumsetofinformationwhichuniquelyidentifiesthe items. Identifyonapermanenttag,ifpossible. Ifpermanenttagisnotpossible,identifyonaremovabletagoron thepackaging.
i. j. k.
Theidentificationmarkingmethodsappliedshallbecompatiblewiththe productsoperationalenvironment. The identification marking methods applied shall be defined in the configurationdefinitiondocument. Identificationmarkingofsoftwareproductsshallbeestablishedthrough thehardwareproductwherethesoftwareisresident(i.e.thefirmware), orthemediainwhichthesoftwareisstored.
5.3.1.6
a. b. c.
Digital file and media identification
Digital files defining configuration characteristics shall be uniquely identifiedandlinkedtotheirrelatedproductconfigurationdata. Thedigitaldatafilesformingpartofeachconfigurationbaselineshallbe storedinasecureenvironmentwithcontrolledaccess. Digital files composing the definition of configuration characteristics shall be maintainable throughout the life cycle of the programme or project. Digital files defining the configuration characteristics shall be stored within the CM system by its native code and by a PC readable file directlygeneratedfromthenativecode. NOTE Forexample:PDForTIFF.
d.
38
e. f. g. h. i. j. The system shall be able to manage checkin/checkout, multiple versions. Thesystemshallbeabletogenerateanycurrent,baselineorpastversion ofthefile. Distribution,deliveryorpublishingofthefileshallbegeneratedfromthe masterfile. Paperformsofdigitalfilesshallbetraceabletothemasterfile. The order of precedence between the master file and the printed documentationshallbeestablished. CADdatashallbetraceabletotheengineeringdrawing. NOTE k. For example: CAD files, 3D models, and digital mockups.
Digitaldatamediashallbeidentifiedbythefollowing: 1. 2. 3. 4. 5. 6. CIidentifier Filenames Versionandissue Dateofgeneration Generatingentity Totalnumberofdeliveredmediaperinformationset(1of...).
l.
The following information shall be provided together with digital data media: 1. 2. 3. 4. Hostsystem Applicationsoftware Printerandstyledetails Specialinstructionforfurtherprocessingofthedatafile.
5.3.2
5.3.2.1
a. b.
Configuration control
Change procedure
A change procedure shall be established to describe the process for changingaconfigurationbaseline. Any change to a configuration item, in relation to an approved configuration baseline, shall be described, justified and classified by the requestingparty,beforesubmissionforreviewanddisposition. Each actor shall establish a configuration control board to evaluate and approve any change to a configuration item relative to a configuration baseline. Related changes of several products resulting from a common need for changeshallbeprocessedsimultaneously.
c.
d.
39
e. Changes related to an element common to several products shall be presentedtoalltheconcernedactorsforimpactassessment.
5.3.2.2
a. b. c. d. e. f. g.
Classification of changes and departures
A class 1 change, or a major departure, shall be approved by the customerbeforeitsimplementation. A class 2 change, or a minor departure, shall be implemented after supplierapprovalandprovidedtothecustomerforinformation. Customer may reclassify the class 2 proposed changes and minor departures. Unplanned departures shall be classified and processed in conformance toECSSQST1009. Majorplanneddeparturesshallbeprocessedasforclass1changes. Minorplanneddeparturesshallbeprocessedasforclass2changes. For planned departures from requirements or design, the supplier shall submit a request for deviation describing why the product concerned cannotmeetrequirementsofthebaselinedconfigurationdocumentation. Thesuppliershallensurethatchangesordeparturesareapprovedatthe level for which the effects of the change or the departure can have no repercussiononthecommitmentsmadetothecustomer. Theevaluationshallbetransmittedtothecustomerforinformation.
h.
i.
5.3.2.3
a. b.
Initiation of change
All changes initiated by the customer shall use a change request in conformancewithAnnexG,changerequestDRD. All changes initiated by the supplier shall use a change proposal in conformancewithAnnexH,changeproposalDRD.
5.3.2.4
a. b.
Change assessment
Both customer and supplier shall establish procedures for the analysis, reviewanddispositionofproposedchanges. The change assessment shall cover all technical, programmatic and operational impacts on all affected products for which the actor is responsible. Eachprojectactorshallassessanyrequestorproposalforachangetoa configuration baseline, which is presented to him by his customer or supplier.
c.
5.3.2.5
a.
Change disposition
Allchangesshallbedispositionedbytheconfigurationcontrolboardas either: 1. approved, defining the applicability of evolution and associated implementationmodes,
40
2. 3. rejected,withasupportingrational,or deferreduntiladditionalinformationisprovided.
5.3.2.6
a.
Departures from configuration baseline
The supplier shall request planned departures from requirements or design using a request for deviation in conformance with Annex I, requestfordeviationDRD. The supplier shall request unplanned departures from requirements or designusingarequestforwaiverinconformancewithAnnexJ,request forwaiverDRD. The configuration control board shall process deviations and waivers frombaselinedrequirementsordesignwhencustomerrequirementsare affected. Departuresshallbelimitedtoanumberofitemsoraperiodoftime. Deviations related to an element common to several products shall be presentedtoalltheconcernedactorsforimpactassessment.
b.
c.
d. e.
5.3.2.7
a. b.
Baseline and documentation update
Configuration baselines shall be updated in conformance with the dispositionofapprovedchangesanddeviations. Configurationcontrolled documents shall be revised to incorporate approvedchanges.
5.3.2.8
a. b. c.
Interface control
Eachactorshallrecordthestatusofinterfacedefinitiondata. Eachactorshallensurethatallinterfacedefinitiondataisconsistentwith itsproductconfiguration. The supplier shall identify and control the internal interfaces of its product and those interfaces for which he has received delegated authority. Configurationmanagementshallestablish,concurrentlywiththesystem engineering, the overall organization and procedures to process and managechangestointerfaces. Each actor shall clearly identify in configuration definition documentationthedatasubjecttointerfacemanagement.
d.
e.
5.3.3
5.3.3.1
a.
Configuration status accounting

General
All actors shall establish a configuration status accounting system to record,storeandretrievethefollowingconfigurationdata: 1. statusoftheconfigurationbaselines;
41
2. 3. 4. 5. 6. b. designstatusoftheconfigurationitems; asbuiltstatusofacceptedproducts; statusofconfigurationdocumentationandconfigurationdatasets; status of approval of changes and deviations and their status of implementation,thestatusofwaivers; statusofactionsderivedfromtechnicalreviewsandconfiguration verificationreviews.
Each supplier shall provide configuration status accounting reports in conformance with Annex F, configuration status accounting reports DRD.
5.3.3.2
a.
As-designed data list
The supplier shall provide a configuration item data list (CIDL), in conformance with Annex C, configuration item data list DRD, for each deliverableCI. For each deliverable software CI, the supplier shall provide a software configuration file (SCF) in conformance with Annex E, software configurationfileDRD. A CIDL shall be available for the first design review to determine the initialconfigurationbaseline. ThecompleteCIDLforanindividualCI,modelordeliverableitemshall beavailableatprojectreviews. Changesimplementedafterdeliveryoftheproductshallbeincorporated intheCIDL. TheupdatedCIDLshallbeprovidedforlogbookupdating.
b.
c. d. e. f.
5.3.3.3
a.
As-built data list
For each deliverable serial number of CI, the supplier shall provide an asbuilt configuration data list in conformance with Annex D, asbuilt configurationlistDRD. TheABCLshallidentifytheasmanufacturedandastestedstatuses applicabletopartscomposingaCI. UsingtheCIDLasareference,anydifferencebetweentheABCLandthe CIDL shall be documented in the ABCL by reference to the applicable NCR(s)orRFW(s).
b. c.
5.3.4
5.3.4.1
a.
Configuration verification
Verification of the product configuration definition
At SRR, the functional configuration definition shall be verified against missionobjectives.
42
b. c. At PDR, the development configuration definition shall be verified againsttheapplicabletechnicalspecifications. At CDR, the design definition shall be verified against the relevant designdocumentation.
5.3.4.2
a.
Verification of the product configuration
The supplier shall perform configuration verification by systematically comparing the asbuilt configuration of a CI with its as designed configuration. Configuration in terms of functional and performance characteristics shallbeverifiedatqualificationreview(QR)forprototypeorprotoflight production,andFCVforserialproduction. Configuration in terms of physical and nominal performance characteristics shall be verified at AR for prototype or protoflight productionandPCVforserialproduction.
b.
c.
5.3.5
a. b.
Audit of the configuration management system
Each projectactor shall conduct internal audits to verify theapplication ofconfigurationmanagementrequirementsinternaltohisorganization. Eachprojectactorshallconductexternalauditstoverifytheapplication ofconfigurationmanagementrequirementsbyitslowertiersuppliers,in accordancewiththerequirementsdefinedinECSSMST10.
5.3.6
a.
Configuration management approach for operational phase
The following product configuration related activities shall be implementedduringtheoperationalphase: 1. Preparation of a CM plan in conformance with Annex A, configurationmanagementplanDRD,tomeettheobjectiveofthe operationalphase. NOTE This requirement can be fulfilled by adapting the development phase CM plan or creating a dedicatedCMplan.
2. 3.
Provisioning of, or access to development phase documents as establishedatproductdelivery. Maintenanceandcontrolofgroundmodels(i.e.engineeringmodel and mockups) supporting the flight operations to be flight representative. Inventory control of flight spare parts in terms of quantity and storagelocation. Accomplishment of product enhancement in three different ways asfollows:
4. 5.
43
(a) for inline production with no retrofit to delivered units, production changes are undertaken by normal change processing; for inline production with retrofitting of delivered units, retrofit changes are either carried out by the supplier on basisofcontractormodificationdocumentation;or retrofitofdeliveredunits(nomoreproduction)bytheuser, on basis of a modification kit with accompanying modificationinstructions.
(b)
(c)
6.
Design change implementation on product according to the followingcases: (a) (b) normal change processing for inline production with no retrofittingofdeliveredproduct; documentation update for inline production with retrofittingofdeliveredproductperformedbythesupplier; or modification kit with accompanying modification instructionsforretrofittingbytheuseroftheproduct.
(c)
5.3.7
Implementation of information/documentation management

General
5.3.7.1
a. b.
Eachactorshallensurethattheinformationmanagementprocessesand informationsystemareinaccordancewiththeprojectneeds. The information system shall support the creation, collection, review, delivery, storage, retrieval and archiving of information/documentation andrelateddata. Therelevantprojectinformation/documentationshallbeaccessibletoall authorizedprojectmembers. Theinformationsystemshallsupporttheagreedreportingrequirements. NOTE For example: generating of document status lists, schedulereports.
c. d.
e. f.
Allinformation/documentationreleasedforaprogrammeorprojectshall bemanagedelectronically. Incaseofdiscrepanciesbetweenelectronicandpaperbasedinformation theelectronicallystoredversionshalltakeprecedence. NOTE Incaseofconflictthenational/Europeanlawtakes precedence.
44
5.3.7.2
5.3.7.2.1
a. b. c. d. e. f.
Creation and revision

Responsibilities
Responsibility for the information/documentation content shall lie with theorganizationclosesttothedatasource. Author(s) for creating the information/documentation shall be assigned responsibilitybytherelevantorganization. The information/documentation content shall be established in accordancewiththeDRDwhichdescribesthedocument. Author(s) shall always identify the reason(s) for generating a new documentissue. Process for revising information/documents shall involve and apply the sameauthoritiesandapprovalprocessasforpreviousissues. During the creation phase the information/documentation shall be consideredpreliminaryandshallnotbeusedforbindingagreements.
5.3.7.2.2
a. b.
Data collection
All projectrelated information shall be maintained within the informationsystem. Dataapplicabletoaprogrammeorprojectshallbeorderedinsuchaway that they can be extracted from the information system and ordered accordingtothepredefinedvalues. Metadata shall be identified and entered into the information system, containingasaminimumthetermsrequiredinAnnexL.
c.
5.3.7.2.3
a.
Conversion to electronic format
In the case of paper documents, their content shall be converted to electronic format and uploaded into the information system together withitsmetadata. Theprocessofconvertingelectroniccontentfromitsnativeformattothe deliveryformatshallmaintainvisualintegrity.
b.
5.3.7.2.4
a. b. c.
Identification
Eachdocumentandeachdocumentissueshallbeuniquelyidentified. Configurationmanagementrequirementsshallbetakenintoaccountfor documentsthatarepartofaconfigurationbaseline. Documentidentificationshallnotcontainanyelementsthatareliableto changefromanissuetoanother. NOTE For example: Product Item, Configuration Item, levelofapproval,issue.
5.3.7.2.5
a. b.
Revision
Changestoinformation/documentationshallbealwaysjustified. Changes to information/documentation and their justification shall be traceablewithintheinformation/documentation.
45
c. d. The updating of any configuration controlled document shall be processedaccordingtotheconfigurationprocess. Once released, the integrity of any information/documentation shall be guaranteedbytheinformationsystem.
5.3.7.3
5.3.7.3.1
a. b.
Review
Review activity
for each
Each actor shall implement a review cycle information/documentationitemheisrequiredtorelease.
The review cycle for classified information/documentation shall be established according to the level of classification defined for the information/documentationitself. The supplier shall implement a control process to ensure that all information requiring customer or lower tier supplier signatures are submittedontimetothecustomerorlowertiersupplier. Thecustomershallconfirmhisapprovalornonapprovalwithrationale totherelevantsupplierinaccordancewiththeirbusinessagreement. Thelowertiersuppliershallconfirmhisapprovalornonapprovalwith rationale to the relevant customer within the contractually agreed timeframe. Any discrepancy raised against a document shall be provided to the originatingorganizationinwriting. Information/documents shall be delivered when the review cycle has beencompletedandalltherequiredapprovalsareobtained.
c.
d. e.
f. g.
5.3.7.3.2
a. b. c. d. e. f. g.
Approval methods by digital signature
Information/documentationshallbesignedusingdigitalsignature. The digital signature shall be in compliance with internationally recognizedstandards. Selfsignedcertificatesshallnotbeused. The digital signature shall be implemented information/documentationinanyelectronicformat. Thedigitalsignatureshallsupportmultiplesigning. Digitallysignedinformationshallprovideindicationthattheinformation hasbeendigitallysigned. A digitally signed document shall provide on the cover page an indicationstatingthatthedocumenthasbeendigitallysigned. NOTE Informationabout digitalsignature isprovidedin AnnexM(Digitalsignature). to sign
5.3.7.3.3
a.
Approval methods by process
Information/documentation approved by an informatics process shall clearlyindicateapprovalinavisiblemanner:
46
1. 2. b. c. d. e. on the cover page of the electronic document file (source file or .pdffile); aspartoftheinformationfileheader.
Actors involved in the approval loop shall be identified on approved Information/documentation. Theinformationsystemmanagingtheprocessshallrecordtheprocessing stepsofapproval. A LogFile of the processing steps of approval shall be generated automaticallybytheinformationsystem. The LogFile shall be stored together with the information/documentationwithintheinformationsystem. released
5.3.7.4
a.
Delivery
NOTE For details see Annex L, Technical Data Package Description.
Information/documentationshallbedeliveredusingTDP.
b.
Customer and Supplier shall agree upon the optional metadata to be exchanged. NOTE For details see Annex L, Technical Data Package Description.
c.
Based on customer input, the supplier shall provide for customer approval the method, format and schedule for the delivery of the requiredinformation. Thefollowingformatsshallbeusedfordelivery:
d.
Readonlydocuments Editabledocuments Photographicimages Technicalimages Technical/CADdrawings TechnicalDataPackage NOTE e.
AcrobatPDFcompatibleformat MSOfficecompatibleformat JPEGcompatibleformat TIFFwithLZWorotherlossless compression DXF,3DCADfile,ISOStepformat TDPZIP
Additional formats can be implemented and agreedwiththecustomer
Thedeliverymechanismshallensurethattheinformation: 1. 2. 3. comesfromagiven,identifiedsender(guaranteeofauthenticity); cannot be disclaimed by the sender (guarantee of non repudiation); cannotbereadbythirdpartiesduringtransmission(guaranteeof confidentiality);
47
4. cannot be modified by third parties during transmission (guaranteeofdataintegrity). NOTE ElectronicmailviaSMTPandfiletransferviaFTP cannot be used with unencrypted files, because these delivery methods do not meet the above requirements.
f.
Where a concurrent environment is available, accessibility to it shall be possible by using established privileges and rules for authorized programme/projectmembers.
5.3.7.5
a.
Storage and retrieval
Each actor shall ensure that the information/documentation is available to the programme/project members throughout the entire programme/projectlifecycle. Each actor shall store all released document issues in the information system. Eachactorshallstoreinformation/documentationinitsnativeformatfor future update, together with metadata, throughout the programme/projectlifecycle. Information/documentationshallbeprotectedagainstenvironmentaland accidentalrisksandagainstunauthorizedaccess. Access to classified information/documentation shall be restricted to authorizedpersonnel.
b. c.
d. e.
5.3.7.6
a.
Archiving and Retrieval
Thesuppliershalldefineandimplementanarchivingsolutiontoensure thatprojectinformation/documentationis: 1. 2. 3. preservedfromdamageorloss, accessibleandretrievableforuse,and accesscontrolledtoauthorizedpersonnel.
b.
Thesuppliershallagreewiththecustomerthedurationofthearchiving activities.
48
Annex A (normative) Configuration management plan - DRD

A.1 DRD identification
A.1.1 Requirement identification and source document
ThisDRDiscalledfromECSSMST40,requirement5.2.1.1a.
A.1.2
Purpose and objective
The objective of the configuration management plan is to provide in a single document all elements necessary to ensure that the implementation of configurationmanagementmeetscustomerrequirementsandiscommensurate withtheprogrammeorproject,organization,andmanagementstructure.
A.2
Expected response
A.2.1
<1>
a.
Scope and content

Introduction
The configuration management plan shall contain a description of the purposeandobjectivepromptingitspreparation.
<2>
a.
Applicableandreferencedocuments
The configuration management plan shall list the applicable and referencedocumentsinsupportofthegenerationofthedocument.
<3>
Management
<3.1> Organization
a. The configuration management plan shall describe the organizational context, both technical and managerial, within which the prescribed configurationmanagementactivitiesshallbeimplemented.
49
b. Theconfigurationmanagementplanshallalsodescribetheinterfacewith otherCMorganizations(customerandsupplier)andtheCMrelationship tootherinternalorganizationelements. The configuration management plan shallalso describe theinterfacefor theinformationmanagementactivities.
c.
<3.2> Responsibilities
a. The configuration management plan shall describe the allocation of responsibilities and authorities for configuration management activities to organizations and individuals within the programme or project structure.
<3.3> Policies,directivesandprocedures
a. Any external constraints, or requirements, placed on the configuration management plan by other policies, directives, or procedures shall be identified in this section together with the consequences of applying thesetotheprogrammeorproject.
<3.4> Security
a. Customer and suppliers shall indicate within the configuration managementplantheclassificationclassestobeappliedandtherelevant documentationset.
<4>
ConfigurationManagement
<4.1> General
a. The configuration management plan shall identify all functions and processes, both technical and managerial, required for managing the configurationoftheprogrammeorproject. The configuration management plan shall introduce the following, as a minimum: 1. 2. 3. 4. 5. 6. configurationidentification; configurationcontrol; configurationstatusaccounting; configurationauditsandreviews; interfacecontrol; suppliercontrol.
b.
<4.2> Configurationidentification
a. The configuration management plan shall identify, name, and describe the documented physical and functional characteristics of the information to be maintained under configuration management control fortheprogrammeorproject. The configuration management plan shall describe the following, as a minimum:
b.
50
1. 2. producttreeestablishment(Systemdecomposition); identification of configuration items, i.e. the selection process of the items to be controlled and their definitions as they evolve or areselected; naming of configuration items, i.e. the specification of the identification systemfor assigning uniqueidentifiers to each item tobecontrolled; configurationbaselinesestablishmentandmaintenance; interfaceidentification; configurationdocumentationanddatareleaseprocedures.
3.
4. 5. 6. c.
Incaseofsoftwareconfigurationitemandwhereatoolisusedtobuild itsbaseline,thefollowingshallbedescribed: 1. 2. 3. 4. 5. proceduretoenterasoftwareconfigurationitemintoabaseline; proceduretoconfigureandestablishabaseline; softwareproductsandrecordstodefineabaseline; proceduretoapproveabaseline; authoritytoapproveabaseline.
d.
In case software libraries are established, the following shall be identified: 1. 2. 3. 4. 5. 6. 7. librarytypes; librarylocations; mediausedforeachlibrary; librarypopulationmechanism; number of identical libraries and the mechanism for maintaining parallelcontents; librarycontentsandstatusofeachitemincludedin; conditions for entering a SCI, including the status of maturity compatible with the contents required for a particular software librarytype; provision for protecting libraries from malicious and accidental harmanddeterioration; softwarerecoveryprocedures; conditionsforretrievinganyobjectofthelibrary; libraryaccessprovisionsandprocedures.
8. 9. 10. 11.
<4.3> Configurationcontrol
a. The configuration management plan shall describe the configuration control processand datafor implementing changes to the configuration itemsandidentifytherecordstobeusedfortrackinganddocumenting thesequenceofstepsforeachchange.
51
b. The configuration management plan shall describe the following, as a minimum: 1. 2. 3. 4. 5. 6. 7. 8. 9. configurationcontrolboardfunctions,responsibilities,authorities; processingchanges; changerequests; changeproposal; changeevaluation; changeapproval; changeimplementation; processingplannedconfigurationdepartures(deviations); processing unplanned configuration nonconformances,waivers). departures (product
<4.4> Interfacecontrol
a. Theconfigurationmanagementplanshalldescribetheprocessanddata for coordinating changes to the programme or project configuration managementitemswithchangestointerfaces.
<4.5> Suppliercontrol
a. For both subcontracted and acquired products (i.e. equipment, software or service), the configuration management plan shall define the process and data to flow down the CM requirements and the programme monitoringmethodstocontrolthesupplier. Theconfigurationmanagementplanshalldefinetheprocessanddatato incorporate the supplier developed items into programme or project configurationmanagementandtocoordinatechangestotheseitems. Theconfigurationmanagementplanshallalsodescribehowtheproduct isreceived,tested,andplacedunderconfigurationcontrol.
b.
c.
<4.6> Configurationstatusaccounting
a. b. Theconfigurationmanagementplanshalldescribetheprocessanddata forreportingthestatusofconfigurationitems. The following minimum information shall be tracked and reported for eachconfigurationmanagementitem: 1. 2. 3. 4. 5. statusoftheconfigurationbaselines; designstatusoftheconfigurationitem; statusofconfigurationdocumentationandconfigurationdatasets; status of approval of changes and deviations and their implementationstatus; status of discrepancies and actions arising from technical reviews andconfigurationverificationreviews.
52
ECSSMST40CRev.1 6March2009 <4.7> Configurationverification

a. Theconfigurationmanagementplanshalldescribetheprocessanddata to verify the current configuration status from which the configuration baselinesareestablished. The configuration management plan shall provide the description of verificationplans,proceduresandschedules. The configuration management plan shall identify how the recording, reporting and tracking of action items and incorporation of review recommendationsaremaintained.
b. c.
<4.8> AuditsofCMsystem
a. Theconfigurationmanagementplanshalldescribetheprocess,dataand schedule for configuration audits to ensure that the configuration managementoftheprogrammeorprojectisperformed. Asaminimum,theconfigurationmanagementplanshallenablethat 1. 2. the CM process is properly defined, implemented and controlled, and the configuration management items reflect the required physical andfunctionalcharacteristics.
b.
<4.9> Technicaldatamanagement
a. Theconfigurationmanagementplanshalldescribetheprocessanddata toaccessandmaintaintextandCADfiles,dataandsoftwarerepositories, andtheimplementationofanyPDMsystem.
<5>
Information/documentationmanagement
<5.1> Informationidentification
a. The configuration management plan shall describe the main information/documentationcategories,suchasmanagementinformation, contractual documentation or engineering data, to be established and usedthroughouttheprogramme/projectlifecycle. The configuration management plan shall describe methods for information/documentidentificationincludingversioning. Theconfigurationmanagementplanshouldlistthecodesforcompanies, information types, models, subsystems, etc. which are applied specifically in the identification method or are in general use during projectexecution. The configuration management plan shall identify the metadata structuresofthemaininformationcategories.
b. c.
d.
<5.2> Dataformats
a. The configuration management plan shall define for the various informationcategoriesthedataformatstobeusedfor
53
1. 2. 3. b. contentcreationandupdate distribution archiving
The configuration management plan shall specify which format takes precedenceincaseaformatconversionisapplied.
<5.3> Processes
a. Theconfigurationmanagementplanshalldescribetheactorsinvolvedin, as well as the method and processesfor, creating,collecting, reviewing, approving,storing,deliveringandarchivinginformationitems. Theconfigurationmanagementplanshalldescribethehandlingoflegacy documentationandofftheshelfdocumentation. The configuration management plan shall define the information retentionperiod.
b. c.
<5.4> Informationsystems
a. The configuration management plan shall list the project information systems to be used for creating, reviewing, storing, delivering and archivingthemaininformationcategories NOTE For example: ABC for schedule, and XYZ for engineeringDB.
<5.5> Deliverymethods
a. The configuration management plan shall describe the methods used to deliverTDPs.
<5.6> Digitalsignature
a. The configuration management plan shall define the procedures, methods and rules applicable to digital signatures. This comprises informationaboutthefollowingaspects: 1. 2. 3. 4. 5. certificatetype managementofsignaturekey timestamping signingofPDFdocuments multiplesignaturesperdocument
<5.7> Informationstatusreporting
a. b. The configuration management plan shall describe the process and contentforreportingthestatusofinformationitems. For documentation the following attributes shall be reported as a minimum: document identification, version, title, issue date, status, and documentcategory.
54
<6>
Scheduleandresources
<6.1> Schedule
a. The configuration management plan shall establish the sequence and coordination for all the configuration management activities and all the eventsaffectingtheCMplansimplementation.
<6.2> Resources
a. The configuration management plan shall identify the tools, techniques, equipment,personnel,andtrainingnecessaryfortheimplementationof configurationmanagementactivities.
A.2.2
a.
Special remarks
The response to this DRD may be combined with the response to the projectmanagementplan,asdefinedinECSSMST10.
55
Annex B (normative) Configuration item list - DRD

B.1 DRD Identification
B.1.1 Requirement identification and source document
ThisDRDiscalledfromECSSMST40,requirement5.3.1.2b.
B.1.2
Theobjectiveoftheconfigurationitemlististoprovideareportinginstrument definingtheprogrammeorprojectitemssubjecttoconfigurationmanagement process.
B.2
Expected response
B.2.1
<1>
a.
Scope and content

Introduction
The introduction shall describe the purpose and objective of the configurationitemlist.
<2>
a.
The configuration item list shall list the applicable and reference documentsinsupporttothegenerationofthedocument.
<3>
a.
List
Theconfigurationitemlistshallcontainforeachconfigurationitem(CI) thefollowinginformation: 1. 2. 3. identificationcode(derivedfromtheproductitemcode); modelsidentificationandquantity; CIname;
56
4. 5. 6. CIcategory(developed,nondeveloped); CIsupplier; applicablespecification.
B.2.2
None.
Special remarks
57
Annex C (normative) Configuration item data list (CIDL) - DRD

C.1 DRD identification
C.1.1 Requirement identification and source document
C.1.2
The configuration item data list (CIDL) is a document generated from the centraldatabasegivingthecurrentdesignstatusofaconfigurationitem(CI),at anypointoftimeinsufficientdetail,providingitscompletedefinition.
C.2
Expected response
C.2.1
<1>
a.
Scope and content

Introduction
The introduction shall describe the purpose and objective of the configurationitemdatalist.
<2>
a.
The configuration item data list shall list the applicable and reference documentsinsupporttothegenerationofthedocument.
<3>
a. 1. 2.
List
Theconfigurationitemdatalistshallincludethefollowing: Coversheetsandscope. Customercontrolleddocumentation,including (a) (b) customerspecificationsandICDs,and supportspecifications.
58
3. Engineeringordesigndocumentation,including (a) (b) NOTE (c) (d) (e) (f) (g) (h) (i) 4. verification plans demonstrating specifiedrequirements, specialinstructionsorprocedures, For example, transportation, integration, and handling. declaredPMPlists, lowerlevelspecifications, lowerlevelICDs, drawingsandassociatedlists, testspecifications, testprocedures,and usersmanualorhandbook. compatibility with
List of applicable changes not yet incorporated into the baselined documentation, and deviations (including status, directly related to the document (e.g. specification) to which the change belongs to). CInumberbreakdown (a) indentured breakdown by part numbers starting from the partnumberassociatedwiththeCIdowntothelowestlevel ofcomposition; quantity of each part number used on the next higher assembly; issue status of the drawings and associated lists applicable toeachpartnumber.
5.
(b) (c) b.
Each entry in the CIDL shall relate to the applicable model(s) of the CI andbedefinedbyitsdocumentnumber,title,issueandreleasedate.
C.2.2
None.
Special remarks
59
Annex D (normative) As-built configuration list - DRD

D.1 DRD identification
D.1.1 Requirement identification and source document
D.1.2
Theobjectiveoftheasbuiltconfigurationlist(ABCL)istoprovideareporting instrumentdefiningtheasbuiltstatuspereachserialnumberofconfiguration itemsubjecttoformalacceptance.
D.2
Expected response
D.2.1
<1>
a.
Scope and content

Introduction
Theintroductionshalldescribethepurposeandobjectiveoftheasbuilt configurationlist.
<2>
a.
The asbuilt configuration list shall list the applicable and reference documentsinsupporttothegenerationofthedocument.
<3>
a.
List
The asbuilt configuration list shall list all discrepancies between the asdesignedconfigurationdocumentedintheconfigurationitemdatalist and the asbuilt configuration documented by nonconformance reports orwaivers.
60
b. The ABCL configuration item breakdown section, obtained from the equivalent configuration item data list section, shall be completed by addingthefollowinginformation: 1. 2. 3. serialnumberidentification; lotorbatchnumberidentification; reference(s)ofapplicablenonconformancereport(s)orrequestfor waiver(s).
D.2.2
None.
Special remarks
61
Annex E (normative) Software configuration file (SCF) - DRD

E.1 DRD identification
E.1.1 Requirement identification and source document
ThisDRDiscalledfromECSSMST40,requirement5.3.3.2bandfromECSSE ST40andECSSQST80.
E.1.2
The objective of the software configuration fileis toprovide the configuration status of the software configuration item. It controls its evolution during the programmeorprojectlifecycle. TheSCFisaconstituentofthedesigndefinitionfile(asdefinedinECSSEST 10).
E.2
Expected response
E.2.1
<1>
a.
Scope and content

Introduction
TheintroductionshalldescribethepurposeandobjectiveoftheSCF.
<2>
a.
TheSCFshalllisttheapplicableandreferencedocumentstosupportthe generationofthedocument.
<3>
a.
Terms,definitionsandabbreviatedterms
The SCF shall include any additional terms, definition or abbreviated termsused.
62
<4>
a. b.
Softwareconfigurationitemoverview
The SCF shall contain a brief description of the software configuration item. For the software configuration item, the following information shall be provided: 1. 2. 3. 4. 5. howtogetinformationaboutthesoftwareconfigurationitem; compositionofthesoftwareconfigurationitem:code,documents; means to develop, modify, install, run the software configuration item; differencesfromthereferenceorpreviousversion; statusofsoftwareproblemreports,softwarechangerequests,and software waivers and deviations related to the software configurationitem.
<5>
a.
Inventoryofmaterials
The SCF shall list all physical media and associated documentation releasedwiththesoftwareconfigurationitem. NOTE Example of physical media are listings, tapes, cardsanddisks.
b.
The SCF shall define the instructions necessary to get information includedinphysicalmedia. NOTE Forexample,togetfiles.
<6>
a.
Baselinedocuments
The SCF shall identify all the documents applicable to the delivered softwareconfigurationitemversion.
<7>
a. b.
Inventoryofsoftwareconfigurationitem
TheSCFshalldescribethecontentofthesoftwareconfigurationitem. TheSCFshalllistallfilesconstitutingthesoftwareconfigurationitem: 1. 2. 3. 4. 5. 6. sourcecodeswithname,version,description; binarycodeswithname,version,description; associateddatafilesnecessarytorunthesoftware; medialabellingreferences; checksumvalues; identificationandprotectionmethodandtooldescription.
<8>
a.
Meansnecessaryforthesoftwareconfigurationitem
TheSCFshalldescribeallitems(i.e.hardwareandsoftware)thatarenot part of the software configuration item, and which are necessary to
63
develop, modify, generate and run the software configuration item, including: 1. itemsrelatedtosoftwaredevelopment; NOTE 2. 3. For example, compiler name and version, linker, andlibraries.
buildfilesandsoftwaregenerationprocess; othersoftwareconfigurationitems.
<9>
a.
Installationinstructions
The SCF shall describe how to install the software configuration item version,itsmeansandproceduresnecessarytoinstalltheproductandto verifyitsinstallation.
<10>
a.
Changelist
This SCF shall contain the list of all changes incorporated into the softwareconfigurationitemversion,withacrossreferencetotheaffected softwareconfigurationitemdocument,ifany. ChangesnotincorporatedyetbutaffectingtheS/WCIshallalsobelisted andinclude. 1. 2. 3. 4. softwareproblemreports; softwarechangerequestsandproposals; contractualchangenotices; softwarewaiversanddeviations.
b.
<11>
a.
Auxiliaryinformation
TheSCFshallincludeanyauxiliaryinformationtodescribethesoftware configuration.
<12>
a.
Possibleproblemsandknownerrors
The SCF shall identify any possible problems or known errors with the softwareconfigurationitemversionandanystepsbeingtakentoresolve theproblemsorerrors.
E.2.2
None.
Special remarks
64
Annex F (normative) Configuration status accounting reports DRD

F.1 DRD identification
F.1.1 Requirement identification and source document
F.1.2
Thepurposeofconfigurationstatusaccountingreportsistoprovideareliable source of configuration information to support all programme or project activities. They provide the knowledge base necessary for performing configurationmanagement.
F.2
Expected response
F.2.1
<1>
a.
Scope and content

Introduction
The introduction shall describe the purpose and objective of the configurationstatusaccountingreports.
<2>
a.
The configuration status accounting reports shall list the applicable and referencedocumentsinsupporttothegenerationofthedocument
<3>
a. 1.
Description
Theconfigurationstatusaccountingreportsshallcontaininformationon: Documentsindexandstatuslist (a) documentidentification;
65
(b) (c) (d) (e) (f) 2. issueandrevision; issueandrevisiondate; title; remarks; identificationofobsoletedocuments.
Drawingindexandstatuslist (a) (b) (c) (d) (e) (f) drawingidentification; issueandrevision; issueandrevisiondate; title; remarks; modelapplicabilityofthedrawing.
3.
Requestfordeviationindexandstatuslist (a) (b) (c) (d) (e) (f) (g) deviationdocumentnumber; issueandrevision; issueandrevisiondate; title; documentorrequirementaffected; configurationitem(s)affected; statusofapproval.
4.
Requestforwaiverindexandstatuslist (a) (b) (c) (d) (e) (f) (g) (h) waiverdocumentnumber; issueandrevision; issueandrevisiondate; title; documentorrequirementaffected; NCRoriginatingthewaiver; serialnumberofconfigurationitem(s)affected; statusofapproval.
5.
Changeproposal(CP)indexandstatuslist (a) (b) (c) (d) (e) (f) CPdocumentnumber; issueandrevision; issueandrevisiondate; title; changerequestoriginatingthechange; configurationitem(s)affected;
66
(g) 6. statusofapproval.
Reviewitemdiscrepancies(RID)indexandstatuslist (a) (b) (c) (d) (e) (f) (g) (h) (i) designreviewidentification; RIDidentification; titleofthediscrepancy; affecteddocumentnumberandissue; affectedparagraph; RIDstatus; identificationofactionassigned; RIDclosuredate; remarks.
F.2.2
None.
Special remarks
67
Annex G (normative) Change request - DRD

G.1 DRD identification
G.1.1 Requirement identification and source document
G.1.2
The objective of a change request is to collect the information that formally defines a proposed programme or project change versus the existing requirements.
G.2
Expected response
G.2.1
a.
Scope and content
ThechangerequestshallcontaintheinformationinTableG1.
G.2.2
None.
Special remarks
68
No. Data
1 2 3 4 5 6 7 8 Organization Number Issue Date Project Title Affecteditem(s)
TableG1:Changerequestscopeandcontent Description
Identificationofthechangerequestoriginating organization Uniqueidentificationandregisternumber Issuestatusofthechangerequest Issuedateofthechangerequest Projectunderwhichthechangerequestis supplied Titleofchangerequest IdentificationoftheCI(s)orPI(s)(numberand name)whichareaffectedbythechangerequest Identificationofthedocument(s)towhichthe changerequestapplies(documentnumberand issue,paragraphorrequirementid) Reasonwhytheproposedchangehastomade (Rationale) Changedescription,andwhenrequirementsare affected,proposednewwording Names,dateandsignaturesoftherelevant authorities Informationontheauthorizationtoproceedor thelimitofliability,ifthechangehastobe incorporatedimmediately
Affecteddocument(s)
Reasonforchange
10 Descriptionofchange 11 Approval 12 Authorizationtoproceed
69
Annex H (normative) Change proposal - DRD

H.1 DRD identification
H.1.1 Requirement identification and source document
H.1.2
Theobjectiveofthechangeproposalistobethevehicleforproposingamajor changetoanapprovedbaselineddataorthebusinessagreement.
H.2
Expected response
H.2.1
a.
Scope and content
ThechangeproposalshallcontaintheinformationinTableH1.
H.2.2
None.
Special remarks
70
No.
1 2 3 4 5 6 7 8 9 Organization Number Issue Date Project
TableH1:Changeproposalscopeandcontent Data Description

Identificationofthechangeproposaloriginating organization Uniqueidentificationandregisternumber Issuestatusofthechangeproposal Issuedateofthechangeproposal Projectunderwhichthechangeproposalis supplied Changerequestreferenceonwhichthechange proposalissupplied Titleofchange Recommendedclassification Recommendedintroductionpointand identificationoftheapplicationrangeofthe change Descriptionofthechange IdentificationoftheCIorPI(numberandname) affectedbythechangeproposal Identificationofthedocument(s)(e.g.number andissue,paragraphordesigndata)affectedby thechange ReasonforChange;Describetherationalforthe changeproposalapproval Indicationonrelatedfactors(e.g.interfaces, safety)ofthechange: performances,interfaces,interchangeability, qualification,reliability,maintainability,safety, electricalandmechanicalparameters,materialor processes,parts,testing,groundsegment,GSE andtooling,userdocumentation,cost,schedule. Estimatedinfluencesonbusinessagreement provisions Detailedcostidentificationandoverallsummary priceofthechange Effectsonschedule Regardingtheintendeduse Names,dateandsignaturesoftherelevant authorities Names,dateandsignaturesoftherelevant authorities
Changerequestreference Title Classification Effectivity
10 Changedescription 11 Affecteditem(s) 12 Affecteddocument(s)
13 Changereason 14 Relatedfactors
15 Effect 16 Price 17 Scheduleeffects 18 Limitationofuse 19 Initiatorapproval 20 Customerapproval
71
Annex I (normative) Request for deviation - DRD

I.1 DRD identification
I.1.1 Requirement identification and source document
I.1.2
Theobjectiveoftherequestfordeviationistobethevehicleforrequiringand agreeing the departure from a customers requirement that is part of an approvedconfigurationbaseline.
I.2
Expected response
I.2.1
a.
Scope and content

TherequestfordeviationshallcontaintheinformationinTableI1.
I.2.2
None.
Special remarks
72
Id
1 2 3 4 5 6 7 8 9 Organization Number Issue Date Classification Project
TableI1:Requestfordeviationscopeandcontent Data Description

Identificationoftherequestfordeviation originatingorganization Uniqueidentificationandregisternumber Issuestatusoftherequestfordeviation Issuedateoftherequestfordeviation Recommendedclassification(i.e.majororminor) Projectunderwhichthenonconformingitemis supplied Businessagreementidentificationunderwhich thenonconformingitemissupplied Ordernumberunderwhichthenonconforming itemissupplied Locationoftherequestfordeviationoriginator Identificationofthenonconformingitemper nameandnumber,accordingtoitsconfiguration itemdatalist IdentificationoftheCI(s)(numberandname) affectedbythedeviation Effectivityofthedeviationbymodelorserial number Identificationofthedocument(s)towhichthe itemdoesnotconform(documentnumberand issue,paragraphorrequirementid) Titleorshortdescriptionoftherequestfor deviation Descriptionofthedeviationfromtherelevant requirementordesignfeature Reasonwhytheproposeddeviationcanbe accepted(rationale) Itemcharacteristicsaffectedbythedeviation Decision,names,dateandsignaturesofthe relevantauthorities
Businessagreement Order Originatorsite
10 Itemdesignation
11 Affecteditem(s) 12 Effectivity 13 Affecteddocument(s)
14 Shortdescription 15 Detaileddescription 16 Reasonforrequest 17 Adverseeffects 18 Approval
73
Annex J (normative) Request for waiver - DRD

J.1 DRD identification
J.1.1 Requirement identification and source document
J.1.2
Purpose and objective:
The objective of the request for waiver is to be the vehicle for requiring and agreeing to the use or the delivery of a product that does not conform to its approvedproductconfigurationbaseline.
J.2
Expected response
J.2.1
a.
Scope and content
TherequestforwaivershallcontaintheinformationinTableJ1.
J.2.2
None.
Special remarks
74
Id
1 2 3 4 5 6 7 8 9 Organization Number Issue Date Project
TableJ1:Requestforwaiverscopeandcontent Data Description

Identificationoftherequestforwaiveroriginating organization Uniqueidentificationandregisternumber Issuestatusoftherequestforwaiver Issuedateoftherequestforwaiver Projectunderwhichthenonconformingitemis supplied Businessagreementidentificationunderwhichthe nonconformingitemissupplied Ordernumberunderwhichthenonconformingitemis supplied Locationoftherequestforwaiveroriginator Identificationofthenonconformingitempernameand number,accordingtoitsconfigurationitemdatalist IdentificationoftheCI(numberandname)affectedby thewaiver Modelorserialnumber(orbatch/lotnumber)ofthe nonconformingitem(s) Identificationofthedocument(s)(numberandissue, paragraphordesigndata)towhichtheitemdoesnot conform Titleorshortdescriptionoftherequestforwaiver (consistentwiththetitleoftherelatednonconformance report) Descriptionofthenonconformity,supportedby sketchesandattachmentsasappropriate Reasonwhytheproposednonconformitycanbe accepted(Rationale) Identificationnumberofthenonconformancereport relatedtotherequestforwaiver Identificationoftheminutesofmeetingofthe nonconformancereviewboardwhichdecidedtoraise therequestforwaiver Itemcharacteristicsaffectedbythenonconformity Regardingtheintendeduse Majororminoraspertheclassificationcriteria Decision,name,dateandsignatureoftherelevant authorities
Businessagreement Order Originatorsite Itemdesignation
10 Affecteditem(s) 11 Effectivity 12 Affecteddocument
13 Shortdescription
14 Detaileddescription 15 Reasonforrequest 16 NCR 17 NRB
18 Adverseeffects 19 Limitationofuse 20 Classification 21 Approval
75
Annex K (informative) Configuration item selection

K.1 General
The selection of configuration items (CI) is a management decision based on experience and good judgment. Therefore, this annex exposes the risk in selectingtoomanyortoofewitems,andprovidesachecklisttobeusedtohelp theselectionprocess.
K.2
Effects of selecting too many configuration items

ToomanyCIscanresultineffectshamperingvisibilityandmanagementrather thanimprovingit.Theseeffectsinclude: increased administrative burden in preparing, processing, and status reportingofrelateddocumentation,whichtendstobemultipliedbythe numberofCIs;or increased development time and cost as well as possibly creating an inefficientdesign.
Possibleincreaseinmanagementeffort,difficultiesinmaintainingcoordination andunnecessarygenerationofpaperworkorfiles.
K.3
Effects of selecting too few configuration items

Toofewconfigurationitemscanresultindecreasingmanagementvisibilityand progress assessment, increasing cost and difficulties in logistics and maintenance. When the lowest level designated CI is a complex item (e.g. implementing unrelated functions, containing both hardware and software components), the followingcanresult: thepotentialforreuseoftheCI,orportionsoftheCIisdiminished; reprocurementoftheCIandcomponentsiscomplicated; potentialreprocurementsourcesarelimited; formal testing of critical capabilities may be delayed or made more difficult; the inability to account for the deployment of a CI whose component partsaredisbursedtodifferentlocations;
76
difficultyinaddressingtheeffectivenessofchangesandretrofitactions, particularlywhentherearedifferentquantitiesorseparatelydeliverable components; increased complexity in managing and accounting for common assembliesandcomponents; loss of identity through separation of affected portions of a CI during operationalordepotmaintenanceormodificationinstallationactivity; inability to control individual, but identical, remove or replace items whenCIidentificationandcontrolissetattoohighalevel; lossofoperationaluseofonefunctionbecauseofmaintenanceofanother functionwithinthesameCI.
K.4
Configuration item selection check-list

ThefollowinglistofquestionsisproposedtohelptheselectionprocessofCIs. If most of the questions can be answered with YES, then the item is a good candidate for being a CI. On the contrary, if most of the questions can be answeredwithNO,thentheitemisnotagoodcandidate.Ifthequestionscan beansweredwithapproximatelyequalnumbersofYESsandNOs,additional judgmentisneeded. a. b. c. d. e. f. g. h. i. j. k. l. m. n. Istheproductcriticalfromasafety,scheduleorfinancialpointofview? Will the product require development of a new design or a significant modificationtoanexistingdesign? Doestheproductincorporateneworunproventechnologies? Doestheproducthaveaninterfacewithhardwareorsoftwaredeveloped underanothercontract? Istheitemrequiredforlogisticsupportoractivity? Doallcomponentsoftheproducthavecommonmission,installationand deploymentrequirements,commontestingandacceptance? Doestheproducthaveinterdependentfunctions? Doestheproducthavereconfigurationcapability? Isit,ordoesithavethepotential(scheduleorlocation)tobedesignated forseparateprocurement? Can(ormust)theitembeindependentlytested? Isitreadilyidentifiablewithrespecttosize,shapeandweight? With respect to form, fit or function, does it interface with other CIs whoseconfigurationiscontrolledbyotherentities? Is there a requirement to know the exact configuration and status of changestoitduringitslifecycle? Does the item have separate mission, training, test, maintenance and support functions, or require separately designated versions for such purposes?
77
Annex L (informative) Technical data package description

L.1 Scope and content
This annex describes the approach, the relevant steps to create a TDP and the semanticsofthemetadatamodel. TheTDPcanbecreatedbyusingstandalonetoolswhichallowcreationofTDP by picking up files from hard disk (in this case, metadata are retyped manually),orbyISintegratedtoolswhichallowcreationoftheTDPfromfiles andmetadataalreadystoredintheIS. Inbothcases,amappingbetweentermsinthisstandard(seecolumn1ofTable L1toTableL5)andthecompanyterminologyneedstobeperformed. When using IS integrated tools, a second mapping between terms in this standard and the IS internal data structure (e.g. columns of the relational database of the IS) needsto be performed,anda connector (export or import) thatiscompliantwiththerequirementsofclause5.3.7.4isimplemented.
L.2
Steps to create an TDP

a. Create an XML document (called datapackage.xml) containing tags and values about documents to exchange, in the order defined by the ecss_m_st_40.xsd XML Schema. (See XML Schema on ECSS website http://www.ecss.nl). Includethedocumentcontentfilesandthedatapackage.xmlfileinsidea zipfile.
b.
L.3
Detailed TDP ZIP file definition:

a. TheTDPZIPfilecontains:
TheContentfile(s)(intherootdirectoryorinanyfolderofthezip file) Onlyonedatapackage.xmlfileinthe\METAINFfolder.
asshowninthefollowingFigureL1:
78
FigureL1TDPZIPfile
b. The datapackage.xml file is XML valid i.e. it is structurally compliant with the grammar defined by the ecss_m_st_40c.xsd XML Schema. (See XMLSchemaonECSSwebsitehttp://www.ecss.nl). The values contained in the datapackage.xml file are semantically compliantwithTableL1toTableL6. Each content file is named as follows: REFERENCE_C{_I}{_[VOL]}.ext Where:
c. d.
REFERENCE mandatory (REFERENCE being the identifying numberofthedocument) _Cmandatory(Cbeingthechangelevel) _Iifrelevant(Ibeingtheissuelevel) _[VOL]mandatoryifthenumberofvolume>1(VOLbeingthe volume number in the case of several files attached to the same reference/change_level/issue_level
e.
ThefilepathofacontentfilewithintheZIParchiverelativetothemeta inf/datapackage.xml file is stored inside the context_file_name implementationfield.
L.4
InthefollowingTDPZIParchivefileofFigureL2,thecontentfileDSISPSC 20062524_01_00.docisstoredinthe\GDOC_DOCfolderoftheDSISPSC 20062524.doc.zipfile.
79
FigureL2:ZIParchive
Intheassociateddatapackage.xmlfilewhichisinthe\metainffolder,the context_file_namefieldisfilledasfollow: <entry_filecontext_file_name=..\GDOC_DOC\DSISPSC2006 2524_01_00.docnative_format_file_name=MyOriginalDocName.doc/>
L.5
Semantics of the metadata model

ThemetadatamodelisdefinedbyanXMLschematree,seeFigureL3.
FigureL3:XMLschematree
Thetoplevelbranchesshownareasfollows: a. data_package:rootofthemetadatamodel(SeeTableL1) 1. dde_definition_exchange: (a) dde_properties: metadata related to the whole TDP (See TableL2).
80
(b) (c) b. item_properties:metadatatobuildvirtualfolders.Eachitem canhavemanyelements(SeeTableL3). elements_properties: metadata to describe a file (See Table L4).
database: persons and companies that are linked to elements (See Table L5).
L.6
Data Tables description

TableL1toTableL5describethefinalblocksoftheprevioustree(definedby theecss_m_st_40.xsdXMLSchema). They also provide the semantics of each term with the corresponding ISO definitionifany. NOTE These tables are given to ease human understanding of the metadata model. However,onlytheecss_m_st_40.xsdXMLSchema isapplicable(seeclause5.3.7.4c).
The column ISO 10303 AP232 Definition contains the ISO definition. If specific comments in this standard alter the ISO definition, they are written insideagreybox. In order to locate precisely the blocks in the XML Schema tree, the full XML path is given above each group of terms using XPATH syntax (See http://www.w3.org/TR/xpath). Themandatorytermsareenclosedinsideasterisksandwrittenbold. Multipletermsrelatingtothesameparenttermareseparatedbydashedlines. TableL6providesadditionalinformationnecessarytothecomparisonofterms usedinTableL1toTableL5.
81
TableL1:data_package ECSSMST40term Designation ISO10303AP232Definition

/data_package *schemaVersion* Versionofthe XMLSchema SpecificECSSMST40(New) VersionoftheXMLSchema,theXMLfilerespects
Thistabledescribestherootofthedatamodel
Yourmapping
Example
2.3
2.3
TableL2:data_definition_exchange ECSSMST40term Designation ISO10303AP232Definition Yourmapping Example
/data_package/data_definition_exchange/dde_properties/dde_identification/
*identifying_number*
Datapackage reference
Theidentifying_numberspecifiesanidentificationnumber forthespecificgroupofproductinformationofinterestas issuedbytheDesign_activity. NOTETheidentifying_numbermaybeanalphanumeric.
A5TDP110000001ADLA FRE
date_of_transfer (date,specific_time)
DataPackage creationdate
Thedate_of_transferspecifiesthedateandtimewhenthe responsibleactivityinitiatedthetransferofthe Data_definition_exchange.Thedate_of_transferneednot bespecifiedforaparticularDatadefinition_ exchange_header.
date=20041115 specific_time=23:59:59.99999+ 02:00
82
ECSSMST40CRev.1 6March2009 ECSSMST40term

title
Designation
Datapackage title
ISO10303AP232Definition
Yourmapping
Example
SaturnExpressCritical DesignReviewDataPackage
Thetitlespecifiestheformaldesignationofthespecific groupofproductinformationofinterest.Thetitleneednot bespecifiedforaparticularElement_identification. NOTEThedocumenttitlemaybeanabbreviatedformof thetitleormayhaveabbreviationsofselectedwords withinthetitle.
dde_exchange_purpose
Purposeofthe exchange
Theexchange_purposespecifiestextualinformation wherethereasonfortheexchangecanbespecified.The exchange_purposeneednotbespecifiedforaparticular Reason.
CriticalDesignReview
*design_activity*
Issuingcompany Referencetothecompanyresponsibleforthedesign reference content. Projectcode Theconfiguration_idspecifiestheuniqueidentificationof avariationoftheProduct_model. Theproduct_namespecifiesthenameofthe Product_modelthatisunderconfigurationmanagement.
*configuration_Id*
A5
*product_name*
Projectname
Ariane5
preparing_contracts(list)
Specifiesthe contracts
Thepreparing_contractsspecifiesthecontractauthorizing thedevelopingoftheConfigurationofinterest.The preparing_contractsneednotbespecifiedforaparticular Configuration.Theremaybemorethanonepreparing_ contractforaconfiguration.
83

contract_number
Designation
Yourmapping
Example
Thecontract_numberspecifiesthecontractnumberusedto referencethecontract. NOTEThecontractnumbermaybeanalphanumeric identification.
contract_data_requirements _list
Thecontract_data_requirements_listspecifiesthecontract datarequirementlistclauseorcontractworklisting numberthatauthorizes,specifies,andregulatestheformal agreementbetweentwoormoreparties.Thecontractdata requirementslistispartofthecontract.The contract_data_requirements_listneednotbespecifiedfora particularcontract. Thedata_item_description_identificationspecifiesa specificsetofdataorsystemproductsthatarereferenced withinacontract.Thedata_item_description_identification neednotbespecifiedforaparticularcontract. Thedistribution_authorizationsspecifiestheallowable circulationofinformationthatisapplicabletothe Configuration.Thedistribution_authorizationsneednot bespecifiedforaparticularConfiguration.Theremaybe morethanonedistribution_authorizationsfora Configuration.
data_item_description_ident ification
distribution_authorizations (list)
Specifiesthe distribution notice(allowed persons distribution)
security_identifications
Thesecurity_identificationsspecifiesthesecurityor Specifiesthe securitylevelsof sensitivityoftheConfigurationanditscontents.The thedatapackage security_identificationneednotbespecifiedfora particularConfiguration.Theremaybemorethanone security_identificationsforaConfiguration.
84

item_classification
Designation
Theitem_classificationspecifiesthesecuritylevelor sensitivityleveloftheTdp_element.Thesecurity classificationisassignedbytheoriginatorbasedon predeterminedcriteria.
Yourmapping

Example
title_security_classification
Thetitle_security_classificationspecifiesthesecuritylevel orsensitivityofthetitleoftheTdp_element.Thesecurity classificationisassignedbytheoriginatorbasedon predeterminedGovernmentorcommercialcriteria restrictingthetitleornomenclatureusedwithinthetitle. Thetitle_security_classificationneednotbespecifiedfora particularSecurity_classification. Theclassification_datespecifiesthedatetheitemwas giventheitem_classification.Theclassification_dateneed notbespecifiedforaparticularSecurity_classification.
classification_date
EXAMPLEAradarabsorbing materialspecificationis classifiedonthedatethe specificationiscreated. EXAMPLEThesecret performancespecificationsto aretiredfighterjetis declassifiedonthisdate.
declassification_date
Thedeclassification_datespecifiesthedatetheitemwas giventheitem_classification.Thedeclassification_date neednotbespecifiedforaparticular security_classification.
release_authorizations(list) Identifiesthe companyand personthathas authenticated datapackage contents
Therelease_authorizationsspecifiestheoriginatingsystem sourcesthathaveauthenticatedtheConfigurationcontents forthepurposesofrelease.Therelease_authorizations neednotbespecifiedforaparticularConfiguration.There maybemorethanonerelease_authorizationsfora Configuration.
85

release_date (date,specific_time) release_authority
Designation
Yourmapping
Example
Therelease_datespecifiesthedateandtimethatthedesign releaseactivityreleasedtheTdp_element. Therelease_authorityspecifiesthenameoftheCompany responsibleforthereleaseoftheTdp_element. Theauthenticationspecifiestheoriginatingsystem identificationoftheauthentication. NOTETheauthenticationconstitutesanelectronic signaturethatassurestheintegrityoftheTdp_elements contents.Thismaybeconductedbyreviewingthe Tdp_elementscontentsorbyvalidatingtheautomated dataprocessingsystemproceduresthatconstructedor managestheTdp_element SpecificECSSMST40(Clarification) Thistermspecifiestheoriginatingsystem identificationoftheauthentication.
authentication
ThistabledescribesmetadatarelatedtothewholeTDP
86
ECSSMST40CRev.1 6March2009 TableL3:item_properties ECSSMST40term Designation ISO10303AP232Definition Yourmapping Example
/data_package/dde_definition_exchange/dde_body/item_properties/ *identifying_number* foldername Theidentifying_numberspecifiesanIdentifierora Drawing_suffix_number_combinationthatisanidentifierthat definestheidentificationnumberfortheItemasissuedbythe design_activityofthecomponent. SpecificECSSMST40(ReplaceISODefinition) Theidentifying_numberspecifiesanIdentifierthatdefines theidentificationnumberfortheItemasissuedbythe design_activityofthecomponent. nomenclature_or_name folderlabel Thenomenclature_or_namespecifiesthename,nounphrase,or abbreviatednameoftheItem.Thenomenclature_or_nameneed notbespecifiedforaparticularItem_identification.
ThistabledescribesmetadatatobuildvirtualfolderswithinaTDP.Eachitem(=folder)canhavemanyelements(=documents)
87
ECSSMST40CRev.1 6March2009 TableL4:element ECSSMST40term Designation ISO10303AP232Definition Your mapping Example
/data_package/dde_definition_exchange/dde_body/item_body/element/element_properties/ *identifying_number* Documentreference Theidentifying_numberspecifiesanidentification numberforthespecificgroupofproductinformation ofinterestasissuedbytheDesign_activity. NOTETheidentifying_numbermaybean alphanumeric *design_activity* Issuingcompany reference Thedesign_activitiesspecifiestheorganization, company,business,orindustryresponsibleforthe Element_identification. CNES ATVST10029CN
language_code
Thelanguagesspecifiesthetypeofvocabulary Specifiesthe languageuseinthe nomenclaturesusedinthedocumentor Tdp_elementtext.Thelangaugesneednotbe document. specifiedforaparticularHeader.Theremaybemore thanonelanguagesforaHeader. SpecificECSSMST40(Supplementaryinfo) ISO6392lettercode http://www.w3.org/WAI/ER/IG/ert/iso639.htm
FR EN DE
88
ECSSMST40CRev.1 6March2009 ECSSMST40term Designation ISO10303AP232Definition Your mapping Example
/data_package/dde_definition_exchange/dde_body/item_body/element/element_properties/identification/document_element/ *title* Documenttitle Thetitlespecifiestheformaldesignationofthe specificgroupofproductinformationofinterest.The titleneednotbespecifiedforaparticular Element_identification.. Thestatus_codespecifiestheprocessstageofthe information. NOTEProductDataManagement(PDM)systems usethisstatustoaidinidentifyingwhereinthelife cycleaninformationelementresides. *change_level* 1stlevelversion level(issue) Thechange_levelspecifiesthelatestalterationmade toaFile,Item,orTdp_elementaspartofarevision. Thechange_levelneednotbespecifiedfora particularChange_identification. NOTEForformatstandards,achangelevelmaybe thesameasanaddendumoramendment. SpecificECSSMST40(ReplaceISO Definition) Thechange_levelspecifiesthefirstlevelof versionidentification. Technicalspecificationofsolar array
*status_code*
Lifecycleor workingprocess stage
Unknown InPreparation InReview Released Withdrawn
ifversionis2.3thenthe change_levelis2andthe issue_levelis3
89

*date* specific_time
Designation
1stlevelversion date(issue)
Thechange_datespecifieseitherthedateandtime thatthechange_levelwasadvancedorthedateand timeofthechange.Thechange_dateneednotbe specifiedforaparticularChange_identification. SpecificECSSMST40(ReplaceISO Definition) Thechange_datespecifieseitherthedateand timeofthechange.
Your mapping
Example
date=20041115 specific_time=23:59:59.99999+02:00
issue_level
2ndlevelversion level(revision)
Theissue_levelspecifiestheissuenumberoftheFile, Item,orTdp_element.Theissue_levelneednotbe specifiedforaparticularChange_identification. NOTE1Changestodocumentsarenormallytracked byrevisionsandengineeringchangenotices. However,incaseswherechangestothedocument donotaffecttechnicalcontent,anewissueofthe documentmaybeprovidedforwhichnorevisionor engineeringchangenoticelevelisadvanced. SpecificECSSMST40(ReplaceISO Definition) Theissue_levelspecifiesthesecondlevelof versionidentification.
ifversionis2.3thenthe change_levelis2andthe issue_levelis3
90

date specific_time
Designation
2ndlevelversion date(revision)
Theissue_datespecifiesthedateandtimethatthe activityissuedtheFile,Item,orTdp_element.The issue_dateneednotbespecifiedforaparticular Change_identification. SpecificECSSMST40(ReplaceISO Definition) Theissue_datespecifieseitherthedateand timeoftheissue.
Your mapping
Example
date=20041220 specific_time=14:30:27
document_abstract
listofabstracts(in Thedocument_abstractspecifiesabriefoverviewof severallanguagesif thedocumentorTdp_element.The needed) document_abstractneednotbespecifiedfora particularHeader. Specifiesthelistof authorsforthe document. APersonisanindividualwithlegalrightsand duties.Apersonshallbeuniquelyidentifiedfor purposesofadataexchange. SpecificECSSMST40(Supplementaryinfo) Note:PersonandPerson_and_organization ISOtermsarereplacedby person_and_company Apersonshallexistinthe<database>section oftheXMLSchema
authors(list)
91

distribution_authorizations (list)
Designation
Specifiesthe distributionnotice (allowedpersons distribution)
Your mapping
Example
Thedistribution_authorizationsspecifiesthe allowablecirculationofinformationthatis applicabletotheConfiguration.The distribution_authorizationsneednotbespecifiedfor aparticularConfiguration.Theremaybemorethan onedistribution_authorizationsforaConfiguration. SpecificECSSMST40(ReplaceISO Definition) Thedistribution_authorizationsspecifiesthe allowablecirculationofinformationthatis applicabletotheElement.The distribution_authorizationsneednotbespecifiedfor aparticularElement.Theremaybemorethanone distribution_authorizationsforanElement.
element_code (list)
Typeofdocument
Theelement_codespecifiestheclassificationcodefor aTdp_element.
NT CR PR
92

keyword (list)
Designation
Specifiesthelistof keywordsinthe document
Thedocument_keywordsspecifieswordsthat describethemainthoughtortopicofadocumentor Tdp_element.Thedocument_keywordsneednot bespecifiedforaparticularHeader.Theremaybe morethanonekeywordsforaHeader. SpecificECSSMST40(Clarification) TheISOtermdocument_keywordsis renamedkeywordsinECSS_M_ST_40which isalistofkeyword
Your mapping
Example
changes_managed_by_sender Specifieswhether theelementis configuration managedbythe companyissuying theTDP proprietary_extensions Proprietary extensionsto documentmetadata
SpecificECSSMST40(New)
trueorfalse
SpecificECSSMST40(New) Iftwofirmswanttoexchangesomeadditional metadata,theycanusethisfieldtoaddsome (key,value)metadataortoextendtheXML Schemainordertoexchangenewmetadata. Note:Thesemetadataarenotexchangeable withcompaniesthatdonotusethesame proprietary_extensions.
93
/data_package/dde_definition_exchange/dde_body/item_body/element/element_properties/identification/ *proprietary_element* fullproprietary metadata(instead of document_element metadata) SpecificECSSMST40(New) Iftwofirmswanttoexchangemetadatathat arenotlinkedtodocuments,the proprietary_elementallowstoextendtheXML Schemainordertoexchangethesemetadata. Note:Thesemetadataarenotexchangeable withcompaniesthatdonotusethe same.proprietary_element. /data_package/dde_definition_exchange/dde_body/item_body/element/element_properties/entry_note(list) note Note Thenotespecifiestheexplanatoryremarksor notationsthatmaybeusefulorinformativetoa human.
type_of_notation
Typeofnotation
Thetype_of_notationspecifiesthetypeofnotation. Thetypeofnotationisacharacteristicofanotethat identifieshow,what,orwhereanotationisused. Theremaybemorethanonetype_of_notationfora Notation.Thetype_of_notationneednotbespecified foraparticularNotation.
94
/data_package/dde_definition_exchange/dde_body/item_body/element/element_body/entry_file(list) *context_file_name* Elementlocalfile pathwithintheZip archive,relatively tothemeta inf/datapackage.xml file Thecontext_file_namespecifiesthecomputersystem fileidentificationfortheFile. NOTEWhenafileisbeingexchanged,the context_file_nameisthefilesidentification. SpecificECSSMST40(Supplementaryinfo) . Inaddition,thepathisdefinedwithcharacters \.and.. ThisfieldisanImplementationfieldthat maybefilledautomaticallybytools ../revue10/ATVST10029 CN_02_05_[2].pdf
95
ECSSMST40CRev.1 6March2009 ECSSMST40term Designation ISO10303AP232Definition

Thenative_format_file_namespecifiesthe originatingcomputersystemapplicationfile identificationfortheFile.The native_format_file_nameneednotbespecifiedfora particularFile. NOTETheoriginatingcomputersystemfile identificationisgenerallyreferredtoasthenative filenameorthenativeapplicationfilename. SpecificECSSMST40(Supplementaryinfo) ThisfieldisanImplementationfieldthat maybefilledautomaticallybytools byte_size Filesize(inbytes) Thesizespecifiesstatisticsrelatedtothecomputer systemrepresentationoftheFile.Thesizeneednot bespecifiedforaparticularFile SpecificECSSMST40(Supplementaryinfo) ThisfieldisanImplementationfieldthat maybefilledautomaticallybytools 12563254
Your mapping
Example
specification.doc
*native_format_file_name* Nativeformatfile name (notthepath)
96
/data_package/dde_definition_exchange/dde_body/item_body/element/element_body/entry_url(list) *url* urlofacontent SpecificECSSMST40(New) Inthiscase,thecontentfileisnotstoredinside thedatapackage,onlythemetadataare. ThisfieldisanImplementationfieldthat maybefilledautomaticallybytools byte_size Filesize(inbytes) Thesizespecifiesstatisticsrelatedtothecomputer systemrepresentationoftheFile.Thesizeneednot bespecifiedforaparticularFile SpecificECSSMST40(Supplementaryinfo) ThisfieldisanImplementationfieldthat maybefilledautomaticallybytools
Thistabledescribesmetadataofafile
http://www.ecss.nl/index.html
12563254
97
ECSSMST40CRev.1 6March2009 TableL5:database ECSSMST40term Designation ISO10303AP232Definition

/data_package/database/companies/company *design_activity_code* Issuing Thedesign_activity_codespecifiesacompanyidentifiercodefor companycode theDesign_authorityresponsibleforthedesigncontent.The design_activity_codeneednotbespecifiedforaparticular Design_authority. NOTEManyindustryassociationsandgovernmentsassign uniquedesign_activity_codestoeachcompany. *name* Company name Companys address Thenamespecifiesthetextuallabelthecompanyisknownby ASTRIUM ASTR
Yourmapping
Example
address
Theaddressspecifiestheelectronicorphysicallocationwherethe companycanbeinterfacedwith.Theaddressneednotbespecified foraparticularCompany. /data_package/database/persons/person
*last_name* first_name middle_name title Email_address
Thistabledescribespersonsandcompaniesthatarelinkedtoelements
98
AdditionalinformationonTableL1toTableL5
Table L6 provides additional information to Table L1 to Table L5, by identifying all the ISO terms mentioned in column ISO 10303 AP232 DefinitionthatarenotdefinedincolumnECSSMST40term(notethatthese ISOtermscorrespondtointermediatenodesinthemetadatamodeltreewhose uniqueroleistogathersubtermswithoutanyothersemantics). Inthefollowingtable,infrontofeachISOtermpreviouslyidentified,anECSS MST40 term or a pointer to the Table L1 to Table L5 is given. For further details,seeecss_m_st_40.xsd.
TableL6:AdditionalinformationonTableL1toTableL5 ISO10303AP232
Change change_date Change_identification Configuration Contract data_definition_exchange data_definition_exchange_header Design_authority document_keywords Element_identification exchange_purpose File Header Issue issue_date Item item_classification item_identification Notation Person Person_and_organization Product_model Security_classification Tdp_element
ECSSMST40
change dateattributeofChangeelement change_identification configuration contract data_definition_exchange TableL2 Company Keyword(list) element_identification dde_exchange_purpose File replacedbydocument_elementType Issue dateattributeofIssueelement TableL3 item_classification item_identification Notation Person person_and_company replacedbyproduct_name security_classification TableL4
99
Annex M (informative) Digital signature

M.1 Introduction
This annex provides information about the main principles and the implementation of the digital signature as approval method for information/documents.
M.2 Digital signature main principles

Thedigitalsignaturemechanismreliesonanasymmetriccryptography. Maindigitalsignaturecomponentsare: Digitalsignaturereliesonthefollowingprinciples: Eachsignerhasprivateandpublickeys(asforacreditcard). Thesignerpublickeyislinkedtothesignerthroughacertificate(X.509). The certificate is delivered by a certification authority which authenticatesthesignerandwarrantstheprocessforcertificatedelivery. The signer signs the document with his/her own and protected private keyusingasignaturetool. Thesigneddocumentcontainssignature(s)andinformationenablingthe recipienttoverifythesignature(s). Ifneeded,therecipient,trustingthecertificationauthorityofthesigner, may verify signatures with the public key figuring in the signer certificate. apublicandprivatekey anX.509certificate acertificateauthority asignaturetoolimplementinghashandcipheralgorithm
100
FigureM1Digitalsignature
M.3 Certificates
M.3.1 X.509 certificate
X.509certificatescomplywiththeISO/IEC/ITUTX.509andIETFinternational standard. An X.509 certificate is a collection of a standard set of fields containing information about a user or device and their corresponding public key. The X.509standarddefineswhatinformationgoesintothecertificate. Additional detailed information can be taken from the following web site: http://www.ietf.org/rfc/rfc3280.txt.
M.3.2
Self-signed certificate
Aselfsignedcertificateisacertificateautogeneratedbythesigner.Sometools allowcreationofsuchcertificates.AselfsignedcertificateisNOTdeliveredby arecognizedcertificationauthoritythatguaranteesthesigneridentity.Thetrust levelofaselfsignedcertificateisextremelylow.
M.4 Digital signature implementation

Thereareseveralmeansandtoolsfordigitallysigningadocument;hereafteris describedaverysimpleimplementationforsigningPDFdocuments. NOTE UsingPDFformatallowsthedigitalsignatureand document to be embodied in a unique PDF document.
101
M.4.1
a.
Signature apposition
Signaturecanbeapposedaftercompletionofthefollowingsteps; ImplementandretrieveanX509signaturecertificate: Certificate may be acquired closely certification authoritiesas for example:

VERISIGN(http://www.verisign.com), THAWTE(http://www.thawte.com/), Cacert(http://www.cacert.org/)
A certificate retrieval search can be performed using MICROSOFT InternetExplorer. b. Find and install a signature tool like Adobe Acrobat Standard, or UTIMACO. TheseproductsenabletosignPDFwithanyX.509certificates. NOTE AdobeAcrobatStandardisdifferentfromAdobe AcrobatReader. For more detailed information, go to http://www.adobe.com , or http://www.utimaco.com.
c. d.
ImportthecertificateintoSignatureTool. SignthePDFdocumentusingSignatureToolfunctions.
M.4.2
a. b.
Signature verification
Auserwhoneedstoverifythedigitalsignatureverifierhastoinstall: AdobeAcrobatReaderorequivalentdependingonthesignaturetool Certificates of certification authorities (in standard with VERISIGN and THAWTE).
102
Bibliography
ECSSSST00 ECSSEST10 ECSSEST40 ECSSQST20 ECSSQST80 ISO10007:2003 ISO10303 ISO/IECTR 15846:1998 ASMEY14.1002000 ANSI/EIA649:2001
ECSSsystemDescription,implementationand generalrequirements SpaceengineeringSystemengineeringgeneral requirements SpaceengineeringSoftwaregeneralrequirements SpaceproductassuranceQualityassurance SpaceproductassuranceSoftwareproduct assurance QualitymanagementGuidelinesforconfiguration management AP232TDPdefinition InformationtechnologySoftwarelifecycle processesConfigurationmanagement Engineeringdrawingpractices ANSI/EIANationalConsensusStandardfor configurationmanagement
103

Ecss M ST 40c Rev.1 (6march2009)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ecss M ST 40c Rev.1 (6march2009)

Uploaded by

Copyright:

Available Formats

ECSS-M-ST-40C Rev.

Space project management

ECSSM40A 19April1996 ECSSM40B 20May2005 ECSSMST40C 31July2008

Thirdissuerevision1 ChangeswithrespecttoversionC(31July2008)areidentifiedwith revisiontracking.

4 Configuration management principles ...............................................................14

Management and planning.......................................................................................16

Implementation of configuration management ......................................................... 18

5 Configuration management requirements .........................................................33

Implementation of configuration management ......................................................... 34

3 Terms, definitions and abbreviated terms

Terms specific to the present standard

changethataffectsapprovedtechnicalspecifications,includinginterfacesofthe samelevel,andassociatedtermsofthebusinessagreementbetweenacustomer andhissupplier

configuration control board

configuration definition document

processforensuring timely and effective creation, collection, review, delivery, storage,andarchivingofprojectinformation

set of resources, procedures and data required in support of project managementprocesses

technical data package

4 Configuration management principles

Configuration management process and objectives

Information/documentation management process and objectives

Management and planning

Configuration management interfaces

Implementation of configuration management

Implementation of configuration management comprises definition, organization,executionandsupervisionofthefollowingactivities,asdepicted inFigure44: Configurationidentification

Implementation of information/documentation management comprises the activitiesdepictedinFigure48anddescribedinclause4.3.8.

Individual unit identification of a product can also include an additional identifier,suchasaserial(orfabrication)number,orlot(orbatch)number.

Figure45Configurationidentification 4.3.2.2 Configuration item

Configuration items, as defined in ECSSSST0001, fall into two categories, whichare:

Developed configuration item

Non-developed configuration item

Selection of configuration items

Customer/supplierlevel System Supplier/lowertiersupplierlevel

Figure46CIproducttreestructure 4.3.2.4 Configuration baseline

Digital file and media identification

Figure47Configurationcontrol 4.3.3.2 Change procedure

Configuration control board

Classification of changes and departures

Configuration status accounting

As-designed and as-built data list

Configuration management process audit

Configuration management approach for operational phase

Implementation of information/documentation management

Implementation of information/documentation management comprises the activitiesasdescribedinthefollowingsubclauses.

Creation and revision

Approval and release

Approvalcanbegiveneitherbyelectronicsignatureorbyprocessasdefinedin theCMPlan. Electronicsignatureorapprovalbyprocessensuresthat a. b. thedocumenthasnotbeenmodifiedafteritsapproval(i.e.integrity),and theauthorcannotdenyhisresponsibilityforthecontentofthedocument (i.e.nonrepudiation).

Figure410DeliveryprocessforTDP 4.3.8.5 Storage and retrieval

Storageandretrievaloverlapswiththeotherphasesdefinedabove.Thestatus ofthedocumentisnotchangedduringstorageandretrieval. Theinformationsystemisdeployedinordertohandlemetadataandstaticand dynamiccontent.Thereproducibilityandintegrityofthestoredinformationis ensuredfortheprogramme/projectlifecycle.

Archiving and retrieval

5 Configuration management requirements

Management and planning

Configuration management plan

Configuration management interfaces

Implementation of configuration management

Configuration item selection

Allproductitems,notdefinedasconfigurationitem,shallbemarkedor labelledincludingthefollowinginformation: 1. 2. Partnumber Serialorlotnumber,whenapplicable

Digital file and media identification

Digitaldatamediashallbeidentifiedbythefollowing: 1. 2. 3. 4. 5. 6. CIidentifier Filenames Versionandissue Dateofgeneration Generatingentity Totalnumberofdeliveredmediaperinformationset(1of...).

Classification of changes and departures

Departures from configuration baseline

Baseline and documentation update

Configuration status accounting