-
Die vorliegende Erfindung betrifft ein Verfahren zum Betrieb eines zeitgesteuerten, in Kommunikationsfenstern in einer Abfolge von Kommunikationszyklen kommunizierenden Bussystems unter Verwendung einer aus Eingabedaten und Konfigurationsdaten automatisch generierten Abarbeitungsanweisung zur Abarbeitung von Kommunikationsaufgaben auf Grundlage von Zeitsignalen, ein Verfahren zur Generierung einer entsprechenden Abarbeitungsanweisung sowie ein entsprechendes Computerprogrammprodukt.
-
Stand der Technik
-
Wenngleich die vorliegende Erfindung vornehmlich in Bezug auf das FlexRay-Feldbussystem beschrieben wird, ist sie nicht hierauf beschränkt, sondern prinzipiell bei einer Vielzahl zeitgesteuerter Busse wie beispielsweise in SAFEbus-, ARINC 659-, SPIDER-, NASA-, TTCAN- und Time-Triggered Protocol-Systemen einsetzbar.
-
Zum Einsatz in Fahrzeugen sind vornehmlich zeitgesteuerte und vornehmlich ereignisgesteuerte Bussysteme bekannt. In zeitgesteuerten Systemen, die zusätzlich auch Merkmale hier nicht näher erläuterter ereignisgesteuerter Systeme beinhalten können, ist die Aktivierung von Funktionen und die Übertragung von Nachrichten in der Regel an vorbestimmte Zeitpunkte gebunden, die beispielsweise auf Grundlage einer globalen Zeit, die in den Busteilnehmern durch eine Synchronisation lokaler Uhren mit der Globalzeit bekannt ist, definiert werden.
-
Im Gegensatz zur ereignisgesteuerten Kommunikation besitzen zeitgesteuerte Systeme in der Regel zumindest teilweise deterministischen Charakter in dem Sinne, dass jedem Teilnehmer an dem Kommunikationssystem ein bestimmtes Kommunikations- bzw. Zeitfenster (”Slot”) zugeordnet ist. Jeder Teilnehmer verfügt daher über ein garantiertes Sende- und/oder Empfangsfenster, das ihm aufgrund einer vorab erfolgten Konfiguration gesichert zur Verfügung steht.
-
Bei FlexRay handelt es sich um ein serielles, deterministisches und fehlertolerantes Feldbussystem für den Einsatz im Automobil. Unter anderem aufgrund der zuvor erwähnten Merkmale zeigtesteuerter Systeme lässt sich durch FlexRay eine höhere Datenübertragungsrate, eine zumindest teilweise Echtzeitfähigkeit und eine hohe Ausfallsicherheit erzielen, die insbesondere für sogenannte X-by-Wire-Systeme (Drive-by Wire, Steer-by-Wire, Brake-by-Wire etc.) Voraussetzung ist.
-
Das im Rahmen von FlexRay vorgesehene Busprotokoll regelt, wie das Netzwerk startet, wie der Bustakt etabliert wird und welche Steuergeräte zu welchem Zeitpunkt senden dürfen. Ein sogenannter Communication Controller setzt das globale Busprotokoll in jedem einzelnen Steuergerät um, indem er beispielsweise die zu übertragenden Informationen in ein Datenpaket verpackt und dieses zum richtigen Zeitpunkt zur Übertragung an den Bus Transceiver übergibt.
-
Die Kommunikation auf dem Bus läuft in Zyklen ab. Jeder der maximal 64 Zyklen ist im wesentlichen in zwei Zeitbereiche unterteilt. In einem ersten, statischen Bereich, der dem deterministischen Teil des FlexRay-Protokolls entspricht, ist jedem Steuergerät bzw. Kommunikationsteilnehmer stets ein bestimmtes Zeitfenster (”Slot”) zugewiesen, in dem es Nachrichten senden kann. Es darf dabei die zeitliche Länge seines Slots nicht überschreiten. Ist die Nachricht zu lang, muss der nächste Zyklus oder der auf den statischen Bereich folgende dynamische Bereich genutzt werden, um die Nachricht fortzusetzen. Durch den deterministischen Charakter dieses Teils des Protokolls kann sichergestellt werden, dass wichtige Nachrichten (z. B. von Lenkung, Bremssystem und dergleichen) zu und innerhalb einer bekannten Zeit übertragen werden.
-
Der auf den statischen Bereich folgende dynamische Bereich kann von einem Steuergerät verwendet werden, um längere oder zusätzliche Nachrichten zu senden, beispielsweise wenn die Breite seines statischen Slots nicht ausreicht oder für wichtigere Nachrichten benötigt wird. Wenn ein Steuergerät keine Nachricht absetzen möchte, läuft das entsprechende Zeitfenster (im dynamischen Bereich auch als ”Minislot” bezeichnet) ungenutzt ab. Dieser Protokollteil ist in seiner Übertragungsstruktur mit dem CAN-Bus vergleichbar.
-
Die Zuordnung der Slots zu einzelnen Busteilnehmern und die Abarbeitung der Kommunikationsaufgaben erfolgt nach Maßgabe einer vorab definierten Konfiguration. Zentrales Element der FlexRay-Konfiguration ist der sogenannte FlexRay Schedule. Der FlexRay Schedule lässt sich als ein verbindlicher Sendeplan auffassen, der die Zuordnung der Slots zu den einzelnen Teilnehmern regelt und jeweils eine Zuordnung der Signale festgelegt.
-
Zum Versand und/oder Empfang von Nachrichten über einen zeitsynchronen Bus, wie z. B. FlexRay oder TTCAN, sind im Wesentlichen zwei Verfahren bekannt:
Im Rahmen des durch die Anmelderin entwickelten MEDC17-Verfahrens werden periodisch alle zu sendenden Botschaften gesendet und alle zu empfangenden Botschaften empfangen. MEDC17 erleichtert hierdurch die Konfiguration eines entsprechenden Busses, da zwischen einzelnen Aufgaben und/oder Busteilnehmern nur geringe Abhängigkeiten auftreten, die evtl. aufgelöst werden müssen.
-
Durch die im Rahmen von MEDC17 erfolgende Abfrage aller jeweils zu sendenden bzw. zu empfangenden Botschaften wird jedoch unnötig Laufzeit und damit Energie im Mikrocontroller verbraucht. Bestimme vorteilhafte Eigenschaften von zeitsynchronen Bussystemen (z. B. eine bussynchrone Lage von sogenannten Protocol Data Units (PDU)) können daher nicht genutzt werden.
-
Das ebenfalls bekannte AUTOSAR-Verfahren beinhaltet die Erstellung einer Lister der zu dem zeitsynchronen Bus (FlexRay oder TTCAN) synchronen Kommunikationsaufgaben (”Job List” bzw. Jobliste). Aufgrund der Einschränkungen zur Verfügung stehender Softwaremittel muss die Erstellung der Job List durch Experten im Wesentlichen ”von Hand” vorgenommen werden. Eine entsprechende AUTOSAR-Konfiguration kann daher nur von über Expertenwissen verfügenden Integratoren vorgenommen werden.
-
Das sogenannte Fieldbus Exchange Format (FIBER), das sich für das Bussystem FlexRay als Standard etabliert hat, ist ein von der Association for Standardisation of Automation and Measuring Systems (ASAM) definiertes Datenaustauschformat zwischen Werkzeugen, die mit nachrichtenorientierten Bus-Kommunikationssystemen arbeiten.
-
Mittels FIBER können komplexe Kommunikationssysteme in einer Datei mit einem einheitlichen Format zusammengefasst werden. Bei FIBER handelt es sich um eine auf XML basierende Beschreibungssprache, die alle Informationen enthält, um ein komplettes Bordnetz eines Fahrzeugs abzubilden. Hierzu gehören u. a. die Topologie, Konfigurationsparameter, Schedules, Frames und Signale bis hin zu deren Codierung auf Bit-Ebene.
-
FIBER-XML-Dateien beschreiben den Aufbau und das Kommunikationsverhalten von Kfz-Bordnetzwerken sowie Verfahren, mit denen Rohdaten, die auf einem Datenbus übertragen werden, in physikalische Signale umgesetzt werden können. Als standardisierte Beschreibungssprache vereinfacht FIBER den Datenaustausch zwischen allen an einem Projekt Beteiligten. FIBER-Dateien können sehr umfangreich und komplex sein und 200 und mehr Parameter umfassen.
-
Im Rahmen von AUTOSAR sind jedoch keine Algorithmen definiert, die es beispielsweise ermöglichen, aus einer FIBER-Konfiguration eines zeitsynchronen Busses eine Job List zu erzeugen.
-
Es besteht daher der Bedarf nach Verfahren zum Betrieb von zeitsynchronen Bussystemen auf Grundlage optimierter Abarbeitungsanweisungen, welche automatisch unter Verwendung beispielsweise von FIBER-Konfigurationsdateien und weitgehend ohne Benutzerinteraktion erstellt werden.
-
Offenbarung der Erfindung
-
Vor diesem Hintergrund stellt die vorliegende Erfindung ein Verfahren zum Betrieb eines zeitgesteuerten, in Kommunikationsfenstern in einer Abfolge von Kommunikationszyklen kommunizierenden Bussystems unter Verwendung einer aus Eingabedaten und Konfigurationsdaten automatisch generierten Abarbeitungsanweisung zur Abarbeitung von Kommunikationsaufgaben auf Grundlage von Zeitsignalen, ein Verfahren zur Generierung einer entsprechenden Abarbeitungsanweisung sowie ein entsprechendes Computerprogrammprodukt mit den Merkmalen der unabhängigen Patentansprüche bereit. Bevorzugte Ausgestaltungen sind in den jeweiligen abhängigen Ansprüchen angegeben.
-
Wie erwähnt, handelt es sich bei FlexRay um ein zeitsynchrones Busprotokoll, das sogenannte Frames, also Signale, in repetitiven Kommunikationszyklen überträgt. Das FlexRay Protokoll arbeitet auf Grundlage einer globalen Zeitbasis, die in jedem Kommunikationsteilnehmer umgesetzt wird. Zeitangaben erfolgen in Form von systemweit einheitlichen sogenannten Makroticks, die Vielfache der jeweiligen lokalen Zeitbasis (der beispielsweise einem Takt eines lokalen Oszillators entsprechenden Mikroticks) sind. Die nominelle Absolutdauer eines Makroticks ist im gesamten FlexRay-System gleich. FlexRay arbeitet in insgesamt höchstens 64 aufeinanderfolgenden Kommunikationszyklen. Nach Ablauf des letzten (maximal 64.) Zyklus beginnt die Zyklenfolge erneut mit dem ersten Zyklus (Wrap Around). Innerhalb jedes Kommunikationszyklus werden Frames zu einer bestimmten Zeit, definiert durch einen jeweiligen Zeitversatz (Offset), ausgedrückt in Form eines Makrotickwerts bezogen auf den Zyklusbeginn, übertragen und empfangen. Eine zeitliche Terminierung im Rahmen von FlexRay kann daher auf Grundlage einer Zyklusinformation (der laufenden Nummer des jeweiligen Zyklus) und einer Zeitoffsetinformation erfolgen.
-
Die Kommunikation auf dem FlexRay-Bus erfolgt, wie ebenfalls erwähnt, auf Grundlage eines globalen FlexRay Schedule. In einer sogenannten Job List wird die Abarbeitung von Kommunikationsaufgaben (Jobs) festgelegt. Die Job List wird zur Abarbeitung der Aufgaben dabei durch Absolutzeit-Signale (Interrupts) angesteuert (getriggert), wobei die jeweiligen Zyklen- und Makrotickwerte der Interrupts (zur Korrelation der absoluten Position mit dem entsprechenden Zyklus und dem Offset) in der Job List abgelegt sind. Ferner beinhaltet eine Job List Verweise (Pointer) zu jeweiligen zu übertragenden bzw. zu empfangenden Frames Tx bzw. Rx.
-
Die vorliegende Erfindung erlaubt einen Betrieb eines zeitgesteuerten, auf Grundlage einer repetitiven Abfolge von Kommunikationszyklen arbeitenden Bussystems, beispielsweise eines FlexRay-Busses, wobei eine aus Eingabedaten und Konfigurationsdaten automatisch generierte Abarbeitungsanweisung zur Abarbeitung von Kommunikationsaufgaben auf Grundlage von Zeitsignalen verwendet wird.
-
Über die Eingabedaten kann ein Benutzer bzw. Konfigurator eines entsprechenden Bussystems Bezeichner zur Kennzeichnung der Kommunikationsaufgaben, Zyklusinformationen zur Zuordnung der Kommunikationsaufgaben zu wenigstens einem Kommunikationszyklus und Zeitoffsetinformationen zur Terminierung der Kommunikationsaufgaben innerhalb wenigstens eines Kommunikationszyklus angeben. Vorteilhafterweise können die Eingabedaten sehr einfach durch einen Software-Wizard abgefragt werden.
-
Andererseits für die Erstellung der Abarbeitungsanweisung verwendete Konfigurationsdaten beinhalten die Kommunikationsaufgaben definierende und/oder das Bussystem beschreibende Daten, insbesondere in Form einer FIBEX-Konfigurationsdatei.
-
Die automatische Generierung der Abarbeitungsanweisung erfolgt anschließend vollständig automatisch und beinhaltet wenigstens die Erzeugung einer zeitlichen Abfolge der Kommunikationsaufgaben auf Grundlage der Zyklusinformationen und der Zeitoffsetinformationen aus den Eingabedaten, gegebenenfalls die Anpassung der Zeitoffsetinformationen auf Grundlage von Zeitversatzinformationen und die Synchronisierung der Abarbeitungsanweisung mit dem zeitsynchronen Bussystem.
-
Aufgrund der erfindungsgemäßen Maßnahmen wird eine sehr einfache und benutzerfreundliche Konfiguration eines entsprechenden Bussystems mittels einer automatischen Erzeugung optimierter, d. h. resourcenoptimaler Abarbeitungsanweisungen aus einer vorhandenen Konfigurationsdatei ermöglicht.
-
Das erfindungsgemäße Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, ist dazu vorgesehen, das erfindungsgemäße Verfahren durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinrichtung, insbesondere in dem erfindungsgemäßen Steuergerät durchgeführtwird. Hierdurch kann beispielsweise eine besonders benutzerfreundliche Abfrage der Eingabedaten durch eine Wizardfunktion erfolgen.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Es versteht sich, dass die vorstehend genannten und die nachfolgend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt eine Darstellung des FlexRay-Kommunikationsschemas gemäß dem Stand der Technik.
-
2 zeigt eine Darstellung des FlexRay-Kommunikationsschemas gemäß dem Stand der Technik in Detailansicht.
-
3 zeigt eine schematische Darstellung der Verarbeitung von Zeitversatzinformationen gemäß einer Ausführungsform der Erfindung.
-
4 zeigt eine schematische Darstellung der Anpassung von Zeitpositionsinformationen gemäß einer Ausführungsform der Erfindung.
-
5 zeigt eine schematische Darstellung des Ablaufs eines Verfahrens gemäß einer Ausführungsform der Erfindung.
-
In den nachfolgenden Figuren sind einander entsprechende Elemente mit gleichen Bezugszeichen angegeben, wobei auf eine wiederholte Erläuterung der Übersichtlichkeit halber verzichtet wird.
-
In 1 sind im unteren Bereich, insgesamt mit 110 bezeichnet, drei (von insgesamt 64) FlexRay-Zyklen n – 1, n und n + 1 zwischen Zyklengrenzen 111 dargestellt. Die Zyklen n – 1, n und n + 1 weisen jeweils ein statisches Segment S und ein dynamisches Segment D auf. Zur Vermeidung von Verwechslungen mit den im folgenden zu betrachtenden, ebenfalls als ”Segmente” bezeichneten Zeitabschnitten zwischen Interrupts (siehe unten) wird im folgenden für die statischen und dynamischen FlexRay-Segmente S und D, abweichend von der üblichen Terminologie, jeweils der Begriff ”Kommunikationsbereich” verwendet.
-
Im oberen Teil der 1, insgesamt mit 120 bezeichnet, sind insgesamt fünf vollständige, durch Interrupts 121 unterteilte Job List-Segmente x, x + 1, x + 2, x + 3 und x + 4 dargestellt. Die Abarbeitung einer Job List erfolgt derart, dass bei einem Auftreten eines Interrupts 121 stets der jeweils nächste Job aus einer Job List-Konfigurationstabelle abgerufen wird. Hieraufhin wird der nachfolgende Interrupt auf Grundlage der (bekannten) Zyklen- und Zeitoffsetinformation konfiguriert. Mit anderen Worten sind Zyklus- und Zeitoffsetinformation für den nachfolgenden Interruptzeitpunkt (basierend auf der globalen Zeit) in der Job List enthalten und damit konfiguriert. Der Communication Controller (oder ein System Timer) wird mit diesen Werten programmiert und löst dann den nächsten Interrupt aus. Sobald dies erfolgt ist, wird die Ausführung der Kommunikationsoperationen (Senden/Empfang) des momentanen Jobs bewirkt.
-
Wie erwähnt, wird die Job List durch die Interrupts auf Grundlage einer Absolutzeit getriggert. Es wird jedoch auch erwogen, im Rahmen des erfindungsgemäßen Verfahrens eine Job List, die ohne Interrupts arbeitet, zu verwenden. Hierbei können die Interrupts beispielsweise durch – an sich bekanntes – ”Polling” ersetzt werden. Läuft das Betriebssystem hingegen bereits synchron zur globalen Zeit, können die Interrupts durch ”normale” Tasks ersetzt werden.
-
Bezogen auf einen bestimmten Kommunikationszyklus n – 1, n, n + 1 entspricht jede Interruptposition einem Wert, der sich aus einem Zykluswert und einem Offsetwert innerhalb des jeweiligen Zyklus (in Makroticks, nachfolgend als ”Zeitpositionsinformation” bezeichnet) bestimmt. Dieser Sachverhalt ist in 2 veranschaulicht.
-
In der 2 sind insgesamt zwei durch eine Zyklengrenze 111 getrennte Flex-Ray-Zyklen n und n + 1 dargestellt, die jeweils statische und dynamische Kommunikationsbereiche S und D aufweisen. Ferner sind Job List Interrupts 121, als M und M + 1 bezeichnet, dargestellt. Die Werte M und M + 1 entsprechen dabei einem Job Index (Bezeichner) der Job List-Konfigurationstabelle. Ein Segment m lässt sich als Zeitunterschied zwischen den durch die jeweilige Zyklusinformation (also hier n bzw. n + 1) und einen zugehörigen Offsetwert ausgedrückten Zeitstempeln M + 1 und M auffassen. Weitere Segmente sind mit m – 1 und m + 1 angegeben. Die vorliegende Erfindung definiert also Zyklengrenzen überspannende Segmente m – 1, m und m + 1.
-
Eine typische, noch nicht mit Werten beschickte Job List-Konfigurationstabelle ist in der nachfolgenden Tabelle schematisch dargestellt.
| Job Index | Zyklus | Offset | Tx | Rx |
| 0 | | | | |
| 1 | | | | |
| ... | | | | |
| K (Gesamtzahl Jobs) | | | | |
-
Der Wert ”Job Index” bezeichnet in der Job List den momentanen Job bzw. dessen Interruptposition (M, M + 1 etc., jeweils bezogen auf die globale Zeit). Insgesamt ist eine Anzahl K Jobs, entsprechend der Maximalanzahl möglicher Interrupts, konfigurierbar. Unter dem Eintrag ”Zyklus” wird zu jedem Job Index der entsprechende FlexRay-Kommunikationszyklus aufgeführt, in dem der Job ausgeführt wird. Mit ”Offset” ist die Zeitposition (in Makroticks) innerhalb des Zyklus angegeben, zu dem der Job ausgeführt wird. ”Tx” und ”Rx” stellen Verweise (Pointer) auf auszuführende Kommunikationsaufgaben in Form von Arrays dar. Sind für Tx und/oder Rx keine Werte vorgesehen, enthält das entsprechende Feld beispielsweise einen NULL-Pointer. Ein entsprechender Array wird dann nicht generiert.
-
Der Interrupt M der 2 entspricht einem bestimmten Job Index der vorstehenden Tabelle (0, 1, 2, ...). Da der Interrupt M im Beispiel der 2 in den Zyklus n fällt, weist der Parameter ”Zyklus” für diesen Interrupt (bzw. den damit verbundenen Job) den Wert n auf. Der Parameter ”Offset” gibt die Position des Interrupts M innerhalb des Zyklus n in Makroticks an. Entsprechend weist der Parameter ”Zyklus” für den nächsten Interrupt M + 1 den Wert n + 1 auf, da der Interrupt M + 1 in Zyklus n + 1 fällt usw. Jeder Zeilenversatz der in der obigen Tabelle dargestellten Job List-Konfigurationstabelle entspricht also einem Segment m – 1, m, m + 1, das zwischen zwei Interrupts liegt. Die Werte Tx und Rx entsprechen dementsprechend den jeweils in diesem Segment abzuarbeitenden Kommunikationsaufgaben, also beispielsweise zu sendenden und zu empfangenden Sende- und Empfangsframes, der Konfiguration von Puffern bzw. Ressourcen im Communication Controller usw.
-
Vorteilhafterweise kann eine Job List mit sämtlichen Einträgen aufgrund der vorliegenden Erfindung vollständig automatisch erstellt und verwendet werden.
-
Hierzu werden Eingabedaten und Konfigurationsdaten verarbeitet. Wie zuvor erläutert, erlauben üblicherweise zur Konfiguration von zeitgesteuerten Bussystemen verwendete FIBER-XML-Konfigurationsdaten keine Spezifikation von Job List-Merkmalen. Daher werden diese zusätzlich erforderlichen Merkmale in Form von Eingabedaten bereitgestellt. Die Bereitstellung erfolgt vorzugsweise durch eine Abfrage mittels eines Software-Wizards.
-
Aufgrund einer erfindungsgemäß vorgesehenen Erstellungsvorschrift wird dann aus den Eingabedaten und den Konfigurationsdaten, insbesondere aus FIBEX-XML-Daten und/oder einer AUTOSAR-Konfigurationsdatei, eine Job List erstellt, die zur Konfiguration eines entsprechenden zeitsynchronen Bussystems verwendet werden kann. Der zeitsynchrone Bus wird unter Verwendung der Job List betrieben. Alternativ kann die Job List auch in geeigneter Form, beispielsweise in Form von C-Quelltextdateien und zugehörigen Headerdateien, und/oder in Form einer AUTOSAR-Datei, ausgegeben werden. Eine automatische Umwandlung einer AUTOSAR-Datei in eine C-Quelltextdatei ist ebenfalls möglich. Der Benutzer kann damit sehr einfach und unaufwendig eine Abarbeitungsanweisung in Form einer Job List erstellen. Expertenwissen zur Konfiguration bzw. Erstellung einer AUTOSAR-Datei, das, wie zuvor erläutert, bisher zum AUTOSAR-Betrieb erforderlich ist, wird nicht benötigt.
-
Die Konfigurationsdaten werden hier nicht näher erläutert, da das FIBEX-Dateiformat allgemein bekannt ist. Insbesondere weisen Konfigurationsdaten alle relevanten Parameter wie Topologie, Konfigurationsparameter und/oder Frames eines entsprechenden Bussystems auf.
-
Das erfindungsgemäße Verfahren ist jedoch nicht auf die Erstellung einer Job List angewiesen. Wird keine Job List bereitgestellt bzw. auf ihre Verwendung verzichtet, verfährt der FlexRay-Treiber zyklisch über alle vorhandenen Puffer und fragt zu sendende bzw. zu empfangende Frames ab, wie dies auch im Rahmen des zuvor erläuterten MEDC17-Verfahrens erfolgt. Wie bereits zuvor erläutert, wird erwogen, eine Job List auch ohne Interrupts abzuarbeiten.
-
Falls eine Job List verwendet werden soll, müssen die Eingabedaten einen Mindestinhalt aufweisen, der beispielsweise der folgenden Form entspricht:
Frlf_JobName01 (BaseCycle, CycleRepetition, MacrotickOffset)
Frlf_JobName02 (BaseCycle, CycleRepetition, MacrotickOffset)
-
Hierbei weisen die Eingabedaten Jobinformationen bzw. Aufgabeninformationen für zwei abzuarbeitende Jobs auf. JobName01 stellt dabei beispielsweise einen eindeutigen Bezeichner für einen ersten Job, JobName01 entsprechend einen eindeutigen Bezeichner für einen zweiten Job dar.
-
Der Wert BaseCycle gibt den ersten FlexRay-Zyklus an, in dem der Job jeweils auszuführen ist. BaseCycle kann für unterschiedliche Jobs gleich oder unterschiedlich sein. CycleRepetition gibt an, in wie vielen und/oder welchen Zyklen der entsprechende Job auszuführen ist, beispielsweise kann mit ”1” angegeben werden, dass der Job in jedem (auf den mit BaseCycle angegebenen Basiszyklus folgenden) Zyklus ausgeführt wird. MacrotickOffset kennzeichnet schließlich die zeitliche Einordnung bzw. Terminierung des Jobs innerhalb des Zyklus wie zuvor erläutert. Auch CycleRepetition und MacrotickOffset können für unterschiedliche Jobs gleich oder unterschiedlich sein.
-
Beispielsweise können die Jobinformationen, die in den Eingabedaten vorliegen, folgende Werte annehmen:
JobName01 (0, 1, 400)
JobName02 (0, 1, 3000)
-
Hiermit wird in den Eingabedaten definiert, dass ein erster Job mit der Bezeichnung JobName01 ab dem 0-ten Zyklus (BaseCycle = 0) in jedem (CycleRepetition = 1) Zyklus bei einer Makrotickposition von 400 (MacrotickOffset = 400) auszuführen ist. Entsprechend ist ein zweiter Job mit der Bezeichnung JobName02 ebenfalls ab dem 0-ten Zyklus (BaseCycle = 0) und in jedem (CycleRepetition = 1) Zyklus, jedoch bei einer Makrotickposition von 3000 (MacrotickOffset = 3000) auszuführen. Die Jobinformationen, die in den Eingabedaten vorliegen, werden zusammen mit den Konfigurationsdaten zu einer Job List-Konfigurationstabelle umgesetzt.
-
Aus den Konfigurationsdaten werden entsprechend beispielsweise eine Zykluszeit, absolute Timerwerte und den Interrupts zugeordnete Timerwerte, also Absolutpositionen der Interrupts, ermittelt.
-
In einem ersten Schritt zur Erstellung der Job List erfolgt ein Erzeugen einer zeitlichen Abfolge der Kommunikationsaufgaben, also der durch die jeweiligen Bezeichner gekennzeichneten Jobs, auf Grundlage der Zyklusinformationen und der Zeitoffsetinformationen, d. h. aufgrund der Werte BaseCycle, CycleRepetition und MacrotickOffset. Die zeitliche Abfolge kann in einer Job List abgelegt oder anderweitig zwischengespeichert werden. Die zeitliche Abfolge wird beispielsweise durch ein Anordnen der Jobs in aufsteigender Reihenfolge, zunächst entsprechend den Zyklusinformationen und anschließend entsprechend den Offsetinformationen, erzeugt. Eine hieraus hervorgehende vorläufige (”erste”) Job List die mit den obigen Informationen betreffend JobName01 und JobName02 erzeugt wurde, ist in der nachfolgenden Tabelle dargestellt.
| Job Index | Zyklus | Offset | Tx | Rx |
| 0 | 0 | 400 | | |
| 1 | 0 | 3000 | | |
| 2 | 1 | 400 | | |
| 3 | 1 | 3000 | | |
| ... | | | | |
| K (Gesamtzahl Jobs) | | | | |
-
Aus der so erzeugten ersten Job List wird eine zweite Job List erzeugt, in der sogenannte Job Delays in Form positiver oder negativer Zeitverschiebungswerte berücksichtigt werden. Positive Zeitverschiebungswerte (+ve Delay) können erforderlich sein, um beispielsweise hohe Interrupt-Latenzzeiten zu kompensieren. Dieser Zeitverschiebungswert berücksichtigt typischerweise den Zeitunterschied zwischen Soll- und Istzeit eines Interrupts (also eine Interrupt-Latenzzeit) und entspricht beispielsweise der Istzeit des Interrupts und einer ersten Codeausführungszeit einer ISR-Routine. Umgekehrt können negative Zeitverschiebungswerte zur Erzielung einer schnelleren Antwortzeit erforderlich sein, um Daten etwa vorab für eine Übertragung vorzubereiten.
-
In der 3 ist die erfindungsgemäße Zeitverschiebung um die Zeitverschiebungswerte dargestellt und insgesamt mit 300 bezeichnet. Im unteren Teil der 3, mit 310 bezeichnet, sind zwei Segmente m – 1 und m schematisch dargestellt. Zwischen diesen Segmenten existiert eine Segmentgrenze 311. Im oberen Teil der Figur 320 sind Slots mit der Bezeichnung ID 60 und ID 61 dargestellt. Bei diesen Slots kann es sich beispielsweise um Slots von dynamischen und/oder statischen Kommunikationsbereichen eines Kommunikationszyklus handeln. Mit 331 ist eine ursprüngliche Interruptanforderung, die noch nicht um den Zeitverschiebungswert verschoben wurde, angegeben, 332 bezeichnet einen ”virtuellen” Interrupt nach einer entsprechenden Berücksichtigung eines Zeitverschiebungswertes, beispielsweise im Rahmen einer Latenzzeitkorrektur. Der Verschiebungswert ist mit 341 angegeben. Der Verschiebungswert im Rahmen einer Job Delay Correction kann beispielsweise –40 Makroticks betragen. Wie in 3 dargestellt, entspricht die Interruptanforderung 332 noch nicht den Grenzen zwischen den Slots ID 60 und ID 61.
-
Der Benutzer kann separate Werte für positive Zeitverschiebung und negative Zeitverschiebung angeben, welche auch in den Konfigurationsdaten abgelegt werden können. Durch die Verschiebung der Ausführungszeiten um die Zeitverschiebungswerte wird gewissermaßen ein virtuelles Interruptsystem erzeugt, das nun noch mit den realen Slotgrenzen zwischen statischen Slots und dynamischen Slots der statischen und der dynamischen Kommunikationsbereiche abzugleichen ist.
-
Das Angleichen an die realen Slotgrenzen erfolgt vorteilhafterweise mittels eines Verfahrens, das im Folgenden erläutert wird. Der Effekt dieser Maßnahme ist in 4 veranschaulicht, wo, wie in 3, die Segmente m – 1 und m und eine Segmentgrenze 311 angegeben ist. Im Gegensatz zu 3 sind in der 4 drei Slots ID 59, ID 60 und ID 61 eines dynamischen oder statischen Kommunikationsbereichs eines FlexRay-Zyklus angegeben. Es wurde zunächst wie zuvor eine ursprüngliche Interruptanfrage 331 durch eine Verschiebung einen Zeitverschiebungswert 341 unter Erzeugung eines virtuellen Interrupts 332 korrigiert. Wie in 4 zu sehen, entspricht dieser virtuelle Interrupt nicht den Slotgrenzen zwischen den Slots ID 60 und ID 61. Daher muss eine Synchronisierung des virtuellen Interrupts 332 mit einer Slotgrenze erfolgen. Hierzu wird die Slotgrenze zwischen den Slots ID 59 und ID 60 verwendet. Das Ergebnis dieser Synchronisierung ist, als weiterer virtueller Interrupt, mit 333 angegeben.
-
Diese Slotgrenzen-Ausrichtung wird nun erläutert. Die Werte, die die jeweilige Slot-ID angeben und die jeweilige Position spezifizieren, werden den Konfigurationsdaten, beispielsweise der FIBER-XML-Datei entnommen.
-
Es ist nun zu unterscheiden, ob statische FlexRay-Slots des statischen Kommunikationsbereichs oder dynamische Slots (Minislots) des dynamischen Kommunikationsbereichs betrachtet werden. Für statische Slots gilt folgende Gleichung, wobei Gd_Static_Slot die Länge des statischen Slots bezeichnet:
Virtuelle Tx/Rx-Interruptposition (N – 1)
< (Tx/Rx-SIot-ID × Gd_Static_Slot)
≤ Virtueller Tx/Rx-Interrupt (N)
-
Es erfolgt jeweils eine getrennte Berechnung für Tx- und Rx-Frames, da deren virtuelle Interrupts, wie zuvor erläutert, unterschiedlich sein können.
-
Für dynamische Slots gilt, mit Gd_MaxDynamicLength als der maximalen Länge eines dynamischen Slots (Minislots), entsprechend:
Virtuelle Tx/Rx-Interruptposition (N – 1)
< (Tx/Rx-SIot-ID × Gd_MaxDynamicLength)
≤ Virtueller Tx/Rx-Interrupt (N)
-
Aufgrund der zuvor erläuterten Maßnahmen ist nun im wesentlichen eine Ausrichtung der Slotgrenzen mit den Interrupts bzw. Interruptanforderungen erfolgt.
-
Zur Verwendung in einem zeitgesteuerten Bussystem muss die erzeugte Job List in einer Echtzeitumgebung synchronisiert werden. Hierzu wird eine Vorschrift verwendet, die zur Übertragung und zum Empfang von FlexRay-Frames nach Maßgabe der statischen Konfiguration, wie zuvor erläutert, eingesetzt wird.
-
Ein FlexRay-Cluster, der sich im Zustand ”Normal Active” befindet, erneuert seine Statusvariablen. Hierdurch werden die FlexRay-Timer-Interrupts aktiv.
-
Es wird folgendes Verfahren ausgeführt:
- 1. Wenn ein Cluster (Kommunikationsteilnehmer) sich im Zustand ”Normal Active” befindet, liest er die FlexRay-Globalzeit, d. h. die momentane Zyklus- und Makrotickposition (curr_cycle und curr_macro_tick).
- 2. Nun wird ein geeigneter Zyklus-Verschiebungszeitwert zum momentanen Zykluswert hinzugefügt (curr_cycle += CYCLE_DELAY, beispielsweise 10 ms). CYCLE DELAY wirkt dabei als ein Sicherheitspuffer, um den Job List-Scheduler auszurichten.
- 3. Eine optimierte Suchroutine wird ausgeführt, um einen Jobindex aufzufinden, dessen Zykluswert größer oder gleich dem momentanen Zyklus ist:
Job_Index → Zyklus ≥ curr_cycle.
- 4. Wenn die Suchroutine ein Ergebnis zurückgibt, wird der nächste FlexRay-Zeitgeber-Interrupt auf den entsprechenden Zyklus- und Makrotickwert von Job_Index eingestellt.
- 5. Nach Synchronisierung der Job List wird der Timer-Interrupt für den nächsten Job aus der Job List-Tabelle abgerufen, sobald ein Zeitgeber-Interrupt für den momentanen Job festgestellt wird.
- 6. Kommunikationsaufgaben, beispielsweise in Form von Tx- und Rx-Frames werden aus der Job List-Tabelle abgerufen, Tx-Frames werden übertragen und die Rx-Frames werden für den momentanen Job empfangen und/oder verarbeitet.
Schritte 5 und 6 werden wiederholt, solange der Communication Controller synchron zur globalen Zeit bzw. zum Bus ist. Gegebenenfalls ist hier auch ein Wrap Around zu berücksichtigen.
- 7. Sobald ein Synchronisationsverlust des FlexRay Controllers eintritt, wird die Vorschrift ab Schritt 1 erneut ausgeführt (Wrap Around).
-
Das erfindungsgemäße Verfahren kann vorteilhafterweise im Rahmen einer Erstellungsvorschrift für eine Job List-Konfigurationstabelle zum Einsatz kommen, wie es in 5 schematisch veranschaulicht und mit 500 bezeichnet ist.
-
Das Verfahren bedient sich zweier Datenquellen für die zuvor erläuterten Eingabedaten 1 und die Konfigurationsdaten 2, beispielsweise einer FIBEX-Konfigurationsdatei 2. In Schritt 3 wird aus diesen Daten mittels eines Job List-Abstraktionsverfahrens, wie zuvor erläutert, eine Job List-Konfigurationstabelle 4 erzeugt und ausgegeben. Diese Job List-Konfigurationstabelle 4 kann ohne weitere Bearbeitung zum Betrieb eines zeitgesteuerten Bussystems eingesetzt werden. Alternativ kann auch in Schritt 5 eine C-Quelltextdatei (beispielsweise zur Verwendung in einer Ansteuerungssoftware) mit zugehöriger Headerdatei und/oder in Schritt 6 eine AUTOSAR-XML-Datei mit Job List-Details erzeugt werden. Eine entsprechende C-Quelltextdatei mit zugehöriger Headerdatei kann auch aus der entsprechenden AUTOSAR-XML-Datei erzeugt werden, wie mit Ablaufpfeil 7 veranschaulicht.
