ISO/TS 18101-1:2019
(Main)Automation systems and integration — Oil and gas interoperability — Part 1: Overview and fundamental principles
Automation systems and integration — Oil and gas interoperability — Part 1: Overview and fundamental principles
This document provides requirements, specifications and guidance for an architecture of a supplier-neutral industrial digital ecosystem. It includes a standardized connectivity and services architecture, and a standardized use case architecture with methods to specify atomically re-usable scenarios and events, which can be used to specify the characteristics of standardized industry use cases. NOTE 1 Examples of standard industry use cases included in the secondary business process are included in Annex A along with standardized use case architecture. This document gives: — guidance for an architecture applicable to the oil and gas, petrochemical, power generation, public utilities and other asset-intensive industries; — requirements for interoperability among systems of systems, systems (including hardware and software) and components included in the secondary business process of a plant, platform or facility at any given time; — guidance on how these interoperability requirements are to be achieved and sustained in support of operations in the same plant, platform or facility; — specifications enabling the specialization of a digital ecosystem concept for the requirements of the secondary business process in included industries; — guidance to industry participants, including owner/operators and their product and services suppliers, to support their secondary business process requirements using products, which interoperate based on the specifications included in this document. NOTE 2 This document is focused on interoperability requirements for systems which play roles in the secondary business process, including those in domains identified in Figure 7.
Systèmes d'automatisation et intégration — Interopérabilité entre les industries du pétrole et du gaz — Partie 1: Vue d'ensemble et principes fondamentaux
General Information
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 18101-1
First edition
2019-06
Automation systems and
integration — Oil and gas
interoperability —
Part 1:
Overview and fundamental principles
Systèmes d'automatisation et intégration — Interopérabilité entre les
industries du pétrole et du gaz —
Partie 1: Vue d'ensemble et principes fondamentaux
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms .
................................................................................................................................................................................................................................................. 5
5 Overview and general requirements . 6
5.1 Secondary business process . 6
5.2 Systems of systems interoperability.10
5.3 Industrial digital ecosystem architecture .11
5.3.1 Overview .11
5.3.2 Engineering Systems .12
5.3.3 Enterprise Business Systems and Automation and Control Systems .13
5.3.4 Data Quality and Architecture .13
5.4 Inter-enterprise user stories.14
6 Compliance and conformance .16
7 OGI concept map .16
Annex A (normative) IT/OT Cloud and Standardized Use Case Architecture .17
Annex B (informative) OGI activity model .20
Annex C (informative) Relationships between selected data standards .24
Annex D (informative) OpenO&M Initiative and Associated Industry Standards .25
Bibliography .26
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 184, Automation systems and integration.
This document provides an overview and outlines the fundamental principles of the ISO 18101 series.
Future parts of the ISO 18101 series will be developed including sets of industry developed use cases,
once the use cases have been documented using the Open Industrial Interoperability Ecosystem (OIIE)
use case architecture and validated using the OIIE Oil and Gas Interoperability (OGI) Pilot, with the
results captured in Technical Reports. These use cases will incrementally define industry prioritized
elements of the secondary business process, which is the scope of the ISO 18101 series.
A list of all parts in the ISO 18101 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO 2019 – All rights reserved
Introduction
It is difficult for the oil and gas industry, and other asset-intensive process industries, to adopt and
adapt digital capabilities for many core business functions. For example:
— Why is it not possible for key industrial systems and applications to "plug and play" like consumer
electronics do?
— Why is it so difficult and expensive to find, capture, manage and use the information that we need to:
— engineer, design and build industrial plants, platforms and facilities?
— operate and maintain industrial plants, platforms and facilities safely, reliably and profitably?
These issues significantly contribute to consistent patterns of major cost and schedule overruns in
capital projects. They also lead to inefficient operations and maintenance spanning the entire life-cycle
of the resulting plants, platforms and facilities. Clearly, this group of industries needs a better solutions
model to help manage operational risks throughout the life-cycle of its plants, platforms and facilities.
Despite many improvements in individual business functions, the oil and gas industry (upstream,
midstream and downstream) as well as other asset-intensive, process industries still struggle with
many inefficient business practices. Many of these inefficiencies stem from how the entire industry
and its primary participants are organized in ‘silos’. This is particularly true for life-cycle asset
management related business processes. These processes span many industry silos, crossing life-cycle
phases, while including both intra and inter-enterprise activities. Meanwhile, participating systems,
equipment, devices, materials, and services suppliers are also organized in their own industry sector
silos. Despite many efforts to break these silos down, they are persistent and are often re-enforced by
current industrial IM solutions, practices, and standards.
Digital business transformation is now being discussed as the solution for many of these issues.
Unfortunately, this industry group lacks a pragmatic, supplier-neutral basis for achieving this objective
and the sought-after business benefits in a timely manner.
The digital ecosystem concept was created for such purposes and has been successfully used in a
variety of industry groups, but for the concept to succeed, it needs to be thoughtfully specialized to
address included industry sectors, while achieving the largest practical scale. Other industry sectors
such as banking, semiconductors, aerospace, consumer electronics and eCommerce have adopted this
model using a combination of open standards and proprietary methods. Each industry has unique
characteristics resulting in industry specific methods, with some basic common denominators such as
the basic standards which define the internet and the World Wide Web.
The oil and gas industry shares many of the same engineering and work practices, while also using
many of the same system (software and hardware), equipment and device classes as many other asset-
intensive, process industries. This provides a mutually beneficial opportunity to share a supplier-neutral
industrial digital ecosystem, where the scale of the aggregated market helps encourage its adoption. A
successful industrial digital ecosystem needs to be supplier-neutral, because no single supplier has the
scale and coverage to impose its will on the entire industry, including all its key participants.
While standards such as ISO 55000 specify good practices for all types of asset management, this
document specifies how those good practices can be implemented using an industrial digital ecosystem.
This document is intended to facilitate discussions between process industry decision-makers and
the specialists who design, build and maintain the processes and systems that enable enterprises to
function. The OIIE provides an example of the proposed, supplier-neutral industrial digital ecosystem.
Key inter-enterprise relationships for the process industry digital ecosystem have been represented
in Figure 1. It depicts the three-way relationship among Owner/Operators (O/O), Engineering,
Procurement, Construction (EPC) organizations and Original Equipment Manufacturers (OEM), which
forms the backbone of the secondary business process spanning the entire asset life-cycle.
Figure 1 — OIIE inter-enterprise industrial digital ecosystem architecture
The secondary business process establishes and maintains operations capability. It spans both inter
and intra-enterprise domains, based on requirements from the standard industry use cases, which are
part of the portfolio of published, supplier-neutral standards and specifications which define the digital
ecosystem. Using a portfolio of existing, well recognized standards, reduces risks associated with the
creation of new standards. The OIIE/OGI Pilot is an interoperability test-bed and is implemented as an
instance of the OIIE, which includes standard oil and gas asset classes and use cases, most of which are
also applicable to other process industries.
This document identifies a portfolio of supplier-neutral IT and IM standards and specifications,
including and driven by standardized industry use cases addressing life-cycle asset management.
The included standards and specifications are validated to work with each other, properly supporting
the standardized industry use cases, using the OIIE/OGI Pilot. Industry solutions are also validated
to interoperate in the OIIE/OGI Pilot, based on the applicable standardized industry use cases, using
the included standards and specifications in the specified manner. Three major phases of the OIIE/OGI
Pilot have already been used to establish and validate the core methods and standards included in the
OIIE. Results from new OIIE/OGI Pilot phases will be documented and published in Technical Reports,
since they will be used to validate inclusions in future parts of the ISO 18101 series. This methodology
provides a pragmatic, supplier-neutral basis for a digital ecosystem which meets major industry
requirements for digital business transformation.
Industry implementation of the Technical Standard has the potential to substantially improve cost
and risk management for the entire life-cycle of plants, platforms and facilities, following a pragmatic
solutions process based largely on existing standards and widely accepted practices and methods.
vi © ISO 2019 – All rights reserved
TECHNICAL SPECIFICATION ISO/TS 18101-1:2019(E)
Automation systems and integration — Oil and gas
interoperability —
Part 1:
Overview and fundamental principles
1 Scope
This document provides requirements, specifications and guidance for an architecture of a supplier-
neutral industrial digital ecosystem. It includes a standardized connectivity and services architecture,
and a standardized use case architecture with methods to specify atomically re-usable scenarios and
events, which can be used to specify the characteristics of standardized industry use cases.
NOTE 1 Examples of standard industry use cases included in the secondary business process are included in
Annex A along with standardized use case architecture.
This document gives:
— guidance for an architecture applicable to the oil and gas, petrochemical, power generation, public
utilities and other asset-intensive industries;
— requirements for interoperability among systems of systems, systems (including hardware and
software) and components included in the secondary business process of a plant, platform or
facility at any given time;
— guidance on how these interoperability requirements are to be achieved and sustained in support
of operations in the same plant, platform or facility;
— specifications enabling the specialization of a digital ecosystem concept for the requirements of the
secondary business process in included industries;
— guidance to industry participants, including owner/operators and their product and services
suppliers, to support their secondary business process requirements using products, which
interoperate based on the specifications included in this document.
NOTE 2 This document is focused on interoperability requirements for systems which play roles in the
secondary business process, including those in domains identified in Figure 7.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 15926-1:2004, Industrial automation systems and integration — Integration of life-cycle data for
process plants including oil and gas production facilities — Part 1: Overview and fundamental principles
ISO 18435-1:2009, Industrial automation systems and integration — Diagnostics, capability assessment
and maintenance applications integration — Part 1: Overview and general requirements
ISO/TS 8000-1:2011, Data quality — Part 1: Overview
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
interoperability
capability of two or more entities to exchange items in accordance with a set of rules and mechanisms
implemented by an interface in each entity, in order to perform their specified tasks
Note 1 to entry: Examples of entities include devices, equipment, machines, people, processes, applications,
computer firmware and application software units, data exchange systems (3.2) and enterprises.
Note 2 to entry: Examples of items include services (3.7), information, material in standards, design documents and
drawings, improvement projects, energy reduction programs, control activities, asset (3.5) description and ideas.
Note 3 to entry: In this context, entities provide items to, and accept items from, other entities, and they use the
items exchanged in this way to enable them to operate effectively together.
[SOURCE: ISO 18435-1:2009, 3.12, modified — The word “respective” has been replaced with “specified”,
Notes 1 and 2 to entry have been modified and Note 3 to entry has been added.]
3.2
system
combination of interacting software and hardware elements organized to achieve one or more stated
purposes
Note 1 to entry: Since a system is composed of system elements (3.3), a system can include hardware, software
(embedded and applications), data, humans, processes, procedures, facilities, materials, and other naturally
occurring entities (e.g. water, organisms, minerals), or any combination.
Note 2 to entry: Industrial application software is included in industrial systems.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.46, modified — The words “software and hardware” have
been added and Notes to entry have been modified.]
3.3
system element
member of a set of elements that constitutes a system (3.2)
EXAMPLE Hardware, software, data, humans, processes (e.g. processes for providing service (3.7) to users),
procedures (e.g. operator instructions), facilities, materials, and other naturally occurring entities (e.g. water,
organisms, minerals), or any combination.
Note 1 to entry: A system element is a discrete part of a system that can be implemented, instructed or used to
fulfil specified requirements.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.47, modified — The words "(e.g. water, organisms, minerals)"
have been added to the Example and the words “instructed or used” have been added to Note 1 to entry.]
3.4
system of systems
system-of-interest whose elements are themselves systems (3.2)
Note 1 to entry: Systems of systems typically entail large-scale inter-disciplinary problems with multiple,
heterogeneous, distributed systems.
Note 2 to entry: In ISO/IEC/IEEE 15288:2015, 4.1.48, a system-of-interest is defined as a system whose life cycle
is under consideration in the context of this document.
2 © ISO 2019 – All rights reserved
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4111, modified — The second definition has been removed and
Notes to entry have been added.]
3.5
asset
item, thing or entity that has potential or actual value to an organization
[SOURCE: ISO 55000:2014, 3.2.1, modified — Notes to entry have been removed.]
3.6
capital project
long-term, capital-intensive investment project
3.7
service
repeatable business activity that has a specified outcome
Note 1 to entry: The service is self-contained, may be composed of other services and is a “black box” to consumers
of the service.
Note 2 to entry: Examples of business activities include: check customer credit, provide weather data, consolidate
drilling reports, maintenance work order.
[SOURCE: ISO/IEC TR 30102:2012, 2.1.17, modified — The words “logical representation of a set of
repeatable activities that has specified outcomes” in the first half of the original definition have been
replaced with “repeatable business activity that has a specified outcome”, the content of the original
Note 1 to entry has been replaced with the content of the second half of the original term and Note 2 to
entry has been added.]
3.8
data set
logically meaningful group of data
[SOURCE: ISO 8000-2:2018, 3.2.4, modified — The word “grouping” has been replaced with “group”.]
3.9
digital twin
digital asset (3.10) on which services (3.7) can be performed that provide value to an organization
Note 1 to entry: The descriptions comprising the digital twin can include properties of the described asset, IIOT
(3.24) collected data, simulated or real behaviour patterns, processes that use it, software that operates on it,
and other types of information.
Note 2 to entry: The services can include simulation, analytics such as diagnostics or prognostics, recording of
provenance and service history.
EXAMPLE A digital model of an aircraft that allows crew training in a simulator; a stream of vibration
readings that allows analysis of bearing wear; maintenance records that enable certification checks or total
operation time computation.
3.10
digital asset
data set (3.8) describing an asset (3.5) that is not necessarily physical
EXAMPLE Digital assets describing non-physical assets include technical specifications, software,
algorithms.
3.11
domain
field of special knowledge, which can be further subdivided according to requirements to support a
higher level of specialized detail
3.12
reference architecture
IT architecture specialized for the requirements of a particular domain (3.11)
EXAMPLE PERA (Purdue Enterprise Reference Architecture) is a reference architecture that can model the
enterprise in multiple layers and multiple stages of the architectural life cycle. Initially, PERA was part of the
PERA methodology, which consisted of three main building blocks (Purdue Enterprise Reference Architecture;
Purdue Reference Model; Purdue implementation procedures manual).
3.13
information model
formal model of a bounded set of facts, concepts or instructions to meet a specified requirement
Note 1 to entry: In this context, the description of domain (3.11) entities in a digital ecosystem (3.26) addressing
lifecycle asset (3.5) management.
3.14
reference data
domain (3.11) and sector standardized data sets (3.8) that help define the set of values to be used to
populate other data sets
3.15
industry standard datasheet
ISD
industry developed, supplier neutral specification for equipment and device classes
Note 1 to entry: The industry standard datasheet includes functional requirements, model and instance level
details needed for industry digital transformation.
3.16
industry standard datasheet definition
ISDD
meta data required to enable machine interpretability of all attributes on industry standard
datasheets (3.15)
3.17
reference data library
RDL
managed collection of reference data (3.14)
[SOURCE: ISO 15926-1:2004, 3.1.19]
3.18
supplier catalogue
list of goods and services (3.7) provided by an organization to its clients that conform to a specification
defined by a supplier
3.19
data quality
degree to which a set of inherent characteristics of data fulfils requirements
Note 1 to entry: Examples of requirements for quality data also include data integrity, data validation (3.22), data
portability (3.23), data synchronization and the data provenance record.
[SOURCE: ISO 8000-2:2018, 3.8.1, modified — Note 1 to entry has been modified.]
3.20
primary business process
process defining principal operations of an enterprise
4 © ISO 2019 – All rights reserved
3.21
secondary business process
process establishing and maintaining operations capability
3.22
data validation
confirmation, through the provision of objective evidence, that the requirements for a specific intended
use or application have been fulfilled
[SOURCE: ISO 8000-2:2018, 3.8.6]
3.23
data portability
ability to easily transfer data from one system (3.2) to another without being required to re-enter data
Note 1 to entry: The need to manually, find, re-read, re-interpret and re-enter data is one of the main factors which
increase industry costs and risks, while also decreasing data quality (3.19). Digital Business Transformation
eliminates this redundant work, simultaneously reducing costs and risks while increasing data quality.
3.24
Industrial Internet of Things
IIOT
global infrastructure for the information society, enabling advanced services (3.7) by interconnecting
(physical and virtual) things based on, existing and evolving, interoperable information and
communication technologies
Note 1 to entry: The Industrial Internet of Things (IIOT) is used to identify the industrial specializations of the
Internet of Things (IOT).
[SOURCE: ISO/IEC 38505-1:2017, 3.6, modified — The original Notes to entry have been removed and a
new Note 1 to entry has been added.]
3.25
plant to business stack
P2B stack
vertical data/information axis from sensor to enterprise systems (3.2)
3.26
digital ecosystem
distributed, adaptive, open socio-technical system (3.2) with properties of self-organisation, scalability
and sustainability inspired from natural ecosystems
3.27
asset-intensive industry
industry requiring a significant amount of large-scale industrial equipment to operate
4 Abbreviated terms
ADID Application Domain Integration Diagram
API Application Programming Interface
CCOM Common Conceptual Object Model
CMMS Computerized Maintenance Management System
EAM Enterprise Asset Management
EPC Engineering, Procurement, Construction
ERP Enterprise Resource Planning
HSE Health and Safety Executive
IM Information Management
ISBM Information Service Bus Model
IT Information Technology
ITB Invitation to Bid
MSM Message Service Model
OEM Original Equipment Manufacturers
OGI Oil and Gas Interoperability
OIIE Open Industrial Interoperability Ecosystem
O&M Operations and Maintenance
OpenO&M Open Operations and Maintenance
O/O Owner/Operators
PERA Purdue Enterprise Reference Architecture
RSPL Recommended Spare Parts List
SPIL Spare Parts Interchange List
SPIR Spares Parts Interchange Record
5 Overview and general requirements
5.1 Secondary business process
Industry activities can be modelled using multiple axes approaches, where the primary business
process concerns itself with the core operations of a given industry group. In the oil and gas industry,
this primary business process usually features raw material inputs, which are taken through a
conversion process resulting, in desired outputs. The upstream, midstream and downstream sectors of
the oil and gas industry, as well as other asset-intensive process industries, can all be modelled in this
fashion, although midstream generally provides no conversion process other than transport.
This document focuses on the secondary business process which supports the primary business
process as is depicted in Figure 2. The secondary business process is shown in more detail in Figure 3. It
includes capital project activities (engineering, design, procurement, and construction), followed by the
handing over and maintenance of the associated plants, platforms, and facilities (collectively referred
to as facilities in the oil and gas industry). Inefficiencies in capital projects often result in large cost
and schedule overruns in capital projects, while also greatly increasing costs and reducing operational
efficiencies over the asset life-cycle. Frustrated operators and maintenance personnel then spend
too much time struggling with sub-optimal implementations of various operations and maintenance
systems. In many cases, they are forced to and re-enter information into their systems, when this
information should have been efficiently captured find as machine interpretable information during
the capital project phase, then handed over and automatically provisioned into their systems.
6 © ISO 2019 – All rights reserved
Figure 2 — Focus on secondary business process
The interrelationships between the primary and secondary business processes and the plant to
business (P2B) stack is illustrated in Figure 2. This three-axis model is a way of visualizing these key
relationships.
Figure 3 — Secondary business process — Asset life-cycle integrated view
While capital projects now seek to build and handover a digital representation of the physical assets,
known as the digital twin, processes for doing this and associated data quality vary greatly, and the
results are often not properly synchronized with the physical assets, nor maintained in synchronization.
Collectively, these factors significantly increase a variety of operational and enterprise risks and costs
impacting the entire life-cycle of plants, platforms, and facilities. While capital project managers have
historically been resistant to managing more data which can help operators and maintainers, since
it can increase their own costs, true digitalization of the secondary business process will require
much more data than is being managed today. The key is finding pragmatic ways to shift most of the
management of this much larger amount of data from individual enterprises and project teams to the
entire industry. At that point, individual project costs can be reduced, and risk managed, while everyone
involved in the entire asset life-cycle can leverage all the machine interpretable information they need.
EXAMPLE 1 A set of loading data is usually specified by the O/O (in the project specifications) as being
required to be “exchanged in an electronic format”, however, this format is usually not clearly defined and
machine interpretable. Data included or embedded in documents are frequently difficult to extract, transform
and load into the target systems and the focus is on a limited set of Enterprise Resource Planning (ERP) oriented
master data. At the time the contracts are placed with the EPC, the ERP and/or the Computerized Maintenance
Management System (CMMS) or Enterprise Asset Management (EAM) system and many other target systems are
often not known. There is also a lack of standardization in load data requirements spanning all these systems,
particularly when trying to add the other details needed for true industry digitalization. As the project proceeds,
other project deliverables generally take precedence for remaining resources, time and budget and what is
ultimately delivered is usually limited to the minimum requirements for loading and commissioning the ERP
system, often based on sub-optimal practices and methods. Collectively, this inefficient process increases costs,
errors, and risks, both during a given project and during the entire life-cycle of the associated plant, platform
or facility, where the lack of readily available, complete, accurate, machine interpretable information is paid for
over and again. If there are no fixed user requirements before placing an order of EPC project and requesting the
EPC to deliver the solution, the load data is delivered in a sub-optimal manner.
EXAMPLE 2 Typically, material requirements are extracted from Spare Parts Interchange Lists (SPIL),
sometimes referred to as Spares Parts Interchange Records (SPIR) or Recommended Spare Parts Lists (RSPL).
These lists are supplied to the O/O at handover via the EPC and originate from the OEM. These documents have
many drawbacks: they are not extractable; contain only a brief description of the product, often just a noun; they
take no account of the equipment criticality; they take no account of the O/O maintenance capability, or their
spares and repair strategy, such as repair or replace. Extracting this data to create material master records is
costly, involves many man days and results in poor data quality. There is a paradigm shift using new technology
and international standards such as ISO/TS 8000-1. The traditional process of the buyer creating templates to
describe an item that fulfils a fit, form, or function as a method of identifying substitutable goods or services, is
being replaced with the importing of supplier catalogue items created using specifications defined by the supplier
in a computer interpretable format, based on ISO 8000 requirements. This new process reduces the cost of handling
such data, thus increasing the quality of the data, and importantly, establishing the provenance of the data.
EXAMPLE 3 The Plant Information Management System contains a wide range of information describing
the details of a given plant, generally from an operations point of view. It forms part of the interface between
physical assets installed, automation and control systems and ERP oriented systems and should be based on a
digital twin including as-built information. Information associated with many aspects of the Purdue Reference
Architecture is collected, compiled and represented in an organized manner. The Plant Information Management
System is built in parallel during the engineering, design, procurement, and construction process. There are often
requirements for information that is not available when it is needed, but the design and implementation of the
Plant Information Management System continues with many associated inefficiencies. Many subsequent efforts
are then required to find, cleans, correlate, validate and load data in the associated applications and systems,
adding substantial time, cost and risk to the project and to future operations and maintenance. The use cases to
be included in future parts of the ISO 18101 series will show how to capture the digital information at the most
appropriate time, then maintain it and re-use it.
EXAMPLE 4 Currently, there is a constant tension in capital projects between those who want to spend
more time and money to identify, capture and manage all known requirements at a very high level of detail and
those who are concerned this adds too much cost to the project and/or unnecessarily slow the project. Most of
this problem is due to the way the industry continues to manage data and information, where each enterprise
or even each project team is forced to do substantial work to find, manage and use data and information in a
consistent and quality-controlled manner. Forced to manage identified costs and resources, managers usually
try to minimize the details to be managed, but all too often, this means nobody is managing these other details.
Overlooked issues in those details then result in significant cost, schedule and quality issues.
8 © ISO 2019 – All rights reserved
EXAMPLE 5 Over the last 100 years (or more in the case of some process industry equipment), major industry
associations have worked on behalf of industry to create supplier-neutral Industry Standard Datasheets (ISD).
ISDs are extremely useful because they provide coverage for all the known properties over the entire life-cycle
of major equipment and device classes, and the functional roles which they play in processes and systems. The
challenge has been to find a way to use them in a machine interpretable manner. They are broadly referenced on
an international basis but are used somewhat inconsistently. Industry Standard Datasheet Definitions are created
via a semi-automated process, capturing the information from ISDs, then binding them to the engineering units
of measure. The ISDDs are published in an information model that is part of the MIMOSA Common Conceptual
Object Model, which is easily associated with processes, systems, models and serialized components. ISDDs
are version managed and can be incrementally updated to follow updates in the ISDs they are associated with,
in cooperation with the organizations publishing the ISDs. Individual O/Os can then specify which versions of
which ISDDs they wish to be used to support their own industrial digital ecosystem, including their supplier
chain partners. This provides a pragmatic risk managed way of using existing, well respected specifications to
support industry digital business transformation.
A fundamental issue has been the lack of standardized, reliable methods for specifying and managing
the required information exchanges and services shared between participants and the various
associated systems (including software applications) used by each of them who are engaged in the
asset life-cycle. This includes a process for coordinating the application of systems (including software
applications) updates in conjunction with applying industry RDL updates to an Enterprise RDL updates.
A related problem is modelling and capturing all the information exchanges and associated information
changes in the normal course of an efficient, standardized work process, which is also flexible enough
to allow the required levels of specialization.
Part of the challenge is due to a highly complex EPC supply chain and the complex nature of the different
systems used by them. It consists of multiple EPC and OEM firms using multiple Engineering, Simulation,
Design, Procurement and Construction Management tools in parallel or over time. This is compounded
by the wide variety of systems (and software applications) used by the various O/Os involved in process
industries, as many of these different systems require detailed, high-quality information provisioning
to deliver their intended business value.
While it is possible to build or buy proprietary, hub-oriented software, the different scopes and
complexity of the interrelated systems interactions increase the cost while decreasing the adaptability
and quality of such tools. Outsourcing the effort to discover and manage all the permutations provides
some short-term relief, but without the power of standardization, the task can be overwhelming for the
supplier. Other participants then suffer from problems associated with lock-in and high switching costs.
There is also a lack of maturity in the engineering reference standards models. No single standard has
broad, in-depth support for capturing all the requirements addressed. The industry should progress
from the current model based on insufficient individual standards to the portfolio approach. Industry
needs to leverage a combination of external reference data libraries and published standards for
format, content, and services, thus adequately addressing the interoperability requirements for process
industries.
The level of standardization specified in this document addresses all these key issues, enabling
commercial software to be adapted to meet the prioritized requirements for industrial business
digitalization.
Digital business transformation has the potential to restructure how the industry works, such that
significantly greater amounts of detailed information are standardized and quality managed by the
entire industry at the lowest practical aggregate costs. The aim is that individual project teams are able
to leverage larger volumes of detailed machine interpretable information, providing required levels of
detail to lock down most key project specifications with far less remaining ambiguity, and that semantic
reasoners are able to validate much more of the detail needed for each project stage, providing the
opportunity to dramatically improve cost, quality and risk management, both for the capital project and
for the delivered plants, platforms and facilities over their entire useful life. This document provides
high-level guidance for how industry can accelerate the process for this needed transformation, using
existing supplier-neutral standards and specifications. Future parts of the ISO 18101 series will provide
further levels of detail organized around industry use cases.
5.2 Systems of systems interoperability
A broad group of the inefficiencies in both the primary and secondary business processes is a
direct result of Industrial IT not yet adopting a fundamental principle of the industrial revolution;
interoperability. Traditional systems integration techniques artificially constrain the quality of the
interactions between people, process, and systems.
To address this issue, the systems engineering community has helped develop systems of systems
modelling techniques, which enable the industrial model for interoperability. This technique includes
methods for sharing both information and services between the systems elements, systems, and
systems of systems.
Systems of systems interoperability improves both the quality and sustainability of such interactions,
while also reducing direct integration costs, as no traditional systems integration layers need to be
developed or sustained by individual organizations. When systems of systems interoperability are
entirely based on published, supplier-neutral standards, the cost savings and improved quality are
efficiently shared by the entire group of participating industries, creating the basis for a cross-industry,
supplier-neutral, industrial digital ecosystem. While this document focuses on the secondary business
process, that process also establishes the basis for systems of systems interoperability in the primary
business process of industry participants.
Figure 4 shows the systems connectivity and services architecture based on the systems of systems
modelling techniques.
Figure 4 — OIIE Intra-Enterprise Industrial Digital Ecosystem Architecture
NOTE Figure 4 provides a simplified view of the connectivity and services included in the OIIE intra-
enterprise architecture. Reference information is persisted in a variety of industry technologies including
Relational Databases, Object Databases and RDF Triple Stores, while the associated information is exchanged
using a variety of standard protocols, information models, data formats and languages including SOAP, REST,
XML, JSON, SQL, SPARQL. The included technologies will continue to change over time as is determined by
industry requirements and the evolution of technology.
This standard industrial digital ecosystem architecture includes Enterprise Business Systems,
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.