Modellgetriebene Softwareentwicklung für Robotiksysteme

Modellgetriebene Softwareentwicklung für Robotiksysteme Andreas Steck, Dennis Stampfer und Christian Schlegel Hochschule Ulm Fakultät Informatik, Prittwitzstr. 10, 89075 Ulm {steck,stampfer,schlegel}@hs-ulm.de Zusammenfassung. Die Erschlieÿung breiter Anwendungspotenziale für Serviceroboter erfordert den Schritt weg von manuell erstellten Einzelentwürfen hin zu baukastenartig zusammengesetzten Systemen. Grundlegend hierfür ist der Schritt weg von codezentrierten hin zu modellgetriebenen Systemen. In modellgetriebenen Ansätzen wird langlebiges Lösungswissen von kurzlebigen Implementierungstechnologien entkoppelt. Durch das Explizieren von Eigenschaften wie Ressourcenbedarf und Kommunikationsverhalten wird die Systemebene adressiert, so dass Zusammensetzbarkeit von ausgereiften Komponenten ebenso unterstützt werden kann wie der Nachweis von Systemeigenschaften. Die so möglichen ressourcenadäquaten Lösungen mit zugesicherten Eigenschaften und der Wiederverwendung ausgereifter Lösungen wird als grundlegend für die eziente Umsetzung der geforderten Qualitätsmaÿstäbe vieler zukünftiger Servicerobotikapplikationen gesehen. Diese Arbeit beschreibt die Umsetzung eines modellgetriebenen Softwareentwicklungsprozesses in OpenArchitectureWare auf der Basis eines Komponentenansatzes und eines Ausführungscontainers, der beispielsweise völlig unabhängig von der Middleware ist. 1 Einleitung Obwohl Software einen groÿen Einuss auf die Entwicklung von Robotiksystemen hat, werden die meisten Systeme dennoch von Hand programmiert. Dabei hat sich in anderen Domänen, wie der Automobilindustrie und der Avionik, längst gezeigt, dass der modellgetriebene Ansatz einen vielversprechenden Weg bietet, um die stetig steigende Komplexität beherrschen zu können. Entscheidend für diesen modellgetriebenen Ansatz ist die Verwendung eines komponentenbasierten Frameworks. Es bildet den Schlüssel zum Erfolg, um Systeme aus mehreren wiederverwendbaren Bausteinen zusammenzusetzen. In diesem Artikel wird der Weg zur modellgetriebenen Softwareentwicklung für die Robotik vorgestellt. Es werden die Schritte von der abstrakten Repräsentation zum ausführbaren Code dargestellt und anhand eines Beispiels verdeutlicht. Zentrum für angewandte Forschung an Fachhochschulen Servicerobotik (ZAFH Servicerobotik) http://www.zafh-servicerobotik.de/

2 Motivation und Stand der Technik Durch grundsätzliche Mängel in der Softwareentwicklung von Robotersystemen werden die vorhandenen Fähigkeiten der Community nicht ausreichend genutzt. So ist die Wiederverwendung von Software meist nur auf der Ebene von Bibliotheken möglich. Die Möglichkeit, Software als Komponenten-Bausteine mit garantierten Services und Funktionalitäten zu nutzen, ndet dabei bisher keine ausreichende Verbreitung. Um die zunehmende Komplexität zu beherrschen, ist daher ein hoher Grad an Wiederverwendbarkeit durch ein solches Baukastensystem anzustreben. Bei der Integration der einzelnen Bestandteile zu einem Gesamtsystem wird häug auf einer unzureichenden oder keiner Basis aufgebaut. Der Aufwand und die Qualität der Integration hängt dann von den Möglichkeiten der Middleware ab. Dieses Vorgehen ist teuer und kostet den Entwickler unnötig viel Zeit, die an anderer Stelle sinnvoller investiert wäre. Der Schritt von der codegetriebenen zur modellgetriebenen Softwareentwicklung ist entscheidend, um die genannten Schwierigkeiten zu lösen. Zusätzlich können auf der Modellebene komfortabel komponentenbasierte Systeme entworfen werden. Die Services können mit Contracts versehen und später mit geeigneter Toolunterstützung veriziert werden. Bereits während der Entwicklung wird so veriziert, ob das Zielsystem beispielsweise garantierte Antwortzeiten oder Ressourcenbeschränkungen (Resource-Awareness) einhalten kann. Es können Sicherheitsaspekte einbezogen und Quality of Service (QoS)-Parameter expliziert werden. Im Bereich distributed real-time und embedded (DRE) gibt es Anforderungen aus der Automobilindustrie und Avionik, die vergleichbar komplex zur Robotik sind. Dort werden ähnliche Fragestellungen beispielsweise vom Artist2 Network of Excellence on Embedded Systems Design [1] bezüglich Echtzeitkomponenten und Echtzeit-Ausführungsumgebungen behandelt. Durch die OMG MARTE [2] Initiative wird ein standardisiertes UML Prol zur Entwicklung von DRE Systemen zur Verfügung gestellt. Die Komponenteninteraktionen sind sehr generisch beschrieben. Die Granularität, wie ein komplexes System aus seinen Bestandteilen zusammengesetzt wird, ist nicht eindeutig festgelegt und lässt sehr viel Spielraum. Unsere Konzepte dagegen leiten den Entwickler durch den vorgegebenen Rahmen an, ohne dabei die Freiheiten einzuschränken. Die Automobilindustrie ist dabei, den AUTOSAR Standard [3] für Softwarekomponenten und den modellgetriebenen Entwurf zu etablieren. Dort werden Fragestellungen behandelt, die auch in der Servicerobotik in ähnlicher Form relevant sein können. Die OMG Robotics Domain Task Force [4] arbeitet an einem modellgetriebenen Standard zur Integration von Robotiksystemen aus modularen Komponenten. Die Komponenten verfügen wie in unserem Komponentenmodell über einen internen Zustandsautomaten und interagieren über Serviceports. Diese Ports sind jedoch nicht genau speziziert. Die Referenzimplementierung ist stark von CORBA getrieben. In dieser Arbeit wird eine von der Middlewarestruktur unabhängige Abstraktionsebene vogestellt.

OROCOS [5] adressiert die Entwicklung von Echtzeit-Regelungssystemen, bei denen der Komponentenentwickler sogenannte Hotspots ausfüllt. Die Interaktionen im Real-Time Toolkit basieren im Kern auf einer Dataow Architektur, während unser Fokus darauf liegt ein breites Spektrum an Interaktionsschemata zu unterstützen. Das V 3 Studio [6] bendet sich noch in der Entwicklung und ist bisher nicht öentlich verfügbar. Beispielsweise sind die Transformationen aus einem V 3 Studio Modell in ein Robotik Framework nicht implementiert. Wir teilen die grundlegenden Sichtweisen von Iborra et al. Das Eclipse Projekt [7] entwickelt sich zum De-facto-Standard und bietet eine Vielzahl an Plugins für den modellgetriebenen Ansatz. So ist sowohl open- ArchitectureWare (oaw) [8] als auch Papyrus UML [9] vollständig in Eclipse integriert. 3 SmartSoft Laser Server Self Localization Map Building Path Planning Motion Execution Base Server Um die Komplexität der Robotik beherrschen zu können, ist ein komponentenbasierter Ansatz nötig. Das Gesamtsystem wird aus mehreren Komponenten zusammengesetzt, die über vorgegebene Interaktionsmuster mit festgelegter Semantik miteinander kommunizieren [10]. Dieser Ansatz wird bei SmartSoft verfolgt und bildet die Grundlage für unsere Arbeit. Die Auswahl der Muster ist ausreichend, da sie sowohl Request/Response Interaktionen als auch asynchrone Mitteilungen und Push Services zur Verfügung stellen. Daraus ergeben sich lose gekoppelte Komponenten, die über Services kommunizieren und einen Contract erfüllen (Abb. 1). Demnach kann SmartSoft unter zwei verschiedepush timed <laserscan> send <pose update> push newest <map> send <waypoint> send <motion command> push timed <base state> Abb. 1. Typische Komponenten einer Navigationsanwendung, die über standardisierte Interaktionsmuster miteinander interagieren. nen Gesichtspunkten betrachtet werden. Zum einen handelt es sich um ein abstraktes, komponentenbasiertes Konzept, welches völlig unabhängig von jeglicher Implementierungstechnologie und Middlewarestruktur ist. Zum anderen existieren spezische Implementierungen wie beispielsweise CorbaSmartSoft [11], das auf ACE/TAO [12] basiert. Bei den spezischen Implementierungen sind die Ideen, die durch SmartSoft beschrieben sind, mit den jeweiligen Technologien und Middlewarestrukturen umgesetzt. Die Mechanismen skalieren vom 8 Bit Mikrocontroller bis zum hochperformanten Standardsystem [13].

4 Der modellgetriebene Ansatz Grundlegend für den modellgetriebenen Ansatz ist die Dierenzierung zwischen dem plattformunabhängigen Modell (PIM), dem plattformspezischen Modell (PSM) und der plattformspezischen Implementierung (PSI). Im ersten Schritt modelliert der Komponentenentwickler eine Komponentenhülle mit denierten Serviceports unabhängig von der Zielplattform (Abb. 2). Er bedient sich dabei aus einer Menge vorgegebener Elemente (Tasks, Ports, Handler,...). Durch PIM der Komponentenhülle PSI User Code Transformation u. Verifikation (z.b. QoS) legacy code RTAI Lab / OpenCV MATLAB / Simulink Qt / Kavraki Lab /... User Space Neutral Fatal Config Send Param Alive Query Push User Space Wiring etc. Interface Execution Environment Threads / Mutex / Timer Lauffähige Komponente Abb. 2. Die Komponentenhülle wird durch Transformationen in ein PSI überführt. Der Komponentenentwickler fügt beliebige Implementierungen hinzu. Knopfdruck wird der Code für die Hülle erzeugt und Parameter des Modells werden veriziert. Es wird ausschlieÿlich die Hülle generiert und eigener Code sowie externe Bibliotheken können integriert werden. Die im Hintergrund ablaufenden Schritte werden im Folgenden beschrieben. Die Abbildung 3 gibt den Gesamtüberblick über den Workow. PIM PSM PSI SmartMARS (Modeling and Analysis of Robotics Systems) UML2 Profile platform independent stereotypes M2M oaw xtend CorbaSmartSoft CORBA based implementation of SmartSoft AceSmartSoft ACE based implementation of SmartSoft Microsoft Robotic Studio MSRS based implementation... any other middleware M2T oaw xpand Config Param Neutral Alive User Space Fatal User Space legacy code MATLAB / Simulink RTAI Lab / OpenCV Qt / Kavraki Lab /... Interface Execution Environment Threads / Mutex / Timer Send Query Push Wiring etc. UML2 Profile platform specific stereotypes Abb. 3. Der Workow zeigt die Übergänge vom plattformunabhängigen Modell (PIM) hin zu einem der plattformspezischen Modelle (PSM) und von dort zur jeweiligen plattformspezischen Implementierung (PSI).

4.1 Platform Independent Model (PIM) Das plattformunabhängige Modell (PIM) ist frei von jeglichen Technologie- und Middlewarestrukturen. Nachdem die SmartSoft Konzepte seit Jahrzehnten erfolgreich in verschiedenen Robotiksystemen eingesetzt werden, bieten sie eine vielversprechende Ausgangssituation auf dem Weg zur modellgetriebenen Softwareentwicklung solcher Systeme. Diese allgemeinen Konzepte bilden die Grundlage für das plattformunabhängige Modell SmartMARS: Modeling and Analysis of Robotics Systems (Abb. 4). Eine Komponente stellt verbindliche interne Struk- Mutex Semaphore QueryHandler ConfigPort Task Component Interaction Pattern ParamPort EventTestHandler... StateAutomaton EventHandler WiringMaster R A D QueryServer SendServer WiringSlave QueryClient R A SendClient PushServer D D PushClient EventServer D P E EventClient P E Abb. 4. Ein Ausschnitt des SmartMARS UML Prols turen zur Verfügung [13], wie spezielle standardisierte Ports zur Parametrierung und Konguration des internen Komponentenverhaltens. Ein interner Zustandsautomat setzt sich aus Zuständen wie beispielsweise neutral, alive und fatal zusammen. Die Ports einer Komponente werden aus den vorgegebenen Interaktionsmustern zusammengestellt. Durch Kommunikationsobjekte ist der Austausch beliebiger Datenstrukturen möglich. Dies stellt sicher, dass sich interne Verhaltensweisen nicht über Komponentengrenzen ausweiten können. Durch die an die Stereotypen angehängten Tagged Values können die Metaelemente parametriert werden. Die Elemente im Modell erlauben eine Zuweisung von QoS Parametern. Dies bietet die Möglichkeit, externe Tools zur Verikation der Parameter in den Entwicklungsprozess einzubinden. So können beispielweise Ressourcen- und zeitliche Anforderungen gegenüber den Möglichkeiten der Zielplattform überprüft werden. Um Verhalten abbilden zu können, wird ein Statechart modelliert, der sich in den alive Zustand des internen Zustandsautomaten einbindet. An den Statechart angehängte Annotationen vereinheitlichen die Komponentenzugriffe, um das Verhalten der Komponenten des Gesamtsystems zu instrumentieren. Damit kann beispielsweise durch externe Events der Datenuss zwischen den Komponenten zur Laufzeit geändert werden.

4.2 Platform Specic Model (PSM) Je nach Implementierungstechnologie und Middlewarestruktur kann es beliebig viele plattformspezische Modelle geben. Diese PSMs werden durch Model- Model Transformation (M2M / oaw xtend) aus dem PIM erzeugt. Das PSM bildet die Zwischenebene zwischen dem PIM und der plattformspezischen Implementierung (PSI). Es abstrahiert die Konzepte und Eigenheiten des Frameworks, gegen das bei der späteren Codegenerierung generiert wird (Abb. 5 links). Diese Tasks Tasks Mutex Mutex Betriebssystem Framework Pattern... Corba ACE... RPC Socket Middleware Sockets... Core Rahmen für Tasks, Handler,..................... Userspez. Code: Tasks, Handler,... <<singleton>> Komponentenhülle Ports,... User erweiterungen Generierter Code User Code Funktionalität Ausführungsumgebung Abb. 5. Links: Die Schnittstelle des Frameworks, gegen die der Generator generiert; Rechts: Die Struktur der Komponente auf Quellcodeebene. Zwischenebene muss für jede Middleware nur einmal implementiert werden. Der Aufwand ist abhängig davon, wie leicht sich die Konzepte aus SmartSoft dort umsetzen lassen. Werden von der Ziel-Middleware nur wenige der geforderten Konzepte unterstützt, müssen diese durch das Framework mit den vorhandenen Mechanismen realisiert werden. Die PSMs werden ebenfalls als UML Prole realisiert, wie beispielsweise das CorbaSmartSoft UML Prol. Unsere Arbeit konzentriert sich derzeit hauptsächlich auf dieses PSM, obwohl auch PSMs für andere Robotik-Frameworks integriert werden können (z.b. Microsoft Robotics Studio [14]). 4.3 Codegenerierung aus dem PSM in die PSI Aus dem PSM wird der Quellcode für die Komponentenhülle durch Model-Text Transformation (M2T / oaw xpand) generiert. Der Entwickler integriert seine Algorithmen und kann sich dabei frei innerhalb der Hülle bewegen. Es können sowohl Quellen aus anderen Tools (MATLAB Simulink, RTAI Lab,...) als auch beliebige Libraries (OpenCV, Qt, Kavraki Lab,...) eingebunden werden. Um die Wiederverwendbarkeit unabhängig vom PSM und die Einbindung von Bibliotheken sicherzustellen, ist es notwendig, bei der Codegenerierung strikt zwischen generierten Code und userspezischen Code zu trennen (Abb. 5 rechts). Die Trennung basiert auf dem Generation Gap Pattern [15]. Durch Ableiten von den entsprechenden Core-Klassen (Tasks, Handler,...) kann der Entwickler

eigenen Quellcode integrieren. Um auf alle Elemente (Serviceports, Tasks, Mutex,...) der Komponente zugreifen zu können, ist die Klasse, welche die Komponente selbst repräsentiert, als Singleton realisiert. Die Verwendung des Singleton hat keinen Einuss auf die Auÿensicht der Komponente, da Komponenten in der verwendeten Implementierung von SmartSoft (CorbaSmartSoft) als Prozess abgebildet sind. Beim Wechsel des PSM von CorbaSmartSoft auf eine andere Smart- Soft Implementierung erfolgt die Generierung der PSI transparent. Gleiches gilt beispielsweise für Anpassungen an den Serviceports, wenn diese im PIM von aktiver auf passive Behandlung der Anfragen umgeschaltet werden. Es sind in beiden Fällen keine Anpassungen am Usercode notwendig. 5 Beispiel Abbildung 6 zeigt einen möglichen Workow am Beispiel einer Mapper Komponente (SmartMapperGridMap). Unter Verwendung des SmartMARS Prols wird die Komponente mit ihren Serviceports, Tasks und Handlern mit Papyrus UML modelliert. In dieser Ebene legt der Entwickler die gesamte Struktur seiner Komponente fest. Durch die Model-Model Transformation (M2M) wird das Abb. 6. Der Workow anhand eines praktischen Beispiels. Links: PIM der Mapper- Komponente; Mitte: UML Modell des PSM; Rechts: Ausschnitt zeigt generierten Code. PSM erzeugt. Das Beispiel verwendet das CorbaSmartSoft Prol als Metamodell für das PSM. Diese Ebene bleibt jedoch vor dem Komponentenentwickler verborgen. Schlieÿlich wird aus dem PSM durch Model-Text Transformation (M2T) der Quellcode generiert. Der Entwickler fügt nun die für den Mapper spezischen Algorithmen hinzu und erhält so eine lauähige Komponente. Im PIM können Änderungen, wie beispielsweise das Setzen des Tagged Values isactive eines Handlers von passiver auf aktive Behandlung, vorgenommen werden. Durch Knopfdruck wird die PSI neu generiert. Die veränderten Serviceeigenschaften sind nun ohne Quellcodeänderungen verfügbar.

6 Zusammenfassung und Ausblick Der vorgestellte Ansatz zeigt die maÿgeblichen Schritte, die auf dem Weg zur modellgetriebenen Softwareentwicklung in der Robotik nötig sind. Basierend auf einem komponentenbasierten Konzept wird die middlewarespezische Komponentenhülle von der eigentlichen Userimplementierung getrennt. Dadurch, dass nur die Komponentenhülle genertiert wird und der Entwickler seine spezischen Implementierungen und Bibliotheken selbst einbindet, ist dieser Ansatz der Schlüssel zum Erfolg. Das vorgestellte Beispiel zeigt anhand einer einfachen Komponente die Toolchain im praktischen Einsatz [11]. Einer der nächsten Schritte ist es, das Deployment der einzelnen Komponenten auf die Zielsysteme und eine darauf basierende Verikation der Quality of Service Parameter zu realisieren. Literaturverzeichnis 1. ARTIST, Network of excellence on embedded system design, 2009, http://www.artist-embedded.org/, visited on June 17th 2009. 2. OMG MARTE, Modeling and analysis of real-time and embedded systems, 2009, http://www.omgmarte.org/, visited on June 17th 2009. 3. AUTOSAR, Automotive open system architecture, 2009, http://www.autosar.org/, visited on June 17th 2009. 4. OMG Robotics, OMG Robotics Domain Task Force, 2009, http://robotics.omg.org/, visited on June 17th 2009. 5. H. Bruyninckx, P. Soetens, and B. Koninckx, The real-time motion control core of the Orocos project, in Proc. IEEE International Conference on Robotics and Automation ICRA '03, vol. 2, 14-19 Sept. 2003, pages 27662771. 6. A. Iborra, D. Caceres, F. Ortiz, J. Franco, P. Palma, and B. Alvarez, Design of service robots, IEEE Robotics and Automation Magazine, vol. 16, no. 1, pages 2433, March 2009. 7. ECLIPSE, 2009, http://www.eclipse.org/, visited on June 17th 2009. 8. openarchitectureware, Platform for model-driven software development, 2009, http://www.openarchitectureware.org/, visited on June 17th 2009. 9. PAPYRUS UML, 2009, http://www.papyrusuml.org/, visited on June 17th 2009. 10. C. Schlegel, Software Engineering for Experimental Robotics, STAR series. Springer, 2007, vol. 30, ch. Communication Patterns as Key Towards Component Interoperability, pages 183210. 11. SmartSoft, 2009, http://smart-robotics.sourceforge.net, visited on June 17th 2009. 12. D. Schmidt, Adaptive Communication Environment, The ACE ORB, 2009, http://www.cs.wustl.edu/schmidt/ace.html, visited on June 17th 2009. 13. C. Schlegel, T. Haÿler, A. Lotz and A. Steck, Robotic Software Systems: From Code-Driven to Model-Driven Designs In Proc. 14th Int. Conf. on Advanced Robotics (ICAR), Munich, 2009. 14. Microsoft, Microsoft robotics developer studio, 2009, http://msdn.microsoft.com/en-us/robotics/default.aspx, visited on June 17th 2009. 15. John Vlissides, Pattern Hatching - Generation Gap Pattern, 2009, http://researchweb.watson.ibm.com/designpatterns/pubs/gg.html, visited on June 17th 2009.