Zwar sind domänenspezifische Spra-chen (DSLs) nicht neu, aber ins-besondere im Umfeld der einge-betteten Softwareentwicklu...
Controller und einem Entwicklungssys-tem. Welche Datenfelder das SUD zurVerfügung stellt und wie sie formatiertsind, legt ...
Die Plug-ins unterstützen die Anwen-dung der DSL durch Syntaxhervorhebungund Autovervollständigung. Damit hatder Entwickle...
einen Systems die Daten eines anderenSystems referenzieren, ohne dass es des-sen Definitionen wiederholen muss.Über diese ...
Nächste SlideShare
Wird geladen in …5
×

Eingebettete Systeme und Xtext: iX Magazin 5/2013

965 Aufrufe

Veröffentlicht am

Eingebettete Systeme sind selten isoliert. Der Normalfall ist, dass sie mit vielen anderen Systemen Daten austauschen.Dazu bedarf es Schnittstellen, die auch bei Änderungen im Quellcode konstant bleiben. Formale Beschreibungen, formuliert in einer domänenspezifischen Sprache, halten den dafür nötigen Aufwand gering.
Artikel von Jonatan Antoni im iX Magazin Ausgabe 5/2013.
https://www.xing.com/profile/Jonatan_Antoni

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
965
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
13
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Eingebettete Systeme und Xtext: iX Magazin 5/2013

  1. 1. Zwar sind domänenspezifische Spra-chen (DSLs) nicht neu, aber ins-besondere im Umfeld der einge-betteten Softwareentwicklung nicht weitverbreitet. Dabei gibt es mittlerweile, et-wa mit Eclipse/Xtext, ausgereifte und li-zenzkostenfreie Werkzeugunterstützungfür DSLs. Wie man damit arbeitet, hat iXbereits in mehreren Artikeln exemplarischgezeigt [1], [2]. Der vorliegende Artikelunterstreicht insbesondere den Mehrwerteiner DSL zur formalen Erfassung von Da-ten eingebetteter Systeme. Durch Code-generatoren kann über ein solches Modelleine bisher meist ungekannte Konsistenzvon Daten über Systemgrenzen hinwegerreicht werden.Die Entwicklung eingebetteter Syste-me und deren Integration in Systemland-schaften stellt Softwareingenieure vorwiederkehrende Herausforderungen, da-runter den Datenaustausch. Isolierte einge-bettete Systeme sind eher die Ausnahme.Mindestens während der Entwicklung,aber in der Regel auch für den späterenEinsatz, ist der Datenaustausch eine zen-trale Anforderung. Während der Ent-wicklung wollen die Programmiererselbst wissen, welchen Zustand ihr Sys-tem gerade hat; sei es zur Optimierungder Algorithmen oder schlicht zum auto-matisierten Testen des Systems. Im spä-teren Einsatzszenario muss die Softwaremit anderen Systemen innerhalb der Sys-temlandschaft interagieren, also ebenfallsDaten austauschen.Entwickler lernenauf der Meta-EbeneDaher stellt sich die Frage, wie sich dieKonsistenz des Datenaustauschs komfor-tabel sicherstellen lässt. Abzugrenzen istdiese Aufgabenstellung gegen vergleich-bare im Enterprise-Umfeld, bei denenverschiedene Back- und Frontend-Syste-me zu integrieren sind. Die dort verbrei-teten XML- oder JSON-Schnittstellen,etwa bei WebServices, sind mangelsRessourcen für eingebettete Anwendun-gen häufig nicht einsetzbar. Die Laufzeit-anforderungen beispielsweise für einenXML-Parser sprengen insbesondere beiAnwendungen mit kleineren Mikrocon-trollern meist den Rahmen.Entwickler können jedoch auf derMeta-Ebene von dieser Enterprise-Me-thodik lernen. Die Systeme sind zwargrößer und leistungsfähiger, aber dieZiele sind sehr ähnlich: konsistenteSchnittstellen zur Vernetzung mehrererSysteme innerhalb einer Systemland-schaft.Die Komplexität heutiger Systemland-schaften bringt meistens nicht eine ein-zelne Schnittstelle mit sich, sondern er-fordert die Unterstützung verschiedenerInterfaces. Je nach Anwendungsfall müs-sen die Daten über eine (serielle) Punkt-zu-Punkt-Verbindung übertragen werdenoder über Bussysteme wie RS485, CANund so weiter.Abbildungˇ1 skizziert beispielhaft einSystemumfeld. Das „System under De-velopment“ (SUD) ist umgeben vonweiteren Systemen, etwa einem Master100 iX 5/2013REPORT | EMBEDDED SYSTEMSSchnittstellen mit eingebetteter Konsistenz mit Xtext generierenIm ZuschnittJonatan AntoniEingebettete Systeme sind selten isoliert. Der Normalfall ist,dass sie mit vielen anderen Systemen Daten austauschen.Dazu bedarf es Schnittstellen, die auch bei Änderungen imQuellcode konstant bleiben. Formale Beschreibungen, formu-liert in einer domänenspezifischen Sprache, halten den dafürnötigen Aufwand gering.FA-266, 2013
  2. 2. Controller und einem Entwicklungssys-tem. Welche Datenfelder das SUD zurVerfügung stellt und wie sie formatiertsind, legt implizit der Quellcode desSUD fest. Eine Änderung an diesen Da-tenfeldern wirkt sich an vielen weiterenStellen des Gesamtsystems aus, etwa auf–ˇden Master Controller,–ˇdas Slave-Systemˇ1,–ˇdas Slave-Systemˇ2,–ˇdie Testschnittstelle und–ˇdie Simulationen der Systemumgebung.Je nach Zielplattform kommen dabeiin der Regel unterschiedliche Entwick-lungswerkzeuge zum Einsatz. Die Soft-ware für das eingebettete System imple-mentieren Entwickler häufig mit C/C++,während sie für PC-Tools beispielsweiseC oder Java nutzen. Dazu kommen An-forderungen zum Protokollieren und Wei-terverarbeiten mit Standardwerkzeugenoder Anbindungen an Simulations- undTestsysteme wie MatLab/Simulink oderLabView/Teststand.Datentypen müssenkonsistent bleibenAlle direkten oder indirekten Kommuni-kationspartner in der Systemlandschaftbenötigen konsistente Datendefinitio-nen. Es gilt festzulegen, welche Daten esgibt, wie sie formatiert sind und auf wel-che Weise man sie anspricht. Es wirdschnell klar, dass eine manuelle Imple-mentierung und Pflege mit steigenderDatenmenge und Anzahl an Kommuni-kationspartnern nicht mehr handhabbarist. Nicht nur der immense Arbeitsauf-wand, um eine Änderung an vielen Stel-len nachzuziehen, fällt hier ins Gewicht.Viel gravierender ist die Fehlerwahr-scheinlichkeit und der daraus resultie-rende Test- und Korrekturaufwand.Um die Enterprise-Parallele nochmalszu bemühen: Man braucht also eine ArtXSD (XML Schema Definition), eineformale Definition von Strukturen fürXML-Dokumente speziell für eingebet-tete Systeme.Eine denkbare Lösung beginnt mit derBeherzigung einiger Prinzipien, die sich inanderen Softwarebereichen bereits durch-gesetzt haben. Darunter fallen insbesonde-re das Prinzip des „Single Point of Truth“aus dem Datenmanagement [3] sowie derin der Softwareentwicklung bekannteLeitsatz „Don’t repeat yourself“ [4].Eine formale Beschreibung der Datendes eingebetteten Systems auf Domänen-ebene wird beiden Prinzipien gerecht.Dazu ist eine domänenspezifische Spra-che besonders geeignet. Gegenüber einerrein tabellarischen Erfassung, etwa mit-tels einer relationalen Datenbank mitstarren Tabellenschemata, erlaubt eineDSL weitaus mehr Freiheiten, um dieDaten zu beschreiben. Als Werkzeug bie-tet sich das im Java/Eclipse-Umfeld mitt-lerweile verbreitete Xtext (siehe Online-quellen [a] und „Alle Links“) geradezuan. Diese Lösung kommt zudem ohneden XML-typischen „Spitze-Klammern-Salat“ aus. Mit Eclipse/Xtext steht eineinzwischen ausgereifte Werkzeugkettezur Erstellung und Anwendung textuellerDSLs zur Verfügung.Plug-ins für dengewohnten KomfortListingˇ1 zeigt ein Beispiel für eineXtext-Syntaxdefinition in abgewandel-ter EBNF-Notation (Erweiterte Backus-Naur-Form [5]). Die erste Definition bildetdie Wurzel im entstehenden Syntax-baum. ID, FLOAT und STRING sind Ter-minale, die hier als gegeben angenom-men sind. Mit [<Definition>] werdenQuerreferenzen im Syntaxbaum erzeugt.Aus dieser Syntaxbeschreibung generiertdas Xtext-System einen Parser auf Basisvon Antlr [b] sowie Editor-Plug-ins fürEclipse.iX 5/2013 101x-TRACTG Eingebettete Systeme haben in der Regel diverse Schnittstellen, über die siemit anderen Systemen Daten austauschen.G Ein in einer domänenspezifischen Sprache formuliertes Modell zur Erfassung derDaten hilft, deren Konsistenz auch bei Änderungen im Quellcode zu erhaltenund manuelle Modifikationen auf ein Minimum zu reduzieren.G Mit dem Eclipse-Projekt Xtext lässt sich auf komfortable Weise ein formalesDatenmodell in einer solchen DSL entwerfen, aus dem die Transformations-sprache Xtend dann Javacode erzeugen kann.Master-Controller-SimulationMaster-ControllerSystem underDevelopment(SUD)Control-/Observation-APISlave-System 1 Slave-System 2Slave-System-SimulationEntwicklungssystemEntwicklungs-, Simulations-und TestwerkzeugePunkt-zu-PunktBUSPunkt-zu-PunktEine Systemlandschaft mit eingebetteten Systemen: Der PC bindet die Entwicklungs-/Simulations- und Testwerkzeuge ein und dient je nach Szenario als Simulator für dasgesamte Systemumfeld (Abb.ˇ1).Model:definitions+=Definition+;Definition:TypeDefinitionDataDefinition;TypeDefinition:Type name=ID(type=PlainTypefields+=Field+);Field:name=IDtype=PlainType;DataDefinition:Data name=IDtype=[TypeDefinition];PlainType:number(resolution=FLOAT)?(unit=STRING)?text;Listing 1: Xtext-Syntaxdefinition
  3. 3. Die Plug-ins unterstützen die Anwen-dung der DSL durch Syntaxhervorhebungund Autovervollständigung. Damit hatder Entwickler mit minimalem Aufwandim Prinzip alles, was er von modernenEntwicklungsumgebungen gewohnt ist.Mit der DSL kann er die Daten formal er-fassen. Listingˇ2 modelliert exemplarischzwei physikalische Typen mit jeweils ei-nem Datenfeld. Angedeutet wird die De-finition von Auflösungen und Einheiten-bezeichnern, die etwa in C/C++ nichtdirekt zur Verfügung stehen. Die Ver-wendung der Werte lässt sich damit aufModellebene beispielsweise hinsichtlichkompatibler Einheiten validieren.Die Freiheiten bei der Definition derDSL erlauben es, sich sehr nahe an derProblemdomäne zu orientieren, etwaDatenfelder mit physikalischen Einhei-ten zu definieren. Entwickler könnensich direkt der Sprache der Domänen-experten bedienen, ohne bereits bei derDefinition der Daten allzu technischwerden zu müssen. Zwar wird der ange-strebte Technikabstand dennoch in vie-len Fällen eher gering ausfallen, da dieDaten meist auch in der Domäne einentechnischen Hintergrund haben. Wichtigist aber dennoch ein gewisser Abstandzur konkreten Implementierung in einerProgrammiersprache.Mit Xtend elegantenCode erzeugenIm dritten Schritt kann man jetzt mitXtend [c] auf elegante Weise aus demDatenmodell Code erzeugen. Dabei pro-fitiert man von der Domänenlastigkeitdes Datenmodells, da man erst jetzt fest-legen muss, wie diese Daten in der jewei-ligen Zielsprache technisch darzustellensind. Auf diesem Wege gelingt es, aus ei-ner einheitlichen Spezifikation technischeUmsetzungen für die verschiedenen Ziel-umgebungen zu erzeugen. Dazu zählenetwa geeignete Typdefinitionen, um dieDomänendaten effizient darzustellen.Aber auch Zugriffs-, Konvertierungs- undSerialisierungsfunktionen für den Daten-austausch zwischen den Systemen lassensich einheitlich generieren. Darüber hin-aus kann der Entwickler über ein Quell-code-Template den generierten Code hin-sichtlich der Effizienz optimieren, da erdort beispielsweise auf nicht benötigteGeneralisierung verzichten kann.Ein Beispiel für die Datenhaltung undden Austausch einer Temperatur könntewie folgt aussehen. Für die C/C++-Im-plementierung wird ein Fließkomma-wert einfacher Genauigkeit gewählt. DieSchnittstellenspezifikation für den Da-tenaustausch über CAN (Controller AreaNetwork) schreibt jedoch die Verwen-dung von Festkommawerten vor. DerTemperaturwert muss zur Übertragungmit geeigneten Konvertierungsfunktionenbeispielsweise in einen 16-Bit-Festkom-mawert mit zwei Nachkommastellenkonvertiert werden.Listingˇ3 zeigt den Ausschnitt einesdenkbaren Codegenerators in Xtend. Mitden Template-Strings, eingefasst in drei-fachen Hochkommata, steht eine elegan-te Möglichkeit zur Codegenerierung zurVerfügung, bei der die Einrückung desZielcodes erhalten bleibt, um lesbarenCode zu erzeugen. Innerhalb der Tem-plate-Strings kann der Entwickler mitGuillemets («...») eingeschränkte Kon-trollstrukturen nutzen oder Java/Xtend-Methoden aufrufen, deren Rückgabe alsTest eingefügt wird. Ebenfalls erwäh-nenswert ist die ausgeklügelte Leerzei-chenerkennung. Sie stellt sicher, dassder generierte Code die korrekte Einrü-ckung erhält, ohne dass man einen nach-gelagerten Code Beautifier einsetzenmuss. Dies unterstützt den Entwicklererheblich bei der Generierung lesbarenCodes. An dieser Stelle sei für weitereDetails auf die Xtend-Dokumentationverwiesen.Den GenerierungseffektvervielfachenDer Generierungs-Effekt vervielfachtsich nochmals, wenn man die Datenmehrerer Systeme in Modellen erfassthat und diese miteinander verknüpft. Sokann beispielsweise das Datenmodell desREPORT | EMBEDDED SYSTEMSDie Datendefinitionensind aus dem Quell-code des SUD in einDatenmodell ausgela-gert. Codegeneratorengenerieren den not-wendigen Quellcodesowohl für das SUDals auch für die um-liegenden Systeme(Abb.ˇ2).Master-Controller-SimulationMaster-ControllerSUD-Daten-modellSystem underDevelopment(SUD)Control-/Observation-APISlave-System 1 Slave-System 2Slave-System-SimulationEntwicklungssystemEntwicklungs-, Simulations-und TestwerkzeugePunkt-zu-PunktBUSPunkt-zu-PunktType Temperaturevalue number 0.01 ""sensorStatus textData RoomTemperature TemperatureType Pressurevalue number 0.1 "hPa"sensorStatus textData AirPressure PressureListing 2: Mögliches Datenmodellclass Generator : IGeneratordef void doGenerate(Resource rsrc,FileSystemAccess fsa)val types = rsrc.definitions.filter(typeof(TypeDefinition))fsa.generateFile("types.h",generateTypesH(types))def generateTypesH(List<?> types)«FOR type : types»«type.typedef»«ENDFOR»def getTypedef(TypeDefinition type)[...]Listing 3: Codegenerator in Xtend(Ausschnitt)102 iX 5/2013
  4. 4. einen Systems die Daten eines anderenSystems referenzieren, ohne dass es des-sen Definitionen wiederholen muss.Über diese formal erfassten Referenzenlassen sich Datenaustauschvorschriftenfür die beteiligten Systeme generieren.Der Vollständigkeit halber seien Aspektewie eine generierte Schnittstellendoku-mentation, die Schnittstellenversionierungund das Management der Abhängig-keiten ebenfalls erwähnt. Diese Maßnah-men helfen, Gespräche wie „Sag mal,benutzt diesen Wert eigentlich irgend-wer?“ – „In welcher Version denn?“ zuvermeiden.Wenig neuer Quellcodebei ÄnderungenDer generierte Code stellt sicher, dass dieDatenformate über alle beteiligten Syste-me, Protokolle und Schnittstellen hinwegbekannt sind. Eine Änderung am Daten-format eines Systems wirkt sich bei derGenerierung auf alle abhängigen Systemeaus. So steht beispielsweise ein neuer Da-tenwert des eingebetteten Beispielsys-tems ohne weiteres Zutun auch in derSchnittstelle des Testsystems zur Verfü-gung. Abbildungˇ2 skizziert die generier-ten Abhängigkeiten, die bestehen, nach-dem die impliziten Datendefinition ausdem SUD in ein explizites Datenmodellextrahiert wurden.Pauschal quantifizieren lässt sich derNutzen allerdings nicht. Ein Beispiel auseinem realen Projekt verdeutlicht den po-tenziellen Nutzen. In Abbildungˇ3 ist derUmfang der manuell geschriebenen Arte-fakte im Verhältnis zu den generiertendargestellt. Die Relation zwischen hand-geschriebenen und generierten Zeilenliegt ungefähr bei 1ˇ:ˇ8. In diesem Projektwirkt sich das Einfügen eines neuen Da-tenfelds mit etwa zehn neuen ZeilenDSL-Modellcode auf 17 generierte Datei-en aus und erzeugt insgesamt 798 neueZeilen Quellcode (siehe Abbildungˇ4).Selbst wenn man unterstellt, dass ein er-fahrener Entwickler manuell kompakte-ren Quellcode erzeugt, ist eine Änderungan 17 Dateien kaum zu vermeiden. Einkleiner Tippfehler in nur einer dieser Da-teien führt vermutlich zu einer langwieri-gen Fehlersuche.FazitDurch den Einsatz einer domänenspezi-fischen Sprache zur formalen Erfassungvon Daten beinhaltet das Modell einen„Single Point of Truth“. Der Codegene-rator kapselt das Wissen über die kon-krete Implementierung für verschiedeneZielsprachen und -systeme, was Wieder-holungen vermeidet. Änderungen an denDaten und/oder der Umsetzung für dieZielumgebungen können Entwickler künf-tig an einer zentralen Stelle vornehmen.Das erspart zum einen deutlich Arbeits-aufwand bei Änderungen, zum anderenvermeidet es lästige Fehler durch Inkon-sistenzen.Der Aufwand, eine eigene DSL zuentwerfen und die Codegeneratoren zupflegen, sollte allerdings einkalkuliertwerden. Dabei darf man an das Designder DSL und die Architektur der Genera-toren keinen geringeren Maßstab anlegenals an den resultierenden Produktivcode.Sobald die DSL und die Generatoren ei-ne gewisse Verbreitung gefunden haben,werden Schwachstellen schnell sichtbarund unbequem. Während Änderungen anden Generatoren vergleichsweise harm-los erscheinen, etwa analog zu Änderun-gen am Produktivcode, haben Modifika-tionen an der Sprachsyntax den Rangvon Arbeiten an der grundlegenden Soft-warearchitektur.Wie bei jeder Methodik oder Technikgilt es, für jeden Anwendungsfall Kostenund Nutzen abzuwiegen. Für ein isoliertesSystem ist der Aufwand, eine eigene DSLzu entwerfen, sicherlich nur eingeschränktgerechtfertigt. Je mehr Systeme es jedochzu integrieren gilt, desto schneller wirdsich diese Arbeit amortisieren. Spätestensbei ganzen Produktlinien und -familien,die einen hohen Grad an Wiederverwend-barkeit der geschaffenen Infrastruktur er-möglichen, wird der Nutzen spürbarüberwiegen. (ka)Jonatan Antoniist als Softwareingenieur für Zühlke tätig.Sein Schwerpunkt sind testbare Software-/Hardwarearchitekturen, ContinuousIntegration und Target-Tests im Umfeldeingebetteter Systeme.Literatur[1]ˇHeiko Behrens; Mundart nach Maß;Domänenspezifische Sprachen mitdem Eclipse-Projekt Xtext; iX 8/09,S.ˇ110[2]ˇStanislav Elinson, Matthias Hanns,Simon Kronseder; Für die Sprachen-vielfalt; Xtext 1.0: Tiefere Integrationin Eclipse; iX 10/10, S.ˇ76[3]ˇManfred Soeffky; Data Warehouse;Prozess- und Systemmanagement;IT-Research, München 1999[4]ˇKarl Eilebrecht, Gernot Starke;Patterns kompakt; Entwurfsmusterfür effektive Software-Entwicklung;Springer-Verlag, Heidelberg 2013[5]ˇISO/IEC 14977:1996(E); Informationtechnology – Syntactic metalanguage– Extended BNF; ISO/IEC, GenfiX 5/2013 103Modell GeneratorC++ CS MatLab/SimulikStellt man die Anzahl der manuell ge-schriebenen Zeilen (Modell und Codege-nerator) der der generierten Zeilen (C++,C#, MatLab/Simulink) gegenüber, liegtdas Verhältnis etwa bei 1ˇ:ˇ8 (Abb.ˇ3).Modell GeneratorC++ CS MatLab/SimulikWerden im Modell Zeilen eingefügt (her-vorgehoben), liegt das Verhältnis dieserZeilen zu den daraus neu generierten(C++, C#, MatLab/Simulink) bei etwa1ˇ:ˇ80 (Abb.ˇ4).[a] Sven Efftinge et al.; Xtextwww.xtext.org[b] Terence Parr et al.; Antlrwww.antlr.org[c] Sven Efftinge et al.; Xtendwww.xtend-lang.orgOnlinequellenAlle Links: www.ix.de/ix1305100 x

×