Determining which components are required for a system con guration, and whether they are compatible, can be a di cult task, especially in an industry with signi cant amounts of information that resides within a group of experts. In this paper we illustrate some of the main challenges we and our industrial partner (Technicon) face when con guring a robot system (typically consisting of a robotic arm, end effector, coupling device, and a base) and present our domain model, Robot System Con gurator Information Model (RoboCIM). We formalise the model within a defeasible reasoning framework, in order to explicitly capture cases where information is missing or is obtained from the system integrators' experience. We provide a prototype implementation of the framework in ASP and evaluate it on a subset of components from Technicon's component catalogue, illustrating the feasibility of the congurator.
In the context of industrial robotics, integration is the process of introducing
and merging robotics hardware, peripherals, software, and supporting
technology into a production, or manufacturing line, to automate it [
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
The challenge of con guration is not new. In other areas such as personal computers (PCs), customisation tools have had tremendous success, thanks to standardised interfaces4. These tools are easy to use, contain comprehensive databases, and allow consumers to pick and choose the parts desired based on their performance needs, while ensuring compatibility among the hardware elements.
Our vision, and that of our industrial partners, is that robot con guration
tasks should be as easy as their PC con guration counterparts. Recent
developments [
The challenges described in this paper have been identi ed in the course of our work with Technicon, while assembling robotic cells in the Aarhus University Digital Transformation Lab, as well as discussions with Technicon's engineers. Technicon is a Danish system integrator, that has been in the market for 7 years, and has made more than 300 robotic system integrations. So far, Technicon has been able to successfully operate due to its engineers' extensive experience and internal documentation, determining compatibility constraints between robotic components. However, it recognises the need to formalise these rules, into tools that facilitate robotic system con guration.
The main contributions of this paper are: 1. (Section 3) We report on some of the challenges we encountered. The main factor in these is the uncertainty and incomplete information. 2. (Section 4) We sketch our open-ended domain model, the Robot System Con gurator Information Model (RoboCIM), which describes how to capture knowledge on robot products. We illustrate how to go from product speci cations to a formalised domain model, and how to tackle real world challenges using a rule-based approach.
We give a brief description of the robotic domain in Section 2 and demonstrate the results of our prototype implementation and validation in Section 5, concluding in Section 6.
The robot components and challenges we describe originate from real industrial manufacturers. In order to avoid harming the companies, we have anonymised their names. 2
In this section we describe what a robot system con gurator is and introduce the main components in a robot system that we will use in such a con gurator. For 4 An example customisation tool: https://pcpartpicker.com/list/. the remainder of this paper we will refer to a robot system con gurator simply as a con gurator.
According to [
A robot system consists of one or more robots, end e ectors, and other devices
combined with the robot to perform a particular task [
Without loss of generality, we focus on robot systems consisting of the components between the robotic arm and the tool, i.e. we do not consider the base that the robotic arm is mounted on. The reason for this choice is that these components cover a wide range of 10+ manufacturers. Most of these components have mechanical and data interfaces, which are used to connect them with other components. We brie y describe each of the components and their relevant characteristics below.
Robotic
arm Base
End effector End effector coupling device
Robotic
arm Base
End effector Flange adapter
End effector
coupling device
(a) Example Setup A
(b) Example Setup B
Robotic Arm has mechanical, data, and electrical interfaces. The tip of the
robotic arm is called the robot ange. The mechanical interface of the robot
ange is described using the ISO 9409-1 standard [
End E ector Coupling Device (EECD) has two mechanical interfaces, one for connecting with the robotic arm, and one for connecting with the end e ector. It also has an electrical interface for supplying the current from the robotic arm to the end e ector.
Flange Adapter has two mechanical interfaces, as it adapts from one interface to the other in order to be able to connect a robot ange to an EECD with a di erent mechanical interface.
End E ector is connected to the tip of the robotic arm, and is application speci c, i.e. gripper for Pick and Place, screwdriver for Screwdriving applications. The end e ector has a mechanical interface that connects to the EECD. Typically, both the end e ector and EECD are developed by the same manufacturer. Data Connection can be provided using di erent components, such as a Data Cable or a Data Control Box. The Data Control Box supports more communication protocols. 3
In this section we describe four main challenges that were found during the modelling phase of the con gurator. The underlying source of each of these challenges is incomplete information.
CH1: Unexpected Sources of Information When looking for technical information about a product, it is typical to expect this information to be present in the data sheet or technical report of the product. Figure 2 illustrates an example of unexpected sources of information, where the ISO of the robot ange of a robotic arm was not found in the data sheet of the product. Instead, this information was found in the data sheet of a compatible end e ector, which is manufactured by another company.
Dingo DingDoi-nAgo brochure
Dingo-A data sheet Primary information source:
ISO flange information missing
Dingo
Dingo-A robotic arm
ISO-9409-1-??-??-??
Catomatic Screwdriver
Catomatic
Catomatic Screwdriver data sheet Secondary information source:
ISO flange information found
for Dingo-A robotic arm
CH2: Misleading Compatibility When a data sheet states that a product supports
an Industrial Communication Protocol [
Robotic Arm
Modbus TCP Robotic Arm
Data Control Box Modbus TCP
CH3: Implicit Information In some cases, component properties were inferred from the name of the component, and not from its data sheet. The example, illustrated in Figure 4, shows that the maximum current load of the EECD 3A can be interpreted as 3A, but this information is not in the data sheet. Moreover, it leaves the authors to wonder what the maximum current load of the EECD component is. Performing an empirical test of the con guration showed that the Screwdriver was incompatible with the EECD.
CH4: Misleading Incompatibility Some data sheets specify that two products A and B are incompatible in one part of the document, while revising this by stating that A and B can be made compatible when some precondition is fullled. An example is illustrated in Figure 5, describing that the Robotic Arm is incompatible with EECD, unless the Data Control Box is used for the data connection. This challenge example originates from the manufacturer adding the EECD IO to their component list in order to support using a Data Cable. This introduced the complexity of supporting both the con guration with the EECD IO and the legacy con guration with the Data Control Box. 4
In this section we describe the di erent concepts, layers and rules that we apply in the methodology of developing a con gurator, illustrated in Figure 6. We present how RoboCIM has been designed to tackle the challenges presented EECD 3A EECD EECD incompatible
Screwdriver Screwdriver
Gripper in Section 3 above, based on the two rule layers illustrated in Figure 6. The Universal Rules layer contains generic rules that can be applied to con gurators of various domains, focused on generating valid con gurations. The Application Rules layer is domain speci c, containing rules that in this case are speci c to robot systems. Here, we illustrate some of the main rules used to describe a con gurator for robot systems, built on top of the Universal Rules.
System integrator Customer provides provides
Product Catalogue User Requirements
Payload = 2kg Reach >= 35cm
Solver Application Rules (Domain Model) Universal Rules (Meta-Model)
Valid
configurations
We describe the Universal Rules (Meta-Model) of the con gurator to be applied
to domains where incomplete information is pervasive. We use similar concepts
to the ones de ned in [
Universal layer Product Con guration. A Con guration consists of a number of Products, which are Port containers. Port Containers can be connected to other Port containers through their ports. A Product can be part of a Product series, which is an abstract notion of a product. The concept of Product series represents a group of products that have common attributes, in which a product belonging to this series inherits these attributes. A product series itself can be de ned as a subclass of another product series via the is a association relation (transitive, irre exive). A subset of constraints on Ports and Product series, are shown in Listing 1.1, which are made explicit using Object Constraint Language (OCL)5. -- Constraint 1: A port cannot be connected to itself : context Port inv : self . connected <> self -- Constraint 2: A product series cannot be its own product : context Product_series inv : self . is_a <> self -- Constraint 3: A port must have an orientation : context Port inv : self . attribute . name = 'input ' or self . attribute . name = ' output ' -- Constraint 4: A port can connect to another port , if they have opposite orientation and the same interface ( represented by attribute value ) context Port inv : self . connected (p2) implies
Set { self . attribute . name } union Set {p2. attribute . name } = Set {'input ', ' output '} and
self . attribute . name . value = p2. attribute . name . value Listing 1.1: Examples of basic Meta-Model axioms described using OCL.
Assuming general properties and compatibility of products in industrial
congurators is common, however, special cases exist where the initial assumption
about a product may be incorrect, de ned by an explicit constraint which
underlies hidden information. \The relationship of support between premises and
conclusion is a tentative one, potentially defeated by additional information " is
stated by Koons [
We de ne default properties of products, which can be defeated by explicit
evidence disproving the assumption, based on Nute's defeasible logic framework [
Listing 1.2 exempli es a constraint for de ning incompatible products, and a constraint on the uniqueness of products in a con guration. --Constraint 5: Two products ( productA and productB ), known to be incompatible , must not exist in the same configuration : context Configuration inv:
self.products -> excludes ('productA ') and self.products -> excludes ('productB ') --Constraint 6: Only one instance of a product can exist in the same configuration : context Configuration inv: Set{self. products } = self. products
Listing 1.2: Examples of con guration related axioms described using OCL.
Tackling Incomplete Information. To formally model cases of incomplete
information, the con gurator is designed with a notion of information sources from
various categories, de ned as justi cations. This provides the basis in RoboCIM
for reasoning about defeasible compatibility. Categories that have been used
when integrating data from multiple sources (e.g. in [
A primary source comes from the manufacturer of the product in forms of data sheets, technical reports or brochures. The secondary source comes from another manufacturer of a related product, typically this product can be connected to the referred product. We also add the two categories empirical test and observation. An empirical test can be derived from physical test results of connecting products, which could be performed by system integrators. An observation is a property of a product that is de ned by a domain expert, which has acquired this knowledge by observing how this product can connect to others.
The veracity of information about (in)compatibility varies for each category. The primary source is the strongest justi cation category, followed by the empirical test, and then observation. Importantly, RoboCIM is customisable such that users can specify which justi cations are used to infer defeasible compatibility, e.g. users can setup a RoboCIM solver to generate con gurations such that compatibility must be justi ed by primary sources (thus only delivering strongly justi ed con gurations), as illustrated in Listing 1.3. --Constraint 7: Configurations using information from primary justifications only: context Configuration inv: self.products -> forAll (p1 | p1. attribute .value. justification = primary ) and self.products -> forAll (product -> forAll (
port | port. attribute .value. justification = primary ))
Listing 1.3: Example of justi cation related axiom described using OCL. Rationale of Modelling Choices. Both challenges CH3 and CH4 can be dealt with by explicitly de ning that these products may not exist in the same con guration. Constraint 5 in Listing 1.2 solves the issue in CH3, and can be extended to include three products for solving CH4. Although CH2 can also be addressed using incompatibility constraints (as CH3 and CH4), this incompatibility constraint di ers in the sense that the two products can exist in the same con guration but cannot be directly connected. An incompatibility constraint only on neighbouring products can be used, de ning that if two products are directly incompatible, then their ports are also incompatible, shown in Listing 1.4. -- Constraint 8: Two directly incompatible products cannot be connected : context Configuration inv : self . products -> forAll (p1 ,p2 | p1 <> p2 and incompatible_neighbours (p1 ,p2) implies p1. ports -> forAll ( port1 | p2. ports -> forall ( port2 | port1 . connected <> port2 ))) Listing 1.4: Example of incompatibility axiom described using OCL.
Solving the challenge of CH1 can be done using justi cation and sources of information. To ensure the certainty of the candidate con gurations, it is possible to exclude con gurations using knowledge from speci c justi cations. 4.2
Application Rules (Domain Model) The Application Rules layer extends the Universal Rules layer with concepts and rules related to the robotics domain, and also incorporates rules to impose the user requirements in the con gurator. A robot con guration must contain speci c products, as the examples shown in Figure 1. Each of these products must have speci c types of ports, for example, a robotic arm must have a robot ange interface. These rules are de ned in the Application Rules and illustrated in Listing 1.5. De ning which products must exist in a robot con guration can also be used to solve challenges, such as CH2 described in Section 3 above. -- Constraint 9: One product of each type robotic_arm , eecd , end_effector , and data_connection , must exist in the configuration : context Configuration inv : let product_types_attr = self . products -> forAll (
p-> select ( attribute | attribute . name = 'type ')) in product_types_attr -> one ( value = ' robotic_arm ') and product_types_attr -> one ( value = 'eecd ') and product_types_attr -> one ( value = ' end_effector ') and product_types_attr -> one ( value = ' data_connection ') -- Constraint 10: Products of type robotic_arm must have specific port types : context Product inv : self . attributes -> exists ( attribute | attribute . name = 'type ' and attribute . value = ' robotic_arm ') implies self . ports -> exists ( port | port . type = ' robotic_arm_flange ') Listing 1.5: Con guration rules on required product and port types in a con guration described using OCL.
Other than rules on the speci c products and their ports in a con guration, rules related to user requirements are also implemented in the Application Rules. As illustrated in Figure 6, the user can specify di erent requirements, such as the required payload of the robotic arm, and the type of application. Di erent robotic arms have di erent payload requirements, e.g. some can carry up to 3kg, while others up to 10kg. Here, the user should be able to specify their application requirements, and the con gurator should only give the relevant con gurations. Examples of rules related to the user requirements are shown in Listing 1.6. -- Constraint 11: User requirement on payload of robotic_arm : context Product inv : req_payload <> none and self . attributes -> exists ( attribute | attribute . name = 'type ' and attribute . value = ' robotic_arm ') implies self . attributes -> one ( attribute | attribute . name = ' payload ') and req_payload <= self . attributes -> select ( attribute | attribute . name = ' payload '). value -- Constraint 12: User requirement on application context Configuration inv : req_application <> none and self . applications -> exists ( req_application ) implies let end_effector_type = self . applications -> select ( req_application ). end_effector_type in let end_effector_product = self . products -> select (p | p. attributes -> exists ( attribute | attribute . name = 'type ' and attribute . value = ' end_effector ')) in end_effector_product . attributes -> exists ( attribute | attribute . name = ' subtype ' and attribute . value = end_effector_type ))
Listing 1.6: Rules related to user requirements described using OCL.
The concept of Product series allows to easily group products with similar properties. In the robotics domain this can be applied to incorporate product type series, such as robotic arm series, but even extend this to gripper types, by creating product series of electrical grippers, vacuum grippers etc.
Apart from these general domain rules that are de ned in the Application Rules, RoboCIM is designed to incorporate knowledge about speci c products, even without their existence in the product catalogue. This allows users to build up the knowledge base on robotic products, and later specify which products a company owns, by specifying its product catalogue. 5
In this section we describe the prototype implementation and evaluation of
RoboCIM using ASP. We have chosen to use ASP, since it can handle
nonmonotonic and default reasoning for cases where information is incomplete. We
use clingo [
RoboCIM was implemented in ASP, using the UML diagram in Figure 7, and the constraints described above in Section 4. A product is de ned as an ASP fact, it's belonging to a product series is de ned as a rule and a fact on the speci c product and series. Listing 1.7 exempli es how these concepts have been implemented in ASP, and the remaining concepts in RoboCIM were implemented likewise. The complete code can be found in the public Github repository6. product ( koala_a ). % robotic arm product ( catomatic_gripperA ). % end effector ( gripper ) series_has_product ( koala , koala_a ). % koala_a belongs to the product series koala % A product inherits the same attributes as the product series it belongs to has_primitive_attr (X,I,V,J,S) :- has_primitive_attr (Y,I,V,J,S), series_has_product (Y,X).
Listing 1.7: Product and product series in ASP.
The ASP implementation was validated on a subset of 20 products from 3 manufacturers, from Technicon's product catalogue. The con gurator was validated with regards to both product compatibility and user requirements, where
the user could specify an application and payload. The time taken to generate all con gurations is presented in Table 1. The very short runtimes (within 0.1 seconds) demonstrate the practicality of our approach for defeasible reasoning via ASP to infer plausible con gurations in the case of incomplete knowledge. We presented our con gurator model, RoboCIM, which was designed to deal with incomplete information and a number of challenges found in the robot system integration domain. RoboCIM uses the concept of products, product series, ports, information sources and justi cations which are all used to generate valid con gurations composing compatible products.
An initial prototype implementation executed on a real data set of 20 products from 3 manufacturers demonstrates the practicality of our approach, taken within 0.3 seconds to generate all con gurations consisting of either 4 or 5 components. This proof of concept operates on about a third of the devices usually o ered by system integrators, in future work we will verify our approach in full inventory sets. We plan on working with human expert system integrators to evaluate the usability and impact of RoboCIM. Speci cally, we plan to integrate this work with Technicon and perform a small user experiment, where one of the engineers will extend the product catalogue and constraints of the currently developed domain model prototype.
To ease the work of adding information to the knowledge base, an approach
of extracting rules from natural language, as the one presented in [
We acknowledge the Innovation Foundation Denmark for the MADE FAST project. The views and opinions expressed in this paper are those of the authors and do not necessarily re ect the o cial policy or position of Technicon ApS.