DE102021114191A1

DE102021114191A1 - Verteiltes System

Info

Publication number: DE102021114191A1
Application number: DE102021114191.5A
Authority: DE
Inventors: Tadanobu Toba; Takumi UEZONO; Yutaka Uematsu; Kenichi Shimbo
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2020-06-10
Filing date: 2021-06-01
Publication date: 2021-12-16
Also published as: CN113778025A; JP2021196678A; US20210390795A1

Abstract

Ein verteiltes System umfasst ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, und einen Diagnosedaten-Computer. Das Edge-Device weist einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller auf, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert. Hier empfängt der Diagnosedaten-Computer: Diagnosedaten, die einen internen Zustand im In-Edge-Controller anzeigen.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein verteiltes System mit einem Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist.
2. Beschreibung des Stands der Technik
JP-A-2010-55545 offenbart ein System, das einen anormalen Zustand vor dem Abgleich mit einer Datenbank vergangener Fehler auf der Basis von Zustandsdaten, wenn in einem Fahrzeug (eines der Edge-Devices) eine Anomalie aufgetreten ist, klassifiziert und dann in der Fehlerdatenbank nur Teile sucht und analysiert, die für diese Klassifizierung relevant sind. In diesem System erfolgt die Klassifizierung des anormalen Zustands auf Seiten des Fahrzeugs, die Klassifizierungsdaten werden zur Zentrale übertragen, und eine detaillierte Analyse wird auf Seiten der Zentrale durchgeführt, wodurch die fahrzeugseitige Last reduziert werden kann, ohne die Unterscheidungsgenauigkeit der Anomaliesursache zu verringern.
Es ist abzusehen, dass der Controller (Steuergerät) im Edge-Device, der den Bewegungsmechanismus im bewegten Körper wie z.B. den Motor oder den Betätigungsmechanismus in einer Ausrüstung wie z.B. den Hydraulikdruck steuert, komplexer werden wird, um einen automatisch betreibbaren bewegten Körper zu realisieren. In diesem Fall kann das Steuergerät im Edge-Device interne Zustände verschiedener Art annehmen. Die Behebung dieser internen Zustände (insbesondere von anormalen Zuständen) ist nicht auf interne Zustände der Art beschränkt, die nur in einem Edge Device 12 wiederherstellbar sind.
Da jedoch in JP-A-2010-55545 der interne Zustand (insbesondere ein anormaler Zustand) der ECU (eines der Steuergeräte im Edge-Device) selbst nicht außerhalb des Edge-Device übertragen wird, kann der interne Zustand nicht in Kooperation mit einem Computer außerhalb des Edge-Device behandelt werden.
Eine Aufgabe der vorliegenden Erfindung ist die Bereitstellung einer Technik zum Umgang mit dem internen Zustand eines Controllers in einem Edge-Device durch Kooperation des Edge-Device mit einem Computer außerhalb des Edge-Device.
KURZFASSUNG DER ERFINDUNG
Die vorliegende Anmeldung umfasst eine Vielzahl von Mitteln, um mindestens einen Teil der obigen Probleme zu lösen, und Beispiele dafür sind wie folgt:
Das verteilte System nach einem ersten Aspekt umfasst ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Diagnosedaten-Computer und einen Hersteller-Computer, der ein Computer ist, der einem Hersteller des Edge-Device gehört. Das Edge-Device weist einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller auf, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert. Hier empfängt der Diagnosedaten-Computer Diagnosedaten, die einen internen Zustand im In-Edge-Controller anzeigen, führt auf der Basis der Diagnosedaten einen Ursachenanalyseprozess des Zustands im In-Edge-Controller durch, und überträgt die Daten nach dem Ursachenanalyseprozess oder auf der Basis des Ergebnisses des Ursachenanalyseprozesses verbesserte Daten für das Edge-Device zum Hersteller-Computer.
Das verteilte System nach einem zweiten Aspekt umfasst ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Dienstanbieter-Computer, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet, und einen Analyse-Outsourcing-Computer. Das Edge-Device weist einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller auf, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert. Hier führt der Analyse-Outsourcing-Computer auf der Basis des Zustands des In-Edge-Controllers einen dienstbezogenen Analyseprozess durch, der ein Analyseprozess ist, der sich auf einen bestimmten Dienst bezieht, und überträgt die Daten, die durch den dienstbezogenen Analyseprozess erhalten wurden, nach dem dienstbezogenen Analyseprozess zum Dienstanbieter-Computer.
Das verteilte System nach einem dritten Aspekt umfasst ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Diagnosedatenmanagement-Computer, einen Analyse-Outsourcing-Computer, einen Edge-Datendistributor-Computer und einen Dienstanbieter-Computer, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet. Das Edge-Device weist einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller auf, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert.
Hier empfängt der Diagnosedatenmanagement-Computer Diagnosedaten, die einen Zustand im In-Edge-Controller anzeigen, überträgt die Diagnosedaten zum Edge-Datendistributor-Computer und überträgt die Diagnosedaten gemäß einem ersten Zeitplan zum Analyse-Outsourcing-Computer.
Der Edge-Datendistributor-Computer empfängt vom Diagnosedatenmanagement-Computer Diagnosedaten, speichert die Diagnosedaten in einer Speicherressource, verarbeitet die in der Speicherressource gespeicherten Diagnosedaten gemäß einem zweiten Zeitplan, der ein längeres Intervall als der erste Zeitplan hat, und überträgt die verarbeiteten Diagnosedaten zum Dienstanbieter-Computer.
Der Analyse-Outsourcing-Computer führt auf der Basis des Zustands des In-Edge-Controllers einen dienstbezogenen Analyseprozess durch, der ein Analyseprozess ist, der sich auf einen bestimmten Dienst bezieht, und überträgt die Daten, die durch den dienstbezogenen Analyseprozess erhalten wurden, nach dem dienstbezogenen Analyseprozess zum Dienstanbieter-Computer.
Das verteilte System nach einem vierten Aspekt umfasst ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Diagnosedatenmanagement-Computer und einen Hersteller-Computer, der ein Computer ist, der einer Herstellerfirma des Edge-Device gehört. Das Edge-Device weist einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller auf, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert. Hier empfängt der Diagnosedaten-Computer Diagnosedaten, die den internen Zustand im In-Edge-Controller anzeigen, und sendet die Diagnosedaten oder die verarbeitete Diagnosedaten an einen anderen Computer.
Der vorliegenden Erfindung gemäß ist es möglich, den internen Zustand eines Controllers in einem Edge-Device durch Kooperation des Edge-Device mit einem Computer außerhalb des Edge-Device zu behandeln.
Andere Probleme, Konfigurationen und Wirkungen als die oben beschriebenen gehen aus der Beschreibung der folgenden Ausführungsformen hervor.
Figurenliste

1 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel eines verteilten Systems zeigt;
2 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel eines Edge-Device zeigt;
3 ist ein Diagramm, das ein Beispiel einer Computerhardware-Konfiguration zeigt;
4 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel eines Edge-Device-Hersteller-Computers zeigt;
5 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel einer Diagnosedaten-Cloud zeigt;
6 ist ein Diagramm, das einen Verarbeitungsablauf eines verteilten Systems in einer ersten Lösung zeigt;
7 ist ein Diagramm, das ein Beispiel eines Diagnosemodell-Definitionsbildschirms zeigt;
8 ist ein Diagramm, das einen Verarbeitungsablauf eines verteilten Systems in einer zweiten Lösung zeigt.
9 ist ein Diagramm, das ein Beispiel eines Ergebnisbildschirms der Ursachenanalyse für einen Händler oder einen Reparaturbetrieb zeigt;
10 ist ein Diagramm, das einen Verarbeitungsablauf eines verteilten Systems in einer dritten Lösung zeigt; und
11 ist ein Diagramm, das ein Beispiel eines Ergebnisbildschirms der Ursachenanalyse für eine Vermietungsfirma oder ein MaaS (Mobility as a Service (Mobilitätsdienst))-Unternehmen zeigt.

BESCHREIBUNG VON AUSFPUHRUNGSFORMEN
Wenn dies in den folgenden Ausführungsformen der Einfachheit halber erforderlich ist, ist die Beschreibung im Folgenden in mehrere Abschnitte oder Ausführungsformen unterteilt, die jedoch, sofern nicht anders angegeben, nicht voneinander unabhängig sind und sich auf einen Teil oder die Gesamtheit der anderen Modifikationen, Details, ergänzenden Erklärungen und dergleichen beziehen.
Wenn in den folgenden Ausführungsformen auf die Anzahl von Elementen (einschließlich der Anzahl, des Zahlenwerts, der Menge, des Bereichs und dergleichen) Bezug genommen wird, ist die Anzahl nicht auf die spezifische Anzahl beschränkt und kann mehr oder weniger als die spezifische Anzahl sein, außer, wenn dies ausdrücklich angegeben ist und die Anzahl grundsätzlich eindeutig auf eine bestimmte Anzahl beschränkt ist.
Ferner versteht es sich, dass die Elemente (einschließlich der Elementschritte und dergleichen) in den folgenden Ausführungsformen nicht unbedingt wesentlich sind, es sei denn, wenn dies ausdrücklich angegeben ist oder die Elemente eindeutig als im Prinzip wesentlich zu betrachten sind.
Dementsprechend sind, wenn in den folgenden Ausführungsformen auf die Form, die Lagebeziehung usw. einer Komponente oder dergleichen Bezug genommen wird, auch solche eingeschlossen, die der Form im Wesentlichen nahe kommen oder dieser ähnlich sind oder dergleichen, es sei denn, wenn dies ausdrücklich angegeben ist oder wenn klar ist, dass dies im Prinzip nicht der Fall ist. Dies gilt auch für die obigen Zahlenwerte und Bereiche.
In allen Zeichnungen zur Veranschaulichung der Ausführungsformen werden gleiche Elemente grundsätzlich durch gleiche Bezugszeichen bezeichnet, und deren wiederholte Beschreibung wird ausgelassen. Im Folgenden wird jede Ausführungsform der vorliegenden Erfindung Bezug nehmend auf die Zeichnungen beschrieben.
Ausführungsformen der vorliegenden Erfindung werden im Folgenden beschrieben. Im Folgenden wird der Einfachheit der Beschreibung halber eine Ausführungsform beschrieben, die einen Cloud-Server (manchmal einfach als Cloud abgekürzt) verwendet, statt des Cloud-Servers ist jedoch auch ein Computer verwendbar. Ferner ist die Beschreibung einer Ausführungsform, die einen Computer verwendet, auch auf eine Cloud anwendbar. Der Cloud-Server besteht aus mindestens einem oder mehreren Computern.
<Systemkonfiguration>
1 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel eines verteilten Systems zeigt. Ein verteiltes System 1000 ist mehrschichtig und umfasst ein oder mehrere Edge-Devices 12, eine oder mehrere Clouds oder Computer, die in einer Datenmanagementschicht 30 enthalten sind, und eine oder mehrere Clouds oder Computer, die in einer Datennutzungsschicht 31 enthalten sind.
Das Edge-Device 12 kann zum Beispiel ein bewegter Körper (zum Beispiel ein Fahrzeug, eine Drohne oder ein Roboter) oder eine Ausrüstung (zum Beispiel ein Roboterarm, eine Werkzeugmaschine, eine numerisch gesteuerte Drehmaschine oder dergleichen) sein, die automatisch betreibbar sind. Automatisches Fahren ist ein Beispiel für den „automatischen Betrieb“.
Das Edge-Device 12 umfasst einen Bewegungsmechanismus (im Falle eines bewegten Körpers zum Beispiel eine Brennkraftmaschine oder ein Motor) oder einen Betätigungsmechanismus (im Falle einer Ausrüstung ein Aktuator wie z.B. ein Motor oder Hydraulikdruck) 17 und einen In-Edge-Controller (zum Beispiel eine ECU: Elektronische Steuereinheit) 10, der den Bewegungsmechanismus oder den Betätigungsmechanismus 17 steuert, und einen Sensor (zum Beispiel GPS: globales Positionsbestimmungssystem) 18. Weitere spezifische Beispiele dieser Komponenten werden weiter unten beschrieben. „Betätigung“ bedeutet mindestens, dass „die Vorrichtung ihren Betriebszustand einem Befehl entsprechend ändert, indem eine bestimmte Operation durchgeführt wird (JIS B 0132-konform)“. In der folgenden Beschreibung wird der Einfachheit der Beschreibung halber stellvertretend der Fall beschrieben, dass das Edge-Device 12 ein bewegter Körper ist. Daher wird in der Beschreibung des Bewegungsmechanismus oder des Betätigungsmechanismus 17 stellvertetend der Fall des Bewegungsmechanismus beschrieben.
Der In-Edge-Controller 10 kann als ECTL (Edge Con-TroLer) abgekürzt sein. Ferner übernimmt der In-Edge-Controller 10 mindestens einen Teil der Verarbeitung zur Realisierung des automatischen Betriebs des Edge-Device 12. Dadurch wird der In-Edge-Controller 10 hardware- oder softwaremäßig immer komplexer. Als Beispiel für die Komplexität der Hardware können z.B. eine GPU (Graphikprozessor) und ein FPGA (feldprogrammierbares Gate-Array), ein dedizierter Prozessor für neuronale Netze und andere Hardware, die das Maschinenlernen beschleunigt, eingeschlossen sein, um die Maschinenlernverarbeitung einzuführen und die Verarbeitung zur Erkennung und Bestimmung der Dateneingabe von verschiedenen Sensoren und Kameras in Echtzeit durchzuführen.
<<Datenmanagementschicht>>
Die Datenmanagementschicht 30 ist eine virtuelle Schicht oder Gruppe, die zur Vereinfachung der Erklärung eingeführt wurde. Die in dieser Schicht enthaltenen Clouds umfassen eine Cloud, die vom Edge-Device 12 erzeugte Daten speichert, im Gegensatz zur weiter unten beschriebene Datennutzungsschicht 31.
Eine Cloud, die der obigen Beschreibung nicht entspricht, kann in die Datenmanagementschicht 30 aufgenommen werden, und eine Cloud, die der obigen Beschreibung entspricht, kann aus dieser Schicht ausgenommen werden. In 1 wird Folgendes als Beispiel für Clouds oder Computer dargestellt, die in dieser Schicht enthalten sind (nachstehend auch als Datenmanagementschicht-Clouds bezeichnet).
Edge-Datendistributor-Cloud 24: Diese Cloud speichert Daten in Bezug auf das Edge-Device 12 (im Folgenden als Edge-Daten bezeichnet), und überträgt unverarbeitete oder verarbeitete Edge-Daten auf Anforderung einer anderen Cloud an diese Cloud. Als Beispiele für Edge-Daten lassen sich neben den Sensordaten D12 des Sensors 18 des Edge-Device 12 die Konfigurationsinformation des Edge-Device 12 und dergleichen anführen. Beispiele der Datenverarbeitung in dieser Ausführungsform sind die Änderung der Datencodierung, die Berechnung von Differenzwerten, die Berechnung von statistischen Werten, die Verschlüsselung, die Entschlüsselung, die Komprimierung, die Dekomprimierung, die Entfernung unnötiger Daten, der Zusatz oder die Entfernung von Redundanzcodes und die Datenextraktion. Wenn Daten, die von der verarbeitenden Entität empfangen werden, teilweise oder komplett verändert und übertragen wurden, ist dies als Verarbeitung zu verstehen. In dieser Beschreibung können die Daten nach der Verarbeitung einfach als „verarbeitete Daten“ bezeichnet werden.
Diagnosedatenmanagement-Cloud 26: Diese Cloud zeigt den internen Zustand des In-Edge-Controllers 10 an, speichert Diagnosedaten (nachstehend als In-Edge-Controller-Diagnosedaten oder ECTL-Diagnosedaten bezeichnet) zur Diagnose außerhalb dieses Controllers und überträgt unverarbeitete oder verarbeitete Edge-Daten in Reaktion auf eine Anforderung von einer anderen Cloud. ECTL-Diagnosedaten sind ein Beispiel für Edge-Daten.
Computer des Edge-Device-Herstellers (nachstehend als Edge-Device-Hersteller-Computer oder als Hersteller-Computer bezeichnet) 21: Dieser Computer ist ein Computer, der einem Unternehmen gehört, das das Edge-Device 12 entwickelt oder herstellt. Da der Hersteller Edge-Daten für die Entwicklung und Wartung seiner eigenen Produkte speichert, ist er in dieser Ausführungsform der Einfachheit halber in die Datenmanagementschicht enthalten.
Das Obige sind die in der Datenmanagementschicht 30 enthaltenen Clouds. Unter einem Aspekt kann ein Unternehmen, das eine Cloud oder einen Computer der Datenmanagementschicht 30 besitzt (nachstehend einfach als in der Datenmanagementschicht enthaltendes Unternehmen bezeichnet), als ein Unternehmen betrachtet werden, das das Edge-Device (einschließlich der Vorrichtung selbst oder Komponenten davon) entwickelt oder herstellt, oder als ein Unternehmen, das für die Verteilung von Edge-Daten zuständig ist. Unter diesem Aspekt kann die Cloud eines Telekommunikationsunternehmens, eines Unternehmens, das ein Auto-Navigationsprogramm bereitstellt, das von einem Smartphone ausgeführt wird, und eines Herstellers eines Bewegungsmechanismus als Teil der Datenmanagementschicht betrachtet werden.
<<Datennutzungsschich>>
Die Datennutzungsschicht 31 ist eine virtuelle Schicht oder Gruppe, die zur Vereinfachung der Erklärung eingeführt wurde. Diese Schicht umfasst eine Vielzahl von Clouds oder Computern (nachstehend auch als Datennutzungsschicht-Cloud oder Dienstanbieter-Computer bezeichnet). Die Datennutzungsschicht-Cloud umfasst Clouds von Unternehmen, die für den Teil zuständig sind, der näher an der Diensterbringung liegt als die Datenmanagementschicht-Cloud.
Geeignete Dienste, die in der Datennutzungsschicht-Cloud angeboten werden, sind hier Edge-Device-bezogene Dienste, die das Edge-Device 12 nutzen, eine auf das Edge-Device 12 bezogene Entität zum Gegenstand haben oder das Edge-Device 12 selbst zum Gegenstand haben. Ein Beispiel für eine Entität ist eine Gruppe von Menschen (einschließlich einer Gruppe von Menschen z.B. in einem Unternehmen), Tieren, Vorrichtungen (zum Beispiel Verkehrsampeln, Schiffe, die Edge-Devices 12 tragen, und andere Geräte, die den automatischen Betrieb des Edge-Device 12 außerhalb des Edge-Device 12 unterstützen). Unter einem anderen Aspekt kann ein Unternehmen, das eine in der Datennutzungsschicht enthaltene Cloud besitzt (nachstehend einfach als in der Datennutzungsschicht enthaltenes Unternehmen oder Dienstanbieter bezeichnet), als ein Unternehmen betrachtet werden, das kein Edge-Device 12 selbst oder Komponenten davon entwickelt oder herstellt (ein Unternehmen, das keine Designdaten 13 hat). In 1 wird Folgendes als Beispiel für die Datennutzungsschicht-Cloud gezeigt.
Transportunternehmens-Cloud: Diese Cloud ist eine Cloud eines im Transportgeschäft tätigen Unternehmens, das das Edge-Device 12 direkt nutzt oder die Dienste eines anderen Transportunternehmens nutzt. Der Prozess, der in dieser Cloud durchgeführt wird, ist ein Prozess, der Edge-Daten oder von einer Analyse-Outsourcing-Cloud 27 bereitgestellte Analysedaten empfängt und den Transportdienst bereitstellt. Beispiele für solch einen Prozess sind die Fahrzeugeinsatzplanung für Edge-Devices, die Berechnung von Transportkosten und ein Analyseprozess zur Revision der Dienstbeschreibung einschließlich der Transportkosten. In dieser Beschreibung können die Daten nach den Analyseprozess einfach als „Analysedaten“ bezeichnet werden.
Versicherer-Cloud 29: Die Versicherungsgesellschaft übernimmt ein bestimmtes Risiko bezüglich des Geschäfts eines Unternehmens, welches das Edge-Device 12 nutzt, um eine bestimmte Funktion zu erfüllen. Die Versicherungsgesellschaft führt einige oder alle Prozesse in der Versicherer-Cloud 29 durch, um unter Bezugnahme auf die Edge-Daten oder die Analysedaten von der Analyse-Outsourcing-Cloud 27 den Prämiensatz zu bestimmen. Das von der Versicherungsgesellschaft garantierte Risiko kann ein Risiko bezüglich einer Entität sein, die das Edge-Device 12 nutzt. Es handelt such zum Beispiel um eine Kraftfahrzeugversicherung, die von einer Einzelperson abgeschlossen wird.
Händler- oder Reparaturbetriebs-Cloud 28: Der Händler oder der Reparaturbetrieb veranlasst die Reparatur und Wartung des Edge-Device 12 und repariert das Edge-Device 12. Um derartige Operationen zu unterstützen, empfängt die Cloud Edge-Daten oder von der Analyse-Outsourcing-Cloud 27 bereitgestellte Analysedaten, generiert die Information, die für Wartungsdienste (vorbeugende Wartung und Instandsetzung) oder Reparaturdienste (bei einem Unfall) benötigt wird, und zeigt dem Bearbeiter oder Reparateur diese Information an.
Vermietungsfirmen- oder MaaS-Unternehmens-Cloud 22: Diesen Unternehmen ist gemeinsam, dass es sich um Unternehmen handelt, die das Edge-Device 12 direkt nutzen oder die Dienste anderer Personenbeförderungsunternehmen zur Erbringung von Transportdiensten nutzen. Um solch einen Dienst zu unterstützen, empfängt die Vermietungsfirmen- oder MaaS-Unternehmens-Cloud 22 Edge-Daten oder von der Analyse-Outsourcing-Cloud 27 bereitgestellte Analysedaten und generiert Information, die zur Wartungsplanung der eigenen Fahrzeuge und dergleichen benötigt wird. Diese Information wird den Mitarbeitern des Unternehmens und Benutzern des Unternehmens angezeigt.
Analyse-Outsourcing-Cloud 27: Die Analyse-Outsourcing-Cloud 27 ist eine Cloud, zu welcher Unternehmen, die in der Datennutzungsschicht 31 enthalten sind, die zur Bereitstellung oder Verbesserung von Diensten erforderliche Datenanalyse (nachstehend als dienstbezogener Analyseprozess bezeichnet) auslagern. In der vorliegenden Ausführungsform wird der Fall beschrieben, in welchem sie für die Auslagerung der Analyse von Edge-Daten (insbesondere von ECTL-Diagnosedaten) zuständig ist, diese Cloud kann jedoch auch für die Auslagerung der Analyse einer Cloud oder eines Unternehmens zuständig sein, die in der Datenmanagementschicht 30 enthalten ist, wie z.B. eines Edge-Device-Herstellers. In jeder Lösung, die weiter unten beschrieben wird, ist der dienstbezogene Analyseprozess ein Ursachenanalyseprozess, der sich auf den internen Zustand des Edge-Device 12 oder des In-Edge-Controllers 10 bezieht.
Ferner kann die Aufteilung zwischen der Datenmanagementschicht 30 und der Datennutzungsschicht 31 auch anders sein als diese und muss nicht ausschließend sein. Zum Beispiel entspricht ein Telekommunikationsunternehmen einer Edge-Datendistributor-Cloud 24 und ist in der obigen Definition unter dem Aspekt der Edge-Datenverteilung in der Datenmanagementschicht 30 enthalten, kann jedoch unter dem Aspekt der Bereitstellung von „Kommunikationsdiensten“ zum Edge-Gerät 12 auch in der Datennutzungsschicht 31 enthalten sein.
«Vorteile der Verwendung von Diagnosedaten des In-Edge-Controllers und Datenfluss»
Das verteilte System 1000 in der vorliegenden Ausführungsform zeichnet sich dadurch aus, dass Diagnosedaten, die den internen Zustand des In-Edge-Controllers 10 (zum Beispiel einen anormalen Zustand) anzeigen (nachstehend auch einfach als „Anomalie“ bezeichnet), außerhalb des Edge-Device 12 verwendet werden, wodurch das verteilte System als Ganzes Maßnahmen (einschließlich verschiedener Maßnahmen wie vorbeugende Wartung, Wartung, Instandsetzung und Verbesserung) ergreifen kann. Die Begründung ist wie folgt.
Es ist abzusehen, dass der In-Edge-Controller 10 in Zukunft komplexer werden wird, um einen automatisch betreibbaren bewegten Körper zu realisieren. In diesem Fall wird der In-Edge-Controller 10 interne Zustände verschiedener Art annehmen. Die Behebung dieser internen Zustände (insbesondere von anormalen Zuständen) beschränkt sich nicht auf interne Zustände des Typs, die nur im Edge-Device 12 wiederherstellbar sind. Daher haben die Anmelder in Betracht gezogen, verschiedene interne Zustände des verteilten Systems 1000 als Ganzes zu behandeln, indem sie Diagnosedaten verwenden, die den internen Zustand des In-Edge-Controllers 10 außerhalb des Edge-Device 12 anzeigen.
Der Datenfluss wird weiter unten erläutert, doch das verteilte System 1000 bringt insbesondere die folgenden Vorteile.
Im Falle eines Edge-Device-Herstellers: Da das Edge-Device 12 aufgrund des automatischen Betriebs komplex ist, kann die Last des Herstellers für die Zustandsanalyse von Edge-Devices 12 sehr hoch sein. Durch Anwenden des verteilten Systems 1000 ist es möglich, die Last der Analyse des internen Zustands des In-Edge-Controllers 10 für den Hersteller des Edge-Device 12 zu reduzieren. Diese Wirkung wird noch erheblicher, wenn dasselbe Unternehmen wie der Hersteller des In-Edge-Controllers 10 oder ein beteiligtes Unternehmen die Diagnosedatenmanagement-Cloud 26 oder die Analyse-Outsourcing-Cloud 27 besitzt. Dies ist dadurch bedingt, dass die Ursachenanalyse mit Detailkenntnis durchgeführt werden kann.
Im Falle einer Versicherungsgesellschaft: Die Häufigkeit und Tendenz von Ausfällen für Edge-Devices 12 jeden Typs kann zur Anpassung der Versicherungsprämien und der Auszahlungsbedingungen im Versicherungsfall verwendet werden.
Im Falle eines Transportunternehmens, einer Vermietungsfirma oder eines MaaS-Unternehmens: Es ist möglich, eine Verschlechterung der Dienstqualität, die auf eine Anomalie des In-Edge-Controllers 10 zurückzuführen ist, zu reduzieren. Beispielsweise ist es möglich, das Edge-Device 12 effizient zu betreiben, indem der Typ des Edge-Device 12 (oder des In-Edge-Controllers 10) so an die Einsatzumgebung des Edge-Device 12 angepasst wird, dass der In-Edge-Controller 10 keine Anomalien verursacht. Angenommen zum Beispiel, die Analyse ergibt, dass ein bestimmter Typ von Edge-Device 12 zwar kostenwirksam oder mit hoher Geschwindigkeit beweglich ist, in einer spezifischen Einsatzumgebung jedoch leicht eine Anomalie des Edge-Device 12 (oder des In-Edge-Controllers 10) auftritt. Dann kann erwogen werden, den Einsatzplan des Edge-Device 12 so zu ändern, dass das Edge-Device 12 dieses Typs in einer anderen Umgebung als in der spezifischen Einsatzumgebung eingesetzt wird.
Im Falle eines Händlers oder Reparaturbetriebs: Wenn eine Anomalie auftritt, kann der Benutzer das Edge-Device 12 schnell austauschen, die Ursache ermitteln, das Produkt reparieren und den Austauschort schnell identifizieren.
Im Falle einer Behörde: Bei einem Unfall wird eine Analyse einschließlich der ECTL-Diagnosedaten ermöglicht.
Im Falle eines Analyse-Outsourcing-Unternehmens: Wenn bereits vor dem Empfang der ECTL-Diagnosedaten ein bestimmter Analysedienst bereitgestellt wird, werden die zu analysierenden Daten vermehrt, wodurch das Unternehmen eine umfangreichere oder genauere Analyse als Dienst anbieten kann.
<<<Einfacher Datenfluss zur Datennutzungsschicht>>>
Der einfache Datenfluss zur Nutzung der obigen Vorteile beginnt damit, dass das Edge-Device 12 die ECTL-Diagnosedaten aussendet, wie durch ECTL-Diagnosedaten D11 dargestellt. Als Beispiel zeigt 1 einen Fall, in welchem eine Datenmanagementschicht-Cloud, insbesondere eine Diagnosedatenmanagement-Cloud 26, die ECTL-Diagnosedaten empfängt und in einer Speicherressource speichert. Wenn die Cloud, die die ECTL-Diagnosedaten empfangen hat, die ECTL-Diagnosedaten danach zur Cloud jedes Unternehmens überträgt, kann jedes Unternehmen die ECTL-Diagnosedaten nutzen.
Die Daten können in der Diagnosedatenmanagement-Cloud 26 verarbeitet werden, und die verarbeiteten Daten können zur Cloud jedes Unternehmens gesendet werden.
Die Verarbeitung von ECTL-Diagnosedaten oder der Prozess der Datenübertragung an andere Clouds durch die obige Diagnosedatenmanagement-Cloud 26 kann auch ganz oder teilweise zur Edge-Datendistributor-Cloud 24 ausgelagert werden. In diesem Fall überträgt die Diagnosedatenmanagement-Cloud 26 die ECTL-Diagnosedaten selbst oder ECTL-Diagnosedaten, die im von der Diagnosedatenmanagement-Cloud 26 behandelten Bereich verarbeitet wurden, zur Edge-Datendistributor-Cloud 24, wie durch die Daten D21 dargestellt.
Zusätzlich zu den bereits beschriebenen Verarbeitungsbeispielen können die Anonymisierung personenbezogener Informationen und die Vereinfachung und Abstraktion von ECTL-Diagnosedaten in Betracht gezogen werden.
Wenn die Edge-Datendistributor-Cloud 24 die Edge-Daten aggregiert und die Edge-Daten dann der Cloud der Datennutzungsschicht 31 bereitstellt, und wenn die Edge-Datendistributor-Cloud 24 für die Verteilung der ECTL-Diagnosedaten zuständig ist, ergeben sich zum Beispiel die folgenden Vorteile.
Da die Cloud-Ressourcen (weiter unten beschrieben), über welche die Edge-Datendistributor-Cloud 24 der Datennutzungsschicht 31 bereits verfügt, ausgenutzt werden können, können die Cloud-Ressourcen der Diagnosedatenmanagement-Cloud 26 reduziert werden.
Ferner können in der Datennutzungsschicht 31 enthaltene Clouds sowohl Sensordaten als auch die ECTL-Diagnosedaten des Edge-Device 12 erhalten, indem sie die Daten von der Edge-Datendistributor-Cloud 24 empfangen.
Die ECTL-Diagnosedaten vom Edge-Device 12 können von anderen Clouds empfangen werden, die in der Datenmanagementschicht 30 enthalten sind. Ferner können die ECTL-Diagnosedaten vom Edge-Device 12 auch von Clouds empfangen werden, die in der Datennutzungsschicht 31 enthalten sind.
«<Datenfluss bei Verstärkung der Diagnosedatenmanagement-Cloud»>
Angenommen, die Verarbeitung der Diagnosedatenmanagement-Cloud 26 wird wiederholt verstärkt, sodass nach der Verarbeitung verbesserte Daten an andere Geräte gesendet werden können. Derartig verarbeitete Daten können jedoch nicht zu Datennutzungsschicht-Clouds übertragen werden, es sei denn, das Programm wird so modifiziert, dass verarbeitete Daten auf Seiten des Edge-Datendistributors 24 empfangen, in der Speicherressource gespeichert und zu Datennutzungsschicht-Clouds übertragen werden können. Um solch eine Situation zu vermeiden, kann die Diagnosedatenmanagement-Cloud 26 die verarbeiteten Daten zu Datennutzungsschicht-Clouds übertragen, ohne über die Edge-Datendistributor-Cloud 24 zu gehen. Um diese Übertragung zu realisieren, kann zum Beispiel die folgende Methode oder Konfiguration in Betracht gezogen werden.
(Kooperation) Ein Analyse-Outsourcing-Unternehmen, das über eine Analyse-Outsourcing-Cloud 27 verfügt, schließt einen Vertrag mit einem Unternehmen ab, das über eine Diagnosedatenmanagement-Cloud 26 verfügt, und erwirbt Schnittstellenspezifikationen und Nutzungsrechte, um formatierte Daten zu empfangen. Das Analyse-Outsourcing-Unternehmen kann die verarbeiteten Daten, für die das Nutzungsrecht erworben wurde, empfangen, indem es das Programm seiner eigenen Analyse-Outsourcing-Cloud 27 den Schnittstellenspezifikationen entsprechend modifiziert. Die Daten D26 von 1 (nachstehend als Kooperationsdaten oder Kooperationsdaten in der Diagnosedaten-Cloud bezeichnet) zeigen erweiterte Daten nach Durchführung der Verarbeitung (verarbeitete Daten) an.
Die Schnittstellenspezifikationen und Nutzungsrechte können auch anders als vertraglich erworben werden. Zum Beispiel können die Analyse-Outsourcing-Cloud 27 und die Diagnosedatenmanagement-Cloud 26 vom selben Unternehmen oder einem kapitalbeteiligten Unternehmen betrieben werden, um Schnittstellenspezifikationen und Nutzungsrechte zu sichern.
(Integration) Die Diagnosedatenmanagement-Cloud 26 dient auch als Analyse-Outsourcing-Cloud 27. Bei der Integration können die Computer, die beide Clouds realisieren, im selben Rechenzentrum stehen, oder die Programme und Daten, die in beiden Clouds ausgeführt werden sollen, können zusammen auf einem gemeinsamen Computer angeordnet sein. Alternativ dazu kann mindestens einer von einer Vielzahl von virtuellen Computer, die demselben Computer zugeordnet sind, für die Diagnosedatenmanagement-Cloud 26 verwendet werden, und mindestens ein anderer kann für die Analyse-Outsourcing-Cloud 27 verwendet werden. Unter einem anderen Aspekt kann „die Diagnosedatenmanagement-Cloud 26 dient auch als Analyse-Outsourcing-Cloud 27“ bedeuten, dass Ressourcen eines bestimmten Rechenzentrums (zum Beispiel ein Prozessor, eine Speicherressource, ein Kommunikationsgerät, ein Netzwerk und eine Managementsoftware zur Verwaltung der Ressourcen, die weiter unten beschrieben wird) von beiden Clouds gemeinsam benutzt werden.
Das Obige sind Beispiele für die Kooperation und Integration. Solch eine Kooperation oder Integration ermöglicht es der Analyse-Outsourcing-Cloud 27, der Datennutzungsschicht-Cloud verarbeitete Daten bereitzustellen, die nicht von der Edge-Datendistributor-Cloud 24 übertragen werden, und dadurch eine umfangreichere oder hochgenaue Analyse als Dienst anzubieten. Da der Übertragungszeitplan zur Datennutzungsschicht-Cloud durch die Analyse-Outsourcing-Cloud 27 oder die Diagnosedatenmanagement-Cloud festgelegt werden kann, ist es zudem möglich, das Analyseergebnis in Echtzeit bereitzustellen. Zur Bereitstellung in Echtzeit kann der Übertragungszeitplan ein kürzeres Intervall haben als zum Beispiel der Sende- und Empfangszeitplan der Edge-Datendistributor-Cloud.
In der folgenden Beschreibung kann das Aggregat der Diagnosedatenmanagement-Cloud 26 und der Analyse-Outsourcing-Cloud 27 als „Diagnosedaten-Cloud“ 32 bezeichnet werden. Die Diagnosedatenmanagement-Cloud 26, die zugleich als Analyse-Outsourcing-Cloud 27 dient, ist auch in der Diagnosedaten-Cloud 32 enthalten.
«Zusatzfunktionen der Diagnosedatenmanagement-Cloud und der Analyse-Outsourcing-Cloud»
Die Diagnosedatenmanagement-Cloud 26 und die Analyse-Outsourcing-Cloud 27 können andere Funktionen oder Prozesse als die oben beschriebenen durchführen. Wenn die Diagnosedatenmanagement-Cloud 26 zum Beispiel von einem Unternehmen betrieben wird, das den In-Edge-Controller 10 entwickelt oder herstellt, ist es auch möglich, das Design oder die Herstellung des In-Edge-Controllers 10 in der Diagnosedatenmanagement-Cloud 26 zu verwalten. Ferner können die ECTL-Diagnosedaten, die in dieser Diagnosedatenmanagement-Cloud 26 gespeichert sind, analysiert werden, um den In-Edge-Controller 10 zu verbessern.
Darüber hinaus kann die Analyse-Outsourcing-Cloud 27 ein Unternehmen sein, das das Edge-Device 12 selbst oder Komponenten davon entwickelt oder herstellt. In diesem Fall lässt sich leicht verhindern, dass Entwicklungs- und Fertigungsknowhow für den In-Edge-Controller 10 unnötigerweise an andere Unternehmen weitergegeben wird, die in der Datennutzungsschicht 31 enthalten sind, mit Ausnahme der Analyse-Outsourcing-Cloud 27.
<<Datenfluss zwischen Clouds>>
Obwohl ein Teil davon bereits erläutert wurde, weist das in 1 dargestellte verteilte System 1000 den folgenden Datenfluss auf. Die Cloud oder der Computer, von der in der Zeichnung ein Pfeil ausgeht, ist die Entität, die Daten sendet, und die Cloud oder der Computer, auf die der Pfeil gerichtet ist, ist die Entität, die Daten empfängt. Die Datenflüsse D11 bis D33 werden als „Pfeil“ D11 bis D33 ausgedrückt, wenn der Fluss betont werden soll, und werden als „Daten“ D11 bis D33 ausgedrückt, wenn es um den Inhalt der fließenden Daten geht. Wenn mehrere Inhalte der „Daten“ D11 bis D33 aufgeführt sind, bedeutet dies nicht unbedingt, dass die aufgeführten Inhalte gleichzeitig übertragen werden. Der Übertragungszeitpunkt kann unterschiedlich sein, und die Übertragung eines Teils der Inhalte kann ausgelassen werden.
Datenfluss (oder Daten) D11: ECTL-Diagnosedaten.
Datenfluss (oder Daten) D12: Sensordaten. Obwohl dies nicht dargestellt ist, können Sensordaten vom In-Edge-Controller 10 empfangen werden.
Datenfluss (oder Daten) D21, D27: ECTL-Diagnosedaten. In diesem Datenfluss können die verarbeiteten ECTL-Diagnosedaten fließen.
Datenfluss (oder Daten) D22: Daten nach dem Ursachenanalyseprozess oder auf der Basis des Ergebnisses der Ursachenanalyse verbesserte Daten für das Edge-Device. Verbesserte Daten umfassen zum Beispiel verbesserte Controller-Designdaten, Programme, Diagnosesequenzen oder thermische Auslegungsdaten. Die Diagnosedatenmanagement-Cloud 26 kann die Übertragungsquelle eines Teils der Daten D22 sein.
Datenfluss (oder Daten) D23: Daten in Bezug auf technische Daten, Handbücher und die Konfiguration des Edge-Device 12. Ferner ein Programm, das vom Edge-Device 12 ausgeführt wird (zum Beispiel ein Programm für ein Kfz-Navigationssystem, ein Spracherkennungsprogramm, ein Programm für den In-Edge-Controller 10 und dergleichen) sowie Parameter, die vom Programm referenziert werden. Die Daten D23 können das vom Edge-Device 12 ausgeführte Programm selbst und die Parameter selbst einschließen.
Datenfluss (oder Daten) D24: Wie die Daten, die als Datenfluss D23 übertragen werden. Als D23 können die Daten selbst gesendet werden, oder verarbeitete Daten (zum Beispiel nach der Verschlüsselung oder Komprimierung). Der Datenfluss D24 kann von einer anderen Komponente als dem Edge-Device 12 selbst oder dem In-Edge-Controller des Edge-Device 12 empfangen werden.
Datenfluss (oder Daten) D25: Edge-Daten. Die bisher beschriebenen Edge-Daten sind hauptsächlich Daten, deren Wert sich dynamisch ändert. Doch auch statische Daten wie z.B. technische Daten und Handbücher des Edge-Device 12 sind Daten, die sich auf das Edge-Device 12 beziehen und in den Edge-Daten enthalten sein können. Diese Edge-Daten werden von der Edge-Datendistributor-Cloud 24 zu Clouds der Datennutzungsschicht 31 übertragen. Die Daten können auch von der Edge-Datendistributor-Cloud 24 zu Clouds der Datenmanagementschicht 30 übertragen werden.
Datenfluss (oder Daten) D26: Kooperationsdaten in der Diagnosedaten-Cloud.
Datenfluss (oder Daten) D31, D32: Analysedaten. Als Ergebnis des von der Analyse-Outsourcing-Cloud 27 durchgeführten Analyseprozesses wird zum Beispiel Reparaturinformation wie der Fehlerort und die Anbindung des auszutauschenden Device sowie auf das Edge-Device 12 bezogene Wartungsinformation wie der Verschlechterungsgrad jedes Edge-Devices 12 und die Wartungsfrist eingeschlossen. Dies sind Daten, die zur Diensterbringung oder -verbesserung eines in der Datennutzungsschicht 31 enthaltenen Unternehmens verwendet werden.
Datenfluss (oder Daten) D33: Dienstbezogene Daten. Das sind Daten, die von der Cloud oder dem Computer der Datennutzungsschicht 31, die einen Dienst bereitstellen, zur Cloud oder zum Computer eines anderen Unternehmens derselben Datennutzungsschicht 31 übertragen werden. Dies sind zum Beispiel Dienstbeschreibungen (Versicherungsprämien, Fahrpreise, verschiedene Gebühren und dergleichen können enthalten sein), Ergebnisse der Diensterbringung und Verbesserungsvorschläge für Dienstbeschreibungen.
«Beschreibung anderer Clouds»
Obwohl ein Teil davon bereits erläutert wurde, sind diese wie folgt.
Edge-Datendistributor-Cloud: Eine Cloud, die die obigen Edge-Daten D25 an Datennutzungsschicht-Clouds verteilt. Diese Cloud kann die durch den Analyseprozess erhaltenen Analysedaten an eine beliebige Cloud verteilen. Ferner überträgt die Edge-Datendistributor-Cloud 24 die obigen Daten D24. Die Edge-Datendistributor-Cloud 24 ist als eine gemeinsame Plattform für die Kommunikation mit Clouds zu betrachten, die einem Edge-Device-Hersteller (mehrere sind möglich), einem Diagnosedatenmanagement-Cloud-Unternehmen (mehrere sind möglich) und einem in der Datennutzungsschicht enthaltenen Unternehmen (mehrere sind möglich) gehören. In solch einem Fall kann sie über mehr Cloud-Ressourcen zum Senden und Empfangen von Daten (hauptsächlich Kommunikationsbandbreite und Rechenkapazität) als andere Unternehmen verfügen. Um beim Senden und Empfangen von Daten an und von einer großen Zahl von Edge-Devices 12, die zusätzlich zu den Clouds oder Computern einer Vielzahl von Unternehmen vorhanden sind, Engpässe in den Cloud-Ressourcen zu vermeiden, kann die Edge-Datendistributor-Cloud 24 auf der Basis eines vorbestimmten Zeitplans Daten senden und empfangen.
<Edge-Device>
2 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel eines Edge-Device zeigt. Das Edge-Device 12 weist die folgende Konfiguration auf (bereits erläuterte Punkte werden ausgelassen).
Bewegungsmechanismus oder Betätigungsmechanismus 17: Der Bewegungsmechanismus wird stellvertretend beschrieben. Beispiele für den Bewegungsmechanismus 17 sind ein Kraftübertragungsmittel wie z.B. ein Rad, eine Welle, ein Riemen oder ein Getriebe, ein Aktuator wie z.B. ein Motor oder Hydraulikdruck, eine Komponente, die Kraft erzeugt oder reduziert wie z.B. eine Bremse oder ein Motor. Es können jedoch andere Mechanismen verwendet werden.
In-Edge-Controller 10 zur Steuerung des Bewegungsmechanismus 17 des Edge-Device 12: Beispiele für den Controller schließen eine ECU eines Fahrzeugs, einen Controller einer Drohne, eine SPS im industriellen Bereich und einen NC-Controller einer Werkzeugmaschine ein. Das Edge-Device 12 kann eine Vielzahl von In-Edge-Controllern 10 umfassen.
Wenn das Edge-Device 12 ein Fahrzeug ist und der In-Edge-Controller 10 eine ECU ist, kann das Edge-Device 12 eine Vielzahl von In-Edge-Controllern 10 enthalten, und jeder In-Edge-Controller 10 kann eine andere Steuerfunktion haben (Spurhaltung, Abstandsregelung zwischen Fahrzeugen, Drehzahlregelung der Brennkraftmaschine und Kommunikationsteuerung mit der Außenwelt des Edge-Device 12). Ein gemeinsamer In-Edge-Controller 10 kann eine Vielzahl von Steuerfunktionen haben. In der Autoindustrie wird solch eine Steuerfunktion manchmal als „Funktion“ oder „Systemfunktion“ bezeichnet. Diese Zuordnungsweise von Steuerfunktionen ist auch anwendbar, wenn der In-Edge-Controller 10 nicht die ECU ist.
Die Hardware, aus welcher der In-Edge-Controller 10 besteht, umfasst zum Beispiel eine Zentraleinheit (CPU), einen Grafikprozessor (GPU), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) für die Datenverarbeitung, einen Bus und einen Sensor, wobei nicht alles davon unbedingt erforderlich ist. Die logische Konfiguration des In-Edge-Controllers 10 wird Bezug nehmend auf 2 beschrieben. Der In-Edge-Controller 10 hat eine oder mehrere Steuerfunktionen, und jede Steuerfunktion weist eine Zustandsdaten-Diagnoseeinheit 110 und eine Steuerverarbeitungseinheit (Steuerprozessor) auf, die nicht dargestellt ist.
Die Steuerverarbeitungseinheit des In-Edge-Controllers 10 führt die Steuerungsverarbeitung durch, die zur Realisierung der Steuerfunktion erforderlich ist. Die Steuerverarbeitungseinheit ist die Hardware, die den In-Edge-Controller ausmacht, und wird durch Ausführung eines Programms (nachstehend als Steuerprogramm bezeichnet) realisiert. Das Steuerprogramm kann durch die vom In-Edge-Controller 10 empfangenen Daten D24 (Aktualisierungsdaten) installiert oder aktualisiert werden, oder seine Parameter können aktualisiert werden. Wenn die Steuerfunktion beispielsweise das Halten der Geschwindigkeit ist, ist das Steuerprogramm ein Programm, das einen Prozess ausführt, um Anweisungen zum Öffnen oder Schließen der Drosselklappe einer Brennkraftmaschine oder Anweisungen zum Beschleunigen oder Bremsen an einen Motor zu senden, während es die vom Tachometer, der einer der Sensoren 18 ist, gemessene Geschwindigkeit (eine der Sensordaten) mit der Sollgeschwindigkeit vergleicht.
Die Zustandsdaten-Diagnoseeinheit 110 erfasst der in einer Diagnosesequenz-Speichereinheit 111 gespeicherten Diagnosesequenz entsprechend Information, die den Zustand der Hardware anzeigt, aus der das Edge-Device 12 besteht (einen der internen Zustände des In-Edge-Controllers 10), und erzeugt Daten D11 (ECTL-Diagnosedaten). Ferner kann die Zustandsdaten-Diagnoseeinheit 110 durch Überwachen der Steuerverarbeitungseinheit (genauer gesagt, des Steuerprogramms) Information erfassen, die den Zustand der Steuerverarbeitungseinheit anzeigt, und diese auf gleiche Weise behandeln wie die Information, die den Zustand der Hardware anzeigt, aus welcher der obige In-Edge-Controller besteht.
Die Diagnosesequenz ist Definitionsinformation, um Information, die den obigen Zustand anzeigt, in der von außen durch die Zustandsdaten-Diagnoseeinheit 110 vorgegebenen Reihenfolge zu erfassen. Der konkrete Inhalt der Diagnosesequenz wird weiter unten beschrieben.
Das Edge-Device 12 kann als Komponente auch einen Sensor 18 zur Messung des Zustands des Edge-Device 12 aufweisen. Als Beispiele für solch einen Sensor 18 sind Geräte wie z.B. ein GPS, ein Kraftstoffsensor, ein Tachometer, ein Drehzahlmesser (für Motoren, Brennkraftmaschinen und Räder), ein Abstandsmesser (zum Beispiel ein Abstandsmesser mit LiDAR (Light Detection And Ranging) oder Ultraschallwellen), Positions- oder Wegsensoren und Winkelerkennungsensoren denkbar. Die Daten, die von diesen Sensoren 18 und vom In-Edge-Controller 10 erzeugt werden (nachstehend auch als Edge-generierte Daten bezeichnet) werden zur Cloud der Datenmanagementschicht 30 (Diagnosedatenmanagement-Cloud 26) oder zum In-Edge-Controller 10 übertragen. Die Kommunikation vom Edge-Device 12 nach außen erfolgt typischerweise über ein drahtloses Kommunikationsmodul (zum Beispiel ein WiFi-Modul (eingetragenes Warenzeichen) oder ein 5G-Kommunikationsmodul), doch nicht jede Komponente des Edge-Device 12 muss unbedingt ein drahtloses Kommunikationsmodul aufweisen. Stattdessen kann das Edge-Device 12 ein Gateway-Gerät (zum Beispiel eine ECU, ein Smartphone, einen drahtlosen Router) umfassen, das ein drahtloses Kommunikationsmodul aufweist, und das Gateway-Gerät kann den Prozess der Kommunikation nach außen konsolidieren.
Das Edge-Device 12 ist nicht auf Devices desselben Herstellers beschränkt, sondern umfasst Devices verschiedener Generationen und Typen. Darüber hinaus ist das Edge-Device nicht auf einen bewegten Körper oder eine Ausrüstung beschränkt, sondern kann auch als beides dienen.
<Hardware-Konfiguration der Clouds oder Computer>
3 ist ein Diagramm, das ein Beispiel für die Hardwarekonfiguration eines Computers 400 zeigt, aus dem jede Cloud gebildet ist. Da der Computer eines der Geräte ist, kann er als Computergerät bezeichnet werden.
Der Computer 400 umfasst einen Prozessor 401 wie z.B. eine CPU, einen Speicher 402 als Hauptspeicher, ein externes Speichergerät 403 wie z.B. eine Festplatte oder ein Solid-State-Laufwerk (SSD), ein Audio-Ausgabegerät 404 wie z.B. einen Lautsprecher, ein biometrisches Informationseingabegerät 405 wie z.B. eine Kamera, ein Sichtlinien-Eingabegerät oder ein Mikrofon, ein Eingabegerät 406 wie z.B. eine Tastatur, eine Maus und ein Touchpanel, ein Ausgabegerät 407 wie z.B. einen Bildschirm und einen Drucker, ein Kommunikationsgerät 408 wie z.B. eine Netzwerkkarte (NIC) und einen Bus, der diese verbindet. Nicht jede dieser Komponenten ist unbedingt erforderlich.
Der Speicher 402 ist zum Beispiel ein Speicher wie ein Direktzugriffsspeicher (RAM).
Das externe Speichergerät 403 ist ein nichtflüchtiges Speicher, der in der Lage ist, digitale Information zu speichern, wie z.B. eine sogenannte Festplatte, ein SSD-Laufwerk oder ein Flash-Speicher.
Das Kommunikationsgerät 408 ist ein drahtgebundenes Kommunikationsgerät, das über ein Netzwerkkabel eine drahtgebundene Kommunikation durchführt, oder ein drahtloses Kommunikationsgerät, das über eine Antenne eine drahtlose Kommunikation durchführt. Das Kommunikationsgerät 408 kommuniziert mit anderen Geräten, die mit demselben Netzwerk verbunden sind. Für die Kommunikation wird die Paketkommunikation per TCP/IP (Transmission Control Protocol/Internet Protocol) verwendet, die Kommunikation ist jedoch nicht darauf beschränkt, und die Kommunikation kann auch andere Protokolle wie z.B. UDP (User Datagram Protocol) verwenden.
Ferner wird durch das Kommunikationsgerät 408 eine Kommunikationseinheit (nicht dargestellt) realisiert, die kommunikativ mit einem lokalen Netzwerk (LAN) oder dergleichen verbunden ist.
Obiges ist ein Beispiel für die Hardwarekonfiguration eines Computers 400, aus dem jede Cloud in der vorliegenden Ausführungsform gebildet ist. Die Konfiguration des Computers 400 ist jedoch nicht darauf beschränkt und kann durch Verwendung anderer Hardware konfiguriert werden. Ferner kann der Computer 400 verschiedene informationsverarbeitende Geräte wie z.B. einen Server-Computer, einen Personal-Computer, einen Notebook-PC, ein Tablet-Gerät, ein Smartphone oder ein Fernsehgerät einschließen.
Obwohl dies nicht dargestellt ist, kann der Computer 400 ein bekanntes Programm wie z.B. ein Betriebssystem (OS), Middleware oder eine Anwendung aufweisen. Solch ein Programm wird vom Prozessor 401 auf gleiche Weise wie andere Programme ausgeführt, damit der Computer 400 einen bestimmten Prozess durchführt. Zusätzlich können die Komponenten, die in jeder Cloud der vorliegenden Beschreibung als „Einheiten“ beschrieben werden, mit Ausnahme derjenigen, die ausdrücklich als Bereiche von Speicherressourcen angegeben sind, durch die obigen Programme realisiert werden. Zudem ist der Prozessor 401 nicht auf die CPU beschränkt und kann durch andere Prozessoren wie z.B. eine GPU und ein FPGA realisiert werden.
Da die funktionale Grenze zwischen dem Speicher 402 und dem externen Speichergerät 403 aufgrund von Technologien wie die Virtualisierung unscharf geworden ist, ist eine strikte Unterscheidung nicht erforderlich, solange sie als Speicherressourcen verwendbar sind. Ferner können der Prozessor, die Speicherressourcen und das Kommunikationsgerät 408 als Cloud-Ressourcen bezeichnet werden. Es ist auch möglich, ein ganzes Rechenzentrum als Cloud zu betrachten. In diesem Fall können die Cloud-Ressourcen auch Netzwerk-Switches, Router, Stromversorgungen für Rechenzentren und Kühleinrichtungen als Teil der Cloud-Ressourcen umfassen. Zudem kann der Computer 400 eine virtuelle Entität wie z.B. ein virtueller Rechner sein, der die Hardware des physischen Computers 400 virtualisiert.
Bei einem Computer, der z.B. als Webserver fungiert, kann das Eingabegerät und das Ausgabegerät entfallen. In diesem Fall werden diese Geräte dadurch ersetzt, dass der Server-Computer über die Kommunikationseinrichtung 408 als Eingabedaten die Eingabe eines Eingabegeräts empfängt, das an einem anderen Computer als Client (Client-Computer) vorgesehen ist, der mit dem Server-Computer verbunden ist. Dementsprechend überträgt der Server-Computer die Daten, die an den Client-Computer ausgegeben werden sollen, über die Kommunikationseinrichtung 408 und gibt die Ausgabedaten an das Ausgabegerät des Client-Computers aus. Unabhängig davon, ob ein Eingabegerät und ein Ausgabegerät vorhanden ist oder nicht, besteht die Gemeinsamkeit darin, dass der Empfang der Eingabedaten und der Ausgabeprozess durch das Programm erfolgt, das auf dem Server-Computer ausgeführt wird. In einer Webanwendung, die HTML (Hyper-Text Markup Language) und JavaScript verwendet, wird der auf dem Ausgabegerät anzuzeigende Text durch Ausführen von HTML oder JavaScript auf einem Client-Computer erzeugt, der einen Webbrowser ausführt. In diesem Fall umfasst die „Ausgabeverarbeitung“ auch die Übertragungsverarbeitung von HTML-Daten und JavaScript-Daten durch das Webserver-Programm, das vom Computer für den Webserver ausgeführt wird.
Das Obige ist ein Beispiel für die Hardware-Konfiguration eines Computers, aus dem eine Cloud gebildet ist. Die Diagnosedatenmanagement-Cloud, der Edge-Device-Hersteller-Computer 21 und die Edge-Datendistributor-Cloud 24, die zur Datenmanagementschicht 30 gehören, und die Vermietungsfirmen- oder MaaS-Unternehmens-Cloud 22, die Transportunternehmens-Cloud, die Versicherer-Cloud 29, die Händler- oder Reparaturbetriebs-Cloud 28 und die Analyse-Outsourcing-Cloud, die Clouds sind, die zur Datennutzungsschicht 31 gehören, haben dieselbe Hardwarekonfiguration wie der Computer 400.
<Konfiguration des Edge-Device-Hersteller-Computers>
4 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel eines Edge-Device-Hersteller-Computers zeigt Der Edge-Device-Hersteller-Computer (Hersteller-Computer) 21 speichert mindestens die Designdaten 13 in der Speicherressource. Der Edge-Device-Hersteller-Computer 21 liest und verarbeitet die Designdaten 13 in den Produktentwicklungs- und Fertigungsprozessen. Daher kann der Edge-Device-Hersteller-Computer 21, auch wenn dies nicht dargestellt ist, ein Programm wie z.B. ein CAD-Programm (Computer-Aided Design), ein CAE-Programm (Computer Aided Engineering) und ein Fertigungsmanagementprogramm ausführen, das den Entwurf oder die Fertigung des Edge-Device 12 unterstützt.
<Konfiguration der Diagnosedatenmanagement-Cloud>
Bevor auf die Lösungen bezüglich der Bereitstellungsform jedes Dienstes eingegangen wird, wird die logische Konfiguration der gemeinsamen Diagnosedatenmanagement-Cloud beschrieben. Die Diagnosedatenmanagement-Cloud 26 empfängt unter Verwendung des obigen Computers 400 die Daten D11 (ETCL-Diagnosedaten) vom In-Edge-Controller 10, die Daten D12 (Sensordaten) vom Sensor 18 und die Daten D26, die in 1 und dergleichen beschrieben wurden. Dementsprechend überträgt die Diagnosedatenmanagement-Cloud 26 die Daten D21, die Daten D26 und die Daten D27, die in 1 und dergleichen beschrieben wurden. Diese Sende- und Empfangsprozesse werden durchgeführt, indem vom Prozessor ein Programm (nachstehend auch als Diagnosedatenmanagement-Programm bezeichnet) ausgeführt wird, das in den Speicherressourcen des Computers 400 gespeichert ist, aus denen die Diagnosedatenmanagement-Cloud 26 gebildet ist.
Zudem speichert das Diagnosedatenmanagement-Programm die Daten D11 (ECTL-Diagnosedaten) und die Daten D12 (Sensordaten) in der Speicherressource, und daher können diese Daten an einem geeigneten Zeitpunkt zu jeder Cloud übertragen werden. Das Diagnosedatenmanagement-Programm kann diese Daten gemäß einem vorgegebenen Zeitplan oder auf Anforderung senden oder empfangen.
<Konfiguration der Analyse-Outsourcing-Cloud>
Bevor auf Lösungen bezüglich der Bereitstellungsform jedes Dienstes eingegangen wird, wird die logische Konfiguration der gemeinsamen Diagnosedatenmanagement-Cloud beschrieben. Die Analyse-Outsourcing-Cloud 27 empfängt unter Verwendung des obigen Computers 400 die Daten D25 (Edge-Daten) und die Daten D26, die in 1 und dergleichen beschrieben wurden. Dementsprechend überträgt die Analyse-Outsourcing-Cloud 27 die Daten D31 und D32 (Analysedaten), die Daten D22 und die Daten D26, die in 1 und dergleichen beschrieben wurden. Diese Sende- und Empfangsprozesse werden durchgeführt, indem vom Prozessor ein Programm (nachstehend auch als Analyse-Outsourcing-Programm bezeichnet) ausgeführt wird, das in den Speicherressourcen des Computers 400 gespeichert ist, der die Analyse-Outsourcing-Cloud 27 bildet. Ferner speichert das Analyse-Outsourcing-Programm die empfangenen Daten D25 (Edge-Daten) und D26 in der Speicherressource, um den Analyseprozess vorzubereiten.
Der Zweck des Analyseprozesses durch das Analyse-Outsourcing-Programm ist wie oben beschrieben (oder wie weiter unten beschrieben), zu diesem Zweck können jedoch zum Beispiel die folgenden Prozesse durchgeführt werden.

* Prozess des Empfangens und Speicherns von Daten von der Outsourcing-Quellcloud, die zur Analyse benötigt werden (nachstehend als „für die Analyse vorausgesetzte Daten“ bezeichnet). Hier werden Daten, die für die Analyse vorausgesetzt werden, über das Kommunikationsgerät empfangen. Zusätzlich werden empfangene Daten, die für die Analyse vorausgesetzt werden, in der Speicherressource gespeichert.
* Erfassen der Tendenz des Auftretens von Anomalien durch ein statistisches Verfahren oder ein Maschinenlernverfahren (zum Beispiel SVM (Support Vector Machine) oder neuronales Netzwerk). Als Daten für diesen Prozess können zusätzlich zu den Daten D25 (Edge-Daten) und D26 auch für die Analyse vorausgesetzte Daten verwendet werden.
* Analyseprozess der Anomalieursache oder des Einflussbereichs. Auf der Basis der Konfigurationsinformation des Edge-Device 12 und der Information über die kausale Beziehung des anormalen Zustands (ein Beispiel ist die Analyseregel einer ersten Lösung, die weiter unten beschrieben wird) werden die Komponente, die eine bestimmte Anomalie verursacht hat, und die von dieser Anomalie betroffenen Komponenten identifiziert (oder es werden Kandidaten identifiziert). Die obige Konfigurations- und Beziehungsinformation kann zudem die Konfigurations- und Beziehungsinformation innerhalb der Komponente des Edge-Device 12 umfassen. Außerdem kann die Konfigurations- und Beziehungsinformation außerhalb des Edge-Device 12 (zum Beispiel eines Geräts, das den obigen automatischen Betrieb des Edge-Device 12 unterstützt) berücksichtigt werden. Als Daten für den Prozess können zusätzlich zu den Daten D25 (Edge-Daten) und D26 auch für die Analyse vorausgesetzte Daten verwendet werden.
* FTA (Fehlerbaumanalyse) Analyseverfahren.

Wie in 1 gezeigt, kann ein gemeinsames Analyse-Outsourcing-Programm Daten D32 und Daten D31 (Analysedaten) an eine Vielzahl von Dienstanbietern verschiedenen Typs übertragen, und ein auf einen bestimmten Dienst zugeschnittenes Analyse-Outsourcing-Programm kann vorgesehen sein. Wenn selbst für eine Vielzahl von Diensten eine gemeinsame Analyse vorhanden ist, können die Analysedaten, die im Analyseprozess des ersten Dienstes erzeugt wurden, oder Zwischendaten während des Analyseprozesses im Analyseprozess eines zweiten Dienstes verwendet werden. Dabei können der erste und der zweite Dienst die gleiche Art von Dienst oder Dienste verschiedener Art sein.
Im Folgenden werden Lösungen für jedes Unternehmen beschrieben, die beschriebene Technik ist jedoch auch auf Lösungen für andere Unternehmen anwendbar.
<Erste Lösung (für Edge-Device-Hersteller)>
Das verteilte System 1000 kann einem Edge-Device-Hersteller dem Datenfluss D22 gemäß die ECTL-Diagnosedaten und das Analyseergebnis bereitstellen, und diese Lösung wird im Folgenden anhand eines Beispiels beschrieben. Dieses Beispiel ist lediglich ein Beispiel dafür, wie das verteilte System 1000 gemäß der vorliegenden Erfindung verwendet werden kann und schränkt den Anwendungsbereich der vorliegenden Erfindung nicht ein. Wenn das Edge-Device 12 ein Kraftfahrzeug ist, kann das Unternehmen, das der Edge-Device-Hersteller ist, in dieser Beschreibung als OEM (Original Equipment Manufacturer (Erstausrüster) gemäß ISO 16949 bezeichnet werden. Diese Lösung schließt den Hersteller-Computer 21 ein, der einem Edge-Device-Hersteller gehört, da dieser Computer jedoch bereits erläutert wurde, wird er ausgelassen.
<<In-Edge-Controller>>
Der In-Edge-Controller 10 enthält zusätzlich zur zuvor beschriebenen Konfiguration eine Diagnoseschaltung. Die Diagnoseschaltung ist eine Schaltung zur Diagnose der Hardwarekomponenten des In-Edge-Controllers 10. Die Diagnoseschaltung umfasst einen In-Edge-Controller-Sensor zur Diagnose einer Komponente und eine Schnittstellenschaltung, der den vom Sensor erhaltenen Wert im unveränderten oder verarbeiten Zustand der Zustandsdaten-Diagnoseeinheit 110 bereitstellt. Ein In-Edge-Controller-Sensor ist hier zum Beispiel ein Thermometer, ein Strommesser oder ein Widerstandsmesser, der an einer Komponente des In-Edge-Controllers 10 angebracht ist. Da das FPGA eine logische Schaltung beinhaltet, kann das FPGA als ein Mittel zur Realisierung der Diagnoseschaltung verwendet werden.
Die Zustandsdaten-Diagnoseeinheit 110 hat Information zum Gegenstand, die den elektronischen Zustand (zum Beispiel den im Systemregister gespeicherten Wert und den Inhalt der Bus-Schnittstelle) des Edge-Device 12 (insbesondere des In-Edge-Controllers) anzeigt. Da die Information in einem Low-Level-Datenformat vorliegt, das von der Hardware selbst bereitgestellt wird, wird die Information hier als Zustandsinformation im hardwareabhängigen Format bezeichnet. Daher erfasst die Zustandsdaten-Diagnoseeinheit 110 der Diagnosesequenz entsprechend die Zustandsinformation im hardwareabhängigen Format und führt den Diagnoseprozess durch. Der Zeitpunkt der Erfassung der Zustandsinformation im hardwareabhängigen Format kann zum Beispiel durch Erkennung eines anormalen Zustands, periodisch (einmal pro Tag oder dergleichen) oder beim Start ausgelöst werden.
Die Diagnosesequenz-Information ist in der Diagnosesequenz-Speichereinheit 111 gespeichert, die im In-Edge-Controller 10 enthalten ist. Die Diagnosesequenz wird ausgelesen und verwendet, wenn die Zustandsdaten-Diagnoseeinheit 110 den Diagnoseprozess durchführt. Da die Zustandsinformation im hardwareabhängigen Format hier Low-Level-Information ist, ist es unpraktisch, die Information in jeder Cloud zu behandeln, und es stellt eine Verschwendung der Speicherressourcen des In-Edge-Controllers 10 dar, jede Information wiederholt sequenziell zu erfassen und zu speichern.
Der Diagnoseprozess auf der Basis der Diagnosesequenz verarbeitet die Zustandsinformation zu einem hardwareunabhängigen Datenformat, um dieses Problem zu beseitigen, oder grenzt die Ursachenkandidaten für den aufgetretenen anormalen Zustand ein, indem er die Verarbeitung auf Zustandsinformation fokussiert, die sich auf den anormalen Zustand bezieht, und führt die Datenspeicherung oder Datenübertragung durch. Die Information, die in der vorliegenden Lösung in den Daten D11 (ECTL-Diagnosedaten) enthalten ist, stellt die Zustandsinformation dar, die durch diesen Diagnoseprozess verarbeitet wird. Das hardwareunabhängige Datenformat der Zustandsinformation ist bevorzugt ein Format, das zwischen der Vielzahl von Herstellerfirmen des In-Edge-Controllers 10 als Standardschnittstelle definiert wurde, kann aber auch ein anderes Format sein.
Zum Beispiel ist als eine Diagnosesequenz, die die obige Funktion erfüllt, Folgendes definiert.

* Eine Vielzahl von Diagnoseelementen.
* Diagnoseabfolge zwischen Diagnoseelementen und Ausführungsbedingungen für Diagnoseelemente.
* Bedingungen für den Start der Diagnosesequenz.
Die Diagnoseelemente umfassen hier zum Beispiel Folgendes:
* Parameter zur Erfassung von Zustandsinformation in einem hardwareabhängigen Format. Zum Beispiel eine Systemregisteradresse, eine Adresse eines Speicherbereichs oder eine Interruptnummer.
* Verarbeitungsparameter zur Verarbeitung von Zustandsinformation in einem hardwareabhängigen Format zu einem hardwareunabhängigen Datenformat. Wenn der Registerwert zum Beispiel „0xFFFF“ ist, wird der Text „False“ ausgegeben, was ein hardwareunabhängiges Datenformat ist, das angibt, dass die Hardware anormal ist, wobei diese Parameter satzweise verwaltet werden.

Das Diagnoseprogramm, das die Zustandsdatendiagnoseeinheit 110 realisiert, interpretiert die Definition der Diagnosesequenz und führt den Prozess dieser Definition gemäß durch.
<<Diagnosedaten-Cloud>>
5 ist ein Diagramm, das ein schematisches Konfigurationsbeispiel für eine Diagnosedaten-Cloud zeigt. Die Diagnosedaten-Cloud 32 umfasst die Diagnosedatenmanagement-Cloud 26 und die Analyse-Outsourcing-Cloud 27. Eine Teilkomponente der nachstehend beschriebenen Diagnosedatenmanagement-Cloud 26 kann zur Analyse-Outsourcing-Cloud 27 verschoben werden. Ferner kann ein Teil der Komponenten der nachstehend beschriebenen Analyse-Outsourcing-Cloud 27 zur Diagnosedatenmanagement-Cloud 26 verschoben werden. Da in 5 jede „Einheit“, die durch ein Rechteck mit abgerundeten Ecken dargestellt ist, eine Einheit ist, die durch die Speicherressource der Cloud realisiert wird, mit anderen Worten, ein Teil des durch die Speicherressource bereitgestellten Speicherbereichs, ist „Einheit“ wie oben beschrieben auch als „Bereich“ zu verstehen. Jede „Einheit“, die durch ein Rechteck ohne abgerundete Ecken dargestellt ist, wird durch das im Computer 400 beschriebene Programm realisiert. Einzelheiten werden weiter unten Bezug nehmend auf die Bezugszeichen in 6 bis 7 beschrieben.
<<<Diagnosedatenmanagement-Cloud>>>
Die Diagnosedatenmanagement-Cloud 26 umfasst eine Diagnosemodell-Definitionseinheit 3, eine Diagnosemodell-Speichereinheit 4, eine Diagnosesequenz-Generierungseinheit 5, eine Diagnoseschaltungs- und Programmspeichereinheit 6, eine Diagnoseschaltungs- und Steuerungs-Aktualisierungseinheit 15 und eine Diagnosesequenz-Speichereinheit.
Die Diagnosemodell-Definitionseinheit 3 definiert ein Diagnosemodell auf der Basis der Designdaten 13. Konkret zeigt die Diagnosemodell-Definitionseinheit 3 einen Bildschirm an, um die Produkt-Designdaten 13 anzuzeigen, veranschaulicht Funktionen einschließlich der Produkt-Komponenten und Diagnosepunkte, empfängt die eingegebenen Konfigurationsbeziehungen von Diagnosepunkten und speichert die eingegebenen Konfigurationsbeziehungen im Diagnosemodell-Speicherabschnitt 4 als Diagnosemodell ab. Die Diagnosemodell-Definitionseinheit 3 wird hauptsächlich vom Besitzer der Diagnosedatenmanagement-Cloud 26 verwendet, ist aber nicht darauf beschränkt und kann auch von einem Edge-Device-Hersteller verwendet werden. Hier ist das obige „Produkt“ das Edge-Device 12, eine Komponente des Edge-Device 12 oder der In-Edge-Controller.
Das Diagnosemodell wird in der Diagnosemodell-Speichereinheit 4 gespeichert. Das Diagnosemodell wird weiter unten beschrieben.
Die Diagnoseschaltungs- und Steuerungsaktualisierungseinheit 15 empfängt die von der Analyse-Outsourcing-Cloud 27 analysierten und verarbeiteten Analysedaten und aktualisiert die Diagnoseschaltungsinformation (das heißt, die Designinformation der Diagnoseschaltung) und das Diagnoseprogramm, die in der Diagnoseschaltungs- und Programmspeichereinheit 6 gespeichert sind. Hier ist das Diagnoseprogramm ein Programm, das die Zustandsdatendiagnoseeinheit 110 realisiert, indem es im In-Edge-Controller 10 dupliziert und dann vom In-Edge-Controller 10 ausgeführt wird.
Die Diagnoseschaltungs- und Programmspeichereinheit 6 speichert Diagnoseschaltungsinformation oder ein Diagnoseprogramm. In der Diagnoseschaltungs- und Programmspeichereinheit 6 kann auch die Schnittstellenspezifikation der Diagnoseschaltung und des Diagnoseprogramms gespeichert sein. Da die Diagnoseschaltungsinformation Teil der Designdaten 13 ist, kann die Diagnoseschaltungsinformation beim Start dieser Lösung erhalten werden, indem die entsprechende Information aus den Designdaten 13 extrahiert und in der Diagnoseschaltungs- und Programmspeichereinheit 6 gespeichert wird, oder indem die Diagnoseschaltungsinformation, die im Besitz des Herstellers des In-Edge-Controllers ist, in der Diagnoseschaltungs- und Programmspeichereinheit 6 gespeichert wird. Dasselbe gilt für das Diagnoseprogramm.
Die Diagnosesequenz-Generierungseinheit 5 generiert auf der Basis des Diagnosemodells, der Diagnoseschaltungsinformation und des Diagnoseprogramms (oder der Information des Diagnoseprogramms) eine Diagnosesequenz. Die generierte Diagnosesequenz wird in der Diagnosesequenz-Speichereinheit gespeichert und dann zum In-Edge-Controller 10 übertragen. Die Definition der Diagnosesequenz, die durch die Diagnosesequenz-Generierungseinheit generiert wurde, ist daher die gleiche wie die Definition der Diagnosesequenz, die im In-Edge-Controller 10 beschrieben wird.
<<<<Beziehung zwischen dem Diagnosemodell, der Diagnosesequenz und dem Diagnoseprogramm>>>>>
Hier wird die Beziehung oder Differenz zwischen dem Diagnosemodell, dem Diagnosesequenz, dem Diagnoseprogramm und der Diagnoseschaltung zusammengefasst. Wie bereits erwähnt, sind die Diagnosesequenz, das Diagnoseprogramm und die Diagnoseschaltung Komponenten des In-Edge-Controllers 10, deren Aktualisierung von der Diagnosedaten-Cloud 32 wiederholt durchgeführt wird. Daher können die Diagnosesequenz, das Diagnoseprogramm und die Diagnoseschaltung (deren Information) als Teil der Designdaten 13 betrachtet werden. Andererseits ist das Diagnosemodell als Zwischendaten zur Erzeugung einer Diagnosesequenz aus den Designdaten 13 zu verstehen. Es zeichnet sich durch eine Datendarstellung aus, die es ermöglicht, die Hardwareunabhängigkeit im Vergleich zur Diagnosesequenz zu erhöhen und eine Reihe häufig verwendeter Diagnoseelemente zu gruppieren (Blockbildung), um die Wiederverwendbarkeit von Diagnosemodellen zu erhöhen und den Erstellungsaufwand zu reduzieren. Ferner kann das Diagnosemodell eine Datendarstellung aufweisen, die einer Vielzahl von Produkttypen gemeinsam ist, wodurch sich die Wiederverwendbarkeit des Modells erhöhen lässt.
<<<Analyse-Outsourcing-Cloud>>>
Die Analyse-Outsourcing-Cloud 27 umfasst eine Diagnoseergebnis-Speichereinheit 7, eine Ursachenanalyse-Verarbeitungseinheit 8, eine Analysedaten-Speichereinheit 9, eine Analyseregel-Aktualisierungseinheit 16, eine Analyseregel-Speichereinheit und eine Konfigurationsinformations-Speichereinheit.
Die Diagnoseergebnis-Speichereinheit 7 speichert die ECTL-Diagnosedaten, die über die Diagnosedatenmanagement-Cloud vom In-Edge-Controller 10 empfangen wurden. Der Datenfluss kann eine Serie von Datenflüssen D11, D21 und D25 oder eine Serie von Datenflüssen D11 und D26 sein. Wie oben beschrieben, können mit dem Datenfluss D26 mehr Echtzeitdaten erhalten werden.
Die Ursachenanalyse-Verarbeitungseinheit 8 bestimmt die Anomaliesursache der Produktkomponente, indem sie die ECTL-Diagnosedaten auf der Basis der Analyseregel und der Konfigurationsinformation analysiert. Die zu bestimmende Einheit der Komponente kann eine Ersatzteil-Einheit oder eine Komponenten-Einheit sein, die für eine Person, die eine bestimmte Anomaliesursache analysiert, leicht zu verstehen ist. Ferner ist es wünschenswert, dass die Ursachenanalyse-Verarbeitungseinheit 8 die Information über die Anomaliesursache mit der Information über die aufgetretene Anomalie korreliert. Wenn die Information des Edge-Device 12 in der Konfigurationsinformations-Speichereinheit nicht ausreicht, empfängt die Ursachenanalyse-Verarbeitungseinheit 8 die Designdaten 13 von der Edge-Datendistributor-Cloud 24 oder vom Hersteller-Computer 21 und verwendet die empfangenen Designdaten 13.
Die Analyseregel ist Information, die die Kettenbeziehung von Anomalien definiert, das heißt, die Kettenbeziehung von anormalen Zuständen, die auf der Basis der kausalen Beziehung der Anomalie verkettet auftreten. Die Analyseregel-Speichereinheit speichert derartige Analyseregeln. Die Analyseregel kann auf der Basis der Designdaten 13 oder auf der Basis des Diagnosemodells generiert werden. Die Analyseregel selbst kann daher vom Edge-Device-Hersteller-Computer 21 oder von der Diagnosedatenmanagement-Cloud 26 generiert und zur Analyse-Outsourcing-Cloud 27 übertragen werden. Alternativ dazu können die Designdaten 13 und das Diagnosemodell in der Analyse-Outsourcing-Cloud dupliziert werden, um in der Analyse-Outsourcing-Cloud Analyseregeln zu generieren. Eine davon wird weiter unten in 8 beispielhaft beschrieben.
Die Konfigurationsinformations-Speichereinheit speichert Konfigurationsinformation, die Information ist, die die Konfiguration des Produkts angibt. Die Konfiguration kann zum Beispiel statische Information wie die Modellnummer und die Seriennummer der Produktkomponente umfassen, sowie komponentenbezogene Werte, die sich mit dem Betrieb dynamisch ändern (zum Beispiel kumulativer Kraftstoffverbrauch) und aus anderen Quellen als den ECTL-Diagnosedaten erfasst werden.
Wenn im In-Edge-Controller 10 ein anormaler Zustand bestimmt wurde, kann dessen Ursache im In-Edge-Controller 10 oder außerhalb des In-Edge-Controllers 10 liegen (zum Beispiel im Edge-Device 12 und in anderen Komponenten des Edge-Device 12). Daher enthalten die Analyseregel und die Konfigurationsinformation bevorzugt nicht nur Informationen über den In-Edge-Controller 10, sondern auch über das Edge-Device 12 und andere Komponenten des Edge-Device 12.
Bei einer Änderung der Diagnosesequenz (oder der Designdaten 13) aktualisiert die Analyseregel-Aktualisierungseinheit 16 die in der Analyseregel-Speichereinheit gespeicherte Analyseregel der Änderung entsprechend. Zu diesem Zweck kann die Analyseregel-Aktualisierungseinheit 16 von der Diagnosedatenmanagement-Cloud 26 oder vom Hersteller-Computer 21 die Designdaten 13 empfangen.
<<Diagnosemodell-Definitionsbildschirm und Diagnosemodell>>
Als nächstes werden der Diagnosemodell-Definitionsbildschirm und das Diagnosemodell Bezug nehmend auf 7 beschrieben.
7 ist ein Diagramm, das ein Beispiel eines Diagnosemodell-Definitionsbildschirms zeigt. Der Diagnosemodell-Definitionsbildschirm 500 ist ein Bildschirm, der von der Diagnosemodell-Definitionseinheit 3 erzeugt wird, bei der Definition eines Diagnosemodells Eingabeinformation empfängt und der Eingabeinformation entsprechende Ausgabeinformation anzeigt. Dann erstellt die Diagnosemodell-Definitionseinheit 3 auf der Basis der auf dem Diagnosemodell-Definitionsbildschirm 500 eingegebenen Definitionsinformation ein bestimmtes Diagnosemodell und speichert das Diagnosemodell in der Diagnosemodell-Speichereinheit 4.
Auf dem Diagnosemodell-Definitionsbildschirm 500 wird auf der Basis der Designdaten 13 ein Bildschirm zum visuellen und interaktiven Entwurf von Produktfunktionen angezeigt. Der Bildschirmbenutzer entwirft unter Verwendung dieses Bildschirms eine abstrahierte Diagnosesequenz.
Der Diagnosemodell-Definitionsbildschirm 500 enthält einen Funktions- und Datenfluss-Definitionsbereich 501 und einen Bibliotheksbereich 502. Diese Bereiche haben die folgenden Bedeutungen.

* Im Bibliotheksbereich 502 sind Knoten (als Komponenten-Metaknoten bezeichnet), die Komponenten angegeben, die im Produkt enthalten sind, oder Komponentenkandidaten, die in Zukunft in das Produkt aufgenommen werden können, nach Typ geordnet. Der Komponenten-Metaknoten kann einem Komponententyp, einem Aggregat mehrerer Komponententypen, oder einem Teil eines bestimmten Komponententyps entsprechen.
* Im Funktions- und Datenfluss-Definitionsbereich sind ein Knoten, der im Produkt enthaltene Komponenten angibt (Komponenten-Instanzknoten), und ein Verknüpfungsobjekt enthalten (in der Zeichnung durch Pfeile dargestellt), das den Datenfluss zwischen den Komponenten angibt, die durch den Komponenten-Instanzknoten angegeben sind.

Einem Komponenten-Metaknoten kann eine Vielzahl von Attributinformationen hinzugefügt werden. Zudem kann ein Teil oder die Gesamtheit der Attributinformation durch die Diagnoseschaltung oder das Diagnoseprogramm erfasst und bestimmt werden. Zum Beispiel kann Folgendes als Attributinformation zum Komponenten-Metaknoten „GPU“ hinzugefügt werden:

* Vorliegen oder Abwesenheit eines internen Speicherfehlers
* Ob eine Rechenkern-Exception aufgetreten ist oder nicht
* Vorliegen oder Abwesenheit eines internen Busfehlers

Entsprechende Attributinformation wird auch dem Verknüpfungsobjekt zugewiesen. Die Attributinformation des Verknüpfungsobjekts ist zum Beispiel wie folgt.

* Bestimmungsinformation, die angibt, welche Attributinformation des Quellkomponenten-Instanzknotens im Datenfluss, der durch das Verknüpfungsobjekt angegeben ist, zum Zielkomponenten-Instanzknoten gesendet werden soll.
* Empfangshäufigkeit der Information

Das Obige ist die Attributinformation des Verknüpfungsobjekts. Es ist auch möglich, dem Komponenten-Instanzknoten Attributinformation hinzuzufügen. Die Attributinformatin kann zum Beispiel eine Teilmenge der Attributinformation des Komponenten-Metaknotens entsprechenden Typs sein.
Wenn der Bildschirmbenutzer eine Diagnosesequenz für eine neue Diagnoseschaltung zu erstellen wünscht, führt der Bildschirmbenutzer die folgenden Operationen durch.

* Im Bibliotheksbereich 502 einen Komponenten-Metaknoten für die neue Diagnoseschaltung erstellen und Attributinformation hinzufügen.
* Den erstellten Komponenten-Metaknoten in den Funktions- und Datenfluss-Definitionsbereich 501 ziehen und ablegen, um den Metaknoten zu instanziieren. Dadurch wird ein Komponenten-Instanzknoten für die neue Diagnoseschaltung erzeugt.
* Den Komponenten-Instanzknoten der Komponente, die von der Diagnoseschaltung diagnostiziert werden soll, anklicken und dann den erstellten Komponenten-Instanzknoten anklicken. Dadurch wird ein Verknüpfungsobjekt erzeugt, das bedeutet, dass Daten von der zu diagnostizierenden Komponente zur Diagnoseschaltung fließen.
* Die Attributinformation des von der Diagnoseschaltung zu diagnostizierenden Quellkomponenten-Instanzknotens in der Attributinformation des erstellten Verknüpfungsobjekts einstellen.

Durch Durchführen eines Speichervorgangs nach den obigen Operationen wird das Diagnosemodell in der Diagnosemodell-Speichereinheit 4 gespeichert. Die Hardwareabhängigkeit der Anzeigeinformation auf dem Diagnosemodell-Definitionsbildschirm ist im Vergleich zur Diagnosesequenz, zur Diagnoseschaltung und zum Diagnoseprogramm geringer, wodurch die Wiederverwendbarkeit für verschiedene Typen erhöht wird. Zudem können Diagnoseelemente gruppiert sein, da einem Knoten oder Verknüpfungsobjekt eine Vielzahl von Attributinformationen hinzugefügt werden, wodurch sie gruppiert werden können.
Das Diagnosemodell speichert den Inhalt des Funktions- und Datenfluss-Definitionsbereichs, der auf dem obigen Diagnosemodell-Definitionsbildschirm 500 erstellt wurde. Daher ist zum Beispiel Folgendes im Diagnosemodell gespeichert.

* Komponenten-Metaknoten-Information. Diese Information enthält Attributinformation.
* Komponenten-Instanzknoten-Informationen. Diese Information enthält die Kennung des Komponenten-Metaknotens, die bei der Erstellung festgelegt wurde. Zusätzlich kann diese Information Attributinformation enthalten.
* Verknüpfungsobjekt-Information. Diese Information enthält eine Kennung des Quellkomponenten-Instanzobjekts, einen Kennung des Zielkomponenten-Instanzobjekts und Attributinformation für fließende Daten.

Hier lässt sich die Hardwareabhängigkeit des Diagnosemodell-Definitionsbildschirms wie folgt reduzieren:

* Als Name der Attributinformation wird ein generischer Name des Diagnoseelements in der Diagnosesequenz gewählt.
* Das Diagnosemodell enthält keine hardwareabhängige Information (zum Beispiel die obigen Parameter und Verarbeitungsparameter) von Diagnoseelementen, die in der Diagnosesequenz enthalten sind.

«Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices»
6 ist ein Diagramm, das den Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices in der ersten Lösung zeigt. Im Folgenden wird jeder davon beschrieben.
(Schritt S1B01) Die Diagnosedatenmanagement-Cloud 26 (genauer gesagt, die Diagnosemodell-Definitionseinheit 3) generiert eine Diagnosesequenz.
(Schritt S1B02) Die Diagnosedatenmanagement-Cloud 26 (genauer gesagt, die Diagnosemodell-Definitionseinheit 3) überträgt die generierte Diagnosesequenz. In 6 wird der Edge-Device-Hersteller-Computer 21 als Beispiel für das Übertragungsziel beschrieben, doch das Übertragungsziel ist auch in dieser Lösung nicht auf diesen Computer oder diese Cloud beschränkt.
(Schritt S1A01) Der Edge-Device-Hersteller fertigt das Edge-Device 12. Dabei wird die in S1B02 übertragene Diagnosesequenz im In-Edge-Controller 10 gespeichert.
(Schritt S1A02) Der Edge-Device-Hersteller liefert das gefertigte Edge-Device 12 aus. Der Versand kann neben den in 1 gezeigten und in der zugehörigen Beschreibung genannten Unternehmen oder Gruppen auch an Einzelpersonen erfolgen (im Folgenden zusammenfassend als Edge-Device-Benutzerentität bezeichnet). Das in diesem Schritt ausgelieferte Edge-Device 12 kann als ein Edge-Device der aktuellen Generation bezeichnet werden.
(Schritt S1C01) Die Edge-Device-Benutzerentität startet den Betrieb des Edge-Device 12. Das Edge-Device 12, das den Betrieb aufgenommen hat, bewegt sich durch einen automatischen Betrieb wie z.B. automatisches Fahren, wird aufgeladen oder betankt oder wird vorübergehend auf einem Parkplatz abgestellt.
(Schritt S1C02) Das Edge-Device 12 (genauer gesagt, der In-Edge-Controller 10, und noch genauer, die Zustandsdaten-Diagnoseeinheit 110) erkennt (oder diagnostiziert), dass das Edge-Device 12 in einem anormalen Zustand ist. Danach wird die durch die Zustandsdaten-Diagnoseeinheit 110 beschriebene Diagnose durchgeführt, und die ECTL-Diagnosedaten werden übertragen. 6 veranschaulicht einen Fall, bei dem die Daten über die Diagnosedatenmanagement-Cloud übertragen werden (Fluss der Datenflüsse D11 und D26). Dieser Fluss hat den Vorteil, dass die Übertragung näher an Echtzeit erfolgen kann als über die Edge-Datendistributor-Cloud 24, doch auch andere Wege können verwendet werden.
(Schritt S1D01) Die Analyse-Outsourcing-Cloud 27 empfängt die ECTL-Diagnosedaten. Dann analysiert die Ursachenanalyse-Verarbeitungseinheit 8 die durch die ECTL-Diagnosedaten angezeigte Ursache des anormalen Zustands.
(Schritt S1D02) Die Analyse-Outsourcing-Cloud 27 überträgt die Analysedaten von Schritt S1D01 zur Edge-Device-Benutzerentität, zum Edge-Device-Hersteller-Computer und zur Diagnosedatenmanagement-Cloud 26. Der Inhalt der Analysedaten kann je nach dem, ob sie an eine Edge-Device-Benutzerentität oder an einen Edge-Device-Hersteller-Computer übertragen werden, unterschiedlich sein. Wie in 6 gezeigt, sind die Übertragungswege die Datenflüsse D22, D26 und D27. In diesem Schritt kann ein spezifisches Beispiel der bereits beschriebenen Daten übertragen werden.
(S1C03) Die Edge-Device-Benutzerentität stellt das Edge-Device 12 unter Bezugnahme auf die empfangenen Analysedaten wieder her.
(S1B03) Die Diagnosedatenmanagement-Cloud (genauer gesagt, die Diagnoseschaltungs- und Steuerungs-Aktualisierungseinheit) aktualisiert auf der Basis der empfangenen Analysedaten die Diagnoseschaltung oder das Diagnoseprogramm, um das Auftreten anormaler Zustände zu reduzieren. Dann wird die aktualisierte Diagnoseschaltung oder das aktualisierte Diagnoseprogramm zum Edge-Device-Hersteller übertragen. Die Diagnosedatenmanagement-Cloud 26 kann in diesem Schritt die Diagnosesequenz aktualisieren oder kann einen Teil der Designdaten 13, für deren Entwurf der Edge-Device-Hersteller zuständig ist, aktualisieren oder dessen Aktualisierung vorschlagen. Diagnoseschaltungen und Diagnoseprogramme, die auf diese Weise aktualisiert wurden, sind verbesserte Daten.
(S1A03) Der Edge-Device-Hersteller erstellt auf der Basis der empfangenen Analysedaten die Designdaten 13 für das Edge-Device der nächsten Generation 12. Der Edge-Device-Hersteller kann sich bei der Erstellung auf verbesserte Daten stützen.
Als Prozess nach dem Ablauf von 6 kann der Edge-Device-Hersteller in Schritt S1B01 auf der Basis den Daten D26 die Diagnosesequenz generieren und die Diagnosesequenz dann aktualisieren (das heißt, eine verbesserte Diagnosesequenz erzeugen). Die verbesserte Diagnosesequenz gehört zu den verbesserten Daten. Wenn der Edge-Device-Hersteller eine Funktion aktualisiert, um auf das Design bezogene Probleme oder wichtige Punkte des Edge-Device 12 zu lösen, kann der Edge-Device-Hersteller Aktualisierungsdaten zur Edge-Datendistributor-Cloud 24 übertragen. Dadurch können die Aktualisierungsdaten zum Edge-Device 12 übertragen werden, um die Funktion zu verbessern und das Problem zu lösen.
Das Obige ist die die Erklärung des Ablaufs. Diese Lösung ermöglicht es der Edge-Device-Benutzerentität, eine Anomalie schneller zu beheben. Zudem erleichtert es dem Edge-Device-Hersteller das Design eines Edge-Device der nächsten Generation, das das Auftreten von Anomalien reduziert.
<Zweite Lösung (für Händler oder Reparaturbetriebe)>
Das verteilte System 1000 kann die ECTL-Diagnosedaten und die Analysedaten einem Händler oder Reparaturbetrieb bereitstellen, und im Folgenden wird diese Lösung anhand eines Beispiels beschrieben. Dieses Beispiel ist lediglich ein Anwendungsbeispiel des verteilten System 1000 gemäß der vorliegenden Erfindung und schränkt den Anwendungsbereich der vorliegenden Erfindung nicht ein.
Dieses Beispiel weist im Wesentlichen die gleiche Konfiguration auf wie die obige Lösung für Edge-Device-Hersteller. Daher wird auf wiederholte Beschreibungen verzichtet, und es wird hauptsächlich auf abweichende Punkte eingegangen. Die Diagnosedaten-Cloud 32 stellt dem Händler oder Reparaturbetrieb des Edge-Device 12 zusätzlich zu den Analysedaten der Ursachenanalyse auch Reparaturinformation (auszutauschende Teile und Austauschzeitplan) bereit.
<<Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices>>
8 ist ein Diagramm, das den Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices in einer zweiten Lösung zeigt. Im Folgenden wird jeder davon beschrieben. Die Beschreibung von Elementen, die denen in der ersten Lösung gleichen (insbesondere von Elementen, die in der Zeichnung dasselbe Bezugszeichen tragen), wird ausgelassen. Im folgenden Beispiel wird angenommen, dass die Benutzerentität des Edge-Device ein MaaS-Unternehmen oder eine Vermietungsfirma ist, und dass der Entität für das Edge-Device, bei dem die Anomalie aufgetreten ist, ein Ersatzgerät geliehen wird, was jedoch nicht der Fall sein muss. Das heißt, der Benutzer kann warten, bis der Händler oder der Reparaturbetrieb die Reparatur abgeschlossen hat, ohne das Edge-Device 12 auszutauschen.
(Schritt S1D01) Die Analyse-Outsourcing-Cloud 27 empfängt die ECTL-Diagnosedaten. Dann analysiert die Ursachenanalyse-Verarbeitungseinheit 8 die Ursache des anormalen Zustands, der durch die ECTL-Diagnosedaten angezeigt wird. Der Analyseinhalt kann der gleiche wie in der ersten Lösung sein oder davon abweichen. In dieser Lösung werden als Bestandeil der Ursachenanalyse die im Edge-Device 12 enthalten Teile (Komponenten), die auszutauschen sind, identifiziert. Ferner kann der Ursachenanalyseprozess die geschätzte Austauschzeit des Teils oder die Zeit schätzen, bis das Ersatzteil beim Händler oder Reparaturbetrieb ankommt. In der folgenden Beschreibung wird die Information über die auszutauschenden Teile und die geschätzte Zeit als in den Analysedaten enthalten beschrieben.
(Schritt S1D02) Die Analyse-Outsourcing-Cloud 27 überträgt die Analysedaten von Schritt S2D01 zur Händler- oder Reparaturbetriebs-Cloud 28. Der Übertragungsweg ist der Datenfluss D32, wie in 8 gezeigt.
(Schritt S2C03) Die Edge-Device-Spezifikationsentität tauscht das Edge-Device 12 aus. Das ausgetauschte Edge-Device 12 mit dem anormalen Zustand wird zum Händler oder Reparaturbetrieb geschickt. In 8 sorgt die Händler- oder Reparaturbetriebs-Cloud nicht für ein Ersatz-Edge-Device. Zudem verwendet die Edge-Device-Spezifikationsentität ein Ersatz-Edge-Device.
(Schritt S2E01) Nach Empfang der Analysedaten prüft der Händler oder der Reparaturbetrieb den Lagerbestand und bestellt das Ersatzteil beim Edge-Device-Hersteller, falls es nicht vorrätig ist. Diese Entscheidung kann getroffen werden, bevor das Edge-Gerät 12, in welchem die Anomalie aufgetreten ist, beim Händler oder der Reparaturbetrieb eintrifft. Insbesondere, wenn das Edge-Device ein bewegter Körper ist und dieser sich aufgrund einer Anomalie nicht bewegen kann, kann dies viel Zeit in Anspruch nehmen, da es erforderlich sein kann, den bewegten Körper mit einem Abschleppwagen von dem Ort, an dem die Anomalie aufgetreten ist, zu den Räumlichkeiten des Händlers oder des Reparaturbetriebs zu befördern. Maßnahmen, die durch solch einen Empfang von Analysedaten veranlasst werden, können die Reparaturzeit verkürzen. Darüber hinaus ist es der Händler- oder Reparaturbetriebs-Cloud möglich, Reparaturen unter Berücksichtigung der geschätzten Zeit systematischer durchführen. Der Händler oder der Reparaturbetrieb repariert dann das Edge-Device 12.
(Schritt S2E02) Der Händler oder der Reparaturbetrieb verschickt das reparierte Edge-Device 12 an die Edge-Device-Benutzerentität. Die Entität kann dabei eine andere als die Entität vor dem Austausch sein, oder sie kann dieselbe sein.
(Schritt S2C04) Die Edge-Device-Benutzerentität startet den Betrieb des reparierten Edge-Device 12.
<<Datenbildschirm nach dem Ursachenanalyseprozess>>
9 ist ein Diagramm, das ein Beispiel eines Datenbildschirms 600 nach der Ursachenanalyse für Händler oder Reparaturbetriebe zeigt. Die Information, die auf dem Bildschirm angezeigt wird, ist in den Analysedaten, die in Schritt S2D02 übertragen wurden, enthalten. Der Bildschirm wird von einem Mitarbeiter eines Händlers oder Reparaturbetriebs benutzt. Der Bildschirm ist als Webanwendung ausgeführt.
Der Datenbildschirm 600 nach der Ursachenanalyse für Händler oder Reparaturbetriebe umfasst einen Bereich zur Anzeige der Bezeichnung und der Modellnummer, die das Edge-Device angeben, das der Ursachenanalyse unterzogen wurde, einen Bereich zur Anzeige der Historie der Benutzerentität und einen Bereich zur Anzeige der Analysedaten. Im Folgenden wird jeder dieser Bereiche beschrieben.

* Im Bereich zur Anzeige der Bezeichnung und der Modellnummer wird zum Beispiel, wenn das Edge-Device, das der Ursachenanalyse unterzogen wurde, ein Kraftfahrzeug ist, der Fahrzeugtyp, das Modell oder die Konfigurationsinformations-ID angezeigt.
* Im Bereich zur Anzeige der Benutzerentität wird die ID der Entität, die das Edge-Device verwendet hat, in Form einer Historie angezeigt. Andere Historien (zum Beispiel das Datum der Inbetriebnahme oder die Wartungshistorie) können in diesem Bereich angezeigt werden.

Im Bereich zur Anzeige von Analysedaten nach dem Ursachenanalyseprozess wird zum Beispiel Folgendes in Bezug auf das Edge-Device 12 angezeigt. Nicht alle Anzeigen sind unbedingt erforderlich.

* ID der Komponente im anormalen Zustand.
* Datum und Uhrzeit des Auftretens des anormalen Zustands.
* Registerauszüge und Speicherauszüge, die Register- und Speicherwerte anzeigen, die während der Diagnose von der Diagnoseschaltung und dem Diagnoseprogramm erfasst wurden. Diese Werte sind für Experten bestimmt.
* Kommunikationsprotokoll.
* Information zur Angabe der Ursache der Anomalie.

Hier enthält die Anomalieursache Information, um der aufgetretenen Anomaliesursache entsprechend zu bestimmen, ob die Anomalie eine Softwareanomalie oder eine Hardwareanomalie ist. Dies deshalb, weil die Verfahren zur Behebung einer Softwareanomalie und einer Hardwareanomalie oft sehr unterschiedlich sind.
Wie oben erwähnt, ermöglicht diese Lösung einem Händler oder Reparaturbetrieb, schnell zu erkennen, dass das Edge-Device in einem anormalen Zustand ist und repariert werden muss. Zudem kann ein größerer Personenkreis mit der Reparatur betraut werden, da der Händler oder der Reparaturbetrieb keine Designdaten zu verwenden hat, um auszutauschende Teile zu identifizieren.
<Dritte Lösung (für Versicherungsgesellschaften)>
Das verteilte System 1000 kann die ECTL-Diagnosedaten und Analysedaten der Versicherungsgesellschaft bereitstellen, und diese Lösung wird im Folgenden anhand eines Beispiels beschrieben. Dieses Beispiel ist lediglich ein Anwendungsbeispiel des verteilten System 1000 gemäß der vorliegenden Erfindung und schränkt den Anwendungsbereich der vorliegenden Erfindung nicht ein.
Dieses Beispiel weist im Wesentlichen die gleiche Konfiguration auf wie die oben beschriebene Lösung für Edge-Device-Hersteller. Daher wird auf wiederholte Beschreibungen verzichtet, und es wird hauptsächlich auf abweichende Punkte eingegangen. Es wird angenommen, dass die Diagnosedaten-Cloud 32 der Versicherungsgesellschaft für das Edge-Device 12 als Teil der Analysedaten der Ursachenanalyse statistische Information wie die Ursache und die Häufigkeit des Auftretens der erkannten Anomalie bereitstellt. In der folgenden Beschreibung wird das von der Versicherungsgesellschaft gezahlte Geld als Auszahlung im Versicherungsfall bezeichnet, und das vom Versicherungsnehmer an die Versicherungsgesellschaft gezahlte Geld wird als Versicherungsprämie bezeichnet.
«Versicherer-Cloud»
In dieser Lösung speichert die Versicherer-Cloud 29 als Speicherressource die folgenden Daten.

* Daten zu den Vertragsbedingungen: Daten zur Angabe der Vertragsbedingungen, die den Leistungen des Versicherungsdienstes entsprechen. Diese Daten speichern die im Versicherungsvertrag festgelegten Bedingungen wie z.B. die Auszahlungsbedingungen im Versicherungsfall (einschließlich des Betrags), die Versicherungsprämie und die Vertragslaufzeit.
* Daten zum Versicherungsnehmer: Daten in Bezug auf den Versicherungsnehmer. Diese Daten speichern den Namen des Versicherungsnehmers, eine ID, die die geltenden Vertragsbedingungen angibt, und das Datum des Versicherungsbeginns. Im Falle eines Versicherungsdienstes, der nur gilt, wenn der Versicherungsnehmer ein bestimmtes Edge-Device 12 benutzt, können Daten (zum Beispiel eine Fahrzeugnummer) enthalten sein, die das Edge-Device 12 identifizieren. Die Daten können unternehmensbezogene Daten für Geschäftsaktivitäten speichern, die nicht direkt mit dem Vertrag im Zusammenhang stehen.
* Historie der Auszahlungen im Versicherungsfall:
- Daten in Bezug auf die Historie der Auszahlungen im Versicherungsfall. Diese Daten speichern das Auszahlungsdatum, den Auszahlungsbetrag der Versicherung, die ID des Versicherungsnehmers, der Zahlungsempfänger ist, die ID der Vertragsbedingungen und Daten, die zur Ermittlung des Auszahlungsbetrags verwendet werden (zum Beispiel Daten, die angeben, welche Art von Anomalie oder Unfall aufgetreten ist) .
* Historie des Zahlungseingangs der Versicherungsprämie: Daten in Bezug auf die Historie des Zahlungseingangs der Versicherungsprämie. Diese Daten speichern das Datum des Zahlungseingangs, die Versicherungsprämie, die ID des Versicherungsnehmers, der die Zahlungsquelle ist, und die ID der Vertragsbedingungen.

Nicht alle der oben beschriebenen Daten sind wesentlich, und es ist nicht notwendig, die einzelnen Daten in streng getrennten Tabellen oder Speicherbereichen zu speichern.
In der Versicherer-Cloud wird durch die Versicherungsgesellschaft ein Programm zur Bereitstellung von Versicherungsdiensten (im Folgenden als Versicherungsdienst-Programm bezeichnet) ausgeführt. Das Versicherungsdienst-Programm empfängt vom Versicherungsnehmer die Daten, die den obigen Daten zugrunde liegen, und aktualisiert diese Daten dem Eingang der Versicherungsprämien und den Auszahlungen im Versicherungsfall entsprechend.
Die Versicherer-Cloud 29 führt außerdem ein Programm zur Analyse der Vertragsbedingungen aus. Dieses Programm ist ein Programm, das einen Analyseprozess durchführt, der zur Revision der Vertragsbedingungen erforderlich ist, indem es auf die obigen Daten zugreift. Das Programm zur Analyse der Vertragsbedingungen kann zum Beispiel die folgenden Prozesse durchführen.

* Schätzung der Anzahl der Versicherungsverträge anhand der obigen Daten, des Gesamtbetrags der Versicherungsprämien auf der Basis der Anzahl der Verträge, und des Gesamtbetrags der Auszahlungen im Versicherungsfalls unter Annahme bestimmter Vertragsbedingungen.
* Kalkulation eines Vorschlags für Vertragsbedingungen, die unter Annahme betriebswirtschaftlicher Kennzahlen wie die Gewinnhöhe oder die Profitrate der Versicherungsgesellschaft geeignet sind.

«Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices»
10 ist ein Diagramm, das den Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices in einer dritten Lösung zeigt. Im Folgenden wird jeder davon beschrieben. Die Beschreibung von Abschnitten, die denen in der ersten und zweiten Lösung gleichen (insbesondere von Abschnitten, die in der Zeichnung das gleiche Bezugszeichen tragen), wird ausgelassen.
(Schritt S3D01) Die Analyse-Outsourcing-Cloud 27 empfängt die ECTL-Diagnosedaten. Dann analysiert die Ursachenanalyse-Verarbeitungseinheit 8 die durch die ECTL-Diagnosedaten angezeigte Ursache des anormalen Zustands. Der Analyseinhalt kann derselbe wie in der ersten und zweiten Lösung oder anders sein. In dieser Lösung wird statistische Information, wie z.B. die Ursache und die Häufigkeit des Auftretens der erkannten Anomalie, als Teil des Ursachenanalyseprozesses bereitgestellt.
(Schritt S3D02) Die Analyse-Outsourcing-Cloud 27 überträgt die Analysedaten von Schritt S2D01 zur Versicherer-Cloud 29. Der Übertragungsweg ist D32, wie in 8 dargestellt.
(Schritt S3F01) Die Versicherer-Cloud (das heißt, das Vertragsbedingungsanalyseprogramm) kalkuliert unter Verwendung der empfangenen Analysedaten und der obigen Daten, die in der Speicherressource gespeichert sind, einen Vorschlag für revidierte Versicherungsvertragsbedingungen.
Das Obige ist der Ablauf. Was die Bedingungen des Versicherungsvertrages anbetrifft, wird der Versicherungsnehmer den Vertrag auch bei einer niedrigen Versicherungsprämie nicht abschließen, wenn die Bedingungen für die Auszahlung im Versicherungsfall zu streng sind. Wenn die Bedingungen für die Auszahlung im Versicherungsfall dagegen zu sehr gelockert werden, verschlechtert sich die Bilanz für die Versicherungsgesellschaft zu sehr, und der Dienst kann nicht fortgeführt werden. Auf der Basis der verarbeiteten Daten, die von der Analyse-Outsourcing-Cloud bereitgestellt werden, können die Bedingungen für die Auszahlung im Versicherungsfall unter Berücksichtigung der Häufigkeit des Auftretens anormaler Zustände im In-Edge-Controller 10 festgelegt werden. Wenn zum Beispiel eine bestimmte Bedingung (zum Beispiel Typ des Edge-Device 12, Einsatzumgebung, Typ der Benutzerentität) eine hohe Häufigkeit anormaler Zustände im In-Edge-Controller verursacht, kann die Versicherungsprämie für diese Bedingung erhöht werden, und umgekehrt kann die Prämie unter Bedingungen, bei denen die Häufigkeit des Auftretens gering ist, verringert werden, wodurch eine Optimierung der Versicherungsprämie möglich wird. Dieser Vorteil ist umso größer, je zahlreicher Anomalien im In-Edge-Controller 10 aufgrund der Verbreitung des automatischen Betriebs werden.
<Vierte Lösung (für Vermietungsfirmen oder MaaS-Unternehmen)>
Die zweite Lösung für Händler oder Reparaturbetriebe ist auch auf Vermietungsfirmen oder MaaS-Unternehmen anwendbar. Die Vermietungsfirma oder das MaaS-Unternehmen führt jedoch im Gegensatz zum Händler oder zum Reparaturbetrieb keine detaillierten Reparaturen am Edge-Device 12 durch. Anderseits kann im Falle eines Dienstes, der von einer Vermietungsfirma oder einem MaaS-Unternehmen angeboten wird, von einem Benutzer des Dienstes nur dann ein angemessener Preis verlangt werden, wenn das Edge-Device 12 ordnungsgemäß funktioniert. Deshalb wird die Zeit bis zur Wiederherstellung des Edge-Device 12 aus dem anormalen Zustand verkürzt.
Daher ist es wünschenswert, die Information, die der Vermietungsfirma oder dem MaaS-Unternehmen durch diese Lösung bereitgestellt wird, anzupassen. In Bezug auf diese Lösung wird zunächst ein Datenbildschirm 700 nach der Ursachenanalyse für eine Vermietungsfirma oder ein MaaS-Unternehmen beschrieben, wobei insbesondere auf die Unterschiede eingegangen wird.
<<Datenbildschirm nach der Ursachenanalyse>>
11 ist ein Diagramm, das ein Beispiel des Datenbildschirms 700 nach der Ursachenanalyse für eine Vermietungsfirma oder ein MaaS-Unternehmen zeigt. Der Bildschirm wird von einem Mitarbeiter einer Vermietungsfirma oder eines MaaS-Unternehmens benutzt. Der Bildschirm ist als Webanwendung realisiert. Da der Bildschirm von 11 die gleiche Information enthält wie der Datenbildschirm nach der Ursachenanalyse von 9 (für Händler oder Reparaturbetriebe), werden hier hauptsächlich abweichende Punkte erläutert. Dieser Bildschirm ist ein Bildschirm, der durch den Prozess der Analyse-Outsourcing-Cloud 27 auf der Vermietungsfirmen- oder MaaS-Unternehmens-Cloud 22 angezeigt wird.
Der Datenbildschirm 700 enthält einen Bereich zur Anzeige der Bezeichnung und der Modellnummer, die das Edge-Device angeben, das der Ursachenanalyse unterzogen wurde, einen Bereich zur Anzeige der Historie der Benutzerentität und einen Bereich zur Anzeige der Analysedaten. Im Folgenden wird jeder dieser Bereiche beschrieben.

* Im Bereich zur Anzeige der Bezeichnung und der Modellnummer wird zum Beispiel, wenn das Edge-Device, das der Ursachenanalyse unterzogen wurde, ein Kraftfahrzeug ist, der Fahrzeugtyp, das Modell oder die Konfigurationsinformations-ID angezeigt.
* Im Bereich zur Anzeige der Benutzerentität wird die ID der Entität, die das Edge-Device benutzt hat, in Form einer Historie angezeigt. Andere Historien (zum Beispiel das Datum der Inbetriebnahme oder die Wartungshistorie) können in diesem Bereich angezeigt werden.

Im Bereich zur Anzeige von Analysedaten nach dem Ursachenanalyseprozess wird in Bezug auf das Edge-Device 12 zum Beispiel Folgendes angezeigt. Nicht alle Anzeigen sind unbedingt erforderlich.

* ID der Komponente im anormalen Zustand.
* Datum und Uhrzeit des Auftretens des anormalen Zustands.
* Ort des Auftretens des anormalen Zustands.
* Dringlichkeit der Behebung des anormalen Zustands.
* Erforderliche Reaktionszeit für den anormalen Zustand.
* Kosten zur Behebung des anormalen Zustands.
* Information zur Angabe der Ursache der Anomalie.
* Historie des Auftretens anormaler Zustände.

Die Informationen zur weiteren Verkürzung der Zeit zur Wiederherstellung des Edge-Device 12 aus dem anormalen Zustand sind hier der Ort, die Dringlichkeit und die erforderliche Reaktionszeit. Der Vermieter oder das MaaS-Unternehmen hat die Möglichkeit, unter Berücksichtigung dieser Faktoren ein geeignetes Wiederherstellungsverfahren auszuwählen. Die Wiederherstellungsverfahren, die durch Bereitstellen dieses Bildschirms möglich sind, sind zum Beispiel folgende:

* Reparaturarbeiten vorrangig an Edge-Devices durchführen, deren Ort, an dem der anormale Zustand aufgetreten ist, vom Standort des Vermieters oder des MaaS-Unternehmens weiter entfernt ist. Ein Beispiel, das diese Priorität widerspiegelt, ist das Vorsehen eines Esatz-Edge-Device 12.
* Einen anormalen Zustand mit niedriger Dringlichkeit beheben, bevor er zu einem anormalen Zustand hoher Dringlichkeit wird. In dieser Lösung ist dies möglich, da der Dringlichkeitsgrad der Reaktion auf der Basis des internen Zustands des In-Edge-Controllers 10 genau bestimmt werden kann. Die Dringlichkeit kann bestimmt werden, indem als Analyseprozess in der Analyse-Outsourcing-Cloud 27 eine Korrelationsanalyse der ECTL-Diagnosedaten durchgeführt wird, die Korrelation als Analysedaten erhalten wird und die Korrelation bei der Einstellung der Dringlichkeit berücksichtigt wird. Wenn zum Beispiel ein anormaler Zustand für den In-Edge-Controller 10 selbst nicht fatal ist, kann die Priorität herabgesetzt werden, doch wenn ein anormaler Zustand mit hoher Korrelation eine hohe Dringlichkeit hat, wird der frühere anormale Zustand auf mittel oder hoch gesetzt, was höher als niedrig ist.
* Reparaturarbeiten auf der Basis der Dringlichkeit priorisieren. Insbesondere, wenn im selben Edge-Device 12 anormale Zustände mit verschiedenen Dringlichkeitsgraden auftreten, kann die Behebung eines anormalen Zustands mit höherer Dringlichkeit zur Behebung eines anormalen Zustands mit geringerer Dringlichkeit führen.

«Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices»
Der Ablauf der Kooperation zwischen Computern, Clouds und Edge-Devices ist wie in 8 in Bezug auf die zweite Lösung beschrieben. Da der in 11 beschriebene Bildschirm jedoch in Schritt S2D01 ausgeführt wird, der in der Analyse-Outsourcing-Cloud 27 erfolgt, beinhaltet der in diesem Schritt durchgeführte Ursachenanalyseprozess einen Prozess des Generierens der in 11 beschriebenen Information. Es versteht sich, dass die in 11 beschriebene Information in den Daten enthalten ist, die im Schritt S2D02 der Datenübertragung übertragen werden.
< Modifikationen >
Damit ist die Erklärung der jeweiligen Lösungen abgeschlossen. Die vorliegende Erfindung ist nicht auf die obigen Ausführungsformen beschränkt und schließt verschiedene Modifikationen ein, wie folgt.
Die Daten, die vom In-Edge-Controller 10 als ECTL-Diagnosedaten ausgegeben werden, müssen nicht unbedingt einen anormalen Zustand oder einen Zustand einer Hardwarekomponente anzeigen. Zum Beispiel kann neben dem aktuellen Zustand der Software auch die Historie vergangener Prozesse (zum Beispiel Parameter und Hyperparameter des neuronalen Netzes, Lernzustände anderer Maschinenlernverfahren, und im Falle eines automatischen Fahrprogramms, die automatische Fahrregel, die der Grund für eine bestimmte Steuerung des Bewegungs- oder Betätigungsmechanismus ist, sowie der Ort (Name) des Verzweigungsprozesses) in die ECTL-Diagnosedaten aufgenommen werden.
Obwohl oben beschrieben wurde, dass ein Unternehmen über eine Cloud verfügt, die einen bestimmten Dienst bereitstellt, ist es für das Unternehmen nicht immer erforderlich, die Hardware-Ressourcen, aus denen die Cloud gebildet ist, zu besitzen. Dementsprechend ist es für das Unternehmen nicht immer erforderlich, einen Teil oder die Gesamtheit des Programms zu besitzen, um einen bestimmten Dienst anzubieten.
Es ist möglich, einen Teil der Konfiguration einer Ausführungsform durch die Konfiguration einer anderen Ausführungsform zu ersetzen. Es ist auch möglich, die Konfiguration einer Ausführungsform zur Konfiguration einer anderen Ausführungsform hinzuzufügen.
Darüber hinaus ist es möglich, einen Teil der Konfiguration der Ausführungsform hinzuzufügen, zu streichen oder durch eine andere Konfiguration zu ersetzen.
Jede der obigen Konfigurationen, Funktionen, Verarbeitungseinheiten, Verarbeitungsmittel und dergleichen kann durch Hardware realisiert werden, indem ein Teil oder die Gesamtheit davon zum Beispiel durch eine integrierte Schaltung realisiert wird. Ferner kann jede der obigen Konfigurationen, Funktionen und dergleichen durch Software realisiert werden, indem ein Prozessor ein Programm interpretiert und ausführt, das jede Funktion realisiert. Information wie z.B. Programme, Tabellen und Dateien, die jede der Funktionen realisieren, kann in einem Speichergerät wie z.B. einem Speicher, einer Festplatte oder einem Halbleiterlaufwerk (SSD) oder in einem Speichermedium wie z.B. eine IC-Karte, eine SD-Karte oder eine DVD gespeichert sein.
Die Steuer- und Datenleitungen sind diejenigen, die zur Erläuterung als notwendig erachtet wurden, doch nicht alle Steuer- und Datenleitungen am Produkt wurden dargestellt. Tatsächlich können nahezu alle Konfigurationen als durch ein Kommunikationsnetzwerk, einen Bus oder dergleichen miteinander verbunden betrachtet werden.
Die Technik gemäß der vorliegenden Erfindung ist nicht auf das verteilte System beschränkt und kann in verschiedenen Formen wie z.B. einen Computer, ein computerlesbares Programm, ein verteiltes Verarbeitungsverfahren bereitgestellt werden.
<Kurzdarstellung>
In dieser Beschreibung wurde Folgendes erläutert. Da der Cloud-Server aus mindestens einem Computer besteht, wird ein Computer stellvertretend erläutert.
«Aspekt 1»
Verteiltes System, umfassend ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Diagnosedaten-Computer und einen Hersteller-Computer, der ein Computer ist, der einem Hersteller des Edge-Device gehört, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, wobei der Diagnosedaten-Computer: Diagnosedaten empfängt, die einen internen Zustand im In-Edge-Controller anzeigen, auf der Basis der Diagnosedaten einen Ursachenanalyseprozess des Zustands im In-Edge-Controller durchführt, und die Daten nach dem Ursachenanalyseprozess oder auf der Basis des Ergebnisses des Ursachenanalyseprozesses verbesserte Daten für das Edge-Device zum Hersteller-Computer überträgt.
«Aspekt 2»
Verteiltes System gemäß Aspekt 1, wobei der Diagnosedaten-Computer in einer Speicherressource eine Analyseregel speichert, die eine kausale Beziehung des im Edge-Device auftretenden Zustands speichert, und der Diagnosedaten-Computer während des Ursachenanalyseprozesses die Analyseregel referenziert.
«Aspekt 3»
Verteiltes System gemäß Aspekt 1, wobei die verbesserten Daten Designdaten für das Edge-Device der nächsten Generation sind, wenn der Diagnosedaten-Computer verbesserte Daten zum Hersteller-Computer überträgt.
«Aspekt 4»
Verteiltes System gemäß Aspekt 1, wobei die verbesserten Daten verbesserte Daten des In-Edge-Controllers sind und der Hersteller-Computer die verbesserten Daten zum Edge-Device überträgt, wenn der Diagnosedaten-Computer verbesserte Daten zum Hersteller-Computer überträgt.
«Aspekt 5»
Verteiltes System gemäß Aspekt 4, außerdem umfassend einen Edge-Datendistributor-Computer, der die verbesserten Daten vom Hersteller-Computer empfängt und die verbesserten Daten zum Edge-Device überträgt, wobei der Edge-Datendistributor-Computer: die Diagnosedaten vom Diagnosedaten-Computer empfängt, die Diagnosedaten in einer Speicherressource speichert, die in der Speicherressource gespeicherten Diagnosedaten gemäß einem bestimmten Zeitplan verarbeitet, und die verarbeiteten Diagnosedaten an einen Dienstanbieter-Computer überträgt, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet.
«Aspekt 6»
Verteiltes System gemäß Aspekt 1, wobei der Diagnosedaten-Computer: die Daten nach dem Ursachenanalyseprozess oder die Daten, die auf der Basis des Ergebnisses des Ursachenanalyseprozesses die Ursache einer Anomalie des Edge-Device identifizieren, an einen Dienstanbieter-Computer überträgt, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet.
«Aspekt 7»
Verteiltes System gemäß Aspekt 1, wobei der Diagnosedaten-Computer: die Daten nach dem Ursachenanalyseprozess oder die Daten, die auf der Basis des Ergebnisses des Ursachenanalyseprozesses ein Teil identifizieren, das die Ursache einer Anomalie des Edge-Device ist, und einen Austauschzeitplan des Teils auf der Basis des Ergebnisses des Ursachenanalyseprozesses zum Dienstanbieter-Computer überträgt, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet.
«Aspekt 8»
Verteiltes System, umfassend ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Dienstanbieter-Computer, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet, und einen Analyse-Outsourcing-Computer, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, und der Analyse-Outsourcing-Computer: auf der Basis des Zustands des In-Edge-Controllers einen dienstbezogenen Analyseprozess durchführt, der ein Analyseprozess ist, der sich auf einen bestimmten Dienst bezieht, und die durch den dienstbezogenen Analyseprozess erhaltenen Daten nach dem dienstbezogenen Analyseprozess zum Dienstanbieter-Computer überträgt.
«Aspekt 9»
Verteiltes System gemäß Aspekt 8, wobei das Unternehmen, das einen bestimmten Dienst anbietet, ein Unternehmen ist, das nicht das Edge-Device oder Komponenten des Edge-Device entwickelt oder herstellt.
«Aspekt 10»
Verteiltes System gemäß Aspekt 8, wobei der bestimmte Dienst ein Reparaturdienst für das Edge-Device ist, der dienstbezogene Analyseprozess ein Prozess ist, der die Ursache eines bestimmten internen Zustands des In-Edge-Controllers identifiziert, und die Daten nach dem dienstbezogenen Analyseprozess ein Prozess des Generierens von Reparaturinformation sind, um die Ursache zu beheben.
«Aspekt 11»
Verteiltes System gemäß Aspekt 8, wobei der bestimmte Dienst ein Versicherungsdienst für das Edge-Device ist und die dienstbezogenen Analysedaten Information über die Häufigkeit des Auftretens eines anormalen Zustands des Edge-Device enthalten.
«Aspekt 12»
Verteiltes System, umfassend: ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Diagnosedatenmanagement-Computer, einen Analyse-Outsourcing-Computer, einen Edge-Datendistributor-Computer und einen Dienstanbieter-Computer, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, und der Diagnosedatenmanagement-Computer: Diagnosedaten empfängt, die einen Zustand im In-Edge-Controller anzeigen, die Diagnosedaten zum Edge-Datendistributor-Computer überträgt und die Diagnosedaten gemäß einem ersten Zeitplan zum Analyse-Outsourcing-Computer überträgt, der Edge-Datendistributor-Computer: die Diagnosedaten vom Diagnosedatenmanagement-Computer empfängt, die Diagnosedaten in einer Speicherressource speichert, die in der Speicherressource gespeicherten Diagnosedaten gemäß einem zweiten Zeitplan, der ein längeres Intervall als der erste Zeitplan hat, verarbeitet und die verarbeiteten Diagnosedaten zum Dienstanbieter-Computer überträgt, und der Analyse-Outsourcing-Computer: auf der Basis des Zustands des In-Edge-Controllers einen dienstbezogenen Analyseprozess durchführt, der ein Analyseprozess ist, der sich auf einen bestimmten Dienst bezieht, und die durch den dienstbezogenen Analyseprozess erhaltenen Daten nach dem dienstbezogenen Analyseprozess zum Dienstanbieter-Computer überträgt.
«Aspekt 13»
Verteiltes System gemäß Aspekt 12, wobei der Analyse-Outsourcing-Computer dem gleichen Rechenzentrum oder dem gleichen Unternehmen gehört wie der Diagnosedatenmanagement-Computer.
«Aspekt 14»
Verteiltes System, umfassend ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist, einen Diagnosedaten-Computer, und einen Hersteller-Computer, der ein Computer ist, der einem Hersteller des Edge-Device gehört, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, und der Diagnosedaten-Computer Diagnosedaten empfängt, die einen internen Zustand im In-Edge-Controller anzeigen, und die Diagnosedaten oder verarbeitete Diagnosedaten an einen anderen Computer überträgt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

JP 2010055545 A [0002, 0004]

Claims

Verteiltes System, umfassend: ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist; einen Diagnosedaten-Computer; und einen Hersteller-Computer, der ein Computer ist, der einem Hersteller des Edge-Device gehört, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, und der Diagnosedaten-Computer: Diagnosedaten empfängt, die einen internen Zustand im In-Edge-Controller anzeigen, auf der Basis der Diagnosedaten einen Ursachenanalyseprozess des Zustands im In-Edge-Controller durchführt, und die Daten nach dem Ursachenanalyseprozess oder auf der Basis des Ergebnisses des Ursachenanalyseprozesses verbesserte Daten für das Edge-Device zum Hersteller-Computer überträgt.
Verteiltes System nach Anspruch 1, wobei der Diagnosedaten-Computer eine Analyseregel speichert, die in einer Speicherressource eine kausale Beziehung des im Edge-Device auftretenden Zustands speichert, und der Diagnosedaten-Computer während des Ursachenanalyseprozesses die Analyseregel referenziert.
Verteiltes System nach Anspruch 1, wobei die verbesserten Daten Designdaten für das Edge-Device der nächsten Generation sind, wenn der Diagnosedaten-Computer verbesserte Daten zum Hersteller-Computer überträgt.
Verteiltes System nach Anspruch 1, wobei die verbesserten Daten verbesserte Daten des In-Edge-Controllers sind und der Hersteller-Computer die verbesserten Daten zum Edge-Device überträgt, wenn der Diagnosedaten-Computer verbesserte Daten zum Hersteller-Computer überträgt.
Verteiltes System nach Anspruch 4, außerdem umfassend: einen Edge-Datendistributor-Computer, der die verbesserten Daten vom Hersteller-Computer empfängt und die verbesserten Daten zum Edge-Device überträgt, wobei der Edge-Datendistributor-Computer: die Diagnosedaten vom Diagnosedaten-Computer empfängt, die Diagnosedaten in einer Speicherressource speichert, die in der Speicherressource gespeicherten Diagnosedaten gemäß einem bestimmten Zeitplan verarbeitet, und die verarbeiteten Diagnosedaten an einen Dienstanbieter-Computer überträgt, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet.
Verteiltes System nach Anspruch 1, wobei der Diagnosedaten-Computer: die Daten nach dem Ursachenanalyseprozess oder die Daten, die auf der Basis des Ergebnisses des Ursachenanalyseprozesses die Ursache einer Anomalie des Edge-Device identifizieren, an einen Dienstanbieter-Computer überträgt, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet.
Verteiltes System nach Anspruch 1, wobei der Diagnosedaten-Computer: die Daten nach dem Ursachenanalyseprozess oder die Daten, die auf der Basis des Ergebnisses des Ursachenanalyseprozesses ein Teil identifizieren, das die Ursache einer Anomalie des Edge-Device ist, und einen Austauschzeitplan für das Teil auf der Basis des Ergebnisses des Ursachenanalyseprozesses zum Dienstanbieter-Computer überträgt, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet.
Verteiltes System, umfassend: ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist; einen Dienstanbieter-Computer, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet; und einen Analyse-Outsourcing-Computer, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, und der Analyse-Outsourcing-Computer: auf der Basis des Zustands des In-Edge-Controllers einen dienstbezogenen Analyseprozess durchführt, der ein Analyseprozess ist, der sich auf einen bestimmten Dienst bezieht, und die durch den dienstbezogenen Analyseprozess erhaltenen Daten nach dem dienstbezogenen Analyseprozess zum Dienstanbieter-Computer überträgt.
Verteiltes System nach Anspruch 8, wobei das Unternehmen, das einen bestimmten Dienst anbietet, ein Unternehmen ist, das nicht das Edge-Device oder Komponenten des Edge-Device entwickelt oder herstellt.
Verteiltes System nach Anspruch 8, wobei der bestimmte Dienst ein Reparaturdienst für das Edge-Device ist, der dienstbezogene Analyseprozess ein Prozess ist, der die Ursache eines bestimmten internen Zustands des In-Edge-Controllers identifiziert, und die Daten nach dem dienstbezogenen Analyseprozess ein Prozess des Generierens von Reparaturinformation sind, um die Ursache zu beheben.
Verteiltes System nach Anspruch 8, wobei der bestimmte Dienst ein Versicherungsdienst für das Edge-Device ist, und die dienstbezogenen Analysedaten Information über die Häufigkeit des Auftretens eines anormalen Zustands des Edge-Device enthalten.
Verteiltes System, umfassend: ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist; einen Diagnosedatenmanagement-Computer; einen Analyse-Outsourcing-Computer; einen Edge-Datendistributor-Computer; und einen Dienstanbieter-Computer, der ein Computer eines Unternehmens ist, das einen bestimmten Dienst anbietet, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, und der Diagnosedatenmanagement-Computer: Diagnosedaten empfängt, die einen Zustand im In-Edge-Controller anzeigen, die Diagnosedaten zum Edge-Datendistributor-Computer überträgt, und die Diagnosedaten gemäß einem ersten Zeitplan zum Analyse-Outsourcing-Computer überträgt, der Edge-Datendistributor-Computer: die Diagnosedaten vom Diagnosedatenmanagement-Computer empfängt, die Diagnosedaten in einer Speicherressource speichert, die in der Speicherressource gespeicherten Diagnosedaten gemäß einem zweiten Zeitplan, der ein längeres Intervall hat als der erste Zeitplan, verarbeitet und die verarbeiteten Diagnosedaten zum Dienstanbieter-Computer überträgt, und der Analyse-Outsourcing-Computer: auf der Basis des Zustands des In-Edge-Controllers einen dienstbezogenen Analyseprozess durchführt, der ein Analyseprozess ist, der sich auf einen bestimmten Dienst bezieht, und die durch den dienstbezogenen Analyseprozess erhaltenen Daten nach dem dienstbezogenen Analyseprozess zum Dienstanbieter-Computer überträgt.
Verteiltes System nach Anspruch 12, wobei der Analyse-Outsourcing-Computer dem gleichen Rechenzentrum oder dem gleichen Unternehmen gehört wie der Diagnosedatenmanagement-Computer.
Verteiltes System, umfassend: ein Edge-Device, das ein bewegter Körper oder eine Ausrüstung ist, der oder die automatisch betreibbar ist; einen Diagnosedaten-Computer; und einen Hersteller-Computer, der ein Computer ist, der einem Hersteller des Edge-Device gehört, wobei das Edge-Device einen Bewegungsmechanismus oder einen Betätigungsmechanismus zum automatischen Betrieb und einen In-Edge-Controller aufweist, der den Bewegungsmechanismus oder den Betätigungsmechanismus steuert, und der Diagnosedaten-Computer Diagnosedaten empfängt, die einen internen Zustand im In-Edge-Controller anzeigen, und die Diagnosedaten oder verarbeitete Diagnosedaten an einen anderen Computer überträgt.