DE102022208087A1

DE102022208087A1 - Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten

Info

Publication number: DE102022208087A1
Application number: DE102022208087.4A
Authority: DE
Inventors: Peter Schneider; Sascha Guebner
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2022-08-03
Filing date: 2022-08-03
Publication date: 2024-02-08
Also published as: US20240045854A1; CN117520353A

Abstract

Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten beschrieben, aufweisend Ermitteln, für jede mehrerer Sequenzen von Datenverarbeitungsblöcken, von Referenz-Ergebnisdaten, die sich ergeben, wenn vorgegebene Metadaten durch die Sequenz der Datenverarbeitungsblöcke verarbeitet werden, Empfangen von Nutzdaten-Ergebnisdaten und Metadaten-Ergebnisdaten für eine Datenverarbeitung der Nutzdaten und der Metadaten, Überprüfen, ob die Metadaten-Ergebnisdaten mit für mindestens eine für die Datenverarbeitung der Nutzdaten zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen und Auslösen einer Sicherheitsmaßnahme, falls die Metadaten-Ergebnisdaten für keine für die Datenverarbeitung zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen.

Description

Stand der Technik
Die vorliegende Offenbarung bezieht sich auf Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten.
Sicherheitskritische Anwendungen werden heutzutage meist auf spezieller, dafür entwickelter Hardware ausgeführt. Aus den Sicherheitsanforderungen der Anwendung ergeben sich meist Anforderungen an die Hardware bezüglich Fehleranfälligkeiten und Fehlerraten, die durch nicht-sicherheitskritische kommerziell weit verbreitete Hardware, beispielsweise Prozessoren oder Arbeitsspeicher, oft nicht garantiert werden können. Aktuell existieren jedoch Bestrebungen, sicherheitskritische Anwendungen dennoch auf nicht-sicherheitskritischer Hardware auszuführen, da diese häufig deutlich günstiger und leistungsfähiger ist. Um dies zu ermöglichen werden bestimmte Features der sicherheitskritischen Hardware, wie ein Lock-Step-Modus oder Ähnliches durch Software emuliert.
So kann beispielsweise eine sicherheitskritische Berechnung auf mehreren unabhängigen nicht-sicherheitskritischen Systemen ausgeführt werden und deren Ergebnisse können dann verglichen werden, um mögliche Fehler zu detektieren. Die Datenpfade sind in solchen Systemen naturgemäß komplexer und deren Einhaltung muss durch das Gesamtsystem sichergestellt werden. So muss die korrekte Einhaltung des Bearbeitungspfads (mittels sog. Programmflusskontrollen) über mehrere verarbeitende Bausteine einer sicherheitskritischen Anwendung sichergestellt werden, wenn beispielsweise Daten vor der eigentlichen Analyse noch vorverarbeitet werden müssen, um die korrekte Ausführung der Anwendung sicherzustellen.
Es sind deshalb effektive Herangehensweisen für die Überwachung von Datenverarbeitungen, insbesondere in Hinblick auf den Programmfluss, wünschenswert, insbesondere für verteilte und zur Laufzeit dynamisch rekonfigurierbare Datenverarbeitungssysteme.
Offenbarung der Erfindung
Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten bereitgestellt, aufweisend Ermitteln, für jede mehrerer Sequenzen von Datenverarbeitungsblöcken, von Referenz-Ergebnisdaten, die sich ergeben, wenn vorgegebene Metadaten durch die Sequenz der Datenverarbeitungsblöcke verarbeitet werden, Empfangen von Nutzdaten-Ergebnisdaten und Metadaten-Ergebnisdaten für eine Datenverarbeitung der Nutzdaten und der Metadaten, Überprüfen, ob die Metadaten-Ergebnisdaten mit für mindestens eine für die Datenverarbeitung der Nutzdaten zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen und Auslösen einer Sicherheitsmaßnahme, falls die Metadaten-Ergebnisdaten für keine für die Datenverarbeitung zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen.
Das oben beschriebene Verfahren ermöglicht es, den korrekten Bearbeitungspfad der Daten (z.B. von der Vorverarbeitung, über die Analyse zur Entscheidungsfindung) auch in verteilten und zur Laufzeit dynamisch rekonfigurierbaren Systemen nachzuvollziehen, um damit im Sinne einer Programmabflusskontrolle die vollständige Bearbeitung, sowie die korrekte Reihenfolge der Bearbeitungsschritte einer Datenpipeline sicherzustellen. Das obige Verfahren kann in einfacher Weise ohne Einsatz zusätzlicher spezieller Hardware-Elemente (z.B. Watchdog) implementiert werden und ist damit auf einer Vielzahl an ,off-the-shelf Geräten ausführbar.
Die Sicherheitsmaßnahme beinhaltet beispielsweise, dass die Nutzdaten-Ergebnisdaten verworfen werden und/oder neu berechnet werden. In anderen Worten werden die Nutzdaten-Ergebnisdaten (nur) verwendet (z.B. weiterverarbeitet, z.B. wenn auf deren Grundlage eine Steuerung durchgeführt wird), wenn die Metadaten-Ergebnisdaten mit für mindestens eine für die Datenverarbeitung der Nutzdaten zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmt.
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
Ausführungsbeispiel 1 ist ein Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten, wie oben beschrieben.
Ausführungsbeispiel 2 ist ein Verfahren nach Ausführungsbeispiel 1, ferner aufweisend Empfangen einer Angabe einer Sequenz, wobei die zulässige Sequenz die angegebene Sequenz ist.
Damit wird ermöglicht, dass mehrere Verarbeitungspfade möglich sind, aber verifiziert wird, dass die Verarbeitung auch tatsächlich gemäß dem angegebenen Verarbeitungspfad erfolgt ist.
Ausführungsbeispiel 3 ist ein Verfahren nach Ausführungsbeispiel 1, wobei die mindestens eine zulässige Sequenz eine beliebige der Sequenzen ist.
Damit wird überprüft, ob die Verarbeitung zu mindestens einer (beliebigen) der Sequenzen passt. Dadurch wird ermöglicht, dass die Datenverarbeitung auf flexible Art durchgeführt werden kann, z.B. auf verschiedene Weisen auf Datenverarbeitungseinheiten in einer Cloud verteilt werden kann, solange die durch die entstehende Sequenz verarbeiteten Metadaten zu einer der Referenz-Ergebnisdaten und damit zu einer auf diese Weise als zulässige Sequenz gekennzeichnete Sequenz passt.
Ausführungsbeispiel 4 ist ein Verfahren nach einem der Ausführungsbeispiele 1 bis 3, ferner aufweisend Ermitteln, für jede Sequenz, für mehrere Teilsequenzen der Sequenz, von Teilsequenz-Referenz-Ergebnisdaten, die sich ergeben, wenn Metadaten durch die Teilsequenz der Datenverarbeitungsblöcke verarbeitet werden, Empfangen, zusätzlich zu Ergebnisdaten von Teil-Ergebnisdaten, Überprüfen, falls die Ergebnisdaten für keine für die Datenverarbeitung zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen, ob die Teil-Ergebnisdaten für Teilsequenz-Referenzdaten der mindestens einen zulässigen Sequenz übereinstimmen, und Initiieren einer Wiederholung der Datenverarbeitung ab dem Ende einer Teilsequenz, für die die Teilsequenz-Referenzdaten mit empfangenen Teil-Ergebnisdaten übereinstimmen.
Damit kann vermieden werden, dass eine Datenverarbeitung komplett wiederholt wird, falls festgestellt wird, dass sie nicht in einer zulässigen Sequenz von Datenverarbeitungsblöcken durchgeführt wurde und ein Teil-Ergebnis der Datenverarbeitung, das durch eine zulässige Teilsequenz von Datenverarbeitungsblöcken erzeugt wurde. Damit wird die Neuberechnung gültiger Zwischenergebnisse vermieden.
Ausführungsbeispiel 5 ist ein Verfahren nach einem der Ausführungsbeispiele 1 bis 4, wobei mehrere der Datenverarbeitungsblöcke von derselben Datenverarbeitungsvorrichtung implementiert werden.
Anschaulich erfolgt eine Programmflusskontrolle innerhalb einer Datenverarbeitungsvorrichtung, d.h. mit feinerer Granularität als auf Datenverarbeitungsvorrichtungs-Ebene. Die Datenverarbeitungsblöcke können also beispielsweise auch Programmmodule oder -abschnitte oder andere funktionale Einheiten innerhalb einer Datenverarbeitungsvorrichtung sein.
Ausführungsbeispiel 6 ist eine Datenverarbeitungsvorrichtung, die eingerichtet ist, ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchzuführen.
Diese Datenverarbeitungsvorrichtung ist beispielsweise eine Datensenke für die verarbeiteten Nutzdaten.
Ausführungsbeispiel 7 ist ein Computerprogramm mit Befehlen, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchführt.
Ausführungsbeispiel 8 ist ein Computerlesbares Medium, das Befehle speichert, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchführt.
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.

1 zeigt ein Fahrzeug mit mehreren Steuereinrichtungen als Beispiel für ein verteiltes Datenverarbeitungssystem.
2 veranschaulicht eine Datenverarbeitungspipeline.
3 veranschaulicht eine Datenverarbeitung mit mehreren zulässigen Verarbeitungspfaden.
4 zeigt eine Möglichkeit, um fehlerhafte Verarbeitungspfade frühzeitig zu erkennen.
5 zeigt ein Ablaufdiagramm, das ein Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten 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.
1 zeigt ein Fahrzeug 101 mit mehreren Steuereinrichtungen 102 als Beispiel für ein verteiltes Datenverarbeitungssystem.
Die Steuereinrichtungen 102 sind beispielsweise Electronic Control Units (ECUs) 102, die jeweils eine Verarbeitung durchführen und miteinander verbunden sind und Daten austauschen.
Jede Fahrzeugsteuereinrichtung 102 weist Datenverarbeitungskomponenten auf, z.B. einen Prozessor (z.B. eine CPU (Zentraleinheit)) 103 und einen Speicher 104 zum Speichern von einem jeweiligen Steuerprogramm 105, gemäß der die Fahrzeugsteuereinrichtung 102 arbeitet, und Daten, die von dem Prozessor 103 verarbeitet werden.
Beispielsweise weist für jede Fahrzeugsteuereinrichtung das gespeicherte Steuerungsprogramm 105 (Computerprogramm) Anweisungen auf, die, wenn der jeweilige Prozessor 103 sie ausführt, bewirken, dass die Fahrzeugsteuereinrichtungen 102 zusammen Fahrerassistenz-Funktionen ausführen oder sogar das Fahrzeug 101 autonom steuern.
Die Verteilung von Aufgaben kann sich auch weiter erstrecken als innerhalb des Fahrzeugs 101. Beispielsweise kann über ein Netzwerk 106 auch eine Datenverarbeitungsaufgabe an einen oder mehrere Server 107 (z.B. in eine Cloud) gegeben werden, der ebenfalls ein jeweiliges Steuerprogramm 105 (z.B. Teil eines Gesamtprogramms für die jeweilige Anwendung) ausführt, sodass das verteilte Datenverarbeitungssystem, das eine jeweilige Anwendung (wie hier die Steuerung des Fahrzeugs 101) durchführt, nicht nur die Steuereinrichtungen 102 sondern auch die ein oder mehreren Server 107 aufweist. Dabei können Aufgaben auch dynamisch verteilt werden (insbesondere an den Server 107 ausgelagert werden), sodass ein dynamisches verteiltes System vorliegt.
Um Fehler im Programmablauf oder der Programmausführung (d.h. in obigem Beispiel der Steuerprogramme 105) für eine Anwendung zu detektieren, werden typischerweise für Anwendungen mit strengeren Sicherheitsanforderungen (wie Software für die Fahrzeugsteuerung) zur Entwicklungszeit eine sog. Programmflussanalyse (englisch control flow analysis) durchgeführt, welche die Korrektheit des Programmablaufs bzgl. Reihenfolgen und/oder Zeitverhalten sicherstellen sollen. Die Automotive-Sicherheitsnorm ISO26262-6:2018 fordert solche Analysen, welche sich typischerweise auf die kompilierte Software eines einzelnen Steuergeräts beziehen. Zur Überprüfung des Programmablaufs zur Laufzeit werden typischerweise spezielle Hardware-Einheiten (z.B. Watchdog-Timer oder ASICs) verwendet, mit deren Hilfe Abweichungen vom erwarteten Programmfluss erkannt werden und z.B. durch einen Steuergerät-Reset oder eine Unterbrechung der Kommunikationsschnittstellen sicher abgefangen werden.
Für verteilte und asynchrone Anwendungen oder Anwendungen, die auf nicht-exklusiv genutzten Hardware-Einheiten ausführt werden, sind die oben beschriebenen Programmflusskontrollverfahren jedoch nicht ohne weiteres geeignet, da der Programmablauf aufgrund schwankender Übertragungs- und Ausführungszeiten zeitlich stark variieren kann (ohne, dass die Ausführung dadurch zwingend fehlerhaft wird) und die notwendigen Checkpoints/Signaturen zur Überwachung der korrekten Ablaufreihenfolge zur Entwicklungs- und Kompilierzeit eines einzelnen Elements in einem dynamischen verteilten Systems in der Regel noch gar nicht bekannt sind. Der anwendungsbezogene Kontrollfluss ergibt sich erst zur Laufzeit durch die dynamische Integration einzelner Elemente in eine verteile Anwendung und muss daher zur Laufzeit flexibel konfigurierbar sein.
Gemäß verschiedenen Ausführungsformen wird die Programmausführung (insbesondere hinsichtlich ihres Programmflusses) verifiziert bzw. überwacht, indem in einem verteilten Datenverarbeitungssystem (d.h. einer verteilten Ausführung des jeweiligen Programms) den Daten, die verarbeitet werden sollen, zusätzliche Meta-Daten zugeordnet werden, die auf dem Weg durch das verteilte Datenverarbeitungssystem (also durch die von diesem gebildete verteilte Datenverarbeitungspipeline für die Daten) von den bearbeitenden Verarbeitungseinheiten (Bausteine, Steuergerät, Programmmodule) mittels eines speziellen Verfahrens so modifiziert (verarbeitet) und weitergereicht werden, dass Defekte (insbesondere des Programmflusses) in den Metadaten sichtbar werden. Die jeweilige Datensenke kann anhand der verarbeiteten Metadaten prüfen, ob alle benötigten Bearbeitungsschritte in korrekter Anzahl und Reihenfolge durchgeführt wurden.
2 veranschaulicht eine Datenverarbeitungspipeline 200 mit einem Datenerzeuger 201 (Datenquelle) für zu verarbeitenden Daten (wie z.B. einem LiDAR-Sensor im Fahrzeug 101, der LiDAR-Daten liefert), mehreren Verarbeitungseinheiten 202, 203, 204 und einer Datensenke 205.
Gemäß verschiedenen Ausführungsformen werden die zu verarbeitenden (Nutz-)Daten ND0 von dem Datenerzeuger 201 (z.B. einer Ausgangsschnittstelle einer Sensorvorrichtung) mit zufälligen Metadaten (z.B. ein zufälliges Metadatum in Form eines (Schlüssel-)Werts MD0) ergänzt. Die in der Datenverarbeitungspipeline 200 nachfolgende Verarbeitungseinheit (z.B. ein jeweiliger Baustein, der z.B. eine Vorverarbeitung der Sensordaten durchführt), wendet auf das ursprüngliche Metadatum MD0 eine Funktion (F) unter Verwendung eines persönlichen (d.h. dieser Verarbeitungseinheit zugewiesenen) Schlüssels (PK1) an. Das Ergebnis der Anwendung der Funktion auf MD0, das als MD 1 bezeichnet wird, wird zusammen mit den von der ersten Verarbeitungseinheit 202 verarbeiteten Nutzdaten (ND) an den die nächste Verarbeitungseinheit 203 weitergeleitet, der dann wiederum die Funktion F auf das Metadatum MD 1 unter Verwendung ihres persönlichen Schlüssels (PK2) anwendet und so weiter.
Die Datensenke 205 enthält letztendlich eine verarbeitete Version des ursprünglichen Metadatums MD0, die, wenn jede Verarbeitungseinheit 202, 203, 204 die von ihr erhaltene Version des Metadatums korrekt verarbeitet hat, gleich $MDn' = F (PKn, F (PKn - 1, F (\dots, F (PK 1, M D 0))))$
ist (bei n Verarbeitungseinheiten). Dieser erwartete (Referenz-)Wert MDn' ist der Datensenke 205 bekannt, sodass sie durch Vergleich dieses Werts mit der von ihr empfangenen durch die Verarbeitungseinheiten 202, 203, 204 verarbeiteten Version des Metadatums überprüfen kann, ob alle Verarbeitungseinheiten 202, 203, 204 in der richtigen Reihenfolge das Metadatum (und damit auch die Nutzdaten) verarbeitet haben. Stimmt der Wert MDn' mit der von ihr empfangenen durch die Verarbeitungseinheiten 202, 203, 204 verarbeiteten Version des Metadatums nicht überein, so leitet sie eine entsprechende Sicherheitsmaßnahme ein (z.B. Reset, keine Verwendung des Nutzdatenverarbeitungsergebnisses etc.).
Den Wert MDn' kann die Datensenke 205 beispielsweise aus dem Wissen des ursprünglichen Metadatums MD0, den persönlichen Schlüsseln PKi der Verarbeitungseinheiten 202, 203 204 und der korrekten Berechnungsreihenfolge ermitteln.
Die Verifizierung des Metadatums an der Datensenke 205 benötigt je nach Komplexität der Funktion F ggf. viel Rechenzeit, da F beispielsweise absichtlich so gewählt wird, dass möglichst viele der in der jeweiligen Hardware vorhandenen Verarbeitungseinheiten 202, 203, 204 mindestens kurzzeitig aktiviert werden. Das ist vor allem dann problematisch, wenn das letzte Glied der Kette (d.h. die Datensenke 205) aus deutlich leistungsschwächerer Hardware besteht und ein Nachberechnen der gesamten Metadatenverarbeitung damit eventuell nicht effizient und rechtzeitig möglich ist (beispielsweise weil Vektor-/Matrix-Operation sequentiell in einer einfachen ALU berechnet werden müssen, wodurch die Ausführungsdauer exponentiell steigen kann).
Deshalb wird gemäß einer Ausführungsform das ursprüngliche Metadatum MD0 beispielsweise als Teil einer Folge oder pseudo-zufällig vorab generierter Zahlen gewählt, sodass das Ergebnis MDn' auch vorab berechnet werden kann, um ein schnelleres Prüfen (z.B. mittels einer Look-up-Tabelle) zu ermöglichen und nicht erst bei Eintreffen der Daten an der Datensenke 205 die Funktionskette berechnen zu müssen.
Die Funktion F wird beispielsweise aus möglichst unterschiedlichen Rechenoperationen der jeweiligen Verarbeitungseinheit (z.B. arithmetisch-logischen Einheit) zusammen, bspw. Addition, Subtraktion, Multiplikation, Division sowie logische Operationen wie AND, OR oder XOR und ggf. zusätzliche Vektor-/Matrix oder weitere Operationen von spezielle Hardware-Verarbeitungseinheiten (z.B. AVX oder SSE; sofern in der ausführenden Hardware-Architektur, die der jeweiligen Verarbeitungseinheit zu Grunde liegt, vorhanden). Durch geeignete Wahl der Funktion F kann so die Datensenke 205 auch Fehler in der Berechnungslogik einer Verarbeitungseinheit erkennen, da, selbst wenn die Verarbeitungsreihenfolge korrekt war, die von ihr empfangene verarbeitete Version des Metadatums nicht mit MDn' übereinstimmt, wenn eine Verarbeitungseinheit aufgrund eines Fehlers die Funktion F nicht korrekt berechnet hat, z.B. weil ihre Arithmetisch-logische Einheit defekt ist.
Mindestens der Endpunkt der Verarbeitungskette, d.h. die Datensenke 205, beispielsweise eine Aktuator-Steuereinrichtung in einem Fahrzeug, befindet sich beispielsweise auf einem unabhängigen (sicheren) Gerät (z.B. einer separaten Steuereinrichtung 102), um die vorangegangene (durch die Verarbeitungseinheiten 202, 203, 204 gebildete) Verarbeitungskette unabhängig überprüfen zu können.
Weiterhin wird die Funktion F beispielsweise so gewählt, dass ihre Ausgabe immer die gleiche Größe hat, z.B. sodass sie einen 64 bit Wert ausgibt. Die Eingabe der Funktion kann beispielsweise die Konkatenation des persönlichen Schlüssels mit der jeweiligen (ggf. von einer oder mehreren vorhergehenden Verarbeitungseinheiten 202, 203, 204 vorverarbeiteten) Version des Metadatums sein. Die Funktion wird beispielsweise derart gewählt, dass sie nicht-kommutativ ist, sodass F(PKi, F(PKj, w)) ≠ F(PKj, F(PKi, w)) beispielsweise immer gilt, bzw. eine Gleichheit sehr selten auftritt.
Gemäß verschiedenen Ausführungsformen sind mehrere Bearbeitungspfade zulässig, d.h. die Datensenke akzeptiert nicht nur die in 2 dargestellte Verarbeitungsreihenfolge bzw. das Nutzdatenverarbeitungsergebnis (sofern das Metadatum MD0 korrekt verarbeitet wurde) sondern auch das weiterer Verarbeitungspfade, wie es in 3 dargestellt ist.
3 zeigt eine Verarbeitung mit mehreren zulässigen Verarbeitungspfaden.
In diesem Beispiel erfolgt zunächst (bei korrekter Reihenfolge) eine Verarbeitung durch eine erste Verarbeitungseinheit 301, dann eine Verarbeitung durch eine zweite Verarbeitungseinheit 302 oder durch eine Verarbeitungseinheit 303, dann durch eine vierte Verarbeitungseinheit 304 ggf. gefolgt von weiteren Verarbeitungseinheiten.
Sowohl die Verarbeitung durch die zweite Verarbeitungseinheit 302 als auch die Verarbeitung durch die dritte Verarbeitungseinheit 303 sind zulässig, somit gibt es mehrere zulässige Verarbeitungspfade (hier zwei, aber es kann folgende auf die vierte Verarbeitungseinheit 304 noch weitere Verzweigungen geben, sodass viele unterschiedliche Verarbeitungspfade zulässig sind).
Beispielsweise könnte eine Bild-Vorverarbeitung je nach erkannter Szenerie entweder den einen oder anderen Berechnungspfad einschlagen. Auch komplett unterschiedliche Pfade wären hier möglich, bspw. direkt 301, 304, da die Information, welcher Pfad genommen wurde, im Metadatum enthalten ist.
Die Datensenke 205 (in 3 nicht gezeigt) kann nun überprüfen, ob die Version des Metadatums, die sie empfängt, für einen der zulässigen Verarbeitungspfade mit dem jeweiligen verarbeiteten Metadatum, dass sich bei der Verarbeitung durch den Verarbeitungspfad ergibt, übereinstimmt, d.h. die Datensenke 205 kann eine Liste von korrekten verarbeiteten Metadaten (d.h. MDn' für alle zulässigen Verarbeitungspfade) enthalten. Stimmt kein Wert auf der Liste mit der von der Datensenke 205 empfangenen durch die Verarbeitungseinheiten 202, 203, 204 verarbeiteten Version des Metadatums überein, so leitet sie eine entsprechende Sicherheitsmaßnahme ein (z.B. Reset, keine Verwendung des Nutzdatenverarbeitungsergebnisses etc.)
Es kann den Nutzdaten auch ein weiteres Metadatum hinzugefügt werden, dass Identifikationen und Reihenfolge der durchlaufenen Verarbeitungseinheiten enthält (beispielsweise den Vektor [1,2,4] nach Verarbeitung durch die erste, zweite und vierte Verarbeitungseinheit bzw. den Vektor [1,3,4] nach Verarbeitung durch die erste, dritte und vierte Verarbeitungseinheit). Die Datensenke 205 kann dann zuerst prüfen, ob es sich beim Vektor, den sie zusammen mit den empfangenen Nutzdaten empfängt, um einen zulässigen Verarbeitungspfad handelt und dann, ob der dafür (also für die angegebene Reihenfolge) errechnete Schlüssel MD_n mit dem verarbeiteten Metadatum, das sie von der letzten Verarbeitungseinheit des Verarbeitungspfads empfangen hat, übereinstimmt. Stimmt der für den durch den Vektor angegebenen Verarbeitungspfad berechnete Wert mit der von der Datensenke 205 empfangenen durch die Verarbeitungseinheiten 202, 203, 204 verarbeiteten Version des Metadatums nicht überein, so leitet sie eine entsprechende Sicherheitsmaßnahme ein (z.B. Reset, keine Verwendung des Nutzdatenverarbeitungsergebnisses etc.)
Liegt dem Datenverarbeitungssystem eine Beschreibung zulässiger (z.B. von der jeweiligen Anwendung erlaubter) Berechnungspfade vor, kann (beispielsweise anhand des Vektors) auch an bestimmten Stellen innerhalb der Verarbeitungskette geprüft werden, ob die vorangegangenen Berechnungen entlang zulässiger Verarbeitungspfade erfolgt ist und die Berechnung ggf. frühzeitig eingestellt werden, falls das nicht der Fall ist.
4 zeigt eine weitere Möglichkeit, um fehlerhafte Verarbeitungspfade frühzeitig zu erkennen.
Hier ist eine redundant ausgelegte Berechnung (zweite Verarbeitungseinheit 402 und dritte Verarbeitungseinheit 403) vorgesehen, deren Ergebnisse an einen Komparator 404 weitergeleitet werden. Dessen Aufgabe ist es, die von diesen Verarbeitungseinheiten 402, 403 erzeugten Daten (das kann die verarbeiteten Nutzdaten als auch die verarbeiteten Metadaten betreffen) auf Gleichheit bzw. ggf. auf Ähnlichkeit zu prüfen, um zu detektieren, ob ein Berechnungsfehler z.B. durch defekte Hardware auftrat. Durch die Nutzung (d.h. den Vergleich) der von den Verarbeitungseinheiten 402, 403 verarbeiteten Metadaten MD2 und MD2' kann hier ein Berechnungsfehler, der ggf. nur zu leicht verändertem (aber trotzdem potenziell unsicherem) Nutzdatenergebnis geführt hat frühzeitig erkannt werden und beispielsweise zum Abbruch der Berechnung führen.
Die oben beschriebene Vorgehensweise kann zur Prüfung der korrekten und vollständigen Berechnungsfolge von mehreren Berechnungsbausteinen eingesetzt werden und/oder zur Prüfung der korrekte Abfolge der Berechnungen innerhalb eines Berechnungsbausteins. Beispielsweise können Checkpoints im Code vorgesehen werden (wobei an jedem Checkpoint ein zugeführtes Metadatum (weiter-)verarbeitet wird) und am Ende der Verarbeitung durch einen Baustein wird geprüft, ob alle Checkpoints in einer zulässigen Reihenfolge passiert wurden. Nur dann gilt die Verarbeitung durch den Baustein als korrekt. Die Überprüfung innerhalb von Bausteinen ermöglicht eine feingranulare Prüfung des Programmablaufs.
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 5 dargestellt.
5 zeigt ein Ablaufdiagramm 500, das ein Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten gemäß einer Ausführungsform darstellt.
In 501 werden für jede mehrerer Sequenzen von Datenverarbeitungsblöcken Referenz-Ergebnisdaten ermittelt, die sich ergeben, wenn vorgegebene Metadaten durch die Sequenz der Datenverarbeitungsblöcke verarbeitet werden.
In 502 werden Nutzdaten-Ergebnisdaten und Metadaten-Ergebnisdaten für eine Datenverarbeitung der Nutzdaten und der Metadaten empfangen.
In 503 wird überprüft, ob die Metadaten-Ergebnisdaten mit für mindestens eine für die Datenverarbeitung der Nutzdaten zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen.
In 504 wird eine Sicherheitsmaßnahme ausgelöst, falls die Metadaten-Ergebnisdaten für keine für die Datenverarbeitung zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen.
Die Referenz-Ergebnisdaten können vorab ermittelt (und gespeichert) werden (wobei das Ermitteln auch nur darin bestehen kann, dass die Referenz-Ergebnisdaten empfangen werden, z.B. von der Datenquelle) oder erst nach Empfang der Metadaten-Ergebnisdaten ermittelt werden, d.h. die Reihenfolge von 501 bis 504 ist nicht auf die in 5 dargestellte Reihenfolge festgelegt.
Das Verfahren von 5 kann durch einen oder mehrere Computer mit einer oder mehreren Datenverarbeitungseinheiten durchgeführt werden. Insbesondere kann jede (oder zumindest manche) der Datenverarbeitungsblöcke einer Datenverarbeitungseinheit entsprechen. 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.
Das Verfahren von 5 kann insbesondere auf eine Datenverarbeitung zum Erzeugen eines Steuersignals für eine Robotervorrichtung, z.B. aus von der Robotervorrichtung aufgenommenen Sensordaten, angewendet werden. 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 technische System dann entsprechend gesteuert.
Verschiedene Ausführungsformen können Sensorsignale von verschiedenen Sensoren wie z. B. Video, Radar, LiDAR, Ultraschall, Bewegung, Wärmeabbildung usw. empfangen und verwenden, die verarbeitet werden. Die Datenverarbeitung kann die Klassifikation der Sensordaten oder das Durchführen einer semantischen Segmentierung an den Sensordaten umfassen, beispielsweise um die Anwesenheit von Objekten (in der Umgebung, in der die Sensordaten erhalten wurden) zu detektieren.
Obwohl spezielle Ausführungsformen hier dargestellt und beschrieben wurden, wird vom Fachmann auf dem Gebiet erkannt, dass die speziellen Ausführungsformen, 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 Ausführungsformen abdecken, die hier erörtert sind. Daher ist beabsichtigt, dass diese Erfindung nur durch die Ansprüche und die Äquivalente davon begrenzt ist.

Claims

Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten, aufweisend: Ermitteln, für jede mehrerer Sequenzen von Datenverarbeitungsblöcken, von Referenz-Ergebnisdaten, die sich ergeben, wenn vorgegebene Metadaten durch die Sequenz der Datenverarbeitungsblöcke verarbeitet werden; Empfangen von Nutzdaten-Ergebnisdaten und Metadaten-Ergebnisdaten für eine Datenverarbeitung der Nutzdaten und der Metadaten; Überprüfen, ob die Metadaten-Ergebnisdaten mit für mindestens eine für die Datenverarbeitung der Nutzdaten zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen; Auslösen einer Sicherheitsmaßnahme, falls die Metadaten-Ergebnisdaten für keine für die Datenverarbeitung zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen.
Verfahren nach Anspruch 1, ferner aufweisend Empfangen einer Angabe einer Sequenz, wobei die zulässige Sequenz die angegebene Sequenz ist.
Verfahren nach Anspruch 1, wobei die mindestens eine zulässige Sequenz eine beliebige der Sequenzen ist.
Verfahren nach einem der Ansprüche 1 bis 3, ferner aufweisend Ermitteln, für jede Sequenz, für mehrere Teilsequenzen der Sequenz, von Teilsequenz-Referenz-Ergebnisdaten, die sich ergeben, wenn Metadaten durch die Teilsequenz der Datenverarbeitungsblöcke verarbeitet werden, Empfangen, zusätzlich zu Ergebnisdaten von Teil-Ergebnisdaten, Überprüfen, falls die Ergebnisdaten für keine für die Datenverarbeitung zulässige Sequenz der Sequenzen mit den für die Sequenz ermittelten Referenz-Ergebnisdaten übereinstimmen, ob die Teil-Ergebnisdaten für Teilsequenz-Referenzdaten der mindestens einen zulässigen Sequenz übereinstimmen, und Initiieren einer Wiederholung der Datenverarbeitung ab dem Ende einer Teilsequenz, für die die Teilsequenz-Referenzdaten mit empfangenen Teil-Ergebnisdaten übereinstimmen.
Verfahren nach einem der Ansprüche 1 bis 4, wobei mehrere der Datenverarbeitungsblöcke von derselben Datenverarbeitungsvorrichtung implementiert werden.
Datenverarbeitungsvorrichtung, die eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 5 durchzuführen.
Computerprogramm mit Befehlen, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ansprüche 1 bis 5 durchführt.
Computerlesbares Medium, das Befehle speichert, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ansprüche 1 bis 5 durchführt.