DE4131133B4 - Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen - Google Patents
Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen Download PDFInfo
- Publication number
- DE4131133B4 DE4131133B4 DE4131133A DE4131133A DE4131133B4 DE 4131133 B4 DE4131133 B4 DE 4131133B4 DE 4131133 A DE4131133 A DE 4131133A DE 4131133 A DE4131133 A DE 4131133A DE 4131133 B4 DE4131133 B4 DE 4131133B4
- Authority
- DE
- Germany
- Prior art keywords
- message
- data
- connection
- receive
- messages
- 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.)
- Expired - Lifetime
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 Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Abstract
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, dass Verbindungen
(24) zwischen mindestens zwei Stationen (33, 34) über den
Bus eingerichtet, aktiviert und deaktiviert werden, über die
Nachrichten auszutauschen sind und, dass 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, wobei 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.
Description
- Stand der Technik
- 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, dass 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 dass 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 Prozesssteuerungen zu aufwändig 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 Prozesssteuerungen 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.
- So zeigt auch die Entgegenhaltung
US 5,050,166 ein Datenübertragungsverfahren, bei dem Botschaften unterschiedlicher Länge über das Netzwerk segmentiert übertragen werden können. Bei dem dort beschriebenen Datenübertragungsverfahren ist ein Busprotokoll betrachtet, bei dem eine Teilnehmeradressierung durchgeführt wird, ja durchgeführt werden muss. D. h. jede Botschaft enthält ein Adressfeld für die Zieladresse der Botschaft und für die Quelladresse der Botschaft. Es wird also zwingend Quell- bzw. Zieladresse mitübertragen. Dabei ist kein Hinweis auf die Abspeicherung von Sende- und Empfangsobjekten für die Einrichtung einer selektiven Verbindung enthalten. - Vorteile der Erfindung
- Das erfindungsgemäße Verfahren mit den kennzeichnenden Merkmalen des Hauptanspruchs hat demgegenüber den Vorteil, dass trotz der Ein schrä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 Konfigurierung 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 aufeinander folgender 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 geignete Maßnahmen, wie Absendung weiterer zusätzlicher Botschaften 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 deaktivieren 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 Datennachrichtsegmenten 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 F1ußkontrolle ist es vorteilhaft, den Inhalt des Empfängerstatusfeldes in einem Zwischenspeicher zu speichern. Weiter vorteilhaft ist, zur Kennzeichnung der Anzahl der Datensegemente einen Datensegmentspeicher in der Vorrichtung vorzusehen, und zur Kennzeichnung der Gesamtlänge der Datenbytes einer Datennachricht oder eines Datennachrichtsegementes einen Datenlängenspeicher zu installieren.
- Zeichnung
- Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung anhand mehrerer Figuren dargestellt und in der nachfolgenden Beschreibung näher erläutert.
- Es zeigen
1 eine Darstellung zur Einordnung des erfindungsgemäßen Verfahrens in das ISO/OSI-Schichtenmodell,2 eine allgemeine Darstellung einer Punkt-zu-Punkt-Verbindung innerhalb einer Schicht des ISO/OSI-Schichtenmodells,3a ein Ausführungsbeispiel einer CAN-Verbindung zwischen zwei Stationen eines Datenverarbeitungssystems,3b den formalen Aufbau eines Sende- oder Empfangs-Objektes,4a die schematische Darstellung der Zuordnung dreier Data Link- bzw. Transport-Verbindungen zu drei einzelnen CAN-Verbindungen innerhalb des ISO/OSI-Schichtenmodells,4b eine schematische Darstellung der Zuordnung dreier Data Link- bzw. Transport-Verbindungen zu einer CAN-Verbindung innerhalb des ISO/OSI-Schichtenmodells,4c die schematische Darstellung einer Zuordnung von einer Data Link- bzw. Transport-Verbindung zu drei verschiedenen CAN-Verbindungen innerhalb des ISO/OSI-Schichtenmodells,5 den formalen Aufbau des Datenfeldes der Botschaften, bei der übertragung der verschiedenen Data Link-Nachrichten,6 den formalen Aufbau des Kontrollinformationsfeldes der Botschaften bei der Übertragung der verschiedenen Data Link-Nachrichten,7 den Zustandsgraphen einer Data Link-Sendeprotokollinstanz,8 den Zustandsgraphen einer Data Link-Empfangsprotokollinstanz,9 den formalen Aufbau des Datenfeldes der Botschaften, bei der Übertragung der verschiedenen Transport-Nachrichten,10 den formalen Aufbau des Kontrollinformationsfeldes der Botschaften bei der Übertragung der verschiedenen Transport-Nachrichten,11 ein Beispiel für die segmentierte Übertragung eines 15 Bytes langen Datensatzes,12 den Zustandsgraphen einer Transport-Sendeprotokollinstanz,13 den Zustandsgraphen einer Transport-Empfangsprotokollinstanz. - Beschreibung der Erfindung
- 1.1. Merkmale des Verfahrens
- 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.
1 zeigt die Einordnung des CAN-Protokolls17 in das ISO/OSI-Schichtenmodell. Das CAN-Protokoll17 deckt darin die Bitübertragungsschicht (Physical Layer11 ) und Teile der Sicherungsschicht (Data Link Layer16 ) ab. Die Data Link Layer16 ist in eine MAC Sublayer12 und eine LLC Sublayer Type 1, 2, 3 Operation13 unterteilt. Über der Data Link Layer16 ist die Network Layer14 und darüber die Transport Layer15 angeordnet. An der Schnittstelle S1 des CAN-Protokolls17 mit der Data Link Layer16 bietet das CAN-Protokoll17 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 Connectionless-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-Protokoll18 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-Protokoll19 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 Verbindungsdienst 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 Verbindung bewirkt, daß die den Verbindungsdienst erbringenden Protokollinstanzen zurückgesetzt werden und damit wieder in einem Zustand sind, in dem sie Daten austauschen können.
- 1.2. Verbindungen
-
2 zeigt den Austausch von Daten über Punkt-zu-Punkt-Verbindungen im Sinne des ISO/OSI-Schichtenmodells. Die Verbindung24 verläuft dabei zwischen zwei Protokollinstanzen der Schicht (N) und wird den Benutzern der Schicht (N) als Dienst angeboten. Nachdem die Verbindung24 eingerichtet ist, können die Benutzer der Schicht (N) Daten über diese Verbindung24 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 Verbindungsendpunkt (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 (
1 ) auf der Basis des CAN-Protokolls angeboten. - 2) Data Link-Verbindungen werden an der Schnittstelle S2 (
1 ) auf der Basis einer oder mehrerer CAN-Verbindungen angeboten. - 3) Transport-Verbindungen werden an der Schnittstelle S3 (
1 ) auf der Basis einer oder mehrerer CAN-Verbindungen angeboten. -
3a zeigt ein Beispiel für die Realisierung einer CAN-Verbindung. Der Aufbau eines Sendeobjektes36 ,37 und eines Empfangsobjektes35 ,38 ist in3b dargestellt. Jedes Sende- und Empfangsobjekt besitzt ein Kopffeld39 und ein Datenfeld40 . Das Kopffeld40 wird im folgenden als IDENTIFIER bezeichnet. Das letzte Bitfeld41 des IDENTIFIER ist in3b gesondert dargestellt. Ein stationsübergreifendes Sende-/Empfangsobjekt-Paar36 ,38 bzw.37 ,35 mit gleichem IDENTIFIER39 . aber unterschiedlicher Belegung des RECEIVE/TRANSMIT-Bits (LOW für das Sendeobjekt und HIGH für das Empfangsobjekt) definiert dabei einen Kanal32 bzw.31 , über den Daten in eine Richtung übertragen werden können. Die Werte der beiden IDENTIFIER39 , die eine Verbindung kennzeichnen sind prinzipiell beliebig. Zweckmäßig ist die Wahl von IDENTIFIER39 , die bis auf das Bit im letzten Bit-Feld41 den gleichen Wert haben. Das letzte Bit legt dann die Datenrichtung aus der Sicht einer Station33 ,34 fest. Die Verbindung selbst und ihre Priorität läßt sich dadurch auf einfache Weise durch die ersten n – 1 Bits des IDENTIFIER39 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 Netzprojektierung 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.
-
4a zeigt schematisch die Abbildung von der Verbindung46 in der höheren Schicht 2 auf die Verbindung49 in der niederen Schicht 1 mit Hilfe einer Protokollinstanz52 in der Schicht 2. In gleicher Weise wird die Verbindung47 in der Schicht 2 auf die Verbindung50 in der Schicht 1 und die Verbindung48 auf die Verbindung51 durch die Protokoll-Instanz52 abgebildet. - Für die Protokoll-Instanz
52 der Schicht 2 kommen hier z. B. eine Data Link- bzw. Transport-Protokollinstanz in Frage. Die Verbindungen49 ,50 und51 stellen dann drei CAN-Verbindungen, die in der Schicht 1 mit Hilfe einer CAN-Protokollinstanz betrieben werden, dar. -
4b zeigt hingegegen die Abbildung der drei Verbindungen46 ,47 und48 der Schicht 7 auf lediglich eine CAN-Verbindung49 in der Schicht 1. Dies entspricht einem Multiplex-Mode der Protokollinstanz52 . -
4c zeigt die Abbildung der Verbindung46 der Schicht 2 auf die drei Verbindungen49 ,50 und51 in der Schicht 1. Dies entspricht einem "Splitting"-Mode der Protokollinstanz52 . - 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 sogenannte 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. - 1.3 Beschreibung des Data Link-Protokolls
- Das Data Link-Protokoll
18 ermöglicht die verbindungsorientierte, quittierte Übertragung einer einzelnen Datennachricht zwischen zwei Benutzern der Data Link-Layer16 . Daten werden über virtuelle Data 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 selbststä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. - 1.3.1 Dienste (siehe Tabelle 1)
- 1.3.1.1 Protokollinitialisierung
- 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-Protokolls18 werden mit ihren Voreinstellungswerten belegt (siehe Tabelle 2). - 1.3.1.2 Verbindungsaktivierung
- 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.
- 1.3.1.3 Datenübertragung
- Die Dienstelemente für die Datenübertragung sind D_DATA_ACR.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.
- 1.3.1.4 Verbindungsdeaktivierung
- Eine Verbindung wird nach wiederholter, erfolgloser Übertragung vom Diensterbringer deaktiviert. Die Deaktivierung wird dem Dienstbenutzer durch das Dienstelement D_DEACTIVATED.ind angezeigt.
- 1.3.2 Data Link-Nachrichten
- 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
2 ,3a ,4a ,4b und4c 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 Data 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. -
5 zeigt die Datenfelder57 der Botschaften, die die einzelnen Nachrichten des Data Link-Protokolls übertragen. Das Datenfeld57 enthält bei den Nachrichten AR, AC, DT und AK ein Kontrollinformationsfeld54 und bei der Datennachricht DT zusätzlich ein Feld59 zur Aufnahme der Daten, die mit dieser Nachricht DT übertragen werden. Das Feld59 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 Datenfeld57 einer CAN-Botschaft lokalisiert. -
6 zeigt die Einteilung der Kontrollinformationsfelder58 für die Botschaften zur Übertragung der verschiedenen Nachrichentypen. Für die Unterscheidung der vier Nachrichtentypen ist innerhalb des Kontrollinformationsfeldes58 ein Feld63 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 Kontrollinformationsfelder58 der Botschaften zur Übertragung der Nachrichtentypen DT und AK enthalten darüber hinaus ein Feld64 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 Feld64 zur Aufnahme der Sequenznummer SN umfaßt mindestens 1 Bit. Das Kontrollinformationsfeld58 der Botschaften zur Übertragung der Quittungsnachrichten AK enthält darüber hinaus noch ein Empfängerstatusfeld65 . In dem Empfängerstatusfeld65 wird eine Information RS über den Status des Empfängers abgelegt. Diese Information kann zur stationsübergreifenden Flußkontrolle verwendet werden. Das Empfängerstatusfeld65 umfaßt mindestens ein Bit zur Kennzeichnung, ob der Empfänger empfangsbereit ist oder nicht. - 1.3.3 Variablen und Parameter
- Das Protokoll verwendet folgende Variablen und Parameter (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, DEACTIVATED, 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.
- 1.3.4 Zustandsgraphen und Automatentabellen
- 1.3.4.1 Zustandsgraph der Data Link-Sendeprotokollinstanz
-
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
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-Empfangsproto-
kollinstanz 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 IDLE eingenommen (Übergangspfeil
72 ), in dem die Data Link-Sendeprotokollinstanz Aufträge zur quittierten Übertragung von Daten 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 (Übergangspfeil85 von8 ). 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 (Übergangspfeil74 ). Nach MNT unqittierten Ü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 (Übergangspfeil75 ). - 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 eine Bestätigungsnachricht AC (Aktion SEND (AC)) gesendet; die Verbindungsaktivierung wird dem Benutzer angezeigt (Aktion D_ACTIVATE_IND()) (Übergangspfeil77 ). - 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 (Übergangspfeil83 ). Quittungen mit falscher Sequenznummer (Ereignis RECEIVE_AK (SN = V(S), RS = RR) werden im Zustand WAIT_AK ignoriert (Übergangspfeil79 ). Wenn eine Quittungsnachricht AK eintrifft, die anzeigt, daß die Empfangsprotollinstanz nicht empfangsbereit ist (Ereignis RECEIVE_AK (SN = V(S), RS = RNR)), wird die Sendewiederholung der vorhergehenden Datennachricht DT verzögert (Übergangspfeil80 ). Wenn im Zustand WAIT_AK eine Nachricht AR zur Verbindungsaktivierung eintrifft Ereignis (RECEIVE_AR), werden den Protokollvariablen ihre Voreinstellungswerte zugewiesen, eine Bestätigungsnachricht AK gesendet (Aktion SEND (AC)) und der Folgezustand IDLE eingenommen (Übergangspfeil81 ). Die laufende Datenübertragung wird dabei abgebrochen; die erfolglose Datenübertragung und die Verbindungsaktivierung werden dem Benutzer angezeigt. - 1.3.4.2 Automatentabelle der Data Link-Sendenprotokollinstanz
- Tabelle 3 zeigt die Automatentabelle der Data Link-Sendeprotokollinstanz. Die Spalte ÜGPN enthält die Übergangspfeilnummern für die
7 . - Zustände: (Beschreibung siehe 1.3.4.1)
- 1) INACTIVE
- 2) START_UP
- 3) IDLE
- 4) WAIT_AK
- Ereignisse:
-
- 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.
- Aktionen/Funktionen:
-
- 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 Verbingungsaktivierungsdienstes.
- 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.
- 1.3.4.3 Zustandsgraph der Data Link-Empfangsprotokollinstanz
-
8 zeigt den Zustandsgraphen der Data Link-Empfangsprotokollinstanz. Für die8 gilt der gleiche Formalaufbau wie in7 . 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 (Übergangspfeil84 ). - 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 Übergangspfeil73 von7 ). 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 (Übergangspfeil74 ). 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 (Übergangspfeil75 ). - 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 (Übergangspfeil87 ). 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 (Übergangspfeil88 ). 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 SEND (AC)); die Verbindungsaktivierung wird dem Benutzer angezeigt (Aktion D_ACTIVATE_IND ()) (Übergangspfeil89 ). - 1.3.4.4 Automatentabelle der Data Link-Empfangsprotokollinstanz
- Tabelle 4 zeigt die Automatentabelle der Data Link-Empfangsprotokollinstanz. Die Spalte ÜGPN enthält die Übergangspfeilnummern für die
8 . - Zustände: (Beschreibung siehe 1.3.4.3)
- 1) INACTIVE
- 2) START_UP
- 3) READY
- Ereignisse:
-
- 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 = (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.
- Aktionen/Funktionen:
-
- 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.
- 1.4 Beschreibung des Transport-Protokolls
- 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 Transportlayer15 des Senders in Segmente zerlegt, separat übertragen und in der Transportlayer15 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. - 1.4.1 Dienste (siehe Tab. 5)
- 1.4.1.1 Protokollinitialisierung
- 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).
- 1.4.1.2 Verbindungsaktivierung
- 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 gibt, 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.
- 1.4.1.3 Datenübertragung
- Die Dienstelemente für die Datenübertragung sind T_DATA.req, T_DATA.ind und T_DATA.con. Mit T_DATA.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 T_DATA.ind angezeigt. Das Ergebnis der Übertragung wird dem Auftraggeber durch das Dienstelement T_DATA.con mitgeteilt.
- 1.4.1.4 Verbindungsdeaktivierung
- Eine Verbindung wird nach wiederholter, erfolgloser Übertragung vom Diensterbringer deaktiviert. Die Deaktivierung wird dem Dienstbenutzer durch das Dienstelement T_DEACTIVATED.ind angezeigt.
- 1.4.2 Transport-Nachrichten
- Für die Tansport-Nachrichten, die zwischen Transport-Protokollinstanzen 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
9 und10 erläutert. Das Transport-Protokoll unterscheidet ebenfalls vier Nachrichtentypen AR, AC, DT und AK:AR (ACTIVATION REQUEST): Aktivierungsnachricht zur Aktivierung einer Transport-Verbindung AC (ACITIVATION 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 einer Transport-Nachricht über eine Transport-Verbindung. -
9 zeigt die Datenfelder94 der Botschaften, die die einzelnen Nachrichten des Transport-Protokolls übertragen. Das Datenfeld94 enthält bei den Nachrichten AR, AC, DT und AK ein Kontrollinformationsfeld95 und bei der Datennachricht DT zusätzlich die Felder96 ,97 und98 zur Aufnahme der einzelnen Datenbytes, die mit dieser Nachricht DT übertragen werden. Es können hierbei maximal 7 Datenbytes sich an das Kontrollinformationsfeld95 anschließen. Der Nachrichtentyp 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 Datenfeld95 einer CAN-Botschaft lokalisiert. -
10 zeigt die Einteilung der Kontrollinformationsfelder95 für die Botschaften zur Übertragung der verschiedenen Nachrichtentypen. Für die Unterscheidung der 4 Nachrichtentypen ist innerhalb des Kontrollinformationsfeldes95 ein Feld101 zur Aufnahme eines Nachrichtencodes vorgesehen. Die Kontrollinformationsfelder95 der Botschaften zur Übertragung der Nachrichtentypen DT und AK enthalten darüber hinaus ein Feld102 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 Feld102 zur Aufnahme der Sequenznummer SN umfaßt hier ebenfalls mindestens ein Bit. Zusätzlich umfaßt das Kontrollinformationsfeld95 einer Botschaft, die eine Datennachricht überträgt, ein Feld103 zur Aufnahme eines Nachrichtenendecodes EOM. Das Feld103 umfaßt mindestens ein Bit. Die Information, die in diesem Feld über- tragen wird, gibt an, ob weitere Datensegmente folgen (EOM 0) oder nicht (EOM = 1). Weiterhin umfaßt das Kontrollinformationsfeld95 einer Botschaft die eine Datennachricht DT überträgt ein Feld104 zur Aufnahme einer Information NB, die angibt, wieviele Daten mit dieser Botschaft übertragen werden. - Das Feld
104 umfaßt mindestens 3 Bit. In dem Feld105 einer Botschaft, die eine Quittungsnachricht AK überträgt, wird ebenfalls eine Information über den Status des Empfängers abgelegt. Das Empfängerstatusfeld105 umfaßt mindestens 1 Bit zur Kennzeichnung, ob der Empfänger empfangsbereit ist oder nicht, wie in6 . -
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 Feld130 dargestellt. Speziell dargestellt sind die Datenbytefelder131 ,132 ,133 und134 für die Datenbytes 1, 2, 3 und 15. Zur Verdeutlichung der Abwicklung der Datenübertragung sind einige unterschiedliche Funktionsschichten innerhalb der Station dargestellt. Die Schicht140 ist die Anwendungsschicht innerhalb der ersten Station, in der die Anwendungsprogramme abgearbeitet werden. Die Schicht143 ist die Anwendungsschicht innerhalb der zweiten Station. Die Schicht141 ist die Transportschicht der ersten Station, in der das Transportprotokoll19 Aufträge von der Anwendungsschicht entgegennimmt und abwickelt. Die Schicht144 ist die Transportschicht der zweiten Station. Zwischen den beiden Transportschichten141 und144 ist die virtuelle Transport-Verbindung mit Hilfe der gestrichelten Linien146 und147 dargestellt. Das Transport-Protokoll19 in der Schicht141 macht zur Abwicklung einer Transportnachrichtenübertragung seitens der zugehörigen Station von dem in der Schicht142 befindlichen CAN-Protokoll17 Gebrauch. Die Schicht145 enthält das CAN-Protokoll17 der zweiten Station. Das CAN-Protokoll17 macht seinerseits zur Datenübertragung von der CAN-Busverbindung148 zwischen den Stationen Gebrauch. Die Datenübertragung der 15 Datenbytes, in dem Feld130 geschieht mit Hilfe des Transport-Protokolls19 in 3 Schritten. Im ersten Schritt werden die Datenbytes 1–7 übertragen. Dazu bildet die Transport-Protokollinstanz die Datennachricht DT1. Diese wird dann von der CAN-Protokollinstanz mit Hilfe einer CAN-Botschaft übertragen. Der Aufbau des Datenfeldes139 der Botschaft zur Übertragung der Datennachricht DT1 ist in11 dargestellt. In dem Kontrollinformationsfeld135 der Botschaft ist der Nachrichtencode DT, die Sequenz Nummer 0, der Nachrichtendecode 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 Datenbytefelder136 ,137 und138 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 Kontrollinformationsfeld135 . 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 eingeteilt. Die Datenbytefelder136 ,137 und138 enthalten die Datenbytes 8, 9 und 14. In dem Kontrollinformationsfeld135 sind der Nachrichtencode DT, die Sequenznummer 1, der Nachrichtenendecode 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 Kontrollinformationsfeld135 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 Kontrollinformationsfeld135 eingetragen ist. - Im dritten 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 Datenbytefeld136 enthält das 15. Datenbyte und die weiteren Datenbytefelder, die beispielhaft als 137 und 138 dargestellt sind, enthalten keine relevante Information. In dem Kontrollinformationsfeld135 sind der Nachrichtencode DT, die Sequenznummer 0, der Nachrichtenendecode 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 Kontrollinformationsfeld135 der Botschaft, die die Quittungsnachricht AK3 überträgt, ist genau wie im Schritt1 belegt. Als Resultat sind alle 15 Datenbytes zur zweiten Station übertragen worden und die Anwendungsschicht143 der zweiten Station kann diese weiterverarbeiten. - 1.4.3 Variablen und Parameter
- 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) Verbindungsstatusvariable 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 Sendewiederholungen von 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-Variable 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-l 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. RS 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 Verbindungsaktivierungsnachricht AR.
- 12) Protokollparameter NSEG_MAX Maximale Anzahl von Datensegmenten.
- 13) Protokollparameter TA TA ist die Zeiteinheit, in der eine Quittungsnachricht AK bzw. eine Bestätigungsnachricht AC erwartet wird.
- 1.4.4. Zustandsgraphen und Automatentabellen
- 1.4.4.1 Zustandsgraph der Transport-Sendeprotokollinstanz
-
12 zeigt den Zustandsgraphen der Transport-Empfangsprotokollinstanz. Auch für12 gilt der gleiche formale Aufbau wie in den7 und8 . 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-Protokollinstanz 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 Verbindungsaktivierungsauftrags) die Aktivierungsnachricht AR zur Verbindungsaktivierung eintrifft (Ereignis RECEIVE_AR), wird eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und der Folgezustand IDLE eingenommen, in dem die Transport-Sendeprotokollinstanz Aufträge zur quittierten Übertragung von Daten entgegennimmt (Übergangspfeil112 ). - 2) START_UP
Im Zustand START_UP wartet die Transport-Sendeprotokollinstanz
auf die Bestätigungsnachricht
AC (Bestätigung
der Verbindungsaktivierung) der angesprochenen Transport-Empfangsprotokollinstanz.
Nach
Eingang der Bestätigungsnachricht
AC oder nach Eingang der Aktivierungsnachricht AR (Verbindungsaktivierungswunsch
der Transport-Empfangsprotokollinstanz) wechselt die Transport-Sendeprotokollinstanz
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 Übergangspfeil123 von12 ). 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 (Übergangspfeil74 ). 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 (Übergangspfeil114 ). - 3) IDLE
Im Zustand IDLE wartet die Transport-Sendeprotokollinstanz
auf einen Auftrag zur Übertragung
von Daten. Nach Auftreten des entsprechenden Ereignisses T_DATA_REQ
wird die Anzahl NSEG der Datensegmente berechnet und die Datennachricht
DT mit der Kontrollinformation und dem ersten Datensegment gebildet, gesendet
(Aktion SEND (DT)) und der Folgezustand WAIT_AK eingenommen (Übergangspfeil
115 ). Wenn im Zustand IDLE eine Aktivierungsnachricht AR zur Verbindungaktivierung 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()) (Übergangspfeil116 ). - 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 (SN < > V(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 (Übergangspfeil119 ). 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 (Übergangspfeil82 ). 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 (Übergangspfeil83 ). Quittungen mit falscher Sequenznummer (Ereignis RECEIVE_AK (SN = V(S)) werden im Zustand WAIT_AK ignoriert (Übergangspfeil79 ,80 ). Wenn eine Quittungsnachricht AK eintrifft, die anzeigt, daß die Emfpangsinstanz nicht empfangsbereit ist (Ereignis RECEIVE_AK (SN = VC/S), RS = RNR), wird die Sendewiederholung der vorhergehenden Datennachricht DT verzögert (Übergangspfeil80 ). Wenn im Zustand WAIT_AK eine Datennachricht AR zur Verbindungsaktivierung eintrifft (RECEIVE_AR), werden den Protokollvariablen ihre Voreinstellungswerte zugewiesen, eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und der Folgezustand IDLE eingenommen (Übergangspfeil120 ). Die laufende Datenübertragung wird dabei abgebrochen; die erfolglose Datenübertragung und Verbindungsaktivierung werden dem Benutzer angezeigt. - 1.4.4.2 Automatentabelle der Transport-Sendeprotokollinstanz
- Tabelle 7 zeigt die Automatentabelle der Transport-Sendeprotokollinstanz. Die Spalte ÜGPN enthält die Übergangspfeilnummern der
12 . - Zustände: (Beschreibung siehe 1.4.4.1)
- 1) INACTIVE
- 2) START_UP
- 3) IDLE
- 4) WAIT_AK
- Ereignisse:
-
- 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 Quittung 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 (SN < > V(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 (SN < > V(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 (SN < > V(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.
- Aktionen/Funktionen
-
- 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übertragung.
- 12) IF (RS(AK) = RR) (SEND (DT)) Die Nachricht DT mit dem nächsten Datensegment wird gesendet, wenn die Transport-Empfangsprotokollinstanz in der letzten Quittungsnachricht ihre Empfangsbereitschaft angezeigt hat. Andernfalls 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 Sendefolgevariablen V(S) zugewiesen. Die Werte 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 Verbindungaktivierungsdienstes.
- 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.
- 1.4.4.3 Zustandsgraph der Transport-Empfangsprotokollinstanz
-
13 zeigt den Zustandsgraphen der Transport-Empfangsprotokollinstanz. Auch hier gilt der gleiche formale Aufbau wie in den7 ,8 und12 . Die Transport-Empfangsprotokollinstanz hat folgende Zustände: - 1) INACTIVE
Im Zustand INACTIVE befindet
sich die Transport-Empfangsprotokollinstanz nach der Initialisierung.
In diesem Zustand wartet die Protokollinstanz auf den Auftrag zur
Aktivierung der Verbindung (Ereignis T_ACTIVATE_REQ) bzw. auf den
Eingang einer Verbindungsaktivierungsnachricht AR der Partnerprotokollinstanz.
Wenn das Ereignis T_ACTIVATE_REQ auftritt, wird die Aktivierungsnachricht
AR an die Transport-Sendeprotokollinstanz gesendet (Aktion SEND
(AR)) und der Folgezustand START_UP eingenommen (Übergangspfeil
121 ). 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 Transport-Empfangsprotokollinstanz bereit ist, Daten zu empfangen (Übergangspfeil122 ). - 2) START_UP
Im Zustand START_UP wartet die Transport-Empfangsprotokollinstanz
auf die Bestätigungsnachricht
AC (Bestätigung
der Verbindungsaktivierung) der angesprochenen Sendeprotokollinstanz.
Nach Eingang der Bestätigungsnachricht
AC oder nach Eingang der Aktivierungsnachricht AR (Verbindungsaktivierungswunsch
der Transport-Sendeprotokollinstanz) wechselt die Transport-Empfangsprotokollinstanz
in den Zustand READY, in dem sie bereit ist, Daten zu empfangen (Übergangspfeil
123 ). Die entsprechende Transport-Sendeprotokollinstanz geht quasi gleichzeitig in den Zustand IDLE (siehe Übergangspfeil113 ,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 (Übergangspfeil74 ). Nach MNT unquittierten Übertragungen der Aktivierungsnachricht AR (Ereignis TA_EXPIRED and (RC = MNT)), geht die Transport-Empfangsprotokollinstanz wieder in den Zustand INACTIVE und zeigt die erfolglose Verbindungsaktivierung dem Benutzer an (Übergangspfeil124 ). - 3) READY
Im Zustand READY wartet die Transport-Empfangsprotokollinstanz
auf den Eingang einer Datennachricht DT. Nach Empfang einer entsprechenden
Nachricht mit der erwarteten Sequenznummer (Ereignis RECEIVE_DT
(SN = V(R)) wird die Nachricht abgespeichert und eine Quittungsnachricht
AK gesendet (Aktion SEND (AK)). Falls die Nachricht das letzte 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 Empfangsstatus "Empfänger nicht bereit" mitgeteilt (Übergangspfeil87 ). 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 (Übergangspfeil88 ). Wenn im Zustand READY eine Aktivierungsnachricht AR zur Verbindungsaktivierung eintrifft (Ereignis RECEIVE_AR), werden den Protokollvariablen ihre Voreinstellungswerte zugewiesen, eine Bestätigungsnachricht AC gesendet (Aktion SEND (AC)) und die Aktivierung dem Benutzer mitgeteilt (Übergangspfeil127 ). - 1.4.4.4 Automatentabelle der Transport-Empfangsprotokollinstanz
- Tabelle 8 zeigt die Automatentabelle der Transport-Empfangsprotokollinstanz. Die Spalte ÜGPN enthält die Übergangspfeilnummern der
13 . - Zustände: (Beschreibung siehe 1.4.4.3)
- 1) INACTIVE
- 2) START_UP
- 3) READY
- Ereignisse:
-
- 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ä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-Empfangsprotokollinstanz 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.
- Aktionen/Funktionen:
-
- 1) SEND (AR) Senden einer Nachricht AR zur Verbindungsaktivierung.
- 2) SEND (AC) 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 Verbindungsstatusvariablen V(C) zugewiesen.
- 15) RESET_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 Verbindungsstatusvariablen 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äne DATA_LENGTH und die Daten DATA übergeben.
- 1.4.4.5 Sliding Window-Technik
- 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 (23)
- 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, dass Verbindungen (
24 ) zwischen mindestens zwei Stationen (33 ,34 ) über den Bus eingerichtet, aktiviert und deaktiviert werden, über die Nachrichten auszutauschen sind und, dass 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, wobei 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. - Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei Aktivierung einer Verbindung (
24 ) eine Aktivierungsnachricht (AR) von einer der Stationen (33 ,34 ) ausgegeben wird, die von mindestens einer anderen empfangenden Station (33 ,34 ) durch eine Bestätigungsnachricht (AC) quittiert wird und dass die Aktivierung der Nachrichten-Verbindung (24 ) den Benutzern mitgeteilt wird. - Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei Deaktivierung einer Verbindung (
24 ) ein Verbindungsstatusspeicher in den jeweiligen Stationen (33 ,34 ) der Nachrichten-Verbindung (24 ) auf einen bestimmten Wert gesetzt wird. - Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für den Nachrichtencode mindestens ein Bit verwendet wird.
- Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass 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. - Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass 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. - Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass für die Sequenznummer (SN) mindestens ein Bit verwendet wird.
- Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass in dem Kontrollinformationsfeld (
58 ,95 ) einer die Quittungsnachricht (AK) übertragenden Botschaft ein Empfängerstatusfeld (65 ,105 ) vorgesehen wird. - Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass für das Empfängerstatusfeld (
65 ,105 ) mindestens ein Bit verwendet wird. - Verfahren nach einem der vorhergehenden Ansprüche 2 bis 9, dadurch gekennzeichnet, dass sich das Kopffeld (
39 ) der die Quittungsnachricht (AK) übertragenden Botschaft in mindestens einem signifikanten Bit von dem Kopffeld (39 ) der die Datennachricht (DT) übertragenden Botschaft unterscheidet. - Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass das mindestens eine signifikante Bit an letzter Stelle (
41 ) des Kopffeldes (39 ) positioniert wird. - Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine vollständige Nachricht mit einer einzelnen Botschaft übertragen wird oder nach Segmentierung mit mehreren Botschaften übertragen wird.
- Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Botschaften, die ein Nachrichtensegment übertragen, in den Kontrollinformationsfeldern (
95 ) der Botschaften gekennzeichnet werden. - Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Botschaft, die das letzte Nachrichtensegment überträgt, in einem Feld (
103 ) des Kontrollinformationsfeldes (95 ) als solche gekennzeichnet wird. - Verfahren nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass das Kontrollinformationsfeld (
95 ) der Botschaft eine Angabe über die Länge des folgenden Datenfeldes der Botschaft eingegeben wird. - Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Angabe über die Länge des dem Kontrollinformationsfeld (
95 ) folgenden Datenfeldes nur in einem Feld (104 ) des Kontrollinformationsfeldes (95 ) der das letzte Nachrichtensegment übertragenden Botschaft eingegeben wird. - Verfahren nach einem der Ansprüche 5 bis 16, dadurch gekennzeichnet, dass beim Ausbleiben der Quittungsnachricht (AK) die Datennachricht (DT) nach einer vorbestimmten Wartezeit erneut gesendet wird.
- Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass beim wiederholten Ausbleiben der Quittungsnachricht (AK) die Datennachricht (DT) nur so oft wiederholt wird, bis eine bestimmte Anzahl von Sendewiederholungen erreicht ist.
- Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass bei Überschreitung der bestimmten Anzahl von Sendewiederholungen die Verbindung (
24 ) deaktiviert wird und die Deaktivierung den Benutzern der Verbindung (24 ) mitgeteilt wird. - Vorrichtung zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 19, 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 Schnittstellen-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 Schnittstellen-Baustein und Rechner einer jeden Station (33 ,34 ), wobei die Schnittstellen-Bausteine Mittel zum seriellen Datenaustausch über die Busverbindung erhalten, dadurch gekennzeichnet, dass in den Stationen (33 ,34 ) jeweils Mittel zur Einrichtung, Aktivierung und Deaktivierung von Verbindungen (24 ) zwischen den Stationen (33 ,34 ) über den Bus vorhanden sind, dass zum quittierten Austausch von Daten über aktivierte Verbindungen (24 ) eine Station (33 ,34 ) der Verbindung (24 ) sendet, dass die weiteren Stationen (33 ,34 ) diese Datennachricht (DT) durch Rücksendung einer Quittungsnachricht (AK) quittieren und dass die Schnittstellen-Bausteine, die die Datennachrichten (DT) empfangen, dem angeschlossenen Rechner den Empfang der Datennachricht (DT) mitteilen so dass der Schnittstellen-Baustein, der die Quittungsnachrichten (AK) empfängt, den Empfang der Quittungsnachricht (AK) dem angeschlossenen Rechner mitteilt. - Vorrichtung nach Ansprüch 20, dadurch gekennzeichnet, dass 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. - Vorrichtung nach Anspruch 20 oder 21, dadurch gekennzeichnet, dass 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, dass die weiteren Stationen (33 ,34 ) das Datennachrichtensegment durch Rücksendung einer Quittungsnachricht (AK) bestätigen, dass der Schnittstellen- Baustein, der das Datennachrichtensegment empfängt, dem angeschlossenen Rechner den Empfang des Datennachrichtensegmentes mittel und, dass der Schnittstellen-Baustein, der die Quittungsnachrichten empfängt, dem Empfang der Quittungsnachrichten (AK) dem angeschlossenen Rechner mitteilt. - Vorrichtung nach einem der Ansprüche 20 bis 22, dadurch gekennzeichnet, dass in den Schnittstellen-Bausteinen zur fortlaufenden Nummerierung von Datennachrichtensegmenten ein Sendefolgezähler vorhanden ist, dass zur Speicherung der Sequenznummer (SN) der nächsten zum Empfang erwarteten Nachricht oder des nächsten zum Empfang erwarteten Datennachrichtensegmentes ein Empfangsfolgezähler vorhanden ist, d zur Speicherung des Status einer Verbindung (
24 ) ein Verbindungsstatusspeicher vorhanden ist, dass zur Speicherung der aktuellen Anzahl der Sendewiederholungen ein Sendewiederholungszähler vorhanden ist, dass 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, dass die vorbestimmte Wartezeit, sowie die maximale Anzahl der Botschaftswiederholungen in einem Speicher abzulegen ist, dass zur Kennzeichnung der Anzahl der Datensegmente ein Datensegmentspeicher vorhanden ist, dass zur Kennzeichnung der Gesamtlän der Datenbytes einer Nachricht oder eines Datennachrichtensegmentes 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 DE4131133A1 (de) | 1993-04-01 |
DE4131133B4 true 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) |
Families Citing this family (150)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE4229175A1 (de) * | 1992-09-02 | 1994-03-03 | Bosch Gmbh Robert | Netzwerkschnittstelle |
US5590181A (en) * | 1993-10-15 | 1996-12-31 | Link Usa Corporation | Call-processing system and method |
US6643362B2 (en) * | 1998-11-19 | 2003-11-04 | Global Crossing, Ltd. | 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 |
US6467039B1 (en) * | 1996-02-22 | 2002-10-15 | Kvaser Consultant Ab | Device in a system operating with can-protocol and in a control and/or supervision 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 |
DE19637312A1 (de) | 1996-09-12 | 1998-03-19 | Bosch Gmbh Robert | Verfahren zur Kontrolle der Verbindungen eines Übertragungssystems und Komponente zur Durchführung des Verfahrens |
DE19640346C2 (de) * | 1996-09-20 | 1999-03-04 | Tektronix Inc | Verfahren zum Überprüfen eines gemäß einem Kommunikationsprotokoll durchgeführten Datenaustausches |
US5752931A (en) * | 1996-09-30 | 1998-05-19 | Minnesota Mining And Manufacturing Company | Perfusion system with perfusion circuit display |
US6164920A (en) * | 1996-09-30 | 2000-12-26 | Minnesota Mining And Manufacturing Company | Perfusion system with control network |
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 |
WO1998042108A1 (en) * | 1997-03-20 | 1998-09-24 | 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 |
US6035324A (en) * | 1997-08-28 | 2000-03-07 | International Business Machines Corporation | Client-side asynchronous form management |
US6070184A (en) * | 1997-08-28 | 2000-05-30 | International Business Machines Corporation | Server-side asynchronous form management |
DE19754640A1 (de) | 1997-12-09 | 1999-06-10 | Bosch Gmbh Robert | Verfahren zur Koordination von Netzwerkkomponenten |
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 |
JP2001016234A (ja) | 1999-06-29 | 2001-01-19 | Mitsubishi Electric Corp | Canコントローラおよびcanコントローラを内蔵したワンチップ・コンピュータ |
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 |
US6757597B2 (en) | 2001-01-31 | 2004-06-29 | Oshkosh Truck | A/C bus assembly for electronic traction vehicle |
FI19992470A (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 |
US6735620B1 (en) | 2000-07-18 | 2004-05-11 | International Business Machines Corporation | Efficient protocol for retransmit logic in reliable zero copy message transport |
US6799200B1 (en) | 2000-07-18 | 2004-09-28 | International Business Machines Corporaiton | Mechanisms for efficient message passing with copy avoidance in a distributed system |
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 |
US7379797B2 (en) * | 2001-01-31 | 2008-05-27 | Oshkosh Truck Corporation | System and method for braking in an electric vehicle |
US7277782B2 (en) | 2001-01-31 | 2007-10-02 | Oshkosh Truck Corporation | Control system and method for 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 |
US7562146B2 (en) | 2003-10-10 | 2009-07-14 | Citrix Systems, Inc. | Encapsulating protocol for session persistence and reliability |
US20050198379A1 (en) | 2001-06-13 | 2005-09-08 | Citrix Systems, Inc. | Automatically reconnecting a client across reliable and persistent communication sessions |
US7180879B2 (en) * | 2001-08-17 | 2007-02-20 | Ragulan Sinnarajah | Method and apparatus for call setup latency reduction |
DE50115035D1 (de) * | 2001-10-31 | 2009-09-24 | Infineon Technologies Ag | Bus-Interface |
US7302320B2 (en) | 2001-12-21 | 2007-11-27 | Oshkosh Truck Corporation | Failure mode operation for an electric vehicle |
US7254468B2 (en) | 2001-12-21 | 2007-08-07 | Oshkosh Truck Corporation | Multi-network control system for a 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 |
AU2005255517B2 (en) * | 2004-06-21 | 2009-10-08 | Blackberry Limited | System and method for handling message receipt notification |
KR100869540B1 (ko) * | 2004-08-06 | 2008-11-19 | 샤프 가부시키가이샤 | 송신기, 수신기, 통신시스템, 통신방법, 통신프로그램을 기록한 컴퓨터 독취가능한 기록매체 |
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 |
US20060078125A1 (en) * | 2004-10-08 | 2006-04-13 | Philip Cacayorin | Devices and methods for implementing cryptographic scrambling |
JP4198741B2 (ja) * | 2005-01-28 | 2008-12-17 | シャープ株式会社 | 通信機器、通信システム、通信方法、通信プログラム、通信回路 |
US7787391B2 (en) * | 2005-01-28 | 2010-08-31 | Sharp Kabushiki Kaisha | Communication device, communication system, communication method, communication program, and communication circuit |
US8051182B2 (en) * | 2005-01-28 | 2011-11-01 | 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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
US8255086B2 (en) | 2008-10-27 | 2012-08-28 | Lennox Industries Inc. | System recovery in a 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 |
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 |
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 |
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 |
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 |
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 |
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 |
US8798796B2 (en) | 2008-10-27 | 2014-08-05 | Lennox Industries Inc. | General control techniques 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 |
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 |
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 |
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 |
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 |
US8437877B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | System recovery in 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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
US8295981B2 (en) | 2008-10-27 | 2012-10-23 | Lennox Industries Inc. | Device commissioning in a 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 |
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 |
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 |
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 |
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 |
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 |
US8600558B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US10085657B2 (en) | 2009-06-17 | 2018-10-02 | 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 |
ES2820457T3 (es) | 2010-04-12 | 2021-04-21 | Qualcomm Inc | Acuses de recibo retardados para comunicación de baja sobrecarga en una red |
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 |
KR101921357B1 (ko) * | 2011-04-06 | 2018-11-22 | 로베르트 보쉬 게엠베하 | 직렬 버스 시스템에서 데이터 전송 용량을 증대하기 위한 방법 및 장치 |
BR112013025903B1 (pt) | 2011-04-06 | 2021-06-08 | Robert Bosch Gmbh | processo e dispositivo para transmissão de dados serial em um sistema de barramento |
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 |
US9690742B2 (en) | 2011-06-29 | 2017-06-27 | Robert Bosch Gmbh | Method and device for serial data transmission having a flexible message size and a variable bit length |
DE102012223352A1 (de) * | 2012-12-17 | 2014-06-18 | Siemens Aktiengesellschaft | Verfahren zum Betreiben eines Gebäudeinstallationssystems |
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 |
US10982736B2 (en) | 2015-02-17 | 2021-04-20 | Oshkosh Corporation | Multi-mode electromechanical variable transmission |
US9650032B2 (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 |
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 |
US11701959B2 (en) | 2015-02-17 | 2023-07-18 | Oshkosh Corporation | Inline electromechanical variable transmission system |
US9651120B2 (en) | 2015-02-17 | 2017-05-16 | Oshkosh Corporation | Multi-mode electromechanical variable transmission |
US10584775B2 (en) | 2015-02-17 | 2020-03-10 | 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 |
Citations (2)
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 |
US5050166A (en) * | 1987-03-17 | 1991-09-17 | Antonio Cantoni | Transfer of messages in a multiplexed system |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3546664C3 (de) * | 1985-02-22 | 1995-10-26 | Bosch Gmbh Robert | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
DE3719283A1 (de) * | 1987-06-10 | 1988-12-22 | Bosch Gmbh Robert | Verfahren zur lokalisierung defekter stationen in lokalen netzwerken und dazugehoeriger schnittstellencontroller |
EP0412085B1 (de) * | 1989-02-17 | 1994-10-12 | Robert Bosch Gmbh | Netzwerkschnittstelle |
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
Patent Citations (2)
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 |
US5050166A (en) * | 1987-03-17 | 1991-09-17 | Antonio Cantoni | Transfer of messages in a multiplexed system |
Also Published As
Publication number | Publication date |
---|---|
US5448561A (en) | 1995-09-05 |
DE4131133A1 (de) | 1993-04-01 |
JP3461850B2 (ja) | 2003-10-27 |
JPH05235965A (ja) | 1993-09-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE4131133B4 (de) | Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen | |
DE69433098T2 (de) | Vorrichtung zur Übertragung von Daten | |
DE60317837T2 (de) | Verfahren und System zur Messung von Last und Kapazität auf einem Kanal mit variabler Kapazität | |
DE3586430T2 (de) | Lokales netzwerk fuer numerische datenverarbeitungssysteme. | |
DE69015275T2 (de) | Datenkommunikationssystem und Vorrichtung mit einer zyklischen Quittungsantwortensequenz. | |
DE60219999T2 (de) | Taskverwaltungsverfahren für einen Router einer Paketvermittlungsstelle, die Teil eines gesicherten und Paketvermittelten Netzes ist | |
EP1828858B1 (de) | Steuerungssystem mit einer vielzahl von räumlich verteilten stationen sowie verfahren zum übertragen von daten in einem solchen steuerungssystem | |
WO1999035797A1 (de) | Verfahren zum datentransport sowie rechnernetzwerk zur durchführung des verfahrens | |
DE60109959T2 (de) | Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen | |
DE4129205A1 (de) | Verfahren zum aufbau von botschaften fuer den datenaustausch und/oder fuer die synchronisation von prozessen in datenverarbeitungsanlagen | |
DE69021186T2 (de) | "Master-Slave" industrielles Netzwerk mit Tokenübergabe. | |
DE102007011071B4 (de) | Verfahren zur Verbesserung eines TCP Datenübertragungsprozesses im Fall einer Unterbrechung des physikalischen Übertragungsmediums | |
DE69929054T2 (de) | Extensions für datenverarbeitungsschicht in einem drahtlosen mac-protokoll mit hoher latenz | |
DE60316419T2 (de) | Serialisierung von eine Verteiltenapplikation einer Router | |
EP0443003B1 (de) | Kanalzugriffsverfahren für ein als bus-system konfiguriertes lokales übertragungsnetz | |
EP1884851B1 (de) | Verfahren, Knoten und Netzwek zum zyklischen Versenden von Ethernet-Telegrammen | |
DE60036121T2 (de) | Hochgeschwindigkeitsverbindung für eingebettete Systeme in einem Rechnernetzwerk | |
EP1312992B1 (de) | Verfahren zum Tunneln eines höherwertigen Protokolls auf einem Feldbussystem | |
DE102005062575B4 (de) | Verfahren und Vorrichtung zum Übertragen von Daten über eine Datenverbindung von einem Sender zu einem Empfänger mittels Pakete | |
EP1121645A1 (de) | Elektronische steuereinrichtung mit einem parallelen datenbus und verfahren zum betreiben der steuereinrichtung | |
DE10037969C2 (de) | Verfahren zur Erkennung einer flexiblen Vernetzung von Baugruppen bei beliebiger Netztopologie sowie zum Informationsaustausch zwischen solchen Baugruppen | |
EP1527547B1 (de) | Verfahren und vorrichtung zur überwachung einer daten übertragung | |
DE68929401T2 (de) | Transportsystem für ein lokales Netz | |
WO2006076960A1 (de) | Verfahren und vorrichtungen zur datenübertragung | |
DE60225875T2 (de) | Zugangskontrollegateway zu einem Aktiven Netzwerk |
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 |