The defense-related considerations and alternatives that were
presented consisted of the following:
Also in [1], various issues that complicate the prospect of migrating
the IETM specifications to a non-defense standard or specification
were presented. The main issues that were presented and/or discussed
are as follows:
Given the issues and alternatives addressed in [1], the recommended non-defense migration alternative was standardization through STEP. This migration path would require the development of an appropriate Application Protocol (AP), similar to the Electronic Technical Manual (ETM) AP introduced in [2]. It is further recommended that requirements for training manuals either be included within this ETM AP or be provided in a separate AP. The development of an ETM AP would constitute a non-defense standard for IETMs.
As can be seen from the definitions above, the potential scope
of STEP is enormous. Everything that is bought, sold, shipped,
consumed, manufactured, and/or used in any way (with the possible
exception of humans and animals, depending on one's definition
of thing and/or substance) is a product. In addition,
with respect to the purpose of this report, computer software,
Technical Manuals (TM), ETMs, and IETMs are all products. TMs,
ETMs, and IETMs could also be considered forms of product documentation.
Given STEP's potential scope, coupled with the vast number of
ways to represent products and product data, one could argue that
STEP could ultimately prove to be one of the most complex and
time-consuming standardization efforts ever undertaken. Consequently,
if STEP is to be truly successful, it will require the unrelenting
support of both Governments and major industries from around the
world for many years to come.
STEP is considered by some to be one of four principal components
of the CALS vision and strategy that are necessary for achieving
Enterprise Integration (EI). The other three principal components
include Electronic Commerce/Electronic Data Interchange (EC/EDI),
Concurrent Engineering (CE) principles, and CALS technical information
(whose aspects fall almost entirely within the scope of STEP but
can be used in conjunction with STEP, in a complementary fashion).
A pictorial view of these principal components of the CALS vision
and strategy was given in [1] and is repeated in Figure 3.0-1.
The first official release of STEP was approved as an ISO standard
in December 1994 [4]. It was then adopted as an American National
Standard (ANS) in February 1995.
STEP is organized into separately published parts. Each part
falls into one of the following seven categories [4, 3]:
Product data description methods within STEP cover both computer
processable and graphical description methods. The computer processable
product data description method defined within STEP is EXPRESS.
EXPRESS is a formal information requirements specification language
that allows a complete and unambiguous description of product
data and the constraints applicable to that data.
The parts governing implementation methods within STEP address
methods and constraints regarding the use of APs. These methods
include common information requirements, constraints regarding
conformance requirements, etc. Current implementation standards
that either are approved or are in process include ISO 1030321,
which is a specification for mapping EXPRESS to a sequential data
file for exchange; 1030322, which provides a standard software
interface to STEP data (the Standard Data Access Interface (SDAI));
1030323, which covers C++ language binding to the SDAI;
1030324, covering C language binding to the SDAI; 1030325,
covering FORTRAN language binding to the SDAI; and 1030326,
the Interface Definition Language (IDL) binding to the SDAI [5,
6].
The conformance testing methodology and framework govern the testing
of software products that claim conformance to an ISO 10303 AP.
These parts are being developed with the goal of ensuring that
tests are performed correctly and that test results are consistent
whenever and wherever they are conducted [3].
Integrated Resources (IR) are the bases for describing product
data. They provide a unique representation of each element of
information within 10303. Generic IRs are termed contextindependent,
whereas application IRs are related to a specified group of applications.
IRs provide a foundation for later integration and/or harmonization
of different APs.
APs are the application-specific building blocks of STEP. For
a given application (e.g., Mechanical Design Using Boundary
Representation (AP204), Life-Cycle Product Change Process (AP208),
etc.) an AP contains the scope, context, and information requirements
necessary for data standardization and exchange. Development
of an AP is recommended in [1] for migrating the DoD IETM specifications
to a nondefense standard. The development of an AP is not
a trivial undertaking and is addressed later in this report.
Abstract test suites contain sets of abstract test cases for their
corresponding APs. Abstract test cases are developed in a formal
language and specify (in an applicationindependent manner)
the necessary steps required to evaluate one or more conformance
requirements. Each AP contains (or will contain) a reference
to a corresponding abstract test suite.
The idea of developing an ETM AP is proposed in [2] as one of
at least three principal components for establishing an integrated
product logistic support database. The other two principal components
consist of a Product Support Analysis (PSA) AP and an Order Administration
AP. In [2] these three APs, together, are termed the Product
Logistic Support (PLS) AP suite. In all three cases, it is further
proposed in [2] that these APs be developed through a harmonization
of one or more U.S. military standard, specification, and/or practice
with appropriate portions of the European AECMA 1000D and 2000M.
Specifically, the ETM AP would be developed from a harmonization
of MILD87269 and AECMA 1000D. The PSA AP would
be a harmonization of MILSTD13882B, and Chapters 1A
and 1B of AECMA 2000M. The Order Administration AP would be a
harmonization of Military Standard Requisitioning and Issue Procedures
(MILSTRIP); Military Standard Transaction Reporting and Accounting
Procedures (MILSTRAP); and the Procurement Planning, Order Administration,
and Invoicing sections of AECMA 2000M (Chapters 2 through 5).
The PLS AP suite is not specifically being developed by any of
the current working groups within STEP. Although this is the
case, considerable interest [7, 8] has been expressed recently
in WG3/T8 (the Product Structure and Life-Cycle Support Team)
concerning the work proposed in [2]. This interest resulted in
the drafting of a letter/proposal to various national and industry
organizations to seek their support for including a harmonized
Logistics Support Analysis (LSA) standard (the Integrated Logistics
Standard Harmonization Application Protocol (ILS AP)) within STEP
[7]. In a recent meeting of T8 (Dallas, TX, 19-26 January 1996),
discussions associated with the creation of the ILS AP were tabled
due to funding and ownership issues [8].
In terms of recent and future work, WG3/T8 has been developing
AP208 (The Life-Cycle Product Change Process Application Protocol).
Other planned APs (in addition to the ILS AP) currently include
[9]
At this time, it appears that the ETM AP issue should be addressed
not only by WG3/T8, but also by WG3/T14 (the Product Documentation
Group). In [2] the ETM AP seems to consist of a straightforward
harmonization of MIL-D-87269 and AECMA 1000D. The more difficult
problem, however, is the integration of either or both of these,
which essentially employ Standard Generalized Markup Language
(SGML) as their modeling language, within the STEP environment,
which employs EXPRESS [20] as its modeling language. This nontrivial
problem is being addressed by WG3/T14.
WG3/T14 is currently looking at an integrated approach to product
documentation using both STEP and SGML (and includes HyTime and
Document Style Semantics and Specification Language [DSSSL]).
T14's goal is to produce an information architecture based on
STEP and SGML which integrates product documentation and product
data for the life-cycle of the product [10]. SGML is being
considered because of its widespread acceptance, its status as
an international standard, availability of tools, and the desire
to not "reinvent the wheel" by trying to figure out
how to do in EXPRESS what SGML already does.
T14 considers that product documentation can, in some cases, be
a product itself (e.g., as would be the case in an ETM AP).
In addition, product documentation may include maintenance instructions.
Three levels of documentation have been discussed [11]:
It seems clear that the tackling of tertiary level documentation
will be required prior to, or in conjunction with, development
of the ETM AP described in [2].
The primary migration/integration requirements, in a high-level
sense, for realizing the ETM AP are as follows:
Perhaps the most critical requirement for TM, ETM, IETM standardization,
from the point of view of the DoD, is to have a set of clearly
expressed DoD requirements with regard to TMs, ETMs, and IETMs.
More specifically, if DoD interests are to be taken into account,
then the Army, Navy, Air Force, Marines, etc., must clearly define
their TM, ETM, and IETM-related operational requirements, system
requirements, and technical requirements. These requirements
are further defined as follows:
With respect to ETMs and IETMs, documentation-related requirements
may also differ according to the different ETM/IETM system configurations.
Sets of operational, system, and technical requirements are needed
for each of the following configurations:
The need for a consistent set of requirements should not be underestimated.
Given that different specifications, standards, and handbooks
exist within DoD for TMs, ETMs, and IETMs, it is clear that no
single set provides all of the operational, system, and technical
requirements that are necessary for DoD-wide consensus. Until
such a set of requirements is developed, it is unlikely that any
standardization approach for DoD TMs, ETMs, and/or IETMs will
be successful.
In addition to the need for requirements, it is also clear that appropriate representatives from DoD, or on behalf of DoD, will have to participate in the development of the ETM AP. This will likely require participation in both WG3/T8 and WG3/T14. Participation, in general, within WG3/T14 is light at this time, and strong participation from the DoD IETM community would likely have an immediate impact (and would also serve to ensure that U.S. DoD interests would be taken into consideration).
The development of an AP is not a trivial task; the ETM AP would
be no exception. According to [12], AP development, in general,
is a time-consuming, labor-intensive, and expensive process.
In addition, a scheduling estimation in [12] indicates that 6294
man-hours of effort over more than 1.5 years are required for
the development of a single AP; this, of course, can vary a great
deal depending on the nature of the AP.
Development of an ETM AP to function as a non-defense standard
for IETMs requires conformance to the AP development requirements
of the STEP community. Approved STEP APs are ISO standards, and
their development is therefore subject to the guidelines imposed
by ISO. As stated in current draft STEP (SC4) AP development
documentation [22], ISO/International Electrotechnical Commission
(IEC) directives define seven stages in the development lifecycle
of an international standard. These stages, as applied to SC4,
are as follows:
Additionally, ISO/IEC directives specify certain time periods
after the approval of an AP development project for when it must
advance to the next stage:
Also according to draft SC4 AP development documentation [22],
the ISO Technical Management Board reviews any AP project that
has not attained the required progress and may decide to cancel
the project. The decision on whether to cancel is based on information
provided by the SC4 Secretariat.
There are different ways to initiate the development of an AP.
Initiation of any AP, among other things, requires the development
of a New Work Item (NWI) Proposal and the approval of SC4. Such
approval can be sought either by an SC4 approved AP planning project
or by some group external to the STEP community. Regardless of
where the initiation comes from, the NWI proposal is required.
One of the key items that is required for submitting an NWI proposal
comes from ISO standardization guidelines. Specifically, five
countries (and in some cases more) that are registered as P-members
must elect to participate in the standardization effort. Current
SC4 draft guidelines that address NWI proposals indicate that
the NWI proposal must include the following:
The partial draft of the proposed AP should include an outline
of the proposed document, a statement of scope, and enough technical
content so that its requirements and position in the SC4 architecture
are clear. Additionally, according to the current draft guidelines,
the draft AP must comply with the format and table of contents
for an AP and include the following:
The partial draft of the proposed AP may or may not also include
the initial Application Reference Model (ARM). This document,
with or without the ARM, will constitute the initial working draft
of the proposed AP.
Seeking approval for initiating an AP generally begins with industry
representatives who indicate the need for standardized product
data exchange for some product or application. These needs are
then converted into detailed, documented requirements and then
transformed into an Application Activity Model (AAM). The AAM
is usually done in Integrated computer-aided manufacturing Definition
method-0 (IDEF-0), and describes the processes, information flows,
and functional requirements of the application. The AAM may be
developed using methods other than IDEF-0 provided that there
is sufficient documentation on the selected method in the public
domain [13].
IDEF-0 was originally developed during the U.S. Air Force's Integrated
Computer Aided Manufacturing (ICAM) program [14]. IDEF-0 provides
a means to model both the functions required by a system, subject
area, or enterprise, and the functional relationships and data
within and among the various functions. Functions can be activities,
actions, processes, or operations. In addition, IDEF-0 can be
used for modeling both new and existing systems, subject areas,
or enterprises.
A model developed using IDEF-0 consists of a hierarchical series
of cross-referenced diagrams that depict the functions of a system
or subject area with graphics, text, and glossary [14]. The hierarchy
of the diagram structure is such that the level of detail associated
with the system or subject area being modeled gradually increases.
The principal components of the diagrams are boxes and arrows
[14]. Boxes denote functions and are therefore named with either
a verb or verb phrase. Arrows denote either input, output, control,
mechanism, or call information (depending on their location and
direction) and are named with either a noun or noun phrase. A
box with standard arrow positions and meanings is shown in Figure 5.2.2-1.
One of the more important, and possibly controversial, aspects
of developing an AAM for initiation of the ETM AP is to determine
the orientation of the model. Orientation refers to context,
viewpoint, and purpose [14]. The context shows where the model
fits within the broader environment and creates a boundary with
this environment through the description of external interfaces.
The viewpoint determines from what perspective the model is being
developed. The purpose provides the intent of the model.
An appropriate context for the ETM AP AAM, as more or less suggested
in [2], is within the logistical support environment. The viewpoint
and purpose, on the other hand, may require some debate. In [2],
it is suggested that the ETM AP be developed through a harmonization
of MIL-D-87269 and AECMA 1000D. The problem here is that, currently,
there are other ways (in both industry and the U.S. DoD) to create
IETMs (e.g., ATA 2100, MIL-PRF-28001 with the Presentation
Specification (PS), and MIL-STD-2361). Each of these approaches
specifies ETM/IETM structural and/or developmental requirements
differently:
In addition to the problem of having different specifications,
there is also the question of whether the model is to be process-oriented
rather than specification-oriented. If the model is to be process-oriented,
then the ETM AAM would be a diagrammatic equivalent to the information
given in various TM/ETM/IETM process-specific documents such as
[16, 17, 18, 19]. Given the different ETM/IETM specifications,
processes, etc., some level of debate will likely take place before
agreement is reached on the viewpoint and purpose of the AAM and
hence the ETM AP. Useful inputs for these debates are models
that are currently under development, such as the ATA 2100 Maintenance
and Engineering (M&E) data model being developed by Boeing
and the "TO-BE" DoD IETM process model being developed
through the U.S. Army's Logistics Support Activity (LOGSA).
After completing the AAM, the next major undertaking is the development
of an ETM ARM. ARMs are required for all STEP APs and are usually
done in IDEF-1X, Nijssen Information Analysis Model (NIAM), or
STEP's EXPRESS. ARMs are formal information models that define
all of the data, data relations, and data constraints within the
scope of a given AP.
ARMs differ from AAMs in that they are information models as opposed
to function models. The difference becomes evident when comparing
IDEF0 to IDEF1 (and hence IDEF1X). IDEF0
models, as described in the previous section, are "function
models" that are structured representations of the activities
or processes within an environment or system. IDEF1 models,
on the other hand, are "information models" that represent
the structure and semantics of information within an environment
or system [15]. IDEF-1X is an extended
version of IDEF1 that was developed to support integration
and the development of conceptual schemas. A conceptual schema
lies between the user's "view" of information (termed
the external schema) and the computers "view" of information
(the internal schema). In other words, a conceptual schema provides
a single integrated definition of the data within a process or
enterprise that is unbiased towards any single application of
data and is independent of how the data is actually stored or
retrieved [15].
All information requirements that fall within the scope of the
ETM AAM must be expressed in the ETM ARM. The ETM ARM must be
detailed enough to completely describe the information-related
needs of the ETM AP. Additionally, as the ETM ARM is developed
it must be modularized into various UOF. A
UOF is a collection of entities, attributes, and relationships
that convey one or more well-defined concepts within an ARM [13].
After the ETM ARM is developed and validated against the AAM,
scope, and functional requirements, the next major step required
for the ETM AP is the development of the ETM Application Interpreted
Model (AIM).
AIMs are created in STEP's EXPRESS and specify appropriate interpretations
of STEP integrated resources to satisfy the information requirements
of their corresponding ARMs. Integrated resources are encoded
in accordance with EXPRESS and serve as the foundation for integration
of APs. EXPRESS is a formal information requirements specification
language with an object-oriented flavor [5]. The EXPRESS language
(and hence the integrated resources) focuses on the definition
of entities, which are the things, or data elements, of interest
[20].
Although EXPRESS is a flexible and capable language, EXPRESS representations
of APs, in the form of AIMs, are not created with the only requirement
that they conform to the EXPRESS syntax. The EXPRESS constructs
that make up the AIM must be derived from corresponding EXPRESS
constructs that already exist as integrated resources. The process
of deriving an AIM from STEP's integrated resources is referred
to as interpretation.
As discussed earlier, there are two types of integrated resources:
generic IRs and application IRs. The interpretation of integrated
resources may involve one or more of the following [13]:
When necessary, information requirements given in an ARM that
cannot be satisfied by the current sets of integrated resources
will result in additions or extensions to the integrated resources.
Clearly, the process of developing the ETM AIM from its ARM will
be a time-consuming process and will require not only a detailed
understanding of EXPRESS but also a detailed understanding of
STEP's integrated resources. For the ETM AP, this situation is
complicated by the fact that the current work in WG3/T14 indicates
that SGML should be used in conjunction with EXPRESS for documentation-specific
requirements.
Development of both the ETM ARM and AIM will require concrete
harmonization of the STEP and SGML environments. This harmonization
is not a solved problem and, as mentioned earlier, is currently
under investigation by WG3/T14 [8, 10, 11]. At this time, five
main technical requirements have been proposed for effecting the
integration of STEP and SGML [10]:
In terms of the first requirement, it is suggested that product
documentation need only be modeled in STEP down to generic content
descriptions, whereas actual content models would be modeled and
encoded in SGML. For the second requirement, the storing of various
forms of product documentation will require appropriate constructs,
defined within EXPRESS, to denote the type of data being stored.
In the third requirement, exporting SGML data from a STEP-compliant
environment can be accomplished through STEP's SDAI. For the
fourth requirement, given an appropriate referencing scheme, translation
parameters could be embedded within references to the data for
subsequent interpretation by an application, or could be embedded
within appropriate applications. The fifth requirement could
be handled in a standardized fashion through a HyTime-based scheme
when referencing from SGML to EXPRESS, it is not clear how the
reverse would be handled.
WG3/T14 has begun hammering away at STEP/SGML integration by proposing
an SGML_STRING construct for use in STEP resource models [10].
The purpose of this construct is to allow for the definition
and utilization of SGML text strings as STEP objects. Furthermore,
this construct will allow for content and will reference a corresponding
Document Type Definition (DTD) fragment (and the fragment's corresponding
SGML declaration). T14 envisions that the SGML_STRING will be
used within the definitions of STEP APs and will therefore function
as an integral part of those APs.
The immediate need for both the SGML_STRING construct and a global
addressing mechanism has been presented to the STEP Architecture
Group (WG10) [8]. As a result, WG10 has determined that these
items are, indeed, necessary components of the STEP architecture
and therefore will be responsible for providing them.
The inclusion of SGML, a global addressing mechanism, and the
use of DTD fragments, however, will not immediately solve the
problems associated with realizing the ETM AP. If the ETM AP
is to be useful for both defense and non-defense industries, then
agreement will have to be reached as to the nature of the SGML
elements and DTD fragments that are used. The fact that two applications
can both import and export their data in an SGML-compliant format
does not imply that those same two applications can exchange data,
in a meaningful fashion, with each other. In general, when SGML
is used for exchanging data, a disciplined approach is required.
Two such approaches are as follows:
The idea of having a single or small, finite set of well-defined
DTDs for use within the STEP environment may seem unreasonable
at this time because STEP APs are evolving standards with diverse
and ever-expanding information requirements. The question of
whether this is unreasonable depends on the applications that
will ultimately process the documentation and product documentation
data. It also depends on the extent that documentation or product
documentation-related content is encoded within EXPRESS versus
SGML.
If one assumes that the only meaningful requirement that must
be satisfied by documentation and product documentation is that
the underlying data be suitable for presentation to humans, then
the idea of having a small set of DTDs, or even a single DTD that
is strictly presentation-oriented, may appear very reasonable.
Following this track would require that all documentation andproduct-documentation related content be given in EXPRESS, leaving
the SGML portions of an EXPRESS/SGML model devoid of content.
The downside, of course, is that SGML-encoded documentation-related
content could not be extracted, as content-intensive SGML instances
from EXPRESS representations, without a fairly complex intermediate
translation step; this is further complicated by the fact that
corresponding DTDs would also have to be derived from the EXPRESS
schemas.
A DTD for creating HyperText Markup Language (HTML) documents
is the best example of a single DTD that is strictly presentation-oriented.
Shortcomings associated with HTML's interactive electronic presentation
capabilities are overcome by using it in conjunction with a programming
or scripting language. This process has been standardized over
the Internet, to some extent, using the Internet's Common Gateway
Interface (CGI) standard. This same model, DTD plus programming/scripting
language, however, is probably inappropriate for both the ETM
AP and STEP/SGML integration in general (unless EXPRESS is used
as the scripting language). A single DTD, such as the MID, given
its embedded programming language capabilities, may be more appropriate
if a single DTD model is followed.
If one assumes that it must be possible for documentation and
product documentation SGML data exchange formats, that are used
in conjunction with EXPRESS, to include arbitrary levels of information-richness,
then the single presentation-oriented DTD approach could be abandoned
in favor of a meta-DTD approach.
A meta-DTD is basically a model of a DTD that is used to create
other DTDs. When developed properly, a
meta-DTD makes it possible for a DTD designer to create seemingly
arbitrary DTDs such that a separately developed processing algorithm
can process the associated SGML instances in a meaningful fashion.
For example, when creating DTDs for electronic presentation and
all the processing information is associated with the SGML elements
(rather than through a stylesheet), the presentation system must
understand what to do with the tagged data that it is processing.
In the nonmeta DTD approach, without standardized processingspecific
stylesheets, a new program must be written to present each DTD
that is created. In the metaDTD approach, a single presentation
system can be created such that all DTDs that conform to the requirements
of the meta-DTD can be presented (without needing additional software
developed). One example of a meta-DTD (although it does not strictly
conform to the metaDTD formalism as described in [21]) is
the generic layer DTD in the DoD IETM database specification,
MIL-D-87269.
One meta-DTD that does conform to meta-DTD formalism is the HyTime
standard. The HyTime standard contains architectural forms (meta-elements)
that are specified in SGML and allow for the location, linking,
and scheduling of information. The SGML elements that are used
to implement HyTime-compliant hyperlinking can have any desired
name so long as the element, its corresponding attributes, and
the interpretation of its use are in accordance with the HyTime
standard. This meta-DTD methodology makes it possible for HyTime
engines to be created to resolve all of the addressing information
associated with HyTime-compliant hyperlinking, while at the same
time leaving the implementor free to assign meaningful names to
the hyperlinking-related elements that he or she wishes to create.
At this time, it seems probable that WG3/T14 will propose an approach
to inclusion of SGML constructs that is consistent with the meta-DTD
paradigm [8]. Specifically, recent discussions in WG3/T14 have
centered around the development of a scheme for developing
standard tag sets for STEP applications [8]. This scheme calls
for the development of a standard set of templates or architectural
forms (i.e., meta-DTD). In addition, current thinking regarding
the nature of the templates is that they be developed in accordance
with the principles of information mapping and the seven classes
given in Table 5.2.5-1 [8].
In the end, to be successful, the ETM AP will require the participation,
support, and commitment of the U.S. DoD, interested international
defense communities, relevant U.S. and international non-defense
industries (e.g., airline and automotive), and the STEP community.
[2] "The ISO STEP Pilot Product Logistic Support
Application Protocol Suite Developmental Plan," by Ruey Chen,
Carderock Division, Naval Surface Warfare Center, Bethesda, MD,
CARDIVNSWC-TR-94/007, July 1994.
[3] "Standard for the Exchange of Product Model
Data (STEP) Part 1: Overview and Fundamental Principles,"
ISO 10303-1.
[4] "U.S. Product Data Association and Initial
Graphics Exchange Specification (IGES)/Product Data Exchange Specification
(PDES) Organization Reference Manual," January 1996.
[5] "A Survey of the STEP Project," by David
Sanford, Boeing Commercial Airplane Group, January 22, 1996.
[6] "SOLIS - STEP On-Line Information Service
Directory" http://elib.cme.nist.gov:70/1/step.
[7] "Summary and Notes of the Joint Meeting of
ISO Technical Committee (TC) 184/SC4 and the IGES/PDES Organization
(IPO)," Crystal City, VA, June 25-30, 1995.
[8] "Product Structure and Life-Cycle Support
Team Meeting Minutes," ISO/IPO Joint Meeting, Doubletree
Hotel, Dallas, TX, USA, January 19-26, 1996.
[9] "An Overview of AP208, The Life-Cycle Product
Change Process Application Protocol," by Chuck Amaral, Rockwell
Aerospace, presented at Joint ISO/IPO Meeting, CALS PDE Committee,
Dallas, TX, January 22-25, 1996.
[10] "Product Documentation - Technical
Requirements, ISO/TC184/SC4/WG3/T14, IPO Technical Publications,
Standing document H. November 1, 1995."
[11] "T184/SC4/WG3/T14 Product Documentation Group,
Minutes: Grenoble meeting," October 23-27, 1995.
[12] "Requirements for an Application Protocol
Development Environment," by Allison Barnard Feeney, Stephen
Nowland Clark, and James E. Fowler, National Institute of Standards
and Technology (NIST), NISTIR 5197.
[13] "Guidelines for the Development and Approval
of STEP Application Protocols," Version 1.0, February 20, 1992.
[14] "Integration Definition For Function Modeling
(IDEF-0), FIPS Pub 183," http://www.ha.osd.mil/rmo/pages/draft/fips/
fipsmain.html.
[15] "Integration Definition
For Function Modeling (IDEF-1X), FIPS Pub 184," http://speckle.ncsl.nist.gov/~gunn/mos/backgr.html.
[16] "Interactive Electronic Technical Manual
(IETM) Process Plan, Processes and Guidance for IETM Implementation,"
published by Commander, Naval Sea Systems Command and Commander,
Space and Naval Warfare Systems Command, S005-AD-PRO-010, 0910-LP-751-9100/5800.
[17] "Training/IETM Interface Guide," prepared
for Naval Air Warfare Center Training Systems Division (NAWCTSD).
[18] "Applying CALS to the Creation, Management,
and Use of Technical Manuals," Second Edition, prepared by
CALS Resource and Implementation Cooperative, prepared for Navy
CALS/Acquisition Group, June 30, 1993.
[19] "Navy Interactive Electronic Technical Manual
(IETM) Acquisition Guide, Initial Draft," by Samuel C. Rainey
and Joseph J. Fuller, Carderock Division Naval Surface Warfare
Center (CDNSWC)/TM-18-95/01.
[20] "Express Language Reference Manual,"
ISO 10303: Part 11.
[21] "Multimedia Interchange using SGML: The
ISO "HyTime" Standard," by Steven R. Newcomb, First
ACM International Conference on Multimedia, August 1-6, 1993,
Anaheim, California USA.
[22] "Guidelines for the Development and Approval
of STEP Application Protocols, Version 1.2, Working Draft,"
April 5, 1996, ISO TC184/SC4 N433, ftp://ftp.cme.nist.gov/
pub/ step/ sc4docs/ methods/ ap/ ballot1/ sc4n433.w51.
| AAM | Application Activity Model |
| AECMA | Association Europeanne Des Constructeurs De Material Aerospatiale |
| AIM | Application Interpreted Model |
| ANS | American National Standard |
| ANSI | American National Standards Institute |
| AP | Application Protocol |
| ARM | Application Reference Model |
| ATA | Air Transport Association |
| ATIS | Advanced Technical Information System |
| CALS | Continuous Acquisition and Life-cycle Support |
| CD | Committee Draft |
| CDM | Content Data Model |
| CDNSWC | Carderock Division Naval Surface Warfare Center |
| CE | Concurrent Engineering |
| CGI | Common Gateway Interface |
| DIS | Draft International Standard |
| DM | Data Module |
| DoD | Department of Defense |
| DSSSL | Document Style Semantics and Specification Language |
| DTD | Document Type Definition |
| EC | Electronic Commerce |
| EDI | Electronic Data Interchange |
| EI | Enterprise Integration |
| ETM | Electronic Technical Manual |
| FDIS | Final Draft International Standard |
| HTML | HyperText Markup Language |
| ICAM | Integrated Computer Aided Manufacturing |
| IDE | Integrated Data Environment |
| IDEF-0 | Integrated computer-aided manufacturing Definition method-0 |
| IDEF-1X | Integrated computer-aided manufacturing Definition method-1X |
| IDL | Interface Definition Language |
| IEC | International Electrotechnical Commission |
| IETM | Interactive Electronic Technical Manual |
| IGES | Initial Graphics Exchange Specification |
| ILS AP | Integrated Logistics Standard Harmonization Application Protocol |
| IPO | IGES/PDES Organization |
| IR | Integrated Resources |
| ISO | International Organization for Standardization |
| JCALS | Joint Continuous Acquisition and Life-cycle Support |
| LOGSA | Logistics Support Activity |
| LSA | Logistics Support Analysis |
| M&E | Maintenance and Engineering |
| MID | Metafile for Interactive Documents |
| MILSTRAP | Military Standard Transaction Reporting and Accounting Procedures |
| MILSTRIP | Military Standard Requisitioning and Issue Procedures |
| NAWCTSD | Naval Air Warfare Center Training Systems Division |
| NIAM | Nijssen Information Analysis Model |
| NIST | National Institute of Standards and Technology |
| NWI | New Work Item |
| P-members | Participating-members |
| PDE | Product Data Exchange |
| PDES | Product Data Exchange Specification |
| PLS | Product Logistic Support |
| PS | Presentation Specification |
| PSA | Product Support Analysis |
| SAE | Society of Automotive Engineers |
| SC4 | SubCommittee 4 |
| SDAI | Standard Data Access Interface |
| SFQL | Structured Full-text Query Language |
| SGML | Standard Generalized Markup Language |
| SOLIS | STEP On-Line Information Service |
| STEP | Standard for the Exchange of Product Model Data |
| TC | Technical Committee |
| TM | Technical Manual |
| TSWG | Tri-Service IETM Working Group |
| U.S. | United States |
| UOF | Units Of Functionality |
| WD | Working Draft |
| WG3/T8 | Working Group 3/Team 8 |
| WG3/T14 | Working Group 3/Team 14 |
| WG10 | Working Group 10 (the STEP Architecture Group) |