Page - 34 - in Proceedings of the OAGM&ARW Joint Workshop - Vision, Automation and Robotics

define the following constraint. reqComp(Z)→ implComp(Z,W)∧comp(W) Like capabilities, components can have dependencies. Thus, to model these dependencies we use another constraint. comp(W)→ ∧ X∈compReqCap(W) reqCap(X)∧ ∧ z∈compReqComp(W) reqComp(z) Using the ontology, we can instantiate the constraints automatically. The instantiated constraints are gathered in the set C. As we want to derive a minimal configuration for a given taskX we first need to add reqCap(X) to the set C. Afterward, we need to find a minimal set of componentsW to fulfill this requirement. This is achieved by the following minimization problem. argmin W (|{W|comp(W)∧W ∈W}|)s.t.C The solution to this minimization problem is a minimal set of components to use to guaranty that all dependencies are met. With the above-defined constraint problem, the minimal configuration can be generated. To realize these constraints in an efficient manner the constraint solving is split into two parts. The first part is the parsing of the ontology to extract the minimal dependency for one component. The second part uses this extracted data to find a minimal configuration in a very efficient way through a constraint solver. The first part is done by extracting the minimal set of necessary capabilities, for a chosen task, by recursively traversing the referenced capabilities of the chosen tasks. Using the resulting set of capabilities all mandatory com- ponents are extracted. Additionally, during the recursion one creates a separate set of mandatory components for each al- ternative realization. After this extraction, the minimal set of necessary capabilities, as well as the mandatory components, are already determined. Therefore, only the extraction of the various combinations of alternative components, such that the required tasks still can be fulfilled, must be done. We solved this problem by using the constraint solver choco [5]. To represent the constraints, we generated a matrixH. Each row in the matrix represents one abstract component descriptions. Each row vectorV describes a component that can implement these abstract component descriptions. With the help of this representation the data can be modeled as follows: • For all entries i of all vectors V in the matrixH, a variable E(i) is generated • The domains of these Variables E(i) are restricted, based on the component they implement. It is limited to the domain {0,B(V)K(H)+1}, whereB(V) denotes the maximum number of entries of all vectorsV andK(H) is the index of the vectorVwithin the matrixH. With this model all combinations of alternative components that are necessary to fulfill the given task can be determined using the following constraint: N(H)−1∑ i=0 E(i) != M(H)∑ i=1 B(V)i Here,N(H)denotes the totalnumberofentriesofall vectors VwithinHwhileM(H)denotes the number of rows within the matrixH. This ensures that all values of E(i) are zero, except for a single entry between all entries E(i) that share the same domain. This single non-zero entry is equal to the chosen component among all component alternatives that implement the same main component. To retrieve the components representedby thevaluesE(i) the index i isused as an index in an array containing the component names. C. User Interface In this section, the relevant components of our graphical user interface are described. The GUI itself is structured into separate tabs which all fulfill different tasks. 1) Defining Source Ontologies: The GUI features a tab that empowers the user to load any desired ontology (Figure 1). The definition of more than one ontology will result in a single model that contains all relationships. For this, the user is provided with a list that contains all ontologies added so far at the top of the tab. At the bottom, there are two buttons, one to add another ontology and another button to load the defined ontology files. Upon a click on the Load button, the ontologies will be loaded and scanned for capabilities, components and other important information. For this, the user may define keywords that identify components and capabilities, within the ontology, in the Settings tab. This generic approach should guarantee that the software can also incorporate different ontology sets. Fig. 1. The Sources tab of the GUI. Here the user may define the paths to the ontologies which are to be loaded into the model. 2) Defining Capabilities: After having loaded the desired ontologies, the user may define the desired tasks. There may be multiple of them or just one. This can be configured in the Capabilities tab as depicted in Figure 2. In this tab, desired tasks may be added using the Add button at the 34