DE3506118C2 - - Google Patents

Info

Publication number
DE3506118C2
DE3506118C2 DE3506118A DE3506118A DE3506118C2 DE 3506118 C2 DE3506118 C2 DE 3506118C2 DE 3506118 A DE3506118 A DE 3506118A DE 3506118 A DE3506118 A DE 3506118A DE 3506118 C2 DE3506118 C2 DE 3506118C2
Authority
DE
Germany
Prior art keywords
message
error
bus
data
state
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
Application number
DE3506118A
Other languages
English (en)
Other versions
DE3506118A1 (de
Inventor
Wolfgang Dipl.-Ing. 7320 Goeppingen De Botzenhardt
Siegfried Dipl.-Phys. 7016 Gerlingen De Dais
Uwe Dipl.-Ing. 7140 Ludwigsburg De Kiencke
Martin Dipl.-Ing. 7143 Vaihingen De Litschel
Wolfgang Dipl.-Ing. 7015 Korntal-Muenchingen De Krampe
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=6263209&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE3506118(C2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority to DE3546664A priority Critical patent/DE3546664C3/de
Priority to DE3546683A priority patent/DE3546683C3/de
Priority to DE19853506118 priority patent/DE3506118A1/de
Priority to DE3546684A priority patent/DE3546684C2/de
Priority to DE3546662A priority patent/DE3546662C3/de
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to FR8517780A priority patent/FR2578070B1/fr
Priority to JP61031033A priority patent/JP2545508B2/ja
Priority to US06/831,475 priority patent/US5001642A/en
Publication of DE3506118A1 publication Critical patent/DE3506118A1/de
Application granted granted Critical
Publication of DE3506118C2 publication Critical patent/DE3506118C2/de
Priority to US07/856,430 priority patent/US5303348A/en
Priority to JP5302049A priority patent/JPH0721784B2/ja
Priority to JP5302048A priority patent/JPH0772883B2/ja
Priority to US08/185,024 priority patent/US5640511A/en
Priority to US08/464,383 priority patent/US5621888A/en
Priority to US08/465,059 priority patent/US5901156A/en
Granted legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric 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/02—Electric 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/03—Electric 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/0315—Electric 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
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02D—CONTROLLING COMBUSTION ENGINES
    • F02D41/00—Electrical control of supply of combustible mixture or its constituents
    • F02D41/24—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means
    • F02D41/26—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor
    • F02D41/266—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor the computer being backed-up or assisted by another circuit, e.g. analogue
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02P—IGNITION, OTHER THAN COMPRESSION IGNITION, FOR INTERNAL-COMBUSTION ENGINES; TESTING OF IGNITION TIMING IN COMPRESSION-IGNITION ENGINES
    • F02P5/00—Advancing or retarding ignition; Control therefor
    • F02P5/04—Advancing or retarding ignition; Control therefor automatically, as a function of the working conditions of the engine or vehicle or of the atmospheric conditions
    • F02P5/145—Advancing or retarding ignition; Control therefor automatically, as a function of the working conditions of the engine or vehicle or of the atmospheric conditions using electrical means
    • F02P5/15—Digital data processing
    • F02P5/1502—Digital data processing using one central computing unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0745—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an input/output transactions management context
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0763—Error or fault detection not based on redundancy by bit configuration check, e.g. of formats or tags
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
    • G06F13/374—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control using a self-select method with individual priority code comparator
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0079—Formats for control data
    • H04L1/0082—Formats for control data fields explicitly indicating existence of error in data being transmitted, e.g. so that downstream stations can avoid decoding erroneous packet; relays
    • 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/40143—Bus networks involving priority mechanisms
    • H04L12/40163—Bus networks involving priority mechanisms by assigning priority to messages according to a message field
    • 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/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L25/00—Baseband systems
    • H04L25/02—Details ; arrangements for supplying electrical power along data transmission lines
    • H04L25/026—Arrangements for coupling transmitters, receivers or transceivers to transmission lines; Line drivers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0094—Bus
    • 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
    • H04L25/00—Baseband systems
    • H04L25/02—Details ; arrangements for supplying electrical power along data transmission lines
    • H04L25/0264—Arrangements for coupling to transmission lines
    • H04L25/0272—Arrangements for coupling to multiple lines, e.g. for differential transmission
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/10—Internal combustion engine [ICE] based vehicles
    • Y02T10/40—Engine management systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mechanical Engineering (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Power Engineering (AREA)
  • Small-Scale Networks (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)
  • Regulating Braking Force (AREA)

Description

Die Erfindung geht aus von einem Verfahren zum Betreiben einer Daten­ verarbeitungsanlage bzw. zum Aufbau von Botschaften nach der Gattung des Hauptanspruchs. In den letzten Jahren wurde die Funktion des Kraftfahrzeuges durch elektronische Steuerungen wesentlich verbessert. Durch eine digitale Motorelektronik konnte z. B. der Kraftstoffver­ brauch reduziert und die Emission von Schadstoffen verringert werden.
Weitere Funktionsverbesserungen sind für das Kraftfahrzeug in Zukunft insbesondere dadurch zu erreichen, daß die Steuerfunktionen nicht mehr einzeln für sich arbeiten, sondern untereinander vermascht werden. Die Schaltvorgänge eines elektronisch gesteuerten Automatikgetriebes las­ sen sich z. B. mit geringem Verschleiß der Kupplungsbelege und ohne störbarem Druck durchführen, wenn im Schaltaugenblick das Motormoment durch einen entsprechenden Eingriff in die elektronische Motorsteue­ rung kurzzeitig reduziert wird.
Dazu ist es erforderlich, daß der Rechner für die elektronische Ge­ triebesteuerung genau im richtigen Zeitpunkt entsprechende Daten an den Rechner für die elektronische Motorsteuerung überträgt. Bislang wurde dies mit Hilfe einer Reihe von einzelnen Signalleitungen er­ reicht.
1. Stand der Technik
Die Anzahl derartiger Signalleitungen wird jedoch bei umfangreicheren Systemen zu groß. Man benötigt deshalb in diesem Fall eine schnelle Datenübertragung zwischen den im Kraftfahrzeug installierten Rechnern, die wenig Anschlüsse im Steuergerätstecker benötigt und bei der die Information in kodierter Form übertragen wird. Es ist bereits bekannt, lokale Netzwerke zur Kopplung von Mikroprozessoren, Minirechnern und Peripheriegeräten insbesondere für nachrichtentechnische Anwendungen zu betreiben. So gibt es bereits eine große Anzahl verschiedener Über­ tragungsprotokolle für die Kopplung von Mikrorechnern wie z. B. DDB, IIC, MUART, CSMA, SDLC und HDLC. Diese Protokolle wurden beispiels­ weise in den Druckschriften Valvo, DDB-Spezifikation; Valvo, Techni­ sche Information für die Industrie 8 11 215; Intel, Microprozessor and Peripheral Handbook, 1983 und A. Tannenbaum, Computer Networks, Pren­ tin/Hall International, 1983 vorgestellt.
2. Nachteile des Stands der Technik
In den obengenannten Protokollen sind die Anforderungen für eine Steuergerätekopplung nur ungenügend berücksichtigt. Während in der Nachrichten- und Rechnertechnik größere Datenpakete übertragen werden, ist die typische Länge der Datenpakete bei der Übertragung zwischen Steuergeräten klein. Insbesondere im Kraftfahrzeug werden nämlich zwi­ schen Steuergeräten, Sensoren und Stellern vorzugsweise Meßwerte, Zwischenergebnisse von Rechenalgorithmen und Signale zur zeitlichen Synchronisation ausgetauscht. Für diese Anwendungen ergeben sich kurze Datenworte, so daß die bei größeren Datenpaketen üblichen Sicherungs­ maßnahmen nicht verwendet werden können.
Die Steuerungen arbeiten auch meist unter Echtzeitbedingungen, d. h. die Rechenoperation und Steuereingriffe müssen in bestimmten Zeit­ fensters erfolgen, schritthaltend mit den Prozessen. Für ein lokales Netzwerk ergibt sich daraus die Forderung, daß die Übertragungsleitung nach einer kurzen Latenzzeit für wichtige Botschaften frei sein muß, um zu lange Verzögerungen zu vermeiden.
Beim genormten Ethernet-Protokoll dauert allein die Übertragung einer einzigen Botschaft mindestens 580 Mikrosekunden, sowohl dort eine Übertragungsrate von 10 MHz vorgesehen ist. Erst nach dieser Zeit ist der Bus zur Übertragung weiterer Botschaften frei. Beginnen mehrere Busteilnehmer gleichzeitig mit der Übertragung, so kommt es zu einer Kollision mehrerer Botschaften auf dem Netzwerk. Der Zugriffskonflikt wird gelöst, indem sich zunächst alle Sender zurückziehen und erst nach einer statistischen Wartezeit erneut mit der Übertragung begin­ nen. Durch diese Maßnahme sind jedoch auch wiederholte Buszugriffs­ konflikte nicht auszuschließen. Dadurch wird das zuverlässige Einhal­ ten von harten Zeitbedingungen, wie sie bei Kraftfahrzeugsteuerungen er­ forderlich sind, unmöglich.
Weiterhin passiert es oft, daß sich die Konfiguration eines lokalen Netzwerkes und die Zahl seiner Teilnehmer ändert. Insbesondere ist es wichtig, daß die bereits am Netzwerk angeschlossenen Rechner mit un­ verändertem Programm arbeiten können, wenn sich an der von ihnen rea­ lisierten Funktion nichts ändert. Bekannte Übertragungssysteme sind jedoch nicht so konzipiert, daß weitere funktionale Verknüpfungen zwi­ schen den Steuergeräten möglich sind. Beispielsweise werden bei dem Protokoll DDB in jeder Botschaft die Sender- und Empfänger-Adressen angegeben. Kommt ein weiterer Netzwerkteilnehmer hinzu, der auch be­ reits auf den Bus übertragene Daten benötigt, so muß in entspre­ chenden, bereits vorhandenen Teilnehmern die neue Adresse ergänzt werden. Zusätzlich müssen die bereits zu anderen Teilnehmern übertragenen Da­ ten nochmals auch zu dem neuen Teilnehmer gesendet werden. Ändert man daher die Struktur des Netzwerkes, sind daher für jeden Teilnehmer neue Programmvarianten erforderlich.
Viele bekannte Netzwerke, z. B. auf Basis des Intel-Mikroprozessors 8044 (HDLC/SDLC-Protokoll), arbeiten nach dem sogenannten Master Slave-Prinzip, d. h. nur einer der Teilnehmer, der Master, hat zu einem Zeitpunkt die Berechtigung zum Buszugriff. Dadurch vermeidet man Kol­ lision auf den Bus.
Im allgemeinen wird die Master-Eigenschaft nacheinander von einem Bus­ teilnehmer zu einem anderen weitergegeben. Bei vielen Anwendungen ist ein derartiges Verfahren aber nachteilig. Ein Teilnehmer kann nämlich nur dann senden, wenn er gerade im Besitz der Sendeberechtigung ist. Dadurch können gegebenenfalls nicht tolerierbare lange Wartezeiten in den Slaves entstehen, bis eine Botschaft hoher Priorität übertragen wird. Bei schnellen Datenübertragungsanforderungen ist daher dieses System nicht anwendbar. Ungünstig ist das Master-Slave-Konzept auch bei elektromagnetischen Störungen, wie sie gerade im Kraftfahrzeug bekanntlich häufig auftreten. Dabei kann z. B. die Sendeberechtigung durch eine Störung verloren gehen oder irrtümlicherweise ein weiterer Teilnehmer eine Sendeberechtigung erlangen. Die Bewältigung solcher Störfälle ist zwar im Prizip möglich, erfordert aber viel Zeit (Bus­ ausfallzeit, CPU-Rechenzeit) und Aufwand, was im Hinblick auf die Echtzeitanforderungen bei der schnellen Datenübertragung nur schlecht tragbar ist.
Ein weiteres Problem bei vielen bekannten Netzwerken ist die Synchro­ nisation von Ereignissen. Sollen z. B. durch Übertragung einer Bot­ schaft an zwei oder mehrere Teilnehmer gleichzeitig Aktionen ausge­ löst werden, so muß die Botschaft von allen im genau gleichen Augen­ blick empfangen werden. Bei der sonst üblichen zeitlich aufeinander­ folgenden Übertrag von Botschaften zu den einzelnen Empfängern (Punkt zu Punkt-Verbindung) ist die Gleichzeitigkeit des Empfangs einer gültigen Botschaft prinzipiell nicht zu erreichen. Häufig sind auch gleiche Botschaften an verschiedenen Empfänger zu senden. Der gleichzeitige Empfang durch einen angesprochenen Teilnehmer würde in diesen Fällen die Belegung des Netzwerkes beträchtlich reduzieren. Dieses Vorgehen wird aber von den bekannten Schnittstellenbausteinen nicht ermöglicht. Eine weitere wesentliche Voraussetzung ist eine lei­ stungsfähige Fehlererkennung. Selbst die aufwendigeren der heute be­ kannten Protokolle sind jedoch nicht in der Lage, ohne zusätzlichen Ab­ sicherungsprogramme auf Benutzerebene (z. B. Mehrfach-Übertragung) eine ausreichende Übertragungssicherheit zu gewährleisten. So kann beim HDLC-Protokoll bereits ein Einzelbitfehler zu einer nicht erkennbaren Verfälschung der Botschaft führen, obwohl diese durch einen CRC-Check mit 16 Bitlängen abgesichert wird.
Aus dem Artikel 4. International Conference on Automotive Electro­ nics, 14. bis 18. November 1983, Institution of Electrical Engineers, London und New York, 1983, Seite 160 bis 164 ist ein Verfahren zum Be­ treiben einer Datenverarbeitungsanlage mit wenigstens zwei Rechnern und mit die Rechner verbindenden Leitungen zur Übertragung von Bot­ schaften bekannt, wobei die Botschaft selbst einen Kopfteil und einen Datenteil aufweist und der Kopfteil am Anfang der Botschaft steht. Der Kopfteil hat hier die Aufgabe einer Stationsidentifikation. Dies be­ deutet, daß vom Sender im Kopfteil die Station angegeben wird, an die die Nachricht gesendet werden soll. Dies bedetuet jedoch, daß unter Umständen an jede Station die gleiche Nachricht geschickt werden muß, wenn an mehrere Stationen die gleiche Nachricht zu übertragen ist. Das dort gezeigte Verfahren ist daher relativ zeitaufwendig, ermöglicht keine Synchronisation und ein entsprechendes Netzwerk ist nicht er­ weiterbar.
Aus der Zeitschrift Elektronik Application, 15, Jahrgang, 1983, Nr. 5, Seite 17 bis 24 ist ein Bussystem in Verbindung mit einem Kraftfahr­ zeug bekannt geworden. Bei diesem Bussystem handelt es sich um ein Master-Slave-System, das mit den oben erwähnten Unzulänglichkeiten behaftet ist.
Schließlich zeigt die CH-PS 27 547 ein Verfahren zur Informationsüber­ tragung mit Prioritätsschema in einem Zeitmultiplex-Nachrichtenüber­ tragungssystem mit Ringleitung.
Dem Datenteil der Information ist ein Zuteilungsfeld, ein Anforde­ rungsfeld sowie ein Adreßteil zugeordnet. Hierbei dient der Adreß­ teil dazu, eine bestimmte Station des Teilnehmerfeldes anzusprechen. Sollen daher mehrere Stationen die gleiche Nachricht erhalten, muß die Nachricht mehrmals an die unterschiedlichen Stationen übertragen wer­ den, was die zeitliche Busbelegung sowie den Übertragungsaufwand er­ höht.
Ausgehend vom aufgezeigten Stand der Technik ist es Aufgabe der Erfin­ dung, ein Verfahren zur Datenübertragung sowie ein Verfahren zum Auf­ bau einer Botschaft anzugeben, mittels dem eine sehr schnelle Übertra­ gungsgeschwindigkeit zu erzielen ist.
Diese Aufgabe wird durch die kennzeichnenden Merkmale des Hauptan­ spruchs gelöst.
3. Vorteile der Erfindung
Die erfindungsgemäßen Verfahren mit den kennzeichnenden Merkmalen der Ansprüche 1 und 2 haben demgegenüber den Vorteil, daß der Identifi­ zierer nicht stationsbezogen ist, sondern den Inhalt und die Priorität der Botschaft festlegt. Durch diese Maßnahme wird erreicht, daß bei einem Buszugriff eines Rechners bereits bei der Übertragung des Kopf­ teils erkannt wird, ob aufgrund der Priorität der übertragenen Funk­ tion der Buszugriff berechtigt ist. Durch die weitere Ausbildung des Kopfteils als Datenname wird erreicht, daß jeder der angeschlossenen Teilnehmer aufgrund das Datennamens entscheiden kann, ob er die zur Übertragung anstehende Information gebrauchen kann und übernehmen möchte oder nicht. Durch diese Maßnahme wird erreicht, daß eine Bot­ schaft nur einmal übertragen werden muß, auch wenn sie für mehrere Emp­ fänger bestimmt ist. Soll daher durch die Botschaft bei mehereren Teil­ nehmern gleichzeitig eine Aktion ausgelöst werden, so ist es aufgrund der erfindungsgemäßen Maßnahme sehr leicht möglich, synchrone Aktionen in den Empfängern auszulösen, da der Beginn oder ein sonstiger Ab­ schnitt der Übertragung der Botschaft als Synchronisationspunkt für die unterschiedlichen Empfänger bzw. Steuergeräte dienen kann. Als weiterer Vorteil ist anzusehen, daß die Datenverarbeitungsanlage durch beliebige Sender und Empfänger ergänzbar ist, da die Stationen nicht direkt angesprochen werden, sondern lediglich die Art der Information gekennzeichnet ist, so daß auch zusätzliche Empfänger die Auswahl treffen können, ob sie diese Informationen empfangen wollen. Weiterhin können zusätzliche Sender weitere Informationen auf den Datenbus brin­ gen, wobei es dann den angeschlossenen Empfängern überlassen bleibt, ob sie diese Information auswerten wollen oder nicht. Es wird also er­ reicht, daß sich die zu übertragenen Botschaften bezüglich ihres In­ haltes mit Hilfe des Kopfteils selbst identifizieren und sich gleich­ zeitig eine Priorität zuordnen.
Durch die in den Unteransprüchen aufgeführten Maßnahme sind vorteil­ hafte Weiterbildungen und Verbesserungen des im Hauptanspruch angege­ benen Verfahren möglich. Besonders vorteilhaft ist es, daß der Iden­ tifizierer Datennamen wie Adressen, Daten, Sensorsignale und anderes kennzeichnet. Durch die Vielzahl der möglichen Datennamen wird er­ reicht, daß nicht nur Signalinformationen wie Spannungen oder Ströme übertragbar sind, sondern daß beispielsweise auch Einsprungadressen für ein Programm oder Synchronisationsbefehle, beispielweise wenn bei einer Kraftfahrzeug-Anwendung der obere Totpunkt eines Zylinders pas­ siert wird, aussendbar sind. Eine besonders einfache Möglichkeit der Prioritätsregelung ist darin zu sehen, daß die höhere Priorität der Botschaft dadurch bestimmt ist, daß in bezug auf den Kopfteil anderer Botschaften das erste unterschiedliche Bit dominant ist. Durch diese Maßnahme wird erreicht, daß die prioritätshöhere Botschaft bei der Übertragung nicht abgebrochen werden muß, sondern aufgrund der Identi­ tät mit den sonstigen Botschaften auf dem Bus bis zu deren Abbruch einfach weiter übertragen werden kann, während sich die Botschaften, bei denen das erste unterschiedliche Bit nicht dominant ist, vom Datenbus zurückzuziehen. Durch diese Maßnahme wird erreicht, daß selbst bei einer Datenkollision bei der Datenübertragung keine Zeit verloren geht, sondern die Übertragung der prioritätshöheren Botschaft weiter­ geführt wird.
Besonders sicher wird die Datenübertragung auch dadurch, daß die Bot­ schaften bipolar übertragen werden. Weiterhin ist vorteilhaft, daß die Botschaft von allen Rechnern gleichzeitig empfangen wird, daß jeder Rechner eine Liste der für ihn relevanten Botschaften enthält, daß zu­ mindest ein Teil des Kopfteils der Botschaft mit der Liste verglichen wird und daß eine Botschaft nur dann weiter verarbeitet wird, wenn dieser Teil in der Liste gefunden wird. Dadurch wird erreicht, daß die entsprechenden Empfänger nicht die gesamte Botschaft empfangen müssen und danach erst auswerten, ob diese Botschaft für sie relevant ist, sondern bereits zu einem frühen Zeitpunkt festgestellt werden kann, so die gerade übertragenen Botschaft für den Empfänger von Interesse ist oder nicht. Ist dieses Interesse nicht vorhanden, kann der Empfänger die weitere Übertragung derselben Botschaft ignorieren und die ihm übertragenen Aufgaben wahrnehmen.
4. Ausführungsbeispiel 4.1 Auflistung der einzelnen Figuren der Zeichnung
Fig. 1 Ausführungsbeispiel für lineare Busstruktur
Fig. 2 Beispiel für galvanisch gekoppelte, asymmetrische Ansteuerung der Busleitung
Fig. 3 Beispiel für galvanisch gekoppelte, symmetrische Ansteuerung der Busleitung
Fig. 4 Beispiel für galvanisch getrennte, symmetrische Ansteuerung mit Übertrager
Fig. 5 Ausführungsbeispiel für Lichtleiter-Stern
Fig. 6 Ausführungsbeispiel für Lichtleiter-Bus
Fig. 7 Aufbau einer Botschaft
Fig. 8 Aufbau CONTROL-FIELD
Fig. 9 Aufbau CRC-FIELD
Fig. 10 Aufbau einer Fehlermeldung
Fig. 11 Blockschaltbild des Schnittstellen-Bausteins
4.2 Physikalische Realisierung
Tabelle 1 zeigt die möglichen Bustopologien, Ankopplungs- und Leitungsarten in Abhängigkeit von dem gewählten Übertragungsmedium.
Tabelle 1
Übertragungsart:
Zeitmultiplex Basisbandübertragung
Zugriffsart:
Multimaster-Prinzip deterministische Buszuteilung
räumlliche Ausdehnung:
von Übertragungsrate abhängig
Das vorgestellte Bussystem kann genau realisiert werden, wenn auf dem Übertragungsmedium zwei Zustände mit den Eigenschaften dominant bzw. rezessiv möglich sind.
Beispiele hierfür sind:
Beispiele für Impedanz:
Schalter geschlossen/offen
Transistor leitend/nicht leitend
Beispiele für Energie:
Spannung liegt an/liegt nicht an
Licht an/aus
Fig. 1 zeigt die Ausführung als lineares Bussystem. Das System besteht aus einer durchgehenden Busleitung (Adernpaar oder Lichtleiter) und Anschlußleitungen, die zu den einzelnen Teilnehmern gehen.
Fig. 2 zeigt eine Ausführung mit galvanischer Ankopplung an die Busleitung. Die Treiber sind steuerbar Schalter, realisiert durch Transistoren (Open-Collector-Ankopplung). Als Busleitung dient eine Zweidrahtleitung oder ein Koaxkabel. Die Ansteuerung erfolgt asymmetrisch. Am Ende der Busleitung wird über Widerstände eine Versorgungsspannung angelegt. Der dominante Buszustand liegt dann vor, wenn mindestens ein Treibertransistor leitet.
Fig. 3 zeigt eine Ausführung, bei der als Sendetreiber zwei komplementäre Treibertransistoren eingesetzt werden, die gleichzeitig leitend bzw. sperrend gesteuert werden. Die Leitung wird dadurch symmetrisch angesteuert. Der Vorteil dieser Anordnung liegt in einer höheren Störfestigkeit und in einer niedrigeren Störabstrahlung.
Bei den oben gezeigten Ausführungen ist die Busleitung galvanisch mit den einzelnen Stationen verbunden. Dadurch können in elektrisch bzw. in elektromagnetisch gestörter Umgebung Probleme auftreten, wenn die Stationen über weitere Leitungen (z. B. Stromversorgungen) verkoppelt sind. Die folgenden Beispiele weisen diesen Nachteil nicht auf.
Fig. 4 zeigt eine Ausführung, bei der zur galvanischen Trennung Überträger eingesetzt werden. Die Gleichstromfreiheit wird durch eine Biphase-Kodierung gewonnen. Der rezessive Buszustand wird durch Abkopplung aller Überträger von ihren Treibern erreicht (Treiber hochohmig schalten). Der dominante Buszustand wird durch das Aufschalten eines positiven oder eines negativen Impulses auf mindestens einen der Übertrager erreicht. Die Synchronisierung der Impulspolarität geschieht über die Festlegung der Startbitpolarität.
Eine weitere Ausführungsform mit galvanisch getrennter Ankopplung kann durch den Einsatz von Optokopplern erreicht werden. Besonders einfach wird dies durch den Einsatz von Optokopplern mit Open-Collector-Ausgängen.
Fig. 5 zeigt als Beispiel für eine Ausführung mit Lichtleitern ein Sternsystem mit einem zentralen optischen Koppler. Die Verkopplung kann passiv oder mit elektrooptischen Wandlern ausgeführt werden.
Dominanter Buszustand: mindestens eine Sendediode leuchtet.
Rezessiver Buszustand: alle Sendedioden dunkel.
Fig. 6 zeigt als Beispiel für eine Ausführung mit Lichtleitern ein lineares Bussystem. Die Anschlußleitungen sind mit der zentralen Busleitung so verbunden, daß zur Ein- und Auskopplung von Licht keine aufwendigen passiven oder elektrooptischen Wandler benötigt werden. Ein Beispiel ist die Verschmelzung von zentraler Busleitung und Anschlußleitung.
Dominanter Buszustand: mindestens eine Sendediode leuchtet.
Rezessiver Buszustand: alle Sendedioden dunkel.
4.3. Übertragungsprotokoll
Eine Botschaft besteht aus den Bitfeldern START-OF-FRAME, IDENTIFIER, CONTROL-FIELD, DATA-FIELD, CRC-FIELD, ACK-FIELD, END-OF-FRAME und INTERMISSION (siehe Fig. 6)
Hinweis:
  • In dieser Beschreibung werden die Begriffe HIGH und LOW im Sinne logischer Pegel verwendet.
  • Während HIGH in seiner Wirkung auf dem Bus rezessiv ist, ist LOW dominant. Das hat zur Folge, daß von allen Busteilnehmern LOW empfangen wird, sofern mindestens einer von mehreren Busteilnehmern LOW sendet.
START-OF-FRAME
markiert den Botschaftsanfang und besteht aus einem einzigen LOW Bit.
Ein Busteilnehmer darf nur im Zustand BUS-IDLE (siehe Abschnitt 4.5), d. h. wenn der Bus frei ist, die Übertragung einer Botschaft beginnen. Alle Empfänger synchronisieren sich auf die führende, durch START-OF-FRAME verursachte Flanke.
IDENTIFIER
kennzeichnet den Inhalt des Datenfeldes (DATA-FIELD) im Sinne eines Namens und einer Priorität.
Der IDENTIFIER hat nicht zwangsläufig die Bedeutung einer Adresse, die einen einzigen Empfänger aus einer Vielzahl von Busteilnehmern bestimmt. Ob eine korrekt empfangene Botschaft von den Busteilnehmern weiter bearbeitet wird oder nicht, wird ausschließlich durch das AKZEPTANZ-FILTER (siehe Abschnitt 4.7.1.1.3.) eines jeden Busteilnehmers bestimmt. Aus der Sicht eines Senders gibt es deshalb keinen Unterschied zwischen einer Punkt zu Punkt - Übertragung und der gleichzeitigen Ansprache einiger oder aller Busteilnehmer.
Bei gleichzeitig Buszugriff mehrerer Sender wird während der Arbitrierungsphase anhand der Priorität bestimmt, welcher der Sender das Recht zur weiteren Übertragung der Botschaft erhält (siehe Abschnitt 4.4.).
Im vorliegenden Ausführungsbeispiel ist der IDENTIFIER acht Bit lang.
(IFL = IDENTIFIER-FIELD-LENGTH = 8)
CONTROL-FIELD
umfaßt die Bitfelder REMOTE-TRANSMISSION-REQUEST, DATA-BYTE-CODE und für zukünftige Erweiterungen reservierte Bits.
REMOTE-TRANSMISSIONS-REQUEST zeigt an, ob durch die entsprechenden Botschaft Daten übertragen oder angefordert werden sollen. DATA-BYTE-CODE enthält Information über die Länge des Datenfeldes.
In dem vorliegenden Ausführungsbeispiel ist das CONTROLL-FIELD acht Bit lang.
(CFL = CONTROL-FIELD-LENGTH = 8)
DATA-FIELD
enthält die zu übertragende Information, deren Bedeutung durch den IDENTIFIER festgelegt ist. Die Länge dieses Feldes (DATA-BYTE-COUNT) ist variabel und kann z. B. ein, zwei, vier oder acht Bytes betragen.
DATA-BYTE-COUNT = 2** DATA-BYTE-CODE
DFL = DATA-FIELD-LENGTH = 8* DATA-BYTE-COUNT
CRS-FIELD
Dieses Bitfeld enthält das mittels eines Generators- Polynoms erzeugter Kontrollwort (CRC-SEQUENCE), es wird mit einem CRC-DELIMITER abgeschlossen (Fig. 9).
Das Generator-Polynom ist für kleine Botschaftslängen (kleiner 120 zu sichernde Bits) ausgewählt, womit eine höhere Hamming-Distanz erreicht wird wie bei der Absicherung langer Botschaften mit der gleichen Anzahl von Kontrollbits.
In dem vorliegenden Ausführungsbeispiel ist die CRC-SEQUENCE 15 Bits lang.
(CRCL = CRC-SEQUENCE-LENGTH = 15)
Durch das Kontrollwort werden die Felder START-OF-FRAME, IDENTIFIER, CONTROL-FIELD, DATA-FIELD und CRS-SEQUENCE (ohne CRC-DELIMITER) gesichert.
CRC-DELIMITER
Der CRC-DELIMITER besteht aus einem HIGH Bit, er folgt auf das CRC-Kontrollwort und schließt das CRC-FIELD ab.
Zyklische Codes können solche Fehler nicht aufdecken, die sich auf die zyklische Verschiebung des gesamten Codewortes (zu sichernde Bits und Sicherungsbits) zurückzuführen lassen. Eine zyklische Verschiebung ergibt nämlich wieder ein gültiges Codewort.
Wird jedoch das Bit START-OF-FRAME, das per Definition LOW ist, in das Codewort einbezogen, kann jede Rotation des Codewortes daran erkannt werden, daß das CRC-FIELD nicht mit HIGH abgeschlossen wird.
ACK-FIELD
Alle Empfänger teilen dem Sender den Empfang einer korrekten Botschaft dadurch mit, daß sie als erstes Bit in diesem Fenster ein LOW-Bit übertragen. Als zweites Bit wird HIGH (ACK-DELIMITER) übertragen. Der Sender kann auf diese Art und Weise erkennen, ob zumindest einer der Busteilnehmer die Botschaft fehlerfrei empfangen hat.
Alle diejenigen Busteilnehmer, die eine fehlerhafte Botschaft empfangen haben, melden dies mittels eines ERROR-FLAG.
Erhält der Sender keine Bestätigung für den korrekten Empfang seiner Botschaft durch zumindest einen Empfänger so setzt er selbst eine Fehlermeldung ab.
END-OF-FRAME
besteht aus einer ununtzerbrochenen Folge von HIGH Bits und steht am Ende einer jeden Botschaft.
Die Länge von END-OF-FRAME ist so zu wählen, daß all diejenigen Empfänger, die aufgrund einer fehlerhaften Übertragung der Längeninformation an dieser Stelle Daten erwarten, bereits beim zweitletzten Bit von END-OF-FRAME einen Stuffehler feststellen (siehe KODIERUNG). Unabhängig von vorangegangenen Übertragungsfehlern kann so jeder Busteilnehmer das Ende einer Botschaft erkennen.
Tastet der Sender während END-OF-FRAME zumindest ein LOW Bit (z. B. Bit von ERROR-FLAG) auf dem Bus ab, so wird dies von dem zuletzt aktiven Sender als Reaktion auf die soeben von ihm übertragene Botschaft angesehen. Dadurch besteht eine eindeutige Zuordnung von Fehlermeldungen, auch wenn der Fehlerzustand erst mit der Übertragung des zweitletzten Bits einer Botschaft durch einen der Empfänger erkannt wird.
In dem vorliegenden Ausführungsbeispiel ist END-OF-FRAME sieben Bits lang.
(EOFL = END-OF-FRAME-LENGTH = 7)
INTERMISSION
besteht aus einer ununterbrochenen Folge von HIGH Bits. In dieser Zeit darf keiner der Busteilnehmer die Übertragung einer neuen Botschaft beginnen.
Während INTERMISSION hat jeder Empfänger die Möglichkeit, eine Überlastung (fehlende Empfangsbereit­ schaft) durch Senden eines ERROR-FLAG zu melden, so daß das Absenden der nächsten Botschaft verzögert wird, bis alle Empfänger wieder bereit sind.
Eine in INTERMISSION fallende Fehlermeldung wird genauso wie die in andere Bitfelder fallenden Fehlermeldungen behandelt. Eine Wiederholung vorangegangenen Botschaft durch den entsprechenden Sender erfolgt jedoch nicht.
In dem vorliegenden Ausführungsbeispiel ist INTERMISSION drei Bit lang.
(IML = INTERMISSION-LENGTH = 3)
BUS-IDLE
Der Bus ist frei, wenn er nach Ablauf von INTERMISSION weiterhin HIGH-Pegel führt. Der Zustand BUS-IDLE kann von beliebiger Dauer sein. Der Empfang eines LOW Bits wird als START-OF-FRAME interpretiert.
Eine Fehlermeldung besteht aus dem Bitfeldern ERROR-FLAG und ERROR-DELIMITER (siehe Fig. 0)
ERROR-FLAG
besteht aus einer ununterbrochenen Folge von LOW-Bits.
Die Länge der Folge ist so zu bestimmen, daß durch sie das Gesetz des "Bitstuffing" verletzt wird, das auf alle Bitfelder von START-OF-FRAME bis CRC-DELIMITER angewendet wird. Die anderen Busteilnehmer reagieren darauf, indem sie selbst eine Fehlermeldung senden.
In dem vorliegenden Ausführungsbeispiel ist das ERROR-FLAG sechs Bit lang.
(EFL = ERROR-FLAG-LENGTH = 6)
ERROR-DELIMITER
Jede Fehlermeldung wird mit einer ununterbrochenen Folge von HIGH Bits abgeschlossen.
Der Sendevorgang des ERROR-DELIMITER beginnt, nachdem auch alle anderen Teilnehmer mit der Übertragung des ERROR-FLAG fertig sind (LOW nach HIGH Übergang auf dem Bus).
Im vorliegenden Ausführungsbeispiel ist der ERROR-DELIMITER sieben Bit lang.
(EDL = ERROR-DELIMITER-LENGTH = 7)
4.4. Bus-Organisation
Die Organisation des Busverkehrs beruht auf folgenden fünf Regeln:
(1) BUS-ZUGRIFF
Die Busteilnehmer dürfen nur im Zustand BUS-IDLE die Üpbertragung einer Botschaft starten.
Alle Empfänger müssen auf die führende Flanke von START-OF-FRAME synchronisieren.
(2) ARBITRIERUNG
Beginnen zwei oder mehr Busteilnehmer gleichzeitig mit der Übertragung, wird der Zugriffskonflikt durch einen Arbitrierungsmechanismus auf Bitebene gelöst.
Während der Arbitrierung vergleicht jeder Sender den Bitpegel, den er selbst auf den Bus schreibt, mit demjenigen, den er tatsächlich auf dem Bus abtastet. Alle diejenigen Sender, die nicht den von ihnen selbst gesendeten Buspegel vorfinden, müssen die Übertragung ohne auch nur ein weiteres Bit zu senden einstellen. Durch diese Vereinbarung kann der Arbitrierungsvorgang ablaufen, ohne daß irgendwelche Information auf dem Bus zerstört wird. Derjenige Sender, dessen Botschaft den IDENTIFIER mit der höchsten Priorität aufweist, gewinnt den Buszugriff. Er überträgt die begonnene Botschaft zu Ende.
(3) KODIERUNG
Die Botschaftssegmente START-OF-FIELD, IDENTIFIER, CONTROL-FIELD, DATA-FIELD und CRC-FIELD werden nach der Methode des Bitstuffing kodiert. Treten in dem zu übertragenden Datenstrom in ununterbrochener Reihenfolge fünf gleiche Bits auf, so fügt der Sender automatisch ein Bit mit umgekehrter Wertigkeit in den Bitstrom ein.
(4) DEKODIERUNG
Die Botschaftssegmente START-OF-FIELD, IDENTIFIER, CONTROL-FIELD, DATA-FIELD und CRC-FIELD werden nach der Methode des Bitstuffing kodiert. Empfängt ein Busteilnehmer fünf gleiche Bitpegel in ununterbrochener Reihenfolge, so entfernt dieser das nachfolgende Stuffbit aus dem Bitstrom. Die Wertigkeit des Stopfbits muß invers zu der der voran gegangenen Bits sein (Fehlerprüfung).
(5) FEHLERMELDUNG
Jeder Busteilnehmer, der einen Übertragungsfehler feststellt, teilt dies allen anderen Busteilnehmern mit, indem er sechs aufeinander folgende LOW Bits (ERROR-FLAG) sendet.
Die Fehlermeldung erfolgt sofort nach einem erkannten Fehler, d. h. beginnend mit dem auf den Fehlerzustand folgenden Bit. Nur bei Erkennung eines CRC-Fehlers wird die Fehlermeldung erst drei Takte später abgeschickt. Dadurch wird sichergestellt, daß das ACK-FIELD nicht durch eine von einem CRC-Fehler ausgelöste Fehlermeldung überschrieben wird.
Die Fehlermeldung wird durch einen Übergang von LOW nach HIGH nach mindestens sechs LOW Bits auf dem Bus beendet (siehe Zustandsdiagramm zur Fehlerbehandlung)
(6) ÜBERLAST
Bei Überlastung (empfangene Botschaft ist noch nicht bearbeitet) hat jeder Busteilnehmer die Möglichkeit, durch Senden eines ERROR-FLAG während INTERMISSION dies allen anderen Teilnehmern zu melden (siehe INTERMISSION).
4.5. Zustandsdiagramme 4.5.1. Erläuterungen zu den Zustandsgraphen
Jeder Rechteckrahmen stellt einen Systemzustand dar. Die Übergänge zwischen den Zuständen, die von Eingangs- und Zustandsvariablen abhängen, sind durch gerichtete Verbindungslinien dargestellt. Die Zustandsübergänge erfolgen stets mit der aktiven Flanke des Bustaktes. Mit der gleichen Taktflanke werden Ausgangsdaten auf die Busleitung gelegt. Der tatsächliche Buspegel wird erst kurz vor der nächsten aktiven Bustaktflanke abgetastet.
Nach einem BUS-IDLE Zustand wird der Bustakt auf den nächsten Buspegelübergang von HIGH nach LOW synchronisiert.
Die Eingangs- und Zustandsvariablen können geordnet und zu einem Entscheidungsvektor zusammengefaßt werden.
Der Entscheidungsvektor hat folgende Form:
(BUS-MONITOR; BUS-DRIVE, STUFF, COUNT, TX-REQUEST, CRC-ERROR, OVERLOAD)
Es bedeutet:
BUS-MONITOR
Eingangsvariable, die den auf der Busleitung abgetasteten Logikpegel wiederspiegelt.
BUS-MONITOR = 0 entspr. dominantem Buspegel (LOW)
BUS-MONITOR = 1 entspr. rezessivem Buspegel (HIGH)
BUS-DRIVE
Zustandsvariable, die den Logikpegel angibt, der in diesem Zustand gesendet wird.
BUS-DRIVE = 0 Sendepegel dominant (LOW)
BUS-DRIVE = 1 Sendepegel rezessiv (HIGH)
STUFF
Eingangsvariable, die angibt, ob der Buspegel während der letzten fünf Tage Abtasttakte konstant war (fünfmal LOW oder fünfmal HIGH). Der Pegel, den BUS-MONITOR angibt, ist der aktuellste Wert dieser Fünferkette.
STUFF = 0 Buspegel hat gewechselt
STUFF = 1 Buspegel war konstant
COUNT
Zustandsvariable, die angibt, ob der interne Zähler (CNTR) abgelaufen ist. Dieser Zähler wird nicht in allen Zuständen benötigt. Falls benötigt, wird der Zähler beim Übergang in den entsprechenden Zustand gesetzt.
COUNT = 0 Zähler noch nicht abgelaufen (CNTR << 0)
COUNT = 1 Zähler abgelaufen (CNTR = 0)
TX-REQUEST
Eingangsvariable, die angibt, ob eine Botschaft zum Absenden, bereit liegt, so daß an der nächsten Buszuteilungsprozedur teilgenommen werden muß.
TX-REQUEST = 0 Sendeauftrag liegt nicht vor
TX-REQUEST = 1 Sendeauftrag liegt vor
CRC-ERROR
Zustandsvariable, die angibt, ob in der empfangenen Botschaft ein Übertragungsfehler vorlag. Die Variable wird nach dem Empfang des letzten Bits der CRC-SEQUENCE gesetzt.
CRC-ERROR = 0 Empfang war fehlerfrei
CRC-ERROR = 1 Übertragungsfehler
OVERLOAD
Zustandsvariable die angibt, ob die letzte empfangene Botschaft von der Schnittstellenlogik aufgearbeitet werden konnte oder ob diese überlastet ist.
OVERLOAD = 0 Empfangslogik überlastet
OVERLOAD = 1 Empfangslogik bereit
Mit dem Entscheidungsvektor ist eindeutig festgelegt, in welchen Folgezustand gegangen wird. Der Zustandsgraph kann deshalb mit Hilfe der Entscheidungsvektoren beschrieben werden. Ist für ein bestimmtes Element im Zustandsvektor ein "x" angegeben, so bedeutet dies, daß die entsprechende Variable für die Entscheidung nicht relevant ist (die Variable darf "0" oder "1" sein).
4.5.2. Beschreibungsbeispiel für den Zustand BUS-IDLE
Der Zustand BUS-IDLE ist der reguläre Folgezustand des Zustands TEST-INTERMISSION. Im Zustand BUS-IDLE wird stets der rezessive Sendepegel HIGH auf die Busleitung gelegt.
Übergänge in Folgezustände:
  • 1) Entscheidungsvektor (1,1,1,x,0,x,x):
    Dieser Entscheidungsvektor bedeutet folgendes: Buspegel HIGH, Sendepegel HIGH, Bus war schon mind. fünf Takte lang HIGH, Zähler nicht relevant, keine Sendeanforderung, Übertragungsfehler und Überlastung nicht relevant. Da keine Busaktion detektiert wurde und keine Sendeanforderung vorlag, ist der Folgezustand wieder BUS-IDLE.
  • 2) Entscheidungsvektor (1,1,1,x,1,x,x):
    Jetzt liegt bei sonst gleichen Variablen wie in 1) eine Sendeanforderung vor. Da die Busleitung frei ist, kann sofort mit dem Senden begonnen werden. Der Folgezustand ist also TRANSMIT-START-OF-FRAME.
  • 3) Entscheidungsvektor (0,1,0,x,x,x,x):
    Auf der Busleitung wurde der Pegel LOW detektiert, das heißt, daß mindestens ein anderer Busteilnehmer begonnen hat, eine Botschaft zu übertragen. Das detektierte, LOW-Bit ist START-OF-FRAME. Der Folgezustand ist RECEIVE-IDENTIFIER.
  • 4) Alle weiteren Entscheidungsvektoren deuten auf eine Hardware-Störung bzw. auf einen Hardware-Ausfall innerhalb des Schnittstellenbausteins hin.
Entsprechendes gilt für alle anderen Systemzustände, die in den Zustandsgraphen EMPFANGSMODUS, SENDEMODUS und FEHLER-BEHANDLUNG beschrieben werden.
Neben den Entscheidungsvektoren, die sich aufgrund von Störungen auf der Busleitung ergeben, werden nur die Vektoren aufgeführt, die bei funktionsfähiger Hardware auftreten können. Die restlichen Vektoren kann man entweder zur Vereinfachung des Steuerwerks ausnützen oder zur Erhöhung der Systemsicherheit in einem Zustand HARDWARE-ERROR behandeln.
4.5.3. Zustandsdiagramm EMPFANGS-MODUS
Aus dem Zustand BUS-IDLE kommt man durch Erkennen von START-OF-FRAME auf dem Bus inden Zustand RECEIVE-IDENTIFIER. Beim Zustandsübergang wird der Zähler CNTR mit IFL=B (IDENTIFIER-FIELD-LENGTH) vorbelegt. IFL gibt an wieviel Kennungsbits vereinbart wurden (siehe 4.3, IDENTIFIER).
Mit jedem empfangenen Kennungsbit wird die Scheife des Zustands RECEIVE-IDENTIFIER einmal durchlaufen und der Zähler wird dekrementiert. Tritt im IDENTIFIER ein Stuffbit auf, so erfolgt aufgrund von STUFF = 1 der Übergang in den Zustand IGNORE-ID-STUFFB. Dort wird das Stuffbit ausgeblendet. Ist danach immer noch STUFF = 1, so muß eine Ausnahmesituation vorliegen (Störung auf Busleitung, Fehlermeldung eines anderen Teilnehmers, unerwartete Busruhe); als Reaktion darauf wird in den Zustand ERROR-HANDLING gegangen. Ist jedoch STUFF = 0, so kann der Rücksprung in den Zustand RECEIVE-IDENTIFIER erfolgen.
Nach Ablaufen des Zählers geht das System (entweder aus dem Zustand RECEIVE-IDENTIFIER oder IGNORE-ID-STUFFB) in den Zustand RECEIVE-CONTROL-FIELD über. Hier wird der Zähler mit CFL=8 (CONTROL-FIELD-LENGTH) vorbelegt.
Sind alle Bits des CONTROL-FIELDS empfangen, so wird als nächstes in Zustand RECEIVE-DATA-FIELD das Datenfeld empfangen. Als Besonderheit gilt hier, daß der Zähler nicht mit einer Konstanten, sondern mit der Variablen DFL (DATA-FIELD-LENGTH) vorbelegt wird. DFL kann die Werte 8, 16, 32 oder 64 annehmen.
Als nächstes wird im Zustand RECEIVE-CRC-SEQUENCE das CRC-Kontrollwort (CRC-SEQUENCE) empfangen. Hierzu wird zunächst der Zähler CNTR mit CRCL=15 (CRC-SEQUENCE-LENGTH) vorbelegt. Nach dem Empfang des letzten CRC-Bits wird die Zustandsvariable CRC-ERROR gesetzt (CRC-ERROR=6 bedeutet kein Fehler, CRC-ERROR=1 bedeutet Fehler im Übertragungsrahmen).
Das CRC-Kontrollwort muß stets durch ein Bit (CRC-DELIMITER) mit dem Pegel HIGH abgeschlossen sein. Dies wird im Zustand RECEIVE-CRC-DELIMITER geprüft. Bei falschem Buspegel wird zum Zustand ERROR-HANDLING gesprungen.
Im nächsten Bustaktzyklus müssen die Empfänger den Empfang der Botschaft bestätigen. Dies geschieht im Zustand SEND-ACKNOWLEDGE durch Senden eines LOW-Pegels für fehlerfreien Empfang bzw. durch Senden eines HIGH-Pegels im Fehlerfall. Beim Entdecken des Buspegels HIGH wird, falls der dominante Pegel LOW gesendet wurde, zum Zustand ERROR-HANDLING übergegangen.
Auf das erste Acknowledge-Bit folgt der ACK-DELIMITER, der stets den Pegel HIGH haben muß. Dieser Pegel wird im Zustand SEND-ACK-DELIMITER von allen Empfängern ausgegeben. Wird der Pegel LOW empfangen, so wird zum Zustand ERROR-HANDLING übergegangen.
Beim Zustandsübergang nach RECEIVE-END-OF-FRAME wird der Zähler CNTR EOFL=7 (END-OF-FRAME-LENGTH) initialisiert. Falls CRC-ERROR=1 ist, oder falls während RECEIVE-END-OF-FRAME der Buspegel LOW empfangen wird, wird zum Zustand ERROR-HANDLING übergegangen.
Im fehlerfreien Fall wurde die Botschaft jetzt vollständig empfangen. Als nächstes folgt der Zustand TEST-INTERMISSION, der aus IML=3 (INTERMISSION-LENGTH) Zyklen besteht. Der Buspegel muß dauernd HIGH sein, sonst wird nach ERROR-HANDLING gesprungen. Im Zustand TEST-INTERMISSION hat jeder Empfänger die Möglichkeit eine Überlastung (OVERLOAD=1) zu melden, so daß das Absenden der nächsten Botschaft verzögert wird, bis der Empfänger wieder bereit ist. Auch dies geschieht durch ERROR-HANDLING: Nach Ablauf des Zählers CNTR wird in den Folgezustand BUS-IDLE übergegangen, mit dem ein neuer Empfangs- oder Sendezyklus beginnt.
Bezüglich der Stuffbits, die in den Feldern CONTROL-FIELD, DATA-FIELD und CRC-SEQUENCE auftreten können, gelten die zum Zustand RECEIVE-IDENTIFIER gemachten Ausführungen entsprechend.
Empfangs-Modus
Entscheidungsvektor:
(Bus-Monitor, Bus-Drive, Stuff, Count, TX-Request, CRC-Error, Overload)
4.5.4. Zustandsdiagramm SENDE-MODUS
Vom Zustand BUS-IDLE aus erfolgt der Übergang in den Sendemodus dann, wenn vor oder während BUS-IDLE eine Sendeanforderung eintrifft (TX-REQUEST=1). Siehe hierzu Zustandsgraph RECEIVE-MODE.
Das Senden einer Botschaft beginnt mit dem Zustand TRANSMIT- START-OF-FRAME, in dem der dominante Sendepegel LOW ausgegeben wird. Falls eine Störung den dominanten Pegel LOW in HIGH verfälscht, wird zum Zustand ERROR-HANDLING übergegangen.
Sonst folgt im Zustand TRANSMIT-IDENTIFIER die Buszuteilungsprozedur. Am Anfang wird der Zähler auf IFL=8 (IDENTIFIER-FIELD-LENGTH) gesetzt.
Im Zustand TRANSMIT-IDENTIFIER wird verblieben (lediglich der Zähler wird dekrementiert), wenn der empfangene Pegel dem gesendeten entspricht und die letzten fünf Buspegel nicht konstant waren und der Zähler noch nicht abgelaufen ist.
Der Zustand TRANSMIT-IDENTIFIER wird verlassen, wenn
  • - der gesendete rezessive HIGH-Pegel durch LOW überschrieben wurde. Die Buszuteilung ist damit verloren. Falls STUFF=1 ist, ist der Folgezustand IGNORE-ID-STUFFB. Sonst ist bei nicht abgelaufenem Zähler der Folgezustand RECEIVE-IDENTIFIER, bei abgelaufenem Zähler RECEIVE-CONTROL-FIELD.
  • - ein gesendeter dominanter LOW-Pegel in HIGH verfälscht wird. Der Folgezustand ist ERROR-HANDLING.
  • - der empfangene Pegel dem gesendeten entspricht. Falls die letzten fünf Pegel gleich waren muß in den Zustand INSERT-ID-STUFFB übergegangen werden. Sonst wird bei abgelaufenem Zähler in den Folgezustand TRANSMIT-CONTROL-FIELD übergegangen. Im letzten Fall wurde die Buszuteilung gewonnen.
Im Zustand INSERT-ID-STUFFB werden die Stuffbits des IDENTIFIER-FIELDS eingefügt. Da in diesem Zustand die Buszuteilung nicht verloren werden kann, ist im Falle von unterschiedlichen Sende- und Empfangs-Pegeln ERROR-HANDLING der Folgezustand. Ansonsten wird bei nicht abgelaufenem Zähler in den Zustand TRANSMIT-IDENTIFIER zurückgegangen, bei abgelaufenen Zähler wurde die Buszuteilung gewonnen, der Folgezustand ist TRANSMIT-CONTROL-FIELD.
Beim Einstieg in den Zustand TRANSMIT-CONTROL-FIELD wird der Zähler CNTR mit CFL=8 initialisiert (CONTROL-FIELD-LENGTH). Da die Buszuteilung beendet ist, muß ab jetzt der Sende- und Empfangs-Pegel stets gleich sein. Ist dies nicht der Fall, so wird in den Zustand ERROR-HANDLING übergegangen. Bei nicht abgelaufenem Zähler und bei Flankenwechsel innerhalb der letzten fünf Taktzyklen bleibt das System im Zustand TRANSMIT-CONTROL-FIELD, lediglich der Zähler wird dekrementiert. Das Einfügen von Stuffbits geschieht im Zustand INSERT-CF-STUFFB. Bei abgelaufenem Zähler erfolgt der Übergang in den Folgezustand TRANSMIT-DATA-FIELD.
Die Vorgänge im Zustand TRANSMIT-CONTROL-FIELD gelten auch für die Zustände TRANSMIT-DATA-FIELD und TRANSMIT-CRC-SEQUENCE. Beim Einstieg in TRANSMIT-DATA-FIELD wird der Zähler CNTR mit der Variablen DFL (DATA-FIELD-LENGTH) vorbelegt, die die Werte 8, 16, 32 oder 64 annehmen kann. Beim Einstieg in TRANSMIT-CRC-SEQUENCE wird der Zähler mit der Konstanten CRCL=15 (CRC-FIELD-LENGTH) vorbelegt.
Im Anschluß an die CRC-SEQUENCE muß der CRC-DELIMITER übertragen werden. Dies geschieht im Zustand TRANSMIT-CRC-DELIMITER. Falls der gesendete HIGH-Zustand nach LOW verfälscht wird, wird in den Zustand ERROR-HANDLING übergegangen.
Als nächstes wird das Acknowledge-Bit geprüft. Ein empfangener HIGH-Pegel bedeutet, daß kein Teilnehmer die Botschaft fehlerfrei empfangen hat oder daß alle Teilnehmer eine falsche Rahmensynchronisation haben. Der Sender gibt deshalb im Zustand ERROR-HANDLING eine Fehlermeldung. Bei empfangenem LOW-Pegel wird in den Folgezustand RECEIVE-ACK-DELIMITER übergegangen. Der ACK-DELIMITER muß stets HIGH sein. Ist dies nicht der Fall, so wird nach ERROR-HANDLING gesprungen.
Das Botschaftsende wird im Zustand TRANSMIT-END-OF-FRAME übertragen. Das END-OF-FRAME aus sieben HIGH-Bits besteht, wird der Zähler CNTR mit EOFL=7 (END-OF-FRAME-LENGHT) vorbelegt. Bei empfangenem HIGH-Pegel bleibt das System im Zustand TRANSMIT-END-OF-FRAME, bis der Zähler abgelaufen ist und geht dann zu TEST-INTERMISSION über. Bei empfangenem LOW-Pegel wird dagegen nach ERROR-HANDLING gesprungen.
Mit dem Übergang in den Zustand TEST-INTERMISSION ist der TRANSMIT-MODE beendet. Der Zustand TEST-INTERMISSION ist mit dem im RECEIVE-MODE beschriebenen identisch.
SENDE-MODUS
Entscheidungsvektor:
(BUS-MONITOR, BUS-DRIVE, STUFF, COUNT, TX-Request, CRC-ERROR, OVERLOAD)
4.5.5. Zustandsdiagramm FEHLERBEHANDLUNG
Die Fehlerbehandlung beginnt mit dem Zustand SEND-ERROR-FLAG. Das ERROR-FLAG dient dazu, allen Teilnehmern mitzuteilen, daß auf dem Bus ein Übertragungsfehler stattgefunden hat oder daß ein Empfänger überlastet ist. Das ERROR-FLAG besteht aus sechs aufeinanderfolgenden LOW-Bits, deshalb wird der Zähler CNTR beim Einstieg in SEND-ERROR-FLAG auf EFL=6 (ERROR-FLAG-LENGTH) gesetzt. Falls eine Störung die gesendeten dominanten Pegel LOW nach HIGH verfälscht, wird noch einmal mit ERROR-HANDLING begonnen. Sonst wird der Zähler dekrementiert. Beim Zählerstand Null erfolgt der Übergang zum Zustand ERROR-SYNC.
Im Zustand ERROR-SYNC wird gewartet, bis andere Teilnehmer, die eventuell auch ein ERROR-FLAG senden, fertig sind. Dies wird daran erkannt, daß der Buspegel nach HIGH geht.
Die Fehlerbehandlung wird durch das Senden des ERROR-DELIMITERS im Zustand SEND-ERROR-DELIMITER abgeschlossen. Beim Einstieg wird der Zähler CNTR mit EDL-1=6 (ERROR-DELIMITER-LENGTH=7) vorbelegt. Der ERROR-DELIMITER besteht aus sieben HIGH-Bits, das erste dieser Bits wurde jedoch bereits im Zustand ERROR-SYNC gesendet. Wird beim Senden der restlichen Bits auf dem Bus ein LOW-Pegel entdeckt, so wird erneut mit ERROR-HANDLING begonnen. Sonst wird nach dem Ablaufen des Zählers zum Zustand TEST-INTERMISSION weitergegangen. Damit ist die Fehlerbehandlung beendet.
4.6. Fehlerbehandlung 4.6.1. Fehlerreaktion
Jeder Teilnehmer sendet sofort nach einem erkannten Fehler, d. h. beginnend mit dem auf den Fehlerzustand folgenden Bit, seine Fehlermeldung (ERROR-FLAG). Nur bei Erkennung eines CRC-Fehlers wird die Fehlermeldung erst drei Takte später abgeschickt. Dadurch wird sichergestellt, daß das ACK-FIELD nicht durch eine von einem CRC-Fehler ausgelöste Fehlermeldung überschrieben wird. Durch das Freihalten des ACK-FIELD kann ein Sender sowohl eine Bestätigung seiner Botschaft von einigen Empfängern erhalten als auch eine Fehlermeldung von den restlichen Empfängern. Dies bietet die Möglichkeit, im Wiederholungsfall mit hoher Wahrscheinlichkeit festzustellen, ob der Ausfall beim Teilnehmer (Sender) selbst oder bei einem Empfänger liegt.
Eine Fehlermeldung besteht aus mindestens sechs aufeinanderfolgenden LOW Bits (ERROR-FLAG). Nach dem anschließenden LOW-HIGH-Übergang müssen noch mindestens 10 HIGH Bits abgewartet werden (ERROR-DELIMITER und INTERMISSION).
4.6.2. Fehlerauftreten
Die Fehlerbehandlung kann sowohl von ihrem räumlichen als auch ihrem zeitlichen Auftreten abhängen.
Unter 4.6.5. werden einige Beispiele von Fehlerreaktionen des Open-Kollektor Busses gezeigt.
Aus der folgenden Tabelle 4.6.2. können alle möglichen Einzelbit-Fehlerfälle entnommen werden.
Unter den angegebenen Nummern sind die hier unter 4.6.5. aufgeführten Beispiele für Fehlerfälle zu finden.
Tabelle 4.6.2
4.6.3. Fehlerklassen
Auf Grund der in 4.3 beschriebenen Festlegung des Busprotokolls und der in 4.4 spezifizierten Bus-Organisation können folgende Fehlerklassen auftreten:
Sender:
BF Bitfeher, Buspegel stimmt nicht mit gesendetem Pegel überein.
BK Im Zustand TRASMIT-IDENTIFIER (Arbitrierung) und TRANSMIT-START-OF- FRAME gilt nur Buspegel HIGH bei gesendetem LOW Bit als Fehler
AF kein Acknowledge während RECEIVE-ACKNOWLEDGE
NF Während des Zustands TEST-INTERMISSION ein LOW Bit auf dem Bus
SF Verletzung der Stuffvorschrift
Empfänger:
CF CRC-Fehler
DF die CRC-SEQUENCE ist nicht mit einem CRC-DELIMITER abgeschlossen, d. h. auf das CRC-Kontrollwort folgt kein HIGH Bit
NF Während der Zustände RECEIVE-END-OF-FRAME und TEST-INTERMISSION ist ein LOW Bit auf dem Bus.
SF Verletzung der Stuffvorschrift
BF Bitfehler im Zustand TRANSMIT-ACK
In der nachfolgenden Tabelle 4.6.3 sind alle Fehlererkennungs­ möglichkeiten zusammengestellt, die sich aus den Kombinationen aus zeitlichem und räumlichem Auftreten sowie der Fehlerklassen ergeben. Angegeben sind die zum Zeitpunkt des Fehlers erkennbaren Fehlerklassen.
Die Abkürzungen in der oberen Zeile jedes Feldes der Matrix charakterisieren die am Sender auftretenden Fehlerklassen, die in der unteren Reihe die an den Empfängern auftretenden Fehlerklassen.
Tabelle 4.6.3
4.6.4. Erläuterungen zu den Beispielen
In den Bildern werden folgende Abkürzungen verwendet:
- α
Störung
- --- ungestörte Botschaft
- *** eigenes Eingreifen
- ### fremdes Eingreifen
- S Stuffbit
- 1..8. Nummerierung
- R Busruhe (Zustand BUS-IDLE) erkannt
- B Bitfehler während einer Übertragung erkannt
- F Fehler von einem Teilnehmer erkannt
- Z Beginn einer Fehlermeldung
- K Teilnehmer hat Arbitrierung verloren und bricht seine Übertragung ab
Modellparameter der folgenden Fehlerbehandlungsbeispiele:
  • - maximale Anzahl von Bits gleichen Pegels (S=5)
  • - END-OF-FRAME besteht aus sechs aufeinanderfolgenden HIGH Bits (EOFL=6)
  • - INTERMISSION besteht aus drei aufeinanderfolgenden HIGH Bits (IML=3)
  • - eine Fehlermeldung besteht aus mindestens sechs aufeinanderfolgenden LOW Bits (EFL=6)
  • - mit Sender wird ein Teilnehmer bezeichnet der entweder schon sendet oder in dem ein Sendewunsch vorliegt
4.6.5. Beispiele Einzelbitfehler 4.6.5.1. Globale Störung, von allen Teilnehmern entdeckbar. Bitfehler im IDENTIFIER
Der Sender "verliert" die Arbitrierung und erkennt dann, wie die Empfänger einen Stuffehler. Nach der Fehlermeldung und anschließende Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
Zwei Sender beginnen gleichzeitig mit der Übertragung.
Die Störung erzeugt am Sender 2 einen Bitfehler, und er setzt seine Fehlermeldung ab. Dadurch kommt es bei den Empfängern zu einem Stuffehler und am Sender 1 entweder zu einem Bitfehler und /oder einem Stuffehler. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachrichten begonnen werden.
4.6.5.2. Fehler tritt an einem Teil der Empfänger und am Sender bzw. an Station mit Sendewunsch auf. Stuffehler im DATA-FIELD.
Der Sender erkennt einen Bitfehler und die gestörten Empfänger erkennen einen Stuffehler und setzen eine Fehlermeldung ab. Dadurch entsteht an den nicht gestörten Empfängern ein Stuffehler und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
4.6.5.3. Fehler tritt an einem Teil der Empfänger und am Sender bzw. an Station mit Sendewunsch auf. Bitfehler im ACK-SLOT
Die gestörten Empfänger erkennen einen Bitfehler (ihr LOW Bit wird gestört) und setzen eine Fehlermeldung ab. Der Sender bekommt kein Acknowledge und setzt ebenfalls eine Fehlermeldung ab. Dadurch erkennen die nicht gestörten Empfänger einen Fehler (ACK-DELIMITER) und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung kann mit neuen Übertragungen oder der Wiederholung der gestörten Botschaft begonnen werden.
4.6.5.4. Nur der Sender wird gestört. Fehler in BUS-IDLE.
Durch die Störung gelingt es dem Teilnehmer S 1 nicht mehr seine Übertragung zu starten, und er verhält sich bis zum Ende der Fehlerbehandlung, wie ein Empfänger. S 1 erkennt Stuffehler und setzt seine Fehlermeldung ab. Dadurch erhalten die Empfänger einen Stuffehler und setzen ebenfalls eine Fehlermeldung ab. Nach der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen begonnen werden.
4.6.5.5. Störung nur am Sender. Stuffehler im DATA-FIELD
Der Sender erkennt Stuffehler und Bitfehler zugleich und setzt eine Fehlermeldung ab. Dadurch erhalten die Empfänger einen Stuffehler und setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
4.6.5.6. Fehler tritt an allen Empfängern auf, aber nicht am Sender bzw. an Station mit Sendewunsch auf. Bitfehler im CONTROLL-FIELD, Längenangabe verfälscht. Fall 1: Vergrößerung der Längenangabe, Empfänger erwarten längere Botschaft als tatsächlich gesendet.
Die Empfänger können nicht mehr an der richtigen Stelle den Empfang einer Botschaft quittieren, der Sender erkennt deswegen einen Fehler und setzt seine Fehlermeldung ab. Dadurch entsteht an den Empfängern ein Stuffehler und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Botschaft begonnen werden.
Fall 2: Verkleinerung der Längenangabe, Empfänger erwarten eine kürzere Botschaft als tatsächlich gesendet.
Die Empfänger stellen einen CRC-Fehler fest und setzen eine Fehlermeldung ab. Dadurch entsteht am Sender eine Bitfehler und er setzt ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Botschaft begonnen werden.
4.6.5.7. Fehler tritt an einem Teil der Empfänger auf, aber nicht am Sender bzw. an Station mit Sendewunsch. Bitfehler in BUS-IDLE.
Die gestörten Empfänger erhalten durch die Störung eine falsche Längenangabe und setzen deshalb ihren CRC-Check an die falsche Stelle. Wenn der CRC der gestörten Empfänger um mehr als 8 Takte später als die richtige Lage erfolgt, so erhalten die Empfänger einen Stuffehler und setzen eine Fehlermeldung ab. Erfolgt der CRC-Check innerhalb von 8 Takten nach der richtigen Lage, so erkennen die gestörten Empfänger einen CRC-Fehler und senden eine Fehlermeldung. Dadurch entsteht am Sender ein Bitfehler. Die nicht gestörten Empfänger empfangen als END-OF-FRAME eine unzulässige Bitfolge und setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
4.6.5.8. Fehler tritt an einem Teil der Empfänger auf, aber nicht am Sender bzw. an Station mit Sendewunsch. Stuffehler in DATA-FIELD.
Die gestörten Empfänger erkennen einen Stuffehler und setzen eine Fehlermeldung ab. Dadurch entsteht am Sender ein Bitfehler und an den nicht gestörten Empfängern ein Stuffehler und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
4.7. INTERFACE-MANAGEMENT-PROCESSOR (IMP) 4.7.1. Konfiguration 4.7.1.1. Allgemeines Konzept 4.7.1.1.1. Struktur
Der IMP hat folgende Aufgaben
  • - Datenaustausch zwischen CPU und serieller Schnittstelle durch die Benutzung eines DUAL PORT RAM (DPRAM)
  • - Steuerung von Senden und Empfangen
Fig. 11 zeigt das Blockschaltbild des seriellen Schnittstellenbausteins. Der serielle Schnittstellenbaustein besteht aus den Teilen:
  • - DPRAM
  • - IMP
  • - serielles Schieberegister
  • - Buslogik
  • - Taktoszillator
Die Verbindungen der Teile untereinander sind im Blockschaltbild angegeben.
4.7.1.1.2. Priorität der Botschaften
Die Priorität innerhalb des IMP wird durch den Platz der verschiedenen Botschaften im DPRAM festgelegt. Die Priorität auf dem Bus (Arbitrierung) wird durch den IDENTIFIER der Botschaft bestimmt.
Der Suchprozeß nach der höchstprioren Botschaft innerhalb eines IMP startet an der niedrigsten DPRAM Adresse.
4.7.1.1.3. Akzeptanzfilter
Jede vom Bus ankommende Nachricht wird daraufhin geprüft, ob sie empfangen werden soll oder nicht. Dazu wird im DPRAM die Liste durchgesehenen, in der alle Botschaften stehen, die in diesem IMP verarbeitet werden. Eine ankommende Botschaft wird nur dann ins DPRAM übernommen, wenn ihr IDENTIFIER dort gefunden wird und wenn sie auch empfangen werden soll, was durch das RECEIVE/TRANSMIT Bit angezeigt wird.
4.7.1.1.4. Warteschlange der Botschaften, die gesendet werden soll
Jede Botschaft, die gesendet werden soll, wird von der CPU in das DPRAM geschrieben, wobei anschließend das TRANSMIT-REQUEST Bit gesetzt wird. Ein Suchvorgang findet die höchstpriore Botschaft, die zur Übertragung ansteht. Nur diese Botschaft wird für eine Übertragung ins serielle Schieberegister berücksichtigt. Wenn die CPU später eine wichtigere Botschaft zur Übertragung anmeldet, so wird der Suchvorgang diese entdecken und die erste Botschaft verdrängen. Dadurch werden die Botschaften entsprechend ihrer Priorität übertragen, unabhängig von ihrer Ankunftszeit.
4.7.1.1.5. Warteschlange empfangener Botschaften
Wenn empfangene Botschaften im DPRAM gespeichert werden, wird automatisch das INTERRUPT-REQUEST Bit gesetzt. Der Suchvorgang wird unter den empfangenen Botschaften diejenige mit der höchster Priorität finden und einen Interrupt an die CPU weitergeben. Wenn eine wichtigere Botschaft im DPRAM gespeichert wird, bevor die CPU den Interrupt beantwortet hat, so wird die höherpriore Botschaft berücksichtigt. Damit werden die Botschaften entsprechend ihrer Priorität berücksichtigt, unabhängig von ihrer Ankunftszeit.
4.7.1.2. DPRAM Organisation
Das DPRAM enthält DESCRIPTOREN (IDENTIFIER, CONTROL-SEGMENTE) und DATA-FIELDS aller Botschaften, die von der CPU über den Bus empfangen oder gesendet werden sollen. Die Aufteilung des DPRAM ist unabhängig vom spezifizierten Protokoll. Möglichkeiten:
  • - getrennte Speicher für ankommende und abgehende Botschaften
  • - getrennte Speicher für DESCRIPTORS und DATA-FIELDS
  • - einen einzigen Speicher für alle Aufgaben
In einer ersten Ausführung wird ein Speicher für alle Aufgaben vorgeschlagen. Die Botschaften können äquidistant in den Speicher eingetragen werden. Um jedoch Speicherplatz zu sparen, ist es angebracht, die Botschaften hintereinander dichtgepackt abzuspeichern, mit einer Länge von drei bis zehn Bytes abhängig von der DATA-BYTE-COUNT.
Die Größe des DPRAM ist zur Zeit auf 64 Byte festgelegt. Wenn die Integrationskosten in Zukunft kleiner werden sollten, kann der Speicher vergrößert werden. Damit könnten eine größere Anzahl von Botschaften oder längere Botschaften (sowohl DATA-FIELD als auch DESCRIPTOR) gespeichert werden. Es könnten auch Ersatzbotschaften für das Ausbleiben von Nachrichten im DPRAM abgelegt werden, was im Fehlerfall die Software vereinfachen würde.
Das DPRAM dient also als:
  • - Speicher, der gleichzeitig entscheidet ob ankommende Botschaften empfangen werden sollen (Akzeptanzfilter)
  • - Warteschlange für ankommende und fortgehende Botschaften geordnet nach ihrer Priorität
  • - Speicher für die Kontrollregister des IMP
4.7.1.3. CONTROLL-SEGMENT Organisation
  • 7 DATA-BYTE-CODE
  • 6 DATA-BYTE-CODE
  • 5 TRANSMISSION-REQUEST
  • 4 PENDING
  • 3 TRANSMISSION-COUNT
  • 2 INTERRUPT
  • 1 INTERRUPT-ENABLE
  • 0 RECEIVE/TRANSMIT
4.7.1.4. Funktion des DPRAM 4.7.1.4.1. DATA-BYTE-CODE
Bei Suchvorgängen muß der Adreß-Zeiger des DPRAM zuerst auf den jeweiligen Anfang einer Botschaft zeigen. Wenn die DESCRIPTOREN und DATA-Fields dichtgepackt abgespeichert sind, kann auf die nächste Botschaft gezeigt werden indem man den Zeiger um
2** (DATA-BYTE-COUNT) + 2
erhöht. Um den Speicherplatz und die Botschaften besser auszunützen, können mehrere Botschaften unter einem DESCRIPTOR zusammengefaßt werden und als eine große Botschaft übertragen werden. Die maximale Blockgröße wird vorerst auf 8 Bytes festgelegt.
Die Länge des DATA-FIELDS erhält man aus den DATA-BYTE-CODE mit
DATA-BYTE-COUNT = 2** DATA-BYTE-CODE
4.7.1.4.2. PENDING
Das PENDING Bit zeigt an, daß entweder eine Übertragung oder eine Interruptroutine noch nicht fertig ist. Es wird automatisch gesetzt, wenn eine Übertragung auf dem Bus beginnt oder wenn die CPU einen Interrupt bestätigt (Laden des Interruptzeigers). Das PENDING Bit wird automatisch nach einer Übertragung (erfolgreich oder nicht erfolgreich) zurückgesetzt. Das PENDING Bit wird außerdem unter Programmkontrolle von der CPU zusammen mit dem INTERRUPT-REQUEST oder bei Ankunft einer neuen Botschaft mit dem gleichen IDENTIFIER zurückgesetzt. Ist das PENDING Bit einer Botschaft gesetzt, so wird diese Botschaft bei einem Suchvorgang nicht berücksichtigt.
Das PENDING Bit erlaubt dem Programmierer der CPU am Ende der Interruptroutine zu überprüfen, ob ein weiterer Interrupt die Konsistenz einer Botschaft mit mehreren Bytes zerstört hat, *** Wenn das PENDING Bit am Ende der Interruptroutine immer noch auf HIGH steht, ist dies die Bestätigung, daß das DATA-FIELD konsistent bearbeitet wurde vor Ankunft der nächsten Botschaft.
Diese Vorgänge erfolgen nur für INTERRUPT-ENABLE = HIGH. Wenn der INTERRUPT-ENABLE auf Low zurückgesetzt ist, dann wird das PENDING Bit nicht mit der Interruptbestätigung der CPU gesetzt.
4.7.1.4.3. INTERRUPT-ENABLE
Ein gesetztes INTERRUPT-ENABLE erlaubt, das INTERRUPT-REQUESTS im richtigen Bezug zur CPU weitergegeben werden.
Ein nicht gesetztes INTERRUPT-ENABLE verhindert, daß eine Interruptaktion an die CPU gemeldet wird.
4.7.1.4.4. INTERRUPT-REQUEST
Der INTERRUPT-REQUEST wird automatisch auf HIGH gesetzt bei jeder Übertragung einer neu empfangenen Botschaft ins DPRAM unabhängig von Zustand des INTERRUPT-ENABLE, INTERRUPT-REQUEST wird auch gesetzt, wenn eine wiederholte Übertragung (TRANSMISSION-COUNT = HIGH) scheitert.
4.7.1.4.5. TRANSMISSION-COUNT
TRANSMISSION-COUNT zählt die Übertragungsversuche. TRANSMISSION-COUNT wird nach einer erfolgreichen Übertragung zurückgesetzt.
Nach der zweiten fehlerhaften Übertragung wird INTERRUPT-REQEST gesetzt um die weitere Fehlerbehandlung der Benutzersoftware überlassen zu können.
4.7.1.4.6. TRANSMISSION-REQUEST
Ein gesetztes TRANSMISSION-REQUEST Bit veranlaßt den IMP die zugehörige Botschaft zu übertragen.
Es gibt zwei verschiedene Zustände:
  • a. RECEIVE/TRANSMIT = LOW (Übertragung) Startwert nach einem Reset. Die Botschaft wird gesendet. TRANSMISSION-REQUEST wird von der CPU oder von einer ankommenden Botschaft mit gesetztem REMOTE-TRANSMISSION-REQUEST Bit auf HIGH gesetzt.
  • b. RECEIVE/TRANSMIT = HIGH (Empfang)
    Alle so gekennzeichneten Botschaften sind im Empfangsmodus. Als Ausnahme in diesem Zustand wird durch OP Setzen von TRANSMISSION-REQUEST eine Botschaft mit leerem DATA-FIELD und gesetztem REMOTE-TRANSMISSION-REQUEST abgeschickt.
4.7.1.4.7. RECEIVE/TRANSMIT
RECEIVE/TRANSMIT bestimmt die Richtung der Daten.
  • a. RECEIVE/TRANSMIT = LOW (Übertragung)
    Startwert nach einem Reset. Die DATA-FIELDS im DPRAM sind für ankommende Botschaften schreibgeschützt, wenn RECEIVE/TRANSMIT auf LOW gesetzt ist. Die Botschaften werden durch TRANSMISSION-REQUEST HIGH aktiviert.
    Es gibt jedoch eine Ausnahme:
    Wenn REMOTE-TRANSMISSION-REQUEST = HIGH in einer ankommenden Botschaft ist, dann wird TRANSMISSION-REQUEST des zugehörigen CONTROL-SEGMENTS auf HIGH gesetzt trotz RECEIVE/TRANSMIT = LOW. TRANSMISSION-REQUEST ist das einzige Bit, das in dieser Operation geändert wird, alle anderen Bits bleiben weiterhin schreibgeschützt. Dieses Vorgehen dient zur Anforderung von Botschaften durch andere Busteilnehmer.
  • b. RECEIVE/TRANSMIT = HIGH (Empfang)
    Die ankommenden Botschaften werden in das zugehörige DATA-FIELD übertragen. INTERRUPT-REQUEST wird automatisch auf HIGH gesetzt bei jeder Übertragung der zugehörigen Botschaft.
4.7.2. Datenaustausch CPU-DPRAM 4.7.2.1. Synchronisationsproblem
Der Austausch von DATA-FIELDS, die aus mehreren Bytes bestehen, kann abhängig von der Anwendung ohne Berücksichtigung von der synchronen Betriebsweise vorgenommen werden. Wenn die DATA-FIELDS jedoch synchron verarbeitet werden sollen, muß eine geeignete Synchronisation vorgesehen werden. Um die Hardwarekosten niedrig zu halten, wird zur Zeit eine Software-Synchronisation vorgeschlagen. In dieser Vorgehensweise greift die CPU auf das DPRAM im Cycle Stealing mit Priorität gegenüber allen anderen Zugriffsversuchen zu.
4.7.2.2. Nicht synchrone Operation
Das DPRAM wird von der CPU als RAM-Erweiterung benutzt. Es werden keine weiteren Übertragungsbefehle dazu benötigt. Empfangene Botschaften werden einfach in das DPRAM geschrieben, wobei die vorhergehenden Botschaften überschrieben werden. Übertragungen werden von der CPU durch Setzen von TRANSMISSION-REQUEST im CONTROL-SEGMENT, das zu dem zu übertragenen DATA-FIELD gehört, gestartet. TRANSMISSION-REQUEST kann ebenso von fremden CPUs durch REMOTE-TRANSMISSION-REQUEST gesetzt werden.
4.7.2.3. Software Synchronisation 4.7.2.3.1. Abfragen einer Sequenznummer
Wenn die sendende CPU ein Byte des DATA-FIELDS als Sequenznummer benutzt, und diese vor jedem Setzen des TRANSMISSION-REQUEST Bits inkrementiert, dann kann die empfangene CPU anhand der Sequenznummer prüfen, ob sich diese verändert hat nachdem sie die Daten im DATA-FIELD bearbeitet hat. Wenn sich die Sequenznummer verändert hat, muß die empfangene CPU einen Teil der Bearbeitung mit den neuen Daten wiederholen.
4.7.2.3.2. Abfragen des INTERRUPT-REQUEST
Neu ankommende Botschaften setzen automatisch das INTERRUPT-REQUEST Bit im zugehörigen CONTROL-SEGMENT. Auch wenn der CPU wegen INTERRUPT-ENABLE = LOW keinen Interrupt mitgeteilt wird, wird INTERRUPT-REQUEST vor jeder Bearbeitung der Botschaft zurückgesetzt und nach der Bearbeitung wird geprüft, ob es nicht in der Zwischenzeit wieder gesetzt wurde.
4.7.2.3.3. Interrupt gesteuerte Bearbeitung
Die empfangene CPU kann im CONTROLL-SEGMENT der zu empfangenen Botschaft das INTERRUPT-ENABLE Bit setzen. Neu ankommende Botschaften setzen das zugehörige INTERRUPT-REQUEST Bit und setzen gleichzeitig automatisch das PENDING Bit auf LOW zurück. Der wichtigste Interrupt wird der CPU gemeldet. Die Bestätigung der CPU setzt automatisch das PENDING Bit auf HIGH. Bevor die CPU am Ende der Interruptbehandlung beide (INTERRUPT-REQUEST und PENDING) zurücksetzt, fragt sie das PENDING Bit ab. Wenn das PENDING Bit immer noch auf HIGH ist, so ist die nächste Botschaft nicht innerhalb der Interruptbehandlung angekommen.
4.7.2.3.4. Block Übertragung
Um DATA-FIELDS synchron zu bearbeiten, können diese blockweise zu und von CPU übertragen werden. Ausreichender RAM Speicherplatz muß für die dadurch bedingte doppelte Speicherung bereitgestellt werden.
  • a. Senden
    Am Anfang wird TRANSMISSION-REQUEST, das als Semaphor Variable dient, geprüft. Wenn es zurückgesetzt ist, wird das DATA-FIELD byteweise vom CPU-RAM ins DPRAM übertragen. Danach wird TRANSMISSION-REQUEST gesetzt.
    WARNUNG:
    Bei dieser Vorgehensweise kann im Falle eines gesetzten REMOTE-TRANSMISSION-REQUEST Bits keine korrekte Synchronisation garantiert werden.
  • b. Empfang
    Bevor die eigentliche Interruptroutine begonnen wird, wird das DATA-FIELD blockweise ins CPU-RAM übertragen, wie unter 4.7.2.4.2. beschrieben. Dadurch wird die Wahrscheinlichkeit, daß die Daten inkonsistent werden, beträchtlich verringert, da der kritische Zeitabschnitt von der gesamten Interruptbearbeitung auf die Blockübertragung des DATA-FIELDS verringert wird.
4.7.2.3.5. Doppelter Empfangspuffer
Für wichtige Botschaften können zwei Speicherplätze im DPRAM vorgesehen werden. Ein IDENTIFIER erscheint dann zweimal im DPRAM. Die Benutzersoftware kann nun ankommende Botschaften von einem Speicherplatz im DPRAM auf einen anderen durch Ändern des zugehörigen RECEIVE/TRANSMIT Bits, anschließend an die Bestätigung des Interrupts, umschalten. Bei dieser Vorgehensweise ist in einem Speicherplatz das RECEIVE/TRANSMIT Bit HIGH, und ist damit bereit, die entsprechende Botschaft aufzunehmen, und im anderen Speicherplatz mit dem gleichen IDENTIFIER ist RECEIVE/TRANSMIT Bit LOW, und damit ist die gerade empfangene Botschaft dort schreibgeschützt.
4.7.2.4. Hardware Synchronisation
Als Voraussetzung für eine Hardware Synchronisation muß die CPU schnelle Blockübertragung mit DMA-Fähigkeiten und nicht unterbrechbare Semaphorbehandlung bieten. Der Zugriff auf das DPRAM wird durch wechselseitigen, durch ein Semaphorbit geregelten Zugriff von der CPU und dem IMP vor inkonsistenter Blockübertragung geschützt. Zwischen dem Ende einer Übertragung und dem Start einer neuen muß genügend Zeit vorgesehen werden. Im schlechtesten Fall muß der IMP solange warten, bis die CPU eine Blockübertragung abgeschlossen hat. Die CPU muß im schlechtesten Fall warten, bis der IMP eine empfangene Botschaft im DPRAM gespeichert und die nächste Botschaft, die übertragen werden soll, ins serielle Schieberegister geladen hat.
4.7.3. Datenaustausch DPRAM-Schieberegister 4.7.3.1. Parallele Steuerprozesse
Der Datenaustausch zwischen DPRAM und seriellem Schieberegister wird durch mehrere parallele Prozesse gesteuert, deren Funktion später beschrieben wird. Ein Prozeß wird initialisiert und damit in den aktiven Zustand überführt durch ein Aktivierungssignal. Im aktiven Zustand kann jeder Prozeß weitere Aktivierungssignale ausgeben, die wiederum zu anderen Prozessen gehen. Die Ausgabe eines Aktivierungssignals bedeutet nicht notwendigerweise, daß der Quellenprozeß sich gleichzeitig deaktivieren muß. Die gesamte Steuerung enthält die folgenden Prozese und Aktivierungssignale:
Aktivierungssignale:
  • - Ende der Übertragung:
    Endsignal am Ende einer fehlerfrei abgeschlossenen Übertragung. Wird beim Übergang aus dem Zustand TRANSMIT-END-OF-FRAME in den Zustand TEST-INTERMISSION für einen Bustakt gesetzt. - Ende der Arbitrierung: Signal am Ende des Arbitrierungsvorgangs; nach Auftreten dieses Signals ist der BUS-Zugriff geregelt (Senden oder Empfangen). Wird am Ende der Übertragung des IDENTIFIERS für einen Bustrakt gesetzt.
  • - Start Search:
    Startsignal für den SEARCH-Prozeß, vom Anfang des DPRAM an den Suchvorgang neu zu beginnen; erfolgt am Ende des RECEIVE/TRANSMIT-Prozesses.
  • - Übertragungsfehler:
    Fehlermeldung vom Übertragungsvorgang. Wird für einen Bustakt gesetzt, wenn eine Fehlermeldung auf dem Bus übertragen wird,
  • - Beginn der Übertragung:
    Startsignal für den LOAD-Prozeß; erfolgt am Ende des STORE-Prozesses oder des ERROR-Prozesses
  • - Weitermachen:
    - Erneuter Start bei Endlos-Prozessen
Die Prozesse sind im folgenden unter Zuhilfenahme der üblichen Kontrollfluß-Konstrukte erklärt, wie sie in ALGOL oder PASCAL verwendet werden und mit denen auch in der Informatik-Literatur gearbeitet wird.
4.7.3.2. LOAD-Prozeß
Der LOAD-Prozeß lädt die nächste zu übertragene Botschaft in das serielle Schieberegister. Wenn keine Botschaft zur Übertragung ansteht, wird der SEARCH-Prozeß gestartet. Wenn der SEARCH-Prozeß bei noch belegtem BUS eventuell eine zweite Botschaft mit höherer Priorität in der Warteschlange zu übertragender Prozesse findet, so wird diese Botschaft die vorher gefundene verdrängen.
Bus free:
Bus free ist wahr, während die BOTSCHAFTSSEGMENTE START-OF-FRAME, IDENTIFIER, CONTROL-FIELD, DATA-FIELD, CRC-FIELD und ACK-FIELD übertragen werden.
TRANSMIT-STATUS:
Muß am Ende der Arbitierung gesetzt (HIGH) oder rückgesetzt (LOW) werden
Initialisierung: TRANSIT-STATUS = LOW
4.7.3.3. STORE-Prozeß
Der STORE-Prozeß speichert entweder eine empfangene Botschaft oder verwaltet die TRANSMISSION-REQUEST und PENDING Bits von gesendeten Botschaften. Das Signal Ende der Übertragung kommt nur nach einem erfolgreichen Übertragungsvorgang ohne Fehler. Im Falle eines Fehlers kommt Übertragungsfehler.
4.7.3.4. ERROR-Prozeß
Der Error Prozeß zählt im Fehlerfall TRANSMISSION-COUNT hoch oder setzt im Falle einer zweiten nicht geglückten Übertragung INTERRUPT-REQUEST. Eine empfangene Botschaft wird im Fehlerfall einfach nicht weiter verarbeitet.
4.7.3.5. RECEIVE/TRANSMIT-Prozeß
Im Falle daß die Arbitrierung gewonnen wurde, wird das PENDING Bit, das zur gerade übertragenen Botschaft gehört, auf HIGH gesetzt und dann der zugehörige TX-POINTER auf den Stack geladen. Der RECEIVE/TRANSMIT-Prozeß setzt je nach Ausgang der Arbitrierung den TX-POINTER oder den RX-POINTER auf einen leeren Adreßzeiger zurück, bevor der SEARCH-Prozeß durch Start Search aktiviert wird.
4.7.3.6. SEARCH-Prozeß
Der Search-Prozeß sucht andauernd nach Adreßzeigern des DPRAM für
  • - zu übertragende Botschaften (TX-POINTER), wenn TRANSMISSIONEN-REQUEST gesetzt ist,
  • - zu empfangende Botschaften (RX-POINTER), d. h. ob der empfangene IDENTIFIER im DPRAM enthalten ist,
  • - Botschaften, die eine Unterbrechungsanforderung bei der CPU auslösen sollen, d. h. bei denen INTERRUPT-REQUEST und INTERRUPT-ENABLE gesetzt sind.
Der SEARCH-Prozeß wird mit Start auf die Botschaft mit der höchsten Priorität am Anfang des DPRAM zurückgesetzt, wenn die Echtzeitabläufe bei der Übertragung auf dem BUS es erfordern. Das Absuchen einer gesamten Botschaft ist als unteilbare Operation ausgeführt. In jeder Clock-Periode kann der SEARCH-Prozeß durch einen DPRAM-Zugriff der CPU im Cycle-Stealing-Verfahren angehalten und um eine Clock-Periode verzögert werden. Nach Abschluß der unteilbaren Operation kann der SEARCH-Prozeß durch höherpriore Prozesse vom Zugriff des DPRAM ausgeschlossen werden, bis die Semaphore-Variable wieder vom SEARCH-Prozeß selbst gesetzt werden kann.
4.7.3.7. INTERRUPT-HANDLING-Prozeß
Der INTERRUPT-HANDLING-Prozeß leitet Interrupts von empfangenen Botschaften oder von mehrfach fehlerhaft übertragenen Botschaften an die CPU weiter. Es wird jeweils der Interrupt mit der durch die Anordnung im DPRAM vorgegebenen höchste Priorität an die CPU weitergeleitet. Der INTERRUPT­ HANDLING-Prozeß läuft ununterbrochen, parallel zu den ändernden Prozessen. Der Anfangswert des Interrupt Pointer ist der leere Adreßzeiger.
4.7.4. Steuerung des Zugriffs zum DPRAM 4.7.4.1. Zugriffssynchronisation
Die Zugriffe zum DPRAM werden durch eine Semaphore-Variable geregelt. Diese sichert den unteilbaren Zugriff zu den zusammengehörigen Bytes der DATA-FIELDS und des CONTROL-SEGMENTS. Andere Zugriffe werden solange blockiert, bis die Semaphore-Variable zurückgesetzt ist. Damit wird die Konsistenz von DATA-FIELDS geschützt, die länger als ein Byte sind. Wenn mehrere Prozesse versuchen sollten, die Semaphore-Variable gleichzeitig zu setzen, dann gilt das folgende Prioritäten-Schema:
  • a. STORE
  • b. LOAD
  • c. ERROR
  • d. INTERRUPT-HANDLING
  • e. RECEIVE/TRANSMIT
  • f. SEARCH
Die CPU wird von der Zugriffsverwaltung mittels Semaphore ausgenommen. Sie hat per Cycle-Stealing immer sofortigen Vorrang vor allen anderen Zugriffen. Es ist klar, daß mit dieser Regelung die Konsistenz der Daten bei CPU-Zugriffen ggfs. verletzt werden kann. Um dies zu vermeiden, müßte bekanntlich auch die CPU in die Zugriffsregelung mit Semaphore eingezogen werden. Dies erfordert aber spezielle Befehle zur unteilbaren Behandlung von Semaphores, die bei den derzeit am Markt verfügbaren CPUs noch nicht realisiert sind.
4.7.4.2. DPRAM-Adreßzeiger
Auf den DPRAM wird von verschiedenen Quellen aus zugegriffen, der CPU und den parallelen Prozessen. Die Adressen kommen dabei von
  • - CPU-Adresse
  • - EMPTY-POINTER:
    Adreßzeiger, der auf eine leere, d. h. nicht mit sinnvollen Botschaften gefüllten Adresse zeigt. Wenn ein Adreßzeiger gleich dem EMPTY-POINTER ist, wird dies so interpretiert, daß keine entsprechende Botschaft vorliegt
  • - SEARCH-POINTER:
    Adreßzeiger des SEARCH-Prozesses
  • - TX-POINTER:
    Adreßzeiger, der auf die zu sendende Botschaft zeigt. Falls keine Botschaft zu senden ist, ist der TX-POINTER = EMPTY-POINTER
  • - RX-POINTER:
    Adreßzeiger, der auf die zu empfangende Botschaft zeigt. Falls keine Botschaft zu empfangen ist, ist der RX-POINTER = EMPTY-POINTER
  • - INTERRUPT-POINTER:
    Adreßzeiger, der auf die Botschaft zeigt, die eine Unterbrechungsanforderung an die CPU hat. Falls keine Unterbrechungsanforderung vorliegt, ist der INTERRUPT-POINTER = EMPTY-POINTER
Die Adreßzeiger (Pointer) werden in den verschiedenen Prozessen verarbeitet, um die DPRAM-Adresse zu erhalten, unter der Daten gespeichert oder gelesen werden sollen. Die tatsächlich DPRAM-Zugriffe mittels der Adreßzeiger sind entsprechend ihrer Priorität organisiert. Unteilbare Zugriffe auf mehrere Bytes geschehen mittels der Semaphore-Variablen, die den Zugriff für alle Prozesse blockiert, außer für den Prozeß, der die Semaphore-Variable gesetzt hat.
4.7.4.3. Prioritätssteuerung
Wie bereits beschrieben, werden der CPU-Zugriff auf den DPRAM und das Setzen der Semaphore-Variablen nach Prioritäten geordnet. Ein Prozeß darf seine Adresse nur dann an den Adreßeingang des DPRAM legen, wenn die CPU nicht zugreifen will (kein Access request und deshalb auch kein Access inhibit) und wenn die Semaphore-Variable nicht von einem anderen Prozeß belegt ist (Semaphore = LOW). Die Anschlüsse von LOAD, ERROR, INTERRUPT-HANDLING, RECEIVE/TRANSMIT und SEARCH sind gleich wie bei STORE und deshalb nicht detailliert gezeichnet.
Eine Ausführung für den Block "Access Control" des obigen Schemas ist im folgenden Flußdiagramm angegeben, das in jeder Clock-Periode durchlaufen wird.
Im obigen Flußdiagramm wurden die Abkürzungen verwendet:
  • - INT-HA for INTERRUPT-HANDLING
  • - REC/TR for RECEIVE/TRANSMIT und
  • - per for period.

Claims (8)

1. Verfahren zum Betreiben einer Datenverarbeitungsanlage, insbeson­ dere für Kraftfahrzeuge, mit wenigstens zwei Rechnern, einer die Rech­ ner verbindenden Leitung zum Übertragen von Botschaften, wobei die Botschaft zumindest einen Kopfteil (Identifier) und einen Datenteil aufweist, wobei der Kopfteil am Anfang der Botschaft steht, dadurch gekennzeichnet, daß der Kopfteil zumindest teilweise als Identifizie­ rer der Botschaft ausgebildet ist, der den Datennamen und die Priori­ tät der Botschaft festlegt, und daß durch die im Identifizierer fest­ gelegte Priorität der Zugang zum Bus bestimmt ist.
2. Verfahren zum Aufbau von Botschaften für eine Datenverarbeitungsan­ lage, insbesondere für Kraftfahrzeuge, wobei die Botschaft zumindest einen Kopfteil (Identifier) und einen Datenteil aufweist, wobei der Kopfteil am Anfang der Botschaft steht, dadurch gekennzeichnet, daß der Kopfteil zumindest teilweise als Identifizierer der Botschaft aus­ gebildet ist, der den Datennamen und die Priorität der Botschaft fest­ legt, und daß durch die im Identifizierer festgelegte Priorität der Zugang zum Bus bestimmt ist.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Identifizierer Datennamen wie Adressen, Daten, Sensorsignale, Stell­ größe, Zwischenergebnisse, Befehle für Synchronisation, Befehle zum Auslösen von Aktionen bezeichnet.
4. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Identifizierer Inhalte wie Drehzahl, Drehzahlgradient, Motortempera­ tur, Last der Antriebsmaschine bezeichnet.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekenn­ zeichnet, die höhere Priorität der Botschaft dadurch bestimmt ist, daß in bezug auf den Kopfteil (Identifier) anderer Botschaften das erste unterschiedliche Bit dominant ist.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß die Priori­ tät der Botschaft durch am Anfang des Identifizierers angeordnete do­ minante Bits bestimmt wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekenn­ zeichnet, daß die Botschaften bipolar übertragen werden.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekenn­ zeichnet, daß die Botschaft von allen Rechnern gleichzeitig empfangen wird, daß jeder Rechner eine Liste der für ihn relevanten Botschaften enthält, daß zumindest ein Teil des Kopfteils der Botschaft mit der Liste verglichen wird und daß eine Botschaft nur dann weiterverarbei­ tet wird, wenn dieser Teil in der Liste gefunden wird.
DE19853506118 1985-02-22 1985-02-22 Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge Granted DE3506118A1 (de)

Priority Applications (14)

Application Number Priority Date Filing Date Title
DE3546683A DE3546683C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage
DE19853506118 DE3506118A1 (de) 1985-02-22 1985-02-22 Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge
DE3546684A DE3546684C2 (en) 1985-02-22 1985-02-22 Operating communication bus network for processors
DE3546662A DE3546662C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage
DE3546664A DE3546664C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage
FR8517780A FR2578070B1 (fr) 1985-02-22 1985-12-02 Procede pour faire fonctionner une installation de traitement de donnees pour des vehicules a moteur
JP61031033A JP2545508B2 (ja) 1985-02-22 1986-02-17 車両に対するデータ処理装置の作動方法およびデータ処理装置
US06/831,475 US5001642A (en) 1985-02-22 1986-02-20 Method for operating a data processing system
US07/856,430 US5303348A (en) 1985-02-22 1992-03-23 Method of arbitrating access to a data bus and apparatus therefor
JP5302048A JPH0772883B2 (ja) 1985-02-22 1993-12-01 データ処理装置におけるエラーのあるメッセージの処理方法
JP5302049A JPH0721784B2 (ja) 1985-02-22 1993-12-01 データ処理装置に対する伝送すべきメッセージの処理方法
US08/185,024 US5640511A (en) 1985-02-22 1994-01-24 Method of arbitrating access to a data bus and apparatus therefor
US08/464,383 US5621888A (en) 1985-02-22 1995-06-05 Method of building up messages for driving a data processing arrangement with several stations receiving connected thereto
US08/465,059 US5901156A (en) 1985-02-22 1995-06-05 Method of processing messages to be transmitted for a data processing arrangement

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE19853506118 DE3506118A1 (de) 1985-02-22 1985-02-22 Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge

Publications (2)

Publication Number Publication Date
DE3506118A1 DE3506118A1 (de) 1986-08-28
DE3506118C2 true DE3506118C2 (de) 1991-01-03

Family

ID=6263209

Family Applications (4)

Application Number Title Priority Date Filing Date
DE3546662A Expired - Lifetime DE3546662C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage
DE3546664A Expired - Lifetime DE3546664C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage
DE19853506118 Granted DE3506118A1 (de) 1985-02-22 1985-02-22 Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge
DE3546683A Expired - Lifetime DE3546683C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage

Family Applications Before (2)

Application Number Title Priority Date Filing Date
DE3546662A Expired - Lifetime DE3546662C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage
DE3546664A Expired - Lifetime DE3546664C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE3546683A Expired - Lifetime DE3546683C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage

Country Status (4)

Country Link
US (5) US5001642A (de)
JP (3) JP2545508B2 (de)
DE (4) DE3546662C3 (de)
FR (1) FR2578070B1 (de)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4129412A1 (de) * 1991-09-04 1993-03-18 Nec Electronics Germany Verfahren zur datenuebertragung und datenverarbeitungsanlage mit verteilten rechnerknoten
DE4140017A1 (de) * 1991-12-04 1993-06-09 Nec Electronics (Germany) Gmbh, 4000 Duesseldorf, De Verfahren zur erzeugung einer globalen zeitbasis und datenverarbeitungsanlage mit verteilten rechnerknoten
US6292862B1 (en) 1998-07-28 2001-09-18 Siemens Aktiengesellschaft Bridge module
DE112015005263B4 (de) 2014-11-20 2020-08-06 Autonetworks Technologies, Ltd. Kommunikationssystem und Kommunikationsvorrichtung
DE102012221633B4 (de) * 2011-11-30 2021-01-21 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) Verfahren zum Diagnostizieren eines Fehlers in einem fahrzeuginternen Kommunikationssystem
DE102020212452B3 (de) 2020-10-01 2022-01-13 Volkswagen Aktiengesellschaft Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft
DE102015108333B4 (de) 2014-05-27 2023-06-07 GM Global Technology Operations, LLC (n.d. Ges. d. Staates Delaware) Kurzschlussfehlerisolierung in einem controller area network
DE102015108342B4 (de) 2014-05-27 2023-08-03 GM Global Technology Operations LLC (n. d. Gesetzen des Staates Delaware) Leitungsunterbrechungsfehlerdetektion und -diagnose in einem controller area network

Families Citing this family (134)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3546662C3 (de) * 1985-02-22 1997-04-03 Bosch Gmbh Robert Verfahren zum Betreiben einer Datenverarbeitungsanlage
JPH01148645A (ja) * 1987-12-04 1989-06-12 Sumitomo Electric Ind Ltd 車両スリップ制御装置
FR2627039B1 (de) * 1988-02-10 1994-01-21 Peugeot Automobiles
JP2726931B2 (ja) * 1988-03-15 1998-03-11 三菱農機株式会社 移動農機の制御装置
DE3826774A1 (de) * 1988-08-06 1990-02-08 Bosch Gmbh Robert Netzwerkschnittstelle
DE3926165A1 (de) * 1989-08-08 1991-02-14 Bodenseewerk Geraetetech Sender- und empfaengeranordnung als schnittstelle zu einem mikroprozessor
DE3927968A1 (de) * 1989-08-24 1991-02-28 Bosch Gmbh Robert Verfahren zur datenuebertragung ueber einen seriellen datenbus in verteilten systemen
JP2904298B2 (ja) * 1990-03-30 1999-06-14 マツダ株式会社 車両用多重伝送装置
JP2915080B2 (ja) * 1990-05-25 1999-07-05 株式会社日立製作所 マルチプロセッサシステムにおけるデータ処理方法
DE4028809B4 (de) * 1990-09-11 2005-03-10 Bosch Gmbh Robert System zur Steuerung eines Kraftfahrzeugs
DE4028926A1 (de) * 1990-09-12 1992-03-19 Teves Gmbh Alfred Schaltungsanordnung zur steuerung von elektrischen oder elektromechanischen verbrauchern
FR2668624B1 (fr) * 1990-10-30 1993-02-19 Renault Dispositif de reconnaissance d'adresses pour module electronique de traitement de donnees.
DE4039483A1 (de) * 1990-12-11 1992-06-17 Bayerische Motoren Werke Ag Linearer datenbus
GB2251499A (en) * 1991-01-05 1992-07-08 Delco Electronics Corp Electronic control module.
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
JP2598178B2 (ja) * 1991-04-30 1997-04-09 三菱電機株式会社 通信システム
DE4121999A1 (de) * 1991-07-03 1993-01-07 Bosch Gmbh Robert Lichtmischstecker fuer einen optobus
DE4122084A1 (de) * 1991-07-04 1993-01-07 Bosch Gmbh Robert Verfahren zur informationsuebertragung in einem mehrere teilnehmer aufweisenden bussystem
US5729755A (en) * 1991-09-04 1998-03-17 Nec Corporation Process for transmitting data in a data processing system with distributed computer nodes, communicating via a serial data bus, between which data messages are exchanged, tested for acceptance in a computer node, and stored temporarily
DE4131133B4 (de) * 1991-09-19 2005-09-08 Robert Bosch Gmbh Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen
DE4133268A1 (de) * 1991-10-08 1993-04-15 Bosch Gmbh Robert Vorrichtung zur steuerung der antriebsleistung eines fahrzeuges
JPH07501503A (ja) * 1991-11-26 1995-02-16 シーメンス アクチエンゲゼルシヤフト バスシステム
JP2700843B2 (ja) * 1991-12-10 1998-01-21 三菱電機株式会社 多重通信制御装置
DE4213134B4 (de) * 1992-04-21 2006-03-02 Robert Bosch Gmbh Netzwerkschnittstelle mit Wiederzuschaltvorrichtung zum schnelleren Verlassen eines passiven Zustandes
DE4219669B4 (de) * 1992-06-16 2007-08-09 Robert Bosch Gmbh Steuergerät zur Berechnung von Steuergrößen für sich wiederholende Steuervorgänge
JP3266331B2 (ja) * 1992-10-09 2002-03-18 富士通株式会社 出力回路
US6151689A (en) * 1992-12-17 2000-11-21 Tandem Computers Incorporated Detecting and isolating errors occurring in data communication in a multiple processor system
JPH06236352A (ja) * 1993-02-09 1994-08-23 Nippondenso Co Ltd データ通信装置
DE4340048A1 (de) * 1993-11-24 1995-06-01 Bosch Gmbh Robert Vorrichtung zum Austauschen von Daten und Verfahren zum Betreiben der Vorrichtung
JP3892052B2 (ja) * 1993-12-01 2007-03-14 株式会社デンソー エンジン用制御装置
EP0666199B1 (de) * 1994-02-02 1999-09-29 Mannesmann VDO Aktiengesellschaft Elektronisches System eines Kraftfahrzeugs mit zwischen zwei verschiedenen Bussen gelegener Schnittstellenschaltung
DE19514696B4 (de) * 1994-04-18 2006-03-09 Kvaser Consultant Ab System zur Beseitigung von Störungen bzw. zur Ermöglichung einer Hochgeschwindigkeitsübertragung in einer seriellen Bus-Schaltung sowie mit letzterer verbundene Sende- und Empfangsgeräte
DE4421083C2 (de) * 1994-06-16 1996-04-11 Volkswagen Ag Verfahren zur Überwachung einer seriellen Übertragung von digitalen Daten auf einer Ein-Draht-Multiplexverbindung zwischen untereinander kommunizierenden Signalverarbeitungsgeräten
JP3618119B2 (ja) * 1994-06-23 2005-02-09 株式会社デンソー 車両通信システム
DE4429953B4 (de) * 1994-08-24 2012-06-06 Wabco Gmbh Serielles Bussystem
SE503397C2 (sv) * 1994-09-11 1996-06-03 Mecel Ab Arrangemang och förfarande för ett reglersystem till en förbränningsmotor innefattande ett distribuerat datornät
US6145008A (en) * 1994-09-13 2000-11-07 Kopetz; Hermann Conflict free time-triggered method and apparatus for the transmission of messages in a distributed real-time computer system
US5568484A (en) * 1994-12-22 1996-10-22 Matsushita Avionics Systems Corporation Telecommunications system and method for use on commercial aircraft and other vehicles
JP3505882B2 (ja) * 1995-01-31 2004-03-15 株式会社デンソー 車両用発電装置
DE19616293A1 (de) 1996-04-24 1997-10-30 Bosch Gmbh Robert Bussystem für die Übertragung von Nachrichten
JPH11513231A (ja) 1996-07-24 1999-11-09 ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング データ伝送方法、データ伝送用インターフェースおよびデータ受信用インターフェース
JP3183181B2 (ja) * 1996-08-28 2001-07-03 トヨタ自動車株式会社 情報送信方法
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
US6164920A (en) * 1996-09-30 2000-12-26 Minnesota Mining And Manufacturing Company Perfusion system with control network
US5752931A (en) * 1996-09-30 1998-05-19 Minnesota Mining And Manufacturing Company Perfusion system with perfusion circuit display
US5813972A (en) * 1996-09-30 1998-09-29 Minnesota Mining And Manufacturing Company Medical perfusion system with data communications network
US5995512A (en) * 1997-01-17 1999-11-30 Delco Electronics Corporation High speed multimedia data network
JP3117000B2 (ja) * 1997-02-21 2000-12-11 株式会社デンソー 通信システムおよびそれに使用される電子制御装置
FR2764149B1 (fr) * 1997-05-27 1999-08-27 Peugeot Procede et dispositif de validation/invalidation d'un message emis sur un reseau de transmission d'informations par reponse dans une trame de communication
FR2764098B1 (fr) * 1997-05-27 1999-08-20 Peugeot Procede et dispositif de controle des acces a un champ de donnees destine a etre emis sur un reseau de transmission d'informations
US6175603B1 (en) * 1997-08-07 2001-01-16 Cisco Technology, Inc. System for managing signals in different clock domains and a programmable digital filter
US6256677B1 (en) * 1997-12-16 2001-07-03 Silicon Graphics, Inc. Message buffering for a computer-based network
DE19813923A1 (de) * 1998-03-28 1999-10-14 Telefunken Microelectron Verfahren zur Datenübertragung in einem über eine Busleitung vernetzten Rückhaltesystem
US6397282B1 (en) * 1998-04-07 2002-05-28 Honda Giken Kogyo Kabushikikaisha Communication controller for transferring data in accordance with the data type
US6385210B1 (en) * 1998-04-17 2002-05-07 Ford Global Technologies, Inc. Method for detecting and resolving data corruption in a UART based communication network
DE19832531A1 (de) * 1998-07-22 2000-02-10 Bosch Gmbh Robert Steuerung für eine Mehrzahl von elektrischen Verbrauchern eines Kraftfahrzeugs
DE19843810A1 (de) * 1998-09-24 2000-03-30 Philips Corp Intellectual Pty Datenbus
DE19904092B4 (de) * 1999-02-02 2012-01-05 Robert Bosch Gmbh Verfahren zur Übertragung von Daten
US6975612B1 (en) 1999-06-14 2005-12-13 Sun Microsystems, Inc. System and method for providing software upgrades to a vehicle
US6754183B1 (en) 1999-06-14 2004-06-22 Sun Microsystems, Inc. System and method for integrating a vehicle subnetwork into a primary network
US6362730B2 (en) 1999-06-14 2002-03-26 Sun Microsystems, Inc. System and method for collecting vehicle information
US6370449B1 (en) * 1999-06-14 2002-04-09 Sun Microsystems, Inc. Upgradable vehicle component architecture
US6253122B1 (en) 1999-06-14 2001-06-26 Sun Microsystems, Inc. Software upgradable dashboard
US6507810B2 (en) 1999-06-14 2003-01-14 Sun Microsystems, Inc. Integrated sub-network for a vehicle
US6728268B1 (en) * 1999-06-22 2004-04-27 Trimble Navigation Ltd. Method and system to connect internet protocol hosts via an application specific bus
US6427180B1 (en) * 1999-06-22 2002-07-30 Visteon Global Technologies, Inc. Queued port data controller for microprocessor-based engine control applications
JP2001016234A (ja) 1999-06-29 2001-01-19 Mitsubishi Electric Corp Ｃａｎコントローラおよびｃａｎコントローラを内蔵したワンチップ・コンピュータ
FI112548B (fi) * 1999-09-08 2003-12-15 Iws Int Oy Järjestelmä datan siirtoa varten
US6510479B1 (en) * 1999-09-15 2003-01-21 Koninklijke Philips Electronics N.V. Transmit pre-arbitration scheme for a can device and a can device that implements this scheme
DE19954758A1 (de) * 1999-11-15 2001-05-23 Becker Gmbh Verfahren zum Datenaustausch für eine Multimediaanlage sowie Multimediaanlage für ein Fahrzeug
US6442708B1 (en) 1999-12-14 2002-08-27 Honeywell International Inc. Fault localization and health indication for a controller area network
US6629247B1 (en) * 2000-03-28 2003-09-30 Powerware Corporation Methods, systems, and computer program products for communications in uninterruptible power supply systems using controller area networks
US6744987B1 (en) * 2000-04-17 2004-06-01 Delphi Technologies, Inc Tertiary optical media interface
US6751452B1 (en) 2000-05-01 2004-06-15 General Motors Coporation Internet based vehicle data communication system
DE10027017A1 (de) * 2000-05-31 2002-02-28 Bayerische Motoren Werke Ag Betriebsverfahren für einen Datenbus für mehrere Teilnehmer
DE10030158A1 (de) * 2000-06-20 2002-01-03 Bayerische Motoren Werke Ag Steuergerät mit einem Hauptmikroprozessor und mit einer Prozessorschnittstelle zu einer Bus-Sende-Empfangseinheit
DE10034693A1 (de) * 2000-07-17 2002-02-07 Siemens Ag Verfahren zur Datenübermittlung
US6448901B1 (en) * 2000-09-11 2002-09-10 Honeywell International Inc Status indicator for an interface circuit for a multi-node serial communication system
US6373376B1 (en) 2000-09-11 2002-04-16 Honeywell International Inc. AC synchronization with miswire detection for a multi-node serial communication system
US7171613B1 (en) * 2000-10-30 2007-01-30 International Business Machines Corporation Web-based application for inbound message synchronization
DE10055938A1 (de) * 2000-11-10 2002-05-23 Hirschmann Electronics Gmbh Datenübertragung
FI115005B (fi) * 2000-11-20 2005-02-15 Vacon Oyj Toimilaitteiden ohjausjärjestelmä ja menetelmä toimilaitteiden ohjaamiseksi
US6795941B2 (en) 2000-12-21 2004-09-21 Honeywell International Inc. Method for diagnosing a network
ATE330264T1 (de) * 2000-12-29 2006-07-15 Empir Ab Steueranordnung auf der basis von can-bus- technologie
US7093050B2 (en) * 2000-12-29 2006-08-15 Empir Ab Control arrangement
FR2819324B1 (fr) * 2001-01-09 2003-04-11 Crouzet Automatismes Interface-reseau, en particulier pour protocole de type can
US7012927B2 (en) * 2001-02-06 2006-03-14 Honeywell International Inc. High level message priority assignment by a plurality of message-sending nodes sharing a signal bus
US7333504B2 (en) * 2001-03-08 2008-02-19 Honeywell International Inc. Simultaneous serial transmission of messages with data field arbitration
DE10118300B4 (de) * 2001-04-12 2006-05-18 Conti Temic Microelectronic Gmbh Verfahren zum Betreiben von elektronischen Steuereinrichtungen in einem Kraftfahrzeug
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
DE10133945A1 (de) 2001-07-17 2003-02-06 Bosch Gmbh Robert Verfahren und Vorrichtung zum Austausch und zur Verarbeitung von Daten
JP3829679B2 (ja) * 2001-10-09 2006-10-04 株式会社デンソー 通信制御装置
US7024067B2 (en) * 2001-10-19 2006-04-04 Visteon Global Technologies, Inc. Communication system with a signal conduction matrix and surface signal router
US20030095675A1 (en) * 2001-10-19 2003-05-22 Marlow C. Allen Light communication channel-based voice-activated control system and method for implementing thereof
GB2384636A (en) * 2001-10-19 2003-07-30 Visteon Global Tech Inc Communication system with a signal conduction matrix and surface signal router
US20030090161A1 (en) * 2001-10-19 2003-05-15 Marlow C. Allen Light communication channel-based electronics power distribution system
US6772733B2 (en) 2001-10-19 2004-08-10 Visteon Global Technologies, Inc. Optically controlled IPCS circuitry
US6949758B2 (en) * 2001-10-19 2005-09-27 Visteon Global Technologies, Inc. LCC-based fluid-level detection sensor
US6864653B2 (en) 2001-11-26 2005-03-08 Ebm-Papst St. Georgen Gmbh & Co. Kg Equipment fan
DE10218645A1 (de) * 2002-04-25 2003-11-13 Infineon Technologies Ag An einen Bus angeschlossene Einrichtung
DE10349600B4 (de) * 2002-10-25 2011-03-03 Infineon Technologies Ag Verfahren zur Überprüfung von Leitungsfehlern in einem Bussystem und Bussystem
DE10321679B4 (de) * 2003-05-14 2006-11-30 Siemens Ag Verfahren und Vorrichtung zur Übertragung von Daten zwischen einem zentralen Steuergerät eines Insassenschutzsystems in einem Fahrzeug und mindestens einer dezentralen Sensoreinheit
US8554860B1 (en) * 2003-09-05 2013-10-08 Sprint Communications Company L.P. Traffic segmentation
US6991302B2 (en) * 2003-09-26 2006-01-31 Haldex Brake Products Ab Brake system with distributed electronic control units
US7663915B2 (en) * 2004-02-10 2010-02-16 Semiconductor Energy Laboratory Co., Ltd. Nonvolatile memory
DE102004013629B4 (de) * 2004-03-19 2023-06-01 Volkswagen Ag Kommunikationssystem für ein Kraftfahrzeug
US20090213915A1 (en) * 2004-06-30 2009-08-27 Koninklijke Philips Electronics N.V. Method for the non-bitrate-dependent encoding of digital signals on a bus system
FR2876482B1 (fr) * 2004-10-07 2007-01-12 Siemens Transp Systems Soc Par Dispositif d'envoi de commande de sortie securisee
JP4531555B2 (ja) * 2004-12-27 2010-08-25 ルネサスエレクトロニクス株式会社 データ処理モジュール及びその送付候補メッセージの決定方法
JP4594124B2 (ja) 2005-02-07 2010-12-08 ルネサスエレクトロニクス株式会社 通信システム及び通信方法
JP2006236047A (ja) * 2005-02-25 2006-09-07 Renesas Technology Corp 半導体集積回路装置
JP4721741B2 (ja) * 2005-03-25 2011-07-13 ルネサスエレクトロニクス株式会社 データ処理モジュール及びそのメッセージ受信方法
DE102005014783A1 (de) * 2005-03-31 2006-10-05 Siemens Ag Verfahren und Vorrichtungen zum Übertragen von Daten auf eine Datenleitung zwischen einem Steuergerät und zumindest einem dezentralen Datenverarbeitungsgerät
JP2007034892A (ja) * 2005-07-29 2007-02-08 Nec Electronics Corp データ処理モジュール及びそのメッセージ送信終了処理方法
US7769932B2 (en) * 2005-09-09 2010-08-03 Honeywell International, Inc. Bitwise arbitration on a serial bus using arbitrarily selected nodes for bit synchronization
US7680144B2 (en) * 2006-09-12 2010-03-16 Honeywell International Inc. Device coupled between serial busses using bitwise arbitration
WO2010144815A2 (en) * 2009-06-11 2010-12-16 Panasonic Avionics Corporation System and method for providing security aboard a moving platform
US8327189B1 (en) 2009-12-22 2012-12-04 Emc Corporation Diagnosing an incident on a computer system using a diagnostics analyzer database
US8704960B2 (en) 2010-04-27 2014-04-22 Panasonic Avionics Corporation Deployment system and method for user interface devices
US8897974B2 (en) * 2010-06-07 2014-11-25 Gm Global Technology Operations, Llc Gear selector system
WO2012132217A1 (ja) * 2011-03-31 2012-10-04 ルネサスエレクトロニクス株式会社 Ｃａｎ通信システム、ｃａｎ送信装置、ｃａｎ受信装置、およびｃａｎ通信方法
US9577788B2 (en) 2011-06-15 2017-02-21 Denso Corporation Coding apparatus, coding method, data communication apparatus, and data communication method
JP2013058845A (ja) * 2011-09-07 2013-03-28 Denso Corp データ通信方法及びデータ通信システム
JP5532030B2 (ja) * 2011-09-07 2014-06-25 株式会社デンソー データ通信方法及びデータ通信装置
US8817810B2 (en) * 2012-06-27 2014-08-26 Nxp B.V. Communications apparatus, system and method with error mitigation
US9641267B2 (en) * 2014-06-10 2017-05-02 Halliburton Energy Services Inc. Synchronization of receiver units over a control area network bus
US9590898B2 (en) * 2015-02-17 2017-03-07 Telefonaktiebolaget L M Ericsson (Publ) Method and system to optimize packet exchange between the control and data plane in a software defined network
US10635619B2 (en) * 2016-10-12 2020-04-28 Cirrus Logic, Inc. Encoding for multi-device synchronization of devices
JP2018082247A (ja) * 2016-11-14 2018-05-24 株式会社東芝 通信装置、通信システム、通信方法及びプログラム
FR3113149A1 (fr) * 2020-07-30 2022-02-04 Psa Automobiles Sa Formatage d’informations de défaut par ajout d’identifiant
FR3113150A1 (fr) * 2020-07-30 2022-02-04 Psa Automobiles Sa Formatage d’informations de défaut par filtrage
CN112559430B (zh) * 2020-12-24 2022-07-05 上海微波技术研究所（中国电子科技集团公司第五十研究所） 适用于窄带信道单元的cpu与fpga数据交互方法和系统
DE112022000521T5 (de) 2021-03-01 2023-10-26 Rohm Co., Ltd. Sendeschaltung, elektronische steuereinheit und fahrzeug
JPWO2022185784A1 (de) 2021-03-01 2022-09-09

Family Cites Families (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3419849A (en) * 1962-11-30 1968-12-31 Burroughs Corp Modular computer system
GB1168476A (en) * 1966-05-17 1969-10-29 British Telecomm Res Ltd Improvements in or relating to data transmission systems
CH527547A (de) * 1971-08-13 1972-08-31 Ibm Verfahren zur Informationsübertragung mit Prioritätsschema in einem Zeitmultiplex-Nachrichtenübertragungssystem mit Ringleitung
JPS5312762B2 (de) * 1974-02-04 1978-05-04
DE2554775C2 (de) * 1975-12-05 1987-02-19 Robert Bosch Gmbh, 7000 Stuttgart Vorrichtung zur Datenübertragung bei Elektronikschaltungen für Kraftfahrzeuge
DE2838619A1 (de) * 1978-09-05 1980-03-20 Bosch Gmbh Robert Einrichtung zum steuern von betriebsparameterabhaengigen und sich wiederholenden vorgaengen fuer brennkraftmaschinen
US4241398A (en) * 1978-09-29 1980-12-23 United Technologies Corporation Computer network, line protocol system
US4231086A (en) * 1978-10-31 1980-10-28 Honeywell Information Systems, Inc. Multiple CPU control system
US4236213A (en) * 1978-11-27 1980-11-25 General Motors Corporation Apparatus for producing pulse width modulated signals
EP0014556B1 (de) * 1979-02-01 1983-08-03 WARD &amp; GOLDSTONE LIMITED Multiplexsystem zur Informationsverarbeitung und ein dieses System enthaltendes Fahrzeug
EP0023105A1 (de) * 1979-07-06 1981-01-28 WARD &amp; GOLDSTONE LIMITED System und Verfahren zur Verarbeitung von Multiplexinformation
JPS6041372B2 (ja) * 1979-07-19 1985-09-17 株式会社明電舎 複数のデ−タ処理装置の接続方式
US4275095A (en) * 1979-07-31 1981-06-23 Warren Consultants, Inc. Composite article and method of making same
US4319338A (en) * 1979-12-12 1982-03-09 Allen-Bradley Company Industrial communications network with mastership determined by need
DE3001331A1 (de) * 1980-01-16 1981-07-23 Robert Bosch Gmbh, 7000 Stuttgart Einrichtung zum seriellen uebertragenvon daten in und/oder aus einem kraftfahrzeug
JPS5947905B2 (ja) 1980-02-08 1984-11-22 株式会社日立製作所 共通伝送路を用いた情報の伝送方法
DE3111135A1 (de) * 1980-06-20 1982-03-11 Robert Bosch Gmbh, 7000 Stuttgart Verfahren zum regeln der verbrennung in den brennraeumen einer brennkraftmaschine
JPS6032232B2 (ja) * 1980-11-12 1985-07-26 株式会社日立製作所 デ−タバッファ制御方式
JPS57121750A (en) * 1981-01-21 1982-07-29 Hitachi Ltd Work processing method of information processing system
JPS57160236A (en) * 1981-03-28 1982-10-02 Nissan Motor Co Ltd Multiple transmission system for vehicle
US4814979A (en) * 1981-04-01 1989-03-21 Teradata Corporation Network to transmit prioritized subtask pockets to dedicated processors
US4412285A (en) * 1981-04-01 1983-10-25 Teradata Corporation Multiprocessor intercommunication system and method
US4945471A (en) * 1981-04-01 1990-07-31 Teradata Corporation Message transmission system for selectively transmitting one of two colliding messages based on contents thereof
DE3114734A1 (de) * 1981-04-11 1982-10-28 Licentia Patent-Verwaltungs-Gmbh, 6000 Frankfurt Einrichtung zur datenuebertragung zwischen einem rechner und externen teilnehmern
JPS57208746A (en) * 1981-06-18 1982-12-21 Toyota Motor Corp Transmission controlling system
FR2508257B1 (fr) * 1981-06-19 1988-04-29 Peugeot Procede de transmission de messages entre modules emetteurs recepteurs autonomes possedant des horloges et des dispositifs de synchronisation internes independants
US4482951A (en) 1981-11-12 1984-11-13 Hughes Aircraft Company Direct memory access method for use with a multiplexed data bus
US4463445A (en) * 1982-01-07 1984-07-31 Bell Telephone Laboratories, Incorporated Circuitry for allocating access to a demand-shared bus
JPS58120340A (ja) * 1982-01-13 1983-07-18 Fujitsu Ltd フレ−ム伝送方式
JPS5940728A (ja) * 1982-08-31 1984-03-06 Matsushita Electric Works Ltd 電力線搬送制御装置
JPS5970851A (ja) * 1982-10-18 1984-04-21 Caterpillar Mitsubishi Ltd 油圧補機装備車輌の用途別負荷に対応した運転指令装置
JPS5991527A (ja) * 1982-11-17 1984-05-26 Hitachi Ltd バス優先制御方式
JPS59110245A (ja) * 1982-12-15 1984-06-26 Meidensha Electric Mfg Co Ltd マルチドロツプ方式の情報伝送方式
CA1219091A (en) * 1983-01-10 1987-03-10 Ulrich Killat Method of and arrangement for controlling access to a time-division multiplex message transmission path
JPH0612895B2 (ja) * 1983-01-24 1994-02-16 株式会社東芝 情報処理システム
US4534025A (en) * 1983-02-24 1985-08-06 United Technologies Automotive, Inc. Vehicle multiplex system having protocol/format for secure communication transactions
JPS59175242A (ja) * 1983-03-25 1984-10-04 Ricoh Co Ltd Ａｒｑ伝送方式
US4561092A (en) * 1983-05-13 1985-12-24 The Bdm Corporation Method and apparatus for data communications over local area and small area networks
US4556943A (en) * 1983-05-27 1985-12-03 Allied Corporation Multiprocessing microprocessor based engine control system for an internal combustion engine
JPS60551A (ja) * 1983-06-16 1985-01-05 Hitachi Ltd 自動車用データ伝送システム
DE3335932A1 (de) * 1983-10-04 1985-04-18 Wabco Westinghouse Fahrzeugbremsen GmbH, 3000 Hannover Einrichtung zum abfragen und steuern von mehreren komponeneten eines fahrzeuges
JPS59112045A (ja) * 1983-11-17 1984-06-28 村田機械株式会社 紡績糸
US4566097A (en) * 1983-12-23 1986-01-21 International Business Machines Corp. Token ring with secondary transmit opportunities
US4652873A (en) * 1984-01-18 1987-03-24 The Babcock & Wilcox Company Access control for a plurality of modules to a common bus
US4654655A (en) * 1984-03-02 1987-03-31 Motorola, Inc. Multi-user serial data bus
CA1246681A (en) * 1985-01-30 1988-12-13 Northern Telecom Limited Terminal address assignment in a broadcast transmission system
DE3546662C3 (de) * 1985-02-22 1997-04-03 Bosch Gmbh Robert Verfahren zum Betreiben einer Datenverarbeitungsanlage
JPS61232363A (ja) * 1985-04-05 1986-10-16 Honda Motor Co Ltd 内燃エンジンの電子制御装置
US4745600A (en) * 1985-07-09 1988-05-17 Codex Corporation Network collision detection and avoidance apparatus
EP0208998A3 (de) * 1985-07-19 1989-01-04 Rodger T. Lovrenich Dezentralisiertes Steuerungssystem und Verbindung dazu
US4715031A (en) * 1985-09-23 1987-12-22 Ford Motor Company Vehicular data transfer communication system
CA1249886A (en) * 1986-05-02 1989-02-07 Claude J. Champagne Method of duplex data transmission using a send-and- wait protocol
US4769761A (en) * 1986-10-09 1988-09-06 International Business Machines Corporation Apparatus and method for isolating and predicting errors in a local area network
US4887076A (en) * 1987-10-16 1989-12-12 Digital Equipment Corporation Computer interconnect coupler for clusters of data processing devices
US5131081A (en) * 1989-03-23 1992-07-14 North American Philips Corp., Signetics Div. System having a host independent input/output processor for controlling data transfer between a memory and a plurality of i/o controllers
GB8915135D0 (en) * 1989-06-30 1989-08-23 Inmos Ltd Message routing
SE467437B (sv) * 1990-11-07 1992-07-13 Ericsson Telefon Ab L M Foerfarande att undvika interferens mellan ett foersta och ett andra meddelande i ett mobiltelefonsystem
EP0505659B1 (de) * 1991-02-28 1996-06-12 Rai Radiotelevisione Italiana Verfahren zur Nachrichtenübertragung über einen Fernsehkanal mit dem Teletextsystem

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4129412A1 (de) * 1991-09-04 1993-03-18 Nec Electronics Germany Verfahren zur datenuebertragung und datenverarbeitungsanlage mit verteilten rechnerknoten
DE4140017A1 (de) * 1991-12-04 1993-06-09 Nec Electronics (Germany) Gmbh, 4000 Duesseldorf, De Verfahren zur erzeugung einer globalen zeitbasis und datenverarbeitungsanlage mit verteilten rechnerknoten
US6292862B1 (en) 1998-07-28 2001-09-18 Siemens Aktiengesellschaft Bridge module
DE102012221633B4 (de) * 2011-11-30 2021-01-21 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) Verfahren zum Diagnostizieren eines Fehlers in einem fahrzeuginternen Kommunikationssystem
DE102015108333B4 (de) 2014-05-27 2023-06-07 GM Global Technology Operations, LLC (n.d. Ges. d. Staates Delaware) Kurzschlussfehlerisolierung in einem controller area network
DE102015108342B4 (de) 2014-05-27 2023-08-03 GM Global Technology Operations LLC (n. d. Gesetzen des Staates Delaware) Leitungsunterbrechungsfehlerdetektion und -diagnose in einem controller area network
DE112015005263B4 (de) 2014-11-20 2020-08-06 Autonetworks Technologies, Ltd. Kommunikationssystem und Kommunikationsvorrichtung
DE102020212452B3 (de) 2020-10-01 2022-01-13 Volkswagen Aktiengesellschaft Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft

Also Published As

Publication number Publication date
DE3546662C3 (de) 1997-04-03
US5303348A (en) 1994-04-12
US5001642A (en) 1991-03-19
JPH0721784B2 (ja) 1995-03-08
JPH0772883B2 (ja) 1995-08-02
JPS61195453A (ja) 1986-08-29
US5640511A (en) 1997-06-17
DE3506118A1 (de) 1986-08-28
DE3546683C2 (en) 1991-03-07
JP2545508B2 (ja) 1996-10-23
FR2578070A1 (fr) 1986-08-29
DE3546664C2 (en) 1991-03-07
US5901156A (en) 1999-05-04
JPH06236333A (ja) 1994-08-23
FR2578070B1 (fr) 1994-05-06
JPH06236328A (ja) 1994-08-23
US5621888A (en) 1997-04-15
DE3546664C3 (de) 1995-10-26
DE3546662C2 (en) 1991-03-07
DE3546683C3 (de) 2003-10-09

Similar Documents

Publication Publication Date Title
DE3506118C2 (de)
EP1298849B1 (de) Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem
DE3855590T2 (de) Bitorganisiertes Nachrichtennetzwerk
DE69432841T2 (de) Verfahren und Vorrichtung für digitale Datenübertragung in einem Nachrichtennetz
EP0576459B1 (de) Verfahren zum aufbau von botschaften für den datenaustausch und/oder für die synchronisation von prozessen in datenverarbeitungsanlagen
DE69433858T2 (de) Methode und Vorrichtung zum Austausch unterschiedlicher Arten von Daten während verschiedener Zeitintervallen
DE112015004473T5 (de) Bestätigen der datengenauigkeit in einem verteilten steuerungssystem
DE3882192T2 (de) Schnittstelleanordnung für die Verbindung zwischen einerseits getrennten Stationen und andererseits einem für den Nachrichtenverkehr zwischen diesen Stationen benutzten physikalischen Mittel.
DE69021186T2 (de) &#34;Master-Slave&#34; industrielles Netzwerk mit Tokenübergabe.
EP2434695A1 (de) Serielle ringförmige Kommunikationsanordnung und dementsprechendes Verfahren, wobei für die Übermittlung von einem Datenpaket von jedem Slave eine Adressinformation des Datenpakets geändert wird
DE69432726T2 (de) Verfahren und System zur seriellen Datenübertragung
DE3887552T2 (de) Zeitsteuerung für Doppelanschluss.
DE3855566T2 (de) Vielfach-Zeitschlitz-Zugriffssystem
EP0610202B1 (de) Verfahren zur informationsübertragung in einem mehrere teilnehmer aufweisenden bussystem
EP0150540B1 (de) Verfahren zur Datenübertragung, sowie Station zur Durchführung des Verfahrens
DE3751882T2 (de) Serieller Datenbus für Datenübertragung zwischen Modulen und Verfahren zur Datenarbitrierung und zur Kollisionsdetektion auf einem Datenbus
DE102006004191B4 (de) Deterministisches Kommunikations-System
DE102018203680A1 (de) Teilnehmerstation für ein serielles Bussystem und Verfahren zur Datenübertragung in einem seriellen Bussystem
DE3546684C2 (en) Operating communication bus network for processors
DE69627148T2 (de) Ringbusdatenübertragungssystem
WO2003036879A1 (de) Teilnehmergerät für ein hochperformantes kommunikationssystem
EP1357707A2 (de) Verfahren und Vorrichtung zur Übertragung von Nachrichten auf einem Bussystem und Bussystem
DE69021626T2 (de) Eingebettete Steuertechnik für verteilte Steuersysteme.
DE3856051T2 (de) Relaisstation für periphere Geräte
DE3329228A1 (de) Datenuebertragungsverfahren in einem digitalen uebertragungsnetzwerk und vorrichtung zur durchfuehrung des verfahrens

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
8125 Change of the main classification

Ipc: G06F 13/38

8172 Supplementary division/partition in:

Ref country code: DE

Ref document number: 3546664

Format of ref document f/p: P

Ref country code: DE

Ref document number: 3546663

Format of ref document f/p: P

Q171 Divided out to:

Ref country code: DE

Ref document number: 3546663

Ref country code: DE

Ref document number: 3546664

8172 Supplementary division/partition in:

Ref country code: DE

Ref document number: 3546662

Format of ref document f/p: P

Q171 Divided out to:

Ref country code: DE

Ref document number: 3546662

8172 Supplementary division/partition in:

Ref country code: DE

Ref document number: 3546683

Format of ref document f/p: P

Q171 Divided out to:

Ref country code: DE

Ref document number: 3546683

8172 Supplementary division/partition in:

Ref country code: DE

Ref document number: 3546684

Format of ref document f/p: P

Q171 Divided out to:

Ref country code: DE

Ref document number: 3546684

AH Division in

Ref country code: DE

Ref document number: 3546664

Format of ref document f/p: P

Ref country code: DE

Ref document number: 3546683

Format of ref document f/p: P

Ref country code: DE

Ref document number: 3546684

Format of ref document f/p: P

Ref country code: DE

Ref document number: 3546662

Format of ref document f/p: P

D2 Grant after examination
AH Division in

Ref country code: DE

Ref document number: 3546684

Format of ref document f/p: P

Ref country code: DE

Ref document number: 3546683

Format of ref document f/p: P

Ref country code: DE

Ref document number: 3546662

Format of ref document f/p: P

Ref country code: DE

Ref document number: 3546664

Format of ref document f/p: P

8363 Opposition against the patent
AH Division in

Ref country code: DE

Ref document number: 3546664

Format of ref document f/p: P

8369 Partition in:

Ref document number: 3546945

Country of ref document: DE

Format of ref document f/p: P

Q171 Divided out to:

Ref country code: DE

Ref document number: 3546945

AH Division in

Ref country code: DE

Ref document number: 3546662

Format of ref document f/p: P

8331 Complete revocation