-
Stand der Technik
-
Die vorliegende Offenbarung bezieht sich auf Verfahren zum Steuern einer Robotervorrichtung.
-
Bei Steuersoftware für Robotervorrichtungen hat für einige Anwendungen, z.B. für die Steuerung eines Fahrzeugs, insbesondere für ein autonomes Fahrzeug, die Komplexität der in der Software umgesetzten Funktionalitäten eine beträchtliche Komplexität erreicht. Beispiele hierfür sind insbesondere Funktionen zur Umfelderkennung oder zur Verhaltensplanung für das autonome Fahren oder auch Software zum Lernen von Aufgaben wie z.B. für Roboterarme.
-
Es sind Herangehensweisen wünschenswert, die es ermöglichen, solche Funktionen in Robotervorrichtungen, insbesondere mobilen Robotervorrichtungen mit eingeschränkten Verarbeitungsressourcen, effizient und zuverlässig zu implementieren.
-
Offenbarung der Erfindung
-
Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Steuern einer Robotervorrichtung bereitgestellt, aufweisend Ausführen eines Steuerprogramms in der Robotervorrichtung zum Steuern der Robotervorrichtung, Ermitteln, für einen Aufruf einer Funktion in dem Steuerprogramm, ob eine Anforderung an die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von einem externen System erfüllt werden kann, Anfordern, von dem externen System, die Funktion auszuführen, falls die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System erfüllt werden kann, und Ausführen der Funktion intern in der Robotervorrichtung, falls die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System nicht erfüllt werden kann.
-
Das oben beschriebene Verfahren ermöglicht es, dass Berechnungen, die üblicherweise auf (z.B. Fahrzeug-)internen (kompilierten) Programmbibliotheken beruhen, nach extern auslagert werden und damit interne Ressourcen temporär eingespart oder dauerhaft reduziert werden. Der Steuereinrichtung in der Robotervorrichtung, die das Steuerprogramm ausführt, kann beispielsweise ohne Notwendigkeit von Software-Updates eine beständige Service-Schnittstelle (z.B. API) zur Nutzung von Funktionen aus einer oder mehreren Programmbibliotheken angeboten werden, während die Programmbibliotheken in der Community weiterentwickelt und im Backend aktualisiert werden. Hinter der Service-Schnittstelle können Programmbibliotheken auch komplett ausgetauscht werden, falls sich z.B. eine Bibliothek über die Zeit als performanter, genauer oder sicherer herausstellt, um der Steuereinrichtung immer Funktionen mit hoher Qualität zur Verfügung zu stellen. Über die Kombination und Koordination von gleichartigen Programmbibliotheken kann auch mit nicht nach einem Sicherheitsstandard entwickelten Bibliotheken (z.B. Open-Source-Bibliotheken) eine höhere Integrität des zurückgegebenen Ergebnisses erreicht werden (z.B. über Vergleiche oder Majority Voting). Das Verfahren erleichtert auch den Einsatz von LGPL(Lesser General Public License)-Programmbibliotheken.
-
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein Verfahren zum Steuern einer Robotervorrichtung, wie oben beschrieben.
-
Ausführungsbeispiel 2 ist das Verfahren nach Ausführungsbeispiel 1, aufweisend Ausführen eines Funktions-Dienstprogramms in der Robotervorrichtung, Empfangen, durch das Funktions-Dienstprogramm, des Aufrufs der Funktion, Empfangen eines Ergebnisses der Ausführung der Funktion und Zurückliefern des Ergebnisses an das Steuerprogramm.
-
In anderen Worten wird ein Funktions-Aufruf durch einen Dienst-Aufruf ersetzt. Dies ermöglicht die Verteilung des Funktions-Aufrufs an verschiedene Ergebnis-Quellen, insbesondere an das externe System. Das Funktions-Dienstprogramm kann die Ausführung der Funktion von dem externen System anfordern, falls die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System erfüllt werden kann, und die Ausführung der Funktion von einer internen Entität der Robotervorrichtung anfordern, falls die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System nicht erfüllt werden kann. Es wird somit abhängig von der geforderten Integrität, z.B. einer geforderten Integritätsstufe, an die Ausführung der Funktion, entschieden, ob die Funktion intern in der Robotervorrichtung oder mittels einer Anforderung (z.B. eines Diensts-Aufrufs) an ein externes System ausgeführt werden soll. Die jeweilige Quelle (d.h. Datenverarbeitungseinrichtung), mit der die Funktion ausgeführt wird, kann unter mehreren Quellen mit jeweils zugeordneter Integritätsstufe ausgewählt werden, sodass die Anforderung an die Integrität erfüllt wird.
-
Ausführungsbeispiel 3 ist das Verfahren nach Ausführungsbeispiel 2, aufweisend Erzeugen ausführbaren Code des Steuerprogramms aus Quellcode des Steuerprogramms wobei Funktionsaufrufe in dem Steuerprogramm durch Dienst-Aufrufe an das Funktions-Dienstprogramm ersetzt werden.
-
Vor der Ausführung des Steuerprogramms können also automatisch (z.B. für den Programmierer transparent) beispielsweise durch eine entsprechende Programmierumgebung oder ein Tool, Funktions-Aufrufe durch Dienst-Aufrufe ersetzt werden, die die Verteilung des Funktions-Aufrufs an verschiedene Ergebnis-Quellen, insbesondere an das externe System, ermöglichen.
-
Ausführungsbeispiel 4 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 3, aufweisend Überprüfen, ob eine Implementierung der Funktion in der Robotervorrichtung veraltet ist, und Anfordern, von dem externen System, die Funktion auszuführen, falls die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System erfüllt werden kann, und falls die Implementierung der Funktion in der Robotervorrichtung veraltet ist.
-
Die Robotervorrichtung kann somit Funktionen lokal ausführen, sofern sie über aktuelle Versionen verfügt und ansonsten auf eine externe Quelle zurückgreifen, sofern die geforderte Integrität der Ausführung es zulässt.
-
Ausführungsbeispiel 5 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 4, wobei das externe System die Funktion mittels mehrerer Datenverarbeitungseinrichtungen mehrfach ausführt und die Ergebnisse der Ausführungen der Funktion kombiniert, so dass die Integrität der Ausführung der Funktion von dem externen System erfüllt wird.
-
Beispielsweise kann durch eine Mehrheitsabstimmung (engl. majority voting), Vergleiche oder „n-Version-Programming“ die Integritätsstufe der kombinierten Ergebnisse gegenüber der Einzelausführung erhöht werden. Dadurch ist es möglich, mittels des externen Systems eine Integritätsanforderung zu erfüllen, die einzelne Datenverarbeitungsvorrichtungen des externen Systems (z.B. einer Cloud) nicht erfüllen können.
-
Ausführungsbeispiel 6 ist eine Steueranordnung, die eingerichtet ist, ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchzuführen.
-
Die Steueranordnung kann einer Steuereinrichtung, die in der Robotervorrichtung angeordnet ist, entsprechen, kann aber auch zumindest Teile des externen Systems umfassen.
-
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 die Übersetzung eines Programm-Quellcodes in Binärcode, der mit Binärcode einer Programmbibliothek für solche Funktionen zu einem ausführbaren Programm verlinkt wird.
- 3 zeigt die Verteilung eines Funktionsaufrufs durch eines auf einer Steuereinrichtung ausgeführten Programms durch einen internen Funktions-Service.
- 4 zeigt ein Ablaufdiagramm, das ein Verfahren zum Steuern einer Robotervorrichtung 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.
-
Im Beispiel von 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 Arbeitsspeicher 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 ausführt, bewirken, dass der Prozessor 103 Fahrerassistenz-Funktionen ausführt (oder auch Fahrdaten sammelt) oder sogar das Fahrzeug autonom steuert.
-
Eine solche Steuerungssoftware kann komplexe Funktionen 108 verwenden, wie beispielsweise Bayes'sche Filter, sequentielle Monte-Carlo-Methoden, Graph-Algorithmen, SLAM (Simultaneous Localization and Mapping), Neuronale Netze).
-
In dem Fahrzeug 101 sind die Funktionen 108, die von der Steuersoftware 107 verwendet werden, implementiert. Sie bilden somit einen Teil der Steuersoftware 107. Dabei können die Funktionen 108 in den Binärcode der Steuersoftware 107 (d.h. eines ausführbaren Hauptprogramms der Steuersoftware 107) beim Kompilieren des Binärcodes verlinkt sein oder sie können separat dazu (z.B. als dynamische Bibliothek) in den Arbeitsspeicher 103 (von einem nichtflüchtigen Speicher, von dem z.B. auch das Hauptprogramm in den Arbeitsspeicher geladen wird, hier nicht gezeigt) geladen werden, sodass das Hauptprogramm sie bei seiner Ausführung nutzen kann.
-
2 veranschaulicht die Übersetzung eines Programm-Quellcodes 201 in einen Binärcode 202, der mit Binärcode einer Programmbibliothek 203 für Funktionen (wie den oben genannten) zu einem ausführbaren Programm 204 verlinkt wird.
-
Für solche (komplexe) Funktionen existiert eine Vielzahl an Open-Source-Programmbibliotheken mit vordefinierten Funktionen, z.B. für mathematische Operationen, um deren Implementierung in Software zu erleichtern.
-
Beispiele hierfür sind Eigen (lineare Algebra), G2O (Optimierung von graphbasierten nichtlinearen Fehlerfunktionen, z.B. für Lokalisierungsfunktionen), Boost:Geometry (Geometrische Algorithmen, z.B. für Perzeptionsfunktionen), Clothoids (Klothoidenbögen, z.B. für Kartenfunktionen), PCL, suitesparse, ipopt, stl, math, Quantib, etc.
-
Allerdings werden solche Programmbibliotheken häufig in einer offenen Community entwickelt und weiterentwickelt, die keinen konkreten Anwendungsfall adressiert, sondern eine umfassende, generische Sammlung an Modulen und Funktionen anbieten möchte. Daher sind diese Programmbibliotheken oft viel umfangreicher als für einen konkreten Anwendungsfall notwendig und bringen „toten Code“ mit sich, der auch nach der Kompilierung im Programmcode enthalten sein kann, wenn eine solche Bibliothek in einem Programm verwendet wird. Zudem ist oft nur ein Teil der genutzten Anteile einer spezifischen Programmbibliothek für den konkreten Anwendungsfall optimal, während sich der Entwickler bei anderen Funktionen mit nicht-optimalen Umsetzungen zufriedengeben muss.
-
Außerdem werden bei der Entwicklung von Open-Source-Programmbibliotheken typischerweise keine Sicherheitsstandards eingehalten, d.h. es gibt keinen typischerweise keinen systematischen Entwicklungsprozess und keine systematische Dokumentation. Daher ist ihr Einsatz oder zumindest der mancher Funktionen in Situationen, in der sie sicherheitskritisch sind, wie z.B. in einem Fahrzeug, nicht wünschenswert.
-
Ein weiterer Faktor bei der Verwendung von Programmbibliotheken für Steuersoftware ist, da sie von der jeweiligen Community ständig weiterentwickelt und optimiert werden, dass typischerweise die Nutzung der aktuellsten Version (z.B. in einem Fahrzeug) wünschenswert ist (unter Umständen insbesondere aus Sicht von Cybersecurity). Das bedingt aber sowohl für statische als auch dynamische Programmbibliotheken ein Software-Update, welches hinsichtlich Integration in die jeweilige Robotervorrichtung und der damit verbunden Prozessen aufwändig sein kann.
-
In Hinblick auf das Obige ist es deshalb gemäß verschiedenen Ausführungsformen vorgesehen, dass abhängig von verschiedenen Faktoren eine Funktion, die lokal in der jeweiligen Robotervorrichtung (z.B. eine der Funktionen 108, die im folgenden als lokale Funktionen 108 bezeichnet werden) oder eine extern bereitgestellte Funktion 109 (im Folgenden auch als externe Funktion 109 bezeichnet, verwendet 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 die Kommunikation zwischen dem Fahrzeug 101 (allgemein einer Robotervorrichtung, insbesondere einer mobilen Robotervorrichtung) auf Basis von fortgeschrittenen Technologien wie 5G mit sehr geringer Latenz erfolgen.
-
Deshalb können einzelne Berechnungen, die von Funktionen aus einer Programmbibliothek durchgeführt werden, nach extern verschoben werden. Beispielsweise sind extern implementierte Funktionen (d.h. durch gegenüber dem Fahrzeug 101 externe Datenverarbeitungseinrichtungen implementierte Funktionen) 109 Teil einer Programmbibliothek (z.B. Open-Source-Programmbibliothek) 110.
-
Gemäß verschiedenen Ausführungsformen wird hierfür eine Architektur verwendet, in welcher der Aufruf von einer lokalen Funktion 108 (die im Fahrzeug lokal in einer (kompilierten) Programmbibliothek vorliegen), der bei der Ausführung der Steuersoftware 107 durch den Prozessor 103 auftritt, durch ein den Aufruf eines (Funktions-)Services 111 ersetzt wird.
-
Dieser Service 111 verteilt anschließend die angeforderte Berechnung fahrzeugintern durch Aufruf der lokalen Funktion 108 und/oder nach extern auf die entsprechende externe Funktion 109, z.B. einen (Berechnungs-)Service 112, der die entsprechende externe Funktion 109 bereitstellt, der beispielsweise selbst auf der jeweiligen Programmbibliothek 110 aufbaut, zu der die Funktionen 108 gehören, und bei Aufruf der externen Funktion 109 entsprechende Berechnungsergebnisse zurück an die Fahrzeugsteuereinrichtung 102 liefert. Der Funktions-Service 111 verwendet kann zum Aufruf der externen Funktion 109 auch zum Beispiel einen Remote-Procedure-Call.
-
Gemäß verschiedenen Ausführungsformen bietet der Funktions-Service 111 zusätzlich die Möglichkeit, Berechnungsergebnisse aus mehreren, diversitären Quellen zu beziehen und diese zu vergleichen, um darauf aufbauend (im Sinne eines „n-Version-Programming“ mit Vergleich oder Majority Voting) ein Ergebnis mit höherer Sicherheitsintegrität zurückzugeben (z.B. an das Hauptprogramm der Steuersoftware 107).
-
3 zeigt die Verteilung eines Funktionsaufrufs durch eines auf einer Steuereinrichtung 201 ausgeführten Programms (z.B. Steuersoftware-Hauptprogramms) 202 durch einen (z.B. Fahrzeug-)internen Funktions-Service 203.
-
Der Funktions-Service 303 (der als Koordinator arbeitet, also auch als interner Koordinations-Service angesehen werden kann) verteilt den Funktionsaufruf an eine interne Entität 304 oder über eine (z.B. drahtlose, beispielsweise von dem Kommunikationsnetzwerk 106 bereitgestellte) Kommunikationsschnittstelle 306 an ein externes System 305. Jede interne Entität 304 kann eine lokal (insbesondere als Teil der Steuersoftware, die auch das Programm 302 enthält) vorgesehene Funktion sein (z.B. in einer mit der Steuersoftware 302 verlinkten Programmbibliothek) oder auch ein interner Funktions-Dienst sein, z.B. von einem Dienstprogramm, das lokal (auf der Steuereinrichtung 301) ausgeführt wird und auf einer Programmbibliothek basiert.
-
Die jeweilige interne Entität 304 oder das externe System 305, je nachdem wohin der Funktions-Service 303 den Funktions-Aufruf verteilt hat, führt die jeweilige Funktion (z.B. eine Berechnung) aus und liefert das Ergebnis an den Funktions-Service 303 zurück, der das Ergebnis (oder ein Ergebnis, das darauf basiert) an das Programm 302 liefert.
-
Funktionsaufrufe im Programm 302 werden somit durch Service-Aufrufe ersetzt. Dies kann auch nach der eigentlichen Programmierung erfolgen, um dem Programmierer die gewohnte Arbeitsumgebung, inklusive Programmbibliotheken, zu bieten, zum Beispiel durch ein entsprechendes Tool, das den Programmcode vor dessen Kompilierung entsprechend verarbeitet, d.h. Funktionsaufrufe zur Service-Aufrufe ersetzt.
-
Durch zusätzliche Parameter können von dem aufrufenden Programm 302 weitere Anforderungen an den Funktions-Service 303 übermittelt werden, z.B. die geforderte (Sicherheits-)Integrität des Ergebnisses (z.B. „QM“, „ASIL A“, „ASIL B“ nach ISO 26262 oder Integritätsstufen nach anderen Sicherheitsnormen) oder die geforderte maximale Latenz der Antwort auf den Funktionsaufruf.
-
Auf Basis der Anfrage (d.h. des Funktionsaufrufs) und ggf. der Parameter wählt der Funktions-Service 303 aus, wohin der Funktionsaufruf vergeben wird: nach intern (an eine interne Entität 304) oder an das externe System 305 und ob der Funktionsaufruf sogar mehrfach, d.h. an mehrere Ergebnis-Quellen, vergeben wird, um dann die zurückgelieferten Ergebnisse kombinieren zu können, z.B. an ein oder mehrere interne Entitäten 304 und ein oder mehrere externe Funktionsdiente (Berechnungs-Dienste) 307 oder sogar mehrere externe Systeme 305.
-
Der Service 303 kann diese Entscheidung entweder auf Basis der genauen Kenntnis des aktuellen Systemzustands, z.B. aktuelle Latenz der Kommunikation mit dem externen System 305 und der Berechnung in dem externen System 305 (z.B. Cloud) oder Verfügbarkeit und ASIL von Services, treffen oder auf Basis von einfachen Regeln, z.B. Wahl interner Ergebnis-Quellen (Entitäten) 304, wenn die geforderte Latenz unter einem entsprechenden Grenzwert ist oder Auswahl von einer bestimmten Anzahl von Ergebnis-Quellen je nach gefordertem ASIL.
-
Für die Funktionsaufrufe kann eine generische Schnittstelle (Abstraktion) verwendet werden, die es erlaubt, Funktionen aus unterschiedlichen und u.U. wechselnden (externen, sich z.B. in der Cloud befindlichen) Programmbibliotheken für die Berechnung der gleichen Operation zu nutzen.
-
Das externe System 305 kann einen Koordinations-Service 308 bereitstellen, der dort die Berechnungsaufträge koordiniert. Anhand von Metainformationen, die der (interne) Funktions-Service 303 an den externen Koordinations-Service 308 mit einem Funktionsaufruf liefert, kann er es dem Koordinations-Service 308 möglich machen, die Verlässlichkeit der erhaltenen Berechnungsergebnisse zu prüfen, z.B. über Informationen über die Integrität der Quellen und/oder über Zertifikate, und darauf aufbauend auch Daten zu verwerfen. Im Falle einer höheren geforderten Sicherheitsintegrität des Ergebnisses kann der Koordinations-Service 308 Berechnungsergebnisse aus diversitären Quellen anfordern und anschließend vergleichen (einfacher Vergleich oder Majority Voting). Damit ist im Sinne von „Diversity-Off-The-Shelf” prinzipiell auch die Nutzung von „Nicht-ASIL“, QM, „Commercial-Off-The-Shelf“ (COTS) Quellen für sicherheitsbezogene Funktionen möglich. Der Koordinations-Service 308 kann beispielsweise unter Verwendung von zwei COTS-Quellen 307 eine ASIL B-äquivalente Quelle bilden. Die Sicherheitsintegrität des Koordinations-Services 308 muss hierbei mindestens der (maximal) angeforderten Sicherheitsintegrität entsprechen.
-
Eine solche Kombination von Ergebnissen kann auch vom interne Funktions-Service 303 vorgenommen werden. Insbesondere kann der interne Funktions-Service 303 Ergebnisse kombinieren (z.B. vergleichen), die ihm vom externen System 305 und von ein oder mehreren internen Quellen 304 geliefert wurden (wobei das vom externen System 305 seinerseits schon aus einer solchen Kombination durch den Koordinations-Service 308 hervorgegangen sein kann).
-
Je nach geforderter Sicherheitsintegrität einer Berechnung können also vom Funktions-Service 303 unterschiedliche Quellen und Kombination dieser für die Ermittlung des Ergebnisses genutzt werden: für einen „QM-Aufruf“ ist beispielsweise eine „QM-Quelle“ ausreichend, für einen „ASIL B-Aufruf“ müssen eventuell zwei Ergebnisse (z.B. auch von COTS(Commercial off-the-shelf)-Produkten) ermittelt und verglichen werden. Der interne Funktions-Service 303 kann eine entsprechende Kombination von dem externen System 305 anfordern (die der Koordinations-Service 308 dann entsprechend vornimmt).
-
Für einen Funktionsaufruf einer Funktion, z.B. aus einer Programmbibliothek, erfolgt also ein Funktions-Dienst-Aufruf (an den Funktions-Service 303). Dann erfolgen durch den Funktions-Service 303 und ggf. den Koordinations-Service 308 möglicherweise mehrere verteilte Funktions-Dienst-Aufrufe an Quellen 304, 307 und die Ergebnisse werden ggf. durch den Funktions-Service 303 und/oder den Koordinations-Service 308 kombiniert und das Ergebnis der Kombination bzw. das Ergebnis, wenn der Funktionsaufruf nur an eine Quelle 304, 307 verteilt wurde, wird vom Funktions-Service 303 an das Programm 302 zurückgeliefert.
-
Gemäß verschiedenen Ausführungsformen sind z.B. zumindest für sicherheitskritische Funktionen interne Quellen 304 vorgesehen, sodass eine immer verfügbare und per default auswählbare Fallback-Option im Fahrzeug vorhanden ist, so dass auch der (temporäre) Ausfall der Kommunikation nach außen zum externen System 305 überbrückt werden kann.
-
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 4 dargestellt.
-
4 zeigt ein Ablaufdiagramm 400, das ein Verfahren zum Steuern einer Robotervorrichtung gemäß einer Ausführungsform darstellt.
-
In 401 wird ein Steuerprogramm zum Steuern der Robotervorrichtung in der Robotervorrichtung ausgeführt (bzw. dessen Ausführung begonnen).
-
Bei der Ausführung des Steuerprogramms wird in 402 ermittelt, für einen Aufruf einer Funktion in dem Steuerprogramm, ob eine Anforderung an die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von einem externen System erfüllt werden kann.
-
Falls die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System erfüllt werden kann wird in 403 von dem externen System angefordert, die Funktion auszuführen.
-
Falls die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System nicht erfüllt werden kann wird in 404 die Funktion intern in der Robotervorrichtung ausgeführt.
-
Gemäß verschiedenen Ausführungsformen wird entschieden, ob eine Funktion, die sowohl lokal (intern) als auch extern ausgeführt werden kann, intern oder extern ausgeführt wird. Dabei können neben dem Kriterium, ob die Integritätsanforderung erfüllt werden kann, auch weitere Kriterien zu Grunde gelegt werden. Beispielsweise kann eine Funktion auch intern ausgeführt werden, obwohl die Integrität der Ausführung der Funktion durch eine Ausführung der Funktion von dem externen System erfüllt werden kann, wenn dies durch ein anderes Kriterium vorgegeben wird (z.B. eine maximale Latenz durch eine Ausführung auf dem externen System nicht eingehalten werden könnte). „Falls“ ist also gemäß verschiedenen Ausführungsformen nicht als „immer, falls“ zu verstehen sondern beispielsweise als „nur, falls“ oder „höchstens, falls“.
-
Das Verfahren von 4 kann durch einen oder mehrere Computer (oder allgemein Datenverarbeitungsvorrichtungen) 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. Eine oder mehrere solche Datenverarbeitungseinheiten können eine oder mehrere Datenverarbeitungseinrichtungen implementieren.
-
Die Herangehensweise von 4 dient zum Erzeugen eines Steuersignals für eine Robotervorrichtung. 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. Somit kann an die Stelle des Fahrzeugs in den obigen Beispielen eine Robotervorrichtung treten.
-
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.
