DE10303489A1

DE10303489A1 - Verfahren und Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs

Info

Publication number: DE10303489A1
Application number: DE10303489A
Authority: DE
Inventors: Manfred Birk; Michael Zimmermann; Uwe Loew; Gottfried Frenzen
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2003-01-30
Filing date: 2003-01-30
Publication date: 2004-08-12

Abstract

Verfahren zum Testen von Software einer Steuereinheit eines Fahrzeugs, wobei durch ein Testsystem eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert wird, wobei Ausgangssignale von der Steuereinheit erzeugt werden und diese Ausgangssignale der Steuereinheit zu ersten Hardware-Bausteinen über eine erste Verbindung übertragen werden und Signale von zweiten Hardware-Bausteinen als Eingangssignale zur Steuereinheit über eine zweite Verbindung übertragen werden, dadurch gekennzeichnet, dass die Ausgangssignale als erste Steuerwerte in der Software bereitgestellt werden und zusätzlich über eine Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zum Testsystem übertragen werden.

Description

Stand der Technik
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs, wobei durch ein Testsystem eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert wird gemäß den unabhängigen Ansprüchen.
Da die Steuergerätesoftware permanent komplexer wird und der Anteil der Überwachungsfunktionen zunimmt, ist ein Test der Gesamtsoftware als sogenannter Software-Systemtest inzwischen nur noch am Fahrzeug oder an einem Hardware-in-the-Loop-Testsystem möglich.

Beim Test am Fahrzeug wird das Motorsteuergerät mit der in Entwicklung befindlichen Software über einen Trennadapter an den Motorprüfstand angeschlossen bzw. in ein Versuchsfahrzeug eingebaut. Dabei werden dann manuell nach Checkliste verschiedene Tests durchgeführt und die Testergebnisse protokolliert. Dadurch sind die Tests bzw. Testergebnisse üblicherweise nicht frühzeitig verfügbar, da erst eine Auswertung der Protokolle erfolgen muss. Daneben sind die Ergebnisse und Testabläufe nicht in allen Ausstattungsvarianten verfügbar, da eine sehr individuelle Abstimmung auch in Hardware notwendig ist. Weiterhin sind die Tests nicht automatisier- oder reproduzierbar. Daneben lassen sich viele Tests nicht oder nicht in gewünschtem Umfang durchführen, da diese durch den Hardwarebezug sehr stark von Randbedingungen abhängen.

Bei einem Test an einem Hardware-in-the-Loop-Testsystem werden die relevanten Fahrzeugkomponenten elektronisch nachgebildet. Hierzu werden die im Fahrzeug befindlichen Aktoren elektronisch nachgebildet bzw. Originalaktoren in das Testsystem eingebaut. Elektronische Baugruppen vermessen die Signale, mit denen das Steuergerät diese Aktoren ansteuert. Diese Messergebnisse fließen dann zusammen mit den Bedieneingriffen der testenden Person in eine nummerische Fahrzeugsimulation ein. Die Simulationsergebnisse werden dann wiederum über elektronische Baugruppen in elektrische Signale umgesetzt, die gegenüber dem Steuergerät das Sensorverhalten simulieren. Auf diese Art wird erreicht, dass gegenüber dem Steuergerät das Verhalten des restlichen Fahrzeugs einschließlich Fahrer und Umweltumgebung in dem Umfang nachgebildet wird, wie es für den Softwaretest erforderlich ist. Ein solcher Test ist in 1 im Rahmen des Standes der Technik dargestellt. Durch den Hardware-in-the-Loop-Test können zwar viele der oben genannten Nachteile des Tests am Fahrzeug überwunden werden, es entstehen aber dabei sehr hohe Kosten durch die notwendige elektronische Umsetzung und hoher Platzbedarf. Durch die jeweilige Anpassung an das entsprechende Steuergeräteprojekt entsteht eine aufwendige Projektierung, und für die effektive Nutzung dieses Testverfahrens ist umfangreiches Testsystem-Know-how erforderlich.

Somit zeigt sich, dass der Stand der Technik nicht in jeder Hinsicht optimale Ergebnisse zu liefern vermag. Damit ist es Aufgabe der Erfindung, ein neues Testsystem bereitzustellen, das gemäß der erfindungsgemäßen Vorrichtung sowie des entsprechenden Verfahrens höhere Flexibilität und schnellere Anpassbarkeit an Steuergeräteprojekte ermöglicht, sowie mit deutlich geringeren Kosten verbunden ist.

Vorteile der Erfindung

Zur Lösung der Aufgabe wird ein Verfahren und eine Vorrichtung vorgeschlagen zum Testen von Software einer Steuereinheit eines Fahrzeugs, wobei durch ein Testsystem eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert wird, wobei Ausgangssignale von der Steuereinheit erzeugt werden und diese Ausgangssignale der Steuereinheit zu ersten Hardware-Bausteinen über eine erste Verbindung übertragen werden und Signale von zweiten Hardware-Bausteinen als Eingangssignale zur Steuereinheit über eine zweite Verbindung übertragen werden, wobei vorteilhafter Weise die Ausgangssignale als erste Steuerwerte in der Software bereitgestellt werden und zusätzlich über eine Kommunikationsschnittstelle in Echtzeit, bezogen auf die Regelstrecke, zum Testsystem übertragen werden.

Weiterhin von Vorteil ist, dass das Testsystem abhängig von den ersten Steuerwerten Simulationsergebnisse erzeugt und diese als zweite Steuerwerte ebenfalls über die Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zur Steuereinheit überträgt. Zweckmäßiger Weise kann das Testsystem auch Fehlervorgaben erzeugen und diese über die Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zur Steuereinheit übertragen.

Dabei ist dann von Vorteil, dass als Fehlervorgaben dritte Steuerwerte als Aktorfehler und/oder vierte Steuerwerte als Sensorfehler der Regelstrecke durch das Testsystem jeweils vorgegeben und über die Kommunikationsschnittstelle zur Steuereinheit übertragen werden.

In einer besonderen Ausgestaltung der Steuereinheit ist die Software in einen hardwareabhängigen Anteil und einen hardwareunabhängigen Anteil bezogen auf eine Hardware der Steuereinheit aufgeteilt, wobei die Ausgangssignale als physikalische Größen repräsentierende erste Steuerwerte im hardwareunabhängigen Anteil der Software bereitgestellt werden.

In einer vorteilhaften Ausgestaltung wird als Kommunikationsschnittstelle die Applikationsschnittstelle des Steuergerätes verwendet.

Dadurch, dass im neuen Testsystem gemäß der Erfindung der Informationsaustausch zwischen simulierendem Testsystem und dem Steuergerät nicht mehr über elektrische Signale, sondern per Datenaustausch über die Kommunikationsschnittstelle, insbesondere die Applikationsschnittstelle erfolgt, entsteht der angesprochene Kostenvorteil und ebenso die erhöhte Flexibilität.

Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus der Beschreibung sowie den Merkmalen der Ansprüche.

Zeichnung

Die Erfindung wird im Weiteren anhand der in der Zeichnung dargestellten Figuren näher dargestellt. Dabei zeigt

1 den schematischen Aufbau eines erfindungsgemäßen Testsystems.

In 2 ist als Stand der Technik ein gängiges Hardware-in-the-Loop-Testsystem dargestellt zur Verdeutlichung der erfindungsgemäßen Unterschiede.

3 zeigt dann als Pendant die Struktur des erfindungsgemäßen Softwaretestsystems mittels Kommunikationsschnittstelle.
Beschreibung der Ausführungsbeispiele
1 zeigt ein Steuergerät 100 zur Steuerung von Betriebsabläufen bei einem Fahrzeug, beispielsweise zur Motorsteuerung, Getriebesteuerung, Bremsensteuerung, aber auch zur Steuerung weiterer Sicherheitssysteme wie Airbag oder auch Komfortfunktionen. Darin ist eine Steuereinheit oder auch Verarbeitungseinheit 103 enthalten. Diese Steuereinheit 103 stellt beispielsweise einen Mikrocomputer oder Controller dar, der die Steuergerätesoftware bzw. Software der Steuereinheit ausführt, im Allgemeinen inklusive der Regelungs- und Diagnosefunktionen. Diese Steuereinheit 103 ist über eine erste Verbindung 106, beispielsweise ein internes Bussystem oder sonstige Verbindungsleitungen mit einem ersten Hardwarebaustein oder einer Hardwarebaugruppe 104 verbunden. Die Hardwarebaugruppe 104 stellt dabei die Verbindung zur Ansteuerung von Aktoren bezüglich der Steueraufgaben des Steuergerätes 100 dar. Ebenso ist die Steuereinheit 103 über eine zweite Verbindung 107 mit einem zweiten Hardwarebaustein oder zweiten Hardwarebausteinen bzw. einer zweiten Hardwarebaugruppe 105 verbunden. Diese Hardwarebaugruppe 105 stellt dabei das Verbindungsglied zur Kommunikation mit bezüglich der zu steuernden Regelstrecke verbundenen Sensoren dar. Entsprechend der Möglichkeit der Verwendung von intelligenten Aktoren und/oder intelligenten Sensoren können die entsprechenden Hardwarebaugruppen 104 bzw. 105 sowohl unidirektional als auch bidirektional ausgeführt sein. Des Weiteren ist in 1 ein Testsystem 101 dargestellt, welches zum Testen der Software der Steuereinheit bzw. des Steuergeräts dient. Über eine Verbindung 102 und entsprechenden Schnittstellenbausteinen KSG für die Kommunikationsschnittstelle im Steuergerät und KTS für die Kommunikationsschnittstelle im Testsystem ist dieses Testsystem mit dem Steuergerät 100 verbunden. Dabei kann der entsprechende Schnittstellenbaustein KSG oder KTS entweder separat im Steuergerät bzw. Testsystem enthalten sein, oder auch in einem bestehenden Baustein, wie beispielsweise dem Controller, also die Verarbeitungseinheit 103 bzw. die Verarbeitungseinheit 108 des Testsystems 101 integriert sein. Die Kombination KSG, KTS und 102 wird im Weiteren nur als Kommunikationsschnittstelle bezeichnet. Wichtig ist somit erfindungsgemäß die Verwendung einer Kommunikations- bzw. Datenschnittstelle, z. B. der Applikationsschnittstelle. Bei den bisherigen Hardware-in-the-Loop-Testsystemen, entsprechend nachher dargestellt in 2, dient ein erheblicher Teil der kostspieligen Hardware dazu, die Ergebnisse der Fahrzeugsimulation in elektrische Signale umzusetzen, die dann dem Steuergerät an den Eingangspins zur Verfügung gestellt werden, indirektional angedeutet in 1 über Bauteil 104 und 105. Ein weiterer kostspieliger Teil dient der Simulation der Aktoren einschließlich der Signalauswertung. Beim neuen Testsystem gemäß 1 und 3 erfolgt der Informationsaustausch zwischen simulierendem Testsystem und dem Steuergerät bzw. der Steuereinheit nicht mehr über elektrische Signale in dem Sinne, sondern über eine reine Kommunikations- bzw. Datenschnittstelle, insbesondere die Applikationsschnittstelle. Hierzu sendet das Testsystem die Simulationsergebnisse über diese Schnittstelle an das Steuergerät. Im Steuergerät ist dann dafür zu sorgen, dass die zu testende Software nicht die Signale verwendet, die an den Sensoreingängen anliegen, sondern diejenigen Daten, die über die Schnittstelle, also die Kommunikationsschnittstelle, direkt vom Testsystem übertragen werden. Ebenso müssen die Werte bzw. Daten, die im Steuergerät zur Ansteuerung der Hardware an den Steuergeräteausgängen genutzt werden, über die genannte Schnittstelle, also die Kommunikationsschnittstelle an das Testsystem übertragen werden. Diese Übertragungen sollen in beiden Richtungen in Echtzeit erfolgen, um auf diese Art Regelkreise schließen zu können. Damit ist, wie nachfolgend noch detailliert beschrieben wird, die Möglichkeit gegeben, dieses Konzept für die komplette Steuergerätesoftware einschließlich Aktordiagnose einzusetzen. Da das Steuergerät permanent das elektrische Verhalten der Aktoren überprüft, war in bisherigen Testsystemen immer die Verwendung von Originallasten bzw. Ersatzlasten bezüglich der Hardware und Sensorik erforderlich. Im neuen Testsystemansatz werden diese Diagnoseinformationen ebenfalls über die oben genannte Kommunikationsschnittstelle vom Testsystem zum Steuergerät übertragen. Somit sind zukünftig vorteilhafter Weise im Testsystem keine Aktoren mehr erforderlich.
Ein herkömmliches Hardware-in-the-Loop-Testsystem ist in 2 dargestellt. Darin ist der Controller, der die Steuergerätesoftware ausführt, mit 203 dargestellt, das Testsystem bzw. der Simulationsrechner zur Simulation des Fahrzeugs, des Fahrers und der Umwelt im Block 206. Des Weiteren ist über eine Schnittstelle 210 mit dem Simulationsrechner ein Block 207 verbunden, der beispielsweise einen PC zur Steuerung des Tests und Darstellung der Testergebnisse darlegt. Im genannten Stand der Technik werden nun über eine erste Schnittstelle erste Signale SS zu einem Block 209 einer Hardware zur Simulation der Sensoren übertragen. Ebenso erfolgt die Fehlersimulation und die Übertragung der Fehler über Verbindung F zu einer Hardware 208 zur Simulation der Aktoren. Messergebnisse der Hardware 208 werden über M zum Simulationsrechner 206 zurückübertragen. Die Steuereinheit oder der Controller 203 empfängt von der Hardware zur Auswertung der Sensorsignale 205 die Signale S. Ebenso empfängt der Controller oder die Steuereinheit 203 von der Hardware zur Ansteuerung der Aktoren und Diagnose von Aktorfehlern 204 die Diagnoseergebnisse über D und übermittelt die Aktoransteuerung über A. Zur Erzielung geschlossener Regelkreise erfolgt dann eine elektrische Verbindung optional mit Trennadapter bezüglich der Aktoren über die Verbindung AE und bezüglich der Sensoren über die Verbindung SE.
Die erfindungsgemäße neue Methode ist in 3 nochmals schematisch dargestellt. Darin sind die Verarbeitungseinheit oder der Controller, der die Steuergerätesoftware, insbesondere auch Reglerfunktionen und Diagnosefunktionen ausführt, mit 103 bezeichnet. Die Hardware zur Auswertung der Sensorsignale ist wiederum mit Block 105 bezeichnet, und die Hardware zur Ansteuerung der Aktoren und Diagnose von Aktorfehlern mit Block 104. Hier dargestellt sind die Blöcke 103, 104 und 105 Teil des Steuergerätes 100. Diagnoseergebnisse, die Block 104 betreffen und dort erstellt werden können, werden im genannten Stand der Technik, hier dargestellt über D5, dem Controller 103 übermittelt. Ebenso werden Signale aus der Hardware zur Auswertung der Sensorsignale 105, soweit diese dort generiert werden, im Stand der Technik über Verbindung S6 dem Controller 103 übermittelt. Zur Herstellung geschlossener Regelkreise mit dem Simulationsrechner zur Simulation des Fahrzeugs, des Fahrers und der Umwelt in Block 300 wird nun allerdings die Aktoransteuerung, also die Ausgangssignale SWA nicht nur der Hardware 104 zugeleitet, sondern auch dem Simulationsrechner 300. Aktorfehlervorgaben, die vorher durch die Hardware 208 generiert wurden, werden nun durch den Simulationsrechner als Steuerwert 3 SW3 dem Controller 103 zugeführt. Hierzu ist die Software des Controllers 103 derart zu modifizieren, dass Sie als Aktordiagnose nicht die vom Block 104 zur Verfügung gestellten Daten nutzt, sondern die über die Kommunikationsschnittstelle 102 übermittelten Aktorfehlervorgaben SW3. Ebenso werden über eine weitere schematisch dargestellte Verbindung Simulationsergebnisse als zweite Steuerwerte SW2 und/oder Vorgaben von Sensorfehlern als vierte Steuerwerte SW4 vom Testsystem an den Controller 103 übermittelt. Hierzu ist die Software des Controllers 103 derart zu modifizieren, dass Sie als Eingangssignale nicht die vom Block 105 zur Verfügung gestellten Daten nutzt, sondern die über die Kommunikationsschnittstelle 102 übermittelten Steuerwerte SW2 und SW4. Der Austausch dieser Daten, also der ersten Steuerwerte SWA, der zweiten Steuerwerte SW2, der dritten Steuerwerte SW3 und der vierten Steuerwerte SW4 erfolgt nun in Echtzeit über die Kommunikationsschnittstelle, insbesondere die Applikationsschnittstelle. Weiterhin ist mit 301 ein Steuerungsrechner des Tests, insbesondere ein PC zur Steuerung des Tests und Darstellung der Testergebnisse dargestellt, welche über eine Verbindung 310 mit dem Simulationsrechner verkoppelt ist. Erfindungsgemäß ist es auch denkbar, die Blöcke 300 und 301 in einer Einheit baulich zusammenzufassen. Zur Erstellung der Simulationsergebnisse SW2 sind im Simulationsrechner Simulationsmittel enthalten. Diese können in Hardware, aber vornehmlich in Software in Form eines Simulationsprogramms vorgesehen werden. Ebenso sind Fehlervorgabemittel enthalten, um Aktorfehler und/oder Sensorfehler zu erzeugen bzw. vorzugeben, die zwar auch in Hardware, vornehmlich aber in Software dargestellt sind, beispielsweise in Form einer Tabelle mit diversen Fehlern und einer zufälligen oder gezielten Auswahl einzelner Fehler. Die Simulationsmittel im Simulationsrechner sind beispielsweise das entsprechende Modell zur Simulation des Fahrzeugs und/oder des Fahrers und/oder der Umwelt, wodurch die jeweiligen Einflüsse dieser Größen unter Berücksichtigung der Ausgangssignale bezüglich der Aktoransteuerung SWA dargestellt werden können.
In der besonderen Ausgestaltung wird die Gesamtsoftware des Steuergeräts/der Steuereinheit in die sogenannte Hardwarekapsel, also einen hardwareabhängigen Anteil und die eigentliche Systemsoftware als hardwareunabhängigen Anteil unterschieden. Hierdurch ergibt sich die Möglichkeit, an der Übergabe von Werten von der Hardwarekapsel an die Systemsoftware diese Werte zu manipulieren. Hierdurch müssen diese Werte nicht mehr von einer aufwendigen Simulationshardware über die Steuergerätepins dem Steuergerät zur Verfügung gestellt werden, sondern können prinzipiell auch von anderen Quellen übernommen werden. Hierzu bietet sich in der Steuergerätesoftwareentwicklung eine Kommunikationsschnittstelle, insbesondere die sogenannte Applikationsschnittstelle an. Im bekannten Hardware-in-the-Loop-Testsystem war dies bisher so nicht möglich, da die Applikationsschnittstelle nicht leistungsfähig genug war, um sämtliche Werte in Echtzeit mit der Systemsoftware austauschen zu können. Außerdem wären bisher in der Steuergerätesoftware hierfür umfangreiche Änderungen erforderlich gewesen, die erhebliche Ressourcen gebunden hätten. Zum Einen war dies in den gängigen Systemen, also dem bisherigen Stand der Technik nicht tolerierbar, und zum Anderen wäre dann der Test nicht mit der Originalseriensoftware erfolgt, was zu Nachteilen bezüglich der Aussagekraft geführt hätte.
Im neuen Testsystem ist die Applikationsschnittstelle leistungsfähig genug, um sämtliche Werte schnell genug vom Steuergerät an das Simulationssystem und von diesem wieder zum Steuergerät zu übertragen. Dies geschieht mit einem echtzeitfähigen Übertragungsprotokoll. Zusätzlich bietet der Controller, hier 103, im Gegensatz zum Stand der Technik die Möglichkeit, ohne zusätzlichen Ressourcenverbrauch Werte, die normalerweise von Softwaremodulen berechnet werden, direkt von der Applikationsschnittstelle oder Kommunikationsschnittstelle zu übernehmen. Damit, und mit den erfindungsgemäßen Ausgestaltungen, ergibt sich die Möglichkeit, ein preiswertes Test- und Simulationssystem zur Verfügung zu stellen, welches für die Simulation nur einen erfindungsgemäßen Hochleistungsrechner mit Applikationsschnittstelle und entsprechender Software benötigt. Da auch die Diagnoseinformationen, die die Steuergeräteausgänge normalerweise der steuergeräteinternen Überwachungsfunktion zur Verfügung stellen, über die Applikationsschnittstelle manipuliert werden können, werden auch keine Aktoren bzw. Aktornachbildungen mehr benötigt. Dies stellt eine erhebliche Vereinfachung des Testsystems dar. Damit muss auch aus den genannten Gründen die Testsystemhardware einschließlich eines Kabelbaums nicht mehr an das jeweilige Projekt angepasst werden, und die Anpassung des Testsystems erfolgt in reiner Software. Dies stellt auch beim Betrieb eine erhebliche Vereinfachung und Kostenreduktion dar. Die einzige Einschränkung des erfindungsgemäßen Testsytems ist, dass es nur für den Softwaretest genutzt werden kann und somit für den Hardwaretest und den Test des Komplettsystems aus Hard- und Software weiterhin andere Testsysteme nötig sind. Da aber der überwiegende Teil der durchgeführten Tests reine Softwaretests sind, bedeutet das neue Testsystem insgesamt ein erhebliches Einsparpotential.

Claims

Verfahren zum Testen von Software einer Steuereinheit eines Fahrzeugs, wobei durch ein Testsystem eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert wird, wobei Ausgangssignale von der Steuereinheit erzeugt werden und diese Ausgangssignale der Steuereinheit zu ersten Hardware-Bausteinen über eine erste Verbindung übertragen werden und Signale von zweiten Hardware-Bausteinen als Eingangssignale zur Steuereinheit über eine zweite Verbindung übertragen werden, dadurch gekennzeichnet, dass die Ausgangssignale als erste Steuerwerte in der Software bereitgestellt werden und zusätzlich über eine Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zum Testsystem übertragen werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Testsystem abhängig von den ersten Steuerwerten Simulationsergebnisse erzeugt und diese als zweite Steuerwerte über die Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zur Steuereinheit überträgt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Testsystem Fehlervorgaben erzeugt und diese über die Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zur Steuereinheit überträgt.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass als Fehlervorgaben dritte Steuerwerte als Aktorfehler der Regelstrecke durch das Testsystem vorgegeben und über die Kommunikationsschnittstelle zur Steuereinheit übertragen werden.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass als Fehlervorgaben vierte Steuerwerte als Sensorfehler der Regelstrecke durch das Testsystem vorgegeben und über die Kommunikationsschnittstelle zur Steuereinheit übertragen werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Software in einen hardwareabhängigen Anteil und einen hardwareunabhängigen Anteil bezogen auf eine Hardware der Steuereinheit aufgeteilt ist, wobei die Ausgangssignale als physikalische Größen repräsentierende erste Steuerwerte im hardwareunabhängigen Anteil der Software bereitgestellt werden.
Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs, mit einem Testsystem, welches eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert und der Steuereinheit, welche Ausgangssignale erzeugt und diese Ausgangssignale zu ersten Hardware-Bausteinen über eine erste Verbindung überträgt, mit zweiten Hardware-Bausteinen, welche Signale als Eingangssignale zur Steuereinheit über eine zweite Verbindung übertragen, dadurch gekennzeichnet, dass Mittel enthalten sind, die die Ausgangssignale als erste Steuerwerte in der Software bereitstellen und zusätzlich eine Kommunikationsschnittstelle vorgesehen ist, über welche die Ausgangssignale zusätzlich und in Echtzeit bezogen auf die Regelstrecke zum Testsystem übertragen werden.
Vorrichtung nach Anspruch 7, dadurch gekennzeichnet, dass die Kommunikationsschnittstelle der Applikationsschnittstelle des Steuergerätes entspricht.
Vorrichtung nach Anspruch 7, dadurch gekennzeichnet, dass das Testsystem Simulationsmittel enthält, die derart ausgebildet sind, dass diese abhängig von den ersten Steuerwerten Simulationsergebnisse erzeugen und die Kommunikationsschnittstelle diese als zweite Steuerwerte in Echtzeit bezogen auf die Regelstrecke zur Steuereinheit überträgt.
Vorrichtung nach Anspruch 7, dadurch gekennzeichnet, dass das Testsysteme Fehlervorgabemittel enthält, die Fehlervorgaben von Aktoren und/oder Sensoren der Regelstrecke erzeugen und die Kommunikationsschuittstelle diese in Echtzeit bezogen auf die Regelstrecke zur Steuereinheit überträgt.