=Paper=
{{Paper
|id=Vol-2739/paper_7
|storemode=property
|title=A Cross-Platform Communication Mechanism for ROS-Based Cyber-Physical System
|pdfUrl=https://ceur-ws.org/Vol-2739/paper_7.pdf
|volume=Vol-2739
|authors=Rui Zhao,Xu Tao,Davide Conzon,Enrico Ferrera,Yenchia Yu
|dblpUrl=https://dblp.org/rec/conf/sam-iot/ZhaoTCFY20
}}
==A Cross-Platform Communication Mechanism for ROS-Based Cyber-Physical System==
https://ceur-ws.org/Vol-2739/paper_7.pdf
A Cross-Platform Communication Mechanism
for ROS-Based Cyber-Physical System
Rui Zhao, Xu Tao, Davide Conzon, Enrico Ferrera Yenchia Yu
LINKS Foundation Tongji University
via Pier Carlo Boggio 61, 4800 Cao’an Road,
Turin, Shanghai,
Italy China
name.surname@linksfoundation.com yuyenchia@tongji.edu.cn
Abstract—Recently, one of the main research topics in the as physical and engineered systems whose operations are mon-
context of application of Cyber-Physical System (CPS) in the itored, coordinated, controlled and integrated by a computing
Smart City and Industry 4.0 scenarios is the one related to the and communication core. To realize such an intelligent system,
use of Robot Operating System (ROS)-based CPS. Specifically,
one of the main interest is to allow a ROS-based smart robot various technologies need to be involved, including sensor and
communicating with other heterogeneous Internet of Things (IoT) actuator technology etc. Together with IoT, Cloud computing
applications in an intelligent environment to efficiently react to and Cognitive computing, they become the main technologies
the system requirements and environment changes. However, of Industry 4.0 [1]. Specially, CPS and IoT are often discussed
the communication between the IoT systems will face many together, not only because they have many similarities but also
challenges and increase the cost and risks that lead to the
requirement of a cross-platform communication for bridging the because they are the foundations of the intelligent production
ROS-based CPS and other heterogeneous IoT applications. environment, in another word, the smart factories, which is
This paper introduces ROS Edge Node for the interoperability one of the most important topics of Industry 4.0.
between Robotics domain and other IoT domains, leveraging The communication is an important research topic for both
the highly modular BRAIN-IoT federation, which allows to de- of CPS and IoT. As more and more different devices will
centralize, compose and dynamically federate the heterogeneous
IoT platforms using OSGi specification, thanks to its dynamic be integrated in an intelligent production environment, the
modularity and wide usage in IoT middlewares. Together with requirement of communication between different CPSs or
the flexible integration with existing IoT devices/platforms within between CPS and IoT devices are becoming more and more
BRAIN-IoT platform, the event-driven asynchronous communi- significant. For example, in a smart factory, different CPSs
cation mechanism realizes cross-platform interaction with ROS- such as Autonomous Mobile Robots (AMR) [2] need to
based CPS and solves the major challenges faced. This commu-
nication mechanism allows dynamic deployment of new function- communicate with each other for cooperation, or an AMR
alities for enhancing/extending the behaviour of robots according needs to communicate with IoT devices such as automatic
to external events. In addition, some specific behaviours to new doors when it needs to cross different zones in the factory.
”virgin” robots, which might be needed to extend the fleet of However, such communication is not that easy to realize since
robots or replace damaged/low batteries ones can be dynamically heterogeneity is a basic property for both CPS and IoT devices.
deployed at the setup phase. In BRAIN-IoT platform, Edge
Node behaves as IoT devices/platform adaptors which integrate On the one hand, heterogeneity exists because different
the existing IoT devices/platforms. The ROS Edge Node is one CPS and IoT devices use different technologies in hardware,
type of the Edge Node, which bridges the underlying ROS- software, or communication method due to different needs. On
based robotics systems and BRAIN-IoT execution environment, the other hand, it is because the manufacturers of the devices
thus communicates with various IoT systems connected to the are different. Different manufacturers will design the device
BRAIN-IoT platform. A Service Robotic use case is developed to
demonstrate the proposed solution, it shows how the ROS Edge according to their own standards. Devices from different man-
Node enables the fast adaptivity and interoperability between ufacturers, even if they are using the same technologies, their
heterogeneous IoT domains in a federated environment. protocol will be different. According to the latest statistics [3],
Index Terms—Brain-IoT, Cyber-Physical System (CPS), Ser- there are officially 620 IoT platform companies in the global
vice Robotics, IoT Middleware, Cross-platform Communication, open market in 2019, in which 50% of the platforms focus
OSGi
on industrial use. From the perspective of communication,
devices from these companies could use hundreds of different
I. I NTRODUCTION
communication protocols which makes the standardization of
Nowadays, CPS are widely used in various aspects in our communication protocol extremely difficult. In the recent years
society, including but not limiting in areas such as manufac- of research, the idea of using middleware to realize cross-
turing, energy, health, transportation and intelligent buildings, platform communication is proposed.
causing significant socio-economic impacts. CPS are defined This paper presents a novel adaptor, ROS Edge Node, which
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
46
implements an event-driven asynchronous cross-platform com- communication mechanism for ROS-based CPS and the future
munication mechanism for ROS-based CPS. The work is a work being undertaken.
part of the H2020 research project BRAIN-IoT [4] that is a
federation enabling the dynamic deployment, orchestration and II. BACKGROUND
monitoring of the distributed IoT applications leveraging the A. State of the Art
OSGi [5] technology, since OSGi is a series of specifications One of the most popular example of CPSs is represented
for Java dynamic modular system, it provides the dynamicity by smart industrial robots. This sector is really fragmented,
for the life cycle management of software components. One in terms of hardware and software architectures, But in re-
of the main functions is to make components as decoupled cent years, more and more robots have begun adopting one
as possible, and to allow components to dynamically discover common technology, the middleware ROS. According to the
with each other, so that programmers can develop refinable, annual ROS Metrics Report for 2019 [10], there are near
reusable, and assistive components in accordance with these 150 types of documented robots available to the community
specifications. Nowadays, OSGi is the widest used technology with ROS drivers, and in recent years, the total number of
to support implementations of IoT abstraction layers. For papers citing “ROS: an opensource Robot Operating System”
example, Bosch ProSyst and Eurotech are two examples (Quigley et al.,2009) increase at an annual rate of 20% to 30%.
of companies providing OSGi-based IoT gateways; Oracle® More and more famous robot vendors such as Asea Brown
Fusion Middleware [6] is developed for developing Java Boveri (ABB) Ltd., Comau Spa. and Kuka AG are starting to
Enterprise Edition (EE) management applications for Oracle support ROS in some models of their robots. ROS is the widest
WebLogic Server; SNPS [7] is an OSGi-based middleware used abstraction layer for robotics. However, even the robots
for Wireless Sensor Networks; The OSGi-based software are using ROS middleware, the problems in communication
platform Eclipse SensiNact [8] provides support in technical still exists. ROS-based CPS are often used to communicate
aspects (e.g. Connectivity, Interoperability, Data processing, with other heterogeneous IoT applications to satisfy system
and Developer Tool) related to smart city platforms. BRAIN- requirements and react physical environment changes. There
IoT platform is implemented with OSGi and it aims integrating are two existing middlewares for interacting with ROS-based
with generic existing IoT devices or IoT platforms or existing CPS.
IoT middlewares to allow them communicating with each The ROS–YARP Framework for Middleware Interop-
other. ROS Edge Node is one implementation of the BRAIN- erability [11]: ROS and Yet Another Robot Platform (YARP)
IoT Edge Node mainly focused on the integration of robotics [12] are the most popular robotics middlewares. YARP is
platforms in IoT domain allowing to interoperate with other more used in the domain of humanoid robots and develop-
heterogeneous IoT devices by mapping the ROS services mental robotics, whereas ROS has higher focus on mobile
to OSGi services, to maximize the connectivity of robots robots. They have complementary functions and many robotic
within IoT systems. ROS Edge Node is a modular software platforms may benefit from using functions from both. But
component of the BRAIN-Io platform. It provides four main it’s not an easy task mainly due to fundamental differences
features: 1) Interoperability: it provides the connectivity to IoT in the communication architecture. This approach generates
platforms connected to BRAIN-IoT solution. 2) Plug & Play: the “bridging gap” code from a configuration file, connecting
leveraging the OSGi specification, the component follows YARP ports and ROS topics through code-generated YARP
an event-driven approach and it is developed as a software bottles. It supports YARP/ROS and viceversa sender/receiver
module that can be deployed/undeployed at runtime without configurations. Reading from/sending to ROS topics needs an
interrupting other running services. 3) Automatic Adaptation, additional conversion, which is handled by the existing run-
it provides a code generator to automatically expose the ad- time YARP to ROS converter. The generator abstracts YARP
hoc ROS services provided by different ROS-based CPSs and and ROS developers from dealing directly with interoperability
speeds up the adaptor development process. 4) Standards Com- issues. However, this work is only focusing the interoperability
pliant, it exploits the Web of Things (WoT) Thing Description among robotics middlewares.
(TD) [9] describing the services provided by the ROS-based ROBIN Middleware for CPS [13]: ROBIN is a mid-
CPS, making it more portable to the production environment, dleware funded by European H2020 program providing an
not restrict to the OSGi implementation. effective, bidirectional, reliable and structured data interchange
The rest of this paper is organized as follows. Section II mechanism to address the demand for flexible robotics in
introduces the state of the art of the solutions similar to the one contemporary industrial environments and the necessity to
proposed in this paper in multiple domains and the challenges integrate robots and automation equipment in an efficient
to be addressed typically by these software. It also outlines the manner. ROBIN, the robotics bridge to industrial automation,
relevant technologies used to develop the proposed solution. aims to allow the interoperability between robotics and au-
Section III describes the architecture of the ROS Edge Node, tomation systems by enabling the communication between
functionalities and development process. Section IV imple- ROS and CODESYS [14], which is a softPLC1 , a real-time
ments a simple robotic application to validate the solution in multi-task control kernel, that can run on embedded devices
a distributed environment. Finally, the paper concludes with
the Section V to provide a summary of the cross-platform 1 http://www.softplc.com/
47
and that supports a variety of fieldbuses, and other industrial stop atomic behaviours at runtime, deploy new ones, import,
network protocols. CODESYS handles the establishment of update and upgrade behaviours at runtime every time a new
external communication with the equipment via a fieldbus more stable or more secure version is available).
and communicates with ROS through the developed robotics
bridge. More specifically, since ROS implementation follows C. Challenges
the publisher–subscriber messaging pattern, which enables ROS Edge Node intends to address the gaps mentioned in
exchanging data between ROS nodes [15], A ROS node is the previous section in the current State of The Art (SoTA)
basically a process that performs computation and it is an exe- and the typical challenges faced in researches on middleware
cutable program running inside the robotics application. Many for CPS [16], [17]. More specifically, apart from supporting
nodes can be implemented in ROS packages. The proposed the interoperability between the ROS-based CPS and other
bridging mechanism allows developers to create or include heterogeneous IoT applications, it also supports adaptivity,
in existing ROS packages the valuable feature of connecting security and privacy protection and autonomous operation, as
with an external device via fieldbuses or industrial network explained in the following subsections.
protocols promoted by the softPLC bridge. Multiple ROS Abstraction and Automatic Adaptation: [18] An ideal
nodes can access and modify the data shared with the softPLC middleware for an intelligent environment such as the IoT
application in ROS. The information to be propagated to the should provide abstractions at various levels such as hetero-
external devices could be published on a ROS topic, handled geneous input and output hardware devices, hardware and
by the developed bridge, and then relayed by CODESYS to software interfaces, data streams, physicality and the de-
the proper industrial network protocol or fieldbus. velopment process. And an Adaptive middleware is usually
motivated by the need of adapting the middleware to changes
B. Problems with State of the Art in application’s requirements, changes of environmental con-
ROS allows the communication between heterogeneous ditions, fixing middleware’s bugs or extending/improving the
devices, being deployable on heterogeneous platforms. After middleware functionality. ROS Edge Node solution proposes
ROS is deployed on the device, it can use ROS as communi- an approach to create a software component to abstract the
cation method to communicate. However, it can only support ROS-based CPS for communicating with other OSGi-based
communication between devices developed based on ROS, IoT middlewares/applications through the distributed BRAIN-
it cannot be used to communicate with off-the-shell devices IoT EventBus. The adaptor can be generated according to
using different technologies. Furthermore, the messages used different ROS platform implementations. For the simplicity,
in ROS are the original data sent by the device, which has a code generator is provided to speed up the development
not been standardized. The receiver must know the content process.
of the communication in advance, otherwise it will not be Security and Privacy: Automatic communication of real-
able to understand the received data. In State Of The Art life objects represents a huge challenge in terms of trust,
(SOTA), one of the limitations of ROS–YARP middleware is security and privacy. The security and privacy component is
the applicability area, which is limited to ROS and YARP needed to provide the integrity of the collected data (stream)
only, while CPSs are widely used in various aspects. The and to ensure that the user’s privacy is not violated. The
robotic bridge provided by ROBIN project allows the com- data can only be able to connect to authenticated/certified
munication between ROS and the automation application IoT devices. The management support of security and privacy
through the inter-node communication mechanism in ROS, has to be considered as a main function of the middle-
but it requires the developers to directly create or include in ware for the IoT. The ROS Edge Node adaptor will be
existing ROS packages the valuable features for interacting integrated with the BRAIN-IoT platform, which introduces
with other external devices via fieldbuses or industrial network a holistic end-to-end trust framework and privacy-awareness
protocols. This requires to the developers to be expert in and control approach to address the challenge [4]. Currently,
ROS programming. Besides, the direct operation on existing the integration between ROS Edge Node and the end-to-end
ROS packages may bring the risk of the damaging the basic framework guarantees only authenticated ROS-based CPSs can
functionalities. Moreover, in the real production environment, integrate with BRAIN-IoT platform and communicate with
the robotics applications are significantly sophisticated and other authenticated IoT systems.
dynamic, requiring to the bridge to be flexible enough to react Autonomous Operation: Many CPS applications are con-
to the continuously changing production environment; to allow sidered complex systems which can be in a huge number of
this the robotic bridge needs to support the update at runtime different states at any point of time. It is generally extremely
and the deployment on demand and this feature is not feasible difficult to develop code to handle all these states effectively
using only native ROS. and in a timely manner. Having middleware that supports
Instead, ROS Edge Node bridges ROS and other IoT autonomous operations such as self-adaptive, self-resilient, and
platforms using OSGi specification, in such way, the robot’s self-protected services can relax implementing and operating
behaviours can be developed at the application level using these complex CPS applications. The ROS Edge Node ad-
OSGi instead of ROS. And this allows to have all the advanced dresses this challenge supporting the development of complex
OSGi capabilities applied in robotics scenario(i.e., start and IoT solutions for monitoring and controlling physical environ-
48
ments and systems. Specifically, it simplifies the operation of of values are sent asynchronously to the receiver. TD can be
application providing a an event-driven notification method, used for flexible implementation and simulation (if required).
which allow avoiding to use polling methods to query the WoT will break the barrier of interoperability of various IoT
robot or mission status, reducing greatly the network traffics. platforms, thereby contributing to the explosive growth of the
market. It doesn’t aim to define a new platform, but to use the
D. Relevant Technologies
metadata to bridge existing platforms and standards.
RosJava Open Source Library2 : RosJava project provides In this paper, these technologies will be used in the follow-
a pure Java implementation of ROS, and it also can inter- ing aspects. The ROS Edge Node, will be developed as OSGi
connect to an existing ROS environment through the Internet bundles, which can be remotely installed, started, stopped,
Protocol (IP) address. It provides a client library for ROS updated, and uninstalled without requiring a reboot in BRAIN-
communications in java that allows Java programmers to IoT federation.
quickly interface with ROS topics, services and parameters RosJava can be considered as the bridge between ROS world
through the eXtensible Markup Language (XML)-Remote and Java world. It provides an efficient way for the ROS Edge
Procedure Call (RPC) [19] protocol. It provides some common Node to establish a communication with ROS-based devices.
Java API allowing to create new ROS nodes, services, topics in Different ROS functionalities will be mapped into different
native ROS environment, and the corresponding ROS clients. OSGi services in the ROS Edge Node. The mapping procedure
The library can be fully integrated in OSGi software. will be done automatically through JCodeModel library with
JCodeModel Open Source Library3 : JCodeModel is a a TD of the underlying ROS environment. Anyway, the
Java code generation library. It provides common API to corresponding formatting procedure of events and integration
generate Java programs using Java language. with BRAIN-IoT framework should be done by developers.
World Wide Web Consortium (W3C) and WoT: In recent
years, W3C organization has developed the WoT [9] standard III. A RCHITECTURE
aiming to achieve interoperability problem between IoT plat- This section details the ROS Edge Node architecture along
forms and application domains. WoT provides a mechanism with its role in the overall BRAIN-IoT platform.
for describing IoT interfaces, allowing IoT devices (physical
or virtual entity) and services to communicate with each other, A. Overview in BRAIN-IoT Context
independent of their underlying implementation, and can span ROS Edge Node will be integrated with BRAIN-IoT Fabric
multiple network protocols. In addition, WoT also provides [20] infrastructure service, which is composed with a set
a standardized way to define and plan IoT behaviors. WoT of the computing resources (physical/virtual machines) and
Architecture specification is centered on the scope of W3C provides a distributed OSGi execution environment allowing
WoT standardization, divided into several building blocks. the interaction between the OSGi services deployed on it
The four core building blocks provided by W3C WoT are: through events, thanks to the implementation of OSGi Alliance
Thing Description, Binding Template, Scripting Application specifications for Remote Services and Remote Service Admin
Programming Interface (API), Security and Privacy Guide- [5]. Each BRAIN-IoT Fibre is an OSGi R7 framework, and
lines. More specifically, The central building block is the different Brain-IoT OSGi bundles deployed on local and
WoT TD4 , which can describe the metadata of the object remote Fibres can communicate with each other using some
and the network-oriented interfaces and it’s the entry point specific strongly typed BRAIN-IoT events delivered in the
of a Thing. TDs are encoded in a JavaScript Object Notation asynchronous BRAIN-IoT EventBus [20] according to the
(JSON) format that also allows JSON-based Serialization for BRAIN-IoT approach. The BRAIN-IoT Nodes are the Service
Linked Data (JSON-LD) processing, primarily intended to Fabric Fibres with different BRAIN-IoT Services deployed
be a way to use Linked Data in Web-based programming on them, they can be of two types: BRAIN-IoT Processing
environments. The building blocks allow an application client Nodes and BRAIN-IoT Edge Nodes. The first ones are a
(a Consumer) to interact with Things that expose diverse sort of Service Fabric Fibres deploying IoT application logic
protocols through the three types of Interaction Affordances and controlling the CPS behaviours through their adaptors
defined by W3C WoT Interaction Model representing the capa- supported by the machine learning algorithms. The latter ones
bilities of individual Things: i) Properties (PropertyAffordance are Fabric Fibres with the installed edge components deployed
class) can be used for sensing and controlling parameters, on the top of them. BRAIN-IoT Fabric allows users to label
such as getting the current value or setting an operation the BRAIN-IoT nodes, thus to guide where the BRAIN-IoT
state; ii) Actions (ActionAffordance class) model invocation of service, satifying the required capabilities, should be deployed
physical (and hence time-consuming) processes, but can also at runtime. The BRAIN-IoT architecture allows the dynamic
be used to abstract RPC-like calls of existing platforms. iii) redeployment of 1) new functionalities for enhancing/extend-
Events (EventAffordance class) are used for the push model of ing the behaviour of robots according to external events. 2)
communication where notifications, discrete events, or streams specific behaviours to new ”virgin” robots, which might be
2 https://github.com/rosjava needed to extend the fleet of robots or replace demaged/low
3 https://github.com/phax/jcodemodel batteries ones. Each ROS Edge node can be considered as
4 https://w3c.github.io/wot-thing-description/ an access point or an adaptor to ROS-based CPS, to allow
49
objects representing ROS messages, then transforms to ROS
environment through the exposed OSGi services. In contrast,
the adaptor also retrieves the ROS messages from the native
services/topics and convert to the BRAIN-IoT events, then de-
liver them in the distributed EventBus. The connectivity with
ROS is configurable through the ROS environment variable
ROS MASTER URI by default whose value is configurable
on-the-fly in order to set up which machine as a ROS master
when a new ”virgin” robot join the fleet of robots.
B. ROS Edge Node Approach
The ROS Edge Node adaptor is further explained in this
subsection, detailing its approach, implementation steps and
the addressed challenges.
1) Abstraction of ROS environment: It aims to address the
interoperability challenge when integrating other IoT devices
in BRAIN-IoT platofrm. As Fig.1 shows, the basic function of
Fig. 1. ROS Edge Node structure ROS Edge Node is to map the ROS messages to BRAIN-IoT
events and vice-versa. The BRAIN-IoT services interact with
each other by leveraging the Requirements and Capabilities
heterogeneous IoT applications running on the processing metadata provided by default by all OSGi Bundles, the events
nodes to control the robots. In the BRAIN-IoT platform, the issued by a source BRAIN-IoT service contains the sufficient
authors’ contribution is to develop the ROS Edge Node as information presenting the Requirements of this service, in the
OSGi Declarative Service, so that from the northbound it can meanwhile, the events also identify the Capabilities of the sink
receive the interested BRAIN-IoT events from other different BRAIN-IoT services that will consume them.
IoT platforms in a distributed environment, then construct the The ROS Edge Node simply interconnects to the ROS
data and send to the connected ROS environment. Therefore, environment thanks to the RosJava library which provides a
any new functionalities for enhancing/extending the behaviour simple interface enabling the ROS Edge Node to automatically
of robots according to external events can be developed using generate a set of Java object classes, which is totally compliant
OSGi instead of ROS. From the southbound, the ROS Edge with native ROS messages’ structure in the ROS environment.
Node is able to retrieve the information from ROS and inject The instances of the classes could be transformed to the ROS
to the BRAIN-IoT Fabric as BRAIN-IoT events, which will be environment. However, it’s not possible to make the BRAIN-
received by other BRAIN-IoT services. The ROS Edge Node IoT events types the same as the names of the native ROS
aims to achieve the interoperability between heterogeneous messages. For a single robot, there could be hundreds of types
IoT applications integrated within BRAIN-IoT platform and of native ROS messages in the ROS environment and their
the ROS-based CPSs. It exposes the ROS functionalities as data structures are in general very complex, direct mapping
OSGi services. between the ROS messages types and BRAIN-IoT events is
The architecture of ROS Edge Node is shown in Fig.1. For inefficient and will increase the complexity of the usage of the
its development and validation, the authors have used the ROS events for other IoT applications. Also, different robots having
simulation for BRAIN-IoT service robotic use case provided same functions may use completely different types of ROS
by the Robotnik Automation S.L.L. (see Section IV). The messages as commands. In such case, if directly mapping each
ROS Edge Node has two main requirements: i) to expose ROS message into an event, the difficulty to integrate different
all the relevant ROS functionalities as OSGi services (task robots in a system will be increased. Thus, some common data
done by OSGi Service Component). The objective is to make types including necessary information need to be defined and
the adaptor able to interoperate with the ROS environment shared between diverse IoT applications. So it’s necessary for
leveraging APIs provided by the open source Rosjava project, ROS Edge Node to format the received events into the specific
in this way, the adaptor is able to send/receive the ROS Java objects that are compliant with ROS messages.
request/response messages from/to the ROS services and pub- The ROS Edge Node wraps also the native ROS functionali-
lish/subscribe to the ROS topics between the OSGi world and ties, exposing them to the OSGi services for heterogeneous IoT
ROS world. ii) To collect and format of the BRAIN-IoT events applications’ access, by creating the corresponding ROS ser-
from different sources based on the Publish-Subscribe pattern5 vices and publish/subscribe clients in OSGi bundles, through
(task done by BRAIN-IoT Robot Service). The adaptor receives the APIs provided by RosJava project. The exposed OSGi
the events from heterogeneous platforms in the distributed services are a set of java classes containing multiple robot
BRAIN-IoT Fabric environment and constructs them as Java operations mapped to Java methods. The BRAIN-IoT Robot
Service in Fig.1 is a wrapper of the exposed OSGi services,
5 https://en.wikipedia.org/wiki/Publish\%E2\%80\%93subscribe pattern with the specific Capabilities information represented by the
50
consumed event types. The ROS Edge Node is responsible
for communicating with other BRAIN-IoT services using
Events. When the robot service receives an event from the
EventBus, it will construct a ROS message in Java type and
perform the corresponding action by calling the exposed ROS
functionalities. Thanks to the BRAIN-IoT solution, the service
will be deployed on the BRAIN-IoT Fabric by the event-driven
mechanism. It’s completely de-coupled from the underlying
BRAIN-IoT Fabric runtime.
2) The Autonomous Operation: As mentioned in Sec-
tion II-C, supporting autonomous operation is one of the
challenges for a CPS adaptor. In the ROS Edge Node, the
autonomous operation is fully supported by a feedback mech-
anism: the ROS Edge Node is responsible for continuously
querying the execution status of CPS where it is installed
and then to issue an response event if the status changes.
Fig. 2. Thing Description of ROS Environment
This allows building services, which leverage the ROS Edge
Node, which are “smarter” and reducing the communication
workload on the EventBus,(see Fig.6 in Section IV).
3) Automatic Adaptation and Standards Compliant: This
is a usual task that needs to be supported by such type of
solutions. For ROS-based devices, this challenge is addressed
by ROS Edge Node. As mentioned above, the exposed service
components are a set of java classes containing multiple
methods for robot operations. The operations are done through
ROS services/topics clients in Java code via simple API
provided by RosJava library. Normally, when developers create
the java clients for the used native ROS functionalities, the java
clients could be grouped in one or more Java classes for better
organization.
Since the services or topics and their related methods in a Fig. 3. Expose of ROS Environment to OSGI Services Using WoT TD
component class have the same structures, the authors achieve
to automatically realize the adaption by creating a Code
Generator to automatically generate the OSGi service classes
from a predefined configuration file as the input. Since all for different types of robot functionalities, and each component
entities in ROS-based CPS communicate through services and can contain multiple service clients and the different operations
topics, the authors choose to use the W3C WoT TD, which could be done through the methods called by each client. The
is a general standard for both integrating diverse devices and values of other properties will be used as the arguments of the
interoperability of diverse applications to describe the ROS generated methods. Similarly, the ROS topics will be described
functionalities. In the proposed solution, WoT TD describes in the Properties element, including the information about
the interfaces for OSGi to expose the ROS services and topics. Role, ReferenceName, TopicName, TopicType, MessageType
In this way, a standard approach is used to describe the ROS and ClassName. The value of the Role property could be
API and to generate the corresponding OSGi services, this publisher or subscriber, so the corresponding client type
allows to have a solution WoT integration-ready and highly will be created with the client name equal to the value of
reusable. The ROS functionalities are compliant with TD ReferenceName.
specification: 1) the topics are as Properties Interaction Af- To automatically expose relevant ROS functionalities and
fordances 2) the services are described as Actions Interaction speed up the ROS Edge Node development for the ad-hoc
Affordances. ROS platforms, A code generator is provided to generate the
For a ROS service, the part of TD file is shown as Fig.2. artefacts automatically by taking the TD as a configuration
More specially, there could be a set of ROS services described file, to describe the ROS services and topics, as shown in
in the Actions element, and for each of them, the informa- Fig.3, which is demonstrated in Fig.5 in Section IV. This
tion will include serviceClientName, serviceName, service- approach greatly reduces the dependence for developers in the
Type, serviceRequestType, serviceResponseType and Class- process of adapting to different ROS-based CPSs, increasing
Name, which are used by the Code Generator to create the development simplicity. Developers can therefore focus
service clients in OSGi world. The Code Generator uses the more on the development of BRAIN-IoT services rather than
ClassName property to generate multiple component classes on adaptation work.
51
Fig. 4. Warehouse simulation
Fig. 5. Method Blocks of Automatically Exposed ROS Services from TD file
IV. U SE C ASE D EMONSTRATION
In this section, a brief description of ROS simulation The new functionalities for enhancing/extending the behaviour
used for the Brain-IoT Service Robotic Use Case and the of robots according to external events can be dynamically
result obtained evaluating the cross-platform communication upgraded and redeployed in the BRAIN-IT architecture. Based
mechanism using it are presented. on that, the authors define the events in three types: action,
query and cancellation. The events in action type includes
A. Use Case Introduction WriteGoTo, PickCart and PlaceCart, which present the basic
Smart warehouse is a popular application of Industry 4.0. functions of the robot. There are also other events defined for
The basic elements of a smart warehouse include AMR, querying the execution status of corresponding actions and for
heterogeneous IoT devices and cargo carts. To be “smart”, cancelling current actions.
these elements need to interact and cooperate with each other. In the use case, there are three services related to the
The use case aims to realize one of the basic function of smart WriteGoTo action event, a WoT TD file is defined for the com-
warehouse: the cart movement. The Fig.4 shows the warehouse munication with the robotic system, the code generator using
with three zones in 3D perspective in Gazebo simulator: a the TD as input will automatically generate the class named
docking area, a unloading area and a storage area. The last GoToComponent as shown in Fig.5 by using the open source
two zones are separated by an automatic door, which is an JCodeModel library which is a Java code generation library.
IoT device. There are three rb1 base robots (robot1, robot2 and Specifically, according to the ROS functionalities described
robot3) in the docking area responsible for moving all carts to in the TD, there are three ROS service clients (e.g. gotoRun,
the storage area. In the unloading area there are 3 carts (cart1, gotoCancel, gotoQuery) will be created in the generated class.
cart2 and cart3) and each has a different QR code attached. when the ROS Edge Node receives an event, the corresponding
The storage area is divided into three sub-zones (zone A, zone construct XXX Msg method representing the operation of the
B and zone C). The robots need to pick up these carts from client will be called to construct a Java object representing the
the unloading area, pass through the door and place them in ROS message as a ROS service request to be sent to the native
the storage area according to the received commands from the ROS environment through the call XXX method of the service
robot application. client, where the XXX stands for the name of the service client.
The Robot Behaviour Service continuously checks the
B. Robot System Design shared tables to get a task and then it controls the robots
In order to demonstrate how the adaptor bridges the ROS through a sequence of BRAIN-IoT events to finish the mission.
environment and the OSGi environment, the authors imple- The events will be received by the ROS Edge Node Service
mented a simple multi-agent robot system based on OSGi to and sent to the connected robot. As an example shown in Fig.6,
control the simulated robots. after the ROS Edge Node receives a WriteGoTo event from the
The system contains three system parts: a Robot Behaviour Controller Service containing the coordinates where the robot
Service, a ROS Edge Node Service and a Door Edge Node should go, with the autonomous operation of the ROS Edge
Service. There are several tables storing the coordinates of Node, only twice communications are needed between the
the carts and the storage positions will be used as the shared Controller Service and the ROS Edge Node, one for sending
resources among three robots. In the ROS simulation, the basic the action command, while the other one for receiving the
task for each robot is that starting from the docking area, it action result. When the robots detected a door on the way
needs to go to the picking area for picking up a cart, then pass to the storage area, it reports the situation and the Robot
through a door to the storage area and finally place the cart, Behaviour Service will instruct the Door Edge Node Service
the procedure is controlled by the Robot Behaviour Service. to open the door.
52
find the pending tasks. When a cart to be moved is found in
the table, Robot Behavior will change the status of the cart
to moving and start the moving procedure. Robot behaviors
will deliver a sequence of events to the corresponding ROS
Edge Node one by one to command the robot to move to cart
position, pick up the cart, move the cart to specific position
in the storage area and finally drop the cart. When ROS Edge
Node receives an event, it extracts the information contained
in the event, constructs a ROS message in Java type, and com-
municates with the robot through the exposed OSGi services.
ROS Edge Node is responsible for continuously querying the
execution status from the specific ROS service/topic, when the
action of an event is finished or something wrong happened,
a feedback event will be issued to inform the Robot Behavior
to ask for the next action. During the moving procedure, if
the door is closed, it will scan the QR code of the automated
Fig. 6. Communication Procedure of “WriteGoTo” action for ROS Edge Node
door, and return a DoorFound event to the Robot Behavior.
The Robot Behaviour will send a OpenDoor event to the Door
Edge Node service to open the door.
After finishing the moving procedure, the Robot Behavior
Service will change the status of the cart to moved in the table
and search for the next mission. Finally all carts are moved in
ROS simulation.
D. Validation in Physical Environment
To prove the feasibility of the approach proposed in the
paper, ROS Edge node has been installed on a real rb-1 base
mobile robot. Due to the difference of the simulated world
and the physical world, the autonomous robotic system is not
Fig. 7. Deployment of Robot System in the distributed BRAIN-IoT Fabric
used in the physical environment, but authors implemented
an Orchestrator service, which provides a simple interface
for users to manually send a sequence of BRAIN-IoT events
In the test, the robot system above is deployed on a dis- including the coordinates to control the actions of the robots in
tributed Fabric environment containing multiple Raspberry Pis a physical environment. The Orchestrator is implemented as a
and one Linux server running the ROS simulation as BRAIN- OSGi Declarative Service and it injects a sort of commands in
IoT nodes in a same network. The Linux server is labeled the Apache Felix Gogo 6 , which is a subproject of Apache Fe-
in advance when BRAIN-IoT Fabric cluster is created and the lix implementing a command line shell for OSGi, which could
ROS Edge Node Service is automatically deployed on it when be accessed via its web interface in a distributed BRAIN-IoT
the label is detected. Since there are three simulated robots, Fabric environment. When a user enters the command in Gogo
three instances of the ROS Edge Node Service instantiated shell, the corresponding method in the Orchestrator will issue
by OSGi Configuration Admin Service Specification [5] to a specific event to EventBus. The Orchestrator service could
connect to the robots through IP address, the interested events be installed on any BRAIN-IoT node. Finally, ROS Edge Node
will be delivered to the ROS Edge Node through the integrated is able to receive the events and the robot will move towards
EventBus. In the multi-agent system, each Robot Behaviour to the target positions.
Service instance will control one robot to take a task from
the shared table, after one task is finished, it will start next V. C ONCLUSION AND F UTURE W ORK
iteration. In this case, the deployment of Robot Behaviour The paper has presented the ROS Edge Node, which enables
Service and the ROS Edge Node Service in the real physical the interoperability between the ROS-based CPS applications
environment can be shown as Fig.7. Meanwhile, The door and other heterogeneous IoT platforms in a sophisticated IoT
in the simulation environment is a IoT device controlled by software ecosystem, based on the available services in BRAIN-
the Door Edge Node Service, which is simulated in the ROS IoT framework. This solution provides several innovative
environment. features, to ease such interaction. Firstly, it can be dynamically
deployed and flexibly scaled on demand to connect to multiple
C. Validation in Simulation Environment
ROS-based CPSs at runtime whenever a new CPS joins the
When the multi-agent robot system is activated, each Robot
Behavior Service instance will check the shared cart table to 6 https://felix.apache.org/documentation/subprojects/apache-felix-gogo.html
53
cluster. Secondly, it provides an approach to automatically [6] https://docs.oracle.com/middleware/1212/wls/WLPRG/overview.htm#
expose the ROS functionalities as OSGi services for bridging WLPRG107.
[7] G. Di Modica, F. Pantano, and O. Tomarchio, “Snps: An osgi-based
the ROS world and OSGi world. Thirdly, ROS Edge Node middleware for wireless sensor networks,” 09 2013, pp. 1–12.
maximizes the flexibility of the mechanism by supporting [8] https://projects.eclipse.org/proposals/eclipse-sensinact.
customized autonomous operation to detect the changes of [9] https://www.w3.org/TR/wot-architecture/.
[10] “Community metrics report,” http://download.ros.org/downloads/
action status and issue feedback events, thus greatly reduces metrics/metrics-report-2019-07.pdf, July 2019.
the communication load on EventBus and its dependence [11] M. Aragão, P. Moreno, and A. Bernardino, “Middleware interoperability
on other system components. Finally, the use of WoT TD for robotics: A ros–yarp framework,” Frontiers Robotics AI, vol. 3, p. 64,
2016.
standardizes the description of the ROS functionalities. [12] G. Metta, P. Fitzpatrick, and L. Natale, “Yarp: Yet another robot
Compared with the existing CPS middleware or IoT middle- platform,” International Journal of Advanced Robotic Systems, vol. 3,
ware, the proposed solution presents several advantages, but 03 2006.
[13] R. Arrais, P. Ribeiro, H. Domingos, and G. Veiga, “Robin:
some further developments are still ongoing. The integration An open-source middleware for plug‘n’produce of cyber-physical
with the BRAIN-IoT End-to-End Security Framework are systems,” International Journal of Advanced Robotic Systems, vol. 17,
still under development. Besides, its functionalities will be no. 3, p. 1729881420910316, 2020. [Online]. Available: https:
//doi.org/10.1177/1729881420910316
enriched more, such as the graphical monitoring of robot status [14] A. Pletsch, “Codesys eases programming for multiple controls hard-
and the warehouse coordinates at runtime by integrating with ware,” vol. 50, pp. 34–35, 06 2004.
other BRAIN-IoT monitoring tools. ROS Edge Node will be [15] A. Santos, A. Cunha, N. Macedo, R. Arrais, and F. N. dos Santos,
“Mining the usage patterns of ros primitives,” in 2017 IEEE/RSJ
tested on the real robots with a more complex Robotics use International Conference on Intelligent Robots and Systems (IROS),
case and the performance will be compared with other existing 2017, pp. 3855–3860.
solutions, in the future work. [16] N. Mohamed, J. Al-Jaroodi, S. Lazarova-Molnar, and I. Jawhar, “Mid-
dleware challenges for cyber-physical systems,” Scalable Computing.
ACKNOWLEDGMENT Practice and Experience, vol. 18, no. 4, pp. 331–346, 2017.
[17] M. A. Chaqfeh and N. Mohamed, “Challenges in middleware solutions
The work presented here was part of the project ”Brain-IoT- for the internet of things,” pp. 21–26, 2012.
model-Based fRamework for dependable sensing and Actua- [18] N. Rosa, D. Cavalcanti, G. Campos, and A. Silva, “Adaptive middleware
in go - a software architecture-based approach,” J Internet Serv Appl 11,
tion in iNtelligent decentralized IoT systems” and received 3 (2020), 05 2020.
funding from the European Union’s Horizon 2020 research [19] T. Tomlinson and J. VanDyk, “Xml-rpc,” 01 2010.
and innovation programme under grant agreement No 780089. [20] R.Nicholson, T.Ward, D.Baum, X.Tao, D.Conzon, and E.Ferrera, “Dy-
namic fog computing platform for event-driven deployment and orches-
The simulation environment is provided by Robotnik Au- tration of distributed internet of things applications,” pp. 239–246, 2019.
tomation S.L.L.
R EFERENCES
[1] N. Boulila, “Cyber-physical systems and industry 4.0: Properties, struc-
ture, communication, and behavior,” 04 2019.
[2] S. Barai, M. K. Kundu, and B. Sau, “Path following of autonomous
mobile robot with distance measurement using rfid tags,” in 2019 IEEE
International Symposium on Measurement and Control in Robotics
(ISMCR), 2019, pp. A3–4–1–A3–4–4.
[3] nud Lasse Lueth, “Iot platform companies landscape
2019/2020: 620 iot platforms globally,” https://iot-analytics.com/
iot-platform-companies-landscape-2020/, December 2019.
[4] D. Conzon, M. R. A. Rashid, X. Tao, A. Soriano, R. Nicholson, and
E. Ferrera, “Brain-iot: Model-based framework for dependable sensing
and actuation in intelligent decentralized iot systems,” in 2019 4th
International Conference on Computing, Communications and Security
(ICCCS), 2019, pp. 1–8.
[5] O. Alliance, “Osgi core release 7,” OSGi Alliance, Tech. Rep., Apr.
2018.
54