System Integration Guide€¦ · Web viewIn accordance with DEFLOGMAN, Technical Data includes all technical know-how and information reduced to material form (includes digital

Technical Data Management HandbookDefence Materiel Handbook (ENG)

12-2-003

DMH (ENG) 12-2-003

BPO: MEC Chair Version: 1.0 Page ii

DMH (ENG) 12-2-003

Australian Government

Department of Defence Defence Materiel

Organisation

Defence Materiel Handbook(Engineering Management)

DMH (ENG) 12-2-003

Technical Data Management Handbook

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.

BPO: MEC Chair Version: 1.0 Page iii

DMH (ENG) 12-2-003

TABLE OF CONTENTS1 INTRODUCTION..................................................................................................................... 11.1 Purpose of this Guide..............................................................................................................11.2 What is Technical Data?..........................................................................................................11.3 How much Technical Data?.....................................................................................................52 TECHNICAL DATA MANAGEMENT......................................................................................52.1 Technical Data Management Activities....................................................................................52.2 Technical Data in the Capability System Life Cycle.................................................................62.2.1 Life Cycle Phases Overview....................................................................................................62.2.2 Needs Phase........................................................................................................................... 72.2.3 Requirements Phase...............................................................................................................72.2.4 Acquisition Phase.................................................................................................................... 82.2.5 In Service Phase..................................................................................................................... 82.2.6 Disposal Phase....................................................................................................................... 83 IDENTIFICATION - TECHNICAL DATA REQUIREMENTS ANALYSIS................................93.1 Introduction.............................................................................................................................. 93.2 System Definition..................................................................................................................... 93.3 Technical Data associated with a System.............................................................................113.4 Activities requiring Technical Data.........................................................................................133.5 Technical Data associated with Support................................................................................153.6 Technical Data Formats........................................................................................................184 ACQUISITION AND CREATION OF TECHNICAL DATA....................................................194.1 Rights to Technical Data.......................................................................................................194.2 Objectives.............................................................................................................................. 194.3 ASDEFCON and Technical Data...........................................................................................195 VERIFICATION, VALIDATION AND ACCEPTANCE OF TECHNICAL DATA....................205.1 Purpose of Verification and Review / Acceptance.................................................................205.2 Data Quality Verification........................................................................................................205.3 Data Marking Inspection........................................................................................................215.4 Metadata Standard................................................................................................................215.5 Validation of Technical Data..................................................................................................215.6 Technical Information Review...............................................................................................215.7 Contractual Endorsement/Review.........................................................................................226 STORAGE, MAINTENANCE AND CONTROL OF TECHNICAL DATA..............................226.1 Purpose................................................................................................................................. 226.2 Storage Systems...................................................................................................................226.3 Access Controls and Maintenance........................................................................................236.4 Configuration Management...................................................................................................236.5 Unique Identification..............................................................................................................246.6 File and Database Management............................................................................................246.7 Maintenance of Essential File and Version Relationships.....................................................247 USE, DISTRIBUTION AND EXCHANGE OF TECHNICAL DATA.......................................257.1 General.................................................................................................................................. 257.2 Enterprise-wide Access and Use...........................................................................................257.3 Data Management System....................................................................................................257.3.1 Facilitating Data Exchange....................................................................................................257.3.2 DMS General Requirements.................................................................................................257.3.3 DMS Implementation and Management................................................................................268 ARCHIVAL AND DISPOSAL OF TECHNICAL DATA.........................................................278.1 Overview............................................................................................................................... 278.2 Legal Archival, Destruction or Disposal.................................................................................288.3 National Archives Act and POLMAN 3.....................................................................288.2 LEGAL ARCHIVAL, DESTRUCTION OR DISPOSAL.........................................................288.3 National Archives Act and POLMAN 3..................................................................................28

List of FiguresFigure 1 – Hierarchy of Technical Data Information Categories.............................................................3Figure 2 - Optimum level of Technical Data...........................................................................................5

BPO: MEC Chair Version: 1.0 Page iv

DMH (ENG) 12-2-003

Figure 3 – Technical Data Management Activities..................................................................................6Figure 4 – Capability System Life Cycle Phases....................................................................................6Figure 5 – Technical Data understanding and requirements change during CSLC................................7Figure 6 – Capability System Breakdown.............................................................................................10Figure 7 – Product Breakdown Structure..............................................................................................10Figure 8 – Technical Data Items assigned as required for different Activities......................................14Figure 9 – Technical Data Requirements depend on Acquisition Needs, Support Concepts and

Business Needs............................................................................................................................ 15Figure 10 – Support System Constituent Capabilities and Resources.................................................15Figure 11 – Support Services and Organisations for some System Components................................17Figure 12 – Exchange and Flow of Technical Data Across a Product Lifecycle...................................18

List of TablesTable 1 – Uses for Product Technical Data in Different Information Categories.....................................4Table 2 – Information Categories of Technical Data generated during the CSLC..................................6Table 3 – Examples of Technical Data associated with the System PBS.............................................12Table 4 – Examples of Technical Data associated with Support System Constituent Capabilities.......16Table 5 – Product Technical Data Information Categories.....................................................................2

AnnexesAnnex A: Technical Data FormatAnnex B: Referenced DocumentsAnnex C: Definitions and Abbreviations

BPO: MEC Chair Version: 1.0 Page v

DMH (ENG) 12-2-003

1 INTRODUCTION1.1 Purpose of this Guide1.1.1 This guide is intended to assist Defence Materiel

Organisation (DMO) personnel to manage Technical Data in Materiel Systems acquisition and sustainment.

1.1.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.

1.2 What is Technical Data?1.2.1 In accordance with DEFLOGMAN2, 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.

1.2.2 The range of information considered to be Technical Data can be shown as a hierarchy of information categories illustrated by Figure 13. 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).

1.2.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.

1.2.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.

1.2.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;

b. 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

2 DEFLOGMAN, Part 2, Volume 10, Chapter 5, Acquisition and Management of Technical Data3 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.

BPO: MEC Chair Version: 1.0 Page 1

DMH (ENG) 12-2-003

c. 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.

1.2.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.

1.2.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.


DMH (ENG) 12-2-003

Technical ProductDefinition

Information

Data

TechnicalData

Non Technical Data such as:•Financial Data•Management Data•Administrative Data

ProductTechnical Data

Non-Product Technical Data

Technical Associated

Information

Technical ProductOperational Information

Design Information

Requirements Information

Manufacturing Information

Verification Information

Configuration Control

Information

Other Associated

Information

Logistics Product

Data

MaterialIn Service

Data

Other Design

Information

Product Design•Models•Drawings•Associated Lists•Specifications•Standards•Quality Assurance Provisions•Software Documentation•Packaging Details

Software

Figure 1 – Hierarchy of Technical Data Information Categories


DMH (ENG) 12-2-003

Information Category Use Typical ExamplesTe

chni

cal P

rodu

ct D

efin

ition

Info

rmat

ion


Captures and documents: how a system/component will be used, what functions must be performed, level of performance required, which constraints will apply, and traceability of requirements through the

product hierarchy.

Operational Concept DocumentsFunction and Performance SpecificationsSystem SpecificationsSupport System SpecificationsSoftware Requirements SpecificationsRequirements DatabasesRequirements Traceability Matrices

Design Information Captures, documents and records: how a design was performed, why certain design decisions are made, and what components were selected and why.

Logical models4

Product ModelsProduct DrawingsSoftware Design DescriptionsDesign DocumentationSystem Architecture DescriptionTrade Study Reports


Documents and records: what will be manufactured, how it will be manufactured, components required for manufacture, and any specific processes required.

Circuit SchematicsPrinted Circuit Board Layout FilesAssembly DrawingsParts ListsBill of MaterialsEngineering DrawingsComputer Software Source Code

Tech

nica

l Ass

ocia

ted

Info

rmat

ion


Captures, documents and records: validation and verification concepts, validation and verification planning, validation procedures and results, verification procedures and results, and traceability from requirements to validation

and verification results.

Test Concept DocumentsTest & Evaluation/Acceptance Master PlansAcceptance Test Plans, Procedures, Reports

& ResultsTest Procedures & ResultsVerification Cross Reference Matrices

Configuration Control Information

Documents and records: system or component configuration, configuration at specific instances such as:

o baseline,o version release or upgrade, oro product issue, and

constituent parts and processes.

Master Record IndicesConfiguration Status Accounting ReportsEngineering DrawingsParts ListsSoftware Version Description DocumentsConfiguration IdentifiersConfiguration Baselines

Other Associated Information

Captures, documents and records: associated information not in verification or

configuration control categories.

GIDEP Notices of Obsolete PartsSuppliers Notices of Obsolete PartsDisposal Information

Tech

nica

l Pro

duct

Ope

ratio

nal I

nfor

mat

ion

Logistics Product Data Documents and records: system or component availability and

reliability, sparing analysis, preventive/corrective maintenance

procedures repair/replace procedures, support & test equipment requirements, software support requirements, and training needs.

Failure Modes & Effect Criticality Analyses Reliability Centred Maintenance ReportsLevel of Repair AnalysesLogistic Support AnalysesTraining Needs Analysis ReportsSupport & Test Equipment Plans and

Provisioning ListsSoftware Support Plans

Materiel In-Service Data

Documents, defines or provides: spares holdings and usage, technical publications, training records, electronic manuals, servicing frequencies and inspection criteria, determination of materiel useability interactive electronic manuals, and system and component availability records

Codification DataSpares ListsPublication PackagesOperator, Maintenance ManualsServicing and Inspection InstructionsSoftware Operator / User ManualsMaintenance Management System DataInteractive Electronic Technical ManualsDefect ReportsTraining MaterialsOperator/Maintainer Training Courses

Table 1 – Uses for Product Technical Data in Different Information Categories

4 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)


DMH (ENG) 12-2-003

1.3 How much Technical Data?1.3.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).

insufficient Technical Data excessive Technical Data

• support functions may not be able to be performed at all

• support may not be performed efficiently and cost effectively (eg no Defence ability to compete suppliers)

• unnecessary data management• excess support resources• cost of unnecessary IP• cost of Technical Data maintenance

optimum level of Technical Data

“amount” of Technical Data

cost

of o

wne

rshi

p

Figure 2 - Optimum level of Technical Data

2 TECHNICAL DATA MANAGEMENT2.1 Technical Data Management Activities2.1.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);

b. acquisition and creation of Technical Data, including consideration of the Intellectual Property (IP) rights associated with Technical Data;

c. verification, validation and acceptance of Technical Data;d. storage, maintenance and configuration control of Technical Data;e. use, distribution and exchange of Technical Data; andf. archival and disposal of Technical Data.

2.1.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 goals5, maximising options for product support and enabling performance of downstream life cycle functions.

5 This is an element of achieving value for money over the entire life of type


DMH (ENG) 12-2-003

Identify Data Requirements

Store, Maintainand Control Data

Use, Distributeand Exchange Data

Data Acquisition

Data Use & Management

Policies, Procedures, & Training

DataRepository

•Acquire or Develop• Manufacture• Operate

• Support• Maintain• Dispose of

Data Needed To:

• ASDEFCON • SOW & DIDs• Contract Clauses

• Data Quality Verification• Data Marking Inspection• ASDEFCON Endorsement/Review• Technical Information Review• Authorisation for use

• Storage System(s)• Access Controls• Configuration Management

• Enterprise-wide Access & Use• Seamless Data Exchange• Competitive Use Over Lifecycle

the System

Data Rights Resolution

• Assertion Challenges• Commonwealth & Contractor

Licence Agreements• Legacy Programs

Key Decision Point

• Definitions• Education• SDMI

• Data Rights Assertions

• Source Selection

Verify / Validate andAccept Data

Acquire or Create Data

Archive or Dispose of Data

• Archival according to law• Destruction or Disposal• National Archives Act 1983/POLMAN 3

Figure 3 – Technical Data Management Activities

2.2 Technical Data in the Capability System Life Cycle

2.2.1 Life Cycle Phases Overview

2.2.1.1 The Capability System Life Cycle (CSLC) has five phases6 as illustrated in Figure 4. DMO provides a Materiel System as a component of the Capability System.

NeedsPhase

RequirementsPhase

AcquisitionPhase

In ServicePhase

DisposalPhase

Figure 4 – Capability System Life Cycle Phases

2.2.1.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 PhasesNeeds 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

2.2.1.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.

6 The CSLC phases are defined in the Defence Capability Development Handbook.


DMH (ENG) 12-2-003

REQUIREMENTS I REQUIREMENTS II ACQUISITION IN-SERVICE

1P 2P

“Exemplar” Tenderer-Proposed Solutions

Negotiated Contract(Modifies Proposed Solutions)

ContractSignature

Final MaterielRelease

Final “Baseline”Design

Design Evolution

.

.

.

.

.

.

.

.

.

.

.

.

Options Exploration,

Requirements Definition

Solicitation Document

Development

Tender Evaluation,

Offer Definitio

n Activities

Contract Negotiation

Contractor analysis of the types / quantities of TD identified for each of the Support System Constituent Capabilities to define the optimal range and quantity of Technical Data required to meet the Support System Functional Baseline.

Integration, Test,

Deployment/Delivery Sustainment…

Maintenance, Evolution,

Interfacing, Enhancement,

Obsolescence Management

DetailedDesign Review

Commonwealth establishes Whole of Life Acquisition and Support Implementation Strategy that frames each organisation’s need for Technical Data.

Figure 5 – Technical Data understanding and requirements change during CSLC

2.2.2 Needs Phase

2.2.2.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)7.

2.2.3 Requirements Phase

2.2.3.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.2.3.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.

2.2.3.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

7 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.


DMH (ENG) 12-2-003

and content requirements should be developed and reviewed to confirm they address what is required.

2.2.3.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.

2.2.4 Acquisition Phase

2.2.4.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.2.4.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.

2.2.4.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.

2.2.5 In Service Phase

2.2.5.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.2.5.2 Logistics Product Data and Materiel In-Service Data8 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.

2.2.5.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.

2.2.5.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.

2.2.6 Disposal Phase

2.2.6.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.

8 Categories from Figure 1


DMH (ENG) 12-2-003

3 IDENTIFICATION - TECHNICAL DATA REQUIREMENTS ANALYSIS 3.1 Introduction3.1.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.3.1.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 TDd. 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.1.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.

3.1.4 In service, Technical Data is one of the fundamental support resources needed for each of the Support System Constituent Capabilities (SSCC)9, 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.

3.1.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; andf. define the required format for the Technical Data.

3.2 System Definition3.2.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).

9 Refer DI(G) LOG 4-5-005 Defence Policy on Integrated Logistics Support.


DMH (ENG) 12-2-003

Capability System

Mission System(s)

Support System

Organisation Personnel Collective Training Facilities Supply Materiel

SystemCommand & Management Support

Fundamental Inputs to Capability

Figure 6 – Capability System Breakdown

3.2.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 classificationError: Reference source not found.

3.2.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, subcontractorsError: Reference source not found or other suppliers.

3.2.4 Any system (Mission or Support) can be represented by a structured hierarchy of component products, the Product Breakdown Structure (PBS)10, 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 project11. A product may be any component or combination of components in the System from any level or levels in the hierarchy12.

10 DEF(AUST) 5664 Issue A, Work Breakdown Structures for Defence Materiel Projects.11 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.12 Products also include items of the Support System, eg items of support and test equipment (S&TE) and training equipment.


DMH (ENG) 12-2-003

System

Subsystem 1

Subsystem 2

Subsystem 3

Assembly 1.1

Assembly 1.2

Assembly 2.1

Assembly 2.2

Assembly 2.3

Part 1.2.1

Part 1.2.2

Part 1.2.3

Part 2.2.1

Part 2.2.2

Part 2.3.1

Part 2.3.2

OTS

DI

Figure 7 – Product Breakdown Structure

3.2.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)13 where components at the lower levels could be hardware or software CIs.

3.2.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.

3.3 Technical Data associated with a System3.3.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.

3.3.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.3.3 The application of acquisition and support concepts14 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.

13 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.14 including maintenance philosophy and the in-service support methodology to be employed


DMH (ENG) 12-2-003

3.3.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.

3.3.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 Figure7, Table 3 lists the information categories and examples of typical Technical Data that could be associated with this subset of the PBS.

3.3.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.


DMH (ENG) 12-2-003

ProductTechnical Data

Information Category ExamplesSystem 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 ResultsConfiguration Control Master Record Index, Baseline Configurations

Subsystem 1 Requirements Subsystem Specification, Requirements Traceability MatrixDesign Design Documentation, Functional ModelsVerification Acceptance Test Procedure, Report and ResultConfiguration Control Allocated and Product Baseline Configurations

Assembly 1.1 Requirements Procurement SpecificationDesign Product Models, Engineering Drawings (External Interfaces)Verification Acceptance and Production Test Procedures and ResultsConfiguration Control Product Baseline ConfigurationInstallation Software Version Descriptions, Installation DrawingsLogistics 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 SpecificationDesign Design/Development DocumentationVerification Acceptance Test Procedures and ResultsConfiguration Control Product Baseline ConfigurationManufacturing Assembly Drawings, Bill of MaterialsLogistics 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 SpecificationDesign Design/Development DocumentationVerification Acceptance and Production Test Procedures and ResultsConfiguration Control Product Baseline ConfigurationManufacturing Assembly Drawings, Software Version Descriptions, Bill of MaterialsLogistics 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 & 1.2.3

Requirements Procurement SpecificationDesign Product Models, Engineering Drawings (External Interfaces)Verification Production Test Results, Certificates of ConformanceConfiguration Control Product Baseline ConfigurationLogistics 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


DMH (ENG) 12-2-003

3.4 Activities requiring Technical Data3.4.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 framework15 and Australian legislation16;

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.3.4.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.4.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; andg. Other – any activity that was not anticipated or covered by the preceding

Additional Activities or Core Activities.3.4.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.

15 As defined by DI(G) LOG 4-5-012, Regulation of technical integrity of ADF Materiel.16 For example, the Commonwealth Work Health and Safety Act 2011 and Environment Protection and Biodiversity Conservation Act 1999


DMH (ENG) 12-2-003

TDI-0001

Technical Data Items

TDI-0002

TDI-0003

TDI-0004

TDI-0005

TDI-0006

TDI-0007

TDI-0008

TDI-0009

TDI-0010

TDI-0011

TDI-0012

TDI-0013

TDI-0014

TDI-0015

TDI-0016

TDI-0017

TDI-0018

TDI-0019

TDI-0020

TDI-0021

TDI-0022

TDI-0023

TDI-0024

TDI-0025

Operation

Installation & Configuration

Activities

CO

RE

AD

DIT

ION

AL

Operational Maintenance

Technical Integrity

Integration

Verification & Validation

Storage & Transportation

Training

Modification

Development

Manufacturing

Non-Operational Maintenance

Emergency Repair

Other

Disposal (notSale or Donation)

Disposal bySale or Donation

Figure 8 – Technical Data Items assigned as required for different Activities

3.4.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.


DMH (ENG) 12-2-003

Figure 9 – Technical Data Requirements depend on Acquisition Needs, Support Concepts and Business Needs

3.5 Technical Data associated with Support3.5.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.

Support System

Maintenance Support

Engineering Support

Operating Support

Supply Support

Training Support

Personnel

Processes

Facilities

Equipment

Technical Data

Personnel

Processes

Facilities

Equipment

Technical Data

Personnel

Processes

Facilities

Equipment

Technical Data

Personnel

Processes

Facilities

Equipment

Technical Data

Personnel

Processes

Facilities

Equipment

Technical Data

IM Systems IM Systems IM Systems IM Systems IM Systems

Spares & Packaging

Figure 10 – Support System Constituent Capabilities and Resources


DMH (ENG) 12-2-003

Constituent CapabilityTechnical Data

Example Expected ActivitiesOperating Support Operator Manuals

HandbooksSimulationsStandards

Operation

Engineering Support SpecificationsEngineering DrawingsModelsPlansDatabasesDesign DataTest ResultsCM RecordsAnalyses

Installation & ConfigurationVerification & ValidationTechnical IntegrityIntegration

ModificationDevelopmentManufacturing

Maintenance Support Maintenance ManualsHandbooksRecordsReportsCalibration Reports

Installation & ConfigurationOperational MaintenanceDisposal (not by Sale or Gift)Non-Operational MaintenanceEmergency Repair

Supply Support DatabasesReportsDrawingsHandbooksPlansCalibration Reports

Installation & ConfigurationOperational MaintenanceDisposal (not by Sale or Gift)Non-Operational MaintenanceEmergency RepairDisposal by Sale or Gift

Training Support Training MaterialsPresentationsHandbooksModelsSimulations

Training

Table 4 – Examples of Technical Data associated with Support System Constituent Capabilities

3.5.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.5.3 The relationship and interaction between support services and organisations supporting the components of the example system is illustrated in Figure 1117. 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; andd. required exchange of Technical Data to support these arrangements.

17 This uses a subset of the components identified in the PBS hierarchy shown in Figure 7.


DMH (ENG) 12-2-003

Operating Support

Engineering

Maintenance

Supply

Training

Components to be Supported

Commonwealth

Other Contractors or Third Parties

Original Contractor

Organisation providing support service.

Syst

em

Subs

yste

m 1

Asse

mbl

y 1.

1

Asse

mbl

y 1.

2

Part

1.2

.1

Part

1.2

.2

Part

1.2

.3

Con

stitu

ent C

apab

ility

Su

ppor

t Ser

vice

Figure 11 – Support Services and Organisations for some System Components

3.5.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).

3.5.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.

3.5.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


DMH (ENG) 12-2-003

11

Contractor (Acquisition)

CoA

Technical Data

Software

Contractor A (Support)

GFD / GFI

GFI/GFD

new Technical Data

Acquisition Support

CoA supplied Technical Data

CoA supplied Technical Data Contractor B (Support)

GFD / GFI

new Technical Data

CoA supplied Technical Data

Technical Data for external projects / systems(eg interface data)

Technical Data

Technical Data from external projects / systems(eg interface data)

Technical Data

Figure 12 – Exchange and Flow of Technical Data Across a Product Lifecycle

3.6 Technical Data Formats3.6.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).

3.6.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.6.3 The content and format of Technical Data will be specified in the contract mostly through Data Item Descriptions (DID).

3.6.4 DMO policy18 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.

3.6.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.

3.6.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.

18 Refer to DMI (ENG) 12-2-003, Acquisition and Management of Technical Data.


DMH (ENG) 12-2-003

4 ACQUISITION AND CREATION OF TECHNICAL DATA4.1 Rights to Technical Data4.1.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.

4.2 Objectives4.2.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.

4.2.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.

4.3 ASDEFCON and Technical Data4.3.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).

4.3.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.

4.3.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.3.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);


DMH (ENG) 12-2-003

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); andk. the (optional) Data Accession List (DAL).

4.3.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.

4.3.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.

4.3.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).

5 VERIFICATION, VALIDATION AND ACCEPTANCE OF TECHNICAL DATA5.1 Purpose of Verification and Review / Acceptance5.1.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; andd. take appropriate action to acknowledge the suitability or otherwise of the Technical

Data.

5.2 Data Quality Verification5.2.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) 5629B19, 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.

5.2.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.

19 DEF(AUST) 5629 Issue B, Production of Military Technical Manuals Standard.


DMH (ENG) 12-2-003

5.2.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.

5.2.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.2.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 formats20 unless there is a specific business case need for an alternative. Guidance on formats preferred by Defence is provided in Annex A.

5.3 Data Marking Inspection5.3.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) classificationd. rights relating to the Technical Data, including Intellectual Property ownership and

authorised use; ande. any other access restrictions.

5.3.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.

5.4 Metadata Standard 5.4.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 elements21 are:

a. creator (author),b. publisher,c. title,d. date,e. subject or function, andf. identifier or availability.

5.5 Validation of Technical Data5.5.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.

5.5.2 Validation of Technical Data may also form part of a broader supportability test and evaluation activities22.

20 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.21 Also see ABR 6492 Volume 2, Navy Technical Regulations Manual.22 For further discussion of this issue, refer to DMH(ENG) 12-5-001 Defence Materiel Verification and Validation Guide


DMH (ENG) 12-2-003

5.6 Technical Information Review5.6.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.

5.6.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.

5.6.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.23

5.7 Contractual Endorsement/Review5.7.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.

5.7.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 Review24. The processes associated with these differing levels of endorsement are specified in the ASDEFCON SOW.

5.7.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.

5.7.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.7.5 For additional information on detailed contracting issues, refer to the the ASDEFCON contract guidance material.

6 STORAGE, MAINTENANCE AND CONTROL OF TECHNICAL DATA6.1 Purpose6.1.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 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.24 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.


DMH (ENG) 12-2-003

6.2 Storage Systems6.2.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.

6.2.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.25 Program unique repository approaches may also inhibit data access, sharing and reuse across the appropriate organisations.

6.2.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.

6.3 Access Controls and Maintenance6.3.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.

6.3.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.

6.3.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.6.3.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

25 DMO’s Standardisation Office (SO) is coordinating a move towards centralised DMO/Defence repositories.


DMH (ENG) 12-2-003

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.

6.4 Configuration Management6.4.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.

6.4.2 Changes to the data should be coordinated with the data owner or be identified as changed from the original data.

6.4.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.

6.4.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.

6.4.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; ande. a defined relationship to one or more specific product definition(s) and/or specific

product instance(s).

6.5 Unique Identification. 6.5.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, andc. retrieved when necessary.

6.5.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, andg. sponsor.


DMH (ENG) 12-2-003

6.6 File and Database Management. 6.6.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.

6.6.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.

6.7 Maintenance of Essential File and Version Relationships. 6.7.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.

7 USE, DISTRIBUTION AND EXCHANGE OF TECHNICAL DATA7.1 General7.1.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 Control26 perspective) need to be considered.

7.2 Enterprise-wide Access and Use7.2.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.

7.2.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.

26 Refer to DMH(IND) 05-0-001 United States Defence Export Controls Guidance.


DMH (ENG) 12-2-003

7.3 Data Management System

7.3.1 Facilitating Data Exchange

7.3.1.1 Once the Commonwealth has determined its Technical Data requirements, a decision should be made regarding how best to obtain access to it.

7.3.1.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).

7.3.1.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;

andc. reduced risk through enhanced access to data.

7.3.1.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.

7.3.2 DMS General Requirements

7.3.2.1 A DMS27 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.

7.3.2.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; andc. contract or sub-contract personnel acting on Defence’s behalf.

7.3.2.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

27 MIL-STD-974. Contractor Integrated Technical Information Service (CITIS), may provide additional background information on implementing a DMS.


DMH (ENG) 12-2-003

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.

7.3.3 DMS Implementation and Management

7.3.3.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).

7.3.3.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.

7.3.3.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.

7.3.3.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.

7.3.3.5 DMS Technical Data should be protected against unauthorised access.

7.3.3.6 System security28 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); andf. 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.3.3.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.

7.3.3.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; andd. how comments are to be provided for document type (eg native file formats etc).

7.3.3.9 The promotion of data in the DMS from one status to the next (eg working, draft

28 Refer to Defence Security Manual for guidance and further detail and protection of classified material.


DMH (ENG) 12-2-003

submission, final submission, Approved and Accepted) should be detailed; and

7.3.3.10 A point-of-contact should be provided for assisting Commonwealth Authorised Users with problem resolution and to answer questions concerning the DMS.

7.3.3.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; ande. provision of training materials.

8 ARCHIVAL AND DISPOSAL OF TECHNICAL DATA8.1 Overview8.1.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.

8.1.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.

8.1.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.

8.1.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; ande. Financial Management and Accountability (FMA) Act 1997.

8.1.5 The disposal of Technical Data is therefore a continuous process that extends beyond the life cycle of a capability system or specific equipment.

8.1.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).

8.2 Legal Archival, Destruction or Disposal8.2.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.

8.2.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.


DMH (ENG) 12-2-003

8.3 National Archives Act and POLMAN 38.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).

8.3.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; andd. Section 33 – Exempt records.

8.3.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.8.3.4 For further detailed guidance on Technical Data disposal,

DMO personnel should consult POLMAN 3.


ANNEX A TODMH (ENG) 12-2-003

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.

BPO: MEC Chair Version: 1.0 Page A-1

ANNEX A TODMH (ENG) 12-2-003

Information Categories Examples

Tech

nica

l Pro

duct

Def

initi

on In

form

atio

n

Design InformationOther Design Information Functional Breakdown Descriptions

Trade Study Reports (Trade-Offs)Design Selection DocumentEngineering AnalysesSimulation Models and Test Cases

Product Design Technical Data Package (TDP)Engineering Drawings/ModelsInspection ListsTest Equipment ListsSoftware DocumentationInterface Control DocumentsEngineering Product StructureDesign Documentation


Operational Concept DocumentCapabilities Development DocumentCapabilities Production DocumentSystem SpecificationsInterface Specifications


Manufacturing InstructionsManufacturing Process RoutingsDepot Maintenance Work Requirements (DMWR) for RebuildsNational Maintenance Work Requirements (NMWR)Bill of MaterialsParts List

Tech

nica

l Ass

ocia

ted

Info

rmat

ion


Verification/Validation PlanningVerification/Validation ProceduresVerification/Validation Result ReportsPhysical Configuration AuditsFunctional Configuration Audits

Configuration Control Information

Requests for ChangesRequests for VarianceCCB DecisionsProduct Configuration Management Status Account InformationEngineering Change Proposals

Other Associated Information

GIDEP Notices of Obsolete PartsSupplier Notices of Obsolete PartsDisposal Information

Tech

nica

l Pro

duct

O

pera

tiona

l Inf

orm

atio

n Logistics Product Data

Maintenance Planning InformationTechnical PublicationsSupport & Test Equipment InformationManpower, Personnel & Training InformationPackaging, Handling, Storage & Transportation InformationEnvironmental and Work Health and Safety Information

Material In Service Data

Field Feedback InformationDemand Data from Field RequisitionsItem Prognostics & Diagnostics InformationField Quality Deficiency ReportsField Supply Deficiency ReportsProduct Unit Configuration Information

Table 5 – Product Technical Data Information Categories

BPO: MEC Chair Version: 1.0 Page A-2

ANNEX B TODMH (ENG) 12-2-003

ANNEX B: REFERENCED DOCUMENTS

ABR 6492 Navy Technical Regulations ManualArchives Act 1983

AS/NZS ISO 9000:2000 Quality management and quality assurance standardsASDEFCON(Complex) Australian Standard for Defence Contracting (Complex Materiel) TemplateASDEFCON(SM) Australian Standard for Defence Contracting (Strategic Materiel) TemplateASDEFCON(Support) Australian Standard for Defence Contracting (Support) TemplateDCDH Defence Capability Development Handbook 2012DEF(AUST) 5629B Production of Military Technical ManualsDEF(AUST) 5664A Work Breakdown Structures for Defence Materiel Projects

Defence Logistics Manual Part 2, Volume 5, Chapter 10 Disposal of Defence AssetsDefence 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 DataDesigns 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 SupportDI(G) LOG 4–5–012 Regulation of technical integrity of ADF MaterielDMH(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 GuideDMH(ENG) 12-3-005 Functional and Performance Specification (FPS) Development GuideDMH(ENG) 12-5-001 Defence Materiel Verification and Validation GuideDMH(IND) 05-0-001 United States’ Defence Export Controls GuidanceDMI(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 DataDPPM Defence Procurement Policy ManualDSM Defence Security ManualEIA-632 Processes for Engineering a System, American National Standards

Institute / Electronic Industries AssociationEIA-649B National Consensus Standard for Configuration Management

Electronic Transactions Act 1999Environment Protection and Biodiversity Conservation Act 1999

eTAMM electronic Technical Airworthiness Management ManualEvidence Act 1995Financial Management and Accountability (FMA) Act 1997Freedom of Information Act 1982

IPMAN Defence Intellectual Property ManualMIL-STD-31000A Technical Data PackagesMIL-STD-974 Contractor Integrated Technical Information Service

Patents Act 1990

BPO: MEC Chair Version: 1.0 Page B-1

ANNEX B TODMH (ENG) 12-2-003

PMBOK Guide 2000 Project Management Book of Knowledge – 2000 EditionPOLMAN 3 Defence Records Management Policy Manual

Privacy Act 1988Trade Marks Act 1985

TRAMM-L Technical Regulation of ADF Materiel Manual – LandWork Health and Safety Act 2011

BPO: MEC Chair Version: 1.0 Page B-2

ANNEX C TO DMH (ENG) 12-2-003

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 interestSupport 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]

BPO: MEC Chair Version: 1.0 Page C-1


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 BoardCCP Configuration Change ProposalCDD Capability Definition DocumentsCDRL Contract Data Requirements Lists CI Configuration Item CIOG Chief Information Officer GroupCM Configuration Management COTS Commercial Off The Shelf CSA Configuration Status Accounting CSLC Capability System Life Cycle DAL Data Accession List DCDH Defence Capability Development HandbookDID Data Item Description DMH Defence Materiel Handbook DMI Defence Materiel InstructionDMO Defence Materiel Organisation DMS Data Management System DMWR Depot Maintenance Work Requirements DPPM Defence Procurement Policy Manual DSM Defence Security ManualETD Electronic Technical Data FAA Federal Aviation Administration FIC Fundamental Inputs to Capability FMECA Failure Modes and Effects Criticality AnalysisFMS Foreign Military Sales FPS Function and Performance SpecificationGFD Government Furnished Data GFI Government Furnished Information GIDEP Government-Industry Data Exchange ProgramIETD Interactive Electronic Technical Data IP Intellectual Property IPMAN Intellectual Property ManualISP Integrated Support Plan ITAR International Traffic in Arms RegulationsJOS Judgement of Significance LCC Life Cycle Cost LIMS Logistic Information Management Systems LOT Life of Type LSA Logistics Support AnalysisMEC Materiel Engineering Council NAA National Archives of Australia OCD Operational Concept Document OEM Original Equipment Manufacturer PBS Product Breakdown Structure RCM Reliability Centred MaintenanceRTM Requirements Traceability Matrix SIE Single Information Environment SM Strategic MaterielSOW Statement of Work SS System Specification



SSCC Support System Constituent Capabilities SSDESC Support System DescriptionT&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


DMH (ENG) 12-2-003

DOCUMENT ADMINISTRATION SHEETKEY 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 [email protected]

Domain Expert Paul [email protected]

Amendment Details Initial Version

Filing Details AB16924258

Review Period 24 months

Consultation Engineering COP and Materiel Engineering Council

BPO: MEC Chair Version: 1.0 Page DAS-1