Fahrzeugnetze – Entwickeln oder Testen

10. August 2007, 11:27 Uhr | Thomas Heurung
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Fahrzeugnetze – Entwickeln oder Testen

Bild 4 zeigt das entsprechende Timing, um die beschriebene Funktion gemäß den Anforderungen zu implementieren. Es ist das relevante Timing dargestellt und nur der Worst-Case-Fall ist analysiert. Grundsätzlich müssen alle Signalketten innerhalb der gegebenen Spezifikation liegen, womit das System sehr komplex werden kann.

Nach Auslösen des DDMKnopfes wird die Zeit t1 benötigt, um dieses Ereignis zu erfassen. Nach Ablauf von t2 empfängt das PDM das »CentralLockRequest«- Signal und sendet das »LockRequestFRDU«- und »LockRequestRRDU«-Signal mit der Verzögerung t3 an den PDMLIN-Bus. FRDU empfängt das »LockRequestFRDU « nach Ablauf von t4 und benötigt t5 für die Signalverarbeitung und das Starten des Verriegelungsmechanismus. Nach t6 ist die Tür dann verriegelt bzw. geöffnet. Die restliche Kommunikation läuft entsprechend ab.

Die Spezifikation fordert, dass die Türverriegelung am FRDU nicht später als 250 ms nach Auslösen des Vorganges beendet ist. Um dies sicherzustellen, muss also die Summe der Timings (t1 bis t 6) gleich oder kleiner als 250 ms sein (Gleichung 1).

Netzwerkarchitektur

Der zweite Teil der Spezifikation fordert eine maximale Verzögerungszeit von 20 ms bis alle vier Türen verriegelt bzw. entriegelt sind. In dem gegebenen Beispiel weist die RLDU die schnellste und die FRDU die langsamste Verriegelungszeit auf. Daher muss Gleichung (2) beachtet werden.

Die Timinganalyse von Netzwerksignalen kann schnell komplex werden und erfordert daher einen strukturierten Ansatz, um zu entsprechend guten Ergebnissen zu kommen. Wenn erst mal die Anforderungen definiert sind, dann lässt sich das Timing automatisch analysieren und die Worst-Case-Latenzzeit für jedes Signal bestimmen. Mathematische Algorithmen ermöglichen die automatische Erzeugung von Netzwerkkonfigurationen, die per Design korrekt sind und daher nicht validiert werden müssen. Stattdessen ist lediglich die korrekte Implementierung zu überprüfen.

Um etwa die Timinganforderungen korrekt zu implementieren, sind alle Timingparameter so zu wählen, dass alle Signalketten innerhalb der maximalen Latenzzeit liegen. Dies lässt sich durch eine Methode erreichen, die man als »Deadline Monotonic Analysis« bezeichnet. Dieses Verfahren ist skalierbar und für eine große Anzahl von Signalen geeignet.

Um das Problem der Synchronität zu lösen beziehungsweise einen möglichst geringen Jitter zu erreichen, setzt man heute meist auf zeitgesteuerte Protokolle oder direkte Verbindungen statt Busse. Ist das Netzwerktiming berechnet, dann lassen sich die Konfigurationsdaten automatisch erzeugen und die Signale in Frames verpacken. Alle Daten wie das Signal-to-Frame- Mapping, Baudrate, Message- Filtering, etc. sind verfügbar.

Der erhöhte Aufwand in der frühen Phase des Designs bietet zahlreiche Vorteile für den gesamten Designprozess wie mehr Flexibilität für spätere Änderungen, eine bessere Nutzung der Ressourcen und eine erhöhte Zuverlässigkeit. Was aber vielleicht noch wichtiger ist, ist der Einfluss auf die Testund Validierungsphase. Im Unterschied zu einer »Spray and Pray«-Vorgehensweise erfolgt die Überprüfung auf mathematischer Basis. Der Testvorgang verifiziert die korrekte Implementierung eines als korrekt bekannten Designs mit einem entsprechenden Testvektor. Dafür stehen heute Tools zur Verfügung, welche diese Tests vollautomatisch ausführen und fehlerhafte Implementierungen anzeigen. Statt Monate bei einem herkömmlichen Testansatz zu verbringen, lässt sich dieser Prozess auf Wochen oder Tage reduzieren, und die Testingenieure wissen genau, wenn der Test erfolgreich beendet ist. (mc)

Bild04__tm_09.jpg
Bild 4. Timing-Diagramm für eine Zentralverriegelung

Autor:

Thomas Heurung ist Business Development Manager bei Mentor Graphics

Mentor Graphics
Telefon 089 /57 09 60
www.mentor.com/germany

Verwandte Artikel:

In Bezug auf den Test heißt das, dass es nicht ausreicht, festzustellen, ob die gewünschte Funktion für sich betrachtet rechtzeitig ausgeführt wird. Es ist vielmehr zu prüfen, ob unerwünschte Interaktionen zu kritischen Verzögerungen führen können – was eine größere Herausforderung ist, wie Bild 2 zeigt. Generell werden n Funktionen auf verschiedene Komponenten verteilt, sodass ein Datenaustausch über das Netzwerk nötig ist. Ein geprüftes Konzept erfordert den Test von allen möglichen Interaktionen für diese Funktionen.

Wenn beispielsweise zwei Funktionen F1 und F2 existieren, dann muss auf eine Wechselwirkung zwischen F1 und F2 geprüft werden. Bei drei Funktionen ist bereits die Prüfung der Wechselwirkung zwischen F1 und F2, F1 und F3 sowie F2 und F3 erforderlich. Allgemein nimmt der Testaufwand nichtlinear mit n!/(n-1)! zu. Mit steigender Anzahl von Funktionen mutiert die Netzwerkvalidierung daher meist zu einer Abschätzung der korrekten Funktionsweise, anstatt eine vollständige Überprüfung zu sein.

Bild02__tm_21.jpg
Bild 2. Interaktion der Funktionen

Die korrekte Funktion des Datenverkehrs im Netzwerk erfordert das rechtzeitige Liefern der richtigen Daten. Die Vorgaben des Regelalgorithmus bestimmen die Bedingung »rechtzeitig«. Abhängig von der Natur des Systems kann die entsprechende »Deadline« ein sicherheits- oder qualitätsrelevantes Kriterium sein, was bei einem Sicherheitssystem zu Lebensgefahr oder bei einem Komfortsystem zu signifikanten Mängeln führen kann.

Da viele Systeme die Daten zwar rechtzeitig aber nicht gleichzeitig erfordern, werde im Folgenden nur die Latenzzeit betrachtet. Bild 3 zeigt eine typische Verteilung von Latenzen, beginnend mit den kürzest möglichen bis hin zur längsten. Je höher die Anzahl der Messungen ist, desto mehr nähert man sich dem Worst- Case-Fall. Bedingt durch statistische Effekte kann die tatsächlich längste Latenzzeit größer sein als die gemessene. Daher ist ein zusätzlicher Sicherheitspuffer erforderlich. Ist dieser Puffer zu klein ausgelegt, kann dies zu verspäteten, also unbrauchbaren Nachrichten führen. Ist der Puffer zu groß, ist das Design ineffizient. Um also ein Netzwerk bezüglich Ressourcen und Performance zu optimieren, ist ein vertieftes Verständnis für das Timing erforderlich.

Bild03__tm_20.jpg
Bild 3. Gemessenes und tatsächliches Worst-Case-Timing

  1. Fahrzeugnetze – Entwickeln oder Testen
  2. Fahrzeugnetze – Entwickeln oder Testen
  3. Modelliertes Timing

Jetzt kostenfreie Newsletter bestellen!