Echtzeit-Fähigkeit im verteilten Regler-Entwurf – Teil 1

Potential von FlexRay optimal nutzen

16. Dezember 2008, 13:52 Uhr | Dr. Kai Richter
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 4

Potential von FlexRay optimal nutzen

Mit der Einführung von verteilten Funktionen muss der OEM heute zunächst die Gesamtfunktion modularisieren und auf mehrere ECUs verteilen, bevor er Aufträge an ECU- und Software-Zulieferer vergibt. Eine zusätzliche technische Herausforderung besteht darin, dass das System während der Entwicklung nicht mehr „als Ganzes“ testbar ist, denn jeder Partner implementiert nur einen Teil des Systems. Das korrekte Zusammenspiel erst beim Integrationstest zu prüfen, ist offensichtlich zu spät, da Korrekturen hohe Kosten verursachen und ggf. sogar Entwicklungszeitpläne gefährden. Daraus ergibt sich eine Reihe neuer Fragen:

  • Wie kann man das Timing von Software- und Hardware-Subsystemen gezielt vorhersagen und verifizieren?
  • Wie können die geforderten Frequenzen und die Gesamtverzögerung in lokale Anforderungen für jede Komponente im Netzverbund bestimmt werden?
  • Wer verantwortet welchen Teil der Gesamtverzögerung? OEM, Tier 1, BSW & OS-Konfigurator?
  • Wie kommuniziert man dies zwischen den beteiligten Partnern möglichst „schmerz-frei“ im Rahmen bestehender Prozesse?
  • Wie kann man das Zeitverhalten des Gesamtsystems optimieren?

Die Beantwortung dieser (und weiterer) Fragen erfordert zunächst ein Verständnis des Zeitverhaltens verteilter Systeme und dann einen systematischen Umgang damit. Bild 3 zeigt den Signalfluss des Beispielsystems, diesmal unter Einbeziehung der Software-Architektur bei Verteilung auf drei ECUs.

Die Abbildung orientiert sich am AUTOSAR-Standard, die Effekte existieren jedoch in vergleichbarer Form auch heute schon in nahezu allen verteilten Systemen. Im Idealfall durchlaufen alle Signale von der Sensor-Hardware alle Komponenten immer in derselben zeitlichen Folge, analog einem Fließband. D.h., alle Stufen haben dieselbe Frequenz und sind perfekt synchronisiert, so dass die zweite Stufe genau dann beginnt, wenn die erste Stufe fertig mit der Berechnung ist usw.

In heutigen „zeitgesteuerten Systemen“ bedient man sich dazu gerne einer Taktung. In der Realität ist das Timing jedoch komplizierter, insbesondere durch die Einflüsse der Plattform bestehend aus Basis-Software, Bus-Kommunikation und Betriebssystem. Das hat mehrere Ursachen.

89ah0703_04.jpg
Bild 3. Die Software-Architektur eines verteilten Systems: Sensor, Aktor und Regler sind auf drei über FlexRay verbundene ECUs verteilt. Jedes neue Signal vom Sensor durchläuft die Komponenten: I/O – RTE – SWC – RTE – COM – FlexRay – COM – RTE usw.

  1. Potential von FlexRay optimal nutzen
  2. Zukünftige FlexRay-Systeme
  3. Konstanter Strom und konstante Spannung für die LED
  4. Über- und Unterabtastung
  5. Potential von FlexRay optimal nutzen

Jetzt kostenfreie Newsletter bestellen!