DE10005154A1 - Verfahren und Vorrichtung zum Kommunikationsaufbau und zum Laden von Daten bei Teilnehmern eines Bussystems - Google Patents

Abstract

Verfahren und Vorrichtung zum Kommunikationsaufbau zwischen zwei Teilnehmern eines Bussystems und zum Laden von Daten über das Bussystem, wobei die Daten in einen Speicher eines ersten Teilnehmers geladen werden und die Daten von einem zweiten Teilnehmer gesendet werden, wobei das Bussystem eine vorgebbare und für alle Teilnehmer gültige Übertragungsrate aufweist, mit der alle Teilnehmer im Betrieb kommunizieren, wobei die Übertragung der Daten in Form von Rahmen durchgeführt wird und ein solcher Rahmen eine Kennung enthält, wobei jeder Busteilnehmer gleichberechtigt Rahmen senden kann und jeder Teilnehmer über die Kennung für ihn bestimmte Rahmen ermittelt und empfängt. Dabei empfängt der erste Teilnehmer von dem zweiten Teilnehmer Rahmen, wenn der zweite Teilnehmer wenigstens einen Rahmen mit einer von der vorgegebenen Übertragungsrate im Betrieb verschiedenen Übertragungsrate über das Bussystem sendet. Insbesondere werden dabei ein Sync, One und Zero Frame definiert, mit denen eine Einsprungbedingung in einen Ladevorgang für die Daten bzw. Kommunikationsaufbau realisiert werden kann.

Description

Stand der Technik

Die Erfindung betrifft Verfahren und Vorrichtung zum Kommunikationsaufbau und zum Laden von Daten bei Teilnehmern eines Bussystems, wobei das Bussystem im normalen Betrieb mit einer vorgebbaren Übertragungsrate bzw. Baudrate ausgestattet ist, mit der alle Teilnehmer über das Bussystem kommunizieren, gemäß den Oberbegriffen der unabhängigen Ansprüche.

Eine solche gemeinsame Übertragungs- bzw. Baudrate, welche zwischen allen beteiligten Teilnehmern des Bussystems vereinbart ist und im normalen Betrieb unveränderlich gilt, ist bei einem CAN-Bussystem gezeigt und wichtig für das Funktionieren eines CAN-Verbundes. Dies ist in der CAN- Spezifikation der Robert Bosch GmbH von 1991, Version 1.2 und 2.0 offenbart. Der CAN-Bus hat sich als Datenübertragungsmedium mit hoher Datenübertragungsrate und hoher Datenübertragungssicherheit bewährt. Dabei ist ein serieller Kommunikationsbus beschrieben, bei welchem Daten in Paketen bzw. Rahmen sogenannten CAN-Frames, die im wesentlichen aus einer Kennung bzw. Identifikation (ID) und einer Anzahl Datenbytes, insbesondere 8 bestehen, übertragen werden. Die ID wird hierbei auch für die Priorität der Datenpakete bei der Busarbitrierung genützt. Busarbitrierung oder Arbitrierung bedeutet, daß wann immer das Bussystem bzw. der Bus frei ist, jeder Teilnehmer eine Nachricht, insbesondere Daten übertragen kann. Starten zwei oder mehrere Teilnehmer die Datenübertragung zur gleichen Zeit, wird durch Benutzung der Kennung dieser Buszugangskonflikt durch Vergleich des übertragenen Pegels der binär codierten Information, also des Pegels des übertragenen Bits jedes Teilnehmers mit dem Pegel des auf den Bus angezeigten Bits gelöst. Sind diese Pegel gleich, darf der Teilnehmer weitersenden. Dabei ist ein Pegel rezessiv und der andere Pegel dominant. Wird nun ein rezessiver Pegel gesendet und auf dem Bus ein dominanter Pegel angezeigt, hat der Teilnehmer die Arbitrierung verloren und muß augenblicklich die Übertragung einstellen. Dies gilt für einen Basic-CAN. Bei einem Full-CAN wird ein sich unterscheidender Mechanismus eingesetzt, wobei aber ebenfalls ein Pegel- bzw. Bitvergleich bezüglich des Identifiers stattfindet. Im weiteren wird nicht mehr zwischen Basic-CAN und Full-CAN unterschieden, da die folgenden Ausführungen auf beide anwendbar bzw. leicht übertragbar sind.

Für das Laden von Daten, insbesondere Programmcode, ist der Mechanismus eines Bootstrap-Loaders bekannt. Der Bootstrap- Loader ist ein spezielles Programm, das bei Starten eines Computersystems in einen Speicher gebracht wird und anschließend dafür sorgt, daß die zum Betrieb der Anlage notwendigen Teile des Betriebssystems in den Arbeitsspeicher gebracht werden und die Kontrolle übernehmen. Ein Computersystem dessen Betriebssoftware nicht fest verdrahtet, bzw. in einem reinen Lesespeicher (Read-Only- Memory) enthalten ist, wird durch diesen Mechanismus erst betriebsbereit gemacht. Ein solcher Bootstrap-Mechanismus für Teilnehmer eines Bussystems ist in der EP 0 364 127 A1 gezeigt. Dabei wird zwischen einem definierten und einem undefinierten Bootstrap-Load-Pfad unterschieden. Der definierte Pfad wird dabei dann ausgeführt, wenn die aktuelle Systemkonfiguration der für den definierten Ladepfad vorgesehenen Systemkonfiguration entspricht. Ansonsten wird der undefinierte Bootstrap-Load-Pfad ausgewählt, wobei ein zentrales Servicemodul mögliche Bootstrap-Load-Pfade sucht, um damit das System zu starten. Es wird somit über den Bootstrap-Loader das Gesamtsystem in einen betriebsbereiten Zustand gebracht.

Sollen in einem Systemverbund einzelne Teilnehmer, insbesondere Steuergeräte in einem Fahrzeug, von einem weiteren Teilnehmer, insbesondere einem Programmier- und/oder Prüf-System zu einem Bootstrap-Mechanismus angestoßen werden, tritt insbesondere bei Bussystemen mit gleichberechtigten Teilnehmern die Problematik auf, das ungewollte Eingriffe in die Software, insbesondere den Programmcode anderer Teilnehmer entstehen können, die zu Fehlern führen können. Bei einem CAN-Bussystem bzw. CAN- Verbund müßte dies somit individuell und somit sehr speziell auf das jeweilige CAN-System angepaßt als High-Level- Programmierung realisiert werden. Damit wäre eine solche High-Level-Programmierung nur für das jeweilige zugrundeliegende CAN-System aber nicht universell einsetzbar.

Desweiteren zeigt der Stand der Technik bezüglich eines solchen Bootstrap-Loaders keine Autorisierungsprüfung, wodurch weitere Fehler, insbesondere durch Fehlprogrammierungen, entstehen können.

Eine allgemein verwendbare serielle Schnittstelle (ISO-K) zwischen einem Steuergerät und einem Prüf- und/oder Programmier-System ist bekannt, wobei für dieses Übertragungsmedium auch Bootstrap-Loader Verwendung finden. Dabei wird das auszuführende Programm über dieses Übertragungsmedium übertragen und ist somit von außen allerdings ohne Autorisierungsprüfung vorgebbar. Die Verwendung einer schnellen, insbesondere CAN-, Schnittstelle ohne Verwendung gesonderter Hardware-Einsprungbedingungen ist dabei nicht gezeigt.

Es zeigt sich, daß der Stand der Technik nicht in jeder Hinsicht optimale Ergebnisse zu liefern vermag. So stellt sich die Aufgabe ein Verfahren und eine Vorrichtung bereitzustellen, durch welche ein universell einsetzbarer Bootstrap-Loader-Mechanismus, insbesondere mit Autorisierungsprüfung für eine schnelle Schnittstelle, insbesondere CAN, definiert werden kann, wobei dieser ohne gesonderte Hardware-Einsprungsbedingungen gestartet werden soll.

Vorteile der Erfindung

Die Erfindung zeigt ein Verfahren und eine Vorrichtung zum Kommunikationsaufbau zwischen zwei Teilnehmern eines Bussystems und zum Laden von Daten über das Bussystem, wobei die Daten in einen Speicher eines ersten Teilnehmers geladen werden und die Daten von einem zweiten Teilnehmer gesendet werden, wobei das Bussystem eine vorgebbare und für alle Teilnehmer gültige Übertragungsrate aufweist, mit der alle Teilnehmer im Betrieb kommunizieren, wobei die Übertragung der Daten in Form von Rahmen durchgeführt wird und ein solcher Rahmen eine Kennung enthält, wobei jeder Busteilnehmer gleichberechtigt Rahmen senden kann und jeder Teilnehmer über die Kennung für ihn bestimmte Rahmen ermittelt und empfängt, wobei der erste Teilnehmer von dem zweiten Teilnehmer Rahmen empfängt, wenn der zweite Teilnehmer wenigstens einen Rahmen mit einer von der vorgegebenen Übertragungsrate im Betrieb verschiedenen Übertragungsrate über das Bussystem sendet.

Die unterschiedliche Übertragungsrate dient vorteilhafterweise als Einsprungbedingung in die Datenübertragung, insbesondere in einen Bootstrap-Loader- Mechanismus des ersten Teilnehmers. Damit kann vorteilhafterweise ein universell einsetzbarer Bootstrap- Mechanismus für Bussysteme mit eigentlich jeweils vorgegebener Übertragungsrate (Baudrate), insbesondere mit Autorisierungsprüfung für ein CAN-Bussystem erstellt werden. Nach einer Empfangsbestätigung durch den ersten Teilnehmer, z. B. eines KfZ-Steuergerätes, mittels Acknowledge folgt die Übertragung der Daten, insbesondere eines auszuführenden Programmcodes, in einen Speicher des ersten Teilnehmers. Nach einer Prüfung, insbesondere Checksummenprüfung werden die geladenen Daten z. B. wenn diese ein Programm ergeben ausgeführt.

Damit können vorteilhafterweise beliebige Daten bzw. Programmcode in einen Speicher des ersten Teilnehmers geladen und zur Ausführung gebracht werden wodurch sich das Verfahren und die Vorrichtung neben z. B. einer Low-Level- Programmierung (z. B. des Flash-Speichers) auch zur Analyse bzw. Prüfung des ersten Teilnehmers, auch unabhängig von dessen eigentlicher Funktion, eignet.

Werden vorteilhafterweise als Einsprungbedingung nur übertragene Rahmen, insbesondere CAN-Rahmen sogenannte CAN- Frames, verwendet, kann zweckmässigerweise auf eine gesonderte HW-Einsprungbedingung verzichtet werden wobei die Vorteile der schnellen Busschnittstelle voll erhalten bleiben. Damit kann vorteilhafterweise eine Verkürzung der Programmierzeiten erzielt werden.

Vorteilhafterweise kann damit der Bootstrap-Mechanismus in jeder Busumgebung, insbesondere CAN-Umgebung, also entweder bei einem separaten Steuergerät mit CAN-Schnittstelle oder einem CAN-Verbund, auch bereits in einem z. B. Fahrzeug oder einer Werkzeugmaschine verbaut eingesetzt werden und ist für den Einsatz in verschiedenen Netzwerken bezüglich Baudrate und/oder verwendeter ID's anpassbar.

Speziell die Verwendung mehrerer wechselnder, insbesondere niedriger, Baudraten wodurch ganze Rahmen als unstörbare Informationsträger benutzt werden können hat grosse Vorteile in Bezug auf die Aufgabenstellung.

Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus der Beschreibung und/oder sind Gegenstand der Ansprüche.

Zeichnung

Die Erfindung wird nachfolgend anhand der in der Zeichnung dargestellten Figuren beschrieben. Dabei zeigen

Fig. 1a eine Anordnung mit einem Steuergerät und einem Prüf- und/oder Programmiersystem PPS, welche über ein Bussystem bzw. eine diesem entsprechende Schnittstelle, insbesondere CAN, verbunden sind.

Fig. 1b zeigt einen Systemverbund in einem Fahrzeug, an welchen über das eingesetzte Bussystem, insbesondere CAN, ein Prüf- und/oder Programmiersystem PPS angekoppelt ist.

Fig. 2 zeigt den Ablauf eines erfindungsgemäßen Verfahrens eines Bootstrap-Loaders BSL, insbesondere über CAN-Bus in einem Flußdiagramm.

In Fig. 3 sind die Einsprungbedingungen ESB bzw. die diesen entsprechenden Rahmen mit wechselnden Baudraten dargestellt.

Fig. 4 zeigt beispielhaft die Definition verschiedener Rahmen bei einem CAN-Bootstrap-Loader.

Fig. 5 zeigt den Ablauf bei einer Steuergeräteprogrammierung in einem Flußdiagramm.

Im weiteren wird die Erfindung in Form eines Ausführungsbeispiels beschrieben. Dabei wird zur Veranschaulichung ein CAN-Bussystem verwendet. Die Erfindung kann aber bei jedem Bussystem, das bezüglich eines Bootstrap-Mechanismus bzw. der Einsprungbedingung eine vergleichbare Situation wie ein CAN-Verbund-System bereithält, Verwendung finden.

Beschreibung des Ausführungsbeispiels

Fig. 1a zeigt ein Steuergerät 100, das über ein CAN- Bussystem 107 bzw. eine dem CAN-Bussystem entsprechende Schnittstelle mit einem Programmier- und/oder Prüfsystem PPS 108 verbunden ist. Das PPS 108 enthält dabei eine Schnittstelle 106 zur Verbindung mit dem CAN-Bus. Eine solche Schnittstelle 105 zur Verbindung mit den CAN-Bus 107 ist ebenfalls im Steuergerät 100 enthalten. Mit 102 ist der Arbeitsspeicher (RAM) des Steuergerätes dargestellt. Dieser kann im Mikrocomputer µC 101 des Steuergeräts enthalten oder extern von diesem angeordnet sein. Gleiches gilt für Speicher 103, der als nicht flüchtiger Speicher ausgebildet ist. Dieser nicht flüchtige Speicher 103 kann wiederbeschreibbar, also löschbar oder nicht löschbar ausgebildet sein. Je nach Ausführung des Speichers 103 ist optional ein weiterer Speicher 104 ebenfalls nicht flüchtig enthalten. Mit 101 ist ein Mikroprozessor dargestellt. Je nach Funktionsumfang und Ausführungsform wird dieser auch als Mikrocomputer µC, Mikrocontroller u. s. w. bezeichnet. Die Speicher 102, 103 und optional 104 sowie die Schnittstelle 105 und die wenigstens eine Recheneinheit 101 des Steuergeräts 100 sind über ein internes Bussystem 115 verbunden. Mögliche weitere im Steuergerät enthaltene Elemente wie weitere Recheneinheiten, Speicher, Schnittstellen, Energieversorgung, u. s. w. sind der Übersichtlichkeit halber nicht dargestellt.

Fig. 1b zeigt das Steuergerät 100 verbaut in einem Fahrzeug 110 über ein CAN-Bussystem 111 sind optional weitere Steuergeräte, Sensorik, Aktuatorik, Schnittstellen, u. s. w. über ein CAN-Bussystem 111 verbunden. Stellvertretend für die sonstigen an den CAN-Bus 111 angeschlossenen Elemente ist ein Element 109 dargestellt. Eine Anschlußschnittstelle an den CAN-Bus 111 ist mit 112 dargestellt. An diese Schnittstelle 112 kann beispielsweise ein Prüf- und/oder Programmiersystem PPS 114, insbesondere ohne eigene Schnittstelle über Verbindung 113, bidrektional mit dem CAN- Bus verbunden werden. Die Anschlußschnittstelle an den CAN- Bus kann somit über PPS 108 integriert sein oder wie bei PPS 114 extern ausgebildet sein.

Die erfindungsgemässe Definition eines universellen CAN- Bootstrap-Loaders (CAN-BSL), insbesondere mit Autorisierungsprüfung, soll beispielsweise eine Low-Level- Programmierung eben über den CAN-BSL ermöglichen um beispielsweise die Verkürzung der Programmierzeiten eines Steuergeräts 100 zu erzielen. Desweiteren kann beispielsweise auch eine Steuergeräteprüfung (Analyse) über diesen Weg, unabhängig von der eigentlichen Steuergerätefunktion, durchgeführt werden. Der im nachfolgenden behandelte Mechanismus kann somit am einzelnen Steuergerät oder auch bei einem im Fahrzeug verbauten Steuergerät jederzeit eingesetzt werden. Mit Low-Level- Programmierung im Gegensatz zu High-Level-Programmierung bzw. Übertragung ist eine einfache Übertragung auf Bauteilebene ohne aufwendige Softwarestruktur im Steuergerät gemeint. D. h. spezifische und aufwendige Software-Protokolle für die Kommunikationsebene mit komplexer Verpackung wie Header und Overhead werden vermieden. Insbesondere orientiert sich die Low-Level-Programmierung bzw. - Kommunikation an den Möglichkeiten der Maschine und nicht direkt an der Aufgabenstellung des Benutzers.

Der Bootstrap-Loader ist dabei entweder in einem nicht flüchtigen Speicher 103 bzw. 104 als Programmcode abgelegt, um von dort in den Arbeitsspeicher 102 des Steuergeräts 100 geladen zu werden oder er kann auch in Hardware in Form einer Statemachine also als Automat im µC 101 selbst enthalten sein. Dabei kann der Bootstrap-Loader in einem reinen Lesespeicher (ROM) 104 untergebracht sein und zur Ausführung in den Arbeistspeicher geladen werden. Ebenso kann er in einem reservierten und geschützten Bereich eines nichtflüchtigen Speichers 103 z. b. ausgebildet als PROM, EPROM, EEPROM, Flash-EPROM, usw. befinden, wodurch ein als ROM ausgebildeter Speicher 104 zu diesem Zweck nicht gebraucht würde.

Der universelle CAN-Bootstrap-Loader BSL in einem Steuergerät wird durch die Übertragung von einer Einsprungbedingung, speziell CAN-Einsprungbedingung, CAN-ESB aktiviert. Die in den CAN-ESB enthaltene Information wird zur Konfigurierung der weiteren CAN-Kommunikation verwendet. Somit ist das Verfahren für den Einsatz in verschiedenen CAN-Netzwerken, entsprechend Bautdrate und vergebener IDs anpassbar. Nach einer Empfangsbestätigung durch das Steuergerät, mittels Steuergeräteacknowledge folgt die Übertragung des auszuführenden Programmcodes in den Steuergeräte-Arbeitsspeicher das RAM 102. Nach der Autorisierungsprüfung, z. B. durch Checksummenberechnung wird das geladene Programm dann ausgeführt. Fig. 2 zeigt dazu ein Ablaufdiagramm. Das Programmiersystem PPS 108 bzw. 114 fungiert dabei als Master und das Steuergerät SG 100 als Slave. In Block 201 wird das Steuergerät mit Energie versorgt und in Block 200 der Programmiervorgang bzw. der Bootstrap-Loader-Vorgang gestartet. Der Master, also das PPS sendet in Block 202 die Einsprungbedingung ESB an den Slave, das Steuergerät SG 100. Dies ist dargestellt durch den Übergang PPS1.

In Abfrage 203 wird überprüft, ob die Einsprungsbedingung des Master erkannt wurde bzw. diese vorliegt. Ist dies nicht der Fall, gelangt man zu Block 204 und der normalen Funktion des Steuergerätes. Wird hingegen die Einsprungbedingung erkannt, gelangt man zu Block 205, worin das Steuergerät mittels einer Steuergeräteacknowledge quittiert. Der Übergang der Quittung ist mit SG1 dargestellt. Daraufhin wird in Abfrage 206 überprüft, ob vom Master also dem PPS die Steuergeräteacknowledge empfangen wurde. Ist dies nicht der Fall, gelangt man wieder zu Block 202 und die Einsprungbedingung wird erneut gesendet. Ist das Steuergeräteacknowledge empfangen, gelangt man zu Block 207.

Nach Senden der Steuergeräteacknowledge im Block 205 läd das Steuergerät, ausgelöst durch die Einsprungbedingung ESB den Bootstrap-Loader in den Arbeitsspeicher (RAM) 102 des Steuergeräts 100. Wie schon vorher erwähnt, kann in diesem Block 208 der Bootstrap-Loader auch, wenn er in Form einer Statemachine im Mikrocomputer 101 vorliegt aktiviert werden. Mittels des Bootstrap-Loaders erfolgt nun die CAN-Daten- Übertragung, also die Übertragung insbesondere von Programmierroutinen in den Arbeitsspeicher (RAM) 102 des Steuergeräts 100. Dieser Übergang ist mit PPS2 dargestellt.

Im Block 209 erfolgt eine Überprüfung des Arbeitsspeichers, beispielsweise durch Checksummenbildung. Bei Verwendung eines CAN-Busses kann der Checksummenmechanismus des CAN- Protokolls verwendet werden. Tritt bei der Checksummenprüfung des Arbeitsspeichers ein Fehler auf, ist bei Verwendung eines CAN-Busses eine Fehlerbehandlung nach CAN durchführbar und deshalb im einzelnen nicht mehr ausgeführt. So würden bei einem Fehler die Routinen z. B. einfach erneut in den Arbeitsspeicher geladen, um die fehlerhaften zu ersetzen, dargestellt durch die gestrichelte Rückführung mit der Bezeichnung Fehler.

Ist die Checksummenprüfung in Ordnung folgt der Einsprung zu der eingeladenen Routine im Arbeitsspeicher im Block 210. Von Abschnittspunkt A1 bis Abschnittspunkt A2 in Block 210 erfolgte die Ausführung aus dem nicht flüchtigen Steuergerätespeicher, insbesondere dem Steuergeräte ROM bzw. dem reservierten Flash-Bereich (vgl. oben). Ab Abschnittspunkt A2 wird nun der weitere Verfahrensablauf aus dem Steuergerätearbeitsspeicher (RAM) 102 heraus ausgeführt. Nach dem Ansprung der Arbeitsspeicherroutine im Block 210 und Ausführung oder Ausführungsbeginn bzw. ersten Routinendurchlauf wird im Block 211 erneut ein Steuergeräteacknowledge als Quittung gesendet. Der Übergang zum Master dargestellt als SG2 bedingt wiederum eine Überprüfung in Abfrage 212 ob die Steuergerätequittung empfangen wurde. Ist dies nicht der Fall, gelangt man zurück zu Block 207 und die Programmierroutinen werden wiederum in den Arbeitsspeicher übertragen. Eine nicht verlassbare Schleife kann man durch eine Begrenzung der Lade-Versuche verhindern.

Ist das Steuergeräteacknowledge empfangen, gelangt man zu Block 213 zum Beginn der CAN-Übertragung. Wird der Programmiervorgang als Flashprogrammierung verstanden erfolgt nun im Block 213 die Übertragung der Flashdaten. Dabei kann der nichtflüchtige Speicher 103 eben beispielsweise als Flash-Speicher ausgebildet sein. Die Flash-Daten werden im Steuergerät empfangen und dort einer Checksummenprüfung oder sonstigen Überprüfung unterzogen. Ist die Überprüfung in Ordnung, werden die Flash-Daten in den Flash-Speicher einprogrammiert. Dies geschieht im Block 214. Bei einem Fehler bei der Datenprüfung bzw. Checksummenprüfung können die jeweiligen Daten erneut übertragen werden. Mit Einprogrammierung bzw. abgeschlossener Einprogrammierung der Flash-Daten wird zur Bestätigung wiederum eine Steuergeräteacknowledge gesendet. Dies geschieht im Block 215.

Die Übergänge vom Master PPS zum Steuergerät also hier die übertragenen Flash-Daten sind durch Übergang PPSK dargestellt. Die Übermittlung der Steuergeräteacknowledge ist in Übergang SGK dargestellt. Aus Sicherheitsgründen und durch die Begrenzung des maximalen Dateninhaltes eines CAN- Rahmens werden dabei die Flash-Daten z. B. portioniert, also in Teilen übertragen. Die Ausführung des Verfahrens von Abschnittspunkt A3 zu Abschnittspunkt A4 wird somit für jeden übertragenen Teil der Flash-Daten wiederholt. Aus Übersichtlichkeitsgründen ist die erneute Überprüfung der Steuergeräteacknowledge nicht im einzelnen dargestellt. Der Master überprüft aber anhand der Acknowledges, ob die letzten übertragenen Flash-Daten programmiert sind oder nicht und sendet beispielsweise erst im Anschluß einer Acknowledge die nachfolgenden Daten. Bleibt ein Steuergeräteacknowledge aus, bezüglich des letzten Flash- Datenpakets, werden die nicht programmierten, also durch Acknowledge nicht bestätigten Flash-Daten erneut übertragen. Ist die CAN-Übertragung der Flash-Daten in Block 213 abgeschlossen, gelangt man zu Block 216 dem Ende des Ablaufs. Durch Einladen der Routinen insbesondere Programmierroutinen ins RAM erfolgt die Ausführung von Abschnittspunkt A2 bis Abschnittspunkt A4 aus dem Arbeitsspeicher des Steuergerätes. Somit werden die Flash- Programmierroutinen per CAN-Bootstrap-Loader ins interne Steuergeräte-RAM geladen, checksummengeprüft und ausgeführt. Das Programmier-Prüf-System muß nur das Steuergerät versorgen und die CAN-Einsprungsbedingung (CAN-ESB) generieren und anschließend die Daten (Flash- Programmierroutinen und Flash-Daten) per CAN übertragen.

Mit Hilfe des dargestellten Verfahrens läßt sich aber im Prinzip beliebiger Code in den Steuergeräte-Arbeitsspeicher laden und zur Ausführung bringen. Somit kann das Verfahren neben der Low-Level-Flash-Programmierung auch z. B. für die Analyse bzw. Prüfung des Steuergeräts eingesetzt werden.

Entscheidend für den Einsatz des Verfahrens bei einem CAN- oder CAN-vergleichbaren Bussystem ist die Einsprungbedingung ESB in dem Bootstrap-Loading-Mechanismus. Dabei sollen einerseits die Vorteile der schnellen Schnittstelle (z. B. ein MBaud) genutzt werden ohne gesonderte Hardware- Einsprungsbedingungen zu verwenden. Es werden also als Einsprungsbedingung ESB nur übertragene CAN-Rahmen, sog. CAN-Frames eingesetzt. Allerdings sollte diese Einsprungbedingung bzw. die verwendeten CAN-Frames im normalen Betrieb nicht vorkommen, da sonst eine große Gefahr der Störungserzeugung besteht, weil durch Festlegung der Übertragungsrate bzw. Baudrate im CAN-System und die Gleichberechtigung der Teilnehmer bei einer Programmierung in die Systemsoftware bei Fahrzeugen beispielsweise in die Fahrsoftware eingegriffen würde.

Da die CAN-ID's bzw. CAN-Identifier systemspezifisch sind, also dem jeweiligen CAN-System eindeutig zugeordnet, sind diese für einen allgemeinen CAN-Bootstraploader-Mechanismus mit zugehöriger Einsprungbedingung nicht verwendbar. Die erfindungsgemäße Lösung ist die Verwendung von wechselnden, insbesondere niedrigen Baudraten als CAN-Einsprungbedingung. Ein konventionelles CAN-System reagiert auf wechselnde, insbesondere niedrige, Baudraten nicht. Desweiteren ist zur Steigerung der Datenübertragungsrate in Zukunft eher eine weitere Erhöhung der verwendeten CAN-Baudraten zu erwarten. Da im CAN-System der dominante Buszustand sich durchsetzt (dominanter Buszustand ist z. B. Lowpegel), kommt dem CAN- Frame mit mehr führenden Nullen im Identifier ID die höhere Priorität zu. Aus Synchronisationsgründen wird innerhalb eines CAN-Frames nach einer bestimmten Anzahl von Bits gleicher Pegellage, insbesondere nach max. 5 Bits, stets ein Flankenwechsel eingefügt, was im CAN als Bitstuffing bezeichnet wird. Normalerweise wird dieses Stuffbit bei der Nachrichtenauswertung dann wieder gelöscht. Zum Kommunikationsaufbau nach Master-Slave-Form über den CAN-Bus mit eigentlich gleichberechtigten Teilnehmern werden dazu drei Frames, ein sogenannter Sync-Frame, ein One-Frame sowie ein Zero-Frame definiert. Dies ist in Fig. 3 dargestellt. Der Beginn dieser CAN-ESB-Frames im weiteren als Info-Phase bezeichnet stellt somit durch die insbesondere fünf führenden dominanten Bits ein unstörbares und unverwechselbares Signal dar.

Fig. 3 zeigt dabei von Abschnitt At0 bis Abschnitt At2 einen ersten Rahmen, den Sync-Frame, der in einer Übertragungsrate Baudrate 1 durch den Master übertragen wird. Die Infophase dabei ist von Zeitabschnitt At0 bis Zeitabschnitt At1 und mit IPSync bezeichnet. In IPSync werden somit fünf Bit mit dominanter Pegelrate in Baudrate 1 übertragen. Im nachfolgenden Teil, mit RestSync bezeichnet von Abschnitt At1 bis Zeitabschnitt At2 gilt lediglich die Bedingung, dass keine fünf Bits gleicher Pegellage, insbesondere der dominanten Pegellage aufeinanderfolgen sollten, dies wird aber bei Fig. 4 noch näher erläutert. Der One-Frame, der zum Kommunikationsaufbau die "1" oder high-Information überträgt ist vom Zeitabschnitt At3 bis Zeitabschnitt At5 dargestellt. Dieser wird mit einer Übertragungsrate Baudrate 2 übertragen. Die Infophase dauert hier von Zeitabschnitt At3 bis Zeitabschnitt At4 und ist mit IPOne bezeichnet. Auch hier werden fünf gleiche Bits, insbesondere dominanter Pegellage mit einer Baudrate 2 durch den Master übertragen. Die übrigen Bits des One-Frame sind in RestOne von Zeitabschnitt At4 bis At5 zusammengefasst, wobei die gleichen Überlegungen bezüglich der aufeinanderfolgenden Bits gleicher Pegellage wie für den Sync-Frame gelten. Schließlich ist in Fig. 3 noch der Zero- Frame dargestellt, dessen Bits mit einer Baudrate 3 übertragen werden und der die Null-Information (Low) bezüglich des Kommunikationsaufbaus überträgt. Von Zeitabschnitt At6 bis At7 werden auch hier in der Infophase IPZero des Zero-Frame fünf Bits dominanter Pegellage diesmal mit Baudrate 3 durch den Master übertragen. Die übrigen Bits des Zero-Frame sind in RestZero von At7 bis At8 zusammengefasst, wobei gleiche Überlegungen wie für RestSync und RestOne gelten. Je nach Definition der benutzten Rahmen für Sync, One und Zero könnten die Umfänge der jeweiligen Restbits RestSync, RestOne bzw. RestZero variieren. Entscheidend sind aber die Infophasen IPSync, IPOne bzw. IPZero mit den aufeinanderfolgenden, insbesondere fünf an der Zahl, Bits dominanter Pegellage. Diese Phasen werden im weiteren in Verbindung mit den unterschiedlichen Übertragungsraten Baudrate 1, 2 bzw. 3 als Informationsträger eingesetzt.

Durch die Verwendung dieser unterschiedlichen, insbesondere niedrigen Baudraten, ergeben sich unterschiedliche Zeiten, mit denen gleichzeitig mit der CAN-ESB auch die Information für die weitere CAN-Kommunikation, also mit hoher Baudrate, übertragen wird. Aus Sicherheitsgründen kann festgelegt werden, dass der Rest der jeweiligen CAN-Frames, RestSync, RestOne und RestZero maximal 3 aufeinanderfolgende Bits dominanter Pegellage aufweist, wenn aufgrund des Bitstuffings nach fünf Bits die Infophase mit fünf dominanten Bits gebildet wird. Das bedeutet also, dass die längste dominante Bitfolge im Rest der CAN-Frames, also RestSync, RestOne bzw. RestZero, also insbesondere niedriger Baudrate zu keiner Verwechslung mit den insbesondere fünf dominanten Bits einer Infophase führen dürfen. Dies ist mit dem in der Tabelle in Fig. 4 angegebenen Beispiel erfüllt.

In Fig. 4 sind nun vier unterschiedliche CAN-Frames definiert. Der sogenannte Sync, One, Zero und im weiteren der Trigger-Frame. Da aus den unterschiedlichen ESB-CAN- Frames, insbesondere niedriger Baudrate Sync, One und Zero nur die Infophase als sichere Information einer CAN- Botschaft zu betrachten ist, da die nachfolgenden Bits störbar sind, wird dieser Teil als Träger genutzt. Mit Hilfe dieser Träger werden n Bit Information übertragen, die den nachfolgenden Trigger-Frame spezifizieren. Dies wird später in Fig. 5 noch einmal dargestellt.

Damit ist das Verfahren für den Einsatz in verschiedenen CAN-Netzwerken bezüglich Baudrate und vergebener Identifier anpassbar. Im Beispiel gemäß Tabelle T400 in Fig. 4 ist die CAN-ESB definiert als eine zyklische Sequenz von CAN-Frames, die vom PPS als Master gesendet werden. Die Bedingungen für die Verzweigung in den CAN-Bootstrap-Loader sind also quasi im Identifier, indirekt im Dateninhalt, der Baudrate und Abfolge der CAN-Botschaften inkludiert. In Tabelle T401 sind dafür beispielhaft die CAN-Frames vom Master mit den Framebezeichnungen Sync, One, Zero und Trigger dargestellt. Bei den Frames Sync, One und Zero sind lediglich drei Bedingungen zu erfüllen. Zum einen wird mit einer Anzahl von dominanten Bits, insbesondere 5, der Identifier eingeleitet. Zum zweiten wird im weiteren, also im Rest des Identifiers sowie im Dateninhalt darauf geachtet, dass diese Konstellation der, insbesondere fünf führenden, dominanten Bits nicht mehr auftritt. Als drittes werden die drei Frames mit unterschiedlichen Übertragungsraten, insbesondere Baudraten 1, 2 und 3 wie dargestellt, übertragen.

Beispielhafte Baudraten sind dabei insbesondere niedrige Baudraten im Vergleich zu einer im Betrieb üblichen Übertragungsrate von ein MBaud. Diese liegen beispielsweise zwischen 38 und 47 Kilobaud. Dabei könnte in einem Beispiel Baudrate 1 38,27 Kilobaud, Baudrate 2 42,10 Kilobaud und Baudrate 3 mit 46,78 Kilobaud vorgegeben werden. Der Triggerframe, der durch abwechselnde One- und Zero-Frames wie in Fig. 5 dargestellt spezifiziert wird, trägt als Identifier die CAN-Bootstrap-Loader-Master-ID (CAN-BSL- Master-ID), welche auch für Codeblock- und Flash-Daten verwendet werden kann.

Der Dateninhalt in diesem Beispiel hat zu Beginn und am Ende jeweils ein reserviertes Byte und zusätzlich die CAN-BSL- Slave-ID für das Steuergerät, z. B. 2 Byte für die RAM- Startadresse sowie 2 Byte für die RAM-Endadresse (Ersatzweise Startadresse plus Adressoffset) und wird mit einer Übertragungsrate, Baudrate R, übertragen. Die Baudrate R unterscheidet sich ebenfalls von der im jeweiligen CAN- System üblichen vorgegebenen Übertragungsrate.

Im Beispiel bei einer Übertragungsrate im Normalbetrieb von 1 Megabaud könnte der Trigger mit 500 Kilobaud übertragen werden. Damit wird vermieden, dass beispielsweise bei einem Steuergerät in einem Fahrzeug die Fahrsoftware angesprochen wird. Wird die CAN-ESB vom Steuergerät erkannt, antwortet dieses mit einem Acknowledge-Frame dargestellt in Tabelle T402. Das Acknowledge-Frame enthält als Identifier die CAN- BSL-Slave-ID und im Dateneinhalt ein Byte Error-Code plus vier Byte entsprechend der Maskenversion bei Basic-CAN. Darüber hinaus sind beispielsweise drei Byte reserviert. Auch der Acknowledge-Frame des Slave also des Steuergeräts wird mit Baudrate R an den Master übertragen. Der 11-Bit- Identifier kann insbesondere in den Bits ID 28 bis ID 18 eines CAN-Frames im Standartformat abgelegt werden. Dies ist natürlich einfach auf ein Extended-Format übertragbar.

In Fig. 5 ist nun ein Ablauf im Programmiersystem bezüglich des Masters mit Spezifikation des Trigger-Frames dargestellt. Von Abschnitt A50 bis Abschnitt A51 wird zu Verfahrensbeginn ein Sync-Frame Block 500 übertragen. Mit diesem Sync-Frame wird der Slave, also das Steuergerät, geweckt. Von Abschnitt A51 bis A52 folgen dann n Frames, One-Frame oder Zero-Frame im Wechsel zur Übertragung der n Bit Information zur weiteren Kommunikationsspezifikation. In Block 501 wird eine Anzahl nb Frames für Bittiming, insbesondere die Information, mit welcher Baudrate nachfolgend der Trigger-Frame bzw. der Acknowledge-Frame übertragen werden sollen übertragen. Im speziellen Beispiel könnte dieses nb 15 sein. Somit können mit 15 One- oder Zero-Frames 15 Bit mit der Information für die später zu verwendende Baudrate übermittelt werden. Im Block 502 wird dann die CAN-BSL-Master-ID mit ni Frames übertragen. In unserem Beispiel werden 11 Bit Identifier verwendet, wodurch somit die ID z. B. eben mit 11 Bit sprich ni = 11 Frames übermittelt wird. Im Block 503 stehen dann noch nc Frames zur Überprüfung insbesondere für eine Checksummenbildung zur Verfügung. Bei dem Einsatz einer Nibbel-XOR-Checksumme beispielsweise wäre nc = 4. Es werden somit vier Bit in vier Frames, One oder Zero, in Block 503 übertragen. Ein Nibbel ist dabei die Hälfte eines Bytes, wobei ein Nibbel als hexzahl codierbar ist. Dies entspricht einer bevorzugten Schreibweise für Speicherinhalte.

Somit würden in Block 501, 502 und 503 in einem konkreten Beispiel 15 + 11 + 4 = 30 Bit mit n = 30 Frames übertragen. Jeder Zero-Frame stellt somit eine "Null" (0) und jeder One- Frame eine "Eins-" (1) Information dar.

Von Abschnitt A52 bis Abschnitt A53 wird mit einem erneuten Sync-Frame in Block 504 das Senden des Trigger-Frames eingeleitet. Die Blöcke 500 bis 504 bzw. die darin gesendeten Frames weisen insofern eine Besonderheit auf, als dass der Master darauf kein Hardware-Acknowledge-Bit erwartet. Wegen dem fehlenden Hardware-Acknowledge-Bit ist somit ein anschließendes Rücksetzen des CAN (Reset) bzw. dieser Blocks 500 bis 504 nötig. Die CAN-ESB ist somit definiert als eine zyklische Sequenz von CAN-Frames die vom Master PPS gesendet werden. Von Abschnitt 53 bis Abschnitt 55 erfolgt dann der Übergang und das Senden des Trigger- Frame. Dabei wird von Abschnitt 54 bis Abschnitt 57 zur hohen in Block 501 übermittelten Baudrate R mit z. B. 500 Kilobaud übergegangen. In Block 505 wird dann der Trigger- Frame mit CAN-BSL-Slave-ID + RAM-Startadresse + RAM- Endadresse an den Slave, gekennzeichnet durch dessen Slave- ID übertragen. Der Slave übermittelt nach empfangenen Trigger-Frame sein Acknowledge-Frame wie in Fig. 4 dargestellt an den Master. Dieser wartet von Abschnitt 55 bis Abschnitt 56 auf die Steuergeräteantwort insbesondere mit einem Timeout, also einer Wartezeit TW. Dies geschieht in Abfrage 506. Ist die Steuergeräteantwort mit CAN-BSL- Slave-ID innerhalb der Wartezeit PW eingegangen, wird im Block 507 mit der CAN-Übertragung der vereinbarten Bautdrate z. B. R der Informationen vom Master zum Slave begonnen.

Empfängt der Master kein Slaveacknowledge wird wieder mit dem Senden eines SYNC-Frames in Block 500 begonnen und somit die Einsprungbedingung ESB wiederholt. Die Wartezeit für den Timeout TW kann dabei beispielsweise 2 Millisekunden betragen. Wird also die CAN-ESB vom Steuergerät erkannt, antwortet dieses mit einem Acknowledge-Frame. Wesentlich ist hierbei, daß die verwendete Baudrate und CAN-ID nicht hart ins Steuergerät eincodiert ist, sondern über die Einsprungbedingung dem Steuergerät mitgeteilt wurde. Die weitere CAN-Übertragung in Block 507 läuft dann mit höherer Baudrate R insbesondere beispielsweise 500 Kilobout und benützt die beiden IDs CAN-BSL-Master-ID für die Übertragung vom Master zum Slave und CAN-BSL-Slave-ID für die Übertragung vom Slave zum Master. Somit gelingt es mit dem erfindungsgemässen Verfahren und Vorrichtung in einem Bussystem mit gleichberechtigten Teilnehmern und für den Betrieb vorgegebener Übertragungsrate eine Master-Slave- Kommunikation zwischen zwei Teilnehmern zu etablieren ohne Fehler oder Störungen im Gesamtsystemverbund zu erzeugen.

Als vorteilhafte Ausgestaltung läßt sich die gesamte Übertragung in Form eines NOP-Files als Erweiterung für CAN definieren, wodurch eine einfache Spezifikation möglich ist. Dabei beschreibt das NO-Protokoll-Communikation-File (NOP- File) den Datenstrom einer seriellen Kommunikation. Es enthält neben den eigentlichen Daten noch die Kommunikationsbeschreibung und die Parametrierung der Schnittstelle. Mit Hilfe dieses Files sollen die Daten für die Flash-Programmierung eines Steuergerätes über eine serielle Datenleitung übermittelt werden. Damit können unterschiedliche Protokolle einheitlich beschrieben werden. Dieses File ist automatisch nach den Vorgaben des zu beschreibenden Protokolls generierbar. In unserem Fall für CAN.

Claims (12)

1. Verfahren zum Kommunikationsaufbau zwischen zwei Teilnehmern eines Bussystems und zum Laden von Daten über das Bussystem, wobei die Daten in einen Speicher eines ersten Teilnehmers geladen werden und die Daten von einem zweiten Teilnehmer gesendet werden, wobei das Bussystem eine vorgebbare und für alle Teilnehmer gültige Übertragungsrate aufweist, mit der alle Teilnehmer im Betrieb kommunizieren, wobei die Übertragung der Daten in Form von Rahmen durchgeführt wird und ein solcher Rahmen eine Kennung enthält, wobei jeder Busteilnehmer gleichberechtigt Rahmen senden kann und jeder Teilnehmer über die Kennung für ihn bestimmte Rahmen ermittelt und empfängt, dadurch gekennzeichnet, dass der erste Teilnehmer von dem zweiten Teilnehmer Rahmen empfängt, wenn der zweite Teilnehmer wenigstens einen Rahmen mit einer von der vorgegebenen Übertragungsrate im Betrieb verschiedenen Übertragungsrate über das Bussystem sendet.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die über das Bussystem übertragenen Informationen binär kodiert sind, wobei ein Pegel dominant und der andere Pegel rezessiv ist und der wenigstens eine Rahmen unterschiedlicher Übertragungsrate mit einer vorgebbaren Anzahl dominanter Pegel, insbesondere fünf, beginnt.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass wenigstens zwei Rahmen mit von der im Betrieb vorgegebenen Übertragungsrate verschiedener Übertragungsrate von dem zweiten Teilnehmer übertragen werden, wobei eine erste Übertragungsrate eines ersten Rahmens sich von einer zweiten Übertragungsrate eines zweiten Rahmens ebenfalls unterscheidet und die Kennungen beider Rahmen mit der gleichen Anzahl dominanter Pegel beginnen, wobei der erste Rahmen der mit der ersten Übertragungsrate übertragen wird mit den dominanten Pegeln insgesamt die binär kodierte Information eines dominanten Pegels überträgt und der zweite Rahmen der mit der zweiten Übertragungsrate übertragen wird mit den dominanten Pegeln insgesamt die binär kodierte Information eines rezessiven Pegels überträgt wobei abhängig von der zu übertragenden Information aufeinanderfolgend der erste oder der zweite Rahmen übertragen wird.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der erste Teilnehmer zum Laden der Daten einen Bootstrap- Mechanismus einsetzt, wobei als Einsprungbedingung in den Bootstrap-Mechanismus der wenigstens eine Rahmen mit der von der für das Bussystem vorgegebenen Übertragungsrate verschiedener Übertragungsrate vom zweiten an den ersten Teilnehmer übermittelt wird.

5. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass ein dritter Rahmen, der mit einer dritten Übertragungsrate übertragen wird durch den zweiten Teilnehmer an den ersten Teilnehmer übertragen wird, wobei der erste und der zweite Teilnehmer mit den dominanten Pegeln im dritten Rahmen synchronisiert werden.

6. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass ein vierter Rahmen, der mit einer vierten Übertragungsrate übertragen wird definiert wird, wobei die Kennung des vierten Rahmens mit ersten und zweiten Rahmen vor dem Übertragen des vierten Rahmens durch den zweiten Teilnehmer an den ersten Teilnehmer übertragen wird und nach dem vierten Rahmen die Daten von dem zweiten an den ersten Teilnehmer übertragen werden.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass der vierte Rahmen neben der Kennung des zweiten Teilnehmers auch eine Kennung für den ersten Teilnehmer enthält und eine Startadresse bezüglich der nachfolgend geladenen Daten in dem Speicher des ersten Teilnehmers aufweist.

8. Verfahren nach Anspruch 3 und 5 und 6, dadurch gekennzeichnet, dass die erste, zweite, dritte und vierte Übertragungsrate sich untereinander und von der vorgegeben Übertragungsrate des Bussystems im Betrieb unterscheiden, wobei die vierte Übertragungsrate, mit der neben dem vierten Rahmen auch die Daten vom zweiten zum ersten Teilnehmer übertragen werden höher ist als die erste, zweite oder dritte Übertragungsrate.

9. Vorrichtung mit einem ersten und einem zweiten Teilnehmer und einem diese verbindenden Bussystem, wobei Mittel zum Kommunikationsaufbau zwischen den Teilnehmern und zum Laden von Daten über das Bussystem enthalten sind, wobei die Daten in einen Speicher des ersten Teilnehmers geladen werden und die Daten von dem zweiten Teilnehmer gesendet werden, wobei das Bussystem eine vorgebbare und für alle Teilnehmer gültige Übertragungsrate aufweist, mit der alle Teilnehmer im Betrieb kommunizieren, wobei die Übertragung der Daten in Form von Rahmen durchgeführt wird und ein solcher Rahmen eine Kennung enthält, wobei jeder Busteilnehmer gleichberechtigt Rahmen senden kann und jeder Teilnehmer über die Kennung für ihn bestimmte Rahmen ermittelt und empfängt, dadurch gekennzeichnet, dass weitere Mittel im zweiten Teilnehmer enthalten sind und der erste Teilnehmer von dem zweiten Teilnehmer Rahmen empfängt, wenn der zweite Teilnehmer durch die weiteren Mittel wenigstens einen Rahmen mit einer von der vorgegebenen Übertragungsrate im Betrieb verschiedenen Übertragungsrate über das Bussystem sendet.

10. Steuergerät, als erster Teilnehmer eines Bussystems, wobei über das Bussystem Daten zu dem Steuergerät übertragen werden und das Steuergerät Daten über das Bussystem überträgt, wobei das Bussystem eine vorgebbare und für alle Teilnehmer gültige Übertragungsrate aufweist, mit der alle Teilnehmer im Betrieb kommunizieren, wobei die Übertragung der Daten in Form von Rahmen durchgeführt wird und ein solcher Rahmen eine Kennung enthält, wobei jeder Teilnehmer gleichberechtigt Rahmen senden kann und jeder Teilnehmer über die Kennung für ihn bestimmte Rahmen ermittelt und empfängt, dadurch gekennzeichnet, dass das Steuergerät einen Bootstrap- Loader enthält und im Steuergerät Mittel enthalten sind, die wenigstens einen Rahmen mit einer von der vorgegebenen Übertragungsrate verschiedenen Übertragungsrate ermitteln können und nachfolgend den Bootstrap-Loader aktivieren.

11. Prüf- und/oder Programmier-System, als zweiter Teilnehmer an einem Bussystem, wobei über das Bussystem Daten zu einem ersten Teilnehmer durch den zweiten Teilnehmer übertragen werden, wobei das Bussystem eine vorgebbare und für alle Teilnehmer gültige Übertragungsrate aufweist, mit der alle Teilnehmer im Betrieb kommunizieren, wobei die Übertragung der Daten in Form von Rahmen durchgeführt wird und ein solcher Rahmen eine Kennung enthält, wobei jeder Teilnehmer gleichberechtigt Rahmen senden kann und jeder Teilnehmer über die Kennung für ihn bestimmte Rahmen ermittelt und empfängt, dadurch gekennzeichnet, dass der zweite Teilnehmer Mittel enthält, welche wenigstens einen Datenrahmen mit einer von der vorgegebenen Übertragungsrate verschiedenen Übertragungsrate bilden und an den ersten Teilnehmer übertragen und nachfolgend die Daten an den ersten Teilnehmer übertragen.

12. Bussystem über das Daten zu einem ersten Teilnehmer durch einen zweiten Teilnehmer übertragen werden, wobei das Bussystem eine vorgebbare und für alle Teilnehmer gültige Übertragungsrate aufweist, mit der alle Teilnehmer im Betrieb kommunizieren, wobei die Übertragung der Daten in Form von Rahmen durchgeführt wird und ein solcher Rahmen eine Kennung enthält, wobei jeder Teilnehmer gleichberechtigt Rahmen senden kann und jeder Teilnehmer über die Kennung für ihn bestimmte Rahmen ermittelt und empfängt, dadurch gekennzeichnet, das auf dem Bussystem Rahmen definiert sind, die mit wenigstens einer von der vorgegebenen Übertragungsrate verschiedenen Übertragungsrate über das Bussystem übertragen werden.