Next-Generation Enterprise Architectures

Common Vernacular and Evolution Towards Service-Orientation ✰

Mohsen Moghaddam a, b, *, C. Robert Kenley a, b, Julia M. Colby a, b, Marissa N. Cadavid Berns a, b, Randy Rausch c,
Joel Markham c, Wesley M. Skeffington c, John Garrity c, Alok R. Chaturvedi a, d, Abhijit V. Deshmukh a, b
a
GE-Purdue PRIAM, Purdue University, West Lafayette, IN, USA
b
School of Industrial Engineering, Purdue University, West Lafayette, IN, USA
c
GE Global Research Center, Niskayuna, NY, USA
d
Krannert School of Management & Department of Computer Science, Purdue University, West Lafayette, IN, USA

Abstract—Industry 4.0 is opening new avenues for reconfigu-
rable and information-centric integration of enterprise functions
and control systems. Most of the current approaches (e.g., ISA-95)
view enterprise architectures in a pre-defined, monolithic, and hi-
erarchical sense. To enable more innovative, personalized, and ef-
ficient manufacturing processes, however, such ‘tree-like’ archi-
tectures must turn into decentralized and cyber-physical networks
of ‘things’ and ‘services’. This article investigates the emerging In-
dustry 4.0 paradigms and architectures (e.g., IIRA, RAMI4.0),
their commonalities, limitations, and evolution towards modular
and service-oriented architectures (e.g., ISO/IEC 18384:2016).
The goal is to identify and analyze the existing technical and tech-
nological gaps, and provide recommendations for developing new
reference models/architectures for next-generation enterprises.
Keywords—Service-oriented architecture; Modular design; In-
dustrial internet of things; Cyber-physical system; Industry 4.0
I. INTRODUCTION
The fourth industrial revolution, or Industry 4.0, is charac-
terized by a series of tools and technologies that enable seamless
connectivity between physical systems and their ‘digital twins’.
The vision of Industry 4.0 is to leverage these new capabilities
(e.g., networked/digitized processes; cyber-physical systems) to
better address the dynamic, unpredictable, and complex nature
of next-generation manufacturing systems [1], and emerging
challenges such as agility [2], interoperability and cyber-secu-
rity [3]. A prerequisite for development of an ‘unprecedented’
system like this is an architecture—a ‘blueprint’ that “provide[s]
current or future descriptions of a ‘domain’ composed of com-
ponents, and their interconnections, actions or activities those
components perform, and the rules or constraints for those ac-
tivities” [4].
The General Electric-Purdue University Partnership in Re-
search and Innovation in Advanced Manufacturing (GE-Purdue
PRIAM) has recently launched a new project on Next-Genera-
tion Enterprise Architectures (NGEA), with the goal of investi-
gating the fitness of current enterprise architectures for infor-
mation-centric integration of enterprise functions and control
✰
This work is sponsored by the GE-Purdue Partnership in Research and In-
novation in Advanced Manufacturing (PRIAM).
* Corresponding author,
mmoghadd at purdue.edu, (765) 430-4957.
systems, and developing a path towards defining new standards
(if needed). The NGEA project has been defined in three phases:
1) Evaluate existing and emerging standards, define com-
mon vernacular, educate on how the standards interact
and overlap, summarize strengths and weaknesses;
2) Define gaps, if any, in existing/emerging architectures,
clearly define the unsolved problem;
3) If necessary, design and publish a new architecture.
This article encompasses parts of Phases 1 and 2.
The Purdue Enterprise Reference Architecture (PERA) [5],
developed by Prof. Ted Williams at Purdue University, served
as the basis for the industry-wide standard for enterprise integra-
tion, ISA-95 (IEC 62264:2013 [6]), and heavily influenced the
development of other frameworks (e.g., SCOR; OAGIS; DIRA;
MESA) and architectures (e.g., ISA-99 for security; ISA-101 for
human-machine interfaces). The task of information integration
also extends to device communication protocols, SCADA, and
industrial control functions, such as MTConnect, OPC UA,
Modbus, Profinet, Foundation Fieldbus, and ISA-100 for wire-
less communications. To fully enable the capabilities of Industry
4.0 systems, however, new frameworks and architectures are re-
quired that support dynamic composition of functionality based
on a modular and service-oriented perspective of an enterprise.
The Industrial Internet Reference Architecture (IIRA) [7]
and the Reference Architecture Model Industrie 4.0 (RAMI4.0)
(DIN SPEC 91345:2016 [8]) are amongst the pioneering refer-
ence models for next-generation enterprises. The vision of IIRA
is to create a broad industry consensus for higher interoperability
and enhanced development of Industrial Internet systems. IIRA
relates to a wide range of industries including energy,
healthcare, manufacturing, and transportation. On the other
hand, RAMI4.0 proposes a 3-dimensional reference model de-
termining the Functional Layers of Industry 4.0, as well as the
lifecycle, value stream, and equipment hierarchy models.
RAMI4.0’s primary focus is on manufacturing. Due to the sig-
nificant overlap between the frameworks and capabilities of
IIRA and RAMI4.0, and their considerable similarity with ISA-
95, it is important to evaluate their relative strengths and weak-
nesses with respect to different enterprise integration capabili-
ties. In doing so, one can identify gaps in the state-of-the-art that
need to be filled, exposing possibilities for new standards.

l-))) 

Authorized licensed use limited to: Steve Bishop. Downloaded on June 07,2020 at 21:13:18 UTC from IEEE Xplore. Restrictions apply.
 The purpose of this article is to systematically compile the
inventory of existing industry-wide enterprise reference models
and architectures, particularly IIRA and RAMI4.0, and evaluate
their relative key strengths and limitations vis-a-vis (1) the In-
dustrial Internet-enabled sensing, communication, computing,
and integration capabilities, and (2) the evolution of systems ar-
chitecting methodologies and practices, from hierarchical Struc-
tured Analysis models to Service-Oriented Architecture (SOA).
Section II provides an overview of the equipment hierarchy
model of ISA-95 and the I4.0 Component model of RAMI4.0,
and the path towards developing a standardized ‘Internet-of-
Things’ (IoT) [8]. Section III discusses the functional hierarchy
models of ISA-95, IIRA, and RAMI4.0, along with their capa-
bilities, and mapping for creation of an ‘Internet-of-Services’
(IoS) [9]. Section IV summarizes the discussion, and provides
recommendations for future research and development. (Note:
The focus of this work is primarily on manufacturing; however,
the concepts and architectures discussed here are also applicable
to other sectors.)
II. INTERNET OF THINGS
Industry 4.0 is based on inter-networking of ‘things’ (e.g.,
sensors; computing devices; robots; machines; organizations)
supporting a wide range of interaction, communication, and
computing services. Revisiting the definition of enterprise archi-
tecture in Section I, these ‘things’ refer to the interconnected
‘components’ performing different actions or activities follow-
ing certain rules or constraints. This section presents an inte-
grated approach, based on the RAMI4.0 standard DIN SPEC
91345:2016 [8] as well as the Equipment Hierarchy model of
ISA-95 (IEC 62264-2:2013 [6]), for standard representation of
Industry 4.0 Components (henceforth, I4.0 Components). In this
context, an IoT (Internet-of-Things) refers to a network of I4.0
Components, configured following certain rules/conditions for
on-demand provision of services. (Services are further discussed
in Section III.)
A. ISA-95 Equipment Hierarchy Model
ISA-95 categorizes components in a role-based hierarchical
manner, representing the relationships between different hierar-
chy levels along with the areas of responsibility associated with
each level (FIG. I). ISA-95 applies UML (Universal Modeling
Language, ISO/IEC 19501:2005) for constructing common ob-
ject/information models associated with different manufacturing
scenarios. The equipment hierarchy levels in ISA-95 are as fol-
lows (IEC 62264-1:2013 [6]):
x Enterprise. A collection of sites and areas, responsible
for high-level, strategic decisions.
x Site. A physical/geographical/logical grouping of areas,
production lines/units, and process cells, responsible for
rough-cut planning and scheduling.
x Area. A physical/geographical/logical grouping of pro-
duction lines/units, process cells, and storage zones, with
well-defined manufacturing capabilities and capacities.
x Work center and unit.
- Production unit. Continuous manufacturing equip-
ment.
▪ Unit. Lower-level elements and modules.
- Production line. Discrete manufacturing equipment.
▪ Work cell. Lower-level elements for flexible rout-
ing of work (if applicable).
- Process cell. Batch manufacturing equipment.
▪ Unit. Lower-level elements for flexible routing of
work within process cells (if applicable)
- Storage zone. Material handling/storage equipment.
▪ Storage unit. Lower-level units with finer details
and changeable location (e.g., an AGV).
ISA-95 proposes a monolithic and hierarchical model for
systematic representation of components in a manufacturing en-
terprise (generalizable to other industrial domains). However,
the inherent complexity, uncertainty, and dynamicity of Industry
4.0 systems call for higher ‘agility quotient’; i.e., ability to ef-
fectively accommodate time-pressure (responsiveness), recover
from damage (resilience), handle inadequate options (flexibil-
ity), invent new solutions (innovativeness), handle a variety of
situations (versatility), and self-configure (adaptation) [2]. This,
in turn, necessitates modular design—characterizing an Industry
4.0 system as a network of distributed, self-contained, and au-
tonomous modules (e.g., agents [10]; holons [11]), with inte-
grated local collaborative autonomy and global orchestration
[7].

Layers Enterprise ISA-95

Business Site
Functional
Area
Information
Communication
Process Production Production Storage
Integration Unit Line
Cell Zone
Asset
Unit Unit Work Cell Storage Module

Lower Level Lower Level Lower Level Lower Level

Resources in Resources in Resources in Resources in
Batch Ops. Continuous Ops. Discrete Ops. Handling Ops.
RAMI4.0

FIGURE I. THE PHYSICAL ARCHITECTURES OF ISA-95 (ROLE-BASED EQUIPMENT HIERARCHY MODEL) AND RAMI4.0 (HIERARCHY LEVELS).



Authorized licensed use limited to: Steve Bishop. Downloaded on June 07,2020 at 21:13:18 UTC from IEEE Xplore. Restrictions apply.
B. I4.0 Component
RAMI4.0 builds its component hierarchy model upon ISA-
95 and ANSI/ISA-88 standard for batch control (IEC
61512:1997 [12]), by incorporating three additional elements:
Field device; Product; Connected world (FIG. I). Field device
refers to the smaller elements (e.g., sensor) of a large control
device (e.g., a machine). Consideration of product implies that
in addition to factory machinery and operators, RAMI4.0 takes
into account the outcomes of manufacturing processes as com-
ponents of the system. External collaborators (e.g., suppliers;
manufacturers; customers) are also considered by adding con-
nected world on the top of the equipment hierarchy model.
In addition to the equipment hierarchy, RAMI4.0 also ad-
dresses continuous data acquisition and improvement through-
out the lifecycle of components (e.g., products; orders; equip-
ment; factories), as well as the associated value streams (FIG. I).
The lifecycle model is based on IEC 62890 [13], where the dis-
tinction between component ‘type’ and ‘instance’ is the key—
type-related examples include prototype design, development,
testing, and validation; while instance-related examples are
sales, delivery, data collection, and after-sale services. Virtual-
ization of components is the main enabler of the value stream
model. It enhances visibility across different domains, thus ena-
bling systematic elimination of non-value-adding processes.
(This is further discussed in Section III.)
The unique aspect of RAMI4.0—corresponding to the notion of
modular design—is the I4.0 Component, which may refer to a
group of hardware, software, ideas, or concepts, arranged on a
dynamic basis to provide different services on demand.
RAMI4.0 defines certain characteristics, in order for a group of
‘things’ to be regarded as an I4.0 Component: Identifiability,
communication capability, compliant services, states and se-
mantics, virtual description, safety, security, quality of service,
nestability, and separability [8]. RAMI4.0 introduces the notion
of an ‘administration shell’ as the logical unit of an I4.0 Com-
ponent, responsible for virtual representation, interaction with
the system, and resource management. RAMI4.0 also defines a
‘CP’ classification, which classifies components in an Industry
4.0 system with respect to two key characteristics [8]:
x Communication capability (C). The ability of digital
communication (e.g., via Fieldbus or TCP/IP).
- Classes: None; Passive; Active; I4.0 compliant.
x Presentation (P). The ‘publicity’ of a component in the
information system.
- Classes: Unknown; Anonymous; Individually
known; Entity.
III. INTERNET OF SERVICES
The purpose of every sensor, device, machine, robot, soft-
ware, or simply, every ‘thing’ in an Industry 4.0 system is to
perform certain functions. That is, parallel to the physical archi-
tecture of an Industry 4.0 system, characterized by IoT, is a func-
tional architecture, which we characterize as an IoS, or an Inter-
net-of-Services. The mapping between the physical and func-
tional architectures in the classic Structured Analysis techniques
[4] is performed by an allocated architecture (a.k.a., configura-
tion architecture). The allocated architecture provides a set of
rules for governing the topology, interactions, and independence

Authorized licensed use limited to: Steve Bishop. Downloaded on June 07,2020 at 21:13:18 UTC from IEEE Xplore. Restrictions apply.
Consumer
Mgmt. & Security
Development
Governance
Information
Integration
Process
Services
“Things”
FIGURE II. THE SOA REFERENCE MODEL (ADAPTED FROM ISO/IEC
18384:2016).
of components and functions. The NGEA project proposes an
analog for these architectures in the context of Industry 4.0; an
architecture for dynamic mapping of IoT and IoS (FIG. II)—an
SOA adapted from ISO/IEC 18384:2016 [9].
A service refers to “a logical representation of a set of activ-
ities that has specified outcomes, is self-contained, may be com-
posed of other services and is a ‘black box’ to consumers of the
service” [9]. Going back to the definition of enterprise architec-
ture in Section I, a service refers to the set of actions/activities
that the components of a system perform, under certain rules or
constraints. Thus, services and I4.0 Components complement
each other, under the umbrella of an SOA (FIG. II). This section
briefly discusses the Functional Hierarchy model of ISA-95, the
Functional Viewpoint of IIRA, and the Functional Layers of
RAMI4.0. The goal is to generate a ‘superset’ of enterprise func-
tions, which can then be formalized as standard services, com-
pliant with ISO/IEC 18384:2016 [9].
A. ISA-95 Functional Hierarchy Model
ISA-95 defines five hierarchy levels for different functions
of a manufacturing enterprise; from business planning to logis-
tics, manufacturing operations management, and shop-floor
control. The functional levels are (IEC 62264-1:2013 [6]):
x Level 4. Business-related functions such as production
scheduling, shipping, and inventory control.
x Level 3. Process-related functions such as workflow con-
trol, detailed scheduling, and reliability assurance.
x Level 2. Process monitoring functions such as supervi-
sory/automated control of processes.
x Level 1. Sensing and process manipulation functions.
x Level 0. The physical processes.
The majority of the high-level functions in the Functional
Hierarchy model of ISA-95 (e.g., Levels 3 and 4) are processed
at the Enterprise, Site, or Area levels [6], and functions or com-
munications are not able to jump between non-adjacent levels.
This indicates the centralized and monolithic nature of decision-
making and control in ISA-95, which is contradictory to the
ideas of agile and modular design discussed thus far.
B. IIRA Functional Viewpoint
IIRA is composed of four viewpoints addressing the con-
cerns of different stakeholders compliant with ISO/IEC/IEEE
42010:2011 [14]. Considering local collaborative autonomy and
optimization through global orchestration as the two emerging x Business. The functions mapping the business mod-
thrusts in Industry 4.0 systems, the Functional viewpoint of els/processes, defining rules and regulations, and orches-
IIRA specifies five major functional domains as follows (FIG. trating services in the Functional layer.
III): x Functional. The functions enabling formal description,
x Business. The functions enabling end-to-end operations modeling, and integration of services, associated with the
of an Industry 4.0 system; Business layer and the corresponding processes.
- e.g., enterprise resource planning; customer relation- x Information. The functions supporting event pre-pro-
ship management; lifecycle management; billing; cessing, execution of rules, data analysis, quality assur-
planning and scheduling. ance, and provision to the Functional layer.
x Application. The functions implementing the application x Communication. The functions supporting communica-
logics that realize business functionalities; tion for the Information layer, and providing services for
the control of the Integration layer.
- e.g., rules; models; activity/workflows; application
programming interface; user interface. x Integration. The functions providing asset information,
enabling computer-aided control, event-generation, con-
x Information. The functions supporting data provision nectivity, and component virtualization.
and deployment;
x Asset. The functions physically performed by the com-
- e.g., data gathering; syntactical and semantic transfor-
ponent or connecting the component to the virtual world
mation; storage; quality processing; distribution.
by passive means (e.g., UPC barcode).
x Operations. The functions operating components
throughout their lifecycle; D. Services
- e.g., provisioning; deployment; management; moni- The functional hierarchy models proposed by ISA-95, IIRA,
toring; diagnostics; prognostics; optimization. or RAMI4.0 may be sufficient for representation of system func-
tions and their correspondence with the traditional, hierarchical
x Control. The functions enabling the industrial control structure of components. However, considering the definition of
system; IoT in the context of Industry 4.0, as a network of self-contained
- e.g., sensing; actuation; communication; abstraction; and autonomous I4.0 Components, these hierarchical models
virtualization; analytics; asset management. must be transformed into analogous ‘network models’, com-
posed of self-contained and autonomous groupings of functions;
C. RAMI4.0 Functional Layers i.e., services. ISO/IEC 18384:2016 [9] provides a comprehen-
The four major aspects of RAMI4.0 are vertical integration sive taxonomy of services (mainly for software engineering ap-
of components and services, end-to-end engineering throughout plications), classified as domain-specific (e.g., process services;
value streams and component lifecycles, horizontal cross-enter- information services; business services) and domain-independ-
prise integration, and human-in-the-loop orchestration of value ent (e.g., security services; infrastructure services; life cycle ser-
streams [8]. With this in mind, RAMI4.0 specifies the following vices). Service-orientation offers several unique benefits com-
six major functional layers (FIG. III): pared to the traditional, hierarchical models:

① Hardware; So ware; Human Resources; Ideas; Concepts ⑥ Semantics; Syntaxes; Persistence; Storage; Quality Processing; Analytics; Distribution
② Sensing; Actua on; Virtualiza on; Modeling; Execu on ⑦ Engines; Ac vity Flows; Workflows; API & UI; Service Modeling
③ Communica on; Interfacing ⑧ Specifica on of Rules & Models
④ Provisioning; Deployment; Asset Mgmt.; Monitoring; Diagnos cs; Prognos cs ⑨ Service Orchestra on; ERP; CRM; Lifecycle Mgmt.; Billing; HRM; Planning; Scheduling
⑤ Data Collec on

Business Plan/Logistics Functional Domains

Production planning and scheduling, Business
engineering design, purchasing, customer Layers
order handling ⑨
⑧
Business
Information

Application
Operations

⑦
Functional
⑥
Mfg. Ops. Mgmt. ⑤
Information
Production, maintenance, quality Communication
testing, inventory and material flow ④
Control ③ Integration
management ②
Asset
Sensing Actuation
①

Batch Continuous Discrete

Control Control Control Physical Systems

ISA-95 IIRA RAMI4.0

FIGURE III. THE FUNCTIONAL LAYERS OF ISA-95, IIRA, AND RAMI4.0 (DOTTED LINES: MAPPING BETWEEN LAYERS OF IIRA AND RAMI4.0).



Authorized licensed use limited to: Steve Bishop. Downloaded on June 07,2020 at 21:13:18 UTC from IEEE Xplore. Restrictions apply.
 x Interoperability. Addressing heterogeneity issues via
open and standard service interfaces;
x Loose-coupling. Enabling intra/inter -enterprise compo-
sition, provisioning, and deployment of services;
x Complexity-handling. Lowering system complexity via
‘encapsulation of services as ‘black-boxes’ to users;
x Stateless-ness. Focusing on the functionalities of an ap-
plication rather than the objects providing it;
x Scalability. Supporting reconfiguration/expansion of an
enterprise without major architectural changes;
x Reusability. Enabling processes composition via dy-
namic mapping of services to their ‘physical twin’;
x Standardization. Providing standard service descrip-
tions, contracts, interfaces, and governance.
IV. DISCUSSION
The Industry 4.0 vision for cost-effective, agile, and cus-
tomer-centric production cannot be fully materialized without
interweaving IoT with a parallel IoS. This introduces two fun-
damental questions:
Q1 What changes if the enterprise resources and functions
are standardized as self-contained and autonomous
components and services, respectively?
Q2 How can businesses make this transition from a central-
ized and hierarchical architecture such as ISA-95 to a
modular and service-oriented architecture?
The changes resulting from modularization and service-ori-
entation (Q1) can be classified as the changes in the structure of
a system, the way it operates, and its expected outcomes. The
first involves a transition from a hierarchical to a network struc-
ture. The equipment/functional hierarchies will be replaced with
networks of standardized components/services, where the links
represent information carriers, edge connectivity, APIs, enter-
prise service bus, etc. In line with this revolution, manual and
centralized workflows will be transformed into digital and de-
centralized operations/decisions, supported by end-to-end col-
laboration between all entities throughout the value chain. This,
in turn, calls for new business models, analytical tools, compu-
tational models, and interaction protocols [15]. The expected
outcomes of such a digitized and decentralized system will be
better efficiency, agility, customer-centricity, cross-platform
functionality, complexity-handling, and ability to interact with
external/heterogeneous systems. These outcomes all contribute
to the ever-increasing need for business agility [2].
This transition essentially requires a wide range of R&D and
implementation efforts (Q2), which may vary depending on the
status of an entity in an Industry 4.0 environment (e.g., service
provider; physical resource provider; consumer). A preliminary
step is to develop a modular and service-oriented enterprise ar-
chitecture, as a ‘blueprint’ for guiding this transition, supported
by new analytical tools and standards for emerging Industry 4.0
challenges such as interoperability and cybersecurity [3]. To bet-
ter quantify the benefits and impacts of new and existing enter-
prise architectures, however, more quantitative methods must be
developed.

Authorized licensed use limited to: Steve Bishop. Downloaded on June 07,2020 at 21:13:18 UTC from IEEE Xplore. Restrictions apply.
A. Service-Oriented Architecture—IoS
Various SOA reference models have been developed over
the past decade and implemented with significant financial suc-
cess [16]; however, these are mostly designed for software en-
gineering applications. Common examples include the IBM Ser-
vice-Oriented Modeling and Architecture [17], the Open Group
SOA Reference Architecture Technical Standard [18], the Ar-
rowhead framework [19], the OASIS Reference Model for Ser-
vice Oriented Architecture [20], and the General Technical Prin-
ciples of SOA (ISO/IEC TR 30102:2012, Annexes D & F) [21],
leading to the development of the international standard
ISO/IEC 18384:2016, Reference Architecture for SOA (FIG. II).
The manufacturing ‘analog’ of these developments is Cloud
Manufacturing built upon the Cloud Computing reference
model [22]. Nevertheless, the current Cloud Manufacturing ref-
erence architectures lack several key features of ISO/IEC
18384:2016 such as a standard and all-inclusive definitions of
various architectural capabilities/aspects, building-blocks, met-
rics, and service categories [9]. A recent Smart Manufacturing
System Architecture proposed by NIST [23] addresses some of
these concerns, while still noting many implementation chal-
lenges. ‘Manufacturing adoption’ of ISO/IEC 18384:2016 is
therefore a foremost R&D/implementation effort, which must be
conducted consistent with DIN SPEC 91345:2016 [8], as well
as other emerging frameworks/architectures such as ManuCloud
[24] and Predix [25].
B. Modular Design—IoT
An essential step in ‘manufacturing adoption’ of ISO/IEC
18384:2016 is to identify the analogs of software objects and
modules in a manufacturing environment. The recently pub-
lished RAMI4.0 standard, DIN SPEC 91345:2016 [8], provides
the foundation for modularization of manufacturing via I4.0
Components. Through reconstructing classic monolithic archi-
tectures as reconfigurable networks of ‘Lego-brick’ (e.g., I4.0
Components), modular design enables decentralization and de-
mocratization of manufacturing to lower cost, improve effi-
ciency, and drive innovation. Major R&D and implementation
efforts in this context therefore include (1) further development
of the notion of I4.0 Component proposed by DIN SPEC
91345:2016 to conform with ISO/IEC 18384:2016; (2) develop-
ment of passive and active infrastructures to enable plug-and-
play reconfigurability and module/infrastructure evolution [2];
and (3) validation through field experiments. The GE Power
plants, for example, have already adopted the notion of modular
design for plug-and-play connectivity between manufacturing
modules (e.g., gas turbine; steam turbine; heat rejection system;
electrical system; controls) [26].
C. Data-Driven Analytics
Industry 4.0 is characterized by the notion of ‘digital twin’,
an offspring of comprehensive digitization, ubiquitous connec-
tivity, and big data. In this context, data-driven analytics are pro-
gressively playing a pivotal role in successful design and imple-
mentation of enterprise architectures. New analytical tools and
techniques are indeed required to address the emerging Industry
4.0 challenges such as cybersecurity (e.g., ISA/IEC-62443 [27];
C2M2 [28]), safety, interoperability, connectivity [7], decentral-
ized process control (e.g., agent-based modeling and simulation;
holonic manufacturing), and online/ evolutionary computing [2]
(e.g., machine learning; real-time optimization).
[3]
D. International Standards
[4]
Several organizations and working groups are currently de-
veloping different concepts/frameworks/architectures for Indus-
try 4.0 enterprises; independent of each other. Additionally, [5]
there may be a need for a ‘super-architecture’ or ‘architecture-
of-architectures’ that governs the interactions of different sub- [6]
systems (e.g., organizational architecture, communications ar-
chitecture, functional architecture, service architecture, infor- [7]
mation architecture, etc.) Existing frameworks such as The
[8]
Open Group Architecture Framework (TOGAF) [29], the Uni-
fied Architecture Framework [30], and OPC Unified Architec- [9]
ture (UA) [31] may be regarded as different ‘facets’ of such a
super-architecture, although this topic requires further investiga- [10]
tion. As mentioned in Section I, this manuscript discusses some
of the work for Phases 1 and 2 of the three-part PRIAM NGEA [11]
project. The next phase of the project will plan to bring together
a group of interested parties, from industry, government, stand-
ards organizations, and academia, to investigate the foundations [12]
of next generation enterprise architectures, and initiate the pro- [13]
cess of creating new standards for enterprise integration and
control that will fully leverage the capabilities offered by the In- [14]
dustrial Internet and cyber-physical systems.
[15]
E. Architecture Analysis Methods
One major challenge of determining the best enterprise ar- [16]
chitectures developed for Industry 4.0 is the lack of quantitative
architecture analysis methods. While Martin [32] identifies pos- [17]
sible architecture analysis methods, many are qualitative such as
focus group survey and Delphi methods. These methods make it [18]
difficult to quantify the benefits of one architecture over another,
an important step in deciding which architecture to convert to [19]
for Industry 4.0. A more comprehensive analysis would be to [20]
experimentally test the various enterprise architectures in a man-
[21]
ufacturing environment. However, this would be extremely
time-consuming and expensive, considering the work involved
in setting up the proper hardware and software to represent mul- [22]
tiple enterprise architectures. The development of a quantitative
architecture analysis method requires further investigation. In [23]
addition to the project work previously mentioned, case studies
will be conducted in Phase 2 as a method of providing a more [24]
objective analysis of the existing and newly-created architec-
tures.
ACKNOWLEDGMENT [25]
[26]
The authors would like to extend their gratitude to Dr. Albert
[27]
T. Jones from the U.S. National Institute of Standards and Tech-
[28]
nology (NIST) and Dr. Eswaran Subrahmanian from Carnegie
Mellon University for sharing their insights and expertise, and
[29]
to the GE-Purdue PRIAM for their support during the course of
[30]
this research.
REFERENCES
[1] “Factories of the future.” International Electrotechnical Commission [31]
(IEC), 2015. [32]

Authorized licensed use limited to: Steve Bishop. Downloaded on June 07,2020 at 21:13:18 UTC from IEEE Xplore. Restrictions apply.
R. Dove, “Agile systems-engineering AND agile-systems engineering”.
INCOSE INSIGHT vol. 17, pp. 6–10, 2014.
L.D. Xu, W. He, S. Li, “Internet of Things in Industries: A Survey,” IEEE
Transactions on Industrial Informatics, vol. 10, pp. 2233-2243, 2014.
A. Levis, “Systems architecture,” in Handbook of Systems Engineering
and Management, Second Edition (A.P. Sage & W.B. Rouse., Eds.),
Wiley, 2009, pp. 479–506.
T. Williams, “The Purdue enterprise reference architecture,” Computers
in Industry, vol. 24, pp. 141–158, 1994.
“IEC 62264:2013, ISA95 – Enterprise-Control System Integration,”
2013.
“Industrial Internet Reference Architecture (IIRA),” Industrial Internet
Consortium, 2015.
“DIN SPEC 91345:2016-04, Reference Architecture Model Industrie 4.0
(RAMI4.0),” DIN Deutsches Institut für Normung e. V., Berlin, 2016.
“ISO/IEC 18384:2016, Information technology—Reference Architecture
for Service Oriented Architecture (SOA RA),” 2016.
D. Trentesaux, “Distributed control of production systems.” Engineering
Applications of Artificial Intelligence, vol. 22, pp. 971–978, 2009.
H. Van Brussel, J. Wyns, P. Valckenaers, L. Bongaerts, and P. Peeters,
“Reference architecture for holonic manufacturing systems: PROSA.”
Computers in Industry, vol. 37, pp. 255–274, 1998.
“IEC 61512, Batch Control,” 1997.
“IEC 62890, Life-cycle management for systems and products used in
industrial-process measurement, control and automation,” 2016.
“ISO/IEC/IEEE 42010, Systems and software engineering—Architecture
description,” 2011.
D. Wu, M.J. Greer, D.W. Rosen, and D. Schaefer, “Cloud manufacturing:
Strategic vision and state-of-the-art.” Journal of Manufacturing Systems,
vol. 32, pp. 564–579, 2013.
“Reaping the Rewards of Your Service-Oriented Architecture.” IBM
Global Services, 2008.
A. Arsanjani, “Service-oriented modeling and architecture,” IBM
Technical Library, 2004.
“Open Group Standard SOA Reference Architecture Technical
Standard,” The Open Group, 2011.
J. Delsing. IoT Automation: Arrowhead Framework, CRC Press, 2017.
“OASIS Reference Model for Service Oriented Architecture 1.0,” OASIS
Standard, 2006.
“ISO/IEC/TR 30102, Information technology — Distributed Application
Platforms and Services (DAPS) — General technical principles of Service
Oriented Architecture,” 2012.
X. Xu, “From cloud computing to cloud manufacturing,” Robotics and
Computer-Integrated Manufacturing, vol. 28, p. 75–86, 2012.
Y. Lu, F. Riddick, and N. Ivezic, “The Paradigm Shift in Smart
Manufacturing System Architecture,” 2011.
M. Meier, J. Seidelmann, and I. Mezgár, “ManuCloud: the next-
generation manufacturing as a service environment.” European Research
Consortium for Informatics and Mathematics News, vol. 83, pp. 33–34,
2010.
“Predix: The Industrial Internet Platform.” GE Digital, 2015.
“Powering the World.” GE Power, 2015.
“ISA/IEC 62443: Industrial Network and System Security,” 2010.
“Cybersecurity Capability Maturity Model (C2M2).” U.S. Department of
Energy.
“The Open Group. TOGAF 9.1.,” 2011.
W. Pessemier, G. Deconinck, G. Raskin, P. Saey, H. Van Winckel, “UAF:
a generic OPC Unifed Architecture Framework”, Proceedings of SPIE -
The International Society for Optical Engineering, vol. 8451, 84510P,
2012.
“OPC Unified Architecture,” 2008.
J. Martin, “Architecture Evaluation Framework,” in Trade-off Analytics,
First Edition (G. Parnell), Wiley, 2016.