-
Diese
Erfindung betrifft Kommunikationsnetzwerke, und spezieller ein Verfahren
um Kollisionen und Rauschverstümmelung
in einem Peer-to-Peer-Kommunikationsnetzwerk zu detektieren und
beizulegen, das auf einem universellen Asynchronsender/Empfänger basiert.
Historisch wurden elektrische und elektronische Funktionen in Fahrzeugen
mit einzelnen elektronischen Regeleinheiten (ECU's, Electronic Control Units; elektronischen
Regeleinheiten) implementiert, welche getrennte, unabhängige Funktionen
verrichten. Zum Beispiel kann ein Fahrzeugsystem eine ECU für Motor-Regelfunktionen
einschließen,
eine andere ECU um Bremsen-Antiblockierfunktionen zu verrichten,
und noch eine andere ECU um die Instrumentengruppe zu regeln. Da
sich die elektronische Architektur von Fahrzeugen entwickelt hat,
wurde es für
ECU's notwendig
niteinander zu kommunizieren, um wünschenswerte Fahrzeugsystem-Merkmale
wie etwa die folgenden zu realisieren:
- 1. verteilte
Fahrzeugfunktionen über
Koordinierung zwischen ECU's
- 2. Teilen miteinander in Zusammenhang stehender Daten zwischen
ECU's; und
- 3. Zugriff auf Diagnosedaten mehrerer ECU's über
eine einzige, gemeinsame Schnittstelle.
-
Ein
Beispiel des ersten Merkmals wäre
ein Fahrzeugtraktions-Regelsystem, welches Koordinierung zwischen
einer Antriebsstrang-Regelung und einem Antiblockiersystem-Regler
(ABS, Antilock Brake System; Antiblockiersystem) beinhaltet. Ein
Beispiel für
das zweite Merkmal wäre
eine Kommunikation von Motorkühlmittel-Temperaturdaten
von der Antriebsstrang-ECU zu der Instrumentengruppen-ECU zur Anzeige
durch die Instrumentengruppe. Das dritte oben erwähnte Merkmal
erlaubt es einer einzigen Diagnoseverbindung zu einem Bus oder einem
Netzwerk für
Diagnoseinformationen – oder
um Diagnosefunktionen in einem Fahrzeug auszuüben – auf eine Mehrzahl von Modulen
zuzugreifen, ohne sich mit jeder ECU getrennt verbinden zu müssen.
-
Kommunikation
zwischen ECU's in
Fahrzeugen wurde mit einer Vielfalt von Lösungen verwirklicht. Mehrere
CARRIER SENSE MULTIPLE ACCESSS/COLLISION DETECT/ARBITRATE (CSMA/CD/A) – Protokolle
wurden entwickelt und werden in Fahrzeugen verwendet, einschließlich des
Standards IS011898, sonst als Controller Area Network (CAN) bekannt,
und der Standards SAE J1850, einschließlich der Implementierungen
J1850 PWM und VPW. Diese Protokolle müssen durch speziell aufgebaute
integrierte Schaltungen implementiert werden, welche spezifisch
konstruiert sind um sich an das genannte Protokoll zu halten. Als
auf Willkür
basierende Protokolle erfordern diese Protokolle eine Nachrichtenübertragung,
um sich miteinander zu synchronisieren und auf Bit-für-Bit-Basis
derart untereinander zu schlichten, daß Nachrichtenkollisionen für die maßgebliche
Nachricht nicht zerstörend
sind. Die Tatsache daß speziell
aufgebaute integrierte Schaltungen benötigt werden um diese Kommunikationsprotokolle
zu implementieren, setzt jedoch zugehörige Kosten für den Protokollregler
voraus.
-
Eine
Alternative zur Verwendung von speziell aufgebauten integrierten
Schaltungen ist es einen UART (Universal Asynchronous Reiceiver
Transmitter; universeller Asynchronsender/Empfänger) zu verwenden, um ein
Peer-to-Peer-Kommunikationsnetzwerk zwischen ECU's zu implementieren, wie in 1 gezeigt.
Die in Fahrzeugen verwendeten ECU's sind beinahe ausschließlich auf
Mikrocontrollern basierende Konstruktionen. Der UART ist ein Mikrocontroller-Peripheriegerät, welches
für eine
große
Vielfalt von Mikrocontroller-Familien weithin verfügbar ist
und welches weniger komplex und weniger kostspielig ist als speziell
aufgebaute integrierte Lösungen
für CSMA/CD/A-Kommunikationsprotokolle.
UARTs werden jedoch am üblichsten
als Lösungen für die Kommunikation
von Punkt zu Punkt zwischen ECU's
in einem gemeinsamen Netzwerk benutzt, wo die Kommunikation durch
einen einzigen Bus-„Master" in dem Netzwerk
koordiniert wird, wobei die verbleibenden Knoten als „Slaves" wirken.
-
Peer-to-Peer-Kommunikationsnetzwerke
werden aus den folgenden Gründen
typischerweise nicht unter Verwendung von UARTs implementiert: 1.)
UARTs sind nicht in der Lage mit bereits auf dem Bus vorhandenen
Signalen zu synchronisieren. Wenn dem UART befohlen wird ein Zeichen
zu übertragen,
so überträgt er das
Zeichen unabhängig
davon, welches Signal sich auf dem Bus befindet. 2.) UARTs sind
nicht in der Lage bitweise zu schlichten; beginnt der UART einmal
die Übertragung
eines Zeichens, so wird das Zeichen vollständig übertragen. 3.) Kollisionen
zwischen mehreren übertragenden
Knoten auf einem UART-basierten Peer-to-Peer-Kommunikationsnetzwerk können in
verzerrten Wellenformen resultieren, welche bewirken daß Daten
durch verschiedene Knoten auf dem Bus unterschiedlich interpretiert
werden.
-
Das
mit dem Gebrauch von UARTs in Peer-to-Peer-Kommunikationsnetzwerken
in Zusammenhang stehende Kollisionsproblem wird aus der folgenden
Besprechung unter Bezug auf 2 offensichtlich
sein. In diesem Fall haben zwei Knoten asynchron – mit einer
halben Bitperiode Phasenverschiebung zwischen sich – Nachrichtenübermittlungen
eingeleitet. Die resultierende Wellenform auf dem Bus, welche ein
Gemisch der durch die beiden Einzelknoten auf den Bus getriebenen
Signale ist, bringt Datenübergänge dazu
genau an den empfangenden UART-Abtastpunkten aufzutreten, welche
aus der ersten Flanke des Startbits geplant wurden. Während Datenübergängen aufgenommene
Datenproben (eingekreiste Pfeile) sind undefiniert und resultieren in
entsprechend unverläßlichen
Datennachrichten. Weil UARTs nicht zu einer bitweisen Schlichtung
in der Lage sind, ist es nicht möglich
ein sie verwendendes CSMA/CD/A-Protokoll zu entwickeln.
-
Zusätzlich zum
Problem der Datenkollision ist die Fahrzeugumgebung sowohl bezüglich abgestrahlter wie
auch geleiteter Rauschquellen eine extrem verrauschte elektrische
Umgebung, was die Verläßlichkeit
und Integrität
von Datenübertragungen
weiter vermindert.
-
US-A-5,414,717
legt einen Multiplex-Kommunikationsregelapparat offen, in dem ein
negatives Quittiersignal als ein Reaktionssignal übertragen
wird, um das Auftreten eines Empfangsfehlers zu melden. Die offenbarten
Signalformate wären
für ein
asynchrones Netzwerk nicht geeignet. Die vorliegende Erfindung legt ein
Verfahren der Peer-to-Peer-Kommunikation zwischen einer Mehrzahl
von durch einen Bus gekoppelten Reglern bereit, wobei jeder Regler
einen Empfänger
und einen Sender einschließt,
und wobei dieses Verfahren eine Abfolge der folgenden Schritte durch
einen dieser Mehrzahl von Regler umfaßt:
Empfangen mindestens
eines Teils einer Nachricht;
Detektieren daß die Nachricht eine verstümmelte Version
einer original unverstümmelten
Nachricht ist;
Übertragen
eines negativen Quittiersignals in Reaktion auf die Detektierung
dieser verstümmelten
Version;
dadurch gekennzeichnet daß:
diese Peer-to-Peer-Kommunikation
asynchron ist und jede Nachricht eine Gruppe von Zeichen einschließt, wobei
jedes Zeichen einen Rahmen aufweist, der einen Bytewert und ein
Stopbit einschließt;
dieses
negative Quittiersignal den Bus dazu bringt für ein vorherbestimmtes Zeitintervall
einen vorherrschenden Zustand einzunehmen, um die in Bearbeitung
befindliche Nachricht abzubrechen;
dieses negative Quittiersignal
ein besagtes Stopbit eines Zeichenrahmens überschreibt;
dieses überschriebene
Stopbit als ein Zeichenrahmen-Fehler delektiert wird, um den Empfang
dieser verstümmelten
Version durch einen anderen dieser Mehrzahl von Reglern zu verhindern;
und
daß man
den Bus dazu bringt am Ende dieses Zeitintervalls einen rezessiven
Zustand einzunehmen.
-
Gemäß der vorliegenden
Erfindung wird ein Mehrfach-ECU-Kommunikationsverfahren bereitgestellt, das
Mikrocontroller-UARTs verwendet um verläßliche Peer-to-Peer-Kommunikation zu
erzielen. Das Kommunikationsverfahren verwendet ein definiertes
Nachrichtenformat und eine Mehrzahl von Prüfungen der Integrität einzelner
Zeichen und der Integrität
der vollständigen
Nachricht relativ zum definierten Nachrichtenformat, um zuverlässige Datenübertragung
und zuverlässigen
Datenempfang zwischen Knoten zu erzielen. Die Knoten verwenden einen
Softwaremechanismus um ein negatives Quittiersignal (NACK, Negative
Acknowledgement; negative Quittierung) zu erzeugen, welches – für den Fall
daß durch
irgendeinen Knoten auf dem Netzwerk Nachrichtenverstümmelung
detektiert wird – die
Nachrichtenverstümmelung
markiert und ein Signal erzeugt, welches garantiert die in Bearbeitung
befindliche Nachricht zu verstümmeln.
Dies bringt alle Empfänger der
in Bearbeitung befindlichen Nachricht dazu den Empfang einer verstümmelten
Nachricht abzubrechen, und bringt den Sender dazu die Übertragung
der Nachricht erneut zu versuchen. Diese Negativ-Quittiertechnik zieht
Vorteil aus der UARTs eigenen Rahmenformatprüfung, indem sie das Stopbit
des UART-Zeichenrahmens überschreibt.
-
Das
hierin beschriebene Verfahren ist gleichermaßen effektiv darin eine Verstümmelung
von Nachrichten in einem UART-basierten System zu detektieren und
abzulehnen, welche entweder aufgrund von Datenkollisionen durch
mehrere Sender in dem Netzwerk verstümmelt wurden, oder aufgrund
einer aus geleiteten oder abgestrahlten Rauschquellen resultierenden
Rauschverstümmelung.
Das zurückgewiesene
Rauschen kann entweder globales Rauschen sein (von allen Empfängern im
Netzwerk detektiert) oder lokales Rauschen (nur von von einem Sender
oder Empfänger
im Netzwerk detektiert). Das durch diese Erfindung definierte Verfahren
erlegt der Anzahl von Knoten in dem Netzwerk keinerlei Grenzen auf
und erfordert keinen speziellen Dateninhalt außer einer einzigartigen Quelladresse,
die jedem Knoten in dem Netzwerk zugeschrieben ist.
-
Die
Erfindung wird nun, anhand eines Beispiels, unter Bezug auf die
beigefügten
Zeichnungen beschrieben werden, in welchen:
-
1 ein
Blockdiagramm des auf mehreren ECUs basierenden Kommunikationssystems
der vorliegenden Erfindung ist;
-
2 Wellenformen
zeigt, die aus asynchronen Kollisionen in einem UART-basierten Netzwerk
resultierende Datenunsicherheiten darstellen;
-
3 ein
detailliertes Blockdiagramm einer der ECU's von 1 ist;
-
4 das
durch die vorliegende Erfindung benutzte Zeichenrahmen-Format zeigt;
-
5 das
durch die vorliegende Erfindung benutzte Nachrichtenformat zeigt;
-
6 Details
des Nachrichtenkopf-Formats zeigt;
-
7 ein
Zustandsdiagramm ist, daß die
Zustandsmaschine der Sender/Empfänger-Software zeigt;
-
8 Nachrichten-Wellenformen
und Logikzustände
für normale
Kommunikation zeigt;
-
9 Nachrichten-Wellenformen
und Logikzustände
für Fehlermodus-Betrieb
zeigt.
-
Unter
Bezug auf die Zeichnungen, und anfänglich auf 3,
schließt
das Kommunikationssystem der vorliegenden Erfindung eine Mehrzahl
von allgemein mit 10 bezeichneten Mikrocontrollern ein,
die jeder einen CPU 12 umfassen; einen zugehörigen Speicher 14,
der die Software-Zustandsmaschine speichert; ein UART-Peripheriegerät 16;
einen Flankendetektor-Eingang 18 und einen Zeitgeber 20.
Ein physischer Schichtempfänger 22 verbindet
den UART 16 mit einem nulldominanten Bus 24.
-
UART-Implementierungen
variieren von Mikrocontroller zu Mikrocontroller. Zum Beispiel schließen manche – aber nicht
alle – UARTs
Informationen ein ob ein Byteempfang im Gange ist (Bus nicht im
Leerlauf). Manche, aber nicht alle UARTs lassen es zu daß Bytes
in der „aufgereihten" Art und Weise in
einer Warteschlange eingereiht und übertragen werden. Manche, aber
nicht alle UARTs erlauben es daß ein „Unterbrechungs"-Signal direkt gesendet
wird, was bewirkt daß in
empfangenden UARTs ein Rahmenfehler detektiert wird. Das Protokoll
der vorliegenden Erfindung wurde entwickelt um mit den einfachst
verfügbaren
UARTs in üblichen,
billigen, kommerziellen Mikrocontrollern zu arbeiten, und keine
speziellen UART-Merkmale. Die vorliegende Erfindung arbeitet mit
einer Standard-Bitrate von 9600 Bit/Sekunde, und alle UARTs auf
dem Bus sind programmiert um – mit
einer Toleranz von +/– 2% – mit der
gleichen Bitrate zu arbeiten. Diese Prinzipien sind jedoch leicht
auf andere Bitraten auzudehnen, solange alle UARTs auf dem Bus mit
der gleichen Bitrate arbeiten.
-
Der
Zeitgeber 20 wird benutzt um die Leerlaufperiode zwischen
empfangenen Bytes zu messen, und um zu bestimmen ob der Bus sich
im Leerlauf befindet oder nicht. Der Zeitgeber wird außerdem benutzt
um eine Zeitdauer nach Abschluß der
Nachrichtenübertragung
oder des Nachrichtenempfangs zu reservieren, während der das Auftreten eines
NACK auf dem Bus den erfolgreichen Abschluß oder Empfang einer Nachricht
negiert.
-
Der
Flankendetektions-Eingang 18 ist ein gesonderter Eingang
zu dem Mikrocontroller, welcher ein Bit setzt wenn auf dem Bus ein Übergang
von einer logischen 1 auf eine logische 0 auftritt. Der Zweck dieses
Eingangs ist es die Anzahl von Kollisionsereignissen zu minimieren,
welche auf dem Bus auftreten, und dadurch die effektive Bus-Bandbreite
zu steigern. Das Protokoll erfüllt
seinen Zweck ohne den Flankendetektions-Eingang, aber das Flankendetektions-Merkmal erlaubt es
einem Knoten zu bestimmen ob auf dem Bus irgendeine Aktivität herrscht,
gerade bevor er ein Zeichen überträgt. Befindet
sich der Bus nicht im Leerlauf, so verschiebt ein Knoten, der gerade
dabei ist zu übertragen,
seine Übertragung
bis der Bus sich wieder im Leerlauf befindet. Manche UARTs schließen ein
Statusbit ein, welches anzeigt daß eine Byteübertragung im Gange ist. Für solche
UARTs kann dieses Statusbit benutzt werden, um zu detektieren ob
der Bus beschäftigt
ist, und es würde kein
Flankendetektions-Eingang gebraucht. Der Bus 24 befindet
sich auf einem von zwei logischen Pegeln oder Zuständen; 0
und 1. Der Bus ist dahingehend ein nulldominater Bus, daß der Zustand
0 der maßgebliche Zustand
auf dem Bus ist, wenn zwei Sender gleichzeitig versuchen gegensätzliche
Zustände
auf den Bus zu treiben. Jeder der Prozessoren auf dem Bus kommuniziert
in einem Halbduplex-Modus und empfängt zur gleichen Zeit das Mischsignal
auf dem Bus, zu der er Signale auf den Bus treibt. Der Zweck der
physischen Schichttransceiver-Vorrichtung 22 ist es, den
Logikzustand des durch die UART übertragenen
Bits in ein Analogsignal mit Impedanzcharakteristika umzuwandeln,
die mit der nulldominanten Art des Bus kompatibel sind. Der physische
Schichttransceiver treibt aktiv logische 0-Signale auf den Bus (geringe
Impedanz), und treibt passiv logische 1-Signale (hohe Impedanz)
auf den Bus.
-
Kommunikation
in dem UART-basierten Protokoll (UBP; UART Based Protocol; UART-basiertes Protokoll)
wird mittels Nachrichten bewirkt. Nachrichten sind Gruppen von Zeichen,
welches eines zur Zeit durch den UART übertragen werden. Der in UBP
benutzte Zeichenformat ist ein Standardrahmen von 10 Bit, wie in 4 gezeigt.
Das erste Bit ist ein Startbit, welches durch einen Übergang
von rezessiver 1 auf dominante 0 identifiziert wird. Die nächsten 8
Bits sind Datenbits, welche den Bytewert des übertragenen Zeichens umfassen.
Das 10. Bit ist ein Stopbit, welches eine 1-Bit-Periode eines rezessiven
Zustands 1 ist. Empfangende UARTs synchronisieren auf die erste
Startbit-Flanke und sagen die einzelnen Bit- Abtastpunkte basierend auf der ersten
Flanke des Startbits voraus. Wird das Stopbit als eine dominate
0 abgetastet, so identifiziert ein empfangender UART diesen Zustand
als einen Zeichenrahmen-Formatfehler. Hiernach wird auf die von
dem UART übertragenen
Zeichen dahingehend synonym mit Bytes Bezug genommen werden, daß ein Zeichen
aus einem Startbit, einem Bytewert und einem Stopbit besteht.
-
Zur
gleichen Nachricht gehörende
Zeichen weisen eine Trennung zwischen den Zeichen auf, welche eine
spezifizierte Leerlaufzeit von 10 Bitdauern nicht überschreiten
darf. Übersteigt
die Trennung zwischen Zeichen für
zwei aufeinander folgend empfangene Zeichen 10 Bitdauern, so wird
angenommen daß die
Zeichen zu gesonderten Nachrichten gehören. Gemäß UBP übertragene Nachrichten kombinieren
Zeichen zu einem Nachrichtenformat, wie es in 5 gezeigt
ist. Jede Nachricht schließt
einen Pflichtkopf von drei Byte ein, ein Datenfeld von 1 bis 8 Datenbytes,
und ein Prüfsummen-Byte.
Nachrichten werden durch eine Minimaldauer von 51 Bitdauern getrennt,
was gebraucht wird um den Knoten zu erlauben zu bestimmen, ob irgendein
anderer Knoten in dem System eine Nachricht als ungültig erklärt hat,
indem er ein NACK überträgt. Der
Kopf besteht aus drei einzigartigen Bytes, gezeigt in 6.
Das erste Byte ist ein Formatbyte, das zweite Byte ist ein Zielbyte,
und das dritte Byte ist das Quellbyte. Die ersten zwei Bits des
Formatbytes spezifizieren den Nachrichtentyp. Die beiden Nachrichtentyp-Bits
lassen vier mögliche
Nachrichtentypen zu, obwohl in UBP zwei Nachrichtentypen definiert
sind; funktionell adressierte Nachrichten (erste zwei Bits 00 binär) und physisch adressierte
Nachrichten (erste zwei Bits 10 binär). Die nächsten 6 Bits des Formatbytes
spezifizieren die Anzahl in der Nachricht zu übertragender Datenbytes; die
möglichen
Werte sind 1 bis 8.
-
Das
zweite Byte ist ein Zielbyte. Im Fall von funktionell adressierten
Nachrichten muß die
Nachricht empfangen werden, wenn das durch einen Knoten empfangene
Zielbyte zu einer für
diesen Knoten definierten Liste von vordefinierten Zielbytes paßt. Ist
die Nachricht eine physisch adressierte Nachricht, so wird die Nachricht
empfangen wenn das Zielbyte zur Quelladresse des empfangenden Knotens
paßt.
Das dritte Byte ist das Quellbyte, welches der einzigartigen Adresse
des Knotens entspricht, welcher die Quelle der übertragenen Nachricht ist.
Das Datenfeld besteht aus 1 bis 8 Datenbytes. Die Datenbytes werden
von dem Prüfsummen-Byte
gefolgt. Das Prüfsummen-Byte
stellt die arithmetische Summe all der Bytewerte in der Nachricht vom
Formatbyte bis zum letzten Datenbyte dar, berechnet Modulo 256 dezimal.
-
Ein
anderes Zeichen, welches von einem oder allen Knoten in dem System
für den
Fall gesendet werden kann, daß ein
Fehler detektiert wird, ist ein „Unterbrechungs"-Zeichen. Auf dieses
Zeichen wird auch als eine „Negativquittierung" oder „NACK" Bezug genommen.
Das NACK- Zeichen
ist als mindestens 10 Bitdauern eines dominanten Zustands 0 definiert, übertragen
durch einen Knoten im Netzwerk. Die Bedeutung des Zeichens „Unterbrechung" oder „NACK" ist es, daß seine Übertragung
garantiert daß die
Detektion eines Zeichenrahmen-Formatfehlers durch jeden Empfänger auf
dem Bus bewirkt wird. Der Grund hierfür ist es, daß die Übertragung
von 10 Bitdauern eines dominanten Zustands einen Empfänger dazu
bringen wird ein Stopbit als dominant zu interpretieren, selbst
wenn zu dem Zeitpunkt, da das NACK übertracken wird, bereits eine
Zeichenübertragung
im Gange ist. Das NACK wie in diesem Protokoll definiert und implementiert
erlaubt es einem UART-basierten Peer-to-Peer-Kommunikationsprotokoll, ungeachtet
von Kollisionen oder Rauschereignissen ein hohes Niveau von Datenintegrität zu erzielen
und richtig zu arbeiten.
-
Weil
manche UARTs nicht in der Lage sind ein Unterbrechungssignal direkt
zu übertragen,
kann das NACK-Signal in Software in Verbindung mit dem Zeitgeber
des Mikrocontrollers geschaffen werden, welcher der Implementierung
dieses Protokolls gewidmet ist. In allen UART-Konstruktionen, welche
durch die Anmelder beurteilt wurden, kann die UART-Funktionalität deaktiviert
werden, und die TX- und RX-Pins können direkt als Mikrocontroller-Schnittstellenpins
geregelt werden. Das Unterbrechungssignal beginnt indem man die
Ausgabe des TX-Pins auf jenen Zustand setzt, welcher bewirkt daß ein dominantes
Signal auf den Bus getrieben wird, und indem man den Mikrocontroller-Zeitgeber
für 10
Bitdaueren vom gegenwärtigen
Zeitpunkt setzt. Wenn der Zeitgeber abläuft wird der Ausgangszustand
des TX-Pins derart
umgeschaltet, das ein rezessiver Zustand auf den Bus gegeben wird.
-
Die
hierin beschriebene Protokollimplementierung minimiert das Auftreten
von Kollisionen über
den Flankendetektions-Eingang 18. Bevor durch irgendeinen
Sender im Netzwerk irgendein Byte übertragen wird, wird der Flankendetektions-Eingang
geprüft,
um zu sehen ob irgendein anderer Knoten im Netzwerk die Übertragung
eines Bytes begonnen hat. Dieser Ansatz minimiert die Anzahl von
Kollisionen, aber es können
nicht alle Kollisionen vorhergesehen werden. Für den Fall daß Nachrichten
gleichzeitig von zwei (oder mehr) Knoten im Netzwerk übertragen
werden, werden Kollisionen durch Mehrfachprüfungen der Datenintegrität der Nachricht
detektiert und sofort durch Übertragung
eines NACK geklärt.
-
Jeder
Sender empfängt
und prüft
gleichzeitig jedes Byte, während
es auf dem Bus übertragen
wird. Das empfangene Byte wird mit dem Byte verglichen welches der übertragende
Knoten gerade in seinen UART geladen und übertragen hat. Der übertragende
Knoten übermittelt
ein NACK, um die Detektion einer Kollision anzuzeigen, für jeden
von zwei Fällen:
1) das empfangene Byte hat nicht den gleichen Wert wie das übertragene
Byte oder 2) das empfangene Byte weist einen Rahmenformat-Fehler
auf (z.B. das rezessive Stopbit 1 wurde zu einer dominanten 0 überschrieben).
Der Effekt des NACK ist es zu garantieren daß alle Knoten auf dem Bus einen
Rahmenfehler detektieren und die Übertragung und/oder den Empfang
jeglicher im Gange befindlichen Nachricht abbrechen. Diese Kollisionsprüfung und
das Übertragen
eines NACK, wenn ein Fehler detektiert wird, wird mit jedem durch
einen Sender übertragenen
Byte verrichtet, einschließlich
dem Formatbyte, dem Zielbyte, dem Quellbyte, den Datenbytes und
dem Prüfsummen-Byte.
-
Die
vorliegende Erfindung erlaubt es jedem Knoten auf dem Bus eine Nachricht
auf dem Bus unwirksam zu machen, indem er ein NACK übermittelt
wann immer er einen Fehler detektiert. Ein möglicher Weg nach Detektion
einer Abweichung Kollisionen beizulegen ist es, jenen Sender, welcher
die Abweichung detektiert hat, einfach „zurückzuziehen" und die Übertragung einfach anzuhalten.
Dieser Ansatz erlaubt es einem Sender, welcher keinen Fehler detektiert,
selbst nach einer Kollision mit der Übertragung fortzufahren. Das Problem
mit einem derartigen Ansatz ist die Unsicherheit empfangener Daten,
die mit dem in 2 in Zusammenhang stehen. Wenn
zwei Nachrichtenübertragungen
kollidieren und die resultierende Wellenform bewirkt daß Datenübergänge genau
am Abtastpunkt eines Empfängers
auftreten, so ist es für
verschiedene empfangende Knoten auf dem Bus möglich die gleiche Wellenform
zu empfangen und unterschiedlich zu interpretieren. Übertragung
des NACK durch irgendeinen Knoten, welcher eine Kollision oder irgendeinen
Widerspruch in einer empfangenen Wellenform detektiert, garantiert
daß es
einer Wellenform auf dem Bus – aufgrund
einer Kollision möglicherweise
verstümmelt – nicht
weiter erlaubt wird durch andere Knoten in dem Netzwerk empfangen
zu werden, und es wird erzwungen daß sie durch die übertragenden
Knoten erneut übertragen
wird.
-
Für die Mehrheit
der Fälle
werden Kollisionen auf dem Bus nach Kollision des ersten Zeichens
detektiert. Nachrichten unterschiedlicher Typen, Längen und
Ziele resultieren typischerweise in einer detektierbaren Kollision,
nachdem die ersten beiden Bytes der Nachricht übertragen wurden. Mit dem dritten
Byte der Nachricht sind jedoch fast alle Kollisionen detektiert.
Wie erwähnt
wird jedem Knoten auf dem Bus eine einzigartige Adresse zugewiesen.
Da diese Adresse durch einen einzigen Bytewert dargestellt wird,
können
Knotenadressen im Bereich von 0 bis 255 liegen, mit bis zu 256 auf
dem Bus zugelassenen Knoten. Es bestehen keine anderen Einschränkungen
der jedem Knoten zugewiesenen Adresswerte, als das Erfordernis daß jede Knotenadresse
auf dem Bus einzigartig sein muß.
Die Tatsache daß jede
Knotenadresse einzigartig ist, garantiert daß Kollisionen in den meisten
Fällen
nach Übertragung
des Quellbytes beigelegt sind. Für
den in 2 gezeigten Fall jedoch, wo Datenübergänge an Abtastpunkten
auftreten, garantieren einzigartige Quelladressen nicht immer eine
Kollisionsdetektion nach dem Quellbyte. Aufgrund jener der Datenübertragung
zuzuschreibenden Unsicherheit ist es möglich daß zwei verschiedene Sender
Bytewerte empfangen, die gleich dem Wert sind den sie übertragen
haben und selbst nach dem Quellbyte fortfahren zu übertragen.
-
Während Prüfung jedes
empfangenen Bytes durch jeden Sender und Übertragung eines NACK zur Beilegung
von Kollisionen der primäre
Mechanismus ist, um Kollisionen zu detektieren und beizulegen, sind
in dem Protokoll zusätzliche
Detektions- und Beilegungsmechanismen eingeschlossen. Jeder Knoten
auf dem UBP-Bus wird aus jedem der folgenden Gründe ein NACK übertragen
und jede in Gang befindliche Nachricht unterbrechen:
- 1. Detektion einer Unstimmigkeit zwischen einem übertragenen
und einem empfangenen Byte durch einen Sender;
- 2. Detektion eines Rahmenfehlers für jegliches empfangene Byte
durch einen Empfänger;
- 3. Detektion durch einen Empfänger, daß die Anzahl empfangener Bytes
höher ist
als die durch den Datenlängen-Code
spezifizierte Anzahl;
- 4. Detektion einer Übertragungs-Zeitsperre
durch einen Empfänger,
d.h. es ist zuviel Zeit mit dem Warten auf Empfang eines Bytes verstrichen,
wie es durch den Datenlängen-Code spezifiziert
ist; und
- 5. Detektion einer ungültigen
Prüfsumme
durch einen Empfänger.
-
Während nicht
jeder Knoten in dem UBP-Netzwerk zu jeder gegebenen Zeit ein Sender
ist, ist jeder Knoten in dem UBP-Netzwerk ein Empfänger, selbst
wenn der Knoten sendet. Jeder Knoten auf dem UBP-Bus empfängt und
prüft jede
auf dem Bus übertragene
Nachricht. Wenn irgendein Knoten einen Rahmenfehler detektiert,
d.h. ein dominantes Stopbit, so wird durch diesen Knoten ein NACK
gesendet. Das Formatbyte, das erste Byte der Nachricht, spezifiziert
die Anzahl von Datenbytes in der Nachricht. Ein empfangender Knoten weiß, basierend
auf dem Datenlängen-Teil
des empfangenen Formatbytes, welches empfangene Byte als die Prüfsumme zu
interpretieren ist. Wird innerhalb der minimalen Leerlaufzeit von
20 Bitdauern nach Empfang des Prüfsummen-Bytes
ein zusätzliches
Byte empfangen, so detektiert der empfangende Knoten einen Nachrichtenformat-Fehler
und sendet ein NACK, um den Empfang der gegenwärtigen Nachricht für alle Knoten
in dem Netzwerk zu widerrufen.
-
Ähnlich wird
ein Fehler detektiert und ein NACK durch den empfangenden Knoten
gesendet, wenn ein empfangender Knoten weniger Datenbytes empfängt als
durch den Datenlängen-Code
angezeigt. Abschließend
wird durch alle empfangenden Knoten eine Prüfsumme berechnet und mit der
auf dem Bus empfangenen Prüfsumme
verglichen. Jegliche Unstimmigkeit in der Prüfsumme bringt den die Prüfsumme empfangenden Knoten
dazu ein KNACK zu senden und die in Bearbeitung befindliche Nachricht
zu beenden.
-
Empfang
eines NACK innerhalb eines Nachrichten-Rahmenformats durch irgendeinen
Empfänger
bewirkt, daß die
in Bearbeitung befindliche Nachricht abgebrochen und nicht empfangen
wird. Empfang eines NACK durch irgendeinen Sender bringt die Nachrichtenübertragung
dazu abzubrechen. Übertragene
Nachrichten werden 10 mal erneut versucht, bevor der Übertragungsversuch
aufgegeben wird. Nachrichten in diesem Protokoll besitzen keine
Priorisierung. Der erste Benachrichtigungsversuch wird mit einer
minimalen Verzögerung
von 51 Bitdauern seit der vorigen Nachricht übertragen. Nachfolgenden Versuchen
wird eine zufällige
Verzögerung
von zwischen 0 bis 15 Bitdauern gegeben, um zu versuchen Kollisionsereignisse
zu minimieren, wenn zwei oder mehr Knoten um Zugriff auf das Netzwerk
wetteifern.
-
Wenn
nur ein Knoten einen Fehler detektiert und ein NACK sendet, so interpretieren
andere Knoten das erste NACK als einen Fehler und senden in Reaktion
ein NACK. Um zu verhindern das NACKs endlos zwischen Knoten „hin- und
hergespielt" werden,
ist die Übertragung
eines NACK durch jeden Knoten im Netzwerk auf eine KNACK-Übertragung
pro Nachrichtenereignis beschränkt.
Zusätzlich
behält
jeder Knoten einen Fehlerzähler
bei, welcher jedesmal stufenweise erhöht wird wenn ein NACK gesendet
wird, und jedes mal stufenweise verringert wird wenn eine Nachricht
erfolgreich empfangen wird. Erreicht der Fehlerzähler eine vorherbestimmte Grenze,
so wird der Knoten aus dem Bus genommen und ihm nicht erlaubt zu
kommunizieren, bis der Mikrocontroller den Softwaretreiber erneut
initialisiert hat. Dies geschieht, um fehlerhafte Knoten auf dem
Bus daran zu hindern die Kommunikation auf dem Bus endlos zu unterbrechen.
-
Zusätzlich zu
Kollisionsdetektion und -beilegung werden alle hierin beschriebenen
Mechanismen außerdem
benutzt um die Effekte externen Rauschens zu detektieren, sowohl
global auf dem Bus (allen Knoten gemein) und/oder lokal an einem
einzelnen Empfänger
oder Empfängern.
Im gleichen Sinne wie Datenkollisionen auf dem Bus Nachrichtenverstümmelungen
verursachen können,
können
auch geleitete und abgestrahlte Rauschquellen Nachrichten verstümmeln. Alle
fünf oben
für Sender
und Empfänger
beschriebenen Nachrichtenverstümmelungs-Detektionsmechanismen
finden auch auf Rauschverstümmelung
von Nachrichten Answendung. Detektion einer rauschinduzierten Unstimmigkeit
zwischen einem übertragenen
und empfangenen Byte durch den Sender, und durch Empfänger detektierte
Nachrichtenverstümmelungen,
einschließlich
Rahmenformat-Fehler;
Nachrichtenlängen-Fehler
und Prüfsummen-Fehler,
resultieren alle in der Übertragung
eines NACK durch den Knoten oder die Knoten der/die den Fehler detetiert/detektieren,
und im Abbruck der in Verarbeitung befindlichen Nachricht für alle Knoten
in dem Netzwerk.
-
Die
Software-Zustandsmaschine des Senders/Empfängers ist in 7 gezeigt.
Die Zustandsmaschine reagiert auf die Hardwarekomponenten des Mokrocontrollers
einschließlich
des UART, der Flankendetektions-Schnittstelle und des Zeitgebers.
Die möglichen
Zustände
der Zustandsmaschine sind ein Zustand Idle 30; eine Zustand
Wait_Format 32; einen Zustand Wait_Checksum 34;
einen Zustand Wait_RxNACK 36; einen Zustand Wait_TxNACK 38;
einen Zustand Drive_Break 40; und einen Zustand Wait_Break 42.
Eine Beschreibung der Zustände
folgt.
-
Idle
-
Der
Zustand Idle 30 entspricht fehlender Aktivität auf dem
Bus für
eine minimale Zeitdauer, „Max_Idle". Die Bedeutung dieses
Leerlaufzustands ist es, daß der
Versuch der Nachrichtenübertragung
sofort beginnt, wenn eine Nachrichtenübertragung durch die Anwendung
angefordert wird. Zusätzlich
werden während
des Leerlaufzustands unter Verwendung der maximalen Periode des
Zeitgebers 20 wiederholt Zeitgeber-Unterbrechungen terminiert,
um zu bestimmen wann eine Dauer von 1 Sekunde ohne jegliche Busaktivität verstrichen ist.
Die Bedeutung der Zeitdauer von 1 Sekunde ist es „schlafende" Anwendungen zu informieren,
das heißt Anwendungen
welche in einem Zustand mit niedrigem Dauerstrom eingeschaltet bleiben,
während
der Zündschalter
ausgeschaltet ist, um in einen Ruhemodus einzutreten. Wenn die Anwendung
den UBP-Treibercode aktiviert, wird die UBP-Zustandsmaschine in den Leerlaufzustand
versetzt.
-
Wait_Format
-
Der
Zustand Wait_Format 32 ist ein Zwischenzustand zwischen
dem Abschluß einer
Nachricht auf dem Bus und dem Leerlaufzustand. Knoten können versuchen
während
des Zustands Wait_Format zu senden. Die Zeit, zu welcher ein Knoten
seinen Sendeversuch beginnt, während
man sich in diesem Zustand befindet, muß relativ zu einer Zeitgeber-Referenz
terminiert werden, die zuletzt bei Empfang des Prüfsummen-Bytes
der vorigen Nachricht auf dem Bus geschaffen wurde. Die Minimalzeit
die ein Knoten warten muß, um
von der Zeitgeber-Referenz
ausgehend zu übertragen,
ist ein Intervall „Min_TWI", welches das minimale Übertragungs-Warteintervall
ist. Dieses Intervall ist definiert um zu garantieren daß alle Knoten
auf dem Bus in den Zustand Wait_Format fortgeschritten sind und
bereit sind das erste Byte einer Nachricht zu empfangen. Dieses
Minimalintervall muß die
zulässige
Ansammlung von Anwendungsunterbrechungs-Latenzzeiten für jeden
Knoten auf dem Bus im schlimmsten Fall in Betracht ziehen, ebenso
wie mit jedem Knoten auf dem Bus in Zusammenhang stehende Oszillatortoleranzen
im schlimmsten Fall.
-
Wait_Checksum
-
Der
Zustand Wait_Checksum 34 ist der Zustand, in welchem die
verbleibenden Bytes in der Nachricht bis zu und einschließlich des
Prüfsummen-Bytes
durch einen Knoten empfangen werden. Wenn ein Knoten ein Sender
ist, so prüft
der Knoten während
er sich in diesem Zustand befindet einfach ein empfangenes Byte, um
sicherzustellen daß es
das gleiche Byte ist wie das zuvor übertragene. Jegliche Unstimmigkeit
bewirkt die Erzeugung eines Unterbrechungssignals. Ist ein Knoten
ein Empfänger,
so schließt
das erste Byte der empfangenen Nachricht, das Formatbyte, einen
Datenlängen-Code
ein, und so ist ein Empfänger
in der Lage zu bestimmen wie viele Nachrichtenbytes zu empfangen
sind, bevor ein empfangenes Byte als Prüfsummen-Byte zu identifizieren ist. Während jede
Nachricht empfangen wird, wird ein Prüfsummen-Byte berechnet. Ist
das Prüfsummen-Byte
empfangen, so wird es mit der berechneten Prüfsumme verglichen. Jegliche
Unstimmigkeit resultiert in der Übertragung
eines Unterbrechungs- oder NACK-Signals (Negative ACKnowledgement).
-
Auf
jeden Empfang eines Nachrichtenbytes hin terminiert jeder Knoten
eine Zeitgeber-Unterbrechung für 20 Bitdauern
ab jener Zeit, zu der das Byte empfangen wird. Wenn der Sender und
der Empfänger
beide richtig funktionieren und wenn die Unterbrechungs-Latenzanforderung
sowohl für
den Sender wie auch den Empfänger
auf dem Bus erfüllt
wird, dann sollte das nächste übertragene
Byte auf dem Bus innerhalb von 20 Bitdauern empfangen werden. Dieser
Etat von 20 Bitdauern schließt
ein Maximum von 7 Bitdauern als zulässige Unterbrechungstlatenz
ein, einen Etat von 3 Bitdauern um die empfangene Unterbrechung
zu verarbeiten, und die Zeichenlänge
von 10 Biteinheiten jedes UBP-Zeichens. Wenn eine Zeitgeber-Unterbrechung
auftritt bevor ein erwartetes Byte empfangen wird, wird eine Fehlerbedingung
interpretiert und ein Unterbrechungssignal gesendet.
-
Wait_RxNACK
-
Der
Zustand Wait_RxNACK 36 ist der nächste Zustand, der nach erfolgreichem
Empfang des Prüfsummen-Bytes
definiert ist. Nachdem das Prüfsummen-Byte
empfangen ist wird eine Zeitgeber-Unterbrechung für 20 Bitdauern
ab jener Zeit terminiert, zu der das Prüfsummen-Byte empfangen wurde.
Der Zweck dieses Zustands ist es die Möglichkeit zu erlauben, daß das Formatbyte,
und spezieller der in dem Formatbyte eingeschlossene Datenlängen-Code
durch Rauschen oder durch eine Kollision verstümmelt wurde. Erwartet ein Empfänger in
einer Nachricht mehr Bytes als der Sender überträgt, so muß der Zeitgeber-Unterbrechung von
20 Bitdauern ausreichend Zeit gelassen werden um aufzutreten, und
dem empfangenden Knoten um ein Unterbrechungssignal zu senden und
es durch den Sender rechtzeitig erkennen zu lassen, um die Nachricht erneut
zu senden. Das Zeitintervall von 20 Bitlängen zieht die Ansammlung maximal
zulässiger
Unterbrechungs-Latenzzeiten für
den schlimmsten Fall ebenso in Betracht wie Oszillatortoleranzen
im schlimmsten Fall.
-
Verstümmelung
des Datenlängen-Codes
durch Rauschen oder durch eine Kollision auf dem Bus kann einen
Empfänger
auch dazu bringen weniger Bytes zu erwarten als tatsächlich durch
einen Sender übertragen werden.
Während
dieses Zustandes erwartet ein Empfänger keinerlei empfangene Bytes,
und so wird ein Unterbrechungssignal versandt und die empfangene
Nachricht wird ignoriert, wenn während
dieses Zustands ein Byte empfangen wird. Unter normalen Bedingungen
wird während
dieses Zustands kein Byte empfangen, und die Zeitgeber-Unterbrechung tritt
wie terminiert 20 Bitdauern nach Empfang des Prüfsummen-Bytes auf. Wenn alle
anderen Nachrichtenprüfungen
richtig befriedigt wurden, bewirkt die Zeitgeber-Unterbrechung, welche während dieses
Zustandes auftritt, daß die
empfangene Nachricht angenommen und an die Wirtsanwendung weitergegeben
wird.
-
Wait_TxNACK
-
Der
Zustand Wait_TxNACK 38 läßt ausreichend Zeit zu, damit
durch empfangende Knoten gesendete Unterbrechungssignale durch den
sendenden Knoten empfangen und erkannt werden, bevor er eine Nachricht für erfolgreich übertragen
erklärt.
Empfangende Knoten können
eine Unterbrechung nur bis und einschließlich des Zustands Wait_RxNACK übertragen.
Im Zustand Wait_TxNACK haben Empfänger empfangene Nachrichten
bereits für
gültig
erklärt,
und so wird der Empfang jeglichen Bytes, ob gültig oder mit einem Rahmenfehler, durch
den empfangenden Knoten einfach ignoriert. Empfängt ein übertragender Knoten jedoch
während
dieses Zustandes ein NACK, was möglicherweise
durch einen Empfänger
in seinem Zustand Wait_RxNACK eingeleitet wurde, durch den Sender
jedoch bis zu seinem Zustand Wait_TxNACK nicht empfangen wird, so nimmt
der Sender an daß die
Nachricht nicht erfolgreich empfangen wurde und überträgt die Nachricht erneut.
-
Es
sollte bemerkt werden daß es
im dem Fall von mehreren Empfängern
einer gegebenen Nachricht für
einige Empfänger
möglich
ist eine Nachricht als erfolgreich empfangen zu deklarieren, wohingegen
andere Empfänger
dies nicht tun und eine Unterbrechung senden, was den Sender dazu
zwingt die Nachricht erneut zu übertragen.
-
Neuübertragung
der Nachricht impliziert, daß einige
Empfänger
eine gegebene Nachricht mehr als einmal erhalten. Aus diesem Grund
können
Nachrichten, welche „Relativbefehle" einschließen, wie
etwa stufenweise Zunahme oder Abnahme, in unterschiedlichen Empfängern unterschiedliche
Ergebnisse erzeugen und sollten vermieden werden, besonders für Nachrichten
mit mehreren Empfängern.
Eine grundlegende Designvoraussetzung in der Definition von UBP
ist es, daß ein
Sender niemals annimmt er habe eine Nachricht erfolgreich übertragen,
wenn sie tatsächlich
nicht erfolgreich durch einen Empfänger empfangen wurde, d.h. daß er keine
empfangenen Nachrichten verpaßt.
Es ist für
den Empfänger
jedoch akzeptabel die gleiche Nachricht mehr als einmal zu empfangen.
-
Es
gibt in UBP nur zwei Ereignisse, welche Übergänge von einem UBP-Zustand in
die anderen verursachen: 1) eine UART-Empfangsunterbrechung und
2) eine Zeitgeber-Unterbrechung. UBP speist die Empfangseingabe
des physischen Schichttransceivers 22 zu einem Flakendetektions-Eingang;
diese Eingabe wird benutzt um vor Übertragung eines Bytes auf
Busaktivität
zu prüfen,
steht aber nicht mit einer Unterbrechung in Zusammenhang. Damit
das Zustandsübergang-Diagramm
als umfassend betrachtet wird, muß das Auftreten jedes dieser
beiden Ereignisse für
jeden und alle Zustände
betrachtet werden.
-
Das
in
7 gezeigte UBP-Zustandsdiagramm schließt Zustände und Übergänge ein,
welche als „normal" betrachtet werden,
d.h. die mit erfolgreicher Nachrichtenübertragung und erfolgreichem
Nachrichtenempfang in Zusammenhang stehen; ebenso wie „Fehler"-Zustände und Übergänge, welche
als ein Ergebnis von Datenkollisionen, Rauschen, oder Unterbrechungslatenzen
der Wirtsanwendung auftreten, welche das für erfolgreiche Implementierung
von UBP zugelassene Maximum übersteigen.
In dem Diagramm von
7 werden die Zustandsübergänge, die
mit durchgezogenen Linien gezeigt sind, als Wege betrachtet, welche
für normale
Kommunikation gekreuzt werden; und die Zustandsübergänge welche als ein Ergebnis
von Fehlermodi auftreten sind als gestrichelte Linien gezeigt. Das
Folgende ist eine Beschreibung aller möglichen Zustandsübergänge welche
auftreten können,
und eine Beschreibung des Qualifizierungsereignisses und der -bedingungen
der als Ergebnis des speziellen Zustandsübergangs unternommenen Aktionen. Normale
Wege A.
Initialisierung
| Gegenwärtiger Zustand: | Undefiniert |
| Ereignis: | Initialisierung
durch Anwendung (Aufrufen von „nadinit") |
| Nächster Zustand: | Leerlauf |
| Aktionen: | Terminiere
Zeitgeber-Unterbrechung für
Maximalverzögerung |
B.
Leerlaufunterbrechung im Leerlaufzustand
| Gegenwärtiger Zustand: | Leerlauf |
| Ereignis: | Zeitgeber-Unterbrechung |
| Nächster Zustand: | Leerlauf |
| Aktionen: | Lösche Zeitgeber-Unterbrechung |
| | WENN
(Nachricht wartet auf Übertragung) |
| | WENN
(nicht an Fehlergrenze) |
| | WENN
(Flankendetektion nicht gesetzt) |
| | WENN
(Wiederholungsversuch<Wiederholungsgrenze)
Übertrage
das Formatbyte
Initialisiere die Übertragungs-Prüfsumme
Setze
Merker „Übertrage
gegenwärtige
Nachricht" |
| | SONST |
| | Berichte
erreichte Wiederholungsgrenze an Anwendung |
| | SONST |
| | Setze
Zeitgeber-Unterbrechung auf gegenwärtige Zeit
Setze Zeitgeber-Unterbrechung
für 10
Bitdauern ab der gegenwärtigen
Zeit |
| | SONST |
| | WENN
(Leerlauf-Zeitgeber > 1
Sekunde)
Setze Merker „Leerlauf
für 1 Sekunde" |
| | SONST |
| | Setze
Zeitgeber für
Maximalverzögerung |
C.
Gültiges
Formatbyte im Leerlaufzustand empfangen
| Gegenwärtiger Zustand: | Leerlauf |
| Ereignis: | gültiges Formatbyte
empfangen |
| Nächster Zustand: | Wait_Checksum |
| Aktionen: | Setze
Zeitgeberreferen auf gegenwärtige
Zeit
Lösche
den Eingangserfassungs-Merker |
| | WENN
(Übertrage
gegenwärtige
Nachricht) |
| | WENN
(Empfangenes Byte = übertragenes
Formatbyte) |
| | UND
Eingangserfassungs-Merker gelöscht
Übertrage
Zielbyte
Erhöhe
Zeiger auf nächstes
zu übertragendes
Byte
Addiere Zielbyte zu Übertragungs-Prüfsumme |
| | SONST |
| | Speichere
empfangenes Formatbyte
Initialisiere empfangene Prüfsumme
Setze
Zeitgeber-Unterbrechung für
20 Bitdauern vom Zeitgeber-Bezug |
D.
Gültiges
Nachrichtenbyte (nicht die Prüfsumme)
im Status Wait_Checksum State empfangen
| Gegenwärtiger Zustand: | Wait_Checksum |
| Ereignis: | gültiges Nachrichtenbyte
empfangen |
| Nächster Zustand: | Wait_Checksum |
| Aktionen: | Setze
Zeitgeber-Referenz auf gegenwärtige
Zeit
Lösche
den Eingangserfassungs-Merker |
| | WENN
(Übertragung
gegenwärtiger
Nachricht |
| | WENN
(empfangenes Byte = letztes Byte übertragen UND Eingangserfassungs-Merker
gelöscht |
| | WENN
(nächstes
zu übertragendes
Byte ist ein Nachrichtenbyte)
Übertrage nächstes Nachrichtenbyte
Erhöhe Zeiger
stufenweise auf das nächste
zu übertragende
Byte
Addiere Byte zur Übertragungs-Prüfsumme |
| | SONST |
| | Übertrage
das Prüfsummen-Byte |
| | SONST |
| | Speichere
empfangenes Byte
Frische empfangene Prüfsumme auf
Setze Zeitgeber-Unterbrechung
auf 20 Bitdauern vom Zeitgeber-Bezug |
E.
Gültiges
Prüfsummen-Byte
in Zustand Wait_Checksum empfangen
| Gegenwärtiger Zustand: | Wait_Checksum |
| Ereignis: | gültiges Nachrichtenbyte
empfangen |
| Nächster Zustand: | Wait_RxNACK |
| Aktionen: | Setze
Zeitgeber-Referenz auf gegenwärtige
Zeit
Lösche
den Eingabe-Erfassungsmerker
Setze Zeitgeber-Unterbrechung
auf 20 Bitdauern vom Zeitgeber-Bezug
Verringere den Fehlerzähler stufenweise
um 32 |
F.
Zeitgeber-Unterbrechung während
des Zustands Wait_RxNAKC
| Gegenwärtiger Zustand: | Wait_RXNACK |
| Ereignis: | Zeitgeber-Unterbrechung |
| Nächster Zustand: | Wait_TxNACK |
| Aktionen: | Lösche den
Eingabe-Erfassungsmerker |
| | WENN
(keine gegenwärtige
Nachricht wird übertragen)
Übergebe
empfangene Nachricht an Anwendung
Setze Zeitgeber-Unterbrechung
auf 51 Bitdauern von der Zeitgeberreferenz |
G.
Zeiteber-Unterbrechung während
des Zustands Wait_TxNACK
| Gegenwärtiger Zustand: | Wait_TxNACK |
| Ereignis: | Zeitgeber-Unterbrechung |
| Nächster Zustand: | Wait_Format |
| Aktionen: | Lösche den
Eingangserfassungs-Merker |
| | Wenn
(Übertragung
gegenwärtiger
Nachricht)
Berichte Nachricht Tx vollständig
Setze Zeitgeber-Unterbrechung
für Max_Idle
von Zeitgeber-Referenz |
| | SONST |
| | WENN
(Nachricht wartet auf Übertragung) |
| | WENN
(Wiederholungsgrenze nicht erreicht)
Terminiere nächsten Übertragungsversuch |
| | SONST |
| | Setze
Zeitgeber-Unterbrechung für
Max_Idle von Zeitgeber-Referenz |
| | SONST |
| | Setze
Zeitgeber-Unterbrechung für
Max_Idle von Zeitgeber-Referenz |
H.
Zeitgeber-Unterbrechung während
in Zustand Wait_Format UND auf Übertragung
wartende Nachricht
| Gegenwärtiger Zustand: | Wait_Format |
| Ereignis: | Zeitgeber-Unterbrechung
UND ausstehende Nachrichtenübertragung |
| Nächster Zustand: | Wait_Format |
| Aktionen: | WENN
(nicht an Fehlergrenze) |
| | WENN
(Flankendetektion nicht gesetzt) |
| | WENN
(Wiederholungsversuch < Wiederholungsgrenze)
Übertrage
das Formatbyte
Initialisiere die Übertragungs-Prüfsumme
Setze
Merker „Übertrage
gegenwärtige
Nachricht" |
| | SONST |
| | Berichte
Wiederholungsgrenze erreicht an Anwendung |
| | SONST |
| | Setze
Zeitgeber-Referens auf gegenwärtige
Zeit
Setze Zeitgeber-Unterbrechung für 10 Bitdauern von der gegenwärtigen Zeit |
I.
Zeitgeber-Unterbrechung während
in zustand Wait_Format UND keine auf Übertragung wartende Nachricht
| Gegenwärtiger Zustand: | Wait_Format |
| Ereignis: | Zeitgeber-Unterbrechung
UND keine ausstehende Nachrichtenübertragung |
| Nächster Zustand: | Leerlauf |
| Aktionen: | Lösche Schlummer-Zeitgeber
Setze
nächste
Zeitgeber-Unterbrechung für
maximale Zeitgeber-Periode |
J.
Gültiges
Formatbyte empfangen während
in Zustand Wait_Format
| Gegenwärtiger Zustand: | Wait_Format |
| Ereignis: | gültiges Formatbyte
empfangen |
| Nächster Zustand: | Wait_Checksum |
| Aktionen: | Setze
Zeitgeber-Referenz auf gegenwärtige
Zeit
Lösche
den Eingangs-Erfassungsmerker |
| | WENN
(übertrage
gegenwärtige
Nachricht) |
| | WENN
(empfanges Byte = Formatbyte übertragen UND
Eingangserfassungs-Merker gelöscht)
Übertrage
Zielbyte
Erhöhe
Zeiger auf nächstes
zu übertragendes
Byte |
| | stufenweise
Addiere
Zielbyte zu Übertragungs-Prüfsumme hinzu. |
| | SONST |
| | Speichere
empfangenes Formatbyte
Initialisiere empfangene Prüfsumme
Setze
Zeitgeber-Unterbrechung auf 20 Bitdauern von Zeitgeber-Referenz |
Fehlerwege K.
Byte (ohne Rahmenfehler) empfangen während im Zustand Wait_Tx_NACK
| Gegenwärtiger Zustand: | Wait_TxKNACK |
| Ereignis: | Byte
(ohne Rahmenfehler) empfangen, während
im Zustand
Wait_Tx_NACK |
| Nächster Zustand: | Wait_TxKNACK |
| Aktionen: | Lösche Eingangs-Erfassungsmerker |
L.
Ungültiges
Byte empfangen während
im Leerlaufzustand
| Gegenwärtiger Zustand: | Leerlauf |
| Ereignis: | Eine
der folgenden Bedingungen schaft ein Ereignis eines ungültig empfangenen
Bytes:
1. Das empfangene Byte weist einen Rahmenfehler auf
2.
Dieser Knoten überträgt, und
das empfangene Byte paßt
nicht zu dem übertragenen
Byte |
| Nächster Zustand: | Drive_Break |
| Aktionen: | Deaktiviere
UART
Treibe Tx-Pin passiv an
Erhöhe den Fehlerzähler stufenweise |
| | WENN
(Fehlerzähler
bei 255)
Setze Fehlergrenzen-Merker (verhindere Busübertragungen) |
| | SONST |
| | Treibe
den Tx-Pin aktiv an (beginne Unterbrechungsübertragung)
Setze Zeitgeber-Referenz
auf gegenwärtige
Zeit
Setze Zeitgeber-Unterbrechung für 10 Bitdauern von |
| | der
Zeitgeber-Referenz |
| | WENN
(übertrage
gegenwärtige
Nachricht)
Stoppe Übertragung |
M.
Fehlerereignis während
im Zustand Wait_Checksum
| Gegenwärtiger Zustand: | Wait_Checksum |
| Ereignis: | Jede
der folgenden Bedingungen stellt ein Fehlerereignis dar, welches
dieses verursacht:
Übergang:
1.
Ungültiges
Byte (mit Rahmenfehler) empfangen;
2. Ungültige Prüfsumme empfangen (berechnete Prüfsumme paßt nicht
zur empfangenen Prüfsumme);
3.
Zeitgeber-Unterbrechung (deutet abgelaufene Zeit an, während auf
ein Byte gewartet wird);
4. Wenn übertragen wird, paßt empfangenes
Byte nicht zu übertragenem
Byte. |
| Nächster Zustand: | Drive_Break |
| Aktionen: | Deaktiviere
UART
Treibe Tx-Pin passiv an
Erhöhe den Fehlerzähler 255
stufenweise |
| | WENN
(Fehlerzähler
bei 255)
Setze Fehlergrenzen-Merker (hindert Busübertragung) |
| | SONST |
| | Treibe
Tx-Pin aktiv an (starte Unterbrechungsübertragung
Setze Zeitgeber-Referenz
auf gegenwärtige
Zeit
Setze Zeitgeber-Unterbrechung auf 10 Bitdauern von der
Zeitgeber-Referenz |
| | WENN
(übertrage
gegenwärtige
Nachricht) Stoppe Übertragung |
N.
Byte empfangen (mit oder ohne Rahmenfehler) während im Zustand Wait_RxNACK
| Gegenwärtiger Zustand: | Wait_RxNACK |
| Ereignis: | Byte
empfangen (mit oder ohne Rahmenfehler) |
| Nächster Zustand: | Drive_Break |
| Aktionen: | Deaktiviere
UART
Treibe Tx-Pin passiv an
Erhöhe den Fehlerzähler 255
stufenweise |
| | WENN
(Fehlerzähler
bei 255)
Setze Fehlergrenzen-Merker (hindert Busübertragung) |
| | SONST |
| | Treibe
Tx-Pin aktiv an (starte Unterbrechungsübertragung
Setze Zeitgeber-Referenz
auf gegenwärtige
Zeit
Setze Zeitgeber-Unterbrechung auf 10 Bitdauern von der
Zeitgeber-Referenz |
| | WENN
(übertrage
gegenwärtige
Nachricht)
Stoppe Übertragung |
O.
Ungültiges
Byte empfangen (mit Rahmenfehler) während im Zustand Tx_NACK
| Gegenwärtiger Status: | Wait_TxNACK |
| Ereignis: | Byte
empfangen (mit Rahmenfehler) |
| Nächster Zustand: | Drive_Break |
| Aktionen: | Deaktiviere
UART
Treibe Tx-Pin passiv an
Erhöhe den Fehlerzähler 255
stufenweise |
| | WENN
(Fehlerzähler
bei 255)
Setze Fehlergrenzen-Merker (hindert Busübertragung) |
| | SONST |
| | Treibe
Tx-Pin aktiv an (starte Unterbrechungsübertragung
Setze Zeitgeber-Referenz
auf gegenwärtige
Zeit
Setze Zeitgeber-Unterbrechung auf 10 Bitdauern von der
Zeitgeber-Referenz |
| | WENN
(übertrage
gegenwärtige
Nachricht)
Stoppe Übertragung |
P.
Ungültiges
Byte empfangen während
im Zustand Wait_Format
| Gegenwärtiger Zustand: | Wait_Format |
| Ereignis: | Eine
der folgenden Bedingungen schaft ein Ereignis eines |
| | ungültig empfangenen
Bytes:
Das empfangene Byte weist einen Rahmenfehler auf
Dieser
Knoten überträgt, und
das empfangene Byte paßt
nicht zu dem übertragenen
Byte |
| Nächster Zustand: | Drive_Break |
| Aktionen: | Deaktiviere
UART
Treibe Tx-Pin passiv an
Erhöhe den Fehlerzähler stufenweise |
| | WENN
(Fehlerzähler
bei 255)
Setze Fehlergrenzen-Merker (verhindere Busübertragungen) |
| | SONST |
| | Treibe
den Tx-Pin aktiv an (beginne Unterbrechungsübertragung)
Setze Zeitgeber-Referenz
auf gegenwärtige
Zeit
Setze Zeitgeber-Unterbrechung für 10 Bitdauern von der Zeitgeber-Referenz |
| | WENN
(übertrage
gegenwärtige
Nachricht)
Stoppe Übertragung |
Q.
Zeitgeber-Unterbrechung während
in Zustand Drive_Break
| Gegenwärtiger Zustand: | Drive_Break |
| Ereignis: | Zeitgeber-Unterbrechung |
| Nächster Zustand: | Wait_Break |
| Aktionen: | Lösche Eingangs-Erfassungsmerker
Treibe
Tx-Pin passiv an (Stoppe Unterbrechungsübertragung)
Initialisiere
den UART erneut |
| | Setze
Zeitgeber-Unterbrechung für
20 Bitdauern von der Zeitgeber Referenz |
R.
Zeitgeber-Unterbrechung während
in Zustand Wait_Break
| Gegenwärtiger Zustand: | Wait_Break |
| Ereignis: | Zeitgeber-Unterbrechung |
| Nächster Zustand: | Wait_Format |
| Aktionen: | Ziehe
20 Bitdauern von der Zeitgeber-Referenz ab, um die nächsten Übertragungsversuche
vorzuziehen |
| | Lösche den
Eingangs-Erfassungsmerker |
| | WENN
(Nachricht wartet auf Übertragung) |
| | WENN
(Wiederholungsgrenze nicht erreicht)
Terminiere nächsten Übertragungsversuch |
| | SONST |
| | Setze
Zeitgeber-Unterbrechung für
Max_Idle von Zeitgeber-Referenz |
| | SONST |
| | Setze
Zeitgeber-Unterbrechung für
Max_Idel von Zeigeber-Referenz |
S.
Byte empfangfan während
in Zustand Drive_Break
| Gegenwärtiger Zustand: | Drive_Break |
| Ereignis: | Byte
empfangen |
| Nächster Zustand: | Drive_Break |
| Aktionen: | WENN
(Byte weist Rahmenfehler auf)
Erhöhe Fehlerzähler stufenweise |
T.
Byte empfangen während
in Zustand Wait_Break
| Gegenwärtiger Zustand: | Wait_Break |
| Ereignis: | Byte
empfangen |
| Nächster Zustand: | Wait_Break |
| Aktionen: | WENN
(Byte weist Rahmenfehler auf)
Erhöhe Fehlerzähler stufenweise |
-
Beziehung zwischen Nachrichten-Wellenformen
und UBP-Zuständen
-
Normale Kommunikation
-
Eine
Wellenform einer UBP-Nachricht ist in 8 zusammen
mit zusätzlichen
diagnostischen Wellenformen gezeigt. In dieser Wellenform überträgt Knoten
1A und Knoten 2A und 2B empfangen die Sendung von Knoten 1A. Ein
Puls, der anzeigt wo Knoten 1A seine Nachricht als erfolgreich übertragen
erklärt,
ist in den UBP-Treibercode eingeschlossen. Dieser Punkt tritt an
der ansteigenden Flanke des Signals „TXOK1A" auf und entspricht dem Ende des Intervalls
Wait_TxNACK des übertragenden
Knotens. Die Zeit vom Ende des übertragenen
Prüfsumme-Bytes
bis zur ansteigenden Flanke von TXOK1A ist 5,413 ms, was ungefähr 51 Bitperioden
bei 104μS
pro Bitdauer bedeutet. Der Punkt an welchem Knoten 2A und 2B empfangene
Nachrichten als gültig
erklären
tritt entsprechend an der aufsteigenden Flanke der Signale „RXOK2A" und „RXOK2B" auf. Die Zeit vom
Ende der übertragenen
Prüfsumme
zum Ende des Zustands Wait_RxNACK beträgt 2,199mS, was ungefähr 20 Bitdauern
bei 104μS
pro Bitdauer bedeutet.
-
Fehlermodus-Betrieb
-
Den
Fehler-Betriebsmodus des UBP's
veranschaulichende Wellenformen sind in 9 gezeigt,
die ein System veranschaulicht für
welches es auf dem Bus 4 Knoten gibt; Knoten 1A, 1B, 2A und 2B. 4 zeigt die
Wellenform des Bus („Bus") zusammen mit den
aus dem Tx-Pin jedes der einzelnen Knoten des Systems herausgetriebenen
und in den Übertragungspin
der physischen Schicht dieses speziellen Knotens hinein getriebenen
Logiksignalen (TXLGxx, wobei xx identifiziert welcher Knoten) zeigt.
Für diesen
speziellen physischen Schichttransceiver ist das Logikniveau am
Eingang zum Transceiver (TXLGxx) invertiert, d.h. ein Zustand logischer
Eins am Eingang erzeugt einen Zustand logischer Null am Ausgang.
Das Signal BUS ist eine zusammengesetzte Wellenform der einzelnen Übertragungen
jedes der Knoten auf dem Bus; derart, daß jedes durch irgendeinen einzelnen
Knoten übertragenes,
dominantes Signal jeden rezessiven Zustand auf dem Bus überschreibt.
-
In
dem Beispiel von 9 versuchen zwei Knoten (1A
und 1B) gleichzeitig zu übertragen,
was in einer Kollision auf dem Bus resultiert. In diesem Fall übertragen
beide Knoten das gleiche Formatbyte, und so ist keiner der Knoten
auf dem Bus in der Lage irgendeine Unstimmigkeit zu detektieren;
einschließlich
der zwei Sender, welche jeder das Gleiche Byte empfangen das sie
gesendet haben. Das zweite auf dem Bus übertragene Byte, das Zielbyte,
ist für
die beiden sendenden Knoten unterschiedlich, und die aufgrund der
Kollision resultierende Wellenform auf dem Bus paßt weder
zur Übertragung
von Knoten 1A noch von 1B. Nach Empfang des zweiten Bytes detektieren
beide Sender die Unstimmigkeit und senden ein Unterbrechungssignal
(10 Bitdauern von dominatem Zustand). Das zweite Byte scheint den
beiden anderen Empfängern
auf dem Bus, den Knoten 2A und 2B, eine gültiges Byte zu sein. Als ein
Ergebnis senden die beiden Empfänger
ein Unterbrechungssignal nur als ein Ergebnis und in Folge der Unterbrechungssignale
sendenden Knoten 1A und 1B.
-
Während ein
Knoten sein Unterbrechungssignal sendet, befindet er sich im Zustand „Drive_Break". Nach vollständiger Übertragung
der Unterbrechung befindet sich der Knoten für 10 zusätzliche Bitdauern im Zustand „Wait_Break". Man bemerke, daß in diesem
Fall, wo die Empfänger
keinen Fehler detektieren bis das Unterbrechungssignal durch die
Sender gesendet wird, Zeitdauern vorhanden sind während welcher
Sender und Empfänger
auf dem Bus sich nicht in den gleichen Softwarezuständen befinden.
Nachdem eine Unterbrechung abgeschlossen ist, „zieht" die UBP-Implementierung „vor" die Zeit, zu welcher
der Knoten möglicherweise
versuchen wird die nächste
Nachricht zu übertragen,
indem der Zeitgeber-Referenzwert
angepaßt
wird. Ein Knoten muß jedoch
ausreichend lange warten um es allen anderen Knoten zu erlauben
eine Unterbrechungssequenz abzuschließen und in den Zustand „Wait_Format" einzutreten; so
daß sie
in der Lage sind das erste Byte der nächsten Nachricht richtig zu
empfangen. In diesem Fall muß Knoten
1A ausreichend lange warten nachdem er seine Unterbrechungssequenz
abgeschlossen hat, um es den Empfängern – den Knoten 2A und 2B – zu erlauben
Unterbrechungssequenzen abzuschließen und in den Zustand „Wait_Format" einzutreten.