DE3506118A1 - Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge - Google Patents
Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeugeInfo
- Publication number
- DE3506118A1 DE3506118A1 DE19853506118 DE3506118A DE3506118A1 DE 3506118 A1 DE3506118 A1 DE 3506118A1 DE 19853506118 DE19853506118 DE 19853506118 DE 3506118 A DE3506118 A DE 3506118A DE 3506118 A1 DE3506118 A1 DE 3506118A1
- Authority
- DE
- Germany
- Prior art keywords
- error
- message
- transmission
- messages
- bus
- 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.)
- Granted
Links
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/03—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for
- B60R16/0315—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for using multiplexing techniques
-
- F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
- F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
- F02D—CONTROLLING COMBUSTION ENGINES
- F02D41/00—Electrical control of supply of combustible mixture or its constituents
- F02D41/24—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means
- F02D41/26—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor
- F02D41/266—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor the computer being backed-up or assisted by another circuit, e.g. analogue
-
- F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
- F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
- F02P—IGNITION, OTHER THAN COMPRESSION IGNITION, FOR INTERNAL-COMBUSTION ENGINES; TESTING OF IGNITION TIMING IN COMPRESSION-IGNITION ENGINES
- F02P5/00—Advancing or retarding ignition; Control therefor
- F02P5/04—Advancing or retarding ignition; Control therefor automatically, as a function of the working conditions of the engine or vehicle or of the atmospheric conditions
- F02P5/145—Advancing or retarding ignition; Control therefor automatically, as a function of the working conditions of the engine or vehicle or of the atmospheric conditions using electrical means
- F02P5/15—Digital data processing
- F02P5/1502—Digital data processing using one central computing unit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0745—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an input/output transactions management context
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0763—Error or fault detection not based on redundancy by bit configuration check, e.g. of formats or tags
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
- G06F13/374—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control using a self-select method with individual priority code comparator
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0079—Formats for control data
- H04L1/0082—Formats for control data fields explicitly indicating existence of error in data being transmitted, e.g. so that downstream stations can avoid decoding erroneous packet; relays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40143—Bus networks involving priority mechanisms
- H04L12/40163—Bus networks involving priority mechanisms by assigning priority to messages according to a message field
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/407—Bus networks with decentralised control
- H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection (CSMA-CD)
- H04L12/4135—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection (CSMA-CD) using bit-wise arbitration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L25/00—Baseband systems
- H04L25/02—Details ; arrangements for supplying electrical power along data transmission lines
- H04L25/026—Arrangements for coupling transmitters, receivers or transceivers to transmission lines; Line drivers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L2001/0092—Error control systems characterised by the topology of the transmission link
- H04L2001/0094—Bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L25/00—Baseband systems
- H04L25/02—Details ; arrangements for supplying electrical power along data transmission lines
- H04L25/0264—Arrangements for coupling to transmission lines
- H04L25/0272—Arrangements for coupling to multiple lines, e.g. for differential transmission
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
- Y02T10/00—Road transport of goods or passengers
- Y02T10/10—Internal combustion engine [ICE] based vehicles
- Y02T10/40—Engine management systems
Description
1. Stand der Technik
In den letzten Jahren wurde die Funktion des Kraftfahrzeugs
durch elektronische Steuerungen wesentlich verbessert. Durch eine digitale Motorelektronik konnte z.B. der
Kraftstoffverbrauch reduziert und die Emmission von
Schadstoffen verringert werden. Mit dem Anti- Blockier-System
lassen sich die Bremswege bei Vollbremsung verkuerzem wobei gleichzeitig die Lenkbarkeit des Fahrzeugs erhalten bleibt.
Weitere Funktionsverbesserungen sind fuer das Kraftfahrzeug in
Zukunft insbesondere dadurch zu erreichen» dass die Steuerfunktionen nicht mehr einzeln fuer sich allein arbeiten»
sondern untereinander vermascht werden. Die Schaltvorgaenye
eines elektronisch gesteuerten Automatik- Getriebes lassen sich z.B. mit geringerem Verschleiss der Kupplungsbelaege und ohne
spuerbaren Ruck durchfuehren» wenn im Schaltaugenblick das
Motormoment durch einen entsprechenden Eingriff in die elektronische Motorsteuerung kurzzeitig reduziert wird.
Dazu ist es erforderlich» dass der Rechner fuer die
elektronische Getriebesteuerung genau im richtigen Zeitpunkt entsprechende Daten an den Rechner fuer die elektronische
Motorsteuerung uebertraegt.Bislang wurde dies mit Hilfe einer
Reihe von einzelnen Signal leitungen erreicht.
Die Anzahl derartiger Signal Ieitungen wird jedoch bei
umfangreicheren Systemen zu gross. Man benoetigt deshalb in
diesem Fall eine schnelle Datenuebertragung zwischen den im Kraftfahrzeug installierten Rechnern» die wenig Anschluess im
Steuergeraete - Stecker benoetigt und bei der die Information in codierter Form uebertragen wird.
Zu diesem Zwecke wurden in der Vergangenheit lokale Netzwerke
zur Kopplung von Mikroprozessoren» Minirechnern und Peripheriegeraeten in Steuerungen» insbesondere jedoch in
nachrichtentechnischen Anwendungen entwickelt. So gibt es als
Stand der Technik eine grosse Zahl verschiedener UebertragungsprotokolIe fuer die Kopplung von Mikrorechnern wie
z.B. DDB Cl5» HC C2D» MUART C3D» CSMA C4D» SDLC C43 und HDLC
C4:.
C13 VALVO» DDB specification
C23 VALVO» Technische Informationen fuer die
Industrie 811215
Industrie 811215
C33 INTEL» Microprocessor and Peripheral Handbook» 1983
C4D A. Tannenbaum» Computer Networks»
Prentice/Hal I International» 1981
'Vi- 'Il " ■' ·
2. Nachteile des Stands der Technik
In den oben genannten Protokollen sind die Anforderungen einer
Steuergeraete - Kopplung im Kraftfahrzeug nur ungenuegend
beruecksi cht igt.
2.1 Waehrend in der Nachrichten- und Rechnertechnik
insbesondere groessere Datenpakete uebertragen werden»
sind die typischen Laengen der Datenpakete im Kraftfahrzeug klein. Im Auto werden zwischen
Steuergeraeten ι Sensoren und Stellern vorzugsweise
Messwerte» Zwischenergebnisse von Rechenalgorithmen und
Signale zur zeitlichen Synchronisation ausgetausc'r. t. Die
Entwicklung eines fuer diese Anwendungen geeigneten üebertragungsprotokolIs fuehrt zwangslaeufig zu anderen
Ergebn i ssen.
2.2 Die Steuerungen im Auto arbeiten unter Echtzeitbedingungen» d.h. die Rechenoperationen und
Steuereingriffe muessen in bestimmten Zeitfenstern
erfolgen? schritthaltend mit den Prozessen. Fuer das
lokale Netzwerk ergibt sich daraus die Forderung» dass die Uebertragungsleitung nach einer kurzen Latenzzeit (typisch
200 Mikrosekunden) fuer wichtige Botschaften frei sein
muss» um zulange Verzoegerungen zu vermeiden.
Beim genormten Ethernet - Protokoll dauert demgegenueber
allein die Uebertragung einer einzigen Botschaft mindestens 580 Mikrosekunden» trotz der· hohen
Uebertragungsrate von 10 MHz. Erst nach dieser Zeit ist der Bus zur Uebertragung weiterer Botschaften frei.
Beginnen dann mehrere Busteilnehmer gleichzeitig mit der
Uebertragung» so kommt es zu einer Kollision mehrerer Botschaften auf dem Netzwerk. Der Zugriffskonflikt wird
geloest» indem sich zunaechst alle Sender zurueckziehen
und erst nach einer statistischen Wartezeit erneut mit der
Uebertragung beginnen. Durch diese Massnahmen sind jedoch auch wiederholte Buszugriffskonflikte nicht
auszuschliessen. Dadurch wird das zuverlaessige Einhalten
von harten Zeitbedingungen» wie bei Kraftfahrzeug
Steuerungen erforderlich» unmoeglich.
Steuerungen erforderlich» unmoeglich.
2.3 Kraftfahrzeuge werden je nach Wunsch des Kaeufers mit
einem unterschiedlichen Ausstattungsumfang ausgeruestet .
Die Konfiguration eines lokalen Netzwerkes und die Zahl
seiner teilnehmer muss deshalb auf einfache Weise aenderbar sein. Insbesondere ist es wichtig» dass die
bereits am Netzwerk angeschlossenen Rechner mit unveraendertem Programm arbeiten koennen» wenn sich an der
von ihnen realisierten Funktion nichts aendert. Das Uebertragungssystem muss so konzipiert sein» dass ueber
die bestehenden» funktionalen Verknuepfungen zwischen
"" Ja ~"
Steuergeraeten hinaus keine weiteren? durch das
Busprotokoll bedingten Abhaengigkeiten eingefuehrt werden
muessen. Diese Forderung ist bei keinem der bekannten
Schnittstellen - Bausteinen erfuellt.
Z.B. werden bei DDB in jeder Botschaft die Sender- und Empfaenger- Adressen angegeben. Kommx ein weiterer
Netzwerk - Teinehmer hinzu? der auch bereits auf dem Bus
uebertragene Daten benoetigt? so muss in entsprechenden? bereits vorhandenen Teilnehmern die neue Adresse ergaenzt
werden. Zusaetzlich muessen die bereits zu anderen Teilnehmern uebertragenen Daten nochmals auch zu den neuen
gesendet werden. Obwoh von der logischen Struktur nicht erfordertichi erhaelt man eine grosse Vielzahl von
Programmνarianten.
2.4 Viele bekannte Netzwerke (z.B. auf Basis Intel Mikroprozessor 8044? HDLC/SDLC - Protokoll) arbeiten nach
dem sogenannten Master / Slave - Prinzip? dh. nur einer der Teinehmer (der Master) hat zu einem Zeitpunkt die
Berechtigung zum Buszugriff. Damit umgeht man die sonst erforderliche Arbitrierung.
Im allgemeinen wird die Master - Eigenschaft nacheinander an alle Bus - Teilnehmer weitergegeben. Bei Automobil
Anwendungen ist ein derartiges Verfahren aber nachteilig. Ein Teilnehmer kann naemlich nur dann senden? wenn er gerade im Besitz der Sendeberechtigung ist. Dadurch koennen ggf. nicht tolerierbar lange Wartezeiten in den Slaves entstehen» bis eine Botschaft hoher Prioritaet uebertragen wird.
Anwendungen ist ein derartiges Verfahren aber nachteilig. Ein Teilnehmer kann naemlich nur dann senden? wenn er gerade im Besitz der Sendeberechtigung ist. Dadurch koennen ggf. nicht tolerierbar lange Wartezeiten in den Slaves entstehen» bis eine Botschaft hoher Prioritaet uebertragen wird.
2.5 Unguenstig ist das Master / Slave - Konzept auch bei elektromagnetischen Stoerungen? mit denen im Kraftfahrzeug
bekanntlich gerechnet werden muss. Dabei kann z.B. die Sendeberechtigung durch eine Stoerung verloren gehen oder
irrtuemlicherweise ein weiterer Teilnehmer gleichzeitig
eine Sendeberechtigung erlangen.
Die Bewaeltigung solcher Stoerfaelle ist zwar im Prinzip
moeglich? erfordert aber viel Zeit (BusausfalIzeit?CPU
Rechenzeit) und Aufwand (Hardware/Sofware)j was im Hinblick auf die Echtzeit - Anforderungen der Steuergeraete nicht zugebilligt werden kann.
Rechenzeit) und Aufwand (Hardware/Sofware)j was im Hinblick auf die Echtzeit - Anforderungen der Steuergeraete nicht zugebilligt werden kann.
2.6 Ein Problem bei vielen bekannten Netzwerken ist die Synchronisation von Ereignissen. Sollen z.B. durch
Uebertragungh einer Botschaft in zwei oder mehreren Teilnehmern gleichzeitig Aktionen ausgeloest werden? so
muss die Botschaft von allen im genau gleichen Augenblick empfangen werden. Bei der sonst ueblichen? zeitlich
aufeinanderfolgenden Uebertragung von Botschaften zu den
einzelnen Empfaengern (Punkt zu Punkt - Verbindung) ist
die Gleichzeitigkeit des Empfangs einer gueltigen
Botschaft prinzipiell nicht zu erreichen.
2.7 In Kfz - Netzwerken sind haeufig gleiche Botschaften an
verschiedene Empfaenger zu senden. Der gleichzeitige
Empfang durch alle angesprochenen Teilnehmer- wuerde in diesen Faellen die Belegung des Netzwerkes betraechtIich
reduzieren. Dieses Vorgehen wird aber von den bekannten Schnittstellen - Bausteinen nicht unterstuetzt.
2.8 Netzwerke im Kraftfahrzeug arbeiten in einer
ausserordentIich stark gestoerten Umgebung. Zur
Reduzierung der unerkannten Uefoertragungsfehler ist
deshalb eine leistungsfaehige Fehlererkennung erfordert ich j so dass im Bedarfsfall eine Uebertragung
wiederholt werden kann. Einfache Algorithmen wie die zusaetzliche Uebertragung von Quersummen - Bits erkennen
nur Einzelfehler und sind nicht ausreichend bei den im
Auto vorhersehenden BuescheIstoerungen.
Selbst die aufwendigeren der heute bekannten Protokolle
sind nicht in der Lage? ohne zusaetzliche Absicherungsprogramme auf Benutzerebene (z.B. Mehrfach
-Uebertragung) eine ausreichende Uebertragungssicherheit
im Kraftfahrzeug zu gewaehrIe ist en. So kann beim HDLC
Protokoll bereits ein Einzelbit - Fehler zu einer nicht erkennbaren Verfae Ischung der Botschaft fuehren? obwohl
diese durch einen CRC-Check von 16 Bit Laenge abgesichert wird.
2.9 Um eine Wiederholung im Fehlerfall veranlassen zu koennen?
muss der Sender von allen Empfaengern eine Rueckmetdung
ueber den korrekten Empfang der Botschaft erhalten. In den Punkten 2.6 und 2.7 wurde dargelegt» dass es von
erheblichem Vorteil ist? die Botschaften gleichzeitig von mehreren Teinehmern empfangen zu koennen. Die
Rueckmeldungen duerfen nun aber nicht wie bei bekannten
Protokollen in einzelnen? aufeinaderfolgenden Botschaften
oder Teilbotschaften erfolgen. Eine konsistente?
gleichzeitige Behandlung dsr Daten durch die
angesprochenen Bus - Teilnehmer ist in diesem Falle nicht zu gewaehrleisten.
2.10 Stoerungen in Kfz werden haeufig nur lokal wirksam. Aufgrund der endlichen Ausbreitungsgeschwindigkeit
elektromagnetischer Wellen kann es z.B. vorkommen» dass
nur ein Teil der Empfaenger in einem bestimmten Zeitintervall verfaelschte Pegel auf dem Bus abtastet. Bei
gleichzeitigem Empfang einer Botschaft durch mehrere
Teilnehmer koennte es also vorkommen? dass ein Teil der Empfaenger gueltige? der andere Teil verfaelschte
Botschaften empfaengt. Dies darf nicht dazu fuehren? dass
·λ>·; j j IU" ο:::·
in einem solchen Fehlerfall bereits einige Teilnehmer die Botschaft bearbeiten und damit ein synchrones Vorgehen
aller Bus _ Teilnehmer nicht mehr zustande kommt.
2.11 Die am lokalen Netzwerk angeschlossenen Teilnehmer muessen entscheiden» ob sie eine gerade uebertragene Botschaft
empfangen wollen oder nicht. Aufgrund der starken Auslastung der Rechner durch Echtzeit - Aufgaben muss
diese Entscheidung unbedingt per Hardware erfolgen. Bisher bekannte Schnittstellen - Bausteine fuer Mikrocomputer
treffen diese Auswahlentscheidung nur an Hand der eigenen
Teilnehmeradresse. Neben den bereits in Punkt 2.6 und 2.7
aufgefuehrten Nachteilen eines sochen Vorgehens wird der
Rechner darueberhinaus stark mit dem Einordnen und inhaltsabhaengigen Abspeichern der Botschaften belastet.
Die Rechner werden erst dann wirksam entlastet? wenn der Schnittstellen - Baustein empfangene Daten gleich
inhaltsabhaengig in den zugeordneten Speicherzellen ablegt.
2.12 Zur Kodierung der im Kfz zu uebertragenden Daten wird
abhaengig von der Anwendung eine unterschiedliche Anzahl
von Bits verwendet. Unabhaengig von der Laenge der Daten
muss jedoch sichergestellt werden» dass diese vom Schnittstellen - Baustein und vom angeschlossenen Rechner
immer konsistent bearbeitet werden. Erfolgt z.B. die inhaltsbezogene Abspeicherung der Daten in mehreren
Schritten» je nach Laenge der Daten» so ist sicherzustellen» dass bei zeilticher Ueberlagerung von
Rechnerzugriff und Uebertragung nicht alte und neu» Daten
derselben Bedeutung (Kennung) unzulaessigerweise vermischt
werden.
Es werde z.B. eine Drehzahl in zwei Bytes codiert uebertragen und vom Schnittstellen - Baustein in zwei
Speicherzellen abgelegt. Es darf dabei nicht passieren» dass der Rechner unerkannt das erste Byte der letzten und
das zweite Byte der aktuellen uebertragung ausliest und zu einer ungueltigen Drehzahl - Information zusammensetzt.
2.13 An ein lokales Netzwerk sind viele Sende- und Empfangsschaltungen angeschlossen. Die
AusfalIwahrscheinIichkeit des Netzwerkes steigt
bekanntlich mit der Anzahl dieser Schaltungen. Es muss deshalb verhindert werden» dass bereits der Ausfall eines
einzelnen Teilnehmers das gesamte Netzwerk blockiert.
2.14 Die galvanische Kopplung mehrerer» raeumlich verteilter Steuergeraete fuehrt haeufig zu einer Beeintraechtigung
deren Funktion» z.B. durch Ausgleichsstroeme .
Das UebertragungsprotokolI fuer ein lokales Netzwerk im
Kfz muss so gestaltet sein» dass nicht nur mit teuren
Lichtleitern» sondern auch bei Verwendung von
Kupfer Ieitern eine galvanische Entkopplung realisiert
werden kann.
2,15 In Kfz - Anwendungen muessen sowohl schnell als auch
langsam sich veraendernde Daten uebertragen werden. Um zu verhindern? dass der Informationsgehalt der schnell
veraenderlichen Daten nicht mehr aktuell ist» wenn sie
empfangen werden) muessen diese bevorzugt vor den anderen uebertragen werden. Deshalb muessen Buszugriffe? die
Bearbeitung der Uebertragungsanforderungen im Sender und
die Abarbeitung der empfangenen Daten nach Prioritaeten geordnet erfolgen. Die Prioritaeten sind den einzelnen
Botschaften individuell zuzuordnen.
Ist z.B. die Anforderung zur Uebertragung der
Motortemperatur bereits erfolgt? die Uebertragung selbst aber noch nicht geschehen? so muss dennoch die vorrangige
Bearbeitung des nachtraeglich zur Uebertragung angemeldeten? hoeher prioren Lastsignals sichergestellt
werden. Bei bekannten Schnittstellen kann die
Bearbeitungsfolge nur vom Rechner per Programm festgelegt
werden. Diese Vorgehensweise ist bei Mikrorechnern? die
fuer Echtzeit - Aufgaben im Kfz eingesetzt werden? nicht moeglich? da die Rechenzeitbelastung aufgrund der hohen
Rate zu uebertragender Botschaften unertraeglich waere.
3. Vorteile der Erfindung
Das erfindungsgemaesse Verfahren mit den Merkmalen des
Hauptanspruchs 1 hat gegenueber dem beschriebenen Stand der
Technik den Vorteil? dass eine schnelle und sichere Datenuebertragung zwischen den im Kraftfahrzeug installierten
Rechnern mit den besonderen Anforderungen einer Steuergeraete Kopplung
im Kraftfahrzeug moeglich ist.
Dies wird dadurch erreicht? dass die zu uebertragenden Botschaften sich bezueglich ihres Inhalts und ihrer Bedeutung
mit Hilfe eines Identifizierers selbst identifizieren.
Besonders vorteilhaft ist es dabei? dem Identifizierer
gleichzeitig eine Prioritaet zuzuordnen? wobei der identifizierer dann vorzugsweise am Anfang der zu
uebertragenden Botschaft steht.
Eine weitere vorteilhafte Weiterbildung besteht darin^ dass der
Identifizierer Inhalte wie Adressen? Daten? Sensorsignale?
■ η-
St el Igroessen» Zwischenergebnisse» Befehle fuer
Synchronisationen» Befehle zum Ausloesen von Aktionen»
Drehzahl» Drehzahlgradienten» Motortemperatur» Last der Antriebsmaschine» Befehlsdaten wie z.B. von einer
Anti-Blockiei—Einrichtung oder einer Antischlupfeinrichtung»
usw. kennzeichnet.
Weitere vorteilhafte Weiterbildungen und Verbesserungen des im
Hauptanspruch 1 angegebenen Verfahrens ergeben sich aus den Unteranspruechen» sowie aus der Zeichnung und der zugehoerigen
Beschre ibung.
Das erfindungsgemaesse Verfahren mit den Merkmalen des
Hauptanspruchs 7 hat gegenueber dem beschriebenen Stand der Technik den Vorteil» dass eine schnelle und sichere
Datenuebertragung zwischen den im Kraftfahrzeug installierten
Rechnern mit den besonderen Anforderungen einer Steuergeraete Kopplung
im Kraftfahrzeug moeglich ist.
Dies wird dadurch erreicht» dass die zu uebertragende Botschaft mit einem definierten Bitmuster anfaengt» dieses Bitmuster in
eine Fehlererkennung einbezogen wird und auf das Kontrollwort der Fehlererkennung ein Bitmuster folgt» das zum
Anfangsbitmuster komplementaer ist.
Besonders vorteilhaft ist es dabei» das Kontrollwort der Fehlererkennung durch die Multiplikation eines Senerator
Polynoms mit dem Restklassenpolynom (X + 1) zu erzeugen.
Polynoms mit dem Restklassenpolynom (X + 1) zu erzeugen.
Weitere vorteilhafte Weiterbildungen und Verbesserungen des im
Hauptanspruch 7 angegebenen Verfahrens ergeben sich aus den
unteranspruechen» sowie aus der Zeichnung und der zugehoerigen Beschreibung.
Das erfindungsgemaesse Verfahren mit den Merkmalen des
Hauptanspruchs 9 hat gegenueber dem beschriebenen Stand der
Technik den Vorteil» dass eine schnelle und sichere Datenuebertragung zwischen den im Kraftfahrzeug installierten
Rechnern mit den besonderen Anforderungen einer Steuergeraete Kopplung
im Kraftfahrzeug moeglich ist.
Dies wird dadurch erreicht» dass auf der die wenigstens zwei Rechner verbindenden Leitung dominante und rezessive Zustaende
uebertragen werden und dass eine Fehlermeldung aus einer
einzigen» mit der bei der Uebertragung der Botschaft auftretenden Zustandsfolge nicht zu verwechselnden
Zustandsfolge dominanter Zustaende besteht.
■ te-: · : ■ /■■;■...:
Besonders vorteilhaft ist es dabei» dass die Fehlermeldung zu
jedem beliebigen Zeitpunkt und von jedem Teilnehmen der mit der Leitung gekoppelt ist) abgegeben werden kann. Weiter
besteht ein Vorteil darin» dass das Ende der Fehlermeldung» bzw. das Ende der letzten Fehlermeldung zur zeitlichen
Synchronisation aller Teilnehmer verwendet wird.
Weitere vorteilhafte Weiterbildungen und Verbesserungen des im
Hauptanspruch 9 angegebenen Verfahrens ergeben sich aus den ünteranspruechen» sowie aus der Zeichnung und der zugehoerigen
Beschre ibung.
Das erf indungsgemaesse Verfahren mit den Merkmalen dies Hauptanspruchs 16 hat gegenueber dem beschriebenen Stand der
Technik den Vorteil» dlass eine schnelle und sichere Datenuebertragung zwischen den im Kraftfahrzeug installierten
Rechnern mit den besonderen Anforderungen einer Steuergeraete Kopplung
im Kraftfahrzeug moeglich ist.
Dies wird dadurch erreicht» dass jeder Teilnehmer alle Botschaften empfaengt» jedoch nur die fuer ihn relevante
Botschaft weiterverarbeitet» wobei die relevanten Botschaften
bei jedem Teilnehmer mit Hilfe einer Liste mit den empfangenen Botschaften in Beziehung gebracht werden,
Besonders vorteilhaft ist es dabei» dass die Reihenfolge der Liste fuer die interne Weiterverarbeitung im Teilnehmer
prioritaet-bestimmend ist. Ein weiterer Vorteil besteht darin»
dass die in den Botschaften enthaltenen Informationen in
Abhaengigkeit in der jedem Teilnehmer vorliegenden Liste in
Speicherzellen uebertragbar sind und dem Teilnehmer zur Weiterverarbeitung zur Verfuegung stehen.
Weitere vorteilhafte Weiterbildungen und Verbesserungen des im
Hauptanspruch 16 angegebenen Verfahrens ergeben sich aus den Unteranspruechen» sowie aus der Zeichnung und der zugehoerigen
Beschreibung.
Das erfindungsgemaesse Verfahren mit den Merkmalen des
Hauptanspruchs 25 hat gegenueber dem beschriebenen Stand der
Technik den Vorteil» dass eine schnelle und sichere Datenuebertragung zwischen den im Kraftfahrzeug installierten
Rechnern mit den besonderen Anforderungen einer Steuergeraetε Kopplung
moeglich ist.
Dies wird dadurch erreicht» dass jeder Teilnehmer den zu uebertragenden Botschaften mittels einer Liste eine Prioritaet
zuordnet und in jedem Zeitpunkt die Liste die Prioritaet der im Teilnehmer zur Uebertragung bereitstehenden Botschaften
-/- 3'5'ΟΒ 118
best immt.
Besonders vorteilhaft ist es dabei» dass der Liste weitere
Informationen insbesondere bezueglich des
Uebertragungszustandes und bezueglich
Uebertragungsanforderungen zugeordnet sind. Weiter ist es
vorteilhaft) fehlerbehaftete Uebertragungen zu erfassen und zu
registrieren und die Uebertragung bei aufgetretenen Fehlern zu
wiederholen.
Bei einer weiteren vorteilhaften Weiterbildung handelt es sich
darum» dass jedem Teilnehmer ein bestimmter maximaler Teil der
Uebertragungskapazitaet der Leitung zugeordnet wird. Eine weitere vorteilhafte Moeglichkeit besteht darin» dass nach dem
Auftreten einer bestimmten Anzahl von Fehlermeldungen eines
bestimmten Teilnehmers sich dieser Teilnehmer sendesignalmaessig von der Leitung abkoppelt.
Weitere vorteilhafte Weiterbildungen und Verbesserungen des im
Hauptanspruch 25 angegebenen Verfahrens ergeben sich aus den
Unteranspruechen sowie aus der Zeichnung und der zugehoerigen
Beschre ibung.
Das erfindungsgemaesse Verfahren mit den Merkmalen des
Hauptanspruchs 33 hat- gegenueber dem beschriebenen Stand der
Technik den Vorteil» dass eine schnelle und sichere Datenuebertragung zwischen den im Kraftfahrzeug installierten
Rechnern mit den besonderen Anforderungen einer Steuergeraete Kopplung
im Kraftfahrzeug moeglich ist.
Dies wird dadurch erreicht» dass bei dem erfindungsgemaassen
Verfahren zur Uebertragung von zweiwertigen Informationen der
eine Informationswert durch einen konstanten Signalpegel» der
andere Informationswert mit alternierenden Signalpegeln
uebertragen wird.
Besonders vorteilhaft ist es dabei» die alternierenden
Signalpegel gleichzeitig zur Fehlererkennung heranzuziehen.
Weitere vorteilhafte Weiterbildungen und Verbesserungen des im
Hauptanspruch 33 angegebenen Verfahrens ergeben sich aus den
Unteranspruechen» sowie aus der Zeichnung und der zugehoerigen
Beschre ibung.
4. Ausfuehrungsbeispiel
4.1. Auflistung der einzelnen Figuren der Zeichnung
Fig. Is Ausfuehrungsbeispiel fuer lineare Busstruktur
Fig. 2! Beispiel fuer galvanisch gekoppelte)
asymmetrische Ansteuerung der Busleitung
Fig. 3; Beispiel fuer galvanisch gekoppelte»
symmetrische Ansteuerung der Busleitung
Fig. 4: Beispiel fuer galvanisch getrennte»
symmetrische Ansteuerung mit Uebertrager
Fig. 5! AusfuehrungsbeispieI fuer Lichtleiter - Stern
Fig. 6: AusfuehrungsbeispieI fuer Lichtleiter - Bus
Fig. 7: Aufbau einer Botschaft
Fig. 8: Aufbau CONTROL-FIELD
Fig. 9: Aufbau CRC-FIELD
Fig. 10: Aufbau einer Fehlermeldung
Fig. Ils Blockschaltbild des Schnittstellen-Bausteins
4.2. Physikalische Realisierung
Tabelle 1 zeigt die moeglichen Bustopologienι Ankopplungs- und
Leitungsarten in Abhaengigkeit von dem gewaehlten
Uebertragungsmedium.
| Uebertragungs- medium |
I | I Bustopologie Iinearer Bus Stern |
Ankopplung | I Leitungsart I |
| Elektr. Leiter | linearer Bus Stern mit zentr. Koppler! I |
galvanisch i ndukt iν Optokoppler |
Leitungspaar i verdrilltes I Le i tungspaarI Koaxialkabel I I |
|
| Licht leiter | elektro- opt ische Wandler |
Glasfasern I Kunsstoff- I fasern I I I |
Uebertragungsart '· Zugriffsart s
raeumliche Ausdehnung! von Uebertragungsrate abhaengig
Zei tmult iplex Basisbanduebertragung
MuIt i mast ei—Prinzip
deterministische Buszuteilung
Das vorgestellte Bussystem kann genau dann realisiert werden?
wenn auf dem Uebertragungsmedium zwei Zustaende mit den
Eigenschaften dominant bzw. rezessiv moeglich sind.
•ft·
- ySt -
Beispiele hierfuer sind!
I Parallel- I
I Impedanz I Energie
Und-Satter I
I I
dominant I niederohmig I vorhanden
I I
rezessiv I hochohmig i nicht vorh.
0
1
1
Beispiele fuer Impedanz:
Schalter geschlossen / offen Transistor leitend / nichtleitend
Beispiele fuer Energie :
Spannung Licht
Ii egt an an
/ Ii egt η i cht an
/ aus
/ aus
Fig. 1 zeigt die Ausfuehrung als lineares Bussystem. Das.System
besteht aus einer durchgehenden Busleitung (Adernpaar oder Lichtleiter) und Anschlussleitungen» die zu den einzelnen
Teilnehmern gehen.
Fig. 2 zeigt eine die Busleitung.
Ausfuehrung mit Die Treiber
galvanischer Ankopplung an sind steuerbare Schalter»
realisiert durch Transistoren (Open-Collector-Ankopplung). Als
Busleitung dient ein ZweidrahtIeitung oder ein Koaxkabel. Die
Ansteuerung erfolgt asymmetrisch. Am Ende der Busleitung wird
ueber Widerstaende eine Versorgungsspannung angelegt. Der dominante Buszustand liegt dann vor? wenn mindestens ein
Treibertransistor leitet.
Fig. 3 zeigt eine Ausfuehrung» bei der als Sendetreiber zwei komplementaere Treibertransistoren eingesetzt werden? die
gleichzeitig leitend bzw. sperrend gesteuert werden. Die Leitung wird dadurch symmetrisch angesteuert. Der Vorteil
dieser Anordnung liegt in einer hoeheren Stoerfestigkeit und in
einer niedrigeren Stoerabstrahlung.
-ti-
Bei den oben gezeigten Ausfuehrungen ist die Busleitung
galvanisch mit den einzelnen Stationen verbunden. Dadurch koennen in elektrisch bzw. in elektromagnetisch gestoerter
Umgebung Probleme auftreten» wenn die Stationen ueber weitere Leitungen (z.B. Stromversorgungen) verkoppelt sind. Die
folgenden Beispiele weisen diesen Nachteil nicht auf.
Fig. 4 zeigt eine Ausfuehrung? bei der zur galvanischen
Trennung Uebertrager eingesetzt werden. Die Gleichstromfreiheit
wird durch eine Biphase-Kodierung gewonnen. Der rezessive Buszustand wird durch Abkopplung aller Uebertrager von ihren
Treibern erreicht (Treiber hochohmig schalten). Der dominante Buszustand wird durch das Aufschauten eines positiven oder
eines negativen Impulses auf mindestens einen der Uebertrager erreicht. Die Synchronisierung der Impulspolaritaet geschieht
ueber die Festlegung der Startbitpolaritaet.
Eine weitere Ausfuehrung mit galvanisch getrennter Ankopplung kann durch den Einsatz von Optokopplern erreicht werden.
Besonders einfach wird dies durch den Einsatz von Optokopplern mit Open-Col Iector-Ausgaengen .
Fig. 5 zeigt als Beispiel fuer eine Ausfuehrung mit Lichtleitern ein Sternsystem mit einem zentralen optischen
Koppler. Die Verkopplung kann passiv oder mit elektrooptischen
Wandlern ausgefuehrt werden.
Dominanter Buszustand: mindestens eine Sendediode leuchtet.
Rezessiver Buszustand: alle Sendedioden dunkel.
Rezessiver Buszustand: alle Sendedioden dunkel.
Fig. 6. zeigt als Beispiel fuer eine Ausfuehrung mit
Lichtleitern ein lineares Bussystem. Die Aschlussleitungen sind
mit der zentralen Busleitung so verbunden? dass zur Ein- und Auskopplung von Licht keine aufwendigen passiven oder
elektrooptischen Wandler benoetigt werden. Ein Beispiel ist die Verschmelzung von zentraler Busleitung und Anschlussleitung.
Dominanter Buszustand! mindestens eine Sendediode leuchtet.
Rezessiver Buszustand: alle Sendedioden dunkel.
Dominanter Buszustand! mindestens eine Sendediode leuchtet.
Rezessiver Buszustand: alle Sendedioden dunkel.
4.3. Uebertragungsprotokol I
Eine Botschaft besteht aus den Bitfeldern START-OF-FRAME>
IDENTIFIER) CONTROL-FIELD» DATA-FIELD) CRC-FIELD» ACK-FIELDj
END-OF-FRAME und INTERMISSION (siehe Fig. 6)
HINWEIS:
In dieser Beschreibung werden die
Begriffe HISH und LOW im Sinne
logischer Pegel verwendet.
Begriffe HISH und LOW im Sinne
logischer Pegel verwendet.
Waehrend HISH in seiner Wirkung
auf dem Bus rezessiv ist» ist LOW
dominant. Das hat zur Folge? dass
von allen Busteilnehmern LOW
empfangen wird? sofern mindestens
einer von mehreren Busteilnehmern
LOW sendet.
auf dem Bus rezessiv ist» ist LOW
dominant. Das hat zur Folge? dass
von allen Busteilnehmern LOW
empfangen wird? sofern mindestens
einer von mehreren Busteilnehmern
LOW sendet.
START-OF-FRAME
markiert den Botschaftsanfang und besteht aus einem
einzigen LOW Bit.
Ein Busteilnehmer darf nur im Zustand BUS-IDLE (siehe
Abschnitt 4.5)? d.h. wenn der Bus frei ist> die Uebertragung einer Botschaft beginnen. Alle Empfaenger
synchronisieren sich auf die fuehrendei durch
START-OF-FRAME verursachte Flanke .
IDENTIFIER
kennzeichnet den Inhalt des Datenfeldes (DATA-FIELD) im Sinne eines Namens und einer Prioritaet.
Der IDENTIFIER hat nicht zwangslaeufig die Bedeutung einer
Adresse? die einen einzigen Empfaenger aus einer Vielzahl
von BüsteiInehmern bestimmt. Ob eine korrekt empfangene
Botschaft von den Busteilnehmern weiter bearbeitet wird
oder nichts wird ausschliesslich 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 zischen einer Punkt zu Punkt - Uebertragung und der gleichzeitigen Ansprache einiger
oder aller Busteilnehmer.
Bei gleichzeitigem Buszugriff mehrerer Sender wird
waehrend der Arbitrierungsphase anhand der Prioritaet
bestimmt» welcher der Sender das Recht zur weiteren Uebertragung der Botschaft erhaelt (siehe Abschnitt 4.4.)
Im vorliegenden AusfuehrungsbeispieI ist der IDENTIFIER
acht Bit ianq.
< IFL = IDENTIFIER-FIELD-LENSTH = B )
CONTROL-FIELD
umfasst die Bitfelder REMOTE-TRANSMISSION-REQUESTj
DATA-BYTE-CODE und fuer zukuenftige Erweiterungen
reservierte Bits.
REMOTE-TRANSMISSION-REQUEST zeigt an» ob durch die entsprechende Botschaft Daten uebertragen oder angefordert
werden sollen.DATA-BYTE-CODE enthaelt Information ueber
die Laenge des Datenfeldes.
In dem vorliegenden Ausfuehrunqsbeispiel ist das
CONTROL-FIELD acht Bit lang.
(CFL = CONTROL-FIELD-LENGTH = 8)
(CFL = CONTROL-FIELD-LENGTH = 8)
DATA-FIELD
enthaelt die zu uebertragende Information? deren Bedeutung
durch den IDENTIFIER festgeleqt ist. Die Laenqe dieses
Feldes (DATA-BYTE-COUNT) ist variabel und kann "zB. eim
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 enthaelt das mittels eines Generator
Polynoms erzeugte Kontrollwort (CRC-SEQUENCE)ι es wird mit einem CRC-DELIMITER abgeschlossen (Fig. 9).
Polynoms erzeugte Kontrollwort (CRC-SEQUENCE)ι es wird mit einem CRC-DELIMITER abgeschlossen (Fig. 9).
Das Generator - Polynom ist fuer kleine Botschaftslaengen
(kleiner 120 zu sichernde Bits) ausgewaehlti womit eine hoehere Hamming - Distanz erreicht wird wie bei der
Absicherung langer Botschaften mit der gleichen Anzahl von KontrolIbifs.
In dem vorlieqenden Ausfuehrunqsbeispiel ist die
CRC-SEQUENCE 15 Bits lang.
(CRCL = CRC-SEQUENCE-LENGTH = 15)
Durch das Kontrollwort werden die Felder START-OF-FRAME»
IDENTIFIERi 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 schliesst das CRC-FIELD ab.
Zyklische Codes koennen solche Fehler nicht aufdecken? die
sich auf die zyklische Verschiebung des gesamten Codewortes (zu sichernde Bits und Sicherungsbits)
zurueckfuehren lassen. Eine zyklische Verschiebung ergibt
naemlich wieder ein gueltiges 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» dass das CRC-FIELD nicht mit HIGH abgeschlossen wird.
ACK-FIELD
Alle Empfaenger teilen dem Sender den Empfang einer korrekten Botschaft dadurch mit» dass sie als erstes Bit
in diesem Fenster ein LOW - Bit uebertragen. Als zweites Bit wird HIGH (ACK-DELIMITER) uebertragen. Der Sender kann
auf diese Art und Weise erkennen» ob zumindestens einer der Busteilnehmer die Botschaft fehlerfrei empfangen hat.
Alle diejenigen BusteiInehmer» die eine fehlerhafte
Botschaft empfanqen haben? melden dies mittels eines
ERROR-FLAG.
Erhaelt der Sender keine Bestaetigung fuer den korrekten Empfang seiner Botschaft durch zumindest einen Empfaenger»
so setzt er selbst eine Fehlermeldung ab.
END-OF-FRAME
besteht aus einer ununterbrochenen Folge von HIGH Bits und
steht am Ende einer jeden Botschaft.
Die Laenge von END-OF-FRAME ist so zu waehlen» dass all diejenigen Empfaenger» die aufgrund einer fehlerhaften
Übertragung der Laengeninformation an dieser Stelle Daten
- γι -
erwarten? bereits beim zweitletzten Bit von END-OF-FRAME
einen Stuffehler feststellen (siehe KODIERUNG). Unabhaengig von vorangegangenen Uebertragungsfehlern kann
so jeder Busteilnehmer das Ende einer Botschaft erkennen.
Tastet der Sender waehrend END-OF-FRAME zumindest ein LOW Bit (zB. Bit von ERROR-FLAG) auf dem Bus abj so w:rd dies
von dem zuletzt aktiven Sender als Reaktion auf die soeben von ihm uebertragene Botschaft angesehen. Dadurch besteht
eine eindeutige Zuordnung von Fehiermeldungenj auch wenn
der Fehlerzustand erst mit der Uebertragung des
zweitletzten Bits einer Botschaft durch einen der Empfaenger erkannt wird.
In dem vorliegenden Ausf uehrungsbe ispie I ist EN.'-OF-FRAME
s i e b.e η Bits lang.
(EOFL = END-OF-FRAME-LENGTH = 7)
INTERMISSION
besteht aus einer ununterbrochenen Folge von HIGH Bits. In
dieser Zeit darf keiner der Busteilnehmer die Uebertragung
einer neuen Botschaft beginnen.
Waehrend INTERMISSION hat jeder Empfaenger die Moeglichkeitj eine Ueberlastung (fehlende Empfangsbereitschaft)
durch Senden eines ERROR-FLAG zu melden? so dass das Absenden der naechsten Botschaft verzoegerl wird? bis
alle Empfaenger wieder bereit sind.
Eine in INTERMISSION fallende Fehlermeldung uird genauso
wie die in andere Bitfelder fallenden Fehlermeldungen
behandelt. Eine Wiederholung der vorangegangenen Botschaft durch den entsprechenden Sender erfolgt jedoch nicht.
In dem vorliegenden AusfuehrungsbeispieI ist INTERMISSION
drei Bit lanq.
(IML = INTERMISSION-LENGTH = 3)
BUS-IDLE
Der Bus ist frei? wenn er nach Ablauf von INTERMISSION
weiterhin HIGH - Pegel fuehrt. Der Zustand BUS-IDLE kann von beliebiqer Dauer sein. Der Empfanq 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 LOW-Bits.
Die Laenge der Folge ist so zu bestimmen» dass durch sie das Gesetz des "Bitstuffinq1 verletzt wird? das auf alle
Bitfelder von START-OF-FRAME bis CRC-DELIMITER angewendet
wird. Die anderen Busteilnehmer reagieren daraufj indem
sie selbst eine Fehlermeldung senden.
In dem vorliegenden Ausfuehrungsbeispiel 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.
Der Sendevorgang des ERROR-DELIMITER beginnt» nachdem auch alle anderen Teilnehmer mit der Uebertragung des
ERROR-FLAG fertig sind (LOW nach HIGH Uebergang auf dem Bus).
Im vorlieqenden Ausfuehrunqsbeispiel ist der
ERROR-DELIMITER sieben Bit lang.
(EDL = ERROR-DELIMITER-LENGTH = 7)
(EDL = ERROR-DELIMITER-LENGTH = 7)
4.4. Bus-Organisation
Die Organisation des Busverkehrs beruht auf folgenden fuenf Regeln:
(1) BUS-ZUGRIFF
Die Busteilnehmer duerfen nur im Zustand BUS-IDLE die
Uebertragung einer Botschaft starten.
2k-
Alle Empfaenger muessen auf START-OF-FRAME synchronisieren
die fuehrende Flanke von
(2) ARBITRIERUNG
Beginnen zwei oder mehr Busteilnehmer gleichzeitig mit der
Uebertragungj wird der Zugriffskonflikt durch einen
Arbitrierungsmechanismus auf Bitebene geloest.
Waehrend der Arbitrierung vergleicht jeder Sender den
Bitpegelϊ den er selbst auf den Bus schreibt» mit
demjenigen» den er tatsaechlich auf dem Bus abtastet. Alle diejenigen Sender» die nicht den von ihnen selbst
gesendeten Buspegel vorfinden» muessen die übertragung ohne auch nur ein weiteres Bit zu senden einstellen. Durch
diese Vereinbarung kann der Arbitrierungsvorgang ablaufen»
ohne dass irgendwelche Information auf dem Bus zerstoert wird. Derjenige Sender» dessen Botschaft den IDENTIFIER
mit der hoechsten Prioritaet aufweist» gewinnt den Buszugriff. Er uetaertraegt die begonnene Botschaft zu
Ende.
(3) KODIERUNG
Die Botschaftssegmente START-OF-FIELD» IDENTIFIER» CONTROL-FIELD» DATA-FIELD und CRC-FIELD werden nach der
liethode des Bitstuffing kodiert. Treten in dem zu uebertragenden Datenstrom in ununterbrochener Reihenfolge
fuenf gleiche Bits auf» so fuegt der Sender automatisch ein Bit mit umgekehrter Wertigkeit in den Bitstrom ein.
(A) DEKODIERUNG
Die Botschaftssegmente START-OF-FIELD» IDENTIFIER»
CONTROL-FIELD» DATÄ-FIELD und CRC-FIELD werden nach der
Methode des Bitstuffing kodiert. Empfaengt ein Bust εiInehmer fuenf gleiche Bitpegel in ununterbrochener
Reihenfolge» so entfernt dieser das nachfolgende Stuffbit aus dem Bitstrom. Die Wertigkeit des Stopfbits muss invers
zu der der voran gegangenen Bits sein (Fehlerpruefung).
(5) FEHLERMELDUNG
Jeder Bust eiInehmer» der einen Uebertragungsfehler
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? dh» beginnend mit dem au* den Fehlerzustand
folgenden Bit. Nur bei Erkennung eines CRC-Fehlers wird
die Fehlermeldung erst drei Takte spaeter abgeschickt.
Dadurch wird sichergestellt» dass das ACK-FIELD nicht
durch eine von einem CRC - Fehler ausgeloeste Fehlermeldung ueberschrieben wird.
Die Fehlermeldung wird durch einen Uebergang von LOW nach
HISH nach mindestens sechs LOW Bits auf dem Bus beendet (siehe Zustandsdiagramm zur Fehlerbehandlung)
(6) UEBERLAST
Bei Ueberlastung (empfangene Botschaft ist noch nicht bearbeitet) hat jeder Busteilnehmer die Moegl ichtkei11
durch Senden eines ERROR-FLAS waehrend INTERMISSION dies allen anderen Teilnehmern zu melden (siehe INTERMISSION).
4.5. Zustandsdiagramme
4.5.1. ErIaeuterungen zu den Zustandsgraphen
Jeder Rechteckrahmen stellt einen Systemzustand dar. Die
Uebergaenge zwischen den Zustaenden» die von Eingangs- und
Zustandsvariablen abhaengen» sind durch gerichtete
Verbindungslinien dargestellt. Die Zustandsuebergaenge erfolgen
stets mit der aktiven Flanke des Bustaktes. Mit der gleichen Taktflanke werden Ausgangsdaten auf die Busleitung gelegt. Der
tatsaechliche Buspegel wird erst kurz vor der naechsten aktiven
Bustaktf lanke abgetastet.
Nach einem BUS-IDLE Zustand wird der Bustakt auf den naechsten Buspegeluebergang von HIGH nach LOW synchronisiert.
Die Eingangs- und Zustandsvariablen koennen geordnet und zu
einem Entscheidungsvektor zusammengefasst werden.
- "4Λ -Der
Entscheidungsvektor hat folgende Forms
C BUS-MONITOR* BUS-DRIVEi STUFFj COUNT j
TX-REQUESTj CRC-ERRORi OVERLOAD )
Es bedeutet:
BUS-MONITOR
Eingangsvariable» die den auf der Busleitung abgetasteten
Logikpegel wiederspiegelt.
BUS-MONITOR = Q entspr. dominantem Buspegel (LOW)
BUS-MONITOR = 1 entspr. rezessivem Buspegel (HIGH)
BUS-MONITOR = 1 entspr. rezessivem Buspegel (HIGH)
BUS-DRIVE
Zustandsvariablei die den Logikpegel angibti der
Zustand gesendet wird.
Zustand gesendet wird.
in diesem
BUS-DRIVE = 0 BUS-DRIVE = 1
Sendepegel dominant (LOW) Sendepegel rezessiv (HISH)
STUFF
Eingangsvariab I ε j die angibti ob der Buspegel waehrend der
letzten fuenf Abtasttakte konstant war. (fuenfmal LOW oder fuenfmal HIGH ). Der Pegel ι den BUS-MONITOR angibti ist der
aktuellste Wert dieser Fuenferkette.
STUFF = STUFF =
Buspegel BuspegeI
hat gewechselt war konstant
COUNT
Zustandsvariable» die angibti ob der interne Zaehler (CNTR)
abgelaufen ist. Dieser Zaehler wird nicht in allen Zustaenden benoetigt. Falls benoetigti wird der Zaehler
beim Uebergang in den entsprechenden Zustand gesetzt.
- 22 -
COUNT COUNT
0 Zaehler
1 Zaehler
noch nicht atagelaufen ( abgelaufen < CNTR = O )
CNTR O O )
TX-REQUEST
Eingangsvariable» die angibt» ob eine Botschaft zum
Absenden bereit liegti so dass an der naechsten
Buszuteilungsprozedur teilgenommen werden muss.
TX-REQUEST = O TX-REQUEST = 1
Sendeauftrag liegt nicht
Sendeauftrag liegt vor
Sendeauftrag liegt vor
vor
CRC-ERROR
Zustandsvariable» die angibt) ob in der empfangenen
Botschaft ein Uebertragungsfehler vorlag« Die Variable wird
nach dem Empfang des letzten Bits der CRC-SEQUENCE gesetzt.
CRC-ERROR = 0 CRC-ERROR = 1
Empfang war fehlerfrei Uebertragungsfehler
OVERLOAD
Zustandsvariab Ie die angibt» ob die letzte empfangene
Botschaft von der SehnittsteIlenlogik aufgearbeitet werden
konnte oder ob diese ueberlastet ist.
OVERLOAD = 0 OVERLOAD = 1
Empfangslogik ueberlastet Empfangslogik bereit
Mit dem Entscheidungsvektor ist eindeutig festgelegt» in
welchen Folgezustand gegangen wird. Der Zustandsgraph kann
deshalb mit Hilfe der Entscheidungsvektoren beschrieben werden.
Ist fuer ein bestimmtes Element im Zustandsvektor ein 'x'
angegeben» so bedeutet dies» dass die entsprechende Variable
. ÄS ·
fuer die Entscheidung nicht relevant ist (die Variable darf Ό'
oder *1' se in) .
4.5.2. Beschreibungsbeispiel fuer den Zustand BUS-IDLE
Der Zustand BUS-IDLE ist der requlaere Folgezustand des
Zustands TEST-INTERMISSION. Im Zustand BUS-IDLE wird stets der rezessive Sendepegel HIGH auf die Busleitung gelegt.
Uebergaenge in Folgezustaendes
1) Entscheidungsvektor (111 il»χiOiχtχ):
Dieser Entscheidungsvektor bedeutet folgendesi
Buspegel HIGH» Sendepegel HIGHj Bus war schon mind. fuenf
Takte lang HIGHi Zaehler nicht retevantj keine
Sendeanforderungj Uebertragungsfehler und Ueberlastung nicht
relevant. Da keine Busaktion detektiert wurde und keine
Sendeanforderunq vorlaqr ist der Folgezustand wieder
BUS-IDLE.
2) Entscheidungsvektor Cl 11>i ι χ?1»χ ι χ):
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 Folqezustand ist also TRANSMIT-START-OF-FRAME.
3) Entscheidungsvektor (OiliOixinxix) :
Auf der Busleitung wurde der Pegel LOW detektiert ■>
das heisstj dass mindestens ein anderer Busteilnehmer begonnen
hat) eine Botschaft zu uebertraqen. Das detektierte LÖW-Bit
ist START-OF-FRAME. Der Folgezustand ist RECEIVE-IDENTIFIER.
4) Alle weiteren Entscheidungsvektoren deuten auf eine
Hardware-Stoerung bzw. auf einen Hardware-Ausfall innerhalb
des Schnittstellenbausteins hin.
Entsprechendes gilt fuer alle anderen Systemzustaende>
die in
den Zustandsgraphen EMPFANGSMODUS) SENDEMODUS und FEHLER-BEHANDLUNG beschrieben werden.
Neben den Entscheidungsvektoren? die sich aufgrund von
Stoerungen auf der Busleitung ergeben) werden nur die Vektoren
aufgefuehrt? die bei funktionsfaehiger Hardware auftreten
koennen. Die restlichen Vektoren kann man entweder zur Vereinfachung des Steuerwerks ausnuetzten oder zur Erhoehung
der Systemsicherheit in einem Zustand HARDWARE-ERROR behandeln.
vom Zustand TEST-INTERMISSION
ν I
C1 j 1 j 11 χ j 0 j x ? χ) I
Zustand:
BUS-IDLE
■ _— wa __ ·» «_ ■» w- ·— all· ■-· ··«· a
I ν
(1f1f1)χil! χ ι x)
zum Zustand SEND-START-OF-FRAME
zum Zustand
RECEIVE-IDENTIFIER
RECEIVE-IDENTIFIER
4.5.3. Zustandsdiagramm EMPFANGS-MODUS
Aus dem Zustand BUS-IDLE kommt man durch Erkennen von START-OF-FRAME auf dem Bus in den Zustand RECEIVE-IDENTIFIER.
Beim Zustandsueberqang wird der Zaehler CNTR mit IFL=S
(IDENTIFIER-FIELD-LENGTH) vorbelegt. IFL gibt an wieviel
Kennungsbits vereinbart wurden (siehe 4.3» IDENTIFIER).
Mit jedem empfangegen Kennungsbit wird die Schleife des
Zustands RECEIVE-IDENTIFIER einmal durchlaufen und der Zaehler wird dekrementiert. Tritt im IDENTIFIER ein Stuffbit auf» so
erfolgt aufgrund von STUFF = 1 der Uebergang in den Zustand
IGNORE-ID-STUFFB . Dort wird das Stuffbit ausgeblendet. Ist
danach immernoch STUFF = 1 * so muss eine Ausnahmesituation
vorliegen (Stoerung 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 Ruecksprung in den Zustand RECEIVE-IDENTIFIER erfolgen.
Nach Ablaufen des Zaehlers qeht das System (entweder aus dem
Zustand RECEIVE-IDENTIFIER oder IGNORE-ID-STUFFB) in den
Zustand RECEIVE-CONTROL-FIELD ueber. Hier wird der Zaehler mit
CFL=S (CONTROL- FIELD-LENGTH) vorbsleqt.
Sind alle Bits des CONTROL-FIELDs empfanqen* so wird als
naechstes in Zustand RECEIVE-DATA-FIELD das Datenfeld
empfangen. Als Besonderheit gilt hier» dass der Zaehler nicht mit einer Konstanten* sondern mit der Variablen DFL
(DATA-FIELD-LENGTH) vorbelegt wird. DFL kann die Werte 8? 16?
32 oder 64 annehmen.
Als naechstes wird im Zustand RECEIVE-CRC-SEQUENCE das
CRC-KontrolIwort (CRC-SESUENCE) empfangen. Hierzu wird
zunaechst der Zaehler CNTR mit CRCL=15 CCRC-SEQUENCE-LENSTH)
vorbelegt. Nach dem Empfang des letzten CRC-Bits wird die Zustandsvariable CRC-ERROR gesetzt (CRC-ERROR = Q bedeutet kein
Fehlen CRC-ERROR = 1 bedeutet Fehler im Uebertragungsrahmen).
Das CRC-Kontrollwort muss stets durch ein Bit (CRC-DELIMITER)
mit dem Pegel HIGH abgeschlossen sein. Dies wird im Zustand RECEIVE-CRC-DELIMITER geprueft. Bei falschem Buspegel wird zum
Zustand ERROR-HANDLING gesprungen.
Im naechsten Bustaktzyklus muessen die Empfaengsr den Empfang
der Botschaft bestaetigen. Dies geschieht im Zustand SEND-ACKNOWLEDGE durch Senden eines LOW-Pegels fuer
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
uebergegangen.
Auf das erste Acknowledge-Bit folgt der ACK-DELIMITER* der
stets den Pegel HIGH haben muss. Dieser Pegel wird im Zustand SEND-ACK-DELIMITER von allen Empfaengern ausgegeben. Wird der
Pegel LOW empfangen* so wird zum Zustand ERROR-HANDLING uebergegangen.
Beim Zustandsueberganq nach RECEIVE-END-OF-FRAME wird der
Zaehler CNTR mit E0FL=7 (END-OF-FRAME-LENGTH) initialisiert.
Falls CRC-ERROR = 1 ist» oder falls waehrend
3λ
RECEIVE-END-OF-FRAME der Buspegel LOW empfangen wirdi wird zum
Zustand ERROR-HANDLING uebergegangen.
Im fehlerfreien Fall wurde die Botschaft jetzt vollstaendig empfangen. Als naechstes folgt der Zustand TEST-INTERMISSIOhh
der aus IML=3 (INTERMSSION-LENGTH) Zyklen besteht. Der
Buspegel muss dauernd HIGH seim sonst wird nach ERROR-HANDLING
gesprungen. Im Zustand TEST-INTERMISSION hat jeder Empfaenger
die Moeglichkeit eine Ueberlastung (OVERLOAD = 1) zu melden»
sodass das Absenden der naechsten Botschaft verzoegert wird»
bis der Empfaenger wieder bereit ist. Auch dies geschieht durch ERROR-HANDLING. Nach Ablauf das Zaehlers CNTr" wird in den
Folgezustand BUS-IDLE uebergegangen> mit dem ein neuer
Empfangs- oder Sendezyklus beginnt.
Bezueglich der Stuffbitsj die in den Feldern CONTROL-FIELD ι
DATA-FIELD und CRC-SEQUENCE auftreten koennen» gelten die zum
Zustand RECEIVE-IDENTIFIER gemachten Ausfuehrungen entsprechend.
Empfangs-Modus
Entscheidungsvektor: (Bus-Monitor, Bus-Drive, Stuff,' Count, TX-Request,
CRC-Error, Overload)
f. 1 +
jzustand: i (1,1,1»x»1,x,x) d.h. Sendeanforderung
tßus-Idle ί -ί zum~Züs"-EäSar"TRJairSMIT-START-OF-
+ j ♦ FRAME
(CNTR:=CNTR-1) ' (0,1 ,0,X,x,x,x)
! I I (CNTR:=IFL)
+ { i-A?-* 1,1,x,x,x,x) +
[Zustand: { >" +Zustand:
+Zustand: | (χ,1,1,χ,χ,χ,χ)
, , „ ·, RECEIVE- ι , »IGNORE-ID- f >
(χ, 1,0,0, χ, {IDMIIEIEB * +ST.UEE£.f J
χ,χ) ι (χ,Ι,Ο,Ο,χ,χ,χ) ι
(x,1,0,1,χ,χ,χ)
(CNTR:=CNTR-1)
(CNTR:=CNTR-1)
.}(χ,1,0,1,χ,χ,χ) J
i(CNTR:=CFL)
V V ( TC 1 1 V V V χ)
y β
j Zustand: { > {Zustand: |χ,χ) \
t+
(χ, 1,0,0, χ ,x ,Jj
)
; (1
)
; (1
+RECEIVE-
ι (χ,Ι,Ο,Ο,χ,χ,χ)
-CF-
RE-CF- ί
ΕΕ+._ J
♦-
(CNTR:=DFL) γ (χ,1,1,χ,χ,χ,χ)
ν(χ,1,0,1,χ,χ,χ) »
t 1
!I Il Il !1 Il
!I !I
!I
Zustand:
j-* RECEIVE-DATA-j <
ι
(χ,1,0,0,χ,χ,χ) y (χ,Ι,Ο,Ο,χ,χ,χ)
ι Zustand: • τπ.τ\τητ)ΐρ_ρι
Ix,1,1
jC.x) ^
y(x,1,0,1,χ,χ,χ)
Il I
ϋ ι ι \Χ,ι,ι,χ,χ,χ,χ^
"I j Zustand: + ♦ > jZustand: άχ>
]' 1 'χ'χ'
:jx,x) , . I (χ,Ι,Ο,Ο,χ,χ,χ) I
<\ (χ,1 ,0,1 ,χ,χ,χ) ι ι (χ,1 ,0,1 ,χ,χ,χ)
!Zustand:
j (0,1,χ,χ,χ,χ,χ)
ι RECEIVE-CRC-
(1 ,1 ,χ,χ,χ,χ,χ)
I1
!Zustan [
ι) ι ι-
d:
SEND-
(1,Ο,χ,χ,χ,χ,χ)
{(O5O,Ο,χ,χ,χ,χ)
*(0,1,0,χ,χ,χ,χ) {(1,1,X5X5X5X,χ)
!Zustand: · (θ,1,Ο,χ,χ,χ,χ)
iSEND-i
ITYFTY
(CNTR:=CNTR-1)
(1,1,χ,χ,χ,χ,χ)
(CNTR:=EOFL)
(0,1 ,Ο,χ,χ,χ,χ)
+'Züi'tändT* ί (1 ,1 ,χ,χ,χ, 1 ,x) d.h. CRC-Fehler
! } RECEIVE-END- J. >,
(1,1,X5O5X5OJOF-FRA^E . '
') * ι*
von Zustand
TRMT -.MIT-END-OF-FRAME
ι
TRMT -.MIT-END-OF-FRAME
ι
ν
!
!Zustand: ι
tERROR-HANDLING-ι
[(s.ges.^eschr. ){
(CNTRi=CNTR-I)
(1,1,X5O5X5X5
0)
0)
ν ν
I I
ι Zustand:
-+ TEST-INTER- ψ-j
MISSION ,, !}
(C TR:=IML.)
(0,1 ,χ,χ, χ, χ,χ) JT
(χ,1,χ,χ,χ,χ,Ι) d.h. Empfänger
überlastet
(1,15χ,1,χ,χ,Ο)
4.5.4. Zustandsdiagramm SENDE-MODUS
Vom Zustand BUS-IDLE aus erfolgt der Uebergang in den
Sendemodus dann* wenn vor oder waehrend BUS-IDLE eine
Sendeanforderung eintrifft (TX-REQUEST = 1). Siehe hierzu
Zustandsgraph RECEIVE-MODE.
Das Senden einer Botschaft beginnt mit dem Zustand TRANSMIT-START-OF-FRAMEj
in dem der dominante Sendepegel LOW ausgegeben wird. Falls eine Stoerung den dominanten Pegel LOW in HIGH
verfaelschtj wird zum Zustand ERROR-HANDLINS uebergegangen.
Sonst folgt im Zustand TRANSMIT-IDENTIFIER die Buszuteilungsprozedur. Am Anfang wird der Zaehler auf IFL=S
CIDENTIFIER-FIELD-LENGTH) gesetzt.
Im Zustand TRANSMIT-IDENTIFIER wird verblieben (lediglich der Zaehler wird dekrementiert)ι wenn der empfangene Pegel dem
gesendeten entspricht und die letzten fuenf Buspegel nicht
konstant waren und der Zaehler noch nicht abgelaufen ist.
Der Zustand TRANSMIT-IDENTIFIER wird verlassen? wenn
der gesendete rezessive HIGH-Pegel durch LOW ueberschrieben
wurde. Die Buszuteilunq ist damit verloren.
Falls STUFF = 1 ist ι ist der Folgezustand I5N0RE-ID-STUFFB.
Sonst ist bei nicht abgelaufenem Zaehler der Folgezustand
RECEIVE-IDENTIFIERj " bei abgelaufenem Zaehler REtEIVE-CONTROL-FIELD.
— ein qesendeter dominanter LOW-Pegel in HIGH verfaelscht
wird. Der Folgezustand ist ERROR-HANDLING.
der empfangene Pegel dem gesendeten entspricht. Falls die letzten fuenf Pegel gleich waren muss in den Zustand
INSERT-ID-STUFFB uebergegangen werden. Sonst wird bei
abgelaufenem Zaehler in den Folgezustand TRANSMIT-CONTROL-FIELD uebergegangen. Im letzten Fall wurde
die Buszuteilung gewonnen.
Im Zustand INSERT-ID-STUFFB werden die Stuffbits des
IDENTIFIER-FIELDS eingefuegt. Da in diesem Zustand die Buszuteilung nicht verloren werden kannj ist im Falle von
unterschiedlichen Sende- und Empfangs- Pegeln ERROR-HANDLING
der Folgezustand. Ansonsten wird bei nicht abgelaufenem Zaehler in den" Zustand TRANSMIT-IDENTIFIER zurüeckgegangenj bei
abqelaufenen Zaehler wurde die Bussuteilunq qewonnem der
Foigezustand ist TRANSMIT-CONTROL-FIELD.
Beim Einstieg in den Zustand TRANSMIT-CONTROL-FIELD wird der
Zaehler CNTR mit CFL=S initialisiert (CONTROL-FIELD-LENGTH). Da
die Buszuteilung beendet ist? muss ab jetzt der Sende- und
Empfangs-Pegel stets gleich sein. Ist dies nicht der Falls so wird in den Zustand ERROR-HANDLING uebergegangen. Bei nicht
abgelaufenem Zaehler und bei Flankenwechsel innerhalb der letzten fuenf Taktzyklen bleibt das System im Zustand
TRANSMIT-CONTROL-FIELDj lediglich der Zaehler wird dekrementiert. Das Einfuegen von Stuffbits geschieht im Zustand
INSERT-CF-STUFFB. Bei abgelaufenem Zaehler erfolgt der Uebergang in den Folgezustand TRANSMIT-DATA-FIELD.
Die Vorgaenge im Zustand TRANSMIT-CONTROL-FIELD gelten auch
fuer " die Zustaende TRANSMIT-DATA-FIELD und TRANSMIT-CRC-SEQUENCE. Beim Einstieg in TRANSMIT-DATA-FIELD
wird der Zaehler 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 Zaehler mit der
Konstanten CRCL=IS CCRC-FIELD-LENGTH) vorbelegt.
Im Anschluss an die CRC-SEQUENCE muss der CRC-DELIMITER
uebertraqen werden. Dies geschieht im Zustand TRANSMIT1CRC-DELIMITEr. Falls der gesendete HIGH-Zustand nach
LOW verfaelscht wird? wird in den Zustand ERROR-HANDLING uebergegangen.
Als naechstes wird das Acknowledge-Bit geprueft. Ein
empfangener HIGH-Pegel bedeutet? dass kein Teilnehmer die
Botschaft fehlerfrei empfangen hat oder dass alle Teilnehmer eine falsche Rahmensynchronisation haben. Der Sender gibt
deshalb im Zustand ERROR-HANDLING eine Fehlermeldung. Bei
empfangenem LOW-Peqel wird in den Folqezustand RECEIVE-ACK-DELIMITER "uebergegangen. Der ACK-DELIMlfER muss
stets HIGH sein. Ist dies nicht der Fall? so wird nach ERROR-HANDLING gesprungen.
Das Botschaftsende wird im Zustand TRANSMIT-END-OF-FRAME
uebertragen. Da END-OF-FRAME aus sieben HIGH-BHs besteht? wird der Zaehler CNTR mit E0FL=7 (END-0F-FRAME-LEN6TH) vorbelegt.
Bei empfanqenem HIGH-Peqel bleibt das System im Zustand
TRANSMIT-END-OF-FRAME? bis der Zaehler abgelaufen ist und geht
dann zu TEST-INTERMISSION ueber. Bei empfangenem LOW-Pegel wird dagegen nach ERROR-HANDLING gesprungen.
Mit dem Uebergang in den Zustand TEST-INTERMISSION ist der
TRANSMIT-MODE~beendet. Der Zustand TEST-INTERMISSION ist mit
dem im RECEIVE-MODE beschriebenen identisch.
SENDE-MODUS
Entscheidungsvektor:
Entscheidungsvektor:
(BUS-MONITOR, BUS-DRIVE, STUFF. CRC-ERROR, OUEREOAD)
COUNT, TX-Request,
Eustand:
(TRANSMIT-STARS
«-OF-FRAME j ι (1,Ο,χ,χ,χ,χ,χ)
(CNTR:=CNTR-1)
——————T
(θ,Ο,Ο,χ,χ,χ,χ)
(CNTR:=IFL)
_ _4I
(1,1,0,0,x,x,x) j Zustand:
IGNORE-ID-STUFFB
(0,1
(0,1
REC-IDENT. (100?)
(0,1,0Λ ,1,χ,χ,χ)
(0,1,0Λ ,1,χ,χ,χ)
transmit-
IDENTIFIER
REC.-CONTR.-FIELD
(tor)(i,1,0,1,x,x,x)
(0,0,0,1,χ,χ,χ)
(CNTR:=CNTR-1) -fr
η n η
it
it η
-CT
(0,0,1,χ,χ,χ,χ)
(1,1,1,χ,χ,χ,χ)
(1,1,1,χ,χ,χ,χ)
(1,0,1,χ,χ,χ,χ
(051,1,x5x5x5x
-ί ί
> +Zustand:
!insert-id- j >
< +STUFFB ι1
Tt
+ } (1,1,0,0,χ,χ,χ) j
(0,0,O5O,χ,χ,χ) I (i,1,0,1,x,x,x)
+ J
ο—<- I (1,1,0,1,χ,χ,)
j (Ο,Ο,Ο,Ι,χ,χ,χ)
(O,O,O,O,χ,χ,χ)
(1,1,0,0,χ,χ,χ)
(1,1,0,0,χ,χ,χ)
ι —+
ν '
' Zustand:
(CNTR:=CFL) (0,1,χ,χ,χ,χ,χ)
(1 ,1,x ,χ,χ,χ,χ)
(1 ,1,x ,χ,χ,χ,χ)
TRAESMIT- * CONTROL-
{(0,0,1,χ,χ,χ,χ)
{ FIELD iINSERT-CF-
.·———-.—-Ν—
(1,1,0,1,χ,χ,χ)
(Ο,Ο,Ο,Ι,χ,χ,χ)
(CNTR:=CNTR-1)
♦·—— _____ t
T
ν I (1,1,0,0,χ,χ,χ)
(O,O5O,O,χ,χ,χ)
(O,O5O,O,χ,χ,χ)
ι (1
+ (0
,1,0, ,0,0,
1,χ,χ,χ) 1 ,χ,χ,χ)
(CNTR:=DFL) (0,1,χ,χ,χ,χ,χ)
(1,Ο,χ,χ,χ,χ,χ)
(1,Ο,χ,χ,χ,χ,χ)
ι Zustand:
(1,1,0,0,χ,χ,χ)ι DATA-FIELD
(1,1,0,1,χ,χ,χ)
(Ο,Ο,Ο,Ι,χ,χ,χ)
ί ι INSERT-DF- t >
{ < 1 STUFFB ι
-t i + +
(1,1,O,O,χ,χ,χ) I (1,1,0,1,χ,χ,χ)
(Ο,Ο,Ο,Ο,χ,χ,χ) ί (O,O5O,1,χ,χ,χ)
(Ο,Ο,Ο,Ο,χ,χ,χ)
(1,1,Ο,Ο,χ,χ,χ)
(CNTR^CNTR-J) j (CNTR:=CRCL)
J ι (0,1,χ,χ,χ,χ,χ)
]_ ] + (1,0,χ,χ,χ,χ,χ)
Zustand: tTn"n "·ί""γ""γ~γ"~Τ"
TRANSMIT- |ll'.l'J_'.x.'.
CRC-SEQUENCEi j INSERT-CRC-
,0,1,x,x,x,x)
•i-l·j ' ,X,X,X,X/
(1,1,0,1,χ,χ,χ) j (1,1,0,0,χ,χ,χ) i (1,1,0,1,χ,χ,χ) „
1 (0,0,0,1,χ,χ,χ) j (Ο,Ο,Ο,Ο,χ,χ,χ) j (O,O,0,1,χ,χ,χ) I
{ZustäadT { (0,1,χ,χ,χ,χ,χ)
ι (1,1,χ,χ,χ,χ,χ)
•RECEIVE- ί (1>Τ>χ>χ>χ>χ>χ)
. γ(O,1,0,χ,χ,χ,χ)
ι
ιZustanu: ι (θ,1,Ο,χ,χ,χ,χ)
j TEST-ACK- I >
ι DELIMITER r
H f l·
(CNTR:=CNTR-1)
ι (1,1 ,Ο,χ,χ,χ,χ)
(CNTR:=EDFL)
(1,1,χ,O,χ,χ,χ)
1__. _J.e-_e III.. ['
!Zustand: κ
-+TRANSMIT-END-I-
ιOF-FRAME r
zum Zustand
TEST-INTERMISSION
TEST-INTERMISSION
(1,1,x,1,χ,χ,χ)
zum Zustand
ERROR-HANDLING
ERROR-HANDLING
~r 3505118
4.5.5. Zustandsdiaqramm FEHLERBEHANDLUNG
Die Fehlerbehandlung beginnt mit dem Zustand SEND-ERROR-FLAG.
Das ERROR-FLAG dient dazui allen Teilnehmern mitzuteilen) dass
auf dem Bus ein Uebertragungsfehler stattgefunden hat oder dass
ein Empfaenger ueberlaftet ist. Das ERROR-FLAG besteht aus
sechs aufeinanderfolgenden LOW-Bitsi deshalb wird der Zaehler
CNTR beim Einstieg in SEND-ERROR-FLAG auf EFL=6 (ERROR-FLAG-LENGTH) gesetzt. Falls eine Stoerung die gesendeten
dominanten Pegel LOW nach HIGH verfaelschti wird noch einmal
mit ERROR-HÄNDLING begonnen. Sonst wird der Zaehler dekrement i ert. Beim Zaehlerstand Null erfolqt der Ueberqancf 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» dass der Buspegel nach HIGH geht.
Die Fehlerbehandlung wird durch das Senden des ERROR-DELIMITERs
im Zustand SEND-ERROR-DELIMITER abgeschlossen. Beim Einstieg
wird der Zaehler CNTR mit EDL-1=6 (ERROR-DELIMITER-LENGTH = 7)
vorbelegt. Der ERROR-DELIMITER besteht aus sieben HIGH-BUs5
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 Zaehlers zum Zustand TEST-INTERMISSION weitergegangen. Damit
ist die Fehlerbehandlung beendet.
4.6. Fehlerbehandlung
4.6.1. Fehlereaktion
Jeder Teilnehmer sendet sofort nach einem erkannten Fehlen dh.
beginnend mit dem auf den Fehlersustand folgenden Bit» seine
Fehlermeldung (ERROR-FLAG). Nur bei Erkennung eines CRC-Fehlers wird die Fehlermeldung erst drei Takte spaeter abgeschickt.
Dadurch wird sichergestellt» dass das ACK-FIELD nicht durch
eine von einem CRC - Fehler ausgeloeste Fehlermeldung ueberschrieben wird. Durch das Freihalten des ACK-FIELD kann
ein Sender sowohl eine Bestaetigung seiner Botschaft von einigen Empfaengern erhalten als auch eine Fehlermeldung von
den restlichen Empfaengern. Dies bietet die Moeglichkeit ι im
Wiederholungsfall mit hoher Wahrscheinlichkeit festzustellen»
ob der Ausfall beim Teilnehmer (Sender) selbst oder bei einem Empfaenger liegt.
Eine Fehlermeldung besteht aus mindestens sechs aufeinanderfolgenden LOW Bits (ERROR-FLAG). Nach dsm
anschliessenden LOW - HIGH Ueberqanq musssen noch mindestens 10
HIGH Bits abgewartet werden (ERRÖR-DELIMITER un INTERMISSION).
4.6.2. Fehlerauftreten
Die Fehlerbehandlung kann sowohl von ihrem raeumlichen als auch
ihrem seitlichen Auftreten abhaengen.
Unter 4.6.5. werden einige Beispiele von Fehlerreaktionen dss
Open-Kollektor Busses gezeigt.
Aus der folgenden Tabelle 4.6.2 koennen alle moeglichen EinzeIbit-FehlerfaeI Ie entnommen werden.
Unter den angegebenen Nummern sind die hier unter 4.6.5. aufgefuehrten Beispiele fuer Fehlerfaelle zu finden.
/Sh -
Tabelle 4.6.2
| I I zeit- I raeum- Ii chesI Ii ches Auf treten I |
I am !Sender I und lallen Em !pfaeng. |
I am I Sender lund Ie i nem ITeH der IEmpfaeng |
I am I Sender lund kein IEmpfaen- I ger I |
4.6.5.2. | I I I |
I | 4.6.5.5.I | I nicht lam Sender I aber lallen Em Ipfaengern |
I nicht I lam Senderl I aber I I Te iI der I IEmpf aeng. I I · |
| BUS-IDLE | I I I 14.6.5.4. I I |
I 4.6.5.7.1 | |||||||
| START-OF-FRAME | I I I I I |
4.6.5.3. | |||||||
| IDENTIFIER | 4.6.5.1. | I I I I |
|||||||
| CONTROL-FIELD (DATA-BYTE- COUNT) |
4.6.5.6. | 1 1 |
|||||||
| DATA-FIELD | 4.6.5.S.I | ||||||||
| CRC-FIELD CRC-DELIMI7ER |
I I I I I I |
||||||||
| ACK-SLOT I I |
I I I I I I |
||||||||
| END-OF-BLOCK I | I I J I I I |
t | |||||||
| INTERMISSION I | I I I |
||||||||
• U
4.6.3. Fehlerklassen
Auf Grund der in 4.3 beschriebenen Festlegung des Busprotokolls
und der in 4.4 spe2ifζierten Bus-Organisation koennen folgende
Fehlerklassen auftreten!
Senders BF Bitfehler* Buspegel stimmt nicht mit
gesendetem Pegel ueberein.
gesendetem Pegel ueberein.
BK Im Zustand TRANSMIT-IDENTIFIER
(Arbitrierung) und TRANSMIT-START-OF-FRAME
gilt nur Buspegel HIGH bei
gesendetem LOW Bit als Fehler
gesendetem LOW Bit als Fehler
AF kein Acknowledge waehrend
RECEIVE-ACKNOWLEDGE
RECEIVE-ACKNOWLEDGE
NF Waehrend des Zustands TEST-INTERMISSION
ein LOW Bit auf dem Bus
ein LOW Bit auf dem Bus
SF Verletzung der StuffVorschrift
Empf aenger!
CF CRC-Fehler
DF die CRC-SEÖUENCE ist nicht mit einem
CRC-DELIMITER abqeschlossen? d.h. auf das
CRC-Kontrollwort folgt kein HIGH Bit
NF Waehrend der Zustaende RECEIVE-END-OF-FRAME
und TEST-INTERMISSION ist ein LOW Bit auf dem Bus.
SF Verletzung der Stuffvorschrift
BF Bitfehler im Zustand TRANSMIT-ACK
BF Bitfehler im Zustand TRANSMIT-ACK
In der nachfolgenden Tabelle 4.6.3 sind alle Fehlererkennungsmoeglichkeiten
zusammengestellt? die sich aus den Kombinationen
aus zeitlichem und raeumlichem Auftreten sowie der Fehlerklassen ergeben. Angegeben sind die zum Zeitpunkt des
Fehlers erkennbaren Fehlerkiassen.
Die Abkuerzungen in der charakterisieren die am
in der unteren Reihe Fehlerklassen.
oberen Zeile jedes Feldes der Matrix Sender auftretenden Fehlerklassenι die
die an den Empfaengern auftretenden
Tabelle 4.6.3
I I am I am I !Sender !Sender
seit- Iraeum-lund lund
IicheslIicheslallen Emleinem
I am In icht !Sender lam Sender
lund keinlaber IEmpfaen-lallen Em-
Auftreten Ipfaeng. ITeil derlfaenger Ipfaenger
I I lEmpfaengl
BUS-IDLE
ni cht am Sender aber
Teil der Empfaeng.
IBK
BK
START-OF-FRAME
-+-
I
I
I
I
IDENTIFIER
IBKjSF
ISF
IBKjSF
ISF
BKjSF
SF
IBFjSF IBFjSF CONTROL-FIELD! ! (DATA-BYTE- ISF ISF
IBFjSF
ί SF
ISF
| COUNT) | I | IAF | j SF | I | SF | I | SF | I | I |
| 1BF | I | IBFj | IBFj | I | I | ||||
| DATA-FIELD | I | IBF | I | I | I | I | |||
| ISF | IBF | j SF | ISF i |
SF | I | SF | ISF | ISF | |
| IBF | I | IBFj | IBFj | I | I | ||||
| CRC-SE«SUENCE | I | INF | j DF | I | DFj | I | I | I | |
| CRC-DELIMITERICF | IBF | j SF | SFICFj * |
SF | SFI | SF | ICFj f |
CDjSF ICFjCDjSF ■ |
|
| I | IAFj | IAFj | I | I | |||||
| ACK-SLOT | !NF ■+— |
j SF | I | SF | I | I | I | ||
| j NF | IBFj t |
NF | I | NF | IBFj t |
SF IBFjSF • |
|||
| IBFj | I | I | |||||||
| END-OF-BLOCK | I | I | I | ||||||
| j NF | INF ■ |
NF | NF | INF | INF | ||||
| IBFj | I | I | |||||||
| INTERMISSION | I | 1 | I | ||||||
| INF | INF | INF | |||||||
| IBFj | |||||||||
| BFj | |||||||||
| h | |||||||||
• kk-
~"~
350611 a
4.6.4. Erlaeuterungen zu den Beispielen
In den Bildern werden folgende Abkuerzungen verwendet!
- δ Stoerung
- ungestoerte Botschaft
- *** eigenes Eingreifen
- ### fremdes Eingreifen
- S Stuffbit
- 1..8. Nummerierung
- R Busruhe (Zustand BUS-IDLE) erkannt
- B Bitfehler waehrend einer Uebertragung
erkannt
- F Fehler von einem Teilnehmer erkannt
- Z Beginn einer Fehlermeldung
- K Teilnehmer hat Arbitrierung verloren
und bricht seine Uebertragung ab
Modellparameter der folgenden Fehlerbehandlungsbeisiele:
- 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 aufeinanderfolqenden LOW Bits
(EFL = 6)
mit Sender wird ein Teilnehmer bezeichnet der entweder schon sendet oder in dem ein
Sendewunsch vorliegt
• ks-
4.6.5. Beispiele Einzelbitfehler
4.6.5.1. Globale Stoerunq» von allen Teilnehmern entdeckbar.
Bitfehler im IDENTIFIER
I I I I I I
I I 111 I
123456789R K12345FZ23456123456789R
Sl I I III I
I I III I
I I III I
I I III I
123456789R 12345FZ23456123456789R
El 1 I III I
ι ι ill ι
ι ι ι ι ι ι
ι ι ill ι
123456789R 12345FZ23456123456789R
E2 I I III I
—a ****** — —
ι ι iii ι
Der Sender 'verliert1 die Arbitrierung und erkennt dann» wie
die Empfaenger einen Stuffehler. Nach der Fehlermeldung und
ansehtiessender Busruhe (Zustand BUS-IDLE) kann mit neuen
Uebertragungen oder der Wiederholung der gestoerten Nachricht begonnen werden.
• k<o-
I i III I
I I III I
123456789R K12345FZ23456123456789R
I I III I
I I ill I
I I III I
I I III I
123456789R BZ23456 123456789R
I I III I
I I III I
I I III I
I I III I
123456789R 12345FZ23456123456789R
El I I III I
I I III I
I I III I
I I III I
123456789R 12345FZ23456123456789R
E2 I I II! I
I I III I
Die Stoerung erzeugt am Sender2 einen Bitfehler» und er setzt
seine Fehlermeldung ab. Dadurch kommt es bei den Empfaengern zu
einem Stuffehler und am Senderl entweder zu einem Bitfehler und
/ oder einem Stuffehler. Nach dem letzten LOW Bit der Fehlermeldung und anschliessender Busruhe (Zustand BUS-IDLE)
kann mit neuen Uebertragungen oder der Wiederholung der
gestoerten Nachrichten begonnen werden.
, la.
■ #2 -
4.6.5,2. Fehler tritt an einem Teil Sender bzw. an Station mit Stuffehler im DATA-FIELD.
der Empfaenger und
Sendewunsch auf.
Sendewunsch auf.
am
123456789R
I I
! I
I I
123456789R
I I
I I
I I
I I
123456789R
I I
I i
BZ23456
123456789R
ι ι ι
123456789R
12345FZ23456
III I
III I
III I
III I
•12345S12345FZ23456123456789R
I I I
I I I
I I I
Der Sender erkennt einen Bitfehler und die gestoerten
Empfaenger erkennen pinen Stuffehler und setzen eine Fehlermeldung ab. Dadurch entsteht an den nicht gestoerten
Empfaengern ein Stuffehler und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzen LOW Bit der Fehlermeldung und
anschliessender Busruhe (Zustand BUS-IDLE) kann mit neuen
Uebertragungen oder der Wiederholung der gestoerten Nachricht
begonnen werden.
- ty.
4.6.5.3. Fehler tritt an einem Teil der Empfaenger und am
Sender bzw. an Station mit Sendewunsch auf. Bitfehler im ACK-SLOT
ACK I I I I ! FZ23456 123456789R
_« I H — M ... .Jl. — — ■ — —
SII I
I I I I I I
BZ23456 123456789R
ElI I I
I I I I I I
Mi I FZ23456123456789R
E21 I I
I I I
I I I
Die gestoerten Empfaenger erkennen einen Bitfehler (ihr LOW Bit
wird gestoert) und setzen eine Fehlermeldung ata. Der Sender
bekommt kein Acknowledge und setzt ebenfalls eine Fehlermeldung ab. Dadurch erkennen die nicht gestoerten Empfaenger einen
Fehler (ACK-DELIMITER) und sie setzten ebenfalls eine
Fehlermeldung ab. Nach dem letzten LOW Bit der Feherme Idung
kann mit neuen Uebertragungen oder der Wiederholung der
gestoerten Botschaft begonnen werden.
• 1(9.
a*-
4.6.5.4. Nur der Sender wird gestoert. Fehler in BUS-IDLE.
123456789R
12345FZ23456
123456789R
Sl
123456789R
123456789R
I I I I I
III! I
I I I I i
I I I I I
12345FZ23456123456789R
i I I
I I I I
I I I I
12345FZ23456123456789R
I I I
I I I I
Durch die Stoerung gelingt es dem Teilnehmer Sl nicht mehr
seine Uebertragung zu starten? und er verhaelt sich bis zum Ende der Fehlerbehandlung wie ein Empfaenger. Sl erkennt
Stuffehler und setzt seine Fehlermeldung ab. Dadurch erhalten
die Empfaenger einen Stuffehler und setzen ebenfalls eine Fehlermeldung ab. Nach der FphlermeIdung und anschliessender
Busruhe (Zustand BUS-IDLE) kann mit neuen Uebertragungen begonnen werden.
• so- y ,, .:
4.6.5.5. Stoerunq nur am Sender. Stuffehler im DATA-FIELD
Il I I I i
Il I I I I
123456789R 12345FZ23456 123456789R
Sl I I I I I I
Il I I I I
Il I I I I
Il III
123456789R 12345FZ23456123456789R
El I I III
Il III
Il III
Il III
123456789R 12345FZ23456123456789R
E2 I I III — ######******
Il III
Der Sender erkennt Stuffehler und Bitfehler zugleich und setzt
eine Fehlermeldung ab. Dadurch erhalten die Empfaenger einen
Stuffehler und setzen ebenfalls eine Fehlermeldung ab. Nach dem
letzten LOW Bit der Fehlermeldung und anschliesender Busruhe
(Zustand BUS-IDLE) kann mit neuen Uebertragungen oder der
Wiederholung der gestoerten Nachricht begonnen werden.
4.6.5.6. Fehler tritt an allen Empfaengern auf» aber nicht
am Sender bzw. an Station mit Sendewunsch auf. Bitfehler im CONTROLL-FIELD» Laengenangabe
verfae Ischt.
Fall l: Vergroesserung der Laengenangabej
Empfaenger erwarten laengere Botschaft als tatsaechlich gesendet.
CRC I I I
I FZ23456 123456789R
S I I I 1
Ii I I
Il I I
I I I CRC I I
I 12345FZ23456123456789R
—— —3 ....
—~
El .1 III
I I I 1 I I
I I I I I I
I I I CRC I I
I 12345FZ23456123456789R
E2 I III ######****##
I I I I I I
Die Empfaenger koennen 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 Empfaengern ein Stuffehler und sie setzen ebenfalls eine Fehlermeldung ab. Nach dem letzen LOW Bit der Fehlermeldung und
anschliessender Busruhe (Zustand BUS-IDLE) kann mit neuen
Uebertragungen oder der Wiederholung der gestoerten Botschaft begonnen werden.
-JfI-
Empfaenger erwarten eine kuerzere Botschaft als tatsaechlich gesendet.
CRC I BZ23456123456789R
• a . ■
S III
·_· ·_>
__· ■_■ ·_· «1 *m "■ fl » fc fc ""* *"" ^f "A* Λ Λ Λ Λ* Λ* ™"
ι · ι ι ι
II! I !Il I
CRC Ζ23456 123456789R
β ■ * ι ■
III I III I
III I CRC Z23456 123456789R
■ ■ ■ s
E2 III
« t _ ■
Die Empfaenger 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 letzen LOW
Bit der Fehlermeldung und anschliessender Busruhe (Zustand
BUS-IDLE) kann mit neuen Uebertragungen oder der Wiederholung der gestoerten Botschaft begonnen werden.
4.6.5.7. Fehler tritt an einem Teil der Empfaeger auf % aber
nicht am Sender bzw. an Station mit Sendewunsch.
Bitfehler in BUS-IDLE.
nicht am Sender bzw. an Station mit Sendewunsch.
Bitfehler in BUS-IDLE.
123456789R
CRC
* ■ a ■
| I I 123456789R |
I 11234 |
| I i I I |
I a ■ |
| I I I I |
I |
| I I 123456789F |
I I
I I
BZ23456
I I
BZ23456
12345678
Il I I
Ii I I
CRC I I
12345FZ23456 12345678
■ ■ m ·
CRC
I I I
II I I I I I
I I I 12345FZ2345612345678
I I I
Die gestoerten Empfaenger erhalten durch die Stoerung eine
falsche Laengenangabe und setzen deshalb ihren CRC-Check an die falsche Stelle. Wann der CRC der gestoerten Empfaenger um mehr
als 8 Takte spaeter als die richtige Lage erfolgt» so erhalten die Empfaenger einen Stuffehler und setzen eine Fehlermeldung
ab. Erfolgt der CRC-Check innerhalb von 8 Takten nach der richtigen Lage? so erkennen die gestoerten Empfaenger einen
CRC-Fehler und senden eine Fehlermeldung. Dadurch entsteht am
Sender ein Bitfehler. Die nicht gestoerten Empfaenger empfangen als END-OF-FRAME eine unzulaessige Bitfolge und setzen
ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW Bit der
Fehlermeldung und ansehtiessender Busruhe (Zustand BUS-IDLE)
kann mit neuen Uebertragungen oder der Wiederholung der gestoerten Nachricht begonnen werden.
• Sk
4.6.5.8. Fehler tritt an einem Teil der Empfaeger aufi aber
nicht am Sender bzw. an Station mit Sendewunsch. Stuffehler in DATA-FIELD.
I I IM I
I I I ! I I
123456789R BZ23456 123456789R
Sl I I Ii! I
I I III I
I I I 1 I I
I I III I
123456789R 12345FZ23456 123456789R
El I I III I
I I III I
I I III I
I I III I
123456789F 12345FZ23456123456789R
E2 I I Il
— -######*#***
Il Il
Die gestoerten Empfaenger erkennen einen Stuffehler und setzen
eine Fehlermeldung ab. Dadurch entsteht am Sender ein Bitfehler
und af\ den nicht gestoerten Empfaengern ein Stuffehler und sie
setzen ebenfalls eine Fehlermeldung ab. Nach dem letzten LOW
Bit der Fehlermeldung und anschliessender Busruhe (Zustand
BUS-IDLE) kann mit neuen Uebertragungen oder tiier Wiederholung
der gestoerten Nachricht begonnen werden.
4.7. INTERFACE-MANASEMENT-PROCESSOR (IMP)
4.7.1. Konfiguration
4.7.1.1. Allgemeines Konzept
4.7.1.1.1. Struktur
Der IMP hat folgende Aufgaben
- Datenaustausch zwischen CPU und serieller Schnittstelle
durch die Benutzung eines DUAL PORT RAM (DPRAM)
- Steuerung von Senden und Empfangen.
Fig. 11 zeigt das Blockschaltbild des seriellen
Schnittstellenbausteins Der serielle Schnittstellenbaustein
besteht aus den Teilen s
- DPRAI
- IMP
- serielles Schieberegister
- Bus logik
- Taktosz ilator
Die Verbindungen der Teile untereinander sind im
Blockschaltbild angegeben.
4.7.1.1.2. Prioritaet der Botschaften
Die Prioritaet innerhalb des IMP wird durch den Platz der verschiedenen Botschaftern im DPRAM festgelegt. Die Prioritaet
auf dem Bus CArbitrierung) wird durch den IDENTIFIER der
Botschaft bestimmt.
Der Suchprozess nach der hoechstprioren Botschaft innerhalb
eines IMP startet an der niedriqsten DPRAM Adresse.
. 9ο
4.7.1.1.3. Akzeptanzfilter
Jede vom Bus ankommende Nachricht wird daraufhin geprueft» ob
sie empfangen werden soll oder nicht. Dazu wird im DPRAM die Liste durchgesehen j in der alle Botschaften stehen? die in
diesem IMP verarbeitet werden. Eine ankommende Botschaft wird nur dann ins DPRAM uebernommenj wenn ihr IDENTIFIER dort
gefunden wird und wenn sie auch empfanqen werden soll? was
durch das RECEIVE/TRANSMIT Bit anzeigt wird.
4.7.1.1.4.
War+3schlange der Botschaften» die gesendet
werden soll.
werden soll.
Jede Botschaft? die gesendet werden soll? wird von der CPU in
das DPRAM geschrieben? wobei ansehtiessend das TRANSMIt-RESUEST
Bit gesetzt wird. Ein Suchvorgang findet die hoechstpriore
Botschaft» die zur Uebertragung ansteht. Nur diese Botschaft wird fuer eine Uebertragung ins serielle Schieberegister
beruecksichtigt. Wenn die CPU spaeter eine wichtigere Botschaft
zur Uebertragung anmeldet» so wird der Suchvorgang diese entdecken und die erste Botschaft verdraengen. Dadurch werden
die Botschaften entsprechend ihrer Prioritaet uebertrageni unabhaenig von ihrer Ankunftszeit.
4.7.1.1.5. Warteschlange empfangenen Botschaften
Wenn empfangene Botschaften im DPRAM gespeichert werden» wird automatisch das INTERRUPT-REÜUEST Bit gesetzt. Der Suchvorgang
wird unter den empfangenen Botschaften diejenige mit der hoechsten Prioritaet finden und einen Interrupt an die CPU
weitergeben . Wenn eine wichtigere Botschaft im DPRAM gepseichert wird» bevor die CPU den Interrupt beantwortet hat»
so wird die hoehsrpriore Botschaft beruecksichtigt. Damit
werden die Botschaften entsprechend ihrer Prioritaet beruecksichtigt» unabhaengig von ihrer Ankunftszeit.
4.7.1.2. DPRAM Organisation
Das DPRAM enthaelt DESCRIPTORen CIDENTIFIERi CONTROL-SEGMENTe)
und DATA-FIELDs aller Botschaften» die von der CPU ueber den
Bus empfangen oder gesendet werden sollen. Die Aufteilung des DPRAM ist unabhaengig vom spezifizierten Protokoll.
MoegIi chke i t en :
getrennte Speicher fuer ankommende und
abgehende Botschaften
abgehende Botschaften
getrennte Speicher ΓΆΤΑ-FIELDS
fuer DESCRIPTORS und
- einen einzigen Speicher fuer alle Aufgaben
In einer ersten Ausfuehrung wird ein Speicher fuer alle Aufgaben vorgeschlagen. Die Botschaften koennen aequidistant in
den Speicher eingetragen werden. Um jedoch Speicherplatz zu
sparen» ist es angebracht? die Botschaften hintereinander
dichtgepackt abzuspeichern? mit einer Laenge von drei bis zehn
Bytes'abhaengig von der DATA-ßYTE-COUIMT.
Die Sroesse des DPRAM ist zur Zeit auf 64 Byte festgelegt. Wenn die Integraationskosten in Zukunft kleiner werden sollten* kann
der Speicher vergroessert werden. Damit koennten eine groessere Anzahl von Botschaften oder laengere Botschaften (sowohl
DATA-FIELD als auch DESCRIPTOR) gespeichert werden. Es koennten auch Ersatzbotschaften fuer dss Ausbleiben von Nachrichten im
DPRAM abge'egt werden» was im Fehlerfall die Software vereinfachen wuerde.
5?·
Adress
Ze iger
Ze iger
des
DPRAM
~>l IDENTIFIER 1 I
+ + DESCRIPTOR
I CONTROL-SEGMENT 1 I
I DATA-FIELD 1 Cl Byte) I DATA
1 I1 ι mtm __ mmm ^ __ ^ ,_ m^ _ m ^ ^- __ __ mml __ mmt _^ ^-, ^- tmt ^ — „„,„„ ■»—.■»— ·— — ·—· ·*■ *·« —>
B_ MB (i.
I IDENTIFIER 2 I
I CONTROL-SEGMENT 2 I
J. ^ ^ ^ ·_ BV » «— *M «■ — ■>« M>
*** M SH H ■»■* ·— BH *« «— ■» SH ——■-·. M _._«*« — -~ ·—· « _M ~B- ·_· «i.
I I
I I
+- DATA-FIELD 2 (4 Bytes) -+
I i
I !
I . I
I Up to Byte 64 I
Das DPRAM dient also als:
- Speicher? der gleichseitig entscheidet ob ankommende
Botschaften emfangen werden sollen (AkzeptanzfiIter)
- Warteschlange fuer ankommende und fortgehende Botschaften
geordnet nach ihrer Prioritaet
- Speicher fuer die Kontrollregister des IMP
4.7.1.3. CONTROL-SEGMENT Organisation
•S9·
| +- | — — — | —+ |
| I | 7 | I |
| *T* """" | -+ | |
| I | 6 | I |
| I | 5 | I |
| «· aim | ||
| I | 4 | I |
| - + | ||
| ! | 3 | I |
| I | 2 | I |
| + - | - + | |
| I | 1 | I |
DATA-BYTE-CODE
TRANSMISSION-REQUEST PENDING TRANSMISSION-COUNT INTERRUPT-REQUEST
INTERRUPT-ENABLE
+
+
0 I RECEIVE/TRANSMIT
4.7.1.4. Funktion des DPRAM
4.7.1.4.1. DATA-BYTE-CODE
Bei Suchvorgaer.gen muss der Aclrsss Zeiger des DPRAM zuerst auf
den jeweiligen Anfang einer Botschaft zeigen. Wenn die DESCRIPTORen und DATA-Fields dichtgepackt abgespeichert sind)
kann auf die naechste botschaft gezeigt werden indem man den Zeiger um
2**CDATA-BYTE-C0UNT) + 2
erhoeht. Um den Speicherplatz und die Botschaften besser
auszunuetzenj koennen mehrere Botschaften unter einem
DESCRIPTOR zusammengefasst werden und als eine grosse Botschaft
uebertragen werden. Die maximale Blockgroesse wird vorerst auf 8 Bytes festgelegt.
Die Laenge des DÄTA-FIELDs erhaelt man aus dem DATA-BYTE-CODE
m i t
DATA-BYTE-COUNT = 2** DATA-BYTE-CODE
- .55 -
4.7.1.4.2. PENDING
Das PENDING Bit zeigt am dass entweder eine Uebertragung oder
eine Interruptroutine noch nicht fertig ist. Es wird
automatisch gesetzt wenn eine Uebertragung auf dem Bus beginnt oder wenn die CPU einen Interrupt
Interruptzeigers). Das PENDING Bit wird
Uebertraqunq (erfolgreich oder
zurueckgesetzt. Das PENDING Bit
Programmkontrolle von der CPU
INTERRUPT-RESUEST oder bei Ankunft einer
dem gleichen IDENTIFIER zurueckgesetzt.
Interruptzeigers). Das PENDING Bit wird
Uebertraqunq (erfolgreich oder
zurueckgesetzt. Das PENDING Bit
Programmkontrolle von der CPU
INTERRUPT-RESUEST oder bei Ankunft einer
dem gleichen IDENTIFIER zurueckgesetzt.
bestaetigt (Laden des automatisch nach einer
nicht erfolgreich)
wird ausserdem unter
zusammen mit dem
neuen Botschaft mit
Ist das PENDING Bit
einer Botschaft gesetzt» so wird Suchvorgang nicht beruscksichtigt.
diese Botschaft bei einem
Das PENDING Bit erlaubt dem Programmierer der CPU am Ende der
Interruptroutine zu ueberpruefen ι ob ein weiterer Interrupt die
Konsistenz einer Botschaft mit mehreren Bytes zerstoert hat.***
Wenn das PENDING Bit am Ende der Interruptroutine immer noch
auf HIGH steht !ist dies die Bestaetigung» dass das DATA-FIELD
konsistent bearbeitet wurde vor Ankunft der naechsten Botschaft.
INTERRUPT-REQUEST
PENDING
Wirkung
LOW
LOW
HIGH
HIGH
LOW HIGH
LOW HIGH
kein Interrupt
kein Int errupt
neuer Interrupt
kein Int errupt
neuer Interrupt
Bestaetigung des
Int errupts
Int errupts
Diese Vorgaenge erfolgen nur fuer INTERRUPT-ENABLE = HIGH. Wenn der INERRÜPT-ENABLE auf Low zurueckgesetzt ist? dann wird das
PENDING Bit nicht mit der Interruptbestaetigung der CPU
geset zt.
4.7.1.4.3. INTERRUPT-ENABLE
Ein gesetztes INTERRUPT-ENABLE erlaubt? dass INTERRUPT-RESUESTs
im richtigen Bezug zur CPU weitergegeben werden.
Ein nicht gesetztes INTERRUPT-ENABLE verhindert? dass eine
Interruptaktion an die CPU gemeldet wird.
tra -
4.7.1.4.4. INTERRUPT-RESUEST
Der INTERRUPT-REQUEST wird automatisch auf HIGH gesetzt bei
jeder Uebertraqunq einer neu empfanqenen Botschaft ins DPRAM unabhaengig von Zustand des INTERRUPT-ENABLE. INTERRUPT-REQUEST
wird auch gesetzt» wenn eine wiederholte Uebertragung (TRANSMISSION-COUNT = HIGH) scheitert.
4.7.1.4.5. TRANSMISSION-COUNT
TRANSMISSION-COUNT
TRANSMISSION-COUNT
zurueckgesetzt.
TRANSMISSION-COUNT
zurueckgesetzt.
zaehlt die Ubertragungsversuche. wird nach einer erfolgreichen Uebertragung
TRANSMISSION-REQUEST I TRANSMISSION-COUNT
Zustand
LOW
LOW
HIGH
HIGH
der zweiten
LOW
HIGH
LOW
HIGH
fehlerhaften
INTERRUPT-REQUEST gesetzt um die weitere Benutzersoftware ueberlassen zu koennen.
Ikeine Uebertragung
!keine Uebertragung
.!erste Uebertragung
!zweite Uebertragung Uebertragung wird
Fehlerbehandlung der
Fehlerbehandlung der
4.7.1.4.6. TRANSMISSION-REQUEST
Ein gesetztes TRANSMISSION-REQUEST Bit zugehoerige Botschaft zu uebertragen.
Es gibt zwei verschiedene Zustaendes
veranlasst den IMP die
RECEIVE/TRANSMIT = LOW (Uebertragung)
Startwert nach einem Reset. Die Botschaft wird gesendet. TRANSMISSION-REQUEST wird von der CPU oder
von einer ankommenden Botschaft mit gesetzem REMOTE-TRANSMISSION-REQUEST Bit auf HIGH gesetzt.
RECEIVE/TRANSMIT = HIGH (Empfang)
Alle so gekennzeichneten Botschaften sind im
Empfanqsmodus. Als Ausnahme in diesem Zustand wird
durchOP Setzen von TRANSMISSION-REQUEST eine Botschaft
mit leerem DATA-FIELD und qesetztem REMOTE-TRANSMISSION-REQUEST abgeschickt.
4.7.1.4.7. RECEIVE/TRANSMIT
RECEIVE/TRANSMIT bestimmt die Richtung der Daten.
RECEIVE/TRANSMIT = LOW (Uebertragung)
Startwert nach einem Reset. Die DATA-FIELDs im DPRAM
sind fuer ankommende Botschaften schreibqeschuetzt>
wenn RECEIVE/TRANSMIT auf LOW gesetzt" ist. Die Botschaften werden durch TRANSMISSION-REQUEST HI6H
akt iν i ert.
Es gibt jedoch eine Ausnahme!
Wenn REMOTE-TRANSMISSION-REQUEST = HISH in einer ankommenden Botschaft isti dann wird
TRANSMISSION-REQUEST des zugehoerigsn CONTROL-SEGMENTs auf HIGH gesetzt trotz RECEIVE/TRANSMIT = LOW.
TRANSMISSION-REQUEST ist das einzige Bit» das in dieser Operation geaendert wird? alle anderen Bits bleiben
weiterhin schreibgeschuetzt. Dieses Vorgehen dient zur
Anforderung von Botschaften durch andere Busteilnehmer.
RECEIVE/TRÄNSMIT = HIGH (Empfang)
Die ankommenden Botschaften werden in das zuqehoeriqe
DATA-FIELD uebertragen. INTERRUPT-REQUESf wird automatisch auf HIGH gesetzt bei jeder Uebertragung der
zugehoerigen Botschaft.
4.7.2. Datenaustausch CPU-DPRAM
4.7.2.1. Synchronisations Problem
Der Austausch von DATA-FIELDs» die aus mehreren Bytes bestehen?
kann abhaengig von der Anwendung ohne Beruecksichtigung von der
synchronen Betriebweise vorgenommen werden. Wenn die DATA-FIELDs jedoch synchron verarbeitet werden sollen» muss
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 Prioritaet
gegenueber allen anderen Zugriffsversuchen zu.
4.7.2.2, Nicht synchrone Operation
Das DPRAM wird von der CPU als RAM-Erweiterung benutzt. Es
werden keine weiteren Uebertragungsbefehle dazu benoetigt.
Empfangene Botschaften werden einfach in das DPRAM geschrieben? wobei die vorhergehenden Botschaften ueberschrieben werden.
Uebertraguncjen werden von der CPU durch Setzen von
TRANSMISSION-RESUEST im CONTROL-SEGMENT » das zu dem zu
uebertragenen DATA-FIELD gehoert? gestartet.
TRANSMISSION-REQUEST kann ebenso von fremden CPUs durch REMOTE-TRANSMISSION-REQUEST gesetzt werden.
4.7.2.3. Software Synchronisation
4.7.2.3.1. Abfragen einer Sequenznummer
Wenn die sendende CPU ein Byte dss DATA-FIELDs als
Sequenznummer benutzt? und diese vor jedem Setzen des TRANSMISSION-REQUEST Bits inkrementiertj dann kann die
empfangende CPU anhand der Sequenznummer pruefen? ob sich diese veraenderi hat nachdem sie die Daten im DATA-FIELD bearbeitet
hat. Wenn sich die Sequenznummer veraendert hat? muss die empfangende CPU einen Teil der bearbeitung mit den neuen Daten
wi ederholen.
4.7.2.3.2. Abfragen des INTERRUPT-REQUEST
Neu ankommende Botschaften setzen automatisch das INTERRUPT-REQUEST Bit im zugehoerigen CONTROL-SEGMENT. Auch
wenn der CPU wegen INTERRUPT-ENABLE = LOW keinen Interrupt
mitgeteilt wirdi wird INTERRUPT-REQUEST vor jeder Bearbeitung der Botschaft zuruechgesetzt und nach der Bearbeitung wird
geprueft? ob es nicht in der Zwischenzeit wieder gesetzt wurde.
4.7.2.3.3. Interrupt.gesteuerte Bearbeitung
Die empfangende CPU kann im CONTROL-SEGMENT der zu empfangenden
Botschaft "das INTERRUPT-ENABLE Bit setzen. Neu ankommende Botschaften setzen das zugehoerige INTERRUPT-REßUEST Bit und
setzen gleichzeitig automatisch das PENDINS Bit auf LOW zurueck. Der wichtigste Interrupt wird der CPU gemeldet. Die
Bestaetigung der CPU setzt automatisch das PENDING Bit auf
HIGH. Bevor die CPU am Ende der Interruptbehandlunq beide (INTERRUPT-REtSUEST und PENDING) zurueckset zt ? fragt sie das
PENDING Bit ab. Wenn das PENDING Bit immer noch auf HIGH ist» so ist die naechste Botschaft nicht innnerhalb der
Interruptbehandlung angekommen.
4.7.2.3.4. Block Uebertragung
Um DATA-FIELDs synchron zu bearbeiten koennen diese blockweise
zu und von CPU uebertragen werden. Ausreichender RAM
Speicherplatz muss fuer die dadurch bedingte doppelte
Speicherung bereitgestellt werden.
a. Senden
Am Anfang wird TRANSMISSION-REQUEST* das als Semaphor
Variable dient? geprueft. Wenn es zurueckgesetzt isti wird
das DATA-FIELD byteweise vom CPU-RAM ins DPRAM uebertragen. Danach wird TRANSMISSION-REQUEST gesetzt.
WARNUNG! Bei dieser Vorqehensweise kann im Falle eines
gesetrten 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 uebertragen? wie unter 4.7.2.4.2. beschrieben. Dadurch wird die Wahrscheinlichkeit?
dass die Daten inkonsistent werden? betraechtlich
verringert? da der kritische Zeitabschnitt von der gesamten
Interruptbearbeitung auf die Blockuebertragung des
DATA-FIELDs verringert wird.
4.7.2.3.5. Doppelter Empfangspuffer
Fuer wichtige Botschaften koennen zwei Speicherplaetze 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 Aendern
des zugehoerigen RECEIVE/TRANSMIT Bits» anschliessend an die
Bestaetigung des Interrupts» umschalten. Bei dieser Vorgehensweise ist in einem Speicherplatz das RECEIVE/TRANSMIT
Bit HISHj und ist damit bereit» die entsprechende Botschaft
aufzunehmen» und im anderen Speicherplatz mit dem qleichen
IDENTIFIER ist das RECEIVE/TRANSMIT Bit LOW? und damit ist die
gerade empfangene Botschaft dort schreibgeschuetzt.
4.7.2.4. Hardware Synchronisation
Als Voraussetzung fuer eine Hardware Synchronisation muss die
CPU schnelle Blockuebertragung mit DMA-Faehigkeiten 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
Blockuebertragung geschuetzt. Zwischen dem Ende einer Uebertragung und dem Start einer neuen muss genuegend Zeit
vorgesehen werden. Im schlechtesten Fall muss der IMP solange
warten» bis die CPU eine Blockuebertragung abgeschlossen hat. Die CPU muss im schlechtesten Fall warten» bis der IMP eine
empfangene Botschaft im DPRAM gespeichert und die naechste
Botschaft» die uebertragen werden soll» ins serielle Schieberegister geladen hat.
4.7.3. Datenaustausch DPRAM - Schieberegister
4.7.3.1. Parallele Steuerprozesse
Der Datenaustausch zwischen DPRAM und seriellem Schieberegister
wird durch mehrere parallele Prozesse gesteuert» deren Funktion spaeter beschrieben wird. Ein Prozess wird initialisiert und
damit in den aktiven Zustand ueberfuehrt durch ein Aktivierungssignal. Im aktiven Zustand kann jeder Prozess
weitere Aktivierungssignale ausgeben» die wiederum zu anderen
Prozessen gehen. Die Ausgabe eines Aktivierungssignals bedeutet
nicht notwendigerweise» dass der Sue IIprozess sich gleichzeitig
deaktivieren muss. Die gesamte Steuerung enthaelt die folgenden Prozesse und Aktivierungssignales
Prozesse
I
ν
I
ν
+■
I
I
I
I
LOAD
STORE
ERROR
Akt ivierungssignale
I
ν
I
ν
+ Ende der Uebertragung Ende der Arbitrierung Start Search
Uebertragungsfehler
Uebertragungsfehler
>o I
I
Beginn der Uebertragung i I
-+ I I
! I ■+ Beginn der Uebertragung I I
I Uebertraqunqsfehler I I
I 1—1 +__+.
I Ende der Uebertragung ν I
I -ζ — — ·—— _-_ —_ __.„____—. — _ q |
■+ I
-+ Beginn der Uebertragung
I Uebertragungsfehler
-+ Start Search
I
RECEIVE/ I
TRANSMIT I Ende der Arbitrierung
ι < 1.
·+ Weitermachen
SEARCH f <-
■>o
ν
ν
--O
Start Search
I <-
■+-
I I
I I I I ! I
+ 1
i V
—ο
ν
>o
>o
-o
-+ Weitermachen
I -
INTERRUPT- I
! HANDLING I
I <-
ν
σ
σ
Aktivierungssignale!
- Ende der Uebertragungi
Endesignal am Ende einer fehlerfrei abgeschlossenen Uebertraqunq. Wird beim Ueberqanq aus dem Zustand
TRANSMIT-END-OF-FRAME in den Zustand TEST-INTERMISSION fuer einen Bustakt gesetzt. - Ende der Arbitrierung!
Signal am Ende des Ärbitrierungsvorgangs? nach Auftreten
dieses Signals ist der BUS-Zugriff geregelt (Senden oder Empfangen). Wird am Ende der Üebertragung des IDENTIFIERS
fuer einen Bustakt gesetzt.
- Start Search:
Startsignal fuer den SEARCH-Prozess? vom Anfang des DPRAM an den Suchvorganq neu zu beqinnen? erfolqt am Ende des
RECEIVE/TRANSMIT-Prozesses.
- Uebertragungsfehlerί
Fehlermeldung vom Uebertragungsvorgang. Wird fuer einen
Bustakt gesetzt? wenn eine Fehlermeldung auf dem Bus
uebertragen wird.
- Beginn der Üebertragung:
Startsignal fuer den LOAD-Prozess? erfolgt am Ende des STORE-Prozesses oder des ERROR-Prozesses
- Weitermachen:
- Erneuter Start bei Endlos-Prozessen
Die Prozesse sind im folgenden unter Zuhilfenahme der ueblichen KontrolIfluss-Konstrukte erklaert? wie sie in ALSOL oder PASCAL
verwendet werden und mit denen auch in der Informatik-Literatur
gearbe i t et wird.
4.7.3.2. LOAD-Prozess
Der LOAD-Prozess laedt die naechste zu usbertragende Botschaft
in das serielle Schieberegister. Wenn keine Botschaft zur
Üebertragung ansteht» wird der SEARCH-Prozess gestartet. Wenn
der SEARCH-Prozess bei noch belegtem BUS eventuell eine zweite Botschaft mit hoeherer Prioritaet in der Warteschlange zu
uebertragender Prozesse findet? so wird diese Botschaft die vorher gefundene verdraengen.
Bus free:
Bus free:
Bus free ist wahr? waehrend dIE BOTSCHAFTSSEGMENTE
START-OF-FRAME »IDENTIFIER? CONTROL-FIELD? DATA-FIELD?
CRC-FIELD UND ACK-FIELD uebertragen werden. TRANSMIT-STATUS:
Muss am Ende der Arbitierung gesetzt (HIGH) oder rueckgesetzt (LOW) werden
- VZ -Initialisierung: TRANSMIT-STATUS = LOW
Beqinn der Uebertraqunq
I ν m , mm mm mm ^, n ι _,, 1M „ J, .... .„ .- ι, ι imu ■mm — „ι ,„ X
ITRANSMIT-STATUS=LOWi -Csetze TRANSMIT-STATUS zurueck
+ + + auf Anfangsbedingung vor dem
ν Ende der Arbitrierung>
/ TX-POINTER < equal to \ EMPTY-POINTER?
ν Yes
Start Search
\ No >
>o
ν >o
No
/ TX-POINTER < equal to \ EMPTY-POINTER?
\ .— _ — — -* — — — X — — — — ——
I Yes
No /- \-
BUS free?
I Yes
I
untrennbare ν Operation
I
untrennbare ν Operation
τ Τ
l-test and set semaphore
I to block DPRAM
I if RECEIVE/TRANSMIT=HISH
I then I
I to block DPRAM
I if RECEIVE/TRANSMIT=HISH
I then I
I begin
I set REMOTE-TRANSMISSION- I I REQUEST Bit
I load first byte of DATA-FIELD I I into shift reqister
I load DATA-BYTE-CÖDE=zero into I shift register
I end else
I load first byte of DATA-FIELD I I into shift reqister
I load DATA-BYTE-CÖDE=zero into I shift register
I end else
l-load message into shift
I register
l-reset semaphore to !
I register
l-reset semaphore to !
I unblock DPRAM I
I aktivate TX-REQUEST !
Ende der Arbitrierung
Ende der Uebertragung
Ende der Uebertragung
Uebertragungsfehler
4.7.3.3. STORE-Prozess
Der STORE-Prosess speichert entweder eine empfanqene Botschaft
oder verwaltet die TRANSMISSION-REQUEST und PENDING Bits von gesendeten Botschaften. Das Signal Ende der Uebertragung kommt
nur nach einem erfolgreichen Uebertragungsvorgang ohne Fehler.
Im Falle eines Fehlers kommt Uebertragungsfehler.
-JS5
Ende der Uebertraqunq I
ν
ν
untrennbare Operation
I test and set semaphore I block DPRAM
to I
<TRANSMIT-STATUS=HIGH ?
ν Yes I ν
l-swap TX-POINTER
I with stack
l-reset TRANSMISSION-REQUEST to I LOW
l-reset TRANSMISSION-COUNT to I LOW
l-reset PENDING to LOW l-swap TX-POINTER
I with stack
I-reset TRANSMIT-STATUS to LOW • ^ „. ,B^e-, ^ ^HBHH ··— ^ a_ ·» <m η -I- — ·— ·■- ·»■- — ββ — .·■. β«» _ — ^ — <m _
-if RECEIVE/TRANSMIT = HIGH then
begin
begin
set INTERRUPT-REQUEST to HIGH? set PENDING to LOW
end else
begin
begin
if REMOTE-TRANSMISSION-RE(5UEST=HIGH then b e q i η
set TRANSMISSION-REQUEST» reset PENDING
end5
end 5
end 5
-reset RX-POINTER to EMPTY-POINTER?
I I
ν -o
+ 1 1
I reset semaphore to unblockl I DPRAM !
+ 1 1
Beginn der Uebertragung Uebertragungsfehler
4.7.3.4. ERROR-Prozess
Der Error Prozess zaehlt im FehlerfaU TRANSMISSION-COUNT hoch
oder setzt im Falle einer zweiten nicht geglueckten Uebertragung INTERRUPT-REQUEST. Eine empfangene Botschaft wird
im Fehlerfall einfach nicht weiter verarbeitet.
| Uebertraqunqsf i V |
ehler | vidable | No S.— _. _._. — — _ |
| <TRANSMIT-STATUS \ + |
-high ?; | ||
| LYes | 1 | ||
| I reset TX-REQUEST I •L· ' Il I I |
|||
| 1 ν undi L ______ |
operat ion .——j. |
>o
l-test and set semaphore to
I block DPRAM
-swap TX-POINTER
I block DPRAM
-swap TX-POINTER
with stack
-if TRANSMISSION-COUNT = LOW
then increment TRANSMISSION-COUNT
else
then increment TRANSMISSION-COUNT
else
■ set INTERRUPT-REQUEST to HIGH
-reset PENDING of transmit
-reset PENDING of transmit
messaqe to LCW
-swap TX-POINTER
-swap TX-POINTER
with stack
-reset semaphore to unblock
DPRAM
DPRAM
Beginn der Uebertragung
• η
4.7.3.5. RECEIVE/TRANSMIT-Prozess
Im Falle dass die Arbitrierung gewonnen wurde» wird das PENDING
Bit» das zur gerade uebertragenen Botschaft gehoert» auf HIGH gesetzt und dann der zugehoerige TX-POINTER auf den Stack
geladen. Der RECEIVE/ TRANFMIT-Prozess setzt je nach Ausgang
der Arbitrierung den TX-POINTER oder den RX-POINTER auf einen leeren Adresszeiger zurueck» bevor der SEARCH-Prozess durch
Start Search aktiviert wird.
Ende der Arbitrierung
untrennbare Operation
m H mm ·_ — Ktm mm>
*_· ^ «t se· ·— ^ _ ■_■ a». — m—mm — *·· <4_
<TRANSMIT-STATUS=HIGH
ν Yes I reset TX-RESUEST I
\ No
I ν
-test and set semaphore
to block DPRAM -set PENDING of transmit
message to HIGH -push TX-POINTER to stack -reset TX-POINTER
to EMPTY-POINTER -reset semaphore to unblock DPRAM
ν — aw M _ _ M _ aw mmt s— β· -4· H ν — — —a ^ IH. w — —. _>
a·
mm mm· mm mam a» «-<· — ·» —>
mm mm» — >&· ·__ _ _m as. —· «m ■«—.——» η w ι
reset RX-POINTERI to EMPTY-POINTERI
I I ν
ν ■o
Start
Search
4.7.3.6. SEARCH-Prozess
Der Search-Prozess sucht andauernd nach Adresszeigern des DPRAM
f uer
- zu uebertragende Botschaften (TX-POINTER) j
wenn TRANSMISSION-REQUEST gesetzt ist 5
- zu empfangende Botschaften (RX-POINTER)?
dh. ob der- empfangene IDENTIFIER im DPRAIi enthalten ist»
- Botschaften» die eine Unterbrechungsanforderung bei der
CPU ausloesen sollen» dh. bei denen INTERRUPT-REQUEST
und INTERRUPT-ENABLE gesetzt sind.
Der SEARCH-Prozess wird mit Start Search auf die Botschaft mit der hoechsten Prioritaet am Anfang des DPRAM zurueckgesetztι
wenn die Echt zeitablaeufe bei der Uebertragung auf dem BUS es
erfordern. Das Absuchen einer gesamten Botschaft ist als unteilbare Operation ausgefuehrt. In jeder Clock-Periode kann
der SEARCH-Prozess durch einen DPRAM-Zugriff der CPU im
Cycle-Stealing-Verfahren angehalten und um eine Clock-Periode
verzoegert werden. Nach Abschluss der unteilbaren Operation kann der SEARCH-Prozess durch hoeherpriore Prozesse vom Zugriff
des DPRAM ausgeschlossen werdem bis die Semaphore-Variable
wieder vom SEARCH-Prozess selbst gesetzt werden kann.
η-
Start Search I ν
™ T ~
l-reset SEARCH-POINTER to DPRAM I I adress of highest priority I
l-reset T5RjI flags to LOW I
T ™ ^" — — -J-
o<
untrennbare Operation ν
-test and set semaphore to block DPRAMi
-read IDENTIFIER of SEARCH-POINTER? -if R=LOW then
begi η
begi η
if IDENTIFIER in DPRAM and received message are equal then
begin
begin
increment SEARCH-POINTER?
if RECEIVE/TRANSMIT=HISH of SEARCH-POINTER then
begin
load
set
end
begin
load
set
end
end else
incremen
end else
incremen
end else
increment SEARCH-POINTER! -if PENDING=LOW of SEARCH-POINTER
begi η
read CONTROL-SEGMENT of SEARCH-POINTERi
if <INTERRUPT-ENABLE=HIGH) and (INTERRUPT-REQUEST=HIGH)
and (I=LOW) then beqi η
load SEARCH-POINTER to INTERRUPT-P0INTER5
set I=HIGH
end?
end?
SEARCH-POINTER R=HIGH
to RX-P0INTER5
SEARCH-POINTER
then
if CRECEIVE/TRANSMIT=LOW) and (TRANSMISSION
-REQUEST=HISH) and (T=LOW) then begin
load SEARCH-POINTER to TX-POINTER!
load SEARCH-POINTER to TX-POINTER!
set T=HIGH
end
end?
reset semaphore to unblock DPRAIi!
end
end?
reset semaphore to unblock DPRAIi!
. __ __ mm _ _ H _. w _·—_>
—— _- —_ _· mm■ ·_· —— _ u _—. _ ■!■ ·_ —>
·—. Ha «η m>
— _ ma. «· «a· *«* <Μ· — MB M -H ·_ _· Ma ^ M
!-increment SEARCH-POINTERI I (DATA-BYTE-CODE) !
I by 2 +IiI
— W·. V— -^ _ — — —— — -γ- ·_ — -HP· —- — —— -J-
< SEARCH-POINTER overfLOW ? >
V __ —— ^-_ —_ — ______ ~— f
v Yes
No
4.7.3.7. INTERRUPT-HANDLING-Prozess
Der INTERRUPT-HANDLINe-Prozess leitet Interrupts von
empfangenen Bo schäften oder von mehrfach fehlerhaft uebertragenen Botschaften an die CPU weiter. Es wird jeweils
der Interrupt mit der durch die Anordnung im DPRAM vorgegebenen hoechsten Prioritaet ar\ die CPU we i t ergele i t et. Der INTERRUPT-HANDLING-Prozess
laeuft ununterbrochen? parallel zu den
aenderen Prozessen. Der Anfangswert des Interrupt Pointers ist der leere Adresszeiger.
-JA-
< INTERRUPT-POINTER non-empty ? > >o
N + / . No
ν Yes
I activate interrupt request I I at CPU input I
οι———————————————~——ο
/ — — \ I
<interrupt acknowledged by CPU ?>—>o
ν Yes
T T
-test and set semaphore to block DPRAM5
i-set PENDING of INTERRUPT-POINTER to Hi I-reset INTERRUPT-POINTER with EMPTY-POINTER?
I
-reset semaphore to unblock DPRAMI I
ο
>o
c ο η t i η u e
4.7.4. Steuerung des Zugriffs sum DPRAM
4.7.4.1. Zugriffssynchron isat ion
Die Zugriffe zum DPRAM werden durch eine Semaphore-Variable
geregelt. Diese sichert den unteilbaren Zugriff zu den zusammengehoerigen Bytes der DATA-FIELDs und des
CONTROL-SEGMENTs. Andere Zugriffe werden solange blockiert» bis die Semaphore- Variable zurueckgesetzt ist. Damit wird die
Konsistenz von DATA-FIELDs geschuetztj die laenger als ein Byte sind. Wenn mehrere Prozesse versuchen sollten» die
Semaphore-Variable gleichzeitig zu setzen» dann gilt das
folgende Prioritaeten- Schemas
a. STORE
b. LOAD
c. ERROR
d. INTERRUPT-HANDLING
e. RECEIVE/TRANSMIT
f. SEARCH
Die CPU wird von der Zugriffsverwaltung mittels Semaphore
ausgenommen. Sie hat per Cycle-Stealing immer sofortigen
Vorrang vor allen anderen Zugriffen. Es ist klar» dass mit dieser Regelung die Konsistenz- der Daten bei CPU-Zugriffen
ggfs. verletzt Werden kann. Um dies zu vermeiden» muesste 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 verfuegbaren CPÜs noch nicht realisiert sind.
4.7.4.2. DPRAM-Adresszeiger
Auf den DPRAM wird von verschiedenen Quellen aus zugegriffen»
der CPU und den parallelen Prozessen. Die Adressen kommen dabei von
- CPU-Adresse
- EMPTY-POINTER:
Adresszeiger» der auf eine leere» d.h. nicht mit
sinnvollen Botschaften gefuellte Adresse zeigt. Wenn ein Adresszeiger gleich dem EMPTY-POINTER ist»
wird dies so interpretiert» dass keine entsprechende
Botschaft vorliegt
- SEARCH-POINTER:
Adresszeiger des SEARCH-Prozesses
- TX-POINTER:
Adresszeiger» der auf die zu sendende Botschaft
zeiqt. Falls keine Botschaft zu senden ist» ist der'TX-POINTER = EMPTY-POINTER
- RX-POINTER:
Adresszeigerj der auf die zu empfangende Botschaft
zeigt. Falls keine Botschaft zu empfangen ist» ist derRX-POINTER = EMPTY-POINTER
- INTERRUPT-POINTER:
Adresszeigerj der auf die Botschaft zeigt» die eine -Unterbrechungsanforderung
an die CPU hat. Falls keine Unterbrechunqsanforderunq vorlieqt» ist der
INTERRUPT-POINTER = EMPTY-POINTER
Die Adresszeiger (Pointer) werden in den verschiedenen Prozessen verarbeitet» um die DPRAM-Adresse zu erhalten» unter
der Daten gespeichert oder gelesen werden sollen. Die tatsaechlichen DPRAM- Zugriffe mittels der Adresszeiger sind
entsprechend ihrer Prioritaet organisiert. Unteilbare Zugriffe
auf mehrere Bytes geschehen mittels der Semaphore-Variablen 5
die den Zugriff fuer alle Prozesse blockiert? ausser fuer den
Prozess» der die Semaphore-Variable selbst gesetzt hat.
4.7.4.3. Prioritaetssteuerung
Wie bereits beschrieben» werden der CPU-Zugriff auf den DPRAM und das Setzen der Semaphore-Variablen nach Prioritaeten
geordnet. Ein Prozess darf seine Mrssse nur dann an dan
Adresse ingang 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 Prozess
belegt ist (Semaphore = LOW). Die Anschluesse von LOAD» ERROR? INTERRUPT-HANDLING? RECEIVE/TRANSMIT und SEARCH sind gleich wia
bei STORE und deshalb nicht detailliert gezeichnet.
I o< >+
I +
+ I
Daten
_ Jr -«
DPRAM
CPU
OTADC W I VAt-
LOAD
ο I
+ adrsss
I access
>0 I request
+ adress
I access
I >0
inhibit
I semaphore I I
JLy _. ~ J . L
Itest and setl semaphore I
I reset
+
+
I semaphore !
+ y+ access
1 1
o< >+ SEARCH
o< >+ ERROR I
I +<■
+ ι
•1· —t — __ w a» —. ·^ —· —· — a— *a>
-4·
I +—
>+ INTERRUPT- I
I HANDLING I
.J. MH —1· __ MH — — MK ··* ·— _■ HK BM -f·
« _ .« H- _„ π« HI ^ HHI H-I __· _· HHl *L
I +—
>+ RECEIVE/ I
I TRANSMIT I
-+ I
I I
I
+-
+-
Eine Ausfuehrung fuer den Block 'Access Control' des obigen
Schemas ist im folgenden Flussdiagramm angegeben? das in jeder Clock-Periode durchlaufen wird.
SO
untrennbare Operation
/ + χ Yes
<CPU access request?>
\———— 1· — /
+ t . 1
lreset access inhibit f
* ^ mm mim — m m^ ^m ^- ,_ ^- ^- +^ ■■■ ■-· ··— ^ ·— ·— — —■ ^ +
/ + \ Yes
< semaphore set ? >
/ + \ Yes
<test+set frm STORE?> >o
/ + \ Yes v
<test+set from LOAD?> >o
\ I / I
\ t~ / ι
/ + \ Yes v
<test+set frm ERROR?> >o
\-__ __ —_ —J.—____ ___ /
— — —. — — — —-j-— — — j
/ + \ Yes
<test+set fr INT-HA?> >o
λ τ / 1
/ + \ Yes v
<test+set fr REC/TR?> >o
/ + \ Yes v +
<test+set fr SEARCH?> >o
x + / v
IsI0I + + +
! I set ! I 1 semaphore I
I + + +
ν ν
o<
0<
lset
inh
inh
access ibit
/reset sema=\
<phore frm any>
ν \ process ? /
<phore frm any>
ν \ process ? /
vYes
reset I
semaphore I
semaphore I
No
-+—>o I I
v ■o<V V
-o<--o
ι , , Ml M , 1|Μ β
i goto
next clock per I MJMJ mm ^- ^- t^ ^ w^ _ VH —· -β tm· _ «— ·Χ
ν
0-
0-
Im obiqen Flussdiagramm wurden die Abkuerzungen verwendet
- INT-HA for INTERRUPT-HANDLING
- REC/TR for RECEIVE/TRANSMIT and
- per for period.
-U-
INHALTSVERZEICHNIS SEITE
1. Stand der Technik
2. Nachteile des Stands der Technik
3. Vorteile der Erfindunq.
4. Ausf uehrungsbe ispiel 9
4.1. Auflistung der einzelnen Figuren der Zeichnung.. 10
4.2. Physikalische Realisierung.. 10
4.3. Uebertragungsprotokol I 14
4.4. Bus-Organisation.......... 18
4.5. Zustandsdi agramme 20
4.5.1. Erlaeuterungen zu den Zustandsgraphen.... 20
4.5.2. BeschreibunqsbeispieI fuer den Zustand
BUS-IDLE ...'. 23
BUS-IDLE ...'. 23
4.5.3. Zustandsdiagramm EMPFANGS-MODUS 24
4.5.4. Zust andsd iagramm SENDE-MODUS 29
4.5.5. Zustandsdiagramni FEHLERBEHANDLUNG...... .. 33
4.6. Fehlerbehandlung.. 34
4.6.1. Fehlereaktion....... 35
4.6.2. Fehlerauf treten.......................... 35
4.6.3. Fehlerklassen............................ 37
4.6.4. Erlaeuterungen zu den Beispielen......... 39
4.6.5. Beispiele EinzeIbitfehler................ 40
4.6.5.1. Globale Stoerung» von allen
Teilnehmern entdeckbar.
Teilnehmern entdeckbar.
Bitfehler im IDENTIFIER 40
INHALTSVERZEICHNIS SEITE
4.6.5.2. Fehler tritt an einem Teil der Empfaenger und am Sender bzw.
an Station mit Sendewunsch
auf. Stuffehler im DATA-FIELD... 42
4.6.5.3. Fehler tritt an einem Teil der Empfaenger und am Sender bzw.
an Station mit Sendewunsch
auf. Bitfehler im ACK-SLOT 43
4.6.5.4. Nur der Sender wird gestoert.
Fehler in BUS-IDLE 44
4.6.5.5. Stoerunq nur am Sender.
Stuf fehler im DATA-FIELD 45
4.6.5.6. Fehler tritt an allen
Empfaengern auf j aber nicht am Sender bzw. an Station mit Sendewunsch auf. Bitfehler im CONTROLL-FIELD? Laengenangabe verfaelscht..................... 46
Empfaengern auf j aber nicht am Sender bzw. an Station mit Sendewunsch auf. Bitfehler im CONTROLL-FIELD? Laengenangabe verfaelscht..................... 46
4.6.5.7. Fehler tritt an einem Teil der Empfaeger auf» aber nicht am
Sender bzw. an Station mit Sendewunsch. Bitfehler in
BUS-IDLE 46
4.6.5.S. Fehler tritt an einem Teil der
Empfaeger auf? aber nicht am Sender bzw. an Station mit Sendewunsch. Stuffehler in
DATA-FIELD 4?
4.7. INTERFACE-MANAGEMENT-PROCESSOR (IMP) 50
4.7.1. Konfiguration............................ 50
4.7.1.1. Allgemeines Konzept............. 50
4.7.1.1.1. Struktur 50
4.7.1.1.2. Prioritaet der Botschaften.... 50
4.7.1.1.3. Akzeptanzfilter.......... 51
4.7.1.1.4. Warteschlange der
Botschaften» die gesendet
Botschaften» die gesendet
werden sol I 51
INHALTSVERZEICHNIS SEITE
4.7.1.1.5. Warteschlange empfangenen
Botschaften ....... 51
4.7.1.2. DPRAM Organisation 52
4.7.1.3. CONTROL-SESMENT Organisation.... 53
4.7.1.4. Funktion des DPRAM 54
4.7.1.4.1. DATA-BYTE-CODE 54
4.7.1.4.2. PENDING 55
4.7.1.4.3. INTERRUPT-ENABLE 55
4.7.1.4.4. INTERRUPT-RESUEST. 56
4.7.1.4.5. TRANSMISSION-COUNT...... 56
4.7.1.4.6. TRANSMISSION-REQUEST 56
4.7.1.4.7. RECEIVE/TRANSMIT... 57
4.7.2. Datenaustausch CPU-DPRAM. 57
4.7.2.1. Synchronisations Protal em........ 57
4.7.2.2. Nicht synchrone Operation.. 58
4.7.2.3. Software Synchronisation........ 58
4.7.2.3.1. Abfragen einer Sequenznummer.. 58
4.7.2.3.2. Abfragen des
INTERRUPT-REQUEST 58
INTERRUPT-REQUEST 58
4.7.2.3.3. Interrupt gesteuerte
Bearbeitung................... 59
Bearbeitung................... 59
4.7.2.3.4. Block Uebertragung 59
4.7.2.3.5. Doppelter Empfangspuffer...... 60
4.7.2.4. Hardware Synchronisation........ 60
4.7.3. Datenaustausch DPRAM - Schieberegister... 60
4.7.3.1. Parallele Steuerprozesse........ 60
INHALTSVERZEICHNIS SEITE
4.7.3.2. LOAD-Prozess. 62
4.7.3.3. STORE-Prosess 64
4.7.3.4. ERROR-Prozess 66
4.7.3.5. RECEIVE/TRANSMIT-Prosess 67
4.7.3.6. SEARCH-Prozess 68
4.7.3.7. INTERRUPT-HANDLING-Prozess 70
4.7.4. Steuerung des Zugriffs sum DPRAM 71
4.7.4.1. Zugriffssynchronisation 71
4.7.4.2. DPRAM-Adresszeiger. . . . 72
4.7.4.3. Priori taetssteuerung. 73
5. Zeichnungen. 76
5.1. Ausfuehrungsbeispiel fuer lineare Busstruktur... 76
5.2. Beispiel fuer galvanisch gekoppelteasymmetrische
Ansteuerung der Busleitung........ 77
5.3. Beispiel fuer galvanisch gekoppelte»
symmetrische Ansteuerung der Busleitung......... 77
5.4. Beispiel fuer galvanisch getrennte?
symmetrische Ansteuerung mit Uebertrager 78
5.5. Ausfuehrungsbeispiel fuer Lichtleiter - Stern... 78
5.6. Ausfuehrungsbeispiel fuer Lichtleiter - Bus..... 79
5.7. Aufbau einer Botschaft................... 80
5.8. Aufbau CONTROL-FIELD 81
5.9. Aufbau CRC-FIELD 81
5.10. Aufbau einer Fehlermeldung.... 82
5.11. Blockschaltbild des seriellen Schnittstellen
- Leerseite -
Claims (1)
- 6, AnspruecheVerfahren zum Betreiben einer Datenverarbeitungsanlage fuer Kraftfahrzeuge mit wenigstens zwei Rechnern» einer die Rechner verbindenden Leitung zum l^ebertragen von Botschaften (Messages)? dadurch gekennzeichnet» dass sich die Botschaften bezueglich Inhalt und Bedeutung mittels eines Identifizieres selbst identifizieren.Verfahren nach Anspruch 1? dadurch gekennzeichnet» dass dem Identifizierer eine Prioritaet insbesondere fuer die Reihenfolge der Uebertragung der Botschaften auf der Leitung zugecdnet ist.3. Verfahren nach Anspruch 2» dadurch gekennzeichnet? dass der Identifizierer mit impliziter Prioritaetenangabe vorzugsweise am Anfang der Botschaft steht.4. Verfahren nach Anspruch 1? dadurch gekennzeichnet» dass der Identifizierer Inhalte wie Adressen» Daten» Ssnsorsignaleι SteIIgroessen» Zwischenergebnisse» Befehle fuer Synchronisation» Befehle zum Auslpesen von Aktionen kennzeichnet.5. Verfahren nach Anspruch 1> dadurch gekennzeichnet» dassder Identifizierer Inhalte wie Drehzahl» Drehzahlgradient»Motortempeiatur» Last der Antriebsmaschine usw. kennzeichnet.6. Verfahren nach Anspruch 1» dadurch gekennzeichnet» dass dsr Identifizierer Befehlsdaten » zum Beispiel von einer Antib lockiereinrichtung? einer Antischlupfeinrichtung usw. kennzeichnet.Verfahren zum Betreiben einer Datenverarbeitungsanlage fuer Kraftfahrzeuge mit wenigstens zwei Rechnern» einer die Rechner verbindenden Leitung zum Uebertragen von Botschaften (Messages) und einer Fehlererkennung bezueglich der Botschaft» dadurch'gekennzeichnet» dass die Botschaft mit einem definierten Bitmuster (wenigstens ein Bit) anfaengt» dieses Bitmuster mit in den CRC-Check mit einbezogan wird und dass auf den CRC-Check (Kontrollwort) ein Bitmuster folgt» das zum Anfangsbitmuster komplementaer ist.8. Verfahren nach Anspruch 7» dadurch gekennzeichnet» dass das zur Berechnung des Kontrollworts benuzte Generator-Polynom so gestaltet wird» dass vorzugsweise einBCH-Code (Bose» Chaudhure» Hocquenghem) mit dem Restklassen - Polynom (X + 1 ) multipliziert wird.Verfahren zum Betreiben einer Datenverarbeitungsanlage fuer Kraftfahrzeuge mit wenigstens zwei Rechnern? einer die Rechner verbindenden Leitung zum Uebertragen von Botschaften (Messages) und einer Fehlermeldung (error report) »dadurch gekennzeichnet» dass auf die Leitung (Bus) dominate und rezessive Zustaende uebertragen werden und dass die Fehlermeldung aus einer einzigen» mit der bei der Uebertragung der Botschaft auftretenden Zustandsfolge nicht zu verwechselnden Zustandsfolge dominanter Zustaende besteht.10. Verfahren nach Anspruch 9» dadurch gekennzeichnet» dass die Fehlermeldung zu jedem beliebigen Zeitpunkt (zB. waehrend der laufenden Uebertragung einer Botschaft) gesendet werden kann.11. Verfahren nach Anspruch 9» dadurch gekennzeichnet» dass jeder Teilnehmer» der mit der Leitung gekoppelt ist? eine Fehlermeldung abgeben kann.12. Verfahren nach Anspruch 9» dadurch gekennzeichnet» dass das EnHs der Fehlermeldung zur zeitlichen Synchronisation aller Teilnehmer dient.13. Verfahren nach Anspruch 12» dadurch gekennzeichnet» dass bei mehreren Fehlermeldungen das Ende der letzten der Synchronisation dient.14. Verfahren nach Anspruch 9» dadurch gekennzeichnet» dass der informationstragende Teil der Botschaft mit einer nicht dominanten Zustandsfolge abgeschlossen wird» sodass im Fshlsrfall die aus dominanten Zustaenden bestehende Fehlermeldung zeitlich in die Uebertragung der nicht dominanten Zustandsfο Ige trifft und dadurch eindeutig die fehlerhafte Botschaft bestimmt ist.15. Verfahren nach Anspruch 9» dadurch gekennzeichnet» dass die nicht dominante Zustandsfolge am Ende der Botschaft um mindestens einen Zustand laenger ist als die fuer die Fehlererkennung erforderliche minimale Zustandsfolge.16. Verfahren zum Betreiben einer Datenverarbeitungsanlage fuer Kraftfahrzeuge mit weniqstens zwei Rechnern» einerdie Rechner verbindenden Leitung zum Uebertragen von Botschaften (Messages) ?dadurch gekennzeichnet» dass jeder Teilnehmer alle Botschaften empfaengt und nur die fuer ihn relevanten Botschaften weiter verarbeitet? indem jeder Teilnehmer eine Liste der fuer ihn relevanten Botschaften fuehrt und Teile der empfangenen Botschaften mit den in der Liste enthaltenen Informationen in Beziehung bringt.17. Verfahren nach Anspruch 16? dadurch gekennzeichnet» dass das in Beziehung bringen so erfolgt? dass alle Teilnehmer zum gleichen Rasterpunkt der Signaluebertragung die Entscheidung treffen koennen? ob die spezielle Botschaft weiter verfolgt wird.18. Verfahren nach Anspruch 16» dadurch gekennzeichnet? dass die in den Botschaften enthaltenen Informationen in Abhaengigkeit von der in jedem Teilnehmer vorliegenden Liste in Speicherzellen uebertragbar sind und dem Teilnehmer zur Weiterverarbeitung zur Verfuegung stehen.19. Verfahren nach Anspruch 18? dadurch gekennzeichnet? dass abhaengig vom Listeninhalt beim Empfang einer Botschaft eine Unterbrechungsanforderung ausloesbar ist.20. Verfahren nach Anspruch 18? dadurch gekennzeichnet? dass die Uebernahme der Botschaft erst nach fehlerfreiem insbesondere durch alle Teilnehmer erfolgt.21. Verfahren nach Anspruch 18? dadurch
die Informationsannahme blockierbargekennzeichnet?
ist.Verfahren nsch Anspruch 16? dadurch die Reihenfolge der Liste Weiterverarbeitung im Teilnehmer ist.gekennzeichnet? dassfuer die interne priori taetsbest immend23. Verfahren nach Anspruch 16? dadurch gekennzeichnet? dass die Weitergabe von Informationen? insbesondere die Abspeicherung? so erfolgt? dass inhaltlich zusammenhaengende Informationsteile im zugehoerigen Informat ionsverarbe i tungsvorgang zusammengehoerig verarbeitet werden koennen (Konsistenz der Informationsbehandlung).24. Verfahren nach Anspruch 16? dadurch gekennzeichnet? dass in jedem Zeitpunkt die Rangfolge der Liste die Prioritaet der Ueiterverarbeitung bestimmt.BAD ORIGINAL25. Verfahren sum Betreiben einer Datenverarbeitungsanlage fuer Kraftfahrzeuge mit wenigstens zwei Rechnern» einer die Rechner verbindenden Leitung zum Uebertragen von Botschaften (Messages) »dadurch gekennzeichnet» dass jeder Teilnehmer den zu uebertragenden Botschaften mittels einer Liste eine Prioritaet zuordnet und in jedem Zeitpunkt die Liste die Prioritaet der im Teilnehmer zur Uebertragung bereitstehenden Botschaften bestimmt.Ib. Verfahren nach Anspruch 25? dadurch gekennzeichnet» dass der Liste weitere Informationen insbesondere bezueglich des Uebertragungszustandes zugeordnet sind.27. Verfahren nach Anspruch 25» dadurch gekennzeichnet» dass fehlerbshaftste Uebertragungen erfasst und registriert werden.28. Verfahren nach Anspruch 27? dadurch gekennzeichnet» dass die Uebertragung bei auftretendem Fehler wiederholt wird.29. Verfahren nach Anspruch 28» dadurch gekennzeichnet» dass nach einer vorbestimmten Anzahl von fehlerhaften Usbertragungen die Wiederholung der Uebertragung abgebrochen wird und eine Unterbrechungsanforderung ausgaloest werden kann.30. Verfahren nach Anspruch 25» dadurch gekennzeichnet» dass die Liste eine Information bezueglich Uebertr3gungsanforderungen enthaelt» die vom Teilnehmer selbst und auch von den uebrigen mit der Leitung gekoppelten Einrichtungen bestimmt werden kann.31. Verfahren zum Betreiben einer Datenverarbeitungsanlage fuer Kraftfahrzeugs mit wenigstens zwei Rechnern» einer die Rechner verbindenden Leitung zum Uebertragen von Botschaften (Messages) »dadurch gekennzeichnet» dass jedem Teilnahmer ein bestimmter Teil der Uebertragungskapazitaet der Leitung zugeordnet wird.32. Verfahren zum Betreiben einer Datenverarbeitungsanlage fuer Kraftfahrzeuge mit wenigstens zwei Rechnern» einer die Rechner verbindenden Leitung zum Uebertragen von Botschaften (Messages) »dadurch gekennzeichnet» dass nach dsm Auftreten einer bestimmten Anzahl von Fehlermeldungen eines bestimmten Teilnehmers sich dieser Teilnehmer sendesignalmaesig von der Leitung abkoppelt.33. Verfahren zur Uebertragung von zweiwertigen InformationenBAD(O und 1) im Kraftfahrzeugi dadurch gekennzeichnetj dass die von einem konstanten Signalpegel (0) abweichende Information Cl) mit alternierenden Signalpegeln (+!-) uebertragbar ist.34. Verfahren nach Anspruch 33» dadurch gekennzeichnetj dass die alternierenden Signalpegel zur Fehlererkennung uetasrwachbar sind.
Priority Applications (14)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE3546683A DE3546683C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
| DE19853506118 DE3506118A1 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge |
| DE3546664A DE3546664C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
| DE3546684A DE3546684C2 (en) | 1985-02-22 | 1985-02-22 | Operating communication bus network for processors |
| DE3546662A DE3546662C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
| FR8517780A FR2578070B1 (fr) | 1985-02-22 | 1985-12-02 | Procede pour faire fonctionner une installation de traitement de donnees pour des vehicules a moteur |
| JP61031033A JP2545508B2 (ja) | 1985-02-22 | 1986-02-17 | 車両に対するデータ処理装置の作動方法およびデータ処理装置 |
| US06/831,475 US5001642A (en) | 1985-02-22 | 1986-02-20 | Method for operating a data processing system |
| US07/856,430 US5303348A (en) | 1985-02-22 | 1992-03-23 | Method of arbitrating access to a data bus and apparatus therefor |
| JP5302049A JPH0721784B2 (ja) | 1985-02-22 | 1993-12-01 | データ処理装置に対する伝送すべきメッセージの処理方法 |
| JP5302048A JPH0772883B2 (ja) | 1985-02-22 | 1993-12-01 | データ処理装置におけるエラーのあるメッセージの処理方法 |
| US08/185,024 US5640511A (en) | 1985-02-22 | 1994-01-24 | Method of arbitrating access to a data bus and apparatus therefor |
| US08/464,383 US5621888A (en) | 1985-02-22 | 1995-06-05 | Method of building up messages for driving a data processing arrangement with several stations receiving connected thereto |
| US08/465,059 US5901156A (en) | 1985-02-22 | 1995-06-05 | Method of processing messages to be transmitted for a data processing arrangement |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE19853506118 DE3506118A1 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| DE3506118A1 true DE3506118A1 (de) | 1986-08-28 |
| DE3506118C2 DE3506118C2 (de) | 1991-01-03 |
Family
ID=6263209
Family Applications (4)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| DE3546662A Expired - Lifetime DE3546662C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
| DE3546683A Expired - Lifetime DE3546683C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
| DE3546664A Expired - Lifetime DE3546664C3 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
| DE19853506118 Granted DE3506118A1 (de) | 1985-02-22 | 1985-02-22 | Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge |
Family Applications Before (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| DE3546662A Expired - Lifetime DE3546662C3 (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 |
| DE3546664A Expired - Lifetime DE3546664C3 (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 (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE3926165A1 (de) * | 1989-08-08 | 1991-02-14 | Bodenseewerk Geraetetech | Sender- und empfaengeranordnung als schnittstelle zu einem mikroprozessor |
| DE4028926A1 (de) * | 1990-09-12 | 1992-03-19 | Teves Gmbh Alfred | Schaltungsanordnung zur steuerung von elektrischen oder elektromechanischen verbrauchern |
| DE4214303A1 (de) * | 1991-04-30 | 1992-11-12 | Mitsubishi Electric Corp | Kommunikationssystem |
| EP0382794B1 (de) * | 1988-08-06 | 1994-05-18 | Robert Bosch Gmbh | Netzwerkschnittstelle |
| 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 |
| WO1998011700A1 (de) * | 1996-09-12 | 1998-03-19 | Robert Bosch Gmbh | Verfahren zur kontrolle der verbindungen eines übertragungssystems und komponente zur durchführung des verfahrens |
| WO1999050100A1 (de) * | 1998-03-28 | 1999-10-07 | Robert Bosch Gmbh | Verfahren zur datenübertragung in einem über eine busleitung vernetzten rückhaltesystem |
| US6208924B1 (en) | 1996-04-24 | 2001-03-27 | Robert Bosch Gmbh | Bus system for data transfer |
| EP1168119A2 (de) * | 2000-06-20 | 2002-01-02 | Bayerische Motoren Werke Aktiengesellschaft | Steuergerät mit einem Hauptmikroprozessor und mit einer Prozessorschnittstelle zu einer Bus-Sende-Empfangseinheit |
| US6567476B2 (en) | 1996-07-24 | 2003-05-20 | Robert Bosch Gmbh | Data synchronisation process, and transmission and reception interfaces |
| US6636100B1 (en) | 1999-06-29 | 2003-10-21 | Mitsubishi Denki Kabushiki Kaisha | Can controller and one-chip computer having a built-in can controller |
| DE4028809B4 (de) * | 1990-09-11 | 2005-03-10 | Bosch Gmbh Robert | System zur Steuerung eines Kraftfahrzeugs |
| 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 |
| DE4219669B4 (de) * | 1992-06-16 | 2007-08-09 | Robert Bosch Gmbh | Steuergerät zur Berechnung von Steuergrößen für sich wiederholende Steuervorgänge |
| US7340380B2 (en) | 2001-07-17 | 2008-03-04 | Robert Bosch Gmbh | Method and device for the exchange and processing of data into fusion data |
Families Citing this family (127)
| 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 | 三菱農機株式会社 | 移動農機の制御装置 |
| 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 | 株式会社日立製作所 | マルチプロセッサシステムにおけるデータ処理方法 |
| 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 |
| 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 |
| 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 |
| DE59202560D1 (de) * | 1991-11-26 | 1995-07-20 | Siemens Ag | Bussystem. |
| DE4140017C2 (de) * | 1991-12-04 | 1995-01-05 | Nec Electronics Germany | Verfahren zum Betreiben von über einen Datenbus durch seriellen Datenaustausch miteinander kommunizierenden Rechnereinheiten |
| JP2700843B2 (ja) * | 1991-12-10 | 1998-01-21 | 三菱電機株式会社 | 多重通信制御装置 |
| DE4213134B4 (de) * | 1992-04-21 | 2006-03-02 | Robert Bosch Gmbh | Netzwerkschnittstelle mit Wiederzuschaltvorrichtung zum schnelleren Verlassen eines passiven Zustandes |
| JP3266331B2 (ja) * | 1992-10-09 | 2002-03-18 | 富士通株式会社 | 出力回路 |
| US6151689A (en) * | 1992-12-17 | 2000-11-21 | Tandem Computers Incorporated | Detecting and isolating errors occurring in data communication in a multiple processor system |
| JPH06236352A (ja) * | 1993-02-09 | 1994-08-23 | Nippondenso Co Ltd | データ通信装置 |
| DE4340048A1 (de) * | 1993-11-24 | 1995-06-01 | Bosch Gmbh Robert | Vorrichtung zum Austauschen von Daten und Verfahren zum Betreiben der Vorrichtung |
| JP3892052B2 (ja) * | 1993-12-01 | 2007-03-14 | 株式会社デンソー | エンジン用制御装置 |
| DE69512443T2 (de) * | 1994-02-02 | 2000-05-04 | Mannesmann Vdo Ag | Elektronisches System eines Kraftfahrzeugs mit zwischen zwei verschiedenen Bussen gelegener Schnittstellenschaltung |
| 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 | 株式会社デンソー | 車両用発電装置 |
| JP3183181B2 (ja) * | 1996-08-28 | 2001-07-03 | トヨタ自動車株式会社 | 情報送信方法 |
| US5813972A (en) * | 1996-09-30 | 1998-09-29 | Minnesota Mining And Manufacturing Company | Medical perfusion system with data communications network |
| US6164920A (en) * | 1996-09-30 | 2000-12-26 | Minnesota Mining And Manufacturing Company | Perfusion system with control network |
| US5752931A (en) * | 1996-09-30 | 1998-05-19 | Minnesota Mining And Manufacturing Company | Perfusion system with perfusion circuit display |
| US5995512A (en) * | 1997-01-17 | 1999-11-30 | Delco Electronics Corporation | High speed multimedia data network |
| JP3117000B2 (ja) * | 1997-02-21 | 2000-12-11 | 株式会社デンソー | 通信システムおよびそれに使用される電子制御装置 |
| FR2764098B1 (fr) * | 1997-05-27 | 1999-08-20 | Peugeot | Procede et dispositif de controle des acces a un champ de donnees destine a etre emis sur un reseau de transmission d'informations |
| FR2764149B1 (fr) * | 1997-05-27 | 1999-08-27 | Peugeot | Procede et dispositif de validation/invalidation d'un message emis sur un reseau de transmission d'informations par reponse dans une trame de communication |
| US6175603B1 (en) * | 1997-08-07 | 2001-01-16 | Cisco Technology, Inc. | System for managing signals in different clock domains and a programmable digital filter |
| US6256677B1 (en) * | 1997-12-16 | 2001-07-03 | Silicon Graphics, Inc. | Message buffering for a computer-based network |
| 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 |
| US6507810B2 (en) | 1999-06-14 | 2003-01-14 | Sun Microsystems, Inc. | Integrated sub-network for a vehicle |
| US6253122B1 (en) | 1999-06-14 | 2001-06-26 | Sun Microsystems, Inc. | Software upgradable dashboard |
| US6754183B1 (en) | 1999-06-14 | 2004-06-22 | Sun Microsystems, Inc. | System and method for integrating a vehicle subnetwork into a primary network |
| US6362730B2 (en) | 1999-06-14 | 2002-03-26 | Sun Microsystems, Inc. | System and method for collecting vehicle information |
| US6975612B1 (en) | 1999-06-14 | 2005-12-13 | Sun Microsystems, Inc. | System and method for providing software upgrades to a vehicle |
| US6370449B1 (en) * | 1999-06-14 | 2002-04-09 | Sun Microsystems, Inc. | Upgradable vehicle component architecture |
| US6427180B1 (en) * | 1999-06-22 | 2002-07-30 | Visteon Global Technologies, Inc. | Queued port data controller for microprocessor-based engine control applications |
| US6728268B1 (en) * | 1999-06-22 | 2004-04-27 | Trimble Navigation Ltd. | Method and system to connect internet protocol hosts via an application specific bus |
| 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 |
| 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 |
| EP1356352B1 (de) * | 2000-12-29 | 2006-06-14 | 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 |
| 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 |
| US6772733B2 (en) | 2001-10-19 | 2004-08-10 | Visteon Global Technologies, Inc. | Optically controlled IPCS circuitry |
| 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 |
| US20030095675A1 (en) * | 2001-10-19 | 2003-05-22 | Marlow C. Allen | Light communication channel-based voice-activated control system and method for implementing thereof |
| 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 |
| KR101264761B1 (ko) * | 2004-02-10 | 2013-05-15 | 가부시키가이샤 한도오따이 에네루기 켄큐쇼 | 비휘발성 메모리와 그것을 내장하는 ｉｃ 카드, ｉｄ 카드 및 ｉｄ 태그 |
| DE102004013629B4 (de) * | 2004-03-19 | 2023-06-01 | Volkswagen Ag | Kommunikationssystem für ein Kraftfahrzeug |
| US20090213915A1 (en) * | 2004-06-30 | 2009-08-27 | Koninklijke Philips Electronics N.V. | Method for the non-bitrate-dependent encoding of digital signals on a bus system |
| FR2876482B1 (fr) * | 2004-10-07 | 2007-01-12 | Siemens Transp Systems Soc Par | Dispositif d'envoi de commande de sortie securisee |
| JP4531555B2 (ja) * | 2004-12-27 | 2010-08-25 | ルネサスエレクトロニクス株式会社 | データ処理モジュール及びその送付候補メッセージの決定方法 |
| JP4594124B2 (ja) | 2005-02-07 | 2010-12-08 | ルネサスエレクトロニクス株式会社 | 通信システム及び通信方法 |
| JP2006236047A (ja) * | 2005-02-25 | 2006-09-07 | Renesas Technology Corp | 半導体集積回路装置 |
| JP4721741B2 (ja) * | 2005-03-25 | 2011-07-13 | ルネサスエレクトロニクス株式会社 | データ処理モジュール及びそのメッセージ受信方法 |
| DE102005014783A1 (de) * | 2005-03-31 | 2006-10-05 | Siemens Ag | Verfahren und Vorrichtungen zum Übertragen von Daten auf eine Datenleitung zwischen einem Steuergerät und zumindest einem dezentralen Datenverarbeitungsgerät |
| JP2007034892A (ja) * | 2005-07-29 | 2007-02-08 | Nec Electronics Corp | データ処理モジュール及びそのメッセージ送信終了処理方法 |
| US7769932B2 (en) * | 2005-09-09 | 2010-08-03 | Honeywell International, Inc. | Bitwise arbitration on a serial bus using arbitrarily selected nodes for bit synchronization |
| US7680144B2 (en) * | 2006-09-12 | 2010-03-16 | Honeywell International Inc. | Device coupled between serial busses using bitwise arbitration |
| US8402268B2 (en) * | 2009-06-11 | 2013-03-19 | Panasonic Avionics Corporation | System and method for providing security aboard a moving platform |
| US8327189B1 (en) | 2009-12-22 | 2012-12-04 | Emc Corporation | Diagnosing an incident on a computer system using a diagnostics analyzer database |
| CN102971214B (zh) | 2010-04-27 | 2016-01-13 | 松下航空电子公司 | 用于用户接口设备的连接支撑系统及方法 |
| US8897974B2 (en) * | 2010-06-07 | 2014-11-25 | Gm Global Technology Operations, Llc | Gear selector system |
| JPWO2012132217A1 (ja) * | 2011-03-31 | 2014-07-24 | ルネサスエレクトロニクス株式会社 | Ｃａｎ通信システム、ｃａｎ送信装置、ｃａｎ受信装置、およびｃａｎ通信方法 |
| JP2013058845A (ja) * | 2011-09-07 | 2013-03-28 | Denso Corp | データ通信方法及びデータ通信システム |
| JP5532030B2 (ja) * | 2011-09-07 | 2014-06-25 | 株式会社デンソー | データ通信方法及びデータ通信装置 |
| US9577788B2 (en) | 2011-06-15 | 2017-02-21 | Denso Corporation | Coding apparatus, coding method, data communication apparatus, and data communication method |
| 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 |
| 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 |
| 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 |
| WO2015191053A1 (en) * | 2014-06-10 | 2015-12-17 | Halliburton Energy Services, Inc. | Synchronization of receiver units over a control area network bus |
| JP6282216B2 (ja) | 2014-11-20 | 2018-02-21 | 国立大学法人名古屋大学 | 通信システム及び通信装置 |
| US9590898B2 (en) * | 2015-02-17 | 2017-03-07 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system to optimize packet exchange between the control and data plane in a software defined network |
| US10635619B2 (en) * | 2016-10-12 | 2020-04-28 | Cirrus Logic, Inc. | Encoding for multi-device synchronization of devices |
| JP2018082247A (ja) * | 2016-11-14 | 2018-05-24 | 株式会社東芝 | 通信装置、通信システム、通信方法及びプログラム |
| 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数据交互方法和系统 |
| DE112022000540T5 (de) | 2021-03-01 | 2024-03-14 | Rohm Co., Ltd. | Verzögerungssignal-erzeugungsschaltung, sendeschaltung, elektronische steuereinheit und fahrzeug |
| WO2022185782A1 (ja) | 2021-03-01 | 2022-09-09 | ローム株式会社 | 送信回路、電子制御ユニット、及び車両 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CH527547A (de) * | 1971-08-13 | 1972-08-31 | Ibm | Verfahren zur Informationsübertragung mit Prioritätsschema in einem Zeitmultiplex-Nachrichtenübertragungssystem mit Ringleitung |
| DE1449532C3 (de) | 1962-11-30 | 1978-12-07 | Burroughs Corp., Detroit, Mich. (V.St.A.) | |
| DE3114734A1 (de) | 1981-04-11 | 1982-10-28 | Licentia Patent-Verwaltungs-Gmbh, 6000 Frankfurt | Einrichtung zur datenuebertragung zwischen einem rechner und externen teilnehmern |
| US4366479A (en) | 1980-02-08 | 1982-12-28 | Hitachi, Ltd. | Control information communication method and system through a common signal transmission line |
| US4482951A (en) | 1981-11-12 | 1984-11-13 | Hughes Aircraft Company | Direct memory access method for use with a multiplexed data bus |
Family Cites Families (53)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB1168476A (en) * | 1966-05-17 | 1969-10-29 | British Telecomm Res Ltd | Improvements in or relating to data transmission systems |
| 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 |
| EP0023105A1 (de) * | 1979-07-06 | 1981-01-28 | WARD & GOLDSTONE LIMITED | System und Verfahren zur Verarbeitung von Multiplexinformation |
| JPS6041372B2 (ja) * | 1979-07-19 | 1985-09-17 | 株式会社明電舎 | 複数のデ−タ処理装置の接続方式 |
| US4275095A (en) * | 1979-07-31 | 1981-06-23 | Warren Consultants, Inc. | Composite article and method of making same |
| US4319338A (en) * | 1979-12-12 | 1982-03-09 | Allen-Bradley Company | Industrial communications network with mastership determined by need |
| DE3001331A1 (de) * | 1980-01-16 | 1981-07-23 | Robert Bosch Gmbh, 7000 Stuttgart | Einrichtung zum seriellen uebertragenvon daten in und/oder aus einem kraftfahrzeug |
| 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 |
| US4412285A (en) * | 1981-04-01 | 1983-10-25 | Teradata Corporation | Multiprocessor intercommunication system and method |
| 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 |
| 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 |
| US4463445A (en) * | 1982-01-07 | 1984-07-31 | Bell Telephone Laboratories, Incorporated | Circuitry for allocating access to a demand-shared bus |
| JPS58120340A (ja) * | 1982-01-13 | 1983-07-18 | Fujitsu Ltd | フレ−ム伝送方式 |
| JPS5940728A (ja) * | 1982-08-31 | 1984-03-06 | Matsushita Electric Works Ltd | 電力線搬送制御装置 |
| JPS5970851A (ja) * | 1982-10-18 | 1984-04-21 | Caterpillar Mitsubishi Ltd | 油圧補機装備車輌の用途別負荷に対応した運転指令装置 |
| JPS5991527A (ja) * | 1982-11-17 | 1984-05-26 | Hitachi Ltd | バス優先制御方式 |
| JPS59110245A (ja) * | 1982-12-15 | 1984-06-26 | Meidensha Electric Mfg Co Ltd | マルチドロツプ方式の情報伝送方式 |
| CA1219091A (en) * | 1983-01-10 | 1987-03-10 | Ulrich Killat | Method of and arrangement for controlling access to a time-division multiplex message transmission path |
| JPH0612895B2 (ja) * | 1983-01-24 | 1994-02-16 | 株式会社東芝 | 情報処理システム |
| US4534025A (en) * | 1983-02-24 | 1985-08-06 | United Technologies Automotive, Inc. | Vehicle multiplex system having protocol/format for secure communication transactions |
| JPS59175242A (ja) * | 1983-03-25 | 1984-10-04 | Ricoh Co Ltd | Ａｒｑ伝送方式 |
| US4561092A (en) * | 1983-05-13 | 1985-12-24 | The Bdm Corporation | Method and apparatus for data communications over local area and small area networks |
| US4556943A (en) * | 1983-05-27 | 1985-12-03 | Allied Corporation | Multiprocessing microprocessor based engine control system for an internal combustion engine |
| JPS60551A (ja) * | 1983-06-16 | 1985-01-05 | Hitachi Ltd | 自動車用データ伝送システム |
| DE3335932A1 (de) * | 1983-10-04 | 1985-04-18 | Wabco Westinghouse Fahrzeugbremsen GmbH, 3000 Hannover | Einrichtung zum abfragen und steuern von mehreren komponeneten eines fahrzeuges |
| JPS59112045A (ja) * | 1983-11-17 | 1984-06-28 | 村田機械株式会社 | 紡績糸 |
| US4566097A (en) * | 1983-12-23 | 1986-01-21 | International Business Machines Corp. | Token ring with secondary transmit opportunities |
| US4652873A (en) * | 1984-01-18 | 1987-03-24 | The Babcock & Wilcox Company | Access control for a plurality of modules to a common bus |
| US4654655A (en) * | 1984-03-02 | 1987-03-31 | Motorola, Inc. | Multi-user serial data bus |
| CA1246681A (en) * | 1985-01-30 | 1988-12-13 | Northern Telecom Limited | Terminal address assignment in a broadcast transmission system |
| DE3546662C3 (de) * | 1985-02-22 | 1997-04-03 | Bosch Gmbh Robert | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
| JPS61232363A (ja) * | 1985-04-05 | 1986-10-16 | Honda Motor Co Ltd | 内燃エンジンの電子制御装置 |
| US4745600A (en) * | 1985-07-09 | 1988-05-17 | Codex Corporation | Network collision detection and avoidance apparatus |
| EP0208998A3 (de) * | 1985-07-19 | 1989-01-04 | Rodger T. Lovrenich | Dezentralisiertes Steuerungssystem und Verbindung dazu |
| US4715031A (en) * | 1985-09-23 | 1987-12-22 | Ford Motor Company | Vehicular data transfer communication system |
| CA1249886A (en) * | 1986-05-02 | 1989-02-07 | Claude J. Champagne | Method of duplex data transmission using a send-and- wait protocol |
| US4769761A (en) * | 1986-10-09 | 1988-09-06 | International Business Machines Corporation | Apparatus and method for isolating and predicting errors in a local area network |
| US4887076A (en) * | 1987-10-16 | 1989-12-12 | Digital Equipment Corporation | Computer interconnect coupler for clusters of data processing devices |
| US5131081A (en) * | 1989-03-23 | 1992-07-14 | North American Philips Corp., Signetics Div. | System having a host independent input/output processor for controlling data transfer between a memory and a plurality of i/o controllers |
| GB8915135D0 (en) * | 1989-06-30 | 1989-08-23 | Inmos Ltd | Message routing |
| SE467437B (sv) * | 1990-11-07 | 1992-07-13 | Ericsson Telefon Ab L M | Foerfarande att undvika interferens mellan ett foersta och ett andra meddelande i ett mobiltelefonsystem |
| 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 DE3546683A patent/DE3546683C3/de not_active Expired - Lifetime
- 1985-02-22 DE DE3546664A patent/DE3546664C3/de not_active Expired - Lifetime
- 1985-02-22 DE DE19853506118 patent/DE3506118A1/de active Granted
- 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
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE1449532C3 (de) | 1962-11-30 | 1978-12-07 | Burroughs Corp., Detroit, Mich. (V.St.A.) | |
| CH527547A (de) * | 1971-08-13 | 1972-08-31 | Ibm | Verfahren zur Informationsübertragung mit Prioritätsschema in einem Zeitmultiplex-Nachrichtenübertragungssystem mit Ringleitung |
| US4366479A (en) | 1980-02-08 | 1982-12-28 | Hitachi, Ltd. | Control information communication method and system through a common signal transmission line |
| US4366479B1 (de) | 1980-02-08 | 1992-03-10 | Hitachi Ltd | |
| DE3114734A1 (de) | 1981-04-11 | 1982-10-28 | Licentia Patent-Verwaltungs-Gmbh, 6000 Frankfurt | Einrichtung zur datenuebertragung zwischen einem rechner und externen teilnehmern |
| US4482951A (en) | 1981-11-12 | 1984-11-13 | Hughes Aircraft Company | Direct memory access method for use with a multiplexed data bus |
Non-Patent Citations (16)
| Title |
|---|
| DE-B.: FÄRBER, G., Bussysteme, R. Oldenbourg Verlag, München, 1981, S. 100-101 und 119-121 |
| DE-B.: FÄRBER, Georg, Bussysteme, R. Oldenbourg Verlag, München, Wien, 1984, S. 104-108 |
| DE-B.:FÄRBER, Georg, Bussysteme, R. Oldenbourg Verlag, München, Wien, 1984, S. 110-115 |
| DE-Firmenschrift VALVO, Technische Information 811215, 1981 |
| DE-Firmenschrift: D·2·B-Specification, VALVO, Tech. Information für die Industrie, Nr.: 81 1215 * |
| DE-Z.: Elektronik-Applikation, 15. Jg., 1983, Nr. 5, S. 17-24 * |
| DE-Z: "Elektronik", 12/15.6.84, S. 76-81 |
| IEE Conference Publication 229, 4. Int. Conf. on Automotive Electronics, 14.-18. Nov. 1983, Published by the Institution of Electrical Engineers, London und New York, 1983, S. 160-164 * |
| IEE Conference Publication Number 229, 4. Int. Conf. on Automotive Electronics, 14.-18. Nov. 1983, Published by the Institution of Electrical Engineers, London und New York, 1983, S. 160-164 |
| IEE Conference Publication Number 229, 4. Int. Conf. on Automotive Electronics, 14.-18. Nov. 1983, S. 160-164 |
| MOELANDS, A., I2C bus in consumer applications, Philips Electronic Components and Applications, Vol. 5, No. 4, 1983, S. 214-221 |
| US-B.: TANNENBAUM, A., Computer Networks, Prentin/Hall Internatiional, 1983 * |
| US-Z.: INTEL, Microprozessor and Peripheral Handbook, 1983 * |
| VDI-Bericht 515, VDI-Verlag GmbH, Düsseldorf, 1984, S. 231-235 |
| VDI-Berichte 515, Verlag des Vereins deutscher Ingenieure, Düsseldorf 1984, S. 231-235 |
| VDI-Berichte 515, Verlag des Vereins Deutscher Ingenieure, Düsseldorf, 1984, S. 231-235 und 227-230 |
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0382794B1 (de) * | 1988-08-06 | 1994-05-18 | Robert Bosch Gmbh | Netzwerkschnittstelle |
| DE3926165A1 (de) * | 1989-08-08 | 1991-02-14 | Bodenseewerk Geraetetech | Sender- und empfaengeranordnung als schnittstelle zu einem mikroprozessor |
| 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 |
| DE4214303A1 (de) * | 1991-04-30 | 1992-11-12 | Mitsubishi Electric Corp | Kommunikationssystem |
| US5367644A (en) * | 1991-04-30 | 1994-11-22 | Mitsubishi Denki Kabushiki Kaisha | Communication system |
| 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 |
| DE4219669B4 (de) * | 1992-06-16 | 2007-08-09 | Robert Bosch Gmbh | Steuergerät zur Berechnung von Steuergrößen für sich wiederholende Steuervorgänge |
| 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 |
| US6208924B1 (en) | 1996-04-24 | 2001-03-27 | Robert Bosch Gmbh | Bus system for data transfer |
| US6567476B2 (en) | 1996-07-24 | 2003-05-20 | Robert Bosch Gmbh | Data synchronisation process, and transmission and reception interfaces |
| US6643689B2 (en) | 1996-09-12 | 2003-11-04 | Robert Bosch Gmbh | Process and components for controlling the connections of a transmission system |
| WO1998011700A1 (de) * | 1996-09-12 | 1998-03-19 | Robert Bosch Gmbh | Verfahren zur kontrolle der verbindungen eines übertragungssystems und komponente zur durchführung des verfahrens |
| US6449545B1 (en) | 1998-03-25 | 2002-09-10 | Robert Bosch Gmbh | Method for data transfer in a restraint system connected to a bus line |
| WO1999050100A1 (de) * | 1998-03-28 | 1999-10-07 | Robert Bosch Gmbh | Verfahren zur datenübertragung in einem über eine busleitung vernetzten rückhaltesystem |
| US6636100B1 (en) | 1999-06-29 | 2003-10-21 | Mitsubishi Denki Kabushiki Kaisha | Can controller and one-chip computer having a built-in can controller |
| EP1168119A2 (de) * | 2000-06-20 | 2002-01-02 | Bayerische Motoren Werke Aktiengesellschaft | Steuergerät mit einem Hauptmikroprozessor und mit einer Prozessorschnittstelle zu einer Bus-Sende-Empfangseinheit |
| EP1168119A3 (de) * | 2000-06-20 | 2006-01-18 | Bayerische Motoren Werke Aktiengesellschaft | Steuergerät mit einem Hauptmikroprozessor und mit einer Prozessorschnittstelle zu einer Bus-Sende-Empfangseinheit |
| US7340380B2 (en) | 2001-07-17 | 2008-03-04 | Robert Bosch Gmbh | Method and device for the exchange and processing of data into fusion data |
Also Published As
| Publication number | Publication date |
|---|---|
| US5001642A (en) | 1991-03-19 |
| US5303348A (en) | 1994-04-12 |
| JPH06236333A (ja) | 1994-08-23 |
| DE3546662C3 (de) | 1997-04-03 |
| US5901156A (en) | 1999-05-04 |
| DE3546683C3 (de) | 2003-10-09 |
| US5621888A (en) | 1997-04-15 |
| JPS61195453A (ja) | 1986-08-29 |
| DE3546664C2 (en) | 1991-03-07 |
| FR2578070A1 (fr) | 1986-08-29 |
| US5640511A (en) | 1997-06-17 |
| JP2545508B2 (ja) | 1996-10-23 |
| DE3546683C2 (en) | 1991-03-07 |
| JPH06236328A (ja) | 1994-08-23 |
| JPH0721784B2 (ja) | 1995-03-08 |
| DE3546662C2 (en) | 1991-03-07 |
| JPH0772883B2 (ja) | 1995-08-02 |
| FR2578070B1 (fr) | 1994-05-06 |
| DE3506118C2 (de) | 1991-01-03 |
| DE3546664C3 (de) | 1995-10-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| DE3506118A1 (de) | Verfahren zum betreiben einer datenverarbeitungsanlage fuer kraftfahrzeuge | |
| EP2434695B1 (de) | Serielle ringförmige Kommunikationsanordnung und dementsprechendes Verfahren, wobei für die Übermittlung von einem Datenpaket von jedem Slave eine Adressinformation des Datenpakets geändert wird | |
| DE19900245B4 (de) | Vorrichtung und Verfahren zum Senden von Daten von einem USB-Endpunkt an einen USB-Host | |
| EP1298849B1 (de) | Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem | |
| DE69932603T2 (de) | Frühere zuteilung eines vollen zweiweg busses | |
| DE2913288C2 (de) | Multiprozessoranlage mit einer Vielzahl von Prozessorbausteinen | |
| DE69921882T2 (de) | Verfahren zur Entdeckung und Lösung von Datenkorruption in einem UART-basierten Kommunikationsnetzwerk | |
| EP2028797B1 (de) | Verfahren zur Datenübertragung | |
| DE112015004473T5 (de) | Bestätigen der datengenauigkeit in einem verteilten steuerungssystem | |
| DE19900369A9 (de) | Vorrichtung und Verfahren zur Ausführung einer Steuerübertragung auf einem Universal Serial Bus | |
| EP2090031B1 (de) | Verfahren und anordnung zur kommunikation auf einem lin-bus | |
| EP0144403A1 (de) | Verfahren und anordnung zum übertragen von informationen in einem datenring. | |
| WO2014096278A1 (de) | Datenübertragungsprotokoll mit protokollausnahmezustand | |
| US7698485B2 (en) | Round-robin bus protocol | |
| DE102006004191B4 (de) | Deterministisches Kommunikations-System | |
| DE3546684C2 (en) | Operating communication bus network for processors | |
| DE69825636T2 (de) | Verfahren und gerät zum bereitstellen und einschliessen von kontrollinformation in einem bussystem | |
| EP2538618A1 (de) | Verfahren zur Übertragung von Datenpaketen | |
| EP0133577B1 (de) | Datenübertragungsverfahren in einem digitalen Übertragungsnetzwerk und Vorrichtung zur Durchführung des Verfahrens | |
| EP1329057B1 (de) | Verfahren für den Zugriff aauf einen Datenbus zwischen kommunizierenden elektronischen einheiten | |
| DE112005000687B4 (de) | Mechanismus zur Wiederholung von Signalen über eine Verbindung ohne Beziehung | |
| DE112020004896T5 (de) | Übertragungsvorrichtung und kommunikationssystem | |
| DE3500264A1 (de) | Hochgeschwindigkeits-serienbusstruktur und verfahren zur datenuebertragung | |
| DE3500248A1 (de) | Hochgeschwindigkeits-mehrfachbusstruktur und verfahren zur datenuebertragung | |
| DE3500254A1 (de) | Hochgeschwindigkeits-parallelbusstruktur und verfahren zur datenuebertragung |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 8110 | Request for examination paragraph 44 | ||
| 8125 | Change of the main classification |
Ipc: G06F 13/38 |
|
| 8172 | Supplementary division/partition in: |
Ref country code: DE Ref document number: 3546664 Format of ref document f/p: P Ref country code: DE Ref document number: 3546663 Format of ref document f/p: P |
|
| Q171 | Divided out to: |
Ref country code: DE Ref document number: 3546663 Ref country code: DE Ref document number: 3546664 |
|
| 8172 | Supplementary division/partition in: |
Ref country code: DE Ref document number: 3546662 Format of ref document f/p: P |
|
| Q171 | Divided out to: |
Ref country code: DE Ref document number: 3546662 |
|
| 8172 | Supplementary division/partition in: |
Ref country code: DE Ref document number: 3546683 Format of ref document f/p: P |
|
| Q171 | Divided out to: |
Ref country code: DE Ref document number: 3546683 |
|
| 8172 | Supplementary division/partition in: |
Ref country code: DE Ref document number: 3546684 Format of ref document f/p: P |
|
| Q171 | Divided out to: |
Ref country code: DE Ref document number: 3546684 |
|
| AH | Division in |
Ref country code: DE Ref document number: 3546664 Format of ref document f/p: P Ref country code: DE Ref document number: 3546683 Format of ref document f/p: P Ref country code: DE Ref document number: 3546684 Format of ref document f/p: P Ref country code: DE Ref document number: 3546662 Format of ref document f/p: P |
|
| D2 | Grant after examination | ||
| AH | Division in |
Ref country code: DE Ref document number: 3546684 Format of ref document f/p: P Ref country code: DE Ref document number: 3546683 Format of ref document f/p: P Ref country code: DE Ref document number: 3546662 Format of ref document f/p: P Ref country code: DE Ref document number: 3546664 Format of ref document f/p: P |
|
| 8363 | Opposition against the patent | ||
| AH | Division in |
Ref country code: DE Ref document number: 3546664 Format of ref document f/p: P |
|
| 8369 | Partition in: |
Ref document number: 3546945 Country of ref document: DE Format of ref document f/p: P |
|
| Q171 | Divided out to: |
Ref country code: DE Ref document number: 3546945 |
|
| AH | Division in |
Ref country code: DE Ref document number: 3546662 Format of ref document f/p: P |
|
| 8331 | Complete revocation |