NISTIR 7917 

Modeling and Conformance Testing 

for the Engineering Information 

Integration Standard ISO 15926 

Peter Denno 

Mark Palmer 

 

http://dx.doi.org/10.6028/NIST.IR.7917
NISTIR 7917

Modeling and Conformance Testing 

for the Engineering Information 

Integration Standard ISO 15926 

Peter Denno 

Mark Palmer 

Systems Integration Division 

Engineering Laboratory 

http://dx.doi.org/10.6028/NIST.IR.7917 

February, 2013 

U.S. Department of Commerce 

Rebecca Blank, Acting Secretary 

National Institute of Standards and Technology 

Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director 
1

ABSTRACT

The process and power industries and their suppliers have invested in multiple initiatives to develop and deploy a 

new information exchange and integration standard, ISO 15926, Industrial automation systems and integration —

Integration of life-cycle data for process plants including oil and gas production facilities. Although the potential 

benefits of this standard have been demonstrated in pilot projects, broad, cost-effective deployment may require

improved methods, tools, and testing. This publication identifies requirements for successful implementation of 

ISO 15926-based information exchange. Currently there exists a draft methodology for information modeling with 

ISO-15926, documented in a patchwork of ISO-approved and draft-status documents, and supplemented by 

documents produced by industry projects [1], [2]. However, there are variations and no consensus as to the 

criteria for achieving interoperability. There are reasons to believe that successful implementation of ISO 15926 -

based exchanges will require substantial refinement of the methodology. Further, there are many more 

requirements for successful implementation – matters of technical sufficiency and organizational responsibility –

that have received insufficient attention. This publication summarizes our assessment of the current landscape, 

presents a set of principles for successful implementation, and provides recommendations for addressing 

challenges.
2

Executive Summary

The process and power industries and their suppliers have invested in multiple initiatives to develop 

and deploy a new information exchange and integration standard, ISO 15926, Industrial automation 

systems and integration —Integration of life-cycle data for process plants including oil and gas 

production facilities [3]. Although the potential benefits of this standard have been demonstrated in 

pilot projects, improved methods, tools, and testing are needed to enable broad, cost-effective 

deployment. This publication takes a systems view of the resources that have come together to develop 

and deploy ISO 15926.1 We examine whether the system, as it now exists, is sufficient and effective in 

providing the interoperability that the stakeholders seek. 

This publication presents a set of principles for successful development and deployment of 

information exchange and integration standards. By examining the current process and infrastructure 

for ISO 15926, and comparing it with successful standardization efforts, the publication identifies areas 

for improvement and “missing components.” Currently, there exists a draft methodology for 

information modeling with ISO-15926, documented in a patchwork of ISO-approved [3], [4], [5] and 

draft status documents [6], [7] , and supplemented by documents produced by industry projects [8]. 

However there are numerous variations and no consensus as to the criteria for achieving 

interoperability. This publication argues that the key activities for improving the delivery and use of ISO 

15926 are the addition of a program of validation, conformance and interoperability testing, the use of 

domain conceptual modeling, and the development of a roadmap for completing the infrastructure and 

standardization of ISO 15926.

 

1 NIST contributes to the development of ISO 15926.
3

Contents

1 Introduction................................................................................................................................4

1.1 Principles for the Development of Information Integration Standards .....................................6

2 Implementation Scenarios of ISO 15926 .......................................................................................7

3 Conformance Testing ..................................................................................................................9

3.1 Challenges in Conformance Testing.......................................................................................9

3.2 Successful Implementation of a Testing Program .................................................................10

3.3 Recommendations in Testing..............................................................................................11

4 Information Modeling ...............................................................................................................12

4.1 An Outline of Information Modeling with ISO 15926 ............................................................12

4.2 The Roles of Reference Data Libraries .................................................................................13

4.3 Recommendations in Information Modeling........................................................................14

5 Roadmap for ISO 15926 Development........................................................................................17

6 Conclusions...............................................................................................................................18

7 References................................................................................................................................19
4

1 Introduction

The organizations that come together to create an exchange standard function as a system. 2Viewed 

as a system, the domain experts, software implementers, information modelers, modeling procedures 

and technologies, conformance checking tools, and other “components” interact to serve a principal 

high-level goal: reduce the cost incurred in business interaction. The “system” serves this goal by 

providing many forms of guidance to the various stakeholders. The most fundamental guidance is 

embodied in the exchange standard specifications, but supplementing that typically are procedures for 

information modeling and testing, and, in the case of ISO 15926, for the development and use of 

reference data libraries. 

This publication takes a systems view of the resources that have come together to develop and 

deploy ISO 15926. We examine whether the system, as it now exists, is sufficient and effective in 

providing the interoperability that the stakeholders seek. The publication identifies areas for 

improvement and “missing components” through comparison with successful information exchange and 

integration standardization efforts. It proposes solutions and recommendations for improving the 

development and deployment. It covers issues at the leading edge of ISO 15926 implementation 

experience. It does not provide an introduction to ISO 15926.

Good systems engineering starts with a characterization of what the system must achieve. Therefore, 

we explain in Section 1 the role of exchange standards in successful interoperation and essential 

characteristics for successful standards development and deployment. In Section 2, we build on the 

basic view of interoperability presented in Section 1 with a discussion of use cases for ISO 15926. In 

Section 3 we consider the roles of conformance and interoperability testing. In Section 4 we discuss 

information modeling with ISO 15926. In Section 5 we consider how the resources directed at ISO 15926 

might be better organized. We conclude discussion in Section 6 with a summary of our 

recommendations for improving development, deployment, and the standardization process.

To interoperate is to work jointly toward a shared goal. Communication enables interoperation by 

orchestrating “components” to achieve together the joint work. As illustrated in Figure 1, one 

component, seeking to elicit a particular behavior3from another, formulates a message to send to the 

other component that the originating component deems appropriate given the goal it intends to 

achieve. The receiving component needs to interpret that message and exhibit a behavior that it deems

appropriate. This is all so fundamental to communication that we usually overlook it. If I say "Please pick 

up your end of the table" and instead you open a window, our collaborative work starts to go wrong. 

 

2

A system is an assembly of resources and procedures united and regulated by interaction or interdependence 

to accomplish specific functions. [22]

3

It is not necessary that the message explicitly specifies the intended behavior. In some situations, the 

behavior may be implied, and the message serves to identify relevant elements of a shared universe of discourse. 

Essentially, the message might say “Process that one.”
5

Figure 1: Specifications are used in both the development and the testing of interfaces. At (1) the Sending System identifies a 

task for which it intends to collaborate with the Receiving System. At (2) it produces a message it deems appropriate. At (3) 

the Receiving System decodes the message and produces a behavior, which is either (4’) an action the Receiving System

takes to change the environment, or (4) a message to the Sending System, which that system uses to affect the environment

itself. In ISO 15926 specifically, the production and interpretation of the message structures may involve use of a Reference 

Data Library.

Most of the trouble relates to those two occurrence of “it deems appropriate“ in the previous 

paragraph. Note that there are necessarily separate parties guided by specifications but acting 

independently in judging what is appropriate with regard to the message; one is “encoding” the 

message, the other (or others) are “decoding” it. How do they recognize what is appropriate? What 

provisions and safeguards exist to ensure that communicating parties will recognize the (possibly finegrained) distinctions intended to guide behavior? Typically, in answer to these questions, we may point 

to:

 agreement on the meaning of terms used in communication.

 agreement on how sentences are to be encoded and exchanged.

 a program of testing that confirms that communication performed as specified by the 

agreements will achieve the intended result.
6

Concerning the first bullet above, every standards development organization (SDO) that focuses on 

business or engineering collaboration needs a strategy describing how stakeholders will reach and 

document consensus on the meaning of terms used in exchanges; “conceptual modeling” often serves 

this purpose. The strategy might be as loose as allowing collaborating partners to work out meanings ad 

hoc. In contrast, the SDO might focus on developing a formal ontology where fine-grained distinctions 

among concepts are formulated and rules constraining usage can be enforced. 

Likewise with regard to the second bullet, every SDO focused on business collaboration needs a 

strategy describing how “sentences” (the smallest meaningful units of exchange) are encoded and 

exchanged. Sometimes the choice of encoding and exchange technology is linked to the choice of 

technology for conceptual modeling. An example of this relationship is Web Ontology Language (OWL) 

[9] for representation and Resource Description Framework /Extensible Markup Language (RDF/XML)

[10] for exchange.

Finally, regarding the third bullet, stakeholder organizations may implement testing procedures to 

improve the likelihood of interoperable exchange among tools implementing the standard. These 

include conformance testing and interoperability testing. Conformance testing assesses the degree to 

which a tool claiming to implement a standard meets the normative elements of the specification. 

Interoperability testing assesses the degree to which communication directs behaviors to intended ends. 

Typically, conformance and interoperability testing will rely on an artifact documenting consensus on 

the meaning of terms and required capabilities.

1.1 Principles for the Development of Information Integration Standards

The success of an SDO depends on the abilities of its contributors, the technology it embraces, and the 

operating procedures it establishes. Key principles that have emerged include: 

1. define a technical architecture.

1.1. select modeling technologies and methods that are adequately expressive and supported by 

tools for modeling and conformance testing.

1.2. document the rules for consistent use of these methods and tools.

1.3. define the roles of architectural components (e.g., reference data libraries).

1.4. develop methods for encoding and communicating information.

2. document a development strategy in a roadmap for infrastructure and standardization.

2.1. identify the scope of each planned specification consistent with its role in the technical 

architecture.

2.2. define viable increments of capabilities for deployment.

3. develop procedures, test suites, and tools for conformance and interoperability testing.

4. establish procedures for vetting and validating fitness-to-purpose of the components of the 

standard.

5. establish the support of stakeholders for collaborative testing and prototyping.

6. establish the support of implementers to the roadmap plans for deployment and standardization.

7. demonstrate the feasibility of proposed solutions before standardizing them.
7

The ISO 15926 development community has adopted many of these principles to varying degrees. 

The ISO 15926 Real-time Interoperability Network Grid (iRING Tools) effort [11] is developing modeling 

methodology and tools (1.1) and rules for the use of an “upper ontology” (1.2, 1.3). The Joint 

Operational Reference Data (JORD) initiative [1], [2] is contributing to 1.1-1.3 and to procedures for 

conformance testing (3). However, at present, there are significant gaps in coordination and alignment 

of priorities among industry efforts. Although there have been a number of pilot projects to assess 

various implementation formats and procedures, the ISO 15926 community has made only a modest 

effort toward defining and implementing conformance testing. Testing is discussed in Section 3 of this

publication.

2 Implementation Scenarios of ISO 15926

The architecture and implementation methods for ISO 15926 have evolved since Part 1, Overview 

and fundamental principles, was published in 2004. Therefore, with a view toward identifying methods 

of testing consistent with new implementation technology, in this section we identify technologies most 

likely to be applied in the modeling and management of ISO 15926-based information. Table 1 lists the 

planned parts of ISO 15926 and their current status in the ISO standardization process. 

The ISO 15926 community has investigated and adopted new methods for information modeling and 

implementation since the publication of Part 1. Some of these methods are not common practice and 

have not been tested sufficiently to move into commercial tools and contracts. For industry to have 

confidence in adopting and deploying ISO 15926, the core set of ISO 15926 parts must be completed as 

a cohesive and tested standard. To address this need, at the November 2012 meeting of the ISO

TC184/SC4 SDO, NIST submitted recommendations for developing a “Roadmap for the Infrastructure 

and Standardization of ISO 15926,” including initiating work on a new Part 10, Conformance testing and

to focus on viable increments of capabilities that would be implemented by software vendors.

Table 1: Parts of ISO 15926.

Part # Title Status

1 Overview and fundamental principles International Standard (IS) ed.1 

published June 2004

2 Data model IS ed 1 published Dec. 2003

3 Ontology for geometry and topology Technical Specification (TS) ed. 1 

published April 2009

4 Initial reference data TS ed. 1, published Oct. 2007

5 (withdrawn) Replaced by SC4 “Procedures for 

the maintenance of ISO 

TC184/SC4 reference data”

6 Scope and methodology for reference data TS, ballot comments being 

resolved 

7 Template methodology TS published October 2011

8 OWL Representation TS published October 2011

9 Implementation methods for the integration of distributed 

systems – Façade implementation

Under development
8

10 Conformance testing Not started (previous proposed 

title: Abstract test methods)

11 Methodology for simplified industrial usage of reference 

data

Under development, draft 

distributed for review Nov. 2012

12 ISO 15926 as OWL 2 – Implementation with named graphs Proposed

This publication focuses on the use of Parts 2, 4, 7, 8, and 9 for achieving interoperability. In ISO 

15926, information, excluding reference data library (RDL) entries, is exchanged in Part 7 templatebased structures. A choice exists: information may be encoded concisely based on the template 

signature (the “lowered form”) or verbosely based on the Part 2 ontology building blocks in the 

template expansion (the “lifted form”). A note in Part 8 (Clause 7.4) states that the choice to store and 

exchange in lifted form versus lowered form is a business decision out of scope of the specifications.4

[12]

None of the implementations used by Fiatech [11] nor POSC/Caesar initiatives [8] store or exchange

information in lifted form. Storage in lifted form is problematic in that without explicit knowledge 

associating each stored element with a template instance, multiple templates might apply, each 

referencing some of the same stored elements; boundaries might overlap. Thus it may not be clear what 

the stored information is intended to represent. Part 8 [12] seems to recognize this problem and 

mentions the need to maintain “metadata” about the template to avoid loss of information (Section 

7.4), but none of the current Parts for ISO 15926 specify how this metadata is to be related to Part 2 

building block elements. In light of the above, we assume that the dominant method of exchange will be 

data encoded in the lowered form based on the template signatures. 

Since templates are used in exchange and they are also a means of information modeling, it might be 

assumed that template specification will be the dominant method of information modeling in ISO 

15926. This, however, is not so clear. We assume that the specialization of RDL classes and base 

templates will remain an important activity in the SDO, but we recommend in Section 4 that significant

modeling activity occur using domain conceptual models with the RDLs. 

Assuming that the atomic units of communication are Part 8 template-based, decisions still remain to 

be made regarding methods of communication. The JORD Compliance Specification [2] describes

“change-management functional categories” representing various degrees of shared awareness among 

the communicating systems. Though that document suggests that these are ordered by “compliance 

level,” this is not quite accurate.

5

They are implementation choices currently not addressed by ISO 

15926 documentation.

 

4

Yet Clause 7.1 of the same part says “Where the lowered template provides the structure for data to be 

exchanged using the template, and the lifted template provides a definitional mapping of the lowered template to 

the data model and reference data of ISO 15926.”

5

Further, what the JORD Compliance Specification calls “Semantic Compliance Categories” correspond to levels 

of ability to perform conformance testing. There is a difference between this and levels of conformance.
9

3 Conformance Testing

At present, there is insufficient engagement from commercial software vendors in testing the 

feasibility and efficiency of ISO 15926 practices. Recent industry pilot projects of ISO 15926, including 

the operations and maintenance alliance MIMOSA, and POSC Caesar Association (PCA) Oil and Gas 

Interoperability (OGI) Pilots [8], have confirmed the lack of methods for defining and assessing 

conformance to ISO 15926 and that this is a major barrier to industry adoption.

3.1 Challenges in Conformance Testing

In principle, conformance testing should be straightforward. Determining that a normative 

requirement has been met (that is, conformance testing) involves two key tasks:

Task 1: formulating the statement of the requirement, and

Task 2: relating the formulated statement to the elements that claim to conform. 

In practice, conformance testing is often muddled by imperfections in how these two tasks are 

realized. To begin, difficulty in conformance testing can often be traced to a lack of formality in the

specifications of the requirements. Ideally, in Task 1, normative requirements are stated in a formal 

language (e.g., EXPRESS, OCL, or a logical language), and a software tool is written to compile these 

formal specifications into executable tests. Without the formal specification, developers of testing tools 

must create custom code to check requirements expressed in natural language text. This code will

necessarily be based on the tool developer’s interpretation of what is intended. The cost of working this 

way can be prohibitive.

Even when requirements are formally stated, their clarity and power to constrain interpretation can 

be inadequate because of limitation in the formal language, because the requirements are ambiguously 

stated, or typing is lax. For example, in Part 2 the approver role of an approval relation can be any 

possible_individual (e.g., a pipe can be an approver). Typing serves to constrain the roles played in 

relationships. In this example, ideally, the approver would be something capable of making decisions. 6

The identification of effective types in an upper ontology7is a difficult problem. But additionally, in 

writing the specification, one must be careful not to posit conceptualizations that are not supported by 

type structures. For example, in ISO 15926 Part 2 there is a specialized notion of property called 

indirect_property which applies to the same class of entity (possible_individual) as the more general 

notion, property. In fact, our experience suggests that indirect_property applies where the possessor is 

an encoded abstraction (such as the specification of a class of pressure transmitter described in a data 

sheet) and that property applies in all other cases of a physical instance (such as the pressure 

transmitter PT-002 installed at location A-576 in the plant on November 5, 2012). But the sense of 

encoded abstraction and physical instance that we are speaking of here are not found in ISO 15926. A 

consequence of this design is that information modelers are likely to incorrectly apply property and 

 

6

Strictly speaking, this discussion does not concern conformance testing, since lax typing does not impair the 

ability to perform the test. But lax typing makes testing less useful toward ensuring interoperability.

7

Part 2 is an upper ontology.
10

indirect_property, and conformance tool developers must either apply their own interpretation of the 

context in which the requirement applies or ignore the requirement entirely.

Further, Part 2 misses some opportunities to enforce its natural language statements of 

requirements with formal axioms. Admittedly, every upper ontology will contain some concepts that are 

primitive – their meaning cannot be defined in the ontology. We limit the following to requirements that 

could have been stated formally in EXPRESS [13]:

 4.6.2 (possible_individual) “No two individuals have the exactly the same space-time 

extension.”

 4.7.8 (whole_life_individual) “A whole_life_individual is a space-time extension that is 

not a temporal part of any other individual that is of the same class.”

 4.7.8 (whole_life_individual) “are individuals whose identities are considered to be 

independent of one another.”

 4.7.9 (arranged_individual) “The properties, characteristics, and behaviors of an 

arranged individual are different from those of its individual parts.”

 4.7.10 (event and point_in_time) “One-time events are always a part of a 

point_in_time.”

 4.7.11 (period_in_time) “A period_in_time is a possible_individual that is all space for 

part of time – a temporal part of the universe.”

 5.2.1.1 “An abstract_object is a thing that does not exist in space-time.”

Additionally, some of the above refer to “space-time,” and indeed there are entities that might 

represent space-time, but there is scant guidance on how it is to be done.

3.2 Successful Implementation of a Testing Program

An example of an effective interoperability and conformance testing program is provided by the 

Object Management Group (OMG) [14]. Formulation of conformance requirements (Task 1, above) is 

enabled by a metamodel included with every OMG specification. The metamodel encodes constraints 

described in the text of the specification, much as the EXPRESS schema of Part 2 does for ISO 15926. The 

metamodel is stated using a subset of UML called the Meta-Object Facility (MOF) [15] and an 

accompanying lexical language called the Object Constraint Language (OCL). 8[16] The application of the 

constraints to populations (Task 2), is straightforward because objects in the population explicitly 

declare their type. 

The OMG has chartered its Model Interchange Working Group (MIWG) to operate an interoperability

testing program. This group, comprised of software vendors and other interested parties, uses a 

consensus-based process to produce test cases consisting of reference diagrams and exchange files. 

Participants in the testing, which include the great majority of suppliers of UML-based modeling tools, 

produce models based on the reference diagrams and serialize these as exchange files. They then use a 

 

8

The MOF and OCL are analogous to (respectively) ISO EXPRESS entity definitions and expression language 

used for global and WHERE rules. Note however that ISO 15926 Part 2 contains no expression language rules.
11

“model diffing” tool produced by NIST to confirm that their exchange file contains objects identical to 

those in the reference file. The diffing activity is an enhancement over the original procedure performed 

during the first two years of the MIWG program. In the original procedure, each participant shared the 

exchange file that they produced with all other participants. The participants imported the exchange 

files of other participants and reported the result. The original process was more costly than the new 

process, but served to resolve rudimentary interoperability problems that would have hamstrung the 

newer process.

Interoperability testing programs can effectively use conformance testing as a means to 

interoperability; in the process, specifications are improved. Clearly, conforming to an exchange 

standard is not necessary to interoperation; parties can make ad hoc agreements about content that 

work well. In fact, in the early stages of the development of the MIWG, the consensus of participants 

was that the work was to be solely about the interoperation of the tools of the active participants. It was 

only after some experience with the costly procedure of importing and verifying the files of the several 

other participants that each participant came to see the benefits of focusing their effort on 

conformance. To support conformance assessment, the MIWG relied on a set of tools (beyond the 

model diffing tool mentioned) to assess the conformance of exchange files. These tools (also provided 

by NIST) evaluated the elements of the exchanged model for consistency of type and cardinality. The 

tools also evaluated the OCL rules of the metamodel and well-formedness of the exchange form. The 

MIWG participants used the conformance reports to correct problems in their tools. The conformance 

reports also identify flaws in the subject metamodels themselves. These are communicated back to the 

OMG.

Though the technology differs, a program for testing ISO 15926 can follow the basic structure 

developed by the MIWG. In the MIWG, reference diagrams serve to describe challenge problems 

focused on the exchange of a particular collection of related concepts. In ISO 15926, the scope and 

detailed requirements of a challenge problem (an exchange scenario) can be described in text, with 

references to relevant RDL entries. Reference exchange files or RDF named graphs, vetted by experts, 

can be produced for each challenge problem. Just as in the MIWG, these can be maintained in a library,

for use by anyone at any time; their usefulness is not restricted to the period of time in which the formal 

testing program operates. Parties interested in assessing the exchange capabilities of their tools can

access these files and graphs and either (depending on what is being tested) confirm that their tool can 

produce a file with content and form matching the reference file, or confirm that their tool can read the 

reference file and establish the appropriate state in their system.

3.3 Recommendations in Testing

The ISO 15926 SDO has yet to define a plan for conformance testing. As discussed in Section 3.1, the 

path forward is impeded by the lax nature of requirements specification in ISO 15926, minimal 

experience with implementation, and the variety of possible implementation scenarios. NIST believes

that a vibrant conformance testing program will be essential to the success of ISO 15926. We are 

developing a conformance checking tool for template-based information, and we have initiated projects 

with industry stakeholders to identify the key impediments to interoperability with ISO 15926. We 
12

believe that with the addition of new methods and tools for conformance testing, and by leveraging our 

experience with the OMG’s MIWG and other standards development efforts, interoperation will be 

more easily achieved, and industry stakeholders will find adoption of ISO 15926 increasingly beneficial. 

The NIST conformance testing tool will examine template-encoded instance information for 

conformance to the requirements specified in the template definitions (specifically the template axiom) 

and thereby for conformance to Part 2 and Part 7. Currently, the tool reads template definitions in Part 

8 OWL2 XML serialization9and reports on inconsistencies in the formulation of the template. We are 

extending the capabilities of the tool to address template-encoded instance information. 

4 Information Modeling

4.1 An Outline of Information Modeling with ISO 15926

Information modeling using ISO 15926 relies on three principal components: an upper ontology, 

template definitions, and reference data libraries (RDLs). The upper ontology is specified by Part 2. The 

form of template definitions and an initial set is defined by Part 7, and the form and base content of an 

RDL is specified by Part 4. 

The upper ontology specified by Part 2 provides a collection of basic concepts and relationship types 

for modeling. Comparison of Part 2 with other upper ontologies (SUMO [17], DOLCE [18]) is difficult. 

Certainly, Part 2 is more focused on serving also as a data model, and on describing information 

technology elements such as classes and identifiers. It contains fewer enforceable constraints than most 

upper ontologies. (See the discussion of conformance testing above.) In the modeling methodology, the 

principal purpose of Part 2 is to define base types and relations for template roles. Base types are 

specialized in the RDLs.

A Part 7 template is a mapping of an n-ary relation (called a template signature) to a collection of 

upper ontology elements defined in Part 2. The mapping describes a correspondence between roles on 

the signature side and Part 2 elements on the ontology building block side. The specification of a 

template also includes a description of the intended usage, diagram of lifted elements, and a usage 

example.

A reference data library is, in the words of ISO 15926 Part 4 Clause 3.2.8, a managed collection of 

“process plant life-cycle data that represents information about classes or individuals which are 

common to many process plants or of interest to many users.” The base content specified by Part 4 is 

comprised of 20 tables of content in areas including piping, properties, valves, instruments and units of 

measure. Together there are about 10,000 items defined in these tables.

The intent of RDLs is that the classes that they define can be extended by stakeholder specializations. 

The RDL contains provisions to identify what source or authority created each class entry, so it is 

possible to identify the context and basis for the definition of the class. The most general classes defined 

in the RDL correspond to Part 2 ontology classes; the most specific are the specialization provided by the 

 

9

and other forms, such as some spreadsheet content, for which some custom coding was necessary.
13

stakeholders. The most general classes specify the role types of the most general templates; more 

specific classes specify the role types of more specific templates. However, the specialization of a 

reference data class should not, in itself, motivate the specialization of any templates. Specialization 

should be used to signify a distinction that must be communicated in exchange; if no such distinction is 

required, neither is specialization.

The three components, Part 2, RDLs, and template definitions are used together to provide a method 

of information modeling. The method delivers templates specialized to domain requirements as 

independent units of representation, in the sense that there is no conceptual model which identifies the 

collection of templates as elements of a larger domain of conceptualization.10

4.2 The Roles of Reference Data Libraries

For practical reasons, the management of reference data may benefit from tighter control than that 

suggested by the ISO 15926 specifications. Part 1 describes the ordering of reference data classes by 

specialization, in which the most specialized classes are proprietary and typically maintained by a single 

commercial organization, whereas the most general classes are stable and defined by consensus. [3] The 

JORD Compliance Specification [2] identifies four levels of authority and validation in RDL entries: 

sandbox level, global industry level, PCA / JORD level, and ISO level. However there is no discussion of 

how validation would differ at these levels and how duplication and alignment will be managed. The 

peculiarity of the predicament is that general classes (e.g., “pump”) would be the entries defined with 

the fewest constraints and the specializations defined by a manufacturer of pumps (e.g., “our axial flow 

pump with variable pitch blades”) could require more constraints.

In fact, the ISO subcommittee responsible for ISO 15926, TC184/SC4, recently reorganized to address 

the control of RDLs across SC4 standards. In November 2012, SC4 established Working Group 22 toward 

this end. [19] However, there are already multiple industry initiatives developing RDLs intended for use 

with ISO 15926, and WG22 has not yet established a date by which SC4 will have an operational 

reference data library.

If RDLs are to have a role in enabling inter-organizational communications, organizations specializing 

existing terminology will need to identify the distinctions they have in mind. Currently, there is very little 

effort being made toward this goal. To illustrate, we recently searched the PCA RDL for concepts similar 

to “rated operating pressure.” We found also “maximum operating pressure,” “upper limit static 

operating pressure,” “upper limit safe operating pressure,” “upper limit operating pressure at design 

temperature,” “rated operating pressure,” “upper limit required pressure,” and several others focused 

on inlets, outlets, and supply. Neither the textual definitions of these terms, nor the subtyping were 

helpful towards identifying what distinctions were intended – if any were. The quandary with “rated 

operating pressure” may reflect unnecessary proliferation of terms. It may be the case that there is no 

significant distinction in meaning intended by some of the terms. The proliferation of such terms can 

 

10 Part 8 introduces the concept of an Object Information Model (OIM). The OIM is intended to relate 

properties (their templates) to the object types on which they are defined. But only a few pages are dedicated to 

this idea; it is not thoroughly developed. 
14

only hinder interoperability. When the definition of a term (the definiens) is vague, and the term itself 

(the definiendum) does not appeal to the modeler, the inclination of most modelers will be to add the 

term his organization uses and not identify it as a synonym. Conversely, when working independently (in 

isolation), modelers cataloging their terms miss opportunities to highlight fine-grained distinctions 

among their terms – they simply are not aware that anyone might view things differently. In these cases 

they do not include in their definitions provisions that would force the distinction to be made. 

Unprincipled specification of an RDL may not serve interoperability.

The current state of ISO 15926 RDLs raises many questions: What belongs in an RDL and why? What 

level of coordination is appropriate? How much effort should be expended in ensuring that fine-grained 

distinctions are stated and organized? Answers to these questions depend on what purposes you intend 

the RDL to serve. The mainstream Semantic Web answer is that heterogeneity is inevitable and that 

there is value in getting content on the web whatever the form. But the role of the RDL in ISO 15926 is 

certainly more demanding than that. The RDL has a specific role to play in interoperable exchange; its 

entries specify the types declared in template roles. What is needed then is a framework that ensures 

that types can be organized to serve interoperability – that, for example, whatever is intended by the 

concepts around “rated operating pressure” is comprehensible to interface programmers. Additionally 

one might seek an RDL design that supports conformance testing. This almost necessarily entails formal 

specification of definitions and constraints – the idea of associating domain axioms with classes in the 

RDL. This is a key new activity that we believe the ISO 15926 SDO should pursue.

4.3 Recommendations in Information Modeling

The idea of a domain ontology integrated with reference data presents issues in the scope of the ISO 

15926 architecture. Associating domain axiomatic constraints to classes in the RDL enables a level of 

conformance checking beyond what is called the “Full Ontology Level” in the JORD Compliance 

Specification. [2] That level of checking only concerns what can be represented using templates and Part 

2, it does not concern RDL content. Part 2 is a data model and an upper ontology. In its present form, it 

is probably an insufficient foundation for a domain ontology supporting reference data. Some of our 

rationale for this position is provided in the discussion of conformance testing in Section 3 of the 

publication. Nonetheless, it is likely that a significant portion of Part 2 could be directly used in the 

foundational ontology. The result could still be consistent with established template definitions, for 

example. There is currently a PCA activity to investigate an OWL2 formulation of Part 2. [20]

Development of template specialization is also an area where improvements can be made. 

Discussion of domain conceptual modeling in ISO 15926 parts is scant. Part 2 is too abstract to be seen

as a domain model, and the Part 8 notion of an Object Information Model (OIM) is not discussed in 

sufficient detail. This is unfortunate. Conceptual modeling can serve many purposes, but most 

importantly to ISO 15926, it can serve to document concepts and distinctions conveyed in

communications. This documentation can be used in inter-organizational settings to identify differences 

in how the various stakeholders view the domain. Where differences are identified, mappings from one 

viewpoint to another can often be defined. We believe that domain conceptual modeling can be an 

important part of successful use of ISO 15926; this section discusses how.
15

There are at least two threads of activity in template-based information modeling11 currently 

underway in the ISO 15926 SDO. One of these is defining templates intended to be widely applicable, 

the other is modeling a collection of information common to several stakeholders using specializations

of existing templates and existing RDLs. The former is being performed by the POSC Caesar Association

(PCA) Modeling, Methods and Technology (MMT) Special Interest Group (SIG), the latter by the iRING 

ISO 15926 Information Pattern (IIP) project. The MMT SIG template work is complementary to the iRING 

IIP project in that the templates used in the IIP project modeling can be specializations of those specified 

by the MMT SIG. 

The iRING IIP project brings together a broad range of participants with good representation by the 

relevant software vendors. The stated scope of the work of the requirements subgroup is software 

interfaces for design, procurement, construction, operation and maintenance. The iRING IIP method 

focuses on mapping to templates but does not yet elaborate the template role association to Part 2 

elements. Expansion of the template axioms would ensure that types applied in the signatures are 

consistent with those defined in the templates. However, perhaps more significant improvements to the 

methodology could be made by organizing the scope of information into a conceptual model and 

ensuring that the text definition of classes and properties presented are accurate and highlight 

important distinctions. Figure 2 depicts a portion of a conceptual model of pressure transmitters (design 

view) annotated with Part 2 and RDL information. Compared to the IIP methodology, the conceptual 

model makes clear the domain of properties (the class of object to which they associate). The UML 

model also has provisions to associate documentation with each class and property. 

 

11 A conceptual model defines types, properties, and relationships in a universe of discourse. An information 

model is a model that defines structures for storage and exchange of these elements.
16

Figure 2: This figure depicts a portion of a UML class diagram providing a conceptual model of a pressure transmitter

(product model view). Classes are annotated through the UML profiling mechanism with the identification of Part 2 types 

and RDL references: the ClassOfInanimatePhysicalObject stereotype is applied to the Instrument class; the RDLclass 

stereotype is applied to PressureTransmitter, allowing the specification of a URI to the corresponding reference data class.

Conceptual models can serve to concisely communicate to subject matter experts and software tool 

developers a conceptualization of a domain. Our approach of annotating the diagram with relations to 

ISO 15926 elements provides a view unencumbered by complex detail that are irrelevant to use by these 

stakeholders. Our intention is to build a software tool that applies Part 7 template patterns to the 

exchange form of UML diagrams such as the one depicted in Figure 2. The resulting model may guide 

semi-automated conformance testing of Part 8 exchange files and RDF named graphs. In providing an 

abstraction over Part 2 detail, this method is similar to the method proposed by the JORD Mapping 

Methodology. [1]. In fact, the collection of patterns described in Appendix B of that document is similar 

to those that can be recognized and processed into template specializations using stereotype-annotated 

UML.

Conceptual modeling provides a number of additional advantages. First, a base conceptual model 

representing a consensus view can be developed and then specialized independently by the various 

stakeholders. Certainly something similar to this stratification of the model into consensus and 

specialized views is possible with specialization of templates and RDL entries, but the conceptual model 

demarcates the boundary between the two visibly and much more concisely. Second, the IIP 

methodology has scant support for associating types and dimensions to properties. In a conceptual 

model, property types and dimensions can be stated explicitly, and reference can be made to normative 
17

sources. Finally, conceptual models provide effective input for characterizing differences in viewpoint, 

and therefore are useful to interface developers where mapping to/from the software application is 

required.

A rationale for not investing resources in consensus conceptual modeling originates with the fact that 

the cost of implementing mappings and interfaces has dropped significantly with the emergence of 

SPARQL and iRING tools. These technologies promise lower development costs, perhaps making feasible 

point-to-point interfaces in which differences in viewpoint are reconciled ad hoc. Weighing against the 

emergence of this practice, however, is the need for increasingly fine-grained distinctions in 

communication as the automation of processes increases. Deciding what exactly is intended where 

many seemingly similar concepts are defined (e.g., our rated operating pressure example) requires that 

someone describes the distinctions intended (if any); this is a job for a conceptual model. Characterizing 

the intended distinctions among properties like these can be costly; investment in a shared conceptual 

model can ensure that the cost need only be borne once.

5 Roadmap for ISO 15926 Development

In Section 1.1 we enumerated key principles for the successful development of information 

integration standards. Among the items we highlighted is the development of a roadmap to coordinate 

the activities of the community. An ISO 15926 roadmap would describe a consensus view of the scope of 

ISO 15926 parts that need to be completed and infrastructure such as conformance testing that the 

community plans to deploy. The roadmap would serve to coordinate the various industry initiatives in 

ISO 15926. By defining increments of capabilities for which software vendors can see business value, the 

roadmap might also improve the engagement of software-solution providers.

The ISO subcommittee working group responsible for ISO 15926 is performing work that can 

contribute to the roadmap. The working group is determining what needs to be updated and the tasks 

for completing the core set of the ISO 15926 Parts. ISO TC 184/SC4 is also planning to deploy a reference 

data library. We recommend that the working group leadership engages industry organizations such as 

Fiatech, PCA, USPI, and Engineering Advancement Association of Japan(ENAA) on a candid assessment 

of the current status of the ISO 15926 methods and draft parts. Together they can coordinate a common 

work plan to accelerate the completion and deployment of ISO 15926.

NIST has performed work that can contribute to the roadmap. During the Summer of 2012, the NIST 

Collaborative Requirements Engineering (CRE) project reviewed the “system” for developing the ISO 

15926 standard, including the draft documents for ISO 15926, the current planning and coordination 

among industry programs, and the status of the ISO program of work. The CRE project also worked with 

a number of organizations which are investing in the development of ISO 15926 to understand their 

challenges and successes with ISO 15926. The results of that analysis were presented at the Fall 2012 

meetings of Fiatech and ISO TC184/SC4. At those meetings, NIST submitted recommendations for 

essential improvements in the technical rigor of Fiatech projects working on ISO 15926 and in the 

coordination among industry initiatives, U.S. engineering standards organizations, and the ISO 15926 

work program.
18

Other community efforts would also contribute to the roadmap. The JORD Compliance Specification 

[2] makes a good start at surveying the landscape of conformance issues; it provides a checklist that can 

be used to characterize how ISO 15926 is being used. That is an essential first step. But the JORD 

document is silent on what, other than template conformance, need be assessed. The document does 

not elaborate how conformance assessment will be performed. 

6 Conclusions

We started with a systems view and the idea that the goal of the system is to deliver business 

interoperability to the stakeholders at a price they find compelling. We believe that this can be achieved 

only if the “system” focuses on pragmatics and bottom-line issues. We discussed three issues that we 

believe are key to the success of ISO 15926: the implementation of a conformance testing program, 

improvements in information modeling, and the development of a roadmap to coordinate efforts.

Our recommendations in conformance testing and modeling complement each other. Figure 3

depicts relationships and feedback loops in modeling and testing. Our approach to conceptual modeling 

provides a viewpoint that indicates relationship with Part 2 and Part 7 concepts without allowing Part 2 

and Part 7 viewpoints to dominate. The modeling method, a draft domain conceptual model, and the 

testing capability are being developed and evaluated with industry partners.

Figure 3: In this publication we recommend the development of domain conceptual models to drive the generation of 

specialized templates and additional axioms associated with reference data. These axioms, the specialized templates, the 

Part 2 upper ontology, and content from the system under test are input to conformance testing, which provides feedback 
19

on the correctness of the interface and the domain model. In our design, some conceptual modeling is more appropriately 

associated with reference data than with the specification of templates.

We have developed a tool for template conformance checking, but we believe that this is only the 

start of what might be necessary. Conformance does not guarantee interoperability, and conformance 

to lax requirements even less so. We discussed the value of axiomatizing constraints on reference data 

in this regard. Interoperability by this route comes at a cost. The iRING IIP project reflects a different 

strategy, where cost-effective tooling for developing interfaces might provide a solution with acceptable 

total cost. We plan to follow this initiative closely while working to shore up conformance testing and 

modeling capability. Ultimately the best solution might differ from one application to the next.

The third of our recommendations, the development of a roadmap to coordinate effort, is work that 

is clearly needed. The community developing ISO 15926 will benefit from better coordination of its 

efforts and consensus on the way forward.

7 References

1. POSC Caesar Association. JORD ISO 15926 Mapping Methodology. POSC Caesar Association. 

[Online] October 2, 2012. [Cited: October 10, 2012.] 

https://www.posccaesar.org/attachment/wiki/FiatechJord/JORD-ISO15926-Mapping-MethodologyV2.doc.

2. —. JORD Compliance Specification. s.l. : POSC Caesar Association., 2012.

3. ISO. ISO 15926-1, 2004 -- Integration of lifecycle data for process plants including oil and gas 

production facilities, Part 1: Overview and fundamental principles. 

4. —. ISO 15926-2, 2003 -- Integration of lifecycle data for process plants including oil and gas 

production facilities, Part 2: Data model. First. 

5. —. ISO 15926-7, 2011 -- Integration of lifecycle data for process plants including oil and gas 

production facilities, Part 7: Implementation methods for the integration of distrubuted systems: 

Template methodology. 

6. —. Implementation methods for the integration of distributed systems – Façade implementation 

(ISO draft document). s.l. : ISO, 2011.

7. —. Methodology for simplified industrial usage of reference data (ISO draft document). s.l. : ISO, 

2012.

8. MIMOSA / PCA. Recording of Live Oil & Gas Interoperability (OGI) Phase 1 Pilot Demonstration. 

http://www.mimosa.org. [Online] MIMOSA, September 26, 2012. [Cited: January 31, 2013.] 

http://www.mimosa.org/?q=news/recording-live-oil-gas-interoperability-ogi-phase-1-pilotdemonstration.
20

9. W3C. OWL 2 Web Ontology Language Reference Document Overview (Second Edition). OWL 2 

Web Ontology Language Reference Document Overview (Second Edition). [Online] December 11, 2012. 

[Cited: January 29, 2013.] http://www.w3.org/TR/owl2-overview/.

10. —. RDF/XML Syntax Specificatioin (Revised). RDF/XML Syntax Specificatioin (Revised). [Online] 

February 10, 2004. [Cited: January 29, 2013.]

11. FIATECH. ISO 15926 Information Patterns (IIP). iRINGTools User Group. [Online] November 21, 

2012. [Cited: November 21, 2012.] 

http://iringug.org/wiki/index.php?title=ISO_15926_Information_Patterns_%28IIP%29.

12. ISO. ISO 15926-8, 2011 -- Integration of lifecycle data for process plants including oil and gas 

production facilities, Part 8: Implementation methods for integration of distributed systems: Web 

Ontology Language (OWL) implementation. 

13. —. Industrial automation systems and integration -- Product data representation and exchange --

Part 11: Description methods: The EXPRESS language reference manual. Geneva : ISO, 2004.

14. Model Interchange Testing: a Process and a Case Study. Elaasar, Maged and Labiche, Yvan.

Lyngby : Springer, 2012. 8th European Conference on Modelling Foundations and Applications. pp. 49-

61.

15. OMG. OMG Meta Object Facility (MOF) Core Specification. Needham, 

http://www.omg.org/spec/ : Object Management Group, 2011.

16. —. Object Constraint Language, Version 2.3 Beta. Needham, http://www.omg.org/spec/ : Object 

Management Group, 2011.

17. Pease, Adam. Ontology: A Practical Guide. s.l. : Articulate Software Press, Angwin, CA, 2011.

18. Sweetening Ontologies with DOLCE. Gangemi, A, et al. [ed.] A Gomez-Perez and V R Benjamins. 

Siguenza : Springer Verlag, 2002, Knowledge Engineering and Knowledge Management, Ontologies and 

teh Semantic Web, 13th Internation Conference, EKAW 2002, pp. 166-181.

19. ISO TC184/SC4. SC4 Reorganization 2012. s.l. : ISO, 2012. N 2812.

20. POSC Caesar Association. ISO 15926 as OWL project. POSC Caesar Association. [Online] 

November 13, 2012. [Cited: November 21, 2012.] 

https://www.posccaesar.org/wiki/ISO15926inOWL/OWL2.

21. OMG. Model Interchange Wiki. Object Management Group. [Online] November 21, 2012. [Cited: 

November 21, 2012.] http://www.omgwiki.org/model-interchange/doku.php.

22. US Department of Defense. DOD Joint Staff Publication No. JP 1-02, Department of Defense 

Dictionary of Military and Associated Terms. http://www.dtic.mil/doctrine : US Department of Defense, 

1994.