Titel

Verfahren zum Übertragen von Log-Daten einer Ausführung eines Computerprogramms

Stand der Technik

Die vorliegende Offenbarung bezieht sich auf Verfahren zum Übertragen von Log -Daten einer Ausführung eines Computerprogramms.

Computerprogramme müssen typischerweise auf Fehler überprüft werden. Dies gilt insbesondere bei Steuerprogrammen in sicherheitsrelevanten Anwendungen, wie z.B. Steuersoftware für ein (ggf. autonomes) Fahrzeug. Dies geschieht durch die Untersuchung von Log-Daten der Ausführung eines jeweiligen Computerprogramms. In bestimmten Anwendungen, wie beispielsweise einer Steuersoftware in einem Fahrzeug, ist es wünschenswert, das für solche Log-Daten flexible (z.B. benutzerdefinierte) Datenstrukturen verwendet werden können und zugleich der Aufwand auf der sendenden Seite (hier das Fahrzeug) gering ist, weil sie beispielsweise über eingeschränkte Rechenressourcen verfügt.

Offenbarung der Erfindung

Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Übertragen von Log- Daten einer Ausführung eines Computerprogramms bereitgestellt, aufweisend Erzeugen einer indizierten Liste von Identifikatoren von benutzerdefinierten Log-Anweisungs- Argument-Datentypen, Übertragen, vor der Ausführung des Programms, für jede Log- Anweisung einer Menge von Log-Anweisungen zur Ausgabe von Log-Daten, die in dem Programm enthalten ist, von statischen Log-Daten an einen Log-Daten-Empfänger, wobei die statischen Log-Daten solche Log-Daten sind, die von Ausführung zu Ausführung des Programms für die Log-Anweisung gleich bleiben und Übertragen, bei der Ausführung des Programms, fur jede Log -Anweisung der Menge von Log-Anweisungen, die bei der Ausführung des Programms ausgeführt wird, von dynamischen Log-Daten für die Log- Anweisung, wobei die dynamischen Log-Daten solche Log-Daten sind, die sich von Ausführung zu Ausführung des Programms verändern können, und wobei die dynamischen Log-Daten, wenn die Log-Anweisung einen der benutzerdefinierten Log- Anweisungs-Argument-Datentypen zur Ausgabe von dynamischen Log-Daten verwendet, einen Index des Identifikators des Log-Anweisungs-Argument-Datentyps enthält.

Das oben beschriebene Verfahren ermöglicht eine effiziente Übertragung von Log-Daten (und damit ein effizientes Loggen) durch die Trennung von statistischen und dynamischen Log-Daten. Dies geschieht insbesondere für benutzerdefinierte Log- Anweisungs-Argument-Datentypen und somit für flexibel definierbare Datentypen, die für die Übertragung von Log-Daten (und deren Strukturierung) verwendet werden.

Das Trennen von statischen und dynamischen Log-Daten erhöht die Leistungsfähigkeit des Loggens erheblich. Die Verwendung von benutzerdefinierten Log-Anweisungs- Argument-Datentypen (auch einfacher nur als Log-Datentypen bezeichnet) ermöglicht in diesem Kontext das Loggen von strukturierten Log-Daten. Dies kann beispielsweise für Tracing (für Visualisierung und forensischer Rekonstruktion der Programmausführung) zum Tracen verwendet werden, unter Verwendung einer (nachgelagerten) Deserialisierung.

Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.

Ausführungsbeispiel 1 ist das oben beschriebene Verfahren zum Übertragen von Log- Daten einer Ausführung eines Computerprogramms.

Ausführungsbeispiel 2 ist ein Verfahren nach Ausführungsbeispiel 1, wobei die dynamischen Log-Daten, wenn die Log-Anweisung einen der benutzerdefinierten Log- Anweisungs-Argument-Datentypen zur Ausgabe von dynamischen Log-Daten verwendet, Rohdaten für den Log-Anweisungs-Argument-Datentyp und eine Angabe der Datenmenge der Rohdaten enthält. Auf diese Weise können kann die Menge der Rohdaten, die mittels eines benutzerdefinierten Log-Anweisungs-Argument-Datentyps übertragen wird, flexibel eingestellt werden, da sie Teil der dynamischen Daten für den Log-Anweisungs- Argument-Datentyp ist (und nicht statisch festgelegt ist).

Ausführungsbeispiel 3 ist ein Verfahren nach Ausführungsbeispiel 1 oder 2, aufweisend Übertragen der dynamischen Log-Daten über einen Kommunikationskanal, Empfangen der dynamischen Log-Daten durch den Empfänger, Prüfen, ob die dynamischen Log- Daten einen Index eines Log-Anweisungs-Argument-Datentypen enthalten, falls die dynamischen Log-Daten einen Index eines Log-Anweisungs-Argument-Datentypen enthalten, Beschaffen von Informationen über den Log-Anweisungs-Argument-Datentyp und Umwandeln der dynamischen Log-Daten in eine Datenstruktur gemäß den Informationen über den Log-Anweisungs-Argument-Datentyp. Das Umwandeln kann als die eigentliche Deserialisierung der benutzerdefinierten Logdaten angesehen werden. Das Prüfen, Beschaffen der Informationen über den Log-Anweisungs-Argument-Datentyp und Umwandeln passiert beispielsweise auf Seiten des Empfängers der Log-Daten (z.B. eines Servers und/oder einer Cloud), der eine Analyse der Logdaten durchführt. Der Sender der Log-Daten (z.B. ein Fahrzeug) führt hingegen diese komplexe Verarbeitung nicht durch und schreibt die Log-Daten z.B. Eins-zu-Eins in ein Archiv (für die spätere Weiterleitung an den Empfänger).

Ein Empfänger (z.B. Server oder Host, der die Log -Daten analysiert und/oder für einen Benutzer aufbereitet) kann auf diese Weise die dynamischen Daten (insbesondere Rohdaten), die für einen Log-Anweisungs-Argument-Datentyp übertragen werden, korrekt strukturieren und weiterverarbeiten.

Ausführungsbeispiel 4 ist ein Verfahren nach Ausführungsbeispiel 3, wobei die Informationen über den Log-Anweisungs-Argument-Datentyp Bezeichnungen von Elementen des Log-Anweisungs-Argument-Datentyps aufweisen.

Dies ermöglicht beispielsweise die Anzeige der Rohdaten, die für einen Log- Anweisungs-Argument-Datentyp übertragen werden, für einen Benutzer mit den korrekten Bezeichnungen. Beispielweise können in einer Visualisierung der Ausführung des Computerprogramms die Log- Daten dann direkt und hierarchisch dargestellt werden. Ausführungsbeispiel 5 ist ein Verfahren nach einem der Ausführungsbeispiele 1 bis 4, wobei der Identifikator jedes Log -Anweisungs-Argument-Datentyps ein Hash eines Syntaxbaums des Log-Anweisungs-Argument-Datentyps ist.

Die Verwendung solcher Hashes ermöglicht eine einfache Erzeugung eindeutiger Identifikatoren.

Ausführungsbeispiel 6 ist ein Verfahren nach einem der Ausfuhrungsbeispiele 1 bis 5, wobei die statischen Log-Daten ein Ort der Log-Anweisung, ein Kanal Schweregrad einer von der Log-Anweisung ausgegebenen Log-Nachricht und/oder ein Argument- Layout der Log-Anweisung sind.

Diese Informationen ändern sich nicht zwischen den Ausführungen des Programms. Durch ihre Vorab-Übermittlung (z.B. an einen Server) kann die Datenmenge von Log- Daten, die während der Ausführung des Programms übertragen wird, reduziert werden. Der Kanal kann insbesondere einen Schweregrad repräsentieren. Beispiele für Kanäle sind TIME, TRACE, EVENT, DEBUG, STATUS, INFO, WARNING, ERROR und FATAL.

Ausführungsbeispiel 7 ist ein Verfahren nach einem der Ausführungsbeispiele 1 bis 6, wobei die Log-Datentypen Klassen einer objektorientierten Programmiersprache sind.

Dies ermöglicht eine flexible Strukturierung der Log-Daten.

Ausführungsbeispiel 8 ist eine Datenverarbeitungsanordnung, die eingerichtet ist, ein Verfahren nach einem der Ausführungsbeispiele 1 bis 7 durchzuführen.

Ausführungsbeispiel 9 ist ein Computerprogramm mit Befehlen, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, bewirken, dass die ein oder mehreren Prozessoren ein Verfahren nach einem der Ausführungsbeispiele 1 bis 7 durchführen.

Ausführungsbeispiel 10 ist ein Computerlesbares Medium, das Befehle speichert, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, bewirken, dass die ein oder mehreren Prozessoren ein Verfahren nach einem der Ausführungsbeispiele 1 bis 7 durchführen. In den Zeichnungen beziehen sich ähnliche Bezugszeichen im Allgemeinen auf dieselben Teile in den ganzen verschiedenen Ansichten. Die Zeichnungen sind nicht notwendigerweise maßstäblich, wobei die Betonung stattdessen im Allgemeinen auf die Darstellung der Prinzipien der Erfindung gelegt wird. In der folgenden Beschreibung werden verschiedene Aspekte mit Bezug auf die folgenden Zeichnungen beschrieben.

Figur 1 zeigt ein Fahrzeug.

Figur 2 zeigt ein Aufzeichnungssystem das Loggen für Software, die auf einer Steuereinrichtung ausgeführt wird, in größerem Detail.

Figur 3 zeigt eine verkettete Liste, die ausgehend von einem Listenkopf eine Verkettung von Knoten enthält.

Figur 4 zeigt ein Ablaufdiagramm, das ein Verfahren zum Übertragen von Log-Daten einer Ausführung eines Computerprogramms gemäß einer Ausführungsform darstellt.

Die folgende ausführliche Beschreibung bezieht sich auf die begleitenden Zeichnungen, die zur Erläuterung spezielle Details und Aspekte dieser Offenbarung zeigen, in denen die Erfindung ausgeführt werden kann. Andere Aspekte können verwendet werden und strukturelle, logische und elektrische Änderungen können durchgeführt werden, ohne vom Schutzbereich der Erfindung abzuweichen. Die verschiedenen Aspekte dieser Offenbarung schließen sich nicht notwendigerweise gegenseitig aus, da einige Aspekte dieser Offenbarung mit einem oder mehreren anderen Aspekten dieser Offenbarung kombiniert werden können, um neue Aspekte zu bilden.

Im Folgenden werden verschiedene Beispiele genauer beschrieben.

Figur 1 zeigt ein Fahrzeug 101.

Im Beispiel von Figur 1 ist ein Fahrzeug 101, beispielsweise ein PKW oder LKW, mit einer Fahrzeugsteuereinrichtung (z.B. einer Electronic Control Unit (ECU)) 102 versehen. Die Fahrzeugsteuereinrichtung 102 weist Datenverarbeitungskomponenten auf, z.B. einen Prozessor (z.B. eine CPU (Zentraleinheit)) 103 und einen Speicher 104 zum Speichern von Steuersoftware 107, gemäß der die Fahrzeugsteuereinrichtung 102 arbeitet, und Daten, die von dem Prozessor 103 verarbeitet werden.

Beispielsweise weist die gespeicherte Steuerungssoftware (Computerprogramm) Anweisungen auf, die, wenn der Prozessor sie ausfuhrt, bewirken, dass der Prozessor 103 Fahrerassistenz -Funktionen ausfuhrt (oder auch Fahrdaten sammelt) oder sogar das Fahrzeug autonom steuert.

In einem solchen Kontext ist es von hoher Wichtigkeit, dass Fehler in der Steuersoftware 107 oder bei der Ausführung der Steuersoftware 107 zuverlässig und schnell erkannt werden.

Deshalb ist es gemäß verschiedenen Ausführungsformen vorgesehen, dass bei der Ausführung der Steuersoftware 107 Log-Daten erzeugt werden (z.B. „im Feld“, d.h. wenn das Fahrzeug unterwegs ist). Diese werden z.B. zunächst vom Prozessor 103 im Speicher 104 (z.B. Arbeitsspeicher) gespeichert und von diesem an eine Aufzeichnungseinrichtung 105 übertragen. Von dieser können sie dann über ein Netzwerk 106 an einen Server 108 übertragen werden. Im Falle der Steuersoftware in einem Fahrzeug ist das Netzwerk 106 ein drahtloses Netzwerk. In dem Fall, dass die Steuersoftware in einer Steuereinrichtung einer stationären Robotervorrichtung (z.B. für einen Industrie-Roboterarm) vorgesehen ist, ist das Netzwerk 106 z.B. ein drahtgebundenes Netzwerk (z.B. ein Ethernet).

Die Übertragung von Log-Daten von der Steuereinrichtung 102 (d.h. ihrem Speicher 104) kann über eine Schnittstelle mit hoher Datenrate (z.B. PCIe (Peripheral Component Interconnect Express) erfolgen.

Im Server 108 können die Log-Daten dann auf verschiedene Weisen analysiert werden. Beispielsweise kann der Server 108 mittels einer Ablaufverfolgung (engl. trace) eine Repräsentation der Ausführung der Steuersoftware 107 in der Form eines Gantt- Diagramms erzeugen, die beispielsweise Aktivierungspunkte, Ausführungsdauem, Datenfluss, jegliche von (Benutzer)-Log-Nachrichten zur Leistungsmessung, eine Algorithmus-spezifische Ablaufverfolgung etc. beinhaltet.

Bei der Ausführung der Steuersoftware 107 von dem Prozessor erzeugte und ausgebende Nachrichten mit Log-Daten (auch als Log -Informationen bezeichnet) sind beispielsweise:

• Text-basierte Log-Nachrichten mit enthaltenen oder angehängten Nachrichtenargumenten und Schweregrad (auch als Log-Level bezeichnet, z.B. fatal, Fehler, Warnung, Info, . . . )

• Ablaufverfolgungsnachrichten mit einem enthaltenen oder angehängten Ablaufverfolgungskontext (Datenfluss, Ausfuhrungsreihenfolge, . . . )

• Ausführungsüberwachungs(engl. profilingj-Nachrichten mit enthaltenem oder angehängtem Zeitkontext (Zeitpunkte, Zeitspannenidentifikationen)

• Ereignisse, ggf. ohne weitere enthaltene oder angehängte Daten (z.B. nur eine Ereignisidentifikation)

• Gekennzeichnete Nutzdatennachrichten (wie in einem Messsystem)

Die ersten vier Typen der oben genannten Nachrichten sind typischerweise klein und enthalten einen statischen und einen dynamischen Teil. Nachrichten vom letzten Typ (d.h. gekennzeichnete Nutzdatennachrichten) können sehr groß sein (z.B. größer als 100 MB für spezielle interne Zustandsdaten). Für einen ganzheitlichen Mechanismus zum Analysieren von Log-Daten müssen beim Loggen aber alle Arten von Daten verfügbar gemacht werden und mit einem gemeinsamen zeitlichen Rahmen verknüpft werden, denn dies erlaubt es beispielsweise dem jeweiligen Entwickler das Systemverhalten unter Verwendung spezieller Wiederholungs- und (graphischer) Analysewerkzeuge zu verfolgen und zu reproduzieren.

Da ein ganzheitlicher Mechanismus betrachtet wird, bezeichnet das „Loggen“, d.h. das Sammeln von Log-Daten, sowohl das Ermitteln der Log-Daten (z.B. Messen) als auch das Aufzeichnen.

FIG. 2 zeigt ein Aufzeichnungssystem 200 für das Loggen für Software, die auf einer Steuereinrichtung 201 ausgeführt wird, in größerem Detail.

Die Steuereinrichtung 201 entspricht beispielsweise der Steuereinrichtung 107. Sie ist über einen PCIe-Bus 203 mit einer Aufzeichnungseinrichtung 202 verbunden, die beispielsweise der Aufzeichnungseinrichtung 105 entspricht. Dazu weisen die Steuereinrichtung 201 und die Aufzeichnungseinrichtung 202 entsprechende PCIe- Treiber 204 und PCIe-Schnittstellen 205 auf.

Die Aufzeichnungseinrichtung 202 weist außerdem einen Ethernet-Treiber 206 und eine Ethernet-Schnittstelle 207 auf, beispielsweise zur Kommunikation mit dem Server 108. Wie oben erwähnt kann dies auch eine drahtlose Kommunikationsschnittstelle (mit entsprechender Treiber- bzw. Kommunikationssoftware) sein. Die Datenübertragung kann über einen „Logger“ (z.B. im Fahrzeug 101) erfolgen, der die Weiterleitung an den Server 108 übernimmt. Der Logger kann beispielsweise dafür verantwortlich sein, die Log-Daten zu verpacken und über eine Mobilfiink- Verbindung an den Server 108 zu übertragen.

Die Steuereinrichtung 201 kann mehrere Prozesse 208 mit mehreren Threads 209 ausführen. Die Threads 209 produzieren Log-Daten, die der Prozessor in Form von Log- Nachrichten 212 ausgibt und die (bzw. deren Inhalt) in einem gemeinsamen Speicher 210 gespeichert werden, der beispielsweise dem Speicher 104 entspricht. Die Übertragung an die Aufnahmeeinrichtung 202 steuert ein Aufzeichnungs-Gateway 211. Die Aufzeichnungseinrichtung 202 weist eine Aufzeichnungs-Bridge und/oder einen Aufzeichnungs-Balancer 213 auf, die bzw. der die Weiterleitung von Log -Daten an den Server 108 steuert.

Um die Analyse von Software 107 nicht nur in ihrer Entwicklungsphase sondern auch im Betrieb (z.B. wie im Obigen Beispiel bei Ihrer Ausführung im Fahrzeug) zu ermöglichen, ist es wünschenswert, dass das Loggen die folgenden Eigenschaften hat:

• Freiheit von Interferenz (z.B. soll keine Synchronisation auf eine gemeinsame Ressource erfolgen, d.h. Software-Threads 209 sollen unabhängig voneinander geloggt werden können).

• Deterministische Ausführung (z.B. sind keine nichtdeterministischen Aktionen wie das Beschaffen von Heap-Speicher erlaubt)

• Zuverlässiger Datentransfer (d.h. keine Daten sollen verloren gehen, da sonst keine vollständige Analyse möglich ist)

Die obigen Erfordernisse haben erhebliche Auswirkungen auf das Design des Log- Mechanismus, da die Log-Nachrichten 212, die von den Threads 209 (also vom Prozessor) in den Speicher 210 geschrieben werden, so kompakt wie möglich sein sollen, so dass sie nicht unnötig Laufzeit-Overhead erzeugen und die Laufzeit-Interferenz minimieren (auch während der Prozessausfuhrung können die Prozesses unterschiedliche Mengen von Lognachrichten ausgeben).

Das Aufzeichnungssystem 200 entkoppelt das Loggen von dem eigentlichen Log-Daten- Transport.

Gemäß verschiedenen Ausführungsformen wird, um die Log -Nachrichten 212 möglichst klein zu halten, jede Log-Nachricht 212 in einen statischen Teil (d.h. statische Log- Daten) und einen dynamischen Teil (d.h. dynamische Log-Daten) aufgeteilt. Die statischen Log-Daten werden zur Kompilationszeit der Software 107 (von der jeweiligen Datenverarbeitungseinrichtung, die die Kompilierung vomimmt) gesammelt. Sie sind somit verfügbar, bevor die Software 107 ausgeführt wird (d.h. bevor die main(.)- Funktion, z.B. im Falle einer in C geschriebenen Software, ausgeführt wird). Dies erfolgt durch Bilden einer verketteten Liste zur Kompilierzeit, wie sie FIG. 3 zeigt.

Figur 3 zeigt eine verkettete Liste 300, die ausgehend von einem Listenkopf 301 eine Verkettung von Knoten 302 enthält.

Jeder Knoten 302 enthält eine Identifikation, statische Log-Daten und einen Zeiger 303 auf den nachfolgenden Knoten 302 (wobei der letzte Knoten auf NULL 304 zeigt).

Die statischen Log-Daten enthalten alle Daten, die aus dem Source-Code der Software entnommen werden können, ohne dass dieser ausgeführt wird. Das bedeutet, dass zur Kompilationszeit die jeweilige Datenverarbeitungseinrichtung, die die Kompilierung vomimmt, durch den Source-Code der Software geht und aus jeder Anweisung zur Ausgabe von Log-Daten, statische Log-Informationen, die darin enthaltenen sind (d.h. die bei der Ausführung dieser Anweisung immer gleich sind), entnimmt, einen zugehörigen Knoten 302 an die Kette 302 anhängt und in diesen die statischen Log -Informationen einfügt.

Beispiele für solche statische Log-Daten einer solchen Anweisung (auch als „Log- Anweisung“ bezeichnet) sind:

• Schweregrad (fatal, Fehler, . . . )

• Ort der Log-Anweisung (Softwarekomponente, Funktion, Datei, Zeile, . . . ) • Argumente der Log-Anweisung (Argumentliste inklusive Argumentnamen und Argument-Typidentifikatoren oder eine Referenz auf einen AST (Abstract Syntax Tree), der nichttriviale Argument-Layouts beschreibt)

• Formatstring (für eine Lazy-Late-Erzeugung der Nachricht, d.h. für ein Verschieben des Aufwands von der Sender- auf die Empfängerseite)

• Ggf. statische Kontextinformation

Die statischen Log-Daten können vorab gespeichert werden, z.B. im Server 108. Dann brauchen zur Übermittlung einer Log -Nachricht 212 nur noch die zugehörigen dynamischen Log-Daten übermittelt zu werden.

Die Log-Anweisung kann auf alle Informationen, die zur Kompilierzeit erstellt werden zugreifen, und nur den dynamischen Teil (d.h. die dynamischen Log-Daten) übertragen. Dies erfolgt beispielsweise über das C++-Sprach-Paradigma „Template Meta- Programming“.

Die dynamischen Log -Daten brauchen nur noch den Laufzeit-Teil der Log-Nachricht enthalten, wie beispielsweise

• die Werte der Argumente der Log-Anweisung

• eine Identifikation der Nachricht (als Referenz auf die statischen Log-Daten der Log-Anweisung) .

• Laufzeit-Kontextinformation (wie beispielsweise die Identifikation des Threads 209, der die Log-Anweisung ausgeführt hat)

Tabelle 1 zeigt ein Beispiel für statische Log-Daten und dynamische Log-Daten für eine durch eine Log-Anweisung ausgegebene Log-Nachricht. Tabelle 1

Da z.B. einem eingebeteten Echtzeit-System kein dynamischer (d.h. Heap-) Speicher verwendet werden kann, haben die Datenstrukturen für die Log-Daten feste Größen (also insbesondere die Datenstrukturen, die die dynamischen Log-Daten für eine jeweilige Log-Nachricht tragen). Dies bedeutet, dass die Anzahl der Argumente einer Log- Anweisung beschränkt sein muss.

In dem obigen Beispiel steht der „Typ“ eines Arguments für übliche Typen wie int, float etc.

Gemäß verschiedenen Ausführungsformen wird aber auch eine Unterstützung für benutzerdefinierte („custom“, z.B. primitive) Log-Anweisungs-Argument-Datentypen (auch als Log-Datentypen) hinzugefügt, indem diese auf spezifische Typenidentifikatoren abgebildet werden. Dies erfolgt dadurch, dass zur Kompilierzeit (von der jeweiligen Datenverarbeitungseinrichtung, die die Kompilierung vomimmt), eine Typenliste erstellt und jedem Typen (ebenfalls zur Kompilierzeit) ein Typenidentifikator (z.B. ein Hash in einer Typen-Hash-Liste, der durch einen zugehörige Hash-Index angegeben werden kann) zugewiesen wird.

Der Hash wird nur für benutzerdefinierte (komplexe) Datentypen benötigt. Er stellt eine Art Quersumme über die Typdefmition dar und wird verwendet, um auf die abstrakte Typbeschreibung zuzugreifen (z.B. aus einem Pool von Klasseninformation). Eine solche Typbeschreibung kann beliebige Datentypen beschreiben (nicht nur die vom Logging direkt unterstützten primitiven Datentypen).

Dies erfolgt beispielsweise durch Meta-Programmierung (also z.B. durch C++ Metaprogrammierung für eine C++ Typenliste im Pall einer in C++ geschriebenen Software 107).

Die Log-Anweisungs-Argument-Datentypen können dann auf einfache Weise mitels eines Deserialisierungs-Handlers (auf Empfängerseite) deserialisiert werden, d.h. die bei der Ausführung einer Log-Anweisung, die einen solchen Log-Argument-Datentyp verwendet, ausgegebenen Rohdaten können mitels eines Deserialisierungs-Werkzeugs in eine Datenstruktur umgewandelt werden, die zu dem Datentyp (der sich ständig, insbesondere im Laufe eines Entwicklungsprozesses, ändern kann), passt, beispielsweise um den Inhalt einer Log-Nachricht, die durch die Log-Anweisung ausgegeben wird, passend auszugeben (z.B. in einer Konsole). Dies ist auch auf eingebetteten Systemen (trotz der dortigen Einschränkungen hinsichtlich dynamischem Speicher) möglich. Nichtdeterministische Serialisierung oder sogar Deserialisierung ist hingegen auf dem eingebetteten System (z.B. einem Steuergerät) beispielsweise nicht erlaubt.

Benutzerdefinierte Log-Anweisungs-Argument-Datentypen sind nützlich, um komplexe Log-Daten-Strukturen auf anonyme Weise für spätere Analyse aufzuzeichnen. Die Deserialisierung von komplexen Datenstrukturen zur Laufzeit ist rechenintensiv und wird deshalb gemäß einer Ausführungsform nicht in der Steuereinrichtung 102 ausgeführt, sondern erfolgt außerhalb, z.B. durch einem von dem Server 108 (d.h. auf Host-Seite) durchgeführten Nachrichtenextraktionsprozess, der erst erforderlich ist, wenn die Log- Daten analysiert werden sollen.

Eür einen benutzerdefinierten Log-Argument-Datentyp enthalten die statischen Log- Daten einer Log-Anweisung einen speziellen Log-Argument-Typenidentifikator, die dem Empfänger der durch die Log-Anweisung ausgegebenen Log-Nachricht (also einer jeweiligen Log-Daten-Senke wie dem Server 108) anzeigt, dass die Log-Argument-Daten in den dynamischen Log-Daten, die die Log-Nachricht enthält, nicht auf triviale Weise interpretiert werden können, sondern Typ-Reflexion erforderlich ist.

Tabelle 2 zeigt ein Beispiel für statische Log-Daten und dynamische Log-Daten für eine durch eine Log-Anweisung ausgegebene Log-Nachricht, wobei die Log-Anweisung einen benutzerdefinierten Log-Argument-Datentyp verwendet.

Tabelle 2

Mit „Benutzerdefinierter Typ“ ist hier der Hash des benutzerdefinierten Log- Anweisungs-Argument-Datentyps (bzw. sein Index in einer Liste von Hash-Werten) gemeint. Der Hash dient als Indikator des Log-Anweisungs-Argument-Datentyps. Mittels des Hash-Index kann in auf Liste von Hash-Werten Liste zugegriffen werden, in welche der Hash zur Compile-Zeit abgelegt wurde. Das erlaubt eine weitere Größenoptimierung der zu übertragenden Daten.

Um einen (komplexen) benutzerdefinierten Log-Datentyp zu registrieren, d.h. zu bewirken, dass er zu der Typenliste hinzugefugt wird und ihm ein Hash (mit zugehörigem Hash-Index) zugewiesen wird, wird (z.B. durch den Benutzer, der den benutzerdefinierten Log-Datentyp verwendet will) in die Software 107 eine Registrierungsanweisung eingefugt. Damit ist der benutzerdefinierten Log-Datentyp dem System (insbesondere der Datenverarbeitungseinrichtung, die kompiliert und die statischen Log-Daten anlegt) bekannt, bevor die statischen Log-Daten angelegt werden (und im Server 108 gespeichert werden).

Tabelle 3 zeigt einen Programmausschnitt, bei dem ein benutzerdefinierter Log-Datentyp definiert wird („EinfachesTraceObjekt“), mittels einer Registrierungs-Anweisung (REGISTER LOG DATA TYPE) registriert wird und von einer Log-Anweisung (LOG INFO) verwendet wird.

Tabelle 3 Vor dem LOG INFO-Aufruf kann eine Instanz von EnfachesTraceObjekt auf dem Stack angelegt werden, durch

EinfachesTraceObjekt traceObjekt; oder auto traceObjekt = EinfachesTraceObjekt{};

Tabelle 4 zeigt ein Beispiel für eine Log-Ausgabe, die durch Deserialisierung aus der dabei ausgegebenen Log-Nachricht erzeugt wird (wobei hier eine Ausgabe in JSON- Format angenommen wird) _

Tabelle 4

Die Strings „activation_sequence_number“, „activation_context_id“, „execution time ns“ und „data sequence numbers“ kommen aus (einem Pool von) Typbeschreibungen (z.B. Klasseninformationen), die bei der Registrierung von benutzerdefinierten Datentypen angereichert werden. Dabei ist der Handle für jede Typbeschreibung der Hash des jeweiligen Datentyps.

Die Registrierung von benutzerdefinierten Log-Anweisungs-Argument-Datentypen wird ein Framework verwendet, das den Hash für den Log-Argument-Datentyp (z.B. einen Klassen-Hash), der den Log-Argument-Datentyp identifiziert, der wiederum die Information des Log-Argument-Datentyps (z.B. Klasseninformation) referenziert.

Diese Information des Log-Argument-Datentyps repräsentiert den Typ-AST, der beim Build-Prozess der Software 107 aus dem Programmcode extrahiert wird. Dies erfolgt beispielsweise mittels einer Clang-Zwischenrepräsentation oder DWARF -Debug- Information, die von dem Compiler erzeugt wird. Die Information des Log-Argument- Datentyps enthält beispielsweise auch ABI (Application Binary Interface) Informationen (z.B. in Form von Flags), die z.B. die verwendete Byte-Reihenfolge (engl. endianness) oder Standard-Speicherausrichtung, die für die dynamischen Log-Daten verwendet werden, angeben. Die Information des Log-Argument-Datentyps (also z.B. Klasseninformation) enthält auch die Bezeichnungen der Inhalte des Datentyps wie sie in Tabelle 4 enthalten sind, also z.B. "activation sequence number" im obigen Beispiel.

Gemäß verschiedenen Ausführungsformen wird ein Deserialisierungs-Framework verwendet, das Werkzeuge und Bibliotheken zum Deserialisieren von Datenströmen, die Roh-C++-Objekte enthalten, mit einer Quellen-ABI (d.h. direkt aus dem Speicher erfasst), enthält. Es kann in ein beliebiges Datenformat deserialisiert werden, indem ein Reflexions-Mechanismus verwendet wird. Nach einem Ziel ABI können die Daten auch wieder zurück in Roh-C++-Objekte umgewandelt werden. Diese Framework ermöglicht es Roh-C++-Daten aus dem Arbeitsspeicher zu verarbeiten, ohne dass eine Serialisierung in der Steuereinrichtung 102 (z.B. ein einem eingebetteten System) erforderlich ist, die die Daten in eine übliche Repräsentation bringt. Auf diese Weise kann ein ausreichender Durchsatz beim Aufzeichnen der Log-Daten gewährleistet werden. (Der Fokus der Herangehensweise liegt auf hohen Datenraten und Lasten und deshalb auf der Schreiboptimierung.) Gemäß einer Ausführungsform verwendet das Deserialisierungs- Framework sognannte Klassen-Infos und ABI-Flags zur Beschreibung von Datentypen- (Standard-)Layouts und Klassen-Hashes zum Identifizieren der Datentyp -Layouts. Eigenständigkeit kann dadurch erreicht werden, dass diese Informationen in den Aufzeichnungsstrom für Deserialisierung in der jeweiligen Log-Daten-Senke (Host, Server) eingefügt werden.

Wie oben erläutert wird bei der Registrierung zur Kompilierzeit der Hash (z.B. Klassenhash) für jeden benutzerdefinierten Log-Daten-Typ extrahiert und dem Hash (der z.B. vier Byte hat) als weitere Optimierungsmaßnahme ein Index zugewiesen, mittels dem er in einer Liste, die den statischen Log-Daten hinzugefügt wird und die ebenfalls zur Kompilierzeit erstellt wird, nachgeschlagen werden kann. Außerdem wird Information für jeden Log-Argument-Datentyp Information (z.B. Klasseninformation) erzeugt und entweder in dem Log-Daten-Datenstrom, der an den Server 108 übertragen wird, verfügbar gemacht (z.B. unter Verwendung eines lesbaren Speichers, der von einer separaten Middleware verwaltet wird) oder indem sie den statischen Log-Daten hinzugefügt werden. Tabelle 5 zeigt dafür entsprechenden Programmcode. Tabelle 5

Da die dynamischen Log-Daten pro Log-Anweisung typischerweise gering sind (d.h. die Objekte, die jeweils die dynamischen Log-Daten für eine Log-Anweisung, enthalten sehr klein sind) werden sie vor ihrem (asynchronen) Transfer (z.B. von dem Speicher 210 an das Aufzeichnungs-Gateway 211) akkumuliert. Ein Grund dafür ist, dass auf modernen Hardware-Plattformen die Übertragung von Speicherinhalten typischerweise ohne Kopieren erfolgt, d.h. die Speicherinhalte werden mittels DMA (Direct Memory Access) übertragen, wobei unmittelbar die Besitzrechte der jeweiligen Speicherbereiche (des Speichers 210) übernommen werden.

Solche Übertragungen sind aber teuer (im Sinne des Rechnen- bzw. Signalisierungsaufwands) und werden deshalb nicht für jede Log-Nachricht 212 durchgeführt. Stattdessen ist die Verwendung einer Speicher-zu-Speicher- Kopieroperation (z.B. memcpy) für die dynamischen Log-Daten einzelner Log- Anweisungen insgesamt weniger teuer, wenn die Menge der dynamischen Log-Daten (pro Log-Anweisung), insbesondere die dynamischen Log-Daten für benutzerdefinierte Log-Anweisungs-Argument-Datentypen, gering ist.

Gemäß einer Ausführungsform hat somit jeder Thread 209 eine dedizierte Stack-artige Datenstruktur im gemeinsamen Speicher 210, die während der Ausführung der Software 107 mit dynamischen Log-Daten gefüllt wird. Die Log-Daten werden dann (z.B. nach Beendigung des jeweiligen Threads oder Prozesses) übertragen, indem der jeweilige Empfänger benachrichtig wird (hier das Aufzeichnungs-Gateway 211, was wiederum den asynchronen Transfer initiiert). Ein Überlauf kann durch eine vorzeitige Benachrichtigung und Übertragung verhinder werden.

Tabelle 6 zeigt ein Beispiel für eine solche Stack-artige Datenstruktur für einen Thread.

Tabelle 6

Mit den Log-Daten können unterschiedliche Prioritäten verknüpft sein. Beispielsweise kann es sein, dass bei Verlust eines Trace-Objekts eine Neuberechnung nicht mehr möglich ist. Deshalb kann der Log-Prozess Priorisierungsfiinktionen, die von den jeweiligen Schnittstellen und Adaptern bereitgestellt werden, nutzen, um eine Log- Nachrichten-Priorisierung zu erzielen.

Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in Figur 4 dargestellt.

Figur 4 zeigt ein Ablaufdiagramm 400, das ein Verfahren zum Übertragen von Log- Daten einer Ausführung eines Computerprogramms gemäß einer Ausführungsform darstellt.

In 401 wird eine indizierte Liste von Identifikatoren von benutzerdefinierten Log- Anweisungs-Argument-Datentypen erzeugt.

In 402 werden vor der Ausführung des Programms für jede Log-Anweisung einer Menge von Log-Anweisungen zur Ausgabe von Log-Daten, die in dem Programm enthalten ist, statische Log-Daten an einen Log-Daten-Empfänger übertragen, wobei die statischen Log-Daten solche Log-Daten sind, die von Ausführung zu Ausführung des Programms für die Log-Anweisung gleich bleiben.

In 403 werden bei der Ausführung des Programms für jede Log-Anweisung der Menge von Log-Anweisungen, die bei der Ausführung des Programms ausgeführt wird, dynamische Log-Daten fur die Log-Anweisung übertragen, wobei die dynamischen Log- Daten solche Log-Daten sind, die sich von Ausführung zu Ausführung des Programms verändern können, und wobei die dynamischen Log-Daten, wenn die Log-Anweisung einen der benutzerdefinierten Log-Anweisungs-Argument-Datentypen zur Ausgabe von dynamischen Log-Daten verwendet, einen Index des Identifikators des Log-Anweisungs- Argument-Datentyps enthält.

Das Verfahren von Figur 4 kann durch einen oder mehrere Computer mit einer oder mehreren Datenverarbeitungseinheiten durchgeführt werden. Der Begriff „Datenverarbeitungseinheit“ kann als irgendein Typ von Entität verstanden werden, die die Verarbeitung von Daten oder Signalen ermöglicht. Die Daten oder Signale können beispielsweise gemäß mindestens einer (d.h. einer oder mehr als einer) speziellen Funktion behandelt werden, die durch die Datenverarbeitungseinheit durchgeführt wird. Eine Datenverarbeitungseinheit kann eine analoge Schaltung, eine digitale Schaltung, eine Logikschaltung, einen Mikroprozessor, einen Mikrocontroller, eine Zentraleinheit (CPU), eine Graphikverarbeitungseinheit (GPU), einen Digitalsignalprozessor (DSP), eine integrierte Schaltung einer programmierbaren Gatteranordnung (FPGA) oder irgendeine Kombination davon umfassen oder aus dieser ausgebildet sein. Irgendeine andere Weise zum Implementieren der jeweiligen Funktionen, die hierin genauer beschrieben werden, kann auch als Datenverarbeitungseinheit oder Logikschaltungsanordnung verstanden werden. Es können ein oder mehrere der im Einzelnen hier beschriebenen Verfahrensschritte durch eine Datenverarbeitungseinheit durch eine oder mehrere spezielle Funktionen ausgeführt (z. B. implementiert) werden, die durch die Datenverarbeitungseinheit durchgeführt werden.

Die Herangehensweise von Figur 4 dient zum Überwachen von Software. Dies kann beispielsweise Steuersoftware für eine Robotervorrichtung sein. Der Begriff „Robotervorrichtung“ kann als sich auf irgendein technisches System (mit einem mechanischen Teil, dessen Bewegung gesteuert wird) beziehend verstanden werden, wie z. B. eine computergesteuerte Maschine, ein Fahrzeug, ein Haushaltsgerät, ein Elektrowerkzeug, eine Fertigungsmaschine, einen persönlichen Assistenten oder ein Zugangssteuersystem. Es wird eine Steuerungsvorschrift für das technische System gelernt und das physikalische System dann entsprechend gesteuert. Die Software kann beispielsweise auf einem eingebetteten System laufen. Obwohl spezielle Ausfuhrungsformen hier dargestellt und beschrieben wurden, wird vom Fachmann auf dem Gebiet erkannt, dass die speziellen Ausfuhrungsformen, die gezeigt und beschrieben sind, gegen eine Vielfalt von alternativen und/oder äquivalenten Implementierungen ausgetauscht werden können, ohne vom Schutzbereich der vorliegenden Erfindung abzuweichen. Diese Anmeldung soll irgendwelche Anpassungen oder Variationen der speziellen Ausfuhrungsformen abdecken, die hier erörtert sind. Daher ist beabsichtigt, dass diese Erfindung nur durch die Ansprüche und die Äquivalente davon begrenzt ist.