Abstract
Motivated by the Fourth Industrial Revolution, there is an ever-increasing need to integrated Cyber-Physical Systems in industrial production environments. To address the demand for flexible robotics in contemporary industrial environments and the necessity to integrate robots and automation equipment in an efficient manner, an effective, bidirectional, reliable and structured data interchange mechanism is required. As an answer to these requirements, this article presents ROBIN, an open-source middleware for achieving interoperability between the Robot Operating System and CODESYS, a softPLC that can run on embedded devices and that supports a variety of fieldbuses and industrial network protocols. The referred middleware was successfully applied and tested in various industrial applications such as battery management systems, motion, robotic manipulator and safety hardware control, and horizontal integration between a mobile manipulator and a conveyor system.
Introduction
The next generation of industrial manufacturing is being driven by the ongoing Fourth Industrial Revolution. This current industrial revolution, so often referred to as Industry 4.0, 1 has been preceded by the introduction of digitalization and by the use of electronics and Information and Communications Technology (ICT) in manufacturing processes, which paved the way for the large-scale deployment of Cyber-Physical Systems (CPSs) and the emergence of Internet of Things (IoT) in industrial contexts. 2
Even though the original axioms of Industry 4.0 primarily addressed the full adoption of interconnected CPSs in production environments, nowadays the movement accredits an extensive catalogue of technologies and has been extended to the majority of valuable processes in the product and production system life cycles. In addition, in the last decade, the Industry 4.0 view has been associated with cornerstone ideological shifts, not only on the technological domain, with innovations in areas such as robotics, automation, artificial intelligence and IoT, but also on the business front. To cope with increasing demand diversity, products with shorter life cycles and low volumes per order, manufacturing enterprises are altering their production paradigms to account for an ever-increasing necessity of enhancing the flexibility and efficiency in novel and legacy production systems. Furthermore, while abiding by the aforementioned necessities, companies are also expected to maintain, if not enhance, quality, reliability, manage costs and also account for environmental impacts.
In an attempt to deal with recent changes to traditional manufacturing practices and to capitalize on the opportunities created by the current industrial revolution, manufacturing companies and their suppliers are resorting to novel ICT and manufacturing strategies. These new technological advancements and decision-making processes are currently emerging to endure the high variability of contemporary supply chains and production units. Notably, the introduction of fully interoperable CPSs for the automation of non-added value operations and the enhancement of working conditions and ergonomics are significant constituents of the array of technological innovations being developed and applied in cross-sectorial manufacturing industries.
Many complications and opportunities appear when considering the application of advanced CPSs in industrial environments, which largely vary according to the specificities of each industrial sector and the particular application. Nevertheless, the interoperability between different CPSs and between CPSs and the industrial digital infrastructure are transversal to a multitude of industrial sectors and application domains, where effective communication methods are deemed to be indispensable. Moreover, the advent of flexible, autonomous and reconfigurable CPSs increases the necessity of effective and agile methodologies for expediting intercommunication, as to further foster the plug’n’produce concept.
On a broader perspective, the adoption of CPSs in manufacturing contexts undeniably requires connection and interoperability with the industrial ecosystem. Currently, despite being an essential property of modern manufacturing systems, the interoperability of CPSs in contemporary industrial settings is still subpar in many dimensions. This characteristic deeply contrasts with other industrial domains, such as Business-to-Business (B2B) interactions and Inter-Organizational Systems (IOS), where integration research and commercial efforts have been in development in the last decades, especially since the advent of the Internet. 3,4 Even though there are many complex challenges associated with the domain of IOS, some effort has been applied to exploring the standardization processes and interactions between enterprises. 5 Such efforts have been motivated by clear commercial advantages and further highlight the dissimilarities in achieving interoperability on different industrial domains. However, the introduction of CPSs in industry, on the scope of the ongoing industrial revolution, is serving as the tipping point to alter this pattern. As modern robotic systems and advanced automation equipment are undoubtedly being applied to manufacturing processes, connectivity and interoperability efforts of scientific and commercial nature are emerging, as industrial enterprises are starting to sense potential business advantages. Many of the pioneering efforts on this discipline have an open-source, community-supported and market pull essence, which not only supplements the genuine motivation driving the necessity for achieving true and open interoperability but also acutely opposes traditional approaches based on market push, introduced by key corporations in the field.
Thus, to promote and maximize the effectiveness of CPSs in industry, traditional manufacturing systems and architectures need to be revisited. To take full advantage of CPSs in production, a complete integration with all levels of the industrial digital infrastructure is required. As a consequence, there is a crescent need to characterize and standardize the interoperability of CPSs in two distinct, although relatable, axis: the vertical integration with higher layers of enterprise software, such as Enterprise Resource Planning and Manufacturing Execution Systems; and the horizontal integration between different CPSs or between CPSs and legacy production systems.
In the last years, some efforts on the topic of vertical connectivity of CPSs have been presented and introduced in the industrial context, with varying levels of success. 6 The majority of efforts, however, either focuses categorically on some restricted domains of the overall industrial architecture or fail to be accepted by the robotics and automation communities. Two additional constraints need to be pondered when considering vertical integration of CPSs in modern manufacturing systems. The first constraint is related to the necessity for integration architectures to foresee and allow seamless data transmission and functional interoperability. These notions not only apply to the aimed interoperability within a single organization but also when considering intercompany integration. This issue has an extra layer of complexity associated since more often than desired, each industrial sector employs its own standards and processes for vertical communication, and mostly rely on proprietary enterprise systems, with limited Application Programming Interfaces (APIs). The second constraint is related to security and is intrinsically associated with the first, in the sense that if data transfer and functional interoperability are to be expected between multiple enterprise systems, future vertical integration efforts have to provide at least basic security standards. 7
In a similar way, the horizontal integration between CPSs and existing automation equipment is still an open-ended issue. Actually, even the integration of automation equipment alone can still be a cumbersome task in the present. Problems often referred to as vendor lock, such as proprietary protocols, communication interfaces and buses are a daily struggle for automation and integration engineers trying to interconnect equipment from different suppliers. As a consequence, very frequently, integrators make the decision of acquiring components from the same vendor, in order to protect the system from the risk of incompatibility. 8
In the particular case of the integration of robotic systems and automation equipment, some organizations and initiatives such as ROS-Industrial and OPC-Unified Architecture (OPC-UA) have been attempting to improve interoperability between the automation and robotics realms. While the latter initiative still has a limited presence in practical horizontal integration efforts between robots and automation equipment, the former organization has promoted the materialization of a set of approaches for establishing interoperability between robots, running the Robot Operating System (ROS), and automation equipment, mostly on the form of communication via fieldbuses. In fact, the ROS-Industrial organization has endorsed the development of ROS packages that enable interoperability with some fieldbuses, such as Modbus, CANopen, EtherNET/IP and EtherCAT. 8
Although communication between robotic systems running ROS and automation equipment is possible relying solely on fieldbuses, it is often not practical. Not only interface limitations of fieldbuses pose some challenges to enable an effective and bidirectional communication pattern between complex ROS messages and automation devices, but also these methods often require developers to handler inherent overheads imposed when following the fieldbus-based communication approach.
To address these limitations, the ROS-Industrial organization is promoting the ROBIN project, as one of the Focused Technical Projects (FTPs) of the European-funded ROSIN initiative. The ROBIN project aims to address the demand for flexible robotics in industrial environments and the necessity to integrate robots and automation equipment in an efficient manner. For this, the ROBIN project will focus on further developing and releasing, as an open-source software, a bidirectional, reliable and structured communication bridge between ROS and CODESYS, a softPLC that can run on embedded devices and that supports a variety of fieldbuses, and even OPC-UA (https://github.com/ScalABLE40/robin).
This article will present the proposed communication bridge, which is built on top of a previously published paper. 8 Furthermore, this work will highlight the set of innovations introduced in the preparation of the open-source release of the aforementioned communication method. In specific, an automatic code generation procedure will be presented, which effectively diminishes the time and effort required to establish interoperability using the proposed bridge. In addition, several application examples will be portrayed, representing the application of the proposed interoperability methodology in several R&D initiatives of European nature. Furthermore, the development roadmap, following the release of the proposed methodology will be described, also addressing future work on the scope of the ROBIN project.
Related work
Encapsulated under the Industry 4.0 umbrella, groundbreaking technology has pushed forward the connection between physical assets and computational capabilities. In the prospective Factory of the Future, data from the physical factory shop floor will be captured and stored in a synchronized and centralized virtual representation. 9,10 As a direct consequence of the information analytics conducted on the captured data, networked industrial systems will be capable of more efficient, collaborative and resilient performance. 11 In addition, the interaction with the physical reality will not be restricted to sensing capabilities, but will, in fact, also incorporate active actuation by embedded software devices in the production process.
The aforementioned capabilities are associated with the concept of CPSs that can be defined as embedded software devices which directly record physical data using sensors and affect physical processes using actuators. The German Academy of Science and Engineering (acatech) 12 defines that CPSs can also evaluate and save recorded data from the environment, and actively or reactively interact both with the physical and digital world. As such, one of the main characteristics of CPSs is that these devices are connected with one another (horizontal integration) and in a global network via digital communication facilities such as the IoT (vertical integration). Furthermore, it suggests that through the usage of CPSs, the cyberspace, that is, the virtual representation of an environment, can be seamlessly connected with the physical reality. This junction originates an Internet of Things, Data and Services. As pointed by the IEEE Technical Committee on CPSs (http://www.ieee-cps.org/), the design, implementation and operation of CPSs need the consideration of multiple aspects such as reliability and real-time computing constraints. These are key features for many robotic systems, particularly safety and mission-critical applications such as industrial manufacturing. Although such features are not currently supported by ROS, efforts are being made to include them in ROS 2. 13
The domain of potential applications of CPSs is very broad. The market pull for CPSs solutions is increasing from a multitude of different sectors, ranging from robotic systems and factory automation to aerospace systems and transportation vehicles. 14 Networked industrial automation systems and robotics can be considered CPSs, as there is a connection between sensing and actuation on the physical reality with computing and communication infrastructures. 2
Lee et al. 11 propose an architectural guideline for Industry 4.0-based manufacturing systems, which encompasses CPSs. This architectural guideline is one example of the multitude of research-based efforts that appeared in the last few years. Complementary, some government-based initiatives, such as the European-supported RAMI 4.0, 15 originated in Germany, which proposes a reference architecture model for Industry 4.0 have also been introduced. This reference architectural model can be described as a three-dimensional map that portrays the Industry 4.0 issue in a structured fashion. In its essence, RAMI 4.0 is a service-oriented architecture (SOA) that combines all elements and IT components in a layer and life cycle model.
Although some researchers and government-based initiatives have made a significant contribution to the overall status of integration and interoperability of CPSs in manufacturing environments, the reality, however, is still far from the one presented in the literature. In fact, the current integration of CPSs and automation equipment with enterprise-level systems still mostly follow ad hoc approaches. Currently, integration efforts are still closely tied with the automation pyramid envisioned in ISA-95, 16 requiring data to travel through several levels of the architecture before it reaches its desired destination. In addition, in a vast majority of cases, the so-called integration is done by creating and establishing point-to-point connections, specific to the problem and use case, which deeply undermines the flexibility of the system to adapt to the frequent changes required in a dynamic and modern manufacturing environment. Furthermore, these integration efforts frequently employ proprietary communication buses, which does not abide in favour of the eventual integration of future equipment.
In the last years, some integration efforts have been presented and introduced in the industrial context with varying levels of success. These efforts, however, mostly focus on some domains of the overall architecture, as a common, universal, integration architecture approach is still missing. Two good examples of this sectorial efforts are the integration of modern automation equipment using OPC-UA, 17 and the emergence of IoT platforms 18 such as FIWARE 19 and OpenIoT. 20 Nevertheless, their reach to practical application examples in industrial settings is still minimal.
On the domain of robotics, the development of an application for industrial purposes can be undermined if one has to account for starting the development process from the driver-level up to the high-level tasking. Not only such effort would require an immeasurable amount of time, but it would also require an extensive domain of knowledge, which is far beyond the capabilities of a single developer, researcher or even of a company or a research laboratory. For these reasons, modularity is a key concept in the development of robotic applications. Thus, some robotic frameworks have appeared in the last years to foster the modularity and aid the development process. ROS has become a de facto framework for robot development, and it is expanding its industrial presence over time. Besides the modularity factor, which is undeniably present in the ROS framework, since each feature of the system can be decomposed into a set or an arrangement of ROS nodes, the distributed nature of the framework is also interesting. In fact, some R&D initiatives such as H2020 RobMoSys 21 and H2020 FASTEN 22 have been exploiting these tenets for the modular design of complex robotic systems. ROS also provides libraries and tools to help developers in the process of creating robotic applications and, consequently, robotic systems. Besides providing hardware abstractions and device drivers, ROS also provides tools such as visualizers, message-passing and package management systems. 23
The distributed tenet allows for a typical ROS system to be a composition of multiple somewhat independent nodes that are interconnected by a communication medium. ROS supports two major paradigms for interchanging information between nodes: services and topics. Topics are named buses over which nodes exchange messages via a publisher–subscriber semantics, which decouples the production of information from its consumption, and are intended for unidirectional streaming communication. This pattern ensures that a given node can publish messages on topics that have a specific and identifiable name in the ROS network, allowing other nodes to access the data published on these topics, by subscribing them by their names. Each topic also has a message type, determining the type of data to be transmitted. Even though ROS has some predefined standard messages, it is also possible to create custom messages, suited to the user needs.
Communication between ROS nodes is usually accomplished through a publisher–subscriber pattern. 24 a very flexible communication paradigm, however, sometimes its many-to-many one-way transport is not appropriate for Remote Procedure Call request–reply interactions. Since the aforementioned interaction is common and required in a distributed system such as ROS, a service paradigm is also available as a communication methodology. In it, request–reply interactions, that is, services, are defined by a pair of messages: one for the request and the other for the reply. In great similarity with the topic-based communication, a ROS node can be the provider of a service by defining it under a string name and with a given service type. In its turn, a ROS client node can call the service by sending the request message and awaiting the reply. These communication interfaces have also served as the base for the development of communications bridges analogous to the one proposed by this article, such as the ROSLink 25 and the Rosbridge, 26 which facilitate the integration of ROS nodes and web technologies.
Out of the many industrial robotic systems developed using ROS, the mobile manipulators appear as one of the most promising approaches for solving a multitude of open challenges in industrial scenarios. A mobile manipulator is the result of the integration of a robotic manipulator arm in a robotic mobile platform, which results in a manipulator appended with a horizontal workspace, only limited by its surroundings. Traditionally, these systems have been used in applications such as space exploration and military operations, but now they are beginning to be introduced in the industry. 27 Mobile manipulators are an excellent case study for the application of a robotic development framework, such as ROS, since they combine a multitude of robotic disciplines under the same platform. Moreover, due to the necessity of integrating different equipment from different manufacturers (mobile platform, robotic manipulator arm, sensors and actuators), often relying on fieldbuses and industrial network protocols, mobile manipulators are the perfect test bed for attempting to assess the relevance of horizontal integration approaches, such as the one proposed in this article.
In the domain of industrial automation, the IEC 61131 standard promoted a common understanding, compatibility and possibility of code portability between Programmable Logic Controllers (PLCs) of different manufacturers. This standard defines all aspects regarding PLC development and is decomposed in a subset of parts. The third part of the standard, IEC 61131-3, defines the five available programming languages and the three Program Organization Units (POUs). 28 The adoption of the standard by PLC manufacturers has increased in the last years, even though it is frequent for each vendor to introduce some modifications to the program development domain. Consequently, it is still common to have programs created for different PLC brands not being compatible with one another. However, the emergence of softPLCs, which are, most of the times, hardware agnostic, contributed to a decrease in incompatibility between manufacturers. In fact, softPLCs can be implemented in a diverse array of devices, from robust industrial computers to frail embedded devices. CODESYS, from the German company 3S-Smart Software Solutions GmbH, has emerged in the last years as a market reference for softPLCs. Currently, CODESYS offers an IDE that implements almost strictly the IEC 61131-3 standard and allows developers to program PLCs not only from the over 250 PLC hardware manufacturers that rely on CODESYS as a development tool for their equipment but also from multiple devices from other vendors. 29 In what regards connectivity, CODESYS supports and has integration tools for an immense number of fieldbuses and industrial network protocols. Fieldbuses and industrial network protocols are traditionally the preferred way of interchange information between automation equipment. Furthermore, the same communication approaches are often employed to transmit data between PLCs applications to the non-automation domain. Nevertheless, as previously addressed, these interfaces are not always ideal, especially when attempting to achieve interoperability between robotic systems, running ROS, and automation devices.
Robotics bridge to industrial automation
ROBIN, the robotics bridge to industrial automation previously proposed 8 was idealized for running inside an embedded device. In specific, the BeagleBone Black (BBB) was used, due to it being a low cost embedded solution to potentially achieve real-time task execution. In addition, the BBB was capable of running Ubuntu, which is the recommended Linux distribution for ROS and CODESYS. The developed bridge was, therefore, tested using the CODESYS softPLC runtime v3.5.10.30 and ROS Kinetic on Ubuntu 16.04. As described later, the usage of an embedded device could be dismissed in some applications, since both ROS and CODESYS, can run on a traditional computer. Furthermore, since both CODESYS and ROS are supported by several (embedded) devices running Linux, the developed mechanism can be easily ported to other hardware solutions. This particular migration is marked as future work.
The reach of potential practical application examples for this horizontal integration approach is vast, as robotic systems often need to rely on establishing communication or interoperability with hardware providing a fieldbus-based communication, such as actuators like grippers or motor drivers, and sensors like laser scanners or safety barriers. In addition, robotic systems, mainly the ones of an industrial nature, often need to communicate with external industrial equipment, frequently controlled by a PLC.
As previously addressed, ROS currently lacks proper support for fieldbus-based communications, which one can argue that constitutes a potential major limitation impeding the full-blown adoption of ROS in industrial applications. In spite of existing some ROS packages which already implement communication with a limited amount of fieldbus protocols, the development process can be difficult and slow. On the other hand, the CODESYS framework, as a proper development environment for programming PLC applications, already provides tools to implement communications using fieldbuses and other industrial network protocols effortlessly. Therefore, the proposed mechanism can be used to ease the fieldbus-based communication between a ROS system and external devices. In this scenario, CODESYS handles the establishment of external communication with the equipment via a fieldbus and communicates with ROS through the developed methodology. The information to be propagated to the external devices could be published on a ROS topic, handled by the developed bridge, and then relayed by CODESYS to the proper industrial network protocol or fieldbus. Similarly, on the other way around, information can arrive at the CODESYS side, via fieldbuses or other industrial network protocols, and relayed to a ROS topic using the proposed methodology. As CODESYS supports several fieldbuses and industrial network protocols, this application perspective is particularly interesting if the communication protocol has not yet been implemented on ROS, such as OPC-UA, as it is possible to enable interoperability while maintaining the structural and functional composition of ROS messages and topics. In addition, CODESYS provides a set of interesting tools and plug-ins that can be useful for robotic systems. One interesting example is in advanced motion control or Human–Machine Interfaces (HMIs). Thus, the difficulties of developing controllers for motor drivers are significantly smaller, when in comparison with ROS. Similarly, the development of web-based user interfaces with an industrial outlook for robots can be simplified by relying on the HMI design tools provided by CODESYS.
Another utilization opportunity regards the direct horizontal integration of robots and automation systems in an Industry 4.0 production environment. As industrial machines are generally controlled by PLCs (using either a CODESYS-based runtime application or of another manufacturer), horizontal integration could be achieved by the interchange of messages between the robot and the PLC. A concrete example of this modality is presented later, where a mobile manipulator, running ROS, interacts with a conveyor system and a set of laser sensors controlled by a Siemens PLC, running SIMATIC.
Furthermore, the proposed methodology enables the programming or parametrization of robotic tasks using IEC 61131-3 programming languages. In this scenario, ROS developers can parametrize their applications with data expected to come from the softPLC environment via the bridging mechanism. Even though this scenario has not yet been explored in practice in any industrial endeavour, one can easily see the potential of having automation engineers or even operators, without any background in robotics, to easily be capable of parametrizing or altering ROS-based robotic behaviour using familiar IEC 61131-3 programming languages and automation development environments.
In the remainder of this section, the proposed bridge for achieving horizontal interoperability, as described in a previous publication, 8 will be further explained, detailing its implementation steps and the supporting architecture, as depicted in Figure 1. This open-source mechanism is currently in the release process as a contribution to the ROS-Industrial stack, as part of the ROBIN project, funded as one of the FTPs of the European-funded ROBIN project. In the next section, a novel contribution to this mechanism will be introduced, allowing an easier development process, aimed at reducing development overheads. Furthermore, the following section will showcase some practical application scenarios, where the technology proposed in this article was tested, assessed and improved, in industrially relevant scenarios, on the scope of major R&D initiatives.
High-level architecture overview of the robotics bridge to industrial automation.
High-level overview
As previously discussed, the traditional method of allowing applications outside the automation domain to communicate with PLC or softPLC applications is through fieldbuses. However, as softPLCs are processes running on PC-based devices, the same system can support other software running in parallel. Therefore, it is possible to establish communication between non-automation applications and softPLCs through Inter-Process Communication (IPC) methods. This approach presents some advantages as well as some disadvantages when compared with network-based approaches. On one hand, IPC can outperform network-based communication, since data transmissions do not suffer from unnecessary overheads introduced by the necessity of routing data through all layers of a network as processes are running on the same machine. On the other hand, some interesting features introduced by networked transmissions are absent, such as data types compatibility or data access synchronization. Nevertheless, the developed bridge aims to tackle these limitations, in order to enable IPC between ROS and CODESYS using the POSIX shared memory library. POSIX shared memory objects are created in a virtual filesystem, in which data can be stored in a structured manner.
The developed approach relies on establishing bidirectional communication using an IPC method to explore the publisher–subscriber messaging pattern associated with ROS messages. The proposed bridging mechanism allows a ROS node to publish a message to a named topic, and have its content propagated to a shared memory location, that can then be accessed and read by the softPLC runtime application. Inversely, the softPLC application can write data to the shared memory location, which is then published as a ROS message on a named topic. Two independent interfaces were developed to achieve this bidirectional bridging mechanism, one on the ROS side and one on the softPLC side. Each interface is responsible for writing and reading data from the common shared memory location and receiving and propagating it to the processes that will use it. In addition, the developed approach implements a synchronization mechanism, based on a semaphore method to handle concurrent accesses to the shared memory. Due to these characteristics, the proposed bridging approach aims to be easily adaptable to either fit already existing robotic and industrial automation systems, as well as serve as a foundation for forthcoming horizontal integration efforts. By relying on the modularity and by having dedicated interfaces for transmitting and receiving data on both sides, the proposed approach aims to be effectively and easily applied to a multitude of use cases, platforms, and environments.
In the next two subsections, the developed bridging interfaces for ROS and CODESYS will be described in detail. Afterwards, the following subsection will focus on detailing the developed methodology for handling concurrent accesses to the shared memory data. Finally, the last subsection will address the necessary adjustments required for enabling data types compatibility between ROS and IEC 61131-3.
ROS interface
By relying on the ROS implementation of the publisher–subscriber messaging pattern, which enables communication between ROS nodes, the proposed bridging mechanism allows developers to rely on the most popular inter-node communication mechanism in ROS. 24 This way, developers can create or include in existing ROS packages the valuable feature of connecting with an external device via fieldbuses or industrial network protocols promoted by the softPLC bridge. From the ROS application point of view, this connection would be highly transparent, not only from a development point of view but also during runtime, as ROS nodes could communicate with the bridge mechanism without being aware that it is relaying data to/from outside of the system. Moreover, as a many-to-many data model is applicable to the publisher–subscriber messaging pattern, multiple ROS nodes can access and modify the data shared with the softPLC application. This behaviour is deeply similar and has been inspired by the Rosbridge middleware abstraction that facilitates the communication between ROS nodes and web-based technologies. 26
The ROS interface implementation is based on a created C++ template class. This class implements a set of fundamental communication and data handling procedures, and each instance of this class corresponds to a subclass which is directly associated to a ROS message type and its corresponding CODESYS compatible data structure. Data access to the shared memory is also handled by the ROS interface by using a semaphore-based approach, which is going to be detailed in a subsequent subsection. When an instance of this subclass is created, the name of the ROS topic is passed to its constructor method that uses this information to identify the ROS topic, the shared memory location and the corresponding semaphore. Then, after the instance has been created, another class method can be triggered to actuate the pipeline of operations required to route the data from/to the shared memory location to/from the appropriate ROS topic. This pipeline includes a set of operations which corresponds to the data type conversions between ROS types and IEC 61131-3 types, the data synchronization handler, and the processes to read/write data from/to the shared memory location.
In order to use the ROS interface for transmitting data between a ROS topic and the shared memory, developers have two options: (i) they could either manually invoke an instance of the previously described subclass, corresponding to the data type that they wish to transmit, or (ii) they could rely on the automatic code generator tool, to be detailed in the next section, which creates these interfaces automatically based on a YAML configuration file. In the manual option, developers can choose to either include the subclass in their own ROS nodes or, alternatively and preferably, create isolated nodes that are only responsible for handling this IPC method. By relying on the former alternative, other ROS nodes on the system can be completely abstracted and unaware that the information being subscribed or published to a topic is being transmitted to the softPLC application. In the automated option, the functional behaviour of the proposed bridging mechanism, after the creation of the configuration YAML file, resembles the previously mentioned Rosbridge behaviour, where developers can be abstracted from the internal data transmissions in lieu of simply publishing and/or subscribing to ROS topics in a standard fashion.
CODESYS interface
In contrast to the ROS interface, due to the unavailability of a publisher–subscriber messaging pattern in the IEC 61131-3 standard, a different approach was followed. As an attempt to provide the interchanged data to all programs on the automation project, the Global Variable Lists (GVLs), a component of the IEC 61131-3 standard that makes it possible to declare and use variables on all POU of a project was used. Inspired by the ROS interface implementation, two Function Blocks (FBs) were created to read (the subscriber) and write (the publisher) data from/to the shared memory for each ROS message type. By following this approach of having a dedicated publisher and subscriber in separate FB on the GVL not only simplifies the implementation of the IPC-based method using IEC 61131-3 programming languages but also makes the interchanged data structure available to be used by other programs within the same project.
The automation domain implementation relies on implementing on the subscriber and publisher FB a set of methods that, similarly to the ROS interface, trigger the initialization of the shared memory mechanism, the data structure creation to match the corresponding ROS messages, and the interaction with the semaphore-based mechanism to handle concurrent accesses to the shared memory location. In the current format of the implementation, FB methods have the task of creating the shared memory and the semaphore interfaces, while FB variables hold the semaphores information, the shared memory mechanism data, and the structure corresponding to the ROS messages.
Similarly to the ROS interface, developers have two options to apply the bridge mechanism on their automation applications. The first possibility is to manually add GVL, where the developed FB act as an interface to the shared memory location, a program to call the methods responsible for creating, writing and reading the shared memory, and, finally, a task to trigger the previously referred program in a periodical fashion. Another option is to rely on the recently developed automated project generation. Using this option, an automatic project generation tool uses the same YAML file referred in the ROS interface, to generate an IEC 61131-3 project (as an importable and PLCopen compliant XML file) that has been preconfigured to implement the specified data transmissions using the IPC method.
Data access synchronization
In order to avoid data corruption, it is imperative to synchronize the access to the shared memory. Therefore, as to keep data integrity, all the interactions with the shared memory must be coordinated by a semaphore-based mechanism. Using this approach, all access to the shared memory is preceded by a semaphore lock by the process attempting the access and immediately followed by a semaphore release, in order to allow other processes to access it. With this condition, an application attempting to access a locked shared memory will necessarily have to wait until the semaphore is released by the application currently accessing it, thus avoiding data corruption.
As the POSIX shared memory library does not have the synchronizing mechanism built-in, two approaches were followed, which resulted in the identification of the semaphore using a common string shared by both interfaces. On the ROS interface, an API for C/C++ of the Realtime Extension library of the POSIX standards was used to implement the semaphore-based data access synchronization. On the CODESYS interface side, two libraries compliant with the POSIX.1b standard provided by CODESYS were used. Thus, the
Data types mapping
ROS messages are mapped as strictly typed data structures, which can be composed of standard primitive data types, arrays and also nested structures. Fortunately, IEC 61131-3 also supports a similar data aggregation strategy, in which it is possible to group variables into C structures and map them to shared memory locations. Therefore, as POSIX also supports the transmission of data using structures, the interchange of information between ROS and the softPLC application is possible.
Nevertheless, the development team still had to face one issue, related to the incompatibility of data types between ROS and IEC 61131-3. As ROS message primitive data types are, in fact, mapped to C++ data types by the ROS C++ APIs, the challenge was to map C++ to IEC 61131-3 data types, which turned out to be straightforward for most cases. Yet, time-related variables and strings were some of the exceptions, which required the development of conversion mechanisms. Furthermore, multidimensional arrays with a non-defined length are still an open problem, due to limitations imposed by IEC 61131-3 when dealing with arrays of variable size.
Currently, most of the messages of the predefined ROS message libraries were already tested and are available to be used by developers, including (i)
Data transmission performance
Even though the feasibility and appropriateness of the proposed approach will be made clear in the application examples section, a meticulous data transmission performance measurement is still work in progress. Nevertheless, in order to quantitatively demonstrate its efficiency, a comparison was made using as a reference Modbus Transmission Control Protocol (TCP), a commonly used communication interface in industry.
The mentioned quantitative analysis compared the data transmission rate of both the Modbus TCP protocol and the proposed shared memory mechanism. To evaluate the transmission rate of Modbus TCP, 100 unsigned integers were stored in holding registers of a Modbus slave implemented in a C program, in the BBB, using the
Automatic code generator
As a direct consequence of the new production paradigms resulting from the industrial revolution, automation and robotic solution providers are being forced to cope with new challenges by automating the development process as much as possible. In the development of automation or robotic solutions, it is a common practice to rely on a set of frameworks, libraries or previously developed code to expedite some parts of the process. Nevertheless, there is often specifications or requirements associated with automation and/or robotics development process which undermines its full automation, or, at least, imposes a considerable development time and corresponding costs that have to be accounted for.
On the field of robotics, frameworks such as ROS help considerably to promote code reusability and make available a set of tools to aid the development process. Furthermore, being a community-based and mostly open-source system, developers have at their disposal a vast array of components and applications that can be rearranged and reapplied on different projects. In contrast, in the domain of automation, the development process is frequently less flexible. The existence of a set of tools that allows code generation for PLCs would reduce the development overhead and the design issues originated by manual implementations, thus increasing the robustness and productivity, while reducing costs. 30 Some authors have proposed approaches for automatic code generation, 31,32 however, truly applicable and universal code generation approach for PLC programming is non-existent.
To foster the utilization of ROBIN in an efficient manner, an automatic code generator tool was developed. This tool was developed having in mind the tenets and requirements associated with automatic code generation for PLCs. 32 In specific, the following properties were ensured: (i) modularity, as the generated code is composed of tested and self-contained FB; (ii) transparency, as the generated code abides by a well-defined structure, which can be easily interpreted by the user and by the IDE; (iii) scalability, as the generated code is structured in such a way that it can be easily expanded.
For this purpose, a YAML configuration file was conceived. Figure 2(b) displays an example of such configuration file. This file acts as an input to the automatic code generator, that by using a template engine outputs a valid XML file that is compliant with the PLCopen XML notation, as defined in the IEC 61131 standard. The proposed approach is valid as many softPLCs, such as CODESYS, support the import of projects specified in this notation.
Automatic code generator: (a) Example configuration YAML file for the automatic code generator; (b) subset of a PLCopen XML template structure. For readability purposes, only the relevant XML tags are represented.
The YAML configuration file is parsed by the code generation application, developed using the Python programming language, and the parameters for the project name, IEC 61131-3 programming language, and the information of the ROS message structure to be read and written are obtained. With this information, it is possible to retrieve or construct the necessary XML excerpts corresponding to the individual PLCopen compliant objects. This XML excerpts are then introduced into a PLCopen XML template file, represented in Figure 2(a), using a template-based engine.
The concluding PLCopen XML file for the proposed bridge mechanism is, therefore, organized in the following way: (i)
Thus, the output PLCopen project generated contains both the structures, FBs, methods, variables and programs necessary to read or write ROS messages, as specified in the YAML configuration file. The same principle can be applied to the ROS software layer. The same YAML configuration file is used to include only the subclasses associated with the corresponding ROS messages to be transmitted. On the ROS side, the tool generates a set of ROS nodes that are then capable of instantiating the aforementioned classes, and successfully parse and relay the information to the shared memory location. By default, the generated nodes publish the content of a given ROS topic when there is a new message published to it, and attempt to retrieve novel information from the shared memory location periodically. Nevertheless, developers can easily alter the generated code to better suit their needs.
Application examples
ScalABLE4.0 mobile manipulator
For the purpose of application in the H2020 ScalABLE4.0 project, a collaborative mobile manipulator that could be easily integrated into existing production lines is being developed (Figure 3(a)). The manufacturing companies in the project’s consortium, PSA Peugeot Citroën and Simoldes Plásticos, provided a use case each, resulting in the need for two different (although very similar) versions of the system, whose objectives and requirements will be further detailed.
Application platforms: (a) H2020 ScalABLE4.0 mobile manipulator; (b) H2020 FASTEN mobile manipulator.
For the Simoldes Plásticos use case, the mobile manipulator will be responsible for picking and placing recently injected automotive plastic parts from a conveyor and packaging them into boxes for automotive manufacturers. These boxes will be temporarily stored and carried to a logistic supermarket by the robot itself. For this purpose, the mobile manipulator has to interact with the conveyor automation system, controlled by an external PLC, as to be informed on the presence of recently injected components to be packed. Furthermore, to support the coexistence of a group of human operators in the vicinity of the robotic system, the mobile manipulator has to be fully compliant with human-robot collaborative performance.
The major applications within the system are being developed using ROS, which, as previously discussed, is still limited in areas such as the implementation of up-to-date fieldbus-based communication with automation equipment and hardware devices. On the other hand, PLC development environment provides high-level and up-to-date packages to easily establish communication with the majority of fieldbus networks available in the market. Thus, by relying on the proposed bridging mechanism, it was possible to take advantage of the best features of each domain: on the ROS level by relying on the high-level application development environment using object-oriented programming languages for robotic purposes, and on the automation level by entrusting in the effective establishment of communication via fieldbuses with hardware devices.
The design and development of the mobile manipulators are following a full modularity approach, decomposing the robotic system into modules. Two main modules are being considered for the mobile manipulators in development: (i) the mobile module and (ii) the manipulator module. The following subsections will detail each module, raising awareness of the application of the proposed bridge to establish interoperability between the robotic and automation domains. In addition, the last subsection will present the horizontal integration achieved between the mobile manipulator and the PLC controlling the conveyor system.
Mobile module
The mobile module was further divided into five submodules: (i) the actuator submodule (drive wheels, gearbox, motor, controller, and suspension); (ii) the sensor submodule (safety lasers); (iii) the power submodule (batteries with management system and power converter); (iv) the signal submodule (industrial PC, PLC and I/O modules); and (v) the structural submodule (structure and caster wheels). For the scope of this article, the actuator and power submodules will receive particular attention, due to their communication interfaces requirements.
Within the actuator submodule, a differential drive mechanism was chosen for the mobile platform, relying on two brushless DC motors. The selected motor controllers communicated through the EtherCAT fieldbus system, which motivated the usage of the proposed bridge. In what regards the power submodule, lithium (LiFePO4) batteries were chosen as the power source, due to their higher energy density, longer service life and stable chemistry. A Battery Management System (BMS) was used to monitor the state of the batteries and there was the necessity to propagate the charging level and other battery information to ROS topics, which motivated the application of the proposed interoperability methodology. As it will be clear, the development process relying on the proposed methodology was straightforward, allowing for an effective, sustainable and intuitive interchange of data between both domains.
Two software interfaces were developed to handle the communication between ROS and the BMS, and the communication between the high-level navigation software, developed in ROS, and the motor controllers. On the automation development environment, a modularity approach was followed, as FB that encapsulate specific properties and functions of the real-world components (i.e. the motor controllers and the BMS) were created. Furthermore, the bridging methodology was configured, mapping the variables to be extracted and propagated to the shared memory location, for each module. On the ROS environment, the process was even simpler. After setting up the ROS topics and corresponding shared memory locations using the developed mechanism, the only step left to achieve interoperability was the remapping of existing ROS applications’ topics to match the ones configured in the previous step. The following subsections will present in detail the approaches followed for the BMS and the motor controllers.
Battery Management System
The state of charge of the batteries of the mobile module has to be monitored to avoid running out of power during a task. Instead, the platform should automatically go to a charging station when required and available. For this purpose, as the trigger for this automatic behaviour needs to come from the ROS system, this information needs to be propagated all the way from the BMS to the ROS environment. The instantaneous current consumption also has to be monitored, in order to detect abnormally high currents that could reveal system malfunctions and to also avoid draining the batteries too quickly. Other parameters such as individual cell voltage levels and daily energy consumption were also mapped.
The manufacturer of the selected batteries for the mobile module provided a BMS that could be used to manually inspect these and other parameters. The system also had a Universal Asynchronous Receiver-Transmitter (UART) serial connection available, meant to be connected to a module, sold separately, that could communicate via Controller Area Network (CAN) bus with other devices. However, there was a possibility that this serial connection could also be read directly by the BBB, already running the CODESYS runtime and the ROS environment.
The manufacturer provided the electrical schematic of a circuit, based on an optocoupler, that both isolated and inverted the signal output by the BMS, returning a signal that could be read by the BBB. A document with the communication protocol used was also provided, containing the communication settings and the structure of the string of data that was output by the system. Therefore, an interface was implemented as a FB to read these parameters through the serial port of the BBB and provide them to ROS through the developed bridge. Figure 4(a) depicts the architecture of the developed interoperability.
ROBIN interface diagrams for the considered industrial application examples: (a) Battery management system; (b) motor controllers; (c) manipulator controller; (d) conveyor system; (e) laser-based safety zone commutation.
Motor controllers
The H2020 ScalABLE4.0 mobile manipulator has a localization and navigation software layer based on ROS. As the mobile manipulator’s motor drivers communicate via the EtherCAT protocol, its integration with ROS could be facilitated by the developed bridge. The interface diagram is represented in Figure 4(b).
Thus, the developed mechanism was used to pass velocity commands for all motors and to read information from the corresponding encoders. These velocity instructions consist of two
Manipulator module
The manipulator module encompasses the structural and electrical submodules for supporting the manipulators and controllers and corresponding electrical and communication interfaces. Two different manipulators were selected, according to each use case. For the SP use case, a Yaskawa HC10 collaborative robotic manipulator (with a payload of 10 kg, and reachability of 1200 mm) was employed.
The existing drivers and interfaces for enabling the actuation of the Yaskawa HC10 robotic manipulator did not allow a ROS application to directly issue movement commands and receive updates on the position of the robot. Therefore, as the movement of the HC10 manipulator could be monitored and controlled by an external device through the Modbus communication protocol, the bridging mechanism was employed. Figure 4(c) presents the conceptual schematic of the proposed interoperability interface.
Four ROS topics were used in this interaction. One ROS topic, /
Horizontal Integration with a conveyor system
To allow the mobile manipulator to be aware of the presence of recently injected plastic parts to be packed, the industrial conveyor is equipped with a set of photoelectric sensors. The sensors are also used to actuate the movement of the conveyor, in such a way that the conveyor is stopped if there is not any part detected, and it is moving if the recently injected parts need to be transported to the shop floor location where the mobile manipulator needs to perform its task. Additionally, the sensors are used to issue a stoppage command to the conveyor if the part to be packed is in front of the robot. This conveyor system logic is controlled by a SIEMENS PLC that communicates with the CODESYS softPLC running on the embedded device via Modbus. Through the application of the developed bridge, the mobile manipulator can receive the information of a new part arrival at the designated conveyor location and can also communicate the success of the packing procedure. The interface diagram of this horizontal integration mechanism between two different CPSs is depicted in Figure 4(d).
FASTEN mobile manipulator
An omnidirectional mobile manipulator is being developed for one of the use cases of the H2020 FASTEN project. In the use case, promoted by the aerospace manufacturer Embraer, the mobile manipulator operates in a logistic warehouse. The main objective of the robot is to create and deliver logistic kits of parts required by the wing assembly production line. The major scientific focus of the demonstrator is to create a collaborative and adaptable robotic platform that is capable of sensing, recognizing, localizing and grasping parts of different morphology, assemble a logistic kit and transport it to the production line. For accomplishing this task, the robot is required to interact with an automated warehouse, as to retrieve the containers storing the parts that will compose the logistic kit.
The design and development process of the H2020 FASTEN mobile manipulator follows a similar strategy to the previously presented mobile manipulator. The system can also be decoupled into a manipulator module and a mobile module, the former being composed of a Universal Robots collaborative manipulator with a gripper and 3D-based perception system, and the latter being composed by a custom-made omnidirectional traction system.
Laser-based safety zone commutation
To be able to retrieve components stored inside the automated warehouse, and due to the reachability restrictions of the system, the robot needs to approximate itself to the automated warehouse. This requirement imposes the challenge of having to alter the laser security zones, which are configured to safely stop the movement of the robot if an obstacle is detected. Two SICK laser scanners guarantee that there is always a configurable safety area around the mobile manipulator, capable of detecting obstacles in the robot’s surroundings. This safety area can be scaled and adapted to match the velocity of the robot since a fast-moving robot requires a larger safety zone than one that is moving slowly. The project specifications relative to the docking process also lead to changes in the safety area’s shape, since it is performed at a slow speed and at a few centimetres from the automated warehouse.
To dynamically change the shape of the laser-based safety area, an I/O module was included in the system to alter the configuration of the safe PLC that directly communicates the lasers. The I/O module, on its turn, can externally communicate using the EtherCAT protocol. Therefore, to easily reflect location and speed information from the ROS layer to the configuration of the lasers, the proposed bridging mechanism was used. In this scenario, the I/O module receives from ROS a set of commands to alter the shape of the safety area to be used (/
Conclusion and future work
The approach described in this article for developing an IPC-based method for establishing bidirectional, reliable and structured communication between ROS and CODESYS, allowed interoperability between robotics and automation systems. An automatic code generation module for diminishing development overhead and, thus, promoting the usage of the mechanism is also proposed. Additionally, the article presents a set of real applications in a multitude of scenarios, platforms and industrial use cases attesting the relevance and practical applicability of the proposed mechanism.
Future work for the bridging mechanism is aligned with the objectives of the ROBIN project, a FTP of the European-funded H2020 ROSIN initiative. After the release of the bridging mechanism as an open-source component, under the ROS-Industrial umbrella, the initial immediate focus is to promote and gather feedback from the community usage of the software. Support consists not only of addressing issues, implicitly helping developers and improving documentation, wikis and tutorials, but also to improve the automated testing pipeline, with the objective of having a truly fully-fledged continuous integration strategy. The initiative will also promote the test and validation of the developed bridge using different hardware, and porting the bridge mechanism to other applicable embedded devices (such as the Raspberry Pi). Furthermore, to speed up even further the integration process, a common ontology will be researched, proposed and integrated into the bridge for promoting the reutilization of common functionalities in robotic hardware and automation equipment. In particular, this innovation will create a set of elemental properties of hardware modules and connect them with existing ROS standards and common practices for hardware integration, with the objective of further simplifying the integration. A specific example would be the polymorphic behaviour obtained by grouping common robotic grippers inheriting from a single elemental class, further deriving each gripper type according to the specificities of the hardware being used (suction, fingers, etc.), and, thus, reutilizing common functionalities or properties. This would allow a developer trying to integrate novel hardware systems to easily have basic functionality and the foundation for the creation of the integration mechanism. Finally, there will also be a focus on assessing and validating the developed system to provide ROS platforms with the capability of utilizing softPLC tools, such as the CODESYS SOFTMOTION for motion control in time-constrained applications, further expanding the concepts already addressed by this article.
Footnotes
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The research leading to these results has received funding from the European Union’s Horizon 2020 – The EU Framework Programme for Research and Innovation 2014–2020, under grants agreement nos 723658 and 777096.
