DE4131133A1 - Verfahren und vorrichtung zum austausch von daten in datenverarbeitungsanlagen - Google Patents
Verfahren und vorrichtung zum austausch von daten in datenverarbeitungsanlagenInfo
- Publication number
- DE4131133A1 DE4131133A1 DE4131133A DE4131133A DE4131133A1 DE 4131133 A1 DE4131133 A1 DE 4131133A1 DE 4131133 A DE4131133 A DE 4131133A DE 4131133 A DE4131133 A DE 4131133A DE 4131133 A1 DE4131133 A1 DE 4131133A1
- Authority
- DE
- Germany
- Prior art keywords
- message
- data
- connection
- messages
- field
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40169—Flexible bus arrangements
- H04L12/40176—Flexible bus arrangements involving redundancy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40208—Bus networks characterized by the use of a particular bus standard
- H04L2012/40215—Controller Area Network CAN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
- Computer And Data Communications (AREA)
Description
Die Erfindung geht aus von einem Verfahren zum Austausch von Daten
in Datenverarbeitungsanlagen nach der Gattung des Hauptanspruchs.
In den letzten Jahren wurde in Prozeßsteuerungen - insbesondere in
Kraftfahrzeugen, Robotern und medizinischen Überwachungs- und Analysegeräten,
in Aufzugsystemen, usw. - der Datenaustausch zwischen
den einzelnen Steuer- und Regeleinheiten zunehmend mit Hilfe von
Verfahren zum seriellen Datenaustausch abgewickelt. Ein solches Verfahren
ist aus der Patentschrift DE 35 06 118 C2 bekannt; sie beschreibt
die Abwicklung des Datenaustauschs mit Hilfe eines besonderen
Datenübertragungsprotokolls, daß unter dem Namen CAN-Protokoll
bekannt geworden ist. Weiterhin ist ein solches Verfahren aus der
noch nicht veröffentlichten Patentanmeldung DE-P 41 10 428 bekannt,
welche die Abwicklung des Datenaustausches gemäß einem erweiterten
CAN-Protokoll beschreibt. Die heute auf dem Markt verfügbaren
Schnittstellen-Bausteine, die den Datenaustausch nach dem CAN-Protokoll
durchführen, decken gemäß dem ISO/OSI-Schichtenmodell
(ISO-Standard 7498 sowie 8802.2/3) nur die untersten logischen
Schichten, nämlich Physical Layer, Medium Access Control Sublayer
(MAC) und Teile der Logical Link Control Sublayer (LLC).
Damit lassen sich aber keine Daten derart zwischen zwei oder mehr
Stationen übertragen, daß die Empfänger der Daten den korrekten
Empfang der Daten durch Rücksendung einer Quittungsnachricht bestätigen.
Ebenfalls ist es nicht möglich, längere Datensätze segmentiert
zu übertragen, so daß der Empfänger die einzelnen Datensegmente
als zu einem Datensatz zugehörig erkennt. Weiterhin sind Protokolle
bekannt, die mit Hilfe von Quittungsnachrichten abgesicherte
Datenübertragungen und auch die segmentierte Übertragung längerer
Datensätze ermöglichen. Diese Protokolle werden heute zum Beispiel
bei der Rechnerkopplung eingesetzt. Hierbei handelt es sich um verbindungsorientierte
Protokolle, die für Anwendungen bei Prozeßsteuerungen
zu aufwendig und damit ungeeignet sind. Bei ETHERNET
sind beispielsweise bei jeder Datenbotschaft umfangreiche Kontrollinformationen,
unter anderem Quell- und Zielinformationen, auf der
Sicherungsschicht (DATA-LINK-Layer) mitzuübertragen, was im Zusammenhang
mit Kommunikationsprotokollen wie dem CAN-Protokoll wegen
der geringen Datenmenge pro Botschaft (0-8 Bytes) zu einem sehr
geringen Datendurchsatz führen würde.
Für den Einsatz in Prozeßsteuerungen wie dem Kraftfahrzeug geeignete
Verfahren für eine angemessene Absicherung der Datenübertragung
und/oder zum Austausch größerer Datensätze sind bislang nicht eingeführt.
Das erfindungsgemäße Verfahren mit den kennzeichnenden Merkmale des
Hauptanspruchs hat demgegenüber den Vorteil, daß trotz der Einschränkungen,
wie sie bei Protokollen zur Prozeßsteuerung gegeben
sind, ein sicherer Datenaustausch mit Hilfe eines Quittungsbetriebes
gewährleistet wird. Außerdem können längere Datensätze, wie sie etwa
zur Konfiguration oder Initialisierung von Komponenten in Datenverarbeitungsanlagen
zur Prozeßsteuerung vorkommen, mit sehr geringem
Aufwand segmentiert und übertragen werden. Die Segmentierung längerer
Datensätze und deren sichere Übertragung kann gemäß des erfindungsgemäßen
Verfahrens so vorgenommen werden, daß pro Botschaft
höchstens ein Byte für Kontrollinformationen notwendig ist. Damit
kann das erfindungsgemäße Transportprotokoll sehr vorteilhaft auch
zusammen mit Kommunikationsprotokollen wie CAN eingesetzt werden.
Durch die in den Unteransprüchen aufgeführten Maßnahmen sind vorteilhafte
Weiterbildungen und Verbesserungen des im Hauptanspruch
angegebenen Verfahrens möglich. Besonders vorteilhaft ist, zur Einrichtung
einer Nachrichten-Verbindung in den Stationen der Nachrichten-Verbindung
jeweils ein Sende- und Empfangsobjekt zu speichern.
Dies kann bei Inbetriebnahme des Systems geschehen, so daß für die
Einrichtung der Verbindungen keine Nachrichten zwischen den kommunizierenden
Stationen übertragen werden müssen und während des Betriebs
zu keiner Zeit die Notwendigkeit besteht, Quell- und Zieladressen
mitzuübertragen. Weiterhin ist es vorteilhaft, zur Aktivierung
einer Nachrichten-Verbindung eine Aktivierungs-Nachricht von
einer Station auszugeben, die von der empfangenden Station durch
eine Bestätigungsnachricht quittiert wird und die Aktivierung der
Nachrichten-Verbindung den Benutzern der Verbindung mitzuteilen.
Dadurch findet eine zusätzliche Überprüfung der Nachrichten-Verbindung
vor der eigentlichen Datenübertragung statt. Ebenfalls ist es
vorteilhaft, in den Kontrollinformationsfeldern der Botschaften, die
Datennachrichten oder Quittungsnachrichten übertragen, eine Sequenznummer
abzulegen. Damit läßt sich eine Unterscheidung aufeinanderfolgender
Datennachrichten, eine Erkennung von Datennachrichtenduplikaten
sowie eine Zuordnung von Quittungsnachrichten zu Datennachrichten
erreichen. Vorteilhaft ist es auch, in dem Kontrollinformationsfeld
einer die Quittungsnachricht übertragenden Botschaft ein
Empfängerstatusfeld vorzusehen und in dieses eine Information über
den Status des Empfängers einzutragen. Daraufhin kann die sendende
Station geeignete Maßnahmen, wie Absendung weiterer zusätzlicher Botschafter
oder Verzögerung der Absendung weiterer Botschaftsabsendungen
durchführen. Ebenfalls vorteilhaft ist es, beim Ausbleiben
einer Quittungsnachricht die Datennachricht nach einer vorbestimmten
Wartezeit erneut auszusenden und bei wiederholtem Ausbleiben der
Quittungsnachricht die Nachricht nur so oft erneut auszusenden, bis
eine bestimmte Anzahl von Sendewiederholungen erreicht ist, und bei
Überschreitung der bestimmten Anzahl von Sendewiederholungen die
Nachrichtenverbindung zu detektieren und die Deaktivierung der
Nachrichten-Verbindung den Benutzern mitzuteilen.
Für die Vorrichtung zum Aufbau der Botschaften ist es vorteilhaft,
in dem Schnittstellen-Baustein zur fortlaufenden Numerierung von
Datennachrichtensegmenten einen Sendefolgezähler zu installieren.
Weiterhin ist es vorteilhaft, einen Empfangsfolgezähler zu installieren,
der zur Speicherung der Sequenznummer der nächsten zum Empfang
erwarteten Nachricht oder des nächsten zum Empfang erwarteten
Datennachrichtsegmentes dient. Zur stationsübergreifenden Flußkontrolle
ist es vorteilhaft, den Inhalt des Empfängerstatusfeldes in
einem Zwischenspeicher zu speichern. Weiter vorteilhaft ist, zur
Kennzeichnung der Anzahl der Datensegmente einen Datensegmentspeicher
in der Vorrichtung vorzusehen, und zur Kennzeichnung der Gesamtlänge
der Datenbytes einer Datennachricht oder eines Datennachrichtsegmentes
einen Datenlängenspeicher zu installieren.
Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung anhand
mehrerer Figuren dargestellt und in der nachfolgenden Beschreibung
näher erläutert.
Es zeigt
Fig. 1 eine Darstellung zur Einordnung des erfindungsgemäßen
Verfahrens in das ISO/OSI-Schichtenmodell,
Fig. 2 eine allgemeine
Darstellung einer Punkt-zu-Punkt-Verbindung innerhalb einer
Schicht des ISO/OSI-Schichtenmodells,
Fig. 3a ein Ausführungsbeispiel
einer CAN-Verbindung zwischen zwei Stationen eines Datenverarbeitungssystem,
Fig. 3b den formalen Aufbau eines Sende- oder Empfangs-Objektes,
Fig. 4a die schematische Darstellung der Zuordnung
dreier Date Link- bzw. Transport-Verbindungen zu drei einzelnen
CAN-Verbindungen innerhalb des ISO/OSI-Schichtenmodells,
Fig. 4b
eine schematische Darstellung der Zuordnung dreier Date Link- bzw.
Transport-Verbindungen zu einer CAN-Verbindung innerhalb des
ISO/OSI-Schichtenmodells,
Fig. 4c die schematische Darstellung
einer Zuordnung von einer Data-Link- bzw. Transport-Verbindung zu
drei verschiedenen CAN-Verbindungen innerhalb des ISO/OSI-Schichtenmodells,
Fig. 5 den formalen Aufbau des Datenfeldes der Botschaften,
bei der Übertragung der verschiedenen Data-Link-Nachrichten,
Fig. 6 den formalen Aufbau des Kontrollinformationsfeldes der Botschaften
bei der Übertragung der verschiedenen Data-Link-Nachrichten,
Fig. 7 den Zustandsgraphen einer Data-Link-Sendeprotokollinstanz,
Fig. 8 den Zustandsgraphen einer Data-Link-Empfangsprotokollinstanz,
Fig. 9 den formalen Aufbau des Datenfeldes der Botschaften,
bei der Übertragung der verschiedenen Transport-Nachrichten,
Fig. 10 den formalen Aufbau des Kontrollinformationsfeldes der
Botschaften bei der Übertragung der verrschiedenen Transport-Nachrichten,
Fig. 11 ein Beispiel für die segmentierte Übertragung
einer 15 Bytes langen Datensatzes,
Fig. 12 den Zustandsgraphen
einer Transport-Sendeprotokollinstanz,
Fig. 13 den Zustandsgraphen
einer Transport-Empfangsprotokollinstanz.
Das im Ausführungsbeispiel beschriebene erfindungsgemäße Verfahren
baut auf dem CAN-Protokoll auf. Das Verfahren kann jedoch ebensogut
auf der Basis anderer Prozeßsteuerungsprotokolle, wie z. B. VAN oder
J1850, eingesetzt werden.
Das erfindungsgemäße Verfahren ermöglicht den sicheren Datenaustausch
zwischen zwei Stationen, die mittels des CAN-Protokolls (oder
eines anderen Prozeßsteuerungsprotokolls) kommunizieren. Fig. 1
zeigt die Einordnung des CAN-Protokolls 17 in das ISO/OSI-Schichtenmodell.
Das CAN-Protokoll 17 deckt darin die Bitübertragungsschicht
(Physical Layer 11) und Teile der Sicherungsschicht (Data-Link-Layer
16) ab. Die-Data-Link Layer 16 ist in eine MAC Sublayer 12 und eine
LLC Sublayer Type 1, 2, 3 Operation 13 unterteilt. Über der Data-Link-Layer
16 ist die Network Layer 14 und darüber die Transport Layer 15
angeordnet. An der Schnittstelle S1 des CAN-Protokolls 17 mit der
Data-Link-Layer 16 bietet das CAN-Protokoll 17 einen Dienst für die
unquittierte Übertragung von bis zu acht Byte langen Daten an. Dieser
Dienst ist vergleichbar dem ISO 8802-2 LLC Unacknowledged Conectionless-Mode
Data-Transfer-Service - Type 1 Operation. Aufbauend
auf diesem Dienst, ermöglicht das erfindungsgemäße Verfahren:
- 1) Die quittierte Übertragung einer Botschaft zwischen zwei Stationen (vergleichbar dem ISO 8802-2 LLC Acknowledged Connectionless-Mode Service - Type 3 Operation). Das den quittierten Übertragungsdienst erbringende Protokoll ist entsprechend ISO/OSI der Data-Link-Schicht 16 zuzuordnen, und wird im folgenden als Data-Link-Protokoll 18 bezeichnet (Beschreibung siehe 1.3).
- 2) Die sichere, segmentierte Übertragung von Daten beliebiger Länge zwischen zwei Stationen. Das den Dienst für die Übertragung langer Daten erbringende Protokoll ist entsprechend ISO/OSI der Transportschicht 15 zuzuordnen und wird im folgenden als Transport-Protokoll 19 bezeichnet (Beschreibung siehe 1.4).
Die Datenübertragung nach dem erfindungsgemäßen Verfahren erfolgt
über virtuelle Data-Link- bzw. Transport-Verbindungen, die bei der
Netzprojektierung festgelegt und bei Systeminitialisierung für die
Dauer der Systembetriebszeit eingerichtet werden. Die virtuellen
Data Link- bzw. Transport-Verbindungen sind dabei Nachrichten-Verbindungen
zwischen zwei Stationen des Datenverarbeitungssystems, die
nur zu bestimmten Zeiten (jeweils nach Aktivierung einer Verbindung)
benutzt werden. Die Übertragung der Nachrichten geschieht bei jeder
Nachrichten-Verbindung über das gleiche Übertragungsmedium 10, das
die einzelnen Stationen des Datenverarbeitungssystems miteinander
verbindet. Eine Data-Link-Verbindung wird dabei als Dienst der Data-Link-Schicht
dem Data-Link-Benutzer angeboten. Eine Transport-Verbindung
wird dabei als Dienst der Transport-Schicht dem Transport-Benutzer
angeboten. Da die Verbindungen bereits in der Netzprojektierungsphase
festgelegt werden, müssen bei ihrer Einrichtung keine
Nachrichten zwischen den kommunizierenden Instanzen ausgetauscht
werden.
Vor Beginn der eigentlichen, beliebig langen Datenübertragungsphase
wird in einer sogenannten Verbindungsaktivierungsphase die Kommunikationsbereitschaft
der den Verbindungsdient erbringenden Protokollinstanzen
durch ein Handshake-Verfahren überprüft. Nach erfolgreicher
Verbindungsaktivierung wissen die Kommunikationspartner, daß
eine Verbindung für die Kommunikation bereitsteht und daß die den
Verbindungsdienst erbringenden Protokollinstanzen im sende- bzw.
empfangsbereiten Zustand sind. Die Aktivierung einer Verbindung wird
von einem der beiden Kommunikationspartner oder von einer der entsprechenden
Schicht zugeordneten Netzmanagementinstanz angestoßen.
Im Falle (wiederholt) auftretender Fehler kann eine Verbindung automatisch
deaktiviert werden. Die erneute Aktivierung (Reaktivierung)
einer deaktivierten Verrbindung bewirkt, daß die den Verbindungsdienst
erbringenden Protokollinstanzen zurückgesetzt werden und
damit wieder in einem Zustand sind, in dem sie Daten austauschen
können.
Fig. 2 zeigt den Austausch von Daten über Punkt-zu-Punkt-Verbindungen
im Sinne des ISO/OSI-Schichtenmodells. Die Verbindung 24 verläuft
dabei zwischen zwei Protokollinstanzen der Schicht (N) und
wird den Benutzern der Schicht (N) als Dienst angeboten. Nachdem die
Verbindung 24 eingerichtet ist, können die Benutzer der Schicht (N)
Daten über diese Verbindung 24 nach dem Protokoll der Schicht (N)
miteinander austauschen. Dazu legt der Benutzer einen entsprechenden
Dienstauftrag, bestehend aus einem Kommando (z. B. T_DATA.request)
und den zu übertragenden Daten am Verbindungspunkt (CEP) (26, 28)
des Dienstzugangspunktes (SAP) (25, 27) ab. Dem Dienstauftrag müssen
keine Quell- und Zieladressen mitgegeben werden, da diese Information
implizit in der verwendeten Verbindung enthalten ist. Prinzipiell
können über eine Verbindung Daten in beiden Richtungen ausgetauscht
werden.
Das erfindungsgemäße Verfahren unterscheidet drei Arten von Verbindungen:
- 1) CAN-Verbindungen werden an der Schnittstelle S1 (Fig. 1) auf der Basis des CAN-Protokolls angeboten.
- 2) Data-Link-Verbindungen werden an der Schnittstelle S2 (Fig. 1) auf der Basis einer oder mehrerer CAN-Verbindungen angeboten.
- 3) Transport-Verbindungen werden an der Schnittstelle S3 (Fig. 1) auf der Basis einer oder mehrerer CAN-Verbindungen angeboten.
Fig. 3a zeigt ein Beispiel für die Realisierung einer CAN-Verbindung.
Der Aufbau eines Sendeobjektes 36, 37 und eines Empfangsobjektes
35, 38 ist in Fig. 3b dargestellt. Jedes Sende- und
Empfangsobjekt besitzt ein Kopffeld 39 und ein Datenfeld 40. Das
Kopffeld 40 wird im folgenden als IDENTIFIER bezeichnet. Das letzte
Bitfeld 41 des IDENTIFIER ist in Fig. 3b gesondert dargestellt. Ein
stationsübergreifendes Sende-/Empfangsobjekt-Paar 36, 38 bzw. 37, 35
mit gleichem IDENTIFIER 39, aber unterschiedlicher Belegung des
RECEIVE/TRANSMIT-Bits (LOW für das Sendeobjekt und HIGH für das
Empfangsobjekt) definiert dabei einen Kanal 32 bzw. 31, über den
Daten in eine Richtung übertragen werden können. Die Werte der
beiden IDENTIFIER 39, die eine Verbindung kennzeichnen sind
prinzipiell beliebig. Zweckmäßig ist die Wahl von IDENTIFIER 39, die
bis auf das Bit im letzten Bit-Feld 41 den gleichen Wert haben. Das
letzte Bit legt dann die Datenrichtung aus der Sicht einer Station
33, 34 fest. Die Verbindung selbst und ihre Priorität läßt sich
dadurch auf einfache Weise durch die ersten n-1 Bits des IDENTIFIER
39 identifizieren. Innerhalb einer Station repräsentiert das
Sende/Empfangs/objekt-Paar einer Verbindung den Verbindungsendpunkt
(CEP), 46 . . . 51.
Auf der Basis von CAN-Verbindungen können Verbindungen auf höheren
Schichten (Data-Link-Layer, Transport-Layer usw.) bei der Netzpprojektierung
eingerichtet werden. Die Adressierung dieser Verbindungen
und die Abbildung von Verbindungen der Schicht (N+1) auf Verbindungen
der Schicht (N) kann gemäß ISO 7498 erfolgen.
Fig. 4a zeigt schematisch die Abbildung von der Verbindung 46 in
der höheren Schicht 2 auf die Verbindung 49 in der niederen Schicht
1 mit Hilfe einer Protokollinstanz 52 in der Schicht 2. In gleicher
Weise wird die Verbindung 47 in der Schicht 2 auf die Verbindung 50
in der Schicht 1 und die Verbindung 48 auf die Verbindung 51 durch
die Protokoll-Instanz 52 abgebildet.
Für die Protokoll-Instanz 52 der Schicht 2 kommen hier z. B. eine
Data-Link- bzw. Transport-Protokollinstanz in Frage. Die Verbindungen
49, 50 und 51 stellen dann drei CAN-Verbindungen, die in der
Schicht 1 mit Hilfe einer CAN-Protokollinstanz betrieben werden,
dar.
Fig. 4b zeigt hingegen die Abbildung der drei Verbindungen 46, 47
und 48 der Schicht 7 auf lediglich eine CAN-Verbindung 49 in der
Schicht 1. Dies entspricht einem Multiplex-Mode der Protokollinstanz
52.
Fig. 4c zeigt die Abbildung der Verbindung 46 der Schicht 2 auf die
drei Verbindungen 49, 50 und 51 in der Schicht 1. Dies entspricht
einem "Splitting"-Mode der Protokollinstanz 52.
Auf der Basis des erweiterten CAN-Protokolls ist es möglich, eine
Verbindung zwischen einem Sender und mehreren Empfängern einzurichten
und Daten quittiert über eine sogenannten Mehrpunkt-Verbindung
zu übertragen. Die ersten 10 Bits des kurzen Identifizierers im
erweiterten CAN-Protokoll identifizieren dabei die Verbindung. Das
letzte Bit des kurzen Identifizierers legt die Datenrichtung fest.
bei Empfang einer Botschaft werten die Empfänger den kurzen Identifizierer
aus und übernehmen gegebenenfalls die Botschaft. Die Empfänger
bestätigen die Übernahme von Botschaften durch das Senden
einer Quittungsnachricht, wobei die letzten 18 Identifiziererbits
("Identifier Extension") der die Quittung übertragenden Botschaft
den Sender der Quittungsnachricht identifizieren.
Das Data-Link-Protokoll 18 ermöglicht die verbindungsorientierte,
quittierte Übertragung einer einzelnen Datennachricht zwischen zwei
Benutzern der Data-Link-Layer 16. Daten werden über virtuelle Date-Link-Verbindungen
übertragen (siehe Abschnitt 1.2). Die beliebig
lange Datenübertragungsphase beginnt nach erfolgreicher Verbindungsaktivierung
(siehe Abschnitt 1.1). Nach Aussenden einer Datennachricht
zeigt der Eingang einer korrekten Quittungsnachricht an, daß
die zu quittierende Datennachricht korrekt empfangen wurde und daß
der Empfang der Nachricht dem Data-Link-Benutzer in der Empfangsstation
angezeigt wurde. Wenn nach einer gewissen vordefinierten
Zeit die Quittungsnachricht nicht eingetroffen ist, wiederholt das
Data-Link-Protokoll selbständig das Aussenden der Datennachricht.
Nach wiederholter, erfolgloser Übertragung der Datennachricht wird
die verwendete Verbindung deaktiviert. Das Ergebnis der Übertragung
und die Deaktivierung einer Verbindung werden dem Benutzer angezeigt.
Bezogen auf eine Verbindung kann nach dem Aussenden einer
Datennachricht erst dann die nächste Datennachricht mit Hilfe einer
Botschaft übertragen werden, wenn die Quittungsnachricht für die
vorhergehende Datennachricht eingetroffen ist.
Die Dienstelemente für die Initialisierung des Data-Link-Protokolls
18 sind D_INIT.req und D_INIT.con. Die Initialisierung wird mit
D_INIT.req angefordert und mit D_INIT.con bestätigt. Die Wirkung der
Initialisierung ist nur lokal: Die Variablen des Data-Link-Protokolls
18 werden mit ihren Voreinstellungswerten belegt (siehe
Tabelle 2).
Die Dienstelemente für die Aktivierung einer Data-Link-Verbindung
sind D_ACTIVATE.req, D_ACTIVATE.ind und D_ACTIVATE.con. Die Wirkung
von D_ACTIVATE.req ist, daß die den Verbindungsdienst erbringenden
Protokollinstanzen in einen kommunikationsbereiten Zustand gesetzt
werden, wobei die Protokoll-Variablen ihre Voreinstellungswerte einnehmen.
Wenn Verbindungsbenutzer A den Dienstauftrag D_ACTIVATE.req
gibt. wird nach erfolgreicher Aktivierung dies dem Verbindungsbenutzer
B in der entfernten Station mittels D_ACTIVATE.ind angezeigt.
Das Dienstelement D_ACTIVATE.con bestätigt den Dienstauftrag.
Die Dienstelemente für die Datenübertragung sind D_DATA_ACK.req,
D_DATA_ACK.ind und D_DATA_ACK.con. Mit D_DATA_ACK.req wird die
quittierte Übertragung von Daten (Parameter: DATA) der Länge
DATA_LENGTH angefordert. Nach korrekter Übertragung wird der Empfang
der Daten dem Kommunikationspartner mittels des Dienstelements
D_DATA_ACK.ind angezeigt. Das Ergebnis der Übertragung wird dem
Auftraggeber durch das Dienstelement D_DATA_ACK.con mitgeteilt.
Eine Verbindung wird nach wiederholter, erfolgloser Übertragung vom
Diensterbringer deaktiviert. Die Deaktivierung wird dem Dienstbenutzer
durch das Dienstelement D_DEACTIVATED.ind angezeigt.
Eine Nachricht wird mit einer Botschaft übertragen. Die Botschaft
besitzt ein Kopffeld (IDENTIFIER) und ein Datenfeld. Data-Link-Verbindungen
werden, wie in der Beschreibung der Fig. 2, 3a, 4a, 4b
und 4c erläutert, durch eine Data-Link-Protokollinstanz auf CAN-Verbindungen
abgebildet. Eine Data-Link-Nachricht wird daher mit einer
Botschaft übertragen, die den gleichen formalen Aufbau wie eine
CAN-Botschaft besitzt.
Das Data-Link-Protokoll unterscheidet vier Typen von Nachrichten:
AR (ACTIVATION REQUEST):
Aktivierungsnachricht zur Aktivierung einer Data-Link-Verbindung.
AC (ACTIVATION CONFIRM):
Bestätigungsnachricht zur Bestätigung der Aktivierung einer Daten-Link-Verbindung.
DT (DATA):
Datennachricht zur Übertragung von Daten über eine Data-Link-Verbindung.
AK (DATA-ACKNOWLEDGEMENT):
Quittungsnachricht zur Bestätigung des Empfangs einer Datennachricht über eine Data-Link-Verbindung.
Aktivierungsnachricht zur Aktivierung einer Data-Link-Verbindung.
AC (ACTIVATION CONFIRM):
Bestätigungsnachricht zur Bestätigung der Aktivierung einer Daten-Link-Verbindung.
DT (DATA):
Datennachricht zur Übertragung von Daten über eine Data-Link-Verbindung.
AK (DATA-ACKNOWLEDGEMENT):
Quittungsnachricht zur Bestätigung des Empfangs einer Datennachricht über eine Data-Link-Verbindung.
Fig. 5 zeigt die Datenfelder 57 der Botschaften, die die einzelnen
Nachrichten des Data-Link-Protokolls übertragen. Das Datenfeld 57
enthält bei den Nachrichten AR, AC, DT und AK ein Kontrollinformationsfeld
54 und bei der Datennachricht DT zusätzlich ein Feld 59
zur Aufnahme der daten, die mit dieser Nachricht DT übertragen werden.
Das Feld 59 kann maximal 7 Byte Daten aufnehmen. Der Nachrichtentyp
wird anhand einer mitgegebenen Kontrollinformation (DPCI),
die im Kontrollinformationsfeld der die Nachricht übertragenden Botschaft
enthalten ist, identifiziert. Die Kontrollinformation umfaßt
höchstens ein Byte und ist im Datenfeld 57 einer CAN-Botschaft
lokalisiert.
Fig. 6 zeigt die Einteilung der Kontrollinformationsfelder 58 für
die Botschaften zur Übertragung der verschiedenen Nachrichtentypen.
Für die Unterscheidung der vier Nachrichtentypen ist innerhalb des
Kontrollinformationsfeldes 58 ein Feld 63 zur Aufnahme eines Nachrichtencodes
vorgesehen. Der Nachrichtencode besteht im Regelfall
mindestens aus zwei Bits. Eine weitere Möglichkeit ist, für den
Nachrichtencode der Datennachrichten nur 1 Bit vorzusehen und für
die Nachrichtencodes der Nachrichtentypen AR, AC und AK zwei oder
mehr Bits vorzusehen. Die Kontrollinformationsfelder 58 der Botschaften
zur Übertragung der Nachrichtentypen DT und AK enthalten
darüber hinaus ein Feld 64 zur Aufnahme einer Sequenznummer SN. Die
Sequenznummer dient zur Unterscheidung aufeinanderfolgender DT-Nachrichten,
für die Zuordnung von Quittungsnachrichten AK zu Datennachrichten
DT und für die Erkennung von Nachrichtenduplikaten. Das Feld
64 zur Aufnahme der Sequenznummer SN umfaßt mindestens 1 Bit: Das
Kontrollinformationsfeld 58 der Botschaften zur Übertragung der
Quittungsnachrichten AK enthält darüber hinaus noch ein Empfängerstatusfeld
65. In dem Empfängerstatusfeld 65 wird eine Information
RS über den Status des Empfängers abgelegt. Diese Information kann
zur stationsübergreifenden Flußkontrolle verwendet werden. Das Empfängerstatusfeld
65 umfaßt mindestens ein Bit zur Kennzeichnung, ob
der Empfänger empfangsbereit ist oder nicht.
Das Protokoll verwendet folgende Variablen und Paramter (siehe
Tabelle 2):
- 1) Sendefolgevariable V(S)
Variable zur fortlaufenden Numerierung von Datennachrichten DT. V(S) kann die Werte 0 und 1 annehmen. Nach Empfang einer korrekten Quittungsnachricht AK wird der Wert von V(S) komplementiert. - 2) Empfangsfolgevariable V(R)
Variable zur Speicherung der Sequenznummer der nächsten zum Empfang erwarteten Datennachricht DT. V(R) kann die Werte 0 und 1 annehmen. Nach korrektem Empfang der erwarteten Datennachricht DT wird der Wert von V(R) komplementiert. - 3) Verbindungsstatusvariable V(C)
Variable zur Speicherung des Status einer Verbindung. Die Variable kann die Werte NOT_ACTIVATED, DEACTIAVTED, RECEIVE_READY und RECEIVE_NOT_READY annehmen. - 4) Sendewiederholungsvariable RC
Variable zur Speicherung der aktuellen Anzahl der Sendewiederholungen der Nachrichten vom Typ AR und DT. - 5) DPDU-Variable SN
Sequenznummervariable der Nachrichtentypen AR und DT. - 6) DPDU-Variable RS
Variable der Quittungsnachricht AK zur Kennzeichnung des Status der Empfangsprotokollinstanz. RS kann die Werte RR (Receive Ready) und RNR (Receive Not Ready) annehmen. - 7) Protokollparameter MNT
MNT ist die maximale Anzahl von automatischen Sendewiederholungen für eine Datennachricht DT bzw. für eine Aktivierungsnachricht AR. - 8) Protokollparameter TA
TA ist die Zeiteinheit, in der eine Quittungsnachricht AK bzw. eine Bestätigungsnachricht AC erwartet wird.
Fig. 7 zeigt den Zustandsgraphen der Data-Link-Sendeprotokollinstanz.
Die Zustände sind durch Kreise dargestellt. Die Übergänge
zwischen den Zuständen sind durch numerierte Übergangspfeile dargestellt.
Ein Übergang findet aufgrund bestimmter Ereignisse statt.
Bei den Übergängen werden in der Regel bestimmte Aktionen durchgeführt.
Welche Ereignisse zu den Übergängen führen und welche
Aktionen bei den Übergängen durchgeführt werden, kann der Automatentabelle
in 1.3.4.2 entnommen werden.
Wie in Fig. 7 dargestellt, hat die Data-Link-Sendeprotokollinstanz
folgende Zustände:
- 1) INACTIVE
Der Zustand INACTIVE wird nach der Initialisierung des Protokolls eingenommen. In diesem Zustand wartet die Protokollinstanz auf den Auftrag zur Aktivierung der Verbindung (Ereignis D_ACTIVATE_REQ) bzw. auf den Eingang einer Aktivierungsnachricht AR der Partnerprotokollinstanz. Wenn das Ereignis D_ACTIVATE_REQ auftritt, wird die Aktivierungsnachricht AR an die Data-Link-Empfangsprotokollinstanz gesendet (Aktion SEBD (AR)) und der Folgezustand START_UP eingenommen (Übergangspfeil 71).
Wenn im Zustand INACTIVE (vor Eingang des Verbindungsaktivierungsauftrags) die Aktivierungsnachricht AR zur Verbindungsaktivierung eintrifft (Ereignis RESEIVE_AR), wird eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und der Folgezustand IDLE eingenommen (Übergangspfeil 72), in dem die Data-Link-Sendeprotokollinstanz Aufträge zur quittierten Übertragung von Data entgegennimmt. - 2) START_UP
Im Zustand START_UP wartet die Data-Link-Sendeprotokollinstanz auf die Bestätigungsnachricht AC (Bestätigung der Verbindungsaktivierung) der angesprochenen Data-Link-Empfangsprotokollinstanz. Nach Eingang der Bestätigungsnachricht AC oder nach Eingang der Aktivierungsnachricht AR (Verbindungsaktivierungswunsch der Data-Link-Empfangsprotokollinstanz) wechselt die Data-Link-Sendeprotokollinstanz in den Zustand IDLE (Übergangspfeil 73), in dem sie Aufträge zur quittierten Übertragung von Daten entgegennimmt (die angesprochene Data-Link-Empfangsprotokollinstanz geht quasi gleichzeitig in den Zustand READY (Übergangspfeil 85 von Fig. 8). Wenn die Bestätigungsnachricht AC nach Ablauf der Wartefrist TA nicht eingetroffen ist (Ereignis TA_EXPIRED and (RC<MNT)), wird das Senden der Aktivierungsnachricht AR automatisch wiederholt (Übergangspfeil 74). Nach MNT unquittierten Übertragungen der Aktivierungsnachricht AR (Ereignis TA_EXPIRED and (RC=MNT)) geht die Data-Link-Sendeprotokollinstanz in den Zustand INACTIVE und zeigt die erfolglose Verbindungsaktivierung dem Benutzer an (Übergangspfeil 75). - 3) IDLE
Im Zustand IDLE wartet die Data-Link-Sendeprotokollinstanz auf einen Auftrag zur quittierten Übertragung von Daten. Nach Auftreten des entsprechenden Ereignisses D_DATA_ACK_REQ wird eine Datennachricht DT mit der Kontrollinformation und den zu übertragenden Daten gebildet, gesendet (Aktion SEND (DT)) und der Folgezustand WAIT_AK eingenommen (Übergangspfeil 76). Wenn im Zustand IDLE eine Aktivierungsnachricht AR zur Verbindungsaktivierung eintrifft (Ereignis RECEIVE_AR), werden den Protokollvariablen ihre Voreinstellungswerte zugewiesen und ein Bestätigungsnachricht AC (Aktion SEND (AC)) gesendet; die Verbindungaktivierung wird dem Benutzer angezeigt (Aktion D_ACTIVATE_IND( )) (Übergangspfeil 77). - 4) WAIT_AK
Im Zustand WAIT_AK wartet die Data-Link-Sendeprotokollinstanz auf das Eintreffen der Quittungsnachricht AK, die den korrekten Empfang der vorhergehenden Datennachricht DT bestätigen soll. Wenn die erwartete Quittung eintrifft (Ereignis RECEIVE_AK (SN<<V(S)), wird die erfolgreiche Übertragung der Daten dem Benutzer angezeigt und der Folgezustand IDLE eingenommen (Übergangspfeil 78). Wenn nach Ablauf der Wartefrist TA die Quittung AK nicht eingetroffen ist (Ereignis TA_EXPIRED and RC<MNT)), wird das nach MNT unquittierten Übertragungen der Datennachricht DT (Ereignis TA_EXPIRED and (RC=MNT)), wird die Verbindung deaktiviert; die Data-Link-Sendeprotokollinstanz geht wieder in den Zustand INACTIVE und zeigt die erfolglose Übertragung und die Deaktivierung der Verbindung dem Benutzer an (Übergangspfeil 83). Quittungen mit falscher Sequenznummer (Ereignis RECEIVE_AK (SN=V(S), RS=RR) werden im Zustand WAIT_AK ignoriert (Übergangspfeil 79). Wenn eine Quittungsnachricht AK eintrifft, die anzeigt, daß die Empfangsprotokollinstanz nicht empfangsbereit ist (Ereignis RECEIVE_AK (SN=V(S), RS=RNR)), wird die Sendewiederholung der vorhergehenden Datennachricht DT verzögert (Übergangspfeil 80). Wenn im Zustand WAIT_AK eine Nachricht AR zur Verbindungsaktivierung eintrifft Ereignis (RECEIVE_AK), werden den Protokollvariablen ihre Voreinstellungswerte zugewiesen, eine Bestätigungsnachricht AK gesendet (Aktion SEND (AC)) und der Folgezustand IDLE eingenommen (Übergangspfeil 81). Die laufende Datenübertragung wird dabei abgebrochen; die erfolglose Datenübertragung und die Verbindungsaktivierung werden dem Benutzer angezeigt.
Tabelle 3 zeigt die Automatentabelle der Data-Link-Sendeprotokollinstanz.
Die Spalte ÜGPN enthält die Übergangspfeilnummern für die
Fig. 7.
- 1) INACTIVE
- 2) START_UP
- 3) IDLE
- 4) WAIT_AK
- 1) D_AKTIVATE_REQ
Eingang eines Auftrags zur Verbindungsaktivierung. - 2) RECEIVE_AR
Empfang einer Aufforderung zur Verbindungsaktivierung. - 3) RECEIVE_AC
Empfang einer Bestätigung der Verbindungsaktivierung. - 4) TA_EXPIRED and (RC<MNT)
Wartefrist für das Eintreffen einer Bestätigungsnachricht AC oder Quittungsnachricht AK ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist nicht überschritten. - 5) TA_EXPIRED and (RC=MNT)
Wartefrist für das Eintreffen einer Bestätigungsnachricht AC oder Quittungsnachricht AK ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist erreicht. - 6) D_DATA_ACK_REQ (DATA_LENGTH, DATA)
Eingang eines Auftrags zur Übertragung der Daten DATA der Länge DATA_LENGTH. - 7) RECEIVE_AK (SN<<V(S))
Empfang einer Quittung, die den korrekten Empfang der vorhergehenden Datennachricht DT bestätigt. - 8) RECEIVE_AK (SN=V(S), RS=RR)
Empfang einer Quittung, deren Sequenznummer SN identisch ist mit der Sequenznummer der vorhergehenden Datennachricht DT. Dieses Ereignis kann auftreten, wenn durch vorzeitigen Fristablauf eine Datennachricht DT erneut gesendet wird und der Empfänger diese Nachricht als Duplikat erkennt. Die Statusinformation RS zeigt an, daß der Empfänger empfangsbereit ist. - 9) RECEIVE_AK (SN=/V(S), RS=RNR)
Empfang einer Quittung, deren Sequenznummer SN identisch ist mit der Sequenznummer der vorhergehenden Datennachricht DT. Dieses Ereignis kann auftreten, wenn die Data-Link-Empfangskontrollinstanz eine Datennachricht DT nicht entgegennehmen kann. Die Statusinformation RS=RNR zeigt an, daß der Empfänger nicht empfangsbereit ist.
- 1) SEND (AR)
Senden einer Aktivierungsnachricht AR zur Verbindungsaktivierung. - 2) SEND (DT)
Senden einer Datennachricht DT. - 3) SEND (AC)
Senden einer Bestätigungsnachricht AC zur Bestätigung der Verbindungsaktivierung. - 4) RESEND_AR
Wiederholung des Sendens einer Aktivierungsnachricht AR zur Verbindungsaktivierung. - 5) RESEND_LAST_DT
Wiederholung des Sendens der letzten Datennachricht DT. - 6) START_TA
Rücksetzen und Starten des Timers zur Überwachung der Wartefrist TA. - 7) CANCEL_TA
Rücksetzen des Timers zur Überwachung der Wartefrist TA. - 8) RC:=1
Setzen der Sendewiederholungsvariablen RC auf den Wert 1. - 9) RC:=RC+1
Inkrementieren der Sendewiederholungsvariablen RC um den Wert 1. - 10) V(S):=1-V(S)
Komplementieren der Sendenfolgevariablen V(S). - 11) V(C):=RECEIVE_READY
Setzen der Verbindungsstatusvariablen V(C) auf den Wert RECEIVE_READY. - 12) V(C):=DEACTIVATED
Setzen der Verbindungsstatusvariablen V(C) auf den Wert DEACTIVATED. - 13) V(C):=NOT_ACTIVATED
Setzen der Verbindungsstatusvariablen V(C) auf den Wert NOT_ACTIVATED. - 14) RESET_VARIABLES( )
Besetzen der Protokollvariablen mit den Voreinstellungswerten (siehe Tabelle 2). - 15) DT:=DT (SN=V(S))
Bildung einer Datennachricht DT. Der Sequenznummervariablen SN wird dabei der Wert der Sendefolgevariablen V(S) zugewiesen. - 16) D_ACTIVATE_CON (CONNECTION_STATUS=V(C))
Bestätigung des Verbindungsaktivierungsdienstes. - 17) D_ACTIVATE_IND( )
Anzeige einer Verbindungsaktivierung. - 18) D_DATA_ACK_CON (TRANSFERSTATUS:=SUCCESS)
Positive Bestätigung des Datenübertragungsdienstes. - 19) D_DATA_ACK_CON (TRANSFERSTATUS:=NO_SUCCESS)
Negative Bestätigung des Datenübertragungsdienstes. - 20) D_DEACTIVATED_IND( )
Anzeige einer automatischen Verbindungsdeaktivierung.
Fig. 8 zeigt den Zustandsgraphen der Data Link-Empfangsprotokollinstanz
Für die Fig. 8 gilt der gleiche Formalaufbau wie in Fig. 7.
Die Data-Link-Empfangsprotokollinstanz hat folgende Zustände:
- 1) INACTIVE
Im Zustand INACTIVE befindet sich die Data-Link-Empfangsprotokollinstanz nach der Initialisierung. In diesem Zustand wartet die Data-Link-Empfangsprotokollinstanz auf den Auftrag zur Aktivierung der Verbindung (Ereignis D_ACTIVATE_REQ) bzw. auf den Eingang einer Aktivierungsnachricht AR der Partnerprotokollinstanz. Wenn das Ereignis D_ACTIVATE_REQ auftritt, wird die Aktivierungsnachricht AR an die Data-Link-Sendeprotokollinstanz gesendet (Aktion SEND (AR)) und der Folgezustand START_UP eingenommen (Übergangspfeil 71).
Wenn im Zustand INACTIVE (vor Eingang des Verbindungsaktivierungsauftrags) die Aktivierungsnachricht AR zur Verbindungsaktivierung eintrifft (Ereignis RECEIVE_AR), wird eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und der Folgezustand READY eingenommen, in dem die Data-Link-Empfangsprotokollinstanz bereit ist, Daten zu empfangen (Übergangspfeil 84). - 2) START_UP
Im Zustand START_UP wartet die Data-Link-Empfangsprotokollinstanz auf die Bestätigungsnachricht AC (Bestätigung der Verbindungsaktivierung) der angesprochenen Data-Link-Sendeprotokollinstanz. Nach Eingang der Bestätigungsnachricht AC oder nach Eingang der Aktivierungsnachricht AR (Verbindungsaktivierungswunsch der Data-Link-Sendeprotokollinstanz) wechselt die Data-Link-Empfangsprotokollinstanz in den Zustand READY, in dem sie bereit ist, Daten zu empfangen (Übergangspfeil 85). Die entsprechende Data-Link-Sendeprotokollinstanz geht quasi gleichzeitig in den Zustand IDLE (siehe Übergangspfeil 73 von Fig. 7). Wenn die Bestätigungsnachricht AC nach Ablauf der Wartefrist TA nicht eingetroffen ist (Ereignis TA_EXPIRED and (RC<MNT)), wird das Senden der Aktivierungsnachricht AR automatisch wiederholt (Übergangspfeil 74). Nach MNT unquittierten Übertragungen der Aktivierungsnachricht AR (Ereignis TA EXPIRED and (RC=MNT)) geht die Data-Link-Empfangsprotokollinstanz wieder in den Zustand INACTIVE und zeigt die erfolglose Verbindungsaktivierung dem Benutzer an (Übergangspfeil 75). - 3) READY
Im Zustand READY wartet die Data-Link-Empfangsprotokollinstanz auf den Eingang einer Datennachricht DT. Nach Empfang einer entsprechenden Nachricht mit der erwarteten Sequenznummer (Ereignis RECEIVE_DT (SN=V(R)) wird der Empfang dem Benutzer angezeigt und eine Quittungsnachricht AK gesendet (Aktion SEND (AK)) (Übergangspfeil 86). Wenn die Data-Link-Empfangsprotokollinstanz bei Eingang einer Datennachricht DT nicht empfangsbereit ist, so wird die Nachricht AK verworfen und dem Sender dies durch die Übertragung einer Quittungsnachricht AK mit unveränderter Sequenznummer (=Sequenznummer der erwarteten Datennachricht DT) und dem Empfangsstatus ("Empfänger nicht bereit" mitgeteilt (Übergangspfeil 87).
Wenn eine Datennachricht DT mit falscher Sequenznummer eintrifft (Ereignis RECEIVE_DT (SN<<V(R)), wird eine Quittungsnachricht AK mit der erwarteten Sequenznummer und dem aktuellen Empfangsstatus gesendet (Übergangspfeil 88).
Wenn im Zustand READY eine Aktivierungsnachricht AR zur Verbindungsaktivierung eintrifft (Ereignis RECEIVE_AR), werden den Protokollvariablen ihre Voreinstellungswerte zugewiesen und eine Bestätigungsnachricht AC gesendet (Aktion (AC)); die Verbindungsaktivierung wird dem Benutzer angezeigt (Aktion D_ACTIVATE_IND( ) (Übergangspfeil 89).
Tabelle 4 zeigt die Automatentabelle der Data-Link-Empfangsprotokollinstanz.
Die Spalte ÜGPN enthält die Übergangspfeilnummern für
die Fig. 8.
- 1) INACTIVE
- 2) START_UP
- 3) READY
- 1) D_ACTIVATE_REQ
Eingang eines Auftrags zur Verbindungsaktivierung. - 2) RECEIVE_AR
Empfang einer Aufforderung zur Verbindungsaktivierung. - 3) RECEIVE_AC
Empfang einer Bestätigung der Verbindungsaktivierung. - 4) TA_EXPIRED and (RC<MNT)
Wartefrist für das Eintreffen einer Bestätigungsnachricht AC ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist nicht überschritten. - 5) TA_EXPIRED and (RC=MNT)
Wartefrist für das Eintreffen einer Bestätigungsnachricht AC ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist erreicht. - 6) RECEIVE_DT (SN=V(R)) and RECEIVE_STATUS ( )=RECEIVE_READY
Eingang einer erwarteten Datennachricht DT. Die Data-Link-Empfangsprotokollinstanz ist empfangsbereit. - 7) RECEIVE_DT (SN=V(R)) and RECEIVE_STATUS ( )=RECEIVE_NOT_READY
Eingang einer erwarteten Datennachricht DT. Die Data-Link-Empfangsprotokollinstanz ist nicht empfangsbereit. - 8) RECEIVE_DT (SN<<V(R))
Eingang einer nicht erwarteten Datennachricht DT.
- 1) SEND (AR)
Senden einer Aktivierungsnachricht AR zur Verbindungsaktivierung. - 2) SEND (AC)
Senden einer Bestätigungsnachricht AC zur Bestätigung der Verbindungsaktivierung. - 3) RESEND_AR
Wiederholung des Sendens einer Aktivierungsnachricht AR zur Verbindungsaktivierung. - 4) START_TA
Rücksetzen und Starten des Timers zur Überwachung der Wartefrist TA. - 5) CANCEL_TA
Rücksetzen des Timers zur Überwachung der Wartefrist TA. - 6) RC:=1
Setzen der Sendewiederholungsvariablen RC auf den Wert 1. - 7) RC:=RC+1
Inkrementieren der Sendewiederholungsvariablen RC um den Wert 1. - 8) V(R):=1-V(R)
Komplementieren der Empfangsfolgevariablen V(R). - 9) V(C):=RECEIVE_READY
Setzen der Verbindungsstatusvariablen V(C) auf den Wert RECEIVE_READY. - 10) V(C):=NOT_ACTIVATED
Setzen der Verbindungsstatusvariablen V(C) auf den Wert NOT_ACTIVATED. - 11) V(C):=RECEIVE_STATUS ( )
Die Funktion RECEIVE_STATUS ( ) stellt die Empfangsbereitschaft der Data-Link-Empfangsprotokollinstanz fest. Der Rückgabewert der Funktion (RECEIVE_READY bzw. RECEIVE_NOT_READY) wird der Verbindungsstatusvariablen V(C) zugewiesen. - 12) RESET_VARIABLES( )
Besetzen der Protokollvariablen mit den Voreinstellungswerten (siehe Tab. 2). - 13) AK:=AK(SN=V(R), RS=V(C))
Bildung einer Quittungsnachricht AK. Der Sequenznummervariablen SN wird dabei der Wert der Empfangsfolgevariablen V(R) zugewiesen. Der Empfangsstatusvariablen RS wird der Wert der Verbindungsstatusvariablen V(C) zugewiesen. - 14) D_ACTIVATE_CON (CONNECTION_STATUS=V(C))
Bestätigung des Verbindungsaktivierungsdienstes. - 15) D_ACTIVATE_IND( )
Anzeige einer Verbindungsaktivierung. - 16) D_DATA_ACK_IND (DATA_LENGTH, DATA)
Anzeige des korrekten Empfangs einer Datennachricht. Als Parameter werden die Datenlänge DATA_LENGTH und die Daten DATA übergeben.
Die Aufgabe des Transportprotokolls 19 ist die sichere Übertragung
von Daten beliebiger Länge. Daten, deren Länge zuzüglich der Transport-Kontrollinformation
die maximale Datenlänge einer einzelnen
CAN-Botschaft überschreitet, werden in der Transportlayer 15 des
Senders in Segmente zerlegt, separat übertragen und in der Transportlayer
15 des Empfängers wiedervereinigt.
Das Transport-Protokoll 19 des Ausführungsbeispiels arbeitet nach
der Methode Send-and-Wait. Daten werden über virtuelle Transport-Verbindungen
übertragen (siehe Abschnitt 1.2). Die beliebig lange
Datenübertragungsphase beginnt nach erfolgreicher Verbindungsaktivierung
(siehe Abschnitt 1.1). Nach dem Aussenden einer Datennachricht
wartet die Transport-Sendeprotokollinstanz auf das Eintreffen
der entsprechenden Quittungsnachricht. Die nächste Nachricht (Datensegment
oder neue Daten) darf erst nach Eingang der korrekten Quittungsnachricht
für die vorhergehende Nachricht gesendet werden. Wenn
die Transport-Sendeprotokollinstanz die Übertragung einer Nachricht
initiiert, wird ein Timer gestartet, der die maximale Wartezeit TA
bis zum Eintreffen der Quittungsnachricht mißt. Die Transport-Empfangsprotokollinstanz
beantwortet jede korrekt empfangene Datennachricht
mit dem Senden einer Quittungsnachricht, die zusätzliche
Informationen über den Status der Transport-Empfangsprotokollinstanz
enthält, die von der transport-Sendeprotokollinstanz zur Flußkontrolle
benötigt wird. Wenn die Wartezeit TA vor Eintreffen der
Quittung abläuft, wiederholt die Transport-Sendeprotokollinstanz die
Übertragung der letzten Nachricht. Nach wiederholter erfolgloser
Übertragung einer Nachricht wird die Transport-Verbindung deaktiviert.
Das Ergebnis der Übertragung und die Deaktivierung einer
Verbindung werden dem Benutzer angezeigt.
Die Dienstelemente für die Initialisierung des Transport-Protokolls
sind T_INIT.req und T_INIT.con. Die Initialisierung wird mit
T_INIT.req angefordert und mit T_INIT.con bestätigt. Die Wirkung der
Initialisierung ist nur lokal: Die Variablen des Transport-Protokolls
werden mit ihren Voreinstellungswerten belegt (siehe Tabelle
6).
Die Dienstelemente für die Aktivierung einer Transport-Verbindung
sind T_ACTIVATE.req, T_ACTIVATE.ind und T_ACTIVATE.con. Die Wirkung
von T_ACTIVATE.req ist, daß die den Verbindungsdienst erbringenden
Transport-Protokollinstanzen in einen kommunikationsbereiten Zustand
gesetzt werden, wobei die Protokollvariablen ihre Voreinstellungswerte
einnehmen. Wenn Verbindungsbenutzer A den Dienstauftrag
T_ACTIVATE.req, wird nach erfolgreicher Aktivierung dies dem
Verbindungsbenutzer B in der entfernten Station mittels
T_ACTIVATE.ind angezeigt. Das Dienstelement T_ACTIVATE.con bestätigt
den Dienstauftrag.
Die Dienstelemente für die Datenübertragung sind T_DATA.req,
T_DATA.ind und T_DATA.con. Mit T_DATA.req wird die quittiierte Übertragung
von Daten (Parameter: DATA) der Länge DATA_LENGTH angefordert.
Nach korrekter Übertragung wird der Empfang der Daten dem
Kommunikationspartner mittels des Dienstelements T_DATA.ind angezeigt.
Das Ergebnis der Übertragung wird dem Auftraggeber durch das
Dienstelement T_DATA.con mitgeteilt.
Eine Verbindung wird nach wiederholter, erfolgloser Übertragung vom
Diensterbringer deaktiviert. Die Deaktivierung wird dem Dienst
benutzer durch das Dienstelement T_DEACTIVATED.ind angezeigt.
Für die Transport-Nachrichten, die zwischen Transport-Protokoll
instanzen ausgetauscht werden, gilt das gleiche wie für die Data-
Link-Nachrichten. Auch sie werden mit Hilfe von CAN-Botschaften
übertragen. Die einzelnen Teilfelder des Datenfeldes der CAN-Botschaften
sind jedoch für Transport-Nachrichten zum Teil unterschiedlich
belegt. Dies wird in der nachfolgenden Beschreibung der Fig. 9
und 10 erläutert. Das Transport-Protokoll unterscheidet ebenfalls
vier Nachrichtentypen AR, AC, DT und AK:
AR (ACTIVATION REQUEST):
Aktivierungsnachricht zur Aktivierung einer Transport-Verbindung
AG (ACTIVATION CONFIRM):
Bestätigungsnachricht zur Bestätigung der Aktivierung einer Transport-Verbindung
DT (DATA)
Datennachricht zur Übertragung von Daten über eine Transport-Verbindung
AK (DATA-ACKNOWLEDGEMENT):
Quittierungsnachricht zur Bestätigung des Empfangs eienr Transport-Nachricht über eine Transport-Verbindung.
Aktivierungsnachricht zur Aktivierung einer Transport-Verbindung
AG (ACTIVATION CONFIRM):
Bestätigungsnachricht zur Bestätigung der Aktivierung einer Transport-Verbindung
DT (DATA)
Datennachricht zur Übertragung von Daten über eine Transport-Verbindung
AK (DATA-ACKNOWLEDGEMENT):
Quittierungsnachricht zur Bestätigung des Empfangs eienr Transport-Nachricht über eine Transport-Verbindung.
Fig. 9 zeigt die Datenfelder 94 der Botschaften, die die einzelnen
Nachrichten des Transport-Protokolles übertragen. Das Datenfeld 94
enthält bei den Nachrichten AR, AC, DT und AK ein Kontrollinfor
mationsfeld 95 und bei der Datennachricht DT zusätzlich die Felder
96, 97 und 98 zur Aufnahme der einzelnen Datenbytes, die mit dieser
Nachricht DT übertragen werden. Es können hierbei maximal 7 Datenbytes
sich an das Kontrollinformationsfeld 95 anschließen. Der Nach
richtentyp wird wieder anhand einer mitgegebenen Kontrollinformation
(TPCI), die im Kontrollinformationsfeld der die Nachricht übertragenden
Botschaft enthalten ist, identifiziert. Die Kontrollinformation
umfaßt hier höchstens ein Byte und ist im Datenfeld 95 einer
CAN-Botschaft lokalisiert.
Fig. 10 zeigt die Einteilung der Kontrollinformationsfelder 95 für
die Botschaften zur Übertragung der verschiedenen Nachrichtentypen.
Für die Unterscheidung der 4 Nachrichtentypen ist innerhalb des Kon
trollinformationsfeldes 95 ein Feld 101 zur Aufnahme eines Nach
richtencodes vorgesehen. Die Kontrollinformationsfelder 95 der
Botschaften zur Übertragung der Nachrichtentypen DT und AK enthalten
darüber hinaus ein Feld 102 zur Aufnahme der Sequenznummer SN. Die
Sequenznummer dient hier ebenfalls zur Unterscheidung aufeinanderfolgender
DT Nachrichten für die Zuordnung von Quittungsnachrichten
zu Datennachrichten DT und für die Erkennung von Nachrichtenduplikaten.
Das Feld 102 zur Aufnahme der Sequenznummer SN umfaßt hier
ebenfalls mindestens ein Bit. Zusätzlich umfaßt das Kontrollinfor
mationsfeld 95 einer Botschaft, die eine Datennachricht überträgt,
ein Feld 103 zur Aufnahme eines Nachrichtenendecodes EOM. Das Feld
103 umfaßt mindestens ein Bit. Die Information, die in diesem Feld
übertragen wird, gibt an, ob weitere Datensegmente folgen (EOM =
0) oder nicht (EOM = 1). Weiterhin umfaßt das Kontrollinformations
feld 95 einer Botschaft, die eine Datennachricht DT überträgt, ein
Feld 104 zur Aufnahme einer Information NB, die angibt, wieviele
Daten mit dieser Botschaft übertragen werden.
Das Feld 104 umfaßt mindestens 3 Bit. In dem Feld 105 einer Botschaft,
die eine Quittungsnachricht AK überträgt, wird ebenfalls
eine Information über den Status des Empfängers abgelegt. Das
Empfängerstatusfeld 105 umfaßt mindestens 1 Bit zur Kennzeichnung,
ob der Empfänger empfangsbereit ist oder nicht, wie in Fig. 6.
Fig. 11 zeigt die Abwicklung einer Datenübertragung zwischen zwei
Stationen, mit Hilfe des Transport-Protokolls. Dabei werden 15
Datenbytes übertragen. Die 15 Datenbytes sind in dem Feld 130 dargestellt.
Speziell dargestellt sind die Datenbytefelder 131, 132, 133
und 134 für die Datenbytes 1, 2, 3 und 15. Zur Verdeutlichung der
Abwicklung der Datenübertragung sind einige unterschiedliche Funk
tionsschichten innerhalb der Station dargestellt. Die Schicht 140
ist die Anwendungsschicht innerhalb der ersten Station, in der die
Anwendungsprogramme abgearbeitet werden. Die Schicht 143 ist
die Transportschicht der ersten Station, in der das Transportprotokoll
19 Aufträge von der Anwendungsschicht entgegennimmt und
abwickelt. Die Schicht 144 ist die Transportschicht der zweiten
Station. Zwischen den beiden Transportschichten 141 und 144 ist die
virtuelle Transport-Verbindung mit Hilfe der gestrichelten Linien
146 und 147 dargestellt. Das Transport-Protokoll 19 in der Schicht
141 macht zur Abwicklung einer Transportnachrichtenübertragung
seitens der zugehörigen Station von dem in der Schicht 142 befindlichen
CAN-Protokoll 17 Gebrauch. Die Schicht 145 enthält das
CAN-Protokoll 17 der zweiten Station. Das CAN-Protokoll 17 macht
seinerseits zur Datenübertragung von der CAN-Busverbindung 148
zwischen den Stationen Gebrauch. Die Datenübertragung der 15 Datenbytes
in dem Feld 130 geschieht mit Hilfe des Transport-Protokolls
19 in 3 Schritten. Im ersten Schritt werden die Datenbytes 1-7
übertragen. Dazu bildet die Transport-Protokollinstanz die Daten
nachricht DT1. Diese wird dann von der CAN-Protokollinstanz mit
Hilfe einer CAN-Botschaft übertragen. Der Aufbau des Datenfeldes 139
der Botschaft zur Übertragung der Datennachricht DT1 ist in Fig. 11
dargestellt. In dem Kontrollinformationsfeld 135 der Botschaft ist
der Nachrichtencode DT, die Sequenz Nummer 0, der Nachrichten
decode 0 und 7 für die Anzahl der Datenbytes eingetragen. Die
weiteren Datenbytefelder der Botschaft sind mit den ersten sieben
Bytes der zu übertragenden 15 Datenbytes belegt. Beispielhaft sind
die Datenbytefelder 136, 137 und 138 dargestellt.
Nach dem Empfang der Datennachricht DT1 sendet die empfangende
Station die Quittungsnachricht AK1 an die sendende Station zurück.
Das Datenfeld 139 der Botschaft, die die Quittungsnachricht AK1
überträgt, besteht nur aus dem Kontrollinformationsfeld 135. In
diesem Feld sind der Nachrichtencode AK, die Sequenznummer 1 und die
Empfängerstatusinformation RR (entspricht korrekter Empfang einer
Datennachricht) eingetragen.
Im zweiten Schritt werden die Datenbytes 8-14 übertragen. Dies
geschieht mit Hilfe der Datennachricht DT2. Das Datenfeld 139 der
Botschaft, die die Datennachricht DT2 überträgt, ist wie im ersten
Schritt eingeteilgt. Die Datenbytefelder 136, 137 und 138 enthalten
die Datenbytes 8, 9 und 14. In dem Kontrollinformationsfeld 135 sind
der Nachrichtencode DT, die Sequenznummer 1, der Nachrichten
endecode 0 und 7 für die Anzahl der Datenbytes eingetragen. Die
empfangende Station bestätigt durch den Empfang der Datennachricht
DT2 mit Hilfe der Quittungsnachricht AK2. Das Kontrollinformations
feld 135 der Botschaft, die die Quittungsnachricht AK2 überträgt,
ist genau wie im Schritt 1 belegt, mit deM Unterschied, daß
für die Sequenznummer eine 0 in das Kontrollinformationsfeld 135
eingetragen ist.
Im ersten Schritt wird das letzte Datenbyte 15 übertragen. Dies
geschieht mit Hilfe der Datennachricht DT3. Das Datenfeld 139 der
Botschaft, die die Datennachricht DT3 überträgt, ist unterschiedlich
zu den Datenfeldern in den Schritten 1 und 2 eingeteilt. Das Datenbyte
feld 136 enthält das 15. Datenbyte und die weiteren Datenbyte
felder, die beispielhaft als 137 und 138 dargestellt sind, enthalten
keine relevante Information. In dem Kontrollinformationsfeld 135
sind der Nachrichtencode DT, die Sequenznummer 0, der Nachrichten
code 1 und 1 für die Anzahl der Datenbytes eingetragen. Die
empfangende Station bestätigt den Empfang der Datennachricht DT3
mit Hilfe der Quittungsnachricht AK3. Das Kontrollinformationsfeld
135 der Botschaft, die die Quittungsnachricht AK3 überträgt, ist
genau wie im Schritt 1 belegt. Als Resultat sind alle 15 Datenbytes
zur zweiten Station übertragen worden und die Anwendungsschicht 143
der zweiten Station kann diese weiterverarbeiten.
Das Protokoll verwendet folgende Variablen und Parameter (siehe Tab. 6):
- 1) Sendefolgevariable V(S)
Variable zur fortlaufenden Nummerierung von Datennachrichten DT. V(S) kann die Werte 0 und 1 annehmen. Nach Empfang einer korrekten Quittungsnachricht AK wird der Wert von V(S) komplementiert. - 2) Empfangsfolgevariable V(R)
Variable zur Speicherung der Sequenznummer der nächsten zum Empfang erwarteten Datennachricht DT. V(R) kann die Werte 0 und 1 annehmen. Nach korrektem Empfang der erwarteten Datennachricht DT wird der Wert von V(R) komplementiert. - 3) Verbindunsstatusvariable V(C)
Variable zur Speicherung des Status einer Verbindung. Die Variable kann die Werte NOT_ACTIVATED, DEACTIVATED, RECEIVE_READY und RECEIVE_NOT_READY annehmen. - 4) Sendewiederholungsvariable RC
Variable zur Speicherung der aktuellen Anzahl der Sendewieder holungen zum Nachrichtentypen AR und DT. - 5) Segmentanzahl NSEG
Anzahl der Datensegmente, die für die Übertragung von Daten gebildet werden müssen. - 6. Datenlänge DL
Variable der Transport-Empfangsprotokollinstanz zur Berechnung der Datenlänge der empfangenen Nachricht. - 7) TPDU-Variabele EOM
Variable zur Kennzeichnung, ob weitere Datensegmente folgen (EOM = 0) oder nicht (EOM = 1). - 8) TPDU-Variable NB
Anzahl der relevanten Bytes im Datenfeld. Für die Datensegmente 1 bis NSEG-1 hat NB den Wert 7. - 9) TPDU-Variable SN
Sequenznummervariable der Nachrichtentypen AR und DT. - 10) TPDU-Variable RS Variable der Quittungsnachricht AK zur Kennzeichnung des Status der Transport-Empfangsprotokollinstanz. Es kann die Werte RR (Receive Ready) und RNR (Receive Not Ready) annehmen.
- 11) Protokollparameter MNT
MNT ist die maximale Anzahl von automatischen Sendewiederholungen für eine Datennachricht DT bzw. für eine Verbindungsaktivierungs nachricht AR. - 12) Protokollparameter NSEGT_MAX
Maximale Anzahl von Datensegmenten. - 13) Protokollparameter TA
TA ist die Zeiteinheit, in der eine Quittungsnachricht AK bzw. eine Bestätigungsnachricht AC erwartet wird.
Fig. 12 zeigt den Zustandsgraphen der Transport-Empfangsprotokoll
instanz. Auch für die Fig. 12 gilt der gleiche formale Aufbau wie in
den Fig. 7 und 8. Die Transport-Empfangsprotokollinstanz hat
folgende Zustände:
- 1) INACTIVE
Der Zustand INACTIVE wird nach der Initialisierung des Protokolls eingenommen. In diesem Zustand wartet die Transport-Protokoll instanz auf den Auftrag zur Aktivierung der Verbindung (Ereignis T_ACTIVATE_REQ) bzw. auf den Eingang einer Aktivierungsnachricht AR der Partnerprotokollinstanz. Wenn das Ereignis T_ACTIVATE_REQ auftritt, wird die Aktivierungsnachricht AR an die Transport- Empfangsprotokollinstanz gesendet (Aktion SEND (AR)) und der Folgezustand START_UP eingenommen (Übergangspfeil 111).
Wenn im Zustand INACTIVE (vor Eingang des Verbindungsaktivie rungsauftrags) die Aktivierungsnachricht AR zur Verbindungsaktivierung eintrifft (Ereignis RECEIVE_), wird eine Bestätigungs nachricht AC gesendet (Aktion SEND (AC)) und der Folgezustand IDLE eingenommen, in dem die Transport-Sendeprotokollinstanz Aufträge zur quittierten Übertragung von Daten entgegennimmt (Über gangspfeil 112). - 2) START UP
Im Zustand START_UP wartet der Transport-Sendeprotokollinstanz auf die Bestätigungsnachricht AC (Bestätigung der Verbindungs aktivierung) der angesprochenen Transport-Empfangsprotokoll instanz.
Nach Eingang der Bestätigungsnachricht AC oder nach Eingang der Aktivierungsnachricht AR (Verbindungsaktivierungswunsch der Transport-Empfangsprotokollinstanz) wechselt die Transport-Sende protokollinstanz in den Zustand IDLE, in dem sie Aufträge zur Übertragung von Daten entgegennimmt (Übergangspfeil 113). Die angesprochene Transport-Empfangsprotokollinstanz geht quasi gleichzeitig in den Zustand READY (siehe Übergangspfeil 123 von Fig. 12). Wenn die Bestätigungsnachricht AC nach Ablauf der Wartefrist TA nicht eingetroffen ist (Ereignis TA_EXPIRED and (RC < MNT)), wird das Senden der Aktivierungsnachricht AR automatisch wiederholt (Übergangspfeil 74). Nach MNT unquittierten Übertragungen der Aktivierungsnachricht AR (Ereignis TA_EXPIRED and (RC = MNT)) geht die Transport-Sendeprotokollinstanz wieder in den Zustand INACTIVE und zeigt die erfolglose Verbindungsaktivierung dem Benutzer an (Übergangspfeil 114). - 3) IDLE
Im Zustand IDLE wartet die Transport-Sendeprotokollinstanz auf einen Auftrag zur Übertragung von Daten. Nach Auftreten des ent sprechenden Ereignisses T_DATA_REQ wird die Anzahl NSEG der Datensegmente berechnet und die Datennachricht DT mit der Kontroll information und dem ersten Datensegment gebildet, gesendet (Aktion SEND (DTT)) und der Folgezustand WAIT_AK eingenommen (Übergangspfeil 115). Wenn im Zustand IDLE eine Aktivierungsnach richt AR zur Verbindungsaktivierung eintrifft (Ereignis RECEIVE AR), werden den Protokollvariablen ihre Voreinstellungswerte zugewiesen, eine Bestätigungsnachricht AC (Aktion SEND (AC)) gesendet und die Aktivierung dem Benutzer mitgeteilt (Aktion T_ACTIVATE_IND()) (Übergangspfeil 116. - 4) WAIT_AK
Im Zustand WAIT_AK wartet die Transport-Sendeprotokollinstanz auf das Eintreffen der Quittungsnachricht AK, die den korrekten Empfang der vorhergehenden Datennachricht DT bestätigen soll. Wenn die erwartete Quittung eintrifft (Ereignis RECEIVE_AK (SNV(S)), wird NSEG dekrementiert und im Fall von NSEG ≧ 1 die Nachricht mit dem nächsten Datensegment gebildet und gesendet (Übergangspfeil 117). Wenn NSEG = 0 ist, wird nach Eingang der Quittung die korrekte Übertragung dem Benutzer mitgeteilt und der Folgezustand IDLE eingenommen (Übergangspfeil 119). Wenn nach Ablauf der Wartefrist TA die Quittungsnachricht AK nicht eingetroffen ist (Ereignis Ta_EXPIRED and (RC < MNT)), wird das Senden der Datennachricht DT automatisch wiederholt (Übergangspfeil 82). Nach MNT unquittierten Übertragungen der Datennachricht DT (Ereignis TA_EXPIRED and (RC = MNT)) wird die Verbindung deaktiviert; die Transport-Sendeprotokollinstanz geht wieder in den Zustand INACTIVE und zeigt die erfolglose Übertragung und die Deaktivierung der Verbindung dem Benutzer an (Übergangspfeil 83). Quittungen mit falscher Sequenznummer (Ereignis RECEIVE_AK (SN = V(S)) werden im Zustand WAIT_AK ignoriert (Übergangspfeil 79), 80). Wenn eine Quittungsnachricht AK eintrifft, die anzeigt, daß die Empfangsinstanz nicht empfangsbereit ist (Ereignis RECEIVE_AK (SN = VC/S), RS=RNR), wird die Sendewiederholung der vorhergehenden Datennachricht DT verzögert (Übergangspfeil 80). Wenn im Zustand WAIT_AK eine Datennachricht AR zur Verbindungsaktivierung ein trifft (RECEIVE_AR), werden den Protokollvariablen ihre Vorein stellungswerte zugewiesen, eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und der Folgezustand IDLE eingenommen (Übergangs pfeil 120). Die laufende Datenübertragung wird dabei abgebrochen; die erfolglose Datenübertragung und Verbindungsaktivierung werden dem Benutzer angezeigt.
Tabelle 7 zeigt die Automatentabelle der Transport-Sendeprotokoll
instanz. Die Spalte ÜGPN enthält die Übergangspfeilnummern der Fig. 12.
- 1) INACTIVE
- 2) START_UP
- 3) IDLE
- 4) WAIT_AK
- 1) T_ACTIVATE_REQ
Eingang eines Auftrags zur Verbindungsaktivierung. - 2) RECEIVE_AR
Empfang einer Aufforderung zur Verbindungsaktivierung. - 3) RECEIVE_AC
Empfang einer Bestätigung einer Verbindungsaktivierung. - 4) TA_EXPIRED and (RC < MNT)
Wartefrist für das Eintreffen einer Bestätigung AC oder Quittung AK ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist nicht überschritten. - 5) TA_EXPIRED and (RC = MNT)
Wartefrist für das Eintreffen einer Bestätigung AC oder Quittierung AK ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist erreicht. - 6) T_DATA_REQ (DATA_LENGTH, DATA)
Eingang eines Auftrags zur Übertragung der Daten DATA der Länge DATA_LENGTH. - 7) RECEIVE_AK (SNV(S)) and (NSEG ] 1)
Empfang einer Quittung, die den korrekten Empfang der vorhergehenden Datennachricht DT bestätigt, wobei noch weitere (mindestens 2) Datensegmente zu übertragen sind. - 8) RECEIVE_AK (SNV(S)) and (NSEG = 1)
Empfang einer Quittung, die den korrekten Empfang der vorhergehenden Datennachricht DT bestätigt, wobei noch ein weiteres Datensegment zu übertragen ist. - 9) RECEIVE_AK (SNV(S)) and (NSEG = 0)
Empfang einer Quittung, die den korrekten Empfang der vorhergehenden Datennachricht DT mit dem letzten Datensegment bestätigt. Die Übertragung der Daten ist somit abgeschlossen. - 10) RECEIVE_AK (SN = V(S)), RS = RR)
Empfang einer Quittung, deren Sequenznummer SN identisch ist mit der Sequenznummer der vorhergehenden Nachricht DT. Dieses Ereignis kann auftreten, wenn durch vorzeitigen Fristablauf eine Datennachricht DT erneut gesendet wird und der Empfänger diese Nachricht als Duplikat erkennt. Die Statusinformation RS zeigt an, daß der Empfänger empfangsbereit ist. - 11) RECEIVE_AK (SN = V/(S), RS = RNR)
Empfang einer Quittung, deren Sequenznummer SN identisch ist mit der Sequenznummer der vorhergehenden Nachricht DT. Dieses Ereignis kann auftreten, wenn die Transport-Empfangsprotokollinstanz eine Datennachricht DT nicht entgegennehmen kann. Die Statusinformation RS zeigt an, daß der Empfänger nicht empfangsbereit ist.
- 1) SEND (AR)
Senden einer Nachricht AR zur Verbindungsaktivierung. - 2) SEND (DT)
Senden einer Nachricht DT. - 3) SEND (AC)
Senden einer Nachricht AC zur Bestätigung der Verbindungsaktivierung. - 4) RESEND_AR
Wiederholung des Sendens einer Nachricht AR zur Verbindungsaktivierung. - 5) RESEND_LAST_DT
Wiederholung des Sendens der letzten Datennachricht DT. - 6) START_TA
Rücksetzen und Starten des Timers zur Überwachung der Wartefrist TA. - 7) CANCEL_TA
Rücksetzen des Timers zur Überwachung der Wartefrist TA. - 8) IF (DATA_LENGTH MOD 7) THEN NSEG :=DATA_LENGTH/7
Berechnung der Segmentanzahl NSEG im Falle, daß die Datenlänge DATA_LENGTH ohne Rest durch 7 teilbar ist. - 9) NSEG := INT (DATA_LENGTH/7) + 1
Berechnung der Segmentanzahl NSEG im Falle, daß die Datenlänge DATA_LENGTH nicht ohne Rest durch 7 teilbar ist. Die Funktion INT(X) rundet die reelle Zahl X und gibt einen ganzzahligen Wert zurück. - 10) IF (NSEG < 1) THEN (EOM := 0, NB : 7) ELSE (EOM := 1, NB := DATA
LENGTH)
In Abhängigkeit von NSEG werden die Kontrollvariablen EOM und NB gesetzt. - 11) NSEG := NSEG - 1
Dekrementierung der Segmentanzahl nach erfolgreicher Segmentüber tragung. - 12) IF (RS(AK) = RR) (SEND (DT))
Die Nachricht DT mit dem nächsten Datensegment wird gesendet, wenn die Transport-Empfangsprotokollinstanz in der letzten Quit tungsnachricht ihre Empfangsbereitschaft angezeigt hat. Andern falls wird die Nachricht DT erst nach Verstreichen der Wartezeit TA gesendet. - 13) RC := 1
Setzen der Sendewiederholungsvariablen RC auf den Wert 1. - 14) RC := RC + 1
Inkrementieren der Sendewiederholungsvariablen RC um den Wert 1. - 15) V(S) := 1 - V(S)
Komplementieren der Sendefolgevariablen V(S) - 16) V(C) := RECEIVE_READY
Setzen der Verbindungsstatusvariablen V(C) auf den Wert RECEIVE_READY. - 17) V(C) := DEACTIVATED
Setzen der Verbindungsstatusvariablen V(C) auf den Wert DEACTIVATED. - 18) V(C) := NOT_ACTIVATED
Setzen der Verbindungsstatusvariablen V(C) auf den Wert NOT_ACTIVATED. - 19) RESET_VARIABLES ()
Besetzen der Protokollvariablen mit den Voreinstellungswerten (siehe Tabelle 6). - 20) DT := DT (SN = V(S), EOM = . . ., NB = . . .)
Bildung einer Datennachricht DT. Der Sequenznummervariablen SN wird dabei der Wert der Sendefolgenvariablen V(S) zugewiesen. Die Wert von EOM und NB werden in Abhängigkeit der Anzahl der noch zu übertragenden Datensegmente gesetzt. - 21) D_ACTIVATE_CON (CONNECTION_STATUS := V(C))
Bestätigung des Verbindungsaktivierungsdienstes. - 22) D_ACTIVATE_IND ()
Anzeige einer Verbindungsaktivierung. - 23) D_DATA_ACK_CON (TRANSFER_STATUS := SUCCESS)
Positive Bestätigung des Datenübertragungsdienstes. - 24) D_DATA_ACK_CON (TRANSFER_STATUS := NO_SUCCESS)
Negative Bestätigung des Datenübertragungsdienstes. - 25) D_DEACTIVATED_IND
Anzeige einer automatischen Verbindungsdeaktivierung.
Fig. 13 zeigt den Zustandsparagraphen der Transport-Empfangsprotokoll
instanz. Auch hier gilt der gleiche formale Aufbau wie in den Fig. 7,
8 und 12. Die Transport-Empfangsprotokollinstanz hat folgende
Zustände:
- 1) INACTIVE
Im Zustand INACTIVE befindet sich die Transport-Empfangsproto kollinstanz nach der Initialisierung. In diesem Zustand wartet die Protokollinstanz auf den Antrag zur Aktivierung der Verbindung (Ereignis T_ACTIVATE_REQ) bzw. auf den Eingang einer Verbin dungsaktivierungsnachricht AR der Partnerprotokollinstanz. Wenn das Ereignis T_ACTIVATE_REQ auftritt, wird die Aktivierungsnach richt AR an die Transport-Sendeprotokollinstanz gesendet (Aktion SEND (AR)) und der Folgezustand START_UP eingenommen (Übergangs pfeil 121). Wenn im Zustand INACTIVE (vor Eingang des Verbin dungsaktivierungsauftrags) die Aktivierungsnachricht AR zur Ver bindungsaktivierung eintrifft (Ereignis RECEIVE_AR), wird eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und der Folge zustand READY eingenommen, in dem die Transport-Empfangsprotokoll instanz bereit ist, Daten zu empfangen (Übergangspfeil 122). - 2) START_UP
Im Zustand START_UP wartet die Transport-Empfangsprotokollinstanz auf die Bestätigungsnachricht AC (Bestätigung der Verbindungsak tivierung) der angesprochenen Sendeprotokollinstanz. Nach Eingang der Bestätigungsnachricht AC oder nach Eingang der Aktivierungs nachricht AR (Verbindungsaktivierungswunsch der Transport-Sende protokollinstanz) wechselt die Transport-Empfangsprotokollinstanz in den Zustand READY, in dem sie bereit ist, Daten zu empfangen (Übergangspfeil 123). Die entsprechende Transport-Sendeprotokoll instanz geht quasi gleichzeitig in den Zustand IDLE (siehe Über gangspfeil 113, Fig. 12). Wenn die Bestätigungsnachricht AC nach Ablauf der Wartefrist TA nicht eingetroffen ist (Ereignis TA_EXPIRED and (RC < MNT)), wird das Senden der Aktivierungnach richt AR automatisch wiederholt (Übergangspfeil 74). Nach MNT unquittierten Übertragung der Aktivierungsnachricht AR (Ereignis TA_EXPIRED and (RC = MNT)), geht die Transport-Empfangsproto kollinstanz wieder in den Zustand INACTIVE und zeigt die erfolglose Verbindungsaktivierung dem Benutzer an (Übergangspfeil 124). - 3) READY
Im Zustand READY wartet die Transport-Empfangsprotokollinstanz auf den Eingang einer Datennachricht DT. Nach Empfang einer ent sprechenden Nachricht mit der erwarteten Sequenznummer (Ereignis RECEIVE_DT (SN = V(R)) wird die Nachricht abgespeichert und eine Quittierungsnachricht AK gesendet (Aktion SEND (AK)). Falls die Nachricht des letzten Datensegment beinhaltet (EOM =1) wird dem Benutzer die Ankunft der Daten angezeigt (Aktion T_DATA_END()) (Übergangspfeil 126). Wenn die Transport-Empfangsprotokollinstanz bei Eingang einer Datennachricht DT nicht empfangsbereit ist, so wird die Nachricht verworfen und dem Sender dies durch die Übertragung einer Quittungsnachricht mit unveränderter Sequenznummer (= Sequenznummer der erwarteten Datennachricht) und dem Empfangs status "Empfänger nicht bereit" mitgeteilt (Übergangspfeil 87).
Wenn eine Datennachricht DT mit falscher Sequenznummer eintrifft (Ereignis RECEIVE_DT (SN V(R)), wird eine Quittungsnachricht AK mit der erwarteten Sequenznummer und dem aktuellen Empfangs status gesendet (Übergangspfeil 88).
Wenn im Zustand READY eine Aktivierungsnachricht AR zur Verbin dungsaktivierungs eintrifft (Ereignis RECEIVE_AR), werden den Proto kollvariablen ihre Voreinstellungswerte zugewiesen, eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und die Aktivierung dem Benutzer mitgeteilt (Übergangspfeil 127).
Tabelle 8 zeigt die Automatentabelle der Transport-Empfangsproto
kollinstanz. Die Spalte ÜGPN erhält die Übergangspfeilnummern der
Fig. 13.
- 1) INACTIVE
- 2) START_UP
- 3) READY
- 1) T_ACTIVATE_REQ
Eingang eines Auftrags zur Verbindungsaktivierung. - 2) RECEIVE_AR
Empfang einer Aufforderung zur Verbindungsaktivierung. - 3) RECEIVE_AC
Empfang einer 06004 00070 552 001000280000000200012000285910589300040 0002004131133 00004 05885Bestätigung einer Verbindungsaktivierung. - 4) TA_EXPIRED and (RC < MNT)
Wartefrist für das Eintreffen einer Bestätigungsnachricht AC ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist nicht überschritten. - 5) TA_EXPIRED and (RC = MNT)
Wartefrist für das Eintreffen einer Bestätigungsnachricht AC ist abgelaufen. Die maximale Anzahl von Sendewiederholungen ist erreicht. - 6) RECEIVE_DT (SN = V(R), EOM = 0) and RECEIVE_STATUS () = RECEIVE
READY
Eingang einer erwarteten Datennachricht DT. Der Nachricht DT folgen eine oder mehrere Nachrichten mit weiteren, zusammengehörenden Datensegmenten. Die Transport-Empfangsprotokollinstanz ist empfangsbereit. - 7) RECEIVE_DT (SN = UV(R), EOM = 1) and RECEIVE_STATUS () = RECEIVE
READY
Eingang einer erwarteten Datennachricht DT. Die Datennachricht DT enthält das letzte Segment der Daten. Die Transport-Empfangs protokollinstanz ist empfangsbereit. - 8) RECEIVE_Dt (SN = V(R)) and RECEIVE_STATUS () = RECEIVE_NOT_READY
Eingang einer erwarteten Datennachricht DT. Die Transport- Empfangsprotokollinstanz ist nicht empfangsbereit. - 9) RECEIVE_DT (SN V(R))
Eingang einer nicht erwarteten Datennachricht DT.
- 1) SEND (AR)
Senden einer Nachricht AR zur Verbindungsaktivierung. - 2) SEND (AR)
Senden einer Nachricht AC zur Bestätigung der Verbindungsaktivierung. - 3) RESEND_AR
Wiederholung des Sendens einer Nachricht AR zur Verbindungsaktivierung. - 4) START_TA
Rücksetzen und Starten des Timers zur Überwachung der Wartefrist TA. - 5) CANCEL_TA
Rücksetzen des Timers zur Überwachung der Wartefrist TA. - 6) DL := DL + 7
Inkrementieren der Datenlänge DL um 7. - 7) DL := DL + NB (DT)
Inkrementieren der Datenlänge DL um den Wert NB der empfangenen Datennachricht DT. - 8) STORE_DATA ()
Abspeichern des zuletzt empfangenen Datensegments. - 9) RC := 1
Setzen der Sendewiederholungsvariablen RC auf den Wert 1. - 10) RC := RC + 1
Inkrementieren der Sendewiederholungsvariablen RC um den Wert 1. - 11) V(R) := 1 - V(R)
Komplementieren der Empfangsfolgevariablen V(R). - 12) V(C) := RECEIVE_READY
Setzen der Verbindungsstatusvariablen V(C) auf den Wert RECEIVE READY. - 13) V(C) := NOT_ACTIVATED
Setzen der Verbindungsstatusvariablen V(C) auf den Wert NOT_ACTIVATED. - 14) V(C) := RECEIVE_STATUS ()
Die Funktion (RECEIVE_STATUS () stellt die Empfangsbereitschaft der Transport-Empfangsprotokollinstanz fest. Der Rückgabewert der Funktion RECEIVE_READY bzw. RECEIVE_NOT_READY) wird der Verbindungs statusvariablen V(C) zugewiesen. - 15) REST_VARIABLES ()
Besetzen der Protokollvariablen mit den Voreinstellungswerten (siehe Tabelle 6). - 16) AK := AK (SN = V(R), RS = V(C)
Bildung einer Quittungsnachricht AK. Der Sequenznummervariablen SN wird dabei der Wert der Empfangsfolgevariablen V(R) zugewiesen. Der Empfangsstatusvariablen RS wird der Wert der Verbin dungsstatusvariablen V(C) zugewiesen. - 17) D_ACTIVATE_CON (CONNECTION_STATUS := V(C))
Bestätigung des Verbindungsaktivierungsdienstes. - 18) D_ACTIVATE_IND ()
Anzeige einer Verbindungsaktivierung. - 19) D_DATA_ACK_IND (DATA_LENGTH, DATA)
Anzeige des korrekten Empfangs von Daten. Als Parameter werden die Datenlänge DATA_LENGTH und die Daten DATA übergeben.
Eine Variante des Transport-Protokolls ermöglicht der Transport-
Sendeprotokollinstanz w Datennachrichten nacheinander abzusenden,
ohne auf den Empfang einer Quittungsnachricht AK zu warten (sogenannte
Sliding-Window-Technik, w = Größe des Window). Die Transport-
Empfangsprotokollinstanz kann bei dieser Protokollvariante den
Empfang mehrerer aufeinanderfolgender Datennachrichten mit einer
einzelnen Quittungsnachricht bestätigen (sogenanntes Acknowledgement
Accumulation).
Claims (38)
1. Verfahren zum Austausch von Daten mit Hilfe einer Nachricht in
Datenverarbeitungsanlagen mit mindestens zwei Stationen, die durch
einen Bus miteinander verbunden sind, wobei die Nachricht in einer
Botschaft übertragen wird, wobei die Botschaft mindestens ein Kopffeld
und ein Datenfeld enthält, das Kopffeld am Anfang der Botschaft
steht, die Botschaft identifiziert und die Priorität der Botschaft
festgelegt, wobei die Prioriät den Zugang zum Bus bestimmt,
dadurch gekennzeichnet,
daß Verbindungen (24) zwischen mindestens zwei Stationen (33, 34)
über den Bus eingerichtet, aktiviert und deaktiviert werden, über
die Nachrichten auszutauschen sind und, daß dem Kopffeld (39) der
Botschaft ein Kontrollinformationsfeld (58, 95) hinzugefügt wird, in
dem mindestens ein Nachrichtencode zur näheren Kennzeichnung der
durch die Botschaft übertragenen Nachricht abgelegt wird.
2. Verfahren nach Anspruch 1,
dadurch gekennzeichnet,
daß zur Einrichtung einer Verbindung (24) in den Stationen (33, 34)
der Verbindung (24) jeweils ein aus Daten bestehendes Sende-Objekt
(36) und Empfangs-Objekt (35) gespeichert wird.
3. Verfahren nach Anspruch 1 oder 2,
dadurch gekennzeichnet,
daß bei Aktivierung einer Verbindung (24) eine Aktivierungsnachricht
(AR) von einer der Stationen (33, 34) ausgegeben wird, die von min
destens einer anderen empfangenden Station (33, 34) durch eine Bestätigungs
nachricht (AC) quittiert wird und daß die Aktivierung der
Nachrichten-Verbindung (24) den Benutzern mitgeteilt wird.
4. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß bei Deaktivierung einer Verbindung (24) ein Verbindungsstatus
speicher in den jeweiligen Stationen (33, 34) der Nachrichten-Verbindung
(24) auf einen bestimmten Wert gesetzt wird.
5. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß für den Nachrichtencode mindestens ein Bit verwendet wird.
6. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß bei aktivierter Verbindung (24) jede Station (33, 34) nach dem
Empfang einer und/oder mehrerer Datennachrichten (DT) den Empfang
der einen und/oder mehreren Datennachricht (DT) durch Rücksendung
einer Quittungsnachricht (AK) bestätigt, wobei die Datennachricht
(DT) sowie die Quittungsnachricht (AK) mit Botschaften übertragen
werden.
7. Verfahren nach Anspruch 6,
dadurch gekennzeichnet,
daß in dem Kontrollinformationsfeld (58, 95) der Botschaft ein Teil
des Feldes (64, 102) für eine Sequenznummer (SN) zur Unterscheidung
aufeinanderfolgender Datennachrichten (DT), sowie zur Erkennung von
Datennachrichten-Duplikaten, sowie zur Zuordnung von Quittungsnach
richten (AK) zu Datennachrichten (DT) verwendet wird.
8. Verfahren nach Anspruch 7,
dadurch gekennzeichnet,
daß für die Sequenznummer (SN) mindestens ein Bit verwendet wird.
9. Verfahren nach einem der Ansprüche 6 bis 8,
dadurch gekennzeichnet,
daß in dem Kontrollinformationsfeld (58, 95) einer die Quittungsnachricht
(AK) übertragenden Botschaft ein Empfängerstatusfeld (65, 105)
vorgesehen wird.
10. Verfahren nach Anspruch 9,
dadurch gekennzeichnet,
daß für das Empfängerstatusfeld (65, 105) mindestens ein Bit verwendet
wird.
11. Verfahren nach einem der vorhergehenden Ansprüche 3 bis 10,
dadurch gekennzeichnet,
daß sich das Kopffeld (39) der die Quittungsnachricht (AK) übertragenden
Botschaft in mindestens einem signifikanten Bit von dem Kopf
feld (39) der die Datennachricht (DT) übertragenden Botschaft unter
scheidet.
12. Verfahren nach Anspruch 11,
dadurch gekennzeichnet,
daß mindestens eine signifikante Bit an letzter Stelle (41) des
Kopffeldes (39) positioniert wird.
13. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß eine vollständige Nachricht mit einer einzelnen Botschaft übertragen
wird oder nach Segmentierung mit mehreren Botschaften übertragen
wird.
14. Verfahren nach Anspruch 13,
dadurch gekennzeichnet,
daß die Botschaften, die ein Nachrichtensegment übertragen, in den
Kontrollinformationsfeldern (95) der Botschaften gekennzeichnet
werden.
15. Verfahren nach Anspruch 14,
dadurch gekennzeichnet,
daß die Botschaft, die das letzte Nachrichtensegment überträgt, in
einem Feld (103) des Kontrollinformationsfeldes (95) als solche
gekennzeichnet wird.
16. Verfahren nach Anspruch 14 oder 15,
dadurch gekennzeichnet,
daß das Kontrollinformationsfeld (95) der Botschaft eine Angabe
über die Länge des folgenden Datenfeldes der Botschaft eingegeben
wird.
17. Verfahren nach Anspruch 16,
dadurch gekennzeichnet,
daß die Angabe über die Länge des dem Kontrollinformationsfeld (95)
folgenden Datenfeldes nur in einem Feld (104) des Kontrollinforma
tionsfeldes (95) der das letzte Nachrichtensegment übertragenden
Botschaft eingegeben wird.
18. Verfahren nach einem der Ansprüche 6 bis 17,
dadurch gekennzeichnet,
daß beim Ausbleiben der Quittungsnachricht (AK) die Datennachricht
(DT) nach einer vorbestimmten Wartezeit erneut gesendet wird.
19. Verfahren nach Anspruch 18,
dadurch gekennzeichnet,
daß beim wiederholten Ausbleiben der Quittungsnachricht (AK) die
Datennachricht (DT) nur so oft wiederholt wird, bis eine bestimmte
Anzahl von Sendewiederholungen erreicht ist.
20. Verfahren nach Anspruch 19,
dadurch gekennzeichnet,
daß bei Überschreitung der bestimmten Anzahl von Sendewiederholungen
die Verbindung (24) deaktiviert wird und die Deaktivierung den
Benutzern der Verbindung (24) mitgeteilt wird.
21. Verfahren zum Aufbau von Botschaften in einer Station zum
Einsatz in einer mindestens zwei Stationen aufweisenden
Datenverarbeitungsanlage, wobei die mindestens zwei Stationen durch
einen Bus miteinander verbunden sind, wobei die Botschaft eine Nachricht
zwischen mindestens zwei Stationen der Datenverarbeitungsanlage
überträgt, die Botschaft mindestens ein Kopffeld und ein Datenfeld
enthält, das Kopffeld am Anfang der Botschaft steht, die Botschaft
identifiziert und die Priorität der Botschaft festlegt, wobei
die Priorität den Zugang zum Bus bestimmt,
dadurch gekennzeichnet,
daß dem Kopffeld (39) der Botschaft ein Kontrollinformationsfeld
(58, 95) hinzugefügt wird, in dem mindestens ein Nachrichtencode zur
näheren Kennzeichnung der durch die Botschaft übertragenen Nachricht
abgelegt wird.
22. Verfahren nach Anspruch 21,
dadurch gekennzeichnet,
daß für den Nachrichtencode mindestens ein Bit verwendet wird.
23. Verfahren nach Anspruch 21 oder 22,
dadurch gekennzeichnet,
daß in dem Kontrollinformationsfeld (58, 95) der Botschaft ein Teil
des Feldes (64, 102) für eine Sequenznummer (SN) zur Unterscheidung
aufeinanderfolgender Datennachrichten (DT), sowie zur Erkennung von
Datennachrichten-Duplikaten, sowie zur Zuordnung von Quittungsnachrichten
(AK) zu Datennachrichten (DT) verwendet wird.
24. Verfahren nach Anspruch 23,
dadurch gekennzeichnet,
daß für die Sequenznummer (SN) mindestens ein Bit verwendet wird.
25. Verfahren nach einem der Ansprüche 21 bis 24,
dadurch gekennzeichnet,
daß in dem Kontrollinformationsfeld (58, 95) einer die Quittungs
nachricht (AK) übertragenden Botschaft ein Empfängerstatusfeld
(65, 105) vorgesehen wird.
26. Verfahren nach Anspruch 25,
dadurch gekennzeichnet,
daß für das Empfängerstatusfeld (65, 105) mindestens ein Bit verwendet
wird.
27. Verfahren nach einem der Ansprüche 21 bis 26,
dadurch gekennzeichnet,
daß sich das Kopffeld (39) der die Quittungsnachricht (AK) übertragenden
Botschaft in mindestens einem signifikanten Bit von dem Kopf
feld (39) der die Datennachricht (DT) übertragenden Botschaft unter
scheidet.
28. Verfahren nach Anspruch 27,
dadurch gekennzeichnet,
daß das mindestens eine signifikante Bit an letzter Stelle (41) des
Kopffeldes (39) positioniert wird.
29. Verfahren nach einem der Ansprüche 21 bis 28,
dadurch gekennzeichnet,
daß die Botschaften, die ein Nachrichtensegment übertragen, in den
Kontrollinformationsfelder (95) der Botschaften gekennzeichnet
werden.
30. Verfahren nach einem der Ansprüche 21 bis 29,
dadurch gekennzeichnet,
daß die Botschaft, die das letzte Nachrichtensegment überträgt, in
einem Feld (103) des Kontrollinformationsfeldes (95) als solche
gekennzeichnet wird.
31. Verfahren nach einem der Ansprüche 21 bis 30,
dadurch gekennzeichnet,
daß in das Kontrollinformationsfeld (95) der Botschaft eine Angabe
über die Länge des folgenden Datenfeldes der Botschaft eingegeben
wird.
32. Verfahren nach einem der Ansprüche 21 bis 31,
dadurch gekennzeichnet,
daß die Angabe über die Länge des dem Kontrollinformationsfeld (95)
folgenden Datenfeldes nur in einem Feld (104) des Kontrollinformations
feldes (95) der das letzte Nachrichtensegment übertragenden
Botschaft eingegeben wird.
33. Vorrichtung zur Durchführung des Verfahrens nach einem der
Ansprüche 1 bis 20, mit mindestens zwei Stationen (33, 34) mit
mindestens einem Rechner, mit einem Schnittstellen-Baustein in jeder
der Stationen (33, 34), mit einer Busverbindung zwischen den Schnitt
stellen-Bausteinen der Stationen (33, 34), mit Mitteln zur Erzeugung,
zum Empfang und zur Fehlererkennung von Botschaften in den Schnittstellen-
Bausteinen, mit Mitteln zum Datenaustausch zwischen Schnitt
stellen-Baustein und Rechner einer jeden Station (33, 34), wobei die
Schnittstellen-Bausteine Mittel zum seriellen Datenaustausch über
die Busverbindung erhalten,
dadurch gekennzeichnet,
daß in den Stationen (33, 34) jeweils Mittel zur Einrichtung, Akti
vierung und Deaktivierung von Verbindungen (24) zwischen den Stationen
(33, 34) über den Bus vorhanden sind, daß zum quittierten Austausch
von Daten über aktivierte Verbindungen (24) eine Station
(33, 34) der Verbindung (24) sendet, daß die weiteren
Stationen (33, 34) diese Datennachricht (DT) durch Rücksendung einer
Quittungsnachricht (AK) quittieren und daß die Schnittstellen-
Bausteine, die die Datennachrichten (DT) empfangen, dem angeschlos
senen Rechner den Empfang der Datennachricht (DT) mitteilen sowie
daß der Schnittstellen-Baustein, der die Quittungsnachrichten (AK)
empfängt, den Empfang der Quittungsnachricht (AK) dem
angeschlossenen Rechner mitteilt.
34. Vorrichtung nach Anspruch 33,
dadurch gekennzeichnet,
daß jede der Stationen (33, 34) zum quittierten Austausch von Daten
beliebiger Länge über aktivierte Verbindungen (24) Mittel enthält,
die, die den Daten zugeordnete, Datennachricht (DT) segmentieren.
35. Vorrichtung nach Anspruch 33 oder 34,
dadurch gekennzeichnet,
daß als Mittel zum segmentierten und quittierten Austausch von Daten
beliebiger Länge über aktivierte Verbindungen (24) eine Station
(33, 34) der Verbindung (24) ein Datennachrichtensegment an die
weiteren Stationen (33, 34) der Verbindung (24) sendet, daß die
weiteren Stationen (33, 34) das Datennachrichtensegment durch Rück
sendung einer Quittungsnachricht (AK) bestätigen, daß der Schnittstellen-
Baustein, der das Datennachrichtensegment empfängt, dem an
geschlossenen Rechner den Empfang des Datennachrichtensegmentes mitteilt
und, daß der Schnittstellen-Baustein, der die Quittungsnach
richten empfängt, dem Empfang der Quittungsnachrichten (AK) dem
angeschlossenen Rechner mitteilt.
36. Vorrichtung nach einem der Ansprüche 33 bis 35,
dadurch gekennzeichnet,
daß in den Schnittstellen-Bausteinen zur fortlaufenden Numerierung
von Datennachrichtensegmenten ein Sendefolgezähler vorhanden ist,
daß zur Speicherung der Sequenznummer (SN) der nächsten zum Empfang
erwarteten Nachricht oder des nächsten zum Empfang erwarteten Daten
nachrichtensegmentes ein Empfangsfolgezähler vorhanden ist, daß zur
Speicherung des Status einer Verbindung (24) ein Verbindungsstatus
speicher vorhanden ist, daß zur Speicherung der aktuellen Anzahl der
Sendewiederholungen ein Sendewiederholungszähler vorhanden ist, daß
mindestens die Sequenznummer (SN) der letzten empfangenen Nachricht
oder des letzten empfangenen Nachrichtensegmentes sowie der Inhalt
des Empfängerstatusfeldes (65, 105) in einem Zwischenspeicher zu
speichern ist, daß die vorbestimmte Wartezeit, sowie die maximale
Anzahl der Botschaftswiederholungen in einem Speicher abzulegen ist,
daß zur Kennzeichnung der Anzahl der Datensegmente ein Datensegment
speicher vorhanden ist, daß zur Kennzeichnung der Gesamtlänge der
Datenbytes einer Nachricht oder eines Datennachrichtensegmentes ein
Datenlängenspeicher vorhanden ist.
37. Vorrichtung zur Durchführung des Verfahrens nach einem der
Ansprüche 21 bis 32, mit mindestens einem Rechner, mit einem
Schnittstellen-Baustein, mit Mitteln zum Datenaustausch zwischen
Schnittstellen-Baustein und dem mindestens einem Rechner, mit
Anschlüssen einer Busverbindung an dem Schnittstellen-Baustein, mit
Mitteln zum seriellen Datenaustausch über eine angeschlossene
Busverbindung,
dadurch gekennzeichnet,
daß Mittel zum Aufbau, zur Absendung, zum Empfang und zur
Fehlererkennung von Botschaften und zur Anlegung der den
Botschaften, sowie den Inhalten der Botschaften entsprechenden
Signale an eine angeschlossene Busverbindung vorhanden sind.
38. Vorrichtung nach Anspruch 37,
dadurch gekennzeichnet,
daß in den Schnittstellen-Bausteinen zur fortlaufenden Numerierung
von Datennachrichtensegmenten ein Sendefolgezähler vorhanden ist,
daß zur Speicherung der Sequenznummer (SN) der nächsten zum Empfang
erwarteten Nachricht oder des nächsten zum Empfang erwarteten Daten
nachrichtensegmentes ein Empfangsfolgezähler vorhanden ist, daß
mindestens die Sequenznummer (SN) der letzten empfangenen Nachricht
oder des letzten empfangenen Datennachrichtensegmentes sowie der
Inhalt des Empfängerstatusfeldes (65, 105) in einem Zwischenspeicher
zu speichern ist, daß zur Kennzeichnung der Anzahl der Datensegmente
ein Datensegmentspeicher vorhanden ist, daß zur Kennzeichnung der
Gesamtlänge der Datenbytes einer Nachricht oder eines Datennachrichten
segmentes ein Datenlängenspeicher vorhanden ist.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE4131133A DE4131133B4 (de) | 1991-09-19 | 1991-09-19 | Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen |
US07/947,501 US5448561A (en) | 1991-09-19 | 1992-09-16 | Method & apparatus for data exchange in data processing installations |
JP25128392A JP3461850B2 (ja) | 1991-09-19 | 1992-09-21 | データ処理装置におけるデータの交換方法およびデータ通信装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE4131133A DE4131133B4 (de) | 1991-09-19 | 1991-09-19 | Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen |
Publications (2)
Publication Number | Publication Date |
---|---|
DE4131133A1 true DE4131133A1 (de) | 1993-04-01 |
DE4131133B4 DE4131133B4 (de) | 2005-09-08 |
Family
ID=6440941
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE4131133A Expired - Lifetime DE4131133B4 (de) | 1991-09-19 | 1991-09-19 | Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen |
Country Status (3)
Country | Link |
---|---|
US (1) | US5448561A (de) |
JP (1) | JP3461850B2 (de) |
DE (1) | DE4131133B4 (de) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1998011700A1 (de) * | 1996-09-12 | 1998-03-19 | Robert Bosch Gmbh | Verfahren zur kontrolle der verbindungen eines übertragungssystems und komponente zur durchführung des verfahrens |
DE19754640A1 (de) * | 1997-12-09 | 1999-06-10 | Bosch Gmbh Robert | Verfahren zur Koordination von Netzwerkkomponenten |
US6636100B1 (en) | 1999-06-29 | 2003-10-21 | Mitsubishi Denki Kabushiki Kaisha | Can controller and one-chip computer having a built-in can controller |
DE102007035533A1 (de) * | 2007-07-28 | 2009-01-29 | Biotronik Crm Patent Ag | Anordnung und Verfahren zur Verwaltung einer Datenübertragungsschicht für ein persönliches medizinisches Gerät |
DE102012223352A1 (de) * | 2012-12-17 | 2014-06-18 | Siemens Aktiengesellschaft | Verfahren zum Betreiben eines Gebäudeinstallationssystems |
Families Citing this family (145)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE4229175A1 (de) * | 1992-09-02 | 1994-03-03 | Bosch Gmbh Robert | Netzwerkschnittstelle |
US6643362B2 (en) * | 1998-11-19 | 2003-11-04 | Global Crossing, Ltd. | Call-processing system and method |
US5590181A (en) * | 1993-10-15 | 1996-12-31 | Link Usa Corporation | Call-processing system and method |
JP2848784B2 (ja) * | 1994-08-02 | 1999-01-20 | 沖電気工業株式会社 | パケット交換方式 |
DE19509558A1 (de) * | 1995-03-16 | 1996-09-19 | Abb Patent Gmbh | Verfahren zur fehlertoleranten Kommunikation unter hohen Echtzeitbedingungen |
US6067407A (en) * | 1995-06-30 | 2000-05-23 | Canon Information Systems, Inc. | Remote diagnosis of network device over a local area network |
US5754774A (en) * | 1996-02-15 | 1998-05-19 | International Business Machine Corp. | Client/server communication system |
EP0882342B1 (de) * | 1996-02-22 | 2006-07-05 | Kvaser Consultant Ab | Vorrichtung zur Beeinflussung von Nachrichten in einem CAN-System |
US5673322A (en) * | 1996-03-22 | 1997-09-30 | Bell Communications Research, Inc. | System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks |
DE19623738C2 (de) * | 1996-06-14 | 1998-08-06 | Deere & Co | Fahrzeug mit Elektroantrieb |
US5953681A (en) * | 1996-07-30 | 1999-09-14 | Bayer Corporation | Autonomous node for a test instrument system having a distributed logic nodal architecture |
US5772963A (en) * | 1996-07-30 | 1998-06-30 | Bayer Corporation | Analytical instrument having a control area network and distributed logic nodes |
DE19640346C2 (de) * | 1996-09-20 | 1999-03-04 | Tektronix Inc | Verfahren zum Überprüfen eines gemäß einem Kommunikationsprotokoll durchgeführten Datenaustausches |
US6164920A (en) * | 1996-09-30 | 2000-12-26 | Minnesota Mining And Manufacturing Company | Perfusion system with control network |
US5752931A (en) * | 1996-09-30 | 1998-05-19 | Minnesota Mining And Manufacturing Company | Perfusion system with perfusion circuit display |
US5813972A (en) * | 1996-09-30 | 1998-09-29 | Minnesota Mining And Manufacturing Company | Medical perfusion system with data communications network |
US6456974B1 (en) * | 1997-01-06 | 2002-09-24 | Texas Instruments Incorporated | System and method for adding speech recognition capabilities to java |
US6324592B1 (en) | 1997-02-25 | 2001-11-27 | Keystone Aerospace | Apparatus and method for a mobile computer architecture and input/output management system |
AU6473498A (en) * | 1997-03-20 | 1998-10-12 | Ericsson Inc. | Method for implementing a transport layer protocol for wireless packet data delivery |
US5931915A (en) | 1997-05-13 | 1999-08-03 | International Business Machines Corporation | Method for processing early arrival messages within a multinode asynchronous data communications system |
US6035335A (en) * | 1997-08-26 | 2000-03-07 | International Business Machines Corporation | Optimistic, eager rendezvous transmission system and combined rendezvous system for message processing, and related data structures |
US6178174B1 (en) | 1997-08-26 | 2001-01-23 | International Business Machines Corporation | Optimistic, eager rendezvous transmission mode and combined rendezvous modes for message processing systems |
US6070184A (en) * | 1997-08-28 | 2000-05-30 | International Business Machines Corporation | Server-side asynchronous form management |
US6035324A (en) * | 1997-08-28 | 2000-03-07 | International Business Machines Corporation | Client-side asynchronous form management |
US6223221B1 (en) | 1998-02-05 | 2001-04-24 | International Business Machines Corporation | System and method for calculating the transfer rate across a communication medium using a downloaded test program and transferring data accordingly |
CA2280571A1 (en) * | 1998-11-30 | 2000-05-30 | Daimlerchrysler Corporation | J1850 application specific integrated circuit (asic) and messaging technique |
US6505097B1 (en) | 1999-01-13 | 2003-01-07 | Sony Corporation | Arithmetic processing device, inter-object communication method, and robot |
GB2351884B (en) * | 1999-04-10 | 2002-07-31 | Peter Strong | Data transmission method |
US6757597B2 (en) | 2001-01-31 | 2004-06-29 | Oshkosh Truck | A/C bus assembly for electronic traction vehicle |
US6885920B2 (en) | 1999-07-30 | 2005-04-26 | Oshkosh Truck Corporation | Control system and method for electric vehicle |
US7729831B2 (en) | 1999-07-30 | 2010-06-01 | Oshkosh Corporation | Concrete placement vehicle control system and method |
FI19992470L (fi) * | 1999-11-17 | 2001-05-18 | Nokia Mobile Phones Ltd | Tiedonsiirto |
US6442708B1 (en) | 1999-12-14 | 2002-08-27 | Honeywell International Inc. | Fault localization and health indication for a controller area network |
DE10000303B4 (de) * | 2000-01-05 | 2011-09-29 | Robert Bosch Gmbh | Verfahren und Vorrichtung zum Austausch von Daten zwischen wenigstens zwei mit einem Bussystem verbundenen Teilnehmern |
US6799200B1 (en) | 2000-07-18 | 2004-09-28 | International Business Machines Corporaiton | Mechanisms for efficient message passing with copy avoidance in a distributed system |
US6735620B1 (en) | 2000-07-18 | 2004-05-11 | International Business Machines Corporation | Efficient protocol for retransmit logic in reliable zero copy message transport |
US7089289B1 (en) | 2000-07-18 | 2006-08-08 | International Business Machines Corporation | Mechanisms for efficient message passing with copy avoidance in a distributed system using advanced network devices |
US6795941B2 (en) | 2000-12-21 | 2004-09-21 | Honeywell International Inc. | Method for diagnosing a network |
US7277782B2 (en) | 2001-01-31 | 2007-10-02 | Oshkosh Truck Corporation | Control system and method for electric vehicle |
US7379797B2 (en) * | 2001-01-31 | 2008-05-27 | Oshkosh Truck Corporation | System and method for braking in an electric vehicle |
US20020154119A1 (en) * | 2001-04-24 | 2002-10-24 | Lepejian Yervant D. | Apparatus and method for performing branch processing according to a user indicated selection from displayed graphics |
FR2824213B1 (fr) * | 2001-04-27 | 2003-08-01 | Renault | Dispositif de generation d'une messagerie commune a plusieurs systemes electroniques produisant et consommant des donnees |
US20050198379A1 (en) | 2001-06-13 | 2005-09-08 | Citrix Systems, Inc. | Automatically reconnecting a client across reliable and persistent communication sessions |
US7562146B2 (en) | 2003-10-10 | 2009-07-14 | Citrix Systems, Inc. | Encapsulating protocol for session persistence and reliability |
US7180879B2 (en) * | 2001-08-17 | 2007-02-20 | Ragulan Sinnarajah | Method and apparatus for call setup latency reduction |
EP1315337B1 (de) * | 2001-10-31 | 2009-08-12 | Infineon Technologies AG | Bus-Interface |
US7254468B2 (en) | 2001-12-21 | 2007-08-07 | Oshkosh Truck Corporation | Multi-network control system for a vehicle |
US7302320B2 (en) | 2001-12-21 | 2007-11-27 | Oshkosh Truck Corporation | Failure mode operation for an electric vehicle |
US7117264B2 (en) * | 2002-01-10 | 2006-10-03 | International Business Machines Corporation | Method and system for peer to peer communication in a network environment |
US7661129B2 (en) | 2002-02-26 | 2010-02-09 | Citrix Systems, Inc. | Secure traversal of network components |
US7984157B2 (en) | 2002-02-26 | 2011-07-19 | Citrix Systems, Inc. | Persistent and reliable session securely traversing network components using an encapsulating protocol |
US7520354B2 (en) | 2002-05-02 | 2009-04-21 | Oshkosh Truck Corporation | Hybrid vehicle with combustion engine/electric motor drive |
JP2004158988A (ja) * | 2002-11-05 | 2004-06-03 | Nissan Motor Co Ltd | データ送信装置及び方法、データ通信システム |
FR2847751B1 (fr) * | 2002-11-22 | 2005-04-01 | Peugeot Citroen Automobiles Sa | Systeme de transmission securisee d'informations entre des stations raccordees par un reseau de transmission d'informations embarque a bord d'un vehicule automobile |
FR2852765B1 (fr) * | 2003-03-21 | 2005-06-24 | Peugeot Citroen Automobiles Sa | Systeme de securisation de la transmission d'au moins certaines trames de commande sur un reseau multiplexe de transmission d'informations |
CA2571386C (en) * | 2004-06-21 | 2010-10-12 | Research In Motion Limited | System and method for handling message receipt notification |
WO2006013979A1 (ja) * | 2004-08-06 | 2006-02-09 | Sharp Kabushiki Kaisha | 送信機、受信機、通信システム、通信方法、通信プログラム |
US7439711B2 (en) * | 2004-09-27 | 2008-10-21 | Oshkosh Corporation | Energy storage device including a status indicator |
US7516226B2 (en) * | 2004-09-30 | 2009-04-07 | Agere Systems Inc. | Transmit adaptive equalization using ordered sets |
US20060078127A1 (en) * | 2004-10-08 | 2006-04-13 | Philip Cacayorin | Dispersed data storage using cryptographic scrambling |
US8051182B2 (en) * | 2005-01-28 | 2011-11-01 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, communication program, and communication circuit |
US7787391B2 (en) * | 2005-01-28 | 2010-08-31 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, communication program, and communication circuit |
US8284684B2 (en) * | 2005-01-28 | 2012-10-09 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, and communication circuit |
CN101964705B (zh) * | 2005-01-28 | 2012-08-08 | 夏普株式会社 | 通信设备、通信系统、通信方法、通信程序、通信电路 |
US20070027485A1 (en) * | 2005-07-29 | 2007-02-01 | Kallmyer Todd A | Implantable medical device bus system and method |
CN101305580B (zh) * | 2005-11-10 | 2012-01-18 | 夏普株式会社 | 数据发送装置及其控制方法、数据接收装置及其控制方法、数据发送系统、数据发送装置控制程序、数据接收装置控制程序以及记录有该程序的记录介质 |
US8947531B2 (en) | 2006-06-19 | 2015-02-03 | Oshkosh Corporation | Vehicle diagnostics based on information communicated between vehicles |
US8139109B2 (en) | 2006-06-19 | 2012-03-20 | Oshkosh Corporation | Vision system for an autonomous vehicle |
JP4219950B2 (ja) * | 2006-10-16 | 2009-02-04 | シャープ株式会社 | 通信機器、通信方法、通信回路、携帯電話機、プログラム、およびプログラムを記録したコンピュータ読み取り可能な記録媒体 |
US7853375B2 (en) * | 2007-04-10 | 2010-12-14 | Maurice Tuff | Vehicle monitor |
US8908700B2 (en) | 2007-09-07 | 2014-12-09 | Citrix Systems, Inc. | Systems and methods for bridging a WAN accelerator with a security gateway |
CN101431847A (zh) | 2008-02-05 | 2009-05-13 | 马田专业公司 | 分布式驱动器和控制器区域网络总线通信协议 |
DE102008000561A1 (de) * | 2008-03-07 | 2009-09-10 | Robert Bosch Gmbh | Kommunikationssystem mit einem CAN-Bus und Verfahren zum Betreiben eines solchen Kommunikationssystems |
US8239066B2 (en) | 2008-10-27 | 2012-08-07 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US9268345B2 (en) | 2008-10-27 | 2016-02-23 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8874815B2 (en) | 2008-10-27 | 2014-10-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network |
US8788100B2 (en) | 2008-10-27 | 2014-07-22 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
US8600558B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8255086B2 (en) | 2008-10-27 | 2012-08-28 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US9377768B2 (en) | 2008-10-27 | 2016-06-28 | Lennox Industries Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US9632490B2 (en) | 2008-10-27 | 2017-04-25 | Lennox Industries Inc. | System and method for zoning a distributed architecture heating, ventilation and air conditioning network |
US8655491B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8452456B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8442693B2 (en) | 2008-10-27 | 2013-05-14 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8977794B2 (en) | 2008-10-27 | 2015-03-10 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9325517B2 (en) | 2008-10-27 | 2016-04-26 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8744629B2 (en) | 2008-10-27 | 2014-06-03 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8725298B2 (en) | 2008-10-27 | 2014-05-13 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network |
US8437878B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US9261888B2 (en) | 2008-10-27 | 2016-02-16 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8615326B2 (en) | 2008-10-27 | 2013-12-24 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8295981B2 (en) | 2008-10-27 | 2012-10-23 | Lennox Industries Inc. | Device commissioning in a heating, ventilation and air conditioning network |
US8560125B2 (en) | 2008-10-27 | 2013-10-15 | Lennox Industries | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8655490B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8774210B2 (en) | 2008-10-27 | 2014-07-08 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9432208B2 (en) | 2008-10-27 | 2016-08-30 | Lennox Industries Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
US8892797B2 (en) | 2008-10-27 | 2014-11-18 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8994539B2 (en) | 2008-10-27 | 2015-03-31 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8452906B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8694164B2 (en) | 2008-10-27 | 2014-04-08 | Lennox Industries, Inc. | Interactive user guidance interface for a heating, ventilation and air conditioning system |
US8564400B2 (en) | 2008-10-27 | 2013-10-22 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8762666B2 (en) | 2008-10-27 | 2014-06-24 | Lennox Industries, Inc. | Backup and restoration of operation control data in a heating, ventilation and air conditioning network |
US8463443B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US8433446B2 (en) | 2008-10-27 | 2013-04-30 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8437877B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US9678486B2 (en) | 2008-10-27 | 2017-06-13 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8600559B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | Method of controlling equipment in a heating, ventilation and air conditioning network |
US8352080B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8802981B2 (en) | 2008-10-27 | 2014-08-12 | Lennox Industries Inc. | Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system |
US9651925B2 (en) | 2008-10-27 | 2017-05-16 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
US8352081B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8463442B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8661165B2 (en) | 2008-10-27 | 2014-02-25 | Lennox Industries, Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
US8543243B2 (en) | 2008-10-27 | 2013-09-24 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8855825B2 (en) | 2008-10-27 | 2014-10-07 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US9152155B2 (en) | 2008-10-27 | 2015-10-06 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8798796B2 (en) | 2008-10-27 | 2014-08-05 | Lennox Industries Inc. | General control techniques in a heating, ventilation and air conditioning network |
US8548630B2 (en) | 2008-10-27 | 2013-10-01 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8437824B2 (en) | 2009-06-17 | 2013-05-07 | Sotera Wireless, Inc. | Body-worn pulse oximeter |
USD648642S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
USD648641S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
US8260444B2 (en) | 2010-02-17 | 2012-09-04 | Lennox Industries Inc. | Auxiliary controller of a HVAC system |
US8693558B2 (en) | 2010-04-12 | 2014-04-08 | Qualcomm Incorporated | Providing delimiters for low-overhead communication in a network |
US8363550B1 (en) | 2010-06-15 | 2013-01-29 | Google Inc. | Adaptive data unit transmission and acknowledgment |
US8337352B2 (en) | 2010-06-22 | 2012-12-25 | Oshkosh Corporation | Electromechanical variable transmission |
US8954622B1 (en) | 2011-01-19 | 2015-02-10 | Marvell International Ltd. | Embedded programmable logic for logic stacking on application processor |
RU2013149025A (ru) * | 2011-04-06 | 2015-05-20 | Роберт Бош Гмбх | Способ и устройство для повышения пропускной способности при передаче данных в последовательной шинной системе |
CN103562901B (zh) | 2011-04-06 | 2017-01-18 | 罗伯特·博世有限公司 | 用于匹配串行总线系统中的数据传输安全性的方法和设备 |
CN103649933B (zh) * | 2011-04-26 | 2016-10-19 | 罗伯特·博世有限公司 | 用于与存储器大小匹配的串行数据传输的方法和设备 |
US8984531B2 (en) * | 2011-06-01 | 2015-03-17 | Microsoft Technology Licensing, Llc | Episodic coordination model for distributed applications |
EP2726999B1 (de) | 2011-06-29 | 2015-09-09 | Robert Bosch GmbH | Verfahren und vorrichtung zur seriellen datenübertragung mit flexibler nachrichtengrösse und variabler bitlänge |
US9114804B1 (en) | 2013-03-14 | 2015-08-25 | Oshkosh Defense, Llc | Vehicle drive and method with electromechanical variable transmission |
JP5987761B2 (ja) * | 2013-04-05 | 2016-09-07 | 株式会社デンソー | 診断システム、当該診断システムを構成する診断装置及びecu |
AU2013263700B1 (en) | 2013-11-25 | 2015-05-14 | Smart Start Technology Pty Ltd | Electrical System Enhancer |
DE102014217973A1 (de) * | 2014-09-09 | 2016-03-10 | Siemens Aktiengesellschaft | Verfahren und System zur gesicherten Kommunikation |
US11701959B2 (en) | 2015-02-17 | 2023-07-18 | Oshkosh Corporation | Inline electromechanical variable transmission system |
US10584775B2 (en) | 2015-02-17 | 2020-03-10 | Oshkosh Corporation | Inline electromechanical variable transmission system |
US9650032B2 (en) | 2015-02-17 | 2017-05-16 | Oshkosh Corporation | Multi-mode electromechanical variable transmission |
US10982736B2 (en) | 2015-02-17 | 2021-04-20 | Oshkosh Corporation | Multi-mode electromechanical variable transmission |
US12078231B2 (en) | 2015-02-17 | 2024-09-03 | Oshkosh Corporation | Inline electromechanical variable transmission system |
US10421350B2 (en) | 2015-10-20 | 2019-09-24 | Oshkosh Corporation | Inline electromechanical variable transmission system |
US9656659B2 (en) | 2015-02-17 | 2017-05-23 | Oshkosh Corporation | Multi-mode electromechanical variable transmission |
US9651120B2 (en) | 2015-02-17 | 2017-05-16 | Oshkosh Corporation | Multi-mode electromechanical variable transmission |
US10578195B2 (en) | 2015-02-17 | 2020-03-03 | Oshkosh Corporation | Inline electromechanical variable transmission system |
US11539621B2 (en) * | 2021-02-03 | 2022-12-27 | Motional Ad Llc | Controller area network messages in an autonomous vehicle |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3546684C2 (en) * | 1985-02-22 | 1991-03-07 | Robert Bosch Gmbh, 7000 Stuttgart, De | Operating communication bus network for processors |
DE3546683C3 (de) * | 1985-02-22 | 2003-10-09 | Bosch Gmbh Robert | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
CA1309519C (en) * | 1987-03-17 | 1992-10-27 | Antonio Cantoni | Transfer of messages in a multiplexed system |
DE3719283A1 (de) * | 1987-06-10 | 1988-12-22 | Bosch Gmbh Robert | Verfahren zur lokalisierung defekter stationen in lokalen netzwerken und dazugehoeriger schnittstellencontroller |
KR970011741B1 (ko) * | 1989-02-17 | 1997-07-15 | 로베르트 보쉬 게에베하 | 네트워크 인터페이스 |
US4999834A (en) * | 1989-03-20 | 1991-03-12 | International Business Machines Corporation | Communication method and apparatus |
DE4129205A1 (de) * | 1991-03-28 | 1992-10-01 | Bosch Gmbh Robert | Verfahren zum aufbau von botschaften fuer den datenaustausch und/oder fuer die synchronisation von prozessen in datenverarbeitungsanlagen |
-
1991
- 1991-09-19 DE DE4131133A patent/DE4131133B4/de not_active Expired - Lifetime
-
1992
- 1992-09-16 US US07/947,501 patent/US5448561A/en not_active Expired - Lifetime
- 1992-09-21 JP JP25128392A patent/JP3461850B2/ja not_active Expired - Lifetime
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1998011700A1 (de) * | 1996-09-12 | 1998-03-19 | Robert Bosch Gmbh | Verfahren zur kontrolle der verbindungen eines übertragungssystems und komponente zur durchführung des verfahrens |
US6643689B2 (en) | 1996-09-12 | 2003-11-04 | Robert Bosch Gmbh | Process and components for controlling the connections of a transmission system |
DE19754640A1 (de) * | 1997-12-09 | 1999-06-10 | Bosch Gmbh Robert | Verfahren zur Koordination von Netzwerkkomponenten |
US7103000B1 (en) | 1997-12-09 | 2006-09-05 | Robert Bosch Gmbh | Method for coordinating network components |
US6636100B1 (en) | 1999-06-29 | 2003-10-21 | Mitsubishi Denki Kabushiki Kaisha | Can controller and one-chip computer having a built-in can controller |
DE102007035533A1 (de) * | 2007-07-28 | 2009-01-29 | Biotronik Crm Patent Ag | Anordnung und Verfahren zur Verwaltung einer Datenübertragungsschicht für ein persönliches medizinisches Gerät |
EP2026229A3 (de) * | 2007-07-28 | 2012-01-25 | Biotronik CRM Patent AG | Anordnung und Verfahren zur Verwaltung einer Datenübertragungsschicht für ein persönliches medizinisches Gerät |
DE102012223352A1 (de) * | 2012-12-17 | 2014-06-18 | Siemens Aktiengesellschaft | Verfahren zum Betreiben eines Gebäudeinstallationssystems |
Also Published As
Publication number | Publication date |
---|---|
DE4131133B4 (de) | 2005-09-08 |
JPH05235965A (ja) | 1993-09-10 |
JP3461850B2 (ja) | 2003-10-27 |
US5448561A (en) | 1995-09-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE4131133B4 (de) | Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen | |
DE69531410T2 (de) | Mehrrechnerumgebungen | |
DE3882238T2 (de) | Verfahren zur Behandlung von durch ein Netzwerk übertragenen langsamen Anforderungen. | |
DE3788355T2 (de) | Eingangs/ausgangsnetz für ein rechnersystem. | |
DE60022994T2 (de) | Ein flexibles steuerprotokoll für funkverbindungen | |
EP0576459B1 (de) | Verfahren zum aufbau von botschaften für den datenaustausch und/oder für die synchronisation von prozessen in datenverarbeitungsanlagen | |
DE60132735T2 (de) | Fehlerkorrekturübertragungsverfahren zum Übertragen von Datenpaketen in einem Netzkommunikationssystem | |
DE60030094T2 (de) | Datenablösungsmechanismus für selektive wiederholungsprotokolle | |
DE69130187T2 (de) | Hochgeschwindigkeitsübertragungsprotokoll mit zwei Fenstern | |
DE3750647T2 (de) | Netz mit Jetonübergabe. | |
DE69328578T2 (de) | Leistungsfähiges und betriebssicheres Übertragungsverfahren und System für grosse Datenmengen | |
DE69021186T2 (de) | "Master-Slave" industrielles Netzwerk mit Tokenübergabe. | |
DE10008148A1 (de) | Verfahren zum Betreiben eines Mobilfunknetzes | |
WO1999035797A1 (de) | Verfahren zum datentransport sowie rechnernetzwerk zur durchführung des verfahrens | |
DE102007011071B4 (de) | Verfahren zur Verbesserung eines TCP Datenübertragungsprozesses im Fall einer Unterbrechung des physikalischen Übertragungsmediums | |
EP3895384B1 (de) | Überlagerungserfassungseinheit für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem | |
DE10127417A1 (de) | Transport-Protokoll für die Gerätekommunikation | |
DE60036121T2 (de) | Hochgeschwindigkeitsverbindung für eingebettete Systeme in einem Rechnernetzwerk | |
EP1312992B1 (de) | Verfahren zum Tunneln eines höherwertigen Protokolls auf einem Feldbussystem | |
EP1121645B1 (de) | Elektronische steuereinrichtung mit einem parallelen datenbus und verfahren zum betreiben der steuereinrichtung | |
DE4210094C2 (de) | Multiplexes Übertragungsverfahren | |
EP1527547B1 (de) | Verfahren und vorrichtung zur überwachung einer daten übertragung | |
EP4073983B1 (de) | Verfahren zur datenkommunikation zwischen teilnehmern eines automatisierungssystems | |
EP1380962B1 (de) | Vorrichtung und Verfahren zur Datenkommunikation | |
EP1387532B1 (de) | Optimiertes Verfahren zur Nachrichtenübertragung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8110 | Request for examination paragraph 44 | ||
8125 | Change of the main classification |
Ipc: G06F 1340 |
|
8364 | No opposition during term of opposition | ||
R071 | Expiry of right | ||
R071 | Expiry of right |