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