Introduction of a unified robot intergration package

1 Introduction

In a modern manufacturing environment, robot systems are becoming an integral part of an increasing number of different production processes [1]. Due to the specific requirements of different manufacturing processes, e.g. complex or repetitive mounting tasks, handling of small-scale parts, high-precision tasks, or even heavy-duty processes, the variety of robots is constantly increasing. In recent decades, robots and their environments have become more heterogeneous, with different types, configurations, and vendors. Such different types include articulated, delta, cartesian, SCARA, collaborative and soft robots. Due to differences in engineering basics, e.g. tools, languages, terms, and definitions, this variety often leads to a more complex engineering process for robot systems. In addition, robots of these types are regarded as incomplete machines. They are designed to be combined with additional components, such as an end effector. The resulting combined robot systems offer composite functionalities, as combinations of the individual functionalities of the components [2]. For example, a soft robot gripper attached to an articulated robot to handle fragile objects or objects with unknown geometry [3], can provide a pick-and-place functionality. This system integration can be a demanding task, when complex behavior is required. Often times this leads to the expensive outsourcing of the system integration. Currently, this custom engineering of robotic systems is a major cost factor for robotic automation, of up to 70 %, [4]. Additionally, as most robot systems are engineered for specific requirements and functionalities, a requirements change could immediately lead to a different robot type or auxiliary component and therefore additional integration cost.

One opportunity to reduce the complexity and accelerate the engineering of robot systems is modularization [5]. In the process industry, modularization concepts are already defined by the Module Type Package (MTP) [6]. Due to the differences between the production equipment of the process industry (pipes, vessels, pumps) and robots, it is not sufficient to directly use MTP to describe robot systems. This will be explained in detail in Section 2.

Facing existing drawbacks, this work presents a novel architecture aimed at accelerating the engineering of robotic systems by means of modularization. This architecture is termed Unified Robot Integration Package (URIP). During the design phase of URIP, including a detailed state-of-the-art analysis, three crucial aspects of the engineering process have been derived:

1. control and orchestration,

2. functionality description,

3. human-machine interface.

This article outlines the overall structure and objectives of each aspect to explain the new concept for the first time, though detailed exploration is beyond its scope and will be the subject of future work.

The remainder of this article is structured as follows. In Section 2 related work is outlined from different domains. The structure of the URIP, divided into the mentioned aspects, is established in Section 3. An exemplary robot system is provided in Section 4. Lastly, a summary and an outlook for future research regarding the extension of the URIP are given in Section 5.

2 Related work

One of the major goals of the presented architecture is to establish a generic basis applicable to different sectors such as chemical, pharmaceutical, life science, food and beverage, oil and gas production plants, as well as the discrete manufacturing and assembly industry. For this, existing modularization efforts from different domains have been analyzed.

As mentioned in Section 1, a prevalent example of modularization in process plants is the MTP. The MTP, defined in the VDI/VDE/NAMUR 2658 [6], describes a modular process plant as an aggregation of process equipment assemblies (PEAs). A PEA can be, for example, process equipment such as distillation units [7]. Such a PEA is made up of functional equipment assemblies (FEAs). A FEA can be a controlled flow subsystem within the dosing unit. The monitoring and coordination of PEAs is implemented within a process orchestration layer (POL) [6]. The POL is usually a process control system that imports the MTP information models and uses them to orchestrate the overall configuration of the process plant, according to a process recipe. The MTP is designed specifically for process automation. For instance, the generation of standardized human-machine interfaces (HMIs), as defined by the MTP in part 2, only considers PEAs like pumps, tanks, or valves and their respective schematics. In order to integrate robotic systems into the MTP concept, all advertised functionalities must be wrapped in state machines. For granular functions like opening a gripper, this is not feasible, as most granular robotic functionalities are provided as remote procedure calls (RPCs), which can be directly invoked. When regarding higher level functionality like pick and place, a state machine becomes more advantageous. This results in the programming of the state machine, integrating all system components. Currently, the MTP does not provide assistance for this integration step, making it a manual process. This increases the burden on the module manufacturer. Therefore, the MTP concept is not directly suitable for robotic integration, necessitating the formulation of a streamlined approach of modular robotic systems.

The direct usage of the MTP with robotic systems is illustrated well in [8]. Here, the author utilizes the Robot Operating System (ROS) for hardware abstraction. The ROS offered robot functionalities are directly integrated with the Open Platform Communications Unified Architecture (OPC UA) in line with the MTP service structure by using mtppy [9]. The software mtppy provides a service framework for an MTP compliant state machine. This MTP adaptation considers robots only from the control aspect and does not regard HMIs. Additionally, the mtppy approach limits the consideration of complex robot systems, due to the rigid code structure. The reference implementation, in [8], directly integrates the functionalities of an articulated robot arm and an attached gripper into the POL. A Move-Service is implemented to trigger robot movement and a Hand-Service for gripper opening and closing. A composite functionality like pick-and-place therefore needs to be orchestrated directly in the POL. When considering the robot and gripper as a module offering a composite pick-and-place functionality, the timing of the services need to be implemented within the module’s service. This example highlights that while it is possible to represent a robot using the MTP, there is currently no approach to structuring a robotic system and the advertised functionality.

In addition to MTP adaptations towards articulated robots, the MTP concept has already been utilized for process-oriented intralogistics units [10]. This concept involves implementing a Transport Coordination System (TCS) as a PEA and utilizing a Logistic Orchestration Layer (LOL) instead of the POL. The LOL manages orders, assets and transports [11]. The TCS communicates with a mission manager that coordinates transport tasks with automated guided vehicles (AGVs). This concept extends the scope of the MTP to AGVs [12]. However, the AGV is not directly considered as the mission manager, and the TCS abstract the AGVs functionalities. Therefore, this approach is not suitable for the direct representation of robotic systems.

So far, the MTP only considers communication via OPC UA [13]. OPC UA provides both cyclic Client/Server and event-based Pub/Sub communication. To provide the Pub/Sub pattern for MTP, OPC UA can be combined with the Message Queuing Telemetry Transport (MQTT) protocol [14]. These communication patterns are usually not provided by robots. Often, the communication method of a robot is based on the use of RPCs within a manufacturer-specific Application Programming Interface (API). To wrap these custom RPCs, ROS or ROS2 are commonly used [15]. ROS enables a Service-Oriented Architecture (SOA) of robot systems by wrapping the robot functionality into ROS services. There are also attempts to implement a software bridge between ROS and OPC UA [16]. These can be utilized to control robot functionality with non-ROS-enabled software nodes. In view of the diverse use of RPCs in robot systems, a modular concept RPCs and the ROS architecture must be taken into account.

Another aspect that needs to be taken into account when modeling modularized robot systems is the PPR-Method, which splits a production entity into product (P), process (P), and resource (R) [17]. Its focus is on the definition of skills that can be supplemented to describe the relationship between processes and resources [18], which in turn allows a layer of abstraction [19]. For example, a skill can be “welding” – or “pick and place”. This approach has already been implemented to orchestrate robot systems, using the so-called skill execution engines (SEE) [20]. Expending on the idea of PPR and production skills [2], [21], introduces the Capability Skill Service (CSS) model. The CSS model defines (a) capabilities as the description of implemented skills in a process-relevant context, (b) a skill as the implementation of a capability, and (c) services as a way to offer capabilities to external partners via a marketplace. For example, the capability “pick and place”, utilizes implemented skills like “closing of a gripper” and “control of a robot”. The capability can then be wrapped into an “automated material handling” service.

A comparison can be drawn between the CSS and MTP concepts. The skill describing the implementation of a functionality advertised by a system as defined by the CSS model can be compared to a procedure, defined as the realization of an abstract functionality in the MTP. A capability, the description and abstraction of a skill, can be compared to the service advertised by a PEA defined in the MTP [22].

Another method of modeling and abstracting intralogistics systems is the System Architecture for Intralogistics (SAIL) defined in [23]. SAIL describes how a material flow facility is subdivided into SAIL components. This architecture specifies the way functionalities are encapsulated, how interfaces are defined, and how control components are provisioned. This function-centric modeling approach promises to lower costs in all engineering phases by improving the reusability of components and, therefore, lowering engineering overhead for reconfiguration of systems [23]. However, the SAIL concept is specifically designed for conventional material flow technology such as conveyor belts or AGVs. Therefore, it specifically models the material flow through a production environment by defining, for example, the Transport Coordination and Direction Control functionalities. A welding robot, for example, cannot be modeled with such functionalities efficiently. It is not designed to use articulated robot functions.

In conclusion, many efforts of modularization already exist. Each of the presented concepts approach modularization from a different perspective and in different domains. As elaborated, each method has different reasons for why a direct application for robotic systems is not feasible. This establishes the need for action to adapt and combine aspects of the existing methods towards robotic systems.

3 Concept of a unified robot integration package

Similar to related work in the process industry and intralogistics, robot systems can be modularized. In this article, a package description is developed to describe such modular robotic systems. The proposed Unified Robot Integration Package (URIP) is an MTP-like package which models data used during engineering and operation. Therefore, URIP includes aspects of a robot-specific core concept such as control, functionality description, and HMI, during the engineering and operation of robot systems.

3.2 Module decomposition

The URIP uses the term robot module as a combination of one or multiple robotic components and optional auxiliary components. A robot component can be defined as a robot as defined in ISO 10218 [25] or a mobile robot component following the definition of ISO 13482 [26]. A robot component is integrated with a vendor-specific controller. Auxiliary components are assets which are attached to robots, and their controllers. They include, for example, safety equipment, like light curtains. This type of component does not include any standalone controller and is supposed to be integrated into the robot controller.

The combination of multiple robot components constitutes a robot module. The example in Figure 1 illustrates how a mobile robot manipulator can be decomposed into sensible parts, based on the previous explanations. When a robot module is combined with additional components, a hierarchical structure is applied. Each component and combination of components can be represented as a robot module with a unique URIP.

Figure 1:

Definition of subdivisions by means of an exemplary AGV robot manipulator.

3.3 Core concept aspects

The following sections describe the core concepts incorporated with the URIP, starting with the control aspect, followed by the description of the robot’s functionalities and the module HMI concept.

3.3.1 URIP-aspect 1: robot control

This section will elaborate on how the URIP implements a comprehensive, abstract, and modular robot control mechanism.

When integrating a robot system, it becomes clear that the control methods of robot systems vary drastically with each vendor. Each robot provider implements a custom controller structure for their robots, including custom programming languages and APIs. As mentioned in Section 1, the multitude of vendor-specific solutions leads to a drastic overhead in engineering effort. To alleviate this fact, the overarching goal of URIP control component is to provide a comprehensive, vendor-abstracted robot control system. This system aims at providing a unified interface for controlling various robotic systems, regardless of the manufacturer. In this way, the exposed functionalities of the robot module satisfy the requirement REQ 1.

As depicted in Figure 2, in the core, the control aspect is based on the API offered by the vendor, which exposes the functionality offered by the vendor. In order to achieve a generalized robot integration, a hardware abstraction layer is necessary, standardizing the robot interface. On top of this hardware interface, generic robot controllers can be implemented, that latch onto the hardware interface functionality, offering control over granular robot functionality, such as Tool Center Point (TCP) or joint trajectory movement. Due to the standardized nature of the hardware interface, implemented controllers can be reused across different robot systems. Such controllers can be provided for each robot component of a robot module.

Figure 2:

Control aspect of the URIP.

For complex robot behavior and multi-robot modules, coordination of all submodules and components is necessary to provide the needed robot functionality. To this end, choreography or orchestration methods can be utilized.

Both concepts are rooted in computer technology and web service architectures. Orchestration utilizes a single coordination process, which describes the flow of operations. Choreography is a decentralized method of coordinating multiple systems, with direct peer to peer communication between each system [27].

With regard to automation technology, the usage of orchestration is more common, than choreographies [28].

When implementing a choreography of multiple controlled systems, each system needs the knowledge about the following systems functionalities. Therefore, the overall system structure must be clear during the implementation of granular functionalities. For example, when implementing an articulated robot with a gripper attachment using the choreography method, the robot controller interacting with the gripper is specific for that attachment. If the robot is afterward used with a completely different, or even without a gripper, the controller implementation needs to be redone. Based on this reasoning, the authors recommend module internal orchestration within a superordinate system, as depicted in Figure 2. However, the possibilities of choreography implementations for modular robot systems need to be explored in further research.

The orchestration will be provided by module-specific statecharts, where granular robot control is used to coordinate robot functionalities. By adopting a modular approach to statecharts and utilizing orthogonals as defined by Harel [29], it is ensured that the implementation of robot components behavior within statecharts is reusable, given the generic interface of the granular robot controller. In this context, orthogonality refers to the ability to split a state into independent concurrent sub-states, each representing a different aspect or subsystem. For example, orthogonality can be used to handle different hardware components such as sensors, cameras, and actuators independently, but concurrently.

Implementation-wise, the ros2_control stack [30] can be followed to implement the hardware interface and the reusable robot controller. ROS2 provides a widely popular middleware, defining standardized interfaces and provides a large library of robotics tools. A component using ROS2 to communicate with other components is called a node. The communication patterns can follow a Pub/Sub or call-response (ROS-Service/Action) pattern.

When a module with multiple robot components is concerned, each will need a dedicated ros2_control node. Each of these can be deployed on different or the same hardware within the module. An exemplary distribution of an articulated robot manipulator is depicted in Figure 3. The robot and gripper are connected separately to a vendor offered hardware controller and an I/O-Link interface. Both systems provide an API, which can be utilized by the depicted real-time operating system (RTOS) enabled computer. On the RTOS-system two ROS2 controllers are implemented, one generally available joint trajectory controller (JTC) node (1), and a separate gripper controller node (2). These controllers establish a ROS2 action and service based interface within the ROS2 network. A superordinate orchestration system utilize these in order to offer complex pick and place behavior. Regarding this architecture, only elementary components will provide a hardware interface and direct controller, as indicated by the crosshatch pattern in Figure 2. All (sub-)modules implement the described orchestration of the internally advertised functionalities of comprised components. Implementation-wise, this can result in a ROS2 workspace with a controller workspace for each elementary module and state chart workspaces for each (sub-)module.

Figure 3:

Exemplary controller deployment architecture.

In order to implement the statecharts, SMACC2 [31] can be used. With this approach, state charts similar to those defined by ISA-88 [32] can be implemented. The implementation of such a module statechart is described in [33]. A resulting exposed functionality can be serviced to a high-level orchestration system that can commission the robot module functionality via the standardized transition signals, which can be provided as ROS2 services in the appropriate states.

With this method, the orchestration of robot modules is possible, similar to [8], [20], but providing only the functionalities of modules relevant to the high level process rather than the functionalities of granular robot component.

In conclusion, the requirement for provisioning a hardware abstraction for controller and orchestration implementation is fulfilled through modular robot orchestration based on a generic granular robot controller and the utilization of hardware and vendor abstraction via the hardware interface. The ROS2 control stack can be followed to implement the hardware interface and reusable robot controller. For the Harel statechart implementation, the ROS2 package, SMACC2, can be used to interface with the generic ROS2 controllers. This comprehensive method ensures an effective approach to flexible, reusable, and vendor-agnostic functionality of robot modules. The ROS2 and SMACC2 implementations proposed in this section have been tested in the example explained in Section 4.

3.3.2 URIP-aspect 2: descriptive aspect

The overarching goal of this aspect is to achieve seamless integration of module functionalities within an over all ROS Orchestration Layer (RosOL). This integration aims to ensure that various modules, regardless of their specific functionalities, can work together cohesively within a production environment.

Integration is heavily dependent on the implementation details of module functionalities, such as procedures and parameters. This dependency creates challenges in achieving a standardized approach to integration, as each module may have unique requirements and interfaces.

To address this issue and therefore satisfy REQ 2, the authors propose the integration of a generic description model for all orchestration-related functionalities that a module provides. This solution involves using the CSS [2] approach. As described in Section 2, the CSS method is a structured approach to defining and implementing functionalities within industrial systems. In this method, a capability is an implementation-independent specification of a function in industrial production to achieve an effect in the physical or virtual world. A capability may be implemented by one or more skills. A skill is an executable implementation of an encapsulated function specified by a capability.

For modular robotic systems, this method can be adapted. A robot module, consisting of submodules and components, exposes which can be described as capabilities. These capabilities choreograph the functionalities of submodules and components within the module hierarchy. Therefore, the module capability is considered a composite capability. Only the elementary components of each (sub-)module implement the skills out of which the (sub-)modules form their capabilities. For example, if a composite capability involves picking, moving, and placing an object, it will utilize the skills associated with each of these actions (pick, move, place), which are implemented within the elementary components, articulated robot and robot gripper, rather than implementing a new skill for the entire sequence. The described capability and skill decomposition is depicted in Figure 4. The goal of accessing and orchestrating the composite capabilities of the robot module entails the need for information models that describe the capabilities of the module, the elementary skills of the components and the connections of the skill interface. This information model will facilitate the standardized description and integration of module functionalities within the orchestration system.

Figure 4:

Capability and skill decomposition example.

To be able to access the capability and skill descriptions, an Asset Administration Shell (AAS) [34] implementation is advantageous. The CSS model outlines the use of an AAS submodel for describing capabilities, based on references to skills and additional metadata such as descriptions [2]. This capability submodel is currently under development [35]. To describe a skill within the AAS, it is recommended to use the AAS submodel element “operation” or a function block (FB), which represents an independent submodel [2]. In Section 3.3.1, it is proposed to implement the robot functionality with ROS2. However, currently there is no submodel to reference ROS2 functionalities within the AAS. Therefore, the development of a ROS2 compatible functionality description as depicted in Figure 5 is necessary.

Figure 5:

Skill description of ROS functionalities.

A ROS-FB submodel, which represents the functionality provided by a URIP defined robot module, must entail the data presented in Table 1. Additionally, in order to be able to call the described functionality, a description of the skill interfaces, containing the data listed in Table 2, is also necessary. The detailed definition of the ROS-FB submodel, although within the scope of the author’s research, is out of the scope of this article and will therefore be published in future work.

Table 1:

ROS function block submodel elements.

Element	Type	Example
Reference ID	ID	45dj-6qe3-sfo0-h23j
Name	String	Joint movement
Description	String	Joint based movement of the robot
Parameters	List<Ref>	Angle, velocity, acceleration
Prerequisites	List<String>	Robot not moving, angle within range
Post-requisite	List<String>	Robot not moving, angle within tolerance
Interface	Ref	k35h-kj36-s24f-1lk9

Table 2:

ROS interface submodel elements.

Element	Type	Example
Reference ID	ID	k35h-kj36-s24f-1lk9
ROS-node name	String	JTC-controller
ROS-IP	String	196.0.0.1
ROS-domain	Int	0
ROS-method	Enum	Action
Topic name	String	JTC-controller/follow_joint_trajectory
Message type	String	control_msgs/action/FollowJointTrajectory.action

3.3.3 URIP-aspect 3: human machine interface aspect

The goal of this section is to explore the development and implementation of HMIs for modular robot systems. HMIs play a crucial role in ensuring that operators can interact and control robotic systems effectively, facilitating seamless operation and integration within flexible production environments.

One of the primary challenges in the development of HMIs for modular robot systems is the complexity that arises from the diverse functionalities and configurations of different modules. Each module may have unique control requirements, parameters, and procedures, making it difficult to create a standardized interface that can accommodate all variations. This complexity requires an advanced HMI that can adapt to the specific needs of each module.

To address this challenge and satisfy REQ 3, the integration of an automatically generated HMI, similar to the HMI of the MTP, is proposed. The proposed approach leverages the control implementation discussed in Section 3.3.1 and the descriptive aspect elaborated in Section 3.3.2. The automatic generation of HMIs is crucial for managing intricate interactions between modules, allowing operators to monitor and control systems with ease. This method minimizes the manual effort required to design and update HMIs, reducing the potential for errors and enhancing overall system efficiency.

The HMI visualizes the state of the robot module system, makes the module capabilities available to the operator, and incorporates the decomposition of the system. The HMI is provisioned for the overall robot module, each submodule and elementary component. This ensures exposure of all relevant functionalities for different scenarios like normal operation or maintenance, where granular control over specific components might be necessary.

In Figure 6, a mock-up HMI of the exemplary composite robot module from Section 3.2 is shown.

Figure 6:

Exemplary mock-up HMI of AGV based robot manipulator module.

The following paragraphs explain the elements of a URIP HMI.

3.3.3.1 HMI element: system state

Utilizing the information models for robotic systems, which incorporate 3D models, the system state can be visualized for each robot (sub-)module and component directly. An example of such an information model would be the Simulation Description Format (SDF) [36] or the URDF mentioned in section Section 3.3.1. These information models can be used to render robotic components within a module. The renderings can be controlled to visualize the current system state of a component, for example, the joint angles of an articulated robot. Such visualizations can be implemented using ROS2 and the ROS-Visualization (RViz) [37]. In order to display the immediate robot environment, more elaborate tools like the robotics simulation tool Gazebo [38] can be used. This approach is well integrated with the ROS2 control aspect described in Section 3.3.1.

3.3.3.2 HMI element: capabilities

As described in Section 3.3.2 the advertised module functionality can be described with the CSS model. The elaborated approach can be used to advertise the appropriate module functionality in the HMI. Each capability can be displayed and interacted with regard to the description and the necessary parameters. Such module capabilities might be callable by an operator through the HMI, for example, to start and stop grasping functionality provided by an articulated robot with a gripper attachment. The description entails all relevant information, like the interface type, message type, namespace and endpoint in order to automatically create a client node. As described in Section 3.3.1, a node represents a ROS2 capable software program, that can communicate with other nodes, for example by calling services.

3.3.3.3 HMI element: submodules

As described in Section 3.2, a module consists of submodules and components. Each submodule provides a different granularity of the module functionality. In order to access the capabilities of a specific submodule, the HMI needs to provide a hierarchical structure. Therefore, each submodule and component need to be equipped with separate HMIs. A decomposition menu will make the composite system’s HMI accessible. In this way, the HMI can penetrate all layers of a module and access data from all submodules, components, and the module itself.

4 Exemplary concept application

In this section, an exemplary robot module is presented. With this, the usage of the introduced URIP concept is outlined. The overall functionality of the exemplary robot module is the automated collaborative drilling of a work piece, as depicted in Figure 7.

Figure 7:

Simulation of the exemplary robot drilling module.

Although drilling is not a natural task for collaborative systems due to the necessary system rigidity, the example is chosen because it is easy to explain and illustrate. The decomposition of the module is shown in Figure 8. The main components are two robots with specific end effectors, one end effector is a common gripper, and the other is a drill head. As illustrated in Figure 7, both robots are cooperating with each other in order to accomplish the drilling task.

Figure 8:

Example decomposition of a robotic drilling module.

Each elementary component, in the component-layer of Figure 8, implements an individual skill and exposes a corresponding capability. The drill attachment implements a ROS2 based controller to activateDrill and deactivateDrill the drill. Similarly, the gripper attachment implements the closeGripper and openGripper skills. Both robot components use the ros2_control implementation of a joint_trajectory_controller. Therefore, the robot movement is configured joint wise with angle, speed and acceleration parameters. In the submodule-layer of Figure 8 the granular skills of the composite components are orchestrated using the SMACC2 implemented statecharts. The submodules provide the composite-capabilities drilling, exposeWorkpiece, placeWorkpiece. Within the state charts, each submodule or elementary component is represented as an orthogonal. In the module-layer the composite-capabilities are composed to the exposed capability of automatedDrilling, which uses the exposeWorkpiece, placeWorkpiece and drilling capabilities. The functionalities are listed in Table 3 Du to the taken approach, the integration involves little programming. The available elementary skills are provided as ROS2 services and actions. These can be orchestrated as composite capabilities with a SMACC2 state chart. Currently, the state chart integration is done manually, but an assistance based on the functionality description is possible in the future.

An imported point mentioned in Section 3 is the interchangeability of components. Due to the usage of the ros2_control implementation, it is possible to exchange the articulated robot with another robot with similar configuration, without any reprogramming. For example, the here used UR5 robot can be exchanged with a UR10 or a similar kuka iizy robot. All three systems are currently supported with open source repositories of the ros2_control stack.

With regard to the security, SROS2 is used for authentication and integrity within the operational- and submodule-layer. This is done to ensure that the signals and commands are sent by the appropriate system, and were not tampered with. The required device entities, including private key and public key inform of a X.509 certificate, trust anchor, as well as a security configuration for example in the form of a key storage, are provided manually. This is done for all components, participating in the ROS2 communication, this excluded vendor provided hardware controllers, which are currently not regarded within the security aspect.

All actuated submodules can be described within URDF or SDF information models, which can be used to visualize the state of the system. In this instance, the visualization depicted in Figure 7 is provided with a custom simulation environment implemented in Unity. The described HMI of Subsubsection 3.3.3 is not implemented as of this time.

This example illustrates how the URIP aspects can be used to combine elementary submodules to complex robot modules, with little integration effort.

5 Summary and outlook

In this article, the authors introduce the novel concept of the URIP. In this context, three main aspects: robot control, descriptive aspect, and HMI were introduced, and implementation recommendations were given. The control and orchestration of robot functionalities with the ROS2 control stack enables early validation with mock components and hardware abstracted implementation, as well as reuse of control algorithms. This is followed by the description of skills, capabilities and composite capabilities, enabling the future integration of URIP described robot modules into a ROS2 based RosOL. With the proposed HMI, only relevant functionalities of each module can be accessed during operation, but lower-level functionalities can be accessed for maintenance purposes. Lastly, an exemplary system was introduced to validate and explain the URIP concept.

In following publications, each aspect of the URIP will be elaborated in depth. Starting with the implementation of the control aspect in [33] and the detailed description of an information model for the implemented functionalities as proposed in Section 3.3.2. Afterward, the implementation of the HMI and the integration of URIP described robot modules into a RosOL will be explored.

Additionally, a seamless cross-phase usage of URIP from concept creation to design, implementation, testing, and operation will be transferred into a life-cycle model.