Autoren: Dr. Andreas Wagener, Dr. Fritz Faulhaber GmbH & Co. KG, Robert Stemplinger und Markus Pauls, b1 Engineering Solutions GmbH<\/p>\n
\u00dcber Tools wie Rhapsody kann aus der Modellierung direkt Code auch f\u00fcr Embedded Systeme generiert werden. Im betrachteten Projekt wird das gesamte System derart in Rhapsody entworfen und implementiert. Stacks und signalverarbeitender Code werden mit eingebunden. Dazu sind einige Vorarbeiten n\u00f6tig, das Abstraktionsniveau steigt f\u00fcr alle Beteiligten – verbunden mit der Chance, bis zum Produkt eine klar erkennbare Architektur umzusetzen und damit ein gut wartbares Produkt zu erhalten.<\/strong><\/p>\n Die Dr. Fritz Faulhaber GmbH & Co. KG entwickelt, fertigt und verkauft Klein- und Micromotoren, die dazu passenden Positionsgeber und Ansteuerungen zum geregelten Betrieb der Motoren. Die Ansteuerungen sind in Ausf\u00fchrungen als reine Drehzahlregler oder auch als Positionsteuerungen im Programm. Realisiert sind diese als eingebettete Steuerungen auf der Basis von \u00b5Controllern, in denen alle Stufen der Regelung rein digital abgebildet werden. Betrachtet werden sollen hier die Positioniersysteme.<\/p>\n Die Software einer Motoransteuerung f\u00fcr einen Servoantrieb kann grob in die Teile<\/p>\n gegliedert werden. Erweiterungen und Anpassungen an ver\u00e4nderte Anforderungen, aber auch Beschr\u00e4nkungen des Zielsystems erforderten in den Bestandssystemem den klaren Entwurf zu verlassen. Dies f\u00fchrt zu der klassischen Situation bei eingebetteten Steuerger\u00e4ten mit deutlich ineinander \u00fcbergehenden Softwareanteilen.<\/p>\n Trotz dieser Beschr\u00e4nkungen stellt der Motion Controller ein sehr stabiles Ger\u00e4t dar, Erweiterungen erfordern jedoch einen h\u00f6heren Aufwand und Entwicklungszeitraum. Insofern war f\u00fcr eine n\u00e4chste Ansteuerungs-Generation klar, dass insbesondere die Wartbarkeit und Erweitbarkeit durch eine klare und modulare Software-Architektur deutlich verbessert werden sollte.<\/p>\n Funktionale Anforderungen waren:<\/p>\n Die Anforderungen waren mit der Erwartung verbunden, k\u00fcnftig wieder deutlich schneller auf Kundenw\u00fcnsche eingehen zu k\u00f6nnen.<\/p>\n Gleichzeitig sollte der Wechsel auf eine aktuelle und zukunftstr\u00e4chtige Prozessorfamilie erfolgen, die Software aber so entwickelt werden, dass auch k\u00fcnftige Prozessorwechsel deutlich vereinfacht werden.<\/p>\n Aufgrund der sehr verwobenen Struktur nach Abbildung 1 (siehe\u00a0PDF<\/a>) war relativ schnell klar, das aus dem bestehenden Produkt eigentlich nur die Erfahrungen im Betrieb von elektrischen Kleinantrieben \u00fcbernommen werden konnten. Alle Teile der Software mussten neu entworfen werden.<\/p>\n Eine Aufgabe war daher die Suche nach einer Prozessorplattform f\u00fcr die speziellen Anforderungen von integrierbaren Kleinantrieben. Die andere Aufgabe war die Suche nach einer geeigneten Entwurfs-Methodik, verbunden mit der Suche nach geeigneten Werkzeugen, die es erlauben w\u00fcrden, die Grundentscheidungen aus dem Entwurf auch in der Implementierung abzusichern.<\/p>\n Abweichend vom bisherigen Vorgehen sollte ein objekorientierter Ansatz verfolgt werden, auch um den Entwurf \u00fcber die Mechanismen der UML zu strukturieren.<\/p>\n Bereits bisher kamen f\u00fcr die Entwicklung der signalverarbeitenden Softwareteile in der Regelung und Positionsauswertung Target Link f\u00fcr die Code-Erzeugung aus SIMULINK Modellen zum Einsatz. Dieser Ansatz eignet sich aber nicht, um die eher event-basierten Softwareteile aus der Treiber-Schicht, dem Parameterhandling, der Kommunikation und auch der Antriebssteuerung zu beschreiben und dann auch zu implementieren.<\/p>\n Nach einer ersten Evaluation und auf der Basis der Erfahrungen aus fr\u00fcheren Projekten [1] fiel die Entscheidung auf Rhapsody bzw. f\u00fcr die Embedded Version, wie sie von der Fa. Willert angeboten wird. Hauptargumente waren:<\/p>\n Es war aber von Beginn an klar, dass damit auch eine erhebliche Lernkurve sowohl hinsichtlich der Bediensicherheit des Werkzeugs als auch in der Entwurfsmethodik anstehen w\u00fcrde. Klar war daher auch, dass wir uns einen erfahrenen Partner f\u00fcr die anstehenden Kernthemen suchen mussten, den wir in der Fa. Tieto bzw. Tieto Embedded Systems – heute b1 Engineering Solution fanden (siehe dazu auch Abb. 2,\u00a0PDF<\/a>).<\/p>\n Basierend auf der erarbeiteten Spezifikation, den Use-Cases des Systems und den Erkenntnissen aus dem Bestandssystem entstand zun\u00e4chst eine Grobarchitektur:<\/p>\n Angewandte Muster waren die Schichtbildung (Layering) mit insbesondere einer eindeutigen Zuordnung von Verantwortlichkeiten f\u00fcr die Kapselung der \u00b5Controller-typischen Peripherieeinheiten im HAL und einer darauf aufsetzenden Middleware-Schicht (siehe Abb. 3,\u00a0PDF<\/a>). Die Middleware-Schicht stellt deutlich abstrahierte Informationen wie die Motorgeschwindigkeit als Ergebnis unterschiedlichster Sensorsysteme zur Verf\u00fcgung oder errechnet Stellgr\u00f6\u00dfen aus allgemeinen Vorgaben, wie z.B. die passende Ansteuerung f\u00fcr den angeschlossenen Motor aus der Sollspannung des Reglers.<\/p>\n Um eine Signalflussrichtung entgegen den definierten Abh\u00e4ngigkeitsbeziehungen zu realisieren, wurde das Publish\/Subscribe-Pattern bzw. Beobachter-Muster verwendet. Dazu registrieren Informationskonsumenten aus h\u00f6heren Schichten Callback-Funktionen\u00a0und\u00a0Instanz-Zeiger bei den Informationsproduzenten in den niedrigeren Schichten. Dieses Pattern wird gleicherma\u00dfen f\u00fcr den \u00dcbergang zwischen Interrupt-Kontext und Task-Kontext als auch zwischen Task-Kontexten verwendet. Um die Nebenl\u00e4ufigkeiten zu beherrschen, wird in den Callback-Funktionen daher im Allgemeinen ein Event der Laufzeitumgebung an die adressierte Objekt-Instanz versendet. Es ist vielfach ausreichend, genau einen Subscriber bereits w\u00e4hrend der Initialisierung zu registrieren (siehe Abb. 4,\u00a0PDF<\/a>).<\/p>\n Die Aktivit\u00e4ten des Systems k\u00f6nnen aufgeteilt werden in die streng zeitlich getriebenen Aktivit\u00e4ten einerseits:<\/p>\n Beide werden \u00fcber einen Interrupt angesto\u00dfen und auch im Interrupt-Kontext ausgef\u00fchrt. Diese signalverarbeitenden Systemteile werden in SIMULINK entworfen und \u00fcber TargetLink in C-Code mit einer zum Systementwurf passenden Schnittstellengestaltung \u00fcberf\u00fchrt.<\/p>\n Auf der anderen Seite stehen die eher reaktiven Aktivit\u00e4ten:<\/p>\n In beiden F\u00e4llen wird der Interrupt-Kontext verlassen und ein Event ausgel\u00f6st, der typisch \u00fcber eine Zustandsmaschine bearbeitet wird. Die Modellierung der Interaktion kann hier vorteilhaft \u00fcber Kommunikationsidagramme, die Systemreaktion \u00fcber Zustandsmaschinen entworfen werden.<\/p>\n Innerhalb des Willert Framework werden Zustandsmaschinen und die n\u00f6tige Eventbehandlung direkt nativ angeboten, d.h. aus Zustandsdiagrammen und den dazu geh\u00f6renden Events kann direkt lauff\u00e4higer Code erzeugt werden. Da die Reaktion auf jeden Event am St\u00fcck abgearbeitet wird (run to completion), k\u00f6nnen Zustandsmaschinen auch verwendet werden, um quasi gleichzeitige Ereignisse zu serialisieren, indem die Ereignisse in einer Event-Queue einer Zustandsmaschine eingestellt werden \u2013 so z.B. f\u00fcr die Bearbeitung von \u00fcber die serielle Schnittstelle erhaltener Anfragen in Konkurrenz zu intern erzeugten asynchronen Botschaften.<\/p>\n Das Gesamtsystem wurde in eine Reihe von parallelen Rhapsody Projekten zerlegt, die je f\u00fcr eine Komponente die Arbeitsumgebung aus Implementierung und Testpaket beinhalteten. Damit k\u00f6nnen die Komponenten weitgehend getrennt bearbeitet werden – wichtig f\u00fcr die Arbeit im Team.<\/p>\n Die Komponenten wurden dann entsprechend den Abh\u00e4ngigkeiten und Schichten von Beginn an zu Integration zusammengef\u00fcgt (Top Down), deren Funktionsumfang dann schrittweise wachsen konnte.<\/p>\n Die Basis bildet ein Projekt, in dem lediglich Typ- und Stereotype-Definitionen beheimatet sind, die sich aus der Programmierrichtlinie ergeben. Darauf setzten die Fachpakte auf, die je aus der zu entwickelnden Komponente und optional einem Test-Package bestehen. \u00dcber das Test-Package k\u00f6nnen aus dem Fachpaket ausf\u00fchrbare Testkomponenten erzeugt werden, die je nur den Umfang der betrachteten Fachkomponente nutzen. Auf oberster Ebene werden die Komponenten im Integrationsprojekt referenziert (siehe Abb. 5,\u00a0PDF-Datei<\/a>)<\/p>\n F\u00fcr die Integration und die zu erstellenden Bin\u00e4rfiles stellen die Rhapsody-Projekte die Build-Umgebung dar. Der gesamte Code wird \u00fcber die Projekte in ein Projekt der C-Entwicklungsumgebung (hier Keil \u00b5Vision) verschoben und dort nur gebildet und debuggt. Die exportierten C-Files unterliegen damit nicht dem Konfigurationsmanagement.<\/p>\n Trotzdem m\u00fcssen auch in C vorliegende Code-Teile, wie z.B. gekaufte Kommunikations-Stacks oder die \u00fcber TargetLink erzeugten Code-Anteile, integriert werden. Aufgaben sind dabei, die vorhandenen Codes jeweils aktuell ins C-Projekt zu kopieren, sowie ggf. die Gestaltung von Schnittstellen, um die externen Code-Anteile im Projekt nutzen zu k\u00f6nnen.<\/p>\n Der erste Teil der Aufgabe gelingt \u00fcber make-File Erweiterungen, die innerhalb der in Rhapsody erstellten Komponenten angelegt werden k\u00f6nnen und die Kopieranweisungen aufnehmen.<\/p>\n F\u00fcr die Integration ins Modell wurden typisch Wrapper-Klassen angelegt. So kann z.B. mit TargetLink sehr gut ein Regler erstellt werden. Auch k\u00f6nnen die Parameter und Variablen in je einer klassenartigen Struktur gesammelt und auch an der Funktionsschnittstelle der eigentlichen Rechenroutine verwendet werden. Das so erzeugte C-Modul kann dann als externer Code im Projekt eingebunden werden. F\u00fcr den Zugriff auf die einzelnen Parameter der Regler-Struktur werden in TargetLink aber keine zur Integration geeigneten Zugriffsmethoden bereitgestellt. Bliebe der Direktzugriff auf die Member der Struktur, oder eben ein Wrapper, der daf\u00fcr die Read- und Write-Handler bereitstellt und das Wissen \u00fcber die C-Struktur kapselt.<\/p>\n Das Projekt ist noch nicht abgeschlossen, eine vorl\u00e4ufige Bewertung l\u00e4sst als Vorteile erkennen:<\/p>\n Insbesondere aus Sicht des Entwicklers ergeben sich in der t\u00e4glichen Anwendung von Rhapsody einige H\u00fcrden, mit denen man zu leben lernen muss. Im Folgenden seien einige Beispiele genannt. Vieles k\u00f6nnte unserer Meinung nach leicht abgestellt werden, wenn der Wille zur Pflege des Produkts noch ausgepr\u00e4gter w\u00e4re.<\/p>\n Welche Properties bei der Code-Generierung wie oder wann wirken, ist sehr undurchsichtig. Hier hilft oft nur Probieren. Beispielsweise ist das Property C_CG::Type::ReturnType nicht wirksam, wenn man sich \u00fcber das Property C_CG::Attribute::AccessorGenerate automatisch einen Accessor generieren lassen will. Im genannten Fall sollte anstelle einer Kopie einer Struktur (default) ein Const-Zeiger auf die Struktur zur\u00fcckgegeben werden.<\/p>\n Die Files, in denen Rhapsody seine Informationen hinterlegt, sind leider nicht sehr „Merge“-freundlich gestaltet. Insbesondere werden in Files h\u00e4ufig Zeitstempel und GUIDs ge\u00e4ndert, obwohl sie ansonsten keinerlei \u00c4nderungen erfahren haben. Um ein gemeinsames Arbeiten zu erm\u00f6glichen, haben wir daher h\u00e4ufig vor dem Commit mit den Mitteln des Konfigurations-Management-Tools manuell kontrolliert, welche Files wirklich inhaltlich ge\u00e4ndert wurden. Bei tats\u00e4chlichen Konflikten war mitunter auch Handarbeit mit dem Merge-Tool notwendig, sofern sich diese Konflikte nicht im Vorfeld durch Absprachen umgehen lie\u00dfen.<\/p>\n Wir arbeiten gerne und h\u00e4ufig mit konstanten, privaten Daten-Tabellen, die dann durch den Code ausgewertet werden. Leider k\u00f6nnen Staircase-Member bei Klassen nicht angelegt werden (wie es in C++ m\u00f6glich ist). Anwendungsbeispiele w\u00e4ren:<\/p>\n Umgehungsm\u00f6glichkeiten ergeben sich teilweise durch die Definitionen durch Types, aber z.B. nicht f\u00fcr die Callback-Funktionen, da die Funktionsprototypen im generierten Code erst nach den Types angeordnet werden.<\/p>\n Die Erfahrung zeigt, dass f\u00fcr ein effizientes Arbeiten mit Rhapsody fr\u00fchzeitig die richtigen Voraussetzungen zu schaffen sind. Aus unserer Sicht sind folgende Punkte wichtig:<\/p>\n Unabh\u00e4ngig von der konkreten Entwicklungsmethodik ist ein gutes Grundverst\u00e4ndnis der Dom\u00e4nen-spezifischen Probleme immer ein wesentlicher Erfolgsfaktor. In diesem Falle ist es z.B. das Verst\u00e4ndnis der treibenden Aktivit\u00e4ten und die Zuordnung in den zeitgetriebenen Interrupt-Kontext oder den ereignisbasierten Task-Kontext.<\/p>\n Durch den abstrakteren, modellhaften Ansatz muss von den beteiligten Entwicklern noch mehr entsprechendes Wissen abverlangt werden. Man darf sich bei der Methodik nicht gleich in die Bits und Bytes fl\u00fcchten und im Nachhinein schauen, wie man alles zusammenf\u00fcgt. Der Vorteil von entsprechenden Modellierungs- und Codier-Richtlinien muss sicherlich nicht extra hervorgehoben werden.<\/p>\n Die bisherigen Ergebnisse m\u00fcssen differenziert betrachtet werden. Aus Sicht des Architekten erlaubt die modellbasierte Arbeit einen z\u00fcgigen \u00dcbergang von der Architektur bis in die Implementierung. Insbesondere bleiben durch die expliziten Notationen die Grundentscheidungen der Architektur stets im Blick.<\/p>\n F\u00fcr die Entwickler stellt der Wechsel auf OO und Rhapsody eine erhebliche Umstelung ihrer Arbeitsweise dar. Statt in C-Files und sehr ausgefeilten C-Editoren entsteht der Code im Editor von Rhapsody. \u00c4nderungen in den C-Files w\u00e4hrend des Tests m\u00fcssen sorgf\u00e4ltig zur\u00fcckgepflegt werden. Nicht untersch\u00e4tzt werden darf auch der Paradigmenwechsel von einer Main-Loop auf ene Event-basierte Systemarchitektur.<\/p>\n Aus Sicht des Projektverantwortlichen bestand die gr\u00f6\u00dfte Herausforderung in der Suche nach geeigneten Partnern. Der Umstieg auf einen OO-Entwurf gelingt nicht aus dem Stand. Rhapsody stellt ein sehr m\u00e4chtiges Werkzeug dar, mit eher \u00fcberschaubarer Dokumentation. Trotz eines vorgelagerten Evaluationsprojekts und begleitender Schulungen w\u00e4re das Projekt diesen Umfangs und Neuigkeitsgrades ohne die erfahrenen Partner nicht in der ohnehin knappen Vorgabezeit zu bew\u00e4ltigen gewesen.<\/p>\n Kritisch anzumerken bleibt, dass ein erheblicher Teil der Zeit – typisch f\u00fcr embedded Systeme – in die Entwicklung von Middleware-Schichten geflossen ist. Diese weisen dadurch zwar ebenso wie die Applikation eine klare Struktur auf, dienen aber nicht zur Produktdifferenzierung. Hilfreich w\u00e4ren hier k\u00fcnftig ggf. st\u00e4rker standardisiere Middlewarepakete, die aber sicher Branchen- bzw. Anwendungstypisch ausgef\u00fchrt sein m\u00fcssen.<\/p>\n [1] A. Wagener, Ch. K\u00f6rner, P. Seger, H. Kabza, Anpassung eines Embedded Target f\u00fcr verteilte Steuer- und Regelungsaufgaben an den RTW von Matlab\/Simulink, Embedded Intelligence 2001, N\u00fcrnberg<\/p>\n [2] U. Lefarth, T. Beck, Qualit\u00e4ts- und Effizienzsteigerung bei der Entwicklung von Steuerger\u00e4te-Software, 3. Stuttgarter Symposium Kraftfahrwesen und Verbrennungsmotoren, 1999, Stuttgart.<\/p>\n [3] Dr. Gary Morgang, AUTOSAR \u2013 ein Projekt zur Entwicklung von Steuerger\u00e4te-Software, Elektronik automotive 1\/2006<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n\n
\n
Grundentscheidungen<\/h2>\n
\n
Architektur & Design<\/h2>\n
\n
Umsetzung<\/h2>\n
\n
\n
Anteile der Laufzeitumgebung<\/h2>\n
Umsetzung in Rhapsody<\/h2>\n
Integration von C-Code<\/h2>\n
Vorteile<\/h2>\n
\n
Herausforderungen und M\u00fchen<\/h2>\n
Der RPY Code- und Modell-Editor<\/h2>\n
\n
Properties<\/h2>\n
Versionierung<\/h2>\n
OO in C<\/h2>\n
\n
Voraussetzungen<\/h2>\n
\n
\n
Ergebnisse<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\nModellierung – MicroConsult Trainings & Coachings<\/h2>\n
\nModellierung – Fachwissen<\/h2>\n