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

we use an Ontology for the model. With the help of the model, the tool can derive the dependencies which need to be met to fulfill a task. To derive which configuration fulfills the dependencies a separate reasoning process is performed. This separate reasoning process uses the data contained in the model to yield a minimal configuration. Through this separation, the model can be capped simply by avoiding the ”complex“ reasoning for a minimal configuration. Using the information fromtheontologyand the reasoning to derive a minimal configuration the tool can present a possible configuration to the user through a graphical user interface. The interface allows selecting tasks to perform, which components are used as well as which configuration would be minimal. In the remainder of the section, we will discuss each part in more detail. A. Ontology To model the relationships between tasks and necessary components, an ontology describing this relationship is needed. The ontology we use for the implementation is an open-source knowledge base and can be found at [3]. In this ontology, tasks are referred as capabilities. Each capability can be comprised of other basic capabilities. The ontology also describes the relationship of capabilities to hard- and software components that are needed for their implementa- tion. Some of these components may be compulsory and do not include alternatives while others may be chosen from a pool of similar components that may all be used to fulfill the same task. The information, stored in the ontology can be loaded and queried with an appropriate tool. We use the framework Jena [4] to load the ontology into a model. The model can be queried using the SPARQL query language. The Jena framework allows multiple ontologies to be loaded into a single model. The base ontology we use already contains references to the sub-ontologies, including descriptions of robot components. Therefore, it is enough to load the base ontology as all sub-ontologies will be loaded into the model automatically by the framework. B. Calculation of Configuration With the help of the ontology mentioned above, we can define the dependencies which need to be met to perform a task. The above calculate gives as a set of capabilities Cap, which can be requested to be fulfilled directly or indirectly. We use the variablesX and Y in the remaining subsections for variables with the domain of capabilities dom(X) = dom(Y) = Cap. Besides the capabilities, we have additionally the set of componentsComp. These com- ponents describe a software component, e.g. a laser-based localization or a hardware component, e.g. a laser scanner. We use the variableZ in the remainder of the subsection for variables with the domain of componentsdom(Z)=Comp. As the description of the components is rather abstract one needs a concrete implementation/realization of such a component, e.g. a Sick LMS100 for a laser scanner. To describe this implementation/realization of components the ontologyaboveyields theset ImplComp. In the remainderof the subsection, we use the variableW for variables with the domain of the implementations of components dom(W)= ImplComp. Beside the sets of possible capabilities, components and their implementation we additionally have four different functions describing the dependencies which need to be fulfilled for a capability, component and its implemen- tation. The function capReqCap : Cap → 2Cap de- scribes which set of capabilities needs to be fulfilled by the robot to implement a certain capability. For example, the capability liftObject depends on two other capabili- ties moveArm,graspObject which is described as follows capReqCap(liftObject) → {moveArm,graspObject}. To describe the dependencies between capabilities and com- ponents the function capReqComp : Cap → 2Comp is used. For example, the capability liftObject depends on two components arm,gripper which is described as fol- lows capReqComp(liftObject) → {arm,gripper}. Each requested component can be implemented differently to link a component and an implementation we use the predicate implComp : Comp × ImplComp → {>,⊥}. Like a capability a component can depend on capabilities, we use the function compReqCap :Comp→2Cap to describe this dependency. Additionally, a component can depend on other components which define through the following function compReqComp : Comp→ 2Comp . Using this functions and the predicate we can define the dependencies which need to be met to implement a certain capability. As we are interested in a configuration of the system which is minimal we need a specific reasoning to derive such a configuration. This is done by first extracting all dependenciesofa task togetherwitheverypossibility tomeet this dependency. The model does not store all dependencies in a single level. Instead, some dependencies may result from other dependencies. Therefore, a recursive extraction of dependencies must be performed. Once all these dependencies are extracted, a constraint problem can be defined to find (all) minimal configurations which fulfill the dependencies. This is done as follows. For each capabilityY which is required the predicate reqCap(Y) isused todescribe thecapabilities andcomponentswhichare needed by the robot. reqCap(Y)→ ∧ X∈capReqCap(Y) reqCap(X)∧ ∧ Z∈capReqComp(Y) reqComp(Z) Through this equation, one can simply resolve the recursive dependencies on the capabilities. Some of these capabili- ties might need components. As several hard- or software instances can implement a specific component we use an equation for the required capabilities to resolve components. If a componentW implements a required componentZwe 33