Empowering the Model-driven Engineering of Robotic Applications

using Ontological Semantics and Reasoning

Stefan Zander

, Nadia Ahmed

and Yingbing Hua

FZI Research Center for Information Technology, Haid-und-Neu-Str. 10-14, 76131 Karlsruhe, Germany

Karlsruhe Institute of Technology, Engler-Bunte-Ring 8, 76131 Karlsruhe, Germany

Keywords:

Knowledge Representation, Semantic Technologies, Ontologies, Cyber-physical Systems, Robotics.

Abstract:

This work discusses two scenarios in which the model-driven engineering of robotic applications can be im-

proved using ontological semantics and reasoning. The objective of the presented approach is to facilitate

reuse and interoperability between cooperating software and hardware components. Central to the presented

approach is the usage of ontologies and description logics as knowledge representation frameworks for the ax-

iomatic description of component metadata models. In the ﬁrst scenario, we show how application templates

can be created using the concept of placeholders in which requirements for integrating external components

can be axiomatically speciﬁed and eligible components can be computed using subsumption reasoning. The

second scenario extends this idea for the inference of compatibilities between cooperating components. The

practical applicability of the approach is demonstrated by a concrete use case from the ReApp project.

1 INTRODUCTION

The development of robot applications is usually an

expensive and time-consuming task, resulting from

the inherent heterogeneity and complexity of in-

volved elements (data, algorithms, interfaces, proto-

cols etc.) and the required technical and domain ex-

pert knowledge. These aspects, among others, hin-

der the broad usage of robotic systems, in particu-

lar in small and medium-sized enterprises (SMEs)

and industries with high production variability (cf. the

ReApp project

). In order to tackle these issues, the

integration of model-driven engineering (MDE) prin-

ciples into the software- and tool-development pro-

cesses of robotic applications revealed promising im-

provements (cf. (Schlegel et al., 2009; Alonso et al.,

2010; Gherardi and Brugali, 2014)). However, the

positive effects of MDE approaches can be further in-

creased, if they are synthesized with ontological se-

mantics and formal reasoning methods, as new forms

of tool-support and assistance can be provided to soft-

ware developers, system integrators and end users

likewise (Zander et al., 2016).

In this paper, we present two scenarios that

corroborate our hypothesis that ontologies used as

knowledge representation frameworkcan improve the

www.reapp-projekt.de

model-driven engineering of robotic applications in

terms of reusability and utilization. In one scenario,

we show how the utilization and interoperability of

software components can be improved by axiomati-

cally describing functional requirements for external

components that are needed by a given component in

order to provide its full service (e.g., a path planing

component combined with an object detection soft-

ware). We therefore deﬁne the concept of applica-

tion templates in which axiomatically expressed re-

quirements using description logics (cf. (Baader et al.,

2003; Kr¨otzsch et al., 2014)) are encoded in compo-

nent descriptions (Gil, 2005). These axioms can be

processed by a reasoner in order to deduce eligible

components, which are hosted e.g. in application mar-

ketplaces

. This concept allows a software compo-

nent or robotic application to explicitly express nec-

essary requirements for external or third-party appli-

cations it requires for its correct execution on a func-

tional level (see (Zander and Awad, 2015)). These

requirements can being speciﬁed by the developers at

design time to exploit formal reasoning for inferring

recommendations of suitable components.

A second scenario demonstrates how compatibil-

In the context of the ReApp project, a marketplace for

robotic components was developed, the so-called ReApp-

Store (Bastinos et al., 2014).

192

Zander, S., Ahmed, N. and Hua, Y.

Empowering the Model-driven Engineering of Robotic Applications using Ontological Semantics and Reasoning.

DOI: 10.5220/0006086201920198

In Proceedings of the 8th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2016) - Volume 2: KEOD, pages 192-198

ISBN: 978-989-758-203-5

ities between cooperating software components can

be automatically inferred by a reasoner on basis of

the formal model-theoretic semantics employed by

the ontology language upon which a component’s

metadata model is described. In contrast to many

rule-based approaches in which compatibility is de-

termined by evaluating expressions encoded in rule

bases, we compute compatibility between compo-

nents through subsumption reasoning, i.e., by inter-

preting the axioms encoded in the terminological part

of a knowledge base (cf. (Zander and Awad, 2015)).

We employ the Resource Description Frame-

work (RDF)

(W3C, 2014) as knowledge represen-

tation framework for encoding ontological informa-

tion and the Web Ontology Language (OWL)

(Patel-

Schneider et al., 2009; W3C OWL Working Group,

2012) for describing a model’s formal semantics us-

ing description logics (DL) fragments as they exhibit

well-understood reasoning complexity and tractabil-

ity (cf. (Baader et al., 2003; Kr¨otzsch et al., 2014)).

2 RELATED WORKS

2.1 Model-driven Engineering

During the evolution of software engineering, model-

driven software development has achieved remark-

able success. In the domain of robotics, a distinc-

tion can be made between approaches that use exist-

ing general purpose languages for modeling tasks and

those that use domain speciﬁc languages (DSL) (Bru-

gali, 2015). SmartSoft (Schlegel et al., 2009) supports

both platform-independent and platform-dependent

artifacts and provides a model-driven toolchain that

features a coordination language called SmartTCL

to model runtime communication orchestration be-

tween components. V

CMM (Alonso et al., 2010)

provides a meta-model for robotic component archi-

tectures that provides three different UML views of

a system regarding structure, coordination, and al-

gorithms. The HyperFlex toolchain (Gherardi and

Brugali, 2014) demonstrates how reference architec-

tures can be used for the development of robotic

applications using component models that abstract

from a speciﬁc implementation framework. The idea

is to further enable reuse for entire mature subsys-

tems. Examples for robotic DSL are the Architecture

Analysis and Design Language AADL (Ramaswamy

et al., 2014a), the RobotML language developed by

the french research project PROTEUS (Farges, 2009),

https://www.w3.org/RDF/

https://www.w3.org/OWL/

the MontiArcAutomation framework (Ringert et al.,

2013), and the CoSTAR framework modeling lan-

guage (Guerin et al., 2015). AADL plays a vital

role in the SafeRobots framework (Ramaswamy et al.,

2014c; Ramaswamy et al., 2014b) as a solution space

modeling language.

Although all these approaches enable modeling

of robotic components and systems to a certain ex-

tent, yet most of them neglect the semantic interoper-

ability, since there is barely any explicit semantic in-

terpretation of component descriptions, which means

the requirements and interactions between them are

only deﬁned syntactically using proprietary and vary-

ing grammars. To be able to use certain frameworks, a

user is required to dive deeply into the concepts of the

underlying technologies, which signiﬁcantly reduces

the practicability of the approach.

2.2 Ontologies in Robotics

In the Web of Data (aka semantic Web), ontologies

have proven their usefulness for describing concepts

and relationships between resources as they serve

as crucial constituents of a semantic interoperability

infrastructure built upon standards proposed by the

W3C. A core ontology containing common knowl-

edge about robotics and automation was developed

by the recently established working group “ontolo-

gies for robotics and automation” within the IEEE-

RAS (Prestes et al., 2013) committee. In addition

to the Semantic Sensor Network Ontology (Comp-

ton et al., 2012), which is widely used in the cyber-

physical systems and IoT domain, Ion-Mircea and

Gerd (Diaconescu and Wagner, 2014) developed a

sensor and actuator systems ontology speciﬁcally for

the Web of Things. Carbonera et al. (Carbonera et al.,

2013) deﬁned an ontology to describe robot posi-

tioning as part of the core ontology concept by the

IEE RAS working group. Nilsson et al. (Nilsson

et al., 2009) developed a robotic component ontol-

ogy to demonstrate the possible improvements and

gains in robustness when designing robotic systems

using task-oriented models. An extensive investiga-

tion into the beneﬁts of combining ontologies and

model-driven approaches is carried out by Assmann

et al. (Aßmann et al., 2006). Semantic technologies

could also be found in model-driven robotic frame-

works; PROTEUS (Lortal G, 2011), for example, in-

troduced a methodology for using ontologies on the

system level where knowledge transfer between ex-

perienced users is supported. The lack of ﬁne-grained

information models limits the platform’s usability.

Empowering the Model-driven Engineering of Robotic Applications using Ontological Semantics and Reasoning

193

3 APPROACH

In the ﬁrst part of this section, we describe how ap-

plication templates and placeholders can be axiomat-

ically expressed in form of ABox, TBox and RBox

axioms. The second part demonstrates the usage of

terminological knowledge for computing compatibil-

ities between components using subsumption reason-

ing. A central concept of both parts is the notion of

formal requirements, which we elaborate in detail in

the ﬁrst part.

3.1 Expressing Requirements for

Application Templates

In this work, we deﬁne an application template as a

composition of placeholders that can be ﬁlled by con-

crete software or hardware components. An applica-

tion template is composed of at least one placeholder

which is expressed as a set of ABox axioms that fol-

low a speciﬁc schema (see Axioms 1-6) and deﬁne re-

quirements using terms from hardware, software and

capability ontologies

. For example, a robotic appli-

cation for picking-up an object from a conveyor belt

can be speciﬁed using the template concept in order

to express the requirement of three necessary com-

ponents including their respective capabilities: (1)

a camera that captures the image of the object to

be picked; (2) a position detection component that

detects the target position for controlling the robot

movement; (3) a path calculation component that cal-

culates the trajectory for the robot from its initial to

the target position. A strong point of the presented

approach is that it allows eligible components to be

expressed not only directly via their respective types

but rather by the functionalities they provide. With re-

gard to the previous example, this would be axiomat-

ically expressed as follows:

2DCamera ⊑ ∃hasCapability.{2DImageCapturing}

Vision ⊑ ∃hasCap ability.{PositionDetection}

PathCalculation ⊑

∃hasCapability.{TrajectoryCalculation}

The above mentioned functionalities are encoded

in the terminological part of the capability ontology

and are represented via the classes: ImageCapturing,

In the course of the ReApp project (www.reapp-

projekt.de) two ontologies for classifying hardware

and software components together with one on-

tology for expressing capabilities of such compo-

nents have been developed and published (see http://

ipe-id.fzi.de/ontologies/reapp/).

http://ipe-id.fzi.de/ontologies/reapp/doc/Capability.htm

PositionDetection and TrajectoryCalculation. Capabil-

ities are linked to hardware and software components

via role restriction axioms that act along a speciﬁed

property (hasCapability). This axiom type can be used

for the formulation of placeholders; the placeholder

for a component that offers an ImageCapturing capa-

bility can be expressed as follows:

RobotApplica tion(application1) (1)

PlaceholderExpression(p1) (2)

hasPlacehol der(application1, p1) (3)

Requirement(req1) (4)

requires(p1, req1) (5)

requiresCapability(req1, {ImageCapturing }) (6)

{ImageCapturing} ⊑ Capability (7)

requiresCapability ⊑ hasCapability (8)

Axiom 1 states that a concrete robot application-

template represented by application1-individual,

member of the class RobotApplication, has a place-

holder (Axiom 2) represented by p1-individual

member of the class PlaceholderExpression (Ax-

iom 2). This p1-individual is related to a member

of Requirement-class denoted by req1 via requires-

property (Axiom 3). Additionally to express the

requirement information by mean of functional-

ities, we deﬁne the property requiresCapability

as expressed in Axiom 6, this property relates

req1-individual to the DL nominal ImageCapturing.

Axiom 7 denotes that ImageCapturing is subsumed

by Capability. Additionally, Axiom 8 transforms

the property requiredCapability into a hasCapability

expression when inferring eligible components via

subsumption reasoning.

Assuming a robotic system contains a spe-

ciﬁc hardware component (e.g. Sick IVC-2D cam-

era), which is represented by the individual

myIVC2DCamera and classiﬁed as a member of the

2DCamera class. Based on the following axioms

2DCamera(myIVC2DCamera)

2DCamera ⊑ ∃hasCapability.{2DImageCapturing}

a reasoner is able to infer that each member of

2DCamera is also a member of the abstract class

∃hasCapability.{2DImageCapturing } and offers the

capability 2DImageCapturing, i.e., it participates in

a hasCapability-role with the nominal represented by

2DImageCapturing.

∃hasCapability.{2DImageCapturing } ←֓

(myIVC2DCamera)

Since 2DImageCapturing is subsumed by ImageCap-

turing (as stated in the capability ontology), a rea-

soner can infer that hardware components, which are

KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development

194

members of the class 2DCamera fulﬁll the place-

holder’s requirements expressed in Axioms 1-8. Be-

sides, if a component provides a capability, e.g.,

Fast2DImageCapturing, which is subsumed by 2DIm-

ageCapturing, the reasoner can also deduce that this

component fulﬁlls the placeholder’s requirements.

Furthermore, placeholder’s requirements are also

extended with constraints in form of ABox axioms

that eligible component must satisfy. In order to ex-

press within a placeholder that the image resolution

value must be at least equal to 10 Mega Pixel we de-

ﬁne the following axioms.

Constraint(cons1) (9)

hasConstraint(req1, cons1) (10)

requiresAttribute(cons1, {Resolution}) (11)

requiresAttribute ⊑ hasAttribute (12)

{Resolution} ⊑ Attribute (13)

hasOperator(cons1, {GreaterThan}) (14)

{GreaterThan} ⊑ Operator (15)

hasConstraintValue(cons1, ‘10‘) (16)

hasUnitOfMeasurement(co ns1, {MegaPixel}) (17)

Axioms 9 and 10 state that req1-individual (previ-

ously deﬁned in Axiom 4) is related to cons1, mem-

ber of the class Constraint via hasConstraint-property.

Since a constraint expression consists of an attribute,

an operator and a value, cons1-individual, is related

to individuals, members of the class Attribute via re-

quiresAttribute-property (Axiom 12), members of the

class Operator via hasOperator-property (Axiom 14)

and members of the class Value via hasConstraint-

Value-property (Axiom 16). Operators are expressed

at TBox level such as the class GreaterThan (Ax-

iom 15). Axiom 16 and 17 state that the value

of cons1-individual is equal to 10 and is related to

MegaPixel-nominal via the hasUnitOfMeasurement-

property. The retrieval of components that fulﬁll

a placeholder’s requirements is performed by com-

paring the attribute values that a component provide

with the constraints required by a given placeholder.

Whereby, concrete instances of attributes that are ap-

pended to placeholder’s requirements as well as to

speciﬁc components are classiﬁed by the reasoner.

The fact that a speciﬁc component, classiﬁed as a

camera, has the attribute resolution can be encoded

as follows:

Sensor ⊑ ∃hasAttribute.{Resoluti on} (18)

{Resolution} ⊑ Attribute (19)

Camera ⊑ Sensor (20)

Axiom 18 denotes that members of the class Sensor

have at least one relationship to the nominal Resolu-

tion, which is a subconcept of Attribute (Axiom 19).

Since Camera is a subclass of Sensor, the reasoner

deduces that individuals, members of the class Cam-

era are also related to individuals of the class reso-

lution via hasAttribute-property. Summarized, each

component classiﬁed as a camera also has the reso-

lution attribute.

3.2 Semantic Compatibility

After eligible components that satisfy a placeholder’s

requirements are inferred by a reasoner, an additional

test is required to assure that two cooperating com-

ponents are compatible in terms of their technical in-

terface speciﬁcations. For example, a visual odom-

etry component subscribes to a ROS

image-topic

published by a camera access component (the cam-

era driver). Connecting these two components via

the image-topic merely based on syntactical param-

eters (e.g. the name of the ROS topic) does in most

cases not ensure their technical compatibility and sat-

isﬁability of functional requirements; e.g., the visual

odometry component might require a depth image

while the camera componentprovides an intensity im-

age. In order to infer whether an eligible component

also satisﬁes technical requirements, requirement in-

formation is appended to the component model.

Requirement information related to a placeholder

(as described in 3.1) is also used to describe require-

ments for components in order to check whether an el-

igible component satisﬁes the requirements of a given

component. Therefore, requirement information is

appended to a component analogically to placehold-

ers (see Axioms 4-6). For example, asserting that a

component requires a 3DIntensityImageCapturing ca-

pability is encoded as follows:

SoftwareComponent(objectD e t e ction) (21)

Requirement(req2) (22)

requiresCapability(objectDetection,

{3DIntensityImageCapturing}) (23)

Axiom 21 states that a component represented by an

individual objectDetection is a member of the class

SoftwareComponent and is related to the req2 indi-

vidual, which is a member of the class Requirement

(Axiom 22) via the requiresCapability-property (Ax-

iom 23). In the given case, the class 3DIntensityIm-

ageCapturing is a subclass of ImageCapturing; a rea-

soner thus is able to infer additional requirement in-

formation related to the ImageCapturing class. Re-

quirement information for a concrete component are

also extended by constraints information and are ax-

iomatically expressed as described in Axiom 9-10.

http://wiki.ros.org/Messages

Empowering the Model-driven Engineering of Robotic Applications using Ontological Semantics and Reasoning

195

ĂƉĂďŝůŝƚǇ=Image

Processing

Maximal intensity > 170

Height = 264

Width = 400

Proc:ImageProcessing

Component

Obj Viz:Pose

Recognition Component

ƌĞƋƵŝƌĞƐĂƉĂďŝůŝƚǇ

Compatibility

Check

ĂƉĂďŝůŝƚǇ = Bilinear

Interpolation-based

Image Processing

Max intensity = 255

Size = 264 * 400

ŚasĂƉĂďŝůŝƚǇ

ŚasAttribute

(1) ĂƉĂďŝůŝƚǇ Matching

Check

ŚasConstraint

(3) Implicit Specification

Check

ŝs^ubsumedy

Perception

Error Rate < 3%

Has/mplicit

Constraints

Signal Processing

Is^ubsumedy

Error Rate = 10%

Śas/mplicit

Attributes

(Ϯ) ŽŶƚƌĂŝŶƚ&ƵůůĨŝůůŵĞŶƚ

Check

Figure 1: Compatibility calculation between two exemplary

components on the basis of their attributes together with the

different levels of checks: (1) capability matching, (2) con-

straints fulﬁllment, and (3) implicit speciﬁcations checks.

Therefore, a compatibility check can be performed by

comparing the provided attribute values with the con-

straints required by a given component.

In order to check the compatibility between an

image processing component and a pose recognition

component (see Figure 1), three different levels of

checks are required. At the ﬁrst level, the capabil-

ity of the provided side ImageProcessing must be

subsumed by the capability of the component at the

required side PoseRecognition. Secondly, the con-

straints must be fulﬁlled. That means the provided

values of the attributes of ImageProcessing must sat-

isfy the constraints speciﬁed by the required side. On

this level, a class membership of attribute individuals

(denoted in Figure 1 as Max intensity and Maximal in-

tensity) is also calculated in order to identify that they

belong to the same Attribute-class. In order to unify

the representation of attributes, they are also repre-

sented as TBox axioms.

Afterward, a numerical comparison is performed

in order to check whether the values of the provided

attributes fulﬁll the given constraints. Finally, implic-

itly deduced information about additional capabilities

such as inferred capability of the component Signal-

Processing is also used for further checks. Implicit

constraint information deduced from the constraint of

the subsuming capability PoseRecognitioncan also be

used for additional checks.

As depicted in Figure 1, given an image pro-

cessing component, represented by proc-individual,

member of the class SoftwareComponent, this com-

ponent provides the capability BilinearInterpolation-

basedImageProcessing. On the other side, given a

pose recognition component represented by an indi-

vidual denoted by ObjViz, member of the class Soft-

wareComponent, this component requires the capa-

bility ImageProcessing. The required capability is

formalized as illustrated in Axioms 4-8 and 21-23.

Since BilinearInterpolation-basedImageProcessing is

subsumed by ImageProcessing, the capability level of

both components is matching. Additionally, the rea-

soner infers implicit attributes related to the subsum-

ing class SignalProcessing such as the ErrorRate is

equal to 10%. Analogically, on the required side (pose

recognition), implicit constraints are derived from the

subsuming capability Perception. For example, the

error rate must be smaller than 3%. This improves

the checking process by delivering more knowledge

about the properties that a component exhibits or re-

quires, which are not explicitly stated at design time.

4 USE CASE

In this section, we demonstrate the applicability of

the proposed semantically enhanced model-drivenap-

proach by means of a use case, in which the applica-

tion developer will be assisted during the engineering

phase of a robotic system in the electronic industry.

In this use case, a robotic system should solder LED

stripes on printed circuit boards (PCB) while the hu-

man operator holds the connection wires between the

soldering points, thus also enabling a close human to

machine cooperation

Aiming at a ﬂexible automation solution that can

be reconﬁgured for potential soldering applications

with different process requirements, the application

developer will make a template for the robotic sys-

tem comprising various hardware and software com-

ponents. For example: A robot arm should be used

as actuator to drive the soldering tool to the tar-

get position. By utilizing the placeholder concept,

the application developer can axiomatically formu-

late necessary requirements, e.g., an actuator with 3-

dimensional movementcapability and add them to the

semantic metadata model of its application:

PlaceholderExpression(p1) (24)

Requirement(req1) (25)

requires(p1, req1) (26)

requiresCapability(req1, 3DMovement) (27)

3DMovement ⊑ Capabil ity (28)

requiresCapability ⊑ hasCapability (29)

The placeholder will be semantically processed

and the reasoner is capable to ﬁnd suitable com-

This is one of the three use cases in the ReApp project.

KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development

196

ponents from a knowledge base that fulﬁll the re-

quirements, e.g. a robot of type UR5 and UR10.

Moreover, the application developer can further re-

strict the component to have a certain accuracy

(Repeatabili ty <= 0.02 m m) for the soldering pro-

cess and a minimum payload to carry the soldering

tool (Payload >= 7kg). Such constraints can be by

deﬁned axiomatically as follows (excerpt):

Requirement(req1) (30)

hasConstraint(req1, cons1) (31)

Constraint(cons1, con s2) (32)

requiresAttribute(cons1, {Repeatability}) (33)

hasOperator(cons1, {SmallerOrEqualTh an}) (34)

hasConstraintValue(cons1, ‘0.02‘) (35)

hasUnitOfMeasurement(co ns1, {mm}) (36)

hasConstraint(req1, cons2) (37)

requiresAttribute(cons2, {Payload}) (38)

hasOperator(cons2, {GreaterOrEqualThan}) (39)

hasConstraintValue(cons2, ‘7‘) (40)

hasUnitOfMeasurement(co ns2, {kg}) (41)

Both candidates UR5 and UR10 fulﬁll the Re-

peatability constraint, yet not the Payload constraint,

since UR5 can only carry tools up to 5 kg. As a result,

the reasoner will infer that the UR5 does not satisfy

all constraints and answers a placeholder query only

with the robot UR10.

Figure 2: An interaction model of the components in the

soldering application.

To ensure the safety of the production, the appli-

cation developer needs a safety controller which has

to monitor possible collisions between solder tip and

obstacles, and will be fed by on-line distance and tac-

tile information (Figure 2). Moreover, to assure that

the emergency stop can be triggered in time, if any

collision is about to occur, the safety controller re-

quires incoming sensor data with a least frequency

of 500 Hz. During the engineering, to connect the

safety controller with appropriate sensor drivers, the

data type of published distance and tactile informa-

tion must be standard ROS message types to guaran-

tee syntactic compatibility; On the other hand, the fre-

quency of the sensor drivers can be modeled addition-

ally as functional requirement via formal semantics:

hasConstraint(req2, cons3) (42)

hasAttribute(cons3, {Frequency}) (43)

hasOperator(cons3, {GreaterOrEqualThan}) (44)

hasConstraintValue(cons3, ‘500‘) (45)

hasUnitOfMeasurement(co ns3, {Hz}) (46)

The compatibility computation thus provide re-

sults upon which a decision can be made whether a

given sensor driver fulﬁlls the speciﬁed requirements.

5 CONCLUSION

This work demonstrates how the model-driven en-

gineering of robotic applications can be synthesized

with ontological semantics and reasoning in order to

enhance the reuse and interoperability of hardware-

and software components. We used description

logic grounded ontologies as knowledge representa-

tion framework as they employ well-understood rea-

soning complexity and tractability. In a ﬁrst scenario,

the concepts of application templates and placehold-

ers were introduced that allow for the axiomatic

expression of requirements and constraints external

components have to satisfy for collaboration. By in-

terpreting the formal semantics of those axioms, eli-

gible components can be inferred using subsumption

reasoning. We extended this idea in a second sce-

nario and illustrated, how compatibilities between co-

operating components can be inferred by a reasoner

based on the axiomatic descriptions of constraints and

features of components. A distinguishing feature of

the presented approach is that it makes extensive uses

of terminological knowledge in order to fully exploit

the formal model-theoretic semantics of the underly-

ing ontology language in the reasoning process rather

than using rule-based language frameworks.

ACKNOWLEDGEMENTS

This work has been partially funded by the German

Federal Ministry for Economic Affairs and Energy

through the project ReApp (no. 01MA13001) and

by the Ministerium f¨ur Wirtschaft, Arbeit und Woh-

nungsbau Baden-W¨urttembergthrough the Digital In-

novation Center (DIZ Digitales Innovationszentrum).

Empowering the Model-driven Engineering of Robotic Applications using Ontological Semantics and Reasoning

197

REFERENCES

Alonso, D., Vicente-chicote, C., Ortiz, F., Pastor, J., and

Alvarez, B. (2010). V3CMM: a 3-View Compo-

nent Meta-Model for Model-Driven Robotic Software

Development. Journal of Software Engineering for

Robotics (JOSER), 1(January):3–17.

Aßmann, U., Zschaler, S., and Wagner, G. (2006). Ontolo-

gies, meta-models, and the model-driven paradigm.

In Ontologies for software engineering and software

technology, pages 249–273. Springer.

Baader, F., Calvanese, D., McGuinness, D., Nardi, D., and

Patel-Schneider, P. (2003). The Description Logic

Handbook: Theory, Implementation and Applications.

Cambridge University Press.

Bastinos, A. S., Haase, P., Heppner, G., Zander, S., and

Ahmed, N. (2014). ReApp Store - a semantic app-

store for applications in the robotics domain. In Inter-

national Semantic Web Conference (Industry Track).

Brugali, B. D. (2015). Model-Driven Software Engineering

in Practice. pages 155–166.

Carbonera, J. L., Fiorini, S. R., Prestes, E., Jorge, V. a. M.,

Abel, M., Madhavan, R., Locoro, A., Goncalves,

P., Haidegger, T., Barreto, M. E., and Schlenoff, C.

(2013). Deﬁning positioning in a core ontology for

robotics. IEEE International Conference on Intelli-

gent Robots and Systems, pages 1867–1872.

Compton, M., Barnaghi, P. M., Bermudez, L., Garcia-

Castro, R., Corcho,

O., Cox, S. J. D., Graybeal, J.,

Hauswirth, M., Henson, C. A., Herzog, A., Huang,

V. A., Janowicz, K., Kelsey, W. D., Phuoc, D. L.,

Lefort, L., Leggieri, M., Neuhaus, H., Nikolov, A.,

Page, K. R., Passant, A., Sheth, A. P., and Taylor, K.

(2012). The ssn ontology of the w3c semantic sensor

network incubator group. Journal of Web Semantics,

17:25–32.

Diaconescu, I.-M. and Wagner, G. (2014). Towards a gen-

eral framework for modeling, simulating and build-

ing sensor/actuator systems and robots for the web

of things. In First Workshop on Model-Driven Robot

Software Engineering (MORSE).

Farges, J.-L. (2009). Robotic Ontology and Modelling - 3rd

version.

Gherardi, L. and Brugali, D. (2014). Modeling and

reusing robotic software architectures: The HyperFlex

toolchain. Robotics and Automation (ICRA), 2014

IEEE International Conference on, pages 6414–6420.

Gil, Y. (2005). Description logics and planning. AI Maga-

zine, 26(2):73–84.

Guerin, K. R., Lea, C., Paxton, C., and Hager, G. D. (2015).

A Framework for End-User Instruction of a Robot As-

sistant for Manufacturing. pages 6167–6174.

Kr¨otzsch, M., Simanˇc´ık, F., and Horrocks, I. (2014). De-

scription logics. IEEE Intelligent Systems, 29:12–19.

Lortal G, Dhouib S, G. S. (2011). Integrating ontological

domain knowledge into a robotic dsl. In 2010 interna-

tional conference on Models in software engineering

MODELS?10, pages 401–414.

Nilsson, a., Muradore, R., Nilsson, K., and Fiorini, P.

(2009). Ontology for robotics: A roadmap. 2009 In-

ternational Conference on Advanced Robotics.

Patel-Schneider, P. F., Motik, B., and Grau, B. C. (2009).

OWL 2 Web Ontology Language Direct Semantics.

W3C recommendation, W3C.

Prestes, E., Carbonera, J. L., Fiorini, S. R., Jorge, V. A. M.,

Abel, M., Madhavan, R., Locoro, A., Goncalves, P.,

Barreto, M. E., Habib, M., Chibani, A., G´erard, S.,

Amirat, Y., and Schlenoff, C. (2013). Towards a core

ontology for robotics and automation. Robotics and

Autonomous Systems, 61(11):1193 – 1204. Ubiqui-

tous Robotics.

Ramaswamy, A., Monsuez, B., and Tapus, A. (2014a). Ar-

chitecture Modeling and Analysis Language for De-

signing Robotic Architectures. International Con-

ference on Control Automation Robotics & Vision

(ICARCV), 2014(December):10–12.

Ramaswamy, A., Monsuez, B., and Tapus, A. (2014b).

SafeRobots : A Model Driven Framework for Devel-

oping Robotic Systems. (Iros):1517–1524.

Ramaswamy, A., Monsuez, B., and Tapus, A. (2014c).

SafeRobots: A Model-Driven Approach for Design-

ing Robotic Software Architectures. Collaboration

Technologies and Systems (CTS), 2014 International

Conference on, pages 131 – 134.

Ringert, J. O., Rumpe, B., and Wortmann, A. (2013). Mon-

tiArcAutomaton: Modeling Architecture and Behav-

ior of Robotic Systems. Workshops and Tutorials Pro-

ceedings of the 2013 IEEE International Conference

on Robotics and Automation (ICRA, pages 10–12.

Schlegel, C., Hassler, T., Lotz, A., and Steck, A. (2009).

Robotic software systems: From code-driven to

model-driven designs. In Advanced Robotics (ICAR)

2009 Intl. Conf. on, pages 1–8.

W3C (2014). RDF 1.1 Concepts and Abstract

Syntax. http://www.w3.org/TR/2014/REC-rdf11-

concepts-20140225/.

W3C OWL Working Group (2012). OWL 2 Web Ontol-

ogy Language Document Overview (Second Edition)

- W3C Recommendation 11 December 2012.

Zander, S. and Awad, R. (2015). Expressing and reasoning

on features of robot-centric workplaces using ontolog-

ical semantics. In IEEE/RSJ Intl. Conf. on Intelligent

Robots and Systems. to be published.

Zander, S., Heppner, G., Neugschwandtner, G., Awad, R.,

Essinger, M., and Ahmed, N. (2016). A model-driven

engineering approach for ROS using ontological se-

mantics. CoRR, abs/1601.03998.

KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development

198