Zu den gängigsten Argumenten für den Umstieg von CAN auf FlexRay gehören höhere Bandbreite, Ausfallsicherheit sowie deterministisches Timing. Im ersten Teil des Artikels [1] wurde gezeigt, dass auch bei FlexRay unerwünschte zeitliche Effekte auftreten, welche...
Teil 2: Analyse und Optimierung der Echtzeit-Fähigkeit von verteilten FlexRay-Systemen
Zu den gängigsten Argumenten für den Umstieg von CAN auf FlexRay gehören höhere Bandbreite, Ausfallsicherheit sowie deterministisches Timing. Im ersten Teil des Artikels [1] wurde gezeigt, dass auch bei FlexRay unerwünschte zeitliche Effekte auftreten, welche die Echtzeit-Fähigkeit beeinflussen, insbesondere Frequenzumsetzungen, Verzögerungen und ECU-seitiger Signal-Jitter.
In diesem Beitrag wird gezeigt, wie man diese zeitlichen Effekte im Gesamtsystem mittels Timing- und Scheduling-Analysen sichtbar machen und gezielt optimieren kann. Dies gibt System-Architekten die notwendige Kontrolle, um die Vorteile FlexRay-basierter Architekturen systematisch zu bewerten, das Echtzeit-Potential optimal zu nutzen und präzise Timing-Anforderungen an die ECU-Zulieferer zu spezifizieren. Und auch die ECUAnbieter profitieren durch die Möglichkeit, das ECU-Timing frühzeitig gegen die OEM-Anforderungen abzusichern.
Timing-Fehler sind heute für eine steigende Zahl von Integrationsproblemen verantwortlich. OEMs und Tier-1-Zulieferer benötigen neue Ansätze für die Analyse, Absicherung und Optimierung der Echtzeit-Fähigkeit. Dies ist mit traditionellen Tests kaum zuverlässig möglich, weil man den Signalen in den Tests die relevanten Echtzeit-Eigenschaften, z.B. ihr Alter, nicht ansehen kann. Vielmehr äußern sich zu alte Daten in einer Reduzierung der Reglerqualiät, die möglicherweise vom Fahrer als Qualitätseinbuße bemerkt wird, etwa wenn das ESP zu ruckeln beginnt. Schlimmstenfalls schaltet sich ein elektronisches System ab. Die Testergebnisse geben aber keinen Aufschluss über die Ursache und helfen daher kaum beim Debugging von Timing-Fehlern.
Zudem werden die Komponenten vernetzter Systeme heute meist zugeliefert. Das integrierte Gesamtsystem ist daher während der Entwicklung nicht als Ganzes testbar. Das korrekte Zusammenspiel aber erst beim Integrationstest zu prüfen, ist zu spät, da Korrekturen hohe Kosten verursachen oder sogar Entwicklungszeitpläne gefährden. An dieser Stelle helfen Timing-Modelle des Systems.