Keyword

1 Station Control in Line-Less Mobile Assembly Systems

The trend of consumers demanding individualized products requires adaptable and flexible production and therefore adaptable and flexible assembly systems [1]. The paradigm of Line-less Mobile Assembly Systems (LMAS) offers a solution for realizing such an assembly system based on the three principles: Mobilized resources, a clean floor approach, and dynamic job-routes [2]. To ensure the adaptation of stations in LMAS to new tasks, each new task involves checking which resources provide the capability to perform the allocated task, which has been done manually beforehand. Therefore, the objective of this paper is to provide a framework of the two necessary steps for formation planning in a flexible assembly station: a formalized representation of assembly resources and their capabilities and a task allocation based on this representation [3, 4]. Accordingly, the paper aims to answer the research question: How can assembly tasks, assembly resources and boundary conditions for automated task allocation be described? The resulting framework is intended as a foundation for adaptive assembly station planning through feasibility checking, whereby the offered capabilities of the resources and the requested requirements of the tasks are matched.

The remainder of the paper is structured as follows: In Sect. 2, the related work on assembly resource modeling, capability modeling and task allocation is reviewed with regard to applicability for formation planning in LMAS. In Sect. 3, the methodology followed while developing the framework is summarized. Section 4 introduces the methodology’s results and details the derived conceptual schema of the ontology and the task allocation. A use-case-specific implementation on operation level is presented and its performance is evaluated in Sect. 5. Finally, the results are concluded and future work is presented in Sect. 6.

2 Related Work in the Context of Station Planning in LMAS

LMAS enables dynamic adaption to changing demands through temporal and reconfigurable layouts (formations) of assembly stations. The task-depending and ever-changing formation of the heterogeneous and mobilized resources in assembly stations requires adaptable formation planning and task allocation [2]. The foundation for automated task allocation to assembly resources is a consistent and formal modeling of the resources, their capabilities and their taxonomy as a digital representation [4, 5]. Ontologies provide a means of formally representing knowledge by describing instances and their relations, and are thus suitable for modeling resources and their capabilities in the manufacturing domain [6].

In the following, the imposing requirements on a capability-based resource allocation ontology for a station in LMAS are detailed. The ontology has to be scalable, to be enhanced with new classes and instances representing newly integrated resources. It has to enable queries for assembly resources and their capabilities to allocate resources to assembly tasks depending on availability and requested capabilities [4]. Considering cooperating resources or changing capabilities depending on equipment and tools, it has to provide inheritance of combinational capabilities. For station control, the time-relevant update of properties (e.g. a resource being idle or not idle) must be included [2]. To allow for task allocation the transfer of query results to third-party software has to be implemented. In the following existing ontologies and frameworks will be evaluated with regard to these requirements.

The Product Resource Order Staff Architecture (PROSA) provides one of the first semantic representations intended for smart manufacturing. However, it leaves matching capabilities to requirements for future research [7]. MANDATE defines an International Standard for representing manufacturing management data, including the product, process and resource paradigm [6]. The “Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0)” for information systems defines a reference architecture of technical assets and their relevant aspects throughout their entire life cycle [3].

With MAnufacturing’s Semantics Ontology (MASON), a semantic net as an upper-level ontology for manufacturing was presented, including entities, operations and resources, but lacking a representation of capabilities [8]. In the BaSys 4.0 ontology, modular resources provide combined basic and slave capabilities orchestrated by master capabilities. BaSys 4.0 includes querying by matching requested and provided capabilities, but excludes task allocation to individual resources. [9] Weser et al. aim to create an upper-level ontology (C4I) enabling matching of provided capabilities of resources and the required capabilities to fulfill the task. They define capabilities as a hardware-agnostic representation of the resources’ functionalities, consisting of sub-capabilities. C4I lacks the means of allocating tasks to individual resources. [5] In the Manufacturing Resource Capability Ontology (MaRCO), the four classes of product, process, capability and resource are differentiated. Combined capabilities are modeled in an analog approach to C4I: The combined capabilities result from cooperating resources or a combination of resources to an aggregated resource [10]. A wide-ranging review of ontologies intended for robotic utilization can be found in [11].

Currently, ontologies can be queried for matching the task’s requested capabilities to resources’ provided capabilities, resulting in a list of individual or combined resources that provide the requested capability. For formation planning, it is necessary to allocate one specific resource to one specific task. No ontology fulfilling all stated requirements is publically accessible to derive an ontology for task allocation for stations in LMAS. Currently, the planning of formations of mobile resources in LMAS takes place manually. Due to the manual process, reconfigurable stations in LMAS are still inefficient for industrial applications, especially for prototype production and lot size one.

3 Methodology and Foundations

This research aims at developing an ontology-based task allocation framework as a foundation for station planning in LMAS. Varying methods of creating such a framework can be found in the literature. For building the domain ontology, the broadly accepted seven-step procedure according to Noy et al. [12] was followed due to its application-oriented structure. Moreover, the first two steps (definition phase: developing an ontology and modeling phase: modeling of a use-case) of the digital twin pipeline of Göppert et al. were applied [13]. Finally, validation and verification are carried out following Sargent et al. and Gómez-Pérez through application ontology and performance testing [14, 15].

The conceptual ontology is built in Protégé using the Web Ontology Language OWL. OWL is a machine-readable knowledge representation language that enables the derivation of implicit knowledge from explicitly defined knowledge by reasoning systems [9]. OWL allows for reasoning based on semantic and syntactic rules, thus being formal and allowing for capabilities to be inherited from one instance to another and composing of capabilities of other capabilities [12].

4 Capability-Based Resource Allocation Ontology CAPILANO

In the following the first phase of ontology-based modeling, the definition phase, according to Göppert et al. [13], is described and the conceptual CAPabILity-based resource AllocatioN Ontology (CAPILANO) is presented. The broadly applied concept of dividing assembly systems into product, process and resource of Martin et al. was followed. We focus on the resources and their allocation to tasks through capability-matching, defining a process as a set of tasks [11, 16].

The resource class consists of the heterogeneous individual resources (class objects) and the associated capabilities of the individuals. Table 1 provides an example of the individual FASIMA_ABB4600 of the resource class “ABB_4600” and its parameters. According to RAMI 4.0, resources are assumed to be an entity, i.e., a uniquely identifiable, represented, and known asset [3]. Consistent with the definitions of RAMI 4.0 [3] and PROSA [7], the resources follow the definition of an asset or holon. Thus they can be delimited individually but may also be composed of other resources. Resources have a defined boundary, can be composed of other identifiable resources, can be combined to form resources and be assigned a value and a purpose. [3, 7] The utilization of individual parameters was adapted from MASON [8], PROSA [7] and PMK [17]. The actual static and dynamic parameters were adjusted from MASON [8]. The interaction of these parameters with the capabilities was adapted from PROSA [7] and PMK [17].

Table 1 Example of the robot resource class ‘ABB_4600’ of CAPILANO
Full size table

Following Kluge, we assume capabilities to be describable by referring to the elemental assembly operations defined in standards and guidelines such as VDI 2860 and DIN 8580, 8582, 8588, 8592 and 8593 [18]. Here we define capability as a hardware-agnostic means of fulfilling a function. Capabilities are defined as classes and are assigned to the resources through the class restrictions adapted from MaRCO and C4I [5, 11]. To model the resources’ capabilities, the functional methodology from MaRCO [11] and specifications of the VDI 2860 are adapted, inheriting the concept of combinatory capabilities. In contrast to MaRCO, parameters like ‘Payload’ are assigned to the capability class instead of the resource class, allowing for easier adaption through changing the individual itself instead of an entire class. Simple capabilities are directly assigned to the individual resources, therefore represented as individual parameters. Complex capabilities consist of multiple simple capabilities, as visualized in Fig. 1. Depending on the related capabilities, a resource inherits these parameters [7]. For example, if the individual ‘Gripper’ has the individual parameter ‘GrippingForce’, the ‘Gripping’ capability inherits this parameter. The combined capability combines the capabilities and the related individual parameters resulting in the capability parameter. For example, the resource ‘mobile manipulator’ consists of the resource ‘robot’ and ‘AGV’ and inherits the following capabilities: ‘EndEffector’, ‘Positioning’, ‘Transporting’ and assuming the end effector ‘ScrewDriver’ e.g. ‘Screwing’. The inheritance process itself is adapted from the MASON ontology [8].

Fig. 1
figure 1

Combined capabilities and their properties in UML

Full size image

Figure 2 presents CAPILANO as the main result of the definition phase, depicted with the related ontologies. Compliant with the development phase defined in Göppert et al., elements of existing ontologies were inherited, adapted and extended.

Fig. 2
figure 2

Ontological approach and inheritances towards CAPILANO

Full size image

5 Task Allocation Framework

The conceptual framework for task allocation is depicted in Fig. 3. The framework consists of a means of storing and retrieving data (data lake), converting this data into a tailored schema (data conversion), querying the data in the ontology (here: CAPILANO) followed by allocation of the querying results, and converting the results back into a storable data format and thus closing the circle to the data lake. Realizing the framework’s goal to match the task’s requirements to the resources’ capabilities, the process of querying and consecutive task allocation is detailed below. The resulting framework can be found under: https://github.com/AKlugeWilkes/IoP-CAPILANO.

Fig. 3
figure 3

Conceptual framework including the ontology, task allocation and interfaces

Full size image

In a pre-processing stage, CAPILANO, including the resources and provided capabilities, is extracted. Moreover, the input process chart is retrieved from the data lake and converted into a custom schema adapted from MaRCO [11] and the C4I metamodel [5]. The process chart contains the required capabilities to perform the tasks and the task order.

During the processing step, querying and task allocation are carried out. For querying, the requested list of capabilities of the process chart is converted in a SPARQL query by the Python-based Cython Phaser. Figure 4 visualizes one query loop for the capabilities of ‘Screwing’, ‘Positioning’ and ‘Transporting’. The SPARQL queries are forwarded to the JAVA-based HermiT Reasoner and the output is cached by checking the compatibility of capabilities and inferring implicit capabilities [19]. At first, individuals, which provide the requested capability are identified (e.g. ‘ScrewDriver_1’ and ‘ScrewDriver_2’ for ‘Screwing’), then the HermiT Reasoner checks for combinable capabilities of the resources, e.g., if a capability is required, which could be provided by a specific robot in combination with a particular end-effector (here: ‘ScrewDriver_1’ and ‘MobileManipulator’ are combinable through ‘EndEffector Type 01’). This function facilitates the combinatory capability inheritance requirement. If several resources match the capabilities, they are chosen in descending order, thus in the first query loop, the one with the closest matching parameter is selected (e.g. a payload of 20 kg is requested a gripper providing a payload of 25 kg would be preferred over one providing 40 kg), represented in Fig. 4 by a white square. The loop continues until all possible combinations of resources are listed in descending order. Once the Cython Phaser processed all queries, the cached results are converted into CSV/TSV and forwarded to the task allocation step. (Depending on the interchangeable third-party system carrying out the task allocation, this conversion could be adapted, providing compatibility to other programs.) During task allocation, the best possible resource is selected. The ‘best’ is currently defined by the criteria 1) necessary equipment is already equipped on the robot 2) highest battery charge 3) the first item of query list.

Fig. 4
figure 4

Querying for ‘Screwing’, ‘Positioning and ‘Transporting’ in CAPILANO

Full size image

During post-processing, the list of allocated resources and tasks is converted to be OWL readable and the results are integrated and updated in CAPILANO.

6 Evaluation and Results

According to Gómez-Pérez [15], the fulfillment of the evaluation criteria consistency, completeness and expandability were investigated to validate and verify CAPILANO. Consistency was proven by deriving the inferred hierarchy of the asserted hierarchy of CAPILANO with the HermiT Reasoner and applying the ROMEO (Requirements-oriented methodology for evaluating ontologies) methodology [20]. To verify the correct implementation and programming of the conceptual ontology (computerized model verification), the ontology taxonomy evaluation and a comparison of the asserted and inferred hierarchy were applied [14].

An application ontology was implemented to validate the framework within its intended scope and determine whether its output behavior provides an acceptable accuracy [14]. Use-case-specific instances are modeled according to the conceptual ontology, creating a knowledge base/description model on an operational level, consistent with [8, 13] and [12]. The process of truck chassis assembly is used as an application scenario: The parts ‘cross member’, ‘front member’ and ‘rear member’ have to be transported from storage to the chassis and have to be screwed onto ‘chassis’. To fulfill this process, the capabilities ‘Screwing’, ‘Transporting’ and ‘Positioning’ are requested with differing property parameters of acceleration, velocity, jerk, etc. As resources, several stationary robots (ABB_4600, ABB_2600), mobile robots (Kairos) and equipment (gripper, screwdriver) are available, which provide the requested capabilities in varying resource combinations.

Based on the application ontology, the framework’s performance is analyzed by measuring the time to process a task allocation. Twenty unique queries with varying degrees of complexity were created and used as the seed for a randomizer to generate processes charts. Five process charts with the same number of queries, but unique randomized queries are processed for each data point. The run-time of these five charts is averaged to ensure uniform distribution of complexity within the five process charts. The queries and process charts can be found here: https://github.com/AKlugeWilkes/IoP-CAPILANO/tree/main/03_Evaluation.

The graph “Average runtime vs. number of queries” a) in Fig. 5 presents the scaling performance of the ontology. The querying was carried out for 5, 25, 50, 100, 250, 500, 1000, 1500 and then every 1500 queries. Based on the test data, it shows linear scaling behavior. The graph “Runtime per query vs. number of queries” b) in Fig. 5 along with an R-Squared trendline, presents an upward trend, representing a non-linear behavior. Linear behavior is obtained when normalized to an error percentage of 0.8385. It is concluded that the developed ontology has a linear scaling behavior within a margin of 0.8385%.

Fig. 5
figure 5

Runtime analysis depending on the number of queries

Full size image

It was shown that the developed framework is scalable as one can integrate new entities for application and inherit other ontologies. As visualized in the figures above querying and matching resources to tasks based on the required and provided capabilities was realized through SPARQL querying and Python-based allocation. Capabilities resulting from combining resources to a new one can be inherited from one instance to another. A transfer of query results to a third-party software to enable task allocation was exemplary realized by developing interfaces allowing for a transfer in a Python program and can be adapted for other third party software.

7 Conclusion and Outlook

This paper contributes the ontology CAPILANO. CAPILANO formally describes assembly resources and their combined capabilities as a function of equipment using the Web Ontology Language (OWL). Based on CAPILANO, a framework matching resource capabilities with task requirements and subsequent availability-aware task allocation was developed. Compared to the manual allocation of tasks to resources, automatic allocation requires less time and provides reproducible results. In conclusion, the developed framework supports the planning of mobile assembly stations by displaying possible combinations of resources and allocations to assembly tasks, reducing the time required for task allocation compared to manual allocation.

In future research, the framework will be extended by investigating the spatial and temporal requirements of a feasible formation. Spatial reachability and manipulability of the allocated tasks as well as collision avoidance of the allocated resources will be researched. The task allocation applied will be extended by incorporating criteria like proximity of the resource and the allocated task pose, to optimize production time.

To explicitly integrate a higher degree of detail of the implicitly existing knowledge of humans necessary for automated assembly planning and the subsequent assembly execution into the ontology, the ontology can be enhanced by additional parameters. For example, parameters such as the wear and tear of resources over time or the consideration of measurement systems for localization on a map can be added.