Manufacturing operations as services by robots with skills

2.1 Organizing services

Service has been described as value co-creation phenomena [6] taking place as a result of interaction between legal entities and their resources (including people, information, and technology) in a service system via value propositions [7]. Services can be characterized also as applications of competences (knowledge and skills) by one legal entity for the benefit of another [8]. In case of MaaS, a manufacturing company owning and managing competences, skills, and technologies for manufacturing, is providing a service offering on producing a physical product based on digital product and design data for customer companies. If the service offering is fully automated and consists only of applications of technical systems based on information, communication, computing, and automation technology for realization of the operations, the MaaS offering can be viewed as a digital service [9]. Here advanced automation and robotic capabilities have a major role in enabling digital MaaS offerings.

Two basic architectures of manufacturing systems are emerging: integrated and open. The integrated architecture is amenable to disruptive products and technologies, e.g., simultaneous invention of a new material, manufacturing process, and a product. Currently, commercial offers of “production as a service” follow this usually leading to proprietary systems with the risk of platform vendor lock-ins. Open manufacturing would involve decoupling of the design, logistic, and service layers from the physical assets. The open manufacturing enterprise will be amenable to the X-as-a-service mode, where X is, e.g., manufacturing, supply, and distribution [10].

One of the most advanced developments toward open manufacturing is the smart factory web (SFW) initiative, aiming to form a network of smart factories with flexible adaptation of production capabilities and sharing of resources and assets to improve order fulfilment [11]. The idea is also to provide a marketplace for industrial production that mediates between production orders and registered factory assets and capabilities. Service providers in SFW can be connected to the SFW platform, enabling secure data and service integration in cross-site application scenarios as well as “plug & work” functions for devices, machines, and data analytics software [12]. This is based on applying open standards, like Open Geospatial Consortium (OPS) SensorThings, IEC 62541 OPC UA for connecting machines and sensors, and Automation Markup Language (AML, or AutomationML) over International Data Spaces (IDS) for secure communication and data exchange and service integration in cross-site application scenarios as well as “plug & work” functions for devices, machines, and data analytics software [11]. Considered manufacturing service operations include computer numerical control machining, three-dimensional printing, urethane casting, sheet metal fabrication and injection molding, which are all much related to the use of numerical control (NC) machinery and does not consider the details and links to autonomous robots as we do by our skill-based robotics approach. We extend the services towards using autonomous mobile robots (AMRs) and include versatile handling of products and parts with robots, which involves higher number of interoperation between other field devices and rely on wider set of data. We count ourselves also among the first ones to apply IDS architecture in real robotic systems.

2.2 Data sources for configuring robotized manufacturing operations

Implementation of agile manufacturing services implies essentially sharing of manufacturing related data and information across enterprise borders. Service and data orientation enables flexible take-up of comprehensive set of manufacturing operations, provided the needed information is available through enterprise borders. On the other hand, service and data orientations also imply the device operations in manufacturing facilities to be organized in an appropriate, i.e., parametrized and configurable way.

Automatic robotized manufacturing operations require detailed data especially concerning the geometric aspects of parts and products. Recipes with bill of materials (BOM) are the core of data for any product. Product recipe and BOM are often understood with the same meaning and distinguishing between these may be vague. Basically, BOM can include the same information as a recipe, i.e., include, in addition to the parts and materials, also the process steps (“procedure” of the recipe in some systems). Recipes are used to setup equipment to produce a given product or to put it in a given mode. If a machine can run many different products and each product has different settings, then the need to manage recipes is essential [13]. The BOM is composed only of the materials necessary to manufacture the product, while the recipe includes the steps to be executed and the resources required. The engineering bill of materials (EBOM) is organized according to the design of a product, but having an accurate manufacturing bill of materials (MBOM) is even more important because it provides details on all the parts required to build a final product. The MBOM is structured to support how parts are manufactured and a product is assembled [14]. The MBOM is a different arrangement of the EBOM that can be optimized for manufacturing purposes, e.g., to change assembly ordering of parts or subassemblies to comply with the manufacturing constraints. The MBOM also lists the transformational stages of a product, such as an aluminum component requiring a powder coat finish before being bolted onto a final assembly. Then, the component must be listed on the BOM in both its pre- and post-coated form [15].

An MBOM can be created from a template that links to a recipe for searching the EBOM for required parts and determines the parts to be manufactured (Figure 1).

Figure 1

From EBOM to MBOM with a recipe and MBOM template (adapted from [16]).

MBOM is based on the EBOM, representing the expected end product, with additional information not needed during design, e.g., packaging material, assembly process information, tooling, work instructions, paint information, etc. [17]. In our case, a recipe introduces handling instructions, processing instructions, and assembly instructions, which at best link directly to abstract robot operations and further to available devices. The robot operations are described in the form of parametrized robot skills. As the MBOM introduces the material and geometric specifications of final part or product, it provides the link to detailed design data from which related skill parameter values can be derived and computed.

Instant configurations and reconfigurations of manufacturing systems and equipment lay the basis for truly agile operation. We consider especially distributed control of robot systems, where a variety of control modules and functions need to be managed, with distributed embedded or automation systems. It is notable that requirements for robotic tasks and systems cover both workflow sequences as well as metric constraints in the task space. In general, the latter ones need to be mapped to the robot capabilities, i.e., in the form of ranges, accuracies, speeds, and forces in the Cartesian task space. We introduce the use of control recipes in the form of handling paths for robots, for which, to the best of authors’ knowledge, no solutions have not yet been presented.

2.3 Robot skill models

Pure hierarchical control rarely satisfies the needs for robot tasks, and more relevant is the integration and operation of robots and tools collaboratively with sensor systems. Robust operation implies behavioral models, where use and integration of sensors into robot operations is essential. This is represented by the “skills” of robots. Boada et al. defined a skill as a high-level entity, a sensory-motoric decomposition pattern, decomposed to action and trajectory level representations [18]. At best, the skills are highly re-usable and applicable in varying situations and if the skill layer is object dependent and tool independent, it provides a flexible programming interface, relying on a device level setup. Re-usability can be supported by simpler, or conversely by more complex skills [19].

Collaborative robotics have become an essential part of agile manufacturing, and concerning collaborative robotics, skill models should also be compared to digital work instructions so that alternative work allocation from robots to human operators can be supported. Work instructions should react as BOMs change for a particular model and should be capable of displaying individual tasks with different instructions based on a BOM or model difference [20]. Digital work instructions are composed by identifying the basic work steps and record time for each step, and a schematic picture of the work area and the operators’ workflow are drawn as a standardized work chart. Relying on product model geometries, it is possible to animate all work motions and the tools are pointed out and color-coded – this works in practice as a simulation of the workflow. [21].

Skills can be represented in a hierarchical or multi-layered way. Skills can be compositions of skill primitives, and tasks compositions of skills. Finally, the objective of the robot is a composition of tasks [22]. Skill parametrization is crucial for re-configurability and avoiding application specific reprogramming, from which, however, there are only few examples available [3]. Device level automation is typically based on product specific programs of robots, sensors, and tools, but we use configurable skill programs, which enable creation of service manufacturing offerings without any reprogramming of the production devices (robots, tools, and sensors). Skill modeling has been much focused on describing the dynamic operation with and within skill models, but skill parametrization has received little attention. Our contribution has been to concretize this aspect with practical examples.

3.1 Overall architecture

Our vision for future production is automation of customized and special products, implying specialized manufacturing technologies and optionally highly skilled human operators. The organizations and structures for manufacturing facilities will become dynamic, and many resources will be available as needed and organized in a service-based manner. This concerns especially discrete operations without or in between heavy NC machinery in manufacturing shops. We are sharing the ideas of “Enterprise-in-Motion” and “MaaS,” digital transformation through the automation of value streams [23], which involves participants from multiple business units and involves IoT components and enterprise applications: all collaborating for optimizing the target services. We will see such a drastic change taking place in future manufacturing.

Figure 2 presents our view on an overall architecture of the general context for MaaS as an ArchiMate model. For more details concerning ArchiMate modeling, refer ref. [24]. The model is expressed in terms of main drivers, value co-creation goal, stakeholder roles (departments or separate legal entities) involved with their value co-creation roles, and the information systems and capabilities (knowledge, skills, and resources) which the stakeholder roles own and govern as part of the overarching value co-creation goal.

Figure 2

The general architectural context for MaaS as an ArchiMate model illustration.

As illustrated in Figure 2, enabling data-driven configurable automated “lot size 1” production with MaaS involves many different stakeholder roles in the overall value chain. The stakeholder roles can be taken by one legal entity (departments of a same company), or by separate legal entities (specialized companies). The most central ones for MaaS are the retailer (initiating a digital product order), product design organization (producing a digital product and manufacturability design), and the manufacturing organization (providing MaaS based on digital order and digital product and manufacturability design information). Accordingly, especially if the stakeholder roles are taken by different legal entities (specialized companies), MaaS requires digital transactions and trusted data exchange between the entities involved. Even though the digital transactions and trusted data exchange can technically be implemented as point-to-point integrations between the information systems of the interacting entities, this often-used approach introduces considerable delay (an IT integration project between the two entities), rigidity (value networks instead of ecosystem), and undermines the full potential of MaaS concept. To overcome these downsides, the International Data Spaces Association (IDSA) [25] is standardizing the trusted data exchange solution based on the Industry 4.0 vision. The IDSA solution architecture is based on the IDS connectors and IDS broker [26], as illustrated in Figure 1, and enables creating trusted industrial data spaces and exchange data within those. The benefit of the IDSA solution for MaaS is that it provides a certification scheme for trust and the IDS broker enables dynamic discovery of trusted entities for data exchange. This enables dynamic ecosystem type co-operation and data exchange, where the delays and rigidity caused by the current point-to-point IT systems integration approach can be avoided and MaaS can be offered in ecosystem setting widely for different customers.

3.2 Functional hierarchy with robot skills

In our case, we distinguish, from highest to lowest levels of operations, between missions, tasks, skills, and primitive actions, all of which are parametrized and can easily be setup without additional programming (Figure 3). Parameters are derived from product information (like IDs, structures, geometries, and material properties) and equipment data (like IDs, dimensions, and geometric properties). Task decomposition follows the functional layers with parametric inputs to trigger an appropriate operation: “Transport-and-Assemble” service is ordered from an AMR fleet owner and indoor logistics and part handling service provider, with links to related product specifications in the order. The AMR fleet control system is connected to a shop floor control system of a manufacturing enterprise, and while order has been dispatched, the fleet control system triggers an appropriate AMR unit to transport and assemble parts, from storage locations as parts to locations in manufacturing lines as an assembly. Then, the AMR control system acquires control recipes for object detection, handling, assembly, and transfer, e.g., from the product lifecycle management (PLM) system of the manufacturing companies, and triggers comparable skills like detect object, pick, place, and transfer, with parameters from the control recipes. The AMR control system’s skill control modules finally take care of commanding the physical devices for the primitive device operations, like detect and locate, move, and deliver.

Figure 3

An example of a skill hierarchy for transport and assembly tasks.

3.3 Data sources and parameters for skills

Here we are considering a new scenario for manufacturing: an AMR, i.e., a mobile robot with an industrial robot arm, is working as a transportation unit, but also as a pre-assembly or part processing unit. It collects parts but also carries out preliminary assembly or finalizing operations while transportation. e.g., with pre-assemblies, “Pick,” “Place,” and “Transfer” are the key elementary skills for our exemplary transport and assembly tasks. While carrying out the assembly operations by the mobile robot unit, the recipe must include these skills as the process steps (or production operations), comparably with resource selected as the mobile robot unit. Concerning parametrization and linking to product data for configuration, relevant skills for the new scenario are those which are dealing with the operations with the real environment, i.e., “pick” and “place,” with robot motions and tool operations. Here we take a closer look on assembly operations, and have less emphasis in the finalizing and transportation tasks.

Product knowledge should enable automatic setup and configuration of the needed robot skills and that information is available from the product BOMs and related recipes. We present the related product knowledge for handling and assembly instructions (or procedures) as production operations in the recipe related data, and related poses (or coordinate frames) in the part CAD files. These are implemented as meta-data or user defined attributes in the model files, describing how to carry out details for assembly: approaching motion for grasping and motion of the robot gripper to grasping position (Figure 4).

Figure 4

Handling knowledge as approach and grasp poses in part coordinate frames, for a bushing (a) and for a peg (b).

Handling instructions are first utilized in transport operations, in getting the parts from the storage buffers or buffers in the production cells. After getting the parts, the mobile robot unit will carry out the assembly or finalizing operation, here in the case of assembly, inserting a part, i.e., a peg into another, e.g., a bushing. This should be done based on the assembly knowledge (or instructions), also expressed as operations in the recipe and related object poses in the product CAD file, describing the part locations before and after being assembled (Figure 5). The grasped peg is brought to the approach position, after which the peg will be inserted into the bushing according to the poses in the assembly instructions.

Figure 5

Assembly knowledge as approach and grasp poses in part coordinate frames, for a grasped peg before (a) and after (b) assembly motions.

4.1 MaaS case: logistics and pre-assembly as a digital service

Our case example considers manufacturing operations where transportation and robot operations are carried with tight integration between a manufacturing company and its logistics service provider, fully automatically driven by digital data exchange. This compares to a situation, where the roles of contractors, like indoor logistics service providers are expanded: an indoor logistics operator not only transports parts and components from storage areas to production lines, but also carries out some preparatory operations. For efficiency, the whole chain of operations, from handling in storage areas and production lines to assembly operations must be fully data driven and automatic, without explicit programming efforts with the real device. This is done at best by run-time configurations of the controlled manufacturing operations.

In our case example, a manufacturing company and a logistics provider collaborate in data driven automated way on business-, information-, and operational levels in the digital service; based on a digital order from the manufacturing company (customer), the logistics provider (digital service provider) provides a digital service of collecting, pre-assembling, and delivering pre-assemblies to production line of the manufacturing company. Figure 7 illustrates the case and the flow of information and activities within it.

Regarding Figure 7, the activities 1&2 mainly represent IT/OT integration and inter-organizational information exchange challenges, whereas the activity 3 represents a challenge for full automation of robotic missions with a mobile robot in a customer factory. Going further in our case description, we mainly focus in activity 3. Figure 6 illustrates an ArchiMate model of the service case in more detail focusing especially on data and functionalities relevant for robot mission control (activity #3 in Figure 7 above).

Figure 6

Service model with data: Manufacturing operation specification compared to MBOM and recipes.

Figure 7

Information flow in the digital manufacturing operation services.

The link to industrial and mobile robot devices are based on skill models, implemented with the devices. The core in the service model is the “Manufacturing operation specification” which is compared with MBOM and related recipes (Figure 8). In our case, the recipe descriptions have been created for the handling skill “PickAndPlace” and assembly skill “PegInHole.” It includes the BOM, assembly instructions and handling instructions. In addition, links to part design models as geometry data are provided. It is worth noting that “peg-in-hole” and “hole-in-peg” use the same PegInHole assembly skill, but with different object instances (hole → peg; peg → hole), Figure 9.

Figure 8

Data model for “Manufacturing Operation Specification” for assembly operations (compared with MBOM and recipes).

Figure 9

Generic assembly instruction PegInHole compared with “peg-in-hole” (upper right) and “hole-in-peg” (lower right).

Transportation tasks are an in-built part of our manufacturing service operation and are integrated to the service operation using factory layout data. The service order must include references to the layout in the form of storage locations and line or cell locations, where the part handling takes place according to the handling instructions. We use a simple data model for this, with source and target locations connected to the route map of the mobile platform (Figure 10).

Figure 10

Data model for “Manufacturing Operation Specification” for transport operations (compared to MBOM and recipes).

4.2 Integration to PLM systems

The information of product models and recipes was implemented in a PLM system, in our case ARAS Innovator [27]. In the integration to the manufacturing system, a reliable and safe cross-enterprise connection was emulated using IDS connectors between two servers (“Willab servers,” Figure 11). IDS connectors enable data exchange across company boarders in a trusted manner.

Figure 11

System architecture: integration of the shop floor devices and PLM systems of different parties via IDS.

In our implementation, there are two IDS connectors: data consumer and data provider. Data consumer is the client side IDS connector that forwards REST requests to server side IDS connector (data provider), which again forwards the requests to the actual PLM system. In this way, the IDS connectors operate as proxies to the corresponding REST services in the PLM system. The connection to the robot control and high-level mission control was carried out implementing a REST client for the ARAS PLM system, which implemented the corresponding skill configurator, i.e., acquired the skills to be used and related parameters from the PLM.

5.1 Evaluation experiment 1: transportation and assembly services

The first experiment was a demonstration where a MIR100 mobile platform with UR10e arm performed a pre-assembly task. An on-board mission controller of the mobile platform controlled the workflow by trigging the handling and assembly skill controllers with proper skill parameters. Two parts of an assembly were retrieved from a storage area, assembled and further on delivered to a production line. The parts’ location was known, and the mobile platform moved to the correct place in the storage area. A 3D-vision system was used to find the parts on the storage shelf and handling skill parameters (i.e., instructions) were acquired from the server (emulating the PLM system) for each of the parts with the services specified in the model. The robot arm then used the combination of the instructions and the 3D vision to pick up and place the parts on board of the mobile platform.

The assembly instructions were acquired from the server and they were used by the robot arm in combination to the handling instructions to assemble the parts. The platform then moved to the production line where the parts were delivered using the handling instructions for the assembled piece (Figure 12). The whole operating sequence is illustrated in Figure 13.

Figure 12

Handling poses: grasped bushing in an assembly target pose, and a grasping pose for an assembly.

Figure 13

Indoor parts logistics: transportation and assembly operations guided with on-board 3D vision.

5.2 Evaluation experiment 2: finalizing operation services

The second experiment (Figure 14) was a demonstration where a KUKA KR210 robot and MIR100 mobile platform with UR10e arm performed a hole finalizing operation. First, the finalizing process was specified in the ARAS PLM system as a set of parameters for finalizing skills. The specification was implemented as product meta-data. Second, in the task execution, the skill parameters were acquired from the ARAS PLM server, and the skill execution requests were synchronously sent to the robots, which replied when they were done.

Figure 14

Detection and deburring of holes.

The finalizing process was divided into five tasks: simulated drilling of the holes, moving mobile robot into the work area, handing the part to mobile robot, simulated deburring of the holes, and picking and placing the part into storage. The first task was handled by KUKA KR120, the second by MIR 100, third again by KUKA KR120, fourth by UR10e, and fifth by KUKA KR120. 3D vision was used by UR10e to localize the holes.