DE3546664C2 - Operating communication bus network for processors - Google Patents

Operating communication bus network for processors

Info

Publication number
DE3546664C2
DE3546664C2 DE3546664A DE3546664A DE3546664C2 DE 3546664 C2 DE3546664 C2 DE 3546664C2 DE 3546664 A DE3546664 A DE 3546664A DE 3546664 A DE3546664 A DE 3546664A DE 3546664 C2 DE3546664 C2 DE 3546664C2
Authority
DE
Germany
Prior art keywords
error
message
bus
transmission
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
DE3546664A
Other languages
English (en)
Other versions
DE3546664C3 (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=DE3546664(C2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE3546664A priority Critical patent/DE3546664C3/de
Application granted granted Critical
Publication of DE3546664C2 publication Critical patent/DE3546664C2/de
Publication of DE3546664C3 publication Critical patent/DE3546664C3/de
Anticipated expiration legal-status Critical
Expired - Lifetime 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

Description

Die Erfindung geht aus von einem Verfahren zum Betreiben einer Datenverarbeitungsanlage 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 Kraftstoffverbrauch 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 lassen sich z. B. mit geringem Verschleiß der Kupplungsbelege und ohne störbarem Ruck durchführen, wenn im Schaltaugenblick das Motormoment durch einen entsprechenden Eingriff in die elektronische Motorsteuerung kurzzeitig reduziert wird.
Dazu ist es erforderlich, daß der Rechner für die elektronische Getriebesteuerung genau im richtigen Zeitpunkt entsprechende Daten an den Rechner mit Hilfe einer Reihe von einzelnen Signalleitungen erreicht.
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 dem 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 Übertragungsprotokolle für die Kopplung von Mikrorechnern wie z. B. DDB, IIC, MUART, CSMA, SDLC und HDLC. Diese Protokolle wurden beispielsweise in den Druckschriften Valvo, DDB-Spezifikation; Valvo, Technische Information für die Industrie 81 1215; Intel, Microprozessor and Peripheral Handbook, 1983 und A. Tannenbaum, Computer Networks, Prentice/ Hall International, 1983 vorgestellt.
2. Nachteile des Standes 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 zwischen 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 Sicherungsmaßnahmen nicht verwendet werden können.
Die Steuerungen arbeiten auch meist unter Echtzeitbedingungen, d. h. die Rechenoperation und Steuereingriffe müssen in bestimmten Zeitfensters 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, obwohl 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 beginnen. Durch diese Maßnahmen sind jedoch auch wiederholte Buszugriffskonflikte nicht auszuschließen. Dadurch wird das zuverlässige Einhalten von harten Zeitbedingungen, wie sie bei Kraftfahrzeugsteuerungen erforderlich 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 unverändertem Programm arbeiten können, wenn sich an der von ihnen realisierten Funktion nichts ändert. Bekannte Übertragungssysteme sind jedoch nicht so konzipiert, daß weitere funktionale Verknüpfungen zwischen 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 bereits auf den Bus übertragene Daten benötigt, so muß in entsprechenden, bereits vorhandenen Teilnehmern die neue Adresse ergänzt werden. Zusätzlich müssen die bereits zu anderen Teilnehmern übertragenen Daten 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 Kollisionen auf den Bus.
Im allgemeinen wird die Master-Eigenschaft nacheinander von einem Busteilnehmer 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 Prinzip möglich, erfordert aber viel Zeit (Busausfallzeit, 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 Synchronisation von Ereignissen. Sollen z. B. durch Übertragung einer Botschaft an zwei oder mehreren Teilnehmern gleichzeitig Aktionen ausgelöst werden, so muß die Botschaft von allen im genau gleichen Augenblick empfangen werden. Bei der sonst üblichen zeitlich aufeinanderfolgenden Übertragung 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 verschiedene 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 leistungsfähige Fehlererkennung. Selbst die aufwendigeren der heute bekannten Protokolle sind jedoch nicht in der Lage, ohne zusätzliche Absicherungsprogramme 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.
In dem Artikel Moelands, I²C bus in consumer applications, Electronic Components and Applications, Vol. 5, Nr. 4, 1983, Seiten 214 bis 221 sowie in der Firmenschrift Valvo, Technische Information 81 12 15, 1981 ist der an sich bekannte IIC-Bus beschrieben. In den Druckschriften wird auch die Arbitrierung bei einem Multimaster-System abgehandelt. Bei mehreren Rechnern ist nämlich darauf zu achten, daß nur einer der Rechner auf den Bus zugreifen kann, ohne daß die Daten, die auf den Bus übertragen werden sollen, verfälscht werden. Dieser Auswahlprozeß erfolgt beim I²C-Bus dadurch, daß der prioritätshöchste Rechner eine Anzahl von logischen Einsen (dominanter Status) abgibt. Rechner mit geringeren Prioritäten geben eine geringere Anzahl dominanter Signale ab. Stellt nun ein Rechner fest, daß der Bus dominante Signale enthält, obwohl er selbst eine logische Null ausgibt (rezessiver Status), zieht sich der entsprechende Rechner zurück. Auf die Fehlerbehandlung wird jedoch nicht eingegangen.
In dem Buch Färber, Bussysteme, R. Oldenbourg Verlag, München, Wien 1984, Seiten 100 bis 101 und Seiten 119 bis 121 wird die Ankopplung von Rechner an Bussysteme beschrieben sowie der D²B-Bus erläutert. Die Fehlerbehandlung ist hier auch nicht erwähnt.
Ausgehend vom aufgezeigten Stand der Technik ist es Aufgabe der Erfindung, ein Verfahren zum Betreiben einer Datenverarbeitungsanlage und ein Verfahren zum Behandeln fehlerhafter Botschaften anzugeben, mittels dem eine systemweite Datenkonsistenz im Bus erzielt wird.
Diese Aufgabe wird durch die kennzeichnenden Merkmale der Ansprüche 1 und 2 gelöst.
3. Vorteile der Erfindung
Die erfindungsgemäßen Verfahren mit den kennzeichnenden Merkmalen der Ansprüche 1 und 2 haben den Vorteil, daß mit der Übertragung einer Zustandsfolge dominanter Zustände, die sonst nicht auftreten kann, nicht nur vom Sender erkannt wird, daß eine Botschaft zumindest bei einem Rechner nicht angekommen ist, sondern auch den übrigen Rechnern die Möglichkeit geboten ist zu erkennen, daß die Botschaft zumindest von einem Rechner nicht ordnungsgemäß empfangen worden ist. Dies hat zur Folge, daß die Datenübertragung vom sendenden Rechner abgebrochen wird und auch von den übrigen Rechnern das bisher empfangene Signal verworfen wird.
Durch die in den Unteransprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im Hauptanspruch angegebenen Verfahrens möglich. Besonders vorteilhaft ist, daß die Fehlermeldung jederzeit aussendbar ist, so daß die Übertragung einer Botschaft nicht beendet werden muß, sondern die Unterbrechung auch am Anfang vorgenommen werden kann, wenn dort ein Fehler auftritt. Dies führt zu einer wesentlich verringerten Busbelegung beim Übertragen von Botschaften. Vorteilhaft ist auch, daß von jedem Teilnehmer eine Fehlermeldung ausgegebbar ist. Ohne Rücksicht auf die laufende Übertragung wird dadurch ein Abbruch der übertragenen Nachricht möglich, da es ohne Belang ist, ob der Sender ein Fehler bei der Übertragung feststellt oder ob bei einem der Empfänger ein Fehler festgestellt wird. Vorteilhaft ist auch, daß das Ende der Fehlermeldung zur zeitlichen Synchronisation aller Teilnehmer dient. Dies hat den Vorteil, daß nach der Fehlermeldung bereits eine Synchronisation der Teilnehmer vorliegt und daher eine neue Übertragung sofort begonnen werden kann. Treten mehrere Fehlermeldungen auf, dient das Ende der letzten Fehlermeldung der Synchronisation, wenn beispielsweise mehrere Stationen einen Fehler erkannt haben.
Vorteilhaft ist auch, daß die Übernahme der Botschaft in den Empfängern erst erfolgt, wenn der Empfang der Botschaft ohne Fehlererkennung abgeschlossen ist. Durch diese Maßnahme wird erreicht, daß bei allen Empfängern die Botschaft in gleicher Form zur Verfügung steht. Damit ist sichergestellt, daß sämtliche Empfänger über die gleichen Daten verfügen. Vorteilhaft ist auch, daß die Übertragung bei auftretenden Fehlern wiederholt wird, bzw. daß die Wiederholung dann abgebrochen wird, wenn eine bestimmte Anzahl von fehlerhaften Übertragungen die Übertragung abgebrochen wird. Dadurch wird verhindert, daß beispielsweise bei Fehlern im Sender oder in einem der Empfänger eine ständige Wiederholung der Nachricht erfolgt, ohne daß ein Ende abzusehen ist. Besonders vorteilhaft ist in diesem Zusammenhang, daß der Teilnehmer, der die Fehlermeldung abgibt, vom Bus abgekoppelt wird, so daß die übrigen Teilnehmer des Systems ordnungsgemäß miteinander kommunizieren können. Weiterhin ist vorteilhaft, jedem Teilnehmer lediglich einen bestimmten Teil der zeitlichen Übertragungskapazität der Leitung zur Verfügung zu stellen. Dadurch wird erreicht, daß in einem Fehlerfall nicht durch einen Teilnehmer, wenn auch nur für eine bestimmte Zeit, der Bus blockiert werden kann.
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äumliche Ausdehnung: von Übertragungsrate abhängig
Das vorgestellte Bussystem kann genau dann 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/nichtleitend
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 sehen.
Fig. 2 zeigt eine Ausführung mit galvanischer Ankopplung an die Busleitung. Die Treiber sind steuerbare Schalter, realisiert durch Transistoren (Open-Collector-Ankopplung). Als Busleitung dient ein Zweidrahtleitung oder eine 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 Übertrager eingesetzt werden. Die Gleichstromfreiheit wird durch eine Biphase-Kodierung gewonnen. Der rezessive Buszustand wird durch Abkopplung aller Übertrager 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ührung 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)
Hinweise:
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 gleichzeitigem 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-TRANSMISSION-REQUEST zeigt an, ob durch die entsprechende 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 CONTROL-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
CRC-FIELD
dieses Bitfeld enthält das mittels eines Generator- Polynoms erzeugte Kontrollwert (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 Hammind-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 CRC-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ückfü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 zumindestens 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 ununterbrochenen 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 erkenne.
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 Empfangsbereitschaft) 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 der 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. 10)
ERROR-FLAG
besteht aus einer ununterbrochenen Folge von LOWBits.
Die Länge der Folge ist so zu bestimmen, daß durch sie das Gesetz des "Bitstuffins" 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 Übertragung 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, OVERLAND)
Es bedeutet:
BUS-MONITOR
Eingangsvaribale, die den auf der Busleitung abgetasteten Logikpegel wiederspiegelt.
BUS-MONITOR=0 entspr. dominanten 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 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
OVERLAND
Zustandsvariable, die angibt, ob die letzte empfangene Botschaft von der Schnittstellenlogik aufgearbeitet werden konnte oder ob diese überlastet ist.
OVERLAND=0 Empfangslogik überlastet
OVERLAND=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 Takt 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 den Busleitungen 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 in den Zustand RECEIVE-IDENTIFIER. Beim Zustandsübergang wird der Zähler CNTR mit IFL=8 (IDENTIFIER-FIELD-LENGTH) vorbelegt. IFL gibt an wieviel Kennungsbits vereinbart wurden (siehe 4.3, IDENTIFIER).
Mit jedem empfangenen Kennungsbit wird die Schleife 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 der 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) vorgelegt 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=0 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 mit 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 (OVERLAND=1) zu melden, sodaß das Absenden der nächsen 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, selten die zum Zustand RECEIVE-IDENTIFIER gemachten Ausführungen entsprechend.
EMPFANGS-MODUS
ENTSCHEIDUNGSVEKTOR: (BUS-MONITOR, BUS-DRIVE, STUFF, COUNT, TX-REQUEST, CRC-ERROR, OVERLAND)
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-DATE-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 und daß alle Teilnehmer eine falsche Rahmensynchronisation haben. Der Sender gibt deshalb im Zustand ERROR-HANDLING eine Fehlermeldung. Bei empfangenen 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. Da END-OF-FRAME aus sieben HIGH-Bits besteht, wird der Zähler CNTR mit EOFL=7 (END-OF-FRAME-LENGTH) 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 den Ü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 erfordert 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.
FEHLER-BEHANDLUNG
ENTSCHEIDUNGSVEKTOR: (BUS-MONITOR, BUS-DRIVE, STUFF, COUNT, TX-REQUEST, CRC-ERROR, OVERLOAD)
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 Erkenntnis 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 liest.
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 abgewertet 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
Bitfehler, Buspegel stimmt nicht mit gesendeten Pegel überein.
BK Im Zustand TRANSMIT-IDENTIFIER (Arbitrierungs) und TRANSMIT-START-OF-FRAME gilt nur Buspegel HIGH bei gesendetem LOW 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 Fehlererkennungsmöglichkeiten zusammengestellt, die sich aus den Kombinationen aus zeitlichem und räumliche Auftreten sowie der Fehlerklassen ergeben. Ansonsten 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. Numerierung
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ßender 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 eine 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 gegonnen 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 keine Acknowledge und setzt ebenfalls eine Fehlermeldung ab. Dadurch erkennen die nicht gestörten Empfänger einen Fehler (ACK-DELIMITER) und sie setzten 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 S1 nicht mehr seine Übertragung zu starten, und er verhält sich bis zum Ende der Fehlerbehandlung wie ein Empfänger. S1 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 ein 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 ihre 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 Lise durchgesehen, 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 anzeigt 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 empfangenen 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öchsten 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. CONTROL-SEGMENT Organisation
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 enthält man aus dem 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, daß 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-REQUEST 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)
    Start 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. Synchronisations Problem
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 Vorgehenweise 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 empfangende 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 empfangende 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 empfangende CPU kann im CONTROL-SEGMENT der zu empfangenden 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 das 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 Quellprozeß sich gleichzeitig deaktivieren muß. Die gesamte Steuerung enthält die folgenden Prozesse 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 Bustakt 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 übertragende 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: TRANSMIT-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 TRANSMISSION-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 Search 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-Stealings-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 vorgegeben höchsten Priorität an die CPU weitergeleitet. Der INTERRUPT- HANDLING-Prozeß läuft ununterbrochen, parallel zu den anderen Prozessen. Der Anfangswert des Interrupt Pointers 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 einbezogen werden. Dies erforderte 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 leerem, 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ächlichen 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 selbst 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 and
- per for period.

Claims (14)

1. Verfahren zum Betreiben einer Datenverarbeitungsanlage, insbesondere für Kraftfahrzeuge, mit wenigstens zwei Rechnern, einer die Rechner verbindenden Leitung zum Übertragen von Botschaften (Messages), wobei auf der Leitung dominante und rezessive Zustände übertragen werden, dadurch gekennzeichnet, daß von den Rechnern eine Fehlermeldung ausgebbar ist und daß die Fehlermeldung aus einer mit bei der Übertragung von Botschaften auftretenden Zustandsfolgen nicht zu verwechselnden Zustandsfolge dominanter Zustände besteht.
2. Verfahren zum Behandeln fehlerhafter Botschaften in einem Rechner, der mit wenigstens einem weiteren Rechner über eine Leitung zur Übertragungen von Botschaften verbindbar ist, wobei auf der Leitung dominante und rezessive Zustände übertragbar sind, dadurch gekennzeichnet, daß von dem Rechner beim Auftreten eines Fehlers eine Fehlermeldung ausgebbar ist und daß die Fehlermeldung aus einer mit bei der Übertragung von Botschaften auftretenden Zustandsfolgen nicht zu verwechselnden Zustandsfolge dominanter Zustände besteht.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Fehlermeldung nach der Erkennung des Fehlers während der laufenden Übertragung einer Botschaft gesendet wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß von jedem Teilnehmer, der mit der Leitung gekoppelt ist und einen Fehler erkennt, eine Fehlermeldung ausgebbar ist.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das Ende der Fehlermeldung zur zeitlichen Synchronisation aller Teilnehmer dient.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß bei mehreren Fehlermeldungen das Ende der letzten Fehlermeldung der Synchronisation dient.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der informationstragende Teil der Botschaft mit einer nicht dominanten Zustandsfolge abgeschlossen wird.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß die nicht dominante Zustandsfolge am Ende der Botschaft um mindestens einen Zustand länger ist als die für die Fehlererkennung erforderliche minimale Zustandsfolge.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß fehlerbehaftete Übertragungen erfaßt und registriert werden.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Übernahme der Botschaft in dem Empfängern der Teilnehmer erst erfolgt, wenn der Empfang der Botschaft ohne Fehlererkennung abgeschlossen ist.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Übertragung bei auftretendem Fehler wiederholt wird.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß nach einer bestimmten Anzahl von fehlerhaften Übertragungen die Wiederholung der Übertragung abgebrochen wird und eine Unterbrechungsanforderung ausgelöst wird.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß nach einer vorgegehenen Anzahl von Fehlermeldungen eines Teilnehmers dieser vom Bus abgekoppelt wird.
14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß von jedem Teilnehmer lediglich ein bestimmter Teil der zeitlichen Übertragungskapazität der Leitung in Anspruch nehmbar ist.
DE3546664A 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage Expired - Lifetime DE3546664C3 (de)

Priority Applications (1)

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE3546664A DE3546664C3 (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

Publications (2)

Publication Number Publication Date
DE3546664C2 true DE3546664C2 (en) 1991-03-07
DE3546664C3 DE3546664C3 (de) 1995-10-26

Family

ID=6263209

Family Applications (4)

Application Number Title Priority Date Filing Date
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
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 Before (3)

Application Number Title Priority Date Filing Date
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
DE3546662A Expired - Lifetime DE3546662C3 (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) DE3506118A1 (de)
FR (1) FR2578070B1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10118300A1 (de) * 2001-04-12 2002-11-07 Conti Temic Microelectronic Verfahren zum Betreiben von elektronischen Steuereinrichtungen in einem Kraftfahrzeug

Families Citing this family (141)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3506118A1 (de) * 1985-02-22 1986-08-28 Robert Bosch Gmbh, 7000 Stuttgart Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge
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
DE4129412C2 (de) * 1991-09-04 1994-10-27 Nec Electronics Germany Verfahren zur Datenübertragung in einer Datenverarbeitungsanlage
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
WO1993011002A1 (de) * 1991-11-26 1993-06-10 Siemens Aktiengesellschaft Bussystem
DE4140017C2 (de) * 1991-12-04 1995-01-05 Nec Electronics Germany Verfahren zum Betreiben von über einen Datenbus durch seriellen Datenaustausch miteinander kommunizierenden Rechnereinheiten
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 株式会社デンソー エンジン用制御装置
DE69512443T2 (de) * 1994-02-02 2000-05-04 Mannesmann Vdo Ag 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
WO1998005139A1 (de) 1996-07-24 1998-02-05 Robert Bosch Gmbh Verfahren zur synchronisierung von daten, schnittstellen zur übertragung und zum empfang
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
US5813972A (en) * 1996-09-30 1998-09-29 Minnesota Mining And Manufacturing Company Medical perfusion system with data communications network
US5752931A (en) * 1996-09-30 1998-05-19 Minnesota Mining And Manufacturing Company Perfusion system with perfusion circuit display
US6164920A (en) * 1996-09-30 2000-12-26 Minnesota Mining And Manufacturing Company Perfusion system with control network
US5995512A (en) * 1997-01-17 1999-11-30 Delco Electronics Corporation High speed multimedia data network
JP3117000B2 (ja) * 1997-02-21 2000-12-11 株式会社デンソー 通信システムおよびそれに使用される電子制御装置
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
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
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
US6292862B1 (en) 1998-07-28 2001-09-18 Siemens Aktiengesellschaft Bridge module
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
US6754183B1 (en) 1999-06-14 2004-06-22 Sun Microsystems, Inc. System and method for integrating a vehicle subnetwork into a primary network
US6507810B2 (en) 1999-06-14 2003-01-14 Sun Microsystems, Inc. Integrated sub-network for a vehicle
US6975612B1 (en) 1999-06-14 2005-12-13 Sun Microsystems, Inc. System and method for providing software upgrades to a vehicle
US6253122B1 (en) 1999-06-14 2001-06-26 Sun Microsystems, Inc. Software upgradable dashboard
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
US6427180B1 (en) * 1999-06-22 2002-07-30 Visteon Global Technologies, Inc. Queued port data controller for microprocessor-based engine control applications
US6728268B1 (en) * 1999-06-22 2004-04-27 Trimble Navigation Ltd. Method and system to connect internet protocol hosts via an application specific bus
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
US6373376B1 (en) 2000-09-11 2002-04-16 Honeywell International Inc. AC synchronization with miswire detection for a multi-node serial communication system
US6448901B1 (en) * 2000-09-11 2002-09-10 Honeywell International Inc Status indicator for an interface circuit 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
US7093050B2 (en) * 2000-12-29 2006-08-15 Empir Ab Control arrangement
ATE330264T1 (de) * 2000-12-29 2006-07-15 Empir Ab Steueranordnung auf der basis von can-bus- technologie
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
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 株式会社デンソー 通信制御装置
GB2385665B (en) * 2001-10-19 2004-06-02 Visteon Global Tech Inc Engine combustion monitoring and control with intergrated cylinder head gasket combustion sensor
US20030095675A1 (en) * 2001-10-19 2003-05-22 Marlow C. Allen Light communication channel-based voice-activated control system and method for implementing thereof
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
US7024067B2 (en) * 2001-10-19 2006-04-04 Visteon Global Technologies, Inc. Communication system with a signal conduction matrix and surface signal router
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
WO2006003540A1 (en) * 2004-06-30 2006-01-12 Philips Intellectual Property & Standards Gmbh 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
EP2441229B1 (de) * 2009-06-11 2020-05-06 Panasonic Avionics Corporation System und verfahren zur bereitstellung von sicherheit auf einer beweglichen plattform
US8327189B1 (en) 2009-12-22 2012-12-04 Emc Corporation Diagnosing an incident on a computer system using a diagnostics analyzer database
CN102971214B (zh) 2010-04-27 2016-01-13 松下航空电子公司 用于用户接口设备的连接支撑系统及方法
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
JP5532030B2 (ja) * 2011-09-07 2014-06-25 株式会社デンソー データ通信方法及びデータ通信装置
JP2013058845A (ja) * 2011-09-07 2013-03-28 Denso Corp データ通信方法及びデータ通信システム
US9160620B2 (en) * 2011-11-30 2015-10-13 GM Global Technology Operations LLC Integrated fault diagnosis and prognosis for in-vehicle communications
US8817810B2 (en) * 2012-06-27 2014-08-26 Nxp B.V. Communications apparatus, system and method with error mitigation
US9678131B2 (en) 2014-05-27 2017-06-13 GM Global Technology Operations LLC Method and apparatus for short fault isolation in a controller area network
US9568533B2 (en) 2014-05-27 2017-02-14 GM Global Technology Operations LLC Method and apparatus for open-wire fault detection and diagnosis in a controller area network
WO2015191053A1 (en) * 2014-06-10 2015-12-17 Halliburton Energy Services, Inc. Synchronization of receiver units over a control area network bus
JP6282216B2 (ja) 2014-11-20 2018-02-21 国立大学法人名古屋大学 通信システム及び通信装置
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
DE102020212452B3 (de) 2020-10-01 2022-01-13 Volkswagen Aktiengesellschaft Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft
CN112559430B (zh) * 2020-12-24 2022-07-05 上海微波技术研究所（中国电子科技集团公司第五十研究所） 适用于窄带信道单元的cpu与fpga数据交互方法和系统
CN116941225A (zh) 2021-03-01 2023-10-24 罗姆股份有限公司 发送电路、电子控制单元和车辆
CN116918308A (zh) * 2021-03-01 2023-10-20 罗姆股份有限公司 延迟信号产生电路、发送电路、电子控制单元和车辆

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE1449532B2 (de) * 1962-11-30 1974-01-10 Burroughs Corp., Detroit, Mich. (V.St.A.) Datenverarbeitungsanlage
JPS5616224A (en) * 1979-07-19 1981-02-17 Meidensha Electric Mfg Co Ltd Connection system for plural data processors

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
DE2554775A1 (de) * 1975-12-05 1977-06-16 Bosch Gmbh Robert Verfahren und vorrichtung zur datenuebertragung zwischen einem zentralen speicher und mindestens einem angeschlossenen rechner
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
GB2058418A (en) * 1979-07-06 1981-04-08 Ward Goldstone Ltd A multiplex information handling system
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
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
US4412285A (en) * 1981-04-01 1983-10-25 Teradata Corporation Multiprocessor intercommunication system and method
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
DE3506118A1 (de) * 1985-02-22 1986-08-28 Robert Bosch Gmbh, 7000 Stuttgart Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge
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
ATE139400T1 (de) * 1991-02-28 1996-06-15 Rai Radiotelevisione Italiana Verfahren zur nachrichtenübertragung über einen fernsehkanal mit dem teletextsystem

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE1449532B2 (de) * 1962-11-30 1974-01-10 Burroughs Corp., Detroit, Mich. (V.St.A.) Datenverarbeitungsanlage
JPS5616224A (en) * 1979-07-19 1981-02-17 Meidensha Electric Mfg Co Ltd Connection system for plural data processors

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DE-B.: FÄRBER, G., Bussysteme, R. Oldenbourg Verlag, München, 1981, S. 100-101 und 119-121 *
DE-Firmenschrift: VALVO, Technische Information 811215, 1981 *
DE-Z: "Elektronik", 12/15.6.84, S. 76-81 *
MOELANDS, A., I2C bus in consumer applications, Philips Electronic Components and Applications, Vol. 5, No. 4, 1983, S. 214-221 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10118300A1 (de) * 2001-04-12 2002-11-07 Conti Temic Microelectronic Verfahren zum Betreiben von elektronischen Steuereinrichtungen in einem Kraftfahrzeug
DE10118300B4 (de) * 2001-04-12 2006-05-18 Conti Temic Microelectronic Gmbh Verfahren zum Betreiben von elektronischen Steuereinrichtungen in einem Kraftfahrzeug

Also Published As

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

Similar Documents

Publication Publication Date Title
DE3546664C2 (en) Operating communication bus network for processors
DE3043894C2 (de)
EP1298849B1 (de) Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem
DE69433882T2 (de) Vorrichtung zur Übertragung von Daten
EP2434695B1 (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
EP0772832B1 (de) Arbitrierung bei verzögernder buskopplung
DE69432842T2 (de) Nachrichtennetz mit zeitkoordinierter Stationsaktivität
DE3204905C2 (de)
DE69433858T2 (de) Methode und Vorrichtung zum Austausch unterschiedlicher Arten von Daten während verschiedener Zeitintervallen
DE3317567C2 (de) Rechnergesteuertes Zeitmultiplex-System
DE112015004473T5 (de) Bestätigen der datengenauigkeit in einem verteilten steuerungssystem
DE69433232T2 (de) Digitales Nachrichtennetz mit Auswahlprozess einer Moderatorstation
DE4129205A1 (de) Verfahren zum aufbau von botschaften fuer den datenaustausch und/oder fuer die synchronisation von prozessen in datenverarbeitungsanlagen
EP0144403B1 (de) Verfahren und anordnung zum übertragen von informationen in einem datenring
WO2014096278A1 (de) Datenübertragungsprotokoll mit protokollausnahmezustand
DE102007032845B4 (de) Feldbus-Stecker mit integriertem bidirektionalen Bus-Repeater zur Kopplung von Bus-Teilnehmern und Verfahren hierzu
EP1881413B1 (de) Kommunikationssystem für den flexiblen Einsatz in unterschiedlichen Einsatzfällen der Automatisierungstechnik
DE3546684C2 (en) Operating communication bus network for processors
DE102018203680A1 (de) Teilnehmerstation für ein serielles Bussystem und Verfahren zur Datenübertragung in einem seriellen Bussystem
WO1993001668A1 (de) Verfahren zur informationsübertragung in einem mehrere teilnehmer aufweisenden bussystem
DE102006004191B4 (de) Deterministisches Kommunikations-System
EP2538618A1 (de) Verfahren zur Übertragung von Datenpaketen
WO2003036879A1 (de) Teilnehmergerät für ein hochperformantes kommunikationssystem
EP1329057B1 (de) Verfahren für den Zugriff aauf einen Datenbus zwischen kommunizierenden elektronischen einheiten
DE10216920A1 (de) Verfahren und Vorrichtung zur Überprüfung einer Überwachungsfunktion eines Bussystems und Bussystem

Legal Events

Date Code Title Description
Q172 Divided out of (supplement):

Ref country code: DE

Ref document number: 3506118

8110 Request for examination paragraph 44
AC Divided out of

Ref country code: DE

Ref document number: 3506118

Format of ref document f/p: P

AC Divided out of

Ref country code: DE

Ref document number: 3506118

Format of ref document f/p: P

D2 Grant after examination
8363 Opposition against the patent
8366 Restricted maintained after opposition proceedings
8305 Restricted maintenance of patent after opposition
AC Divided out of

Ref country code: DE

Ref document number: 3506118

Format of ref document f/p: P

D4 Patent maintained restricted