Bevor Automobil-OEMs ein neues Sensorsystem 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 Sensoren präsentieren, die zumeist Algorithmen und Logiken, die auf einem FPGA 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 ASIC 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 SPI, I2C, LIN, XCP, CAN und SENT.

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.

Seite 1 von 212