DE60301767T2

DE60301767T2 - Normalisierung eines Verifizierungsmasses in einer Vorrichtung zur Sprecherverifikation

Info

Publication number: DE60301767T2
Application number: DE60301767T
Authority: DE
Inventors: Delphine Charlet
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2002-07-22
Filing date: 2003-07-10
Publication date: 2006-06-29
Also published as: EP1385149B1; US20040107099A1; DE60301767T9; US7409343B2; FR2842643A1; FR2842643B1; EP1385149A1; DE60301767D1; ES2246462T3

Description

Die vorliegende Erfindung betrifft allgemein Kommunikationssysteme auf der Basis eines zeitlich getriggerten Nachrichtenaustauschs mit Maßnahmen zur Fehlereindämmung im Zeitbereich unter Verwendung eines Buswächters für jeden Knoten des Kommunikationssystems.
Die vorliegende Erfindung betrifft insbesondere ein Verfahren zur Überwachung einer Zugriffsablaufssteuerung für ein Kommunikationsmedium einer Kommunikationssteuerung eines Kommunikationssystems mittels eines Buswächters. Das Kommunikationssystem umfaßt ein Kommunikationsmedium und mit dem Kommunikationsmedium verbundene Knoten. Jeder Knoten umfaßt eine Kommunikationssteuerung und einen der Kommunikationssteuerung zugewiesenen Buswächter. Nachrichten werden über das Kommunikationsmedium auf der Basis eines zyklischen zeitlich getriggerten Kommunikationsmedium-Zugriffsschemas zwischen den Knoten übertragen. Natürlich kann ein Knoten weitere Komponenten umfassen, wie zum Beispiel eine Hoststeuerung.
Ferner betrifft die Erfindung ein Computerprogramm, das auf einem Computer, insbesondere einem Mikroprozessor, ausgeführt werden kann.
Weiterhin betrifft die vorliegende Erfindung einen Buswächter, der einer Kommunikationssteuerung von einem einer Anzahl von mit einem Kommunikationsmedium verbundenen Knoten zugewiesen ist. Nachrichten werden zwischen dem Knoten über das Kommunikationsmedium auf der Basis eines zyklischen zeitlich getriggerten Kommunikationsmedium-Zugriffsschemas übertragen. Der eine Knoten umfaßt eine Kommunikationssteuerung und den Buswächter. Der Buswächter besitzt Mittel zum Überwachen der Kommunikationsmedium-Zugriffsablaufsteuerung der Kommunikationssteuerung.
Darüber hinaus betrifft die Erfindung einen Knoten einer Anzahl von mit einem Kommunikationsmedium verbundenen Knoten. Der Knoten umfaßt eine Kommunikationssteuerung und einen der Kommunikationssteuerung zugewiesenen Buswächter. Nachrichten werden über das Kommunikationsmedium zwischen den Knoten auf der Basis eines zyklischen zeitlich getriggerten Kommunikationsmedium-Zugriffsschemas übertragen. Der Buswächter besitzt Mittel zum Überwachen der Kommunikationsmedium-Zugriffsablaufssteuerung der Kommunikationssteuerung.
Schließlich betrifft die vorliegende Erfindung ein Kommunikationssystem, das ein Kommunikationsmedium und mit dem Kommunikationsmedium verbundene Knoten umfaßt. Nachrichten werden über das Kommunikationsmedium zwischen den Knoten auf der Basis eines zyklischen zeitlich getriggerten Kommunikationsmedium-Zugriffsschemas übertragen. Jeder Knoten umfaßt eine Kommunikationssteuerung und einen der Kommunikationssteuerung zugewiesenen Buswächter. Der Buswächter überwacht die Kommunikationsmedium-Zugriffsablaufssteuerung der Kommunikationssteuerung.
Bei zeitlich getriggerten Kommunikationssystemen, die zum Nachrichtenaustausch in Sicherheitskritischen Anwendungen in Fahrzeugen verwendet werden können, ist eine Situation, in der einer der Knoten aufgrund einer lokalen Fehlfunktion die Kommunikation zwischen den Knoten des Kommunikationssystems vorübergehend oder permanent behindert (der sogenannte „Babbling Idiot") nicht tolerierbar. Die Funktion eines Buswächters ist in der Technik aus Kommunikationssystemen bekannt, die für X-by-wire-Anwendungen vorgeschlagen wurden, wie zum Beispiel einem FlexRay-Kommunikationssystem.
Für solche zeitlich getriggerte Kommunikationssysteme wird ein Buswächter vorgeschlagen, um zu vermeiden, daß eine Kommunikationssteuerung eines der Knoten des Kommunikationssystems kontinuierlich Daten sendet und dadurch das Kommunikationsmedium blockiert, so daß keine andere Kommunikationssteuerung eines anderen Knotens Daten senden kann (der sogenannte Ausfall des Typs „Babbling Idiot"). Mit Ausnahme der Kommunikationssteuerung stellt der Buswächter eine zweite Quelle für die Erzeugung eines Kommunikationsmedium-Zugriffssteuersignals dar. Der Buswächter leitet aus einer unabhängigen Menge von Konfigurationsdaten ein entsprechendes Steuersignal ab. Der Buswächter ermöglicht Kommunikationsmedium-Zugriff für die Kommunikationssteuerung, der er zugewiesen ist, nur für spezifische Zeitschlitze, in denen der Kommunikationssteuerung erlaubt ist, Daten über das Kommunikationsmedium zu senden. Die Verwendung eines solchen Buswächters in einem Kommunikationssystem ist aus Temple, Christopher: „Avoiding the Babbling-Idiot Failure in a Time-Triggered Communication System", Fault-Tolerant Computing, 1998, Digest of Papers, 28 Annual International Symposium München, Deutschland, 23.–25.6.1998, Los Alamitos, CA, USA, IEEE Comput. Soc., US, 23.6.1998, Seiten 218–227, XP 01 0291298, ISBN 0-8186-8470-4 bekannt.
Der Buswächter wird mit einer Kommunikationsmedium-Zugriffsablaufsteuerung konfiguriert. Mittels dieser Konfigurationsdaten kann der Buswächter den Zugriff auf das Kommunikationsmedium für bestimmte Zeitschlitze freigeben, für die eine Datenübertragung durch die Kommunikationssteuerung, der der Buswächter zugewiesen ist, erwartet wird. Für die übrigen Zeitschlitze wird der Zugriff auf das Kommunikationsmedium gesperrt.
In einem fehlertoleranten Kommunikationssystem werden häufig Verfahren für eine anfängliche Synchronisation eines bestimmten Verfahrens zum Mediumzugriff (zum Beispiel TDMA – Zeitmultiplex-Mehrfachzugriff) implementiert, wobei mehr als ein Knoten des Kommunikationssystems eine anfängliche Synchronisation nach dem Einschalten versuchen kann. In dieser Phase (bei der sogenannten Ablaufsteuerungseinrichtung) wird versucht, alle verfügbaren Knoten dergestalt zu synchronisieren, daß sie auf einem globalen Kommunikationsschema wirken, das definiert, wann die Knoten das Kommunikationsmedium exklusiv belegen können. Wenn diese Synchronisation erfolgreich war, ändert sich das festgelegte Zeitschema für die Knoten nicht mehr. Jeder Knoten arbeitet in dem sogenannten Normalmodus. Nur eine kritische Betriebssituation oder ein absichtliches Herunterfahren der Kommunikation zwischen den Knoten kann zu einem Enden der Kommunikation des Knotens führen. Eine Änderung des Zugriffsverhaltens ist nicht zulässig.
Während einer Herauffahrphase kann es jedoch aus verschiedenen Gründen geschehen, daß eine Kommunikationssteuerung die Ausführung einer Kommunikationsablaufsteuerung unterbricht und sie später wieder aufnimmt. Dieser Vorfall wird im folgenden als Ablaufsteuerungs-Rücksetzen bezeichnet. Im Gegensatz zu dem oben beschriebenen Normalmodus muß der Buswächter diesen Vorfall während einer Ablaufsteuerungseinrichtphase tolerieren. Verursacht durch eine Kollision von zwei oder mehr Knoten, die versuchen, gleichzeitig eine anfängliche Synchronisation aller Knoten zu erzielen, entsteht eine Situation, in der sich alle Knoten bis auf einen nach der Erkennung des Kollisionsszenarios zurückziehen müssen. Der Knoten, der sich nicht zurückziehen muß (übriger Knoten) könnte ein Knoten sein, der zuerst einen regulären Rahmen sendet. Als Alternative könnte er der Knoten sein, der als letzter den regulären Rahmen sendet, oder der einen regulären Rahmen einer bestimmten Länge sendet.
Beim Zurückzug gibt ein Knoten einen Übertragungsprozeß auf der Basis seiner eigenen lokalen Kommunikationszeitablaufsteuerung auf und nimmt die von dem übrigen Knoten vorgeschlagene Zeitablaufsteuerung an. Der chronologische Ort der eigenen Zeitschlitze wird dann auf diese Zeitablaufsteuerung eingestellt. Somit werden die lokalen Kommunikationszeitablaufsteuerungen aller Knoten in eine globale Entsprechung gebracht. Das heißt, daß die Ablaufsteuerungseinrichtung abgeschlossen ist und die Kommunikationssteuerungen in Bezug auf ihr Medium-Zugriffsverhalten synchronisiert sind.
Obwohl das Medium-Zugriffsmuster während des Normalbetriebs des Kommunikationssystems eine zyklische, sich wiederholende Struktur aufweist, muß das lokale Kommunikationssystem während einer Herauffahrphase daher die anfängliche Herstellung einer globalen Zugriffsablaufsteuerung, zum Beispiel auf der Basis von TDMA (Zeitmultiplex-Mehrfachzugriff), die für alle Knoten des verteilten Kommunikationssystems gültig ist, unterstützen. Das Herauffahren der Kommunikation in dem verteilten System, wobei mehr als einem Knoten erlaubt wird, die anfängliche Ablaufsteuerungssynchronisation durchzuführen, erfordert, daß ein Knoten möglicherweise seine eigene Zugriffsablaufsteuerung an einen anderen der Knoten anpassen muß, obwohl er bereits versucht hat, die Kommunikation aktiv heraufzufahren. Dies wird zum Beispiel durch ein Ablaufsteuerungs-Rücksetzen (SR) bewirkt, das von dem Knoten eingeleitet wird, der seine Zugriffsablaufsteuerung an einen anderen Knoten anpassen muß. Diese Situation während des Herauffahrens der Kommunikation kann zu zulässigen Abweichungen (zum Beispiel Ablaufsteuerungs-Rücksetzen RS) von der gewöhnlichen Kommunikationsmedium-Zugriffsablaufsteuerung führen.
Damit die Kommunikationssteuerung Tasks wie zum Beispiel das Senden von Triggersignalen (ARM) usw. durchführen kann, muß sie funktionsfähig sein. Anders ausgedrückt, ist die Kommunikationssteuerung bereits heraufgefahren, wenn die Kommunikation über das Kommunikationssystem hinweg heraufgefahren wird.
Dasselbe gilt für den Buswächter, der auch bereits gestartet ist (eingeschaltet ist und interne Logik ausführt). Beide Einrichtungen kooperieren einfach nur noch nicht zur Kommunikation auf dem Kanal. Die vorliegende Erfindung behandelt nun, wie die Kommunikationssteuerung und der Buswächter miteinander in Interaktion treten, um die Kommunikation zu starten.
Für einen Buswächter, der Fehlereindämmung im Zeitbereich für den jeweiligen Knoten sicherstellen soll, realisiert dieses Szenario eine fundamentale Schwierigkeit – zwischen zulässigen Änderungen der Kommunikationsmedium-Zugriffsablaufsteuerung der Kommunikationssteuerung, die durch das Herauffahrverhalten in Entsprechung mit der Spezifikation verursacht werden, und verbotenen Änderungen, die durch ein Versagen der Kommunikationssteuerung verursacht werden, das dann als solches erkannt werden muß, zu unterscheiden.
Eine Möglichkeit zur Unterscheidung zwischen einer zulässigen und einer verbotenen Abweichung von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens ist ein explizites Signalisieren des aktuellen Status der Kommunikationssteuerung, das heißt zum Beispiel eines Herauffahrmodus oder eines Normalmodus. Das Problem bei expliziter Signalisierung besteht darin, daß die Kommunikationssteuerung dem Buswächter wann sie will ein Ablaufsteuerungs-Rücksetzen anzeigen kann. Dies ermöglicht Fehlerszenarien, bei denen eine Kommunikationssteuerung das Kommunikationsmedium kontinuierlich durch periodisches Signalisieren von Ablaufsteuerungs-Rücksetzungen für den Buswächter blockiert. Dies soll der Buswächter jedoch gerade verhindern.
Um die Unabhängigkeit des Buswächters nicht zu gefährden, gibt es verschiedene Ansätze, die nicht die direkte Schnittstelle zwischen der Kommunikations steuerung und dem Buswächter benutzen. In solchen Fällen signalisiert die Kommunikationssteuerung einer Verarbeitungseinheit auf höherer Ebene, die zum Beispiel eine Hoststeuerung ist, ein Ablaufsteuerungs-Rücksetzen. Die Verarbeitungseinheit ist gewöhnlich Teil des Knotens und stellt die tatsächliche Funktionsfähigkeit des verteilten Steuersystems einschließlich der Kommunikationsfähigkeit und der Fahrzeugsteuerfunktionalität sicher. Die Verarbeitungseinheit der höheren Ebene kann ein angegebenes Ablaufsteuerungs-Rücksetzen validieren und es über eine unabhängige Schnittstelle zu dem Buswächter weiterleiten.
Das Problem besteht darin, daß es bei der Verarbeitungseinheit der höheren Ebene eine Entität in dem kritischen Weg gibt, die nichts mit der Ausführung der Prozedur des Knotens zu tun hat. Eine Funktionalität des Knotens wird an eine Entität höherer Ebene abgegeben, die die Datenübertragungsfähigkeiten des Knotens nur zur Realisierung der Funktionalität des verteilten Steuersystems benutzen möchte. Das heißt, daß entsprechende Anforderungen bezüglich Verarbeitungsgeschwindigkeit und Reaktionszeit auch durch die Verarbeitungseinheit erreicht werden müssen, was gewöhnlich nicht der Fall ist. In der Anwendungssoftware in der Verarbeitungseinheit müssen spezielle Routinen vorgesehen werden, die eine garantierte Latenz für die Erkennung, Verarbeitung und Weiterleitung eines Ereignisses, das heißt das Ablaufsteuerungs-Rücksetzen, anbieten. Somit kann ein Knoten des Kommunikationssystems nicht als geschlossene Entität betrachtet werden und es ist deshalb schwierig, Konformität zu bescheinigen und zu prüfen.
Die Signalisierung des aktuellen Status oder eines expliziten Rücksetzbefehls von der Kommunikationssteuerung zu dem Buswächter würde deshalb gegen die Anforderung eines unabhängigen Betriebs der Kommunikationssteuerung und des Buswächters verstoßen. Ein unabhängiger Betrieb dieser beiden Entitäten ist wichtig, um ihre Empfindlichkeit gegenüber sogenannten Gleichtaktfehlern zu verringern.
Die Realisierung einer separaten Empfangsschaltung, die das Empfangen, Decodieren und Interpretieren der von der Kommunikationssteuerung übertragenen Nachrichten ermöglicht, wäre viel zu komplex und zu kostspielig.
Der Buswächter kann eine unabhängige Beobachtung der Kommunikationssteuerung, der er zugewiesen ist, nur dann sicherstellen, wenn die Kommunikationssteuerung sich an ein definitives Zugriffsschema hält. Ein Problem entsteht, wenn das Zugriffsverhalten der Kommunikationssteuerung, das durch den Buswächter überwacht werden soll, sich entsprechend dem Zugriffsschema ändert, und wenn eine solche zulässige Änderung von einer durch eine defekte Kommunikationssteuerung verursachten fehlerhaften Änderung unterschieden werden soll.
Eine Aufgabe der vorliegenden Erfindung ist deshalb die Bereitstellung eines Mechanismus, der es dem Buswächter ermöglicht, das Kommunikationsmedium-Zugriffsschema der Kommunikationssteuerung auch während des Herauffahrens der Kommunikation zu überwachen.
Diese Aufgabe wird gelöst durch ein Verfahren der oben erwähnten Art, das dadurch gekennzeichnet ist, daß der Buswächter a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens der Kommunikation besitzt, und daß der Buswächter während des Herauffahrens der Kommunikation das a-priori-Wissen ausnutzt, um zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung verursacht wird, zu unterscheiden.
Die Erfindung präsentiert einen Ansatz, der die Unabhängigkeit des Buswächters von einer affiliierten Kommunikationssteuerung aufrechterhält. Es wird ein Mechanismus vorgeschlagen, der das potentielle Verhalten der Kommunikationssteuerung während des Netzwerkherauffahrens auf vereinfachte Bedingungen kondensiert, die durch den Buswächter geprüft werden können, indem er das Medium-Zugriffsschema der Kommunikationssteuerung beobachtet. Dadurch kann der Buswächter die Rücksetzbedingungen für seine eigene Zugriffsfreigabeablaufsteuerung unabhängig ableiten.
Der vorgeschlagene Mechanismus spart zusätzliche Schnittstellensignale durch Ausnutzen des Informationsflusses, der sowieso bereitgestellt werden muß, und löst das Problem der lokalen Ablaufsteuerungssynchronisation ohne Schwächung der Unabhängigkeit des Buswächters.
Gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung wird vorgeschlagen, daß zulässige Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens der Kommunikation durch Rücksetzinformationen und durch das chronologische Auftreten der Rücksetzinformationen repräsentiert werden, und daß der Buswächter die Rücksetzinformationen und das chronologische Auftreten der Rücksetzinformationen während des Herauffahrens der Kommunikation überwacht. Insbesondere sind die Rücksetzinformationen ein Ablaufsteuerungs-Rücksetzen. Das chronologische Auftreten der Rücksetzinformationen bezieht sich auf den Zeitpunkt bzw. Zyklus, an dem die Ablaufsteuerungsinformationen während des Kommunikationsmedium-Zugriffsschemas auftreten.
Gemäß einer weiteren Ausführungsform der Erfindung wird vorgeschlagen, daß während des Herauffahrens der Kommunikation eine Kommunikationssteuerung von einem der Knoten ein erstes Triggersignal zu dem Buswächter sendet, der der Kommunikationssteuerung zugewiesen ist. Der Buswächter definiert abhängig von den a-priori-Informationen mindestens ein Erwartungsfenster. Ferner überwacht der Buswächter, ob weitere Triggersignale in den definierten Erwartungsfenstern vorliegen. Als letztes unterscheidet der Buswächter zwischen einer zulässigen Abweichung und einer verbotenen Abweichung abhängig davon, ob weitere Triggersignale in den definierten Erwartungsfenstern vorliegen, und abhängig von den a-priori-Informationen. Zum Beispiel ist in einem FlexRay-Kommunikationssystem das erste Triggersignal ein sogenanntes ARM-Signal. Das ARM-Signal dient zum Synchronisieren des Buswächters und der Kommunikationssteuerung. Ein Erwartungsfenster wird durch seinen Zeitpunkt oder Zyklus des Erscheinens und/oder seine Größe definiert. Ein Erwartungsfenster ist eine bestimmte Zeit oder ein Zykluszeitraum, worin der Buswächter das Medium-Zugriffsverhalten der Kommunikationssteuerung überwacht.
Ferner wird vorgeschlagen, daß das erste Triggersignal am Anfang eines Zeitschlitzes in einem Zyklus des Kommunikationsmedium-Zugriffschemas gesendet wird und daß am Ende des besagten Zeitschlitzes in dem Zyklus ein erstes Erwartungsfenster definiert wird. Vorzugsweise definiert ein weiteres Triggersignal in dem weiteren Erwartungsfenster den Anfang eines neuen Zyklus des Kommunikationsmedium-Zugriffschemas. Wenn das Triggersignal das erste Triggersignal ist, das die Kommunikationssteuerung nach dem Herauffahren sendet, erlaubt es der Buswächter sofort der Kommunikationssteuerung, während des aktuellen Zeitschlitzes auf das Kommunikationsmedium zuzugreifen. Die Zugriffsgenehmigung wird mittels eines Freigabesignals (BGEN; Buswächterfreigabe) gewährt, das der Buswächter zu der Kommunikationssteuerung oder zu einem Bustreiber sendet, der zwischen die Kommunikationssteuerung und das Kommunikationsmedium geschaltet ist. während des Zeitschlitzes sendet die Kommunikationssteuerung eine vordefinierte Nachricht (CAS; Kollisionsvermeidungssymbol), wodurch der Buswächter informiert wird, daß die Kommunikationssteuerung dabei ist, eine anfängliche Synchronisation nach dem Einschalten zu versuchen (das sogenannte ColdStart-Verhalten). Am Ende dieses Zeitschlitzes wird ein weiteres Triggersignal zu dem Buswächter gesendet und ein neuer Zyklus beginnt. Wenn dagegen während des ersten Erwartungsfensters kein weiteres Triggersignal gesendet wurde, befände sich die Kommunikationssteuerung nicht in einer ColdStart-Phase, sondern statt dessen in einer sogenannten Integrating-Phase. In einer Integrating-Phase nimmt die Kommunikationssteuerung die Zeitablaufsteuerung an, die durch einen Knoten vorgeschlagen wird, der bereits ein erfolgreiches ColdStart durchgeführt hat. Das heißt, daß sowohl das Senden als auch das Nichtsenden eines Triggersignals während des ersten Erwartungsfensters erlaubt ist. Der Buswächter weiß, daß dies weder wenn ein Triggersignal in dem Erwartungsfenster gesendet wurde noch wenn es nicht gesendet wurde ein Ablaufsteuerungs-Rücksetzen einleitet.
Gemäß einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung wird vorgeschlagen, daß am Anfang nachfolgender Zyklen des Kommunikationsmedium-Zugriffsschemas jeweils eine Anzahl weiterer Erwartungsfenster definiert wird. Die Anzahl weiterer Erwartungsfenster wird vorzugsweise abhängig von den a-priori-Daten definiert, insbesondere abhängig von einem Parameter, der die maximale Anzahl von Zyklen definiert, für die die Kommunikationssteuerung versuchen darf, aktiv die Kommunikation mit einer weiteren Kommunikationssteuerung eines der anderen Knoten des Kommunikationssystems herzustellen. Diese bevorzugte Ausführungsform gilt für die ColdStart-Phase der Kommunikationssteuerung. Gemäß dieser Ausführungsform erkennt für eine bestimmte Anzahl von Zyklen abhängig von dem Wert des Parameters der Buswächter einen Gültig-Zustand der Kommunikationssteuerung gleichgültig, ob weitere Triggersignale in den weiteren Erwartungsfenstern gesendet werden oder nicht. Wenn kein weiteres Triggersignal in einem der weiteren Erwartungsfenster gesendet wird, wird ein gültiges Ablaufsteuerungs-Rücksetzen bewirkt. Wenn dagegen außerhalb der Anzahl weiterer Erwartungsfenster kein weiteres Triggersignal gesendet wird, wird ein Ungültig-Zustand der Kommunikationssteuerung erkannt und der Kommunikationsmedium-Zugriff wird für einen bestimmten Zeitraum gesperrt, oder bis das Kommunikationssystem heruntergefahren wird.
Es wird vorgeschlagen, daß es für eine zulässige Abweichung von der Kommunikationsmedium-Zugriffsablaufsteuerung weitere Triggersignale in den Erwartungsfenstern geben kann oder nicht. Ferner wird vorgeschlagen, daß für ein gültiges Ablaufsteuerungs-Rücksetzen keine weiteren Triggersignale in den weiteren Erwartungsfenstern vorliegen. Als letztes wird vorgeschlagen, daß für eine verbotene Abweichung von der Kommunikationsmedium-Zugriffsablaufsteuerung keine weiteren Triggersignale außerhalb der Erwartungsfenster vorliegen.
Weiterhin wird die oben erwähnte Aufgabe durch ein Computerprogramm der oben erwähnten Art gelöst, dadurch gekennzeichnet, daß das Computerprogramm programmiert ist, um ein Verfahren gemäß der vorliegenden Erfindung auszuführen.
Gemäß einer bevorzugten Ausführungsform wird vorgeschlagen, daß das Computerprogramm auf einem Nurlesespeicher (ROM), auf einem Direktzugriffsspeicher (RAM) oder auf einem Flash-Speicher (Flash) gespeichert wird.
Darüber hinaus wird die oben erwähnte Aufgabe durch einen Buswächter der oben erwähnten Art gelöst, dadurch gekennzeichnet, daß der Buswächter a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens der Kommunikation besitzt und daß der Buswächter Mittel zum Ausnutzen des a-priori-Wissens besitzt, um während des Herauffahrens zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung verursacht wird, zu unterscheiden.
Gemäß einer bevorzugten Ausführungsform wird vorgeschlagen, daß der Buswächter Mittel zum Ausführen des Verfahrens gemäß der vorliegenden Erfindung umfaßt.
Außerdem wird die oben erwähnte Aufgabe durch einen Knoten der oben erwähnten Art gelöst, dadurch gekennzeichnet, daß der Buswächter a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens der Kommunikation besitzt und daß der Buswächter Mittel zum Ausnutzen des a-priori-Wissens besitzt, um während des Herauffahrens zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung verursacht wird, zu unterscheiden.
Gemäß einer bevorzugten Ausführungsform wird vorgeschlagen, daß der Buswächter Mittel zum Ausführen des Verfahrens gemäß der vorliegenden Erfindung umfaßt.
Schließlich wird die oben erwähnte Aufgabe durch ein Kommunikationssystem der oben erwähnten Art gelöst, dadurch gekennzeichnet, daß der Buswächter a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens der Kommunikation besitzt und daß der Buswächter Mittel zum Ausnutzen des a-priori-Wissens besitzt, um während des Herauffahrens der Kommunikation zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung verursacht wird, zu unterscheiden.
Gemäß einer bevorzugten Ausführungsform wird vorgeschlagen, daß das a-priori-Wissen Rücksetzinformationen und das chronologische Auftreten der Rücksetzinformationen während des Herauffahrens der Kommunikation umfaßt und daß die Mittel zum Ausnutzen des a-priori-Wissens die Rücksetzinformationen und das chronologische Auftreten der Rücksetzinformationen während des Herauffahrens der Kommunikation überwachen, um zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung verursacht wird, zu unterscheiden.
Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung wird vorgeschlagen, daß der Buswächter Mittel zum Ausführen des Verfahrens gemäß der vorliegenden Erfindung umfaßt.
Diese und weitere Merkmale, Aspekte und Vorteile der vorliegenden Erfindung werden bei Durchsicht der folgenden ausführlichen Beschreibung, der angefügten Ansprüche und der beigefügten Zeichnungen besser verständlich. Es zeigen:
1 ein Kommunikationssystem gemäß der vorliegenden Erfindung mit einer Doppelkanal-Buskonfiguration;
2 ein Kommunikationssystem gemäß der vorliegenden Erfindung mit einer Doppelkanal-Einzelsternkonfiguration;
3 ein Kommunikationssystem gemäß der vorliegenden Erfindung mit einer kaskadierten Einkanal-Sternkonfiguration;
4 ein Kommunikationssystem gemäß der vorliegenden Erfindung mit einer kaskadierten Doppelkanal-Sternekonfiguration;
5 ein Kommunikationssystem gemäß der vorliegenden Erfindung mit einer Einkanal-Hybridkonfiguration;
6 ein Kommunikationssystem gemäß der vorliegenden Erfindung mit einer Doppelkanal-Hybridkonfiguration;
7 Zeitsteuerungshierarchieebenen in einem Kommunikationszyklus für die Datenübertragung in dem Kommunikationssystem;
8 einen zeitbasisgetriggerten Kommunikationszyklus für die Datenübertragung in dem Kommunikationssystem;
9 mögliche Übertragungsmuster für einen einzelnen Knoten in einem statischen Segment des Kommunikationszyklus;
10 die ausführliche Zeitsteuerung eines statischen Schlitzes in dem statischen Segment eines Kommunikationszyklus;
11 eine Übersicht über ein dynamisches Segment eines Kommunikationszyklus;
12 eine ausführliche Zeitsteuerung in einem Minischlitz eines Kommunikationszyklus;
13 eine ausführliche Zeitsteuerung in einem dynamischen Segment eines Kommunikationszyklus;
14 eine ausführliche Zeitsteuerung an der Grenze zwischen einem statischen Segment und einem dynamischen Segment eines Kommunikationszyklus;
15 eine ausführliche Zeitsteuerung in einem Symbolfenster eines Kommunikationszyklus;
16 eine Absender-/Empfängerschnittstelle einer Kommunikationssteuerung eines Knotens des Kommunikationssystems;
17 eine Bytecodierung;
18 eine Rahmencodierung in einem statischen Segment eines Kommunikationszyklus;
19 eine Rahmencodierung in einem dynamischen Segment eines Kommunikationszyklus;
20 einen Bitstrom eines Statusnormalsymbols (SNS);
21 einen Bitstrom eines Statusalarmsymbols (SAS);
22 einen Bitstrom eines Kollisionsvermeidungssymbols (CAS);
23 einen Bitstrom einer Sequenz zweier Wecksymbole (WUS);
24 ein Blockschaltbild einer Bitstromdecodierungseinheit eines Knotens des Kommunikationssystems;
25 einen Mechanismus zur Bestimmung eines Anfangsflankendetektionsfensters, wenn ein Rahmen empfangen wird;
26 einen Mechanismus zum Erkennen einer fallenden Flanke in der Mitte einer ersten Bytestartsequenz (BSS);
27 einen Mechanismus zur Bestimmung eines Flankendetektionsfensters;
28 eine Bittaktsynchronisation in einem ersten Beispiel;
29 eine Bittaktsynchronisation in einem zweiten Beispiel;
30 eine Bittaktsynchronisation in einem dritten Beispiel;
31 ein Beispiel für eine Bitabtastung für Bit, die zehn Abtastwerte umfassen;
32 einen Mechanismus zur Neusynchronisation der Bitabtastung;
33 ein Beispiel für einen Bitwert-Wählmechanismus;
34 eine Übersicht über ein FlexRay-Rahmenformat;
35 eine Übersicht über ein byteflight-Rahmenformat;
36 ein Rahmenempfangs-Zustandsdiagramm;
37 eine Rahmenannahmezeitsteuerung in einem statischen Segment eines Kommunikationszyklus;
38 eine Rahmenannahmezeitsteuerung in einem dynamischen Segment eines Kommunikationszyklus;
39 ein Diagramm mit einer lokalen Zeitsteuerung dreier Knoten und ihrer Beziehung zueinander;
40 eine relative Ausführungszeitsteuerung eines Taktsynchronisationsmechanismus;
41 eine Knoteninterne Ausführung von Taktsynchronisationsprozeduren;
42 eine Zeitdifferenzmessung (erwartete Ankunftszeiten im Vergleich zu beobachteten Ankunftszeiten);
43 einen Algorithmus zur Taktkorrekturwertberechnung;
44 eine Zeitsteuerung der Messung und Korrektur;
45 eine Bewertung eines berechneten Ratenkorrekturwerts;
46 eine Bewertung eines berechneten Offsetkorrekturwerts;
47 eine globale Struktur einer Weckprozedur;
48 eine Struktur einer Weckkanalüberwachungsprozedur;
49 eine Struktur einer Weckmusterübertragungsprozedur;
50 eine globale Struktur einer Herauffahrprozedur;
51 eine Struktur einer Kanalüberwachung und einer Auswahl eines Herauffahrweges;
52 eine Struktur einer Auswahl eines Kaltstartinitiators;
53 eine Struktur einer Überprüfung einer erfolgreich hergestellten Kommunikation;
54 eine Struktur einer anfänglichen Synchronisation;
55 eine Struktur einer Überprüfung einer erfolgreichen Integration;
56 eine globale Struktur eines Protokollzustandsdiagramms;
57 eine Struktur eines Kommunikationssteuerungs-Weckautomaten eines Knotens eines Kommunikationssystems;
58 ein einfaches Wecken, während die größeren Zeiträume in einem Millisekundenbereich durch gestrichelte Linien dargestellt sind;
59 ein einfaches Wecken mit Weiterleitung, während die größeren Zeiträume in einem Millisekundenbereich durch gestrichelte Linien dargestellt sind;
60 eine Listen-Zeitgrenze eines ersten Timerwerts vdStartup;
61 Listen-Zeitgrenzen eines zweiten Timerwerts vdStartupNoise;
62 ein Herauffahrzustandsdiagramm in einem Zeittriggerprotokollmodus;
63 ein Herauffahrzustandsdiagramm in einem byteflight-Protokollmodus;
64 ein Diagramm eines kollisionsfreien Herauffahrens;
65 ein Diagramm eines Herauffahrens mit einer Kollision an einem Kollisionsvermeidungssymbol;
66 ein Diagramm eines Herauffahrens mit einer Validierungsprüfung in einem CC_IntegrationVCW-Zustandsausfall, wobei in diesem Zustand ein Knoten des Kommunikationssystems keine Übertragungen ablaufsteuert;
67 ein Zustandsübergangsdiagramm einer Kommunikationssteuerung eines Knotens des Kommunikationssystems;
68 ein Zustandsübergangsdiagramm eines Bustreibers eines Knotens des Kommunikationssystems (die Zustände des optischen Buswächters sind nicht gezeigt);
69 ein Zustandsübergangsdiagramm eines optischen Bustreibers eines Knotens des Kommunikationssystems;
70 ein Zustandsübergangsdiagramm eines Buswächters eines Knotens eines Kommunikationssystems;
71 ein Zustandsübergangsdiagramm einer Aktiv-Sternkommunikationssystemtopologie;
72 ein Fehlermanagement-Zustandsübergangsdiagramm für einen verteilten Zeittrigger- Protokollmodus und einen Master-gesteuerten Zeittrigger-Protokollmodus;
73 ein Fehlermanagement-Zustandsübergangsdiagramm für einen byteflight-Protokollmodus;
74 eine konzeptuelle Architektur einer Steuerungs-Hostschnittstelle eines Knotens des Kommunikationssystems;
75 ein Zustandsdiagramm einer Steuerungs-Hostschnittstelle;
76 Interaktionen von Steuerungs-Hostschnittstellendiensten mit Steuerungs-Hostschnittstellenelementen;
77 eine Schnittstelle von Bustreiber/Kommunikationssteuerung eines Knotens des Kommunikationssystems;
78 eine Schnittstelle von Bustreiber/Buswächter;
79 das Verhalten zweier Signale RxD und RxEN zum Empfangen eines Datenrahmens, der in einem statischen Segment des Kommunikationszyklus gesendet wird, gemäß einem ersten Beispiel;
80 das Verhalten zweier Signale RxD und RxEN zum Empfangen eines Datenrahmens gemäß einem zweiten Beispiel;
81 die erforderliche Zeitsteuerung zweier Signale TxD und TxEN zum Übertragen eines Datenrahmens;
82 ein Blockschaltbild einer Schnittstelle von Buswächter/Kommunikationssteuerung;
83 eine Übersicht über die Buswächterablaufsteuerung;
84 eine Zeitsteuerung von Buswächter/Kommunikationssteuerung während eines statischen Segments eines Kommunikationszyklus;
85 eine Zeitsteuerung von Buswächter/Kommunikationssteuerung am Anfang eines dynamischen Segments eines Kommunikationszyklus gemäß einem ersten Beispiel;
86 eine Zeitsteuerung von Buswächter/Kommunikationssteuerung am Anfang eines dynamischen Segments eines Kommunikationszyklus gemäß einem zweiten Beispiel;
87 eine Zeitsteuerung von Buswächter/Kommunikationssteuerung während eines Buswächtersymbolfensters und einer Buswächter-Watchdog-Sperrzeit;
88 eine Struktur einer Buswächter-Ablaufsteuerungs-Überwachungsvorrichtung;
89 einen Buswächter-Ablaufsteuerungs-Überwachungsautomaten;
90 eine Interaktion in einem statischen Segment eines Kommunikationszyklus;
91 eine Interaktion in einem statischen Segment eines Kommunikationszyklus mit einer minimalen Länge von Lücken zwischen Schlitzen;
92 eine Interaktion in einem dynamischen Segment eines Kommunikationszyklus mit einem gesperrten Symbolfenster;
93 eine Interaktion in einem Symbolfenster und in einer Netzwerk-Leerlaufzeit;
94 Betriebsarten des FlexRay-Kommunikationszyklus;
95 eine Ereignisgetriggerte Kommunikationsabwicklung in einer Hoststeuerung, einer Steuerungs-Hostschnittstelle und in einer Kommunikationssteuerung eines Knotens des Kommunikationssystems;
96 eine Zeitsteuerungshierarchie aus der Sicht eines Master-Knotens des Kommunikationssystems;
97 eine Kommunikationszyklusausführung aus der Sicht eines Master-Knotens und eines Slave-Knotens;
98 eine Triggerbedingung in einem Ereignisanzeigesignal;
99 eine Überwachung eines Triggersignals für die Kommunikationssteuerung durch einen Master-Knoten des Kommunikationssystems;
100 eine Überwachung eines Ereignisanzeigesignals durch Slave-Knoten des Kommunikationssystems;
101 ein Protokollzustandsdiagramm für einen ereignisgetriggerten Modus;
102 interne Busereignisse, die extern angezeigt werden;
103 eine Architektur eines Knotens des Kommunikationssystems;
104 ein Beispiel für eine mögliche Netzwerkkonfiguration;
105 eine Definition eines Kommunikationszyklus mit einem statischen Segment;
106 eine Definition eines Kommunikationsszyklus in einem Reindynamik-Kommunikationssystem;
107 ein Beispiel für ein Kommunikationsschema zweier Knoten eines FlexRay-Kommunikationssystems;
108 ein FlexRay-Rahmenformat;
109 ein byteflight-Rahmenformat;
110 eine Übertragung einer Startsequenz;
111 einen Empfang einer Startsequenz;
112 ein Rahmenformat für eine elektrische Übertragung auf der physischen Schicht;
113 eine Topologie eines FlexRay-Kommunikationssystems mit zwei aktiven Sternen;
114 eine Topologie eines FlexRay-Kommunikationssystems mit einem passiven Bus;
115 eine Topologie eines FlexRay-Kommunikationssystems mit einem aktiven Stern kombiniert mit einem passiven Bus;
116 ein Blockschaltbild eines elektrischen aktiven Sterns;
117 eine Übersicht über Schnittstellen zwischen einer Hoststeuerung, einer Kommunikationssteuerung, einem Bustreiber, einem Buswächter und einer Stromversorgung eines Knotens des Kommunikationssystems;
118 ein Kommunikationssystem gemäß der vorliegenden Erfindung;
119 einen Knoten gemäß der vorliegenden Erfindung, wobei der Knoten Teil des Kommunikationssystems ist;
120 ein Phasendiagramm eines Verfahrens gemäß der vorliegenden Erfindung;
121 einen Verlauf verschiedener Signale in dem Knoten gemäß einer ersten bevorzugten Ausführungsform;
122 einen Verlauf verschiedener Signale in dem Knoten gemäß einer zweiten bevorzugten Ausführungsform;
123 einen Verlauf verschiedener Signale in dem Knoten gemäß einer dritten bevorzugten Ausführungsform;
124 einen Verlauf verschiedener Signale in dem Knoten gemäß einer vierten bevorzugten Ausführungsform;
125 einen Verlauf verschiedener Signale in dem Knoten gemäß einer fünften bevorzugten Ausführungsform;
126 einen Verlauf verschiedener Signale in dem Knoten gemäß einer sechsten bevorzugten Ausführungsform;
127 einen Verlauf verschiedener Signale in dem Knoten gemäß einer siebten bevorzugten Ausführungsform.
118 zeigt ein Kommunikationssystem auf der Basis eines zeitgetriggerten Nachrichtenaustauschs mit der Bezugszahl 1. Das Kommunikationssystem 1 kann ein FlexRay-Kommunikationssystem sein. Das Kommunikationssystem 1 umfaßt ein Kommunikationsmedium 2, das ein Datenbus sein kann. Mit dem Kommunikationsmedium 2 sind mehrere Knoten 3 (A, B, C, D, E) verbunden. Nachrichten werden zwischen den Knoten 3 über das Kommunikationsmedium 2 auf der Basis eines zyklischen Zeittrigger-Kommunikationsmedium-Zugriffsschemas übertragen.
119 zeigt einen Knoten 3 des in 118 dargestellten Kommunikationssystems 1. Jeder Knoten 3 umfaßt eine Hoststeuerung (Host) 4, eine Kommunikationssteuerung (CC) 5, einen Buswächter (BG) 6 und einen Bustreiber (BD) 7. Der Buswächter 6 wird der Kommunikationssteuerung 5 zugewiesen. Der Buswächter 6 überwacht die Kommunikationsmedium-Zugriffsablaufsteuerung der Kommunikationssteuerung 5, um zu verhindern, daß die Kommunikationssteuerung 5 das Kommunikationsmedium 2 blockiert, indem sie vorübergehend oder kontinuierlich Nachrichten sendet (sogenannter „babbling idiot"). Um Unabhängigkeit von den beiden redundanten Kanälen (siehe zum Beispiel 1) aufrechtzuerhalten, können die Knoten (Bezugszeichen 100 in 1) zwei Bustreiber und zwei Buswächter umfassen.
Die vorliegende Erfindung beschreibt einen Ansatz, der die Unabhängigkeit des Buswächters 6 von der affiliierten Kommunikationssteuerung 5 aufrechterhält. Es wird ein Mechanismus vorgeschlagen, der das potentielle Verhalten der Kommunikationssteuerung 5 während des Herauffahrens des Systems 1 bzw. die Kommunikation über das System 1 zu vereinfachten Bedingungen zusammenfaßt, die von dem Buswächter 6 geprüft werden können, indem das Medium-Zugriffsschema der Kommunikation beobachtet wird. Dadurch kann der Buswächter 6 die Rücksetzbedingung für seine eigene Zugriffsfreigabeablaufsteuerung (BGEN) unabhängig ableiten. Der Buswächter 6 verwendet a-priori-Wissen über mögliche Herauffahr-Ablaufsteuerungsabweichungen, um zwischen einer gültigen Divergenz von dem regulären Schema und einer irregulären zu unterscheiden. Der vorgeschlagene Mechanismus spart zusätzliche Schnittstellensignale durch Ausnutzen des Informationsflusses, der sowieso bereitgestellt werden muß, und löst das Problem der lokalen Ablaufsteuerungssynchronisation ohne Schwächung der Unabhängigkeit des Buswächters 6.
Nunmehr mit Bezug auf 120 beginnt das Verfahren gemäß der vorliegenden Erfindung in einem Block 10. Wenn die Bedingung 11 erfüllt ist, tritt die Kommunikationssteuerung 5 in die Initialisierungsphase (Init) 12 ein und das gesamte System 1 befindet sich in einer Herauffahrphase. Zum Beispiel kann die Bedingung 11 erfüllt sein, wenn die Kommunikationssteuerung 5 eingeschaltet wird. Während der Initialisierungsphase 12 beobachtet die Kommunikationssteuerung 5 die Kommunikation auf dem Kommunikationsmedium 2. Wenn die Steuerung 5 eine ablaufende Kommunikation erkennt, versucht sie, ihre eigene lokale Zeitablaufsteuerung an die globale Zeitablaufsteuerung der Knoten 3, die bereits bei dem Kommunikationssystem 1 registriert sind, anzupassen (Integrationsphase; Integr) 13. Wenn die Steuerung 5 jedoch eine ablaufende Kommunikation sehen kann, versucht sie, ihre eigene lokale Zeitablaufsteuerung als globale Zeitablaufsteuerung für alle bei dem System 1 zu registrierende Knoten 3 festzulegen (Kaltstartphase; ColdStart) 14. Von der Integrationsphase 13 und von der Kaltstartphase 14 aus kann die Kommunikationssteuerung 5 in den Normalmodus 15 eintreten. Während der Integrationsphase 13 wird jede Abweichung von der regulären Kommunikationsmedium-Zugriffsablaufsteuerung von dem Buswächter 6 als ein Fehler interpretiert und der Status der Kommunikationssteuerung 5 wechselt zu einem Fehlerstatus (F) 16. In dem Fehlerstatus 16 verhindert der Buswächter 6 für eine begrenzte Zeitspanne oder bis die Kommunikationssteuerung 5 wieder heruntergefahren wird, daß die Kommunikationssteuerung 5 auf das Kommunikationsmedium 2 zugreift. Nach dem Herunterfahren der Kommunikationssteuerung 5 endet das Verfahren gemäß der vorliegenden Erfindung im Block 17.
Während der Kaltstartphase 14 erkennt der Buswächter Abweichungen von der regulären Kommunikationsmedium-Zugriffsablaufsteuerung. Diese Abweichung kann zulässig 18 oder verboten 19 sein. Zulässige Abweichungen 18 führen zu einem Ablaufsteuerungs-Rücksetzen (SR) 20. Nach dem Ablaufsteuerungs-Rücksetzen 20 kehrt die Kommunikationssteuerung 5 in die Initialisierungsphase 12 zurück und betrachtet die auf dem Kommunikationsmedium 2 stattfindende Kommunikation. Verbotene Abweichungen 19 führen dazu, daß der Status der Kommunikationssteuerung 5 zu dem Fehlerstatus 16 wechselt, und das Verfahren endet im Block 17.
Die vorliegende Erfindung schlägt einen Mechanismus vor, der es dem Buswächter 6 ermöglicht, allen zulässigen Ablaufsteuerungs-Rücksetzungen (SR) zu folgen und gleichzeitig einen hohen Grad an Unabhängigkeit zu besitzen, um verbotene oder falsche Ablaufsteuerungs-Rücksetzungen (SR) zu erkennen und entsprechend zu reagieren. Für die Implementierung der Erfindung ist keine zusätzliche Entität, wie etwa eine Verarbeitungseinheit auf höherer Ebene, notwendig.
Der Buswächter 6 besitzt eine geeignete Repräsentation des möglichen Verhaltensmusters der zu überwachenden Kommunikationssteuerung 5. Dadurch wird das komplexe Verhalten der Kommunikationssteuerung 5 auf Rücksetzinformationen und auf das chronologische Auftreten der Rücksetzinformationen während des Herauffahrens der Kommunikation abgebildet. Der Buswächter 6 kann sogenannte Erwartungsfenster definieren und sicherstellen, daß nach der Erkennung eines bestimmten Musters des Kommunikationssystem-Zugriffschemas der Kommunikationssteuerung 5 keine weiteren Ablaufsteuerungs-Rücksetzungen angenommen werden. Dadurch kann der Buswächter 6 verschiedene Verhaltensmuster der Kommunikationssteuerung 5 erkennen und gegebenenfalls diese von einem verbotenen oder falschen verhalten unterscheiden.
121 bis 127 zeigen eine Ausführungsform der Erfindung, bei der die Kommunikationssteuerung 5 eine Prozedur für das Ablaufsteuerungs-Rücksetzen (SR) befolgt. Ein Knoten 3 kann entweder versuchen, eine anfängliche Herstellung des Kommunikationsmedium-Zugriffsschemas über den Kaltstartweg 14 zu erzielen oder über den Integrationsweg 13 an einer bereits existierenden Kommunikation teilzunehmen.
Ein Parameter ColdStartMax in der Kommunikationssteuerung 5 spezifiziert die Anzahl der Kommunikationszyklen, für die die Steuerung 5 in dem Kaltstartweg 14 arbeiten und versuchen kann, eine Kommunikation mit anderen Kommunikationssteuerungen des Kommunikationssystems 1 herzustellen, das heißt, durch Eintreten in den Normalmodus 15 die Ablaufsteuerungs-Einrichtung abzuschließen. Mit jedem Kommunikationszyklus in dem Kaltstartweg 14 wird ein ColdStart-Zähler inkrementiert. Sobald der Wert des Zählers den Parameter ColdStartMax erreicht, verliert die Kommunikationssteuerung 5 ihre Autorisation zum Eintritt oder Verbleiben in dem Kaltstartweg 14. Bei den folgenden Ausführungsformen wird angenommen, daß der Parameter ColdStartMax gleich 3 ist; natürlich kann er auch jeden beliebigen anderen Wert annehmen. Der Buswächter 6 muß seine Auswertung des Verhaltens der Kommunikationssteuerung 5 (integrierendes oder Kaltstart-Verhalten) in der tatsächlichen Situation und den Wert des ColdStart-Zählers alleine deduzieren. Der Parameter ColdStartMax kann in dem Buswächter 6 als a-priori-Informationen während der Konfigurationsphase gespeichert werden.
In 121 bis 127 zeigt der obere Verlauf die Kommunikationsablaufsteuerung der Kommunikationssteuerung 5. In allen Figuren wird eine Kommunikationsablaufsteuerung mit fünf Zeitschlitzen zur Übertragung von Informationen behandelt. Ein Rechteck mit einer durchgezogenen Linie symbolisiert eine aktive Übertragung an dem eingeteilten Zeitpunkt. Ein Rechteck mit einer gestrichelten Linie bedeutet, daß die Kommunikationssteuerung 5 bereits eine von einem anderen Knoten 3 stammende Zeitablaufsteuerung angenommen hat, aber für die angegebenen Übertragungszyklen noch nicht aktive Rechte zum Senden von Daten beseitigt.
Der untere Verlauf zeigt ein Freigabesignal BGEN für den Kommunikationsmedium-Zugriff der Kommunikationssteuerung 5. Dieses Signal wird von dem Buswächter 6 erzeugt und ermöglicht der Kommunikationssteuerung 5, während seiner Low-Phase (low-aktiv) auf das Kommunikationsmedium 2 zuzugreifen. Während seiner High-Phase ist der Kommunikationsmedium-Zugriff gesperrt.
Ein Aspekt der vorliegenden Erfindung besteht darin, die Erzeugung des Freigabesignals BGEN in dem Buswächter 6 an eine mögliche Variation des Kommunikationsmedium-Zugriffsverhaltens der Kommunikationssteuerung 5 anzupassen, und zwar insbesondere während des Herauffahrens der Kommunikation. Zu diesem Zweck wird in den in 121 bis 127 gezeigten Ausführungsformen ein Triggersignal ARM analysiert, das durch die Kommunikationssteuerung 5 erzeugt wird, um die Kommunikationssteuerung 5 und den Buswächter 6 zu synchronisieren. Zum Beispiel dient das Triggersignal ARM zum Übermitteln des Anfangs der Kommunikationsablaufsteuerung zu dem Buswächter 6 und zur Verhinderung eines Auseinanderdriftens der Kommunikationsablaufsteuerungen der Kommunikationssteuerung 5 und des Buswächters 6, wobei das Auseinanderdriften aufgrund von Toleranzen in den lokalen Timern unausweichlich ist. Die Aktivierung eines Triggersignals (Triggerimpulses) ARM ist durch einen Pfeil auf der gestrichelten Mittellinie dargestellt. Der Zeitpunkt, zu dem der Buswächter 6 ein Nichterscheinen des Triggersignals ARM als ein Ablaufsteuerungs-Rücksetzen interpretiert, ist mit doppelten Klammern dargestellt.
121 bis 123 zeigen den Verlauf von Signalen für ein Ablaufsteuerungs-Einrichten, die jeweils ohne ein Ablaufsteuerungs-Rücksetzen in der Kommunikationssteuerung 5 und in dem dieser zugewiesenen Buswächter 6 gehen.
121 zeigt eine Situation, in der die Kommunikationssteuerung 5 bereits im Normalmodus 15 arbeitet und in der der Buswächter 6 periodisch in dem dritten von fünf Zeitschlitzen 30 eines Kommunikationszyklus 31 Zugriff auf das Kommunikationsmedium 2 erlaubt. Mittels des Triggersignals ARM am Anfang eines Kommunikationszyklus 31 wird sichergestellt, daß die Mediumzugriff-Ablaufsteuerung der Kommunikationssteuerung 5 und die Mediumfreigabe-Ablaufsteuerung des Buswächters 6 synchronisiert sind. Das Nichterscheinen des Triggersignals ARM wird von dem Buswächter 6 als ein Fehler interpretiert und der Buswächter 6 sperrt den Medium-Zugriff permanent.
122 zeigt eine Situation, in der die Kommunikationssteuerung 5 in den Kaltstartweg 14 eintritt und den Normalmodus innerhalb der zulässigen Anzahl von Kommunikationszyklen erreicht. Abhängig von dem Kaltstartverhalten der Kommunikationssteuerung 5 wird eine spezielle Nachricht CAS (Kollisionsvermeidungssymbol) gesendet (siehe das schwarze Rechteck), gefolgt durch einen Zugriff in die reguläre Medium-Zugriffsablaufsteuerung. Dieses spezielle Verhalten wird dem Buswächter 6 durch Aktivieren des Triggersignals ARM vor der Anfangsnachricht CAS sowie unmittelbar nach der Nachricht CAS (Anfang des Anfangskommunikationszyklus) angezeigt. Direkt nach dem ersten Triggerimpuls ARM, das heißt nach dem Abschluß des Zeitschlitzes, wird das Auftreten eines weiteren Triggerimpulses ARM als Ablaufsteuerungs-Rücksetzen interpretiert. Gleichzeitig erkennt der Buswächter 6, daß die Kommunikationssteuerung 5 in den Kaltstartweg 14 eingetreten ist. Diese Bedingung wird zum Inkrementieren des ColdStart-Zählers in dem Buswächter 6 gemäß dem Verhalten der Kommunikationssteuerung 5 benutzt. Mit ColdStartMax = 3 würde folglich für weitere dreimal Ablaufsteuerungs-Rücksetzen am Ende eines Kommunikationszyklus ausgeführt, das heißt, die Kommunikationssteuerung 5, die aus dem Kaltstartweg 14 austritt, würde weitere dreimal angenommen. Dies ist in 122 durch die doppelten Klammern symbolisiert.
In 122 durchläuft die Kommunikationssteuerung 5 den Kaltstartweg 14 jedoch für die zulässige maximale Anzahl von Kommunikationszyklen und erzeugt regelmäßig Triggerimpulse in zyklischen Intervallen. Nachdem der Grenzwert ColdStartMax erreicht wurde, kann der Buswächter 6 die Möglichkeit eines Ablaufsteuerungs-Rücksetzens zu einem späteren Zeitpunkt sperren (siehe doppelte Klammern in 122). Dadurch stellt der Buswächter 6 sicher, daß die Kommunikationssteuerung 5 nach keiner Anzahl von Kommunikationszyklen ein Ablaufsteuerungs-Rücksetzen des Buswächters 6 einleiten kann. Für den Rest wird jeder Triggerimpuls ARM, der nicht an einem Zeitpunkt zwischen zwei Kommunikationszyklen auftritt, als ein Fehler bewertet, wodurch eine permanente Blockierung des Kommunikationsmedium-Zugriff durch den Buswächter 6 verursacht wird.
123 zeigt eine Situation, in der die Kommunikationssteuerung 6 über den Integrationsweg in den Normalmodus 15 eintritt. Bevor die Kommunikationssteuerung 5 aktiv an der Kommunikation über das Kommunikationsmedium 2 teilnimmt, nimmt sie die globale Kommunikationsablaufsteuerung an und erkennt ihren eigenen Zeitschlitz für die Übertragung innerhalb eines Kommunikationszyklus (Rechtecke mit gestrichelten Linien). Der erste Triggerimpuls ARM übermittelt dem Buswächter 6, daß sich die Kommunikationssteuerung 5 am Anfang eines Kommunikationszyklus befindet, in dem gemäß der Kommunikationsmedium-Zugriffsablaufsteuerung der Zeitschlitz aktiv zugeteilt ist. An diesem Zeitpunkt kann der Buswächter 6 noch nicht erkennen, ob die Kommunikationssteuerung 5 ein integrierendes oder Kaltstart-Verhalten zeigen soll. Deshalb muß der Buswächter 6 so reagieren, daß beide Möglichkeiten unterstützt werden. Als Reaktion auf den ersten Triggerimpuls ARM gibt der Buswächter 6 den Kommunikationsmedium-Zugriff für einen Zeitraum von einem Zeitschlitz frei, falls eine Kommunikationssteuerung 5 eine Anfangsnachricht CAS in dem Kaltstartweg 14 senden möchte (siehe 122). Unmittelbar nach diesem Zeitschlitz öffnet der Buswächter 6 ein Erwartungsfenster 32 für einen weiteren Triggerimpuls ARM, wodurch ein Ablaufsteuerungs-Rücksetzen eingeleitet werden könnte (falls die Kommunikationssteuerung 5 Kaltstartverhalten zeigt (siehe 122). Wenn dieser weitere Triggerimpuls ARM auftritt, kann der Buswächter 6 daraus ableiten, daß die Kommunikationssteuerung 5 über den Integrationsmodus 13 in den Normalmodus 15 eingetreten ist. Dies bedeutet jedoch, daß keine weiteren Ablaufsteuerungs-Rücksetzungen (SR) zulässig sind und daß jedes Nichtauftreten eines erwarteten Trigger impulses ARM von dem Buswächter 6 als ein Fehler interpretiert werden muß. In 123 wird dies durch den Umstand geklärt, daß der Buswächter 6 keine weiteren Erwartungsfenster 33 (repräsentiert durch die doppelten Klammern) für ein Ablaufsteuerungs-Rücksetzen (SR) öffnet.
124 zeigt eine Situation, in der die Kommunikationssteuerung 5 den Kaltstartweg 14 in dem dritten Kommunikationszyklus nach der Anfangsnachricht CAS verläßt und nicht in den Normalmodus 15 eintritt. Die Bedingung für das Einleiten eines Ablaufsteuerungs-Rücksetzens in dem Buswächter 6 ist das Nichtauftreten des Triggerimpulses ARM innerhalb des Erwartungsfensters (siehe mindestens eines der Erwartungsfenster 33 und das Ereignis SR). Es wird der Umstand ausgenutzt, daß die Kommunikationssteuerung 5 gemäß ihrem spezifizierten Verhalten in dem Kaltstartweg 14 nicht das Ende des aktuellen Kommunikationszyklus erreicht und deshalb der Triggerimpuls ARM nicht mehr eingeleitet werden kann. Der Buswächter 6 deduziert indirekt die Bedingungen für sein eigenes Ablaufsteuerungs-Rücksetzen von dem überwachten Kommunikationsverhalten der Kommunikationssteuerung 5. Danach kehrt der Buswächter 6 zu einem Anfangszustand 12 zurück. Von diesem Anfangszustand 12 aus kann der Buswächter 6, getriggert durch einen Triggerimpuls ARM der Kommunikationssteuerung 5, in den Integrationsweg 13 oder in den Kaltstartweg 14 migrieren. Im Anfangszustand 12 ist der Medium-Zugriff blockiert; der ColdStart-Zähler für die Anzahl der Kommunikationszyklen in dem Kaltstartweg 14 wird nicht zurückgesetzt.
125 zeigt eine Situation, in der die Kommunikationssteuerung 5 den Kaltstartweg 14 in dem ersten Kommunikationszyklus nach der Anfangsnachricht CAS verläßt. Der Buswächter 6 hat den Eintritt in den Kaltstartweg 14 erkannt (Triggerimpuls in dem ersten Erwartungsfenster nach dem Anfangs-Triggerimpuls) und führt am Ende des ersten Kommunikationszyklus ein Ablaufsteuerungs-Rücksetzen (SR) aus, weil die Bedingungen deshalb erkannt wurden. Ferner zeigt 125, daß der Buswächter 6 in der Lage ist, dem Kaltstartverhalten zu folgen, sobald die Kommunikationssteuerung 5 wieder aktiv ist und erneut in den Kaltstartweg 14 eintritt.
126 zeigt eine Situation, in der die Kommunikationssteuerung 5 ein fehlerhaftes Verhalten zeigt, das durch den Buswächter 6 als solches erkannt wird. Nach der anfänglichen Aktivierung des Triggersignals ARM wird kein Ablaufsteuerungs-Rücksetzen freigegeben. Von dem Buswächter 6 aus gesehen bedeutet dies, daß die Kommunikationssteuerung 5 über den Integrationsweg 13 in den Normalmodus 15 eintritt. Ein Nichtauftreten des erwarteten Triggersignals ARM wird nicht mehr als Ablaufsteuerungs-Rücksetzen akzeptiert (keine weiteren Erwartungsfenster), und die fehlende Aktivierung des Triggersignals ARM am Ende des Kommunikationszyklus 31 adressiert die Fehlerdetektion in dem Buswächter 6 (siehe Fehlerereignis F). Folglich sperrt der Buswächter 6 den Medium-Zugriff und die Kommunikationssteuerung 5 kann das Geschehen in dem Kommunikationsmedium 2 nicht beeinflussen, obwohl sie immer noch die Kommunikationsablaufsteuerung verarbeitet.
127 zeigt eine Situation, in der der Buswächter 6 abhängig von der Konfiguration des Parameters ColdStartMax (in dem vorliegenden Beispiel ist sein Wert auf drei gesetzt) die Freigabe eines Ablaufsteuerungsrücksetzens dreimal nach dem Ende jedes Kommunikationszyklus erlaubt. Das Erwartungsfenster wird geöffnet, aber bei diesem Beispiel nicht von der Kommunikationssteuerung 5 benutzt. Nur in dem folgenden Kommunikationszyklus emittiert die Kommunikationseinheit 5 keinen Triggerimpuls ARM zu dem Buswächter 6. Da die maximale Anzahl der Kommunikationszyklen ColdStartMax, für die ein Ablaufsteuerungs-Rücksetzen durch den Buswächter 6 angenommen wird, überstiegen ist, wird dieses Verhalten als fehlerhaft bewertet (Fehlerereignis F). Dies könnte von einer fehlerhaften Konfiguration der Begrenzungswerte in der Kommunikationssteuerung 5 und in dem Buswächter 6 oder von der Nichterzeugung des notwendigen Triggerimpulses ARM durch die Kommunikationssteuerung 5 aufgrund eines internen Verarbeitungsfehlers herrühren. In jedem Fall ist die Fehlerdetektion und das Blockieren des Medium-Zugriffs durch den Buswächter 6 die gewünschte Reaktion für das Kommunikationssubsystem (Knoten 3).
Das erfindungsgemäße Konzept kann auch für andere als die beschriebenen Herauffahrsequenzen verwendet werden. In diesem Fall müßte die Abbildung der Bedingungen für ein Ablaufsteuerungs-Rücksetzen in dem Buswächter 6 angepaßt werden. Die Fähigkeit des Buswächters, ein Ablaufsteuerungs-Rücksetzen aus dem Verhalten der Kommunikationssteuerung 5 zu deduzieren, kann durch eine Hoststeuerung 5 einer höheren Schicht deaktiviert werden. Die Hoststeuerung 4 besitzt Informationen bezüglich des Zeitpunkts, zu dem die Kommunikationssteuerung 5 in den Normalmodus 15 eintritt. Sobald die Kommunikationssteuerung 5 in den Normalmodus 15 eintritt, deaktiviert die Hoststeuerung 4 das erfindungsgemäße Verfahren, obwohl die Anzahl der Zyklen in dem Kaltstartweg 14 noch nicht den Parameter ColdStartMax erreicht hat.
Die vorliegende Erfindung kann insbesondere für neuartige Kommunikationssysteme in Fahrzeugen verwendet werden. Zur Zeit werden zwei verschiedene Standards für Kommunikationsprotokolle für zukünftige X-by-wire-Anwendungen entwickelt. Sowohl bei FlexRay als auch bei TTP (Zeitgetriggertes Protokoll) wird beabsichtigt, einen Buswächter zu verwenden. Für beide Standards repräsentiert die vorliegende Erfindung einen idealen Ansatz für die Probleme eines unweigerlichen Ablaufsteuerungs-Rücksetzens während des Herauffahrens des Systems.
Die vorliegende Erfindung bezieht sich auf ein verläßliches Automotive-Netzwerk. In der gesamten folgenden Beschreibung wird der folgenden Struktur gefolgt: am Anfang jedes Kapitels (Abschnitts) werden die Anforderungen für dieses Thema definiert, danach werden ausführlichere Beschreibungen gegeben. In der Beschreibung werden zur Bezeichnung von Konstanten GROSSBUCHSTABEN verwendet. Alle in der Schrift verwendeten Konstanten sind am Ende der Beschreibung aufgelistet.
Ziele
Die bei der Entwicklung des verläßlichen Automotive-Netzwerks verfolgten Ziele sind die folgenden:

• Unterstützung zweier Kommunikationsparadigmen, deterministische (statisch definierte) Kommunikation und dynamische ereignisgesteuerte Kommunikation.
• Konfigurierbarer statischer und dynamischer Teil (Segment) in einem Kommunikationszyklus. Es muß eine völlig statische und völlig dynamische Konfiguration unterstützt sein.
• Flexible Erweiterbarkeit auch nach dem Einsatz.
• Hohe Datenrate und Bandbreiteneffizienz.
• Skalierbare Fehlertoleranz (d.h. Einkanal- und Doppelkanalbetrieb müssen unterstützt sein).
• Zuverlässige Fehlerdetektion (Buswächtermechanismus im Zeitbereich, CRC-Prüfung (cyclic redundancy check) im Wertebereich).
• Unterstützung elektrischer und optischer physischer Schnittstellen.
• Ermöglichung von Ausfällen auf sehr niedriger Systemebene bei Zeitnennwerten.
• Erlauben der Verwendung von Kristalloszillatoren und Keramikresonatoren mit niedriger Toleranz.
• Unterstützung von Aktiv-Stern- und Bustopologien.
• Niedrige Gesamtsystemkosten.
• Ermöglichung einer Wiederverwendung von Carry-Over-Komponenten ohne Einbettung von wissen über zukünftige Plattformaufteilung.

Die Ziele des statischen Segments sind die folgenden:

• Deterministisches Kommunikationsverhalten im Zeitbereich.
• Durch einen fehlertoleranten Taktsynchronisationsalgorithmus implementierte globale Zeit.
• Immunität gegenüber der Annahme von fehlerfreien Subsequenzen einer Nachricht als gültige Nachrichten (d.h. Kurznachrichtenzurückweisung).

Die Ziele des dynamischen Segments sind die folgenden:

• Möglichkeit einer ereignisgesteuerten dynamischen Kommunikation.
• Flexible Bandbreitenzuteilung (für verschiedene Knoten während der Laufzeit).
• Keine Interferenz mit dem statischen Segment.
• Unterstützung des Buszugriffs mit Prioritäten.
• Unterstützung von Nachrichten variabler Länge mit mindestens 200 Datenbyte.

Die globalen Anforderungen lauten wie folgt:

• Unterstützung von Fehlertoleranz, es muß aber auch ein Betrieb ohne Fehlertoleranz möglich sein, d.h. es muß eine Verbindung über einen einzigen Bus für nicht fehlertolerante Knoten möglich sein.
• Das Kommunikationsnetz muß eine Systemarchitektur unterstützen, bei der kein einzelner Fehler zu einer funktionalen Verschlechterung führen darf.
• Schutz vor Fehlern gemäß wohldefinierten Fehlerhypothesen.
• Schutz vor bis zu einschließlich fünf Zufallsbitfehlern pro Rahmen.
• Das Kommunikationsprotokoll sollte so weit wie möglich unabhängig von der Topologie sein.
• Für hochverläßliche und fehlertolerante Anwendungen ist ein unabhängiger Buswächter zur Verhinderung der Monopolisierung des Kommunikationsmediums durch eine Kommunikationssteuerung erforderlich (sogenannter „babbling idiot").
• Hardware- und Konfigurationsdatenfehler müssen während der Initialisierung und des Betriebes durch Fehlerdetektionsmechanismen (EDMs) erkannt werden. Falls ein kritischer Fehler erkannt wird, darf es der Steuerung und dem Sender/Empfänger nicht erlaubt werden, in den normalen Betrieb einzutreten, oder sie müssen sofort den normalen Betrieb abbrechen und dem Host einen Fehler melden.
• Unterstützung der Service-Fähigkeit von Fehlern auf System- und Komponentenebene.
• Die Bitcodierungstechnik darf keine datenabhängigen Änderungen der Länge des resultierenden Bitstroms einführen z.B. ist kein Bitstopfen erlaubt.
• Es ist eine Automotive-Qualifikation der Kommunikationssteuerung, des Buswächters und der physischen Schicht erforderlich.
• Konfigurationsdaten müssen durch den Host lesbar/schreibbar sein. Es muß möglich sein, das Schreiben während der Laufzeit zu sperren.
• Unterstützung umfassender Selbstprüfung beim Herauffahren der Systemkommunikation.
• Unterstützung von rechtzeitiger und sehr zuverlässiger KomponentenReintegration und rechtzeitigem und sehr zuverlässigem Herauffahren auf Systemebene.
• Unterstützung von Master-losem Systemherauf- und -herunterfahren.
• Unterstützung von Verfolgbarkeit von Fehlern auf System- und Komponentenebene zur Identifizierung von Ursachen von Ausfällen.
• Unterstützung eines synchronisierten Systemherunterfahrens ohne Fehleranzeigen.
• Unterstützung von synchronisiertem Herauffahren und Herunterfahren verteilter Anwendungen mit annehmbaren Zeitsteuerungs- und Fehlertoleranzeigenschaften.
• Unterstützung von Knoten- und Netzwerk-Moding mit hoher Sicherheit vor kritischen unbeabsichtigten Modusänderungen.
• Logikleitungskompatibilität mit dem byteflight-Protokoll bei der Verwendung einer optischen physischen Schicht muß möglich sein.

Grundkonzepte
Das Kommunikationsprotokoll für das verläßliche Automotive-Netzwerk gemäß der vorliegenden Erfindung hat die folgenden Eigenschaften:

• Synchroner und asynchroner Rahmentransfer.
• Mehrfach-Master-Taktsynchronisation.
• Garantierte Latenzzeiten und garantiertes Jitter während synchronem Transfer.
• Prioritäten für Rahmen während des asynchronen Transfers.
• Fehlerdetektion und -signalisierung.
• Fehlereindämmung auf der physischen Schicht durch eine unabhängige Buswächtereinrichtung.
• Skalierbare Fehlertoleranz, z.B. eine Steuerung, ein/zwei Kanäle, ein Buswächter für jeden Kanal.

Das FlexRay-Protokoll kann in verschiedene Schichten einer Schichtenarchitektur unterteilt werden, die die folgenden Schichten umfaßt:

• Die physische Schicht definiert, wie Signale tatsächlich übertragen werden. Aufgaben der physischen Schicht sind Fehlereindämmung und Fehlerdetektion und -signalisierung. Die physische Schicht umfaßt eine Signalebene, eine Bitrepräsentation und ein Übertragungsmedium. Eine Aufgabe der physischen Schicht ist die Erkennung von Fehlern der Kommunikationssteuerung im Zeitbereich. Dies geschieht durch den sogenannten Buswächter.
• Die Transferschicht repräsentiert den Kern des Protokolls. Sie legt empfangene Rahmen der Präsentationsschicht vor und nimmt zu übertragende Rahmen von der Präsentationsschicht an. Die Transferschicht ist für Zeitsteuerung, Synchronisation, Nachrichten-Framing, Fehlerdetektion und -signalisierung und Fehlereindämmung verantwortlich.
• Die Präsentationsschicht betrifft die Rahmenfilterung und -maskierung, Rahmenstatusbehandlung und enthält die Kommunikationssteuerungs-Hostschnittstelle.
• Die Anwendungsschicht ist nicht Teil der vorliegenden Beschreibung.

Architektur des Knotens (ECU)
103 zeigt die Architektur eines Knotens 100 (elektronische Steuereinheit, ECU) des Kommunikationssystems. Jeder Knoten 100 besteht aus den fünf Subkomponenten Hoststeuerung 101, Kommunikationssteuerung 102, Buswächter 103, Bustreiber 104 und Stromversorgung 105. In der folgenden Beschreibung werden die Anforderungen für die Kommunikationssteuerung 102, den Buswächter 103, den Bustreiber 104 und die Schnittstelle zu dem Host 101 und die Stromversorgung 105 beschrieben.
Es sind zwei Implementierungen für die Kommunikationssteuerung möglich, eine Konfiguration einer Kommunikationssteuerung 102, die auf redundanten physischen Kanälen sendet und empfängt, und eine zweite Konfiguration, die nur mit einem physischen Kanal verbunden ist.
Topologie
104 zeigt eine mögliche Topologiekonfiguration des Kommunikationssystems 106 (Netzwerks). Ein Knoten 100 kann entweder mit beiden Kanälen 1 und 2 verbunden sein (Knoten A, C und E), oder nur mit Kanal 1 (Knoten B) oder nur mit Kanal 2 (Knoten D). Es ist auch eine Konfiguration möglich, bei der alle Knoten 100 durch einen Kanal verbunden werden.
Rahmentransfer
Bei FlexRay erfolgt der Medium-Zugriff innerhalb eines Kommunikationszyklus. Innerhalb eines Kommunikationszyklus bietet FlexRay die Auswahl zweier Medium-Zugriffsschemata. Diese sind das Schema des statischen Zeitmultiplex-Mehrfachzugriffs (TDMA) und ein dynamisches Schema auf Minischlitzbasis. Die Kommunikation in dem Kommunikationssystem 106 erfolgt in einem Kommunikationszyklus, der aus einem statischen Segment und einem dynamischen Segment besteht, wobei jedes der Segmente leer sein kann. Die erste Rahmen-ID in einem System mit einem statischen Segment ist die ID-Nummer 1 (siehe 105). In einem reinen dynamischen System mit einem Symbol für Zyklusstart (SOC) (siehe 106). Die Sendeschlitze werden durch ID-Nummern repräsentiert, die auf beiden Kanälen gleich sind.
Die Sendeschlitze werden (bei einer vordefinierten Strategie des Zeitmultiplex-Mehrfachzugriffs (TDMA)) in dem statischen Segment deterministisch verwendet. In dem dynamischen Segment kann es Phasenunterschiede auf den beiden Kanälen geben (siehe 106). Knoten 100, die mit beiden Kanälen verbunden sind, senden ihre Rahmen gleichzeitig auf beiden Kanälen in dem statischen Segment. Zwei Knoten, die nur mit einem Kanal verbunden sind, aber nicht demselben Kanal, können sich einen Schlitz in dem statischen Segment teilen.
Um die Einheitlichkeit der Taktsynchronisation zu garantieren, können nur Knoten 100 teilnehmen, die Rahmen senden, die von allen anderen Knoten (z.B. Knoten A, C und E in 104) empfangen werden. Alle Knoten führen den Taktsynchronisationsalgorithmus aus, es werden aber nur die Rahmen des statischen Segments betrachtet. Es ist möglich, in demselben Sendeschlitz auf verschiedenen Kanälen verschiedene Daten zu senden.
Die folgenden Einschränkungen sollten in dem Kommunikationssystem 106 gemäß der vorliegenden Erfindung respektiert werden:

• Die Kommunikationssteuerung 102 muß sich an eine optische oder elektrische physische Schicht anschalten können.
• Die Kommunikationssteuerung 102 muß eine Nettodatenrate von mindestens 5 Mbit/s von pro Sekunde transferierten Realanwendungsdaten unter den Einschränkungen des Rahmenoverhead (einschließlich CRC) und des Protokollzeitsteuerungsoverhead (Lücke zwischen Rahmen IFG) im statischen Kommunikationsmodus unterstützen.
• Es muß möglich sein, zwei bis zu einem Wert CONTROLLER_MAX Steuerungen 102 mit einem Kommunikationskanal zu verbinden. CONTROLLER_MAX ist die maximale Anzahl der mit einem Kommunikationskanal verbundenen Steuerungen 102 und kann zum Beispiel einen Wert von 64 aufweisen.
• Die maximale Anzahl der Schlitze in dem statischen Segment wird auf STATIC_SLOTS_MAX eingestellt. STATIC_SLOTS_MAX ist die maximale Anzahl der statischen Schlitze in einem statischen Segment eines Kommunikationszyklus und kann zum Beispiel einen Wert von 4095 aufweisen.
• Die Stromversorgung 105 für den Bustreiber 104 (einschließlich des Buswächters 103) und die Kommunikationssteuerung 102 müssen Automotive-Anforderungen entsprechen.

Anmerkung
Mit Bezug auf das in dem vorherigen Teil der Beschreibung beschriebene FlexRay-Protokoll kann das Kommunikationsschema vernetzter FlexRay-Knoten kurz folgendermaßen charakterisiert werden:

• Jeder Knoten 100 muß den verteilten Takt verwenden können.
• Jeder Knoten 100 muß Rahmen innerhalb eines vordefinierten statischen Schlitzes oder/und innerhalb des dynamischen Segments (kollisionsfreier Zugriff) senden

Die Übertragung von Rahmen muß in drei Phasen unterteilt werden:

1. Ein Buswächter 103 muß den Zugriff auf den Bus freigeben;
2. Es muß signalisiert werden, daß ein Rahmen übertragen werden soll;
3. Die Übertragung des Rahmens selbst.

Protokollbeschreibung
In der gesamten Schrift wird die folgende Notation verwendet:

Anf.: Anforderungen

Anmerkung: enthält zusätzliche Beschreibungen und Erläuterungen

Allgemeine Anforderungen

Anf.: Das Kommunikationsprotokoll soll von der Datenrate unabhängig sein.
Anmerkung:
Es soll möglich sein, Low-End-Steuerungen zu implementieren, z.B. Steuerungen mit 500 Kbit/s und High-End-Steuerungen mit mehr als 100 Mbit/s.

Anf.: Die erste Kommunikationssteuerung muß eine Nettodatenrate von mindestens 5 Mbit/s unterstützen.
Anmerkung:

Nettodatenrate: Realanwendungsdaten, die pro Sekunde unter den Einschränkungen des Rahmenoverhead (einschließlich CRC) und des Protokollzeitsteuerungsoverhead (IFG) im statischen Kommunikationsmodus transferiert werden.

Anf.:	Es muß ein CRC-Code mit einer Hamming-Distanz von mindestens 6 verwendet werden.
Anf.:	Die Kommunikationssteuerung soll in der Lage sein, in einer derzeitigen byteflight-Umgebung zu arbeiten, d.h. die beiden Protokollsteuerungen müssen dieselbe physische Schnittstelle und dieselbe Repräsentation auf der logischen Leitungsebene unterstützen. Die byteflight-Kompatibilität ist nur für die optische physische Schicht erforderlich.

Anmerkung:
Es ist keine Kompatibilität der Schnittstellen zwischen Host-CPU und der Protokollsteuerung (CHI) erforderlich. Die elektrische physische Schicht muß keine byteflight-Kompatibilität unterstützen. Die byteflight-Spezifikation kann von der folgenden Webadresse heruntergeladen werden:
www.byteflight.com.
Rahmentransfer

Der Datentransfer bei FlexRay erfolgt in Zyklen, die als Kommunikationszyklen bezeichnet werden.

Anf.:

Der Kommunikationszyklus besteht aus einem statischen und einem dynamischen Segment, wie in Figur 105 gezeigt. Jedes der Segmente kann leer sein, d.h. es gibt drei mögliche Konfigurationen des Kommunikationszyklus (rein statisch, gemischt statisch und dynamisch (ein gemischtes System besteht aus mindestens zwei statischen Schlitzen) und rein dynamisch).

In einem reinen dynamischen System beginnt der Kommunikationszyklus mit einem SOC-Symbol. Es gibt zwei verschiedene SOC-Symbole (Alarmbedingung, Normalbedingung). Die Sendeschlitze werden durch die Kennungen repräsentiert, die auf beiden Kanälen gleich sind (siehe Figur 106). Die Sendeschlitze werden (in einer vordefinierten TDMA-Strategie) in dem statischen Segment deterministisch verwendet. In dem dynamischen Segment kann es Phasenunterschiede auf den beiden Kanälen geben (siehe Figur 105). Knoten, die mit beiden Kanälen verbunden sind, senden ihre Rahmen in dem statischen Segment gleichzeitig auf beiden Kanälen. Ein Knoten, der nur mit einem Kanal verbunden ist, kann sich eine Kennung mit einem anderen Knoten, der nur mit dem anderen Kanal verbunden ist, teilen. Der aktuelle Kommunikationszyklus wird durch einen Zykluszähler bestimmt, der in jedem Zyklus einheitlich inkrementiert wird (siehe Figur 108).

Anf.:

Die Länge des Kommunikationszyklus muß in den Konfigurationsdaten gespeichert werden.

Paßkriterien:

Die maximale Zykluslänge wird durch CYCLE_LENGTH_MAX definiert und kann zum Beispiel einen Wert von 64 ms aufweisen.

Anf.:

Ein Prüfmechanismus muß so ausgelegt werden, daß sichergestellt wird, daß innerhalb eines bestimmten Intervalls, der sogenannten verbotenen Region, vor dem Ende des

	Kommunikationszyklus keine Rahmenübertragung gestartet wird, um sicherzustellen, daß der Anfang des statischen Segments in dem nächsten Kommunikationszyklus nicht gestört wird.
Anf.:	Das Multiplexen von Sendeschlitzen einer Steuerung muß so unterstützt werden, daß Inhalte von Rahmen für bestimmte Sendeschlitze in verschiedenen Kommunikationszyklen gemultiplext werden können.

Anmerkung:

Es kann also eine Kommunikationsmatrix mit nahezu beliebigen möglichen Kommunikationsmustern (Perioden bestimmter Rahmen) auf der Basis der Prinzipien der Kommunikationszyklen aufgebaut werden. Statisches Segment

Anf.:	Wenn das statische Segment des Kommunikationszyklus nicht leer ist, besteht es aus STATIC_SLOTS_MIN ≤ NUMBER_OF_SLOTS ≤ STATIC_SLOTS_MAX.
Anf.:	Das statische Segment wird in eine Sequenz von Zeitschlitzen unterteilt. In jedem dieser statischen Schlitze kann auf jedem Kanal nur eine Steuerung einen Rahmen senden.

Anmerkung:

In dem statischen Segment des Kommunikationszyklus wird eine TDMA-Medium-Zugriffsstrategie verwendet.

Anf.:

Es gibt einen Konfigurationsparameter für die Schlitzlänge (slot_length) in dem statischen Segment, wodurch dieser Wert definiert wird. Die Länge der Schlitze ist offline konfigurierbar, aber während der Laufzeit fest.

Dynamisches Segment

Anf.:	In einem reinen dynamischen System beginnt der Kommunikationszyklus mit dem Symbol für Zyklusstart (SOC).
Anf.:	Das dynamische Segment des Kommunikationszyklus besteht aus null oder mehr dynamischen Kennungen (Schlitzen) in dem Kommunikationszyklus.
Anf.:	Der Buszugriff in dem dynamischen Segment erfolgt über statische Rahmenprioritäten gemäß der byteflight-Spezifikation.
Anf.:	In dem dynamischen Segment basiert die Medium-Zugriffsstrategie auf Wartezeiten (Minischlitzschema) und der Priorität von Kennungen. Steuerungen, die Rahmen mit Kennungen höherer Priorität senden, senden vor Steuerungen, die Rahmen niedrigerer Priorität senden.
Anf.:	Die Rahmenlänge in dem dynamischen Segment ist während der Laufzeit variabel.
Anf.:	Im reinen dynamischen Modus muß eine extern getriggerte SOC-Erzeugung und damit der Start des Kommunikationszyklus unterstützt werden. Das Zeitsteuerungsverhalten des externen Triggers muß durch die Kommunikationssteuerung überwacht werden.

Rahmenformat FlexRay

Anf.:

Es müssen zwei nachfolgend spezifizierte Formate unterstützt werden.

Anmerkung:
Die Mischung der beiden Rahmenformate muß nicht unterstützt werden, d.h. es können alle Knoten, die mit einem FlexRay-Kommunikationssystem verbunden sind, nur unter Verwendung des FlexRay-Formats (siehe 108) oder des byteflight-Formats (siehe 109) konfiguriert werden.
Das FlexRay-Rahmenformat

Das folgende bezieht sich auf das FlexRay-Rahmenformat.

Anf.:	Es muß möglich sein, das FlexRay-Format in einer reinen statischen, in einer kombinierten statischen und dynamischen und in einer reinen dynamischen Konfiguration zu verwenden.
Anf.:	Der erste Teil des Datenfeldes in einem Rahmen gemäß dem FlexRay-Format muß als ein Nachrichten-ID-Feld konfigurierbar sein. Dieses Datenfeld muß durch den Empfänger filterbar sein.

In 108 werden die folgenden Abkürzungen benutzt:

Res:

Reservierte Bit, 4 Bit für zukünftige Protokollerweiterungen.

ID:

Kennung, 12 Bit, Wertebereich: (1₁₀ ... 4095₁₀) definiert die Schlitzposition in dem statischen Segment und definiert die Priorität in dem dynamischen Segment. Eine niedrigere Kennung bestimmt eine höhere Priorität. Die Kennung eines Rahmens muß innerhalb eines Clusters eindeutig sein. Jede Steuerung kann eine oder mehrere Kennungen aufweisen (in dem statischen und dem dynamischen Segment).

SYNC:	Synchronisationsfeld, 1 Bit, zeigt an, daß der Schlitz für die Taktsynchronisation verwendet wird.
DLC:	Datenlängencodefeld, 7 Bit, DLC·2 = Anzahl der Datenbyte (0₁₀, 2₁₀, ..., 246₁₀)
H-CRC:	9-Bit-CRC-Sequenz. H-CRC wird über dem SYNC- und dem DLC-Feld berechnet.
NF:	Nullrahmenanzeigefeld, 1 Bit, zeigt an, daß der entsprechende Datenpuffer vor dem Senden nicht durch den Host aktualisiert wird.
CYCO:	Zykluszähler, 6 Bit, der Zykluszähler wird gleichzeitig in allen Knoten durch die Steuerung am Anfang jedes neuen Kommunikationszyklus erhöht.
Nachrichten-ID:	Das Nachrichten-ID-Feld ist konfigurierbar, um als Nachrichtenkennung oder als die ersten beiden Datenbyte benutzt zu werden.
D0 ... D246:	Datenbyte, 0–246 Byte.
CRC:	24-Bit-CRC-Sequenz. Die CRC wird über den vollständigen Rahmen berechnet.

byteflight-Rahmenformat
Das folgende bezieht sich auf das byteflight-Rahmenformat (siehe 109).

Anf.: Das byteflight-Rahmenformat muß für reine dynamische Konfigurationen unterstützt werden.

In 109 werden die folgenden Abkürzungen benutzt:

ID:	Kennung, 8 Bit, Wertebereich: (1₁₀ ... 255₁₀), definiert die Priorität in dem dynamischen Segment. Eine niedrigere Kennung bestimmt eine höhere Priorität. Die Kennung eines Rahmens muß innerhalb eines Clusters eindeutig sein. Jede Steuerung kann eine oder mehrere Kennungen enthalten.
Res:	Reservierte Bit, 4 Bit, für zukünftige Protokollerweiterungen.
LEN:	Längenfeld, 4 Bit, LEN = Anzahl der Datenbyte (0₁₀, ..., 12₁₀), ein Wert von mehr als 12 wird als LEN = 12 behandelt.
D0 ... D11:	Datenbyte, 0–12 Byte.
CRC:	15-Bit-CRC-Sequenz (x¹⁵ + x¹⁴ + x¹⁰ + x⁸ + x⁷ + x⁴ + x³ + 1).
FCB:	Füllvervollständigungsbit: ein zusätzliches Bit wird zu der 15-Bit-CRC hinzugefügt, um das vollständige Wort zu füllen. Das Bit wird auf „0" als LSB gesetzt.

Rahmenablaufsteuerung – Multiplexen des Sendens von Schlitzen
Das folgende bezieht sich auf die Rahmenablaufsteuerung und das Multiplexen des Sendens von Schlitzen.

Anf.: Der Zykluszähler kann zur Unterscheidung zwischen verschiedenen Rahmeninhalten verwendet werden.
Anmerkung:
Für einen Sendeschlitz können verschiedene Sende- und Empfangspuffer in verschiedenen Zyklen definiert werden (Schlitzmultiplexen)
Anmerkung:
Der Zykluszähler kann als logische Erweiterung der Kennung (im Fall des Multiplexens) verwendet werden.
Rahmen- und Bitcodierung
Das folgende bezieht sich auf die Rahmen- und Bitcodierung.

Anf.: Der Codierungsalgorithmus in der Kommunikationssteuerung muß gegenüber folgendem robust sein: – Glitches
Optische physische Schicht
Das folgende bezieht sich auf die optische physische Schicht.

Anf.: Die Steuerung muß mindestens die optische byteflight-Bitcodierung unterstützen.
Anmerkung:
Bei byteflight bestehen Rahmen auf dem Kommunikationsmedium aus einzelnen Byte, die aus einem Startbit, acht Datenbit und einem Stopbit bestehen.
Zusätzlich beginnt die Übertragung dieses Rahmens mit einer Startsequenz, die aus 6 logischen „0"-Bit besteht. Dies ist durch das Diagramm in 110 dargestellt. Aufgrund bestimmter Effekte bei der optischen Übertragung ist es möglich, daß die Startsequenz während der optischen Übertragung kürzer oder länger wird. Aus diesem Grund nimmt der Empfänger Startsequenzen in der Region von 1 bis 9 logischen „0"-Bit an. Dies ist durch das Diagramm in 111 dargestellt.
Elektrische physische Schicht

Das folgende bezieht sich auf die elektrische physische Schicht.

Anf.:	Rahmen auf dem Kommunikationsmedium für die elektrische physische Schicht sind wie in Figur 112 gezeigt aufgebaut. Die Rahmenendsequenz kann leer sein.
Anf.:	Es muß ein geeignetes Bitcodierungsschema gewählt werden, abhängig von Bandbreiteneffizienz- und elektromagnetischen Kompatibilitätsanforderungen (EMC).

Rahmenzeitsteuerung

Das folgende bezieht sich auf die Rahmenzeitsteuerung

Anf.:

Rahmenzeitsteuerungen verschiedener Kommunikationssteuerungsimplementierungen müssen interoperabel sein.

Rahmenzeitsteuerung für das statische Segment

Anf.:

Mit Bezug auf die Rahmenzeitsteuerung für das statische Segment soll das Empfangsstartfenster in Bezug auf die Präzision definiert werden, d.h. das Startfenster muß größer als die Präzision sein.

Anmerkung:

Der tatsächliche Wert für das Empfangsstartfenster muß in der Implementierungsspezifikation definiert werden.

Anf.:

In dem statischen Segment müssen genaue Zeitsteuerungsanforderungen für den korrekten Rahmenempfang sichergestellt werden. Rahmen dürfen nur innerhalb des Empfangsstartfensters gestartet werden.

Anmerkung:

Die Länge des Rahmens bestimmt die Rahmendauer. Korrekter Empfang ist gegeben, wenn der jeweilige Rahmen die durch das Zugriffsschema gegebenen zeitlichen Grenzen nicht verletzt. Die Beurteilung der zeitlichen Korrektheit basiert auf einem strengen Zeitsteuerungsschema.

Anf.:	Die Zeitdifferenz zwischen dem vorhergesagten Start StartNom und dem beobachteten Start des Rahmens (SOF) wird durch den Taktsynchronisationsalgorithmus verwendet.
Anf.:	Die Länge der Lücke zwischen Rahmen (IFG) muß minimiert werden, um die Nettokommunikationsrate zu optimieren.

Rahmenzeitsteuerung für das dynamische Segment

Anf.:

Mit Bezug auf die Rahmenzeitsteuerung für das dynamische Segment muß die Rahmenzeitsteuerung in dem dynamischen Segment aufgrund der byteflight-Spezifikation definiert werden.

Herauffahren
Anforderungen

Das folgende bezieht sich auf das Herauffahren des Kommunikationssystems.

Anf.:	Für jede Konfiguration (reine statische, reine dynamische und gemischte Systeme) muß das Herauffahren des Kommunikationsnetzwerks möglich sein, sobald zwei Knoten kommunizieren können.
Anf.:	Die Integration von Steuerungen, die später eingeschaltet werden, darf die Herauffahrprozedur der anderen Knoten nicht stören.
Anf.:	Das Herauffahren und Neuintegrieren von Steuerungen soll den normalen Betrieb des Netzwerks nicht stören.
Anf.:	Die Herauffahrzeit im ungünstigsten Fall unter den oben angegebenen Fehlerbedingungen muß vom Hersteller der Kommunikationssteuerung angegeben und garantiert werden. Das Kommunikationsnetzwerk muß nach 100 ms funktionsfähig sein.

Anmerkung:

Der Anwendungsentwickler muß die Herauffahrzeit während der Bestimmung der Konfigurationsparameter berücksichtigen. Typische Automotive-Anwendungen erfordern eine Herauffahrzeit im ungünstigsten Fall von 100 ms. Für Systemkonfigurationen mit extrem langen Kommunikationszyklen sind längere Herauffahrzeiten annehmbar.

Anf.:	Während des Herauffahrens setzt eine Kommunikationssteuerung den Zykluszähler abhängig von dem Wert in dem empfangenen Rahmen. Die Zykluszeit wird aus der Rahmen-ID abgeleitet und entsprechend gesetzt.
Anf.:	Das Herauffahren muß funktionieren, ohne sich auf Kollisionsdetektion zu verlassen.

Anmerkung:
Kollisionen können auf dem Bus während des Herauffahrens und dem Fall von Fehlern auftreten. Bei Sterntopologien ist die Kollisionsdetektion nicht immer durchführbar. Funktionsprinzip – Protokollbetriebsarten Reines statisches System und gemischtes System

Anf.: Das Herauffahren muß als ein verteilter Algorithmus arbeiten.

Anf.: Nur Steuerungen, die an der Taktsynchronisation teilnehmen (SYNC-Bit gesetzt) dürfen das System herauffahren.
Anmerkung:
Bei einem Doppelkanalsystem dürfen in einer heterogenen Topologie (die Steuerungen mit einem Kanal und Steuerungen mit Doppelkanal mischt) nur mit beiden Kanälen verbundene Steuerungen das Herauffahren ausführen.

Mit nur einem Kanal verbundene Steuerungen dürfen den Bus nicht herauffahren, weil sie den Verkehr dieses Kanals im Fall eines Ausfalls der ankommenden Strecke durch Senden von Rahmen nach der Zuhörzeitgrenze (listen_timeout) verfälschen können.

Anf.:

Das Herauffahren des Kommunikationsnetzes, die Integration von später eingeschalteten Knoten und die Reintegration von ausgefallenen Knoten müssen gegenüber folgendem fehlertolerant sein: – dem vorübergehenden/permanenten Ausfallen einer oder mehrerer Kommunikationssteuerungen (bis herab zu einer Steuerung, die in dem statischen Segment sendet, für gemischte oder reine statische Konfigurationen), – dem vorübergehenden/permanenten Ausfallen eines oder mehrerer Kommunikationskanäle in einer redundanten Konfiguration und – dem Verlust eines oder mehrerer Rahmen.

Reines dynamisches System

Anf.:

Ein einziger Master sendet das SOC-Symbol. Der Master soll in der Entwicklungszeit definiert werden.

Herunterfahren

Das folgende bezieht sich auf das Herunterfahren des Kommunikationssystems.

Anf.:

Das koordinierte Herunterfahren des FlexRay-Clusters, einschließlich aller Knoten und aller Sterne, die durch die Anwendung initialisiert werden, muß möglich sein. Interferenz mit dem Weckmechanismus muß behandelt werden.

Anf.:

Das Kommunikationssystem muß ein synchronisiertes Systemherunterfahren ohne Fehleranzeigen unterstützen.

Taktsynchronisation
Das folgende bezieht sich auf die Taktsynchronisation der Knoten in dem Kommunikationssystem.
Anmerkung:
Die ordnungsgemäße Synchronisation der einzelnen Takte der Kommunikationssteuerung ist eine Vorbedingung für das TDMA-Kommunikationsschema.

Die folgende Beschreibung bezieht sich auf den FlexRay-Taktsynchronisationsmechanismus (auf der Basis des fehlertoleranten Mittelpunkt-Algorithmus). Reines dynamisches System

Anf.:

Bei einem reinen dynamischen Betrieb wird die Taktsynchronisation von einem Master (SOC) durchgeführt.

Reines statisches und gemischtes System

Anf.:	Die globale Zeit ist ein Vektor von zwei Werten. Globale Zeit = < cycle_counter, cycle_time >.
Anf.:	Die Zykluszeit ist ein in Einheiten von Makroticks inkrementierter Zähler. Die Zykluszeit wird am Anfang jedes Kommunikationszyklus auf 0 zurückgesetzt.
Anf.:	Der Makrotick definiert die Auflösung der globalen Zeit in einem Cluster. In realistischen Konfigurationen muß eine Auflösung von 1 μs erzielbar sein.
Anf.:	Der Makrotick soll von der Oszillatorfrequenz unabhängig sein.

Anmerkung:
Bei der Implementierung ist jeder (lokale) Makrotick ein ganzzahliges Vielfaches des (lokalen) Taktticks, d.h. hängt von der Oszillatorfrequenz ab, aber die Faktoren zweier verschiedener Makroticks können verschieden sein, so daß über einen Zyklus hinweg Unabhängigkeit erzielt werden kann.

Anf.: Der Mikrotick definiert die Genauigkeit der Taktdifferenzmessung. Für den Mikrotick ist eine Auflösung von <= 50 ns erforderlich.
Anmerkung:

Typische Automotive-Anwendungen erfordern eine Auflösung von 50 Nanosekunden. Für Systemkonfigurationen mit niedriger Bandbreite sind höhere Werte annehmbar.

Anf.:

Der Taktsynchronisationsmechanismus muß in der Lage sein, alle fehlerfreien Steuerungen innerhalb der Präzision zu halten. Eine Taktsynchronisationspräzision innerhalb der verschiedenen Steuerungen von mehr als 1 Mikrosekunde ist erforderlich.

Anmerkung:

Typische Automotive-Anwendungen erfordern eine Präzision von 1 Mikrosekunde. Für Systemkonfigurationen mit niedrigeren Präzisionsanforderungen sind höhere Werte annehmbar.

Anf.:	Der Absolutwert der globalen Zeit muß in jeder Steuerung innerhalb der durch die Präzision definierten Grenzen derselbe sein. Während des Herauffahrens bestimmt der erste sendende Knoten den Wert der globalen Zeit.
Anf.:	Die Fehlertoleranz des Taktsynchronisationsmechanismus muß mit der Anzahl von Steuerungen skalierbar sein. Das Niveau der Fehlertoleranz hängt von der Anzahl tatsächlicher Knoten in dem System ab (3k + 1 zum Tolerieren von k asymmetrischen Fehlern). In einer reduzierten fehlertoleranten Konfiguration von weniger als vier Steuerungen (z.B. 2 oder 3 in einem degradierten Betriebsmodus) muß die Synchronisation möglich sein. Bei 4 bis 6 Steuerungen muß der Taktsynchronisationsmechanismus gegenüber 1 (asymmetrischem) Fehler fehlertolerant sein. Bei 7 oder mehr Steuerungen muß der Taktsynchronisationsmechanismus gegenüber 2 (asymmetrischen) Fehlern fehlertolerant sein.
Anf.:	Der Taktsynchronisationsmechanismus muß die Bildung von Klicken mit verschiedenen Zeitbegriffen innerhalb des Netzwerks verhindern.
Anf.:	Der Taktsynchronisationsmechanismus muß in der Lage sein, mit Oszillatoren zu arbeiten, die Automotive-Qualität besitzen. Insbesondere muß der Taktsynchronisationsmechanismus in der Lage sein, die physikalischen Phänomene (Drift, Verschlechterung) zu behandeln, die während der Lebensdauer eines Kraftfahrzeugs auftreten können.

Anf.:	Eine Teilmenge von Steuerungen muß so konfiguriert sein, daß sync-Rahmen (ein Rahmen mit einem gesetzten sync-Bit) gesendet werden. Bei einem Doppelkanalsystem dürfen nur mit beiden Kanälen verbundene Steuerungen zu dieser Teilmenge gehören.
Anf.:	Nur ein statischer Sendeschlitz jeder Steuerung darf zu dem Taktsynchronisationsmechanismus beitragen, d.h. eine Steuerung darf höchstens einen sync-Rahmen pro Kommunikationszyklus senden.
Anf.:	Nur korrekt empfangene sync-Rahmen werden für die Taktsynchronisation benutzt.
Anf.:	Jeder Knoten muß alle verfügbaren sync-Rahmen zur Taktsynchronisation benutzen.
Anf.:	Die Taktsynchronisation und die Implementierung der Taktsynchronisation sollen gegenüber Entwurfsverstößen, die sich aus der Umgebung oder möglichem Mißbrauch ergeben, so robust wie möglich sein.

Funktionsprinzip

Das folgende bezieht sich auf das Funktionsprinzip. Erhalten der Zeitwerte

Anf.:

In dem statischen Segment mißt jeder Knoten die Zeitdifferenz zwischen der tatsächlichen Empfangszeit und der erwarteten Empfangszeit für die sync-Rahmen mit einer Auflösung von einem Mikrotick.

Anf.:	Diese Zeitdifferenzmessung geschieht für alle Kanäle.
Anf.:	Ein Fenster des Rahmenstarts (SOF) wird um die erwartete Empfangszeit eines SOF herumgelegt. Die Länge des Empfangsfensters ist gleich der Länge des SOF-Fensters.
Anf.:	Zeitwerte werden nur für korrekte Rahmen erhalten.

Anmerkung

Man beachte, daß einer der Gründe dafür, daß ein Rahmen als falsch angesehen wird, ein Empfang außerhalb des Empfangsfensters ist. Die strenge Anwendung des Empfangsfenstermechanismus stellt sicher, daß Synchronisationsfehler von Knoten detektierbar sind. Meßmethode

Anf.:

Die Messungder Taktabweichungen geschieht durch Messen der Differenzen zwischen der erwarteten Ankunftszeit und der tatsächlichen Ankunftszeit. Die erwartete Ankunftszeit eines Rahmens wird durch die interne Sicht der Zykluszeit definiert.

Synchronisationsalgorithmus
Das folgende bezieht sich auf den Synchronisationsalgorithmus.

Anf.: Der Synchronisationsalgorithmus verwendet einen fehlertoleranten Mittelpunkt-Algorithmus (FTM), der mit einer beliebigen Anzahl von Steuerungen arbeitet.
Anmerkung, Beschreibung des FTM:
Die gemessenen Werte werden sortiert, und die k größten und kleinsten Werte werden verworfen. k wird dynamisch so angepaßt, daß mindestens zwei gemessene Werte verbleiben.

Der größte und der kleinste der übrigen Werte werden für die Berechnung des Mittelpunktwerts, d.h. des Mittelwerts der beiden Werte ausgewählt. Der resultierende Wert in einem Knoten beschreibt die Abweichung des eigenen Takts von der globalen Zeitbasis und dient als ein Korrekturterm.

Anf.:	Die resultierenden Korrekturterme sollen für Fehlerdetektion der Kommunikationssteuerung verwendet werden. Wenn der Korrekturterm nicht angewandt werden kann, muß dem Host ein Fehler signalisiert werden.
Anf.:	Der im vorherigen Schritt berechnete Korrekturterm bzw. die im vorherigen Schritt berechneten Korrekturterme sollen auf den lokalen Takt angewandt werden.
Anf.:	Wenn gleich viel oder mehr als die Hälfte der Rahmen außerhalb des Empfangsstartfensters empfangen werden, wird dem Host ein Synchronisationsfehler angezeigt. Der Synchronisationsfehler ist ein fataler Fehler, den die Steuerung reintegrieren muß.

Anmerkung:
Dieser Mechanismus verhindert die Bildung von Klicken.
Externe Synchronisation
Das folgende bezieht sich auf die externe Synchronisation

Anf.: Externe Synchronisation muß unterstützt werden.
Anmerkung:

Externe Synchronisation ist für die Synchronisation eines FlexRay-Netzwerks mit einer externen Zeitreferenz, z.B. einem GPS-Empfänger oder einem DCF77-Empfänger, oder zum Synchronisieren mehrerer FlexRay-Netzwerke notwendig.

Anf.:	Jede Steuerung kann dem berechneten Taktkorrekturterm bzw. den berechneten Taktkorrekturtermen zusätzliche externe Taktkorrekturterme hinzufügen.
Anf.:	Der resultierende Taktkorrekturterm bzw. die resultierenden Taktkorrekturterme sollen nicht größer als der maximale zulässige Korrekturterm bzw. die maximalen zulässigen Korrekturterme oder kleiner als der minimale zulässige Term bzw. die minimalen zulässigen Terme sein. Die Kommunikationssteuerung soll den angewandten Korrekturterm bzw. die angewandten Korrekturterme auf zulässige Werte beschränken.
Anf.:	Der Host soll in der Lage sein, den aktuellen (lokalen) Korrekturterm bzw. die aktuellen (lokalen) Korrekturterme (aktueller Taktwert) zu lesen und den externen Korrekturterm bzw. die externen Korrekturterme zu setzen:
Anf.:	Ein Hardware-Eingangssignal an der Kommunikationssteuerung zur externen Synchronisation ist erforderlich.

Anf.:

Das Hardware-Eingangssignal sollmit dem internen Soft-Rücksetzen der Steuerung verbunden sein. Es soll möglich sein, die Steuerung zu einem spezifischen Zeitpunkt durch den Host aus dem Soft-Rücksetzen freizugeben.

Unterstützung von Anwendungsvereinbarungsprotokollen

Anf.:

Das Protokoll muß die Realisierung von Anwendungsvereinbarungsprotokollen unterstützen. Dazu ist es notwendig, daß mehrere Sendeschlitze Übereinkunft in einem Kommunikationszyklus erzielen.

Unterstützung des Netzwerk-Managements

Anf.:	Unterstützung von synchronem verteiltem Anwendungs-Herauffahren und -Herunterfahren mit annehmbaren Zeitsteuerungs- und Fehlertoleranzeigenschaften.
Anf.:	Unterstützung von Knoten- und Netzwerkbetriebsarten mit hoher Sicherheit gegenüber kritischen unbeabsichtigten Modusänderungen.

Hardwarespezifikation
Der folgende Teil der Beschreibung erläutert die hardwarebezogenen Anforderungen für ein FlexRay-System.
Allgemeine Anforderungen

Mit Bezug auf die Kommunikationshardware muß ein verteiltes System von FlexRay-Knoten bestimmte Eigenschaften anbieten, wenn es durch Verwendung aktiver Sterne und passiver Busse entworfen wird:

Anf.:	Es müssen ein- und zweikanalige Lösungen unterstützt werden.
Anf.:	Es muß eine elektrische und eine physische Schicht unterstützt werden.
Anf.:	Die Kommunikation über redundante physische Verbindungen ist optional. Das Kommunikationssystem muß sowohl Kommunikation über redundante als auch über nichtredundante physische Verbindungen unterstützen. Eine Mischung von redundanten und nichtredundanten physischen Verbindungen muß unterstützt werden.
Anf.:	Bei Verwendung aktiver Sterne müssen mehrere 1:1-Verbindungen verwendet werden.
Anf.:	Das Aufwecken von Knoten und Sternen über das Kommunikationssystem muß unterstützt werden. Signalisierung auf einem Kanal reicht für das Aufwecken aus.
Anf.:	Eine Baudrate von 500 kbit/s bis zu 10 Mbit/s muß unterstützt werden.
Anf.:	Es muß ein Power-Mode-Management unterstützt werden.

Topologie

Anf.:	Das Protokoll muß so weit wie möglich von der Topologie unabhängig sein. Es müssen gemischte und homogene Systemtopologien unterstützt werden.
Anf.:	Es muß ein FlexRay-Netzwerk möglich sein, das einen passiven Bus verwendet (siehe Figur 114).

Anf.:	Es muß ein FlexRay-Netzwerk möglich sein, das einen passiven Stern verwendet.
Anf.:	Es muß ein FlexRay-Netzwerk möglich sein, das einen aktiven Stern verwendet (siehe Figur 113).
Anf.:	Unterstützung für verschiedene Topologien bzw. physische Schichten auf verschiedenen Kanälen ist wünschenswert.
Anf.:	Unterstützung für verschiedene physische Schichten auf einem Kanal ist wünschenswert.
Anf.:	Ein verteiltes System von FlexRay-Knoten kann durch Kombinieren des Aktiv-Stern- und des Passiv-Bus-Ansatzes (siehe Figur 115) entworfen werden. Es können mehrere Knoten mit einem Zweig verbunden werden.
Anf.:	Jeder Knoten muß sich an die folgenden Anforderungen halten (siehe Figur 103):
Anf.:	In einem Knoten müssen 1 oder 2 Bustreiber mit einer einzigen Kommunikationssteuerung verbunden sein.

Jeder aktive Stern muß sich an die folgenden Anforderungen halten (siehe 116):

Anf.: Es wird von keiner Kommunikationssteuerung gefordert, die Sternfunktionalität durchzuführen.

Anf.: Es wird von keinem Host gefordert, die Sternfunktionalität durchzuführen.
Anmerkung:

Eine Implementierung kann den Stern in eine ECU integrieren.

Anf.:	Ein Zweig eines aktiven Sterns muß deaktiviert werden, wenn ein fehlerhaftes Kommunikationssignal erkannt wird: 1) permanente „0" auf dem Bus oder 2) permanente „1" auf dem Bus oder 3) permanentes Rauschen auf dem Bus.
Anf.:	Ein deaktivierter Zweig darf die Kommunikation der aktiven Module nicht beeinflussen (Ausfall-Stille).
Anf.:	Ein deaktivierter Zweig muß wieder aktiviert werden, wenn die Ausfallbedingung, die zu einem fehlerhaften Kommunikationssignal führt, nicht mehr verfügbar ist.

Automotive-Einschränkungen
Das Kommunikationssystem gemäß der vorliegenden Erfindung kann in fast jeder Umgebung verwendet werden. Vorzugsweise wird es jedoch in Fahrzeugen beliebiger Art verwendet, insbesondere in Sicherheitskritischen Anwendungen im Automotiv-Sektor. In diesem Fall muß das Kommunikationssystem die folgenden Automotive-Einschränkungen erfüllen:

Anf.: FlexRay-Einrichtungen müssen Automotive-Temperaturanforderungen genügen.
Anmerkung:

Allgemeine Temperaturanforderungen enthalten einen Bereich von –40 bis +125 Grad Celsius. Spezielle Anwendungen können höhere Temperaturen erfordern, z.B. in der Nähe von Bremsen-Betätigungselementen.

Anf.:

Jedes Produkt muß optimiert werden, um den Automotive- und rechtlichen EMC-Anforderungen zu entsprechen. Externe Filter sind möglicherweise nicht erforderlich, können aber eventuell verwendet werden.

Anmerkung:
Aufgelistete Strengegrade, so wie sie genannt wurden, werden bei Verwendung eines passiven Busses nicht erreichbar sein.

Anf.: Der Stromverbrauch während des Normalbetriebsmodus und des Low-Power-Modus muß minimiert werden.
Anmerkung:
Typische Werte werden in der folgenden Tabelle 1 angegeben:

Tabelle 1: Typischer Stromverbrauch.

Anf.: Die Spannungsversorgung für die Kommunikationssteuerung sollte dieselbe wie für im Handel erhältliche ECUs sein.
Anmerkung:

Heutzutage unterstützen die meisten ECUs 5 V. Für Optimierungen sind z.B. 3 V zulässig.

Anf.:

Alle Eingänge und Ausgänge des Bustreibers und der Kommunikationssteuerung, die direkt an den Kabelbaum angekoppelt sind, müssen auf die bekannten elektrischen Anforderungen passen. Die Unterstützung zukünftiger hoher Versorgungsspannungen (36/42 V anstelle von 12 V) muß unterstützt werden.

Architektur – Power Modes

Dieser Teil der Beschreibung faßt die Zusammenfassungen bezüglich der Kommunikationssteuerung und des Bustreibers zum Betreiben einer ECU in mehreren Betriebsarten zusammen.

Anf.:	Die Power Modes der ECU müssen gegenüber Steuersignalen von dem Host und Wecksignalen von dem Übertragungsmedium aus der ECU intern (z.B. aus dem Host) und wahlweise aus der ECU extern (z.B. durch einen Schalter) empfindlich sein.
Anf.:	Es müssen mindestens 3 Power Modes für Kommunikationssteuerungen und Bustreiber und Sterne unterschieden werden (siehe Tabelle 2): Normal (Spannungsregler aktiv, Kommunikation möglich) Standby (Spannungsregler aktiv, Kommunikation nicht möglich) Sleep (Spannungsregler nicht aktiv, Kommunikation nicht möglich)

Tabelle 2: Power Modes

Anf.:

Die Power Modes des aktiven Sterns müssen durch die Bustreiber automatisch gesteuert werden. Es ist nicht wünschenswert, daß ein spezieller „Aufweck" und „Herunterfahr"-Befehl zu dem Stern gesendet wird oder zusätzliche Verdrahtung erforderlich ist.

Die Kommunikationssteuerung

Das folgende bezieht sich auf die Kommunikationssteuerung:

Anf.:	Eine Kommunikationssteuerung muß eine Schnittstelle zur Verbindung mit einem Host enthalten.
Anf.:	Dem Host sichtbare Teile des Verhaltens, z.B. Anwendungssteuerung, Konfiguration, Nachrichtenbereich, Kommunikationssteuerungsstatus, Interrupts usw. müssen unter den Herstellern bestätigt und spezifiziert werden.

Anf.:	Die Zeitbasis der redundanten Kanäle muß in jedem Knoten gleich sein (z.B. durch einen einzigen Automaten).
Anf.:	Die Funktionalität der Kommunikationssteuerung muß von der Existenz eines Buswächters unabhängig sein.
Anf.:	Für eine selbständige Steuerung muß das Pinout vollständig spezifiziert und dokumentiert sein.

Zustände und Betriebsarten

Anf.:	Power-On und NOT (Power-On) müssen als mindestens unterschieden werden.
Anf.:	Die Steuerung muß außerhalb des Modus Power-On passiv sein.
Anf.:	Die Steuerung muß extern rücksetzbar sein.
Anf.:	Die Steuerung muß mindestens einen Low-Power-Modus unterstützen.
Anf.:	Die Steuerungsbetriebsarten müssen gemäß den Bustreiberbetriebsarten definiert sein.

Logikleitungsoperation auf dem Kommunikationsmedium (z.B. Bus)

Anf.:

Es müssen mindestens die folgenden Informationen unterschieden werden:

Bus belegt: Daten oder SOC-Symbol werden übertragen. Bus läuft leer.

Anf.:	Die Codierungs-/Decodierungsmethode muß sowohl optische als auch elektrische
	Kommunikationsnetze ermöglichen. Es muß mindestens eine Methode unterstützt werden: NRZ (Non Return to Zero) in dem Codierungsschema der physischen Schicht (siehe byteflight-Spezifikation).
Anf.:	Bit-Sampling muß gegenüber im Innern von Fahrzeugen, z.B. Signalverzögerung, Flankenjitter, Baudraten-Jitter, robust sein.
Anf.:	Bit-Sampling muß in der Lage sein, z.B. mit Temperaturschwankungen oder Toleranzen elektrischer und physikalischer Parameter fertigzuwerden.

Optischer Treiber

Anf.:

Siehe die byteflight-Spezifikation.

Der elektrische Bustreiber

Anf.:	Für einen Bustreiber muß das Pinout vollständig spezifiziert und dokumentiert sein.
Anf.:	Für redundante Konfigurationen muß eine Implementierung gewählt werden, die die Wahrscheinlichkeit von Gleichtaktausfällen beider Bustreiber (→ jede redundante Kommunikation ist gestört) gewählt werden.

Anmerkung:
Zwei Bustreiber zur Unterstützung einer redundanten Kommunikation durch eine einzige Kommunikationssteuerung werden möglicherweise nicht auf einem einzigen Chip implementiert.

Zwei Bustreiber zur Unterstützung einer redundanten Kommunikation durch eine einzige Kommunikationssteuerung können in ein Gehäuse integriert werden, wenn ein etwaiger Gleichtaktausfall ausgeschlossen werden kann.

Anf.:	Der Bustreiber muß wahlweise Statusinformationen und Diagnoseinformationen bereitstellen, die von jeder μ-Steuerung gelesen werden können.
Anf.:	Der Bustreiber muß vor elektrischer Überspannung und Kurzschlüssen geschützt sein.

Spannungsüberwachung

Anf.:	Der Bustreiber muß die Batteriespannung überwachen und muß Statusinformationen bereitstellen.
Anf.:	Der Bustreiber muß eine unterbrochene Verbindung mit der Batterie erkennen und muß Statusinformationen bereitstellen.

Zustände und Betriebsarten

Der Bustreiber muß mehrere Zustände oder Betriebsarten unterstützen:

Anf.:	Power-On und NOT (Power-On) müssen unterschieden werden – permanente Stromversorgung – Reglerspannung
Anf.:	Der Bustreiber muß mindestens zwei Low-Power-Betriebsarten unterstützen.

Anf.:	Der Bustreiber muß in der Lage sein, einem externen Spannungsregler einen internen Power-Down-Modus zu signalisieren.
Anf.:	Der Bustreiber muß einen „Herunterfahrmodus" unterstützen – dieser Modus muß von gesicherten Mechanismen auf Bedarf des Host erreicht werden – dieser Modus darf nur durch ein Herunterfahren zurückgelassen werden – der Bustreiber muß passiv sein und muß dem Spannungsregler signalisieren, auszuschalten.
Anf.:	Die Buspegel müssen automatisch durch den Bustreiber gewählt werden, um etwaige Netzweite Herunterfahr-Betriebsarten zu unterstützen.

Buswächter

Anf.:	Das Ausfallen einer Kommunikationssteuerung im Zeitbereich, z.B. eine Kommunikationssteuerung sendet in einem Zeitschlitz, in dem sie nicht senden darf, muß durch einen Buswächter verhindert werden. Die Wahrscheinlichkeit für Gleichtaktausfälle im Zeitbereich, die sich sowohl auf die Kommunikationssteuerung als auch auf den Buswächter auswirken, muß klein genug sein.
Anf.:	Der Buswächter muß die statischen Schlitze (Steuerung) voreinander schützen. In dem dynamischen Segment gewährt der Buswächter allen Steuerungen Zugriff auf den Bus.

Anmerkung:
Einer der Hauptgründe für einen Fehler im Zeitbereich ist ein fehlerhafter interner Zustand, der zu einem falschen (Zeitsteuerungs-) Zugriff auf das Kommunikationsmedium führt.

Anf.: Der Buswächter muß in der Lage sein, Fehler in der physischen Taktquelle zu erkennen, sowie Fehler in der internen Repräsentation der Zeitbasis der Kommunikationssteuerung.
Anmerkung:
Einer der Hauptgründe für einen Fehler im Zeitbereich ist ein Fehler in der Taktquelle der Kommunikationssteuerung. Daher muß sich der Taktquellenprüfmechanismus des Buswächters auf die hauptsächlichen physikalisch möglichen Ausfallarten der Taktquelle der Kommunikationssteuerung konzentrieren.

Der Buswächter kann seine eigene Taktquelle besitzen. Zwei Buswächter, die mit derselben Kommunikationssteuerung verbunden sind, können dieselbe Taktquelle benutzen.

Anf.:	Der Buswächter darf nicht den Zugriff auf mehr als einen Kanal sperren, d.h. es ist ein Buswächter pro Kanal erforderlich.
Anf.:	Es muß möglich sein, den Buswächter als eine selbständige Schaltung zu implementieren. Diese Schaltung muß mit den bekannten vorbekannten physischen Schichten kombinierbar sein.

Anmerkung:

Der Buswächter könnte in dem Bustreiber integriert werden. Die Schnittstelle(n) in Richtung der Kommunikationssteuerung (und des Bustreibers) muß bzw. müssen definiert werden.

Anf.:	Es muß möglich sein, den Buswächter als selbständige Schaltung in dem Sternkoppler zu verbinden. Diese Schaltung muß mit der vorbekannten physischen Schicht in Wechselwirkung treten.
Anf.:	Der Buswächter muß die korrekte Freigabe der Treiberausgangsstufe prüfen.
Anf.:	Der Mechanismus des Trennens der Kommunikationssteuerung von dem Kommunikationsmedium muß geprüft werden. Mindestens einmal pro Ansteuerzyklus (Einschalten/Ausschalten) reicht aus.
Anf.:	Der Buswächter wird über eine Konfigurationsdatenschnittstelle konfiguriert.
Anf.:	Der Buswächter muß die Bustreiberausgangsstufe abhängig von einem vordefinierten Zeitsteuerungsmuster freigeben und sperren. Wenn der Buswächter einen Fehler in dem Zeitsteuerungsmuster der Kommunikationssteuerung erkennt, sperrt er den Zugriff auf das Kommunikationsmedium permanent und signalisiert dies.
Anf.:	Wenn ein Fehler in dem Buswächter auftritt, darf der Kommunikationskanal nicht gestört (monopolisiert) werden.
Anf.:	Die Konfigurationsdatenschnittstelle muß spezifiziert und dokumentiert werden. Dazu gehört hauptsächlich der logische Inhalt des Zeitsteuerungsmusters.

Aufwecken

Anf.:	Es müssen mehrere Aufweckmechanismen in Betracht gezogen werden.
ECU →	Bustreiber
Anf.:	Der Bustreiber muß durch eine beliebige Quelle innerhalb oder außerhalb der ECU (lokales Aufwecken) aufgeweckt werden.
Anf.:	Das Wecken muß flankenabhängig sein.

Beispiel: z.B. Flanke an einem Aufweck-Anschluß des Bustreibers

Bus →	Bustreiber
Anf.:	Vom Standpunkt des Host aus gesehen ist sowohl für elektrische als auch für optische Systeme ein allgemeiner Aufweckmechanismus erforderlich.
Anf.:	Der Bustreiber sollte über Standardkommunikation (Nachrichtenmuster) aufgeweckt werden.
Anf.:	Der Aufweckdetektor muß robust gegenüber Störungen in Fahrzeugen, wie zum Beispiel Gleichtaktsignalen durch Emission, sein.
Anf.:	Der Bustreiber darf nicht durch irgendwelches Rauschen aufgeweckt werden.
Bustreiber →	Steuerung
Anf.:	Der Bustreiber muß die Steuerung durch ein beliebiges Signal auf der Schnittstelle aufwecken. Es ist keine spezielle Aufweckleitung erforderlich.

Beispiel: z.B. Flanke an dem Empfangsanschluß (Rx), die durch den Bustreiber erzeugt wird

Bustreiber →	Stromversorgung
Anf.:	Der Bustreiber muß seinen Sleep-Zustand signalisieren, z.B. zur Steuerung des Spannungsreglers.

Beispiel: Signal sperren

Steuerung →	Bustreiber
Anf.:	Die Steuerung muß in der Lage sein, den Bustreiber durch ein beliebiges Signal auf der Schnittstelle aufzuwecken. Es ist keine spezielle Aufweckleitung erforderlich.

Beispiel: Flanke an dem Sendeanschluß (Tx) Selektives Sleep

Anf.:

Die Realisierung eines selektiven Sleep muß unterstützt werden.

Schnittstellen

Das folgende bezieht sich auf die in einem Knoten des Kommunikationssystems bereitgestellten Schnittstellen:
Die Schnittstellen zwischen den einzelnen Modulen (Host, Steuerung, Bustreiber, Buswächter und Stromversorgung) müssen zwischen den Herstellern gemäß den in der vorliegenden Schrift definierten allgemeinen Anforderungen vereinbart werden. 117 zeigt eine Übersicht über alle Schnittstellen. Kommunikationssteuerung ⇔ Hostschnittstelle (CHI) Allgemeine Anforderungen

Anf.:	Die Konfigurationsdaten der Kommunikationssteuerungen müssen gegen unbeabsichtigten Zugriff und unbeabsichtigte Modifikationen sicherbar sein (z.B. durch Soft-Rücksetzen).
Anf.:	Schutz vor nicht ordnungsgemäßer Hostmodifikation von BG- und CC-Konfigurationsdaten.
Anf.:	Die Schnittstelle zwischen dem Host und der Kommunikationssteuerung sollte als eine 16-Bit-Schnittstelle implementiert werden (wählbare gemultiplexte bzw. nicht gemultiplexte Busschnittstelle).
Anf.:	Funktionale Kompatibilität zwischen verschiedenen Herstellern muß auf der CHI-Ebene garantiert sein.
Anf.:	Die CHI muß in Sende- und spezielle Empfangspuffer und Empfangspuffer mit FIFO-Verhalten (first-in, first-out) konfigurierbar sein.
Anf.:	Wenn die FIFO-Warteschlange voll ist und neue Daten ankommen, werden die ältesten Daten überschrieben. Die FIFO-Warteschlange muß ein Diagnosebit setzen, wenn Daten in dem Puffer überschrieben werden.
Anf.:	Für die Rahmenübertragung wird MSB-(höchstwertiges Bit/Byte) zuerst verwendet.

Anmerkung:
Der Statusbereich der CHI enthält Kommunikationssteuerungs-Statusfelder, die durch die Steuerung geschrieben werden und die der Host nur lesen kann. Die Statusfelder werden in der Protokollspezifikation und in der Schnittstellenspezifikation definiert.
Der Steuerbereich in der CHI enthält Felder, die es dem Host erlauben, das Verhalten der Kommunikationssteuerung zu steuern. Die Steuerfelder werden in der Protokollspezifikation und in der Schnittstellenspezifikation definiert.

Der Nachrichtenbereich in der CHI enthält einen Speicherbereich, in dem die zu sendenden bzw. zu empfangenden Rahmen zusammen mit Statusinformationen für jeden Rahmen gespeichert werden. Das Layout dieses Speicherbereichs wird in den Konfigurationsdaten jeder Kommunikationssteuerung bestimmt. Die Nachrichtenpuffer-Statusfelder werden in der Protokollspezifikation und in der Schnittstellenspezifikation definiert.

Anf.:	Unterstützung von Verfolgbarkeit von Fehlern auf System- und Komponentenebene zum Identifizieren von Ursachen von Ausfällen.
Anf.:	Die Hardwareimplementierung sollte verifizieren, daß nur eine Kombination von Rahmen-ID und sync-Bit für die Übertragung als gültig betrachtet wird.

Rahmenfilterung und -maskierung

Anf.:

Nachrichtenempfang, jeder Nachrichtenpuffer muß einen Kanal, eine Rahmen-ID und einen Zykluszähler enthalten, die zur Nachrichtenfilterung benutzt werden. Wahlweise werden die ersten beiden Datenbyte jedes Nachrichtenpuffers als Nachrichten-ID-Filter verwendet. Optionen für das Filtern: 1) Rahmen-ID + Kanal 2) Rahmen-ID + Zykluszähler + Kanal 3) Nachrichten-ID + Zykluszähler + Kanal

Anmerkung:
Filterung: Filterung von Nachrichten bedeutet, daß für jeden Nachrichtenpuffer die Rahmen-ID, der Zykluszählwert und die Nachrichten-ID Parameter sind, die definieren, in welchem Nachrichtenpuffer die korrekt empfangene Nachricht (korrekte CRC, Zeit, usw.) gespeichert ist, oder ob die Nachricht verworfen wird.

Anf.: Es muß mindestens ein Maskenregister pro Kommunikationssteuerung und Kanal geben, das alle Kombinationen von Maskierung erlaubt.
Anmerkung:

Maskierung: Maskierung von Nachrichtenfiltern bedeutet, daß bestimmte der Filterparameter (Teile davon) dafür konfiguriert werden können, verworfen zu werden (setzen auf „don't care").

Anf.:

Nachrichtenübertragung, Filterparameter für die Übertragung sind Rahmen-ID und Zykluszähler; für die Rahmen-ID ist keine Maskierung möglich. Jeder Sendepuffer besitzt seine eigene Maske für den Zykluszähler.

Interrupts

Anf.:	Der Hostcomputer muß in der Lage sein, verschiedene Interrupts von der Kommunikationssteuerung anzufordern: mindestens einen Lese-Interrupt (Puffer), einen Schreib-Interrupt (Puffer), 2 unabhängige Timer-Interrupts.
Anf.:	Timer-Interrupt: Der Host kann an jedem beliebigen absoluten Punkt in der globalen Zeit (über Kommunikatioszyklusgrenzen hinweg) einen Zeit-Interrupt anfordern.
Anf.:	Für eine selbständige Steuerungsimplementierung ist eine Interrupt-Leitung erforderlich.
Anf.:	Interrupts können auf eine oder mehrere Interrupt-Leitungen in einer integrierten Steuerung abgebildet werden.

Host ⇔ Buswächterschnittstelle

Anf.:	Die Buswächterkonfigurationsdaten werden während des Herunterladens geschrieben und dann in einem lokalen Speicher des Buswächters gespeichert.
Anf.:	Während des normalen Betriebs ist kein Konfigurationsdatentransfer von dem Host zu dem Buswächter zulässig.
Anf.:	Der Buswächter aktualisiert periodisch ein Statusfeld, auf das die Host-/Buswächterschnittstelle zugreifen kann und das mindestens die folgenden Statusinformationen enthält:

Zustand des Busses Zustand der Steuerung Kommunikationssteuerung ⇔ Buswächterschnittstelle

Anf.:

Es sind mindestens die folgenden Steuerinformationen erforderlich:

ARM-Signal Kommunikationssteuerung ⇔ Bustreiberschnittstelle

Anf.:

Diese Schnittstelle muß zwischen Herstellern bestätigt werden.

Beispiel:

Tx, TxEnable (TxEN)
Rx, RxEnable (RxEN)
Buswächter ⇔ Bustreiberschnittstelle Bustreiber ⇔ Stromversorgungsschnittstelle

Anf.: Um die Aufweck- und Sleep-Funktionalität durchzuführen, ist eine Schnittstelle zwischen Bustreiber und Stromversorgung erforderlich.

Fehlerbehandlung
Das folgende bezieht sich auf die Fehlerbehandlung.
Das Kommunikationssystem und seine Komponenten sollen angemessene Fehlermanagement-Mechanismen anbieten, um Fehler zu behandeln, die aus den folgenden Ebenen entstehen:

• Medium
• Bit (Codierung)
• Rahmen
• Daten
• Topologie und
• Zeit.

Das Kommunikationssystem soll ferner dem Hostcomputer mit Bezug auf Ausfälle von Steuerung, Bus (Kanal) und der ankommenden/abgehenden Verbindung Diagnoseinformationen anbieten. Anforderungen

Anf.: Das Fehlermanagement soll der Philosophie „niemals aufgeben" folgen.
Anmerkung:
Das heißt, daß das Kommunikationsprotokoll einen ordnungsgemäßen Betrieb unterstützen muß, bis bestimmte kritische Fehlerzustände erreicht werden.

Anf.: Die Nichtankunft periodischer Nachrichten soll nicht unerkannt sein.
Anmerkung:

Es ist in Ordnung wenn z.B. eine periodische Nachricht ausgelassen wird, aber dies muß detektiert werden. Die Tatsache, daß eine periodische Nachricht ausgeblieben ist, sollte dem Host signalisiert werden.

Anf.:

Wenn eine periodische Nachricht ausgeblieben ist, dürfen dem Host keine zufälligen Daten gegeben werden.

Anf.:	Dateninhalt von Nachrichten (periodisch und spontan) darf durch das Kommunikationsprotokoll verändert werden.
Anf.:	Die Änderung von Dateninhalt soll dem Host signalisiert werden.
Anf.:	Nachdem ein Fehler in einem Kommunikationspartner in dem Netzwerk erkannt wurde, darf die Funktionalität der anderen Kommunikationspartner nicht beeinflußt werden.

Anmerkung:
Die korrekte Funktion darf nicht von der korrekten Funktion eines bestimmten Host, einer bestimmten Kommunikationssteuerung oder einer bestimmten Stromversorgung abhängen.

Die Kommunikationssteuerung soll die folgende Liste von Fehlern detektieren:

Anf.:	Synchronisationsfehler. Die Kommunikationssteuerung ist nicht mehr mit der globalen Zeit auf dem Bus synchronisiert.
Anf.:	Das Kommunikationsnetz muß dem Hostcomputer mit Bezug auf die Ausfälle von Bus (Kanal), ankommende bzw. abgehende Verbindung Diagnoseinformationen anbieten.
Anf.:	Das Kommunikationsnetz muß dem Hostcomputer innerhalb einer definierten maximalen Verzögerung nach dem Auftreten des Ausfalls des Diagnoseelements Diagnoseinformationen anbieten.

Anf.:

Das Kommunikationsnetz muß dem Hostcomputer keine einheitlichen und vereinbarten Diagnoseinformationen bereitstellen.

Hardwareeinheiten

Die Kommunikationssteuerung muß mindestens die folgenden Fehler detektieren:

Anf.:	Defektzeitquelle (z.B. defekter Kristall).
Anf.:	Niedrige Spannung. Die folgenden Fehler müssen von dem Bustreiber als Fehler erkannt werden:
Anf.:	Fehlerhafte Kommunikationssignale, die z.B. durch etwaiges fehlerhaftes Übertragungsmedium (defekte Leitung, Kurzschluß auf Masse, ...) verursacht werden.
Anf.:	Inkorrekte Kommunikation mit dem Host, z.B. Kommunikation über die Datenschnittstelle.
Anf.:	Inkorrekte Kommunikation mit der Kommunikationssteuerung, z.B. busblockierende Sendesignale.
Anf.:	Deaktivierter Zweig.

Schnittstellen

Anf.:

Es müssen Statusinformationen bezüglich detektierter Fehler bereitgestellt werden. Zusätzlich ist es erforderlich, daß maskierbare Interrupts für bestimmte detektierte Fehler durch den Host angefordert werden können.

Konstantendefinitionen
In dem folgenden Teil der Beschreibung werden die Konstanten für eine Anzahl von Entwurfsparametern, die in der gesamten Schrift definiert sind, auf tatsächliche Werte gesetzt. Die erwähnten Werte sind Beispiele und können durch praktisch jeden beliebigen gewünschten Wert ersetzt werden.
Tabelle 3 zeigt Kommunikationsnetzwerk-Konstanten (Min/Max).
Tabelle 3: Definition der in der gesamten Spezifikation verwendeten Konstanten.
Glossar

In dem folgenden Glossar werden einige der für die Beschreibung der vorliegenden Erfindung benutzten Begriffe definiert.

Bus	besteht aus einem oder mehreren Kanälen.
Bustreiber	Ein Bustreiber verbindet eine Kommunikationssteuerung mit einem Kanal.
Buswächter	Ein Buswächter schützt einen Kanal vor Zeitsteuerungsausfällen der Kommunikationssteuerung. Er ist deshalb mit einer Kommunikationssteuerung und einem Bustreiber verbunden. Der Buswächter muß von der Protokollkommunikationssteuerung unabhängig sein.
byteflight	Kommunikationsnetz, entwickelt von BMW AG, Motorola, ELMOS, Infineon, Siemens EC, Steinbeis Transferzentrum für Prozessautomatisierung, IXXAT (siehe www.byteflight.com)
Kanal	Ein Kanal ist eine physische Verbindung zwischen mehreren Kommunikationssteuerungen. Ein redundanter Kanal besteht aus zwei, dieselben Kommunikationssteuerungen verbindenden Kanälen.
CHI	Steuerungs-Host-Schnittstelle
Clique	Menge von Kommunikationssteuerungen mit derselben Sicht von bestimmten Systemeigenschaften, z.B. dem globalen Zeitwert oder dem Aktivitätszustand von Kommunikationssteuerungen.

Cluster	innerhalb der vorliegenden Spezifikation gleichbedeutend mit Netzwerk.
Cluster-Zeit	dasselbe wie Zykluszeit.
Kommunikationssteuerung	eine Kommunikationssteuerung ist mit einem oder zwei Kanälen verbunden, zu dem bzw. denen sie Rahmen senden und von dem bzw. denen sie Rahmen empfangen kann.
Kommunikationszyklus	Periodischer Datentransfermechanismus. Struktur und Zeitsteuerung sind statisch definiert. Ein statisches und ein dynamisches Segment ermöglichen jedoch die Übertragung sowohl von Zustands- als auch von Ereignisinformationen.
Steuerung	siehe Kommunikationssteuerung.
CRC	an einen Rahmen angehängter CRC-Code.
CYCLE	Das CYCLE-Feld dient zum Senden des Zykluszählers. Der Zykluszähler wird durch die Kommunikationssteuerung am Start jedes neuen Kommunikationszyklus gleichzeitig in allen Knoten erhöht.
Zykluszähler	enthält die Nummer des aktuellen Kommunikationszyklus.
Zykluszeit	enthält die Zeit innerhalb eines Kommunikationszyklus in Einheiten von Makroticks. Dasselbe wie Cluster-Zeit.
DATA	Datenfeld in einem Rahmen.
DLC	Datenlängenfeld

Dynamisches Segment	Segment des Kommunikationszyklus, in dem Rahmen gemäß einem Minischlitzalgorithmus übertragen werden. Die Sendereihenfolge wird durch eine statisch bestimmte Kennung definiert. Kennungen mit kleineren Nummern haben gegenüber Kennungen mit höheren Nummern Priorität. Ein Kommunikationszyklus kann nur aus dem statischen Segment bestehen.
EOF	Rahmenende. Eine optische oder elektrische physische Schicht kann verschiedene Rahmenendesequenzen erfordern.
ECU	Elektronische Steuereinheit. Dasselbe wie Knoten.
EMC	Elektromagnetische Kompatibilität.
FIFO	First-In-First-Out. Puffer können so konfiguriert werden, daß sie für Rahmen als FIFO-Speicher arbeiten.
Rahmen	Ein Rahmen besteht aus allen in einem Schlitz (mit einer Kennung) auf einem Kanal übertragenen Informationen.
FTA	Fehlertoleranter Mittelwert. Der FTA ist ein fehlertoleranter Taktsynchronisationsalgorithmus, der bis zu eine vordefinierte Anzahl k böswillig fehlerhafter Takte tolerieren kann. Dieser Algorithmus basiert auf einem sortierten Array von Taktabweichungen. Der untere und der obere k-Taktabweichungswert werden verworfen.

	Aus den verbliebenen Taktabweichungswerten wird der Mittelwert berechnet und dann zur Taktkorrektur verwendet.
FTM	Fehlertoleranter Mittelpunkt. Der FTM ist ein fehlertoleranter Taktsynchronisationsalgorithmus, der bis zu eine vordefinierte Anzahl k von böswillig fehlerhaften Takten tolerieren kann. Dieser Algorithmus basiert auf einem sortierten Array von Taktabweichungen. Der untere und der obere k-Taktabweichungswert werden verworfen. Aus den verbliebenen Taktabweichungswerten wird der Mittelwert berechnet und dann zur Taktkorrektur verwendet.
Gateway	Ein Knoten kann als ein Gateway fungieren und zwei oder mehr Netzwerke verbinden.
Globale Zeit	enthält die Kombination von Zykluszähler und Clusterzeit.
Hamming-Distanz	minimale Distanz von zwei beliebigen Codewörtern in einem Code.
Host	Der Host ist der Teil einer ECU, in dem die Anwendungssoftware ausgeführt wird, und ist durch die CHI von dem Kommunikationsnetz getrennt.
ID	Die Rahmenkennung definiert die Schlitzposition in dem statischen Segment und definiert die Priorität in dem dynamischen Segment. Eine niedrigere Kennung bestimmt eine höhere

	Priorität. Die Kennung Null ist für das SOC-Symbol reserviert. Die Kennung eines Rahmens muß innerhalb eines Clusters eindeutig sein. Jede Steuerung kann eine oder mehrere Kennungen (in dem statischen und dem dynamischen Segment) aufweisen.
Kennung	siehe ID.
IFG	Lücke zwischen Rahmen.
LEN	Längenfeld eines Rahmens.
LLI	Logische Leitungsschnittstelle.
LSB	Niedrigstwertiges Bit/Byte.
MAC	Medium-Zugriffssteuerung.
Macrotick	Grundlegende Einheit der Zeitmessung innerhalb eines Netzwerks von Kommunikationssteuerungen. Der Taktsynchronisationsmechnismus garantiert, daß die Taktwerte in allen nichtfehlerhaften Steuerungen gleich sind. Die Unbestimmtheit der Taktwerte wird durch die Präzision beschränkt.
Nachricht	In einem Rahmen transportierte Anwendungsdaten. Es können mehrere Nachrichten zusammengepackt werden, um einen Rahmen zu bilden.
Microtick	Grundlegende Einheit der Zeitmessung innerhalb einer Kommunikationssteuerung zur Messung der Zeitdifferenz zwischen dem Takt der Steuerung und den Takten der anderen Kommunikationssteuerungen. Taktkorrektur erfolgt in Mikrotick-Einheiten.

MSB	Höchstwertiges Bit/Byte.
Netzwerk	Ein Netzwerk besteht aus einer Menge von Knoten (mehr als einem Knoten), die durch ein Kommunikationssubsystem verbunden werden. Netzwerke sind durch spezielle Knoten (Gateways) verbunden. Dasselbe wie Cluster.
Knoten	Ein Knoten kann eine oder mehrere Kommunikationssteuerungen enthalten. Gleichbedeutend mit ECU (elektronische Steuereinheit).
Nominale Präzision	Die nominale Präzision ist die Taktsynchronisationspräzision, die durch die lokale Taktsynchronisation eines Clusters erreicht werden kann.
NRZ	Codierungsschema der physischen Schicht des Typs Non-Return-to-Zero.
Präzision	Die Präzision ist ein Zeitintervall, das die Abweichungen zwischen lokalen Takten aller aktiven Kommunikationssteuerungen beschränkt. Wenn der Takt einer Kommunikationssteuerung um mehr als die Präzision von den Takten der anderen Steuerungen abweicht, darf er nicht mehr an der Kommunikation teilnehmen.
Schlitz	Zeitdauer, während der eine Kommunikationssteuerung auf das Kommunikationsmedium zugreifen kann.

SOC	Zyklusstart. Definiert den Start eines Kommunikationszyklus in dem reinen dynamischen Modus und den Start der Kommunikation beim Herauffahren.
SOF	Rahmenstart. Eine optische oder elektrische physische Schicht kann verschiedene Rahmenstartsequenzen erfordern.
Sternkoppler	Ein Sternkoppler ist mit einem Kanal verbunden.
Statisches Segment	Segment des Kommunikationszyklus, in dem Rahmen gemäß einem statisch definierten TDMA-Schema übertragen werden. Ein Kommunikationszyklus kann nur aus dem statischen Segment bestehen.
SYNC	Synchronisationsfeld. Dieses Feld gibt an, daß der Schlitz für Taktsynchronisation verwendet wird.
TDMA	Zeitmultiplex-Mehrfachzugriff.

Es folgt eine Beschreibung der Notation für Variablen, Konstanten und Parameter in der vorliegenden Schrift.
Tabelle 4: Benennungskonventionen
Pseudocodekonventionen
Um Funktionen und Algorithmen zu spezifizieren, werden kurze Codeabschnitte verwendet. Der Pseudocode basiert ungefähr auf der von MATLAB verwendeten Programmiersprache. Die folgende Tabelle 5 skizziert einige der Pseudocodekonventionen (Funktionen und Elemente).
Tabelle 5: Pseudocodekonventionen
Bustopologie
1 zeigt eine mögliche Topologiekonfiguration eines Kommunikationssystems 106 als Doppelbus. Ein Knoten 100 kann entweder mit beiden Kanälen A und B verbunden sein (Knoten A, C und E), nur mit Kanal A (Knoten D) oder nur mit Kanal B (Knoten B).
Ein FlexRay-Kommunikationssystem 106 kann auch ein Einzelbus sein. In diesem Fall sind alle Knoten 100 mit diesem Bus verbunden.
Sterntopologie
Gültige Sternnetzwerkkonfigurationen
Ein Flexray-Kommunikationssystem kann als eine Mehrfachsterntopologie aufgebaut werden. Ähnlich wie die Bustopologie kann die Mehrfachsterntopologie redundante Kommunikationskanäle unterstützen. Jeder Netzwerkkanal muß frei von geschlossenen Ringen sein und die Anzahl der Sternkoppler muß zwischen einschließlich 1 und cStarCouplersMax liegen, wenn sequentiell verbundene (kaskadierte) Sternkoppler vorliegen. Die Gesamtzahl der Sternkoppler kann mehr als cStarCouplersMax betragen, wenn das Netzwerk Zweige enthält. Jede Netzwerkleitung, die einen Knoten mit dem Sternkoppler verbindet oder zwischen zwei Sternkopplern repräsentiert eine ordnungsgemäß abgeschlossene Punkt-zu-Punkt-Verbindung. Das durch den Sternkoppler empfangene ankommende Signal wird aktiv an alle Kommunikationsknoten angesteuert.
2 zeigt die Konfiguration eines einzelnen redundanten Sternnetzwerks. Die logische Struktur (d.h. die Knotenkonnektivität) dieser Topologie ist mit der in 1 gezeigten identisch. Außerdem ist es möglich, eine einzige, nicht redundante Sterntopologie zu erzeugen, die dieselbe logische Struktur wie der oben erwähnte Einzelbus aufweist.
3 zeigt ein mit drei Sternkopplern aufgebautes Einzelkanalnetzwerk. Jeder Knoten besitzt eine Punkt-zu-Punkt-Verbindung mit einem der drei Sternkoppler.
Zwei der Sternkoppler (Nr. 1 und 3) sind direkt mit dem dritten Sternkoppler (Nr. 2) verbunden.
Man beachte, daß auch eine redundante Kanalkonfiguration mit kaskadierten Sternen möglich ist. 4 ist ein Beispiel für eine solche Konfiguration. Man beachte, daß dieses Beispiel nicht einfach die Menge von Sternen für den zweiten Kanal dupliziert – Stern 1A verbindet die Knoten A, B und C, während Stern 2A die Knoten A, C und E verbindet.
Sternkopplerverhalten und Protokollauswirkung
Für jeden mit einem Sternkoppler verbundenen Knoten enthält der Sternkoppler eine im Halbduplexmodus arbeitende bidirektionale Verbindung.
Vor dem Übertragen eines Rahmens müssen alle Verbindungen in jedem Sternkoppler entweder für Empfang oder Senden eingerichtet werden.
Der FlexRay-Codierungsmechanismus definiert eine Übertragungsstartsequenz (TSS), mit der ein ordnungsgemäßer Verbindungsaufbau in dem gesamten Netzwerk eingeleitet wird, bevor der eigentliche FlexRay-Rahmen bzw. das eigentliche FlexRay-Symbol übertragen wird. Die Übertragung der TSS wird von dem Sternkoppler erkannt und als Verbindungsaufbauanforderung behandelt. Der Sternkoppler kehrt zu seinem Leerlaufzustand zurück, nachdem der Bus durch den sendenden Knoten in den Leerlaufzustand freigegeben wurde.
Am Ende jeder Rahmenübertragung müssen alle Sternkoppler zu dem Anfangszustand zurückkehren, bevor die nächste Verbindungsaufbauanforderung eingeleitet wird. Dies ist notwendig, damit der Sternkoppler in der Lage ist, die nächste Konfigurationsanforderung korrekt zu verarbeiten.
Die minimale Leerlaufzeit zwischen zwei aufeinanderfolgend übertragenen Rahmen muß die Zeiten für Verbindungsaufbau und Rückkehr zum Anfangszustand für die Sternkoppler, die in dem System verwendet werden, berücksichtigen.
Hybridtopologien
Zusätzlich zu Topologien, die entweder völlig aus einer Bustopologie oder völlig aus einer Sterntopologie bestehen, sind hybride Topologien möglich, die eine Mischung von Bus- und Sternkonfigurationen sind. Das FlexRay-System unterstützt solche Hybridtopologien, solange die für jede einzelne Topologie geltenden Grenzen nicht überschritten werden. Zum Beispiel begrenzt die Grenze von cStarCouplersMax kaskadierten Sternkopplern auch die Anzahl kaskadierter Sternkoppler in einer Hybridtopologie.
Es gibt sehr viele mögliche Hybridtopologien, es sind hier aber nur zwei repräsentative Topologien gezeigt. 5 zeigt ein Beispiel für eine Art von Hybridtopologie. In diesem Beispiel sind bestimmte Knoten (Knoten A, B, C und D) unter Verwendung von Punkt-zu-Punkt-Verbindungen mit einem Sternkoppler verbunden. Andere Knoten (Knoten E, F und G) sind durch Verwendung einer Bustopologie miteinander verbunden. Dieser Bus ist auch mit einem Sternkoppler verbunden, so daß die Knoten E, F und G mit den anderen Knoten kommunizieren können.
6 zeigt eine grundsätzlich verschiedene Art von Hybridtopologie. In diesem Fall werden auf verschiedenen Kanälen verschiedene Topologien benutzt. Kanal A ist hier als eine Bustopologieverbindung implementiert, während Kanal B als eine Sterntopologieverbindung implementiert ist.
Kommunikationszyklus
Der Kommunikationszyklus ist das Grundelement des Medium-Zugriffsschemas innerhalb von FlexRay. Er wird mittels einer Zeitsteuerungshierarchie definiert.
Zeitsteuerungshierarchie
Die Zeitsteuerungshierarchie besteht aus vier Zeitsteuerungshierarchieebenen, wie in 7 gezeigt.
Die höchste Ebene, die Ebene des Kommunikationszyklus, definiert den Kommunikationszyklus. Sie enthält das statische Segment, das dynamische Segment, das Symbolfenster und die Netzwerk-Leerlaufzeit (NIT). In dem statischen Segment wird ein statisches Zeitmultiplex-Mehrfachzugriffsschema verwendet, um Übertragungen zu arbitrieren. In dem dynamischen Segment wird zum Arbitrieren von Übertragungen ein dynamisches, auf Minischlitzen basierendes Schema verwendet. Das Symbolfenster ist ein Kommunikationszeitraum, in dem ein Symbol aus einer definierten Menge von Symbolen auf dem Netzwerk übertragen werden kann. Das statische Segment, das dynamische Segment und das Symbolfenster bilden die Netzwerkkommunikationszeit (NCT), ein Zeitraum, in dem netzwerkübergreifende Kommunikation stattfindet. Die Netzwerkleerlaufzeit definiert einen kommunikationsfreien Zeitraum, der jeden Kommunikationszyklus beendet.
Die nächst niedrigere Ebene, die Arbitrierungsgitterebene, enthält das Arbitrierungsgitter, das das Rückgrat der FlexRay-Medium-Arbitrierung bildet. In dem statischen Segment besteht das Arbitrierungsgitter aus als statische Schlitze bezeichneten aufeinanderfolgenden Zeitintervallen, in dem dynamischen Segment besteht das Arbitrierungsgitter aus als Minischlitze bezeichneten aufeinanderfolgenden Zeitintervallen.
Die Arbitrierungsgitterebene baut auf der Makrotickebene auf, die durch Makrotick definiert wird. Der Makrotick wird später spezifiziert. Spezifische Makrotickgrenzen werden als Aktionspunkte bezeichnet. Diese sind fest zugeordnete Zeitpunkte, an denen Übertragungen beginnen sollen (in dem statischen Segment, dem dynamischen Segment und dem Symbolfenster) und enden sollen (nur in dem dynamischen Segment).
Die niedrigste Ebene in der Hierarchie wird durch den Mikrotick definiert, der später behandelt wird.
Kommunikationszyklusausführung
Im folgenden wird der Kommunikationszyklus für den zeitgetriggerten verteilten Modus (TT-D) und für den zeitgetriggerten mastergesteuerten Modus (TT-M) spezifiziert. Der Kommunikationszyklus für den ereignisgetriggerten Modus (ET) wird später spezifiziert. Der Kommunikationszyklus für den byteflight-Modus wird in der byteflight-Spezifikation behandelt.
Sowohl im TT-D-Modus als auch im TT-M-Modus triggert die synchronisierte Zeit die Ausführung des Kommunikationszyklus auf der Basis eines periodisch wiederauftretenden Prinzips mit einer Periode, die aus einer konstanten Anzahl von Makroticks besteht.
Die Kommunikationszyklen werden von 1 bis cCycleMax beziffert. Jeder Knoten soll einen Zykluszähler vCycle führen, der die Nummer des aktuellen Kommunikationszyklus hält. Die Initialisierung des Zykluszählers wird später spezifiziert.
8 zeigt die Ausführung des Kommunikationszyklus.
Im TT-D-Modus muß das statische Segment mindestens zwei statische Schlitze enthalten (es müssen mindestens zwei Rahmen mit dem sync-Bit gesetzt gesendet werden). Das dynamische Segment kann wahlweise auch wie das Symbolfenster existieren. Der Medium-Zugriffstest kann jedoch nur durchgeführt werden, wenn das Symbolfenster existiert.
Im TT-M-Modus muß das statische Segment genau einen statischen Schlitz enthalten (in diesem Schlitz muß ein Rahmen mit dem sync-Bit gesetzt gesendet werden). In diesem Modus muß das dynamische Segment existieren, während die Existenz des Symbolfensters optional bleibt.
Tabelle 6 faßt die Protokollbetriebsarten und die möglichen Konfigurationen des Kommunikationszyklus zusammen.
Tabelle 6: Netzwerkkommunikationszeitbestandteile gegenüber Protokollbetriebsarten
Wie bereits beschrieben, unterstützt das FlexRay-Protokoll Cluster mit einem einzigen Kommunikationskanal (nur Kanal A) oder mit zwei Kommunikationskanälen (Kanal A und Kanal B). Im Fall eines Zweikanalclusters werden die Kanäle miteinander synchronisiert. Im Zweikanalfall können Knoten entweder mit einem der Kommunikationskanäle oder mit beiden verbunden sein. Diese Topologieoptionen können frei mit dem Kommunikationszyklus kombiniert werden.
Netzwerkkommunikationszeit
Die Arbitrierung in der Netzwerkkommunikationszeit erfolgt mittels eindeutiger Rahmenprioritäten und eines Schlitzzählschemas.
Die Arbitrierung setzt voraus, daß als Rahmenkennungen bezeichnete eindeutige Rahmenprioritäten dem Rahmen unter den Knoten für jeden Kanal zugewiesen wurden (die Rahmenkennungen können entweder durch ein Offline-Konfigurationswerkzeug oder während der Laufzeit unter Verwendung einer auf Anwendung basierenden Zuweisungsstrategie zugewiesen werden. Man beachte, daß in allen Fällen die Eindeutigkeit der Rahmenkennungen pro Kanal aufrechterhalten werden muß, um eine kollisionsfreie Arbitrierung sicherzustellen). Die Rahmenkennungen sollen im Bereich von 1 bis cSlotIDMax liegen. Die Rahmenkennung bestimmt, in welchem Segment und wann in dem jeweiligen Segment ein Rahmen gesendet werden soll.
Jeder Knoten soll für jeden der beiden jeweiligen Kanäle einen Schlitzzähler vSlotCounter[ch] führen. In der Operationsphase sollen die Schlitzzähler am Start jedes Kommunikationszyklus mit 1 initialisiert werden. Die Initialisierung in der Herauffahrphase wird später spezifiziert.
Statisches Segment
In dem statischen Segment soll ein statisches Zeitmultiplex-Mehrfachzugriffsschema zum Arbitrieren von Übertragungen angewandt werden. In diesem Segment weisen alle Kommunikationsschlitze eine gleiche, statisch konfigurierte Dauer auf und alle Rahmen besitzen gleiche, statisch konfigurierte Länge.
Struktur
Das statische Segment soll aus gNumberOfStaticSlots statischen Schlitzen gleicher Dauer bestehen. Die Anzahl statischer Schlitze gNumberOfStaticSlots ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 1 bis cSlotIDMax liegen.
In jedem beliebigen gegebenen Knoten kann ein statischer Schlitz pSyncSlot so konfiguriert werden, daß er einen Synchronisationsrahmen, eine spezielle Art von Rahmen, die für die Synchronisation innerhalb des Clusters erforderlich ist, enthält. pSyncSlot ist ein knotenspezifischer Wert, der gleich der Nummer des statischen Schlitzes ist, in dem der sync-Rahmen übertragen werden soll.
9 zeigt alle Übertragungsmuster, die für einen einzelnen Knoten in dem statischen Segment möglich sind. Im Schlitz 1 sendet der Knoten einen Rahmen auf Kanal A und einen Rahmen auf Kanal B. Im Schlitz 2 sendet der Knoten einen Rahmen nur auf Kanal A (es ist auch ein Äquvivalenzmuster möglich, bei dem ein Knoten auf Kanal B einen Rahmen und auf Kanal A keinen Rahmen sendet. Verschiedene Knoten können sich wie bereits erwähnt über beide Kanäle hinweg einen statischen Schlitz teilen). Im Schlitz 3 wird auf keinem Kanal ein Rahmen übertragen.
Übertragungsbedingung
In dem statischen Segment ist die Bedingung, ob ein Rahmen übertragen werden soll oder nicht, abhängig von der aktuellen Protokollphase unterschiedlich.
In der Herauffahrphase soll ein Rahmen auf einem Kanal gesendet werden,

1. wenn der Schlitz über die Rahmen-ID und die kanalspezifische Zuweisung dem Knoten zugewiesen ist, und
2. wenn das Herauffahren die Rahmenübertragung freigegeben hat, und
3. wenn der Schlitz so konfiguriert ist, daß er einen sync-Rahmen enthält, d.h. der jeweilige Schlitzzähler mit pSyncSlot übereinstimmt.

In der Operationsphase soll ein Rahmen auf einem Kanal übertragen werden,

1. wenn der Schlitz über die Rahmen-ID und kanalspezifische Zuweisung dem Knoten zugewiesen ist, und
2. wenn sich der Steuerautomat in dem Zustand Operation befindet.

Der Rahmen soll folgendermaßen zusammengestellt werden:

1. Das reservierte Bit soll auf Null gesetzt werden.
2. Das sync-Bit soll auf Eins gesetzt werden, wenn der jeweilige Schlitzzähler vSlotCounter[ch] mit pSyncSlot übereinstimmt, andernfalls auf Null.
3. Das Netzwerkverwaltungsbit soll auf den in der CHI gehaltenen Wert gesetzt werden.
4. Das Rahmen-ID-Feld soll auf den Wert des jeweiligen Schlitzzählers vSlotCounter[ch] gesetzt werden.
5. Das Längenfeld soll auf gPayloadLengthStatic gesetzt werden.
6. Die Kopfteil-CRC soll auf den in der CHI gehaltenen Wert gesetzt werden.
7. Das Zykluszählfeld soll auf den Wert des aktuellen Zykluszählers vCycle gesetzt werden.
8. Wenn Nutzsignaldaten von der CHI für den jeweiligen Schlitz verfügbar sind, dann soll
a. das Nullrahmenanzeigebit auf Null gesetzt werden und
b. die Nutzsignaldaten auf die aus der CHI empfangenen Werte gesetzt werden und
c. etwaige verbleibende Nutzsignaldatenbyte auf das Stopfmuster 0x00 gesetzt werden.
9. wenn keine Nutzsignaldaten aus der CHI für den jeweiligen Schlitz verfügbar sind, dann soll
a. das Nullrahmenanzeigebit auf Eins gesetzt werden und
b. alle Nutzsignaldaten sollen auf das Stopfmuster 0x00 gesetzt werden.
10. Die Rahmen-CRC soll unter Verwendung der später spezifizierten Prozedur berechnet werden.

Zeitsteuerung und Schlitzzählerverwaltung
Alle statischen Schlitze sollen aus einer gleichen Anzahl von gdStaticSlot Makroticks bestehen. Die Anzahl der Makroticks pro statischem Schlitz gdStaticSlot ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 2 bis TBD liegen.
Jeder statische Schlitz enthält einen Aktionspunkt, der um gdActionPointOffset Makroticks von dem Start des Schlitzes versetzt sein soll. Die Rahmenübertragung soll an dem Aktionspunkt des jeweiligen statischen Schlitzes beginnen. Die Anzahl der Makroticks in den Aktionspunktoffset gdActionPointOffset ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 1 bis TBD liegen.
Eine angemessene Konfiguration der statischen Schlitzlänge muß sicherstellen, daß der Rahmen und das Kommunikationstrennelement in den statischen Schlitz passen.
10 zeigt die detaillierte Zeitsteuerung des statischen Schlitzes.
Am Ende jedes statischen Schlitzes sollen der Schlitzzähler für Kanal A vSlotCounter[A] und der Schlitzzähler für Kanal B vSlotCounter[A] um Eins inkrementiert werden (man beachte, daß dies auch für den letzten statischen Schlitz in dem statischen Segment gilt).
Konfiguration
Die statische Schlitzlänge gdStaticSlot soll so gewählt werden, daß nicht nur die Übertragung des Rahmens in dem statischen Schlitz untergebracht werden kann, sondern auch die Kanalleerlaufdetektionslatenz unter Annahmen des ungünstigsten Falls (der Parameter gdStaticSlot soll durch ein Offline-Konfigurationswerkzeug bestimmt werden). Die Formel zur Bestimmung dieses Parameters und jeweiliger Einschränkungen wird später spezifiziert. Auch wird die Formel für die Bestimmung des Parameters gdActionPointOffset und jeweiliger Einschränkungen später spezifiziert.
Dynamisches Segment
In dem dynamischen Segment soll ein dynamisches Schema auf Minischlitzbasis zum Arbitrieren von Übertragungen verwendet werden. In diesem Segment kann die Dauer der Kommunikationsschlitze variieren, um Rahmen verschiedener Längen unterzubringen.
Struktur
Das dynamische Segment soll aus gNumberOfMiniSlots Minischlitzen gleicher Dauer bestehen. Die Anzahl der Minischlitze gNumberOfMiniSlots ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 0 bis tbd liegen.
Das dynamische Segment besteht auch aus einer Menge aufeinanderfolgender dynamischer Schlitze, die einen oder mehrere Minischlitze enthalten. Die Dauer eines dynamischen Schlitzes hängt davon ab, ob Kommunikation, d.h. Rahmenübertragung oder -empfang, stattfindet. Die Dauer eines dynamischen Schlitzes soll kanalweise festgelegt werden.
Die Bedingung, ob Kommunikation stattfindet oder nicht, soll am Ende jedes Minischlitzes ausgewertet werden: Der dynamische Schlitz soll aus einem Minischlitz bestehen, wenn keine Kommunikation stattfindet, d.h. der jeweilige Kommunikationskanal befindet sich während des gesamten jeweiligen Minischlitzes in dem Kanalleerlaufzustand. Der dynamische Schlitz soll aus mehreren Minischlitzen bestehen, wenn Kommunikation stattfindet.
Einzelheiten darüber, wie die Dauer eines dynamischen Schlitzes für Rahmenübertragungen bestimmt wird, werden in dem nachfolgenden Teilabschnitt spezifiziert. Einzelheiten, wie dies im Fall des Rahmenempfangs bestimmt wird, werden später spezifiziert.
11 skizziert das Medium-Zugriffsschema in dem dynamischen Segment.
Wie in der Figur gezeigt, erfolgt der Medium-Zugriff auf den beiden Kommunikationskanälen nicht im Gleichschritt. Beide Kommunikationskanäle teilen sich jedoch dasselbe Arbitrierungsgitter. 11 zeigt außerdem, wie sich die Dauer eines dynamischen Schlitzes abhängig davon, ob Kommunikation stattfindet oder nicht, anpaßt.
Übertragungsbedingung
In dem dynamischen Segment hängt die Bedingung, die bestimmt, ob ein Rahmen übertragen werden soll oder nicht, von der aktuellen Protokollphase ab.
In der Herauffahrphase sollen auf keinem der Kanäle Rahmen übertragen werden.
In der Operationsphase soll ein Rahmen auf einem Kanal übertragen werden,

1. wenn der Schlitz über die Rahmen-ID und kanalspezifische Zuweisung dem Knoten zugewiesen ist, und
2. wenn das dynamische Segment pLatestTx Minischlitz, eine knotenspezifische obere Schranke, nicht überschritten hat, und
3. wenn sich der Steuerautomat in dem Zustand Operation befindet.

Der Rahmen soll folgendermaßen zusammengestellt werden:

1. Das reservierte Bit soll auf Null gesetzt werden.
2. Das sync-Bit soll auf Null gesetzt werden.
3. Das Netzwerkverwaltungsbit soll auf dem in der CHI gehaltenen Wert gesetzt werden.
4. Das Rahmen-ID-Feld soll auf den Wert des jeweiligen Schlitzzählers vSlotCounter[ch] gesetzt werden.
5. Das Längenfeld soll auf die Anzahl der Nutzsignaldatenbyte, dividiert durch zwei, gesetzt werden.
6. Die Kopfteil-CRC soll auf den in der CHI gehaltenen Wert gesetzt werden.
7. Das Zykluszählfeld soll auf den Wert des aktuellen Zykluszählers vCycle gesetzt werden.
8. Wenn Nutzsignaldaten aus der CHI für den jeweiligen Schlitz verfügbar sind, dann
a. soll das Nullrahmenanzeigebit auf Null gesetzt werden, und
b. sollen die Nutzsignaldaten auf die aus der CHI empfangenen Werte gesetzt werden und
c. sollen etwaige übrige Nutzsignaldatenbyte auf das Stopfmuster 0x00 gesetzt werden.
9. Wenn keine Nutzsignaldaten aus der CHI für den jeweiligen Schlitz verfügbar sind, dann
a. soll das Nullrahmenanzeigebit auf Eins gesetzt werden und
b. sollen alle Nutzsignaldaten auf das Stopfmuster 0x00 gesetzt werden.
10. Die Rahmen-CRC soll unter Verwendung der später spezifizierten Prozedur berechnet werden.

Zeitsteuerung und Schlitzzählerverwaltung
Die Zeitsteuerung innerhalb des dynamischen Segments basiert auf Minischlitzen. Jeder Minischlitz soll eine gleiche Anzahl von gdMinislot Makroticks enthalten. Die Anzahl der Makroticks pro Minischlitz gdMinislot ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 2 bis tbd liegen.
Jeder Minischlitz enthält einen Aktionspunkt der um gdMsActionPointOffset Makroticks von dem Start des Minischlitzes versetzt sein soll. Die Anzahl der Makroticks in dem Minischlitzaktionspunktoffset gdMsActionPointOffset ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 1 bis tbd liegen.
12 zeigt die ausführliche Zeitsteuerung eines Minischlitzes.
Die Rahmenübertragung soll an dem Minischlitzaktionspunkt des ersten Minischlitzes des jeweiligen dynamischen Schlitzes starten. In dem dynamischen Segment soll die Rahmenübertragung auch an einem Minischlitzaktionspunkt enden. Wenn der Rahmen wegen seiner Datenlänge nicht an einem Minischlitzaktionspunkt endet, soll der Sender die Übertragung unter Verwendung der dynamischen Nachspannsequenz (DTS) wie später beschrieben verlängern. Die DTS verhindert eine verfrühte Leerlaufdetektion durch die Empfänger.
Im Gegensatz zu einem statischen Schlitz unterscheidet der dynamische Schlitz zwischen der Übertragungsphase und der dynamischen Schlitzleerlaufphase. Die Übertragungsphase reicht von dem Start des dynamischen Schlitzes bis zu dem letzten Minischlitz, in dem die Übertragung endet. Die dynamische Schlitzleerlaufphase schließt den dynamischen Schlitz ab. Die dynamische Schlitzleerlaufphase wird als eine kommunikationsfreie Phase definiert, die der Übertragungsphase in jedem dynamischen Schlitz folgt. Es ist erforderlich, die Kommunikationskanal-Leerlaufdetektionslatenz zu berücksichtigen und den Rahmen durch die Empfänger zu verarbeiten.
13 zeigt die ausführliche Zeitsteuerung in dem dynamischen Segment.
Der Start des dynamischen Segments erfordert besondere Aufmerksamkeit. Der erste Aktionspunkt in dem dynamischen Segment soll nach max(gdActionpointOffset, gdMsActionPointOffset) Makroticks nach dem Ende des statischen Segments auftreten.
Die beiden möglichen Fälle sind in 14 dargestellt.
Jeder Knoten soll kanalweise Schlitzzählerverwaltung durchführen. Am Ende jedes dynamischen Schlitzes soll der jeweilige Schlitzzähler vSlotCounter[ch] um Eins inkrementiert werden, bis entweder

1. der jeweilige Schlitzzähler vSlotCounter[ch] den Wert cSlotIDMax erreicht hat oder
2. das dynamische Segment den Minischlitz gNumberOfMinislots, d.h. das Ende des dynamischen Segments, erreicht hat, oder

Nachdem eine dieser Bedingungen erfüllt ist, soll der jeweilige Schlitzzähler auf Null gesetzt werden und weitere Inkrementierungen sollen für den jeweiligen Kommunikationszyklus suspendiert werden.
Die Arbitrierungsprozedur stellt sicher, daß alle fehlerfreien Empfänger implizit über den dynamischen Schlitz, in dem die Übertragung startet, übereinstimmen. Ferner stimmen alle fehlerfreien Empfänger auch implizit über den Minischlitz überein, in dem das Schlitzzählen wiederaufgenommen wird. Folglich stimmt der Schlitzzähler aller fehlerfreien Empfänger mit dem Schlitzzähler des fehlerfreien Senders und der in dem Rahmen enthaltenen Rahmenkennung überein.
Konfiguration
Einschränkungen bezüglich der Konfiguration des dynamischen Segments werden später spezifiziert.
Symbolfenster
In dem Symbolfenster kann ein einziges Symbol gesendet werden, d.h. entweder ein normales Symbol, ein Alarmsymbol, ein Mediumzugriff-Testsymbol oder überhaupt kein Symbol soll gesendet werden. Im allgemeinen wird die Arbitrierung zwischen verschiedenen Absendern durch das Protokoll für das Symbolfenster nicht vorgesehen. Wenn Arbitrierung zwischen mehreren Absendern für das Symbolfenster erforderlich ist, muß sie mittels eines Protokolls höherer Ebene durchgeführt werden.
Struktur
Das Symbolfenster soll aus einer festen Anzahl von gdSymbolWindow Makroticks bestehen. Die Anzahl der Makroticks pro Symbolfenster gdSymbolWindow ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 0 bis TBD liegen.
Übertragungsbedingung
Wie bei den beiden Kommunikationssegmenten hängt die Bedingung, ob ein Symbol übertragen werden soll oder nicht, von der aktuellen Protokollphase ab.
In der Herauffahrphase soll auf keinem der Kanäle ein Symbol übertragen werden.
In der Operationsphase soll ein Symbol auf einem Kanal übertragen werden,

1. wenn ein Symbol für die Übertragung freigegeben ist und
2. wenn sich der Steuerautomat in dem Operation-Zustand befindet.

Einzelheiten, die spezifizieren, wann ein Symbol für die Übertragung freigegeben wird, werden später spezifiziert.
Übertragungszeitsteuerung
Das Symbolfenster enthält einen Aktionspunkt, der um gdActionPointOffset Makroticks von dem Start des Schlitzes versetzt sein soll. Die Symbolübertragung soll an dem Aktionspunkt in dem Symbolfenster beginnen (siehe 15).
Konfiguration
Einschränkungen bezüglich der Konfiguration des Symbolfensters werden später spezifiziert.
Netzwerkleerlaufzeit
In der Netzwerkleerlaufzeit sollen die Taktkorrekturen berechnet werden und der Offsetkorrekturterm soll in einem oder mehreren Makroticks angewandt werden. Einzelheiten des Taktsynchronisationsprozesses werden später beschrieben.
Die Netzwerkleerlaufzeit soll außerdem als eine Phase zur Durchführung implementierungsspezifischer clusterzyklusbezogener Aufgaben dienen.
Die Netzwerkleerlaufzeit soll gdNIT Makroticks enthalten. Die Anzahl der Makroticks in der Netzwerkleerlaufzeit gdNIT ist eine globale Konstante für ein gegebenes Cluster und kann im Bereich von 1 bis TBD liegen.
Einschränkungen bezüglich der Dauer der Netzwerkleerlaufzeit werden später spezifiziert.
Codierung und Decodierung
Im folgenden werden die Codierungs- und Decodierungsmethoden beschrieben, die das FlexRay-System benutzt.
Da das FlexRay-Protokoll von der zugrundeliegenden physischen Schicht unabhängig ist, beschreibt das folgende die Codierungs- und Decodierungsregeln der Schnittstellensignale, so wie sie von der Kommunikationssteuerung gesehen werden (d.h, TxENn, TxDn und RxDn, n ∊ {A, B} in 16). Danach werden zusätzliche Informationen über diese Schnittstelle gegeben.
Im allgemeinen gibt es mehrere nicht ideale Bedingungen (zum Beispiel Taktoszillatordifferenzen, elektrische Eigenschaften des Übertragungsmediums und von Sender/Empfängern usw.), die Schwankungen der Signalzeitsteuerung verursachen oder Anomalien/Glitches in den Kommunikationsbitstrom einführen können. Die nachfolgend beschriebenen Codierungs- und Decodierungsmechanismen sollen gegenüber solchen Effekten robust sein. FlexRay verwendet das Signalisierungsverfahren NRZ (Non-Return to Zero) zur Codierung und Decodierung von Rahmen und Symbolen.
Bitstromcodierung mit NRZ
Dieser Abschnitt spezifiziert die Mechanismen, mit denen die logischen Rahmen und Symbole zur Übertragung zu einem Bitstrom codiert werden und wie der sendende Knoten diesen Bitstrom zur Kommunikation auf das Netzwerk dem Bustreiber zuführt. Der Absender soll die Übertragung eines Rahmens oder Symbols durch Setzen des TxENn-Signals auf logisch „0" beginnen. Der Absender soll die Übertragung eines Rahmens oder Symbols durch Setzen der Signale TxENn und TxDn auf logisch „1" stoppen. Der logische Rahmen wird später beschrieben.
Rahmencodierung
Die Rahmencodierung transformiert logische Rahmen durch die folgenden Schritte in einen kontinuierlichen Bitstrom:
Aufteilen des logischen Rahmens in einzelne Bytekomponenten
Aufbauen von Bytesequenzen durch Hinzufügen einer Bytestartsequenz (BSS) am Anfang jeder Bytekomponente
Zusammenstellen eines kontinuierlichen Bitstroms aus den Bytesequenzen
Hinzufügen einer Übertragungsstartsequenz (TSS) vor dem Start des Bitstroms
Anhängen einer Rahmenendesequenz (FES) am Ende des Bitstroms
Anhängen einer dynamischen Nachspannsequenz (DTS) nach der Rahmenendesequenz, wenn der Rahmen in dem dynamischen Segment des Kommunikationszyklus übertragen wird
Bytecodierung
Jede Bytesequenz soll mit einer Bytestartsequenz (BSS) beginnen. Die BSS besteht aus einem logischen „1"-Bit, gefolgt durch ein logisches „0"-Bit. Eine Bytesequenz besteht aus einer BSS, gefolgt durch acht Datenbit aus dem logischen Rahmen.
Die Übertragung der Datenbit in einer Bytesequenz soll dergestalt sein, daß das höchstwertige Bit der Daten zuerst übertragen wird, wobei die übrigen Bit der Daten in absteigender Reihenfolge der Wertigkeit übertragen werden. Dies ist in 17 gezeigt.
Der Zweck der BSS ist die Bereitstellung von Bitstrom-Zeitsteuerungsinformationen für empfangende Einrichtungen. Die Signalflanke zwischen dem ersten und dem zweiten Bit der BSS dient zur Neusynchronisation der Bitzeitsteuerung des Empfängers (d.h. Bittaktneusynchronisation).
Übertragungsstartsequenz (TSS)
Die Übertragungsstartsequenz wird vor der ersten Bytesequenz in den Bitstrom eingefügt. Die TSS besteht aus einem kontinuierlichen logischen „0"-Pegel. Die Dauer der TSS soll zwischen 1 bis 15 nominale Bitzeiten konfigurierbar sein.
Rahmenendesequenz (FES)
Die Rahmenendesequenz (FES) wird im Anschluß an die letzte Bytesequenz an den Bitstrom angehängt. Die FES ist eine Zwei-Bit-Sequenz, die aus einem logischen „0"-Bit, gefolgt durch ein logisches „1"-Bit, besteht.
Dynamische Nachspannsequenz (DTS)
Unmittelbar nach der FES eines Rahmens, der in dem dynamischen Segment eines Kommunikationszyklus übertragen wird, soll eine dynamische Nachspannsequenz (DTS) übertragen werden. Der Zweck dieser Sequenz ist die Anzeige des exakten Zeitpunkts des Minischlitz-Aktionspunkts.
Die DTS beginnt mit einer variablen Anzahl aufeinanderfolgender logischer „0"en. Die DTS-Länge ist größer oder gleich 1 Bit. Die DTS wird mit der Übertragung eines logischen „1"-Bit abgeschlossen. Man beachte, daß die Granularität der Länge des „0"-Teils der DTS nicht Bit, sondern Mikroticks ist. Im allgemeinen ist der Nachspann-Übergang von „0" nach „1" nicht mit einer Bitzellengrenze synchron.
Der gesamte Bitstrom für einen Rahmen in dem statischen Segment
18 zeigt den gesamten Bitstrom eines in dem statischen Segment übertragenen Rahmens.
Nach Abschluß der FES soll der sendende Knoten das TxENn-Signal auf logisch eins setzen.
Der gesamte Bitstrom für einen Rahmen in dem dynamischen Segment
19 zeigt den gesamten Bitstrom eines in dem dynamischen Segment übertragenen Rahmens.
An dem Minischlitz-Aktionspunkt soll das TxDn-Ausgangssignal zu einem logischen „1"-Pegel wechseln, während TxENn eine Bitdauer gdBit nach dem Aktionspunkt zu logisch „1" wechseln soll (dadurch wird sichergestellt, daß eine Dauer von gdBit besteht, in der das TxDn-Ausgangssignal vor dem Übergang von TxENn zu logisch eins auf logisch eins liegt. Dies ist für die Stabilität bestimmter Arten von physischen Schichten notwendig).
Symbolcodierung
Das FlexRay-Kommunikationsprotokoll definiert sechs Symbole; jedes dieser wird durch spezifische Bitmuster repräsentiert:
Status-Normal-Symbol (SNS)
Status-Alarm-Symbol (SAS)
Mediumzugriffs-Testsymbol (MTS)
Kollisionsvermeidungssymbol (CAS)
Ereignisanzeigesymbol (EIS)
Aufwecksymbol (WUS)
Der Bitstrom jedes Symbols wird in den folgenden Abschnitten beschrieben.
Status-Normal-Symbol (SNS)
Das Status-Normal-Symbol soll beginnend mit der Übertragungsstartsequenz (TSS) übertragen werden, gefolgt durch 2 gdBit Zeiten auf dem logischen „1"-Pegel, 30 gdBit Zeiten auf dem logischen „0"-Pegel und schließlich einer gdBit-Zeit auf einem logischen „1"-Pegel, wie in 20 gezeigt.
Status-Alarm-Symbol (SAS)
Das Status-Alarm-Symbol soll beginnend mit der Übertragungsstartsequenz (TSS) übertragen werden, gefolgt durch zwei gdBit Zeiten auf einem logischen „1"-Pegel, 20 gdBit Zeiten auf einem logischen „0"-Pegel und schließlich einer gdBit-Zeit auf einem logischen „1"-Pegel, wie in 21 gezeigt.
Kollisionsvermeidungssymbol (CAS)
Das Kollisionsvermeidungssymbol soll beginnend mit der Übertragungsstartsequenz (TSS) übertragen werden, gefolgt durch 30 gdBit Zeiten auf einem logischen „0"-Pegel, wie in 22 gezeigt.
Mediumzugriffs-Testsymbol (MTS)
Das Mediumzugriffs-Testsymbol (MTS) soll genauso wie das oben beschriebene CAS-Symbol codiert werden.
Ereignisanzeigesymbol (EIS)
Das Ereignisanzeigesymbol (EIS) soll genauso wie das oben beschriebene SNS-Symbol codiert werden.
Aufwecksymbol (WUS)
Bei der TxD-Ausgabe soll das Aufwecksymbol beginnend mit einer konfigurierbaren Anzahl von gdBit-Zeiten auf einem logischen „0"-Pegel (gdWakeupSymbolTxLow) übertragen werden, gefolgt durch eine konfigurierbare Anzahl von gdBit-Zeiten auf einem logischen „1"-Pegel (gdWakeupSymbolTxIdle).
Bei der TxENn-Ausgabe soll das WUS identisch mit der TxD-Leitung übertragen werden, d.h. beginnend mit einer konfigurierbaren Anzahl von gdBit-Zeiten auf einem logischen „0"-Pegel (gdWakeupSymbolTxLow), gefolgt durch eine konfigurierbare Anzahl von gdBit-Zeiten auf einem logischen „1"-Pegel (gdWakeupSymbolTxIdle).
Das Aufwecksymbol soll eine konfigurierbare Anzahl von Malen (gdWakeupPattern) wiederholt werden. Die minimale Anzahl der Wiederholungen ist 2. Die Konfigurationsparameter für das WUS werden später ausführlicher beschrieben. 23 zeigt ein Beispiel mit einer Sequenz zweier WUS.
Bitstromdecodierung mit NRZ
Dieser Abschnitt spezifiziert die Mechanismen, mit denen Bitstromdecodierung durchgeführt wird, einschließlich der relevanten Parametergrenzen und Konfigurationsparameter mit dieser Funktion. Die Decodierungsfunktion interpretiert den an den RxDn-Eingängen des CC beobachteten Bitstrom.
Das Blockschaltbild in 24 zeigt den Steuerfluß der Empfangssignale durch die Einheit für Bitstromdecodierung (BSD).
Die Bitstromdecodierung verarbeitet auf dem physischen Medium vorliegende Bitströme, extrahiert logische Rahmen- und Symbolinformationen und leitet diese Informationen zu der FlexRay-Protokoll-Engine weiter. Es werden die folgenden Schritte ausgeführt: Bittaktsynchronisation an speziellen Flanken während des Bitstroms, der an dem RxDn-Eingang detektiert wird Bitabtastung und -Voting auf der Basis des synchronisierten Bittakts Decodierung von Rahmen- und Symbolinformationen aus der Ausgabe von Bitabtastung und -Voting
Die Bitstrom-Decodierungsprozesse der einzelnen Kanäle auf einem mehrkanaligen FlexRay-Knoten operieren unabhängig voneinander. Genauer gesagt müssen die Prozesse der Bittaktsynchronisation, der Flankendetektion, des Abtast-Voting, der Rahmendecodierung und der Symboldetektion auf den einzelnen Kanälen zu einem unabhängigen Betrieb fähig sein.
Bittaktsynchronisation
Die Funktion der Bittaktsynchronisation (BCA) synchronisiert den für Bitabtastung und -Voting verwendeten lokalen Bittakt mit dem empfangenen Bitstrom an dem RxDn-Eingang.
Flankendetektionsfenstersteuerung
Das Flankendetektionsfenster bestimmt das Zeitfenster, in dem die nächste Flanke für Bittaktsynchronisation erwartet wird. Dieses Fenster wird während des Rahmenempfangs um den erwarteten logischen Übergang von „1" zu „0" zwischen den beiden Bit der nächsten BSS herumgelegt.
Anfangsflanken-Detektionsfensterbestimmung
Die Initialisierung der BCA wird gestartet, sobald an RxDn Kanal-Leerlauf erkannt (und der BCA über die Decodereinheit signalisiert) wird. 25 zeigt den Mechanismus, der das Anfangsflanken-Detektionsfenster bestimmt, wenn ein Rahmen empfangen wird. Wenn der empfangene Bitstrom kein Rahmen ist (z.B. Symbolempfang), soll die BCA deaktiviert werden, bis der nächste Kanal-Leerlauf über die Decodereinheit der BCA signalisiert wird.
Die Initialisierung der BCA wird durch die folgenden Schritte ausgeführt:
Detektion der fallenden Flanke (potentieller Start eines Rahmens, d.h. Start einer TSS)
Detektion der ansteigenden Flanke (potentieller Start der BSS)
Detektion der fallenden Flanke (potentielle fallende Flanke in der Mitte der BSS)
Synchronisation des Bitstroms auf diese fallende Flanke Bestimmung des ersten Flankendetektionsfensters
Start der Rahmendetektion
Nach Kanal-Leerlauf wartet die BCA auf eine fallende Flanke, die potentiell der Start eines Rahmens ist (TSS). Um Glitches herauszufiltern, wird eine kontinuierliche Anzahl von pVotingSamples Abtastwerten zum Mehrheits-Voting genommen, um das Auftreten der Flanke zu validieren (siehe 25 mit pVotingSamples = 3).
Wenn die Mehrheit von pVotingSamples aufeinanderfolgenden Abtastwerten eine logische „0" ist, wurde eine fallende Flanke detektiert.
Start der BSS-Detektion
Nach dem Detektieren einer gültigen fallenden Flanke wartet die BCA auf eine ansteigende Flanke, die potentiell der Start einer BSS ist. Um Glitches herauszufiltern, wird eine kontinuierliche Anzahl von pVotingSamples Abtastwerten für Mehrheits-Voting genommen, um das Auftreten der Flanke zu validieren (siehe 25 mit pVotingSamples = 3).
Wenn die Mehrheit von pVotingSamples aufeinanderfolgenden Abtastwerten eine logische „1" ist, wurde eine gültige ansteigende Flanke detektiert.
Detektion der fallenden Flanke in der Mitte der BSS
Nach dem Detektieren einer gültigen ansteigenden Flanke wartet die BCA auf eine fallende Flanke, die potentiell die Mitte einer BSS ist. Um Glitches herauszufiltern, wird eine kontinuierliche Anzahl von pVotingSamples Abtastwerten für Mehrheits-Voting genommen, um das Auftreten der Flanke zu validieren (siehe 25 mit pVotingSamples = 3).
Wenn die Mehrheit von pVotingSamples aufeinanderfolgenden Abtastwerten eine logische „0" ist, wurde eine gültige fallende Flanke detektiert.
Bitstromsynchronisation
Nach dem Detektieren einer gültigen fallenden Flanke wird der Bittakt auf den Bitstrom synchronisiert (siehe 26).
Der erste Abtastwert des nächsten Bit wird durch den mittleren Abtastwert des Voting-Fensters bestimmt. 26 zeigt ein Beispiel mit pVotingSamples = 3, wobei der zweite Abtastwert des Voting-Fensters als der erste Abtastwert des nächsten Bit betrachtet werden soll. Nach dem Synchronisieren der Bitabtastung auf diesen bestimmten Abtastwert in der BSS wird von dem ersten Abtastwert jedes nachfolgenden Bit des nächsten Byte in Betracht gezogen, daß er pSamplesPerBit nach dem ersten Abtastwert des vorherigen Bit auftritt.
Bestimmung des ersten Flankendetektionsfensters
Die fallende Flanke der nächsten BSS wird 10·pSamplesPerBit Abtastwerte nach der fallenden Flanke der aktuellen BSS erwartet. Das Bitzeitfenster wird symmetrisch um die erwartete Flanke in der nächsten BSS gelegt, mit einer Größe von sechs Abtastwerten, d.h. das nächste Flankendetektionsfenster wird von drei Abtastwerte zuvor bis drei Abtastwerte nach dieser erwarteten fallenden Flanke gelegt (siehe 27).
Bittaktsynchronisation
Während des Flankendetektionsfensters wird die Anzahl der Abtastwerte, die gleich logisch „0" sind, als vEdgeLowSamples gezählt. Es müssen drei Fälle unterschieden werden:
Fall 1: vEdgeLowSamples = pEdgeSamples/2
In diesem Fall wird angenommen, daß die Bittaktsynchronisation korrekt ist. Die fallende Flanke wird an der erwarteten fallenden Flanke detektiert (siehe 28).
Fall 2: vEdgeLowSamples > pEdgeSamples/2
In diesem Fall muß der Bittakt durch (–1)-Abtastpunkt synchronisiert werden (siehe 29).
Fall 3: vEdgeLowSamples < pEdgeSamples/2
In diesem Fall muß der Bittakt durch (+1)-Abtastwert synchronisiert werden (siehe 30).
Im allgemeinen ist das Verschieben der Bitstartzeit auf plus oder minus einen Abtastpunkt beschränkt.
Wenn während des Flankendetektionsfensters keine fallende Flanke detektiert wird (d.h. alle Abtastwerte haben denselben Wert), wird gemäß den folgenden Regeln die Neusynchronisation der nächsten Bitabtastung durchgeführt
Wenn in dem Flakendetektionsfenster nur logische „0"-Werte abgetastet werden, wird der Bittakt –1 Abtastwert relativ zu der erwarteten fallenden Flanke synchronisiert.
Wenn nur logische „1"-Werte in dem Flankendetektionsfenster abgetastet werden, wird der Bittakt +1 Abtastwert relativ zu der erwarteten fallenden Flanke synchronisiert.
Diese Bedingung stellt keinen Codierungsfehler dar.
Flankendetektionsfensterbestimmung während des Rahmenempfangs
Das nächste Flankendetektionsfenster wird aus dem synchronisierten Bittakt der aktuellen detektierten fallenden Flanke bestimmt. Die fallende Flanke der nächsten BSS wird 10·pSamplesPerBit nach der aktuellen detektierten fallenden Flanke erwartet. Das Bitzeitfenster wird symmetrisch um die erwartete Flanke in der nächsten BSS gelegt, d.h. das nächste Flankendetektionsfenster wird von drei Abtastwerte vor bis zu drei Abtastwerte nach dieser erwarteten fallenden Flanke gelegt (siehe 27).
Bitabtastung und -Voting
Die Funktion des Bitabtastens und -Voting entscheidet, ob der aktuelle Bitwert als logische „1" oder logische „0" zu betrachten ist. Diese Bestimmung soll an den Signalen RXDA und RXDB durchgeführt werden.
Anfangs-Bitstartbestimmung
Nach der Initialisierung des CC beginnt die BSD-Einheit sofort mit der Bitabtastung, d.h. der lokale Bittakt wird sofort gestartet und der Bitstrom wird mit diesem (unsynchronisierten) Bittakt abgetastet. Es wird angenommen, daß das erste Bit mit dem ersten Abtastwert beginnt. Die Bittaktsynchronisation beginnt unabhängig wie oben beschrieben. Die Anzahl der Abtastwerte eines Bit wird durch den Parameter pSamplesPerBit konfiguriert. pSamplesPerBit kann entweder 8 oder 10 betragen. Es wird angenommen, daß jedes nachfolgende Bit pSamplesPerBit nach seinem Vorgängerbit beginnt. 31 zeigt ein Beispiel für Bitabtastung mit pSamplesPerBit = 10.
Neusynchronisation der Bitabtastung
Nachdem die Bittaktsynchronisation aktiviert ist, wird die Bitabtastung durch Verwendung des synchronisierten Bittakts neu mit dem empfangenen Bitstrom synchronisiert. Die Neusynchronisation der Bitabtastung wird nur an den fallenden Flanken in der BSS durchgeführt. Im allgemeinen soll der erste Abtastwert des nächsten Bit auf den Abtastwert gesetzt werden, der der durch die BCA detektierten fallenden Flanke folgt. Dieser Mechanismus ist in 32 dargestellt.
Nach der Bittaktsynchronisation wird Bitabtastung ohne Neusynchronisation für die nächsten zehn Bit durchgeführt, d.h. bis zu der fallenden Flanke der nächsten BSS.
Bitwert-Voting
Die Anzahl der für Mehrheits-Voting zu betrachtenden Abtastwerte soll ungerade sein. Es wird empfohlen, das Voting-Fenster auf der vorgeblichen Mitte der Bitzelle zu zentrieren.
Der Abtastwert-Voting-Prozeß definiert ein „Fenster" von Abtastwerten, mit denen der Wert eines empfangenen Bit bestimmt wird. Dieses Fenster ist durch zwei Parameter pVotingOffset und pVotingSamples charakterisiert. Ein Beispiel mit pVotingOffset = 3 und pVotingSamples = 5 ist für den Fall von pSamplesPerBit = 10 in 33 gezeigt.
Der Parameter pVotingOffset spezifiziert das Offset zwischen dem 1. Abtastwert des Bit und dem Anfang des Voting-Fensters. Dieses Offset definiert den ersten Abtastwert des Bit, der für das Voting betrachtet wird. Genauer gesagt ist der erste für das Voting betrachtete Abtastwert der Abtastwert nach den ersten pVotingOffset Abtastwerten des Bit (d.h. das Voting beginnt, nachdem pVotingOffset Abtastwerte „übersprungen" wurden).
Der Parameter pVotingSamples spezifiziert die Anzahl der Abtastwerte in dem Voting-Fenster. Das Fenster wird definiert durch Nehmen von pVotingSamples aufeinanderfolgenden Abtastwerten, beginnend mit dem durch pVotingOffset angegebenen Abtastwert.
Der Bitwert soll durch Mehrheits-Voting über den Abtastwerten in dem Voting-Fenster bestimmt werden (dies hat zur Folge, daß die Anzahl der Abtastwerte in dem Voting-Fenster, pVotingSamples, ungerade sein muß), d.h., wenn eine Mehrzahl von Abtastwerten in dem Voting-Fenster den logischen Wert „0" aufweist, soll der Ausgangswert des abgetasteten Bit „0" sein; Wenn eine Mehrheit von Abtastwerten in dem Voting-Fenster den logischen Wert „1" aufweist, soll der Ausgangswert des abgetasteten Bit „1" sein.
Man beachte, daß das Voting-Fenster und die Bitabtastung bei jeder Flanke zwischen den beiden Bit der Bitstartsequenz (BSS) neusynchronisiert werden soll. Dies ist die einzige für die Neusynchronisation zu verwendende Flanke.
Rahmen- und Symboldecodierung
Man beachte, daß aufgrund bestimmter Auswirkungen auf das physische Übertragungsmedium (z.B. optische Übertragung, Abschneidung aufgrund des Verbindungsaufbaus in dem Sternkoppler usw.) es möglich ist, daß die an dem RxDn-Eingang gesehene TSS kürzer oder länger als die gesendete TSS sein kann. Alle Empfänger sollen Übertragungsstartsequenzen mit beliebiger Dauer im Bereich von 1 bis 16 Bitzeiten (einschließlich) annehmen.
Ein gültiger Start von Rahmen oder Symbol soll betrachtet werden, wenn die folgenden Bedingungen erfüllt sind:

• der Kanal wurde als leerlaufend detektiert und
• es bestand mindestens ein Übergang von logisch „1" zu logisch „0" und
• der mit dem als Start der Bitzelle betrachteten Übergang assoziierte Bitwert wurde als logisch „0" betrachtet (Bitwert-Voting-Ergebnis)

Anmerkung: für Glitsch-Filterung und Bitstartzeitsynchronisation am Anfang des Rahmens und/oder Symbols siehe den Abschnitt über Bittaktsynchronisation in diesem Kapitel.
Rahmendecodierung
der Rahmencodierungsstatus soll „gültige Codierung" sein, wenn die folgenden Bedingungen erfüllt sind: Es wurde detektiert, daß die TSS-Länge mindestens 1 Bit und kleiner oder gleich 16 Bit beträgt und alle erwarteten BSS wurden erfolgreich detektiert (d.h. das erste Bit der BSS wurde als eine logische „1" und das zweite Bit als logische „0" gewählt) und die FES wurde erfolgreich detektiert (d.h, das erste Bit der FES wurde als logische „0" und das zweite Bit als logische „1" gewählt).
Nachdem die Decodierereinheit anstelle einer erwarteten BSS eine FES detektiert, wird die BCA-Funktion deaktiviert, bis Kanal-Leerlauf detektiert wird.
SNS-Decodierung
Die Detektion eines SNS-Symbols soll als „gültige Codierung" betrachtet werden, wenn die folgenden Bedingungen erfüllt sind:
eine TSS wird mit einer Dauer zwischen 1 und 16 gdBit detektiert und
es werden zwei gdBit Zeiten logisch „1" detektiert und für eine Dauer von 27 gdBit < t_{_sns_0} < 33 Bit wird ein nachfolgender logischer „0"-Pegel detektiert
SAS-Decodierung
Die Detektion eines SAS-Symbols soll als „gültige Codierung" betrachtet werden, wenn die folgenden Bedingungen erfüllt sind:
es wird eine TSS mit einer Dauer zwischen 1 und 16 gdBit detektiert und
es werden zwei gdBit Zeiten logische „1" detektiert und für eine Dauer von 18 gdBit < t_{_sas_0} < 22 gdBit wird ein nachfolgender logischer „0"-Pegel detektiert
EIS-Decodierung
Die Detektion eines EIS-Symbols soll als „gültige Codierung" betrachtet werden, wenn dieselben Bedingungen wie für die SNS-Decodierung (siehe oben) erfüllt sind.
CAS-Decodierung
Die Detektion eines CAS-Symbols soll als „gültige Codierung" betrachtet werden, wenn die folgende Bedingung erfüllt ist:
die TSS wird mit einer Dauer zwischen 1 und 16 gdBit detektiert und
für eine Dauer von 27 gdBit < t_{_cas_0} < 33 gdBit wird ein nachfolgender logischer „0"-Pegel detektiert
MTS-Decodierung
Die Detektion eines MTS-Symbols soll als „gültige Codierung" betrachtet werden, wenn dieselbe Bedingung wie für die CAS-Decodierung (siehe oben) erfüllt ist.
WUS-Decodierung
Die Detektion eines WUS-Symbols soll als „gültige Codierung" betrachtet werden, wenn die folgende Bedingung erfüllt ist:
Es wird eine Dauer zwischen 1 gdBit und gdWakeupSymbolRxLow auf einem logischen „0"-Pegel detektiert.
Kanal-Leerlauf-Detektion
Die Funktion der Kanal-Leerlauf-Detektion befindet sich in dem Decodierer und verwendet die Eingabe aus der Abtast- und Voting-Einheit. Die Kanal-Leerlauf-Detektionsfunktion ist immer aktiv, einschließlich zum Beispiel während der ablaufenden Rahmen und/oder Symboldetektion. Wenn sich CC im Low-Power-Modus und/oder im CC-Konfigurationszustand befindet, wird keine Kanal-Leerlauf-Detektionsunterstützung durchgeführt.
Nach dem Austritt aus dem CC-Konfigurationszustand und/oder dem CC-Low-Power-Modus soll anfänglich angenommen werden, daß der Kanal belegt ist (d.h. nicht leerläuft). Das Verhalten ist außerdem erforderlich, wenn ein undefiniertes Kommunikationselement detektiert wird.
Der Kanal soll als leerlaufend betrachtet werden, sobald 12 aufeinanderfolgende Bit mit dem logischen Datenwert „1" detektiert wurden.
Das Vorliegen von Glitches, während der Kanal leerläuft, stellt keine Codierungsfehlerbedingung her und der Kanal-Leerlauf-Detektions-Timer soll nicht neu starten. Der Kanal-Leerlauf-Detektionszähler soll neugestartet werden, wenn ein Übergang von logisch „1" zu „0" detektiert wurde, wenn das assoziierte Bit-Voting-Ergebnis „0" war.
Wenn der nächste Rahmen- oder Symbolstart früher als nach erfolgreicher Kanal-Leerlauf-Detektion detektiert wird, stellt dies einen Kanal-Leerlauf-Bedingungs verstoß her (aber keinen Codierungsfehler) und soll dem Host signalisiert werden.
Codierungsfehlersignalisierung
Nachdem ein Rahmen- oder Symbolstart detektiert wurde, d.h. wenn ein Übergang von Kanal-Leerlauf zu logisch „0" an RxDn beobachtet wird und keine der im Abschnitt „0" beschriebenen Bedingungen gegeben sind, soll der Codierungsstatus „ungültige Codierung" sein.
Nachdem ein gültiger Rahmen oder ein gültiges Symbol empfangen wurde, soll die CC die Kanalleerlaufprüfung durchführen. Wenn die aufeinanderfolgenden 12 Bit nach Rahmen- oder Symbolende nicht logisch „1" sind, soll dem Host ein „Kanalleerlauf-Codierungsverstoß" signalisiert werden.
Einrichtung befindet sich im Sleep-Modus
Sobald eine logische „0"-Bedingung detektiert wurde, soll diese Bedingung erfaßt und als ein potentieller Start eines Aufwecksymbols betrachtet werden. Wenn die Aufweckbedingung als „gültig" verifiziert wird, sollen die entsprechenden Herauffahraktionen durchgeführt werden (siehe unten), andernfalls soll die Einrichtung weiter im Sleep-Modus bleiben.
Konfigurationsparameter
Um in der Lage zu sein, eine geeignete Menge verschiedener Bitraten zu unterstützen, ohne daß die Oszillatorfrequenz modifiziert werden muß, soll die Anzahl der Abtastwerte pro Bit pSamplesPerBit auf entweder 8 oder 10 konfigurierbar sein. Zusätzlich sollte typischerweise ein skalierbarer Oszillatortaktperiodenmultiplikator vorgesehen sein. Mindestens soll der Knoten Taktperiodenmultiplikatoreinstellungen (Vorskalierereinstellungen) von 1, 2, 4, 8 und 16 unterstützen. Die unterstützten Bitraten hängen von der verwendeten Oszillatorfrequenz, der Vorskalierereinstellung und der Abtastwerte-Pro-Bit-Einstellung ab.
Die folgende Tabelle 7 gibt ein Beispiel für unterstützte Bitraten mit einer Oszillatorperiode von 12,5 ns (z.B. f_osc = 80 MHz nominal).
Tabelle 7: Beispiel für unterstützte Bitraten mit einer Oszillatorperiode von 12,5 ns
Übersicht
Das folgende beschreibt die von dem FlexRay-Protokoll verwendeten unterstützten Rahmenformate und gibt eine Übersicht. Dann konzentriert sich die Beschreibung auf die Rahmenformate.
Das FlexRay-Protokoll unterstützt zwei verschiedene Rahmenformate:
das FlexRay-Rahmenformat
das byteflight-Rahmenformat
Alle Steuerungen in einem Cluster müssen so konfiguriert werden, daß sie dasselbe Rahmenformat verwenden. Genauer gesagt ist ein System, in dem bestimmte Steuerungen das FlexRay-Rahmenformat und andere Steuerungen das byteflight-Rahmenformat benutzen, keine gültige Systemkonfiguration.
Das FlexRay-Rahmenformat kann für Systeme im zeitgetriggerten verteilten Modus (TT-D-Modus), im zeitgetriggerten Master-gesteuerten Modus (TT-M-Modus) oder im ereignisgetriggerten Modus (ET-Modus) verwendet werden.
Das byteflight-Rahmenformat kann nur in Systemen verwendet werden, die im byteflight-Modus (BF-Modus) arbeiten.
Beide Rahmenformate enthalten ein Kopfteilsegment, ein Nutzsignalsegment und ein Nachspannsegment, die jeweils spezifische Felder enthalten. Diese werden für das FlexRay- und das byteflight-Rahmenformat beschrieben und in 34 bzw. 35 dargestellt.
FlexRay-Rahmenformat
Eine Übersicht über das FlexRay-Rahmenformat wird in 34 gegeben. Der Rahmen soll dergestalt in dem Netzwerk übertragen werden, daß das Kopfteilsegment zuerst erscheint, gefolgt durch das Nutzsignalsegment und dann gefolgt durch das Nachspannsegment, das zuletzt übertragen wird.
FlexRay-Kopfteilsegment
Das FlexRay-Kopfteilsegment besteht aus 5 Byte, die mehrere verschiedene Felder enthalten; ein reserviertes Bit, ein Netzwerkverwaltungsanzeigebit, ein Nullrahmenanzeigebit, ein Sync-Bit, ein Rahmen-ID-Feld, ein Nutzsignallängenfeld, ein Kopfteil-CRC-Feld und ein Zykluszählerfeld. Diese Felder werden in den folgenden Abschnitten ausführlich beschrieben. In dem Kopfteilsegment sollen die Felder in der in 34 angegebenen Reihenfolge von links nach rechts übertragen werden (d.h. das reservierte Bit wird zuerst und das Zykluszählerfeld zuletzt übertragen).
Reserviertes Bit (1 Bit – fReservedBit)
Dieses Feld besteht aus einem Bit, das für zukünftige Protokollbenutzung reserviert ist. Dieses Bit soll von der Anwendung nicht verwendet werden.
In einem sendenden Knoten soll das reservierte Bit auf logisch „0" gesetzt werden.
In einem empfangenden Knoten soll das reservierte Bit ignoriert werden (Der Empfänger benutzt den Wert des reservierten Bit für den Rahmen-CRC-Prüfprozeß, ignoriert aber ansonsten seinen Wert (d.h. der Empfänger soll in diesem Feld entweder eine 1 oder eine 0 annehmen).).
Netzwerkverwaltungsanzeigebit (1 Bit – fNMIndicationBit)
Dieses Feld gibt an, ob ein optionaler Netzwerkverwaltungsvektor in dem Nutzsignalteil des Rahmens enthalten ist.
Wenn das Netzwerkverwaltungsanzeigebit auf fNMIndicationBit = 1 gesetzt ist, enthält der Nutzsignalteil des Rahmens einen Netzwerkverwaltungsvektor.
Wenn das Netzwerkverwaltungsanzeigebit auf fNMIndicationBit = 0 gesetzt ist, enthält der Nutzsignalteil des Rahmens keinen Netzwerkverwaltungsvektor.
Nullrahmenanzeigebit (1 Bit – fNullFrameIndicationBit)
Das Nullrahmenanzeigebit fNullFrameIndicationBit gibt an, ob der aktuelle Rahmen ein „Nullrahmen" ist, d.h. ein Rahmen, der in dem Nutzsignalsegment des Rahmens keine benutzbaren Daten enthält. (Das Nullrahmenanzeigebit gibt nur an, ob der Kommunikationssteuerung zum Zeitpunkt des Sendens des Rahmens gültige Daten zur Verfügung standen. Ein Nullrahmenanzeigebit, das auf 1 gesetzt ist, bedeutet, daß die empfangenen Daten in dem Nutzsignalsegment nicht gültig sind. Wenn das Bit auf 0 gesetzt ist, sind die Daten in dem Nutzsignalsegment von Standpunkt der sendenden Kommunikationssteuerung aus gesehen gültig. Der Empfänger muß möglicherweise mehrere weitere Prüfungen durchführen, um zu entscheiden, ob die Daten tatsächlich gültig sind.)
Wenn das Nullrahmenanzeigebit auf fNullFrameIndicationBit = 1 gesetzt ist, enthält das Nutzsignalsegment keine gültigen Daten.
Wenn das Nullrahmenanzeigebit auf fNullFrameIndicationBit = 0 gesetzt ist, enthält das Nutzsignalsegment Daten.
Weitere Informationen über Nullrahmen finden sich später.
Sync-Bit (1 Bit – fSyncBit)
Das sync-Bit fSyncBit bestimmt, ob der Rahmen für verschiedene Aspekte der Systemsynchronisation verwendet werden soll.
Wenn das Sync-Bit auf fSyncBit = 1 gesetzt ist, kommt der Rahmen für Synchronisation in Frage, wenn er andere Kriterien erfüllt (siehe unten).
Wenn das Sync-Bit auf fSyncBit = 0 gesetzt ist, soll der Rahmen nicht zur Synchronisation verwendet werden.
Zu Beispielen für Protokollmechanismen, die das Sync-Bit benutzen, gehören Taktsynchronisation (später beschrieben) und Herauffahren (später beschrieben). In allen Fällen ist die Bedingung fSyncBit = 1 nur eine von mehreren Bedingungen, die dafür notwendig sind, daß der Rahmen in den verschiedenen Synchronisationsmechanismen verwendet wird.
Alle in dem dynamischen Segment (falls anwesend) übertragenen Rahmen sollen mit fSyncBit = 0 gesendet werden.
Wenn ein Knoten einen gegebenen Rahmen auf mehr als einem Kanal sendet, soll er fSyncBit auf jedem Kanal auf denselben Wert setzen.
Ein Knoten soll einen Rahmen mit fSyncBit = 1 nicht in mehr als einem Schlitz eines gegebenen Kommunikationszyklus senden. Wenn ein Knoten Rahmen mit fSyncBit = 1 sendet, dann nur in demselben Schlitz jedes Kommunikationszyklus.
Ein Knoten soll einen Rahmen mit fSyncBit = 1 in einem gegebenen Schlitz eines Kommunikationszyklus nur dann senden, wenn er dafür konfiguriert ist, auf allen konfigurierten Kanälen für diesen Schlitz zu senden (Dies hat zur Folge, daß Knoten, die Rahmen mit fSyncBit = 1 auf Zweikanalsystemen senden, diesen Rahmen auf beiden Kanälen des Systems senden müssen. Einkanalsysteme erfüllen diese Anforderung implizit – alle Rahmen werden auf allen konfigurierten Kanälen übertragen.).
Rahmen-ID (12 Bit – fFrameID)
Dieses Feld enthält die Rahmenkennung für den Rahmen. Jeder Rahmen, der in einem Cluster übertragen werden kann, hat eine zugewiesene Rahmen-ID fFrameID.
Die Rahmen-ID fFrameID ist eine eindeutige Nummer pro Kommunikationskanal pro Kommunikationszyklus und definiert den Schlitz, in dem der Rahmen übertragen wird.
Gültige Werte für fFrameID liegen im Bereich von 1 bis 4095 (in binär: von (0000 0000 0001)₂ bis (1111 1111 1111)₂) während der Protokolloperationsphase (POP). Die Rahmen-ID 0 ist eine ungültige Rahmen-ID.
Das Rahmen-ID-Feld soll so übertragen werden, daß das höchstwertige Bit von fFrameID zuerst übertragen wird, wobei die übrigen Bit von fFrameID in absteigender Reihenfolge der Wertigkeit übertragen werden.
Nutzsignallänge (7 Bit – fPayloadLength)
Das Nutzsignallängenfeld besteht aus einem einzigen Parameter fPayloadLength, der mit der Anzahl der in dem Nutzsignalsegment des Rahmens enthaltenen Byte zusammenhängt. Genauer gesagt gibt fPayloadLength die Anzahl der Byte in dem Nutzsignalsegment dividiert durch zwei, an. Ein Rahmen, der zum Beispiel ein Nutzsignalsegment enthält, das aus 72 Byte besteht, würde mit fPayloadLength = 36 gesendet. Eine ausführliche Definition der Inhalte des Nutzsignalsegments eines FlexRay-Rahmens wird später angegeben.
Das Nutzsignallängenfeld enthält nicht die Anzahl der Byte in dem Kopfteil- und dem Nachspannsegment des FlexRay-Rahmens.
Die Maximale Nutzsignallänge ist cPayloadLengthMax, entsprechend einem Nutzsignalsegment, das 2·cPayloadLengthMax Byte enthält. Das Nutzsignalfeld soll kleiner oder gleich der maximalen Nutzsignallänge sein: cPayloadLength ≤ cPayloadLengthMax.
Die Nutzsignallänge soll für alle Rahmen in dem statischen Segment eines Kommunikationszyklus festliegen. Für diese Rahmen soll das Nutzsignallängenfeld mit fPayloadLength = gPayloadLengthStatic übertragen werden.
Die Nutzsignallänge fPayloadLength kann für verschiedene Rahmen in dem dynamischen Segment eines Kommunikationszyklus verschieden sein. Zusätzlich kann die Nutzsignallänge eines spezifischen Dynamisches-Segment-Rahmens von Zyklus zu Zyklus variieren. Als letztes können die Nutzsignallänge eines spezifischen Dynamisches-Segment-Rahmens auf jedem konfigurierten Kanal verschieden sein. Für alle Dynamisches-Segment-Rahmen soll jedoch 0 ≤ fPayloadLength ≤ cPayloadLengthMax gelten.
Das Nutzsignallängenfeld soll so übertragen werden, daß das höchstwertige Bit von fPayloadLength zuerst übertragen wird, wobei die übrigen Bit von fPayloadLength in absteigender Reihenfolge der Wertigkeit übertragen werden.
Kopfteil-CRC (11 Bit – fHeaderCRC)
Das Kopfteil-CRC-Feld enthält einen CRC-Code (Cyclic Redundancy Check), der über das Sync-Bit, die Rahmen-ID und die Nutzsignallängenfelder des Rahmens hinweg berechnet wird.
Die CRC wird auf allen konfigurierten Kanälen auf dieselbe Weise berechnet. Das CRC-Polynom soll folgendermaßen lauten: x11 + x9 + x8 + x7 + x2 + 1 = (x + 1)(x5 + x3 + 1)(x5 + x4 + x3 + x + 1)
Dieses 11-Bit-CRC-Polynom erzeugt einen (31,20)-BCH-Code mit einer minimalen Hamming-Distanz von 6. Das Codewort besteht aus den zu schützenden Daten und der CRC. Bei dieser Anwendung schützt diese CRC genau 20 Datenbit (1 Bit sync + 12 Bit Rahmen-ID + 7 Bit Nutzsignallänge = 20 Bit). Dieses Polynom wurde von T. Wadayama, Average Distortion of Some Cyclic Codes, Website verfügbar bei http://vega.c.okapu.jp/-wadayama/distortion.html, erhalten, und seine Eigenschaften wurden durch Verwendung der Techniken verifiziert, die in P. Koopman, „32-bit Cyclic Redundancy Codes for Internet Applications", Proceedings of the International Conference on Dependable Systems and Networks (DSN 2002), Washington DC, Juni 2002, Seiten 459–468, beschrieben werden. Der Initialisierungsvektor des zur Erzeugung der Kopfteil-CRC verwendeten Registers soll (1A)_HEX sein.
Mit Bezug auf die Berechnung von fHeaderCRC sollen die Felder von Sync-Bit, Rahmen-ID und Nutzsignallänge dem CRC-Generator in Netzwerkreihenfolge zugeführt werden, genauer gesagt soll das Sync-Bit zuerst eingeschoben werden, gefolgt durch das höchstwertige Bit des Rahmen-ID-Feldes, gefolgt durch nachfolgende Bit der Rahmen-ID, gefolgt durch das höchstwertige Bit des Nutzsignallängenfeldes und gefolgt durch nachfolgende Bit des Nutzsignallängenfeldes.
Das Kopfteil-CRC-Feld soll so übertragen werden, daß das höchstwertige Bit von fHeaderCRC zuerst übertragen wird, wobei die übrigen Bit von fHeaderCRC in absteigender Reihenfolge der Wertigkeit übertragen werden.
Eine ausführliche Beschreibung, wie die Kopfteil-CRC erzeugt oder verifiziert wird, wird später angegeben.
Zykluszähler (6 Bit – fCycleCount)
Das Zykluszählerfeld gibt die Sicht des sendenden Knotens des Zykluszählers vCycle zum Zeitpunkt der Rahmenübertragung an.
Das Zykluszählerfeld soll vor der Übertragung eines Rahmens auf fCycleCount = vCycle gesetzt werden.
Das Zykluszählerfeld soll so übertragen werden, daß das höchstwertige Bit von fCycleCount zuerst übertragen wird, wobei die übrigen Bit von fCycleCount in absteigender Reihenfolge der Wertigkeit übertragen werden.
FlexRay-Nutzsignalsegment
Das FlexRay-Nutzsignalsegment enthält 0 bis 254 Byte (0 bis 127 Zwei-Byte-Wörter) von Daten, die durch den Host geschrieben werden.
Aufgrund der Beschränkungen, die der Repräsentation der Länge des Nutzsignalsegments durch das Nutzsignallängenfeld (fPayloadLength) des Kopfteilsegments auferlegt werden, soll das FlexRay-Nutzsignalsegment aus einer geraden Anzahl von Byte bestehen. (Die durch fPayloadLength angegebene Länge des Nutzsignalsegments korreliert mit der Anzahl der Byte, die auf dem Kommunikationskanal gesendet wird. Sie definiert nicht notwendigerweise die Anzahl der von der Anwendung in dem Nutzsignalteil verwendeten Byte. Die von der Anwendung bereitgestellten Daten können kürzer als der Nutzsignalteil sein. Eine Stopfunktion in der Kommunikationssteuerung füllt die „fehlenden" Byte, wenn der konfigurierte Sendepuffer kleiner als die konfigurierte Nutzsignallänge ist.)
Man beachte, daß die nachfolgend beschriebene Rahmen-CRC für Nutzsignallängen von bis zu 248 Byte eine Hamming-Distanz von sechs aufweist. Für Nutzsignallängen von mehr als 248 Byte stellt die CRC nur eine Hamming-Distanz von vier bereit.
Die ersten beiden Byte des FlexRay-Nutzsignalsegments können wahlweise als ein Nachrichten-ID-Feld benutzt werden, wodurch empfangende Knoten Daten auf der Basis des Inhalts dieses Feldes filtern oder lenken können.
Die nachfolgenden Byte des Nutzsignalsegments können wahlweise als Netzwerkverwaltungsvektor benutzt werden. Die Länge des Netzwerkverwaltungsvektors wird durch gNetworkManagementVectorLength während CC_SoftReset konfiguriert und kann während der Protokollherauffahrphase (PSP) oder während der Protokolloperationsphase (POP) nicht verändert werden.
gNetworkManagementVectorLength kann zwischen einschließlich 0 und 12 Byte konfiguriert werden. Das Netzwerkverwaltungsanzeigebit in dem Rahmenkopfteil gibt an, ob der Nutzsignalteil den Netzwerkverwaltungsvektor enthält (Rahmen, die Netzwerkverwaltungsdaten enthalten, sind nicht darauf beschränkt, nur Netzwerkverwaltungsdaten zu enthalten – mit den anderen Byte in dem Nutzsignalteil kann man zusätzliche Nicht-Netzwerkverwaltungsdaten übermitteln).
Wenn das optionale Nachrichten-ID-Feld nicht benutzt wird, beginnt der Netzwerkverwaltungsvektor (falls vorhanden) mit dem ersten Byte des Nutzsignalteils.
Die einzelnen Byte in dem Nutzsignalsegment sollen so übertragen werden, daß das höchstwertige Bit des Byte zuerst übertragen wird, wobei die übrigen Bit des Byte in absteigender Reihenfolge der Wertigkeit übertragen werden.
FlexRay-Nachspannsegment
Das FlexRay-Nachspannsegment enthält ein einziges Feld, eine 24-Bit-CRC für den Rahmen.
Rahmen-CRC (24 Bit – fFrameCRC)
Das Rahmen-CRC-Feld enthält einen CRC-Code (Cyclic Redundancy Check), der über das Kopfteil- und Nutzsignalsegment des Rahmens hinweg berechnet wird. Die Berechnung umfaßt alle Felder in diesen Segmenten (dazu gehören die Kopfteil-CRC sowie etwaige, von der Kommunikationssteuerung erzeugte „Stopf"-Byte, die in dem Nutzsignalsegment enthalten sein können).
Die CRC wird auf beiden Kanälen unter Verwendung desselben Generatorpolynoms berechnet. Das CRC-Polynom soll folgendermaßen lauten: x24 + x22 + x20 + x19 + x18 + x16 + x14 + x13 + x11 + x10 + x8 + x7 + x6 + x3 + x + 1 = (x + 1)2(x11 + x9 + x8 + x7 + x5 + x3 + x2 + x + 1)(x11 + x9 + x8 + x7 + x6 + x3 + 1)
Dieses 24-Bit-CRC-Polynom erzeugt einen Code mit einer minimalen Hamming-Distanz von 6 für Codewörter einer Länge von bis zu 2048 Bit und einer minimalen Hamming-Distanz von 4 für Codewörter mit einer Länge von bis zu 4094 Bit. Das Codewort besteht aus allen Rahmendaten und der CRC. Dies entspricht einem Schutz mit H = 6 für FlexRay-Rahmen mit Nutzsignallängen von bis zu 248 Byte und einem Schutz mit H = 4 für längere Nutzsignallängen. Dieses Polynom wurde aus G. Castagnoli, S. Bräuer und M. Herrmann, „Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Trans. Commun., Band 41, Seiten 883–892, Juni 1993, erhalten und seine Eigenschaften wurden unter Verwendung der Techniken verifiziert, die in P. Koopman, „32-bit Cyclic Redundancy Codes for Internet Applications", Proceedings of the International Conference on Dependable Systems and Networks (DSN 2002), Washington DC, Juni 2002, Seiten 459–468, beschrieben werden.
Der Erzeugungsprozeß der CRC ist abhängig davon, auf welchem Kanal der Rahmen übertragen wird, etwas unterschiedlich (Es werden verschiedene Initialisierungsvektoren definiert, um zu verhindern, daß ein Knoten kommuniziert, wenn er falsch geschaltete Kanäle, eine Verbindung eines Einkanalknotens mit dem falschen Kanal oder kurzgeschlossene Kanäle (beide Steuerungskanäle mit dem selben physischen Kanal verbunden) aufweist.):
Der Initialisierungsvektor des CRC-Generators soll für auf Kanal A gesendete Rahmen (FE DC BA)_HEX sein.
Der Initialisierungsvektor des CRC-Generators soll für auf Kanal B gesendete Rahmen (AB CD EF)_HEX sein.
Mit Bezug auf die Berechnung von fFrameCRC sollen die Rahmenfelder im CRC-Generator in Netzwerkreihenfolge zugeführt werden (das heißt, das erste, das in den Generator kommt, ist das höchstwertige Bit des Reserviertes-Bit-Feldes und das letzte, das in den Generator kommt, ist das niedrigstwertige Bit des letzten Byte des Nutzsignalsegments).
Das Rahmen-CRC-Feld soll so übertragen werden, daß das höchstwertige Bit von fFrameCRC zuerst übertragen wird, wobei die übrigen Bit von fFrameCRC in absteigender Reihenfolge der Wertigkeit übertragen werden.
Eine ausführliche Beschreibung, wie die Rahmen-CRC erzeugt oder verifiziert werden soll, wird später gegeben.
Nullrahmen
Unter bestimmten Bedingungen kann ein sendender Knoten einen „Nullrahmen" senden, d.h. einen Rahmen, der keine gültigen Daten in dem Nutzsignalsegment enthält. Ein solcher Rahmen wird gesendet, wenn ein Sender dafür konfiguriert ist, in einem gegebenen Schlitz und Kanal des statischen Segments zu senden, aber keine gültigen Daten besitzt, wenn die Übertragung dieses Schlitzes dafür eingeteilt ist, zu beginnen. Dazu könnte es dadurch kommen, daß der Host einen Sendepuffer verriegelt und ihn vor der Übertragungszeit nicht freigibt, oder dadurch, daß ein Sender für Zykluszählerfilterung (siehe unten) konfiguriert ist und der aktuelle Zykluszähler nicht mit dem Filter übereinstimmt. Zusätzlich kann eine sendende Steuerung einen Nullrahmen anzeigen, wenn der Host die Daten seit der letzten eingeteilten Übertragung nicht erfolgreich aktualisiert hat. Dieses Verhalten ist optional (siehe weiter unten). Der Sender zeigt einen Nullrahmen durch Setzen von fNullFrameIndicationBit = 1 an.
Ein Nullrahmen besteht aus folgendem:

• einem Kopfteilsegment wie oben beschrieben mit fNullFrameIndicationBit = 1
• einem Nutzsignalsegment mit allen Bit auf Null gesetzt
• einem Nachspannsegment wie oben beschrieben.

Nullrahmen sollen nur in dem statischen Segment gesendet werden, und daher wird die Nutzsignallänge durch gPayloadLengthStatic definiert.
Das Nutzsignalsegment eines Nullrahmens soll vom Empfänger ignoriert werden (der Empfänger verwendet die Daten in dem Nutzsignalsegment für den Rahmen-CRC-Prüfprozeß, ignoriert aber ansonsten die Daten), aber andere Felder des Rahmens können nützliche Daten enthalten (Zum Beispiel kann der Taktsynchronisationsalgorithmus die Ankunftszeit von Nullrahmen mit auf 1 gesetztem Sync-Bit-Feld benutzen (solange alle anderen Kriterien für die Annahme dieses Rahmens erfüllt sind).).
byteflight-Rahmenformat
Eine Übersicht über das byteflight-Rahmenformat wird in 35 gegeben. Der Rahmen soll so in dem Netzwerk übertragen werden, daß das Kopfteilsegment zuerst erscheint, gefolgt durch das Nutzsignalsegment und dann gefolgt durch das Nachspannsegment, das zuletzt übertragen wird.
byteflight-Kopfteilsegment
Das byteflight-Kopfteilsegment besteht aus 2 Byte, die mehrere verschiedene Felder enthalten; die Rahmen-ID, ein Feld reservierter Bit und die Rahmenlänge. Diese Felder werden in den folgenden Abschnitten ausführlich beschrieben.
In dem Kopfteilsegment sollen die Felder in der in 35 angegebenen Reihenfolge übertragen werden, und zwar von links nach rechts (d.h. das Rahmen-ID-Feld wird zuerst und das Rahmenlängenfeld zuletzt übertragen).
Rahmen-ID (8 Bit – fBfFrameID)
Dieses Feld enthält die Rahmenkennung für den Rahmen. Jedem Rahmen, der in einem Cluster übertragen werden kann, ist eine Rahmen-ID fBfFrameID zugewiesen.
Die Rahmen-ID fBfFrameID ist eine eindeutige Nummer pro Kommunikationszyklus und definiert den Minischlitz, in dem der Rahmen übertragen wird.
Gültige Werte für fBfFrameID reichen von (0000 0001)₂ bis (1111 1111)₂.
Das Rahmen-ID-Feld soll so übertragen werden, daß das höchstwertige Bit von fBfFrameID zuerst übertragen wird, wobei die übrigen Bit von fBfFrameID in absteigender Reihenfolge der Wertigkeit übertragen werden.
Spezial-Anwendungsbit (4 Bit – fBFSpecialApplBits)
Dieses Feld besteht aus vier Bit, die von der Anwendung benutzt werden können.
Das Feld fBFSpecialApplBits soll so übertragen werden, daß das höchstwertige Bit von fBfSpecialApplBits zuerst übertragen wird, wobei die übrigen Bit von fBfSpecialApplBits in absteigender Reihenfolge der Wertigkeit übertragen werden.
Das Feld fBfSpecialApplBits in dem sendenden Knoten wird durch den Host geschrieben (Die vier Spezial-Anwendungsbit werden durch den Host des sendenden Knotens geschrieben. Die Kommunikationssteuerungen auf allen Knoten (Sender und Empfänger) behandeln diese Bit als Anwendungsdaten).
Rahmenlänge (4 Bit – fBfFrameLength)
Die Rahmenlänge besteht aus einem einzigen Parameter fBfFrameLength, der die Anzahl der Datenbyte angibt, die in dem Nutzsignalsegment des Rahmens enthalten sind.
Das Rahmenlängenfeld enthält nicht die Anzahl der Byte in dem Kopfteil- und dem Nachspannsegment des byteflight-Rahmens.
Die kürzest mögliche Länge ist 0 Byte. (fBfFrameLength = (0000)₂), die längste Länge 12 Byte (fBfFrameLength = (1100)₂). Ein Rahmen, der mit fBfFrameLength von mehr als 12 empfangen wird, soll als ein Fehler behandelt werden.
Das Rahmenlängenfeld soll so übertragen werden, daß das höchstwertige Bit von fBfFrameLength zuerst übertragen wird, wobei die übrigen Bit von fBfFrameLength in absteigender Reihenfolge der Wertigkeit übertragen werden.
byteflight-Nutzsignalsegment
Das byteflight-Nutzsignalsegment besteht aus 0 bis 12 Byte Daten, die durch den Host geschrieben werden.
Die einzelnen Byte in dem Nutzsignalsegment sollen so übertragen werden, daß das höchstwertige Bit des Byte zuerst übertragen wird, wobei die übrigen Bit des Byte in absteigender Reihenfolge der Wertigkeit übertragen werden.
byteflight-Nachspannsegment
Das byteflight-Nachspannsegment besteht aus 2 Byte, die zwei verschiedene Felder enthalten; eine Rahmen-CRC und das Rahmenvervollständigungsbit. Diese Felder werden in den folgenden Abschnitten ausführlich beschrieben.
In dem Nachspannsegment sollen die Felder in der in 35 angegebenen Reihenfolge übertragen werden, und zwar von links nach rechts (d.h. das Rahmen-CRC-Feld wird zuerst übertragen und das Rahmenvervollständigungsbit zuletzt).
Rahmen-CRC (15 Bit – fBfFrameCRC)
Das Rahmen-CRC-Feld enthält einen CRC-Code (Cyclic Redundancy Check), der über das Kopfteil- und Nutzsignalsegment des Rahmens hinweg berechnet wird. Die Berechnung umfaßt alle Felder in diesen Segmenten.
Das CRC-Generatorpolynom soll folgendermaßen lauten: x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1
Dies ist dasselbe Polynom, das in dem CAN-Protokoll verwendet wird, wie in ISO/DIS 11898-1;1999, Road vehicles – Controller area network (CAN) – Part 1: Data Link Layer and Physical Signaling, International Standards Organization, 1999, definiert. Es ist für Codewörter von bis zu 127 Bit optimiert.
Der Initialisierungsvektor der byteflight-Rahmen-CRC soll (00)_HEX lauten.
Mit Bezug auf die Berechnung von fBfFrameCRC sollen die Rahmenfelder dem CRC-Generator in Netzwerkreihenfolge zugeführt werden (das heißt, das erste, das in den Generator kommt, ist das höchstwertige Bit des Rahmen-ID-Feldes und das letzte, das in den Generator kommt, ist das niedrigstwertige Bit des letzten Byte des Nutzsignalsegments).
Das Rahmen-CRC-Feld soll so übertragen werden, daß das höchstwertige Bit von fBfFrameCRC zuerst übertragen wird, wobei die übrigen Bit von fBfFrameCRC in absteigender Reihenfolge der Wertigkeit übertragen werden.
Eine ausführliche Beschreibung, wie die Rahmen-CRC erzeugt oder verifiziert werden soll, wird nachfolgend angegeben.
Rahmenvervollständigungsbit (1 Bit – fBfFCB)
Das Rahmenvervollständigungsbit fBfFCB ist ein einziges Bit, dessen einziger Zweck darin besteht, es dem byteflight-Rahmen zu ermöglichen, an einer Bytegrenze zu enden.
Das Rahmenvervollständigungsbitfeld soll mit fBfFCB = 0 übertragen werden.
Abhängigkeiten
Nachrichten-ID (optional, 16 Bit – fMessageID)
Die ersten beiden Byte des Nutzsignalsegments des FlexRay-Rahmenformats können als empfängerfilterbare Daten, die als Nachrichten-ID bezeichnet werden, benutzt werden.

• Die Nachrichten-ID ist eine Anwendungsbestimmbare Zahl, die den Inhalt des Datensegments beschreibt.
• Die Nachrichten-ID ist 16 Bit lang.
• Im Sender wird die Nachrichten-ID durch den Host durch Anwendungsdaten beschrieben. Die Kommunikationssteuerung hat kein Wissen über die Nachrichten-ID und kein Mechanismus in der Kommunikationssteuerung basiert auf der Nachrichten-ID.
• Im Empfänger kann die Speicherung eines Rahmens von dem Ergebnis eines Filterungsprozesses abhängen, der die Nachrichten-ID benutzt. Alle bei der Rahmenverarbeitung durchgeführten Rahmenprüfungen (siehe weiter unten) sind unmodifiziert (d.h. sind keine Funktion der Nachrichten-ID). Die Verwendung des Nachrichten-ID-Filters wird in dem Kapitel über die Hostschnittstelle definiert (siehe weiter unten).
• Die wahlweise Benutzung von Nachrichten-IDs muß in allen Rahmen in dem gesamten Cluster einheitlich sein (Einheitlichkeit bedeutet, daß eine Nachrichten-ID für ALLE Rahmen (sowohl statisch als auch dynamisch) in einem Cluster oder für KEINEN Rahmen benutzt wird. Eine teilweise Benutzung der Nachrichten-ID ist nicht möglich).
• Wenn dieser Mechanismus verwendet wird, soll das höchstwertige Bit von fMessageID in dem höchstwertigen Bit des ersten Byte des Nutzsignalsegments abgelegt werden. Nachfolgende Bit von fMessageID sollen in dem nächsten Nutzsignalbit in der Reihenfolge absteigender Wertigkeit abgelegt werden.

Rahmen-CRC-Berechnung
Die Rahmen-CRC-Berechnung erfolgt in der Kommunikationssteuerung vor der Übertragung oder nach dem Empfang eines Rahmens. Sie ist Teil des Rahmenübertragungsprozesses bzw. des Rahmenempfangsprozesses.
Die Variable vCheckCRC_x steht für das Ergebnis der Prüfung der Einheitlichkeit eines Rahmens und seiner CRC für den jeweiligen Kommunikationskanal. Die Berechnung kann durch den folgenden Pseudocode beschrieben werden.

Die Werte der Protokollkonstanten cCrcSize, cCrcInit_x und cCrcPolynomial hängen von dem verwendeten Rahmenformat ab, d.h. das FlexRay- oder das byteflight-Rahmenformat. Für das FlexRay-Rahmenformat hängt der Wert von cCrcInit_x auch von dem zum Senden des Rahmens verwendeten Kanal ab: FlexRay-Rahmenformat/Kanal A:

cCrcSize = 24;	// Größe des Registers beträgt 24 Bit
cCrcInit = (FE DC BA)_HEX;	// Initialisierungsvektor von Kanal A
cCrcPolynomial = (5D 6D CB)_HEX;	// Hexadezimalrepräsentation des CRC-Polynoms

FlexRay-Rahmenformat/Kanal A:

cCrcSize = 24;	// Größe des Registers beträgt 24 Bit
cCrcInit = (AB CD EF)_HEX;	// Initialisierungsvektor von Kanal B
cCrcPolynomial = (5D 6D CB)_HEX;	// Hexadezimalreprasentation des CRC-Polynoms

byteflight-Rahmenformat:

cCrcSize = 15;	// Größe des Registers beträgt 15 Bit
cCrcInit = 0_HEX;	// Initialisierungsvektor
cCrcPolynomial = (45 99)_HEX;	// Hexadezimalrepräsentation des CRC-Polynoms

Kurzbeschreibung: Das CRC-Schieberegister mit dem entsprechenden Initialisierungswert initialisieren. So lange die Bit (vNextBit_x) aus dem Kopfteil oder dem Nutzsignalsegment des Rahmens verfügbar sind, wird die While-Schleife ausgeführt. Die Anzahl verfügbarer Bit in dem Nutzsignalsegment wird aus dem Nutzsignallängenfeld abgeleitet. Die Bit (Sender verwenden die Bitsequenz, die dem Codierungsalgorithmus zugeführt wird, einschließlich etwaiger von der Steuerung erzeugter Stopfbit. Empfänger benutzen die decodierte Sequenz, so wie sie aus dem Decodierungsalgorithmus empfangen wird (d.h. nach Entfernung etwaiger Codierungssequenzen (z.B. Bytestartsequenzen, Rahmenstartsequenzen usw.)).) des Kopfteil- und Nutzsignalsegments werden dem CRC-Register durch Verwendung der Variablen vNextBit_x bitweise in Netzwerkreihenfolge zugeführt, z.B. für das Flexray-Rahmenformat ist das erste als vNextBit_x verwendete Bit das Reserviertes-Bit-Feld und das letzte verwendete Bit ist das niedrigstwertige Bit des letzten Byte des Nutzsignalsegments.
Prozedur 1: Rahmen-CRC-Berechnung
Der folgende Vergleich geschieht nur im Empfänger.
Kopfteil-CRC-Berechnung
Neben seinen anderen Verwendungszwecken soll das Kopfteil-CRC-Feld eines FlexRay-Rahmens vor einer nicht ordnungsgemäßen Modifikation des Sync-Bit-Feldes durch eine fehlerhafte Kommunikationssteuerung (CC) schützen. Die für das Übertragen eines bestimmten Rahmens verantwortliche CC soll das Kopfteil-CRC-Feld für diesen Rahmen nicht berechnen. Statt dessen soll die CC mit der entsprechenden Kopfteil-CRC für einen gegebenen Rahmen durch den Host konfiguriert werden. Dadurch wird es unwahrscheinlich, daß ein Fehler in der CC, der eine Änderung eines Sync-Bit verursacht, zu einem Rahmen führt, der von anderen Knoten in dem Netzwerk angenommen wird, weil die CRC nicht übereinstimmen würde. Das Entfernen der Fähigkeit des Senders, die CRC zu erzeugen, minimiert die Möglichkeit, daß eine Nachricht, die aus einem CC-Fehler resultiert, eine ordnungsgemäße Kopfteil-CRC aufwiese.
Die für den Empfang eines Rahmens verantwortliche CC soll die erforderlichen CRC-Berechnungen zum Prüfen der Korrektheit des Kopfteil-CRC-Feldes relativ zu anderen Informationen, die in dem Rahmen empfangen werden, durchführen.
Die Variable vCheckHeaderCRC_x steht für das Ergebnis der Prüfung für den jeweiligen Kommunikationskanal. Die Prüfung kann durch den folgenden Pseudocode beschrieben werden.

Der Wert der Protokollkonstanten cHCrcSize, cHCrcInit und cHCrcPolynomial wird folgendermaßen definiert: FlexRay-Kopfteil-CRC-Berechnung:

cHCrcSize = 11;	// Größe des Registers beträgt 11 Bit
cHCrcInit := (1A)_HEX;	// Initialisierungsvektor der Kopfteil-CRC für beide Kanäle
cHCrcPolynomial := (3 85)_HEX;	// Hexadezimalrepräsentation des Kopfteil-CRC-Polynoms

Kurzbeschreibung: Das CRC-Schieberegister mit dem entsprechenden Initialisierungswert initialisieren. So lange Bit (vHNextBit_x) aus den Feldern Sync-Bit, Rahmen-ID und Nutzsignallänge des Rahmens verfügbar sind, wird die While-Schleife ausgeführt. Die Anzahl verfügbarer Bit wird durch die Rahmenformatdefinition festgelegt (auf 20). Die Bit der angegebenen Felder werden dem CRC-Register durch Verwendung der Variablen vHNextBit_x bitweise in Netzwerkreihenfolge zugeführt, d.h. das Sync-Bit, gefolgt durch das höchstwertige Bit des Rahmen-ID-Feldes, gefolgt durch nachfolgende Bit der Rahmen-ID, gefolgt durch das höchstwertige Bit des Nutzsignallängenfeldes und gefolgt durch nachfolgende Bit des Nutzsignallängenfeldes. Sender verwenden die Bitsequenz, die dem Codierungsalgorithmus zugeführt wird. Empfänger verwenden die decodierte Sequenz, so wie sie aus dem Decodierungsalgorithmus empfangen wird (d.h. nach der Entfernung etwaiger Codesequenz usw.).
Es wird dieselbe Prozedur wie in Prozedur 1 beschrieben verwendet, außer daß mit folgendem angefangen wird:
vNextBit_x = vHNextBit_x;
cCrcSize = cHCrcSize;
cCrcInit = cHCrcInit;
cCrcPolynomial = cHCrcPolynomial;
Der folgende Vergleich erfolgt nur im Empfänger:
Das folgende deckt die Rahmenverarbeitung und insbesondere die Rahmenempfangsprozedur des FlexRay-Protokolls ab.
Übersicht
Die mit der Protokoll-Engine zusammenhängende Rahmenverarbeitung besteht aus drei Schritten: Der erste Schritt wird als Rahmendecodierung bezeichnet. In diesem Schritt findet die Rahmendecodierung statt. Die Rahmendecodierung soll gemäß den oben spezifizierten Decodierungsregeln stattfinden. Der nächste Schritt wird als der Rahmenempfang bezeichnet. In diesem Schritt wird die syntaktische Korrektheit des Rahmens sichergestellt. Der letzte Schritt wird als Rahmenannahme bezeichnet. In diesem Schritt werden die in dem Kopfteil jedes Rahmens enthaltenen protokollspezifischen Daten, wie zum Beispiel der Zykluszählwert, mit Bezugswerten verglichen.
Rahmenempfang
Der Rahmenempfang spezifiziert, wie die syntaktische Korrektheit eines Rahmens ermittelt wird.
Syntaktische Korrektheit
Im allgemeinen wird ein Rahmen als syntaktisch korrekt betrachtet, wenn während des Empfangs des Rahmens keine Codierungsverstöße erkannt werden, die Kopfteil-CRC gültig ist, die Rahmen-CRC gültig ist und die Anzahl der empfangenen Byte der in dem Rahmenkopfteil enthaltenen Rahmenlänge entspricht.
Ein Rahmen soll also als syntaktisch korrekt betrachtet werden, wenn alle folgenden Bedingungen erfüllt sind:

1. Beginnend mit dem Anfang des Empfangs werden die fünf Rahmenkopfteilbyte ohne Codierungsfehler empfangen. Der Verstoß gegen diese Bedingung wird als ein Kopfteilcodierungsfehler (S_HeaderCodingError) betrachtet.
2. Die Kopfteil-CRC-Verifikation gemäß der CRC-Berechnungsprozedur ist mit dem Ergebnis „gültig" zurückgekommen. Der Verstoß gegen diese Bedingung wird als ein Ungültige-Kopfteil-CRC-Fehler (S_InvalidHeaderCRCError) betrachtet.
3. Die übrigen (2·fPayloadLength + 3) Byte des Rahmens werden ohne Codierungsfehler unter Verwendung des aus dem Kopfteil des Rahmens extrahierten Werts fPayloadLength empfangen. Der Verstoß gegen diese Bedingung wird als ein Rahmencodierungsfehler (S_FrameCodingError) betrachtet.
4. Die Rahmen-CRC-Verifikation gemäß der CRC-Berechnungsprozedur ist mit dem Ergebnis „gültig" zurückgekommen. Der Verstoß gegen diese Bedingung wird als ein Ungültige-Rahmen-CRC-Fehler (S_InvalidFrameCRCError) betrachtet.
5. Das Rahmenende wird ohne Codierungsfehler erreicht. Der Verstoß gegen diese Bedingung wird als ein Rahmencodierungsfehler (S_FrameCodingError) betrachtet.
6. Der Knoten leitet keine eigene Übertragung ein, während der Empfang auf demselben Kanal abläuft. Der Verstoß gegen diese Bedingung wird als ein Übertragungskonfliktfehler (S_TransmissionConflictError) betrachtet.

Der fehlerfreie Empfang von fünf Rahmenkopfteilbyte, d.h. Bedingung 1 eines syntaktisch korrekten Rahmens ist erfüllt, wird als Empfang mit erfolgreichem Kopfteil (S_SuccessfulHeaderReception) betrachtet.
Ein syntaktisch korrekter Rahmen wird als ein korrekter Rahmen betrachtet (S_CorrectFrame).
Rahmenempfangs-Zustandsdiagramm
36 zeigt das Rahmenempfangs-Zustandsdiagramm. Die Übergänge sind in Tabelle 8 zusammengefaßt.
Tabelle 8: Rahmenempfangs-Zustandsübergänge
Der Zustand FR_Idle
Der Empfangsautomat soll in dem Zustand FR_Idle bleiben, solange der Kanal leerläuft. In diesem Zustand wartet der Knoten auf den Anfang eines Empfangs, der auftritt, sobald der Kanal aktiv wird. Der Anfang eines Empfangs soll einen Übergang zu dem Zustand FR_Active verursachen.
Der Zustand FR_Active
Der Rahmenempfang findet in dem Zustand FR_Active statt. Dadurch soll die syntaktische Korrektheit eines Rahmens ermittelt werden. Das Auftreten von S_HeaderCodingError, S_InvalidHeaderCRCError, S_FrameCodingError, S_InvalidFrameCRCError soll einen Übergang in den Zustand FR_Abort verursachen.
Die Erkennung von Leerlauf am Ende eines syntaktisch korrekten Rahmens soll einen Übergang in den Zustand FR_Idle verursachen.
Der Zustand FR_Abort
Der Empfangsautomat soll in dem Zustand FR_Abort bleiben, bis auf dem jeweiligen Kanal der Kanalleerlaufzustand erreicht wird. Nachdem der Kanalleerlaufzustand erreicht ist, soll der Empfangszustand zu FR_Ready wechseln.
Der Zustand FR_SoftReset
Der Empfangsautomat soll in dem Zustand FR_SoftReset bleiben, so lange sich die Kommunikationssteuerung in dem Zustand CC_SoftReset und sich der jeweilige Kommunikationskanal nicht im Leerlaufzustand befindet.
Rahmenannahme
Die Rahmenannahme ist abhängig von der aktuellen Protokollphase unterschiedlich. Ob ein Rahmen in einer spezifischen Phase angenommen wird oder nicht, hängt von dem Ergebnis einer Anzahl von Prüfungen ab.
FlexRay unterscheidet zwischen den Herauffahrannahmekriterien, den Statisches-Segment-Annahmekriterien und den Dynamisches-Segment-Annahmekriterien.
Herauffahrannahmekriterien
Die Herauffahrannahmekriterien werden angewandt, wenn sich der Knoten in dem Integrationsweg der Herauffahrphase befindet.
Ein Rahmen soll also als den Herauffahrannahmekriterien entsprechend betrachtet werden, wenn alle folgenden Bedingungen, die auf einem korrekten Rahmen angewandt werden, erfüllt sind:

1. Die in dem Kopfteil des Rahmens enthaltene Rahmen-ID ist nicht größer als die Nummer des letzten statischen Schlitztes gNumberOfStaticSlots.
2. Das sync-Bit ist gesetzt.
3. Die in dem Kopfteil des Rahmens enthaltene Nutzsignallänge ist gleich dem global konfigurierten Wert der Nutzsignallänge eines statischen Rahmens, die in gPayloadLengthStatic gehalten wird. Der Verstoß gegen diese Einschränkung wird als ein payload-length-static error (S_PayloadLengthStaticError) betrachtet.

Ein Rahmen, der den Herauffahrannahmekriterien entspricht, wird als ein Gültiges-Herauffahren-Rahmen (S_ValidStartupFrame) betrachtet.
Wenn der in dem Kopfteil eines Gültiges-Herauffahren-Rahmens enthaltene Zykluszählwert gerade ist, wird der Rahmen als ein Gültiges-Gerades-Herauffahren-Rahmen (S_ValidEvenStartupFrame) betrachtet.
Wenn der in dem Kopfteil eines Gültiges-Herauffahren-Rahmens enthaltene Zykluszählwert ungerade ist, wird der Rahmen als ein Gültiges-Ungerades-Herauffahren-Rahmen (S_ValidOddStartupFrame) betrachtet.
Statisches-Segment-Annahmekriterien
Die Statisches-Segment-Annahmekriterien werden angewandt, wenn der Knoten in dem statischen Segment betrieben wird, bevor die Ablaufsteuerung festgelegt ist.
Ein Rahmen soll als den Statisches-Segment-Annahmekriterien entsprechend betrachtet werden, wenn alle folgenden Bedingungen erfüllt sind, die auf einem korrekten Rahmen angewandt werden:

1. Die in dem Kopfteil des Rahmens enthaltene Nutzsignallänge ist gleich dem globalkonfigurierten Wert der Nutzsignallänge eines statischen Rahmens, die in gPayloadLengthStatic gehalten wird. Der Verstoß gegen diese Einschränkung wird als ein Nutzsignal-Längen-Statisch-Fehler (S_PayloadLengthStaticError) betrachtet.
2. Die in dem Kopfteil des Rahmens enthaltene Rahmen-ID ist gleich dem Wert des Schlitzzählers vSlotCounter[ch], und zwar sowohl am Anfang des Rahmens als auch am Ende des Rahmens. Der Verstoß gegen diese Einschränkung wird als ein Rahmen-ID-Fehler (S_FrameIDError) betrachtet. 37 zeigt diese Einschränkung.
3. Der in dem Kopfteil des Rahmens enthaltene Zykluszählwert ist gleich dem Wert des Zykluszählers vCycle sowohl am Anfang des Rahmens als auch am Ende des Rahmens. Der Verstoß gegen diese Einschränkung wird als ein Zyklus-Zählwert-Fehler (S_CycleCountError) betrachtet.

Ein Rahmen, der den Statisches-Segment-Annahmekriterien entspricht, wird als ein Gültig-Statisch-Rahmen (S_ValidStaticFrame) betrachtet.
Dynamisches-Segment-Annahmekriterien
Die Dynamisches-Segment-Annahmekriterien werden angewandt, wenn der Knoten in dem dynamischen Segment betrieben wird.
Ein Rahmen soll als den Dynamisches-Segment-Annahmekriterien entsprechend betrachtet werden, wenn alle folgenden Bedingungen erfüllt sind, die auf einem korrekten Rahmen angewandt werden:

1. Die in dem Kopfteil des Rahmens enthaltene Rahmen-ID ist gleich dem Wert des Schlitzzählers vSlotCounter[ch] am Anfang des Rahmens. Der Verstoß gegen diese Einschränkung wird als ein Rahmen-ID-Fehler (S_FrameIDError) bezeichnet. 38 zeigt diese Anforderung.
2. Der in dem Kopfteil des Rahmens enthaltene Zykluszählwert ist gleich dem Wert des Zykluszählers vCycle, sowohl am Anfang des Rahmens als auch am Ende des Rahmens. Der Verstoß gegen diese Einschränkung wird als ein Zyklus-Zählwert-Fehler (S_CycleCountError) betrachtet.
3. Das in dem Kopfteil enthaltene sync-Bit ist auf „0" gesetzt. Der Verstoß gegen diese Einschränkung wird als ein Sync-Bit-Fehler (S_SyncBitError) betrachtet.

Ein Rahmen, der den Dynamisches-Segment-Annahmekriterien entspricht, wird als ein Gültig-Dynamisch-Rahmen (S_ValidDynamicFrame) betrachtet.
Taktsynchronisation
Einführung
In einem verteilten Kommunikationssystem besitzt jeder Knoten seinen eigenen Takt. Aufgrund von Temperaturschwankungen, Spannungsschwankungen und Herstellungstoleranzen der Zeitsteuerungsquelle (z.B. des Oszillators) divergiert die interne Zeitbasis nach einer kurzen Zeit zwischen den Knoten, auch wenn alle internen Zeitbasen der Knoten gleichzeitig gestartet werden.
Eine Grundannahme für ein zeitgetriggertes System besteht darin, daß jeder Knoten in dem Cluster praktisch dieselbe Sicht der Zeit besitzt und diese gemeinsame globale Sicht der Zeit als lokale Zeitbasis für jeden Knoten verwendet wird. In diesem Kontext bedeutet „dieselbe", daß die Differenzen zwischen den Sichten der globalen Zeit zweier beliebiger Knoten auf eine spezifizierte Toleranzgrenze beschränkt sind und daß der Maximalwert für diese Differenz als die Präzision bekannt ist.
Die Hauptaufgabe der Taktsynchronisationsfunktion besteht darin, sicherzustellen, daß die Zeitdifferenzen zwischen den Knoten eines Clusters innerhalb der Präzision bleiben.
Es kann zwischen zwei Arten von Zeitdifferenzen zwischen Knoten unterschieden werden:

• Offset-(Phasen)-Differenzen und
• Raten-(Frequenz)-Differenzen

Um die lokale Zeitbasis verschiedener Knoten zu synchronisieren, sind Verfahren zur Offsetkorrektur und zur Ratenkorrektur bekannt. Bei FlexRay wird eine Kombination beider Verfahren verwendet.
Taktsynchronisationsmoden
FlexRay unterstützt sowohl zeitgetriggerte als auch ereignisgetriggerte Taktsynchronisation. Dieses Kapitel beschreibt die zeitgetriggerten Moden. Später wird beschrieben, wie der ereignisgetriggerte Modus arbeitet. Der entsprechende Taktsynchronisationsmodus sollte auf der Basis der Anforderungen der durch das Cluster zu unterstützenden Anwendungen gewählt werden. Das Cluster muß dann entsprechend konfiguriert werden. Tabelle 9 zeigt die Clusterkonfigurationsbedingungen für die verschiedenen Taktsynchronisationsmoden.
FlexRay unterstützt zwei Moden zur Durchführung der zeitgetriggerten Taktsynchronisation.
Tabelle 9: Konfigurationsregel für verschiedene Taktsynchronisationsmoden
Einzelmaster-Taktsynchronisation
Bei Einzelmaster-Taktsynchronisation synchronisiert sich jeder Knoten einzeln selbst mit dem Cluster durch Beobachten der Zeitsteuerung übertragener sync-Rahmen aus dem Takt-Sync-Master.

• Die Einzelmaster-Taktsynchronisation soll ausgeführt werden, wenn das statische Segment mit nur einem statischen Schlitz konfiguriert ist (gNumberOfStaticSlots = 1).
• Der Knoten, dem der statische Schlitz gehört, muß in diesem Schlitz in jedem Zyklus sync-Rahmen senden. Dieser Knoten ist dann der einzige Knoten in dem Cluster, der sync-Rahmen sendet. Er ist der Taktsynchronisations-Master und die übrigen Knoten sind Slaves.
• Alle anderen Knoten sollen die sync-Rahmen empfangen und den Taktsynchronisationsalgorithmus so durchführen, als ob sich der Knoten in einem Cluster befände, das verteilte Taktsynchronisation verwendet (siehe unten).
• Das Verhalten im Fall eines Fehlers wird später beschrieben. Die Bedingungen zum Signalisieren eines Fehlers sind für den Master und für die Slaves verschieden und sind in der nachfolgenden Tabelle 10 aufgelistet.

Verteilte Taktsynchronisation
Bei verteilter Taktsynchronisation synchronisiert sich jeder Knoten einzeln selbst mit dem Cluster durch Beobachten der Zeitsteuerung gesendeter sync-Rahmen von anderen Knoten. Es wird ein fehlertoleranter Algorithmus benutzt.

• Die verteilte Taktsynchronisation soll nur dann durchgeführt werden, wenn das Cluster mit einem statischen Segment konfiguriert ist (gNumberOfStaticSlots > 1).
• Es sollen mindestens zwei Knoten sync-Rahmen senden.

Die Zeitrepräsentation und die Prinzipien der (verteilten) Taktsynchronisation werden nachfolgend ausführlich beschrieben.
Unterschiede zwischen verteilter und Einzelmaster-Taktsynchronisation
In beiden Moden (Einzelmaster- und verteilte Taktsynchronisation) wird derselbe Taktsynchronisationsalgorithmus verwendet. Unterschiede zwischen beiden Moden gibt es bezüglich

• der Konfiguration (siehe Tabelle 6),
• des Herauffahrens (siehe weiter unten) und
• der Signalisierung eines Fehlers zu der Fehlerverwaltung.

Die folgenden Tabellen zeigen die relevanten Unterschiede für die Fehlersignalisierung.
Tabelle 10: Unterschiede bei der Fehlersignalisierung zwischen der verteilten und der Einzelmaster-Taktsynchronisation
Zeitrepräsentation
Lokale Zeitrepräsentation

• Intern können Knoten ihr Verhalten mit Mikrotickauflösung timen. Mikroticks sind Zeiteinheiten, die von dem (externen) Oszillatortakttick wahlweise unter Verwendung eines Vorskalierers abgeleitet werden. Mikroticks sind steuerungsspezifische Einheiten. Sie können in verschiedenen Steuerungen verschiedene Dauern aufweisen. Die Präzision von lokalen Zeitdifferenzmessungen eines Knotens ist ein Mikrotick.
• Die lokale Steuerungszeit basiert auf clusterübergreifenden synchronisierten Zyklus- und Makrotickwerten, die durch den Mechanismus der verteilten Taktsynchronisation bereitgestellt werden. Eine lokale Zeitsteuerung mit feinerer Auflösung soll unter Verwendung des knotenspezifischen Mikroticks erfolgen. Der Wert vMacrotick.vMicrotick repräsentiert die lokale Ansicht der Steuerung der Zeit in einem gegebenen Zyklus.
• vCycle ist die (steuerungslokale) Zyklusnummer und wird einmal in jeder Kommunikationsrunde erhöht. Zu einem beliebigen gegebenen Zeitpunkt sollten alle Knoten denselben Wert von vCycle aufweisen (mit Ausnahme einer nichtperfekten Synchronisation an Zyklusgrenzen).
• Zykluszählerwerte (vCycle) reichen von Null (00 0000)₂ bis cCycleMax (11 1111)₂.
• Wenn cCycleMax erreicht wird, soll der Zykluszähler vCycle in dem nächsten Kommunikationszyklus auf Null (00 0000)₂ zurückgesetzt werden (siehe Prozedur 3)
• vMacrotick ist der aktuelle Wert des (steuerungslokalen) Makrotickzählers.
• gMacroPerCycle definiert die (ganzzahlige) Anzahl von Makroticks pro Zyklus (siehe 39).
• Innerhalb der Toleranzen ist die Dauer eines Makroticks in dem gesamten Cluster auf synchronisierten Knoten konstant.
• Jeder Knoten in dem Cluster hat seine eigene lokale Sicht der globalen Zeit. Die lokale Sicht der globalen Zeit wird durch einen Vektor repräsentiert, der aus der aktuellen Zyklusnummer (vCycle) und dem aktuellen Makrotickwert (vMacrotick) besteht. Der Wert vCycle.vMacrotick ist die (steuerungslokale) Ansicht der globalen Zeit in dem Cluster. Er ist der Anwendung sichtbar.
• pMicroPerMacroNom ist die (steuerungsspezifische) nominale Anzahl von Mikroticks pro Makrotick.
• vRateCorrection ist die (ganzzahlige) Anzahl von Mikroticks, die in dem aktuellen Zyklus zu den pMicroPerMacroNom·gMacroPerCycle Mikroticks addiert werden soll, um die korrekte Zykluslänge zu produzieren. vRateCorrection kann negativ sein. Der Wert von vRateCorrection wird durch den Taktsynchronisationsalgorithmus bestimmt. Er kann sich nur einmal (gewöhnlich am Anfang) pro Zyklus ändern.
• pMicroOverheadPerCycleNom ist der Anfangskonfigurationswert von vRateCorrection.
• Die Dauer des aktuellen steuerungslokalen Makroticks ist ein ganzzahliges vielfaches der steuerungslokalen Mikroticks und wird durch vMicroPerMacroCorr repräsentiert. Der Wert von vMicroPerMacroCorr in einer Steuerung kann sich von Makrotick zu Makrotick ändern.
• In einem beliebigen gegebenen Zyklus sollen vRateCorrection Mikroticks über die gMacroPerCycle Makroticks, die den Zyklus bilden, verteilt werden, um die Zykluslänge auf die ordnungsgemäße Dauer einzustellen. Folglich bleibt vMicroPerMacroCorr nicht konstant. Im allgemeinen ist vRateCorrection von Null verschieden und ist kein Vielfaches von gMacroPerCycle. Der Prozeß des Verteilens der vRateCorrection Mikroticks über die gMacroPerCycle Makroticks führt folglich konzeptuell Bruchstücke von Makroticks ein.
• Am Anfang des ersten Kommunikationszyklus sollen die „lokalen Zeitvariablen" initialisiert werden (siehe Prozedur 2).

Prozedur 2: Initialisierung eines Knotens
Die Initialisierung der ersten drei Werte ist verschieden, wenn sich der Knoten in ein laufendes Cluster reintegriert (siehe Kapitel „Aufwecken, Herauffahren und Reintegration").
Prozedur 3: Inkrementieren des Zykluszählwerts
Der Host soll in der Lage sein, den Zykluszähler und den Makrotickzähler zu lesen. Die Aktualisierung des Zykluszählers soll mit dem Makrotickzähler atomisch sein. Eine atomische Aktion ist eine Aktion, bei der keine Unterbrechungen möglich sind.
Die Dauer eines Makroticks soll eine ganze Zahl von Mikroticks sein, aber die Anzahl der Mikroticks pro Makrotick kann von Makrotick zu Makrotick verschieden sein. Bevor der erste Korrekturwert berechnet wird, soll der Taktsynchronisationsalgorithmus mit nominalen Makroticks arbeiten, wobei vMicroPerMacroCorr = pMicroPerMacroNom + pMicroOverhead PerCycleNom (siehe Prozedur 4) verwendet wird. Die Anzahl der Mikroticks pro nominalem Makrotick kann zwischen Knoten unterschiedlich sein und hängt von der Oszillatorfrequenz und dem Vorskalierer ab.
Die Dauer eines Zyklus soll eine ganze Zahl von Makroticks sein. Es ist beabsichtigt, daß die Anzahl der Makroticks pro Zyklus in allen Knoten in einem Cluster identisch ist (siehe 39).
Prozedur 4: Inkrementieren des Makrotickzählers
Für einen gegebenen Zyklus (ohne Offsetkorrektur) wird die mittlere Länge eines Makroticks durch pMicroPerMacroNom + vRateCorrection/gMacroPerCycle gegeben.
Prozedur 5: Gleichförmige Verteilung von Mikroticks
Das folgende Beispiel behandelt nur die Verteilung von Mikroticks über die Makroticks, aus denen der Zyklus besteht. Die vollständigere Lösung muß auch Offsetkorrekturen behandeln und wird in Prozedur 10 beschrieben.
Anmerkungen bezüglich der obigen Prozedur:
Die Offsetkorrektur hat einen zusätzlichen Einfluß. Deshalb besteht ein Unterschied zwischen den Variablen vMicroPerMacroCorr und vMicroPerMacroRateCorr.
Da keine Real-Division in Hardware zur Verfügung steht, dupliziert die Implementierung wahrscheinlich nicht genau die obige Prozedur. Am wahrscheinlichsten wird die Variable vMicroPerMacroCorr nicht explizit in Hardware berechnet.
Wie typischerweise bei Pseudocode der Fall ist, gibt die obige Prozedur Einsichten in das Verhalten des Mechanismus, nicht aber in seine Implementierung.
Globale Zeitrepräsentation
In einem FlexRay-Knoten sollen Aktivitäten, einschließlich Kommunikation, auf dem Konzept der globalen Zeit basieren, obwohl jeder einzelne Knoten seine eigene Sicht davon hält. Der Taktsynchronisitätsmechanismus unterscheidet das FlexRay-Cluster von anderen Knotenansammlungen mit unabhängigen Taktmechanismen. Die globale Zeit ist ein Vektor von zwei Werten, dem Zyklus (Zykluszähler) und dem Makrotickzähler (Zykluszeit).
Allgemeine Konzepte
Der Knoten (oder im Fall eines Herauffahrens mit Kollisionen die Knoten), der die erste CAS während des Herauffahrens sendet, soll den Zykluszähler und die Zykluszeit am Anfang des Kommunikationszyklus nach der Übertragung der CAS initialisieren. Siehe oben für Details.
Die Dauer eines statischen Schlitzes gdSlot, eines Kommunikationszyklus gdCycle und die Leerlaufzeit am Ende eines Kommunikationszyklus gdNetworkIdle sollen alle als ganze Anzahl von Makroticks ausgedrückt werden.
Jeder Knoten mit pChannels == gChannels, der dafür konfiguriert ist in dem statischen Segment des Kommunikationszyklus zu senden, kann pro Kommunikationszyklus höchstens einen Rahmen mit gesetztem sync-Bit senden. Das sync-Bit kann nur in Rahmen gesetzt werden, die auf allen Kanälen übertragen werden (gChannels – Ein- oder Zweikanalkonfiguration). Nicht alle Knoten, die dafür konfiguriert sind, in dem statischen Segment des Kommunikationszyklus zu senden, müssen Rahmen mit gesetztem sync-Feld senden.
Die Kommunikationssteuerung soll alle korrekt empfangenen Rahmen zählen, wenn das sync-Bit gesetzt ist. Der Zähler wird am Anfang des Kommunikationszyklus zurückgesetzt. Diese Anzahl der korrekt empfangenen sync-Rahmen des vorherigen Kommunikationszyklus wird durch vValidSyncFrameCount präsentiert und soll dem Host zugänglich sein.
Wenn eine Steuerung mehr als gSyncNodeMax empfängt, soll das erste gSyncNodeMax zur Taktsynchronisation verwendet werden. Die Berechnung der Korrekturwerte soll in jedem zweiten Kommunikationszyklus während der Netzwerkleerlaufzeit (NIT) stattfinden.
Die Taktsynchronisation kann mit vier Prozessen realisiert werden, die als Messung, Berechnung, Offsetkorrektur und Ratenkorrektur bezeichnet werden. Die Prozesse der Offsetkorrektur, der Messung und der Berechnung werden sequentiell ausgeführt. Die Ratenkorrektur wird parallel mit den anderen drei ausgeführt. 40 zeigt die relative Ausführungszeitsteuerung dieser vier Prozesse.
41 zeigt die interne Struktur des Taktsynchronisationsmechanismus ausführlicher. Die Blöcke in der Darstellung entsprechen den Pseudocodeprozeduren in diesem Kapitel. Die schwarzen Kästen beschreiben die durchgeführten Aufgaben und der blaue Text daneben gibt den entsprechenden Prozedurnamen. Anmerkung: Für Kästen ohne entsprechenden Prozedurnamen (kein blauer Text) gibt es keine Prozedur, die genau der Aufgabe entspricht. Pseudocodefragmente für diese Aufgaben werden mit dem Text vermischt.
Zeitmessung
Jeder Knoten soll kanalweise die Zeitdifferenzen vMeasureChx (in Mikroticks) zwischen der erwarteten und der beobachteten Ankunftszeit aller während des statischen Segments empfangenen sync-Rahmen messen und speichern. Differenzbeobachtungen werden so lange als ungültig markiert, bis der Rahmen vollständig empfangen wurde und die erforderlichen Validitätsprüfungen bestanden hat.
Die erwartete Ankunftszeit eines Rahmens ist der Minischlitzaktionspunkt des entsprechenden Schlitzes. Sie wird durch vExpectedArrivalTime = vMacrotick_ExpectedμvMicrotick_Expected repräsentiert, wobei vMacrotick_Expected und vMicrotick_Expected die Makrotick- und Mikrotick-Timerwerte an dem Zeitpunkt des Minischlitzaktionspunkts sind.
Die beobachtete Ankunftszeit eines Rahmens ist der Zeitpunkt des Empfangs der 1/0-Flanke in der Mitte der ersten Bytestartsequenz nach der Rahmenstartsequenz. Sie wird durch vObservedArrivalTimeChx = vMacrotick_Observed·vMicrotick_Observed repräsentiert, wobei vMacrotickObserved und vMicrotick_Observed die Makrotick- und Mikrotick-Timerwerte zum Zeitpunkt des Empfangs dieser Flanke sind.
Die Zeitdifferenz zwischen der erwarteten und der beobachteten Ankunftszeit wird folgendermaßen berechnet:
vMeasureChx = vObservedArrivalTimeChx – vExpectedArrivalTime – gdFrameStartSequence – 1 gdBit – pDelayCompensationChx
Die globalen Parameter gdFrameStartSequence und gdBit werden in Einheiten von Bitzeiten spezifiziert, die zwischen Knoten unterschiedlich sein können, wenn Taktquellen mit verschiedenen Frequenzen benutzt werden. Intern werden diese Parameter in Mikroticks repräsentiert. Die während des Herauffahrens und der Reintegration während des normalen Betriebs verwendeten sync-Rahmenvaliditätsprüfungen werden in dem Abschnitt „Rahmenverarbeitung" beschrieben.
Die Zeitdifferenzmessung soll für alle Kanäle pChannels geschehen.
Wenn es Zeitdifferenzmessungen von mehr als einem Kanal für einen gegebenen sync-Rahmen gibt, soll der kleinste Wert genommen werden.
Wenn nur ein gültiger Rahmen in einem gegebenen statischen Schlitz empfangen wird, soll diese einzige Beobachtung für die Zeitdifferenzmessung benutzt werden.
Jeder Knoten muß in der Lage sein, Meßwerte mit ihren assoziierten Rahmen-IDs für gSyncNodeMax-Sync-Knoten zu speichern. Ein Zähler vValidSyncFrameCount wird erhöht, wenn ein gültiger sync-Rahmen empfangen wird. Wenn ein Knoten mehr als gSyncNodeMax-Sync-Rahmen in einem Kommunikationszyklus empfängt, handelt es sich um Kommunikation mit der Fehlerverwaltung, verwendet aber die ersten gSyncNodeMax Beobachtungen für die Berechnung der Raten- und Driftkorrektwerte. Der Zähler vValidSyncFrameCount wird auf Null gesetzt, wenn ein neuer Kommunikationszyklus beginnt. Man beachte, daß die Rahmenkennungen von sync-Rahmen, deren Empfang erwartet wird, nicht in der Konfiguration eines Knotens gespeichert werden. Einzelne Verzögerungskompensationswerte pDelayCompensationChA und pDelayCompensationChB können für jeden Kanal konfiguriert werden. Die Kompensationswerte sollten auf die minimale Ausbreitungsverzögerungszeit gesetzt werden, die ein beliebiger Knoten in dem Cluster erfährt.
Prozedur 6: Messung
Die folgende Prozedur soll während des normalen Betriebs nach dem Empfang jedes Rahmens in dem statischen Segment ausgeführt werden.
Korrekturtermberechnung
Fehlertoleranter Mittelpunktalgorithmus
Die Technik zur Berechnung der Korrekturterme ist ein fehlertoleranter Mittelpunktalgorithmus (FTA/FTM). Der Algorithmus arbeitet wie folgt (siehe 43 und Prozedur 7):

1. Die gemessenen werte werden sortiert und die n größten und die n kleinsten Werte werden verworfen.
2. Der Wert von n wird dynamisch an die Anzahl der Werte in der sortierten Liste angepaßt.
Tabelle 11: FTA/FTM-Termauslöschung als Funktion der Listengröße
3. Der größte und der kleinste der übrigen Werte werden für die Berechnung des Mittelpunktwerts gemittelt. von dem resultierenden Wert wird angenommen, daß er die Abweichung des Knotens von der globalen Zeitbasis repräsentiert, und dient als der Korrekturterm (siehe 43).

Prozedur 7: FTM/FTA-Algorithmus
Wenn die Liste nur einen Wert enthält, wird dieser Wert zur Taktsynchronisation benutzt.
Berechnung des Offsetkorrekturwerts

1. Der Offsetkorrekturwert vOffsetCorrection ist eine (vorzeichenbehaftete) ganze Zahl, die angibt, um wie viele Mikroticks der Knoten seinen Start des Zyklus verschieben soll.
2. Die Offsetberechnung soll vor dem Start des Zyklus beendet sein und darf erst nach dem Ende des letzten Synchronisationsschlitzes starten.
3. Der eigene Offsetwert des Knotens (abhängig von dem verwendeten Meßprinzip am wahrscheinlichsten Null) soll aufgenommen werden, wenn er einen sync-Rahmen sendet.
4. Die Berechnung des Offsetkorrekturwerts soll in jedem Kommunikationszyklus erfolgen, aber die Offsetkorrektur soll nur in den ungeradzahligen Zyklen erfolgen. In geradzahligen Zyklen soll keine Offsetkorrektur durchgeführt werden.
5. Der berechnete Offsetkorrekturwert soll in jedem Zyklus mit den Grenzwerten verglichen werden. Wenn der berechnete Offsetkorrekturwert außerhalb des zulässigen Bereichs liegt, soll eine Warnung an den Host abgegeben werden (das weitere Verhalten wird im folgenden Text spezifiziert).
6. Wenn der Knoten sync-Rahmen sendet, soll seine eigene Offsetzeit hinzugefügt werden, indem eine Instanz des Werts Null (abhängig von der Meßmethode) zu der Liste gemessener Zeitdifferenzwerte aus dem letzten Zyklus addiert wird.
7. Der Offsetkorrekturwert soll durch Anwenden von FTA/FTM auf die Liste gemessener Zeitdifferenzen bestimmt werden.

Prozedur 8: Berechnung des Offsetkorrekturwerts
Berechnung des Ratenkorrekturwerts

1. Die Berechnung des Ratenkorrekturwerts soll nach jedem zweiten Kommunikationszyklus in den ungeradzahligen Zyklen erfolgen (siehe 44).
2. Der Ratenkorrekturwert soll durch Vergleichen der entsprechenden gemessenen Zeitdifferenzen aus zwei aufeinanderfolgenden Zyklen bestimmt werden. Genauer gesagt soll eine neue Liste von Werten erzeugt werden, deren Elemente durch Nehmen der Differenzen zwischen der gemessenen Zeitdifferenz des letzten Zyklus und der gemessenen Zeitdifferenz des vorherigen Zyklus berechnet werden. Es sollen nur Zeitwerte verwendet werden, die Rahmen entsprechen, die die Gültigkeitsprüfungen auf beiden Kanälen bestehen.
3. Wenn der Knoten sync-Rahmen sendet, soll sein eigener Ratenkorrektureinfluß berücksichtigt werden, indem eine Instanz des Werts Null zu der Liste berechneter Zeitdifferenzen hinzugeführt wird.
4. Im nächsten Schritt soll der oben beschriebene FTA/FTM-Algorithmus auf die Liste der in den zwei vorherigen Schritten aufgebauten Zeitdifferenzwerte angewandt werden.
5. Nach der Berechnung des Korrekturwerms sollen die gespeicherten Meßwerte gelöscht werden, damit die nächste Berechnung mit einer neuen Menge von Werten startet.
6. Der ideale neue Ratenkorrekturwert ist die Summe des in dem vorherigen Schritt berechneten Werts und des aktuellen Korrekturwerts.
7. Um Cluster-Driften zu verhindern, das aus einer Akkumulation von Rundungsfehlern entstehen kann, ist der tatsächlich verwendete Ratenkorrekturterm nicht die ideale Ratenkorrektur, sondern eine geringfügige Modifikation dieses Terms in Richtung des Konfigurationswerts. Der Modifikationsterm ist eine positive ganze Zahl pClusterDriftDamping, die Teil der statischen Konfiguration des Knotens ist.

Prozedur 9: Berechnung des Ratenkorrekturwerts
pClusterDriftDamping sollte so konfiguriert werden, daß der Dämpfungswert in allen Steuerungen nahezu dieselbe Dauer aufweist. Ein Konfigurationswert wird zur Anpassung im Fall verschiedener Mikrotickdauer in verschiedenen Steuerungen verwendet. Nach der Berechnung des Ratenkorrekturwerts wird der Speicher für die Meßwerte gelöscht und als leer markiert. Es sollte klar sein, daß der Offsetkorrekturwert vor dem Löschen des Speichers berechnet wird.
Externe Taktsynchronisation (optional)
Während des normalen Betriebs können zwei unabhängige Cluster signifikant driften (z.B. durch den Dämpfungsfaktor jedes Clusters). Wenn über die beiden Cluster hinweg ein synchroner Betrieb erwünscht ist, ist externe Synchronisation notwendig; obwohl die Knoten innerhalb jedes Clusters synchronisiert sind.
Man kann dies durch synchrone Anwendung von Hostdeduzierten Raten- und Offsetkorrekturtermen auf beide Cluster erreichen.
Externe Taktsynchronisation ist ein optionales Merkmal einer FlexRay-Steuerung, d.h. es wird nicht von jeder Steuerung gefordert, Protokollkonformität zu erfüllen. Wenn dieses Merkmal in einem Cluster verwendet wird, sollten jedoch alle Knoten in diesem Cluster dieses Merkmal unterstützen, damit es nützlich wird.
Die externe Offsetkorrektur soll in allen Knoten eines Clusters in demselben Zyklus durchgeführt werden; in allen Knoten eines Clusters soll die externe Ratenkorrektur in demselben Doppelzyklus durchgeführt werden.
Die externen Korrekturterme (Offset- und Ratenkorrekturterme), die der Kommunikationssteuerung verfügbar sind, wenn die Netzwerk-Leerlaufzeit beginnt, sind die verwendeten Werte. Wenn keine Werte verfügbar sind, sollen die externen Korrekturwerte für den nächsten Doppelzyklus auf Null gesetzt werden.
Die externen Korrekturterme werden mit Grenzen verglichen und angewandt, nachdem die entsprechenden Aufgaben für die internen Korrekturterme durchgeführt sind. Dies soll während der Netzwerk-Leerlaufzeit stattfinden. Nach der Netzwerk-Leerlaufzeit soll ein aggregierter Ratenkorrekturterm, der aus Korrekturkomponenten aus den internen und externen Ratenkorrekturtermen besteht, während der nächsten beiden Kommunikationszyklen angewandt werden. Der aggregierte Offsetkorrekturterm, der aus Korrekturkomponenten aus den internen und externen Offsetkorrekturtermen besteht, soll im Rest der Netzwerk-Leerlaufzeit angewandt werden, bevor der nächste Zyklus startet. Beim Soft-Rücksetzen kann die anfängliche externe Ratenkorrektur durch Setzen des externen Ratenkorrekturterms durch den Host erreicht werden.
Wertebeschränkungen
Bevor sie angewandt werden, sollen die berechneten Korrekturwerte mit vorkonfigurierten Grenzen verglichen werden. Diese Grenzen definieren zwei Regionen, die als die Regionen „Rot" und „Grün" bezeichnet werden, wobei die Farben die Annehmbarkeit des berechneten Werts widerspiegeln (siehe 45). Die grüne Region liegt zwischen –gRateCorrectionOut und +gRateCorrectionOut, und die rote Region außerhalb dieser Grenzen.
Wenn Korrekturwerte in der grünen Region liegen, ist der Knoten voll synchronisiert. Es sind keine weiteren Aktionen notwendig.
Wenn einer der Korrekturwerte in der roten Region liegt, ist der Knoten nicht synchronisiert. Dies entspricht einer Fehlerbedingung. Informationen bezüglich der Handhabung dieser Situation werden später im Text spezifiziert.
Die Korrekturwerte liegen in der grünen Region, wenn folgendes gegeben ist:
–gRateCorrectionOut ≤ vRateCorrection ≤ +gRateCorrectionOut AND
–gRateCorrectionOut ≤ vRateCorrection + vRateCorrectionExtern ≤ +gRateCorrectionOut
–gOffsetCorrectionOut ≤ vOffsetCorrection ≤ +gOffsetCorrectionOut AND
–gOffsetCorrectionOut ≤ vOffsetCorrection + vOffsetCorrectionExtern ≤ +goffsetCorrectionOut
Wenn beide Korrekturwerte im grünen Bereich liegen, ist die Korrektur abgeschlossen.
–gRateCorrectionOut ist die untere Grenze und +gRateCorrectionOut ist die obere Grenze des grünen Bereichs für die Ratenkorrektur.
–gOffsetCorrectionOut ist die untere Grenze und +gOffsetCorrectionOut die obere Grenze des grünen Bereichs für die Offsetkorrektur.
Der Korrekturwert liegt in der roten Region, wenn folgendes gegeben ist:
–gRateCorrectionOut > vRateCorrection OR
+gRateCorrectionOut < vRateCorrection OR
–gRateCorrectionOut > vRateCorrection + vRateCorrectionExtern OR
+gRateCorrectionOut < vRateCorrection + vRateCorrectionExtern – gOffsetCorrectionOut > vOffsetCorrection OR
+gOffsetCorrectionOut < vOffsetCorrection OR
–gOffsetCorrectionOut > vOffsetCorrection + vOffsetCorrectionExtern OR
+gOffsetCorrectionOut < vOffsetCorrection + vOffsetCorrectionExtern
Die Signifikanz von Korrekturwerten in der roten Region hängt davon ab, ob sich der Knoten gerade im Herauffahren befindet oder nicht. Während des Normalbetriebs ist dies als Fehlerbedingung anzusehen. Wenn vRateCorrection OR vRateCorrection + vRateCorrectionExtern außerhalb des spezifizierten Bereichs liegt, wird das Fehlersignal CCLR auf 1 gesetzt. Wenn vOffsetCorrection OR vOffsetCorrection + vOffsetCorrectionExtern außerhalb des spezifizierten Bereichs liegt, wird das Fehlersignal CCLR auch auf 1 gesetzt. Während des Herauffahrens und der Reintegration wird diese Bedingung anders behandelt (siehe später im Text).
Die Werte von gRateCorrectionOut und gOffsetCorrectionOut werden für alle Knoten in dem Cluster identisch spezifiziert. Sie werden in Makroticks oder Bruchteilen eines Makroticks ausgedrückt definiert. Aus diesen clusterweiten Werten sollen die Konfigurationsdaten für jeden Knoten (gemessen in Mikroticks) berechnet werden. Diese Werte sollen in die Konfigurationsschnittstelle aufgenommen werden. Diese Berechnungen werden folgendermaßen zusammengefaßt:
pOffsetCorrectionOut = gOffsetCorrectionOut·pMicroPerMacroNom
pRateCorrectionOut = gRateCorrectionOut·pMicroPerMacroNom
Taktkorrektur
Nach ihrer Berechnung sollen die Korrekturterme zum Modifizieren des lokalen Takts dergestalt verwendet werden, daß er besser mit dem globalen Takt synchronisiert wird. Dies soll durch Verwendung der Korrekturterme zur Einstellung der Anzahl der Mikroticks in jedem Makrotick erreicht werden.
Die Ratenkorrektur soll durch Modifizieren des Werts von vRateCorrection (siehe Prozedur 9) erreicht werden, der danach über die den nächsten Zyklus bildenden Makroticks verteilt werden soll.
Die Offsetkorrektur soll durch Modifizieren des Werts von vOffsetCorrection (siehe Prozedur 8) erreicht werden, der danach über die aktuelle Netzwerk-Leerlaufzeit bildenden Makroticks verteilt werden soll.
Ratenkorrektur
Der Ratenkorrekturterm soll gleichmäßig über den gesamten Zyklus verteilt werden (siehe 44).
Prozedur 10: Verteilung von Mikroticks über Makroticks
Prozedur-Anmerkungen:
Dies ist nur ein Beispiel.
Wie bereits erwähnt, scheint es unwahrscheinlich zu sein, daß die Variable vMicroPerMacroRateCorr explizit in Hardware berechnet werden kann. Wahrscheinlicher ist, daß die Prozedur IncrementMacrotickCounter ein intrinsischer Teil mindestens des Ratenteils des Mikrotickverteilungsautomaten sein wird.
Offsetkorrektur
Die Offsetkorrektur soll während der Netzwerkleerlaufzeit durch Vergrößern oder Verkleinern der Größe der Makroticks abhängig von dem Wert von vOffsetCorrection erfolgen. Es ist nicht erforderlich, daß alle Steuerungen ihre Offsetkorrektur identisch durchführen. Sie sollen jedoch die Offsetkorrektur in der Netzwerk-Leerlaufzeit durchführen. Die Offsetkorrektur sollte mindestens einen Makrotick vor dem Ende der NIT und deshalb vor dem Ende des Kommunikationszyklus abgeschlossen sein.
Der Offsetkorrekturterm vOffsetCorrection ist eine vorzeichenbehaftete ganze Zahl, die der Anwendung sichtbar sein soll. Die maximale Anzahl der Mikroticks, um die ein Makrotick (aufgrund der Offsetkorrektur und der Ratenkorrektur kombiniert) vergrößert werden kann, soll durch eine Konfigurationskonstante pMicroPerMacroMax begrenzt werden. Der Offsetkorrekturterm vOffsetCorrection soll bis zu der durch pMicroPerMacroMax zulässigen Grenze über den ersten und nachfolgende Makroticks hinweg verteilt werden, bis der gesamte Offsetterm verteilt ist.
Die maximale Anzahl der Mikroticks, um die ein Makrotick (aufgrund von Offsetkorrektur und Ratenkorrektur kombiniert) verkleinert werden kann, soll durch eine Konfigurationskonstante pMicroPerMacroMin begrenzt sein. Der Offsetkorrekturterm vOffsetCorrection soll bis zu der durch pMicroPerMacroMin zulässigen Grenze über den ersten und nachfolgende Makroticks verteilt werden, bis der gesamte Offsetterm verteilt ist.
pMicroPerMacroMax ist die maximale Länge eines Makroticks in Mikroticks.
pMicroPerMacroMin ist die minimale Länge eines Makroticks in Mikroticks.
Prozedur 11: Offsetkorrektur
Taktsynchronisationsparameter
Die folgenden Parameter sind für die Taktsynchronisation spezifisch
Aufwecken, Herauffahren und Reintegration
Einführung
Dieser Abschnitt beschreibt die Aufweck- und Herauffahrmechanismen von FlexRay. Bevor das Herauffahren durchgeführt werden kann, muß das Cluster wach sein, so daß das Aufwecken abgeschlossen sein muß, bevor das Herauffahren beginnen kann.
Als erstes wird eine vereinfachte Beschreibung beider Prozesse gegeben. Die Absicht dieser Beschreibungen ist die Bereitstellung einer Übersicht über den Prozeß zur Erleichterung eines grundlegenden Verständnisses. Die technischen Einzelheiten werden absichtlich bis später in dem Kapitel zurückgestellt.
Danach wird das Aufwecken ausführlicher beschrieben. Es werden zwei Beispiele angegeben, um Einsichten in die kombinierten Bemühungen der Hosts und Kommunikationssteuerungen des Clusters bei der Durchführung des Aufweckens zu geben.
Nach dem Aufweckteil wird das Herauffahren zuerst für FlexRay-Cluster in einem der zeitgetriggerten Protokollbetriebsarten und dann für FlexRay-Cluster unter Verwendung des byteflight-Protokollmodus oder der ereignisgetriggerten Protokollmoduserweiterung beschrieben.
FlexRay-Aufwecken und -Herauffahren – eine Funktionalbeschreibung
Dieser Abschnitt erläutert die Grundarbeitsweisen der FlexRay-Aufweck- und Herauffahrprozedur unter Verwendung von Flußdiagrammen und Textbeschreibungen auf hoher Ebene. Später in diesem Kapitel werden die Aufweck- und Herauffahrprozesse unter Verwendung von Automaten definiert, wobei eine genaue Definition der in diesem Abschnitt absichtlich weggelassenen Einzelheiten gegeben wird.
Aufwecken
47 zeigt eine globale Struktur des Aufweckens. An einem beliebigen Zeitpunkt können sich bestimmte Knoten (möglicherweise alle bis auf einen) in dem FlexRay-Cluster in einem Energiesparmodus befinden. Mindestens einer dieser Knoten, die wach sind, möchte möglicherweise ein Herauffahren des gesamten Clusters einleiten. Bevor ein Knoten mit den anderen Knoten kommunizieren kann, müssen sie jedoch wach sein, so daß der Aufweckprozeß dem Herauffahrprozeß vorausgehen muß.
Das Protokoll definiert ein Aufweckmuster, das, wenn es ohne Fehler über den Bus gesendet wird, bewirkt, daß alle anderen Knoten aufwachen. Die Kommunikationssteuerung gibt dem Host eine Prozedur zum Senden dieses Musters auf seinen Kanälen. Um die Gefahren des Störens einer ablaufenden Kommunikation zu begrenzen, darf die Kommunikationssteuerung dieses Muster nur auf einem ihrer möglicherweise zwei angeschlossenen Kanäle auf einmal senden.
Der Host leitet den Aufweckprozeß ein, woraufhin die Kommunikationssteuerung ihre Kanäle auf bedeutungsvolle Kommunikation überwacht, die aus Rahmen, Aufwecksymbolen oder CAS-Symbolen besteht. Das Ergebnis dieser Überwachung bestimmt das weitere Aufweckverhalten. Wenn nichts Bedeutungsvolles empfangen wird, wird das Aufweckmuster gesendet; andernfalls bricht die Kommunikationssteuerung den Aufweckversuch mit einer Fehlernachricht an den Host ab. Die Übertragung des Aufweckmusters wird abgebrochen, wenn während der Übertragung eine Kollision erfaßt wird. In diesem Fall überwacht die Kommunikationssteuerung den Kanal bzw. die Kanäle nochmals, um den Grund für die Kollision zu bestimmen.
Das FlexRay-Protokoll unterstützt keine teilweisen Netzwerke, d.h. Netzwerke, in denen ein Teil der Knoten wach ist und andere Knoten schlafen. Dies hat zur Folge, daß der Aufweckprozeß versucht, auf allen verfügbaren Kanälen alle Knoten aufzuwecken, bevor das Herauffahren eingeleitet wird. Es hat außerdem zur Folge, daß ein Cluster, das bereits kommuniziert, bereits voll wach ist und keine weiteren Aufweckprozeduren erfordert.
Aufweck-Kanalüberwachung
48 zeigt eine Struktur der Aufweck-Kanalüberwachung. Zur leichteren Präsentation wurde der Prozeß zum Horchen nach Rahmen und Aufwecksymbolen seriell abgebildet, obwohl diese Prozesse tatsächlich gleichzeitig ablaufen sollten.
Die Phase „Aufweck-Kanalüberwachung" stellt sicher, daß keine ablaufende Kommunikation durch die Übertragung des Aufweckmusters gestört wird. Es wird eine Horchzeit definiert, in der die Kommunikationssteuerung versucht, eine bedeutungsvolle Kommunikation auf ihren angeschlossenen Kanälen zu erkennen.
Wenn Rahmen empfangen werden, wird das Aufwecken sofort abgebrochen. Ein „empfangener Rahmen" wird in diesem Kontext als aufgetreten seiend betrachtet, wenn das Ereignis S_SuccessfulHeaderReception für einen der konfigurierten Kanäle auftritt. Da bereits andere Knoten miteinander kommunizieren, ist kein Aufwecken notwendig (derjenige, der das Cluster-Herauffahren eingeleitet hat, stellt sicher, daß alle verfügbaren Kanäle wach sind). Dasselbe gilt, wenn ein Aufwecksymbol auf dem Kanal empfangen wird, den die Kommunikationssteuerung versucht, aufzuwecken.
Der Empfang eines CAS-Symbols verlängert die Horchphase. Wie in den folgenden Abschnitten beschrieben wird, kann erwartet werden, daß ein Rahmen bald nach der CAS folgt, wenn es sich wirklich um ein CAS-Symbol und nicht um Rauschen handelte, so daß der Empfang dieses Rahmens dazu verwendet wird, den Abbruch zu triggern. Dadurch verringert sich die Empfindlichkeit des Prozesses gegenüber Rauschen, da als ein CAS-Symbol wahrgenommenes Rauschen den Prozeß nicht abbricht. Wenn die Horchphase vorüber ist, wartet die Kommunikationssteuerung darauf, daß mindestens ein Kanal frei wird. Dadurch verringert sich das Risiko des Unterbrechens der Kommunikation, die gerade empfangen wird. Es kann nicht verlangt werden, daß beide Kanäle in einem Zweikanalsystem frei sind, da dann ein fehlerhafter, rauschbehafteter Kanal das Systemaufwecken verhindern könnte. Insbesondere während der Herauffahrphase, in der die Kommunikation spärlicher ist und dadurch leichter als in späteren Phasen übersehen werden kann, treten die meisten Symbole und Rahmen auf beiden Kanälen gleichzeitig auf. Z.B. wird das CAS-Symbol gleichzeitig auf beiden Kanälen übertragen. Die Forderung, daß mindestens ein Kanal frei ist, verhindert, daß das Aufwecken zu senden beginnt, während ein solches Symbol auf beiden Kanälen empfangen wird, aber bevor es erkannt wird. Die Kommunikationssteuerung erlaubt nur eine vordefinierte Anzahl von Versuchen, das Aufweckmuster zu senden. Wenn diese Anzahl überstiegen wird, wird der Aufweckprozeß abgebrochen.
Aufweckmusterübertragung
49 zeigt eine Struktur einer Aufweckmusterübertragung. Das Aufweckmuster besteht aus mehreren Wiederholungen des Aufwecksymbols. Das (oben definierte) Aufwecksymbol besteht aus einer aktiven und einer Leerlaufzeitspanne. Die Kommunikationssteuerung horcht während der Leerlaufzeitspanne auf Kanalaktivität. Wenn diese Aktivität eine Schwelle übersteigt, wird die Übertragung abgebrochen. Dieser Mechanismus löst Kollisionen zwischen mehreren Knoten auf, die fast zur selben Zeit beginnen, das Aufweckmuster zu senden. Diese Schwelle wird so gewählt, daß sichergestellt wird, daß mindestens ein Knoten weiter das Muster überträgt. Während das Aufweckmuster selbst kollisionsbeständig ist und noch erkennbar ist, wenn zwei solche Muster kollidieren, ist es diese Erfassung in der Leerlaufzeitspanne, durch die der Aufweckmechanismus gegenüber einer Anzahl von Kollisionen robust wird.
Wenn eine solche Kollision erfaßt wird, kehrt die Kommunikationssteuerung zu der Phase „Kanalüberwachung" zurück. Dort kann eine Kollision mit einem anderen Aufweckmuster verifiziert und dem Host signalisiert werden.
Nach einer erfolgreichen Übertragung des Aufweckmusters oder dem Abbruch des Aufweckversuchs kehrt die Kommunikationssteuerung zu ihrem Rücksetzzustand zurück und wartet auf Anweisungen von dem Host.
FlexRay-Herauffahren – zeitgetriggerter Protokollmodus
Das Herauffahren nimmt an, daß alle Knoten in dem Cluster wach sind (mindestens im fehlerfreien Fall). Nur mit allen verfügbaren Kanälen verbundene Knoten können als sync-Knoten (die das Cluster herauffahren dürfen) konfiguriert werden. Ohne Fehler sind also die Übertragungen eines sync-Knotens jedem Knoten in dem Cluster sichtbar.
Das Herauffahren legt ein globales Zeitsteuerungsschema fest, das – innerhalb gewisser Grenzen – in allen Knoten in dem Cluster dasselbe ist. Die Möglichkeit, den richtigen Zeitpunkt zum Senden und/oder Empfangen jedes Rahmens berechnen zu können, verläßt sich darauf. Außerdem verläßt sich der Taktsynchronisationsalgorithmus auf dieses grundlegende Zeitsteuerungsschema, so daß alle Knoten Taktkorrekturterme gleichzeitig (am Ende ungeradzahliger Zyklen) anwenden können.
Das maximale Takt-Driften, das zwischen zwei beliebigen Knoten in einem Cluster innerhalb eines Zyklus auftreten kann, muß bekannt sein, um die notwendigen Horchzeitgrenzen zu konfigurieren.
Bis ein Knoten in die Protokollbetriebsphase eintritt, die der Protokollherauffahrphase (siehe unten) folgt, müssen seine Nachrichtenpuffer nicht aktualisiert werden. Vor diesem Zeitpunkt ist kein Datenrahmensenden und -empfangen möglich. 50 zeigt eine globale Struktur des Herauffahrens.
Jeder korrekt konfigurierte Knoten beginnt den Herauffahrprozeß (nach dem Beenden des Aufweckprozesses für kaltstartfähige Knoten (durch Eintreten in die Phase „Kanalüberwachung und Auswahl des Herauffahrweges". Jeder Knoten, der das Cluster herauffahren darf, überwacht seine angeschlossenen Kanäle und nimmt an dem Prozeß der Auswahl des Initiators des Kaltstartprozesses teil. Dieser Prozeß ist so ausgelegt, daß alle bis auf einen sync-Knoten eliminiert werden, der dann die Verantwortung für die Durchführung des Kaltstarts übernimmt. Dieser Kaltstartinitiator überquert den rechten Weg in 50.
Alle anderen Knoten warten passiv darauf, daß der ausgewählte Knoten die Kommunikation einleitet. Der Empfang eines sync-Rahmens mit einem geraden Zykluszähler (angezeigt durch S_ValidEvenStartupFrame) bewirkt, daß sie in den links in 50 gezeigten Integrationsweg eintreten.
Nachdem die designierte Prüfung erfolgreich war, tritt der Knoten in den Normalbetrieb ein und darf Datenrahmen senden.
Kanalüberwachung und Auswahl des Herauffahrweges
51 zeigt eine Struktur der Kanalüberwachung und Auswahl eines Herauffahrweges. Die Phase „Herauffahrkanalüberwachung" ist der Kanalüberwachungsphase des Aufweckens ähnlich. Jeder Knoten hört seine angeschlossenen Kanäle an und versucht, ablaufende Kommunikation zu erkennen. Wenn ein S_ValidEvenStartupFrame empfangen wird, tritt der Knoten in den Integrationsweg ein. Die sync-Knoten, die das Cluster herauffahren dürfen, warten, daß ihre Horchzeitgrenze abläuft. Ein empfangener Rahmen (S_SuccessfulHeaderReception) oder ein CAS-Symbol (S_CASReception) verlängert die Zeitgrenze. Wenn die Zeitgrenze abläuft, tritt der Knoten in den Kaltstartweg ein. Fall überhaupt keine Aktivität erkannt wird, läuft eine spezielle Zeitgrenze ab und ermöglicht dadurch ein schnelleres Herauffahren.
Auswahl des ColdStart-Initiators
52 zeigt eine Struktur der Auswahl eines ColdStart-Initiators. Nach dem Ablaufen der Horchzeitgrenze in der Kanalüberwachungsphase senden die dafür konfigurierten sync-Knoten ein CAS-Symbol. Dieses CAS-Symbol setzt die Horchzeitgrenze anderer potentieller Kaltstartinitiatoren, die sich noch in der Horchphase befinden, zurück, so daß diese in der Überwachungsphase verbleiben. Nach der Übertragung initialisieren diese Knoten ihre Kommunikationsablaufsteuerung und warten auf ihren zugewiesenen Schlitz, indem sie einen sync-Rahmen mit Zykluszähler Null senden. Dieser sync-Rahmen erzwingt, daß alle Knoten in der Überwachungsphase in den Integrationsweg eintreten.
Es können mehrere Knoten nahezu gleichzeitig in die Auswahlphase eintreten und ihr CAS-Symbol nahezu gleichzeitig senden. Diese Situation wird aufgelöst, indem von Knoten in dieser Phase verlangt wird, wieder in die Überwachungsphase einzutreten, wenn sie einen sync-Rahmen oder ein CAS-Symbol empfangen. Aufgrund der unzweideutigen Zuweisung von Schlitzen zu den verschiedenen Knoten verlassen alle Knoten bis auf einen (gewöhnlich den des frühesten Schlitzes) diese Phase nach höchstens drei Zyklen (Taktoszillatorabweichungen können einen zweiten oder dritten Zyklus zur Kollisionsauflösung erfordern).
Nach drei Zyklen treten die Knoten in die Prüfung „Kommunikation hergestellt" ein.
Prüfung auf erfolgreich hergestellte Kommunikation
53 zeigt eine Prüfung auf eine erfolgreich hergestellte Kommunikation. Der Kaltstartinitiator hat drei sync-Rahmen übertragen, ohne unterbrochen worden zu sein. Nun kann er die ersten Antworten anderer sync-Knoten erwarten. Er sendet seinen sync-Rahmen weiter in dem designierten Schlitz.
Am Ende jedes Zyklus betrachtet er die sync-Rahmen, die er während des aktuellen Zyklus empfangen hat. Wenn er mehr sync-Rahmen empfangen hat, die nicht in seine Kommunikationsablaufsteuerung passen, als sync-Rahmen, die in seine Kommunikationsablaufsteuerung passen, bricht er das Herauffahren ab und tritt wieder in die Überwachungsphase ein. Dieses Verhalten verhindert die Erzeugung mehrerer Klicken mit nicht übereinstimmenden Wahrnehmungen der Zeit.
Am Ende jedes ungeraden Zyklus führt der Kaltstartinitiator zusätzliche Tests durch. Wenn mindestens ein Paar sync-Rahmen empfangen wurde, führt er die Taktsynchronisation unter Verwendung dieser Paare durch (siehe das Kapitel „Taktsynchronisation"). Wenn die resultierenden Korrekturwerte außerhalb spezifizierter Grenzen liegen, bricht er den Kaltstart ab und tritt wieder in die Überwachungsphase ein. wenn die werte innerhalb der spezifizierten Grenzen liegen und mindestens ein Paar sync-Rahmen empfangen wurde, tritt er in die Normalbetriebsart ein. Dadurch wird sichergestellt, daß mindestens zwei sync-Knoten in bezug auf die Zeitsteuerungsablaufsteuerung übereinstimmen, bevor irgendwelche Datenrahmen übertragen werden können. Es ermöglicht eine stabile Taktsynchronisation für die beiden Knoten und alle anderen Knoten, die sich danach in die nun hergestellte Kommunikation integrieren.
Ein Zähler beobachtet, wie viele Zyklen der Kaltstartinitiator in dem Kaltstartweg verbringt. Wenn zu viele Zyklen vergehen, ohne daß dieser Knoten in die Normalbetriebsart eintritt, wird das Herauffahren abgebrochen und der Knoten darf nicht nochmal versuchen, das Cluster heraufzufahren. Dadurch wird verhindert, daß fehlerhafte Knoten dauerhaft das Herauffahren stören.
Anfängliche Synchronisation
54 zeigt eine Struktur einer anfänglichen Synchronisation. Wenn ein Knoten in der Überwachungsphase einen sync-Rahmen mit geradem Zykluszähler (S_ValidEvenStartupFrame) empfängt, tritt er in den Integrationsweg ein. Der Knoten, der den sync-Rahmen gesendet hat, wird automatisch zu dem Referenzknoten für den Empfänger.
Wenn dieser Referenzknoten der Referenzknoten bei einem zuvor erfolglosen Integrationsversuch war, wird er nicht ausgewählt und es wird auf einen weiteren sync-Rahmen gewartet. Wenn innerhalb eines spezifizierten Zeitraums kein sync-Rahmen von einem anderen Knoten empfangen wird, wird dem zuvor erfolglos gebliebenen Referenzknoten eine neue Chance gegeben.
Der sich integrierende Knoten setzt seinen eigenen Zykluszähler auf den in dem sync-Rahmen empfangenen Wert und wartet auf den sync-Rahmen des Referenzknotens in dem folgenden ungeraden Zyklus. Unter Verwendung dieses Rahmenpaars korrigiert der sich integrierende Knoten seinen Takt in Richtung der Zeitsteuerung des Senders dieser Rahmen. Wenn kein sync-Rahmen mit einem ungeraden Zykluszähler dem geradzahligen Rahmen, der den Integrationsversuch getriggert hat, folgt, bricht der Knoten die Integration ab.
Prüfung auf erfolgreiche Integration
55 zeigt eine Prüfung auf eine erfolgreiche Integration. Während dieser Prüfphase darf der Knoten immer noch keine Rahmen senden. Er hat nun ein Verständnis der aus seinem Referenzknoten abgeleiteten Zeit. Während des nachfolgenden Zyklus horcht er auf sync-Rahmen von allen Knoten, nicht nur von seinem Referenzknoten. Der Knoten prüft die Zeitsteuerungsinformationen, die er aus dem Referenzknoten abgeleitet hat, im Vergleich zu aller beobachtbarer Kommunikation, wobei nur sync-Rahmen betrachtet werden.
Am Ende jedes Zyklus bestimmt er, ob die Mehrheit der beobachteten sync-Rahmen mit dem von ihm abgeleiteten Zeitsteuerungsschema vereinbar ist. Wenn nicht, deklariert er seinen Integrationsversuch als erfolglos und tritt wieder in die Überwachungsphase ein. Man beachte, daß er für den folgenden neuen Integrationsversuch wie oben beschrieben versucht, einen anderen sync-Knoten als Referenzknoten auszuwählen.
Am Ende jedes ungeraden Zyklus führt er die in dem Kapitel „Taktsynchronisation" beschriebene Offsettaktkorrektur durch. Die berechneten Taktkorrekturterme für Offset und Rate werden mit spezifizierten Grenzen verglichen. Die Grenzen für die Offsetkorrektur sind während der ersten Durchführung der Korrektur nach dem Eintreten in diese Prüfphase weniger streng. Wenn entweder der Raten- oder der Offsetkorrekturwert außerhalb der definierten Grenzen liegt, bricht der sich integrierende Knoten den Integrationsversuch ab und tritt wieder in die Überwachungsphase ein.
Außerdem zählt am Ende jedes ungeraden Zyklus der Knoten die Anzahl der Schlitze, in denen er gerade/ungerade Zykluspaare von sync-Rahmen empfangen hat. Wenn keine Paare empfangen wurden, bricht der Knoten den Integrationsversuch ab, weil, wenn überhaupt, sync-Rahmen von dem Referenzknoten empfangen worden sein müßten. Wenn mehr als ein Paar empfangen wurde, tritt der Knoten in die Normalbetriebsart ein. Wenn es dem sich integrierenden Knoten erlaubt ist, selbst sync-Rahmen zu senden und ein Paar sync-Rahmen empfangen wurde, tritt er auch in den Normalbetrieb ein. Im Normalbetrieb, d.h. während der Protokollbetriebsphase, darf der Knoten Daten und sync-Rahmen senden (falls nicht anders konfiguriert).
Der Aufweck- und der Herauffahr-Modus – globale Struktur
Aus dem Zustand CC_SoftReset heraus soll der Host in der Lage sein, über den Übergang G1 (siehe 56) das Cluster-Aufwecken einzuleiten. Für Aufweck- und auch für die distinkten Herauffahrprozeduren arbeitet die Kommunikationssteuerung in dem Top-Level-HW-Zustand CC_Normal. Ferner soll abhängig davon, wie die Konfigurationseinstellungen gewählt werden, von dem Zustand CC_SoftReset aus in einen von drei distinkten Herauffahrautomaten eingetreten werden.
Im zeitgetriggerten Protokollmodus, d.h. im zeitgetriggerten verteilten Modus (TT-D) und im zeitgetriggerten mastergesteuerten Modus (TT-M) soll durch den Übergang G2 ein auf sync-Rahmen basierender Herauffahrmechanismus getriggert werden.
Für FlexRay-Cluster, die im TT-D-Modus laufen, soll ein fehlertolerantes verteiltes Herauffahren durchgeführt werden. Im TT-M-Modus soll ein mastergesteuertes Herauffahren durchgeführt werden, aber alle Mechanismen bauen weiterhin auf einem zeitgetriggerten Kommunikationszyklus auf.
Für den byteflight-(BF)-Protokollmodus und den ereignisgetriggerten (ET)-Protokollmodus hängt der notwendige Herauffahrautomatenübergang (G3, G4 bzw. G5, G6) davon ab, ob ein Knoten als ein Master konfiguriert ist oder nicht.
Für den ereignisgetriggerten Protokollmodus wird das Herauffahrverhalten später beschrieben.
Tabelle 12: Globale Herauffahr-Zustandsübergänge und jeweilige Bedingungen für die Ausführung
Die Übergänge W1 und W5 werden in Tabelle 13 und der Übergang A1 in Tabelle 14 beschrieben.
Cluster-Aufwecken
Dieser Abschnitt beschreibt den Aufweckweg, der dem Kommunikationsherauffahren vorausgeht.
Jeder Knoten, der in das Herauffahren eintritt und Kaltstartfähigkeit besitzt, soll zuerst die Aufweckprozedur ausführen. Andernfalls kann nicht sichergestellt werden, daß das Cluster wach ist (oder zumindest daß das Aufwecken getriggert wurde), bevor der Knoten die Herauffahrprozedur beginnt.
Der Host steuert die Aufweckprozedur vollständig. Die Kommunikationssteuerung gibt dem Host die Fähigkeit, auf jedem seiner verfügbaren Kanäle ein spezielles Aufweckmuster (siehe oben) zu senden. Dadurch wird sichergestellt, daß die ablaufende Kommunikation auf diesem Kanal nicht gestört wird. Die Kommunikationssteuerung kann nicht garantieren, daß alle mit diesem Kanal verbundenen Knoten aufgrund der Übertragung des Aufweckmusters aufwachen (zum Beispiel könnte die Übertragungseinheit des Bustreibers defekt sein), da diese Knoten bis zur Herauffahrphase keine Rückmeldungen geben können. Der Host muß über mögliche Ausfälle des Aufweckens wissen und entsprechend handeln.
Durch die Aufweckprozedur können einkanalige Einrichtungen in einem Zweikanalsystem das Aufwecken triggern, indem sie einfach nur auf dem einzigen Kanal, mit dem sie verbunden sind, das Aufweckmuster senden. Ein anderer Knoten übernimmt dann die Verantwortung für das Wecken des anderen Kanals. Jeder Knoten mit Kaltstartfähigkeit muß vor dem Eintreten in das Herauffahren beide Kanäle wecken. Jeder Knoten ohne Kaltstartfähigkeit, der mit beiden Kanälen verbunden ist, muß beide Kanäle wecken, wenn er das Cluster aufwecken möchte.
Die Aufweckprozedur toleriert, wenn eine beliebige Anzahl von Knoten gleichzeitig versucht, einen einzelnen Kanal aufzuwecken, und löst diese Situation so auf, daß nur ein Knoten das Muster sendet. Zusätzlich ist das Aufweckmuster kollisionsbeständig, so daß sogar bei Anwesenheit eines fehlerhaften Knotens, der auch ein Aufweckmuster sendet, das Aufwecken sichergestellt werden kann.
Wecken eines Kanals
Das Aufwecken des FlexRay-Systems muß von einem Host eingeleitet werden. Der Host eines Knotens kann seiner Kommunikationssteuerung befehlen, ein Tx-Aufweckmuster auf dem Kanal vWakeupChannel zu senden, während sich die Kommunikationssteuerung selbst in dem Zustand CC_SoftReset befindet. Die Kommunikationssteuerung tritt dann in ihren Aufweckmodus ein und versucht, auf dem konfigurierten Kanal ein Tx-Aufweckmuster zu senden. Als letztes signalisiert sie dem Host den Status des Aufweckversuchs zurück (siehe den Aufweckstatusvektor später im Text).
Am Aufweckmodus der Kommunikationssteuerung sind drei Zustände beteiligt:
CC_SoftReset
CC_WakeupListen
CC_WakeupSend
Aufweck-Zustandsdiagramm
Die Struktur des Kommunikationssteuerungs-Aufweckautomaten ist in 57 gezeigt.
Tabelle 13: Aufweck-Zustandsübergänge und entsprechende Bedingungen für die Ausführung.
Der Zustand CC_SoftReset ist Teil des Gesamt-Protokollzustandsdiagramms. Nur in dem Zustand CC_SoftReset kann der Host die Kommunikationssteuerung konfigurieren und ein Aufwecken auf dem Kanal vWakeupChannel initialisieren (G1). Nach dem Aufwecken kehrt die Kommunikationssteuerung in den Zustand CC_SoftReset zurück und signalisiert dem Host das Ergebnis des Aufweckversuchs:
Abbruch, weil die Kommunikationssteuerung einen Rahmenkopfteil ohne Codierungsverletzung empfangen hat, signalisiert durch Setzen des Flags vWakeupFrameHeaderReceived (W1).
Abbruch, weil die Kommunikationssteuerung ein gültiges Rx-Aufwecksymbol auf dem Kanal vWakeupChannel empfangen hat, signalisiert durch Setzen des Flags vWakeupSymbolReceived (W1).
Abbruch aufgrund zu vieler Aufweckversuche, signalisiert durch Setzen des Flags vWakeupFailed (W1). Vollständige Übertragung des Tx-Aufweckmusters, signalisiert durch Setzen des Flags vWakeupComplete (W5).
Der Parameter gWakeupMax definiert die maximal zulässige Anzahl der Aufweckversuche. Der Parameter vWakeupChannel definiert den Kanal, den die Kommunikationssteuerung wecken soll.
Der Zustand CC_WakeupListen
Der Zweck dieses Zustands besteht darin, sicherzustellen, daß die Übertragung des Tx- Aufweckmusters keine existierende Kommunikation auf dem Kanal vWakeupChannel stört.
Der Zähler vWakeupCount wird beim Übergang G1 von dem Zustand CC SoftReset zu dem Zustand CC_WakeupListen auf Null gesetzt. Es werden zwei Timer definiert:
vdWakeup
vdWakeupNoise
Beide Timer werden bei Eintritt in den Zustand CC_WakeupListen auf Null gesetzt.
Der Timer vdWakeup läuft beim Erreichen von gdCycle + gdMaxDrift (eine Zykluslänge plus eine Sicherheitsreserve) ab. Der Timer vdWakeupNoise läuft beim Erreichen der Zeitdauer ab, während der das Cluster in der Lage ist, die Taktsynchronisation innerhalb des maximal spezifizierten Toleranzbandes aufrechtzuerhalten.
Der Timer vdWakeup wird immer dann zurückgesetzt, wenn auf einem der Kanäle Aktivität empfangen wird.
Der Timer vdWakeupNoise wird immer dann zurückgesetzt, wenn auf irgendeinem Kanal ein gültiges CAS-Symbol empfangen wird (S_CASReception aufgetreten). Ein CAS-Symbol ist – abhängig von der Bitrate – relativ kurz, so daß Rauschen als ein CAS-Symbol fehlinterpretiert werden könnte. Um einen Abbruch der Aufweckprozedur aufgrund von Rauschen zu verhindern, wird nur der Zähler zurückgesetzt, wenn ein CAS-Symbol empfangen wird. Nur der dem CAS-Symbol folgende Rahmen triggert den Abbruch. Ferner könnte es schwierig sein, ein CAS-Symbol von dem ersten Teil eines Tx-Aufweckmusters zu unterscheiden.
Wenn die Kommunikationssteuerung einen Rahmenkopfteil ohne Codierungsverletzung auf irgendeinem Kanal empfängt (angezeigt durch S_SuccessfulHeaderReception), tritt sie wieder in den Zustand CC_SoftReset ein und setzt das Flag vWakeupFrameHeaderReceived (W1). Eine Kommunikationssteuerung darf kein Tx-Aufweckmuster senden, wenn eine ablaufende Kommunikation detektiert wird. Der Empfang eines Rahmenkopfteils ohne Codierungsverletzung ist für die Detektion einer ablaufenden Kommunikation robust genug.
Wenn die Kommunikationssteuerung ein gültiges Rx-Aufwecksymbol auf dem Kanal vWakeupChannel empfängt, tritt sie wieder in den Zustand CC_SoftReset ein und setzt das Flag vWakeupSymbolReceived (W1). (Die Detektion soll weniger streng als die starre Definition des Rx-Aufwecksymbols sein, um Topologieeffekte, Kollisionen und verschiedene Taktgeschwindigkeiten zu berücksichtigen.) Ein Rx-Aufwecksymbol auf dem anderen Kanal (falls verfügbar) wird ignoriert.
Wenn einer der Timer abläuft und (vWakeupCount < gWakeupMax) gilt und mindestens ein Kanal sich im Leerlaufzustand befindet, tritt die Kommunikationssteuerung in den Zustand CC_WakeupSend ein (W2). Alle bedeutungsvolle Kommunikation während des Herauffahrens wird auf beiden Kanälen gleichzeitig übertragen. Durch Fordern, daß ein Kanal leerläuft, wird sichergestellt, daß keine solche Übertragung durch die Übertragung des CAS-Symbols unterbrochen wird (innerhalb der Unbestimmtheit der Übertragungsverzögerung). Es kann nicht gefordert werden, daß beide Kanäle leerlaufen, da ein Kanal defekt und rauschbehaftet sein könnte und dadurch jeden Aufweck- und Herauffahrversuch verhindert.
Wenn einer der Timer abläuft und (vWakeupCount == gWakeupMax) gilt und mindestens ein Kanal sich im Leerlaufzustand befindet, tritt die Kommunikationssteuerung wieder in CC_SoftReset ein und setzt vWakeupFailed in dem Aufweckstatusvektor (W1). Das Aufwecken wird erst nach dem Erreichen der maximalen Anzahl von Versuchen, wenn ein Timer abläuft, abgebrochen. Dadurch hat die Kommunikationssteuerung Zeit, in dem Netzwerk nach Ablaufen der Kommunikation oder Aufweckmustern zu horchen, nachdem sie aus dem Zustand CC_WakeupSend zurückgeschritten ist.
Der Zustand CC_WakeupSend
In diesem Zustand sendet die Kommunikationssteuerung das Tx-Aufweckmuster auf dem konfigurierten Kanal und prüft auf Kollisionen.
Nach dem Eintritt in den Zustand CC_WakeupSend wird vWakeupCount um eins erhöht.
Das oben beschriebene Tx-Aufweckmuster wird auf dem Kanal vWakeupChannel gesendet.
Während der Leerlaufphasen des Tx-Aufweckmusters horcht die Kommunikationssteuerung nach Aktivität auf dem Bus. Wenn die Kommunikationssteuerung mehr als gdWakeupMaxCollision eines kontinuierlichen „aktive-low" während einer Leerlaufphase empfängt (diese Prüfung wird oben ausführlich beschrieben und das Auftreten dieses Ereignisses wird durch S_CheckWakeupCollision. signalisiert), schreitet sie sofort in den Zustand CC_WakeupListen zurück (W6). Ohne dieses Horchen und Abbrechen würden nicht alle Kollisionen zu erkennbaren Aufwecksymbolen führen (man erinnere sich, daß das Tx-Aufweckmuster selbst nur gegenüber Kollisionen von bis zu zwei solchen Mustern beständig ist). Je kleiner pdWakeupMaxCollision ist, desto besser wird die Kollisionsdetektion, aber die EMC-Robustheit verschlechtert sich. Eine Untergrenze für den Wert könnte das Äquivalent von 400 ns, für ein System mit 10 Mbit/s sein.
Nach einer vollständigen, nicht abgebrochenen Übertragung des Tx-Aufweckmusters tritt die Kommunikationssteuerung wieder in den Zustand CC_SoftReset ein und setzt das Flag vWakeupComplete in dem Aufweckstatusvektor (W5).
Aufweckanwendung-Anmerkungen
Da der Host stark an dem Aufwecken des FlexRay-Clusters beteiligt ist, wird in diesem Abschnitt das erforderliche Hostverhalten beschrieben. Der Host muß den Aufweckmodus des Buswächters und der Kommunikationssteuerung koordinieren. Er muß das Aufwecken zweier Kanäle koordinieren und entscheiden, ob ein spezifischer Kanal geweckt wird oder nicht.
Buswächter
In Systemen, in denen ein Buswächter installiert ist, muß der Host dem entsprechenden Buswächter befehlen, in seinen Aufweckmodus einzutreten, bevor er der Kommunikationssteuerung befiehlt, ein Aufwecken durchzuführen. Nachdem die Kommunikationssteuerung in den Zustand CC_SoftReset zurückgekehrt ist, muß dem Buswächter befohlen werden, seinen Aufweckmodus zu verlassen.
Knoten mit Kaltstartfähigkeit
Jeder Knoten, der dafür konfiguriert ist, einen Kaltstart durchzuführen, muß wie oben beschrieben vor der Fortsetzung des Herauffahrens ein Aufwecken durchführen. Für Zweikanalcluster ist es im allgemeinen ratsam, die nachfolgend beschriebene Prozedur zu verwenden.
Für FlexRay-Cluster im TT-D-Modus umfaßt dies alle sync-Knoten, die nicht in einem Nur-Horchen-Modus konfiguriert sind. Für FlexRay-Cluster im TT-M-Modus umfaßt dies den Master-Knoten.
Aktionen des Host zum Initialisieren des Aufweckens
Ein Host, der ein Aufwecken des Clusters durchführen möchte, muß zuerst seinen bzw. seine Bustreiber prüfen, um zu sehen, ob sie Rx-Aufweckmuster empfangen haben. Wenn der Bustreiber eines Kanals kein Rx-Aufweckmuster empfangen hat, muß der Host versuchen, diesen Kanal zu wecken.
Jede Kommunikationssteuerung, die mit Kaltstartfähigkeit konfiguriert ist, verläßt sich darauf, daß ihr Host das Cluster aufgeweckt hat, bevor er sie in die Herauffahrphase eintreten läßt. Nur der Host kann sicherstellen, daß die Aufweckphase abgeschlossen ist, bevor irgendein Herauffahrversuch durchgeführt wird.
Der Host darf keine Kanäle wecken, deren Bustreiber ein Rx-Aufwecksymbol empfangen haben, wenn nicht ein Herauffahren ohne ein zusätzliches Aufwecken dieser Kanäle unmöglich ist. Dies geschieht zum Beschleunigen des Aufweckprozesses und zur Begrenzung der Verkehrsmenge auf den Kanälen; dadurch wird die Anzahl der Kollisionen während dieser Phase verringert.
Der Host muß dem Buswächter (falls verfügbar) des Kanals vWakeupChannel befehlen, in seinen Aufweckmodus einzutreten. Dann verwendet der Host die oben beschriebene Prozedur zum Einleiten eines Aufweckens des Kanals vWakeupChannel. Die Kommunikationssteuerung kann mehrere verschiedene Statusbedingungen zurückgeben, die in dem folgenden Abschnitt beschrieben werden. Vor der Auswertung dieser Bedingung muß der Host dem Buswächter des Kanals vWakeupChannel befehlen, seinen Aufweckmodus zu verlassen. Wenn der Host nicht bewirkt, daß der BG seinen Aufweckmodus verläßt (BG_WakeUp), verläßt der BG ihn nach einem festen, nicht konfigurierbaren Zeitraum und tritt in den BG_FailSilent-Modus ein.
Reaktionen des Host auf die von der Kommunikationssteuerung signalisierten Status-Flags Dieser Abschnitt definiert die verschiedenen Statusbedingungen, die die Kommunikationssteuerung als Ergebnisse ihres Aufweckversuchs an den Host zurückgeben kann, und die empfohlenen Reaktionen des Host. Diese Bedingungen schließen sich im allgemeinen gegenseitig aus, aber in Zweikanalsystemen könnte auf dem Kanal vWakeupChannel ein Rx-Aufwecksymbol empfangen werden, während auf dem entgegengesetzten Kanal gleichzeitig ein gültiger Rahmenkopfteil empfangen wird. Das Aufwecken erfüllt immer noch seine Funktion, wenn den Austrittsbedingungen ein Vorrang gegeben wird und dadurch bewirkt wird, daß sie sich gegenseitig ausschließen (höchste zu niedrigste Priorität):
Übertragung abgeschlossen, ein Rahmenkopfteil ohne Codierungsverstoß wurde empfangen, ein Rx-Aufwecksymbol wurde empfangen, die zulässige Anzahl von Aufweckungen wurde überschritten.
Ein Rahmenkopfteil ohne Codierungsverstoß wurde empfangen
Wenn ein Rahmenkopfteil ohne Codierungsverstoß von der Kommunikationssteuerung während CC_WakeupListen auf einem der verfügbaren Kanäle empfangen wird, bricht die Kommunikationssteuerung das Aufwecken ab, auch wenn der Kanal vWakeupChannel noch still ist. Der Host darf die Kommunikationssteuerung nicht dafür konfigurieren, zusätzliche Aufweckversuche durchzuführen, da dies eine ablaufende Kommunikation stören kann. Statt dessen soll er die Kommunikationssteuerung dafür konfigurieren, in das Herauffahren einzutreten, um sich in das bereits laufende Cluster zu integrieren.
Ein Rx-Aufwecksymbol wurde empfangen
Die Kommunikationssteuerung hat auf dem Kanal vWakeupChannel während ihres Zustands CC_WakeupListen ein Rx-Aufwecksymbol empfangen. Das heißt, daß ein anderer Knoten bereits diesen Kanal weckt. Um Kollisionen von Tx-Aufweckmustern auf dem Kanal vWakeupChannel zu verhindern, bricht die Kommunikationssteuerung das Aufwecken ab.
Wenn ein anderer Kanal verfügbar ist, der noch nicht wach ist, soll der Host die Kommunikationssteuerung dafür konfigurieren, diesen Kanal zu wecken. Andernfalls soll er die Kommunikationssteuerung dafür konfigurieren, in das Herauffahren einzutreten.
Die Übertragung wurde abgeschlossen
Die Kommunikationssteuerung hat das vollständige Tx-Aufweckmuster auf dem Kanal vWakeupChannel übertragen.
Wenn ein anderer Kanal verfügbar ist, der noch nicht wach ist, soll der Host die Kommunikationssteuerung dafür konfigurieren, diesen Kanal zu wecken. Andernfalls soll er die Kommunikationssteuerung dafür konfigurieren, in das Herauffahren einzutreten.
Die zulässige Anzahl von Aufweckversuchen wurde überschritten
Die Kommunikationssteuerung war nicht in der Lage, ein vollständiges Tx-Aufweckmuster zu übertragen, weil jeder seiner gWakeupMax Versuche, es zu senden, dazu führte, daß mindestens gdWakeupMaxCollision mal ein kontinuierliches „aktive-low" während einer Leerlaufphase des Musters auftrat. Zwei mögliche Gründe hierfür sind starke EMC-Störungen auf dem Bus oder ein plappernder Knoten. Eine, nicht für diesen Abbruch verantwortliche Ursache ist die Kollision mit einem anderen Tx-Aufweckmuster. Eine solche Kollision läßt sich nach dem Wiedereintritt in den Zustand CC_WakeupListen erkennen und würde durch Setzen des Flag vWakeupSymbolReceived signalisiert.
Da kein vollständiges Tx-Aufweckmuster übertragen wurde, kann nicht angenommen werden, daß alle Knoten ein Rx-Aufwecksymbol empfangen haben. Der Host kann die nachfolgend beschriebene Neuübertragungsprozedur verwenden.
Wecken zweier Kanäle
Dieser Abschnitt beschreibt, wie der Host beide Kanäle eines Zweikanalsystems wecken kann.
Es ist einer Kommunikationssteuerung verboten, auf beiden Kanälen gleichzeitig ein Tx-Aufweckmuster zu senden. (Diese Regel wurde eingerichtet, um sicherzustellen, daß eine fehlerhafte Kommunikationssteuerung eine ablaufende Kommunikation nicht durch Senden von Aufweckmustern auf beiden Kanälen gleichzeitig stören konnte). Wenn es also notwendig ist, beide Kanäle zu wecken, muß der Host diese einzeln wecken. Der Host kann die Prozedur zum Senden eines Tx-Aufweckmusters auf einem Kanal (siehe oben) zweimal verwenden – einmal für den ersten Kanal und danach für den zweiten Kanal.
Ein Beispiel für diese Prozedur ist später angegeben.
Neuübertragung von Aufwecksymbolen
Bestimmte Ereignisse können ein Cluster-Aufwecken durch ein Tx-Aufweckmuster verhindern, ohne daß die sendende Kommunikationssteuerung in der Lage ist, es sofort zu erkennen (z.B. ein fehlerhafter Stern, der wesentlich mehr Zeit zum Herauffahren benötigt, um in der Lage zu sein, Nachrichten weiterzuleiten). Nach einem definierten Zeitraum kann der Host einen solchen Fehler erkennen, wenn das Cluster nach dem Aufwecken nicht wie erwartet herauffährt oder der Versuch der eigenen Kommunikationssteuerung des Hosts, das Cluster heraufzufahren, erfolglos bleibt.
Der Host kann dann eine Neuübertragung des Tx-Aufweckmusters durchführen. Er muß den Buswächter (wenn verfügbar) des gewählten Kanals in seinen Aufweckmodus befehlen. Die Kommunikationssteuerung muß in den Zustand CC_SoftReset gebracht werden; zum Senden eines Tx-Aufweckmusters auf dem Kanal vWakeupChannel kann dann die oben beschriebene Prozedur verwendet werden. Danach muß dem Buswächter befohlen werden, seinen Aufweckmodus zu verlassen.
Man beachte, daß dies eine ablaufende Kommunikation anderer Knoten stören kann, wenn der die Aufweckprozedur durchführende Knoten einen Ausfall der ankommenden Strecke erfährt.
Übergang zum Herauffahren
Es kann mehrere Hundert Millisekunden (abhängig von der verwendeten Hardware) dauern, bevor alle Knoten und Sterne vollständig geweckt und konfiguriert sind. Um ein Herauffahren in dem zeitgetriggerten verteilten Protokollmodus von FlexRay durchzuführen, sind mindestens zwei sync-Knoten notwendig. Ein Knoten wird als ein sync-Knoten bezeichnet, wenn der Host pSyncNode in der Hostschnittstelle gesetzt hat. Für einen Nicht-Sync-Knoten wird pSyncNode auf false gesetzt. Der Konfigurationsparameter kann dann nur in dem Zustand CC_SoftReset gesetzt oder gelöscht werden. Die Übertragung von mehr als einem sync-Rahmen durch einen Knoten innerhalb eines Zyklus muß durch die Kommunikationssteuerung verhindert werden. Für diesen Protokollmodus sollen sync-Knoten im allgemeinen nicht sofort nach der Durchführung des Aufweckens in den Zustand CC_StartupListen eintreten, wenn nicht das Flag vColdStartInhibit gesetzt ist. Eine Kommunikationssteuerung ohne gesetztes vColdStartInhibit-Flag wird versuchen, das Cluster heraufzufahren, kann aber erfolglos bleiben, da möglicherweise keine andere Kommunikationssteuerung bereit ist, sich der Kommunikation anzuschließen, bevor der Kaltstartinitiator den Herauffahrversuch abbricht, weil er die maximale Anzahl zulässiger Kaltstartversuche erreicht hat. (Dieses Szenario führt immer noch zu einem erfolgreichen Herauffahren, so lange bestimmte der anderen sync-Knoten dafür konfiguriert sind, das Herauffahren zu initialisieren. Der Knoten, der das Netzwerk geweckt hat und beim Herauffahren erfolglos geblieben ist, schließt sich immer noch der durch einen anderen Knoten gestarteten Kommunikation an.) Der Host muß dieses Flag löschen, nachdem genug Zeit vergangen ist, um es den anderen Knoten in dem Cluster zu erlauben, aufzuwachen.
Übertragung von Aufwecksymbolen während des Normalbetriebes
Während des Normalbetriebes kann der Host das Nutzsignal von Rahmen, die er sendet, auf ein Muster setzen, das zwei aufeinanderfolgende Tx-Aufwecksymbole imitiert (dies gilt nur für die oben definierte NRZ-Codierung). Man beachte, daß, da das Aufwecksymbol eine feste Länge aufweist, die notwendige Anzahl von Bit zum Konstruieren eines Nutzsignals, das zwei solchen Aufwecksymbolen äquivalent ist, von der Bitrate des Systems abhängt. Es ist möglicherweise nicht durchführbar, ein solches Nutzsignal für jede Kombination von zulässiger Bitrate und statischer Schlitzlänge (insbesondere kurzen) zu konstruieren. In diesem Fall kann es jedoch immer noch möglich sein, einen dynamischen Rahmen mit diesem Nutzsignal zu konstruieren, wenn das dynamische Segment lang genug dafür ist. Abhängig von der Systemkonfiguration kann es sogar möglich sein, zwei aufeinanderfolgende statische Rahmen zu benutzen.
Beispiele
Dieser Abschnitt beschreibt genauer die Wechselwirkung von Host und Kommunikationssteuerung für das Aufwecken in zwei typischen Situationen. Erstens wird beschrieben, wie ein Host beide Kanäle eines Zweikanalsystems weckt. Zweitens wird beschrieben, wie ein mit nur einem Kanal eines Zweikanalsystems verbundener Knoten diesen Kanal weckt und wie ein (mit beiden Kanälen verbundener) sync-Knoten den anderen Kanal weckt.
Da auch der Übergang zwischen Aufwecken und Herauffahren beschrieben wird, werden die Beispiele mit einem vorbekannten Verständnis des FlexRay-Herauffahrens, das in nachfolgenden Abschnitten beschrieben wird, besser verständlich.
Zweikanal-Aufwecken durch einen Knoten
58 zeigt ein einfaches Aufwecken. Größere Zeitdauern (ms-Bereich) werden durch gestrichelte Linien repräsentiert.
Dieser Abschnitt beschreibt ein FlexRay-System mit zwei Kanälen, das im zeitgetriggerten verteilten Protokollmodus konfiguriert ist und darin betrieben wird. Es wird beschrieben, wie ein sync-Knoten zuerst das Cluster weckt und dann das Herauffahren durchführt. Knoten 1 ist wach. Er hat sich entschieden, das Cluster aufzuwecken. Knoten 2 und Knoten 3 befinden sich in einem Energiespar-Sleep-Modus. Der Host von Knoten 1 (Host 1) prüft auf Aufweckaktivität durch Prüfung, ob einer seiner Bustreiber ein Rx-Aufwecksymbol empfangen hat. Da dies nicht der Fall ist, muß Host 1 beide Kanäle wecken.
Host 1 befiehlt BG 1B (dem Buswächter von Knoten 1 und Kanal B), in seinen Aufweckmodus einzutreten.
Host 1 befiehlt CC 1 (der Kommunikationssteuerung von Knoten 1), Kanal B aufzuwecken, indem vWakeupChannel auf Kanal B gesetzt und die notwendigen Bit in der CC-Host-Schnittstelle gesetzt/gelöscht werden (eine ausführlichere Beschreibung findet sich später in der Beschreibung).
CC 1 tritt in den Zustand CC_WakeupListen ein. Sie empfängt auf keinem der Kanäle irgendwelche Aktivität. Somit läuft der Timer vdWakeup ab. CC 1 tritt in den Zustand CC_WakeupSend ein.
Während des Zustands CC_WakeupSend wird das Tx-Aufweckmuster auf Kanal B gesendet. während der Leerlaufphasen des Tx-Aufweckmusters erkennt CC 1 keine Aktivität auf Kanal B. Nach der vollständigen Übertragung setzt CC 1 vWakeupComplete und tritt wieder in CC_SoftReset ein.
Host 1 befiehlt BG 1B, seinen Aufweckmodus zu verlassen. Das Aufweckmuster hat den Aufweckempfänger des Bustreibers von Knoten 2 (der nur mit Kanal B verbunden ist) getriggert. Knoten 2 initialisiert sich. Host 1 hat in der Zwischenzeit den Aufweckstatusvektor von CC 1 gelesen und weckt weiter den anderen Kanal.
Host 1 befiehlt BG 1A, in seinen Aufweckmodus einzutreten.
Host 1 setzt vWakeupChannel auf Kanal A und befiehlt CC 1, den Aufweckmodus auszuführen.
CC 1 tritt wieder in den Zustand CC_WakeupListen ein. Sie empfängt auf keinem Kanal Aktivität. Somit läuft der Timer vdWakeup ab. CC 1 tritt in den Zustand CC_WakeupSend ein. Während des Zustands CC_WakeupSend wird das Tx-Aufweckmuster auf Kanal A gesendet. In den Leerlaufphasen des Tx-Aufweckmusters erkennt CC 1 auf Kanal A keine Aktivität. Nach der vollständigen Übertragung setzt CC 1 vWakeupComplete und tritt wieder in CC_SoftReset ein.
Host A befiehlt BG 1A, seinen Aufweckmodus zu verlassen.
Das Aufweckmuster hat den Aufweckempfänger des Bustreibers vom Knoten 3 (der nur mit Kanal A verbunden ist) getriggert. Knoten 3 initialisiert sich.
Host A liest den Aufweckstatusvektor von CC 1 aus und trifft die Entscheidung, das Herauffahren fortzusetzen, da beide Kanäle aufgeweckt wurden. Er setzt das Flag vColdStartInhibit und befiehlt CC 1, in den Zustand CC_StartupListen einzutreten.
Nach einiger Zeit sind Knoten 2 und Knoten 3 vollständig konfiguriert. Beide sind keine sync-Knoten und jeder ist nur mit einem von zwei Kanälen verbunden. Außerdem signalisieren ihre Bustreiber, daß sie Rx-Aufweckmuster empfangen haben, so daß ihre Hosts selbst kein Aufwecken durchführen dürfen. Statt dessen befehlen beide Hosts ihren Kommunikationssteuerungen, das Herauffahren zu beginnen. Sowohl CC 2 als auch CC3 bleiben in dem zustand CC_StartupListen.
Als letztes trifft Knoten 1 die Entscheidung, daß genug Zeit vergangen ist, um es den anderen Knoten in dem Cluster zu erlauben, aufzuwachen und sich zu konfigurieren. Er löscht das Flag vColdStartInhibit seiner Kommunikationssteuerung und ermöglicht es ihr dadurch, in den Zustand CC_ColdStartICW einzutreten.
Siehe unten für Einzelheiten bezüglich der Herauffahrprozedur.
Aufweck-Weiterleitung durch einen Knoten
59 zeigt ein einfaches Aufwecken mit Weiterleitung. Größere Zeiträume (ms-Bereich) sind durch gestrichelte Linien repräsentiert.
Dieser Abschnitt beschreibt ein FlexRay-System mit zwei Kanälen, das im zeitgetriggerten verteilten Protokollmodus konfiguriert ist und darin betrieben wird. Es wird beschrieben, wie zuerst ein mit nur einem Kanal verbundener Nicht-Sync-Knoten seinen Kanal weckt und wie dann ein sync-Knoten das Tx-Aufweckmuster an den entgegengesetzten Kanal weiterleitet und die Kommunikation einleitet.
Knoten 1 ist wach. Er hat sich entschieden, das Cluster aufzuwecken.
Knoten 2 und Knoten 3 befinden sich in einem Energiespar-Sleep-Modus. Der Host von Knoten 1 (Host 1) prüft auf Aufweckaktivität durch Prüfung, ob sein Bustreiber ein Rx-Aufwecksymbol empfangen hat. Da dies nicht der Fall ist, entscheidet sich Host 1, seinen Kanal zu wecken. Da dieser Knoten kein sync-Knoten ist, muß der Host vor dem Eintreten in das Herauffahren nicht seinen Kanal wecken. In diesem Beispiel verlangt es die Anwendung sowieso.
Host 1 befiehlt BG 1B (dem Buswächter von Knoten 1 und Kanal B), in seinen Aufweckmodus einzutreten.
Host 1 befiehlt CC 1 (der Kommunikationssteuerung von Knoten 1), Kanal B aufzuwecken, indem vWakeupChannel auf Kanal B gesetzt und die notwendigen Bit in der CC-Hostschnittstelle gesetzt/gelöscht werden (für eine ausführlichere Beschreibung siehe die folgende Beschreibung).
CC 1 tritt in den Zustand CC_WakeupListen ein. Sie empfängt auf ihrem Kanal keinerlei Aktivität. Somit läuft der Timer vdWakeup ab. Die CC 1 tritt in den Zustand CC_WakeupSend ein.
Während des Zustands CC_WakeupSend wird das Tx-Aufweckmuster auf Kanal B gesendet. In den Leerlaufphasen des Tx-Aufweckmusters erkennt CC 1 auf Kanal B keine Aktivität. Nach der vollständigen Übertragung signalisiert CC 1 dies durch Setzen des Flags vWakeupComplete und tritt wieder in den Zustand CC_SoftReset ein.
Host 1 befiehlt BG 1B, seinen Aufweckmodus zu verlassen.
Das Aufweckmuster hat den Aufweckempfänger des Bustreibers von Knoten 2 (der mit beiden Kanälen verbunden ist) getriggert.
Knoten 2 initialisiert sich.
Host 1 liest den Aufweckstatusvektor von CC 1. Er bemerkt, daß CC 1 die Übertragung abgeschlossen hat, und befiehlt CC 1, in den Zustand CC_StartupListen einzutreten. Knoten 1 ist kein sync-Knoten und muß nun darauf warten, daß irgendein anderer Knoten das Herauffahren initialisiert.
In der Zwischenzeit ist Knoten 2 aufgewacht. Knoten 2 ist ein sync-Knoten und darf einen Kaltstart durchführen und muß also vor dem Eintritt in das Herauffahren ein Aufwecken ausführen.
Host 2 prüft auf Aufweckaktivität durch Auswertung, ob einer seiner Bustreiber ein Rx-Aufwecksymbol empfangen hat. Er bemerkt, daß der Bustreiber von Kanal B ein Rx-Aufwecksymbol empfangen hat, und muß also nur Kanal A wecken.
Host 2 befiehlt BG 2A in seinen Aufweckmodus einzutreten.
Host 2 setzt vWakeupChannel auf Kanal A und befiehlt CC 2, den Aufweckprozeß auszuführen.
CC 2 tritt in den Zustand CC_WakeupListen ein. Sie empfängt auf keinem der Kanäle Aktivität. Somit läuft der Timer vdWakeup ab. CC 2 tritt in den Zustand CC_WakeupSend ein.
Während des Zustands CC_WakeupSend wird das Tx-Aufweckmuster auf Kanal A gesendet. In den Leerlaufphasen des Tx-Aufweckmusters erkennt CC 2 auf Kanal A keine Aktivität. Nach der vollständigen Übertragung signalisiert CC 2 dies durch Setzen des Flag vWakeupComplete und tritt wieder in den Zustand CC_SoftReset ein.
Host 2 befiehlt BG 2A, seinen Aufweckmodus zu verlassen. Das Aufweckmuster hat den Aufweckempfänger des Bustreibers von Knoten 3 (der nur mit Kanal A verbunden ist) getriggert. Knoten 3 initialisiert sich. Host 2 liest den Aufweckstatusvektor von CC 2 aus und entscheidet sich, das Herauffahren fortzusetzen. Da ein bestimmter anderer Knoten bereits Kanal B geweckt hat, nimmt Host 2 an, daß bereits andere Knoten wach und initialisiert sind. Er löscht das Flag vColdStartInhibit und befiehlt CC 2, in den Zustand CC_StartupListen einzutreten.
Siehe unten für ausführliche Informationen bezüglich der Herauffahrprozedur.
Kommunikations-Herauffahren und Reintegration
Entsprechend den unterstützten Protokollbetriebsarten werden drei verschiedene Mechanismen für das Kommunikationsherauffahren spezifiziert. Cluster, die in dem zeitgetriggerten verteilten Modus (TT-D) arbeiten, folgen einer fehlertoleranten verteilten Herauffahrstrategie; für den zeitgetriggerten mastergesteuerten Modus (TT-M) verringert sich dies auf ein mastergesteuertes Systemverhalten (es wird auf die durch das Präfix „S" angegebenen Übergänge verwiesen; siehe 62). Ein im byteflight-(BF)-Modus oder im ereignisgetriggerten (ET)-Modus konfiguriertes Cluster führt ein ereignisgesteuertes, mastergesteuertes Herauffahren durch (Zustandsübergänge mit Präfix „B" (byteflight; siehe 63) bzw. „E" (ereignisgesteuerte; siehe die folgende Beschreibung). Die Protokolloperationen in Bezug auf die Synchronisation der laufende Kommunikationsablaufsteuerung, Integration weiterer Knoten in ein laufendes Cluster, Medium-Zugriffsregeln und Fehlerhandhabung sind bei den Konfigurationsalternativen verschieden. Deshalb werden in den folgenden Abschnitten konfigurationsspezifische Zustandsdiagramme für jede dieser Konfigurationen gegeben, einschließlich Zustandsbeschreibungen und Zustandsübergänge. Das Cluster-Aufwecken muß dem Kommunikations-Herauffahren vorausgehen, um sicherzustellen, daß alle für das Herauffahren definierten Mechanismen ordnungsgemäß arbeiten. Nach dem anfänglichen Aufwecken verhält sich das gesamte Netzwerk wie ein Broadcast-Medium.
Herauffahren – zeitgetriggerter Protokollmodus (TT-D und TT-M)
Im allgemeinen kann ein Knoten in die Kommunikation (d.h. den Zustand CC_NormalOperation) über den Kaltstartweg (CC_ColdstartICW- und CC_ColdstartVCW-Zustandssequenz), wodurch die Ablaufsteuerungssynchronisation eingeleitet wird, oder über den Integrationsweg (CC_InitSync und CC_IntegrationVCW-Zustandssequenz), wodurch in eine existierende Kommunikationsablaufsteuerung integriert wird, eintreten. Nur sync-Knoten dürfen über den Kaltstartweg eintreten und sie müssen im voraus prüfen, ob bereits Kanalaktivität besteht oder nicht (siehe unten).
Um eine globale Medium-Zugriffsablaufsteuerung herzustellen, muß die anfängliche Synchronisation der periodischen TDMA-Ablaufsteuerung zwischen allen verbundenen Kommunikationsknoten koordiniert werden. Da jeder sync-Knoten die Ablaufsteuerungssynchronisation einleiten darf, müssen gleichzeitig gestartete und in Konflikt stehende Versuche von verschiedenen sync-Knoten aufgelöst werden. Jeder Knoten sendet zu Anfang ein Kollisionsvermeidungssymbol (CAS, siehe oben) spezifisch für diesen Zweck vor der Initialisierung der periodischen Ablaufsteuerung. Dieses Symbol repräsentiert eine Art von Arbitrierungsvorrichtung, mit der anfängliche Kollisionen von Knoten, die gleichzeitig versuchen, die Kommunikationsablaufsteuerung einzurichten, aufgelöst werden.
Sowohl Nicht-Sync-Knoten als auch sync-Knoten beginnen die passive Integration über den Integrationsweg, sobald sie sync-Rahmen empfangen, aus denen die TDMA-Ablaufsteuerungsinformationen abgeleitet werden können. Während der Integration muß der Knoten seinen eigenen Takt an den globalen Takt anpassen (Rate und Offset) und muß seine Zykluszeit mit der in dem Netzwerk beobachtbaren globalen Ablaufsteuerung vereinbar machen. Danach werden diese Einstellungen auf Vereinbarkeit mit allen verfügbaren Netzwerkknoten geprüft. Nur wenn diese Prüfungen bestanden werden, kann der Knoten die Integrationsphase verlassen und aktiv an der Kommunikation teilnehmen.
Es werden mehrere Betriebsarten unterstützt, die die Fähigkeit des Knotens zum aktiven Kommunizieren oder Einleiten des Herauffahrens einschränken (siehe unten). Diese Betriebsarten sind vom Host konfigurierbar und werden in ihren jeweiligen Abschnitten erläutert.
Herauffahr-Zeitgrenzen
Ein sync-Knoten soll zwei verschiedene Timer aufrechterhalten, die zwei Zeitgrenzenwerte vdStartup und vdStartupNoise unterstützen. Der Ablauf einer dieser Timer bewirkt, daß der Knoten die anfängliche Erfassungsphase (CC_StartupListen-Zustand) mit der Absicht des Herauffahrens der Kommunikation verläßt. Obwohl die folgende Beschreibung auf der Annahme basiert, daß diese Timer ihre Werte (beginnend mit einem Rücksetzwert von Null) inkrementieren, ist es für die Implementierung zulässig, eine andere Realisierung zu wählen (z.B. Zählerdekrementierung).
Die knotenlokale Horchzeitgrenze vdStartup soll für jeden Knoten in dem System, der dafür konfiguriert ist, ein anfängliches CAS während des Herauffahrens zu senden (sync-Knoten), dieselbe Länge (gdStartup) aufweisen. Die obere Grenze gdStartup begrenzt die Horchzeit, mit der ein Knoten bestimmt, ob bereits Kommunikation zwischen anderen Knoten oder mindestens einem sync-Knoten, der aktiv die Integration anderer anfordert, besteht.
Aufgrund des anfänglichen Taktdriftens zwischen der Menge von Knoten, die bereits aktiv kommunizieren (sync-Rahmen senden), und dem Knoten, der eine Integration versucht, muß die Horchzeitgrenze das maximale akkumulierte Driften über die Länge eines Zyklus hinweg berücksichtigen. Deshalb soll das Zeitgrenzenintervall gdStartup durch die folgende Ungleichung eingeschränkt werden (gdStartup wird intern aus den Konfigurationsparametern gdCycle und gdMaxDrift abgeleitet. Zusätzlich ist die Obergrenze für die Horchzeitgrenze vdStartupNoise ein Vielfaches von gdStartup und ist durch Verwendung des Parameters gStartupNoise konfiguriert):
gdStartup ≥ gdCycle + gdMaxDrift
Das maximal zulässige Driften zwischen zwei beliebigen Takten in dem Netzwerk ist ein wichtiger Systemparameter und ist zum Zeitpunkt des Entwurfs bekannt. Dieser Zeitraum des „ungünstigsten Falls" muß durch entsprechendes Konfigurieren von gdMaxDrift (Einheit: Makroticks) abgedeckt werden.
Obwohl das Zählen auf Makrotickgranularität basiert, soll das Rücksetzen des Timers vdStartup asynchron mit dem Makroticktakt durchgeführt werden. Der Timer vdStartup soll bei Eintritt in den Zustand CC_StartupListen zurückgesetzt werden (vdStartup = 0).
Weitere Rücksetzbedingungen für den Timer vdStartup werden folgendermaßen definiert (siehe auch 60):

1. Wenn Kommunikationskanalaktivität (jede im Empfänger detektierbare Signalflanke (d.h. eine Signalflanke, die durch das Glitch-Filter gekommen ist) wird als „Kanalaktivität" bezeichnet (Kanalautomat ist in den Aktiv-Zustand eingetreten).) auf einem der konfigurierten pChannels Kanäle detektiert wird, während sich der Knoten in dem Zustand CC_StartupListen befindet, soll die Horchzeitgrenze vdStartup zurückgesetzt werden.
2. So lange der Kanalstatus eines der konfigurierten pChannels Kanäle aktiv ist, wird der Timer kontinuierlich zurückgesetzt. Der Timer soll das Zählen wiederaufnehmen, sobald der Kanalleerlaufzustand für alle pChannels Kanäle erreicht ist und sich der Knoten immer noch in dem Zustand CC_StartupListen befindet.

Wenn die Horchzeitgrenze vdStartup abläuft (vdStartup = gdStartup) soll weder ein Überlauf noch ein zyklisches Neustarten des Timers durchgeführt werden. Der Status muß zur weiteren Verarbeitung durch den Herauffahrautomaten erhalten werden (siehe Tabelle 14).
Gleichzeitig mit dem Starten der Horchzeitgrenze vdStartup zum ersten Mal (Übergang von CC_SoftReset zu dem Zustand CC_StartupListen) soll eine zweite Zeitgrenze vdStartupNoise mit vdStartupNoise = 0 gestartet werden. Mit dieser zusätzlichen Zeitgrenze wird die Zuverlässigkeit der Herauffahrprozedur bei Anwesenheit von Rauschen verbessert.
Während das Zählen auf Makrotickgranularität basiert, soll das Rücksetzen des Timers vdStartupNoise asynchron zu dem Makroticktakt durchgeführt werden. Der Timer vdStartupNoise soll beim Eintritt in den Zustand CC_StartupListen zurückgesetzt werden.
Weitere Rücksetzbedingungen für den Timer vdStartupNoise und sein Verhalten werden folgendermaßen definiert (siehe auch 61):

1. Der Übergang von Kanal-Leerlauf zu Kanal-Aktiv soll den Timer nicht beeinflussen. Der Knoten muß ein bestimmtes Muster (s. unten) empfangen, um den Timer vdStartupNoise zurückzusetzen.
2. Wenn S_SuccessfulHeaderReception oder S_CASReception für irgendeinen Kanal auftreten, während sich der Knoten in dem Zustand CC_StartupListen befindet, soll die Horchzeitgrenze vdStartupNoise zurückgesetzt werden.

Nachdem die Horchzeitgrenze vdStartupNoise abläuft (vdStartupNoise = gStartupNoise·gdStartup) soll weder ein Überlauf noch ein zyklisches Neustarten des Timers durchgeführt werden. Der Status muß zur weiteren Verarbeitung durch den Herauffahrautomaten gehalten werden (siehe Tabelle 13).
Da die Zeitgrenze vdStartupNoise nicht zurückgesetzt wird, wenn Kanalaktivität erfaßt wird (siehe 61), definiert diese Zeitgrenze die Fallback-Lösung, die garantiert, daß ein Knoten auch bei Anwesenheit von Rauschen versuchen wird, das Kommunikationscluster heraufzufahren. Durch Definition bestimmter Rücksetzbedingungen wird dagegen die Synchronisation des Kaltstarteintritts weiter garantiert. Das Ablaufen von vdStartupNoise und der resultierende Eintritt in den Kaltstartweg werden in der Variablen vNoise erfaßt (vNoise wird auf „true" gesetzt).
Der Nur-Horchen-Modus
Ein FlexRay-Knoten soll einen Nur-Horchen-Modus unterstützen. Im Nur-Horchen-Modus soll der Knoten in der Lage sein, nach erfolgreicher Integration in die ablaufende Kommunikation alle Rahmen zu empfangen; d.h. der Knoten ist voll synchronisiert und führt die Taktsynchronisation durch, um diesen Status zu behalten. Im Vergleich zu dem Normalbetriebsmodus (Zustand CC_NormalOperation) nimmt der Knoten nicht aktiv an der Kommunikation teil, d.h. es werden weder Symbole noch Rahmen übertragen.
Das Setzen von vListenOnly auf true während des Zustands CC_SoftReset konfiguriert den Nur-Horch-Modus. Nach dem Verlassen des Zustands CC_SoftReset kann vListenOnly nicht auf true gesetzt werden, kann aber zu jeder Zeit gelöscht werden.
Dieser Modus unterstützt die Kommunikationsdiagnose („Überwachung") sowie spezielle Aufweckstrategien, die Hostinteraktion erfordern (vListenOnly nachfolgend gelöscht), um aktiv nach dem Aufwecken an der Kommunikation teilzunehmen.
Im Nur-Horch-Modus verhalten sich sync-Knoten während des Herauffahrens wie Nicht-Sync-Knoten. Genauer gesagt gilt dies für die Vorbedingungen für den Übergang von CC_IntegrationVCW zu CC_PassiveOperation. Das Bestehen der Validierungsprüfung erfordert, daß mindestens zwei verschiedene sync-Knoten bereits synchronisiert sind und kommunizieren können. Es wird auf die Beschreibung der nachfolgend beschriebenen Validierungsprüfung verwiesen.
ColdStart-Sperrmodus
Ein FlexRay-Knoten soll einen Kaltstart-Sperrmodus unterstützen. Im Kaltstart-Sperrmodus soll verhindert werden, daß der Knoten die TDMA-Kommunikationsablaufsteuerung initialisiert. Wenn der Host vColdStartInhibit gesetzt hat, darf dem Knoten nicht erlaubt werden, nach Prüfung auf existierende Kommunikation die Clusterkommunikation zu initialisieren, d.h. der Eintritt in den Kaltstartweg ist gesperrt. Es soll dem Knoten erlaubt werden, sich in ein laufendes Cluster zu integrieren oder einen anderen Knoten zu bestätigen, der anfänglich versucht, die Clusterkommunikation zu starten.
Der Kaltstart-Sperrmodus vColdStartInhibit kann nur im Zustand CC_SoftReset gesetzt werden. vColdStartInhibit kann nach dem Verlassen des Zustands CC_SoftReset nicht gesetzt werden, kann aber zu jeder Zeit gelöscht werden. vColdStartInhibit kann auf den Konfigurationsparameter gColdStartMax abgebildet werden, der den Nullwert verwendet, um den Knoten davon abzuhalten, das Netzwerk aus eigener Initiative zu starten (siehe das Kapitel „Hostschnittstelle"). Es muß geprüft werden, ob der Parameter gColdStartMax während der Laufzeit, d.h. nach dem Verlassen des Zustands CC_SoftReset zugänglich ist, da dies für die Funktion „Kaltstart-Speeren" erforderlich ist).
Nachdem der Knoten synchronisiert ist, soll vColdStartInhibit die Fähigkeit des Knotens, Rahmen zu empfangen oder Rahmen zu senden, nicht einschränken.
Herauffahr-Zustandsdiagramm – zeitgetriggerter Protokollmodus (TT-D und TT-M)
62 zeigt ein Herauffahr-Zustandsdiagramm – zeitgetriggerter Protokollmodus (TT-D und TT-M)
Tabelle 14: Zustandsübergänge und entsprechende Bedingungen für die Ausführung
Der Zustand CC_StartupListen
Ein FlexRay-Knoten soll von dem Zustand CC_SoftReset in den Zustand CC_StartupListen eintreten, wenn die Kommunikationssteuerung bereit ist, das Kommunikationsherauffahren zu versuchen oder in ein laufendes Netzwerk einzutreten. Wenn die Kommunikationssteuerung dazu fähig ist, einen Herauffahrversuch einzuleiten, soll der Host zuerst sicherstellen, daß das Cluster wach ist, bevor er die Kommunikationssteuerung in den Zustand CC_StartupListen eintreten läßt.
Beim Eintritt in den Zustand CC_StartupListen von dem Zustand CC_SoftReset aus oder beim Neueintritt von irgendeinem anderen Zustand des Herauffahrautomaten, der von dem Zustand CC_StartupListen selbst verschieden ist, sollen sync-Knoten ihre Horchzeitgrenze vdStartup und ihre Horchzeitgrenze mit Rauschen vdStartupNoise (siehe oben) (neu) starten.
Die globale Clusterkonstante gColdStartMax definiert die Anzahl der Zyklen, für die es einem Knoten erlaubt werden soll, einen Kaltstart zu versuchen, d.h. die Anzahl der Zyklen, für die ein Knoten in dem Kaltstartweg residieren darf. Nachdem vColdStartCount gleich gColdStartMax ist, soll der Knoten nicht in den Kaltstartweg eintreten (dies ließe sich durch Verhindern des Neustarts der Horchzeitgrenzen vdStartup und vdStartupNoise erreichen). vColdStartCount wird nur beim Eintritt in den Zustand CC_StartupListen von dem Zustand CC_SoftReset aus zurückgesetzt.
Nicht-Sync-Knoten sollen nicht in den Kaltstartweg eintreten, weil es diesen Knoten nicht erlaubt ist, selbst Kommunikation einzuleiten. Dies ließe sich durch mehrere Mittel erzielen, z.B. wird für Nicht-Sync-Knoten gColdStartMax auf Null konfiguriert oder die Horchzeitgrenzen vdStartup und vdStartupNoise werden nicht aufrechterhalten.
Nach Empfang eines S_ValidEvenStartupFrame soll über den Zustand CC_InitSync in den Integrationsweg eingetreten werden. Ferner muß vRefSync Null sein (siehe die Strategie, die definiert wird, um zu verhindern, daß ein Knoten wiederholt einen fehlerhaften Knoten als Referenz wählt). fFrameID soll in vRefSync gespeichert werden, um die Kennung des Referenzrahmens und dadurch eine Repräsentation des entsprechenden sync-Knotens zur weiteren Verarbeitung (siehe unten) zu speichern.
Wenn sich mindestens einer der Kanäle in dem Kanalleerlaufzustand befindet, mindestens eine der Horchzeitgrenzen vdStartup oder vdStartupNoise abgelaufen ist und die Eintrittsbedingung für den Integrationsweg nicht erfüllt ist, soll der Knoten in den Zustand CC_ColdStartICW eintreten.
Ein Knoten, der sich nicht auf den Referenzknoten integrieren konnte, der ausgewählt wurde, um Anfangsraten und -Offsetinformationen abzuleiten, soll für einen Integrationsversuch während des nächsten Kommunikationszyklus nicht denselben Knoten benutzen. Deshalb soll ein Knoten eine Vorgeschichte von Referenzknoten führen, die er versucht hat, zu verwenden, um eine sich wiederholende Auswahl desselben Referenzknotens zu vermeiden. Es muß sichergestellt werden, daß ein Knoten in dem Zustand CC_StartupListen einen von dem etwaigen früheren Referenzknoten verschiedenen sync-Knoten auswählt.
Wenn ein Integrationsversuch mit einem gewählten Referenzknoten versagt, soll der Referenzknoten nicht permanent aus der Liste potentieller Referenzknoten ausgeschlossen werden. Aufgrund einer transienten Störung könnte die Integration versagt haben, obwohl der Referenzknoten fehlerfrei gearbeitet hat (ein verfälschter sync-Rahmen könnte den Übergang in den Zustand CC_InitSync oder den Zustand CC_IntegrationVCW verhindern). Deshalb soll die folgende Strategie angewandt werden, nachdem ein Integrationsversuch versagt hat (siehe unten). Ein Knoten, der in CC_StartupListen eintritt, soll einen Timer mit dem Zeitgrenzenwert vdCycleWithHistory zurücksetzen und starten, wenn vRefSync von Null verschieden ist. Dieser Timer soll denselben Zeitraum gdStartup wie die Zeitgrenze vdStartup umschließen.
Die Zeitgrenze vdCycleWithHistory soll nicht aufgrund von Kanalaktivität im Zustand CC_StartupListen zurückgesetzt werden. Nach Ablaufen der Zeitgrenze vdCycleWithHistory soll vRefSync gelöscht werden. Diese Einstellung (vRefSync = 0) verhindert den Neustart von vdCycleWithHistory
Der Knoten soll nur dann (über den Zustand CC_InitSync) in den Integrationsweg eintreten, wenn die fFrameID eines empfangenen S_ValidEvenStartupFrame nicht gleich der in vRefSync gespeicherten ID ist. Da im TT-M-Modus nur ein sync-Knoten verfügbar ist, bewirkt es das Gegenteil des gewünschten, zu versuchen, auf einen anderen Knoten zu syncen.
Im TT-M-Modus soll ein Nicht-Sync-Knoten die oben definierte Strategie nicht ausführen. Im TT-M-Modus existiert ein einziger sync-Knoten, d.h. der Master. Alle Nicht-Sync-Knoten und ihre Synchronisation sind völlig von dem Master-Knoten abhängig. Deshalb wird dieser Knoten niemals als potentielle Referenz ausgeschlossen. Beim Eintritt in den Zustand CC_StartupListen von irgendeinem anderen Zustand aus wird vRefSync gelöscht (d.h. auf Null gesetzt).
Beim Neueintritt in den Zustand CC_StartupListen von irgendeinem Zustand aus soll der Ratenkorrekturwert mit pMicroOverheadperCycleNom neu initialisiert werden.
Der Zustand CC_ColdStartICW (Anfangsprüffenster)
Es soll nur sync-Knoten erlaubt werden, über den Zustand CC_ColdStartICW in den Kaltstartweg einzutreten. Die Phase, für die sich ein sync-Knoten in dem Zustand CC_ColdStartICW befindet, soll für die folgenden Zwecke verwendet werden:
Es muß sichergestellt werden, daß ein einziger sync-Knoten das Kommunikationscluster starten wird. Es muß deshalb verhindert werden, daß andere sync-Knoten in den Kaltstartweg eintreten. Wenn mehrere Knoten gleichzeitig in den Zustand CC_ColdStartICW eintreten, stellt ein Auflösungsmechanismus sicher, daß alle bis auf einen zu dem Zustand CC_StartupListen zurückkehren.
In dem Zustand CC_ColdStartICW wird erwartet, daß der Kaltstart-Einleitungsknoten im fehlerfreien Fall exklusiven Zugriff auf die Kanäle hat. Andere Knoten, die sich auf der Basis des sync-Rahmenempfangs des Kaltstartinitiators integrieren, befolgen immer eine definierte Prozedur, die sicherstellt, daß diese Knoten für Anfangszyklen in dem Integrationsweg passiv bleiben. Danach sollte der den Kaltstart einleitende Knoten, während er sich in dem Zustand CC_ColdStartICW befindet, keine Antworten empfangen. Jeder Rahmenempfang während des Zustands CC_ColdStartICW ist deshalb auf einen anderen Knoten zurückzuführen, der gleichzeitig in den Kaltstartweg eingetreten ist (siehe den obigen Punkt), oder auf ein Fehlerszenario.
In dem Zustand CC_ColdStartICW soll ein sync-Knoten ein anfängliches CAS-Symbol senden und soll dann periodisch seinen konfigurierten sync-Rahmen senden, um das Herauffahren des gesamten Netzwerks zu ermöglichen. Durch Starten des ersten Kommunikationszyklus nach der CAS-Übertragung wird der Zykluszähler auf Null initialisiert; somit wird der erste sync-Rahmen mit fCycleCount gleich Null übertragen.
Durch Übertragen des CAS-Symbols wird verhindert, daß andere sync-Knoten in den Kaltstartweg eintreten. Wenn mehr als ein einziger sync-Knoten gleichzeitig das CAS-Symbol senden, treten diese Knoten alle gleichzeitig in den Zustand CC_ColdStartICW ein. Ihre Zykluszeitsteuerung ist jedoch naturgemäß synchronisiert, so daß dieses Szenario während der nächsten Zyklen während des Zustands CC_ColdStartICW auflösbar ist.
Der Empfang eines gültigen CAS-Symbols (S_CASReception aufgetreten) oder eines Rahmenkopfteils (angezeigt durch S_SuccessfulHeaderReception) auf irgendeinem Kanal soll bewirken, daß der Knoten sofort wieder in den Zustand CC_StartupListen eintritt.
In dem Zustand CC_ColdStartICW soll ein Knoten keine normalen Datenrahmen, die Rahmen ohne gesetztes sync-Bit sind, senden.
Ein Knoten soll für einen bestimmten Zeitraum, der durch die Anfangs-Kaltstartphase (gdInitialColdStartPhase) bestimmt wird, in dem Zustand CC_ColdStartICW bleiben. Ein Timer vdInitialColdStartPhase soll zurückgesetzt und gestartet werden, wenn in CC_ColdStartICW eingetreten wird. Dieser Timer soll den für die CAS-Übertragung verwendeten Anfangschlitz sowie drei vollständige Kommunikationszyklen abdecken (siehe die Definition von gdInitialColdStartPhase im folgenden Teil der Beschreibung). Dadurch bestimmt gdInitialColdStartPhase die Zeit, für die ein Knoten in dem Zustand CC_ColdStartICW bleibt, bevor er in CC_ColdStartVCW eintritt.
Nach dem Übergang in einen anderen Zustand soll der Timer vdInitialColdStartPhase gestoppt werden.
Ein Knoten mit einem zeitgetriggerten verteilten Modus (TT-D) mit einem „Versagen der ankommenden Strecke" soll die Übertragung nach einem vordefinierten Zeitintervall stoppen. Dadurch können andere sync-Knoten die Verantwortung für das Starten der Kommunikation für das Cluster übernehmen.
Für dieses Merkmal soll der zusätzliche Zähler vColdStartCount geführt werden.
Mit dem Übergang in den Zustand CC_ColdStartICW soll die Variable vColdStartCount um eins inkrementiert werden. Bei jedem neuen Zyklusstart in dem Zustand CC_ColdStartICW soll vColdStartCount um eins inkrementiert werden.
Am Ende jedes Zyklus wird vColdStartCount mit dem zulässigen Maximum gColdStartMax verglichen. Wenn vColdStartCount gleich gColdStartMax ist, soll der Knoten wieder in den Zustand CC_StartupListen eintreten. In diesem Fall konnte der Knoten, der den Kaltstart einleitet, keine Kommunikation mit einem anderen Knoten (Übergang zu dem Zustand CC_NormalOperation) innerhalb von gColdStartMax Zyklen erzielen. Wenn diese Bedingung wahr geworden ist, soll der sync-Knoten nicht wieder in den Kaltstartweg eintreten können. Nur der Host kann diesen Status zurücksetzen (durch Erzwingen des Übergangs in den Zustand CC_SoftReset).
Ein Knoten in dem zeitgetriggerten mastergesteuerten Modus (TT-M) soll den Zähler vColdStartCount nicht führen.
Der Zustand CC_ColdStartVCW (Validierungsprüffenster)
In dem Zustand CC_ColdStartVCW soll der Knoten eine periodische Übertragung seines sync-Rahmens auf Zyklusbasis aufrechterhalten, es sollen aber keine anderen Rahmen für die Übertragung eingeteilt werden. Zusätzlich soll der Knoten am Ende jedes Zyklus eine Validierungsprüfung durchführen, um das für den aktuellen Zyklus wahrgenommene Netzwerkbild zu bewerten. Abhängig von dem Ergebnis der Validierungsprüfung soll der Knoten in dem Zustand CC_ColdStartVCW bleiben, wenn überhaupt keine Antwort empfangen wurde (und vColdStartCount kleiner als gColdStartMax ist), soll er in den Zustand CC_StartupListen zurückschreiten, wenn die Antwort nicht in die knotenlokale Kommunikationsablaufsteuerung paßt, soll in den Normalbetrieb (den Zustand CC_NormalOperation) eintreten, wenn die Antwort der knotenlokalen Kommunikationsablaufsteuerung entspricht.
Diese Liste gilt für sync-Knoten in dem zeitgetriggerten verteilten Modus (TT-D). Für im zeitgetriggerten mastergesteuerten Modus (TT-M) arbeitende FlexRay-Cluster ist der Kaltstartinitiator der einzige Knoten, der zum Senden von sync-Rahmen konfiguriert ist. Deshalb soll dieser Knoten nicht auf Antworten warten und soll den Übergang in den Zustand CC_NormalOperation am Ende des Zyklus ausführen.
Durch Übertragung des sync-Rahmens fordert der Kaltstartinitiator andere Knoten auf, sich der gegebenen Kommunikationsablaufsteuerung anzuschließen. Nachdem diese Knoten (mindestens ist das Dazukommen eines weiteren sync-Knotens für den TT-D-Protokollmodus erforderlich) aktiv werden, soll der Kaltstartinitiator den Kaltstartweg durch Eintreten in den Normalbetrieb, d.h. die Protokolloperationsphase (POP), verlassen. Um einen Kaltstartinitiator im TT-D-Modus in den Zustand CC_NormalOperation zu transferieren, muß die Antwort anderer aktiver Knoten bestimmte Validierungskriterien erfüllen. Der Begriff „Antwort" und die Validierungsprüfregeln werden nachfolgend ausführlich beschrieben.
Es sollen zwei verschiedene Mechanismen zu der Validierungsprüfung beitragen.
Erstens müssen empfangene sync-Rahmen der knotenlokalen Kommunikationsablaufsteuerung entsprechen Ferner dürfen die Korrekturterme der Taktsynchronisation die konfigurierten Grenzen nicht überschreiten.
Um auf die Validierungsprüfung vorzubereiten, soll der Knoten die Kommunikation über einen Zyklus hinweg beobachten und bewerten. Es sollen zwei Ereigniszähler pro Kanal (vValidSyncCount[ch] und vInvalidSyncCount[ch]) administriert werden, um die Entscheidungsfindung zu unterstützen. Gemäß dem Statisches-Segment-Annahmekriterium (siehe das Kapitel „Rahmenverarbeitung" oben) kann eine klare Unterscheidung zwischen mehreren möglichen Fällen für jeden Schlitz getroffen werden. Diese Schlitzszenarios sollen beurteilt und Zähler gemäß den folgenden Regeln inkrementiert werden:
Die Validierungsprüfzähler sollen bei jedem neuen Zyklusstart folgendermaßen für alle konfigurierten pChannel Kanäle initialisiert werden:
vValidSyncCount[ch] = 1;
vInvalidSyncCount[ch] = 0;
Der Knoten soll sich selbst als korrekt arbeitend betrachten und soll deshalb die Zähler vValidSyncCount[ch] entsprechend initialisieren (auf eins voreinstellen).
Die Validierungsprüfung soll bestanden werden, wenn vValidSyncCount[ch] für alle konfigurierten Kanäle größer als vInvalidSyncCount[ch] ist. Der Übergang zu CC_NormalOperation soll nur dann gestattet werden, wenn die Prüfung mit vValidSyncCount[ch] > 1 auf mindestens einem der pChannel Kanäle bestanden wird.
Mit dem Übergang zu CC_ColdStartVCW und mit jedem neuen Zyklusstart in CC_ColdStartVCW soll die Variable vColdStartCount um eins inkrementiert werden. Am Ende jedes Zyklus soll vColdStartCount mit dem zulässigen Maximum gColdStartMax verglichen werden. Wenn vColdStartCount gleich gColdStartMax ist, soll der Knoten wieder in den Zustand CC_StartupListen eintreten.
In CC_ColdStartVCW soll der Knoten die globale Taktsynchronisation in bezug auf Offset und Rate gemäß den regulären Regeln ausführen. CC_ColdStartVCW ist der letzte Zeitpunkt, an dem die Taktsynchronisation, einschließlich Meß- und Korrekturphase, aktiv sein muß. Der Knoten könnte die Taktsynchronisation bereits in dem Zustand ColdStartICW durchführen. Dies könnte für den TT-M-Protokollmodus und die Einrichtung der auf zwei Zyklen basierenden Ratenmeßphase vorteilhaft sein. Gemäß der Definition der regulären Ratenmeßphase sollen alle sync-Rahmen zur Taktsynchronisation registriert und paarweise (sync-Rahmen mit derselben Rahmenkennung) aufgewertet werden. Die Offset-Meßphase soll auch gemäß dem regulären Schema angewandt werden. Das heißt, daß für jeden Zyklus mit einem ungeraden Zykluszählerwert die betreffenden sync-Rahmen zur Bestimmung des nächsten Offsetkorrekturterms verwendet werden sollen. Die sync-Rahmen, die aus Knoten empfangen werden, die sich auf den Kaltstartversuch hin integriert haben, werden um zweimal die Gesamt-(Netzwerk)-Ausbreitungsverzögerung verzögert. Dies muß für die Einstellung der Offsetkorrekturtermgrenze (sowieso) berücksichtigt werden.
Der Knoten in dem Zustand CC_ColdStartVCW benötigt mindestens ein zusätzliches übereinstimmendes Paar sync-Rahmen, die für Ratenmessung geeignet sind (selbe Rahmenkennung, aufeinanderfolgendes Auftreten in der Zyklusreihenfolge „gerade/ungerade"), um eine der notwendigen Vorbedingungen für den Eintritt in CC_NormalOperation zu erfüllen. Nach dem Empfang zweier gültiger übereinstimmender Rahmen (S_ValidStaticFrame) in der Zyklusreihenfolge gerade/ungerade soll der Knoten in CC_ColdStartVCW den Zähler vSyncPairs inkrementieren. So lange der Knoten keine Antwort empfängt, führt er die Taktkorrektur auf der Basis eines „Paars mit übereinstimmendem sync"-Rahmen, nämlich seiner eigenen Übertragungen durch (dies wird durch Verwendung des Werts 0 als „Meßprobe" berücksichtigt). Die Einführung von vSyncPairs erfolgt zur Erleichterung der Beschreibung mehrerer in der Spezifikation zu treffender Unterscheidungen. Als Hilfsvariable ist es nicht erforderlich, daß dieser Parameter für eine Implementierung einer FlexRay-Protokollsteuerung verwendet wird. Beim Anfang jeder Ratenmeßphase in dem Zustand CC_ColdStartVCW soll der Zähler vSyncPairs auf Null zurückgesetzt werden.
Zusätzlich zu der Vorbedingung, daß notwendige Mengen von Meßproben verfügbar sind (vSyncPairs ist größer als Null), soll die Qualität der resultierenden Korrekturterme für die Taktsynchronisation bewertet werden. Der Knoten darf den Übergang in den Zustand CC_NormalOperation nur dann ausführen, wenn die Korrekturterme sowohl für Rate als auch für Offset in den konfigurierten Grenzen liegen:
|vOffsetCorrection| ≤ pOffsetCorrectionOut
|vRateCorrection| ≤ pRateCorrectionOut
Wenn einer der Korrekturterme gegen die Grenzeinstellungen verstößt, soll der Knoten wieder in den Zustand CC_StartupListen eintreten.
Der Zustand CC_InitSync
Ein Knoten soll in den Zustand CC_InitSync eintreten, nachdem er ein S_ValidEvenStartupFrame auf einem der konfigurierten pChannel Kanäle in dem Zustand CC_StartupListen empfangen hat. In dem Zustand CC_InitSync soll der Knoten keine Übertragung einteilen. Die Knotenvariable vRefSync soll die Rahmenkennung des sync-Rahmens enthalten, womit in den Integrationsweg eingetreten wurde. Der diesem Referenzrahmen entsprechende sync-Knoten wird als der Referenzknoten bezeichnet.
In dem Zustand CC_InitSync soll ein Anfangsratenkorrekturwert bestimmt werden, um die lokale Makrotickzeitsteuerung auf die durch den Referenzknoten gegebene Zeitsteuerung einzustellen (sogenannte „Ratenanpassung"). Zu diesem Zweck wird die Zeit zwischen dem ersten Auftreten des Referenzrahmens und seinem nächsten Auftreten gemessen, und die Differenz von der nominalen Zykluslänge soll als der Ratenkorrekturterm angewandt werden.
Um die Robustheit des gesamten Integrationsprozesses gegenüber vorübergehenden Störungen zu verbessern, wird der Empfang von S_ValidStartupFrame für jeden Kanal separat verfolgt. Das heißt, daß, wenn der Anfangs-Sync-Rahmen auf Kanal A empfangen wurde und der nächste sync-Rahmen auf diesem Kanal fehlt, soll der Knoten in dem Zustand CC_InitSync bleiben, wenn die Ratenanpassung immer noch auf dem anderen Kanal, d.h. Kanal B basieren kann. Dies erfordert den korrekten Empfang eines gültigen Paars von S_ValidStartupFrame (beginnend mit S_ValidEvenStartupFrame) auf dem zweiten Kanal. Auf keinen Fall soll ein Paar Rahmen aus Messungen gebildet werden, die von verschiedenen Kanälen entnommen werden, d.h. die kanalübergreifende Messung ist verboten.
Der Knoten soll Mittel anwenden, um sicherzustellen, daß ein Übergang zurück in den Zustand CC_StartupListen durchgeführt wird, wenn S_ValidOddStartupFrame zu früh auf einem der Kanäle ch empfangen wird, wofür bereits ein S_ValidEvenStartupFrame empfangen wurde, und wenn kein S_ValidOddStartupFrame innerhalb eines definierten Zeitraums auf einem der Kanäle ch empfangen wird, wofür ein S_ValidEvenStartupFrame bereits empfangen wurde Im wesentlichen darf der erfaßte Anfangsratenkorrekturwert eine konfigurierte Grenze, die durch pRateCorrectionInitOut gegeben wird, nicht überschreiten.
Sobald ein gültiger Ratenkorrekturterm verfügbar geworden ist, soll der Knoten mit der korrigierten Rate betrieben werden (direkte Anwendung des Korrekturterms).
Ferner soll mit S_ValidOddStartupFrame die nominale Ablaufsteuerungsposition bestimmt werden. Diese Operation soll auf der empfangenen Kennung fFrameID basieren. Der Knoten soll seine lokale Zykluszeit entsprechend setzen, d.h. er soll die Mikro- und Makrotickzähler auf das erste BSS (fallende Flanke) des empfangenen sync-Rahmens synchronisieren. Der Zykluszählerwert fCycleCount des empfangenen sync-Rahmens soll extrahiert und zur Initialisierung des lokalen Zykluszählers verwendet werden.
Auf diese Weise wird die lokale Ablaufsteuerung gemäß den aus dem Referenzknoten abgeleiteten Informationen eingerichtet. Der Knoten soll der lokalen Ablaufsteuerung bis zum Ende des aktuellen Zyklus folgen, ohne aktiv zu senden.
Jeder weitere Empfang soll ignoriert und weder Raten- noch Offsetmessungen sollen durchgeführt werden. Am Ende des Zyklus soll der Knoten in den Zustand CC_IntegrationVCW übergehen.
Der Zustand CC_IntegrationVCW
In dem Zustand CC_IntegrationVCW soll der Knoten keine Übertragung einteilen.
In CC_IntegrationVCW soll der Knoten die aus dem Referenzknoten kopierten Einstellungen mit dem Gesamtnetzwerkkommunikationsschema bestätigen. Zu diesem Zweck soll der Knoten eine auf Zyklen basierende Validierungsprüfung durchführen, die der Prüfung ähnlich ist, die für den Zustand CC_ColdStartVCW definiert wurde (siehe oben). Da sich der Knoten immer noch passiv verhält, ist die Initialisierung der administrierten Zähler von der für einen Knoten in CC_ColdStartVCW verschieden (wobei ein sync-Rahmen gesendet und somit aktiv an der Validierungsprüfung teilgenommen wird).
Die Validierungsprüfzähler sollen für alle konfigurierten pChannel Kanäle bei jedem neuen Zyklusstart folgendermaßen initialisiert werden:
vValidSyncCount[ch] = 0;
vInvalidSyncCount[ch] = 0;
Das Zählerinkrement soll gemäß den folgenden Regeln durchgeführt werden:
Die Validierungsprüfung soll als bestanden betrachtet werden, wenn für alle Kanäle vValidSyncCount[ch] größer ist als vInvalidSyncCount[ch], mit Ausnahme derjenigen, für die vValidSyncCount[ch] == vInvalidSyncCount[ch] == 0 ist. Wenn sowohl vInvalidSyncCount als auch vValidSyncCount für alle konfigurierten Kanäle gleich Null sind, versagt die Validierungsprüfung.
Der Übergang in CC_NormalOperation kann nur stattfinden, wenn die Validierungsprüfung bestanden wurde, aber es müssen zusätzlich weitere Bedingungen erfüllt sein (siehe die Taktkorrekturtermbewertung bzw. die nächsten Abschnitte). Die Validierungsprüfung soll gleichzeitig mit diesen zusätzlichen Prüfungen laufen, bis die Validierungsprüfung selbst versagt oder ein Zustandsübergang aufgrund einer anderen Bedingung ausgeführt wird.
Wenn der Knoten in CC_IntegrationVCW eintritt, soll eine reguläre Meßphase für den nächsten Ratenkorrekturterm gestartet werden. Gemäß der Definition der regulären Ratenmeßphase sollen alle sync-Rahmen registriert und paarweise (sync-Rahmen mit derselben Rahmenkennung) zur Taktsynchronisation ausgewertet werden. Die Offsetmeßphase soll auch gemäß dem regulären Schema angewandt werden. Das heißt, daß für jeden Zyklus mit ungeradem Zykluszählerwert die betreffenden sync-Rahmen zur Bestimmung des nächsten Offsetkorrekturterms verwendet werden.
Ein sich integrierender sync-Knoten erfordert mindestens ein übereinstimmendes Paar sync-Rahmen, das für die Ratenmessung geeignet ist (selbe Rahmenkennung, aufeinanderfolgendes Auftreten in der Reihenfolge „gerade/ungerade"), um eine der notwendigen Vorbedingungen für den Eintritt in den Zustand CC_NormalOperation zu erfüllen. Unter Verwendung dieses Paars sync-Rahmen kann der Knoten einen existierenden Knoten in CC_ColdStartVCW bestätigen oder sich einfach in ein synchronisiertes Cluster integrieren. Die Anzahl der übereinstimmenden Paare von sync-Rahmen soll in vSyncPairs akkumuliert werden.
Der Zähler vSyncPairs soll am Ende eines ungeraden Zyklus ausgewertet werden.
Für sync-Knoten, die nicht im Nur-Horch-Modus arbeiten (vListenOnly ist false) muß vSyncPairs mindestens eins betragen, andernfalls soll keine Integration möglich sein. In diesem Fall soll der Knoten wieder in den Zustand CC_StartupListen eintreten. Dadurch wird das Szenario charakterisiert, wobei der ursprüngliche Referenzknoten nicht für die gesamte Integrationsphase eine ordnungsgemäße sync-Rahmenübertragung aufrechterhält.
Dies gilt auch für Knoten im TT-M-Modus, die sich in die „mastergesteuerte" Ablaufsteuerung integrieren werden. Der Parameter vSyncPairs muß mindestens eins betragen; andernfalls soll keine Integration möglich sein. In diesem Fall soll der Knoten in den Zustand CC_StartupListen eintreten.
Wenn ein sync-Knoten als Nur-Horch-Knoten konfiguriert ist (vListenOnly ist true), muß er dieselbe Bedingung wie Nicht-Sync-Knoten im TT-D-Protokollmodus erfüllen. Diese Knoten müssen mindestens zwei übereinstimmende Paare von sync-Rahmen empfangen, die für Ratenmessung geeignet sind (selbe Rahmenkennung, aufeinanderfolgendes Auftreten). Nur wenn bereits eine Kommunikation hergestellt ist, die mindestens zwei sync-Knoten (Knoten in dem Zustand CC_NormalOperation) umfaßt, können sich Nicht-Sync-Knoten (oder Knoten im Nur-Horch-Modus) anschließen. Für diese Knoten muß vSyncPairs mindestens zwei betragen, andernfalls soll keine Integration möglich sein. Der Knoten soll wieder in den Zustand CC_StartupListen eintreten, wenn vSyncPairs Null ist.
Beim Anfang jeder Ratenmeßphase in dem Zustand CC_IntegrationVCW soll die Variable vSyncPairs auf Null zurückgesetzt werden.
Zusätzlich zu der Vorbedingung, daß notwendige Mengen von Meßproben verfügbar sind (vSyncPairs ist groß genug, siehe oben), muß die Qualität der resultierenden Korrekturterme zur Taktsynchronisation akzeptabel sein. Einem Knoten soll nur dann erlaubt werden, sich aktiver Kommunikation anzuschließen (Übergang in den Zustand CC_NormalOperation), wenn die Korrekturterme sowohl für Rate als auch für Offset innerhalb der konfigurierten Grenzen liegen:
|vOffsetCorrection| ≤ pOffsetCorrectionOut
|vRateCorrection| ≤ pRateCorrectionOut.
Wenn einer der Korrekturterme gegen die Grenzeinstellungen verstößt, muß der Knoten wieder in CC_StartupListen eintreten.
Die einzige Ausnahme dieser Regel ist für das erste Mal, daß ein Offsetkorrekturwert in dem Zustand CC_IntegrationVCW verfügbar ist. In diesem Spezialfall kann der Korrekturwert vOffsetCorrection die konfigurierte Grenze pOffsetCorrectionOut, die während der regulären Taktsynchronisation angewandt wird, überschreiten. Der Anfangsoffsetkorrekturwert soll mit der Grenze pOffsetCorrectionInitOut verglichen werden.
|vOffsetCorrection| ≤ pOffsetCorrectionInitOut Wenn diese weniger strenge Anforderung erfüllt werden kann, soll der Knoten in dem Zustand CC_IntegrationVCW bleiben, soll aber nicht in den Zustand CC_NormalOperation übergehen.
Nach der Anwendung des Anfangsoffsetkorrekturterms (und Prüfung im Vergleich zu der Grenze pOffsetCorrectionInitOut) in dem Zustand CC_IntegrationVCW muß der nächste Offsetkorrekturterm die reguläre Grenze pOffsetCorrectionOut erfüllen. Das heißt, die beschriebene Ausnahme wird nur einmal angewandt, d.h. wenn der erste Offsetkorrekturterm verfügbar ist.
Um eine ordnungsgemäße Verarbeitung sicherzustellen, soll ein Flag vOffsetOut auf true gesetzt werden, sobald die Anfangsoffsetkorrekturtermprüfung durchgeführt wurde. Die Einführung von vOffsetOut geschieht, um die Beschreibung in der Spezifikation zu erleichtern. Als Hilfsvariable wird nicht gefordert, daß dieser Parameter für eine Implementierung einer FlexRay-Protokollsteuerung verwendet wird. Dieses Flag soll immer ausgewertet werden, wenn ein neuer Offsetkorrekturterm im Vergleich zu den konfigurierten Grenzeinstellungen geprüft werden sollte. Das Flag vOffsetOut wird auf false initialisiert, wenn in CC_IntegrationVCW aus dem Zustand CC_InitSync eingetreten wird.
Die Kombination aller dieser Prüfungen stellt sicher, daß der Knoten nur dann zu einem aktiven Sender wird, wenn die lokale Zeitbasis (einschließlich des Zykluszählers und der Taktsynchronisationsparameter) mit der durch die Mehrheit aktiver sync-Knoten in dem System repräsentierten globalen Zeit vereinbar ist.
Der Zustand CC_NormalOperation
Sobald der Knoten, der das erste CAS-Symbol gesendet hat (wodurch der potentielle Zugriffskonflickt aufgelöst und über den Kaltstartweg in das Herauffahren eingetreten wird) und ein zusätzlicher Knoten in den Zustand CC_NormalOperation eingetreten sind, ist die Herauffahrphase für ein Cluster im TT-D-Protokollmodus beendet.
Im TT-M-Protokollmodus tritt ein einziger sync-Knoten ohne jedes Kommunikationsgegenstück in den Zustand CC_NormalOperation ein. Dies ist auf seine Master-Rolle im zeitgetriggerten mastergesteuerten Modus zurückzuführen.
In dem Zustand CC_NormalOperation werden alle konfigurierten Nachrichten für die Übertragung eingeteilt. Dazu gehören alle Datenrahmen sowie der sync-Rahmen.
Der Zustand CC_PassiveOperation
Im Zustand CC_PassiveOperation soll ein Knoten keine seiner konfigurierten Rahmen senden. Dennoch soll der Knoten nicht alle Aktivitäten stoppen – er soll Taktsynchronisation auf der Basis empfangener sync-Rahmen, des Empfangs von Nachrichten und der vollen Unterstützung der Hostschnittstelle durchführen.
Zusätzlich wird mit dem Zustand CC_PassiveOperation das Protokollmerkmal „nur horchen" unterstützt, wobei Knoten voll synchronisiert sind und alle verfügbaren Rahmen (einschließlich Empfangspufferaktualisierung) empfangen, aber nichts senden sollen. Dieser Modus soll durch vListenOnly angezeigt werden, das vom Host nur in dem Zustand CC_SoftReset gesetzt werden kann. Sobald der Host vListenOnly löscht, soll am Anfang des nächsten Zyklus in den Zustand CC_NormalOperation eingetreten werden.
Herauffahren – byteflight-Protokollmodus (BF)
Eine korrekt konfigurierte Sync-Master-Kommunikationssteuerung (pMaster ist true) soll über den Übergang von CC_SoftReset zu CC_byteflightMaster in die Herauffahrsequenz eintreten.
Es sollte ein einziger Knoten als der sync-Master-Knoten konfiguriert werden, der auf allen gChannels Kanälen ein Statussymbol senden muß. Für den sync-Master-Knoten muß pChannels gleich gChannels sein.
Eine korrekt konfigurierte Slave-Knotenkommunikationssteuerung (pMaster ist false) soll über den Übergang von CC_SoftReset zu CC_byteflightListen in die Herauffahrsequenz eintreten. Alle Slave-Knoten sollen sich mit dem durch den sync-Master-Knoten übertragenen Statussymbol synchronisieren. Wenn dieser Knoten nicht startet, fährt das System nicht herauf.
Slave-Knoten starten ihren Kommunikationszyklus auf beiden Kanälen mit dem Empfang des ersten gültigen Statussymbols auf einem der pChannels Kanäle.
Eine ausführliche Beschreibung des byteflight-Protokollmodus findet man in M. Peller, J. Berwanger und R. Greissbach, byteflight Specification, Version 0.5, BMW Corporation 1999, verfügbar bei http://www.byteflight.com.
Herauffahr-Zustandsdiagramm – byteflight-Protokollmodus (BF)
63 zeigt ein Herauffahrzustandsdiagramm des byteflight-Protokollmodus (BF)
Tabelle 15: Zustandsübergänge und entsprechende Bedingungen für die Ausführung
Der Zustand CC_SendSymbol
Ein einzelner Knoten, der als sync-Master konfiguriert wurde (pMaster ist gesetzt) soll ein Statussymbol senden. Beim Ende der Übertragung sollen die Timer (der Empfängereinheit) gemäß den Definitionen in der byteflight-Spezifikation gestartet werden (siehe M. Peller, J. Berwanger und R. Greissbach, byteflight Specification, Version 0.5, BMW Corporation 1999, verfügbar bei http://www.byteflight.com) und der Knoten soll in den Zustand CC_byteflightMaster eintreten.
Wenn ein Knoten in den Zustand CC_SendSymbol eintritt, während ein Rahmenempfang abläuft, wird der Empfangsprozeß gestoppt.
Der Zustand CC_byteflightMaster
Ein Knoten soll Nachrichten in dem Zustand CC_byteflightMaster gemäß seiner Konfiguration senden und empfangen. Nach dem Eintritt in den Zustand CC_byteflightMaster, d.h. nach der Übertragung des Statussymbols, ist die Herauffahrphase abgeschlossen. Der Master-Knoten benötigt keinerlei Bestätigung von anderen Knoten.
Der Zustand CC_byteflightListen
Alle Slave-Knoten (pMaster ist false) sollen im Zustand CC_byteflightListen auf den Empfang eines gültigen Statussymbols warten. Alle konfigurierten pChannels Kanäle sollen unabhängig überwacht werden. Der Übergang in CC_byteflightSlave und deshalb die Synchronisation beider Kanäle mit dem Master soll beim Empfang des ersten gültigen Statussymbols erfolgen. Nach der Initialisierung der Wartetimer sollen alle konfigurierten Kanäle asynchron in bezug auf das erforderliche Rahmen-Minislotting auf jedem der pChannels Kanäle operieren.
Der Zustand CC_byteflightSlave
Slave-Knoten sollen sich mit einem gültigen Statussymbol synchronisieren und Nachrichten in dem Zustand CC_byteflightSlave gemäß ihrer Konfiguration senden und empfangen.
Der Zustand CC_byteflightPassive
In CC_byteflightPassive soll ein Knoten keine seiner konfigurierten Rahmen senden. Der Knoten soll nicht alle Aktivitäten stoppen, sondern soll weiter die Synchronisation auf Statussymbole (über den Zustand CC_byteflightListen) und den Empfang von Nachrichten durchführen.
Der Zustand CC_byteflightPassive dient zur Unterstützung des Protokollmerkmals „Nur-Horchen", wobei der Knoten voll synchronisiert sein soll und alle verfügbaren Rahmen (einschließlich Empfangspufferaktualisierung) empfangen soll, aber nichts senden soll. Dieser Modus soll durch vListenOnly angezeigt werden, das vom Host nur in dem Zustand CC_SoftReset gesetzt werden kann. Sobald der Host vListenOnly löscht, soll beim Anfang des nächsten Zyklus wieder in den Zustand CC_byteflightSlave eingetreten werden.
Da die Kommunikationssteuerung den Übergang zu dem Zustand CC_byteflightListen bei jedem Kommunikationszyklus durchführt, ist er immer noch mit dem Master-Knoten synchronisiert. Deshalb darf der Knoten direkt aus CC_byteflightListen (am Anfang des nächsten Zyklus) in CC_byteflightSlave wiedereintreten, wenn der Host vListenOnly auf false setzt.
Herauffahren – der ereignisgetriggerte Protokollmodus (ET)
Das Verhalten des Knotens während des Herauffahrens wird später in der Beschreibung beschrieben.
Herauffahrbeispiele – zeitgetriggerter Protokollmodus (TT-D)
Für alle in diesem Kapitel beschriebenen Herauffahrsequenzen wird angenommen, daß die Korrekturterme für die Taktsynchronisation genau mit den Grenzeinstellungen des Qualitätsbewertungskriteriums übereinstimmen (siehe oben). Deshalb darf der Knoten direkt in den Normalbetrieb (Zustand CC_NormalOperation) voranschreiten, nachdem die Offsetmessung, die Korrekturphase und die Phase der regulären Ratenmessung zum ersten Mal durchgeführt wurden.
Herauffahren ohne Kollisionen
Das in 64 dargestellte Szenario zeigt drei Knoten, wobei zwei davon dafür konfiguriert sind, das Herauffahren aktiv einzuleiten (sync-Knoten A und B). Knoten C ist nicht dafür konfiguriert, sync-Rahmen einzuteilen, und darf deshalb nicht in CC_ColdStartICW eintreten. Der erste von den Knoten B und C empfangene Zykluszählerwert befindet sich in dem durch Knoten A gesendeten sync-Rahmen und ist gerade.
Knoten A tritt in CC_ColdStartICW ein und sendet das Anfangs-CAS vor jedem anderen Knoten. Getriggert durch die damit zusammenhängende Kanalaktivität startet Knoten B seine Horchzeitgrenze vdStartup neu. Beim Empfang des CAS-Symbols wird die Horchzeitgrenze vdStartupNoise neu gestartet. Bei dem ersten sync-Rahmen (fFrameId = 3), der von Knoten A gesendet wird, treten alle anderen Knoten in CC_InitSync ein. An diesem Punkt wird Knoten A zu dem Referenzknoten (vSyncRef = 3) und die Meßphase für Anfangsratenkorrekturterm wird gestartet. Das nächste Auftreten des sync-Rahmens von Knoten A stoppt die Ratenmeßphase. Der Ratenkorrekturterm wird von den Knoten B und C direkt bestimmt und auf ihre lokale Taktrate angewandt (d.h. auf ihre lokale Makrotickerzeugungseinheit). zusätzlich wird auf der Basis der Referenzrahmen-ID die tatsächliche Ablaufsteuerungsposition bestimmt und die Mikro- und Makroticktimer werden unter Verwendung der fallenden Flanke des vorderen BSS des empfangenen sync-Rahmens synchronisiert.
Die Knoten B und C folgen der aktuellen Ablaufsteuerung bis zum Zyklusende und gehen dann in den Zustand CC_IntegrationVCW über. Diese Knoten verhalten sich immer noch passiv, d.h. sie nehmen nicht mit ihren eigenen Rahmen an der Kommunikationsablaufsteuerung teil. Nach einem vollständigen Ratenmeßzeitraum (zwei Zyklen) und der entsprechenden Offsetmeß- und -korrekturphase (während des zweiten Zyklus) wird dem sync-Knoten B der Eintritt in den Normalbetrieb erlaubt. Die in dem Zustand CC_IntegrationVCW ausgewerteten Validierungsprüfungen werden bestanden, weil beim Empfang des Referenz-Sync-Rahmens vValidSyncCount[ch] erhöht wird, während vInvalidSyncCount[ch] unverändert bliebt. Beim Start des nächsten Zyklus tritt Knoten B folglich in CC_NormalOperation ein und beginnt mit dem Senden von Nachrichten gemäß seiner eigenen Konfiguration. Beim Empfang des von einem anderen Knoten (Knoten B), der mit sich selbst synchronisiert ist, gesendeten sync-Rahmenpaars tritt der Knoten, der das CAS anfänglich gesendet hat (Knoten A) dann am Start des nächsten Kommunikationszyklus (nachdem ein gesamter Ratenmeßzeitraum abgeschlossen wurde) in CC_NormalOperation ein. In CC_NormalOperation werden alle konfigurierten Rahmen für die Übertragung eingeteilt. Sobald der Knoten, der anfänglich das CAS gesendet hat, und ein anderer Knoten in den Zustand CC_NormalOperation eingetreten sind, ist die Herauffahrphase abgeschlossen.
Knoten C tritt in demselben Zyklus wie Knoten A in CC_NormalOperation ein, sobald er die reguläre Ratenmeßphase auf der Basis von 2 (oder mehr) Paaren entsprechender sync-Rahmen durchgeführt hat.
Herauffahren mit anfänglicher Kollision
65 zeigt ein Herauffahren mit einer Kollision an einem CAS-Symbol. Das in 65 dargestellte Szenario zeigt drei Knoten, wobei sie alle dafür konfiguriert sind, aktiv das Herauffahren einzuleiten (sync-Knoten). Eine Kollision während des Herauffahrens entsteht, wenn zwei sync-Knoten zur selben oder fast zur selben Zeit den Zustand CC_SoftReset verlassen. In diesem Fall treten zwei Knoten (Knoten A und B) gleichzeitig in CC_ColdStartICW) ein und senden ihr anfängliches CAS gleichzeitig oder nahezu gleichzeitig. Beide Knoten sind dann dafür vorbereitet, ihre ersten sync-Rahmen zu senden. Der Knoten mit dem sync-Rahmen mit der niedrigeren Kennung sendet seinen Rahmen zuerst (Knoten B; fFrameID = 1). Beim Empfang dieses sync-Rahmens kehrt der andere Knoten (Knoten A), der gerade in dem Zustand CC_ColdStartICW verankert ist, zu CC_StartupListen zurück und wartet auf das nächste S_ValidEvenStartupFrame. Die Figur zeigt den Fall, in dem sich ein Knoten A in dem sechsten Zyklus nach dem Zyklus, in dem die Kollision stattfand, integriert.
Herauffahren mit Knoten-Versagen aufgrund der Validierungsprüfung
66 zeigt ein Herauffahren mit Validierungsprüfung in CC_IntegrationVCW nicht bestanden. Das in 66 dargestellte Szenario zeigt die Knoten B und C, die die Integration zu dem Referenzknoten (Knoten A) beginnen. Während sich die Knoten B und C in dem Zustand CC_IntegrationVCW befinden, versagt der Empfang des durch den Referenzknoten gesendeten sync-Rahmens in beiden Knoten. Somit versagt auch die Validierungsprüfung in beiden Knoten. Am Ende dieses Zyklus müssen beide Knoten wieder in den Zustand CC_StartupListen eintreten. Da vRefSync von 0 verschieden ist (vRefSync = 3), wird der erste sync-Rahmen aus dem ehemaligen Referenzknoten (Knoten A) ignoriert. Da während gdCycleWithHistory kein weiterer sync-Rahmen auftritt, wird vRefSync am Ende dieses Zyklus gelöscht. Beim nächsten Auftreten des durch Knoten A gesendeten sync-Rahmens (vRefSync ist wieder auf 3 gesetzt), starten Knoten B und C einen weiteren Integrationsversuch. Über den Integrationsweg synchronisieren sich beide Knoten schließlich auf die Zeitsteuerung des Knotens A. In der Zwischenzeit bleibt Knoten A für die gesamte Periode in dem Zustand CC_ColdStartVCW, weil er keine gültige Antwort erkennt.
Anforderungen für Hardware-Zustände
Einführung
Dieses Kapitel beschreibt die HW-Zustände, deren Unterstützung durch CC, BG, elektrisches und optisches BD und den aktiven Stern erforderlich ist. Zusätzlich werden einige wünschenswerte optionale Übergänge beschrieben. Dem Zustandsnamen geht eine Abkürzung aus zwei/drei Buchstaben voraus, die der Hardwarekomponente entspricht, die der Zustand betrifft (d.h. CC, BG, BDe oder BDo). Zustandsübergangsnamen enthalten wie folgt einen von zwei Präfixen:

Zustandsübergänge mit Präfix „V" entsprechend bestimmten Spannungspegeln
Zustandsübergänge mit Präfix „L" zeigen logischen Bedingungen entsprechende Zustandsübergänge an

Der Rest dieses Kapitels besteht aus Abschnitten entsprechend jeder der FlexRay-Hardwarekomponenten. Jeder dieser Abschnitte besteht aus zwei Teilabschnitten; einer beschreibenden Übersicht über die Zustände der Komponente, gefolgt durch eine formalere Verhaltensbeschreibung in Form eines Zustandsdiagramms, zusammen mit einer Tabelle, die die Übergänge in dem Diagramm detailliert.
Spannungspegel
Im allgemeinen müssen drei verschiedene Spannungspegel und entsprechende HW-Zustände unterschieden werden:
PowerOff – Die Versorgungsspannung ist nicht verfügbar oder liegt unter einem vordefinierten Pegel. Folglich können bestimmte integrierte Schaltungen ihre Anschlüsse nicht in einem definierten Zustand, z.B. Tri-State, halten. Der Halbleiterhersteller muß garantieren, daß während des Herauf-/Herunterfahrens keine Störungen auftreten, oder muß die betroffenen Anschlüsse und ihr Verhalten spezifizieren.
PowerOn – der Versorgungsspannungspegel ist hoch genug, um einen definierten Zustand der Anschlüsse zu garantieren, wobei keine Störungen auftreten. Betrieb/Normal – der Versorgungsspannungspegel ermöglicht vollen Betrieb (Anmerkung: Betrieb/Normal ist ein Unterzustand von PowerOn).
HW-Zustände der CC
Übersicht
Die folgende Übersicht beschreibt das CC-Verhalten in verschiedenen Zuständen. In der Tabelle im Anschluß an das nachfolgende Zustandsdiagramm werden Bedingungen für den Eintritt in diese Zustände und den Austritt aus diesen Zuständen beschrieben. Unterstützung für die Überwachung der Spannungspegel (Brown-Out-Detektion) ist nur für selbständige Steuerungen erforderlich. Dadurch kann die Überwachung durch externe Überwachungshardware erfolgen.
Der Zustand CC_PowerOff

• Die Spannung liegt unter einer vordefinierten Schwelle für den ordnungsgemäßen Betrieb
• Anhalten aller CC-internen Takte
• Die CC darf keinerlei Anschlüsse ansteuern

Der Zustand CC_PowerOn
Der Spannungspegel liegt über einer Schwelle zur Garantie eines definierten Zustands der Anschlüsse
Der Zustand CC_HWReset
Alle Steuerungstakte halten sofort an. Die CC darf keinerlei Anschlüsse ansteuern
Der Zustand CC_Operating
Die CC unterstützt reguläre Kommunikationsfunktion
Der Zustand CC_Awake
Der Zustand CC_SoftReset
Sofortiges Anhalten aller CC-internen Takte mit Ausnahme derjenigen, die für den Betrieb der Hostschnittstelle notwendig sind.
Der Zustand CC_Normal
Es soll reguläre Kommunikation unterstützt werden.
Der Zustand CC_ShutdownComplete
Wenn dieser Zustand vorliegt, ist die Kommunikation inaktiv.
Der Zustand CC_Standby
Die Stromaufnahme der elektrischen CC ist im Vergleich zu CC_Normal signifikant verringert
Alle CC-Takte aus, mit Ausnahme derjenigen, die für die Aufweckdetektion benötigt werden
Konfigurationsdaten bleiben unverändert
Das Zustandsdiagramm der Kommunikationssteuerung (CC)
67 zeigt das Zustandsübergangsdiagramm einer Kommunikationssteuerung (CC). Tabelle 16 ist eine CC-Zustandsübergangstabelle.
Tabelle 16: CC-Zustandsübergangstabelle.
Die Konstanten CC_U1, CC_U2, CC_U3, CC_U4, CC_tv₃ und CC_tv₄ sind produktspezifisch und müssen in der CC-Produktspezifikation definiert werden.
Anmerkung: CC_U1 < CC_U3, CC_U2 < CC_U4
HW-Zustände des elektrischen Bustreibers (BD)
Übersicht
Die folgende Übersicht beschreibt das elektrische BD-Verhalten in verschiedenen Zuständen. Es werden in der Tabelle im Anschluß an das nachfolgende Zustandsdiagramm Bedingungen für den Eintritt in diese Zustände und das Austreten aus diesen Zuständen beschrieben.
Unterstützung für Überwachung der Sperrschichttemperatur ist optional.
Der Zustand BDe_PowerOff

• Die Spannung liegt unter einer vordefinierten Schwelle für ordnungsgemäßen Betrieb
• Der BD darf keinerlei Anschlüsse ansteuern (z.B. kein Rückstrom).

Der Zustand BDe_PowerOn

• Der Spannungspegel liegt über einer Schwelle zur Garantie eines definierten Zustands der Anschlüsse

Der Zustand BDe_Operating
Der BD unterstützt reguläre Kommunikationsfunktion
Der Zustand BDe_Normal
Reguläre Kommunikation soll unterstützt werden
Der Zustand BDe-Standby
Die Stromaufnahme des elektrischen BD ist im Vergleich zu BDe_Normal signifikant verringert Der BD kann keine regulären Nachrichten übertragen Die Aufwecküberwachungsfunktion des BD ist aktiv.
Der Zustand BDe_Sleep
Der BD unterstützt keine reguläre Kommunikation Der BD tritt in einen Modus mit niedriger Stromaufnahme ein, z.B. alle Takte werden gestoppt und nur ein Aufweckempfänger mit niedriger Stromaufnahme aktiv. Die Stromaufnahme ist im Vergleich zu BDe Normal signifikant verringert Die Aufwecküberwachungsfunktion des BD ist aktiv
Der Zustand BDe BusOff

• Die Kanalausgabe des BD befindet sich im Hochimpedanzzustand, z.B. er steuert nicht den Leerlaufpegel des Busses an (schwebt statt dessen)

Der Zustand BDe_BusNormal

Der BD gibt reguläre Buspegel für die Kommunikation aus

BD-Zustandsdiagramm (elektrischer BD)
68 zeigt ein Zustandsübergangsdiagramm des Bustreibers (BD) für einen elektrischen BD. Tabelle 17 ist eine BD-Zustandsübergangstabelle für einen elektrischen BD. Für Zustände des optischen Buswächters siehe 69.
Tabelle 17: BD-Zustandsübergangstabelle (elektrischer BD).
Die Konstanten BDe_U1, BDe_U2, BDe_U3, BDe_U4, BDe_U5, BDe_U6, BDe_t₁, BDe_t_v3, BDe_t_v4, BDe_t_v5, BDe_t_v6 und BDe_K_T1 sind produktspezifisch und müssen in der BD-Produktspezifikation definiert werden.
Anmerkung: BDe_U1 < BDe_U3, BDe_U2 < BD2_U4
HW-Zustände des optischen BD
Übersicht
Die folgende Übersicht beschreibt das Verhalten des optischen BD in verschiedenen Zuständen. In der Tabelle im Anschluß an das nachfolgende Zustandsdiagramm werden Bedingungen für den Eintritt in diese Zustände und den Austritt aus diesen beschrieben.
Der Zustand BDo_PowerOff
Die Spannung liegt unter einer bestimmten Schwelle für ordnungsgemäßen Betrieb
Die CC darf keinerlei Anschlüsse ansteuern.
Der Zustand BDo_Normal
Der BD unterstützt reguläre Kommunikation
Der Zustand BDo_Sleep
Der BD unterstützt keine reguläre Kommunikation
Der BD befindet sich in dem Modus niedriger Stromaufnahme, z.B. alle Takte gestoppt und nur der Aufweckempfänger mit niedriger Stromaufnahme aktiv.
Die Aufwecküberwachungsfunktion des BD ist aktiv
BD-Zustandsdiagramm (optischer BD)
69 zeigt ein Übergangsdiagramm eines Bustreibers (BD) für einen optischen BD. Tabelle 18 ist ein BD-Zustandsübergangsdiagramm für einen optischen BD.
Tabelle 18: BD-Zustandsübergangstabelle (optischer BD).
Die Konstanten BDo_U1, BDo_U2 und BDo_t₁ sind produktspezifisch und müssen in der BD-Produktspezifikation definiert werden.
HW-Zustände des BG
Übersicht
Die folgende Übersicht beschreibt das BG-Verhalten in verschiedenen Zuständen. In der Tabelle im Anschluß an das nachfolgende Zustandsdiagramm werden Bedingungen für den Eintritt in diese Zustände und das Austreten aus diesen beschrieben.
Unterstützung für Überwachung der Spannungspegel (Brown-Out-Detektion) ist nur für selbständige Steuerungen erforderlich, während die Überwachung auch durch eine externe Überwachungshardware durchgeführt werden kann.
Der Zustand BG_PowerOff

• Die Spannung liegt unter einer bestimmten Schwelle für ordnungsgemäßen Betrieb
• Anhalten aller BG-internen Takte
• Der BG darf keinerlei Anschlüsse ansteuern

Der Zustand BG_PowerOn

Der Zustand BG_HWReset
Alle Takte halten sofort an
BG darf keinerlei Anschlüsse ansteuern
Der Zustand BG_Operating
Der BG unterstützt reguläre Funktion
Der Zustand BG_Awake
Der Zustand BG_SoftReset
Freigabe des BD-Senders für eine ablaufende Rahmenübertragung wird gehalten, danach sofortiges Anhalten BG-interner Takte, mit Ausnahme derjenigen, die für den Betrieb der Hostschnittstelle und das Sperren des BD notwendig sind.
Der Zustand BG_Normal
Reguläre Funktion wird unterstützt
Der Zustand BG_Standby
Die Stromaufnahme des BG wird im Vergleich zu BG_Normal signifikant verringert
Alle BG-Takte aus, mit Ausnahme derjenigen, die für den Betrieb der Hostschnittstelle notwendig sind Konfigurationsdaten werden gehalten
Es ist keine explizite Herunterfahrunterstützung für BG erforderlich.
BG-Zustandsdiagramm
70 zeigt ein Zustandsübergangsdiagramm eines Buswächters (BG). Tabelle 19 ist eine BG-Zustandsübergangstabelle.
Tabelle 19: BG-Zustandsübergangstabelle.
Die Konstanten BG_U1, BG_U2, BG_U3, BG_U4, BG_t_v3 und BG_tv₄ sind produktspezifisch und müssen in der BG-Produktspezifikation definiert werden.
Anmerkung: BG_U1 < BG_U3, BG_U2 < BG_U4
HW-Zustände des aktiven Sterns
Übersicht
Die folgende Übersicht beschreibt das Verhalten des aktiven Sterns in verschiedenen Zuständen. In der Tabelle im Anschluß an das nachfolgende Zustandsdiagramm werden Bedingungen für den Eintritt in diese Zustände und das Austreten aus ihnen beschrieben.
Der Zustand ST_PowerOff

Die Spannung liegt unter einer bestimmten Schwelle für ordnungsgemäßen Betrieb

Der aktive Stern darf keinerlei Anschlüsse ansteuern
Der Zustand ST PowerOn
Der Zustand ST_Normal
Der Spannungsregler ist aktiv
Der Zustand ST_Sleep
Der Spannungsregler ist ausgeschaltet
Zustandsdiagramm des aktiven Sterns
71 zeigt ein Zustandsübergangsdiagramm des aktiven Sterns. Tabelle 20 ist eine Zustandsübergangstabelle des aktiven Sterns.
Tabelle 20: Zustandsübergangstabelle des aktiven Sterns.
Die Konstanten ST_U1, ST_U2 und ST_t_s1 sind produktspezifisch und müssen in der Stern-Produktspezifikation definiert werden.
Fehlersignalisierung und Fehlerbehandlung
Fehlersignalisierung
Dieses Kapitel beschreibt die Fehlersignalisierungsmechanismen des FlexRay-Protokolls. Diese Mechanismen sollen es der Hostanwendung oder irgendwelcher anderen Software auf höherer Ebene ermöglichen, von der Anwesenheit unerwarteter Protokollbedingungen zu erfahren. In bestimmten Fällen mag der Host möglicherweise eine bestimmte Aktion durchführen, wenn er über bestimmte Arten von Fehlern benachrichtigt wird. Die vorliegende Protokollspezifikation fordert jedoch nicht, daß die Hostanwendung auf irgendwelche der in diesem Kapitel beschriebenen Fehlerbedingungen reagiert.
Fehlersignalisierung bedeutet die Präsentation gefilterter und/oder ungefilterter Protokollfehlerbedingungsinformationen aus der Kommunikationssteuerung für den Host.
Rahmenempfang und -validierung
Mehrere in diesem Kapitel beschriebene Fehlersignalisierungsmechnismen benutzen den Status des Empfangsprozesses verschiedener Rahmen durch den Rahmenverarbeitungsteil der Protokoll-Engine. Siehe die obige Beschreibung für die Einzelheiten dieser Mechanismen und die Signale, die sie dem Mechanismus zur Fehlersignalisierung/Fehlerbehandlung zuführen.
Symbolempfang und -validierung
Mehrere in diesem Kapitel beschriebene Fehlersignalisierungsmechanismen verlassen sich auf die Detektion verschiedener Protokollsymbole durch den Symbolverarbeitungsteil der Protokoll-Engine. Siehe die obige Beschreibung für die Einzelheiten dieser Mechanismen und der Signale, die sie den Mechanismen für Fehlersignalisierung/Fehlerbehandlung zuführen.
Fehlersignale und Fehlerzähler
Dieser Abschnitt beschreibt die Fehlersignale und Fehlerzähler des FlexRay-Protokolls. Mit Fehlersignalen wird dem Host ein erkannter Fehler angezeigt. Fehlerzähler dienen zum Zählen von Fehlern und es werden Informationen bezüglich der Anzahl von Fehlern an den Host weitergeleitet. In allen Fällen dürfen die Fehlerzähler nicht über ihren Maximalwert hinaus inkrementiert werden, d.h. die Zähler sollen nicht auf Null zurück „umlaufen", sondern statt dessen auf ihrem Maximalwert bleiben.
Tabelle 21 und Tabelle 22 zeigen die Fehlersignale und Fehlerzähler des FlexRay-Protokolls. Die folgenden Abschnitte geben ausführliche Beschreibungen der verschiedenen Signale und Zähler.
Tabelle 21: Fehlersignale und Fehlerzähler für den FlexRay-Betriebsmodus
Tabelle 22: Fehlersignale für den byteflight-Betriebsmodus
Rahmenstatus- und -fehlerinformationen (FSEI)
Eine FlexRay-Kommunikationssteuerung soll eine Klassifizierung des Schlitzstatus pro Kanal für jeden zum Empfang eines Rahmens gebuchten Schlitz geben. Ein Schlitz wird für den Empfang eines Rahmens gebucht, wenn ein Filter (bezüglich Rahmen-ID, Zykluszähler und Kanal – siehe die folgende Beschreibung) für diesen Schlitz gesetzt ist.
Tabelle 23 zeigt die Status- und Fehlerinformationen für einen gebuchten Schlitz. Die Bestimmung dieser Status basiert auf der Anwesenheit oder Abwesenheit bestimmter in den obigen Abschnitten definierter Rahmenempfangsstatussignale.
Tabelle 23: Fehlersignale in Bezug auf FSEI
Übertragungskonflikt wird nur erkannt, wenn der Knoten versucht, einen Rahmen zu senden, während er empfängt. Das Fehlersignal gehört zu der Schlitz-ID des gesendeten Rahmens. Wenn ein Empfangspuffer dafür konfiguriert ist, den Stil „erstes gültiges nehmen" der Kanalfilterung zu verwenden (siehe unten), sollen die folgenden zusätzlichen Informationen bezüglich des Status des Kanals, der nicht für die Nutzsignalspeicherung gewählt wurde, in den FSEI zusammengefaßt werden:
Tabelle 24: Zusätzliche FSEI-Fehlersignale für die Kanalfilterung der Art „erstes gültiges nehmen"
S_InvalidDTSError gilt nur während des Rahmenempfangs in dem dynamischen Segment. Jeder Schlitz, der zum Empfangen eines Rahmens gebucht ist, besitzt entsprechende FSEI. Die FSEI sollen auf Null zurückgesetzt werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das vorherige Kapitel). Die FSEI sollen beginnen, aktualisiert zu werden, nachdem eine CC die Protokollherauffahrphase (siehe oben) erfolgreich durchlaufen hat.
Die FSEI werden immer aktualisiert, sobald die Empfangsrahmenverarbeitung beendet ist (siehe oben). Der empfangene Dateninhalt soll nur der Datenspeicherung zugeführt werden, die dem gebuchten Schlitz entspricht, wenn keine der oben aufgelisteten Fehlerinformationen gesetzt wurden (wenn das Kanalfilter „erstes gültiges nehmen" konfiguriert ist, listen die FSEI mindestens eines Kanals keine Fehlerinformationen). In allen anderen Fällen sollen nur die aktuellen FSEI der Datenspeicherung zugeführt werden. Es soll möglich sein, während der Konfiguration der CC eine Teilmenge der FSEI-Komponenten [Bytecodierungs-/CRC-Fehler, Schlitznichtübereinstimmung, Zykluszählernichtübereinstimmung, Längennichtübereinstimmung, Null-Rahmen, leerer Schlitz, Übertragungskonflikt, Empfangsfehler auf dem zweiten Kanal, leerer Schlitz auf dem zweiten Kanal] als die Triggerbedingung für ein Interrupt des Hosts zu definieren. Diese Teilmenge gilt für alle gebuchten Schlitze.
Kanalstatus- und -fehlerinformationen (CSEI)
Eine FlexRay-Kommunikationssteuerung soll eine akkumulierte Klassifizierung des Schlitzstatus aller auf einem gegebenen Kanal empfangener Rahmen geben. Daraus folgt, daß eine FlexRay-CC, die Kommunikation auf zwei Kanälen unterstützt, zwei solche Informationssätze liefern soll. Die Kanalstatus- und -fehlerinformationen (CSEI) fassen den Status aller auf dem Kommunikationskanal empfangener Rahmen, einschließlich der Rahmen, die nicht gebucht sind und deshalb keine entsprechenden Daten oder Statusspeicherung in der CHI aufweisen, zusammen. Tabelle 25 zeigt den Inhalt der CSEI und beschreibt die Abbildung der oben beschriebenen Rahmen- und Symbolverarbeitungsstatussymbole.
Tabelle 25: Fehlersignale in Bezug auf CSEI
S_InvalidDTSError gilt nur während des Rahmenempfangs in dem dynamischen Segment. Die CSEI sind über die Steuerungs-Hostschnittstelle (CHI) durch den Host lesbar. Alle Komponenten der CSEI sollen zurückgesetzt (zum Beispiel alle Komponenten auf Null gesetzt) werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten (siehe oben) ausführt. Die Komponenten der CSEI sollen beginnen, aktualisiert zu werden, sobald eine CC erfolgreich die Protokollherauffahrphase (siehe oben) durchläuft.
Die Komponenten der CSEI werden nach Abschluß der Rahmenverarbeitung jedes Kommunikationsschlitzes aktualisiert (siehe das Kapitel „Rahmenverarbeitung"). Die Komponenten der CSEI sollen auch beim Abschluß der Symbolverarbeitung aktualisiert werden (siehe das Kapitel „Symbolverarbeitung").
Wenn eine CSEI-Komponente bereits aufgrund einer früheren Aktualisierung gesetzt ist, soll die Komponente gesetzt bleiben. Dadurch können die CSEI den aggregierten Status aller Rahmen auf dem Kommuni kationskanal melden. Alle Komponenten der CSEI sollen durch eine Host-Leseoperation zurückgesetzt werden.
Während der Konfiguration der CC soll es möglich sein, eine Teilmenge der CSEI-Komponenten (Bytecodierungsfehler/CRC-Fehler, Schlitznichtübereinstimmung, Zykluszählernichtübereinstimmung, Längennichtübereinstimmung, nichtakzeptiertes Symbol) als die Triggerbedingung für einen Interrupt des Hosts zu definieren. Diese Teilmenge gilt für alle Kanäle.
Kaltstartzählwertmaximumsignal (CCMS)
Das Kaltstartzählwertmaximalsignal (CCMS) soll gesetzt werden, um anzuzeigen, daß die CC die maximale Anzahl zulässiger Kaltstartneuversuche erreicht hat (siehe die Spezifikation des Kaltstarts in dem Kapitel „Aufwecken, Herauffahren und Reintegration"). Das CCMS folgt dem Wert von vCCMS. CCMS soll auf Null zurückgesetzt werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände"). Das CCMS wird nur während der Protokollherauffahrphase auf eins gesetzt, wenn vCCMS gesetzt wurde (siehe das Kapitel „Aufwecken, Herauffahren und Reintegration"). Nachdem es auf eins gesetzt ist, bleibt das CCMS gesetzt, bis die CC den Zustandsübergang L5 oder L6 des HW-Automaten das nächste Mal ausführt.
Taktbezogene Fehlersignale und Zähler
Herauffahr-Mehrheits-Verfehlt-Signal (SMMS)
Das Herauffahr-Mehrheit-Verfehlt-Signal (SMMS) soll gesetzt werden, um anzuzeigen, daß die CC während des Herauffahrens eine Menge von sync-Rahmen empfangen hat, die nicht dazu geführt hat, daß eine Mehrheit der sync-Rahmen mit der lokalen Sicht der Systemzeit übereinstimmt (siehe das Kapitel „Aufwecken, Herauffahren und Reintegration"). Das SMMS folgt dem Wert von vSMMS. Das SMMS soll auf Null zurückgesetzt werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände"). Das SMMS wird auf eins gesetzt, wenn vSMMS in der Protokollherauffahrphase gesetzt wurde.
Nachdem es auf eins gesetzt wurde, bleibt das SMMS gesetzt, bis der Host dieses Signal löscht.
Fehlende-Ratenkorrektur-Signal (MRCS)
Das Fehlende-Ratenkorrektur-Signal (MRCS) zeigt die Unfähigkeit an, aufgrund des Fehlens jeglicher übereinstimmender Paare von sync-Rahmen in den geraden und ungeraden Kommunikationszyklen einen Taktsynchronisationsratenkorrekturwert zu berechnen. Das MRCS folgt dem Wert von vMRCS. MRCS soll gesetzt werden, wenn vMRCS durch den Taktsynchronisationsmechanismus gesetzt wurde (siehe das Kapitel „Taktsynchronisation"). Im dynamischen Medium-Zugriffsmodus ist die Setzbedingung gegeben, wenn der Knoten nicht einen geraden und einen ungeraden Referenzrahmen empfangen hat. Da der Referenzrahmen alle Zeitsteuerungsinformationen in einem im dynamischen Medium-Zugriffsmodus arbeitenden System liefert, zeigt der den Referenzrahmen in einem solchen System bereitstellende Knoten niemals einen MRCS-Fehler an.
Das Signal soll auf eins gesetzt bleiben, bis der Taktsynchronisationsalgorithmus einen gültigen Ratenkorrekturterm berechnen kann und deshalb vMRCS zurücksetzt.
Das MRCS soll auf Null gesetzt werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände").
Während der Protokollherauffahrphase soll MRCS auf eins gesetzt werden, wenn das Signal vMRCS durch Herauffahren gesetzt wurde (siehe das Kapitel „Aufwecken, Herauffahren und Reintegration"). Für Nicht-Sync-Knoten und für einen sync-Knoten im Nur-Horch-Modus zeigt dieses Signal an, daß ein zweites Paar übereinstimmender sync-Rahmen fehlt. Das MRCS bleibt auf eins gesetzt, bis der Host dieses Signal löscht oder die Protokollherauffahrphase erfolgreich durchlaufen wurde.
Während der Konfiguration der CC soll es möglich sein, zu definieren, daß MRCS ein Trigger eines Interrupts des Hosts ist.
Fehlende-Offsetkorrektur-Signal (MOCS)
Das Fehlende-Offsetkorrektur-Signal (MOCS) zeigt die Unfähigkeit an, aufgrund des Fehlens von sync-Rahmen in einem ungeraden Kommunikationszyklus durch den Taktsynchronisationsmechanismus einen Offsetkorrekturwert zu berechnen (siehe das Kapitel „Taktsynchronisation"). Das MOCS folgt dem Wert von vMOCS. MOCS soll gesetzt werden, wenn vMOCS durch den Taktsynchronisationsmechanismus gesetzt wurde (siehe das Kapitel „Taktsynchronisation"). Im dynamischen Medium-Zugriffsmodus geschieht dies, wenn der Knoten keinen Referenzrahmen in einem ungeraden Zyklus empfängt. Der den Referenzrahmen bereitstellende Knoten zeigt niemals einen MOCS-Fehler an.
Das Signal bleibt auf eins gesetzt, bis der Taktsynchronisationsalgorithmus einen gültigen Offsetkorrekturterm berechnen kann und deshalb vMOCS zurücksetzt.
Das MOCS soll auf Null gesetzt werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände").
Während der Protokollherauffahrphase soll das MOCS auf seinem Anfangswert bleiben. Bis der Knoten erfolgreich aus der Protokollherauffahrphase austritt, ist keine Aktualisierung dieses Signals möglich.
Es soll möglich sein, während der Konfiguration des CC zu definieren, daß MOCS ein Trigger eines Interrupts des Hosts ist.
Taktkorrekturgrenze erreicht (CCLR)
Taktkorrekturgrenze erreicht (CCLR) zeigt eine Unfähigkeit an, eine Taktsynchronisationsrate oder Offsetkorrektur anzuwenden, weil die berechnete Korrektur die Grenzwerte überschritten hat. CCLR folgt dem Wert von vCCLR. CCLR soll auf eins gesetzt werden, wenn die Grenzprüfungen an den Raten- und Offsetkorrekturwerten anzeigen, daß einer dieser oder beide diese Parameter in der roten Region liegen und vCCLR gesetzt wurde (siehe Abschnitt 0). Das CCLR-Signal soll auf eins gesetzt bleiben, bis der Knoten in der Lage ist, Raten- und Offsetkorrekturterme zu berechnen, die beide in dem grünen Bereich liegen, und der Taktsynchronisationsmechanismus setzt deshalb vCCLR auf Null zurück. Das CCLR-Fehlersignal soll auch auf Null gesetzt bleiben, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände").
Man beachte, daß die Rot-/Grünregion-Bestimmungen durchgeführt werden, nachdem etwaige durch den Host bereitgestellte externe Taktkorrekturen berücksichtigt wurden (siehe den Abschnitt „Externe Taktsynchronisation (optional)"). Aus diesem Grund basiert vCCLR auf dem Aggregat der (etwaigen) internen und externen Taktkorrekturterme. Ein System, das normalerweise aufgrund interner Taktsynchronisation kein CCLR erfahren würde (zum Beispiel arbeitet der Referenzknoten in einem System in dem dynamischen Mediumzugriffsknoten), kann immer noch als Ergebnis einer externen Ratenkorrektur solche Fehler erfahren.
Während der Protokollherauffahrphase soll CCLR auf eins gesetzt werden, wenn vCCLR während der Protokollherauffahrphase gesetzt wird (siehe das Kapitel „Aufwecken, Herauffahren und Reintegration"). Das CCLR-Signal bleibt auf eins gesetzt, bis die CC gültige Raten- und Offsetkorrekturwerte berechnen kann und die Protokollherauffahrphase erfolgreich durchlaufen wurde und deshalb vCCLR auf Null zurückgesetzt wurde (siehe das Kapitel „Aufwecken, Herauffahren und Reintegration"). CCLR kann durch den Host auf Null zurückgesetzt werden, bevor das Ende der Protokollherauffahrphase erreicht wurde.
Es soll möglich sein, während der Konfiguration der CC zu definieren, daß CCLR ein Trigger eines Interrupts des Hosts ist.
Taktkorrektur-Mißerfolg-Zähler (CCFC)
Der Taktkorrektur-Mißerfolg-Zähler (CCFC, Bereich [0 .. 15]) ermöglicht es dem Host, die Dauer der Unfähigkeit eines Knotens, Taktkorrekturterme zu berechnen, nachdem die CC die Protokollherauffahrphase durchlaufen hat, zu überwachen. Er soll einmal am Ende jedes ungeraden Kommunikationszyklus, in dem entweder MOCS oder MRCS gesetzt ist, inkrementiert werden. Der CCFC soll am Ende eines ungeraden Kommunikationszyklus auf Null zurückgesetzt werden, wenn weder das MOCS noch das MRCS aktiv sind. Der CCFC hört bei 15 mit dem Inkrementieren auf (d.h. ein Inkrementieren des Zählers auf seinem Maximalwert soll nicht bewirken, daß er zurück zu Null „umläuft"). Der CCFC soll auf Null zurückgesetzt werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände").
Zusammenfassung
Die folgenden Tabellen fassen die Bedingungen und Anwendbarkeit der verschiedenen taktbezogenen Fehlersignale und Zähler zusammen.
Tabelle 26: Taktsynchronisationsfehlersignale und Zähler während CC_Normal-Betrieb und CC_Passive-Betrieb
Tabelle 27: Taktsynchronisationsfehlersignale und Zähler während der Protokollherauffahrphase
Buswächter-Ablaufsteuerungsüberwachungsfehler (BGME)
Mit dem Buswächter-Ablaufsteuerungsüberwachungsfehler (BGME) wird signalisiert, daß die CC erkannt hat, daß das durch den Buswächter durchgesetzte Statisches-Segment-Übertragungsmuster nicht mit dem in die Kommunikationssteuerung konfigurierten Statisches-Segment-Übertragungsmuster übereinstimmt. Der BGME folgt dem Wert des in der Beschreibung der BG-Ablaufsteuerungsüberwachung definierten Parameters vBgsmError (siehe Abschnitt „BG-Ablaufsteuerungsüberwachungsdienst").
BGME soll auf Null gesetzt werden, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände"). BGME soll immer dann auf eins gesetzt werden, wenn vBgsmError = TRUE gilt (siehe Spezifikation in dem Kapitel „Buswächterschnittstelle"). (Für das Verhalten während der Protokollherauffahrphase wird auch auf das Kapitel „Buswächterschnittstelle" verwiesen).
BGME soll auf Null gesetzt werden, sobald der Host die BG-Ablaufsteuerungsnichtübereinstimmung durch aktive Bestätigung über das Signal vBgsmErrorAck bestätigt (siehe das Kapitel „Buswächterschnittstelle").
Bestimmte Systeme benutzen den BG-Ablaufsteuerungsüberwachungsdienst nicht. Es besteht keine Anforderung, daß die CC einen Mechanismus bereitstellt, um eine Sperrung dieses Dienstes zu erlauben – nicht anwendbare Ergebnisse müssen vom Host ignoriert werden.
Es soll möglich sein, während der Konfiguration der CC zu definieren, daß BGME ein Trigger eines Interrupts des Hosts ist.
Tabelle 28: Fehlersignale in bezug auf die BG-Ablaufsteuerungsüberwachung
Fehlersignale in bezug auf SOC/ILLPIF (byteflight-Modus)
Die folgenden Fehlersignale können benutzt werden, um es dem Host zu erlauben, den Status des periodischen SOC-Symbols zu überwachen und das Auftreten illegaler Impulse anstelle von SOC-Symbolen für in dem byteflight-Mediumzugriffsmodus arbeitende Systeme zu erkennen.
Im byteflight-Modus steuert die byteflight-Master-CC die Kommunikationsablaufsteuerung durch ihr eigenes SOC-Symbol, und die folgenden Fehlersignale gelten deshalb nicht für einen Knoten, der als der byteflight-Master arbeitet.
SOC zu früh
Dieses Fehlersignal soll gesetzt werden, wenn das Ende eines korrekten SOC (Symbol hat die Prüfungsmenge „ValidSOC") vor gdCycleMin auftritt. Dieses Fehlersignal wird durch eine Host-Leseoperation zurückgesetzt.
SOC verloren
Dieses Fehlersignal soll gesetzt werden, wenn das Ende eines gültigen SOC nicht vor gdCycleMax auftritt (kein Symbol hat die Prüfungsmenge „ValidSOC" vor gdCycleMax bestanden). Dieses Fehlersignal wird durch eine Host-Leseoperation zurückgesetzt.
Illegaler-Impuls-Fehler (ILLPIF)
Dieses Fehlersignal soll gesetzt werden, wenn eine der folgenden Bedingungen erfüllt ist:
gdCycleMin ist seit dem letzten gültigen SOC-Symbol (Symbol hat die Prüfungsmenge „ValidSOC" bestanden) nicht abgelaufen und eine Sequenz von logisch „0" mit einer Dauer zwischen 21·gdBit und 29·gdBit oder einer Dauer von mehr als 31·gdBit wurde empfangen, ODER
gdCycleMin ist seit dem letzten korrekten (gültigen) SOC-Symbol (Symbol hat die Prüfungsmenge „ValidSOC" bestanden) abgelaufen und es wurde eine bestimmte Busaktivität erkannt (mit Ausnahme eines gültigen SOC-Symbols).
Dieses Fehlersignal wird durch eine Host-Leseoperation zurückgesetzt.
Tabelle 29: Fehlersignale in bezug auf SOC/ILLPIF im byteflight-Modus
Fehlerbehandlung
Fehlerbehandlung bedeutet das Verhalten der unteren Protokollschichten, wenn irreguläre Protokollbedingungen erkannt wurden. Abhängig von der Beschaffenheit und Dauer der Fehlerbedingung tritt die Protokollsteuerung in bestimmte Zustände ein, um solche Bedingungen abzuhandeln. In bestimmten Fällen ist Programmbefehlaktivität auf höheren Schichten erforderlich, damit die Protokollsteuerung den Normalbetrieb wieder aufnimmt.
Das in dieser Schrift beschriebene Fehlerbehandlungskonzept soll sicherstellen, daß die Kommunikation zwischen nichtbeeinflußten Knoten bei Anwesenheit eines Protokollfehlers einer niedrigen Schicht in einem einzigen Knoten aufrechterhalten werden kann. Außerdem soll die Kommunikation aufrechterhalten werden, wenn sich ein Host bei Abwesenheit eines Fehlers in dem lokalen Protokoll der niedrigeren Schicht auf nicht-optimale Weise verhält.
Protokollfehlerzustände
Die hier beschriebenen Fehlerbehandlungsmechanismen sind dafür bestimmt, die Kommunikation auch bei Anwesenheit von Fehlern so lang wie möglich aufrechtzuerhalten.
Die Fehlerbehandlung basiert auf drei Fehlerzuständen mit einer assoziierten Fehlerhypothese und einer assoziierten Strategie für die nächsten Schritte (Verhalten) der CC (siehe Tabelle 30). Diese Fehlerzustände entsprechen einem Ampelmodell [grün, gelb, rot].
Tabelle 30: Protokollfehlerzustände [grün, gelb, rot]
Übersicht über die Übergänge in dem FlexRay-Fehlerautomaten
Die folgenden Abschnitte und Tabellen fassen die erforderlichen Beziehungen zwischen den Fehlersignalen, die Werte der Fehlerzähler und die Übergänge in den Protokollfehlerzuständen [grün, gelb, rot] zusammen. Die Zustände geben die FlexRay-Fehlerbehandlung auf der Basis der Dreizustands-Fehlerhypothese des Protokolls wieder. Der Abschnitt „Fehlerbehandlung für Protokollmodus TT-D und TT-M" deckt die Übergänge während des Protokollbetriebes für den zeitgetriggerten verteilten Protokollmodus und den zeitgetriggerten mastergesteuerten Protokollmodus ab und der Abschnitt „Fehlerbehandlung für Protokollbetrieb im byteflight-Protokollmodus" deckt die Übergänge während des Protokollbetriebes im byteflight-Protokollmodus ab.
Fehlerbehandlung für Protokollmodus TT-D und TT-M
Dieser Abschnitt beschreibt den zentralen Fehlerbehandlungsmechanismus für FlexRay-Knoten, die in dem statischen, gemischten und dynamischen Mediumzugriffsmodus arbeiten. Der Protokollfehlerzustand wird auf grün gesetzt, wenn die CC den Zustandsübergang L5 oder L6 des HW-Automaten ausführt (siehe das Kapitel „Anforderungen für Hardwarezustände"), unabhängig von dem konfigurierten FlexRay-Modus (statisch, dynamisch oder gemischt).
Wenn der CCFC-Wert kleiner ist als gMaxWithoutClockCorrectionPassive (Bereich [1 .. 7]), soll sich der Fehlerzustand im Grün-Zustand befinden, wenn nicht irgendein anderer Fehler einen Gelb- oder Rot-Zustand verursacht.
Wenn CCFC gleich gMaxWithoutClockCorrectionPassive wird, soll die Fehlerhypothese des Gelb-Zustands angenommen werden (wenn nicht eine bestimmte andere Bedingung bewirken würde, daß der Fehlerzustand rot ist). Die Taktkorrektur arbeitet möglicherweise nicht korrekt und deshalb soll die CC keinerlei Rahmen senden. Es ist möglich, daß auch der BG nicht mit der Ablaufsteuerung des Clusters synchronisiert ist. So lange CCFC nicht gMaxWithoutClockCorrectionFatal erreicht (Bereich [≥ gMaxWithoutClockCorrectionPassive ... 15]), bliebt die CC in dem Gelb-Fehlerzustand. Wenn CCFC wieder zurückgesetzt wird (siehe Abschnitt 0), soll der Grün-Zustand aktiv werden, wenn nicht irgendein anderer Fehler einen Gelb- oder Rot-Zustand verursacht. Die CC war in der Lage, sich zu resynchronisieren und ist voll funktionsfähig.
Wenn CCFC gleich gMaxWithoutClockCorrectionFatal wird, soll die Fehlerhypothese des Rot-Zustands angenommen werden. Die CC konnte sich nicht auf das Cluster resynchronisieren. Die CC soll nur durch ihren Host zurückgesetzt werden. Der Parameter gMaxWithoutClockCorrectionFatal wird als eine benutzerdefinierte Schwelle betrachtet, mit der die Änderung der Fehlerhypothese gesteuert wird, und setzt die Schwelle, wann von dem Gelb-Zustand in den Rot-Zustand gewechselt werden soll. Wenn der Knoten mit gMaxWithoutClockCorrectionPassive = gMaxWithoutClockCorrectionFatal konfiguriert ist, soll der Knoten in den Rot-Zustand eintreten, sobald CCFC gleich ihrem gemeinsamem Wert ist. Diese Konfiguration kann für bestimmte Arten von Systemen wünschenswert sein.
Wenn der CCLR gesetzt ist (siehe Abschnitt 0), soll die CC sofort in den Rot-Protokollfehlerzustand eintreten. Die CC soll in dem Rot-Zustand bleiben, bis der Host die CC zurücksetzt.
Während der Protokollherauffahrphase soll CCLR den Fehlerbehandlungsmechanismus nicht beeinflussen.
Die oben beschriebenen Übergänge sollen in allen FlexRay-Mediumzugriffsarten verwendet werden. Der dynamische Modus hat jedoch einige spezielle Situationen. Im dynamischen Modus wird nur ein statischer Schlitz zum Zwecke des Sendens des Referenzrahmens definiert und das System arbeitet deshalb in einer Master/Slave-Konfiguration. Alle CCs, die als Slaves in dem Cluster wirken, müssen den Referenzrahmen und seinen Inhalt als die einzige Datenquelle für ihre Taktsynchronisationsalgorithmen annehmen. Dies führt zu einem Taktsynchronisationsalgorithmus, der auf dem Empfang von nur einem sync-Rahmen basiert (siehe das Kapitel „Taktsynchronisation"). Der Mechanismus selbst, einschließlich Raten- und Offsetkorrekturberechnung, kann damit fertig werden (d.h. der Einzel-Sync-Knotenfall ist nur ein Spezialfall des allgemeinen Taktsynchronisationsalgorithmus). Im dynamischen Mediumzugriffsmodus arbeitende Knoten sollen deshalb dieselben Taktsynchronisations-Fehlerbehandlungsmechanismen wie bei den anderen Mediumzugriffsarten verwenden. Ein MRCS auf einem solchen System bedeutet, daß der gerade und/oder ungerade Referenzrahmen fehlt und kein Ratenkorrekturwert berechnet werden konnte. Ein MOCS bedeutet, daß kein ungerader Referenzrahmen empfangen wurde und kein Offsetkorrekturterm berechnet werden konnte. Der CCFC soll gemäß seiner Spezifikation in dem Abschnitt „Taktkorrektur-Erfolglos-Zähler (CCFC)" inkrementiert und der Fehlerautomat soll deshalb dem oben definierten verhalten folgen. Besondere Aufmerksamkeit wird der Konfiguration der Werte für gMaxWithoutClockCorrectionPassive und gMaxWithoutClockCorrectionFatal gegeben. Wie definiert, wird ein Slave mit dem Senden eines etwaigen Datenrahmens aufhören, sobald er in den Gelb-Zustand eintritt.
Dasselbe gilt für die Grenzprüfungen in den Slaves. Wenn der Referenzrahmen zu viel von der lokalen Sicht der globalen Zeit des Slave abweicht und ungültige Korrekturaktivität (bezüglich Rate und/oder Offset) notwendig wird, soll das CCLR-Signal gesetzt werden und der Protokollfehlerautomat soll sich in den Rot-Zustand bewegen.
Da die Master-CC die Zeitsteuerung des gesamten Clusters durch ihren Referenzrahmen steuert, soll keine Fehlerbehandlungsaktivität bezüglich CCFC während des Normalbetriebs die Master-CC beeinflussen (siehe das Kapitel „Taktsynchronisation"). Die Fehlerbehandlung des Master-Knotens soll nur durch das CCLR-Signal beeinflußt werden, wenn externe Taktsynchronisation angewandt wird. Die externen Raten- und/oder Offsetkorrekturwerte können zu einem Grenzverstoß der Raten- und Offsetkorrekturwerte führen (siehe das Kapitel „Taktsynchronisation").
In Tabelle 31 sind die Übergänge für den statischen, den gemischten und den dynamischen Mediumzugriffsmodus zusammengefaßt.
Tabelle 31: Fehlerverwaltung – Automatenübergänge für den zeitgetriggerten verteilten Protokollmodus und den zeitgetriggerten mastergesteuerten Protokollmodus
72 zeigt ein Fehlerverwaltungs-Zustandsübergangsdiagramm für den zeitgetriggerten verteilten Protokollmodus und den zeitgetriggerten mastergesteuerten Protokollmodus.
Fehlerbehandlung für Protokollbetrieb im byteflight-Protokollmodus
Dieser Abschnitt beschreibt den zentralen Fehlerbehandlungsmechnismus für den byteflight-Modus.
Jedes Mal, wenn der Host den „Clear-Befehl" gibt, während sich die CC im Konfigurationszustand befindet, wird der Protokollfehlerzustand auf Grün gesetzt. Gemäß der Definition in der byteflight-Spezifikation (siehe M. Peller, J. Berwanger und R. Greissbach, byteflight Specification, Version 0.5, BMW Corporation 1999, verfügbar bei http://www.byteflight.com), ist der Empfang eines SOC immer der Trigger zum Starten eines neuen Kommunikationszyklus und die CC beginnt den Betrieb (Protokollherauffahrphase beendet).
Wenn ein Kommunikationszyklus immer noch abläuft und ein SOC empfangen wird (SOC vor gdCycleMin), muß ein neuer Kommunikationszyklus gestartet werden (der Master hat das SOC gesendet und muß deshalb von allen Knoten akzeptiert werden). Die CC bleibt in dem Grün-Zustand.
Wenn ein Kommunikationszyklus bereits beendet ist und das nächste SOC fehlt (gdCycleMax ist vergangen), startet die CC so lange keinen neuen Kommunikationszyklus bis das SOC detektiert wird. Innerhalb dieser Zeit bleibt die CC passiv (Gelb-Zustand).
Wenn anstelle eines SOC ein ILLPIF detektiert wird (zwischen gdCycleMin und gdCycleMax) oder sogar während eines ablaufenden Kommunikationszyklus, tritt die CC in den Gelb-Zustand ein. Die Detektion eines SOC bewirkt, daß die CC sowieso zu den Grün-Zustand wechselt.
Tabelle 32 faßt die Übergänge für den byteflight-Modus zusammen.
Tabelle 32: Fehlerverwaltungs-Automatenübergänge für den byteflight-Protokollmodus
73 zeigt ein Fehlerverwaltungs-Zustandsübergangsdiagramm für den byteflight-Protokollmodus.
Protokollfehlerzustandssignal
Der Host soll die Möglichkeit haben, zu jeder Zeit den aktuellen Protokollfehlerzustand zu lesen (PESS, Bereich [grün, gelb, rot]).
Es soll möglich sein, während der Konfiguration der CC zu definieren, daß eine Änderung innerhalb von PESS ein Trigger für ein Interrupt des Hosts ist.
Steuerungshostschnittstelle
Einführung
Zweck und Umfang
Der Zweck dieses Kapitels ist die Beschreibung der konzeptuellen Struktur und der erforderlichen Funktionen und Eigenschaften der Steuerungshostschnittstelle, die den Steuer- und Datenfluß zwischen dem Hostprozessor und der FlexRay-Steuerungsprotokoll-Engine abwickelt.
Der Umfang dieses Kapitels reicht von der Hostprozessorschnittstelle bis zu der Protokoll-Engine-Schnittstelle. FlexRay-Protokollfunktionen werden nicht beschrieben.
Definitionen, Kürzel und Abkürzungen
Dieses Kapitel und das folgende Kapitel enthalten eine Anzahl von Anforderung, aber auch Einführungen, Anmerkungen, Erläuterungen usw. Alle Anforderungen werden in dem folgenden Format dokumentiert:
Anforderung 1 <Text für Anforderung 1>
Text in einem anderen Format stellt keine Anforderung dar und ist deshalb nicht Gegenstand einer Konformitätsprüfung.
CHI-Elemente – sind die sieben Elemente der CHI: Hostprozessorschnittstelle, Steuerdatenbehandlung, Statusdatenbehandlung, Nachrichtendatenbehandlung, Konfigurationsdatenbehandlung, CHI-Dienste, Protokoll-Engine-Schnittstelle
Konfigurationsdaten – dienen zum Programmieren einer FlexRay-Kommunikationssteuerung, um mit anderen FlexRay-Steuerungen zu kommunizieren. Konfigurationsdaten haben eine konstante Auswirkung auf das Verhalten der Protokollimplementierung während NormalOperation, sofern sie nicht vom Host geändert werden. Diese Eigenschaft unterscheidet die Konfigurationsdaten von den Steuerdaten, die während Normal Operation nur eine zeitliche Auswirkung besitzen. Außerdem ist der Hostprozessor die einzige Quelle für Konfigurationsdaten.
Steuerungszustand – dies ist die Übermenge von Protokollzustand und anderen Zuständen der Steuerung, die nicht durch den Protokollautomaten bestimmt werden (z.B. HardReset-Zustand, Konfiguration, Standby usw.)
Interrupt – ist ein durch eine FlexRay-Steuerung getriggertes Ereignis, das durch eine spezielle Kommunikationsverbindung zu dem Hostprozessor übermittelt wird, um anzuzeigen, daß eine spezifische Bedingung in der FlexRay-Steuerung wahrgeworden ist. Man beachte, daß Interrupts durch den CHI-Element-Host-Interrupt-Dienst erzeugt werden, aber seine Übermittlung zu dem Hostprozessor durch die CHI-Element-Status-Datenbehandlung gesteuert wird.
Nachrichtenspeicher – ist Speicher, der Informationen enthält, die in einem empfangenen Rahmen oder in einem Rahmen, der übertragen wurde oder werden wird, enthalten sind.
Nachrichtenstatusspeicher – ist Speicher, der Statusinformationen über einen empfangenen oder übertragenen Rahmen enthält.
Nachrichtensteuerfeld – ist ein Feld, mit dem der Host die Benutzung eines Nachrichtenspeichers steuern kann.
Nachrichtendaten – ist eine Teilmenge der in einem FlexRay-Rahmen enthaltenen Daten. Sie enthält nicht FrameID oder FrameCRC. Sie enthalten die folgenden Daten: ReservedBits, NMIndicationBit, PayloadLength, HeaderCRC, CycleCount, FData[0 .. 254].
NormalOperation – ist der Zustand, in dem die Steuerung an der Clusterkommunikation teilnehmen bzw. diese einleiten kann, indem Rahmen empfangen oder gesendet werden. Dieser Zustand enthält den Nur-Horch-Modus.
Statusdaten – sind alle Arten von Daten, die die Steuerung ohne Interaktion mit dem Host durch Empfangen von Informationen aus der physikalischen Schicht von FlexRay oder dem Buswächter oder durch steuerungsinterne Mechanismen bestimmt.
Schlitzkanal-Tupel – Bestimmen die Zuteilung von Übertragungsbandbreite auf einem spezifischen Kanal und einen Schlitz für die Übertragung in dem statischen Segment. Dies ist notwendig, weil sich zwei Steuerungen einen einzigen Schlitz teilen können – einen für jeden Kanal.
Datenblöcke – sind Mengen von Datenbyte, die zusammengehören, nämlich fNMVector, fData, fFrameID, fHeaderCRC, vStatusVector, vInterruptStatusVector
Statischer Rahmen – ist ein Rahmen mit fFrameID kleiner oder gleich gNumberOfStaticSlots
Dynamischer Rahmen – ist ein Rahmen mit fFrameID größer als gNumberOfStaticSlots
Anwendungsanforderungen – eine Menge von Anforderungen, die durch eine konkrete Anwendung oder eine Gruppe ähnlicher Anwendungen bestimmt werden
CC-Konfigurationszustand – ein Zustand, in dem der Host die FlexRay-Steuerung konfigurieren kann. In diesem Zustand sind weder Senden noch Empfangen möglich.
Dieser Zustand wird erst dann verlassen, wenn der Host explizit von der FlexRay-Steuerung anfordert, ihn zu verlassen.
HardReset-Zustand – der Zustand, in den automatisch durch die FlexRay-Steuerung eingetreten wird, nachdem die Stromversorgung eingeschaltet wurde, oder nach Aktivierung eines speziellen Hard-Rücksetz-Triggers. Nach Initialisierung von Registern und Speichern mit Vorgabewerten geht die FlexRay-Steuerung automatisch in den CC-Konfigurationszustand über.
Steuerungszustand – ist die Kombination des Protokollzustands mit allen Zuständen von parallel in einer Steuerungsimplementierung arbeitenden Automaten.
Passiv-Zustand – ein Zustand, in dem die FlexRay-Steuerung keine Daten sendet, aber weiter Daten empfängt. Außerdem führt sie weiter die Taktsynchronisation durch.
Freeze-Zustand – ein Zustand, in dem die FlexRay-Steuerung weder Daten sendet noch empfängt, die Taktsynchronisation wird gestoppt und alle für den Host durch die CHI zugängliche Daten bleiben konstant, so lange der Host nicht selbst eine Änderung durchführt.
Übersicht über die CHI
Konzeptuelle Architektur
Die Steuerungshostschnittstelle (CHI) verwaltet den Daten- und Steuerfluß zwischen dem Hostprozessor und der FlexRay-Protokoll-Engine.
Konzeptuell besteht die CHI aus sieben CHI-Bestandteilen. Diese sind die Hostprozessorschnittstelle und die Protokoll-Engine-Schnittstelle, die vier Datenbehandlungseinheiten – Statusdatenbehandlung, Steuerdatenbehandlung, Nachrichtendatenbehandlung und Konfigurationsdatenbehandlung, sowie die CHI-Dienste. Man beachte, daß die Hardwarearchitektur einer Steuerungsimplementierung von dieser konzeptuellen Architektur recht verschieden sein kann.
74 zeigt die konzeptuelle Architektur der Steuerungshostschnittstelle und ihrer sieben Komponenten. Die Komponenten werden in den Abschnitten „Hostprozessorschnittstelle" bis „Protokoll-Engine-Schnittstelle" und in dem Abschnitt „CHI-Dienste" beschrieben.
Hostprozessorschnittstelle
Die Hostprozessorschnittstelle gibt dem Hostprozessor Steuermittel und gibt ihm Zugang zu in den vier CHI-Datenbehandlungseinheiten gehaltenen Daten. Im allgemeinen setzt FlexRay keine spezielle Art und Weise der Realisierung dieser Schnittstelle durch. Sie kann auf verschiedene Weisen realisiert werden, zum Beispiel als ein paralleler Prozessorbus oder als eine serielle Kommunikationsverbindung, wie zum Beispiel eine SPI.
Konfigurationsdatenbehandlung
Die Konfigurationsdatenbehandlungseinheit enthält die Funktionen und Speicher, die bzw. der erforderlich sind bzw. ist, um die auf die Kommunikationssteuerung bezogenen Konfigurationsdaten zu behandeln und zu speichern. Die durch den Hostprozessor geschriebenen Konfigurationsdaten werden dazu verwendet, alle von der Protokoll-Engine benötigten Konfigurationsparameter abzuleiten. Die Protokoll-Engine muß von diesem CHI-Element bereitgestellte Protokollparameter benutzen. Die Konfigurationsdatenbehandlungseinheit kann außerdem Integritätsprüfungen der Konfigurationsdaten durchführen.
FlexRay unterscheidet zwischen zwei Teilmengen von Konfigurationsdaten:
Konstant-Konfigurationsdaten – können nur verändert werden, während sich das FlexRay-Protokoll in dem CC-Konfigurationszustand befindet; bleiben während NormalOperation konstant. Die Möglichkeit des Hosts, diese Daten zu modifizieren, wird gesperrt, so lange Senden und/oder Empfangen auf mindestens einem Kommunikationskanal freigegeben ist.
Variable Konfigurationsdaten – müssen vom Host in dem CC-Konfigurationszustand gesetzt werden, so lange sie nicht durch die FlexRay-Steuerung mit gültigen Vorgabewerten initialisiert werden. Diese Daten können vom Host zu einem beliebigen Zeitpunkt modifiziert werden, wenn nicht die Hard-Rücksetzbedingung gegeben ist, z.B. auch wenn NormalOperation aktiv ist.
Man beachte, daß Konfigurationsdaten während NormalOperation eine konstante Auswirkung auf das Verhalten der Protokollimplementierung haben, sofern es nicht durch den Host geändert wird. Diese Eigenschaft unterscheidet konstante sowie variable Konfigurationsdaten von Steuerdaten, die während NormalOperation nur eine zeitliche Auswirkung haben. Darüber hinaus ist der Hostprozessor die einzige Quelle für Konfigurationsdaten, es können aber auch Steuerdaten durch die Protokoll-Engine beeinflußt werden (z.B. Interrupt-Anzeiger werden durch die Protokoll-Engine gesetzt, aber durch den Host zurückgesetzt).
Steuerdatenbehandlung
Dieses CHI-Element verarbeitet Steuerbefehle aus dem Hostprozessor. Dieses CHI-Element behandelt außerdem Steuerbefehle für andere CHI-Elemente, z.B. für CHI-Dienste.
Statusdatenbehandlung
Dieses CHI-Element sammelt Statusdaten aus der Protokoll-Engine und CHI-Diensten, verarbeitet sie und führt sie auf Anfrage dem Hostprozessor zu. Es behandelt Statusdaten von Nachrichten. Es übermittelt durch den Host-Interruptdienst getriggerte Interrupt-Anforderungen zu der Hostprozessorschnittstelle. Es enthält Speicher zum Speichern von Statusdaten.
Nachrichtendatenbehandlung
Dieses CHI-Element transferiert Nachrichtendaten und führt sie der Hostprozessorschnittstelle und auch der Protokoll-Engine-Schnittstelle zu. Es enthält Speicher zum Speichern von Nachrichtendaten.
Daten einer Nachricht zugeordneter Speicher wird als Nachrichtenpuffer bezeichnet. Ein Nachrichtenpuffer, der zum Speichern von Daten für zu sendende Rahmen konfiguriert ist, wird als Sendepuffer bezeichnet. Ein Nachrichtenpuffer, der zum Speichern von Daten für empfangene Rahmen konfiguriert ist, wird als ein Empfangspuffer bezeichnet.
Man beachte, daß dieses CHI-Element keine Statusdaten von Nachrichten behandelt.
Anforderung 1: Die FlexRay-Steuerung darf den Inhalt eines Sendepuffers weder während Normal Operation noch während des Konfigurationszustands modifizieren. Man beachte, daß die Protokoll-Engine das Stopfmuster an dem Nutzsignalteil von zu sendenden Rahmen anhängen kann, die mehr Nutzsignaldaten enthalten, als in dem entsprechenden Sendepuffer gespeichert werden können. Hierdurch wird der Inhalt des Sendepuffers nicht modifiziert.
Protokoll-Engine-Schnittstelle
Die Protokoll-Engine-Schnittstelle stellt der Protokoll-Engine ein Mittel zur Steuerung zur Verfügung und gibt ihr Zugang zu in den vier CHI-Datenbehandlungseinheiten gehaltenen Daten. Außerdem erlaubt sie der Protokoll-Engine, mit den CHI-Diensten zusammenzuarbeiten. Diese Schnittstelle ist dem Host nicht sichtbar.
Anforderung 2: Die Protokoll-Engine-Schnittstelle soll atomische Datenleseoperationen bereitstellen, so daß, sobald eine Leseoperation eingeleitet ist, garantiert wird, daß die transferierten Daten nicht geändert werden, bis die Leseoperation abgeschlossen ist.
Anforderung 3: Die Protokoll-Engine-Schnittstelle soll atomische Datenschreiboperationen bereitstellen, so daß während einer Schreiboperation in eine Speicherzelle eines CHI-Elements kein anderes CHI-Element einen unstimmigen Wert aus dieser Speicherzelle lesen oder in sie schreiben kann.
Man beachte, daß die vorherigen beiden Anforderungen notwendig, aber nicht hinreichend sind. Weitere Nachrichtendatenbehandlungsanforderungen sind weiter unten angegeben.
CHI-Zustände
75 zeigt verschiedene Zustände der Steuerungshostschnittstelle (CHI).
CHI-Status-Übergangstrigger (Übergänge W1 und W5 werden in Tabelle 13 beschrieben):
vConfigure in {TRUE, FALSE}
vWakeUp in {TRUE, FALSE}
vNormalOperation in {TRUE, FALSE}
vFreeze in {TRUE, FALSE}
vStandby in {TRUE, FALSE}
CHI-Zustandsbeschreibung:
HardReset-Zustand: Erreicht, nachdem das harte Rücksetzen der Steuerung getriggert wurde. Initialisiert die Steuerung mit einem Vorgabezustand.
Konfigurationszustand: Versetzt Protokoll-Engine in den Konfigurierzustand. Erlaubt dem Hostprozessor, Konfigurationsdaten zu ändern. Setzt alle CHI-Zustandsübergangstrigger auf FALSE.
WakeUp-Zustand: Setzt vWakeup auf FALSE. Versetzt Protokoll-Engine in den WakeUpListen-Zustand. Die Protokoll-Engine kann zum WakeUpSend-Zustand übergehen. Zustandsübergänge in den Konfigurierzustand werden in dem Kapitel „Aufwecken, Herauffahren und Reintegration" beschrieben.
NormalOperation-Zustand: Setzt den Trigger vNormalOperation auf FALSE. Initialisiert beim Eintritt interne Zustände der Steuerung gemäß Konfiguration, triggert dann Herauffahren in Protokoll-Engine. Man beachte, daß dieser Zustand alle Protokollzustände enthält, in denen die Protokoll-Engine über den FlexRay-Bus Interaktion mit anderen FlexRay-Knoten aufweist. Protokollzustandsänderungen können in diesem Zustand angefordert werden, z.B. kann von der Protokoll-Engine angefordert werden, in den Passiv-Zustand überzugehen, um sich auf weitere Zustandsübergänge (z.B. Herunterfahren, Standby usw.) vorzubereiten.
Standby-Zustand: Setzt den Trigger vStandby auf FALSE. Versetzt die Steuerung in einen Low-Power-Modus. Die minimale erforderliche Funktionalität besteht darin, daß CHI in der Lage ist, zu erkennen, wann der Host den Trigger vConfigure setzt.
Freeze-Zustand: Setzt den Trigger vFreeze auf FALSE. Stoppt jede Interaktion der Protokoll-Engine mit anderen FlexRay-Knoten. Alle Protokollparameter, einschließlich des vollständigen Protokollzustands, werden eingefroren. Dieser Modus erlaubt es dem Hostprozessor, Diagnose durchzuführen.
CHI-Dienste
76 zeigt verschiedene Interaktionen von CHI-Diensten mit CHI-Elementen. CHI-Dienste erhalten Daten aus der Protokoll-Engine über empfangene und gesendete Kommunikationselemente sowie über den Protokoll- und Fehlerstatus. Sie können Daten benutzen, die in der Status-, der Steuer-, der Nachrichten- oder in der Konfigurationsschnittstelle gespeichert sind.
CHI-Dienste können sich auf Daten auswirken, die in der Status-, der Steuer- oder der Nachrichtenschnittstelle gespeichert sind. Sie können sich nicht auf in der Konfigurationsschnittstelle gespeicherte Daten auswirken.
CHI-Dienste beeinflussen nicht den Betrieb der Protokoll-Engine, weder direkt noch indirekt durch eines der Status-, Steuer- oder Nachrichtendatenbehandlungselemente.
Allgemeine Anforderungen
Anforderung 4: Es soll sichergestellt werden, daß der gleichzeitige Betrieb von CHI-Elementen keine Blockaden verursachen kann.
Anforderung 5: Im Fall eines gleichzeitigen Zugriffs verschiedener CHI-Elemente auf gemeinsam benutzte CHI-Elemente soll die Hostprozessorschnittstelle und die Protokoll-Engine-Schnittstelle gegenüber anderen CHI-Elementen Priorität haben.
Anforderung 6: Im Fall eines gleichzeitigen Zugriffs der Hostprozessorschnittstelle und der Protokoll-Engine-Schnittstelle auf gemeinsam benutzte CHI-Elemente soll die Protokoll-Engine-Schnittstelle Priorität haben. Eine Ausnahme ist Anforderung 7 (Rationale: notwendig zur Sicherstellung der Rechtzeitigkeit aller Protokoll-Engine-Operationen).
Anforderung 7: Falls der Hostprozessor einen Protokollzustandswechsel zu FreezeState oder zu ConfigurationState durch RequestStateChange anfordert, hat er Priorität gegenüber der Protokoll-Engine-Schnittstelle.
Anforderung 8: Die Datenbandbreite der Kommunikation innerhalb der CHI soll schnell genug sein, um auf jedem ihrer Kanäle während NormalOperation der Protokoll-Engine 100% Busausnutzung zu unterstützen. Man beachte, daß diese Anforderung nur die interne Kommunikation der CHI betrifft, so daß sie nicht durch Leistungsbegrenzungen der implementierten Hostprozessorschnittstelle betroffen ist.
Annahmen und Abhängigkeiten
Alle Annahmen und Abhängigkeiten werden dort dokumentiert, wo sie gelten. Es bestehen keine zusätzlichen allgemeinen Annahmen oder Abhängigkeiten.
Hostprozessorschnittstelle
Die folgende Menge von Anforderungen muß von jeder Instanziierung der Hostprozessorschnittstelle erfüllt werden.
Anforderung 9: Die Hostprozessorschnittstelle soll eine atomische Datenleseoperation aus Speicherzellen bereitstellen, dergestalt, daß, nachdem der Host eine Leseoperation einleitet, garantiert wird, daß sich die transferierten Daten nicht ändern, bis die Leseoperation abgeschlossen ist.
Anforderung 10: Die Hostprozessorschnittstelle soll eine atomische Datenschreiboperation bereitstellen, dergestalt, daß während einer Hostprozessor-Schreiboperation in eine Speicherzelle eines CHI-Elements kein anderes CHI-Element einen unstimmigen Wert aus dieser Speicherzelle lesen kann.
Man beachte, daß die vorherigen beiden Anforderungen für stimmigen Datenzugriff notwendig, aber nicht immer hinreichend sind, z.B. sind für Nachrichtenpufferzugriff weitere Mechanismen notwendig (siehe den Abschnitt „Nachrichtendatenbehandlungsinteraktion").
Anforderung 11: Die Hostprozessorschnittstelle soll mindestens ein fest zugeordnetes Interrupt-Signal bereitstellen.
Anforderung 12: Die Hostprozessorschnittstelle soll eine Interrupt-Anforderung an den Hostprozessor über das Interruptsignal immer dann triggern, wenn es durch die Statusdatenbehandlung angefordert wird.
Außerdem ist es möglich, eine FlexRay-Kommunikationssteuerung mit mehreren Hostprozessorschnittstellen auszustatten. Wenn eine FlexRay-Steuerungsimplementierung mehrere Instanzen von Hostprozessorschnittstellen (z.B. einen parallelen Bus und eine serielle Kommunikationsverbindung oder verschiedene mehrere parallele Busse) unterstützt, dann gelten die beiden folgenden zusätzlichen Anforderungen:
Anforderung 13: Es soll ein Mechanismus bereitgestellt werden, der die Auswahl von genau einer Hostprozessorschnittstelleninstanz erlaubt, bevor die Kommunikation zwischen FlexRay-Steuerung und Hostprozessor beginnt.
Anforderung 14: Eine Änderung dieser Auswahl soll nur durch Versetzen der FlexRay-Steuerung in den HardReset-Zustand effektiv werden. Wenn sich die Auswahl während anderer Zustände ändert (mit Ausnahme des Zustands PowerOff oder des Zustands Standby), darf sie nicht zu einer Änderung der Hostprozessorschnittstelle führen.
Konfigurationsdatenbehandlungsinteraktion
Beziehung zwischen Konfigurationsdaten und Protokollparametern
In einer FlexRay-Steuerung bestehen die Konfigurationsdaten gewöhnlich aus einer Menge von Registern und Speichern. Es besteht jedoch nicht unbedingt eine eindeutige Abbildung zwischen dieser Menge und den von ihr bestimmten Protokollparametern. Dies ist der Fall, weil es Protokollparameter gibt, die aus anderen Protokollparametern abgeleitet werden können. Außerdem kann eine FlexRay-Steuerung Parameter in einer anderen Repräsentation, als später spezifiziert, erfordern (Beispiel:
pSamplePeriod [ns] = gdBit [ns]/pSamplesPerBit)).
Konfigurationsdatenbehandlungsanforderungen
Die Interaktion mit der Konfigurationsdatenbehandlung muß die folgenden Anforderungen erfüllen
Anforderung 15: Konfigurationsdaten sollen nicht durch die FlexRay-Steuerung verändert werden, außer als Ergebnis der Aktivierung eines Hard-Rücksetz-Triggers oder nachdem Strom angelegt wurde.
Es wird angenommen, daß der Host auf jeden Fall Mittel zur Bestimmung besitzt, ob ein Mechanismus, wie zum Beispiel „HardReset", modifizierte Konfigurationsdaten aufweist. Außerdem soll unter keinen Umständen jemals ein Protokollmechanismus irgendwelche Konfigurationsdaten ändern.
Anforderung 16: Nach Aktivierung des Hard-Rücksetzens oder nach dem Einschalten sollen die Konfigurationsdaten durch Konfigurationsdatenbehandlung mit Vorgabekonfigurationswerten initialisiert werden, wodurch sichergestellt wird, daß die FlexRay-Steuerung keine Daten auf dem FlexRay-Bus sendet. Wenn der Hostprozessor einen Zustandswechsel zu NormalOperation anfordert, ohne irgendwelche Konfigurationsdaten zu ändern, dürfen keine Daten unabhängig von dem resultierenden Protokollzustand auf dem FlexRay-Bus gesendet werden. Rationale: Dabei handelt es sich um eine Fail-Silence-Anforderung für den Fall eines Fehlers, wodurch ein hartes Rücksetzen oder ein Herauffahren verursacht wird, wobei der Host keinerlei Konfigurationsdaten schreiben würde.
Anforderung 17: Konfigurationsdaten sollen so gekennzeichnet werden, daß alle Protokollparameter unzweideutig bestimmt sind.
Anforderung 18: Konfigurationsdaten sollen so gekennzeichnet werden, daß alle Protokollparameter mit mindestens der später angegebenen Auflösung bestimmt werden. Die Auflösungen und Einheiten aller Konfigurationsdaten sollen derartig sein, daß all diese Auflösung für alle gültigen Konfigurationen erzielt wird.
Anforderung 19: Es soll sichergestellt werden, daß die FlexRay-Steuerung niemals mehr als einen sync-Rahmen pro Kommunikationszyklus sendet, auch wenn der Host versucht hat, die FlexRay-Steuerung dafür zu konfigurieren. Die FlexRay-Steuerung soll spezielle Maßnahmen verwenden, um dies zu verhindern.
Anforderung 20: Mindestens die folgenden Parameter sollen durch konstante Konfigurationsdaten bestimmt werden:

1. Alle Cluster-Konstanten (dadurch werden mehrere Parameter abgedeckt, z.B. gdStartup, gStartupNoise, usw.)
2. Alle Knotenkonstanten (dadurch werden mehrere Parameter abgedeckt, z.B. pdWakeupPattern usw.)
3. Zeitsteuerungsparameter
4. Falls pSyncNode gleich TRUE, der Wert von pSyncSlot
5. Rahmenkennungen, Übertragungskanäle und Zykluszählerfilter aller statischen Rahmen, die übertragen werden können (man beachte, daß dies nur Konfigurationsdaten betrifft und bestimmt, welche Schlitz-Kanal-Tupel für die Übertragung durch eine FlexRay-Steuerung zugeteilt werden. Daraus folgt nicht, daß Nachrichtenspeicher in dem Nachrichtendatenbehandlungselement für jedes Schlitz-Kanal-Tupel vorgesehen ist).
6. Physische Schicht (optisch oder elektrisch), Codierung

Anforderung 21: Der Host soll Schreibzugriff auf konstante Konfigurationsdaten nur dann haben, wenn sich das Protokoll in dem CC-Konfigurationszustand befindet. Wenn sich das Protokoll in irgendeinem anderen Zustand befindet, sollen diese Daten vor Zugriff durch den Hostprozessor schreibgeschützt werden.
Anforderung 22: Es sollen entsprechende Mechanismen vorgesehen werden, die Änderungen von variablen Konfigurationsdaten während Normal Operation unterstützen. Diese Mechanismen sollen sicherstellen, daß die zu verändernde Teilmenge von Konfigurationsdaten nicht während der Dauer des Änderungsprozesses von der Protokoll-Engine benutzt wird. Indirekt erfordert dies einen Verriegelungsmechanismus für alle Fälle, in denen keine atomische Änderung möglich ist.
Anforderung 23: Variable Konfigurationsdaten sollen in Konfigurationsteilmengen von Konfigurationsdaten, die zusammengehören, so geclustert werden, daß eine Aktualisierung einer Teilmenge während oder nach der Aktualisierung keine unstimmige Konfiguration verursachen kann.
Anforderung 24: Mindestens die folgenden Parameter werden durch variable Konfigurationsdaten bestimmt

1. Rahmenkennungen von Nachrichten in dem dynamischen Segment
2. vColdStartInhibit

Anforderung 25: Die folgenden Parameter sollen entweder durch variable Konfigurationsdaten oder durch konstante Konfigurationsdaten bestimmt werden, aber nicht beides.

1. (zur Zeit kein Parameter für diese Kategorie identifiziert)

Anforderung 26: Der Host soll in allen Steuerungszuständen mit Ausnahme des Zustands PowerDown und des Zustands HardReset Lesezugriff zu allen Konfigurationsdaten besitzen.
Steuerungsdatenbehandlungsinteraktion
Steuerung von Protokollparametern
Anforderung 27: Es sollen Mittel vorgesehen werden, um die folgenden Protokollparameter während des Zustands Normaloperation zu bestimmen und zu ändern:

1. vOffsetCorrectionExtern, vRateCorrectionExtern
2. vBgsmErrorAck (kann verworfen werden, wenn ein verriegelter Parameter für BgsmError verwendet wird)
3. vColdStartInhibit

Steuerbefehle für den Hostprozessor
Anforderung 28: Mindestens die folgenden Steuerbefehle sollen für den Hostprozessor bereitgestellt werden: (TBD-Wortformulierung)

1. ChangeControllerState (behandelt Übermenge von Änderungen an Protokoll-Engine-Schnittstelle – vielleicht besser ChangeControllerState, um auch Nicht-Protokollzustandsänderungen abzudecken)
2. EnableInterrupt (<interrupt_type>)
3. DisableInterrupt (<interrupt_type>)
4. EnableCHIService (<CHI_service>, <CHI_service_feature>)
5. DisableCHIService (<CHI_service>, <CHI_service_feature>)

Tabelle 33: ChangeControllerState
Tabelle 34: Auswirkung einer Steuerungszustandsänderung auf Protokoll-Engine und CHI (maximale Latenz ist vor dem Eintritt in den Zustand unter der Annahme, daß der angeforderte Übergang legal ist; die maximale Latenz in dem Steuerungszustand Normaloperation hängt von der Leistungsfähigkeit der Steuerungsimplementierung ab; dabei wird vorausgesetzt, daß die steuerungsinternen Zustände abhängig von der Konfiguration initialisiert werden müssen).
Man beachte, daß Tabelle 34 nicht Gegenstand einer Konformitätsprüfung ist. Spezifische FlexRay-Steuerungsimplementierungen können abweichende maximale Latenzwerte aufweisen. Diese Werte müssen jedoch bestimmt, dokumentiert und konstant sein.
Tabelle 35: EnableInterrupt/DisableInterrupt (weitere Interrupt-Typen können unterstützt werden, sind aber nicht erforderlich)
Tabelle 36: EnableCHIService/DisableCHIService
Statusdatenbehandlungsinteraktion
Statusdaten werden aus steuerungsinternen Zustandsvariablen abgeleitet, die als ihre Quelle dienen. Es gibt zwei Arten von Statusdaten:

1. Frei-Statusanzeiger, die ihren Wert immer dann ändern können, wenn sich ihre Quellenwerte ändern. Wenn es nicht anders erwähnt wird, sind alle nachfolgenden Anzeiger Frei-Statusanzeiger.
2. Verriegelte Statusanzeiger, die ihren Wert ändern können, wenn eine spezifische Bedingung des Quellenwerts für eine kurze Zeit erfüllt ist (in der Regel im Bereich von einem bis mehreren Steuerungstaktzyklen), und die diesen Wert behalten, auch wenn die Bedingung nicht mehr erfüllt ist.

Bestimmte Statusanzeiger können in einem Superzustand kombiniert werden, der möglicherweise nicht durch eine atomische Hostoperation zugänglich ist. Für Statusanzeiger, die zu groß sind, um durch eine atomische Leseoperation zugänglich zu sein, gilt gleiches. Es können spezielle Statusstimmigkeitsmechanismen erforderlich sein, um sicherzustellen, daß sie stimmig durch den Hostprozessor mit einer nicht-atomischen Sequenz von Leseoperationen gelesen werden können.
Anforderung 29: Freie Statusanzeiger sollen für den Hostprozessor nur zu lesen sein. Versuche durch den Hostprozessor freie Statusanzeiger zu überschreiben, beeinflussen diese nicht.
Anforderung 30: Verriegelte Statusanzeiger sollen gesetzt werden, wenn ein spezifischer interner Zustand erreicht wird, sie sollen nicht auf Anforderung des Hostprozessors gesetzt werden.
Anforderung 31: Verriegelte Statusanzeiger sollen nur bei Anforderung durch den Hostprozessor zurückgesetzt werden, sie sollen nicht bei Änderung des benachbarten internen Zustandes zurückgesetzt werden.
Anforderung 32: Alle Statusanzeiger sollen beim Austritt aus dem CC-Konfigurationszustand zurückgesetzt werden.
Anforderung 33: Der aktuelle Steuerungszustand soll auf Leseanforderung des Hosts bereitgestellt werden.
Anforderung 34: Der aktuelle Fehlerstatusvektor soll auf Leseanforderung des Hosts bereitgestellt werden.
Anforderung 35: Es soll ein Mechanismus vorgesehen werden, der es dem Host ermöglicht, den Protokollzustand stimmig zu lesen.
Anforderung 36: Es soll ein Mechanismus vorgesehen werden, der es dem Host ermöglicht, den Fehlerstatusvektor stimmig zu lesen.
Anforderung 37: Wenn der Host-Interrupt-Dienst einen Host-Interrupt erzeugt und wenn dieser Interrupt freigegeben ist, soll er der Hostprozessorschnittstelle angezeigt werden.
Anforderung 38: Interrupts, die gesperrt sind, sollen nicht zu der Hostprozessorschnittstelle übermittelt werden.
Anforderung 39: Die Statusdatenbehandlung soll einen Mechanismus bereitstellen, mit dem der Hostprozessor selektiv jeden Interrupt freigeben und sperren kann.
Anforderung 40: Für jeden Empfangspuffer soll ein fest zugeordneter Statusanzeiger vorgesehen werden, um anzuzeigen, wann ein Empfangspuffer durch die PutFrame-Schnittstelle aktualisiert wird.
Anforderung 41: Die folgenden Protokollvariablen sollen bereitgestellt werden (Mengen von Statusdaten, die zusammengehören, werden in einem Punkt kombiniert):

1. vColdStartCount
2. vValidSyncCount
3. vCycle, vMacrotick, vCurrentSlot, vErrorHandlingLevel
4. Ergebnisse von BG-Überwachungsprüfungen
5. Ergebnisse des Medium-Zugriffstests

Anforderung 42: Die folgenden Ergebnisse des Taktsynchronisationsalgorithmus, der während NIT des Zyklus n durchgeführt wird, sollen im Verlauf von Zyklus n + 1 und Zyklus n + 2 bereitgestellt werden

1. vOffsetCorrection, vRateCorrection
2. Ein Anzeiger für unmögliche Raten- oder Offsetkorrekturtermberechnung
3. Anzahl der für die letzte Taktkorrekturtermberechnung verwendeten sync-Rahmenpaare

Anforderung 43: Es soll ein Herauffahrstatusvektor bereitgestellt werden, der folgendes enthält:

1. Einen Anzeiger, der nur gesetzt wird, wenn vColdStartMax gleich gColdStartMax ist
2. Ein Anzeiger, daß Plausibilitätsprüfung versagt hat
3. Ein Anzeiger, daß über den Kaltstartweg in normalen Zustand eingetreten wurde
4. Ein Anzeiger, daß aufgrund des Ablaufens von pStartupNoise in den Kaltstartweg eingetreten wurde

Anforderung 44: Für jeden Empfangspuffer soll ein entsprechender Statusvektor bereitgestellt werden, der mindestens die folgenden Statusinformationen enthält

1. Semantisch gültiger Rahmen empfangen
2. Syntaktisch korrekter Nullrahmen empfangen
3. Syntaktisch korrekter sync-Rahmen empfangen
4. Leerer Schlitz – Leerlauf wurde im Verlauf des gesamten Schlitzes auf dem Empfangskanal detektiert
5. Zykluszähler-Nichtübereinstimmung erkannt
6. Längennichtübereinstimmung erkannt (PayloadLength in dem statischen Rahmen stimmt nicht mit gPayloadLengthStatic überein)

Anforderung 45: Der Statusvektor für einen Empfangspuffer soll immer dann aktualisiert werden, wenn dieser Puffer durch den Nachrichtenauswahlprozeß ausgewählt wird. (Man beachte, daß dies nicht zur Folge hat, daß die Daten des Empfangspuffers auch aktualisiert werden.)
Anforderung 46: Bei Erkennung eines Aufweckmusters soll ein verriegelter Anzeiger gesetzt werden, das heißt, wenn das Flag vWakeupSymbolReceived gesetzt wird.
Anforderung 47: Wenn vWakeupFrameHeaderReceived gesetzt wird, soll ein verriegelter Anzeiger gesetzt werden.
Anforderung 48: Wenn das Flag vWakeupFailed gesetzt ist, soll ein verriegelter Anzeiger gesetzt werden.
Anforderung 49: Wenn das Flag vWakeupComplete gesetzt ist, soll ein verriegelter Anzeiger gesetzt werden.
Nachrichtendatenbehandlungsinteraktion
Der Host kann ein Schlitz-Kanal-Tupel zur Übertragung buchen. Man beachte, daß das Buchen keine weiteren Bedingungen wie Subskription (z.B. Zykluszählerfilterung) umfaßt, obwohl Sendepuffer zusätzliche Bedingungen unterstützen können, um zu bestimmen, welche Daten während der gebuchten Schlitz-Kanal-Tupel übertragen werden. Das Buchen eines spezifischen Schlitz-Kanals muß in dem Cluster eindeutig sein. Der Host kann außerdem ein Schlitz-Kanal-Tupel für Empfang subskribieren. Abhängig von der FlexRay-Steuerungsimplementierung kann die Subskription weitere Bedingungen umfassen, z.B. einen übereinstimmenden Zykluszähler usw. Identische Subskriptionen können in demselben Cluster koexistieren.
Anforderung 50: Damit der Host den Inhalt von Nachrichtenpuffern manipulieren kann, sollen mindestens die folgenden Schnittstellenfunktionen unterstützt werden (weitere Schnittstellenfunktionen können unterstützt werden, um Effizienz zu verbessern):
GetMessage
PutMessage
Tabelle 37: GetMessage
Tabelle 38: PutMessage
Anforderung 51: Der Host soll Lesezugriff auf alle Nachrichtenpuffer mit gültigen Nachrichtendaten besitzen. Die Nachrichtendaten dürfen nicht gültig sein, während die Protokoll-Engine auf den Nachrichtenpuffer zugreift.
Anforderung 52: Für jeden Empfangsnachrichtenpuffer soll, wenn er Daten eines semantisch gültigen Rahmens enthält, ein Anzeiger vorgesehen werden.
Anforderung 53: Nach Aktivierung des Hard-Rücksetzens oder nach dem Einschalten soll dieser Anzeiger durch die Nachrichtendatenbehandlung initialisiert werden, um anzuzeigen, daß der Empfangsnachrichtenpuffer nicht Daten eines semantisch gültigen Rahmens enthält.
Anforderung 54: Es soll ein Mechanismus vorgesehen werden, der Zugriff auf stimmige Nachrichtendaten durch den Host sicherstellt. Das heißt, daß, während der Host auf Daten eines Nachrichtenpuffers zugreift, diese Daten nicht durch andere CHI-Elemente verändert werden sollen.
Anforderung 55: Sendepuffer sollen die folgenden Daten enthalten: ReservedBits, NMIndicationBit, FrameID, PayloadLength, HeaderCRC, CycleCount, FData[0..pMaxPayloadLength-1]
Anforderung 56: Im Fall einer Anforderung durch die GetFrame-Schnittstelle durch die Protokoll-Engine soll cPaddingValue in FData[pMaxPayloadLength..PayloadLength-1] gesetzt werden, falls pMaxPayloadLength kleiner als PayloadLength und <frame_data_found> TRUE ist. Das Stopfmerkmal soll nur durch Steuerungsimplementierungen unterstützt werden, die Nachrichtenpuffer aufweisen, die nicht 254 Byte Nutzsignaldaten speichern können. Es soll möglich sein, das Stopfen durch einen speziellen Konfigurationsparameter zu sperren.
Anforderung 57: Es soll ein Mechanismus vorgesehen werden, durch den der Host Sendepuffer für Ablaufplanung zur Übertragung übergeben kann.
Anforderung 58: Der Host soll nur dann Schreibzugriff auf Sendepuffer besitzen, wenn sie nicht für eine Übertragung eingeteilt sind.
Anforderung 59: Der Host soll keinen Schreibzugriff auf Empfangspuffer besitzen.
Anforderung 60: Jeder Empfangspuffer soll mit den folgenden Nachrichtendaten ausgestattet werden: ReservedBits, NMIndicationBit, NullFrameIndicationBit, SyncBit, FrameID, PayloadLength, HeaderCRC, CycleCount, FData[0..pMaxPayloadLength-1], Empfangskanal. (Anmerkung: Wenn der Empfangskanal durch Konfigurationsdaten bestimmt wird, muß der Empfangskanal nicht in dem Empfangspuffer gespeichert werden).
Anforderung 61: Empfangspuffer sollen von der Protokoll-Engine nur mit Daten semantisch gültiger Rahmen aktualisiert werden.
Anforderung 62: Die Nachrichtendaten gültiger Rahmen, die in einem Empfangspuffer gespeichert werden, sollen durch GetMessage in derselben Sequenz zugänglich sein, in der die Rahmen als gültig erkannt werden.
Anforderung 63: Für im Schlitz x empfangene gültige statische Rahmen soll der frühestmögliche Zugriff auf die Nachrichtendaten durch GetMessage innerhalb von 1 μs nach dem Ende von Schlitz x stattfinden, wenn sie subskribiert sind.
Anforderung 64: Für gültige dynamische Rahmen, die mit Minischlitz x enden, soll der frühestmögliche Zugriff auf die Nachrichtendaten durch GetMessage innerhalb von 1 μs nach dem Ende des Minischlitzes x erfolgen, wenn sie subskribiert sind.
Protokoll-Engine-Schnittstelle Kommunikation mit der Protokoll-Engine
Tabelle 39: Protokoll-Engine-Schnittstelle
Die Protokoll-Engine-Schnittstelle ist in eine Steuer- und eine Datenschnittstelle aufgeteilt. Die Steuerschnittstelle dient zum Anfordern einer Protokollzustandsänderung in der Protokoll-Engine (siehe unten). Die Datenschnittstelle liefert Dienste, die durch die Protokoll-Engine angefordert werden können. Diese Dienste werden später beschrieben.
RequestStateChange
Tabelle 40: RequestStateChange
Funktionsweise: Die Zustandsänderungsanforderung wird zu der Protokoll-Engine propagiert. Es liegt im Verantwortungsbereich der Protokoll-Engine, entsprechend zu reagieren, z.B. bestimmte Zustandsänderungsanforderungen müssen sofort befolgt werden, während es bei anderen möglich ist, einen ablaufenden Sende- oder Empfangsprozeß abzuschließen.
Die Protokoll-Engine bestätigt die Anforderung durch Verwendung der PutProtocolState-Schnittstelle zum Melden ihres Übergangs zu dem angeforderten Zustand.
PutFrame
Tabelle 41: PutFrame
Funktionsweise: Die von der Protokoll-Engine bereitgestellten Daten werden zu allen CHI-Diensten und zur Nachrichtendatenbehandlung weitergeleitet. Diese CHI-Elemente treten miteinander in Wechselwirkung, um folgendes zu bestimmen:
ob die bereitgestellten Daten in dem Nachrichtendatenspeicher gespeichert werden sollen – wenn ja, Bestimmen der Speicherstelle
ob der Empfang genau dieser Nachricht dem Hostprozessor angezeigt werden soll (z.B. über Interrupt) wenn pMaxPayloadLength kleiner als PayloadLength ist, Verwerfen von FData[pMaxPayloadLength...PayloadLength-1]; aber nicht PayloadLength ändern (folglich kann ein Nachrichtenpuffer weniger FrameData als durch PayloadLength angegeben enthalten)
ob und welche Statusdaten zu aktualisieren sind
ob Steuerdaten betroffen werden (z.B. Rücksetzen eines durch den Host gesetzten Anzeigers, wenn er eine spezifische Nachricht gelesen hat)
ob im Fall einer Fehleranzeige vielleicht ein Interrupt getriggert werden soll anderes abhängig von weiteren CHI-Diensten
GetFrame
Tabelle 42: GetFrame
Funktionsweise: die Protokoll-Engine fordert Rahmendaten durch diese Schnittstelle für jeden Schlitz und Kanal an.
Wenn kein Schlitz-Kanal-Tupel zur Übertragung in den Konfigurationsdaten enthalten ist, soll der Wert von <slot_is_booked> FALSE sein und die Protokoll-Engine versucht, einen Rahmen zu empfangen.
Wenn ein Schlitz-Kanal-Tupel zur Übertragung in den Konfigurationsdaten enthalten ist, soll <slot_is_booked> jedoch TRUE sein und es wird ein Rahmen oder Nullrahmen übertragen, wenn <frame_data_found> TRUE bzw. FALSE ist.
Falls sowohl <slot_is_booked> als auch <frame_data_found> TRUE sind, stellt die Nachrichtendatenbehandlung sicher, daß cPaddingValue in Fdata[pMaxPayloadLenth..PayloadLength-1] gesetzt ist, falls pMaxPayloadLength kleiner als PayloadLength ist.
PutProtocolState
Tabelle 43: PutProtocolState
Funktionsweise: Diese Schnittstelle wird von der Protokoll-Engine immer dann benutzt, wenn sich der Protokollzustand ändert. Diese Informationen werden allen CHI-Diensten, der Statusdatenbehandlung zugeführt, die entsprechend in Wechselwirkung treten, um folgendes durchzuführen:
Bestimmen, ob die Zustandsänderung in den Statusdaten widergespiegelt werden muß
Bestimmen, ob Steuerdaten aktualisiert werden müssen (z.B. Rücksetzen/Setzen spezifischer Zustandsänderung oder Übertragungsanforderungen
Prüfen, ob Interrupt-Anforderungen getriggert werden sollen
PutErrorStatusVector
Tabelle 44: PutErrorSatusVector
GetConfigurationData
Tabelle 45: GetConfigurationData
Funktionsweise: Immer dann, wenn die Protokoll-Engine einen spezifischen Protokollparameter benötigt, verwendet sie diese Schnittstelle zum Anfordern des Werts. Das Konfigurationsdatenbehandlungselement kann ihn direkt aus den Konfigurationsdaten extrahieren oder den Wert aus den Konfigurationsdaten berechnen.
Statusdatenbehandlungsinteraktion
Die Protokoll-Engine muß alle für CHI erforderlichen Anzeiger bereitstellen, die nicht von einem der CHI-Elemente erzeugt werden können.
Nachrichtendatenbehandlungsinteraktion
Anforderung 65: Es soll ein Mechanismus vorgesehen werden, der Zugriff auf stimmige Nachrichtendaten durch die Protokoll-Engine sicherstellt. Das heißt, daß, während die Protokoll-Engine auf Daten eines Nachrichtenpuffers zugreift, dürfen sie nicht durch andere CHI-Elemente verändert werden
Steuerungs-Hostschnittstellendienste
Übersicht
Die Steuerungs-Hostschnittstellendienste (CHI-Dienste) stellen dem Hostprozessor verschiedene Dienste bereit. Als Konzept können die CHI-Dienste als eine zusätzliche Dienstschicht angesehen werden, die auf den durch die Protokoll-Engine bereitgestellten Protokolldiensten aufbaut.
CHI-Dienste höherer Komplexität, wie etwa der Nachrichtenfilterungsdienst, fallen in verschiedenen CHI-Dienstmerkmalen auseinander. Spezifische CHI-Dienstmerkmale können andere CHI-Dienstmerkmale als Vorbedingung erfordern.
Jeder CHI-Dienst wird entweder als erforderlich oder optional klassifiziert. Alle Dienste, d.h. sowohl die als erforderlich klassifizierten als auch die als optional klassifizierten, müssen sich jedoch an die in diesem Kapitel definierten Anforderungen halten. Zusätzlich kann ein CHI-Dienst eine Menge verschiedener Teildienste enthalten. Jedes CHI-Dienstmerkmal wird seinerseits ebenfalls entweder als erforderlich oder optional klassifiziert. Ein CHI-Dienst ist erforderlich, wenn er mindestens ein erforderliches CHI-Dienstmerkmal bereitstellt.
Ein CHI-Dienst kann auch auf anderen CHI-Diensten aufbauen. In diesem Fall ist ein CHI-Dienst erforderlich, wenn er eine Abhängigkeit für mindestens einen anderen CHI-Dienst bereitstellt.
Die CHI-Dienste treten durch die vier Datenbehandlungseinheiten mit dem Hostprozessor in Wechselwirkung. Auf diese Weise wird dem Hostprozessor der Dienststatus angezeigt und der Hostprozessor kann den Dienst steuern und konfigurieren. Zusätzlich kann ein CHI-Dienst auf Nachrichtendaten reagieren, die entweder durch den Hostprozessor oder die Protokoll-Engine der Nachrichtendatenbehandlungseinheit zugeführt werden.
Zur Zeit sind acht CHI-Dienste definiert. Tabelle 46 zeigt die acht CHI-Dienste zusammen mit etwaigen potentiellen CHI-Dienstmerkmalen und die jeweiligen Klassifizierungen.
Die Protokoll-Engine-Schnittstelle propagiert alle durch die Protokoll-Engine bereitgestellten Daten über PutFrame, PutProtocolStatus, PutErrorStatusVector zu allen CHI-Diensten. Auf diese Daten hin führen die CHI-Dienste alle notwendigen Operationen und Prüfungen zur Erfüllung ihrer Funktionen durch.
Tabelle 46: Erforderliche und optionale CHI-Dienste und -Merkmale
Nachrichtenfilterungsdienst
Der Nachrichtenfilterungsdienst liefert ein Mittel zum Abrufen von Nachrichtendaten aus Nachrichtenpuffern zur Übertragung, jeweils zum Speichern empfangener Nachrichtendaten in Nachrichtenpuffern, abhängig von spezifischen Filterbedingungen. Um diesen Dienst bereitzustellen, greift die Protokoll-Engine über einen Nachrichtenfilter auf jeden Nachrichtenpuffer zu. Jedes Nachrichtenfilter kann auf eine oder mehrere Filterbedingungen zugreifen. Das Nachrichtenfilter prüft, ob die Nachrichtendaten die definierten Filterbedingungen erfüllen oder nicht. Nachrichtenfilter können mit Empfangspuffern und auch mit Sendepuffern verwendet werden.
Zur Zeit sind Filterungsbedingungen für die Rahmen-ID, die Kanal-ID, den Zykluszähler und die Nachrichten-ID definiert. Die folgenden sendepufferbezogenen Anforderungen müssen unabhängig von der Filterungsbedingung erfüllt sein:
Anforderung 66: Im Fall eines Sendepuffers soll der Pufferinhalt der Protokoll-Engine zur Übertragung nur dann zur Verfügung gestellt werden, wenn der Sendepuffer Nachrichtendaten enthält, die alle jeweiligen Filterbedingungen erfüllen.
Anforderung 67: Wenn mehrere Filter übereinstimmen, soll ein Sendepuffer auf deterministische Weise ausgewählt werden.
Die folgenden empfangspufferbezogenen Anforderungen müssen unabhängig von der Filterungsbedingung erfüllt werden:
Anforderung 68: Im Fall eines Empfangspuffers sollen die in einem gültigen Rahmen enthaltenen Nachrichtendaten nur dann in dem Empfangspuffer gespeichert werden, wenn die in dem Rahmen enthaltenen Daten alle jeweiligen Filterbedingungen erfüllen.
Anforderung 69: Wenn mehrere Filter übereinstimmen, soll ein Empfangspuffer unabhängig von dem Protokoll zustand und den Nachrichtendaten auf eine deterministische Weise ausgewählt werden.
Rahmen-ID-Filterung
Innerhalb der Rahmen-ID-Filterung wird die Filterbedingung auf die Rahmen-ID angewandt. Rahmen-ID-Filterung gilt für Sende- und Empfangspuffer.
Anforderung 70: Für Sendepuffer soll das Filter den jeweiligen Schlitzzähler betrachten, für den Daten durch die Protokoll-Engine angefordert werden, für Empfangspuffer soll das Filter die in dem gültigen Rahmen enthaltene Rahmen-ID betrachten. Der Schlitzzähler ist immer mit Kanal-ID assoziiert. Ein Schlitz wird dem Knoten für einen spezifischen Kanal zugewiesen, wenn sowohl das Rahmen-ID-Filter als auch das Kanal-ID-Filter für einen Puffer übereinstimmen.
Anforderung 71: Jedes Filter soll mittels eines Rahmen-ID-Filterwerts und einer optionalen Rahmen-ID-Filtermaske konfiguriert werden.
Anforderung 72: Jede Rahmen-ID-Filterkonfiguration soll durch statische Konfigurationsdaten bestimmt sein.
Anforderung 73: Das Rahmen-ID-Filter soll übereinstimmen, wenn die betrachtete Rahmen-ID gleich dem Rahmen-ID-Filterwert ist. Wenn das Filter eine Rahmen-ID-Filtermaske hält, soll die Rahmen-ID-Filtermaske vor dem Vergleich mit dem Rahmen-ID-Filterwert auf die betrachtete Rahmen-ID angewandt werden.
Kanalfilterung
Innerhalb der Kanalfilterung wird die Filterbedingung auf den Kanal angewandt. Kanalfilterung gilt für Sende- und Empfangspuffer.
Anforderung 74: Für Sendepuffer soll das Filter den Kanal betrachten, für den Daten durch die Protokoll-Engine angefordert werden, für Empfangspuffer soll das Filter den Kanal betrachten, auf dem der gültige Rahmen empfangen wurde. Die Kanal-ID ist immer mit einem Schlitzzähler assoziiert. Ein Schlitz wird dem Knoten für einen spezifischen Kanal zugewiesen, wenn sowohl das Rahmen-ID-Filter als auch das Kanal-ID-Filter für einen Puffer übereinstimmen.
Anforderung 75: Jedes Filter soll mittels einer Kanalfiltermenge konfigurierbar sein, die gleich einer der folgenden Mengen ist: {A}, {B}, {A, B}, {}.
Anforderung 76: Jede Kanalfilterkonfiguration soll durch statisch oder durch variable Konfigurationsdaten bestimmt sein.
Anforderung 77: Das Kanalfilter soll übereinstimmen, wenn der betrachtete Kanal in der Kanlafiltermenge enthalten ist.
Nachrichten-ID-Filterung
Innerhalb der Nachrichten-ID-Filterung wird die Filterbedingung auf die Nachrichten-ID angewandt. Nachrichten-ID-Filterung gilt nur für Empfangspuffer.
Anforderung 78: Das Filter soll die in dem gültigen Rahmen enthaltene Nachrichten-ID nur dann betrachten, wenn die Nutzsignallänge des Rahmens mindestens ein Wort enthält. Wenn die Nutzsignallänge 0 Wörter enthält, soll das Filter nicht übereinstimmen.
Anforderung 79: Jedes Filter soll mittels eines Nachrichten-ID-Filterwerts und einer Nachrichten-ID-Filtermaske konfigurierbar sein.
Anforderung 80: Das Nachrichten-ID-Filter soll übereinstimmen, wenn das Ergebnis nach der Anwendung der betrachteten Nachrichten-ID auf die Nachrichten-ID-Filtermaske gleich dem Nachrichten-ID-Filterwert ist.
Anforderung 81: Die Nachrichten-ID-Filterkonfiguration soll durch konstante oder durch variable Konfigurationsdaten bestimmt sein.
Zykluszählerfilterung
Innerhalb der Zykluszählwertfilterung wird die Filterbedingung auf den Zykluszählwert angewandt. Die Zykluszählwertfilterung gilt für Sende- und Empfangspuffer.
Anforderung 82: Für Sendepuffer soll das Filter den Zykluszähler betrachten, für den Daten durch die Protokoll-Engine angefordert werden, für Empfangspuffer soll das Filter den in dem gültigen Rahmen enthaltenen Zykluszählwert betrachten.
Anforderung 83: Jedes Filter soll mittels einer Zyklusmenge konfigurierbar sein. Eine Zyklusmenge C_b,c enthält alle Zykluszahlen C_b,c = {x|x = (b + n·2^c} modulo (cCycleMax + 1}; n in N₀; 0 <= b < 2^c <= cCycleMax + 1} mit
b: Basiszyklus
c: Zykluswiederholung
b, c in N₀
Anforderung 84: Die Zykluszählerfilterkonfiguration soll durch konstante oder variable Konfigurationsdaten bestimmt werden.
Anforderung 85: Ein Zykluszählerfilter soll übereinstimmen, wenn der betrachtete Zykluszählwert in der Zyklusmenge C_b,c enthalten ist.
Zulässige Filterungskombinationen
Anforderung 86: Sendepuffer sollen entweder eine Kombination von Rahmen-ID-Filterung und Kanal-ID-Filterung oder eine Kombination von Rahmen-ID-Filterung, Kanal-ID-Filterung und Zykluszählerfilterung erlauben.
Anforderung 87: Empfangspuffer sollen entweder eine Kombination von Rahmen-ID-Filterung und Kanal-ID-Filterung oder eine Kombination von Rahmen-ID-Filterung, Kanal-ID-Filterung und Zykluszählerfilterung oder eine Kombination von Nachrichten-ID-Filterung und Kanal-ID-Filterung oder eine Kombination von Nachrichten-ID-Filterung, Kanal-ID-Filterung und Zykluszählerfilterung erlauben. Rahmen-ID-Filterung und Nachrichten-ID-Filterung schließen sich für Empfangspuffer gegenseitig aus, d.h. es ist nicht möglich, gleichzeitig Rahmen-ID-Filterung und Nachrichten-ID-Filterung zu aktivieren.
Anforderung 88: Wenn die Konfiguration eines Filters während der Laufzeit geändert wird, während sich das Protokoll in dem Zustand Normaloperation befindet, soll das Filter so lange nicht übereinstimmen, bis die Konfiguration abgeschlossen ist.
Nachrichten-FIFO-Dienst
Beschreibung
Nachrichten-FIFOs dienen zum Speichern und Empfangen von Rahmeninhalten gemäß dem Prinzip „first-in, first-out". Zur Zeit sind nur Empfangs-FIFOs definiert.
Der Empfangs-FIFO speichert den Inhalt aus durch die Protokoll-Engine empfangenen gültigen Rahmen. Der Hostprozessor braucht die Nachrichten aus dem FIFO durch Lesen aus dem FIFO auf.
Interaktion mit der Protokoll-Engine-Schnittstelle
Empfangs-FIFO: Speichert die bereitgestellten Nachrichtendaten bei einer PutFrame-Anforderung, wenn kein fest zugeordneter Nachrichtenpuffer gefunden werden kann und der Rahmen durch optionale Filter angenommen wird.
Interaktion mit der Konfigurationsdatenbehandlung
Nachrichtenfilter können für ausgewählte spezifische Nachrichten zur Speicherung in Empfangs-FIFOs in statischen oder variablen Konfigurationsdaten konfiguriert werden. Diese Nachrichtenfilter können spezifische Rahmen-IDs oder Nachrichten-IDs annehmen oder zurückweisen.
Interaktion mit der Statusdatenbehandlung
Anforderung 89: Es soll ein boolscher Frei-Anzeiger bereitgestellt werden, um zu bestimmen, ob Nachrichten in dem FIFO gespeichert sind.
Anforderung 90: Es soll ein boolscher Verriegelt-Anzeiger bereitgestellt werden, um zu bestimmen, ob der FIFO aufgrund eines Überlaufs Nachrichtendaten verloren hat.
Interaktion mit der Nachrichtendatenbehandlung
Nachrichten-FIFOs dienen zum Speichern/Abrufen von Nachrichtendaten nur dann, wenn kein fest zugeordneter Nachrichtenpuffer für eine spezifische Nachricht konfiguriert ist und der Rahmen durch optionale Filter angenommen wird.
Anforderung 91: Die Nachrichtensequenz aus einem spezifischen Kanal, die in einem Empfangs-FIFO gespeichert wird, soll mit der Sequenz dieser Nachricht auf dem FlexRay-Bus identisch sein.
Man beachte, daß, wenn mehr als ein Kanal in den Empfangs-FIFO gespeist wird, die Nachrichtensequenz in dem FIFO mit der Nachrichtensequenz für jeden Kanal einzeln vereinbar ist, jedoch keine spezifische Speicherungssequenz zwischen Nachrichten verschiedener Kanäle definiert ist.
Netzwerkverwaltungsdienst
Beschreibung
Der Netzwerkverwaltungsdienst liefert Mittel für den Host zum Behandeln des Netzwerkvektors, der in einem FlexRay-Rahmen übertragen werden kann.
Einschränkungen
Der Netzwerkverwaltungsdienst ist nur während NormalOperation funktionsfähig.
Interaktion mit der Protokoll-Engine-Schnittstelle
Dieser CHI-Dienst scannt jeden Rahmen, der durch die Protokoll-Engine durch PutFrame bereitgestellt wird. Wenn NMIndicationBit gesetzt ist, wird er aktiv.
Interaktion mit der Konfigurationsdatenbehandlung
Anforderung 92: Der Wert von NMIndBit in zu übertragenden Rahmen soll durch statische Konfigurationsdaten bestimmt werden.
Interaktion mit der Steuerdatenbehandlung
Anforderung 93: Wenn eine spezifische Steuerungsimplementierung Interrupt-Triggerung an spezifischen NM-Ereignissen unterstützt, soll es für den Host möglich sein, diese Interrupts zu sperren.
Interaktion mit der Statusdatenbehandlung
Anforderung 94: Ein Vektor der Netzwerkverwaltung (NM) vGloNMVec von gNetworkManagementVectorLength Byte Länge soll während Normaloperation bereitgestellt werden.
Es ist nicht erforderlich, daß vGloNMVecis in anderen Betriebsarten als Normal Operation gültig ist.
Es wird der Anwendung überlasen, nur eine Teilmenge der gNetworkManagementVectorLength Byte für NM zu benutzen. In diesem Fall liegt es an der Anwendung, die unbenutzten Bit zu maskieren.
Anforderung 95: Ein aktualisiertes vGloNMVecs soll am Anfang jedes Kommunikationszyklus bereitgestellt werden.
Anforderung 96: Der Wert eines am Anfang eines Kommunikationszyklus bereitgestellten vGloNMVec soll gleich einer logischen OR-Operation aller in korrekt empfangenen Rahmen enthaltenen fLocNMVec mit gesetztem NM-Anzeigebit während des vorherigen Kommunikationszyklus sein. Man beachte, daß die Extraktion von fLocNMVec von der Benutzung von Nachrichtenkennungen abhängt. Dies kann für verschiedene Rahmen verschieden sein. Wenn Nachrichten-ID-Filterung in dem Nachrichtenpuffer zum Speichern eines empfangenen Rahmens gesperrt ist, werden die fData[0 .. 8] als fLocNMVec verwendet. Wenn Nachrichten-ID-Filterung freigegeben ist, wird fData[2 .. 10] als fLocNMVec benutzt. Man beachte, daß die logische OR-Verknüpfung auch für verschiedene fLocNMVec-Werte gilt, die auf den beiden Kanälen in demselben Schlitz empfangen werden. Am Anfang des ersten Kommunikatioszyklus in Normal Operation soll ein auf 0 initialisierter NM-Vektor bereitgestellt werden.
Anforderung 97: Es soll ein Mechanismus bereitgestellt werden, der entweder fGloNMVec auf stimmige Weise bereitstellt oder explizit oder implizit anzeigt, daß ein unstimmiges fGloNMVec durch den Host gelesen wurde.
Eine implizite Anzeige könnte der Zykluszählerwert des Kommunikationszyklus sein, aus dem der NM-Vektor erzeugt wurde. Der Host könnte diesen Wert lesen und speichern, den NM-Vektor lesen und verifizieren, ob der Zykluszählerwert mit dem gespeicherten Wert übereinstimmt. wenn diese Prüfung erfolglos bleibt, ist der gelesene NM-Vektor möglicherweise nicht stimmig. Wenn die Prüfung erfolgreich ist, ist der NM-Vektor stimmig. Dies gilt nur, wenn der Host weniger als 64 Zyklen zum Lesen des NM-Vektors benötigt, weil sich die Zykluszählerwerte nach 63 Zyklen wiederholen.
Anforderung 98: Wenn NMIndicationBit gesetzt ist, aber PayloadLength des Rahmens nicht groß genug ist, um den vollständigen NM-Vektor zu halten, soll ein Fehler angezeigt und fGloNMVec nicht verändert werden.
Anforderung 99: Wenn NMIndicationBit gesetzt und NullframeIndicationBit gesetzt ist, soll ein Fehler angezeigt und fGloNMVec nicht verändert werden
Interaktion mit der Nachrichtendatenbehandlung
Anforderung 100: Die Nachrichtenschnittstelle soll Mittel für den Hostprozessor bereitstellen, um die Werte des NM-Vektors (fLocNMVec) in zu übertragenden Rahmen zu bestimmen.
Für alle dem Host zugeführten empfangenen Rahmen soll die Nachrichtenschnittstelle außerdem die Werte von fNMIndBit und fLocNMVec bereitstellen. fNMIndBit und fLocNMVec repräsentieren die Werte für das NM-Anzeigebit und den NM-Vektor in dem (empfangenen) Rahmen.
Timer-Dienst
Beschreibung
Dieser Dienst ermöglicht die Synchronisation der Anwendung mit der globalen Zeit des FlexRay-Clusters. Timer können absolut sein (spezifischer Zyklus und Makrotick) oder relativ (zu der Zeit ihres Startens) und sie können sich wiederholende oder Single-Shot-Timer sein.
Interaktion mit der Protokoll-Engine-Schnittstelle
Timer-Ereignisse werden abhängig von den neusten Werten von vMacrotick und vCycle getriggert.
Interaktion mit der Konfigurationsdatenbehandlung
Anforderung 101: Timer-Ereignisse sollen in statischen oder variablen Konfigurationsdaten enthalten sein.
Anforderung 102: Ein Timer-Ereignis soll unzweideutig definiert werden, so daß die Zeit (Zykluszahl und Makrotick) der Aktivierung bestimmt werden kann.
Interaktion mit der Steuerdatenbehandlung
Timer sowie der Timer-Interrupt können während NormalOperation freigegeben oder gesperrt werden.
Interaktion mit der Statusdatenbehandlung
Anforderung 103: Ein fest zugeordneter Interrupt soll dem Hostprozessor zugeführt werden, der getriggert wird, wenn ein Timer abgelaufen ist.
Fehlersignalisierungsdienst
Interaktion mit der Steuerdatenbehandlung
Anforderung 104: Fehlersignalisierungsdaten sollen beim Austreten aus dem CC Konfigurationszustand zurückgesetzt werden.
Interaktion mit der Statusdatenbehandlung
Anforderung 105: Es soll ein Verriegelt-Statusanzeiger bereitgestellt werden, der gesetzt wird, wenn vOffsetCorrection die rote Region erreicht hat (vOffsetCorrection > gOffsetCorrectionOut).
Anforderung 106: Es soll ein Verriegelt-Statusanzeiger vorgesehen werden, der gesetzt. wird, wenn vBgsmError TRUE ist. Dieser Statusanzeiger soll zurückgesetzt werden, wenn vBgsmErrorAck gleich TRUE ist.
Anforderung 107: Es soll ein Verriegelt-Statusanzeiger bereitgestellt werden, der gesetzt wird, wenn während des Symbolfensters ein Mediumzugriff-Testsymbol (MTS) empfangen wurde
Symbolbehandlungsdienst
Beschreibung
Dieser Dienst ermöglich, zu steuern, welche Symbole während des Symbolfensters übertragen werden. Darüber hinaus liefert er Informationen an den Hostprozessor über das während des Symbolfensters empfangene Symbol. Dieser Dienst hat die folgenden Merkmale:

• Mediumzugriff-Testsymbolbehandlung – ist ein erforderliches Merkmal zur Durchführung der Mediumzugriff-Prüfung.
• Statussymbolbehandlung – ist ein optionales Merkmal zur Behandlung des Status-Normal-Symbols und des Status-Alarm-Symbols.

Interaktion mit der Protokoll-Engine-Schnittstelle
Der wert von vTXSymbol soll auf Anforderung durch die GetConfigurationData-Schnittstelle bereitgestellt werden, wenn das Argument „vTXSymbol" ist. (TBD – Beschreibung formalisieren und standardisieren)
Interaktion mit der Konfigurationsdatenbehandlung
Die Länge des Symbolfensters ist eine Clusterkonstante und wird deshalb durch statische Konfiguration bestimmt.
Interaktion mit der Steuerdatenbehandlung
Anforderung 108: Es sollen Mittel zur Steuerung des Werts von vTXSymbol vorgesehen werden.
Interaktion mit der Statusdatenbehandlung
Anforderung 109: Der Wert von vRXSymbol soll als Frei-Anzeiger der Hostprozessorschnittstelle zugeführt werden.
Host-Interrupt-Dienst
Beschreibung
Dieser Dienst prüft Bedingungen zur Erzeugung von Interrupt-Anforderungen sowie Bedingungen zum Rücksetzen dieser Anforderungen.
Interaktion mit der Protokoll-Engine-Schnittstelle
Abhängig von den Interrupts, die eine FlexRay-Steuerungsimplementierung unterstützt, kann dieser CHI-Dienst Bedingungen für die Interrupterzeugung oder -rücksetzung auf Daten hin prüfen, die durch PutFrame bereitgestellt werden, auf den Protokollzustand hin, der durch PutProtocolState bereitgestellt wird, und auf den Fehlerstatusvektor hin, der durch PutErrorStatusVector bereitgestellt wird.
Interaktion mit der Konfigurationsdatenbehandlung
Keine erforderlich.
Interaktion mit der Steuerdatenbehandlung
Anforderung 110: Es sollen Mittel vorgesehen werden, um die Datenbehandlung zu steuern, um jeden durch diesen Dienst erzeugten Interrupt selektiv freizugeben und zu sperren.
Interaktion mit der Statusdatenbehandlung
Anforderung 111: Dieser CHI-Dienst erzeugt auf Anforderung des Timer-Dienstes eine Timer-Interrupt-Anforderung.
Abhängig von den zusätzlichen Interrupts, die eine FlexRay-Steuerungsimplemetierung unterstützt, werden weitere Interrupt-Anforderungen erzeugt.
Interaktion mit der Nachrichtendatenbehandlung
Abhängig von den zusätzlichen Interrupts, die eine FlexRay-Steuerungsimplementierung beim Empfang oder Senden spezifischer Rahmen unterstützt.
Optischer Diagnosedienst
Beschreibung
Dieser Dienst liefert durch den optischen Sender/Empfänger bereitgestellte Informationen, die anzeigen, ob die optische Leistung unter einer gegebenen Schwelle liegt.
Interaktion mit der Protokoll-Engine-Schnittstelle
Anforderung 112: Es soll eine Schnittstellenfunktion PutOpticalDiagnosisFlags vorgesehen werden.
Tabelle 47: PutOpticalDiagnosisFlags
Interaktion mit der Statusdatenbehandlung
Anforderung 113: Für jeden Kanal wird ein Optische-Diagnose-Anzeiger vorgesehen.
Interaktion mit der Nachrichtendatenbehandlung
Abhängig von den zusätzlichen Interrupts, die eine FlexRay-Steuerungsimplementierung beim Empfang oder Senden spezifischer Rahmen unterstützt.
Bustreiberschnittstelle
Einführung
Dieses Kapitel beschreibt die Schnittstelle zu dem elektrischen FlexRay-Bustreiber (BDe). Diese Schnittstelle umfaßt drei Komponenten, die Schnittstelle zu der FlexRay-Kommunikationssteuerung (CC), die Schnittstelle zu dem FlexRay-Buswächter (BG) und die Schnittstelle zu dem Host. Eine Beschreibung der BDI-Funktionsweise findet sich in FlexRay Electrical Physical Layer Preliminary Functional Specification, v1.0, Philips Corporation, 2002, und in dem Kapitel „Anforderungen für Hardwarezustände".
Bustreiber – Kommunikationssteuerungsschnittstelle
Übersicht
Die Schnittstelle Bustreiber – Kommunikationssteuerung ist in 77 gezeigt. Die Schnittstelle zwischen dem BDe und der CC umfaßt drei digitale elektrische Signale, zwei, die aus der CC in den BDe eingegeben werden (mit den Bezeichnungen TxD und TxEN) und eines, das aus dem BDe an die CC ausgegeben wird (mit der Bezeichnung RxD).
Die folgende Beschreibung gilt, wenn sich der BDe in dem Modus BDe_Normal befindet.
TxEN ist eine Eingabe in den BDe aus der CC. Sie wird von der CC verwendet, um es dem BDe zu ermöglichen, den Zustand Data_0 oder Data_1 auf den Kanal zu steuern.

• Während die CC einen logischen HIGH-Zustand auf TxEN aufrechterhält, signalisiert der BDe Idle auf dem Kanal.
• während die CC einen logischen LOW-Zustand auf TxEN aufrechterhält, steuert der BDe Data_0 oder Data_1 auf dem Kanal (abhängig von der TxD-Eingabe, siehe unten), aber nur wenn es der BG gleichzeitig dem BDe erlaubt, dies zu tun (siehe unten). Wenn der BG dies nicht erlaubt, signalisiert der BDe weiter Idle auf dem Kanal.

TxD ist eine Eingabe in den BDe aus der CC, mit der die CC die tatsächliche Signalsequenz zur Übertragung auf den Kanal zu dem BDe transferiert. Diese Signalsequenz ist der zu übertragende Signalstrom. Mit einem logischen LOW-Zustand auf TxD steuert der BDe Data_0 und mit einem logischen HIGH-Zustand auf TxD steuert der BDe Data_1 auf den Kanal, wenn der BDe Erlaubnis von dem BG hat und über TxEn durch die CC freigegeben ist.
RxD ist eine Ausgabe des BDe an die CC, mit der der BDe die tatsächliche empfangene Signalsequenz zu der CC transferiert. Dies ist der empfangene Datenstrom. RxD wird auf einen logischen LOW-Zustand gesteuert, wenn der Kanal Data_0 signalisiert. Wenn der Kanal Idle oder Data_1 signalisiert, wird RxD auf einen logischen HIGH-Zustand gesteuert.
Wenn sich der BDe nicht in dem BDe Normal-Modus befindet, signalisiert er Idle auf den Kanal.
Schnittstelle Bustreiber – Buswächter
Übersicht
Die Schnittstelle Bustreiber – Buswächter ist in 78 gezeigt. Die Schnittstelle zwischen dem BDe und dem BG umfaßt zwei digitale elektrische Signale, eine Eingabe für den BDe (mit der Bezeichnung BGE) und eine Ausgabe von dem BDe (mit der Bezeichnung RxEN).
BGE ist eine Eingabe in dem BDe aus dem BG. Mit ihr erlaubt der BG es dem BDe, die Zustände Data_0 und Data_1 auf den Kanal zu steuern.

• Während die BG einen logischen LOW-Zustand auf BGE aufrechterhält, signalisiert der BDe Idle auf den Kanal.
• Während die BG einen logischen HIGH-Zustand auf BGE aufrechterhält, darf der BDe Data_0 oder Data_1 abhängig von der Eingabe TxD und TxEN (siehe oben) auf den Kanal steuern.

Die folgende Beschreibung ist gültig, wenn sich der BDe in dem BDe_Normal-Modus befindet.
RxEN ist eine Ausgabe des BDe an den BG, mit der der BDe anzeigt, ob sich der Kanal in dem Idle-Zustand befindet oder nicht. Während sich der Kanal in dem Idle-Zustand befindet, wird RxEN auf einen logischen HIGH-Zustand gesteuert.
Während der Kanal Data_0 oder Data_1 signalisiert, wird RxEN auf einen logischen LOW-Zustand gesteuert.
Wenn sich der BDe nicht in dem BDe_Normal-Modus befindet, sollen sich RxD und RxEN in einem logischen HIGH-Zustand befinden.
Schnittstelle Bustreiber – Host
Die Bustreiber-Host-Schnittstelle ist eine produktspezifischen Schnittstelle. Sie ermöglicht es dem Host, die Betriebsarten des BDe zu steuern und Fehlerbedingungen aus dem BDe zu lesen. Diese Schnittstelle muß außerdem die Weckquelle signalisieren (lokales Aufweckereignis oder Fernaufwecken über Aufwecksymbol auf den Bus).
Die Schnittstelle kann mit einer seriellen Kommunikationsschnittstelle (z.B. „SPI") oder durch Verwendung fest verdrahteter Signale (z.B. spezielle Anschlüsse für Betriebsartensteuerung und Fehlersignalisierung) realisiert werden.
Eine Beschreibung der BDe-Betriebsarten wird in dem Kapitel „Anforderungen für Hardwarezustände" gegeben.
Schnittstellensignalzeitsteuerung
BDe-Ausgangssignale: RxD und RxEN
Die erwartete Zeitsteuerung von RxD und RxEN ist in 79 abgebildet (Rahmen im statischen Teil des Kommunikationszyklus übertragen).
Die Übertragungsstartsequenz (TSS), die ein Knoten empfängt, kann kürzer als die ursprünglich gesendete TSS sein. Der Grund dafür besteht darin, daß aktive Sterne einen Teil der TSS abschneiden können. RxEN bleibt für die Dauer von MediaIdleDetectionTime auf dem logischen LOW-Zustand nach dem letzten übertragenen Bit. (Siehe das Kapitel „Codierung und Decodierung" für weitere Informationen über die TSS sowie das Dokument FlexRay Electrical Physical Layer Preliminary Functional Specification, v1.0, Philips Corporation, 2002, für die Auswirkung des Abschneidens)
Ein Knoten, der einen Rahmen überträgt, kann seine eigene Übertragung auf RxD zurücklesen, wenn der BDe Rückschleife bereitstellt. Falls das letzte Bit als Data_1 übertragen wurde (Rahmen im statischen und dynamischen Teil, Symbole: EIS, SNS oder SAS), kann nur der übertragende Knoten ein anderes Verhalten (in rot abgebildet) von RxD nach dem Ende seines eigenen Rahmens oder Symbols als alle anderen Empfänger in dem Netzwerk sehen. Dazu kommt es, wenn Gleichtaktdrosseln mit signifikanter Streuinduktivität verwendet werden.
Da die Symbole WU, CAS, MTS an Data_0 enden, ist die Situation in diesen Fällen etwas unterschiedlich. Das Verhalten von RxD und RxEN ist in 80 gezeigt.
Die Übertragungsstartsequenz (TSS), die ein Knoten empfängt, kann kürzer als die ursprünglich gesendete TSS sein (siehe oben), dieser Effekt könnte möglicherweise durch den Effekt des Vergrößerns des Symbols um MediaIdleDetectionTime nicht kompensiert werden. Der übertragende Knoten kann beim Zurücklegen seiner eigenen Übertragung das Verhalten sehen, das durch die gestrichelte rote Linie abgebildet ist, wenn Gleichtaktdrosseln mit signifikanter Streuinduktivität verwendet werden.
BDe-Eingangssignale: TxD und TxEN
Die erforderliche Zeitsteuerung von TxD und TxEN ist in 81 abgebildet.
Beim Start des ersten zu übertragenden Bit wird TxEN in den logischen LOW-Zustand umgeschaltet und am Ende des letzten Bit, das zu übertragen war, in den logischen HIGH-Zustand zurückgeführt. Es wird erwartet, daß Flanken in TxEN mit der ersten und letzten Flanke in dem TxD-Signal synchron sind.
Buswächterschnittstelle
Einführung
Dieses Kapitel deckt die Konformitätsanforderungen ab, die für die Schnittstelle zwischen den Funktionsblöcken der Kommunikationssteuerung (CC) und des dezentralisierten Buswächters (BG) gelten. Der dezentralisierte Buswächter schützt den Kommunikationskanal bzw. die Kommunikationskanäle vor nicht ordnungsgemäßen Übertragungen durch eine fehlerhafte oder falsch konfigurierte Kommunikationssteuerung, die versucht, außerhalb ihrer vorkonfigurierten Ablaufsteuerung zu senden. Der Buswächter besitzt unabhängige Kenntnis der Kommunikationsablaufsteuerung des Knotens und schränkt die Übertragung auf ausschließlich die Zeiten ein, die durch die Ablaufsteuerung erlaubt sind.
Dieses Kapitel spezifiziert die Schnittstelle zwischen dem Buswächter und der Kommunikationssteuerung und gibt eine Übersicht über das Buswächterablaufsteuerungsschema. Außerdem legt sie die Anforderungen bezüglich des Verhaltens von BG und CC in bezug auf die Schnittstellensignale zwischen BG und CC fest. Für eine ausführliche Funktionsspezifikation des Buswächters wird auf FlexRay Bus Guardian Preliminary Functional Specification, v1.2, Philips Corporation, 2002, verwiesen.
Der zweite Teil dieses Kapitels enthält eine Spezifikation des von der Kommunikationssteuerung bereitgestellten BG-Ablaufsteuerungsüberwachungsdienstes. Der Zweck dieses Dienstes ist die Überwachung der Buswächterablaufsteuerung und das Informieren des Hosts, wenn eine Nichtübereinstimmung zwischen der Kommunikationsablaufsteuerung von BG und CC erkannt wird.
Schnittstellensignale BG-CC
Tabelle 48 zeigt eine Liste der Buswächtereingaben und -ausgaben an der Schnittstelle zwischen dem Buswächter und der Kommunikationssteuerung. Das in 82 gezeigte Blockschaltbild beschreibt, wie Buswächter in einem zweikanaligen FlexRay-Knoten mit einer Kommunikationssteuerung verbunden sind. Man beachte, daß die Signale TxEN und BGE mit dem konkreten Kanal assoziiert sind. Für jeden Kanal muß es fest zugeordnete Signale TxEN und BGE geben (siehe die FlexRay-Anforderungsspezifikation, Req. 219 G: Der Buswächter darf nicht den Zugriff auf mehr als einen Kanal sperren, d.h. es ist ein Buswächter pro Kanal erforderlich). Zusätzlich zu den BG-CC-Schnittstellensignalen zeigt das Blockschaltbild außerdem das RxEN-Signal von dem Bustreiber, das für die lokale Auswertung der Mediumzugriffsprüfung erforderlich ist.
BG-CC-Schnittstellensignalübersicht
Tabelle 48: BG-CC-Schnittstellensignale (Datenrichtung DIR in Bezug auf den Buswächter. „I" repräsentiert eine Eingabe in den BG, „0" repräsentiert eine Ausgabe des BG).
BG-CC-Schnittstellensignalbeschreibung
MT
Das MT-Signal, das von der CC erzeugt wird, dient als Eintaktsignal für den BG-Scheduler. Die ansteigende Flanke des MT-Signals muß mit dem Start des internen lokal korrigierten Makrotick der CC synchronisiert sein. Die CC soll sicherstellen, daß etwaige interne Makrotickkorrekturen während desselben Makroticks in dem MT-Signal wiedergegeben werden, d.h. das MT-Signal ist eine genaue Repräsentation des internen lokal korrigierten Makroticktakts der CC).
BGT
Das BGT-Signal, das von der CC erzeugt wird, dient zur Überwachung der MT-Periode. Die BGT-Periode wird durch Taktkorrekturen nicht beeinflußt und hängt nur von der Frequenz des Kristalloszillators der CC und einem Frequenzteiler in der CC ab.
ARM
Das ARM-Signal wird von der CC erzeugt und zeigt dem BG den Start des Kommunikationszyklus an. Das ARM-Signal aus der CC wird so erzeugt, daß es mit dem MT-Signal synchron ist (ARM-Flanken sind mit der ansteigenden Flanke des MT-Signals synchronisiert). Die fallende Flanke des ARM-Signals definiert das ARM-Triggerereignis für die BG-Zyklussynchronisation. Nach dem Knotenherauffahren muß die BG-Ablaufsteuerung mit der CC-Ablaufsteuerung synchronisiert werden. Man erreicht dies mittels des ersten ARM-Triggerereignisses, das von dem BG nach dem Knotenherauffahren detektiert wird. Nachfolgende ARM-Triggerereignisse sind für die Zyklussynchronisation nicht erforderlich, aber für die Überwachung der konfigurierten Zykluslänge. Der BG prüft auf das regelmäßige Auftreten von ARM-Triggerereignissen am Start jedes Zyklus durch Zählen der Anzahl der MT-Perioden zwischen ARM-Triggerereignissen und Vergleichen des Ergebnisses mit der nachfolgend berechneten erwarteten BG-Zykluszeit.
BGE
Das BGE-Signal wird von dem Buswächter erzeugt und steuert Sendezugriff auf das Kommunikationsmedium. Jeder Sendezugriff auf das Medium soll so lange gesperrt sein, wie das BGE-Signal inaktiv ist (BGE = LOW). Das BGE-Signal wird auch als ein Eingangssignal, das zur Überwachung der BG-Ablaufsteuerung dient, der CC zugeführt. Es wird auf den nachfolgend beschriebenen BG-Ablaufsteuerungsüberwachungsdienst verwiesen.
TxEN
Das TxEN-Signal wird von der CC erzeugt und zeigt an, daß die CC gerade versucht, auf dem bestimmten Kanal zu senden. Dieses Signal soll von dem BG zur Überwachung der CC-Ablaufsteuerung ausgewertet werden. Der BG soll eine Ablaufsteuerungsnichtübereinstimmung detektieren, wenn das TxEN-Signal aktiv ist, während das BGE-Signal inaktiv ist (für Einzelheiten bezüglich durch den BG bereitgestellte Ablaufsteuerungsüberwachungsmerkmale wird auf die BG-Funktionsspezifikation verwiesen).
Buswächter-Ablaufsteuerungsschema
83 zeigt eine Übersicht über die Beziehung zwischen der CC-Ablaufsteuerung und der BG-Ablaufsteuerung auf dem Kommunikationssegmentniveau. Für jedes Segment der CC-Ablaufsteuerung soll ein entsprechendes Segment der BG-Ablaufsteuerung konfiguriert werden. Das statische Segment des BG und die BG-Watchdog-Sperrzeit sind obligatorische Teile der BG-Ablaufsteuerung. Das statische Segment des BG muß mindestens einen statischen Schlitz enthalten. Die minimale Länge für die BG-Watchdog-Sperrzeit beträgt 1 MT-Periode.
Teile der BG-Ablaufsteuerung, die zur Übertragung verwendet werden können, werden durch Lücken zwischen Schlitzen (ISG) getrennt. Dies gilt für statische Schlitze, das dynamische Segment des BG und das BG-Symbolfenster. Der BG soll die Übertragung einen Makrotick vor dem erwarteten Anfang einer Übertragung freigeben und sie einen Makrotick nach dem erwarteten Ende sperren. Man beachte, daß eine Mindestlänge der ISG von 2 Makroticks benötigt wird, um diese Bedingung zu erfüllen.
Die ISG enthält zwei optionale Elemente gdBGpreEnablePart und gdBGpostEnablePart. Die Synchronisation der BG-Ablaufsteuerung mit den CC-Aktionspunkten wird durch Konfiguration von gdBGpreEnablePart erzielt, während die Konfiguration gdBGpostEnablePart eine Vergrößerung der Sicherheitsreserve zwischen Übertragungen ermöglicht.
84 zeigt die BG-CC-Zeitsteuerung während des statischen Segments. Sendezugriff wird gdBGpreEnablePart Makroticks nach dem Anfang eines statischen Schlitzes freigegeben und bleibt für gdBGStaticSlot + 2 Makroticks freigegeben. Der statische Schlitz wird durch eine Periode von gdBGpostEnablePart Makroticks abgeschlossen, während der Übertragung durch den BG gesperrt wird.
Der BG-Kommunikationszyklusstart wird als der Anfang des statischen Schlitzes 1 definiert. Der BG soll annehmen, daß am BG-Zyklusstart die ARM-Triggerereignisse geschehen.
Am Anfang des dynamischen Segments müssen zwei mögliche Fälle unterschieden werden (siehe den Abschnitt „dynamisches Segment"). 85 zeigt die BG-CC-Zeitsteuerung einer Konfiguration mit gdActionPointOffset > gdMSActionPointOffset. In diesem Fall wird der Sendezugriff einen Makrotick vor dem Aktionspunkt in der CC freigegeben. 86 zeigt die BG-CC-Zeitsteuerung einer Konfiguration mit gdActionPointOffset ≤ gdMSActionPointOffset. In diesem Fall wird der Sendezugriff gdMSActionPointOffset – gdActionPointOffset + 1 Makroticks vor dem Aktionspunkt in der CC freigegeben.
Im allgemeinen wird der Sendezugriff gsBGpreEnablePart Makroticks nach dem Anfang des dynamischen Segments freigegeben, unabhängig von der Konfiguration von gdMSActionPointOffset, und bleibt für gdBGDynSegment + 2 Makroticks freigegeben.
87 zeigt die BG-CC-Zeitsteuerung am Ende des dynamischen Segments sowie während des BG-Symbolfensters und der BG-Watchdog-Sperrzeit (WDT). Während der BG-Watchdog-Sperrzeit wird die Überwachung der MT-Periode gesperrt. Dies erlaubt Taktoffsetkorrektur zur Verkürzung oder Verlängerung von Makroticks um einen Betrag, der die konfigurierten Grenzen der Makroticküberwachung überschreiten würde.
Der BG kann dann so konfiguriert werden, daß er Übertragung während des dynamischen BG-Segments bzw. des BG-Symbolfensters freigibt oder sperrt. Der Sendezugriff wird gdBGpreEnbablePart Makroticks nach dem Anfang des Symbolfensters freigegeben und bleibt für gdBGSymbolWindow + 2 Makroticks freigegeben. Der BG sperrt die Übertragung während der BG-Watchdog-Sperrzeit gdBGWatchdogDisable.
Der BG soll die Anwendung der Mediumzugriffsprüfung während des Symbolfensters unterstützen, d.h. zusätzlich zu dem Sperren des Sendezugriffs soll ein Sendeversuch durch die CC nicht als Ablaufsteuerungsverstoßfehler detektiert werden. Der Zweck der Mediumzugriffsprüfung besteht darin, zu prüfen, ob der BG die Übertragung erfolgreich sperrt. Der BG unterstützt die Anwendung der Mediumzugriffsprüfung, wenn Übertragung während des Symbolfensters gesperrt ist (pBGSymWinEnable = 0) und Mediumzugriffsprüfung freigegeben ist (pBGMatEnable = 1). Tabelle 49 beschreibt das konfigurierbare Verhalten des BG während des BG-Symbolfensters.
Tabelle 49: BG-Verhalten während des BG-Symbolfensters
Die Beziehung zwischen BG-Konfigurationsparametern und globalen Protokollparametern wird definiert durch:

• gdBGStaticSlot + ISG = gdStaticSlot
• gdBGDynSegment + ISG = gNumberOfMinislots·gdMinislot + (gdActionPointOffset – gdMSActionPointOffset)

Die obige Gleichung gilt nur für den Fall gNumberOfMinislots ! = 0; Der Term (gdActionPointOffset – gdMSActionPointOffset) gilt nur für den Fall gdActionPointOffset > gdMSActionPointOffset.

• gdBGSymbolWindow + ISG = gdSymbolWindow

Die obige Gleichung gilt nur für den Fall gdSymbolWindow ! = 0.

• gdBGWatchdogDisable = gdNIT
• gdBGpreEnablePart + 1 = gdActionPointOffset

Die Lücke zwischen Schlitzen (ISG) wird definiert durch:
ISG = gdBGpreEnablePart + gdBGpostEnablePart + 2
Unter Verwendung von BG-Konfigurationsparametern wird die Zykluszeit folgendermaßen berechnet:
BG-Zykluszeit (MT) =
gNumberOfStaticSlots·(gdBGStaticSlot + ISG)
+ gdBGDynSegment + ISG
+ gdBGSymbolWindow + ISG
+ gdBGWatchdogDisable
gdBGDynSegment ist ein optionales dynamisches Segment. (Das dynamische BG-Segment und die entsprechende ISG sind nicht Teil der BG-Einteilung, wenn gdBGDynSegment = 0 konfiguriert ist.) gdBGSymbolWindow ist ein optionales Symbolfenster. (Das BG-Symbolfenster und die entsprechende ISG sind nicht Teil der BG-Einteilung, wenn gdSymbolWindow = 0 konfiguriert ist.)
Tabelle 50 zeigt eine Zusammenfassung von Konfigurationsparametern in Bezug auf die Buswächterablaufsteuerung.
Tabelle 50: Buswächtereinteilungskonfigurationsparameter
Synchronisation BG-CC
Der FlexRay-Buswächteransatz hält die Synchronisation der lokalen BG-Ablaufsteuerung mit der globalen Zeit aufrecht, indem alle BG-Ablaufsteuerungsoperationen auf einem durch die CC bereitgestellten korrigierten Makroticksignal (MT) basiert werden. Dadurch kann der BG seine Mediumzugriffs-Schutzfunktion (d.h. Einschränkung des Sendezugriffs auf die konfigurierte Ablaufsteuerung) durchführen, während er kontinuierlich unter Verwendung des Taktsynchronisationsalgorithmus der CC mit dem globalen Takt synchronisiert ist.
Ein zweites Taktsignal, der Buswächtertick (BGT), der zur Überwachung der Periode des MT-Signals dient, wird durch die CC bereitgestellt. Die Kommunikationssteuerung soll das BGT-Signal dergestalt erzeugen, daß seine Periode von der durch die CC durchgeführten Taktkorrektur unabhängig ist (zum Beispiel könnte das BGT-Signal aus der Anwendung eines programmierbaren Vorskalierers auf das Oszillatoreingangssignal der Kommunikationssteuerung abgeleitet werden). Der Buswächter soll mit dem BGT-Signal eine Überwachung der Dauer des korrigierten Makroticks durchführen, indem geprüft wird, ob das Verhältnis MT/BGT um mehr als eine vordefinierte konfigurierbare Grenze von dem nominalen Verhältnis abweicht. Annehmbare Abweichungen von der nominalen Grenze können durch den Taktratenkorrekturalgorithmus verursacht werden, da er die Länge bestimmter Makroticks vergrößert oder verkleinert, um die Gesamttaktrate aufrechtzuerhalten.
Schnittstellenanforderungen BG-CC
Tabelle 51 zeigt die BG-CC-Schnittstellenzeitsteuerungsanforderungen. Man beachte, daß die spezifizierten Einschränkungen als Ergebnis bestimmter Halbleitertechnologiebegrenzungen eingeführt wurden.
Tabelle 51: BG-CC-Schnittstellenzeitsteuerungsanforderungen (diese Zeitsteuerungsanforderungen sind implementierungsspezifisch)
BG-Ablaufsteuerungsüberwachungsdienst
Hintergrund
Der Dienst der BG-Ablaufsteuerungsüberwachung (BGSM) ist ein Dienst, der von der FlexRay-Kommunikationssteuerung bereitgestellt wird. Der Zweck dieses Dienstes ist, zu beurteilen, ob die Ausführung der Buswächterablaufsteuerung mit der Ausführung der jeweiligen Ablaufsteuerung der CC übereinstimmt.
Vorgeschlagene Funktionsspezifikation
Struktur
Der Buswächterablaufsteuerungsüberwacher verwendet die folgenden Eingangssignale zur Durchführung seiner Funktion (siehe 88): Das BG-Signal, die zu überwachende Regel iBgsmRule und das Bestätigungssignal vBgsmErrorAck als Eingangssignale. Die BGSM-Funktion produziert das Ausgangssignal vBgsmError. Der CC-Protokollautomat liest die Parameter pdBgeStaticDuration, pdBgeDynamicDuration, pdBgeSymbolDuration, pBgsmDynSegDisabled und pBgsmSymWinDisabled. Die folgenden Beschränkungen gelten für diese Parameter:
BGE ∊ {0, 1},
iBgsmRule ∊ {BGE_X, BGE_ENABLED, BGE_DISABLED},
vBgsmErrorAck ∊ {FALSE, TRUE},
vBgsmError ∊ {FALSE, TRUE},
pdBgeStaticDuration[MT] ∊ {1 ... TBD},
pdBgeDynamicDuration[MT] ∊ {1 ... TBD},
pdBgeSymbolDuration[MT] ∊ {1 ... TBD},
pBgsmDynSegDisabled ∊ {FALSE, TRUE},
pBgsmSymWinDisabled ∊ {FALSE, TRUE}.
89 zeigt einen Automaten, der die Funktionsweise des BGSM-Dienstes beschreibt.
Interaktion des BG-Ablaufsteuerungsüberwachers mit dem Protokollbetrieb
Hintergrund
Der Protokollbetrieb kann in zwei verschiedene Phasen aufgeteilt werden: die anfängliche Phase des unsynchronisierten Herauffahrens und die nachfolgende Phase des synchronisierten Betriebs. Die beiden Phasen unterscheiden sich folgendermaßen:

• während der anfänglichen unsychronisierten Herauffahrphase hat die Kommunikationssteuerung keine Kenntnis über die systemübergreifende synchronisierte Zeit, d.h. der Schlitzzähler und der Zykluszähler sind nicht synchronisiert.
• während der synchronisierten Betriebsphase hat die Kommunikationssteuerung Kenntnis der systemübergreifenden synchronisierten Zeit, d.h. der Schlitzzähler und der Zykluszähler sind synchronisiert.

Unsynchronisierte Herauffahrphase
In der unsynchronisierten Herauffahrphase soll BGSM alle Regeln annehmen, d.h. iBgsmRule wird auf BGE_X gesetzt.
Synchronisierte Betriebsphase
In der synchronisierten Betriebsphase wird die Kommunikationsablaufsteuerung zum Zugriff auf das Kommunikationsmedium verwendet. Eine Kommunikationsablaufsteuerung besteht aus den folgenden Bestandteilen: dem statischen Segment, dem dynamischen Segment, dem Symbolfenster und der Netzwerkleerlaufzeit (NIT – network idle time).
Statisches Segment
Der Konfigurationsparameter pdBgeStaticDuration definiert die Dauer der BGE-Aktivphase während Übertragungsschlitzen in dem statischen Segment. Die Beziehung zwischen pdBgeStaticDuration und anderen Konfigura tionsparametern in Bezug auf das statische Segment wird gegeben durch:
pdBgeStaticDuration = gdBGStaticSlot + 2 = gdStaticSlot – gdBGpreEnablePart – gdBGpostEnablePart
mit
gdBGpreEnablePart = gdActionPointOffset – 1
gdBGpostEnablePart = gdStaticSlot – pdBgeStaticDuration – gdActionPointOffsat + 1
Übertragungsschlitz
Beginnend mit dem ersten Makrotick des Übertragungsschlitzes soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart == 0) OR
(gdBGpostEnablePart == 0 AND
vorheriger statischer Schlitz == freigegeben)
iBgsmRule soll auf BGE_X gesetzt werden;
else
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit dem zweiten Makrotick des Übertragungsschlitzes soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart > 1)
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit Makrotick gdActionPointOffset des Übertragungsschlitzes soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart > 0)
iBgsmRule soll auf BGE_X gesetzt werden;
end;
Beginnend mit Makrotick gdActionPointOffset + 1 des Übertragungsschlitzes soll iBgsmRule auf BGE_ENABLED gesetzt werden. Beginnend mit Makrotick pdBgeStaticDuration + gdActionPointOffset soll die folgende Regel angewandt werden:
if (gdBGpostEnable Part > 0)
iBgsmRule soll auf BGE_X gesetzt werden;
end;
Beginnend mit Makrotick pdBgeStaticDuration + gdActionPointOffset + 1 soll die folgende Regel angewandt werden:
if (gdBGpostEnablePart > 1)
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Empfangsschlitz
Beginnend mit dem ersten Makrotick des Empfangsschlitzes soll die folgende Regel angewandt werden:
if (vorheriger statischer Schlitz == freigegeben) AND
(gdBGpostEnablePart == 0)
iBgsmRule soll auf BGE_X gesetzt werden;
else
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit dem zweiten Makrotick des Empfangsschlitztes soll iBgsmRule auf BGE_DISABLED gesetzt werden.
90 zeigt die Interaktion in dem statischen Segment. 91 zeigt die Interaktion in dem statischen Segment für eine minimale ISG-Länge.
Dynamisches Segment
Der Konfigurationsparameter pdBgeDynamicDuration definiert die Dauer der BGE-Aktiv-Phase während des dynamischen Segments. Die Beziehung zwischen pdBgeDynamicDuration und anderen Konfigurationsparametern in Bezug auf das dynamische Segment wird gegeben durch:
pdBgeDynamicDuration = gdBGDynSegment + 2 =
gNumberOfMinislots·gdMinislot – gdBGpreEnablePart – gdBGpostEnablePart
(Anmerkung: Die Gleichung gNumberOfMinislots gilt nur für den Fall gNumberOfMinislots ! = 0.)
mit:
gdBGpreEnablePart = gdActionPointOffset – 1
gdBGpostEnablePart = gdStaticSlot – pdBgeStaticDuration – gdActionPointOffset + 1
Die folgenden Regeln gelten nur für Konfigurationen, die ein dynamisches Segment enthalten (gdNumberOfMinislots ! = 0). Der Konfigurationsparameter pBgsmDynSegDisabled zeigt an, ob Übertragung während des dynamischen Segments von dem BG freigegeben oder gesperrt werden soll und steuert, welche Menge von Regeln angewandt werden muß.
pBgsmDynSegDisabled = TRUE
Beginnend mit dem ersten Makrotick des dynamischen Segments soll die folgende Regel angewandt werden:
if (letzter statischer Schlitz == freigegeben) AND
fgdBGpostEnablePart == 0)
iBgsmRule soll auf BGE_X gesetzt werden;
else
iBgsmRule soll auf BGE_DISTABLED gesetzt werden;
end;
Beginnend mit dem zweiten Makrotick des dynamischen Segments soll iBgsmRule auf BGE_DISABLED gesetzt werden.
pBgsmDynSegDisabled = FALSE
Beginnend mit dem ersten Makrotick des dynamischen Segments soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart == 0) OR
(letzter statischer Schlitz == freigegeben) AND
(gdBGpostEnablePart == 0)
iBgsmRule soll auf BGE_X gesetzt werden;
else
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit dem zweiten Makrotick des dynamischen Segments soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart > 1)
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit Makrotick gdActionPointOffset des dynamischen Segments soll iBgsmRule auf BGE_X gesetzt werden.
Beginnend mit Makrotick gdActionPointOffset + 1 soll iBgsmRule auf BGE_ENABLED gesetzt werden.
Beginnend mit Makrotick pdBgeStaticDuration + gdActionPointOffset soll die folgende Regel angewandt werden:
if (gdBGpostEnablePart > 0)
iBgsmRule soll auf BGE_X gesetzt werden;
end;
Beginnend mit Makrotick pdBgeStaticDuration + gdActionPointOffset + 1 soll die folgende Regel angewandt werden:
if (gdBGpostEnablePart > 1)
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
92 zeigt die Interaktion in dem dynamischen Segment mit gesperrtem Symbolfenster.
Symbolfenster
Der Konfigurationsparameter pdBgeSymbolDuration definiert die Dauer der BGE-Aktiv-Phase während des Symbolfensters. Die Beziehung zwischen pdBgeSymbolDuration und anderen Konfigurationsparametern in Bezug auf das Symbolfenster wird gegeben durch:
pdBgeSymbolDuration = gdBGSymbolWindow + 2 =
gdSymbolWindow – gdBGpreEnablePart – gdBGpostEnablePart
Die folgenden Regeln gelten nur für Konfigurationen, die ein Symbolfenster enthalten (gdSymbolWindow ! = 0).
Der Konfigurationsparameter pBgsmSymWinDisabled gibt an, ob die Übertragung während des Symbolfensters durch den BG freigegeben oder gesperrt werden soll und steuert, welche Menge von Regeln angewandt werden muß.
pBgsmSymWinDisabled = TRUE
Beginnend mit dem ersten Makrotick des Symbolfensters soll die folgende Regel angewandt werden:
if (gdBGpostEnablePart == 0) AND
(pBgsmDynSegDisabled == FALSE)
iBgsmRule soll auf BGE_X gesetzt werden;
else
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit dem zweiten Makrotick des Symbolfensters soll iBgsmRule auf BGE_DISABLED gesetzt werden.
pBgsmSymWinDisabled = FALSE
Beginnend mit dem ersten Makrotick des Symbolfensters soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart == 0) OR
(gdBGpostEnablePart == 0 AND
pBgsmDynSegDisabled == FALSE)
iBgsmRule soll auf BGE_X gesetzt werden;
else
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit dem zweiten Makrotick des Symbolfensters soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart > 1)
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit Makrotick gdActionPointOffset des Symbolfensters soll die folgende Regel angewandt werden:
if (gdBGpreEnablePart > 0)
iBgsmRule soll auf BGE_X gesetzt werden;
end;
Beginnend mit Makrotick gdActionPointOffset + 1 soll iBgsmRule auf BGE_ENABLED gesetzt werden.
Beginnend mit Makrotick pdBgeSymbolDuration + gdActionPointOffset soll die folgende Regel angewandt werden:
if (gdBGpostEnablePart > 0)
iBgsmRule soll auf BGE_X gesetzt werden;
end;
Beginnend mit Makrotick pdBgeSymbolDuration + gdActionPointOffset + 1 soll die folgende Regel angewandt werden:
if (gdBGpostEnablePart > 1)
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
93 zeigt die Interaktion in dem Symbolfenster und der Netzwerkleerlaufzeit.
Netzwerkleerlaufzeit
Beginnend mit dem ersten Makrotick der Netzwerkleerlaufzeit soll die folgende Regel angewandt werden:
if (gdBGpostEnablePart == 0) AND
(pBgsmSymWinDisabled == FALSE)
iBgsmRule soll auf BGE_X gesetzt werden;
else
iBgsmRule soll auf BGE_DISABLED gesetzt werden;
end;
Beginnend mit dem zweiten Makrotick der Netzwerkleerlaufzeit soll iBgsmRule auf BGE DISABLED gesetzt werden.
Hostinteraktion
Nach Erkennung eines Regelverstoßes soll die Kommunikationssteuerung dem Hostcomputer diesen Verstoß mittels des Flags vBgsmError in der Hostschnittstelle signalisieren.
Das Flag soll gesetzt bleiben, bis es durch die Hoststeuerung gelöscht wird.
Anmerkungen
Zur Zeit wird die Möglichkeit zum Reaktivieren des Ablaufsteuerungsüberwachers nicht vorhergesehen. Bei ohne einen BG arbeitenden Systemen ist zu beachten, daß dies zur Folge hat, daß vBgsmError einen permanenten BG-Fehler anzeigt, sobald die (erwartete) erste Nichtübereinstimmung zwischen der konfigurierten Regel und dem BGE-Signal auftritt.
Ereignisgetriggerter Modus
Einführung
Dieses Kapitel beschreibt den ereignisgetriggerten Kommunikationsmodus des FlexRay-Kommunikationsproto kolls. Im Gegensatz zum zeitgetriggerten Kommunikationsmodus kann das Wiederholungsintervall des Kommunikationszyklus im ereignisgetriggerten Kommunikationsmodus variieren.
Betriebsarten
FlexRay unterstützt zwei Betriebsarten für die Kommunikationszyklusausführung (siehe 94, worin die FlexRay-Kommunikationsbetriebsarten gezeigt sind):
Einen zeitgetriggerten Kommunikationsmodus, in dem die Zeitbasis entweder durch einen verteilten Taktalgorithmus oder unter der Kontrolle eines Kommunikations-Masters erzeugt wird
Einen ereignisgetriggerten Kommunikationsmodus
Die verschiedenen Betriebsarten werden nachfolgend beschrieben.
Zeitgetriggerte Kommunikationszyklen
Dieser Modus wird ausführlich in dem Mediumzugriffskapitel beschrieben (siehe das Kapitel „Mediumzugriffsschema").
Ereignisgetriggerte Kommunikationszyklen
Im ereignisgetriggerten Kommunikationsmodus wird der Kommunikationszyklus immer durch einen Master-Knoten eingeleitet. Der Master-Knoten kann den Kommunikationszyklus auf der Basis der Eingabe einer Anzahl von Quellen einleiten. Die Verwaltung dieser Quellen unterliegt Host-Kontrolle über die CHI. Die folgende Funktionalität ist die minimal erforderliche (siehe 95, worin die ereignisgetriggerte Kommunikationsbehandlung in dem Host, in der CHI und in der CC gezeigt ist).
Ein Mechanismus, der es dem Host erlaubt, über die CHI einen Kommunikationszyklus einzuleiten. Es gibt viele Mittel, durch die dies erreicht werden könnte. Ein Beispiel ist ein CHI-Element, das, wenn es durch den Host geschrieben wird, die Einleitung eines Kommunikationszyklus bewirken würde. Wenn der Host während eines Kommunikationszyklus einen neuen Trigger einleitet, soll sofort nach dem Ende des aktuellen Kommunikationszyklus ein neuer Kommunikationszyklus getriggert werden.
Ein konfigurierbarer Timer zum Einleiten periodischer Kommunikationszyklen. Die CHI liefert eine Funktion zum Starten/Stoppen des Timers. Wenn der Timer freigegeben ist, wird ein Kommunikationszyklus gestartet, wenn der Timer abläuft.
Einen direkten Hardware-Eingang an der Kommunikationssteuerung zum Triggern des Kommunikationszyklus durch einen externen Hardware-Anschluß. Die CHI gibt dem Host Gelegenheit, den direkten Hardware-Eingang zu konfigurieren (Freigeben/Sperren, Flankenempfindlichkeit usw.).
Alle CHI-Quellen können das CC-Triggersignal aufsetzen (OR-Funktion). Die erforderliche Protokoll-Engine-Schnittstelle ist der CC-Triggereingang.
Wenn das CC-Triggersignal an einem fest zugeordneten Master auftritt, wird der Kommunikationszyklus durch Senden eines Ereignisanzeigesymbols (EIS) in dem Triggerfenster eingeleitet. Der neue Zyklus wird dann gestartet, nachdem der Master die NIT mit Rahmen-ID 1 gesendet hat.
8. Im ereignisgetriggerten Kommunikationsmodus ist kein Buswächterschutz erforderlich.
Die Takte auf den Master- und Slave-Knoten werden durch Senden und Empfangen des EIS-Symbols synchronisiert.
Das FlexRay-Protokoll behandelt einen Fehler, der verhindert, daß der Kommunikations-Master das EIS oder Rahmen-ID 1 sendet, nicht spezifisch. Es gibt mögliche Behebungsstrategien (Umkonfiguration des Systems, um zum Beispiel einen neuen Master zu benutzen), aber diese müssen auf der Anwendungsebene implementiert werden und sind nicht Teil des Protokolls.
Der ereignisgetriggerte Modus unterstützt zwei Kanäle. Der Master steuert in einem Zweikanalsystem beide Kanäle. Der Master sendet das EIS und Rahmen-ID 1 gleichzeitig auf allen konfigurierten Kanälen. Die Slave-Knoten müssen nicht mit beiden Kanälen verbunden sein. Wenn ein Slave mit beiden Kanälen verbunden ist, gewinnt der Kanal mit dem korrekten EIS-Symbol in Kombination mit Rahmen-ID 1 die Arbitrierung und bestimmt den Zyklusstart auf dem Slave.
Die Verwendung eines EIS-Symbols in Kombination mit dem Rahmen mit ID 1 hat die folgenden Vorteile:
Slave-Knoten können mit minimaler Zeitverzögerung bei Annahme des FlexRay-Mediumzugriffsschemas auf ein Triggerereignis auf dem Master-Knoten reagieren. Die Wiederverwendung des FlexRay-Mediumzugriffsschemas ist deshalb möglich.
Der Zykluszähler wird in dem Master und im Slave am (Zyklusstart) inkrementiert. Deshalb kann nahezu dasselbe Rahmenakzeptanzverfahren angewandt werden.
Umordnen der Nachrichten in dem dynamischen Teil kann in der NIT geschehen
Mediumzugriff – Ereignisgetriggerter Modus
Der Kommunikationszyklus ist das fundamentale Element des Mediumzugriffsschemas in FlexRay. Er wird mittels einer „Zeitsteuerungshierarchie" gesteuert.
Zeitsteuerungshierarchie
Die Zeitsteuerungshierarchie besteht aus vier Zeitsteuerungshierarchieebenen (siehe 96).
Die höchste Ebene, die Kommunikationszyklusebene definiert den Kommunikationszyklus. Sie enthält das statische Segment, das dynamische Segment, das Symbolfenster und die Netzwerkleerlaufzeit (NIT). In dem statischen Segment werden mit einem statischen Zeitmultiplexzugriffschema Übertragungen arbitriert, wie in dem Abschnitt „statisches Segment" spezifiziert. In dem dynamischen Segment werden Übertragungen mit einem dynamischen, auf Minischlitzen basierenden Schema arbitriert, wie in dem Abschnitt „Dynamisches Segment" spezifiziert. Das Symbolfenster ist eine Kommunikationsperiode, in der ein Symbol aus einer definierten Menge von Symbolen in dem Netzwerk übertragen werden kann, wie in dem Abschnitt „Symbolfenster" spezifiziert. Das statische Segment, das dynamische Segment und das Symbolfenster bilden die Netzwerkkommunikationszeit (NCT), eine Periode, in der netzwerkübergreifende Kommunikation stattfindet. Die Netzwerkleerlaufzeit definiert eine kommunikationsfreie Periode, mit der jeder Kommunikationszyklus endet.
Die nächst niedrigere Ebene, die Arbitrierungsgitterebene, enthält das Arbitrierungsgitter, das das Rückgrat der FlexRay-Medium-Arbitrierung bildet. In dem statischen Segment besteht das Arbitrierungsgitter aus aufeinanderfolgenden Zeitintervallen, die als statische Schlitze bezeichnet werden, in dem dynamischen Segment besteht das Arbitrierungsgitter aus aufeinanderfolgenden Zeitintervallen, die als Minischlitze bezeichnet werden. Die Arbitrierungsgitterebene baut auf die Makrotickebene auf, die durch den Makrotick definiert wird. Spezifische Makrotickgrenzen werden als Aktionspunkte bezeichnet. Diese sind fest zugeordnete Zeitpunkte, an denen Übertragungen starten sollen (in dem statischen Segment, dem dynamischen Segment und dem Symbolfenster) und enden sollen (nur in dem dynamischen Segment).
Die niedrigste Ebene in der Hierarchie wird durch den Mikrotick definiert, der in dem Kapitel „Taktsynchronisation" abgedeckt wird.
Kommunikationszyklusausführung
Im ereignisgetriggerten Modus wird der Kommunikationszyklus unter der Kontrolle eines einzigen Masters ausgeführt. Jeder Knoten tritt in eine als Zykluslücke bezeichnete Phase unmittelbar nach dem Ende des dynamischen Segments ein. Wenn kein dynamisches Segment besteht, beginnt die Zykluslücke am Ende des statischen Segments. In der Zykluslücke wird die Ausführung des Kommunikationszyklus suspendiert, bis ein Ereignisanzeigesymbol (EIS) empfangen wird. Der Master gibt das EIS-Symbol aus. Nach Empfang des EIS-Symbols nehmen alle Knoten die Ausführung des Kommunikationszyklus wieder auf.
97 zeigt die Ausführung des ereignisgetriggerten Kommunikationszyklus.
Ereignisanzeigesymbol (EIS)
Das Ereignisanzeigesymbol (EIS) wird in dem Kapitel „Codierung und Decodierung" definiert. Die zweite fallende Flanke dient als Synchronisationsereignis (SyncEvent) auf Master- und Slave-Knoten. Das EIS-Symbol muß nicht kollisionsbeständig sein. Die Triggerbedingung in dem EIS ist in 98 dargestellt.
Taktsynchronisation im ereignisgetriggerten Modus
Prinzip
Die Kommunikationszykluszeitsteuerung im ereignisgetriggerten Modus basiert auf dem EIS-Symbol. Da der Start eines Kommunikationszyklus nicht vorhersehbar ist (und deshalb die Dauer eines Kommunikationszyklus variabel ist), gibt es keinen Zeitbegriff, der von den Slave-Knoten verwendet werden kann, um eine Taktratenkorrektur durchzuführen, und das EIS wird einfach von den Slave-Knoten als ein Synchronisationsereignis verwendet und die gesamte nachfolgende Zeitsteuerung basiert auf den nominalen (unkorrigierten) Makroticks auf der Basis eines Zeitstörungsgitters, das durch die Ankunftszeit des EIS festgelegt wird. Die folgenden Absätze definieren die Einzelheiten der Taktsynchronisation für Master- und Slave-Knoten.
Taktsynchronisation des Master-Knotens
Nach der Ankunft des CC-Triggerereignisses auf dem Master-Knoten startet das Symbolfenster und der Master sendet das EIS-Symbol in dem Symbolfenster am Anfang des nächsten Mikroticks. Während des Sendens des EIS-Symbols wird der Timer vEDMTimer an dem SyncEvent-Punkt mit dem Konfigurationswert pdMasterEIStoEndOfNIT initialisiert (der Parameter pdMasterEIStoEndOfNIT wird in Mikroticks ausgedrückt, um Zeitsteuerungs-Jitter zu minimieren), der die Dauer zwischen dem SyncEvent-Punkt des EIS und dem Ende der NIT beschreibt.
Wenn der Timer vEDMTimer am Ende der Phase b abläuft (siehe 97) wird der neue Kommunikationszyklus gestartet, der Master initialisiert die Makrotick- und Mikrotickzähler mit 0, und der Zykluszähler wird inkrementiert.
Beginnend mit dem neuen Zyklus sendet der Master einen Rahmen mit ID 1. Das Zykluszählerfeld dieses Rahmens wird auf den lokalen Zykluszähler des Masters gesetzt.
Taktsynchronisation des Slave-Knotens
Wenn ein Slave mit zwei Kanälen verbunden ist, wird der erste gültige Empfang eines EIS-Symbols auf einem der beiden Kanäle genommen.
Wenn ein Slave den Empfang eines gültigen EIS-Symbols erkennt, wird der Timer vEDMTimer provisorisch an dem SyncEvent-Punkt mit dem Konfigurationsfeld pdMasterEIStoEndOfNIT initialisiert, der die Dauer zwischen dem SyncEvent-Punkt des empfangenen EIS-Symbols und dem Ende der NIT quantifiziert (der Parameter pdSlaveEIStoEndOfNIT wird über das SyncEvent des empfangenen EIS ausgedrückt und sollte deshalb die Effekte einer etwaigen festen Netzwerkausbreitungsverzögerung enthalten. Der Parameter wird in Mikroticks ausgedrückt, um Zeitsteuerungs-Jitter zu minimieren.). Der Timer vEDMTimer wird eingewiesen, wenn das EIS-Symbol korrekt empfangen wurde. Der Parameter pdMasterEIStoEndOfNIT wird während des Soft-Rücksetzens konfiguriert. Wenn der Timer vEDMTimer am Ende der Phase c abläuft, wird der neue Kommunikationszyklus gestartet, der Slave initialisiert die Makrotick- und Mikrotickzähler mit 0, und der lokale Zykluszähler wird inkrementiert. Danach wartet der Slave auf den Empfang des Rahmens mit ID 1.
Unter Verwendung dieser Prozedur wechseln alle Slave-Knoten, die das EIS empfangen und der Master-Knoten einheitlich zu dem nächsten Kommunikationszyklus. Während der Herauffahrphase wird der Prozeß auf andere Weise durchgeführt (siehe unten).
Wenn der Slave den Empfang eines gültigen EIS-Symbols nicht erkennt, wird keine Aktion durchgeführt. Die lokale Zeit schreitet bis zum Empfang eines neuen EIS-Symbols voran und die Zeitsteuerungsüberwachung (siehe unten) signalisiert einen Fehler.
Rahmenverarbeitung im ereignisgetriggerten Modus
Rahmenverarbeitung des Master-Knotens
Der Master-Knoten soll Rahmen unter Verwendung der Prozedur verarbeiten, die in dem Kapitel „Rahmenverarbeitung" am Anfang der vorliegenden Schrift definiert wird.
Rahmenverarbeitung des Slave-Knotens
Wenn kein gültiger Rahmen mit Rahmen-ID 1 auf mindestens einem Kanal korrekt im Schlitz 1 nach einem EIS-Symbol auf einem Slave-Knoten empfangen wird, führt dieser Slave-Knoten während des Kommunikationszyklus keine Kommunikation aus (in diesem Fall bedeutet „keine Kommunikation", daß keine Übertragung von Rahmen möglich ist. Das Empfangen von Rahmen kann durchgeführt werden). Dies wird durch Setzen von S_Trig_Symb_Failure angezeigt.
Wenn mindestens ein gültiger Rahmen mit ID 1 im Schlitz 1 auf einem Slave-Knoten empfangen wird, wendet der Slave die oben beschriebenen Rahmenprüfungen an, mit der Ausnahme, daß die Zykluszählerprüfungen von Schlitz 1 wie nachfolgend beschrieben behandelt werden (In den nachfolgenden Beschreibungen wird angenommen, daß ein Rahmen nur dann als gültig betrachtet wird, wenn alle Annahmekriterien mit Ausnahme der Zykluszählerübereinstimmung erfüllt sind.):
Einzelkanalverbundene Slaves

• Wenn der Zykluszähler des empfangenen Rahmens mit ID = 1 nicht gleich dem lokalen Zykluszähler ist, soll der lokale Zykluszähler auf den Zykluszähler gesetzt werden, der in dem Rahmen mit ID = 1 empfangen wird. Dies wird durch ein S_CycleCountError angezeigt. Der Rahmen mit ID = 1 wird normal angenommen und der Rest des Kommunikationszyklus wird normal ausgeführt.
• In allen anderen Fällen soll der lokale Zykluszähler unverändert bleiben, der Rahmen soll weiter den Akzeptanzprozeß durchlaufen und der Kommunikationszyklus soll normal ausgeführt werden

Zweikanalverbundener Slave

• Wenn die Zykluszählwerte aller empfangenen Rahmen mit ID = 1 identisch, aber nicht gleich dem lokalen Zykluszähler sind, dann soll der lokale Zykluszähler auf den Zykluszähler gesetzt werden, der in dem Rahmen mit ID = 1 empfangen wird (wenn nur ein Rahmen empfangen wird, ist er als Vorgabe identisch). Dies wird durch ein S_CycleCountError angezeigt. Der bzw. die Rahmen mit ID = 1 werden normal angenommen und der Rest des Kommunikationszyklus wird normal ausgeführt.
• In allen anderen Fällen soll der lokale Zykluszähler unverändert bleiben, der bzw. die Rahmen soll bzw. sollen weiter den Akzeptanzprozeß durchlaufen und der Kommunikationszyklus soll normal ausgeführt werden

Nach dem ersten Schlitz sollen alle Rahmen für den Rest des Kommunikationszyklus unter Verwendung der in dem Kapitel „Rahmenverarbeitung" der vorliegenden Schrift beschriebenen Prozedur verarbeitet werden.
Überwachung der Zykluszeitsteuerung
Im ereignisgetriggerten Modus von FlexRay gibt es zwei verschiedene Methoden zur Überwachung der Zeitsteuerung des Kommunikationssystems, abhängig davon, ob ein Knoten als der Master oder als ein Slave dient:
Die Zeitsteuerung des CC-Triggers wird durch den Master überwacht. Die Zeitsteuerung von Zyklus zu Zyklus des EIS-Symbols, das vom Master gesendet wird, wird durch die Slaves überwacht.
Überwachung des CC-Triggers durch den Master
Die Zeitsteuerung des CC-Triggers wird durch den Master unter Verwendung eines durch zwei Konfigurationsparameter pdExTrigCycleMin und pdExTrigCycleMax definierten CC-Triggerfensters überwacht. Die Zeitsteuerungsüberwachung betrifft nur die externe Triggerquelle – die Triggerquellen „Host-Triggerbit" und „Zyklus-Timer" wirken sich nicht auf die Überwachung aus. Es gibt drei verschiedene Fälle in bezug auf die Ankunft des CC-Triggers:
Im Normalbetrieb erscheint der CC-Trigger später als pdExTrigCycleMin und früher als pdExTrigCycleMax. Es wird kein Fehler signalisiert und der Start eines neuen Kommunikationszyklus wird durch den CC-Trigger eingeleitet. Der Start eines neuen CC-Triggerfensters wird berechnet, wenn der CC-Trigger ankommt.
Wenn der CC-Trigger nicht vor pdExTrigCycleMax erscheint, wird ein Fehler EXT_TRIG_LIF (CC-Trigger-Verloren-Interrupt-Flag) nach pdExTrigCycleMax signalisiert. Der Start eines neuen Triggerfensters wird erst nach der tatsächlichen Ankunft eines neuen CC-Triggers bestimmt. So lange kein neuer CC-Trigger ankommt, wird kein neuer Kommunikationszyklus eingeleitet. Es liegt am Host, notwendigenfalls den Kommunikationszyklus einzuleiten.
Wenn der CC-Trigger früher als pdExTrigCycleMin erscheint, wird der Fehler EXT_TRIG_LIF (CC-Trigger- Früh-Interrupt-Flag) sofort signalisiert. In diesem Fall wird kein Kommunikationszyklus eingeleitet und kein neues Triggerfenster bestimmt.
Diese Bedingungen sind in 99 abgebildet.
Überwachung der EIS-Zeitsteuerung durch die Slaves
Die Zeitsteuerung des Empfangs von Ereignisanzeigesymbolen wird durch die Slaves durch Verwendung eines durch zwei Konfigurationsparameter pdEISSymbCycleMin und pdEISSymbCycleMax definierten EIS-Fensters überwacht. Es gibt drei verschiedene Fälle in bezug auf die Ankunft des EIS:
Im Normalbetrieb erscheint das Ende des EIS später als pdEISSymbCycleMin, aber früher als pdEISSymbCycleMax. Es wird kein Fehler signalisiert. Der Start eines neuen EIS-Fensters wird berechnet, wenn das Ende des EIS ankommt.
Wenn kein gültiges EIS empfangen wird, so daß das Ende des EIS vor pdEISSymbCycleMax erscheint, wird ein Fehler EIS_SYMB_LIF (EIS-Symbol-Verloren-Interrupt-Flag) nach pdEISSymbCycleMax signalisiert. Wenn ein EIS-Symbol ankommt, fahren die Slaves mit einem neuen Kommunikationszyklus fort.
Wenn das Ende des EIS-Symbols früher als pdEISSymbCycleMin erscheint, wird das zu frühe EIS-Symbol ignoriert und es wird sofort ein Fehler EIS_SYMB_EIF (EIS-Symbol-Früh-Interrupt-Flag) signalisiert. Der Knoten wechselt zu einem Passiv-Modus, wobei jegliches Senden und Empfangen von Rahmen gestoppt wird. Es wird kein neues EIS-Fenster berechnet und kein neuer Kommunikationszykus eingeleitet. Der Slave-Knoten wartet auf ein weiteres EIS-Symbol nach pdEISSymbCycleMin.
Diese Bedingungen sind in 100 abgebildet.
Herauffahren und Reintegration – Ereignisgetriggerter Modus
Die folgende Übersicht beschreibt das CC-verhalten im ereignisgetriggerten Kommunikationsmodus. Bedingungen für den Eintritt in diese Zustände und den Austritt aus ihnen werden in Tabelle 52 beschrieben.
Zustandsübergänge mit einem Präfix „G" sind globale Übergänge für das FlexRay-Protokoll.
Zustandsübergänge mit einem Präfix „L" geben Zustandsübergänge an, die logischen Bedingungen entsprechen. Zustandsübergänge mit einem Präfix „E" sind Übergänge, die für den ereignisgetriggerten Kommunikationsmodus spezifisch sind.
Wenn sich ein Knoten in ein ablaufendes System integriert oder beim Herauffahren wird der Zykluszähler aus dem Master ohne Setzen einer Fehleranzeige akzeptiert. Die Fehleranzeige wird unterdrückt, bis die Integration erfolgreich abgeschlossen ist.
Tabelle 52: Zustandsübergänge – ereignisgetriggerter Modus
Zustandsdiagramm
101 zeigt ein Protokollzustandsdiagramm für den ereignisgetriggerten Modus.
Hostschnittstellenanforderungen – Ereignisgetriggerter Modus
Spezifische Anforderungen für den ereignisgetriggerten Modus:
Ein Konfigurationsparameter (z.B. pMasterSelect, oder man ziehe in Erwägung, pSyncMaster wiederzuverwenden), definiert, ob der Knoten als ein Master oder als ein Slave wirkt.
Für den Master-Knoten existieren drei Ereignisquellen für das Starten des nächsten Zyklus: externes Ereignis, Hostzugriff, CC-interner Timer (normale Zugriffslänge). Der Host entscheidet in der Laufzeit, welche Ereignisquelle(n) verwendet wird bzw. werden.
Die Trigger-/Ereignisquellen externes Ereignis und CC-interner Timer können unabhängig freigegeben/gesperrt werden. Wenn mehr als eine Quelle freigegeben ist, macht das erste Ereignis die CC scharf, um das EIS-Symbol zu senden. Mindestens eine der Trigger-Quellen muß freigegeben sein.
Produktspezifisch: Das Verhalten des Eingangssignals für die externe Quelle soll in Bezug auf den Triggertyp (fallende oder ansteigende Flanke) und die Zuweisung zu einem Trigger-Anschluß konfigurierbar sein.
Produktspezifisch: Bei Erkennung des Triggerereignisses soll die Master-CC den Makrotickzähler erfassen und diesen Wert dem Host vorlegen.
Produktspezifisch: Beim Empfang des Triggerereignisses soll die Master-CC dies dem Host sofort anzeigen (Ereignis-Trigger).
Produktspezifisch: Beim Empfang des Ereignisanzeigesymbols sollen die Slaves ihre Makrotickzähler erfassen.
Nach Empfang des Ereignisanzeigesymbols soll der Slave dies dem Host sofort anzeigen (Ereignisanzeigesymbol (EIS) detektiert).
Es ist erforderlich, daß der Host in der Lage ist, die Sendepuffer während des dynamischen Segments auf die folgende Weise zu ändern:

• Die Daten eines Puffers können geändert werden.
• Die Daten und die ID eines Puffers können geändert werden, so lange sich ihre Reihenfolge in der Liste dynamischer IDs nicht ändert

Allgemeines Interrupt-Register
Für den ereignisgetriggerten Kommunikationsmodus sind die oben beschriebenen Interrupt-Flags verfügbar. Tabelle 53 zeigt zusätzliche Interrupt-Flags, die für den ereignisgetriggerten Kommunikationsmodus spezifisch sind.
Jede in Tabelle 53 beschriebene Interrupt-Quelle soll einen individuellen Freigabe-/Sperrmechanismus besitzen.
Tabelle 53: Interrupt-Register-Ereignisgetriggerte Modus
Anmerkung: Es ist möglich, den Externe-Quelle-Interrupt (EXT_SOR_INT) auch dann zu benutzen, wenn die externe Quelle nicht zum Sammeln von Informationen über das Auftreten von Externe-Quelle-Trigger-Ereignissen verwendet wird.
Fehlermanagement – Master-getriggerter Modus
Für den ereignisgetriggerten Kommunikationsmodus gilt im allgemeinen das in dem Kapitel „Fehlersignalisierung und Fehlerbehandlung" beschriebene Fehlermanagement. Nur die Behandlung des Rahmens mit ID = 1 ist verschieden. Wenn ein Rahmen nicht Rahmen-ID 1 nach einem korrekten EIS-Symbol empfängt, schaltet der Slave-Knoten Fehler (passiv) herein und hält die Rahmenübertragung an, bis ein nächstes Paar aus gültigem EIS + Rahmen-Id 1 empfangen wird.
Die Fehlersignalisierungszähler werden während des – Übergangs am Anfang des neuen Kommunikationszyklus neu initialisiert.
Steuerungshost-Schnittstellen-Beispiel Zweck
Dieses Kapitel enthält ein Beispiel für eine Steuerungshostschnittstelle (CHI), die den in dem Kapitel „Steuerungshostschnittstelle" und in dem Kapitel „Steuerungshostschnittstellen-Dienste" definierten Hostschnittstellenanforderungen genügt.
Ein Teil dieser Anforderungen gilt für alle FlexRay-Implementierungen, und andere gelten nur, wenn spezifische optionale Protokollmechanismen implementiert werden.
Steuerungsstatusregister
Dieser Abschnitt zählt die Register auf, die durch die Kommunikationssteuerung unterstützt werden sollen, um dem Host Statusinformationen bezüglich des Betriebes der Steuerung und den aktuellen Wert verschiedener CC-interner Variablen zuzuführen. Auf Leseanforderung des Host soll der derzeitige Steuerungsstatus bereitgestellt werden. Die interne Variablen haltenden Statusregister sollen bei den Zustandsübergängen L1, L5 und L6 des HW-Automaten (siehe den Abschnitt „CC-Zustandsdiagramm") gelöscht und sollen durch die CC aktualisiert werden. Der Host soll Nur-Lese-Zugriff auf die Statusinformationen besitzen. Der Host kann im allgemeinen den Inhalt dieser Register nicht modifizieren, mit der Ausnahme bestimmter Fehlerflags, die vom Host gelöscht werden können.
Produktversionsregister
Die CHI soll ein 16-Bit-Nurleseregister zum Halten der FlexRay-Produktversionsnummer bereitstellen. Diese Nummer identifiziert den Hersteller, das Produkt und die implementierte Protokollversion, um es dem Benutzer zu ermöglichen, zwischen verschiedenen Produkten zu unterscheiden. Beginnend mit dem MSB soll das Register folgendermaßen benutzt werden:

• 5 Bit zum Identifizieren des Siliziumherstellers
• 4 Bit für herstellerdefinierte Siliziumversionen
• 7 Bit zum Identifizieren der implementierten Protokollversion.

Der Halbleiterhersteller soll diese Versionsnummer mit dem FlexRay-Konsortium vereinbaren.
Aktueller Zykluszählerwert
Die CHI soll ein 6-Bit-Register zum Halten des aktuellen Zykluszählerwerts(vCycle) bereitstellen. Der Inhalt soll durch CC am Start des Zyklus implementiert werden.
Aktueller Makrotickwert
Die CHI soll ein 16-Bit-Register zum Halten des aktuellen Makrotickwerts (vMacrotick) bereitstellen. Der Inhalt soll durch CC inkrementiert und am Start des Zyklus zurückgesetzt werden.
Ratenkorrekturwert
Die CHI soll ein 8-Bit-Register zum Halten des Ratenkorrekturwerts (vRateCorrection) bereitstellen, der von der Takt-Sync in dem aktuellen Zyklus angewandt wird. (Siehe den Abschnitt „Berechnung des Ratenkorrekturwerts")
Offsetkorrekturwert
Die CHI soll ein 8-Bit-Register zum Halten des Ratenkorrekturwerts (vOffsetCorrection) bereitstellen, der von der Takt-Sync in dem aktuellen Zyklus angewandt wird. (Siehe den Abschnitt „Berechnung des Offsetkorrekturwerts")
Gültige-Sync-Rahmen Kanal A (VSFC_A)
Die CHI soll ein 5-Bit-Register bereitstellen, das die Anzahl in dem vorherigen Zyklus empfangener gültiger sync-Rahmen angibt. Die Variable soll nur am Ende des statischen Segments mit dem Zählerwert VSFC_A aktualisiert werden.
Gültige-Sync-Rahmen Kanal B (VSFC_B)
Die CHI soll ein 5-Bit-Register bereitstellen, das die Anzahl in dem vorherigen Zyklus empfangener gültiger sync-Rahmen angibt. Die Variable soll nur am Ende des statischen Segments mit dem Zählerwert VSFC_B aktualisiert werden.
Zur Takt-Sync verwendete sync-Rahmen
Die CHI soll ein 5-Bit-Register bereitstellen, das die Anzahl für die Berechnung der Ratenkorrekturterme im vorherigen Zyklus benutzter gültiger sync-Rahmenpaare angibt. Das Register soll nur am Ende der NIT des ungeraden Zyklus mit dem Zählerwert vValidSyncFrameCount aktualisiert werden. (Siehe den Abschnitt „Taktsynchronisation – allgemeine Konzepte")
Fehlendes Ratenkorrektursignal (MRCS)
Die CC soll ein Flag bereitstellen, um dem Host zu signalisieren, daß keine Ratenkorrektur ausgeführt werden kann, weil keine Paare (gerade/ungerade) von sync-Rahmen empfangen wurden. Das Flag soll von der CC nach erfolgreicher Ratenkorrektur zurückgesetzt werden. (Siehe den Abschnitt „Fehlendes Ratenkorrektursignal (MRCS)")
Fehlendes Offsetkorrektursignal (MOCS)
Die CC soll ein Flag bereitstellen, um dem Host zu signalisieren, daß keine Offsetkorrektur ausgeführt werden kann, weil keine sync-Rahmen in einem ungeraden Zyklus empfangen wurden. Das Flag soll von der CC nach erfolgreicher Offsetkorrektur zurückgesetzt werden. (Siehe den Abschnitt „Fehlendes Offsetkorrektursignal (MOCS)")
Taktkorrektur-Erfolglos-Zähler (CCFC)
Die CC soll einen 4-Bit-Zähler bereitstellen, der am Ende jedes ungeraden Kommunikationszyklus um eins inkrementiert werden soll, wenn entweder der Fehlende-Offsetkorrektur-Fehler oder der Fehlende-Ratenkorrektur-Fehler aktiv sind. CCFC soll am Ende eines ungeraden Kommunikationszyklus zurückgesetzt werden, wenn weder die Offsetkorrektur erfolglos geblieben ist noch Ratenkorrektur-Erfolglos-Fehler aktiv sind. CCFC stoppt bei 15 (Siehe den Abschnitt „Taktkorrektur-Erfolglos-Zähler (CCFC)")
Herauffahr-Mehrheit-Verfehlt-Signal (SMMS)
Die CC soll ein Flag bereitstellen, um dem Host zu signalisieren, daß die CC während des Herauffahrens eine Menge von sync-Rahmen empfangen hat, die nicht dazu führte, daß eine Mehrheit der sync-Rahmen mit der lokalen Sicht der Systemzeit übereinstimmt (siehe den Abschnitt „Herauffahr-Mehrheit-Verfehlt-Signal (SMMS)"). Das SMMS soll durch Hostinteraktion zurückgesetzt werden, oder wenn die CC den Zustandsübergangs L5 oder L6 des HW-Automaten ausführt (siehe den Abschnitt „CC-Zustandsdiagramm").
Protokollfehlerzustand
Die CC soll 2 Bit bereitstellen, die den aktuellen Protokollfehlerzustand angeben. (siehe den Abschnitt „Protokollfehlerzustandssignal")
Herauffahrstatusvektor
Die CC soll einen Herauffahrstatusvektor mit den folgenden Status-Flags bereitstellen:
vCCMS; Kaltstart-max. erreicht (vColdStartCount = gColdStartMax)
vSMMS, Plausibilitätsprüfung erfolglos
vOpViaColdstart; über Kaltstartweg in Normalzustand eingetreten
vColdStartAborted; Kaltstart aufgrund des Empfangs von CAS oder Sync-Rahmen abgebrochen
vColdstartNoise; aufgrund des Ablaufens von pColdstartNoise wurde in den Kaltstartweg eingetreten
Eine logische „1" zeigt die Wahrheitsbedingung für jedes Status-Flag an.
Für Einzelheiten siehe den Abschnitt „Kommunikationsherauffahren und Reintegration".
Buswächter-Ablaufsteuerungsüberwachungsfehler (BGME)
Die CC soll ein Flag bereitstellen, um dem Host einen Buswächter-Ablaufsteuerungsüberwachungsverstoß (vBgsmError) zu signalisieren. Das Flag soll durch den Ablaufsteuerungsüberwachungsmechanismus gesetzt und nur durch den Host gelöscht werden. (Siehe den Abschnitt „Buswächter-Ablaufsteuerungsüberwachungsfehler(BGME)")
Taktkorrekturgrenze erreicht (CCLR)
Die CC soll ein Flag bereitstellen, um dem Host zu signalisieren, daß der Offsetkorrekturwert (vOffsetCorrection) die rote Region erreicht hat (vOffsetCorrection > gOffsetCorrectionOut). Die CC soll nur die Fähigkeit zum Setzen dieses Flags besitzen. Das Flag soll gesetzt bleiben, bis es vom Host gelöscht wird. (Siehe den Abschnitt „Wertebegrenzungen" und den Abschnitt „Taktkorrekturgrenze erreicht (CCLR)").
Mediumzugriffsprüfungswarnung
Die CC soll ein Flag (pMATestWarning) bereitstellen, um dem Host zu signalisieren, daß die CC während des Symbolfensters ein Mediumzugriffsprüfsymbol (MTS) empfangen hat. Die CC soll nur die Fähigkeit zum Setzen dieses Flag besitzen. Das Flag soll gesetzt bleiben, bis es vom Host gelöscht wird.
Aufweckstatusvektor
Die CC soll einen Aufweckstatusvektor mit den folgenden Status-Flags bereitstellen:
Rahmenkopfteil während Aufweck-Flag empfangen (vWakeupFrameHeaderReceived). Dieses Flag soll gesetzt werden, wenn aufgrund des Empfangs eines Rahmenkopfteils ohne Codierungsverstoß die CC das Aufwecken stoppt. Aufwecksymbol-Empfangen-Flag (vWakeupSymbolReceived). Dieses Flag soll gesetzt werden, wenn aufgrund des Empfangs eines gültigen Rx-Aufwecksymbols die CC das Aufwecken stoppt.
Aufwecken-Erfolglos-Flag (vWakeupFailed). Dieses Flag soll gesetzt werden, wenn die CC aufgrund zu vieler Aufweckversuche das Aufwecken stoppt.
Aufwecken-Abgeschlossen-Flag (vWakeupComplete). Dieses Flag soll gesetzt werden, wenn die CC die Übertragung des Tx-Aufweckens abgeschlossen hat.
(Siehe den Abschnitt „Clusteraufwecken" für Einzelheiten)
Kommunikationssteuerungs-Statusvektor
Die CC soll einen Kommunikationssteuerungs-Statusvektor mit den folgenden Status-Flags bereitstellen, die die tatsächliche Betriebsart der CC angeben:
CC_SoftReset – Zustand
CC_Normal – Zustand
CC_ShutdownRequest – Zustand
CC_Shutdown Complete – Zustand
CC_Standby – Zustand
Listen-Only-Modus
WakeUPListen – Zustand
StartupListen – Zustand
ColdStartICW – Zustand
ColdStartVCW – Zustand
IntegrationVCW – Zustand
PassiveOperation – Zustand
Ereignisgetriggerter Modus
Die CC soll das Statusflag beim Eintritt in den entsprechenden Zustand oder in den entsprechenden Modus setzen und es nach dem Austritt daraus unabhängig von den Einstellungen in den verschiedenen Konfigurationsregistern löschen. Einzelheiten werden unten und in den Abschnitten „HW-Zustände der CC" und „Herauffahrzustandsdiagramm – Zeitgetriggerter Protokollmodus (TT-D und TT-M)" angegeben.
Konfigurations- und Steuerregister
Dieser Abschnitt zählt die Register auf, die durch die Kommunikationssteuerung unterstützt werden, um es dem Host zu erlauben, die Funktionsweise der CC zu steuern.
Der Host soll Schreib- und Lesezugriff auf alle Konfigurationsdaten besitzen.
Konfigurationsdaten sollen durch die CC während des Normalbetriebes nicht verändert werden. Die CC soll die Konfigurationsdaten bei ihrem Übergang L1 von dem CC_HWReset-Zustand (siehe den Abschnitt „HW-zustände der CC") zurücksetzen.
Modulkonfigurationsregister
Das Modulkonfigurationsregister (MCR) ermöglicht es dem Host, grundlegende Betriebsarten in der CC zu konfigurieren. (Siehe den Abschnitt „HW-Zustände der CC") Das MCR soll die folgenden Steuerbit bereitstellen:
Soft-Rücksetzen
Wenn dieses Bit vom Host gesetzt wird, soll die CC sofort in den Zustand CC_SoftReset eintreten. Jedes ablaufende Senden oder Empfangen soll abgebrochen und die Synchronisation mit der ablaufenden Kommunikation gestoppt werden. Wenn dieses Bit vom Host gelöscht wird, soll die CC in den Normal-Zustand eintreten und die Reintegration bzw. das Herauffahren starten. Wenn Aufwecken konfiguriert ist, soll die CC nach dem Verlassen von CC_SoftReset in den Zustand WakeUPListen eintreten. Die CC soll automatisch nach dem Einschaltrücksetzen in den Zustand CC_SoftReset eintreten. Der Host soll die CC in diesem Zustand konfigurieren. Wenn der Host die CC zu einem Soft-Rücksetzen zwingt, sollten die Status- und Fehlerregister ihre Daten unverändert halten, bis das Soft-Rücksetzen beendet ist. (Übergang L5 und L6 des HW-Automaten; siehe den Abschnitt „CC-Zustandsdiagramm"))
Nurlese-Auswahl
Wenn dieses Bit (vListenOnly) gesetzt ist, soll die CC in der Lage sein, nach erfolgreicher Integration in die ablaufende Kommunikation alle Rahmen zu empfangen. Im Vergleich zur Normalbetriebsart nimmt der Knoten nicht aktiv an der Kommunikation teil, d.h. es werden weder Symbole noch Rahmen gesendet. Dieses Bit kann nur in dem Zustand CC_SoftReset auf true gesetzt werden, kann aber zu jeder Zeit durch den Host gelöscht werden. (Siehe den Abschnitt „Nurlese-Modus")
Master-Auswahl
Dieses Bit (pSyncMaster) wählt die CC als einen Bus-Master in den mastergesteuerten Betriebsarten. (Siehe Abschnitt 0) Die CC soll das Ereignisanzeigesymbol und den statischen sync-Rahmen senden, wenn das Bit gesetzt ist. Die CC soll jeden Versuch, die Status dieses Bit außerhalb des Zustands CC_SoftReset zu ändern, ignorieren.
Master-Alarm
Wenn die Bit Master-Auswahl und Master-Alarm gesetzt sind, soll die CC im byteflight-Modus ein SAS-Symbol senden. Das Bit kann durch den Host zu jeder Zeit während des Normalbetriebs gesetzt und zurückgesetzt werden.
Herunterfahranforderung
Wenn dieses Bit vom Host gesetzt wird, soll die CC in den Zustand CC_ShutdownComplete eintreten (siehe den Abschnitt „Der Zustand CC_ShutDownComplete"). In diesem Zustand sollen alle internen Takte gestoppt werden, nachdem die aktuelle Kommunikationsrunde beendet ist. Der Zustand kann verlassen werden, indem der Host das Bit zurücksetzt.
Standby-Anforderung
Wenn dieses Bit vom Host gesetzt wird, soll die CC in den Zustand CC_StandByRequest eintreten. In diesem Zustand sollen alle internen Takte gestoppt werden, nachdem die CC ein etwaiges ablaufendes Senden und Empfangen abgeschlossen hat. Die CC soll diesen Zustand verlassen, wenn der Host das Bit zurücksetzt, oder wenn die physische Schicht am Rx-Eingang Aufweckaktivität signalisiert.
Sende-Aufwecken
Wenn dieses Bit vom Host gesetzt wird, soll die CC in den Zustand WakeUPListen eintreten, wenn sie den Zustand CC_SoftReset verläßt, und das Aufweckmuster senden. Die CC soll jeden Versuch, den Status dieses Bit außerhalb des Zustands CC_SoftReset zu verändern, ignorieren. (Siehe die Abschnitt „Wecken eines Kanals")
Aufweckkanalauswahl
Mit diesem Bit (vWakeupChannel) wählt der Host den Kanal, auf dem die CC das Aufweckmuster senden soll („0" = Kanal A, „1" = Kanal B). Die CC soll jeden versuch, den Status dieses Bit außerhalb des Zustands CC_SoftReset zu ändern, ignorieren. (Siehe den Abschnitt „Wecken eines Kanals")
Auswahl – Ereignisgetriggerter Modus
Wenn dieses Bit vom Host gesetzt wird, soll die CC im ereignisgetriggerten Modus arbeiten. Dieses Bit soll als Vorgabe zurückgesetzt sein (= zeitgesteuerter Modus) und die CC soll jeden Versuch, den Status dieses Bit außerhalb des Zustands CC_SoftReset zu verändern, ignorieren.
Annahme Externer Trigger
Wenn dieses Bit vom Host gesetzt wird, soll die CC einen externen Trigger zum Senden des Ereignisanzeigesymbols und des statischen sync-Rahmens im ereignisgetriggerten Modus annehmen, wenn die CC als Master konfiguriert ist (Master-Auswahlbit gesetzt). Die CC soll jeden Versuch, den Status dieses Bit außerhalb des Zustands CC_SoftReset zu ändern, ignorieren.
Nachrichten-/Rahmen-ID-Filterung
Wenn dieses Bit (gMsgIdFilter) vom Host gesetzt wird, soll die CC die konfigurierte Nachrichten-ID-Filterung für alle fest zugeordneten Empfangs- und FIFO-Empfangs-Mailbox-Puffer wie im Abschnitt 0 beschrieben anwenden. Wenn dieses Bit nicht gesetzt ist (Vorgabe) soll die CC die Rahmen-ID-Filterung anwenden. Die CC soll jeden Versuch, den Status dieses Bit außerhalb des Zustands CC_SoftReset zu ändern, ignorieren. Es soll in allen Knoten eines Clusters identisch konfiguriert werden.
byteflight-Kompatibilitätsmodus
Dieses Bit wählt den byteflight-Kompatibilitätsmodus, wenn es gesetzt ist. Die CC soll jeden Versuch, den Status dieses Bit außerhalb des Zustands CC_SoftReset zu ändern, ignorieren.
FIFO-Größe
Die CC soll ein Register zum Konfigurieren der Anzahl der FIFO-Empfangspuffer als Teil aller verfügbaren Nachrichtenpuffer bereitstellen. Die CC soll jeden Versuch, den Inhalt des Registers außerhalb von CC_SoftReset zu ändern, ignorieren. (Siehe unten).
Zeitsteuerungsparameter
Die CHI soll drei Register zum Konfigurieren der Zeitsteuerungsparameter TCR1, TCR2, TCR3 bereitstellen, die für den byteflight-Kompatibilitätsmodus erforderlich sind. Diese Parameter werden nicht in allen anderen Betriebsarten der CC verwendet.
TCR1
8 Bit; zum Konfigurieren des Zeitsteuerungsparameters pdWx0Rx, einer konstanten Komponente von vdWaitTime in dem dynamischen Teil, falls die letzte Busaktivität durch den lokalen Knoten empfangen wurde; kann nur in CC_SoftReset modifiziert werden.
TCR2
8 Bit; zum Konfigurieren des Zeitsteuerungsparameters pdWx0Tx, einer konstanten Komponente von vdWaitTime in dem dynamischen Teil, falls die letzte Busaktivität durch den lokalen Knoten gesendet wurde; kann nur in CC_SoftReset modifiziert werden.
TCR3
10 Bit; zum Konfigurieren des Zeitsteuerungsparameters gdWxDelta, eines Multiplikatorteils vdWaitTime. Der gewählte Wert muß für alle Knoten in dem Cluster identisch sein und kann nur in CC_SoftReset modifiziert werden. Er soll folgendermaßen berechnet werden:
gdWxDelta = gdMaxPropagationDelay + gdMaxTolerances
Taktvorskalierer
Die CC soll ein Taktvorskaliererregister bereitstellen, das aus den folgenden drei Feldern besteht:
Bitratenindex, 4 Bit
Abtasttaktvorskalierer, 4 Bit
Abtastwerte pro Bit, 2 Bit (8 oder 10 Abtastwerte; 01_b = 8, 10_b = 10 Abtastwerte)
(Siehe den Abschnitt „Codierung und Decodierung – Konfigurationsparameter" für Einzelheiten)
Die CC soll Modifikationen des Registers nur in CC_SoftReset akzeptieren.
Maximales Oszillatordriften
Die CC soll ein 16-Bit-Register zum Halten der maximalen erwarteten Taktabweichung des Oszillators während eines Kommunikationszyklus (gdMaxDrift) in Mikroticks bereitstellen, das nur in CC_SoftReset konfigurierbar ist.
Abtastwert-Wähl-Offset
Die CC soll ein 4-Bit-Register zum Konfigurieren des Offsets vom Start des Wählfensters (pVotingOffset) bereitstellen, mit dem der Wert eines empfangenen Bit vom Start der Bitzelle bestimmt wird. Dieses Offset definiert den ersten Abtastwert des Bit, der für das Wählen betrachtet werden soll; nur in CC_SoftReset konfigurierbar. (Siehe den Abschnitt „Bitwert-Wählen")
Wähl-Abtastwerte
Die CC soll ein 4-Bit-Register zum Konfigurieren der Anzahl der Abtastwerte in dem Wählfenster (pVotingSamples) bereitstellen, mit denen der Wert eines empfangenen Bit bestimmt wird; nur in CC_SoftReset konfigurierbar. (Siehe den Abschnitt „Bitwert-Wählen")
Nominale Makrotick-Länge
Die CC soll ein 8-Bit-Register zum Halten der nominalen (unkorrigierten) Anzahl der Mikroticks pro Makrotick (pMicroPerMacroNom) bereitstellen; kann nur in CC_SoftReset modifiziert werden.
Buswächter-Tick
Die CC soll ein 4-Bit-Register zum Konfigurieren der Länge des Buswächter-Ticks (BGT) bereitstellen, die durch die CC dem Buswächter in vielfachen des CC-Mikroticks zugeführt werden soll; nur in CC_SoftReset konfigurierbar.
Statische Schlitzlänge
Die CC soll ein 8-Bit-Register zum Konfigurieren der Dauer eines statischen Schlitzes (gdSlot) in Minischlitzen bereitstellen; kann nur in CC_SoftReset modifiziert werden. Die statische Schlitzlänge muß in allen Knoten eines Clusters identisch sein.
Statische Rahmendatenlänge
Die CC soll ein 7-Bit-Register zum Konfigurieren der (festen) Rahmenlänge (gPayloadLengthStatic) für alle im statischen Teil gesendeten Rahmen in Doppelbyte bereitstellen; kann nur in CC_SoftReset modifiziert werden. Die statische Schlitzlänge muß in allen Knoten eines Clusters identisch sein.
Anzahl der statischen Schlitze
Die CC soll ein 12-Bit-Register zum Konfigurieren der Anzahl der statischen Schlitze in einem Zyklus (gNumberOfStaticSlots) bereitstellen; kann nur in CC_SoftReset modifiziert werden. Die statische Schlitzlänge muß in allen Knoten eines Clusters identisch sein.

• Zykluslänge

Die CC soll ein 16-Bit-Register zum Konfigurieren der Dauer eines Kommunikationszyklus (gMinislotPerCycle) in Minischlitzen bereitstellen; kann nur in CC_SoftReset modifiziert werden. Die Zykluslänge muß in allen Knoten eines Clusters identisch sein.
Netzwerkleerlaufzeit
Die CC soll ein 8-Bit-Register zum Konfigurieren der Dauer der Netwzerkleerlaufzeit (gdNetworkIdle) am Ende des Kommunikationszyklus in Minischlitzen bereitstellen; kann nur in CC_SoftReset modifiziert werden.
Start des spätesten Sendens
Die CC soll ein 16-Bit-Register zum Konfigurieren des maximal zulässigen Minischlitzwerts (pdLatestTX) vor dem Sperren neuer Rahmenübertragungen in dem dynamischen Teil des Zyklus, ausgedrückt über Minischlitze vom Anfang des Zyklus, bereitstellen; kann nur in CC_SoftReset modifiziert werden.
Übertragungsstartsequenzdauer
Die CC soll ein 4-Bit-Register zum Konfigurieren der Dauer der Übertragungsstartsequenz (TSS) (gdTransmissionStartSequence) über Bitzeiten (gdBit) bereitstellen; kann nur in CC_SoftReset modifiziert werden und soll in allen Knoten eines Clusters identisch sein.
Symbolfensterlänge
Die CC soll ein 8-Bit-Register zu konfigurierender Länge des Symbolfensters in Minischlitzen bereitstellen; kann nur in CC_SoftReset modifiziert werden.
Mediumzugriffs-Prüfzykluszähler
Die CC soll ein 6-Bit-Register zum Konfigurieren des Zykluszählerwerts (pMATestCycle) bereitstellen, worin die CC periodisch das Mediumzugriffsprüfsymbol (MTS) senden soll, um die Mediumzugriffsprüfung durchzuführen.
Mediumzugriffsprüfungsfreigabe
Die CC soll ein Konfigurations-Flag (pMATestEnable) zum Freigeben der CC zur periodischen Durchführung der Mediumzugriffsprüfung, wenn das Bit gesetzt ist, bereitstellen. Das Flag soll als Vorgabe zurückgesetzt sein und kann nur in CC_SoftReset modifiziert werden.
Akzeptanz externer Taktkorrektur
Die CC soll ein Konfigurationsflag bereitstellen, um externe Taktkorrektur zu erlauben, wenn es gesetzt ist. Das Flag soll als Vorgabe nach einem Einschaltrücksetzen zurückgesetzt sein und kann nur in CC_SoftReset modifiziert werden. Die CC soll die externen Taktkorrekturen ignorieren, wenn dieses Bit nicht gesetzt ist.
Maximale Offsetkorrektur
Die CC soll ein 8-Bit-Register zum Halten des maximal zulässigen Offsetkorrekturwerts (gOffsetCorrectionOut) bereitstellen, der während des regulären Taktsynchronisationsalgorithmus angewandt wird; kann nur in CC_SoftReset modifiziert werden. Die CC prüft die Summe der internen und externen Offsetkorrektur im Vergleich zu dem Parameter gOffsetCorrectionOut. (Siehe den Abschnitt „Korrekturtermberechnung – Wertebegrenzungen")
Maximale Anfangsoffsetkorrektur
Die CC soll ein 8-Bit-Register zum Halten des Anfangsoffsetkorrekturwerts (gOffsetCorretionInitOut) bereitstellen, der durch den Taktsynchronisationsalgorithmus in dem Zustand IntegrationVCW angewandt werden soll; kann nur in CC_SoftReset modifiziert werden. (Siehe den Abschnitt „Zustand CC_IntegrationVWC")
Maximale Ratenkorrektur
Die CC soll ein 8-Bit-Register zum Halten des maximal zulässigen Ratenkorrekturwerts (gRateCorretionOut) zur Anwendung durch den internen Taktsynchronisationsalgorithmus bereitstellen; kann nur in CC_SoftReset modifiziert werden. Die CC prüft die Summe der internen und externen Ratenkorrektur im Vergleich zu dem Parameter gRateCorretionOut. (Siehe den Abschnitt „Korrekturtermberechnung – Wertebegrenzungen")
Clusterdrift-Dämpfung
Die CC soll ein 4-Bit-Register zum Halten des Cluster-Drift-Dämpfungswerts (pClusterDriftDamping) bereitstellen, der bei der Taktsynchronisation zur Minimierung der Akkumulation von Rundungsfehlern benutzt wird; nur in CC_SoftReset konfigurierbar. (Siehe den Abschnitt „Berechnung des Ratenkorrekturwerts")
Buswächter-Freigabe-Dauer für BGSM
Die CC soll ein 12-Bit-Register zum Konfigurieren der Dauer (pBgenStaticDuration) des Buswächter-Freigabe-Signals für die Übertragungsphase eines statischen Schlitzes in Makroticks bereitstellen. Dies soll durch die CC im Vergleich zu dem durch den Buswächter produzierten BGE-Signal geprüft werden; kann nur in CC_SoftReset modifiziert werden. (Siehe den Abschnitt „BG-Ablaufsteuerungsüberwachungsdienst")
Buswächter-Dynamisches-Segment-Freigabe-Dauer für BGSM
Die CC soll ein 16-Bit-Register zum Konfigurieren der Dauer (pBgeDynamicDuration) des Buswächter-Freigabe-Signal für die Übertragungsphase des dynamischen Segments in Makroticks bereitstellen. Dies soll durch die CC im Vergleich zu dem durch den Buswächter produzierten BGE-Signal geprüft werden; kann nur in CC_SoftReset modifiziert werden. (Siehe den Abschnitt „BG-Ablaufsteuerungsüberwachungsdienst")
Buswächter-Symbolfenster-Freigabe-Dauer für BGSM
Die CC soll ein 8-Bit-Register zum Konfigurieren der Dauer (pBgeSymbolDuration) des Buswächter-Freigabe-Signals für die Übertragungsphase des Symbolfensters in Makroticks bereitstellen. Dies soll durch die CC im Vergleich zu dem durch den Buswächter produzierten BGE-Signal geprüft werden; kann nur in CC_SoftReset modifiziert werden. (Siehe den Abschnitt „BG-Ablaufsteuerungsüberwachungsdienst")
BG-Ablaufsteuerungsüberwachung im Symbolfenster
Die CC soll ein Konfigurationsflag (pBgsmSymWinDisabled) zum Sperren der Buswächterablaufsteuerungsüberwachung während des Symbolfensters, wenn gesetzt, bereitstellen; kann nur in CC_SoftReset modifiziert werden. (Siehe den Abschnitt „BG-Ablaufsteuerungsüberwachungsdienst")
BG-Ablaufsteuerungsüberwachung im dynamischen Segment
Die CC soll ein Konfigurationsflag (pBgsmDynSegDisabled) zum Sperren der Buswächterablaufsteuerungsüberwachung während des dynamischen Segments, wenn gesetzt, bereitstellen; kann nur in CC_SoftReset modifiziert werden. (Siehe den Abschnitt „BG-Ablaufsteuerungsüberwachungsdienst")
Timer-Interrupt-Konfigurationsregister
Die CC soll zwei Timer-Interrupt-Konfigurationsregister bereitstellen, um es dem Host zu ermöglichen, zwei verschiedene Timer-Interrupts zu konfigurieren. Jedes Register soll drei Felder enthalten: Zyklusmenge – ein 9-Bit-Register dient zum Spezifizieren, in welcher Menge von Zyklen der Interrupt auftreten soll. Es besteht aus zwei Feldern, dem Basiszyklus [b] und der Zykluswiederholung [c]. Die Menge von Zyklusnummern, an denen der Interrupt erzeugt werden soll, wird aus diesen beiden Feldern unter Verwendung der folgenden Formel bestimmt:
b + n·2^c (n = 0, 1, 2, ...)

Basiszyklus [b] – eine 6-Bit-Zykluszahl, mit der der Anfangswert zur Erzeugung der Zyklusmenge identifiziert wird
Zykluswiederholung [c] – ein 3-Bit-Wert, mit dem ein zu dem Basiszyklus (c = 0 ... 6) zu addierender konstanter Wiederholungsfaktor bestimmt wird.

Makrotick-Offset – dieser 16-Bit-Wert ist das Makrotickoffset vom Anfang des Zyklus, wo der Interrupt auftreten soll. Der Interrupt tritt an diesem Offset für jeden Zyklus in der Interrupt-Zyklusmenge auf.
Schalter Sender-erzeugtes Stopfen
In der CC entscheidet ein Konfigurationsschalter, ob der Sender fehlende Datenbyte hinzufügen kann, wenn die konfigurierte Rahmendatenmenge die Länge des Pufferdatenfelds überschreitet. Der Konfigurationsschalter gilt für alle Sendepuffer der CC. Das Flag soll als Vorgabe gesperrt sein (logisch „0"), kann nur in CC_SoftReset freigegeben (logisch „1") werden.
Kaltstart-Max
Die CC soll ein 8-Bit-Register zum Konfigurieren der maximalen Anzahl von Zyklen(gColdStartMax) bereitstellen, für die ein kaltstartender Knoten versuchen darf, das Netzwerk heraufzufahren, ohne irgendeine gültige Antwort von einem anderen Knoten zu empfangen; nur in CC_SoftReset konfigurierbar. Wenn der Wert „0" ist, darf die CC die Kommunikation nicht herauffahren.
Kaltstart-Sperrung
Die CC soll ein Konfigurationsflag (vColdStartInhibit) zum Sperren des Kaltstartens eines Knotens während des Aufweckens, wenn gesetzt, bereitstellen. (Siehe den Abschnitt „ColdStart-Sperrmodus")
Max. Ohne Taktkorrektur passiv
Die CC soll ein 4-Bit-Register bereitstellen, das mit der Anzahl von Zyklen ohne Durchführung von Ratenkorrektur (gMaxWithoutClockCorrectionPassive) konfigurierbar ist, wenn die CC in den Zustand „gelb" eintreten soll. Das Register kann nur in CC_SoftReset konfiguriert werden. (Siehe den Abschnitt „Fehlerbehandlung für die Protokollmodi TT-D und TT-M")
Max. Ohne Taktkorrektur fatal
Die CC soll ein 4-Bit-Register bereitstellen, das mit der Anzahl von Zyklen ohne Durchführung von Ratenkorrektur (gMaxWithoutClockCorrectionFatal) konfigurierbar ist, wenn die CC in den Zustand „rot" eintreten soll. Das Register kann nur in CC_SoftReset konfiguriert werden. (Siehe den Abschnitt „Fehlerbehandlung für die Protokollmodi TT-D und TT-M")
Aufwecksymboldefinitionsregister
Die CHI soll die folgenden Register zum Konfigurieren der von der CC benötigten Parameter zum Senden und Empfangen des Aufwecksymbols bereitstellen:
6 Bit; zum Konfigurieren der Dauer des Aktiv-Low-Pegels (gdWakeupSymbolTxLow) des Aufwecksymbols in Vielfachen von Bitzeiten (gdBit); kann nur in CC_SoftReset modifiziert werden.
8 Bit; zum Konfigurieren der Dauer des Aktiv-High-Pegels (gdWakeupSymbolTxIdle) des Aufwecksymbols in Vielfachen von Bitzeiten (gdBit); kann nur in CC_SoftReset modifiziert werden.
4 Bit; zum Konfigurieren der Anzahl von Wiederholungen (Sequenzen) (gdWakeupPattern) des Aufwecksymbols; kann nur in CC_SoftReset modifiziert werden.
6 Bit; zum Konfigurieren der minimalen Dauer des Aktiv-Low-Pegels (gdWakeupSymbolRxLow) in Vielfachen von Bitzeiten (gdBit) für den Empfänger zum Erkennen des Symbols als ein Aufwecken; kann nur in CC_SoftReset modifiziert werden.
6 Bit; zum Konfigurieren der minimalen Dauer des Leerlauf-/Rezessiv-High-Pegels (gdWakeupSymbolRxIdleMin) in Vielfachen von Bitzeiten (gdBit) für den Empfänger zum Erkennen des Symbols als ein Aufwecken; kann nur in CC_SoftReset modifiziert werden.
9 Bit; zum Konfigurieren der Fensterlänge, in der das Symbol empfangen werden muß (gdWakeupSymbolRxWindow) in Vielfachen von Bitzeiten (gdBIt) für den Empfänger zum Erkennen des Symbols als ein Aufwecken; kann nur in CC_SoftReset modifiziert werden.
4 Bit; zum Konfigurieren, wie oft (gWakeupMax) die CC autonom versuchen darf, ein Aufweckmuster zu senden; kann nur in CC_SoftReset modifiziert werden.
6 Bit; zum Konfigurieren in Vielfachen von Bitzeiten (gdBit) der Dauer des Aktiv-Low-Pegels auf dem Bus (gdWakeupMaxCollision), die eine ein Aufweckmuster sendende CC während der Leerlaufphase des Musters akzeptieren soll, ohne wieder in den Zustand WakeupListen einzutreten; kann nur in CC_SoftReset modifiziert werden.
(Siehe den Abschnitt „Cluster-Aufwecken"0)
Kommunikationsverzögerungsregister
Die CC soll zwei 8-Bit-Register zum Konfigurieren der mittleren Verzögerungskompensationswerte für jeden Kanal (pDelayCompensationChx) in Mikroticks bereitstellen; nur in CC_SoftReset konfigurierbar. (Siehe den Abschnitt „Zeitmessung")
Puffersteuerregister
Die Konfiguration der Nachrichten-Mailbox-Puffer (als Sende-/fest zugeordnete Empfangs- oder FIFO-Empfangspuffer) und der Zugriff des Hosts auf die Mailbox-Nachrichtenpuffer soll durch Verwendung eines Puffersteuerregisters gesteuert werden. (Siehe unten für Implementierungsrichtlinien)
Taktkorrekturregister
Dieser Abschnitt zählt die Register auf, die die Kommunikationssteuerung bereitstellen soll, um externe Taktkorrektur durch den Host zu erlauben. Der Host soll Schreib- und Lesezugriff auf diese Register besitzen.
Die CC soll während des Normalbetriebs nur Lesezugriff besitzen. Die CC soll die Konfigurationsdaten während des Einschalt-Rücksetzens zurücksetzen.
Externe Offsetkorrektur
Die CC soll ein 8-Bit-Register zum Halten des externen Taktoffsetkorrekturwerts (vOffsetCorrectionExtern) in Mikroticks bereitstellen, der durch den internen Taktsynchronisationsalgorithmus anzuwenden ist, wenn das Externe-Taktkorrektur-Akzeptanz-Bit gesetzt ist (siehe oben). Der Registerinhalt soll durch den Host vor dem Start der Netzwerkleerlaufzeit (NIT) geschrieben werden und soll aufgebraucht werden, wenn er durch die CC angewandt wird. (Siehe den Abschnitt „Externe Taktsynchronisation (optional)")
Externe Ratenkorrektur
Die CC soll ein 8-Bit-Register zum Halten des externen Taktratenkorrekturwerts (vRateCorrectionExtern) in Mikroticks bereitstellen, der durch den internen Taktsynchronisationsalgorithmus anzuwenden ist, wenn das Externe-Taktkorrektur-Akzeptanz-Bit gesetzt ist (siehe oben). Der Registerinhalt soll durch den Host vor dem Start der Netzwerkleerlaufzeit (NIT) geschrieben werden und soll aufgebraucht werden, wenn er durch die CC angewandt wird. (Siehe den Abschnitt „Externe Taktsynchronisation (optional)")
Nachrichtenpuffer
Die Kommunikationssteuerung muß eine implementierungsspezifische Anzahl konfigurierbarer Nachrichtenpuffer für die Datenkommunikation mit einer implementierungsspezifischen Rahmenlänge von bis zu dem Maximum von 254 Datenbyte bereitstellen. Die Nachrichtenpuffer sollen zur Verwendung als Sende-, fest zugeordnete Empfangs- oder FIFO-Empfangspuffer konfigurierbar sein.
Jeder Puffer soll den vollständigen Rahmenkopfteil und das Datenfeld enthalten und soll nicht die Rahmen-CRC enthalten (siehe den Abschnitt „FlexRay-Rahmenformat" für Einzelheiten). Die CC soll geeignete Mechanismen zum Gewähren eines sicheren Zugriffs auf die Puffer bereitstellen. Unter Verwendung eines geeigneten Mechanismus soll entweder die CC oder der Host Zugang zu einem bestimmten Puffer erhalten. Eine vordefinierte Anzahl von Puffer soll nur während CC_SoftReset konfigurierbar sein, während die anderen während der Laufzeit umkonfigurierbar sein sollen.
Sendepuffer
Ein Teil der Nachrichtenpuffer soll als Sendepuffer konfigurierbar sein.
Es soll einen expliziten Sendepuffer geben, der fest dafür zugeordnet ist, dafür konfiguriert zu sein, den übertragenen sync-Rahmen eines Knotens zu halten, wenn er einen sendet, und der nur in CC_SoftReset umkonfiguriert werden kann. Dadurch soll sichergestellt werden, daß für Sync-Rahmen Sync-Rahmen-ID, Sync-Bit, Nutzsignallänge und die entsprechende Kopfteil-CRC nur während CC_SoftReset verändert werden können und daß jeder Knoten höchstens einen sync-Rahmen pro Kommunikationszyklus sendet. Die CC soll Mechanismen bereitstellen, die die Übertragung von sync-Rahmen von anderen Puffern nicht erlauben.
Für Senderahmen in dem dynamischen Segment können umkonfigurierbare Puffer verwendet werden. Rahmen-ID, Kopfteil-CRC und die entsprechende Nutzsignallänge sollen während der Laufzeit umkonfigurierbar sein.
CC soll nicht dazu fähig sein, die Sende-Kopfteil-CRC zu berechnen. Es wird vom Host angenommen, daß er die Rahmen-IDs und Kopfteil-CRCs für alle übertragenen Rahmen bereitstellt.
Die CC soll keinen Schreibzugriff durch den Host auf das Nullrahmen-Anzeigebit gestatten.
Das Längenfeld in allen Nachrichten (statisch und dynamisch) gibt die in dem Rahmenformat definierte Rahmennutzsignaldatenlänge wieder. Die CC kann kürzere Mailbox-Sendepufferstrukturen als die tatsächlich konfigurierte Datenrahmenlänge in dem statischen Segment benutzen. In diesem Fall soll die CC Stopfbyte erzeugen (falls freigegeben), um sicherzustellen, daß Rahmen eine ordnungsgemäße physische Länge aufweisen. Diese Fähigkeit muß jedoch über Konfiguration freigegeben werden (siehe oben). Das Stopfmuster soll logisch Null sein. Die Stopffunktion soll nur für in dem statischen Teil zu übertragende Rahmen gelten. In dem dynamischen Teil soll kein Rahmen übertragen werden, wenn das Datenfeld in dem Puffer kürzer als die konfigurierte Datenmenge ist.
Für jeden Sendenachrichtenpuffer soll ein Anzeiger bereitgestellt werden, um anzuzeigen, ob die Nachricht durch die CC gesendet wurde (jeweils durch den Host aktualisiert). Der Host soll explizit dieses „Commit"-Flag setzen, wenn der Puffer bereit zur Übertragung ist. In dem „Single-shot-Modus" soll die CC das Flag zurücksetzen, nachdem die Übertragung abgeschlossen wurde und der Host zum Schreiben der nächsten Nachricht in den Puffer auf den Puffer zugreifen kann. Dieses Handshaking-Flag soll beim Übergang der CC von dem Zustand CC_HWReset zurückgesetzt werden (siehe den Abschnitt „der Zustand CC_HWReset").
Die CC soll aus einem Puffer, den der Host aktualisiert, keine Rahmendaten übertragen. Die CC soll die Nachrichtendaten aus dem Puffer heraus senden, bevor der Host angezeigt hat, daß die Aktualisierung abgeschlossen ist, indem das „Commit"-Flag gesetzt wird.
Nullrahmenübertragung
Die CHI soll für jeden Sendepuffer ein Flag vorsehen, um es dem Host zu erlauben, den Übertragungsmodus für den Puffer zu konfigurieren. Wenn dieses Bit gesetzt ist, soll der Sender in dem statischen Segment in dem sogenannten „Single-shot-Modus" arbeiten. Wenn dieses Bit gelöscht ist, soll der Sender in dem statischen Segment in dem sogenannten „kontinuierlichen Modus" arbeiten.
Wenn ein Puffer in dem „Single-shot-Modus" konfiguriert ist, wird der konfigurierte Rahmen durch den Sender erst dann herausgesendet, nachdem der Host das „Commit"-Flag gesetzt hat. Wie oben definiert, setzt die CC das Flag nach der Übertragung zurück. Wenn der Hast das „Commit"-Flag nicht vor der Sendezeit setzt und es keinen anderen Sendepuffer mit übereinstimmender Rahmen-ID und übereinstimmendem Zykluszählerfilter gibt, soll die CC einen Nullrahmen mit gesetztem Nullrahmenbit (fNullFrameIndicationBit) und mit auf „0" gesetzten Nutzsignaldaten senden.
Wenn ein Puffer in dem „kontinuierlichen Modus" konfiguriert ist, soll die CC das „Commit"-Flag nach der Übertragung nicht zurücksetzen. Wenn das „Commit"-Flag gesetzt ist, soll der Rahmen zu einem beliebigen Zeitpunkt, wenn Rahmen-ID und Zykluszählerfilter übereinstimmen, ausgesendet werden. Wenn der Host das „Commit"-Flag löscht und es keinen anderen Sendepuffer mit übereinstimmender Rahmen-ID und übereinstimmendem Zykluszählerfilter gibt, soll die CC einen Nullrahmen mit gesetztem Nullrahmenbit (fNullFrameIndicationBit) und gelöschten Nutzsignaldaten senden.
Wenn ein statischer Schlitz der CC zugewiesen ist, soll sie einen Nullrahmen mit gesetztem Nullrahmenanzeigebit (fNullFrameIndicationBit) und den Rest des Rahmenkopfteils mit unveränderter Rahmenlänge (siehe den Abschnitt „Nullrahmenanzeigebit") in beliebigen der folgenden Fälle senden:
Es gibt übereinstimmende Rahmen-IDs und Zykluszähler, aber bei keinen dieser Sendepuffer ist das „Commit"-Flag gesetzt. Alle Sendepuffer, die für den Schlitz konfiguriert sind, besitzen Zyklusfilter, die nicht mit dem aktuellen Zyklus übereinstimmen (siehe unten).
Nullrahmen sollen in dem dynamischen Segment nicht gesendet werden.
Empfangspuffer
Ein Teil der Nachrichtenpuffer der CC soll als fest zugeordneter Empfangspuffer konfigurierbar sein.
Die CC soll nur gültige empfangene Nachrichten aus dem seriellen Empfangsnachrichtenpuffer zu dem fest zugeordneten Empfangspuffer mit der übereinstimmenden Filterkonfiguration transferieren (siehe unten).
Ein Empfangsnachrichtenpuffer soll Platz für alle in dem Kapitel „Rahmenformate" definierten Rahmenelemente enthalten, mit Ausnahme der Rahmen-CRC.
Die dem Host vorgelegten Nutzsignallängeninformationen sollen die durch den empfangenen Nutzsignallängencode angegebene Länge wiedergeben, und keinen anderen Wert.
Wenn kein Rahmen, Nullrahmen oder verfälschter Rahmen in einem Schlitz empfangen wird, soll der Pufferinhalt vor dem Empfang nicht gelöscht oder überschrieben werden. Die Diskrepanz zu dem konfigurierten Rahmen soll dem Host unter Verwendung eines geeigneten Bit in dem entsprechenden Pufferstatusregister signalisiert werden.
Es soll ein Anzeiger für jeden fest zugeordneten Empfangsnachrichtenpuffer bereitgestellt werden, um anzuzeigen, ob er neue Daten (aktualisiert durch die CC seit dem letzten Lesen) enthält. Der Host ist für das Löschen dieses Flags nach der Leseoperation verantwortlich.
Die CC soll keine Rahmendaten in einem fest zugeordneten Empfangspuffer speichern, den der Host gerade liest.
Der Host soll während des Normalbetriebs keinen Schreibzugriff auf die fest zugeordneten Empfangspuffer besitzen. Der Host soll nur während der Konfigurierung des Puffers in CC_SoftReset mit den notwendigen Parametern für den fest zugeordneten Empfangsprozeß Schreibzugriff auf die fest zugeordneten Empfangspuffer besitzen.
Nullrahmenempfang
Das Nutzsignal eines empfangenen Nullrahmens soll nicht in den passenden Mailbox-Empfangspuffer kopiert werden. Der Empfang des Nullrahmens soll dem Host durch Setzen eines entsprechenden Bit in dem Empfangspufferstatusregister signalisiert werden. (Siehe unten)
FIFO-Empfangspuffer
Ein Teil der Nachrichtenpuffer der CC kann als FIFO-Empfangspuffer konfiguriert werden.
Die CC soll nur gültige empfangene Nachrichten aus dem seriellen Empfangsnachrichtenpuffer in den FIFO-Empfangspuffer transferieren, wenn kein passender fest zugeordneter Empfangspuffer existiert und der Kopfteil nicht durch das FIFO-Zurückweisungsfilter zurückgewiesen wird (siehe unten).
Ein FIFO-Empfangsnachrichtenpuffer soll alle in dem Kapitel „Rahmenformate" definierten Rahmenelemente enthalten, mit Ausnahme der Rahmen-CRC.
Es soll ein Anzeiger bereitgestellt werden, um anzuzeigen, daß die CC eine Nachricht in einem FIFO-Empfangspuffer gespeichert hat. Der Anzeiger soll die Information „FIFO nicht leer" bereitstellen. Die CC soll das Flag zurücksetzen, nachdem der Host auf alle Nachrichten zugegriffen hat.
Die CC soll keine Rahmendaten in einem FIFO-Empfangspuffer speichern, den der Host gerade liest. Die Daten sollen in den nächsten freien FIFO-Puffer geschrieben werden.
Rahmenstatus- und Fehlerinformationen (FSEI)
Es soll mit jedem Nachrichtenpuffer assoziierte fest zugeordnete Rahmenstatus- und Fehlerinformationen geben. Die Rahmenstatus- und Fehlerinformationen enthalten 8 Bit, die in der folgenden Tabelle 54 zusammengefaßt sind:
Tabelle 54: Rahmenstatus- und Fehlervektor
Der Vektorinhalt soll am Ende des entsprechenden Schlitzes (definiert durch die konfigurierte Rahmen-ID, siehe den Abschnitt „Rahmenstatus- und Fehlerinformationen (FSEI)") durch die Kommunikationssteuerung aktualisiert werden und kann vom Host geprüft werden. Die Flags sollen gesetzt werden, wenn die Kommunikationssteuerung einen der aufgelisteten Fehler während der Rahmenakzeptanzprüfungen erkennt. (Siehe das Kapitel „Rahmenverarbeitung") Der Vektorinhalt soll immer den Status des letzten Schlitzes zeigen, so daß also Fehler aus vorherigen Zyklen überschrieben werden.
Die ersten sieben Flags beziehen sich spezifisch auf den konfigurierten Kanal, auf dem der Rahmen empfangen werden soll (siehe unten), während sich die anderen beiden auf den anderen Kanal beziehen.
Beim Suchen nach Rahmen-ID-Übereinstimmung soll das Suchen mit dem ersten Empfangspuffer beginnen. Es soll inkrementell durch die übrigen Empfangspuffer voranschreiten. Wenn mehr als ein Empfangspuffer dieselbe Rahmen-ID und denselben Zykluszählerfilter hält, soll der Fehlervektor in dem ersten übereinstimmenden Puffer aktualisiert werden.
Filterung und Maskierung
Definitionen
Rahmenfilterung
Rahmenfilterung soll durch Prüfen spezifischer Felder in einem Rahmen im Vergleich zu entsprechenden Konfigurationskonstanten in dem Puffer geschehen, mit der Vorgabe, daß der empfangene Rahmen nur dann weiterverarbeitet werden soll, wenn die erforderlichen Übereinstimmungen auftreten. Andernfalls soll er verworfen werden. Rahmen sollen an den folgenden Rahmenfeldern gefiltert werden:

• Kanalnummer
• Rahmen-ID
• Zykluszähler
• Nachrichten-ID

Rahmenfiltermaske
Die CC soll einen Mechanismus zum Maskieren der Rahmenfilter bereitstellen. Die vom Host maskierten Filterungsparameter sollen verworfen werden (Setzen auf „don't care").
Filterungsmechanismen
Die nachfolgend beschriebenen Filterungsmechanismen sollen für Empfangs- und Sendenachrichtenpuffer verschieden angewandt werden. Empfangspuffer: Um eine Nachricht zu speichern, müssen die Filter für Kanal-ID und Zykluszähler übereinstimmen. Abhängig von dem Konfigurationsbit gMsgIdFilter (siehe Abschnitt 0) müssen zusätzlich entweder die Rahmen-Id (gMsgIdFilter = „0") oder die Nachrichten-ID (gMsgIdFilter = „1") übereinstimmen (aber nicht beides).
Sendepuffer: Ein Rahmen soll in dem Zeitschlitz gesendet werden, der der Rahmen-ID auf dem konfigurierten Kanal bzw. den konfigurierten Kanälen entspricht, wenn der Zykluszähler mit dem konfigurierten Zyklusfilterwert übereinstimmt.
Kanalfilterung
Mit jedem Puffer soll ein Kanalfilterungsfeld (2 Bit) assoziiert sein. Es dient als ein Filter für einen Empfangsnachrichtenpuffer und als ein Steuerfeld für einen Sendenachrichtenpuffer.
Abhängig von der Pufferkonfiguration (siehe Tabelle 55), Empfangspuffer: Empfangene Rahmen sollen gespeichert werden, wenn sie auf allen spezifizierten in dem Kanalfilterungsfeld empfangen werden. Außerdem müssen Filterungskriterien erfüllt sein.
Sendepuffer: Der Inhalt des Puffers wird nur auf den in dem Kanalfilterungsfeld spezifizierten Kanälen gesendet, wenn die Kriterien der Zykluszählerfilterung und Rahmen-ID-Filterung auch erfüllt sind.
Tabelle 55: Kanalfilterungskonfiguration
Rahmen-ID-Filterung
Jeder Sende- und fest zugeordnete Empfangsnachrichtenpuffer soll eine Rahmen-ID enthalten. Diese Rahmen-ID soll für Empfangs- und Sendenachrichtenpuffer verschieden verwendet werden.
Empfangsnachrichtenpuffer: Eine empfangene Nachricht wird in dem ersten Empfangsnachrichtenpuffer gespeichert, wenn die empfangene Rahmen-ID mit der Empfangs-Mailbox-Rahmen-ID übereinstimmt, so lange gMsgIdFilter = „0" gilt und die anderen Empfangsfilterungskriterien auch erfüllt sind. Wenn Nachrichten-ID-Filterung verwendet wird (gMsgIdFilter = „1"), wird dieses Filter nicht angewandt.
Für Sendepuffer wird mit der Rahmen-ID in dem Puffer der entsprechende Schlitz für die Nachrichtenübertragung bestimmt. Der Rahmen soll in dem der Rahmen-ID entsprechenden Zeitschlitz gesendet werden, so lange auch die Kanal- und Zykluszählerkriterien erfüllt sind.
Zykluszählerfilterung
Zykluszählerfilterung basiert auf dem Prinzip einer Zyklusmenge. Für Filterungszwecke soll eine Übereinstimmung erkannt werden, wenn eine Übereinstimmung mit einem beliebigen der Elemente der Menge vorliegt.
Zyklusmenge – ein 9-Bit-Register dient zum Spezifizieren, welche Zykluszahlen Elemente der Menge sind. Es besteht aus zwei Feldern, dem Basiszyklus [b] und der Zykluswiederholung [c]. Die Menge von zu der Menge gehörenden Zyklusnummern soll aus diesen beiden Feldern mit der folgenden Formel bestimmt werden:
b + n·2^c (n = 0, 1, 2, ...)

Basiszyklus [b] – eine 6-Bit-Zykluszahl, mit der der Anfangswert zur Erzeugung der Zyklusmenge identifiziert wird
Zykluswiederholung [c] – ein 3-Bit-Wert mit dem ein konstanter Wiederholungsfaktor bestimmt wird, der zu dem Basiszyklus addiert werden soll (c = 0 ... 6).

Die Funktionsweise des Filterungsmechanismus hängt von der Konfiguration des Puffers ab:
Empfangspuffer: Die empfangene Nachricht wird nur dann gespeichert, wenn der empfangene Zykluszähler mit einem Element der Zyklusmenge des Puffers übereinstimmt. Außerdem müssen Kanal-, Rahmen-ID- oder Nachrichten-ID-Kriterien erfüllt sein.
Sendepuffer: Der Inhalt des Puffers wird gesendet, wenn ein Element der Zyklusmenge mit dem aktuellen Zykluszähler übereinstimmt und die Rahmen-ID mit dem Schlitzzählerwert übereinstimmt. Wenn der Zykluszähler mit keinen Zykluszählerfilterkriterien aus den konfigurierten Sendepuffern mit übereinstimmender Rahmen-ID übereinstimmt, soll ein Nullrahmen in dem statischen Segment gesendet werden. (Siehe unten).
Nachrichten-ID-Filterung
Nachrichten-ID-Filterung gilt nur für Empfangsnachrichtenpuffer und soll von der CC benutzt werden, wenn die Nachrichten-ID-Filterung konfiguriert ist (gMsgIDFilter = „1") (siehe oben). Für Nachrichten-ID-Filterung sollen die ersten beiden Datenbyte aus dem Empfangspuffer benutzt werden, Der empfangene Rahmen soll in dem konfigurierten Empfangspuffer gespeichert werden, wenn Nachrichten-ID, Kanal- und Zykluszähler übereinstimmen. Die Rahmen-ID soll in dem Puffer gespeichert, aber für die Filterung ignoriert werden.
Für die Rahmenübertragung soll keine Nachrichten-ID-Filterung benutzt werden.
FIFO-Filterung
Zur FIFO-Filterung sollen ein Zurückweisungsfilter und eine Zurückweisungsfiltermaske verfügbar sein. Jedes Register besteht aus 39 Bit für Kanal (2 Bit), Rahmen-ID (12 Bit), Zykluszähler (9 Bit) und Nachrichten-ID (16 Bit). Die beiden Register sollen nur in CC_SoftReset umkonfigurierbar sein.
Ein empfangener Rahmen soll in dem nächsten freien FIFO-Puffer gespeichert werden, wenn Kanal, Rahmen-ID, Zykluszähler und Nachrichten-ID nicht durch das konfigurierte Zurückweisungs- und Maskierungszurückweisungsfilter zurückgewiesen werden und wenn kein übereinstimmender fest zugeordneter Empfangspuffer verfügbar ist.
Allgemeine Interrupts
Interrupts sollen fast sofort getriggert werden, wenn die Steuerung einen Fehler erkennt, ein Rahmen empfangen oder gesendet wird oder ein konfigurierter Timer-Interrupt aktiviert wird. Dadurch kann der Host sehr schnell auf spezifische Fehlerbedingungen, Timer und Ereignisse reagieren. Die CC soll Sperr-/Freigabe-Steuerungen für jeden einzelnen Interrupt separat und als ganzes unterstützen.
Verfolgung des Status und Erzeugung von Interrupts, wenn eine Statusänderung auftritt, sollen zwei unabhängige Tasks sein. Gleichgültig, ob ein Interrupt freigegeben ist oder nicht, soll der entsprechende Status verfolgt und durch die CC angezeigt werden.
Es soll mindestens eine Hardware-Interruptleitung verfügbar sein, um dem Host einen Interrupt zu signalisieren.
Allgemeines Interrupt-Register
Die Kommunikationssteuerung soll ein allgemeines Interrupt- und Fehleranzeigeregister bereitstellen.
Tabelle 56: Allgemeines Interrupt-Register
Die Flags sollen gesetzt werden, wenn die Kommunikationssteuerung einen der aufgelisteten Fehler oder Ereignisse erkennt. (Siehe den Abschnitt „Kanalstatus- und Fehlerinformationen (CSEI)" und „Rahmenempfang"). Wenn der Host den Vektor prüft, muß er die Werte zurücksetzen, so daß die CC sie aktualisieren kann.
Die Kommunikationssteuerung soll einen allgemeinen Fehlerinterrupt bereitstellen, der getriggert werden soll, wenn irgendwelche der Flags gesetzt sind, solange der entsprechende Interrupt freigegeben ist.
Allgemeines Interrupt-Freigaberegister
Die CC soll für jedes allgemeine Interrupt-Anzeigeflag ein allgemeines Interrupt-Freigabeflag bereitstellen. Die Einstellungen in dem allgemeinen Interrupt-Freigaberegister bestimmen, welche Statusänderungen in dem allgemeinen Interrupt-Register zu einem Interrupt führen sollen.
Empfangs-Interrupt-Statusregister
Die Kommunikationssteuerung soll ein Empfangs-Interrupt-Statusregister bereitstellen, um den Empfang eines gültigen Rahmens (gespeichert in einem der Empfangspuffer), eines Kollisionsvermeidungssymbols (CAS), eines Aufwecksymbols, eines Mediumzugriffs-Prüfsymbols (MTS), eines Ereignisanzeigesymbols (EIS), eines Status-Normal-Symbols (SNS), eines Status-Alarm-Symbols (SAS) oder eines optischen Diagnosesignals (bei Verwendung einer optischen flüssigen Schicht) anzuzeigen. Die Flags sollen durch die CC gesetzt werden, wenn das entsprechende Ereignis auftritt. wenn freigegeben, steht ein Interrupt an, wenn eines der Bit gesetzt ist. wenn der Host den Vektor prüft, muß er die Werte zurücksetzen, damit die CC sie aktualisieren kann.
Die folgenden Nur-Lese-Bit soll der Host lesen können:
Empfangs-Interrupt-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein Rahmen empfangen und in einem der fest zugeordneten Empfangspuffer gespeichert wurde.
Empfangs-FIFO-Nicht-Leer-Interrupt-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein Rahmen empfangen und in einem der FIFO-Puffer gespeichert wurde.
Empfangs-FIFO-Überlauf-Interrupt-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein Empfangs-FIFO-Überlauf erkannt wurde.
Kollisions-Vermeidungs-Symbol-Interrupt-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein CAS empfangen wurde.
Aufwecksymbol-Interrupt-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein Aufwecksymbol empfangen wurde.
Mediumzugriffs-Prüfsymbolflag
Das Flag soll durch die CC gesetzt werden, wenn ein MTS empfangen wurde.
Ereignisanzeigesymbol-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein EIS empfangen wurde.
Optische-Diagnose-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein optisches Diagnosesignal empfangen wurde.
Status-Normal-Symbol-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein SNS empfangen wurde.
Status-Alarm-Symbol-Flag
Das Flag soll durch die CC gesetzt werden, wenn ein SAS empfangen wurde.
Netzwerkverwaltungsvektoränderungs-Flag
Das Flag soll durch die CC gesetzt werden, wenn die optionalen NM-Dienste implementiert sind und eine Änderung des NM-Vektors aufgetreten ist. (Siehe unten)
Empfangs-Interrupt-Freigabe-Register
Die Kommunikationssteuerung soll ein Empfangs-Interrupt-Freigabe-Register bereitstellen, um jedes der Empfangs-Interrupt-Status-Register-Flags separat freizugeben. Die Einstellungen in dem Empfangs-Interrupt-Freigabe-Register bestimmen, welche Statusänderungen in dem Empfangs-Interrupt-Status-Register zu einem Interrupt führen sollen.
Allgemeines Fehler- und Status-Interrupt-Freigabe-Register
Die CC soll ein Interrupt-Freigabe-Flag bereitstellen, um jeden der folgenden Status und Fehler individuell freizugeben:
Taktkorrekturmißerfolg; dieses Flag gibt einen Interrupt immer dann frei, wenn einer der folgenden Fehler auftritt:

• Fehlende-Ratenkorrektur-Signal (MRCS)
• Fehlende-Offsetkorrektur-Signal (MOCS)
• Taktkorrektur-Mißerfolg-Zähler (CCFC), gestoppt bei 15
• Taktkorrekturgrenze erreicht (CCLR)
• Der Interrupt soll am Ende des Zyklus aufgesetzt werden, nachdem die aufgelisteten Fehler geprüft wurden.

Protokollfehlerzustand; dieses Flag gibt einen Interrupt immer dann frei, wenn der Fehlerzustand von „grün" auf „gelb" oder „rot" wechselt.
Herauffahren: dieses Flag gibt einen Interrupt immer dann frei, wenn eines der folgenden Ereignisse auftritt:

• Kaltstart-Max. erreicht
• Eintritt in den Kaltstart-Weg aufgrund des Ablaufens von pStartupNoise
• Eintritt in Normalzustand über Kaltstartweg
• Plausibilitätsprüfung erfolglos (während des Herauffahrens)

Buswächter-Ablaufsteuerungsüberwachungsfehler (BGME)
Mediumzugriffs-Prüfungswarnung
Aufwecken; dieses Flag gibt einen Interrupt immer dann frei, wenn eines der folgenden Ereignisse auftritt:

• Rahmenkopfteil während Aufwecken empfangen
• Aufwecksymbol empfangen
• Aufwecken erfolglos
• Aufwecken abgeschlossen

Die Einstellungen in dem allgemeinen Fehler- und Statusinterrupt-Freigabe-Register bestimmen, welche Status- oder Fehlerflagänderungen zu einem Interrupt führen sollen. (Siehe oben)
Anforderungen für optionale Mechanismen
Netzwerkverwaltungsdienste
Wenn NM-Dienste unterstützt werden, soll die CHI folgendes bereitstellen:

• vier Bit zum Konfigurieren der Länge des NM-Vektors (gNetworkManagementVectorLength), (0 bis 12 Byte); kann nur in CC_SoftReset modifiziert werden. Die konfigurierte Länge muß in allen Knoten eines Clusters identisch sein.
• ein Bit zum Konfigurieren des Startpunkts des NM-Vektors in dem Datenfeld (Byte 0, wenn Bit nicht gesetzt ist, Byte 2, wenn Bit gesetzt ist); kann nur in CC_SoftReset modifiziert werden. Der konfigurierte Startpunkt muß in allen Knoten eines Clusters identisch sein.
• ein Register (innerhalb der Implementierung auf 8 bis 12 Byte spezifiziert) zum Halten des NM-Vektors als Ergebnis einer logischen OR-Operation über alle empfangene NM-Vektoren in dem vorherigen Zyklus hinweg. Die CC soll die OR-Operation über alle NM-Vektoren aus allen empfangenen NM-Rahmen mit gesetztem fNMIndicationBit durchführen. (Siehe den Abschnitt „Netzwerkverwaltungsanzeigebit") Die CC soll den NM-Vektor am Ende des Zyklus aktualisieren.
• ein Interrupt-Flag, um dem Host sichtbar eine Änderung in dem NM-Vektor zu signalisieren.
• ein Interrupt-Freigabe-Bit.

Optische-Diagnose-Flags
Wenn der optische Diagnosedienst unterstützt wird, soll die CHI folgendes bereitstellen:
Zwei Optische-Diagnose-Flags (eines für jeden Kanal)
Die Flags sollen durch die CC gesetzt werden, wenn der optische Sender/Empfänger zu wenig optische Leistung empfangen hat, und sollen der CC signalisiert werden. Wenn der Host die Flags prüft, muß er sie zurücksetzen, damit die CC sie aktualisieren kann.
Implementierungsbeispiel
Mailbox-Puffersteuerungsregisterfelder
Die CHI soll ein Puffersteuerregister zur Konfiguration der Nachrichten-Mailbox-Puffer (als Sende-, fest zugeordneter Empfangs- oder FIFO-Empfangspuffer) und zur Steuerung des Hostzugriffs auf die Nachrichtenpuffer bereitstellen.
Dieses Steuerregister soll ein Byte für jeden Mailbox-Puffer bereitstellen.
Tabelle 57: Mailbox-Puffer-Steuerregisterfeld
(Anmerkung: Der Host kann die Steuerflags CFG und CFG_SR nur während CC_SoftReset modifizieren.)
Anzeige von Busereignissen
Die Kommunikationssteuerung soll zusätzliche Ausgangssignale zur Anzeige der folgenden Ereignisse bereitstellen:
Tabelle 58: Busereignisanzeige
Die genaue Zuschreibung von Ereignissen zu Interrupt-Vektoren oder -Leitungen soll in der Dokumentation der jeweiligen Kommunikationssteuerungsimplementierung beschrieben werden.
Um Fehlerüberwachung in einem Sternknoten zu ermöglichen, soll die Kommunikationssteuerung vier Ausgangssignale bereitstellen, wobei die Einstellung interner Status-Flags mittels eines Impulses angezeigt wird.
102 zeigt, welche internen Ereignisse extern als Signale SLMM, ERR, ROK und SOC angezeigt werden sollen.
Wenn ein internes Ereignis angezeigt wird, soll das entsprechende Signal eine definierte Zeit lang in den Aktiv-Zustand umgeschaltet werden, um ein kurzes logisches „1"-Signal mit einer Dauer von mindestens 50 ns zu erzeugen.
Das Signal SLMM bestätigt den Empfang eines Rahmens mit einem korrekten Format und korrekter CRC, auch wenn die Rahmenkennung von dem Schlitzzählerwert zum Zeitpunkt des Empfangs abweicht.
Das Signal ERR zeigt wie oben beschrieben einen Fehler an.
Das Signal ROK zeigt an, daß ein korrekter Rahmen oder ein gültiges Symbol empfangen wurden, obwohl die Nachricht nicht in einen Puffer in der Kommunikationssteuerung kopiert wurde.
Das Signal SOC bestätigt, daß ein gültiges SOC-Symbol (Normal oder Alarm) empfangen oder gesendet wurde. Es kann zum Triggern von Timern oder zum Starten synchronisierter Software-Tasks mit jedem SOC verwendet werden.
Jede Kommunikationssteuerung sollte in der Lage sein, mindestens die Signale ERR, ROK und SOC zu erzeugen.
Systemparameter
Die folgenden Parameter werden in der Beschreibung der vorliegenden Erfindung verwendet. Alle Werte und Bereiche der Parameter werden als Beispiel angegeben und implizieren keinerlei Einschränkung.
Protokollkonstanten
Globale Cluster-Konstanten
Clusterweite technologieabhängige Konstanten (die hier aufgelisteten Konstanten definieren inplementierungsspezifische Einschränkungen. Die spezifizierten Werte gelten für den FlexRay-Buswächter von Philips. Einschränkungen für den ungünstigsten Fall gelten für das gesamte Cluster, wenn Buswächtereinrichtungen von verschiedenen Halbleiterherstellern in einem Cluster gemischt werden).
Knotenkonstanten
Knotenvariablen
Rahmenvariablen
Ereignisanzeigen
Glossar

μT	Mikrotick
Anwendungsdaten	Durch Anwendungs-Tasks produzierte und/oder benutzte Daten. Im Automotive-Kontext wird der Begriff „Signal" häufig für zwischen Tasks ausgetauschte Anwendungsdaten benutzt.
BCA	Bittaktsynchronisation
BD	Bustreiber
BDe	Elektrischer Bustreiber
BDo	Optischer Bustreiber
BF	byteflight (Protokollmodus)
BG	Buswächter
BGME	Buswächterablaufsteuerungsüberwacherfehler (Fehlersignal)

BGSM	Buswächterablaufsteuerungsüberwacher
BSD	Bitstromdecodierung
BSS	Bytestartsequenz
Bus	Ein Kommunikationskanal in Bustopologie. Manchmal wird das Wort „Bus" als Synonym für Kommunikationskanal benutzt.
byteflight	Von BMW AG, Motorola, ELMOS, Infineon, Siemens EC, Steinbeis Transferzentrum für Prozessautomatisierung und IXXAT entwickeltes Kommunikationsnetzwerk.
CAS	Kollisionsvermeidungssymbol
CC	Kommunikationssteuerung – die Einrichtung, die das FlexRay-Protokoll implementiert
CCFC	Taktkorrektur-Erfolglos-Zähler
CCLR	Taktkorrekturgrenze erreicht (Fehlersignal)
CCMS	Kaltstartzählwertmaximumsignal (Fehlersignal)
Kanalleerlauf	Medium-Leerlauf-Bedingung, so wie sie von jedem einzelnen Knoten in dem Netzwerk wahrgenommen wird.
CHI	Steuerungshostschnittstelle
Cluster	Ein Kommunikationssystem aus zwei oder mehr Knoten, die über mindestens einen Kommunikationskanal direkt (Bustopologie) oder durch Sternkoppler (Sterntopologie) verbunden werden.
Kommunikationskanal	Die Verbindung zwischen Knoten, durch die Signale zum Zweck der Kommunikation übermittelt werden. Der Kommunikationskanal abstrahiert sowohl die Netzwerktopologie, d.h. Bus oder Stern, als auch das physische Übertragungsmedium, d.h. elektrisch oder optisch.
CRC	Zyklischer Redundanzcode
CSEI	Kanalstatus und Fehlerinformationen
Zykluszeit	Zeit für einen Kommunikationszyklus.
DTS	Dynamische Nachspannsequenz

Dynamisches Segment	Teil des Kommunikationszyklus, in dem der Medium-Zugriff über ein Minischlitzschema gesteuert wird, auch als FTDMA (Flexible Time Division Media Access) bekannt. Während dieses Segments wird der Zugriff auf das Medium dynamisch auf Prioritätsbasis Knoten mit zu sendenden Daten gewährt.
Dynamischer Schlitz	Einheit variabler Dauer zur Steuerung des Medium-Zugriffs in dem dynamischen Segment eines Kommunikationszyklus. Ein dynamischer Schlitz besteht aus einem oder mehreren Minischlitzen, bestimmt durch das Minischlitz-FTDMA-/-Minischlitz-Mediumzugriffs-Schema. Die Dauer eines dynamischen Schlitzes kann in einem gegebenen Zyklus von Schlitz zu Schlitz variieren und für einen gegebenen Schlitz von Zyklus zu Zyklus. In einem beliebigen gegebenen dynamischen Schlitz/in einer beliebigen gegebenen Kanalkombination kann nur ein Knoten senden.
EIS	Ereignisanzeigesymbol
ET	Ereignisgetriggert (Protokollmodus)
FES	Rahmenendesequenz
FIFO Rahmen	First-In, First-Out (Datenpufferstruktur) von dem Kommunikationssystem verwendete Struktur zum Austausch von Informationen innerhalb des Systems. Ein Rahmen besteht aus einem Kopfteilsegment, einem Nutzsignalsegment und einem Nachspannsegment. Das Nutzsignalsegment dient zum Übermitteln von Anwendungsdaten.
FSEI	Rahmenstatus- und Fehlerinformationen
FTDMA	Flexible Time Division Multiple Access
	(Medium-Zugriffsverfahren). Dies ist ein anderer Name für das auf Minischlitzen basierende Mediumzugriffsverfahren.
Hamming-Distanz	Minimale Distanz (d.h. Anzahl der verschiedenen Bit) zwischen zwei beliebigen Codewörtern in einem Binärcode

ICW	Anfangsprüffenster
Makrotick	Aus dem clusterübergreifenden Taktsynchronisationsalgorithmus abgeleitete Zeiteinheit. Ein Makrotick besteht aus einer ganzen Anzahl von Makroticks – die tatsächliche Anzahl der Mikroticks in einem gegebenen Makrotick wird durch den Taktsynchronisationsalgorithmus eingestellt. Der Makrotick repräsentiert die kleinste Granularitätseinheit der globalen Zeit.
Mediumleerlauf	Zustand des physischen Übertragungsmediums, wenn kein Knoten aktiv auf dem physischen Übertragungsmedium sendet
Mikrotick	Direkt aus dem Oszillator der CC abgeleitete Zeiteinheit. Der Mikrotick wird durch die Taktsynchronisationsmechanismen nicht direkt beeinflußt und ist somit ein knotenlokales Konzept. Verschiedene Knoten können Mikroticks verschiedener Dauer aufweisen.
Minischlitz	Zeiteinheit fester Dauer, die zur Steuerung des Minischlitz-/FTDMA-Mediumzugriffsschemas im dynamischen Segment verwendet wird. Ein Minischlitz besteht aus einer konfigurierbaren Anzahl von Makroticks. Alle Minischlitze in einem Zyklus besitzen dieselbe Dauer (ausgedrückt in Makroticks), und diese Dauer ist von Zyklus zu Zyklus konstant.
MOCS	Fehlende-Offsetkorrektur-Signal (Fehlersignal)
MRCS	Fehlende-Ratenkorrektur-Signal (Fehlersignal)
MT	Makrotick
MTS	Mediumzugriffs-Prüfsymbol
Netzwerktopologie	Anordnung der Verbindungen zwischen den Knoten. FlexRay unterstützt sowohl eine Bus-Netzwerktopologie als auch eine Mehrfach-Stern-Netzwerktopologie.

NIT	Netzwerkleerlaufzeit
NM	Netzwerkverwaltung
Knoten	Eine mit dem Netzwerk verbundene Einrichtung, die Rahmen senden und/oder empfangen kann.
NRZ	Non-Return to Zero (Codierungsverfahren)
Physische Kommunikationsstrecke	Eine Verbindung zwischen Knoten, durch die Signale zum Zwecke der Kommunikation übermittelt werden. Alle mit einer gegebenen physischen Kommunikationsstrecke verbundenen Knoten teilen sich dieselben elektrischen oder optischen Signale (d.h. sie werden nicht durch Zwischenverstärker, Sterne, Gateways usw. verbunden). Physische Kommunikationsstrecken sind zum Beispiel ein Busnetzwerk oder eine Punkt-zu-Punkt-Verbindung zwischen einem Knoten und einem Stern. Ein Kommunikationskanal kann durch Kombinieren einer oder mehrerer physischer Kommunikationsstrecken miteinander unter Verwendung von Sternen konstruiert werden.
SAS	Statusalarmsymbol
Schlitz	Entweder ein statischer Schlitz oder ein dynamischer Schlitz, abhängig vom Kontext.
SMMS	Herauffahr-Mehrheit-Verfehlt-Signal (Fehlersignal)
SNS	Statusnormalsymbol
Stern	Eine Einrichtung, die einen Transfer von Informationen von einer physischen Kommunikationsstrecke zu einer oder mehreren anderen physischen Kommunikationsstrecken ermöglicht. Ein Stern dupliziert auf einer seiner Strecken vorliegende Informationen auf die anderen mit dem Stern verbundenen Strecken, so daß Cluster aus Knoten aufgebaut werden

	können, die nur Punkt-zu-Punkt-Verbindungen unterstützen. Ein Stern kann entweder passiv oder aktiv sein.
Statisches Segment	Teil des Kommunikationszyklus, in dem der Mediumzugriff über ein statisches TDMA-Schema (Time Division Media Access) gesteuert wird. Während dieses Segments wird der Zugang zu dem Medium nur durch das Ablaufen der Zeit bestimmt.
Statischer Schlitz	Zeiteinheit fester Dauer, mit der der Mediumzugriff in dem statischen Segment eines Kommunikationszyklus gesteuert wird. Alle statischen Schlitze in einem Zyklus besitzen dieselbe Dauer (ausgedrückt in Makroticks), und diese Dauer ist von Zyklus zu Zyklus konstant. In einer beliebigen gegebenen Kombination von statischem Schlitz/Kanal kann nur ein Knoten senden.
Sync-Rahmen	FlexRay-Rahmen, dessen Kopfteilsegment Informationen enthält, die angeben, daß die zwischen der Ankunftszeit des Rahmens und seiner erwarteten Ankunftszeit gemessene Abweichung von dem Taktsynchronisationsalgorithmus verwendet werde soll.
TBD	Noch zu bestimmen
TDMA	Time Division Multiple Access (Mediumzugriffsverfahren)
TSS	Übertragungsstartsequenz
TT-D	Zeitgetriggerte verteilte Synchronisation (Protokollmodus)
TT-M	Zeitgetriggerte mastergesteuerte Synchronisation (Protokollmodus)
VCW	Validierungsprüffenster
WUS	Aufwecksymbol

Claims

Verfahren zur Überwachung einer Zugriffsablaufsteuerung für ein Kommunikationsmedium einer Kommunikationssteuerung (5) eines Kommunikationssystems (1) mittels eines Buswächters (6), wobei das Kommunikationssystem (1) ein Kommunikationsmedium (2) und mit dem Kommunikationsmedium verbundene Knoten (3) umfaßt, wobei jeder Knoten (3) eine Kommunikationssteuerung (5) und einen der Kommunikationssteuerung (5) zugewiesenen Buswächter (6) umfaßt, während Nachrichten über das Kommunikationsmedium (2) auf der Basis eines zyklischen zeitlich getriggerten Kommunikationsmedium-Zugriffsschemas zwischen den Knoten übertragen werden, dadurch gekennzeichnet, daß der Buswächter (6) a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffssteuerung während des Herauffahrens des Kommunikationssystems (1) besitzt und daß der Buswächter (6) während des Herauffahrens des Kommunikationssystems (1) das a-priori-Wissen ausnutzt, um zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung (5) verursacht wird, zu unterscheiden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Buswächter (6) a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während einer anfänglichen Synchronisation der Knoten (3) nach dem Einschalten des Kommunikationssystems (1) besitzt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß zulässige Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens der Kommunikation durch Rücksetzinformationen (SR) und durch das chronologische Auftreten der Rücksetzinformationen (SR) repräsentiert werden und daß der Buswächter (6) die Rücksetzinformationen (SR) und das chronologische Auftreten der Rücksetzinformationen (SR) während des Herauffahrens der Kommunikation überwacht.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß während des Herauffahrens der Kommunikation die Kommunikationssteuerung (5) eines der Knoten (3) ein erstes Triggersignal (ARM) zu dem der Kommunikationssteuerung (5) zugewiesenen Buswächter (6) sendet, der Buswächter (6) abhängig von den a-priori-Informationen mindestens ein Erwartungsfenster (32) definiert, der Buswächter (6) überwacht, ob weitere Triggersignale in dem mindestens einen Erwartungsfenster (32) vorliegen, und der Buswächter (6) abhängig davon, ob weitere Triggersignale in dem mindestens einen Erwartungsfenster (32) vorliegen, und abhängig von den a-priori-Informationen zwischen einer zulässigen Abweichung und einer verbotenen Abweichung unterscheidet.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß das erste Triggersignal (ARM) am Anfang eines Zeitschlitzes (30) in einem Zyklus (31) des Kommunikationsmedium-Zugriffsschemas gesendet wird und daß am Ende des Zeitschlitzes (30) in dem Zyklus (31) ein erstes Erwartungsfenster (32) definiert wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß ein weiteres Triggersignal (ARM) in einem weiteren Erwartungsfenster (33) den Anfang eines neuen Zyklus (31) des Kommunikationsmedium-Zugriffsschemas definiert.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß jeweils am Anfang nachfolgender Zyklen (31) des Kommunikationsmedium-Zugriffsschemas eine Anzahl weiterer Erwartungsfenster (33) definiert wird.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß die Anzahl weiterer Erwartungsfenster (33) abhängig von den a-priori-Daten, insbesondere abhängig von einem Parameter (ColdStartMax) definiert wird, der die maximale Anzahl von Zyklen (31) definiert, für die der Kommunikationssteuerung (5) erlaubt wird, aktiv zu versuchen, Kommunikation mit einer weiteren Kommunikationssteuerung (5) von einem der anderen Knoten (3) des Kommunikationssystems (1) herzustellen.
Verfahren nach einem der Ansprüche 4 bis 8, dadurch gekennzeichnet, daß bei einer zulässigen Abweichung von der Kommunikationsmedium-Zugriffsablaufsteuerung weitere Triggersignale (ARM) in den Erwartungsfenstern (32, 33) oder kein Auftreten in den Erwartungsfenstern (32, 33) vorliegen können.
Verfahren nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, daß bei einem gültigen Ablaufsteuerungs-Rücksetzen (SR) keine weiteren Triggersignale (ARM) in den weiteren Erwartungsfenstern (33) vorliegen.
Verfahren nach einem der Ansprüche 4 bis 10, dadurch gekennzeichnet, daß bei einer verbotenen Abweichung von der Kommunikationsmedium-Zugriffsablaufsteuerung keine weiteren Triggersignale (ARM) außerhalb der Erwartungsfenster (32, 33) vorliegen.
Computerprogramm, das auf einem Computer, insbesondere einem Mikroprozessor, ausgeführt werden kann, dadurch gekennzeichnet, daß das Computerprogramm programmiert ist, um alle Schritte des Verfahrens nach einem der Ansprüche 1 bis 11 auszuführen.
Computerprogramm nach Anspruch 12, dadurch gekennzeichnet, daß das Computerprogramm auf einem Nurlesespeicher, auf einem Direktzugriffsspeicher oder einem Flash-Speicher gespeichert ist.
Buswächter (6), der einer Kommunikationssteuerung (5) von einem einer Anzahl von mit einem Kommunikationsmedium (2) verbundenen Knoten (3) zugewiesen ist, während Nachrichten über das Kommunikationsmedium (2) auf der Basis eines zyklischen zeitlich getriggerten Kommunikationsmedium-Zugriffsschemas zwischen den Knoten (3) übertragen werden, wobei der eine Knoten (3) die Kommunikationssteuerung (5) und den Buswächter (6) umfaßt, der Buswächter (6) Mittel zum Überwachen der Kommunikationsmedium-Zugriffsablaufsteuerung der Kommunikationssteuerung (5) besitzt, dadurch gekennzeichnet, daß der Buswächter (6) a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffsablaufsteuerung während des Herauffahrens des Kommunikationssystems (1) besitzt und daß der Buswächter (6) Mittel zum Ausnutzen des a-priori-Wissens besitzt, um während des Herauffahrens des Kommunikationssystems (1) zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung (5) verursacht wird, zu unterscheiden.
Buswächter (6) nach Anspruch 14, dadurch gekennzeichnet, daß der Buswächter (6) Mittel zum Ausführen des Verfahrens nach einem der Ansprüche 2 bis 11 umfaßt.
Knoten einer Anzahl von mit einem Kommunikationsmedium (2) eines Kommunikationssystems (1) verbundenen Knoten (3), wobei das Kommunikationssystem (1) das Kommunikationsmedium (2) und die Knoten (3) umfaßt, wobei der Knoten (3) eine Kommunikationssteuerung (5) und einen Buswächter (6) umfaßt, während Nachrichten über das Kommunikationsmedium (2) auf der Basis eines zyklischen zeitlich getriggerten Kommunikationsmedium-Zugriffsschemas zwischen den Knoten (3) übertragen werden, wobei der Buswächter (6) Mittel zum Überwachen der Kommunikationsmedium-Zugriffsablaufsteuerung der Kommunikationssteuerung (5) besitzt, dadurch gekennzeichnet, daß der Buswächter (6) a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffssteuerung während des Herauffahrens des Kommunikationssystems (1) besitzt und daß der Buswächter (6) Mittel zum Ausnutzen des a-priori-Wissens besitzt, um während des Herauffahrens des Kommunikationssystems (1) zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung (5) verursacht wird, zu unterscheiden.
Knoten (3) nach Anspruch 16, dadurch gekennzeichnet, daß der Buswächter (6) Mittel zum Ausführen des Verfahrens nach einem der Ansprüche 2 bis 11 umfaßt.
Kommunikationssystem (1), das ein Kommunikationsmedium (2) und mit dem Kommunikationsmedium verbundene Knoten (3) umfaßt, während Nachrichten über das Kommunikationsmedium (2) auf der Basis eines zyklischen zeitlich getriggerten Kommunika tionsmedium-Zugriffsschemas zwischen den Knoten (3) übertragen werden, mit einer Kommunikationssteuerung (5) und einem der Kommunikationssteuerung (5) zugewiesenen Buswächter (6), wobei der Buswächter (6) die Kommunikationsmedium-Zugriffsablaufsteuerung der Kommunikationssteuerung (5) überwacht, dadurch gekennzeichnet, daß der Buswächter (6) a-priori-Wissen über mögliche Abweichungen von der Kommunikationsmedium-Zugriffssteuerung während des Herauffahrens des Kommunikationssystems (1) besitzt und daß der Buswächter (6) Mittel zum Ausnutzen des a-priori-Wissens besitzt, um während des Herauffahrens des Kommunikationssystems (1) zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung (5) verursacht wird, zu unterscheiden.
Kommunikationssystem (1) nach Anspruch 18, dadurch gekennzeichnet, daß das a-priori-Wissen Rücksetzinformationen (SR) und das chronologische Auftreten der Rücksetzinformationen (SR) während des Herauffahrens der Kommunikation umfaßt und daß die Mittel zum Ausnutzen des a-priori-Wissens die Rücksetzinformationen (SR) und das chronologische Auftreten der Rücksetzinformationen (SR) während des Herauffahrens der Kommunikation überwachen, um zwischen einer zulässigen Abweichung und einer verbotenen Abweichung, die durch ein Versagen der Kommunikationssteuerung (5) verursacht wird, zu unterscheiden.
Kommunikationssystem (1) nach Anspruch 18 oder 19, dadurch gekennzeichnet, daß der Buswächter (6) Mittel zum Ausführen des Verfahrens nach einem der Ansprüche 2 bis 11 umfaßt.