Entwicklung von AUTOSAR Software-Komponenten mit Model-Based Design
Fortsetzung des Artikels von Teil 1
Wirkungsvolle Modellpflege
Auf diese Weise formulierte Entwürfe können von Anfang eines Projektes an getestet und validiert werden. Die Verifikation und Validierung eines Produkts ist damit im Model-Based Design nicht der letzte Schritt einer Gesamtentwicklung, sondern ein kontinuierlicher Prozess. Zusätzlich zu den von Entwicklungs- und Testingenieuren entwickelten Testszenarien gibt es hier Tools, mit denen Testfälle bis hin zum Niveau der Modified Condition/Decision Coverage (MC/DC) automatisch erzeugt werden können.
Model-Based Design auf der Grundlage ausführbarer Spezifikationen erleichtert sowohl die Kommunikation zwischen dem OEM-Hersteller und seinen Zulieferern als auch die projektinterne Kommunikation, weil alle Informationen in grafischer und ausführbarer Form vorliegen. Entwicklerteams können daher beim Model-Based Design eine Reihe zentraler Aufgaben erheblich früher abschließen als mit konventionellen Arbeitsweisen. Durch diese Fähigkeit steigt zusätzlich die Qualität des gesamten Entwicklungsprozesses, da Fehler nicht erst am Ende eines Projekts aufgedeckt werden, lassen sich zusätzliche, zeit- und kostenintensive Iterationen vermeiden. Abbildung 3 verdeutlicht, wie enorm die Kosten für die Beseitigung eines in der Anforderungsphase eingeschleppten Fehlers steigen, wenn dieser bis in die Testphase hinein unentdeckt bleibt.
Erzeugung von Produktionscode
Zur Erzeugung von Produktionscode wird die fertige Software automatisch aus den Modellen generiert, beispielsweise mit dem Real-Time Workshop Embedded Coder. Da bei zeitdiskreten Modellen hierfür keine Blöcke durch andere ersetzt werden müssen, gelangt man in kurzer Zeit zum fertigen Code. Einer der zentralen Vorteile dieser sehr geradlinigen Integrationsmethode besteht darin, dass die gesamte bis zu diesem Punkt aufgebaute und bereits für die Modelltests genutzte Infrastruktur weiterverwendet werden kann. Fehler und andere Defekte, die im Rahmen dieses Verifikations- und Validierungsprozesses entdeckt werden, behebt man direkt auf der Modellebene und kann danach die Software ohne jeden manuellen Eingriff erneut automatisch generieren.
AUTOSAR
Um mit den Herausforderungen Schritt halten zu können, denen Ingenieuren durch die stetig weiter steigende Komplexität der Entwicklung und Pflege moderner Automobil-Anwendungen gegenüber stehen, entschlossen sich die betroffenen Unternehmen, eine standardisierte Architektur für elektronische Steuergeräte (ECUs) zu definieren.
Jobangebote+ passend zum Thema
Die Modifikationen für diese neuste Version des Core 750D lassen sich in 16 einzelne Kategorien unterteilen, von denen elf die Hardware und fünf den Compiler betreffen. Die Veränderungen der Hardware an der Core-Pipeline sorgen für den wesentlichen Anstieg der Verarbeitungsleistung – und das alles mit minimal verändertem Flächenbedarf.
Der ARC-Core 750D beansprucht lediglich eine Fläche von 1,23 mm2 (ohne die Taktgeber für die Cache-Speicher, aber mit der entsprechenden Logik zur Unterstützung dieser Taktgeber); das entspricht einem Anstieg des Flächenbedarfs im Vergleich zur vorherigen Version von nicht einmal 10 %. Der Core kann mit Taktfrequenzen von über 533 MHz arbeiten und liefert dabei eine Verarbeitungsleistung von 813 Dhrystone-MIPS. Die Verlustleistungsaufnahme beträgt dann 0,16 mW/MHz – ein Wert, der signifikant geringer ist als bei anderen Prozessoren mit ähnlicher Verarbeitungsleistung. In den Anwendungs-Code-Benchmarks von EEMBC läuft der neue Core etwa 30 % schneller als Vorgänger-Versionen (Bild 2).
Verbesserte Branch-Prediction und Vermeidung von Speicherkollisionen
Bei den signifikantesten Veränderungen der Hardware handelt es sich um Veränderungen des Speicher-Handlings der Pipeline sowie um eine neue Branch-Prediction-Unit (eine Einheit, welche die Vorhersage für die Verzweigungs-Befehle tätigt). Zusammen tragen diese beiden Veränderungen zu mehr als 50 % der Steigerung der Verarbeitungsleistung bei.
Die Speicher-Struktur wurde mit einem „Store-Hit-FIFO“ modifiziert. Das zwei Elemente tiefe Store-Hit-FIFO wird genutzt, um eine Blockade zu verhindern, wenn ein Store- und ein Load-Befehl gleichzeitig auf ei-ne Speicherstelle im Cache-Speicher zugreifen wollen. Stattdessen wird der Inhalt des Store-Registers im FIFO gespeichert und unabhängig vom Load-Befehl abgelegt.
Ein zwei Elemente tiefes FIFO wird dabei so genutzt, dass aufeinander folgende Load/Store-Befehle handhabbar sind, sodass ausreichend Zeit für ein Reload des Cache-Speichers vorhanden ist. Dies vermeidet Blockaden.
Wenn ein Load-Befehl in der DA1-Stufe auf eine Adresse zugreift, die den gleichen Seiten-Offset wie ein Store-Befehl in der DA2-Stufe aufweist, dann wird der Load-Befehl auf Eis gelegt. In der Praxis bedeutet das, dass der Befehl am Beginn der Prozessor-Pipeline neu eingereiht und dann nochmals ausgeführt wird – ein Szenario, das verhältnismäßig selten vorkommt und nur geringe Auswirkungen auf die Gesamtleistung hat.
Die andere wesentliche Veränderung erfolgte in der Branch-Prediction Unit (BPU), denn sie wurde mit einem neuen Branch-Prediction-Algorithmus modifiziert. Außerdem hat ARC die Größe der Branch-Prediction-Tabelle verdoppelt und um Zweiwege-Assoziativität ergänzt.
Der neue Algorithmus der BPU nutzt die Historie der letzten vier Branch-Befehle, um die Vorhersage des nächsten Satzes von Befehlen zu verbessern. Damit verringert sich die Wahrscheinlichkeit einer falschen Vorhersage. Die Prozessorentwickler haben eine Vielzahl von Branch-Prediction-Modellen untersucht – Kunden-Code sowie Beispiel-Code aus dem Internet für die entsprechenden Modelle unter die Lupe genommen, um ein Modell zu finden, das die besten Ergebnisse liefert.
Im Rahmen der Modellierung stellte sich heraus, dass ein Blick in die Vergangenheit, ob die vorherigen vier Branch-Befehle ausgeführt wurden, in Kombination mit dem Einbeziehen des Program-Counters zu den genauesten Vorhersagen für den nächsten Branch-Befehl führte.
Dies alles wurde in der BPU zusammen mit einer neuen, 256 Einträge umfassenden Tabelle implementiert. In der Praxis bedeutet das, dass nunmehr zu einem beliebigen Zeitpunkt doppelt so viele Branch-Befehle vorhergesagt werden können. Die Zweiwege-Assoziativität ermöglicht es dem Compiler, die Branch-Befehle in dem Befehls-Fluss zu positionieren – und zwar mit einem geringeren Konflikt-Risiko zwischen zwei Branch-Befehlen, sodass die Sensitivität gegenüber der Platzierung von Branch-Befehlen verringert wird.
Diese verbesserte Branch-Prediction erhöht den Silizium-Flächenbedarf des Core um lediglich 7 % und zielt mehr auf die Nutzung des Core als Host-Prozessor ab, denn bei dieser Anwendung kommen Branch-Befehle häufiger vor. Von dieser Verbesserung profitiert die Implementierung des ARC750 D mehr als die abgespeckte Embedded-Core-Version 710D.
Neue MAC-Einheit und bedingte Evaluierung
Es gab aber auch Veränderungen am XMAC, was besonders für Anwendungen nützlich ist, die DSP-Code nutzen. Früher musste das Hilfsregister, das die Betriebsart einer MAC-Einheit bestimmt, vor dem nächsten Befehl die Pipeline leeren. In einigen Modi, die zwischen verschiedenen Betriebsarten umschalteten, war das allerdings ein Problem. Jetzt wird die Pipeline nur noch dann geleert, wenn es für diesen Modus notwendig ist. Dadurch verringert sich die Anzahl der Blockaden in der Pipeline.
Zu den weiteren Veränderungen gehört die bedingte Evaluierung, bei der zuvor zwei Werte, die gespeichert werden sollten, warten mussten, bis eine Evaluation stattfand. Jetzt können die Werte durch die Pipeline hindurchgelangen, und die Ergebnisse der Evaluation werden weitergeleitet. Es gab aber auch Veränderungen der Eckfälle beim Multiplizierer, der Write-after-Write-Performance (der Verarbeitung von zwei aufeinander folgenden Schreib-Befehlen) sowie Veränderungen der Debugging-Hardware. Während letzteres sich zwar nicht auf die Verarbeitungsleistung auswirkt, handelt es sich dennoch um ein nützliches Update zur Entwicklung von stabilen integrierten SoC-Bausteinen auf Basis von ARC-Cores.
Bisher musste der Core im Debugging-Modus stets mit einem Poll getriggert werden, um den Core auf einen Hold-Status hin zu überprüfen. Um diese Aufgabe zu übernehmen, fügte das Debugging-Modul einen Befehl in die Pipeline ein. Jetzt wird der Status über einen direkten Pfad abgefragt, was die Aufdringlichkeit des Debuggers in großem Umfang verringert.
Mehr als nur Compileranpassung
Zu den weiteren Veränderungen gehören Modifikationen des Compilers, teilweise um die neue Hardware mit einzubeziehen. Diese Veränderungen führten zu einer Erhöhung der Gesamt-Verarbeitungsleistung um signifikante 10 %, wobei auch Verbesserungen des Scheduling von Load-Befehlen für Funktions-Parameter und zurückgelieferte Werte sowie das „Sizing“ kleiner Funktionen zur Unterstützung des Stacks gehören, der für den Rücksprung aus Subroutinen benötigt wird. Auch das Scheduling für Slow-Track-Befehle wurde verbessert.
Auch beim Scheduling gab es einige Veränderungen von bedingten Befehlen, weiter Verbesserungen der temporären Register-Zuweisung um Funktions-Aufrufe herum sowie eine Anpassung der Funktions-Ausgänge, um so ein unnötig aufgeblähtes Alignment (so genannte Alignment-Bubbles) zu vermeiden. Auch die Selektions-Kriterien für MPY-Befehle wurden verbessert, sodass jetzt keine Shift-Addier-Multiplizier-Operation mehr nötig ist und auch die Überprüfung zweier Zeichen auf Übereinstimmung wurde beschleunigt.
2002 wurde zu diesem Zweck von einer Reihe von OEMs und Zulieferern die AUTOSAR-Partnerschaft (Automotive Open System Architecture) gegründet, die vor allem die folgenden Ziele verfolgt [3]:
- Implementierung und Standardisierung von System-Basisfunktionen als OEM-weite »Standard Core«-Lösung
- Skalierbarkeit an verschiedene Fahrzeug- und Plattformvarianten
- Verschiebbarkeit von Funktionen im gesamten Netzwerk
- Integration funktioneller Module von unterschiedlichsten Zulieferern
- Beachtung von Verfügbarkeit und Sicherheitsanforderungen
- Redundanz-Aktivierung
- Wartbarkeit über den gesamten Lebenszyklus
- Verstärkte Verwendung kommerzieller Fertighardware (COTS-Hardware)
- Software-Updates und –Upgrades über die gesamte Lebensdauer eines Fahrzeugs
Abbildung 4 zeigt die dabei erarbeitete Architektur mit ihren verschiedenen, in drei Hauptbereiche unterteilten Softwareschichten. Die Anwendungsschicht (Application Layer) enthält die funktionellen Anwendungen des ECU-Netzwerks. In der Terminologie des Standards heißen diese Anwendungen AUTOSAR-Softwarekomponenten. Die AUTOSAR-Laufzeitumgebungsschicht (Real-Time Environment, RTE) wurde eingeführt, um die Anwendungssoftware effektiv von der Infrastruktur-Software zu entkoppeln. Die zwischen dem Mikrocontroller und der RTE angesiedelte Basissoftware-Schicht (AUTOSAR Basic Software Layer) definiert schließlich die Infrastruktur-Software in Form hardwareabhängiger und hardwareunabhängiger, nicht funktionstragender Dienste.
Verbessertes Hardware-Layout
Es gab aber auch Verbesserungen im Backend-Layout der Cores, die es ermöglichen, eine exaktere Takt-Abweichung von 150 ps zu nutzen, wodurch sich eine höhere Verarbeitungsleistung ergibt. ARC nutzt jetzt auch die Virage-Speicher-Bibliotheken für 0,13 µm mit besseren Leistungsdaten, das führt wiederum zu einer höheren System-Performance.
All diese Veränderungen ermöglichen es der Core-Familie 700, die kritischen Anforderungen in punkto Taktfrequenz zu erfüllen, die für eine Direkt-Ansteuerung von DDR2-Speichern erforderlich sind. Auch das Betriebssystem wird davon profitieren. Die ARC-Cores der Serie 700 unterstützen ThreadX, MQX, Java, µltron, µCLinux und Embedded-Linux. Bild 4 zeigt das Chip-Lay-out einer auf maximale Taktfrequenz getrimmten ARC700-Implementierung.
Die Unterstützung dieser Geschwindigkeit ermöglicht es insbesondere dem ARC-Core 750D, auch als Host-Prozessor in einem System zum Einsatz zu kommen. Die höhere Verarbeitungsleistung gestattet es, mehr Funktionen im Core per Software abzuarbeiten, sodass die Flexibilität bei der System-Entwicklung ansteigt und Upgrades leichter möglich werden. In Kombination mit den DSP- und Gleitkomma-Befehlen können mehr Funktionen im Core integriert werden. Dadurch sinken die Kosten und die Komplexität des Systems, weil die Coprozessoren und Hardware-Blocks wegfallen.
Wie bereits erwähnt, ist die Entkopplung der funktionstragenden Anwendungssoftware von der Target-Hardware eines der Hauptziele von AUTOSAR. Um dieses Ziel zu erreichen, wurde der Virtual Functional Bus eingeführt. AUTOSAR-Softwarekomponenten bilden die Anwendungsschicht und enthalten die Funktionalität einer einzelnen ECU oder eines ganzen ECU-Netzwerks. Diese Softwarekomponenten sind mit wohldefinierten und standardisierten Schnittstellen ausgerüstet. Jede AUTOSAR-Softwarekomponente gehört zu genau einer einzigen ECU. Eine ECU dagegen kann aus vielen verschiedenen Softwarekomponenten bestehen.
Der Virtual Functional Bus vermittelt die Kommunikation zwischen den verschiedenen AUTOSAR-Softwarekomponenten, unabhängig von deren Position im ECU-Netzwerk eines Fahrzeugs. Durch dieses Konzept lässt sich jede AUTOSAR-Softwarekomponente prinzipiell an jedem Ort dieses Netzwerks integrieren und auch beliebig innerhalb des Netzwerks verlagern. In der Implementierungsphase ist die generierte Laufzeitumgebung eine spezifische Instanz des Virtual Functional Bus.
Entwicklung von AUTOSAR-Softwarekomponenten
Das Konzept und die Vorteile des Model-Based Design sind im AUTOSAR-Kontext sogar noch wertvoller, weshalb es sinnvoll ist, den Einsatz der Methode in Zukunft auf noch mehr Anwendungsfelder auszudehnen. Wenn ein Unternehmen sich einmal entschieden hat, seine ECUs nach einem AUTOSAR-konformen Prozess zu entwickeln, braucht es seine Entwicklungs- und Software-Ingenieure nicht zwingen, ihren bisher gewohnten Workflow zu diesem Zweck völlig umzustellen. Der von The MathWorks angebotene, auf MATLAB, Simulink und dem Real-Time Workshop Embedded Coder basierende Ansatz zur Entwicklung von AUTOSAR-konformem Programmcode ist transparent und intuitiv. Er unterstützt zwei verschiedene Workflows: Top-Down und Bottom-Up.
Top-Down: Vom Architekturmodell zur AUTOSAR-Softwarekomponente
Beim Top-Down-Ansatz entwerfen die Ingenieure Architekturen von ECU-Netzwerken in Architektur-Entwicklungstools (in der AUTOSAR-Terminologie als Authoring Tool bezeichnet) wie etwa der DaVinci Tool Suite von Vector Informatik. Die Möglichkeit, auch andere Authoring Tools einzusetzen, wird dadurch in keiner Weise eingeschränkt. Danach wird eine XML-Beschreibung aller Komponenten exportiert: Die AUTOSAR Software Component Description. Diese Datei enthält alle notwendigen Informationen über die Komponenten wie Runnables, Schnittstellenbeschreibungen, Datentypen etc.
 | Peter Hutton, Vice President Engineering von ARC International, besitzt mehr als 20 Jahre Berufserfahrung bei IP- und IC-Unternehmen. Von 1998 bis 2002 arbeitete er als Design Centre Manager des größten IC-Designzentrums von Cadence, war damit für Designprojekte mit mehreren Prozessor-Cores verantwortlich und leitete den Aufbau und den Betrieb des Soft-IP-Geschäfts von Cadence. Zuvor war er bei Cadence als Senior Solution Architect im Bereich Consulting und Technical Sales eingesetzt. Hutton begann seine berufliche Laufbahn als Prozessordesigner bei Unisys und arbeitete später unter anderem bei ES2 und Plessey Research. peter.hutton@arc.com |
 | Daniel Hansson studierte an der Lund Universität in Schweden und schloss dort 1996 mit dem Master-Grad ab. Er arbeitete für Ericsson und Texas Instruments im digitalen ASIC-Entwurf, sowohl als Designer als auch als Projekt-Manager, bevor er dann zu ARC International wechselte. daniel.hansson@arc.com |
Mit der AUTOSAR-Lösung von The MathWorks können Ingenieure diese XML-Datei importieren und in Simulink damit automatisch ein Skelettmodell erzeugen, das die Schnittstellenblöcke (Inports und Outports) sowie sämtliche AUTOSAR betreffenden Einstellungen für diese Objekte in der Form enthält, wie sie in der Beschreibungsdatei der Softwarekomponente definiert sind. Abbildung 6 illustriert diesen Workflow. Mit Funktionen der MATLAB-API importiert man von der Kommandozeile aus die XML-Datei mit der AUTOSAR Software-Komponentenbeschreibung und erzeugt das Skelettmodell auf der Grundlage der darin vorgegebenen AUTOSAR-Einstellungen. Mit dem Skelettmodell als Ausgangsbasis entwickeln dann die Ingenieure das Controllermodell mit Simulink, Stateflow und möglicherweise zusätzlich benötigten Blocksets (Abb. 7).
- Entwicklung von AUTOSAR Software-Komponenten mit Model-Based Design
- Wirkungsvolle Modellpflege
- Entwicklung von AUTOSAR Software-Komponenten mit Model-Based Design
