EN 16601-40:2014
(Main)Space project management - Configuration and information management
Space project management - Configuration and information management
The scope of this standard is to describe the processes and provide the requirements for managing the information/documentation and configuration of products within a space programme or project.
The requirements specified herein apply to, and affect the supplier and customer at all levels.
This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00.
Raumfahrt-Projektmanagement - Teil 40: Konfigurations- und Informationsmanagement
Der Anwendungsbereich dieser Norm umfasst die Beschreibung der Prozesse und die Festlegung der Anforderungen an das Informations-/Dokumentationsmanagement sowie das Konfigurationsmanagement von Produkten innerhalb eines Raumfahrtprogramms oder -projektes.
Die in dieser Norm festgelegten Anforderungen betreffen und gelten für Lieferanten und Kunden auf allen Ebenen.
Diese Norm darf auf die speziellen Merkmale und Vorgaben eines Raumfahrtprojekts nach ECSS S ST 00 ausgelegt werden.
Management des projets spatiaux - Gestion de la configuration et de I'informations
Vodenje vesoljskih projektov - 40. del: Vodenje konfiguracije in informacij
Področje uporabe standarda EN 16601-40 je opisati procese in zagotoviti zahteve za upravljanje informacij/dokumentacije ter konfiguracije izdelkov v okviru vesoljskega programa ali projekta. Zahteve, navedene v tem dokumentu, veljajo za dobavitelje in stranke na vseh ravneh. Ta standard se lahko prilagodi posameznim lastnostim in omejitvam vesoljskega projekta v skladu s standardom ECSS-S-ST-00.
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-november-2014
1DGRPHãþD
SIST EN 13290-5:2002
SIST EN 13290-6:2002
Vodenje vesoljskih projektov - 40. del: Vodenje konfiguracije in informacij
Space project management - Part 40: Configuration and information management
Raumfahrt-Projektmanagement - Teil 40: Konfigurations- und Informationsmanagement
Management des projets spatiaux - Partie 40: Gestion de la configuration et de
I'informations
Ta slovenski standard je istoveten z: EN 16601-40:2014
ICS:
03.100.40 Raziskave in razvoj Research and development
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD
EN 16601-40
NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2014
ICS 49.140 Supersedes EN 13290-5:2001, EN 13290-6:2001
English version
Space project management - Teil 40: Configuration and
information management
Management des projets spatiaux - Partie 40: Gestion de la Raumfahrt-Projektmanagement - Teil 40: Konfigurations-
configuration et de I'informations und Informationsmanagement
This European Standard was approved by CEN on 14 December 2013.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving
this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning
such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN and CENELEC
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC Management Centre
has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia,
Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre:
Avenue Marnix 17, B-1000 Brussels
© 2014 CEN/CENELEC All rights of exploitation in any form and by any means reserved Ref. No. EN 16601-40:2014 E
worldwide for CEN national Members and for CENELEC
Members.
Table of contents
Foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 8
3 Terms, definitions and abbreviated terms . 9
3.1 Terms from other standards . 9
3.2 Terms specific to the present standard . 9
3.3 Abbreviated terms. 11
4 Configuration management principles . 13
4.1 Overview . 13
4.1.1 Configuration and information/documentation activities . 13
4.1.2 Configuration management process and objectives . 13
4.1.3 Information/documentation management process and objectives . 14
4.2 Management and planning . 15
4.2.1 Configuration management plan . 15
4.2.2 Configuration management interfaces . 15
4.3 Implementation of configuration management . 17
4.3.1 Overview . 17
4.3.2 Configuration identification . 19
4.3.3 Configuration control . 23
4.3.4 Configuration status accounting . 25
4.3.5 Configuration verification . 26
4.3.6 Configuration management process audit . 26
4.3.7 Configuration management approach for operational phase . 26
4.3.8 Implementation of information/documentation management . 27
5 Configuration management requirements . 32
5.1 General . 32
5.2 Management and planning . 32
5.2.1 Configuration management plan . 32
5.2.2 Configuration management interfaces . 33
5.3 Implementation of configuration management . 33
5.3.1 Configuration identification . 33
5.3.2 Configuration control . 38
5.3.3 Configuration status accounting . 40
5.3.4 Configuration verification . 41
5.3.5 Audit of the configuration management system . 42
5.3.6 Configuration management approach for operational phase . 42
5.3.7 Implementation of information/documentation management . 43
Annex A (normative) Configuration management plan - DRD . 48
Annex B (normative) Configuration item list - DRD . 55
Annex C (normative) Configuration item data list (CIDL) - DRD . 57
Annex D (normative) As-built configuration list - DRD . 59
Annex E (normative) Software configuration file (SCF) - DRD . 61
Annex F (normative) Configuration status accounting reports -DRD . 64
Annex G (normative) Change request - DRD . 67
Annex H (normative) Change proposal - DRD . 69
Annex I (normative) Request for deviation - DRD . 71
Annex J (normative) Request for waiver - DRD . 73
Annex K (informative) Configuration item selection . 75
Annex L (informative) Technical data package description . 77
Annex M (informative) Digital signature . 99
Bibliography . 102
Figures
Figure 4-1 Configuration management . 14
Figure 4-2 Configuration management interface (inputs) . 16
Figure 4-3 Configuration management interface (outputs) . 17
Figure 4-4 Implementation of configuration management . 19
Figure 4-5 Configuration identification . 20
Figure 4-6 CI product tree structure . 21
Figure 4-7 Configuration control . 24
Figure 4-8 Implementation of information/documentation management . 27
Figure 4-9 TDP contents . 29
Figure 4-10 Delivery process for TDP . 30
Figure 4-11 Project phases and baseline definitions . 31
Figure L-1 TDP ZIP file . 78
Figure L-2 : ZIP archive . 79
Figure L-3 : XML schema tree . 79
Figure M-1 Digital signature . 100
Tables
Table G-1 : Change request scope and content . 68
Table H-1 : Change proposal scope and content . 70
Table I-1 : Request for deviation scope and content . 72
Table J-1 : Request for waiver scope and content . 74
Table L-1 : data_package . 81
Table L-2 : data_definition_exchange . 81
Table L-3 : item_properties . 86
Table L-4 : element . 87
Table L-5 : database . 97
Table L-6 : Additional information on Table L-1 to Table L-5 . 98
Foreword
This document (EN 16601-40:2014) has been prepared by Technical Committee
CEN/CLC/TC 5 “Space”, the secretariat of which is held by DIN.
This standard (EN 16601-40:2014) originates from ECSS-M-ST-40C Rev. 1.
This European Standard shall be given the status of a national standard, either
by publication of an identical text or by endorsement, at the latest by February
2015, and conflicting national standards shall be withdrawn at the latest by
February 2015.
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. CEN [and/or CENELEC] shall not be held
responsible for identifying any or all such patent rights.
This document supersedes EN 13290-5:2001 and 13290-6:2001.
This document has been developed to cover specifically space systems and has
therefore precedence over any EN covering the same scope but with a wider
domain of applicability (e.g. : aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards
organizations of the following countries are bound to implement this European
Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
This document defines the configuration management and
information/documentation requirements for space projects.
The document is structured into two main parts, the first part presenting the
processes and the second one providing the detailed requirements.
In addition, the expected configuration and information/documentation
management documentation is specified in the annexed document
requirements definitions (DRDs).
Scope
The scope of this standard is to describe the processes and provide the
requirements for managing the information/documentation and configuration
of products within a space programme or project.
The requirements specified herein apply to, and affect the supplier and
customer at all levels.
This standard may be tailored for the specific characteristics and constraints of a
space project in conformance with ECSS-S-ST-00.
Normative references
The following normative documents contain provisions which, through
reference in this text, constitute provisions of this ECSS Standard. For dated
references, subsequent amendments to, or revisions of any of these publications
do not apply. However, parties to agreements based on this ECSS Standard are
encouraged to investigate the possibility of applying the most recent editions of
the normative documents indicated below. For undated references the latest
edition of the publication referred to applies.
EN reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms
EN 16601-10 ECSS-M-ST-10 Space project management – Project planning and
implementation
EN 16602-10-09 ECSS-Q-ST-10-09 Space product assurance – Nonconformance control
system
EN 16602-20 ECSS-Q-ST-20 Space product assurance – Quality assurance
Terms, definitions and abbreviated terms
3.1 Terms from other standards
For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-
01 apply, in particular for the following terms:
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
approval of its configuration baseline
NOTE Adapted from ISO 10007.
3.2.2 class 1 change
change that affects approved technical specifications, including interfaces of the
same level, and associated terms of the business agreement between a customer
and his supplier
3.2.3 class 2 change
change that does not fulfil class 1 change criteria
3.2.4 configuration control board
person or a group of persons assigned responsibility and authority to make
decisions on the configuration
NOTE 1 This configuration control board is called
dispositioning authority in ISO 10007.
NOTE 2 Relevant interested parties within and outside the
organization are represented on the configuration
control board.
NOTE 3 Adapted from ISO 10007.
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
product structure
NOTE Adapted from ASME Y14.100.
3.2.6 configured item
any level of product whose functional or physical characteristics are recorded in
a retrievable, consistent manner
3.2.7 departure
inability of a product to meet one of its functional performance or technical
requirements
NOTE 1 Two types exist:
• planned departure resulting in request for
deviation, and
• unplanned departure resulting in request for
waiver.
NOTE 2 Departures do not change the engineering
documentation.
3.2.8 information/documentation management
process for ensuring timely and effective creation, collection, review, delivery,
storage, and archiving of project information
3.2.9 information system
set of resources, procedures and data required in support of project
management processes
3.2.10 metadata
metadata are structured, encoded data that describe characteristics of in-
formation-bearing entities to aid in the identification, discovery, assessment,
and management of the described entities
NOTE Adapted from Committee on Cataloguing Task
Force on metadata Summary Report.
3.2.11 product item
element of the product tree having a unique identifier
3.2.12 self-signed certificate
certificate auto-generated by the signer
3.2.13 technical data package
ZIP file containing structured collection of files with their related metadata, to
be exchanged between information systems
NOTE Adapted from ISO10303 AP232 TDP definition.
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, parts and material lists, processes and tooling.
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
and the following apply:
Abbreviation Meaning
ABCL as-built configuration data list
AR acceptance review
CAD computer aided design
CAGE commercial and government entity
CCB configuration control board
CD compact disk
CDR critical design review
CI configuration item
CIDL configuration item data list
CM configuration management
CP change proposal
CR change request
CSA configuration status accounting
DB design baseline
DCB development configuration baseline
DRD document requirements definition
DRL document requirements list
DUNS data universal numbering system
DXF drawing exchange format
EIDP end item data package
FCB
functional configuration baseline
FCV functional configuration verification
FTP file transfer protocol
H/W hardware
ICD
interface control document
IDM information documentation management
IEC
International Electrotechnical Commission
IETF internet engineering task force
IS
information system
ISO International Organization for Standardization
ITU
International Telecommunication Union
JPEG joint photographic experts group
LZW Lempel-Ziv-Welch
MOB mission objective baseline
MS Microsoft
NATO North Atlantic Treaty Organization
NCR nonconformance report
OTS off-the-shelf
PA product assurance
PCB product configuration baseline
PCV physical configuration verification
PDF portable document format
PDR preliminary design review
PI product item
PMP parts, materials and processes
PRR preliminary requirements review
QR qualification review
RFD request for deviation
RFW request for waiver
RID review item discrepancy
ROM read only memory
SCF software configuration file
SMTP simple mail transfer protocol
SRR system requirements review
STEP standard for the exchange of product
S/W software
TDP technical data package
TIFF tagged image file format
TRR test readiness review
TS technical specification
WBS work breakdown structure
XML extensible mark-up language
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,
depicted in Figure 4-1, are:
• management and planning;
• implementation of CM activities, i.e. configuration identification, control,
status accounting, and verification and audit;
• implementation of IDM activities, i.e. creation, collection, review,
delivery, storage and retrieval, and archiving.
4.1.2 Configuration management process and
objectives
Configuration management is the process for establishing and maintaining a
consistent record of a product’s functional and physical characteristics
compared to its design and operational requirements. Configuration
management is applied throughout the entire life cycle of the product and
allows one to:
• know at any time the technical description of a product using approved
documentation;
• record and control the evolution in the technical description of a product
(e.g. system and its products);
• provide traceability of the evolution of the product’s technical
description;
• ensure the consistency of the internal interfaces;
• verify and demonstrate to all actors that documentation is and remains
the exact image of the products it describes;
• identify the current configuration baseline and the as-built configuration
of a product, to record discrepancies detected during production,
delivery or operation and dispositioned for further use;
• enable any actor to know the operational possibilities and limitations of
each product item and, in case of nonconformance, to know which items
are affected.
Corrective actions
CM Plan
Management
requirements
CM procedures
Management & Baseline content (agreed set of documents)
Configuration item + Configuration item list
planning
Dispositioned changes (e.g. CRs,CPs,RFDs,RFWs)
Configuration item data list/
Software configuration file
Implementation of
RIDs As-built configuration list definition
configuration management
Configuration status accounting reports
Engineering requirements
Logistic Maintenance plan
Validated baseline
Product tree
Project documentation
Validated CM System
Request for change (e.g. CR,CP,RFD,RFW, NCR)
PA requirements
Legal requirements
for storage/archiving
Documents electronically signed
Collection of infos
Implementation of
Electronic signature
Delivered documents + Meta-data
Distribution list information/documentation
XML schema
management
Security requirements (access control)
Project archived documents
Protection requirements
NOTE: Corrective actions are improvements on the process itself as a consequence of lessons learned and any
feedback provided on the project
Figure 4-1 Configuration management
4.1.3 Information/documentation management
process and objectives
Information/documentation management is the process for ensuring timely and
effective creation, collection, review, delivery, storage, and archiving of project
information. To achieve this objective, all recorded project information is
managed electronically.
Information/documentation management is applied throughout the entire life
cycle of the project and allows someone to
• ensure the correctness, accessibility, rapid availability, reliability and
security of information provided to all the actors both internal and
external to the project;
• ensure the coherence of the overall project information, thus facilitating
effective and efficient use of the information;
• ensure that all the actors who need access to information are aware of its
availability, the means of access, and related methods and procedures;
• support the programme / project reporting.
4.2 Management and planning
4.2.1 Configuration management plan
The customer defines the configuration management requirements for a
programme or project. These requirements are applicable to all the actors of the
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 customer’s configuration management requirements.
The CM plan is submitted to the customer for approval. Upon customer
approval, the supplier executes his own CM plan and ensures that his lower tier
suppliers execute their CM plan.
The purpose of the CM plan is to define the process and resources for managing
the configuration of the product in a controlled and traceable manner
throughout the programme or project life cycle. It also describes the means for
an efficient comparison between the predicted (“as-designed”) and the actual
(“as-built”) 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
the information/documentation management meets all customer requirements,
and that it is in line with the programme or project organization and
management structure.
The customer defines the programme or project phase during which the CM
plan is prepared and approved.
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,
responsibilities and authorities are described in the CM plan.
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
configuration management and it contributes to programme or project activities
by provision of all the necessary information through the information system.
The information system is a repository of information where the project
disciplines implement data and activate processes. These interfaces are used to
establish the configuration management process.
Necessary inputs for configuration management are depicted in Figure 4-2.
Figure 4-3 summarizes the outputs provided by configuration management and
Information/documentation management to other project activities.
Other project
management
activities
Management requirements and schedule
Logistic/Maintenance plan
Request for changes
RIDs
Configuration management
Product
Engineering
assurance
Information/documentation
management
Request for changes Engineering requirements
Project documentation Product tree
RIDs
Request for changes
Project documentation
RIDs
Figure 4-2 Configuration management interface (inputs)
Other project
management
activities
CIs + Configuration item list
Dispositioned changes (CPs, RFDs, RFWs)
Configuration status accounting reports
Validated baseline
CM proposed corrective actions
Validated CM system
Configuration management
Product
Engineering
assurance
Information/documentation
management
CIs + Configuration item list CIs + Configuration item list
Baseline content (agreed set of Baseline content (agreed set of
documents) documents)
Dispositioned changes (CPs, RFDs, Dispositioned changes (CPs, RFDs,
RFWs) RFWs)
Configuration item data list/Software Configuration item data list/Software
configuration file configuration file
As-built configuration list definition Validated baseline
Validated baseline Reliable and secure information
Validated CM system
Reliable and secure information
Figure 4-3 Configuration management interface (outputs)
4.3 Implementation of configuration management
4.3.1 Overview
Implementation of configuration management comprises definition,
organization, execution and supervision of the following activities, as depicted
in Figure 4-4:
• Configuration identification
to identify the product architecture;
to select configuration items and to define their configuration
documents;
to establish means for identifying products and documentation;
to define identification requirements for software media;
to establish configuration baselines for the purpose of
requirements- and design-management.
• Configuration control
to establish and implement a change control process for individual
products and systems, and their internal and external interfaces;
to record and control the configuration of a product at any time
during its evolution;
to record the different configurations of a product;
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
including back-up copies in a controlled environment.
• Configuration status accounting
to provide a product definition by reference to approved and
recorded configuration statuses;
to enable access to software libraries according to established
privileges.
• Configuration verification and audit
to verify and demonstrate that the product meets its documented
functional, performance and physical characteristics;
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
activities depicted in Figure 4-8 and described in clause 4.3.8.
Engineering requirements
Logistic/maintenance plan Configuration items + Configuration item list
Product tree
Configuration
identification
Project documentation Baseline content (agreed set of documents)
CM Plan
Dispositioned changes (CPs, RFDs, RFWs)
Configuration
control
Request for change (e.g. CPs, RFDs, RFWs, NCRs)
Configuration item data list / Software configuration file
As-built configuration list
Configuration
status accounting
Configuration status accounting reports
Configuration
verification
RIDs
CM corrective actions
Configuration
audit
CM procedures
Validated CM system
Figure 4-4 Implementation of configuration management
4.3.2 Configuration identification
4.3.2.1 Overview
Configuration identification, as depicted in Figure 4-5, incrementally establishes
and releases controlled documentation for the purpose of identifying
configuration characteristics of a product until it is fully defined with respect to
its intended functional, performance and physical characteristics, thereby
ensuring the continuous integrity of the product configuration.
Configuration identification also provides the basis for evolution through
controlled changes and status accounting of a product throughout its life cycle.
It ensures that all programme or project disciplines are provided with identical
documentation for their use.
By applying product item identifiers to the product, configuration identification
enables traceability from the product to its defining documentation.
The product item identifier is represented through the item identification code
established by the governing configuration definition document. The product
item identifier can be
a. the same code applied for identifying the configuration definition
document,
b. a code containing this code, or
c. a different code defined within the configuration definition document.
NOTE To avoid the possible existence of the same
product item identifier for different product
item(s), a common practice is to prefix the product
item identifier with an enterprise identifier, such
as a DUNS number, or NATO CAGE code.
Individual unit identification of a product can also include an additional
identifier, such as a serial (or fabrication) number, or lot (or batch) number.
Corrective actions
Product tree
Logistic/maintenance plan
Configuration items + Configuration item list
CI selection
Engineering requirements
CM Plan
Documentation type definition
Define baseline
content
Project and documents identifiers assigned
Identify documents and
items
Dispositioned changes (CPs, RFDs, RFWs)
Baseline content
Release baseline content
(agreed set of documents)
Project documentation
Figure 4-5 Configuration identification
4.3.2.2 Configuration item
Configuration items, as defined in ECSS-S-ST-00-01, fall into two categories,
which are:
4.3.2.2.1 Developed configuration item
This is a configuration item subject to development and fully or partially
designed for the programme or project. Its configuration management conforms
to the programme or project configuration management requirements and is
carried out by the supplier responsible for its development.
4.3.2.2.2 Non-developed configuration item
This is a configuration item being a standardized or “off-the-shelf” product that
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
used without modification.
Configuration management of non-developed CIs conforms to the programme
or project configuration management requirements to the extent necessary for
its integration into the next higher level configuration item.
4.3.2.3 Selection of configuration items
The product tree, as defined in ECSS-M-ST-10, is used for the selection of
configuration items and serves as a basis for the programme or project work
breakdown structure.
Configuration items are identified at various levels of the product tree, as
depicted in Figure 4-6, and defined at least by a technical specification.
Configuration item assignment provides the means for configuration control of
the product. Each CI becomes also a configured item during its development.
Selection of configuration items starts at the early definition phase of a
programme or project to build a manageable set of hardware or software items.
The responsibility for identifying an item as a CI rests with the customer, unless
delegated by him to the supplier.
No fixed rules govern the selection of configuration items. The process for
selecting configuration items relies on good system engineering judgment, and
configuration management experience, supported by cost trade-off
considerations.
Customer/supplier level
System
Supplier/lower tier supplier level
(*) in both levels
CI (*)
CI CI
CI CI CI
Figure 4-6 CI product tree structure
4.3.2.4 Configuration baseline
Configuration baselines represent the approved status of requirements and
design at key milestones of the programme or project and provide the point of
departure for further evolution (see Figure 4-11). These configuration baselines
are applicable to both hardware and software.
A configuration baseline comprises the documentation that describes the
characteristics of a product. This documentation is formally designated as the
configuration reference at a key point in the product life cycle corresponding to
a major product definition event. Any subsequent change of a product
characteristic proposed for this documentation is subject to a formal change
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
the following sequence:
• 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
operational and performances capabilities for each phase of its life cycle,
and the permissible flexibility.
• Functional configuration baseline (FCB) is established at SRR based on
the approved system technical specification. This baseline establishes the
system’s characteristics in terms of its technical requirements, as well as
the criteria and corresponding levels of qualification and acceptance.
• Development configuration baseline (DCB) is established at PDR based
on approved technical specifications (TS). This baseline establishes the
product’s characteristics in terms of technical requirements and design
constraints, as well as their verification conditions.
NOTE FCB and DCB are also named “Requirements
baselines” in different standards.
• Design baseline (DB) is established at CDR based on the approved design
documentation.
• Product configuration baseline (PCB) is established at FCV/PCV for serial
production, or QR/AR for prototypes based on the approved set of
documents containing all the functional and physical characteristics
required for production, acceptance, operation, support and disposal.
The log book, as in ECSS-Q-ST-20, is established at successful completion of the
acceptance review and is maintained during the utilization and disposal phases.
Details relevant to the configuration management approach during these
phases are provided in clause 4.3.7.
4.3.2.5 Identification marking
Each item, H/W and S/W is uniquely identified by a specific identification code.
The identification code is assigned to a product to distinguish it during its
entire life. The rules for the identification coding system are established in the
CM plan.
A configured H/W item is identified by a part number and, if necessary, a serial
or lot number such that every single item has a unique identifier. In this
context, bulk material is treated as a part. A configured S/W item is identified
by a unique code and version number. When the configured item is a
configuration item, its identification also includes a CI identifier. These different
product identification data are applied on the product itself or, when not
possible, linked to the product.
4.3.2.6 Digital file and media identification
Configuration identification also provides the means for maintaining
traceability from a product to its design definition data resident in an electronic
database (digital files).
Such data, represented by digital files, are composed by a variety of subset data,
which are merged in a controlled manner in order to represent the product
design definition concerned in the intended configuration.
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. library management).
Digital files defining the configuration characteristics of a product item are
therefore subject to the same configuration management principles applicable
to configuration documentation.
The application of configuration identification rules to digital data are
applicable for
• digital data identification,
• digital data storage,
• maintenance of digital data relating to the product,
• version control of digital data and the related change management
process,
• controlled access to digital data, and
• digital data transmittal.
4.3.3 Configuration control
4.3.3.1 Overview
Configuration control, as depicted in Figure 4-7, is the process for controlling
the evolution of, or departures from agreed baselines. It includes the
preparation, justification, evaluation, disposition and implementation of
engineering and contractual changes, deviations and waivers.
Corrective actions
CIs + Configuration listt
Request for change
and departure
Request for change
package
Initiate request
Project documentation
for change
CM Plan
RFDs and RFWs
Assess change
impact
Change effectivity and classification
Baseline content (agreed set of documents)
Dispositioned changes (CPs, RFDs, RFWs)
Authorize and implement
change
Approved baseline
Figure 4-7 Configuration control
4.3.3.2 Change procedure
Configuration control ensures that all changes, deviations and waivers to
agreed configuration baselines, including their released and approved
documentation are processed and controlled in a traceable manner.
The configuration control process ensures that the following activities are
covered:
• prevention of changes affecting degradation of product capability;
• involvement of all actors in the concerned analysis and decision process
of changes;
• control that authorized changes or deviation are implemented, verified
and recorded;
• prevention of the implementation of unauthorized changes or deviations.
Change control procedures are applied following the establishment of the first
baseline.
All released baseline documentation, thereafter, is subject to configuration
control, including submission to the customer for higher-level approval or
review, as necessary. As such, no formal change can be generated without an
approved baseline.
A change can be either
• initiated by the customer (e.g. evolution of requirements) followed by a
reply from the supplier within a defined time limit, or
• proposed by the supplier (e.g. self initiated improvement of design)
followed by a response from the customer.
4.3.3.3 Configuration control board
Configuration control boards (CCB) are established at each project level as the
relevant authority for all changes. The CCB is convened by the configuration
manager in agreement with the project manager. The CCB consists of
permanent representatives of all programme or project disciplines necessary for
the review and evaluation of changes. The members of the CCB are with
decision-making authority.
A change initiated by the customer can only be implemented after examination
and approval of the supplier’s response, e.g. change proposal.
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
departure as major or minor. The change or departure can be reclassified by the
next higher level CCB.
According
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...