STUTTGARTER BEITRÄGE ZUR PRODUKTIONSFORSCHUNG
ALEXANDER BUBECK
Modellbasierte Softwareentwicklung für mobile 
Manipulatoren im industriellen Einsatz
Alexander Bubeck
Modellbasierte Softwareentwicklung für mobile 
Manipulatoren im industriellen Einsatz
STUTTGARTER BEITRÄGE ZUR PRODUKTIONSFORSCHUNG BAND 54
Herausgeber:  
Univ.-Prof. Dr.-Ing. Thomas Bauernhansl
Univ.-Prof. Dr.-Ing. Dr. h.c. mult. Alexander Verl
Univ.-Prof. a. D. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper
FRAUNHOFER VERLAG
Kontaktadresse:
Fraunhofer-Institut für Produktionstechnik und Automatisierung IPA, Stuttgart
Nobelstraße 12, 70569 Stuttgart
Telefon 0711 9 70-00, Telefax 0711 9 70-13 99
info@ipa.fraunhofer.de, www.ipa.fraunhofer.de
STUTTGARTER BEITRÄGE ZUR PRODUKTIONSFORSCHUNG
Herausgeber:
Univ.-Prof. Dr.-Ing. Thomas Bauernhansl
Univ.-Prof. Dr.-Ing. Dr. h.c. mult. Alexander Verl
Univ.-Prof. a. D. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper
Fraunhofer-Institut für Produktionstechnik und Automatisierung IPA, Stuttgart
Institut für Industrielle Fertigung und Fabrikbetrieb (IFF) der Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) 
der Universität Stuttgart
Titelbild: © Fraunhofer IPA
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; 
detaillierte bibliografische Daten sind im Internet über www.dnb.de abrufbar.
ISSN: 2195-2892
ISBN (Print): 978-3-8396-1033-6
D 93
Zugl.: Stuttgart, Univ., Diss., 2015
Druck: Mediendienstleistungen des Fraunhofer-Informationszentrum Raum und Bau IRB, Stuttgart
Für den Druck des Buches wurde chlor- und säurefreies Papier verwendet.
© by FRAUNHOFER VERLAG, 2016
Fraunhofer-Informationszentrum Raum und Bau IRB
Postfach 80 04 69, 70504 Stuttgart
Nobelstraße 12, 70569 Stuttgart
Telefon  0711 9 70-25 00
Telefax  0711 9 70-25 08
E-Mail verlag@fraunhofer.de
URL http://verlag.fraunhofer.de 
Alle Rechte vorbehalten
Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Ver wertung, die 
über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zustimmung 
des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, 
Mikro ver filmungen sowie die Speiche rung in elektronischen Systemen.
Die Wiedergabe von Warenbezeichnungen und Handelsnamen in diesem Buch berechtigt nicht 
zu der An nahme, dass solche Bezeichnungen im Sinne der Warenzeichen- und Markenschutz-
Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürften.
Soweit in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z.B. DIN, 
VDI) Bezug genommen oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr für 
Richtigkeit, Vollständigkeit oder Aktualität übernehmen.
GELEITWORT DER HERAUSGEBER
Produktionswissenschaftliche Forschungsfragen entstehen in der Regel im Anwen-
dungszusammenhang, die Produktionsforschung ist also weitgehend erfahrungsbasiert. 
Der wissenschaftliche Anspruch der „Stuttgarter Beiträge zur Produktionsforschung“ 
liegt unter anderem darin, Dissertation für Dissertation ein übergreifendes ganzheitliches 
Theoriegebäude der Produktion zu erstellen.
Die Herausgeber dieser Dissertations-Reihe leiten gemeinsam das Fraunhofer-Institut 
für Produktionstechnik und Automatisierung IPA und jeweils ein Institut der Fakultät für 
Konstruktions-, Produktions- und Fahrzeugtechnik an der Universität Stuttgart. 
Die von ihnen betreuten Dissertationen sind der marktorientierten Nachhaltigkeit 
verpflichtet, ihr Ansatz ist systemisch und interdisziplinär. Die Autoren bearbeiten 
anspruchsvolle Forschungsfragen im Spannungsfeld zwischen theoretischen Grundlagen 
und industrieller Anwendung. 
Die „Stuttgarter Beiträge zur Produktionsforschung“ ersetzt die Reihen „IPA-IAO 
Forschung und Praxis” (Hrsg. H.J. Warnecke / H.-J. Bullinger / E. Westkämper / D. Spath) 
bzw. ISW Forschung und Praxis (Hrsg. G. Stute / G. Pritschow / A. Verl). In den vergan-
genen Jahrzehnten sind darin über 800 Dissertationen erschienen. 
Der Strukturwandel in den Industrien unseres Landes muss auch in der Forschung in 
einen globalen Zusammenhang gestellt werden. Der reine Fokus auf Erkenntnisgewinn 
ist zu eindimensional. Die „Stuttgarter Beiträge zur Produktionsforschung“ zielen also 
darauf ab, mittelfristig Lösungen für den Markt anzubieten. Daher konzentrieren sich die 
Stuttgarter produktionstechnischen Institute auf das Thema ganzheitliche Produktion in 
den Kernindustrien Deutschlands. Die leitende Forschungsfrage der Arbeiten ist: Wie 
können wir nachhaltig mit einem hohen Wertschöpfungsanteil in Deutschland für einen 
globalen Markt produzieren?
Wir wünschen den Autoren, dass ihre „Stuttgarter Beiträge zur Produktionsforschung“ 
in der breiten Fachwelt als substanziell wahrgenommen werden und so die Produk-
tionsforschung weltweit voranbringen.
Alexander Verl  Thomas Bauernhansl       Engelbert Westkämper
kskdxks
Modellbasierte Softwareentwicklung für mobile
Manipulatoren im industriellen Einsatz
Von der Fakultät Konstruktions-, Produktions- und Fahrzeugtechnik
der Universität Stuttgart
zur Erlangung der Würde eines Doktor-Ingenieurs (Dr.-Ing.)
genehmigte Abhandlung
Vorgelegt von
Dipl.-Ing. Alexander Bubeck
aus Magdeburg
Hauptberichter: Prof. Dr.-Ing. Dr. h. c. mult. Alexander Verl
Mitberichter: Prof. Dr.-Ing. habil. Björn Hein
Mitberichter: Prof. Dr. rer. nat. Stefan Wagner
Tag der mündlichen Prüfung: 30.11.2015
Institut für Steuerungstechnik der Werkzeugmaschinen
und Fertigungseinrichtungen
der Universität Stuttgart
2015

Vorwort
Vorwort des Verfassers
Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am
Fraunhofer-Institut für Produktionstechnik und Automatisierung IPA in Stuttgart.
Mein großer Dank gilt Herrn Prof. Dr.-Ing. Dr. h. c. mult. Alexander Verl für die Übernahme
des Hauptberichts sowie für seine Unterstützung und Förderung, sowohl für diese Arbeit als
auch für meine Tätigkeit am Fraunhofer IPA. Mein Dank gilt ebenfalls Herrn Prof. Dr.-Ing.
habil. Björn Hein und Prof. Dr. rer. nat. Stefan Wagner für die Durchsicht der Arbeit und für
die Übernahme des Mitberichts. Für die Organisation des Promotionsprozesses möchte ich Frau
Heide Kreuzburg danken.
Ein besonderer Dank gilt zudem Dr.-Ing. Kai Pfeiffer, Dr.-Ing. Ulrich Reiser, Sophie Nilsson,
Florian Weißhardt und Johannes Bix für die Durchsicht meiner Manuskripte, für die vielen wert-
vollen Anregungen und für die motivierenden Worte sowie Frau Luzia Schuhmacher M. A. für
ihre Lektor-Arbeiten. Ebenfalls danken möchte ich meinen ehemaligen Studenten, die in Form
von Praktika, Studien- und Diplomarbeiten zu dieser Arbeit beigetragen haben.
Von ganzem Herzen bedanken möchte ich mich bei meiner Freundin Nina, die mir mit großer
Geduld und viel Aufmunterung während des gesamten Promotionszeitraums zur Seite stand.
Diese Arbeit möchte ich meinen Eltern Renate und Wolfgang widmen. Ich danke Ihnen beson-
ders für ihre Förderung und Unterstützung, die sie mir während meiner schulischen Laufbahn,
meines Studiums und meiner Promotion entgegengebracht haben. Sie sind mir stets ein Vorbild.
Stuttgart, im Dezember 2015 Alexander Bubeck
iii

Summary
Kurzinhalt
Roboter, die Mobilität und Manipulation verbinden, stehen in immer größerer Anzahl für den
Einsatz in Wissenschaft, aber auch in industriellen Anwendungen zur Verfügung. Jedoch ist die
Softwareentwicklung durch die hohe Anzahl an Aktoren und Sensoren für solche Robotersysteme
aufwändig und komplex. Eine Nutzung ist im industriellen Kontext daher oft nicht wirtschaft-
lich. Ziel dieser Arbeit ist eine Verbesserung der Softwareentwicklung durch modellgetriebene
Entwicklungsmethodik herbeizuführen, um durch geringeren Aufwand, durch verstärkte Wieder-
verwendung bestehender Software und durch das bessere Separieren von Expertenwissen die
Entwicklungskosten zu senken.
Dazu wird im Rahmen dieser Arbeit eine direkte formale Beschreibung des ROS Komponenten-
frameworks als Meta-Modell entwickelt, auf dessen Basis eine Entwicklungstoolchain umgesetzt
wird. Die konzeptionelle Nähe zu den bestehenden Mechanismen innerhalb des Komponenten-
frameworks ermöglicht eine schnellere Akzeptanz bei ROS Entwicklern sowie die Wiederver-
wendung bestehender ROS Komponenten. In der Umsetzung des Meta-Modells wird dabei die
Auftrennung von Entwicklerrollen und -belangen umgesetzt. Zudem wird durch Modelltransfor-
mationen eine Unterstützung von anderen Roboterframeworks und Meta-Modellen implemen-
tiert.
Die entwickelte Toolchain wird in dieser Arbeit im Rahmen von drei Case Studies auf Ro-
boterentwicklungsprozesse angewandt und bzgl. Wiederverwendbarkeit, der Auftrennung von
Nutzerrollen und des Entwicklungsaufwands analysiert. Dabei kann eine Effizienzsteigerung und
eine Verbesserung von Wiederverwendungsmetriken gezeigt werden. Mit Hilfe einer Entwick-
lerbefragung wird zudem eine qualitative Verbesserung von Entwicklungsprozessen für mobile
Manipulatoren durch die modellbasierte Toolchain nachgewiesen.
v
Summary
Short summary
An increasing number of robots combining mobility with manipulation are available for both
scientific use cases, but also industrial applications. Due to the high number of actuators and
sensors, software development for such robot systems is elaborate and complex. Therefore, the
usage in industrial applications is often not economically feasible. The goal of this work is an
improvement in the software development for mobile manipulators by using the model based
development methodology. In order to reduce the overall development effort, the support of
reuse of existing software and the differentiation of expert knowledge are optimized by the
application of this methodology to robotics.
For that reason, a formal description of the ROS component frameworks is developed in this work
as a meta-model that is the basis for a model based development tool chain. The conceptional
vicinity to the existing mechanisms in the component framework improves the acceptance of
the ROS developers and makes reuse of existing ROS components possible. The separation
of developer concerns and roles are implemented within the meta-model. Furthermore, model
transformations are created to support different robot software frameworks and other meta-
models.
The approach is applied during the development process of three case studies using the tool
chain, evaluating the amount of reuse, the differentiation of the user roles and the amount of
development effort. An improvement of development efficency and of metrics for component
reusability are shown for the developed components and systems. By evaluation of a developer
survey, the qualitative improvement of development processes for mobile manipulators is proven.
vi
Inhaltsverzeichnis
Inhaltsverzeichnis
Abkürzungsverzeichnis xi
Abbildungsverzeichnis xiii
Tabellenverzeichnis xvii
1 Einleitung 1
1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen und Ausgangssituation 5
2.1 Verfügbare Systeme und deren Anwendungen . . . . . . . . . . . . . . . . . . . 5
2.2 Mobile Manipulation: Technologieüberblick . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Navigationssysteme zur Umsetzung von Mobilität . . . . . . . . . . . . 10
2.2.2 Komponenten für die Umgebungserfassung bei der mobilen Manipulation 12
2.2.3 Systeme zur Regelung und Steuerung der Kinematik von mobilen Robotern 12
2.3 Komponentenbasierte Entwicklung in der Robotik . . . . . . . . . . . . . . . . 14
2.3.1 Das Komponentenframework OROCOS RTT . . . . . . . . . . . . . . . 14
2.3.2 Das Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Weitere Frameworks und Bewertung von komponentenbasierter Entwick-
lung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Modellbasierte Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Anwendung von modellbasierter Softwareentwicklung in der Robotik . . . . . . . 21
2.6 Ableitung von Anforderungen an eine Entwicklungstoolchain . . . . . . . . . . . 24
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation 27
3.1 Methoden zur Umsetzung von modellbasierter Entwicklung . . . . . . . . . . . 27
3.1.1 Modellbasierte Entwicklung nach der Top-down-Methode . . . . . . . . 28
3.1.2 Modellbasierte Entwicklung nach der Bottom-up-Methode . . . . . . . . 29
3.1.3 Vergleich der Umsetzungsmethoden . . . . . . . . . . . . . . . . . . . . 30
3.2 Separierung der Entwicklerbelange . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Separierung der Entwicklerrollen . . . . . . . . . . . . . . . . . . . . . . . . . . 33
vii
Inhaltsverzeichnis
3.4 Integration mit Meta-Modellen für das High Level Design . . . . . . . . . . . . 36
3.4.1 BCM als abstraktes Meta-Modell . . . . . . . . . . . . . . . . . . . . . 36
3.4.2 SysML als abstraktes Meta-Modell . . . . . . . . . . . . . . . . . . . . 36
3.4.3 SCXML als abstraktes Meta-Modell . . . . . . . . . . . . . . . . . . . . 37
3.4.4 Integration der Meta-Modelle in den Roboterentwicklungsprozess . . . . 38
3.5 Plattformabhängigkeit in der Toolchain . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Portieren von Komponenten zwischen Softwareframeworks . . . . . . . . . . . . 39
3.7 Programmiersprachen und Zielsysteme . . . . . . . . . . . . . . . . . . . . . . 41
3.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren 45
4.1 BRIDE als eine modellbasierte Entwicklungsumgebung für ROS . . . . . . . . . 45
4.2 Das ROS Meta-Modell und die Entwicklerbelange . . . . . . . . . . . . . . . . 46
4.3 Entwicklung von Modelleditoren für ROS . . . . . . . . . . . . . . . . . . . . . 52
4.3.1 Umsetzung des Capability-Editors . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Umsetzung des Coordinator-Editors . . . . . . . . . . . . . . . . . . . . 55
4.3.3 Umsetzung des System-Editors . . . . . . . . . . . . . . . . . . . . . . 56
4.3.4 Entwickeln mit textuellen Editoren . . . . . . . . . . . . . . . . . . . . 57
4.4 Codegenerierung aus den Modellen . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 Roundtripping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6 Transformationen zwischen den Meta-Modellen . . . . . . . . . . . . . . . . . . 61
4.7 Testing und Validierungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.8 ROS-Integration der Toolchain . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5 Case Studies zur modellbasierten Entwicklung in der Robotik 69
5.1 BRICS Showcase Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1.1 Umsetzung mit BRIDE . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Regelungs-Framework für synchrone mobile Manipulation . . . . . . . . . . . . 75
5.2.1 Überarbeitung von SyncMM mit BRIDE . . . . . . . . . . . . . . . . . 75
5.2.2 Transfer zu OROCOS RTT . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Logistikszenario mit der Plattform rob@work 3 . . . . . . . . . . . . . . . . . . 80
5.3.1 Anwendungsentwicklung mit BRIDE . . . . . . . . . . . . . . . . . . . 80
5.4 Zusammenfassung der Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 84
6 Evaluation von modellbasierter Entwicklung in der Robotik 85
6.1 Auswertung der umgesetzten Komponentenmodelle . . . . . . . . . . . . . . . . 85
6.2 Portierungsaufwand von Komponenten . . . . . . . . . . . . . . . . . . . . . . 90
6.3 Qualitative Auswertung der umgesetzten Systemmodelle . . . . . . . . . . . . . 91
viii
Inhaltsverzeichnis
6.4 Analyse der allgemeinen Benutzung der modellbasierten Entwicklungstoolchain . 93
6.4.1 Das Goal-Question-Metric Verfahren . . . . . . . . . . . . . . . . . . . 93
6.4.2 Das Technology Acceptance Model . . . . . . . . . . . . . . . . . . . . 93
6.4.3 Erstellung von Evaluationsmetriken mit einer Kombination aus GQM und
TAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.4.4 Ergebnisse der Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.4.5 Bewertung der Reliabilität . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7 Abschließende Betrachtung 101
7.1 Zusammenfassung und Ergebnisse der Arbeit . . . . . . . . . . . . . . . . . . . 101
7.2 Mögliche Weiterentwicklungen von BRIDE . . . . . . . . . . . . . . . . . . . . 102
A Anhang: Fragebogen für BRIDE Nutzerumfrage 107
B Anhang: Ergebnisse der BRIDE Nutzerumfrage 111
Referenzen 113
ix

Abkürzungsverzeichnis
Abkürzungsverzeichnis
AST Abstract Syntax Tree
ATL ATL Transformation Language
BCM BRICS Component Model
BRICS Best Practice in Robotics
BRIDE BRICS integrated development environment
DDS Data Distribution Service
DSL Domain Specific Language
EMF Eclipse Modeling Framework
ETL Epsilon Transformation Language
GEF Graphical Editing Framework
GMF Graphical Modeling Framework
GQM Goal-Question-Metric
HUTN Human Usable Textual Notation
M2M Model-to-Model
M2T Model-to-Text
MDA Model-driven architecture
MDD Model-Driven Development
MOF Meta Object Facility
OCL Object Constraint Language
OMG Object Management Group
PIM Platform-independent model
xi
PSP Platform-specific model
RCC Rate of Component Customizability
RCO Rate of Component Observability
ROS Robot Operating System
SCXML State Chart XML
SOA Service Oriented Architecuture
SysML System Modeling Language
TAM Technology Acceptance Model
UML Unified Modeling Language
WADL Web Application Description Language
WSDL Web Services Description Language
XMI XML Metadata Interchange
YAML YAML Ain’t Markup Language
xii
Abbildungsverzeichnis
Abbildungsverzeichnis
1.1 Mobiler Manipulator Care-O-bot® 3 beim Bedienen eines Wasserspenders . . . . 2
2.1 AMADEUS Roboter für Intralogistikanwendungen . . . . . . . . . . . . . . . . 6
2.2 Bosch Produktionsassistent APAS . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 ImRoNet Inspektionsroboter beim Drehen eines Stellrades . . . . . . . . . . . . 7
2.4 Architekturbild eines Navigationssubsystems mit Lokalisierung und Pfadplanung 11
2.5 Visualisierung einer laufenden Navigation für einen mobilen Roboter . . . . . . . 11
2.6 Übersicht des Regelungsframework für synchrone mobile Manipulation SyncMM 13
2.7 Darstellung des OROCOS RTT Komponentenmodells . . . . . . . . . . . . . . 15
2.8 Visualisierung der OMG-Modellpyramide . . . . . . . . . . . . . . . . . . . . . 19
2.9 Umsetzung eines Reglers für synchrone mobile Manipulation in Simulink . . . . 22
3.1 Abstrakte Meta-Modelle für Robotik in der OMG-Modellpyramide . . . . . . . . 28
3.2 Frameworknahe Meta-Modelle für die Robotik in der OMG-Modellpyramide . . . 29
3.3 Fünf Belange einer Software-Komponente bei der Wiederverwendung. Nur
bestimmte Belange müssen modifiziert werden (orange) . . . . . . . . . . . . . 32
3.4 Einordnung der in dieser Arbeit definierten Entwicklerrollen in die Prozessphasen
der ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Verschiedene Entwicklerrollen und die Zuordnung der Entwicklerbelange . . . . . 34
3.6 Anwendung der Konzepte Separierung der Entwicklerbelange und Entwicklerrol-
len auf die modellbasierte Entwicklung . . . . . . . . . . . . . . . . . . . . . . 35
3.7 SysML Editor Papyrus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 Zusammenhang von abstrakten Meta-Modellen mit den verschiedenen Entwick-
lungsprozessphasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 Plattformunabhängigkeit zwischen Middlewares . . . . . . . . . . . . . . . . . . 40
3.10 Gesamtkonzeption einer modellbasierten Entwicklungsumgebung für mobile
Manipulatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Umsetzung der verschiedenen Ebenen der OMG-Pyramide in BRIDE . . . . . . . 46
4.2 Workflow zum Erstellen einer modellbasierten Toolchain mit EMF . . . . . . . . 47
4.3 Interne Zustandsmaschine einer ROS-Komponente, die mit BRIDE entwickelt
wurde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 ECore Meta-Modell für Komponenten- und Systemaspekte in ROS . . . . . . . 50
xiii
Abbildungsverzeichnis
4.5 ECore Meta-Modell für Koordinationsaspekte in ROS in Form der SMACH DSL 51
4.6 Prozess der Erstellung von GMF-basierten Modelleditoren . . . . . . . . . . . . 52
4.7 Entwicklung einer Funktionalität im BRIDE-Capability-Editor . . . . . . . . . . 53
4.8 Entwicklung einer Zustandsmaschine für eine Anwendung im BRIDE-Coordinator-
Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.9 Entwicklung von Softwaresystemen für Roboteranwendungen mit dem BRIDE
System Deployment Modellierer . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.10 Struktur eines ROS Paketes nach der Erzeugung in BRIDE . . . . . . . . . . . 59
4.11 Ablauf der Generierung von Modellen aus Quellcode zum Umsetzen von Round-
tripping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.12 Screenshot einer laufenden Modellevaluierung in BRIDE . . . . . . . . . . . . . 64
4.13 Quellcode eines autogenerierten Testcases mit blau hinterlegten Nutzermodifi-
kationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.14 Textuelles Erstellen von Modellen über eine Netzwerkverbindung mit dem Editor
VIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.15 Wikiseite des BRIDE-Projekts mit Dokumentation, Tutorials und Verknüpfung
zu anderen ROS-Projekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1 BRICS Showcase Industry Demonstrator . . . . . . . . . . . . . . . . . . . . . 70
5.2 Modelle verschiedener Komponenten aus dem BRICS Showcase Industry . . . . 71
5.3 Application-Modell des BRICS Showcase Industry . . . . . . . . . . . . . . . . 72
5.4 System-Modell des BRICS Showcase Industry . . . . . . . . . . . . . . . . . . . 74
5.5 Abstrakter Aufbau des SyncMM-Systems . . . . . . . . . . . . . . . . . . . . . 76
5.6 Systemmodell der modellbasierten Umsetzung des SyncMM-Frameworks . . . . 78
5.7 SyncMM-System im Einsatz auf dem Care-O-bot® 3 . . . . . . . . . . . . . . . 79
5.8 Architekturbild der IPA-Navigation . . . . . . . . . . . . . . . . . . . . . . . . 81
5.9 Coordinator-Modell für die beschriebene Logistikanwendung . . . . . . . . . . . 82
5.10 Ausführung des Beispiels einer Logistikanwendung mit dem rob@work 3 . . . . . 84
6.1 Vergleich der ROS-Abhängigkeit von Komponenten nach klassischer und mit
modellbasierter Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 Vergleich der Rate of Component Observability von Komponenten nach
klassischer und mit modellbasierter Entwicklung . . . . . . . . . . . . . . . . . 90
6.3 Vergleich der Rate of Component Customizability von Komponenten nach
klassischer und mit modellbasierter Entwicklung . . . . . . . . . . . . . . . . . 90
6.4 Überblick über die qualitatitve Evaluationsstrategie für die Toolchain BRIDE . . 94
6.5 GQM für das Evaluationsziel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.6 GQM für das Evaluationsziel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.7 GQM für das Evaluationsziel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 96
xiv
Abbildungsverzeichnis
6.8 Resultate der Umfrage zu Evaluationsziel 1 . . . . . . . . . . . . . . . . . . . . 97
6.9 Resultate der Umfrage zu Evaluationsziel 2 . . . . . . . . . . . . . . . . . . . . 98
6.10 Resultate der Umfrage zu Evaluationsziel 3 . . . . . . . . . . . . . . . . . . . . 99
6.11 Resultate der Umfrage zu TAM . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.1 Protege Editor zur Entwicklung von OWL-basierten, semantischen Modellen . . 103
7.2 Entwickler während der Verwendung von BRIDE für eine industrielle Roboteran-
wendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
xv

Tabellenverzeichnis
Tabellenverzeichnis
2.1 Vergleich der Funktionalität von verfügbaren mobilen Manipulatoren . . . . . . . 8
2.2 Vergleich der Hardwareausstattung von verfügbaren mobilen Manipulatoren . . . 8
2.3 Abschätzung des Entwicklungsaufwandes für verschiedene Teile einer Roboter-
szenarienentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Überblick über die Mechanismen des Komponentenframeworks ROS . . . . . . . 17
2.5 Die Bewertungsskala von modellbasierter Entwicklung . . . . . . . . . . . . . . 21
2.6 Überblick über derzeitige modellbasierte Entwicklungsumgebungen für die Robotik 23
3.1 Vergleich der Ansätze zur Entwicklung einer modellbasierten Toolchain . . . . . 30
4.1 Zuordnung von Entwicklerbelangen zu den ROS-Mechanismen . . . . . . . . . . 50
4.2 Zuordnung von BCM-Modellierungsmechanismen zu ROS-Modellierungs-
mechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Zuordnung von SysML-Modellierungsmechanismen zu ROS-Modellierungs-
mechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 Auszug der Validierungsregeln des BRIDE Capability Editors . . . . . . . . . . 63
6.1 Liste der in den Case Studies entstandenen Komponenten . . . . . . . . . . . . 86
6.2 Evaluation der in den Case Studies entstandenen Komponenten . . . . . . . . . 88
6.3 Evaluation der Metriken für die ursprünglichen Komponenten, die nicht modell-
basiert entstanden sind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.4 Metriken zu den auf OROCOS RTT portierten Komponenten . . . . . . . . . . 91
6.5 Ergebnisse der Evaluation der BRIDE Systeme aus den Case Studies . . . . . . . 92
6.6 Bereiche, für die das Technology Acceptance Model angewandt werden kann . . 94
6.7 Metriken des Technology Acceptance Model angewandt auf die Evaluation von
BRIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
xvii

1 Einleitung
1.1 Problemstellung
Durch die stetige Verbesserung von Aktoren und Sensoren im Serviceroboterbereich entstehen
immer wieder neue Anwendungsbereiche und Robotertypen. In den letzten Jahren ist daher die
Anzahl an verfügbaren Plattformen aus der Kategorie der mobilen Manipulatoren stark ange-
wachsen. Bei diesen Robotertypen werden kleine und leichte Manipulatoren durch Mobilität einer
aktiv bewegten Plattform unterstützt. Damit ergeben sich viele neue Einsatzgebiete und Arbeits-
bereiche, da die Manipulatoren durch die Mobilität einen sehr großen Arbeitsraum bekommen.
Gleichzeitig können die Flexibilität und Sicherheitseigenschaften der kompakten Manipulatoren
genutzt werden. Einhergehend mit der Verfügbarkeit von Hardwareplattformen wurden in der
Wissenschaft gerade in der letzten Dekade eine Vielzahl von Steuerungskonzepten und Algorith-
men entwickelt, die den Einsatz von mobilen Manipulatoren ermöglichen. Die Ansätze werden vor
allem im Rahmen von Experimenten in künstlichen Wohnumgebungen evaluiert (siehe Beispiel
in Abbildung 1.1), um der Vision von Robotern in jedem Heim nachzukommen (Graf, Jacobs
et al. 2012).
Dem gegenüber ist die Anzahl der in der Praxis befindlichen mobilen Manipulatoren in industriel-
len Anwendungsszenarien, die in Kapitel 2 dieser Arbeit diskutiert werden, sehr begrenzt. Wenn
überhaupt werden klassische fahrerlose Transportsysteme mit einfachen Sensoren, wie beispiels-
weise Kameras für optische Linienführung, verwendet, um Manipulatoren zwischen definierten
Punkten zu bewegen. An diesen Punkten führen die Manipulatoren dann fest programmierte
Funktionalitäten aus. Das enorme Einsatzpotential von flexiblen mobilen Manipulatoren, das im
Rahmen von Evaluationen im Forschungsumfeld nachgewiesen ist, wird in der Praxis noch we-
nig genutzt. Bezüglich Geschwindigkeit, Flexibilität und wirtschaftlichen Gesichtspunkten sind
menschliche Arbeiter in Einsatzfällen von Manipulation mit hoher Mobilität zur Zeit Robotern
stark überlegen (Hägele, Blümlein et al. 2011).
Beim Blick auf heutige mobile Manipulatoren in der angewandten Forschung fällt auf, dass
die Gesamtkomplexität dieser Roboter recht hoch ist. Durch das Zusammenführen von mobiler
Plattform und Manipulator erhöht sich nicht nur die Anzahl der Freiheitsgrade des Roboters. Die
1
1 Einleitung
erhöhte Flexibilität erfordert den Einsatz zusätzlicher, meist heterogener Sensorsysteme wie 3D-
Umgebungserfassung und Laserlokalisierung. Die eingesetzten Aktuator- und Wahrnehmungs-
systeme sind in der Regel nicht für einen kombinierten Einsatz ausgelegt, was die Integration
erschwert, aber auch dafür sorgt, dass bei mobilen Manipulatoren verteilte Systeme aus meh-
reren Regelsystemen zur Ansteuerung eingesetzt werden. Höhere Komplexität in der Hardware
führt daher zu einem höheren Softwareentwicklungsaufwand.
Abbildung 1.1: Mobiler Manipulator Care-O-bot® 3 beim Bedienen eines Wasserspenders
Mobile Manipulatoren, wie beispielsweise der Care-O-bot® 3, enthalten mehrere hundert se-
parate Softwarekomponenten, die zur Nutzung des Roboters erforderlich sind. Während dieser
Aufwand im Forschungsbereich beherrschbar und zum Teil forschungsrelevant ist, kann man
beim Technologietransfer in industrielle Anwendungen die Entwicklungskosten nur auf einen
wirtschaftlich sinnvollen Wert reduzieren, wenn der Großteil der Softwarekomponenten als fer-
tige Module wiederverwendet werden kann. Diese einfache Wiederverwendung von offenen, aus
der Forschung kommenden oder kommerziellen Softwaremodulen auf mobilen Manipulatoren ist
zur Zeit nur bedingt möglich (Brugali, Gherardi et al. 2012).
Zusätzlich zum hohen Entwicklungsaufwand ist durch die Diversität der eingesetzten Software-
und Hardwaremodule auf einem mobilen Manipulator auch die fachliche Anforderung an einen
Systemintegrator sehr unterschiedlich. Bei der Anwendungsentwicklung für mobile Manipulato-
ren sind daher sehr gut ausgebildete Systemtechniker erforderlich, um eine ausreichende Ge-
schwindigkeit und Flexibilität zu erreichen. Dies erhöht die Entwicklungskosten und begrenzt
aktuell die Verbreitung von mobilen Manipulatoren.
2
1.2 Zielsetzung
1.2 Zielsetzung
Um die Verbreitung von mobilen Manipulatoren in Anwendungen der industriellen Servicerobotik
zu erhöhen, beschäftigt sich diese Arbeit mit den Herausforderungen in der Softwareentwicklung
bei der Umsetzung von Systemen und Anwendungen mit diesem Robotertyp. Dabei wird eine
vollständige Entwicklungs-Toolchain für mobile Manipulatoren im industriellen Umfeld konzipiert
und umgesetzt, die gegenüber den bestehenden Softwareentwicklungsframeworks für Roboter
folgende Vorzüge haben soll:
• Reduktion der Komplexität für Entwickler: Dabei wird insbesondere durch das Abkapseln
von Subsystemen und die Konzentration von Expertenwissen auf bestimmte Bereiche die
Komplexität von mobilen Manipulatoren reduziert.
• Reduktion des Entwicklungsaufwandes: Eine häufigere Wiederverwendung von bestehender
Software auf verschiedenen mobilen Manipulatoren verringert den Entwicklungsaufwand
stark. Die Toolchain soll daher vor allem implizite Abhängigkeiten in den Softwarekompo-
nenten abbauen.
• Trennung von Komponenten-, System- und Anwendungsentwicklung: Ein Anwendungs-
entwickler muss sich nur noch mit der Konfiguration des Softwaresystems für die Anwen-
dungen beschäftigen, wie es heute bei Industriemanipulatorsystemen der Fall ist.
Der Fokus dieser Arbeit liegt nicht nur auf der Konzeption von Werkzeugen für die Software-
entwicklung, sondern auch auf deren Umsetzung. Damit kann der Einfluss der entwickelten
Werkzeuge auf die Roboterentwicklung konkret nachvollzogen werden.
1.3 Vorgehensweise
Im Rahmen dieser Arbeit wird eine modellgetriebene Entwicklungsumgebung für mobile Mani-
pulatoren in der Produktion geschaffen. Dazu wird in Kapitel 2 ein Überblick über bestehen-
de mobile Manipulatoren, deren Software- und Hardwaresysteme sowie über allgemeine Soft-
wareentwicklungskonzepte gegeben. Auf dieser Basis werden konkrete Anforderungen an einen
neuartigen Entwicklungswerkzeugkasten herausgearbeitet. Bewährte Erfolgsmethoden aus der
Softwareentwicklung anderer Domänen werden in Kapitel 3 auf das Themengebiet der mobi-
len Manipulation angewandt und entsprechend der ermittelten Anforderungen erweitert. Zudem
werden diese erfolgreichen Praktiken in bestehende Entwicklungskonzepte der Robotik integriert.
Die konkrete Umsetzung einer Toolchain, die die entwickelten Konzepte und bestehenden Werk-
zeuge der Roboterentwicklung integriert, wird in Kapitel 4 behandelt. Um die Tauglichkeit der
Toolchain für verschiedene Anwendungsfälle nachzuweisen, werden in Kapitel 5 drei repräsenta-
tive Entwicklungsprozesse mit zunehmender Komplexität erläutert.
3
1 Einleitung
Die Optimierung der Entwicklungsprozesse hinsichtlich der eingangs beschriebenen Herausfor-
derungen bei der Umsetzung von Anwendungen mit mobilen Manipulatoren wird schließlich in
Kapitel 6 anhand einer quantitativen Analyse von erzeugten Softwareartefakten durchgeführt.
Zudem wird mittels einer Nutzerumfrage qualitativ der Einfluss der entstandenen Werkzeuge
nachgewiesen. Kapitel 7 fasst schließlich die Ergebnisse dieser Arbeit zusammen und zeigt weiter
Entwicklungsperspektiven und -herausforderungen für die mobile Manipulation in der Produktion
auf.
4
2 Grundlagen und Ausgangssituation
Im Rahmen dieses Kapitels wird ein Überblick über bestehende Installationen von mobilen Ma-
nipulatoren gegeben. Dabei werden besonders die für die Anwendung erforderlichen Software-
systeme und deren Umsetzung untersucht. Da außerhalb der Robotik auch in anderen Domä-
nen komplexe Softwaresysteme im Einsatz sind, wird ein Überblick über Entwicklungsstrategien
in solchen Systemen gegeben. Anhand einer Analyse von transferierten Technologien aus der
Softwareentwicklung in die Robotik werden Vorteile und Defizite dieser Ansätze diskutiert und
Anforderungen für eine Anwendung auf die mobile Manipulation abgeleitet.
2.1 Verfügbare Systeme und deren Anwendungen
Bei Transportaufgaben im industriellen Umfeld befinden sich fahrerlose Transportsysteme, d.h.
mobile autonome Plattformen, seit Jahren im Einsatz. Durch die Weiterentwicklung kompak-
ter und energieeffizienter Manipulationssysteme können die fahrerlosen Transportsysteme um
Manipulatoren ergänzt werden. Im Gegensatz zu Manipulatorsystemen auf Linearachsen, die
bereits in einigen Industrieanwendungen umgesetzt wurden, besteht beim Einsatz von mobilen
Plattformen ein höheres Maß an Flexibilität. Ein solches Robotersystem, bestehend aus einer
frei beweglichen, mobilen Plattform und einem Manipulatorsystem wird im Folgenden als mo-
biler Manipulator bezeichnet. Wenn sich Plattform und Manipulator koordiniert und zeitgleich
bewegen können, spricht man von synchroner mobiler Manipulation.
In der Wissenschaft sind mobile Manipulatoren, auch mit synchroner Regelung, schon seit etwa
25 Jahren Forschungsgegenstand (siehe beispielsweise (Brooks, Connell et al. 1988)). Durch
die Einführung von standardisierten Forschungsplattformen, wie beispielsweise den Systemen
PR2 (Wyrobek, Berger et al. 2008), Justin (Fuchs, Borst et al. 2009) und Care-O-bot® 3 (Rei-
ser, Connette et al. 2009), ist zudem die Integration von Forschungsergebnissen in Anwendungen
forciert worden. Daher sind die wissenschaftlichen Grundlagen bzgl. der erforderlichen Robo-
tertechnologien bereits sehr weit entwickelt. Um eine noch anwendungsbezogenere Forschung
für den Einsatz von mobilen Manipulatoren voranzutreiben, sind ebenfalls Standardplattformen
für den industriellen Einsatz entwickelt worden, wie beispielsweise der Kuka Omnirob oder der
5
2 Grundlagen und Ausgangssituation
rob@work 3. Diese Systeme ermöglichen das Entwickeln von Anwendungen direkt in der Ferti-
gung oder Montageanlage des Endnutzers.
Aktuell umgesetzte Anwendungen mit mobilen Manipulatoren in der Produktion lassen sich
in mehrere Gebiete unterteilen. Man findet Beispiele im Anwendungsgebiet der Logistik, der
Montage und auch der Inspektion und Wartung.
In den Forschungsprojekten TAPAS, PISA und AMADEUS (Halt, Messmer et al. 2012) wurde
die Umsetzung konkreter Anwendungen der Logistik untersucht, bei denen mittels eines Mani-
pulators von einer mobilen Plattform aus Teile bewegt werden. Dabei kommen neben anwen-
dungsspezifischen Systemen (siehe Abbildung 2.1) auch bereits am Markt erhältliche Produkte
wie der Little Helper (Hvilshoj, Bogh et al. 2009) und Roboter der Neobotix GmbH zum Einsatz.
Abbildung 2.1: AMADEUS Roboter für Intralogistikanwendungen
Da in einem weiteren Anwendungsfeld, der Montage, die Komplexität der Aufgaben in der Pro-
duktion in der Regel sehr hoch ist, kommen mobile Manipulatoren hier vor allem als sogenannte
Produktionsassistenten in Verbindung mit dem menschlichen Werker zum Einsatz. Dabei müssen
zusätzlich zu den technischen Herausforderungen auch Sicherheitsaspekte berücksichtigt werden.
Auch in diesem Bereich gibt es zusätzlich zu den speziell entwickelten Hardwareplattformen be-
reits Roboter im Produktstadium. Als Beispiel ist hier die APAS Plattform von Bosch (Dose und
Dillmann 2012) zu nennen, die zwar in der aktuell erhältlichen Version noch auf einer passiven
mobilen Plattform aufbaut, die jedoch ansonsten alle Eigenschaften eines mobilen Manipulators
aufweist (siehe Abbildung 2.2). Eine generelle Untersuchung von Einsatzpotentialen von mobilen
Manipulatoren für die beschriebenen Bereiche Logistik und Produktion findet sich zudem in (An-
gerer, Strassmair et al. 2012). Darin werden typische Einsatzszenarien für mobile Manipulatoren
untersucht und Kriterien für deren Nutzung festgelegt.
6
2.1 Verfügbare Systeme und deren Anwendungen
Abbildung 2.2: Bosch Produktionsassistent APAS
Im Bereich der Inspektion und Wartung werden ebenfalls schon seit längerem mobile Plattfor-
men eingesetzt. Im Rahmen der Forschungsprojekte ImRoNet (Arbeiter, Bubeck et al. 2010)
und MimroEx (Pfeiffer, Bengel et al. 2011) wurde untersucht, inwiefern die Erweiterung der
mobilen Plattformen zu mobilen Manipulatoren neues Automatisierungspotential eröffnet. Ge-
rade in gefährlichen und kontaminierten Bereichen, bei denen manuelle Inspektion und Wartung
nur sehr schwer möglich ist, kann erst durch den zusätzlichen Einsatz von Manipulatoren die
Automatisierung vollständig umgesetzt werden (siehe Abbildung 2.3). Es können, wie im Fall
von MimroEx, durch den Manipulator Sensorsysteme in schwer zugängliche Bereiche gebracht
werden oder nicht-automatisierte Prozessteile (wie z.B. manuelle Stellräder) nachträglich auto-
matisiert werden. In der Anwendung werden die autonomen Technologien der Roboter häufig
mit Teleoperationssystemen kombiniert, um die Bedienung der Roboter zu vereinfachen.
Abbildung 2.3: ImRoNet Inspektionsroboter beim Drehen eines Stellrades
Obwohl für verschiedene Einsatzszenarien entwickelt, haben die vorgestellten mobilen Manipu-
latoren viele Gemeinsamkeiten. In der folgenden Tabelle 2.1 wird ein Überblick über die im
industriellen Kontext eingesetzten mobilen Manipulatoren aus Sicht der Funktionalität gegeben.
7
2 Grundlagen und Ausgangssituation
Tabelle 2.1: Vergleich der Funktionalität von verfügbaren mobilen Manipulatoren (Forschungs-
plattformen kursiv)
Roboter Geplante
Manipulation
Synchrone Mobile
Manipulation
Freie Navigation
TAPAS Little Helper nein nein ja
AMADEUS nein nein nein
BOSCH APAS nein nein nein
MimroEx nein nein ja
ImRoNet ja ja ja
PR2 ja nein ja
Care-O-bot® 3 ja ja ja
rob@work 3 ja ja ja
Zum Vergleich werden die Forschungsplattformen ImRoNet, PR2, Care-O-bot® 3 und rob@work3
mit betrachtet. Die in Tabelle 2.1 genannten Funktionalitäten von mobilen Manipulatoren sind
ausgewählt, da mit ihnen die volle Flexibilität der mobilen Manipulatoren nutzbar ist.
Tabelle 2.2: Vergleich der Hardwareausstattung von verfügbaren mobilen Manipulatoren (For-
schungsplattformen kursiv)
Roboter Sensorik Mobile Basis Freiheitsgrade des
Manipulators
TAPAS Little Helper Kamera (lokal) differentiell 6
AMADEUS Magnetschleifen (lokal) omnidirektional 7
BOSCH APAS Kamera (lokal) passiv 6
MimroEx Laserscanner, Kamera (lokal) omnidirektional 6
ImRoNet PMD, Farbkamera,
Laserscanner
differentiell 7
PR2 Stereokamera (gesamter
Bereich), Laserscanner,
3D-Kamera
omnidirektional 2 x 7
Care-O-bot® 3 Stereokamera (gesamter
Bereich), Laserscanner,
3D-Kamera
omnidirektional 7
rob@work 3 Stereokamera (gesamter
Bereich), Laserscanner,
3D-Kamera
omnidirektional 7
Beim Vergleich der vorgestellten industriellen Robotersysteme in Tabelle 2.1 mit den Forschungs-
systemen fällt auf, dass viele mögliche Funktionalitäten in industriellen Robotersystemen nicht
8
2.1 Verfügbare Systeme und deren Anwendungen
zum Einsatz kommen. Dies ist der Fall, obwohl auf den industriell genutzten Robotern eine
ähnliche Ausstattung an Sensoren und Aktoren wie bei den Forschungsplattformen zu finden
ist (siehe Tabelle 2.2). Viele Möglichkeiten der Flexibilität und des Automatisierungsspektrums
werden daher nicht genutzt. Zudem wurden die Softwarekomponenten der vorgestellten mo-
bilen Manipulatoren fast vollständig in öffentlich geförderten Forschungsprojekten entwickelt.
Kommerzielle Robotersteuerungen für mobile Manipulation sind derzeit noch nicht verfügbar.
Tabelle 2.3: Abschätzung des Entwicklungsaufwandes für verschiedene Teile einer Robotersze-
narienentwicklung aus einer Studie (Hägele, Blümlein et al. 2011)
Szenario Hardwareinvestitionskosten Softwarekosten Faktor SW/HW
Außenanlagenwartung 0,2 Mio. e 1,5 Mio. e 7,5
Containertransport 1,1 Mio. e 3,3 Mio. e 3
Produktionsassistenz 1,5 Mio. e 4,4 Mio. e 2,9
Ein Blick in die Studie “Wirtschaftlichkeitsanalysen neuartiger Servicerobotik-Anwendungen und
ihre Bedeutung für die Robotik-Entwicklung” (Hägele, Blümlein et al. 2011), die Entwicklungs-
kosten von Servicerobotikanwendungen untersucht, gibt Aufschluss über eine mögliche Ursache
des eingeschränkten Funktionsumfangs von industriellen mobilen Manipulatoren. In der Studie
wird deutlich, dass die Softwareentwicklung einer der Hauptkostenfaktoren bei der Entwicklung
von Servicerobotikanwendungen ist. Wie die Tabelle 2.3 für einige ausgewählte Anwendungs-
szenarien aus dem Bereich Logistik und Montage der Studie zeigt, liegen die Kosten für die
Softwareentwicklung weit über den Hardwarekosten. Die Studie zeigt auf, dass diese Kosten
mit der Komplexität der Anwendungen korrelieren. Diese Studie geht hierbei für das jeweilige
Szenario von einer Neuentwicklung der Software aus. Durch Wiederverwendung bestehender
Softwaresysteme können jedoch die Kosten gesenkt werden, wie in (Poulin, Caruso et al. 1993)
gezeigt. Es muss also Ziel sein, die Wiederverwendung bei der Entwicklung von Robotern zur
mobilen Manipulation zu steigern.
Zusammenfassend lässt sich aus den bisherigen Anwendungen von mobilen Manipulatoren schlie-
ßen, dass die eingesetzten Robotersysteme zwar aus Sicht der Hardware sehr flexible und funkti-
onsreiche Automatisierungssysteme sind, durch den geringen Integrationsgrad und den begrenz-
ten Softwareentwicklungsumfang jedoch die Einsatzmöglichkeiten der Systeme stark beschränkt
werden.
9
2 Grundlagen und Ausgangssituation
2.2 Mobile Manipulation: Technologieüberblick
Das Softwaresystem eines mobilen Manipulators muss im Gegensatz zu einfachen mobilen Platt-
formen oder einfachen Manipulatoren weit aus mehr Funktionalität bereitstellen. Im Folgen-
den werden die einzelnen erforderlichen Technologien diskutiert. Die Aktoren und Sensoren des
Roboters werden dabei meist über eine Abstraktionsschicht in das System integriert, so dass
Erkennungs- und Navigationsalgorithmen darauf aufgesetzt werden können. Die daraus resultie-
renden Bewegungsbefehle werden dann mit entsprechenden Steuerungsarchitekturen umgesetzt.
2.2.1 Navigationssysteme zur Umsetzung von Mobilität
Das Ziel eines Navigationssoftwaresystems ist es, den mobilen Roboter koordiniert in eine ge-
wünschte Position oder auf einer gewünschten Bahn zu bewegen. Es ist somit ein wichtiger
Bestandteil eines mobilen Manipulators und besteht aus einem Lokalisierungsverfahren, welches
aktuell messbare Umgebungsmerkmale (“FeatureMeasurementSource” in Abbildung 2.4) mit be-
kannten Umgebungsmerkmalen (“FeatureAssumptionSource” in Abbildung 2.4) abgleicht und
daraus die Position des Roboters im Raum bestimmt (beispielsweise durch einen Kalmanfilter
Abbildung 2.4). Da man bei mobilen Manipulatoren die Flexibilität der Plattform für die bes-
sere Manipulation einsetzen will, können Lokalisierungsverfahren wie Magnetspurführung oder
optische Spurführung nur bedingt Vorteile bringen, da hier die Bewegung der Plattform schon
vorher bekannt sein muss. Vielmehr sollten bei mobilen Manipulatoren Lokalisierungsverfahren
verwendet werden, die eine freie beliebige Bewegung ermöglichen. Landmarkenbasierte Naviga-
tionssysteme sind ein Beispiel für ein solches freies Lokalisierungsverfahren. Zusätzlich besteht
ein Navigationssystem aus Pfadplanungsalgorithmen, die basierend auf der Lokalisierung und
dem Applikationsziel die gewünschte Bewegung des Roboters berechnen (in Abbildung 2.4 mit
“Global planner” und “Local planner” benannt). Eine weitere Möglichkeit ist die Plattform
direkt gekoppelt mit der Manipulatorsteuerung zu bewegen. Das gesamte Navigationssystem
der mobilen Plattform stellt in diesem Fall eine Subarchitektur dar, die aus den verschiedenen
Signalflüssen der Lokalisierung sowie verschiedenen kaskadierten Pfadplanern besteht. In Ab-
bildung 2.4 ist als Beispiel die Architektur eines Navigationssystems dargestellt. Abbildung 2.5
zeigt die Visualisierung des laufenden Navigationssubsystems mit den Laserscannerdaten, den
kartierten Umgebungsmerkmalen und dem berechneten Roboterpfad.
10
2.2 Mobile Manipulation: Technologieüberblick
Abbildung 2.4: Architekturbild eines Navigationssubsystems mit Lokalisierung und Pfadplanung
Abbildung 2.5: Visualisierung einer laufenden Navigation für einen mobilen Roboter mit Sensor-
daten (gelb), Umgebungsmerkmalen (schwarz) und geplantem Pfad (grün)
11
2 Grundlagen und Ausgangssituation
2.2.2 Komponenten für die Umgebungserfassung bei der mobilen
Manipulation
Zusätzlich zu Sensoren zur Umgebungserfassung auf der mobilen Plattform selbst sind beim
Einsatz von Manipulatoren auf der Plattform weitere Sensoren notwendig. Bei mobilen Mani-
pulatoren, die im Arbeitsbereich von Menschen arbeiten, müssen Kollisionen vermieden werden.
Daher werden 3D Sensoren verwendet, um die Umgebung um den Manipulator wahrzunehmen
und diese in die Pfadplanung des Manipulators einzubeziehen. Selbst in statischen Umgebun-
gen, bei denen die Absicherung durch die Sensoren der Plattform ausreicht, müssen zusätzliche
Kamerasysteme eingesetzt werden, um eine höhere Präzision am Roboterwerkzeug bei Greifvor-
gängen zu erreichen. Die Softwarearchitektur bei Algorithmen zur Umgebungserfassung besteht
meistens aus einer Anzahl von Sensor-Pipelines, d.h. einer kettenartigen Aneinanderreihung von
Softwaremodulen, die vom eigentlichen Sensor über Filter bis hin zum Analysealgorithmus füh-
ren. Verbreitet ist die Benutzung von offenen Bibliotheken zur Verarbeitung von Bildern (Culjak,
Abram et al. 2012), Punktwolken (Rusu und Cousins 2011) oder der Verwaltung von Umgebungs-
modellen (Hornung, Wurm et al. 2013). Die Ergebnisse der Wahrnehmung werden in einem oder
mehreren Umgebungsmodellen gespeichert und zur Laufzeit von Bewegungsplanern verwendet.
2.2.3 Systeme zur Regelung und Steuerung der Kinematik von
mobilen Robotern
Die aufgrund der Wahrnehmung und Planung berechneten Bewegungen müssen über eine Steue-
rungsarchitektur an die Antriebe weitergegeben werden. Die für die Ansteuerung der mobilen
Plattform und des Manipulators infrage kommenden Regelungsverfahren hängen von der Kine-
matik des jeweiligen Roboters ab. Man unterscheidet bzgl. der Regelung bei mobilen Plattformen
nach Anzahl der Freiheitsgrade in der kartesischen Bewegung in nicht-omnidirektionale und om-
nidirektionale Plattformen. Letztere kann man entsprechend vorhandener Zwangsbedingungen
nach (Campion, Bastin et al. 1993) in verschiedene Klassen unterteilen, die unterschiedliche
Regelungsverfahren zur Umsetzung der Bewegung erfordern. Da bei mobilen Manipulatoren
fast ausschließlich serielle Manipulatorkinematiken eingesetzt werden, gleichen sich die Armre-
gelungsverfahren der unterschiedlichen Robotersysteme. Je nach Anwendungsfall werden ggf.
kraftbasierte Regelungsverfahren wie Impedanzregelung umgesetzt.
Da die Führungsgrößen des Reglers sowohl bei Plattformen als auch bei Manipulatoren zumeist
aus kartesischen Signalen bestehen, die vom Benutzer oder von einem Erkennungsalgorithmus
kommandiert werden, ist die Umrechnung vom kartesischen Raum in den Gelenkwinkelraum des
Roboters ein wichtiger Teil der Regler von mobilen Manipulatoren.
Man kann bei einem mobilen Manipulator Plattform und Manipulator synchron und asynchron
verwenden. Im asynchronen Fall werden zumeist die vom Hersteller optimierten Robotercon-
troller für die Regelung nach Verfahren im kartesischen Raum eingesetzt. Für eine synchrone
12
2.2 Mobile Manipulation: Technologieüberblick
Verwendung eines mobilen Manipulators muss jedoch ein Regler umgesetzt werden, der die Be-
wegungen von Plattform und Arm koordiniert. In der Fachliteratur wurden verschiedene Ansätze
entwickelt, die sich in der Verschaltung der Kinematiken und in der Auflösung der durch das
Verschalten entstehenden Redundanz unterscheiden. Beispiele hierfür sind (Yamamoto und Yun
1993), (Yamamoto und Yun 1995), (Khatib, Yokoi et al. 1996), (Nassal 1994) und (Ögren,
Egerstedt et al. 2000). Abbildung 2.6 zeigt ein Komponentenbild für das auf dem Verfahren
von Nassal basierenden SyncMM System (Bubeck, Connette et al. 2012), das eine synchrone
Reglerstruktur für den mobilen Manipulator Care-O-bot® 3 umsetzt. Aufgrund der Komplexi-
tät von synchronen Reglersystems ist eine praktische Umsetzung im Rahmen einer industriellen
Anwendung bisher noch nicht erfolgt.
Abbildung 2.6: Übersicht des Regelungsframework für synchrone mobile Manipulation SyncMM
Auf einem mobilen Manipulator müssen die beschriebenen Technologien für die Subsysteme
Navigation, Wahrnehmung und Regelung verbunden und integriert werden. Da es zwischen
diesen Subsystemen Wechselwirkungen gibt und die Abhängigkeiten von Hardwareschnittstellen
überlappend sind, ist die resultierende Komplexität nicht nur die Summe aus der Komplexität der
Subsysteme. Vielmehr muss ein Systemintegrator komplexes Wissen aller Technologien besitzen,
um das Softwaresystem für einen mobilen Manipulator umzusetzen.
13
2 Grundlagen und Ausgangssituation
2.3 Komponentenbasierte Entwicklung in der Robotik
Aufgrund der vielen Technologien und unterschiedlichen Architekturen von mobilen Manipula-
toren hat sich zusätzlich zur objektorientierten Abstraktion aus der Softwareentwicklung die
Strukturierung der Software in Komponenten durchgesetzt. Dabei werden die einzelnen Subsys-
teme der Navigation, Wahrnehmung und Regelung in unterschiedlich granulare Softwarekompo-
nenten aufgeteilt. Eine Softwarekomponente ist dabei nach (Szyperski, Bosch et al. 1999) wie
folgt definiert: “Eine Softwarekomponente ist ein Kompositionselement, das festgeschriebene
Schnittstellen und nur explizit formulierte Abhängigkeiten hat. Eine Softwarekomponente kann
unabhängig genutzt und extern mit anderen Komponenten verknüpft werden.”
Der Vorteil von komponentenbasierten Softwaresystemen ist die einfache Austauschbarkeit von
Systemteilen. Dadurch können Softwarekomponenten auch über Systemgrenzen hinweg wie-
derverwendet werden. Weiterhin können mit den gleichen Komponenten unterschiedliche Ar-
chitekturen umgesetzt werden. Die Umsetzung der Schnittstellen zwischen den Komponenten
kann unterschiedlich abstrakt funktionieren, so dass komponentenbasierte Systeme oft auch über
Rechnergrenzen hinweg verteilbar sind.
2.3.1 Das Komponentenframework OROCOS RTT
Um ein komponentenbasiertes Softwaresystem umzusetzen, wird ein Softwareframework ver-
wendet, das es erlaubt, die Schnittstellen- und Abhängigkeitsspezifikationen zu beschreiben.
Eines der in der Robotik durchgesetzten Frameworks ist das OROCOS RTT System (Bruy-
ninckx 2001), im Folgenden mit RTT abgekürzt. Die Besonderheit an RTT ist die Umsetzung
der Schnittstellen mittels eines speicher-basierten Kommunikationsmechanismus, der ohne Blo-
ckieren des Programmflusses der Komponente funktioniert. Bei datenfluss-orientierter Kommu-
nikation bleibt somit das Zeitverhalten der Komponenten deterministisch und die Umsetzung
von echtzeitfähigen Komponenten wird möglich. Dies ist eine Eigenschaft, die im Bereich der
Regelungstechnik eines Robotersystems sehr relevant ist, bei Funktionalitäten wie Planung oder
Wahrnehmung jedoch eine untergeordnete Rolle spielt. Die Komponenten werden mittels ei-
nes Softwaretools, bei RTT “deployer” genannt, konfiguriert und verbunden. Zusätzlich zur
echtzeitfähigen, speicher-basierten Verknüpfung kann eine netzwerk-basierte verteilte Kompo-
nentenstruktur umgesetzt werden. Hierzu wird zur Kommunikation das CORBA Framework
verwendet.
RTT gibt zusätzlich zur Formulierung der Schnittstellen und Abhängigkeiten auch ein einheit-
liches internes Verhalten der Komponenten vor. Daher hat RTT eine standardisierte Statema-
chine innerhalb der Komponenten. Durch den hohen Programmieraufwand bei der Erstellung
von Komponenten und die Unterstützung von nur C/C++ als Programmiersprache sind bisher
vergleichsweise wenige Komponenten in RTT umgesetzt. Zudem existieren wenige Systeme mit
14
2.3 Komponentenbasierte Entwicklung in der Robotik
einer großen Zahl von unterschiedlichen Komponenten. In Abbildung 2.7 ist der Aufbau einer
RTT-Komponente mit den Schnittstellen (Ports und Operations) dargestellt.
Abbildung 2.7: Darstellung des OROCOS RTT-Komponentenmodells aus (Bruyninckx 2001)
2.3.2 Das Robot Operating System
Das Robot Operating System (ROS) (Quigley, Conley et al. 2009) ist ein weiteres Framework
zur Umsetzung von komponentenbasierten Systemen in der Robotik. Ähnlich wie RTT han-
delt es sich bei ROS um ein Projekt, das die Kommunikationsfunktionalität sowie eine Vielzahl
von Werkzeugen zur Umsetzung von Softwaresystemen für Roboter zur Verfügung stellt. Zwar
gleicht ROS konzeptionell RTT in vielen Aspekten, es unterscheidet sich jedoch in der techni-
schen Umsetzung der Kommunikation. Im Gegensatz zu RTT sind in ROS alle Komponenten
separate Prozesse. Die Kommunikation passiert immer über eine für ROS spezifische Schnittstel-
lenumsetzung. Daher kann ein ROS System immer als verteiltes System betrachtet werden. Das
Kommunikationsprotokoll basiert auf dem in der Internettechnologie verbreiteten RPC-Protokoll
in Verbindung mit direkten TCP- und UDP-Binärkanälen. Durch diese netzwerk-basierte Um-
setzung können die Komponenten im Gegensatz zu RTT nicht in einem Anwendungskontext
benutzt werden, der Echtzeit-Verhalten erfordert.
Die Unterstützung von sehr vielen Programmiersprachen und eine flexibel nutzbare Komponen-
tenspezifikation hat ROS zum in der Robotik am weitesten verbreiteten Framework geführt. Es
gibt beim heutigen Stand über 3000 Softwarekomponenten, die mit ROS umgesetzt wurden,
viele davon mit Open Source Lizenzen. Dadurch ist ROS-Kompatibilität ein für viele Kompo-
nentenhersteller interessantes Feature und viele Kommunikationsschnittstellen entwickeln sich
zu (Pseudo-)Standards.
15
2 Grundlagen und Ausgangssituation
Da im weiteren Verlauf dieser Arbeit detailiert auf die Entwicklung mit dem Framework ROS
eingegangen wird, sind in Tabelle 2.4 die wichtigsten Mechanismen und Konzepte von ROS
zusammengefasst.
2.3.3 Weitere Frameworks und Bewertung von komponentenbasierter
Entwicklung
Zusätzlich zu den bereits beschriebenen Frameworks ist das OpenRTM (Ando, Suehiro et al.
2005), das in Eigenschaften und Implementationen mit RTT vergleichbar ist, in Japan sehr ver-
breitet. Ein alternativ zu ROS genutztes Framework ist das Yarp Framework (Metta, Fitzpatrick
et al. 2006), das auch auf dem Publish-Subscribe-Prinzip aufbaut. Eher selten im Einsatz befind-
liche Frameworks zur Umsetzung des komponentenbasierten Paradigmas sind OPROS (Jang,
Lee et al. 2010) und Mira (Einhorn, Langner et al. 2012). Detaillierte Benchmarks und Vergleiche
der verschiedenen Frameworks bzgl. der Performanz und Funktionalität finden sich in (Shakhi-
mardanov und Prassler 2007).
Bei der Verwendung der beschriebenen Frameworks ist eine Entscheidung für ein Framework sehr
früh im Entwicklungsprozess notwendig, da eine Integration von Komponenten über Framework-
Grenzen hinweg nicht einfach umsetzbar ist. Dies ist vor allem kritisch, da die Frameworks un-
terschiedliche Funktionalitäten bereitstellen, wie beispielsweise die Unterstützung von Echtzeit-
Verhalten.
Zudem ist die in der Definition einer Softwarekomponente nach (Szyperski, Bosch et al. 1999)
beschriebene schriftliche Festlegung von Schnittstellendefinitionen und Abhängigkeiten unter-
schiedlich streng umgesetzt. Oftmals findet die Definition innerhalb des Quellcodes statt, was
bei Frameworks, die viele Sprachen unterstützen, den Entwicklern viele Freiheiten lässt. Beispiels-
weise ist die Umsetzung der Schnittstellen von ROS-Komponenten zur Zeit sehr unterschiedlich.
Bei diesen Frameworks findet man daher trotz komponentenbasiertem Ansatz einen geringeren
Wiederverwendungsgrad.
In der Regel erfordert die Umsetzung von Software in komponentenbasierten Frameworks im-
mer noch sehr viel softwaretechnische Expertise, da die zur Verfügung gestellten Tools allen
Nutzern sehr viele Funktionalitäten bieten. Zudem ist bei der Entwicklung detailliertes Wissen
über die in den Komponentenframeworks umgesetzten Mechanismen notwendig. Eine Abgren-
zung der Werkzeuge nach Nutzungsart, beispielsweise für die Anwendungsentwicklung, ist in
den Frameworks oft nicht vorgesehen.
Komponentenbasierte Frameworks stellen damit für die Entwicklung von mobilen Manipulatoren
einen Fortschritt dar. Die hohe Komplexität, geringe Wiederverwendung und die nicht vorhan-
dene Trennung von Entwicklungsaspekten sind bei der Softwareentwicklung jedoch weiterhin
problematisch.
16
2.3 Komponentenbasierte Entwicklung in der Robotik
Tabelle 2.4: Überblick über die Mechanismen des Komponentenframeworks ROS
ROS Mechanismus Kurzerklärung
Package Die Implementierungen der Komponenten wird in ROS mit Hilfe
von Packages organisiert. Diese enthalten Metainformationen zu
Abhängigkeiten und Anweisungen zum Kompilieren des
Quellcodes.
Node Softwarekomponenten werden in ROS als “Nodes” bezeichnet.
Diese laufen auf dem Zielsystem als einzelne Prozesse oder
können in einem Prozess als sogenannte “Nodelets”
zusammengefasst werden.
Topic / Subscriber / Publisher Die einzelnen ROS-Nodes können über einen asynchronen
Publish-Subscribe-Mechanismus miteinander kommunizieren. Der
Kanal, über den die Kommunikation passiert, wird in ROS als
“Topic” bezeichnet. Die Implementationen der jeweiligen Server-
und Clientschnittstellen werden als “Publisher” und “Subscriber”
bezeichnet.
Service / ServiceServer /
ServiceClient
Alternativ steht in ROS ein Mechanismus zur synchronen
Kommunikation zur Verfügung, der “Service”. Auch hier werden
entsprechende Schnittstellenimplementierungen benötigt.
Action / ActionServer /
ActionClient
Als dritte Kommunikationsalternative stehen Actions zur
Verfügung. ActionServer und ActionClient stellen jeweils eine
Kommunikationszustandsmaschine dar, die asynchrone
Kommunikation verwendet, jedoch Mechanismen zur
Synchronisation von Nodes bietet.
Parameterserver
/dynamic_reconfigure
Parameter von Komponenten werden in ROS zentral von einem
“Parameterserver” verwaltet. Diese werden beim Start der
Komponente eingelesen. Eine Möglichkeit, Parameter zur Laufzeit
zu modifizieren, bietet der Mechanismus “dynamic_reconfigure”.
SMACH Um komplexe Abläufe einer ROS Anwendung umzusetzen,
können Zustandsmaschinen verwendet werden. Eine Bibliothek,
die es einfach ermöglicht, solche Zustandsmaschinen zu erstellen
und mit dem restlichen ROS-System zu verknüpfen, ist
“SMACH”.
roslaunch Um ROS-Nodes zu konfigurieren und auf einem Zielsystem zu
starten, kann das Tool “roslaunch” eingesetzt werden. Die
Systemkonfigurationen werden dabei in sogenannten
“Launch-Files” in Form von XML-Anweisungen gespeichert.
17
2 Grundlagen und Ausgangssituation
2.4 Modellbasierte Softwareentwicklung
Bei der modellbasierten Softwareentwicklung werden formalisierte Modelle benutzt, um verschie-
dene Abstraktionsebenen bei der Erstellung von Softwaresystemen zu schaffen. Es haben sich
für diesen Ansatz diverse synonyme Begriffe herausgebildet, wie modellgetriebene Softwareent-
wicklung, Model-Driven Software Development oder Model-Driven Engineering. Im Folgenden
wird der Begriff modellbasierte Softwareentwicklung verwendet. In (Kent 2002) ist modellba-
sierte Entwicklung als ein Ansatz definiert, der Modelle in Modellierungssprachen beschreibt,
die für verschiedene Aspekte und Ebenen eines Softwaresystems entworfen werden, den Domain
Specific Languages (DSL’s). Durch Anwendung von Modelltransformationen können Entwick-
lungsschritte automatisiert werden. Dies ist zwischen den Modellebenen möglich, jedoch auch
bis hin zu ausführbarem Code. Der wichtigste Aspekt von modellbasierter Entwicklung ist also
die Formalisierung der Modellbeschreibung.
Das Bilden von Modellebenen in Softwaresystemen durch modellbasierte Entwicklung ermöglicht,
Komplexität zu kapseln, Entwicklerrollen klar zu trennen, Architekturen durchzusetzen und Wie-
derverwendung durch standardisierte Modelle zu vereinfachen. Die modellbasierte Entwicklung
hat sich daher in vielen Anwendungsbereichen, wie der Luftfahrt- oder der Automobilindustrie,
zu einem gängigen Vorgehensmodell entwickelt [Müller2009].
Von der Object Management Group (OMG), einem Konsortium aus Softwareherstellern und
-anwendern, ist eine konkrete Spezifikation zur Umsetzung von modellbasierter Entwicklung
definiert worden, die Model-driven Architecture (MDA). Dabei werden in MDA, wie in (Kleppe,
Warmer et al. 2003) beschrieben, vier verschiedene Modellierungsebenen definiert:
• Auf der untersten M0-Ebene findet sich die konkrete Implementation eines Softwaresys-
temaspektes in einer ausführ- bzw. kombinierbaren Programmiersprache. Ein Beispiel für
diese Ebene ist eine Treiberbibliothek eines Hardwaregerätes.
• Auf der Modellebene, derM1-Ebene wird der Softwareaspekt mittels einer Domain Specific
Language modellartig beschrieben. Je nach DSL kann dies sehr abstrakt oder schon sehr
nahe an der späteren konkreten Implementation sein. Auch kann die Modellierung auf
mehrere Modelle aufgeteilt werden. Ein Beispiel ist die Modellierung der Datentypen einer
Klasse von Hardwaretreibern.
• In der Meta-Modellebene, M2-Ebene werden die für die M1-Ebene erforderlichen DSL’s
spezifiziert. Hier werden Modelle mit den Mechanismen gebildet, die zur Modellierung auf
der M1-Ebene eingesetzt werden können. Sehr verbreitet ist das Unified Modeling Langua-
ge (UML) Meta-Modell, das zur Beschreibung von Objekt-orientierten Softwareprojekten
eingesetzt werden kann. Ein Beispiel sind die zur Beschreibung der Treiberdatentypen
zur Verfügung stehenden Mechanismen, wie der Aufbau von komplexen Datentypen aus
Grundtypen.
18
2.4 Modellbasierte Softwareentwicklung
• Die Meta-Meta-Modellebene,M3-Ebene enthält sehr abstrakte Modellbeschreibungen für
die Definition von DSL’s auf der M2-Ebene. Die M3-Ebene wird meistens von der modell-
basierten Entwicklungstoolchain bereitgestellt und wurde in Form der Meta Object Facility
(MOF) von der OMG standardisiert. Eine Implementation der MOF ist das ECore M3 Mo-
dell in der Eclipse Modeling Toolchain. Bei diesem werden Mechanismen wie “Klassen”
und “Attribute” definiert, die schließlich in ECore basierten DSL’s instanziiert werden.
Diese Mechanismen können dann beispielsweise bei der Definition des Meta-Modells zur
Beschreibung von Datenübertragungsdatentypen verwendet werden.
Die beschriebenen Modellebenen der MDA können in Form einer Pyramide mit zur Spitze auf-
steigender Abstraktion dargestellt werden. Zwischen den Ebenen spricht man dabei nicht von
Vererbung, sondern von Konformität. Eine Darstellung der Pyramide findet sich in Abbildung 2.8.
Abbildung 2.8: Visualisierung der OMG-Modellpyramide
Um den Austausch von Modellen aller Ebenen untereinander zu gewährleisten, müssen sie in
Form eines Dateiformats abgespeichert werden. Diese Abspeicherung wird in der modellbasierten
Entwicklung Persistierung des Modells genannt. Von der OMG wurde zur Persistierung das XML
Metadata Interchange Format (XMI) spezifiziert, ein auf der Extensible Markup Language XML
aufbauendes Format zum Speichern von Modellen aller Ebenen der MDA.
19
2 Grundlagen und Ausgangssituation
Transformationen zwischen den Modellen und Ebenen können mit sogenannten Transformati-
onsregeln durchgeführt werden. Diese sind Funktionen, die als Eingang ein bestimmtes Modell
benötigen und ein oder mehrere Modellelemente in einer Ziel-DSL generieren. Es gibt für diese
Transformationsregeln mehrere Umsetzungssprachen, die sich in der Anwendung durchgesetzt
haben, zum Beispiel die ATL Transformation Language (ATL, rekursives Akronym) (Jouault,
Allilaire et al. 2008) oder die Epsilon Transformation Language (ETL) (Kolovos, Paige et al.
2008).
Um die Anwendung von modellbasierter Entwicklung auf eine Domäne zu bewerten, wurde
in (Rios, Bozheva et al. 2006) das “Model-driven Development Maturity Model” als eine Wer-
tungsmetrik eingeführt. Dieses beschreibt die Einführung von modellbasierter Entwicklung in
fünf Stufen, an die bestimmte Eigenschaften der Toolchain sowie deren Anwendung auf die Ent-
wicklungsprozesse gekoppelt sind. Tabelle 2.5 zeigt die verschiedenen Stufen mit ihren jeweiligen
Eigenschaften. MDD steht dabei für Model-Driven Development.
Anhand der Einordnung in die Bewertungsstufen kann ermittelt werden, inwieweit der Einsatz
von modellbasierter Entwicklung in bestimmten Domänen schon fortgeschritten ist. (Hailpern
und Tarr 2006) hat die Adoption von modellbasierter Entwicklung in verschiedenen Domänen
analysiert und kommt zu dem Schluss, dass folgende Probleme im Allgemeinen die Adoption
verhindern können:
• Komplizierte, schwer verständliche DSL’s
• Hohe Abstraktion in der Modellierung und damit Beschränkung der Entwickler
• Umsetzung reiner graphischen Modellierung. Graphische Modellierung kann in bestimmten
Fällen, zum Beispiel bei sich wiederholenden Artefakten, aufwändiger sein als textuelle
Modellierung
• Schlechte Standardisierung der Modellierungstools
Des Weiteren wird in (Hailpern und Tarr 2006) angemerkt, dass bei modellbasierter Entwicklung
die Toolchain einen stärkeren Einfluss auf die Entwicklung hat als bei herkömmlichen Ansätzen.
Beispielsweise können bei nicht-modellbasierter Entwicklung Programmiereditoren vom Entwick-
ler frei gewählt werden. Modellbasierte Entwicklung hat meist eine geringere Flexibilität bzgl.
der Werkzeuge, daher sind die Ansprüche der Nutzer an eine funktionierende Toolchain auch
höher.
20
2.5 Anwendung von modellbasierter Softwareentwicklung in der Robotik
Tabelle 2.5: Die Bewertungsskala von modellbasierter Entwicklung nach
(Rios, Bozheva et al. 2006)
“Majurity Level” Name Definition
Level 1 Ad-hoc Modelling Praktiken der Modellierung werden nur sporadisch oder
gar nicht genutzt.
Level 2 Manual Modelling Es gibt manuell erstellte Modelle basierend auf der
Implementation und klare Vorgaben zur Umsetzung von
Quellcode.
Level 3 Initial MDD Es gibt eine Toolchain, die es ermöglicht, aus Modellen
automatisiert Code zu generieren. Generierter und
nicht-generierter Code werden separiert. Änderungen im
Code werden wieder in das Modell eingepflegt.
Level 4 Integrated MDD Die Anwendung wird hauptsächlich durch Modellierung
erstellt. Es gibt verschiedene Modellierungssprachen für
unterschiedliche Aspekte. Es ist ein Modell für die
gesamte Domäne definiert, eine standardisierte
Modellierungssprache wird verwendet. Es gibt
modellbasiertes Testen.
Level 5 Ultimate MDD Es werden ausschließlich modellbasierte Verfahren und
DSL’s verwendet, um das Produkt zu entwickeln.
2.5 Anwendung von modellbasierter Softwareentwicklung
in der Robotik
Obwohl in anderen Fachbereichen modellbasierte Entwicklung bereits großflächig eingesetzt wird,
gibt es in der Robotik bisher nur wenige Fälle, in denen über der gesamten Architektur ein
modellbasiertes Framework eingesetzt wird. Das am stärksten verbreitete Framework, welches die
modellbasierten Konzepte umsetzt und mittels einer entsprechenden Toolbox (Corke 2007) für
die Robotik adaptiert, ist Simulink auf Basis von Matlab der Firma Mathworks. Vor allem in der
Regelungstechnik wird Simulink oft genutzt, so dass auch die regelungstechnischen Aspekte einer
Roboteranwendung mit Simulink umgesetzt werden (siehe Abbildung 2.9). Der von Simulink
generierte Code ist echtzeitfähig und kann für verschiedene eingebettete Systeme optimiert
werden. Ein Nachteil ist, dass das Meta-Model (M2) von Simulink nicht offen dokumentiert ist,
so dass keine weiteren Werkzeuge für die Arbeit mit Simulinkmodellen umsetzbar sind und man
stattdessen auf die verfügbaren Werkzeuge der Firma Mathworks angewiesen ist. Dies ist durch
die sehr hohen Anschaffungspreise der Werkzeugerweiterungen für kleinere Unternehmen meist
nicht wirtschaftlich. Neue oder abweichende Entwicklungsprozesse können ebenfalls schlecht
integriert werden.
21
2 Grundlagen und Ausgangssituation
Außerdem ist mittels Simulink generierter Quellcode nicht komponentenbasiert. Vielmehr werden
alle Teile eines Simulinkmodells in einen monolithischen Quellcode übersetzt. Dies macht die
Integration mit bestehenden Softwaremodulen schwierig. Zudem ist eine verteilte Nutzung nicht
möglich.
Abbildung 2.9: Umsetzung eines Reglers für synchrone mobile Manipulation in Simulink
Unabhängig von den in Kapitel 2.4 vorgestellten, bestehenden komponentenbasierten Frame-
works wurden weitere modellbasierte Werkzeuge für die Robotik entwickelt. Aus dem For-
schungsprojekt Proteus ist das Meta-Modell (M2) RobotML für Roboteranwendungen entstan-
den (Dhouib, Kchir et al. 2012). Dieses erweitert das bestehende Meta-Modell von UML um
Primitive, die für die Robotik notwendig sind. Somit entsteht eine UML-Erweiterung. Durch
den Einsatz von UML als Basis kann als Werkzeug ein bestehender UML-Editor, in diesem Fall
Eclipse Papyrus, genutzt und modifiziert werden. Die Modelle der Roboterapplikation sind voll-
ständig unabhängig vom später genutzten komponentenbasierten Framework. Dies verschiebt die
Entscheidung bzgl. des Frameworks auf einen späteren Zeitpunkt des Entwicklungsprozesses. Al-
lerdings wird die automatische Codegenerierung in ein Framework erschwert, da nur abstrakte,
für alle Frameworks identische Funktionalitäten modelliert werden können. Dies hat im Falle von
Proteus zur Folge, dass die für die Codegenerierung genutzten Templates sehr viele implizite
Annahmen beinhalten, die den Entwicklungsprozess intransparent machen (Hailpern und Tarr
2006).
Ein weiteres Projekt zur Erstellung einer modellbasierten Entwicklungstoolchain für die Robotik
ist das SmartSoft-Projekt (Schlegel und Worz 1999), das wie RobotML eine Erweiterung von
UML implementiert. Jedoch wurde beim SmartSoft-Projekt ein eigenes Entwicklungswerkzeug
umgesetzt, das für die Entwicklung von Robotersystemen optimiert ist. SmartSoft hat dabei den
22
2.5 Anwendung von modellbasierter Softwareentwicklung in der Robotik
Fokus auf ein eigenes, wenig verbreitetes, auf CORBA basierendes Kommunikationsframework.
Im Fall von SmartSoft können bestehende komponentenbasierte Frameworks nur über zusätzli-
che Gateway-Softwarekomponenten genutzt werden, die Übersetzungscode für die Primitive der
Frameworks umsetzen.
Einen anderen Ansatz setzt das AMARSi Projekt für die Regelung von Beinkinematiken um (Nord-
mann, Tuleu et al. 2013). Die Modellierung erfolgt hier mittels eines eigens entwickelten Meta-
Modells, welches innerhalb der Programmierumgebung “Jetbrains MPS” umgesetzt ist. Nach
der Modellierung werden die Komponenten für das Softwareframework Yarp generiert, das bei-
spielsweise auf dem iCub Roboter genutzt wird. Das Projekt konzentriert sich bisher auf den sehr
speziellen Anwendungsfall des Reglerentwurfs und hat die Unterstützung von weiteren Frame-
works bisher nur angekündigt. Aussagen über die Skalierbarkeit dieses Meta-Modells auf die
gesamten Problemstellungen von mobilen Manipulatoren sind noch nicht dokumentiert.
Das komponentenbasierte Framework OpenRTM hat mit “RTC Builder” und “RT System Edi-
tor” zwei separierte Eclipse-basierte Modellierungstools für verschiedene Entwicklungsaspekte.
Da für diese jedoch keine formalen Meta-Modelle vorhanden sind, handelt es sich hierbei nicht
um einen modellbasierten Ansatz nach der in Kapitel 2.4 genannten Definition und die Vor-
teile bzgl. Wiederverwendbarkeit und Abstraktion sind ebenfalls nur innerhalb des OpenRTM
Frameworks gültig.
Einen Überblick über die Eigenschaften der aktuell entwickelten modellbasierten Roboterframe-
works gibt Tabelle 2.6.
Tabelle 2.6: Überblick über derzeitige modellbasierte Entwicklungsumgebungen für die Robotik
Projekt /
Produkt
Offenes
Meta-Modell
Unterstützung
komponenten-
basierter
Entwicklung
Native
unterstützte
Frameworks
Über ein
Gateway
unterstützte
Frameworks
Simulink nein nein - -
Proteus ja ja Yarp, ROS,
OROCOS
-
SmartSoft ja ja proprietär ROS
AMARSI nein ja Yarp -
In allen beschriebenen Frameworks können bestehende, nicht durch modellbasierte Verfahren
entwickelte, Komponenten nicht wiederverwendet werden. Somit ist ein hoher Aufwand notwen-
dig, um auf modellbasierte Entwicklung umzusteigen, da alle bestehenden Module überarbeitet
werden müssen. Die Akzeptanz der Software außerhalb der Projekte ist daher zur Zeit begrenzt.
Die von (Hailpern und Tarr 2006) ermittelten und in Kapitel 2.4 zusammengefassten Probleme
der Adoption modellbasierter Entwicklung bestehen auch bei den hier vorgestellten Ansätzen für
die Robotik. Alle Frameworks haben einen hohen Abstraktionsgrad bei der Modellierung. Eigen-
23
2 Grundlagen und Ausgangssituation
schaften der verschiedenen Frameworks können nicht durchgängig modelliert werden. Entwickler,
die bereits erfahren im Umgang mit einem komponentenbasierten Framework sind, müssen neue
Konzepte und Mechanismen lernen.
Um die Standardisierung der Modellierungstools und -sprachen in der Robotik voranzutreiben,
muss die Nutzerzahl der modellbasierten Toolchains vergrößert werden. Zudem müssen mehr An-
wendungsfälle, gerade bzgl. komplexer Robotersysteme, wie mobilen Manipulatoren, geschaffen
werden.
2.6 Ableitung von Anforderungen an eine
Entwicklungstoolchain
Die Vorteile von modellbasierter Entwicklung sind in anderen Fachbereichen klar nachgewiesen
(siehe beispielsweise (Walderhaug, Mikalsen et al. 2008), (Hutchinson, Rouncefield et al. 2011)
und (Mohagheghi, Gilani et al. 2013)) und sind besonders für komplexe Softwaresysteme, wie
sie bei mobilen Manipulatoren umgesetzt werden müssen, erstrebenswert, um die Entwicklungs-
kosten zu senken. Jedoch konnten die mit modellbasierter Entwicklung verbundenen Heraus-
forderungen (siehe Kapitel 2.5) von den verfügbaren Ansätzen noch nicht überwunden werden.
Daher ist im Rahmen dieser Arbeit ein Entwicklungswerkzeug entstanden, welches modellbasiert
einen großen Teil des Prozesses zur Erstellung von Softwaresystemen für mobile Manipulatoren
abdeckt. Ansätze, die sich von denen bestehender Toolchains unterscheiden, sollen dabei Anwen-
dung finden. Es sollen nach den Erfahrungen bestehender Projekte folgende Punkte besondere
Beachtung finden.
Allgemeine Features modellbasierter Entwicklung:
• Durch den Einsatz der modellbasierten Toolchain soll der Wiederverwendungsgrad in den
verschiedenen Entwicklungsschritten einer Roboteranwendung gesteigert werden, um den
Aufwand für die Anwendungsentwicklung mit mobilen Manipulatoren zu senken.
• Das erforderliche Wissen für das Partizipieren in der Entwicklung soll vermindert werden,
besonders bzgl. der erforderlichen Wissensbandbreite.
• Durch formalisierte Dokumentation können standardisierte Architekturen und Systeme für
allgemeine Problemstellungen umgesetzt werden.
24
2.6 Ableitung von Anforderungen an eine Entwicklungstoolchain
Nutzbarkeit:
• Das Tool muss verständlich und für die Zielgruppe, d.h. Entwickler von mobilen Roboter-
systemen, einfach zu bedienen sein.
• Wiederverwendung bestehender, nicht mit der Toolchain entwickelter Software muss mög-
lich sein, da es schon eine Vielzahl von offenen Robotikbibliotheken gibt. Der Einstieg in
die modellbasierte Entwicklung soll mit geringem Aufwand möglich sein.
• Verschiedene Entwicklungsarten müssen unterstützt werden, da sie für verschiedene As-
pekte eines Robotersystems Vorteile bieten. Textuelle und graphische Umsetzungen des
Tools sind daher erforderlich.
Offenheit und Flexibilität:
• Eine zu hohe Abstraktion durch die Modelle darf nicht die Flexibilität manueller Imple-
mentation beschränken.
• Die Verwendung unterschiedlicher komponentenbasierter Frameworks muss möglich sein,
um die Vorteile der verschiedenen Frameworks optimal zu nutzen.
• Durch die hohe Entwicklungsgeschwindigkeit in der mobilen Robotik müssen neue Frame-
works in der Zukunft integrierbar sein.
Im Rahmen dieser Arbeit wurde eine Toolchain entwickelt, die die genannten Anforderungen für
die Entwicklung von mobilen Manipulatoren umsetzt.
25

3 Entwicklung komplexer
Softwaresysteme für die mobile
Manipulation
Im vorherigen Kapitel wurde sowohl die Wichtigkeit der Optimierung von Softwareentwicklungs-
prozessen erläutert, als auch ein Überblick über die bisherigen Lösungen in der Robotik und
darüber hinaus gegeben. Im folgenden Kapitel werden grundlegende Konzepte zur Umsetzung
einer modellbasierten Toolchain vorgestellt. Diese sind im Rahmen dieser Arbeit auf die Ent-
wicklung von Softwaresystemen für die mobile Manipulation angewandt und adaptiert worden.
Dabei werden vor allem auch die Erfahrungen und die ermittelten Hemmnisse beim Einsatz von
bestehenden Umsetzungen von Softwareentwicklungsframeworks in der Konzeption berücksich-
tigt.
Nach der Adaption des Konzeptes der modellbasierten Entwicklung für die Robotik werden die
grundsätzlichen Konzepte der Separierung von Belangen und Entwicklerrollen diskutiert sowie
deren Anwendung durch Einsatz von modellbasierten Techniken erarbeitet. Anschließend wird die
Interaktion von Softwaremodellen der mobilen Manipulation mit abstrakten Beschreibungsspra-
chen untersucht. Die durch den Einsatz von modellbasierter Entwicklung entstehenden Möglich-
keiten zu Modelltransformationen zwischen Modellierungs- und Programmiersprachen werden
am Ende dieses Abschnittes auf die mobile Manipulation angewandt.
Es ergibt sich aus der Integration der verschiedenen beschriebenen Konzepte ein Gesamtansatz,
der die Wiederverwendung steigert und das erforderliche technische Wissen der Entwickler für
die Anwendungs- und Systemerstellung bei mobilen Manipulatoren senkt.
3.1 Methoden zur Umsetzung von modellbasierter
Entwicklung
Wie in Kapitel 2.4 beschrieben, bietet das Konzept der modellbasierten Entwicklung die Mög-
lichkeit, die Wiederverwendung zu erhöhen, Softwareengineeringkonzepte und -architekturen
durchzusetzen und Entwicklerrollen zu trennen. Ein Einsatz in der Erstellung von komplexen
Roboteranwendungen ist daher erstrebenswert.
27
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
3.1.1 Modellbasierte Entwicklung nach der Top-down-Methode
Bestehende Ansätze zum Einsatz von modellbasierten Verfahren in der Robotik, die ebenfalls in
Kapitel 2 beschrieben wurden, haben die Konzepte der modellbasierten Entwicklung aus anderen
Domänen direkt übernommen und daher abstrakte Beschreibungsformen, wie UML und SysML,
als Grundlage der Umsetzung der modellbasierten Toolchain verwendet.
In dadurch entstandenen Meta-Modellen (in Abbildung 3.1 auf Layer “M2”), wie beispielsweise
RobotML, werden die Roboterapplikationen modelliert (Layer “M1”) und durch aufwändige
Templates mittels einer Model-to-Text-Transformation (“M2T”) direkt in lauffähigen Quelltext
umgesetzt (Layer “M0”). Dieses Prinzip ist in Abbildung 3.1 anhand der OMG-Modellpyramide
dargestellt. Durch den hohen Abstraktionsgrad in der Beschreibung der Modelle wird diese
Herangehensweise im Folgenden “Modellbasierte Entwicklung nach der Top-down-Methode”
genannt.
Abbildung 3.1: Abstrakte Meta-Modelle für Robotik in der OMG-Modellpyramide
Der Vorteil dieser Herangehensweise ist es, dass schon bestehende Toolchains verwendet werden
können, da die genutzten Meta-Modelle sehr große Ähnlichkeit mit bestehenden Meta-Modellen,
für die bereits Toolchains existieren, haben. Ebenfalls vorteilhaft ist der hohe Abstraktionsgrad
für Softwarearchitekten, die die Anwendung von Beschreibungsmodellen gewöhnt sind. Jedoch
geht bei diesem Ansatz ein entscheidender Nutzen von modellbasierter Entwicklung, die for-
male Beschreibung von Softwareprinzipien verloren, da die für das jeweils eingesetzte Roboter-
framework spezifischen Mechanismen nur implizit in den Templates enthalten sind. Daher sind
Transformationen zwischen den Frameworks sowie die Umsetzung bestimmter frameworkspezifi-
scher Prinzipien nur schwer möglich. Zudem ist durch den hohen impliziten Informationszuwachs
bei der Transformation eine Rücktransformation aus dem Code in das Modell kaum möglich.
Durch den Unterschied in der Beschreibung des Modells und der Implementierung ist zudem
die Verwendung von bestehenden, nicht durch modellbasierte Verfahren entwickelte Software,
28
3.1 Methoden zur Umsetzung von modellbasierter Entwicklung
schwer möglich. Zudem müssen die Entwickler ihre bestehenden Konzepte verlassen und die
Modellierung mit der Toolchain erlernen.
3.1.2 Modellbasierte Entwicklung nach der Bottom-up-Methode
Aufgrund der beschriebenen Nachteile der Top-down-Methode wird in dieser Arbeit ein anderer
Ansatz zur Einführung modellbasierter Entwicklung in der Robotik umgesetzt: die Entwick-
lung von Meta-Modellen nach der Bottom-up-Methodik. Statt der ausschließlichen Entwicklung
von abstrakten Meta-Modellen werden für das entsprechende Zielsystem frameworknahe Meta-
Modelle entwickelt. Während der Generierung des ausführbaren Quellcodes können die Elemen-
te des Meta-Modells direkt und mit Vermeidung impliziter Annahmen in der Codegenerierung
umgewandelt werden. Die Transformation von oder in andere abstraktere Meta-Modelle wird
durch eine Model-to-Model (M2M)-Transformation beschrieben. Die Transformationen sind da-
her immer formal definiert. Der modellbasierte Ansatz mit frameworknahen Meta-Modellen ist
in Abbildung 3.2 anhand der OMG-Modellpyramide dargestellt.
Abbildung 3.2: Frameworknahe Meta-Modelle für die Robotik in der OMG-Modellpyramide
Trotz der zusätzlichen frameworknahen Meta-Modelle kann durch die M2M-Transformation ein
hoher Abstraktionsgrad bei der Systembeschreibung erreicht werden. Dieser wird in Abschnitt
3.4 konkreter diskutiert. Zusätzlich wird durch die direkte Beschreibung der Mechanismen die
Rücktransformation von Code (M0 Ebene) in das Modell (M1), d.h. die Umkehr der M2T-
Transformation, möglich. Diese auf die Rücktransformation aus der M0 Ebene bezogene Tech-
nik wird bei modellbasierter Entwicklung als Roundtripping bezeichnet. Zudem können auch
bestehende Komponenten, die nicht aus der modellbasierten Toolchain generiert worden sind,
wiederverwendet werden. Für Entwickler fällt die Nutzung der modellbasierten Verfahren leicht,
29
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
da die für sie gewohnten Konzepte des jeweiligen Komponentensystems direkt in den Modellen
verwendbar bleiben. Der vorhandene Informationsverlust oder -gewinn sowie eventuelle Annah-
men bei der Transformation zwischen den Modellierungssprachen sind nun explizit in den M2M-
Beschreibungen enthalten. Jedoch ist im Vergleich zu den bestehenden Ansätzen, die alle die
Top-down-Methode umsetzen, der Entwicklungsaufwand der Modelle und der Entwicklungsum-
gebung weit höher. Da dieser Entwicklungsaufwand allerdings nur einmalig für jedes Framework
entsteht und die Anzahl der Frameworks in der Robotik sehr übersichtlich ist, ist der höhere
Aufwand vernachlässigbar.
3.1.3 Vergleich der Umsetzungsmethoden
In Form einer Gegenüberstellung der beiden vorgestellten Herangehensweisen bei der Entwicklung
von modellbasierten Verfahren für die Robotik nach der Top-down- oder Bottom-up-Methodik
sind die Vor- und Nachteile in Tabelle 3.1 zusammengefasst.
Tabelle 3.1: Vergleich der Ansätze zur Entwicklung einer modellbasierten Toolchain
Top-down-Methodik Bottom-Up-Methodik
Vorteile Nachteile Vorteile Nachteile
Hohe Abstraktion und
Portabilität
Implizite Annahmen in
der M2T
Transformation
Hohe Abstraktion
immer noch möglich
Höherer
Entwicklungsaufwand
der Toolchain
Kein Roundtripping Roundtripping
möglich
Aufwändigere
Modellierung
Neue Konzepte für die
Entwickler
Wiederverwendung
existierender
Komponenten möglich
Keine
Wiederverwendung
bestehender
Komponenten
Annahmen sind in den
Modellen formalisiert
Entwickler benutzen
bekannte Konzepte
Da die Vorteile des Ansatzes nach der Bottom-up-Methodik für die Entwicklungsprozesse in der
Robotik sehr relevant sind und sich die Nachteile der Top-down-Methodik in den existierenden
Umsetzungen bereits gezeigt haben (siehe Kapitel 2.5), wurde die Umsetzung von framework-
nahen Modellierungsverfahren nach der Bottom-up-Methodik in dieser Arbeit gewählt.
30
3.2 Separierung der Entwicklerbelange
3.2 Separierung der Entwicklerbelange
Softwarekomponenten besitzen im Allgemeinen funktionale und nicht-funktionale Anforderun-
gen, die vom Entwickler umgesetzt werden müssen. Diese Anforderungen können grundsätzlich
während der Entwicklung getrennt werden, da sie auch für den Entwickler bei der Umsetzung
von Komponenten unterschiedliche Belange darstellen. Diese Belange wurden schon in (Reade
1989) als sogenannte “developer concerns” bezeichnet. Für die Entwicklung von Softwarekompo-
nenten für mobile Manipulation können, basierend auf den eingesetzten komponentenbasierten
Systemen, folgende Hauptbelange unterschieden werden (siehe Abbildung 3.3):
• Konfiguration: Für die Parametrierung der Komponente ist in der Regel ein Funktio-
nalitätsteil notwendig, der im einfachsten Fall die Parameter aus einer Datei einliest. In
Komponentenframeworks, die in der Robotik eingesetzt werden, stehen in der Regel erwei-
terte Konfigurationsmechanismen zur Verfügung, für die eine entsprechende Funktionalität
innerhalb der Komponente umgesetzt werden muss.
• Koordination: Innerhalb einer Komponente gibt es einen Teil, der für die Regelung des
Verhaltens der Software verantwortlich ist. Dies kann bedeuten, dass eine Funktion zyklisch
aufgerufen wird oder dass bestimmte Eingangsdaten zu einem bestimmten Zeitpunkt im
Programmfluss gelesen werden. In der Wechselwirkung mit anderen Komponenten kann
die Koordinationsfunktionalität einer Komponente auch das Verhalten von anderen Kom-
ponenten beeinflussen.
• Kommunikation: Die einzelnen Komponentenframeworks bieten entsprechende Kommu-
nikationsschnittstellen an, die von den Komponenten genutzt werden können, um mit
anderen Softwarekomponenten Daten auszutauschen. Die Definition sowie das Einlesen
und Auslesen von Daten aus diesen Kommunikationsmechanismen muss jedoch in der
Regel innerhalb der Komponente umgesetzt werden.
• Komposition: Im Zusammenspiel von Komponenten muss definiert werden, welche Kom-
ponentenschnittstellen auf welche Weise miteinander verbunden sind. Dieser deklarative
Teil kann entweder außerhalb oder innerhalb einer Komponente passieren.
• Kalkulation: Der eigentliche funktionale Teil, beispielsweise ein Treiber oder Algorithmus,
führt innerhalb der Komponente die gewünschten Kalkulationen aus. Dieser Teil kann
generell vollständig unabhängig vom benutzten Softwareframework umgesetzt werden.
31
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
Bei Softwarekomponenten, die ähnliche Funktionalitäten umsetzen, gleichen sich die Umset-
zung bestimmter Belange stark. Um bereits entwickelten Code in diesem Fall leicht von einer
Komponente zur anderen zu übertragen und damit wiederzuverwenden, muss er vom Rest der
Software extrahierbar sein. Die “developer concerns” sollten also so weit wie möglich von einan-
der getrennt umgesetzt werden. Dieses Prinzip ist in der Softwareentwicklung als “Separation of
Concerns”, im Deutschen als Separierung der Belange, bekannt. Auf die beschriebenen Belange
eines Roboterkomponentenentwicklers bezogen, heißt das beispielsweise, dass bei einer guten
Separierung die Implementation der Konfiguration eines vorhandenen Laserscannertreibers bei
der Umsetzung eines neuen Laserscannertreibers direkt wiederverwendet werden kann (siehe Ab-
bildung 3.3). Der Vorteil der in diesem Fall manuellen Separierung bei der Roboterentwicklung
wurde in (Bubeck, Weisshardt et al. 2012) gezeigt.
Abbildung 3.3: Fünf Belange einer Software-Komponente bei der Wiederverwendung. Nur
bestimmte Belange müssen modifiziert werden (orange)
Zur praktischen Umsetzung der Separierung von Entwicklerbelangen auf der Programmierebene
wurden verschiedene Konzepte und Programmiersprachen entwickelt, die von den Softwareent-
wicklern eingesetzt werden können. Eine Möglichkeit ist dabei, die Auftrennung der Belange
direkt in die Programmiersprache einzubauen. Dieses Prinzip der aspektorientierten Program-
miersprachen, das beispielsweise in AspectC++ (Spinczyk, Gal et al. 2002) zum Einsatz kommt,
setzt die Separierung der Belange auf solche Weise um. Keines der existierenden Roboterframe-
works unterstützt zur Zeit aspektorientierte Sprachen. Zudem müssen die Entwickler bei diesem
Ansatz eine neue Programmiersprache zur Entwicklung von Roboteranwendungen lernen, was
die Entwicklung von mobilen Manipulatoren noch mehr verteuern und spezialisieren würde.
Ein weiterer Ansatz der Umsetzung von “Separation of Concerns” ist die explizite Modellierung
der Belange in einem modellbasierten Entwicklungsprozess. Die Belange werden schon separiert
im Modell definiert, wenn das Meta-Modell so entwickelt wird, dass die Modellierungsprimitive
einem jeweiligen Belang zugeordnet werden können. Die M2T-Transformation kann dann auf
eine Weise umgesetzt werden, dass die Belange voneinander getrennt im Programmcode stehen.
Eine solche Integration des “Separation of Concerns”-Prinzip wird in dieser Arbeit umgesetzt.
32
3.3 Separierung der Entwicklerrollen
3.3 Separierung der Entwicklerrollen
Vergleichbar zu allgemeinen Softwareentwicklungsprozessen in anderen Domänen durchläuft
auch die Entwicklung von Robotersystemen einen Prozess mit verschiedenen Entwicklungspha-
sen. Angelehnt an die Norm ISO/IEC 12207, die diesen Prozess standardisiert, können die einzel-
nen Phasen auf die Roboterentwicklung angewandt werden. In der Anfangsphase der Enwicklung
werden die funktionalen und nicht-funktionalen Anforderungen gesammelt und dokumentiert.
Abhängig davon wird im Anschluss ein “high level design” durchgeführt, d.h. die Strukturierung
des Systems in Subsysteme und die Hardware- und Softwareabhängigkeiten werden spezifiziert.
Diese beiden ersten Schritte werden meist von Projektmanagern und Softwarearchitekten durch-
geführt. Die in der Softwareentwicklung üblichen Werkzeuge, wie SysML/UML Editoren, können
auch in der Robotik angewandt werden.
Nach der Erstellung der Systemarchitektur definiert ISO/IEC 12207 die Phasen “Module design”,
“Coding”, “Integration Testing” und “System Testing”. Diese Phasen müssen im Rahmen der
Systementwicklung für die Robotik genauer spezifiziert werden.
In der Moduldesignphase werden die einzelnen Komponenten des Robotersystems spezifiziert
und anschließend in der Coding-Phase entwickelt. Diese beiden Phasen werden bei größeren
Robotersystemen meist von Domänen-Experten durchgeführt, deren Hauptfokus in der Ent-
wicklung von Algorithmen und nicht im Softwareengineering liegt. Beispielsweise werden hier
von Regelungstechnikexperten die Motorregler eines Manipulators umgesetzt. Softwareentwick-
lungsspezifische Problemstellungen sollten in dieser Phase demnach minimiert werden. Parallel
zu Modulen, die Funktionalitäten im Robotersystem bereit stellen, werden auch Module für die
Koordination des Systems erstellt. Die Entwickler dieser Module haben meistens einen Überblick
über die bereitgestellten Funktionalitäten sowie über die Zielapplikation.
Basierend auf der erstellten Systemarchitektur und den anschließend entwickelten Komponen-
ten kann im Rahmen der Integrations- und Systemtestphasen eine Systemkonfiguration erstellt
werden, die eine Komposition der Komponenten mit entsprechenden Verbindungen und Kompo-
nentenparametrierungen enthält. Während diese Phasen in ISO/IEC 12207 nur als Testphasen
beschrieben sind, entsteht bei Roboteranwendungen in diesen Phasen noch erheblicher Entwick-
lungsaufwand, oft mit Rückschleifen zur Modulentwicklung. Die Entwickler in dieser Phase sind
oft erfahrene Integrationsexperten, die fundiertes Wissen über Systemarchitekturen haben, und
technisches Verständnis für die Einzelkomponenten besitzen. In dieser Arbeit werden die letzten
beiden Phasen als “System deployment” bezeichnet. Die Phasen von “Module design + Coding”
aus der ISO/IEC 12207 werden als “Capability development” bezeichnet.
33
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
Abbildung 3.4: Einordnung der in dieser Arbeit definierten Entwicklerrollen in die Prozessphasen
der ISO/IEC 12207
In Abbildung 3.4 ist der gesamte beschriebene Entwicklungsprozess dargestellt. Die Phasen wer-
den nicht zwingend sequentiell durchgeführt, sondern oftmals parallel in mehreren Schleifen.
Die im vorherigen Abschnitt definierten Belange eines Entwicklers können auf die Entwicklungs-
phasen zugeordnet werden. In der “Capability development” Phase müssen die Funktionalitäten
Kommunikation, Komponenten-interne Koordination sowie die Kalkulation umgesetzt werden.
Die Konfigurationsmöglichkeiten müssen definiert werden, können aber noch mit Standardwerten
versehen werden. Bei der Erstellung von Koordinatorkomponenten fällt der Hauptfokus auf die
Erstellung der Kommunikationsmechanismen und die Systemkoordination. In der anschließenden
“System deployment” Phase liegt der Hauptfokus auf der Komposition und der Konfiguration
der Komponenten auf den Anwendungsfall. Die Zuordnung der Belange auf die verschiedenen
Entwicklungsphasen ist in Abbildung 3.5 dargestellt.
Abbildung 3.5: Verschiedene Entwicklerrollen und die Zuordnung der Entwicklerbelange
Zusätzlich zum Separieren der Belange des Entwicklers können die Unterschiede der Entwick-
ler bezüglich Wissen und Erfahrung in der Umsetzung der Entwicklungstoolchain manifestiert
werden (Bubeck, Weisshardt et al. 2012). Die Nutzerrollen sollten dabei klar und explizit von
einander getrennt werden. Weiterhin werden nicht bei jeder Roboterentwicklung alle Entwick-
lungsphasen durchschritten, wenn aus anderen Entwicklungen Anwendungsteile wiederverwendet
werden können. In industriellen Anwendungen sind die Funktionalitätskomponenten meist vor-
34
3.3 Separierung der Entwicklerrollen
handen und die Entwicklung von Koordinationskomponenten sowie die “System deployment”
Phase steht im Fokus. Die wissenschaftliche Roboterentwicklung konzentriert sich meist auf
die Entwicklung und Analyse von Teilsystemen oder -komponenten unabhängig von der Zielan-
wendung. Beide Anwendungsfälle müssen von der Toolchain durch eine klare Separierung der
Entwicklerrollen unterstützt werden.
Der Einsatz von modellbasierten Verfahren bei der Toolchain-Entwicklung ermöglicht die ex-
plizite Separierung der Phasen in der Modellierungsebene (“M1” Layer). Wenn in den Meta-
Modellen die einzelnen Entwicklerbelange sowie Abstraktionen formal getrennt werden, können
unterschiedliche Modelleditoren für die einzelnen Nutzergruppen erstellt werden. In der OMG-
Pyramide in Abbildung 3.6 ist beispielhaft die Auftrennung der Entwicklungsphasen- und belange
in den verschiedenen Modellierungsebenen dargestellt.
Abbildung 3.6: Anwendung der Konzepte Separierung der Entwicklerbelange und Entwicklerrol-
len auf die modellbasierte Entwicklung
35
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
3.4 Integration mit Meta-Modellen für das High Level
Design
Im vorherigen Abschnitt wurde vor allem auf die Entwicklungsphasen nach der “High-Level-
Design” Phase aus der ISO/IEC 12207 eingegangen. Für einen vollständigen Entwicklungsweg,
auch bei komplexen Systemen, ist jedoch eine Integration dieser “High-Level-Design” Phase
in die restlichen Phasen notwendig. Bei frameworknahen, d.h. nach der Bottom-up-Methode
umgesetzten, modellbasierten Toolchains ist das High-Level-Design nicht direkt möglich. Die
Integration mit anderen, schon bestehenden High-Level-Toolchains und deren Meta-Modellen
ist daher notwendig. Die dort modellierten Belange werden dann in den nachgelagerten Prozess-
phasen innerhalb der frameworknahen Toolchain weiter konkretisiert. Im Folgenden sollen nun
Meta-Modelle für die abstrakte Modellierung von Applikationen aus drei Entwicklergemeinschaf-
ten – der Robotik, dem Systemengineering und der Webentwicklungswelt – vorgestellt werden.
3.4.1 BCM als abstraktes Meta-Modell
Ein Meta-Modell für die abstrakte High-Level-Modellierung, das mit dem Konzept der Sepa-
rierung der Entwicklerbelange entworfen wurde, ist das BRICS Component Model (BCM) aus
dem EU-Projekt Best Practice in Robotics (BRICS) . Es ist spezifisch für die Anwendung in Ro-
boterentwicklungsprozessen entwickelt worden und stellt für die Definition der Kommunikation
von einzelnen Komponenten entsprechende Kommunikations-“Ports” zur Verfügung. Die Ports
können mit den Eigenschaften “In” und “Out” belegt werden, um die Schnittstellenrichtung zu
definieren. Des Weiteren bietet das BCM die Möglichkeit, Verbindungen zwischen Komponen-
ten herzustellen. Diese Portverbindungen können Schnittstellendatentypen und Eigenschaften
wie Synchronisation zugewiesen werden.
Das BCM bietet damit zwar Unterstützung für die spätere Modulentwicklungsphase und die
Systementwicklungsphase, allerdings werden diese nicht systematisch im Modell getrennt. Bei-
spielsweise hat die Synchronizität einer Kommunikation Einfluss auf die interne Strukturierung
einer Komponente. Im BCM werden diese jedoch mit systemspezifischen Eigenschaften gekop-
pelt (Verbindungsweg). Durch die direkte Beschreibung der fünf Belange einer Komponente
kann das BCM generell sehr gut für die Beschreibung von Komponenten verwendet werden und
dabei als abstrakte Beschreibung von Belangen der “Capability development” Phase dienen.
3.4.2 SysML als abstraktes Meta-Modell
Im Gegensatz zum BCM wurde die System Modeling Language (SysML) nicht direkt für Ro-
botersysteme entworfen, sondern für Softwaresysteme im Allgemeinen von der OMG auf Basis
von UML entwickelt. Die große Bandbreite an Aspekten aus der Softwareentwicklung macht sie
36
3.4 Integration mit Meta-Modellen für das High Level Design
jedoch auch auf den Entwicklungsprozess von mobilen Manipulatoren übertragbar. Software-
systeme werden in SysML in sogenannten Blockdiagrammen beschrieben. Die einzelnen Blöcke
können dabei Schnittstellen haben, die ähnlich wie beim BCM, als “Ports” definiert werden. Den
Ports können Datentypen sowie die Art der Synchronisation (synchron, asynchron) zugewiesen
werden. Die Komposition der Blöcke wird in einem separaten Modelltyp, dem “internal block
diagram” vorgenommen. Damit kann der Kompositionsschritt im Modell klar getrennt werden.
Zusätzlich zu den Definitionen der Blöcke und Ports kann auch das Verhalten von Komponen-
ten und Systemen in SysML beschrieben werden. Hierzu werden die “state machine diagrams”
verwendet, die ebenfalls separat von den restlichen Meta-Modellen definiert werden können.
Der modulare Aufbau des Meta-Modells sowie das Abdecken aller wichtigen Belange für Soft-
warearchitekturen von mobilen Manipulatoren macht das SysML Meta-Modell zu einem geeigne-
ten Kandidaten für die abstrakte Modellierung von Robotersystemen. Zudem sind mit Papyrus,
Topcased und Enterprise Architect schon sehr weit entwickelte Tools für SysML verfügbar (siehe
Abbildung 3.7).
Abbildung 3.7: SysML Editor Papyrus
3.4.3 SCXML als abstraktes Meta-Modell
In der Entwicklung von Internetanwendungen ist der Komplexitätsgrad ebenfalls in den letzten
Jahren stark gestiegen, weswegen auch im World Wide Web Konsortium (W3C) verschiedene
Softwareentwicklungsmodelle diskutiert und standardisiert wurden. Neben der Web Application
Description Language (WADL) und Web Services Description Language (WSDL), die für die Be-
schreibung von Webservice-Strukturen vorgesehen sind, wurde die State Chart XML (SCXML)
Sprache für das Beschreiben vom Verhalten von Webapplikationen definiert. SCXML kann durch
seine abstrakte und separate Definition auch auf Robotersysteme übertragen werden und stellt
damit eine Alternative zu SysML zur Definition von Koordinationskomponenten dar. Die Archi-
tektursprachen WADL und WSDL sind jedoch zu spezifisch auf Service Oriented Architecutures
37
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
(SOA) zugeschnitten, um auf die vorhandenen Komponentensysteme in der Robotik übertragbar
zu sein.
3.4.4 Integration der Meta-Modelle in den
Roboterentwicklungsprozess
Die vorgestellten Meta-Sprachen lassen sich auf unterschiedliche Weise in den in Kapitel 3.3
definierten Roboterentwicklungsprozess integrieren. In Abbildung 3.8 ist der Zusammenhang der
einzelnen Meta-Modelle mit den Entwicklungsphasen nochmals dargestellt.
Abbildung 3.8: Zusammenhang von abstrakten Meta-Modellen mit den verschiedenen Entwick-
lungsprozessphasen
Der Einsatz von Verfahren aus der modellbasierten Entwicklung garantiert eine hohe Flexibilität
im Einsatz der entsprechenden abstrakten Sprachen, da durch M2M-Transformationen eine di-
rekte Umwandlung möglich ist. Zur Wiederverwendung von Komponenten in Robotersystemen
ist zusätzlich die Rückumwandlung von konkreten Modellen und letztendlich deren Implemen-
tationen in die abstrakten Modelle wichtig. Da SysML Unterstützung für einen Transfer in alle
nachgelagerten Entwicklungsphasen bietet und bereits eine sehr starke Verbreitung unter Soft-
warearchitekten hat, wird im Rahmen dieser Arbeit, neben dem roboterspezifischen BCM, vor
allem die Integration von SysML umgesetzt werden.
3.5 Plattformabhängigkeit in der Toolchain
Ein Ziel des Einsatzes von modellbasierten Entwicklungstoolchains ist die Reduzierung von Platt-
formabhängigkeiten und damit die Steigerung von Wiederverwendbarkeit bei der Entwicklung. Im
ursprünglichen Ansatz der OMG zu modellbasierter Entwicklung ist die Definition von plattform-
unabhängigen Modellen (PIM) vorgesehen, später werden plattformspezifische Modelle (PSM)
daraus generiert. In der Anwendung dieser Auftrennung auf die mobile Manipulation stellen sich
38
3.6 Portieren von Komponenten zwischen Softwareframeworks
die Fragen: wie “Plattform” in diesem Zusammenhang definiert ist und wie “Abhängigkeiten”
detaillierter spezifiziert werden können. Im Folgenden sollen nun sowohl für die einzelnen Belange
einer Komponente als auch für die unterschiedlichen Entwicklerrollen während der Entwicklung
die Begriffe der “Abhängigkeit” und die Begriffe der “Plattform” einzelnen analysiert werden.
Für den Belang der Kalkulation kann auch in der Robotik der klassische “Plattform”-Begriff ver-
wendet werden. Dieser bezieht sich auf die eingesetzte Programmiersprache sowie die Computer-
architektur des Zielsystems als induzierte Abhängigkeiten. Bei den Belangen der Kommunikation
und Koordination einer einzelnen Komponente erzeugen die eingesetzten Komponentenframe-
works (siehe Kapitel 2.3) Abhängigkeiten. Außerdem sind Komponenten, beispielsweise im Fall
von Treiberkomponenten, zum Teil an bestimmte Roboterhardware gebunden. Die strukturelle
Beschreibung der Konfiguration einer Komponente ist durch den Konfigurationsmechanismus
des Komponentenframeworks vorgegeben. Die Komposition und Koordination auf Systemebene
ist wiederum anwendungsabhängig und komponentenframeworkabhängig. Die Umsetzung eines
Koordinators hängt sowohl von der Anwendung als auch dem eingesetzten Komponentenframe-
work ab.
Für die Erhöhung der Wiederverwendung während der Entwicklung von Anwendungen für die
mobile Manipulation ist eine klare Darstellung der Abhängigkeiten der verschiedenen “Plattfor-
men” erforderlich. Das Reduzieren von Abhängigkeit bezüglich Middlewares, Programmierspra-
chen und der Anwendungsumsetzung ist während der Entwicklung erforderlich. Im Folgenden
werden nun Konzepte diskutiert, die zu dieser Reduktion führen.
3.6 Portieren von Komponenten zwischen
Softwareframeworks
Da in der mobilen Manipulation, wie in Kapitel 2 diskutiert, verschiedenste Komponentenframe-
works zum Einsatz kommen, sollte ein Transfer von Komponentenimplementationen zwischen
den Frameworks möglichst einfach erfolgen. Da die meisten verbreiteten Frameworks sehr ähn-
liche Prinzipien umsetzen (siehe (Shakhimardanov und Prassler 2007)) ist eine Transformation
über modellbasierte Entwicklungsumgebungen möglich, wenn folgende Faktoren erfüllt sind:
• Die Verfügbarkeit von Meta-Modelle (M2) jeweils für die entsprechenden Frameworks ist
gewährleistet.
• Die Separierung von den frameworkspezifischen Mechanismen und dem Anwendungsquell-
code in den Modellen (M1) sowie im generierten, ausführbaren Code (M0) besteht.
• Die in den Meta-Modellen definierten Primitiven sind aufeinander übertragbar.
Letztere Eigenschaft ist vorhanden, wenn die konkreten Meta-Modelle der Frameworks auf ei-
nem gemeinsamen Abstraktionsmodell basieren. Beispielsweise können Meta-Modelle konkreter
39
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
Frameworks, wie ROS oder OROCOS RTT, auf Basis der Mechanismen des BRICS Compo-
nent Model (BCM) entwickelt werden (siehe (Bruyninckx, Klotzbücher et al. 2013)). Für jedes
Framework kann dann mittels einer solchen Abstraktion eine M2M-Transformation von der Abs-
traktion und eine Rücktransformation in die Abstraktion umgesetzt werden, statt beliebig viele
Transformationen in den entsprechenden Frameworks zu erstellen (siehe Abbildung 3.9).
Abbildung 3.9: Plattformunabhängigkeit zwischen Middlewares
Jedoch entsteht bei dieser Abstraktion ein Informationsverlust, wenn Mechanismen in der Kom-
ponente eingesetzt wurden, die nicht auf verschiedene Middlewares übertragbar sind. Für die
Kompensation dieses Informationsverlustes gibt es zwei Möglichkeiten. Entweder werden die be-
nötigten Informationen manuell vom Entwickler zur Verfügung gestellt oder es gibt implizite
Annahmen in den M2M-Transformationen. Letzteres sollte mit dem Anspruch der Plattformun-
abhängigkeit der Komponententoolchain vermieden werden. Um den Informationsverlust bei der
komponentenframeworkunabhängigen Modellierung klein zu halten, sollte der Komponenten-
entwickler von der Toolchain unterstützt werden. Es sollten übertragbare, d.h. mit geringem
Informationsverlust abstrahierbare, Mechanismen gekennzeichnet werden und für schlecht über-
tragbare Mechanismen Alternativen vorgeschlagen werden.
Um die Portierbarkeit der Komponenten zu gewährleisten, wird das in dieser Arbeit entwickelte
Meta-Modell an das BCM angelehnt. Aufgrund der Verbreitung des Komponentenframeworks
ROS wird das Meta-Modell zunächst für dieses Komponentenframework umgesetzt. Ein Transfer
in ein anderes Framework, beispielsweise OROCOS RTT, wird dann mittels der Konformität zum
BCM umgesetzt.
40
3.7 Programmiersprachen und Zielsysteme
3.7 Programmiersprachen und Zielsysteme
Bei der Entwicklung von komplexen mobilen Manipulatoren werden die verwendeten Komponen-
ten von einer Vielzahl meist verteilter Entwickler umgesetzt. Das Wissen und die Erfahrungen
der Entwickler unterschieden sich meist stark. Dies bezieht sich auch auf die Erfahrungen und
Präferenzen bezüglich der verwendeten Programmiersprachen. Die Einführung von komponen-
tenbasierten Softwaresystemen in der Robotik erleichtert das Zusammenspiel von Komponenten,
die in unterschiedlichen Programmiersprachen entwickelt werden. Gerade die Middleware ROS
zeichnet sich durch eine starke Flexibilität bzgl. Programmiersprachen aus. Bei der Integration
der Software erschwert der Einsatz unterschiedlicher Sprachen jedoch die Arbeit, da im schlimms-
ten Fall der Systemintegrator in allen Sprachen Vorwissen mitbringen muss, um die Struktur der
eingesetzten Komponenten zu verstehen.
Eine programmiersprachenunabhängige Modellierung in einer modellbasierten Toolchain macht
die leichte Integration von Komponenten in unterschiedlichen Programmiersprachen möglich.
Die programmiersprachenabhängigen Mechanismen müssen hier entweder in der verwendeten
Middleware oder in der Codegenerierung der Toolchain abstrahiert werden. Auch Belange wie
Konfiguration und Koordination müssen abstrakt vorhanden sein.
Gleiches gilt für die Unterstützung unterschiedlicher Zielplattformen. Zwar werden in der Praxis
bei komplexen mobilen Manipulatoren zumeist PC-basierte Zielsysteme eingesetzt. Dennoch ist
eine Flexibilität bzgl. des Zielsystems wünschenswert und wird in der Produktentwicklung der
Systeme eine große Rolle spielen. Die Meta-Modelle müssen also zum einen unabhängig von
den Zielsystemen sein und zum anderen ggf. Zusatzinformationen für das Installieren enthalten.
ROS bietet hierfür eine Basis, da Komponenten sowohl auf unterschiedlichen Betriebssystemen,
wie Windows und Linux, als auch auf unterschiedlichen PC-Plattformen, wie ARM oder x86,
betrieben werden können.
Die Umsetzung einer plattformunabhängigen modellbasierten Toolchain konzentriert sich aus
diesen Gründen in dieser Arbeit vor allem auf die Komponentenmiddleware ROS.
41
3 Entwicklung komplexer Softwaresysteme für die mobile Manipulation
3.8 Zusammenfassung
Die in diesem Kapitel beschriebenen Ansätze können zur Erfüllung der eingangs definierten
Entwicklungsziele einer modellbasierten Toolchain beitragen. Daher werden sie zu einem Ge-
samtkonzept für eine ganzheitliche Entwicklungstoolchain kombiniert, wie sie in Abbildung 3.10
graphisch dargestellt ist.
Abbildung 3.10: Gesamtkonzeption einer modellbasierten Entwicklungsumgebung für mobile
Manipulatoren
Die Entwickler in ihren unterschiedlichen Rollen können dabei Modelle ihrer Domäne erstel-
len. Die Modelle unterscheiden sich dabei bzgl. der beschriebenen Entwickleraspekte. Durch die
Unterscheidung von Entwicklerrollen und Modellen können auch die Phasen der Softwareent-
wicklung getrennt betrachtet werden. Während für die Rolle des “Software-Architekten” bereits
verbreitete Werkzeuge, wie für SysML, existieren, müssen im Rahmen dieser Arbeit für die an-
deren Rollen neue modellbasierte Werkzeuge erstellt werden. Diese werden so umgesetzt, dass
sie nach der Bottom-up-Methode das Wissen der Entwickler über das Komponentenframework
direkt in den Modellen abbilden. Aufgrund der starken Verbreitung werden in dieser Arbeit die
Konzepte des Komponentenframeworks ROS in den Modellen verwendet.
42
3.8 Zusammenfassung
Zusätzlich zu neuentwickelten Modellen muss die Nutzung von bestehenden modellierten Kom-
ponenten möglich sein. Die Verknüpfung zu Modellen in bestehenden Toolchains ist durch formal
definierte Transformationen möglich.
Die Modelle beschreiben das vollständige Softwaresystem eines mobilen Manipulators. Durch
automatisierte Generierung von Quellcode können die Modelle in Implementationen für verschie-
dene Komponentenframeworks überführt werden. Wegen der starken Verbreitung und der guten
Integration in bestehende Robotersysteme bietet es sich an, vor allem ROS und OROCOS RTT
zu betrachten. Das weitgehend automatisiert entstandene Softwaresystem kann anschließend
auf dem mobilen Manipulator in der “Deployment”-Phase ausgeführt werden.
Die modellbasierte Entwicklungsumgebung spiegelt damit alle Aspekte der Softwareentwicklung
von mobilen Manipulatoren wider. Der Fokus der Toolchain liegt dabei auf der Formalisierung
und Automatisierung der Entwicklung.
43

4 Umsetzung einer
Entwicklungsumgebung für mobile
Manipulatoren
Basierend auf dem im letzten Kapitel hergeleiteten Gesamtkonzept des frameworknahen modell-
basierten Entwickelns ist im Rahmen dieser Arbeit eine konkrete Umsetzung dieses Konzeptes
entstanden, um die anfangs beschriebenen Entwicklungsziele zu erreichen. Kernstück ist eine
modellbasierte Entwicklungsumgebung für ROS, das “BRICS integrated development environ-
ment“ (BRIDE). Im Folgenden werden die einzelnen Teile dieser Entwicklungsumgebung und
deren Umsetzung diskutiert.
4.1 BRIDE als eine modellbasierte Entwicklungsumgebung
für ROS
Zur Umsetzung einer modellbasierten Entwicklungsumgebung für eine spezifische Domäne kann
auf bereits existierende offene Entwicklungen zurückgegriffen werden, die bereits die M3-Ebene
der OMG-Pyramide sowie Definitions- und Transformationsmechanismen bereitstellen. Neben
dem “Meta Programming System” des Herstellers Jetbrains wurden im Eclipse Projekt, genauer
dem Eclipse Modeling Framework (EMF), entsprechende Werkzeuge geschaffen. Aufgrund der
weiten Verbreitung, der größeren Community sowie der Integration mit anderen Programmierpro-
zessen, wie Versionsmanagement und Testing, wurde die modellbasierte Entwicklungsumgebung
für ROS auf dem Eclipse Modelling Framework (EMF) umgesetzt.
Als Grundvorgehen bei der Erstellung einer ganzheitlichen MDE-Toolchain wird mit der ECore
Meta-Meta-Sprache des Projektes ein Meta-Modell für die Zieldomäne erstellt. Mittels verschie-
dener Umsetzungen aus EMF-Unterprojekten werden Editoren für Modelle, die dem definierten
Meta-Modell entsprechen, entwickelt. Letztendlich können diese Modelle dann mittels Trans-
formationsmechanismen des EMF-Unterprojektes Epsilon in Quellcode umgesetzt werden. Ab-
bildung 4.1 stellt diesen Gesamtaufbau für den Fall von BRIDE an der OMG-Pyramide dar.
Die einzelnen, in Kapitel 3 beschriebenen Entwicklungskonzepte wurden in diesem Bild zudem
den entsprechenden Ebenen in der OMG-Pyramide (Abbildung 2.8) zugeordnet. Diese einzelnen
45
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
Abbildung 4.1: Umsetzung der verschiedenen Ebenen der OMG-Pyramide in BRIDE
Artefakte der modellbasierten Toolchain sind als einzelne Eclipse-Plugins umgesetzt und können
in die Eclipse-Instanz des Entwicklers eingebunden werden. Die Summe aller Plugins ist eine
Eclipse Distribution, die als BRIDE ROS Projekt (http://ros.org/wiki/bride) veröffentlicht wird,
um in der ROS-Community diskutiert und verwendet zu werden.
4.2 Das ROS Meta-Modell und die Entwicklerbelange
Das Kernstück der im Rahmen dieser Arbeit umgesetzten ROS-Entwicklungstoolchain ist die
Definition der domänen-spezifischen Eigenschaften im ROS Meta-Modell, im Folgenden auch
“ROS domain specific language” (ROS DSL) genannt. In diesem sind alle bekannten ROS-
Mechanismen definiert und den jeweiligen, in Kapitel 3 erläuterten Entwicklerbelangen zugeord-
net. Dazu wird in der Meta-Meta-Sprache ECore, die im Eclipse Modelling Framework enthalten
ist, jeweils eine Klasse für die verschiedenen ROS-Mechanismen, wie “Node”, “Package”, etc.
erstellt und die dazugehörigen Eigenschaften als Attribute definiert. Über Relationen wird an-
schließend die Struktur der Mechanismen untereinander spezifiziert, beispielsweise enthält ein
“Package” keinen, einen oder mehrere “Nodes”.
Angelehnt an abstraktere Modellierungssprachen wie SysML, besteht auch das ROS-Meta-
Modell aus mehreren Teilen. Das Meta-Modell “ros.ecore” beschreibt die Grundkonzepte von
ROS, während das Meta-Modell “smach.ecore” eine Spezialisierung der Konzepte der Anwendungs-
und Koodinationsentwicklung enthält. Aus den als “.ecore”-Datei spezifizierten Meta-Modellen
wird ein sogenanntes Generator-Modell in Eclipse (als Datei “genmodel”) erzeugt, das Abhängig-
keiten von Modellen untereinander auflöst und ermöglicht die nachfolgende Codegenerierung zu
konfigurieren. Nach Konfiguration im Generator-Modell kann Quellcode erzeugt werden, der das
46
4.2 Das ROS Meta-Modell und die Entwicklerbelange
Abbildung 4.2: Workflow zum Erstellen einer modellbasierten Toolchain mit EMF
Modell repräsentiert und eine Erzeugung von Modellinstanzen innerhalb von Eclipse ermöglicht.
Zwar sind hiermit noch keine Modelleditoren erstellt, jedoch ist es möglich, programmatisch
Modelle zu erstellen und zu bearbeiten. Dieser Entwicklungsprozess zur Erstellung einer modell-
basierten Toolchain mit EMF ist in Abbildung 4.2 dargestellt.
Im Folgenden wird auf die einzelnen Entwicklerbelange bei der Verwendung von ROS und die
konkrete dazugehörige Modellierung in der ROS DSL eingegangen.
• Kommunikation: Die Kommunikation in ROS, umgesetzt in der ros_comm Bibliothek
(http://wiki.ros.org/ros_comm), kann auf drei verschiedene Weisen in einer Komponen-
te implementiert werden. Die erste Möglichkeit ist asynchrone Kommunikation, bei der
ein Publisher Daten an beliebig viele Subscriber senden kann. Die Daten, die ein Sub-
scriber empfängt, können ebenfalls von unterschiedlichen Publishern kommen. Die zweite
Möglichkeit ist das synchrone Senden, bei dem ein ServiceClient einen Funktionsaufruf
auf einem ServiceServer durchführt. Der ServiceClient blockiert, bis die Antwort empfan-
gen ist. Mehrere ServiceClients können nacheinander einen ServiceServer aufrufen. Die
dritte ROS-Kommunikation ist eine synchronisierte Kommunikation über eine Kommuni-
kationszustandsmaschine. Hier wird von einem sogenannten ActionClient asynchron eine
Funktionalität von einem ActionServer angefragt. Dieser informiert den Client anschließend
asynchron über den aktuellen Stand und das Ergebnis der Verarbeitung. Der ActionClient
ist während der Abarbeitung des Servers nicht blockiert. Die verschiedenen Kommunika-
tionsserver und -clients entsprechen also “Ports” an einer ROS-Komponente, dem ROS
node, und werden dem Entwicklerbelang Kommunikation zugeordnet. Somit sind im ROS
Meta-Modell die Klasse Node und die dazugehörigen Klassen Publisher, Subscriber, Ac-
tionServer, ActionClient, ServiceServer sowie ServiceClient mit den entsprechenden Attri-
buten definiert. Das Besondere bei der Definition der Attribute der Klassen ist der Wegfall
der normalerweise im Quellcode vordefinierten Topics, Services und Actionreferenzen. Die-
47
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
se werden dem Belang der Komposition zugeordnet und sind nicht als implizite Attribute,
sondern als eigene Klasse im Modell definiert, um später separierbar zu sein und während
des Deployment-Vorgangs konfiguriert zu werden.
• Konfiguration: ROS hat mit dem ROS-Parameter-Server, der Definition von Parametern
über Launchfiles sowie der “dynamic_reconfigure”-Infrastruktur drei verschiedene Mög-
lichkeiten der Konfiguration von ROS Komponenten. Da alle drei Mechanismen dieselbe
Definition der zu konfigurierenden Parameter besitzen, wird im Meta-Modell auch nur eine
Definition benutzt. Die Wahl der konkreten Umsetzung der Konfiguration in ROS wird in
der Code-Generierung der Toolchain umgesetzt und kann somit ausgetauscht werden. Ein
Parameter besitzt immer Name, Typ, Wertebereich und Default-Wert. In der Umsetzung
wurde die Parameterklasse als 0:n Containment von Node modelliert.
• Komposition: Um mehrere Komponenten miteinander zu verschalten wurde die Klasse
Architecture als Repräsentation eines ROS-Subsystems definiert, die kein, ein oder meh-
rere Nodes enthalten kann. Zur vollständigen Konfiguration eines ROS Systems wurden
den Komponenten noch zusätzliche Parameter hinzugefügt, wie beispielsweise der ROS
Namespace. Für die entsprechenden Kommunikationsanschlüsse, die für in der Architektur
enthaltene Komponenten definiert wurden, können in ROS entsprechende Verbindungen
konfiguriert werden. Diese Verbindungen wurden ebenfalls als jeweilige Klasse modelliert
und als 0:n Containment zur Architektur hinzugefügt. Jede Klasse enthält als Quelle eine
Referenz auf den jeweiligen Publisher, ActionServer oder ServiceServer und als Ziel eine
Referenz auf den jeweiligen Subscriber, ActionClient oder ServiceClient.
• Kalkulation: Der Teil einer ROS-Komponente, in dem die eigentliche Kalkulation statt-
findet, der Treiber umgesetzt ist oder andere Datenverarbeitungsaufgaben durchgeführt
werden, wird nicht in der DSL modelliert, da es auch innerhalb von ROS keine Defini-
tionen für die Umsetzung dieses Komponententeils gibt. Durch die explizite Modellierung
der anderen Belange und unter der Annahme, dass es in ROS-Komponenten nur diese
fünf Belange gibt, kann die Berechnungsfunktionalität dennoch vom Rest der Kompo-
nente getrennt werden. Der Einsatz von anderen Modellierungswerkzeugen, beispielsweise
Simulink, wird damit möglich.
• Koordination: Innerhalb der Komponente gibt es in ROS keine vorgeschriebene Umset-
zung der zeitlichen Abläufe des Zusammenwirkens von Kommunikation und Berechnung,
dies wird vollständig dem Entwickler überlassen. Daraus resultiert ein sehr unterschiedli-
ches Verhalten von ROS-Komponenten, die wiederverwendet werden sollen. Im Rahmen
dieser Arbeit werden daher unabhängig von der ROS-Spezifikation zwei fest definierte Zu-
standsmaschinen für das interne Verhalten festgelegt, aus denen der Entwickler wählen
kann. Wie in Abbildung 4.3 dargestellt, beginnt der Lebenszyklus einer Komponente mit
48
4.2 Das ROS Meta-Modell und die Entwicklerbelange
dem Konfigurationszustand, in dem der Entwickler alle zur Laufzeit benötigten Aufga-
ben umsetzen kann. Nach dem erfolgreichen Konfigurieren werden entweder zyklisch oder
durch bestimmte Eingangssignale ausgelöst alle Eingänge synchronisiert, danach die Up-
datefunktion ausgeführt und anschließend alle Ausgänge geschrieben. In der Updatefunk-
tion können vom Programmierer beliebige Aufgaben umgesetzt werden. Eine weitere Ei-
genschaft in ROS bezüglich der internen Koordination von Komponenten ist der Einfluss
von Kommunikation in den internen Ablauf der Komponente. Insbesondere im Fall der
auf Actionlib basierten Kommunikation ist daher eine klare Trennung zwischen Verhal-
ten der Berechnung und Verhalten der Kommunikation wichtig. Durch die Trennung von
Kommunikation und Berechnung in der DSL kann bei der späteren Codegenerierung diese
Trennung durch Threading-Mechanismen umgesetzt werden.
Abbildung 4.3: Interne Zustandsmaschine einer ROS-Komponente, die mit BRIDE entwickelt
wurde
Die Modellierung der beschriebenen ROS-Grundkonzepte ermöglicht die Erstellung von einzel-
nen ROS-Komponentenmodellen sowie das Zusammenschalten dieser Komponenten zu einem
Gesamtsystem. Durch die Modellierung der Konzepte in einzelne Klassen ist eine Separierung
der einzelnen Aspekte im Modell möglich. Abbildung 4.4 zeigt das ROS-Meta-Modell in seiner
graphischen Repräsentation. Die einzelnen Aspekte sind dabei farblich hervorgehoben. Zudem
ist in Tabelle 4.1 die Zuordnung übersichtlich dargestellt.
49
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
Abbildung 4.4: ECore Meta-Modell für Komponenten- und Systemaspekte in ROS
Tabelle 4.1: Zuordnung von Entwicklerbelangen zu den ROS-Mechanismen
Entwicklerbelang ROS Mechanismus
Kommunikation Publisher, Subscriber, ServiceServer, ServiceClient, ActionServer,
ActionClient
Konfiguration rosparam, dynamic_reconfigure
Komposition Topic, Service, Action, Namespacing
Kalkulation keiner (wird vom Entwickler umgesetzt)
Koordination keiner (von BRIDE festgelegt)
50
4.2 Das ROS Meta-Modell und die Entwicklerbelange
Zusätzlich zu den Standardkommunikationsmechanismen gibt es weitere spezialisierte Kommuni-
kationsmechanismen in ROS. Zum Übermitteln der aktuellen Positionen der Roboterteile kann
beispielsweise der Mechanismus “TF” eingesetzt werden, zur Übertragung von Analysedaten
werden “diagnostics_aggregators” verwendet. Da diese Kommunikationsmechanismen als Basis
ebenfalls die in der DSL modellierten ROS-Basismechanismen verwenden, wird diese Spezial-
kommunikation nicht in der DSL modelliert. Im Kapitel zur Codegenerierung (4.4) wird noch
einmal detaillierter auf diese Mechanismen eingegangen.
Abbildung 4.5: ECore Meta-Modell für Koordinationsaspekte in ROS in Form der SMACH DSL
Mit der bisher beschriebenen DSL können sowohl Komponenten als auch ROS-Subsysteme aus
mehreren Komponenten entwickelt werden. In ROS werden Applikationen z.B. mit dem Zu-
standsmaschinenframework SMACH umgesetzt. Eine damit entwickelte Zustandsmaschine er-
scheint dann als normale ROS-Komponente in einem ROS-System. Daher wird für die Erstel-
lung von Applikationen mit BRIDE ein weiteres Meta-Modell als smach.ecore erstellt, das eine
Spezialisierung der durch die ROS DSL formalisierten ROS-Komponente ist. In der SMACH
DSL werden Nodes zu “StateMachines” spezialisiert, die jeweils “States” beinhalten können.
Diese “States” bedienen als ActionClients oder ServiceClients jeweils im System befindliche
Funktionalitätskomponenten und werden dementsprechend als Spezialisierungen dieser Kommu-
nikationsmechanismen modelliert. Zusätzlich ist in der SMACH DSL noch der StateTransition-
Mechanismus modelliert, der entsprechend des Feedbacks des vorherigen Kommunikationsstates
aufgerufen wird. Um Anfang und Ende einer Applikation zu beschreiben, gibt es zudem noch die
InitState und FinalState Mechanismen, die States ohne Funktion darstellen. In Abbildung 4.5
ist die SMACH DSL grafisch dargestellt. Das resultierende Meta-Modell ist damit vollständig
kompatibel zum ROS-Meta-Modell. Es enthält ausschließlich zusätzliche Informationen, die für
Applikationskomponenten relevant sind.
51
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
4.3 Entwicklung von Modelleditoren für ROS
Basierend auf dem erstellten Meta-Modell sollen Entwickler mittels eines Editors entsprechende
Modelle erstellen können. Um die Auftrennung der Nutzerrollen bei der Bearbeitung der Modelle
zu ermöglichen, werden bestimmte Teilaspekte des Meta-Modelles in verschiedenen Editoren
umgesetzt. In der Eclipse-Umgebung gibt es zwei verschiedene Möglichkeiten, Modell-Editoren
dem Entwickler bereitzustellen, basierend auf dem Graphical Editing Framework (GEF) einen
graphischen oder basierend auf dem XText Framework einen textuellen Editor. Beide Varianten
haben Vor- und Nachteile und spiegeln in der Regel auch Präferenzen der einzelnen Entwickler
wieder. Um die Verbreitung von BRIDE zu maximieren, wurden beide Implementationsmöglich-
keiten für das jeweilige Modell umgesetzt.
Abbildung 4.6: Prozess der Erstellung von GMF-basierten Modelleditoren
Anstatt der vollständig manuellen Erstellung von GEF-Editoren kann in Eclipse auf ein mo-
dellbasiertes Generierungsverfahren für Modelleditoren zurückgegriffen werden, dem Graphical
Modeling Framework (GMF). Bei der Verwendung dieses Verfahrens werden Modelle erstellt,
aus denen der GEF-Quellcode teilautomatisiert generiert wird (siehe Abbildung 4.6). Für die
einzelnen Editoren von BRIDE wurden entsprechend des GMF-Verfahrens folgende Modelle ent-
wickelt:
• gmfgraph: Resultierend aus den Definitionen im ECore Meta-Meta-Modell kann eine
Beschreibung der einzelnen graphischen Elemente im zu erstellenden Editor umgesetzt
werden. Hierbei handelt es sich um Bilder der Hauptelemente (z.B. Nodes und Subscriber)
sowie Verbindungslinien und Textelemente.
• gmftool: Im späteren Editor gibt es eine Werkzeugleiste, um die einzelnen Elemente
hinzuzufügen. Für die Erstellung dieser Funktionalität wird dieses Modell erstellt.
• gmfmap: Um die Relationen der Elemente untereinander sowie zum ECore Meta-Meta-
Modell zu beschreiben, wird ein weiteres Modell benötigt. In diesem wird definiert, welche
Elemente in anderen dargestellt werden (z.B. Publisher innerhalb von Node-Elementen),
52
4.3 Entwicklung von Modelleditoren für ROS
welche Textelemente welche Textinformation enthalten sowie welche Verbindungselemente
welche Elemente verbinden. Zudem wird die Zugehörigkeit zu Tools und ECore-Klassen
definiert.
• gmfgen: Basierend auf den beschriebenen GMF-Modellen wird ein weiteres Modell ge-
neriert, das die eigentliche Repräsentation in einer graphischen Oberfläche darstellt. In
diesem können noch konkrete Anpassungen der Implementation, wie der verknüpfte Da-
teityp, Klassennamen oder Paketnamen modifiziert werden.
4.3.1 Umsetzung des Capability-Editors
Abbildung 4.7: Entwicklung einer Funktionalität im BRIDE-Capability-Editor
Mittels dieser Vorgehensweise wurde ausgehend von der Meta-Definition eines ROS-Paketes
der Editor für die Ersteller von Funktionalitäten umgesetzt. Der Entwickler kann ein einzelnes
ROS-Paket mit einem oder mehreren Nodes entwickeln. Für jeden Node kann er Parameter
als Konfigurationsaspekt sowie die Kommunikationsschnittstellen als Publisher/Subscriber, Ser-
viceServer/-Client oder ActionServer/-Client definieren. Während die Informationen des graphi-
schen Modells in der Datei _NAME.ros_package_diagramm_ hinterlegt sind, wird synchroni-
siert eine Datei _NAME.ros_package_ nach dem XMI-Standard gepflegt, die die reinen ROS-
Modellinformationen enthält und somit das eigentliche Modell repräsentiert. In Abbildung 4.7
ist eine Instanz des ROS-Capability-Editors exemplarisch dargestellt, Listing 4.1 zeigt das vom
Editor erstellte Modell.
53
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
Listing 4.1: Beispiel eines über den Capability-Editor erzeugten Modells
<?xml version=”1.0” encoding=”UTF8”?>
<ros:Package xmi:version=”2.0” xmlns:xmi=”http://www.omg.org/XMI” xmlns:ros=”http://ros
/1.0” name=”brics_showcase_industry_transformer” author=”Alexander Bubeck” description=
”Transforms Positions from Camera Coordinates to Arm Coordinates” license=”” rosdep=””>
<node name=”pose_transformer”>
<subscriber name=”CameraDetections” msg=”geometry_msgs::PoseArray”/>
<serviceClient name=”SetObjectPose” msg=”brics_showcase_industry_interfaces::
SetObjectPose”/>
<parameter name=”CameraPose” value=”[[0,0,0],[0,0,0,0]]” type=”string”/>
<parameter name=”MeterPerPixel” value=”0.000671” type=”double”/>
<actionserver name=”FindObject”/>
</node>
<depend>brics_showcase_industry_interfaces</depend>
<depend>geometry_msgs</depend>
</ros:Package>
Abbildung 4.8: Entwicklung einer Zustandsmaschine für eine Anwendung im BRIDE-
Coordinator-Editor
54
4.3 Entwicklung von Modelleditoren für ROS
4.3.2 Umsetzung des Coordinator-Editors
Als weitere Nutzerrolle wurde in Kapitel 3 der Anwendungsentwickler definiert, der die System-
koordination erstellt. Die dafür im Meta-Modell entwickelte erweiterte Zustandsmaschinendefi-
nition wird in dem ROS Coordinator Editor als Modelleditor umgesetzt. Dabei handelt es sich
um eine Spezialisierung des “ros.ecore” Modells. Als Werkzeuge stehen dem Benutzer hier Zu-
standsmaschinen, verschiedene Zustandstypen sowie Zustandstransitionen zur Verfügung. Der
in Abbildung 4.8 dargestellte Editor repräsentiert die in _NAME.ros_coordinator_diagramm_
und _NAME.ros_coordinator_ hinterlegten Modellinformationen. Listing 4.2 zeigt das Modell
im Quelltext.
Listing 4.2: Beispiel eines über den Coordinator-Editor erzeugten Anwendungsmodells
<?xml version=”1.0” encoding=”UTF8”?>
<ros:Package xmi:version=”2.0” xmlns:xmi=”http://www.omg.org/XMI” xmlns:xsi=”http://www.
w3.org/2001/XMLSchemainstance” xmlns:ros=”http://ros/1.0” xmlns:smach=”http://smach
/1.0” name=”pickup_application” author=”Alexander Bubeck” author_email=”aub@ipa.fhg.de
” description=”Application implementing a pickup task.” license=”LGPL”>
<node xsi:type=”smach:SMACHStateMachine” name=”pick_up” SkillInterface=”true”>
<actionclient xsi:type=”smach:ActionState” name=”Move_over_box” ActionType=”
brics_showcase_industry_interfaces::MoveArmCart” goal=”Move_over_box”/>
<actionclient xsi:type=”smach:ActionState” name=”Move_down” ActionType=”
brics_showcase_industry_interfaces::MoveArmCart” goal=”Move_down” remap_overwrite=””/
>
<actionclient xsi:type=”smach:ActionState” name=”Close_gripper” ActionType=”
brics_showcase_industry_interfaces::Gripper” goal=”Close_gripper”/>
<actionclient xsi:type=”smach:ActionState” name=”Move_up” ActionType=”
brics_showcase_industry_interfaces::MoveArmCart” goal=”Move_up”/>
<transitions Source=”//@node.0/@initialStates.0” Target=”//@node.0/@actionclient.0”/>
<transitions Source=”//@node.0/@actionclient.0” Target=”//@node.0/@actionclient.1”/>
<transitions Source=”//@node.0/@actionclient.1” Target=”//@node.0/@actionclient.2”/>
<transitions Source=”//@node.0/@actionclient.2” Target=”//@node.0/@actionclient.3”/>
<transitions Source=”//@node.0/@actionclient.3” Target=”//@node.0/@finalStates.0”/>
<finalStates/>
<initialStates/>
</node>
<depend>brics_showcase_industry_interfaces</depend>
</ros:Package>
55
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
4.3.3 Umsetzung des System-Editors
Der Modelleditor für die dritte Entwicklerrolle ist der ROS-System-Editor. Dieser hat die Be-
sonderheit, dass er auf andere Modelle verweisen muss. Im Gegensatz zu bestehenden Ansätzen
in der Eclipse Gemeinde wurde hierbei weder der Ansatz von Modellkopien, d.h. der Kopie der
Modellinformationen in das gemeinsame Modell, noch der Ansatz von GMF-Referenzen, die nur
graphische Referenzen darstellen, gewählt. Der Grund dafür ist, dass zum einen eine Verknüp-
fung der Entwicklerrollen entstehen soll, d.h. Änderungen des Funktionalitätsentwicklers sollen
auch für den Systementwickler sichtbar sein, zum anderen muss die Verknüpfungsinformation
direkt im Modell vorhanden sein, um eine Weiterverarbeitung zu ermöglichen. Die Verknüpfung
wird mit einer Referenz im XMI-Modell umgesetzt. Die graphische Umsetzung dieses Mechanis-
mus stellte sich als schwierig heraus, da diese Verknüpfungsart für GMF-basierte Editoren nicht
vorgesehen ist. Mittels manuellen Eingriffen in die Erstellungs- und Löschfunktionalitäten des
GMF-Editors nach Erstellung über das oben aufgezeigte Verfahren ist ein graphisches Editieren
der verknüpften Elemente möglich.
Listing 4.3: Beispiel eines über den System-Editor erzeugten Modells
<?xml version=”1.0” encoding=”UTF8”?>
<ros:Architecture xmi:version=”2.0” xmlns:xmi=”http://www.omg.org/XMI” xmlns:ros=”http://
ros/1.0” name=”ROS Industrial demonstrator” author=”Alexander Bubeck” author_email=”
aub@ipa.fhg.de” license=”LGPL” description=”System deployment for demonstration booth.”>
<topic name=”detect_pattern”>
<publisher href=”platform:/resource//brics_showcase_industry_cognex/cognex_insight.
ros_package#//@node.0/@publisher.0”/>
<subscriber href=”platform:/resource//brics_showcase_industry_transformer/pose_transformer.
ros_package#//@node.0/@subscriber.0”/>
</topic>
<packages href=”platform:/resource//brics_showcase_industry_cognex/cognex_insight.
ros_package#/”/>
<packages href=”platform:/resource//brics_showcase_industry_world_model/si_worldmodel.
ros_package#/”/>
<packages href=”platform:/resource//brics_showcase_industry_transformer/pose_transformer.
ros_package#/”/>
<service name=”setObjectPose”>
<serviceserver href=”platform:/resource//brics_showcase_industry_world_model/si_worldmodel
.ros_package#//@node.0/@serviceServer.0”/>
<serviceclient href=”platform:/resource//brics_showcase_industry_transformer/
pose_transformer.ros_package#//@node.0/@serviceClient.0”/>
</service>
</ros:Architecture>
56
4.3 Entwicklung von Modelleditoren für ROS
Abbildung 4.9: Entwicklung von Softwaresystemen für Roboteranwendungen mit dem BRIDE
System Deployment Modellierer
Für den Systementwickler stehen somit die Modell-Funktionalitäten der Komposition, d.h. Topic,
Service und Action, sowie die Konfiguration der vom Funktionsentwickler definierten Parameter
zur Verfügung (siehe Abbildung 4.9). Die Komponenten werden dem Systementwickler unab-
hängig vom Typ der Komponenten, also Funktionalität oder Koordination, dargestellt, da dies
keinen syntaktischen Unterschied für die Systemerstellung macht. Das Systemmodell wird in
den Dateien _NAME.ros_system_ sowie _NAME.ros_system_diagram_ hinterlegt, Listing 4.3
zeigt den Inhalt eines solchen Systemmodells.
4.3.4 Entwickeln mit textuellen Editoren
Wer statt der graphischen Editoren die Modelle direkt textuell erstellen oder modifizieren möch-
te, kann hierzu prinzipiell direkt die XMI Dateien nutzen. Für solche Fälle haben sich jedoch
optimalere Formate, wie beispielsweise YAML Ain’t Markup Language (YAML) oder die Human
Usable Textual Notation (HUTN) etabliert. Daher wurde mittels des in Eclipse verfügbaren Xtext
Framework für die jeweilige Nutzerrolle ein HUTN-basiertes Textformat definiert. Hierzu wird
aus dem ECore Meta-Meta-Modell ein Syntaxmodell erstellt, das den Zusammenhang aus syn-
taktischen Elementen und den Elementen des Meta-Modells beschreibt. Aus diesem Modell kann
automatisiert Quellcode generiert werden, der Parser, lexikalische Scanner sowie Hervorhebungs-
mechanismen umsetzt. Die HUTN-Modelle werden entsprechend mit _NAME.ros_system_dsl_,
57
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
_NAME.ros_capability_dsl_ sowie _NAME.ros_coordinator_dsl_ abgespeichert und können
direkt weiterverarbeitet werden.
4.4 Codegenerierung aus den Modellen
Nach der Definition von entsprechenden Modellen zu jeder Entwicklungsprozessphase mittels
der Editoren müssen die Modell in die M0-Ebene der OMG-Pyramide, d.h. die eigentliche Im-
plementation, transferiert werden. Hierzu ist eine M2T-Transformation für jedes Modell spezi-
fiziert worden, die die jeweiligen Artefakte erzeugt. Für die M2T-Transformation werden dazu
Quellcode-Templates in der Epsilon Generation Language definiert, die mit den Informationen
aus den vom Nutzer definierten Modellen gefüllt werden. Hierzu wurde ein M2T-Compiler mit-
tels des Epsilon Frameworks umgesetzt. Die Abbildung 4.10 zeigt eine Übersicht der Dateien
nach einer C++-Generierung eines ROS Capability Modells.
Für die Transformation eines Capability Modells wurde mittels des Templates package.egl der
Inhalt eines ROS-Paketes definiert. Für die Quellcodegenerierung aus einem ros_package wur-
den sowohl Templates für die Erstellung von Komponenten in der Programmiersprache C++
als auch in der Programmiersprache Python implementiert. Zusätzlich zu der Generierung der
Metadatendatei package.xml wird die zum Kompilieren benötigte CMakelist.txt Datei erzeugt.
Für die im Modell definierten Parameter werden “dynamic_reconfigure”-Dateien angelegt. Diese
ermöglichen, zur Laufzeit der Komponente die Konfigurationen anzupassen.
Basierend aus den Erkenntnissen der Separierung von ROS-spezifischem und ROS-unabhängigem
Code (Bubeck, Weisshardt et al. 2012) wird diese Trennung in den Templates umgesetzt. Eine
C++- oder Python-Datei im “ros”-Unterordner setzt die ROS-spezifischen Mechanismen, die im
Modell definiert sind, um. Ein Entwickler sollte diese Datei zu einem späteren Zeitpunkt nicht
modifizieren. Im “common”-Unterordner wird der ROS-unabhängige Quellcode generiert, in dem
der Entwickler seine Implementation der Funktionalität einfügen soll. Hierzu sind innerhalb der
Datei Abschnitte definiert, in denen der Entwickler seinen Quellcode einfügen kann. Durch
die Definition solcher Abschnitte kann der selbstgeschriebene Entwicklercode vom automatisch
generierten Code unterschieden werden und eine Regenerierung des automatisch erzeugten Teils
nach Änderung des Modells überschreibt den vom Nutzer geschriebenen Quellcode nicht. Ein
iterativer Entwicklungsprozess mit mehrmaligen Anpassungen des Modells ist somit möglich.
Ähnlich wie für die ros_package-Modelle sind auch für die ros_coordinator-Modelle ein zen-
trales package.egl definiert sowie Templates für die Meta-Pakete eines Koordinators. Da die
Implementation des Koordinators rein auf ROS und SMACH basiert, ist die Unterscheidung von
ROS-abhängigem und ROS-unabhängigem Code nicht mehr erforderlich. Im Ordner src wird
daher der Quellcode für einen Python-ROS-Node erzeugt, der eine SMACH-Zustandsmaschine
umsetzt. Die Zustandsmaschine wird basieren auf dem definierten Modell aus SimpleActionS-
tates und ServiceStates zusammengesetzt. Für jeden State wird, falls es so modelliert ist, eine
58
4.5 Roundtripping
Abbildung 4.10: Struktur eines ROS Paketes nach der Erzeugung in BRIDE
Callback-Routine angelegt, in der der Nutzer eigenen Quellcode hinzufügen kann. Durch den
Einsatz von Regionen im Template sind auch diese Teile bei einer Neugenerierung weiter vor-
handen.
Für die Generierung von ROS-Systemen werden alle im Systemmodell integrierten Komponenten
automatisch als Systemabhängigkeiten in den generierten Paket-Meta-Dateien eingetragen. Zu-
sätzlich wird für jede Komponente ein Eintrag in der generierten system.launch-Datei erzeugt.
Dieser Eintrag beinhaltet Einträge für die im System-Modell definierten Konfigurationen. Wei-
terhin werden über remap-Kommandos die einzelnen Kommunikationselemente wie im Modell
definiert verbunden. Da für Services solch ein Remapping nicht in der roslaunch-Spezifikation
vorgesehen ist, wird die Komposition im Fall von Services über einen rosParameter vorgenom-
men. Am Anfang und Ende der roslaunch-Datei sind Regionen vorgesehen, in denen der Nutzer
etwaige zusätzliche Launchkonfigurationen (wie z.B. das Hochladen zusätzlicher Parameter)
vornehmen kann.
4.5 Roundtripping
In der bisher beschriebenen Toolchain kann aus einem vom Entwickler erstellten Modell mittels
der M2T-Transformation Quellcode erstellt werden. Wenn eine Toolchain auch ermöglicht, aus
existierendem Quellcode automatisiert die entsprechenden Modelle zu generieren, spricht man
im Kontext der modellbasierten Entwicklung von “Roundtripping”. Das Generieren von Quell-
code, daraus Modelle und wieder Quellcode ergibt einen Kreislauf. Generell bietet Roundtripping
die Möglichkeit, den von der Toolchain generierten Code auch nach manuellen Änderungen zu
überprüfen und entweder nicht-valide Änderungen dem Entwickler mitzuteilen oder auf Ba-
59
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
sis manueller Änderungen das Modell zu aktualisieren. In der Umsetzung von BRIDE für das
Framework ROS ist noch ein weiterer Vorteil von Roundtripping interessant. Da in ROS eine
sehr große Anzahl von Softwarekomponenten vorhanden ist, wurde BRIDE darauf ausgelegt
auch diese, nicht mittels MDE erzeugten Komponenten, in BRIDE zu verwenden. Die manuel-
le Erstellung der Komponentenmodelle existierender Komponenten kann mittels Roundtripping
automatisiert werden. Aufgrund dieser Vorteile bei der Komponentenentwicklung wurde das
Roundtripping in BRIDE realisiert. Dabei muss wie bei der M2T-Generierung für jede Program-
miersprache ein separates Modul geschrieben werden. Im Folgenden soll die Umsetzung für die
bei ROS-Entwicklern verbreitete Sprache Python erläutert werden.
Um aus bestehendem Quellcode die im Meta-Modell beschriebenen Artefakte wiederzufinden,
wird aus dem bestehenden Code ein abstrakter Syntaxbaum (engl. Abstract Syntax Tree, AST)
erstellt. Ein AST wird im Compiler/Interpreter einer Programmiersprache zur baumartigen Sor-
tierung der syntaktischen Elemente eingesetzt, um ihnen eine Semantik zuzuweisen. Für das
Extrahieren von Modellen aus Quellcode ist diese Semantik über das Meta-Modell definiert.
Bei der Umsetzung für Python wird mittels der Bibliothek python-ast ein Syntaxbaum einer
ROS-Komponente erstellt. Daraufhin wird der Baum entsprechend des sogenannten “Visitor
Patterns” durchlaufen und nach einer Tabelle, die basierend auf dem ROS-Meta-Modell erstellt
wurde, werden einzelne ROS-Aufrufe inklusive der entsprechenden Parameter extrahiert. Das
“Visitor Pattern” ist ein Umsetzungsmuster aus der Informatik, das erlaubt, Operationen auf
Strukturen anzuwenden, ohne auf den Aufbau der Strukturen Abhängigkeiten zu erzeugen. Da-
mit kann das Zuweisen von Elementen des Meta-Modells unabhängig von der Erstellung des
AST umgesetzt werden. Aus den aus dem AST extrahierten Daten wird eine XMI-Datei er-
stellt, die das dem Quellcode entsprechende Modell enthält und in BRIDE importiert wird. Da
nicht alle Informationen des ROS-Meta-Modells im Quellcode enthalten sind, werden mit den
dafür vorgesehenen ros-python-Bibliotheken zusätzliche Metadaten aus der package.xml-Datei
des ROS-Paketes extrahiert.
Abbildung 4.11: Ablauf der Generierung von Modellen aus Quellcode zum Umsetzen von Round-
tripping
Der Ablauf des Roundtripping in BRIDE ist schematisch in Abbildung 4.11 dargestellt und wurde
als separates Tool “ros_dissect” umgesetzt. Da es im EMF keine direkten Mechanismen oder
Beispiele für die Umsetzung von Roundtripping gibt, ist die Auslagerung des Parsingvorgangs in
60
4.6 Transformationen zwischen den Meta-Modellen
ein separates Tool ein akzeptables Vorgehen. Das ros_dissect-Tool wird aus dem Eclipse Tool
heraus über Menüs manuell gestartet. Um das Roundtripping auch für Komponenten umzuset-
zen, die in der Programmiersprache C++ entwickelt werden, muss auch für C++ ein AST zum
Traversieren aufgebaut werden. Hierzu wurde beim Tool ros_dissect die Bibliothek libclang ver-
wendet. Die Bibliothek ist die Basis des clang-Projektes (Lattner und Adve 2004), das einen
offenen und, im Gegensatz zum verbreiteten “GNU Compiler Collection” Projekt, einen modula-
ren Kompiler umsetzt. Die Modularität kann im Fall von ros_dissect verwendet werden, um auf
den AST, der innerhalb des Kompilers aufgebaut wird, über die Bibliothek zuzugreifen. Da es für
die libclang auch eine in Python verwendbare Version gibt, kann das Aufstellen des AST in das
in Python geschriebene ros_dissect-Tool integriert werden. Je nach Ursprungssprache wird in
ros_dissect also entweder mittels libclang oder python-ast der AST generiert und anschließend
mit dem implementierten “Visitor Pattern” traversiert.
4.6 Transformationen zwischen den Meta-Modellen
Während die Unterstützung für die Entwicklungsphasen der Einzelkomponentenentwickler und
die spätere Integration in ein Gesamtsystem direkt von der BRIDE-Toolchain umgesetzt ist, ist
es sinnvoll, für die vorangehenden Entwicklungsphasen bestehende Meta-Sprachen zu verwen-
den (siehe Kapitel 3). Für die einzelnen Meta-Sprachen wurden auf Eclipse basierende Editoren
ausgewählt, da diese ebenfalls auf ECore basierende Meta-Modelle integrieren. Mittels dieser
Gemeinsamkeit in den Toolchains ist es mögliche M2M-Transformationen zu definieren, mit
denen die Modelle zwischen den Toolchains ausgetauscht werden können. Ähnlich wie für die
M2T-Codegenerierung aus den ROS Modellen wurden die Transformationsmechanismen aus dem
Epsilon-Projekt auch für die Umsetzung der M2M-Transformationen verwendet. Das Epsilon-
Projekt hat für die Beschreibung von M2M-Transformationen die Epsilon Transformation Lan-
guage vorgesehen. Die vorherige Spezifikation von Vererbungen in der Meta-Modellbeschreibung
in Kapitel 3.6 erleichtert die Definition der Transformationen.
Wie in Kapitel 3.4 erläutert, bietet sich das BRICS Component Model in seiner aktuellen Version
vor allem für die abstrakte Beschreibung von Capability-Modellen an. Das BCM ist ebenfalls in
der BRIDE-Toolchain integriert, wurde aber im Rahmen des BRICS-Forschungsprojektes vom
Partner KU Leuven entwickelt. Da die Basiskomponenten von BRIDE gemeinsam für die ver-
schiedenen Zielsprachen verwendet werden, ist die BCM-Umgebung auch in der BRIDE-Version
für ROS enthalten.
Das Mapping von Komponenten, Ports und Parametern zu den entsprechenden ROS-Konstrukten
in der Transformationsdefinition kann direkt vorgenommen werden. Während bei der Transfor-
mation aus dem abstrakten Modell in das ROS Capability Modell ROS-spezifische Informationen
fehlen – diese werden im Editor als fehlend gekennzeichnet – können auch bei der Transforma-
tion vom ROS-Modell in das BCM-Modell nicht alle Informationen bereit gestellt werden. Dies
61
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
liegt vor allem daran, dass das BCM die Entwicklungsphasen “Module design + coding” und
“Integration + System Testing” aus der ISO/IEC 12207 nicht unterscheidet. Stattdessen müs-
sen schon bei der Definition einzelner Komponenten systemspezifische Informationen in Form
der sogenannten Connection-Information spezifiziert werden. In der aktuellen Implementation ist
das gelöst, indem ähnlich wie bei der nativen Entwicklung von ROS-Komponenten, die Kom-
position direkt aus dem Namen generiert wird. Der Entwickler muss also ggf. die Komposition
nach der Generierung anpassen. Tabelle 4.2 zeigt die Zuordnung der BCM-Mechanismen zu den
ROS-Mechanismen, wie sie in der M2M-Transformation in BRIDE umgesetzt sind.
Tabelle 4.2: Zuordnung von BCM-Modellierungsmechanismen zu ROS-Modellierungs-
mechanismen
BCM-Mechanismus ROS-Mechanismus
Package Package
Component System
Port (In/Out) Subscriber/Publisher
Connections Topics
Connection properties Nicht vorhanden
Properties Parameter
Als Meta-Sprache, die für alle Entwicklungsphasen High-level Modelle direkt unterstützt, eignet
sich die SysML-Beschreibungssprache. Für diese hat sich die Toolchain Papyrus weit verbreitet,
die auf EMF basierende Editoren für UML und SysML bereitstellt. Dabei werden die verschie-
denen SysML-Diagrammtypen, die den unterschiedlichen Modellierungsaspekten entsprechen,
separat dargestellt. Die Modellinformationen sind zentral als Persistierung in einer UML-Datei
enthalten, was dem SysML-Meta-Modell entspricht. Für die Generierung von ROS Capabilities,
Koordinatoren und Systemen wurden jeweils spezifische M2M-Transformationen definiert. Damit
können die Endnutzer entsprechend ihrer jeweiligen Rolle im Entwicklungsprozess die für ihre Ent-
wicklungsphase interessanten Aspekte importieren oder exportieren. Der SysML-Diagrammtyp
“Internal Block Diagram” wird dabei zum Teil in ein ROS-System Diagramm transformiert, ein
anderer Teil des “Internal Block Diagram” wird zu einem ROS Capability Modell. Der SysML-
Diagrammtyp “StateMachine Diagram” kann in ein Coordinator Modell umgewandelt werden.
Die Zuordnung der Modellierungsmechanismen, wie sie in der M2M-Transformation von SysML
in ROS in BRIDE umgesetzt sind, ist in Tabelle 4.3 dargestellt.
Der Informationsverlust bei der Transformation geht dabei von der abstrakten Modellierung in
SysML in die konkretere in ROS. Nach der Transformation sind die ROS-Modelle noch nicht
vollständig spezifiziert. In den Modelleditoren werden dem Nutzer die noch zu spezifizierenden
Informationen angezeigt und die Modelle werden manuell vervollständigt.
62
4.7 Testing und Validierungstools
Tabelle 4.3: Zuordnung von SysML-Modellierungsmechanismen zu ROS-Modellierungs-
mechanismen
SysML-Mechanismus ROS-Mechanismus
Block Node
StateMachine Smach Node
State Subscriber/Publisher
Transition Topics
4.7 Testing und Validierungstools
Die bisher erstellten Editoren für Komponenten, Systeme und Applikationsmodelle erlauben
den jeweiligen Nutzern zwar alle in den Meta-Modellen existierenden Sprachkonstrukte zur Be-
schreibung zu benutzen, jedoch lassen sie auch nicht erlaubte Eingaben zu. Es ist möglich,
bestimmte Aspekte eines Modelles nur ungenügend zu beschreiben bzw. sich ausschließende
Mechanismen gleichzeitig zu verwenden. Derartige Fehler im Modell können auch bei der manu-
ellen Erstellung von Modellen oder bei fehlerhaftem Parsen des ros_dissect Tools entstehen. Die
Modellierungsfehler fallen in der Regel erst bei der Ausführung der implementierten Transfor-
mationen zu anderen Modellen bzw. in den Quellcodes auf. Da es bei diesen Transformationen
zu recht unterschiedlichen Fehlern durch ungültige Modelle kommen kann, die vom Endnutzer
nur mit Hintergrundwissen über die jeweilige Transformation verstanden werden können, ist eine
Modellvalidierung schon während der Modellierungszeit sinnvoll. Zur Validierung von Modellen
können in EMF einem Modellierungseditor Beschränkungen zugewiesen werden, die während des
Editierungsvorgangs überprüft werden. Diese Beschränkungen werden in der Object Constraint
Language (OCL) beschrieben und wurden in BRIDE für die verschiedenen Editoren umgesetzt.
Die für den Capability Editor definierten OCL-Beschränkungen sind beispielhaft in Tabelle 4.4
dargestellt.
Tabelle 4.4: Auszug der Validierungsregeln des BRIDE Capability Editors
Validierungsregel OCL Domain Element
PackageNameRule name.size() > 0 Package
PackageAuthorRule author.size() > 0 Package
NodeNameRule name.size() > 0 Node
PublisherNameRule name.size() > 0 Publisher
PublisherMsgRule msg.size() > 0 Publisher
SubscriberNameRule name.size() > 0 Subscriber
SubscriberMsgRule msg.size() > 0 Subscriber
63
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
Abbildung 4.12: Screenshot einer laufenden Modellevaluierung in BRIDE
Abbildung 4.13: Quellcode eines autogenerierten Testcases mit blau hinterlegten Nutzermodifi-
kationen
64
4.8 ROS-Integration der Toolchain
Das Validieren des Modelles ist im Falle von BRIDE so umgesetzt, dass durch kontinuierliches
Überprüfen dem Entwickler Fehler während des Modellierens angezeigt werden. So kann gewähr-
leistet werden, dass der Entwickler jederzeit validen Quellcode aus dem Modell generieren kann.
In Abbildung 4.12 ist die Bearbeitung eines fehlerhaften Modells gezeigt. Der Fehler wird dem
Entwickler sowohl grafisch als Overlay über dem Element (hier der “feature_map”-Publisher)
als auch textuell in der Fehlerliste von Eclipse angezeigt.
Selbst nach der erfolgreichen Generierung und des Kompilierens der ROS-Komponenten aus
einem validen Modell können während der weiteren Entwicklung Fehler im Programmcode ent-
stehen. Daher ist das Implementieren weiterer Testfälle mittels Unit-Testing oder dem “rostest”-
Framework notwendig. Das modellbasierte Generieren von Quellcode wird eingesetzt, um den
Entwickler bei der Erstellung von Komponententests zu unterstützen. Daher werden für die ver-
schiedenen Interfaces einer Komponente die Gegenkomponenten automatisiert in einem Test-
ordner generiert. Zum Beispiel wird bei der Definition eines ActionServers in der Komponente
automatisiert ein entsprechender ActionClient als Testcase erzeugt. Die Daten, die als Test-
fall der Kommunikationsschnittstelle übergeben werden, können vom Entwickler als Yaml-Files
konfiguriert werden. Anschließend kann mit “rostest” ein Komponententest ausgeführt werden.
Somit ist mit BRIDE das Erzeugen von Komponententests ein Konfigurieren der Testkomponen-
ten ohne tatsächliche Entwicklungsschritte. In Abbildung 4.13 ist ein Beispiel einer generierten
Testkomponente dargestellt. Die entsprechenden Konfigurationsstellen sind in der Abbildung
blau hervorgehoben.
4.8 ROS-Integration der Toolchain
Ein wichtiger Aspekt für die Effektivität von modellbasierter Entwicklung ist die breite Verfügbar-
keit von Modellen und die Unterstützung einer Vielzahl von Nutzungsfällen. Daher ist eine starke
Verbreitung der hier vorgestellten modellbasierten Entwicklungsumgebung wünschenswert.
Ein Grund für den Erfolg von ROS in der Robotik ist die Unterstützung vieler verschiede-
ner Entwicklungsstile durch den Einsatz von einfachen Konsolenwerkzeugen. Daher wurde in
dieser Arbeit zusätzlich zu den grafischen Tools innerhalb der Eclipseumgebung eine Konso-
lenintegration erstellt. Diese bietet die die Funktionalität von BRIDE und wird im ROS-Paket
bride_compilers ausgeliefert. Somit ist möglich, über verbreitete Texteditoren, z.B. VIM, die Mo-
delle manuell zu modifizieren (siehe Abbildung 4.14). Ein eigenständiger Kompiler führt dann
die M2T-Transformation aus. Der Kompiler kann flexibel für verschiedene Projekte und Mo-
delle genutzt werden und unterstützt die Generierung von ROS Komponenten, Systemen und
Koordinatoren:
rosrun bride_compilers m2t o brics_test [p brics_test] model/brics_test.ros_package
65
4 Umsetzung einer Entwicklungsumgebung für mobile Manipulatoren
Abbildung 4.14: Textuelles Erstellen von Modellen über eine Netzwerkverbindung mit dem Editor
VIM
Bei der Codegenerierung wird automatisch ein Makefile target erzeugt, der den Compiler ent-
sprechend des Projektes konfiguriert. Nach einer Änderung am Modell kann somit durch ein
einfaches
make regen
der Quellcode aktualisiert werden.
Zusätzlich zur Konsolenintegration wurden die Quellcodetemplates, die zur Erzeugung der ROS
Komponenten, Systeme und Koordinatoren verwendet werden aus der Eclipse Toolchain heraus-
gelöst und in ein separates ROS-Package ausgelagert, das bride_templates Paket. Dadurch ist
es ROS-Entwicklern möglich, sich an der Kommunikation und Erweiterung der Templates zu
beteiligen, ohne sich in die Eclipse-basierte Entwicklung einzuarbeiten.
In den letzten Jahren wurden vor allem innerhalb der Build-Infrastruktur von ROS von Version
zu Version viele Änderungen vorgenommen. Beispielsweise wurde im Jahr 2012 das System
zum Kompilieren von Komponenten von rosbuild auf catkin umgestellt. Der Wechsel von einer
ROS-Version auf eine neuere ist für viele Paketentwickler mit einem großen Aufwand verbunden.
Durch die Unterstützung von mehreren ROS-Versionen in den Templates von BRIDE kann dieser
Wechsel von ROS-Versionen stark automatisiert werden und erzeugt damit einen weiteren Vorteil
für ROS-Entwickler.
Damit auch Nicht-Entwickler einen einfachen Zugang zur BRIDE-Toolchain haben, werden zu-
sätzlich zum öffentlich zugänglichen Versionsmanagement regelmäßig Softwareversionen inte-
griert und in der Community kommuniziert. Zudem wird regelmäßig eine Übersicht über die
66
4.8 ROS-Integration der Toolchain
Abbildung 4.15: Wikiseite des BRIDE-Projekts mit Dokumentation, Tutorials und Verknüpfung
zu anderen ROS-Projekten
aktuellen Änderungen sowie Anpassungen der Dokumentation veröffentlicht. Zusätzlich wurde
auf dem Community-Wiki unter http://ros.org/wiki/bride eine ausführliche Dokumentation der
Konzepte von BRIDE, sowie basierend auf den Case Studies in Kapitel 5, eine Vielzahl von Tu-
torials erstellt, die von Anfängern bis ROS-Experten einer breiten Benutzergruppe den Einstieg
in die modellbasierte Entwicklung erleichtern (siehe Abbildung 4.15).
67

5 Case Studies zur modellbasierten
Entwicklung in der Robotik
Im folgenden Kapitel sollen drei Beispiele der Anwendungsentwicklung in der Robotik erläutert
werden, die mit BRIDE umgesetzt wurden. Dabei steigt von Anwendung zu Anwendung die
Komplexität des Systems bis hin zu einem vollständig integrierten mobilen Manipulator. Durch
die unterschiedlichen Komplexitätsstufen können unterschiedliche Aspekte des im Rahmen dieser
Arbeit entwickelten modellbasierten Ansatzes mit Bezug auf die formulierten Entwicklungsziele
aufgezeigt werden. Des Weiteren kommen die hier gezeigten Beispiele aus unterschiedlichen
Anwendungsbereichen der Robotik.
Während der erste Anwendungsfall, der BRICS Showcase Industry, vor allem auf die Komponen-
tenentwicklung im Einzelnen eingeht, werden in der Anwendung beim SyncMM Framework vor
allem die Flexibilität des Ansatzes durch die Transformation in andere Frameworks dargestellt.
Die Logistikanwendung des rob@work 3 stellt letztendlich ein sehr komplexes System dar, wel-
ches die verschiedenen Rollenmodelle und die Integration von bestehenden, nicht-modellierten
Subsystemen erforderlich macht und damit hohe Ansprüche an die Systemkomposition und An-
wendungsentwicklung stellt.
5.1 BRICS Showcase Industry
Wie schon in Kapitel 2 erläutert, werden bei heutigen, im industriellen Einsatz befindlichen mobi-
len Manipulatoren die Mobilität und die Manipulation getrennt voneinander betrieben. Bezüglich
der Manipulation werden die Arme in der Regel durch eine Objekterkennung unterstützt, um die
Unsicherheiten in der Lokalisierung der Plattform auszugleichen. Die Manipulation kann sonst
ohne Einbeziehen der Mobilität betrachtet werden.
Als erste Beispielanwendung wird solch ein einfaches System ohne Mobilität mit dem modellba-
sierten Ansatz umgesetzt. Dabei wird ein Demonstrator aus dem EU-Projekt BRICS verwendet,
der Showcase Industry, der aus einem KUKA KR16 Manipulator, einem Sauggreifer sowie einem
Cognex Objekterkennungssystem besteht.
69
5 Case Studies zur modellbasierten Entwicklung in der Robotik
Ziel der Roboteranwendung ist es, mit einem Sauggreifer Kunststoffboxen von einer Platte, die
die Ausgabestation einer Bearbeitungsmachine darstellt, in eine Transportbox zu bewegen. Die
Boxen können dabei an beliebiger Stelle auf der Übergabeplatte stehen. In Abbildung 5.1 ist
die graue Box auf der schwarzen Platte im linken Bereich zu sehen. Die Ablagebox ist blau und
befindet sich nahe der Bildmitte.
Abbildung 5.1: BRICS Showcase Industry Demonstrator
5.1.1 Umsetzung mit BRIDE
Da die Anwendung aus wenigen Komponenten besteht, wird im Entwicklungsprozess die “High
level design”-Phase überschritten und direkt mit der “Module-design + Coding”-Phase begonnen
(siehe Kapitel 3.3). Hierbei werden in der Rolle des “Capability Developers” für die einzelnen
Hardwarekomponenten des Systems jeweils auch Softwarekomponenten, die Treiber, modelliert:
• KUKA-Manipulator: Zur Ansteuerung des KUKA-Arms wird eine Netzwerkschnittstel-
le zur KUKA-Steuerungsbox hergestellt. Dafür wird das von KUKA vorgesehene “KU-
KA.Ethernet KRL XML” verwendet. Die Komponente cob_kuka_xmlkrc setzt diese Schnitt-
stelle um und bietet eine kartesische Schnittstelle, um Bewegungen mit dem Roboterarm
durchzuführen.
• Cognex SmartCam: Für die Bildverarbeitung in der Anwendung wird eine Cognex Smart-
Cam verwendet, die für verschiedene Bildverarbeitungsalgorithmen konfiguriert werden
kann. Die Resultate sind über eine telnet-Netzwerkschnittstelle abrufbar. Die Komponente
brics_cognex_insight setzt diese Schnittstelle um und ist für verschiedene Bildverarbei-
tungsergebnisse konfigurierbar. Die Ergebnisse, die als Koordinaten im Kamerakoordina-
tensystem vorliegen, werden über eine asynchrone Schnittstelle ausgegeben.
70
5.1 BRICS Showcase Industry
• Sauggreifer: Da der Sauggreifer über die I/O-Schnittstelle der KUKA-Steuerungsbox
betrieben wird, ist kein weiterer Treiber notwendig. Vielmehr wurde die cob_kuka_xmlkrc-
Komponente um eine Schnittstelle zur Greiferansteuerung erweitert.
(a) cob_kuka_xmlkrc (b) brics_cognex_insight
(c) brics_showcase_industry_transformer (d) brics_showcase_industry_worldmodel
Abbildung 5.2: Modelle verschiedener Komponenten aus dem BRICS Showcase Industry
Weiterhin werden als Funktionalitäten, immer noch aus Sicht der “Capability Developer”-Rolle,
eine Komponente zur Transformation von Koordinatensystemen sowie ein sehr einfaches Welt-
modell zur Speicherung der Boxpositionen benötigt:
• Transformer: Zur Berechnung der Objektkoordinaten im Weltkoodinatensystem (in die-
sem Fall die Basis des KUKA-Manipulators) hat diese Komponente, die im Softwarepaket
brics_showcase_industry_transformer implementiert ist, einen asynchronen Eingang. Über
eine konfigurierbare Koordinatentransformation sowie die konfigurierbare Transformation
von Pixel- in metrische Koordinaten werden die Objektkoordinaten berechnet und über
einen Service in das Weltmodell übertragen.
71
5 Case Studies zur modellbasierten Entwicklung in der Robotik
• Weltmodell: Das Weltmodell, umgesetzt im Paket brics_showcase_industry_worldmodel,
ist eine einfache Speicherkomponente, die einen Service zum Senden und einen Service zum
Abrufen umsetzt. Über die Zeitstempel der Informationen wird deren Aktualität überprüft.
Zusätzlich zur Entwicklung der einzelnen Komponenten in BRIDE muss die Applikationsentwick-
lung durchgeführt werden. Da dies eine andere Entwicklungsrolle darstellt und daher vollständig
separiert von der Komponentenentwicklung ist, kann das Entwickeln der Anwendung parallel
oder sequenziell passieren. Für das System werden zwei hardwareabhängige Primitives als Ap-
plikationsbausteine umgesetzt:
• PickUp-Primitive: Nachdem der Koordinator mittels eines ServiceState die Objektpo-
sition aus dem Weltmodell ausgelesen hat, benutzt er die Action-Schnittstellen des Ma-
nipulators, um über das Objekt zu fahren, den Greifer abzusenken und den Greifer zu
schließen.
• DropDown-Primitive:Mit den selben Schnittstellen wie schon die PickUp-Primitive setzt
der Manipulator das Objekt an einer konfigurierbaren Stelle ab.
Abbildung 5.3: Application-Modell des BRICS Showcase Industry
72
5.1 BRICS Showcase Industry
Die Anwendung benutzt die plattform-unabhängigen Schnittstellen der Primitives, um die Pick-
and-Place Gesamtanwendung zu implementieren. Dabei wird wieder eine Coordinatorkomponen-
te modelliert. Die plattform-unabhängige Applikation kann später leicht wiederverwendet wer-
den. Nach Hinzufügen des brics_showcase_industry_primitives-Paketes zur Applikation stehen
in den einzelnen ActionStates der Komponente die PickUp- und DropDown-Action-Spezifikation
zur Verfügung. Abbildung 5.3 zeigt die modellierten Primitives “PickUp” und DropDown“ (in
der Grafik ”coordinator_pickup“ und ”coordinator_drop“) sowie die Gesamtapplikation (in der
Grafik ”coordinator_application”) durch Screenshots aus BRIDE für das Beispiel. Die einzelnen
States sind durch rechteckige Elemente dargestellt und werden entsprechend der Statemachine-
Logik verbunden.
Nachdem die einzelnen Capabilities und Coordinators entworfen und implementiert wurden, kann
das Gesamtsystem modelliert werden. Diese “System-Deployment”-Rolle ist zwar vom Ergebnis
der beiden anderen Rollen abhängig, wird aber getrennt von ihnen durchgeführt. Hierzu werden
die einzelnen Komponenten und Koordinatoren zum System hinzugefügt und miteinander durch
Topics, Services und Actions verbunden. Das fertig modellierte System ist in Abbildung 5.4 zu
sehen.
Tests im Rahmen der Projektpräsentation des Projektes BRICS haben gezeigt, dass das ent-
standene System die spezifierte Zielaufgabe wie gewünscht durchführen kann. Durch die klare
Trennung der Rollen sowie der Konfigurationsaspekte konnte die Anwendung zudem auch nach
dem Projekt von den Entwicklern für andere Umgebungssetups bei unterschiedlichen Demons-
trationen angepasst werden.
73
5 Case Studies zur modellbasierten Entwicklung in der Robotik
Ab
bil
du
ng
 5
.4:
 S
ys
tem
-M
od
ell
 d
es
 B
RI
CS
 S
ho
wc
as
e I
nd
us
try
74
5.2 Regelungs-Framework für synchrone mobile Manipulation
5.2 Regelungs-Framework für synchrone mobile
Manipulation
Die Kombination von Mobilität und Manipulation stellt nicht nur auf Applikationsebene ei-
ne Komplexitätssteigerung dar. Auch auf der regelungstechnischen Ebene werden die Systeme
komplizierter. Für die gemeinsame Regelung von Plattform und Manipulator kommen in der Pra-
xis außer der höheren Anzahl von Aktoren und Sensoren ggf. auch die Nutzung verschiedener
Bussysteme, Verteilung auf verschiedene Rechner und Echtzeit-Anforderungen hinzu.
Daher soll im Folgenden die Nutzung der modellbasierten Toolchain für die Entwicklung eines
synchronen Kinematikreglers für einen mobilen Manipulator analysiert werden. Neben verschie-
denen Ansätzen für die synchrone Regelung von mobilen Manipulatoren wird in diesem Abschnitt
konkret auf das SyncMM-Framework (Bubeck, Connette et al. 2012) eingegangen, das für den
Care-O-bot® 3 entwickelt wurde.
In der ursprünglichen Version wurde das SyncMM-Framework als eine Sammlung verschiedener
ROS Nodes umgesetzt, damit die Integration in die bestehenden Treiberschnittstellen des Care-
O-bot® 3 möglich war. Für die prototypischen Anwendungen auf dem Care-O-bot® 3 war dies
ausreichend und eine Portierung auf ein echtzeitfähiges Framework, z.B. OROCOS RTT, wurde
wegen des hohen Aufwands nicht durchgeführt. Die Umsetzung des SyncMM-Frameworks mit
BRIDE kann durch die entstehende Portierbarkeit eine effektive Möglichkeit zur echtzeitfähigen
Umsetzung sein.
Auch unter ROS war die Nutzung des SyncMM-Frameworks nur durch Experten möglich. Der
Grund hierfür liegt in der teilweise komplexen Parametrierung direkt in den Komponenten. Dies
erfordert großes Detailwissen über die Algorithmen bei der Einrichtung des Systems. Des Wei-
teren enthält das SyncMM-Framework sehr viele Kommunikationsschnittstellen, die eine hohe
Abhängigkeit der Komponenten untereinander erzeugen. Eine Änderung an einer Schnittstel-
le hat damit einen starken Einfluss auf die Systemintegration. Dies ist vor allem während der
Entwicklung des Systems ein Problem.
5.2.1 Überarbeitung von SyncMM mit BRIDE
Das SyncMM-Framework ist als ein modulares System konzipiert, um mit verschiedenen Robo-
terkonfigurationen und mit verschiedenen Einsatzszenarien kombinierbar zu sein. Daher ist das
Regelungssystem mit einer kaskadierten Reglerstruktur entworfen worden. Es gibt im SyncMM-
Framework jeweils einen getrennten Regelkreis für die mobile Plattform und den Manipulator.
Diese Regelkreise werden mit einem gemeinsamen synchronen Regler überlagert. Der gemeinsa-
me Regler wird mit Modulen zur Trajektorienkommandierung und mit Modulen zur Umsetzung
von Bewegungseinschränkungen verknüpft. Eine abstrakte Übersicht des SyncMM-Frameworks
ist in Abbildung 5.5 zu sehen.
75
5 Case Studies zur modellbasierten Entwicklung in der Robotik
Abbildung 5.5: Abstrakter Aufbau des SyncMM-Systems
Für die Ansteuerung der mobilen Plattformen des rob@work 3 und Care-O-bot® 3 werden zur
Nutzung des SyncMM-Frameworks folgende Schnittstellen umgesetzt:
• cob_base_drive_chain Treiber für die Kommunikation mit den 8 Antriebsmodulen über
die vorhandene CAN Schnittstelle.
• cob_undercarriage_ctrl: Modul, das die kartesische Regelung der Plattformen um-
setzt. Es unterstützt die verschiedenen Antriebskonfigurationen von Care-O-bot® 3 und
rob@work 3.
Im Gegensatz zur mobilen Plattform werden die mit SyncMM eingesetzten Manipulatoren bereits
mit Regelungsmodulen ausgeliefert. Es genügt daher, für die verschiedenen Manipulatoren ein
Modul zur Kommunikation von Sollgeschwindigkeiten an den internen Regler der Manipulatoren
vorzusehen. Dies ist im Fall von SyncMM die Komponente cob_lbr für den Einsatz des KUKA
LBR4 und die Komponente ur5_driver für den Einsatz mit dem UniversalRobot UR5 als Arm.
Diese Basis-Komponenten wurden als modellbasierte Komponenten umgesetzt. Dazu wurden
Komponentenmodelle für die verschiedenen Module anhand der existierenden Treiber erstellt und
anschließend der Quellcode für die ROS-unabhängige Umsetzung an den generierten Quellcode
angepasst. Die ursprünglichen Parameter der Module, die, da von verschiedenen Entwicklern
programmiert, durch unterschiedliche Verfahren integriert waren, wurden nun einheitlich im
Modell angegeben, um später während des “System deployment”-Schrittes oder zur Laufzeit
anpassbar zu sein.
• cob_config_controller: Basierend auf den durch die Basis-Komponenten vorgegebe-
nen Schnittstellen setzt diese Komponente den synchronen Regler von Manipulator und
Plattform um.
76
5.2 Regelungs-Framework für synchrone mobile Manipulation
Für die durch die Hardware-Module bereitgestellte Kinematik wird eine Konfiguration angelegt,
auf deren Basis eine Vorwärtskinematik generiert wird. Aus dieser kann wiederum die Jacobima-
trix des Systems generiert werden, die zur Regelung verwendet wird. Die Kinematik der Basis
kann dabei auf den kartesischen Raum vereinbart werden, da Beschränkungen, beispielsweise
nicht-holonome Bindungen, bereits im Plattformregelkreis aufgelöst werden können (siehe (Con-
nette, Hofmeister et al. 2010)). Der eingesetzte Regelungsalgorithmus wird damit unabhängig
von der Plattformkinematik und kann auch auf differentiellen Kinematiken eingesetzt werden,
wie beispielsweise auf der ImRoNet-Forschungsplattform (Pfeiffer, Bengel et al. 2011) gezeigt.
Der eingesetzte Regler ist eine Umsetzung des “Configuration Control”-Ansatzes aus (Nassal
1994) (siehe Kapitel 2), der für eine kartesische Eingangsgeschwindigkeit ein redundantes Sys-
tem regelt. Zusätzlich zu der Inversion der Systemjacobimatrix werden Tasks definiert, die die
Redundanz des Systems nutzen, um zusätzliche Bewegungseinschränkungen zu gewährleisten.
Diese können zum einen Einschränkungen des Arbeitsraums der Plattform sein, beispielsweise
durch Hindernisse, zum anderen kann der Arbeitsraum des Manipulators, zum Beispiel durch
Gelenkwinkelbegrenzungen, eingeschränkt sein. Beide Tasks sind direkt in der Berechnung der
Inversen Kinematik während des Regelungsschrittes integriert, werden aber durch separate Cons-
traint Module zur Laufzeit konfiguriert. Dadurch ist es möglich, je nach Anwendungsfall, die
Bewegungseinschränkungen aus unterschiedlichen Sensorquellen zu erzeugen.
Die kartesischen Eingangsgeschwindigkeiten in den synchronen Systemreglern können aus un-
terschiedlichen Quellen kommen. Auch dies ist vom Anwendungsfall abhängig. Neben Joystick-
Kommandos oder einer zusätzlichen Visual-Servoing-Reglerschleife bietet die cob_trajacetories-
Komponente Möglichkeiten, Linear- und Kreistrajektorien zu generieren und anlaufen zu lassen.
Trajektorien können, beispielsweise mit einem Joystick, eingelernt und später wieder komman-
diert werden.
Aufbauend auf den vorhandenen Komponenten des SyncMM-Frameworks kann ein Systemmodell
in BRIDE erstellt werden. Dabei werden nicht nur die einzelnen Komponenten miteinander
verknüpft, auch wird einheitlich die Konfiguration für den Anwendungsfall durchgeführt. Die
Komponenten für beispielsweise die Manipulatoren können nach der Modellierung durch die
gleichen Schnittstellen leicht ausgetauscht werden. Gleiches gilt für die Plattform-Module. In
Abbildung 5.6 ist das fertig modellierte System für einen Anwendungsfall mit dem Care-O-bot®
3 zu sehen.
Das entstandene SyncMM-System stellt damit ein Subsystem dar, das in andere Anwendungen
integriert werden kann. Dabei stellt das Framework mit der “SyncMMAction” und der “Articula-
tionModelAction” Schnittstellen zur Verfügung, die bei der Erstellung von Koordinatormodellen
verwendet werden können. Es können entweder Livedaten von Eingabegeräten oder die Parame-
trierung von manipulierbaren Objekten dem Framework übergeben werden.
Im Rahmen verschiedener Demonstrationen mit dem Care-O-bot® 3 wurde das Framework zum
Öffnen von Türen eingesetzt. Da die Trajektorie während des Öffnens den Arbeitsraum des Ma-
77
5 Case Studies zur modellbasierten Entwicklung in der Robotik
Ab
bil
du
ng
 5
.6:
 S
ys
tem
mo
de
ll d
er 
mo
de
llb
as
ier
ten
 U
ms
etz
un
g 
de
s S
yn
cM
M
-F
ram
ew
or
ks
78
5.2 Regelungs-Framework für synchrone mobile Manipulation
nipulators überschritt, musste die Plattform mitbewegt werden, so dass eine synchrone mobile
Manipulation erforderlich war. Die Kreistrajektorien wurden dabei von dem oben beschriebenen
Modul erzeugt. Der Einsatz von Impedanzreglern, die direkt in der Manipulatorregelung vor-
handen waren, machte es möglich, das System ohne Betrachtung von Echtzeit-Anforderungen
zu verwenden. Eventuelle Trajektorienfehler wurden durch die Impedanzregelung ausgeglichen.
Abbildung 5.7 zeigt den Care-O-bot® 3 mit aktivem SyncMM-Framework beim Öffnen einer
Schranktür.
Abbildung 5.7: SyncMM-System im Einsatz auf dem Care-O-bot® 3
5.2.2 Transfer zu OROCOS RTT
Für den Einsatz des SyncMM-Systems in industriellen Szenarien ist jedoch eine echtzeitfähi-
ge Umsetzung der Komponenten erforderlich. Statt die einzelnen Komponenten in ein neues
Framework zu portieren, kann in diesem Fall die M2T-Transformation von BRIDE verwen-
det werden, um die Komponentenimplementationen für die echtzeitfähige Toolchain OROCOS
RTT zu generieren. Für die SyncMM-Module cob_config_controller, cob_base_drive_chain und
cob_undercarriage_ctrl war dies möglich und wurde durchgeführt. Die Manipulatorkomponente
muss im Falle des KUKA LBR in Java umgesetzt werden und konnte somit nicht portiert werden.
Da die Komponentenmodelle von OROCOS und ROS sich sehr stark gleichen, muss nur für den
Fall, dass inkompatible Mechanismen wie ROS-Services verwendet werden, manueller Aufwand
investiert werden. Im Falle der drei SyncMM-Komponenten war dies nicht der Fall.
Das automatische Generieren der Deployment-Konfiguration für OROCOS RTT vereinfacht
ebenfalls die Integration in das bestehende BRIDE-Systemmodell. Die Schnittstellen zu den
nicht-OROCOS RTT-Komponenten sind durch die entsprechende Konfiguration auf OROCOS-
Seite äquivalent zum ROS System vorhanden und können in diesem hybriden Systemmodell
79
5 Case Studies zur modellbasierten Entwicklung in der Robotik
genutzt werden. Die echtzeitfähige Kommunikation der einzelnen OROCOS-Komponenten mit-
einander muss vom Nutzer manuell an den entsprechenden Stellen der OROCOS-Konfiguration
vorgenommen werden.
Das Verhalten des entstandenen hybriden Systems entsprach bei Tests dem Verhalten des reinen
ROS-Systems. Der zusätzliche Determinismus der echtzeitfähigen Kommunikation war wunsch-
gemäß gegeben.
5.3 Logistikszenario mit der Plattform rob@work 3
Nachdem dargestellt wurde wie einfache klassische Manipulationssysteme mit BRIDE erstellt
werden können und ein synchroner mobiler Manipulationsansatz modellbasiert entwickelt wur-
de, soll nun eine vollständige Anwendung, die Mobilität und Manipulation verknüpft, umgesetzt
werden. Die im Folgenden vorgestellte Applikation stellt einen hohen Komplexitätsgrad sowohl
bezüglich der auszuführenden Fähigkeiten als auch der Integration des Robotersystems dar.
Trotzdem kann durch klare Trennung der Nutzerrollen während des Entwicklungsprozesses und
durch Wiederverwendung von Softwarekomponenten der Aufwand der eigentlichen Anwendungs-
entwicklung minimiert werden.
Bei dieser Anwendung müssen im Rahmen einer Intralogistikinstallation Boxen aus Regalen ge-
griffen und in ein anderes Lager gebracht werden. Die Anwendung verknüpft damit Navigations-,
Wahrnehmungs- und Manipulationsfunktionen auf der mobile Manipulatorplattform rob@work
3. Ziel ist es, dass die Anwendung auch von weniger qualifizierten Nutzern konfiguriert und
verknüpft werden kann und somit leicht für verschiedene ähnliche Anwendungsszenarien portiert
werden kann.
5.3.1 Anwendungsentwicklung mit BRIDE
Zur Navigation des rob@work 3 in der Szenarioumgebung wird die auf Laserscannern basierte
IPA-Navigation eingesetzt. Die Lokalisierung der Navigation wurde vollständig modellbasiert mit
Hilfe von BRIDE entwickelt. Entsprechend der in Abbildung 5.8 dargestellten Lokalisierungsar-
chitektur wurden folgende Komponenten umgesetzt:
• ipa_loc_laser_extract: Diese Komponente wurde auf Basis eines standardisierten Mo-
dells für Messgrößenquellen generiert und für die Daten des Sick S300 umgesetzt. Aus den
Laserscans werden Liniensegmente sowie Lasermarker extrahiert und als Features weiter-
gegeben.
• ipa_loc_feature_map ist ebenfalls nach einem Standardmodell umgesetzt und lädt die
für die Umgebung erstellten Karteninformationen. Auch die in den Karten enthaltenen
Linien und Punkte werden als Features weitergegeben.
80
5.3 Logistikszenario mit der Plattform rob@work 3
• ipa_loc_feature_association und ipa_loc_ekf setzen die eigentliche Lokalisierung
um. Die gemessenen und kartierten Features gehen in die Komponenten ein und wer-
den miteinander assoziiert. Mittels eines extended Kalmanfilters werden dann diese As-
soziationen mit den Odometriedaten genutzt, um die Position des Roboters im Raum zu
bestimmen.
Abbildung 5.8: Architekturbild der IPA-Navigation
Durch die Modellierung der Parameter in BRIDE ist die Konfiguration der Lokalisierung zur
Laufzeit möglich. Nach Spezifizierung und Modellierung wurden die einzelnen Komponenten
von den entsprechenden Navigationsexperten unabhängig erstellt. Für die reaktive Pfadplanung
in der Anwendung wird die in ROS vorhandene move_base-Navigation verwendet. Diese wurde
im Rahmen der Systemintegration in BRIDE modelliert und als proprietäre Komponente dem
Gesamtsystem hinzugefügt.
Für die Manipulationsplanung innerhalb des Szenarios wird das Manipulationsframework MoveIt!
verwendet. Dieses ist zwar das verbreitetste Framework in der ROS-Community, hat jedoch
eine interne Softwarearchitektur, die nicht direkt auf ROS übertragbar ist. Stattdessen stehen
die funktionalen Schnittstellen des Frameworks über ROS-Mechanismen zur Verfügung. Aus
diesem Grund wurden für die Manipulation im Szenario die Komponenten nachmodelliert und
als proprietäre Komponenten verwendet. Für die Manipulation wurden folgende Komponenten
verwendet:
• move_group: Kernkomponente für die Manipulationsplanung. Enthält Schnittstellen für
das Hinzufügen von Umgebungsmodellen und zum Abfragen von kinematischen Berech-
nungen oder Plänen.
• primitive_server: Abstraktion der Planungsschnittstellen von move_group. Viele Pla-
nungsdetails, wie beispielsweise die kinematischen Ketten, werden innerhalb dieser Kom-
ponente für den Roboter konfiguriert. Für die Anwendungsentwicklung reduzieren sich
damit die benötigten Informationen zur Ansteuerung der Planung.
• ur_driver: Treibermodul zur Ansteuerung des universal robot UR10-Manipulators, der auf
dem Roboter genutzt wurde. Enthält die von move_group erforderlichen ROS-Schnittstellen
zur Ausführung der geplanten Trajektorien.
81
5 Case Studies zur modellbasierten Entwicklung in der Robotik
Abbildung 5.9: Coordinator-Modell für die beschriebene Logistikanwendung
82
5.3 Logistikszenario mit der Plattform rob@work 3
Aufgrund der Dynamik des Szenarios und der gewollten Flexibilität werden die zu greifenden
Boxen zur Laufzeit dynamisch erkannt. Hierzu wurde eine Erkennung umgesetzt, die auf den
Boxen aufgeklebte QR-Code-Marker einliest und lokalisiert. Dadurch ist die Identifikation und
die Lokalisierung der Boxen zeitgleich möglich. Während für den Kameratreiber auch hier wie-
der eine bestehende Komponente aus der ROS-Community direkt als propietäre Komponente
nachmodelliert wurde, ist für den Erkennungsalgorithmus ein Bildverarbeitungsexperte hinzuge-
zogen worden. Dieser hat mittels BRIDE die Komponente cob_marker umgesetzt. Dazu wurde
die Komponente vollständig in BRIDE überarbeitet, um die Schnittstellenspezifikation sowie die
Parametrierung automatisiert zu generieren.
Die beschriebenen Einzelkomponenten sowie die in den anderen Cases erstellten Treiber stellen
alle für die Logistikanwendung erforderlichen Funktionalitäten zur Verfügung. Für den konkre-
ten Anwendungsfall wurde daher mittels des Coordinator Developers eine Anwendung erstellt
(siehe Abbildung 5.9). Die Trennung von Konfiguration und Koordination auch im Coordinator
Editor ermöglichte eine spätere Anpassung der einzelnen Arm- und Plattformbewegungen zur
Laufzeit beim Installieren der Anwendung. So ist in der Abbildung im rechten Anwendungsfens-
ter erkennbar, dass für den Zustand “MoveLinGrasp” die entsprechende Zielkonfiguration für
die Linearbewegung als Konfigurationsfile generiert wurde. Der Anwendungsentwickler kann nun
manuell oder mit Zuhilfenahme externer Werkzeuge diese anwendungsspezifische Konfiguration
getrennt von allen anderen Softwareaspekten vornehmen.
￿Parallel zur Anwendungsentwicklung wurden die Komponenten sowie die Koordinationskom-
ponente mittels des System Editors zu einem ROS-System kombiniert. Das entstandene Sys-
temmodell besteht aus 13 Einzelkomponenten. Nachdem alle Entwicklungsschritte durchlaufen
wurden, konnte die Anwendung zur Demonstration des Robotersystems auf Messen und Ver-
anstaltungen fertiggestellt werden. Abbildung 5.10 zeigt den mobilen Manipulator während der
Ausführung des Szenarios.
Durch die modellbasierte Erstellung der Anwendung war es möglich, verschiedene Installatio-
nen mit unterschiedlichen Umgebungen und Abläufen mit geringem Aufwand umzusetzen. Beim
Wechsel zwischen den Szenarien war eine Mithilfe der Experten, die die Einzelkomponenten
erstellt hatten, nicht erforderlich. Der Gesamtentwicklungsaufwand wurde zudem durch die In-
tegration von proprietären, schon vorhandenen, ROS-Komponenten gesenkt.
83
5 Case Studies zur modellbasierten Entwicklung in der Robotik
Abbildung 5.10: Ausführung des Beispiels einer Logistikanwendung mit dem rob@work 3
5.4 Zusammenfassung der Case Studies
Die drei vorgestellten Beispiele zeigen das Entwickeln von verschiedenen Roboteranwendun-
gen mit BRIDE. Dabei konnten alle in Kapitel 3 erarbeiteten Nutzerrollen separat dargestellt
werden. Zudem wurde die Toolchain flexibel in Bezug auf die eingesetzten Systeme, Anwendun-
gen und Zielframeworks eingesetzt. Durch die Möglichkeit, bestehende ROS-Komponenten und
Subsysteme ohne Refactoring, sondern durch Nachmodellierung zu verwenden, ist eine deutliche
Effizienzsteigerung bei der Entwicklung festzustellen.
84
6 Evaluation von modellbasierter
Entwicklung in der Robotik
Nachdem die Nutzung von modellbasierter Entwicklung in Anwendungsfällen unterschiedlicher
Komplexität im letzten Abschnitt detailliert beschrieben wurde, werden die entstandenen Soft-
wareartefakte nun bezüglich der eingangs beschriebenen Ziele von modellbasierter Entwicklung
untersucht. Im Folgenden wird von den einzelnen Komponenten und Anwendungen eine quanti-
tative Auswertung durchgeführt.
Die Tatsache, dass die modellbasierte Entwicklungsumgebung bereits für viele verschiedene Ro-
boterentwicklungen auch außerhalb der Case Studies verwendet wird, soll zudem genutzt werden,
um in Form einer qualitativen Befragung der Entwickler Rückschlüsse auf eine mögliche Verbes-
serung entsprechend der Ziele dieser Arbeit im Entwicklungsprozess zu erlangen.
6.1 Auswertung der umgesetzten Komponentenmodelle
Im Rahmen der dargestellten Case Studies wurden verschiedene Komponenten für die Appli-
kation entwickelt, überarbeitet oder als proprietäre Komponenten genutzt. In Tabelle 6.1 sind
die einzelnen Komponenten und deren Eigenschaften aufgelistet. Entsprechend der dargestellten
Eigenschaften kommen die Komponenten für die Anwendung von unterschiedlichen Metriken in
Frage. Dabei sind die jeweils genutzte Programmiersprache und die Portierung zu OROCOS RTT
hervorgehoben. Es wurde nicht für alle Komponenten die modellbasierte Entwicklung genutzt,
wenn die Komponenten bereits vorhanden waren.
Wie in Kapitel 3 erläutert, sind Ziele von modellbasierter Entwicklung bei der Komponenten-
entwicklung, den Aufwand bei der Entwicklung zu senken sowie die Wiederverwendbarkeit von
Komponenten zu erhöhen. Im Folgenden werden verschiedene Metriken auf die in C++ um-
gesetzten Komponenten angewandt, um das Erreichen dieser Ziele zu verifizieren. Für die in
Python entwickelten Komponenten wurde auf die Anwendung der Metriken verzichtet, da diese
in den Case Studies nur in geringer Anzahl vorhanden waren und ein direkter Vergleich zu den für
C++ ermittelten Metriken auf Grund der Unterschiede der Programmiersprachen nicht möglich
ist. Im Falle der vier überarbeiteten Komponenten ist jedoch ein Vergleich zu den ursprünglichen
Implementierungen möglich.
85
6 Evaluation von modellbasierter Entwicklung in der Robotik
Ta
be
lle
 6
.1:
 L
ist
e d
er 
in 
de
n 
Ca
se
 S
tu
die
s e
nt
sta
nd
en
en
 K
om
po
ne
nt
en
Pr
og
ra
m
m
ier
￿sp
ra
ch
e R
ef
ac
to
re
d E
nt
wi
ck
lu
ng
sm
et
ho
de
 P
or
tie
rt 
zu
 O
RO
CO
S
ne
in
ne
in
ne
in
ne
in
ne
in
ne
in
RO
S 
Ko
m
po
ne
nt
e 
co
b_
ku
ka
_x
ml
rp
c 
co
gn
ex
_i
ns
igh
t 
br
ics
_p
os
e_
tra
ns
for
me
r 
br
ics
_w
or
ld_
mo
de
l
C+
+ 
Py
th
on
 
Py
th
on
 
Py
th
on
ne
in
ne
in
co
b_
ca
rte
sia
n_
tra
jec
to
rie
s 
C+
+
ja
ne
in
co
b_
co
nf
ig_
co
nt
ro
lle
r
C+
+
ja
ja
JA
VA
ne
in
ne
in
C+
+
ja
ja
C+
+
ja
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t
ja
Py
th
on
ne
in
ne
in
C+
+
ne
in
ne
in
C+
+
ne
in
pr
op
rie
rtä
r 
pr
op
rie
rtä
r 
pr
op
rie
rtä
r
ne
in
C+
+
ne
in
ne
in
C+
+
ne
in
ne
in
C+
+
ne
in
ne
in
co
b_
lbr
co
b_
un
de
rca
rri
ag
e_
ctr
l 
co
b_
ba
se
_d
riv
e_
ch
ain
 
ur
_d
riv
er
mo
ve
_b
as
e
mo
ve
it
ipa
_l
oc
_e
kf
ipa
_l
oc
_l
as
er_
ex
tra
ct 
ipa
_l
oc
_m
ap
_s
erv
er 
ipa
_l
oc
_a
sso
cia
tio
n
C+
+
ne
in
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t 
mo
de
llb
as
ier
t
ne
in
86
6.1 Auswertung der umgesetzten Komponentenmodelle
Jede der im Folgenden beschriebenen Metriken wird zum besseren Vergleich auf eine Zahl zwi-
schen 0 und 1 normiert. Zudem ist für jede Metrik ein Konfidenzintervall mit einem Konfidenzko-
effizienten von 95% definiert. Für den Vergleich der Metriken untereinander ist zu beachten, dass
die Messungen nur als grobe Abschätzungen zu verstehen sind, da Metriken wie bespielsweise
die Anzahl an Quellcodezeilen nicht präzise sind.
Um die Ersparnis bei der Entwicklung abzuschätzen und den Anteil an Code zu bestimmen,
der den in der Codegenerierung definierten Standards entspricht, wird der Grad der Autogene-
rierung für jede Komponente berechnet. Hierzu wird als einfache Abschätzung die Anzahl an
Programmzeilen für den generierten Teil LOCgen sowie für den gesamten Quellcode LOCges
einer Komponente c nach folgender Formel berechnet:
autogen(c) = LOCgen(c)/LOCges(c) (6.1)
Zusätzlich entsteht auch bei der Modellierung der Komponenten ein Entwicklungsaufwand. Um
diesen anteilig auf den Komponentenumfang darzustellen, wird die Anzahl an Zeilen, die ein
Modell einer Komponente beschreiben LOCmodel(c) (im Fall der hier umgesetzten Toolchain ein
XML-Dokument) dem Gesamtprogrammierumfang gegenüber gestellt. Dabei ist zu beachten,
dass diese Zahl nicht mit der Zahl der autogenerierten Programmzeilen zu vergleichen ist, da
es sich um verschiedene Ausdruckssprachen handelt. Zudem wird der XML-Code in den meisten
Fällen nicht manuell, sondern durch graphische Editoren erstellt:
model(c) = LOCmodel(c)/LOCges(c) (6.2)
Die Wiederverwendung einer ROS-Komponente kann in zwei Usecases erfolgen, für die jeweils
unterschiedliche Metriken berechnet werden. Falls eine Komponente in einem anderen Framework
als ROS verwendet werden soll, ist die Menge an Quellcode relevant, der von ROS abhängig ist.
Dieser muss in diesem Fall ersetzt werden. Da es hier vor allem um funktionelle Aspekte geht,
wird im Gegensatz zu den bisherigen Metriken nicht die Anzahl an Quellcodezeilen, sondern die
Anzahl an Funktionen mit ROS-Abhängigkeit nrosfunctions zu der Gesamtanzahl an Funktionen
nallfunctions ins Verhältnis gestellt:
rosdep(c) = nrosfunctions/nallfunctions (6.3)
Eine weitere Art der Wiederverwendung ist die Verwendung der Komponente in einem anderen
Kontext, d.h. in einem anderen Robotersystem oder in einer anderen Roboteranwendung. Da hier
Parallelen zur Wiederverwendung von Softwareobjekten in nicht komponentenbasierter Software
gezogen werden können, wurden die Metriken, die in (Washizaki, Yamamoto et al. 2003) für
objektorientierte Softwaresysteme definiert, wurden auf die komponentenbasierte Entwicklung
mit ROS übernommen. Zwei der in (Washizaki, Yamamoto et al. 2003) genannten Metriken
sind die Rate of Component Observability (RCO) und die Rate of Component Customizability
87
6 Evaluation von modellbasierter Entwicklung in der Robotik
(RCC). Da sich diese Metriken auf die Zugriffsart auf Parameter der Komponente beziehen,
werden die Metriken im Fall von ROS auf die verschiedenen Konfigurationsmöglichkeiten einer
ROS-Komponente bezogen. Die RCO ist damit der Anteil an Komponentenparametern, die über
den Parameterserver vor Komponentenstart konfiguriert und während der Laufzeit ausgelesen
werden können. Die Anzahl an Parametern, die über den Parameterserver ausgelesen werden,
wird mit Pparam(c) bezeichnet, die Gesamtanzahl an Parametern mit Pges(c).
Die RCO ergibt sich daher aus:
param = Pparam(c)/Pges(c) (6.4)
Auf gleiche Weise kann die RCC über die Anzahl an Parametern, die zur Laufzeit dynamisch über
den dynamic_reconfigure Mechanismus in ROS angepasst werden können, Pdyn(c), berechnet
werden. Die RCC berechnet sich daher aus:
dynconf = Pdyn(c)/Pges(c) (6.5)
Weitere in (Washizaki, Yamamoto et al. 2003) angegebene Metriken, wie beispielsweise die
“Existence of Meta-Information”, sind zwar für die Wiederverwendung von Komponenten wich-
tig, da diese für ROS-Komponenten generell zutreffend sind, kann aus diesen Werten allerdings
kein Vergleich zur modellbasierten Entwicklung gezogen werden. Daher werden sie bei dieser
Analyse nicht betrachtet.
Für die in den Case Studies erstellten Komponenten ergeben sich die in Tabelle 6.2 dargestellten
Werte. Es liegt ein relativ hoher Grad an Autogenerierung für die jeweiligen Komponenten vor.
Die RCO und RCC ist bei allen Komponenten relativ hoch.
Tabelle 6.2: Evaluation der in den Case Studies entstandenen Komponenten
ROS Komponente autogen(c) model(c) rosdep(c) param(c) dynconf (c)
cob_kuka_xmlrpc 0,129 0,009 0,055 1,0 1,0
cob_cartesian_trajectories 0,379 0,031 0,207 1,0 1,0
cob_config_controller 0,487 0,042 0,368 1,0 1,0
cob_undercarriage_ctrl 0,186 0,014 0,320 0,025 0,025
cob_base_drive_chain 0,112 0,008 0,161 0,5 0,5
ipa_loc_ekf 0,371 0,012 0,452 0,81 0,81
ipa_loc_laser_extract 0,316 0,024 0,261 0,85 0,85
ipa_loc_map_server 0,305 0,024 0,286 1,0 1,0
ipa_loc_association 0,238 0,015 0,360 0,75 0,75
88
6.1 Auswertung der umgesetzten Komponentenmodelle
Tabelle 6.3: Evaluation der Metriken für die ursprünglichen Komponenten, die nicht modellba-
siert entstanden sind
ROS Komponente rosdep(c) rosparam(c) dynconf (c)
cob_cartesian_trajectories 0,586 1,0 0,0
cob_config_controller 0,438 1,0 0,0
cob_undercarriage_ctrl 0,391 0,025 0,0
cob_base_drive_chain 0,333 0,333 0,0
Um diese Werte mit den bestehenden, nicht modellbasierten Implementierungen zu vergleichen,
sind in Tabelle 6.3 für die vier überarbeiteten Komponenten die jeweiligen Werte ermittelt wor-
den. Da der Grad der Autogenerierung und der Grad der Modellierung für diese Komponenten
jeweils null beträgt, wurden diese Metriken in der Tabelle nicht aufgeführt.
Abbildung 6.1: Vergleich der ROS Abhängigkeit von Komponenten nach klassischer (blau) und
mit modellbasierter Entwicklung (grün)
Durch die Autogenerierung konnte ein erheblicher Aufwand eingespart werden. Der durch die
modellbasierte Entwicklung entstandene Quellcode ist bei allen Komponenten unabhängiger von
ROS (siehe Abbildung 6.1) als in der klassischen Umsetzung. Der Vergleich der Metriken der
Wiederverwendbarkeit zeigt, dass sich die Rate of Component Observability nur für eine Kom-
ponente durch das modellbasierte Verfahren steigern ließ (siehe Abbildung 6.2). Jedoch wurde
bei allen Komponenten die Rate of Component Customizability erhöht (siehe Abbildung 6.3),
da diese im klassischen Fall bei allen untersuchten Komponenten null beträgt.
89
6 Evaluation von modellbasierter Entwicklung in der Robotik
Abbildung 6.2: Vergleich der Rate of Component Observability (RCO) von Komponenten nach
klassischer (blau) und mit modellbasierter Entwicklung (grün)
Abbildung 6.3: Vergleich der Rate of Component Customizability (RCC) von Komponenten nach
klassischer (bei allen Komponenten null) und mit modellbasierter Entwicklung
(grün)
6.2 Portierungsaufwand von Komponenten
Für die einzelnen Komponenten wurden Metriken ermittelt, die aufzeigen, inwieweit die erstellten
ROS-Komponenten in anderen Komponentenframeworks wiederverwendbar sind. Da im Rahmen
der Umsetzung des SyncMM-Reglers drei Komponenten von ROS auf OROCOS RTT portiert
wurden, können zusätzlich Abschätzungen bzgl. des Aufwands dieser Portierung durchgeführt
werden. Hierzu werden zusätzlich zu den Größen autogen(c) und modellierung(c) RTT-spezifische
Größen aus dem Quellcode ermittelt.
Auch im Fall der OROCOS RTT-Implementation kann die Menge an autogeneriertem Code
LOCgen(corocos) auf Basis der Anzahl der Programmcodezeilen ermittelt werden:
autogenorocos(corocos) = LOCgen(corocos)/LOCges(corocos) (6.6)
Für die Umsetzungen in ROS und OROCOS RTT kann ebenfalls der manuell entwickelte Pro-
grammcode verglichen werden. Mit Hilfe eines Vergleichs können die Anzahl an Zeilen ermittelt
90
6.3 Qualitative Auswertung der umgesetzten Systemmodelle
werden, die bei der Portierung modifiziert werden mussten LOCcustomchanged. Dieser Modifikati-
onsaufwand wird auf die Größe der Gesamtkomponente bezogen, um einen Anteil zu berechnen:
customchanged(corocos) = LOCcustomchanged(corocos)/LOCges(corocos) (6.7)
Die ermittelten Werte werden in Tabelle 6.4 für die drei Komponenten zusammengefasst. Der
Portierungsaufwand ist durch den Einsatz von modellbasierter Entwicklung für die Kommunika-
tion, Koordination und Konfiguration sehr gering. Da sich die Komponentenmodelle von ROS
und OROCOS sehr ähnlich sind, ist auch bzgl. der vom Entwickler spezifizierten Algorithmen
nur eine geringe Anpassung notwendig.
Tabelle 6.4: Metriken zu den auf OROCOS RTT portierten Komponenten
OROCOS RTT Komponente autogenorocos(corocos) customchanged(corocos)
cob_config_controller 0,448 0,0
cob_undercarriage_ctrl 0,172 0,0
cob_base_drive_chain 0,115 0,0
6.3 Qualitative Auswertung der umgesetzten
Systemmodelle
Analog zur Auswertung der einzelnen, mittels der Toolchain erstellten Komponenten werden
nun die in den Case Studies erstellten Systemmodelle analysiert. Da die Systemmodelle der Case
Studies SyncMM und Logistikszenario vor Bereitstellung der modellbasierten Toolchain manuell
erstellt wurden, kann ein Vergleich zwischen klassischer und modellbasierter Entwicklung von
Systemmodellen erstellt werden.
Eine wichtige Eigenschaft zur Dokumentation eines Systems sowie zur möglichen Wiederverwen-
dung von Teilsystemen ist die Formalisierung der Kommunikation im System. Da die Definition
von Kommunikationskanälen bei ROS optional ist, soll der Anteil an formal beschriebenen Kom-
munikationskanälen als Metrik für Systemmodelle dienen. Dabei wird die Anzahl der im System
definierten “remap”-Tags nremaps der Anzahl an Publishern npubl und Subscribern nsub im System
gegenüber gestellt:
comm(s) = nremaps/(
X
npubl(s) +
X
nsub(s)) (6.8)
Für die zwei in den Case Studies erstellten Systeme sind die Werte für die klassische sowie für
die modellbasierte Erstellung in Tabelle 6.5 dargestellt.
Während die Systemkonfiguration im klassischen Fall vollständig manuell erstellt wurde, wird
im modellbasierten Fall die Erstellung vollständig automatisiert durchgeführt. Daher gibt es bei
91
6 Evaluation von modellbasierter Entwicklung in der Robotik
Tabelle 6.5: Ergebnisse der Evaluation der BRIDE Systeme aus den Case Studies
ROS System comm(s)klassisch comm(s)modellbasiert
SyncMM 0,1 1,0
Logistikszenario 0,25 1,0
der Erstellung der Systemkonfigurationen eine Reduktion des Entwicklungsaufwandes durch das
modellbasierte Verfahren. Die Anzahl der konfigurierten Komponenten ist in beiden Fällen gleich.
Dennoch ist der Grad an formal beschriebener Kommunikation bei der klassischen Erstellung der
Case Study-Systeme gering. Durch die vollständige Modellierung der Kommunikation im modell-
basierten Ansatz haben die generierten Systeme im Gegensatz zur klassischen Umsetzung eine
vollständige Beschreibung der Kommunikationsverbindungen. Dies macht das Verhalten der Sys-
teme transparenter und unterstützt, durch die zusätzliche Dokumentation der Systemstruktur,
die Wiederverwendung von Teilsystemen in anderen Anwendungen.
92
6.4 Analyse der allgemeinen Benutzung der modellbasierten Entwicklungstoolchain
6.4 Analyse der allgemeinen Benutzung der
modellbasierten Entwicklungstoolchain
Aufgrund der quantitativen Analyse im letzten Abschnitt kann für die gezeigten Projekte dar-
gestellt werden, welche Vorteile die modellbasierte Entwicklung mit BRIDE im Detail bringt.
Um auszuschließen, dass diese Vorteile nur in den gezeigten Projekten bzw. bei den involvierten
Entwicklern zum Tragen kommen, soll auch eine allgemeinere Analyse im Rahmen dieser Arbeit
durchgeführt werden. Da BRIDE bei der Fertigstellung dieser Arbeit bereits seit einigen Mona-
ten im Umlauf ist und kontinuierlich weiterentwickelt wird, ist es möglich, eine Befragung der
Entwickler durchzuführen, um qualitative Aussagen über den aktuellen und zukünftigen Einsatz
modellbasierter Entwicklung zu treffen.
6.4.1 Das Goal-Question-Metric Verfahren
Im Bereich der modellbasierten Entwicklung wurden schon in anderen Domänen, beispielsweise
im Fahrzeugbau (Kirstan und Zimmermann 2010), in der Telekommunikationsindustrie (Baker,
Loh et al. 2005) oder im Gesundheitswesen (Walderhaug, Mikalsen et al. 2008), qualitative
Evaluationen durchgeführt. In dieser Arbeit wird sich konzeptionell an diesen Evaluationen ori-
entiert. Zur Entwicklung des Umfragekonzeptes und der daraus resultierenden Metriken kann
das Goal-Question-Metric (GQM) Verfahren aus (Basili und Weiss 1984), das sich in der Analyse
von Softwareengineeringkonzepten bewährt hat, eingesetzt werden. Dabei werden die abstrak-
ten Ziele, die gemessen werden sollen, als “Goals” definiert und daraus Fragen abgeleitet, die
beantworten, ob die Ziele erreicht wurden. Zu jeder dieser Fragen werden Messungen in Form
von “Metrics” definiert. Das GQM-Verfahren hat vor allem Vorteile, wenn die Wirkungen eines
Konzeptes klar sind und validiert werden sollen.
6.4.2 Das Technology Acceptance Model
Ein alternatives Konzept aus dem empirischen Softwareengineering ist das “Technology Ac-
ceptance Model” (TAM) von (Davis 1989) und seine Erweiterungen. Das TAM quantifiziert die
subjektive Wahrnehmung der Nutzer in fünf Bereichen, um die aktuelle Nutzung eines Konzeptes
und dessen zukünftige Nutzung abzuschätzen. Die Bereiche sind in Tabelle 6.6 beschrieben.
6.4.3 Erstellung von Evaluationsmetriken mit einer Kombination aus
GQM und TAM
Im Rahmen dieser Arbeit wird, ähnlich wie in (Mohagheghi, Gilani et al. 2013), eine Kombination
der Verfahren durchgeführt, um zum einen den Effekt der BRIDE-Toolchain bezüglich konkreter
93
6 Evaluation von modellbasierter Entwicklung in der Robotik
Tabelle 6.6: Bereiche, für die das Technology Acceptance Model angewandt werden kann
Bereiche nach TAM Erläuterung des Bereiches
Organizational Support Aussage über die Unterstützung eines Ansatzes durch die
organisationellen Rahmenbedingungen (z.B. Mitarbeiterverpflichtung für
ein bestimmtes Softwaretool).
Perceived Usefulness Beschreibt nach dem persönlichen Empfinden, wie stark ein Ansatz die
eigene Produktivität erhöht.
Perceived Ease of use Eine Abschätzung über den Aufwand, die der Einsatz eines Ansatzes
zusätzlich entstehen lässt und wie leicht der Ansatz persönlich
angewandt werden kann.
Perceived Compatibility Der wahrgenommene Grad, inwieweit die eingesetzten Ansätze mit den
bestehenden Ansätzen und Tools kompatibel sind.
Subject Norm Abschätzung darüber, wie andere (Vorgesetzte, Kunden, etc.) die
Anwendung des Ansatzes wahrnehmen.
Entwicklungsziele mittels GQM zu messen sowie exploratorisch die aktuelle und zukünftige Nut-
zung zu evaluieren. Dazu wird eine Untermenge der Konzepte aus TAM benutzt. Ein Überblick
über dieses Evaluierungskonzept ist in Abbildung 6.4 zu sehen.
Abbildung 6.4: Überblick über die qualitatitve Evaluationsstrategie für die Toolchain BRIDE
Für die konkrete Anwendung des GQM Konzeptes werden folgende Ziele definiert, deren Erfül-
lung im Rahmen der Entwicklerbefragung nachgewiesen werden sollen:
• Evaluationsziel 1: Steigerung der Wiederverwendung mit MDE
• Evaluationsziel 2: Verbesserte Auftrennung von Entwicklerrollen
• Evaluationsziel 3: Bessere Akzeptanz des modellbasierten Ansatzes durch eine ROS-nahe
Toolchain
94
6.4 Analyse der allgemeinen Benutzung der modellbasierten Entwicklungstoolchain
Dabei beziehen sich die ersten beiden Ziele auf die in Kapitel 1 definierten Ziele dieser Arbeit.
Das dritte Ziel ist aus den Analysen der bisherigen modellbasierten Ansätze hervorgegangen und
wurde in Kapitel 3.1 diskutiert. Für die drei Evaluationsziele werden entsprechend des GQM-
Ansatzes zuerst Fragen extrahiert und für diese dann Metriken definiert, die durch die Umfrage
ermittelt werden sollen. Abbildung 6.5, Abbildung 6.6 und Abbildung 6.7 zeigen die Fragen und
Metriken für die drei Entwicklungsziele.
Abbildung 6.5: GQM für das Evaluationsziel 1
Für die Analyse von BRIDE mit der TAM-Methode werden für die verschiedenen TAM-Evaluationstypen
ebenfalls konkrete Metriken abgeleitet, die im Rahmen einer Befragung ermittelt werden kön-
nen und Rückschlüsse auf die jeweilige Akzeptanz zulassen. In Tabelle 6.7 sind die entwickelten
Metriken zusammengefasst.
95
6 Evaluation von modellbasierter Entwicklung in der Robotik
Abbildung 6.6: GQM für das Evaluationsziel 2
Abbildung 6.7: GQM für das Evaluationsziel 3
96
6.4 Analyse der allgemeinen Benutzung der modellbasierten Entwicklungstoolchain
Tabelle 6.7: Metriken des Technology Acceptance Model angewandt auf die Evaluation von
BRIDE
TAM Typ Metrik
Perceived Usefulness Lesbarkeit des Codes
Perceived Usefulness Dokumentation der Software
Perceived Ease of Use Verständlichkeit der Modelle
Perceived Ease of Use Einfachheit der Modifikation von generierten Modellen
Perceived Ease of Use Qualität der DSL
Perceived Compatibility Nutzung mit bestehender Software
Perceived Compatibility Nutzung mit bestehenden Konzepten
6.4.4 Ergebnisse der Evaluation
Auf Basis der entwickelten Metriken wurde ein detaillierter Fragebogen erstellt, der für eine
Entwicklerbefragung genutzt wurde. Die aus dem GQM-Prinzip entwickelten Metriken wurden als
Zustimmfragen mit einer siebenstufigen Skala in den Fragebogen integriert. Bei Fragen nach der
Erfahrung mit ROS oder modellbasierter Entwicklung wurden die Erfahrungsmonate abgefragt.
Somit ist gewährleistet, dass die Beantwortung des Fragebogens nur eine geringe Zeit in Anspruch
nimmt und daher möglichst viele Entwickler an der Befragung teilnehmen. Bei einigen Fragen
wurde für die Zustimmskala eine Inversion vorgenommen. Zusätzlich wurden die Metriken der
TAM in Zustimmfragen umgewandelt. Die Fragen wurden anschließend unabhängig von der
GQM- und TAM-Methodik im Fragebogen nach Themen und nach aufsteigendem Detailgrad
sortiert. Der entstandene Fragebogen, der in englischer Sprache verfasst wurde, enthält 25 Fragen
und wurde zwischen Juni und August 2014 von BRIDE-Entwicklern beantwortet. Der vollständige
Fragebogen ist in Anhang A dieser Arbeit nachzulesen.
Abbildung 6.8: Resultate der Umfrage zu Evaluationsziel 1
97
6 Evaluation von modellbasierter Entwicklung in der Robotik
Die Ergebnisse sind in Anhang B aufgelistet und werden im Folgenden für eine Analyse auf-
gearbeitet. Die Antworten auf die einzelnen Fragen werden den entsprechenden GQM- und
TAM-Metriken wieder zugeordnet und graphisch dargestellt. Dabei ist stellen Wertungen über
3,5 eine Zustimmung dar, Werte unter 3,5 verdeutlichen hingegen Ablehnung.
Die Ergebnisse vom Evaluationsziel 1, der Steigerung der Wiederverwendung, (Abbildung 6.8)
zeigen, dass die mit modellbasierter Entwicklung erstellten Komponenten von den Entwicklern
als besser verständlich wahrgenommen werden. Somit ist es wahrscheinlich, dass die Entwickler
eine Komponente in anderen Anwendungen wieder verwenden. Zudem ist eine Präferenz für
graphische Darstellung der Modelle erkennbar. Die Ergebnisse zur Abgrenzung der Entwickler-
belange zeigen, dass die Belange durch die modellbasierte Entwicklung mit BRIDE als besser
getrennt wahrgenommen werden. Wie in Kapitel 3 beschrieben, steigert dies ebenfalls die Wie-
derverwendbarkeit.
Abbildung 6.9: Resultate der Umfrage zu Evaluationsziel 2
In den Ergebnissen zur Evaluationsziel 2, der verbesserten Auftrennung von Entwicklerrollen
(Abbildung 6.9) zeigt sich, dass sich nach Meinung der Entwickler der Kommunikationsbedarf
untereinander reduziert hat, wenn sie BRIDE verwenden. Modellbasierte Entwicklung sorgt dafür,
dass über die Modelle zwischen den Entwicklerrollen klare Informationsflüsse bestehen. Weiterhin
zeigt sich durch die Fragen Q14, Q15 und Q16, dass die Trennung zwischen der “Capability
Development”-Phase und der “System Deployment”-Phase in BRIDE als gut empfunden wird.
Die “Application Development”-Phase muss aus Sicht der Entwickler noch stärker von den
anderen Phasen getrennt werden.
Bei den Ergebnissen zur Evaluation des frameworknahen, modellbasierten Verfahrens nach der
Bottom-up-Methodik, dem dritten Evaluationsziel, (siehe Abbildung 6.10) ist eine starke ROS-
Präferenz der Entwickler erkennbar. Die Teilnehmer der Umfrage nutzen häufig bestehende
ROS-Komponenten, die nicht durch die modellbasierte Toolchain selbst entwickelt wurden, so
dass eine einfache Integration dieser Komponenten, wie sie in BRIDE umgesetzt wurde, hilfreich
ist. Eine klare Präferenz zwischen Systementwurfsarten nach der Top-down-Methodik oder der
Bottom-up-Methodik ist aus der Befragung nicht erkennbar. Die Varianz bei der Beantwortung
98
6.4 Analyse der allgemeinen Benutzung der modellbasierten Entwicklungstoolchain
Abbildung 6.10: Resultate der Umfrage zu Evaluationsziel 3
dieser Fragen war sehr hoch. Die Unterstützung von abstrakten Entwurfsverfahren, wie beispiels-
weise SysML, und die Unterstützung beim Modellieren von Einzelfunktionalitäten in BRIDE ist
daher gleichermaßen wichtig, wie auch die direkte Unterstützung von ROS-Mechanismen.
Abbildung 6.11: Resultate der Umfrage zu TAM
Aus den Ergebnissen der TAM-Fragen (Abbildung 6.11) ist zu erkennen, dass die aktuelle Ver-
sion von BRIDE von den Entwicklern bzgl. Nützlichkeit und Einfachheit generell sehr positiv
aufgenommen wird. Bezüglich der Modifikation bestehender Modelle wird allerdings noch Aus-
baupotenzial gesehen. Als positiv wird die Qualität der ROS DSL, ein Hauptergebnis dieser
Arbeit, bewertet. Generelle Zustimmung wurde auch bzgl. der Kompatibilität zu bestehenden
Arbeitsmethoden sowie der bestehenden Softwareinfrastruktur festgestellt. Daher ist davon aus-
zugehen, dass die Verbreitung von BRIDE weiterhin steigen wird und die Entwickler Feedback
zu Verbesserungen geben werden.
99
6 Evaluation von modellbasierter Entwicklung in der Robotik
6.4.5 Bewertung der Reliabilität
Als Population für die Umfrage wurden die BRIDE-Entwickler zum Zeitpunkt der Umfrage ge-
wählt. Schätzungsweise handelt es sich dabei um 50 Entwickler aus dem Umfeld der Roboter-
entwicklung. Die Stichprobe entspricht den 14 Entwicklern, die bei der Umfrage teilgenommen
haben. Da die Population aufgrund der noch niedrigen Verbreitung sehr gering gewählt wurde,
ist das Konfidenzniveu der Umfrage sehr niedrig.
Anhand der ersten Fragen der Umfrage ist zu erkennen, dass die Stichprobe eine große Bandbreite
von Entwicklern widerspiegelt. Es gibt eine Mischung aus erfahrenen und jüngeren Softwareent-
wicklern mit längerer Nutzung von BRIDE (12–16 Monate) sowie ebenfalls Neunutzer. Ebenfalls
bzgl. der ROS Erfahrung ist eine hohe Bandbreite bei den Befragten zu erkennen.
Dennoch ist die Umfrage durch die Wahl der Population nur innerhalb der BRIDE-Community
repräsentativ. Ein direktes Übertragen der Ergebnisse auf die gesamte Roboterentwicklungsge-
meinschaft ist somit nicht möglich.
6.5 Zusammenfassung
Im Rahmen dieser Arbeit wurde sowohl eine quantitative Analyse des in den Case Studies ent-
standenen Codes als auch eine Entwicklerbefragung aus einer Kombination aus dem GQM- und
dem TAM-Verfahren durchgeführt. In der quantitativen Analyse hat sich klar gezeigt, dass der
Entwicklungsaufwand für Tätigkeiten der Softwareentwicklung für mobile Manipulatoren ge-
sunken ist. Zudem konnte die Trennung von verschiedenen Abhängigkeiten, die in Kapitel 3
hergeleitet wurden, durch den modellbasierten Ansatz und die entsprechende Entwicklung der
Meta-Modelle nachgewiesen werden.
Die Entwicklerbefragung hat gezeigt, dass die modellbasierte Toolchain BRIDE die Wieder-
verwendbarkeit von Software steigert und sich positiv auf die Trennung von Entwicklerrollen
auswirkt. Zudem wurde Entwicklungspotential bzgl. der Benutzbarkeit von BRIDE ermittelt.
Der in BRIDE gewählte frameworknahe Ansatz wird von den Entwicklern positiv aufgenommen
und dient zur stärkeren Verbreitung der modellbasierten Toolchain.
100
7 Abschließende Betrachtung
Die Erfahrungen und Erkenntnisse aus dieser Arbeit werden im Folgenden im Hinblick auf die
anfangs formulierten Zielstellungen zusammengefasst. Abschließend werden potentielle Weiter-
entwicklungsmöglichkeiten der modellbasierten Toolchain auf Basis der durchgeführten Nutzer-
befragung, der Case Studies sowie der aktuellen Entwicklungen in der Robotik aufgezeigt.
7.1 Zusammenfassung und Ergebnisse der Arbeit
Die Flexibilität von Robotersystemen wird heutzutage in industriellen Anwendungen nur bedingt
genutzt. Vor allem die Verbreitung von mobilen Manipulatoren in industriellen Anwendungen
ist heutzutage niedrig. Der hohe Entwicklungsaufwand der Softwaresysteme solcher Roboter,
insbesondere durch die Komplexitätssteigerung durch die Einführung der Mobilität, ist dabei der
Haupthinderungsgrund. Ziel dieser Arbeit war es, eine Reduktion dieses Aufwandes durch den
Einsatz von modellbasierten Softwareengineering-Techniken zu ermöglichen und die Einführung
dieser Techniken in die bestehenden Entwicklungsprozesse der Robotik durchzuführen. Dabei
kann der Nutzen des modellbasierten Ansatzes für mobile Manipulation im industriellen Einsatz
nachgewiesen werden.
Hierzu wurde unabhängig zu bestehenden modellbasierten Umgebungen, die entweder nur für
eine sehr konkrete Domäne der Robotik geeignet sind oder aber inkompatibel zu bestehen-
den verbreiteten Roboterentwicklungspraktiken und -komponenten sind, eine neue modellba-
sierte Entwicklungsumgebung für das verbreitete Kommunikationsframework ROS konzipiert
und umgesetzt. Dabei wurde spezifisch für das Komponentensystem ROS ein framework-nahes
Meta-Modell erstellt. In diesem wurden die verschiedenen Aspekte einer Softwarekomponente,
die Kommunikation, Koordination, Konfiguration, Komposition und der eigentliche Algorithmus
von einander getrennt betrachtet, so dass sie auch später in der Umsetzung trennbar sind. Zu-
dem wurde im Softwareentwicklungsprozess zwischen den Nutzerrollen Komponentenentwickler,
Systementwickler und Applikationsentwickler unterschieden.
Diese Konzepte wurden im Rahmen dieser Arbeit durch die Formalisierung des ROS-Frameworks
in einer Eclipse-basierten Entwicklungsumgebung namens BRIDE umgesetzt. Dazu wurden ba-
sierend auf dem Meta-Modell verschiedene graphische Editoren für die jeweiligen Nutzerrollen
101
7 Abschließende Betrachtung
sowie Codegenerierungsfunktionalitäten entwickelt. Eine Integration in andere Komponenten-
frameworks sowie andere High-Level MDE-Umgebungen wurden zudem exemplarisch umgesetzt.
Basierend auf dieser Entwicklungsumgebung wurden drei Anwendungsfälle unterschiedlicher
Komplexität ausgewählt und mittels der erstellten Toolchain umgesetzt, um den Entwicklungs-
prozess mit BRIDE darzustellen sowie Komponenten für eine detaillierte quantitative Analyse
zu erstellen. Diese Analyse wurde auf Basis von in dieser Arbeit entwickelten Metriken durch-
geführt. Zusätzlich ist eine Nutzerbefragung durchgeführt worden, um die Entwicklungsziele im
Rahmen weiterer Entwicklungstätigkeiten zu analysieren.
Bei diesen Evaluierungen wurde festgestellt, dass durch die Verwendung von BRIDE die Wieder-
verwendung bestehender Komponenten, Subsysteme und Anwendungskonfigurationen gefördert
und gesteigert wird. Zudem hat sich die klare Trennung von Nutzerrollen bewährt. Die Analyse
zeigt, dass Nutzer in der Roboterentwicklung nur eine Rolle ausfüllen können. Die Kommunika-
tion unter den Entwicklern wurde nach Meinung der Benutzer verbessert. Die Umsetzung der
Toolchain durch eine ROS-Frameworknahe Modellierungssprache hat zur besseren Verbreitung
der Toolchain geführt. Zudem hat die Befragung ergeben, dass die Umstellung der Prozesse der
Entwickler für die Nutzung von modellbasierter Entwicklung durch BRIDE gering ist.
Die im Rahmen dieser Arbeit erstellte modellbasierte Toolchain hat durch die oben genannten
Konzepte die vierte Stufe der modellbasierten Majurity-Levels laut (Rios, Bozheva et al. 2006)
erreicht. Man kann bei der Entwicklung von mobilen Manipulatoren mit ROS also bereits von
“Integrated model driven development” mit all seinen eingangs erwähnten Vorzügen sprechen.
Das Hauptziel dieser Arbeit wurde daher erreicht. Als größte Herausforderung bei der Anwen-
dung der Resultate dieser Arbeit hat sich die Standardisierung von Schnittstellen zwischen den
von den Endnutzern entwickelten Komponentenmodellen herausgestellt. Hierzu ist eine gemein-
same Maßnahme der Entwicklergemeinschaft in der Robotik notwendig. Zudem muss zur noch
stärkeren Verbreitung der Installations-Overhead, der durch die Nutzung von BRIDE entsteht,
minimiert werden.
7.2 Mögliche Weiterentwicklungen von BRIDE
Zusätzlich zur bestehenden Nutzung von BRIDE für aktuelle Roboterprojekte ist die Weiter-
entwicklung der Toolchain in diversen nationalen und europäischen Forschungsprojekten ver-
ankert. Daher bieten sich diverse Möglichkeiten zur Verbesserung sowie zur Entwicklung von
neuen Funktionen und Aspekten. Ein großes Interesse an der Nutzung und Weiterentwicklung
von BRIDE besteht vor allem bei den industriellen Anwendern im Rahmen der ROS-Industrial
Initiative. Standardisierte Entwicklungsverfahren sowie die Möglichkeit des Validierens von An-
forderungen werden als Gründe angegeben, ROS-Anwendungen im industriellen Kontext mit
BRIDE zu entwickeln. Während sich BRIDE zur Zeit sehr stark an die verschiedenen Rollen der
Roboterentwickler richtet, die auf Basis von ROS ein komplexes System für mobile Manipula-
102
7.2 Mögliche Weiterentwicklungen von BRIDE
tion umsetzen wollen, ist die Unterstützung einer Endanwender-Rolle eine weitere interessante
Erweiterungsmöglichkeit. Diese Rolle würde ermöglichen, eine Anwendung direkt durch den End-
nutzer zu erstellen. Der Roboterentwickler spezifiziert dafür geeignete Abstraktionsmechanismen
während der Entwicklung. Durch die automatische Codegenerierung bzw. von Model-To-Model-
Transformationen kann ein entsprechender Endanwender-Editor mit wenig Entwicklungsaufwand
erstellt werden.
Im Rahmen dieser Arbeit wurde die Generierung von Quellcode nicht nur für ROS, sondern auch
für die Toolchain OROCOS RTT gezeigt. Da es noch weitere, zu den ROS-Konzepten kompatible
Frameworks, wie beispielsweise MIRA (Einhorn, Langner et al. 2012), gibt, ist eine Erweiterung
der Codegenerierung erstrebenswert. Zudem wird zur Zeit schon an der nächsten Generation
des ROS-Frameworks (ROS 2.0) gearbeitet, welches auf dem Data Distribution Service (DDS)
Standard basiert. Gerade in der Entstehungsphase ist hierbei mit diversen API-Änderungen zu
rechnen, welche mit der BRIDE-basierten Codegenerierung abgefangen werden können.
Abbildung 7.1: Protege Editor zur Entwicklung von OWL-basierten, semantischen Modellen
Die Umfrage hat gezeigt, dass viele Entwickler von BRIDE auch Erfahrungen mit anderen mo-
dellbasierten Toolchains haben, die wie in Kapitel 2 beschrieben, vor allem für die Erstellung von
spezifischen Capabilities geeignet sind. Eine direkte Kopplung von diesen Toolchains mit dem
BRIDE Capability Editor ist als Erweiterung von BRIDE geplant. Statt manuell den entspre-
chenden Usercode zu erstellen, wechselt in diesem Fall der Nutzer in eine andere Toolchain, wie
beispielsweise Simulink, um die Funktionalität der Komponente, z.B. einen Regler, zu erstellen.
103
7 Abschließende Betrachtung
Auch die Integration von Bildverarbeitungsframeworks, beispielsweise Halcon, ist über diesen
Ansatz geplant.
Zur Zeit ist BRIDE durch die Nutzung vom Eclipse Modelling Framework an Eclipse gekoppelt
und die Entwicklung passiert vollständig in einer vom Entwickler eingerichteten Workstation.
Mit Bespielen wie codebox.io oder dem Eclipse Orion wird bzgl. Entwicklungsumgebungen ein
neuer Weg gegangen. Diese Entwicklungsumgebungen werden von einem Server “cloud-basiert”
bereitgestellt und können von den Entwicklern über einen Browser verwendet werden. Dabei
können durch die Performance heutiger Browser ein ähnliches Nutzungsverhalten wie bei nativen
Umgebungen umgesetzt werden. In Zeiten starker Vernetzung von Industrieanlagen im Rahmen
der Industrie 4.0 Initiative kann durch eine ebenfalls cloud-basierte Entwicklungsumgebung eine
einfachere Kopplung von Entwicklungs- und Zielsystem umgesetzt werden. Zudem reduziert sich
der Einrichtaufwand von Entwicklungsumgebungen stark.
Aus den aktuellen Internetentwicklungen ist auch die Modellierung von Wissen in Form von
semantischen Daten entstanden. Hier werden nicht wie bei modellbasierten Verfahren formale
Regeln für Modelle formuliert, vielmehr werden die Informationen durch sogenannte Triplesto-
res gesammelt. Dabei wird die Nutzung der Informationen sowie deren Erweiterung nicht näher
spezifiziert (open world assumption). Mit kognitiven Verfahren werden dann zur Laufzeit die Zu-
sammenhänge zwischen den Einzelinformationen genutzt, um die benötigten Parameter, Modelle
oder Funktionen zu generieren. Der Vorteil dieser Verfahren, die zur Zeit hauptsächlich in der
Wissenschaft entwickelt werden, zeigt sich in der Robotik vor allem in den applikationsbezogenen
Informationen, da diese bei der Roboterentwicklung nicht immer klar spezifiziert werden kön-
nen und gerade in der Interaktion mit dem Menschen zu unvorhergesehenen Zuständen führen
können. Als Sprache im semantischen Modellieren hat sich OWL verbreitet, für die es zahlreiche
Softwaretools gibt (siehe Abbildung 7.1). Eine Integration der modellbasierten Entwicklung mit
Informationen in Form von semantischen Datenbanken wurde bereits in (Parreiras, Walter et al.
2010) für andere Domänen gezeigt. Eine ähnliche Integration wäre auch für BRIDE denkbar.
104
7.2 Mögliche Weiterentwicklungen von BRIDE
Abbildung 7.2: Entwickler während der Verwendung von BRIDE für eine industrielle Roboteran-
wendung
Generell nimmt die Nutzung von BRIDE zur Zeit kontinuierlich zu. Dies wird durch den Einsatz
von BRIDE in diversen Forschungsprojekten (siehe Abbildung 7.2) sowie durch Industriefirmen
wie Bosch, Phillips oder Alten unterstützt. Die Nutzer von BRIDE bringen viele Verbesserungs-
vorschläge in die Weiterentwicklung des Projektes ein, was die Qualität der Toolchain erhöht
und somit wiederum neue Nutzer nach sich zieht. Durch diesen Kreislauf ist das BRIDE-Projekt
zu einer lebenden Community geworden, die die Kontinuität der modellbasierten Entwicklung in
der mobilen Manipulation auch nach Fertigstellung dieser Arbeit gewährleistet.
105

A Anhang: Fragebogen für BRIDE
Nutzerumfrage
Im Folgenden ist der Fragebogen, der für die BRIDE Nutzerumfrage verwendet wurde, darge-
stellt. Bei den mit * gekennzeichneten Fragen handelt es sich um Pflichtfragen.
Q1: How many months of ROS experience do you have?*
Q2: You are familiar with the core concepts of the ROS component framework. *
Q3: How many months of experience with model driven engineering (MDE) practices,
e.g. UML or SYSML do you have? (not including experience with BRIDE) *
Q4: Since how many months are you using BRIDE (0 if you are not using it)? *
Q5: What other MDE tool chains have you been using?
Q6: What roles in the development of robot applications do you usually have?
(multiple options possible) *
107
A Anhang: Fragebogen für BRIDE Nutzerumfrage
Q7: You prefer graphical development over textual development *
Q8: When developing a robot application, you start with creating an overall software
architecture. *
Q9: Most of the time, you use existing ROS components. Only few components in a
ROS system are developed by yourself. *
Q10: The need for communication between developers is reduced, when you use
BRIDE *
Q11: Modelling components in BRIDE could be simpler *
Q12: Components developed with BRIDE can be better understood compared to
manual written components. *
Q13: When developing with BRIDE, algorithmic code and the toolchain infrastructure
is separated *
108
Q14: When developing a component with BRIDE, the amount of system configuration
is reduced compared to manual development. (optional)
Q15: When configuring a ROS system with BRIDE, the amount of changes inside
of components is reduced compared to manual development of launch files.
(optional)
Q16: When developing coordinators with BRIDE, the amount of changes inside of
components is increased compared to manual development of SMACH state
machines. (optional)
Q17: Developing with BRIDE makes your code independent from the component
framework. *
Q18: With a BRIDE model, you can fully describe the ROS aspects of your
component, system or coordinator. *
Q19: When using BRIDE, you can still write the software in the way you want. *
Q20: BRIDE makes your code less readable *
109
A Anhang: Fragebogen für BRIDE Nutzerumfrage
Q21: It is difficult to modify models after creation with BRIDE *
Q22: You often use components developed with BRIDE together with other non-
BRIDE ROS components. *
Q23: Integration of software created with BRIDE together with other software you
wrote is easy *
Q24: When developing a robot application, you start with writing or collecting nodes
implementing the required features. *
Q25: Software developed with BRIDE is better documented. *
110
B Anhang: Ergebnisse der BRIDE
Nutzerumfrage
Im Folgenden sind die detaillierten Antworten der Entwickler für die Nutzerumfrage dieser Arbeit
gelistet. Die Fragen Q14, Q15 und Q16 waren optional und wurden daher nicht von allen
Befragten beantwortet. Eine Analyse der Antworten der Befragung ist in Unterabschnitt 6.4.4
zu finden.
111
B Anhang: Ergebnisse der BRIDE Nutzerumfrage
Q1
 
Q2
 
Q3
 
Q4
 
Q5
 
Q6
 
Q7
 
Q8
 
Q9
 
Q1
0 
Q1
1 
Q1
2 
Q1
3 
Q1
4 
Q1
5 
Q1
6 
Q1
7 
Q1
8 
Q1
9 
Q2
0 
Q2
1 
Q2
2 
Q2
3 
Q2
4 
Q2
5
18
6
24
16
C,
S 
5 
6 
3 
5 
3 
6 
6 
6 
6 
5 
6 
5 
5 
3 
3 
6 
5 
6 
6
60
7
0
12
C,
6
7
5
3
6
5
6
6
4
4
5
6
2
2
6
7
5
1
5
30
4
0
3
5
5
5
3
5
6
5
5
5
24
7
0
3
A,
 S
C,
 S
 
4 
3 
3 
2 
2 
5 
6 
6
C,
 S
 
5 
3 
2 
5 
2 
6 
6 
7 
7
7
6
6
1
1
6
7
5
6
36
7
0
12
C, A,
 S
4
3
3
5
3
4
6
4
6
3
5
5
5
3
2
6
6
6
4
40
7
6
2
C, A,
 S
4
5
2
6
4
6
6
4
5
2
3
3
4
2
5
6
4
24
6
0
1
C
4
4
2
4
3
7
6
5
4
4
6
4
3
3
7
2
4
5
5
9
5
1
1
C
5
3
2
4
6
5
6
6
6
4
3
6
3
3
4
4
5
4
8
4
0
0
C
1
6
3
2
4
6
5
5
5
6
6
2
3
6
5
6
5
8
4
0
3
C
6
5
4
5
2
5
6
6
5
5
6
6
2
4
4
6
5
3
10
6
4
4
A,
 S
 
6 
6 
7 
7 
5 
6 
6 
5 
4
6
7
6
6
1
4
5
7
6
27
6
0
2
C
5
6
6
3
2
3
5
2
3
3
3
3
5
2
3
4
7
5
4
6
8
0
C,
 S
 
2 
5 
7 
4 
4 
3 
4 
5 
4 
4 
6 
4 
2 
5 
6 
5 
4 
3 
4
20
6
4
2
C, A,
 S
2
6
5
4
4
6
5
6
6
7
1
3
7
6
7
4
112
Referenzen
Referenzen
(Ando, Suehiro et al. 2005) Ando, Noriaki, Suehiro, Takashi, Kitagaki, Kosei, Koto-
ku, Tetsuo, und Yoon, Woo-Keun, 2005. RT-middleware:
distributed component middleware for RT (robot techno-
logy). In: IEEE/RSJ International Conference on Intelli-
gent Robots and Systems, S. 3933–3938. DOI: 10.1109/I-
ROS.2005.1545521
(Angerer, Strassmair et al. 2012) Angerer, Stefanie, Strassmair, Christoph, Staehr, Max,
Roettenbacher, Maren, und Robertson, Neil M, 2012. Gi-
ve me a hand — The potential of mobile assistive ro-
bots in automotive logistics and assembly applications.
In: IEEE International Conference on Technologies for
Practical Robot Applications (TePRA), S. 111–116. DOI:
10.1109/TePRA.2012.6215663
(Arbeiter, Bubeck et al. 2010) Arbeiter, Georg, Bubeck, Alexander, Fischer, Jan, und
Graf, Birgit, 2010. Teleoperierte mobile Roboter warten
Prozessanlagen : Niedrigere Betriebskosten und höhere
Arbeitssicherheit. atp-edition Jg. 52(5) S. 44–51. ISSN:
0178-2320
(Baker, Loh et al. 2005) Baker, Paul, Loh, Shiou, und Weil, Frank, 2005.
Model-Driven engineering in a large industrial context—
motorola case study. In: Model Driven Engineering
Languages and Systems, Springer, S. 476–491. DOI:
10.1007/11557432_36
(Basili und Weiss 1984) Basili, Victor R und Weiss, David M, 1984. A methodo-
logy for collecting valid software engineering data. IEEE
Transactions on Software Engineering Jg. SE-10(6) S.
728–738. DOI: 10.1109/TSE.1984.5010301
113
Referenzen
(Brooks, Connell et al. 1988) Brooks, Rodney A., Connell, Jonathan H., und Ning, Pe-
ter, 1988. Herbert: A second generation mobile robot. In:
A.I. Memo No. 1016,
Massachusetts Institute of Technology
(Brugali, Gherardi et al. 2012) Brugali, Davide, Gherardi, Luca, Biziak, A, Luzzana, An-
drea, und Zakharov, Alexey, 2012. A reuse-oriented de-
velopment process for component-based robotic systems.
In: Simulation, Modeling, and Programming for Autono-
mous Robots, Springer, S. 361–374. DOI: 10.1007/978-
3-642-34327-8_33
(Bruyninckx 2001) Bruyninckx, Herman, 2001. Open robot control soft-
ware: the OROCOS project. In: IEEE International Confe-
rence on Robotics and Automation, S. 2523–2528. DOI:
10.1109/ROBOT.2001.933002
(Bruyninckx, Klotzbücher et al. 2013) Bruyninckx, Herman, Klotzbücher, Markus, Hochge-
schwender, Nico, Kraetzschmar, Gerhard, Gherardi, Luca,
und Brugali, Davide, 2013. The BRICS component mo-
del: a model-based development paradigm for complex
robotics software systems. In: Proceedings of the 28th
Annual ACM Symposium on Applied Computing, ACM,
S. 1758–1764. DOI: 10.1145/2480362.2480693
(Bubeck, Connette et al. 2012) Bubeck, Alexander, Connette, Christian, Hägele, Martin,
und Verl, Alexander, 2012. SyncMM - A Reactive Path
Planning and Control Framework for the Mobile Manipu-
lator Care-O-bot® 3. In: 43rd International Symposium
on Robotics, S. 150–155,
ISBN: 978-986-88683-0-4
(Bubeck, Weisshardt et al. 2012) Bubeck, Alexander, Weisshardt, Florian, Sing, Tobias,
Reiser, Ulrich, Hagele, M, und Verl, Alexander, 2012.
Implementing best practices for systems integration and
distributed software development in service robotics-the
Care-O-bot®robot family. In: IEEE/SICE International
Symposium on System Integration, S. 609–614. DOI:
10.1109/SII.2012.6427386
114
Referenzen
(Campion, Bastin et al. 1993) Campion, Guy, Bastin, Georges, und D’Andréa-Novel,
Brigitte, 1993. Structural properties and classification on
kinematic and dynamic models of wheeled mobile robots.
In: IEEE International Conference on Robotics and Au-
tomation (ICRA), IEEE, S. 462–469. DOI: 10.1109/RO-
BOT.1993.292023
(Connette, Hofmeister et al. 2010) Connette, Christian P, Hofmeister, Stefan, Bubeck,
Alexander, Hägele, Martin, und Verl, Alexander, 2010.
Model-Predictive Undercarriage Control for a Pseudo-
Omnidirectional, Wheeled Mobile Robot. In: 41st Inter-
national Symposium on Robotics (ISR) and 6th German
Conference on Robotics (ROBOTIK), VDE, S. 1–6,
ISBN: 978-3-8007-3273-9
(Corke 2007) Corke, Peter, 2007. MATLAB toolboxes: robotics and vi-
sion for students and teachers. IEEE Robotics & auto-
mation magazine Jg. 14(4) S. 16–17. DOI: 10.1109/M-
RA.2007.912004
(Culjak, Abram et al. 2012) Culjak, Ivan, Abram, David, Pribanic, Tomislav, Dzapo,
Hrvoje, und Cifrek, Mario, 2012. A brief introduction to
OpenCV. In: Proceedings of the 35th International Con-
vention MIPRO, IEEE, S. 1725–1730,
ISBN: 978-1-4673-2577-6
(Davis 1989) Davis, Fred D, 1989. Perceived usefulness, perceived ease
of use, and user acceptance of information technology.
MIS quarterly Jg. 13 S. 319–340. DOI: 10.2307/249008
(Dhouib, Kchir et al. 2012) Dhouib, Saadia, Kchir, Selma, Stinckwich, Serge, Ziadi,
Tewfik, und Ziane, Mikal, 2012. RobotML, a Domain-
Specific Language to Design, Simulate and Deploy Ro-
botic Applications. In: Simulation, Modeling, and Pro-
gramming for Autonomous Robots: Third Internatio-
nal Conference, SIMPAR, Springer, S. 149–160. DOI:
10.1007/978-3-642-34327-8_16
(Dose und Dillmann 2012) Dose, Sven und Dillmann, Rüdiger, 2012. Shop floor ba-
sed programming of assembly assistants for industrial
pick-and-place applications. In: IEEE/RSJ International
115
Referenzen
Conference on Intelligent Robots and Systems, S. 4966–
4971. DOI: 10.1109/IROS.2012.6385547
(Einhorn, Langner et al. 2012) Einhorn, Erik, Langner, Tim, Stricker, Ronny, Martin,
Christian, und Gross, Horst-Michael, 2012. MIRA - midd-
leware for robotic applications. In: IEEE/RSJ Internatio-
nal Conference on Intelligent Robots and Systems, S.
2591–2598. DOI: 10.1109/IROS.2012.6385959
(Fuchs, Borst et al. 2009) Fuchs, Matthias, Borst, Christoph, Giordano, Paolo Ro-
buffo, Baumann, Andreas, Kraemer, Erich, Langwald,
Jörg, Gruber, Robin, Seitz, Nikolaus, Plank, Georg, Kun-
ze, Klaus et al., 2009. Rollin’Justin-design considerations
and realization of a mobile platform for a humanoid up-
per body. In: IEEE International Conference on Robotics
and Automation, S. 4131–4137. DOI: 10.1109/RO-
BOT.2009.5152464
(Graf, Jacobs et al. 2012) Graf, Birgit, Jacobs, Theo, Luz, Jochen, Compagna, Die-
go, Derpmann, Stefan, und Shire, Karen, 2012. Einsatz
und Pilotierung mobiler Serviceroboter zur Unterstüt-
zung von Dienstleistungen in der stationären Altenpflege.
In: Technologiegestützte Dienstleistungsinnovation in der
Gesundheitswirtschaft, Gabler Verlag, S. 265–288. DOI:
10.1007/978-3-8349-3506-9_11
(Hägele, Blümlein et al. 2011) Hägele, Martin, Blümlein, Nikolaus, und Kleine,
Oliver, 2011. Wirtschaftlichkeitsanalysen neuartiger
Servicerobotik-Anwendungen und ihre Bedeutung für die
Robotik-Entwicklung.
Eine Analyse der Fraunhofer Institute IPA und ISI im Auf-
trag des BMBF, Fraunhofer Gesellschaft
(Hailpern und Tarr 2006) Hailpern, Brent und Tarr, Peri, 2006. Model-driven deve-
lopment: The good, the bad, and the ugly. IBM Systems
Journal Jg. 45(3) S. 451–461. DOI: 10.1147/sj.453.0451
(Halt, Messmer et al. 2012) Halt, Lorenz, Messmer, Felix, Hermann, Marco, Wochin-
ger, Thomas, Naumann, Martin, und Verl, Alexander,
2012. AMADEUS - A robotic multipurpose solution for
116
Referenzen
intralogistics. In: 7th German Conference on Robotics
(ROBOTIK), VDE, S. 1–6,
ISBN: 978-3-8007-3418-4
(Hornung, Wurm et al. 2013) Hornung, Armin, Wurm, Kai M, Bennewitz, Maren,
Stachniss, Cyrill, und Burgard, Wolfram, 2013. OctoMap:
An efficient probabilistic 3D mapping framework based
on octrees. Autonomous Robots Jg. 34(3) S. 189–206.
DOI: 10.1007/s10514-012-9321-0
(Hutchinson, Rouncefield et al. 2011) Hutchinson, John, Rouncefield, Mark, und Whittle, Jon,
2011. Model-driven engineering practices in industry. In:
33rd International Conference on Software Engineering,
IEEE, S. 633–642. DOI: 10.1145/1985793.1985882
(Hvilshoj, Bogh et al. 2009) Hvilshoj, Mads, Bogh, Simon, Madsen, Ole, und Kristi-
ansen, Morten, 2009. The mobile robot ”Little Helper”:
Concepts, ideas and working principles. In: Conference on
Emerging Technologies & Factory Automation (ETFA),
IEEE, S. 1–4. DOI: 10.1109/ETFA.2009.5347251
(Jang, Lee et al. 2010) Jang, Choulsoo, Lee, Seung-Ik, Jung, Seung-Woog, Song,
Byoungyoul, Kim, Rockwon, Kim, Sunghoon, und Lee,
Cheol-Hoon, 2010. OPRoS: A new component-based ro-
bot software platform. ETRI journal Jg. 32(5) S. 646–
656. DOI: 10.4218/etrij.10.1510.0138
(Jouault, Allilaire et al. 2008) Jouault, Frédéric, Allilaire, Freddy, Bézivin, Jean, und
Kurtev, Ivan, 2008. ATL: A model transformation tool.
Science of computer programming Jg. 72(1) S. 31–39.
DOI: 10.1016/j.scico.2007.08.002
(Kent 2002) Kent, Stuart, 2002. Model driven engineering. Integrated
formal methods S. 286–298. DOI: 10.1007/3-540-47884-
1_16
(Khatib, Yokoi et al. 1996) Khatib, Oussama, Yokoi, K, Chang, Kyong-Sok, Ruspini,
Diego C, und Holmberg, Robert, 1996. Vehicle/arm co-
ordination and multiple mobile manipulator decentralized
cooperation. In: IEEE/RSJ International Conference on
Intelligent Robots and Systems, Jg. 2, S. 546–553. DOI:
10.1109/IROS.1996.570849
117
Referenzen
(Kirstan und Zimmermann 2010) Kirstan, Sascha und Zimmermann, Jens, 2010. Evalua-
ting costs and benefits of model-based development of
embedded software systems in the car industry–Results
of a qualitative Case Study.
In: Proceedings Workshop C2M: EEMDD „From code
centric to model centric: Evaluating the effectiveness of
MDD” ECMFA
(Kleppe, Warmer et al. 2003) Kleppe, Anneke G, Warmer, Jos B, und Bast, Wim, 2003.
MDA explained, the model driven architecture: Practice
and promise. Boston, MA, USA: Addison-Wesley Profes-
sional. ISBN: 978-0321194428
(Kolovos, Paige et al. 2008) Kolovos, Dimitrios S, Paige, Richard F, und Polack, Fio-
na AC, 2008. The epsilon transformation language. In:
Theory and practice of model transformations, Springer,
S. 46–60. DOI: 10.1007/978-3-540-69927-9_4
(Lattner und Adve 2004) Lattner, Chris und Adve, Vikram, 2004. LLVM: a
compilation framework for lifelong program analysis
transformation. In: International Symposium on Code
Generation and Optimization, IEEE, S. 75–86. DOI:
10.1109/CGO.2004.1281665
(Metta, Fitzpatrick et al. 2006) Metta, Giorgio, Fitzpatrick, Paul, und Natale, Lorenzo,
2006. YARP: yet another robot platform. International
Journal on Advanced Robotics Systems Jg. 3(1) S. 43–
48. DOI: 10.5772/5761
(Mohagheghi, Gilani et al. 2013) Mohagheghi, Parastoo, Gilani, Wasif, Stefanescu, Alin,
und Fernandez, Miguel A, 2013. An empirical study of
the state of the practice and acceptance of model-driven
engineering in four industrial cases. Empirical Software
Engineering Jg. 18(1) S. 89–116. DOI: 10.1007/s10664-
012-9196-x
(Nassal 1994) Nassal, Uwe M, 1994. An approach to motion planning
for mobile manipulation. In: IEEE/RSJ/GI International
Conference on Intelligent Robots and Systems, Jg. 2, S.
831–838. DOI: 10.1109/IROS.1994.407543
118
Referenzen
(Nordmann, Tuleu et al. 2013) Nordmann, Arne, Tuleu, Alexandre, und Wrede, Sebas-
tian, 2013. A Domain-Specific Language and Simulation
Architecture for Motor Skill Exploration.
arXiv preprint arXiv:1302.6436
(Ögren, Egerstedt et al. 2000) Ögren, Petter, Egerstedt, Magnus B, und Hu, Xiao-
ming, 2000. Reactive mobile manipulation using dyna-
mic trajectory tracking: design and implementation. In:
Proceedings of the 39th IEEE Conference on Decision
and Control, Jg. 3, S. 3001–3006. DOI: 10.1109/RO-
BOT.2000.845267
(Parreiras, Walter et al. 2010) Parreiras, Fernando Silva, Walter, Tobias, und Gröner,
Gerd, 2010. Visualizing ontologies with UML-like nota-
tion. In: Ontology-Driven Software Engineering, ACM,
ODiSE’10, S. 4:1–4:6. DOI: 10.1145/1937128.1937132
(Pfeiffer, Bengel et al. 2011) Pfeiffer, Kai, Bengel, Matthias, und Bubeck, Alexan-
der, 2011. Offshore robotics-Survey, implementation, out-
look. In: IEEE/RSJ International Conference on Intelli-
gent Robots and Systems, S. 241–246. DOI: 10.1109/I-
ROS.2011.6094661
(Poulin, Caruso et al. 1993) Poulin, Jeffrey S., Caruso, Joseph M., und Hancock,
Debera R., 1993. The business case for software reu-
se. IBM Systems Journal Jg. 32(4) S. 567–594. DOI:
10.1147/sj.324.0567
(Quigley, Conley et al. 2009) Quigley, Morgan, Conley, Ken, Gerkey, Brian, Faust,
Josh, Foote, Tully, Leibs, Jeremy, Wheeler, Rob, und
Ng, Andrew Y, 2009. ROS: an open-source Robot Opera-
ting System. In: ICRA workshop on open source software,
Jg. 3,
S. 5
(Reade 1989) Reade, Chris, 1989. Elements of functional pro-
gramming. Boston, MA, USA: Addison-Wesley. ISBN:
978-0201129151
(Reiser, Connette et al. 2009) Reiser, Ulrich, Connette, Christian Pascal, Fischer, Jan,
Kubacki, Jens, Bubeck, Alexander, Weisshardt, Florian,
Jacobs, Theo, Parlitz, Christopher, Hägele, Martin, und
119
Referenzen
Verl, Alexander, 2009. Care-O-bot® 3-creating a product
vision for service robot applications by integrating design
and technology. In: IEEE/RSJ International Conference
on Intelligent Robots and Systems, S. 1992–1998. DOI:
10.1109/IROS.2009.5354526
(Rios, Bozheva et al. 2006) Rios, Erkuden, Bozheva, Teodora, Bediaga, Aitor, und
Guilloreau, Nathalie, 2006. MDD Maturity Model: A
Roadmap for Introducing Model-Driven Development. In:
Model Driven Architecture–Foundations and Applicati-
ons, Springer, S. 78–89. DOI: 10.1007/11787044_7
(Rusu und Cousins 2011) Rusu, Radu Bogdan und Cousins, Steve, 2011. 3D is
here: Point cloud library (PCL). In: IEEE International
Conference on Robotics and Automation, S. 1–4. DOI:
10.1109/ICRA.2011.5980567
(Schlegel und Worz 1999) Schlegel, Christian und Worz, Robert, 1999. The software
framework SMARTSOFT for implementing sensorimotor
systems. In: IEEE/RSJ International Conference on Intel-
ligent Robots and Systems, Jg. 3, S. 1610–1616. DOI:
10.1109/IROS.1999.811709
(Shakhimardanov und Prassler 2007) Shakhimardanov, Azamat und Prassler, Erwin, 2007.
Comparative evaluation of robotic software integration
systems: A case study. In: IEEE/RSJ International Con-
ference on Intelligent Robots and Systems, S. 3031–3037.
DOI: 10.1109/IROS.2007.4399375
(Spinczyk, Gal et al. 2002) Spinczyk, Olaf, Gal, Andreas, und Schröder-Preikschat,
Wolfgang, 2002. AspectC++: an aspect-oriented exten-
sion to the C++ programming language. In: Proceedings
of the Fortieth International Conference on Tools, S. 53–
60,
ISBN: ISBN:0-909925-88-7
(Szyperski, Bosch et al. 1999) Szyperski, Clemens, Bosch, Jan, und Weck, Wolfgang,
1999. Component-oriented programming. In: Object-
oriented technology ecoop’99 workshop, Springer, S. 184–
192. DOI: 10.1007/3-540-46589-8_10
120
Referenzen
(Walderhaug, Mikalsen et al. 2008) Walderhaug, S, Mikalsen, M, Benc, I, und Erlend, S,
2008. Factors affecting developers’ use of MDSD in the
Healthcare Domain: Evaluation from the MPOWER Pro-
ject.
In: From code centric to model centric software enginee-
ring: practices, implications and ROI.
(Washizaki, Yamamoto et al. 2003) Washizaki, Hironori, Yamamoto, Hirokazu, und Fukaza-
wa, Yoshiaki, 2003. A metrics suite for measuring reusa-
bility of software components. In: Ninth International
Software Metrics Symposium, IEEE, S. 211–223. DOI:
10.1109/METRIC.2003.1232469
(Wyrobek, Berger et al. 2008) Wyrobek, Keenan, Berger, Eric, Van der Loos, Machiel,
und Salisbury, Kenneth, 2008. Towards a personal ro-
botics development platform: Rationale and design of an
intrinsically safe personal robot. In: IEEE International
Conference on Robotics and Automation, S. 2165–2170.
DOI: 10.1109/ROBOT.2008.4543527
(Yamamoto und Yun 1993) Yamamoto, Yoshio und Yun, Xiaoping, 1993. Control of
mobile manipulators following a moving surface. In: IEEE
International Conference on Robotics and Automation, S.
1–6. DOI: 10.1109/ROBOT.1993.291930
(Yamamoto und Yun 1995) Yamamoto, Yoshio und Yun, Xiaoping, 1995. Coordina-
ted obstacle avoidance of a mobile manipulator. In: IEEE
International Conference on Robotics and Automation, S.
2255–2260. DOI: 10.1109/ROBOT.1995.525597
121
Roboter, die Mobilität und Manipulation verbinden, stehen in immer 
größerer Anzahl für den Einsatz in Wissenschaft, aber auch in industriellen 
Anwendungen zur Verfügung. Jedoch ist die Softwareentwicklung durch 
die hohe Anzahl an Aktoren und Sensoren für solche Robotersysteme 
aufwändig und komplex. Eine Nutzung ist im industriellen Kontext daher 
oft nicht wirtschaftlich. Ziel dieser Arbeit ist eine Verbesserung der Soft-
wareentwicklung durch modellgetriebene Entwicklungsmethodik herbei-
zuführen, um durch geringeren Aufwand, durch verstärkte Wiederver-
wendung bestehender Software und durch das bessere Separieren von 
Expertenwissen die Entwicklungskosten zu senken.
FRAUNHOFER VERLAG
9 783839 610336
ISBN 978-3-8396-1033-6