Modellierungsrichtlinien für Funktionsentwicklung und ... - dSPACE

Modellierungsrichtlinien fürFunktionsentwicklung undSeriencode-GenerierungDr.-Ing. Ulrich EisemanndSPACE GmbHVorgestellt auf der Embedded World Conference 2006,14. - 16. Februar, 2006,Nürnberg, Deutschland

Modellierungsrichtlinien fürFunktionsentwicklung undSeriencode-GenerierungZusammenfassungDieser Beitrag beschreibt Modellierungsrichtlinienfür einen modellbasierten Entwicklungsprozess anhandeiner Werkzeugkette, die auf MATLAB ® /Simulink ® /Stateflow ® zur Funktionsentwicklung sowieTargetLink zur Generierung von Seriencode basiert. Modellierungsrichtlinienspielen eine entscheidende Rolle, wennes darum geht, einen durchgängigen Entwicklungsprozesszu gewährleisten und den Aufwand zur Modellüberarbeitungzu reduzieren, der in den einzelnen Phasen desEntwicklungsprozesses entsteht. Darüber hinaus helfenModellierungsrichtlinien dabei, Qualitätsziele hinsichtlichdes Entwicklungsprozesses, der Effizienz des generiertenCodes und der funktionalen Sicherheit zu erreichen, wiein diesem Beitrag exemplarisch erläutert wird.1. Einleitung und MotivationDer modellbasierte Entwurf von eingebetteten Systemenbietet wesentliche Vorteile gegenüber herkömmlichen Entwicklungsprozessen.Dazu gehört die Spezifikation in Formvon ausführbaren Modellen, die direkte Unterstützung vonVerifikation und Test sowie die direkte Implementierung vonspezifizierten Modellen mittels automatischer Seriencode-Generierung.In der Automobilindustrie haben sich MATLAB/Simulink/Stateflow als Standardwerkzeuge für den modellbasiertenEntwicklungsprozess etabliert. Da Simulink/Stateflowauch zahlreiche für die Seriencode-Generierung eherungeeignete Modellierungsoptionen aufweisen, helfenModellierungsrichtlinien bei der Etablierung eines nahtlosenEntwicklungsprozesses, angefangen bei der Spezifikationin Simulink/Stateflow über Funktions-Prototyping bis hinzur automatischen Seriencode-Generierung. Richtlinienreduzieren Überarbeitungsschleifen, die während derunterschiedlichen Phasen des V-Modells auftreten, sieheAbbildung 1, da Code-Generierungsbelange bereits in derSpezifikations- oder Prototyping-Phase berücksichtigt werden.Zudem vereinfachen Richtlinien durch die Etablierungeiner gemeinsamen Referenz die Durchführung von Reviewsund den Modellaustausch zwischen OEMs und Zulieferern.Auch hinsichtlich Standards wie IEC 61508 [1] und MISRAC [2] sind Richtlinien hilfreich. Durch sie wird sichergestellt,dass der generierte Code für den Einsatz in sicherheitskritischenBereichen, die besondere Anforderungen an denCode stellen, geeignet ist.2. Warum sind zusätzliche Richtliniennotwendig?Vergleichsweise etablierte, wenn auch leicht überholteModellierungsrichtlinien für den Einsatz mit MATLAB/Simulink/Stateflowsind die MAAB Controller Style Guidelines [3](MathWorks Automotive Advisory Board), die primär vonOEMs zusammengestellt und im Jahr 2001 veröffentlichtwurden. 2003 erschien ergänzend der von japanischenOEMs and Zulieferern entwickelte J-MAAB StyleGuide [4].Die behandelten Bereiche in den Richtlinien reichen vonKonventionen für das Layout von Reglern über spezielleEntwurfsmuster bis hin zu Fragen der Architektur. Dadiese Richtlinien relativ generisch und unzureichend fürbestimmte Werkzeugketten unter Einschluss automatischerSeriencode-Generatoren sind, haben OEMs und Zuliefererin der Regel eigene interne Modellierungsrichtlinienentwickelt. Dennoch besteht weiterhin große Nachfragean regelmäßig aktualisierten adäquaten Richtlinien, dieneue Leistungsmerkmale der verwendeten Werkzeuge imEntwicklungsprozess berücksichtigen und die besondersdie eher werkzeugspezifische Seriencode-Generierungabdecken. Aus diesem Grund bietet dSPACE eigeneModellierungsrichtlinien für die Seriencode-Generierungunter Einsatz einer auf Simulink/Stateflow und TargetLinkbasierenden Werkzeugkette. Der Inhalt dieser Richtlinienwird im nächsten Abschnitt detailliert beschrieben.Control DesignFunction PrototypingTarget ImplementationAbbildung 1: Das V-Modell. Modellierungsrichtlinienhelfen sicherzustellen, dass sich in derReglerentwurfsphase (Control Design) erstellteModelle auch für die Implementierung in Form vonhocheffizientem C-Code eignen.CalibrationECU Testing

3. Richtlinien für automatische Seriencode-Generierung mit TargetLinkDie in den TargetLink-Richtlinien behandelten Themen deckenden gesamten Bereich von der Funktionsentwicklungbis zur Seriencode-Generierung ab. So werden nicht nurAspekte des geeigneten Layouts für den Reglerentwurfbetrachtet, sondern auch Codegenerator-Optionen fürhocheffizienten Code und Code für die Anwendung insicherheitskritischen Bereichen. Der folgende Abschnittveranschaulicht den Inhalt der TargetLink-Richtlinien anhandvon Beispielen.3.1 Definition einer geeigneten Sprach-UntermengeSimulink bietet zahlreiche Modellierungsoptionen, die weitdarüber hinausgehen, was gemeinhin in einem Reglerimplementiert wird, um so auch hochkomplexen Streckenmodellengerecht zu werden. TargetLink generiert hochwertigenSeriencode und macht daher einige Einschränkungenin Bezug auf Simulink-Blöcke, die ungeeignet oder irrelevantfür die Seriencode-Generierung sind. Diese Einschränkungensind in den Modellierungsrichtlinien dokumentiert,um zeitintensive Überarbeitungen des Reglermodells vonvornherein zu vermeiden.Ein typisches Beispiel für eine Modellierungsart, die nichtdirekt für die Implementierung in Form von Seriencodegeeignet ist, ist der Reglerentwurf mit zeitkontinuierlichenBlöcken wie Integratoren, Differenzierern usw., siehe Abbildung2. Wenn Funktionsentwickler die Modellierung inForm von traditionellen zeitkontinuierlichen Regelsystemenbevorzugen, sollte ein zusätzlicher Diskretisierungsschrittdurchgeführt werden, um den Regler vorab in eine optimale,zeitdiskrete Repräsentation umzuwandeln. Dadurch wirdsichergestellt, dass der ausgeführte Code, der von Naturaus ein zeitdiskretes System darstellt, optimal an den ursprünglichenReglerentwurf angepasst ist. Streckenmodelle,die nicht der Seriencode-Generierung unterliegen, könnenselbstverständlich immer in Form von zeitkontinuierlichenSystemen modelliert werden.du/dtDerivative1s+1Transfer FcnAbbildung 2: Generell sollten zeitkontinuierliche Blöckebei der Modellierung von Reglern entweder überhauptnicht verwendet werden oder nachträglich in eineoptimale zeitdiskrete Repräsentation überführt werden,bevor sie der Seriencode-Generierung unterliegen.1sIntegratorEine andere von Simulink unterstützte Modellierungsart,die sich generell nicht für eingebettete Systeme mit Echtzeitansprucheignet, ist die Modellierung algebraischerGleichungen mit so genannten algebraischen Schleifen,siehe Abbildung 3. Für die korrekte Implementierungund Ausführung eines solchen Reglermodells wäre nichtnur das Reglermodell selbst erforderlich, sondern auchein numerisches Lösungsverfahren für die algebraischenGleichungen. Diese Konstrukte sind üblicherweise für dieSeriencode-Generierung ungeeignet und werden dahernicht von TargetLink unterstützt.1In12In2AddEqu1AddEqu21Out12Out2Abbildung 3: Das Modellfragment enthält algebraischeSchleifen, die ein Gleichungssystem bilden. Bei dieserModellierung kann die Berechnung der Ergebnisse nichtunmittelbar explizit erfolgen, sondern erfordert einnumerisches Lösungsverfahren, was für Echtzeitsystemeungeeignet ist.3.2 Regeln für die Generierung voneffizientem CodeEines der wichtigsten Leistungsmerkmale von TargetLink istdie Fähigkeit, hocheffizienten Seriencode mit der Qualitätvon handprogrammiertem Code zu erzeugen. Um das Potenzialvon TargetLink voll ausschöpfen zu können, solltenauch die Modellierungsrichtlinien bezüglich Code-Effizienzberücksichtigt werden.TargetLink unterstützt mehrere Optimierungsattribute, dievom Anwender einzelnen Variablen zugewiesen werdenkönnen, um so die Optimierungsmechanismen zu steuern.Die Optimierungsattribute bestimmen zum Beispiel, obeine Variable in eine bedingte Verzweigung verschobenwerden kann, ob für das Gesamtverhalten irrelevante Zwischenvariablengelöscht werden dürfen, oder ob Variablengegebenenfalls zusammengeführt werden können, sieheAbbildung 4. Die Richtlinien helfen dem Anwender bei derEinstellung optimaler Optionen für die Code-Generierung,um sowohl den effizientesten Code zu erzielen, als auchzusätzliche Anforderungen wie spätere Messung und Applikationvon Variablen berücksichtigen zu können.C1GainC1C2GainC2C3GainC3C4GainC4

G1Att_Movable_Set1in.InPortSwitchOutPort1out.G2Att_Movable_Cleared1in.InPortG1Att_Erasable_SetTerm_upOutPort1out.Abbildung 6: Vermeidung großer Datentypen durchVorgabe von Wertebereichsgrenzen. Wenn derWertebereich von Signalen im Vorfeld bekannt ist, sollteer dementsprechend spezifiziert werden, um dem Code-Generator die Verwendung kleinerer Datentypen fürZwischenergebnisse zu ermöglichen.{loop_var = init_expr;}21G2Att_Erasable_ClearedTerm_downAbbildung 4: Modellfragmente mit bedingtauszuführenden Zweigen (oben) und irrelevantenZwischenvariablen (unten). Die Zuweisung vonOptimierungsattributen zu den Variablen bestimmt,ob Variablen in bedingte Verzweigungen verschobenwerden können und dadurch Ausführungszeit gespartwird, oder ob sie vollkommen gelöscht werden dürfen.Die Richtlinien unterstützen den Anwender bei derAuswahl geeigneter Optimierungsattribute.[loop_condition]{loop_action;loop_var = modify_expr;}Ein weiterer für die Generierung von optimalem Codewichtiger Aspekt ist der Einsatz einer Modellierungsart, diespezielle Entwurfsmuster für den Kontrollfluss in Stateflowverwendet, siehe Abbildung 5. Wann immer konditionaleStatements, Switch Statements, Schleifen usw. in Stateflowmodelliert werden, sorgen Entwurfsmuster dafür, dassder Code-Generator diese problemlos in ihre jeweiligenLoops/Chart Gegenstücke in C überträgt, was optimale Code-Effizienzgewährleistet.Eine der charakteristischen Eigenschaften automotiverSoftware-Entwicklung ist die Bedeutung, die Festkomma-Code besitzt. Große Stückzahlen und Kostendruck erfordernhäufig die Implementierung von Regelalgorithmen inFestkomma-Code. Durch Leistungsmerkmale wie Autoskalierungund TargetLink-Modellierungsrichtlinien wird derAnwender umfassend bei der korrekten und effizientenImplementierung des Festkomma-Codes unterstützt. Dazugehört zum Beispiel die Vermeidung großer Datentypen(insbesondere 64-Bit-Arithmetik) durch die Festlegung vonLoops/Chart2Wertebereichsgrenzen, siehe Abbildung 6, die effizienteWahl der Skalierungsfaktoren und Methoden, Sättigungseinstellungenetc.[condition]14 32{action;}Abbildung 5: Entwurfsmuster für Schleifen, die direkt ineffiziente C-Konstrukte übertragen werden.3.3 Regeln für sicherheitskritische Systemeund MISRA CBeim Entwurf von Reglermodellen für den Einsatz in sicherheitskritischenSystemen müssen zusätzliche Einschränkungenhinsichtlich der Modellierungsart beachtet werden, um„sichere Modelle“ gewährleisten zu können. Ein typischesBeispiel für zu vermeidende Code-Konstrukte sind rekursiveFunktionsaufrufe. Die TargetLink-Modellierungsrichtlinienführen die Fälle auf, in denen Rekursionen im Code als Folgespezieller Modellierungskonstrukte in Stateflow auftretenkönnen; in Abbildung 7 finden sich dazu zwei Beispiele.Printed 27-Jan-2006 11:00:17Printed 27-Jan-2006 11:01:21

RecursionGraphicalFunction/Chartfunction A{out=0; A();}{out=out+1;}RecursionGraphicalFunction/Chart1NFor 1 : NIteratorTerminator21[out < 5]{A();}[out don't shift right; 2 => don't shift left; 3 => don't shift right or left)Use state activity encoding if the number of states exceeds this limitUse bitfields for state encoding and flags for Stateflow. [_ON_|OFF]Derived struct component classes use the linker sections of their template classes. [ON|_OFF_]Control creation of simulation frame include file _fri.h.Abbildung 9: Einhaltung von MISRA-Regel 37, die die Anwendung von Bit-Operationen auf vorzeichenbehaftetenDatentypen untersagt. TargetLink unterstützt eine Code-Generierungsoption, um zwischen Multiplikation/Division undBit-Shifts wählen zu können.

3.4 Festlegung eines geeignetenReglerlayoutsGenauso wie Codierungsrichtlinien zur manuellen Programmierungeingesetzt werden (etwa zur Festlegungvon Namenskonventionen für Variablen und Funktionen),kann es auch hilfreich sein, entsprechende Regeln für einenmodellbasierten Entwicklungsprozess aufzustellen. DieTargetLink-Modellierungsrichtlinien decken unter anderemfolgende Bereiche ab:• Namenskonventionen für Blöcke und Signale• Geeignete Farbwahl und Blockanordnung zurVereinfachung von Reviews• Konsistenter Datenfluss(üblicherweise von links nach rechts)• Hierarchische Modellstruktur, die die Funktionalitätund Funktionspartitionierung in TargetLink reflektiert• Aussagekräftige Blockkommentare, die von TargetLinkauch in den Code übernommen werden Variable Handling[C_30]C_30msAbbildung 11: Allgemeine Regelstruktur. Jede Regel beinhaltet einen Titel, eine Switch Definition, einen Zweck, ein Feld für zusätzliche Informationen sowie optionaleReferenzen auf weiterführende Dokumente und Beispiele.In1In2Task_30ms MOVABLE • MOVABLE DISP Gain Void Subsystem(Void){/* Gain: Subsystem/Class DISP_NOT_MOVABLE */Sa1_Class_DISP_NOT_MOVABLE = Sa1_In * 5;/* SwitchSubsystem/u2 >= 0 */if (Sa1_In >= 0) {/* Gain: Subsystem/Class DISP */Sa1_Class_DISP = Sa1_In * 3;1In12In2Out1[C_10]C_10ms2In1In2Task_10ms2[C_30_b]C_30ms_bAbbildung 10: Beispiel für die Farbgebung zurVereinheitlichung des Reglerlayouts und Vereinfachungvon Modellreviews.Out1In1In2Task_30ms_bOut1Out21Out14. Arbeiten mit den ModellierungsrichtlinienDie TargetLink-Modellierungsrichtlinien sind in elektronischerForm verfügbar und bestehen aus zwei separatenTeilen. Der erste Teil bezieht sich auf die Funktionsentwicklungin Simulink/Stateflow und soll die nachfolgendenSchritte der Code-Generierung vereinfachen. Der zweiteTeil unterstützt Software-Entwickler bei der Auswahlgeeigneter Einstellungen für die Code-Generierung mitTargetLink. Die Regeln in den Richtlinien sind einheitlichaufgebaut, siehe Abbildung 11, und werden regelmäßigaktualisiert, um neue Leistungsmerkmale von TargetLinkund Simulink zu berücksichtigen. Intern werden die Regelnim XML-Format gehalten, um einenflexiblen Exportmechanismus undDokumentgenerierungsprozess zuunterstützen. Dadurch wird auchdie Extraktion projektspezifischerSubsets vereinfacht.Um die Einhaltung der Richtlinienbzw. einzelner Regeln sicherzustellen,ist es wünschenswert, sogenannte automatische Style Checkereinzusetzen. Ein Beispiel fürsolch ein Werkzeug ist mint, dasauch die Einhaltung von benutzerspezifischenRegeln erlaubt. SowohlTargetLink als auch MATLAB/Simulink/Stateflowbeinhalten eine vollständigdokumentierte API, die denZugriff auf sämtliche Eigenschafteneinzelner Blöcke bzw. des gesamtenModells ermöglicht. Hierdurch istes TargetLink-Anwendern möglich,Style Checker zur automatischenÜberprüfung von Modellierungsrichtlinienzu entwickeln, die aneigene firmenspezifische Richtlinienangepasst werden können, wasgrößtmögliche Flexibilität und einhohes Maß an Anpassungsfähigkeitbedeutet.}/* # combined # Outport: Subsystem/Out. */Sa1_Out = Sa1_Class_DISP;

5. FazitDieser Beitrag stellt die Vorteile beim Einsatz von Modellierungsrichtlinienin einem modellbasierten Entwicklungsprozesseinschließlich Funktionsentwicklung und automatischerSeriencode-Generierung heraus. Durch die Modellierungsrichtlinienwird die Durchgängigkeit des Entwicklungsprozessessowie die Steigerung von Produktivität und Qualitäterreicht. Konkret wurden Modellierungsrichtlinien für eineWerkzeugkette dargestellt, die auf Simulink/Stateflow undTargetLink zur Seriencode-Generierung basiert. Zu den inden Richtlinien abgedeckten Aspekten gehören unter anderemdie Definition eines geeigneten Simulink/Stateflow-Subsets, die Generierung von optimalem, effizientem Code,die MISRA-Konformität sowie Fragen der Skalierung fürFestkomma-Code. Durch die Anwendung der Richtlinienwird die Effizienz des modellbasierten Entwicklungsprozessesmit TargetLink deutlich gesteigert, wobei diesedurch den Einsatz von Style Checkern zur automatischenÜberprüfung der Einhaltung der Richtlinien noch weitererhöht werden kann.Referenzen[1] IEC 61508,“Functional Safety of electrical/electronic/programmableelectronic safety related systems”,IEC, 1998[2] MISRA Guide,“Guidelines for the Use of the C Language in Vehicle BasedSoftware”,MIRA, April 1998[3] MAAB Guide,“Controller Style Guidelines for Production Intent UsingMATLAB, Simulink and Stateflow”,Version 1.00, MathWorks Automotive Advisory Board,April 2001[4] J-MAAB StyleGuide,“Japan MathWorks Automotive Advisory Board SimulinkStyleGuide”,Version 1.0, J-MAAB, March 2003

Firmensitz in DeutschlanddSPACE GmbHTechnologiepark 2533100 PaderbornTel.: +49 5251 16 38-0Fax: +49 52 51 6 65 29info@dspace.dedSPACEUSA und KanadadSPACE Inc.28700 Cabot DriveSuite 1100Novi . MI 48377Tel.: +1 248 567 1300Fax: +1 248 567 0130info@dspaceinc.comJapandSPACE Japan K.K.West Tower 9FYokohama Business Park134 Godo-cho . Hodogaya-kuYokohama-shiKanagawa-ken 240-0005Tel.: +81 45 338 3361Fax: +81 45 338 3362info@dspace.jpFrankreichdSPACE SarlParc Burospace . Bâtiment 20Route de la Plaine de Gisy91573 Bièvres CedexTel.: +33 1 6935 5060Fax: +33 1 6935 5061info@dspace.frGroßbritaniendSPACE Ltd.2nd Floor Westminster HouseSpitfire CloseErmine Business ParkHuntingdonCambridgeshire PE29 6XYTel.: +44 1480 410700Fax: +44 1480 410701info@dspace.ltd.ukwww.dspace.com