DE3546664C3 - Verfahren zum Betreiben einer Datenverarbeitungsanlage - Google Patents
Verfahren zum Betreiben einer DatenverarbeitungsanlageInfo
- Publication number
- DE3546664C3 DE3546664C3 DE3546664A DE3546664A DE3546664C3 DE 3546664 C3 DE3546664 C3 DE 3546664C3 DE 3546664 A DE3546664 A DE 3546664A DE 3546664 A DE3546664 A DE 3546664A DE 3546664 C3 DE3546664 C3 DE 3546664C3
- Authority
- DE
- Germany
- Prior art keywords
- error
- message
- bus
- state
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 74
- 238000012545 processing Methods 0.000 title claims description 7
- 230000005540 biological transmission Effects 0.000 claims description 74
- 238000001514 detection method Methods 0.000 claims description 5
- 230000008569 process Effects 0.000 description 54
- 238000012546 transfer Methods 0.000 description 23
- 230000007704 transition Effects 0.000 description 16
- 239000013598 vector Substances 0.000 description 16
- 230000008878 coupling Effects 0.000 description 10
- 238000010168 coupling process Methods 0.000 description 10
- 238000005859 coupling reaction Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000002123 temporal effect Effects 0.000 description 6
- 230000004913 activation Effects 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000008520 organization Effects 0.000 description 5
- 238000013475 authorization Methods 0.000 description 4
- 239000013307 optical fiber Substances 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 125000004122 cyclic group Chemical group 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000001105 regulatory effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 1
- 206010000210 abortion Diseases 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000036461 convulsion Effects 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000003344 environmental pollutant Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 230000036039 immunity Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 231100000719 pollutant Toxicity 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- VLCQZHSMCYCDJL-UHFFFAOYSA-N tribenuron methyl Chemical compound COC(=O)C1=CC=CC=C1S(=O)(=O)NC(=O)N(C)C1=NC(C)=NC(OC)=N1 VLCQZHSMCYCDJL-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/03—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for
- B60R16/0315—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for using multiplexing techniques
-
- F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
- F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
- F02D—CONTROLLING COMBUSTION ENGINES
- F02D41/00—Electrical control of supply of combustible mixture or its constituents
- F02D41/24—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means
- F02D41/26—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor
- F02D41/266—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor the computer being backed-up or assisted by another circuit, e.g. analogue
-
- F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
- F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
- F02P—IGNITION, OTHER THAN COMPRESSION IGNITION, FOR INTERNAL-COMBUSTION ENGINES; TESTING OF IGNITION TIMING IN COMPRESSION-IGNITION ENGINES
- F02P5/00—Advancing or retarding ignition; Control therefor
- F02P5/04—Advancing or retarding ignition; Control therefor automatically, as a function of the working conditions of the engine or vehicle or of the atmospheric conditions
- F02P5/145—Advancing or retarding ignition; Control therefor automatically, as a function of the working conditions of the engine or vehicle or of the atmospheric conditions using electrical means
- F02P5/15—Digital data processing
- F02P5/1502—Digital data processing using one central computing unit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0745—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an input/output transactions management context
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0763—Error or fault detection not based on redundancy by bit configuration check, e.g. of formats or tags
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
- G06F13/374—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control using a self-select method with individual priority code comparator
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0079—Formats for control data
- H04L1/0082—Formats for control data fields explicitly indicating existence of error in data being transmitted, e.g. so that downstream stations can avoid decoding erroneous packet; relays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40143—Bus networks involving priority mechanisms
- H04L12/40163—Bus networks involving priority mechanisms by assigning priority to messages according to a message field
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/407—Bus networks with decentralised control
- H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
- H04L12/4135—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L25/00—Baseband systems
- H04L25/02—Details ; arrangements for supplying electrical power along data transmission lines
- H04L25/026—Arrangements for coupling transmitters, receivers or transceivers to transmission lines; Line drivers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L2001/0092—Error control systems characterised by the topology of the transmission link
- H04L2001/0094—Bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L25/00—Baseband systems
- H04L25/02—Details ; arrangements for supplying electrical power along data transmission lines
- H04L25/0264—Arrangements for coupling to transmission lines
- H04L25/0272—Arrangements for coupling to multiple lines, e.g. for differential transmission
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
- Y02T10/00—Road transport of goods or passengers
- Y02T10/10—Internal combustion engine [ICE] based vehicles
- Y02T10/40—Engine management systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mechanical Engineering (AREA)
- Computer Hardware Design (AREA)
- Chemical & Material Sciences (AREA)
- Combustion & Propulsion (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Power Engineering (AREA)
- Small-Scale Networks (AREA)
- Combined Controls Of Internal Combustion Engines (AREA)
- Computer And Data Communications (AREA)
- Regulating Braking Force (AREA)
- Debugging And Monitoring (AREA)
Description
Die Erfindung geht aus von einem Verfahren zum Betreiben einer Datenverarbeitungsanlage
bzw. zum Aufbau von Botschaften nach der Gattung
des Hauptanspruchs. In den letzten Jahren wurde die Funktion des
Kraftfahrzeuges durch elektronische Steuerungen wesentlich verbessert.
Durch eine digitale Motorelektronik konnte z. B. der Kraftstoffverbrauch
reduziert und die Emission von Schadstoffen verringert werden.
Weitere Funktionsverbesserungen sind für das Kraftfahrzeug in Zukunft
insbesondere dadurch zu erreichen, daß die Steuerfunktionen nicht mehr
einzeln für sich arbeiten, sondern untereinander vermascht werden. Die
Schaltvorgänge eines elektronisch gesteuerten Automatikgetriebes lassen
sich z. B. mit geringem Verschleiß der Kupplungsbelege und ohne
störbarem Ruck durchführen, wenn im Schaltaugenblick das Motormoment
durch einen entsprechenden Eingriff in die elektronische Motorsteuerung
kurzzeitig reduziert wird.
Dazu ist es erforderlich, daß der Rechner für die elektronische Getriebesteuerung
genau im richtigen Zeitpunkt entsprechende Daten an
den Rechner mit Hilfe einer Reihe von einzelnen Signalleitungen erreicht.
Die Anzahl derartiger Signalleitungen wird jedoch bei umfangreicheren
Systemen zu groß. Man benötigt deshalb in diesem Fall eine schnelle
Datenübertragung zwischen dem im Kraftfahrzeug installierten Rechnern,
die wenig Anschlüsse im Steuergerätstecker benötigt und bei der die
Information in kodierter Form übertragen wird. Es ist bereits bekannt,
lokale Netzwerke zur Kopplung von Mikroprozessoren, Minirechnern und
Peripheriegeräten insbesondere für nachrichtentechnische Anwendungen
zu betreiben. So gibt es bereits eine große Anzahl verschiedener Übertragungsprotokolle
für die Kopplung von Mikrorechnern wie z. B. DDB,
IIC, MUART, CSMA, SDLC und HDLC. Diese Protokolle wurden beispielsweise
in den Druckschriften Valvo, DDB-Spezifikation; Valvo, Technische
Information für die Industrie 81 1215; Intel, Microprozessor and
Peripheral Handbook, 1983 und A. Tannenbaum, Computer Networks, Prentice/
Hall International, 1983 vorgestellt.
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 anderen weitergegeben. Bei vielen Anwendungen ist
ein derartiges Verfahren aber nachteilig. Ein Teilnehmer kann nämlich
nur dann senden, wenn er gerade im Besitz der Sendeberechtigung ist.
Dadurch können gegebenenfalls nicht tolerierbare lange Wartezeiten in
den Slaves entstehen, bis eine Botschaft hoher Priorität übertragen
wird. Bei schnellen Datenübertragungsanforderungen ist daher dieses
System nicht anwendbar. Ungünstig ist das Master-Slave-Konzept auch
bei elektromagnetischen Störungen, wie sie gerade im Kraftfahrzeug
bekanntlich häufig auftreten. Dabei kann z. B. die Sendeberechtigung
durch eine Störung verloren gehen oder irrtümlicherweise ein weiterer
Teilnehmer eine Sendeberechtigung erlangen. Die Bewältigung solcher
Störfälle ist zwar im
Prinzip möglich, erfordert aber viel Zeit (Busausfallzeit,
CPU-Rechenzeit) und Aufwand, was im Hinblick auf die
Echtzeitanforderungen bei der schnellen Datenübertragung nur schlecht
tragbar ist.
Ein weiteres Problem bei vielen bekannten Netzwerken ist die Synchronisation
von Ereignissen. Sollen z. B. durch Übertragung einer Botschaft
an zwei oder mehreren Teilnehmern gleichzeitig Aktionen ausgelöst
werden, so muß die Botschaft von allen im genau gleichen Augenblick
empfangen werden. Bei der sonst üblichen zeitlich aufeinanderfolgenden
Übertragung von Botschaften zu den einzelnen Empfängern
(Punkt zu Punkt-Verbindung) ist die Gleichzeitigkeit des Empfangs
einer gültigen Botschaft prinzipiell nicht zu erreichen. Häufig sind
auch gleiche Botschaften an verschiedene Empfänger zu senden. Der
gleichzeitige Empfang durch einen angesprochenen Teilnehmer würde in
diesen Fällen die Belegung des Netzwerkes beträchtlich reduzieren.
Dieses Vorgehen wird aber von den bekannten Schnittstellenbausteinen
nicht ermöglicht. Eine weitere wesentliche Voraussetzung ist eine
leistungsfähige Fehlererkennung. Selbst die aufwendigeren der heute
bekannten Protokolle sind jedoch nicht in der Lage, ohne zusätzliche
Absicherungsprogramme auf Benutzerebene (z. B.: Mehrfach-Übertragung)
eine ausreichende Übertragungssicherheit zu gewährleisten. So kann
beim HDLC-Protokoll bereits ein Einzelbitfehler zu einer nicht erkennbaren
Verfälschung der Botschaft führen, obwohl diese durch einen
CRC-Check mit 16 Bitlängen abgesichert wird.
In dem Artikel Moelands, I²C bus in consumer applications,
Electronic Components and Applications, Vol. 5, Nr. 4, 1983, Seiten
214 bis 221, sowie in der Firmenschrift Valvo, Technische Information
81 12 15, 1981, ist der an sich bekannte IIC-Bus beschrieben. In den
Druckschriften wird auch die Arbitrierung bei einem Multimaster-System
abgehandelt. Bei mehreren Rechnern ist nämlich darauf zu achten, daß
nur einer der Rechner auf den Bus zugreifen kann, ohne daß die Daten,
die auf den Bus übertragen werden sollen, verfälscht werden. Dieser
Auswahlprozeß erfolgt beim I²C-Bus dadurch, daß der prioritätshöchste
Rechner eine Anzahl von logischen Einsen (dominanter Status)
abgibt. Rechner mit geringeren Prioritäten geben eine geringere Anzahl
dominanter Signale ab. Stellt nun ein Rechner fest, daß der Bus
dominante Signale enthält, obwohl er selbst eine logische Null ausgibt
(rezessiver Status), zieht sich der entsprechende Rechner zurück. Auf
die Fehlerbehandlung wird jedoch nicht eingegangen.
In dem Buch Färber, Bussysteme, R. Oldenbourg Verlag, München, Wien
1984, Seiten 100 bis 101 und Seiten 119 bis 121 wird die Ankopplung
von Rechner an Bussysteme beschrieben sowie der D²B-Bus erläutert.
Die Fehlerbehandlung ist hier auch nicht erwähnt.
Ausgehend vom aufgezeigten Stand der Technik ist es Aufgabe der Erfindung,
ein Verfahren zum Betreiben einer Datenverarbeitungsanlage und
ein Verfahren zum Behandeln fehlerhafter Botschaften anzugeben,
mittels dem eine systemweite Datenkonsistenz im Bus erzielt wird.
Diese Aufgabe wird durch die kennzeichnenden Merkmale der Ansprüche 1
und 2 gelöst.
Die erfindungsgemäßen Verfahren mit den kennzeichnenden Merkmalen der
Ansprüche 1 und 2 haben den Vorteil, daß mit der Übertragung einer
Zustandsfolge dominanter Zustände, die sonst nicht auftreten kann,
nicht nur vom Sender erkannt wird, daß eine Botschaft zumindest bei
einem Rechner nicht angekommen ist, sondern auch den übrigen Rechnern
die Möglichkeit geboten ist zu erkennen, daß die Botschaft zumindest
von einem Rechner nicht ordnungsgemäß empfangen worden ist. Dies hat
zur Folge, daß die Datenübertragung vom sendenden Rechner abgebrochen
wird und auch von den übrigen Rechnern das bisher empfangene Signal
verworfen wird.
Durch die in den Unteransprüchen aufgeführten Maßnahmen sind vorteilhafte
Weiterbildungen und Verbesserungen des im Hauptanspruch angegebenen
Verfahrens möglich. Besonders vorteilhaft ist, daß die Fehlermeldung
jederzeit aussendbar ist, so daß die Übertragung einer Botschaft
nicht beendet werden muß, sondern die Unterbrechung auch am
Anfang vorgenommen werden kann, wenn dort ein Fehler auftritt. Dies
führt zu einer wesentlich verringerten Busbelegung beim Übertragen von
Botschaften. Vorteilhaft ist auch, daß von jedem Teilnehmer eine
Fehlermeldung ausgebbar ist. Ohne Rücksicht auf die laufende Übertragung
wird dadurch ein Abbruch der übertragenen Nachricht möglich,
da es ohne Belang ist, ob der Sender ein Fehler bei der Übertragung
feststellt oder ob bei einem der Empfänger ein Fehler festgestellt
wird. Vorteilhaft ist auch, daß das Ende der Fehlermeldung zur zeitlichen
Synchronisation aller Teilnehmer dient. Dies hat den Vorteil,
daß nach der Fehlermeldung bereits eine Synchronisation der Teilnehmer
vorliegt und daher eine neue Übertragung sofort begonnen werden kann.
Treten mehrere Fehlermeldungen auf, dient das Ende der letzten Fehlermeldung
der Synchronisation, wenn beispielsweise mehrere Stationen
einen Fehler erkannt haben.
Vorteilhaft ist auch, daß die Übernahme der Botschaft in den
Empfängern erst erfolgt, wenn der Empfang der Botschaft ohne Fehlererkennung
abgeschlossen ist. Durch diese Maßnahme wird erreicht, daß
bei allen Empfängern die Botschaft in gleicher Form zur Verfügung
steht. Damit ist sichergestellt, daß sämtliche Empfänger über die
gleichen Daten verfügen. Vorteilhaft ist auch, daß die Übertragung bei
auftretenden Fehlern wiederholt wird, bzw. daß die Wiederholung dann
abgebrochen wird, wenn eine bestimmte Anzahl von fehlerhaften Übertragungen
die Übertragung abgebrochen wird. Dadurch wird verhindert,
daß beispielsweise bei Fehlern im Sender oder in einem der Empfänger
eine ständige Wiederholung der Nachricht erfolgt, ohne daß ein Ende
abzusehen ist. Besonders vorteilhaft ist in diesem Zusammenhang, daß
der Teilnehmer, der die Fehlermeldung abgibt, vom Bus abgekoppelt
wird, so daß die übrigen Teilnehmer des Systems ordnungsgemäß miteinander
kommunizieren können. Weiterhin ist vorteilhaft, jedem Teilnehmer
lediglich einen bestimmten Teil der zeitlichen Übertragungskapazität
der Leitung zur Verfügung zu stellen. Dadurch wird erreicht,
daß in einem Fehlerfall nicht durch einen Teilnehmer, wenn auch nur
für eine bestimmte Zeit, der Bus blockiert werden kann.
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
Tabelle 1 zeigt die möglichen Bustopologien, Ankopplungs- und
Leitungsarten in Abhängigkeit von dem gewählten
Übertragungsmedium.
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 hierfür sind:
Beispiele für Impedanz:
Schalter | |
geschlossen/offen | |
Transistor | leitend/nichtleitend |
Beispiele für Energie:
Spannung | |
liegt an/liegt nicht an | |
Licht | an/aus |
Fig. 1 zeigt die Ausführung als lineares Bussystem. Das System
besteht aus einer durchgehenden Busleitung (Adernpaar oder
Lichtleiter) und Anschlußleitungen, die zu den einzelnen
Teilnehmern sehen.
Fig. 2 zeigt eine Ausführung mit galvanischer Ankopplung an
die Busleitung. Die Treiber sind steuerbare Schalter,
realisiert durch Transistoren (Open-Collector-Ankopplung). Als
Busleitung dient 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.
Eine Botschaft besteht aus den Bitfeldern START-OF-FRAME,
IDENTIFIER, CONTROL-FIELD, DATA-FIELD, CRC-FIELD, ACK-FIELD,
END-OF-FRAME und INTERMISSION (siehe Fig. 6)
Hinweise:
In dieser Beschreibung werden die
Begriffe HIGH und LOW im Sinne
logischer Pegel verwendet.
Während HIGH in seiner Wirkung
auf dem Bus rezessiv ist, ist LOW
dominant. Das hat zur Folge, daß
von allen Busteilnehmern LOW
empfangen wird, sofern mindestens
einer von mehreren Busteilnehmern
LOW sendet.
START-OF-FRAME
markiert den Botschaftsanfang und besteht aus einem einzigen LOW-Bit.
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.
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)
(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.
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)
(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
enthält die zu übertragende Information, deren Bedeutung durch den IDENTIFIER festgelegt ist. Die Länge dieses Feldes (DATA-BYTE-COUNT) ist variabel und kann z. B. ein, zwei, vier oder acht Bytes betragen.
DATA-BYTE-COUNT=2**DATA-BYTE-CODE
DFL=DATA-FIELD-LENGTH=8*DATA-BYTE-COUNT
CRC-FIELD
dieses Bitfeld enthält das mittels eines Generator- Polynoms erzeugte Kontrollwert (CRC-SEQUENCE), es wird mit einem CRC-DELIMITER abgeschlossen (Fig. 9).
dieses Bitfeld enthält das mittels eines Generator- Polynoms erzeugte Kontrollwert (CRC-SEQUENCE), es wird mit einem CRC-DELIMITER abgeschlossen (Fig. 9).
Das Generator-Polynom ist für kleine Botschaftslängen
(kleiner 120 zu sichernde Bits) ausgewählt, womit eine
höhere Hammind-Distanz erreicht wird wie bei der
Absicherung langer Botschaften mit der gleichen Anzahl von
Kontrollbits.
In dem vorliegenden Ausführungsbeispiel ist die
CRC-SEQUENCE 15 Bits lang.
(CRCL=CRC-SEQUENCE-LENGTH=15)
(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.
Der CRC-DELIMITER besteht aus einem HIGH Bit, er folgt auf das CRC-Kontrollwort und schließt das CRC-FIELD ab.
Zyklische Codes können solche Fehler nicht aufdecken, die
sich auf die zyklische Verschiebung des gesamten
Codewortes (zu sichernde Bits und Sicherungsbits)
zurückführen lassen. Eine zyklische Verschiebung ergibt
nämlich wieder ein gültiges Codewort.
Wird jedoch das Bit START-OF-FRAME, das per Definition LOW
ist, in das Codewort einbezogen, kann jede Rotation des
Codewortes daran erkannt werden, daß das CRC-FIELD nicht
mit HIGH abgeschlossen wird.
ACK-FIELD
Alle Empfänger teilen dem Sender den Empfang einer korrekten Botschaft dadurch mit, daß sie als erstes Bit in diesem Fenster ein LOW Bit übertragen. Als zweites Bit wird HIGH (ACK-DELIMITER) übertragen. Der Sender kann auf diese Art und Weise erkennen, ob zumindestens einer der Busteilnehmer die Botschaft fehlerfrei empfangen hat.
Alle Empfänger teilen dem Sender den Empfang einer korrekten Botschaft dadurch mit, daß sie als erstes Bit in diesem Fenster ein LOW Bit übertragen. Als zweites Bit wird HIGH (ACK-DELIMITER) übertragen. Der Sender kann auf diese Art und Weise erkennen, ob zumindestens einer der Busteilnehmer die Botschaft fehlerfrei empfangen hat.
Alle diejenigen Busteilnehmer, die eine fehlerhafte
Botschaft empfangen haben, melden dies mittels eines
ERROR-FLAG.
Erhält der Sender keine Bestätigung für den korrekten
Empfang seiner Botschaft durch zumindest einen Empfänger,
so setzt er selbst eine Fehlermeldung ab.
END-OF-FRAME
besteht aus einer ununterbrochenen Folge von HIGH Bits und steht am Ende einer jeden Botschaft.
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.
(EOFL=END-OF-FRAME-LENGTH=7)
(EOFL=END-OF-FRAME-LENGTH=7)
INTERMISSION
besteht aus einer ununterbrochenen Folge von HIGH Bits. In dieser Zeit darf keiner der Busteilnehmer die Übertragung einer neuen Botschaft beginnen.
Während INTERMISSION hat jeder Empfänger die Möglichkeit, eine Überlastung (fehlende Empfangsbereitschaft) durch Senden eines ERROR-FLAG zu melden, so daß das Absenden der nächsten Botschaft verzögert wird, bis alle Empfänger wieder bereit sind.
besteht aus einer ununterbrochenen Folge von HIGH Bits. In dieser Zeit darf keiner der Busteilnehmer die Übertragung einer neuen Botschaft beginnen.
Während INTERMISSION hat jeder Empfänger die Möglichkeit, eine Überlastung (fehlende Empfangsbereitschaft) durch Senden eines ERROR-FLAG zu melden, so daß das Absenden der nächsten Botschaft verzögert wird, bis alle Empfänger wieder bereit sind.
Eine in INTERMISSION fallende Fehlermeldung wird genauso
wie die in andere Bitfelder fallenden Fehlermeldungen
behandelt. Eine Wiederholung der vorangegangenen Botschaft
durch den entsprechenden Sender erfolgt jedoch nicht.
In dem vorliegenden Ausführungsbeispiel ist INTERMISSION
drei Bit lang.
(IML=INTERMISSION-LENGTH=3)
(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.
Der Bus ist frei, wenn er nach Ablauf von INTERMISSION weiterhin HIGH-Pegel führt. Der Zustand BUS-IDLE kann von beliebiger Dauer sein. Der Empfang eines LOW Bits wird als START-OF-FRAME interpretiert.
Eine Fehlermeldung besteht aus dem Bitfeldern ERROR-FLAG
und ERROR-DELIMITER (siehe Fig. 10)
ERROR-FLAG
besteht aus einer ununterbrochenen Folge von LOWBits.
besteht aus einer ununterbrochenen Folge von LOWBits.
Die Länge der Folge ist so zu bestimmen, daß durch sie
das Gesetz des "Bitstuffins" verletzt wird, das auf alle
Bitfelder von START-OF-FRAME bis CRC-DELIMITER angewendet
wird. Die anderen Busteilnehmer reagieren darauf, indem
sie selbst eine Fehlermeldung senden.
In dem vorliegenden Ausführungsbeispiel ist das
ERROR-FLAG sechs Bit lang.
(EFL=ERROR-FLAG-LENGTH=6)
(EFL=ERROR-FLAG-LENGTH=6)
ERROR-DELIMITER
Jede Fehlermeldung wird mit einer ununterbrochenen Folge von HIGH Bits abgeschlossen.
Jede Fehlermeldung wird mit einer ununterbrochenen Folge von HIGH Bits abgeschlossen.
Der Sendevorgang des ERROR-DELIMITER beginnt, nachdem auch
alle anderen Teilnehmer mit der Übertragung des
ERROR-FLAG fertig sind (LOW nach HIGH Übergang auf dem
Bus).
Im vorliegenden Ausführungsbeispiel ist der
ERROR-DELIMITER sieben Bit lang.
(EDL=ERROR-DELIMITER-LENGTH=7)
(EDL=ERROR-DELIMITER-LENGTH=7)
Die Organisation des Busverkehrs beruht auf folgenden fünf
Regeln:
- (1) BUS-ZUGRIFF
Die Busteilnehmer dürfen nur im Zustand BUS-IDLE die Übertragung einer Botschaft starten.
Alle Empfänger müssen auf die führende Flanke von START-OF-FRAME synchronisieren. - (2) ARBITRIERUNG
Beginnen zwei oder mehr Busteilnehmer gleichzeitig mit der Übertragung, wird der Zugriffskonflikt durch einen Arbitrierungsmechanismus auf Bitebene gelöst.
Während der Arbitrierung vergleicht jeder Sender den Bitpegel, den er selbst auf den Bus schreibt, mit demjenigen, den er tatsächlich auf dem Bus abtastet. Alle diejenigen Sender, die nicht den von ihnen selbst gesendeten Buspegel vorfinden, müssen die Übertragung ohne auch nur ein weiteres Bit zu senden einstellen. Durch diese Vereinbarung kann der Arbitrierungsvorgang ablaufen, ohne daß irgendwelche Information auf dem Bus zerstört wird. Derjenige Sender, dessen Botschaft den IDENTIFIER mit der höchsten Priorität aufweist, gewinnt den Buszugriff. Er überträgt die begonnene Botschaft zu Ende. - (3) KODIERUNG
Die Botschaftssegmente START-OF-FIELD, IDENTIFIER, CONTROL-FIELD, DATA-FIELD und CRC-FIELD werden nach der Methode des Bitstuffing kodiert. Treten in dem zu übertragenden Datenstrom in ununterbrochener Reihenfolge fünf gleiche Bits auf, so fügt der Sender automatisch ein Bit mit umgekehrter Wertigkeit in den Bitstrom ein. - (4) DEKODIERUNG
Die Botschaftssegmente START-OF-FIELD, IDENTIFIER, CONTROL-FIELD, DATA-FIELD und CRC-FIELD werden nach der Methode des Bitstuffing kodiert. Empfängt ein Busteilnehmer fünf gleiche Bitpegel in ununterbrochener Reihenfolge, so entfernt dieser das nachfolgende Stuffbit aus dem Bitstrom. Die Wertigkeit des Stopfbits muß invers zu der der voran gegangenen Bits sein (Fehlerprüfung). - (5) FEHLERMELDUNG
Jeder Busteilnehmer, der einen Übertragungsfehler feststellt, teilt dies allen anderen Busteilnehmern mit, indem er sechs aufeinander folgende LOW Bits (ERROR-FLAG) sendet.
Die Fehlermeldung erfolgt sofort nach einem erkannten Fehler, d. h., beginnend mit dem auf den Fehlerzustand folgenden Bit. Nur bei Erkennung eines CRC-Fehlers wird die Fehlermeldung erst drei Takte später abgeschickt. Dadurch wird sichergestellt, daß das ACK-FIELD nicht durch eine von einem CRC-Fehler ausgelöste Fehlermeldung überschrieben wird.
Die Fehlermeldung wird durch einen Übergang von LOW nach HIGH nach mindestens sechs LOW Bits auf dem Bus beendet (siehe Zustandsdiagramm zur Fehlerbehandlung). - (6) ÜBERLAST
Bei Überlastung (empfangene Botschaft ist noch nicht bearbeitet) hat jeder Busteilnehmer die Möglichkeit, durch Senden eines ERROR-FLAG während INTERMISSION dies allen anderen Teilnehmern zu melden (siehe INTERMISSION).
Jeder Rechteckrahmen stellt einen Systemzustand dar. Die
Übergänge zwischen den Zuständen, die von Eingangs- und
Zustandsvariablen abhängen, sind durch gerichtete
Verbindungslinien dargestellt. Die Zustandsübergänge erfolgen
stets mit der aktiven Flanke des Bustaktes. Mit der gleichen
Taktflanke werden Ausgangsdaten auf die Busleitung gelegt. Der
tatsächliche Buspegel wird erst kurz vor der nächsten aktiven
Bustaktflanke abgetastet.
Nach einem BUS-IDLE Zustand wird der Bustakt auf den nächsten
Buspegelübergang von HIGH nach LOW synchronisiert.
Die Eingangs- und Zustandsvariablen können geordnet und zu
einem Entscheidungsvektor zusammengefaßt werden.
Der Entscheidungsvektor hat folgende Form:
(BUS-MONITOR, BUS-DRIVE, STUFF, COUNT, TX-REQUEST, CRC-ERROR, OVERLAND)
(BUS-MONITOR, BUS-DRIVE, STUFF, COUNT, TX-REQUEST, CRC-ERROR, OVERLAND)
Es bedeutet:
BUS-MONITOR
Eingangsvariable, die den auf der Busleitung abgetasteten Logikpegel wiederspiegelt.
Eingangsvariable, die den auf der Busleitung abgetasteten Logikpegel wiederspiegelt.
BUS-MONITOR=0 entspr. dominanten Buspegel (LOW)
BUS-MONITOR = 1 entspr. rezessivem Buspegel (HIGH)
BUS-MONITOR = 1 entspr. rezessivem Buspegel (HIGH)
BUS-DRIVE
Zustandsvariable, die den Logikpegel angibt, der in diesem Zustand gesendet wird.
Zustandsvariable, die den Logikpegel angibt, der in diesem Zustand gesendet wird.
BUS-DRIVE=0 Sendepegel dominant (LOW)
BUS-DRIVE=1 Sendepegel rezessiv (HIGH)
BUS-DRIVE=1 Sendepegel rezessiv (HIGH)
STUFF
Eingangsvariable, die angibt, ob der Buspegel während der letzten fünf Abtasttakte konstant war. (Fünfmal LOW oder fünfmal HIGH). Der Pegel, den BUS-MONITOR angibt, ist der aktuellste Wert dieser Fünferkette.
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
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.
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)
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ß.
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
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.
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
CRC-ERROR=1 Übertragungsfehler
OVERLAND
Zustandsvariable, die angibt, ob die letzte empfangene Botschaft von der Schnittstellenlogik aufgearbeitet werden konnte oder ob diese überlastet ist.
Zustandsvariable, die angibt, ob die letzte empfangene Botschaft von der Schnittstellenlogik aufgearbeitet werden konnte oder ob diese überlastet ist.
OVERLAND=0 Empfangslogik überlastet
OVERLAND=1 Empfangslogik bereit
OVERLAND=1 Empfangslogik bereit
Mit dem Entscheidungsvektor ist eindeutig festgelegt, in
welchen Folgezustand gegangen wird. Der Zustandsgraph kann
deshalb mit Hilfe der Entscheidungsvektoren beschrieben werden.
Ist für ein bestimmtes Element im Zustandsvektor ein "x"
angegeben, so bedeutet dies, daß die entsprechende Variable
für die Entscheidung nicht relevant ist (die Variable darf "0"
oder "1" sein).
Der Zustand BUS-IDLE ist der reguläre Folgezustand des
Zustands TEST-INTERMISSION. Im Zustand BUS-IDLE wird stets der
rezessive Sendepegel HIGH auf die Busleitung gelegt.
Übergänge in Folgezustände:
- 1) Entscheidungsvektor (1,1,1,x,0,x,x):
Dieser Entscheidungsvektor bedeutet folgendes:
Buspegel HIGH, Sendepegel HIGH, Bus war schon mind. fünf Takt lang HIGH, Zähler nicht relevant, keine Sendeanforderung, Übertragungsfehler und Überlastung nicht relevant. Da keine Busaktion detektiert wurde und keine Sendeanforderung vorlag, ist der Folgezustand wieder BUS-IDLE. - 2) Entscheidungsvektor (1,1,1,x,1,x,x):
Jetzt liegt bei sonst gleichen Variablen wie in 1) eine Sendeanforderung vor. Da die Busleitung frei ist, kann sofort mit dem Senden begonnen werden. Der Folgezustand ist also TRANSMIT-START-OF-FRAME. - 3) Entscheidungsvektor (0,1,0,x,x,x,x):
Auf der Busleitung wurde der Pegel LOW detektiert, das heißt, daß mindestens ein anderer Busteilnehmer begonnen hat, eine Botschaft zu übertragen. Das detektierte LOW Bit ist START-OF-FRAME. Der Folgezustand ist RECEIVE-IDENTIFIER. - 4) Alle weiteren Entscheidungsvektoren deuten auf eine Hardware-Störung bzw. auf einen Hardware-Ausfall innerhalb des Schnittstellenbausteins hin.
Entsprechendes gilt für alle anderen Systemzustände, die in
den Zustandsgraphen EMPFANGSMODUS, SENDEMODUS und
FEHLER-BEHANDLUNG beschrieben werden.
Neben den Entscheidungsvektoren, die sich aufgrund von
Störungen auf den Busleitungen ergeben, werden nur die Vektoren
aufgeführt, die bei funktionsfähiger Hardware auftreten
können. Die restlichen Vektoren kann man entweder zur
Vereinfachung des Steuerwerks ausnützen oder zur Erhöhung
der Systemsicherheit in einem Zustand HARDWARE-ERROR behandeln.
Aus dem Zustand BUS-IDLE kommt man durch Erkennen von
START-OF-FRAME auf dem Bus in den Zustand RECEIVE-IDENTIFIER.
Beim Zustandsübergang wird der Zähler CNTR mit IFL=8
(IDENTIFIER-FIELD-LENGTH) vorbelegt. IFL gibt an wieviel
Kennungsbits vereinbart wurden (siehe 4.3, IDENTIFIER).
Mit jedem empfangenen Kennungsbit wird die Schleife des
Zustands RECEIVE-IDENTIFIER einmal durchlaufen und der Zähler
wird dekrementiert. Tritt im IDENTIFIER ein Stuffbit auf, so
erfolgt aufgrund von STUFF=1 der Übergang in den Zustand
IGNORE-ID-STUFFB. Dort wird der Stuffbit ausgeblendet. Ist
danach immer noch STUFF=1, so muß eine Ausnahmesituation
vorliegen (Störung auf Busleitung, Fehlermeldung eines anderen
Teilnehmers, unerwartete Busruhe); als Reaktion darauf wird in
den Zustand ERROR-HANDLING gegangen. Ist jedoch STUFF=0, so
kann der Rücksprung in den Zustand RECEIVE-IDENTIFIER
erfolgen.
Nach Ablaufen des Zählers geht das System (entweder aus dem
Zustand RECEIVE-IDENTIFIER oder IGNORE-ID-STUFFB) in den
Zustand RECEIVE-CONTROL-FIELD über. Hier wird der Zähler mit
CFL=8 (CONTROL-FIELD-LENGTH) vorbelegt.
Sind alle Bits des CONTROL-FIELDs empfangen, so wird als
nächstes in Zustand RECEIVE-DATA-FIELD das Datenfeld
empfangen. Als Besonderheit gilt hier, daß der Zähler nicht
mit einer Konstanten, sondern mit der Variablen DFL
(DATA-FIELD-LENGTH) vorgelegt wird. DFL kann die Werte 8, 16,
32 oder 64 annehmen.
Als nächstes wird im Zustand RECEIVE-CRC-SEQUENCE das
CRC-Kontrollwort (CRC-SEQUENCE) empfangen. Hierzu wird
zunächst der Zähler CNTR mit CRCL=15 (CRC-SEQUENCE-LENGTH)
vorbelegt. Nach dem Empfang des letzten CRC-Bits wird die
Zustandsvariable CRC-ERROR gesetzt (CRC-ERROR=0 bedeutet
kein Fehler, CRC-ERROR=1 bedeutet Fehler im Übertragungsrahmen).
Das CRC-Kontrollwort muß stets durch ein Bit (CRC-DELIMITER)
mit dem Pegel HIGH abgeschlossen sein. Dies wird im Zustand
RECEIVE-CRC-DELIMITER geprüft. Bei falschem Buspegel wird zum
Zustand ERROR-HANDLING gesprungen.
Im nächsten Bustaktzyklus müssen die Empfänger den Empfang
der Botschaft bestätigen. Dies geschieht im Zustand
SEND-ACKNOWLEDGE durch Senden eines LOW-Pegels für
fehlerfreien Empfang bzw. durch Senden eines HIGH-Pegels im
Fehlerfall. Beim Entdecken des Buspegels HIGH wird, falls der
dominante Pegel LOW gesendet wurde, zum Zustand ERROR-HANDLING
übergegangen.
Auf das erste Acknowledge-Bit folgt der ACK-DELIMITER, der
stets den Pegel HIGH haben muß. Dieser Pegel wird im Zustand
SEND-ACK-DELIMITER von allen Empfängern ausgegeben. Wird der
Pegel LOW empfangen, so wird zum Zustand ERROR-HANDLING
übergegangen.
Beim Zustandsübergang nach RECEIVE-END-OF-FRAME wird der
Zähler CNTR mit EOFL=7 (END-OF-FRAME-LENGTH) initialisiert.
Falls CRC-ERROR=1 ist, oder falls während
RECEIVE-END-OF-FRAME der Buspegel LOW empfangen wird, wird zum
Zustand ERROR-HANDLING übergegangen.
Im fehlerfreien Fall wurde die Botschaft jetzt vollständig
empfangen. Als nächstes folgt der Zustand TEST-INTERMISSION,
der aus IML=3 (INTERMISSION-LENGTH) Zyklen besteht. Der
Buspegel muß dauernd HIGH sein, sonst wird nach ERROR-HANDLING
gesprungen. Im Zustand TEST-INTERMISSION hat jeder Empfänger
die Möglichkeit eine Überlastung (OVERLAND=1) zu melden,
sodaß das Absenden der nächsen Botschaft verzögert wird,
bis der Empfänger wieder bereit ist. Auch dies geschieht durch
ERROR-HANDLING. Nach Ablauf des Zählers CNTR wird in den
Folgezustand BUS-IDLE übergegangen, mit dem ein neuer
Empfangs- oder Sendezyklus beginnt.
Bezüglich der Stuffbits, die in den Feldern CONTROL-FIELD,
DATA-FIELD und CRC-SEQUENCE auftreten können, gelten die zum
Zustand RECEIVE-IDENTIFIER gemachten Ausführungen entsprechend.
Vom Zustand BUS-IDLE aus erfolgt der Übergang in den
Sendemodus dann, wenn vor oder während BUS-IDLE eine
Sendeanforderung eintrifft (TX-REQUEST=1). Siehe hierzu
Zustandsgraph RECEIVE-MODE.
Das Senden einer Botschaft beginnt mit dem Zustand TRANSMIT-
START-OF-FRAME, in dem der dominante Sendepegel LOW ausgegeben
wird. Falls eine Störung den dominanten Pegel LOW in HIGH
verfälscht, wird zum Zustand ERROR-HANDLING übergegangen.
Sonst folgt im Zustand TRANSMIT-IDENTIFIER die
Buszuteilungsprozedur. Am Anfang wird der Zähler auf IFL=8
(IDENTIFIER-FIELD-LENGTH) gesetzt.
Im Zustand TRANSMIT-IDENTIFIER wird verblieben (lediglich der
Zähler wird dekrementiert), wenn der empfangene Pegel dem
gesendeten entspricht und die letzten fünf Buspegel nicht
konstant waren und der Zähler
noch nicht abgelaufen ist.
Der Zustand TRANSMIT-IDENTIFIER wird verlassen, wenn
- - der gesendete rezessive HIGH-Pegel durch LOW überschrieben wurde. Die Buszuteilung ist damit verloren. Falls STUFF=1 ist, ist der Folgezustand IGNORE-ID-STUFFB. Sonst ist bei nicht abgelaufenem Zähler der Folgezustand RECEIVE-IDENTIFIER, bei abgelaufenem Zähler RECEIVE-CONTROL-FIELD.
- - ein gesendeter dominanter LOW-Pegel in HIGH verfälscht wird. Der Folgezustand ist ERROR-HANDLING.
- - der empfangene Pegel dem gesendeten entspricht. Falls die letzten fünf Pegel gleich waren muß in den Zustand INSERT-ID-STUFFB übergegangen werden. Sonst wird bei abgelaufenem Zähler in den Folgezustand TRANSMIT-CONTROL-FIELD übergegangen. Im letzten Fall wurde die Buszuteilung gewonnen.
Im Zustand INSERT-ID-STUFFB werden die Stuffbits des
IDENTIFIER-FIELDS eingefügt. Da in diesem Zustand die
Buszuteilung nicht verloren werden kann, ist im Falle von
unterschiedlichen Sende- und Empfangs-Pegeln ERROR-HANDLING
der Folgezustand. Ansonsten wird bei nicht abgelaufenem Zähler
in den Zustand TRANSMIT-IDENTIFIER zurückgegangen, bei
abgelaufenen Zähler wurde die Buszuteilung gewonnen, der
Folgezustand ist TRANSMIT-CONTROL-FIELD.
Beim Einstieg in den Zustand TRANSMIT-CONTROL-FIELD wird der
Zähler CNTR mit CFL=8 initialisiert (CONTROL-FIELD-LENGTH). Da
die Buszuteilung beendet ist, muß ab jetzt der Sende- und
Empfangs-Pegel stets gleich sein. Ist dies nicht der Fall, so
wird in den Zustand ERROR-HANDLING übergegangen. Bei nicht
abgelaufenem Zähler und bei Flankenwechsel innerhalb der
letzten fünf Taktzyklen bleibt das System im Zustand
TRANSMIT-CONTROL-FIELD, lediglich der Zähler wird
dekrementiert. Das Einfügen von Stuffbits geschieht im Zustand
INSERT-CF-STUFFB. Bei abgelaufenem Zähler erfolgt der
Übergang in den Folgezustand TRANSMIT-DATE-FIELD.
Die Vorgänge im Zustand TRANSMIT-CONTROL-FIELD gelten auch
für die Zustände TRANSMIT-DATA-FIELD und
TRANSMIT-CRC-SEQUENCE. Beim Einstieg in TRANSMIT-DATA-FIELD
wird der Zähler CNTR mit der Variablen DFL (DATA-FIELD-LENGTH)
vorbelegt, die die Werte 8, 16, 32 oder 64 annehmen kann. Beim
Einstieg in TRANSMIT-CRC-SEQUENCE wird der Zähler mit der
Konstanten CRCL=15 (CRC-FIELD-LENGTH) vorbelegt.
Im Anschluß an die CRC-SEQUENCE muß der CRC-DELIMITER
übertragen werden. Dies geschieht im Zustand
TRANSMIT-CRC-DELIMITER. Falls der gesendete HIGH-Zustand nach
LOW verfälscht wird, wird in den Zustand ERROR-HANDLING
übergegangen.
Als nächstes wird das Acknowledge-Bit geprüft. Ein
empfangener HIGH-Pegel bedeutet, daß kein Teilnehmer die
Botschaft fehlerfrei empfangen hat und daß alle Teilnehmer
eine falsche Rahmensynchronisation haben. Der Sender gibt
deshalb im Zustand ERROR-HANDLING eine Fehlermeldung. Bei
empfangenen LOW-Pegel wird in den Folgezustand
RECEIVE-ACK-DELIMITER übergegangen. Der ACK-DELIMITER muß
stets HIGH sein. Ist dies nicht der Fall, so wird nach
ERROR-HANDLING gesprungen.
Das Botschaftsende wird im Zustand TRANSMIT-END-OF-FRAME
übertragen. Da END-OF-FRAME aus sieben HIGH-Bits besteht, wird
der Zähler CNTR mit EOFL=7 (END-OF-FRAME-LENGTH) vorbelegt.
Bei empfangenem HIGH-Pegel bleibt das System im Zustand
TRANSMIT-END-OF-FRAME, bis der Zähler abgelaufen ist und geht
dann zu TEST-INTERMISSION über. Bei empfangenem LOW-Pegel wird
dagegen nach ERROR-HANDLING gesprungen.
Mit dem Übergang in den Zustand TEST-INTERMISSION ist der
TRANSMIT-MODE beendet. Der Zustand TEST-INTERMISSION ist mit
dem im RECEIVE-MODE beschriebenen identisch.
Die Fehlerbehandlung beginnt mit dem Zustand SEND-ERROR-FLAG.
Das ERROR-FLAG dient dazu, allen Teilnehmern mitzuteilen, daß
auf dem Bus ein Übertragungsfehler stattgefunden hat oder daß
ein Empfänger überlastet ist. Das ERROR-FLAG besteht aus
sechs aufeinanderfolgenden LOW-Bits, deshalb wird der Zähler
CNTR beim Einstieg in SEND-ERROR-FLAG auf EFL=6
(ERROR-FLAG-LENGTH) gesetzt. Falls eine Störung die gesendeten
dominanten Pegel LOW nach HIGH verfälscht, wird noch einmal
mit ERROR-HANDLING begonnen. Sonst wird der Zähler
dekrementiert. Beim Zählerstand Null erfordert der Übergang zum
Zustand ERROR-SYNC.
Im Zustand ERROR-SYNC wird gewartet, bis andere Teilnehmer, die
eventuell auch ein ERROR-FLAG senden, fertig sind. Dies wird
daran erkannt, daß der Buspegel nach HIGH geht.
Die Fehlerbehandlung wird durch das Senden des ERROR-DELIMITERs
im Zustand SEND-ERROR-DELIMITER abgeschlossen. Beim Einstieg
wird der Zähler CNTR mit EDL-1=6 (ERROR-DELIMITER-LENGTH=7)
vorbelegt. Der ERROR-DELIMITER besteht aus sieben HIGH-Bits,
das erste dieser Bits wurde jedoch bereits im Zustand
ERROR-SYNC gesendet. Wird beim Senden der restlichen Bits auf
dem Bus ein LOW-Pegel entdeckt, so wird erneut mit
ERROR-HANDLING begonnen. Sonst wird nach dem Ablaufen des
Zählers zum Zustand TEST-INTERMISSION weitergegangen. Damit
ist die Fehlerbehandlung beendet.
Jeder Teilnehmer sendet sofort nach einem erkannten Fehler, d. h.
beginnend mit dem auf den Fehlerzustand folgenden Bit, seine
Fehlermeldung (ERROR-FLAG). Nur bei Erkenntnis eines CRC-Fehlers
wird die Fehlermeldung erst drei Takte später abgeschickt.
Dadurch wird sichergestellt, daß das ACK-FIELD nicht durch
eine von einem CRC-Fehler ausgelöste Fehlermeldung
überschrieben wird. Durch das Freihalten des ACK-FIELD kann
ein Sender sowohl eine Bestätigung seiner Botschaft von
einigen Empfängern erhalten als auch eine Fehlermeldung von
den restlichen Empfängern. Dies bietet die Möglichkeit, im
Wiederholungsfall mit hoher Wahrscheinlichkeit festzustellen,
ob der Ausfall beim Teilnehmer (Sender) selbst oder bei einem
Empfänger 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 abgewertet werden (ERROR-DELIMITER und INTERMISSION).
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.
Auf Grund der in 4.3 beschriebenen Festlegung des Busprotokolls
und der in 4.4 spezifizierten Bus-Organisation können folgende
Fehlerklassen auftreten:
Sender | |
BF | |
Bitfehler, Buspegel stimmt nicht mit gesendeten Pegel überein. | |
BK | Im Zustand TRANSMIT-IDENTIFIER (Arbitrierungs) und TRANSMIT-START-OF-FRAME gilt nur Buspegel HIGH bei gesendetem LOW als Fehler |
AF | kein Acknowledge während RECEIVE-ACKNOWLEDGE |
NF | Während des Zustands TEST-INTERMISSION ein LOW-Bit auf dem Bus |
SF | Verletzung der Stuffvorschrift |
Empfänger | |
CF | |
CRC-Fehler | |
DF | die CRC-SEQUENCE ist nicht mit einem CRC-DELIMITER abgeschlossen, d. h. auf das CRC-Kontrollwort folgt kein HIGH-Bit |
NF | Während der Zustände RECEIVE-END-OF-FRAME und TEST-INTERMISSION ist ein LOW-Bit auf dem Bus |
SF | Verletzung der Stuffvorschrift |
BF | Bitfehler im Zustand TRANSMIT-ACK |
In der nachfolgenden Tabelle 4.6.3 sind alle Fehlererkennungsmöglichkeiten
zusammengestellt, die sich aus den Kombinationen
aus zeitlichem und räumlichem Auftreten sowie der
Fehlerklassen ergeben. Ansonsten sind die zum Zeitpunkt des
Fehlers erkennbaren Fehlerklassen.
Die Abkürzungen in der oberen Zeile jedes Feldes der Matrix
charakterisieren die am Sender auftretenden Fehlerklassen, die
in der unteren Reihe die an den Empfängern auftretenden
Fehlerklassen.
In den Bildern werden folgende Abkürzungen verwendet:
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.
- 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.
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.
Der Sender erkennt einen Bitfehler und die gestörten
Empfänger erkennen einen Stuffehler und setzen eine
Fehlermeldung ab. Dadurch entsteht an den nicht gestörten
Empfängern ein Stuffehler und sie setzen ebenfalls eine
Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung und
anschließender Busruhe (Zustand BUS-IDLE) kann mit neuen
Übertragungen oder der Wiederholung der gestörten Nachricht
begonnen werden.
Die gestörten Empfänger erkennen einen Bitfehler (ihr LOW Bit
wird gestört) und setzen eine Fehlermeldung ab. Der Sender
bekommt keine Acknowledge und setzt ebenfalls eine Fehlermeldung
ab. Dadurch erkennen die nicht gestörten Empfänger einen
Fehler (ACK-DELIMITER) und sie setzten ebenfalls eine
Fehlermeldung ab. Nach dem letzten LOW Bit der Fehlermeldung
kann mit neuen Übertragungen oder der Wiederholung der
gestörten Botschaft begonnen werden.
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.
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.
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.
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.
Die gestörten Empfänger erhalten durch die Störung eine
falsche Längenangabe und setzen deshalb ihre CRC-Check an die
falsche Stelle. Wenn der CRC der gestörten Empfänger um mehr
als 8 Takte später als die richtige Lage erfolgt, so erhalten
die Empfänger einen Stuffehler und setzen eine Fehlermeldung
ab. Erfolgt der CRC-Check innerhalb von 8 Takten nach der
richtigen Lage, so erkennen die gestörten Empfänger einen
CRC-Fehler und senden eine Fehlermeldung. Dadurch entsteht am
Sender ein Bitfehler. Die nicht gestörten Empfänger empfangen
als END-OF-FRAME eine unzulässige Bitfolge und setzen
ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der
Fehlermeldung und anschließender Busruhe (Zustand BUS-IDLE)
kann mit neuen Übertragungen oder der Wiederholung der
gestörten Nachricht begonnen werden.
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.
Der IMP hat folgende Aufgaben
- Datenaustausch zwischen CPU und serieller Schnittstelle
durch die Benutzung eines DUAL PORT RAM (DPRAM)
- Steuerung von Senden und Empfangen
- Steuerung von Senden und Empfangen
Fig. 11 zeigt das Blockschaltbild des seriellen
Schnittstellenbausteins. Der serielle Schnittstellenbaustein
besteht aus den Teilen:
- DPRAM
- IMP
- serielles Schieberegister
- Buslogik
- Taktoszillator
- IMP
- serielles Schieberegister
- Buslogik
- Taktoszillator
Die Verbindungen der Teile untereinander sind im
Blockschaltbild angegeben.
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.
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 anzeigt wird.
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.
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.
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
- 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 Speicher
platz zu sparen, ist es angebracht, die Botschaften hintereinander
dichtgepackt abzuspeichern, mit einer Länge von drei bis zehn
Bytes abhängig von der DATA-BYTE-COUNT.
Die Größe des DPRAM ist zur Zeit auf 64 Byte festgelegt. Wenn
die Integrationskosten in Zukunft kleiner werden sollten, kann
der Speicher vergrößert werden. Damit könnten eine größere
Anzahl von Botschaften oder längere Botschaften (sowohl
DATA-FIELD als auch DESCRIPTOR) gespeichert werden. Es könnten
auch Ersatzbotschaften für das Ausbleiben von Nachrichten im
DPRAM abgelegt werden, was im Fehlerfall die Software
vereinfachen würde.
Das DPRAM dient also als:
- Speicher, der gleichzeitig entscheidet ob ankommende
Botschaften empfangen werden sollen (Akzeptanzfilter)
- Warteschlange für ankommende und fortgehende Botschaften geordnet nach ihrer Priorität
- Speicher für die Kontrollregister des IMP
- Warteschlange für ankommende und fortgehende Botschaften geordnet nach ihrer Priorität
- Speicher für die Kontrollregister des IMP
Bei Suchvorgängen muß der Adreß Zeiger des DPRAM zuerst auf
den jeweiligen Anfang einer Botschaft zeigen. Wenn die
DESCRIPTORen und DATA-FIELDs dichtgepackt abgespeichert sind,
kann auf die nächste Botschaft gezeigt werden indem man den
Zeiger um
2** (DATA-BYTE-COUNT) + 2
erhöht. Um den Speicherplatz und die Botschaften besser
auszunützen, können mehrere Botschaften unter einem
DESCRIPTOR zusammengefaßt werden und als eine große Botschaft
übertragen werden. Die maximale Blockgröße wird vorerst auf
8 Bytes festgelegt.
Die Länge des DATA-FIELDs enthält man aus dem DATA-BYTE-CODE
mit
DATA-BYTE-COUNT = 2** DATA-BYTE-CODE
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.
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.
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.
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.
Ein gesetztes TRANSMISSION-REQUEST Bit veranlaßt den IMP die
zugehörige Botschaft zu übertragen.
Es gibt zwei verschiedene Zustände:
- a. RECEIVE/TRANSMIT = LOW (Übertragung)
Start nach einem Reset. Die Botschaft wird gesendet. TRANSMISSION-REQUEST wird von der CPU oder von einer ankommenden Botschaft mit gesetztem REMOTE-TRANSMISSION-REQUEST Bit auf HIGH gesetzt. - b. RECEIVE/TRANSMIT = HIGH (Empfang)
Alle so gekennzeichneten Botschaften sind im Empfangsmodus. Als Ausnahme in diesem Zustand wird durch OP Setzen von TRANSMISSION-REQUEST eine Botschaft mit leerem DATA-FIELD und gesetztem REMOTE-TRANSMISSION-REQUEST abgeschickt.
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.
Der Austausch von DATA-FIELDs, die aus mehreren Bytes bestehen,
kann abhängig von der Anwendung
ohne Berücksichtigung von der
synchronen Betriebsweise vorgenommen werden. Wenn die
DATA-FIELDs jedoch synchron verarbeitet werden sollen, muß
eine geeignete Synchronisation vorgesehen werden. Um die
Hardwarekosten niedrig zu halten, wird zur Zeit eine
Software-Synchronisation vorgeschlagen. In dieser Vorgehenweise
greift die CPU auf das DPRAM im Cycle Stealing mit Priorität
gegenüber allen anderen Zugriffsversuchen zu.
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.
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.
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.
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.
Um DATA-FIELDs synchron zu bearbeiten können diese blockweise
zu und von CPU übertragen werden. Ausreichender RAM
Speicherplatz muß für die dadurch bedingte doppelte
Speicherung bereitgestellt werden.
- a. Senden
Am Anfang wird TRANSMISSION-REQUEST, das als Semaphor Variable dient, geprüft. Wenn es zurückgesetzt ist, wird das DATA-FIELD byteweise vom CPU-RAM ins DPRAM übertragen. Danach wird TRANSMISSION-REQUEST gesetzt. Warnung:
Bei dieser Vorgehensweise kann im Falle eines gesetzten REMOTE-TRANSMISSION-REQUEST Bits keine korrekte Synchronisation garantiert werden. - b. Empfang
Bevor die eigentliche Interruptroutine begonnen wird, wird das DATA-FIELD blockweise ins CPU-RAM übertragen, wie unter 4.7.2.4.2. beschrieben. Dadurch wird die Wahrscheinlichkeit, daß die Daten inkonsistent werden, beträchtlich verringert, da der kritische Zeitabschnitt von der gesamten Interruptbearbeitung auf die Blockübertragung des DATA-FIELDs verringert wird.
Für wichtige Botschaften können zwei Speicherplätze im DPRAM
vorgesehen werden. Ein IDENTIFIER erscheint dann zweimal im
DPRAM. Die Benutzersoftware kann nun ankommende Botschaften von
einem Speicherplatz im DPRAM auf einen anderen durch Ändern
des zugehörigen RECEIVE/TRANSMIT Bits, anschließend an die
Bestätigung des Interrupts, umschalten. Bei dieser Vorgehensweise
ist in einem Speicherplatz das RECEIVE/TRANSMIT Bit HIGH, und ist
damit bereit, die entsprechende Botschaft aufzunehmen, und
im anderen Speicherplatz mit dem gleichen
IDENTIFIER ist das RECEIVE/TRANSMIT Bit LOW, und damit ist die
gerade empfangene Botschaft dort schreibgeschützt.
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.
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.
- - Ende der Übertragung:
Endsignal am Ende einer fehlerfrei abgeschlossenen Übertragung. Wird beim Übergang aus dem Zustand TRANSMIT-END-OF-FRAME in den Zustand TEST-INTERMISSION für einen Bustakt gesetzt, - Ende der Arbitrierung:
Signal am Ende des Arbitrierungsvorgangs; nach Auftreten dieses Signals ist der BUS-Zugriff geregelt (Senden oder Empfangen). Wird am Ende der Übertragung des IDENTIFIERs für einen Bustakt gesetzt. - - Start Search:
Startsignal für den SEARCH-Prozeß, vom Anfang des DPRAM an den Suchvorgang neu zu beginnen; erfolgt am Ende des RECEIVE/TRANSMIT-Prozesses. - - Übertragungsfehler:
Fehlermeldung vom Übertragungsvorgang. Wird für einen Bustakt gesetzt, wenn eine Fehlermeldung auf dem Bus übertragen wird. - - Beginn der Übertragung:
Startsignal für den LOAD-Prozeß, erfolgt am Ende des STORE-Prozesses oder des ERROR-Prozesses - - Weitermachen:
Erneuter Start bei Endlos-Prozessen
Die Prozesse sind im folgenden unter Zuhilfenahme der üblichen
Kontrollfluß-Konstrukte erklärt, wie sie in ALGOL oder PASCAL
verwendet werden und mit denen auch in der Informatik-Literatur
gearbeitet wird.
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.
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.
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.
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.
Im Falle daß die Arbitrierung gewonnen wurde, wird das PENDING
Bit, das zur gerade übertragenen Botschaft gehört, auf HIGH
gesetzt und dann der zugehörige TX-POINTER auf den Stack
geladen. Der RECEIVE/TRANSMIT-Prozeß setzt je nach Ausgang
der Arbitrierung den TX-POINTER oder den RX-POINTER auf einen
leeren Adreßzeiger zurück, bevor der SEARCH-Prozeß durch
Start Search aktiviert wird.
Der SEARCH-Prozeß sucht andauernd nach Adreßzeigern des DPRAM
für
- zu übertragende Botschaften (TX-POINTER),
wenn TRANSMISSION-REQUEST gesetzt ist,
- zu empfangende Botschaften (RX-POINTER), d.h. ob der empfangene IDENTIFIER im DPRAM enthalten ist,
- Botschaften, die eine Unterbrechungsanforderung bei der CPU auslösen sollen, d. h. bei denen INTERRUPT-REQUEST und INTERRUPT-ENABLE gesetzt sind.
- zu empfangende Botschaften (RX-POINTER), d.h. ob der empfangene IDENTIFIER im DPRAM enthalten ist,
- Botschaften, die eine Unterbrechungsanforderung bei der CPU auslösen sollen, d. h. bei denen INTERRUPT-REQUEST und INTERRUPT-ENABLE gesetzt sind.
Der SEARCH-Prozeß wird mit Start Search auf die Botschaft mit
der höchsten Priorität am Anfang des DPRAM zurückgesetzt,
wenn die Echtzeitabläufe bei der Übertragung auf dem BUS es
erfordern. Das Absuchen einer gesamten Botschaft ist als
unteilbare Operation ausgeführt. In jeder Clock-Periode kann
der SEARCH-Prozeß durch einen DPRAM-Zugriff der CPU im
Cycle-Stealings-Verfahren angehalten und um eine Clock-Periode
verzögert werden. Nach Abschluß der unteilbaren Operation
kann der SEARCH-Prozeß durch höherpriore Prozesse vom Zugriff
des DPRAM ausgeschlossen werden, bis die Semaphore-Variable
wieder vom SEARCH-Prozeß selbst gesetzt werden kann.
Der INTERRUPT-HANDLING-Prozeß leitet Interrupts von
empfangenen Botschaften oder von mehrfach fehlerhaft
übertragenen Botschaften an die CPU weiter. Es wird jeweils
der Interrupt mit der durch die Anordnung im DPRAM vorgegeben
höchsten Priorität an die CPU weitergeleitet. Der INTERRUPT-
HANDLING-Prozeß läuft ununterbrochen, parallel zu den
anderen Prozessen. Der Anfangswert des Interrupt Pointers ist
der leere Adreßzeiger.
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
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.
Auf den DPRAM wird von verschiedenen Quellen aus zugegriffen,
der CPU und den parallelen Prozessen. Die Adressen kommen dabei
von
- - CPU-Adresse
- - EMPTY-POINTER:
Adreßzeiger, der auf eine leerem, d. h. nicht mit sinnvollen Botschaften gefüllten Adresse zeigt. Wenn ein Adreßzeiger gleich dem EMPTY-POINTER ist, wird dies so interpretiert, daß keine entsprechende Botschaft vorliegt - - SEARCH-POINTER:
Adreßzeiger des SEARCH-Prozesses - - TX-POINTER:
Adreßzeiger, der auf die zu sendende Botschaft zeigt. Falls keine Botschaft zu senden ist, ist der TX-POINTER = EMPTY-POINTER - - RX-POINTER:
Adreßzeiger, der auf die zu empfangende Botschaft zeigt. Falls keine Botschaft zu empfangen ist, ist der RX-POINTER = EMPTY-POINTER - - INTERRUPT-POINTER:
Adreßzeiger, der auf die Botschaft zeigt, die eine Unterbrechungsanforderung an die CPU hat. Falls keine Unterbrechungsanforderung vorliegt, ist der INTERRUPT-POINTER = EMPTY-POINTER
Die Adreßzeiger (Pointer) werden in den verschiedenen
Prozessen verarbeitet, um die DPRAM-Adresse zu erhalten, unter
der Daten gespeichert oder gelesen werden sollen. Die
tatsächlichen DPRAM-Zugriffe mittels der Adreßzeiger sind
entsprechend ihrer Priorität organisiert. Unteilbare Zugriffe
auf mehrere Bytes geschehen mittels der Semaphore-Variablen,
die den Zugriff für alle Prozesse blockiert, außer für den
Prozeß, der die Semaphore-Variable selbst gesetzt hat.
Wie bereits beschrieben, werden der CPU-Zugriff auf den DPRAM
und das Setzen der Semaphore-Variablen nach Prioritäten
geordnet. Ein Prozeß darf seine Adresse nur dann an den
Adreßeingang des DPRAM legen, wenn die CPU nicht zugreifen
will (kein Access request und deshalb auch kein Access inhibit)
und wenn die Semaphore-Variable nicht von einem anderen Prozeß
belegt ist (Semaphore = LOW). Die Anschlüsse von LOAD, ERROR,
INTERRUPT-HANDLING, RECEIVE/TRANSMIT und SEARCH sind gleich wie
bei STORE und deshalb nicht detailliert gezeichnet.
Eine Ausführung für den Block "Access Control" des obigen
Schemas ist im folgenden Flußdiagramm angegeben, das in jeder
Clock-Periode durchlaufen wird.
Im obigen Flußdiagramm wurden die Abkürzungen verwendet:
- INT-HA for INTERRUPT-HANDLING
- REC/TR for RECEIVE/TRANSMIT and
- per for period.
- REC/TR for RECEIVE/TRANSMIT and
- per for period.
Claims (5)
1. Verfahren zum Betreiben einer Datenverarbeitungs
anlage, insbesondere für Kraftfahrzeuge, mit wenigstens
zwei Rechnern, einer die Rechner verbindenden
Leitung zur Übertragung von Botschaften (messages),
wobei auf der Leitung dominante und rezessive Zustände
übertragen werden und von den Rechnern Fehlermeldungen
ausgebbar sind, dadurch gekennzeichnet,
daß die Fehlermeldungen zu jedem beliebigen Zeitpunkt nach der Erkennung des Fehlers während der laufenden Übertragung der Botschaft gesendet werden,
daß die Fehlermeldung aus einer mit bei der Übertragung von Botschaften auftretenden Zustandsfolgen nicht zu ver wechselnden Zustandsfolge dominanter Zustände besteht,
daß nach dem Senden der Zustandsfolge dominanter Zustände gewartet wird, bis andere Teilnehmer, die eventuell auch die nicht zu verwechselnde Zu standsfolge dominanter Zustände senden, fertig sind (Error Sync.),
daß danach ein Error-Delimiter gesendet wird, mit dem die Fehlerbehandlung abgeschlossen wird.
daß die Fehlermeldungen zu jedem beliebigen Zeitpunkt nach der Erkennung des Fehlers während der laufenden Übertragung der Botschaft gesendet werden,
daß die Fehlermeldung aus einer mit bei der Übertragung von Botschaften auftretenden Zustandsfolgen nicht zu ver wechselnden Zustandsfolge dominanter Zustände besteht,
daß nach dem Senden der Zustandsfolge dominanter Zustände gewartet wird, bis andere Teilnehmer, die eventuell auch die nicht zu verwechselnde Zu standsfolge dominanter Zustände senden, fertig sind (Error Sync.),
daß danach ein Error-Delimiter gesendet wird, mit dem die Fehlerbehandlung abgeschlossen wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Ende der
Fehlermeldung zur zeitlichen Synchronisation aller Teilnehmer dient.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß bei mehreren Fehlermeldungen das Ende der
letzten Fehlermeldung der Synchronisation dient.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der informationstragende
Teil der Botschaft mit einer nicht dominanten Zustandsfolge abgeschlossen wird.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die nicht dominante Zustandsfolge am Ende
der Botschaft um mindestens einen Zustand länger ist als die für die Fehlererkennung erforderliche minimale
Zustandsfolge.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE3546664A DE3546664C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19853506118 DE3506118A1 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge |
DE3546664A DE3546664C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
Publications (2)
Publication Number | Publication Date |
---|---|
DE3546664C2 DE3546664C2 (en) | 1991-03-07 |
DE3546664C3 true DE3546664C3 (de) | 1995-10-26 |
Family
ID=6263209
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE3546662A Expired - Lifetime DE3546662C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
DE19853506118 Granted DE3506118A1 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge |
DE3546664A Expired - Lifetime DE3546664C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
DE3546683A Expired - Lifetime DE3546683C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE3546662A Expired - Lifetime DE3546662C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
DE19853506118 Granted DE3506118A1 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE3546683A Expired - Lifetime DE3546683C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
Country Status (4)
Country | Link |
---|---|
US (5) | US5001642A (de) |
JP (3) | JP2545508B2 (de) |
DE (4) | DE3546662C3 (de) |
FR (1) | FR2578070B1 (de) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10027845B4 (de) * | 1999-06-22 | 2008-01-10 | Ford Motor Company, Dearborn | Submodul für die Kontrolle einer Datenwarteschlange |
Families Citing this family (141)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3546662C3 (de) * | 1985-02-22 | 1997-04-03 | Bosch Gmbh Robert | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
JPH01148645A (ja) * | 1987-12-04 | 1989-06-12 | Sumitomo Electric Ind Ltd | 車両スリップ制御装置 |
FR2627039B1 (de) * | 1988-02-10 | 1994-01-21 | Peugeot Automobiles | |
JP2726931B2 (ja) * | 1988-03-15 | 1998-03-11 | 三菱農機株式会社 | 移動農機の制御装置 |
DE3826774A1 (de) * | 1988-08-06 | 1990-02-08 | Bosch Gmbh Robert | Netzwerkschnittstelle |
DE3926165A1 (de) * | 1989-08-08 | 1991-02-14 | Bodenseewerk Geraetetech | Sender- und empfaengeranordnung als schnittstelle zu einem mikroprozessor |
DE3927968A1 (de) * | 1989-08-24 | 1991-02-28 | Bosch Gmbh Robert | Verfahren zur datenuebertragung ueber einen seriellen datenbus in verteilten systemen |
JP2904298B2 (ja) * | 1990-03-30 | 1999-06-14 | マツダ株式会社 | 車両用多重伝送装置 |
JP2915080B2 (ja) * | 1990-05-25 | 1999-07-05 | 株式会社日立製作所 | マルチプロセッサシステムにおけるデータ処理方法 |
DE4028809B4 (de) * | 1990-09-11 | 2005-03-10 | Bosch Gmbh Robert | System zur Steuerung eines Kraftfahrzeugs |
DE4028926A1 (de) * | 1990-09-12 | 1992-03-19 | Teves Gmbh Alfred | Schaltungsanordnung zur steuerung von elektrischen oder elektromechanischen verbrauchern |
FR2668624B1 (fr) * | 1990-10-30 | 1993-02-19 | Renault | Dispositif de reconnaissance d'adresses pour module electronique de traitement de donnees. |
DE4039483A1 (de) * | 1990-12-11 | 1992-06-17 | Bayerische Motoren Werke Ag | Linearer datenbus |
GB2251499A (en) * | 1991-01-05 | 1992-07-08 | Delco Electronics Corp | Electronic control module. |
DE4129205A1 (de) * | 1991-03-28 | 1992-10-01 | Bosch Gmbh Robert | Verfahren zum aufbau von botschaften fuer den datenaustausch und/oder fuer die synchronisation von prozessen in datenverarbeitungsanlagen |
JP2598178B2 (ja) * | 1991-04-30 | 1997-04-09 | 三菱電機株式会社 | 通信システム |
DE4121999A1 (de) * | 1991-07-03 | 1993-01-07 | Bosch Gmbh Robert | Lichtmischstecker fuer einen optobus |
DE4122084A1 (de) * | 1991-07-04 | 1993-01-07 | Bosch Gmbh Robert | Verfahren zur informationsuebertragung in einem mehrere teilnehmer aufweisenden bussystem |
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 |
ES2342136T3 (es) | 1996-07-24 | 2010-07-01 | Robert Bosch Gmbh | Procedimiento para sincronizar datos e interfaz de transmision. |
JP3183181B2 (ja) * | 1996-08-28 | 2001-07-03 | トヨタ自動車株式会社 | 情報送信方法 |
DE19637312A1 (de) | 1996-09-12 | 1998-03-19 | Bosch Gmbh Robert | Verfahren zur Kontrolle der Verbindungen eines Übertragungssystems und Komponente zur Durchführung des Verfahrens |
US5813972A (en) * | 1996-09-30 | 1998-09-29 | Minnesota Mining And Manufacturing Company | Medical perfusion system with data communications network |
US5752931A (en) * | 1996-09-30 | 1998-05-19 | Minnesota Mining And Manufacturing Company | Perfusion system with perfusion circuit display |
US6164920A (en) * | 1996-09-30 | 2000-12-26 | Minnesota Mining And Manufacturing Company | Perfusion system with control network |
US5995512A (en) * | 1997-01-17 | 1999-11-30 | Delco Electronics Corporation | High speed multimedia data network |
JP3117000B2 (ja) * | 1997-02-21 | 2000-12-11 | 株式会社デンソー | 通信システムおよびそれに使用される電子制御装置 |
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 |
US6370449B1 (en) * | 1999-06-14 | 2002-04-09 | Sun Microsystems, Inc. | Upgradable vehicle component architecture |
US6507810B2 (en) | 1999-06-14 | 2003-01-14 | Sun Microsystems, Inc. | Integrated sub-network for a vehicle |
US6975612B1 (en) | 1999-06-14 | 2005-12-13 | Sun Microsystems, Inc. | System and method for providing software upgrades to a vehicle |
US6253122B1 (en) | 1999-06-14 | 2001-06-26 | Sun Microsystems, Inc. | Software upgradable dashboard |
US6362730B2 (en) | 1999-06-14 | 2002-03-26 | Sun Microsystems, Inc. | System and method for collecting vehicle information |
US6754183B1 (en) | 1999-06-14 | 2004-06-22 | Sun Microsystems, Inc. | System and method for integrating a vehicle subnetwork into a primary network |
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 | Canコントローラおよびcanコントローラを内蔵したワンチップ・コンピュータ |
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 | 株式会社デンソー | 通信制御装置 |
GB2385665B (en) * | 2001-10-19 | 2004-06-02 | Visteon Global Tech Inc | Engine combustion monitoring and control with intergrated cylinder head gasket combustion sensor |
US20030090161A1 (en) * | 2001-10-19 | 2003-05-15 | Marlow C. Allen | Light communication channel-based electronics power distribution system |
US20030095675A1 (en) * | 2001-10-19 | 2003-05-22 | Marlow C. Allen | Light communication channel-based voice-activated control system and method for implementing thereof |
US7024067B2 (en) * | 2001-10-19 | 2006-04-04 | Visteon Global Technologies, Inc. | Communication system with a signal conduction matrix and surface signal router |
US6949758B2 (en) * | 2001-10-19 | 2005-09-27 | Visteon Global Technologies, Inc. | LCC-based fluid-level detection sensor |
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 |
EP1714294B1 (de) * | 2004-02-10 | 2016-04-20 | Semiconductor Energy Laboratory Co., Ltd. | Nichtflüchtiger speicher |
DE102004013629B4 (de) * | 2004-03-19 | 2023-06-01 | Volkswagen Ag | Kommunikationssystem für ein Kraftfahrzeug |
WO2006003540A1 (en) * | 2004-06-30 | 2006-01-12 | Philips Intellectual Property & Standards Gmbh | Method for the non-bitrate-dependent encoding of digital signals on a bus system |
FR2876482B1 (fr) * | 2004-10-07 | 2007-01-12 | Siemens Transp Systems Soc Par | Dispositif d'envoi de commande de sortie securisee |
JP4531555B2 (ja) * | 2004-12-27 | 2010-08-25 | ルネサスエレクトロニクス株式会社 | データ処理モジュール及びその送付候補メッセージの決定方法 |
JP4594124B2 (ja) | 2005-02-07 | 2010-12-08 | ルネサスエレクトロニクス株式会社 | 通信システム及び通信方法 |
JP2006236047A (ja) * | 2005-02-25 | 2006-09-07 | Renesas Technology Corp | 半導体集積回路装置 |
JP4721741B2 (ja) * | 2005-03-25 | 2011-07-13 | ルネサスエレクトロニクス株式会社 | データ処理モジュール及びそのメッセージ受信方法 |
DE102005014783A1 (de) * | 2005-03-31 | 2006-10-05 | Siemens Ag | Verfahren und Vorrichtungen zum Übertragen von Daten auf eine Datenleitung zwischen einem Steuergerät und zumindest einem dezentralen Datenverarbeitungsgerät |
JP2007034892A (ja) * | 2005-07-29 | 2007-02-08 | Nec Electronics Corp | データ処理モジュール及びそのメッセージ送信終了処理方法 |
US7769932B2 (en) * | 2005-09-09 | 2010-08-03 | Honeywell International, Inc. | Bitwise arbitration on a serial bus using arbitrarily selected nodes for bit synchronization |
US7680144B2 (en) * | 2006-09-12 | 2010-03-16 | Honeywell International Inc. | Device coupled between serial busses using bitwise arbitration |
EP2441229B1 (de) * | 2009-06-11 | 2020-05-06 | Panasonic Avionics Corporation | System und verfahren zur bereitstellung von sicherheit auf einer beweglichen plattform |
US8327189B1 (en) | 2009-12-22 | 2012-12-04 | Emc Corporation | Diagnosing an incident on a computer system using a diagnostics analyzer database |
CN102971214B (zh) | 2010-04-27 | 2016-01-13 | 松下航空电子公司 | 用于用户接口设备的连接支撑系统及方法 |
US8897974B2 (en) * | 2010-06-07 | 2014-11-25 | Gm Global Technology Operations, Llc | Gear selector system |
US20140016654A1 (en) * | 2011-03-31 | 2014-01-16 | Renesas Electronics Corporation | Can communication system, can transmission apparatus, can reception apparatus, and can communication method |
US9577788B2 (en) | 2011-06-15 | 2017-02-21 | Denso Corporation | Coding apparatus, coding method, data communication apparatus, and data communication method |
JP5532030B2 (ja) * | 2011-09-07 | 2014-06-25 | 株式会社デンソー | データ通信方法及びデータ通信装置 |
JP2013058845A (ja) * | 2011-09-07 | 2013-03-28 | Denso Corp | データ通信方法及びデータ通信システム |
US9160620B2 (en) * | 2011-11-30 | 2015-10-13 | GM Global Technology Operations LLC | Integrated fault diagnosis and prognosis for in-vehicle communications |
US8817810B2 (en) * | 2012-06-27 | 2014-08-26 | Nxp B.V. | Communications apparatus, system and method with error mitigation |
US9678131B2 (en) | 2014-05-27 | 2017-06-13 | GM Global Technology Operations LLC | Method and apparatus for short fault isolation in a controller area network |
US9568533B2 (en) | 2014-05-27 | 2017-02-14 | GM Global Technology Operations LLC | Method and apparatus for open-wire fault detection and diagnosis in a controller area network |
EP2984780A4 (de) * | 2014-06-10 | 2016-10-05 | Halliburton Energy Services Inc | Synchronisation von empfängereinheiten über einen steuerbereichsnetzwerkbus |
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 | 株式会社東芝 | 通信装置、通信システム、通信方法及びプログラム |
FR3113150A1 (fr) * | 2020-07-30 | 2022-02-04 | Psa Automobiles Sa | Formatage d’informations de défaut par filtrage |
FR3113149A1 (fr) * | 2020-07-30 | 2022-02-04 | Psa Automobiles Sa | Formatage d’informations de défaut par ajout d’identifiant |
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数据交互方法和系统 |
DE112022000521T5 (de) | 2021-03-01 | 2023-10-26 | Rohm Co., Ltd. | Sendeschaltung, elektronische steuereinheit und fahrzeug |
WO2022185784A1 (ja) * | 2021-03-01 | 2022-09-09 | ローム株式会社 | 遅延信号生成回路、送信回路、電子制御ユニット、及び車両 |
Family Cites Families (58)
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 |
EP0014556B1 (de) * | 1979-02-01 | 1983-08-03 | WARD & GOLDSTONE LIMITED | Multiplexsystem zur Informationsverarbeitung und ein dieses System enthaltendes Fahrzeug |
GB2058418A (en) * | 1979-07-06 | 1981-04-08 | Ward Goldstone Ltd | A multiplex information handling system |
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 |
US4945471A (en) * | 1981-04-01 | 1990-07-31 | Teradata Corporation | Message transmission system for selectively transmitting one of two colliding messages based on contents thereof |
US4412285A (en) * | 1981-04-01 | 1983-10-25 | Teradata Corporation | Multiprocessor intercommunication system and method |
DE3114734A1 (de) | 1981-04-11 | 1982-10-28 | Licentia Patent-Verwaltungs-Gmbh, 6000 Frankfurt | Einrichtung zur datenuebertragung zwischen einem rechner und externen teilnehmern |
JPS57208746A (en) * | 1981-06-18 | 1982-12-21 | Toyota Motor Corp | Transmission controlling system |
FR2508257B1 (fr) * | 1981-06-19 | 1988-04-29 | Peugeot | Procede de transmission de messages entre modules emetteurs recepteurs autonomes possedant des horloges et des dispositifs de synchronisation internes independants |
US4482951A (en) | 1981-11-12 | 1984-11-13 | Hughes Aircraft Company | Direct memory access method for use with a multiplexed data bus |
US4463445A (en) * | 1982-01-07 | 1984-07-31 | Bell Telephone Laboratories, Incorporated | Circuitry for allocating access to a demand-shared bus |
JPS58120340A (ja) * | 1982-01-13 | 1983-07-18 | Fujitsu Ltd | フレ−ム伝送方式 |
JPS5940728A (ja) * | 1982-08-31 | 1984-03-06 | Matsushita Electric Works Ltd | 電力線搬送制御装置 |
JPS5970851A (ja) * | 1982-10-18 | 1984-04-21 | Caterpillar Mitsubishi Ltd | 油圧補機装備車輌の用途別負荷に対応した運転指令装置 |
JPS5991527A (ja) * | 1982-11-17 | 1984-05-26 | Hitachi Ltd | バス優先制御方式 |
JPS59110245A (ja) * | 1982-12-15 | 1984-06-26 | Meidensha Electric Mfg Co Ltd | マルチドロツプ方式の情報伝送方式 |
CA1219091A (en) * | 1983-01-10 | 1987-03-10 | Ulrich Killat | Method of and arrangement for controlling access to a time-division multiplex message transmission path |
JPH0612895B2 (ja) * | 1983-01-24 | 1994-02-16 | 株式会社東芝 | 情報処理システム |
US4534025A (en) * | 1983-02-24 | 1985-08-06 | United Technologies Automotive, Inc. | Vehicle multiplex system having protocol/format for secure communication transactions |
JPS59175242A (ja) * | 1983-03-25 | 1984-10-04 | Ricoh Co Ltd | Arq伝送方式 |
US4561092A (en) * | 1983-05-13 | 1985-12-24 | The Bdm Corporation | Method and apparatus for data communications over local area and small area networks |
US4556943A (en) * | 1983-05-27 | 1985-12-03 | Allied Corporation | Multiprocessing microprocessor based engine control system for an internal combustion engine |
JPS60551A (ja) * | 1983-06-16 | 1985-01-05 | Hitachi Ltd | 自動車用データ伝送システム |
DE3335932A1 (de) * | 1983-10-04 | 1985-04-18 | Wabco Westinghouse Fahrzeugbremsen GmbH, 3000 Hannover | Einrichtung zum abfragen und steuern von mehreren komponeneten eines fahrzeuges |
JPS59112045A (ja) * | 1983-11-17 | 1984-06-28 | 村田機械株式会社 | 紡績糸 |
US4566097A (en) * | 1983-12-23 | 1986-01-21 | International Business Machines Corp. | Token ring with secondary transmit opportunities |
US4652873A (en) * | 1984-01-18 | 1987-03-24 | The Babcock & Wilcox Company | Access control for a plurality of modules to a common bus |
US4654655A (en) * | 1984-03-02 | 1987-03-31 | Motorola, Inc. | Multi-user serial data bus |
CA1246681A (en) * | 1985-01-30 | 1988-12-13 | Northern Telecom Limited | Terminal address assignment in a broadcast transmission system |
DE3546662C3 (de) * | 1985-02-22 | 1997-04-03 | Bosch Gmbh Robert | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
JPS61232363A (ja) * | 1985-04-05 | 1986-10-16 | Honda Motor Co Ltd | 内燃エンジンの電子制御装置 |
US4745600A (en) * | 1985-07-09 | 1988-05-17 | Codex Corporation | Network collision detection and avoidance apparatus |
EP0208998A3 (de) * | 1985-07-19 | 1989-01-04 | Rodger T. Lovrenich | Dezentralisiertes Steuerungssystem und Verbindung dazu |
US4715031A (en) * | 1985-09-23 | 1987-12-22 | Ford Motor Company | Vehicular data transfer communication system |
CA1249886A (en) * | 1986-05-02 | 1989-02-07 | Claude J. Champagne | Method of duplex data transmission using a send-and- wait protocol |
US4769761A (en) * | 1986-10-09 | 1988-09-06 | International Business Machines Corporation | Apparatus and method for isolating and predicting errors in a local area network |
US4887076A (en) * | 1987-10-16 | 1989-12-12 | Digital Equipment Corporation | Computer interconnect coupler for clusters of data processing devices |
US5131081A (en) * | 1989-03-23 | 1992-07-14 | North American Philips Corp., Signetics Div. | System having a host independent input/output processor for controlling data transfer between a memory and a plurality of i/o controllers |
GB8915135D0 (en) * | 1989-06-30 | 1989-08-23 | Inmos Ltd | Message routing |
SE467437B (sv) * | 1990-11-07 | 1992-07-13 | Ericsson Telefon Ab L M | Foerfarande att undvika interferens mellan ett foersta och ett andra meddelande i ett mobiltelefonsystem |
ATE139400T1 (de) * | 1991-02-28 | 1996-06-15 | Rai Radiotelevisione Italiana | Verfahren zur nachrichtenübertragung über einen fernsehkanal mit dem teletextsystem |
-
1985
- 1985-02-22 DE DE3546662A patent/DE3546662C3/de not_active Expired - Lifetime
- 1985-02-22 DE DE19853506118 patent/DE3506118A1/de active Granted
- 1985-02-22 DE DE3546664A patent/DE3546664C3/de not_active Expired - Lifetime
- 1985-02-22 DE DE3546683A patent/DE3546683C3/de not_active Expired - Lifetime
- 1985-12-02 FR FR8517780A patent/FR2578070B1/fr not_active Expired - Lifetime
-
1986
- 1986-02-17 JP JP61031033A patent/JP2545508B2/ja not_active Expired - Lifetime
- 1986-02-20 US US06/831,475 patent/US5001642A/en not_active Expired - Lifetime
-
1992
- 1992-03-23 US US07/856,430 patent/US5303348A/en not_active Expired - Lifetime
-
1993
- 1993-12-01 JP JP5302049A patent/JPH0721784B2/ja not_active Expired - Lifetime
- 1993-12-01 JP JP5302048A patent/JPH0772883B2/ja not_active Expired - Lifetime
-
1994
- 1994-01-24 US US08/185,024 patent/US5640511A/en not_active Expired - Lifetime
-
1995
- 1995-06-05 US US08/464,383 patent/US5621888A/en not_active Expired - Lifetime
- 1995-06-05 US US08/465,059 patent/US5901156A/en not_active Expired - Lifetime
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10027845B4 (de) * | 1999-06-22 | 2008-01-10 | Ford Motor Company, Dearborn | Submodul für die Kontrolle einer Datenwarteschlange |
Also Published As
Publication number | Publication date |
---|---|
JPH06236328A (ja) | 1994-08-23 |
US5001642A (en) | 1991-03-19 |
FR2578070B1 (fr) | 1994-05-06 |
FR2578070A1 (fr) | 1986-08-29 |
DE3506118A1 (de) | 1986-08-28 |
DE3546662C3 (de) | 1997-04-03 |
DE3546664C2 (en) | 1991-03-07 |
JPH0772883B2 (ja) | 1995-08-02 |
US5901156A (en) | 1999-05-04 |
US5303348A (en) | 1994-04-12 |
JP2545508B2 (ja) | 1996-10-23 |
JPH06236333A (ja) | 1994-08-23 |
JPH0721784B2 (ja) | 1995-03-08 |
US5640511A (en) | 1997-06-17 |
DE3546662C2 (en) | 1991-03-07 |
US5621888A (en) | 1997-04-15 |
JPS61195453A (ja) | 1986-08-29 |
DE3546683C2 (en) | 1991-03-07 |
DE3506118C2 (de) | 1991-01-03 |
DE3546683C3 (de) | 2003-10-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE3546664C3 (de) | Verfahren zum Betreiben einer Datenverarbeitungsanlage | |
EP1298849B1 (de) | Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem | |
DE3204905C2 (de) | ||
DE3043894C2 (de) | ||
EP0772832B1 (de) | Arbitrierung bei verzögernder buskopplung | |
DE3850097T2 (de) | Rechnerverbinder für gruppen von datenverarbeitungseinrichtungen. | |
DE3317567C2 (de) | Rechnergesteuertes Zeitmultiplex-System | |
EP2283616B1 (de) | Kommunikationssystem mit einem can-bus und verfahren zum betreiben eines solchen kommunikationssystems | |
DE69432841T2 (de) | Verfahren und Vorrichtung für digitale Datenübertragung in einem Nachrichtennetz | |
DE3855590T2 (de) | Bitorganisiertes Nachrichtennetzwerk | |
DE3882192T2 (de) | Schnittstelleanordnung für die Verbindung zwischen einerseits getrennten Stationen und andererseits einem für den Nachrichtenverkehr zwischen diesen Stationen benutzten physikalischen Mittel. | |
DE4129205A1 (de) | Verfahren zum aufbau von botschaften fuer den datenaustausch und/oder fuer die synchronisation von prozessen in datenverarbeitungsanlagen | |
EP2434695A1 (de) | Serielle ringförmige Kommunikationsanordnung und dementsprechendes Verfahren, wobei für die Übermittlung von einem Datenpaket von jedem Slave eine Adressinformation des Datenpakets geändert wird | |
EP0144403A1 (de) | Verfahren und anordnung zum übertragen von informationen in einem datenring. | |
DE3546684C2 (en) | Operating communication bus network for processors | |
EP0150540B1 (de) | Verfahren zur Datenübertragung, sowie Station zur Durchführung des Verfahrens | |
WO1993001668A1 (de) | Verfahren zur informationsübertragung in einem mehrere teilnehmer aufweisenden bussystem | |
DE102018203680A1 (de) | Teilnehmerstation für ein serielles Bussystem und Verfahren zur Datenübertragung in einem seriellen Bussystem | |
DE3751882T2 (de) | Serieller Datenbus für Datenübertragung zwischen Modulen und Verfahren zur Datenarbitrierung und zur Kollisionsdetektion auf einem Datenbus | |
DE102006004191B4 (de) | Deterministisches Kommunikations-System | |
EP2538618A1 (de) | Verfahren zur Übertragung von Datenpaketen | |
WO2003036879A1 (de) | Teilnehmergerät für ein hochperformantes kommunikationssystem | |
DE69021626T2 (de) | Eingebettete Steuertechnik für verteilte Steuersysteme. | |
DE3856051T2 (de) | Relaisstation für periphere Geräte | |
EP1329057B1 (de) | Verfahren für den Zugriff aauf einen Datenbus zwischen kommunizierenden elektronischen einheiten |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
Q172 | Divided out of (supplement): |
Ref country code: DE Ref document number: 3506118 |
|
8110 | Request for examination paragraph 44 | ||
AC | Divided out of |
Ref country code: DE Ref document number: 3506118 Format of ref document f/p: P |
|
AC | Divided out of |
Ref country code: DE Ref document number: 3506118 Format of ref document f/p: P |
|
D2 | Grant after examination | ||
8363 | Opposition against the patent | ||
8366 | Restricted maintained after opposition proceedings | ||
8305 | Restricted maintenance of patent after opposition | ||
AC | Divided out of |
Ref country code: DE Ref document number: 3506118 Format of ref document f/p: P |
|
D4 | Patent maintained restricted |