Iot PLSS 2

Industrial Management & Data Systems
Internet of Things-based production logistics and supply chain system-Part 1: Modeling IoT-based
manufacturing supply chain
Mengru Tu, Ming Lim, Ming-Fang Yang,
Article information:
To cite this document:
Mengru Tu, Ming Lim, Ming-Fang Yang, "Internet of Things-based production logistics and supply chain system-Part
1: Modeling IoT-based manufacturing supply chain", Industrial Management & Data Systems, https://doi.org/10.1108/
IMDS-11-2016-0503
Permanent link to this document:
https://doi.org/10.1108/IMDS-11-2016-0503
Downloaded on: 01 January 2018, At: 20:44 (PT)
References: this document contains references to 0 other documents.
To copy this document: permissions@emeraldinsight.com
Downloaded by University of Exeter At 20:44 01 January 2018 (PT)
Access to this document was granted through an Emerald subscription provided by emerald-srm:463575 []
For Authors
If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service
information about how to choose which publication to write for and submission guidelines are available for all. Please
visit www.emeraldinsight.com/authors for more information.
About Emerald www.emeraldinsight.com
Emerald is a global publisher linking research and practice to the benefit of society. The company manages a portfolio of
more than 290 journals and over 2,350 books and book series volumes, as well as providing an extensive range of online
products and additional customer resources and services.
Emerald is both COUNTER 4 and TRANSFER compliant. The organization is a partner of the Committee on Publication
Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.
*Related content and download information correct at time of download.

Internet of Things-based production logistics and supply chain
system-Part 1: Modeling IoT-based manufacturing supply chain
Abstract
Purpose – The lack of reference architecture for IoT modeling impedes the successful design and
implementation of an IoT-based production logistics and supply chain system (PLSCS). We present this
study in two parts to address this research issue. Part A proposes a unified IoT modeling framework to
model the dynamics of distributed IoT processes, IoT devices, and IoT objects. The models of the
framework can be leveraged to support the implementation architecture of an IoT-based PLSCS. Second part
of this study extents the implementation architecture proposed in Part A. Part B presents an IoT-based
Cyber-Physical System (CPS) framework and evaluates its performance.
Design/methodology/approach – This paper adopts a design research approach, using ontology, process
analysis, and Petri net (PN) modeling scheme to support IoT system modeling.
Findings – The proposed IoT system modeling approach reduces the complexity of system development and
increases system portability for IoT-based PLSCS. The IoT design models generated from the modeling can
also be transformed to implementation logic.
Practical implications – The proposed IoT system modeling framework and the implementation
architecture can be used to develop an IoT-based PLSCS in the real industrial setting. The proposed
modeling methods can be applied to many discrete manufacturing industries.
Originality/value – The IoT modeling framework developed in this study is the first in this field which
decomposes IoT system design into ontology-, process-, and object-modeling layers. A novel
implementation architecture also proposed to transform above IoT system design models to implementation
logic. The developed prototype system can track product and different parts of the same product along a
manufacturing supply chain.
Keywords: Internet of Things (IoT), RFID, Production logistics, Petri net, Manufacturing supply chain
Article Type: Research paper
1 Introduction
The Internet of Things (IoT) is envisioned as creating a world whereby every object has a digital identity
and can connect to a data network (Gershenfeld et al., 2004). Radio-frequency identification (RFID)
1
technology, which can be used to give digital identity to the objects, has recently been widely adopted by
various industries, such as manufacturing, retails, and pharmaceuticals. Successful applications of RFID in
tracking objects, people, and animals contribute to the realization of the vision of IoT for a global
infrastructure of networked physical objects (Kortuem et al., 2010). More specifically, the IoT enters our
daily lives through a wireless network of uniquely identifiable objects (Welbourne et al., 2009); it extends
the Internet to physical objects and promises a smart, highly networked world (Quack et al., 2008).
Businesses could employ IoT technology to change their business practices along with their trade partners to
improve supply chain integration and efficiency. IoT applications enable real-time visibility of products
across the global manufacturing supply chain and bring responsiveness and agility to business operations.
IoT-based applications also aid firms in reducing data latency, analysis latency, and decision latency
(Hackathorn, 2003). In addition to automatic object identification, the IoT comprises a global internet-based
information architecture facilitating the exchange of goods and services in global supply chain networks
(Liu and Sun, 2011). Thus, the IoT will greatly shape the evolution of production logistics in manufacturing
and supply chain operation in numerous industries at a global scale. For manufacturing firms, production
logistics (PL) denotes to the logistics activities related to material transfer between production steps and
accounts for nearly 95% execution time of the entire manufacturing process (Qu et al., 2016). The PL
process is not just limited to intra-firm scope, but should also extend to inter-firm scope, involving material
supply, material warehousing, manufacturing, product warehousing, and product consumption among
suppliers, manufacturers, and retailers (Qu et al., 2016). In light of the scope of PL, the dynamics in a
manufacturing supply chain network should be included in the study of a production logistics system. IoT
data come from many sources and may contain discrete (ex. RFID event), continuous data (ex. wireless
sensor data), or both. In this research, we only focus on the discrete data because many IoT applications in
PL and supply chain which mainly concerns with discrete information such as production pedigree or
product life cycle information. Therefore we consider an IoT-based production logistics and supply chain
system (hereafter abbreviated as "IoT-based PLSCS") a discrete event system (DES) in this study.
The boundary of many manufacturing supply chains are not confined within a single company but
extends to several firms along with a supply chain. The most commonly used IoT information architecture
currently available for supply chain applications is the EPCglobal Network (Liu and Sun 2011). The basic
infrastructure of an IoT-enabled supply chain comprises the EPC and EPCglobal Network (EPCglobal, 2007;
EPCglobal, 2010). The EPC is an international, unambiguous code for designating physical goods. The EPC
and EPCglobal Network architecture is created to ensure RFID interoperability in supply chain-wide
applications (Thiesse et al., 2009). Figure 1 describes the EPCglobal Network architecture (EPCglobal, 2007;
EPCglobal, 2010). The EPC is an identification scheme for universally and uniquely identifying objects that
have EPC tags. RFID readers installed in various manufacturing and supply chain settings can retrieve
product data stored in the tags and supply chain members can query, update, or exchange information in real
time through the EPCglobal Network (Bo and Guangwen 2009). The application-level events (ALE) is the
middleware in the architecture, which is a program module or service facilitating IoT event processing and
information exchange between the RFID readers and enterprise information systems (Bo and Guangwen
2009; EPCglobal, 2010). As illustrated in Figure 1, the ALE middleware filters RFID data from RFID reader
and generates EPCIS events, which contains 4W ( What, Where, When, and Why) information relevant to
RFID tagged products passing through a supply chain read point. The sheer amount of raw data generated by
2
even a few readers can easily cause an unacceptable load on corporate networks and systems. Therefore, a
middleware layer is required to filter, aggregate, and associate the data collected from readers on the
network’s edge (Thiesse et al., 2009). EPC standards offer total supply chain visibility, providing the ability
to know exactly where products are located and why. Central to this concept is the EPC Information
Services (EPCIS) standard. EPCIS consists of a set of networking and data-sharing standards which enable
companies to share information among supply chain partners; this information contains not only serial
numbers read from RFID-tagged products but also others such as location, time, and business steps (Kwok
et al., 2010; Yan et al., 2016). Both RFID and the EPCglobal Network architecture play a key role in IoT
logistics applications, such as in agricultural supply chain (Kelepouris et al., 2007; Yan et al., 2016). RFID
technology enables firms to automatically read or write data onto RFID-tagged products without line of
sight at critical points in the supply chain. The EPCglobal network is chosen as an underlying IoT
infrastructure of this study for the following reasons: 1) its coding scheme for product serialization can be
applied to both product and its associated components. 2) its event capturing scheme can record individual
object event, quantity event for multiple objects, and aggregation event dealing with multiple object
relationships such as one object (ex. an engine part) assembled into another object (ex. a car body) or
multiple objects (ex. many bottles of wine) packed into a box. The above two reasons make the EPCglobal
standard and its architecture more appropriate for modeling manufacturing supply chain operations than
other alternatives.
Several studies have been conducted in relation to integrating IoT with enterprise IT infrastructure and
business processes (Datta, 2008; De Souza et al., 2008; Kürschner et al., 2008; Spiess et al., 2009), and
improving manufacturing supply chain operations of enterprises (Zhou and Venkatesh 1999; Doerr et al.,
2006; Chow et al., 2007; Chow et al., 2007; Qiu, 2007; Zhou et al., 2007; Liu et al., 2009; Cimino and
Marcelloni, 2011). To support efficient supply chain integration, IoT applications must integrate RFID
technology with key intra- and inter-organizational business processes and information systems (Fosso
Wamba, 2012). The usefulness of object identification alone is limited unless object identification
encompasses system interoperability and data analysis (Datta, 2008). Thus, to fully reap the benefits of IoT
technology, firms have to transform their organizations to IoT-enabled enterprises.
However, conventional IT architecture of enterprises is static, incapable of accommodating changes,
and difficult to encompass virtue collaboration due to rigid and confined boundaries of a firm (Bi et al.,
2014). The limitations of current enterprise systems are barriers to the adoption of IoT technology. The
integration of business processes and IoT data also poses many challenges for developing IoT applications
because many IoT systems are distributed in nature where the data source and control logic may be
disseminated to different companies at different locations. One major challenge for IoT application
development lies in the lack of architecture design methods (Wu, 2008, Bandyopadhyay and Sen 2011, Patel
and Cassou 2015). Other challenges include the lack of separation of concerns, the lack of high-level of
abstractions to specify high-level IoT system behaviors (Patel and Cassou 2015), and the lack of common
software architecture to account for different IoT environments and diverse software modules
(Bandyopadhyay and Sen 2011). Furthermore, IoT-based systems must incorporate business assets, intra-
and inter-organizational business processes, services, information processing, and the sensing and
communication capabilities of IoT smart items into the architecture design scheme (Haller et al., 2008).
These ubiquitous features of IoT systems create difficulty in representing the dynamic behavior of the
3
systems through a traditional process modeling scheme such as Business Process Execution Language
(BPEL) (Ferreira et al., 2010). For example, neither defining business logic running on IoT smart items nor
distributing business logic between a central system and smart items is possible by using a traditional
process modeling scheme (Ferreira et al., 2010). Attention should also be given to the IoT model checking to
guarantee that the expected system behavior after implementation follows the original IoT design
specifications. Therefore, without a proper modeling and validating scheme, IoT applications may encounter
potential deadlocks and conflicts in intra- and inter-organizational process integration at system
development or implementation phases or even after an IoT system begins full operation. Undetected faults
at the system design stage may propagate until later system development phases; the later these design faults
are found, the higher the cost and effort required to correct them is. Lacking a proper modeling scheme
adversely affects the design, implementation, maintenance, and reuse of IoT application software. Thus,
formal modeling and design methods are essential to preventing design faults in the early stages of IoT
application development.
Although many previous research activities have been undertaken to investigate IoT application in PL
and supply chain, studies related to the formal modeling and design methodology of IoT applications are
limited (Lanese et al., 2013; Bi et al., 2014; Dar et al. 2015). Modeling and validating intra- and
inter-organizational IoT process interactions are one of the major concerns in developing IoT manufacturing
or supply chain applications, but current EPCglobal Network architecture does not provide adequate
guidance regarding resolving these difficulties. Formal IoT modeling methods should address the IoT device
components and consider them IoT business process resources (Meyer et al., 2013). Dar et al. (2015) also
indicate a high need for developing a uniform architecture to facilitate an easy yet standardized access to IoT
devices. Furthermore, the RFID tagging is not limited to item-level tagging. Component-level tagging for
critical parts might become necessary for IoT-based PL application in the future, and we have not seen
studies to address this issue. It is still in the early stage of applying IoT in enterprise systems, and researches
regarding the modularized and semantic integration of IoT technologies are in high demand (Bi et al., 2014).
Therefore, the need to develop a unified and comprehensive modeling approach for IoT-based PLSCS is
evident.
In light of aforementioned challenges discussed above and the lack of a good reference architecture for
modeling IoT-based PLSCS, two research questions arise from those research gaps that this study aimed to
address: 1) How to design system models to describe the dynamics of distributed IoT processes, IoT devices,
and IoT objects on a manufacturing supply chain for an IoT-based PLSCS? 2) How to leverage the above
IoT design models to support the implementation of an IoT-based PLSCS capable of recording and tracking
every manufactured product and its associated parts along a manufacturing supply chain? Therefore, the
objective of this paper is to answer the research questions by developing a unified modeling framework for
IoT-based PLSCS. Hence, we proposed a unified modeling framework with hierarchical modeling approach
to support the modeling and design of IoT systems applied in manufacturing supply chain, specifically for
IoT-based PLSCS, to reduce system modeling and design complexity while achieving high system
reusability and maintainability. All modern software formalisms support separation of concerns to some
extent (Dickerson and Mavris 2013). The EPCglobal Network architecture also supports this concept by
separating its technology stack into sensor-reader, EPC Middleware (ALE), and EPCIS layers, as shown in
Figure 1. Based on the principle of separation of concerns, our methodology comprises three modeling
4
layers, namely ontology-, process-, and object-modeling layers. Each of the three modeling layers addresses
different concerns for the IoT system, where a concern defines a software requirement and can be realized
by an abstract software model or a software module. According to the principle of separation of concerns,
which has been adopted by numerous software development frameworks (Kulkarni and Reddy 2003; Cassou
et al., 2012; Dickerson and Mavris 2013) and IoT system architectures (Kelepouris et al., 2007; Wu, 2008,
Qu et al., 2016), each modeling layer in our methodology employs different techniques to address the
separation of concerns throughout the development phases of an IoT application. The three modeling layers
generate three artifacts: an IoT-aware ontology concept model (IoTCM), IoT-aware process model (IoTPM),
and IoT-aware object model (IoTOM). Ontology and Petri net (PN) are adopted as modeling tool to assist
our development of system-modeling scheme for IoT application. Using ontology for the modeling enables
us to systematically capture, categorize, and describe elements in IoT application domain knowledge. On the
other hand, PN has been considered an excellent modeling tool for a DES and thus it naturally becomes one
of our modeling approaches since we consider an IoT-based PLSCS a DES. One of the saliant contribution
of this paper is to incorporate both item-level tagging and component-level tagging scheme in our modeling
framework (specifically IoTOM) and implementation architecture so that RFID tagging can be applied to a
product and the parts of the same product, allowing IoT system to track both product and parts along a
manufacturing supply chain.
Hence, considering the salient impact of IoT on PL and supply chain, this research examined IoT-based
PLSCS in two parts. The first part investigated IoT technologies in PL production and supply chain
applications and proposed a multilayer modeling approach for designing IoT-based PLSCS. Based on
ontology and PN, we devise modeling methods to support each layer of IoT application design. These
methods can facilitate IoT application development by substantially improving the modularization of
different concerns, lowering coupling between the software models in each layer, and minimizing the
misalignments among these modeling layers. Implementation architecture and application scenario are
provided to evaluate the applicability of our proposed modeling framework. The second part of this research
will present an IoT-based Cyber-Physical System (CPS) framework for production logistics management,
describe the system architecture of the framework and its application in the context of the IoT-based
manufacturing supply chain network, and evaluate the benefits and costs of adopting CPS in managing the
dynamics of production logistics. This paper presents the first part of the research study on IoT-based
production logistics and supply chain system. The remainder of this paper is organized as follows. Section 2
presents our proposed IoT system modeling framework. Section 3-5 discusses IoT ontology modeling, IoT
process modeling, and IoT object modeling respectively. Section 6 describes the system implementation and
practical implications. Finally, concluding remarks are presented in Section 7.
5
Figure 1. EPCglobal Network architecture framework
2 IoT systems modeling framework

To meet the challenges above, this article proposes a novel IoT system modeling framework supporting
formal model validation methods and the clear separation of concerns between different IoT system models.
A running example is also introduced in this section to facilitate the analysis and discussion of the
modeling framework.
2.1 A multilayer hierarchical modeling framework

As stated in previous section, the focus of this research is to develop appropriate modeling scheme to
better design IoT-based PLSCS, which mainly concern physical and information flows of objects or business
assets, like product and parts, on a manufacturing supply chain. In other words, objects or things are central
to IoT-based PLSCS. In the context of manufacturing and supply chain applications, objects usually refer to
movable assets like parts or manufactured products, which can move within a firm or across a supply chain.
When these objects are RFID tagged, they become an IoT-enabled objects and can be tracked and traced by
IoT systems. Hence, from the perspective of an IoT-based PLSCS, an IoT-enabled object is always located in
a particular space–time context under the custody of a business entity with a particular process semantic
given to it. The above analysis indicates what types of information might generated from an IoT-enabled
object when it is observed by an IoT-based PLSCS. Thus, we categorize the information space for IoT-based
PLSCS in five dimensions. The five dimensions are visualized in Figure 2 using a five-tuple vector
comprising the object, business entity, location, time, and process informatics. Taking the initial letter of
each tuple, we called the five-tuple vector an OBLTP vector and it also represents the main types of data
source for IoT systems considered in this study. The OBLTP data can be mapped to the 4Ws of an EPCIS
event. A scenario in Figure 1 describes an EPCIS event contains two RFID tagged products (what) detected
by a RFID reader at certain space (where) and time (when) with a particular process semantic (why)
6
assigned to this RFID reading event, and the RFID reading point and business location defined in an EPCIS
event are owned by a business entity. Therefore, the data element of an object’s EPCIS event must contain
elements from the OBLTP. The physical flows of an object and its related process semantics are recorded as
a sequence of event points over discrete space–time slices.
Figure 2. A five-dimensional view of an IoT-based PLSCS
2.2 Modeling methodology

This paper employs a multilayer hierarchical-modeling scheme for IoT application modeling. This IoT
application modeling framework, as illustrated in Figure 3, is divided into three layers of modeling because
each layer uses different modeling approaches to address different IoT system requirements. At the top of
the framework is the ontology-modeling layer. An ontology concept model must be developed before IoT
process modeling, which utilizes IoT ontology as a modeling element. The process-modeling layer uses the
PN formalism to construct a mathematical structure for the IoT-based system model. The model must be
validated before moving to the object model. If the validation fails, we must determine the cause and rebuild
the IoT system model. At the bottom of the framework is the object-modeling layer in which a colored Petri
net (CPN) modeling scheme is used to construct an IoTOM. Although consigned in different layers, these
models are related and together present a complete picture of IoT application modeling scheme. As many
IoT-based systems are considered as a DES, this paper adopts PN as the main modeling tool. PN can be used
to simulate the dynamic and concurrent activities of systems using tokens (Murata, 1989), and it can also be
used to dynamically record system status by tokens (Jiang et al., 2017). PN and its extensions such as
colored Petri Net (CPN) are based on sound mathematical theory and have strong capacity to model, analyze,
and validate properties of DES such as concurrency and synchronization (Jiang et al., 2017). Many
alternatives also allow to model the dynamics of DES, such as the activity diagrams in unified modeling
language (UML) and finite state machine (automata), however, these modeling methods either lack a formal
semantics and/or propose a more complicated scheme (Bouraga et al., 2016). For instance, UML is currently
most wildly used system modeling language, however, it doesn't well support the modeling of dynamic
behaviour in object-oriented systems and formal validation of these system specifications (Leitão, 2006).
Hence, UML activity diagrams are often transformed to PN for model checking (Barjis, 2009). Furthermore,
7
UML is unable to capture the concurrency in DES and has no similar modeling concept of PN tokens, which
can be used to model object movements and the physical flow and information flow of IoT objects. The
language of PN is also larger than automata language and thus PN can model a larger set of system than
automata does (Saadallah et al., 2011). PN has been proven to be an effective system-modeling tools to
model and analyze DES and distributed manufacturing system (Hsu et al., 2003; Xu and Shatz, 2003; Lv and
Lin, 2017). Most impoprtanly, PN can easily model object movements in a DES using PN tokens. As models
are often considered as mathematical structures forming the semantical conceptual model behind a
description formalism in software engineering (Broy, 2001), we thus choose PN as our modeling method
because it fullfill most of our modleing requirements for IoT-based systtem than other alternatives. The
following sections will discuss each modeling approach in detail.
Figure 3. IoT-based PLSCS modeling framework
2.3 Running example

Before introducing formal modeling methods, an IoT application scenario of a global manufacturing supply
chain is provided as a running example in this paper to explain the modeling processes and illustrate the
applicability of our proposed modeling framework. The firm analyzed in this scenario is TECO Electric and
Machinery, a major home appliance manufacturer in Taiwan. TECO manufactures products of its own brand
and sells products in almost all major distribution channels in Taiwan and abroad. The operations of TECO
in Taiwan employ several flexible production lines, allowing the firm to produce products with small lot
sizes and minor model variations according to customer requirements, the products of which include air
conditioners, refrigerators, dehumidifiers, and other home electronics. The product selected for this study
was dehumidifiers. The reason to launch this IoT project is that the firm and the dehumidifier industry
experienced several incidents involving fire and burn injuries during 2008-2014. Many incidents were
caused by defective dehumidifier components or suppliers using uncertified parts/counterfeits in Taiwan.
Therefore, to protect consumers from such life-threatening accidents, TECO must ensure the quality of its
dehumidifiers by proactively monitoring and controlling every relevant manufacturing and distribution
process. The situation concerning product safety motivated TECO to seek for a novel solution to resolve the
above mentioned problems and enhance its supply chain visibility for both a product and its associated
8
critical parts inside a product, such as the printed circuit board (PCB). Our proposed modeling methodology
was applied to help TECO designs its IoT application to achieve its goal and used as the running example
throughout this paper.
3 Ontology modeling layer

In computer and information science, ontology often refers to the specification and categorization of a
conceptualized domain and is often expressed in a computer-interpretable format such as the XML (Tu et al.,
2009). Business modeling usually begins by finding appropriate concepts and entities in the organization
domain. Ontology can be used to model IoT domain knowledge. For example, De et al., (2012) used
ontologies to define an IoT information model and Meyer et al., (2013) used ontologies to describe IoT
domain components, such as IoT devices and services. Figure 4 elucidates our IoT ontology-modeling
process in which the IoT domain model and use-case model are synchronized to generate the IoT ontology
model. The process is ongoing, which means that should any new concept or entity be captured in the IoT
domain model, the model should refine accordingly. An IoT domain model contains objects that represent
concepts, entities, attributes and the relationships among them; it is a baseline model upon which use-case
analysis relies. To obtain the IoT (application) domain model, one must conduct extensive application
domain analysis and data collection, including documents analysis, domain expert interviews, and observing
operation scenarios. Some qualitative social science methods, such as grounded theory or systems
engineering methods, like qualitative knowledge construction (QKC) (Bartolomei et al., 2009) could
facilitate IoT domain analysis model construction. A formal ontology model usually has five elements:
concept, property, relation, axiom, and instance (Haller et al., 2008), and this study follows this convention
in designing our IoT ontology model, as illustrated in Figure 4.
As we are modeling the IoT systems in production logistics applications, EPCIS events are a major data
source for our system and must be defined in a clear, unambiguous way. Using ontology enables us to
explicitly describe the semantics of an IoT application domain, facilitating the definition of EPCIS events in
the context of an IoT application. Based on the five-dimensional view of an IoT-based PLSCS (Figure 2)
and the TECO application scenarios, we constructed an IoT-aware ontology concept model (IoTCM) with
five domain categories, as shown in Figure 5. In the model, each category corresponds to one OBLTP
dimension. A prototypical ontology and process management tool was developed to facilitate the creation
and managing of the OBLTP ontology elements, as shown in Figure 6 where OBLTP ontology elements can
be created and removed (illustrated in step 1 and step 2 of Figure 6).
9
Figure 4. IoT ontology-modeling process
Figure 5. IoT-aware ontology concept model (IoTCM) example (partial view)
10
4 Process modeling layer
Following the previously developed IoTCM, the next step is to model an IoT-aware process according to our
proposed IoT system modeling framework. In modeling an IoT-aware business process, previously designed
ontologies can be conveyed to the process model elements (Meyer et al., 2013) and the two design models
can thus be aligned. The notations used for IoT process modeling are denoted in Figure 7, part of the
notations such as process-link gateway markers are adapted from the business process modeling notation
(BPMN). The details of IoT process modeling are discussed in this section. We divide the process of
constructing an IoT-aware process model (IoTPM) into seven major steps:
(1) Define the scope of a manufacturing supply chain and set an organizational boundary for each supply
chain’s participant/stakeholder.
(2) Create IoT process steps based on the OBLTP ontology and defines object pattern filter for those steps
requiring RFID/Sensor reading
(3) Assign IoT process step instances created in step 2 to any applicable organizational boundary of supply
chain participants defined in step 1.
(4) Create a baseline IoTPM by linking process steps with material and information flow.
(5) Convert the baseline IoTPM to a PN-based IoTPM.
(6) Conduct model diagnosis and fault detection of the PN-based IoTPM using algorithm 2 to obtain a
fault-free model. If any model fault is detected, the modeler must modify the faulty design in the model
and perform another diagnosis to validate the model.
(7) Create an IoT-aware process model
Section 4.1 will first discuss process modeling steps 1~4; the first milestone from these four modeling is a
baseline IoT process model. Section 4.2 will detail the rest of modeling steps (5~7) and present the final
result-an IoT-aware process model.
4.1 Constructing a baseline IoT process model

Step 1 (Define boundary): The first step in IoT-aware process modeling is to set the IoT application
boundaries within which the scope or boundary of a key organization in a manufacturing supply chain must
be determined. The organization’s supply chain partners are then identified and linked to the organization. In
a typical IoT scenario, the IoT process boundary could begin with suppliers delivering their parts to a
manufacturer and end when the manufactured products are delivered to retailers.
Step 2 (Create IoT process steps): The second step of the process modeling is to create IoT process steps
using previously defined OBLTP ontology elements. The ontology and process management tool can be
used to help create IoT process instances. Figure 6 presents the tool’s interface for process step creation.
Step 2 is decomposed into four substeps:
Substep 2.1: Creating a process step with process name and process ID.
Substep 2.2: Incorporating business logic into the process step by adding OBLTP ontology elements to the
process step. The incorporated OBLTP ontology elements become properties of a business
step, and these properties can be added or removed from the model during building and
refining phases.
Substep 2.3: Assigning a RFID reader group to the process step (also from OBLTP ontology elements), if
11
necessary.
Substep 2.4: Specifying the RFID tag pattern filter for the chosen RFID reader group.
The default RFID data pattern is the EPC coding scheme. A RFID tag filter pattern is used to allow or
refuse tagged objects entering a certain location. For example, a warehouse can create rules refusing
products of certain EPC object classes (product type) to entry because of safety concerns. We can configure
different pattern filter for each RFID read/write point. Finally, the information regarding the OBLTP
ontology objects and IoT process instances are stored in the tool’s data repository.
Step 3 (Assign IoT process steps to boundary): Based on the process step instances created in step 2, step 3
further assigns IoT process steps to any applicable organizational boundary of supply chain participants. By
analyzing TECO’s dehumidifier production processes and supply chain, we identified major process steps
assigned these steps to the home appliance manufacturer and its supply chain partners.
Step 4 (Create a baseline IoTPM): Step 4 used process-link gateway markers (denoted in Figure 7) and
baseline IoT-aware process templates (described in Figure 10) to link IoT process steps with physical and
informational flows and developed a baseline IoTPM as a three-echelon manufacturing supply chain
network. Figure 8 presents the modeling result of a baseline IoTPM as a close-loop IoT information system.
The model in Figure 8 can easily be expanded to multiple supply chain echelons with multiple firms in each
echelon.
Figure 6. IoT ontology and process management tool
12
13
Figure 7. IoT process modeling notations
Figure 8. Baseline IoT process model
4.2 Constructing the IoT-aware process model

After constructing the baseline IoT process model, we must validate the model to ensure there is no
design flaw inherent in the model structure. Detecting design faults and preventing potential deadlocks and
conflicts in the IoT process model requires a rigorous theoretical framework to conduct a behavioral and
structural analysis of the model. However, we cannot perform structure and behavior analysis on the
baseline process model. Therefore, to further analyze and validate the baseline IoT process model (IoTPM),
we convert the baseline IoTPM into its corresponding PN-based IoTPM.
Step 5 (Convert the baseline IoTPM to PN-based IoTPM):

To provide a formal mathematical description of the IoTPM described in previous sections, we present
several key definitions and theorems, some of which are adopted from Murata (1989), Zhou and Venkatesh
(1999), and Renganathan and Bhaskar (2010). Thus, this study generalizes PN with IoT process events
related to PN transitions and names it IoTPM Petri net, abbreviated as IoTPMN. The definition of IoTPMN
is described as follows.
Definition 1 (IoTPMN)
An IoTPMN is a five-tuple PN = (P, T, I, O, M0), where P is a finite, nonempty set of places; T is a finite,
14
nonempty set of transitions; I is an input function that defines directed arcs from places to transitions; O is
an output function that defines directed arcs from transitions to places; and M0 is the initial marking of all
places.
Definition 2 (IoTPMN preset and postset)

The multiplicity of the pair (Pi, Tj) can be viewed as preset and postset. Preset represents the set of input
places connected to a transition, denoted as ‧Tj or the set of input transitions connected to a place, denoted
as ‧Pi ; conversely, postset represents the set of output places of a transition, denoted as Tj‧ or the set of
output transitions of a place, denoted as Pi‧.
Definition 3 (IoTPMN execution rules)

If Mk (Pi) ≥ I(Pi, Tj) for every Pi ∈ ‧ Tj (where ∈ means “belongs to”), transition Tj is enabled for a marking
Mk.
Definition 4 (IoTPMN input/output matrix)

The input function I can be represented as a matrix D− = [ ], where = I(Pi, Tj), which is called the
input incidence matrix or abbreviated to the “input matrix”. Similarly, the output function O can be
represented as a matrix D+ = [], where = O(Pi, Tj), which is called the output incidence matrix or
abbreviated to the “output matrix”.
Definition 5 (IoTPMN incidence matrix)

For an IoTPMN with n transitions and m places, the incidence matrix (or flow matrix) A = [ ] is an n ×m
integer matrix defined by Eq. 1.
A = [ ] = D+ - D− = [ ] - [ ], (1)
Definition 6 (IoTPMN firing control vector)

The firing control vector uk is an n × 1 column vector of n - m 0's and m nonzero entry, where each entry of
the vector uk represents one transition in an IoTPM and an entry with value 1 denotes an enabled transition.
Definition 7 (IoTPMN state transition equation)

Given the incidence matrix A of an IoTPMN, the firing control vector uk, M0 be an initial marking, and Md
be a destination marking that is reachable from M0 through a firing sequence {u1, u2, ... ud}. We thus define
Eq. 2 as the state equation of an IoTPMN, where M and uk are column vectors
Md = M0 + ∑
. (2)
Definition 8 (IoTPMN firing count vector)

By rewriting Eq. 2, we can obtain
Md = M0 + x, (3)
where x = ∑
. The n × 1 column vector of nonnegative integers is called the firing count vector.
15
The firing sequence is valid only if Md is a nonnegative vector and Md is reachable from M0 through the
firing sequence Ω, where Ω= {t1, t2, ... td} be a sequence of transition firings in an IoTPM. Thus, if Md is
reachable from M0, the corresponding firing count vector x must exist.
Figure 9 presents a simplified IoTPMN model and its underlying mathematical representation of an
IoTPMN state equation (definition 7). Additionally, algorithm one is developed below to facilitate acquiring
the firing control vector for the IoTPMN state equation during system evolution and illustrated in the bottom
of Figure 9.
Algorithm 1 (Acquire firing control vector from IoTPMN).

Input: Given a target IoTPMN Ψ, the preset vector V‧T for the ‧T of Ψ (Definition 2), input matrix
and output matrix of Ψ (Definition 4), incidence matrix A of Ψ (Definition 5), and current
marking Mc of Ψ.
Output: A firing control vector
at any stage of an IoTPMN’s evolution
Method:
Step 1 Find the firing condition vector, , by multiplying D and Mc.

Step 2 Compare the V‧T with the . and determine the intersection of two vectors with values common
to both V‧T and VFC ( V‧T ( i ) = VFC ( i ), ∀i, 1≦i≦n ). If any matched value is identified between
V‧T and VFC, proceed to Step 3; when no match is detected, return an empty set (implying that an
IoTPM has a deadlock state, because Mc cannot trigger any transition).
Step 3 Construct an n × 1 column firing control vector
containing the intersection (common elements)
of V‧T and VFC.
Figure 9. Mathematical representation of an exemplary IoTPMN and the illustration of Algorithm 1

16
To validate the static baseline model in Figure 8, we convert the baseline model into a PN-based dynamic
model (an IoTPMN) to allow for model structure and behavior analysis. To achieve the goal, we must
establish the mapping between baseline IoT process patterns and IoTPMN. The approach for transforming
baseline process model to IoTPMN is based on the BPMN to PN transformation scheme proposed by
Ou-Yang and Lin (2008). Figure 10 presents the templates for both baseline IoTPM and IoTPMN process
and the transformation guidelines between them. Based on the conversion rules presented in Figure 10, we
devise three steps to convert the baseline IoTPM to an IoTPMN, as illustrated in Figure 11.
Figure 10. The process modeling templates and guidelines for model transformation
between baseline IoTPM and PN-based IoTPM
17
Figure 11. The illustration of converting a baseline IoTPM model to an PN-based IoTPM
Step 6 (Model validation of the IoTPMN):

The objective of step 6 is to conduct fault diagnosis to validate IoTPMN. We developed the algorithm 2
to diagnose whether an IoTPM design is deadlock-free. Algorithm 2 target three types of model fault defined
in this research. The first type of fault is called the faulty transition set (FTS). If the IoTPMN encounters a
deadlock during a system simulation, it cannot escape from that state; in other words, no operations
(transactions) further down the line can proceed. Therefore, it is crucial that algorithm 2 perform deadlock
analysis to detect any deadlock inherent in the IoT process design. The second type of fault is the unfired
transition set (UTS), which indicates that some transitions may never be executed in the model. The third
type of fault is the multiple firing transitions set (MFS), which describes a situation where some transitions
may be executed more than once. However, this infinite loop may not be an actual fault. Depending on the
model design purposes, a system may allow some transitions to perform a task multiple times. Nevertheless,
the algorithm two still helps identify infinite loop states in the system and let system designer judge whether
these states are faulty states. The model diagnosis and fault detection are explicated in the following steps.
Substep 6.1: Use Algorithm 2 (describe below) to validate the IoTPMN. If the IoTPMN contains any one
of the following faults-FTS, UTS, MFS, then execute 6.2, otherwise perform 6.3.
Substep 6.2: Renew the model by modifying the fault affected IoT process steps, revising the model
structure, and repeat 6.1 until a fault-free model is obtained.
18
Substep 6.3: If no fault found in the IoTPM, we obtain a fault-free IoTPM.
If a new IoT process step is being added to the baseline IoTPM, Substep 6.1 must be executed again. To
automate the model validation of IoTPMN, we devised a deadlock diagnosis and detection algorithm
(algorithm 2) according to the previously defined IoTPMN definitions and mathematical properties.
Algorithm 2 can easily be implemented using programming languages. The details of Algorithm 2 are
presented below.
Algorithm 2 (IoTPM fault diagnosis and detection).

Input: Given a target IoTPMN Ψ, the preset vector V‧T for ‧T of Ψ, input matrix D− and output matrix D+
of Ψ, incidence matrix A of Ψ, initial marking M0 of Ψ, and final marking MF of Ψ.
Output: Output at least one of the following result sets: (1) a faulty transition set (FTS), (2) an unfired
transition set (UTS), (3) a multiple firing transitions set (MFS), (4) an empty set (no fault)
Method:
The flowchart in Figure 12 illustrates the conceptual algorithm for IoTPMN diagnosis and fault detection.
An example showing the application of Algorithm 2 for the model diagnosis, fault detection, and model
revision for a flawed IoTPMN design is illustrated in Figure 13.
19
Figure 12.
20
Flowchart of Algorithm 2
Figure 13. An example of model diagnosis, fault detection, and model revision for IoTPMN using
Algorithm 2
Step 7 (Create an IoT-aware process model):

As we obtained the fault-free IoTPMN in the prior step, the final phase (step 7) of process-layer modeling
is to create the final IoT-aware process model. We first replace baseline process-link gateway markers with
PN-based process-link gateway markers on the baseline IoT process model (Figure 8). There are four types
of such gateway markers shown in Figure 7, including communication node, buffer node, resource node, and
status node. These PN-based gateway markers serve as logical connectors that bridge material and
information flows between any two IoT-aware process steps and contextualize these connections. The
default status node (SN) denotes the status a tagged object is in, such as in the working status of PCB
assembly. Thus, an SN is used to describe the characteristics of a single-item process. The buffer node (BN)
is an extension of the SN and used to describe a physical place-holding multiple tagged objects (ex. a
buffering area) and batch-processing states where a single process step may simultaneously handle multiple
objects. The resource node (RN) denotes the availability of a resource for a specific process step, for
example, a processing machine, robot, or material handling device. Finally, a communication node (CN) is
devised to facilitate intra- and inter-organizational process communication. We used CN to model
information feedback flow among supply chain partners, forming a closed-loop manufacturing supply chain
network. A completed IoT-aware process model is then presented in Figure 14.
21
Figure 14. The IoT-aware process model
5 Object-modeling layer
In the object modeling phase, we extend the IoTPM to endow it with more descriptive power, thus enabling
the behavior of various IoT objects in an IoT system to be systematically described and modeled without
losing the analyzable properties of the original IoTPM. In the object modeling, we introduce the CPN
modeling scheme to extend the IoTPM to an IoT object model (IoTOM). A CPN model can be used as a
specification of a system that we intend to build and provides a dramatically improved understanding of the
modeled system (Bartolomei et al., 2009). CPN was also proven to be an excellent modeling tool for
designing RFID-based manufacturing systems (Chen 2012; Lv and Lin, 2017) and RFID-based
quality-monitoring system for manufacturing (Lv et al., 2012). By applying the CPN-modeling scheme, we
extend the IoTPM to an IoTOM. Definition 9 provides a formal description of the IoTOM.
5.1 IoT-aware object model

Definition 9 (IoTOM)
An IoTOM is a six-tuple CPN = (P, T, F, S, M0, C), where P, T, and M0 represent the place, transition, and
initial marking of IoTPM, respectively, as explained in Definition 1. C = { C1, C2, …, Cn } is a finite color set,
F denotes a firing condition function, and S denotes a token transfer or transformation function.
22
The basic idea of CPN is to assign colors to tokens and associate each colored token with arbitrary data
types; each data type may also include a collection of data values. In an IoT system design, we often want to
model various object classes, such as component, product, and resource, into the system. The CPN-based
IoTOM can thus capture this information with a finite color set C = {C1, C2, …, Cn}. Each element in a color
set is called a color, and each color can represent a specific component, product, or resource type in an IoT
application. The IoTCM (Figure 5) defines the corresponding concept of the colors. Each color in a color set
not only symbolizes an ontology concept but contains attributes describing the properties of that concept.
For example, we can designate an upper index on each element of the aforementioned finite color set C to
represent quantity, denoted as {C1 n, C2 n, …,Ci n}, where i is an instance of a color class, and n is the total
number of that color class; each color class represents a specific IoT object, such as a component or finished
product. The firing condition function F defines the firing conditions for each incoming edge of a transition
in a CPN model. A transition can be enabled (fired) only when all of its firing-condition functions are
evaluated as being true. Finally, the token transformation function S defines the token
transfer/transformation rules for each edge departing a transition. After being successfully fired and executed,
a transition will generate at least one token, and the new tokens will be deposited into the set of output
places of a transition.
5.2 Constructing an IoTOM

An exemplary CPN-based IoTOM is presented in Figure 15 to illustrate the object-modeling concept. The
model is transformed from part of the IoTPM presented in Figure 14. The CPN’s place (P) set is inherited
from the IoTPM’s process-link gateways. Therefore, four types of PN-based process-link gateways directly
correspond to four types of CPN place set. In CPN modeling, a communication place can facilitate
command communications between PN models (Chen 2012); we adopted such modeling scheme in this
study. The business logic for each transition (process step) and pattern filters for that transition are also
inherited from the IoTPM. In other words, in our modeling scheme, business logic is encoded in each
transition and tag filtering patterns are encapsulated in each firing-condition function. Tables 1–3 present the
design logics for functions and transitions pertinent to the PCB assembly operation in the exemplary IoTOM
(Figure 15). The task execution business logic of each transaction in IoTOM, for example, the Checkin task
of T2, is defined first in IoTCM and inherited by IoTPM and IoTOM. To enable item-level visibility and
tracking, IoT system must collect the EPCIS event data from all supply chain participants and share that data
with those participants. EPCIS events collected by RFID readers at critical points along the supply chain are
contextually enriched RFID-reader events (Tribowski et al., 2009). These context-aware EPCIS events are
also defined in the IoTOM. The context of each EPCIS event is inherited from the IoTPM and IoTCM
because each transaction in the IoTOM, such as T3 in Figure 15, is associated with a process step defined in
the IoTPM by using OBLTP ontology elements defined in the IoTCM. Figure 16 illustrates an EPCIS event
for the PCB assembly process (T3) of the exemplary IoTOM. This EPCIS aggregation event example shows
that an IoT reader point, usually represented by a transaction in our model, is contextualized using object,
business entity, location, time, and process data. The vocabulary we use in EPCIS events follows the core
business vocabulary (CBV) proposed by EPCglobal. However, the CBV is currently limited, particularly
regarding manufacturing-related processes. Thus, some self-defined business vocabularies are also adopted
in this study. In this paper, we only define object types for products or components within a manufacturing
23
supply chain under IoTOM. In fact, we can further define the internal attribute or data structure for each
object type represented by a color set in the model. For example, the workpiece dehumidifier C9 can be
devised to have token attributes such as workpiece no., process no., equipment type, etc. All or part of these
attributes can be stored in the memory a RFID tag attached with or embedded in that workpiece. These
attributes can be retrieved and updated in each transaction set of the IoTOM, allowing distributed and offline
processing of IoT objects in an IoT endpoint. Detailed illustration of data structure design for IoT objects
can be seen in Tu et al., (2009) and Chen (2012).
Figure 15. An exemplary CPN-based IoTOM
24
Figure 16. An example of a contextually enriched EPCIS event
Table 1 Design of f2, f3, and f4
25
Table 2 Design of T2, s2, and f5
Table 3 Design of T3, s3, s4, and s5
26
6 Implementation and practical implications
In this section, we first briefly describe the implementation of the case study and then discuss its practical
implications. Our proposed modeling methodology was applied to help the design and development of the
IoT-based system for the manufacturing supply chain described in the case study. The results and insights
obtained from the system implementation of the case study (the running example) are used to elucidate the merits
of our approach and to generalize our research implications.
To evaluate the feasibility of applying IoT technologies in its manufacturing supply chain, the TECO
conducted a prove-of-concept IoT pilot project with Industrial Technology Research Institute of Taiwan. The
basic model of its supply chain includes two part suppliers, one manufacturer (itself), and one retailer (its retail
division). The development process of the IoT pilot application consists of two major phases-design and
implementation. In the design phase, IoT system design models developed in the ontology-, process-, and
object-modeling layers are modularized to address the modeling concerns of each layer. In the implementation
phase, the design models developed in the previous phase were converted into implementation logics to assist
IoT application development. Thus, we also proposed implementation architecture to guide system development.
6.1 Implementation architecture

The proposed implementation architecture is presented in Figure 17, which describes the architecture
components that comprise the software and hardware components. We have verified our proposed architecture
with a prototype system implemented as shown in Figure 17. The hardware components consist two major
platforms, the client and server platforms. The client platform includes Intelligent IoT edge processing node,
abbreviated as iNode, which connects and integrate with various sensor and automation devices, such as RFID
readers and robots in a factory workstation, as shown in Figure 17. Active or passive RFID tags or other types of
sensor devices embedded in parts and products are also included in client platform. Figure 17 illustrates product
tagging scheme for a dehumidifier. The server platform contains servers in a data center, and they collectively
form an IoT Cloud. We consider most of the networking devices as part of the server platform.
The software components of our proposed implementation architecture can be divided into four parts. The first
part is the distributed data storage. The IoT data can be stored in IoT cloud, iNodes, and in RFID tags, as shown
in Figure 17. IoT Cloud uses a relational database to store most system data while iNode store parameters and
temporarily data in files. The second part is the distributed data collection and access logic. Different from
traditional enterprise systems, the data source of IoT-based systems often contains various sensor data. Some
sensor device could generate a large volume of raw data in a few seconds, such as the raw RFID in the case study.
Thus we installed a RFID middleware module in each iNode to filter raw RFID data and convert them to
contextualized OBLTP data sets in EPCIS event format. The other data access collection and access logic are
implemented in IoT Cloud which employed ETL (extraction, transformation, and loading) programs to
synchronize OBLTP data from iNodes and other manufacturing and enterprise data from IoT cloud applications.
The third part of software components is the distributed application logic which comprises cloud-level business
application logic implemented as various cloud application modules and client level application logic
implemented as iNode control logic. We implemented the IoT cloud as a multi-tenant software as a service (SaaS)
platform for the IoT-based manufacturing supply chain. Finally, the fourth part is the distributed presentation
logic which also implemented in both cloud and client (iNode) levels as IoT cloud web user interface and iNode
monitoring and control HMI (human machine interface). Figure 17 demonstrates the web user interface for IoT
27
cloud application and the HMI monitoring the operation of a PCB assembly workstation in a manufacturing cell.
Figure 17 also explicate the relationships between the IoT system design models (five models) and IoT
system implementation architecture. As the case study used object-oriented design method to develop IoT
application, the three IoT system design models discussed in this paper (including IoTCM, IoTPM, IoTOM)
served as the reference models to guide the design of unified modeling language (UML) based IoT structure
model comprising UML class diagrams. IoTCM provides the basic entity model for initial UML class design.
Then, the UML structure model can be mapped to Entity-Relationship model (data model) containing
relational database schemas, and part of the data model can also be duplicated implemented on a RFID tag
using self-defined RFID tag encoding scheme, allowing off-line access of product data directly from a RFID
tag embedded in a product. Finally, function and transition logics of the IoTOM were also used implemented
as part of control logic on iNode and application logic of IoT cloud application.
Figure 18 shows a high-level system view integrating design models and implementation architecture. The
view denotes a simplified IoTOM for the dehumidifier manufacturing supply chain, where a single IoTOM
transaction for a manufacturer in Figure 18(a) can be exploded into a set of transactions in a full IoTOM
model. In Figure 18(a), our IoTOM can be seen as an IoT-based adaptive manufacturing supply chain network
model describing the interconnectedness and interactions among different supply chain entities. Based on the
IoTOM, a holistic IoT dashboard system could also be developed to track object flow status in real time over
a manufacturing supply chain and dynamically present the changing information of supply chain objects,
including parts, products, and orders. The IoTOM model in the case study had also synchronized with its
IoTPM and IoTCM. Finally, the IoTOM had aligned with the underlying software architecture of the EPCgloabl
Network and the proposed implementation architecture, as shown in Figure 18(b).
6.2 Practical implications

Previous sessions describe the design and development of the IoT-based system for the case study based on
the proposed modeling framework. We found several advantages of using our proposed methodology in the
practical implementation of IoT-based PLSCS for TECO and its supply chain partners in this case study and
summarized the findings as follow.
1. IoT ontology and process management tool help maintain the single source of truth of OBLTP naming
for all firms collaborated on a manufacturing supply, reducing the ambiguities and inconsistency in
defining terminology by different supply chain participants.
2. IoT ontology and process management tool and the proposed IoT process modeling scheme significantly
improved inter- and intra- organizational process modeling effort. The tool and the IoTOM also help
supply chain participants quickly reach consensus on the content of EPCIS-based supply chain events,
identify critical points of manufacturing supply chain, and design the RFID reader processing logic and
deployment scheme across the critical points manufacturing supply chain.
3. IoTPM fault diagnosis and detection method described in Algorithm 2 provide a formal and rigorous
method to help system developer diagnosis the distributed process design of IoTPM and detect faulty
process design before implementation, ensuring the validity of an IoT-enabled manufacturing supply
chain model.
4. The core IoT design models (IoTCM, IoTPM, IoTOM) can be easily modified for different IoT
application scenarios and saved in different versions for reuse. The proposed method also allow us to
28
design business logic on both IoT-aware process and IoT device. Hence, our proposed modeling
approach is flexible to accommodate model changes and scalable to add more production lines and
supply chain entities into the base model described in this case study, greatly reducing the system design
complexities.
5. IoTOM contains high-level abstraction of implementation logic capturing physical and information
flows of product and parts. The logic inherent in IoTOM can be easily implemented as control logic
within the proposed implementation architecture framework.
6. IoT object modeling scheme can easily model the movements of RFID tagged product and product
components in an IoT-aware process using CPN tokens and incorporate their dynamic information in one
model (IoTOM). System implementation based on the IoTOM enable an IoT-based PLSCS to track
product and different parts of the same product along a manufacturing supply chain
7. The implemented IoT-based PLSCS enabled TECO to detect uncertified component or counterfeit parts
during production and at later stages of product repair, greatly enhanced its product safety for consumers
while holding its suppliers accountable for defective parts.
The findings above shown that each layer of IoT design model is modularized to address different IoT
application concerns in different modeling layers. In addition to the decoupling of different concerns, the
alignment among models is also a critical consideration in our methodology. In our hierarchical modeling
architecture, a higher-level model provides the baseline for its subsequent application modeling. Thus a model
built at a lower layer will be aligned with a model in its preceding layer. For example, the baseline IoTPM
always serves as a basic model upon which a final IoTOM is developed. Thus, our modeling methods ensure that
an IoTOM is always aligned with its IoTPM; likewise, IoTPM entities such as process steps are inherited from
IoTCMs. Thus, the alignment among ontology, process, and object models is achieved.
The case study of this research also implied that our proposed modeling approach and implementation
architecture could easily be applied to many discrete manufacturing industries, such as the automobile,
airplane, bicycle, home appliance, and electronics industries. Figure 17 has demonstrated a discrete
manufacturing example of our implemented IoT-enabled PLSCS showing the PCB assembly of a
dehumidifier in real industrial settings. Supply chain partners can easily access the production and supply
chain pedigree through the multi-tenant SaaS IoT cloud, as shown in Figure 17. Further applications of the
pedigree include using the IoT-enabled PLSCS to record a product’s environmental pedigree to prove its
compliance with environmental regulations, such as the Restriction of Hazardous Substances (RoHS) and
Waste Electrical and Electronic Equipment (WEEE) directives, or to track carbon footprints of products
Another important implication of the proposed IoT system design and implementation framework lies in
its prospects to support the design and development of IoT-based cyber-physical systems (CPS) or
cyber-physical production systems (CPPS) for production logistics and manufacturing supply chain
management in the industrial 4.0 era. Key ingredients of an IoT-based CPS based on our proposed
implementation architecture in Figure 17 include one IoT cloud and several iNodes. Each iNode manages
multiple IoT devices, such as an industrial robot and conveyor, and collects OBLTP data from IoT devices
during PL operations, including RFID data and various sensor data. The IoT cloud responsible for collecting
data from all iNodes and process these data to generate new knowledge which can later feedback to iNodes
so that iNodes can adjust their behavior based on new business rules, as illustrated in Figure 17. Under the
architecture, each supply entity could develop its cyber-physical systems (CPS) with intelligent IoT edge
29
processing nodes (iNode) deployed in critical manufacturing supply chain points to perform PL tasks and
collect IoT data, such as a manufacturing cell or product packing station. The IoTOM is shared among
supply chain participants and stored in the IoT cloud. Each firm’s CPS also own part of the model since each
IoT-aware process in an IoTOM is mapped to a transition in an IoTOM as presented in Figure 15 or Figure
18(a). Each transition in the IoTOM has a corresponding EPCIS event template and related business logics
expressed in pseudocode, as illustrated in Table1~3. The design artifacts in the IoTOM can be implemented
in both client (iNode) and server (IoT cloud) for CPS. The multi-tenant IoT cloud shown in Figure 17 can be
hosted by a trusted third party IT service firm or by one of the key player in a supply chain, such as the
manufacturer. The implementation architecture described in Figure 17 also presents an operation scenario of
an IoT-based CPS system for discrete manufacturing. Finally, Part 2 of this research will further explore this
topic with a more in-depth discussion of an IoT-based CPS framework and its evaluation.
Figure 17. The implementation architecture and its relationship with system design models
30
Figure 18. (a) A holistic IoT dashboard monitoring real-time object flow status over a manufacturing
supply chain (b) Underlying IoT system architecture integrated with the EPCglobal Network.
7 Conclusion
As more enterprises embrace IoT technology, its applications are expected to seamlessly integrate
information and physical object flows and transform firms into a real-time enterprise. However, the lack of
unified, coherent modeling frameworks and formal model validation methods poses many challenges for
design and implementation of IoT-based PLSCS. Challenges may also arise from system development.
Developing a complex IoT application may involve numerous participants, such as engineers and managers,
from various departments or companies. These participants need to communicate often during application
development. However, communication using natural language often causes ambiguity. A formal model
offering formal semantics can serve as a common language for all parties. The major contribution of this
paper is to address these challenges of in developing IoT-based PLSCS by devising a formal modeling
approach to facilitate the validation of system design model and to ensure the reusability and maintainability
of an IoT-based PLSCS. The top–down modeling methodology described in this paper allows the separation
and modularization of different IoT application development concerns in the ontology-, process-, and
object-modeling layers. Also, alignment of models in the three layers and between system design models
and the implementation architecture can also be achieved. It is not a trivial task to develop IoT-based PLSCS
31
that exhibit characteristics of a dynamic and distributed complex information system. The proposed layered
architectural framework for IoT system modeling explicated in this paper can help reduce modeling
complexity and provide new theoretical lenses through which the structure and dynamics of a complex
multidimensional IoT system for manufacturing supply chain application can be understood and modeled
systematically.
The modeling schemes presented in this paper represent only the first step in improving the design
approaches for IoT application development. The modeling and design methodology discussed in this paper
can analyze IoT applications well as long as it is in a DES. It is less for describing and analyzing continuous
event systems or combined discrete and continuous event systems, such as a cold chain or continuous-flow
manufacturing. In cold chain applications, IoT system requires both RFID and temperature sensors, where
the RFID data represents the discrete event model, and the temperature sensor data denotes a continuous
model of environmental monitoring activities. We will investigate these issues in the future. Another
challenge facing IoT system developers is the lack of development tools supporting the modeling and design
processes. A better IoT process design and system modeling tool is also being considered as part of our
future work to extend this study. Finally, the object event modeling approach and the implementation
architecture proposed in this paper can be easily extended to many novel application of IoT, including the
blockchain technologies. We will explore these new research directions in our future work.
References
Bandyopadhyay, D. and Sen, J. (2011), “Internet of things: Applications and challenges in technology and
standardization”, Wireless Personal Communications, Vol. 58 No 1, pp. 49-69.
Barjis, J. (2009), “Collaborative, participative and interactive enterprise modeling”, Enterprise information
systems, pp.651-662.
Bartolomei, J., Silbey, S., Hastings, D., De Neufville, R. and Rhodes, H. (2009), “Bridging the Unspannable
Chasm: Qualitative Knowledge Construction for Engineering Systems”, Second International
Symposium on Engineering Systems, Citeseer pp. 15-17.
Bi, Z., Da Xu, L., & Wang, C. (2014), “Internet of things for enterprise systems of modern
manufacturing”,. IEEE Transactions on industrial informatics, Vol.10 No 2, pp.1537-1546.
Bo, Y. and Guangwen, H. (2009), “Supply chain information transmission based on RFID and internet of
things”, Computing, Communication, Control, and Management, 2009. CCCM 2009. ISECS
International Colloquium on pp. 166-169.
Bouraga, S., Jureta, I., and Faulkner, S. (2016), “Modelling Requirements for Content Recommendation
Systems”, arXiv:1606.05746.
Broy, M. (2001), “Toward a mathematical foundation of software engineering methods”, IEEE Transactions
on Software Engineering, Vol. 27 No 1, pp. 42-57.
Cassou, D., Bruneau, J., Consel, C. and Balland, E. (2012), “Toward a tool-based development methodology
for pervasive computing applications”, IEEE Transactions on Software Engineering, Vol. 38 No 6, pp.
1445-1463.
Chen, K.-Y. (2012), “Cell controller design for RFID based flexible manufacturing systems”, International
Journal of Computer Integrated Manufacturing, Vol. 25 No 1, pp. 35-50.
Chow, H. K., Choy, K., Lee, W. and Wang, T. (2007), “A RFID based knowledge management systems-an
32
intelligent approach for managing logistics processes”, 2007 5th IEEE International Conference on
Industrial Informatics, IEEE pp. 287-292.
Chow, H. K., Choy, K. L. and Lee, W. (2007), “A dynamic logistics process knowledge-based system–An
RFID multi-agent approach”, Knowledge-Based Systems, Vol. 20 No 4, pp. 357-372.
Cimino, M. G. and Marcelloni, F. (2011), “Autonomic tracing of production processes with mobile and
agent-based computing”, Information Sciences, Vol. 181 No 5, pp. 935-953.
Dar, K., Taherkordi, A., Baraki, H., Eliassen, F., and Geihs, K. (2015), “A resource oriented integration
architecture for the internet of things: A business process perspective”, Pervasive and Mobile
Computing, Vol. 20, pp.145-159.
Datta, S. P. A. (2008), “Auto ID paradigm shifts from internet of things to unique identification of individual
decisions in system of systems”.
De, S., Elsaleh, T., Barnaghi, P. and Meissner, S. (2012), “An internet of things platform for real-world and
digital objects”, Scalable Computing: Practice and Experience, Vol. 13 No 1, pp. 45-58.
De Souza, L. M. S., Spiess, P., Guinard, D., Köhler, M., Karnouskos, S. and Savio, D. (2008). "Socrades: A
web service based shop floor integration infrastructure". The internet of things, Springer: 50-67.
Dickerson, C. E. and Mavris, D. (2013), “A brief history of models and model based systems engineering
and the case for relational orientation”, IEEE Systems Journal, Vol. 7 No 4, pp. 581-592.
Doerr, K. H., Gates, W. R. and Mutty, J. E. (2006), “A hybrid approach to the valuation of RFID/MEMS
technology applied to ordnance inventory”, International Journal of Production Economics, Vol. 103
No 2, pp. 726-741.
EPCglobal (2007), Pedigree Ratified Standard v1.0, EPCglobal Standards
EPCglobal (2010), The EPCglobal Architecture Framework v1.4, EPCglobal Standards
Ferreira, P., Martinho, R. and Domingos, D. (2010), “IoT-aware business processes for logistics: limitations
of current approaches”, Inforum pp. 612-613.
Fosso Wamba, S. (2012), “Achieving supply chain integration using RFID technology: the case of emerging
intelligent B-to-B e-commerce processes in a living laboratory”, Business Process Management
Journal, Vol. 18 No 1, pp. 58-81.
Gershenfeld, N., Krikorian, R. and Cohen, D. (2004), “The Internet of things”, Scientific American, Vol. 291
No 4, pp. 76.
Hackathorn, R. (2003), “Minimizing action distance”, DM REVIEW, Vol. 12 No pp. 22-23.
Haller A, Komazec S, van Lessen T (2008), Semantic business process management tutorial. In:
International Conference on Electronic Commerce (ICEC). Innsbruck, Austria, p 53.
Haller, S., Karnouskos, S. and Schroth, C. (2008), “The internet of things in an enterprise context”, Future
Internet Symposium, Springer pp. 14-28.
Hsu, P.-Y., Chang, Y.-B. and Chen, Y.-L. (2003), “STRPN: A Petri-Net approach for modeling
spatial-temporal relations between moving multimedia objects”, IEEE Transactions on Software
Engineering, Vol. 29 No 1, pp. 63-76.
Huang, J., Zhu, Y., Cheng, B., Lin, C., and Chen, J. (2016), “ A PetriNet-Based Approach for Supporting
Traceability in Cyber-Physical Manufacturing Systems”, Sensors, Vol 16 No 3, pp.382.
Jiang, Z., E, M., Liu, Y., Liu, J., and Li, Y. (2017), “ Study of manufacturing resource perception and process
control of a radio-frequency-identification-enabled decentralized flexible manufacturing
33
system”, Advances in Mechanical Engineering, Vol. 9 No 1, pp. 1-12.
Kürschner, C., Condea, C., Kasten, O. and Thiesse, F. (2008). "Discovery service design in the EPCglobal
network". The Internet of Things, Springer: 19-34.
Kelepouris, T., Pramatari, K. and Doukidis, G. (2007), “RFID-enabled traceability in the food supply chain”,
Industrial Management & Data Systems, Vol. 107 No 2, pp. 183-200.
Kortuem, G., Kawsar, F., Sundramoorthy, V. and Fitton, D. (2010), “Smart objects as building blocks for the
internet of things”, IEEE Internet Computing, Vol. 14 No 1, pp. 44-51.
Kulkarni, V. and Reddy, S. (2003), “Separation of concerns in model-driven development”, IEEE software,
Vol. 20 No 5, pp. 64.
Kwok, S. K., Ting, S. L., Tsang, A. H., Cheung, C. F. (2010). “A counterfeit network analyzer based on
RFID and EPC”, Industrial Management & Data Systems, 110(7), 1018-1037.
Lanese, I., Bedogni, L. and Di Felice, M. (2013), “Internet of things: a process calculus approach”,
Proceedings of the 28th Annual ACM Symposium on Applied Computing, ACM pp. 1339-1346.
Leitão, P., and Colombo, A. W. (2006), “Petri net based methodology for the development of collaborative
production systems”, 2006 IEEE International Conference on Emerging Technologies and Factory
Automation, IEEE pp. 819-826.
Liu, C.-M., Chen, L. and Romanowski, R. (2009), “An electronic material flow control system for
improving production efficiency in integrated-circuit assembly industry”, The International Journal of
Advanced Manufacturing Technology, Vol. 42 No 3-4, pp. 348-362.
Liu, X. and Sun, Y. (2011), “Information flow management of Vendor-Managed Inventory system in
automobile parts inbound logistics based on Internet of Things”, Journal of Software, Vol. 6 No 7, pp.
1374-1380.
Lv, Y., and Lin, D. (2017), “Design an intelligent real-time operation planning system in distributed
manufacturing network”, Industrial Management & Data Systems, Vol.117 No 4, pp. 742-753.
Lv, Y., Lee, C., Chan, H. and Ip, W. (2012), “RFID-based colored Petri net applied for quality monitoring in
manufacturing system”, The International Journal of Advanced Manufacturing Technology, Vol. 60
No 1-4, pp. 225-236.
Meyer, S., Ruppen, A. and Magerkurth, C. (2013), “Internet of things-aware process modeling: integrating
IoT devices as business process resources”, International Conference on Advanced Information
Systems Engineering, Springer pp. 84-98.
Murata, T. (1989), “Petri nets: Properties, analysis and applications”, Proceedings of the IEEE, Vol. 77 No 4,
pp. 541-580.
Ou-Yang, C. and Lin, Y. (2008), “BPMN-based business process model feasibility analysis: a petri net
approach”, International Journal of Production Research, Vol. 46 No 14, pp. 3763-3781.
Patel, P. and Cassou, D. (2015), “Enabling high-level application development for the Internet of Things”,
Journal of Systems and Software, Vol. 103 No pp. 62-84.
Petri CA (1966), Communication with automata. Doctoral Dissertation, University of Bonn, Germany.
Qiu, R. G. (2007), “RFID-enabled automation in support of factory integration”, Robotics and
Computer-Integrated Manufacturing, Vol. 23 No 6, pp. 677-683.
Qu, T., Lei, S., Wang, Z., Nie, D., Chen, X. and Huang, G. Q. (2016), “IoT-based real-time production
logistics synchronization system under smart cloud manufacturing”, The International Journal of
34
Advanced Manufacturing Technology, Vol. 84 No 1-4, pp. 147-164.
Quack, T., Bay, H. and Van Gool, L. (2008). "Object recognition for the internet of things". The Internet of
Things, Springer: 230-246.
Renganathan, K. and Bhaskar, V. (2010), “Observer based on-line fault diagnosis of continuous systems
modeled as Petri nets”, ISA transactions, Vol. 49 No 4, pp. 587-595.
Saadallah, N., Meling, H., and Daireaux, B. (2011), “Modeling a drilling control system, as a
Discrete-Event-System”, 2011 IEEE International Conference on Communications, Computing and
Control Applications, IEEE pp.1-5.
Spiess, P., Karnouskos, S., Guinard, D., Savio, D., Baecker, O., De Souza, L. M. S. and Trifa, V. (2009),
“SOA-based integration of the internet of things in enterprise services”, Web Services, 2009. ICWS
2009. IEEE International Conference on, IEEE pp. 968-975.
Thiesse, F., Floerkemeier, C., Harrison, M., Michahelles, F. and Roduner, C. (2009), “Technology, standards,
and real-world deployments of the EPC network”, Institute of Electrical and Electronics Engineers pp.
Tribowski, C., Goebel, C. and Günther, O. (2009), “RFID Context Data Management: The Missing Link to
EPCIS-Based Supply Chain Monitoring”, PACIS 2009 Proceedings, Vol. No pp. 2.

Tu, M., Jia-Hong, L., Ruey-Shun, C., Kai-Ying, C. and Jung-Sing, J. (2009), “Agent-Based Control
Framework for Mass Customization Manufacturing With UHF RFID Technology”, Systems Journal,
IEEE, Vol. 3 No 3, pp. 343-359.
Welbourne, E., Battle, L., Cole, G., Gould, K., Rector, K., Raymer, S., Balazinska, M. and Borriello, G.
(2009), “Building the Internet of Things Using RFID: The RFID Ecosystem Experience”, Internet
Computing, IEEE, Vol. 13 No 3, pp. 48-55.
Wu, Y. (2008), “Realizing the Internet of Things in Service-Centric Environments”, ICSOC PhD Symposium
pp.
Xu, H. and Shatz, S. M. (2003), “A framework for model-based design of agent-oriented software”, IEEE
Transactions on software engineering, Vol. 29 No 1, pp. 15-30.
Yan, B., Yan, C., Ke, C. and Tan, X. (2016), “Information sharing in supply chain of agricultural products
based on the Internet of Things”, Industrial Management & Data Systems, Vol. 116 No 7, pp.
1397-1416.
Zhou, M. and Venkatesh, K. (1999), Modeling, simulation, and control of flexible manufacturing systems: a
Petri net approach, World Scientific.
Zhou, S., Ling, W. and Peng, Z. (2007), “An RFID-based remote monitoring system for enterprise internal
production management”, The International Journal of Advanced Manufacturing Technology, Vol. 33
No 7-8, pp. 837-844.
35

Iot PLSS 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Iot PLSS 2

Uploaded by

Copyright:

Available Formats

Industrial Management & Data Systems

*Related content and download information correct at time of download.

system-Part 1: Modeling IoT-based manufacturing supply chain

Cyber-Physical System (CPS) framework and evaluates its performance.

Article Type: Research paper

Figure 1. EPCglobal Network architecture framework

2 IoT systems modeling framework

2.1 A multilayer hierarchical modeling framework

Figure 2. A five-dimensional view of an IoT-based PLSCS

2.2 Modeling methodology

Figure 3. IoT-based PLSCS modeling framework

2.3 Running example

3 Ontology modeling layer

Figure 4. IoT ontology-modeling process

Figure 5. IoT-aware ontology concept model (IoTCM) example (partial view)

4.1 Constructing a baseline IoT process model

Figure 6. IoT ontology and process management tool

Figure 8. Baseline IoT process model

4.2 Constructing the IoT-aware process model

Step 5 (Convert the baseline IoTPM to PN-based IoTPM):

Definition 2 (IoTPMN preset and postset)

Definition 3 (IoTPMN execution rules)

Definition 4 (IoTPMN input/output matrix)

Definition 5 (IoTPMN incidence matrix)

A = [ ] = D+ - D− = [ ] - [ ], (1)

Definition 6 (IoTPMN firing control vector)

Definition 7 (IoTPMN state transition equation)

Definition 8 (IoTPMN firing count vector)

Algorithm 1 (Acquire firing control vector from IoTPMN).

Step 1 Find the firing condition vector, , by multiplying D  and Mc.

Figure 9. Mathematical representation of an exemplary IoTPMN and the illustration of Algorithm 1

Step 6 (Model validation of the IoTPMN):

Algorithm 2 (IoTPM fault diagnosis and detection).

Step 7 (Create an IoT-aware process model):

Figure 14. The IoT-aware process model

5.1 IoT-aware object model

5.2 Constructing an IoTOM

Figure 15. An exemplary CPN-based IoTOM

Figure 16. An example of a contextually enriched EPCIS event

Table 1 Design of f2, f3, and f4

Table 3 Design of T3, s3, s4, and s5

6.1 Implementation architecture

6.2 Practical implications

EPCIS-Based Supply Chain Monitoring”, PACIS 2009 Proceedings, Vol. No pp. 2.

You might also like

A = [ ] = D+ - D− = [ ] - [ ], (1)

Step 1 Find the firing condition vector, , by multiplying D and Mc.