Beschreibung

Titel

Gateway zum automatischen Routen von Nachrichten zwischen Bussen

Die vorliegende Erfindung betrifft ein Gateway zum automatischen Routen von Nachrichten zwischen Bussen, insbesondere zwischen seriellen Bussen und Feldbussen.

Die Vernetzung von Steuergeräten, Sensorik und Aktuatorik mithilfe eines Netzwerkes bzw. Kommunikationssystems bestehend aus einer Kommunikationsverbindung, insbesondere einem Bus, und entsprechenden Kommunikationsbausteinen, hat in den letzten Jahren beim Bau von modernen Kraftfahrzeugen oder auch im Maschinenbau, insbesondere im Werkzeugmaschinenbereich als auch in der Automatisierung drastisch zugenommen. Synergieeffekte durch Verteilung von Funktionen auf mehrere Teilnehmer, insbesondere Steuergeräte, können dabei erzielt werden. Man spricht hierbei von verteilten Systemen. Solche verteilten Systeme oder Netzwerke bestehen somit aus den Teilnehmern und dem diese Teilnehmer verbindenden Bussystem oder mehreren verbindenden Bussystemen. Die Kommunikation zwischen verschiedenen Stationen bzw. Teilnehmern findet damit mehr und mehr über ein solches Kommunikationssystem, Bussystem oder Netzwerk statt, über welches die zu übertragenden Daten in Botschaften übermittelt werden. Dieser Kommunikationsverkehr auf dem Bussystem, Zugriffs- und Empfangsmechanismen sowie Fehlerbehandlung werden über ein entsprechendes Protokoll geregelt, wobei der Name des jeweiligen Protokolls häufig und so auch hier als Synonym für das Netzwerke bzw. das Bussystem selbst verwendet wird.

Als Protokoll beispielsweise hat sich der CAN-Bus (Controller Area Network) im Kfz-Bereich etabliert. Dieses ist ein ereignisgesteuertes Protokoll, d. h. Protokollaktivitäten wie das Senden einer Nachricht werden durch Ereignisse initiiert, die ihren Ursprung außerhalb des Kommunikationssystems haben. Der eindeutige Zugang zum Kommunikationssystem bzw. Bussystem wird über eine prioritätsbasierte Bitarbitrierung gelöst. Eine Vorraussetzung dafür ist, dass den zu übertragenden Daten und damit jeder Botschaft eine Priorität zugewiesen ist. Das CAN-Protokoll ist sehr flexibel; ein Hinzufügen weiterer Teilnehmer und Botschaften ist damit problemlos möglich, solange es noch freie Prioritäten (Message Identifier) gibt. Die Sammlung aller im Netzwerk zu sendenden Botschaften mit Prioritäten und deren senden-

den bzw. empfangenden Teilnehmer bzw. den entsprechenden Kommunikationsbausteinen werden in einer Liste, der so genannten Kommunikationsmatrix, abgelegt.

Ein alternativer Ansatz zur ereignisgesteuerten, spontanen Kommunikation ist der rein zeit- gesteuerte Ansatz. Alle Kommunikationsaktivitäten auf dem Bus sind strikt periodisch. Protokollaktivitäten wie das Senden einer Botschaft werden nur durch das Fortschreiben einer für das gesamte Bussystem gültigen Zeit ausgelöst. Der Zugang zu diesem Medium basiert auf der Zuteilung von Zeitbereichen, in denen ein Sender exklusives Senderecht hat. Dabei ist die Botschaftsreihenfolge in der Regel schon vor Inbetriebnahme festzusetzen. Es wird also ein Fahrplan erstellt, der den Anforderungen der Botschaften bezüglich Wiederholrate, Redundanz, Deadlines usw. genügt. Man spricht vom so genannten Bus-Schedule. Ein solches Bussystem ist beispielsweise das TTP/C.

Eine Verbindung der Vorteile beider genannter Busarten erfolgt im Lösungsansatz des zeit- gesteuerten CAN, des so genannten TTCAN (Time Triggered Controller Area Network). Dieser genügt den oben skizzierten Forderungen nach zeitgesteuerter Kommunikation sowie den Forderungen nach einem gewissen Maß an Flexibilität. Der TTCAN erfüllt dies durch den Aufbau der Kommunikationsrunde in so genannten exklusiven Zeitfenstern für periodische Botschaften bestimmter Kommunikationsteilnehmer und in so genannte arbitrierende Zeitfenster für spontane Botschaften mehrerer Kommunikationsteilnehmer. TTCAN basiert dabei im Wesentlichen auf einer zeitgesteuerten, periodischen Kommunikation, die durch einen hauptzeitgebenden Teilnehmer bzw. Kommunikationsbaustein, den so genannten Zeitmaster mit Hilfe einer Zeitreferenznachricht getaktet wird.

Eine weitere Möglichkeit verschiedene übertragungsarten zu verbinden bietet das FlexRay- Protokoll, wodurch ein schnelles, deterministisches und fehlertolerantes Bussystem insbesondere für den Einsatz in einem Kraftfahrzeug beschreiben wird. Dieses Protokoll arbeitet nach dem Verfahren des Time- Division- Multiple- Access (TDMA), wobei den Teilnehmern bzw. den zu übertragenden Botschaften feste Zeitschlitze zugewiesen werden, in denen sie exklusiven Zugriff auf die Kommunikationsverbindung, den Bus haben. Die Zeitschlitze wiederholen sich dabei in einem festgelegten Zyklus, sodass der Zeitpunkt zu dem eine Botschaft über den Bus übertragen wird, exakt vorausgesagt werden kann und der Buszugriff deterministisch erfolgt. Um die Bandbreite für die Botschaftsübertragung auf dem Bussystem optimal zu nutzen, wird der Zyklus in einen statischen und einen dynamischen Teil unterteilt. Die festen Zeitschlitze befinden sich dabei im statischen Teil am Anfang eines Buszyklusses. Im dynamischen Teil werden die Zeitschlitze dynamisch vergeben nach dem Verfahren des Flexible-Time-Division-Multiple-Access (FTDMA). Darin wird nun der exklusive Buszugriff

jeweils nur für eine kurze Zeit ermöglicht. Erfolgt kein Zugriff, wird der Zugriff für den nächsten Teilnehmer freigegeben. Diese Zeitspanne wird als Minislot bezeichnet, in der auf den Zugriff des ersten Teilnehmers gewartet wird.

Wie soeben dargestellt gibt es eine Vielzahl unterschiedlicher übertragungstechnologien und damit Arten von Bussystemen oder Netzwerken. Häufig ist es so, dass mehrere Bussysteme gleicher oder unterschiedlicher Art miteinander verbunden werden müssen. Dazu dient eine Busschnittstelleneinheit, ein so genanntes Gateway. Ein Gateway ist somit eine Schnittstelle zwischen verschiedenen Bussen, die von gleicher oder unterschiedlicher Art sein können, wobei das Gateway (Teil-) Botschaften von einem Bus auf einen oder mehrere andere Busse weiterleitet. Bekannte Gateways bestehen aus mehreren unabhängigen Kommunikationsbausteinen, wobei der Austausch von Botschaften dabei über die Prozessorschnittstelle (CPU- Interface) des jeweiligen Teilnehmers bzw. den entsprechenden Schnittstellenbaustein des jeweiligen Kommunikationsbausteins erfolgt. Dabei wird dieses CPU-Interface durch diesen Datenaustausch und weitere applikative Funktionen zusätzlich zu den zum Teilnehmer selbst zu übertragenden Botschaften stark belastet, wodurch sich zusammen mit der sich daraus ergebenden übertragungsstruktur eine relativ niedrige Datenübertragungsgeschwindigkeit oder anderseits eine hohe Taktfrequenz mit hoher Leistungsaufnahme ergibt. Weiterhin gibt es integrierte Kommunikationscontroller oder Kommunikationsbausteine, die sich einen gemeinsamen Botschaftsspeicher, das so genannte Nachrichtenspeicher bzw. Message- RAM, teilen um damit die Strukturnachteile zu kompensieren. Allerdings sind solche integrierten Kommunikationsbausteine dadurch bezüglich der Datenübertragung sehr unflexibel und insbesondere auf eine bestimmte Anzahl von Busanschlüssen und meist auch auf das gleiche Bussystem festgelegt.

Figur 1 zeigt einen herkömmlichen Kommunikationsbaustein bzw. Kommunikationscontroller CC für ein herkömmliches Gateway, wie es in Figur 2 dargestellt ist. Der Kommunikationsbaustein CC weist ein Interface für einen internen Peripheriebus bzw. Systembus des Gateways und ein weiteres Interface für einen externen seriellen Bus auf. Der Systembus umfasst einen Adressbus, einen Datenbus und einen Steuerbus und dient zur internen Datenübertragung innerhalb des Gateways. An dem Systembus sind neben dem Kommunikationsbaustein eine Host-CPU mit einem Datenspeicher RAM sowie weitere optionale Komponenten, z.B. DMA-Controller, angeschlossen. Die Host-CPU dient zur internen Datenverarbeitung und steuert den internen Datentransfer von einem Kommunikationsbaustein CC zu einem anderen Kommunikationsbaustein CC. Die Kommunikationsbausteine CC kommunizieren mit der Host-CPU nach dem Master-/Slave- Prinzip, wobei Kommunikationsbausteine Slave- Einheiten darstellen und die Host-CPU eine Master- Einheit bildet.

Wie man aus Figur 1 erkennen kann, wird die interne Schnittstelle des Kommunikationsbausteins CC zu dem Systembus durch ein zweischichtiges Interface gebildet, nämlich durch ein Customer- Interface und ein generisches Interface. Das Customer-Interface verbindet den Systembus mit dem generischen Interface, wobei das Customer-Interface herstellerspezifisch und leicht austauschbar ist. Das generische Interface ist über das Customer-Interface an eine große Anzahl von kundenspezifischen Systembussen anschließbar. Der Kommunikationsbaustein CC nach dem Stand der Technik und wie er in Figur 1 dargestellt ist, enthält ferner Pufferspeicher zum Zwischenspeichern von zu transferierenden Daten. Die Puffer- Speicher werden beispielsweise durch RAM- oder Datenregister gebildet. Der Kommunikationsbaustein CC enthält ferner eine Nachrichtenweiterleitungseinheit bzw. einen Message- Handler zur Weiterleitung von Nachrichten von mindestens einem Nachrichtenspeicher und einer Kommunikationsprotokolleinheit, sowie Pufferspeichern. Der Nachrichtenspeicher bzw. das Message- RAM speichert die zu transferierenden Nachrichtenobjekte sowie Konfigurati- ons- und Statusinformationsdaten zwischen. Die Nachrichtenweiterleitungseinheit übernimmt die Steuerung des Datenflusses zwischen allen Pufferspeichern, der Kommunikationsprotokolleinheit und dem Nachrichtenzwischenspeicher. Die Kommunikationsprotokolleinheit (PRT) des in Figur 1 dargestellten herkömmlichen Kommunikationsbausteins CC implementiert die Kommunikation gemäß dem eingesetzten Datenübertragungsprotokoll. Dabei über- nimmt die Kommunikationsprotokolleinheit PRT die Umwandlung bzw. Umsetzung zwischen dem Datenformat der über den externen seriellen Bus übertragenen Datenpakete DP und den innerhalb des Kommunikationsbausteins verwendeten Nachrichten bzw. Messages MSG. Die von der Nachrichtenweiterleitungseinheit bzw. dem Message-Handler weitergeleiteten Nachrichten MSG bestehen dabei zumindest aus einem Datenwort DW, wobei die Wortlänge bzw. die Bitzahl des Datenwortes DW vorzugsweise der Busbreite des internen vorgesehenen Datenbusses des Gateways entspricht. Weist der Systembus beispielsweise einen 32 Bit breiten internen Datenbus auf, umfasst das Datenwort DW ebenfalls 32 Bit. Eine Nachricht bzw. Message MSG kann aus einer vorgegebenen Anzahl von Datenworten DW bestehen. Die Speicherkapazität eines Pufferspeichers entspricht beispielsweise dem Da- tenumfang einer Nachricht bzw. einer Message, die eine vorgegebene Anzahl von Datenworten DW umfasst. Die Arbitrierung des Datenflusses wird durch die Nachrichtenweiterlei- tungseinheit bzw. den Message-Handler vorgenommen.

Insbesondere in Fahrzeugen kommen heutzutage mehrere serielle Busse und Feldbusse, beispielsweise serielle Feldbusse wie ein CAN-Bus, ein FlexRay-Bus, ein MOST-Bus oder ein LIN-Bus zum Einsatz. Während des Betriebs werden zwischen diesen seriellen Bussen, die einen Teil eines Netzwerkes bilden können, Daten über ein Gateway GW ausgetauscht.

Abhängig von dem Fahrzeug und den durchgeführten Funktionen kann dabei das Datenaufkommen in dem zentralen Gateway GW, wie es in Figur 2 dargestellt ist, sehr hoch sein. Dieses Datenaufkommen verursacht eine hohe CPU-Last, d. h. die CPU wird damit belastet, Daten von einem seriellen Bus auf einen oder mehrere andere serielle Busse zu routen. Fer- ner wird die CPU-Last durch Operationen erhöht, die zur Reduzierung von Bandbreite in einzelnen Netzwerken bzw. seriellen Bussen benötigt werden, beispielsweise die Kombination der Dateninhalte mehrerer Nachrichten bzw. Messages zu einer neuen Nachricht.

In vielen Fällen ist es erforderlich, Nachrichten zur Erfüllung von Sicherheitsanforderungen periodisch in einem vorgegebenen Zeitraster zu senden. Bei hochprioren Nachrichten kann die sofortige übermittlung der Nachricht ohne Zeitraster bzw. außerhalb des Zeitrasters erforderlich sein. Die überprüfung, ob eine Nachricht erneut gesendet werden soll bzw. eine Nachricht wegen eines aufgetretenen Fehlers, beispielsweise einer ausgebliebenen Nachricht, nicht mehr gesendet werden darf, erfolgt ebenfalls durch die CPU des Gateways GW und verbraucht Rechenleistung der CPU.

In vielen Fällen führt die CPU weitere Funktionen parallel durch d. h., auf der CPU laufen parallele Verarbeitungsprozesse ab, die sich gegenseitig negativ beeinflussen und das Senden bzw. das Weiterleiten einer Nachricht verzögern. Durch diese parallel ablaufenden Pro- zesse erhöhen sich der Jitter sowie die Latenzzeiten für die übertragung der Nachrichten, da eine Unterbrechung der parallel ablaufenden Prozesse in vielen Fällen nicht möglich ist.

Es ist daher die Aufgabe der vorliegenden Erfindung, ein Gateway zum automatischen Routen von Nachrichten zwischen Bussen zu schaffen, welches Nachrichten ohne Beeinflussung der CPU und unabhängig von einer CPU-Last weiterleitet.

Diese Aufgabe wird erfindungsgemäß durch ein Gateway mit den im Patentanspruch 1 angegebenen Merkmalen gelöst.

Die Erfindung schafft ein Gateway zum automatischen Routen von Nachrichten zwischen Bussen mit:

- mehreren Kommunikationsbausteinen zum Zwischenspeichern und übertragen von Nachrichten N über die Busse; und mit

- einer Gateway-Steuereinheit, die über einen Systembus zum Austausch von Nachrichten N mit den Kommunikationsbausteinen verbunden ist, und die von jedem Kommunikationsbau-

stein das dortige Auftreten einer zu routenden Nachricht N als externes Ereignis EV _ext angezeigt erhält,

wobei die Gateway-Steuereinheit aufweist:

- einen Vektorspeicher VRAM mit einem ersten Speicherbereich zum Speichern von Kommunikationsbaustein-Vektoren KBV, wobei für jeden Kommunikationsbaustein ein Kommunikationsbaustein-Vektor KBV vorgesehen ist, der den Zeitpunkt ZP eines als nächstes zu erwartenden internen Ereignisses EV _mt für eine in dem Kommunikationsbaustein zwischenge- speicherte Nachricht N und eine Vektorsprungadresse auf einen Nachrichtenvektor NV angibt, der in einem zweiten Speicherbereich des Vektorspeichers VRAM gespeichert ist, wobei für jede in dem Kommunikationsbaustein zwischengespeicherte relevante Nachricht N ein entsprechender Nachrichtenvektor NV gespeichert ist, der einen konfigurierbaren Zeitpunkt ZP eines von der zugehörigen Nachricht N auszulösenden internen Ereignisses EV _ιnt , eine Befehlssprungadresse angibt, sowie weitere Konfigurations- und Steuerdaten;

- einen Befehlsspeicher IRAM zum Speichern von Befehlen, die durch die in dem Nachrichtenvektor NV angegebene Befehlssprungadresse adressierbar sind; und

- ein Statusregister SR auf, welches denjenigen Zeitpunkt für das nächste zu erwartende Ereignis von allen zu erwartenden internen Ereignissen für alle in den Kommunikationsbausteinen zwischengespeicherten Nachrichten N zwischenspeichert.

- eine Ablaufsteuerung FSM, die bei Auftreten eines internen Ereignisses EV _mt dessen Zeit- punkt ZP in einem Statusregister SR für alle in den Kommunikationsbausteinen zwischengespeicherten Nachrichten N zwischengespeichert ist oder bei Auftreten eines externen Ereignisses EV _ext , das der Ablaufsteuerung FSM durch einen Kommunikationsbaustein angezeigt wird, den zu dem jeweiligen Kommunikationsbaustein zugehörigen Kommunikationsbaustein-Vektor KBV aus dem ersten Speicherbereich des Vektorspeichers VRAM ausliest und mittels der darin enthaltenen Vektorsprungadresse die Befehlssprungadresse des adressierten Nachrichtenvektors NV aus dem zweiten Speicherbereich des Vektorspeichers VRAM ausliest und anschließend mittels der ausgelesenen Befehlssprungadresse mindestens einen Befehl aus dem Befehlsspeicher IRAM ausliest und ausführt, wobei die in den Vektoren NV, KBV angegebenen Zeitpunkte ZP aktualisiert werden.

Bei einer Ausführungsform des erfindungsgemäßen Gateways weist dieses mindestens einen weiteren Prozessor auf, der über einen zweiten separaten Systembus mit den Kommunikationsbausteinen verbunden ist.

Bei einer Ausführungsform des erfindungsgemäßen Gateways weist die Ablaufsteuerung der Gateway-Steuereinheit eine Ereignis- FS M, welche bei Auftreten eines internen oder eines externen Ereignisses EV _ext die in dem Vektorspeicher VRAM gespeicherten Vektoren KBV, NV auswertet und die in den Vektoren angegebenen Zeitpunkte aktualisiert; und eine Befehls- FS M auf, welche die aus dem Befehlsspeicher IRAM ausgelesenen Befehle ausführt.

Bei einer Ausführungsform des erfindungsgemäßen Gateways weist ein Nachrichtenvektor NV zusätzlich eine Zeitdifferenz t zwischen dem Zeitpunkt eines von der zugehörigen Nachricht N auszulösenden internen oder externen Ereignis und einem Zeitpunkt des nächsten von der zugehörigen Nachricht N auszulösenden internen Ereignisses EV _mt auf.

Bei einer Ausführungsform des erfindungsgemäßen Gateways weist die Gateway- Steuereinheit einen Zähler Z als internen Zeitgeber zum Auslösen eines internen Ereignisses EV _mt auf.

Bei einer Ausführungsform des erfindungsgemäßen Gateways werden die Busse durch serielle Busse gebildet.

Bei einer Ausführungsform des erfindungsgemäßen Gateways weist jeder Kommunikations- baustein auf:

- eine an den seriellen Bus angeschlossene Kommunikations- Protokolleinheit zur Umsetzung zwischen Datenpaketen DP und Nachrichten, die jeweils aus mehreren Datenworten DW bestehen;

- eine Nachrichtenweiterleitungseinheit zur Weiterleitung von Nachrichten zwischen mindestens einem Nachrichtenspeicher und der Kommunikations-Protokolleinheit sowie Pufferspeichern;

- mehrere Interface- Einheiten , die jeweils an einen zugehörigen Systembus des Gateways angeschlossen sind, wobei jede Interface- Einheit mit mindestens einem zugehörigen Pufferspeicher verbunden ist, der eine Nachricht zwischenspeichert, wobei eine übertragung von

Datenworten DW über mehrere Systembusse und deren zugehörige Interface- Einheiten von und zu den Pufferspeichern der Interface- Einheiten zeitgleich ohne Wartezeit erfolgt.

Bei einer Ausführungsform des erfindungsgemäßen Gateways ist der serielle Bus ein FeId- bus.

Bei einer Ausführungsform des erfindungsgemäßen Gateways ist der Feldbus ein CAN (Controller Area Network)-Bus.

Bei einer Ausführungsform des erfindungsgemäßen Gateways ist der Feldbus ein LIN (Local Interconnect Network)-Bus.

Bei einer Ausführungsform des erfindungsgemäßen Gateways ist der Feldbus ein FlexRay- Bus.

Bei einer Ausführungsform des erfindungsgemäßen Gateways ist der serielle Bus ein Ethernet- Bus.

Bei einer Ausführungsform des erfindungsgemäßen Gateways weist jeder der beiden Sys- tembusse einen zugehörigen Systembus- Master auf.

Bei einer Ausführungsform des erfindungsgemäßen Gateways signalisiert die Nachrichten- weiterleitungseinheit eines Kommunikationsbausteins den Empfang einer über den Systembus wortweise übertragenen Nachricht an den Systembus- Master des Systembusses.

Bei einer Ausführungsform des erfindungsgemäßen Gateways bestätigt die Nachrichtenwei- terleitungseinheit dem Systembus- Master den Erhalt einer zu übertragenden Nachricht durch Signale, nachdem dieser die Information angefragt hat.

Bei einer Ausführungsform des erfindungsgemäßen Gateways weist eine von dem jeweiligen Systembus empfangene Nachricht, welche in einem Pufferspeicher zwischengespeichert ist und von der Nachrichtenweiterleitungseinheit an den Nachrichtenspeicher weitergeleitet wird zur Signalisierung einer Sendebereitschaft über den seriellen Bus mindestens ein Flag-Bit auf.

Im Weiteren werden bevorzugte Ausführungsformen des erfindungsgemäßen Gateways unter Bezugnahme auf die beigefügten Figuren zur Erläuterung erfindungswesentlicher Merkmale beschrieben.

Es zeigen:

Figur 1: einen Kommunikationsbaustein nach dem Stand der Technik;

Figur 2: ein Gateway nach dem Stand der Technik;

Figur 3: ein Blockschaltbild einer möglichen Ausführungsform des erfindungsgemäßen Gateways;

Figur 4: ein Blockschaltbild einer möglichen Ausführungsform eines Kommunikationsbau- steins innerhalb des erfindungsgemäßen Gateways;

Figur 5: ein Blockschaltbild einer möglichen Ausführungsform einer in dem erfindungsgemäßen Gateway enthaltenen Gateway-Steuereinheit;

Figur 6: ein Diagramm zur Darstellung eines Speicherinhalts eines in dem erfindungsgemäßen Gateway enthaltenen Vektorspeichers;

Figur 7: ein Diagramm zur Darstellung des Dateninhalts des in dem erfindungsgemäßen Gateway enthaltenen Befehlsspeichers;

Figur 8: ein Signaldiagramm zur Darstellung eines Beispiels zur Nachrichtenweiterleitung durch das erfindungsgemäße Gateway;

Figur 9: ein Signaldiagramm zur Darstellung eines weiteren Beispiels zur Nachrichtenweiter- leitung durch das erfindungsgemäße Gateway;

Figur 10: ein Signaldiagramm zur Darstellung eines weiteren Beispiels zur Nachrichtenweiterleitung durch das erfindungsgemäße Gateway;

Figur 11: ein Signaldiagramm zur Darstellung eines weiteren Beispiels zur Weiterleitung von Nachrichten durch das erfindungsgemäße Gateway;

Figur 12: ein Signaldiagramm zur Darstellung eines weiteren Beispiels zur Weiterleitung von Nachrichten durch das erfindungsgemäße Gateway.

Wie man aus Figur 3 erkennen kann, weist das erfindungsgemäße Gateway 1 mehrere Kommunikationsbausteine 2-i auf, die jeweils an einen seriellen Bus 3-i anschließbar sind. Bei den seriellen Bussen 3-i handelt es sich beispielsweise um einen Feldbus oder einen Ethernet-Bus. über die seriellen Busse 3-i werden Daten als Nachrichten übertragen. übertragene Datenpakete bzw. Nachrichten umfassen Verwaltungs- bzw. Header- Daten sowie Nutz- bzw. Payload- Daten. Das erfindungsgemäße Gateway 1 gemäß der in Figur 3 darge- stellten Ausführungsform weist mehrere Master- Einheiten auf, wobei eine erste Master- Einheit durch eine Gateway-Steuereinheit 4-1 und eine zweite Master- Einheit durch eine CPU 4-2 gebildet wird. Die beiden Master- Einheiten 4-1, 4-2 übernehmen unterschiedliche Funktionen. Bei der in Figur 3 dargestellten Ausführungsform ist die Gateway-Steuereinheit 4-1 für den Datentransfer zwischen den verschiedenen Kommunikationsbausteinen 2-i zu- ständig. Die andere Master- Einheit, die durch einen Prozessor 4-2 bestehend aus einer

Host-CPU und einem internen Speicher RAM gebildet wird, führt die eigentliche Datenverarbeitung beispielsweise einer neben dem Gateway integrierten Steuergerätefunktion durch. Bei der in Figur 3 dargestellten Ausführungsform weist jede Master- Einheit 4-1, 4-2 vorzugsweise ihren eigenen Systembus 5-1, 5-2 auf. Jeder Systembus 5-1, 5-2 weist seinerseits seinen eigenen Daten-, Adress- und Steuerbus auf. Innerhalb des Gateways 1 werden die Daten bei einer möglichen Ausführungsform wortweise übertragen, wobei die Länge eines Datenwortes DW der Busbreite des jeweiligen Datenbusses des Systembusses entspricht. Die Kommunikationsbausteine 2-i weisen bei einer möglichen Ausführungsform für jeden Systembus 5-i ein ebenfalls vorzugsweise zugehöriges Interface auf.

Figur 4 zeigt eine mögliche Ausführungsform eines Kommunikationsbausteins 2-i. Der Kommunikationsbaustein 2-i dient zum Anschluss eines seriellen Busses 3 über ein Interface, wobei der Kommunikationsbaustein 2-i für jeden internen Systembus 5-i des Gateways 1 ein eigenes getrenntes Interface 2a, 2b aufweist. Bei der in Figur 4 dargestellten Ausführungs- form weist der Kommunikationsbaustein 2-i ein erstes Interface 2a zum Anschluss an den Systembus 5-1 auf, dessen Master- Einheit durch die Gateway-Steuereinheit 4-1 gebildet wird. Darüber hinaus weist der Kommunikationsbaustein 2-i ein weiteres Interface 2b zum Anschluss an den Systembus 5-2 des Gateways 1 auf, dessen Bus-Master durch die Host- CPU des Prozessors 4-2 gebildet wird. An den externen seriellen Datenbus 3-i ist eine Kommunikationsprotokolleinheit 2c des Kommunikationsbausteins 2-i angeschlossen. Die Kommunikationsprotokolleinheit 2c führt eine Umsetzung zwischen Datenpaketen bzw. Nachrichten durch, welche extern über den seriellen Datenbus 3-i übertragen werden und

sendet mit Hilfe des Message Handlers intern Nachrichten bzw. Messages aus, die jeweils aus einem oder mehreren Datenworten DW bestehen können.

Der Kommunikationsbaustein 2-i in Figur 4 enthält ferner eine Nachrichtenweiterleitungsein- heit bzw. einen Message-Handler 2d zur Weiterleitung von Nachrichten zwischen mindestens einem internen Nachrichtenspeicher bzw. Message- RAM 2e und der Kommunikationsprotokolleinheit 2c sowie verschiedenen Pufferspeichern 2f, 2g über interne Datenleitungen 2h. Die Speicherkapazität eines Pufferspeichers 2f, 2g entspricht vorzugsweise dem Daten- umfang einer intern zu übertragenden Nachricht, sowie weiterer Verwaltungsdaten. Der Kommunikationsbaustein 2-i weist mehrere Interface- Einheiten 2a, 2b auf, die jeweils an einen zugehörigen Systembus 5-i des Gateways 1 angeschlossen sind. Dabei ist jede Interface-Einheit 2a, 2b mit mindestens einem zugehörigen Pufferspeicher 2f, 2g verbunden, in der mindestens eine Nachricht bzw. Message bzw. ein Message-Objekt MO zwischenspeicherbar ist.

Der Zugriff der Gateway-Steuereinheit 4-1 auf ein Message-Objekt MO bzw. eine Nachricht N erfolgt über das Gateway- Interface 2a und dessen zugehöriges Interface- Register 2f. Die CPU 4-2 greift über das Customer-Interface 5-2 und dessen zugehörigem Interface- Register 2g auf Nachrichten bzw. Message-Objekte zu. Somit ist sowohl von der Gateway- Steuereinheit 4-1 als auch von der Prozessoreinheit 4-2 der Zugriff auf alle Nachrichten bzw. Message-Objekte ohne gegenseitige Beeinflussung möglich.

Figur 5 zeigt eine mögliche Ausführungsform einer in dem erfindungsgemäßen Gateway 1 enthaltenen Gateway-Steuereinheit 4-1. Die Gateway -Steuerein heit 4-1 ist über den zugehö- rigen Systembus 5-1 zum Austausch von Nachrichten mit den Kommunikationsbausteinen 2- i verbunden. Dabei erhält sie von jedem Kommunikationsbaustein 2-i das dortige Auftreten einer zu routenden Nachricht N bzw. eines zu routenden Message-Objekts MO als externes Ereignis EV _ext angezeigt. Wie man aus Figur 3 erkennen kann, ist jeder Kommunikationsbaustein 2-i mit mindestens einer Anzeigeleitung zur Anzeige eines Ereignisses bzw. eines Events mit der Gateway-Steuereinheit 4-1 verbunden. Bei einer möglichen Ausführungsform weist der in Figur 4 dargestellte Kommunikationsbaustein 2-i mehrere parallele Nachrichtenregister für jedes Interface zum Speichern von einer Nachricht pro Nachrichtenregister auf. Bei einer möglichen Ausführungsform sind die Nachrichten dabei in mehrere Gruppen eingeteilt, beispielsweise in m Gruppen. Bei einer möglichen Ausführungsform ist die Anzahl der vorgesehenen Nachrichtengruppen innerhalb eines Kommunikationsbausteins 2-i m = 4. Der Message-Handler 2d des Kommunikationsbausteins 2-i zeigt bei Auftreten eines externen Ereignisses EV _ext , beispielsweise den Empfang einer weiterzuleitenden Nachricht der Gate-

way-Steuereinheit 4-1 über eine entsprechende Anzeigeleitung an. Bei einer möglichen Ausführungsform ist für jede Gruppe von Nachrichten eine eigene Anzeigeleitung vorgesehen, beispielsweise m = 4 Anzeigeleitungen. Beträgt die Anzahl der Kommunikationsbausteine 2-i N unter der Annahme das alle Kommunikationsbausteine 2-i ein identisches N haben und beträgt die Anzahl von Gruppen innerhalb des Kommunikationsbausteins 2-i m, dann ist die Anzahl der Anzeigeleitungen für externe Events bzw. Ereignisse N x m.

Wie man aus Figur 5 erkennen kann, ist die Gateway-Steuereinheit 4-1 über den Systembus 5-1 mit den Kommunikationsbausteinen 2-i verbunden und erhält von jedem Kommunikati- onsbaustein 2-i das dortige Auftreten einer zu routenden Nachricht als externes Ereignis EV _ext über eine Anzeigeleitung angezeigt. Die Gateway-Steuereinheit 4-i enthält einen Vektorspeicher (VRAM) dessen Speicherinhalt in Figur 6 dargestellt ist. Darüber hinaus enthält die Gateway-Steuereinheit 4-1 einen Befehlsspeicher bzw. Instruction RAM (IRAM) zum Speichern von Befehlen dessen Speicherinhalt in Figur 7 dargestellt ist. Das zentrale Steu- erelement der Gateway-Steuereinheit 4-1 wird durch eine Ablaufsteuerung bzw. einen Zustandsautomaten (FSM: Finite State Machine) gebildet, der sich aus einer Ereignis-FSM und einer davon getrennten Befehls- FS M zusammensetzt. Weiterhin enthält die Gateway- Steuereinheit 4-1 ein Statusregister SR und einen Zähler Z als Zeitgeber zum Auslösen von internen Ereignissen EV _mt . Die Gateway-Steuereinheit 4-1 ist über ein Systembus-Interface SBI mit dem Systembus 5-1 verbunden. Der Vektorspeicher bzw. VRAM, wie er in Figur 6 dargestellt ist, enthält im Wesentlichen drei Speicherbereiche. In einem ersten Speicherbereich befinden sich Konfigurationsdaten der Kommunikationsbausteine 2, d. h. für jeden Kommunikationsbaustein 2-i ist pro Nachrichtengruppe ein Kommunikationsbaustein-Vektor KBV abgespeichert. Der Kommunikationsbaustein-Vektor KBV speichert für den zugehörigen Kommunikationsbaustein 2-i denjenigen Zeitpunkt ZP, der das nächste zu erwartende interne Ereignis EV _mt für eine in dem Kommunikationsbaustein 2-i zwischengespeicherte Nachricht N angibt. Zusätzlich weist der Kommunikationsbaustein-Vektor KBV eine Vektorsprungadresse VSA auf einen Nachrichtenvektor NV für die entsprechende Nachricht N auf. Zusätzlich weist jeder Kommunikationsbaustein-Vektor KBV weitere Konfigurationsdaten für den entsprechenden Kommunikationsbaustein 2-i auf. Ein mögliches Konfigurationsdatum wird durch ein CC-Flag gebildet, welches anzeigt, ob ein Kommunikationsbaustein 2 bzw. Communication Controller aktiviert bzw. deaktiviert ist. Weist der Kommunikationsbaustein 2 mehrere Gruppen von Nachrichten N auf, wird ein Kommunikationsbaustein-Vektor KBV für jede Gruppe von Nachrichten innerhalb des Kommunikationsbausteins 2 vorgesehen.

Der Vektorspeicher VRAM innerhalb der Gateway-Steuereinheit 4-1 enthält ferner einen zweiten Speicherbereich, in dem für jede Nachricht N bzw. für jede Message MSG Konfigu-

rationsdaten als Nachrichtenvektoren NV abgespeichert sind. Für jede relevante Message bzw. Nachricht N ist ein Nachrichtenvektor NV in dem Vektorspeicher VRAM abgelegt. Für jede in einem Kommunikationsbaustein 2-i zwischengespeicherte Nachricht N ist ein entsprechender N ach richten vektor NV vorgesehen bzw. in dem VRAM abgespeichert, der einen konfigurierbaren Zeitraum ZP eines von der zugehörigen Nachricht N auszulösenden internen Ereignisses EV _ιnt sowie eine Befehlssprungadresse BSA angibt.

Bei einer möglichen Ausführungsform des erfindungsgemäßen Gateways 1 weist der Nachrichtenvektor NV zusätzlich eine Zeitdifferenz δt zwischen dem Zeitpunkt ZP eines von der zugehörigen Nachricht N auszulösenden internen oder externen Ereignis und einem weiteren Zeitpunkt ZP des nächsten von der zugehörigen Nachricht N auszulösenden internen Ereignisses auf.

Neben den Speicherbereichen für die Kommunikationsbaustein-Vektoren KBV und dem zweiten Speicherbereich für die Nachrichtenvektoren NV weist der Vektorspeicher VRAM ferner einen frei verfügbaren dritten Speicherbereich auf, in dem Variablen zwischengespeichert werden und in dem Konstanten und Flags abgespeichert sind. Darüber hinaus dient der frei verfügbare dritte Speicherbereich des Vektorspeichers VRAM zum Datenaustausch mit der CPU 4-2.

Die in dem zweiten Speicherbereich des Vektorspeichers VRAM abgespeicherten Nachrichtenvektoren NV weisen eine Befehlssprungadresse BSA auf, durch die mindestens eine Befehlsubroutine innerhalb des Befehlsspeichers IRAM adressierbar ist. Für jede Nachricht N ist in dem zweiten Speicherbereich des Vektorspeichers VRAM ein Nachrichtenvektor NV gespeichert, der jeweils eine Befehlssprungadresse BSA auf eine Subroutine innerhalb des Befehlsspeichers IRAM aufweist. Eine derartige Befehlssequenz bzw. Subroutine ist einem der jeweiligen Nachricht zugeordneten Speicherbereich im IRAM abgelegt. Die Größe des Speicherbereichs ist vorzugsweise variabel. Ferner ist die Position des Speicherbereichs innerhalb des Befehlsspeichers IRAM ebenfalls variabel.

In der Gateway-Steuereinheit 4-1 ist neben dem Vektorspeicher VRAM und dem Befehlsspeicher IRAM eine Ablaufsteuerung FSM vorgesehen, die eine Ereignis-FSM und eine Be- fehls-FSM aufweist. Die Ereignis-FSM der Ablaufsteuerung wertet bei Auftreten eines internen oder eines externen Ereignisses die in dem Vektorspeicher VRAM gespeicherten Vekto- ren, d. h. die Kommunikationsbaustein- Vektoren KBV und die Nachrichtenvektoren NV aus und aktualisiert die in den jeweiligen Vektoren angegebenen Zeitpunkte.

Darüber hinaus weist die Gateway-Steuereinheit 4-1 ein Konfigurations- bzw. Statusregister SR auf, welches unter Anderem denjenigen Zeitpunkt ZP für das allernächste zu erwartende Ereignis von allen zu erwartenden internen Ereignissen EV _mt für alle in den Kommunikationsbausteinen 2-i zwischengespeicherten Nachrichten zwischenspeichert.

Die Befehls- FS M innerhalb der Ablaufsteuerung führt die aus dem Befehlsspeicher IRAM ausgelesenen Befehle aus. Bei Auftreten eines internen Ereignisses EV _mt dessen Zeitpunkt ZP in einem Statusregister SR oder bei Auftreten eines externen Ereignisses EV _ext , das der Ablaufsteuerung von einem Kommunikationsbaustein 2-i angezeigt wird, liest die Ereignis- FSM den zu dem jeweiligen Kommunikationsbaustein 2-i zugehörigen Kommunikationsbaustein-Vektor KBV aus dem ersten Speicherbereich des Vektorspeichers VRAM aus. Ein ausgelesener Kommunikationsbaustein-Vektor KBV enthält eine Vektorsprungadresse VSA auf einen Nachrichtenvektor NV in dem zweiten Speicherbereich des Vektorspeichers VRAM. Für jeden Kommunikationsbaustein 2-i bzw. für jede Gruppe von Nachrichten N innerhalb eines Kommunikationsbausteins 2-i ist ein eigener Kommunikationsbaustein-Vektor KBV vorgesehen. Dieser bildet gewissermaßen eine Hash-Tabelle für die Nachrichtenvektoren NV in dem zweiten Speicherbereich des Vektorspeichers VRAM. Mittels der Vektorsprungadresse VSA liest die Ereignis-FSM der Ablaufsteuerung den adressierten Nachrichtenvektor NV aus dem zweiten Speicherbereich des Vektorspeichers VRAM aus und adressiert an- schließend mit der darin enthaltenen Befehlssprungadresse BSA eine Subroutine innerhalb des Befehlsspeichers IRAM. Der adressierte Befehl bzw. die adressierten Befehle werden aus dem Befehlsspeicher IRAM gelesen und durch die Befehls-FSM innerhalb der Ablaufsteuerung abgearbeitet, wobei die Befehls-FSM auch die in den Vektoren, d. h. die in den Nachrichtenvektoren NV und Kommunikationsbausteinvektoren KBV angegebenen Zeitpunk- ten ZP entsprechend den NV und KBV Vektoren vorzugsweise durch die Ereignis-FSM oder den abgearbeiteten Befehlen aktualisiert.

Die in Figur 5 dargestellte Gateway-Steuereinheit 4-1 weist einen Zähler Z als internen Zeitgeber zum Auslösen eines internen Ereignisses auf.

Bei der erfindungsgemäßen Gateway-Steuereinheit 4-1 wird zwischen externen Ereignissen EV _ext und internen Ereignissen EV _mt unterschieden. Externe Ereignisse EV _ext werden durch die Kommunikationsbausteine 2-i ausgelöst, insbesondere bei Empfang einer weiterzuleitenden Nachricht N bzw. eines weiterzuleitenden Nachrichtenpakets DP. Die internen Ereignis- se EVi _nt werden durch den Zeitgeber bzw. Zeitzähler Z ausgelöst. Diese internen Ereignisse dienen beispielsweise zum zyklischen Senden von Nachrichten oder dem Entprellen bzw. Debouncen von empfangenen Nachrichten- Bursts oder zum Senden von Time-out-

Nachrichten bei überschreiten eines Erwartungszeitraums. Für jeden relevanten Nachrichtenpufferspeicher innerhalb eines Kommunikationsbausteins 2-i ist bei einer möglichen Ausführungsform des erfindungsgemäßen Gateways 1 der Nachrichtenvektor NV im Vektorspeicher-VRAM abgelegt, welcher beispielsweise die folgenden Informationen aufweist, nämlich eine Referenz auf das zu sendende Datenobjekt bzw. die Nachricht N, eine Sprungadresse zur Ausführung einer bestimmten Befehlsfolge, des nächsten internen Ereignisses und einer Differenzzeit zur Berechnung der darauf folgenden internen Ereignisse, sowie Informationsdaten zur Steuerung und Statusinformationen.

Durch die in dem Vektorspeicher VRAM abgelegten Daten insbesondere definierten Zeitpunkte ZP, kann unter Einsatz des Zählers Z nahezu jeder zeitliche Ablauf durch die erfindungsgemäße Gateway-Steuereinheit 4-1 implementiert werden, um Daten zwischen zwei oder mehreren Bussen 3 über das Gateway 1 zu übertragen. Dabei wird beim Start des Systems der Zeitgeber Z bzw. Zähler initialisiert, sodass der Zähler den CPU-Takt in einem für das Gesamtsystem günstigen Zeitraster teilt. Der aktuelle Zählwert des Zählers Z wird zur überprüfung der Nachrichtenobjekte in der Kommunikationsbausteinvektoren KBV und Nachrichtenvektoren NV des Vektorspeichers VRAM eingesetzt, um das Senden einer Nachricht N auszulösen. Dabei wird der Zählwert des Zeitgebers Z mit den in der Vektortabelle gespeicherten Zeitwerten verglichen. Ist der Zeitgeberwert des Zählers Z größer oder gleich dem jeweils gespeicherten Zeitwert bzw. Zeitpunkt und handelt es sich bei der entsprechenden Nachricht N bzw. bei dem Nachrichtenobjekt um ein Sendeobjekt, wird an die angegebene Adresse gesprungen und die dort angegebenen Befehle ausgeführt. Handelt es sich bei der Nachricht N bzw. dem Nachrichtenobjekt um ein Empfangsobjekt, wird überprüft, ob das Empfangsobjekt bereits empfangen hätte werden müssen oder nicht. Wird das Emp- fangsnachrichtenobjekt innerhalb der erwarteten Zeit nicht empfangen, wird durch das erfindungsgemäße Gateway 1 ein Time-out ausgelöst und eine entsprechende Time-out- Message abgegeben. Anschließend werden Zeitangaben durch die Ablaufsteuerung aktualisiert, wobei die Berechnung auf den bisherigen Zeitangaben mit den angegebenen Zykluszeiten basiert. Mittels der neu berechneten Zeitpunkte wird ermittelt, wann eine Nachricht N bzw. Message erneut gesendet werden soll bzw. das nächste Time-out erfolgt.

Bei einer unmittelbaren bzw. sofortigen Weiterleitung einer Nachricht N ist der Vergleich des von dem Zähler Z angegebenen Zeitwertes nicht erforderlich. Es wird der Gateway- Steuereinheit 4-1 durch den Kommunikationsbaustein 2-i mitgeteilt, dass eine Nachricht N durch den Kommunikationsbaustein 2 empfangen wurde. Anschließend sucht die Ablaufsteuerung FSM in dem Vektorspeicher VRAM nach einem entsprechenden Eintrag, d. h. einen zu der Nachricht N zugehörigen Kommunikationsbaustein-Vektor KBV. Dieser Vektor

KBV zeigt auf einen Nachrichtenvektor NV in dem zweiten Speicherbereich des Vektorspeichers VRAM. Dieser enthält eine Befehlssprungadresse BSA zu einer Routine, in der die Routingbefehle abgelegt sind.

Die Auswertung des Zeitwertes, der durch den Zähler Z geliefert wird, zur Berechnung der neuen Erwartungszeitwerte bzw. erwarteten Zeitpunkten ZP sowie die Ansteuerung der verschiedenen Kommunikationsbausteine 2-i wird von der automatisch ablaufenden Ablaufsteuerung bzw. Finite State Machine übernommen. Die Ablaufsteuerung FSM überprüft mit Hilfe eines Zählers Z und eines Statusregisters SR alle zu sendenden Nachrichtenobjek- te bzw. Nachrichten und überprüft zusätzlich den Empfang von externen neuen Nachrichten N durch die Kommunikationsbausteine 2-i. Beim Auftreten eines internen Ereignisses, beispielsweise das zyklische Senden einer Nachricht oder eines externen Ereignisses, beispielsweise dem Empfang einer weiterzuleitenden Nachricht N durch einen Kommunikationsbaustein 2, werden die konfigurierten Routingbefehle ausgeführt und die verschiedenen Kommunikationsbausteine 2 angesteuert. Durch die Anbindung der Kommunikationsbausteine 2 über das Customer-Interface 5-2 besteht für die CPU 4-2 im erfindungsgemäßen Gateway 1 jederzeit die Möglichkeit, auf Nachrichten N in dem Kommunikationsbaustein bzw. Bus-Modulen 2-i zuzugreifen. Die Nachrichten N werden in den Kommunikationsbaustein 2-i bzw. in den Bus-Modulen der seriellen Busse 3-i vorzugsweise zwischengespeichert und werden bei dem erfindungsgemäßen Gateway 1 für das automatische Routen bei einer möglichen Ausführungsform nicht in die Gateway-Steuereinheit 4-i geladen. Eine übertragung der Nachrichten zwischen den Kommunikationsbausteinen bzw. Bus- Modulen 2-i erfolgt bei einer möglichen Ausführungsform des erfindungsgemäßen Gateways 1 durch einen weiteren Bus, nämlich einen Ringbus, der die verschiedenen Kommunikationsbausteine ringförmig miteinander verbindet. Die CPU 4-2 kann auf alle zwischengespeicherten Nachrichtenobjekte bzw. Nachrichten N innerhalb eines Kommunikationsbausteins 2-i über das Interface- Register 2g zugreifen, während die Gateway-Steuereinheit 4-2 den Zugriff über das zweite Interface- Register 2f ausführt.

Figur 8 zeigt Signalablaufdiagramme zur Verdeutlichung der Funktionsweise bei einer möglichen Ausführungsform des erfindungsgemäßen Gateways 1. In dem Statusregister SR der Gateway-Steuereinheit 4-1 ist derjenige Zeitpunkt ZP zwischengespeichert, an dem das nächste zu erwartende Ereignis, d. h. das allernächste zu erwartende Ereignis von allen zu erwartenden internen Ereignissen für alle in dem Kommunikationsbaustein 2-i zwischenge- speicherten Nachrichten N auftritt. In dem Statusregister SR ist somit der allernächste interne Event bzw. das von der Gateway-Steuereinheit 4-1 als nächste zu erwartende interne Ereignis EV _ιnt zwischengespeichert. Sobald der Zeitgeber Z einen Zählwert ausgibt, der den

Eintritt dieses Ereignisses angibt (t _nxtE vτaiι < TIMER) ermittelt die Ereignis-FSM innerhalb der Ablaufsteuerung den zugehörigen Kommunikationsbausteinen 2-i und wertet alle in dem Vektorspeicher VRAM abgespeicherten Kommunikationsbaustein-Vektoren KBV für die jeweilige Gruppe innerhalb des entsprechenden Kommunikationsbausteins 2-i aus. Bei dem in Figur 8 dargestellten einfachen Beispiel weist der Kommunikationsbaustein 2 zwei Nachrichten bzw. Message Groups auf, nämlich eine Gruppe GRPl und eine Gruppe GRP2. Die Ereignis-FSM wertet im Schritt Sl den Zeit-Event auslösenden Kommunikationsbaustein- Vektor KBV, welcher in dem ersten Speicherbereich des Vektorspeichers VRAM abgelegt ist, aus und findet bei dem in Figur 8 dargestellten Beispiel den Kommunikationsbaustein-Vektor KBV für die zweite Gruppe GRP2 der zwischengespeicherten Nachrichten innerhalb des Kommunikationsbausteins 2. In einem weiteren Schritt S2 wird der Zeit- Event auslösende Nachrichtenvektor NV im zweiten Speicherbereich des zweiten Vektorspeichers VRAM ausgelesen und ausgewertet. Bei dem in Figur 8 dargestellten Beispiel ist der das Event EV auslösende Vektor der Vektor der ersten Nachricht N bzw. des Nachrichtenobjekts (Message- Objekt 1) innerhalb der zweiten Gruppe GRP2 des auslösenden Kommunikationsbausteins 2-i.

In einem weiteren Schritt S3 wird das nächste Zeit- Event bzw. das nächste interne Ereignis für dieses Nachrichtenobjekt bzw. dieses Message-Objekt MO berechnet:

^ nxtEV+\-Grp _n -MO _m ~ KxIEVt-GrP _n -MO _1n ⁺ ^GrP _n -MO _1n

Dies ist möglich, da jeder Nachrichtenvektor NV zusätzlich eine Zeitdifferenz t zwischen dem Zeitpunkt ZP eines von der zugehörigen Nachricht N bzw. dem Nachrichten-Objekt NO auszulösenden internen Ereignisses und einem Zeitpunkt ZP des nächsten von der entsprechenden Nachricht N auszulösenden internen Ereignisses aufweist.

In einem weiteren Schritt S4 wird das nächste Zeit- Event bzw. das nächste interne Ereignis EVi _n t durch die Ereignis-FSM gesucht:

tnextEV-GRPn = minilTIUm (tpxtEV-GRPn-MOm) : ITl € [1 ... ITl _max ]

In einem weiteren Schritt S5 erfolgt eine Aktualisierung der Zeitangabe t _nxtE v-G _RPn in dem Kommunikationsbaustein-Vektor KBV innerhalb des ersten Speicherbereichs des Vektor- Speichers VRAM aus den ermittelten Zeitpunkten.

In einem weiteren Schritt S6 kann der nächste Zeit- Event bzw. das zu erwartende nächste interne Ereignis über alle Gruppen von gespeicherten Nachrichten bzw. Message-Objekten MO über alle Kommunikationsbausteine 2-i selektiert werden. Bei dem in Figur 8 dargestellten Beispiel ist dies Zeitpunkt t _m für die erste Gruppe GRPl innerhalb des ersten Kommuni- kationsbausteins.

In einem anschließenden Schritt S7 wird in dem Statusregister SR dieser Zeitpunkt t _m als Zeitpunkt t _n+ i das allernächste zu erwartende interne Ereignis bzw. interne Event abgespeichert. Sobald der Zähler Z diesen Zeitpunkt t _n+ i erreicht, beginnt der in Figur 8 dargestellte Vorgang von Neuem, d. h. die Schritte S1-S7 werden erneut durchgeführt.

Figur 9 zeigt zwei Zeitsignaldiagramme, wobei das obere Signaldiagramm eine an dem erfindungsgemäßen Gateway ankommende Nachricht bzw. Message-Objekt MO darstellt, an das zweite untere Zeitsignaldiagramm von dem erfindungsgemäßen Gateway 1 an einen anderen seriellen Bus abgegebene Nachrichten zeigt. Bei dem in Figur 9 dargestellten Beispiel wird eine an einem ersten seriellen Bus 3-i empfangene Nachricht MO direkt über einen anderen seriellen Bus 3-j weitergeleitet, wobei eine leichte Zeitverzögerung t _GD deia _y auftritt. Wie man in Figur 9 erkennen kann, ist die Sende-Zykluszeit t _zyk | _Us konstant, d. h. empfangene Nachrichtenobjekte N (zyklisch oder spontan) werden zyklisch weitergeleitet.

Figur 10 zeigt das zyklische Senden von Nachrichten N durch das erfindungsgemäße Gateway 1, selbst wenn die empfangenen Nachrichtenobjekte N nicht zyklisch empfangen werden. Die zuletzt empfangene Nachricht N ₁ wird kontinuierlich zyklisch innerhalb einer konstanten Zyklusdauer an einen Bus 3-i ausgesendet.

Figur 11 zeigt die unmittelbare Weiterleitung einer Nachricht mit Time-out, d. h. die Abwesenheit einer erwarteten Nachricht wird überwacht. Wie man aus Figur 11 erkennen kann, wird über einen ersten seriellen Bus 3-i eine Nachricht N bzw. ein Message-Objekt empfangen und unmittelbar an einen Ausgangsbus weitergeleitet. Zum Zeitpunkt t _A wird festgestellt, dass die erwartete Nachricht nicht eingetroffen ist und das Gateway 1 generiert eine Timeout-Nachricht, welche als Ausgangsnachricht an den Ausgangsbus abgegeben wird, um das Ausbleiben der erwarteten Nachricht anzuzeigen. Zur Durchführung des in Figur 11 dargestellten Vorgangs führt die Ablaufsteuerung die in Figur 8 dargestellten Schritte Sl beim Empfang einer derartigen Nachricht (Nachricht korrekt im Zeitraster empfangen) und S3 beim Ausbleiben der Nachricht N (Auslösen des Time-out) nicht aus, sondern jeweils nur die übrigen Schritte.

Figur 12 zeigt das Entprellen bzw. Debouncen von Nachrichten-Bursts. In dem in Figur 12 dargestellten Beispiel enthält das Gateway 1 eine Nachricht mehrfach innerhalb eines vorgegebenen Fensters t _DEB und leitet lediglich die erste Nachricht der Gruppe an einen anderen seriellen Bus 3-i weiter. Die übrigen Nachrichten innerhalb des Bursts werden durch das Gateway 1 unterdrückt. Bei der in Figur 12 dargestellten Funktion bzw. dem entsprechenden Betriebsmodus wird in einem ersten Durchlauf ein sogenanntes Debou nee- Active- Bit als Konfigurationsdatum in dem Nachrichtenvektor NV des Vektorspeichers VRAM zum Empfang einer Nachricht gesetzt. Sobald das Debou nee- Active- Bit gesetzt ist, erfolgt der in Figur 8 dargestellte Vorgang, wobei der Schritt S3 entfällt. Abschließend wird das Debounce- Active- Bit dann in den Konfigurationsdaten wieder zurückgesetzt.

Wie man aus den Figuren 9, 10, 11, 12 erkennen kann, eignet sich das erfindungsgemäße Gateway 1 für verschiedene Betriebsmodi bzw. Funktionen zur Weiterleitung bzw. Bearbeitung von Nachrichten, die zwischen verschiedenen Bussen 3-i, 3-j übertragen werden. Bei dem erfindungsgemäßen Gateway 1 wird in Abhängigkeit von dem auftretenden Datenaufkommen die CPU-Last für die automatische überprüfung auf Time-outs und das erforderliche Senden von Nachrichten oder die Kombination von mehreren Nachrichten durch die Gateway-Steuereinheit 4-1 erheblich gesenkt. Das Senden der Nachrichten bzw. des Message-Objekts sowie deren überprüfung auf eventuelle Time-outs erfolgt durch die Gateway- Steuereinheit 4-1 unabhängig von den parallel laufenden Prozessen in der CPU 4-2. Dadurch werden wesentlich kleinere Jitter und Latenzzeiten erreicht, wodurch Prozesse im Netzwerk genauer gestartet und ausgeführt werden können. Dabei kann jedes Message- Objekt bzw. jede Nachricht N unabhängig von anderen Netzwerken und unabhängig von anderen Message-Objekten in den einzelnen Kommunikationsbausteinen bzw. Bus-Modulen konfiguriert werden. Durch die in dem erfindungsgemäßen Gateway 1 eingesetzte Verweistechnik mittels Vektoren besteht eine besonders hohe Flexibilität bezüglich der Konfigurier- barkeit des erfindungsgemäßen Gateways 1. Durch die Bildung von Gruppen von speicherbaren Nachrichten N innerhalb eines jeden Kommunikationsbausteins 2 ist eine weitere Ver- schachtelung möglich, wodurch die Flexibilität weiter gesteigert wird. Zusätzlich wird die Ge- schwindigkeit für Suchvorgänge zu bearbeitender Nachrichten wesentlich verkürzt und durch die kompakte Definition eines Kommunikationsvorgangs der Speicherbedarf für alle Nachrichtenobjekte minimiert. Das erfindungsgemäße Gateway 1 eröffnet die Möglichkeit, dass externe Ereignisse bzw. Events den zeitlichen Ablauf von internen Ereignissen bzw. internen Events mitbestimmen bzw. steuern. Das erfindungsgemäße Gateway 1 überträgt Daten zwi- sehen Feldbussen bzw. seriellen Bussen 3 automatisch ohne die CPU 4-2 zu belasten. Dabei wird das periodische Senden innerhalb eines vorgegebenen Zeitrasters, die sofortige übermittlung nach Erhalt einer Nachricht, die überprüfung auf Ausbleiben einer Nachricht

sowie das Entprellen von Nachrichten ermöglicht. Die übermittlung der Nachrichten N erfolgt dabei ohne direkte Kontrolle durch die CPU. Die CPU 4-2 erhält jedoch jederzeit den Zugriff auf die weitergeleiteten bzw. verwendeten Nachrichtenobjekte bzw. Message-Objekte, ohne dabei das automatische Routen der Nachrichten zu unterbrechen. Die übertragung bzw. Weiterleitung der Message-Objekte bzw. der Nachrichten N erfolgt bei dem erfindungsgemäßen Gateway 1 unabhängig von Software- Latenzzeiten und der aktuellen Last der CPU 4- 2.