Interfacing the Control Systems of Enterprise-Level Process Equipment with a Robot Operating System

Abstract

The analytical section of this paper deals with theoretical knowledge, considering the latest trends in the subject area. To achieve the successful implementation of cobots based on operating systems in manufacturing systems, it is necessary to pay attention specifically to the interfacing of Robot Operating Systems with the control systems of manufacturing systems at the process level of an enterprise. In the practical section, an algorithm with well-defined steps towards the successful implementation of cobots in holonic manufacturing processes is proposed. By setting up an experimental workstation in a laboratory, the proposed procedures are verified at the end of the paper. The creation of a design for the implementation of a collaborative robot with a human represents the missing link in the whole chain of commercial applications of the latest trends from the field of robotic systems in the industrial sphere. The main contributions of this study include the establishment of a communication channel between cobots and programmable logic PLCs (Programmable logic controllers), and an experimental verification of the proposed solution for the implementation of a cooperating robot with a human in a manufacturing system in the laboratory. Another advantage of this paper is the creation of a new procedure for conducting a risk analysis of cooperating robots and multipurpose autonomous devices.

1. Introduction

In recent years, the emergence of new industrial technologies has been visible. These necessarily include cobots capable of working alongside humans. In many cases, manufacturing companies, to innovate and be competitive, turn to such robots. The number of successful implementations is still low despite this huge interest. One of the reasons for this may be precisely the lack of a methodology for implementing cooperating robots in holonic manufacturing systems.

Traditional industrial robots are designed to operate in isolation from humans, with minimal physical interaction between them [1]. This contradiction motivated designers to develop the new generation of collaborative robots (cobots) that are able to share a workspace with human operators [2,3,4,5,6].

One of the main factors to consider when designing a robotic workplace is the ergonomics of the cobot. The latter primarily pursue humane and economic goals. By implementing robotic cobots at the process level, we can achieve certain ergonomic goals, but their applicability in industrial production has not yet been sufficiently explored.

Regardless of the specific task performed, robots are designed to support humans. Consequently, by introducing cobots into workstations, it is necessary to consider ergonomic requirements in their implementation. Thus, it is not possible to discuss robots without considering them in relation to humans. Adopting a human’s point of view allows one to foresee the user’s needs, behaviour, and sensations during the interaction with robots and improve workers’ physical well-being and safety [7,8]. This theoretical review includes an analysis of the use of conventional industrial robots, which clearly shows an increasing number of units sold annually. According to the above statistics, by a clear margin, the highest sales are for the automotive industry. The justification may be in series production, where the robot is in operation almost continuously. In this case, the payback period for the investment is sometimes within half a year to a month. In manufacturing companies with batch production, the use of conventional industrial robots is therefore advantageous. The situation is different in piece production. The return on investment is not as fast as in batch production, and therefore, manufacturing companies do not consider acquiring conventional robots in many cases.

Humanoid robots are expected to work in environments structured for humans [9]. While collaborative humanoids are beginning to gain traction in manufacturing, their employment in other circumstances is still in its infancy [10]. Predictions of the usability of robotic workplaces in the coming years show a high increase in the deployment of robotic workplaces, bringing many benefits [11,12,13]. These are workplaces using both conventional industrial robots and robotic cobots. The use of cobots offers new opportunities in companies with small batch or piece production, which has an impact on the above estimates of robot sales in the coming years.

2. Literature Review

Many global manufacturers of industrial robots are aware of the increase in the requirements of enterprises in the new area of cooperation and are, thus, responding to the market with new developments of robots capable of cooperation with humans. The creation of a design for the implementation of a cooperating robot with a human represents the missing link in the whole chain of commercial applications of the latest trends in the field of robotic systems in the industrial sphere.

Human–robot cooperation in classical industrial robots and in specialised cobot cases still demands an intensive introduction into these industries. However, in this case, the introduction involves nontechnical aspects such as human psychology and personal acceptance of the robots in workplaces. Another aspect of the subjective attitude to robots is limited by their acceptance by managers and process designers.

Many automation cases are still limited by artificial intelligence (AI) issues related to object recognition, object position recognition, and decision generation for object grabbing and manipulating. This issue arises from the process of widening robotic implementation in existing industries, and therefore, many technologies should be redesigned. Nevertheless, pressure due to the absence of a skilled labour force has led to new solutions. Many general solutions using machine vision and sensor fusion have been spontaneously implemented in numerous industrial enterprises [14].

The deployment of a cobot in an enterprise depends on the specific situation and needs of the enterprise [15]. Before deploying a cobot in an enterprise, it is important to perform an analysis of the processes to be automated. It is necessary to determine exactly which steps in the process can be performed by the cobot and what the requirements are for adapting the production process [16]. Deploying a cobot also usually involves training the personnel who will be working with the cobot and ensuring the necessary safety precautions are in place [17]. When deciding whether to deploy a cobot in an enterprise, the advantages and disadvantages of such a move should be weighed. Cobots can increase productivity and improve the quality of production, but they can also impose high upfront costs and may require modifications to existing processes [18].

Research robots can be considered the most cognitively controlled of all robots, but even they still do not achieve a high degree of autonomy and, therefore, a certain degree of intelligence. Industrial robots currently achieve minimal cognitive control, i.e., they achieve a low degree of intelligence and can be considered those that are the most equipped with cognitive control among all robots, but even these still do not achieve a high degree of autonomy and thus a certain degree of intelligence. The industrial robots of today achieve a minimum of cognitive control, reaching a low degree of intelligence [19]. Hierarchies, for instance, allow for the compartmentalization of tasks: if organized correctly, tasks in disjoint subtrees of the hierarchy may be performed in parallel. Intuitively, the shallower the hierarchy, the more subordinates per manager, leading to more potential for parallelism [20].

In the literature, the term industrial robot refers to devices that can independently solve various manipulation tasks [21]. Currently, although an industrial robot is defined according to ISO, there are several other definitions with different interpretations, but they all have the same essence. An industrial robot is officially defined according to [22] to mean a reprogrammable, multifunctional manipulator designed to move material, parts, tools, or specialized devices through variable programmed motions for the performance of a variety of tasks.

Apart from basic terminology, the WG 1 standard is ISO 9787 [22]; WG 1 deals with another vocabulary for certain domains, such as navigation or perception, and was published in ISO 19649 [23]. The standard defines terminology for mobile robots, such as the definitions of wheel types and undercarriage structures. During the last meeting in Suzhou, China, WG 1 started the revision of ISO 8373 [24].

The chair of WG 2 is Osman Tokhi (London South Bank University, United Kingdom). The standard WG 2 includes the following:

• ISO 13482, ISO/CD TR 234821, ISO/CD TR 234822 [23].

WG 3 deals with the safety of industrial robots. After the technical specification ISO/TS 15066 [23], which provides extended requirements for human–robot collaboration and specifies limits for impact forces and pressures, WG 3 developed two new work items.

WG 4 engages with developing standards for robot performance. To compare the performance of functions like pathfinding, object recognition, or the ability to move on difficult terrain, standardized test methods are necessary. According to WG 5 (Medical Robot Safety), other than industrial robots and (nonmedical) service robots, robots used for healthcare purposes have to fulfil safety requirements for medical devices instead of or in addition to requirements for machinery safety. During the last meeting in Suzhou, China, WG 6 finished a series of changes originating from the new work item balloting and prepared a document for the committee draft ballot. Robotics is evolving from its industrial manufacturing roots at an increasing rate, and new robot use cases are emerging [25].

It is also worth mentioning that despite the general public’s (and official bodies as well) increasing support for sustainability in the development of robotic applications with regulations [26,27], the appropriate guidelines for streamlined implementations are still missing [28].

In general, the ability to easily retrain a cobot for a new kind of task is seen as one of its main advantages. However, this feature is not addressed in the current state-of-the-art standards. Risk analysis is starting to be insufficient for new autonomous technologies such as cobots, because individual risk analysis methods do not consider, for example, the level of autonomy of the technology, the ability to make autonomous decisions, the ability to move and navigate in space, etc. The development of a new approach to risk analysis would be particularly useful for reconfigurable systems and therefore for the frequent changes in production for which cobots are adapted. Therefore, in this paper, attention is also paid to this area.

One of the key benefits of cobots is their ability to work alongside human workers, allowing for more efficient collaboration and communication. This can help to improve overall productivity and reduce the risk of workplace injuries. Additionally, cobots can help to automate tasks that are too dangerous or physically demanding for human workers to perform, such as lifting heavy objects or working in hazardous environments.

According to the International Federation of Robotics (IFR), global sales of industrial robots have been increasing steadily over the past decade. In 2020, despite the COVID-19 pandemic, the IFR reported that worldwide shipments of industrial robots reached a record high of 373,000 units, an increase of 3.5% compared to the previous year. Asia continues to be the largest market for industrial robots, accounting for around two-thirds of global sales. The automotive industry remains the largest user of industrial robots, followed by the electronics industry. However, there is growing demand for robots in other industries such as healthcare, logistics, and agriculture. The IFR predicts that global sales of industrial robots will continue to grow over the next few years, driven by technological advancements and increasing demand for automation and productivity improvements.

The stock of operational robots around the globe hit a new record of about 3.5 million units—the value of installations reached an estimated USD 15.7 billion. The International Federation of Robotics analysed the top five trends shaping robotics and automation in 2023 (Figure 1).

The industry statistics presented in the following World Robotics 2022 Industrial Robotics report provide the strongest indication to date that robotics as a technology is making a fundamental contribution towards supporting industries and businesses to immunize their core production processes against the outcomes of each global crisis we experience. Despite all global headwinds and the continued presence of the pandemic, a record 517,385 new robots were installed across all industries in 2021, a significant 31% higher than in 2020, with the electrical/electronics, automotive, and metal industries continuing to be leading adopters of the technology. Global robot stocks reached almost 3.5 million units, 15% higher than in 2020, and the associated value of installations reached an estimated USD 15.7 billion, with a global average manufacturing density of 126 robots per 10,000 employees.

Hence, how to design appropriate robotic mechanism systems, motion planning, and control, and how to integrate the complementary devices and technology into a flexible automatic system are still hot robotic research topics. Since robotic manipulators are multi-input and multioutput systems, their motion planning and control are complicated operations [29]. Standardization allows researchers to combine work from multiple sources without having to spend time creating bespoke adaptors or recreating incompatible work [30]. Recent soft robotic research has been mostly bioinspired to synthetically reproduce the functionality demonstrated by worms, octopuses’ arms, and other model animals. These results rely on new soft actuation technologies, and hence focus more on the design, fabrication, and analysis of actuation performance, providing a solid foundation for further research on challenges blocking complete robotic systems that include power sources, driving hardware (valving), perception, computation, and actuation [31].

The term holon was first coined by the Hungarian writer and philosopher Arthur Kestler [32,33]. At first, it was considered to describe the whole/part of nature in a real-life system; one can say that a holon is both a whole and a part [34]. At the same time, the concept of a holon is often considered an application module that is both “autonomous” and “collaborative” in the system [35].

Distributed intelligent manufacturing can meet these requirements. The more traditional sequential and centralized solutions, used within the scope of such agile environments, do not work since they are slow to react, impose operational bottlenecks, and are a critical point of failure [36]. Indeed, in the literature on holonic systems, little attention has been paid to software models and methodologies. This happens despite the fact that computing with granular information in Software Engineering has been attracting the interest of scholars in the Computational Intelligence sector [37] for almost a decade. In particular, the newborn field of Granular Computing is currently dealing with the issue, for example, of linking [38].

3. Materials and Methods

The main goal of this study is a proposal for the implementation of cooperating robots in production systems, while the facts known so far indicate the need to connect Robot Operating Systems with control systems at the process level of the company. The subgoals include:

• The design and implementation of a communication channel between ROSs (Robot Operating Systems) and PLC control systems;
• The proposal of a new approach to the creation of a risk analysis of robotic workplaces.

As robotic systems are becoming more prevalent today, where autonomous systems are interacting with humans, the need for securing these systems is becoming paramount. Historically, industrial robots were mostly used in the manufacturing environment, where they were protected by walls and closed networks [39,40,41].

For the implementation of cobots in production systems and their cooperation with production equipment, it is necessary to create a communication channel, the design of which is part of this case study. The design and solution will result in the interfacing of the Robot Operating System with the production facility control systems (PLCs) (Figure 2).

At the top layer of the high-level control (HLC), there is communication between agents for negotiation, ordering or cooperation with other agents, etc. At the lower layer, communication takes place between the agents to exchange process data such as information from a sensor about the presence of a pallet, a conveyor belt in motion, and so on.

3.1. Assumptions for the Implementation of Cobots in Production Systems

One of the assumptions for the successful implementation of a cobot into a production system is the creation of staffing, and thus, it is necessary to fill professional positions with qualified personnel. A lack of preparedness can result in inappropriate decisions and therefore the need for skilled personnel involved in the implementation of cobots in a manufacturing enterprise.

By process, we mean a set of activities that transform inputs into outputs (for example the assembly process and welding process). Knowledge of robotic systems is taken for granted. In the case of insufficient theoretical knowledge or practical experience in the field, the wrong selection of a suitable process or suitable cobot may occur. The correct identification of suitable processes is one of the prerequisites for the successful implementation of cobots in manufacturing systems.

When implementing cobots in production systems, it is necessary to define the following technical assumptions:

• A suitable cooperating robot and control system (cobot);
• The design of a suitable effector for the cobot.

3.2. The Incorporation of Robotic Systems into the Process Level of the Company

If the assumptions in Section 3.1 (establishing staffing, the identification of potential processes for automation, and technical assumptions) are accepted and fulfilled, cobots can be deployed in any production system, regardless of the level of automation or the size of the production enterprise. The scientific problem lies in the communication of the Robot Operating System (ROS) with the PLC control systems. The ROS is an open-source framework that provides the easy integration of components into the robot [31].

Within the enterprise information system, the above technologies are located at the process level of the enterprise. A cobot implemented in a production system must be able to cooperate not only with humans but also with production and other equipment. The intention is to achieve the highest possible degree of cobot autonomy. Holonic manufacturing systems define a holon as an autonomous and cooperating unit [32]. Therefore, we propose a holonic systems theory to be used to describe the communication of the cobot with the devices of the production system.

3.3. Holonic Manufacturing Systems

In many industries, production machines and production lines are composed of modular equipment. Individual modules can be placed in the production line at different locations as required. By using modular systems, the required flexibility of production systems is achieved. The modules are controlled by their control system (PLC, embedded systems, etc.), which controls and operates the elements inside the module, such as pneumatic devices, electrical drives, sensors, etc.

Modular systems inevitably need some type of industrial network (Ethernet, Fieldbus, or IO-link) to communicate between the modules and exchange the necessary information. Holons and holarchies made up of holons can work independently, implying that they have a certain degree of intelligence and can solve problems from their particular level without asking higher levels for help. This property ensures that holons are stable and systems are consequently more reliable. Holons can also receive instructions and be controlled by a holon from a higher level [42,43].

The holonic production system (Figure 3) is based on the concept of the holonic system defined by Arthur Koestler [44]. In the holonic production system, holons are considered operators of control processes, acting autonomously. Koestler emphasizes autonomy, which determines to what extent the system is intelligent and to what extent the system can react to faults and resolve them independently without the intervention of a superior holon. At the same time, however, such holons can be controlled and managed by higher-level holons. Thus, an intelligent manufacturing system can be thought of in holonic terms as an entity composed of autonomous modules (holons) with distributed control.

In the artificial intelligence (AI) field, holons have been thoroughly studied in resemblance to agents [45]. In particular, a comprehensive comparison between the two models was presented in [46]. One of the greatest differences is that the holon is structurally recursive, while the agent is not. Furthermore, holons generally account for both information and physical processing, while agents are more often viewed by the AI community as software entities only.

A hierarchy composed of holons, possibly a system of holons located throughout a system of roles, is called a holarchy. This concept can be used to create complex systems, based on the premise of folding elementary parts into increasingly complex units or decomposing the system into smaller functional units [47].

For a thorough description of the proposed structure, we suggest the use of the IEC 61499 standard [47]. In our case, the solution deals with the description of the interfacing of the Robot Operating System of the cooperating robots with the control systems at the lowest level of the enterprise (PLC, CNC, and others). Therefore, the above standard will only serve to formally describe the proposed solution.

The definition of a function block according to IEC 61499 also specifies the link between events and their associated data [48]. An agent must respond to significant changes in its environment; for example, a robot playing soccer has plans based on the current position of the ball and other players, but must be prepared to adapt or abandon plans based on changes in the environment. Moreover, agents are persistent, that is, they try to accomplish their goal even after failed attempts [49].

3.4. The Architecture of the Holonic Agent

When considering the application of agents and their deployment in production systems, it is imperative to consider the possibility of interfacing directly with the hardware equipment at the lowest enterprise level in production. Such hardware, meaning, for example, PLCs, CNCs, and others, is considered real-time systems. Agents are not capable of real-time response, and this leads to the emergence of a new architecture referred to as the “holonic agent architecture”. The above solution is proposed as a suitable option to design the communication structure of autonomous devices.

As can be seen in Figure 4, it is a loose coupling of the upper HLC layer (agent) and the lower LLC layer (hardware—PLC, CNC, and others) together with the communication interface required for data exchange between the LLC and the HLC [50].

The LLC module is considered a standard control program in the PLC, whose cycle is as follows: First, it reads input values from input cards, whether digital or analogue, or reads information coming through the communication interface (Ethernet, IO-link, etc.). The control unit performs the necessary calculations and, according to the predefined logic in the program, sets the values for the PLC outputs of the automaton, thus providing the required signals for the actuators.

The programming of programmable logic PLCs for holonic manufacturing systems is described in the IEC 61499 standard. This is programming using function blocks whose data are processed based on events. This standard should replace today’s established way of programming according to IEC 61131-3. Despite the different opinions on which programming language is more convenient, more readable, and more acceptable for the user, nowadays, programming according to the IEC 61131-3 standard [51] is consistently preferred, with the first-mentioned method being used mainly in laboratory conditions.

The HLC module is represented by an “agent” that satisfies all the properties of agent management. It is software that can make decisions, communicate, or cooperate with other agents. In this sense, we can say that HLC is synonymous with the word agent. To program a complex agent solution with all the necessary features, one of the higher programming languages such as C++, Java, and others is required [50].

The IEC 61499 standard will serve us in this thesis to describe the behaviour of holonic agents in society, in addition to clarifying the basic principle of programming according to that standard. In the research in question, this involves the use of function blocks, with the header of the function block itself being the upper layer of the HLC or, therefore, the software representing the agent. The body of the function block is characterized by the lower layer, which is represented by hardware such as PLC, CNC, and others.

An essential part of the holonic agent as a system is the communication interface between the upper layer of the HLC and the lower layer of the LLC. On the one hand, the HLC receives notifications from the lower LLC layer regarding relevant events that are in the agent’s interest to receive. This includes information such as the completion status of a particular task being performed, the device status of ready or busy, diagnostics informing of impending system failure, insufficient material flow, and a variety of other necessary data. On the other hand, after the agent decides to perform a given action, the result of the decision needs to be sent to the lower layer of the LLC, where the received information from the HLC is usually translated into simple basic data types that are further processed by the LLC hardware. As an example, consider a decision made by an agent after negotiating with other agents to participate in the transport of parts from the warehouse to the conveyor belt.

The agent then sends an order based on the negotiation and agreement made, such as “Unload material from the warehouse and move to the conveyor belt”. The LLC receives the given information from the HLC and translates the command into a series of simple commands such as “Take material from the warehouse from position x, y”, “Put material on the conveyor belt”, etc., based on predefined conditions or data from the surrounding production environment [52].

At the top layer of the HLC, there is communication between agents for negotiation, ordering or cooperation with other agents, etc. At the lower layer, communication takes place between the agents to exchange process data such as information from a sensor about the presence of a pallet, a conveyor belt in motion, and so on.

An important aspect of reliable holonic agent functionality is the correct choice of hardware. A normal and established method is to separate the HLC and LLC layers, with the upper layer being represented by software on a computer, while the lower layer is implemented in a control system such as a PLC, CNC, or microcomputer, etc. However, problems can arise with such an architecture with issues of reliability of operating systems, the hardware of individual devices, communication between HLC and LLC layers, and so on. In addressing these issues, several companies have responded (Rockwell Automation is an example), resulting in the emergence of new architectures where both the upper HLC layer and the lower LLC layer are part of the same hardware. As we mentioned in the section on programmable logic controllers, PLCs are one of the most used control systems in the industry at the process level of the enterprise. For that reason, research and testing are underway into the possibility of deploying both layers within a single PLC by uploading a newly modified firmware to one of the series of programmable logic automata being produced. This opens up the possibility of programming the agents in one of the higher-level programming languages (C++, Java, etc.) along with programming the lower layer with the existing IEC 6113 standard [53] on one common PLC hardware.

4. The Design of a Risk Assessment of a Robotic Workplace

In the robotic world, a risk assessment is used to identify potential risks, with one of the next steps being to reduce them to an acceptable level. According to ISO standards, all mechanisms must undergo a risk assessment to designate a device or machine as safe. However, it is also important to note that many mechanisms are already certified directly by the manufacturer at the time of manufacture, which facilitates our risk assessment process. However, even though the components that make up a cobot or its software are certified and labelled as safe, this does not mean that the robot is safe about its environment. Especially in the case of industrial applications, it is almost impossible for robot manufacturers to declare that a cobot will be safe once incorporated into any process. It is only after the estimation and assessment of all the risks that we can determine with certainty that a robot can be declared safe. An example is the handling of a sharp object by a certified cobot. Although the robot is considered safe, the application as such is far from safe. Despite all the certificates from the cobot manufacturer, it is therefore imperative to reassess the risks and then minimize them. The algorithm (Figure 5) illustrates the process leading to a successful risk assessment along with recommendations for minimizing the risks. Some shortcomings in the current risk assessment approach were identified, and therefore, a new perspective is proposed on risk identification and risk level determination.

The individual parts of the algorithm are described in more detail in Section 4.1, Section 4.2, Section 4.3, Section 4.4, Section 4.5, Section 4.6, Section 4.7 and Section 4.8.

4.1. Definition of the Parameters of the Proposed Workplace

When assessing the risks, the first and essential step is to define all the necessary parameters of the proposed robotic workplace. We can help ourselves by asking the following questions. What effector will the robot use? What will be the robot’s main task? In the case of handling operations, what object will be handled? Asking such questions ensures that there are the necessary data essential for a thorough and detailed risk assessment. At that stage, it should be obvious what type of robot will be used in a given application. Therefore, it is necessary to study the manufacturer’s datasheets and find out, for example, the maximum speed, acceleration, maximum payload, etc.

4.2. Identification of Sources of Risk

This step requires the identification of all possible risks. It is important to note that this identification process applies not only to the operations themselves, such as handling, welding, packaging, etc., but to all operations from the moment of purchase of the individual components or technologies and their receipt from the transporter to the actual disposal of the entire proposed site. The mere improper unloading of a few dozen kilos of the robot from a truck or the commissioning of a given robot without expert handling, etc., can result in injuries. Pointing out these potential risks during installation may seem unimportant, but safety experts warn that the process of identifying the sources of risk is often underestimated, and on many occasions has already ended tragically during the actual installation of the robot into service. Once thoroughly identified, some analysis should result, which is then needed in the next step to determine the level of risk.

4.3. Determining Risk Levels

A list of the main significant risks arising from the use of industrial robots is contained in ISO 10218-1. The application of collaborative robots may give rise to ancillary risks that need to be identified—International safety standards for industrial robots include ISO 10218-1 and -2 [54] and ANSI/RIA R15.06 [54]. These standards describe hazards associated with industrial robots and provide guidelines for eliminating or reducing risks associated with those hazards. International safety standards for cobots include ISO/TS 15066 [23] and ANSI/RIA R15.606. These standards provide important information on how to implement a collaborative robot system in a way that maintains safety for the human collaborator. Some jurisdictions have also included requirements for robots in their health and safety legislation. For example, Alberta’s Occupational Health and Safety Code requires industrial robot systems to comply with CSA Standard CAN/CSA-Z434-03 (R2013) and sets specific employer duties for when a worker is teaching (or programming) a robot [55].

There are several established ways to monitor and assess risk. One of the methods according to ISO 13849-1:2023 is proposed as part of the solution. The risk is evaluated using the “Performance Level Rating—PLr” (PLr risk level determination). The given analysis uses three different parameters:

• Severity of injury (S):

  -

  S1 = Slight (normally reversible injury);

  -

  S2 = Serious (normally irreversible injury or death).

• Frequency of exposure to the hazard (F):

  -

  F1 = Seldom to less often and/or exposure time is short;

  -

  F2 = Frequent to continuous and/or exposure time is long).

• Possibility of avoiding the hazard (P);

  -

  P1 = Possible under specific conditions;

  -

  P2 = Scarcely possible.

The 5G network opens exciting possibilities for creating high-tech warehouses and manufacturing plants where cobots feature alongside other high-tech advancements like computer vision, augmented reality, and big data platforms. Advancements related to 5G and cobots could make industrial networks and a facility’s machines safer. Reducing potential network exposure by building private infrastructure is one approach, but it is also necessary to investigate how to help cobot automation advance with the help of 5G’s advantages.

Traditional robot control algorithms do not necessarily use AI methodologies, although the introduction of AI in robotics research is clearly increasing in many aspects such as navigation, behaviour control, task planning, or perception. In particular, collaborative robotics research is incorporating many AI-based algorithms to increase safety or versatility. Many EU projects in collaborative robotics technology are using AI algorithms [55].

4.4. Design of Risk-Level Determination for Robotic Applications

In the following section, a custom design for determining the risk level for robotic applications is presented. According to the current standard, different parameters are considered as we discussed in the previous section (S, F. P). However, we feel that the current risk-level determination is starting to be insufficient. However, the current standards do not consider many new aspects in the risk assessment that can greatly influence the level of risk. These include, for example:

• The ability to move and navigate in the space of advanced technologies. So far, we have considered static devices, but what if the cobot can move and orient itself in space? In this case, is it necessary to perform a risk analysis for the entire defined area of operation of the robot?
• Changes to the terms of reference: Currently, the establishment is obliged to submit a risk analysis evaluation, but the documents will be submitted based on fixed rules. This means that the robot will work in location “A” and perform activity “01”. In this case, the operator will be able to guarantee the safety of persons or technology. The possibility to change the environment or to adapt quickly to a new activity is considered one of the biggest advantages of cobots. When moving the cobot to location “B” or changing the task assignment and retraining the robot from activity “01” to “02”, the robot does not have a risk analysis performed and a risk reassessment by a safety engineer is necessary.
• The autonomy of technology is one of the other key parameters that is not given any importance nowadays. However, technologies are beginning to “feel” or “see”. This means that a robot, which is dangerous at first sight, sees you, perceives you in its environment, and can adapt to you. In the case of autonomous cobots, any movement is unpredictable, which is why, for example, the “P” parameter (the possibility of avoiding danger) in current standards makes one wonder whether it has merit in this case. Moreover, the trend in robotics is towards complete autonomy or “intelligence”, whereby the robot will be able to plan its routes, movements, obstacle avoidance, changes in planning its activities, etc., in human–robot cooperation. In the current risk analysis, we considered human–robot cooperation unconditionally as an operation with the potential for serious injury. However, in the case of the use of cobots, hitherto-inadmissible direct cooperation is also possible, and even in some cases, a human–robot collision is possible. The new ISO/TS 15066 [23] subsequently sets the level of individual forces, accelerations, and other parameters.

4.5. Risk Assessment

An important step at this point is to ask the question: is the risk acceptable? Or in other words: is the risk level PLr (PL “a” and “e”) sufficient? Without a doubt, everyone aims to minimize the risk, i.e., to work his way through the individual safety steps to the PLr category with a negligible level of risk. If our previous risk assessment results in just the category PL = a, there is no need to carry out further necessary operations to secure the persons in the workplace. However, if we are in the high-risk category PL = d, we must focus on the risk operations and attempt to eliminate the risks. After the given adjustments to the security concept of the whole workplace, we need to return to the first point, namely the identification of the sources of risks, again proceeding through all the points until the elimination of risks.

4.6. The Elimination of Risks

With conventional industrial robots, risk elimination is largely achieved by safety fencing. In collaborative operations, the elimination process is primarily based on changing the design and modifying the collaborative space. What are the necessary operations to be carried out for risk reduction? Achieving risk reduction can be divided into three steps:

• The elimination of hazardous areas by designing solutions;
• Minimization of the risk by implementing safety protections;
• Marking the residual risk in the instructions for use.

As an example, consider the following: the risk assessment gave us a risk level of PL = d. This means that we follow the above steps when we need to secure the workplace. Firstly, we will try to reduce the risk using design solutions. In the second case, we need safety features (safety scanners, sensors, etc.) to secure the robotic workplace, which will be classified in the category of at least d or higher (PL ≥ d). The PL category of the safety features themselves is determined by their manufacturer. The necessary information can be found in the manufacturer’s technical documentation for the specific safety components.

After applying the mentioned points, and thus eliminating the risks, the behaviour of the entire system changes fundamentally. For this reason, it is necessary to carry out the risk analysis again. In some cases, it is necessary to realize that by individual adjustments and re-evaluating individual parameters, we can not only ensure higher security, but in certain cases, also save the financial resources of the company.

4.7. Risk Elimination Design Using Holonic Agents and the Cloud

With the increasing number of robots, it is important to reflect on the question of the general safety risk of these technologies. Throughout the robot implementation chain, conducting a risk analysis is a necessary step. Nevertheless, we are seeing cases of common injuries and even fatalities, for example, in transport (tunnel security, aviation, etc.), energy, and other life-threatening processes. Based on thorough analyses, measures are developed, for example in the form of so-called “record cards”, which help staff to react flexibly in the event of accidents and thus minimize the damage. In the event of a breakdown in a tunnel, supervisors are thus able to assess the seriousness of the situation and react accordingly, based on defined rules, predefined risks, or previous experience. The development of these “cards” has clearly defined priorities. In the event of a potential risk, it is necessary to minimize them in each order, taking into account the following:

• The safety of persons;
• The environment and animals;
• Property.

Given the same functional model, it is transferred to the field of industrial robotics. In the previous sections, the principle of the cloud was introduced and the architecture of holonic agents was presented. Applying the above, we incorporated the cobot into a holonic manufacturing system. We evaluated the above architecture to be advantageous also in terms of data exchange, both at the process level of the enterprise (horizontally) and in the vertical direction, for example, Manufacturing Execution Systems (MESs), Enterprise Resource Planning (ERP), the cloud, etc. There is a relationship between the holonic agent cobot and the robotic cloud that plays an important role in our proposed model. The robots would collect safety-relevant information about people, the environment, and assets. The result would be to send the processed results to the cloud, through which the new cobots could avoid dangerous situations stored in the risk database. The idea is, as in the transport example, to create kinds of “cards” with which cobot agents in risky situations could decide how to eliminate the emerging danger.

4.8. Certification of the Robotic Workstation

Each equipment manufacturer aims to obtain the CE marking, which indicates that the product meets the technical requirements set out in all the government regulations that apply to it and that a set procedure has been followed in assessing its conformity. Carrying out a risk analysis, minimizing risks, or determining residual risks is a requirement before obtaining the declaration of conformity itself.

It is desirable to note that in the case of the introduction of a cobot into a production plant, a declaration of conformity (perceived as new equipment) is required based on the above, but in the case of defining new operations for the robot, the situation is the same as for a new machine. If, when the robot is first introduced into the company, the type of operation to be performed is not defined in the documentation and risk analysis about the application is not carried out, it is necessary to carry out all the appropriate steps again to obtain a new declaration of conformity.

5. Results

Experimental verification was carried out in the laboratory at the University of Zilina. The decision to carry out the development in this laboratory was due to its technical maturity and its focus on intelligent manufacturing systems. The main objective of the experimental verification was to design the implementation of a cooperating robot (cobot) in production systems. The technological equipment included the Baxter cobot, which is built on the ROS operating system and thus could be applied in the experimental verification. The laboratory also had several programmable logic PLCs from several manufacturers, which are used for quality control, conveyor belt control, product identification in conjunction with RFID technology, the management of industrial robots, etc. For the experimental verification, a PLC automaton from SIEMENS was used, namely the PLC S7-1200, which is also one of the most widely used PLC automatons on the European market now, which supported the choice of this type.

5.1. Experimental Validation Procedure

The experimental validation followed the algorithm developed in Section 2. The algorithm will be taken through the various points in turn, with emphasis on the implementation of the cobot in the holonic manufacturing system. Specifically, this involved the creation of a communication channel between the aforementioned S7-1200 PLC and the Baxter robot. An application was created on top of the PLC automaton to simulate a manufacturing device that was capable of communicating with the Baxter robot on the lower layer of the holonic agent LLC architecture, thus achieving a successful implementation of the cobot in holonic manufacturing systems (Figure 6). The next part of the experimental verification was devoted to the attention of the risk analysis according to our proposed method (Conclusion section), and the results obtained were evaluated at the end of the validation.

5.1.1. Identification of Processes for Automation, the Selection of a Suitable Robotic Cobot, and the Effector System

The proposed Robot Operating System (ROS) is a suitable solution for the implementation of more demanding applications. The use of open software libraries allows programmers to develop applications shorter, which translates into savings in funds spent on professional staff, reduced robot downtime, etc. There are several pieces of proprietary software on the market, but based on the benefits of an ROS, the ROS (Robot Operating System) was chosen as a suitable option. A collaborative robot called Baxter from Rethink Robotics, which includes an equally safe effector designed by the same company, represented the hardware. In this case, two types of effectors are available, namely electric and suction cup effectors.

Among component-based approaches, the Robot Operating System (ROS) is becoming the standard programming framework for developing robotic applications [32,33]. The ROS-based software architecture is composed of components and connectors between them that are partially specified in the code and created at run time. However, there are no generally accepted rules and guidelines for developing applications to perform a required task [56].

The Baxter cobot was subjected to several tests to gain a broad overview and a wealth of experience. Several software libraries available on the ROS community site were used in the testing. Examples include the simulation and planning of robot movements, sound or image recognition, etc. When using these libraries, despite their availability and the possibility of implementing them in one’s project, there is a need to know programming language.

5.1.2. Integrating the Robotic System into the Process Level of a Holonic Manufacturing Company

Figure 7 shows a view into the laboratory of the experimental cooperating workstation, where we see the technologies proposed according to the schematic, specifically the Baxter cobot and the Siemens S7-1200 PLC. On the monitor, an application can be seen simulating a production facility. This was used equally for simulation as well as for a visualization of the real data exchange between the PLC S7-1200 and the Baxter cobot. These were updated every 100 ms.

A close-up screenshot of the developed application is shown in Figure 8. By using this application, it was possible to simulate various production equipment conditions such as machine failure, safety circuit breakage, etc.

To ensure the reliability of the operation and the cooperation of the cobot with the external (production) system controlled by the PLC, we used the proposed data from Section 2.

• Plug and Play, the method via which, for example, USB components for computers (mouse, keyboard, etc.) work, are a requirement of the new industrial revolution. By connecting the keyboard to the computer, we achieved reliable keyboard–computer cooperation without any necessary configuration. Achieving the same result is what manufacturing companies strive to achieve when interconnecting industrial technologies. The cooperation of a cobot with an external system would be a matter of a few simple steps. In an attempt to realize the above, a data structure is proposed in the design part based on which the enterprise can define a certain type of operations to be carried out. Once a communication link is successfully established, the cobot can understand the “language” of the external system, resulting in the autonomous execution of the operations of the two interconnected technologies. In this case, the external simulated production device requests to establish communication with the cobot to:
• Supply material to the cobot;
• Remove manufactured parts from the conveyor belt.

Data on the Baxter cobot side are shown in

Table 1. Data on the Baxter cobot’s page.

Reading Data from an External System (Production Device)	Writing Data on an External System (Production Device)
External equipment security	Cobot safety
External device status	Status of the cobot
Enabling operations from an external device	The current cobot operation being performed
	Termination of the cobot operation

.

Figure 9 shows an example of the evaluation (receiving and sending) of data from an external production system (a simulated production device controlled by a PLC automaton) in the ROS (Robot Operating System). The received information is then processed, and thus, based on the needs of the simulated external device, the cobot can react. Despite the cooperation with the simulated workstation, the possibility of simultaneous cooperation with a human in production should be re-emphasized. When using the Baxter cobot (a two-arm cobot), one arm can be used for human–robot cooperation (e.g., joint preassembly, part picking, etc.), while the other arm can be dedicated to cooperating with the external system at the same time. The data on the side of the PLC automaton (simulated production equipment) are shown in

Table 2. Data on the PLC side (simulated production device).

Reading Data from an External System (Production Device)	Writing Data on an External System (Production Device)
Safety of the cobot	Safety of Baxter cobot
Status of the cobot	External Baxter cobot status
The cobot operation currently being executed	The current cobot operation being performed
Termination of the cobot operation

.

Figure 10 shows a sample from the TIA (Totally Integrated Automation) Portal v13 development environment. This is proprietary SIEMENS software for PLCs, drive configuration, HMIs, etc. In this case, the above software plays an important role during the configuration and programming of the PLC–ROS communication, and the creation of the interfacing of the simulation application with the PLC. The program written in the TIA portal was uploaded to the Siemens S7-1200 PLC.

6. Discussion

For risk identification, the definition of the proposed site is necessary. In this case, we consider the external simulated production facility as a separately certified facility with a declaration of conformity; it is not a new or recommissioned machine, nor a case of incorporation (declaration of incorporation). For our experimental validation, we will consider the following:

• The technology used: a Baxter cobot equipped with an emergency stop button.
• The type and characteristics of the operations performed: the requirement of the Baxter cobot is to perform handling operations to remove manufactured parts from the conveyor belt and to supply the external simulated system.
• The material to be handled: this is a part made of plastic in the shape of a cylinder with rounded edges and a max. weight of 0.02 kg.
• The effector: this is an electric effector designed by Rethink Robotics that meets the requirements for cooperation with a human.

For risk identification, it is desirable to define the limits of the use of the cobot. In the development and testing phase, we suggest the use of the cobot exclusively for persons involved in the development of the software and the overall concept of the testbed. Outside the development and test phase, the device is put into an idle state and, thus, the robot will be turned off. Defining any further boundaries would be limiting the freedom of research. Based on the predetermined workplace parameters, the following sections consider the following:

• Risks associated with the robot: this is a summary of the safety characteristics of that robot, which allows us to assess that the cobot as a robotic technology itself is safe and does not pose a high risk to operators.
• Risks associated with the robotic system: This introduces the concepts of “quasi-static” and “dynamic” contact. In the case of tasks performed by a cobot, both of these contacts can occur, and in our case, they are evaluated with minimal risk to humans. In “quasi-static” contact, the application of forces is low, and thus, there is no risk of severe injuries (fractures, etc.). The Baxter cobot is adapted to cooperate with humans. Therefore, in dynamic contact, the human is not exposed to high risk, and the robot’s end effectors and loads have no sharp edges; the workplace uses a height-adjustable table, so in the case of human–robot cooperation, it is possible to ergonomically adjust its height according to the operator’s needs.
• Risks associated with the application:
  • The main task of the Baxter cobot is the handling of light parts and rounded edges, where there is no high risk of injury.
  • The proposed workstation concept makes human–robot cooperation unique. One of the factors affecting safety could be the reduced concentration of the operator when carrying out continuous cooperation with the cobot.
  • There are no facilities in the vicinity of the proposed workplace producing hazardous factors affecting human health (noise, sparking, etc.).

As we noted in the design section, current methods for risk assessment are becoming inadequate. The assessment parameters of the PL (Performance Level) method are difficult to estimate when using new technologies such as a cobot. For a risk assessment of Industry 4.0 technologies, formulation of the parameters is inappropriate. Despite the above, for comparison, we carried out the risk assessment according to the current state-of-the-art “PL” method. We proceeded as follows (Figure 11):

From the graphical solution and our perception of the assessed parameters, the risk level PL = c. This implies the necessity of securing the cooperating workplace using suitable methods described in Section 4.6.

We proceeded as follows to assess the risks using our proposed method (Figure 12):

• Parameter “P”: From a process point of view, the handling of a lightweight rounded part made of plastic material is a safe process. Even in unsafe situations where the cobot releases the part from its jaws—the effector—no serious injury will occur, so we selected parameter “P1” (safe processes).
• Parameter “C”: In the design part, the devices were divided into static and dynamic, and the experimental workstation in the ZIMS lab was static. The Baxter cobot was in its fixed position and the execution of its movements was determined by precisely defined trajectories. Risk detection was predictable. A trained person could estimate the robot’s behaviour, resulting in avoidable injuries in the event of a potential hazard. Based on the above, we selected the parameter “C1” (static device).
• Parameter “L”: The Baxter cobot was implemented in the lab not only from the perspective of human–robot cooperation, but also robot–machine cooperation. It was in the latter case that it was primarily about fulfilling the needs of the simulated production facility. The role of the human may consist of supplying material to the cobot, for example. It was the low frequency of human–robot cooperation that was the basis for our choice of the parameter “L1”.

Based on the graphical solution (Figure 11), we can observe a change concerning the risk assessment of the currently available method (Figure 10). The risk has changed from PL = c to PL = a, and thus to a negligible level.

6.1. Robotic Workstation Certification

Research activities force constant changes in the experimental system concept, changes in the software under development, testing and searching for new collaboration opportunities, etc. In the context of solving the scientific problem of this solution and the implementation of the cobot in laboratory conditions, we consider the given step to be unjustified, and thus, it is not necessary to obtain the CE marking.

6.2. Future Research Directions

As part of the solution, a substantial part was devoted to exploring the issue of cobots. While applying the acquired knowledge from the theoretical part, we described new unexplored areas, such as:

• The implementation of cobots in a manufacturing enterprise with the possibility of establishing communication with external systems was presented in the thesis using the theory of holonic manufacturing systems. We defined the term “holonic agent” and, thus, we know that it consists of an upper HLC layer and a lower LLC layer. At the upper layer, agent communication, negotiation, ordering, and so on take place between the holons. At the lower layer, the exchange of process data takes place. In the given problem, the area of design and standardization of communication between the above-mentioned HLC and LLC layers is still unexplored, which is also a recommendation for a further research direction.
• The given paper also extensively dealt with the design of the individual steps—the procedure for the successful commissioning of the cobot. Based on the research and subsequent practical implementation, a communication interface of the ROS (Robotic Operating System) with a PLC programmable logic automaton was developed. However, it is important to note that, despite this research, the communication at the lower level between the holons at the LLC level is not sufficiently explored nowadays, or the communication channel needs to be redesigned in detail and standardized to create “plug and play” technologies. The result of this part of the development can have enormous benefits for the practice. The new findings from the design of new standards by the OPC Foundation, which proposed the “Automation ML” standard at the time of the work, were brought to attention.

7. Conclusions

Based on the proposed algorithm, an experimental workstation was set up to verify the implementation of cooperating robots (cobots) in holonic manufacturing systems. For the cooperation of the cobot with the plant-level process equipment, we developed an application for the simulation of the production equipment, thus verifying the functionality of the proposed communication and data structure. We concluded the experimental validation by developing a risk analysis according to our proposed method. The creation of a new similar cooperating workstation is feasible when changing technologies (for example PLC automaton and cobot to ROS), but it is recommended to maintain the procedures presented in the paper to achieve the desired results.

Based on the theoretical knowledge presented above, we know that holons, like humans, can cooperate through human–robot cooperation, robot–robot cooperation, robot–manufacturing equipment cooperation, and so on. By using the tools of the new industrial revolution (e.g., cloud computing), cobots can learn from each other or exchange data. The design of an appropriate communication structure is the basis for the establishment of cooperation. For the selection of a robotic system (ROS), a description of the interconnection of devices at the process level in the enterprise, or the interconnection of the lower LLC layer (hardware) with the upper HLC layer (holonic agents), is recommended.

While researching the scientific problem, we concluded that the current legislation is beginning to be inadequate. We presented a risk analysis and assessment. The methods (PL and SIL) were developed for risk assessment, but for the needs of the aforementioned Industrial Revolution 4.0, we propose revising them. Although human–robot cooperation is accepted, any time a workplace design is changed (retraining a robot for a different type of work, changing a load, changing an effector, changing a robot’s position, etc.), a risk analysis must be performed again.

This need not only be carried out if possible changes were considered in the initial design of the cooperating workplace. As a further aspect, we mentioned inappropriate evaluation parameters for robotic systems. “Intelligent” robots (cobots and humanoid robots) can move and orient themselves in space. The planning of their goals, movements, and activities is moving to a higher level (e.g., cloud computing). Therefore, it is almost impossible to predict their states and, thus, assess risks reliably based on current standards. In Section 3, the solution addressed the design of a custom method derived from the PL method.