Mit bis zu hundert eingebauten Embedded-Prozessoren fahren heutige Autos zunehmend auf der Basis von Software-Code. Die Software-gesteuerten Fähigkeiten in modernen Infotainment-Systemen können inzwischen problemlos mit den Unterhaltungssystemen und Computern in unseren Wohnungen mithalten, womit der Einfluss der Software auf die Entwicklung der SoCs (System-on-Chip) hoch ist. Die Integration der kompletten Hardware und Software, um zum Beispiel ein GENIVI-basiertes Infotainment-System zum Laufen zu bringen, ist somit keine einfache Aufgabe. Dies erfordert viel Simulation, Modellierung, Verifikation und die Wiederverwendung von vordefinierten Halbleiter-IP-Blöcken.
Der Kampf um die Lieferung von Informationen und Unterhaltung für einen der wichtigsten Hubs in unserem Leben – das Auto und hier im Besonderen das In-Car Entertainment – ist voll entbrannt. Eine der Schlüsselfragen für Entwickler ist die Auswahl der richtigen Hardware-/Software-Kombination. Wie in anderen Bereichen unseres Lebens wird der Hauptkampf zwischen Apple, Google und Open Source Linux ausgefochten, mit Initiativen wie der Open Automotive Alliance der GENIVI Alliance und Windows Embedded Automotive OS.
Ein charakteristisches Merkmal all dieser Initiativen ist der Bedienkomfort, der unabhängig von der jeweiligen Implementierung des Betriebssystems (OS) ist, und das als Abstraktionsebene für die Hardware dient. Das hat zwei Herausforderungen zur Folge:
hohe Hindernisse für die Validierung der Software im Zusammenhang mit der Hardware, auf der diese ausgeführt wird, sowie
sehr spezifische Anforderungen an die Zusammenarbeit der verschiedenen Entwickler in der Design-Chain.
Design-Chain im Consumer- und Kfz-Bereich
Im Allgemeinen umfasst die Unterhaltungselektronik-Design-Chain fünf primäre Unternehmenstypen, die an der Entwicklung der Elektronik beteiligt sind. Erstens liefern IP-Anbieter verschiedene Bausteine an die Halbleiter-Unternehmen, wie Prozessoren oder Grafik-Cores sowie Peripherie, um Chips mit Schnittstellen und untereinander zu verbinden.
Zweitens stellen Halbleiter-Unternehmen die Halbleiter zur Verfügung, welche die Grundlage für die Sensoren in unseren Autos oder im Schrittzähler am Handgelenk, in unseren Mobiltelefonen oder Servern bilden. Letztere speichern die Informationen, und die Netzwerke übertragen diese entweder drahtlos über Mobiltelefone oder eingebaute Autotelefone oder drahtgebunden über Ethernet im Auto, bis die Daten im Netzwerk des Telefonanbieters landen.
Drittens bauen Systemunternehmen die an dieser Kette beteiligten Geräte, beispielsweise das Armband, das Mobiltelefon und die Server, die unsere Informationen speichern. In diesem Fall kann das Systemunternehmen nicht nur das Armband liefern, mit dem Bewegungen erfasst werden. Sondern auch die Server betreiben, welche die Informationen speichern sowie eine Big Data Analyse ausführen, was entweder selbst oder mit Hilfe der kommerziellen Infrastruktur eines Cloud-Service-Providers erfolgt.
Viertens helfen unabhängige Software-Anbieter bei der Software-Entwicklung und unterstützen dieses Szenario mit den Tools , die auf Android, Linux oder kommerziellen Betriebssystemen, wie iOS und Windows Mobile, laufen. Und schließlich wird die notwendige drahtlose oder drahtgebundene Infrastruktur von Netzwerkanbietern betrieben, die an der Spitze der Kette sind und direkt mit den Endbenutzern interagieren. Diese erlauben den Geräten die oben beschriebenen Interaktionen auszuführen.
Abbildung 1 zeigt die Komplexität einer Automotive-Design-Chain auf. Die Systeme sind so komplex, dass es zwei Arten von Systemhäusern gibt: Der eigentliche OEM, der das Auto produziert, und die so genannten Tier-1-Anbieter, die Halbleiter-Komponenten (die auch lizenzierte IP und System-on-Chip-Subsysteme enthalten) in Subsysteme auf Baugruppenebene (Steuergeräte) integrieren.
Abbildung 1 verdeutlicht auch die jeweiligen Zuständigkeiten in der Softwareentwicklung. Automotive OEMs, welche das eigentliche Auto liefern, konzentrieren sich mehr auf Anwendungen und Bedienkomfort. Tier-1-Anbieter und Subsystem-Integratoren konzentrieren sich auf Aufgaben-orientierte Middleware, während sich Tier-1-Anbieter auf Standardservices, die ECU-Abstraktion und komplexe Treiber fokussieren. Als ein Teil ihres Halbleiter-Angebots müssen Halbleiter-Unternehmen grundlegende Abstraktionsebene-Software, wie die MCU-Abstraktion MCAL, zur Verfügung stellen. Auf Grund der Anforderung die Software zwischen verschiedenen MCUs und ECUs flexibel portieren zu können, wurden Standards wie AUTOSAR (AUTomotive Open System ARchitecture) entwickelt. Diese stellen eine grundlegende Infrastruktur zur Verfügung, um eine Komponenten-basierte Entwicklung von Automotive-Software, Bedienoberflächen und des Anwendungsmanagements zu ermöglichen.
Entwicklungsverfahren für den Kfz-Bereich
Es gibt derzeit keine Chip- und Systementwicklungs-Engine, weder Hardware- noch Software-basiert, die alle erforderlichen Nutzungsmodelle und Benutzeranforderungen für die Hardware- und Software-Verifikation abdeckt. Häufig hilft nur eine Kombination von Engines, damit die Anwender ihre Herausforderungen bei der Verifikation und Software-Entwicklung effizient erfüllen können. Bevor eine wirklich implementierbare Darstellung des Chips auf RTL(Register Transfer-Level)-Ebene zur Verfügung steht, erlauben virtuelle Prototypen eine Software-Entwicklung auf der Basis von Transaktionsmodellen der Hardware. Für die RTL-Ausführung können die Anwender eine Simulation, Emulation und ein FPGA-basiertes Prototyping nutzen, bevor der wirkliche Chip verfügbar ist.
Die Hardware-Software-Abhängigkeiten können kompliziert sein und einen großen Einfluss auf die Time-to-Market haben.Betrachten wir zum Beispiel den Test eines voll ausgestatteten 10/100/1000M Automotive Ethernet-MAC. Die Anwender fordern Merkmale wie eine Embedded-Echtzeit-Uhr sowie Zeitstempel, Hardware-Support für AVB (Audio Video Bridging) einschließlich Priority Queuing und Traffic Shaping. Erst dann ist das Ethernet in der Automobilelektronik einsetzbar. Es werden verschiedene Schnittstellen wie RMII, RGMII und SGMII benötigt, um eine Verbindung zu Off-Chip PHYs, AHB oder AXI4-konformen Bus-Master-DMA-On-Chip-Schnittstellen herzustellen. Beim Kauf der IP erwarten die Anwender, dass geeignete Software verfügbar ist, also ein Software-Stack einschließlich Treiber sowie ein TLM-Modell für das virtuelle Prototyping.
Um zu überprüfen, dass die Software und Hardware richtig zusammenarbeiten, können virtuelle und RTL-basierte Umgebungen kombiniert werden, um das Beste aus beiden Welten zu erhalten - Geschwindigkeit für die Software-Ausführung und Genauigkeit für RTL. Hybride TLM-/Emulationsumgebungen erlauben eine Kombination des genauen RTL für alle Blöcke, die auf der Emulation laufen. Die Firmware läuft dagegen auf einem virtuellen Prozessor-Modell, wie einem Cortex-R4 von ARM. Dies alles ist dann in eine virtuelle Plattform integriert. Alle MACs sind über den ARM-Prozessor konfigurierbar, Priority Queues können aufgesetzt werden und das Senden und Empfangen von Datenverkehr zwischen MACs lässt sich mit verschiedenen Datenprüfungen vergleichen.
Wegen der hohen Kontrollierbarkeit können Testcode und Testpakete on the Fly mit Debuggern ins Design vorgeladen werden. Alle Signale und Busse lassen sich im laufenden Betrieb bei voller Geschwindigkeit beobachten. Außerdem haben Unternehmen wie Broadcom und NVIDIA gezeigt, dass dieselbe kombinierte Umgebung - Transaktionsmodelle für die Software-Ausführung auf Prozessor-Subsystemen und Emulation zur Ausführung der restlichen Hardware - ideal für Hardware-/Software-Entwicklungsteams geeignet ist. Dadurch können diese das Bring-up von Betriebssystemen um bis zu einem Faktor 60 und die Software-Ausführung bis zu einem Faktor 10 beschleunigen – alles bevor der eigentliche Halbleiter verfügbar ist.
Abbildung 2 zeigt die optimalen Punkte in der Pre-Silicon-Software-Entwicklungsumgebung einschließlich der bereits erwähnten TLM/Emulations-Kombination. Damit können die IP-Anbieter, Halbleiter-Anbieter, Tier-1-Anbieter, OEMs und deren Software-Entwickler das Betriebssystem und die Software aufsetzen, bevor man sich beim Halbleiter festlegt. Solche Umgebungen erlauben nicht nur eine effizientere Interaktion innerhalb der Design-Chain und ein viel früheres und effizienteres Bring-up der Software, sie können auch die funktionelle Sicherheit der Testprozesse deutlich verbessern, die in Standards wie ISO 26262 definiert sind.
.jpg "Dreh und Sprich")
