Previous PageTable Of ContentsNext Page

7.0  TOOLS


7.1  Tools
Selection of user tools is as important as designing and implementing the Shared Data Environment. These tools are an integral part for providing connectivity with a common basis for sharing DS information in ready-to-use formats. It is important to note that data stored within the SDE is useless unless it can be extracted, analyzed, manipulated, updated, formatted, and presented in a user friendly manner by the appropriate software application tool.

In parallel with the analysis used to determine the SDE requirements, tool selection must be considered within the SDE context. The ideal situation is to provide an environment that separates information from applications and is based on open system standards. This will help ensure future flexibility in upgrading to new software solutions as technology evolves.


7.1.1  Desktop User Applications
If information is to be effectively used, the user(s) must be able to apply appropriate application software to it. The application(s) software is used to create, analyze, modify, simulate, or interpret the information generated by business processes. This software may address information of a technical or a business aspect, e.g., a CAD/CAM modeler or an EDI transaction generator.

There are as many application packages as there are processes and users. Some are so generic that they may be better identified as an "Infrastructure Desktop Element," such as office automation products (word processors, spreadsheets, etc.). Some are very much discipline specific such as a finite-element modeler. In any case, the applications provide the mechanisms to the user to form and finalize the ultimate deliverable of the business process, i.e., the information product or package.


7.1.2  Tool Sets

 


Figure 7.1.2-1  Development Steps for Information Management Capability



7.1.3  Areas for Tool Consideration
The number and types of tools is almost infinite. The below list is an example of some of the areas that should be considered for tool applications. The list is nowhere near complete, but is only a representative sample. Listing of commercial tools does not imply NATO endorsement or preference.

Office Automation and Connectivity - The use of computer systems and communications technology to perform general, every day tasks such as document management, electronic mail, archiving and retrieval of text/graphics groups. The operation of systems in which a machine interface is required for the user to create, work with, display, or delete records within a general office environment.

Groupware - Groupware is an umbrella term describing the electronic technologies that support person-to-person collaboration. Groupware includes E-Mail, Electronic Meeting Systems (EMS), Desktop Video Conferencing (DVC), as well as systems for workflow and business process re-engineering (BPR).

Electronic Document Management - A document management system incorporates document imaging, archival, storage, text retrieval, workflow, OCR conversion, and fax capabilities.

Configuration Management- (CM) - A process for establishing and maintaining consistency of the configuration of a product over its life-cycle. This is typically achieved through: (1) CM planning and management; (2) Configuration Identification and documentation; (3) Configuration Change Management; (4) Configuration Status Accounting; and (5) Configuration Audit.

Enterprise Resource Planning (ERP) - Enterprise Resource Management is accepted as a broad term for the activities and software infrastructure that manage all of a company's assets and resources, including such basic applications as general ledger, accounts payable and receivable, as well as manufacturing, inventory, and human resources. It is the process of managing an organizations functions, processes and methodologies to achieve focus on customer driven delivery of product or service for the least cost and highest value

Product Data Management (PDM) - Product data management in the broad sense addresses all data that directly or indirectly supports the concept exploration, design, fabrication, assembly, testing, and life-cycle support of a product. This includes primary and derived requirements and the cost/schedule information required to support tracking of progress and timely corrective action.

Drawing Computer Aided Design/Computer Aided Manufacturing (CAD/CAM) - Software that enables developing digital master product models that makes it possible to create, simulate, optimize, document, build, and test products within a single electronic environment.

Workflow Managers - Real-time work management software to track processes, create built-in audit trails, and keep records on service quality and timeliness. Standards are developed by the Workflow Management Coalition (WfMC).

Performance Measurement


7.1.4  Configuration Management
Configuration management embodies two concepts: (1) the configuration management of items and their defining technical data, referred to herein as configuration documentation; and (2) the application of CM principles to digital data in general. Because, digital data management is critical to the control of configuration documentation and therefore to the configuration management of Weapon Systems, document management rules are integral to the CM process.

Configuration management is defined by the Electronics Industry Association (EIA) Standard 649 as a process for establishing and maintaining consistency of a product's performance, functional and physical attributes with its requirements, design and operational information throughout its life. Figure 7.1.4-1 is a top-level activity model depicting the CM process showing:

 


Figure 7.1.4-1  Configuration Management Process Model - Overview


The CM process encompasses:

The CM process is embodied in rules, procedures, techniques, methodology, and resources to assure that:

CM is applied to defense material, whether hardware or software, that are designated as "systems" and "configuration items." Systems generally refer to the level at which major defense acquisitions are defined and managed. A Configuration Item (CI) may be an individual item, or may be a significant part of a system or of a higher-level CI. It is designated at an appropriate level for documenting performance attributes and managing changes to those attributes. The concept of CIs has confused some people into thinking that the level at which they are designated is the point at which configuration management stops. In reality, the CI level is where configuration management really begins; the process encompasses, to some degree, every item of hardware and software down to the lowest bolt, nut and screw, or lowest software unit. This does not mean that the acquiring activity, the prime contractor, or even subcontractors have visibility or configuration control authority over every part. Rather it means that some organization within either the supply chain or the standardization process has configuration documentation and change control responsibility for each part.

The attributes of configuration items are defined in configuration documentation. Configuration baselines are established to identify the current approved documents. Configuration items are uniquely identified. They are verified to make sure they conform to, and perform as defined in, the configuration documentation.

Whenever a change is contemplated to an item, the effect of that change on other items and associated documents is evaluated. Changes are systematically processed and are approved by the appropriate change control authority. Change implementation involves update and verification of all affected items and documentation.

Information about item configuration, document identification and status, and change status is collected as activities associated with the CM process occur. This configuration status accounting information is correlated, maintained, and provided in useable form, as required.

The responsibility for the CM process and supporting activities is shared between the Government and the contractor and will usually vary according to the acquisition philosophy (performance or design-based) and according to the phase of the life-cycle.


7.1.4.1  NATO and Contractor Roles in the CM Process
Both NATO and the contractor participate in the CM process. Since, NATO has ultimate responsibility for the performance and configuration of the systems and equipment it acquires and operates, NATO is always the configuration control authority for the top-level performance attributes, and for selected lower level performance and design attributes that it specifies and contracts for. Contractors may exercise a significant degree of authority for configuration control during any or all phases of the life-cycle, depending on such factors as type of acquisition, contractual requirements, and ownership of the data.

For a specific acquisition, configuration control authority means that the activity or organization exercising that authority controls the configuration of the product and determines what changes are to be installed or incorporated in that product.

It does not mean that NATO or any other configuration control authority can unilaterally authorize change to configuration documentation throughout the life-cycle. Each configuration document has a current document change authority (CDCA), i.e., an agency, activity, or organizational entity that is responsible for the content of the document and is the only authority that can effect changes to the document.

The concept of current document control authority (CDCA), introduced in MIL-STD-2549, establishes that configuration control authority to effect a product configuration change under a contract does not automatically mean that a change can be directed or made to a document for which another organization is the controlling design activity and has content responsibility. An activity that uses a product and its documentation, but is not the CDCA, is referred to as an Application Activity (AA). An AA can only approve for use (adopt) the document, but cannot direct changes to it. These concepts become increasingly more important as acquisition looks to the commercial industrial base. It is central to the management of an automated information system concerning documentation used by different application activities.

The CM process is applicable both to development of new systems and items and to modifications of existing systems and items. A typical distribution of CM related roles is shown in Table 7.1.4.1-1 responsibilities included for continuity that are not primarily configuration management activity are italicized.


Table 7.1.4.1-1  Typical NATO and Contractor CM Roles and Responsibilities


7.1.4.2  CM Benefits, Risks, and Cost Impact
Configuration Management provides knowledge of the correct current configuration of defense assets and the relationship of those assets to associated documents. The CM process efficiently manages necessary changes, ensuring that all impacts to operation and support are addressed.

The benefits of the process should be obvious but are often overlooked. EIA-649 summarizes the benefits of CM from an industry view, as follows:

These benefits are equally applicable to NATO and industry. Additionally, the effective application of CM principles to defense products contributes to and enhances the partnering environment desired between NATO and its suppliers.

In the absence of CM, or where it is ineffectual, there may be equipment failures due to incorrect part installation or replacement; schedule delays and increased cost due to unanticipated changes; operational delays due to mismatches with support assets; maintenance problems, down-time, and increased maintenance cost due to inconsistencies between equipment and its maintenance instructions; and numerous other circumstances which decrease operational effectiveness and add cost. The severest consequence is catastrophic loss of expensive equipment and human life. Of course, these failures may be attributed to causes other than poor CM. The point is that the intent of CM is to avoid cost and minimize risk. Those who consider the small investment in the CM process a cost-driver may not be considering the compensating benefits of CM and may be ignoring or underestimating the cost, schedule and technical risk of an inadequate or delayed CM process.


7.1.5  Interchange Specifications


7.1.5.1  Introduction
This document describes the NATO CALS Data Architecture (NCDA) Version 4.0 and methods by which it can be used to identify and exchange information about a defense system over its life-cycle through the use of Through Life Interchange Specifications (TLIS). The methodology for developing TLIS and an example are detailed in Section 5. The NCDA is based upon the concepts and activities identified and defined by the NATO CALS Through Life Business Model (TLBM) Version 4.0. The TLBM represents improved business methods and efficiencies that can be brought about by the use of information technology throughout the life-cycle of a defense system to reduce costs, improve quality and reduce time cycles. The NATO CALS Concept of Operations (NCOP) describes how to achieve the vision of a Shared Data Environment (SDE) in support of a defense system through life. Taken collectively these tools and techniques can be used on individual programs and across programs and provide a framework for CALS in NATO.


7.1.5.2  Background
The need to exchange and to share product related data has long been recognized, and the NATO business requirements are to establish a standard method of identifying products and their structure as a means of:

For NATO a product is a major engineered asset with a significant life-cycle.1

The problems of achieving effective and efficient data exchange between the computer systems of different organizations are well documented2. The underlying problem is that most computer systems (even those developed by the same organization) are usually based on different data structures, and they usually store the data in file formats or databases that are proprietary or defined according to standards with restricted domains. Hence, being able to read data into system "A" that was generated by system "B," is often impossible. The data exchange standards described by Bloor and Owen3 attempted to overcome these problems by defining publicly accessible data structures and file formats which each system could map to. However, these early standards suffered from other problems, including vendors defining their own subsets of the standards with which they could easily map to, but which were usually different to the subsets that other vendors mapped to. Hence, there were still significant data exchange problems, even with the use "standard" formats.

The NATO CALS Handbook4 identifies standard formats for the digitization and delivery of numerous types of typical deliverables such as Technical Data Packages and Technical Documentation. However, even though this information is exchangeable in digital form, it does not begin to solve the real business problem of keeping technical information in synchronization with a changing product.

This critical need requires that the data management associated with product related information be in synchronization with the configuration management of the product itself. This then leads to the requirement to relate the two sets of data, product data and information about the product, simultaneously. Sophisticated data models are required to achieve this.

In recognition of the requirements across industries to standardize product information, a new data exchange standard - the Standard for the Exchange of Product model data (STEP) - began being developed under the auspices of ISO, the international standardization organization. STEP began development in 1984 and the first parts were released as full International Standards in 1994. The majority of the work to date has concentrated on the design, and to a lesser extent, the manufacturing phases of the product life-cycle. Until late 1996, little attention had been paid to the operation, maintenance, and decommissioning phases of the product life-cycle.

From a users perspective, STEP defines a series of specifications called "Application protocols" (AP), which define self contained sets of data which can be exchanged between two computer systems (thus avoiding vendor selected subsets and the myriad of problems which that caused in the past). Where it is seen to be sensible, various "conformance classes" can be defined for each AP. These conformance classes are further subsets of the total content of an AP, and are again precisely defined in terms of specific data structures required by a conforming implementation. The STEP standard uses a specific modeling language called EXPRESS that is machine interpretable. STEP then, is an enabler for the intelligent management and exchange of related product information. It is the standard the NATO CALS Office intends to use to support NATO CALS requirements. This document describes the requirements in the form of a NATO CALS Data Architecture (NCDA) and Through Life Interchange Specifications (TLIS) that are derived from it.


7.1.5.3  NATO CALS Data Architecture
An important result of the 1995 NATO CALS Acquisition Workshop was that a consistent life-cycle product data model could be established to satisfy the need to manage change to a product:

"The objectives for the development of the systems engineering data model were the alignment with the international standards and the reflection of the TO-BE environment, including concurrent engineering, the recursive systems engineering approach, requirements tractability, version control and life-cycle change management."5

The workshop report further stated that a data model needed to support all of the processes associated with a product throughout the life-cycle:

"Working in a concurrent engineering environment, using the system engineering process, addressing all the life-cycle processes, demands a data model that well supports the continuous comparison between the actual product as it is being developed through all phases and the requirements as they are defined and changed. The management of the different relationships between all the elements of the model is a critical factor for the model to be successful."6

The team that developed the generic high level model during the 1995 Acquisition Workshop selected the ISO 10303 Standard for the Exchange of Product Model Data (STEP) as the appropriate standard for a NATO CALS model.

The NCDA has been developed as a follow on to the NATO CALS Workshops and the NATO CALS Data Model (NCDM) developed as part of the Pilot Project #1 activity that focused on the Acquisition Logistics domain. Considerable input has been received from the ISO STEP community and experts from the NATO community, both governmental and industrial. The architecture is currently conceptual and requires further development of the NCDM for implementation. This is a planned activity as part of the NATO CALS Office 1998 Strategic Plan and is discussed further in Section 3.4. The NATO CALS Office has chaired a ISO project to identify the requirements in the area of Product Life-Cycle Support (PLCS). The activity is complimentary to the NCDA and will provide the basis for the additional standardization required to support the NCDA. Since the work of the ISO PLCS project and the NCDA are connected, references are provided where appropriate. The NATO work is to be performed as a contribution to the ISO STEP standards.

Once fully developed, the NCDA will consist of:

The NCDA is independent of time, organization, and implementation, and it is not inherent in the processes it supports. This enables the NCDA to support the entire life-cycle in a manner where data is created only once and used many times. The following graphic depicts the NCDA.

 


Figure 7.1.5.3-1  NATO CALS Data Architecture


The following sections describe the NCDA.


7.1.5.4  Through Life Business Model Analysis
The focus on through life product information was brought forward into the Through Life Business Model (TLBM) and NCDA as the primary target for standardization. The inputs, outputs, controls, and mechanisms of the TLBM Version 4.0 were analyzed to determine the types and normalized categories of information that the TLBM focused on. While the TLBM is not at a sufficient detail to determine the detailed data requirements of the information, a general architecture can be derived from the TLBM that is focused on the product and its life-cycle. As the TLBM is decomposed, the specific content of these "data assemblies" can be determined and incorporated into the NATO CALS Data Model that is the instantiation of the conceptual NCDA.

The objective of the NCDA is to provide a structure to support the TLBM requirements and satisfy the information management goal of data created once and used many times. Product information is created very early in the life-cycle (e.g., requirements definition) and exists throughout the complete life-cycle. In many armament programs, this represents decades that the information must be managed. This is less true for much of the management information associated with programs that support the defense system. There is a significant amount of information identified in the TLBM that is not "product centric" meaning that it does not require product information as part of its content. An example is a budget. This type of information is not currently detailed in the NCDA, but is part of the overall concept of managing information in support of a defense system. The management category of the NCDA is large and merits further study.

The categories of information in the NCDA are:

The following table details the classification of the information requirements in the TLBM into these categories.


Table 7.1.5.4-1  TLBM Version 4.0 Data Assemblies by DA Categories

Management

  

Acquisition Strategy

Allocated Funding

Authorization

Available Funding

Budget

Business Plan

CM Plan

Concept of Operations

Contractor or Government Entity

Contractual Mechanism

Disengagement Intention

DS Life-cycle Strategy

External Data and Information

Government/Industry Policies, Legal System, International Cooperation

ILS Plan

In-Service Goals

Information Management Plan

Mission Need

Mission Need Document

Multi-Disciplinary Groups

Operational Plans

Procedures, Regulations and Standards

Proposal

QA Plan

SDE Changes

Shared Data Environment

Solicitation

Through Life Business Model

Design

  

Defined Conceptual Options

Configuration Data

Functional Architecture

Design Data

Product Data

Operational Requirements

Quality Data

Proposed Conceptual Solution

Validated Mission Need (NST)

Test Findings

Production

Support (continued)

Accepted Defense System

Disposal Data

Defense Product

End of Use Data

New Defense System

ILS Data

 

Non-Operational Defense System

Operation

Non-Operational Support System

Mission Feedback

Operational Support System

Operational Defense System

Retired Defense System

Operational Feedback

Support Data

Operational Performance Data

Support System

 

Support System Performance Data

Support

Transfer Data

Cannibalization Data

Used Defense System

 


7.1.5.5  Architectural Core
The existing ISO STEP standards support a significant amount of product information, particularly in the areas of design and to some extent production. The NCDA acknowledges the existence of this capability and it will not be replicated in the NCDM. However, in order to accurately link to and reference the various models (called EXPRESS schemas in STEP), a consistent and persistent core model is required. The components of the Core are not only individual data entities, but are elementary EXPRESS schemas that will be called modules for purposes of this report.

The following sections identify the modules of the NCDA Core.


7.1.5.6  Product ID
Product Identification is at the center of the Core and essential in identifying the correct product. This module supports the unique identification of a product, which is the unique identification of a product instance or a group of instances. Among the requirements for this module are:7

1. Identification, within a specific domain, of a product and its components at multiple levels e.g.:

· part numbers
· serial numbers (instances of parts)
· batch number (unique to a set of instances)
· classification schema (e.g., NATO Stock Number - Form, fit and function)

2. Need to hold multiple identifiers for each of the above
3. Identification of context for "uniqueness" - how big, what are the boundaries of "global"
4. Need to link parts identifier to related identifiers:

· ID of part requirement
· ID of part design/model
· Drawing id
· Number used to sell part
· "assembled number"
· "where used" ID

5. Ability to deal with encoded part number, e.g., Bar code (UPC)
6. Identification by classification (e.g., group technology).


7.1.5.7  Organization
Organization is necessary to know the identity of the organization assigning the Product Identification. This module supports the unique identification of a product.
The requirement is stated as:

Need to know the organization, which assigned the identifier.8


7.1.5.8  Configuration
Configuration is necessary to identify the structure and the relationships among components of the product. The following are requirements for the module:9

1. Need to define product by multiple, hierarchical breakdowns, e.g.:

· Assembly structure
· Zonal structure
· Functional structure
· Program specified structure

2. Need to distinguish applicability of breakdowns to different life-cycle stages:

· (as built/as assembled/as fielded/...)

3. Need to maintain product configuration history
4. Need to distinguish between different states which can exist at a point in time - e.g., actual/permitted (states and combinations)/required
5. Need to identify that elements of the structure may be replaced by others:

· Supercedence
· Alternates/Alternatives

6. Need to identify and distinguish different versions of a product
7. Need to represent breakdown to different levels of detail e.g.:

· Configuration Item
· + parts
· + material (BoM)
· + source of material (batch no.)

8. Need to control configuration of Interfaces between separate products
9. Need to hold information about Configuration anomalies
10. Configuration control of software.


7.1.5.9  State
State is necessary to know the condition of the product (at a point in time). The requirement is:


7.1.5.10  Effectivity
"An effectivity is the identification of the valid use of an aspect of product data. An effectivity may be tracked by date, serial number, or lot number." (ISO 10303-41)


7.1.5.11  Linking and Referencing
The NCDA is based upon the principle that the Core model can be used consistently within STEP to provide for linking and referencing between data models, typically in the form of Application Protocols (AP). The ISO PLCS identified the following requirements:11

Referencing and Link (our "hooks" must have "eyes" elsewhere.)

1. Need consistent use of core at three levels:

· when developing a schema
· when implementing a schema
· when transferring information from any implementation to another

2. Keys and pointers. Identifiers as surrogate for data object
3. Need capability to navigate between the modules which use the core
4. Need business rule to ensure consistent identifiers across multiple implementations


7.1.5.12  Product Life-cycle Support (Logistics)
As a military alliance, NATO has a particular interest in "Cooperative Logistics." The following is taken from a NATO paper on the topic:

"Many forms of logistics co-operation exist, in many areas, between many partners, at many levels and for different purposes. As the provision for logistics was a national responsibility, the large majority of information systems are built to support national needs. Whenever logistics co-operation requires the exchange of information, specific "designed to purpose" interfaces are built. With the increase in co-operation as a result of the drive for more effective and efficient logistics solutions, within the context of the aim to make logistics a collective responsibility, the number of logistics co-operation programmes equally increases and with that, the number of proprietary interfaces, database as well. It is quite obvious that this is not the most effective way of proceeding, especially as the Armed Forces are more and more confronted with multiple, non-compatible interfaces."12


7.1.5.13  Within the NATO Context
Within the NATO Context then, requirements exist to exchange specific sets of information to support communications between:

A key element of the NATO CALS Framework is a specific data model that was originally developed to harmonize the requirement of three existing military standards, MIL-STD-1388-2B (US), AECMA 2000M (Europe) and AECMA 1000D (Europe). This work was based upon the results of a NATO CALS Workshop on Acquisition Logistics conducted in 1993. This model, named the NATO CALS Data Model (NCDM), has been encoded in EXPRESS and is intended to be the instantiation of the NCDA. It is currently limited in that it does not meet all of the requirements of the core, contains certain "legacy" characteristics, and needs to be modularized in accordance with the NCDA. It is part of the NATO CALS Office Strategic Plan to modify the NCDM in accordance with the NCDA.

This focus on Logistics is reflected in the NCDM and is the foundation for the instantiation of the NCDA. It is also the major input to the ISO STEP work on product life-cycle support.


7.1.5.14  Information Sharing and Exchange
The NATO CALS Handbook13 contains information and guidance for selecting and using information standards for general types of digital information exchange. The purpose and focus of the NCDA is to go beyond general information exchange and focus directly on clearly defined data elements and relationships associated with a product as defined by the data models in STEP and the NCDM. Data models are powerful tools that are used to define information objects and the relationships amongst them. With existing technology, the utilization of an EXPRESS data model enables significant advancements in the ability to use information beyond that of simple data exchange. Systems utilizing a common data model either as an internal structure or as a system interface can communicate directly and operate as a single logical unit, rather than separate distinct systems that require translation and physical movement of data to perform operations. Applications built upon the data model can then operate anywhere in the systems environment and access data through the model in ways not possible in data exchange, which, for example, must rely on external referencing to identify information and relationships (e.g., LCN to product). In a data model, this referencing is inherent within the model. These powerful concepts represent and enable new ways of doing business.

The NCDM was built to take advantage of these powerful concepts and enable improved access and management of information about a product and its support throughout the total life of the product, not only during "acquisition." Much of this information is created, stored, and managed, within the industrial enterprise supporting the defense system (i.e., product and its support system).

The NCDM will change the way industry creates, manages, and makes available product and logistics information. It will also change the nature of the interfaces between all the enterprises associated with a defense system throughout its life-cycle. Traditional forms of data exchange can be supported through data models, and the analysis of the TLBM along with the utilization of the NCOPS will provide an Information Management Plan (IMP) that identifies the optimal use of EXPRESS schemas and the NCDM.

The preferred method of data exchange for the NCDA/NCDM is defined in the STEP Standard as a Part 21. The details concerning STEP Part 21 are covered later in this document. These physical files can be transported by a wide variety of information "envelopes" from attachments to EDI messages, to MIL-STD-1840 and Internet FTP (File Transfer Protocol), as well as on physical media such as magnetic disks. The Part 21 form of exchange preserves the relationships between the entities in the data model so that they can be retained and utilized in the receiving system. Some forms of exchange do not support this important feature. In addition to a STEP Part 21 physical file transfer between systems, the following types of exchanges can be supported using the NCDM in a CALS Environment.

Each of these is described in the following sections.


7.1.5.14.1  Bulk Data Transfer
The capability to exchange an entire database of information can be supported by transferring an entirely populated NCDM using a Part 21 Exchange.


7.1.5.14.2  Data Lists
Data Lists are simple lists of data elements and values. This form of transfer usually does not preserve the relationships between entities


7.1.5.14.3  Tables
Tabular information can be used to transfer information in a way to preserve relationships such as relational tables. In some cases, this form of transfer can be used to directly import information into databases and spreadsheets. The receiving system must unambiguously understand the tables for this to be used, and it is not as potentially powerful a transfer mechanism as a Part 21 exchange.


7.1.5.14.4  Reports
Reports can be generated from the NCDM and formatted in such a way as to be human-interpretable. The usual application of this format is to extract data from the NCDM into a document that is intended to be read. There are techniques to do this automatically and remotely in response to system queries.


7.1.5.14.5  Direct Access
Direct access to NCDA data can be provided through a service such as the Contractor Integrated Technical Information Service (CITIS)14 and Internet Home Pages. In this case, the Interchange Specifications are actually Interface Specifications.


7.1.5.14.6  Dynamic Link
Dynamic linking of information systems that use the NCDM as a systemic interface is a powerful tool to "push" information via Part 21 files to other systems. This can be used to distribute information to a number of recipients in a distributed environment.


7.1.5.14.7  Through Life Interchange/Interface Specifications
Interchange Specifications can be used repeatedly during a scenario and over the life-cycle of a defense system. For example a "Supportability Characteristics" data assembly from a through life perspective shows that it would be utilized several time during the life time of a defense system:

The generalization of these can be built derived into the following states:


7.1.5.15  Methodology
A methodology for determining Through Life Interchange Specifications (TLIS) using the TLBM is the first step in developing a Concept of Operations for a Program. It yields the information requirements that are input to the programs Information Management Plan (IMP). Refer to the NATO CALS Concept of Operations for details on the IMP.

The following steps are recommended to develop TLIS for a program.

The steps should be used recursively because both at the scenario level and at the activity level the government-industry interface and relationship had to be examined and fed back/refined at the previous steps. The following graphic depicts this recursive approach.

 


Figure 7.1.5.15-1  Recursive Approach


Once the process has produced sufficient results, the TLIS requirements can be translated into STEP Part 21 encodings. This is described in later sections.

The following sections describe the steps in TLIS analysis methodology.


7.1.5.15.1  Define Scenario
The context in which the TLBM is implemented should be established. There are several obvious high-level scenarios for the TLBM in a NATO and Multi-National programmes. Examples of these are:

As you apply a scenario to the TLBM and make decisions while doing so, you will need to re-visit the scenario recursively to refine it. The scenario should be defined as unambiguously as possible.


7.1.5.15.2  Apply the Scenario to the TLBM
Apply the scenario to the TLBM with the aim of developing a tailored business model by:

After selecting and defining activities and ICOMs, the connection between applicable activities has to be re-established. Some activities may be found not be applicable for the scenario and tailoring of the TLBM may be required.


7.1.5.15.3  Define Government/Industry Interface
The interfaces between government and industrial participants in the programme may be different for each activity, and will most likely change over time. The nature of the interface will impact the decision on the type of interchange selected. Refer to the NATO CALS Concept of Operations for details on analysing the implementation of a CALS Environment for a programme. The interfaces between all participants should to be defined at the lowest possible level in the tailored business model.


7.1.5.15.4  Determine TLIS Purpose
The question of how the TLIS is to be used should be analysed. This can even include organisational and workflow analyses.


7.1.5.15.5  Select Type/Style of Exchange
The Type/Style of exchange can be determined at this point. This can include the following:


7.1.5.15.6  Determine Nature of the TLIS
Select the type of TLIS to be used for the exchange. The


7.1.5.15.7  Define Content of TLIS
Once the TLBM is tailored for the scenario, each ICOM should be analysed for its specific content. For those TLIS that contain product related information based on the NCSDM the EXPRESS definitions can be located in the NATO CALS Data Dictionary. The goal of NATO CALS is to have a library of TLIS in STEP Part 21 format for re-use. Until this exists, the STEP Part 21 encodings need to be developed for the requirements generated from the TLIS methodology. The following sections describe the development of STEP Part 21 files and a working example based upon the NCDM.


7.1.5.15.8  Develop STEP Part 21 Definition
An Interface Specification is intended to properly define the capabilities required for these exchanges. This requires a definition of:

The format - in this case the STEP file format (ISO 10303-)17 with user-defined extensions.

 


Figure 7.1.5.15.8-1  NATO CALS Standardization Architecture


The following sections review the elements of the STEP technology that will be used in defining Interface Specifications. These fall into two main categories: use of the EXPRESS language and use of the STEP file format. These will be described separately and the example given later will show how they relate to each other.


7.1.5.16  Use of EXPRESS
The NCDM is defined in the EXPRESS language. To define the Interface Specifications we will use two different facets of the language. The first is that necessary to select a subset of the NCDM. The second covers the ability to impose rules on valid sets of data.


7.1.5.17  EXPRESS Import Facilities
EXPRESS provides two related mechanisms for defining new schemas that select entities and other constructs from an existing schema. These are:

These are formally described in ISO 10303-11 in clause 11. Only an informal description will be given here.

The general effect of both statements is to import some items from one schema into another. See below for a small example. The two statements differ in that the legitimate instantiations of the data sets vary according to which was used. If the USE statement is used, the imported entities are considered to behave as if they had been declared in the schema and may exist independent of other entities indirectly, which is either imported by USE or declared in the schema. (In the case of the Interface Specifications, there will be no entities in the second category.)

For both USE and REFERENCE, any entities and types that are required for the attributes of the entities named but are not explicitly named are considered to be implicitly REFERENCE'd.

NOTE: The following is a simplified example loosely based on entities from the NCDM. It should only be used as an illustration of how the USE and REFERENCE mechanisms work.19 In the case of REFERENCE the imported entity can only exist if it is referenced by another ENTITY.

SCHEMA base_model;

ENTITY mission;

    in_scenario : scenario;
    description : STRING;
    name : STRING;
    mean_duration : OPTIONAL time_measure_with_unit;

END_ENTITY;

ENTITY scenario;

    user : STRING;
    id : STRING;
    description : STRING;
    operating_location_count : OPTIONAL INTEGER;
    number_of_systems : INTEGER;

END_ENTITY;

ENTITY time_measure_with_unit;

    measure : REAL;
    unit : STRING;

END_ENTITY;

ENTITY person;

    name : STRING;

END_ENTITY;

END_SCHEMA; -- base_model

-- New schema using things from the base schema
SCHEMA Interface_Specification;
USE FROM base_schema (mission);
REFERENCE FROM base_schema ( scenario );
END_SCHEMA;

 

In the previous example, the following is the result in the new schema:

Entity

Result

Mission

Included. May be independently

Scenario

Included. May not be independent instantiated.
(Would have been implicitly REFERENCE'd because of its use in the in_scenario attribute of mission.)

time_measure_with_unit

Included by implicit REFERENCE from

Person

Not included.

 


7.1.5.17.1  EXPRESS Rules
A major aspect of EXPRESS is the ability to define rules that a data set (such as an exchange file) should satisfy to be correct. The EXPRESS language provides equivalent power to many programming languages for defining such rules.

As an Interface Specification is inevitably a restricted subset of information to meet specific objectives. It therefore makes sense to allow for the definition of rules specific to an Interface Specification. Given that no new entities will be defined in an Interface Specification, the only EXPRESS construct that is applicable is the RULE.

RULEs can be used for the following types of constraint:

Examples of the first two of these are given below, based on the schema used above:

RULE only_one_scenario_allowed FOR (scenario);
WHERE
one_scenario_only: SIZEOF(scenario) = 1;
-- returns false if there is not exactly one scenario (population constraint)
END_RULE;
RULE positive_systems_count FOR ( scenario);
WHERE
systems_count: SIZEOF( QUERY(each_scenario <* scenario |
each_scenario.number_of_systems < 1)) = 0;
-- returns false if there are any scenarios with less number_of_systems less than 1
END_RULE;

 

Rules such as these can be specified in the same schema that USE's or REFERENCE's the NCDM entities.


7.1.5.17.2  Use of ISO 10303-21
STEP provides a file format that is based on a mapping from the EXPRESS language. It has two major components:

An example file (corresponding to the schema given previously) looks like this:

The header section is required to contain the three entities shown in the example above. These are:

The three entities are defined according to the following EXPRESS schema:

Outside the scope of STEP, this header information can be extended by means of user-defined entities to carry additional data about the exchange, rather than the product itself that is referred to within the data section of the file. The concept here is that the exchange file is itself a "document" and needs to be identified and controlled as such.

For the purposes of Interface Specifications, the following concepts/entities could also be included:


7.1.5.18  Common Conventions for all Interchange Specifications
The NCDM has been written with its eventual inclusion in an ISO standard in mind and for use in databases. Consequently, it does not impose many constraints or business rules such as might be expected for a model that carries the NATO badge. Such business rules might for example ensure that NATO conventions for part numbers are followed.

In order for the Interface Specifications to work in a compatible fashion and serve their intended joint purpose along side databases and other software based on and around the NCDM, it is necessary to impose some of the missing rules. These can be defined using the RULE facility of the EXPRESS language described previously.

The use of a second schema for these rules may seem contrived but it has been found extremely valuable to have the definitions of the information content of a domain separated from the business rules that relate to it. Such an approach facilitates change and does not force the business rules to apply to others who have information with the same content.


7.1.5.18.1  Example of Conventions
Please note that the following is intended to show how to specify the common conventions and only includes a simple rule restricting the length of identifiers for product and product version. This obviously does not represent anything like the full set of possibilities. At the time of writing the necessary requirements analysis has not been undertaken.

SCHEMA nato_cals_data_model_plus_conventions;

USE FROM nato_cals_data_model; -- imports all of it

(* define new rules for common conventions *)

RULE product_identification FOR ( product, product_version);
WHERE

      id_length: SIZEOF(

        QUERY(each_product <* product | LENGTH(each_product.id) > 32)
        ) = 0;

-- returns false if there are any products with id longer than 32 characters

      id_length: SIZEOF(

        QUERY(each_version <* product_version |

          LENGTH(each_version.id) > 32)

        ) = 0;

-- returns false if there are any product_versions with id longer than 32 characters
END_RULE;

-- more rules as appropriate here

END_SCHEMA;

 

7.1.5.19  An Example Interchange Specification
The following brief example is based on an activity identified as part of the NATO Framework project.


7.1.5.19.1  Objective
This Interface Specification is intended to support the exchanges identified for the following activity from the NATO CALS Framework activity model:

This activity was derived from the following:


7.1.5.19.2  Activity Overview
To identify required design and operational characteristics and restrictions which affect the product supportability.


7.1.5.19.3  Activity Description
Establish supportability, cost, environmental impact and readiness objectives and related customer or design requirements for the product. Identify the risks and uncertainties involved in achieving the objectives established including risks associated with new technology planned for the new product (hardware and software). The design constraints will address, but are not limited to, those related to hazardous material, hazardous waste, and environmental pollutants. Customer constraints such as the required use of existing equipment or facilities shall be considered.

These requirements and constraints shall be both quantitative and qualitative and are required for contractual information and as input to various project documentation including the ALDB or equivalent format approved by the project.


7.1.5.19.4  Activity Methodology
If required, further detail on the functionality and methodology behind this activity for the acquisition logistic requirements in defense equipment procurement may be found in the US MIL-STD-1388, UK DEF STAN 00-60, and GE ALS.


7.1.5.19.5  Mapping of Required Data into the NCDM
The following table shows the data elements required and the elements of the NCDM that correspond to them:

DED

LSAR Name

Model Reference

001

REQUIRED ACHIEVED AVAILABILITY

achieved_availability assigned with "Required"

009

ADDITIONAL REQUIREMENTS

narrative_characteristic.description

013

REQUIRED ADMINISTRATIVE

administrative_and_logistic_delay_time

 

AND LOGISTIC DELAY TIME

assigned as "required,maximum"

019

ALTERNATE LCN CODE

alternate_element_relationship.related.id

021

ANNUAL NUMBER OF MISSIONS

scenario.usage.
annual_number_of_missions

022

ANNUAL OPERATING DAYS

scenario.usage.annual_number_of_operating _days

023

ANNUAL OPERATING REQUIREMENTS

property assigned as required to element

064

CREW SIZE

property

096

END ITEM ACRONYM CODE

project_breakdown_assignment.project

164

REQUIRED INHERENT AVAILABILITY

inherent_availability assigned with "Required"

199

LSA CONTROL NUMBER (LCN)

element.id

203

LCN TYPE

element.definition.form

222

REQUIRED MAXIMUM TIME TO REPAIR

distribution_based_period (assigned as required maximum)

223

TECHNICAL MEAN ACTIVE MAINTENANCE DOWNTIME

mean_maintenance_downtime (assigned as required mean)

229

REQUIRED TECHNICAL MEAN TIME BETWEEN FAILURE

time_between_failure (assigned as required mean)

230

REQUIRED TECHNICAL MEAN TIME BETWEEN MAINTENANCE ACTIONS

time_between_maintenance_tasks (assigned as required mean)

236

REQUIRED TECHNICAL MEAN TIME TO REPAIR

time_to_repair assigned as (required mean)

228

MEAN MISSION DURATION

mission.mean duration

238

MEAN MISSION DURATION MEASUREMENT BASE

measure_with_unit.unit_component

262

NUMBER OF OPERATING LOCATIONS

scenario.operating_location_count

273

REQUIRED OPERATIONAL AVAILABILITY

operational_availability assigned to scenario

275

RELIABILITY OPERATIONAL REQUIREMENTS INDICATOR

scenario.usage[].name

286

REQUIRED PERCENTILE

distribution_based_period.percentile (assigned as required maximum)

376

SERVICE DESIGNATOR CODE

organization

450

ADDITIONAL REQUIREMENTS TEXT SEQUENCING CODE

no longer required

454

TOTAL SYSTEM SUPPORTED

scenario.number_of_systems

 

7.1.5.19.6  The Use Study Interface Specification Schema
For the purposes of this example, it is assumed that the source for the necessary entities is a single schema called the nato_cals_data_model_plus_conventions. This schema would include the rules defining common conventions for all NATO Interchange Specifications.

The example also shows one rule applicable to the Use Study Interchange Specification only. As the full requirements for the restrictions appropriate to this Interchange are not defined, only two rules are given as examples. The first rule limits the number of products for which requirements are being specified to one and one only. The second requires that all characteristic assignments point to the one product via its product definition.

SCHEMA nato_use_study_Interchange_specification;

USE FROM nato_cals_data_model_plus_conventions (

      achieved_availability,
      administrative_and_logistic_delay_time,
      alternate_element_relationship,
      breakdown,
      characteristic_assignment,
      distribution_based_period,
      element,
      element_definition,
      inherent_availability,
      mean_maintenance_downtime,
      mission,
      narrative_characteristic,
      operational_availability,
      organization,
      product,
      product_version,
      product_definition,
      project_breakdown_assignment,
      property,
      role,
      scenario,
      scenario,
      time_between_failure,
      time_between_maintenance_tasks,
      time_to_repair
      )

-- additional rules specific to this Interchange Specification

RULE only_one_product FOR ( product);

      WHERE
      only_one: SIZEOF( product) = 1;

END_RULE;

RULE all_assigned_to_product_version FOR ( characteristic_assignment);

      WHERE
      only_one: SIZEOF(

        QUERY(this_one <* characteristic_assignment |
        NOT (`NATO_USE_STUDY_INTERCHANGE_SPECIFICATION'+

          `PRODUCT_VERSION' IN TYPEOF(this_one) ) )

        ) = 0;

END_RULE;

END_SCHEMA;

This schema can be expanded to give an explicit schema for the Interchange Specification. The result will contain considerably more entities than are listed above. As an example the information object part of the model will be imported, enabling Use Study requirements, mission and role descriptions, etc., to be specified as SGML documents.

Note: Interchange Specifications should be published in electronic form, such that they can be used in software development. There are well-established STEP/EXPRESS tool kits that can process EXPRESS definitions and generate much of the required software architecture.


7.1.6  Product Data Management
Product Data Management (PDM) refers to the management of all of the data flowing through an organization that is required for use in the development of new products or in the updating of current products.

Several market pressures have encouraged the recent emergence of PDM systems:

The effective control of this data is a prerequisite of coping with all the above pressures.

Implementing PDM should have three beneficial effects:

The last of these points hints at the real power of PDM - the way it controls and facilitates the distribution and circulation of product data. For example, when you use one of the more advanced PDM systems to send information to other team members, although that information leaves your "ownership" (so you can no longer work on it), it does not leave your sight. At the click of a mouse, you can refer to it, monitor its development, and keep track of changes to it.

With the latest generation of PDM systems, the principles of concurrent engineering, still largely theoretical, receive practical computerized support.

What is more, these systems do not overturn existing working practices. On the contrary, they actually emulate the familiar manual procedures. People, therefore, adapt to them naturally, producing a rapid increase in productivity band efficiency. In addition, as familiarity grows and new working methodologies evolve, the PDM system is flexible enough to provide continuing support.

This text is from a "Product Data Management - Understanding the Fundamental technology and Business Concepts," a report by CoCreate.


7.1.7  Enterprise Resource Management
Enterprise Resource Management is accepted as a broad term for the activities and software infrastructure that manage all of a company's assets and resources, including such basic applications as general ledger, accounts payable and receivable, as well as manufacturing, inventory, and human resources. It is the process of managing an organizations functions, processes and methodologies to achieve focus on customer driven delivery of product or service for the least cost and highest value. The software and processes enabling this approach, Enterprise Resource Planning or ERP, was created to enable businesses to new markets, new demands in the global community and changing customer expectations. Industry, particularly manufacturing, has been driven to:

At the same time, manufacturers must respond to the need to reduce on-hand stocks, implement "just in time" delivery of materials and products and provide more reliable delivery dates and higher levels of service to customers.

There has been a fundamental shift in focus, as the business community has become global in nature. Inventory control was the focus through the 1960s, and in the 1970s planning for material requirements (MRP) began to emerge. MRP and MRP II began to evolve through the 1980s and into the 1990s extending from the "Shop floor" through associated areas such as Human Resources, Project Management, Finance, Engineering, etc. An awareness began to emerge that all these activities, their infrastructure, and supporting software should no longer be managed independently, but viewed and managed as they contributed to the core business. The entire business process was being addressed, thus the term ENTERPRISE Resource Planning evolved.

Throughout this time frame, the focus of this effort has been generally aimed at large business and manufacturing concerns. ERP software suppliers developed solutions to address the large, manufacturing sector. At the same time, industry began to turn to outsourcing and use of mid to smaller size suppliers. As the market forces began driving dependencies in the manufacturing process for inclusion of smaller and outsource suppliers, ERP software began to be developed for mid and smaller sized businesses. Through use of virtual enterprise approaches, the entire enterprise is being addressed.

ERP functionality is based on examining an activity's business processes and dependencies and focusing business processes or changes thereto on:

The Goal is to simplify processes before automating them, then apply tools that automate and integrate the processes to support meeting customers' desires and needs in cost effective ways. Within ERP, several software vendors, such as SAPTM, BAANTM, PeopleSoft,TM and others provide services and suites to address Sales and Distribution, Business Planning, Production Planning, Shop Floor Control, and Logistics. Briefly, these software suites provide:

Through the mid-1990s, the ERP process has been applied across the spectrum of the business processes required to produce products and services within the global marketplace. ERP product suites are expanding to address product data management, product configuration management and logistics planning, especially for complex, long-lived products. ERP, its approach and underlying software are encompassing Supply Chain Management (SCM) issues, treating the supply chain as a continuous and seamless activity, looking at demand, supply and constraints simultaneously. Thus Enterprise Requirements Management is the management of all the facets needed to tie together processes, diversified activities and organizations and still provide the final, customer driven, product in a globally competitive environment.

 

1 "Requirements for through-life standards: 13/11/97:"; ISO SC4/TC184/WG3/T8; draft document.

2 Product data Exchange; M S Bloor and J Owen; UCL Press London; 1995

3 Ibid.

4 NATO CALS HANDBOOK; NATO CALS Office; 2nd Draft; NATO Unclassified; March 1996.

5 "Acquisition Workshop" Stage 2 Overview and Results; NATO CALS Management Board; NATO Industrial CALS Group; NATO Unclassified; March; 1996; page 18.

6 Ibid.

7 "Requirements for through-life standards: 13/11/97"; ISO SC4/TC184/WG3/T8; draft document.

8 "Requirements for through-life standards: 13/11/97:"; ISO SC4/TC184/WG3/T8; draft document.

9 Ibid.

10 "Requirements for through-life standards: 13/11/97:"; ISO SC4/TC184/WG3/T8; draft document.

11 Ibid.

12 THE NATO LOGISTICS ARCHITECTURE PLAN or the need for conceptual logistics standardisation; NAMSA; NATO Unclassified; 6/30/97; page 1.

13 NATO CALS HANDBOOK; NATO CALS Office; 2nd Draft; NATO Unclassified; March 1996.

14 NATO CALS HANDBOOK; NATO CALS Office; 2nd Draft; NATO Unclassified; March 1996; Section 5.

15 ISO 10303-11, 1994; Industrial automation systems and integration - Product data representation and exchange - Part 11: Description methods: The EXPRESS language reference manual.

16 In ISO 10303 (STEP), the concept of a conformance class serves a similar purpose in identifying a subset of an AP. However it does not add any constraints, nor do they identify a specific implementation form.

17 ISO 10303-21, 1994; Industrial automation systems and integration - Product Data representation and exchange - Part 21: implementation methods: Clear text encoding of the exchange structure.

18 In common with STEP this paper adopts the convention of specifying EXPRESS language key words in UPPER CASE.

19 Such an ENTITY may of course be dependent on some other ENTITY through its attributes.

 

Previous PageTop Of PageNext Page