-
Die
Erfindung bezieht sich auf ein System zum Testen einer aus mehreren
Steuergerät(en) bestehenden Steuergeräteanordnung,
wobei die Steuergeräte und etwaige weitere Busteilnehmer über
einen zeitlich deterministischen Datenbus miteinander verbunden
sind, und wobei mindestens eines der Steuergeräte durch
eine Simulationsroutine ersetzt ist.
-
Ein
derartiges System ist für beliebige Datenbusse unter der
Bezeichnung Restbus-Simulationseinrichtung bekannt. Für
einen zeitlich deterministischen Datenbus, hier den sog. FlexRay-Datenbus
ist eine derartige Einrichtung aus
http://www.design-elektronik.com/index.php?id=1697&type=98
unter
dem Titel „Restbussimulation für FlexRay-Systeme"
bekannt. Dabei werden, wie bei derartigen Einrichtungen üblich,
Nachrichten von (noch) nicht real im Netzwerk vorhandenen Steuergeräten
nachgebildet. Auf diese Weise können Steuergeräte
getestet werden, ohne dass der komplette Datenbus aufgebaut werden
muss. Die Restbussimulation ist also eine Methode zum Test eines
vernetzten Systems aus Steuergeräten und ggf. weiteren
Busteilnehmern, das nur teilweise real vorliegt. Fehlende Busteilnehmer
(der Restbus) werden auf einem Simulator virtuell nachgebildet.
Hierzu werden Ersatzmodelle verwendet, deren Resultate vom Simulator
an die realen Knoten verschickt werden.
-
Beim
bekannten System übernimmt ein einziger am Datenbus angeschlossener
Rechner die vielfältigen Funktionen, die erforderlich sind,
um die fehlerfreie Arbeitsweise des realen, d. h. mit den tatsächlichen
Steuergeräten und Busteilnehmern ausgestatteten Gesamtsystems
sicherzustellen. Es handelt sich dabei zum einen häufig
um die Berücksichtigung der busspezifischen Besonderheiten
eines meist neuartigen Busprotokolls. Hier ist die zeitgesteuerte
Aktivierung von Kommunikation und zugeordneten Anwendungen zu nennen,
für die spezielle Entwicklungsmethoden notwendig sind.
Zusätzlich müssen die vielfältigen Konfigurationsmöglichkeiten des
Datenbusses beim jeweiligen Projekt konkretisiert werden. Und letztlich
sind neben dem Datenbus noch weitere neue Abwendungs-Standards zu
berücksichtigen, die beim Einsatz des Datenbusses maßgeblich
sind.
-
Der
Erfindung liegt die Aufgabe zu Grunde, ein System der eingangs genannten
Art und ein Verfahren für ein derartiges System zu schaffen,
das eine verlässliche Restbussimulation gewährleistet.
-
Die
Erfindung löst diese Aufgabe für das System mit
den im Patentanspruch 1 und für das Verfahren mit den im
Patentanspruch 2 angegebenen Mitteln.
-
Die
Erfindung ist im Folgenden näher erläutert. Zur
Vereinfachung ist der deterministische Datenbus als FlexRay-Datenbus
bezeichnet.
-
Die
Realzeit-Restbussimulation für FlexRay besteht aus den
Komponenten ein oder mehrere kostengünstige(r) Realzeitrechner
mit dem notwendigen Teil der Realzeit-Restbussimulationssoftware
für FlexRay sowie einem kostengünstigen Standardrechner
mit Standard-Software (z. B. PC mit Windows) und hinreichendem Teil
der Realzeit-Restbussimulationssoftware für FlexRay. Unter
Realzeit ist ein garantiertes, planbares, d. h. ein „deterministisches
Zeitverhalten" zu verstehen.
-
Jede
Komponente erfüllt eine dedizierte Aufgabe. 1 zeigt
den schematischen Aufbau der Realzeit-Restbussimulation für
FlexRay. Die Realzeit-Restbussimulation für FlexRay wird
im Folgenden FlexRay-RBS genannt und der Standardrechner mit Standard-Software
nur Standardrechner.
-
Der
oder die Realzeitrechner kommunizieren über das Bussystem
FlexRay mit einem oder mehreren Steuergerät(en) und über
ein gewöhnliches Bussystem (z. B. Ethernet) mit dem Standardrechner.
Die Anzahl der Realzeitrechner richtet sich im Wesentlichen nach
der Rechenarbeit und dem Speicherbedarf des notwendigen Teils der
FlexRay-RBS-Software sowie den Ressourcen der oder des Realzeitrechner(s).
Die Anzahl der Steuergeräte hängt vom Anwendungsfall
ab. In einem Netzwerk mit n Steuergeräten können
Restbussimulationen für 1 bis n – 1 Steuergeräte
erstellt werden.
-
Auf
dem oder den Realzeitrechner(n) werden vor allem zeitkritische Aufgaben
(harte Realzeit-Tasks) der FlexRay-RBS-Software bearbeitet. Bei
einer harten Realzeit-Task steigen die Kosten sprunghaft mit dem
Verletzen einer Zeitrestriktion an, z. B. durch einen erhöhten
Entwicklungsaufwand oder eine höheres Restrisiko.
-
Zu
den zeitkritischen Aufgaben der FlexRay-RBS zählen die
rechtzeitige Be- und Verarbeitung von FlexRay-Telegrammen (Frames)
und die rechtzeitige Reaktion auf Ereignisse des technischen Prozesses.
Diese Aufgaben werden paketweise in jedem Zyklus erledigt, um den
Ressourcenbedarf gering zu halten. Der geringere Ressourcenbedarf
und der modulare Aufbau ermöglichen es, eine kostenoptimierte
FlexRay-RBS zu erstellen.
-
Der
Standardrechner ist für Aufgaben mit unscharfen Zeitrestriktionen,
so genannte weiche Realzeit-Tasks, und/oder rechenintensive Aufgaben
zuständig. Bei weichen Realzeit-Tasks steigen die Kosten
mit der Dauer der Bearbeitung oder der Überschreitung einer
Zeitrestriktion langsam an (z. B. Wartezeit).
-
Die
Aufgaben des Standardrechners mit dem hinreichenden Teil der FlexRay-RBS-Software umfassen
die Konfiguration, die Benutzerschnittstelle, eine Automatisierungsschnittstelle
und die automatische Steuerung des oder der Realzeitrechner(s). Es
werden nur relevante Frames konfiguriert und auf dem oder den Realzeitrechner(n)
simuliert. Dadurch bleibt der Ressourcenbedarf gering, und es können kostengünstige
Realzeitrechner verwendet werden. Außerdem werden Frames
von anderen Bussystemen, die über ein Gateway, das i. A.
für die Kommunikation transparent ist, auf das eigentliche
Bussystem gelangen und für eine Restbussimulation wichtig sind,
berücksichtigt (z. B. Netzwerkmanagement).
-
Das
oder die Steuergeräte selbst sind nicht Teil der FlexRay-RBS.
Eine FlexRay-RBS wird z. B. für die Entwicklung eines Steuergeräts
oder den Test mehrerer, aber nicht aller Steuergeräte an
FlexRay (Teilsystemintegration) benötigt.
-
Die
Software-Architektur ist in 2 gezeigt. Sie
sieht eine Trennung der FlexRay-RBS-Software in einen notwendigen
und hinreichenden Teil vor. Der notwendige Teil befindet sich auf
dem oder den Realzeitrechnern, der hinreichende Teil auf dem Standardrechner.
-
Im
notwendigen Teil werden harte Realzeit-Tasks und Aufgaben mit kurzen
Reaktionszeiten bearbeitet. Die harten Realzeit-Tasks steuern den oder
die Realzeitrechner so, dass Prozessdaten rechtzeitig verarbeitet
und die scharfen Zeitrestriktionen beim Steuern des zeitgesteuerten
Bussystems FlexRay eingehalten werden.
-
Bsp.
hierfür sind das rechtzeitige Beschreiben/Lesen von Sende/Empfangsregistern
und das rechtzeitige Berechnen von Alive-Countern, Application-CRCs,
Testsignalen (z. B. Sprung, Rampe, Sinus) sowie Modellen für
Regelkreisglieder.
-
Nebenaufgaben
für den notwendigen Teil der FlexRay-RBS-Software sind
der Austausch von Steuer- und Prozessdaten mit dem Standardrechner für
die Steuerung des oder der Realzeitrechner sowie die Manipulation
von Prozessdaten entsprechend den Vorgaben vom Standardrechner.
Ferner gehören zu den Nebenaufgaben Deadline-Monitoring,
Fehlerinjektion und die Meldung bzw. das Anzeigen von Fehlern und
Alarmen.
-
Restbussimulationen
für FlexRay ohne scharfe Zeitrestriktionen können
den Busverkehr nicht exakt wiedergeben, hauptsächlich weil
FlexRay oft verspätet angesteuert wird. Einige Frames werden
dadurch lange verzögert. In bestimmten Situationen reagieren
Steuergeräte darauf mit Fehlern. Des Weiteren ist damit
kein vollständiger Test gegen die Spezifikation möglich.
Dieser Mangel muss entweder mit einem meist erheblichen Entwicklungsmehraufwand
kompensiert werden, oder es wird ein höheres Restrisiko
in Kauf genommen.
-
Ein
Standardrechner kann nur unscharfe Zeitrestriktionen erfüllen.
Das liegt an der Architektur eines Standardrechners und von Standard-Software. Beides
ist für eine hohe mittlere Rechenleistung optimiert, nicht
jedoch für die Einhaltung von scharfen Zeitrestriktionen.
Bei einem Realzeitrechner verhält es sich genau anders.
Damit man die Vorteile eines Standardrechners mit Standardsoftware
für die FlexRay-RBS nutzen kann, benötigt man
eine so genannte Realzeiterweiterung. Aus diesem Grund ist die hier beschriebene
Trennung der FlexRay-RBS-Software erforderlich. Ein oder mehrere
Realzeitrechner mit entsprechender Software stellt bzw. stellen
eine Möglichkeit für eine Realzeiterweiterung
dar.
-
Die
Vorteile eines Standardrechners mit Standard-Software sind die großen
Ressourcen (Speicher, Rechenleistung, Bildschirm etc.), die vielfältigen Kommunikationsschnittstellen
(Ethernet, USB, COM, Sockets etc.), die weite Verbreitung und die
ergonomische Bedienung. Ein Realzeitrechner bietet das I. A. nicht.
-
Im
hinreichenden Teil der FlexRay-RBS-Software werden rechenintensive und/oder
zeitunkritische Aufgaben ausgeführt, er benötigt
die Eigenschaften eines Standardrechners mit Standard-Software.
Zum hinreichenden Teil der FlexRay-RBS-Software gehören
die Konfiguration, die Benutzerschnittstelle (GUI = Graphical User
Interface), eine Schnittstelle zu anderen Anwendungen und/oder Rechnern
(AI = Automation Interface) sowie eine automatische Steuerung des
oder der Realzeitrechner(s).
-
Die
FlexRay-RBS-Software ist an keine bestimmte Hardware gebunden, es
müssen lediglich ausreichend Ressourcen vorhanden sein
und ggf. Schnittstellen angepasst werden. Mit den meisten der heute üblichen
sog. Embedded-Systems lässt sich die FlexRay-RBS aufbauen.
-
Die
Einhaltung von Zeitbedingungen (Realzeitfähigkeit) ist
bei FlexRay wesentlich. Der notwendige Teil der FlexRay-RBS-Software
trägt hierfür die Verantwortung, seine Funktionsweise
ist in 3 beispielhaft dargestellt.
-
FlexRay
ist ein zeitgesteuertes Bussystem mit deterministischem Zeitverhalten.
Die Übertragung von Frames über FlexRay findet
typischerweise zyklisch statt. In jedem Zyklus werden viele unterschiedliche
Frames nacheinander in definierten Zeitintervallen (Slots) gesendet.
Am Ende eines Zyklus gibt es eine kurze Pause, die so genannte Network-Idle-Time
(NIT).
-
Für
einen reibungslosen Ablauf müssen die in den Frames zu
versendenden Daten rechtzeitig vor dem jeweiligen Slot berechnet
und in ein Senderegister geschrieben werden. Rechtzeitig heißt
in diesem Zusammenhang in einem bestimmten Zeitfenster. Werden Daten
zu früh in ein Senderegister geschrieben, sind sie u. U.
nicht aktuell, werden sie zu spät geschrieben, findet ihre Übertragung
frühestens im nächsten Zyklus statt (viel zu spät)
oder gar nicht, wenn sie überschrieben werden.
-
Die
Folgen hängen von der Anwendung ab, auf jeden Fall handelt
es sich um einen Fehler der Restbussimulation.
-
Da
die Zeit in FlexRay von zentraler Bedeutung ist, findet eine Synchronisation
zwischen FlexRay und der FlexRay-RBS-Software auf dem oder den Realzeitrechner(n)
statt. Die Synchronisation muss in gewissen Zeitabständen
wiederholt werden, damit der Zeitunterschied zwischen der Uhr in
einem Realzeitrechner und der globalen FlexRay-Uhr nicht zu groß wird.
Ansonsten ist keine dauerhafte Realzeitfähigkeit möglich.
-
Für
die Synchronisation verwendet die FlexRay-RBS-Software auf dem oder
den Realzeitrechner(n) das Start-of-Cycle-Event (SoC) von FlexRay. Hardware-Interrupts,
Software-Interrupts, Prozessereignisse, Trigger u. ä. werden
zusammenfassend als Events bezeichnet. Das SoC-Event tritt zu Beginn eines
jeden FlexRay-Zyklus auf und eignet sich besonders gut für
die Synchronisation, weil der Startprozess einfach ist. Die Synchronisation
der FlexRay-RBS-Software auf einem Realzeitrechner kann aber auch
mit anderen geeigneten FlexRay-Events erfolgen.
-
Das
SoC-Event im Bsp. in 3 tritt zum Zeitpunkt t0 auf.
Die FlexRay-RBS-Software startet daraufhin einen Timer (Zeile Timer
in 3) im Realzeitrechner. Mit Ablauf des Timers zum
Zeitpunkt t1 erzeugt der Realzeitrechner ein Timer-Event (Tmr-Event).
Die FlexRay-RBS-Software reagiert darauf, indem sie den Timer neu
startet und die Task 1 aktiviert. In dieser Task werden die Daten
in den bis dahin empfangenen Frames sowie aufgetretene Events (z.
B. von einem Regler) ausgewertet und soweit als möglich
verarbeitet – durch Abhängigkeiten zu später
eintreffenden Frames oder Events ist eine endgültige Verarbeitung
teilweise erst später möglich. Die paketweise
Verarbeitung ermöglicht eine Realisierung mit weniger Ressourcen,
gegenüber einer Restbussimulation mit sofortiger Reaktion.
Durch die paketweise Verarbeitung werden die Anzahl der Task-Wechsel
und die Anzahl der Tasks reduziert, was sich vor allem in der Rechenzeit
und im Speicherplatz bemerkbar macht.
-
Mit
dem Erreichen der Zeitpunkte t3 und t4 wiederholt sich der geschilderte
Ablauf. Zum Zeitpunkt t4 wird eine andere Task, Task 3 aktiviert.
Man kann mehrere Tasks verwenden, muss es aber nicht. Das Gleiche
gilt für den Timer. Es ist genauso möglich mehr
als einen Timer zu verwenden. Die Anzahl der Tasks pro Zyklus, die
Anzahl der Timer und die Einstellung der Timeout-Werte hängen
von den Ressourcen und der Konfiguration des oder der Realzeitrechner(s)
ab.
-
Im
Bsp. in 3 ist nach Task 3 die Bearbeitung
im Zyklus n zu Ende. Nach der NIT beginnt ein neuer Zyklus (Zyklus
n + 1) und das Ganze beginnt von vorne. Weil über FlexRay
die meisten Frames periodisch übertragen werden, werden
die Timeout-Werte für den oder die Timer im Konfigurationsprozess
fest eingestellt. Die Eigenschaften des oder der Realzeitrechner(s)
bestimmen, wie der oder die Timer realisiert und die Timeout-Werte
verarbeitet werden (z. B. Hardware, Software, Interrupt, extern, intern,
auto-reload).
-
Aperiodische
Frames, Ausnahmeereignisse (z. B. Fehlerbehandlungen, Steuerbefehle
vom Standardrechner) oder reaktionsschnelle Aufgaben (z. B. Lesen
eines Frames in einem Slot, verarbeiten der Daten und Schreiben
des Ergebnisses im nächstmöglichen Slot) werden
in der FlexRay-RBS mittels Exceptions behandelt. Im Bsp. in 3 ist
das zum Zeitpunkt t2 der Fall. Mit Exceptions wird der beschriebene
starre Zyklus um einen dynamischen Anteil ergänzt.
-
Eine Überprüfung
der Zeitrestriktionen (Deadline-Monitoring) auf dem oder den Realzeitrechner(n)
erkennt, wenn Senderegister zu spät beschrieben werden.
In FlexRay sind die Sendezeitpunkte wegen der Zeitsteuerung a priori
definiert. Mit einer zu FlexRay synchronen Uhr und/oder einem synchronen
Slot-Zähler wird in der FlexRay-RBS vor dem Schreiben in
ein Senderegister die Rechtzeitigkeit geprüft. Falls die
Prüfung negativ ausfällt, wird das Senderegister
nicht beschrieben und die Deadline-Verletzung angezeigt. Gegenüber
einem herkömmlichen Deadline-Monitoring, hat das Deadline-Monitoring
in der FlexRay-RBS die Vorteile, dass es unabhängig von
Tasks ist und eine Sättigungscharakteristik aufweist. Durch
die Sättigungscharakteristik werden Folgefehler bei Überlast
vermieden.
-
Der
Konfigurationsablauf der FlexRay-RBS ist in 4 dargestellt.
Für die Konfiguration wird eine FIBER-Datei (Field Bus
Exchange Format) geladen und die zu simulierenden Steuergeräte
ausgewählt. In der FIBER-Datei ist die Kommunikation auf dem
Bussystem FlexRay in XML (Extensible Markup Language) beschrieben.
Die Beschreibung enthält im Wesentlichen welches Steuergerät
wann welches Frame sendet und welches bzw. welche Steuergeräte
wann welches Frame empfängt bzw. empfangen.
-
Mit
der Auswahl der zu simulierenden Steuergeräte durch den
Benutzer oder über eine Konfigurationsdatei werden die
Frames auf FlexRay automatisch festgelegt. Es werden nur die relevanten
Frames berücksichtigt (siehe auch 6 links).
Außerdem werden Frames hinzugefügt, die für
eine Restbussimulation wichtig sind, aber einem anderen Bus angehören
(externe Frames). Ein typisches Beispiel ist der Frame „Klemmen",
er wird von einem CAN-Bus über ein Gateway (nicht dargestellt)
an FlexRay geschickt und ist für eine Restbussimulation notwendig.
-
Die
Verteilung der Frames auf die zur Verfügung stehenden Realzeitrechner
erfolgt, wie in 6 rechts gezeigt, in Abhängigkeit
von den Ressourcen, unter Berücksichtigung des Funktionsaspekts
sowie der Bedienervorgaben. Durch den Funktionsaspekt wird eine
Partitionierung ohne Overhead des notwendigen Teils der FlexRay-RBS-Software
für die Realzeitrechner gewährleistet. Die Realzeitrechner
generieren und versenden alle Frames einer Funktion.
-
Durch
das Simulieren nur der benötigten Frames und die besondere
Partitionierung, können mit der FlexRay-RBS zusätzliche
Kosten aufgrund der besseren Ressourcennutzung vermieden werden.
-
Von
der Konfiguration sind der oder die Realzeitrechner und die GUI
betroffen. Für den oder die Realzeitrechner wird daraus
ein entsprechendes Steuerungsprogramm bzw. werden entsprechende Steuerprogramme
erstellt. Anschließend werden das oder die Steuerprogramm(e)
auf den oder die Realzeitrechner geladen und zur Ausführung
gebracht. Für die GUI werden, gemäß der
Konfiguration, Beobachtungs- und Manipulationselemente eingerichtet. Der
Konfigurationsprozess geschieht automatisch, ein manuelles Verfahren
ist wegen der Vielfalt der Restbussimulationen nur in Sonderfällen
sinnvoll. Damit die GUI mit dem oder den richtigen Steuerprogramm(en)
auf dem oder den Realzeitrechner(n) arbeitet, ist bei der FlexRay-RBS
eine eindeutige Kennung (ConfigCheckID) vorhanden.
-
Der
Ablauf einer FlexRay-RBS auf dem Standardrechner ist in 5 dargestellt.
Nach der Konfiguration wird die Restbussimulation gestartet. Über
die GUI werden Teile der FlexRay-RBS auf dem oder den Realzeitrechner(n)
manuell gesteuert. Ein Benutzer kann Frames oder Teile davon (Signale) manipulieren
und ist dadurch in der Lage, z. B. ein bestimmtes Geschwindigkeitssignal
oder Temperatursignal vorzugeben. Die Benutzermanipulationen können
automatisiert werden, indem übergeordnete Anwendungen und/oder
Rechner (HiL, Prüfstandsautomaten, Simulations-Software)
den oder die Realzeitrechner über die AI steuern. Um die
Ressourcen der Realzeitrechner zu schonen, werden geänderte Daten
nicht einzeln übertragen, sondern in Paketen.
-
Eine
interne Steuerung ist mittels weicher Realzeit-Tasks möglich.
Hiermit können Aufgaben mit unscharfen Zeitrestriktionen,
insbesondere des technischen Prozesses, auf dem Standardrechner mit
Standard-Software erledigt werden; Bsp. sind Test- oder Prüfszenarien,
Transportprotokolle und komplexe, zeitunkritische Regelstreckenmodelle.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- - http://www.design-elektronik.com/index.php?id=1697&type=98 [0002]