Knowledge Representation of Cyber-physical Systems for Monitoring Purpose

Full text

ScienceDirect
Available online at www.sciencedirect.com
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2017) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th C IRP Design Conference 2018.
28th CIRP Design Conference, May 2018, Nantes, France
A new methodology to analyze the functional and physical architecture of
existing products for an assembly oriented product family identification
Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat
École Nationale Supérieure d’Arts et Métiers, Arts et Métiers ParisTech, LCFC EA 4495, 4 Rue Augustin Fresnel, Metz 57078, France
* Corresponding author. Tel.: +33 3 87 37 54 30; E-mail address: paul.stief@ensam.eu
Abstract
In today’s business environment, the trend towards more product variety and customization is unbroken. Due to this development, the need of
agile and reconfigurable production systems emerged to cope with various products and product families. To design and optimize production
systems as well as to choose the optimal product matches, product analysis methods are needed. Indeed, most of the known methods aim to
analyze a product or one product family on the physical level. Different product families, however, may differ largely in terms of the number and
nature of components. This fact impedes an efficient comparison and choice of appropriate product family combinations for the production
system. A new methodology is proposed to analyze existing products in view of their functional and physical architecture. The aim is to cluster
these products in new assembly oriented product families for the optimization of existing assembly lines and the creation of future reconfigurable
assembly systems. Based on Datum Flow Chain, the physical structure of the products is analyzed. Functional subassemblies are identified, and
a functional analysis is performed. Moreover, a hybrid functional and physical architecture graph (HyFPAG) is the output which depicts the
similarity between product families by providing design support to both, production system planners and product designers. An illustrative
example of a nail-clipper is used to explain the proposed methodology. An industrial case study on two product families of steering columns of
thyssenkrupp Presta France is then carried out to give a first industrial evaluation of the proposed approach.
© 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
Keywords: Assembly; Design method; Family identification
1. Introduction
Due to the fast development in the domain of
communication and an ongoing trend of digitization and
digitalization, manufacturing enterprises are facing important
challenges in today’s market environments: a continuing
tendency towards reduction of product development times and
shortened product lifecycles. In addition, there is an increasing
demand of customization, being at the same time in a global
competition with competitors all over the world. This trend,
which is inducing the development from macro to micro
markets, results in diminished lot sizes due to augmenting
product varieties (high-volume to low-volume production) [1].
To cope with this augmenting variety as well as to be able to
identify possible optimization potentials in the existing
production system, it is important to have a precise knowledge
of the product range and characteristics manufactured and/or
assembled in this system. In this context, the main challenge in
modelling and analysis is now not only to cope with single
products, a limited product range or existing product families,
but also to be able to analyze and to compare products to define
new product families. It can be observed that classical existing
product families are regrouped in function of clients or features.
However, assembly oriented product families are hardly to find.
On the product family level, products differ mainly in two
main characteristics: (i) the number of components and (ii) the
type of components (e.g. mechanical, electrical, electronical).
Classical methodologies considering mainly single products
or solitary, already existing product families analyze the
product structure on a physical level (components level) which
causes difficulties regarding an efficient definition and
comparison of different product families. Addressing this
Procedia CIRP 72 (2018) 468–473
2212-8271 © 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
10.1016/j.procir.2018.03.018
Available online at www.sciencedirect.com
ScienceDirect
Procedia CIRP 00 (2018) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
Knowledge Representation of Cyber-physical Systems for Monitoring
Purpose
Didem Gürdüra*, Aneta Vulgarakis Feljanb, Jad El-khourya, Swarup Kumar Mohalikc,
Ramamurthy Badrinathc, Anusha Pradeep Mujumdarc, Elena Fersmanb
aDepartment of Machine Design, KTH Royal Institute of Technology, Stockholm 100 44, Sweden
bEricsson Research, Sweden
cEricsson Research, India
* Corresponding author. Tel.: +46 76 427 85 46. E-mail address: dgurdur@kth.se
Abstract
Automated warehouses, as a form of cyber-physical systems (CPSs), require several components to work collaboratively to address the common
business objectives of complex logistics systems. During the collaborative operations, a number of key performance indicators (KPI) can be
monitored to understand the proficiency of the warehouse and control the operations and decisions. It is possible to drive and monitor these KPIs
by looking at both the state of the warehouse components and the operations carried out by them. Therefore, it is necessary to represent this
knowledge in an explicit and formally-specified data model and provide automated methods to derive the KPIs from the representation. In this
paper, we implement a minimalistic data model for a subset of warehouse resources using linked data in order to monitor a few KPIs, namely
sustainability, safety and performance. The applicability of the approach and the data model is illustrated through a use case. We demonstrate
that it is possible to develop minimalistic data models through Open Services for Lifecycle Collaboration (OSLC) resource shapes which enables
compatibility with the declarative and procedural knowledge of automated warehouse agents specified in Planning Domain Definition Language
(PDDL).
© 2018 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 51st CIRP Conference on Manufacturing Systems.
Keywords:automated warehouse, knowledge representation; ontologies; cyber-physical systems; OSLC
1. Introduction
Automated warehouses are forms of CPSs [12]—that
include several components such as robotic arms, autonomous
robots, and automated storage and retrieval systems (AS/RSs).
All these agents require collaborative behavior for effective,
secure and efficient handling and distribution of goods—to
manage complex logistics operations [8]. Due to the increasing
usage of these robots and embedded systems in automated
warehouses, the need to provide the best possible collaboration
options between these systems is of growing importance.
Moreover, this rapid increase of CPS technologies underpin the
integrations of a myriad of physical components and processes
that are developed by external actors and requires coordination
[10]. One effective way to improve the efficiency of these
robots and embedded systems is to monitor different aspects of
the system by collecting and monitoring important data related
to several KPIs of the CPSs.
To monitor these KPIs and generate insights about them, a
knowledge representation of the system is needed —in other
words a knowledge model to represent the information about
the automated warehouse, its components and behavior.
Knowledge representation and reasoning (KR&R) is a field of
artificial intelligence that aims to build intelligent systems that
know about their world and are able to automatically draw
conclusions and act upon them, as humans do [1]. A
fundamental assumption in KR&R is that knowledge is
represented in a tangible form (usually via ontologies), suitable
for understanding relationships between entities. However,
ontologies alone are not enough to model the knowledge since
they aim to model relationships between different entities. A
well-defined data model, which specifies the entities, their
relationships, constraints on these entities and their data types
is therefore necessary, especially for monitoring purposes.
OASIS OSLC[17] is an emerging interoperability open
standard that adopts the architecture of the Internet and its
standard web technologies to integrate information from the
different tools without relying on a centralized integration
platform [4]. OSLC standard aims to solve the integration
needs between software tools. However, in our use case we
Author name / Procedia CIRP 00 (2018) 000–000 2
used the OSLC approach for integration between the
representation of automated warehouse components. This
enables coupling between components by defining the
minimum possible data for the purpose of interoperability.
The research for this paper has been undertaken following
three phases, as illustrated in Fig. 1. Firstly, semi-structured
interviews are used as a qualitative inquiry method. Secondly,
a case study is designed and conducted to identify relevant
ontologies and KPIs. Thirdly, metrics are extracted to define
the data model that is essential for monitoring these KPIs.
Later, this data model is implemented by OSLC standards and
then used to gather data to monitor necessary KPIs. This paper
aims to identify which data is necessary— with support of the
earlier research [8] — and to model the data required to monitor
KPIs in an automated warehouse.
To this end, Section II explains the methodology used
throughout the study. Section III describes the automated
warehouse use case where important KPIs and the necessary
data for each KPI is explained. Then Section IV introduces the
data model and details the implementation, Section V presents
the discussion, and the paper concludes with a summary of the
study in Section VI.
2. Research Methodology
This study has adopted the expert opinion technique [2] to
assist the problem definition. This technique aims to gather
opinions of experts to clarify the issues relevant to a particular
topic. To this end, several meetings have been conducted with
researchers at Ericsson who extensively work on the
architecture of the automated warehouse use case.
As a part of the expert opinion technique, semi-structured
interviews (SSIs) [3] were used as a qualitative inquiry method.
SSIs are designed to collect subjective responses from
interviewees regarding a particular situation or phenomenon
they have experienced. They can be used when there is
sufficient objective knowledge about an experience, but
subjective knowledge by itself is inadequate [13]. In this
research, the subjective knowledge of the experts plays a big
role in identifying how one can collect necessary data from the
different components of the automated warehouse. The
interview questions were used to collect responses of each
participant and constitute the structure of the SSI. These
questions aimed to understand the architecture of the system,
to identify the important constraints on the data for the
integration, and to extract the needs of the data model for the
purpose of monitoring.
In addition, an exploratory case study method [6] was used
to assist in the development of the data model identified by the
expert interviews. This method is especially useful to
investigate complex real-world issues. The exploratory case
studies are condensed case studies that can be used before
implementing a large-scale investigation or solution. Their
basic function is to help identify questions and select types of
measurements prior to the main investigation. The automated
warehouse use case includes different systems interacting with
each other and implementation of a data model, which is
capable of monitoring different KPIs, and requires a
preliminary study as a framework for the implementation.
Hence, the case study method is an ideal methodology for this
particular study, where a holistic investigation is needed [5,16].
3. Use Case
In this section, we describe the use case and a scenario
where several components of the warehouse work
autonomously to fulfill the inventory replenishment, storage
and delivery requests. These components of the CPSs can be
listed as: Automated Storage and Retrieval Systems (AS/RSs);
robotics arms; and autonomous robots. There are several
additional components such as cameras, conveyor belts and
humans that collaborate with the robots to accomplish tasks
related to the business objectives. Fig. 2 shows the overview of
this example warehouse.
In this use case, the warehouse’s components are modeled
as OSLC adapters. These adapters are integrated through linked
data and web services, and implemented by Lyo Adapter
Modelling Tool [4]. This tool models the resource types, their
properties and relationships, based on the Linked Data
constraint language of Resource Shapes [14]. Details of this
implementation are given in the next section. The knowledge
representation we are concerned with relates to the interactions
between these adapters. The adapters are expected to
communicate with a warehouse planner, which uses AI
planning techniques and constructs sequences of actions to
achieve specific goals. The warehouse planner itself is
designed as an OSLC adapter. These components and their
behaviors are listed below:
• AS/RSs: These systems are mounted to shelves. They
keep track of the inventory by saving the location and
quantity of the boxes. AS/RSs are responsible for bringing
the box(es) down where other robots can reach and
transport them within the warehouse to different locations.
Fig. 1. Methodology adopted for the study.
Fig. 2. Automated warehouse and its components.

Didem Gürdür et al. / Procedia CIRP 72 (2018) 468–473 469
Author name / Procedia CIRP 00 (2018) 000–000 2
used the OSLC approach for integration between the
representation of automated warehouse components. This
enables coupling between components by defining the
minimum possible data for the purpose of interoperability.
The research for this paper has been undertaken following
three phases, as illustrated in Fig. 1. Firstly, semi-structured
interviews are used as a qualitative inquiry method. Secondly,
a case study is designed and conducted to identify relevant
ontologies and KPIs. Thirdly, metrics are extracted to define
the data model that is essential for monitoring these KPIs.
Later, this data model is implemented by OSLC standards and
then used to gather data to monitor necessary KPIs. This paper
aims to identify which data is necessary— with support of the
earlier research [8] — and to model the data required to monitor
KPIs in an automated warehouse.
To this end, Section II explains the methodology used
throughout the study. Section III describes the automated
warehouse use case where important KPIs and the necessary
data for each KPI is explained. Then Section IV introduces the
data model and details the implementation, Section V presents
the discussion, and the paper concludes with a summary of the
study in Section VI.
2. Research Methodology
This study has adopted the expert opinion technique [2] to
assist the problem definition. This technique aims to gather
opinions of experts to clarify the issues relevant to a particular
topic. To this end, several meetings have been conducted with
researchers at Ericsson who extensively work on the
architecture of the automated warehouse use case.
As a part of the expert opinion technique, semi-structured
interviews (SSIs) [3] were used as a qualitative inquiry method.
SSIs are designed to collect subjective responses from
interviewees regarding a particular situation or phenomenon
they have experienced. They can be used when there is
sufficient objective knowledge about an experience, but
subjective knowledge by itself is inadequate [13]. In this
research, the subjective knowledge of the experts plays a big
role in identifying how one can collect necessary data from the
different components of the automated warehouse. The
interview questions were used to collect responses of each
participant and constitute the structure of the SSI. These
questions aimed to understand the architecture of the system,
to identify the important constraints on the data for the
integration, and to extract the needs of the data model for the
purpose of monitoring.
In addition, an exploratory case study method [6] was used
to assist in the development of the data model identified by the
expert interviews. This method is especially useful to
investigate complex real-world issues. The exploratory case
studies are condensed case studies that can be used before
implementing a large-scale investigation or solution. Their
basic function is to help identify questions and select types of
measurements prior to the main investigation. The automated
warehouse use case includes different systems interacting with
each other and implementation of a data model, which is
capable of monitoring different KPIs, and requires a
preliminary study as a framework for the implementation.
Hence, the case study method is an ideal methodology for this
particular study, where a holistic investigation is needed [5,16].
3. Use Case
In this section, we describe the use case and a scenario
where several components of the warehouse work
autonomously to fulfill the inventory replenishment, storage
and delivery requests. These components of the CPSs can be
listed as: Automated Storage and Retrieval Systems (AS/RSs);
robotics arms; and autonomous robots. There are several
additional components such as cameras, conveyor belts and
humans that collaborate with the robots to accomplish tasks
related to the business objectives. Fig. 2 shows the overview of
this example warehouse.
In this use case, the warehouse’s components are modeled
as OSLC adapters. These adapters are integrated through linked
data and web services, and implemented by Lyo Adapter
Modelling Tool [4]. This tool models the resource types, their
properties and relationships, based on the Linked Data
constraint language of Resource Shapes [14]. Details of this
implementation are given in the next section. The knowledge
representation we are concerned with relates to the interactions
between these adapters. The adapters are expected to
communicate with a warehouse planner, which uses AI
planning techniques and constructs sequences of actions to
achieve specific goals. The warehouse planner itself is
designed as an OSLC adapter. These components and their
behaviors are listed below:
• AS/RSs: These systems are mounted to shelves. They
keep track of the inventory by saving the location and
quantity of the boxes. AS/RSs are responsible for bringing
the box(es) down where other robots can reach and
transport them within the warehouse to different locations.
Fig. 1. Methodology adopted for the study.
Fig. 2. Automated warehouse and its components.

470 Didem Gürdür et al. / Procedia CIRP 72 (2018) 468–473
Author name / Procedia CIRP 00 (2018) 000–000 3
• Robotic arms: Robotic arms are mounted close to the
shelves. They move the boxes sent down from the higher
shelves by the AS/RSs, making them accessible to
autonomous robots.
• Autonomous robots: These robots carry the box(es) to the
conveyor belts and deposit them on predetermined way
points. Autonomous robots also have the ability to reach
the boxes from the ground level of the shelves.
• Warehouse planner: The planner receives information
submitted by the warehouse manager and derives a plan to
accomplish the specified goal —namely, the intended
destination of a set of boxes. The planner needs the current
(initial) state of the warehouse to derive the plan. The state
consists of the current positions of the boxes, robots,
robotic arms and the battery levels of the robots.
Furthermore, several KPIs such as performance, safety,
and sustainability are considered as important factors for
monitoring the automated warehouse components and their
interactions [8]. The warehouse planner receives a problem
including the initial state and the goal state of the warehouse
and generates a plan to reach this goal. The plan includes a list
of several actions which then gets distributed to the robots. The
actions in this level are called planned actions. During the
execution of the plan, some metrics (numerical values) are
calculated from the changes on the data impacting the
predicates, actions, functions and states. Robots update these
data after performing the actions (performed actions).
This use case aims to define a data model for monitoring
several KPIs from the sequence of data changes that the planner
constructs. Definition of the three most important KPIs and
related metrics are defined below. These metrics have been
identified in the preliminary study [8] for the purpose of aiding
several stakeholders to consider KPIs and essential metrics
while they are developing or using the CPSs. Fig. 3 details how
the data necessary is derived in a top-to-bottom manner: from
KPIs, to metrics and to specific data variables.
Performance is related to metrics such as time, number of
goals accomplished by a particular robot, or the overall time
and number of goals completed in the whole warehouse. The
time metric can be realized through a list of actions and the time
required to complete each action. Start time, end time and idle
time are therefore important values to collect.
Safety is related to the level of trust in the warehouse.
Collision is an example metric that is vital to monitor the safety
KPI. The collision metric can be calculated through the
position and waypoint data. The position of a robot and which
paths it will use are known information. Aggregating this
information for all robots and illustrating their behaviors
through this data is necessary. By this way, the safety status of
each robot can be monitored and the level of safety can be
decided according to the risk of collision.
Sustainability is mainly about the energy levels of the
warehouse in particular. The energy consumption for each
action that is happening in the CPSs needs to be collected. This
information can later be used to monitor the energy
consumption of different components as well as the warehouse
overall. Another important metric is the battery level.
Autonomous robots with critical battery levels should be sent
to the charging stations, and the fully charged robots flagged as
ready to be assigned new tasks.
This use case includes a scenario which is designed to
illustrate the work flow of the warehouse, interactions between
different components of the warehouse and aggregation of
knowledge to monitor KPIs through metrics. The scenario does
not intend to summarize all capabilities of the automated
warehouse but rather to capture the importance of knowledge
representation for monitoring purposes.
Scenario: In this scenario, the warehouse planner receives a
goal where it is requested to have a specific box, which has a
number 165498, on a specific conveyor belt which is called
ConveyorBelt5. The planner receives the current position of the
components and objects of the warehouse and from that
constructs and executes a plan which includes a set of actions.
The box is situated on Shelf2; ASRS2 is responsible for taking
the box from the shelf to the closest carriage, Carriage3, and
Turtlebot3 will carry it to ConveyorBelt5.
We can summarize the set of actions as:
• Action1: ASRS2 should locate, collect and bring
the box number 165498 from Level5 of Shelf2 to
Level1.
• Action2: RoboticArm2 should move the box from
ASRS2 to the TurtleBot3.
• Action3: TurtleBot3 should carry the box to
ConveyorBelt5 via WayPoint5 and deposit the box.
This goal requires TurtleBot3 to collaborate with
RoboticArm2 and ASRS2 to complete the request. For
monitoring purposes, the energy consumption of each action,
time spent for each action, and the waypoint activity is essential
data that needs to be collected. The next section introduces the
implementation details of the data model adopted in this use
case.
Fig. 3. Relationship between KPIs, metrics and data.
Author name / Procedia CIRP 00 (2018) 000–000 4
4. Implementation
Today, there is a broad selection of models —based on
different modeling techniques —that one can use to describe
knowledge about different domains. No matter which model
one chooses, in general, the knowledge about the domain can
be classified into declarative and procedural knowledge.
Declarative knowledge is used to model domain components
and their relationships. This provides an opportunity to perform
analysis or support decisions to answer specific questions about
the system structure, for example “what are the physical assets
in the automated warehouse, and how are they related?”.
Procedural knowledge, on the other hand, is used to model the
dynamic behavior of the components in the domain. Such
knowledge is often represented as a partial or complete finite-
state machine or computer program. It facilitates answering
questions related to the behavior of the system or its
components, such as “what is the (optimal) strategy for
reaching a given state?”.
This data model implementation is focused on representing
the declarative knowledge but it also enables the system to be
discerned through procedural knowledge using OSLC
Resource Shapes and Linked Data technologies. We have
adopted PDDL predicates and actions from the warehouse
planner domain and created resource shapes and their
properties accordingly. This allows the implementation to be
easily integrated with the rest of the automated warehouse
system. However, the linked data approach is not limited to
integration with PDDL —it would also allow different software
tools to be integrated through OSLC adapters via linked data
and web services.
4.1. Planning Domain Definition Language
PDDL [7] is an attempt by the domain independent planning
community to formulate a standard language. PDDL constantly
adds extensions to the base language to represent more
expressive problem domains. This study uses PDDL Version
2.1.
The PDDL input format consists of two files that specify the
domain and the problem. The domain file defines the type of
objects (type of things or concepts in the warehouse that
interest us e.g., robots and waypoints), predicates (properties
of objects that we are interested in, that can be true or false in
a given state, e.g. is-on or can-move), functions (fluents that
return a number e.g. chargeLevel) and the actions that agents
can perform that change the state of the system. Fig. 4
illustrates the PDDL action model for the pick action
performed by TurtleBot3.
At the same time, the problem file models the current state of
the system and the objects involved (available robots, layout of
the warehouse, battery level, etc.) and the goal state or mission
to be achieved. Fig. 5 represents a snippet of the problem
definition.
From these domain and problem files, an off-the-shelf
planner may be run to create a solution plan for a given
problem. In this case, the output of the planner will be a
sequence of actions that will transition the system from the
initial state to the goal state.
The IEEE Standard Ontologies for Robotics and Automation
[15] is used as a reference when these domain and problem files
are defined. The main reason for following this ontology is to
allow a clear dialog between all stakeholders involved in the
life-cycle of a robotic system, and to enable the integration and
efficient communication of heterogeneous robotic systems [9].
To this end, ontologies are useful in the earlier phase of an
evolving domain to facilitate the communication and
knowledge exchange among groups from different areas,
without really forcing them to align their research with the
particular view of a given group.
4.2. OSLC Standard and Resource Shapes
As we mentioned earlier, OASIS OSLC is an open standard
that uses specifications to allow different software tools to
integrate their data and workflows in support of end-to-end
lifecycle scenarios. OSLC does not standardize the behavior of
(:action pickupAtPlace
:parameters
(?robot - Robot ?object - Object ?position - Position
?waypoint - Waypoint)
:precondition
(and
(is-at ?robot ?waypoint)
(situated-at ?position ?waypoint)
(is-on ?object ?position)
)
:effect
(and
(not
(is-on ?object ?position)
)
(carrying ?robot ?object)
))
Fig. 4. A robot pick action modelled in PDDL
(define (problem warehouseProblem)
(:domain warehouseDomain)
(:objects turtlebot3 ASRS2 - Robot
shelf1 shelf2 shelf3 – Shelf
conveyorBelt4 conveyorBelt5 – conveyorBelt
wp2 wp3 wp5 – wayPoint
b165498 b124565 b210947- Box)
(:init
(on turtlebot3 wp3)
(situated-at shelf1 wp2)
(situated-at shelf2 wp2)
(situated-at conveyorBelt4 wp3)
(is-on b165498 shelf2)
(is-on b124565 shelf3)
(can-move wp2 wp3)
(can-move wp3 wp5)
(:goal
(forall (?x - Object)
(imply
(and (is-type ?x Box))
(and (is-on ?x shelf5))
)))
Fig. 5. An example problem file for the automated warehouse

Didem Gürdür et al. / Procedia CIRP 72 (2018) 468–473 471
Author name / Procedia CIRP 00 (2018) 000–000 4
4. Implementation
Today, there is a broad selection of models —based on
different modeling techniques —that one can use to describe
knowledge about different domains. No matter which model
one chooses, in general, the knowledge about the domain can
be classified into declarative and procedural knowledge.
Declarative knowledge is used to model domain components
and their relationships. This provides an opportunity to perform
analysis or support decisions to answer specific questions about
the system structure, for example “what are the physical assets
in the automated warehouse, and how are they related?”.
Procedural knowledge, on the other hand, is used to model the
dynamic behavior of the components in the domain. Such
knowledge is often represented as a partial or complete finite-
state machine or computer program. It facilitates answering
questions related to the behavior of the system or its
components, such as “what is the (optimal) strategy for
reaching a given state?”.
This data model implementation is focused on representing
the declarative knowledge but it also enables the system to be
discerned through procedural knowledge using OSLC
Resource Shapes and Linked Data technologies. We have
adopted PDDL predicates and actions from the warehouse
planner domain and created resource shapes and their
properties accordingly. This allows the implementation to be
easily integrated with the rest of the automated warehouse
system. However, the linked data approach is not limited to
integration with PDDL —it would also allow different software
tools to be integrated through OSLC adapters via linked data
and web services.
4.1. Planning Domain Definition Language
PDDL [7] is an attempt by the domain independent planning
community to formulate a standard language. PDDL constantly
adds extensions to the base language to represent more
expressive problem domains. This study uses PDDL Version
2.1.
The PDDL input format consists of two files that specify the
domain and the problem. The domain file defines the type of
objects (type of things or concepts in the warehouse that
interest us e.g., robots and waypoints), predicates (properties
of objects that we are interested in, that can be true or false in
a given state, e.g. is-on or can-move), functions (fluents that
return a number e.g. chargeLevel) and the actions that agents
can perform that change the state of the system. Fig. 4
illustrates the PDDL action model for the pick action
performed by TurtleBot3.
At the same time, the problem file models the current state of
the system and the objects involved (available robots, layout of
the warehouse, battery level, etc.) and the goal state or mission
to be achieved. Fig. 5 represents a snippet of the problem
definition.
From these domain and problem files, an off-the-shelf
planner may be run to create a solution plan for a given
problem. In this case, the output of the planner will be a
sequence of actions that will transition the system from the
initial state to the goal state.
The IEEE Standard Ontologies for Robotics and Automation
[15] is used as a reference when these domain and problem files
are defined. The main reason for following this ontology is to
allow a clear dialog between all stakeholders involved in the
life-cycle of a robotic system, and to enable the integration and
efficient communication of heterogeneous robotic systems [9].
To this end, ontologies are useful in the earlier phase of an
evolving domain to facilitate the communication and
knowledge exchange among groups from different areas,
without really forcing them to align their research with the
particular view of a given group.
4.2. OSLC Standard and Resource Shapes
As we mentioned earlier, OASIS OSLC is an open standard
that uses specifications to allow different software tools to
integrate their data and workflows in support of end-to-end
lifecycle scenarios. OSLC does not standardize the behavior of
(:action pickupAtPlace
:parameters
(?robot - Robot ?object - Object ?position - Position
?waypoint - Waypoint)
:precondition
(and
(is-at ?robot ?waypoint)
(situated-at ?position ?waypoint)
(is-on ?object ?position)
)
:effect
(and
(not
(is-on ?object ?position)
)
(carrying ?robot ?object)
))
Fig. 4. A robot pick action modelled in PDDL
(define (problem warehouseProblem)
(:domain warehouseDomain)
(:objects turtlebot3 ASRS2 - Robot
shelf1 shelf2 shelf3 – Shelf
conveyorBelt4 conveyorBelt5 – conveyorBelt
wp2 wp3 wp5 – wayPoint
b165498 b124565 b210947- Box)
(:init
(on turtlebot3 wp3)
(situated-at shelf1 wp2)
(situated-at shelf2 wp2)
(situated-at conveyorBelt4 wp3)
(is-on b165498 shelf2)
(is-on b124565 shelf3)
(can-move wp2 wp3)
(can-move wp3 wp5)
(:goal
(forall (?x - Object)
(imply
(and (is-type ?x Box))
(and (is-on ?x shelf5))
)))
Fig. 5. An example problem file for the automated warehouse

472 Didem Gürdür et al. / Procedia CIRP 72 (2018) 468–473
Author name / Procedia CIRP 00 (2018) 000–000 5
any tool yet it specifies the minimum possible common
artefacts to allow tools to work together in an interoperable
manner.
OSLC promotes linking data in a scalable, platform-
independent way using Internet as an architecture. This linking
capability is accomplished by using the Linked Data [11] to
represent specific information on tool artefacts such as RDF
[18] resources identified by HTTP (Unified Resource
Identifiers) URIs. Resource Shapes is the mechanism used to
define the constraints on RDF resources.
In this study, OSLC Resource Shapes are used to define the
data model which reflects the PDDL structure that the
warehouse planner is developed to consume. This data model
allows data aggregation from different components of the
warehouse, hence allowing data to be used for monitoring
purposes. To this end, several OSLC adapters—representing
components data in the form of an OSLC resource and allowing
other components to reach these resources—are generated in
addition to the data model.
As shown Fig. 6, the data model consists of 13 resource
shapes. These resources are linked with each other according
to the declarative relationship between them. This minimalistic
data model aims to define the necessary data for monitoring
KPIs, as discussed earlier.
According to the data model, a plan is a sequence of actions,
and one or more robot can perform each action. An action has
properties such as start time, end time, complete (to show if the
action is completed or not), and charge cost (in other words the
energy consumption of the particular action). These properties
would be updated after the execution of the plan and the action
realized as performed. A warehouse configuration is another
resource, which contains current information about entities
such as robots, way points, boxes, conveyor belts, charge
station and shelf. Every entity has a position and every robot
is situated at a way point. Furthermore, a robot can carry zero
or more boxes at any given time.
The proposed minimalistic data model includes “just
enough” data for monitoring KPIs. For instance, sustainability
can be assessed by categorizing different actions and their
charge cost or energy consumption. Likewise, the performance
of the system can be assessed through the duration of each task.
The change on safety level of a robot can be assessed for
different actions or plans. Moreover, one can easily list these
KPIs for each robot and calculate how many actions or plans
are completed by a particular robot, how much energy is
consumed during the day, how many times the robot has been
recharged, which actions are decreasing the safety level and so
on.
To illustrate the ability of the model, we can go through the
scenario that has been defined in t Section III. The plan lays out
Actions 1-3. Each action is carried out by robot(s) and the
activity information saved as a performed action. These actions
will be performed by robots, and information about the
performed actions will be saved as performed actions. ASRS2,
for example, is a type of robot which can carry a box from
Level 5 to Level 1. RoboticArm2 carries the box to TurtleBot3.
And TurtleBot3 uses WayPoint5 to ConveyorBelt5. As we
described before, all of the resources can be reached through
URIs. Through the Entity resource we can list the information
about physical entities of the warehouse such as shelves,
conveyor belts, robots, boxes and waypoints. The Warehouse
Configuration resource lists the current information about these
entities.
Fig. 6. An example specification diagram implemented by the Eclipse Lyo Adapter Modelling Tool [5].
Author name / Procedia CIRP 00 (2018) 000–000 6
5. Discussion
This study uses PDDL to show the logic behind the use case
and implements a minimalistic data model through resource
shapes. The use case is designed to show the applicability of a
linked data approach for knowledge representation in an
automated warehouse for the purpose of monitoring KPIs such
as sustainability, safety and performance.
The process of defining a data model to represent the
knowledge of the automated warehouse showed that it is
possible to use resource shapes to define the knowledge. The
data model not only defined the resources and their
relationships but also the types of resources. Moreover, the
exercise aided different stakeholders to better understand the
system.
During the implementation of the data model, team
members had the opportunity to talk about what kind of data is
required for what purpose, and different ideas were discussed
before taking any decisions. At the end of this iterative process,
a minimal set of required data was selected to be used only for
monitoring purposes. However, several additional resource
shapes and relationships were also identified to be used in
future studies.
The data model is requirement-driven. It intends to represent
the minimal knowledge necessary to monitor the selected KPIs.
Thus, it need not represent all the little details about the
automated warehouse and its components. For example, an
action has a property called completed. Here, one can easily
query and list all the actions that are planned but not completed
(or performed) yet. However, there is no mechanism which
shows why the action is not yet performed. And the data model
did not intend to give this kind of a reasoning about the actions.
6. Conclusion and Future Study
Cyber-physical systems, in general, require multiple
different components to work collaboratively. In this paper, we
present a methodology to identify the minimal set of data
resources necessary to derive and monitor a selected set of
KPIs.
Firstly, important KPIs are reviewed, metrics to analyze
these KPIs are defined and the data which is necessary to be
collected identified. Secondly, the data model is defined by
examining the declarative and procedural knowledge specified
in the PDDL problem and domain files. Lastly, the data model
is implemented through OSLC resource shapes.
This study shows that it is possible to have a minimalistic
data model which focuses on key performance indicators
through a well thought out process. The research is exemplified
through an automated warehouse use case, with the selected
sustainability, safety and performance KPIs.
The contribution of this work is to approach CPSs
complexity and interoperability related issues from a
minimalistic perspective and implementing a data model with
this perspective for monitoring several KPIs by linked data
approach.
The proposed data model is limited to the selected KPIs.
For instance, information security of the warehouse is an
important KPI that is not considered during this study but found
important for the future studies. A simple yet effective way of
defining the information security as a KPI can be the
assessment of traffic passing through different communication
nodes. Nodes that have unexpectedly high traffic or are
unresponsive (e.g. due to denial of service attack) can be
security risks.
Future studies will use this existing data model to build a
monitoring mechanism—an interactive dashboard—in
addition to identifying important KPIs such as information
security and extend the data model accordingly.
References
[1] Chitta Baral. 2003. Kowledge Representation , Reasoning and
Declerative Problem Solving. Cambridge University Press.
[2] Mark J. Clayton. 1997. Delphi: a technique to harness expert
opinion for critical decision-making tasks in education. Educational
Psychology 4, 17: 373–386.
[3] Eric Drever. 1995. Using Semi-Structured Interviews in Small-Scale
Research. A Teacher’s Guide. .
[4] Jad El-khoury, Didem Gurdur, and Mattias Nyberg. 2016. A
Model-Driven Engineering Approach to Software Tool
Interoperability based on Linked Data. 9, 3: 248–259.
[5] J. R. Feagin, A. M. Orum, and G. Sjoberg. 1991. A case for the
case study. Chapel Hill: University of North Carolina Press Books.
[6] Raya Fidel. 1984. The Case Study Method: A Case Study. Library
and Information Science Research 6, 3: 273–288.
[7] M. Ghallab, A. Howe, C. Knoblock, et al. 1998. PDDL—the
planning domain definition language. Yale.
[8] Didem Gürdür, Klaus Raizer, and Jad El-Khoury. 2018. Data
Visualization Support for Complex Logistics Operations and
Cyber-physical Systems. 13th International Joint Conference on
Computer Vision, Imaging and Computer Graphics Theory and
Applications, IEEE.
[9] Tamás Haidegger, Marcos Barreto, Paulo Gonçalves, et al. 2013.
Applied ontologies and standards for service robots. Robotics and
Autonomous Systems 61, 11: 1215–1223.
[10] Anne Håkansson, Ronald Hartung, and Esmiralda Moradian. 2015.
Reasoning strategies in smart cyber-physical systems. Procedia
Computer Science 60, 1: 1575–1584.
[11] Tom Heath, Christian Bizer, and Freie Universität Berlin. 2011.
Linked Data : Evolving the Web into a Global Data Space Linked
Data : Evolving the Web into a Global Data Space. .
[12] E.A. Lee and S.A. Seshia. 2016. Introduction to Embedded
Systems, A Cyber-Physical Systems Approach. MIT Press,
Cambridge.
[13] L. Richards and J. M. Morse. 2012. Readme first for a user’s guide
to qualitative methods. Sage.
[14] Arthur G Ryman and Steve Speicher. OSLC Resource Shape A
language for defining constraints on Linked Data. .
[15] C. Schlenoff, E. Prestes, P.S. Gonçalves, et al. 2015. IEEE
Standard Ontologies for Robotics and Automation IEEE Robotics
and Automation Society. .
[16] B. Shneiderman and C. Plaisant. 2006. Strategies for evaluating
information visualization tools: multi-dimensional in-depth long-
term case studies. AVI workshop on Beyond time and errors: novel
evaluation methods for information visualization, ACM, 1–7.
[17] OASIS OSLC. Retrieved November 8, 2017 from
http://www.oasis-oslc.org.
[18] RDF Primer. Retrieved November 7, 2017 from
https://www.w3.org/TR/rdf11-primer/.

Didem Gürdür et al. / Procedia CIRP 72 (2018) 468–473 473
Author name / Procedia CIRP 00 (2018) 000–000 6
5. Discussion
This study uses PDDL to show the logic behind the use case
and implements a minimalistic data model through resource
shapes. The use case is designed to show the applicability of a
linked data approach for knowledge representation in an
automated warehouse for the purpose of monitoring KPIs such
as sustainability, safety and performance.
The process of defining a data model to represent the
knowledge of the automated warehouse showed that it is
possible to use resource shapes to define the knowledge. The
data model not only defined the resources and their
relationships but also the types of resources. Moreover, the
exercise aided different stakeholders to better understand the
system.
During the implementation of the data model, team
members had the opportunity to talk about what kind of data is
required for what purpose, and different ideas were discussed
before taking any decisions. At the end of this iterative process,
a minimal set of required data was selected to be used only for
monitoring purposes. However, several additional resource
shapes and relationships were also identified to be used in
future studies.
The data model is requirement-driven. It intends to represent
the minimal knowledge necessary to monitor the selected KPIs.
Thus, it need not represent all the little details about the
automated warehouse and its components. For example, an
action has a property called completed. Here, one can easily
query and list all the actions that are planned but not completed
(or performed) yet. However, there is no mechanism which
shows why the action is not yet performed. And the data model
did not intend to give this kind of a reasoning about the actions.
6. Conclusion and Future Study
Cyber-physical systems, in general, require multiple
different components to work collaboratively. In this paper, we
present a methodology to identify the minimal set of data
resources necessary to derive and monitor a selected set of
KPIs.
Firstly, important KPIs are reviewed, metrics to analyze
these KPIs are defined and the data which is necessary to be
collected identified. Secondly, the data model is defined by
examining the declarative and procedural knowledge specified
in the PDDL problem and domain files. Lastly, the data model
is implemented through OSLC resource shapes.
This study shows that it is possible to have a minimalistic
data model which focuses on key performance indicators
through a well thought out process. The research is exemplified
through an automated warehouse use case, with the selected
sustainability, safety and performance KPIs.
The contribution of this work is to approach CPSs
complexity and interoperability related issues from a
minimalistic perspective and implementing a data model with
this perspective for monitoring several KPIs by linked data
approach.
The proposed data model is limited to the selected KPIs.
For instance, information security of the warehouse is an
important KPI that is not considered during this study but found
important for the future studies. A simple yet effective way of
defining the information security as a KPI can be the
assessment of traffic passing through different communication
nodes. Nodes that have unexpectedly high traffic or are
unresponsive (e.g. due to denial of service attack) can be
security risks.
Future studies will use this existing data model to build a
monitoring mechanism—an interactive dashboard—in
addition to identifying important KPIs such as information
security and extend the data model accordingly.
References
[1] Chitta Baral. 2003. Kowledge Representation , Reasoning and
Declerative Problem Solving. Cambridge University Press.
[2] Mark J. Clayton. 1997. Delphi: a technique to harness expert
opinion for critical decision-making tasks in education. Educational
Psychology 4, 17: 373–386.
[3] Eric Drever. 1995. Using Semi-Structured Interviews in Small-Scale
Research. A Teacher’s Guide. .
[4] Jad El-khoury, Didem Gurdur, and Mattias Nyberg. 2016. A
Model-Driven Engineering Approach to Software Tool
Interoperability based on Linked Data. 9, 3: 248–259.
[5] J. R. Feagin, A. M. Orum, and G. Sjoberg. 1991. A case for the
case study. Chapel Hill: University of North Carolina Press Books.
[6] Raya Fidel. 1984. The Case Study Method: A Case Study. Library
and Information Science Research 6, 3: 273–288.
[7] M. Ghallab, A. Howe, C. Knoblock, et al. 1998. PDDL—the
planning domain definition language. Yale.
[8] Didem Gürdür, Klaus Raizer, and Jad El-Khoury. 2018. Data
Visualization Support for Complex Logistics Operations and
Cyber-physical Systems. 13th International Joint Conference on
Computer Vision, Imaging and Computer Graphics Theory and
Applications, IEEE.
[9] Tamás Haidegger, Marcos Barreto, Paulo Gonçalves, et al. 2013.
Applied ontologies and standards for service robots. Robotics and
Autonomous Systems 61, 11: 1215–1223.
[10] Anne Håkansson, Ronald Hartung, and Esmiralda Moradian. 2015.
Reasoning strategies in smart cyber-physical systems. Procedia
Computer Science 60, 1: 1575–1584.
[11] Tom Heath, Christian Bizer, and Freie Universität Berlin. 2011.
Linked Data : Evolving the Web into a Global Data Space Linked
Data : Evolving the Web into a Global Data Space. .
[12] E.A. Lee and S.A. Seshia. 2016. Introduction to Embedded
Systems, A Cyber-Physical Systems Approach. MIT Press,
Cambridge.
[13] L. Richards and J. M. Morse. 2012. Readme first for a user’s guide
to qualitative methods. Sage.
[14] Arthur G Ryman and Steve Speicher. OSLC Resource Shape A
language for defining constraints on Linked Data. .
[15] C. Schlenoff, E. Prestes, P.S. Gonçalves, et al. 2015. IEEE
Standard Ontologies for Robotics and Automation IEEE Robotics
and Automation Society. .
[16] B. Shneiderman and C. Plaisant. 2006. Strategies for evaluating
information visualization tools: multi-dimensional in-depth long-
term case studies. AVI workshop on Beyond time and errors: novel
evaluation methods for information visualization, ACM, 1–7.
[17] OASIS OSLC. Retrieved November 8, 2017 from
http://www.oasis-oslc.org.
[18] RDF Primer. Retrieved November 7, 2017 from
https://www.w3.org/TR/rdf11-primer/.