DE102015207656A1

DE102015207656A1 - Verfahren und System zum Testen von Steuersoftware eines gesteuerten Systems

Info

Publication number: DE102015207656A1
Application number: DE102015207656.3A
Authority: DE
Inventors: Tasuku Ishigooka; c/o Hitachi Research Labor. Narisawa Fumio; c/o Techn. Universität Suri Neeraj; c/o Techn. Universität Winter Stefan; c/o Techn. Universität Piper Thorsten; c/o Techn. Universität Saissi Habib
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2014-04-29
Filing date: 2015-04-27
Publication date: 2015-11-12
Anticipated expiration: 2035-04-28
Also published as: DE102015207656B4; EP2940586B1; US20150309920A1; JP2015210814A; JP6320328B2; US9575877B2; EP2940586A1

Abstract

Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System zum Testen einer Steuersoftware eines gesteuerten Systems, wobei das gesteuerte System eine oder mehrere elektronische Steuereinheiten, einen oder mehrere Aktuatoren und einen oder mehrere Sensoren umfasst, wobei jeder Sensor dazu ausgelegt ist, ein jeweiliges Sensorsignal in mindestens eine der einen oder der mehreren elektronischen Steuereinheiten einzugeben, und jeder Aktuator dazu ausgelegt ist, in Reaktion auf jeweilige Steuersignale zu handeln, die von mindestens einer der elektronischen Steuereinheiten eingegeben werden, und jede elektronische Steuereinheit dazu konfiguriert ist, ein jeweiliges ausführbares Steuerprogramm auf der Basis von Steuersoftware-Codedaten auszuführen, um ein oder mehrere Steuersignale an den einen oder die mehreren Aktuatoren auf der Basis der eingegebenen Sensorsignale auszugeben. Der Steuertestprozess kann das Bereitstellen von Steuersoftware-Codedaten, das Bereitstellen von Anlagencodedaten, das Erzeugen eines Systemmodells und das Durchführen eines Software-Überprüfungsprozesses auf der Basis eines ausführbaren Programms des Systemmodells umfassen.

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System zum Testen von Steuersoftware eines gesteuerten Systems, wobei das gesteuerte System eine oder mehrere elektronische Steuereinheiten, einen oder mehrere Aktuatoren und einen oder mehrere Sensoren umfassen kann und jeder Sensor dazu ausgelegt ist, ein jeweiliges Sensorsignal in mindestens eine der einen oder der mehreren elektronischen Steuereinheiten einzugeben, und jeder Aktuator dazu ausgelegt ist, in Reaktion auf jeweilige Steuersignale zu handeln, die von mindestens einer der elektronischen Steuereinheiten eingegeben werden, und jede elektronische Steuereinheit dazu konfiguriert ist, ein jeweiliges ausführbares Steuerprogramm auf der Basis von Steuersoftware-Codedaten auszuführen, um ein oder mehrere Steuersignale an die einen oder die mehreren Aktuatoren auf der Basis von eingegebenen Sensorsignalen auszugeben.
HINTERGRUND
In gesteuerten Systemen/Anlagen, wie z. B. Kraftfahrzeug-Steuersystemen oder eingebetteten Systemen, sind häufig eine oder mehrere elektronische Steuereinheiten (ECU) zum Steuern von Aktuatoren des gesteuerten Systems/der gesteuerten Anlage gemäß der Ausgabe von Steuerbefehlen vorgesehen. Die Befehle werden durch die jeweilige elektronische Steuereinheit auf der Basis einer Steuerlogik, die durch Steuersoftware-Codedaten gegeben wird, und von aktuellen Sensorwerten, die in Kraftfahrzeugsystemen das Verhalten des Kraftfahrzeugs und/oder die Handlungen des Fahrers erkennen und/oder angeben können, berechnet. Einige Aktuatoren können beispielsweise durch elektronische Signale oder durch einen Hydraulikdruck auf der Basis der ECU-Softwaresteuerungen gesteuert werden.
Aufgrund der zunehmenden Verantwortungen und Funktionalität der ECUs und der zunehmenden Komplexität der gesteuerten Systeme mit mehreren elektronischen Steuereinheiten und sogar mehreren elektronischen Steuereinheiten, die sich die Steuerung über gemeinsam genutzte Aktuatoren teilen, nehmen jedoch die Anforderungen an die Funktionalität kontinuierlich zu. Häufig ist es eine weitere Schwierigkeit, dass ECUs individuell für eine spezifische technische Funktion entwickelt wurden und dann eine neue oder andere technische Funktion im Hinblick auf die Zusammenarbeit mit anderen ECUs dort hinzugefügt wird. Kurz gesagt ist folglich ein Hauptproblem für die Entwicklung der Zusammenarbeitssteuerung das Erfüllen der höchsten Sicherheitsstandards.
Heutzutage herrschen für die Entwicklung Verfahren auf Modellbasis vor. Solche Verfahren modellieren ”virtuelle Anlagen”, die das Verhalten eines realen Steuerziels, einer sogenannten ”Anlage”, simulieren. Die Steuerlogik des Systems wird modelliert, um die Anlagen auf der Basis der Steuertheorie und der Eigenschaft des Anlagenmodells zu steuern. Die Entwicklung auf Modellbasis ermöglicht die Simulation des Systemverhaltens ohne Verwendung der realen Steuersysteme.
Die Entwicklung auf Modellbasis erfordert genaue Anlagenmodelle, um das Prüfen der Funktionalität des Systems zu ermöglichen. Für einen genauen Anlagenmodellentwurf wird am häufigsten die Bondgraphen-Modellierungsmethode verwendet. Die Bondgraphenmodellierung ermöglicht, dass Benutzer ein Anlagenmodell durch Kombinieren von Objekten (oder Objektblöcken), die physikalische Elemente des realen gesteuerten Systems darstellen, wie z. B. eine Feder, eine Masse, einen Kolben usw., entwerfen. Folglich kann der Benutzer mechanisch-hydraulische Anlagenmodelle auf der Basis von Bewegungsgleichungen, die durch gewöhnliche Differentialgleichungen (ODE) implementiert werden, unter dem Gesetz der Energieerhaltung, was eine algebraische Schleife verursachen kann, und Einschränkungsgleichungen, die durch Ungleichungs- oder algebraische Differentialgleichungen (DAE) implementiert werden, entwerfen. Die Antwort oder Lösung der Formel, die eine algebraische Schleife oder DAE beinhaltet, wird durch DAE-Löser berechnet, die einen Näherungswert durch Konvergenzberechnung finden.
(Ein) DAE-Löser(n) erlegt (erlegen) jedoch insbesondere dem Computer, der die Überprüfungsprozedur durchführt, eine hohe Rechenlast auf. Daher wäre es technisch vorteilhaft, wenn die üblicherweise verwendeten Bondgraphenmodelle durch weniger komplexe und weniger rechenaufwendige Modellierungsmethoden/Modelle ersetzt werden könnten.
Ein weiterer Nachteil der heutigen Methode besteht ferner darin, dass, da die Zusammenarbeitssteuersoftware komplex und anspruchsvoll ist, es sehr schwierig und mühsam ist, alle Situationen und Zustände des Systems mit der Steuerung zu testen, um zu prüfen, ob die Implementierung der Steuerlogik korrekt ist oder nicht. Beispielsweise bestehen schwierig zu findende Defekte oder Funktionsstörungen, die nur in Kombination mit einem spezifischen Zeitablauf einer spezifischen Betriebsbedingung (wie z. B. einer Fahreroperation) und/oder eines spezifischen Systemverhaltens erscheinen können. Die Qualität der herkömmlichen Testtechnologie, wie z. B. Software- oder Hardware-in-the-Loop-Simulation (NILS), hängt folglich von der Qualität des Testfalls (der Testfälle) ab.
JP 2009-014406 A beschreibt z. B. einen Softwaretestprozess auf der Basis einer Hardware-in-the-Loop-Methode (HIL-Methode), bei der ein Anlagensimulator an einer elektronischen Steuereinheit zum Testen der Software der elektronischen Steuereinheit angebracht wird. Die Eingangsmodelle basieren auf Bondgraphen und der (die) zugehörige(n) DAE-Löser erlegen die beschriebene hohe Rechenlast dem Überprüfungssystem auf. Wie vorstehend erwähnt, ist es in HIL-Methoden ferner schwierig, komplexe Systeme wie z. B. Systeme mit mehr als einer elektronischen Steuereinheit zu testen, und Systemdefekte, die aufgrund der Zusammenarbeit von mehreren elektronischen Steuereinheiten auftreten, können z. B. übersehen werden.
Mit anderen Worten, derzeit bekannte Methoden weisen die beschriebenen Nachteile insbesondere im Hinblick auf die Detektion einer schwer zu findenden Funktionsstörung/von schwer zu findenden Defekten für die Überprüfung und das Testen einer Steuersoftware und im Hinblick auf die Rechenlast, die durch zugrundeliegende Anlagenmodelle verursacht wird, auf.
Es besteht ein Bedarf, an einer rechnerisch weniger anspruchsvollen, effizienteren und zuverlässigen Teststeuersoftware von elektronischen Steuereinheiten eines gesteuerten Systems/einer gesteuerten Anlage insbesondere während der Entwicklung, die frei von Systemdefekten sind, und insbesondere um strengste Sicherheitsanforderungen zu erfüllen. Daher sind neue Methoden sehr erwünscht, die die vorstehend erörterten Probleme und Nachteile von gegenwärtigen Methoden beseitigen können.
Angesichts des Obigen ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zum Testen einer Steuersoftware eines gesteuerten Systems zu schaffen, die zuverlässig und effizient ermöglicht, Systemdefekte im gesteuerten System zu finden, einschließlich Systemdefekten, die nur in spezifischen Situationen aufgrund der Zusammenarbeit von mehreren elektronischen Steuereinheiten und des Anlagenverhaltens auftreten. Ferner kann es erwünscht sein, den Rechenaufwand zu verringern, der durch das Überprüfungsverfahren und Überprüfungssystem verursacht wird.
ZUSAMMENFASSUNG
Zum Lösen der obigen Aufgabe werden gemäß Ausführungsformen der vorliegenden Erfindung ein Verfahren zum Testen einer Steuersoftware eines gesteuerten Systems nach Anspruch 1, ein System zum Testen einer Steuersoftware eines gesteuerten Systems nach Anspruch 12 und ein Computerprogrammprodukt nach Anspruch 15 vorgeschlagen. Die abhängigen Ansprüche beschreiben bevorzugte Weiterentwicklungen und Aspekte.
Gemäß einem Aspekt kann ein Verfahren zum Testen einer Steuersoftware eines gesteuerten Systems geschaffen werden, wobei das gesteuerte System eine oder mehrere elektronische Steuereinheiten, einen oder mehrere Aktuatoren und einen oder mehrere Sensoren umfasst, wobei jeder Sensor dazu ausgelegt ist, ein jeweiliges Sensorsignal in mindestens eine der einen oder mehreren elektronischen Steuereinheiten einzugeben, und jeder Aktuator dazu ausgelegt ist, in Reaktion auf jeweilige Steuersignale zu handeln, die von mindestens einer der elektronischen Steuereinheiten eingegeben werden, und jede elektronische Steuereinheit dazu konfiguriert ist, ein jeweiliges ausführbares Steuerprogramm auf der Basis von Steuersoftware-Codedaten auszuführen, um ein oder mehrere Steuersignale an den einen oder die mehreren Aktuatoren auf der Basis von eingegebenen Sensorsignalen auszugeben.
Das Verfahren kann umfassen: Bereitstellen von Steuersoftware-Codedaten für jede der einen oder der mehrere elektronischen Steuereinheiten, Bereitstellen von Anlagencodedaten für das gesteuerte System, Erzeugen eines Systemmodells auf der Basis der bereitgestellten Steuersoftware-Codedaten, die für jede der einen oder der mehreren elektronischen Steuereinheiten bereitgestellt werden, und der bereitgestellten Anlagencodedaten, Erzeugen eines ausführbaren Programms auf der Basis des erzeugten Systemmodells und/oder Durchführen eines Softwareüberprüfungsprozesses auf der Basis des ausführbaren Programms.
Die bereitgestellten Steuersoftware-Codedaten können einen Steuersoftware-Quellencode (oder ein Steuerprogramm) für das gesteuerte System umfassen; insbesondere können sie den Steuersoftware-Quellencode der einen oder der mehreren elektronischen Steuereinheiten umfassen.
Die Bereitstellung der Anlagencodedaten (oder Simulationscodedaten) gemäß einem bevorzugten Aspekt wird in einer automatisierten Weise ausgeführt. Mit anderen Worten, das hier beschriebene Überprüfungssystem kann dazu konfiguriert sein, automatisch Anlagencodedaten zu erzeugen und bereitzustellen; ferner können die bereitgestellten Anlagencodedaten vorzugsweise automatisch in einer vorbestimmten Darstellung bereitgestellt werden, die vorzugsweise eine Darstellung auf Signalflussbasis sein kann. Ein anderer Begriff für Anlagencodedaten kann Anlagenquellencodedaten sein. Die Anlagencodedaten sind gemäß einem bevorzugten Aspekt ein Signalfluss-Anlagenmodell der zu simulierenden Anlage/des gesteuerten Systems.
Das Erzeugen eines Systemmodells auf der Basis der bereitgestellten Steuersoftware-Codedaten, die für jede der einen oder mehreren elektronischen Steuereinheiten bereitgestellt werden, und der bereitgestellten Anlagencodedaten kann bedeuten, dass eine zweckgebundene Einheit die eingegebenen Informationen und Daten zusammensetzen kann, um ein Modell des zu überprüfenden Systems zu erzeugen, das Informationen über das Verhalten des gesteuerten Systems, zu überprüfende Parameter, den zu prüfenden Quellencode usw. enthalten kann. Das Erzeugen eines ausführbaren Programms auf der Basis des erzeugten Systemmodells kann einen Schritt zum Kompilieren des Systemmodells durch einen Kompilierer umfassen, der ein Teil der Einheit sein kann, die das Systemmodell erzeugt.
Folglich kann ein Softwaretest-Überprüfungsprozess auf der Basis eines ausführbaren Programms durchgeführt werden, das auf der Basis eines Systemmodells aufgebaut wird, das Steuersoftware-Codedaten für jede der beteiligten elektronischen Steuereinheiten des gesteuerten Systems sowie Anlagencodedaten umfasst, die erzeugt werden, um das Anlagenverhalten numerisch zu simulieren, so dass der Überprüfungsprozess sich nicht nur auf das Steuerverhalten einer elektronischen Steuereinheit auf einmal konzentriert, sondern auch Effekte berücksichtigt, die aufgrund einer Zusammenarbeit von mehreren elektronischen Steuereinheiten und des Verhaltens des gesteuerten Systems/der gesteuerten Anlage auftreten können.
Als technischer Vorteil davon ist es möglich, zugehörige Systemdefekte, einschließlich Systemdefekten, die nur in spezifischen Situationen aufgrund der Zusammenarbeit von elektronischen Steuereinheiten und des Anlagenverhaltens auftreten, effizient und zuverlässig zu finden, die bei üblichen Steuersoftware-Überprüfungstechniken übersehen werden könnten.
Das Überprüfungsverfahren/der Überprüfungsprozess kann, indem er besonders vorteilhaft ist, Defekte oder Funktionsstörungen ohne Verwendung von Testfällen detektieren. Die Überprüfung kann beispielsweise vorzugsweise auf einer Überprüfung einer symbolischen Ausführung basieren oder diese verwenden. Der Benutzer kann einen Zielwert, dessen Effekt der Benutzer überwachen will, als Symbol definieren. Das Verfahren kann dann den Programmquellencode analysieren, alle erreichbaren Steuerpfade durch Konzentrieren auf Verzweigungsbefehle gewinnen, eine Einschränkungsformel auf der Basis von Symbolen (z. B. X > 0) für jeden Pfad formulieren und einen konstanten Wert für das Symbol berechnen, der die Einschränkungsformel erfüllt (z. B. X = 1). Wenn der Benutzer die Variablen der Programmeingabe als Symbol(e) definiert, können diese Wertesätze für Testfälle verwendet werden.
Gemäß einem weiteren bevorzugten Aspekt kann das (automatisierte) Bereitstellen von Anlagencodedaten (die Schritte) umfassen: Eingeben eines Bondgraphen-Anlagenmodells des gesteuerten Systems, Erzeugen eines vereinfachten Bondgraphen-Anlagenmodells durch Vereinfachen des eingegebenen Bondgraphen-Anlagenmodells, Erzeugen eines Signalfluss-Anlagenmodells durch Transformieren des vereinfachten Bondgraphen-Anlagenmodells und/oder Erzeugen der Anlagencodedaten durch Transformieren des Signalfluss-Anlagenmodells in einen Quellencode.
Das Bondgraphen-Anlagenmodell oder die Bondgraphen-Anlagenmodelldaten des gesteuerten Systems können durch einen Benutzer bereitgestellt oder eingegeben werden, der das Modell erzeugt hat. Das Bondgraphen-Anlagenmodell kann jedoch auch durch einen anderen Computer oder eine Speichervorrichtung eingegeben werden, die mit dem Überprüfungssystem verbunden ist, so dass die Eingabe auch in einer automatisierten Weise ausgeführt werden kann. Das Bondgraphen-Anlagenmodell oder die Bondgraphen-Anlagenmodelldaten können vorzugsweise in einem Datenformat einer jeweiligen Modellierungssoftware bereitgestellt werden. Das Bondgraphen-Anlagenmodell kann graphische Objekte; eine Kombination von Bewegungsgleichungen, die durch gewöhnliche Differentialgleichungen (ODE) implementiert werden, und Einschränkungsgleichungen, die durch Ungleichungs- oder algebraische Differentialgleichungen (DAE) implementiert werden; und/oder dergleichen umfassen. Das Bondgraphen-Anlagenmodell kann insbesondere ein oder mehrere Objekte umfassen, die auch ”Komponente” oder ”Ziel” genannt werden können, die reale Elemente des realen gesteuerten Systems wie z. B. eine Feder oder dergleichen darstellen.
Das Bondgraphen-Anlagenmodell kann verwendet werden, um ein vereinfachtes Bondgraphen-Anlagenmodell oder jeweilige vereinfachte Bondgraphen-Anlagenmodelldaten zu erzeugen. Das vereinfachte Bondgraphen-Anlagenmodell weist bevorzugter dasselbe Datenformat wie das Bondgraphen-Anlagenmodell auf. Das Überprüfungssystem kann eine Modellvereinfachungseinheit umfassen, die dazu konfiguriert ist, das eingegebene Bondgraphen-Anlagenmodell zu vereinfachen. Die Modellvereinfachungseinheit kann vorzugsweise eine Softwarekomponente sein, die im Speicher des Systems gespeichert werden kann und die von deren CPU(s) ausgeführt werden kann. Eine Ersatztabelle, eine Anschlussumsetzungstabelle, eine Bondgraphen-Objektbibliothek und/oder ein Simulationsergebnis (Bibliothek) können erforderliche Informationen für die Modellvereinfachungseinheit für den Vereinfachungsprozess/Vereinfachungsschritt liefern.
Es wird angemerkt, dass der Vereinfachungsschritt ausgelassen oder übersprungen werden kann. Ein Benutzer oder das Überprüfungssystem kann beispielsweise entscheiden, dass das Bondgraphen-Anlagenmodell bereits für die Weiterverarbeitung selbst ohne Vereinfachen desselben geeignet ist. Dies kann beispielhaft der Fall sein, wenn die Komplexität des eingegebenen Bondgraphen-Anlagenmodells bereits relativ gering ist, wenn die Objekte des eingegebenen Bondgraphen-Anlagenmodells bereits vereinfacht sind und/oder wenn es einfach nicht erwünscht ist, ein vereinfachtes Modell zu verarbeiten.
Das Erzeugen eines Signalfluss-Anlagenmodells kann durch Transformieren des (vereinfachten) Bondgraphen-Anlagenmodells ausgeführt werden. Insbesondere sollten daher Objekte der Bondgraphendarstellung durch Komponenten einer Signalflussdarstellung ersetzt werden. Während der Transformation sollte die Verknüpfung/Verbindung der Komponenten ebenso wie das Definieren, welche Signale übertragen werden sollen, ausgeführt werden. Die Transformation kann vorzugsweise durch eine Modelltransformationseinheit durchgeführt werden, die als Computerprogramm im Speicher des Überprüfungssystems gespeichert werden kann. Als Eingabe kann die Modelltransformationseinheit das (vereinfachte) Bondgraphen-Anlagenmodell und Informationen von einem Verzeichnis physikalischer Werte und/oder einer Signalflussgraphen-Objektbibliothek, die z. B. auch im Speicher gespeichert wird, empfangen. Das Signalfluss-Anlagenmodell kann vorzugsweise in dem Datenformat einer jeweiligen Modellierungssoftware bereitgestellt werden; es kann eine Zusammenstellung von ODEs umfassen, die das gesteuerte System darstellen.
Anschließend verarbeitet ein Codegenerator, der z. B. ein allgemeines Codegeneratorwerkzeug sein kann, das dazu ausgelegt ist, das Modell auf Signalflussbasis in Quellencodedaten zu transformieren, auf der Basis des erzeugen Signalfluss-Anlagenmodells das Signalfluss-Anlagenmodell, so dass die Anlagencodedaten erzeugt werden. Mit anderen Worten, der Codegenerator, der im Speicher gespeichert sein kann, kann das Signalfluss-Anlagenmodell in den Quellencode transformieren. DAE-Löser sind vorzugsweise nicht in den erzeugten Anlagencodedaten (Anlagenmodell) enthalten, was die Rechenlast während des Überprüfungsprozesses verringert.
Der vorstehend beschriebene bevorzugte Aspekt verbessert insbesondere das effiziente Auffinden von schwierig zu findenden Systemfunktionsstörungen oder Systemdefekten. Folglich wird dem Benutzer ermöglicht, die Sicherheit eines (mechanisch-elektronischen Steuer-)Systemmodells vorzugsweise durch Überprüfung der symbolischen Ausführung zu überprüfen. Das Systemmodell simuliert das ganze Verhalten des mechanisch-elektronischen Steuersystems durch Synchronisation von Daten und Zeit zwischen der ECU-Software (Steuersoftware-Codedaten) und der realen Anlage.
Das beschriebene Verfahren (und auch das nachstehend weiter beschriebene System) schafft eine leistungsstarke Technologie, die außerdem automatisch ein Bondgraphen-Anlagenmodell in ein Signalfluss-Graphenmodell transformieren kann. Überdies kann, es optional automatisch das Bondgraphen-Anlagenmodell vereinfachen – falls erforderlich – und es kann automatisch ein Systemmodell gemäß der ECU-Software, der transformierten Anlage, Informationen über die Systemstruktur, Sicherheitsanforderungen und Systemeingabe erzeugen. Besonders bevorzugt kann die Sicherheitsüberprüfung eines solchen automatisch erzeugten Systemmodells dann durch Überprüfung der symbolischen Ausführung ausgeführt werden.
Mit anderen Worten, neben der Verbesserung im Hinblick auf die Überprüfung/Defektdetektion selbst weist der vorstehend beschriebene Aspekt gleichzeitig und im Allgemeinen aufgrund der synergistischen Bereitstellung eines Systemmodellgenerators und eines automatisierten Anlagencodedaten-”Bauers” den technischen Hauptvorteil auf, dass die Rechenlast verringert werden kann, da das Anlagenvereinfachungswerkzeug/die Anlagenvereinfachungseinheit und das Modelltransformationswerkzeug/die Modelltransformationseinheit im Allgemeinen (einen) DAE-Löser entfernen können, die in Bondgraphen-Anlagenmodellen verwendet werden und die eine hohe Rechenlast erzeugen.
Wiederum wird hier mit anderen Worten ein Verfahren (ein System und ein Computerprogrammprodukt) beschrieben, das es möglich macht, auf der Basis des eingegebenen Bondgraphen-Anlagenmodells und der eingegebenen Steuersoftware-Codedaten, dass das Überprüfungstesten in einer stark automatisierten Weise durchgeführt werden kann und dass sogar schwierig zu findende Defekte detektiert werden können. Die automatische Erzeugung des Systemmodells verringert mühselige manuelle Arbeit des Benutzers auf ein Minimum, verringert die Rechenarbeitslast ebenso wie es die automatische Erzeugung von Anlagencodedaten auf Signalflussbasis ermöglicht. Gemäß dem hier beschriebenen Verfahren muss der Benutzer weder sich Sorgen machen über noch die Details der Modelltransformation und/oder der Modellvereinfachung kennen, wenn er ein Steuermodell überprüfen will, da die Modelltransformation und/oder Modellvereinfachung, wie vorstehend beschrieben, in einer automatisierten Weise ausgeführt werden.
Mit noch anderen Worten können Systemfunktionsstörungen detektiert werden, da ein ganzes System überprüft wird, das aus einer Steuersoftware und der (realen) Anlage besteht, aufgrund der Berechnung. Die Lastverringerung durch die Anlagenvereinfachung und Modelltransformation, die die DAE-Löser-Verwendung entfernen kann, ermöglicht im Allgemeinen die Überprüfung von vollständigen, wenn sogar großen, Systemen. Im Vergleich dazu hat die vorher verwendete HILS keinen Zeitsynchronisationsmechanismus zwischen der Steuersoftware und dem Anlagenmodell. HIlS kann Systemfunktionsstörungen übersehen/nicht detektieren können, im Allgemeinen da es schwierig ist, alle möglichen Testfälle wie z. B. spezifische Testfälle zu betrachten und durchzuführen, um spezifische Werte in Software in einem spezifischen Anlagenzustand einzugeben. Ferner verwenden die vorher verwendeten Methoden, wie z. B. durch JP 2009-14406 A beschrieben, nur eine Bondgraphen-Software und jeweilige Modelle mit DAE und ODE, die einfach in ein Programmcodeprogramm transformiert werden (einschließlich DAE-Löser mit einer festen Anzahl von Konvergenzberechnungszeiten). (Ein) DAE-Löser und dergleichen erlegen jedoch dem Überprüfungssystem eine hohe Rechenlast auf. Das hier beschriebene Verfahren und System können dagegen und vorteilhafterweise (einen) DAE-Löser durch die automatisierten Vereinfachungs- und Transformationsschritte des eingegebenen Bondgraphen-Anlagenmodells entfernen.
Ein weiterer bevorzugter Aspekt des Verfahrens hinsichtlich der Erzeugung des vereinfachten Bondgraphen-Anlagenmodells kann die Schritte umfassen: Durchsuchen des Bondgraphen-Anlagenmodells nach mindestens einem zu vereinfachenden Objekt, Entfernen des mindestens einen gesuchten Objekts, Hinzufügen mindestens eines vereinfachten Objekts und Verknüpfen der Objekte.
Das Durchsuchen des Bondgraphen-Anlagenmodells kann das Ziel haben, mindestens ein zu vereinfachendes Objekt (Komponente oder Ziel) zu identifizieren. Dieses oder diese Objekte können dann entfernt oder durch ein oder mehrere entsprechende vereinfachte Objekte ersetzt werden. Daher kann das Hinzufügen von mindestens einem vereinfachten Objekt auch als Austauschen von Objekt(en) betrachtet werden. Ferner sollten die Objekte, die auch ein Gemisch von vereinfachten Objekten und nicht vereinfachten Objekten umfassen können, erneut miteinander verbunden werden; insbesondere kann die Verbindung oder Verknüpfung so ausgeführt werden, dass die Verbindungen der entfernten/ersetzten Objekte (im Wesentlichen) in der neuen Struktur wiedergegeben werden mit den hinzugefügten vereinfachten Objekten und möglicherweise ”alten” nicht ersetzten Objekten.
Überdies kann der Aspekt das Kopieren von kompatiblen Konfigurationsparametern umfassen. Dies kann umfassen, dass die Konfigurationsparameter der ersetzten/entfernten Objekte für die vereinfachten Objekte ”wiederverwendet” werden, insbesondere wenn sie kompatibel sind. Ferner können die Konfigurationsparameter (die Konfiguration von Parametern) zum Nähern des Verhaltens einer zu modellierenden Anlage berechnet werden. Ein Beispiel für die kompatiblen Konfigurationsparameter kann z. B. das ”Gewicht” eines ”Masse”-Objekts sein. Zum Beispiel wenn die fortbewegte Masse durch die vereinfachte Masse ersetzt wird, sollte die vereinfachte ”Masse” dieselbe (physikalische) Eigenschaft im Hinblick auf das ”Gewicht” aufweisen. Diese Eigenschaft kann kompatible Konfigurationsparameter genannt werden. Wenn beispielsweise das Objekt ”fortbewegte Masse” durch das Objekt ”vereinfachte Masse” ersetzt wird und das Gewicht der ”fortbewegten Masse” 100 kg ist, sollte ferner das Gewicht der ”vereinfachten Masse” gleich sein. Dies bedeutet, dass das Gewicht der ”vereinfachten Masse” 100 kg ist. Die entsprechende Verbindung wird ”Konfigurationsparameter (Konfiguration von Parametern) für die Näherung des Anlagenverhaltens” genannt. Wenn das Gewicht der ”vereinfachten Masse” z. B. auf 0,001 kg gesetzt werden würde, wäre das Ergebnis des Anlagenverhaltens zu weit weg vom ursprünglichen Verhalten der nicht vereinfachten Anlage. Mit anderen Worten, die Verarbeitung kann realisieren, dass das (physikalische) Verhalten nach der Vereinfachung aufrechterhalten werden kann.
Die vorstehend beschriebenen bevorzugten Schritte der Vereinfachungsprozedur ermöglichen eine effiziente und automatisierte Erzeugung eines vereinfachten Bondgraphenmodells, auf dessen Basis ein Signalfluss-Anlagenmodell aufbaubar ist.
Ein weiterer bevorzugter Aspekt des Verfahrens hinsichtlich der Erzeugung des Signalfluss-Anlagenmodells kann die Schritte umfassen: Lesen von Informationen des mindestens einen Objekts des vereinfachten Bondgraphen-Anlagenmodells, Hinzufügen mindestens einer Signalflusskomponente von einer Bibliothek und Verknüpfen von Anschlüssen der mindestens einen hinzugefügten Signalflusskomponente.
Das Lesen von Informationen des mindestens einen (vereinfachten) Objekts des vereinfachten Bondgraphen-Anlagenmodells kann das Unterscheiden, um welche Art von Objekt es sich handelt, welche Konfiguration (z. B. angesichts der Anschlüsse, Verbindungen usw.) es hat, welche technische Funktion es erfüllt, usw. umfassen. Da beispielsweise eine Komponente mehrere Ports aufweisen kann, können die Komponenteninformationen Informationen wie z. B. ”Anschlussverbindungsbeziehungs-Informationen” und ”Anschlussdaten-Informationen” enthalten. Die Komponenteninformationen können im Bondgraphen-Anlagenmodell als Teil des Anlagenmodels enthalten sein. Das Hinzufügen von mindestens einer Signalflusskomponente aus einer Bibliothek kann auch als Ersetzen von Bondgraphenobjekten durch entsprechende Signalfluss-Graphenobjekte betrachtet werden; vorzugsweise kann dies auf der Basis der gelesenen Informationen ausgeführt werden. Die Anschlüsse der Komponenten können dann verbunden oder verknüpft werden, so dass der Signalfluss zwischen den Komponenten modelliert wird. Die Verknüpfung kann auf der Basis von Informationen getragen werden, die während des Transformationsschritts/Signalflussmodell-Erzeugungsschritts auch gelesen werden können. Die Informationen können Anschlussverbindungsbeziehungs-Informationen des vereinfachten Bondgraphen-Anlagenmodells, die gelesen werden können, sowie Anschlussdaten-Informationen des vereinfachten Bondgraphen-Anlagenmodells umfassen. Die Anschlussverbindungsbeziehungs- und Anschlussdaten-Informationen können die erforderlichen Informationen umfassen, die die Transformation der Verbindungen und Flüsse der Bondgraphen-Darstellung in eine entsprechende Signalflussdarstellung ermöglichen. Die Anschlussverbindungsbeziehung kann beispielsweise Informationen über Verbindungen der Anschlusskomponente mit anderen Komponenten umfassen. Die Anschlussdaten-Informationen können Informationen darüber enthalten, welche Art von Informationen über den Anschluss übertragbar sind, z. B. welcher physikalische Wert wie z. B. Kräfte oder Verlagerungen.
Die vorstehend beschriebenen bevorzugten Schritte der Transformationsprozedur ermöglichen eine effiziente und automatisierte Erzeugung eines Signalfluss-Anlagenmodells, das vorzugsweise keine(n) DAE-Löser umfasst/ersetzt, so dass die Rechenarbeitslast während der Ausführung der Überprüfung drastisch verringert werden kann.
Die Signalflussgraphen-Objektbibliothek sowie im Allgemeinen die Ersatztabelle und die vereinfachte Bondgraphen-Objektbibliothek können ferner vorteilhafterweise unterstützen, dass die Modelltransformation und/oder Modellvereinfachung in einer sehr automatisierten Weise ausgeführt werden können, da im Allgemeinen jeweilige vordefinierte Objekte der vereinfachten Darstellung auf Objektbasis bzw. Signalflussdarstellung in den Bibliotheken oder Tabellen im Voraus gespeichert werden können, so dass die Transformationseinheit automatisch diese vordefinierten Objekte einfügen kann, wenn das vereinfachte Graphenmodell auf Objektbasis und/oder Signalfluss-Graphenmodell erzeugt wird.
Gemäß einem bevorzugten Aspekt kann ferner das Durchführen des Softwareüberprüfungsprozesses auf der Basis des ausführbaren Programms das Durchführen einer symbolischen Ausführung auf der Basis des Systemmodells umfassen. Vorzugsweise kann das Erzeugen des ausführbaren Programms auf der Basis des erzeugten Systemmodells das Übertragen von einem oder mehreren Parametern des Systemmodells in Symbole für die symbolische Ausführung umfassen. Dies hat den Vorteil, dass eine Vielfalt von verschiedenen Situationen effizient und zuverlässig auf der Basis von abstrakten Pfadbedingungen für symbolische Variablen im Gegensatz zu tatsächlichen Eingangswerten getestet werden können.
Wie nachstehend genauer beschrieben, kann das Systemmodell ferner vorzugsweise auch mindestens ein Durchsetzungsmodul, das Verletzungen von Sicherheitsanforderungen prüfen kann, und mindestens ein symbolisches Modul, das einen Systemeingangswert in ein Symbol für die Überprüfung der symbolischen Ausführung transformieren kann, umfassen.
Gemäß einem anderen bevorzugten Aspekt kann das Verfahren ferner das Bereitstellen von Systemeingangs-Informationsdaten umfassen, die den einen oder die mehreren Parameter des Systemmodells angeben, die in Symbole für die symbolische Ausführung übertragen werden sollen. Der Vorteil besteht darin, dass die in Symbole für die symbolische Ausführung zu übertragenden Systemeingangswerte durch Benutzereingabe zum effizienten Ermöglichen von mehreren Überprüfungsmethoden ausgewählt und verändert werden können.
In einem anderen bevorzugten Aspekt können die Systemeingangs-Informationsdaten bei der/für die Erzeugung von Codedaten des symbolischen Moduls verwendet werden. Zum Beispiel und vorzugsweise kann das erzeugte Systemmodell mindestens ein symbolisches Modul bzw. Codedaten des symbolischen Moduls umfassen (das Modul kann die Codedaten umfassen), die eine oder mehrere Funktionen zum Übertragen von Parametern auf Symbole auf der Basis der bereitgestellten Systemeingangs-Informationsdaten definieren.
Gemäß einem anderen bevorzugten Aspekt kann das Verfahren ferner die Bereitstellung von Überprüfungsanforderungs-Informationsdaten umfassen, die eine oder mehrere Überprüfungsanforderungsbedingungen entsprechend einer jeweiligen Steuerfehlersituation angeben. Dies macht die Überprüfung von Fehlern weniger komplex.
In einem anderen bevorzugten Aspekt können die Überprüfungsanforderungs-Informationsdaten bei der/für die Erzeugung der Durchsetzungsmodul-Codedaten (das vorstehend erwähnte Durchsetzungsmodul; das Modul kann die Codedaten umfassen) verwendet werden, auf deren Basis Verletzungen von Sicherheitsanforderungen geprüft werden können.
Vorzugsweise kann das Durchführen des Softwareüberprüfungsprozesses umfassen: Iterieren durch den Ausführungsbaum des ausführbaren Programms gemäß einer oder mehreren Pfadbedingungen des ausführbaren Programms und/oder Prüfen in jeder Iteration, ob mindestens eine der einen oder mehreren Überprüfungsanforderungsbedingungen erfüllt ist, und insbesondere vorzugsweise Benachrichtigen eines Benutzers über die Detektion der Steuerfehlersituation, falls festgestellt wird, dass mindestens eine der einen oder mehreren Überprüfungsanforderungsbedingungen erfüllt ist.
Gemäß einem anderen bevorzugten Aspekt kann das Verfahren ferner das Ausgeben einer spezifischen Pfadbedingung umfassen, die der detektierten Steuerfehlersituation zugeordnet ist. Dies hat den Vorteil, dass die zugrundeliegenden Pfadbedingungen der Systemeingangsvariablen, die zum detektierten Fehler führen, detektiert und analysiert werden können.
Gemäß einem weiteren bevorzugten Aspekt kann das Verfahren ferner das Bereitstellen von Zusammenarbeits-Informationsdaten umfassen, die Zusammenhänge von zusammenhängenden Eingangsparametern und Ausgangsparametern der bereitgestellten Steuersoftware-Codedaten und der bereitgestellten Anlagencodedaten angeben. Dies hat den Vorteil, dass ein Systemmodell definiert werden kann, das definierte Beziehungen von zusammenhängenden Eingangsparametern und Ausgangsparametern der bereitgestellten Steuersoftware-Codedaten und der bereitgestellten Anlagencodedaten verwendet.
Gemäß einem anderen bevorzugten Aspekt kann das Systemmodell Zusammenarbeitsmodul-Codedaten oder mindestens ein Zusammenarbeitsmodul (das Modul kann die Codedaten umfassen) umfassen, die eine oder mehrere Funktionen zum Kopieren von Ausgangsparametern auf zugehörige Eingangsparameter auf der Basis der bereitgestellten Zusammenarbeits-Informationsdaten angeben. Die Zusammenarbeits-Informationsdaten können zum Erzeugen der Zusammenarbeitsmodul-Codedaten verwendet werden.
Gemäß einem weiteren bevorzugten Aspekt können die Zusammenarbeitsmodul-Codedaten eine erste Funktion zum Kopieren von Ausgangsparametern der Steuersoftware-Codedaten von einer oder mehreren elektronischen Steuereinheiten auf zugehörige Eingangsparameter der Steuersoftware-Codedaten von einer oder mehreren elektronischen Steuereinheiten, eine zweite Funktion zum Kopieren von Ausgangsparametern von Steuersoftware-Codedaten von einer oder mehreren elektronischen Steuereinheiten auf zugehörige Eingangsparameter der Anlagencodedaten und/oder eine dritte Funktion zum Kopieren von Ausgangsparametern der Anlagencodedaten auf zugehörige Eingangsparameter von Steuersoftware-Codedaten von einer oder mehreren elektronischen Steuereinheiten angeben. Mehr oder weniger Funktionen können bereitgestellt werden.
Gemäß einem weiteren bevorzugten Aspekt kann das Systemmodell Synchronisationsmodell-Codedaten (ein jeweiliges Modul kann die Daten enthalten) umfassen, die eine Synchronisation zwischen der Ausführung von einer oder mehreren Funktionen der Steuersoftware-Codedaten und der Anlagencodedaten angeben. Dies hat den Vorteil, dass das Systemmodell in Anbetracht eines Zeitverhaltens der gesteuerten Anlage und der Synchronisation zwischen Steueroperationen von einer oder sogar mehreren gleichzeitig handelnden elektronischen Steuereinheiten und dem Anlagenverhalten effizient und genau bereitgestellt werden kann.
In einem weiteren bevorzugten Aspekt können die Synchronisationsmodul-Codedaten eine ausführbare Funktion angeben, die eine Ausführungsreihenfolge und einen Ausführungszeitablauf der ausführbaren Funktionen der Steuersoftware-Codedaten für die eine oder mehreren elektronischen Steuereinheiten und der Anlagencodedaten angeben können, wobei insbesondere verschiedene Ausführungshäufigkeiten für Funktionen der Steuersoftware-Codedaten im Vergleich zu Funktionen der Anlagencodedaten ermöglicht werden.
Vorzugsweise umfasst das Erzeugen des Systemmodells die (weiteren) Schritte: Bereitstellen (manuell oder computergestützt) von Zusammenarbeits-Informationsdaten zum Erzeugen von Zusammenarbeitsmodul-Codedaten; Bereitstellen (manuell oder computergestützt) von Systemeingangs-Informationsdaten zum Erzeugen von Codedaten des symbolischen Moduls; Bereitstellen (manuell oder computergestützt) von Überprüfungsanforderungs-Informationsdaten zum Erzeugen der Durchsetzungsmodul-Codedaten. Ferner können Synchronisationsmodul-Codedaten bereitgestellt und/oder erzeugt werden. Ferner kann das Systemmodell in einem weiteren Schritt kompiliert werden.
Gemäß einem weiteren Aspekt kann gemäß einem oder mehreren der obigen Aspekte ein Überprüfungssystem zum Testen einer Steuersoftware des gesteuerten Systems geschaffen werden, das Überprüfungssystem kann umfassen: eine Datenbereitstellungseinheit, die dazu konfiguriert ist, Steuersoftware-Codedaten für jede der einen oder der mehreren elektronischen Steuereinheiten bereitzustellen, einen Codegenerator (oder einen Anlagencodedaten-”Bauer”, der mit dem Überprüfungssystem verbindbar ist), um Anlagencodedaten für das gesteuerte System bereitzustellen, einen Systemmodell-Konstrukteur/Generator, der dazu konfiguriert ist, ein Systemmodell auf der Basis der bereitgestellten Steuersoftware-Codedaten, die für jede der einen oder der mehreren elektronischen Steuereinheiten bereitgestellt werden, und der bereitgestellten Anlagencodedaten zu erzeugen, einen Kompilierer, der dazu konfiguriert ist, ein ausführbares Programm auf der Basis des erzeugten Systemmodells zu erzeugen, und/oder eine Überprüfungseinheit, die dazu konfiguriert ist, einen Software-Überprüfungsprozess auf der Basis des ausführbaren Programms durchzuführen.
Vorzugsweise umfasst das erzeugte Systemmodell zumindest die Anlagencodedaten und die Steuersoftware-Codedaten. Ferner kann es Synchronisationsmodul-Codedaten, Zusammenarbeitsmodul-Codedaten, Codedaten des symbolischen Moduls und/oder Durchsetzungsmodul-Codedaten umfassen.
Ferner kann das System vorzugsweise umfassen: mindestens eine Modellvereinfachungseinheit (der Begriff ”Werkzeug” anstelle von ”Einheit” kann auch verwendet werden) zum Vereinfachen eines Bondgraphen-Anlagenmodells, um ein vereinfachtes Bondgraphen-Anlagenmodell zu erzeugen, mindestens eine Modelltransformationseinheit zum Transformieren des vereinfachten Bondgraphen-Anlagenmodells in ein Signalfluss-Anlagenmodell und/oder eine Codeerzeugungseinheit (Codegenerator) zum Erzeugen der Anlagencodedaten auf der Basis des Signalfluss-Anlagenmodells.
Der Codegenerator, um Anlagencodedaten für das gesteuerte System bereitzustellen, kann ein Teil eines Anlagencodedaten-”Bauers” (oder ”Generators”) sein, der ferner den Codegenerator, die Modellvereinfachungseinheit und/oder die Modelltransformationseinheit umfassen kann. Der Codedatenbauer kann eine eigenständige Vorrichtung, sein, d. h. die gegenwärtig beschriebene Anmeldung kann auch eine Codedatenbauer-Vorrichtung beanspruchen, die zumindest den Codegenerator, die Modellvereinfachungseinheit und/oder die Modelltransformationseinheit umfasst. Diese Vorrichtung kann die Bondgraphen-Anlagenmodelldaten empfangen und die Anlagenquellencodedaten/Anlagencodedaten ausgeben und sie kann mit dem Überprüfungssystem verbunden sein, um die Anlagencodedaten bereitzustellen. Diese Vorrichtung kann die Aspekte, wie vorstehend beschrieben, kombinieren/umfassen, insbesondere angesichts der Bereitstellung/Erzeugung der Anlagencodedaten.
Gemäß noch einem weiteren Aspekt kann ein Computerprogrammprodukt mit einem Computerprogrammmittel geschaffen werden, das auf einem computerlesbaren Medium speicherbar ist und von einer Computervorrichtung ausführbar ist, wobei das Programmmittel ausführbare Befehle umfasst, die bewirken, dass die Computervorrichtung Schritte eines Verfahrens gemäß einem oder mehreren der obigen Aspekte durchführt.
KURZBESCHREIBUNG DER FIGUREN
1 zeigt beispielhaft eine schematische Ansicht eines Überprüfungssystems.
2 zeigt beispielhaft eine Datenflussstruktur in einem Überprüfungssystem gemäß 1.
3 zeigt beispielhaft ein Beispiel eines gesteuerten Systems.
4 zeigt beispielhaft ein schematisches Bondgraphenmodell (Anlagenmodell) des gesteuerten Systems von 3.
5 zeigt beispielhaft einen Teil von Steuersoftware-Codedaten des gesteuerten Systems von 3.
6 zeigt beispielhaft Informationen über die Systemstruktur.
7 zeigt beispielhaft Systemeingangs-Informationsdaten für Testzwecke des gesteuerten Systems von 3.
8 zeigt beispielhaft Überprüfungsanforderungs-Informationsdaten.
9 zeigt beispielhaft Daten einer/eines Teils einer Ersatztabelle.
10 zeigt beispielhaft einen Teil/Daten einer Anschlussumsetzungstabelle.
11 zeigt beispielhaft ein Diagramm eines vereinfachten Bondgraphenmodells (Anlagenmodells) des gesteuerten Systems von 3.
12 zeigt beispielhaft einen Teil/Daten eines Verzeichnisses physikalischer Werte.
13 zeigt beispielhaft ein Diagramm eines Signalflussmodells (Anlagenmodells).
14 zeigt beispielhaft einen Teil von Anlagencodedaten des gesteuerten Systems von 3.
15 zeigt beispielhaft einen Teil von Zusammenarbeitsmodul-Codedaten der Zusammenarbeits-Informationsdaten von 6.
16 zeigt beispielhaft einen Teil von Codedaten des symbolischen Moduls auf der Basis der Systemeingangs-Informationsdaten von 7.
17 zeigt beispielhaft einen Teil von Durchsetzungsmodul-Codedaten auf der Basis der Überprüfungsanforderungsdaten von 8.
18 zeigt beispielhaft einen Teil von Synchronisationsmodul-Codedaten.
19 zeigt beispielhaft eine Konfiguration des Systemmodells (Daten).
20 zeigt beispielhaft eine Anzeige eines beispielhaften Überprüfungsergebnisses.
21 zeigt beispielhaft einen Ablaufplan eines Prozesses zur Überprüfung für Steuersoftwaretesten.
22 zeigt beispielhaft einen Ablaufplan eines Anlagenvereinfachungsprozesses.
23 zeigt beispielhaft einen Ablaufplan eines Modelltransformationsprozesses.
24 zeigt beispielhaft einen Ablaufplan eines Systemmodell-Erzeugungsprozesses.
AUSFÜHRLICHE BESCHREIBUNG DER FIGUREN
Bevorzugte Aspekte werden nachstehend mit Bezug auf die begleitenden Figuren beschrieben. Die beschriebenen Merkmale und Aspekte können modifiziert oder kombiniert werden.
Cyberphysikalische Systeme (CPS), die Rechensysteme mit physikalischen Systemen verknüpfen, werden häufig verwendet, um sicherheitskritische Prozesse zu überwachen und zu steuern, d. h. Prozesse, die das Potential tragen, eine signifikante Beschädigung oder einen Verlust im Fall von Ausfällen zu verursachen. Obwohl sicherheitskritische Systeme umfangreich sowohl in diskreten Bereichen (Rechenbereichen) als auch analogen Bereichen (Steuerbereichen) untersucht wurden, gelten die entwickelten Techniken meist für den spezifischen diskreten oder analogen Bereich. Da sich cyber-physikalische Systeme über beide diese Bereiche erstrecken, hinterlässt die Konzentration auf einen individuellen Bereich eine Lücke auf der Systemebene, wobei komplexe Wechselwirkungen zwischen beiden Bereichen zu Ausfällen führen können, die nicht durch Betrachten nur des physikalischen oder des digitalen Teils des integrierten CPS analysiert werden können.
Cyber-physikalische Systeme (CPS) sehen eine zunehmende Verwendung in Transport-, Leistungs- und für andere sicherheitskritische Systeme. Das CPS wird verwendet, um ein (analoges) physikalisches Phänomen durch physikalische Aktuatoren zu überwachen und zu steuern, die wiederum durch ein (digitales) sicherheitskritisches Rechensystem betrieben werden. Die Verarbeitung muss das Zielsystemverhalten korrekt überwachen und die Aktuatoren genau betätigen, um die Sicherheit des Systems zu garantieren, um eine Beschädigung entweder am System oder an der Betriebsumgebung zu vermeiden.
Folglich wurden für sicherheitskritische CPS strenge Überprüfungstechnologien, um korrekte Operationen sicherzustellen, untersucht, um sowohl die diskreten als auch kontinuierlichen Aspekte zu betrachten. Da jedoch diese Technologien sich typischerweise nur auf einen individuellen Aspekt konzentrieren, haben die komplexen Wechselwirkungen zwischen diskreter Verarbeitung und kontinuierlichem Verhalten ein Potential, Defekte auf der Ebene des komplexen Systems zu verursachen.
Ein Kraftfahrzeug-Bremssteuersystem kann beispielsweise schwierig zu findende sicherheitsrelevante Defekte enthalten. Diese Defekte können nur erscheinen oder verursacht werden durch eine spezifische Kombination einer spezifischen Fahreroperation und eines spezifischen Fahrzeugverhaltens in Anbetracht einer spezifischen Kombination von Sequenz und Zeitablauf. Obwohl Anforderungen für die Sicherheitsüberprüfung von kritischen CPS leicht anzugeben sind, wobei die Abdeckung aller möglichen Rechen- und Steuerwechselwirkungen sichergestellt wird, ist es unausführbar unter Verwendung von herkömmlichen Konstruktionsmethoden. Komplizierte Steuer/Rechen-Wechselwirkungen führen häufig zu Zeitablauf- und Sequenzdefekten, die besonders schwierig aufzudecken sind. Da ein Konstruktionsingenieur häufig nur eine detaillierte Kenntnis nur seines diskreten Steuer- oder Rechenbereichs hat, wird dieses Problem außerdem sehr komplex.
Gemäß einigen hier beschriebenen Aspekten wird vorgeschlagen, eine praktische formale Überprüfungsplattform/System für sicherheitskritische CPS zu verwenden. Das vorgeschlagene Überprüfungssystem kann Systemebenendefekte durch Prüfen von sicherheitsrelevanten Eigenschaften eines Systemmodells finden, das das Steuersystemverhalten durch Kombinieren der Steuersoftware (Steuersoftware-Codedaten) und des Anlagenquellencodes (Anlagencodedaten) auf der Basis der formalen Überprüfung auf der Basis der symbolischen Ausführung simuliert.
Einige hier beschriebene Aspekte können sich beziehen auf: 1) Konstruktion eines praktischen formalen Überprüfungsprozesses für sicherheitskritische CPS; 2) Entwicklung eines Systemmodell-Konstruktionsverfahrens für sicherheitskritische CPS; 3) Klärung der Symboldefinition für Systemeingaben von sicherheitskritischen CPS; 4) Klärung der Eigenschaftsdefinition unter Verwendung von Durchsetzungsbefehlen für sicherheitskritische CPS; 5) Erstellung der Systemebenendefekt-Detektion durch eine Fallstudie an der Sicherheitsüberprüfung eines beispielhaften realen Kraftfahrzeug-Bremssteuersystems; und/oder 6) Konstruktion eines praktischen Optimierungsprozesses für sicherheitskritische CPS.
In bevorzugten Aspekten wird vorgeschlagen, von der symbolischen Ausführung Gebrauch zu machen. Die formale Überprüfung auf der Basis von symbolischer Ausführung hilft Benutzern, Eingangswertfälle effizient zu finden, die Fehler des Zielquellencodes verursachen. Der Grund besteht darin, dass die Überprüfung alle möglichen Effekte untersuchen kann, die durch Änderungen des Werts in Variablen verursacht werden, die Benutzer als Symbol definieren, vom Blick von Verzweigungsbedingungen (Pfadbedingungen). Wenn Benutzer Eingangsvariablen von Überprüfungszielen als Symbol definieren und Verzweigungsbefehle mit Bedingungen wie negative Eigenschaftsdetektionsfehler als Durchsetzungscode einfügen, kann folglich die Überprüfung den Einfangsfall finden, der Fehler verursacht, wenn das Ziel seine Eigenschaft nicht erfüllt.
Die formale Überprüfung auf der Basis der symbolischen Ausführung analysiert die Programmlogik des Überprüfungsziels und gewinnt eine Formel, die sich auf Symbole auswirkt. Dann macht die Überprüfung eine Einschränkung für eine jeweilige Verzweigung gemäß der Formel. Wenn die Einschränkung mehrere Symbole beinhaltet, macht die Überprüfung eine Einschränkung durch Kombinieren dieser Formeln. Schließlich liefert die Überprüfung den konstanten Wert der Symbole, der die Einschränkung erfüllt, unter Verwendung eines Lösers, der auf das Lösen von Einschränkungen abgezielt ist. Wenn die Überprüfung den Fehlertestfall informieren kann, wenn das Programm den Fehlerpfad erreicht, ist es folglich eine leistungsstarke und effiziente Überprüfungstechnologie, um jegliches mögliches Verhalten (Zustände, Bedingungen usw.) eines Überprüfungsziels logisch abzudecken.
In einigen bevorzugten Aspekten ermöglicht ein vorgeschlagener Prozess die Überprüfung eines ganzen Steuersystems. In dem Prozess ein Systemmodell (oder Anlagenmodell), das das Steuersystemverhalten simuliert und das durch Kombinieren der Steuersoftware, des Anlagencodes (Anlagenquellencodes), Sicherheitsanforderung(en) und/oder Systeminformationen aufgebaut wird. Das Systemmodellverhalten kann unter Verwendung von symbolischen Systemeingaben gemäß Eigenschaftsdetektions-Sicherheitsanforderungsverletzungen geprüft werden.
Der Anlagencode kann gemäß einem bevorzugteren Aspekt in einer automatisierten oder zumindest halbautomatisierten Weise erzeugt werden. Ein Benutzer kann beispielsweise ein Bondgraphen-Anlagenmodell bereitstellen oder eingeben, das das reale System darstellt. Der hier beschriebene bevorzugte Aspekt kann dann das Bondgraphen-Anlagenmodell automatisch verarbeiten und es in einen Anlagenquellencode/Anlagencodedaten transformieren, die auf einem Signalfluss-Anlagenmodell basieren. Die Anlagencodedaten können automatisch zum Verfahren/System für deren Weiterverarbeitung geliefert werden, um das Systemmodell zu erzeugen. Nach der Erzeugung des Systemmodells kann das System/Verfahren die Sicherheitsüberprüfung des Systemmodells durch die formale Überprüfung auf der Basis von symbolischer Ausführung durchführen.
1 zeigt beispielhaft eine schematische Ansicht eines Überprüfungssystems gemäß einem Aspekt der Erfindung. Das Überprüfungssystem 1 umfasst einen Computer 2 mit einer Betriebseinheit 3 (wie z. B. einer oder mehreren CPUs) und einem Speicher 4, der dazu konfiguriert ist, Daten und Programme zu speichern, die durch die Betriebseinheit 3 ausgeführt werden sollen, einschließlich eines Betriebssystemprogramms. Der Speicher kann einen flüchtigen Speicher und/oder einen nichtflüchtigen Speicher umfassen und er kann verschiedene Speichereinheiten wie z. B. RAM, ROM, Cache-Speicher, Festplattenspeicher und/oder Flash-Speicher umfassen.
Beispielhaft speichert der Speicher 4 eine Modellvereinfachungseinheit/ein Modellvereinfachungswerkzeug 5, eine Modelltransformationseinheit/ein Modelltransformationswerkzeug 6, einen Codegenerator 7 und einen Systemgenerator 8. Die technischen Details dieser Einheiten/Werkzeuge werden nachstehend im Einzelnen beschrieben. Ferner ist gezeigt, dass der Speicher 4 eine Einheit/ein Werkzeug 9 zur symbolischen Ausführung und Überprüfung aufweist, wie z. B. ein Überprüfungswerkzeug auf der Basis von symbolischer Ausführung auf der Basis von EXE, KLEE oder CREST (vgl. Zum Beispiel den Artikel "Symbolic Execution for Software Testing: Three Decades Later" von C. Cadar und K. Sen).
Ferner umfasst das Überprüfungssystem 1 eine Eingabevorrichtung 11 (wie z. B. eine Tastatur, ein Tastenfeld, eine Maus, ein Berührungsfeld und/oder einen Berührungsbildschirm) zum Empfangen einer Benutzereingabe und eine Anzeige 12 zur Bereitstellung von Informationen auf einem visuellen Bildschirm für einen Benutzer. Die Eingabevorrichtung 11 und die Anzeige 12 sind mit dem Überprüfungscomputer 2 durch eine Eingabe/Ausgabe-Einheit 10 des Computers 2 verbunden.
In dieser Beschreibung wird eine Unterscheidung zwischen zwei Typen von Daten durchgeführt: Informationsdaten und Codedaten. Informationsdaten sind ein Typ von Daten, die Informationen wie z. B. Parameter, Eingangsparameter und Ausgangsparameter, Werte von Parametern, Beziehungen von Parametern usw. angeben. Das Format der Informationsdaten ist nicht begrenzt. Codedaten werden andererseits als (Quellen-)Code in einer Programmiersprache wie z. B. C, C++, PERL, Postscript, Java, JavaScript oder dergleichen geschrieben und folgen den Regeln der jeweiligen Programmiersprache. Steuerdaten definieren Funktionen, die auf Eingangsparametern beruhen und Ausgangsparameter geben, z. B. auf der Basis von definierten Berechnungen. Unter Verwendung eines Kompilierers können Codedaten in ausführbare Funktionen transformiert werden, die von der Betriebseinheit 3 ausgeführt werden können.
2 zeigt beispielhaft eine Datenflussstruktur in einem Überprüfungssystem gemäß 1. Im Folgenden wird die Eingabe in den Systemmodellgenerator 8 (der Begriff ”Konstrukteur” kann anstelle von ”Generator” verwendet werden) gemäß den Eingangsdaten beispielhaft beschrieben: Steuersoftware-Codedaten 402 (z. B. Software-Quellencode von einer oder mehreren ECUs), Anlagencodedaten 414 (z. B. ein Anlagenquellencode; dessen Erzeugung wird nachstehend im Einzelnen beschrieben), Zusammenarbeits-Informationsdaten 403 (zum Angeben von Informationen einer Systemstruktur), Systemeingangs-Informationsdaten 404 (zum Angeben von Informationen einer Systemeingabe) und Überprüfungsanforderungs-Informationsdaten 405 (zum Angeben von Informationen von einer oder mehreren Überprüfungsanforderungen), die z. B. von einem Benutzer und/oder alternativ durch eine andere verbundene Vorrichtung, einen Computer oder dergleichen geliefert werden.
Die Eingangsdaten, wie vorstehend erwähnt, werden in einen Systemmodell-Konstrukteur 8 eingegeben und der Systemmodell-Konstrukteur 8 ist dazu ausgelegt, ein Systemmodell 415 auf der Basis der eingegebenen Daten zu erzeugen, insbesondere und vorzugsweise auf der Basis der Steuersoftware-Codedaten 402 und der Anlagencodedaten 414. Ferner und bevorzugter sowie auf der Basis der weiteren eingegebenen Daten, einschließlich Zusammenarbeits-Informationsdaten 403, Systemeingangs-Informationsdaten 404 und Überprüfungsanforderungs-Informationsdaten 405.
Das erzeugte Systemmodell 415 wird beispielhaft in das Überprüfungswerkzeug 9 für die (auf der Basis der) symbolische Ausführung für die Überprüfung auf der Basis der symbolischen Ausführung (z. B. auf der Basis eines bekannten Überprüfungswerkzeug auf der Basis der symbolischen Ausführung wie z. B. KLEE, EXE oder CREST, vorstehend erwähnt) eingegeben, das dann die Ergebnisse 416 der Überprüfung ausgibt.
Nun wendet sich die Beschreibung der automatischen (oder zumindest halbautomatischen) Erzeugung der Anlagencodedaten 414 zu, deren (Daten-)Fluss im oberen Teil von 2 dargestellt ist; d. h. in dem Teil von 2, der mit der Eingabe eines Bondgraphen-Anlagenmodells 401 beginnt und mit der Erzeugung der Anlagencodedaten 414 endet. Weitere Details dieser automatisierten Erzeugung werden in Verbindung mit der Beschreibung von 4 ff. gegeben. Die Einheiten, Bibliotheken und dergleichen dieses oberen Teils von 2 können ein Teil einer ”Generator”- oder ”Bauer”-Einheit sein, die die Anlagencodedaten 414 aufbaut.
Wie erwähnt, beginnt die Erzeugung der Anlagencodedaten 414 vorzugsweise mit dem Eingeben von einem oder mehreren Bondgraphen-Anlagenmodellen 401, die die zu simulierende Anlage durch Objekte/Komponenten, Verbindungen zwischen den Objekten und dergleichen darstellen. Ein Beispiel davon ist in 4 bereitgestellt. Das Bondgraphen-Anlagenmodell 401 kann in Form eines Datenformats einer jeweiligen Modellierungssoftware oder dergleichen eingegeben werden. Das Bondgraphen-Anlagenmodell 401 wird von einer Modellvereinfachungseinheit 5 empfangen oder in diese eingegeben, die vorzugsweise ein Softwarecode oder ein Programm ist, das im Speicher 4 gespeichert ist. Die Modellvereinfachungseinheit 5 ist dazu konfiguriert, Informationsdaten von verbundenen Einheiten wie z. B. einer Ersatztabelle 406, einer Anschlussumsetzungstabelle 407, einer Bondgraphen-Objektbibliothek 408 und/oder (eines) Simulationsergebnisse(s) 409 zu empfangen, die nachstehend weiter erläutert werden. Auf der Basis der Informationen ist die Modellvereinfachungseinheit 5 ferner dazu konfiguriert, die Komplexität des empfangenen Bondgraphen-Anlagenmodells 401 zu verringern. Das vereinfachte Bondgraphen-Anlagenmodell 410 kann im Allgemeinen rechnerisch weniger komplexe Objekte umfassen als das Bondgraphen-Anlagenmodell 401. Komplexe Massenobjekte können beispielsweise durch vereinfachte Massenobjekte ersetzt werden. Die Vereinfachung kann die Anzahl von Anschlüssen, die Anzahl von Variablen/Parametern, die für das Objekt erforderlich sind, die Anzahl von zu lösenden Gleichungen und dergleichen betreffen.
Die Vereinfachung durch die Modellvereinfachungseinheit 5 ist optional. Es kann möglich sein, z. B. durch Benutzereingabe oder dergleichen, dass der Vereinfachungsschritt als nicht erforderlich bestimmt wird, möglicherweise da das Bondgraphen-Anlagenmodell 401 bereits relativ wenig komplex ist.
Eine Modelltransformationseinheit 6 ist dazu konfiguriert, das (vereinfachte) Bondgraphen-Anlagenmodell 401/410 zu empfangen und Informationen über Namen von physikalischen Werten und über den Ersatz von Bondgraphenobjekten durch Signalflussobjekte zu erhalten/lesen. Ferner ist die Modelltransformationseinheit 6 mit den Informationen dazu konfiguriert, das (vereinfachte) Bondgraphen-Anlagenmodell 401/410 in ein Anlagenmodell zu transformieren, das auf Signalflussobjekten basiert. Mit anderen Worten, die Einheit 6 erzeugt ein Signalfluss-Anlagenmodell 413 auf der Basis des (vereinfachten) Bondgraphen-Anlagemodells 401/410. Das Signalfluss-Anlagenmodell 413 kann das Datenformat einer jeweiligen Modellierungssoftware oder dergleichen aufweisen.
Der technische Vorteil, der an dieser Transformation beteiligt ist, besteht darin, dass das Signalfluss-Anlagenmodel 413 eine sehr effiziente und weniger rechenaufwändige und weniger komplexe Überprüfung des zu untersuchenden Systems – im Vergleich zu den rechenaufwändigen Bondgraphen-Anlagenmodellen z. B. in HIL-Methoden – ermöglicht. Ferner muss der Benutzer sich weder Gedanken machen über noch die Details der Transformations- und Vereinfachungsschritte des Modells kennen, da dies automatisch gemäß den hier beschriebenen Aspekten ausgeführt werden kann.
Die Überprüfung wird beispielhaft in Verbindung mit einem Bremssteuersystem eines Kraftfahrzeugs als gesteuertes (reales oder physikalisches) System erläutert. Es ist jedoch zu beachten, dass der Überprüfungsprozess nicht auf ein Bremssteuersystem begrenzt ist, sondern auf verschiedene gesteuerte Systeme/Anlagen wie z. B. gesteuerte Systeme mit einer oder mehreren elektronischen Steuereinheiten, einem oder mehreren Aktuatoren und einem oder mehreren Sensoren angewendet werden kann, wobei jeder Sensor dazu ausgelegt ist, ein jeweiliges Sensorsignal in mindestens eine der einen oder mehreren elektronischen Steuereinheiten einzugeben, und jeder Aktuator dazu ausgelegt ist, in Reaktion auf jeweilige Steuersignale zu handeln, die von mindestens einer der elektronischen Steuereinheiten eingegeben werden, und jede elektronische Steuereinheit dazu konfiguriert ist, ein jeweiliges Steuerprogramm auszuführen, um eine oder mehrere auf der Basis der eingegebenen Sensorsignale auszugeben.
3 zeigt beispielhaft ein Beispiel eines gesteuerten Systems. Das Bremssteuersystem umfasst wegen der Bereitstellung eines relativ nicht komplexen Beschreibungsbeispiels eine elektronische Steuereinheit (ECU), nämlich die Bremssteuereinheit 4021 (BCU 4021). Wie bereits vorstehend erwähnt, ist jedoch die hier beschriebene Erfindung besonders vorteilhaft und leistungsfähig, wenn sie auf gesteuerte Systeme mit mehr als einer ECU hinausläuft. Das gesteuerte System von 3 kann beispielsweise ferner eine elektronische Stabilitätssteuereinheit umfassen, die kommunikativ mit der BCU 4021 über ein Kommunikationsnetz (wie beispielsweise einen Systembus oder ein Steuereinheitsbereichsnetz CAN) verbunden sein kann.
Es ist gezeigt, dass die Bremssteuereinheit BCU 4021 eine Eingabe von einem Bremspedal (”Pedalereignis”) empfängt und einen Bremssattel 4011 als Aktuator auf der Basis der Eingabe vom Bremspedal zum Erzeugen einer Bremskraft durch einen Hydraulikdruck, der auf den Bremssattel 4011 aufgebracht wird, steuert.
Falls mehr als eine ECU, z. B. die BCU 4021 und eine elektronische Stabilitätssteuereinheit (ESC), kombiniert sind, handeln in typischen Systemen die BCU 4021 und die ESC auf der Basis ihrer jeweiligen unabhängigen Steuersoftwarecodes und es reicht nicht aus, die Zuverlässigkeit und korrekte Funktion von jeder der jeweiligen Steuersoftware zu überprüfen (d. h. ob jeder der jeweiligen Steuersoftwarecodes für sich allein frei von Defekten ist), vielmehr muss berücksichtigt werden, dass eine Gesamtsystem-Steuerfunktionsstörung aufgrund der Zusammenarbeit der mehreren elektronischen Steuereinheiten entstehen könnte. In einigen Systemen kann beispielsweise die BCU 4021 zusätzlich eine implementierte Steuerung aufweisen, um einen Austritt des Hydraulikfluids zu detektieren, um einen Bremssteuerbefehl zu erhöhen, wenn detektiert wird, dass ein Druck im hydraulischen System niedriger als normal ist, z. B. aufgrund eines Fluidaustritts, um immer noch zu ermöglichen, dass der Fahrer die Geschwindigkeit für die Sicherheit verringert, wenn ein Fluidausstritt auftritt. Dies kann zu einem Gesamtsystemdefekt führen, selbst wenn jeder der Steuersoftwarecodes der BCU 4021 und der ESC unabhängig frei von einer Funktionsstörung/Defekten ist.
Eine solche Steuerfunktionsstörung aufgrund von kausalen Verbindungen in der Zusammenarbeit von mehreren elektronischen Steuereinheiten kann in üblicherweise bekannten Software-Überprüfungstechniken nicht detektiert werden, in denen die Steuersoftware einer einzelnen elektronischen Steuereinheit unabhängig getestet wird, z. B. durch Hardware-in-the-Loop-Systemüberprüfung (HIL) einer elektronischen Steuereinheit, und wobei der Anlagenquellencode auf einem Bondgraphen-Anlagenmodell basiert.
4 zeigt beispielhaft eine (Teil einer) Bondgraphen-Darstellung/Modell (Anlage) 401 des gesteuerten Systems von 3. Das Bondgraphenmodell 401 mit Bondgraphen-Modelldaten beschreibt das Anlagenmodell in einer Bondgraphenweise mit Objekten, die physikalische Komponenten des gesteuerten Systems/der gesteuerten Anlage darstellen, und Blöcken, die Eingabe(n) und Ausgabe(n) der Bondgraphen-Darstellung/Modell 401 darstellen. Die Blöcke und Objekte sind miteinander verbunden; vorzugsweise weisen die Objekte Anschlüsse auf, die ermöglichen, sie miteinander zu verbinden, z. B. zum Übertragen oder Austauschen von Strömen, Kräften usw.
Insbesondere weist im Beispiel von 4, das das beispielhafte gesteuerte System von 3 darstellt, das Bondgraphenmodell 401 einen ”Eingangs”-Block und einen ”Ausgangs”-Block auf, die der Eingang und der Ausgang des Bondgraphenmodells 401 sind. Zwischen den zwei Blöcken sind ferner zwei Objekte, die jeweils eine Feder darstellen, ein Objekt, das einen Kraftsensor darstellt, und ein Objekt, das eine fortbewegte Masse darstellt, angeordnet. Das Objekt ”Feder” ist mit dem Objekt ”Fortbewegte_Masse” über den Anschluss ”P2” verbunden. Das Objekt ”Fortbewegte_Masse” ist ferner mit dem Objekt ”Kraft_Sensor” über weitere Ports ”P1” und ”P2” verbunden. Das Objekt ”Kraft_Sensor” ist ferner mit dem zweiten ”Feder”-Objekt über seinen Anschluss ”P3” verbunden.
5 zeigt dann beispielhaft einen Teil der Steuersoftware-Codedaten 402 der BCU 4021 von 3. Die Steuersoftware-Codedaten 402 definieren eine Funktion software_execution_1ms(), die einer Steuerfunktion der BCU 4021 von 3 für eine Zeitdauer von 1 ms entspricht, d. h. die BCU 4021 kann beispielhaft die Steuerfunktion in Zyklen mit jeweils 1 ms ausführen.
Als erster Eingangsparameter, wenn die Funktion software_execution_1ms() ausgeführt wird, nehmen die Steuersoftware-Codedaten 402 einen Eingangsparameter driver_pedal_event, der beispielhaft Werte von 0 oder größer/kleiner 0 annehmen kann. Ein Falls-Satz prüft, ob das driver_pedal_event 0 oder von 0 verschieden ist. In Abhängigkeit von dem Ergebnis wird z. B. ein vorbestimmter Wert für den brake_control_command gesetzt oder weiter berechnet.
Der dargestellte Teil der Steuersoftware-Codedaten 402 ermöglicht, den Betrag einer Zielbremskraft gemäß dem Eingangsparameter des Bremspedalzustandes zu berechnen.
Wenn man nun zu 14 springt, ist ein kleiner Teil der Anlagencodedaten 414 des gesteuerten Systems von 3 beispielhaft gezeigt. Die Anlagencodedaten 414 werden durch das hier beschriebene Überprüfungssystem 1 und das zugehörige Verfahren erzeugt. Vorzugsweise werden die Anlagencodedaten 414 automatisch zum Verfahren und/oder Überprüfungssystem 1 zum Erzeugen des Systemmodells 414 auf deren Basis sowie auf der Basis der vorstehend beschriebenen Steuersoftware-Codedaten 402 geliefert.
Es wird angemerkt, dass die Anlagencodedaten 414 von den Steuersoftware-Codedaten 402 unterschieden werden sollten, wie vorstehend für die BCU 4021 beschrieben, da die Steuersoftware-Codedaten 402 einem tatsächlichen Steuersoftwarecode der elektronischen Steuereinheiten entsprechen oder zumindest darauf basieren, wie z. B. der BCU 4021, die durch das hier beschriebene Überprüfungssystem 1 getestet werden soll. Die Anlagencodedaten 414 beschreiben ”künstlich/virtuell” das Verhalten des gesteuerten Systems/der gesteuerten Anlage. Beispielsweise nimmt es Ausgangsparameter von elektronischen Steuereinheiten und erzeugt entsprechende Ausgangsparameter, die einer Sensoreingabe entsprechen, die dann in die elektronischen Steuereinheiten (in die Funktion der auszuführenden Software-Codedaten) für den nächsten Zyklus eingegeben werden können.
Für ein gesteuertes System eines Kraftfahrzeugs wie z. B. das System von 3 können die entsprechenden Anlagencodedaten 414 ausgeführt werden, um das gesteuerte System/die gesteuerte Anlage und. insbesondere das Verhalten des gesteuerten Systems/der gesteuerten Anlage auf der Basis von Befehlen zu simulieren, die aus den elektronischen Steuereinheiten ausgegeben werden, und es kann ferner das Verhalten eines Fahrers gemäß einem oder mehreren zu testenden Fahrszenarios simulieren. Die Anlagencodedaten 414 sind dazu konfiguriert, den aktuellen Zustand des gesteuerten Systems/der gesteuerten Anlage auf der Basis der Steuerbefehle zu aktualisieren, die in das gesteuerte System eingegeben werden, einschließlich der Berechnung von entsprechenden Sensorwerten von Sensoren des Systems und der Aktualisierung/Berechnung von internen Werten, die den Zustand des gesteuerten Systems/der gesteuerten Anlage beschreiben.
Es ist zu beachten, dass die Anlagencodedaten 414 manuell durch einen Benutzer in Abhängigkeit von den Anforderungen erzeugt werden können oder der Benutzer die Anlagencodedaten auf der Basis eines Anlagenmodells unter Verwendung von automatischen Codegeneratoren erzeugen kann. Die hier beschriebenen bevorzugten Aspekte umfassen jedoch eine automatische oder halbautomatische Erzeugung, Verarbeitung und Bereitstellung der Anlagencodedaten 414 (wie vorstehend kurz beschrieben wurde und wie nachstehend genauer beschrieben wird). Die automatisierte Erzeugung, Verarbeitung und/oder Bereitstellung der Anlagencodedaten 414 ermöglicht vorteilhafterweise, dass mühselige manuelle Arbeit auf ein Minimum verringert wird und außerdem dass die Nachteile von auf Bondgraphen bezogenen Modellen durch automatische Übertragung von (existierenden) Bondgraphenmodellen 401 in Signalfluss-Anlagenmodelle 413 beseitigt werden können.
Die beispielhaften Anlagencodedaten 414 von 14 definieren eine Funktion plant_update(), die eine Funktion zur Aktualisierung der Anlage auf der Basis von mehreren Eingangsparametern, einschließlich der Steuerbefehls-Parametereingabe von der BCU 4021, definiert. Die dargestellten Codedaten 414 simulieren das Verhalten der Anlage (des gesteuerten Systems) und aktualisieren es, damit es gemäß dem aktuellen Zustand der Steuerbefehls-Parametereingabe ist.
Wie vorstehend erläutert, kann ein jeweiliger Teil der Steuersoftware-Codedaten 414 für jede der elektronischen Steuereinheiten eines gesteuerten Systems bereitgestellt werden, wobei alle jeweiligen Steuersoftware-Codedaten 414 sich auf das Steuerverhalten der elektronischen Steuereinheit beziehen, durch Empfangen von einem oder mehreren Eingangsparametern, die für die Steuerung der jeweiligen elektronischen Steuereinheit verwendet werden, und Bestimmen des einen oder der mehreren Ausgangsparameter (insbesondere Steuerbefehle) der jeweiligen elektronischen Steuereinheit auf der Basis der empfangenen einen oder mehreren Eingangsparameter.
Überdies kann mindestens eine Einheit von Anlagencodedaten 414 zum Simulieren des Verhaltens des gesteuerten Systems/der gesteuerten Anlage für die Aktualisierung des aktuellen Zustandes der Anlage bereitgestellt werden. In weiteren Aspekten können natürlich mehrere Einheiten von Anlagencodedaten 414 für die Simulation von verschiedenen Teilen oder Abschnitten des gesteuerten Systems/der gesteuerten Anlage bereitgestellt werden. Es wird als allgemeiner Kommentar angemerkt, dass die Anlagencodedaten 414, wie in 14 gezeigt, nur einen kleinen Bruchteil der ”realen” Anlagencodedaten 414 wiedergeben. Der wiedergegebene Bruchteil ist zum Verbessern des Verständnisses dessen, was die Anlagencodedaten 414 sind, vorgesehen und dargestellt.
Die Simulation des gesteuerten Systems/der gesteuerten Anlage durch die Ausführung der Funktionen, die durch die Anlagencodedaten 414 definiert sind, empfängt Ausgangswerte/Ausgangsparameter von der (den) elektronischen Steuereinheit(en) als Eingangswerte/Eingangsparameter und bestimmt auf der Basis davon den einen oder die mehreren Ausgangswerte/Ausgangsparameter, die dann in die elektronischen Steuereinheiten als Eingangswerte/Eingangsparameter eingegeben werden (z. B. die Sensorwerte darstellen). Die Ausführung der durch die Anlagencodedaten 414 definierten Funktionen kann auch interne Parameter bestimmen, wie z. B. eine Bremskraft, die einen Zustand des gesteuerten Systems/der gesteuerten Anlage beschreiben.
Wie vorstehend erwähnt, kann im gesteuerten System jeder Ausgangsparameter einer elektronischen Steuereinheit als Eingangsparameter für eine oder mehrere andere elektronische Steuereinheiten und/oder als Eingangsparameter für die Simulation des gesteuerten Systems/der gesteuerten Anlage in den Anlagencodedaten 414 verwendet werden. Andererseits kann jeder Ausgangsparameter der Simulation des gesteuerten Systems/der gesteuerten Anlage als Eingangsparameter für eine oder mehrere andere elektronische Steuereinheiten verwendet werden.
Bisher wurden die eingegebenen ”Steuersoftware-Codedaten 402” und ”Anlagencodedaten 414” für den Systemmodellgenerator 8 beschrieben. Eine weitere Eingabe kann zum Erzeugen eines genauen Systemmodells 415 erwünscht sein: 6 zeigt beispielhaft Zusammenarbeits-Informationsdaten 403 (siehe 2) für das gesteuerte System von 3. Das spezifische Format der Zusammenarbeits-Informationsdaten 403 ist nicht begrenzt. Die Informationen, die in den Zusammenarbeits-Informationsdaten 403 angegeben sind, werden vorzugsweise für die Erzeugung von Zusammenarbeitsmodul-Codedaten 417 verwendet (z. B. 19).
Die Zusammenarbeits-Informationsdaten 403 geben Beziehungen von Eingangsparametern und Ausgangsparametern an und sie geben eine Abbildung von spezifischen Ausgangsparametern auf die entsprechenden zugehörigen Eingangsparameter von Steuereinheiten zu Steuereinheiten, von Steuereinheiten zum gesteuerten System/zur gesteuerten Anlage und/oder vom gesteuerten System/von der gesteuerten Anlage zu den Steuereinheiten an. Das heißt, die Informationen der Zusammenarbeits-Informationsdaten 403 geben die Beziehung von Parametern und die Richtung des Datenflusses an, d. h. von einem spezifischen Ausgangsparameter zum zugehörigen Eingangsparameter.
Insbesondere zeigt 6 beispielhaft die Zusammenarbeits-Informationsdaten 403, die Beziehungen von Eingangs- und Ausgangsparametern für das System von 3 beschreiben. Der Ausgangsparameter brake_control_command, der in den Steuersoftware-Codedaten 402 der BCU 4021 von 5 verwendet wird, wird auf den Eingangsparameter input_brake_control_command abgebildet/diesem zugeordnet, der in den Anlagencodedaten 414 von 14 verwendet wird (von der elektronischen. Steuereinheit BCU 4021 zum gesteuerten System/zur gesteuerten Anlage ”Software zu Anlage”).
Andererseits wird beispielsweise der Ausgangsparameter output_mass_displacement, der in den Anlagencodedaten 414 von 14 verwendet wird, auf current_mass_displacement abgebildet/diesem zugeordnet, das z. B. in den BCU-Steuersoftware-Codedaten 402 verwendet werden kann (vom gesteuerten System/von der gesteuerten Anlage zur elektronischen Steuereinheit BCU: ”Anlage zu Software”).
Falls mehrere elektronische Steuereinheiten verwendet werden, können Beziehungen oder Ausgangsparameter und Eingangsparameter von verschiedenen elektronischen Steuereinheiten dementsprechend abgebildet/zugeordnet werden (von einer elektronischen Steuereinheit zu einer anderen elektronischen Steuereinheit: ”ECU zu ECU”).
Die Zusammenarbeits-Informationsdaten 403 zeigen (eine) Beziehung(en) und/oder die Richtung des Datenflusses (der Datenflüsse).
Ferner zeigt 7 beispielhaft Systemeingangs-Informationsdaten 404 (siehe 2) für Testzwecke des gesteuerten Systems von 3. Das spezifische Format der Systemeingangs-Informationsdaten 404 ist nicht begrenzt. Die gezeigten Werte, z. B. Zeitdauer, sind beispielhaft. Die in den Systemeingangs-Informationsdaten 404 angegebenen Informationen können bei der Erzeugung der Codedaten 418 des symbolischen Moduls verwendet werden.
Die Systemeingangs-Informationsdaten geben während der Software-Überprüfung zu verändernde Parameter als Variablen (Systemeingabe) an und sie können zusätzlich beispielhaft eine Zeitdauer angeben, die die mögliche Zeit/den möglichen Zeitablauf einer Eingangswertänderung angibt. Beispielhaft geben die Systemeingangs-Informationsdaten 404 von 7 den Parameter ”driver_pedal_event” an, der in den Anlagencodedaten 414 von 14 als Systemeingangsvariable verwendet werden kann, die während der Softwareüberprüfung verändert werden soll. Die Dauer der Veränderungszeit des Systemeingangs-Variablenparameters wird beispielhaft auf 1000 gesetzt (in Einheiten von ms, d. h. und z. B. kann die Funktion software_execution_1ms() der Steuersoftware-Codedaten 402 entsprechend einer Zykluszeit von 1 ms 1000 Mal aufgerufen werden).
8 zeigt beispielhaft Überprüfungsanforderungs-Informationsdaten 405. Das spezifische Format der Überprüfungsanforderungs-Informationsdaten 405 ist nicht begrenzt. Die in den Überprüfungsanforderungs-Informationsdaten 405 angegeben Informationen können bei der Erzeugung von Durchsetzungsmodul-Codedaten 419 verwendet werden.
Die Überprüfungsanforderungs-Informationsdaten 405 von 8 geben beispielhaft eine Überprüfungszeit des Softwaretestens an und die Überprüfungszeit wird beispielhaft auf 5000 ms gesetzt (d. h. die Funktion software_execution_1ms() der Steuersoftware-Codedaten 402 entsprechend einer Zykluszeit von 1 ms kann 5000 Mal während der Überprüfung aufgerufen werden).
Außerdem geben die Überprüfungsanforderungs-Informationsdaten 405 von 8 beispielhaft eine Überprüfungsanforderung (Überprüfungsbedingung) an, die einer Bedingung entspricht, die einen Steuerfehler darstellt. Die Überprüfungsanforderung ist beispielsweise als Bedingung definiert, unter der ein unbeabsichtigtes Bremsen auftreten würde. Mit anderen Worten, die Informationen 405 werden verwendet, um zu prüfen, ob ein unbeabsichtigtes Bremsen im System auftritt oder nicht. Insbesondere wird geprüft, ob der Fahrer das Bremspedal nicht tritt (der Parameter pedal_event gleich 0 ist) für mindestens 500 ms (der Parameter pedal_off_time größer als oder gleich 500 ist), während der Parameter brake_force seit dem letzten Aufruf der Funktion plant_update()zunimmt (der Parameter brake_force_in-crease ist größer als 0).
Es ist zu beachten, dass die obigen Parameter pedal_off_time und brake_force_increase nicht in der Funktion software_execution_1ms() der Steuersoftware-Codedaten 402 oder der Funktion plant_update() der Anlagencodedaten 414 gezeigt sind. Diese Parameter geben jedoch Informationen oder eine Informationsänderung zwischen mehreren Aufrufen der Funktionen software_execution_1ms() der Steuersoftware-Codedaten oder der Funktion plant_update() der Anlagencodedaten während des Überprüfungsprozesses an.
Der Parameter pedal_off_time kann beispielsweise durch einen Zähler dargestellt werden, der das Zählen einleitet, nachdem ein Loslassen des Bremspedals angegeben wird, indem der Parameter pedal_event von 1 auf 0 umschaltet. Der Parameter brake_force_increase gibt das Ausmaß der Änderung des berechneten Werts des Parameters brake_force an, der durch die Ausführung der Funktion plant_update() der Anlagencodedaten 414 bei einer aktuellen Iteration bestimmt wird, im Vergleich zum letzten Aufruf der Funktion plant_update(), wobei ein positiver Wert eine Erhöhung der berechneten Bremskraft angeben kann und ein negativer Wert eine Verringerung der berechneten Bremskraft angeben kann. Mit anderen Worten, brake_force_increase kann das Ausmaß der Bremskraftlücke zwischen der vorherigen Bremskraft zu einer spezifischen Zeit vorher (z. B. 100 Mikrosekunden) und einer aktuellen Bremskraft angeben.
Die Zeitauflösung kann von der diskreten Zeit des gesteuerten Systems/der gesteuerten Anlage abhängen. Typischerweise ist die Zeitauflösung der Anlagensimulation kleiner als die Zykluszeit der elektronischen Steuereinheiten (d. h. die Häufigkeit des Aufrufs der Anlagensimulation kann größer sein als die Häufigkeit des Aufrufs der Steuersoftware-Codedatenfunktionen der elektronischen Steuereinheiten).
Nachdem die Eingangsinformationsdaten 402–405 des Systemmodellgenerators 8 beschrieben wurden, wendet sich die Beschreibung nun den spezifischen Modulen/Werkzeugen/Einheiten zu, die für die Erzeugung der Anlagencodedaten 414 vorgesehen sind. Die Modellvereinfachungseinheit 5, die Modelltransformationseinheit 6 und der Codegenerator 7 sind dazu konfiguriert, die nachstehend beschriebenen Aufgaben zu erfüllen. Vorzugsweise sind die Einheiten 5, 6 und 7 ein Softwarecode/Programme, die angesichts ihrer Aufgaben konfiguriert sind und die von den Aufgaben verlangten Funktionen umfassen.
Wie 2 zeigt, empfängt die Modellvereinfachungseinheit 5 ein Bondgraphen-Anlagenmodell 401 des gesteuerten Systems zum Erzeugen eines vereinfachten Bondgraphen-Anlagenmodells 401. Es wird jedoch hier erwähnt, dass der Schritt der Vereinfachung des Bondgraphen-Anlagenmodells 401 übersprungen werden kann, wenn eine direkte Transformation in das Signalfluss-Anlagenmodell 413 möglich ist. Daher kann die Modellvereinfachungseinheit 5 ein optionaler Teil des Überprüfungssystems 1 sein.
Bezugnehmend auf die Beschreibung der Modellvereinfachungseinheit 5 zeigt 9 eine Ersatztabelle 406, von der eine oder mehrere z. B. im Speicher 4 gespeichert sein können. Das spezifische Format ist nicht begrenzt. Die Ersatztabelle 406 speichert Ersatzinformationsdaten wie z. B. Ersatzmuster für Objekte, Anschlüsse und dergleichen. Die Ersatztabelle 406 bzw. ihre Informationen werden von der Modellvereinfachungseinheit 5 zum Ersetzen von Objekten des Bondgraphenmodells 401 durch vereinfachte Objekte verwendet. Das Ersetzen kann daher auf der Basis der Ersatzinformationsdaten, die in der Ersatztabelle 406 gespeichert sind, in einer sehr automatisierten Weise ausgeführt werden und der Benutzer muss keine Kenntnis über die Details des Modellvereinfachungsprozesses haben. 9 zeigt beispielsweise beispielhaft ein erstes ”Ersatzmuster 1”. Das Ersatzmuster gibt an, dass die Objekte ”Fortbewegte_Masse” und ”Kraft_Sensor” (siehe Modell 401 von 4) entfernt werden sollten und dass ein vereinfachtes Objekt ”Einfache_Masse” anstelle der entfernten Objekte hinzugefügt werden sollte. Mit anderen Worten, das Ersatzmuster von 9 legt fest, dass die Objekte ”Fortbewegte_Masse” und ”Kraft_Sensor” durch das vereinfachte Objekt ”Einfache Masse” ersetzt werden sollen.
Ferner ist angegeben: ”Konstante (maximaler fric_value -> kinem_valu und stict_value)”. Dies beschreibt eine spezifische Prozedur für die Anlagenverhaltensnäherung. Beispielsweise bedeutet es, dass der maximale Wert des Parameters oder der Variable ”fric_value” des Objekts ”Fortbewegte_Masse” oder ”Kraft_Sensor” auf ”kinem_value” und ”stict_value” als konstanter Wert kopiert werden sollte. Dadurch kann das Verhalten der Anlage/des gesteuerten Systems durch das vereinfachte Bondgraphen-Anlagenmodell 410 genähert/simuliert werden.
Wenn man sich 10 zuwendet, kann es ferner erforderlich sein, während des Vereinfachungsprozesses, der von der Modellvereinfachungseinheit 5 ausgeführt wird, dass die Objektanschlüsse, z. B. ”P1, P2, P3”, die in Verbindung mit 4 beschrieben wurden, auch umgesetzt werden. Aus diesem Grund kann z. B. der Speicher 4 eine oder mehrere Anschlussumsetzungstabellen 407 umfassen, die Anschlussumsetzungs-Informationsdaten speichern, die Anschlussumsetzungsregeln umfassen. Das spezifische Format der Tabelle/Daten von 10 ist nicht begrenzt. Die Anschlussumsetzungstabelle 407 wird von der Modellvereinfachungseinheit 5 zum (Umordnen) Anordnen von Anschlüssen von Objekten und ihren Verbindungen während der/für die Vereinfachung des Bondgraphenmodells 401 verwendet.
Beispielhaft zeigt 10 zwei Umsetzungs-/Umwandlungsregeln 1, 2. Die Regel 1 definiert ”Fortbewegte_Masse, P2, Einfache_Masse, P1”, was bedeutet, dass der Anschluss ”P1” des vereinfachten Objekts ”Einfache_Masse” mit einem Anschluss des Objekts anstelle des Anschlusses ”P2” des Objekts ”Fortbewegte_Masse” verbunden werden sollte. Mit anderen Worten, die Regel erfordert, dass der Anschluss ”P1” von ”Einfache_Masse” den Anschluss ”P2” von ”Fortbewegte_Masse” im Hinblick auf die Verbindung mit dem Anschluss ”P1” des Objekts ”Feder” ersetzen sollte. Entsprechend bedeutet der Befehl ”Kraft_Sensor, P3, Einfache_Masse, P2”, dass der Anschluss ”P3” des Objekts ”Kraft-Sensor” mit einem Anschluss des Objekts anstelle des Anschlusses ”P2” von ”Einfache Masse” verbunden werden sollte (hier: mit dem Anschluss ”P1” der ”Feder” von 11).
Eine weitere Eingabe in die Modellvereinfachungseinheit 5 kann durch die Bondgraphen-Objektbibliothek 408 geliefert werden, die vordefinierte Objekte, vorzugsweise vereinfachte Objekte der Bondgraphendarstellung umfassen kann, und die Simulationsergebnisdaten 409, wie in 2 gezeigt. Die Bondgraphen-Objektbibliothek 408 kann vordefinierte (vorher gespeicherte) vereinfachte Objekte umfassen, die durch die Modellvereinfachungseinheit 5 automatisch ausgewählt werden können, wenn das Modell vereinfacht wird. Dies ist ein anderer Grund dafür, dass die Vereinfachung in einer sehr automatisierten Weise ausgeführt werden kann und dass der Benutzer nicht die Kenntnis über (die Details der) die Modellvereinfachung haben muss. Die Simulationsergebnisse können Ergebnisse einer Simulation der Anlage enthalten, die verwendet werden, um zu prüfen, ob das Anlagenmodell genau modelliert wurde, z. B. im Vergleich zu realen Test-/Versuchsergebnissen. Wenn die Simulationsergebnisse eine Abweichung von Ergebnissen von realen Tests/Versuchen umfassen sollten, kann entschieden werden, eine andere Bibliothek von Objekten zum Modellieren der Anlage zu verwenden, oder es kann entschieden werden, einen anderen Parameterwert für den kompatiblen Konfigurationsparameter zu verwenden, der das Verhalten genauer widerspiegeln kann.
Nach der Vereinfachung des Bondgraphen-Anlagenmodells 401 durch die Modellvereinfachungseinheit 5 kann das vereinfachte Bondgraphen-Anlagenmodell 410 wie das in 11 gezeigte beispielhafte aussehen. Nach dem vorstehend beschriebenen Ersetzen von Objekten (insbesondere ersetzte hier das vereinfachte Objekt ”Einfache_Masse” die Objekte ”Fortbewegte_Masse” und ”Kraft_Sensor”) gemäß den Regeln des Ersatzmusters der Ersatztabelle 406 und nach der Umsetzung von Anschlüssen gemäß den Regeln der Anschlussumsetzungstabelle 407 (insbesondere wurden hier die Anschlüsse ”P1” und ”P2” der ”Einfachen Masse” mit den Anschlüssen ”P1” und ”P2” von zwei verschiedenen Objekten ”Feder” verbunden), umfasst das Beispiel eines vereinfachten Bondgraphen-Anlagenmodells 410 von 11 einen Eingangs- und einen Ausgangsblock. Zwischen den zwei Blöcken sind zwei ”Feder-”Objekte angeordnet und dazwischen wurde das vereinfachte Objekt ”Einfache_Masse” hinzugefügt, das mit den ”Feder”-Objekten über die Anschlüsse ”P1” und ”P2” verbunden ist.
Nachdem das vereinfachte Bondgraphenmodell 410 erzeugt wurde, transformiert die Modelltransformationseinheit 6 das vereinfachte Bondgraphenmodell 410 in das Signalfluss-Anlagenmodell 413, wie beispielhaft durch 13 gezeigt. Daher empfängt die Modelltransformationseinheit 6 eine Eingabe vom Verzeichnis 411 physikalischer Werte (das z. B. im Speicher 4 gespeichert sein kann), die Signalfluss-Graphenobjekt/Komponenten-Bibliothek 412 (die z. B. im Speicher 4 gespeichert sein kann) und sie empfängt das vereinfachte Bondgraphenmodell 410. Auf der Basis dieser Eingabe baut die Modelltransformationseinheit 6 das Signalfluss-Anlagenmodell 413 auf. Im Vergleich zum technischen Vorteil der Bereitstellung der Ersatztabelle 406 und der vereinfachten Bondgraphen-Objektbibliothek 408 muss der Benutzer ebenso nicht am Ersatz/an der Auswahl der Objekte auf Signalflussbasis beteiligt sein, da die relevanten Informationen von der Signalfluss-Graphenobjekt/Komponenten-Bibliothek 412 in einer automatisierten Weise bereitgestellt werden/empfangbar sein können.
Insbesondere zeigt 12 beispielhaft ein Verzeichnis 411 physikalischer Werte, wobei die Form nicht auf die gezeigte begrenzt ist. Das Verzeichnis 411 physikalischer Werte speichert Informationsdaten von physikalischen Werten über die Bedeutung eines physikalischen Werts oder über mehrere physikalische Werte. In dem gezeigten Beispiel umfasst das Verzeichnis 411 physikalischer Werte aus Beispielgründen nur den Begriff ”Geschwindigkeit”, der den vollständigen Namen des physikalischen Werts darstellt. Die weiteren aufgelisteten Begriffe ”vel1”, ”velocity1” und ”v1” sind Namen von potentiellen Kandidaten, die im Anlagenmodell verwendet werden können. Das Verzeichnis 411 physikalischer Werte gibt daher an, dass sie alle angegeben sind oder dass ihre Namen alle ”Geschwindigkeit” bedeuten.
In Verbindung mit 13 wird es noch klarer, welche weiteren physikalischen Werte im Verzeichnis 411 physikalischer Werte aufgelistet sein können, z. B. ”Kraft”, ”Verlagerung” usw. Die Modelltransformationseinheit 6 kann folglich das Verzeichnis 411 physikalischer Werte verwenden, um die Begriffe von physikalischen Werten im Anlagenmodell zu finden, die Begriffen von physikalischen Werten entsprechen, die für das Signalfluss-Anlagenmodell 413 erforderlich sind/damit verwendet werden.
13 zeigt auch, dass die vereinfachten Objekte des vereinfachten Bondgraphenmodells 410 durch die Modelltransformationseinheit 6 durch entsprechende Komponenten (oder Objekte des Signalfluss-Anlagenmodells) ersetzt wurden, die zum Aufbauen des Signalfluss-Anlagenmodells 413 verwendbar sind. Die Modelltransformationseinheit 6 ersetzte beispielsweise die (vereinfachten) Objekte ”Feder” und ”Einfache_Masse” unter Zurateziehen der Signalfluss-Graphenobjekt/Komponenten-Bibliothek 412 durch die jeweiligen Signalflussmodell-Komponenten (oder Untersysteme) ”Feder” und ”Masse”, die dazu ausgelegt sind, Signale zu empfangen. Die erste ”Feder”-Komponente, die mit dem Eingangsblock von 13 verbunden gezeigt ist, empfängt z. B. über den Anschluss ”P2_vel2” eine Geschwindigkeit Nr. 2 und kann über den Anschluss ”P1_force1” eine Kraft Nr. 1 ausgeben. Die ”Feder”-Komponenten weisen vier Anschlüsse auf, zwei für die Geschwindigkeit (Vel1, Vel2) und zwei für Kräfte (force1, force2). Ferner weist die ”Masse”-Komponente zwei Anschlüsse auf, jeweils für Kraft, Beschleunigung (accel1,2) und Verlagerung (disp1,2).
Falls erforderlich, kann die Modelltransformationseinheit 6 verbunden sein oder eine Eingabe von einer optionalen Signalfluss-Anschlussumsetzungstabelle empfangen, die nicht gezeigt ist, die Regeln zum Verbinden von Anschlüssen von Komponenten bereitstellt, wenn die vereinfachten Bondgraphen-Anlagenmodellobjekte durch die Signalfluss-Anlagenmodell-Komponenten ersetzt werden. Diese Regeln können vorzugsweise auch in der Signalfluss-Graphenobjekt/Komponenten-Bibliothek 412 definiert/enthalten sein.
Zusammenfassend zeigt 13 ein Beispiel eines Signalfluss-Anlagenmodells 413, das im vorliegenden Beispielfall des gesteuerten Systems von 3 einen input_brake_control_command empfangen kann und eine output_mass_displacement ausgibt.
Wie bereits vorstehend beschrieben, zeigt 14 die Anlagencodedaten 414, die durch den Codegenerator 7 erzeugt werden. Der Codegenerator 7 empfängt das Signalfluss-Anlagenmodell 413 und erzeugt den jeweiligen Quellencode auf dessen Basis, d. h. Anlagencodedaten 414. Die Anlagencodedaten 414 werden dann an den Systemmodellgenerator 8 übergeben/in diesen eingegeben.
15 zeigt beispielhaft einen Teil der Zusammenarbeitsmodul-Codedaten 417 auf der Basis der Zusammenarbeits-Informationsdaten 403 von 6. Im Allgemeinen arbeiten die Zusammenarbeitsmodul-Codedaten 417 (oder Zusammenarbeitsmodul(e)) für die Datensynchronisation zwischen der Steuersoftware und dem Anlagenmodell. Die Zusammenarbeitsmodul-Codedaten 417 können z. B. Sensordaten, die ein aktuelles Anlagenverhalten zeigen, von der Anlagenseite zur Softwareseite kopieren. In derselben Weise können die Zusammenarbeitsmodul-Codedaten 417 einen Steuerbefehl, der die Angabe für Steueraktuatoren zeigt, von der Softwareseite zur Anlagenseite kopieren. Die Zusammenarbeitsmodul-Codedaten 417 können beispielsweise manuell erzeugt werden oder vorzugsweise werden die Zusammenarbeitsmodul-Codedaten automatisch durch einen Codegenerator auf der Basis der Zusammenarbeits-Informationsdaten 403 von 6 erzeugt.
Wenn mehr als eine ECU im System vorhanden ist, kann ein (können) (zusätzliche(s) und/oder spezifische(s)) Zusammenarbeitsmodul(e) für ECUs erforderlich sein.
Die Zusammenarbeitsmodul-Codedaten 417 umfassen eine oder mehrere Funktionen zum Kopieren von einem oder mehreren Ausgangsparametern auf einen oder mehrere Eingangsparameter. Insbesondere umfassen die Zusammenarbeitsmodul-Codedaten eine oder mehrere Funktionen zum Kopieren von einem oder mehreren Ausgangsparametern von einer oder mehreren elektronischen Steuereinheiten auf einen oder mehrere Eingangsparameter der Simulation des gesteuerten Systems/der gesteuerten Anlage, eine oder mehrere Funktionen zum Kopieren von einem oder mehreren Ausgangsparametern von einer oder mehreren elektronischen Steuereinheiten auf einen oder mehrere Eingangsparameter von einer oder mehreren elektronischen Steuereinheiten und/oder eine oder mehrere Funktionen zum Kopieren von einem oder mehreren Ausgangsparametern der Simulation des gesteuerten Systems/der gesteuerten Anlage auf eine oder mehrere elektronische Steuereinheiten.
Hier umfassen die Zusammenarbeitsmodul-Codedaten von 15 beispielhaft eine Definition für zwei Funktionen copy_software_to_plant() und copy_plant_to_software(). Wie vorstehend erwähnt, falls mehr als eine ECU vorgesehen ist, kann eine weitere Funktion ”copy_ECU_to_ECU() sein. Die Funktion copy_software_to_plant() bewirkt, dass die Ausgangsparameter der Funktion der Steuersoftware-Codedaten 402 der BCU 4021 Eingangsparametern der Simulation des gesteuerten Systems/der gesteuerten Anlage gemäß der Zuordnung zugeordnet werden, wie in den Zusammenarbeits-Informationsdaten 403 unter ”Software zu Anlage” angegeben.
Die Funktion copy_plant_to_software() bewirkt, dass die Ausgangsparameter der Simulation des gesteuerten Systems/der gesteuerten Anlage zu den zugehörigen Eingangsparametern der Funktion der Steuersoftware-Codedaten 402 der BCU 4021 gemäß der Zuordnung, wie in den Zusammenarbeits-Informationsdaten 403 unter ”Anlage zu Software” angegeben.
Eine mögliche (dritte) Funktion copy_ECU_to_ECU kann bewirken, dass die Ausgangsparameter der Funktion der Steuersoftware-Codedaten der ersten ECU zu dem zugehörigen Eingangsparameter der Funktion der Steuersoftware-Codedaten einer zweiten ECU gemäß der Zuordnung, wie in den möglichen Zusammenarbeits-Informationsdaten 403 z. B. unter ”ECU zu ECU” angegeben (nicht gezeigt).
Zusammenfassend arbeiten die Zusammenarbeitsmodul-Codedaten für die Datensynchronisation zwischen der Steuersoftware der elektronischen Steuereinheiten und dem gesteuerten System/der gesteuerten Anlage. Die Zusammenarbeitsmodul-Codedaten 417 definieren ausführbare Funktionen zum Kopieren von Sensordaten und Sensorwerten, die das Verhalten des gesteuerten Systems/der gesteuerten Anlage angeben, von der Anlagenseite zur Steuersoftwareseite und ausführbare Funktionen zum Kopieren von Steuerbefehlen, die eine Befehlsausgabe an Aktuatoren des gesteuerten Systems/der gesteuerten Angabe angeben, von der Steuersoftwareseite zur Anlagenseite.
In Systemen, die mehr als eine elektronische Steuereinheit aufweisen, können die Zusammenarbeitsmodul-Codedaten ferner ausführbare Funktionen zum Kopieren von Steuerausgangsparametern von einer elektronischen Steuereinheit auf die entsprechenden Eingangsparameter einer anderen elektronischen Steuereinheit des Systems definieren.
16 zeigt beispielhaft einen Teil der Codedaten 418 des symbolischen Moduls auf der Basis der Systemeingangsinformationsdaten 404 von 7. Beispielhaft werden die Codedaten des symbolischen Moduls von 16 in einem Format für das Überprüfungswerkzeug auf der Basis der symbolischen KLEE-Ausführung formuliert und definieren eine Funktion symbolic_module() beispielhaft auf der Basis einer Syntax, die für das Überprüfungswerkzeug auf der Basis der symbolischen KLEE-Ausführung erforderlich ist, wobei von den Befehlen klee_make_symbolic Gebrauch gemacht wird.
Insbesondere wird die Funktion symbolic_module() auf der Basis der Systemeingangs-Informationsdaten von 7 erzeugt und befiehlt dem Überprüfungswerkzeug 9 auf der Basis der symbolischen Ausführung, die symbolische Variable X für den Parameter driver_pedal_event zu verwenden, die in den Systemeingangs-Informationsdaten 404 von 7 identifiziert ist, und transformiert den Parameter driver_pedal_event in X.
Auf der Basis der Zeit 1000, die in den Systemeingangs-Informationsdaten 404 angegeben ist, wird die Funktion klee_make_symbolic nur aufgerufen, wenn der Zeitzählparameter v_time gleich 0 modulo 1000 ist, d. h. falls v_time ein ganzzahliges Vielfaches von 1000 ist. Folglich wird die symbolische Transformation alle 1000 ms durchgeführt, wie beispielhaft in den Systemeingangs-Informationsdaten 404 definiert.
Im Allgemeinen transformieren die Codedaten 418 des symbolischen Moduls die Systemeingabe in abstrakte Symbole wie z. B. X und Y oder dergleichen zur Vorbereitung auf die Überprüfung auf der Basis der symbolischen Ausführung der Steuersoftware. Dies hat den Vorteil, dass die Softwareüberprüfung nicht durch verschiedene Logikpfade mit verschiedenen numerisch festgelegten Werten laufen muss, sondern die möglichen Pfade unter Verwendung von abstrakten Variablen testen und überprüfen kann, die mehrere Situationen in einer abstrakten Weise auf der Basis der Pfadbedingungen abdecken kann. Dies ist ein Hauptvorteil des hier beschriebenen Systems und Verfahrens sowie der automatischen Erzeugung der Simulations-Anlagencodedaten 414 auf der Basis des Signalfluss-Anlagenmodells.
17 zeigt beispielhaft einen Teil von Durchsetzungsmodul-Codedaten 419 auf der Basis der Überprüfungsanforderungsdaten 405 von 8. Die Durchsetzungsmodul-Codedaten 419 liefern eine ausführbare Funktion assertion_module((), die einen Falls-Satz umfasst, der prüft, ob die Überprüfungsanforderungsbedingung erfüllt ist, und wenn sie erfüllt ist, wird die Funktion klee_assert(0) ausgeführt und meldet ein Auftreten eines Fehlers/Defekts an den Benutzer, um den Benutzer zu informieren, dass eine Pfadbedingung gefunden wurde, die ermöglicht, dass das System in einen Zustand gelangt, der eine unbeabsichtigte Überprüfungsanforderungsbedingung erfüllt. Die Ausgabe an den Benutzer gibt vorzugsweise die Pfadbedingung (d. h. die Bedingungen für die Systemeingangsvariablen, um von anfänglichen Bedingungen in die Situation zu gelangen, in der die Überprüfungsbedingung erfüllt ist) aus.
Die Funktion klee_assert() ist eine spezifische Funktion des Überprüfungswerkzeugs KLEE auf der Basis der symbolischen Ausführung, aber die vorliegende Erfindung ist nicht auf die Verwendung dieses Überprüfungswerkzeugs auf der Basis der symbolischen Ausführung begrenzt und andere Überprüfungswerkzeuge auf der Basis der symbolischen Ausführung können verwendet werden. Im Allgemeinen können die Durchsetzungsmodul-Codedaten 419 eine oder mehrere ausführbare Funktionen zum Prüfen von einer oder mehreren Überprüfungsanforderungsbedingungen aufweisen, und wenn festgestellt wird, dass eine der Überprüfungsanforderungsbedingungen erfüllt ist, wird der Benutzer über die Detektion einer fehlerhaften Steuerbedingung benachrichtigt, z. B. wenn die Sicherheitssystemspezifikation verletzt wird, wenn die Überprüfungsbedingung erfüllt ist.
Die Falls-Satz-Bedingung in der Funktion assertion_module() der Durchsetzungsmodul-Codedaten 419 von 17 wird auf der Basis der Überprüfungsanforderungs-Informationen der Überprüfungsanforderungs-Informationsdaten 405 von 8 erzeugt. Beispielsweise kann sie manuell oder automatisch erzeugt werden, z. B. durch einen Codegenerator auf der Basis der bereitgestellten Überprüfungsanforderungs-Informationsdaten 405.
18 zeigt beispielhaft einen Teil von Synchronisationsmodul-Codedaten 420. Die Synchronisationsmodul-Codedaten 420 definieren eine Funktion main(), die die jeweilige Steuersoftware und Simulationssoftware zu den geeigneten Zeitpunkten aufruft, z. B. gemäß Softwarequellencodes, Steuersoftware-Codedaten 402, Anlagencodedaten 414 oder den eingegebenen Informationen.
Beispielhaft führt die Funktion main() einen Zählschleifen-Iterationsprozess für den Parameter v_time durch, der eine Zeit des Überprüfungsprozesses angibt und iteriert (inkrementiert) wird, beispielsweise beginnend von einem Anfangswert v_time = 0 bis zum Maximalwert MAX. Die Iteration des Parameters v_time kann beispielsweise den Iterationsschritten von jeweils 1 ms gemäß der Zykluszeit der obigen BCU 4021 entsprechen. Der Parameter v_time kann auch durch verschiedene Einheiten entsprechend einer Zeitdauer iteriert werden, die kleiner oder größer als 1 ms ist.
Für jede Iteration des Iterationsprozesses, d. h. für jeden Überprüfungszeitschritt in der Iteration der Inkrementierung des Zeitparameters v_time, werden die verschiedenen Funktionen der anderen Module der Codedaten für die Steuersoftware der elektronischen Steuereinheiten und die Simulation des gesteuerten Systems/der gesteuerten Anlage, die vorstehend erwähnt sind, aufgerufen.
Zuerst wird die ausführbare Funktion symbolic_module() der Codedaten 418 des symbolischen Moduls ausgeführt, um eine symbolische Ausführung durch Übertragen der Systemeingangsparameter auf die entsprechenden abstrakten Symbole für die symbolische Ausführung einzuleiten, zumindest wenn die Zeitbedingung v_time % 1000 == 0 der Codedaten 418 des symbolischen Moduls erfüllt ist, d. h. wenn der Parameter v_time ein ganzzahliges Vielfaches von 1000 ist.
Die Synchronisationsmodul-Codedaten 420 fassen die Steuerfunktionen der elektronischen Steuereinheiten durch Vorsehen einer ausführbaren Funktion software_execution zusammen, die die Funktionen BCU_software_execution_1ms() und (die nicht weiter beschriebene Funktion einer möglichen zweiten ECU) ESC_software_execution_1ms() (innerhalb der Falls-Sätze) beispielhaft nur aufruft, wenn der Parameter v_time %1 == 0, d. h. wenn der Parameter v_time ein ganzzahliges Vielfaches von 1 ist. Hier ermöglicht dies das Vorsehen einer Synchronisation zum Aufrufen der Steuerfunktionen der elektronischen Steuereinheiten. Und die Funktionen von verschiedenen elektronischen Steuerfunktionen können zu verschiedenen Zeitpunkten und/oder mit verschiedenen Häufigkeiten und auch zu verschiedenen Zeitpunkten und/oder mit verschiedenen Häufigkeiten im Vergleich zur Simulation des gesteuerten Systems/der gesteuerten Anlage aufgerufen werden.
In der Hauptfunktion der Durchsetzungsmodul-Codedaten 419 nach dem Aufruf des symbolischen Moduls (symbolic_module) für die symbolische Ausführung wird ein Steuerzyklus durch Durchführen der Schritte der Aktualisierung des aktuellen Zustandes des gesteuerten Systems/Modells durch Aufrufen der Funktion plant_update() der Anlagencodedaten 414, Übertragen der Ausgangswerte der Simulation des gesteuerten Systems gemäß dem aktualisierten Zustand auf die zugehörigen Eingangsparameter der Steuersoftware der elektronischen Steuereinheiten in den Steuersoftware-Codedaten durch Aufrufen der Funktion copy_plant_to_software() der Zusammenarbeitsmodul-Codedaten 417, Durchführen eines Steuerzyklus der elektronischen Steuereinheiten durch Aufrufen der vorstehend erwähnten Funktion software_execution als Funktion des Zeitparameters v_time dieser Iteration und Übertragen der Ausgangswerte der Simulation des Steuerzyklus der elektronischen Steuereinheiten auf die zugehörigen Eingangsparameter der Steuersoftware der anderen elektronischen Steuereinheiten in den Steuersoftware-Codedaten durch Aufrufen der Funktion copy_ECU_to_ECU() (z. B. wenn mehr als eine ECU vorhanden ist) der Zusammenarbeitsmodul-Codedaten 417 und auf die zugehörigen Eingangsparameter der Simulation des gesteuerten Systems/der gesteuerten Anlage durch Aufrufen der Funktion copy_software_to_plant() der Zusammenarbeits-Moduldaten 417 simuliert.
Dann wird (werden) der (die) Zähler durch pedal_off_time++ inkrementiert, um anzugeben, dass der Zeitparameter um eine Einheit inkrementiert wurde. Im vorliegenden Beispiel inkrementiert dies den Zähler pedal_off_time.
Dann wird die Funktion assertion_module() aufgerufen, um eine Prüfung durchzuführen, ob die Überprüfungsanforderungsbedingung zum Zeitpunkt v_time der aktuellen Iteration erfüllt ist, bevor zur nächsten Iteration gegangen wird.
19 zeigt beispielhaft eine Konfiguration des Systemmodells (Systemmodell-Codedaten) 415. Die Systemmodell-Codedaten 415 umfassen die Steuersoftware-Codedaten 402 der elektronischen Steuereinheit(en) (hier ist die BCU 4021 gezeigt), die Anlagencodedaten 414 des gesteuerten Systems/der gesteuerten Anlage, die Zusammenarbeitsmodul-Codedaten 417, die Codedaten 418 des symbolischen Moduls, die Durchsetzungsmodul-Codedaten 419 und die Synchronisationsmodul-Codedaten 420.
Das hier beschriebene Systemmodell kann vorzugsweise und vorteilhafterweise ein Kommunikationsmodul zur Datensynchronisation und ein Synchronisationsmodul zur Zeitsynchronisation zwischen den Modulen des Systemmoduls beinhalten. Die Datensynchronisation kann interne Systemwechselwirkungen zwischen der Steuersoftware und der Anlage durchführen. Daher kann das Kommunikationsmodul den aktuellen Steuerbefehl, den die Steuersoftware für die Aktuatorsteuerung berechnet, in den Anlageneingang kopieren, der eine Ausgabe vom Controllermodell empfängt. Das Modul kann auch den aktuellen Sensorwert, der das gemessene Anlagenverhalten angibt, in den Steuersoftwareeingang kopieren, der die Ausgabe vom Anlagenmodell empfängt. Die Wechselwirkung zwischen den ECUs kann durch das Modul ebenso unterstützt werden. Das Synchronisationsmodul kann den aktuellen Zustand der Steuersoftware und der Anlage durch sequentiellen und iterativen Aufruf zum geeigneten Zeitpunkt beibehalten. Außerdem kann das Modul die Überprüfungszeit in der internen Systemzeit begrenzen, um begrenzte Zustandsübergänge durchzuführen. Grundsätzlich kann ein Steuersystem Steuerschleifen durch periodisches Aktualisieren der Steuersoftware beibehalten und muss abgesehen von Leistungsversorgungsereignissen nicht enden. Folglich können die Benutzer der vorgeschlagenen Überprüfungsplattform die begrenzte Zeit bestimmen müssen, um Überprüfungsergebnisse in einigen Aspekten zu erhalten. Die begrenzte Zeit kann von der Eigenschaft des Zielsystems abhängen. Wenn beispielsweise Benutzer den Systemeffekt sehen wollen, der durch die Kombination von Zeitablauf oder Sequenz von veränderten Systemeingaben verursacht wird, sollte die begrenzte Zeit vorzugsweise definiert sein, um sie zu berücksichtigen. Für die formale Überprüfung auf der Basis der symbolischen Ausführung können auch Symboldefinitionsmodule und Durchsetzungsmodule im Systemmodell vorgesehen sein. Das symbolische Definitionsmodul kann Systemeingaben wie z. B. Benutzeroperationen oder Ereignisse von der Umgebung des Überprüfungsziels, die sich auf das Anlagenverhalten auswirken, als Symbole definieren. Um den Wert der Systemeingaben während der Überprüfung zu ändern, kann das Modul sie erneut definieren. Da die erneute Definition neue Symbole erzeugt, nimmt jedoch die Überprüfungszeit zu. Insbesondere nimmt die Ausführungszeit des Lösers in Abhängigkeit von der Anzahl von Symbolen zu. Um die häufige erneute Definition zu vermeiden, kann die erneute Definition unter Verwendung von Verzweigungsbefehlen gemäß einem spezifischen Zeitablauf wie z. B. jede 1 Sekunde, einem Ereignisauslöser und so weiter bereitgestellt werden. Es kann jedoch eine ungeheure Überprüfungszeit aufgrund der exponentiellen Zunahme der Anzahl der möglichen Pfade verursachen. Folglich ist die Entscheidung einer optimalen Neudefinitionshäufigkeit für die Steuersystemüberprüfung wichtig. Da das Systemmodell sein Anlagenverhalten in jeder Diskretisierungszeit aktualisiert, kann außerdem die Entscheidung der optimalen Diskretisierungszeit ebenso wichtig werden. Die Diskretisierungszeit sollte vorzugsweise auf der Basis eines Abtasttheorems bestimmt werden. Das Durchsetzungsmodul, das ein Durchsetzungscode sein kann, kann die Eigenschaft des Steuersystems durch Überwachen von fokussierenden Variablen des Systemmodells prüfen.
20 zeigt beispielhaft eine Anzeige eines beispielhaften Überprüfungsergebnisses auf der Anzeige 12. Am Ende der Überprüfung der Steuersoftware-Codedaten 402, d. h. am Ende der Überprüfungszeit, wie in den Überprüfungsanforderungs-Informationen 405 definiert, wird das Überprüfungsergebnis gezeigt und das Überprüfungsergebnis gibt die Vorkommnisse der Detektion eines Fehlers an, in dem die Überprüfungsanforderungsbedingung bei einer bestimmten Pfadbedingung erfüllt wurde, die ebenso angegeben wird, wobei die Pfadbedingung die Bedingungen für die Systemeingangsparameter definiert, um in der fehlerhaften Situation des detektierten Fehlers anzukommen. Beispielhaft werden auch die Pfadbedingungen von gültigen Pfaden in der Anzeige von 20 angegeben.
21 zeigt beispielhaft einen Ablaufplan eines Prozesses zur Überprüfung für das Steuersoftwaretesten gemäß einem Aspekt:
Zuerst werden in Schritt S01 die Steuersoftware-Codedaten 402 der einen oder mehreren beteiligten elektronischen Steuereinheiten, das Bondgraphen-Anlagenmodell 401, die Zusammenarbeits-Informationsdaten 403, die Systemeingangsinformationen 404 und die Überprüfungsanforderungs-Informationsdaten 405 bereitgestellt. Das heißt, der Benutzer legt die Quellencodes der elektronischen Steuereinheit(en), das Bondgraphen-Anlagenmodell 401, die Informationen über die Systemstruktur und Beziehungen von Eingaben und Ausgaben, die Informationen über die Systemeingabe, die die Variablen des Überprüfungsprozesses angeben, und Informationen über die zu testende Überprüfungsbedingung fest. Alternativ können einige oder alle der beschriebenen Eingangsinformationen automatisch durch einen verbundenen Computer oder dergleichen bereitgestellt werden.
In Schritt S02 leitet der Benutzer oder ein Computer den Überprüfungsprozess am Überprüfungssystem 1 ein/startet diesen, das den Überprüfungsprozess durchführt. Auf der Basis der bereitgestellten Daten verwendet das Überprüfungssystem 1 den Systemmodellkonstrukteur 8, der dazu ausgelegt ist, das Systemmodell 415 (z. B. 19) auf der Basis der bereitgestellten Daten zu erzeugen.
In Schritt S03 vereinfacht die Modellvereinfachungseinheit 5 (die dazu ausgelegt ist) das eingegebene Bondgraphen-Anlagenmodell 401. Nach der Verarbeitung der Modellvereinfachungseinheit 5 wird das vereinfachte Bondgraphen-Anlagenmodell 410 zur Modelltransformationseinheit 6 geliefert. Diese Einheit 6 transformiert dann das vereinfachte Bondgraphen-Anlagenmodell 410 in das Signalfluss-Anlagenmodell 413 in Schritt 04.
Mehr Details der Unterschritte von Schritt 03 sind durch 22 beispielhaft gezeigt. 22 zeigt den Ablaufplan des Anlagenvereinfachungsprozesses, für dessen Ausführung die Modellvereinfachungseinheit 5 konfiguriert ist. In einem Unterschritt S031 sucht die Anlagenvereinfachungseinheit 5 nach einem Ziel/Objekten, die vereinfacht werden sollen, gemäß Informationen, die von der durch 9 gezeigten Ersatztabelle 406 bereitgestellt werden. Mit anderen Worten, alle Objekte eines Bondgraphen-Anlagenmodells 401, die die Modellvereinfachungseinheit 5 empfängt, werden z. B. mit den Einträgen der Ersatztabelle 406 verglichen, und es wird geprüft, ob ein oder mehrere vereinfachte Objekte statt dessen hinzugefügt werden sollten.
Wenn das eine oder die mehreren Ziele/Objekte gesucht/identifiziert wurden, werden die identifizierten Komponenten (Objekte) in Schritt S032 durch die Anlagenvereinfachungseinheit 5 gemäß der Bereitstellung der Ersatztabelle 406 entfernt.
Danach fügt in Schritt S033 die Anlagenvereinfachungseinheit 5 ein oder mehrere Objekte/Komponenten im Austausch gegen und/oder zusätzlich zu der mindestens einen entfernten Komponenten/Objekten gemäß den Informationen der Ersatztabelle 406 hinzu. Die hinzugefügten Komponenten/Objekte werden durch die Bondgraphen-Objektbibliothek 408 gespeichert und bereitgestellt.
In Schritt S034 verknüpft die Anlagenvereinfachungseinheit 5 die hinzugefügten Komponenten miteinander gemäß den von der Umsetzungstabelle 407 bereitgestellten Informationen, wie durch 10 gezeigt. In Schritt S035 kopiert die Anlagenvereinfachungseinheit 5 (einen) kompatible(n) Konfigurationsparameter wie z. B. das Gewicht des Objekts oder dergleichen von der entfernten Komponente (Objekt) auf die hinzugefügte Komponente.
In Schritt S036 kann die Anlagenvereinfachungseinheit 5 (ein) Simulationsergebnis(se) analysieren und (einen) Konfigurationsparameter zum Nähern des Verhaltens der Anlage gemäß der Ersatztabelle finden. In diesem optionalen Schritt zum Verbessern der Genauigkeit des Modells kann beispielsweise die Anlagenvereinfachungseinheit 5 feststellen, dass der Parameter ”Gewicht” eines Objekts so konfiguriert sein sollte, dass er denselben Wert aufweist, z. B. 100 kg, wie das Objekt des nicht vereinfachten Modells, um genaue Simulationsergebnisse zu erhalten, d. h. um sicherzustellen, dass das physikalische Verhalten des vereinfachten Modells mit dem physikalischen Verhalten des nicht vereinfachten Modells übereinstimmt. Die Simulationsergebnisse zum Vergleichen des physikalischen Verhaltens können als Simulationsergebnisdaten 409 gespeichert werden. Dann erzeugt in Schritt S037 die Anlagenvereinfachungseinheit 5 das durch 11 gezeigte vereinfachte Bondgraphen-Anlagenmodell z. B. indem alle Informationen und Schritte, wie vorstehend erörtert, zusammengebracht werden.
Mehr Details der Unterschritte von Schritt 04 sind beispielhaft durch 23 gezeigt. 23 zeigt den Ablaufplan des Modelltransformationsprozesses, für dessen Ausführung die Modelltransformationseinheit 6 konfiguriert ist.
In Schritt S041 liest die Modelltransformationseinheit 6 zuerst Komponenteninformationen des Eingangsanlagenmodells, das heißt vorzugsweise des vereinfachten Bondgraphen-Anlagenmodells 410. Die Komponenteninformationen können alle relevanten Informationen über die Struktur, Parameter, Konfigurationen usw. des eingegebenen Anlagenmodells umfassen; z. B. kann dies das Lesen, welche Komponenten vorhanden sind, wie sie verknüpft sind, usw. umfassen.
In S042 fügt die Modelltransformationseinheit 6 Signalfluss-Graphenkomponenten hinzu, die den Komponenten im (vereinfachten) Bondgraphen-Anlagenmodell 401/410 entsprechen. Dies kann durch die Modelltransformationseinheit 6 ausgeführt werden, die einen Befehl in ein Programmskript schreibt, um die Komponenten zum Signalfluss-Graphenmodell hinzuzufügen. Informationen über entsprechende Komponenten/Objekte zwischen dem (vereinfachten) Bondgraphen-Anlagenmodell 401/410 und den Gegenstücken für das Signalfluss-Anlagenmodell 413 werden vorzugsweise durch die Signalfluss-Graphenobjektbibliothek 412 bereitgestellt. Diese Bibliothek 412 kann z. B. Datentabellen umfassen, die Bondgraphenobjekte mit Signalfluss-Graphenobjekten verknüpfen, so dass die Modelltransformationseinheit 6 die erforderlichen Informationen darüber empfangen kann, wie Objekte/Komponenten zu ersetzen/hinzuzufügen/zu entfernen sind.
In den Schritten S043 und S044 liest die Modelltransformationseinheit 6 die Anschlussverbindungsbeziehung und Anschlussdateninformationen, die z. B. mitteilen, welche Anschlüsse der Objekte miteinander verbunden sind, und welche Informationen über diese Anschlüsse/Verbindungen übertragen werden. Wie in 11 gezeigt, sind z. B. die Anschlüsse ”P2, P1” zwischen der vereinfachten Masse und der Feder miteinander verbunden. Dies können Verbindungsbeziehungsinformationen sein, die durch die Modelltransformationseinheit 6 in Schritt S043 gelesen werden. Unter der Annahme, dass Kraftinformationen über die Verbindung zwischen diesen Anschlüssen ”P2” und ”P1” übertragen werden, können diese als Anschlussdateninformationen in Schritt S044 gelesen werden.
In Schritt S045 verknüpft die Modelltransformationseinheit 6 (z. B. durch Hinzufügen des jeweiligen Befehls im Programmskript) zum Verknüpfen des jeweiligen Eingangs- und Ausgangsanschlusses (der jeweiligen Eingangs- und Ausgangsanschlüsse) der zu verbindenden Komponenten. Die Anschlüsse leiten/übertragen denselben physikalischen Wert. Die Verknüpfung wird auf der Basis von Informationen durchgeführt, die durch das Verzeichnis 411 physikalischer Werte bereitgestellt werden, wie durch 12 gezeigt. In S046 erzeugt die Modelltransformationseinheit 6 dann das Signalflussgraphen-Anlagenmodell 413. Dies kann durch die Modelltransformationseinheit 6 ausgeführt werden, die das Programmskript aufruft, in dem die jeweiligen Befehle der vorher beschriebenen Schritte für ein Signalflussgraphen-Modellierungswerkzeug enthalten sind. Hier wird angemerkt, dass in derselben Weise die Anlagenvereinfachungseinheit 5 Schritt S037 ausführen kann.
In Schritt 05 erzeugt der Codegenerator 7 die Anlagencodedaten 414 auf der Basis des Signalfluss-Anlagenmodells 413, das von der Modellvereinfachungseinheit 5 bereitgestellt wird.
Die technischen vorteilhaften Effekte der automatischen/halbautomatischen Erzeugung von Anlagensimulations-Quellencodedaten 414 zusammenfassend ermöglicht das Verfahren/System, wie hier beschrieben, eine Rechenlastverringerung, insbesondere da die Anlagenvereinfachungseinheit 5 und die Modelltransformationseinheit 6 (einen) DAE-Löser entfernen, die eine hohe Rechenlast erzeugen. Folglich kann der ganze Prozess der Überprüfung auf der Basis von Anlagensimulations-Quellencodedaten 414 durchgeführt werden, die automatisch erzeugt werden, was weniger Rechenlast verursacht als z. B. Modelldaten auf Bondgraphenbasis mit (einem) Rechenleistung verlangenden DAE-Löser(n) und dergleichen.
In Schritt 06 erzeugt der Systemmodellkonstrukteur 8 das Systemmodell 415 (Systemmodell-Codedaten). Daher verwendet der Systemmodellkonstrukteur 8 Steuersoftware-Codedaten 402 und die Anlagencodedaten 414. Ferner kann er vorzugsweise die Zusammenarbeitsmodul-Codedaten 417 auf der Basis der Zusammenarbeits-Informationsdaten 403, die Codedaten 418 des symbolischen Moduls auf der Basis der Systemeingangs-Informationsdaten 404, die Durchsetzungsmodul-Codedaten 419 auf der Basis der Überprüfungsanforderungs-Informationsdaten 405 und die Synchronisationsmodul-Codedaten 420 gemäß den Steuersoftware-Codedaten 402 der elektronischen Steuereinheiten, den Anlagencodedaten 414 und den Zusammenarbeitsmodul-Codedaten 417 verwenden.
Es wird angemerkt, dass die Reihenfolge der Ausführung des Aufbaus des Systemmodells 415 verändert werden kann oder sie sogar parallel ausgeführt werden kann. Ferner kann das Systemmodell 415 verwendet werden, um ein ausführbares Programm zu erzeugen, das durch die Betriebseinheit 3 des Überprüfungssystems 1 abgearbeitet werden kann. Insbesondere kann, falls das Systemmodell 415 als Systemmodell-Codedaten bereitgestellt wird, ein Kompilierungsschritt durch einen Kompilierer durchgeführt werden, um die Systemmodell-Codedaten für Überprüfungszwecke, z. B. für die symbolische Ausführung, zu kompilieren.
24 zeigt einen Ablaufplan mit Unterschritten des Systemmodell-Erzeugungsprozesses, der durch den Systemmodellgenerator 8 ausgeführt wird. Der Ablaufplan von 24 beschreibt genauer den Prozess von Schritt S06. In Schritt S061 erzeugt der Systemmodellgenerator 8 Zusammenarbeitsmodule/Zusammenarbeitsmodul-Codedaten 417, wie durch 15 gezeigt; in Schritt S062 erzeugt der Systemmodellgenerator 8 symbolische Module/Codedaten 418 der symbolischen Module, wie durch 16 gezeigt. In Schritt S063 erzeugt der Systemmodellgenerator 8 Durchsetzungsmodule/Durchsetzungsmodul-Codedaten 419, wie durch 17 gezeigt. In Schritt S064 erzeugt der Systemmodellgenerator 8 Synchronisationsmodule/Synchronisationsmodul-Codedaten 420, wie durch 18 gezeigt. Dann kompiliert der Systemmodellgenerator 8 in Schritt S065 das Systemmodell 415, wie durch 19 gezeigt.
Im nächsten Schritt S07 führt die Betriebseinheit 3 das ausführbare Programm des Systemmodells 415 (z. B. kompilierte Systemmodell-Codedaten) aus und ruft das Überprüfungswerkzeug 9 auf der Basis der symbolischen Ausführung auf, um durch die symbolische Ausführung zu überprüfen, ob in der Software irgendwelche Ausführungspfade vorliegen, wenn das ausführbare Systemmodellprogramm betrieben wird, um zu einer oder mehreren Bedingungen zu gelangen; die die festgelegte Überprüfungsanforderungsbedingung erfüllen. Wenn eine solche fehlerhafte Situation gefunden wird, wird der entsprechende Fehler an den Benutzer gemeldet und die Pfadbedingung wird angegeben.
In Schritt S08 meldet das Überprüfungswerkzeug 9 auf der Basis der symbolischen Ausführung das (die) Überprüfungsergebnis(se) 416 an den Benutzer z. B. über die Anzeige 12 und in Schritt S09 kann der Benutzer die Überprüfungsergebnisse und die Pfadbedingungen des Pfades des Ausführungsbaums prüfen, der in der Situation ankam, die die festgelegte Überprüfungsanforderung erfüllt.
Der hier beschriebene Prozess/das hier beschriebene System ermöglicht, dass Benutzer Systemfunktionsstörungen in den mechanisch-elektronischen Steuersystemen wie z. B. Kraftfahrzeugsystemen, Konstruktionsmaschinensystemen und so weiter bereits in der Entwurfsphase finden.
Zusammenfassend ermöglicht der beispielhafte Aspekt ein zuverlässiges und effizientes Testen der Steuersoftware von elektronischen Steuereinheiten in gesteuerten Systemen/Anlagen mit einer oder mehreren elektronischen Steuereinheiten (ECU) für ECU-Test oder Systemtests. Dies ermöglicht, dass der Benutzer effizient und zuverlässig Systemdefekte in einem elektronischen mechatronischen Steuersystem wie z. B. Kraftfahrzeugsystemen, Konstruktionsmaschinensystemen oder anderen eingebetteten Systemen und Steuersystemen während der Entwicklungsphase findet. Ferner muss sich die Überprüfung nicht auf Bondgraphen-Anlagenmodelle verlassen, sondern automatisch erzeugte und eingegebene Signalfluss-Anlagenmodelle werden verwendet. Die Fähigkeit zum automatischen Erzeugen von Anlagencodedaten 414 ermöglicht, dass der Benutzer weder eine spezifische Kenntnis haben muss noch sich über die Details der Erzeugung der Anlagencodedaten 414 Gedanken machen muss. Der Benutzer muss sich daher auch nicht informieren, wie die Modellvereinfachung und/oder Modelltransformation geschieht. Ferner muss der Benutzer beispielsweise nicht Arbeitszeit aufwenden für die Transformation des Modells auf Bondgraphenbasis in ein Modell auf Signalflussgraphenbasis und/oder die Vereinfachung des Modells auf Bondgraphenbasis.
Die Erfindung kann effizient und zuverlässig auf die Entwicklung von Steuersystemen mit einer elektronischen Steuereinheit, zwei elektronischen Steuereinheiten, die miteinander kommunizieren und/oder sich die Steuerung über einen oder mehrere Aktuatoren des gesteuerten Systems teilen, oder sogar mehr als zwei elektronischen Steuereinheiten angewendet werden. Die Erfindung ermöglicht, vorteilhafterweise sogar Systemdefekte zu finden, die in bekannten Überprüfungstechniken nicht gefunden worden sein könnten, da einige Systemdefekte nur in spezifischen Situationen durch Zusammenarbeit von mehreren elektronischen Steuereinheiten auf der Basis der Systemzustände und der Benutzeroperation oder spezifischen Kombinationen von Systemzustand und Benutzeroperation erscheinen können. Die Modelle auf Signalflussbasis unterstützen die Verbesserung der Möglichkeit des effizienten Entdeckens von Systemdefekten.
Merkmale, Komponenten und spezifische Details der Strukturen der vorstehend beschriebenen Aspekte können ausgetauscht oder kombiniert werden, um weitere Beispiele zu bilden, die für die jeweilige Anwendung optimiert sind. Soweit diese Modifikationen für einen Fachmann auf dem Gebiet leicht ersichtlich sind, sollen sie implizit durch die obige Beschreibung offenbart sein, ohne wegen der Kürze explizit jede mögliche Kombination der vorliegenden Beschreibung anzugeben.
Wie vom Fachmann auf dem Gebiet erkannt wird, wie vorstehend beschrieben und in den begleitenden Figuren, kann die Erfindung als Verfahren (z. B. als Computer-implementierter Prozess, als Geschäftsprozess oder irgendein anderer Prozess), Gerät (einschließlich einer Vorrichtung, einer Maschine, eines Systems, eines Computerprogrammprodukts und/oder irgendeines anderen Geräts) oder als Kombination der Vorangehenden verkörpert sein.
Folglich können die beschriebenen Aspekte die Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform (einschließlich Firmware, residenter Software, Microcode usw.) oder einer Ausführungsform, die Software- und Hardwareaspekte kombiniert, die im Allgemeinen hier als ”System” bezeichnet werden können, annehmen. Ferner können die Ausführungsformen der vorliegenden Erfindung die Form eines Computerprogrammprodukts auf einem computerlesbaren Medium mit einem im Medium enthaltenen computerausführbaren Programmcode annehmen.
Es sollte beachtet werden, dass Pfeile in den Zeichnungen verwendet werden können, um eine Kommunikation, Übertragung oder andere Aktivität darzustellen, die zwei oder mehr Entitäten beinhaltet. Doppelendige Pfeile geben im Allgemeinen an, dass die Aktivität in beiden Richtungen stattfinden kann (z. B. ein Befehl/eine Anforderung in einer Richtung mit einer entsprechenden Antwort zurück in der anderen Richtung oder Peer-to-Peer-Kommunikationen, die durch beide Entitäten eingeleitet werden), obwohl in einigen Situationen die Aktivität nicht notwendigerweise in beiden Richtungen stattfinden kann.
Einendige Pfeile geben im Allgemeinen eine Aktivität ausschließlich oder überwiegend in einer Richtung an, obwohl beachtet werden sollte, dass in bestimmten Situationen eine solche Richtungsaktivität tatsächlich Aktivitäten in beiden Richtungen beinhalten kann (z. B. eine Nachricht von einem Sender an einen Empfänger und eine Bestätigung zurück vom Empfänger zum Sender oder die Herstellung einer Verbindung vor einer Übertragung und die Beendung der Verbindung nach der Übertragung). Folglich ist der Typ von Pfeil, der in einer speziellen Zeichnung verwendet wird, um eine spezielle Aktivität darzustellen, beispielhaft und sollte nicht als Begrenzung gesehen werden.
Ausführungsformen der vorliegenden Erfindung sind vorstehend mit Bezug auf Ablaufplandarstellungen und/oder Blockdiagramme von Verfahren und Geräten und mit Bezug auf eine Anzahl von Musteransichten einer graphischen Benutzerschnittstelle, die durch die Verfahren und/oder Geräte erzeugt wird, beschrieben. Selbstverständlich können jeder Block der Ablaufplandarstellungen und/oder Blockdiagramme und/oder Kombinationen von Blöcken in den Ablaufplandarstellungen und/oder Blockdiagrammen sowie die graphische Benutzerschnittstelle durch einen computerausführbaren Programmcode implementiert werden.
Der computerausführbare Programmcode kann zu einem Prozessor eines Universalcomputers, eines Spezialcomputers oder eines anderen programmierbaren Datenverarbeitungsgeräts geliefert werden, um eine spezielle Maschine zu erzeugen, so dass der Programmcode, der über den Prozessor des Computers oder eines anderen programmierbaren Datenverarbeitungsgeräts ausführt, ein Mittel zum Implementieren der Funktionen/Handlungen/Ausgaben erzeugt, die im Ablaufplan, Blockdiagrammblock oder in den Blöcken, Figuren und/oder in der schriftlichen Beschreibung angegeben sind.
Dieser computerausführbare Programmcode kann auch in einem computerlesbaren Speicher gespeichert sein, der einen Computer oder ein anderes programmierbares Datenverarbeitungsgerät anweisen kann, in einer speziellen Weise zu funktionieren, so dass der im computerlesbaren Speicher gespeicherte Programmcode einen Herstellungsgegenstand mit Befehlsmitteln erzeugt, die die Funktion/Handlung/Ausgabe implementieren, die im Ablaufplan, im Blockdiagrammblock (in den Blockdiagrammblöcken), in den Figuren und/oder in der schriftlichen Beschreibung angegeben sind.
Der computerausführbare Programmcode kann auch auf einen Computer oder ein anderes programmierbares Datenverarbeitungsgerät geladen werden, um zu bewirken, dass eine Reihe von Betriebsschritten auf dem Computer oder anderen programmierbaren Gerät durchgeführt wird, um einen Computer-implementierten Prozess zu erzeugen, so dass der Programmcode, der auf dem Computer oder anderen programmierbaren Gerät ausführt, Schritte zum Implementieren der Funktionen/Handlungen/Ausgaben schafft, die im Ablaufplan, im Blockdiagrammblock (in den Blockdiagrammblöcken), in den Figuren und/oder in der schriftlichen Beschreibung angegeben sind. Alternativ können vom Computerprogramm implementierte Schritte oder Handlungen mit von der Bedienperson oder vom Menschen implementierten Schritten oder Handlungen kombiniert werden, um eine Ausführungsform der Erfindung auszuführen.
Es sollte beachtet werden, dass Begriffe wie z. B. ”Server” und ”Prozessor” hier verwendet werden können, um Vorrichtungen zu beschreiben, die in bestimmten Ausführungsformen der vorliegenden Erfindung verwendet werden können, und nicht als Begrenzung der vorliegenden Erfindung auf irgendeinen speziellen Vorrichtungstyp aufgefasst werden sollten, wenn es der Zusammenhang nicht anders erfordert. Folglich kann eine Vorrichtung ohne Begrenzung eine Brücke, einen Router, einen Brückenrouter (Brouter), einen Schalter, einen Knoten, einen Server, einen Computer, ein Gerät oder einen anderen Typ von Vorrichtung umfassen. Solche Vorrichtungen umfassen typischerweise eine oder mehrere Netzschnittstellen zur Kommunikation über ein Kommunikationsnetz und einen Prozessor (z. B. einen Mikroprozessor mit einem Speicher und anderen Peripheriegeräten und/oder einer anwendungsspezifischen Hardware), der dementsprechend zum Durchführen von Vorrichtungsfunktionen konfiguriert ist.
Kommunikationsnetze können im Allgemeinen öffentliche und/oder private Netze umfassen; können ein lokales, weiträumiges, Großraum-, Speicher- und/oder andere Typen von Netzen umfassen; und können Kommunikationstechnologien verwenden, einschließlich, jedoch keineswegs begrenzt auf analoge Technologien, digitale Technologien, optische Technologien, drahtlose Technologien (z. B. Bluetooth), Vernetzungstechnologien und Internetworking-Technologien.
Es sollte auch beachtet werden, dass Vorrichtungen Kommunikationsprotokolle und Nachrichten (z. B. Nachrichten, die durch die Vorrichtung erzeugt, übertragen, empfangen, gespeichert und/oder verarbeitet werden) verwenden können und solche Nachrichten durch ein Kommunikationsnetz oder Kommunikationsmedium übermittelt werden können.
Wenn es der Zusammenhang nicht anders erfordert, sollte die vorliegende Erfindung nicht als auf irgendeinen speziellen Kommunikationsnachrichtentyp, ein spezielles Kommunikationsnachrichtenformat oder ein spezielles Kommunikationsprotokoll begrenzt aufgefasst werden. Folglich kann eine Kommunikationsnachricht im Allgemeinen ohne Begrenzung einen Rahmen, ein Paket, ein Datagramm, ein Benutzerdatagramm, eine Zelle oder einen anderen Typ von Kommunikationsnachricht umfassen.
Wenn es nicht der Zusammenhang anders erfordert, sind Bezugnahmen auf spezifische Kommunikationsprotokolle beispielhaft und selbstverständlich können alternative Ausführungsformen, wie geeignet, Variationen von solchen Kommunikationsprotokollen (z. B. Modifikationen oder Erweiterungen des Protokolls, die von Zeit zu Zeit durchgeführt werden können) oder andere Protokolle, die entweder bekannt sind oder in der Zukunft entwickelt werden, verwenden.
Es sollte auch beachtet werden, dass die Logikflüsse hier beschrieben sein können, um verschiedene Aspekte der Erfindung zu demonstrieren, und nicht als Begrenzung der vorliegenden Erfindung auf irgendeinen speziellen Logikfluss oder Logikimplementierung aufgefasst werden sollten. Die beschriebene Logik kann in verschiedene Logikblöcke (z. B. Programme, Module, Funktionen oder Subroutinen) aufgeteilt werden, ohne die Gesamtergebnisse zu ändern oder ansonsten vom echten Schutzbereich der Erfindung abzuweichen.
Häufig können Logikelemente hinzugefügt, modifiziert, weggelassen, in einer anderen Reihenfolge durchgeführt oder unter Verwendung von anderen Logikgebilden implementiert werden (z. B. Logikgatter, Schleifengrundelemente, Bedingungslogik und andere Logikgebilde), ohne die Gesamtergebnisse zu ändern oder ansonsten vom echten Schutzbereich der Erfindung abzuweichen.
Die vorliegende Erfindung kann in vielen verschiedenen Formen verkörpert sein, einschließlich, jedoch keineswegs begrenzt auf eine Computerprogrammlogik zur Verwendung mit einem Prozessor (z. B. einem Mikroprozessor, Mikrocontroller, Digitalsignalprozessor, oder Universalcomputer), eine programmierbare Logik zur Verwendung mit einer programmierbaren Logikvorrichtung (z. B. einem anwenderprogrammierbaren Verknüpfungsfeld (FPGA) oder anderen PLD), diskrete Komponenten, eine integrierte Schaltungsanordnung (z. B. eine anwendungsspezifische integrierte Schaltung (ASIC)) oder irgendein anderes Mittel, einschließlich irgendeiner Kombination davon. Die Computerprogrammlogik, die einiges oder alles der beschriebenen Funktionalität implementiert, wird typischerweise als Satz von Computerprogrammbefehlen implementiert, die in eine computerausführbare Form umgesetzt werden, als solche in einem computerlesbaren Medium gespeichert werden und von einem Mikroprozessor unter der Steuerung eines Betriebssystem ausgeführt werden. Eine Logik auf Hardwarebasis, die einiges oder alles der beschriebenen Funktionalität implementiert, kann unter Verwendung von einem oder mehreren geeignet konfigurierten FPGAs implementiert werden.
Die Computerprogrammlogik, die alles oder einen Teil der vorher hier beschriebenen Funktionalität implementiert, kann in verschiedenen Formen verkörpert sein, einschließlich, jedoch keineswegs begrenzt auf eine Quellencodeform, eine computerausführbare Form und verschiedene Zwischenformen (z. B. Formen, die durch einen Assembler, Kompilierer, Verknüpfer oder Lokator erzeugt werden).
Der Quellencode kann eine Reihe von Computerprogrammbefehlen umfassen, die in irgendeiner von verschiedenen Programmiersprachen (z. B. ein Objektcode, eine Assembler-Sprache oder eine Sprache hoher Ebene wie z. B. Fortran, C, C++, JAVA oder HTML) zur Verwendung mit verschiedenen Betriebssystemen oder Betriebsumgebungen implementiert werden. Der Quellencode kann verschiedene Datenstrukturen und Kommunikationsnachrichten definieren und verwenden. Der Quellencode kann in einer computerausführbaren Form vorliegen (z. B. über einen Interpreter), oder der Quellencode kann in eine computerausführbare Form umgesetzt werden (z. B. über einen Übersetzer, Assembler oder Kompilierer).
Der computerausführbare Programmcode zum Ausführen von Operationen von Ausführungsformen der vorliegenden Erfindung kann in einer objektorientierten, Skript- oder Nicht-Skript-Programmiersprache wie z. B. Java, Perl, Smalltalk, C++ oder dergleichen geschrieben sein. Der Computerprogrammcode zum Ausführen von Operationen von Ausführungsformen der vorliegenden Erfindung kann jedoch auch in herkömmlichen Verfahrensprogrammiersprachen wie z. B. der ”C”-Programmiersprache oder ähnlichen Programmiersprachen geschrieben sein.
Die Computerprogrammlogik, die alles oder einen Teil der vorher hier beschriebenen Funktionalität implementiert, kann zu verschiedenen Zeiten auf einem einzelnen Prozessor (z. B. gleichzeitig) ausgeführt werden oder kann gleichzeitig oder zu verschiedenen Zeiten auf mehreren Prozessoren ausgeführt werden und kann unter einem einzelnen Betriebssystem-Prozess/Teilprozess oder unter verschiedenen Betriebssystem-Prozessen/Teilprozessen laufen.
Folglich bezieht sich der Begriff ”Computerprozess” im Allgemeinen auf die Ausführung eines Satzes von Programmbefehlen ungeachtet dessen, ob verschiedene Computerprozesse an demselben oder verschiedenen Prozessoren ausgeführt werden, und ungeachtet dessen, ob verschiedene Computerprozesse unter demselben Betriebssystemprozess/Teilprozess oder verschiedenen Betriebssystem-Prozessen/Teilprozessen laufen.
Das Computerprogram kann in irgendeiner Form (z. B. Quellencodeform, computerausführbare Form oder eine Zwischenform) entweder dauerhaft oder verfügbar in einem konkreten Speichermedium wie z. B. einer Halbleiter-Speichervorrichtung (z. B. RAM, ROM, PROM, EEPROM oder Flash-programmierbarer RAM), einer magnetischen Speichervorrichtung (z. B. einer Diskette oder Festplatte), einer optischen Speichervorrichtung (z. B. einer CD-ROM), einer PC-Karte (z. B. einer PCMCIA-Karte) oder einer anderen Speichervorrichtung fest sein.
Das Computerprogramm kann in irgendeiner Form in einem Signal fest sein, das zu einem Computer unter Verwendung von irgendeiner von verschiedenen Kommunikationstechnologien übertragbar ist, einschließlich, jedoch keineswegs begrenzt auf analoge Technologien, digitale Technologien, optische Technologien, drahtlose Technologien (z. B. Bluetooth), Vernetzungstechnologien und Internetworking-Technologien.
Das Computerprogramm kann in irgendeiner Form als entfernbares Speichermedium mit einer begleitenden gedruckten oder elektronischen Dokumentation (z. B. eingeschweißte Software), mit einem Computersystem vorgeladen (z. B. auf einer System-ROM oder Festplatte) verteilt werden oder von einem Server oder elektronischen Form über das Kommunikationssystem (z. B. das Internet oder World Wide Web) verteilt werden.
Die Hardwarelogik (einschließlich einer programmierbaren Logik für die Verwendung mit einer programmierbaren Logikvorrichtung), die alles oder einen Teil der vorher hier beschriebenen Funktionalität implementiert, kann unter Verwendung von herkömmlichen manuellen Verfahren entworfen werden oder kann elektronisch entworfen, erfasst, simuliert oder dokumentiert werden unter Verwendung von verschiedenen Werkzeugen wie z. B. computergestützter Konstruktion (CAD), einer Hardware-Beschreibungssprache (z. B. VHDL oder AHDL) oder einer PLD-Programmiersprache (z. B. PALASM, ABEL oder CUPL).
Irgendein geeignetes computerlesbares Medium kann verwendet werden. Das computerlesbare Medium kann beispielsweise ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, Gerät, Vorrichtung oder Medium sein, ist jedoch nicht darauf begrenzt.
Spezifischere Beispiele des computerlesbaren Mediums umfassen, sind jedoch nicht begrenzt auf eine elektrische Verbindung mit einem oder mehreren Drähten oder anderen konkreten Speichermedium wie z. B. eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer programmierbarer Festwertspeicher (EPROM oder Flash-Speicher), ein Kompaktdisk-Festwertspeicher (CD-ROM) oder eine andere optische oder magnetische Speichervorrichtung.
Die programmierbare Logik kann entweder dauerhaft oder vorübergehend in einem konkreten Speichermedium, wie z. B. einer Halbleiter-Speichervorrichtung (z. B. einem RAM, ROM, PROM, EEPROM oder flashprogrammierbaren RAM), einer magnetischen Speichervorrichtung (z. B. einer Diskette oder Festplatte), einer optischen Speichervorrichtung (z. B. einer CD-ROM) oder einer anderen Speichervorrichtung fest sein.
Die programmierbare Logik kann in einem Signal fest sein, das zu einem Computer unter Verwendung von irgendeiner von verschiedenen Kommunikationstechnologien übertragbar ist, einschließlich, jedoch keineswegs begrenzt auf analoge Technologien, digitale Technologien, optische Technologien, drahtlose Technologien (z. B. Bluetooth), Vernetzungstechnologien und Internetworking-Technologien.
Die programmierbare Logik kann als entnehmbares Speichermedium mit einer begleitenden gedruckten oder elektronischen Dokumentation (z. B. eingeschweißte Software), mit einem Computersystem vorgeladen (z. B. auf einer System-ROM oder Festplatte) verteilt werden oder von einem Server oder elektronischen Forum über das Kommunikationssystem (z. B. das Internet oder World Wide Web) verteilt werden. Einige Ausführungsformen der Erfindung können natürlich als Kombination von sowohl Software (z. B. ein Computerprogrammprodukt) als auch Hardware implementiert werden. Noch andere Ausführungsformen der Erfindung werden als vollständig Hardware oder vollständig Software implementiert.
Obwohl bestimmte beispielhafte Aspekte in den begleitenden Zeichnungen gezeigt und beschrieben wurden, sind solche Ausführungsformen selbstverständlich nur erläuternd für und schränken die breite Erfindung nicht ein und die Ausführungsformen der Erfindung sind nicht auf die gezeigten und beschriebenen spezifischen Konstruktionen und Anordnungen begrenzt, da verschiedene andere Änderungen, Kombinationen, Auslassungen, Modifikationen und Substitutionen zusätzlich zu den in den obigen Absätzen dargelegten möglich sind.
Der Fachmann auf dem Gebiet erkennt, dass verschiedene Anpassungen, Modifikationen und/oder eine Kombination der gerade beschriebenen Aspekte ohne Abweichung vom Schutzbereich und Gedanken der Erfindung konfiguriert werden können. Daher kann die Erfindung selbstverständlich innerhalb des Schutzbereichs der beigefügten Ansprüche anders als spezifisch hier beschrieben ausgeführt werden. Wenn nicht ausdrücklich anders angegeben, können beispielsweise die hier beschriebenen Schritte von Prozessen in Reihenfolgen durchgeführt werden, die von den hier beschriebenen verschieden sind, und ein oder mehrere Schritte können kombiniert, aufgeteilt oder gleichzeitig durchgeführt werden.
Der Fachmann auf dem Gebiet erkannt auch angesichts dieser Offenbarung, dass verschiedene Aspekte der Erfindung, die hier beschrieben sind, kombiniert werden können, um andere Ausführungsformen der Erfindung zu bilden.
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 Patentliteratur

JP 2009-014406 A [0008]
JP 2009-14406 A [0031]

Zitierte Nicht-Patentliteratur

Artikel ”Symbolic Execution for Software Testing: Three Decades Later” von C. Cadar und K. Sen [0095]

Claims

Verfahren zum Testen einer Steuersoftware eines gesteuerten Systems, wobei das gesteuerte System eine oder mehrere elektronische Steuereinheiten, einen oder mehrere Aktuatoren und einen oder mehrere Sensoren umfasst, wobei jeder Sensor dazu ausgelegt ist, ein jeweiliges Sensorsignal in mindestens eine der einen oder mehreren elektronischen Steuereinheiten einzugeben, und jeder Aktuator dazu ausgelegt ist, in Reaktion auf jeweilige Steuersignale zu handeln, die von mindestens einer der elektronischen Steuereinheiten eingegeben werden, und jede elektronische Steuereinheit dazu konfiguriert ist, ein jeweiliges ausführbares Steuerprogramm auf der Basis von Steuersoftware-Codedaten auszuführen, um ein oder mehrere Steuersignale an den einen oder die mehreren Aktuatoren auf der Basis der eingegebenen Sensorsignale auszugeben, wobei das Verfahren umfasst: – Bereitstellen von Steuersoftware-Codedaten (402) für jede der einen oder der mehreren elektronischen Steuereinheiten, – Bereitstellen von Anlagencodedaten (414) für das gesteuerte System, – Erzeugen eines Systemmodells (415) auf der Basis der Anlagencodedaten (414) und der Steuersoftware-Codedaten (402), – Erzeugen eines ausführbaren Programms auf der Basis des erzeugten Systemmodells (415), und – Durchführen eines Software-Überprüfungsprozesses auf der Basis des ausführbaren Programms.
Verfahren nach Anspruch 1, wobei das Bereitstellen von Anlagencodedaten (414) die Schritte umfasst: – Eingeben eines Bondgraphen-Anlagenmodells (401) des gesteuerten Systems, – Erzeugen eines vereinfachten Bondgraphen-Anlagenmodells (410) durch Vereinfachen des eingegebenen Bondgraphen-Anlagenmodells (401), – Erzeugen eines Signalfluss-Anlagenmodells (413) durch Transformieren des vereinfachten Bondgraphen-Anlagenmodells (410), und – Erzeugen der Anlagencodedaten (414) auf der Basis des Signalfluss-Anlagenmodells (413).
Verfahren nach Anspruch 2, wobei das Erzeugen des vereinfachten Bondgraphen-Anlagenmodells (410) die Schritte umfasst: – Durchsuchen des Bondgraphen-Anlagenmodells (401) nach mindestens einem zu vereinfachenden Objekt, – Entfernen des mindestens einen gesuchten Objekts, – Hinzufügen mindestens eines vereinfachten Objekts und – Verknüpfen der Objekte des vereinfachten Bondgraphen-Anlagenmodells (410).
Verfahren nach Anspruch 2, wobei das Erzeugen des Signalfluss-Anlagenmodells (413) die Schritte umfasst: – Lesen von Informationen des mindestens einen Objekts des vereinfachten Bondgraphen-Anlagenmodells (410) und – Hinzufügen mindestens einer Signalfluss-Komponente von einer Signalflussgraphen-Objektbibliothek (412) und – Verknüpfen von Anschlüssen der mindestens einen hinzugefügten Signalfluss-Komponente.
Verfahren nach mindestens einem der vorangehenden Ansprüche, wobei das Durchführen des Software-Überprüfungsprozesses auf der Basis des ausführbaren Programms das Durchführen einer symbolischen Ausführung auf der Basis des Systemmodells (415) umfasst.
Verfahren nach mindestens einem der vorangehenden Ansprüche, wobei das Erzeugen des ausführbaren Programms auf der Basis des erzeugten Systemmodells (415) das Übertragen von einem oder mehreren Parametern des Systemmodells (415) in Symbole für die symbolische Ausführung umfasst.
Verfahren nach mindestens einem der vorangehenden Ansprüche, das ferner umfasst Bereitstellen von Systemeingangs-Informationsdaten (404), wobei die Systemeingangs-Informationsdaten (404) den einen oder die mehreren Parameter des Systemmodells (415) angeben, die in Symbole für die symbolische Ausführung übertragen werden sollen.
Verfahren nach mindestens einem der vorangehenden Ansprüche, das ferner umfasst Bereitstellen von Überprüfungsanforderungs-Informationsdaten (405), wobei die Überprüfungsanforderungs-Informationsdaten (405) eine oder mehrere Überprüfungsanforderungsbedingungen entsprechend einer jeweiligen Steuerfehlersituation angeben.
Verfahren nach Anspruch 1, wobei das Durchführen des Software-Überprüfungsprozesses umfasst: – Iterieren durch einen Ausführungsbaum des ausführbaren Programms gemäß einer oder mehreren Pfadbedingungen des ausführbaren Programms, und – Prüfen in jeder Iteration, ob mindestens eine der einen oder der mehreren Überprüfungsanforderungsbedingungen erfüllt ist, und insbesondere – Benachrichtigen eines Benutzers über die Detektion der Steuerfehlersituation, falls festgestellt wird, dass mindestens eine der einen oder der mehreren Überprüfungsanforderungsbedingungen erfüllt ist.
Verfahren nach Anspruch 1, das ferner umfasst Ausgeben einer spezifischen Pfadbedingung, die der detektierten Steuerfehlersituation zugeordnet ist.
Verfahren nach mindestens einem der vorangehenden Ansprüche, das ferner umfasst Bereitstellen von Zusammenarbeits-Informationsdaten (403), die Zuordnungen von zusammenhängenden Eingangsparametern und Ausgangsparametern der bereitgestellten Steuersoftware-Codedaten (402) und der bereitgestellten Anlagencodedaten (414) angeben.
Überprüfungssystem zum Testen einer Steuersoftware eines gesteuerten Systems, wobei das gesteuerte System eine oder mehrere elektronische Steuereinheiten, einen oder mehrere Aktuatoren und einen oder mehrere Sensoren umfasst, wobei jeder Sensor dazu ausgelegt ist, ein jeweiliges Sensorsignal in mindestens eine der einen oder der mehreren elektronischen Steuereinheiten einzugeben, und jeder Aktuator dazu ausgelegt ist, in Reaktion auf jeweilige Steuersignale zu handeln, die von mindestens einer der elektronischen Steuereinheiten eingegeben werden, und jede elektronische Steuereinheit dazu konfiguriert ist, ein jeweiliges ausführbares Steuerprogramm auf der Basis von Steuersoftware-Codedaten auszuführen, um ein oder mehrere Steuersignale an den einen oder die mehreren Aktuatoren auf der Basis der eingegebenen Sensorsignale auszugeben, wobei das Überprüfungssystem umfasst: – eine Datenbereitstellungseinheit (10, 11), die dazu konfiguriert ist, Steuersoftware-Codedaten (402) für jede der einen oder mehreren elektronischen Steuereinheiten bereitzustellen, – einen Codegenerator (7), um Anlagencodedaten (414) für das gesteuerte System bereitzustellen, – einen Systemmodellkonstrukteur (8), der dazu konfiguriert ist, ein Systemmodell (415) auf der Basis der Anlagencodedaten (414) und der Steuersoftware-Codedaten (402) zu erzeugen, – einen Kompilierer, der dazu konfiguriert ist, ein ausführbares Programm auf der Basis des erzeugten Systemmodells (415) zu erzeugen, und – eine Überprüfungseinheit (9), die dazu konfiguriert ist, einen Software-Überprüfungsprozess auf der Basis des ausführbaren Programms durchzuführen.
Überprüfungssystem nach Anspruch 12, wobei das erzeugte Systemmodell (415) zumindest die Anlagencodedaten (414) und die Steuersoftware-Codedaten (402) umfasst und ferner umfasst: – Synchronisationsmodul-Codedaten (420), – Zusammenarbeitsmodul-Codedaten (417), – Codedaten (418) eines symbolischen Moduls und – Durchsetzungsmodul-Codedaten (419).
Überprüfungssystem nach mindestens einem der vorangehenden Ansprüche, das ferner umfasst: – mindestens eine Modellvereinfachungseinheit (5) zum Vereinfachen eines Bondgraphen-Anlagenmodells (401), um ein vereinfachtes Bondgraphen-Anlagenmodell (410) zu erzeugen, – mindestens eine Modelltransformationseinheit (6) zum Transformieren des vereinfachten Bondgraphen-Anlagenmodells (410) in ein Signalfluss-Anlagenmodell (413) und – eine Codeerzeugungseinheit (7) zum Erzeugen der Anlagencodedaten (414) auf der Basis des Signalfluss-Anlagenmodells (413).
Computerprogrammprodukt mit einem Computerprogrammittel, das auf einem computerlesbaren Medium speicherbar ist und durch eine Computervorrichtung ausführbar ist, wobei das Programmmittel ausführbare Befehle umfasst, die bewirken, dass die Computervorrichtung Schritte eines Verfahrens nach mindestens einem der Ansprüche 1 bis 11 durchführt.