Nato Cals Www-ils001
-
date post
07-Apr-2018 -
Category
Documents
-
view
224 -
download
0
Transcript of 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 -
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
16/57
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 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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
19/57
Figure 6.1.2.6.3-1 (Diagram A3)
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)
-
8/3/2019 Nato Cals Www-ils001
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/ -
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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 .
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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."
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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:
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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
-
8/3/2019 Nato Cals Www-ils001
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.
-
8/3/2019 Nato Cals Www-ils001
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