Entwicklung von AUTOSAR Software-Komponenten mit Model-Based Design

Dieser Artikel zeigt, wie Ingenieure AUTOSAR-Softwarekomponenten mithilfe von Simulink-Modellen erzeugen können, ohne diese Modelle verändern zu müssen, und wie Beschreibungen von Softwarekomponenten wiederum in Simulink-Modelle umgewandelt werden können...

Mit einer Reihe von Modifikationen hat ARC die Leistungsfähigkeit des ARC750D-Cores an der Schnittstelle zu DDR2-Speichern signifikant erhöht. Herausgekommen ist dabei ein Core, der bei einer Taktfrequenz von 533 MHz eine Rechenleistung von über 800 MIPS liefert. Welche Veränderungen und Optimierungen die Prozessorarchitekten vorgenommen haben, lesen sie in diesem Artikel.

Dieser Artikel zeigt, wie Ingenieure AUTOSAR-Softwarekomponenten mithilfe von Simulink-Modellen erzeugen können, ohne diese Modelle verändern zu müssen, und wie Beschreibungen von Softwarekomponenten wiederum in Simulink-Modelle umgewandelt werden können. Vor der Darstellung dieser Workflows werden kurz das Model-Based Design sowie die Grundidee von AUTOSAR vorgestellt, um die verwendete Terminologie einzuführen und die Intention bezüglich der Zusammenführung von AUTOSAR und Simulink-Modellen aufzuzeigen.

Eine ganze Serie von Modifikationen hat die Verarbeitungsleistung der konfigurierbaren Cores aus der ARC700-Familie beachtlich erhöht. Die entsprechenden Modifikationen identifizierte ARC durch eine intensive Untersuchung von Code, den Kunden, andere Unternehmen der Branche und ARC selbst geschrieben haben. Dank der Modifikationen steigt die Verarbeitungsleistung der Cores beim Einsatz von realem Kunden-Code um 15 bis 30 %. Die Spitzen-Leistung schießt so auf 813 Dhrystone-MIPS in die Höhe, während die Taktfrequenz auf ein Minimum von 533 MHz in einem generischen 0,13-µm-Prozess ansteigt.

Diese Taktfrequenz reicht aus, um die neueste Generation von DDR-2-Speichern anzuschließen, und ermöglicht den Einsatz der konfigurierbaren Core-Familie in neuen wichtigen Anwendungen.

Autosar

Die Zahl elektronischer Steuergeräte (ECUs) in Kraftfahrzeugen steigt stetig – bei wachsender Komplexität der in diesen Controllern implementierten Algorithmen. Diese Situation ist zum Ausgangspunkt einer der seit Jahren wichtigsten Initiativen in der Automobilindustrie geworden. Unter dem Dach von AUTOSAR— der Automotive Open System Architecture — haben sich über 100 Unternehmen, Automobilhersteller, Zulieferer und Softwareanbieter mit dem Ziel zusammengeschlossen, eine Standardarchitektur für ECUs zu entwickeln. Ende 2006 wurde Version 2.1 des Standards freigegeben, und sowohl OEMs als auch Zulieferer haben nun mit der Entwicklung und Integration AUTOSAR-konformer Funktionalitäten und Komponenten begonnen.

Nach Ansicht vieler Beteiligter ist mit Version 2.1 die AUTOSAR-Basissoftware gereift, die zur Spezifikation von Anwendungs-Softwarekomponenten erforderliche Information hat sich stabilisiert. Als Folge hiervon haben spürbar mehr Softwareanbieter begonnen, die Stärken ihrer eigenen Tools mit denen der standardisierten AUTOSAR-Plattform zu verbinden. 2006 führte beispielsweise Volkswagen das Model-Based Design in seinen Entwicklungsprozess ein und integrierte eine AUTOSAR-konforme Komfort-ECU in seine vorhandene E/E-Umgebung [1]. 

Model-Based Design wird von Automobilingenieuren genutzt, um der Komplexität von Anwendungen und Algorithmen effektiv zu begegnen. Diese Methode gibt dem Anwender bereits in sehr frühen Entwicklungsstadien widerspruchsfreie und ausführbare Spezifikationen an die Hand. Fähigkeiten wie die automatische Verifikation, Validierung und Codegenerierung sind weitere wichtige Vorteile des Model-Based Design, durch die Entwicklungsprozesse effizienter und effektiver werden.

AUTOSAR spielt bereits jetzt in der Automobilindustrie eine wichtige Rolle als Standardarchitektur für ECU-Netzwerke. Obwohl derzeit die meisten Aktivitäten noch auf eine nähere Definition und eine Verfeinerung des Standards abzielen, beziehen doch viele OEMs und Zulieferer AUTOSAR fest in ihre Planungen für künftige Entwicklungsprozesse und Softwareumgebungen mit ein. Diese Vorausplanung erfordert Entscheidungen, die die gesamte Werkzeugkette betreffen, angefangen bei den Tools zur Entwicklung von ECU-Architekturen auf der Fahrzeugebene bis hin zu den Tools, mit denen das funktionelle Verhalten der für das Model-Based Design erforderlichen AUTOSAR Softwarekomponenten modelliert wird. Nicht zuletzt betrifft dies aber auch Werkzeuge zur Erzeugung von Laufzeitumgebungen und von Basissoftware-Komponenten.

Die Prozessorfamilie ARC700 ist intern durch eine siebenstufige Pipeline (Bild 1) gekennzeichnet und stützt sich auf „Out-of-Order“-Ausführungs-Einheiten, bei denen jeweils ein Befehl pro Taktzyklus abgearbeitet wird (Single Instruction Issue). Die Cores sind für SoCs (Systems on Chip) konzipiert und bieten sowohl spezielle DSP- und Gleitkomma-Befehle als auch die Möglichkeit, kundenspezifische Befehle zu definieren, um so die Ausführung spezifischer Aufgaben zu beschleunigen. ARCs patentierte Fähigkeiten im Bereich der Konfigurierung von Cores lassen sich nutzen, um die Cores an eine spezifische Anwendung anzupassen, sodass sich ein optimales Verhältnis zwischen Verarbeitungsleistung und Chipfläche ergibt.

Model-Based Design

Der konventionelle Prozess zur Entwicklung von Embedded Software findet auf dem Papier und durch manuelle Programmierung statt. Auf diese Phase folgt die Verifikation, etwa durch Code-Inspektionen und später durch Geräte- und Integrationstests. Für viele erforderliche Arbeitsschritte gibt es keine automatisierte Tools, sie werden vollständig per Hand durchgeführt und sind darum fehleranfällig und zeitraubend. Die eingesetzte Werkzeugkette ist außerdem oft wenig integriert. Dadurch steigt die Wahrscheinlichkeit weiter an, dass Fehler in die Software eingeschleppt werden, die man erst spät im Entwicklungsprozess entdeckt und dadurch hohe Kosten verursachen.

Konfigurierbare Cores wurden bisher schon oft für dedizierte Funktionen sowie als Coprozessoren innerhalb von SoCs genutzt. Mit dieser signifikanten Erhöhung der Verarbeitungsleistung kann ein Core aus der Prozessorfamilie 700 auch die Funktionen des Host-Prozessors übernehmen, die zuvor von den schnellsten Cores mit fester Architektur erledigt wurden. Solche Cores mit fester Architektur sind beispielsweise von ARM bzw. MIPS Technologies erhältlich.

Es gibt einige vorkonfigurierte Implementationen für die Core-Familie 700 von ARC, die allesamt von der erhöhten Verarbeitungsleistung profitieren. ARCs Design-Team nutzte die im Rahmen der Untersuchung gewonnenen Daten und durchforstete systematisch alle Elemente des Code, in denen es zu Verzögerungen kam, um anschließend das Design so zu verändern, dass die Verzögerungen behoben wurden. Exakt durch diese Maßnahmen erzielt ARC eine deutliche Steigerung der Verarbeitungsleistung (Bild 2).

Model-Based Design hat sich heute weithin als akzeptierte Möglichkeit durchgesetzt, diese Problematik gezielt anzugehen. Simulationen ermöglichen dem Entwickler tiefere Einblicke in die Dynamik und in algorithmische Details eines Systems, außerdem werden die aufgebauten Modelle für die verschiedensten Konstruktionsaufgaben eingesetzt. Sie dienen unter anderem:

  • als ausführbare Spezifikationen 
  • zum Austausch von Komponenten-Anforderungen und Schnittstellen-Definitionen zwischen Kunden und Zulieferern 
  • als virtuelle Prototypen von Fahrzeugsystemen sowie als Modelle von Fahrer, Straßenbedingungen und anderen zur Algorithmenentwicklung benötigten Umgebungsbedingungen
  • als Grundlage für die automatische Generierung der Software-Algorithmen in Form von Produktionscode

Die Nutzung von Modellen für all diese Aufgaben stellt sicher, dass der Konstruktionsprozess auf die Fehlervermeidung und eine frühzeitige Fehlererkennung konzentriert bleibt. Eine bereits ab den ersten Projektstadien stattfindende Verifikation und Validierung kann das mit der späten Entdeckung von Fehlern verbundene Risiko verringern.

Abbildung 1 zeigt ein Schema des Model-Based Design: Im Zentrum der Gesamtentwicklung steht ein Modell, das als ausführbare Spezifikation dient, aus dem automatisch Programmcode generiert wird und das verifiziert und validiert werden kann.

Rückverfolgbarkeit von Code und Anforderungen

Die Entwicklung von Embedded Software mit Model-Based Design beginnt in der Regel mit der Formulierung der Systemanforderungen auf einer hohen Abstraktionsebene. Diese Anforderungen werden häufig mithilfe spezieller Requirements Management Tools oder mit Textverarbeitungsprogrammen und Tabellenblättern verwaltet. Unabhängig von den eingesetzten Tools müssen die Ingenieure sicherstellen, dass ein Modell – und schließlich auch der daraus erzeugte Code – diese abstrahierten Anforderungen erfüllt. Wichtig ist deshalb eine robuste Rückverfolgungsfähigkeit, die Verknüpfungen zwischen allen Anforderungen und den zugehörigen Modellkomponenten erzeugt.

Vorkonfigurierte ARC700-Cores

Der ARC-Core 750D (Bild 3) enthält Cache-Speicher sowie eine Memory Management Unit (MMU). Mit seiner höheren Verarbeitungsgeschwindigkeit ist er in der Lage, einen mit 533 MHz getakteten DDR-Speicher direkt zu bedienen, sodass er sich ideal als System-Host-Prozessor eignet, auf dem ein anspruchsvolles Betriebssystem wie beispielsweise Linux läuft. Ein derartiger Core kann beispielsweise in SoCs für Anwendungen wie PDAs, Information-Tablets, High-End-Media-Player und Settop-Boxen sowie in Telematik-Applikationen im Automobil zum Einsatz kommen.

Mit zusätzlichen DSP- oder Gleitkomma-Befehlen ist der Core in der Lage, Funktionen abzuarbeiten, die zuvor nur in Coprozessoren oder mit dedizierter Hardware erledigt werden konnten. Wenn derartige Hardware-Elemente nicht mehr integriert werden müssen, dann verringern sich Größe und Kosten des SoC.

Der ARC-Core 725D umfasst zwar Cache-Speicher, aber keine MMU. Er könnte zum Beispiel in Kombination mit DDR2-Speichern genutzt werden, um ein nichtgeschütztes Betriebssystem wie uCLinux laufen zu lassen. Der ARC-Core 710D nutzt anstelle der Cache-Speicher eng gekoppelte Speicher für Embedded-Anwendungen. Dieser Core lässt sich nicht direkt mit dem Systemspeicher verbinden.

Im Laufe des Entwicklungsprozesses arbeiten die Ingenieure das Software-Designmodell zunehmend detaillierter aus, wobei sie es immer wieder verifizieren und validieren und damit gewährleisten, dass es die Anforderungen tatsächlich erfüllt. Aus Zustandsautomaten und Blockdiagrammen aufgebaute Modelle können mit Links ausgestattet werden, über die sich die in üblichen Requirements Management Tools niedergelegten Anforderungen bidirektional verfolgen lassen. Testfälle – sowohl per Hand definierte als auch automatisch erzeugte – können ebenfalls mit den Anforderungen verlinkt und so genutzt werden, um eine angemessene Abdeckung zu dokumentieren. In den späteren Entwicklungsphasen, also nach Erzeugung des target-spezifischen Produktionscodes aus dem Implementierungsmodell, sind im Real-Time Workshop Embedded Coder außerdem auf die Anforderungen bezogene Links zwischen den Programmanweisungen und dem Modell verfügbar. Industriestandards wie die  IEC 61508 [4] oder Automotive SPICE [5] fordern diese ausgeprägte Rückverfolgbarkeit für die Entwicklung sicherheitskritischer Software.

Ausführbare Spezifikation, Verifikation und Validierung

Die in einer Spezifikation definierten Anforderungen werden im folgenden Schritt in ein Modell übersetzt, also in eine formale, stark abstrahierte Beschreibung, die alle wichtigen funktionellen Merkmale wiedergibt. Diese Vorgehensweise hat zwei ganz zentrale Vorteile: Erstens ist das Modell widerspruchsfrei und zweitens enthält es exakt definierte Schnittstellen, durch die die Ingenieure ihre Konzepte bereits in einem sehr frühen Entwicklungsstadium ausführen können.