Suchen

Praxisbericht Rapid Prototyping und Model Based Design in der Sensorentwicklung

| Autor / Redakteur: Martin Hein * / Franz Graser

Der Anwenderbericht des Automobilzulieferers Hella Fahrzeugkomponenten dokumentiert den Entstehungsprozess von Software für Sensorsysteme im Auto.

Firma zum Thema

Intelligente Sensorik: Das Reifendruck-Kontrollsystem von Hella besteht aus vier Radsensoren, einem elektronischen Steuergerät sowie einem Multicolor-Display.
Intelligente Sensorik: Das Reifendruck-Kontrollsystem von Hella besteht aus vier Radsensoren, einem elektronischen Steuergerät sowie einem Multicolor-Display.
(Copyright: Hella)

Bevor Automobil-OEMs ein neues Sensorsystem beschaffen, ist es wichtig, dass sie seine Funktion anhand eines Echtzeit-Prototypen in einer Fahrzeugumgebung prüfen können, um seine Leistung zu evaluieren und gegebenenfalls die Spezifikationen zu ändern.

Daher müssen Produzenten wie Hella oft eine frühe Version ihrer Sensorsysteme präsentieren. Diese umfassen normalerweise Algorithmen und Logiken, die auf einem FPGA oder Mikroprozessor implementiert wurden. Um dieser Anforderung zu entsprechen, verwendet Hella eine spezifische Rapid Control Prototyping-Plattform und Model-Based Design, wodurch das Unternehmen Echtzeit-Prototypen neuer Entwürfe in einem frühen Stadium des Entwicklungsprozesses erstellen kann.

Der Echtzeit-Prototyp, der bei Hella als A-Muster bezeichnet wird, dient sowohl der Machbarkeitsanalyse als auch als anpassbare Spezifikation während der gesamten Entwicklung.

Erstellung einer flexiblen Prototyping-Umgebung

Hella hat die HFK RCP-Plattform (HFK-RCP: Hella Fahrzeugkomponenten GmbH Rapid Control Prototyping) entwickelt, da handelsübliche Alternativen nicht über die benötigte Flexibilität verfügen. Die meisten Standard-Prototyping-Systeme unterstützen nur die ECU-Softwareentwicklung (ECU: Electronic Control Unit, elektronisches Steuergerät). Ein Sensorentwurf umfasst bei Hella jedoch auch VHDL-Code und spezielle Elektronikkomponenten (VHDL: Very High Speed Integrated Circuit Hardware Description Language).

Die zweite Beschränkung eines handelsüblichen Systems ist der feste Umfang an bereitgestellten Schnittstellen. Ein Komponenten-Hersteller muss diverse Kommunikationsprotokolle und unterschiedlichste Schnittstellenhardware unterstützen. Dazu gehören SPI, I2C, LIN, XCP, CAN und SENT.

Mit Model-Based-Design und der spezifischen Prototyping-Umgebung lassen sich neue Schnittstellen, Protokolle und Funktionalitäten nach Bedarf hinzufügen. Die Ingenieure können bei der Entwicklung von Spezifikationen Prozessoren und FPGAs als Ziel definieren und die Prototyping-Umgebung verwenden, um Algorithmen zu erweitern oder zu verbessern, die bereits auf einem im Feld eingesetzten Prozessor implementiert wurden.

Der Entwicklungsprozess bei Hella entspricht dem bekannten V-Modell und umfasst fünf Schritte:

  • Anforderungsanalyse,
  • Algorithmen-Entwurf,
  • Generierung von Produktionscode,
  • Codeverifikation,
  • Testen.

Abbildung 1: Das Systemmodell in Simulink.
Abbildung 1: Das Systemmodell in Simulink.
(Bild: Hella)

In der Phase der Anforderungsanalyse arbeitet das Team eng mit dem Kunden zusammen, um Systemanforderungen in DOORS von IBM Rational zu definieren. Anschließend wird ein Initialmodell des Entwurfs im Werkzeug Simulink erstellt (Abbildung 1).

Von den Anforderungen bis zum Design

Hella verwendet das Tool Simulink Verification and Validation für die Zuordnung der Anforderungen in DOORS zu Elementen des Modells. Damit ist eine bidirektionale Rückverfolgbarkeit der Anforderungen möglich.

Bei der Erstellung des Modells stellt der Model Advisor sicher, dass die Modellierungsrichtlinien des MAAB (MathWorks Automotive Advisory Board) eingehalten werden. Außerdem führt das Team mit dem Model Advisor Überprüfungen aus, die auf intern bei Hella entwickelten Richtlinien basieren.

Mit Simulationen in Simulink wird der anfängliche Entwurf in Gleitkommaarithmetik frühzeitig einer funktionalen Prüfung unterzogen. Dabei stimulieren die Ingenieure das Modell mit Testdaten, die von einem ähnlichen Sensor erfasst oder mit einem Simulink-Block generiert wurden.

(ID:44912673)