-
Technisches Gebiet
-
Die Erfindung stellt ein Verfahren und ein System zur Animation und zum Debuggen mindestens eines Fahrzeugsystems bereit, wobei Daten ohne Instrumentieren des Quellcodes des Fahrzeugsystems erfasst werden.
-
Stand der Technik
-
Systemkomponenten, die über eine technische Plattform, wie ein Fahrzeug, verteilt sind, müssen miteinander kommunizieren, um ihre Arbeitsabläufe anzupassen. Ein üblicher Standard für eine derartige Kommunikation von Systemkomponenten in Fahrzeugen ist AUTOSAR (AUTomotive Open System ARchitecture), der Verfahren zum Austauschen von Software zwischen diversen Systemkomponenten, wie Steuergeräte, bereitstellt.
-
Bekannte Tools ermöglichen das Ansehen eines Programms in Bezug auf Objekte auf einer höheren Ebene. Ein derartiges System ist RTA-TRACE, das das Beobachten eines Verhaltens eines entsprechend instrumentierten AUTOSAR-Betriebssystems (operating system, OS) in Bezug auf zugrunde liegende OS-Objekte ermöglicht. Bekannte Nachteile derartiger Systeme sind ein verhältnismäßig hohes Ausmaß an Overhead-Daten, Schwierigkeiten bei der individuellen Anpassung und eine starke Ausrichtung auf OS-Verfolgung. Folglich besteht Bedarf an einer Softwarelösung, die eine Möglichkeit zum Überwachen und Debuggen von eingebetteten Systemen mit keinen oder minimierten Overhead-Daten bereitstellt. Des Weiteren sollte diese Software eine individuelle Anpassung ermöglichen, um ihre Eigenschaften auf ein individuelles System anzugleichen.
-
Des Weiteren umfassen eingebettete Systeme normalerweise ein Background-Debug-Mode-Interface (BDM-Interface), bei dem es sich um eine elektronische Schnittstelle handelt, die ein Debuggen von eingebetteten Systemen ermöglicht. Insbesondere stellt es eine In-Circuit-Debugging-Funktionalität in Mikrocontrollern bereit.
-
In-Circuit-Debugging wird von einem In-Circuit-Emulator (ICE) durchgeführt, bei dem es sich um eine Hardwarevorrichtung handelt, die zum Debuggen der Software eines eingebetteten Systems verwendet wird. Ein In-Circuit-Emulator stellt ein Fenster in das eingebettete System bereit. Ein Programmierer verwendet den Emulator, um Programme in das eingebettete System zu laden, sie auszuführen, sie langsam schrittweise durchzusehen und Daten, die von der Software des Systems verwendet werden, anzusehen und zu ändern. Ein „Emulator” emuliert den Zentralprozessor des Computers des eingebetteten Systems. Ein Simulator stellt dieselbe Funktionalität wie die Hardware bereit, jedoch mittels Ausführung von Software, die der Hardware des Prozessors gleichwertig ist. Folglich ist eine Simulation in der Regel langsamer als Echtzeit; es ist jedoch viel mehr des internen Arbeitsablaufs des simulierten Prozessors zu sehen.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zur Animation und zum Debuggen mindestens eines Fahrzeugsystems nach Anspruch 1 bereit. Darüber hinaus stellt die Erfindung ein Computerprogramm nach Anspruch 10 und ein System zur Animation und zum Debuggen mindestens eines Fahrzeugsystems nach Anspruch 11 bereit. Der Gegenstand der abhängigen Ansprüche definiert Ausführungsformen der Erfindung.
-
Das vorliegende Verfahren basiert auf der Verwendung von Datenerfassung, wie sie von einem üblichen Debugger durchgeführt wird. Folglich wird eine Ansicht des Debuggers eines Zielprozessors bzw. einer Anwendung, die auf dem Zielprozessor läuft, durch eine Ansicht auf einer höheren Ebene ersetzt. Das bedeutet, dass das vorliegende Verfahren eine laufende Anwendung auf mindestens einem Zielprozessor pausieren und beispielsweise ein zugrunde liegendes Register oder zugrunde liegende Speicherdaten prüfen und Daten daraus sammeln kann. Im Gegensatz zu üblichen Techniken kann das vorliegende Verfahren Daten aus einer Anwendung ohne Instrumentieren des Codes der Anwendung erfassen. Falls erforderlich, kann das vorliegende Verfahren auch einen Debugging-Schritt beinhalten, der zugrunde liegenden Code einer fehlgeschlagenen Anwendung repariert. Infolgedessen können Overhead-Daten, die gewöhnlich zur Erfassung von Daten ohne einen Debugging-Modus verwendet werden, vermieden oder minimiert werden.
-
Im Rahmen der vorliegenden Erfindung ist ein Zielprozessor ein Prozessor oder ein Satz von Prozessoren, die verbunden sind, und der bzw. die insbesondere ein eingebettetes System eines Fahrzeugs bildet bzw. bilden.
-
Das vorliegende Verfahren ermöglicht eine Überwachung von Anwendungen, die auf einem Fahrzeugsystem, wie dem oben erwähnten Zielprozessor, durchgeführt werden, indem es eine Visualisierung von Prozessen und eine Analyse von Daten, die von dem entsprechenden Fahrzeugsystem verarbeitet werden, bereitstellt.
-
Eine derartige Visualisierung kann auch zum Debuggen im Fall einer Fehlfunktion verwendet werden. Folglich basiert das vorliegende Verfahren auf zwei Architekturelementen – einem Visualisierer- und Analysatorelement und einem Zieldatenerfassungstool, das Daten aus einem System oder Prozess von Interesse sammeln kann, ohne den zugrunde liegenden Quellcode zu instrumentieren, und dem Visualisierer und Analysator gesammelte Daten zuführen kann.
-
Die Zieldatenerfassung kann auf einer Simulation des mindestens einen Zielprozessors und/oder einer Simulation einer Umgebung des mindestens einen Zielprozessors oder bei Emulation einer mit dem Zielprozessor verbundenen echten oder emulierten Umgebung basieren.
-
Wenn eine simulierte Installation und eine simulierte Umgebung verwendet werden, kann eine 0-Intrusion in Bezug auf die Zeit auch erzielt werden, indem die Simulation des Prozessors und der Installation gleichzeitig gestoppt werden, wodurch eine größere Steuerbarkeit und Beobachtbarkeit erhalten wird. Eine Simulation ist jedoch oftmals weniger genau als die Verwendung einer realen Vorrichtung.
-
Wenn ein emulierter oder realer Prozessor mit einer realen Umgebung verwendet wird, kann das Stoppen des Prozessors zu einem inkorrekten Verhalten des Systems führen, da die Umgebung weiterhin läuft. Folglich sind ein realer Prozessor und eine reale Umgebung genauer, aber weniger beobachtbar und steuerbar.
-
Durch Verwenden einer Simulation des Zielprozessors und von Anwendungen, die auf dem Zielprozessor laufen, können eine Analyse und eine Visualisierung der jeweiligen Daten erzielt werden, ohne dass der zugrunde liegende reale Zielprozessor oder eine jeweilige Anwendung pausiert wird. Es ist weiterhin beabsichtigt, dass der reale Zielprozessor mit dem simulierten Zielprozessor und einer simulierten Umgebung interagieren kann, so dass sie beide dieselbe Ansicht der Zeit teilen und ein Stoppen des Ziels auch die simulierte Umgebung und den simulierten Zielprozessor stoppt.
-
Des Weiteren können der Visualisierer und Analysator von einem Softwareentwickler zur Überwachung und Diagnose von Prozessen verwendet werden, um ein Fahrzeugsystem zu verbessern oder zu debuggen. Folglich kann der Visualisierer und Analysator dazu verwendet werden, Kontextinformationen mehrerer Prozesse in einer gegebenen Systemarchitektur anzuzeigen, ohne dass ein Modifizieren von jeweiligem Quellcode erforderlich ist.
-
Es werden Vorkehrungen zur Verwendung der erwähnten Debugging-Technik getroffen, indem eine Anwendung (simuliert oder real) pausiert wird, um Daten zu erfassen und diese Daten zu verarbeiten, um einem Benutzer oder Entwickler zugrunde liegende Prozesse anzuzeigen. Da das vorliegende Verfahren eine Technik verwendet, die auf einem Debugging-Interface basiert, müssen keine Änderungen an dem jeweiligen Quellcode vorgenommen werden, was bedeutet, dass eine 0-Intrusion in Bezug auf den Raum erzielt wird. Wenn der mindestens eine Zielprozessor simuliert ist, kann ebenfalls eine 0-Intrusion in Bezug auf die Zeit erzielt werden.
-
Zur Verwendung der erwähnten Debugging-Technik zur Datenerfassung ist es erforderlich, dass der Visualisierer und Analysator die Ausführung des Zielprozessors leitet, so dass die Datenerfassung zu geeigneten Zeiten durchgeführt wird, wie während eines Bereitschaftszeitraums. Des Weiteren ist der Visualisierer und Analysator das einzige Teilelement, das weiß, wann die Datenerfassung abgeschlossen ist und wann der Zielprozessor wieder gestartet werden kann.
-
Da das Datenerfassungselement des vorliegenden Verfahrens erfordert, dass der Zielprozessor pausiert, um eine Datenerfassung durchzuführen, muss es auch die Ausführung des Zielprozessors steuern und die Daten in dem Zielprozessor modifizieren können, wie eine Variable in einer Aufgabe, deren Ausführung gerade begonnen hat.
-
Falls erforderlich, kann ein Softwareentwickler Haltepunkte und Beobachtungspunkte verwenden, um relevante Aktivitäten des mindestens einen Zielprozessors zu erfassen. Durch Verwendung von Haltepunkten und Beobachtungspunkten kann der Inhalt relevanter Adressen leicht auf automatische Weise gefunden werden.
-
Das oben beschriebene Verfahren kann direkt auf einem Steuergerät eines Fahrzeugs oder auf einem Computersystem, das mit dem Steuergerät des Fahrzeugs verbunden ist, oder einem beliebigen anderen Fahrzeugsystem durchgeführt werden. Darüber hinaus ist es möglich, ein mobiles Computersystem mit dem vorliegenden Programm, das auf einem Fahrzeugsystem durchgeführt wird, zu verbinden. Das Verbinden eines Computersystems mit dem jeweiligen Fahrzeugsystem kann eine höhere Rechenleistung bereitstellen, die die Debugging-Zeit drastisch verkürzen kann.
-
Ein anderer Vorteil des Verbindens eines Computersystems mit dem Fahrzeugsystem, auf dem das vorliegende Computerprogramm läuft, ist die Verwendung eines Bildschirms, der von dem Computersystem bereitgestellt wird und der von dem Computerprogramm dazu verwendet werden kann, analysierte oder gesammelte Daten anzuzeigen.
-
Des Weiteren umfasst die vorliegende Erfindung ein System zur Animation und zum Debuggen mindestens eines Fahrzeugsystems mit mindestens einem Zielprozessor. Das System umfasst mindestens einen Bildschirm zum Anzeigen von Ergebnissen eines Visualisierers und Analysators und kann zum Debuggen von eingebetteten Systemen in Fahrzeugen, entweder automatisch oder durch einen qualifizierten Entwickler, verwendet werden.
-
Wie oben erwähnt, kann die Verwendung eines Bildschirms zur Visualisierung und Analyse von gesammelten Daten vorteilhaft sein, insbesondere wenn große Datenmengen von einem Entwickler analysiert werden müssen. Im Rahmen der Erfindung kann ein Bildschirm eine beliebige geeignete Vorrichtung zum Anzeigen der gesammelten Daten sein, insbesondere ein LCD- oder LED-Monitor eines Computersystems.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt eine mögliche Ausführungsform eines Systems zur Animation und zum Debuggen mindestens eines Fahrzeugsystems.
-
2 zeigt ein Ablaufdiagramm einer Ausführungsform des vorliegenden Verfahrens.
-
Beschreibung von Ausführungsformen
-
1 zeigt ein Fahrzeug 10 mit einem Steuergerät 11, das mit einem Computersystem 20 verbunden ist. Auf dem Computersystem 20 läuft ein Computerprogramm, das ein Visualisierer- und Analysatorelement 1 und ein Zieldatenerfassungselement 2 umfasst.
-
Das Datenerfassungselement 2 sammelt Daten von dem Steuergerät 11 des Fahrzeugs und führt die Daten dem Visualisierer- und Analysatorelement 1 zu. Um die Daten von dem Steuergerät 11 zu sammeln, wird von dem Datenerfassungselement 2 ein Debugger-Interface des Steuergeräts 11 verwendet.
-
Um mögliche Fehlfunktionen zu erkennen, werden die Daten, die von dem Visualisierer- und Analysatorelement 1 analysiert werden, und die analysierten Daten auf einem Bildschirm des Computersystems 20 angezeigt, das von einem Softwareentwickler gesteuert wird. Da das Steuergerät 11 mehrere Untergeräte umfasst, die auf vordefinierte Weise kommunizieren, kann der Softwareentwickler die zugrunde liegenden Kommunikationsprozesse auf dem Bildschirm des Computersystems 20 überwachen. Durch Verwenden des Debugging-Interfaces können Änderungen des Quellcodes des Steuergeräts vermieden werden. Folglich müssen Overhead-Daten, wie Protokolle oder Fehlercodes, nicht von dem Steuergerät selbst verwaltet werden, was die Rechenkapazität des Steuergeräts 11 erhöht.
-
Das Datenerfassungselement 2 liefert Daten von mehreren Quellen innerhalb des Steuergeräts 11, indem es deren jeweilige Debugger-Interfaces für eine Fusion verwendet, die von dem Visualisierer- und Analysatorelement 1 durchgeführt wird und die eine Ansicht auf einer höheren Ebene der gesammelten Debugger-Interface-Daten ermöglicht. Wenn der Softwareentwickler wünscht, spezifische Elemente der bereitgestellten Ansicht auf einer höheren Ebene zu ändern, kann das Datenerfassungselement 2 auch zugrunde liegenden Quellcode des Steuergeräts 11 oder jeweiliger Untergeräte ändern.
-
In 2 zeigt das Ablaufdiagramm einen Prozess zum Debuggen eines Fahrzeugsystems. Der Prozess beginnt mit einem Datenerfassungsschritt 21, der von einem Datenerfassungsmodul durchgeführt wird, das innerhalb eines Debugging-Interfaces des Fahrzeugsystems arbeitet. Die erfassten Daten werden einem Visualisierungs- und Analyseelement zugeführt, das die Daten gemäß Einstellungen, die von einem gegebenen Benutzer definiert wurden, in einem Analyseschritt 22 analysiert, auf den ein Visualisierungsschritt 23 folgt, wobei die analysierten Daten auf einem Bildschirm dargestellt werden. Der Benutzer, bei dem es sich um einen Programmierer oder Entwickler handeln kann, kann nun Prozesse auf dem Bildschirm überwachen, die von dem Fahrzeugsystem durchgeführt werden. In Fällen einer Fehlfunktion oder zur Funktionsverbesserung kann der Benutzer einen Modifizierungsschritt 24 durchführen, wobei die modifizierten Daten in einem Kommunikationsschritt 25 direkt dem Datenerfassungsmodul zugeführt werden. Das Datenerfassungsmodul kann außerdem die Modifizierungen in dem Fahrzeugsystem speichern. In dem Fall, dass der Benutzer keinerlei Modifizierungen durchführt, stoppt der Prozess am Visualisierungsschritt 23, was dem Datenerfassungsmodul berichtet wird, und ein anderer Prozess wird wieder mit einem Datenerfassungsschritt 21 begonnen.
