DE3546662C3 - Verfahren zum Betreiben einer Datenverarbeitungsanlage - Google Patents

Verfahren zum Betreiben einer Datenverarbeitungsanlage

Info

Publication number
DE3546662C3
DE3546662C3 DE3546662A DE3546662A DE3546662C3 DE 3546662 C3 DE3546662 C3 DE 3546662C3 DE 3546662 A DE3546662 A DE 3546662A DE 3546662 A DE3546662 A DE 3546662A DE 3546662 C3 DE3546662 C3 DE 3546662C3
Authority
DE
Germany
Prior art keywords
error
bus
message
state
bit
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
DE3546662A
Other languages
English (en)
Other versions
DE3546662C2 (en
Inventor
Uwe Dr Kiencke
Siegfried Dr Dais
Wolfgang Krampe
Martin Litschel
Wolfgang Botzenhardt
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=DE3546662(C3) "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 DE3546662A priority Critical patent/DE3546662C3/de
Application granted granted Critical
Publication of DE3546662C2 publication Critical patent/DE3546662C2/de
Publication of DE3546662C3 publication Critical patent/DE3546662C3/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. zur Abarbeitung von zu übertragenden 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 für die elektronische Motorsteuerung überträgt. Bislang wurde dies 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 den im Kraftfahrzeug installierten Rechnern, die wenig Anschlüsse im Steuergerätstecker benötigt und bei der die Information in kodierter Form übertragen wird. Es ist bereits bekannt, lokale Netzwerke zur Kopplung von Mikroprozessoren, Minirechnern und Peripheriegeräten insbesondere für nachrichtentechnische Anwendungen zu betreiben. So gibt es bereits eine große Anzahl verschiedener Ü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 Zeitfenstern 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 andern 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 mehrere Teilnehmer 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.
Aus der US-PS 43 66 479 ist eine Informationsanlage bekanntgeworden, bei der mehrere Stationen ringförmig miteinander verbunden sind. Von einer Sendestation werden Daten ausgegeben, die von jeder der im Ring verbundenen Stationen der Reihe nach empfangen werden und gegebenenfalls ausgewertet werden. Nach welchen Gesichtspunkten die Daten gesendet werden, lassen sich dieser Druckschrift nicht entnehmen. Aus der Veröffentlichung IEE, Conference Publication Nummer 229, 4. International Conference on Automotive Electronics, 14. bis 18. November 1983, Seiten 160 bis 164, ist ein Bussystem für Kraftfahrzeuge bekanntgeworden, bei dem zwischen den Einheiten Botschaften übertragen werden. Über Prioritäten ist dieser Druckschrift nichts zu entnehmen. Aus der Druckschrift VDI-Berichte Nr. 515, 1984, Seiten 227 bis 235, ist ein Bussystem für Kraftfahrzeuge bekanntgeworden, das die serielle Datenübertragung gestattet. Das Zugriffsrecht bei der Datenübertragung ergibt sich hier aus einem Prioritätenvergleich. Zu diesem Zweck wird die Priorität der laufenden Übertragung an allen Knoten des Verbundsystems gespeichert. Will ein Steuergerät den Bus belegen, so wird zunächst die Priorität seiner Daten mit der laufenden Priorität verglichen. Ist die laufende Priorität niedriger, so wird die laufende Übertragung durch eine Kollision abgebrochen und die höher priorisierten Daten werden übertragen. Die abgebrochene Übertragung wird danach wiederholt. Dieser Druckschrift lassen sich keine Hinweise dahingehend entnehmen, wie in den einzelnen Stationen die Priorität der Daten festgelegt wird.
Ausgehend vom aufgezeigten Stand der Technik ist es Aufgabe der Erfindung, ein Verfahren zum Betreiben einer Datenverarbeitungsanlage und ein Verfahren zur Abarbeitung von zu übertragenden Botschaften anzugeben, durch das gewährleistet ist, daß immer die prioritätshöchste Information der entsprechenden Station zur Übertragung ansteht.
Diese Aufgabe wird durch die kennzeichnenden Merkmale der Ansprüche 1 und 2 gelöst.
3. Vorteile der Erfindung
Das erfindungsgemäße Verfahren mit den kennzeichnenden Merkmalen des Hauptanspruchs hat den Vorteil, daß für jede Datenverarbeitungsanlage bzw. für jedes Steuergerät die Prioritäten in diesem Steuergerät individuell festgelegt werden können. Aufgrund der individuellen Festlegung der Prioritäten in einem Steuergerät wird es möglich festzulegen, welche Daten eines Steuergerätes zuerst auf den Bus übertragen werden. Dadurch wird es möglich, daß z. B. in einem Steuergerät die Drehzahl die höchste Priorität zugeordnet bekommt, während in einem anderen Steuergerät ein Einspritzsignal die höchste Priorität genießt.
Durch die Unteransprüche ergeben sich vorteilhafte Weiterbildungen und Verbesserungen des Verfahrens gemäß der Ansprüche 1 und 2. Besonders vorteilhaft ist es, der Liste als weitere Information ein Hinweis bezüglich des Übertragungszustandes einer Botschaft zuzuordnen. Durch diese Maßnahme kann leicht festgestellt werden, welche Botschaft gerade übertragen werden soll und deswegen bei der Bearbeitungspriorität nicht mehr zu berücksichtigen ist. Weiterhin ist vorteilhaft, daß die Liste eine Information bezüglich der Übertragungsanforderungen enthält, die vom Teilnehmer selbst oder von den übrigen mit der Leitung gekoppelten Einrichtungen bestimmt wird. Durch diese Maßnahme wird erreicht, daß eventuell die Bearbeitungspriorität verschoben wird, weil beispielsweise eine bestimmte Information von mehreren Stationen dringend angefordert wird. Dadurch kann daher erreicht werden, daß die Bearbeitungspriorität nicht starr festgelegt ist, sondern in Abhängigkeit von Anforderungen veränderbar ist.
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 Bustopolosien, Ankopplungs- und Leitungsarten in Abhängigkeit von dem gewählten Übertragungsmedium.
Tabelle 1
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
liest an / liest 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 (Oren-Collector-Ankopplung). Als Busleitung dient eine Zweidrahtleitung oder ein Koaxkabel. Die Ansteuerung erfolgt asymmetrisch. Am Ende der Busleitung wird über Widerstände eine Versorgungsspannung angelegt. Der dominante Buszustand liegt dann vor, wenn mindestens ein Treibertransistor leitet.
Fig. 3 zeigt eine Ausführung, bei der als Sendetreiber zwei komplementäre Treibertransistoren eingesetzt werden, die gleichzeitig leitend bzw. sperrend gesteuert werden. Die Leitung wird dadurch symmetrisch angesteuert. Der Vorteil dieser Anordnung liegt in einer höheren Störfestigkeit und in einer niedrigeren Störabstrahlung.
Bei den oben gezeigten Ausführungen ist die Busleitung galvanisch mit den einzelnen Stationen verbunden. Dadurch können in elektrisch bzw. in elektromagnetisch gestörter Umgebung Probleme auftreten, wenn die Stationen über weitere Leitungen (z. B. Stromversorgungen) verkoppelt sind. Die folgenden Beispiele weisen diesen Nachteil nicht auf.
Fig. 4 zeigt eine Ausführung, bei der zur galvanischen Trennung Ü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).
HINWEIS:
In dieser Beschreibung werden die Begriffe HIGH und LOW im Sinne logischer Pegel verwendet.
Während HIGH in seiner Wirkung auf dem Bus rezessiv ist, ist LOW dominant. Das hat zur Folge, daß von allen Busteilnehmern LOW empfangen wird, sofern mindestens einer von mehreren Busteilnehmern LOW sendet.
START-OF-FRAME
markiert den Botschaftsanfang und besteht aus einem einzigen LOW Bit.
Ein Busteilnehmer darf nur im Zustand BUS-IDLE (siehe Abschnitt 4.5), d. h. wenn der Bus frei ist, die Übertragung einer Botschaft beginnen. Alle Empfänger synchronisieren sich auf die führende, durch START-OF-FRAME verursachte Flanke.
IDENTIFIER
kennzeichnet den Inhalt des Datenfeldes (DATA-FIELD) im Sinne eines Namens und einer Priorität.
Der IDENTIFIER hat nicht zwangsläufig die Bedeutung einer Adresse, die einen einzigen Empfänger aus einer Vielzahl von Busteilnehmern bestimmt. Ob eine korrekt empfangene Botschaft von den Busteilnehmern weiter bearbeitet wird oder nicht, wird ausschließlich durch das AKZEPTANZ-FILTER (siehe Abschnitt 4.7.1.1.3.) eines jeden Busteilnehmers bestimmt. Aus der Sicht eines Senders gibt es deshalb keinen Unterschied zwischen einer Punkt-zu-Punkt- Übertragung und der gleichzeitigen Ansprache einiger oder aller Busteilnehmer.
Bei 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 Kontrollwort (CRC-SEQUENCE), es wird mit einem CRC-DELIMITER abgeschlossen (Fig. 9).
Das Generator-Polynom ist für kleine Botschaftslängen (kleiner 120 zu sichernde Bits) ausgewählt, womit eine höhere 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 erster 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 erkennen.
Tastet der Sender während END-OF-FRAME zumindest ein LOW Bit (z. B. Bit von ERROR-FLAG) auf dem Bus ab, so wird dies von dem zuletzt aktiven Sender als Reaktion auf die soeben von ihm übertragene Botschaft angesehen. Dadurch besteht eine eindeutige Zuordnung von Fehlermeldungen, auch wenn der Fehlerzustand erst mit der Übertragung des zweitletzten Bits einer Botschaft durch einen der Empfänger erkannt wird.
In dem vorliegenden Ausführungsbeispiel ist END-OF-FRAME sieben Bits lang.
(EDFL = 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 Empfangsbereitsschaft) 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 den Bitfeldern ERROR-FLAG und ERROR-DELIMITER (siehe Fig. 10)
ERROR-FLAG
besteht aus einer ununterbrochenen Folge von LOW-Bits.
Die Länge der Folge ist so zu bestimmen, daß durch sie das Gesetz des "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-LENGTH = 7)
(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 Storfbits muß invers zu der der vorangegangenen Bits sein (Fehlerprüfung).
  • (5) FEHLERMELDUNG
    Jeder Busteilnehmer, der einen Übertragungsfehler feststellt, teilt dies allen anderen Busteilnehmern mit, indem er sechs aufeinanderfolgende 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 Entscheidungsfaktor zusammengefaßt werden.
Der Entscheidungsvektor hat folgende Formel:
(BUS-MONITOR, BUS-DRIVE, STUFF, COUNT, TX-REQUEST, CRC-ERROR, OVERLOAD)
Es bedeutet:
BUS-MONITOR
Eingangsvaribale, die den auf der Busleitung abgetasteten Logikpegel wiederspiegelt.
BUS-MONITOR = 0 entspr. dominantem Buspegel (LOW)
BUS-MONITOR = 1 entspr. rezessivem Buspegel (HIGH)
BUS-DRIVE
Zustandsvariable, die den Logikpegel angibt, der in diesem Zustand gesendet wird.
BUS-DRIVE = 0 Sendepegel dominant (LOW)
BUS-DRIVE = 1 Senderpegel 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
OVERLOAD
Zustandsvariable, die angibt, ob die letzte empfangene Botschaft von der Schnittstellenlogik aufgearbeitet werden konnte oder ob diese überlastet ist.
OVERLOAD = 0 Empfangslogik überlastet
OVERLOAD = 1 Empfangslogik bereit
Mit dem Entscheidungsvektor ist eindeutig festgelegt, in welchen Folgezustand gegangen wird. Der Zustandsgraph kann deshalb mit Hilfe der Entscheidungsvektoren beschrieben werden. Ist für ein bestimmtes Element im Zustandsvektor ein "x" angegeben, so bedeutet dies, daß die entsprechende Variable für die Entscheidung nicht relevant ist (die Variable darf "0" oder "1" sein).
4.5.2. Beschreibungsbeispiel für den Zustand BUS-IDLE
Der Zustand BUS-IDLE ist der reguläre Folgezustand des Zustands TEST-INTERMISSION. Im Zustand BUS-IDLE wird stets der rezessive Sendepegel HIGH auf die Busleitung gelegt.
Übergänge in Folgezustände:
  • 1) Entscheidungsvektor (1,1,1,x,0,x,x):
    Dieser Entscheidungsvektor bedeutet folgendes:
    Buspegel HIGH, Sendepegel HIGH, Bus war schon mind. fünf Takte lang HIGH, Zähler nicht relevant, keine Sendeanforderung, Übertragungsfehler und Überlastung nicht relevant. Da keine Busaktion detektiert wurde und keine Sendeanforderung vorlag, ist der Folgezustand wieder BUS-IDLE.
  • 2) Entscheidungsfaktor (1,1,1,x,1,x,x):
    Jetzt liegt bei sonst gleichen Variablen wie in 1) eine Sendeanforderung vor. Da die Busleitung frei ist, kann sofort mit dem Senden begonnen werden. Der Folgezustand ist also TRANSMIT-START-OF-FRAME.
  • 3) Entscheidungsvektor (0,1,0,x,x,x,x):
    Auf der Busleitung wurde der Pegel LOW detektiert, das heißt, daß mindestens ein anderer Busteilnehmer begonnen hat, eine Botschaft zu übertragen. Das detektierte LOW-Bit ist START-OF-FRAME. Der Folgezustand ist RECEIVE-IDENTIFIER.
  • 4) Alle weiteren Entscheidungsvektoren deuten auf eine Hardware-Störung bzw. auf einen Hardware-Ausfall innerhalb des Schnittstellenbausteins hin.
Entsprechendes gilt für alle anderen Systemzustände, die in den Zustandsgraphen EMPFANGSMODUS, SENDEMODUS und FEHLER-BEHANDLUNG beschrieben werden.
Neben den Entscheidungsvektoren, die sich aufgrund von Störungen auf der Busleitung ergeben, werden nur die Vektoren aufgeführt, die bei funktionsfähiger Hardware auftreten können. Die restlichen Vektoren kann man entweder zur Vereinfachung des Steuerwerks ausnützten 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 das Stuffbit ausgeblendet. Ist danach immer noch Stuff = 1, so muß eine Ausnahmesituation vorliegen (Störung auf Busleitung, Fehlermeldung eines anderen Teilnehmers, unerwartete Busruhe); als Reaktion darauf wird in den Zustand ERROR-HANDLING gegangen. Ist jedoch STUFF = 0, so kann der Rücksprung in den Zustand RECEIVE-IDENTIFIER erfolgen.
Nach Ablaufen des Zählers geht das System (entweder aus dem Zustand RECEIVE-IDENTIFIER oder IGNORE-ID-STUFFB) in den Zustand RECEIVE-CONTROL-FIELD über. Hier wird der Zähler mit CFL = 8 (CONTROL-FIELD-LENGTH) vorbelegt.
Sind alle Bits des CONTROL-FIELDs empfangen, so wird als nächstes in Zustand RECEIVE-DATA-FIELD das Datenfeld empfangen. Als Besonderheit gilt hier, daß der Zähler nicht mit einer Konstanten, sondern mit der Variablen DFL (DATA-FIELD-LENGTH) vorbelegt wird. DFL kann die Werte 8, 16, 32 oder 64 annehmen.
Als nächstes wird im Zustand RECEIVE-CRC-SEQUENCE das CRC-Kontrollwort (CRC-SEQUENCE) empfangen. Hierzu wird zunächst der Zähler CNTR mit CRCL = 15 (CRC-SEQUENCE-LENGTH) vorbelegt. Nach dem Empfang des letzten CRC-Bits wird die Zustandsvariable CRC-ERROR gesetzt (CRC-ERROR = 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 fehlerhaften Fall wurde die Botschaft jetzt vollständig empfangen. Als nächstes folgt der Zustand TEST-INTERMISSION, der aus IML = 3 (INTERMISSION-LENGTH) Zyklen besteht. Der Buspegel muß dauernd HIGH sein, sonst wird nach ERROR-HANDLING gesprungen. Im Zustand TEST-INTERMISSION hat jeder Empfänger die Möglichkeit eine Überlastung (OVERLOAD = 1) zu melden, so daß das Absenden der nächsten Botschaft verzögert wird, bis der Empfänger wieder bereit ist. Auch dies geschieht durch ERROR-HANDLING. Nach Ablauf des Zählers CNTR wird in den Folgezustand BUS-IDLE übergegangen, mit dem ein neuer Empfangs- oder Sendezyklus beginnt.
Bezüglich der Stuffbits, die in den Feldern CONTROL-FIELD, DATA-FIELD und CRC-SEQUENCE auftreten können, gelten die zum Zustand RECEIVE-IDENTIFIER gemachten Ausführungen entsprechend.
EMPFANGS-MODUS
ENTSCHEIDUNGSVEKTOR: (BUS-MONITOR, BUS-DRIVE, STUFF, COUNT, TX-REQUEST, CRC-ERROR- OVERLOAD)
4.5.4. Zustandsdiagramm SENDE-MODUS
Vom Zustand BUS-IDLE aus erfolgt der Übergang in den Sendemodus dann, wenn vor oder während BUS-IDLE eine Sendeanforderung eintrifft (TX-REQUEST = 1). Siehe hierzu Zustandsgraph RECEIVE-MODE.
Das Senden einer Botschaft beginnt mit dem Zustand TRANSMIT- START-OF-FRAME, in dem der dominante Sendepegel LOW ausgegeben wird. Falls eine Störung den dominanten Pegel LOW in HIGH verfälscht, wird zum Zustand ERROR-HANDLING übergegangen.
Sonst folgt im Zustand TRANSMIT-IDENTIFIER die Buszuteilungsprozedur. Am Anfang wird der Zähler auf IFL = 8 (IDENTIFIER-FIELD-LENGTH) gesetzt.
Im Zustand TRANSMIT-IDENTIFIER wird verblieben (lediglich der Zähler wird dekrementiert), wenn der empfangene Pegel dem gesendeten entspricht und die letzten fünf Buspegel nicht konstant waren und der Zähler noch nicht abgelaufen ist.
Der Zustand TRANSMIT-IDENTIFIER wird verlassen, wenn
  • - der gesendete rezessive HIGH-Pegel durch LOW überschrieben wurde. Die Buszuteilung ist damit verloren. Falls STUFF = 1 ist, ist der Folgezustand IGNORE-ID-STUFFB. Sonst ist bei nicht abgelaufenem Zähler der Folgezustand RECIEVE-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 abgelaufenem Zähler wurde die Buszuteilung gewonnen, der Folgezustand ist TRANSMIT-CONTROL-FIELD.
Beim Einstieg in den Zustand TRANSMIT-CONTROL-FIELD wird der Zähler CNTR mit CFL = 8 initialisiert (CONTROL-FIELD-LENGTH). Da die Buszuteilung beendet ist, muß ab jetzt der Sende- und Empfangs-Pegel stets gleich sein. Ist dies nicht der Fall, so wird in den Zustand ERROR-HANDLING übergegangen. Bei nicht abgelaufenem Zähler und bei Flankenwechsel innerhalb der letzten fünf Taktzyklen bleibt das System im Zustand TRANSMIT-CONTROL-FIELD, lediglich der Zähler wird dekrementiert. Das Einfügen von Stuffbits geschieht im Zustand INSERT-CF-STUFFB. Bei abgelaufenem Zähler erfolgt der Übergang in den Folgezustand TRANSMIT-DATA-FIELD.
Die Vorgänge im Zustand TRANSMIT-CONTROL-FIELD gelten auch für die Zustände TRANSMIT-DATA-FIELD und TRANSMIT-CRC-SEQUENCE. Beim Einstieg in TRANSMIT-DATA-FIELD wird der Zähler CNTR mit der Variablen DFL (DATA-FIELD-LENGTH) vorbelegt, die die Werte 8, 16, 32 oder 64 annehmen kann. Beim Einstieg in TRANSMIT-CRC-SEQUENCE wird der Zähler mit der Konstanten CRCL = 15 (CRC-FIELD-LENGTH) vorbelegt.
Im Anschluß an die CRC-SEQUENCE muß der CRC-DELIMITER übertragen werden. Dies geschieht im Zustand TRANSMIT-CRC-DELIMITER. Falls der gesendete HIGH-Zustand nach LOW verfälscht wird, wird in den Zustand ERROR-HANDLING übergegangen.
Als nächstes wird das Acknowledge-Bit geprüft. Ein empfangener HIGH-Pegel bedeutet, daß kein Teilnehmer die Botschaft fehlerfrei empfangen hat oder daß alle Teilnehmer eine falsche Rahmensynchronisation haben. Der Sender gibt deshalb im Zustand ERROR-HANDLING eine Fehlermeldung. Bei empfangenem LOW-Pegel wird in den Folgezustand RECEIVE-ACK-DELIMITER übergegangen. Der ACK-DELIMITER muß stets HIGH sein. Ist dies nicht der Fall, so wird nach ERROR-HANDLING gesprungen.
Das Botschaftsende wird im Zustand TRANSMIT-END-OF-FRAME übertragen. 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 dem Übergang in den Zustand TEST-INTERMISSION ist der TRANSMIT-MODE beendet. Der Zustand TEST-INTERMISSION ist mit dem im RECIEVE-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 den Bus ein Übertragungsfehler stattgefunden hat oder daß ein Empfänger überlastet ist. Das ERROR-FLAG besteht aus sechs aufeinanderfolgenden LOW-Bits, deshalb wird der Zähler CNTR beim Einstieg in SEND-ERROR-FLAG auf EFL = 6 (ERROR-FLAG-LENGTH) gesetzt. Falls eine Störung die gesendeten dominanten Pegel LOW nach HIGH verfälscht, wird noch einmal mit ERROR-HANDLING begonnen. Sonst wird der Zähler dekrementiert. Beim Zählerstand Null erfolgt der Übergang zum Zustand ERROR-SYNC.
Im Zustand ERROR-SYNC wird gewartet, bis andere Teilnehmer, die eventuell auch ein ERROR-FLAG senden, fertig sind. Dies wird daran erkannt, daß der Buspegel nach HIGH geht.
Die Fehlerbehandlung wird durch das Senden des ERROR-DELIMITERs im Zustand SEND-ERROR-DELIMITER abgeschlossen. Beim Einstieg wird der Zähler CNTR mit EDL-1 = 6 (ERROR-DELIMITER-LENGTH = 7) vorbelegt. Der ERROR-DELIMITER besteht aus sieben HIGH-Bits, das erste dieser Bits wurde jedoch bereits im Zustand ERROR-SYNC gesendet. Wird beim Senden der restlichen Bits auf dem Bus ein LOW-Pegel entdeckt, so wird erneut mit ERROR-HANDLING begonnen. Sonst wird nach dem Ablaufen des Zählers zum Zustand TEST-INTERMISSION weitergegangen. Damit ist die Fehlerbehandlung beendet.
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 Erkennung eines CRC-Fehlers wird die Fehlermeldung erst drei Takte später abgeschickt. Dadurch wird sichergestellt, daß das ACK-FIELD nicht durch eine von einem CRC-Fehler ausgelöste Fehlermeldung überschrieben wird. Durch das Freihalten des ACK-FIELD kann ein Sender sowohl eine Bestätigung seiner Botschaft von einigen Empfängern erhalten als auch eine Fehlermeldung von den restlichen Empfängern. Dies bietet die Möglichkeit, im Wiederholungsfall mit hoher Wahrscheinlichkeit festzustellen, ob der Ausfall beim Teilnehmer (Sender) selbst oder bei einem Empfänger liegt.
Eine Fehlermeldung besteht aus mindestens sechs aufeinanderfolgenden LOW Bits (ERROR-FLAG). Nach dem anschließenden LOW-HIGH Übergang müssen noch mindestens 10 HIGH Bits abgewartet werden (ERROR-DELIMITER) und INTERMISSION).
4.6.2. Fehlerauftreten
Die Fehlerbehandlung kann sowohl von ihrem räumlichen als auch ihrem zeitlichen Auftreten abhängen.
Unter 4.6.5. werden einige Beispiele von Fehlerreaktionen des Open-Kollektor Busses gezeigt.
Aus der folgenden Tabelle 4.6.2 können alle möglichen Einzelbit-Fehlerfälle entnommen werden.
Unter den angegebenen Nummern sind die hier unter 4.6.5. aufgeführten Beispiele für Fehlerfälle zu finden.
Tabelle 4.6.2
4.6.3. Fehlerklassen
Auf Grund der in 4.3 beschriebenen Festlegung des Busprotokolls und der in 4.4 spezifizierten Bus-Organisation können folgende Fehlerklassen auftreten:
Sender
BF
Bitfehler, Buspegel stimmt nicht mit gesendetem Pegel überein.
BK Im Zustand TRANSMIT-IDENTIFIER (Arbitrierung) und TRANSMIT-START-OF-FRAME gilt nur Buspegel HIGH bei gesendetem LOW Bit als Fehler.
AF kein Acknowledge während RECIEVE-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äumlichem Auftreten sowie der Fehlerklassen ergeben. Angegeben sind die zum Zeitpunkt des Fehlers erkennbaren Fehlerklassen.
Die Abkürzungen in der oberen Zeile jedes Feldes der Matrix charakterisieren die am Sender auftretenden Fehlerklassen, die in der unteren Reihe die an den Empfängern auftretenden Fehlerklassen.
Tabelle 4.6.3
4.6.4. Erläuterungen zu den Beispielen
In den Bildern werden folgende Abkürzungen verwendet:
Störung
- - - ungestörte Botschaft
* * * eigenes Eingreifen
# # # fremdes Eingreifen
S Stuffbit
1 . 8 . 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 einen Stuffehler und setzen eine Fehlermeldung ab. Dadurch entsteht an den nicht gestörten Empfängern ein Stuffehler und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzen LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
4.6.5.3. Fehler tritt an einem Teil der Empfänger und am Sender bzw. an Station mit Sendewunsch auf. Bitfehler im ACK-SLOT
Die gestörten Empfänger erkennen einen Bitfehler (ihr LOW Bit wird gestört) und setzen eine Fehlermeldung ab. Der Sender bekommt kein Acknowledge und setzt ebenfalls eine Fehlermeldung ab. Dadurch erkennen die nicht gestörten Empfänger einen Fehler (ACK-DELIMITER) und sie 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 ihren CRC-Check an die falsche Stelle. Wenn der CRC der gestörten Empfänger um mehr als 8 Takte später als die richtige Lage erfolgt, so erhalten die Empfänger einen Stuffehler und setzen eine Fehlermeldung ab. Erfolgt der CRC-Check innerhalb von 8 Takten nach der richtigen Lage, so erkennen die gestörten Empfänger einen CRC-Fehler und senden eine Fehlermeldung. Dadurch entsteht am Sender ein Bitfehler. Die nicht gestörten Empfänger empfangen als END-OF-FRAME eine unzulässige Bitfolge und setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
4.6.5.8. Fehler tritt an einem Teil der Empfänger auf, aber nicht am Sender bzw. an Station mit Sendewunsch. Stuffehler in DATA-FIELD
Die gestörten Empfänger erkennen einen Stuffehler und setzen eine Fehlermeldung ab. Dadurch entsteht am Sender ein Bitfehler und an den nicht gestörten Empfängern ein Stuffehler und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen Übertragungen oder der Wiederholung der gestörten Nachricht begonnen werden.
4.7. INTERFACE-MANAGEMENT-PROCESSOR (IMP) 4.7.1. Konfiguration 4.7.1.1. Allgemeines Konzept 4.7.1.1.1. Struktur
Der IMP hat folgende Aufgaben
- Datenaustausch zwischen CPU und serieller Schnittstelle durch die Benutzung eines DUAL PORT RAM (DPRAM)
- Steuerung von Senden und Empfangen
Fig. 11 zeigt das Blockschaltbild des seriellen Schnittstellenbausteins. Der serielle Schnittstellenbaustein besteht aus den Teilen:
- DPRAM
- IMP
- serielles Schieberegister
- Buslogik
- Taktoszilator
Die Verbindungen der Teile untereinander sind im Blockschaltbild angegeben.
4.7.1.1.2. Priorität der Botschaften
Die Priorität innerhalb des IMP wird durch den Platz der verschiedenen Botschaften im DPRAM festgelegt. Die Priorität auf dem Bus (Arbitrierung) wird durch den IDENTIFIER der Botschaft bestimmt.
Der Suchprozeß nach der höchstprioren Botschaft innerhalb eines IMP startet an der niedrigsten DPRAM Adresse.
4.7.1.1.3. Akzeptanzfilter
Jede vom Bus ankommende Nachricht wird daraufhin geprüft, ob sie empfangen werden soll oder nicht. Dazu wird im DPRAM die Liste 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 angezeigt wird.
4.7.1.1.4. Warteschlange der Botschaften, die gesendet werden soll
Jede Botschaft, die gesendet werden soll, wird von der CPU in das DPRAM geschrieben, wobei anschließend das TRANSMIT-REQUEST Bit gesetzt wird. Ein Suchvorgang findet die höchstpriore Botschaft, die zur Übertragung ansteht. Nur diese Botschaft wird für eine Übertragung ins serielle Schieberegister berücksichtigt. Wenn die CPU später eine wichtigere Botschaft zur Übertragung anmeldet, so wird der Suchvorgang diese entdecken und die erste Botschaft verdrängen. Dadurch werden die Botschaften entsprechend ihrer Priorität übertragen, unabhängig von ihrer Ankunftszeit.
4.7.1.1.5. Warteschlange 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 Integragtionskosten 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 Adress Zeiger des DPRAM zuerst auf den jeweiligen Anfang einer Botschaft zeigen. Wenn die DESCRIPTORen und DATA-FIELDs dichtgepackt abgespeichert sind, kann auf die nächste Botschaft gezeigt werden indem man den Zeiger um
2** (DATA-BYTE-COUNT)+2
erhöht. Um den Speicherplatz und die Botschaften besser auszunützen, können mehrere Botschaften unter einem DESCRIPTOR zusammengefaßt werden und als eine große Botschaft übertragen werden. Die maximale Blockgröße wird vorerst auf 8 Bytes festgelegt.
Die Länge des DATA-FIELDs erhält man aus 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)
    Startwert nach einem Reset. Die Botschaft wird gesendet. TRANSMISSION-REQUEST wird von der CPU oder von einer ankommenden Botschaft mit gesetztem REMOTE-TRANSMISSION-REQUEST Bit auf HIGH gesetzt.
  • b. RECEIVE/TRANSMIT=HIGH (Empfang)
    Alle so gekennzeichneten Botschaften sind im Empfangsmodus. Als Ausnahme in diesem Zustand wird durch OP Setzen von TRANSMISSION-REQUEST eine Botschaft mit leerem DATA-FIELD und gesetztem REMOTE-TRANSMISSION-REQUEST abgeschickt.
4.7.1.4.7. RECEIVE/TRANSMIT
RECEIVE/TRANSMIT bestimmt die Richtung der Daten:
  • a. RECEIVE/TRANSMIT=LOW (Übertragung)
    Startwert nach einem Reset. Die DATA-FIELDs im DPRAM sind für ankommende Botschaften schreibgeschützt, wenn RECEIVE/TRANSMIT auf LOW gesetzt ist. Die Botschaften werden durch TRANSMISSION-REQUEST HIGH aktiviert.
    Es gibt jedoch eine Ausnahme:
    Wenn REMOTE-TRANSMISSION-REQUEST=HIGH in einer ankommenden Botschaft ist, dann wird TRANSMISSION-REQUEST des zugehörigen CONTROL-SEGMENTs auf HIGH gesetzt trotz RECEIVE/TRANSMIT=LOW. TRANSMISSION-REQUEST ist das einzige Bit, das in dieser Operation geändert wird, alle anderen Bits bleiben weiterhin schreibgeschützt. Dieses Vorgehen dient zur Anforderung von Botschaften durch andere Busteilnehmer.
  • b. RECEIVE/TRANSMIT=HIGH (Empfang)
    Die ankommenden Botschaften werden in das zugehörige DATA-FIELD übertragen. INTERRUPT-REQUEST wird automatisch auf HIGH gesetzt bei jeder Übertragung der zugehörigen Botschaft.
4.7.2. Datenaustausch CPU-DPRAM 4.7.2.1. Synchronisations Problem
Der Austausch von DATA-FIELDs, die aus mehreren Bytes bestehen, kann abhängig von der Anwendung ohne Berücksichtigung von der synchronen Betriebweise 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.1. 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überragung 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 DRAM 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:
    Endesignal 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 Adresszeiger zurück, bevor der SEARCH-Prozeß durch Start Search aktiviert wird.
4.7.3.6. SEARCH-Prozeß
Der Search-Prozeß sucht andauernd nach Adresszeigern 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 Unterbrechnungsanforderung 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-Stealing-Verfahren angehalten und um eine Clock-Periode verzögert werden. Nach Abschluß der unteilbaren Operation kann der SEARCH-Prozeß durch höherpriore Prozesse vom Zugriff des DPRAM ausgeschlossen werden, bis die Semaphore-Variable wieder vom SEARCH-Prozeß selbst gesetzt werden kann.
4.7.3.7. INTERRUPT-HANDLING-Prozeß
Der INTERRUPT-HANDLING-Prozeß leitet Interrupts von empfangenen Botschaften oder von mehrfach fehlerhaft übertragenen Botschaften an die CPU weiter. Es wird jeweils der Interrupt mit der durch die Anordnung im DPRAM vorgegebenen hö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 Adresszeiger.
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-Adresszeiger
Auf den DPRAM wird von verschiedenen Quellen aus zugegriffen, der CPU und den parallelen Prozessen. Die Adressen kommen dabei von
  • - CPU-Adresse
  • - EMPTY-POINTER:
    Adresszeiger, der auf eine leere, d. h. nicht mit sinnvollen Botschaften gefüllte Adresse zeigt. Wenn ein Adresszeiger gleich dem EMPTY-POINTER ist, wird dies so interretiert, daß keine entsprechende Botschaft vorliegt
  • - SEARCH-POINTER:
    Adresszeiger des SEARCH-Prozesses
  • - TX-POINTER:
    Adresszeiger, der auf die zu sendende Botschaft zeigt. Falls keine Botschaft zu senden ist, ist der TX-POINTER=EMPTY-POINTER
  • - RX-POINTER:
    Adresszeiger, der auf die zu empfangende Botschaft zeigt. Falls keine Botschaft zu empfangen ist, ist der RX-POINTER=EMPTY-POINTER
  • - INTERRUPT-POINTER:
    Adresszeiger, der auf die Botschaft zeigt, die eine Unterberechungsanforderung an die CPU hat. Falls keine Unterbrechungsanforderung vorliegt, ist der INTERRUPT-POINTER=EMPTY-POINTER
Die Adresszeiger (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 Adresszeiger 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 Adresseingang 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 für INTERRUPT-HANDLING
- REC/TR für RECEIVE/TRANSMIT und
- per für period.

Claims (2)

1. Verfahren zum Betreiben einer Datenverarbeitungsanlage, insbeson­ dere für Kraftfahrzeuge, mit wenigstens zwei Rechnern und einer die Rechner verbindenden Leitung zur Übertragung von Botschaften, dadurch gekennzeichnet, daß jede Botschaft eine Information über den Daten­ namen der Botschaft enthält, daß diese Information mit einer beim Teilnehmer abgelegten Liste verglichen und ihr eine interne, in der Liste niedergelegte Bearbeitungspriorität zugeordnet wird, und daß in jedem Zeitpunkt die Bearbeitungspriorität die Reihenfolge der zur Übertragung bereitstehenden Botschaften bestimmt und daß die Liste eine Information bezüglich Übertragungsan­ forderungen enthält, die vom Teilnehmer selbst oder von den übrigen mit der Leitung gekoppelten Einrichtungen bestimmt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Liste als weitere Information ein Hinweis bezüglich des Übertragungs­ zustandes (pending bit) einer Botschaft zugeordnet ist.
DE3546662A 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage Expired - Lifetime DE3546662C3 (de)

Priority Applications (1)

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE3546662A DE3546662C3 (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
DE3546662C2 DE3546662C2 (en) 1991-03-07
DE3546662C3 true DE3546662C3 (de) 1997-04-03

Family

ID=6263209

Family Applications (4)

Application Number Title Priority Date Filing Date
DE3546683A Expired - Lifetime DE3546683C3 (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
DE3546662A Expired - Lifetime DE3546662C3 (de) 1985-02-22 1985-02-22 Verfahren zum Betreiben einer Datenverarbeitungsanlage
DE19853506118 Granted DE3506118A1 (de) 1985-02-22 1985-02-22 Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge

Family Applications Before (2)

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

Family Applications After (1)

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

Country Status (4)

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

Families Citing this family (142)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3546683C3 (de) * 1985-02-22 2003-10-09 Bosch Gmbh Robert Verfahren zum Betreiben einer Datenverarbeitungsanlage
JPH01148645A (ja) * 1987-12-04 1989-06-12 Sumitomo Electric Ind Ltd 車両スリップ制御装置
FR2627039B1 (de) * 1988-02-10 1994-01-21 Peugeot Automobiles
JP2726931B2 (ja) * 1988-03-15 1998-03-11 三菱農機株式会社 移動農機の制御装置
DE3826774A1 (de) * 1988-08-06 1990-02-08 Bosch Gmbh Robert Netzwerkschnittstelle
DE3926165A1 (de) * 1989-08-08 1991-02-14 Bodenseewerk Geraetetech Sender- und empfaengeranordnung als schnittstelle zu einem mikroprozessor
DE3927968A1 (de) * 1989-08-24 1991-02-28 Bosch Gmbh Robert Verfahren zur datenuebertragung ueber einen seriellen datenbus in verteilten systemen
JP2904298B2 (ja) * 1990-03-30 1999-06-14 マツダ株式会社 車両用多重伝送装置
JP2915080B2 (ja) * 1990-05-25 1999-07-05 株式会社日立製作所 マルチプロセッサシステムにおけるデータ処理方法
DE4028809B4 (de) * 1990-09-11 2005-03-10 Bosch Gmbh Robert System zur Steuerung eines Kraftfahrzeugs
DE4028926A1 (de) * 1990-09-12 1992-03-19 Teves Gmbh Alfred Schaltungsanordnung zur steuerung von elektrischen oder elektromechanischen verbrauchern
FR2668624B1 (fr) * 1990-10-30 1993-02-19 Renault Dispositif de reconnaissance d'adresses pour module electronique de traitement de donnees.
DE4039483A1 (de) * 1990-12-11 1992-06-17 Bayerische Motoren Werke Ag Linearer datenbus
GB2251499A (en) * 1991-01-05 1992-07-08 Delco Electronics Corp Electronic control module.
DE4129205A1 (de) * 1991-03-28 1992-10-01 Bosch Gmbh Robert Verfahren zum aufbau von botschaften fuer den datenaustausch und/oder fuer die synchronisation von prozessen in datenverarbeitungsanlagen
JP2598178B2 (ja) * 1991-04-30 1997-04-09 三菱電機株式会社 通信システム
DE4121999A1 (de) * 1991-07-03 1993-01-07 Bosch Gmbh Robert Lichtmischstecker fuer einen optobus
DE4122084A1 (de) * 1991-07-04 1993-01-07 Bosch Gmbh Robert Verfahren zur informationsuebertragung in einem mehrere teilnehmer aufweisenden bussystem
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
JPH07501503A (ja) * 1991-11-26 1995-02-16 シーメンス アクチエンゲゼルシヤフト バスシステム
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 株式会社デンソー エンジン用制御装置
EP0666199B1 (de) * 1994-02-02 1999-09-29 Mannesmann VDO Aktiengesellschaft Elektronisches System eines Kraftfahrzeugs mit zwischen zwei verschiedenen Bussen gelegener Schnittstellenschaltung
DE19514696B4 (de) * 1994-04-18 2006-03-09 Kvaser Consultant Ab System zur Beseitigung von Störungen bzw. zur Ermöglichung einer Hochgeschwindigkeitsübertragung in einer seriellen Bus-Schaltung sowie mit letzterer verbundene Sende- und Empfangsgeräte
DE4421083C2 (de) * 1994-06-16 1996-04-11 Volkswagen Ag Verfahren zur Überwachung einer seriellen Übertragung von digitalen Daten auf einer Ein-Draht-Multiplexverbindung zwischen untereinander kommunizierenden Signalverarbeitungsgeräten
JP3618119B2 (ja) * 1994-06-23 2005-02-09 株式会社デンソー 車両通信システム
DE4429953B4 (de) * 1994-08-24 2012-06-06 Wabco Gmbh Serielles Bussystem
SE503397C2 (sv) * 1994-09-11 1996-06-03 Mecel Ab Arrangemang och förfarande för ett reglersystem till en förbränningsmotor innefattande ett distribuerat datornät
US6145008A (en) * 1994-09-13 2000-11-07 Kopetz; Hermann Conflict free time-triggered method and apparatus for the transmission of messages in a distributed real-time computer system
US5568484A (en) * 1994-12-22 1996-10-22 Matsushita Avionics Systems Corporation Telecommunications system and method for use on commercial aircraft and other vehicles
JP3505882B2 (ja) * 1995-01-31 2004-03-15 株式会社デンソー 車両用発電装置
DE19616293A1 (de) 1996-04-24 1997-10-30 Bosch Gmbh Robert Bussystem für die Übertragung von Nachrichten
EP0852859B1 (de) 1996-07-24 2010-03-31 Robert Bosch Gmbh Verfahren zur synchronisierung von daten, schnittstelle zur übertragung
JP3183181B2 (ja) * 1996-08-28 2001-07-03 トヨタ自動車株式会社 情報送信方法
DE19637312A1 (de) 1996-09-12 1998-03-19 Bosch Gmbh Robert Verfahren zur Kontrolle der Verbindungen eines Übertragungssystems und Komponente zur Durchführung des Verfahrens
US6164920A (en) * 1996-09-30 2000-12-26 Minnesota Mining And Manufacturing Company Perfusion system with control network
US5752931A (en) * 1996-09-30 1998-05-19 Minnesota Mining And Manufacturing Company Perfusion system with perfusion circuit display
US5813972A (en) * 1996-09-30 1998-09-29 Minnesota Mining And Manufacturing Company Medical perfusion system with data communications network
US5995512A (en) * 1997-01-17 1999-11-30 Delco Electronics Corporation High speed multimedia data network
JP3117000B2 (ja) * 1997-02-21 2000-12-11 株式会社デンソー 通信システムおよびそれに使用される電子制御装置
FR2764149B1 (fr) * 1997-05-27 1999-08-27 Peugeot Procede et dispositif de validation/invalidation d'un message emis sur un reseau de transmission d'informations par reponse dans une trame de communication
FR2764098B1 (fr) * 1997-05-27 1999-08-20 Peugeot Procede et dispositif de controle des acces a un champ de donnees destine a etre emis sur un reseau de transmission d'informations
US6175603B1 (en) * 1997-08-07 2001-01-16 Cisco Technology, Inc. System for managing signals in different clock domains and a programmable digital filter
US6256677B1 (en) * 1997-12-16 2001-07-03 Silicon Graphics, Inc. Message buffering for a computer-based network
DE19813923A1 (de) * 1998-03-28 1999-10-14 Telefunken Microelectron Verfahren zur Datenübertragung in einem über eine Busleitung vernetzten Rückhaltesystem
US6397282B1 (en) * 1998-04-07 2002-05-28 Honda Giken Kogyo Kabushikikaisha Communication controller for transferring data in accordance with the data type
US6385210B1 (en) * 1998-04-17 2002-05-07 Ford Global Technologies, Inc. Method for detecting and resolving data corruption in a UART based communication network
DE19832531A1 (de) * 1998-07-22 2000-02-10 Bosch Gmbh Robert Steuerung für eine Mehrzahl von elektrischen Verbrauchern eines Kraftfahrzeugs
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
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
US6754183B1 (en) 1999-06-14 2004-06-22 Sun Microsystems, Inc. System and method for integrating a vehicle subnetwork into a primary network
US6975612B1 (en) 1999-06-14 2005-12-13 Sun Microsystems, Inc. System and method for providing software upgrades to a vehicle
US6507810B2 (en) 1999-06-14 2003-01-14 Sun Microsystems, Inc. Integrated sub-network for a vehicle
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
DE60212331T2 (de) * 2000-12-29 2007-06-06 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
DE10118300B4 (de) * 2001-04-12 2006-05-18 Conti Temic Microelectronic Gmbh Verfahren zum Betreiben von elektronischen Steuereinrichtungen in einem Kraftfahrzeug
FR2824213B1 (fr) * 2001-04-27 2003-08-01 Renault Dispositif de generation d'une messagerie commune a plusieurs systemes electroniques produisant et consommant des donnees
DE10133945A1 (de) 2001-07-17 2003-02-06 Bosch Gmbh Robert Verfahren und Vorrichtung zum Austausch und zur Verarbeitung von Daten
JP3829679B2 (ja) * 2001-10-09 2006-10-04 株式会社デンソー 通信制御装置
GB2385914B (en) * 2001-10-19 2004-03-03 Visteon Global Tech Inc LCC-Based fluid-level detection 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
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
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
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
CN101010915B (zh) * 2004-06-30 2011-11-02 Nxp股份有限公司 用于对总线系统上的数字信号进行非比特率依赖性编码的方法
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
JP2012530296A (ja) * 2009-06-11 2012-11-29 パナソニック・アビオニクス・コーポレイション 移動プラットフォームにセキュリティを搭載するシステムおよび方法
US8327189B1 (en) 2009-12-22 2012-12-04 Emc Corporation Diagnosing an incident on a computer system using a diagnostics analyzer database
JP5613825B2 (ja) 2010-04-27 2014-10-29 パナソニック・アビオニクス・コーポレイションＰａｎａｓｏｎｉｃ Ａｖｉｏｎｉｃｓ Ｃｏｒｐｏｒａｔｉｏｎ ユーザインターフェースデバイスのための展開システム及び方法
US8897974B2 (en) * 2010-06-07 2014-11-25 Gm Global Technology Operations, Llc Gear selector system
JPWO2012132217A1 (ja) * 2011-03-31 2014-07-24 ルネサスエレクトロニクス株式会社 Ｃａｎ通信システム、ｃａｎ送信装置、ｃａｎ受信装置、およびｃａｎ通信方法
JP5532030B2 (ja) * 2011-09-07 2014-06-25 株式会社デンソー データ通信方法及びデータ通信装置
US9577788B2 (en) 2011-06-15 2017-02-21 Denso Corporation Coding apparatus, coding method, data communication apparatus, and data communication method
JP2013058845A (ja) * 2011-09-07 2013-03-28 Denso Corp データ通信方法及びデータ通信システム
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
US9641267B2 (en) * 2014-06-10 2017-05-02 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数据交互方法和系统
CN116918308A (zh) 2021-03-01 2023-10-20 罗姆股份有限公司 延迟信号产生电路、发送电路、电子控制单元和车辆
JPWO2022185782A1 (de) 2021-03-01 2022-09-09

Family Cites Families (58)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
DE3546662C3 (de) Verfahren zum Betreiben einer Datenverarbeitungsanlage
EP1298849B1 (de) Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem
DE69432842T2 (de) Nachrichtennetz mit zeitkoordinierter Stationsaktivität
DE3043894C2 (de)
EP0576459B1 (de) Verfahren zum aufbau von botschaften für den datenaustausch und/oder für die synchronisation von prozessen in datenverarbeitungsanlagen
DE3317567C2 (de) Rechnergesteuertes Zeitmultiplex-System
EP0772832B1 (de) Arbitrierung bei verzögernder buskopplung
DE2913288C2 (de) Multiprozessoranlage mit einer Vielzahl von Prozessorbausteinen
DE69432841T2 (de) Verfahren und Vorrichtung für digitale Datenübertragung in einem Nachrichtennetz
DE69433858T2 (de) Methode und Vorrichtung zum Austausch unterschiedlicher Arten von Daten während verschiedener Zeitintervallen
DE3204905C2 (de)
DE69432726T2 (de) Verfahren und System zur seriellen Datenübertragung
DE3546684C2 (en) Operating communication bus network for processors
WO1993001668A1 (de) Verfahren zur informationsübertragung in einem mehrere teilnehmer aufweisenden bussystem
DE102006004191B4 (de) Deterministisches Kommunikations-System
DE102018203680A1 (de) Teilnehmerstation für ein serielles Bussystem und Verfahren zur Datenübertragung in einem seriellen Bussystem
EP0150540A2 (de) Verfahren zur Datenübertragung, sowie Station zur Durchführung des Verfahrens
EP0175095B1 (de) Datenübertragungsverfahren über einen Multiprozessorbus
EP0447769A2 (de) Verfahren und Schaltungsanordnung zur Verwaltung gleicher Einheiten sowie Vermittlungselement
EP2538618A1 (de) Verfahren zur Übertragung von Datenpaketen
WO2003036879A1 (de) Teilnehmergerät für ein hochperformantes kommunikationssystem
DE3329228A1 (de) Datenuebertragungsverfahren in einem digitalen uebertragungsnetzwerk und vorrichtung zur durchfuehrung des verfahrens
EP1329057B1 (de) Verfahren für den Zugriff aauf einen Datenbus zwischen kommunizierenden elektronischen einheiten
DE4226876C2 (de) Serielles BUS-System
EP0506214B1 (de) Verfahren zum Betrieb einer Multiplexsteuerung für das Bordnetz eines Kraftfahrzeuges

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
8181 Inventor (new situation)

Free format text: KIENCKE, UWE, DR., 7140 LUDWIGSBURG, DE DAIS, SIEGFRIED, DR., 7016 GERLINGEN, DE KRAMPE, WOLFGANG, 7253 RENNINGEN 2, DE LITSCHEL, MARTIN, 7143 VAIHINGEN, DE BOTZENHARDT, WOLFGANG, 7320 GOEPPINGEN, DE

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