Previous PageTable Of ContentsNext Page

6.0  MODELS


6.1  The Through Life Business Model


6.1.1  Purpose of a Through Life Business Model
The Through Life Business Model (TLBM) is a tool designed to help defense system programs manage change. It presents a vision of how NATO can improve its acquisition and logistic processes for multi-national programs by making best use of information technology over the DS's life-cycle.

Information is going "digital." This is changing the way work is done. DS programs have a growing requirement to share information across boundaries. See Figure 6.1.1-1.

 


Figure 6.1.1-1  Weapon System Information Sharing


A DS Program Office, Contractor, or Logistic Agency can use the TLBM in several ways to explore opportunities for allocating responsibility, improving communications and reducing costs:

Most change programs have an IT component. The TLBM is one of a series of tools developed by NATO to help managers make best use of IT. The others are:

DS programs embarking on change can use the TLBM, in conjunction with other NATO CALS products, as a starting point for modeling their future processes and as a tool for developing their information requirements. The TLBM illustrates the improvements that are possible when information is fully exploited. The TLBM provides:


6.1.2  Developing a TLBM


6.1.2.1  TLBM Definition
A model to illustrate NATO's improved business processes for the through life management of a Defense System (DS) as enabled by a Shared Data Environment.


6.1.2.2  TLBM Scope
The model illustrates the core activities that are required to respond successfully to the Validated Mission Need and Business Directives for the specific defense system program over its full life-cycle. Integration of the DS into any wider organizational or business context (e.g., armed force or industrial company) is assumed to occur outside the model and is reflected by the acronym of Input, Control, Output, Mechanism (ICOM) crossing the TLBM boundary, as shown in the context diagram.

The TLBM model does not define the order in which these activities are to be performed, or the organization/activity that may undertake them. In using the TLBM, DS programs will need to tailor the model to reflect their specific relationships with Armed Forces and Industry. The TLBM can be used to identify information exchanges between organizations by selecting the activities (boxes) each organization will perform and noting the arrows that cross the organizational boundary, as shown within the TLBM or at its boundary.

DSs will vary in the degree to which their support is integrated with the support of other DSs operated by the relevant Armed Forces. The model includes all activities required to provide support for a specific DS. Information required by others to support the integration of support for the specific DS with the support of others DSs is reflected by ICOMs crossing the TLBM boundary. The model reflects several activities that could be performed under contract. It does not attempt to define relationships or interfaces into the industrial supply chain beyond the Prime Contractor.


6.1.2.3  Purpose
Provide an illustration of SDE enabled improved business processes for DS through life management.

The TLBM should be used as follows:


6.1.2.4  TLBM Viewpoint
The viewpoint taken in the TLBM is that of the lifetime owner of the Defense System (DS).

The lifetime owner is accountable for providing and sustaining the specific DS, over its full life-cycle, to meet the Validated Mission Need and Business Directives agreed and maintained for that DS. Responsibility for performing this role may be held by different organizations over time.


6.1.2.5  Manage a Defense System Through Life
The NATO CALS Through Life Business Model (TLBM) is a structured representation of the major activities associated with the life-cycle of a defense system from the definition of a Validated Mission Need through disposal. It is intended to provide a reference model and a communication tool used to understand the management of a future defense system over its entire life-cycle. This is illustrated in Figure 6.1.2.5-1.

The TLBM was developed from the results of a series of workshops, arranged by the NATO CALS Organization. Experts from NATO nations were brought together to establish how information technology can be used to reduce costs, accelerate delivery and improve the availability of a defense system, over its life-cycle.

The processes illustrated by the TLBM assume that a Shared Data Environment (SDE) will be implemented within the defense system program, to captures information in digital form, as it is created. Through the SDE, all program participants can access the information when and where needed, in an appropriate form, for use many times without loss of intelligence or the need for data re- entry. This SDE, which may be specific to the program, or part of a wider IT infrastructure, enables the improvement of processes for acquiring, operating, supporting and disposing of a defense system, as illustrated by the TLBM.

 


Figure 6.1.2.5-1  (Top Level Diagram)



6.1.2.5.1  Defense System
A Defense System (DS) is an identifiable product with "special to type" support that has, or will have, a Validated Mission Need or NATO Staff Target. Validated Mission Need and NATO Staff Target (Phased Armament Procurement System (PAPS)) are equivalent pieces of information that can be used interchangeably for a Multi- national or NATO program. The term "Defense System" is used throughout the TLBM in preference to a number of other terms, in use across NATO, which have similar meaning:  e.g., Defense Equipment, Armament System, Weapon System, Weapon Equipment. The development of a support strategy for the system and the conduct of special-to-type support activities are included within the TLBM to allow illustration of Integrated Logistic Support activities. This support strategy also considers the complex and variable interface between the specific DS and the logistic infrastructures of the various Armed Forces that may use it.


6.1.2.5.2  TLBM Principles
There are several key principles identified in the workshops that are fundamental to the new ways of working.


6.1.2.5.2.1  Concurrent Engineering Approach
The TLBM reflects the global change in engineering practice towards the use of an iterative system engineering approach to product development and support, sometimes known as Concurrent Engineering (CE). Systems Engineering is defined in IEEE Standard 1220- 1994 as "An Interdisciplinary collaborative approach to derive, evolve, and verify a life-cycle balanced systems solution which satisfies customer expectations and meets public acceptability." The TLBM reflects the increasing reality that the major life-cycle processes -- requirement definition, development of solutions, manufacture, support and operational use -- operate continuously and in parallel over the life-cycle, and are no longer confined to specific life-cycle phases.


6.1.2.5.2.2  Life-cycle Integration
The life-cycle integration principle has been applied throughout the TLBM so that each activity appears once only, even though it may be used in different life-cycle phases. In addition, the TLBM draws attention (A12) to the requirement to develop and maintain a coherent and consistent set of life-cycle strategies and policies for certain key processes, which need to be applied consistently over the full life-cycle, despite changes in the program organization. Six activities are given special prominence - Acquisition, Risk Management, Integrated Logistics Support, Configuration Management, Quality Assurance, and Information Management (or CALS).


6.1.2.5.2.3  The Use of a Shared Data Environment
The Shared Data Environment (SDE) is a key enabling mechanism for the future environment as shown in the TLBM. Within the TLBM, the term is used to describe the existence of a real and significant capability, within and beyond the DS program team, to work together with digital data. Both a logical and physical environment supports consistent definition and management of information about a defense system and program through life. The DS program SDE must be established at the beginning of the life-cycle and maintained through life. The SDE must therefore have an open architecture and be adaptable to changes over time. The TLBM reflects the activities of creating and operating this SDE and managing information within it.


6.1.2.5.2.4  Multi- Disciplinary Groups
A second key mechanism linked to the TLBM is the use of Multi- Disciplinary Groups (MDGs) or Integrated Project Teams (IPT). MDG are used to bring together skills and resources from different organizations, including industry and government, to solve specific problems efficiently, by joint interactive working. This can be achieved physically by face to face meetings, or in a virtual environment (the SDE). The structure, composition, and role of the MDGs will vary depending on the contract strategy and the level of integration between customer and contractor. Used appropriately, MDGs can accelerate progress and improve quality by replacing protracted formalized procedures for information exchange and approval, by direct face- to- face working. MDGs are assumed available, as a resource, for all life-cycle activities.


6.1.2.5.3  Information as an Asset
Many of the benefits from CALS derive from a capability to capture information once, as it is created, and to use it many times over the life-cycle. Much of the data needed to support the DS in service is created by the design activity. The TLBM encourages the development, early in life, of a single, integrated source of product and support data for use throughout the life-cycle. This will require the development and use of a program information architecture.


6.1.2.5.4  Organizational Interfaces
The interface between participants in a DS program can vary widely between programs and over the life-cycle. The TLBM does not show any organizational boundaries but can be used to explore the consequences of different boundaries in terms of who does what, and to identify the critical areas of information exchange or sharing which any particular boundary will create. (See Model Scope definition for more on this topic).

As noted above, two other NATO CALS products have relevance to the TLBM.


6.1.2.5.4.1  NATO CALS Handbook
A guide for making best use of information technology in support of Defense System program. It describes a process for defining and implementing a Shared Data Environment for a specific DS program. (Chapters 1-5)


6.1.2.5.4.2  NATO CALS Data Model
The NCDM provides a possible start point for the development of the program information architecture by defining an integrated set of product and support information. The goal is to develop this data model, with other inputs, into an international standard for product life-cycle support data.


6.1.2.6  Manage a Defense System Through Life - First Level Breakdown
At this first level of breakdown four major activities are identified which together translate the Validated Mission Need and program Business Directives into a fully serviced DS Ready for Operational Use. This is illustrated in Figure 6.1.2.6-1. After operations, the DS needing support is returned for maintenance, with the necessary Feedback from Operations. This Feedback also allows for the assessment of system performance against the Current Requirement and Contract conditions. DS Data needed by others is provided as an output. Information on other defense systems and other topics of interest is provided as External Data.

 

Figure 6.1.2.6-1  (Diagram A0)


Arrows between boxes are deliberately defined at a high level to avoid too many lines. Decomposition of these arrows occurs at lower levels, and in the arrow definitions (See for example the decomposition of Program Directives within Diagram A1).

Box A1 generates four types of management instruction to control all work on the program. Two are used to manage activities within the model; two place actions externally. This first internal instruction is the Current Requirement, which consolidates and amplifies the VMN and Business Directives to the level of detail needed by the DS program itself. This Current Requirement is maintained over the full life-cycle and is used to communicate any changes (both actual and possible). The Current Requirement may diverge from the VMN if, for example, a decision is taken to accept a level of performance below that originally specified because insufficient funds are available to correct the shortfall. The second form of internal instruction is Program Directives, which are used to manage all activities under the direct control of the life-cycle owner. Two kinds of external instructions are also generated. Instructions to Operators define any necessary limitations on the use of specific systems arising from material shortcomings. Contracts and Requests (see A13) seek Goods and Services from others, as an input to the life-cycle processes. The requirement for contracts is established in part by analysis within A1 and by feedback of Required Items from A2 and A3. The information needed to monitor DS performance is fed back to A1 to control the overall process and to generate a Performance Report. A1 also provides the program SDE and Information Services as a resource to all program participants.

Box A2 undertakes the work needed to obtain a successful DS and provide a support capability. The scope of this work required can vary widely. At a maximum it includes all of the tasks needed to establish the system concept, design, produce, test and deploy the system itself and design, develop and commission a "special to type" support and disposal system, to provide in- service support. At a minimum, it could be limited to renting an existing system, owned and supported by a third party, for use by the Armed Forces. The Obtain function generates a DS ready for Operation, plus its "special to type" tools and facilities and all necessary spares and components. It also provides as an output, ideally through the SDE, all of the data needed to support the use of the system, including a prediction of its life-cycle performance. A2 also undertakes the refurbishment of Items returned from A4.

Box A3 provides the support needed to sustain the DS fit for operational use, including Operational and Servicing Tasks. Work is planned and executed as required by the Operational Program. Tools, facilities, spares, and information needed for this are obtained from A2 or from the Existing Infrastructure. Items no longer needed are returned to A4 for disposal or recycling. Feedback on maintenance activities and on evaluation findings is provided to A1.

Box A4 accepts the retired defense system and DS Items removed from service for disposal or refurbishment. Items for refurbishment or recycling are returned to A2. Items no longer needed are disposed of.


6.1.2.6.1  Establish and Control Defense System Program Through Life
Box A1 provides the control mechanism for managing the DS program over its life-cycle through four linked activities.

In Figure 6.1.2.6.1-1 (Diagram A21), box A11 translates and develops the Validated Mission Need, Business Directives, Usage and Support Policy, and other constraints imposed on the program by external authorities into a program Current Requirement. This Current Requirement establishes the performance and supportability characteristics that the DS program team is actually striving to deliver. It is maintained over the life of the system, in an accurate and up to date form, to communicate all approved changes. The Current Requirement includes all life-cycle support requirements such as life, readiness, supportability, and availability characteristics. It includes information on how the System will be used and maintained (a Use Study). Support Information is fed back from A2 to assist in developing the requirement. Proposed changes to the requirement are fed back from A14. Approved changes are communicated as updates of the Current Requirement.

 


Figure 6.1.2.6.1-1  (Diagram A1)


A12 highlights the need to develop and maintain a coherent set of policies and strategies for managing the DS program efficiently over its life-cycle. These are required to maintain consistency of approach to certain key functions and processes, in the face of changes to organization or responsibility allocation (e.g., the hand-over from acquisition to in- service management).

A13 establishes and directs the organization needed to deliver a successful DS. Three of the five outputs authorize work to proceed. Program Directives provide the resources and tasking instructions to the staff controlled directly by the Life-Cycle Owner (LCO). Contracts provide the same function for commercial organizations being tasked by the LCO. Requests for assistance are raised to place work, or seek changes or authorizations from Government or other non- commercial bodies beyond the program in question, including the owners of other DS.

A13 also undertakes the work needed to create and sustain the program Shared Data Environment (SDE), which is provided as a resource to all other activities. Information Services are also provided to meet any information needs that users cannot satisfy for themselves, through the SDE.

A14 assesses whether the DS program is meeting its objectives in relation to the Current Requirement and Business Directives, and instigates necessary changes. The predicted performance of the DS is provided from A2. A life-cycle cost estimate is provided by A134. Information on actual performance is fed back from Operations, from Maintenance and from Support Evaluations to identify the need for change. The assessment activity generates a performance report, noting any shortfalls evident and may result in change proposals affecting the requirement, the defense system, of the DS Program. This activity will also address the acceptability or otherwise of requests for waivers or concessions for components which fall short of the design intent.


6.1.2.6.1.1  Develop Life-cycle Strategies and Policy
Certain key processes can benefit dramatically from the power of the Shared Data Environment, provided they are managed over the life-cycle in a consistent manner.

In Figure 6.1.2.6.1.1-1 (Diagram A12), A122 identifies the requirement to develop address life-cycle issues when developing an acquisition strategy. The acquisition strategy must consider what role the original designers and suppliers will be expected to play after the initial acquisition, in order to identify what, rights, information and experience the through life support authority will need to acquire.

 


Figure 6.1.2.6.1.1-1  (Diagram A12)


A123 identifies the requirement to manage life-cycle risks from the program outset.

A124 covers the task of developing a strategy and high-level plan to ensure effective support is achieved, through the application of Integrated Logistic Support. The use of a Shared Data Environment, with a Concurrent Engineering approach and Multi Disciplinary Groups at last makes it truly possible to integrate logistic activities fully into the rest of the life-cycle.

A125 draws attention to the importance of Configuration Management, which, in a Shared Data Environment is both easier to do and has critical significance. The major CM data flows are illustrated in the TLBM. A125 is added to TLBM to draw attention to the need to develop a clear life time strategy for configuration management, as early as possible in the life-cycle addressing the requirements of all parties over the life-cycle who will need configuration data or make configuration changes.

A126 Quality Assurance over the life-cycle involves massive volumes of data and is crucially dependent on reliable access to historic records. Appropriate early action, linked to the development of the program SDE, offers the prospect for major improvements in quality through access to better data, and substantial reductions in quality related costs.

A127 highlights the requirement to invest significant effort in the analysis of the life-cycle information requirement, by developing a CALS Strategy. Full guidance on this topic is provided by the NATO CALS Concept of Operations (NCOPS), and is not repeated here.


6.1.2.6.1.2  Establish and Run the Defense System Organization
This activity defines what needs to be done to deliver a DS program to fully satisfy the Current Requirement (A131). It also identifies who will do the work (A132), establishing the necessary contracts (A133) and managing the three key resources needed to deliver the program: money (A134), people (A135), and information (A136).

In Figure 6.1.2.6.1.2-1 (Diagram A13), A131 defines the tasks to be performed and services to be provided, in response to the Current Requirement and Change Proposals and develops a Program WBS to define the necessary tasks. The WBS is also assumed to include the development of any Service Level Agreements needed to specify the standard of ongoing services. A131 also initiates the work needed to assess the impact of proposed change, and based on the results, decides whether to implement or reject the change. Approved changes are implemented by updating the WBS or Task list, amending the Current Requirement if needed. A131 also develops and publishes the high-level program plans needed to define when activities should be undertaken.

 

 


Figure 6.1.2.6.1.2-1  (Diagram A13)


A132 establishes how responsibility for the various program tasks is to be allocated over the life-cycle, develops an organization to undertake "internal" tasks, and raises the necessary contracts to obtain support from industry. A132 also generates requests for assistance from non- commercial external agencies, such as the Armed Forces or other DS programs. As roles and relationships will change over time, particular attention should be paid to the management of transitional arrangements (e.g., on entry into service). Having defined roles and responsibilities, A133 raises and manages any contracts needed to acquire the goods and services. Requirements for contracts are also provided from A2 and A3 as Required Items and from A136 (SDE requirement and Information to be contracted). The Performance Report is provided to allow assessment of contract achievement in relation to in- service use.

A134 acquires, allocates, and accounts for the funds that are needed to manage the DS through- life. This is assumed to include the task of forecasting and tracking DS life-cycle cost. (Financial information flows in the TLBM could be developed in more detail if required.)

A135 plans, organizes, monitors and controls, the provision of human resources for DS program life-cycle, including the issues of recruitment, training, reward and incentives.

A136 responds to the CALS Strategy by developing, deploying, and supporting through life, the Program SDE. It also provides any necessary Information Services to user, beyond those they can access for themselves through the SDE. This activity replaces the traditional task of publishing Technical Manuals, which are replaced by information provided through the SDE. Outputs are provided to A133 to define the information and IT products to be acquired by contract.


6.1.2.6.1.2.1  Place and Manage Contracts
Figure 6.1.2.6.1.2.1-1 (Diagram A133) briefly illustrates the major activities in placing and managing contracts. The requirement should be noted for historic data from other programs in developing a contract strategy (External data) and for significant feedback from maintenance and operations, to assess the performance of reliability or in service availability clauses. This is provided by the Performance Report. The proposals received in response to the ITT are treated as part of External Data.

 


Figure 6.1.2.6.1.2.1-1  (Diagram A133)



6.1.2.6.1.2.2  Manage Defense System Information
The extensive activities (Figure 6.1.2.6.1.2.2-1 (Diagram A136)) involved in managing information through life, in the context of a Shared Data Environment are fully described in the NCOPS to which reference should be made.

 


Figure 6.1.2.6.1.2.2-1  (Diagram A136)



6.1.2.6.2  Obtain Defense System
This element of the life-cycle covers all the activities needed to obtain an operational DS and its associated support capability. It includes four sub- tasks: Integrated Product Development; Production; Testing and Distribution that apply equally and concurrently to the operational system and its associated support.

In Figure 6.1.2.6.2-1 (Diagram A2), the Integrated Product Development activity (A21) converts the Current Requirement into a full definition of the system and its support products, from which the DS can be manufactured, tested and deployed. The activity also generates test definitions and evaluation criteria for the product and its support system, plans and processes for the deployment and operation of the support system (part of Support Info), Training Requirements for operating and support staff, a prediction of the DS performance and a requirement statement for the feedback needed from in- service maintainers and operators to asses life-cycle performance of the operational and support systems.

 


Figure 6.1.2.6.2-1  (Diagram A2)


A21 also develops a "make or buy" plan, which provides an output (to A1) of the items that need to be purchased. As development effort is needed through life to assess off- design conditions or to implement design change, a Change Impact assessment is fed back to A1. A22 turns the detailed Manufacturing and Refurbishment data, provided from A21, into physical products, either by manufacturing processes or by the receipt, assembly and integration of Goods and Services from others. The activity applies to the Operational System, to special- to- type tools, equipment or facilities required for support, to spares and components, to Items for Test and to Items returned for Refurbishment and re-cycling. The activity is taken to include all testing and quality assurance activities applied routinely to production items.

The Conduct Testing function (A23) is the process of comparing the actual performance of the system and its components with the specified technical performance specification and criteria. The result of this function is the specific test findings that are used to influence the decision(s) to move to the next phase of the WS life-cycle. Testing can be applied to any item, but will typically apply specifically to prototypes, first production items and development items related to product change.

A24 is the activity of deploying or distributing the Operational System, and all related items, from the production source to the operational, or normal storage, location. It includes the initial deployment of a newly delivered Operation system, the setting up of the special- to -type support capability, and the re-supply of spares and components used to support operations. The outputs are an Operation System, components, and spares, in their required locations and ready for operational use.


6.1.2.6.2.1  Develop Defense System
The activity of developing potential or actual solutions to the VMN starts as a response to the first issue of the Current Requirement by developing and selecting a DS concept (A211), Figure 6.1.2.6.2.1-1 (Diagram A21). External Data is required to allow alternative concepts to be explored and evaluated, in the form of necessary information on the performance, costs and risks of other DS options.

The DS Concept must address both operational (e.g., system performance capability) and support aspects (e.g., life, readiness and availability).

A212 begins the process of turning the concept into an engineered solution by defining a functional architecture for the intended system and defining the test and evaluation criteria against which solutions will be evaluated. Although this task will be performed early in the system life-cycle, it may need to be repeated many times in response to shortfalls of performance or proposed changes to the operational system or to its support. A212 also undertakes the work needed to decide whether various elements of the intended DS will be designed and produced under the direct control of the life-cycle owner, or be purchased by contract. Details of Required Items are fed- back to A13 for purchase planning and contract action. The Functional Architecture is fed forward to provide a start point for the engineering design.

The design of the Operational System and its related support is undertaken concurrently, by an MDG, through three linked activities: Engineering Design (A213), Failure Modes and Criticality Analysis (A214), and the design of the support system, through Logistic Support Analysis (A215). Engineering Design provides two outputs. The Core Product Data provides a definition of the product to the level needed for the purposes of support and operations. Core Product data includes the identity, version, definition, properties, classifications and characteristics of all parts likely to be exchanged during the in- service life and the assembly structure of the defense system (the Design Configuration) including permitted options and variants. A second output provides the additional data needed for production and refurbishment. The detailed models, calculations, and design data used to derive and justify the design are retained within A212, and are not made available to other program activities. For this reason a feedback loop is through A212 to establish the technical implications of any proposed changes, or off- design condition. A214 uses the functional architecture and product structure to identify failure modes, symptoms and effects as an input to LSA and as an aid to subsequent maintenance.

 


Figure 6.1.2.6.2.1-1  (Diagram A21)


The design of the DS support system, or LSA (A215), is undertaken concurrently with product design and failure analysis. They are shown separately in the model to only to illustrate the different outputs. In an SDE environment, it is expected that data from these three activities will be generated and managed in an integrated product data model within a CM or PDM system. This product data model is expected to provide the authoritative source for the information needed to support the DS in service, over the rest of the life-cycle. The data generated in these three processes should also be sufficient to avoid the requirement to writing additional Technical Publications. Structuring, formatting and distribution of information which is not directly accessible through the SDE is undertaken as an Information Service (A1253)

(A comprehensive IDEF model for logistics support analysis LSA process has been developed by the Norwegian Defense Forces, and is discussed in Section 6.2.)


6.1.2.6.3  Support the Use of the Defense System
This activity provides the support needed to bring individual systems into the condition required for operations.

In Figure 6.1.2.6.3-1 (Diagram A3), A31 defines the work to be done, based on the Operational Program, the Program Directives, and the support procedures within the Support Data. A31 also establishes the requirement for items to be purchased for use in support activities.

A32 provides storage, transportation, and issue as required of spares and other items needed for maintenance, based on the deliveries from A2.

 


Figure 6.1.2.6.3-1  (Diagram A3)


A33 undertakes the maintenance needed to restore the DS to the condition required for the next intended operation. This includes the activities of diagnosing, repairing, testing and calibrating the item in accordance with the Core Product and Support Data. The activity also includes the work needed to incorporate approved changes to the system configuration. Feedback from maintenance is provided as specified by Required IS Data, by recording the findings, action taken, spares used and issues arising. The AS Maintained (current) Configuration is reported to A31 (and elsewhere as needed) to reflect work undertaken. Items removed or no longer required are passed to A4 for disposal, recycling or refurbishment.

A34 undertakes any (non-maintenance) activities needed to prepare the system for operations, e.g., fueling, tow from hanger, empty waste tanks etc.

A35 maintains the support facilities and tools in a fit for use condition.

A36 provides operator and maintainer training, in accordance with the requirement from A215.

A37 evaluates the performance of the support system, in relation to predicted performance, in accordance with the definition provided from A212.


6.1.2.6.4  TLBM Activity Definitions
Activity definitions are included in Appendix C.


6.2  NATO CALS DATA MODEL (NCDM)


6.2.1  Introduction
NOTE: The entire NATO CALS Data Model (NCDM) is not published in this handbook. The Express language and Express Diagrams have been deleted. A complete copy of the NCDM can be downloaded from the NATO CALS Web Site http://www.cals.nato.be.


6.2.1.1  General
The NATO CALS Data Model (NCDM) is a formal description of the data required to support the logistics process for the acquisition and support of major systems. Such systems include aircraft, tanks and ships, and other complex products. The objective is to support the information required, used or provided by:

These three groups have had equal priority. This is necessary as the contractual boundaries between them are becoming increasingly variable.

This information has been covered by several existing standards, such as MIL-STD 1388, AECMA Spec 1000D and AECMA Spec 2000M. The NCDM takes an integrated approach to the data covered by these specifications but also recognizes the possibilities for other kinds of data such as design information and multi-media. It does so in a way that should enable current approaches to be followed while enabling richer and more effective new methods to be applied.


6.2.1.2  Technical view
The NCDM is meant to be used as the basic component of an Information Technology System Architecture that supports the concept of data accessible from multiple applications and business perspectives and that may be stored in and moved between multiple Information Systems.

The NCDM may be seen as the basic element of the three-layer architecture defined by the ANSI/X3/SPARC Study Group on Database Management Systems. In particular, such architecture may be described as follows:

As part of this architecture, the NCDM has the role of conceptual layer. It defines a common set of data definitions and data structures to support Defense System technical information management, throughout the life cycle, in the context of NATO nations and NATO industries.

It is meant to be used as the platform for the development of physical and external models, which are able to support data sharing, and data exchange.

The NCDM addresses the NATO requirement for data interoperability between different Information Systems by delivering a common data semantic and thus enabling consistency of interfaces at the information level without requiring standardization of hardware or software.


6.2.1.3  A Brief History
The NATO Acquisition Logistic Workshop (ALW) final report, in 1993, established the requirement for the development of the NCDM. From the ALW conclusions and recommendations:

"It is recommended that NATO assumes responsibility for the development of a consistent and stable set of data definitions (a single data dictionary) which is applicable to land, sea and air services and manufacturing industry"

The first effort concentrated on the harmonization of the data elements contained in three input Standards (MIL-STD-1388-2B, AECMA S2000M, and AECMA S1000D). This task was completed in 1996 and the NATO CALS Data Dictionary Version 1 was consequently published. The NATO CALS Pilot Project #1 Management Group decided at that point in time to proceed with the development of a database design model (e.g., IDEF 1X or similar model).

The modeling working group used EXPRESS as the modeling language. In doing this they had the opportunity to use the state of the art in Information Technology and Data Modeling (object-oriented languages and databases, multimedia, SGML).

An important element of the approach was that some basic Integrated Resources (IR) specified within STEP were incorporated directly in the NCDM, when appropriate. This is a very important feature of the NCDM, which means that data created in accordance with STEP can easily be integrated in the NCDM data set. In addition, adoption of STEP IRs will facilitate later migration to an ISO standard as recommended by the ALW.

The initial NATO CALS Data Model was created over a relatively short period of time and resulted in the publication of NCDM Version 2.02 in November 1997. This version was the base for the Industrial Rig Test which performed a cross check of the model by implementing it in relational tables in a Database Application. The result of the Rig Test was a list of issues and proposals for improvement.

The NCDM Version 3.00, published in May 1998, was the result of the revision of the model on the basis of the Rig Test Report.

The NCDM Version 3.00 has proved to be an outstanding NATO CALS product. It has been world wide appreciated for its innovative concepts of integration of design data, derived from the engineering design process, and the support data produced by the Logistic Support Analysis and Failure Mode Analysis. It has influenced the work done in the product data area around the world. In particular:

The NATO CALS Office has been collecting comments, issues and change proposals for the last year. Consequently, an initiative was started in September 1999 to analyze all requirements for changes and to produce an update version of the Model. The result is the NCDM Version 4.00, which is presented in this publication.


6.2.1.4  What is new in Version 4.00
The NCDM Version 4.00 takes a wider life cycle perspective and provides a better support for the Configuration Management process. While Version 3.00 was focused on the acquisition logistics data, Version 4.00 expands the scope of the NCDM to also include the management of Defense System Data during the operational life. Also important is that Version 4.00 is now able to capture and manage the user requirements defined in the very early stages of a program.

The following are the main new features of NCDM:


6.2.1.5  Motivation
Modern defense systems cannot operate without access to large quantities of technical information. This information is an asset as valuable and necessary as the defense system itself.

Today, technical information is created in digital form. This behaves differently compared to information on paper. The opportunities are enormous, but new problems and risks are at the same time introduced. A major problem arises when multiple organizations need to use the same information. Differences in data definition and data format block communications between partners and require development of expensive interfaces. Too often, data is locked into the application in which it is created forcing the use of proprietary solutions. As a result, many IT systems, which ought to be offering business improvement act, in practice, as barriers.

To address the above issues, the NATO CALS Data Model (NCDM) defines a common set of data definitions that can be used to achieve consistency of interfaces at the information level without requiring standardization of hardware or software. The role of the NCDM is to standardize content of a life-cycle repository for defense system technical information with the objective that Armed Forces with different Information Technology infrastructure, e.g., different hardware and software platforms, can make use of the same technical information.


6.2.1.6  Information Modeling
Raw data is not information. Two parties can only exchange data in conjunction with an agreement on the meaning of the data. Consider the number "1964." This number is data without information. The data becomes useful if we add the information that it is a year (1964), or the number of people attending the 98 CALS Europe Conference. Although the data is the same in both cases, the information is different.

An information model addresses the underlying meaning of data regardless of technology. A model describes meaning through structure and correctness constraints. It does not specify encoding techniques for data values.

The NATO CALS Data Model uses EXPRESS as a formal language for specifying information requirements. EXPRESS is an ISO standard (ISO 10303-11) and has been used by STEP, POSC and other projects to describe the information requirements of many engineering activities.

The function of EXPRESS is to describe information requirements and correctness conditions necessary for meaningful data exchange. An EXPRESS information model is organized into schemas. The NCDM, for instance, is organized in ten schemas. These schemas contain the model definitions and serve as a mechanism for subdividing large information models. Within each schema, there are three categories of definitions:


6.2.2  How to Use the NCDM


6.2.2.1  Specifying Information Requirements.
An information model is an agreement on the meaning of data. This agreement is represented in a formal manner using an appropriate descriptive language (e.g., EXPRESS). An agreement is a "mutual understanding or arrangement between parties." The parties, in our case, are the Defense Industry and the NATO Armed Forces. The agreement defines WHAT data will be exchanged and what is the MEANING. In a data model the meaning of data is conveyed by the data structure and relationship. How data is created by the industry and how it is used by the single Armed Force is not part of the agreement. The processes and software applications that make use of the data are not part of the agreement either.

The NCDM can be used to specify the technical information needed by the NATO Armed Forces to support a defense system in service, through-life. From the project manager perspective, the NCDM can be used to identify data requirements for a specific project. The utilization of the NCDM in this sense is very similar to what is done today when data elements are contracted according to legacy standards (e.g., MIL STD 1388). The advantage of using the NCDM resides in the quality of the contracted data. The model gives an integrated view of data where design data like system physical and functional breakdowns are integrated with support data and with the data needed to make technical documentation available.

Text appearing as [Arial roman italics] in the following paragraph is provided as a sample language that can be used in developing the data requirements for a Request For Proposal (RFP) or Request for Quotation (RFQ) SOW.


6.2.2.2  Defining a Common Vocabulary
There is a flow of information (e.g., Defense System Technical Information) between the industry, originator of the data, and the Armed Forces, users of the same data. There could also be a need for data exchanged between Armed Forces of different NATO nations. When parties with different software and hardware platforms need to share the same information, the need for interfaces arises. These are sophisticated and expensive software that acts as `translators' between different systems.

 


Figure 6.2.2.2-1  Number of Interfaces Without a Common Vocabulary


As illustrated in Figure 6-2-1, the number of director translators between systems grows as N(N-1) where N is the number of systems. The NCDM can be used as a common vocabulary, agreed by the Defense Industry and by the NATO Armed Forces, to dramatically decrease the number of interfaces. In this case the number of interfaces only grows as 2N.

 


Figure 6.2.2.2-2  Number of Interfaces Using the NCDM as a Common Vocabulary



6.2.2.3  Implementing an Integrated Product Database
A Data Model can be implemented in a database. An EXPRESS data model is technology independent and can be implemented in a variety of databases (e.g., Relational, Object Oriented, and hybrid). For this discussion we assume that the model is implemented in a relational database (e.g., SQL SERVER, ORACLE, INFORMIX etc.).

The strength of relational systems is in their ability to store large amounts of data in a highly normalized, tabular form, and to perform efficient queries across large data sets. Relational systems use SQL for both data definition and data manipulation.

Unfortunately, EXPRESS does not include a construct to create relational tables automatically. A method of mapping the NCDM to a relational database was experimented during the Rig Test.

In this method, each entity is mapped to a table with columns for attributes. Each table has a column with a unique identifier for each instance. Attributes with primitive value are stored in place and composite values like selects, and aggregates are stored as foreign keys containing the corresponding unique instance identifier. Inheritance is normalized out of the tables. The table for each entity type contains the local attributes defined by the entity and uses the instance identifier as the primary key. A complete entity instance, with all inherited attributes, can be reconstructed by a join on the identifier across all tables in the type hierarchy.

Other conflicts that ought to be addressed to implement the NCDM in a relational database are the following:

Potential users of an Integrated Product Database build around the NCDM are the Industry, Defense System project teams and the NATO Armed Forces.


6.2.2.3.1  In the Industry
The need for the industry to integrate their engineering processes around integrated product database is becoming more and more evident. Engineering applications have unusually complex information models. These information models are complex because engineering applications manipulate simulations of the real world. Models for areas such as CAD geometry, tolerances, materials, and manufacturing plans are structurally and semantically rich. Applications are similarly complex, and are tightly bound to the models. Often, the information exists only as program language structures taken from a primary application, usually a PDM or CAD system. Subsequent applications must be modified whenever the primary application changes. The resulting situation is that only special-purpose databases, controlled by PDM and CAD vendors, are used to describe complex products. Designers and Manufacturers do not have any control over their product databases, which is clearly undesirable for strategic reasons. Also, the customers' request for complex design data together with the logistic support information in an open format accessible by off-the-shelf DBMS, is not easily addressed.

To overcome the above problems, design and manufacturing companies need to integrate their engineering processes around product databases.

 


Figure 6.2.2.3.1-1  Integrated Product Database Data Sources


The term "integrated" refers here to "the process of reconciling data from many different sources so that the resulting collection can be managed consistently with minimum redundancy."

Some of the technical opportunities are:


6.2.2.3.2  In a Project
A major value of an Integrated Product Database is that it can support remote access by any authorized user. The project team can make use of this feature to obtain ready access to the data while it is created. The advantages of this are obvious, for instance:

Text appearing as (arial roman italics) in the following paragraph is provided as a sample language that can be used in developing the data requirements for a Request For Proposal (RFP) or Request for Quotation (RFQ) SOW:


6.2.2.3.3  In the NATO Armed Forces
Several NATO nations are investing heavily in major IT infrastructure programs to improve logistic support for their armed forces. The NATO CALS Organization does not intend to recommend a specific hardware or software solution that all the various parties would be required to adopt and integrate with their existing infrastructure systems. Clearly, the definition and development of Information Systems is a national responsibility.

However, the NATO CALS Organization does recommend the use of the NCDM as the conceptual model for individual nation Information Systems. The benefit of such an approach is that, through the use of the common conceptual model, data can be accessed and moved between different information systems (see Paragraph 1.2), hence between different NATO nations and NATO industries. The definition of common data semantics is the NATO CALS Organization addresses the requirement of NATO information interoperability in the area of defense system technical information.

Furthermore, the NCDM, by standardizing at the information level, offers the opportunity to define an Information Infrastructure built around a "Defense System Technical Information Database." The benefits of such repository of technical information for all the available weapon systems are self-evident. Benefits that are even more dramatic could be achieved if the Defense System Technical Information Database is implemented in a consistent way across NATO by all Nations. In this case, the realization of a NATO Distributed Database for `Defense System Technical Information' will be achieved. NATO Nations working together (e.g., Combined Joint Task Force) could then be allowed to access each other weapon system technical database on a need to know basis.


6.2.2.4  How to Implement the NCDM
As said in Paragraph 1.2, the NCDM could be used as an interoperability platform to develop physical models, external models, databases and Information Systems. The following diagram loosely follows IDEF0 notation and illustrates the activities required to build an IT system on top of the NCDM.

 


Figure 6.2.2.4-1  Building an IT System on Top of the NCDM


The boxes in the diagram represent activities to be performed; the arrows are components of the system that should be available to perform the activities.

By delivering the NCDM, the basic component of the system, the first activity is completed. A common "vocabulary" is in place. All the other components are grounded on the NCDM but are equally essential and need to be developed by the organizations willing to implement the Information System. It should be stressed that, to achieve interoperability between programs and between NATO Armed Forces, it is mandatory that the NCDM is used as the conceptual model in the development of national IT solutions.


6.2.2.5  To Create a Physical Model
In order to implement the NCDM, a set of implementation guidelines must be developed. The NATO CALS Office is developing this for NATO programs and NATO nations based on the following approach, which could be followed by any organization trying to implement the NCDM.


6.2.2.5.1  The Requirement


6.2.2.5.2  The Method

 


Figure 6.2.2.5.2-1  Developing Implementation Guidelines


A more detailed description of this method, including examples of results is available. The complete Implementation Guidelines for the selected module will be available from the NATO CALS Office by autumn 2000, subject to distribution limitations.


6.2.3  Model Overview


6.2.3.1  The High Level Model
A very basic simplified view of the NATO CALS Data Model is shown below:

 


Figure 6.2.3.1-1  Abstract View of the NCDM


This can be interpreted as follows:

The diagram loosely follows the conventions of the EXPRESS-G language (formally defined in ISO 10303-11). For the present purposes, the diagram can be read as follows:


6.2.3.2  Model Organization
The NCDM Version 4.00 includes ten schemas covering the following areas:


6.2.4  The Core Model (CoreModel)


6.2.4.1  Overview
The core of the model centers on the following:

To introduce this part of the model it is important to clarify the approach taken by the NCDM to deal with the concept of product. The STEP standard defines a product as: "a thing or substance produced by natural process or manufacture". The STEP definition seems to imply that a product is always a physical, actual (e.g., produced) thing. This is not the case in the life cycle perspective.

In the very early phases of a project, a product is just an idea (a product concept) described by its expected features and functionality. The definition of product in this case would be "the idea or concept of a thing or substance that may be designed and produced by natural process or manufacture to meet the customer requirements."

From the design process perspective, later in the life-cycle, a product would be "the design of a thing or substance that may be produced by natural process or manufacture". Finally, following the manufacturing process, and during its operational life a product would be "a thing or substance produced by natural process or manufacture."

The three definitions above reflect three different life cycle views of a product, the as-required, the as-designed and the as-built/as-used views.

To deal with these different views, the NCDM does not take the STEP approach to generalize the multiple life-cycle views under the single concept of product.

The NCDM re-use the STEP product data definitions and constructs (e.g., product, product_definition_formation, product_definition etc.) to manage the AS-DESIGNED view. The AS-REQUIRED view is covered by the Entity product_concept and its associated specification (see Configuration Schema), while the AS-BUILT/AS-USED view is managed by dedicated data structures collected under the Entity product_instance_definition.

In the NCDM, the three views have a very loose relationship: each one of the three may exist without the others. This approach allows for implementation flexibility of the model in different business context and scenarios (e.g., an organization manages a product instance but doesn't own the product design).

However, the expected cardinalities, in an ideal implementation, are that (1) a product_concept is related to zero, one or many product_design(s) (inverse: one product_design is the solution for exactly one product_concept); (2) a product_design is related to zero, one or many product_instance(s) (inverse: a product_instance is the realization of exactly one product_design).


6.2.4.2  Description


6.2.4.2.1  Product Design
The starting point is STEP Entity product. From STEP the NCDM follows the convention that the product entity represents the core concept of a product design, i.e., its identity, and not the information which is associated with the product. Such information includes the identification, any versions, and any more information, which defines some things about the product. These two concepts are handled as separate entities. This gives the starting point for the model as below:

 


Figure 6.2.4.2.1-1  The Product Entities


This enables there to be many versions of a product and many definitions for that one product. The latter is reasonable because a product_definition is taken to be a collection of data that defines the product design for a given purpose. Hence, we may have several different product definitions for logistics purposes.

In fact, two different kinds of product definition are allowed for in the NCDM. One of these is aligned with the STEP standard. With this approach, the relationships of an assembly to its parts are captured explicitly so the product definition for any assembled part becomes a network of related product definitions. The other type of product definition is common in logistics, where a single breakdown is used for a product/system and all its constituent parts/functions. It is important to note that the NCDM does not require one form over the other, nor does one have to be created before the other.

Product Design Structure
This part of the model is taken with a small number of changes from STEP integrated resources (ISO 10303, parts 41 and 44). The main part of the model defines a network of related product definitions, where the definition of an assembly is linked to the product definitions of the parts used in the assembly through the product_definition_usage entity.

 


Figure 6.2.4.2.1-2  EXPRESS-G of Product Design Structure


In practice, assembly is almost always handled using the next_assembly_usage_occurrence entity. This captures the fact that one part (or rather a product_definition for the part) is used as a component in an assembly (or rather the product_design_definition of the assembly). Graphically this can be seen below.

 


Figure 6.2.4.2.1-3  Product Design Structure Presented as a Tree


The name attribute of the next_assembly_usage_occurrence should be used to hold an identifier for the particular place where a component is used. (This corresponds to the use of two different LCN's to deal with, for example, the Left and Right placements for a pump used twice in the same engine.) This situation is shown in the figure below where two next_assembly_usage_occurrence entities point down to the same component.

 


Figure 6.2.4.2.1-4  An Instance of a Product Design Structure


Product Structure for Logistic Breakdown

There are several different breakdowns used for logistics purposes. These include:

All of these basically define a hierarchy and are treated the same way in the NCDM. The starting point is the breakdown entity (a kind of product definition), which identifies the specific breakdown by name and description (all product definitions have these) and gives the type of breakdown (e.g., "functional"). A number of standard types are allowed for in the NCDM and additional types may be specified. The breakdown entity also points to the starting elements in the breakdown. (Usually for a breakdown with a single root there will only be one starting element.) Thereafter additional levels of breakdown are specified by the use of element_relationship entities. Both the EXPRESS-G and an instance are illustrated below.

 

Figure 6.2.4.2.1-5  EXPRESS-G of Breakdown


The breakdown entity has an attribute called "form" which is used to state the form of logic, which has been applied in creating the breakdown. Several standard values are provided for this as well as the opportunity to define "non-standard" forms of breakdown. The standard forms are catalogue, functional, hybrid, physical, system, and zone.

This indicates the criteria used by the logistics engineer in specifying the elements in the breakdown. Note that hybrid form implies a combined physical/functional breakdown and should not be used for other combinations.

Each element in the breakdown has an identifier. This is the position in the NCDM, which can be used to hold the LCN. There is a separate element_definition entity referenced from the element entity. This allows the use of a common definition (without duplication) for two elements in different breakdowns. Thus, a common set of element definitions can be consistently applied to several breakdowns within a single system or across multiple systems. This corresponds to the use of standardized logistics terms by a particular armed service or other organization. Perhaps somewhat confusingly, each element definition also has an optional form attribute. This is necessary when hybrid breakdowns are defined and enables the nature of a given element in the breakdown to be determined (i.e., is it functional or physical).

The standard values for this attribute are:

There are two specific subtypes of element. These are:

The links between elements are captured using the element_relationship entity. This is also true of the links between levels of indentation in the traditional LCN numbering scheme. Thus for the following LCN breakdown:

id

Name

28

Fuel system

2801

Fuel storage system

2802

Fuel pressurization

 

There will be an explicit element relationship between the element with id 28 and that with id 2801. (Note it is also permissible to make the id of the fuel storage system element 01. The fact that the fuel storage system is a part of the fuel system is captured by the explicit relationship and so there is no longer a need to repeat the "28" in the id of the fuel storage system element.)

There are several types of element_relationship defined in the NCDM. These are necessary to capture all the different links established in the breakdowns currently used for logistics, in the MIL-STD-1388 LSAR or in breakdowns established for catalogues and manuals.

The following types of element relationship are allowed:


6.2.4.2.2  Product Instance
The data structures collected under the Entity product_instance_definition are dedicated to the management of the AS-BUILT/AS-USED view of the product.

A product_instance_definition is optionally related to exactly one product_concept and to exactly one product_design_definition. It may be associated with a person and/or organization with a specific role (e.g., owner, custodian, user, driver, pilot, etc.) through the entity product_instance_organization_association. Additional information about the association is the date when the association was established and the date when it was ended. History of product instance ownership, for example, may be derived by screening the start_date and the end_date attributes. The current ownership is identified by the entity instance whose end_date attribute is empty. A product_instance may be associated with a location.

Product Instance Identification

The subtypes of the Entity product_instance_definition are related to the three different types of identification of a product instance. In particular, a product_instance may be identified by:  (1) a serial number; (2) a lot number; or (3), for some types of material, just by a name. A globally unique identifier consisting of the organization code and the serial number/lot number must be used.

 


Figure 6.2.4.2.2-1  Identification of Product Instances


During the in-service phase, the user may need to issue additional identifiers to product instance (Tail, Plate numbers) in order to manage them within the user management system. In this case, the Entity alias_identification shall be used to link the user defined identifiers with the unique product instance identifier as defined above.

Product Instance Breakdown Structure

A product instance breakdown structure is handled using the Entity product_instance_physical_decomposition.

 


Figure 6.2.4.2.2-2  Product Instance Breakdown


This entity captures the fact that one part (or rather a product_instance_definition identified by a serial number) is used as a component in an assembly (or rather another product_instance_definition also identified by a serial number). The entity product_instance_substitution together with the attributes date_installed and date_removed may be used to maintain a record of the product instance configuration history.

Product Instance Maintenance History

The maintenance history is essential not only to plan the support activities of a product instance but also to plan its operational use. The logistic_activity is a subtype of the Entity activity defined in the Configuration schema. From activity, the Entity logistic_activity inherits the attributes describing the who, when and what of the activity.

 


Figure 6.2.4.2.2-3  Product Instance Maintenance History


The attribute associated_task_definition is defined as optional to deal with the case where a task definition is not available.

Product Instance Usage History

An important parameter to manage and support a product instance is usage history.

 


Figure 6.2.4.2.2-4  Product Instance Usage History


The basic entities in this diagram are product_instance_definition and usage_metrics_parameter. The latter collects all the different parameters and the detection method needed to assess the current usage status of the product instance.

The intersection table between the two entities is used to capture detection dates and the detected values.


6.2.4.2.3  Crossing between Breakdowns and Product Design Structure

Not surprisingly, it is extremely useful to be able to cross reference between the breakdown and element structures. It is unlikely to have individual breakdowns for many components (and systems) used in a given large product. Instead, there will be elements in the breakdowns that correspond to either components or sub-assemblies. Similarly, it is necessary to know which components together provide a certain function in a functional breakdown.

The product_definition_element_relationship entity provides a general link between an element and a product_definition or a product_definition_usage. The reason why it is either a product_definition or a product_definition_usage is that an element (corresponding to an LCN) may refer to either the use of a component (or sub-assembly) that occurs only once, or the use in a particular position of a component (or sub-assembly) that occurs more than once.

The product_definition_element_relationship entity simply establishes a link. A subtype of product_definition_element_relationship called element_realisation is used to assert that the product_definition is the corresponding product in the case of a physical element (LCN) or provides the function for a functional element (LCN). Note that several product definitions can be realized by the same function (i.e. they all point to the same one). Equally a single sub-assembly may have several functions and so can be linked to several elements in a functional breakdown.

In some cases however, a part may realize a function only in the scope of some overall function. In this case the realisation_application entity can be used to show the function or other types of elements for which the realization is valid.


6.2.5  Configuration


6.2.5.1  Overview
The configuration schema deals with:


6.2.5.2  Description
In simple terms, Configuration Management (CM) is the process of defining and controlling the identification of a product, its structure and related items.

The NCDM provides the capability to define and manage the configuration of complex items, over their full life-cycle, to the serial number level.

Accurate, timely information concerning the configuration of a product and its related items is needed throughout the life cycle to achieve cost-effective manufacture, continued safe operation and efficient in-service support. However, the level of effort applied to Configuration Management will vary with business circumstance. In some applications it may prove necessary to control the configuration of each instance of the product to a high level of accuracy to ensure safe operations (e.g., flight safety, nuclear plant). In other circumstance, where errors can be more readily accepted, configuration control may have a more limited scope. The level to which configuration management is applied to any specific product will remain a business decision and is captured using the entity configuration_item.


6.2.5.2.1  Configuration Items
Configuration Items are items to which an organization intends to apply Configuration Management control. The identification of the Configuration Items is dependent on viewpoints. Different life-cycle organizations may have different views over which configuration items they need to manage.

 


Figure 6.2.5.2.1-1  Example of Configuration Item Responsibility


The simplified Express G below indicates the main relationships of the Entity configuration_item.

 


Figure 6.2.5.2.1-2  Configuration Item and Related Entities


A configuration_item is normally related to a product_concept. This attribute is optional in the model to deal with the situation where a product concept is not available.

The Entity configuration_item_solution links configuration_item with publication, product design or product instance with a many to many relationship meaning that the associated product data are to be managed under configuration control.


6.2.5.2.2  Configuration Change
Configuration change provides a controlled and systematic way for the implementation of Engineering Changes. Fundamental to Change Control is the concept of management by baselines.

This concept assumes that, at certain point in time, there must be a recognized, documented and formally approved configuration baseline (requirement, product design or product instance baseline) and that any later change will be documented so that the current status of the system is known at any time.

When considering a Product Data Management system, this concept raise a practical problem:  as the data model may contain thousands of interrelated instances, it is impossible to know what are the actual boundaries of a baseline. (e.g., if a part belongs to a baseline, does a part that is derived from it, belong to this baseline?)

The principle chosen by the NCDM is to cover the baseline requirements is the following manner:

Implementations of the NCDM shall enable users to select all relevant product data when defining baselines selecting the appropriate approval_assigned_item (see NCDM_approval schema).

Configuration Change Control is the process to manage preparation, justification, coordination, disposition and implementation of proposed engineering changes and deviations to effected Configuration Items. This process is supported by the Entities work_request, work_order and activity. The simplified Express G indicates the relationship between the three entities.

 


Figure 6.2.5.2.2-1  Activity and Related Entites



6.2.5.2.3  Product Concept
A product concept is the idea of a product as conceived by the user. Definition of Product concepts will often be driven by user's needs and by the user defined usage scenario. It represents the idea of a product based on the user viewpoint. The basic relationships are showed in the simplified Express G.

 


Figure 6.2.5.2.3-1  Product Concept and Related Entites


A product_concept is defined within a specific context or scenario. This relationship is a many-to-many since the same product_concept may have many usage scenarios and a usage scenario may apply to many different product_concept(s).

Product Concepts are characterized by the user defined specifications. A specification may be a characteristic of more than one product_concept using the Entity product_concept_specification_association.

 


Figure 6.2.5.2.3-2  Specification and Specification Category


A specification refers to a specification_category that completes the semantics of the specification. Examples:  "'red," "'blue," "yellow" are specifications belonging to the specification_category "color," "disk brake"' and "drum brake" are examples for specifications belonging to the specification_category "braking system."

A specification_expression is a combination of specification objects formed by Boolean operations.

 


Figure 6.2.5.2.3-3  Specification Expression


The attribute operation specifies the kind of Boolean operation. Four kinds of operations are permitted:


6.2.6  Failure Analysis (Anomaly)


6.2.6.1  Overview
An anomaly is a reason for doing something. There is something about the product that is not how it should be and so work must be done

Traditionally logistics has been driven by the Failure Mode Effects and Criticality Analysis (FMECA). The model does not start with Failure Mode because there are more general reasons for defining tasks than Failure. As an example, the availability of a new software upgrade is not a failure but does give rise to tasks. Hence, the name product_anomaly is used simply to indicate that not all is as it should be with the product (e.g., in the previous example, the software is not at the desired release and so is anomalous). However, the model does provide for two specific types of Anomaly: Failure and Damage.

The NCDM treats the propagation of anomalies differently to the legacy standards. Instead of following the logic dictated by the breakdown(s) being used (such as a functional breakdown), it captures the cause-effect relationships. Thus, the effects of a given failure can be traced in a manner that reflects the real physics and its equivalent functional impact.


6.2.6.2  Description
The obvious starting place is the product_anomaly entity. As explained above there are two specific types of anomaly identified. These are failure_mode and damage. Failure results from a physical problem of the product concerned while damage is externally caused. Damage is treated as a special type of failure_mode. Either of these can also be specified as a failure_mode_from_a_specified_source, which allows the source to be identified. This is to allow for failure_modes defined in standard references, such as the predicted failures for certain types of printed circuit boards.

Now for each failure, we may get some effects. These can be seen as falling into two major categories: local symptoms (for example, increased engine smoke) and other failures (for example, failure in an oil-pump bearing leading to failure of the engine).


6.2.6.2.1  Effects
Local symptoms are captured using the effect entity. This allows the effect to be described. Effects are specified as an entity so that the same effect can be shared across multiple failures. (This also allows the query: "show me the failures that have this effect").

There is no direct link from failure_mode to effect. Instead, there is the mode_effect_assignment entity which allows for an effect to be associated with a failure_mode or with a combination of a failure mode in an operational phase. Thus, the fact that the effect of a landing gear failure mode is different during taxi than flight can be captured.


6.2.6.2.2  Causal Relationships
Traditionally the means to document a failure has been to capture its cause/effect via a functional or hybrid breakdown. The NCDM allows the direct cause/effect relationship to be captured, independent of the breakdown. The NCDM provides a general relationship entity between anomalies. This is then subtyped to be the consequential_failure_relationship. At a simple level the use of the consequential_failure_relationship is as shown below.

 

Figure 6.2.6.2.2-1  One Anomaly Caused by Two Others


This figure says that failure modes 1 and 2 act as the causes of failure mode 3. In this case, failure mode 3 will be specified as a consequential_failure_mode (a subtype of failure_mode). It is possible that failure modes 1 and 2 are primary failures (the start of a cause-effect chain) in which case they can be specified using the primary_failure entity. Alternatively, one or both of them could be consequences of other failures.

Primary failures have a cause_description attribute, which refers to a separate entity (cause_description) to allow a common set of fundamental causes to be re-used across many failure modes. Examples of such a cause description could be cracking through fatigue or personnel error.

Now life is not always so simple and it may be that a particular failure will occur only if two other failures occur together or if a third failure occurs on its own (not with the first two). This accumulative logic, showing what combinations will occur, is known as roll-up.

 

Figure 6.2.6.2.2-1  Example of Failure Roll-up


Altogether there are three types of roll-up relationship allowed for:


6.2.7  Task Descriptions (Task)


6.2.7.1  Overview
The NCDM breaks away from the traditional view that a task is solely a sequence of steps that has to be followed. Firstly, a distinction is made between what the objective of the task is and the (one or more) ways that the objective can be achieved. In very simple terms the "what is to be done" and the "how to do it" are separated. Why? So that different methods can be defined according to the situation. It is clear that different approaches will be taken to do a given job in the field or in a well-equipped base, or in the arctic versus the desert. Even differently trained personnel and the laws and other restrictions that apply may affect how the same job is done.

Once this immediate separation is made, the NCDM also allows for different approaches to do a task rather than just a pure sequence of steps. The existing approaches made use of free text plus labeled lines to allow for some sequencing changes (such as taking different routes if a test was passed). However, this meant that an entirely separate and additional functionality (use of IETM approaches) was required if this variation was to be used in a computer-sensible way. Hence, the NCDM provides facilities, which enable the way a task is done to be "programmed." This is effectively equivalent to a simple programming language, rich enough to enable IETM style functionality to be provided directly from the database that corresponds to the model. (Note that it is still possible to use textual descriptions only, as in the existing MIL-STD-1388 task narratives. However, this reduces the potential advantages of using the NCDM.) Thereafter, the other main component of the task area of the model is concerned with the resources necessary to do the job.


6.2.7.2  Description
The more detailed description is divided into the two areas: what to do and what is used to do it:


6.2.7.2.1  What to do
The task entity is used to identify something that needs to be done. It has a subtype, logistics_task, which carries additional information, such as criticality and maximum time. Neither of these entities includes the reason why the task has to be done, some kind of anomaly, or the way in which it can be done. The way in which a task can be done is captured through the task_method entity.

The link between them is given by means of an instance of the task_method_assignment entity (or its subtype, the task_method_relationship_with_context). One or more task_methods can be associated with the same task. By using the task_method_relationship_with_context, these can be shown to apply in different scenarios. Hence, it is now possible to allow for the different ways in which the same task will be achieved in varying climatic conditions or by different organisations (with different skill-sets or even different legislation applying).

The most complex area of the task part of the NCDM is the handling of how a task is done, i.e., task_method. The first thing to realize is that it is still possible to give a simple narrative description of how a task is accomplished. This is achieved using the logistics_task_method subtype of base_task_method entity. The text is then given as the value of the representation attribute. (The reason it is called a representation is that other forms of description, such as video, can also be given.)

If, however, it makes sense to divide the task up into some series of stages, each stage will also be documented using the base_task_method entity. At this point, it may also be necessary to designate some of the stages as being warnings. This is done using the advisory_task_stage entity, which is a subtype of the base_task_method entity. Having separated the stages of the task method, it becomes necessary to join them back up to form the method for a single task. This is achieved using the structured_task_method entity and its subtypes.

We will start with the simplest case, that of a sequence of stages which has to be followed. A task_method_sequence is used to specify a list of stages. This is one type of structured_task_method. The ordering of the stages is captured through the use of a List for the methods attribute. There is no sequence number stored so additional stages can be inserted without recourse to renumbering. A second advantage of this approach is that the same stage can be called out by several task_methods without having to duplicate the description of the stage.

 

Figure 6.2.7.2.1-1  Task Method Sequence

This is a simplified view in two major respects:

Both of these are aimed at two significant requirements: the reduction of duplicated descriptions (by enabling sharing of the same information) and the intelligent (electronic) processing of task descriptions (so that the LSAR can act as a direct source for interactive manuals).

Now it is appropriate to look at all the options for structuring tasks:

Together these provide a capability not unlike a simple programming language so that tasks can be structured flexibly and tracked or presented intelligently.


6.2.7.2.2  What Is Used To Do The Job
The other key area associated with tasks is the resources necessary to complete the task. Here the model centres around the link from the task to the resource. This is captured through the task_resource_requirement entity. This essentially says: "here is the resource needed for this task." It has a subtype, which allows for the quantity of the resource to be defined. Otherwise it is assumed to be "one of" the resource.

There is a possibility to describe the requirement for the resource, to specify why it is needed and the role that it will play in the task. The likely roles are: Spare parts, consumable, test equipment, labour, safety equipment, calibration equipment, etc. The value for role is given as a separate entity, enabling a standard set of values to be defined by a given project/organization and referenced rather than duplicated.

The NCDM allows additional tasks to be associated with required resources. Thus if a particular piece of equipment has to be calibrated before use, the calibration task can be given as a supplementary task for using the equipment. (As a consequence of this, calibration and similar tasks are not treated differently from any other task in the NCDM.) Such a supplementary task can of course have additional resources associated with it.

There are the following types of resource identified in the NCDM:

Note that products (identified by a product_design_definition) may play several different roles in a task so an item can be a spare part and a resource for use in testing.


6.2.8  Technical Documentation (InfoObj)


6.2.8.1  Overview
The basic viewpoint taken by the NCDM is that there will be all kinds of additional information connected to aspects of the system/product data. Possible information types include:

In fact, there will be such a variety that no attempt has been made to sort these types of information into pre-defined buckets. Instead, the NCDM provides a kind of library facility for holding information and linking it to the detailed information covered by the rest of the model. Such links may be very general in nature, simply indicating some relevance of the document.


6.2.8.2  Description
The information object area of the data model is very general in that it can be used to support several different processes. Some of these are identified below by listing the input, controls, etc. An additional column identifies the suggested target for an information link from the resulting information object(s).

 


Figure 6.2.8.2-1  ICOM Notation

 

 

Input

Control

Mechanism

Output

Linked to

 

Task and task method, resources, etc.

AECMA 1000D spec

Technical writer (person)

One information object containing the Data Module according to 1000D DTD.

Task method assignment,
Product

 

Task and task method, resources, etc.

Various (could be AECMA or in-house defined format)

Query and report function

Two information objects, one containing the task description and one containing the parameters/instructions for the query/report.

Task method assignment,
Product

 

Task and task method, resources, etc.

Various (could be AECMA or in-house defined format)

Query and report function

One information object, one containing the parameters/instructions for the query/report.

Task method assignment,
Product

 

Many tasks and associated data

Various (could be AECMA or in-house defined format)

Technical editors and/or report generators

Publication collection equivalent to a maintenance manual.

 

 

These can be described as follows:

This is roughly how the information object part of the model is structured:


6.2.9  Logistic Support Analysis (LSA)


6.2.9.1  Overview
The descriptions given above cover the major elements of the NCDM. There is however much more to logistics data. There are many aspects allowed for in the model, which have not been described so far. In particular, two further areas merit description here:


6.2.9.2  Description


6.2.9.2.1  Scenario and Role
In the NCDM allowance is made for the likelihood that a system may be supplied to different customers who may not only use it in different ways and environments but may also have different resources (such as personnel skills) and different policies on maintenance. However it is inevitable that the same failures will probably occur and that many tasks will be common. (E.g., the NH90 helicopter is intended for 11 different services across 4 nations.) Rather than force a separate copy of the database to be developed for each customer, the NCDM provides for these differences through the scenario entity. This is then used in many places as the context for assignments (such as a task to a product) to indicate that the assignment is applicable in the scenario.

As a further refinement to this, the system may have multiple roles (for the NH90 these could be submarine warfare, search and rescue, etc.), which lead to different maintenance requirements. A scenario may include several roles.


6.2.9.2.2  Characteristics
It became clear during the creation of the NCDM that there is an enormous amount of data, which is covered by the existing legacy standards that is attached to the key ideas of product, anomaly and task (and the relationships between them). The data provides for many characteristic values, varying from the familiar ideas, such as mean time between failure to much more obscure values. Furthermore, many of these are provided twice (in the LSAR), once as a requirement (from the assumed single customer) and later as a predicted value (provided by the system/equipment supplier). However, in the NCDM, these values can be specified as requirements by different organizations (i.e., applying in a different scenario). Furthermore, taking a view that goes through the life of the product, a measured value (based on fact rather than prediction) may also be provided.

Given the potential number of such characteristics (see the combined data element lists of the legacy standards), the NCDM takes a more general approach. Firstly, a characteristic (or one of many subtypes) is used. In general terms, this defines a name, description and value.

 


Figure 6.2.9.2.2-1  General Form Of Characteristic

This is then assigned using a characteristic_assignment entity that allows the following to be defined:

 


Figure 6.2.9.2.2-2  Characteristic Assignment

Additionally, some characteristics may be qualified as being mean, maximum or minimum values. This is done by using a qualified_characteristic_assignment entity with an additional attribute that allows the value to be qualified as being a "mean" value for example.

By using this approach, the NCDM is kept as an open model, which can easily be extended as additional characteristics can be added.

Currently there are many different specific characteristics defined as subtypes of the characteristic entity. If we look at one example to see the way these work, most of the subtypes will become clear.

Mean time between failure, is a typical characteristic. It applies to a product (in the NCDM, a product_design_definition or an element) and may be specified as a requirement or as a predicted value by a supplier. In the NCDM this will be a qualified assignment (as "mean") of the time_between_failure characteristic.


6.2.10  Supporting Schemas


6.2.10.1  Approval
An approval may be assigned to the set of product data that are defined in the Select Type approval_assigned_item. The assignment includes information about the person and/or the organization granting the approval, the date of the approval and the type or role of the approval. The NCDM defines three types of approval that are related to baseline management. These are:


6.2.10.2  Person and Organization
A person, a person in organization and a specific organization may be assigned to the set of product data listed in the Select Type person_organization_assigned_items. The assignment specifies the role of the person and/or the organization in the assignment.


6.2.10.3  Date and Time
Date and time may be assigned to the product data listed in the Select Type date_time_assigned_items. The assignment specifies the role of the date and
time in the assignment.


6.2.10.4  Support Resources
This schema includes the definition of a few data types that are used extensively throughout the remaining nine schemas.


6.2.10.5  Referenced STEP Integrated Resources (IR)
The NCDM reference from STEP IRs the measure_schema, the date_time_schema, the contract_schema, the document_schema and the security_classification_schema.


6.3  Developing a Life-cycle Cost Model
A life-cycle cost analysis is a method of calculating the cost of a system over its entire life span. The analysis of a typical system could include such costs as System Planning and Concept Design, Preliminary System Design Cost, Design and Development Costs, Product Costs, Maintenance Costs, and Disposal Costs. This type of analysis often uses values calculated from other reliability analyzes such as failure rate, cost of spares, repair times, and component costs.

Life-Cycle Cost (LCC) looks at the total cost of ownership of a process, system, or piece of equipment. For installation of new equipment, a LCC analysis can assist in the decision-making as to what most benefits the owner economically.

Likewise, a change or improvement to an existing process or equipment can be evaluated on LCC to determine any cost benefit or justification for making the change. The LCC comparison, between the existing condition versus the changed condition, can reveal payback period, cumulative cost savings, or illustrate the change has little or no cost advantage and should not be done.

The outcome of the analysis is dependent on the assumptions made or criteria used in the LCC. Interest (or discount) rate, equipment life, inflation factor(s), operating, and maintenance cost impact are just a few. The better this information, and one's persistence and integrity in using good data, results in a higher confidence level of the outcome and success in finding management support.

In LCC you are looking at the cost and the cash flow or money spent each year over the life of the asset -- in effect, its total cost of ownership. Present value is a term and a formula that normalizes future cash flows to a common point of reference that is today's currency (dollar, euro, franc pound, etc.). Present value can be calculated using cash flow and when it occurs. The present values of each option can then be compared and the most beneficial option selected.


6.3.1  Life-cycle Cost Models
The following was extracted from ANALYSIS of LIFE CYCLE COST MODELS For DoD and Industry USE in "Design-to-LCC" by John C. Sterling.


6.3.1.1  Background
"Design-to Life-Cycle Cost" (LCC) has been mandated since the 1970's, but essentially ignored or implemented on a selective basis. The main alternative, Design-to-Production Cost, ignores the effects of Operating and Support (O&S) costs. These costs can often be 60% to 75% of the total LCC of a system. Design-to-Production also ignores the LCC of various alternatives for Level of Repair (LOR) options (i.e., the intended support policy) for each repairable item that can vary widely depending on the repair/discard-at-failure policy selected.


6.3.1.2  A Summary of "Design-to-LCC" and Life-cycle Cost Models
Currently, Military Standards and Specifications and most U.S. DoD/Service approved LCC models address only pieces of the LCC process. In particular, they fail to adequately address the "Design-to-LCC" process during the "front-end design analysis" stage of a system's development which occurs before a system's "hardware design freeze." These Specifications and Standards, and most LCC models, generate large amounts of non-compatible data that is funneled to Program Managers who are expected to use all of this data to support major LCC decisions (including LOR decisions) on their respective programs. Therefore, Program Managers in both Government and Industry badly need help to structure and analyze this large amount of data so that they can project, early in the concept and hardware design stages, not only the LCC of all available program options and combinations, but also the LOR for each of the system's repairable items, i.e., its "Line Replaceable units" (LRUs) and "Shop Replaceable Units" (SRUs)].

The LCC models available today are "Database Managers" that have the capability, to varying degrees, to import, modify, analyze, integrate, and manage large amounts of data from many different sources. From this data, reports are generated that display or project the overall effects and results of program decisions on existing or alternative system designs, including risks thereof. These LCC models store a baseline of program decisions that can also be used to provide a valuable, systematic audit trail. One major advantage of a few (but not most) of these available LCC models is their ability to provide early input to the front-end design analysis stage of the Concurrent Engineering (CE) and ILS processes. This early LCC influence on design ensures the systematic and simultaneous design of both the end-item system, and the processes by which they are produced, tested/evaluated and supported for their life-cycle.

Both NATO Program Managers and Industry CE and ILS teams need greater awareness of the availability and capabilities of these LCC models. This knowledge must include how they can best be used to ensure that fielded systems are successful (i.e., meet reliability, maintainability and availability goals), both initially and over the life-cycle, and remain within, or below, their established LCC budgets.


6.3.1.3  Life-cycle Cost Model Characteristics
LCC models are primarily "Database Managers" that accept and manage large amounts of data imported from other programs, such as:

The LCC models should be capable of modifying (i.e., adding-to, updating, changing), analyzing, calculating, mixing, and then sorting this imported data into information. This information is usable to determine which approaches are the most economical in terms of "Design-to-LCC" analysis, including LOR decisions, during the "front-end design analysis" stage.

The primary differences between the available LCC models can be grouped into one of the following categories:

The five most popular U.S. DoD approved LCC models are as follows:

 

Previous PageTop Of PageNext Page