NISTIR 7618

STEP-OAGIS Harmonization Joint 

Working Group

PDM Subgroup Interim Report

Xenia Fiorentini 

Sudarsan Rachuri
NISTIR 7618

STEP-OAGIS Harmonization Joint 

Working Group

PDM Subgroup Interim Report

Xenia Fiorentini 

Sudarsan Rachuri

Manufacturing Systems Integration Division 

Manufacturing Engineering Laboratory 

Committee Members: Vijay Srinivasan, Alan Boyd, Annap Derebail, Charlie Stirk, David Connelly, Mike 

Rowell, Frank Heinrich, Steven Vettermann, Sudarsan Rachuri, Hyowon Suh, and Xenia Fiorentini 

August 2009

U.S. Department of Commerce 

Gary Locke, Secretary 

National Institute of Standards and Technology 

Patrick D. Gallagher, Deputy Director 
Executive Summary 

In any manufacturing enterprise, there are two types of tools used to create and share 

product related data across its extended network. The engineering information of the 

product is created using what is commonly called an engineering authoring tool. Some 

examples of engineering authoring tools include Computer-Aided Design (CAD), 

Computer-Aided Engineering (CAE), Product Data Management (PDM), and Product 

Lifecycle Management (PLM). This information, encapsulated in engineering objects, 

mainly focuses on geometry information and some amount beyond geometry. The 

business information, encapsulated in business objects, is created using business 

authoring tools. Some examples of business authoring tools include Enterprise Resource 

Planning (ERP), Customer Relationship Management (CRM), and Supply Chain 

Management (SCM). Various solutions have been proposed to address interoperability 

issues within engineering tools and business tools. The prominent among them are 

standard-based, for example, ISO 10303 [1], informally known as STEP (STandard for 

Exchange of Product model data), for engineering tools. 

The focus of this project is to address the bigger problem of interoperability between 

engineering tools and business tools. The short term focus of the project is to analyze the 

potential harmonization of the ISO STEP-based OMG (Object Management Group) 

standard, called PLM Services [2] (web services for engineering objects), and OAGIS 

(Open Application Group Integration Specification) standard [3] (XML exchange 

protocol for business objects). The output of this short-term project will identify common 

concepts between these two standards that need to be harmonized. A scenario to 

demonstrate this harmonization to enable sharing of information between engineering and 

business tools using PLM Services and OAGIS will be developed. The long-term goal of 

this project is to develop a method for comparing and harmonizing standards. This will 

help designers, engineers, and process modelers in selecting appropriate standards for 

interoperability. 
Table of contents 

1 Introduction and Objectives......................................................................................... 1

2 A brief introduction to OMG PLM Services and OAGIS........................................... 2

2.1 OMG PLM Services in brief ................................................................................ 2

2.2 OAGIS in brief..................................................................................................... 4

3 Observations and suggestions...................................................................................... 6

3.1 Common concepts between OMG PLM Services and OAGIS............................ 6

3.2 Modeling paradigm in OMG PLM Services and OAGIS.................................... 8

3.3 Scenarios ............................................................................................................ 12

4 Issues and Future Plans.............................................................................................. 16

5 References ................................................................................................................. 18

List of figures 

Figure 1: UML version of the informational model in OMG PLM Services: part 

identification package ................................................................................................. 3

Figure 2: The corresponding XML version ........................................................................ 4

Figure 3: Contents of a Business Object Document (BOD) [3] ......................................... 5

Figure 4: The GetItemMaster BOD.................................................................................... 6

Figure 5: Real world products and product models data .................................................... 9

Figure 6: Product model and real world product in OMG PLM Services........................ 10

Figure 7: Physical_instance as a core concept for realizing the mapping ........................ 11

Figure 8: MapForce screenshot of the Physical_instance mapping.................................. 12

Figure 9: ECM scenario in OAGIS................................................................................... 14

Figure 10: A scenario for this project ............................................................................... 15

Table of tables 

Table 1: Examples of the product information represented in the ItemMaster noun ......... 7

Table 2: Examples of use cases in OMG PLM Services and scenarios in OAGIS .......... 13
1 Introduction and Objectives 

Global extended network enterprises participate in collaborative activities such as marketing, 

planning, development, manufacturing, and disposal of a product. Sharing and exchanging 

product and related information among these partners is essential to guarantee an efficient 

collaboration along the network. This information needs to be exchanged not only between 

different applications in the same domain, such as two different Computer-Aided Design (CAD) 

applications or between two different Enterprise Resource Planning (ERP) applications, but also 

between applications belonging to different domains, such as between CAD and ERP 

applications. 

Many information standards have been created to integrate applications belonging to the same 

domain. Within the engineering domain, ISO-10303 (STEP) [1] represents by far the most 

accepted standard, widely implemented in CAD, CAE (Computer-Aided Engineering) and PDM 

(Product Data Management) systems. Many other standards within the engineering domain have 

been developed as spin-offs to STEP, for example OMG PLM Services [2]. Within the business 

domain, the standards landscape offers a major variety of standards, mostly proposed by open 

and nimble organizations such as OMG (Object Management Group) [4], OASIS (Organization 

for the Advancement of Structured Information Standards) [5], and OAGi (Open Applications 

Group Inc) [6]. 

While domain-specific standards have already been developed, the integration of standards 

belonging to different domains, although desired, remains unrealized. In [7], Srinivasan noted 

that “time is ripe for such integration because of the convergence of three important factors: 

maturity of the domain-specific standards, emergence of the SOA architecture for information 

sharing and availability of robust middleware to implement them.” This project exploits the 

opportunities offered by these three factors and addresses the need to integrate engineering and 

business information systems. 

In particular, this project aims to facilitate the exchange of product data between PDM systems 

(engineering authoring tools) and ERP systems (business authoring tools) by harmonizing two 

standards widely adopted by each of them: PLM Services from OMG and OAGIS [3] from 

OAGi respectively. 

The aim of OMG PLM Services is to make the engineering objects derived from STEP readily 

available over the web. Following the Model Driven Architecture (MDA) [8], OMG PLM 

Services provides both a platform-independent and a platform-specific view point. In the 

platform independent viewpoint, an informational model, directly derived from the STEP AP214 

CC21 (conformance class 21) ARM (Application Reference Model) [9] model, describes the 

organization of the modeling concepts while a computational model, derived from PDTNet [10] 

and PDM Enablers [11], captures the functional aspects of the informational model. In the 

platform-specific viewpoint, the informational model of the platform-independent viewpoint is 

mapped into XML [12] while the computational model is mapped in WSDL(Web Services 

Description Language) [13]. 

The scope of OAGIS is that of structuring, in business documents, enterprise-wide business 

functions such as ERP, e-commerce, CRM (Customer Relationship Management), and finance. 

1
in business documents. The Business Object Documents (BODs) are business messages defined 

in XML and exchanged between business application systems. Each BOD includes an 

application area containing the information used to communicate the message, and a data area 

describing the content of the message itself. The content of the message is further organized into 

a noun identifying the business-specific data to be communicated, and a verb identifying the 

action being performed on the noun. 

The goal of this project is to study and compare OMG PLM Services and OAGIS with the aim of 

harmonizing them. The specific objectives are: 

 Understanding each standard by identifying its scope, organization, and modeling 

philosophy 

 Designing one or more use cases (scenarios) to understand the integration issues 

 Recognizing the concepts that intersect both the standards 

 Identifying portions of the models that are part of the intersection 

 Realizing the harmonization 

To achieve these objectives, the working group composition brought together disparate 

competences: members of the organizations owning the standards, participants from 

organizations that are promoting the standards, and experts in product information modeling. The 

following people participated in the project: Vijay Srinivasan (then IBM), Alan Boyd (IBM), 

Annap Derebail (IBM), Charlie Stirk (CostVision), David Connelly (OAGi), Mike Rowell 

(Oracle/OAGi), Frank Heinrich (iBASEt/OAGi), Steven Vettermann (ProSTEP iViP), Sudarsan 

Rachuri (NIST), Hyowon Suh (NIST/ KAIST), and Xenia Fiorentini (NIST). 

2 A brief introduction to OMG PLM Services and OAGIS 

The team approached this project by considering and analyzing the two standards: OMG PLM 

Services version 2 and OAGIS version 9.2. Studying and reviewing these standards helped the 

team to understand the standards on their own, to analyze their differences, and to identify their 

intersection. 

2.1 OMG PLM Services in brief 

The scope of OMG PLM Services is to represent engineering objects and to integrate them with 

service technologies. To achieve this scope, the OMG PLM Services specification provides i) a 

model to structure the engineering information of a product and ii) a model to query and navigate 

the structure. These two models are called, respectively, the informational model and the 

computational model. The specification defines a Platform Specific Model (PSM) applicable to 

the web services implementation defined by a WSDL specification, with a SOAP (Simple Object 

Access Protocol) binding, and an XML schema specification. The services derived from the 

combination of the informational model and computational model allow creating, reading, 

updating, and deleting engineering objects. 

OMG PLM Services is considered a spin-off of STEP since its informational model is directly 

derived from CC21 (Conformance Class 21) of STEP AP214 3rd edition [9]. This informational 

model represents the following: 

2
 part identification 

 part structure 

 document and file management 

 shape definition and transformation 

 product classification 

 product properties 

 authorization 

 configuration management 

 change and work management 

 process planning 

 multi-language support 

To obtain the informational model, the AP214 [9] CC21 AIM (Application Interpreted Model) in 

EXPRESS [14] is mapped through EXPRESS-X [15] into the ARM (Application Reference 

Model). The obtained ARM model in EXPRESS is mapped through XMI (XML Metadata 

Interchange) [16] into UML (Unified Modeling Language) [17]. Finally, the informational model 

is represented in XML schema. Unfortunately, the different nature of the languages implies a 

loss of information during this final translation; the concepts network expressed in UML can be 

hard to translate into a concepts tree in XML. 

We report here an example of the UML and XML versions of the informational model 

describing the part identification (Figure 1 and Figure 2). 

Figure 1: UML version of the informational model in OMG PLM Services: part identification package 

In this example, the UML class Design_discipline_item_defintion, representing a view of an 

item version, contains an association (intitial_context) with the class Application_context that 

describes the universe of discourse in which the view has been primarily designed. Unfortunately, 

the equivalent version of Design_discipline_item_defintion in XML contains only an element of 

3
the type IDREF. The fact that the identification (id) of this type should reference an 

Application_context is only expressed through an annotation. Therefore, some information is lost. 

The computational model of OMG PLM Services is derived from PDTNet and PDM Enablers 

and is first expressed in UML and then translated to WSDL. The computational model captures 

the functional aspects of the informational model; it represents the queries that are necessary to 

navigate it. Examples of these queries are i) the Item_version_query that provides all the 

versions of a selected item, ii) the Product_detail_query that provides detail information about a 

product selected through its id and iii) the Item_classification_query that provides the 

classification of a selected item. 

Since the computational model is strictly dependent on the informational model, the project team 

decided to initially neglect the computational model and to focus only on the informational 

model. 27 use cases are described in the OMG PLM Services specification to illustrate the 

context and way of usage of the informational model. These use cases fulfill the requirements 

analysis reported in the PDTNet project. 

Figure 2: The corresponding XML version 

2.2 OAGIS in brief 

The OAGIS standard aims to achieve interoperability between disparate enterprise-wide business 

systems by standardizing the architecture of the messages they exchange. These template-based 

messages, called Business Object Documents (BODs), are defined in XML and exchanged 

between software applications and/or databases. 

BODs are designed as business messages or business documents that are exchanged between 

software applications or components, between companies, across supply chains, and between 

supply chains. The contents of a BOD are graphically illustrated in Figure 3. The application 

4
area contains the information an application needs to communicate the message; it includes 

information such as the sender characteristics, the creation date of the BOD, and the BOD 

Globally Unique Identifier. The data area carries the business-specific data communicated by the 

BOD. The Verb identifies the action being performed on the specific Noun of the BOD. The 

Noun identifies the business specific data that is being communicated. All of them are defined 

using XML schema. Each Noun comprises components, which are extensible building blocks 

and contain compounds and fields. Compounds are basic, shared building blocks that are used by 

all BODs; these compounds are extensible through contextual use but not with additional fields. 

Fields are the lowest level elements defined in OAGIS; these fields are the fundamental elements 

that are used to create the compounds. 

Figure 3: Contents of a Business Object Document (BOD) [3] 

The OAGIS Release 9.2 [3] specification contains 13 verbs (e.g., create, get, show, and cancel) 

and 79 nouns (e.g., BOM, CreditStatus, InventoryBalance, and SalesOrder). While the verb 

names always represent an action, the nouns names are sometimes a combination of an action 

and a noun (e.g., PurchaseOrder, InspectDelivery and ReceiveDelivery). The BODs names are 

then composed by the name of the verb and the name of the noun (e.g., GetBOM, 

CancelInventoryBalance, ShowPurchaseOrder). The “OAGIS 9 Naming and Design Rules 

Standard” document [18] conforms to UN/CEFACT [19] XML Naming and Design Rules [20]. 

It defines the naming, design rules, and guidelines applied by OAGIS to create the XML files 

representing the BODs. As an example, consider the GetItemMaster BOD, which is of particular 

interest for our following discussion (Figure 4). 

5
Figure 4: The GetItemMaster BOD 

The data area of this BOD contains the verb, Get, and the noun, ItemMaster. The ItemMaster 

noun represents “any unique purchased part or manufactured product” and includes information 

such as UPCID code, product classification and packaging type. The Get verb is used when the 

sender application requests an existing ItemMaster. Usually, a Get-based BOD waits for a Showbased BOD (Show is verb) as a reply. To find the ItemMaster of interest, the message contains a 

selection criterion that enables searching within all the primary ids of the ItemMasters

(belonging to the ItemIDsGroup in the picture). 

The OAGIS Release 9.2 specification includes the description of over 200 BODs, and the 

explanation of 61 integration scenarios, in which two or more integrated applications exchange 

BODs messages. 

3 Observations and suggestions 

3.1 Common concepts between OMG PLM Services and OAGIS 

As a starting point for the harmonization of the two standards, the team decided to focus on the 

mapping between the nouns of the OAGIS BODs and the informational model of OMG PLM 

6
Services. Unfortunately, even though both the standards have an XML version, their XML 

schemas and XML schema files (.xsd) are differently organized. While the XML file of the 

OMG PLM Services informational model looks flat, the XML file of the OAGIS BODs has a 

complex structure (e.g., it often contains xsd:group). Since changing the XML structure of OMG 

PLM Services is not the focus of this project, the team decided to match the structure of OAGIS 

to that of PLM Services. 

From the preliminary analysis, it was clear that the two standards are different not only in their 

organization, but also in their scope and point of view. OAGIS and STEP with its spin-offs 

(OMG PLM Services included) model different aspects of product data. STEP models mainly 

focus on Engineering Objects (EOs), which are outputs of design authoring tools (e.g., CAD and 

PDM) and generally include information such as product geometry and tolerances. OAGIS 

nouns mainly focus on Business Objects (BOs), which are outputs of business authoring tools 

and generally include information such as product location, cost, and sales order. Some examples 

of business authoring tools include ERP and Supply Chain Management (SCM). 

Since EOs and BOs usually complement each other, the challenge to the team was to find the 

product data that travel across engineering authoring tools and business authoring tools. The 

team found that the intersection between the engineering and the business domains is constituted 

by the following OAGIS nouns: EngineeringChangeOrder, BOM, and ItemMaster. 

The EngineeringChangeOrder noun represents the document used to request a change to a 

manufactured product. The requested change pertains to the engineering aspects of the product, 

i.e., its structure and shape, and when it is first suggested, then reviewed and finally approved. 

The EngineeringChangeOrder noun contains information on both the metadata of the document, 

such as document ID and creation date, and the content of the document itself, such as the 

estimated engineering cost of the change and the suggested new BOM of the product to be 

changed. 

The BOM noun represents the document describing the structure of a product. Again, this noun 

contains information of both the metadata of the document, such as its creation date, and its 

content, such as the components of the product. The document mainly describes the engineering 

and manufacturing Bill Of Material of the product. 

As said earlier, the ItemMaster noun represents any unique purchased part or manufactured 

product. The product information represented by this noun is generated and processed by 

applications belonging to different domains: engineering, manufacturing, logistics, customer 

relationships, financials, etc. Table 1 contains, for each application domain, a few examples of 

the product information represented in the ItemMaster noun; a description of this information is 

also provided. 

Table 1: Examples of the product information represented in the ItemMaster noun 

Application domain Product information represented 

in the ItemMaster noun Description 

Specification Properties or features of the product 

Engineering DrawingAttachment Document that graphically represents the product 

BOMReference Product structure 

Routing Receipt routing of the product 

Manufacturing planning AvarageRunSizeQuantity Average quantity made during a manufacturing run 

LeadTimeDuration Forecasted time used to calculate the product availability 

7
Application domain Product information represented 

in the ItemMaster noun Description 

ExecutionTimePeriod Time period in which the product is effectively in process 

Manufacturing execution EffectiveTimePeriod Time period in which the Item is effective 

ManufacturerItemID Identifier of the product provided by the manufacturer 

FreightClassification Product classification based upon its transportation way 

Logistics Packaging Packaging information including type and dimension 

StorageUOMcode Storage unit of measure of the product 

UPCID Barcode of the product used in stores Sales 

CustomerItemId Identifier of the product provided by the customer 

HazardousMaterial Hazardous material code and description 

Environmental information TrackingIndicator Activated when the product needs to be tracked 

OwnerParty Who owns and is responsible for the product 

UnitValue The monetary value of the product 

Financial GLEntityID Responsible business unit 

GLAccount General ledger account 

The purpose of this table is neither to exhaustively list all the product information represented in 

ItemMaster, nor to cover all the application domains. The purpose of this table is to show the 

reader the variety of information included in this noun. 

3.2 Modeling paradigm in OMG PLM Services and OAGIS 

The information concerning the engineering domain is of a particular interest for this project; it 

represents the intersection between the ItemMaster noun and elements in the OMG PLM 

Services informational model. This intersection consists of product engineering aspects that 

belong to two different levels of abstraction: real world products and product models (see Figure 

5). 

8
Product model: mouse model Real world product: my_mouse

Metadata of the mouse model

Creator: Tom

Approval time: 01-01-09

Location: C:\myDocuments\files

Metadata of my_mouse

Manufacturer: Henry & co.

Lot ID: 5647

Location: Target store n°576

Data of the mouse model

Length: 10.00 cm

Weight: 100 g

Data of my_mouse

Length: 10.01 cm

Weight: 100.3 g

PLMServices 

Informational model

OAGIS 

ItemMaster noun

INSTANTIATION

Creator

Approval time

Length Location

Weight

Manufacturer

LotID

Product model: mouse model Real world product: my_mouse

Metadata of the mouse model

Creator: Tom

Approval time: 01-01-09

Location: C:\myDocuments\files

Metadata of my_mouse

Manufacturer: Henry & co.

Lot ID: 5647

Location: Target store n°576

Data of the mouse model

Length: 10.00 cm

Weight: 100 g

Data of my_mouse

Length: 10.01 cm

Weight: 100.3 g

PLMServices 

Informational model

OAGIS 

ItemMaster noun

INSTANTIATION

Creator

Approval time

Length Location

Weight

Manufacturer

LotID

Figure 5: Real world products and product models data 

Real world products are objects that can be seen and touched and exist in the real world: my_ 

mouse in Figure 5 is a real world object. Standards that represent real world products need to 

include both the metadata of the real objects, such as manufacturer and location, and the data 

such as length and weight. The data value of real world products (10.01 cm and 100.3 g in the 

figure) will have a direct correspondence with the data value represented in the product models 

(10.00 cm and 100 g in the figure). The metadata of the mouse model represent information such 

as the name of the model creator and the location of the model file. 

In OAGIS, the ItemMaster noun mainly represents a real world product (“a unique purchased 

part or manufactured product”) but also includes information of the product model: the metadata 

and data of both the real world product and its model are flattened in a unique noun. 

In OMG PLM Services, the informational model mainly represents product models: its 

instantiation is often done by CAD applications. Figure 6 represents, in UML, how the product 

model is connected to the real world products. 

9
Figure 6: Product model and real world product in OMG PLM Services 

The class Item represents the product model information that is common among all the item 

versions. Item_version, the class representing the product versions, collects all the information 

characterizing a physically realizable object: in practice it represents the product model of each 

version of a product. Each product version is depicted through several views; examples of these 

views are the assembly definition, collection definition or mating definition. The 

Design_discipline_item_definition class supports the representation of these views. Each view 

contains one or more Item_instances: they represent the occurrences of a product in a bill of 

material. An Item_instance is defined either by a Design_discipline_item_definition or by a 

Product_identification. A Product_identification identifies a manufacturable object and is 

connected to the product version through the class Product_design. 

The occurrence of a product in a bill of material can have its correspondent in the real world: the 

class Physical_instance represents a real world product. This real world product is connected 

through the class Physical_assembly_relationship to its super-assembly, which itself will be a 

Physical_instance. Physical_assembly_relationship is then connected to the Item_instance that 

10
the physical component is the realization of. Each Physical_instance is finally defined by a 

product model: the classes Product_identification or Design_discipline_item_definition collect 

the information defining the Physical_instance (Physical_instance_definition_select interface). 

The class Physical_instance represents the core concept for realizing the mapping between 

OAGIS and OMG PLM Services. Physical_instance corresponds to the engineering information 

contained in the ItemMaster noun and related to the real world product. 

Figure 7: Physical_instance as a core concept for realizing the mapping 

In Figure 7 the red arrow represents the first possible mapping between OMG PLM Services and 

OAGIS. The team implemented this mapping, as a proof of concept, by using XSLT (EXtensible 

Stylesheet Language Transformations) [21] files generated through MapForceTM [22]. An 

alternative mapping method, finally rejected by the team, used an Excel file to organize the 

XPath [23] expressions indicating the same concepts in the two standards. 

Figure 8 is a screenshot of MapForce: the two boxes at the center of the figure show in a tree 

representation the XMLschema files of the standards and the lines connecting them represent the 

mapping between the elements in each tree. The ItemMaster noun is mapped into the 

Physical_instance class and the primary ID of the ItemMaster is mapped into the serial_number 

attribute of Physical_instance. The serial_number attribute is defined by OMG PLM Services as 

the identifier that distinguishes one Physical_instance from another. 

11
Figure 8: MapForce screenshot of the Physical_instance mapping 

This first mapping provides the opportunity of testing the chosen mapping method and proves 

the feasibility of the goals set for this project. Since in OMG PLM Services there are few classes 

dedicated to the representation of real world products, this mapping covers, only to a limited 

extent, the intersection between OMG PLM Services and OAGIS. 

The major part of this intersection is related to the representation of product models, depicted in 

Figure 6 as EBOM for OMG PLM Services and MBOM for OAGIS. The project challenge is 

then to identify which information is common between the representation of product models in 

OMG PLM Services and OAGIS. 

3.3 Scenarios 

To address this issue the team decided to build a scenario 1 in which product models are 

instantiated and exchanged by two applications using the two standards. Both the standards 

contain, as part of their specification, the description of several scenarios, some of which already 

 

1

 For the purpose of this report, the terms scenario and use case are interchangeable. 

12
include the engineering change management. We report in Table 2 some examples of the 

scenarios contained in the specifications. 

Table 2: Examples of use cases in OMG PLM Services and scenarios in OAGIS 

Use cases in OMG PLM Services Scenarios in OAGIS 

 Export/import of assembly data 

 Browsing up/down the product structure 

data 

 Browsing of alternative solutions 

 Change notification 

 ECM participants comments 

 Catalogue exchange 

 ERP to finite scheduling and manufacturing 

execution 

 Plant data collection 

 Production synchronization 

 Engineering changes 

A comparison between these scenarios is hardly achievable since they strongly differ in scope 

and granularity. While the OMG PLM Services use cases model the engineering aspects of 

product-related data, the OAGIS scenarios model the business aspects. Moreover, the data 

needed to realize the OMG PLM Services use cases have a fine granularity, while the data 

needed for the OAGIS scenarios have a high level of aggregation. 

The most suitable scenario for this challenge is constituted by the Engineering Change 

Management (ECM). The communication, proposal, and acceptance of such changes represent 

the bridge between the manufacturing and the engineering worlds. In this scenario, during the 

manufacturing stage of products, some alterations to the product model need to be made. These 

alterations will affect the representation of the product model in both the engineering authoring 

tools (using OMG PLM Services) and the business authoring tools (using OAGIS). 

The OMG PLM Services specification includes four use cases for ECM: ECM participant 

proposal for a change, ECM participant comments, ECM participant approval and ECM 

participant detailing and comments. These uses cases were defined according to the 

Recommendation for Engineering Change Management Part 1: Engineering Change request 

(ECR) proposed by VDA [24], the German automotive industry association. Therefore these use 

cases do not include Engineering Change Order (ECO). These use cases provide a list of the 

messages exchanged by the actors for ECR; [24] describes how these messages are related to the 

informational model of OMG PLMServices. 

The OAGIS specification includes one scenario dedicated to ECM: scenario 49 “Engineering 

changes” (see Figure 9). 

13
Figure 9: ECM scenario in OAGIS 

In this scenario one or more design engineering systems are integrated with other manufacturing 

engineering systems and exchange BODs relative to the following nouns: 

EngineeringChangeOrder, BOM, and Routing. The engineering change request is originated by 

any department (stakeholders) and transferred to the engineering department. Once the 

engineering department approves the request, a notification of approval is sent from the PDM 

system to the stakeholders and the order for the execution of the change is sent to the ERP 

system, along with the new BOM of the product. The engineering change order is finally 

communicated to the manufacturing execution systems. 

Scenario 49 seems to address the requirements for the integration scenario of this project as it is 

focused on engineering information and it describes the integration of engineering and 

manufacturing systems, i.e., PDM and ERP systems, respectively. For the sake of this project, 

the team restricted this scenario to the exchange of the BOM messages between design 

engineering systems and manufacturing engineering systems (red oval in Figure 9). 

In this restricted scenario, a PDM system conforming to the OMG PLM Services standard 

exchanges the BOM information with an ERP system. While the PDM system contains the 

product EBOM, the ERP system needs the product MBOM to generate the manufacturing 

planning and the purchase orders. Figure 10 describes this scenario. 

14
ERP system

PDM system conforming

to PLMServices

getBOM

showBOM

1 2

3

Figure 10: A scenario for the harmonization 

The ERP system requires a BOM from the PDM system (getBOM BOD): the PDM system 

replies to this request by showing the BOM (showBOM BOD). To realize this scenario, the data 

of the PDM system, conforming to OMG PLM Services, need to be aggregated into the BOM 

noun. The research objective is then to understand how the information from OMG PLM 

Services is aggregated into the BOM noun. 

The mechanism of aggregation of the BOM noun is shown in red arrows in Figure 10: 

1) Some information in the BOM noun can be directly aggregated from the OMG PLM 

Services output file. For example, the Child/ParentBOM in the BOM noun could correspond to 

the product structure in OMG PLM Services (package Part Structure) 

2) Some information in the BOM noun is shared with the ItemMaster noun. For example, the 

information contained in ItemIDsGroup, Classification, Specification, and BOMReference are in 

common between the BOM and ItemMaster nouns. 

3) Some information in the ItemMaster noun can be aggregated from the OMG PLM Services 

file. For example, as previously explained, serial_number of Physical Instance in OMG PLM 

Services have a direct correspondent in ItemMaster. 

Understanding these three mechanisms becomes then the part of the future work of the team. 

15
4 Issues and Future Plans 

The initial work presented in this report contributed to reaching the following objectives: 

 Understanding each standard by identifying its scope, organization, and modeling 

philosophy 

 Designing one or more use cases (scenarios) to understand the integration issues 

 Recognizing the concepts that intersect both the standards 

 Identifying portions of the models that are part of the intersection 

 Realizing the harmonization 

In summary, the first part of the work was dedicated to prove the feasibility of harmonization, to 

define the research directions for its implementation and to understand the issues connected to 

the long-term objectives of the project, which is to develop a method for comparing and 

harmonizing standards. 

The main issue is about the different approaches adopted by the two standards towards modeling 

product information. The approach of OMG PLM Services is top-down: the informational model 

first defines a product model and then links it to actual products (or real world products). On the 

other hand, the approach of OAGIS is bottom-up: the information contained in the selected 

nouns mainly represents actual products and contains references to product models. 

These different approaches arise from the different domains addressed by the two standards. 

OMG PLM Services was conceived to be used in the engineering domain, where product models 

are planned and designed. As a consequence, the engineering objects described in OMG PLM 

Services mainly represent product models. OAGIS has a different prospective, covering other 

domains such as manufacturing, logistics and sales, and the information of real world products is 

the main focus. OAGIS flattens the real world object information and product model information 

as a unique model. 

The challenge still remains as to how to connect the representations of product models and actual 

products in a structured and formal fashion so as to accomplish the harmonization. To address 

this challenge we could explore the ideas implemented in the Athena project [25]. In the Athena 

project, the harmonization between proprietary formats and the standard BODs within the 

inventory domain is realized by creating an e-Kanban reference ontology [26]. The proprietary 

formats and the standard BODs are then mapped to this ontology, as a way to achieve 

harmonization. 

The team will also explore the possibility of creating a BOM reference ontology, to which both 

the PLM Services schema and BODs schema could be mapped. The BOM reference ontology 

should represent both the engineering and manufacturing BOM, and should incorporate 

information about both product models and real world products at different levels of granularity. 

This requires a clear and formal model of the BOM. This ontology could be organized in a multilayered architecture similar to MOF (Meta Object Facility) [27]. The concepts in each layer and 

the relationships between layers could be semantically defined. Semantic technologies could 

enable the harmonization; for example, languages based on description logic could enhance the 

formalization and allow the consistency checking between schemas and instances [28]. Once the 

16
17

PLM Services and BODs schemas are mapped to the appropriate layer of the BOM reference 

ontology, the direct mapping between PLM Services and OAGIS can be accomplished. 

To realize this, the team would need, as a first step, to analyze the concepts and requirements for 

the BOM reference ontology, paying particular attention to the representation of product models, 

actual products, and their relationships. For this analysis, the team could consider the scenario 

presented in the previous section: the BOM reference ontology would represent all the concepts 

necessary for the realization of that scenario. 

As a second step, the team would need to select a language expressive enough to represent those 

concepts. OWL-DL [29] or RDF [30] could be two of the candidate languages. To realize the 

mapping, these languages should be used not only to represent the BOM reference ontology, but 

also the PLM Services and BODs schemas. 

A first attempt towards a semantic version of STEP has already been presented in the OntoSTEP 

project [31]. In this project, the STEP EXPRESS schemas and their instantiations are translated 

into OWL-DL. In the future, the team could explore the opportunity of creating a semantic 

version of the OMG PLM Services informational model by applying the same principles adopted 

for the OntoSTEP project. In a similar way, an RDF version of some OAGIS BODs has already 

been created for the Athena project. The tool used in this project, i.e., AXTOR [25], could be 

exploited to generate the RDF versions of the ItemMaster, BOM, and EngineeringChange nouns. 

The OntoSTEP and Athena projects could then represent the starting point for “ontologizing” the 

PLM Services and OAGIS standards, respectively. 

As a third step, the “ontologized” versions of PLM Services and OAGIS should be mapped to 

the BOM reference ontology. First, for the purpose of harmonization, the team will identify the 

concepts in the BOM reference ontology that are part of the intersection between the two 

standards. Second, to realize the scenario, the team will identify the ownership of the concepts 

that are not part of the intersection but are still represented in the BOM reference ontology. For 

example, the data related to the supplier identification and lot size are represented in the BOM 

and ItemMaster nouns but do not have an equivalent in PLM Services; these data will be then 

owned by OAGIS. As another example, the data related to tolerances and assembly relationships 

are represented in PLM Services but do not have an equivalent in OAGIS; these data will then be 

owned by PLMServices. 

The principles and ideas applied in this project, its results and the experience gained during its 

realization could finally be summarized to achieve long term goals: the team could develop a 

generic methodology for comparing and harmonizing information standards. This methodology 

will be based on semantic technologies and will be aligned with the vision of both the standards 

and semantics communities [32]. 

Disclaimer: No approval or endorsement of any commercial product by NIST is intended or implied. 

Certain commercial equipment, software, instruments or materials are identified in this report to facilitate 

better understanding. Such identification does not imply recommendations or endorsement by NIST nor 

does it imply the materials, software, or equipment identified are necessarily the best available for the 

purpose. 

Acknowledgement: The authors would like to acknowledge the comments and suggestions of Professor 

Steven Fenves, NIST Associate, in improving the report but any residual mistakes remain ours. 
5 References 

[1] ISO 10303-1:1994, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 1: Overview and fundamental principles. 

[2] OMG PLM Services v2.0. http://www.omg.org/cgi-bin/doc?dtc/07-05-01, 2007 

[3] Open Applications Group Integration Specification. www.oagi.org, 2008 

[4] The Object Management Group (OMG). http://www.omg.org/, 2009 

[5] OASIS: Organization for the Advancement of Structured Information Standards. www.oasisopen.org, 2006 

[6] The Open Application Group (OAGi). www.oagi.org, 2009 

[7] Srinivasan, V., "An Integration Framework for Product Lifecycle Management," ComputerAided Design, Vol. In Press, 2009. 

[8] Model-Driven Architecture. http://www.omg.org/mda/, 2004 

[9] ISO 10303-214:2003, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 214: Application Protocol: Core data for automotive 

mechanical design process. 

[10] PDTNet, Project Information. http://www.prostep.org/en/standard-info/pdt-netprojekt.html, 2000 

[11] PDM Enablers v1.3, Final Report. http://www.omg.org/cgi-bin/doc?dtc/2000-06-02,

2000 

[12] eXtensible Markup Language (XML). http://www.w3.org/XML/, 2005 

[13] Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl, 2001 

[14] ISO 10303-11:2004, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 11: Description methods: The EXPRESS language 

reference manual. 

[15] ISO 10303-14:2005, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 14: Description methods: The EXPRESS-X language 

reference manual. 

[16] XMI Mapping Specification. 

http://www.omg.org/technology/documents/formal/xmi.htm, 2007 

18
19

[17] UML 2.0 Superstructure Specification. http://www.omg.org/cgi-bin/doc?ptc/03-08-02,

2003 

[18] Minakawa, G., Ramanathan, S., and Rowell, M.. OAGIS 9 Naming and Design Rules 

Standard. Open Applications Group, 2005. 

[19] The United Nation Centre for Trade Facilitation and Electronic Business (UN/CEFACT). 

http://www.unece.org/cefact/, 2009 

[20] M.Rowell.. UN/CEFACT XML Naming and Design Rules Version 3.0. United Nations 

Centre for Trade Facilitation and Electronic Business, 2008. 

[21] XSL Transformations (XSLT) Specification. http://www.w3.org/TR/xslt, 1999 

[22] MapForce. http://www.altova.com/products/mapforce/data_mapping.html, 2009 

[23] XML Path Language Specification. http://www.w3.org/TR/xpath, 1999 

[24] Recommendation for Engineering Change Management Part 1: Engineering Change 

request (ECR). 

http://www.vda.de/en/publikationen/publikationen_downloads/detail.php?id=382&PHPSESS

ID=c06rqaevgrmhlhou5n430i5qs7, 2006 

[25] ATHENA project: Advanced Technologies for interoperability of Heterogeneous 

Enterprise Networks and their Applications. http://www.athena-ip.org/, 2004 

[26] Barkmeyer, E. J., and Kulvatunyou, B., "An Ontology for the e-Kanban Business 

Process," National Institute of Standards and Technology, NISTIR 7404, 2007. 

[27] Meta Object Facility (MOF) Specification. http://www.omg.org/docs/formal/02-04-

03.pdf, 2002 

[28] Fiorentini, X., Rachuri, S., Mani, M., Fenves, S. J., and Sriram, R. D., "An Evaluation of 

Description Logic for the Development of Product Models," National Institute of Standards 

and Technology, NISTIR 7481, 2008. 

[29] Web Ontology Language (OWL). http://www.w3.org/2004/OWL/, 2005 

[30] Resource Description Framework (RDF). www.w3.org/RDF/, 2006 

[31] Krima, S., Barbau, R., Fiorentini, X., Rachuri, S., and Sriram, R. D., "OntoSTEP: OWLDL Ontology for STEP," National Institute of Standards and Technology, NISTIR 7561, 

2009. 

[32] OntologySummit 2009 Communiqué: Toward Ontology-based Standards. 

http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2009_Communique, 2009.