-
Die Erfindung betrifft ein Verfahren zum Betreiben eines Gateways mit den im Oberbegriff des Patentanspruches 1 angegebenen Merkmalen.
-
Unter einem Gateway versteht man ein Steuergerät mit diversen Anschlüssen für mehrere Bussysteme. Insbesondere im automotiven Bereich haben sich derartige Gateways durchgesetzt. Die Aufgabe dieser Gateways ist es, vollständige Datentelegramme oder ausgewählte Daten aus solchen Datentelegrammen eines Bussystems in ein anderes Bussystem zu übertragen und umzusetzen. Hierbei hat das Gateway die Datenformate und/oder Datenstrukturen, in denen die Datentelegramme eines Bussystems übertragen werden, in die Datenformate und/oder Datenstrukturen umzusetzen, welche das andere Bussystem benötigt. Darüber hinaus hat ein Gateway mittlerweile weitere Aufgabe übernommen, so beispielsweise die Aufgabe des zyklischen Versendens von Datentelegrammen oder die Überwachung von zu erwartenden Eingangsdatentelegrammen.
-
Die Regeln und Vorschriften, welche Eingangs- und Ausgangsdatentelegramme in welcher Form und Struktur umzusetzen sind, werden bei bekannten Gateways üblicherweise in Datenstrukturen, so genannten Routing-Tabellen, im RAM oder ROM des zentralen Prozessors eines Gateways abgelegt. Diese Tabellen umfassen üblicherweise mehr als fünfhundert einzelne Regelungsvorschriften, es können auch teilweise mehr sein. Diese Regeln werden z. B. vom Automobilhersteller, in dessen Automobil das Gateway eingesetzt werden soll, in unterschiedlichen Routingregelformaten, wie beispielsweise Excel-Tabellen, XML-Tabellenformat, Fibex-Datenformat oder ähnlichen Formaten zur Verfügung gestellt.
-
Aus
US-A1-2006/0059278 ist eine Kommunikationscontrollerschnittstelle und Verfahren zum Betreiben der Kommunikationscontrollerschnittstelle bekannt. Die Vorrichtung und das Verfahren dienen zum Kommunizieren von Informationen innerhalb eines Netzwerkes mit Kommunikationseinheiten gemäß einem Kommunikationsprotokoll, beispielsweise dem CAN (Control Area Network) Protokoll, welches in der Automobil-Industrie benutzt wird. Es sind mehrere unabhängige Kommunikationsbusse aus dieser Anwendungen bekannt. Diese Kommunikationsbusse sind miteinander über eine Informations-Controller-Schnittstelle oder Gatewayverbindung verbunden. Die Information wird von einem Bus zu einem anderen Bus (oder zurück zu demselben Bus) über das Gateway in Informationseinheiten, die üblicherweise als Mitteilungsrahmen bezeichnet werden, übertragen.
-
Aus
US-B2-6,934,612 ist ein Kfz-Kommunikationsnetzwerk bekannt. Das Kommunikationsnetzwerk besteht aus einer Vielzahl von Netzwerkelementen und Kommunikationsverbindungen, welche die Netzwerkelementen in einer Punkt zu Punkt-Verbindung untereinander verbinden. Die Kommunikationsverbindungen werden anhand eines Busprotokolls spezifiziert in der Weise, dass zwischen den Netzwerkelementen Datenpakete ausgetauscht werden können.
-
Aus
US-A1_2007/0113273 ist ein Netzwerkmanagementsystem bekannt, das das es ermöglicht dass die Netzwerkeinheiten die vorgegebene Konfigurationsvorgabe einhalten. Hierzu überprüft das Netzwerkmanagementsystem anhand der auszuführenden Arbeiten, ob eine spezifische Vorgabe bei der Verarbeitung zu beachten ist.
-
Aufgabe der vorliegenden Erfindung ist es nunmehr, ein Verfahren zum Betrieb eines Gateways darzustellen, das ein effizientes Routingverfahren ermöglicht und mit geringem Speicherbedarf und niedriger Rechnerleistung arbeiten kann.
-
Diese Aufgabe löst die Erfindung gemäß dem in dem Anspruch 1 angegebenen Verfahren.
-
Vorteilhafte Ausgestaltungen der Erfindung ergeben sich anhand der weiteren Beschreibung, der abhängigen Ansprüche sowie der Figuren und der zugehörigen Figurenbeschreibung.
-
Beim erfindungsgemäßen Verfahren zum Betreiben eines Gateways werden eingehende Datentelegramme mindestens eines ersten Bussystems mittels eines Routingprozesses verarbeitet und in Datentelegramme mindestens eines zweiten Bussystems umgesetzt und an das mindestens zweite Bussystem übertragen. Ein eingehendes Datentelegramm wird entweder komplett und unverändert weitergeleitet oder es wird teilverarbeitet, indem nur Datenteile des Datentelegramms umgesetzt und weitergeleitet werden. Als weitere Verarbeitung kann auch vorgesehen sein, dass ein eingehendes Datentelegramm in einer bestimmten Frequenz wiederholt wird. Der Routingprozess verarbeitet anhand einer Routigtabelle ein eingehendes Datentelegramm. Die Routingtabelle greift hierzu auf mindestens einen Look-Up-Table zu. Es ist vorgesehen, dass der Routingprozess anhand eines ersten Look-Up-Tables das eingehende Datentelegramm anhand dessen Datentelegrammidentifikationstyp verarbeitet, indem er diesen als Index auf den ersten Look-Up-Table verwendet. Durch die Verwendung eines Look-Up-Tables ist ein schneller Zugriff möglich. Es muss nicht eine lange Tabelle durchsucht werden. Indem der Datentelegrammidentifikationstyp als Index des Look-Up-Tables verwendet wird, ist die Anzahl der Einträge im Look-Up-Table beschränkt. Der Inhalt der ersten Look-Up-Tables kann auch auf einen zweiten Look-Up-Table verweisen, der seinerseits anhand des Inhalts des Datentelegramms auf entsprechende Routingregeln verweist. Durch die Zuweisung des ersten Look-Up-Tables über dessen Indexierung kann über den Datentelegrammidentifikationstyp ein direkter Verweis auf die dem Datentelegramm über den Datentelegrammidentifikationstyp zugeordnete Routingregel erfolgen, wodurch ein langwieriger Suchprozess vermieden wird.
-
Auch kann vorgesehen sein, dass bei der Verarbeitung eines Datentelegramms mittels des ersten Look-Up-Tables zwischen relevanten Datentelegrammen und nicht relevanten Datentelegrammen unterschieden wird und nur relevante Datentelegramme weiterverarbeitet werden. Indem im ersten Look-Up-Table nur die Datentelegrammidentifikationstypen hinterlegt sind, kann sofort ein nicht relevantes Datentelegramm erkannt werden, wenn dies nicht im Look-Up-Table vorhanden ist.
-
Vorteilhaft ist es ferner, wenn der zweite Look-Up-Table keine Leereinträge enthält. Durch die Zuweisung über den Datentelegrammidentifikationstyp werden nur solche Datentelegramme verarbeitet, die einen im ersten Look-Up-Table indexierte Datentelegrammidentifikationstypen haben. Daher kann im zweiten Look-Up-Table nur Suchen nach hinterlegten und vorhandenen Routingregeln erfolgen, Leereinträge sind nicht notwendig.
-
Ferner kann vorgesehen sein, dass der Routingprozess bei der Verarbeitung eines Datentelegramms der Datentelegrammidentifikationstyp bei CAN-Datentelegrammen anhand der Datentelegramm-Identifikation 0×001 bis 0×800, bei MOST aus Kombinationen der FBlock-Identifikation, der Ftk-Identifikation, der Adresse von Sender und Empfänger, und bei FlexRay-Datentelegrammen anhand der PDU oder der Frame Nummer erkennt. Somit erfolgen eine schnelle Erkennung und schnelle Verarbeitung.
-
Die Verweise in den Look-Up-Table können als ungültig gekennzeichnet werden, wenn der Datentelegrammidentifikationstyp nicht relevant ist oder wenn eine bestimmte Routingregel nicht anzuwenden ist. Auf diese Weise können nicht relevante Datentelegramme schnell aus der Verarbeitung genommen werden und belasten das Gateway nur sehr gering.
-
Auch können die Verarbeitung der Datentelegramme Maskenoperationen für Umsetzungsregeln der Daten der eingehenden Datentelegramme vordefiniert werden. Durch diese vordefinierten Masken-Operationen ist eine schnelle Verarbeitung der Datentelegramme gewährleistet.
-
Vorteilhaft ist es auch, dass die Masken-Operationen die Datentelegramme bitweise umzusetzen, wodurch die Masken-Operationen universell einsetzbar und miteinander kombinierbar sind.
-
Auch kann vorgesehen sein, dass eine erste Masken-Operation Daten des Datentelegramms mittels einer Bitumsetzungsregel verarbeitet, bei welcher jedes einzelne Bit eines Datentelegramms, beginnend von einer Startadresse bis zu einer Endadresse, in das neue Datentelegramm übertragen wird. Hierdurch kann diese Masken-Operation durch Abänderung der Start- und/oder Endadresse auf diverse Datentelegramme angewendet werden.
-
Ferner kann eine zweite Masken-Operation Daten des Datentelegramms mittels einer Bitumsetzungsregel verarbeiten, bei welcher die Byteposition sowie eine Bitmaske abgelegt werden, mittels denen die Bits im Zielbyte auf Null gesetzt und anschließend mit den Bits des Quellbytes überschrieben werden. Hierdurch kann diese Masken-Operation auf diverse Datentelegramme angewendet werden.
-
Ferner kann eine dritte Masken-Operation vorgesehen sein, mit der Daten des Datentelegramms mittels einer Bitumsetzungsregel verarbeitet werden, bei welcher nur einzelne Bits zu kopieren sind, zur Byte-Position auch eine Maske für Quell- und Zielbit abgelegt wird, mittels derer eine sehr effiziente Überprüfung ermöglicht wird, ob ein Quellbit und/oder ein Zielbit gesetzt ist oder zu setzen ist. Hierdurch kann diese Masken-Operation auf diverse Datentelegramme angewendet werden. Es können auch mehrere Maskenoperationen kombiniert werden.
-
Vorteilhaft ist es ferner, wenn bei der Erzeugung der Routingtabellen mehrere Regelungsvorschriften zu einer der vorher beschriebenen Masken-Operationen kombiniert werden. Dies ist von Vorteil, wenn diese Regeln Bits mit gleichem Abstand in Quell- und Zielbotschaft beschreiben oder aufweisen. Hierdurch kann die Anzahl von Routingregeln, die im Gateway zu speichern sind reduziert werden.
-
Vorteilhaft ist es auch, wenn die Routingregelformate automatisiert eingelesen und daraus die Routingtabellen erzeugt werden. Dadurch können automatisiert aus den Routingregelformaten Routingtabellen erzeugt werden, ohne dass ein Nutzer langwierig diese Routingtabellen händisch erzeugen muss.
-
Gemäß einer Weiterbildung werden die Routingtabellen in einem binären Format oder als Source-Code für einen Compiler erzeugt.
-
Das Verfahren dient auch zur Erzeugung eines Source-Codes oder eines Binärcodes für einen Routingprozess eines Gateways. Der Binärcode oder der aus dem Source-Code mittels eines Compilers gewonnene und dann zum Zentralprozessor des Gateways verlinkte Code dient dann zur Implementierung des Routingprozesses auf den Zentralprozessor eines Gateways. Hierzu werden Routingregelformate aus einer vorgegebenen Quelle eingelesen und aus diesen Routingregelformaten wird der Source-Code oder ein Binarcode für den Routingprozess erzeugt. Die vorgegebene Quelle ist eine die dem Format einer Excel-Datei, einer HTML-Datei, einer XML-Datei, einer Fibex-Datei oder einer Textdatei entspricht. Es ist außerdem vorgesehen, dass der Source-Code für einen Compiler einer bestimmten Programmiersprache erzeugt ist. Der Source-Code wird von einem Zielcompiler in einen Binarcode umgesetzt.
-
In der weiteren nachfolgenden Beschreibung werden weitere Merkmale und Einzelheiten der Erfindung in Zusammenhang mit den beigefügten Zeichnungen anhand von Ausführungsbeispielen näher erläutert. Dabei sind die in einzelnen Varianten beschriebenen Merkmale und Zusammenhänge grundsätzlich auf alle Ausführungsbeispiele übertragbar. Es erfolgt keine Einschränkung der Erfindung auf eine der nachfolgenden konkreten Ausführungsbeispiele bzw. des nachfolgenden Ausführungsbeispiels. Es werden bei der Figurenbeschreibung für gleiche Elemente gleiche Bezugszeichen in allen Figuren verwendet. Dies dient der besseren Verständlichkeit der Beschreibung.
-
Es zeigen:
-
1 einen Aufbau eines Gateways;
-
2 die Vorgehensweise bei der Erzeugung der Routing-Software;
-
3 eine funktionale Darstellung der Datentelegramm-Routingregeln; und
-
4 das Vorgehen bei der Umsetzung eines Datentelegramms.
-
In 1 ist der schematische Aufbau eines Gateways dargestellt. Das Gateway besteht aus einer Zentralprozessoreinheit 1, auch CPU genannt. Es sind mehrere Schnittstellen vorhanden. Diese Schnittstellen sind über entsprechende Treiber gekoppelt. In 1 sind beispielhaft ein CAN-Treiber 2, ein LIN-Treiber 3 sowie ein Flexray-Treiber 5 und ein MOST-Net-Service 4 dargestellt.
-
An den CAN-Treiber 2 sind CAN-Transceiver 11.1 bis 11.6 angebunden, über welche mehrere der CAN-Busse CAN 1 bis CAN 6 Daten anliefern und/oder übergeben und/oder abholen und/oder übernehmen. An den LIN-Treiber 3 sind über dessen Schnittstelle zwei LIN-Transceiver 12.1 und 12.2 angeschlossen, über welche ein erster LIN-Bus LIN 1 und zweiter LIN-Bus LIN 2 angeschlossen sind.
-
An den MOST-Net-Service 4 ist ein entsprechender MOST-Treiber 8 mit dem daran angekoppelten MOST-Bus 9 angeschlossen. Der Flexray-Treiber 5 versorgt die Flexray-Busse 10.1 bis 10.5. Der CAN-Treiber 2, der LIN-Treiber 3, das MOST-Net-Service 4 und der Flexray-Treiber 5 kommunizieren über das Gateway und dessen CPU 1 miteinander über die Routing-Software 6, welche auf die Routing-Tabelle 7 zugreift.
-
Ein Datentelegramm, welches über den CAN-Bus CAN 1 eingeht, wird vom CAN-Transceiver 11.1 empfangen und an den CAN-Treiber 2 geleitet. Im Datentelegramm ist das Ziel angegeben. Im vorliegenden Fall soll das eingehende Datentelegramm beispielsweise dem Flexray-Bus 10.5 übergeben und von diesem an die entsprechende Zielkomponente übertragen werden. Der CAN-Treiber 2 liest das Datentelegramm ein, übergibt dieses der Routing-Software 6. Die Routing-Software 6 analysiert das eingehende Datentelegramm anhand der Routing-Tabelle 7 und setzt das Datentelegramm auf die Spezifikation und die Vorgaben für den Flexray-Bus um und übergibt das verarbeite Datentelegramm an den Flexray-Treiber 5. Dieser übergibt dann das Datentelegramm an den Flexray-Bus 10.5. In analoger Weise erfolgt eine Umsetzung eines Datentelegramms eines anderen Busses auf jeden weiteren Bus. Die Vorschriften zur Umsetzung eines Datentelegramms von einem Bus auf einen anderen sind in der Routing-Tabelle 7 abgelegt und die Routing-Software 6 steuert den Vorgang.
-
In 2 sind ein Gateway-Tool und dessen Funktionsweise dargestellt. Das Gatway-Tool hat folgende Arbeitsweise. Das Gateway-Tool liest selbsttätig Routingregeln aus einer Datei ein. Das Format, insbesondere das Datenformat, der Datei muss bekannt sein. Aus diesen eingelesenen bzw. einzulesenden Routingregeln erzeugt das Gateway-Tool automatisch den Source-Code für die Routing-Tabelle. Die Routingregeln liegen in einem vorbekannten Datenformat vor und werden selbsttätig vom Gateway-Tool in den entsprechenden Source-Code umgesetzt.
-
In 2 ist die Routing-Regel 21 dargestellt. Diese wird an das Gateway-Tool 22 übergeben. Beim Gateway-Tool handelt es sich um eine Software im Binärcode und in von einer CPU abarbeitbarem Code, welche auf einem Computer, insbesondere einem Desktop-PC lauffähig ist. Das Gateway-Tool 22 liest die Routingregeln 21 aus der Datei ein und erzeugt hieraus einen Source-Code 24, der mittels eines Compilers 20 auf eine Target-Software 27 verlinkbar umgesetzt wird. Es besteht die Möglichkeit, zum einen den Source-Code 24 zu einem späteren Zeitpunkt mittels des Compilers 20 in einen Binärcode umzusetzen, um dann auf bzw. mit der Target-Software 27 zu portieren. Weiterhin ist ein Desktop-Compiler 25 vorhanden, welcher den Source-Code 24 der Routing-Tabelle derart compiliert und an das Gateway Tool 22 übergibt, dass dieses den Source-Code 24 testen bzw. mittels einer Testroutine überprüfen kann. Auf diese Weise kann der Source-Code 24 überprüft werden. Das Gateway-Tool 22 ist in der Lage, selbsttestende Routinen abzubilden. Der Source-Code 24 wird mittels des Compilers 20 für die jeweilige Gateway CPU übersetzt, so dass die Routing-Tabelle mit dem Routing-Core 23 zusammenarbeitet und nach Einbringung der Target-Software 27 in das Gateway-Steuergerät abgearbeitet wird und lauffähig ist.
-
Die Aufgabe der Routing-Software ist es außerdem, die Weiterleitung von eingehenden Datentelegrammen auf andere Bussysteme umzusetzen. Hier gibt es wiederum verschiedene Umsetzungsregeln, welche beschreiben, ob der komplette Dateninhalt eines Eingangsdatentelegramms weiterzuleiten ist oder nur einzelne Bits bzw. Teile des Datentelegramms in andere Datentelegramme anderer Busse zu kopieren und dort zu übernehmen sind. Darüber hinaus gibt es Umsetzungsregeln, welche beschreiben, ob ein Sendedatentelegramm in einer bestimmten Frequenz zu wiederholen ist. Außerdem gibt es Umsetzungsregeln, die beschreiben, wie zu verfahren ist, wenn Eingangssignale ausbleiben. In diesem Fall kann vorgegeben werden, dass sogenannte veraltete Bits zu ersetzen sind oder das Senden der Ausgangsdatentelegramme unterbleiben soll.
-
Einen beispielhaften Überblick über die verschiedenen Routingregeln gibt beispielhaft 3 wieder. Die Routingregeln richten sich nach den Routing-Typen (Schritt 301). Es gibt entweder die Möglichkeit, den Routing-Typen (Schritt 301) bitweise zu bearbeiten (Schritt 314) oder das komplette Datentelegramm zu kopieren (Schritt 315). Folgt man dem Zweig des bitweisen Kopierens (Schritt 314), so werden gemäß dem Schritt 302 bitweise die Daten vom Eingangsdatentelegramm in das Ausgangsdatentelegramm kopiert. Es besteht die Möglichkeit, N Datentelegramme in ein Datentelegramm umzusetzen gemäß Schritt 319, es erfolgt eine N zu 1 Umsetzung. In diesem Fall sind im nachfolgenden Schritt 307 folgende weitere Routing-Schritte möglich:
- 1. Bitweise; Daten werden aus mehreren Eingangsdatentelegrammen in ein Ausgangsdatentelegramm gesendet;
- 2. Zyklisch;
- 3. Datentelegramme werden endlos gesendet;
- 4. bei veraltetem Datentyp werden einzeln Bits kopiert.
-
Bei N zu 1 Non BÄS (BÄS bedeutet: „Bei Änderung Senden”) (Schritt 325) wird gemäß Schritt 313 das erzeugte Ausgangsdatentelegramm zyklisch gesendet. Gemäß Schritt 324 wird bei N zu 1 BÄS (Schritt 312) das Datentelegramm sofort gesendet, wenn sich der Dateninhalt geändert hat.
-
Gemäß Schritt 302 erfolgt beim bitweisen Kopieren vom Eingangstelegramm ins Ausgangstelegramm beim 1 zu 1 Kopieren eines Datentelegramms (Schritt 318) der Schritt 306, der ein bitweises 1 zu 1 – Kopieren, welches auch zyklisch sein kann, vornimmt. Im alternativ nachfolgenden Schritt 323 erfolgt ein 1 auf 1 Non BÄS und das Ausgangsdatentelegramm wird nach Schritt 311 zyklisch gesendet.
-
Im alternativ dem Schritt 306 folgenden Schritt 322 gemäß Schritt 310 erfolgt bei 1 auf 1 BÄS ein sofortiges versenden des Datentelegramms, wenn sich der Dateninhalt geändert hat.
-
Beim kompletten Kopieren des Datentelegramms nach Schritt 315 erfolgt in Schritt 303 das Kopieren des kompletten Datentelegramms 1 zu 1. Nunmehr ist zu unterscheiden, zwischen BAF On (Schritt 317) und BAF Off (Schritt 316). Bei BAF On (Schritt 317) erfolgt im Schritt 305 eine 1 zu 1 BAF-Umsetzung. Die Versendung erfolgt nicht zyklisch.
-
Das Datentelegramm wird sofort gesendet. Die Reaktionszeit ist geringer als eine Millisekunde.
-
Bei BAF Off (Schritt 316) erfolgt im nachfolgenden Schritt 304 folgendes:
- 1. zyklisch gesendetes Daten.
- 2. mehrfache Wiederholung beim Ausbleiben des Datentelegramms.
-
Im nächsten Schritt erfolgt eine Verzweigung zwischen BÄS Off (Schritt 321) und BÄS On (Schritt 320).
-
Bei BÄS On (Schritt 320) erfolgt eine 1 zu 1 Non BAF BÄS Verarbeitung. Das Datentelegramm wird sofort gesendet, wenn sich der Dateninhalt geändert hat.
-
Bei BÄS Off (Schritt) 321) erfolgt eine 1 zu 1 Non BAF Non BÄS Verarbeitung. Das Ausgangsdatentelegramm wird zyklisch versendet.
-
Die Routing-Software und das dieser zugrunde liegende Routing-Verfahren muss sehr schnell erkennen, welche der gespeicherten Regeln anzuwenden ist. Hierzu müssen Informationen des Eingangsdatentelegramms, wie in 3 dargestellt, weitergeleitet und bearbeitet werden. Informationen des Eingangsdatentelegramms wie Datentelegrammnummer, Sender, Empfänger oder ähnliches werden mit den Daten der abgelegten Routing-Tabelle verglichen. Anschließend werden die dort spezifizierten Umsetzungsregeln durch die Routing-Software abgearbeitet. Da die CPU, welche auf den Gateways zum Einsatz kommt, kostengünstig sein soll und gleichzeitig möglichst schnelle Umsetzungszeiten der Datentelegramme zu erzielen sind, ist es wichtig, die Zeit für das Durchsuchen der Routing-Tabelle zu minimieren. Dies erfolgt dadurch, dass die Routing-Software auf einem mindestens zweistufigen Look-Up-Table basiert, welcher ein Auffinden der benötigten Routingregeln komplett ohne Durchsuchen der Tabellen ermöglicht. Die Routing-Look-Up-Tables werden durch das Routing-Tool erzeugt.
-
In 4 ist ein solcher Suchvorgang dargestellt. Ein Eingangsdatentelegramm auf CAN 6 (aus 1) mit der Datentelegramm-ID 0×345 geht ein (Schritt 401). Gemäß Schritt 402 wird der Look-Up-Table (T41) anhand der Datentelegramm-ID verlinkt. Hierzu erfolgt ein Verweis auf eine oder mehrere aufeinanderfolgende Zeilen (Schritt 403) in der entsprechenden zweiten Lookup Tabelle (T42).
-
Die zweite Lookup Tabelle enthält Verweise auf Tabellen, die speziellen Typen von Routingregeln zugeordnet sind. So sind im Beispiel der eintreffenden Botschaft 0×345 alle unterschiedlichen Typen von Routingregeln anzuwenden.
-
Es existieren in der zweiten Lookup Tabelle Verweise auf Tabellen mit allen Routingregeln.
-
Der Routingprozess prüft den Verweis (Schritt 404) auf die Tabelle der Routingregel NOT BAF (T43) und führt diese Regel aus (Schritt 414).
-
Der Routingprozess prüft den Verweis (Schritt 405) auf die Tabelle der Routingregel BAF (T44) und führt diese Regel aus (Schritt 415).
-
Der Routingprozess prüft den Verweis (Schritt 406) auf die Tabelle der Routingregel Umsetzung MASK (T45) und führt diese Regel aus (Schritt 416).
-
Der Routingprozess prüft den Verweis auf die Tabelle (Schritt 407) der Routingregel Ausführung Umsetzungsregel veraltet (T46) und führt diese Regel aus (Schritt 417).
-
Die Daten des Datentelegramm-ID, bei CAN-Bussen weist das Datentelegramm die ID 0×001 bis 0×800, bei MOST aus Kombinationen von FBlock, ID und Ftk ID, Senden und Empfänger, bei FlexRay PDU oder Frame Nummern auf, werden direkt als Index auf den erste Look-Up-Table verwendet. Da diese Tabelle so viele Eintrage enthalten muss, wie es mögliche IDs gibt, ist der Speicherplatz beschränkbar und der Speicher kann relativ klein gehalten werden. Daher verweist der Inhalt dieser Tabelle auf eine Zeile in einer zweiten Look-Up-Tabelle (Look-Up-Table). Diese Tabelle hat nur noch Zeilen für relevante Eingangsdatentelegramme. Sie benötigt keine leeren Einträge. Von diesem Look-Up-Table aus wird wiederum auf Look-Up-Tables verwiesen, denen spezielle Routingregeln zugeordnet sind. Die Routing-Software kann mit diesem Mechanismus ohne zu suchen direkt prüfen, ob Eingangsdatentelegramme umzusetzen und umsetzbar sind und welche entsprechenden Routingregeln auszuführen sind. Die Verweise in den Look-Up-Tables sind als ungültig gekennzeichnet, wenn die ID nicht relevant bzw. eine bestimmte Routing-Regel nicht anzuwenden ist.
-
Beim Kopieren und beim bitweisen Umsetzen von Eingangsdatentelegrammen in beliebige Stellen eines Ausgangsdatentelegramms wird gemäß des erfindungsgemäßen Verfahrensvorgehens ein maskenorientiertes Kopieren vorgenommen. Hierzu werden mehrere Routingregeln vom Gateway-Tool untersucht und verschiedene Arten von bitweisen Umsetzungsregeln festgelegt.
-
Sind die Bits über Grenzen von einzelnen Daten-Bytes des Datentelegramms zu kopieren, wird eine allgemeine Schleifenregel angewendet, die die Routing-Regel als bitweises Kopieren kennzeichnet und ablegt. Ist eine Folge von Bits, die innerhalb eines einzelnen Datenbytes liegen, in ein und die gleiche Stelle innerhalb eines anderen Datenbytes zu kopieren, so wird eine Funktion definiert namens ROUTE_COPY_TYPE_BYTE_MASK. Hierzu werden in der Routing-Regel die Byte-Position sowie eine Bitmaske abgelegt, die es erlaubt, die Bits im Zielbyte auf Null zu setzen und anschließend mit den Bits des Quellbytes zu überschreiben.
-
Sind nur einzelne Bits zu kopieren, wird eine Routing-Regel ROUTE_COPY_TYPE_BYTE_GETSET_MASK definiert. Hierbei wird neben der Byteposition auch eine Maske für Quell- und Zielbit angelegt, welche eine sehr effiziente Überprüfung ermöglicht, ob ein Quellbit gesetzt ist und das Setzen eines Zielbits ebenfalls ermöglicht. Darüber hinaus untersucht das Routing-Tool, ob mehrere Einzelbitregeln zu einer ROUTE_COPY_TYPE_BYTE_MASK-Operation kombinierbar sind um die Anzahl der Regeln zu verringern. Bei dieser ROUTE_COPY_TYPE_BYTE_MASK werden einzelne der vorgenannten Vorgehensweisen kombiniert oder alternativ angewendet.
-
Um bei der Implementierung dieser Regeln im Gateway Fehler auszuschließen, werden tool-basierte Lösungen verwendet, welche die gelieferten Routing-Regel-Formate automatisch einlesen und daraus die Routing-Tabellen erzeugen. Befindet sich eine Variante des Routing-Cores auch innerhalb eines weiteren Gateway-Tools, so kann der Source-Code für die Routing-Tabelle auch in diesem Tool integriert werden. Nach Übersetzen dieses Tools bietet dies die Möglichkeit, die Funktionsfähigkeit des Routing-Cores in Verbindung mit der neuen Routing-Tabelle gegen die Routingregeln, welche vorhanden sind, zu prüfen. Das Gateway-Tool hat die Möglichkeit, die zyklischen Funktionen des Routing-Cores zu testen, indem Timer aktiviert werden können, die die zyklischen Verarbeitungsfunktionen des Routing-Cores aufrufen. Das Gateway-Test-Tool hat die Möglichkeit, alle in den Routingregeln spezifizierten Eingangsnachrichten auf den Routing-Core zu geben. Hierzu werden die Daten verwendet, über die das Tool durch das Einlesen der Routingregeln verfügt.
-
Das Gateway-Test-Tool gibt alle Eingangs- und Ausgangsnachrichten in einem Fenster und auch als Log-Dateien aus. Die Log-Dateien lassen sich anschließend sehr leicht mit Textvergleichsprogrammen überprüfen. So ist eine Überprüfung der korrekten Funktion des Routing-Cores in Kombination mit der aktuell gültigen Routing-Table gegen die aktuell gültige Routing-Regel möglich.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, die Routing-Tabelle in einem binären Format zu erzeugen. Bei diesem Vorgehen werden die Vorgänge, wie eingangs beschrieben, des Compilierens der Source-Code-Generierung der Routing-Tabelle ersetzt durch ein Überschreiben der Routing-Tabelle in der Binärdatei der Zielsoftware vom Gateway-Test-Tool.
