Resource Interface Matchmaking as a Part of Automatic Capability Matchmaking

The capability matchmaking relies on different information models that are used to describe the resources and products in a formalized way. For each different resource, a resource description (RD) file (in XML format) is created and published by the resource provider. These files are saved to different catalogues, either global or local, from where the potential users, in this case the capability matchmaking software, can then utilize the descriptions. The resource description represents the basic characteristics, capabilities, interfaces, and properties of the resource. It can contain links to documentation, CAD models and to illustrative figures. One essential part in the resource description is the capability description of the resource, which selects the relevant capabilities and their parameters from the Capability Model.

Central information model for the matchmaking is the Capability Model. The Capability Model is a formal ontology model which is used to model capabilities and their relations. Capability consists of concept name, such as “Drilling”, “Milling”, “Moving” and so on, and parameters, such as “payload”, “speed” or “torque”. The model consists of simple and combined capabilities, where combined capabilities are combinations of simple capabilities. For instance “Picking” is a combined capability which requires as an input “Moving”, and some sort of “Grasping” capability. The capability model forms a capability catalogue, which is a pool of capabilities that can be assigned to resources to describe their functionality. [12]

The Resource Model Ontology imports the Capability Model and is used to describe manufacturing resources and their capabilities. An instance ontology of Resource Model can be automatically created and populated by reading in the information from RDs. The Resource Model can also be used to model systems composed of multiple resources. Based on the relationships between simple and combined capabilities, it is possible to identify potential resource combinations that can have a certain combined capability. [12]

The Resource Model imports another ontology, called Resource Interface Model, which describes the resource interfaces in detail. It is used during the matchmaking for checking the compatibility of the resources from interface perspective. In other words, it is utilized to assess if two resources can be connected physically together. It includes information about interface definition, including identifier, name, category, gender and purpose of the interface; Interface standard and its characteristics and the standardisation organization; Interface port implementation. [13]

Also, the product requirements are described using formal Product Model ontology. The Product Requirement Description (PRD) contains information about the parts, how they are connected to assemblies and what kind of processes and process parameters should be used. The Product Requirement Description uses the same concepts that are involved in the Capability Model. Thus, there is a link between the resource capabilities and process requirements of the product. [11]

Figure 1 represents the capability matchmaking process. The Capability Matchmaking is implemented as a service [14] that the System Designer may call through his desired planning system. When the designer wants to launch this service, he will have to give it certain inputs, for example the matchmaking search space. This input includes description of the resources that should be taken into consideration during the matchmaking, and description of the product (i.e. the PRD), for which a match will be looked for. Thus, the resources and product requirements need to be formally described before the capability matchmaking process can be initialised. These resources in specific search space are automatically processed and read in from RDs to form a Resource Model instance ontology. The input related to the resources may be either a description of the existing system layout (i.e. a resource hierarchy building a system layout) or pool of resources selected from one or various resource catalogues. In the latter case, the input is in form of a flat list of resources creating a resource pool. The Capability Matchmaking software will then process these inputs and provide the matchmaking result to the designer. The result includes information about the resources and resource combinations matching for each process step of the product requirement. This information can then be further processed in the system designer’s planning tool where the desired resources are selected according to some company or situation specific criteria. [14, 15]

The capability matchmaking involves two aspects: Generation of new resource combinations and matching the capabilities of these combinations with the product requirements. The process flow is illustrated in Fig. 2 from left to right. First, the matchmaking system generates new resource combinations that have capabilities requested by the product, e.g. “Screwing”. Next, the interface compatibility of the resources is checked based on the interface matchmaking rules [13, 16]. After that, the combined capability parameters are calculated for the remaining resource combinations based on the combined capability rules. Finally, when the resource combinations have been created and their combined capabilities have been calculated, these combined capabilities are compared to the characteristics and requirements of the product. For this purpose, capability matchmaking rules are used, which find out which resource combinations answer the requirements of the product. The combined capability rules have been introduced in [17] and matchmaking rules in [11]. Both have been implemented with SPIN rule language (SPARQL Inferencing Language).

This case focuses on a single process step, which defines the requirement for fastening two parts with a M6 sized screw with socket head cap (socket size 5 mm). The required end torque is 13..17 Nm. The matchmaking for this process step is illustrated in Fig. 3, which shows only a subset of our complete test data. First, the matchmaking will create new resource combinations from the available resource pool for the required capability at capability concept name level, i.e. resource combinations that could provide “Screwing” capability. The available resources in the resource pool are illustrated in the up left corner in the figure, while the first phase presents four different combinations created by the matchmaking software. While creating these combinations, matchmaking software will simultaneously check that the interfaces of the resources match at fine level, and that the resources can be physically connected. In case of the resource combination (b) on the second phase, the tool bit does not fit into the screw driver’s tool interface and thus incompatible combination from interface perspective is filtered out.

After that, the matchmaking system will calculate the combined capability parameters for the remaining combinations and check that the capability parameters match with the parametric requirements of the product. During the combined capability calculation, the matchmaking system considers each individual resource and calculates the viable range for the whole combination. I.e. if a tool bit can bear only a certain torque, it can be limiting the overall torque for the whole combination. The combined capability SPIN rules are used for inferring the combination parameters and matchmaking SPIN rules are used to compare the parametric requirements of the product with the capability parameters. In this example case the matchmaking system will check that the screw type and screw head size matches with the tool size and that the provided torque is within the range of the required torque. Unsuitable resources and resource combinations are again filtered out. In this case the combination possibility (a) (in phase three) does not provide enough torque, as it limits in maximum to 6 Nm, and it is eliminated from this result. In the end, only the two suitable resource combinations are left as suggestions in the matchmaking result.

Within our practical test data, the resource pool used for this specific case had 68 resources. 530 resource combinations providing “Screwing” capability where found, and 36 out of those was found compatible from the interface point of view. Combined capabilities were calculated for these and finally two resource combinations were found feasible for the given product requirement. These were presented in Fig. 3.

Table 1 shows interface details for the resources used in this case example. Interface port is a placeholder for interface(s) used for a specific function. Interface standard identifies the code of the standard used. Gender sets the polarity of the interface implementation. Additional interface characteristics define properties characterising the interface, such as size and shape in this example. Comparison operator defines how a characteristic should be used in the compatibility evaluation. In this case operator is ‘SAME_SET’, which means that at both sides of the connection, the characteristic value(s) must be the same to allow successful connection.

In Fig. 3. we have the first resource combination (a) from resources 1, 5 and 9. The interfaces allows the combination (See Table 1) – driver (1) has fitting interface (IF1) with the tool bit (5/IF1) at standard, gender and all interface characteristics. Driver (1) has also fitting interface (IF2) with the operator (9/IF1) moving the driver. But later, the combination (a) fails to fulfil the capability parameter requirement for generating enough output torque. The second resource combination (1, 6 and 9) fails at interface matching. The gender of driver (1/IF1) and tool bit (6/IF1) does not match, and even it would, the interface characteristics are not fitting (See Table 1). This would be the case if driver (1/IF1) is tried to connect with tool bit (7/IF1), when the interface characteristic C.Size will prevent the connection. In case of the resource combinations (c) and (d) both interface and capability parameter requirement are matching, leading to propose resource combinations (3, 7, 9) and (2, 6, 9) as a match and potential solution for this product requirement.

Another case example focuses on pick and place case. Similar kind of case was discussed as test case in [13]. The handled part is cylinder shaped having diameter of 44 mm and length of 30 mm and it weights 50 g. The product requirement defines following needs for the process step: grasping is done externally, maximum allowed compressive force is 10 N, transportation is needed in XYZ-directions (linear movements), and positioning accuracy is 0.2 mm.

Within our practical test data, the same resource pool with 68 resources is used as in the previous case. It contains two grippes and seven moving devices. The capability name level matchmaking found 12 potential combinations providing “pick and place” capability, and four out of those were found compatible also from the interface point of view. Combined capability parameters were calculated for these and finally three resource combinations were found feasible for the given product requirement. In this case three different robot arms are found mating with one of the grippers. Resource combination (a) from resources 4 and 1; (b) from 5 and 1; and (c) from 6 and 1 (See Table 2). The resource (4) demonstrates use of several standard interfaces for same interface port. In this case the Schunk-SWS interface is implemented with help of an adapter plate, thus a tool fulfilling either of these standards can be connected to this interface port. In case of resource combination (c) the gripper has two interface ports where the connection can take place – 6/IF2 and 6/IF3. The current version of interface matchmaking does not count or reserve the interface ports, but match is returned if there is any suitable position for connection. The fourth resource combination (d) is a manipulator (3) mating with the gripper (2) (See Table 2), but it provides motion only in two degrees of freedom, thus getting neglected from the result.