-
Stand der Technik
-
Die vorliegende Offenbarung bezieht sich auf Verfahren zum Betreiben einer Robotervorrichtung.
-
Offenbarung der Erfindung
-
Die in Software umgesetzten Funktionalitäten für den Betrieb von Robotervorrichtungen hat für einige Anwendungen, z.B. für die Steuerung eines Fahrzeugs, einen beträchtlichen Umfang erreicht.
-
Beispielsweise beschreibt die Veröffentlichung „Standardisiertes E-Gas Überwachungskonzept für Benzin und Diesel Motorsteuerungen“, Arbeitskreis EGAS, 08.07.2015, Version 6.0, im Folgenden als Referenz 1 bezeichnet, verschiedene Funktionen für die Motorsteuerung und deren Überwachung, die in drei Ebenen, („Ebene 1“ bis „Ebene 3“) eingeteilt sind.
-
Es sind Herangehensweisen wünschenswert, die es ermöglichen, solche Funktionen in Robotervorrichtungen, insbesondere (z.B. mobilen) Robotervorrichtungen mit eingeschränkten Verarbeitungsressourcen, effizient und zuverlässig zu implementieren.
-
Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Betreiben einer Robotervorrichtung bereitgestellt, aufweisend Senden, an eine zur Robotervorrichtung externen Überwachungseinrichtung, von Sensordaten zur Überwachung eines Istwerts für eine physikalische Größe, die beim Betrieb der Robotervorrichtung in oder an der Überwachung eines Istwerts für eine physikalische Größe, die beim Betrieb der Robotervorrichtung in oder an der Robotervorrichtung auftritt, auf der Grundlage eines Sollwerts für die physikalische Größe, durch die externe Überwachungseinrichtung, Aktivieren, falls bei der Überwachung festgestellt wird, dass die Abweichung zwischen Istwert und Sollwert eine vorgegebene Schwelle überschreitet, eines abgesicherten Betriebsmodus der Robotervorrichtung, Überprüfen, ob ein oder mehrere Funktionen zur Ermittlung des Sollwerts und des Istwerts und zur Überwachung des Istwerts, die zumindest teilweise in der externen Überwachungseinrichtung durchzuführen sind, durchgeführt wurden und Aktivieren des abgesicherten Betriebsmodus, falls detektiert wird, dass die ein oder mehreren Funktionen nicht durchgeführt worden sind.
-
Das oben beschriebene Verfahren gewährleistet die Sicherheit bei der Auslagerung einer Überwachungsfunktion in einer externe Überwachungseinrichtung, d.h. in ein externes System wie ein Edge-Computing-Netzwerk oder eine Cloud.
-
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein Verfahren zum Betreiben einer Robotervorrichtung, wie oben beschrieben.
-
Ausführungsbeispiel 2 ist ein Verfahren nach Ausführungsbeispiel 1, ferner aufweisend Überprüfen, ob eine Kommunikationsverbindung zwischen der Überwachungseinrichtung und der Robotervorrichtung, über die die Überwachungseinrichtung die Aktivierung der Sicherheitsmaßnahme auslösen kann, besteht und Aktivieren des sicheren Betriebsmodus, falls die Kommunikationsverbindung unterbrochen ist.
-
Dies erhöht weiter die Sicherheit der Auslagerung der Überwachungsfunktion, da vermieden wird, dass der sichere Betriebsmodus nicht aktiviert wird (obwohl es nötig wäre), da die Konnektivität zwischen Robotervorrichtung und externer Überwachungseinrichtung verloren gegangen ist.
-
Ausführungsbeispiel 3 ist ein Verfahren nach Ausführungsbeispiel 1 oder 2, wobei die ein oder mehreren Funktionen in einer Sequenz durchzuführen sind und überprüft wird, ob ein oder mehrere Funktionen ausgeführt wurden, indem geprüft wird, ob eine der Sequenz zugeführter Anfrage-Nachricht, die von jeder der Funktionen bei Ausführung der Funktion verarbeitet wird, von der Sequenz zu einer erwarteten Antwort verarbeitet wurde.
-
Dies ermöglicht einen effektiven Test der Verarbeitungskette inklusive der extern ausgeführten Funktionen, d.h. eine Ablaufkontrolle, die die ausgelagerten Funktionen mit einbezieht.
-
Ausführungsbeispiel 4 ist ein Verfahren nach einem der Ausführungsbeispiele 1 bis 3, aufweisend, vor der Überwachung, Prüfen, ob die externe Verarbeitungseinrichtung den abgesicherten Betriebsmodus der Robotervorrichtung aktivieren kann, und Ausgeben eines Fehlersignals, falls die externe Verarbeitungseinrichtung den abgesicherten Betriebsmodus der Robotervorrichtung nicht aktivieren kann.
-
Dadurch kann sichergestellt werden, dass die Aktivierung des abgesicherten Betriebsmodus möglich ist, wenn die Überwachung ergibt, dass er aktiviert werden soll.
-
Ausführungsbeispiel 5 ist ein Verfahren nach Ausführungsbeispiel 4, aufweisend Durchführen der Überwachung in der Robotervorrichtung, falls die externe Verarbeitungseinrichtung den abgesicherten Betriebsmodus der Robotervorrichtung nicht aktivieren kann.
-
Damit ist auch für den Fall, dass die externe Verarbeitungseinrichtung den abgesicherten Betriebsmodus nicht aktivieren kann, ein Betrieb mit Überwachung möglich.
-
Ausführungsbeispiel 6 ist ein Roboterüberwachungssystem, das eingerichtet ist, ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchzuführen.
-
Das Roboterüberwachungssystem beinhaltet Komponenten der Robotervorrichtung und kann auch die externe Überwachungseinrichtung beinhalten.
-
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.
- 2 veranschaulicht eine Architektur zur Auslagerung einer Überwachungsfunktion in ein externes System (Cloud oder Edge) aus einem Fahrzeug über eine drahtlose Verbindung.
- 3 zeigt eine Ausführungsform, bei der Diagnosefunktionen für die Eingangsdaten in dem externen System erfolgen.
- 4 zeigt eine Ausführungsform, in der neben den Diagnosefunktionen auch Applikationsfunktionen in das externe System verschoben und dort überwacht werden.
- 5 zeigt ein Ablaufdiagramm, das ein Verfahren zum Betreiben einer Robotervorrichtung veranschaulicht.
-
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.
-
Im Beispiel von 1 ist ein Fahrzeug 101, beispielsweise ein PKW oder LKW, mit einer Fahrzeugsteuereinrichtung (z.B. bestehend aus einer oder mehreren Electronic Control Units (ECU)) 102 versehen.
-
Die Fahrzeugsteuereinrichtung 102 weist Datenverarbeitungskomponenten auf, z.B. einen Prozessor (z.B. eine CPU (Zentraleinheit)) 103 und einen Arbeitsspeicher 104 zum Speichern von Steuersoftware 107, gemäß der die Fahrzeugsteuereinrichtung 102 arbeitet, und Daten, die von dem Prozessor 103 verarbeitet werden. Die Fahrzeugsteuereinrichtung 102 kann mehrere Datenverarbeitungsvorrichtungen aufweisen (z.B. ECUs), die über ein internes Kommunikationsnetz (z.B. einen CAN-Bus) miteinander verbunden sind. Diese können die Steuerungssoftware 107 auch verteilt ausführen.
-
Beispielsweise weist die gespeicherte Steuerungssoftware (Computerprogramm) Anweisungen auf, die, wenn der Prozessor sie ausführt (oder mehrere Prozessoren sie verteilt ausführen), bewirken, dass der Prozessor 103 (oder die Prozessoren) Fahrerassistenz-Funktionen ausführt (oder auch Fahrdaten sammelt) oder sogar das Fahrzeug autonom steuert.
-
Zukünftige Fahrzeug-E/E-Architekturen werden voraussichtlich stark mit externen Systemen, z.B. Cloud, Edge, anderen Fahrzeugen, Smart Devices, vernetzt sein, da z.B. auf Basis der 5G-Technologie die Kommunikation zwischen den Systemen mit sehr geringer Latenz erfolgen kann. Das wird die Möglichkeit bieten, während des Fahrbetriebs Ressourcen außerhalb des Fahrzeugs zu nutzen, um z.B. Funktionen auszulagern oder externe Sensorik in die Bildung des eigenen Umfeldmodells einzubinden. Je nach Auslagerungsgrad ist denkbar, dass auch die Überwachung von Fahrzeugfunktionen (z.B. Motorsteuerung) nach außen (z.B. Cloud, Edge) vergeben bzw. durch externe Systeme unterstützt wird.
-
Beispielsweise kann das Fahrzeug 101 (praktisch dauerhaft, oder zumindest für große Zeitabschnitte seines Betriebs) die mit einem externen System 105 wie z.B. einem oder mehreren Servern einer Cloud oder einer Edge-Computing Plattform vernetzt sein (hier über ein Kommunikationsnetz 106) und eine Kommunikation zwischen dem Fahrzeug 101 (allgemein einer Robotervorrichtung, insbesondere einer mobilen Robotervorrichtung) und dem externen System 105 mit geringer Latenz bereitgestellt werden (z.B. mittels 5G).
-
Gemäß verschiedenen Ausführungsformen wird eine Überwachungsfunktionalität, die insbesondere einen Vergleich eines Istwerts mit einem Sollwert oder einem Schwellwert (der z.B. eine maximale Abweichung von einem Sollwert repräsentiert) beinhaltet, ausgelagert, also im Beispiel von 1 in dem externen System 105, z.B. einer Cloud, statt intern im Fahrzeug 101, ausgeführt.
-
Dies beinhaltet Sicherheitsfunktionalitäten für die Cloud-basierte (oder Edgebasierte) (Funktion-)Überwachung von Fahrzeugsystemen, wie z.B. die Motorsteuerung. Im Folgenden wird als Beispiel eine Architektur beschrieben, mit der die Funktionsüberwachung (d.h. die Funktionalität der Ebene 2 im Sinne von Referenz 1) von einem Fahrzeug 101 (allgemein einer Robotervorrichtung) in ein externes System 105 (z.B. eine Cloud) verschoben werden kann.
-
Damit können die Ressourcen für die Ebene 2-Anteile der Steuerung (Software (SW) und Hardware (HW), z.B. reservierter Speicherbereich) im Fahrzeug 101 eingespart werden. Hierbei können Ressourcen des externen Systems 105 auch mehrfach genutzt werden, z.B. wechselnd für sich im Betrieb befindliche Fahrzeuge, eventuell auch parallel für mehrere Fahrzeug.
-
Durch die Auslagerung kann auch die Auswirkung fahrzeuginterner latenter Fehler (z.B. dauerhaft korrupter Speicherbereiche) und transienter Fehler (z.B. temporär, z.B. durch Alpha-Teilchen, veränderter Speicherbereiche) reduziert werden, die zur Reduzierung der Verfügbarkeit fahrzeuginterner Ressourcen führen können, da weniger fahrzeuginterne HW-Ressourcen (z.B. für die Überwachung reservierter Speicherbereich) genutzt werden.
-
Damit reduzieren sich auch weiter die fahrzeugintern notwendigen Maßnahmen zur Gewährleistung der „Freedom from Interference“ (FFI) zwischen der ASIL X-Sicherheits-Software (Ebene 2) und der QM(Quality Management)-Anwendungs-Software, da eine physische Trennung über die kabellose Schnittstelle (d.h. das Netzwerk 106) erfolgt. Außerdem können Eingriffe von Ebene 1-SW in die Ebene 3-SW (im Sinne der Referenz 1) in der Cloud erkannt werden.
-
Anpassungen der Überwachungsfunktion, die durch Änderungen in der Anwendungs-Software (SW-Updates oder Konfigurationsänderungen) notwendig werden, können rein in dem externen System 105 erfolgen.
-
Alle HW-bezogenen Anteile der Überwachung (z.B. I/O Pins, Bus, uC) können im Feld (d.h. z.B. beim eingesetzten Fahrzeug) unverändert bleiben und können durch die beschriebene Architektur ausreichend abgesichert werden.
-
Durch die Auslagerung von Überwachungsfunktionalität kann diese selbst umfangreicher und detaillierter und damit rechenintensiver gestaltet werden, da Ressourcen im externen System 105 (wie einer Cloud) erheblich weniger beschränkt sind als im Fahrzeug 101.
-
Bei der Bestimmung der passenden (sicheren) Fehlerreaktion können Kontextinformationen (z.B. Fahrzeugumgebung), die (nur) in dem externen System 105 verfügbar sind, berücksichtigt werden (z.B. keine sofortige Abschaltung bei Fehler, falls keine Gefahr besteht). Dies kann auch in einer hybriden Variante genutzt werden: Das externe System 105 greift nur - mit engeren Überwachungsgrenzen - ein, wenn sich das Fahrzeug in einer seltenen E1- oder E2-Situation (nach der Klassifikation von Häufigkeiten von Situationen gemäß ISO 26262) befindet, die engere Grenzen benötigt.
-
Die Überwachungsfunktionalität kann von dem externen System 105 als Service angeboten werden (z.B. mit einem entsprechenden Preismodell (z.B. pay-peruse)).
-
Gemäß verschiedenen Ausführungsformen beinhaltet die Architektur eine abstrahierte Schnittstelle zwischen dem Fahrzeug 101 und dem externen System 105 wodurch der Einsatz von austauschbaren ECU-HW-Modulen je Fahrzeug (z.B. SoCs mit höherer Rechenleistung) unterstützt wird, da die funktionale Überwachung unabhängig von der konkreten fahrzeuginternen HW im externen System 105 erfolgen kann.
-
2 veranschaulicht eine Architektur zur Auslagerung einer Überwachungsfunktion 201 in ein externes System (Cloud oder Edge) aus einem Fahrzeug über eine drahtlose Verbindung 202.
-
Die Funktionen der Ebenen 1, 2, 3 im Sinne von Referenz 1 sind mit L1, L2 bzw. L3 gekennzeichnet. Die Funktionen unterhalb der gestrichelten Linie, die die Verbindung 202 kennzeichnet, werden im Fahrzeug bereitgestellt und die Funktionen oberhalb der gestrichelten Linie im externen System.
-
Im Fahrzeug werden Eingaben 203 für die Überwachung erzeugt und geliefert, z.B. über eine Bus-Schnittstelle (z.B. CAN), eine digitale Sensorschnittstelle (SPI), einen analoge Sensorschnittstelle (mit einem Analog-Digital-Wandler ADC) oder über Variablenwerte in einem RAM.
-
Diese werden dann zunächst von einer HW-Eingabediagnostikeinrichtung 204 überprüft (z.B. bei redundanten Sensoren darauf, dass die Sensordaten zusammenpassen). Die HW-Eingabediagnostikeinrichtung 204 hat beispielsweise Funktionen für eine Bus-Diagnostik 205, Schnittstellen-Diagnostik 206, ADC-Diagnostik 207 und RAM-Diagnostik 208.
-
Die überprüften Ergebnisse liefert die HW-Eingabediagnostikeinrichtung 204 an eine Konnektivitätssteuereinheit (CCU) 218, die sie, ggf. zusammen mit Metadaten wie Anforderungen von Systemen im Fahrzeug, als Daten 209 an die Überwachungsfunktion 201 übermittelt.
-
Außerdem liefert die HW-Eingabediagnostikeinrichtung 204 die überprüften Eingabedaten an eine Applikationssoftware 210. Diese erzeugt ein oder mehrere Applikationsergebnisse, beispielsweise einen Sollwert (z.B. ein mittels des Gaspedals eingestelltes Moment). Diese wird von der Konnektivitätssteuereinheit 218 an das externe System geliefert.
-
Die Bereitstellung der Daten 209 und der Applikationsergebnisse 211 von der Konnektivitätssteuereinheit 218 an das externe System erfolgt beispielsweise als Service.
-
Stellt die Überwachungsfunktion 201 einen Fehler fest (z.B. ein mittels des Gaspedals eingestelltes Moment weicht stark von einem erzeugten Moment, das sie aus den in den Daten 206 enthaltenen Messdaten ermittelt, ab), so schickt sie ein Fehlersignal an einen Abschalt-Manager 212. Dieser informiert über eine durch die Konnektivitätssteuereinheit 205 bereitgestellte Watchdog-Kommunikationsfunktionalität 213 einen Watchdog (WD) 214 im Fahrzeug der bei einem Fehler eine Abschaltung oder Einschränkung 215 von Funktionen des Fahrzeugs vornimmt (d.h. einen abgesicherten Betriebsmodus aktiviert), z.B. mittels ein oder mehrere Hardware-Signale an ein Relais, eine Stromversorgungsstufe, einen Bus-Transceiver, einen Schalter (z.B. IGBT) etc. Beispielsweise kann die Geschwindigkeit des Fahrzeugs reduziert werden oder im Falle eines autonomen Fahrzeugs das Fahrzeug an den Rand fahren und anhalten.
-
Die Watchdog-Kommunikationsfunktionalität 213 und der Watchdog 214 stellen so einen sicheren, von außen aktivierbaren Abschaltpfad bzw. Übergangspfad (für einen Übergang in einen sicheren Zustand (z.B. Abschaltung Stromversorgung Endstufen, Deaktivierung Bus-Kommunikation) aus dem externen System bereit.
-
Das externe System, insbesondere die Komponenten, die die Überwachungsfunktion 201 und den Abschalt-Manager 212 implementieren, kann als Überwachungseinrichtung angesehen werden, die extern zu der Robotervorrichtung ist.
-
Es kann vorgesehen sein, dass der Abschaltpfad auf latente Fehler geprüft werden kann (d.h. darauf, ob über den Watchdog 214 die Abschaltung oder Einschränkung 215 vorgenommen werden kann). Diese Prüfung wird z.B. zu Beginn eines Betriebszyklus vorgenommen und kann auch aus dem externen System durchgeführt werden, z.B. durch den Abschalt-Manager 212.
-
Außerdem kann vorgesehen sein, dass die Überwachungsfunktion 201 auch das Verhalten eines digitalen Zwillings (DT für Digital Twin) 222 in die Überwachung einbezieht bzw. aus dem digitalen Zwilling selbst eine Anforderung für eine Abschaltung oder Einschränkung an den Abschalt-Manager 212 gegeben wird, der den Watchdog 214 entsprechend benachrichtigt.
-
Das Kommunikationsmodul, d.h. die Konnektivitätssteuereinheit 218 kommuniziert nach außen und gibt Nachrichten aus der dem externen System intern weiter. In die Konnektivitätssteuereinheit 218 ist beispielsweise ein SW-Modul integriert, das die Watchdog-Kommunikationsfunktionalität 213 bereitstellt, d.h. mit dem Watchdog 214 kommuniziert, wobei bei Ausfall des Kommunikationsmoduls (und damit dem Ausfall des Durchgriffs aus dem externen System auf das Fahrzeug) der Watchdog 214 automatisch getriggert wird, sodass er die Abschaltung oder Einschränkung 215 vornimmt.
-
Alternativ kann der Watchdog 214 auch Teil der CCU 218 sein bzw. die CCU 218 einen direkten Durchgriff auf den Abschaltpfad (z.B. Endstufen, Kommunikations-Bus) haben.
-
Im Fahrzeug ist weiterhin eine Hardware-Diagnostik/FFI-Einrichtung 216 vorgesehen, die eine Funktion 217 zur Diagnose von internen Hardwarekomponenten wie z.B. Prozessoren (CPU, TPU, GPU etc.) und zur Gewährleistung von FFI aufweist.
-
3 zeigt eine Ausführungsform, bei der Diagnosefunktionen für die Eingangsdaten im externen System 301 erfolgen. Beispielsweise kann das externen System folgende Diagnosefunktionen ausführen:
- • Bus (CAN, SPI): Prüfung über End-to-End-Absicherungsmaßnahmen, z.B. Prüfsumme (Korrektheit) und/oder Frame-Counter (Timing)
- • Sensordaten: Plausibilitätscheck einzelner oder mehrerer Sensoren auf Basis von Redundanz und/oder eines physikalischen Modells, z.B. zwei unabhängige Messungen (Drehzahl, Strom, Spannung, Moment, ...)
- • RAM: z.B. Vergleich Doppelablage
-
Damit können, falls jeweilige Voraussetzungen erfüllt sind (z.B. End-to-End-Absicherungsmaßnahmen in Bus-Nachrichten, Verfügbarkeit von Sicherheitsmetadaten, Plausibilisierungsmöglichkeit über ein physikalisches Modell) die Diagnose der Eingangsgrößen in die Überwachung ebenfalls teilweise oder ganz in das externe System 105 verschoben werden.
-
4 zeigt eine Ausführungsform, in der neben den Diagnosefunktionen 401 auch Applikationsfunktionen 402 (Ebene 1) in das externe System verschoben und dort überwacht (Ebene 2) werden.
-
Unabhängig davon, welche Funktionen ausgelagert werden, werden gemäß verschiedenen Ausführungsformen systeminterne Funktionen und Schnittstellen für die Durchführung einer Ablaufkontrolle im externen System bereitgestellt. Diese sorgen dafür, dass systeminterne Sicherheitsfunktionen wie die Funktionen 205, 206, 207, 208, 218 zur (z.B. HW-)Diagnose und Gewährleistung der FFI ausgeführt wurden. Dazu weist die Architektur eine PFC- und Metadaten-Überwachungseinrichtung 219 auf.
-
In 2 ist die Ablaufkontrolle (PFC für Program Flow Check durch den strichpunktierten Nachrichtenfluss dargestellt.
-
Der Watchdog schickt eine Anfrage-Nachricht 220 („Query“, z.B. einen 8-BitWert) 501 an die internen Komponenten Systems und erwartet eine Antwort („Response“, z.B. 32-Bit) innerhalb eines Zeitfensters. Hier schickt sie die Anfrage-Nachricht 220 zunächst an die Hardware-Diagnostik/FFI-Einrichtung 216, die sie an die HW-Eingabediagnostikeinrichtung 204 weiterleitet. Die HW-Eingabediagnostikeinrichtung 204 schickt die Anfrage-Nachricht 220 weiter an die Überwachungsfunktion 201 und diese an die PFC- und Metadaten-Überwachungseinrichtung 219. Wie in 2 gezeigt, weisen die Funktionen der Hardware-Diagnostik/FFI-Einrichtung 216, der HW-Eingabediagnostikeinrichtung 204 und der Überwachungsfunktion 201 PFC-Funktionen auf, die die Anfrage-Nachricht 220 verarbeiten, auf eine jeweilige vorgegebene Art verarbeiten sodass, wenn die Anfrage-Nachricht 220 alle Funktionen durchlaufen hat, also alle diese Funktionen ausgeführt wurden, die so verarbeitete Anfrage-Nachricht 221 einen bestimmten erwarteten Wert aufweist. Die verarbeitete Anfrage-Nachricht 221 ist nur dann korrekt (d.h. enthält den erwarteten Wert), wenn alle Funktionen, die auf diese Weise PFC-verknüpft sind, in der richtigen Reihenfolge aufgerufen wurden.
-
Die PFC- und Metadaten-Überwachungseinrichtung 219 vergleicht diesen erwarteten Wert mit dem, den die von ihr empfangene verarbeitete Anfrage-Nachricht 221 enthält und gibt entsprechend eine Antwort (über den Abschalt-Manager 212) an den Watchdog. Die Antwort zeigt bei Übereinstimmung der Werte dem Watchdog an, dass die Funktionen ausgeführt wurden, oder bei Abweichung, dass mindestens eine Funktion nicht ausgeführt wurde. Im letzten Fall kann der Watchdog geeignet reagieren, z.B. wiederum eine Abschaltung oder Einschränkung 215 von Funktionen des Fahrzeugs vornehmen oder zumindest einen Fehlerzähler hochzählen und eine Abschaltung oder Einschränkung 215 von Funktionen des Fahrzeugs vornehmen, wenn der Zähler eine Schwelle überschreitet. Auch bei nicht rechtzeitiger Antwort kann der Watchdog auf diese Weise reagieren.
-
Im Beispiel von 2 wird die Antwort (zumindest zum Teil) im externen System berechnet. Dadurch wird durch die PFC auch die Verfügbarkeit des externen Systems geprüft. Die PFC-Funktionalität von der PFC- und Metadaten-Überwachungseinrichtung 219, d.h. den Vergleich der verarbeiteten Anfrage-Nachricht 221 mit dem erwarteten Wert kann aber auch vom Watchdog übernommen werden. Nichtsdestotrotz kann die Anfrage-Nachricht 220 über das externe System geführt werden, um dessen Verfügbarkeit mittels des PFC zu überwachen.
-
Die Ablaufkontrolle kann analog für die Architekturen von 3 und 4 implementiert werden, wie dort durch die PFC-Funktionen der verschiedenen Einheiten und die strichpunktierten Pfade angedeutet ist.
-
Für die oben beschriebenen Funktionalitäten wird eine geeignete Vernetzung, d.h. eine stabile, idealerweise sogar redundante Verbindung vom Fahrzeug 101 (allgemein eine Robotervorrichtung) in die Cloud (allgemein das externe System) bereitgestellt, z.B. über 5G, 5G+, 6G, im gesamten Einsatzbereich der Robotervorrichtung bzw. die oben beschriebenen Funktionalitäten werden nur eingesetzt, wenn eine solche Vernetzung vorhanden ist. Beispielsweise kann vor Beginn einer Fahrt eine prädiktive Einschätzung des erreichbaren QoS (Quality of Service) entlang der geplanten Route erfolgen.
-
Die Vernetzung wird dabei so bereitgestellt (bzw. geprüft, ob sie dieses Erfordernis erfüllt, bevor die Überwachung ausgelagert wird), dass die Kommunikation zwischen Cloud und Fahrzeug mit ausreichend niedriger Latenz erfolgen kann, damit die insgesamt zu erreichende Fehlertoleranzzeit (inklusive Entprellung) nicht überschritten wird (ca. 500ms für Motorsteuerung, HV-Batterie, hybrider Antriebstrang; 200ms für elektrischer Antrieb).
-
Es kann eine initiale Synchronisierung der Fahrzeug- und Cloud-Funktionen vorgesehen sein, z.B. beim Start des Fahrzeugs. Außerdem kann eine regelmäßige Re-Synchronisierung während des Betriebs vorgesehen sein, um z.B. beide Funktionsanteile auch nach Wechsel zwischen Basis-Stationen für die Kommunikation (z.B. im 5G-Netzwerk) synchron zu halten. Die Cloud (d.h. allgemein das externen System) und das Fahrzeug (allgemein die Robotervorrichtung) können alternativ eine gleiche absolute Zeitbasis nutzen.
-
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 5 dargestellt.
-
5 zeigt ein Ablaufdiagramm 500, das ein Verfahren zum Betreiben einer Robotervorrichtung veranschaulicht.
-
In 501 werden an eine zur Robotervorrichtung externen Überwachungseinrichtung Sensordaten zur Überwachung eines Istwerts für eine physikalische Größe, die beim Betrieb der Robotervorrichtung in oder an der Robotervorrichtung auftritt, auf der Grundlage eines Sollwerts für die physikalische Größe, durch die externe Überwachungseinrichtung. Dies bedeutet, dass die Sensordaten der Überwachungseinrichtung die Ermittlung des Istwerts und/oder des Sollwerts ermöglichen, sodass sie den Istwert überwachen kann.
-
In 502 wird, falls bei der Überwachung festgestellt wird, dass die Abweichung zwischen Istwert und Sollwert eine vorgegebene Schwelle überschreitet, ein abgesicherter Betriebsmodus der Robotervorrichtung aktiviert.
-
In 503 wird überprüft, ob ein oder mehrere Funktionen zur Ermittlung des Sollwerts und des Istwerts und zur Überwachung des Istwerts, die zumindest teilweise in der externen Überwachungseinrichtung durchzuführen sind, durchgeführt wurden.
-
In 504 wird der abgesicherte Betriebsmodus aktiviert, falls detektiert wird, dass die ein oder mehreren Funktionen nicht durchgeführt worden sind.
-
Der abgesicherte Betriebsmodus kann verschiedene Sicherheitsmaßnahmen wie oben beschrieben beinhalten. Diese brauchen nicht in allen Fällen des abgesicherten Betriebsmodus übereinstimmen, d.h. die Sicherheitsmaßnahmen, die ergriffen werden, wenn die Abweichung die vorgegebene Schwelle überschreitet, können sich von denen unterscheiden, die ergriffen werden, wenn detektiert wurde, dass die ein oder mehreren Funktionen nicht durchgeführt worden sind.
-
Die Robotervorrichtung ist beispielsweise mobil. In diesem Fall kann „extern“ bedeutet, dass sich die Überwachungseinrichtung nicht notwendig mit der Robotervorrichtung mitbewegt (also stationär ist oder zumindest unabhängig davon bewegt werden kann). Extern kann auch so verstanden werden, dass die Robotervorrichtung und die Komponenten der Überwachungseinrichtung in getrennten Gehäusen enthalten sind (wobei sie nicht notwendig jeweils nur in einem Gehäuse enthalten sein brauchen). Die Überwachungseinrichtung ist über eine Kommunikationsverbindung, beispielsweise über ein Kommunikationsnetzwerk, z.B. ein drahtloses Kommunikationsnetzwerk, z.B. ein Mobilfunk-Netzwerk, mit der Robotervorrichtung verbunden.
-
Das Verfahren von 5 kann durch eine oder mehrere Datenverarbeitungseinheiten (intern in der Robotervorrichtung und extern zur Robotervorrichtung) 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.
-
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.
-
Verschiedene Ausführungsformen können Sensorsignale von verschiedenen Sensoren wie z. B. Video, Radar, LiDAR, Ultraschall, Bewegung, Wärmeabbildung usw. empfangen und verwenden, beispielsweise um den Sollwert und/oder den Istwert zu ermitteln.
-
Die Schnittstelle zwischen Robotervorrichtung und externer Überwachungseinrichtung kann derart ausgestaltet sein, dass sie abstrahiert, welche aus einer Menge von möglichen Hardwarekomponenten in der Robotervorrichtung eingesetzt werden, d.h. sodass die genaue Hardware der Robotervorrichtung für die externe Überwachungseinrichtung transparent ist. Insbesondere kann die Hardware der Robotervorrichtung ausgetauscht werden, ohne die Überwachung zu beeinträchtigen.
-
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.
