System Integration Guide
Technical Data Management Handbook
Defence Materiel Handbook (ENG)
12-2-003
[pic]
Defence Materiel Handbook
(Engineering Management)
DMH (ENG) 12-2-003
Technical Data Management Handbook
[pic]
DMH (ENG) ARE ISSUED UNDER THE SYSTEM OF DEFENCE MATERIEL INSTRUCTIONS
Original issue
© AUSTRALIAN GOVERNMENT (DEPARTMENT OF DEFENCE) 2014.
This work is copyright. Apart from any use as permitted under the Copyright Act 1968, no part may be reproduced by any process without prior written permission from the Department of Defence.
TABLE OF CONTENTS
1 Introduction 1
1.1 Purpose of this Guide 1
1.2 What is Technical Data? 1
1.3 How much Technical Data? 5
2 Technical Data Management 5
2.1 Technical Data Management Activities 5
2.2 Technical Data in the Capability System Life Cycle 6
2.2.1 Life Cycle Phases Overview 6
2.2.2 Needs Phase 7
2.2.3 Requirements Phase 7
2.2.4 Acquisition Phase 8
2.2.5 In Service Phase 8
2.2.6 Disposal Phase 8
3 Identification - Technical Data Requirements Analysis 9
3.1 Introduction 9
3.2 System Definition 9
3.3 Technical Data associated with a System 11
3.4 Activities requiring Technical Data 13
3.5 Technical Data associated with Support 15
3.6 Technical Data Formats 18
4 Acquisition and Creation of Technical Data 19
4.1 Rights to Technical Data 19
4.2 Objectives 19
4.3 ASDEFCON and Technical Data 19
5 Verification, ValidatION and Acceptance of Technical Data 20
5.1 Purpose of Verification and Review / Acceptance 20
5.2 Data Quality Verification 20
5.3 Data Marking Inspection 21
5.4 Metadata Standard 21
5.5 Validation of Technical Data 21
5.6 Technical Information Review 21
5.7 Contractual Endorsement/Review 22
6 Storage, Maintenance and Control of Technical Data 22
6.1 Purpose 22
6.2 Storage Systems 22
6.3 Access Controls and Maintenance 23
6.4 Configuration Management 23
6.5 Unique Identification. 24
6.6 File and Database Management. 24
6.7 Maintenance of Essential File and Version Relationships. 24
7 Use, Distribution and Exchange of Technical Data 25
7.1 General 25
7.2 Enterprise-wide Access and Use 25
7.3 Data Management System 25
7.3.1 Facilitating Data Exchange 25
7.3.2 DMS General Requirements 25
7.3.3 DMS Implementation and Management 26
8 Archival and Disposal of Technical Data 27
8.1 Overview 27
8.2 Legal Archival, Destruction or Disposal 28
8.3 National Archives Act and POLMAN 3 28
8.2 Legal Archival, Destruction or Disposal 28
8.3 National Archives Act and POLMAN 3 28
List of Figures
Figure 1 – Hierarchy of Technical Data Information Categories 3
Figure 2 - Optimum level of Technical Data 5
Figure 3 – Technical Data Management Activities 6
Figure 4 – Capability System Life Cycle Phases 6
Figure 5 – Technical Data understanding and requirements change during CSLC 7
Figure 6 – Capability System Breakdown 10
Figure 7 – Product Breakdown Structure 10
Figure 8 – Technical Data Items assigned as required for different Activities 14
Figure 9 – Technical Data Requirements depend on Acquisition Needs, Support Concepts and Business Needs 15
Figure 10 – Support System Constituent Capabilities and Resources 15
Figure 11 – Support Services and Organisations for some System Components 17
Figure 12 – Exchange and Flow of Technical Data Across a Product Lifecycle 18
List of Tables
Table 1 – Uses for Product Technical Data in Different Information Categories 4
Table 2 – Information Categories of Technical Data generated during the CSLC 6
Table 3 – Examples of Technical Data associated with the System PBS 12
Table 4 – Examples of Technical Data associated with Support System Constituent Capabilities 16
Table 5 – Product Technical Data Information Categories 2
Annexes
Annex A: Technical Data Format
Annex B: Referenced Documents
Annex C: Definitions and Abbreviations
Introduction
1. Purpose of this Guide
1. This guide is intended to assist Defence Materiel Organisation (DMO) personnel to manage Technical Data in Materiel Systems acquisition and sustainment.
2. This guide should be read in conjunction with the applicable policy relating to Intellectual Property, currently contained in the Defence Intellectual Property Manual. DMO is currently undertaking a review of the ASDEFCON template provisions relating to Technical Data and Intellectual Property and will release updated policy in this regard in due course.
2. What is Technical Data?
1. In accordance with DEFLOGMAN[1], Technical Data includes all technical know-how and information reduced to material form (includes digital form) relating to a Materiel System (including subordinate products), and includes all data, manuals, handbooks, designs, standards, specifications, reports, writings, models, sketches, plans, drawings, calculations, software documentation, test results and other items describing or providing information relating to the Materiel System. The ASDEFCON templates contain a definition of Technical Data for the purposes of Defence contracts which is currently being reviewed by DMO.
2. The range of information considered to be Technical Data can be shown as a hierarchy of information categories illustrated by Figure 1[2]. Technical Data does not include financial, contract management and administrative data (eg contract master schedules, project management plans, risk management plans, contract status reports and meeting agendas/minutes).
3. The current ASDEFCON definition of Technical Data includes software (ie the instructions to be used directly or indirectly in a computer in order to bring about a certain result). However, the revised ASDEFCON templates will make it clear that Technical Data does not include software. Software forms part of the product; however software documentation (including source code listings) associated with the software is Technical Data.
4. Technical Data can be related directly to a product of interest, Product Technical Data, or it can be more general Non-Product Technical Data (eg general technical catalogues and standards not currently used in a product). Non-Product Technical Data may also include data such as Civil Aviation Safety Authority (CASA) or Federal Aviation Administration (FAA) notifications that will require assessment by a competent delegate to determine if there is any impact on a product of interest. This handbook is concerned with Product Technical Data, ie Technical Data of relevance to a DMO product of interest.
5. As shown in Figure 1, Product Technical Data can be considered as belonging to three broad categories (with some overlap) which are described by:
a. Technical Product Definition Information: Information that describes the product’s performance, functional and physical attributes, including requirements and design information. Product definition information provides the technical basis for actions taken during all product life cycle phases, for product validation and for product operational information;
a. Technical Associated Information: Information generated as part of the product development, delivery and lifecycle management process, but is not clearly definable as either product definition information or product operational information; and
b. Technical Product Operational Information: Information that is derived from the product definition information. Product operational information consists of procedures and technical information needed by operators and support personnel to operate, maintain and dispose of the product.
6. Some of the uses and typical examples of Product Technical Data are listed in Table 1. This is list is not exhaustive and provides only a subset of Technical Data items as examples.
7. Personnel (particularly systems engineers and project managers) should be aware that terms such as “technical data”, “product data” and “TDP” are often imprecise in their definition, not equivalent and are often used incorrectly or inconsistently.
8. [pic]
Figure 1 – Hierarchy of Technical Data Information Categories
| |Information Category |Use |Typical Examples |
|Techni|Requirements Information |Captures and documents: |Operational Concept Documents |
|cal | |how a system/component will be used, |Function and Performance Specifications |
|Produc| |what functions must be performed, |System Specifications |
|t | |level of performance required, |Support System Specifications |
|Defini| |which constraints will apply, and |Software Requirements Specifications |
|tion | |traceability of requirements through the product |Requirements Databases |
|Inform| |hierarchy. |Requirements Traceability Matrices |
|ation | | | |
| |Design Information |Captures, documents and records: |Logical models[3] |
| | |how a design was performed, |Product Models |
| | |why certain design decisions are made, and |Product Drawings |
| | |what components were selected and why. |Software Design Descriptions |
| | | |Design Documentation |
| | | |System Architecture Description |
| | | |Trade Study Reports |
| |Manufacturing Information |Documents and records: |Circuit Schematics |
| | |what will be manufactured, |Printed Circuit Board Layout Files |
| | |how it will be manufactured, |Assembly Drawings |
| | |components required for manufacture, and |Parts Lists |
| | |any specific processes required. |Bill of Materials |
| | | |Engineering Drawings |
| | | |Computer Software Source Code |
|Techni|Verification Information |Captures, documents and records: |Test Concept Documents |
|cal | |validation and verification concepts, |Test & Evaluation/Acceptance Master Plans |
|Associ| |validation and verification planning, |Acceptance Test Plans, Procedures, Reports & |
|ated | |validation procedures and results, |Results |
|Inform| |verification procedures and results, and |Test Procedures & Results |
|ation | |traceability from requirements to validation and |Verification Cross Reference Matrices |
| | |verification results. | |
| |Configuration Control |Documents and records: |Master Record Indices |
| |Information |system or component configuration, |Configuration Status Accounting Reports |
| | |configuration at specific instances such as: |Engineering Drawings |
| | |baseline, |Parts Lists |
| | |version release or upgrade, or |Software Version Description Documents |
| | |product issue, and |Configuration Identifiers |
| | |constituent parts and processes. |Configuration Baselines |
| |Other Associated Information |Captures, documents and records: |GIDEP Notices of Obsolete Parts |
| | |associated information not in verification or |Suppliers Notices of Obsolete Parts |
| | |configuration control categories. |Disposal Information |
|Techni|Logistics Product Data |Documents and records: |Failure Modes & Effect Criticality Analyses |
|cal | |system or component availability and reliability, |Reliability Centred Maintenance Reports |
|Produc| |sparing analysis, |Level of Repair Analyses |
|t | |preventive/corrective maintenance procedures |Logistic Support Analyses |
|Operat| |repair/replace procedures, |Training Needs Analysis Reports |
|ional | |support & test equipment requirements, |Support & Test Equipment Plans and Provisioning |
|Inform| |software support requirements, and |Lists |
|ation | |training needs. |Software Support Plans |
| |Materiel In-Service Data |Documents, defines or provides: |Codification Data |
| | |spares holdings and usage, |Spares Lists |
| | |technical publications, |Publication Packages |
| | |training records, |Operator, Maintenance Manuals |
| | |electronic manuals, |Servicing and Inspection Instructions |
| | |servicing frequencies and inspection criteria, |Software Operator / User Manuals |
| | |determination of materiel useability |Maintenance Management System Data |
| | |interactive electronic manuals, and |Interactive Electronic Technical Manuals |
| | |system and component availability records |Defect Reports |
| | | |Training Materials |
| | | |Operator/Maintainer Training Courses |
Table 1 – Uses for Product Technical Data in Different Information Categories
3. How much Technical Data?
1. One of the fundamental issues involving Technical Data is how much is required? Technical Data is a resource with an associated cost. If Technical Data is insufficient or inadequate then Life Cycle Cost (LCC) will increase as support functions may not be able to be performed or may not be performed efficiently and cost effectively (Figure 2). Too much Technical Data will have an excessive acquisition cost and increase LCC from inefficient use of data management and support resources. Often requirements for Technical Data have to be identified early in the Capability System Life Cycle when the Materiel System’s product breakdown structure is not completely known (eg before contract award). Attempting to obtain as much data as possible is to be avoided without significant consideration of known Materiel System details. Not only can too much Technical Data result in excessive costs and demands on resources for the Commonwealth, it may create an adversarial and unhelpful relationship with the contractor(s) / supplier(s).
[pic]
Figure 2 - Optimum level of Technical Data
Technical Data Management
4. Technical Data Management Activities
1. Technical Data Management includes the following activities, as shown in Figure 3:
a. identification of Technical Data requirements, including content and any required format, through a Technical Data Requirements Analysis (TDRA);
c. acquisition and creation of Technical Data, including consideration of the Intellectual Property (IP) rights associated with Technical Data;
d. verification, validation and acceptance of Technical Data;
e. storage, maintenance and configuration control of Technical Data;
f. use, distribution and exchange of Technical Data; and
g. archival and disposal of Technical Data.
2. Technical Data Management also includes: understanding, obtaining and protecting Commonwealth owned data and associated IP rights (as well as rights licenced by third parties to the Commonwealth); retaining the ability to achieve future competition goals[4], maximising options for product support and enabling performance of downstream life cycle functions.
[pic]
Figure 3 – Technical Data Management Activities
5. Technical Data in the Capability System Life Cycle
1 Life Cycle Phases Overview
1 The Capability System Life Cycle (CSLC) has five phases[5] as illustrated in Figure 4. DMO provides a Materiel System as a component of the Capability System.
[pic]
Figure 4 – Capability System Life Cycle Phases
2 Technical Data management activities occur across all phases of the CSLC. Some activities are more likely to occur during certain CSLC phases than others. For example, acquisition or creation of Technical Data occurs predominantly during the Acquisition phase of a Materiel System. Table 2 identifies the CSLC phase during which the information category of Technical Data is most likely to be generated.
|Information Category |CSLC Phases |
| |Needs |Requirements |Acquisition |In Service |Disposal |
|Requirements Information |( |( |( | | |
|Design Information | |( |( |( | |
|Manufacturing Information | |( |( |( | |
|Verification Information |( |( |( |( |( |
|Configuration Control Information | |( |( |( |( |
|Logistics Product Data | | |( |( |( |
|Materiel In-Service Data | | |( |( |( |
Table 2 – Information Categories of Technical Data generated during the CSLC
3 Figure 5 illustrates how Defence’s understanding and requirements for Technical Data can change throughout the CSLC, evolving as the state of the system design and associated support concepts develop.
[pic]
Figure 5 – Technical Data understanding and requirements change during CSLC
2 Needs Phase
1 Technical Data captured or generated during this phase will mainly comprise requirements information, and possibly some preliminary design information and/or verification information (eg evidence of prior certification). Key Technical Data issues identified in this phase will inform the Acquisition and Support Implementation Strategy (ASIS)[6].
3 Requirements Phase
1 Technical Data captured or generated during the Requirements Phase will comprise mainly requirements, initial design and verification information. This includes information that provides evidence of technical suitability of potential solutions. The Requirements phase is broken into the following sub-parts to better depict how Technical Data requirements can evolve.
2 Initiation to Options Definition. During this part of the Requirements Phase, a draft Operational Concept Document (OCD), Function and Performance Specification (FPS) and Test Concept Document (TCD) or equivalent will be issued. These documents will allow the development of an “exemplar” system design which may be rudimentary and at a very preliminary stage. At this stage, it will not be possible to perform a comprehensive TDRA. However, there may be enough information to commence identification and some definition of initial Technical Data requirements.
3 Options Definition to Solicitation. During this part which spans First Pass (1P), final versions of the OCD, FPS and TCD will have been generated. The exemplar system design will have evolved to the extent that a solution class has been defined. It is critical that a more detailed TDRA is conducted at this stage and used to define the Technical Data-related requirements in the solicitation documents. Proposed approaches to Technical Data should be considered as part of the tender evaluation. Technical Data requirements should be assessed for potential implications on the contract and future support. Contract data items and content requirements should be developed and reviewed to confirm they address what is required.
4 Solicitation to Contract Award. During this time, system design(s) and proposed solutions will evolve through significant interaction between DMO and industry (ie one or more potential suppliers) including a joint TDRA where applicable; and the Technical Data requirements and overall approach will be need to be revised based on these proposals. Final Technical Data requirements will be negotiated and included in the contract. This period will also need to address any restrictions, limitations, or licensing obligations applying to Technical Data and reflect these in the final contract.
4 Acquisition Phase
1 A significant amount of Technical Data from all information categories will be captured or generated during the Acquisition Phase. Any Technical Data deliverables should be verified against the Technical Data requirements specified in the contract. Defence’s Technical Data requirements as identified through the TDRA process should be reviewed and reassessed at significant events throughout the product’s development such as mandated system reviews.
2 Mandated system reviews or other technical reviews conducted during the Acquisition Phase should include a review of all relevant Technical Data, including data that may have not been identified specifically as a deliverable under the contract. These reviews will determine whether further Technical Data should be provided and what limitations may apply to its provision, use and disclosure. The full scope of the Technical Data requirements is established as a baseline at the Detailed Design Review.
3 In this phase, the system design will be finalised and the full scope of Technical Data will be known and should be reviewed against the TDRA.
5 In Service Phase
1 During the In Service Phase, Technical Data requirements shift focus onto its use, access required, means of distribution and controlled evolution through system changes. Often, the users of Technical Data will be organisations other than the acquisition agency and acquisition (or original) contactor. Therefore, requirements for access, means of distribution and control of Technical Data need to be understood and established (refer to DMH (ENG) 12-2-002 Configuration Management handbook for guidance on configuration control of Technical Data).
2 Logistics Product Data and Materiel In-Service Data[7] will be significant during this phase, though design Information is still required for design changes and engineering support. The detailed TDRA conducted during the Acquisition Phase will consider Technical Data requirements for the In Service Phase, but the TDRA will need to be reviewed and updated. Each support contract will need consideration of the required Technical Data to address the required services, where it will be sourced (eg other contractors / suppliers) and the associated IP rights.
3 Technical Data captured or generated during the In Service Phase will mainly consist of Configuration Control, Logistics Product Data and Materiel In Service Data information. However, Technical Data from a variety of categories will be required to support system upgrades.
4 Technical Data requirements need to be regularly reviewed and reassessed for any change in mission system role, configuration and environment, change to the ASIS, or any change in support arrangements outside of the agreed ASIS.
6 Disposal Phase
1 In Materiel System Disposal Phase, Technical Data will be needed to support the disposal activities and Technical Data will also need archival or destruction. Any Technical Data generated during this phase will mainly be Configuration Control information with the exception of a re-sale/gifting which will require a wider range of information.
Identification - Technical Data Requirements Analysis
6. Introduction
1. Technical Data is needed to:
a. support the acquisition of a product;
b. operate and sustain the product over its life of type (LOT) under changing operational, technical and business environments;
c. support the materiel assurance process;
d. support future re-competition for item acquisition, upgrades and sustainment activities in the interest of achieving cost savings, which may be identified as part of an overall ASIS; and
e. support the disposal of a product.
2. The TDRA should:
a. identify the nature of activities that will be undertaken for a project or product;
b. identify the Technical Data needed for a project or product throughout its life cycle;
c. Identify the IP rights required by the Commonwealth with respect to contractor supplied or generated TD by reference to the identified purposes / uses of that TD
d. ensure that Technical Data requirements are progressively refined and reviewed prior to each major decision point (eg First Pass, solicitation, Second Pass, system acceptance); and
e. consider TD (and associated IP) from the perspective of total cost of asset ownership including balancing potential long-term cost savings determined by Technical Data use (or ownership) strategies resulting in an ability to compete acquisition and sustainment activities against the immediate costs of acquisition of the Technical Data and associated rights.
3. Technical Data is required during acquisition to define technical goals and assess technical progress, as a basis for Commonwealth feedback on the developing solution / progressive deliveries, to confirm conformance, and ensure the technical integrity of the resulting solution. The Technical Data obtained in acquisition may also be used to provide the baseline for the ongoing support and evolution of the system.
4. In service, Technical Data is one of the fundamental support resources needed for each of the Support System Constituent Capabilities (SSCC)[8], ie Operating Support, Engineering Support, Maintenance Support, Supply Support and Training Support. Often, a deliberate process of Logistics Support Analysis (LSA) will be used to define support system requirements and identify and analyse support tasks and associated data for each SSCC.
5. The TDRA process will:
a. define the system requiring Technical Data;
b. identify activities that require Technical Data;
c. identify the required type and content of Technical Data;
d. identify the users of Technical Data;
e. identify the IP rights required by the Commonwealth in relation to TD; and
f. define the required format for the Technical Data.
7. System Definition
1. A Capability System is the necessary combination of the Fundamental Inputs to Capability (FIC) to achieve the required effect (capability). The Materiel System is a component of the Capability System which is the combination of one or more Mission Systems and the Support System (shown in Figure 6) and it covers those aspects of the FIC that are supplied by the acquisition agency (ie DMO).
[pic]
Figure 6 – Capability System Breakdown
2. The Mission System is that element of the capability that directly performs the operational function. Examples include platforms (eg ship, tank, or aircraft), distributed systems (eg communications network) and discrete systems that integrate into other Mission Systems (eg a radar upgrade for a platform). Major Support System Components (such as Simulators, Automatic Test Equipment and Logistic Information Management Systems) could also be classified as Mission Systems if the level of management attention to be applied to these components warranted this classification6.
3. The Support System is the organisation of hardware, software, materiel, facilities, personnel, processes, and data required to enable the Mission System to be operated effectively and supported so that the Mission System can meet its operational requirements. A Support System also includes the support required for Support System Components. The Support System embraces the support responsibilities undertaken by Defence and in-service support contractors, subcontractors6 or other suppliers.
4. Any system (Mission or Support) can be represented by a structured hierarchy of component products, the Product Breakdown Structure (PBS)[9], as illustrated in Figure 7. A product is any tangible item, which must be produced or delivered (or both) to complete a project or part of a project[10]. A product may be any component or combination of components in the System from any level or levels in the hierarchy[11].
[pic]
Figure 7 – Product Breakdown Structure
5. The absolute lowest level elements of a PBS would consist of raw materials, though in practice the branches end with Off-The-Shelf (OTS) or Developmental Item (DI) components shown as indicated in Figure 7 through colour coding. The system is effectively assembled from these lowest level components. Lowest level components have no further decomposition and can occur at any level in the hierarchy. Components at any level may be Configuration Items (CI)[12] where components at the lower levels could be hardware or software CIs.
6. The PBS is developed progressively from concept through implementation, and can only be completely defined after the conclusion of detailed design. Early versions of the PBS will be used to help scope the system, frame the associated work requirements and form the basis of a contract Work Breakdown Structure (WBS). The Technical Data needed for a system will be established progressively as the PBS and system solution evolve. Therefore, Technical Data requirements analysis is an ongoing activity that evolves with the system design.
8. Technical Data associated with a System
1. The acquisition and support concept for the Materiel System and its components will provide the foundation to identify the associated Technical Data needed by Defence. In lieu of a detailed Support Concept, the ASIS should define the broader support strategy. It identifies the expected activities for each component that will be conducted by Defence, or another organisation on Defence’s behalf. These expected activities will define the requirement for specific Technical Data and identify the organisations that need to use it.
2. All the components in a System’s PBS hierarchy, including those that just represent the integration of lower level components, will have associated Technical Data. Defence needs some of this Technical Data to address the activities Defence expects to conduct, or to provide Technical Data to organisations conducting current or future activities on Defence’s behalf.
3. The application of acquisition and support concepts[13] to each component in the hierarchy, particularly lowest level components, will determine the types and quantity of Technical Data required. Issues to be resolved include what level of maintenance is required for a component and which organisation will perform the specified maintenance.
4. To demonstrate the types or information category of Technical Data that may be required, the following acquisition strategies and support concepts for a subset of the PBS components in Figure 7 can be assumed:
a. Assembly 1.1 is an OTS component acquired from a supplier; installed, tested and accepted by Defence who will also conduct all operational maintenance.
b. Assembly 1.2 is a developmental component as it consists of a combination of a DI and OTS components in Parts 1.2.1, 1.2.2 and 1.2.3.
c. Part 1.2.1 is a DI component which has been developed by a contractor on Defence’s behalf. Defence plans to implement upgrades and re-manufacture them at 5 year intervals through LOT with the original or alternative contractor. This component will be maintained and supported by Defence throughout its LOT. Defence expect to contract elements of this support, including to the original contractor.
d. Parts 1.2.2 and 1.2.3 are OTS components acquired from a supplier; installed and tested by Defence who will also conduct operational maintenance.
5. Only the top level System component and Subsystem 1 components have been considered for brevity as they will be sufficient to demonstrate Technical Data requirements. Based on the example system and product breakdown in Figure 7, Table 3 lists the information categories and examples of typical Technical Data that could be associated with this subset of the PBS.
6. The list of Technical Data examples in Table 3 is not exhaustive but it serves to illustrate the types of Technical Data that may be required for the System PBS in Figure 7.
|Product |Technical Data |
| |Information Category |Examples |
|System |Requirements |Function & Performance Specification, System Specification, Support System Specification |
| |Design |System Architecture Description, Logical and Physical Models of the Solution, System Design Document, |
| | |Trade Study Reports |
| |Verification |Test & Evaluation Master Plan, Acceptance Test Procedure and Results |
| |Configuration Control |Master Record Index, Baseline Configurations |
|Subsystem 1 |Requirements |Subsystem Specification, Requirements Traceability Matrix |
| |Design |Design Documentation, Functional Models |
| |Verification |Acceptance Test Procedure, Report and Result |
| |Configuration Control |Allocated and Product Baseline Configurations |
|Assembly 1.1 |Requirements |Procurement Specification |
| |Design |Product Models, Engineering Drawings (External Interfaces) |
| |Verification |Acceptance and Production Test Procedures and Results |
| |Configuration Control |Product Baseline Configuration |
| |Installation |Software Version Descriptions, Installation Drawings |
| |Logistics Product Data |FMECA Reports, Interactive Electronic Technical Manuals, Maintainer Training Courses |
| |Material In Service Data |Spares Lists, Demand Data from Field Requisitions, Item Prognostics & Diagnostics Information |
|Assembly 1.2 |Requirements |Development Specification |
| |Design |Design/Development Documentation |
| |Verification |Acceptance Test Procedures and Results |
| |Configuration Control |Product Baseline Configuration |
| |Manufacturing |Assembly Drawings, Bill of Materials |
| |Logistics Product Data |FMECA Reports, RCM Reports, Support & Test Equipment Provisioning Lists, Interactive Electronic |
| | |Technical Manuals, Maintainer Training Needs Analysis Reports, Maintainer Training Courses |
| |Material In Service Data |Item Prognostics & Diagnostics Information, Field Quality Deficiency Reports, Field Supply Deficiency |
| | |Reports |
|Part 1.2.1 |Requirements |Development Specification |
| |Design |Design/Development Documentation |
| |Verification |Acceptance and Production Test Procedures and Results |
| |Configuration Control |Product Baseline Configuration |
| |Manufacturing |Assembly Drawings, Software Version Descriptions, Bill of Materials |
| |Logistics Product Data |FMECA Reports, RCM Reports, Support & Test Equipment Provisioning Lists, Interactive Electronic |
| | |Technical Manuals, Maintainer Training Needs Analysis Reports, Maintainer Training Courses |
| |Material In Service Data |Spares Lists, Demand Data from Field Requisitions Item Prognostics & Diagnostics Information, Field |
| | |Quality Deficiency Reports, Field Supply Deficiency Reports, Servicing and Inspection Instructions |
|Parts 1.2.2 & |Requirements |Procurement Specification |
|1.2.3 | | |
| |Design |Product Models, Engineering Drawings (External Interfaces) |
| |Verification |Production Test Results, Certificates of Conformance |
| |Configuration Control |Product Baseline Configuration |
| |Logistics Product Data |Support & Test Equipment Provisioning Lists, Interactive Electronic Technical Manuals, Maintainer |
| | |Training Courses |
| |Material In Service Data |Spares Lists, Demand Data from Field Requisitions, Item Prognostics & Diagnostics Information |
Table 3 – Examples of Technical Data associated with the System PBS
9. Activities requiring Technical Data
1. The ASDEFCON templates are currently being revised to describe the activities for which Defence requires Technical Data for a particular system or product. A standard set of “core activities” will be defined that establish a minimum level of expected activities for any given Defence system or product. These activities, undertaken by Defence (or its contractors), include:
a. Installation & Configuration – installing or configuring the product;
b. Operation – operating the product;
c. Operational Maintenance – conducting operational level maintenance on the product;
d. Technical Integrity – ensuring a product’s fitness for service and managing its safety and environmental impact in accordance with the relevant technical regulatory framework[14] and Australian legislation[15];
e. Integration – interfacing and integrating the product with other platforms or systems (including removal);
f. Verification & Validation – conducting verification and validation for system acceptance, ongoing maintenance and operational test and evaluation activities in respect of the product;
g. Storage & Transportation – placing the product in storage in a non-operational state, transporting the product or transport of component spares and consumables;
h. Disposal (not by Sale or Gift) – disposing of the product by any means except sale or gift to an external customer; and
i. Training – training for any of activities (a) to (g) inclusive.
2. The Technical Data needed to support the core activities includes the data necessary to ensure efficient, effective and economical use of Defence resources over LOT. This will allow Defence to understand the relationship between the technical elements of the materiel solution and whole of life costs and enable appropriate trade-offs and analysis.
3. The requirement for Technical Data to support the core activities is intended to apply to all systems and products acquired by Defence as a minimum expectation. For a given system or product, Defence or an organisation acting on Defence’s behalf may perform “additional activities” in excess of this minimum level, such as developing a system or (in rare cases) manufacturing a product by a third party. Additional activities may include:
a. Modification – modifying an existing product;
b. Development – developing a new product;
c. Manufacturing – manufacturing a new or existing product;
d. Non-Operational Maintenance – conducting intermediate or deeper level maintenance on the product;
e. Emergency Repair – conducting emergency repair or overhaul on the product;
f. Disposal by Sale or Gift– disposing of the product by selling or donating it to an external customer; and
g. Other – any activity that was not anticipated or covered by the preceding Additional Activities or Core Activities.
4. As an example, Figure 8 illustrates a numbered list of Technical Data Items required to support different Core Activities and Additional Activities. Note that Technical Data items can be required for both Core and Additional Activities.
[pic]
Figure 8 – Technical Data Items assigned as required for different Activities
5. The Technical Data requirements for a component in the hierarchy will be driven primarily by the operational and support concepts for the system and the expectations for the future evolution of the system. Expected activities and their associated Technical Data requirements need to be determined for components at the appropriate level of the PBS hierarchy (see Figure 9). These definitions should be captured in Section 5.6 of the Operational Concept Document and also in the Function and Performance Specification for Support System requirements.
[pic]
Figure 9 – Technical Data Requirements depend on Acquisition Needs, Support Concepts and Business Needs
10. Technical Data associated with Support
1. Technical Data is a pivotal component of the Support System, critical for the safe and effective operation of the overall capability and to ensure the Support System optimises the Mission Systems availability. Figure 10 illustrates that each of the Support System constituent capabilities includes Technical Data as a key contributor to resources. Typical examples of Technical Data associated with Support are shown in Table 4.
[pic]
Figure 10 – Support System Constituent Capabilities and Resources
|Constituent Capability |Technical Data |
| |Example |Expected Activities |
|Operating Support |Operator Manuals |Operation |
| |Handbooks | |
| |Simulations | |
| |Standards | |
|Engineering Support |Specifications |Installation & Configuration |
| |Engineering Drawings |Verification & Validation |
| |Models |Technical Integrity |
| |Plans |Integration |
| |Databases | |
| |Design Data | |
| |Test Results | |
| |CM Records | |
| |Analyses | |
| | |Modification |
| | |Development |
| | |Manufacturing |
|Maintenance Support |Maintenance Manuals |Installation & Configuration |
| |Handbooks |Operational Maintenance |
| |Records |Disposal (not by Sale or Gift) |
| |Reports | |
| |Calibration Reports | |
| | |Non-Operational Maintenance |
| | |Emergency Repair |
|Supply Support |Databases |Installation & Configuration |
| |Reports |Operational Maintenance |
| |Drawings |Disposal (not by Sale or Gift) |
| |Handbooks | |
| |Plans | |
| |Calibration Reports | |
| | |Non-Operational Maintenance |
| | |Emergency Repair |
| | |Disposal by Sale or Gift |
|Training Support |Training Materials |Training |
| |Presentations | |
| |Handbooks | |
| |Models | |
| |Simulations | |
Table 4 – Examples of Technical Data associated with Support System Constituent Capabilities
2. Once the system is in-service, one or more organisations will provide each Support System Constituent Capability (of Figure 10) as a support service. The activities needed to address the Support System constituent capabilities are normally provided through one or more support service contracts. Each service is provided for the identified system components (ie one or more elements of the product hierarchy in Figure 7), by an appropriate organisation, using the relevant Technical Data. These organisations may include the operational unit, DMO, original contractor, other support contractors or subcontractors and third parties, each one requiring access to relevant Technical Data.
3. The relationship and interaction between support services and organisations supporting the components of the example system is illustrated in Figure 11[16]. The type of organisation providing the various support services for each component is identified by colour. Figure 11 indicates that each organisation can provide a varying scope of the different support services for each component in the system. Some issues that require resolution are:
a. identification of support service being provided by each organisation;
b. definition of scope of support being provided by an organisation;
c. interaction between organisations; and
d. required exchange of Technical Data to support these arrangements.
[pic]
Figure 11 – Support Services and Organisations for some System Components
4. Technical Data obtained under an acquisition contract will generally be provided to the support contractor(s) as Government Furnished Data (GFD) or Government Furnished Information (GFI), unless the support contractor was also the Original Equipment Manufacturer (OEM) (eg for off-the-shelf items, it is often the “norm” for the OEM to provide the required support - in such a case, and where there is no other need for Defence to hold the Technical Data, the required Technical Data may primarily relate to product installation, configuration and operation).
5. Each support contractor will generally provide new Technical Data as part of the services under the Support Contract, which DMO may also need to redistribute for use by other parties. Technical Data may also come from other sources (eg interface data from other projects, Technical Data from Foreign Military Sales (FMS), etc). Figure 12 illustrates the exchange and flow of Technical Data between the various contractors or organisations.
6. Each organisation identified in Figure 11 or Figure 12 will need to use relevant Technical Data to provide the support service defined for the system components. The Commonwealth also has to establish the arrangements that acquire the necessary Technical Data and/or allow the expected exchange of this Technical Data between each of the organisations
[pic]
Figure 12 – Exchange and Flow of Technical Data Across a Product Lifecycle
11. Technical Data Formats
1. Technical Data may exist in a wide range of formats, some of which may be specified in content and delivery standards. Technical Data may be provided as hard copy documents and publications, or as electronic data that may also be interactive. Currently, there is a trend towards using electronic data referred to as electronic Technical Data (ETD) and interactive electronic Technical Data (IETD).
2. Notwithstanding the mode of delivery, the Technical Data’s content format will often be subject to or defined by a published specification or standard. Many of these specifications and standards address the format of Technical Data, eg standards for Engineering Drawings and Technical Publications.
3. The content and format of Technical Data will be specified in the contract mostly through Data Item Descriptions (DID).
4. DMO policy[17] requires Technical Data to be in approved electronic formats employing integrated, open system standards. Where possible this should consider the need to include the source data format to allow editing of content (eg drawing tool files, as well as a pdf). Where Defence has a preferred or mandated standard for a type of Technical Data, these are identified in Annex A. Technical Data produced internally by Defence also needs to conform to similar standards.
5. Where possible, Technical Data should be acquired or captured in approved digital formats in support of clearly defined, documented and cost effective business objectives. In determining the format to be adopted, factors associated with accessibility, cost, compatibility, suitability, degree of configuration control and any special requirements must be considered. Generally, the higher the degree of configuration control exercised over materiel, the greater the need for a highly automated and integrated digital data management system.
6. In some cases, Technical Data may only be available in hard copy, particularly for COTS systems. However, while Technical Data may be offered in hard copy in these cases, Defence should make all reasonable efforts to gain access or convert the data to an electronic format.
Acquisition and Creation of Technical Data
12. Rights to Technical Data
1. The ASDEFCON templates contain provisions relating to the Technical Data to be provided and the rights to be granted to the Commonwealth to use, reproduce and disclose the Technical Data. It is critical for Defence personnel to understand the contractual framework as it relates to Technical Data when considering Technical Data requirements as part of the TDRA. Defence personnel should refer to the applicable policy and ASDEFCON guidance material when undertaking a TDRA and Technical Data management activities.
13. Objectives
1. Where Technical Data is acquired, Defence should:
a. define explicitly, through the contract Statement of Work (SOW), the tasks required by contractors that generate or provide the required Technical Data according to specified content, format and quality; and
b. use current, approved DIDs and a standardised Contract Data Requirements List (CDRL) approach in each contract to manage the delivery of the required Technical Data.
2. Where Technical Data is created by Defence or on Defence’s behalf, it should:
a. contain all content required to understand, evaluate, operate and support the system throughout its life cycle while optimising total cost of ownership; and
b. be generated according to current approved electronic formats and quality consistent with the requirements of the overall contract.
14. ASDEFCON and Technical Data
1. The TDRA will be a critical step in the development of the solicitation and contract documentation using the ASDEFCON templates. The TDRA will assist drafters to determine the Technical Data requirements to be reflected in the documentation, including in relation to the CDRL items and ensure that Defence acquires adequate IP rights to use (including disclose) that TD for the identified activities. The process of TDRA will provide a means for tailoring the CDRL and other contractual requirements to avoid requiring the provision of Technical Data (and associated rights) which is unnecessary, (or acquiring TD for , say, a particular activity, but without the corresponding IP rights to use the TD for those activities).
2. Technical Data to be delivered under the contract should be identified and specified within a contract at the “data product” level, eg two-dimensional drawings, three-dimensional Computer-Aided Design (CAD) models, or technical manuals. Figure 1 provides a representation of different types of product related data that may be needed.
3. As one of the outputs of the contractor's Logistics Support Analysis (LSA) program, the contractor is required to:
a. analyse the types and quantities of Technical Data needed for each of the SSCC and define the optimal range and quantity of Technical Data required to meet the Support System Functional Baseline; and
b. identify this in the Technical Data List (TDL).
4. The CDRL will identify certain Technical Data to be delivered, including:
a. engineering drawings;
b. key requirements documents such as the System Specification (SS) and Requirements Traceability Matrix (RTM);
c. design descriptions such as the Support System Description (SSDESC);
d. a set of design documentation delivered in accordance with the contractor’s Technical Documentation Tree (TDT);
e. publications delivered in accordance with a Publications Tree, including as appropriate Interactive Electronic Technical Manuals (IETMs) and Interactive Electronic Publications (IETPs);
f. codification data;
g. Verification Cross Reference Matrix (VCRM);
h. Acceptance Plan, Procedures and Reports;
i. Technical Data Plan (TDP);
j. the Technical Data List (TDL); and
k. the (optional) Data Accession List (DAL).
5. The contractor is required to ensure that the TDL is a complete list of the optimised types and quantities of Technical Data, including the Technical Data that the Contractor will be providing to the Commonwealth, as well as the Technical Data that will be provided to, or used by, support contractors and subcontractors. The TDL includes references to other elements as listed above as necessary. It is expected that the TDL will be delivered and updated throughout the contract period, with an initial baseline provided at contract signature and subsequent updates delivered at major design milestones (eg Detailed Design Review, when the design is mature) and prior to final acceptance.
6. The contractor is also required to produce a Technical Data Plan (TDP) that describes the contractor’s strategy, plans, methodology, and processes for the identification, assembly, preparation, validation and delivery of Technical Data. The plan must describe a process consistent with meeting the requirements for Technical Data and the various issues related to data access, incorporating existing data, IP and escrow. The Integrated Support Plan (ISP) and Support System Description also provide detail on the management of Technical Data.
7. As part of the verification and validation of the support system, the contractor has to demonstrate the effectiveness of the Technical Data for each of the Support System Constituent Capabilities. Technical Data is also considered at key System Reviews (eg preliminary design review, support system detailed design review, system acceptance audit).
Verification, ValidatION and Acceptance of Technical Data
15. Purpose of Verification and Review / Acceptance
1. Technical Data verification and acceptance should:
a. ensure verification of content, format and quality of required Technical Data received from contractor(s) / supplier(s);
b. inspect Technical Data provided contractually to ensure markings are in accordance with the relevant agreements and contain appropriate distribution statements and/or export control statements;
c. validate the Technical Data as suitable for its intended purpose; and
d. take appropriate action to acknowledge the suitability or otherwise of the Technical Data.
16. Data Quality Verification
1. Verification of Technical Data needs to confirm that it meets its defined requirements. Normally, contractor provided Technical Data needs to be verified against the specific requirements defined in the ASDEFCON CDRL and associated DIDs. In particular, for technical publications, DEF(AUST) 5629B[18], verification is the testing process employed by the Commonwealth, to confirm the accuracy, adequacy, and suitability of use of a technical publication in an operational environment.
2. Verification of Technical Data should determine whether it is relevant, accurate, current and correct for the associated product and expected activity. These attributes will be determined by the content of the Technical Data; therefore, it should be assessed or evaluated by personnel with the appropriate qualifications, competence and authority.
3. The technical integrity of supporting Technical Data must be maintained to provide confidence in the technical integrity of the product with which it is associated.
4. Responsibility for authorising or approving Technical Data must be assigned to appropriately qualified personnel and authorised organisations. Within an Accredited Engineering Organisation, the Configuration Control Board Chair, on advice from the Design Acceptance Authority or representative, must authorise Technical Data. Technical Data may also be produced and authorised to support local design and maintenance activities.
5. In addition to verifying that Technical Data is supplied with the required content, it should also be delivered in the appropriate format. In accordance with Defence and DMO policy, Technical Data should be delivered approved electronic formats[19] unless there is a specific business case need for an alternative. Guidance on formats preferred by Defence is provided in Annex A.
17. Data Marking Inspection
1. All Technical Data deliverables should be inspected to ensure each Technical Data item contains markings to accurately indicate the following, as a minimum:
a. item identification;
b. security classification;
c. FMS or International Trade in Arms Regulations (ITAR) classification
d. rights relating to the Technical Data, including Intellectual Property ownership and authorised use; and
e. any other access restrictions.
2. Electronic data files should have the markings embedded in the digital data itself and on any media or media packaging on which the files are stored.
18. Metadata Standard
1. The National Archives of Australia mandates the method of using metadata (data about data) elements via the Australian Government Locator Service (AGLS) Metadata set to describe document entities. The AGLS Metadata set consists of nineteen elements of which six mandatory elements are to be present. These mandatory elements[20] are:
a. creator (author),
b. publisher,
c. title,
d. date,
e. subject or function, and
f. identifier or availability.
19. Validation of Technical Data
1. Validation of Technical Data is confirmation that the information content is suitable for its intended purpose. For example, validation activities may include:
a. confirmation that a software configuration item can be generated from the associated Technical Data (ie source code and build instructions); or
b. confirmation that a maintenance task can be completed using the Technical Data provided.
2. Validation of Technical Data may also form part of a broader supportability test and evaluation activities[21].
20. Technical Information Review
1. DMO may receive large quantities of Technical Data related to materiel systems acquired through contract. This Technical Data will consist of information which will vary in significance from slightly applicable to critical such as that directly affecting safety.
2. All Technical Data must be carefully managed to ensure that all data received are sorted quickly and prioritised so that the necessary action may be taken in a timely manner. DMO needs a process of Technical Information Review (TIR) to collect and register Technical Data as well as to decide on whether it will be accepted.
3. A Judgement of Significance (JOS) must be completed and documented for the inclusion of each item of critical Technical Data in accordance with the technical regulations of the respective service or user organisation. A JOS is an identification of the risk to technical integrity introduced by the introduction of a new or change to an existing item of Technical Data and assesses the consequence of an error in the data.[22]
21. Contractual Endorsement/Review
1. Typically, Technical Data will have been acquired under a contract that was written using an ASDEFCON contract template. Technical Data deliverables should be reviewed against the contractual requirements to verify that the requested items have been supplied. Where a DID has been specified for a Technical Data deliverable then the supplied item’s conformance to that DID should be verified.
2. Technical Data requires differing levels of endorsement depending on its significance. These are, in order of most to least significant, CCP approval, Accept, Approve or Review[23]. The processes associated with these differing levels of endorsement are specified in the ASDEFCON SOW.
3. Technical Data items that define user requirements (eg system specifications) or form part of the operational system (eg operational manuals) should generally be Accepted by Defence, subject to satisfying the above requirements concerning its quality, validity and compliance with any other appropriate standards.
4. Technical Data items that provide visibility of activities (eg engineering support databases) or provide early feedback on the design (eg design documents) should generally be supplied to Defence as "Approve" or "Review" items.
5. For additional information on detailed contracting issues, refer to the the ASDEFCON contract guidance material.
Storage, Maintenance and Control of Technical Data
22. Purpose
1. Technical Data storage, maintenance and control should:
a. allocate and manage the resources (eg personnel, funds) for the maintenance and upkeep of a product’s data / configuration management system over its LOT;
b. use, to the greatest extent possible, existing Defence / DMO integrated infrastructure;
c. ensure all changes to Technical Data are made in a timely manner and documented accordingly in the integrated data environment infrastructure; and
d. implement a Configuration Management (CM) process and system for the control of Technical Data.
23. Storage Systems
1. The Information Technology (IT) environment that will be used to store and manage the data is a key consideration in the approach to managing Technical Data and needs to be aligned to the ASIS and support concepts. The choices are:
a. Commonwealth repositories – a combination of unit or organisation specific repositories usually provided via the acquisition agency’s Technical Data Management strategy.
b. Contractor repository – provided by either the OEM or a third-party contractor via an existing contract vehicle and a commensurate level of funding provided by the acquisition agency for the storage, maintenance and providing the Commonwealth access to the data.
2. Program-unique repositories are discouraged as long-term product data IT environments due to the high cost to Defence if multiple programs establish and fund separate IT environments.[24] Program unique repository approaches may also inhibit data access, sharing and reuse across the appropriate organisations.
3. Technical Data should be stored and identified such that authorised users can readily search for, locate and access the data when needed. To assure data is well identified and retrievable, appropriate identification, such as metadata, should be used. The identifying metadata may include date, author, title, general topic key words, document identifier, version identifier, retention date, and data owner information. Identifying metadata can be used in the data repository index schemes to identify the data type and where the data is located.
24. Access Controls and Maintenance
1. Access for Defence users throughout the life cycle is another key consideration. This includes methods to be used to inform the organisations that will be involved in the various life cycle support activities as to what product data exists, where the authoritative copies are stored and maintained and who is entitled to access the Technical Data.
2. All Technical Data should be disseminated to appropriate individuals or organisations with the appropriate distribution statement, export control warning notice (where applicable), disposal notice (where applicable), or any other relevant notices, whether produced in hard copy or digital format.
3. Budgeting for maintenance and upkeep of the product data throughout the life cycle is also an important consideration. Such maintenance activities include:
a. incorporation of configuration changes (to include changes due to obsolete parts or materials); and/or
b. technology or format refresh.
4. Since the Commonwealth will often need its Technical Data for several decades to match a system LOT, it is important that Technical Data be kept in a format and data system that is readily usable. Decisions in these areas are driven by mission requirements; anticipated product life cycle, acquisition and logistics support strategies, sources of supply, and cost. Issues to be considered and addressed with long term retention include:
a. Data authoring applications. To ensure Technical Data is readable for later use or manipulation, Defence may need to also store and retain data authoring or viewing application software to view, revise and print images or refresh data. Over time, data may need to be periodically migrated to current software applications and hardware formats for continued accuracy and availability.
b. Storage media. Storage media should not be an issue except where information is not stored on the Defence Single Information Environment (SIE) (ie CIOG). When data is not stored on the SIE, procedures to protect data on any storage media from loss or inadvertent destruction should be established and applied.
c. Applications and Data systems. In some cases, hardware systems also need to be kept past the normal active life cycle in order to access data. Current examples include microfiche viewers or tape drives that are not technologically current but provide the only method to read or access certain data due to the original storage media.
25. Configuration Management
1. Maintaining integrity of the “master” Technical Data item is essential. This can be achieved by using a system of access control so that only authorised personnel can obtain access to the relevant level of Technical Data which includes embedding notices by way of metadata tags or other means that identifies the custodian of the master copy.
2. Changes to the data should be coordinated with the data owner or be identified as changed from the original data.
3. Configuration Management (CM) should be applied to a significant portion of, but not necessarily all, Technical Data. For example, with reference to Figure 1, non-product Technical Data and maintenance management system data may not be under formal change control, though should still be managed as Commonwealth records.
4. Changes to Technical Data under CM should be authorised through an approved change control process. The application of CM principles to the acquisition and management of Technical Data enhances the technical integrity of that data throughout the product’s life cycle.
5. All Technical Data under configuration control should have:
a. application of unique identifiers for data and documents;
b. effective file and data base management;
c. maintenance of essential file, version and revision relationships;
d. controlling status of and access to digital data; and
e. a defined relationship to one or more specific product definition(s) and/or specific product instance(s).
26. Unique Identification.
1. An identification scheme should be at a level at which Technical Data will actually be under control, for example, computer file database elements, illustrations and electronic media. Documents should be assigned unique identifiers so that they can be:
a. correctly associated with the item it supports such that change in the configuration item will change the supporting documentation,
b. referred to precisely, and
c. retrieved when necessary.
2. With the emphasis on the acquisition of commercial products and the use of industry methods, it is inappropriate for Defence to specify one format for document identifiers. Generally document identifiers include all or most of the following parameters:
a. date,
b. assigned numeric or alpha numeric identifier unique to the document,
c. version indicator,
d. revision indicator,
e. type of document,
f. title or subject, and
g. sponsor.
27. File and Database Management.
1. Digital data files are to be identified to differentiate between similar files and to maintain traceability to specific equipment configurations and document representations. As file naming conventions vary widely among operating systems and application programs, it is necessary to store information about the files (metadata) providing correct relationships and associations for the supporting document management system.
2. Each product should have its own record of the indexes and metadata of the associated Technical Data subject to the CM process. These records describe the elements of the technical data package and serve a similar function to cataloguing information in libraries. They must allow for efficient electronic searches; provide filtering / reports such as the set of Technical Data defining the approved configuration of a product; as well as track proposed and approved changes and deviations. It is usual to create a master document index to assist in document version control and referencing.
28. Maintenance of Essential File and Version Relationships.
1. To facilitate the proper relationships, the following digital data identification rules should be applied:
a. a unique identifier should be assigned to each file;
b. a unique identifier should be assigned to each document entity;
c. a version identifier should be assigned to each file;
d. a database of the following relationships should be maintained:
1) document identifier and its revision level,
2) associated document representations, and
3) file identifiers and versions;
e. as necessary, multiple versions of files to recreate prior document revisions and provide traceable history of each document should be maintained.
Use, Distribution and Exchange of Technical Data
29. General
1. Technical Data usage and exchange should plan for and establish methods for access and reuse of Technical Data by all personnel and organisations that perform life cycle support activities. Before disseminating TD (particularly to external organisations) the Commonwealth's rights to use and distribute Technical Data (from both an IP and Export Control[25] perspective) need to be considered.
30. Enterprise-wide Access and Use
1. Some of the Technical Data acquired for a new acquisition program will reside in one or more Commonwealth repositories and some will exist with various industry partners. Users of Technical Data are frequently unaware that the data exists and subsequently expend valuable time and resources trying to recollect existing data. Further, users may know that the Technical Data exists, but are often unable to access it due to security, technical, or organisational boundaries. Finally when users can access the required Technical Data they may find it unusable due to lack of understanding of what the data means or the structure of the data.
2. Life cycle access and use of Technical Data involves leveraging existing data by:
a. locating the required Technical Data wherever it resides;
b. obtaining the ability to access Technical Data where it resides both technologically and legally;
c. using metadata tags and data mining techniques to understand the data and to combine or integrate different Technical Data sets from different repositories into new data sets to fulfil new needs; and
d. maintaining configuration control of the master copy of all accessed or shared data.
31. Data Management System
1 Facilitating Data Exchange
1 Once the Commonwealth has determined its Technical Data requirements, a decision should be made regarding how best to obtain access to it.
2 If an agreement is reached with a contractor to access Technical Data resident on the contractor’s IT systems, then the project/contract manager should encourage and work with the contractor to implement a Data Management System (DMS).
3 The objectives of implementing a DMS should be:
a. reduced paperwork through electronic exchange of data and the use of a virtual work environment;
b. reduced delivery times for data and shorter cycle times for processing the data; and
c. reduced risk through enhanced access to data.
4 The reliability, responsiveness and ease-of-use of the DMS and the timeliness for uploading data onto the DMS are critical to the operational effectiveness of a Commonwealth project office.
2 DMS General Requirements
1 A DMS[26] should provide on line access to:
a. all Technical Data identified in an acquisition contract’s CDRL line items for delivery, including:
1) Technical Data List, and
2) Technical Documentation Tree;
b. all Technical Data generated during or required for the In Service and Disposal phases of a product’s life.
2 The following Commonwealth Authorised Users should be able to access the DMS:
a. Defence operational and maintenance personnel;
b. Commonwealth acquisition and support contracting agency personnel; and
c. contract or sub-contract personnel acting on Defence’s behalf.
3 A DMS should be implemented so that it:
a. provides a controlled repository for all DMS Technical Data;
b. caters for both classified and unclassified data;
c. provides on-line access to the DMS Technical Data in a timely manner for all Commonwealth Authorised Users;
d. enables all Commonwealth Authorised Users to access both the DMS and the DMS Technical Data at the same time;
e. provides access controls to limit access to DMS Technical Data that may be sensitive between certain parties (eg, subcontractor access to prime contractor proprietary data);
f. provides controls to prevent the Commonwealth Authorised Users from replacing or overwriting the configuration controlled versions of DMS Technical Data inadvertently;
g. where reasonably practicable, allows the DMS Technical Data to be downloaded by a Commonwealth Authorised User for further manipulation (including printing) in the native document format;
h. provides access to both current and historical DMS Technical Data, including earlier versions of documents and any pertinent comments provided on each of the versions;
i. provides an index of DMS Technical Data, which is rebuilt at least weekly, with the index to provide the CDRL Line Number or other reference number (as applicable), title, issue, file name (as applicable), status (eg, working, draft submission, final submission, Approved, and Accepted), date of most recent change, and location on the DMS;
j. provides access to DMS Technical Data that may not yet be in the index, but is known to the requesting party;
k. provides the ability for the Commonwealth Authorised Users to search the DMS Technical Data;
l. if DMS Technical Data is required to be delivered to the Commonwealth, provides the Commonwealth Authorised Users with the ability to electronically:
1) acknowledge delivery of the data, and
2) comment on the data;
m. provides the ability to capture, store, provide access to, and maintain an audit trail of comments provided by the Commonwealth Authorised Users on DMS Technical Data; and
n. allows the designated authority to administer access rights for the Commonwealth Authorised Users in accordance with agreed prior contractual access rights.
3 DMS Implementation and Management
1 The Commonwealth should determine and specify the computing hardware and software required to access the DMS so that it can be provided by the contractor with the exception of:
a. any computing hardware for the Commonwealth Authorised Users to access the DMS, except as otherwise defined in the Contract; or
b. any cryptographic equipment (eg, to enable the electronic exchange of classified data).
2 If the electronic data formats of the DMS Technical Data differ from those formats specified in the acquisition and support contracts, all additional software programs and all necessary licences to enable the Commonwealth Authorised Users to access and manipulate the DMS Technical Data should be obtained.
3 Once the DMS has been introduced into operation, there should be measures in place to ensure that the DMS remains fully operational for the duration of the product LOT.
4 Any time-related Commonwealth access restrictions for the DMS should be detailed; for example any limitation to 24x7 access or specific times for DMS system maintenance.
5 DMS Technical Data should be protected against unauthorised access.
6 System security[27] aspects of the DMS should be detailed, including:
a. controlled system access;
b. system administration functions to control data access;
c. file transfer protocols used;
d. security classification of material that will be able to be released on the DMS;
e. procedures for the handling, management, transfer, release, etc of classified material (if required); and
f. procedures for periodic back-up of electronic data, including a list of the data files that should be backed up, how the backup is performed and how such files are restarted.
7 Any DMS administration functions that Commonwealth Authorised Users may be require to perform should be detailed including a description of routine administration that must be carried out and the actions required to perform such administration.
8 Procedures for formal and informal communications should be detailed which may include the following:
a. notification of actions between authorised users;
b. access and navigation of the DMS;
c. downloading, uploading and viewing DMS Technical Data; and
d. how comments are to be provided for document type (eg native file formats etc).
9 The promotion of data in the DMS from one status to the next (eg working, draft submission, final submission, Approved and Accepted) should be detailed; and
10 A point-of-contact should be provided for assisting Commonwealth Authorised Users with problem resolution and to answer questions concerning the DMS.
11 DMS users will need training for effective use of the DMS. A training plan should be detailed for the DMS which may include:
a. proposed venue(s);
b. proposed instructors;
c. participants;
d. training schedules; and
e. provision of training materials.
Archival and Disposal of Technical Data
32. Overview
1. Disposal of Technical Data during the Capability System Life Cycle concerns the removal of systems or products from the Defence inventory and the phasing out of mission and support system equipment and components from the capability system during the In Service phase.
2. Whilst inventory may cease to be used and business process tasks completed, the associated Technical Data will need to be accessible well past the actual point of disposal to support later investigations (eg safety incidents) and to meet the retention requirements of the Archives Act 1983.
3. All data captured under the CM process (termed Configuration or Technical Data) must comply with the Archives Act 1983, Section 3 Interpretation (3), referring specifically to ADF records, and Interpretation (7), referring to the duration of the "open access period" for the records to be available. In particular, in accordance with this act, all Configuration Data is to be maintained for “life of type” plus 30 years.
4. Configuration Data is also subject to the following acts in varying degrees.
a. Electronic Transactions Act 1999;
b. Evidence Act 1995;
c. Freedom of Information Act 1982;
d. Privacy Act 1988; and
e. Financial Management and Accountability (FMA) Act 1997.
5. The disposal of Technical Data is therefore a continuous process that extends beyond the life cycle of a capability system or specific equipment.
6. Technical Data will be withdrawn from service at the end of materiel service life. Disposal of Technical Data is conducted in accordance with Archives Act 1983 and POLMAN 3. There may be IP rights issues that need to be considered as part of disposal, including licensing and export approval – further guidance can be found in the Defence Procurement Policy Manual (DPPM).
33. Legal Archival, Destruction or Disposal
1. Technical Data may be identified for disposal where ownership is to be transferred to another operator (including museums). In this case, all requisite configuration documentation and Configuration Status Accounting (CSA) records (including publications and manuals) must be identified and collated.
2. Technical Data records are subject to a systematic program of declassification and transfer of records to Australian Archives under Defence Archives Policy Manual (POLMAN 3) (refer to DI(G) ADMIN 27-2). A document change authority is responsible for the archiving of documents under their control and other obligations with regard to the treatment, preservation and disposal of records.
34. National Archives Act and POLMAN 3
1. POLMAN 3, Defence Records Management Policy Manual provides policy and guidance on retention, destruction and transfer of Defence records which also includes Technical Data controlled by Defence and addresses:
a. Disposing of records by keeping, destroying or transferring records out of Defence or Commonwealth custody or ownership is regulated by section 24 of the Archives Act 1983.
b. Records disposal by sentencing is the process of using authorised disposal authorities and normal administrative practice to retain, destroy or transfer a record.
c. The National Archives of Australia (NAA) may place a freeze or Defence may place an embargo on the destruction or unauthorised alteration of records for a particular reason.
d. Transfer of records is the process of internal and external change of custody of the records. This can include the transferring of records to:
1) A new location within Defence such as a business unit or repository, and
2) the NAA or the Australian War Memorial (AWM).
2. DMO personnel must be cognisant of and refer to the requirements of the Archives Act 1983 for further guidance, in particular the sections detailed below:
a. Section 24 - Disposal, destruction etc. of Commonwealth Records, subsection (1);
b. Section 27 – Transfer of Commonwealth records to Archives;
c. Section 28 – Archives to have access to records; and
d. Section 33 – Exempt records.
3. Other areas that need to be considered include:
a. destruction procedures and security arrangements for classified materiel (refer to Defence Security Manual), and
b. maintenance of records of destruction and disposal.
4. For further detailed guidance on Technical Data disposal, DMO personnel should consult POLMAN 3.
Annex A: Technical Data Format
Author’s Note: This annex has been included for future use and is being used as a placeholder for information that will be captured at a later date.
Technical Data format can be specified against the different information categories of Technical Data that were illustrated in Figure 1 and listed in Table 5 overleaf.
DEFLOGMAN Part 2, Volume 10, Chapter 5, Annex A contains the current list of Defence Approved Standards and Specifications for Technical Data.
|Information Categories |Examples |
|Technical |Design Information | |
|Product | | |
|Definition| | |
|Informatio| | |
|n | | |
| |Other Design Information |Functional Breakdown Descriptions |
| | |Trade Study Reports (Trade-Offs) |
| | |Design Selection Document |
| | |Engineering Analyses |
| | |Simulation Models and Test Cases |
| |Product Design |Technical Data Package (TDP) |
| | |Engineering Drawings/Models |
| | |Inspection Lists |
| | |Test Equipment Lists |
| | |Software Documentation |
| | |Interface Control Documents |
| | |Engineering Product Structure |
| | |Design Documentation |
| |Requirements Information |Operational Concept Document |
| | |Capabilities Development Document |
| | |Capabilities Production Document |
| | |System Specifications |
| | |Interface Specifications |
| |Manufacturing Information |Manufacturing Instructions |
| | |Manufacturing Process Routings |
| | |Depot Maintenance Work Requirements (DMWR) for Rebuilds |
| | |National Maintenance Work Requirements (NMWR) |
| | |Bill of Materials |
| | |Parts List |
|Technical |Verification Information |Verification/Validation Planning |
|Associated| | |
|Informatio| | |
|n | | |
| | |Verification/Validation Procedures |
| | |Verification/Validation Result Reports |
| | |Physical Configuration Audits |
| | |Functional Configuration Audits |
| |Configuration Control |Requests for Changes |
| |Information | |
| | |Requests for Variance |
| | |CCB Decisions |
| | |Product Configuration Management Status Account Information |
| | |Engineering Change Proposals |
| |Other Associated |GIDEP Notices of Obsolete Parts |
| |Information | |
| | |Supplier Notices of Obsolete Parts |
| | |Disposal Information |
|Technical |Logistics Product Data |Maintenance Planning Information |
|Product | | |
|Operationa| | |
|l | | |
|Informatio| | |
|n | | |
| | |Technical Publications |
| | |Support & Test Equipment Information |
| | |Manpower, Personnel & Training Information |
| | |Packaging, Handling, Storage & Transportation Information |
| | |Environmental and Work Health and Safety Information |
| |Material In Service Data |Field Feedback Information |
| | |Demand Data from Field Requisitions |
| | |Item Prognostics & Diagnostics Information |
| | |Field Quality Deficiency Reports |
| | |Field Supply Deficiency Reports |
| | |Product Unit Configuration Information |
Table 5 – Product Technical Data Information Categories
Annex B: Referenced Documents
ABR 6492 Navy Technical Regulations Manual
Archives Act 1983
AS/NZS ISO 9000:2000 Quality management and quality assurance standards
ASDEFCON(Complex) Australian Standard for Defence Contracting (Complex Materiel) Template
ASDEFCON(SM) Australian Standard for Defence Contracting (Strategic Materiel) Template
ASDEFCON(Support) Australian Standard for Defence Contracting (Support) Template
DCDH Defence Capability Development Handbook 2012
DEF(AUST) 5629B Production of Military Technical Manuals
DEF(AUST) 5664A Work Breakdown Structures for Defence Materiel Projects
Defence Logistics Manual Part 2, Volume 5, Chapter 10 Disposal of Defence Assets
Defence Logistics Manual Part 2, Volume 5, Chapter 19, Procurement of Materiel and Services from the United States of America under the Foreign Military Sales Program
DEFLOGMAN Defence Logistics Manual Part 2, Volume 10, Chapter 5 Acquisition and Management of Technical Data
Designs Act 2003
DI(G) ADMIN 27-2 Access to Defence and Defence-related archival records under the Archives Act 1983
DI(G) LOG 4-4-004 The export and import of Defence and dual-use goods and the use of Government end-user assurances
DI(G) LOG 4–5–005 Defence Policy on Integrated Logistic Support
DI(G) LOG 4–5–012 Regulation of technical integrity of ADF Materiel
DMH(A&S) 14-3-001 to Supporting Documents for the Acquisition and Sustainment Implementation
14-3-006 inclusive Strategy (ASIS)
DMH(ENG) 12-3-003 CDD Guide
DMH(ENG) 12-3-005 Functional and Performance Specification (FPS) Development Guide
DMH(ENG) 12-5-001 Defence Materiel Verification and Validation Guide
DMH(IND) 05-0-001 United States’ Defence Export Controls Guidance
DMI(A&S) 14-3-001 Development and Management of the Acquisition and Support Implementation Strategy (ASIS)
DMI(ENG) 12-2-003 Acquisition and Management of Technical Data
DPPM Defence Procurement Policy Manual
DSM Defence Security Manual
EIA-632 Processes for Engineering a System, American National Standards Institute / Electronic Industries Association
EIA-649B National Consensus Standard for Configuration Management
Electronic Transactions Act 1999
Environment Protection and Biodiversity Conservation Act 1999
eTAMM electronic Technical Airworthiness Management Manual
Evidence Act 1995
Financial Management and Accountability (FMA) Act 1997
Freedom of Information Act 1982
IPMAN Defence Intellectual Property Manual
MIL-STD-31000A Technical Data Packages
MIL-STD-974 Contractor Integrated Technical Information Service
Patents Act 1990
PMBOK Guide 2000 Project Management Book of Knowledge – 2000 Edition
POLMAN 3 Defence Records Management Policy Manual
Privacy Act 1988
Trade Marks Act 1985
TRAMM-L Technical Regulation of ADF Materiel Manual – Land
Work Health and Safety Act 2011
Annex C: Definitions and Abbreviations
The following definitions are used in this document:
|Configuration Item |An aggregation of hardware, software, firmware or any discrete portion thereof that satisfies an end use |
| |function, and is designated for separate configuration management (ie, it has specified requirements, and is |
| |an item to which the effectivity of changes is addressed) [EIA-649-B] |
|Integration |The bringing together of components and ensuring that they function together. Components can be any |
| |combination of subsystems, systems, projects or FIC elements. [DCDH] |
|Intellectual Property |Rights relating to: |
| |Literary, artistic, industrial, technical and scientific works; |
| |Performances of performing artists, phonograms and broadcasts; |
| |Inventions in all fields of human endeavour; |
| |Registered and unregistered designs including industrial designs |
| |Trade marks, service marks and commercial names and designations; |
| |Trade secrets, know-how; and |
| |All other rights resulting from intellectual activity in the industrial, scientific, literary or artistic |
| |fields |
| |[The Convention Establishing the World Intellectual Property Organisation 1967] |
|Interface |The boundary where two items are required to pass information between them. [DCDH] |
|Materiel System |A subset of the Capability System and is the combination of the Mission System(s) and the Support System. The|
| |Materiel System covers those aspects of the Fundamental Inputs to Capability (FIC) that are provided by the |
| |acquisition agency. |
|Mission System |The Mission System is that element of the Materiel System that directly performs the operational function. |
| |Examples include platforms (eg, ship, tank, or aircraft), distributed systems (eg, communications network), |
| |and discrete systems that integrate into other Mission Systems (eg, a radar upgrade for a platform). Major |
| |components of the Support System (such as simulators, Automatic Test Equipment (ATE) and Logistic Information |
| |Management Systems (LIMS)) could also be classified as Mission Systems if the level of management attention to|
| |be applied to these components warranted this classification. |
|Product |A product is defined as any measurable, tangible, verifiable outcome, result, item or deliverable service, |
| |which must be produced or delivered (or both) to complete a project or part of a project. Products include |
| |component products. Depending on context, a product may be any component or combination of components in the |
| |system from any level or levels in the hierarchy. A product in DMO context is generally part of a capability |
| |system, including elements of both the Mission System and the Support System. |
|Product Technical Data |Technical Data related directly to a Product of interest |
|Support System |The organisation of hardware, software, materiel, facilities, personnel, processes, and data required to |
| |enable the Mission System to be effectively operated and supported so that the Mission System can meet its |
| |operational requirements. |
|System |An integrated composite of people, products and processes that provides a capability to satisfy a stated need |
| |or objective. A system is a combination or assembly of hardware, software, principles, doctrines, methods, |
| |ideas, procedures and workforce, or a combination of them, arranged or ordered towards a common objective. |
| |[DCDH] |
|Systems Engineering |An interdisciplinary approach that encompasses the entire technical effort, and evolves into and verifies an |
| |integrated and life-cycle balanced set of systems, people, products, and process solutions that satisfies |
| |customer needs. [DCDH] |
|Technical Data |All technical know-how and information reduced to material form (includes digital form) relating to a product,|
| |and includes all data, manuals, handbooks, designs, standards, specifications, reports, writings, models, |
| |sketches, plans, drawings, calculations, software documentation, test results and other items describing or |
| |providing information relating to the product. A product may be an entire Materiel System, a Mission System, a|
| |Support System, a subsystem, or an item of equipment. |
| |[adapted from DEFLOGMAN GLOSSARY] |
|Test and Evaluation (T&E) |A process to obtain information to support the objective assessment of a capability system with known |
| |confidence, and to confirm whether or not a risk is contained within acceptable boundaries across all facets |
| |of a system’s life cycle. A test is an activity in which a scientific method is used to obtain quantitative or|
| |qualitative data relating to the safety, performance, functionality, contractual compliance, and |
| |supportability of a system. Evaluation is the analysis of test results to determine (verify) or prove |
| |(validate) something. [DCDH] |
|Validation |Confirmation by examination and provision of objective evidence that the specific intended use or application |
| |of a product or service is accomplished in an intended usage environment. [DCDH] |
|Verification |Confirmation by examination and provision of objective evidence that specified requirements to which a product|
| |or service, or aggregation of products and services, is built, coded, assembled and provided have been |
| |fulfilled. [DCDH] |
The following abbreviations are used in this document:
|AGLS |Australian Government Locator Service |
|ASDEFCON |Australian Defence Contract template(s) |
|ASIS |Acquisition and Support Implementation Strategy |
|ATE |Automatic Test Equipment |
|AWM |Australian War Memorial |
|BPA |Business Process Authority |
|BPO |Business Process Owner |
|CAD |Computer-Aided Design |
|CASA |Civil Aviation Safety Authority |
|CCB |Configuration Control Board |
|CCP |Configuration Change Proposal |
|CDD |Capability Definition Documents |
|CDRL |Contract Data Requirements Lists |
|CI |Configuration Item |
|CIOG |Chief Information Officer Group |
|CM |Configuration Management |
|COTS |Commercial Off The Shelf |
|CSA |Configuration Status Accounting |
|CSLC |Capability System Life Cycle |
|DAL |Data Accession List |
|DCDH |Defence Capability Development Handbook |
|DID |Data Item Description |
|DMH |Defence Materiel Handbook |
|DMI |Defence Materiel Instruction |
|DMO |Defence Materiel Organisation |
|DMS |Data Management System |
|DMWR |Depot Maintenance Work Requirements |
|DPPM |Defence Procurement Policy Manual |
|DSM |Defence Security Manual |
|ETD |Electronic Technical Data |
|FAA |Federal Aviation Administration |
|FIC |Fundamental Inputs to Capability |
|FMECA |Failure Modes and Effects Criticality Analysis |
|FMS |Foreign Military Sales |
|FPS |Function and Performance Specification |
|GFD |Government Furnished Data |
|GFI |Government Furnished Information |
|GIDEP |Government-Industry Data Exchange Program |
|IETD |Interactive Electronic Technical Data |
|IP |Intellectual Property |
|IPMAN |Intellectual Property Manual |
|ISP |Integrated Support Plan |
|ITAR |International Traffic in Arms Regulations |
|JOS |Judgement of Significance |
|LCC |Life Cycle Cost |
|LIMS |Logistic Information Management Systems |
|LOT |Life of Type |
|LSA |Logistics Support Analysis |
|MEC |Materiel Engineering Council |
|NAA |National Archives of Australia |
|OCD |Operational Concept Document |
|OEM |Original Equipment Manufacturer |
|PBS |Product Breakdown Structure |
|RCM |Reliability Centred Maintenance |
|RTM |Requirements Traceability Matrix |
|SIE |Single Information Environment |
|SM |Strategic Materiel |
|SOW |Statement of Work |
|SS |System Specification |
|SSCC |Support System Constituent Capabilities |
|SSDESC |Support System Description |
|T&E |Test and evaluation |
|TCD |Test Concept Document |
|TDL |Technical Data List |
|TDP |Technical Data Package |
|TDRA |Technical Data Requirements Analysis |
|TDT |Technical Documentation Tree |
|TIR |Technical Information Review |
|VCRM |Verification Cross Reference Matrix |
|WBS |Work Breakdown Structure |
DOCUMENT ADMINISTRATION SHEET
Key Information
|DOCUMENT CATEGORY |DEFENCE MATERIEL HANDBOOK (DMH) |
|FUNCTIONAL DOMAIN |ENGINEERING MANAGEMENT (ENG) |
|REFERENCE NUMBER |DMH (ENG) 12-2-003 |
|VERSION NO |V1.0 |
|TITLE |TECHNICAL DATA MANAGEMENT HANDBOOK |
|BUSINESS PROCESS OWNER (BPO) |GENERAL MANAGER JOINT, SYSTEMS AND AIR |
|BUSINESS PROCESS AUTHORITY (BPA) |DIRECTOR MATERIEL ENGINEERING |
| |shari.soutberg@.au |
|Domain Expert |Paul Steinback |
| |paul.steinback@.au |
|Amendment Details |Initial Version |
|Filing Details |AB16924258 |
|Review Period |24 months |
|Consultation |Engineering COP and Materiel Engineering Council |
[pic]
-----------------------
[1] DEFLOGMAN, Part 2, Volume 10, Chapter 5, Acquisition and Management of Technical Data
[2] This figure is based on the data taxonomy illustrated in MIL-STD-31000A and elaborated in the US Army Guide for the Preparation of a Program Product Data Management Strategy.
[3] Logical models / logical solution representations - Functional analysis, object-oriented analysis, structured analysis, and information engineering analysis are recognized approaches to develop logical solution representations (logical models) in terms of, for example, functional flows, behavioural responses, state and mode transitions, timelines, control flows, data flows, information models, object services and attributes, context diagrams, threads, data structures, and functional failure modes and effects. (adapted from EIA-632)
[4] This is an element of achieving value for money over the entire life of type
[5] The CSLC phases are defined in the Defence Capability Development Handbook.
[6] Refer to DMI (A&S) 14-3-001, Development and Management of the ASIS and DMH (A&S) 14-3-001 to 14-3-006 (inclusive), Supporting Documents for the ASIS.
[7] Categories from Figure 1
[8] Refer DI(G) LOG 4-5-005 Defence Policy on Integrated Logistics Support.
[9] DEF(AUST) 5664 Issue A, Work Breakdown Structures for Defence Materiel Projects.
[10] Adapted from PMBOK ® Guide -2000 Edition and AS/NZS ISO 9000:2000. Note: examples include component products of the Mission System and Support System; enabling products such as plans, reports and process artefacts; and deliverable services such as training.
[11] Products also include items of the Support System, eg items of support and test equipment (S&TE) and training equipment.
[12] An aggregation of hardware, software, firmware or any discrete portion thereof that satisfies an end use function and is designated for separate configuration management (ie it has specified requirements and is an item to which the effectivity of the changes is addressed) – source EIA-649-B.
[13] including maintenance philosophy and the in-service support methodology to be employed
[14] As defined by DI(G) LOG 4-5-012, Regulation of technical integrity of ADF Materiel.
[15] For example, the Commonwealth Work Health and Safety Act 2011 and Environment Protection and Biodiversity Conservation Act 1999
[16] This uses a subset of the components identified in the PBS hierarchy shown in Figure 7.
[17] Refer to DMI (ENG) 12-2-003, Acquisition and Management of Technical Data.
[18] DEF(AUST) 5629 Issue B, Production of Military Technical Manuals Standard.
[19] DEFLOGMAN Part 2 Volume 10 Chapter 5, Acquisition and Management of Technical Data and DMI (ENG) 12-2-003, Acquisition and Management of Technical Data.
[20] Also see ABR 6492 Volume 2, Navy Technical Regulations Manual.
[21] For further discussion of this issue, refer to DMH(ENG) 12-5-001 Defence Materiel Verification and Validation Guide
[22] Refer to ABR 6492, Navy Technical Regulations Manual, TRAMM-L, Technical Regulation of ADF Materiel Manual – Land and eTAMM, electronic Technical Airworthiness Management Manual for further guidance.
[23] For further discussion, refer to the ASDEFCON templates and associated guidance, in particular see ASDEFCON(SM) SOW clause 2.3 relating to the arrangements for deliverable data items.
[24] DMO’s Standardisation Office (SO) is coordinating a move towards centralised DMO/Defence repositories.
[25] Refer to DMH(IND) 05-0-001 United States Defence Export Controls Guidance.
[26] MIL-STD-974. Contractor Integrated Technical Information Service (CITIS), may provide additional background information on implementing a DMS.
[27] Refer to Defence Security Manual for guidance and further detail and protection of classified material.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- integration of technology in education
- dorothy sayers integration of subjects
- crm integration with office 365
- importance of integration in education
- technology integration in the classroom
- onenote integration with outlook 365
- integration by parts calculator math
- integration by parts calculator steps
- integration by parts calc
- integration rules that involve cos sin
- exponential integration rules
- integration tables