DE69433866T2 - Verfahren zur Übertragung von Daten - Google Patents

Verfahren zur Übertragung von Daten Download PDF

Info

Publication number
DE69433866T2
DE69433866T2 DE69433866T DE69433866T DE69433866T2 DE 69433866 T2 DE69433866 T2 DE 69433866T2 DE 69433866 T DE69433866 T DE 69433866T DE 69433866 T DE69433866 T DE 69433866T DE 69433866 T2 DE69433866 T2 DE 69433866T2
Authority
DE
Germany
Prior art keywords
data
token
message
transmission
node
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 - Fee Related
Application number
DE69433866T
Other languages
English (en)
Other versions
DE69433866D1 (de
Inventor
Hiroshi Wako-shi Hashimoto
Jun Wako-shi Ishii
Yuji Wako-shi Nagatani
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honda Motor Co Ltd
Original Assignee
Honda Motor Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from JP5048560A external-priority patent/JP2947437B2/ja
Priority claimed from JP5048559A external-priority patent/JP2857655B2/ja
Priority claimed from JP5080216A external-priority patent/JP2784709B2/ja
Priority claimed from JP5084079A external-priority patent/JP2947496B2/ja
Application filed by Honda Motor Co Ltd filed Critical Honda Motor Co Ltd
Application granted granted Critical
Publication of DE69433866D1 publication Critical patent/DE69433866D1/de
Publication of DE69433866T2 publication Critical patent/DE69433866T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0061Error detection codes
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60RVEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/03Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for
    • B60R16/0315Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for using multiplexing techniques
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1657Implicit acknowledgement of correct or incorrect reception, e.g. with a moving window
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1664Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1671Details of the supervisory signal the supervisory signal being transmitted together with control information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1685Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1825Adaptation of specific ARQ protocol parameters according to transmission conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/189Transmission or retransmission of more than one copy of a message
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40006Architecture of a communication node
    • H04L12/40013Details regarding a bus controller
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/413Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/413Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/417Bus networks with decentralised control with deterministic access, e.g. token passing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0094Bus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0098Unequal error protection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mechanical Engineering (AREA)
  • Quality & Reliability (AREA)
  • Small-Scale Networks (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Diese Erfindung betrifft ein Verfahren zur Übertragung von Daten zwischen einer Mehrzahl von an einem Kraftfahrzeug installierten elektronischen Steuereinheiten über eine gemeinsame Kommunikationsleitung, die diese elektronischen Steuereinheiten verbindet.
  • Stand der Technik
  • Üblicherweise wird beim Durchführen der gegenseitigen Datenübertragung zwischen einer Mehrzahl von elektronischen Steuereinheiten (im folgenden als „ECUs" bezeichnet), die an einem Kraftfahrzeug installiert sind, über eine gemeinsame Kommunikationsleitung (im folgenden als "der Netzwerkbus" bezeichnet), die diese ECUs verbindet, ein Token-Verfahren zum Zirkulieren eines Übertragungsrechts durch die ECUs in einer vorbestimmten Sequenz verwendet, um einer ECU, die das Übertragungsrecht erhalten hat, zu gestatten, Daten an den Netzwerkbus zu senden.
  • Wenn ein Datenübertragungssystem, das das Token-Verfahren verwendet, gestartet wird, sind üblicherweise die folgenden Verfahren zum anfänglichen Übergeben (d. h. Generieren) des Übertragungsrechts an eine der ECUs bekannt:
    • (1) Starres ECU-Verfahren zum anfänglichen Übergeben des Übertragungsrechts an eine bestimmte, im voraus festgelegte ECU in einer festgelegten Weise.
    • (2) Warte-Verfahren, bei dem alle ECUs beginnen, Daten zu übertragen, wobei angenommen wird, dass ihnen allen anfänglich das Übertragungsrecht übertragen wurde, sie aufhören, Daten zu übertragen, wenn eine Datenkollision auftritt, und sie die Datenübertragung wieder aufnehmen, nachdem sie vorbestimmte Wartezeitabschnitte, auf die die jeweiligen ECUs jeweils eingestellt wurden, abgewartet haben, wobei sie dieses Verfahren wiederholt ausführen, bis keine Kollision auftritt, um dadurch einen anfänglichen Inhaber des Übertragungsrechts auf eine der ECUs zu beschränken.
  • Das starre ECU-Verfahren leidet jedoch unter einem Problem, dass, wenn die spezielle ECU, an die das Übertragungsrecht anfänglich übertragen werden soll, fehlerhaft arbeitet, das Übertragungsrecht für immer nicht erzeugt werden kann.
  • Auch bei dem Warte-Verfahren gibt es eine Unannehmlichkeit, nämlich dass viel Zeit benötigt wird, um das Übertragungsrecht zu generieren, und dass unnütz Zeit verbraucht wird, bevor die ECUs beginnen, als ein Netzwerk zusammenzuarbeiten.
  • Andererseits ist es in dem Datenübertragungssystem, das das Token-Verfahren verwendet, eine bekannte Technik, einer Nachricht Sendedaten zur Übertragung hinzuzufügen, um das Übertragungsrecht zu der nächsten ECU zu transferieren, wie es z. B. in der japanischen Patentveröffentlichung (Kokoku) Nr. 1-58900 offenbart ist.
  • Das Nachrichtendatenformat ist jedoch bei dieser herkömmlichen Technik nicht so konstruiert, dass eine Sendeseite die sichere und genaue Übertragung sowohl des Übertragungsrechts als auch der Daten bestätigen kann, und es gibt daher Spielraum für eine diesbezügliche Verbesserung, um die Übertragung zu beschleunigen.
  • Des weiteren offenbart die japanische Patentveröffentlichung (Kokoku) Nr. 1-57856 (im folgenden als "der erste Stand der Technik" bezeichnet) eine Technik, dass, wenn eine Datenübertragung nicht erfolgreich durchgeführt wird, eine erneute Übertragung der Daten durchgeführt wird, wenn das Übertragungsrecht, nachdem es entlang der ECUs übertragen worden ist, zu der aktuellen ECU zurückkehrt, wobei die Tatsache berücksichtigt wird, dass, wenn eine erneute Übertragung der Daten sofort durchgeführt wird, die Möglichkeit deren Scheitern hoch ist.
  • Weiterhin offenbart die vorläufige japanische Patentveröffentlichung (Kokai) Nr. 62-159539 ein Datenübertragungssystem (im folgenden als "der zweite Stand der Technik" bezeichnet), in dem, wenn eine Übertragung der Daten nicht erfolgreich ausgeführt wird, die Daten erneut innerhalb der Grenze einer vorbestimmten Anzahl von Malen übertragen werden, wobei diese Anzahl von einem anderen Steuersystem geändert oder festgelegt werden kann.
  • Nach dem ersten Stand der Technik wird die erneute Übertragung der Daten nur durchgeführt, nachdem das Übertragungsrecht einmal entlang der ECUs übertragen worden ist, selbst wenn die sofortige Übertragung der Daten erfolgreich sein könnte (z. B., wenn das Scheitern der Übertragung durch ein Rauschen während der Übertragung verursacht worden ist), was eine zu beseitigende Unannehmlichkeit für eine sofortige Beendigung der Datenübertragung darstellt.
  • Des weiteren wird die erneute Übertragung von Daten nach dem zweiten Stand der Technik unmittelbar nach deren Scheitern innerhalb der von dem anderen Steuersystem festgelegten vorbestimmten Anzahl von Malen durchgeführt. Diese Anzahl wird jedoch nicht von der Sendeseite selbst festgelegt, und es ist daher schwierig, eine sofortige Reaktion auf das Scheitern der Übertragung durchzuführen.
  • Weiterhin wird bei der Durchführung einer Überprüfung, ob eine Verbindung zwischen einem Teilnehmer (ECU) und einem anderen (ECU) des Netzwerks sicher hergestellt ist, eine spezielle Nachricht von dem einen Teilnehmer gesendet, um eine Antwort von dem anderen zu erhalten, aufgrund der ermittelt wird, ob die Verbindung sicher hergestellt ist.
  • Wenn die spezielle Nachricht verwendet wird, können jedoch die Datenübertragung und die Übertragung des Übertragungsrechts nicht ausgeführt werden, während die spezielle Nachricht gesendet wird, was in einer verringerten Übertragungseffizienz resultiert. Weiterhin ist, wenn der andere Teilnehmer (ECU) fehlerhaft oder von dem Netzwerk getrennt wird, der Status der Verbindung nicht sicher, bis die diesbezügliche Überprüfung erneut durchgeführt wird, und folglich besteht die Möglichkeit, dass das Übertragungsrecht weiterhin zu der abgetrennten ECU übertragen wird.
  • H. Eing. et al., „Das lokale SP-Netzwerk", Elektronik Vol. 32, Nr. 11, Seiten 73–78 offenbart den Aufbau eines typischen Datenpakets. An dem Ende hat das Datenpaket eine Endbestätigung zum Bestätigen des Empfangs für den gesamten Datenblock. Die Endbestätigung wird nur ausgegeben, wenn der gesamte Datenblock als fehlerfrei erkannt wird.
  • EP-A-0 216 372 offenbart ein Datenbussystem für Fahrzeuge, wobei eine Mehrzahl von unterschiedlichen Nutzern mittels eines gemeinsamen Datenbus kommunizieren kann. Das System stellt die folgenden Merkmale bereit: a) Die Benutzer sind jeweils mit dem Datenbus über eine Steuerstation verbunden, b) die Steuerstationen haben Register zum Speichern von Daten, die von den angegliederten Nutzern gefordert oder geliefert werden, c) die Stationen sind permanent mit dem Datenbus verbunden, um Daten zu empfangen, die von den angegliederten Nutzern angefordert werden, d) die Stationen sind sequentiell mit dem Datenbus verbunden, um sequentiell Daten zu senden, die von den angegliederten Nutzern geliefert werden, und e) die über den Bus übergebenen Daten tragen ein Identifikationszeichen.
  • Zusammenfassung der Erfindung
  • Es ist eine Aufgabe der Erfindung, ein Verfahren zum Übertragen von Daten bereitzustellen, welches prompte Bestätigungen ermöglicht, ob der Transfer des Übertragungsrechts und die Übertragung von Daten erfolgreich ausgeführt wurden, um dadurch das Übertragungsrecht glatt zu zirkulieren.
  • Um die Aufgabe der Erfindung zu erreichen, wird bereitgestellt ein Datenübertragungsverfahren zum Verbinden einer Mehrzahl von Steuersystemen, die an einem Fahrzeug installiert sind, über mindestens eine gemeinsame Signalleitung und zum Übertragen einer Nachricht zwischen der Mehrzahl von Steuersystemen, während ein Übertragungsrecht durch die Mehrzahl von Steuersystemen zirkuliert.
  • Das Datenübertragungsverfahren gemäß der Erfindung ist dadurch gekennzeichnet, dass die Nachricht ein erstes Antwortfeld zum Empfangen einer ersten Bestätigungsantwort, die von einem Steuersystem, welches das Übertragungsrecht empfangen hat, ausgegeben wird, und ein zweites Antwortfeld zum Empfangen einer zweiten Bestätigungsantwort, die von einem Steuersystem, das Daten empfangen hat, ausgegeben wird, umfasst.
  • Vorzugsweise wird ein Verarbeiten entsprechend der ersten Bestätigungsantwort bevorzugt gegenüber einem Verarbeiten entsprechend der Abwesenheit der zweiten Bestätigungsantwort durchgeführt.
  • Vorzugsweise wartet das Verarbeiten entsprechend der ersten Bestätigungsantwort auf einen Empfang des Übertragungsrechts beim nächsten Mal oder auf die Weiterführung des Transfers des Übertragungsrechts, und das Verarbeiten entsprechend dem Fehlen der zweiten Bestätigungsantwort ist die Neuübertragung der Daten.
  • Vorzugsweise wird die Nachricht in eine erste Nachricht mit einem ersten Antwortfeld zum Empfangen einer ersten Bestätigungsantwort, die von einem Steuersystem, welches das Übertragungsrecht empfangen hat, ausgegeben wird, und in eine zweite Nachricht mit einem zweiten Antwortfeld zum Empfangen einer zweiten Bestätigungsantwort, die von einem Steuersystem, das Daten empfangen hat, ausgegeben wird, klassifiziert; und
    jedes der Mehrzahl von Steuersystemen urteilt, dass ein Transfer des Übertragungsrechts beendet ist, unabhängig, ob die zweite Bestätigungsantwort detektiert wird oder nicht, falls die erste Bestätigungsantwort detektiert wird, wenn die zweite Nachricht von dem Steuersystem, das Daten empfangen hat, ausgesendet wird, und führt keine Übertragung der Nachricht durch, bis das Übertragungsrecht das nächste Mal erhalten wird, wohingegen jedes der Mehrzahl von Steuersystemen die erste Nachricht aussendet, um den Transfer des Übertragungsrechts fortzuführen, wenn die erste Bestätigungsantwort nicht delektiert wird.
  • Die obigen und andere Ziele, Merkmale und Vorteile der Erfindung werden aus der nachfolgenden detaillierten Beschreibung in Verbindung mit den begleitenden Zeichnungen deutlicher.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockdiagramm, das die gesamte Anordnung eines Steuersystems für ein Kraftfahrzeug gemäss einer Ausführungsform der Erfindung zeigt;
  • 2 ist ein Blockdiagramm, das die Anordnung einer in 1 gezeigten elektronischen Steuereinheit zeigt;
  • 3 ist ein Schaltungsdiagramm, das Einzelheiten einer in 2 gezeigten Bus-Schnittstelle zeigt;
  • 4a ist ein Diagramm, das ein Format einer eine Dateneinheit enthaltenden Nachricht zur Übertragung zwischen elektronischen Steuereinheiten zeigt;
  • 4b ist ein Diagramm, das ein Format einer Nachricht zeigt, die keine Dateneinheit enthält;
  • 5 ist ein Flußdiagramm, das ein Programm zur anfänglichen Generierung eines Tokens (Übertragungsrecht) zeigt, wenn der Token nicht generiert wurde oder verloren ging;
  • 6a bis 6d bilden gemeinsam ein Zeitablaufdiagramm, das bei der Erklärung einer Art von Mediation für die Beilegung eines Konflikts für das Übertragungsrecht hilfreich ist, wobei:
  • 6a Bit-Nummern zeigt;
  • 6b Daten zeigt, die von einem Knoten 1 übertragen wurden;
  • 6c Daten zeigt, die von einem Knoten 2 übertragen wurden;
  • 6d logische Pegel auf einem Bus zeigt; und
  • 7 ist ein Flußdiagramm, das ein Programm zum Beenden der Datenübertragung zeigt.
  • DETAILLIERTE BESCHREIBUNG
  • Die Erfindung wird detailliert unter Bezug auf die Zeichnungen beschrieben, die eine Ausführungsform davon darstellen.
  • 1 zeigt die gesamte Anordnung eines Steuersystems für ein Kraftfahrzeug gemäss der Ausführungsform, die elektronische Steuereinheiten (im folgenden als "die ECUs" bezeichnet) 1 bis 5 aufweist, die untereinander über einen Netzwerkbus 6 verbunden sind. Eine ENG-Steuer-ECU 1 steuert die Arbeitsweise eines Motors als Antwort auf die Betätigung eines Gaspedals, das von einem Fahrer des Fahrzeugs etc. betätigt wird. Eine MISS-Steuer-ECU 2 steuert ein automatisches Getriebe des Fahrzeugs entsprechend den Betriebsbedingungen des Motors. Eine TCS-Steuer-ECU 3 detektiert einen Schlupf der Antriebsräder und steuert ein Ausgangs-Drehmoment des Motors. Eine Aufhängungs-Steuer-ECU 4 steuert abhängig von den Betriebsbedingungen des Motors ein Aufhängungs-(aktive Aufhängung)system des Fahrzeugs. Eine Brems-Steuer-ECU 5 detektiert ein Rutschen der Räder und steuert den Bremsvorgang. Diese ECUs 1 bis 5 werden benötigt, um gegenseitig Steuerparameter und Arbeitsparameter überwachen zu können, die von Sensoren detektiert werden, von denen einige gemeinsam in 2 gezeigt sind, und sind folglich für die Übertragung von einander erforderlichen Daten durch den Netzwerkbus 6 miteinander verbunden.
  • 2 zeigt die Anordnung der ENG-Steuer-ECU 1, die eine Zentraleinheit 101 (im folgenden als "die CPU" bezeichnet) aufweist, wobei eine Ein-/Ausgabe-Schnittstelle 104 eine Mehrzahl von Sensoren 11 und eine Mehrzahl von Aktoren, wie z. B. Kraftstoffeinspritzventile, mit der CPU 101 verbindet. Die CPU 101 ist über eine Busleitung 107 mit einem RAM (Direktzugriffsspeicher) 102, einem ROM (Nur-Lese-Speicher) 103 und einem Kommunikations-Steuer-IC (Integrierter Schaltkreis) 105 verbunden. Der Kommunikations-Steuer-IC 105 ist über eine Busschnittstelle 106 mit dem Netzwerkbus 6 verbunden.
  • Die CPU 101 legt Steuerparameter auf der Basis von Ausgabesignalen der Sensoren 11 gemäss einem im ROM 103 gespeicherten Programm fest, um die Aktoren 12 anzutreiben. Das RAM 102 speichert temporär Daten der Berechnungsergebnisse. Der Kommunikations-Steuer-IC steuert die Übertragung einer Nachricht an den Netzwerkbus und den Empfang einer Nachricht von dem Netzwerkbus.
  • 3 zeigt Einzelheiten der mit dem Kommunikations-Steuer-IC 105 verbundenen Bus-Schnittstelle 106 und des Netzwerkbusses 6, der aus verdrillten Doppelleitungen 6b und 6c besteht, die an ihren beiden Enden miteinander über entsprechende Endwiderstände 6a, 6a verbunden sind.
  • Ein erstes Sendeterminal des Kommunikations-Steuer-ICs 105 ist mit einer Basis eines Transistors 119 über einen Widerstand 115 verbunden. Ein Emitter des Transistors 119 ist mit einer Netzanschlußleitung VSUP und ein Kollektor über einen Widerstand 116 mit einem invertierenden Eingangsanschluß eines Komparators 111 und mit einer 6b der verdrillten Doppelleitungen 6b und 6c verbunden.
  • Ein zweites Sendeterminal des Kommunikations-Steuer-ICs 105 ist mit einer Basis eines Transistors 120 über einen Widerstand 117 verbunden. Ein Emitter des Transistors 120 ist geerdet und ein Kollektor über einen Widerstand 118 mit einem nicht-invertierenden Eingangsanschluß des Komparators 111 und mit einer 6c der verdrillten Doppelleitungen 6b und 6c verbunden.
  • Der nicht-invertierende Eingangsanschluß des Komparators 111 ist über einen Widerstand 112 an die Netzanschlußleitung VSUP und ebenfalls über einen Widerstand 113 mit dem invertierenden Eingangsanschluß des Komparators 111 verbunden. Der invertierende Einganganschluß des Komparators 111 ist über einen Widerstand 114 geerdet und liefert ein Ausgabesignal davon an ein Empfangsterminal des Kommunikations-Steuer-ICs 105.
  • In der in 3 gezeigten Schaltungsanordnung sind die Widerstände 116 und 118 jeweils auf ungefähr 30 Ω, die Widerstände 112 und 114 auf ungefähr 2 kΩ, der Widerstand 113 auf ungefähr 200 Ω und die Endwiderstände 6a auf ungefähr 100 Ω eingestellt.
  • Die ersten und zweiten Sendeterminals des Kommunikations-Steuer-ICs 105 werden mit zueinander in umgekehrter Phase stehenden Pulssignalen versorgt. Wenn das erste Sendeterminal bei einem niedrigen Pegel und das zweite Sendeterminal bei einem hohen Pegel liegt, werden beide Transistoren 119 und 120 eingeschaltet, um die Spannung der einen verdrillten Doppelleitung 6b auf den hohen Pegel und die der anderen verdrillten Doppelleitung 6c auf den niedrigen Pegel einzustellen. Wenn das erste Sendeterminal auf dem hohen Pegel und das zweite Sendeterminal auf dem niedrigen Pegel liegt, werden beide Transistoren 119 und 120 ausgeschaltet, um die Spannung der einen verdrillten Doppelleitung 6b auf den niedrigen Pegel und die der anderen verdrillten Doppelleitung 6c auf den hohen Pegel einzustellen. Auf diese Weise wird ein Signal an den Netwerkbus 6 gesendet.
  • Da das Potential der einen verdrillten Doppelleitung 6b hoch oder niedrig wird, wird die Ausgabe des Komparators 111 niedrig oder hoch, wodurch ein auf dem Netzwerkbus 6 liegendes Signal empfangen wird.
  • Die ECUs 2 bis 5 sind im wesentlichen in der gleichen Weise konstruiert. Daher wird, auch wenn eine der ECUs ein Signal sendet, das die Spannung der einen verdrillten Doppelleitung 6b auf den niedrigen Pegel einstellt (d. h., die Spannung der anderen verdrillten Doppelleitung 6c auf den hohen Pegel einstellt), wenn eine andere ECU ein Signal sendet, das die Spannung der einen verdrillten Doppelleitung 6b auf den hohen Pegel einstellt, der Zustand der Spannung der verdrillten Doppelleitung 6b auf den hohen Pegel eingestellt. Daher wird in der vorliegenden Ausführungsform ein Zustand, in dem die eine verdrillte Doppelleitung 6b auf dem hohen Pegel liegt (die andere verdrillte Doppelleitung 6c liegt auf dem niedrigen Pegel), als ein dominanter Zustand und ein dem entgegengesetzter Zustand als ein rezessiver Zustand definiert.
  • Als nächstes wird ein Verfahren der Datenübertragung zwischen den ECUs beschrieben. In der vorliegenden Ausführungsform wird ein Token-Verfahren verwendet. Dies berücksichtigt die Tatsache, dass, verglichen mit einem CSMA/CD (Mehrfachzugriff mit Kollisionserkennung – Carrier Sense Multiple Access with Collision Detection)-Verfahren, das in der Lage ist, die Kollision zu beseitigen, das Token-Verfahren in Bezug auf eine elektrische Verzögerung auf dem Netzwerkbus vorteilhaft und in der Lage ist, den maximalen Nachrichtenverzögerungszeitraum einfach zu bestimmen, was es erlaubt, das Netzwerksystem einfach zu entwerfen.
  • 4a und 4b zeigen Formate von Nachrichten, die bei der Datenübertragung der vorliegenden Ausführungsform verwendet werden. 4a zeigt ein Format einer Datennachricht (zweite Nachricht) zur Übertragung eines Tokens (repräsentativ für das Übertragungsrecht) und Daten, während 4b das einer Token-Nachricht (erste Nachricht) zur Übertragung des Tokens allein zeigt. In der folgenden Beschreibung werden die das Netzwerksystem bildenden ECUs als die Knoten 1 bis 5 bezeichnet.
  • In 4a meldet ein Feld F1 (SOM) den Beginn einer Nachricht, was durch ein dominantes Bit gebildet wird. Dieses Feld wird zur Synchronisierung aller das Netzwerksystem bildenden Knoten verwendet.
  • Ein Feld F2 (TA) bestimmt eine durch vier Datenbits gebildete Adresse eines Bestimmungsknotens, an den der Token übertragen werden soll. Die Knotenadresse wird z. B. auf einen der Werte 0 bis 4 in einer den ECUs 1 bis 5 entsprechenden Weise festgesetzt.
  • Ein Feld F3 (CTL) bestimmt eine Art von Nachricht (Token-Nachricht oder Datennachricht).
  • Ein Feld F4 (DATA UNIT) stellt eine Dateneinheit dar, die aus einem DN (Bestimmungsknoten – Destination Node)-Feld, das einen Knoten oder Knoten bestimmt, die in einem DATA-Feld enthaltene Daten empfangen sollen, einem DLC (Datenlänge – Data Length)-Feld, das die Länge eines Bytes des DATA-Felds bestimmt, einem ID (Identifizierungszeichen – Identifier)-Feld, das ein Identifizierungszeichen der Daten bildet, und dem DATA-Feld, das zu übertragende Informationen enthält, besteht.
  • In diesem Zusammenhang ist die Länge des DATA-Feldes, wie aus der obigen Beschreibung vermutet werden kann, variabel, und die Gesamtlänge der Dateneinheit ist innerhalb des Bereichs von 32 bis 96 Byte variabel.
  • Ein Feld F5 (FCS) ist ein CRC (zyklische Redundanzprüfung – Cyclic Redundancy Check)-Feld, das aus einer Folge (CRC-Zeichensequenz – CRC character sequence) von Zeichen zur Fehlerbestimmung mit 16 Bit besteht, erhalten durch die Verwendung der folgenden Gleichung (1) als ein generierendes Polynom: Generierendes Polynom = X16 + X12 + X5 + 1
  • Ein Begrenzungszeichen (Teilungszeichen) mit einem rezessiven Bit wird zwischen das Feld F5 und das Feld F6 gestellt.
  • Ein Feld F6 (DACK) ist ein zweites Antwortfeld, in das eine Datenquittungsantwort (zweites Quittungszeichen), welche durch einen Quittungsschlitz mit zwei Bits gebildet wird, durch einen Knoten geschrieben werden sollte, der die Daten normal oder sicher empfangen hat. Ein Sendeknoten sendet eine Nachricht, die den Quittungsschlitz als rezessive Bits hat, und der oder die Knoten, die in der Nachricht als diejenigen bestimmt sind, die Information zu empfangen, und die Daten normal oder sicher empfangen haben, führen die Daten-Quittungsantwort durch Überschreiben zweier dominanter Bits darin aus. Ein Begrenzungszeichen mit zwei rezessiven Bits wird zwischen die Felder F6 und F7 gestellt.
  • Ein Feld F7 (TACK) ist ein erstes Antwortfeld, in das eine sToken-Quittungsantwort (erstes Quittungszeichen), die, ähnlich dem Feld F6, durch einen Quittungsschlitz mit zwei Bits gebildet wird, durch einen Knoten geschrieben werden sollte, der die Daten normal oder sicher empfangen hat. Der Sendeknoten sendet eine Nachricht, die den Quittungsschlitz als rezessive Bits aufweist, und der Knoten, der den Token empfangen hat, fuhrt die Token-Quittungsantwort durch Überschreiben zweier dominanter Bits darin aus. Ein durch zwei rezessive Bits gebildetes Begrenzungszeichen wird zwischen das Feld F7 und das Feld F8 gestellt.
  • Ein Feld F8 (EOM) bestimmt das Ende der Nachricht und wird durch sechs rezessive Bits gebildet.
  • In der vorliegenden Ausführungsform werden das Feld F7 und das Feld F6 als Felder zur Verfügung gestellt, in denen die Quittung des Tokens bzw. die Quittung der Daten durchgeführt werden, was es einer Sendeseite ermöglicht, sofort zu bestätigen, ob die Übermittlung des Tokens und die Übertragung der Daten erfolgreich durchgeführt wurden oder nicht.
  • Die in 4b gezeigte Token-Nachricht ist so konstruiert, dass die Felder F4 bis F6 aus der Datennachricht gelöscht werden, und ein Begrenzungszeichen wird zwischen die Felder F3 und F7 gestellt.
  • Als nächstes wird ein Verfahren zum Zirkulieren des Tokens (Transferieren des Tokens entlang der ECUs) beschrieben.
  • Wenn ein Knoten, der den Token empfangen hat, Daten oder Informationen zu übertragen hat, muss er den Token zusammen mit den Daten übertragen. Falls der Knoten keine Daten oder Informationen zu übertragen hat, muss er den Token allein übertragen. Ein Knoten, zu dem der Token übertragen werden soll, ist ein in dem Feld F2 (TA) bestimmter Knoten. Die Tokenadresse wird normalerweise durch Hinzufügen eines Wertes von eins zu der Adresse des Sendeknotens selbst gesetzt, und eine Nachricht wird so lange weiter durch eine sequentielle Erhöhung der Tokenadresse um einen inkrementellen Wert von 1 ausgesendet, bis eine Token-Quittungsantwort detektiert wird. Wenn jedoch ein berechneter Wert der Tokenadresse einen Wert von 16 erreicht, wird die Tokenadresse auf 0 gesetzt, so dass die Tokenadresse über Werte von 0 bis 15 zirkuliert wird.
  • Wenn der der in der Nachricht gesetzten Tokenadresse entsprechende Knoten den Token empfangen hat, überschreibt er zwei dominante Bits in den Quittungsschlitz des Feldes F7 (TACK), wodurch er die Token-Quittungsantwort durchführt. Wenn die Token-Quittungsantwort auf diese Weise überschrieben wird und die Nachricht normalerweise in dem Feld F8 (EOM) endet, vervollständigt der Sendeknoten, der den Token gesendet hat, die Übertragung, und der empfangende Knoten hat den Token angenommen.
  • Als nächstes wird eine Art der Fehlerdetektierung in der Übertragung einer Nachricht beschrieben.
  • Wenn man sie grob klassifiziert, gibt es zwei Arten von Fehlern in einer Übertragung: einen, bei dem kein Übertragungsfehler aufgetreten ist, aber keine Daten-Quittungsantwort in das Feld F6 (DACK) des Quittungsschlitzes überschrieben wurde, und der andere, bei dem ein Übertragungsfehler während der Übertragung einer Nachricht detektiert worden ist. Wenn keine Quittungsantwort gegeben worden ist, wird diese Art von Übertragungsfehler durch den Sendeknoten selbst detektiert.
  • Andererseits wird der Übertragungsfehler durch die Überwachung von Daten, Überwachung durch CRC, Überwachung von Bitfüllfehlern und durch eine Überprüfung des Nachrichtenformats detektiert.
  • Entsprechend der Fehlererkennung durch die Überwachung von Daten wird ein Übertragungsfehler detektiert, wenn Daten, die ein Sendeknoten überträgt, nicht mit Daten übereinstimmen, die auf dem Bus liegen. Diese Überwachung der Daten wird jedoch mit den Quittungsschlitzen der Felder F6 und F7 und einem darauf folgenden rezessiven Bit verhindert.
  • Gemäss der Fehlererkennung durch CRC wird ein Übertragungsfehler detektiert, wenn ein Fehler bezüglich den in dem Feld F5 (FCS) gesetzten CRC-Zeichen gefunden wird, und diese Detektierung wird von anderen Knoten als dem Sendeknoten ausgeführt.
  • Entsprechend der Fehlererkennung von Bitfüllfehlern wird festgelegt, dass ein Fehler in der Übertragung vorliegt, wenn mehr als 5 aufeinander folgende Bits den gleichen logischen Zustand bezeichnen, und diese Detektierung wird von anderen Knoten als dem Sendeknoten durchgeführt. Die Felder F6 (DACK), F7 (TACK), F8 (EOM) und die Begrenzungszeichen werden jedoch von Überwachungsobjekten ausgeführt.
  • Gemäss der Fehlererkennung durch die Überprüfung des Nachrichtenformats wird ein Fehler detektiert, wenn ein unzulässiger Zustand in den Feldern der Bits (den Feldern F3, F8 und den Begrenzungszeichen), die einen festgelegten logischen Zustand haben, gefunden wird, und diese Art von Fehlererkennung wird von anderen Knoten als dem Sendeknoten durchgeführt.
  • Wenn irgendeiner der oben beschriebenen Fehler, die während der Übertragung auftreten, detektiert wird, sendet ein Knoten, der den Fehler detektiert hat, unverzüglich eine Fehlermeldung (sechs aufeinander folgende dominante Bits), wodurch der Sendeknoten den Übertragungsfehler erkennen kann, auch wenn ein Übertragungsfehler von einem anderen Knoten oder von anderen Knoten als dem Sendeknoten detektiert wird.
  • Als nächstes wird ein Verfahren zur Generierung des Tokens oder zur anfänglichen Übertragung des Tokens an einen der Knoten, wenn der Token nicht generiert wurde oder das Datenübertragungssystem diesen verloren hat, unter Bezugnahme auf 5 und 6 beschrieben.
  • Der Kommunikations-Steuer-IC 105 jeder der ECUs 1 bis 5 bestimmt bei einem Schritt S1 der 5, ob der Netzwerkbus untätig ist oder nicht, um festzustellen, ob das Datenübertragungssystem sich in einem Zustand befindet, in dem der Token nicht unmittelbar nach dem Start des Systems generiert wurde oder aufgrund eines Fehlers eines Knotens, der den Token empfangen hat, verloren wurde. Wenn die Antwort auf diese Frage negativ ist (NEIN), d. h., wenn eine andere ECU eine Nachricht sendet, wird das laufende Programm sofort beendet.
  • Andererseits startet, falls der Netzwerkbus 6 untätig ist, d. h., keine anderen ECUs irgendeine Nachricht senden, die aktuelle ECU die Datenübertragung über den Kommunikations-Steuer-IC 105 und die Busschnittstelle 106 in einem Schritt S2, wobei angenommen wird, dass der aktuelle Knoten den Token angenommen hat. Dann werden Daten, die von dem aktuellen Knoten gesendet wurden, mit den Daten auf dem Netzwerkbus 6 Bit um Bit in einem Schritt S3 verglichen, um festzustellen, ob beide Daten identisch sind. Wenn die Antwort auf diese Frage bejahend ist (JA), d. h., die gesendeten Daten und die Daten auf dem Netzwerkbus miteinander übereinstimmen, heisst das, dass es keinen Konflikt zwischen den von dem aktuellen Knoten gesendeten Daten und Daten von anderen Knoten gibt oder dass der aktuelle Knoten im Konflikt um die Annahme des Tokens die Oberhand behält, und folglich wird die Datenübertragung fortgesetzt, wobei angenommen wird, dass der aktuelle Knoten den Token noch nicht verloren hat. Das heisst, dass das laufende Programm zu einem Schritt S4 fortschreitet, wo ermittelt wird, ob die Übertragung der gesamten Sequenz von Daten beendet wurde oder nicht. Wenn die Antwort auf diese Frage negativ ist (NEIN), kehrt das Programm zu dem Schritt S3 zurück, wo anschliessend gesendete Daten in der gleichen Weise wie oben beschrieben mit Daten verglichen werden, die auf dem Netzwerkbus liegen.
  • Es versteht sich von selbst, dass es einen Fall gibt, in dem der aktuelle Knoten im Konflikt um die Annahme des Tokens unterliegt, um dann die Datenübertragung zu stoppen, wenn das oben beschriebene Verfahren ausgeführt wird. Des weiteren wird als ein Verfahren zur Ermittlung, ob die vom aktuellen Knoten gesendeten Daten und die auf dem Systembus liegenden Daten miteinander übereinstimmen, das oben beschriebene Verfahren der Fehlererkennung durch Überwachung von Daten für die Ermittlung benutzt, dass die gesendeten Daten und die auf dem Systembus liegenden Daten nicht miteinander übereinstimmen. Genauer gesagt wird im vorliegenden Fall die Übereinstimmung der Daten durch die Berechnung eines exklusiven ODER der gesendeten Daten und der vom Netzwerkbus 6 empfangenen Daten ermittelt.
  • Andererseits, wenn die von dem aktuellen Knoten gesendeten Daten sich von den Daten, die auf dem Netzwerkbus 6 liegen, unterscheiden, heisst das, dass es einen Konflikt mit anderen Knoten um den Token gegeben hat und dass der aktuelle Knoten in dem Konflikt unterlegen ist, so dass die Datenübertragung in einem Schritt S5 unterbrochen wird, gefolgt von der Beendigung des laufenden Programms.
  • Wenn in dem Schritt S4 ermittelt wird, dass die gesamte Sequenz von Daten gesendet wurde, d. h., wenn ermittelt wird, dass der aktuelle Knoten während des Konflikts zur Annahme des Tokens die Oberhand behält, wird in einem Schritt S6 durch eine Überprüfung bezüglich der Token-Quittungsantwort ermittelt, ob die Übertragung des Tokens abgeschlossen wurde oder nicht. Wenn die Übertragung des Tokens nicht beendet wurde, wird der Tokenadresse der Tokennachricht ein Wert von 1 hinzugefügt, und dann wird in einem Schritt S7 die resultierende Tokennachricht an den Netzwerkbus 6 gesendet. Die Schritte S6 und S7 werden wiederholt ausgeführt, bis die Übertragung des Tokens abgeschlossen ist, woraufhin das laufende Programm beendet wird.
  • Des weiteren werden bei der Ermittlung eines Siegers des Konflikts Daten, die durch eine identische Bitsequenz gebildet sind, mehrmals zur Verhinderung einer fehlerhaften Ermittlung aufgrund von Rauschen oder dergleichen gesendet.
  • Als nächstes werden Details einer Art der Ermittlung eines Siegers des Konflikts unter Bezugnahme auf die 6a bis 6d beschrieben.
  • Angenommen, Daten werden, wie in 6b und 6c gezeigt, vom Knoten 1 bzw. vom Knoten 2 übertragen. Wie im vorigen beschrieben, ist ein Bit in dem logischen Zustand "1" ein dominantes Bit, und ein Bit in dem logischen Zustand "0" ist ein rezessives Bit. Wenn ein Konflikt zwischen dem dominanten Bit und dem rezessiven Bit auftritt, wird der logische Zustand auf dem Netzwerkbus gleich "1".
  • Im Falle der in 6b und 6c gezeigten Daten befinden sich Bits, die zu den in 6a gezeigten Bitnummern 1 bis 4 korrespondieren, jeweils im gleichen logischen Zustand, und die logischen Zustände der von dem Knoten 1 und dem Knoten 2 gesendeten Daten sowie der logische Zustand des Netzwerkbusses sind alle einander gleich. Folglich senden Knoten 1 und Knoten 2 beide weiterhin entsprechende Nachrichten von Bit Nr. 1 bis Bit Nr. 4.
  • Bei dem Bit Nr. 5 jedoch ist der logische Zustand der von dem Knoten 1 gesendeten Daten gleich "1", während der logische Zustand von Daten, die vom Knoten 2 gesendet wurden, gleich "0" ist. Folglich wird der logische Zustand des Netzwerkbusses gleich dem logischen Zustand "1" des vom Knoten 1 gesendeten dominaten Bits. Daher ermittelt Knoten 1, der das dominante Bit gesendet hat, dass er den Token nicht verloren hat, und fährt fort, die Nachricht zu senden, während Knoten 2, der das rezessive Bit gesendet hat, ermittelt, dass er den Token verloren hat, und das Senden der Nachricht einstellt.
  • In diesem Zusammenhang zeigen die 6a bis 6d einen Fall, bei dem zwei Knoten in Konflikt um den Token stehen. Es kann jedoch tatsächlich ein Fall auftreten, in dem ein Konflikt um den Token unter mehr als zwei Knoten entsteht. Es ist jedoch für alle Knoten unmöglich, weiterhin die selbe Sequenz von Daten zu senden, und schliesslich wird notwendigerweise ohne irgendwelche Probleme ein Knoten bestimmt, der sich in dem Konflikt behauptet.
  • Wie aus der obigen Beschreibung klar hervorgeht, wird gemäss der vorliegenden Erfindung, wenn das Steuersystem gestartet wird oder ein Knoten, der den Token empfangen hat, fehlerhaft ist, ein Token generiert oder anfänglich an einen der Knoten durch Konflikt um den Token wie oben beschrieben übergeben, und anschliessend wird der Token durch die Knoten zirkuliert oder entlang den Knoten übertragen. Dies ermöglicht es, den Token unverzüglich dadurch zu generieren, dass allen Knoten eine gleiche Chance zum Empfangen des Tokens gegeben wird, wodurch das System in die Lage versetzt wird, effektiv zu funktionieren.
  • Des weiteren ist die vorliegende Erfindung nicht auf die obige Ausführungsform beschränkt, sondern der logische Zustand "0" kann, im Gegensatz zu der obigen Ausführungsform, als eine Art der Konfliktmediation für ein dominantes Bit und der logische Zustand "1" für ein rezessives Bit verwendet werden. Weiterhin ist, nachdem der Token durch Konflikt generiert worden ist, ein Knoten, zu dem der Token zuerst übertragen wurde, nicht notwendigerweise auf einen Knoten beschränkt, der eine Knotenadresse aufweist, die der Adresse folgt, die den Token anfänglich empfangen hat, sondern der Token kann zuerst an einen vorbestimmten Knoten übertragen werden, der die kleinste Knotenadresse hat, um dann dem Knoten zu gestatten, in einem vorbestimmten Zyklus durch die Knoten zu zirkulieren.
  • Als nächstes wird ein Verarbeitungsverfahren beschrieben, das ausgeführt wird, wenn keine Daten-Quittungsantwort erhalten wurde, nachdem ein Sendeknoten eine Datennachricht gesendet hat. In der folgenden Beschreibung wird das erste Quittungszeichen, das in das Feld F7 überschrieben werden soll, als "das Token-ACK" bezeichnet, während das zweite Quittungszeichen, das in das Feld F6 überschrieben werden soll, als "das Daten-ACK" bezeichnet wird.
    • (1) Wenn das Token-ACK nicht ermittelt und das Daten-ACK ermittelt wurde: Die Token-Datenadresse wird durch einen inkrementellen Wert von 1 erhöht und dann wird die resultierende Token-Nachricht gesendet. Dies gilt für die Übertragung des Tokens allein zu einem Knoten, der dem Knoten folgt, zu dem der Token nicht erfolgreich übertragen wurde, da der Empfang der in das Feld F4 geschriebenen Daten bestätigt wurde.
    • (2) Wenn das Token-ACK ermittelt und das Daten-ACK nicht ermittelt wurde: Da die Übertragung des Tokens abgeschlossen ist, wird eine erneute Übertragung der Daten nicht ausgeführt. Die Daten werden, wenn möglich, erneut übertragen, wenn der Token beim nächsten Mal erworben wird.
    • (3) Wenn weder das Token-ACK noch das Daten-ACK ermittelt wurden: Die Tokenadresse wird um einen inkrementellen Wert von 1 erhöht, und die die resultierende Tokenadresse enthaltende Token-Nachricht wird übertragen, die erneute Übertragung der Daten wird aber nicht ausgeführt. So wird die Zirkulation des Tokens bevorzugt vor der Übertragung der Daten ausgeführt, um eine reibungslose Zirkulation des Tokens zu erlauben. Des weiteren werden die Daten, wenn möglich, erneut übertragen, wenn der Token das nächste Mal erworben wird.
  • Wie oben beschrieben wird, auch wenn das Daten-ACK nicht ermittelt wird, die Übertragung des Tokens für abgeschlossen erachtet, solange das Token-ACK ermittelt wird, und die erneute Übertragung von Daten wird verhindert. Des weiteren wird, wenn weder das Daten-ACK noch das Token-ACK ermittelt werden, nur die Übertragung des Tokens, ohne die erneute Übertragung der Daten, erneut versucht, wodurch es möglich ist, den Token reibungslos zu zirkulieren. Der Vorzug wird der Übertragung des Tokens eingeräumt, da die erneute Übertragung der Daten unmittelbar nach der Ermittlung eines Übertragungsfehlers es erfordert, die maximale Verzögerungszeit des Systems auf eine längere Zeitspanne zu setzen, als wenn die Übertragung des Tokens wie in der vorliegenden Ausführungsform bevorzugt durchgeführt würde.
  • Obwohl in dem obigen Beispiel, wenn weder das Token-ACK noch das Daten-ACK ermittelt werden, der Token-Nachricht erlaubt wird, sofort gesendet zu werden, und gleichzeitig eine erneute Übertragung von Daten verhindert wird, ist dies nicht beschränkend, sondern die Übertragung des Tokens kann auch durchgeführt werden, nachdem die erneute Übertragung von Daten ein- oder zweimal versucht wurde.
  • 7 zeigt diese Änderung des Übertragungssteuerungsverfahrens, die von dem Verbindungssteuer-IC 105 zum Beenden der Übertragung bei Beendigung des Sendens der Nachricht oder bei Detektierung einer Fehlermeldung durchgeführt wird.
  • In der folgenden Beschreibung sollte verstanden sein, dass ein Fehler in der Übertragung von einem Sendeknoten oder einem Empfangsknoten detektiert wird, wohingegen eine Fehlermeldung von dem Knoten, der den Fehler detektiert hat, ausgesandt wird, wodurch die Übertragung beendet wird.
  • Bei einem Schritt S21 der 7 wird bestimmt, ob ein Fehler bei der Übertragung aufgetreten ist oder nicht. Wenn die Antwort auf diese Frage negativ (NEIN) ist, wird bei einem Schritt S22 bestimmt, ob der Transfer des Tokens beendet ist oder nicht (ob das Token ACK detektiert ist oder nicht). Wenn der Transfer des Tokens beendet worden ist, werden erste und zweite Zähler CT1, CT2, auf die im Folgenden Bezug genommen wird, bei einem Schritt S30 zurückgesetzt, gefolgt von der Beendigung des vorliegenden Programms. Wenn die Antwort auf die Frage des Schrittes S22 negativ (NEIN) ist, d. h., wenn kein Fehler während der Übertragung aufgetreten ist, aber der Transfer des Tokens nicht beendet ist, schreitet das Programm weiter zu einem Schritt S23, wo bestimmt wird, ob die Daten erfolgreich übertragen worden sind oder nicht (ob das Daten ACK detektiert ist oder nicht). Wenn bestimmt wird, dass die Daten erfolgreich übertragen worden sind, wird der Transfer des Tokens bei einem Schritt S29 durchgeführt, und dann werden die ersten und zweiten Zähler CT1, CT2 bei dem Schritt S30 zurückgesetzt, gefolgt von der Beendigung des Programms.
  • Wenn andererseits die Antwort auf die Frage des Schrittes S23 negativ (NEIN) ist, d. h., wenn kein Fehler während der Übertragung aufgetreten ist, aber weder der Transfer des Tokens noch die Übertragung der Daten erfolgreich ausgeführt wurden (weder das Token ACK noch das Daten ACK detektiert wurden), schreitet das Programm weiter zu einem Schritt S24, wo ein Zählwert des ersten Zählers CT1 um einen Inkrementwert von 1 erhöht wird, und es wird bei einem Schritt S25 bestimmt, ob der resultierende Zählwert des ersten Zählers CT1 gleich einem vorbestimmten Wert C1 (welcher z. B. auf einen Wert von 2 gesetzt wird) ist oder nicht. Wenn dieser Schritt zuerst ausgeführt wird, gilt CT1 < C1, so dass eine Neuübertragung der Nachricht, welche nicht erfolgreich übertragen worden ist, bei einem Schritt S28 durchgeführt wird, gefolgt von der Beendigung des Programms. Wenn die Bestätigungsantworten (das Token ACK und das Daten ACK) weiterhin danach nicht detektiert werden, bis CT1 = C1 bei einem Schritt S25 gilt, schreitet das Programm von dort weiter zu dem Schritt S29, wo der Token von der Tokennachricht transferiert wird, und die Zähler CT1, CT2 werden bei dem Schritt S30 zurückgesetzt, gefolgt von der Beendigung des Programms.
  • Wenn die Antwort auf die Frage des Schrittes S21 bejahend (JA) ist, d. h., wenn ein Fehler bei der Übertragung aufgetreten ist, wird ein Zählwert des zweiten Zählers CT2 um einen Inkrementwert von 1 bei einem Schritt S26 erhöht, und es wird bei einem Schritt S27 bestimmt, ob der resultierende Zählwert des zweiten Zählers CT2 gleich einem zweiten vorbestimmten Wert C2 (welcher z. B. auf einen Wert von 5 gesetzt wird) ist oder nicht. Wenn dieser Schritt zuerst ausgeführt wird, gilt CT2 < C2, so dass die Neuübertragung der Nachricht welche nicht erfolgreich übertragen worden ist, bei dem Schritt S28 durchgeführt wird, gefolgt von der Beendigung des Programms. Wenn der Übertragungsfehler weiterhin auftritt, bis CT2 = C2 bei einem Schritt S27 gilt, schreitet das Programm von dort weiter zu den folgenden Schritten S29 und S30.

Claims (4)

  1. Datenübertragungsverfahren zum Verbinden einer Mehrzahl von Steuersystemen (1, 2, 3, 4, 5), die an einem Fahrzeug installiert sind, über mindestens eine gemeinsame Signalleitung (6), und zum Übertragen einer Nachricht zwischen der genannten Mehrzahl von Steuersystemen (1, 2, 3, 4, 5), während ein Übertragungsrecht durch die Mehrzahl von Steuersystemen (1, 2, 3, 4, 5) zirkuliert, dadurch gekennzeichnet, dass die Nachricht ein erstes Antwortfeld (F7(TACK)) zum Empfangen einer ersten Bestätigungsantwort, die von einem Steuersystem, welches das Übertragungsrecht empfangen hat, ausgegeben wird, und ein zweites Antwortfeld (F6(DACK)) zum Empfangen einer zweiten Bestätigungsantwort, die von einem Steuersystem, das Daten empfangen hat, ausgegeben wird, umfasst.
  2. Datenübertragungsverfahren nach Anspruch 1, wobei ein Verarbeiten entsprechend der ersten Bestätigungsantwort bevorzugt gegenüber einem Verarbeiten entsprechend der Abwesenheit der zweiten Bestätigungsantwort durchgeführt wird.
  3. Datenübertragungsverfahren nach Anspruch 2, wobei das Verarbeiten entsprechend der ersten Bestätigungsantwort auf einen Empfang des Übertragungsrechtes beim nächsten Mal oder auf die Weiterführung des Transfers des Übertragungsrechtes wartet und das Verarbeiten entsprechend dem Fehlen der zweiten Bestätigungsantwort die Neuübertragung der Daten ist.
  4. Datenübertragungsverfahren nach Anspruch 1, wobei die Nachricht in eine erste Nachricht mit dem ersten Antwortfeld (F7(TACK)) und eine zweite Nachricht mit dem zweiten Antwortfeld (F6(DACK)) klassifiziert wird und wobei jedes der Mehrzahl von Steuersystemen (1, 2, 3, 4, 5) urteilt, dass ein Transfer des Übertragungsrechtes beendet ist unabhängig, ob die zweite Bestätigungsantwort detektiert wird oder nicht, falls die erste Bestätigungsantwort detektiert wird, wenn die zweite Nachricht von dem Steuersystem, das Daten empfangen hat, ausgesendet wird, und keine Übertragung der Nachricht durchführt, bis das Übertragungsrecht das nächste Mal erhalten wird, wohingegen jedes der Mehrzahl von Steuersystemen (1, 2, 3, 4, 5) die erste Nachricht aussendet, um den Transfer des Übertragungsrechtes fortzuführen, wenn die erste Bestätigungsantwort nicht detektiert wird.
DE69433866T 1993-02-15 1994-02-15 Verfahren zur Übertragung von Daten Expired - Fee Related DE69433866T2 (de)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
JP5048560A JP2947437B2 (ja) 1993-02-15 1993-02-15 データ伝送方法
JP5048559A JP2857655B2 (ja) 1993-02-15 1993-02-15 車両用データ伝送システム
JP4856093 1993-02-15
JP4855993 1993-02-15
JP5080216A JP2784709B2 (ja) 1993-03-15 1993-03-15 車両用データ伝送システム
JP8021693 1993-03-15
JP5084079A JP2947496B2 (ja) 1993-03-18 1993-03-18 車両用データ伝送システム
JP8407993 1993-03-18

Publications (2)

Publication Number Publication Date
DE69433866D1 DE69433866D1 (de) 2004-07-29
DE69433866T2 true DE69433866T2 (de) 2005-06-30

Family

ID=27462227

Family Applications (4)

Application Number Title Priority Date Filing Date
DE69433882T Expired - Fee Related DE69433882T2 (de) 1993-02-15 1994-02-15 Vorrichtung zur Übertragung von Daten
DE69433866T Expired - Fee Related DE69433866T2 (de) 1993-02-15 1994-02-15 Verfahren zur Übertragung von Daten
DE69428930T Expired - Fee Related DE69428930T2 (de) 1993-02-15 1994-02-15 Verfahren und Vorrichtung zur Übertragung von Daten
DE69433098T Expired - Fee Related DE69433098T2 (de) 1993-02-15 1994-02-15 Vorrichtung zur Übertragung von Daten

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE69433882T Expired - Fee Related DE69433882T2 (de) 1993-02-15 1994-02-15 Vorrichtung zur Übertragung von Daten

Family Applications After (2)

Application Number Title Priority Date Filing Date
DE69428930T Expired - Fee Related DE69428930T2 (de) 1993-02-15 1994-02-15 Verfahren und Vorrichtung zur Übertragung von Daten
DE69433098T Expired - Fee Related DE69433098T2 (de) 1993-02-15 1994-02-15 Vorrichtung zur Übertragung von Daten

Country Status (4)

Country Link
US (4) US5586118A (de)
EP (4) EP0612169B1 (de)
CA (1) CA2115730C (de)
DE (4) DE69433882T2 (de)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69433882T2 (de) * 1993-02-15 2005-08-25 Honda Giken Kogyo K.K. Vorrichtung zur Übertragung von Daten
JP2765538B2 (ja) * 1995-11-30 1998-06-18 日本電気株式会社 データ転送制御装置
GB9603582D0 (en) 1996-02-20 1996-04-17 Hewlett Packard Co Method of accessing service resource items that are for use in a telecommunications system
GB9605048D0 (en) * 1996-03-09 1996-05-08 Jaguar Cars Multiplexed electronic control systems
US5822543A (en) * 1996-07-08 1998-10-13 International Business Machines Corporation Gathering data handling statistics in non-synchronous data communication networks
JP3117000B2 (ja) * 1997-02-21 2000-12-11 株式会社デンソー 通信システムおよびそれに使用される電子制御装置
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
US6038689A (en) * 1997-08-21 2000-03-14 Digital Equipment Corporation Fault notification system and process using local area network
ES2147119B1 (es) * 1998-03-10 2001-03-16 Mecanismos Aux Es Ind S L Sistema para transferir informacion binaria.
DE19843810A1 (de) * 1998-09-24 2000-03-30 Philips Corp Intellectual Pty Datenbus
JP2000156685A (ja) * 1998-11-18 2000-06-06 Fuji Heavy Ind Ltd 車両制御システムの異常監視装置
US6389550B1 (en) * 1998-12-23 2002-05-14 Ncr Corporation High availability protocol computing and method
US6604038B1 (en) * 1999-11-09 2003-08-05 Power Talk, Inc. Apparatus, method, and computer program product for establishing a remote data link with a vehicle with minimal data transmission delay
US7040435B1 (en) * 1999-11-17 2006-05-09 Vehicle Enhancement Systems Inc. Method for data communication between a vehicle and a remote terminal
US6661998B1 (en) * 1999-12-23 2003-12-09 Denso Corporation Mobile station to base station communication and signal acknowledgement
US6484082B1 (en) * 2000-05-24 2002-11-19 General Motors Corporation In-vehicle network management using virtual networks
DE10027017A1 (de) * 2000-05-31 2002-02-28 Bayerische Motoren Werke Ag Betriebsverfahren für einen Datenbus für mehrere Teilnehmer
US6775690B1 (en) * 2000-07-21 2004-08-10 At&T Corp. Time-dependent messaging
EP1202146A1 (de) * 2000-10-23 2002-05-02 Lucent Technologies Inc. System zur Steuerung von elektrischen von Parametern Schaltungskomponenten
IES20010064A2 (en) * 2001-01-29 2002-04-17 Eland Technologies Inc Computer network system
US7164654B2 (en) * 2001-03-09 2007-01-16 Denso Corporation ARQ parameter retransmission control for variable data rate channels
US6973492B2 (en) * 2001-09-07 2005-12-06 International Business Machines Corporation Method and apparatus for collecting page load abandons in click stream data
DE50211756D1 (de) * 2002-02-22 2008-04-03 Bosch Gmbh Robert Verfahren und vorrichtung zur übermittlung von messdaten über einen can-bus in einem objekterfassungssystem für kraftfahrzeuge
JP4100108B2 (ja) * 2002-09-12 2008-06-11 株式会社デンソー 制御システム
WO2004084505A1 (ja) * 2003-03-18 2004-09-30 Fujitsu Limited 伝送帯域割り付け装置
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
US7461319B2 (en) * 2003-04-04 2008-12-02 Sun Microsystems, Inc. System and method for downloading files over a network with real time verification
US7532640B2 (en) 2003-07-02 2009-05-12 Caterpillar Inc. Systems and methods for performing protocol conversions in a machine
US7516244B2 (en) * 2003-07-02 2009-04-07 Caterpillar Inc. Systems and methods for providing server operations in a work machine
US7983820B2 (en) 2003-07-02 2011-07-19 Caterpillar Inc. Systems and methods for providing proxy control functions in a work machine
US7162339B2 (en) * 2004-08-31 2007-01-09 General Motors Corporation automated vehicle calibration and testing system via telematics
DE102004050424B4 (de) * 2004-10-15 2010-04-15 Bosch Rexroth Ag Verfahren zur Übertragung von Daten in einem Kommunikationssystem
DE602004021947D1 (de) * 2004-11-29 2009-08-20 Scania Cv Abp Verfahren zur Start-Up-Kontrolle von Netzkommunikation in einem Kommunikationsnetz
JP4437468B2 (ja) * 2004-12-06 2010-03-24 富士通テン株式会社 車両用電子制御装置
JP2006309547A (ja) * 2005-04-28 2006-11-09 Toshiba Corp 情報処理装置及び情報処理方法
GB2431769B (en) * 2005-10-25 2009-06-10 Laurence Wrenn Switching unit
DE102006051907A1 (de) 2005-11-03 2007-08-30 Continental Teves Ag & Co. Ohg Gemischtsignalschaltkreis für ein elektronisches, abgesichertes Steuer- bzw. Regelungssystem
JP4681504B2 (ja) * 2006-05-22 2011-05-11 ヤマハ発動機株式会社 リモコン用電子制御装置及びそれを用いた遠隔操作システム
US20080082708A1 (en) * 2006-09-29 2008-04-03 Kar Leong Wong Token hold off for chipset communication
CN101816143B (zh) * 2007-10-03 2013-03-20 富士通株式会社 无线通信装置、无线通信控制装置、无线通信方法、以及无线通信控制方法
FR2926943B1 (fr) * 2008-01-30 2012-01-13 Canon Kk Procedes de transmission et reconstruction de sequences d'unites de donnees, produit programme d'ordinateur, moyen de stockage, noeuds emetteur et recepteur correspondants
DE102008012730B3 (de) * 2008-03-05 2009-08-27 Robert Bosch Gmbh Elektronische Steuer- und Diagnoseeinrichtung zum Betreiben einer Ventileinheit
US8238538B2 (en) 2009-05-28 2012-08-07 Comcast Cable Communications, Llc Stateful home phone service
EP2355393B1 (de) * 2010-01-21 2013-12-11 Rohde & Schwarz GmbH & Co. KG Verfahren und Vorrichtung zur Bestimmung einer optimierten Anzahl von Übertragungen für ein Datenpaket in einem Multicast-Übertragungssystem
DE112010005725B4 (de) * 2010-07-08 2017-07-20 Mitsubishi Electric Corp. Fahrzeugdatenabnormalitäts-Bestimmungsvorrichtung
JP5651442B2 (ja) * 2010-11-29 2015-01-14 矢崎総業株式会社 動作支援装置、電子機器、電子制御装置、及び、制御システム
DE102011116642A1 (de) * 2011-10-20 2013-04-25 Audi Ag Übertragungseinrichtung und Verfahren zur sicheren Übertragung eines Sensorsignals an ein Übertragungsziel und Kraftfahrzeug
WO2013141767A1 (en) 2012-03-21 2013-09-26 Husqvarna Ab Method for communicating data between a control system of a power tool and a computing device.
EP2892201B1 (de) 2014-01-06 2017-08-30 Argus Cyber Security Ltd. Detektions-wächter
US10326793B2 (en) 2015-06-10 2019-06-18 RunSafe Security, Inc. System and method for guarding a controller area network
US10423475B2 (en) * 2016-09-30 2019-09-24 Microsoft Technology Licensing, Llc Stateful tokens for communicating with external services
CN106628070B (zh) * 2016-11-09 2018-06-26 重庆长安工业(集团)有限责任公司 基于船用D30mm系统操控台的控制方法
EP3506584B1 (de) * 2017-12-28 2020-12-23 Vestel Elektronik Sanayi ve Ticaret A.S. Verfahren und vorrichtung zur kommunikation zwischen mehreren steuerplatinen
CN110213018B (zh) * 2019-05-09 2022-07-15 北京汽车股份有限公司 车载总线的数据通信方法、装置及车辆
CN114531314B (zh) * 2022-01-11 2023-12-22 宁波天擎航天科技有限公司 航天领域大数据可靠传输的方法、电子设备及存储介质

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4560985B1 (en) * 1982-05-07 1994-04-12 Digital Equipment Corp Dual-count, round-robin ditributed arbitration technique for serial buses
US4590468A (en) * 1983-03-10 1986-05-20 Western Digital Corporation Token access controller protocol and architecture
JPS59211143A (ja) * 1983-05-17 1984-11-29 Nissan Motor Co Ltd マイクロコンピユ−タを用いた車両用制御回路
US4556974A (en) * 1983-10-07 1985-12-03 Honeywell Inc. Method for passing a token in a local-area network
US4551721A (en) * 1983-10-07 1985-11-05 Honeywell Inc. Method for initializing a token-passing local-area network
US4725834A (en) * 1984-02-27 1988-02-16 American Telephone And Telegraph Company, At&T Bell Laboratories Reliable broadcast protocol for a token passing bus network
US4715031A (en) * 1985-09-23 1987-12-22 Ford Motor Company Vehicular data transfer communication system
DE3534216A1 (de) * 1985-09-25 1987-04-02 Bayerische Motoren Werke Ag Datenbussystem fuer fahrzeuge
JPS62151903A (ja) * 1985-12-25 1987-07-06 Nippon Denso Co Ltd 車両に搭載される電子制御装置
JPS62159539A (ja) * 1986-01-07 1987-07-15 Nec Corp デ−タ伝送装置
US4860006A (en) * 1986-06-05 1989-08-22 Michael Barall Heartbeat collision avoidance method and circuit
US4766530A (en) * 1986-11-24 1988-08-23 Westinghouse Electric Corp. Token passing scheme for a predetermined configuration local area network
JPS6457856A (en) * 1987-02-23 1989-03-06 Nitsuko Ltd Automatic incoming circuit in telephone set
JPH0771088B2 (ja) * 1987-04-06 1995-07-31 古河電気工業株式会社 多重伝送方式
JPS6458756A (en) * 1987-08-27 1989-03-06 Inax Corp Method of executing tile
JPS6458900A (en) * 1987-08-28 1989-03-06 Shimizu Construction Co Ltd Piping reclamation shutoff valve
JPH06101732B2 (ja) * 1987-11-30 1994-12-12 三菱電機株式会社 通信制御方式
US4899143A (en) * 1988-04-21 1990-02-06 Bell Communications Research, Inc. High capacity communication system over collision-type channels
JPH0769376B2 (ja) * 1989-08-30 1995-07-31 マツダ株式会社 車両用多重伝送装置
JP2770282B2 (ja) * 1992-04-13 1998-06-25 本田技研工業株式会社 車両用データ伝送システム
EP0580938B1 (de) * 1992-06-26 2001-09-26 Yokogawa Electric Corporation Steuerungsgerät für Duplex-Kommunikation
US5351241A (en) * 1992-12-24 1994-09-27 Intel Corporation Twisted pair ethernet hub for a star local area network
DE69433882T2 (de) * 1993-02-15 2005-08-25 Honda Giken Kogyo K.K. Vorrichtung zur Übertragung von Daten

Also Published As

Publication number Publication date
EP0612169A3 (en) 1995-10-11
DE69433882D1 (de) 2004-08-05
EP0612169A2 (de) 1994-08-24
DE69428930T2 (de) 2002-06-27
US5696904A (en) 1997-12-09
US5764919A (en) 1998-06-09
DE69433098T2 (de) 2004-03-25
US5659702A (en) 1997-08-19
US5586118A (en) 1996-12-17
CA2115730A1 (en) 1994-08-16
EP1022877A1 (de) 2000-07-26
EP1022879B1 (de) 2003-08-27
EP1022878A1 (de) 2000-07-26
CA2115730C (en) 1999-05-04
EP1022877B1 (de) 2004-06-23
DE69433882T2 (de) 2005-08-25
EP0612169B1 (de) 2001-11-07
EP1022879A1 (de) 2000-07-26
DE69433098D1 (de) 2003-10-02
DE69428930D1 (de) 2001-12-13
DE69433866D1 (de) 2004-07-29
EP1022878B1 (de) 2004-06-30

Similar Documents

Publication Publication Date Title
DE69433866T2 (de) Verfahren zur Übertragung von Daten
DE69230738T2 (de) Multiplex Übertragung zwischen Knoten mit Quittungssignalen und CRC-Rechnung
DE2843235C3 (de) Vorrichtung zum bitorientierten, rahmenstrukturierten, synchronen Übertragen von Informationen
DE69232686T2 (de) Multiplex-Übertragungssystem
DE3851127T2 (de) Multiplex-Übertragungssystem.
DE69019013T2 (de) Übertragungsfehler-Diagnosevorrichtung.
DE69921882T2 (de) Verfahren zur Entdeckung und Lösung von Datenkorruption in einem UART-basierten Kommunikationsnetzwerk
DE68920947T2 (de) Multiplex-Übertragungssystem für Kraftfahrzeuge.
DE69533951T2 (de) Protokoll für asynchrone Zeitvielfachvermittlung
DE69829429T2 (de) Datenkommunikationssystem und in diesem verwendete elektronische Kontrolleinheit
DE4231337A1 (de) Datenuebertragungssystem
DE69017096T2 (de) Rahmenabstreifverfahren zur Entfernung von verstümmelten Nachrichten in einem Ringkommunikationsnetz.
DE3736550A1 (de) Verfahren und vorrichtung zum simultanen datenverkehr
DE69129510T2 (de) Multiplex-Übertragungssystem für Kraftfahrzeuge
DE3113332C2 (de)
DE10248672B4 (de) Verfahren zur Übertragung von Daten auf einem Bus
EP3725041B1 (de) Verfahren zur bereitstellung von informationen für die lokalisierung von fehlern in einem kommunikationsnetzwerk eines gerätes, entsprechend ausgelegte busteilnehmerstation sowie fahrzeug
DE69215977T2 (de) System und Verfahren zum Erkennen von falschen Abschlusswiderständen und Kurzschlüssen in einem Netzwerk
DE3928537A1 (de) Verfahren zur fehlererkennung und/oder fehlerlokalisation bei datenuebertragungen
DE69223911T2 (de) Multiplexübertragungsverfahren und Verfahren zur Synchronisation in einer Multiplexübertragung
DE4391639C2 (de) Datenübertragungssystem für Fahrzeuge mit Eigenantrieb
DE102018203680A1 (de) Teilnehmerstation für ein serielles Bussystem und Verfahren zur Datenübertragung in einem seriellen Bussystem
DE102012110712B4 (de) Verfahren und System zur Funktionsprüfung einer Fehlererkennungseinheit einer CAN-Bus-Controllereinheit
DE4238488A1 (de)
DE10243319B4 (de) Sichere Datenübertragung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee