Automatische Codegenerierung: Mythos und Realität

Automatische Codegenerierung:
Mythos und Realität
Die modellbasierte Software-Entwicklung für Embedded Systems
wird noch mit Skepsis betrachtet. Zu Unrecht!
uf
et
Die Technologie für Blockdiagramm-basierende
automatische
Codegenerierung
von Embedded Systems ist
im Laufe der letzten Jahre zu
einer ausgereiften und praxiserprobten
Lösung herangewachsen.
Viele Entwickler
sind jedoch trotzdem immer
noch der Meinung, dass dieses
Verfahren zu viele Nachteile
birgt. Dieser Beitrag
greift verbreitete Argumente
gegen die automatische Codegenerierung
auf und zeigt
auf Basis der MATLAB/Simulink-Werkzeugkette,
wie ausgereift
das Verfahren tatsächlich
ist. CORD ELIAS
CORD ELIAS ist Applikations-Ingenieur
bei The MathWorks
KONTAKT
T +49/241/47075-0
cord.elias@mathworks.de
Ü
ber das Thema der modellbasierten
Entwicklung mit automatischer
Codegenerierung wird
hitzig zwischen Befürwortern
und Gegnern diskutiert. Um alle Argumente
sorgfältig einordnen und prüfen zu können, ist
ein grundsätzliches Verständnis dieser Technologie
nötig. Auf der Grundlage eines Simulink-
Blockdiagramms soll die Technik daher kurz
vorgestellt werden. Eine umfassendere Einführung
zu diesem Thema kann in Fachartikeln
[1] und Lehrbüchern [2] nachgeschlagen werden.
Abbildung 1 zeigt ein Simulink-Blockdiagramm,
das einen PD-Regelungsalgorithmus
implementiert. Die Elemente dieses
Diagramms sind die funktionellen Blöcke
Gain, Addierer, Unit Delay und Sättigung sowie
die Verbindungen zwischen diesen Blöcken, so
genannte Signale. Das fertige Blockdiagramm
wird dann zu Simulationszwecken ausgeführt,
um festzustellen, ob die geforderten Vorgaben
erfüllt werden. Dazu wird neben dem Anwendungs-Modell
auch ein Modell des zu regelnden
Prozesses verwendet. Das Blockdiagramm
der Anwendung kann somit als ausführbare
Spezifikation angesehen werden. Mit Fortschreiten
des Entwicklungsprozesses wird das
Diagramm mit weiteren Details der abschließenden
Implementierung versehen, so dass am
Ende des Prozesses das Modell der Anwendung
als Quellcode dient. Dies wird durch die automatische
Codegenerierung auf der Basis von
Blockdiagrammen ermöglicht. Der gesamte auf
Blockdiagrammen basierende Entwicklungsprozess
wird modellbasierte Entwicklung genannt.

Die Integration eigenen Programmcodes
(Legacy Code) ist unmöglich oder zumindest
äußerst aufwändig
Die automatische Codegenerierung eignet
sich nur für große Prozessoren mit hoher
Leistung und großem Speicher
Die automatische Codegenerierung ist nur
auf sehr wenige Mikrocontroller anwendbar
Die modellbasierte Entwicklung eignet sich
nur für zeitkontinuierliche Systeme
Die modellbasierte Entwicklung mit automatischer
Codegenerierung ist nur etwas
für große Unternehmen
Abb. 1: Simulink-Blockdiagramm,Teil einer Regelungsanwendung
Automatische Codegenerierung –
Fragen und Antworten
Trotz allen Fortschritts auf diesem Gebiet gibt
es immer noch eine Reihe von Einwänden gegen
die automatische Codegenerierung.
Die folgende Liste ist sicher nicht vollständig,
enthält aber einige der am meisten verbreiteten
Auffassungen gegen das genannte Verfahren:
Automatische Codegenerierung ist zu
teuer
Die Leistung automatisch erzeugten
Programmcodes bleibt weit hinter
der vonhandgeschriebenem Code
zurück
Die automatische Codegerierung ist gut für
Rapid Prototyping, aber nicht ausreichend
für die Produktion
Der Codegenerator ist eine Black Box ohne
Einflussnahmemöglichkeit auf den automatisch
erzeugten Code
Es besteht keine Möglichkeit der
Einflussnahme auf das Packaging und das
Layout des Codes
Die Realität sieht im Bezug auf die genannten
Einwände jedoch anders aus und wird im folgenden
genauer erläutert!
Mythos: Preis
Werkzeuge für die automatische Codegenerierung
sind für simple Anwendungen nicht
ökonomisch. Steigende Design-Komplexität erfordert
jedoch auch zunehmend höher entwikkelte
Analyse- und Entwicklungsmethoden. Die
modellbasierte Entwicklung fasst dabei alle
Bestandteile einer integrierten Entwicklungsumgebung
zusammen. Die Erfahrung zeigt,
dass die Produktivität mit automatischer Co-
▲

Die Codegenerierungs-Technologie von
The MathWorks bietet dem Anwender
vielerlei Möglichkeiten, Einfluss auf den
automatisch generierten Code zu nehmen.
So ist es beispielsweise möglich,
bereits vorhandene Bibliotheken anstelle
des automatisch generierten Standard-
Codes einzubinden und/oder eigene
Hilfsprogramme per „Hook-In“ in den
Prozess der Codegenerierung einzubringen.
Auch die angeführte mangelnde
Einflussnahmemöglichkeit auf das Packaging
und das Layout des Codes ist nicht
richtig. Simulink und der Real-Time
Workshop Embedded Coder bieten umfangreiche
Möglichkeiten, beides zu beeinflussen.
So kann beispielsweise der Code für den in
Abbildung 1 gezeigten PD-Regler ganz einfach
mithilfe des in Abbildung 2 dargestellten Dialogs
als Funktion generiert werden. Außerdem
kann auch die Anforderung hinsichtlich eines
bestimmten Dateilayouts durch die Verwendung
frei gestaltbarer Vorlagen (Templates) für
den Code und die Daten erfüllt werden (vgl.
Abbildung 3).
degenerierung um rund 30 Prozent über der
Produktivität bei einer Programmierung von
Hand liegt. Diese Tatsache wiegt die Kosten für
den Codegenerator mehr als auf und spricht
vom Standpunkt des Return-on-Investment aus
gesehen für die automatische Codegenerierung.
Mythos: Leistung
Abb. 2:
Code-Platzierungs-Dialog
Die automatische Codegenerierung für das
Rapid Prototyping kann dem Target-Prozessor
insbesondere im Hinblick auf die Speichernutzung
mehr Ressourcen abverlangen, als zur
Implementierung des nackten (Regelungs-)
Algorithmus nötig wäre. Dies trifft jedoch immer
zu, egal, ob der Code per Hand oder automatisch
geschrieben wurde. Das liegt vor allem
an dem beim funktionalen Rapid Prototyping
hohen Entwicklungskomfort wie Parameter-
Tuning und Signal-Monitoring „on-the-fly“
und der ausschließlichen Verwendung von
Gleitkomma-Datentypen. Geht man jedoch
vom funktionalen Rapid Prototyping zur
Produktion über, ist die freie Einstellbarkeit
jedes einzelnen Parameters nicht gewünscht.
Außerdem müssen die Algorithmen (zumindest
für Massengüter) in Festkomma-Arithmetik
implementiert werden. In Verbindung mit den
mächtigen, vom Codegenerator angebotenen
Optimierungs-Techniken ist der automatisch erzeugte
Code der manuellen Programmierung in
Bezug auf Laufzeitleistung und Speicherbedarf
durchaus ebenbürtig. Aktuelle
Arbeiten unabhängiger Anwender
belegen dies [3], [4].
Mythos: mangelnde
Einflussnahme-möglichkeit
Mythos: mangelnde Integrationsmöglichkeit
Wenn nur ein Teil des Programmcodes eines Projektes
automatisch erzeugt werden soll, ist eine
anwenderfreundliche Schnittstelle zwischen
den automatisch und den manuell erzeugten
Teilen des Codes von allergrößter Wichtigkeit.
Diese Forderung wird von den so genannten
Entry Points und der Datenschnittstelle erfüllt.
Der Real-Time Workshop Embedded Coder erzeugt
drei Entry-Points: Eine Initialisierungs-
Funktion („Initialize“), eine Schritt-Funktion
und eine Beendigungs-Funktion („Terminate“).
Die Datenschnittstelle kann praktisch jede
mögliche Anforderung des Anwenders erfüllen.
Er hat die volle Kontrolle über die Benennung
sämtlicher Variablen auf der Eingangs- und
Ausgangsseite einer automatisch erzeugten
Anwendung. Außerdem können vordefinierte
oder vom Anwender selbst erzeugte Custom
Storage Classes verwendet werden, um auf
nicht standardgemäße Art und Weise auf Daten
zuzugreifen.
Mythos: Ressourcen-Hunger
In der Anfangszeit der automatischen Codegenerierung
traf es durchaus zu, dass dieses
Verfahren überwiegend für große Prozessoren
mit hoher Leistung und großem Speicher geeignet
war. Mittlerweile hat die automatische Codegenerierung
aber ein Reifestadium erreicht, in
dem sie sogar für 8-Bit Mikroprozessoren anwendbar
ist.
Mythos: begrenzte
Einsatzmöglichkeit
Dass die automatische Codegenerierung nur
auf sehr wenige Mikrocontroller anwendbar
ist, ist schlicht und einfach falsch! Auch wenn
bestimmte Mikrocontroller durch Erweiterungspakete
zum Codegenerator („Embedded
Targets“) explizit unterstützt werden, so gilt
jedoch generell: Automatische Codegenerierung
ist für jeden Mikrocontroller möglich, für den
auch manuell Code in C geschrieben werden
kann. Auch die Annahme, dass die modellbasierte
Entwicklung sich nur für zeitkontinuierli-

Abb. 3:Verwendung von Vorlagen für Programmcode und Daten
che Systeme eignet, für zeitdiskrete und ereignisgesteuerte
Systeme aber bessere Ansätze vorahnden
sind, ist nicht richtig. Hierfür müssen
jedoch zunächst einige Begriffe definiert werden:
Ein Zeitkontinuierliches System ist ein System,
das durch eine Differentialgleichung (DGL)
oder ein System von DGLs beschrieben werden
kann. Ein Zeitdiskretes System ist ein System,
das durch eine Differenzengleichung oder ein
System solcher Gleichungen beschrieben wird.
Ein ereignisgesteuertes System ist ein System,
das im Gegensatz zu einem datenflussgesteuerten
System auf (asynchrone) externe Ereignisse
reagiert. Ein ereignisgesteuertes System wird
üblicherweise mit Hilfe von Zustandsautomaten
beschrieben und implementiert.
Simulink deckt sämtliche der oben genannten
Systemtypen sowie alle daraus möglichen
Kombinationen (Hybrid-Systeme) ab.
Mythos: Enterprise-Modell
Bei der Einführung der modellbasierten Entwicklung
mit automatischer Codegenerierung
werden zwar Investitionen für die Anpassung
der Entwicklungsprozesse und ein gewisser
Schulungsaufwand für die Mitarbeiter nötig,
die Erfahrung zeigt aber, dass diese Investitionen
nicht nur für große Unternehmen mit
mehreren hundert Software-Entwicklern sinnvoll
sind. Es gibt zahlreiche Beispiele kleinerer
Ingenieurbüros mit weniger als 30 Mitarbeitern,
die die modellbasierte Entwicklung mit
automatischer Codegenerierung sowohl technologisch
als auch wirtschaftlich äußerst erfolgreich
einsetzen.
bar. Die automatische Codegenerierung ist eine
praxiserprobte Technologie, die sich in den letzten
Jahren deutlich weiterentwickelt hat und
sich auch in Zukunft weiterentwickeln wird. Im
Kontext der modellbasierten Entwicklung betrachtet,
stellt sie den Schlusspunkt einer geschlossenen
und vollständigen Werkzeugkette
dar, die in hervorragender Weise die Bedürfnisse
der Entwickler von Embedded Systems erfüllt.
■
Literatur
[1] “Model-Based Design and Beyond: Solutions
for Today’s Embedded Systems
Requirements”, Krasner, Jerry, Embedded
Market Forecasters, 2004
http://www.mathworks.com/applications/
controldesign/technicalliterature.html
[2] “Simulation Engineering”, Ledin, J., CMP
Books, 2001
[3] “Model based development of Cruise
Control for Mercedes Benz Trucks”,
Wuensche, Mario et al., International
Automotive Conference 2004,
http://www.mathworks.com/industries/
auto/technicalliterature.html
[4] “Multi-target Modelling for Embedded
Software Development for Automotive
Applications”, Hodge, Ye, Stuart, Visteon
Corporation, March 2003, SAE Technical
Paper Series 2004-01-0269
http://www.visteon.com/whitepapers/
2004_01_0269.pdf
Fazit
Die gängigen Einwände gegen die automatische
Codegenerierung sind heute nicht mehr halt-
Weiterführende Infos auf www.duv24.net
more @ click
DV124350 >