Prototyping

(Bild: Hella)

Bevor Automobil-OEMs ein neues erwerben, möchten sie die Funktion an einem Echtzeit-Prototyp des Sensors in einer Fahrzeugumgebung prüfen, um seine Leistung zu evaluieren und gegebenenfalls die Spezifikationen zu ändern. Automobilzulieferer müssen so häufig eine frühe Version ihrer präsentieren, die zumeist Algorithmen und Logiken, die auf einem oder Mikroprozessor implementiert sind, beinhalten. Um dieser Anforderung zu entsprechen, verwendet der Autozulieferer Hella eine benutzerdefinierte Rapid-Control-Prototyping-Plattform und Model-Based-Design, um Echtzeit-Prototypen neuer Entwürfe in einem frühen Stadium des Entwicklungsprozesses zu erstellen. Der Echtzeit-Prototyp, der bei Hella als A-Muster bezeichnet wird, dient dabei sowohl als Konzeptbestätigung als auch als reale Spezifikation während der gesamten Entwicklung.

Anstatt bis zu zwei Jahre auf eine ASIC-Implementierung zu warten, lässt sich so innerhalb weniger Monate ein A-Muster generieren, das etwa 80 Prozent der Funktionalität des Endprodukts umfasst. Das A-Muster ermöglicht eine frühzeitige Zusammenarbeit mit dem Kunden zur Optimierung der Funktionalität des Sensors und zur Evaluierung der Codegröße, der Partitionierung von Modulen und der Hardwarevoraussetzungen. Beim Testen kommt das A-Muster zu Anwendung, um die Testumgebung und Test-Suites einzurichten. So ist es möglich mit der Durchführung von Tests  zu beginnen, sobald ein auf einem oder einem Mikroprozessor implementiertes Produktionsmuster vorliegt.

Eine flexible Prototyping-Umgebung erstellen

Hella hat die HFK-RCP-Einheit (Hella Fahrzeugkomponenten Rapid Control Prototyping) entwickelt, da handelsübliche Alternativen nicht über die benötigte Flexibilität verfügen. Die meisten standardmäßigen Prototyping-Systeme unterstützen lediglich die ECU-Softwareentwicklung, jedoch umfasst ein Sensorentwurf auch VHDL-Code und spezielle Elektronikkomponenten. Die zweite Beschränkung eines handelsüblichen Systems ist der feste Satz an bereitgestellten Schnittstellen. Anwendungen des Automobilzulieferers müssen so eine Vielzahl von Kommunikationsprotokollen und unterschiedliche Schnittstellenhardware unterstützen. Dazu gehören , I2C, , , und .

Mit Model-Based-Design und der eigenen Prototyping-Umgebung kann das Unternehmen neue Schnittstellen, Protokolle und Funktionen bedarfsgerecht hinzufügen. Es ist möglich, bei der Entwicklung von Spezifikationen Mikroprozessoren und FPGAs als Ziel zu definieren und die Prototyping-Umgebung zu verwenden, um Algorithmen, die bereits auf einem Produktionsprozessor implementiert wurden, zu erweitern oder zu verbessern.

Von den Anforderungen bis zum Design

Der Entwicklungsprozess, der dem V-Modell folgt, besteht aus fünf Hauptschritten: Anforderungsanalyse, Algorithmen-Entwurf, Generierung von Produktionscode, Codeverifikation und Tests. In der Phase der Anforderungsanalyse arbeitet der Automobilzulieferer mit dem Kunden zusammen, um Systemanforderungen in IBM Rational DOORS zu definieren. Anschließend erstellt er ein erstes Modell des Entwurfs in Simulink (Bild 1).

Prototypüing

Bild 1. Simulink-Systemmodell. Hella

Hella verwendet Simulink Verification and Validation für die Zuordnung von Anforderungen in DOORS zu Elementen des Modells. Damit ermöglicht das Unternehmen die bidirektionale Rückverfolgbarkeit von Anforderungen. Bei der Erstellung des Modells kommt der Model Advisor zur Anwendung, um sicherzustellen, dass die Richtlinien zur MAAB-Algorithmusmodellierung (Mathworks Automotive Advisory Board) eingehalten werden. Darüber hinaus führt das Unternehmen Model-Advisor-Prüfungen durch, die auf intern bei Hella entwickelten Richtlinien basieren.

Um das anfängliche Modell in Gleitkommaarithmetik frühzeitig einer funktionalen Prüfung zu unterziehen, führt Hella Simulationen in Simulink aus. Dabei wird das Modell mit Testdaten stimuliert, die von einem ähnlichen Sensor erfasst oder mit einem Simulink-Block generiert wurden. Nach diesen Model-in-the-Loop-Tests analysiert das Unternehmen die mit Simulink Verification and Validation erstellten Modellabdeckungsberichte, um nicht getestete Elemente in seinem Modell zu identifizieren. Dabei werden die Tests nach Bedarf aktualisiert, um eine höhere Abdeckung zu erzielen.

Als Vorbereitung für die Tests auf der Rapid-Prototyping-Plattform wird die Kommunikationsschnittstelle modelliert, die für die Ausführung der Sensoralgorithmen in einem Fahrzeug notwendig ist. In Zusammenarbeit mit Beratern von Mathworks hat Hella einen LIN-Blocksatz (Local Interconnect Networking) für Simulink entwickelt. Dieser Blocksatz ermöglicht es, die Funktionen des firmeneigenen Prototyping-Systems um eine LIN-Schnittstelle zu erweitern.

 

Lesen Sie auf der nächsten Seite: Vom Modell zum Prototyp und vom Prototyp zur Produktion.

Vom Modell zum Prototyp

Nach einem internen Review des Modells wird der Entwurf an die HFK RCP-Einheit übergeben (Bild 2). HFK RCP unterstützt eine breite Palette von Konfigurationen mit einer Auswahl von Prozessoren beziehungsweise FPGAs. Dazu gehören ein TI C2000-Mikroprozessor, ein Xilinx-FPGA und Konnektoren für Busse und Sensoren, die in der Automobilindustrie verwendet werden, sowie ein Bereich für spezielle Elektronikkomponenten.

Bei Entwürfen für den Einsatz auf einem Mikroprozessor nutzt das Unternehmen den Embedded Coder, um C-Code aus unserem Simulink-Modell zu generieren und den Code auf dem TI C2000-Prozessor auf der HFK-RCP-Einheit zu implementieren. Wenn für Teile oder den gesamten Entwurf ein FPGA erforderlich ist, verwendet Hella den HDL-Coder, um VDHL-Code aus dem Modell für die Implementierung auf dem Xilinx-FPGA zu generieren.

Prototyping

Vom Prototyp zur Produktion

Nach der Verifikation des A-Musters zur Konzeptbestätigung mit der HFK-RCP-Einheit bereitet das Unternehmen den Entwurf für die Implementierung auf dem Serienprozessor vor. Hella verwendet den Fixed-Point-Advisor im Fixed-Point-Designer, um das eigene Gleitkommamodell in einen anfänglichen Festkommaentwurf zu konvertieren. Mit dem Fixed-Point-Advisor ist es möglich, die Codegröße, die Speicherkapazität und die Festkomma-Skalierung zu optimieren. Im Anschluss wird die Einhaltung der Modellierungsrichtlinien erneut überprüft und Simulationen mit Simulink Verification and Validation ausgeführt, um Informationen zur Modellabdeckung und zur zyklomatischen Komplexität zu erhalten. Das Unternehmen vergleicht die Ergebnisse aus den Gleitkomma- und Festkommamodellen, um sicherzustellen, dass keine Fehler während der Konvertierung entstanden sind.

Danach werden SIL-Tests (Software-in-the-Loop) verwendet, um die Implementierung unserer Algorithmen in C zu überprüfen, und PIL-Tests (Processor-in-the-Loop), um den Algorithmus auf Echtzeit-Hardware zu kontrollieren. Auf diese Weise soll sichergestellt werden, dass das bereits untersuchte Modell ohne Fehler implementiert wird.

Eck-DATEN

Autozulieferer Hella nutzt eine benutzerdefinierte Rapid-Control-Prototyping-Plattform und Model-Based-Design, um Echtzeit-Prototypen neuer Entwürfe in einem frühen Stadium des Entwicklungsprozesses zu erstellen. Dabei kommt die Software Simulink von Mathworks zur Anwendung.

Zur Ausführung von SIL-Tests nutzt Hella den Simulink Coder, um C-Code aus dem Teil des Sensoralgorithmus im firmeneigenen Simulink-Modell zu generieren. Anschließend werden diese Teile im Modell durch eine S-Funktion ersetzt, die den generierten C-Code enthält, und die Simulationen wird erneut ausgeführt. Es folgt ein weiterer Vergleich der Ergebnisse mit früheren Testergebnissen, dieses Mal, um die Softwareimplementierung zu überprüfen.

Hella hat kürzlich mit dem Consulting von Mathworks zusammengearbeitet, um eine Embedded-Coder-Integration für die 78K-Familie von Mikrocontrollern zu entwickeln, sodass PIL-Tests auf dem Renesas-78K-Mikrocontroller ermöglicht wurden. Hella kann nun den Embedded-Coder verwenden, um Code zu generieren, den das Unternehmen auf einer Einheit für PIL-Tests und Tests im Fahrzeug bereitstellt.

Der Weg von der prototypischen Implementierung zum produktiven Einsatz hängt von der Implementierung des Prototyps ab. Wenn Hella den HDL-Coder zur Generierung von VHDL-Code für ein FPGA verwendet hat, übergibt das Unternehmen seinen Entwurf und den generierten VHDL-Code an einen externen Partner, der einen auf der Basis des Prototyps produziert. Da das Modell und die zugehörige HDL-Implementierung gründlich überprüft wurde, sind für ASICs bedeutend weniger Iterationen erforderlich. Dadurch lassen sich Kosten senken und Projektverzögerungen vermeiden.

Wenn Hella jedoch einen Mikrocontroller als Prototyp vorgesehen hat, setzt das Unternehmen die Produktion innerhalb von Hella fort. Das Unternehmen nutzt den Embedded-Coder zur Generierung von ANSI C-Code aus dem Festkommamodell in Simulink und definiert den Mikrocontroller für den produktiven Einsatz als Ziel. Der generierte Code wird intern einem strengen Testverfahren unterzogen. Dazu gehören Integrationstests und statische Analysen mit Polyspace Client for C/C++ und Polyspace Server for C/C++. Die abschließende Integration des ANSI C-Codes auf dem Zielprozessor erfolgt dann mit IBM Rational Rhapsody (C/C++).

Durch die Optimierung der Codegenerierungseinstellungen und die Einhaltung der festgelegten Modellierungsrichtlinien konnte der Automobilzulieferer Produktionscode generieren, der kompakter als entsprechender handgeschriebener Code ist. Indem das Unternehmen sein Prototypenmodell für die Generierung von Produktionscode wiederverwendet hat, konnte es die Entwicklungszeit um 60 Prozent reduzieren. Darüber hinaus kann das Unternehmen dank Model-Based-Design und der HFK-RCP-Einheit Tests in einer frühen Phase des Entwicklungsprozesses ausführen. Dies ermöglicht es, Anforderungen auszuwerten und Entwurfsentscheidungen einige Monate früher als zuvor zu prüfen.

Martin Hein,

Hella Fahrzeugkomponenten

(tm)

Sie möchten gerne weiterlesen?

Unternehmen

Hella KGaA Hueck & Co.

Rixbecker Straße 75
59552 Lippstadt
Germany

MathWorks GmbH-1

Adalperostr. 45
85737 Ismaning
Germany