nato cals www-ils001

8/3/2019 Nato Cals Www-ils001

1/57

6.0 MODELS6.1 The Through Life Business Model6.1.1 Purpose of a Through Life Business ModelThe 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 SharingA 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: A Baseline Description of the Life-cycle: The TLBM provides a common,

agreed description of the major life-cycle activities and information flows that

a program will need to address.
http://www.dcnicn.com/ncmb/nch_june-2000/Html/NATOCALS%20Handbook%201%20June%202009-10.htm#TopOfPagehttp://www.dcnicn.com/ncmb/nch_june-2000/Html/NATOCALS%20Handbook%201%20June%202009-08.htm#TopOfPagehttp://www.dcnicn.com/ncmb/nch_june-2000/Html/NATOCALS%20Handbook%201%20June%202009-08.htm#TopOfPage


2/57

A Benchmark: The integrated, through life approach, illustrated by TLBM

provides a benchmark of best practice across NATO. Program managers can

use TLBM to assess how far their program has progressed in taking full

advantage of modern IT and business practices. Exploring Boundaries: the TLBM can be used to explore the allocation of

roles and responsibility across organizational boundaries. Marking TLBMactivities to show the responsible organization(s) can provide a deeper

understanding of:- Current responsibilities- Information exchange requirements- Opportunities for Change

Implementing Change: For maximum benefits the TLBM should be used,

and further developed, as one active component in a program of business

change.Most change programs have an IT component. The TLBM is one of a series of tools

developed by NATOto help managers make best use of IT. The others are: The NATO CALSHandbook (Chapters 1-5). The NATO CALSDATA MODEL (NCDM) (Section 6.2).

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:Enablers: A Concurrent Engineering approach, Multi Disciplinary Groups, or Integrated Project Teams, and Electronic interaction between participants, based on a Shared Data

Environment, maintained for the life of the program.

Techniques: Improved requirements management, sustained through life. Consistent life-cycle Strategies for managing risk, quality, configuration,

acquisition (and re-supply), support, and program information. Project Optimization over the life-cycle. Early through life cost modeling, and improved cost awareness. Trade-off studies: capability, supportability, cost, risk, and in-service date are

treated as independent variables. Continuous review and approval of predicted or measured performance

against the current requirement.

Optimization of the supply chain for acquisition and for support. Optimization of support management based on feedback of in-service

performance. Life-cycle management of roles and relationships giving a flexible boundary

with industry. Information is managed as an asset.An outcome: Faster and cheaper acquisition Improved system availability Cheaper in-service support Safer disposal or re-use


3/57

6.1.2 Developing a TLBM6.1.2.1 TLBM DefinitionA 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 ScopeThe 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 withArmed 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 PrimeContractor.6.1.2.3 PurposeProvide an illustration of SDE enabled improved business processes for DS through

life management.The TLBM should be used as follows:

By DS program managers and their staff to develop a DS Program Strategy

for CALS. In this context the model must:- Provide a top level over view of the main activities through the DS

life-cycle, as enabled by an SDE.

- Draw attention to certain key activities that need to be managed in aconsistent manner through all life-cycle phases (CM, QA, ILS, IM).

- Illustrate, at a high level, the major information flows within the DS

program life-cycle, so that the program management can see the

totality of information to be managed through life.

Support discussions and decisions of the likely impact, on responsibilities

and on information flows across boundaries arising from:- Different organizational boundaries (within the project, between the

project and industry, between the project and the Armed Forces).

- Different SDE boundaries and capabilities.

- Show where the IM processes fit into through life activities.

- Provide a basis for the development of a program specific TLBM or

other activity models required solving specific problems.


4/57

- By members of NCO, and others, in presenting CALS concepts and

ideas during awareness activities.

- By other NATO or national agencies who are seeking to explore life-

cycle issues (e.g., Co-operative Logistics).

6.1.2.4 TLBM ViewpointThe 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 LifeThe 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 participantscan 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.


5/57

Figure 6.1.2.5-1 (Top Level Diagram)

6.1.2.5.1 Defense SystemA 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 alsoconsiders 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 PrinciplesThere 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 ApproachThe 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


6/57

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 IntegrationThe 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 EnvironmentThe 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 activitiesof creating and operating this SDE and managing information within it.6.1.2.5.2.4 Multi- Disciplinary GroupsA 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 replacingprotracted 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 AssetMany 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.


7/57

6.1.2.5.4 Organizational InterfacesThe 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 formore on this topic).As noted above, two other NATO CALS products have relevance to the TLBM.6.1.2.5.4.1 NATO CALS HandbookA 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 ModelThe NCDM provides a possible start point for the development of the programinformation 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

BreakdownAt 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 inFigure 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 systemperformance 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.


8/57

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 withinDiagram 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 supportcapability. The scope of this work required can vary widely. At amaximum it


9/57

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


10/57

Figure 6.1.2.6.1-1 (Diagram A1)

A12 highlights the need to develop and maintain a coherent set of policies andstrategies 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


11/57

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


12/57

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


13/57

Figure 6.1.2.6.1.2-1 (Diagram A13)

A132 establishes how responsibility for the various program tasks is to be allocatedover 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 DSthrough- life. This is assumed to include the task of forecasting and tracking DS life-

cycle cost. (Financial information flows in the TLBM could be developedin 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


14/57

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 ContractsFigure 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 datafrom 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 InformationThe 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.


15/57

Figure 6.1.2.6.1.2.2-1 (Diagram A136)

6.1.2.6.2 Obtain Defense SystemThis 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.


16/57


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


17/57

6.1.2.6.2.1 Develop Defense SystemThe 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 isfed 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.


18/57

Figure 6.1.2.6.2.1-1 (Diagram A21)

The design of the DS support system, or LSA (A215), is undertaken concurrently withproduct 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 SystemThis 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.


19/57


A33 undertakes the maintenance needed to restore the DS to the condition requiredfor 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 DefinitionsActivity definitions are included in Appendix C.6.2 NATO CALS DATA MODEL (NCDM)


20/57

6.2.1 IntroductionNOTE: 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 GeneralThe 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: The owner of a complex product The people responsible for maintaining and repairing the product The organization(s) who design and manufacture the product

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 viewThe 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 betweenmultiple 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: The conceptual layer contains a single model, within a given context, acting

as the basis for integration of data used by different applications or stored in

different formats. Models in this layer must not include details that are specific

to a particular application or business perspective and they must not include

physical (e.g., storage) format.

The internal layer contains the physical model. It represents the way in

which data is physically stored. There may be many valid physical models forthe same conceptual model. Any physical model must be able to import data

that conforms to the associated conceptual model. The external layer is a view of the conceptual model from a particular

perspective and for a particular application. There may be many valid external

models for the same conceptual model. An external model maps to a subset of

the conceptual model in such a way that the data described in the external

model can be exported in the format of the conceptual model.As part of this architecture, the NCDM has the role ofconceptual 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.
http://www.cals.nato.be/http://www.cals.nato.be/http://www.cals.nato.be/


21/57

It is meant to be used as the platform for the development ofphysical 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 HistoryThe 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 DictionaryVersion 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 ofNCDM 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 designdata, 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: It has provided the initial vision for the launch of the Product Life Cycle

Support (PLCS) initiative.

It has been translated and published in Japanese by JCALS.

It has been the basis for the Finish Defense Information Architecture

implementation. It has been used as a 'reference' by the Turkish Aerospace Industries (TAI)

when they developed the Turkish General Staff (TGS) Logistics System Data

Model.


22/57

It has provided the basic concepts for the launch of the Italian MoD project

(CALS Italia), which will develop a new Logistics Information System using

the NCDM as its conceptual model. Finally, it has been implemented in a software prototype, founded by the

French DGA, to test the model constructs and to prove that an Information

System, based on a relational database, could be developed from theconceptual model.

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.00The 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. Alsoimportant 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: Product instance and product instance management. The product

instance, in the NCDM terminology, is the actual physical system, normally

identified by a serial number, a tail number or a lot number. A product

instance is the result of the manufacturing process where one single product

design is realized in one or many product instances.

In order to support the product instance during its operational life, some new

data structures have been defined. The NCDM Version 4.00 gives the

possibility to maintain a record of the product instance current configuration

with the history of component replacements. Maintenance history and

operational usage history may be captured in order to optimize the support

activities and to plan operational deployment. Logistic activities have been

defined as a subtype of the Entity activity, which in turn is closely linked to

work_requestand work_order. In this way, the maintenance activity itself can

be captured by the NCDM.

Associations of the product instance with different person and/or organizations

in different roles (e.g., owner, user, driver, etc.) may be defined. To define

where the product instance is located at a certain point in time, an associations

with location can be established. Product concept and product concept specification. The user requirements

are defined in the very early phase of a program before the design activity

starts. At that point in time, the idea or concept of the system is formalized by

describing the expected features and functionality. For this process, the

NCDM, has defined a dedicated set of data structures based on the Entities

product_conceptand specification.

The NCDM Version 4.00 exploits these entities for the identification of the

requirement baseline, which is an important element of Configuration

Management. The NCDM defines the requirement baseline as identified by

the set of specifications which are linked to configuration_item through the

Entity configuration_item_characterization and that are associated with theEntity requirement_baseline_approval .


23/57

Configuration Management. Most of the feedback on Version 3.00 was

related to CM. A consolidation of proposals and feedback and an analysis of

the NATO STANAG 4159 and CM best practices was conducted for the

extension of the NCDM. The result was the requirement paper NCMB(NCO)-

(99)A-54 published in August 99. Based on these requirements, the model was

revisited to identify the data structures needed to support CM. The features ofVersion 4.00 in the area of CM are the followings:

- Configuration Status Accounting is a CM major function that is

directly supported by the NCDM. From a database implementation of

the NCDM it is possible to derive, at any time, the current

configuration status of: (1) the user requirements, (2) the physical and

functional design, and of (3) each individual product instance.

- Configuration Identification is based on the Entity

configuration_item, which collects the unambiguous identification of

user specifications (as-required), of physical designs (as-designed) and

of each product instance (as-built and as-used).- Configuration Change is managed through the Entities work_request,work_orderand activity.- Configuration Baselines are identified by those

configuration_items(s) that are associated with a baseline_approval.

According to the NATO STANAG three different types of baselines

are identified: (1) requirement baseline, (2) physical design baseline,

and (3) product instance baseline.

6.2.1.5 MotivationModern 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 atthe 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 ModelingRaw 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.


24/57

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 ofmany 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: Entity Definitions: describe classes of real-world objects with associated

properties. "product", for instance, is an entity of the NCDM. The properties

are called attributes and can be simple values, such as "name" or "id" or

relationships between occurrences of entities, such as "owner" or "part of."Entities can also be organized into classification hierarchies, and inherit

attributes from super-types. The inheritance model supports single and

multiple inheritance, as well as a new type, called AND/OR inheritance.

Type Definitions: describe ranges of possible values. The language

provides several built-in types. A modeler can construct new types using the

built-in types, generalizations of several types, and aggregates of values.

Correctness Rules: are crucial components of entity and type definitions.

These local rules constrain relationships between entity instances or define the

range of values allowed for a defined type. Global rules can also make

statements about an entire information base.6.2.2 How to Use the NCDM6.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 singleArmed 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.


25/57

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. The contractor shall provide configuration and design data that could

support the production of Bill of Material (BOM) Reports and of Labelled

Occurrence, Multilevel, Indented Product Structure Reports. This data shallbe in the form of instances of the following NCDM entities:

- Product- Product_version- Product_design_definition and its subtypes as needed

6.2.2.2 Defining a Common VocabularyThere 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 andexpensive software that acts as `translators' between different systems.

Figure 6.2.2.2-1 Number of Interfaces Without a Common VocabularyAs illustrated in Figure 6-2-1, the number of director translators between systemsgrows 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.


26/57

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

Vocabulary

6.2.2.3 Implementing an Integrated Product DatabaseA 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 ahighly 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. Acomplete 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: The relational model does not directly support the union construct.

EXPRESS Selects are simulated by a table with a column for each possible

member type. Only one column in each row contains a value. The remaining

columns are empty. Relational systems primitive data types are not as extensive as those of

EXPRESS are. A mapping is therefore needed to link the NCDM data types

with those supported by the selected relational system.


27/57

Relational systems need to know the length of the each field in the database.

This requires further data analysis since no attribute length is defined in the

NCDM. Finally, EXPRESS imposes no limit on the length of type or attribute names,

while the NCDM define entities and attributes with long names. Some

relational systems restrict the length of table and column names to 30characters. Name length conflicts in this case need to be resolved.

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 IndustryThe 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 tightlybound 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 SourcesThe term "integrated" refers here to "the process of reconciling data from many

different sources so that the resulting collection can be managed consistently withminimum redundancy."


28/57

Some of the technical opportunities are: Integration around product databases enables concurrent engineering - a

process where multiple engineers work on different facets of a product

concurrently. An Integrated Product Database gives the opportunity to store, in a single

source, information needed to deliver Technical Documentation (e.g.,Technical Manuals) together with Defense System Configuration data.

An Integrated Product Database enables a more efficient and flexible way of

delivering data to NATO Armed Forces:- The NATO Armed Forces can be allowed to access the contractor

maintained database through extensive use of Web technologies.

- The database itself or part of it can be delivered to the Armed Forces

as part of an Information System.- Data can be delivered to the Armed Forces using exchange files

(STEP Part 21, XML, ASCII files).6.2.2.3.2 In a ProjectA 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: Verification that system requirements are met can be assessed in real time. A continuous and concurrent decision schema is enabled, thus avoiding the

long delays in traditional milestone management. Use of cross boundary integrated teams is facilitate. Verification of database accuracy and completeness can be more easily and

accurately assessed.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: The contractor shall provide a cost effective method of implementing an

integrated product technical database based on the NATO CALS Data Model

such that it can be accessed by any authorized person or organization. 6.2.2.3.3 In the NATO Armed ForcesSeveral 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 infrastructuresystems. 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

ofNATO information interoperability in the area of defense system technical

information.Furthermore, the NCDM, by standardizing at the information level, offers theopportunity to define an Information Infrastructure built around a "Defense System


29/57

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 JointTask 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 NCDMAs 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 NCDMThe boxes in the diagram represent activities to be performed; the arrows arecomponents 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 ModelIn order to implement the NCDM, a set of implementation guidelines must bedeveloped. The NATO CALS Office is developing this for NATO programs and


30/57

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

The first step in building interoperable IT systems is to agree the extent,

structure and meaning of the data to be shared or exchanged within aparticular context. This is achieved by defining a conceptual data model. The NCDM is the NATO conceptual data model for product data and

support data. It provides semantic coherence for all partners in the NATO

context. Being a conceptual model, the NCDM addresses semantic definitions but

does not define physical data format, functional viewpoints, business rules and

conventions applicable to the NATO context. Without the definition of the above elements, a single conceptual data model

could give rise to many different real world solutions. The level of

interoperability between these systems depends on the degree of divergence in

format, business rules and conventions that are used by differentimplementers. The development of Implementation Guidelines with the definition of

physical format, functional viewpoints, business rules and conventions is in

the interest of NATO information interoperability.6.2.2.5.2 The Method

The NATO approach for the NCDM Implementation Guidelines is based on

the integration with the Product Life Cycle Support initiative (PLCS) and on a

progressive and iterative approach as illustrated in the figure below. The first step is to identify NCDM modules that are likely to be stable overtime and that are expected not to be changed by PLCS.

For each module, Task B.1 will analyze data definitions of the selected

module with the objective of defining entity unique keys and to resolve the

few existing many to many relationships between entities. Task B.1 will

deliver the logical model.

Figure 6.2.2.5.2-1 Developing Implementation Guidelines


31/57

Task B.2 will define the physical model and will map it to the logical model.

A physical model is used as reference for database implementation.

Task B.3 will start with the identification offunctional viewpoints. A

primary source will be the functional analysis performed under Pilot Project

#1 Task 2.4. Additional functionality, capable of exploiting the benefits of ashared data environment, should also be identified. Each functional viewpoint will be mapped to the supporting metadata in the

physical model. NATO business rules, conventions, coding and possible

derivation algorithms will be identified and documented for each functional

viewpoint.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 Overview6.2.3.1 The High Level ModelA very basic simplified view of the NATO CALS Data Model is shown below:

Figure 6.2.3.1-1 Abstract View of the NCDMThis can be interpreted as follows:

The product concept is, normally, the first object to be created. It is identified

in the very early stage of the life cycle of the system and is described by the

user-defined specifications. The product design, based on product concept specifications, includes the

functional design and the physical design. Concurrently with the system design, the failure analysis (anomaly) is

conducted to determine what can go wrong with the system and what has to be

done (task) to either repair it or prevent problems from occurring. A product instance is the result of the manufacturing process where one

single design is realised in one or many product instances. Maintenance status


32/57

and usage monitoring are needed to optimise system support activities and to

plan its operational deployment. The continuous processes of configuration identification and configuration

change will impact different data objects identified as configuration items. Any kind of additional information can be connected to aspects of the system

data. Possible information types include: engineering and other drawings,video, sound, SGML files. These are, in the NCDM terminology, information

objects. They may be linked to most data objects. Collection of Information

Objects may be identified as publication (maintenance and other manuals, part

catalogue, etc.). Approval may be assigned to most data objects and primarily to those that

are configuration items. A type of approval is the baseline approval.

Person and/or organization with role (designer, manufacturer, owner, driver,

etc.) and date and time with role may also be assigned to different data objects.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: Boxes represent things of interest. Thick black lines represent "is a" relationships, so "funtional_design" is a

"product_design." Thin lines represent relationships or associations and are labelled to give

meaning. They can often be read as a sentence, such as "product_concept"-"is

defined by"-"specifications." The double-layered boxes show that the subject is defined elsewhere.

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

Product Design, Product Instance, Functional Breakdown (CoreModel) Configuration Item, Configuration Change, Product Concept and

Specifications (Configuration) Failure Analysis (Anomaly) Task Definition (TaskDef) Technical Documentation (InfoObj) Logistic Support Analysis (LSA); Person and Organizations (ncdm_person_organization) Approval and Approval Role (ncdm_approval) Date and Time (ncdm_date_time) Support Resources (ncdm_support_resources)

6.2.4 The Core Model (CoreModel)6.2.4.1 OverviewThe core of the model centers on the following:

Product Product category Product design identification and structure Product design definitions, including functional and other breakdowns Product instance identification and structure Product instance maintenance and operational history


33/57

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 togeneralize the multiple life-cycle views under the single concept ofproduct.

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 Entityproduct_conceptand 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_conceptis related to zero, one or manyproduct_design(s) (inverse: one

product_design is the solution for exactly oneproduct_concept); (2) aproduct_design

is related to zero, one or manyproduct_instance(s) (inverse: aproduct_instance is the

realization of exactly one product_design).6.2.4.2 Description6.2.4.2.1 Product DesignThe starting point is STEP Entityproduct. From STEP the NCDM follows theconvention 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:


34/57

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 aproduct_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 ofproduct 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 StructureThis 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 StructureIn practice, assembly is almost always handled using the

next_assembly_usage_occurrence entity. This captures the fact that one part (or rather


35/57

aproduct_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 TreeThe 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 theuse 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.


36/57

Figure 6.2.4.2.1-4 An Instance of a Product Design Structure

Product Structure for Logistic BreakdownThere are several different breakdowns used for logistics purposes. These include:

Physical Functional System Zonal An others

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 ofelement_relationship

entities. Both the EXPRESS-G and an instance are illustrated below.


37/57

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: Physical: the element represents a level in a physical breakdown or a

physical part in a hybrid breakdown. Functional: the element represents a level in a functional breakdown or a

function in a hybrid breakdown. Zonal: the element represents a zone in a zonal breakdown. Catalogue: the element represents a level in a catalogue breakdown. System: the element represents a level in a system breakdown. Group: the element is an element_group (see below).

There are two specific subtypes of element. These are: Element_group - used to define an element in a breakdown which acts as acollection point for more elements. This is used to deal with the logical form


38/57

of figures in parts catalogues where the drawing is effectively used to define a

group of parts. Lsa_element- this carries the additional information as to whether or not an

element is to be treated as a candidate for Logistic Support Analysis.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 numberingscheme. Thus for the following LCN breakdown:

id Name28 Fuel system2801Fuel storage system2802Fuel 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 iscaptured 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 ofelement_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: alternate_element_relationship : two elements at the same level of

breakdown are alternates to each other. element_equivalence_relationship : two elements are equivalents to each

other. sub_element_relationship : one element is a sub-element of another. (This is

the type used to show a new indentation level in the LCN structure.) element_conversion_factor: used to specify how values associated with an

element are converted to a common basis (such as annual usage). element_group_membership : used to show that an element is included in an

element group. (This is how to show that a part is included in a figure in a

parts catalogue breakdown.) element_group_relationship : used to show that two element_group (figures)

are related.6.2.4.2.2 Product InstanceThe data structures collected under the Entityproduct_instance_definition are

dedicated to the management of the AS-BUILT/AS-USED view of the product.Aproduct_instance_definition is optionally related to exactly oneproduct_concept

and to exactly oneproduct_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 entityproduct_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. Aproduct_instance may be associated with a location.


39/57

Product Instance IdentificationThe 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 A serial number is an identifier consisting of alphanumeric characters, which

is assigned sequentially in the order of manufacture or final test which, in

conjunction, with the manufacturer's identification (e.g, id_owner), uniquely

identifies a single item within a group of similar items manufactured from the

same design. A lot number is an identifier consisting of either a date or a string of

alphanumeric characters which, in conjunction with the manufacturer's

identification, uniquely identify a group of units of the same item which are

manufactured or assembled by one producer under uniform conditions and

which are expected to function in a uniform manner. The term "material" applies to bulk items that are liquid, powder, or some

other form, such that a unit of measure, other than "each," is necessary to

describe any quantity of them. Materials should be identified by an appropriate

name according to industry practices. Instances or material are identified by aninternal unique identifier.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

nato cals www-ils001

Documents