JP2021196678A - 分散システム - Google Patents

Abstract

【課題】エッジデバイスとエッジデバイスの外部の計算機とが連携して、エッジデバイス内のコントローラの内部状態に対処する技術を提供する。【解決手段】分散システムは、自動稼働可能な移動体又は設備であるエッジデバイスと、診断データ計算機と、を有する。そして前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は前記作動機構を制御するエッジ内コントローラと、を有する。ここで、前記診断データ計算機は：前記エッジ内コントローラ内の内部状態を示す診断データを受信する。【選択図】図１

Description

本発明は、自動稼働可能な移動体又は設備であるエッジデバイスを含む、分散システムに関する。

特許文献１には、車両（エッジデバイスの一つである）で異常が発生した際の状態データをもとに過去の不良データベースと突合せる前に異常状態で分類し、その後、その分類に関係する部分のみを不良データベースで検索、解析するシステムが開示されている。そのシステムでは、異常状態の分類を車両側で、その分類データをセンタに送信し、センタ側で詳細解析を行うことで、異常要因弁別精度を下げずに車両側の負荷を軽減することができる。

特開２０１０−５５５４５号

モータに代表される移動体における移動機構や、油圧に代表される設備における作動機構を制御するエッジデバイス内のコントローラは、自動稼働可能な移動体の実現のために複雑化することが考えられる。この場合、エッジデバイス内コントローラは様々な種類の内部状態を取り得るようになる。そして、これら内部状態（特に異常状態）の解消はエッジデバイス１２内部だけで復旧できる種類の内部状態とは限らない。

しかし、特許文献１では、ＥＣＵ（エッジデバイス内のコントローラの一つ）自体の内部状態（特に異常状態）をエッジデバイスの外部には送信していないため、エッジデバイスの外部の計算機と連携して当該内部状態に対処することはできない。

本発明の目的は、エッジデバイスとエッジデバイスの外部の計算機とが連携して、エッジデバイス内のコントローラの内部状態に対処する技術を提供することにある。

本願は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下のとおりである。

第１の視点の分散システムは、自動稼働可能な移動体又は設備であるエッジデバイスと、診断データ計算機と、エッジデバイスの製造会社が有する計算機である製造会社用計算機と、を有する。そして、エッジデバイスは、自動稼働するための移動機構又は作動機構と、移動機構又は作動機構を制御するエッジ内コントローラと、を有する。ここで、診断データ計算機は：エッジ内コントローラ内の内部状態を示す診断データを受信し、診断データに基づいて、エッジ内コントローラ内の状態の要因分析処理を行い、製造会社用計算機に、要因分析処理後のデータ、又は要因分析処理の結果に基づいたエッジデバイスの改善データを送信する。

第２の視点の分散システムは、自動稼働可能な移動体又は設備であるエッジデバイスと、所定のサービスを提供する会社の計算機であるサービス提供会社用計算機と、分析アウトソーシング計算機と、を有する。そしてエッジデバイスは、自動稼働するための移動機構又は作動機構と、移動機構又は作動機構を制御するエッジ内コントローラと、を有する。ここで、分析アウトソーシング計算機は：エッジ内コントローラの状態に基づいた、所定のサービスに関連した分析処理であるサービス関連分析処理を行い、サービス関連分析処理で得られたサービス関連分析後データを、サービス提供会社用計算機に送信する。

第３の視点の分散システムは、自動稼働可能な移動体又は設備であるエッジデバイスと、診断データ管理計算機と、分析アウトソーシング計算機と、エッジデータ配信会社用計算機と、所定のサービスを提供する会社の計算機であるサービス提供会社用計算機と、を有する。そしてエッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は作動機構を制御するエッジ内コントローラと、を有する。

ここで、診断データ管理計算機は：エッジ内コントローラ内の状態を示す診断データを受信し、診断データを、エッジデータ配信会社用計算機に送信し、第１のスケジュールにて、診断データを、分析アウトソーシング計算機に送信する。

エッジデータ配信会社用計算機は：診断データ管理計算機から、診断データを受信し、診断データを記憶リソースに格納し、第１のスケジュールよりも長いインターバルを持つ第２のスケジュールに従って、記憶リソースに格納した診断データを加工処理し、加工後の診断データを、サービス提供会社用計算機に送信する。

分析アウトソーシング計算機は：エッジ内コントローラの状態に基づいた、所定のサービスに関連した分析処理であるサービス関連分析処理を行い、サービス関連分析処理で得られたサービス関連分析後データを、サービス提供会社用計算機に送信する。

第４の視点の分散システムは、自動稼働可能な移動体又は設備であるエッジデバイスと、診断データ計算機と、エッジデバイスの製造会社が有する計算機である製造会社用計算機と、を有する。エッジデバイスは、自動稼働するための移動機構又は作動機構と、移動機構又は作動機構を制御するエッジ内コントローラと、を有する。ここで、診断データ計算機は：エッジ内コントローラ内の内部状態を示す診断データを受信し、診断データ、又は加工後の診断データを、他の計算機に送信する。

本発明によれば、エッジデバイスとエッジデバイスの外部の計算機とが連携して、エッジデバイス内のコントローラの内部状態に対処することができる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

分散システムの概要の構成例を示す図である。 エッジデバイスの構成例の概要を示す図である。 計算機のハードウェア構成の例を示す図である。 エッジデバイス製造会社計算機の構成例の概要を示す図である。 診断データクラウドの構成例を示す図である。 第１ソリューションにおける分散システムの処理の流れを示す図である。 診断モデル定義画面の例を示す図である。 第２ソリューションにおける分散システムの処理の流れを示す図である。 ディーラ又は修理会社向け要因分析結果画面の例を示す図である。 第３ソリューションにおける分散システムの処理の流れを示す図である。 レンタル会社又はＭａａＳ（Ｍｏｂｉｌｉｔｙ ａｓ ａ Ｓｅｒｖｉｃｅ）会社向け要因分析結果画面の例を示す図である。

以下の実施形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、詳細、補足説明等の関係にある。

また、以下の実施形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。

さらに、以下の実施形態において、その構成要素（要素ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。

同様に、以下の実施形態において、構成要素等の形状、位置関係等に言及するときは特に明示した場合および原理的に明らかにそうではないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数値および範囲についても同様である。

また、実施形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。以下、本発明の各実施形態について図面を用いて説明する。

以下に本実施例を説明する。なお、以下では説明の簡略化のために、クラウドサーバ（単にクラウドと略すことがある）を用いた形態で説明するが、クラウドサーバに変えて計算機であってもよい。また、計算機を用いた形態の説明であっても、クラウドに適用してもよい。なお、クラウドサーバは、少なくとも１以上の計算機より構成される。

＜システム構成＞
図１は、分散システムの概要の構成例を示す図である。分散システム１０００は、多層化されており、１つ以上のエッジデバイス１２と、データマネジメント層３０に含まれる一つ以上のクラウド又は計算機と、データ活用層３１に含まれる一つ以上のクラウド又は計算機と、を含む。

エッジデバイス１２は、例えば自動稼働可能な移動体（例えば車両、ドローン、ロボット）や、設備（例えばロボットアームや工作機械、数値制御旋盤等）であることが考えられる。なお、自動運転は「自動稼働」であることの一例である。

エッジデバイス１２は、移動機構（移動体の場合、例えばエンジン、モータ）又は作動機構（設備の場合、例えばモータや油圧等のアクチュエータ）１７と、移動機構又は作動機構１７を制御するエッジ内コントローラ（例えばＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１０と、センサ（例えばＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ）１８を有する。なお、これら構成物の他の具体例は後ほど説明する。なお、「作動」とは、少なくとも、「ある動作を行うことによって、機器がその操作された指令どおりの状態の変化を行うこと（ＪＩＳ Ｂ ０１３２準拠）。」を意味する。なお、以後の説明では、説明の簡略化としてエッジデバイス１２が移動体の場合を代表して説明する。よって、移動機構又は作動機構１７の説明では、移動機構の場合を代表して説明する。

なお、エッジ内コントローラ１０はＥＣＴＬ（Ｅｄｇｅ ＣｏｎＴｒｏＬｅｒ）と略して称呼する場合がある。また、エッジデバイス１２の自動稼働を実現するための処理の少なくとも一部を、エッジ内コントローラ１０が担当している。そのため、エッジ内コントローラ１０は、ハードウェア又はソフトウェアの視点で複雑化しつつある。例えば、ハードウェアの複雑化の例としては、機械学習処理導入や各種センサやカメラからのデータ入力をリアルタイムに認知、判断する処理導入のために、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、ニューラルネットワーク専用プロセッサや、その他機械学習を加速させるハードウェアが含まれる場合もある。

＜＜データマネジメント層＞＞
データマネジメント層３０は、説明を容易にするために導入した仮想的な層又はグループである。当該層に含まれるクラウドは、後ほど説明するデータ活用層３１よりもエッジデバイス１２が生成したデータの格納を実施するクラウドが含まれる。

なお、前述の説明に適合しないクラウドがデータマネジメント層３０に含まれてもよく、前述の説明に適合するクラウドが当該層から除かれていてもよい。図１では、当該層に含まれるクラウド又は計算機（以後、これらをデータマネジメント層クラウドと呼ぶことがある）の例として、下記を示した。

エッジデータ配信会社クラウド２４：当該クラウドは、エッジデバイス１２に関するデータ（以後エッジデータと呼ぶ）を格納し、他のクラウドからのリクエストに応じて無加工又は加工後のエッジデータを当該クラウドに送信する。エッジデータの一例としては、エッジデバイス１２のセンサ１８のセンサデータＤ１２の他、エッジデバイス１２の構成情報等が考えられる。なお、本実施例のデータの加工の一例は、データの表現形式の変更、差分値の計算、統計値の計算、暗号化、復号化、圧縮、非圧縮、不要なデータの除去、冗長コードの付与や除去、データ抽出であるが、処理主体が受信したデータを一部又は全てを変更して送信するのであれば、それを加工とみなしてもよい。なお、本明細書では当該加工処理後のデータを単に「加工後データ」と呼ぶことがある。

診断データ管理クラウド２６：当該クラウドは、エッジ内コントローラ１０の内部状態を示し、当該コントローラ外部から診断するための診断データ（以後、エッジ内コントローラ診断データ、ＥＣＴＬ診断データと称呼する場合がある）を格納し、他のクラウドからのリクエストに応じて無加工又は加工後のエッジデータを送信する。なお、ＥＣＴＬ診断データはエッジデータの一例である。

エッジデバイス製造会社計算機（以後、エッジデバイス製造会社用計算機、又は製造会社用計算機と呼ぶ場合がある）２１：当該計算機は、エッジデバイス１２を設計又は製造する会社が有する計算機である。当該製造会社は自社製品の開発や保守のためにエッジデータを格納するため、本実施例では便宜上データマネジメント層に含めた。

以上が、データマネジメント層３０に含まれるクラウドである。なお、一視点として、データマネジメント層３０のクラウド又は計算機を有する会社（以後、単にデータマネジメント層に含まれる会社と記す場合がある）は、エッジデバイス（それ自体又は構成物を含む）の設計又は製造を行う会社、又はエッジデータの配信を担当する会社である、と考えてもよい。当該視点からみると、通信会社や、スマートフォンにて実行されるカーナビゲーションプログラムを提供する会社や、移動機構の製造会社のクラウドは、データマネジメント層に含まれるとみなしてもよい。

＜＜データ活用層＞＞
データ活用層３１は、説明を容易にするために導入した仮想的な層又はグループである。当該層には、複数のクラウド又は計算機（以後、これらをデータ活用層クラウド、あるいはサービス提供会社用計算機と呼ぶことがある）が含まれる。データ活用層クラウドは、データマネジメント層クラウドと比較して、サービス提供により近い部分を担う会社のクラウドが含まれる。

ここで、データ活用層クラウドにおいて提供されるサービスとして好適なサービスは、エッジデバイス１２を利用したり、エッジデバイス１２に関連するエンティティを対象としたり、又はエッジデバイス１２そのものを対象とする、エッジデバイス関連サービスである。なお、エンティティの一例は、人間の集合（含む人間、会社等の人間の集団）、動物、装置（信号機、エッジデバイス１２を運搬する船、その他エッジデバイス１２の外部で、エッジデバイス１２の自動稼働を支援する装置が例）である。また、別視点では、データ活用層に含まれるクラウドを有する会社（以後、単にデータ活用層に含まれる会社、あるいはサービス提供会社と称呼する場合がある）は、エッジデバイス１２自体又はその構成物の設計又は製造をしない会社（設計データ１３を保有しない会社）である、と考えてもよい。図１では、データ活用層クラウドの例として下記を示した。

運輸会社クラウド：当該クラウドは、エッジデバイス１２を直接的に利用するか、あるいは他の運輸会社のサービスを用いて運輸業を営む会社のクラウドである。当該クラウドで行われる処理は、エッジデータまたは分析アウトソーシングクラウド２７から提供される分析後データを受け取り、運輸サービスを提供するための処理である。当該処理の一例は、エッジデバイスの配車計画や、運賃の計算、運賃を含むサービス仕様改訂のための分析処理、である。なお、本明細書では分析処理後のデータを単に「分析後データ」と呼ぶことがある。

保険会社クラウド２９：保険会社は、エッジデバイス１２を利用して所定の機能を発揮する会社の業務に関係する所定のリスクを引き受ける。保険会社は、エッジデータまたは分析アウトソーシングクラウド２７による分析後データを参照して保険料率を決定するための一部又はすべての処理を保険会社クラウド２９で行う。なお、保険会社が引き受けるリスクは、エッジデバイス１２を利用するエンティティに関係するリスクであってもよい。例えば、個人が契約する自動車保険である。

ディーラ又は修理会社クラウド２８：ディーラ又は修理会社は、エッジデバイス１２の修理や保守の手配、、エッジデバイス１２の修理を行う。そうした業務の支援のために、、当該クラウドではエッジデータまたは分析アウトソーシングクラウド２７から提供される分析後データを受け取り、保守サービス（予防や改修）、あるいは修理サービス（事故対応）に必要な情報を生成し、手配者や修理者に表示する。

レンタル会社又はＭａａＳ会社クラウド２２：これら会社に共通するのは、エッジデバイス１２を直接的に利用するか、あるいは他の旅客会社のサービスを用いて移動手段の提供サービスを営む会社であることである。このようなサービスを支援するために、レンタル会社又はＭａａＳ会社クラウド２２は、エッジデータまたは分析アウトソーシングクラウド２７から提供される分析後データを受け取り、保有車両の保守計画等に必要な情報を生成する。当該情報は、同社社員や同社の利用者に表示される。

分析アウトソーシングクラウド２７：分析アウトソーシングクラウド２７は、データ活用層３１に含まれる会社の、サービス提供又は改善に必要なデータ分析（以降、サービス関連分析処理と称呼することがある。）のアウトソーシング先となるクラウドである。本実施例では、エッジデータ（特にＥＣＴＬ診断データ）の分析のアウトソーシングを担当する場合について説明をしているが、本クラウドは、エッジデバイス製造会社等、データマネジメント層３０に含まれるクラウド又は会社の分析アウトソーシングを担当してもよい。なお、後ほど説明する各ソリューションでは、サービス関連分析処理は、エッジデバイス１２又はエッジ内コントローラ１０の内部状態に関する要因分析処理である。

また、データマネジメント層３０とデータ活用層３１の分け方はこれら以外でもよく、さらに排他的でなくてもよい。例えば、通信会社は前述の定義ではエッジデータの配信に関する視点ではエッジデータ配信会社クラウド２４に相当し、データマネジメント層３０に含まれるが、エッジデバイス１２に「通信サービス」を提供する視点ではデータ活用層３１に含まれるとも考えられる。

＜＜エッジ内コントローラの診断データを活用するメリットとデータの流れ＞＞
本実施例における分散システム１０００の特徴は、エッジ内コントローラ１０の内部状態（例えば異常状態(以後、単に「異常」と呼ぶことがある)）が分かる診断データをエッジデバイス１２の外部で活用することで、分散システム全体として対処（予防、保守、復旧、改善等の各種考慮を含む）することにある。その動機は次に説明する通りである。

今後のエッジ内コントローラ１０は、自動稼働可能な移動体の実現のために複雑化することが考えられる。この場合、エッジ内コントローラ１０は様々な種類の内部状態を取り得るようになる。そして、これら内部状態（特に異常状態）の解消はエッジデバイス１２内部だけで復旧できる種類の内部状態とは限らない。そこで、出願人は、エッジ内コントローラ１０の内部状態が分かる診断データを、エッジデバイス１２外部にて活用することで、分散システム１０００全体として各種の内部状態に対処することを考えた。

データの流れは追って説明するが、分散システム１０００は、より具体的には下記に示すメリットを生じさせる。

エッジデバイス製造会社の場合：当該会社は、エッジデバイス１２が自動稼働で複雑化したため、エッジデバイス１２の状態分析の負荷が非常に高くなるおそれがある。分散システム１０００を適用することによって、エッジデバイス１２の製造会社によるエッジ内コントローラ１０の内部状態分析負荷を軽減することができる。特に、エッジ内コントローラ１０の製造会社と同じ会社又は関係する会社が診断データ管理クラウド２６又は分析アウトソーシングクラウド２７を有している場合には、この効果はより顕著となる。より詳しい知識で要因分析が可能となるからである。

保険会社の場合：エッジデバイス１２の種類ごとの故障の頻度や傾向を、保険料率や保険金支払い条件の改善に用いることができる。

運輸会社、レンタル会社、又はＭａａＳ会社の場合：エッジ内コントローラ１０の異常によるサービス提供クオリティの低下を軽減することができる。例えば、エッジ内コントローラ１０が異常を生じさせないように、エッジデバイス１２（又はエッジ内コントローラ１０）の種類とエッジデバイス１２の利用環境をマッチングさせて、効率的にエッジデバイス１２の運用が可能となる。例えば、ある種類のエッジデバイス１２が低価格又は高速移動可能だが、特定の利用環境ではエッジデバイス１２（又はエッジ内コントローラ１０）の異常が生じやすいことが分析で判明したとする。そうすれば当該種類のエッジデバイス１２の利用環境を特定の利用環境により遠い環境で利用できるようにエッジデバイス１２の利用計画を変更することが考えられる。

ディーラ又は修理会社の場合：異常発生時に使用者は迅速にエッジデバイス１２を交換し、原因の究明や製品の修理および交換箇所の特定を迅速に行えるようになる。

政府の場合：事故が発生した場合に、ＥＣＴＬ診断データを含めて分析が可能となる。

分析アウトソーシング会社の場合：ＥＣＴＬ診断データの受信前に、すでに所定の分析サービスを提供している場合、分析対象となるデータが拡大されるため、より広範囲又は高精度な分析をサービスとして提供できるようになる。

＜＜＜データ活用層へのシンプルなデータの流れ＞＞＞
上記メリットを享受するためのシンプルなデータの流れは、ＥＣＴＬ診断データＤ１１が示すように、ＥＣＴＬ診断データをエッジデバイス１２が外部に送信することから始まる。図１ではその一例として、データマネジメント層クラウド、特に診断データ管理クラウド２６が、ＥＣＴＬ診断データを受信及び記憶リソースへ格納している場合を図示している。その後、ＥＣＴＬ診断データを受信したクラウドが、ＥＣＴＬ診断データを各会社のクラウドに送信してしまえば、各会社はＥＣＴＬ診断データを利用することができる。

なお、診断データ管理クラウド２６においてデータの加工処理を行い、処理後のデータを各会社のクラウドへ送信するようにしてもよい。

なお、前述の診断データ管理クラウド２６による、ＥＣＴＬ診断データの加工処理、又は他のクラウドへのデータ送信処理に関して、すべて又は一部をエッジデータ配信会社クラウド２４にオフロードしてもよい。この場合、データＤ２１が示すように、診断データ管理クラウド２６が、エッジデータ配信会社クラウド２４に、ＥＣＴＬ診断データ自体、または診断データ管理クラウド２６にて担当する範囲の加工後のＥＣＴＬ診断データを送信する。

なお、加工処理の例はすでに説明した通りだがさらに、個人情報の匿名化や、ＥＣＴＬ診断データの簡素化・抽象化が考えられる。

エッジデータ配信会社クラウド２４がエッジデータを集約後にデータ活用層３１のクラウドに提供している場合、ＥＣＴＬ診断データの配信をエッジデータ配信会社クラウド２４に担当させると、例えば下記のメリットが生じる。

データ活用層３１のエッジデータ配信会社クラウド２４がすでに有するクラウドリソース（後述）を活用できるため、診断データ管理クラウド２６のクラウドリソースが少なくて済む。

また、データ活用層３１に含まれるクラウドは、エッジデータ配信会社クラウド２４からデータを受信することで、エッジデバイス１２のセンサデータとＥＣＴＬ診断データの両方を得ることができる。

なお、ＥＣＴＬ診断データは、データマネジメント層３０に含まれる他のクラウドがエッジデバイス１２から受信するようにしてもよい。また、ＥＣＴＬ診断データは、データ活用層３１に含まれるクラウドがエッジデバイス１２から受信するようにしてもよい。

＜＜＜診断データ管理クラウドの強化を重要視する場合のデータの流れ＞＞＞
仮に、診断データ管理クラウド２６の加工処理を繰り返し強化し、強化された加工処理後のデータを他の装置に送信できるようにしたとする。しかし、こうした加工後データは、エッジデータ配信会社クラウド２４側で受信、記憶リソースへの格納、及びデータ活用層クラウドへの送信を可能とするプログラム修正をしない限り、データ活用層クラウドに送信できない。このような状況を回避するために、診断データ管理クラウド２６は、加工後データを、エッジデータ配信会社クラウド２４を介さずに、データ活用層クラウドに送信するようにしてもよい。当該送信を実現するに当り、例えば以下の方法又は構成が考えられる。

（連携）分析アウトソーシングクラウド２７を有する分析アウトソーシング会社が、診断データ管理クラウド２６を有する会社と契約を結び、整形データを受信するインターフェース仕様と利用権を取得する。分析アウトソーシング会社は、自社の分析アウトソーシングクラウド２７にインターフェース仕様に沿ったプログラム修正を行うことで、利用権を得た加工後のデータを得ることができる。図１のデータＤ２６（以後、連携データ又は診断データクラウド内連携データと呼ぶことがある）は、当該強化された加工処理がされた後のデータ（加工後データ）を示している。

なお、当該インターフェース仕様と利用権は契約以外で得てもよい。例えば、分析アウトソーシングクラウド２７と、診断データ管理クラウド２６とを、同じ会社又は資本関係を有する会社により運営し、インターフェース仕様と利用権を確保してもよい。

（統合）診断データ管理クラウド２６が、分析アウトソーシングクラウド２７を兼ねる。当該統合には、両クラウドを実現する計算機が同じデータセンタに配置されていもよく、共通の計算機に両クラウドで実行するプログラム及びデータをまとめて配置してもよい。または、同じ計算機に割り当てされた複数の仮想計算機の少なくとも一つを診断データ管理クラウド２６用途に用い、他の少なくとも１つを分析アウトソーシングクラウド２７用途に用いてもよい。別な視点でいえば、「診断データ管理クラウド２６が、分析アウトソーシングクラウド２７を兼ねる」とは、あるデータセンタのリソース（例えば後術する、プロセッサ、記憶リソース、通信装置、ネットワーク、リソースを管理する管理ソフト）を両クラウドでシェアする、という意味でとらえてもよい。

以上が、連携と統合の例である。このような連携又は統合をした場合、分析アウトソーシングクラウド２７は、エッジデータ配信会社クラウド２４から送信されない加工後データをデータ活用層クラウドに提供できるため、より広範囲又は高精度な分析をサービスとして提供できる。また、データ活用層クラウドへの送信スケジュール等を分析アウトソーシングクラウド２７又は診断データ管理クラウドにてアレンジできるため、リアルタイムでの分析結果の提供を行うことが可能となる。リアルタイム提供のため、当該送信スケジュールは、例えばエッジデータ配信会社クラウドのエッジデータ送受信スケジュールよりも短いインターバルを有してもよい。

なお、以後の説明では、診断データ管理クラウド２６と、分析アウトソーシングクラウド２７との集合体を診断データクラウド３２と呼ぶことがある。分析アウトソーシングクラウド２７を兼ねた診断データ管理クラウド２６も、診断データクラウド３２に含まれる。

＜＜診断データ管理クラウドと分析アウトソーシングクラウドの追加役割＞＞
診断データ管理クラウド２６と、分析アウトソーシングクラウド２７とは、上述したもの以外の役割または処理を行うものであってもよい。例えば、診断データ管理クラウド２６がエッジ内コントローラ１０の設計又は製造会社により運営されるものである場合、当該診断データ管理クラウド２６でエッジ内コントローラ１０の設計又は製造を管理することも可能である。また、当該診断データ管理クラウド２６に格納したＥＣＴＬ診断データを分析し、エッジ内コントローラ１０の改善を行うものであってもよい。

さらには、分析アウトソーシングクラウド２７が、エッジデバイス１２自体又はその構成物の設計又は製造をする会社であってもよい。この場合、エッジ内コントローラ１０の設計知識や製造知識が、分析アウトソーシングクラウド２７を除いたデータ活用層３１に含まれる他の会社に不必要に拡散することを防ぎやすくなる。

＜＜クラウド間のデータの流れ＞＞
一部は説明済であるが、図１に示す分散システム１０００は、以下に示すデータの流れを有する。図中の矢印が出始めているクラウド又は計算機がデータを送信するエンティティであり、矢印が向けられたクラウド又は計算機がデータを受信するエンティティである。なお、データフローＤ１１〜Ｄ３３について、流れを強調したい場合は「矢印」Ｄ１１〜Ｄ３３」と表現し、流れているデータの内容に注目する場合は「データ」Ｄ１１〜Ｄ３３と表現していることがある。なお、「データ」Ｄ１１〜Ｄ３３の内容を複数列挙している場合は、必ずしも同時に列挙した内容を送信していることを指しているわけではない。送信タイミングは異なっていてもよく、一部の内容の送信を省略してもよい。
データフロー（またはデータ）Ｄ１１：ＥＣＴＬ診断データ。
データフロー（またはデータ）Ｄ１２：センサデータ。なお、図示は省略したが、センサデータは、エッジ内コントローラ１０が受信してもよい。
データフロー（またはデータ）Ｄ２１、Ｄ２７：ＥＣＴＬ診断データ。なお、本データの流れでは加工後のＥＣＴＬ診断データが流れてもよい。

データフロー（またはデータ）Ｄ２２：要因分析処理後のデータ、又は要因分析結果に基づいたエッジデバイスの改善データ。改善データには、例えば、改善版のコントローラ設計データ、プログラム、診断シーケンス、又は熱設計データがある。なお、データＤ２２の一部は診断データ管理クラウド２６が送信元であってもよい。
データフロー（またはデータ）Ｄ２３：エッジデバイス１２の仕様、マニュアル、構成に関するデータ。また、エッジデバイス１２にて実行されるプログラム（例えば、カーナビゲーションシステムのプログラム、音声認識プログラム、エッジ内コントローラ１０のプログラム等）や、当該プログラムが参照するパラメータ。なお、当該データＤ２３で、エッジデバイス１２で実行されるプログラム自体や、パラメータ自体が含まれてもよい。

データフロー（またはデータ）Ｄ２４：データフローＤ２３として送信されたデータと同様。Ｄ２３として送信されたデータ自体でもよく、加工後（例えば暗号化後又は圧縮後）のデータでもよい。なお、データフローＤ２４はエッジデバイス１２自体又はエッジデバイス１２のエッジ内コントローラ以外の構成物が受信してもよい。
データフロー（またはデータ）Ｄ２５：エッジデータ。なお、これまで説明したエッジデータは動的に値が変化するデータを主に説明してきた。しかし、エッジデバイス１２の仕様、マニュアルといった静的なデータもエッジデバイス１２に関連するデータであり、エッジデータに含めてもよい。このエッジデータは、エッジデータ配信会社クラウド２４から、データ活用層３１のクラウドに送信される。なお、本データはエッジデータ配信会社クラウド２４から、データマネジメント層３０のクラウドに送信されてもよい。

データフロー（またはデータ）Ｄ２６：診断データクラウド内連携データ。
データフロー（またはデータ）Ｄ３１、Ｄ３２：分析後データ。分析アウトソーシングクラウド２７が分析処理を行った結果、例えば故障個所と交換すべきデバイスの紐づけ等の修理情報や、エッジデバイス１２ごとの劣化度合い、保守期限等のエッジデバイス１２に関連する保守情報を含む。本データは、データ活用層３１に含まれる会社の、サービス提供又は改善に用いるデータである。

データフロー（またはデータ）Ｄ３３：サービス関連データ。サービスを提供するデータ活用層３１のクラウド又は計算機から、同じくデータ活用層３１の他の会社のクラウド又は計算機に送信するデータである。例えば、サービス仕様(保険料率や運賃、各種料金等を含めてもよい)、サービス提供結果の他、サービス仕様の改善提案がある。

＜＜その他の各クラウドの説明＞＞
一部説明済であるが、以下の通りである。
エッジデータ配信会社クラウド：前述のエッジデータＤ２５を、データ活用層クラウドに配信するクラウドである。なお、当該クラウドはいずれかのクラウドで分析処理して生成された分析後データを配信してもよい。また、エッジデータ配信会社クラウド２４は、前述のデータＤ２４を送信する。エッジデータ配信会社クラウド２４は、エッジデバイス製造会社（複数社も可）、診断データ管理クラウドの会社（複数社も可）、データ活用層に含まれる会社（複数社も可）と、が有するクラウドと通信する、共通のプラットフォームとして考えてもよい。こうした場合、データの送受信を行うために、他の会社と比較してより多くのクラウドリソース（主として、通信の帯域や演算処理能力）を有してもよい。さらに、多くの会社のクラウド又は計算機に加えて多数存在するエッジデバイス１２とデータの送受信を行う際にクラウドリソースのボトルネックとなる事態を回避するため、エッジデータ配信会社クラウド２４は、事前に定めたスケジュールに基づいてデータの送受信を行ってもよい。

＜エッジデバイス＞
図２は、エッジデバイスの構成例の概要を示す図である。エッジデバイス１２は、下記の構成を含む（なお、すでに説明済の項目は省略した）。
移動機構又は作動機構１７：代表して移動機構で説明する。移動機構１７の例としては、ホイール、車輪、シャフト、ベルト、ギヤといった力の伝達構造の他、モータや油圧等のアクチュエータ、ブレーキ、モータといった力を発生させたり抑制する構成物、等が考えられるが、他の機構であってもよい。

エッジデバイス１２の移動機構１７を制御するエッジ内コントローラ１０：当該コントローラの例としては、車両のＥＣＵ、ドローンのコントローラ、産業分野のＰＬＣ、工作機械のＮＣコントローラ、がある。なお、エッジデバイス１２は複数のエッジ内コントローラ１０を有してもよい。

なお、エッジデバイス１２が車両であり、エッジ内コントローラ１０がＥＣＵである場合、エッジデバイス１２には複数のエッジ内コントローラ１０が含まれ、各エッジ内コントローラ１０毎に異なる制御役割(車線維持、車間距離制御、エンジンの回転数制御、エッジデバイス１２外部との通信制御)を持たせてもよい。なお、複数の制御的役割を共通のエッジ内コントローラ１０が持ってもよい。なお、自動車業界ではこのような制御役割は「機能」や「システム機能」と呼ぶことがある。また、このような制御役割の持たせ方はエッジ内コントローラ１０がＥＣＵ以外の場合に適用してもよい。

エッジ内コントローラ１０を構成するハードウェアは、例えば、ＣＰＵ（Ｃｎｅｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＧＰＵ、データ処理用のＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、バス、センサが考えられるが、全てを必要とはしない。エッジ内コントローラ１０の論理的な構成について図２を用いて説明する。エッジ内コントローラ１０は１以上の制御役割を持ち、そして各制御役割毎に、状態データ診断部１１０と、図示を省略した制御処理部と、を含む。

エッジ内コントローラ１０の制御処理部は、制御役割を実現するために必要な制御処理を行う。制御処理部は、エッジ内コントローラを構成するハードウェアで、プログラム（以後、制御プログラムと呼ぶことがある）を実行することで、実現される。なお、制御プログラムは、エッジ内コントローラ１０が受信したデータＤ２４（アップデートデータ）によって、インストール、アップデート、又はパラメータの更新がされてもよい。なお、一例であるが、制御役割が速度維持である場合、制御プログラムは、センサ１８の一つである速度計が計測した速度（センサデータの１つ）と指定速度とを比較しつつ、エンジンスロットルの開閉指示やモータへの加減速指示を送信する処理を実行させるプログラムである。

状態データ診断部１１０は、診断シーケンス格納部１１１に格納された診断シーケンスをにしたがって、エッジデバイス１２を構成するハードウェアの状態（エッジ内コントローラ１０の内部状態の一つである）を示す情報を取得し、データＤ１１（ＥＣＴＬ診断データ）を生成する。また、状態データ診断部１１０は、制御処理部（より具体的には制御プログラム）を監視することで、制御処理部の状態を示す情報を取得し、前述のエッジ内コントローラを構成するハードウェアの状態を示す情報と同様に取り扱ってもよい。

なお、診断シーケンスは、状態データ診断部１１０において外部より指定した順序にて上記状態を示す情報を取得するための定義情報である。診断シーケンスのより具体的な内容は、後ほど示される。

なお、エッジデバイス１２はその他にも、その構成物として、エッジデバイス１２の状態を測定するセンサ１８を有してもよい。なお、当該センサ１８の一例としては、ＧＰＳ、燃料系、速度計、回転計（モータ、エンジン、ホイールが対象）、距離計（例えばＬｉＤＡＲ（Ｌｉｇｈｔ Ｄｅｔｅｃｔｉｏｎ Ａｎｄ Ｒａｎｇｉｎｇ）や超音波を用いた距離計）、位置又は変位センサ、角度検出センサ、といったデバイスが考えられる。これらセンサ１８とエッジ内コントローラ１０により生成されたデータ（以後、エッジ生成データと呼ぶことがある）は、データマネジメント層３０のクラウド（診断データ管理クラウド２６）又はエッジ内コントローラ１０に送信される。なお、エッジデバイス１２から外部への通信は典型的にはワイヤレス通信モジュール（例えばＷｉ−Ｆｉ（登録商標）モジュールや５Ｇ通信モジュール）で実現されるが、ワイヤレス通信モジュールは、必ずしもエッジデバイス１２の各構成物が持つ必要はない。代わりに、エッジデバイス１２がワイヤレス通信モジュールを有するゲートウェイ装置（例えば、ＥＣＵ、スマートフォン、ワイヤレスルータ）を含み、ゲートウェイ装置に外部との通信処理を集約させてもよい。

エッジデバイス１２は、同一会社が製造したデバイスに限られず、多世代・多品種のデバイスが含まれる。さらには、移動体と設備のいずれかに限られず、両方を兼ねるものであってもよい。

＜クラウド又は計算機のハードウェア構成＞
図３は、各クラウドを構成する計算機４００のハードウェア構成の例を示す図である。なお、計算機は装置の一つであるので計算機装置と呼んでもよい。

計算機４００は、ＣＰＵ等のプロセッサ４０１と、主記憶装置であるメモリ４０２と、ハードディスクやＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の外部記憶装置４０３と、スピーカー等の音声出力装置４０４と、カメラ、視線入力装置、マイクロフォン等の生体情報入力装置４０５と、キーボード、マウス、タッチパネル等の入力装置４０６と、ディスプレイ、プリンタ等の出力装置４０７と、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等の通信装置４０８と、これらをつなぐバスと、を含んで構成される。なお、これらすべての構成物が必須ではない。

メモリ４０２は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などのメモリである。

外部記憶装置４０３は、デジタル情報を記憶可能な、いわゆるハードディスクやＳＳＤ、あるいはフラッシュメモリなどの不揮発性記憶装置である。

通信装置４０８は、ネットワークケーブルを介して有線通信を行う有線の通信装置、又はアンテナを介して無線通信を行う無線通信装置である。通信装置４０８は、同一のネットワークに接続される他の装置との通信を行う。その通信には、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）によるパケット通信を採用するが、これに限られるものではなく、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）等の他のプロトコルによる通信を採用してもよい。

また、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等に通信可能に接続する通信部（図示しない）は、通信装置４０８により実現される。

以上が、本実施形態における各クラウドを構成する計算機４００ハードウェア構成例である。しかし、計算機４００の構成はこれに限らず、その他のハードウェアを用いて構成されるものであってもよい。また、計算機４００は、サーバコンピュータ、パーソナルコンピュータ、ノート型のパーソナルコンピュータ、タブレット装置や、スマートフォン、テレビジョン装置等の、各種の情報処理装置であってもよい。

なお、計算機４００は、図示しないが、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ミドルウェア、アプリケーションなどの公知のプログラムを有してもよい。こうしたプログラムは、他のプログラムと同様にプロセッサ４０１にて実行されることで、所定の処理を計算機４００に行わせる。また、本明細書の各クラウドにて「部」という名前で説明した構成物は、記憶リソースの領域であることを明記したものを除いて、前述のプログラムにて実現してもよい。また、プロセッサ４０１は、ＣＰＵに限られず、他のプロセッサ、例えばＧＰＵ、ＦＰＧＡにより実現されてもよい。

また、メモリ４０２と外部記憶装置４０３については、仮想化等の技術により機能的な境界があいまいになってきていることから、記憶リソースとして利用できるものであれば厳密な区別を要しない。さらには、プロセッサと記憶リソース、および通信装置４０８を含める概念として、クラウドリソースと呼ぶことがある。なお、クラウドをデータセンター全体とみなすこともできる。こうしたみなし方の場合は、クラウドリソースに、ネットワークスイッチ、ルータ、データセンタの電源、冷却設備もクラウドリソースの一部としてみよい。また、計算機４００は仮想マシン等、物理的な計算機４００のハードウェアを仮想化した仮想的な存在でもよい。

なお、Ｗｅｂ等、サーバ用途の計算機では、入力装置や出力装置が省略されることがある。この場合は、サーバ計算機に接続する別なクライアント用途の計算機（クライアント計算機）が備える入力装置の入力をサーバー用途の計算機が通信装置４０８を用いて入力データとして受信することで代替する。同様に、サーバ用途の計算機が出力対象のデータを通信装置４０８を用いてクライアント計算機に送信し、クライアント計算機の出力装置に当該出力データを用いて出力する。入力装置及び出力装置の有無にかかわらず、共通する点は、サーバ用途の計算機で実行されるプログラムによって、入力データが受信され、出力処理が行われることである。なお、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とＪａｖａＳｃｒｉｐｔを用いたＷｅｂアプリケーションにおいては、Ｗｅｂブラウザを実行するクライアント計算機にてＨＴＭＬやＪａｖａＳｃｒｉｐｔを実行することで出力装置に表示するテキストを生成する。この場合、「出力処理」は、Ｗｅｂサーバ用途の計算機で実行されるＷｅｂサーバプログラムによるＨＴＭＬデータやＪａｖａＳｃｒｉｐｔデータの送信処理も含むものとする。

以上が、クラウドを構成する計算機のハードウェア構成例である。データマネジメント層３０に属するクラウドである、診断データ管理クラウド、エッジデバイス製造会社計算機２１、及びエッジデータ配信会社クラウド２４と、データ活用層３１に属するクラウドであるレンタル会社又はＭａａＳ会社クラウド２２、運輸会社クラウド、保険会社クラウド２９、及びディーラ又は修理会社クラウド２８と、分析アウトソーシングクラウドと、は計算機４００と同様のハードウェア構成を備える。

＜エッジデバイス製造会社計算機の構成＞
図４は、エッジデバイス製造会社計算機の構成例の概要を示す図である。エッジデバイス製造会社計算機（製造会社用計算機）２１は、少なくとも設計データ１３を記憶リソースに格納している。エッジデバイス製造会社計算機２１は、製品設計や製造の処理において設計データ１３を読み込んで処理を行う。そのため、図示は省略したが、製造会社用計算機２１は、ＣＡＤ（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ Ｄｅｓｉｇｎ）プログラム、ＣＡＥ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｅｎｇｉｎｅｅｒｉｎｇ）プログラム、製造管理プログラム、といったエッジデバイス１２の設計または製造を支援するプログラムを実行してもよい。

＜診断データ管理クラウドの構成＞
各サービス提供業態ごとのソリューションについて説明する前に、共通する診断データ管理クラウドの論理的構成を説明する。診断データ管理クラウド２６は、前述の計算機４００を用いて、図１等で説明した、エッジ内コントローラ１０からデータＤ１１（ＥＴＣＬ診断データ）と、センサ１８からデータＤ１２（センサデータ）と、データＤ２６とを受信する。同様に、診断データ管理クラウド２６は、図１等で説明した、データＤ２１、データＤ２６、データＤ２７を送信する。これら送受信処理は、診断データ管理クラウド２６を構成する計算機４００の記憶リソースに格納されたプログラム（以後、診断データ管理プログラムと呼ぶことがある）をプロセッサで実行することで行われる。

また、診断データ管理プログラムは、データＤ１１（ＥＣＴＬ診断データ）及びデータＤ１２（センサデータ）とを記憶リソースに格納することで、好適なタイミングでこれらデータを各クラウドに送信することができる。なお、診断データ管理プログラムは、これらデータの送信又は受信タイミングを所定のスケジュールに基づいて行ってもよく、オンデマンドで行ってもよい。

＜分析アウトソーシングクラウドの構成＞
各サービス提供業態ごとのソリューションについて説明する前に、共通する診断データ管理クラウドの論理的構成を説明する。分析アウトソーシングクラウド２７は、前述の計算機４００を用いて、図１等で説明した、データＤ２５（エッジデータ）、データＤ２６を受信する。同様に、分析アウトソーシングクラウド２７は、図１等で説明した、データＤ３１及びＤ３２（分析後データ）、データＤ２２、データＤ２６を送信する。これら送受信処理は、分析アウトソーシングクラウド２７を構成する計算機４００の記憶リソースに格納されたプログラム（以後、分析アウトソーシングプログラムと呼ぶことがある）をプロセッサで実行することで行われる。また、分析アウトソーシングプログラムは、受信したデータＤ２５（エッジデータ）及びＤ２６を記憶リソースに格納し、分析処理に備える。

なお、分析アウトソーシングプログラムによる分析処理の目的はこれまで説明した（または以後も説明する）通りであるが、その実現にあたっては、例えば下記の処理を行ってもよい。
＊アウトソーシング元のクラウドからの分析に必要なデータ（以後、分析前提データと呼ぶ）の受信及び格納処理。ここで、分析前提データは、通信装置を介して受信する。また、受信した分析前提データは記憶リソースに格納される。
＊統計処理又は機械学習処理（例えばＳＶＭ（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）やニューラルネットワーク）による異常発生傾向の把握。当該処理に用いるデータはデータＤ２５（エッジデータ）及びＤ２６の他、分析前提データを用いてもよい。
＊異常要因又は影響範囲分析処理。エッジデバイス１２の構成情報、及び異常状態の因果関係情報（後術する第１ソリューションの分析ルールが一例）に基づいて、所定の異常の要因となった構成物や、所定の異常が影響を及ぼす構成物を、特定（または候補の特定）する。なお、前述の構成情報や関係情報には、エッジデバイス１２の構成物のさらに内部の構成情報や関係情報を含めてもよい。また、エッジデバイス１２の外部（例えば前述のエッジデバイス１２の自動稼働を支援する装置）の構成情報や関係情報を考慮してもよい。当該処理に用いるデータはデータＤ２５（エッジデータ）及びＤ２６の他、分析前提データを用いてもよい。
＊ＦＴＡ（Ｆａｕｌｔ Ｔｒｅｅ Ａｎａｌｙｓｉｓ）解析処理。

なお、図１の通り、共通の分析アウトソーシングプログラムが複数の異なる種類のサービス提供会社にデータＤ３２とデータＤ３１（分析後データ）を送ってもよく、特定のサービスに対してカスタマイズした分析アウトソーシングプログラムを用意してもよい。また、複数サービスであっても共通する分析がある場合は、第１サービスの分析処理で生成した分析後データ又は分析処理中の中間データを、第２サービスの分析処理で用いてもよい。ここで、第１と第２のサービスは同じ種類のサービスでもよく、異なる種類のサービスでもよい。

以後、各会社に対するソリューションについて説明するが、説明した技術は他の会社に対するソリューションにも転用可能である。

＜第１ソリューション（エッジデバイス製造会社向け）＞
分散システム１０００は、エッジデバイス製造会社に対して、ＥＣＴＬ診断データおよび分析結果をデータフローＤ２２の通り提供することが可能であるが、そのソリューションについて以下に例を挙げて説明する。本例は、本発明に係る分散システム１０００を利用する態様の一例にすぎず、本発明を適用可能な範囲を限定するものではない。なお、本明細書ではエッジデバイス１２が自動車である場合は、エッジデバイス製造会社は、ＩＳＯ １６９４９に規定のＯＥＭ（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅ）と呼ぶ場合がある。なお、本ソリューションではエッジデバイス製造会社が保有する製造会社用計算機２１を備えるが、すでに説明済であるため、省略する。

＜＜エッジ内コントローラ＞＞
エッジ内コントローラ１０はこれまで説明した通りの構成に加えて、診断回路を有する。診断回路は、エッジ内コントローラ１０のハードウェア構成物を診断するための回路である。診断回路は構成物を診断するためのエッジ内コントローラセンサと、該センサによって得られた値をそのまま又は加工して状態データ診断部１１０に提供するＩＦ回路と、を有る。ここで、エッジ内コントローラセンサは、エッジ内コントローラ１０の構成物に取り付けた温度計、電流計、抵抗計が例である。なお、ＦＰＧＡは内部に論理的な回路を有するとみなせるため、診断回路の実現手段の一つとしてもよい。

状態データ診断部１１０は、エッジデバイス１２（特にエッジ内コントローラ）の電子的な状態（例えばシステムレジスタの保持している値やバスＩ／Ｆの内容）を示す情報を対象とする。ここで当該情報は、ハードウェア自体が提供するローレベルのデータ表記形式であるため、ハードウェア依存形式の状態情報と呼ぶ。そのために、状態データ診断部１１０は、診断シーケンスに従ってハードウェア依存形式の状態情報を取得して診断処理を行う。なお、ハードウェア依存形式の状態情報の取得タイミングは、例えば異常状態を検知した契機の他、定期的（一日一回等）、あるいは起動時等に実施するものであってもよい。

診断シーケンスの情報は、エッジ内コントローラ１０に包含される診断シーケンス格納部１１１に格納される。そして状態データ診断部１１０が診断処理を行うときに診断シーケンスは読み出されて使用される。ここで、ハードウェア依存形式の状態情報は、低レベル過ぎる情報であるため、各クラウドで取り扱うには不便がある上に、すべての情報を繰り返し取得して逐次格納するのはエッジ内コントローラ１０の記憶リソースの無駄である。

診断シーケンスに基づいた診断処理は、ハードウェア独立なデータフォーマットに状態情報を加工して不便性を解消したり、又は発生した異常状態の要因候補を絞り込んで、異常状態又は要因候補に関連する状態情報に絞って処理、データ格納、又はデータ送信を行う。本ソリューションにおけるデータＤ１１（ＥＣＴＬ診断データ）に含まれる情報は、このような診断処理で加工された状態情報であると言える。なお、状態情報のハードウェア独立なデータフォーマットは、複数のエッジ内コントローラ１０の製造会社間で定められた標準インターフェースとして定められたフォーマットが好ましいが、そうでなくてもよい。

上記の通りの役割を担う診断シーケンスは、例えば以下が定義されている。
＊複数の診断項目。
＊診断項目間の診断順序や、診断項目の実行条件。
＊診断シーケンスを開始する条件。
なお、ここの診断項目は例えば下記を含む。
＊ハードウェア依存形式の状態情報を取得するためのパラメータ。例えばシステムレジスタのアドレスやメモリマップドエリアのアドレス、割り込み番号がある。
＊ハードウェア依存形式の状態情報をハードウェア独立なデータフォーマットに加工するための加工パラメータ。例えばレジスタの値が「０ｘＦＦＦＦ」の場合はそのハードウェアが異常であることを示すハードウェア独立なデータフォーマットである「Ｆａｌｓｅ」テキストを出力するためにこれらパラメータをセットで管理する。
状態データ診断部１１０を実現する診断プログラムは、診断シーケンスの定義を解釈し、当該定義にしたがった処理を行う。

＜＜診断データクラウド＞＞
図５は、診断データクラウドの構成例を示す図である。診断データクラウド３２は、診断データ管理クラウド２６および分析アウトソーシングクラウド２７を含む。なお、以下に説明する診断データ管理クラウド２６の一部構成物を、分析アウトソーシングクラウド２７の構成物として移動させてもよい。また、以下に説明する分析アウトソーシングクラウド２７の一部構成物を、診断データ管理クラウド２６の構成物としてもよい。なお、図５に於いて、隅が丸い四角で表された各「部」はクラウドの記憶リソースで実現された部（いいかえると、記憶リソースが提供する記憶領域の一部であるため、前述の説明の通り「部」を「領域」と読み替えて呼ぶこともできる。隅が丸くない四角で表された各「部」は計算機４００で説明したプログラムを用いて実現される。以下に詳細を説明するが、その際には後ほど説明する図６〜図７に含まれる図番を記載している場合がある。

＜＜＜診断データ管理クラウド＞＞＞
診断データ管理クラウド２６には、診断モデル定義部３と、診断モデル格納部４と、診断シーケンス生成部５と、診断回路・プログラム格納部６と、診断回路・制御更新部１５と、診断シーケンス格納部と、が含まれる。

診断モデル定義部３は、設計データ１３に基づいて、診断モデルを定義する。具体的には、診断モデル定義部３は、画面を表示させて製品の設計データ１３を表示し、製品の構成部品および診断箇所等を含む機能の図示を行い、診断箇所等の構成関係の入力を受け付けて、診断モデルとして診断モデル格納部４に格納する。この診断モデル定義部３は、主として診断データ管理クラウド２６の保有者が利用するが、これに限られるものではなく、エッジデバイスの製造会社が利用するようにしてもよい。ここで、前述の「製品」とは、エッジデバイス１２又はエッジデバイス１２の構成物、又はエッジ内コントローラ、である。

診断モデル格納部４には、診断モデルが格納される。診断モデルについては後ほど説明する。

診断回路・制御更新部１５は、分析アウトソーシングクラウド２７により分析処理された分析後データを受け取って、診断回路・プログラム格納部６に格納された診断回路の情報（より正確には診断回路の設計情報）および診断プログラムを変更する。ここで、診断プログラムは、エッジ内コントローラ１０に複製後、エッジ内コントローラ１０で実行されることで状態データ診断部１１０を実現するプログラムである。

診断回路・プログラム格納部６には、診断回路の情報又は診断プログラムが格納されている。なお、診断回路・プログラム格納部６には、診断回路及び診断プログラムのインターフェース仕様が格納されてもよい。なお、診断回路の情報は設計データ１３の一部であるから、当該ソリューション開始時の診断回路の情報は、設計データ１３から該当する情報を抽出し、診断回路・プログラム格納部６に格納してもよく、又はエッジ内コントローラ製造会社が保有する診断回路の情報を診断回路・プログラム格納部６に格納してもよい。診断プログラムも同様である。

診断シーケンス生成部５は、診断モデルと、診断回路の情報と、診断プログラム（又は診断プログラムの情報）と、に基づいて、診断シーケンスを生成する。生成した診断シーケンスは、診断シーケンス格納部に格納後、エッジ内コントローラ１０に送信される。よって、診断シーケンス生成部で生成される診断シーケンスの定義は、エッジ内コントローラ１０にて説明した診断シーケンスの定義と同様である。

＜＜＜＜診断モデルと、診断シーケンス、診断プログラムとの関係＞＞＞＞
ここで、診断モデル、診断シーケンス、診断プログラム、診断回路との関係又は差異についてまとめる。前述の通り、診断シーケンス、診断プログラム、診断回路、はエッジ内コントローラ１０の構成物であり、診断データクラウド３２によりアップデートが繰り替えされる。よって、診断シーケンス、診断プログラム、診断回路（の情報）、は設計データ１３の一部である、と考えてもよい。一方で、診断モデルは、設計データ１３から診断シーケンスを生成するための中間データと捉えられる。その特徴としては、診断モデルの再利用性や作成負荷軽減のために、診断シーケンスよりもハードウェア非依存性を高め、また頻繁に用いる一連の診断項目をグループ化（ブロック化）できるデータ表現である。また、診断モデルは、複数種類の製品に共通なデータ表現とされることにより、モデルの再利用性が高められるようにしてもよい。

＜＜＜分析アウトソーシングクラウド＞＞＞
分析アウトソーシングクラウド２７には、診断結果格納部７と、要因分析処理部８と、分析後データ格納部９と、分析ルール更新部１６と、分析ルール格納部と、構成情報格納部と、が含まれる。

診断結果格納部７には、エッジ内コントローラ１０から、診断データ管理クラウド経由で受信したＥＣＴＬ診断データが格納される。そのデータの流れはデータフローＤ１１、Ｄ２１、Ｄ２５という一連の流れの他、データフローＤ１１、Ｄ２６という一連の流れであってもよい。前述の通り、Ｄ２６を用いた流れのほうがよりリアルタイムなデータを得られる。

要因分析処理部８は、分析ルールと、構成情報に基づいて、ＥＣＴＬ診断データを分析することで、製品の構成物の異常要因を特定する。なお、特定する構成物の単位は、交換部品の単位や、特定した異常要因を分析する人が理解しやすい構成物単位であってもよい。また、要因分析処理部８は、異常要因の情報に、発生した異常の情報を関連付けるのが望ましい。要因分析処理部８は、構成情報格納部にエッジデバイス１２の情報が不足する場合には、エッジデータ配信会社クラウド２４または製造会社用計算機２１から設計データ１３を受信して利用する。

分析ルールは、異常の連鎖関係、すなわち異常の因果の関係に基づいて連鎖して発生する異常状態の連鎖関係を定義した情報である。分析ルール格納部はこのような分析ルールが格納される。なお、分析ルールは、設計データ１３に基づいて生成されてもよく、又は診断モデルに基づいて生成されてもよい。そのため、分析ルール自体は、エッジデバイス製造会社計算機２１や、診断データ管理クラウド２６で生成して、分析アウトソーシングクラウド２７に送信してもよい。又は、設計データ１３や診断モデルを分析アウトソーシングクラウドに複製して、分析アウトソーシングクラウドで分析ルールを生成してもよい。なお、後ほど説明する図８では、そのうち一つの例で説明する。

構成情報格納部には、製品の構成を示す情報である構成情報が格納される。構成とは例えば製品の構成物の型番やシリアル番号といった静的な情報の他、ＥＣＴＬ診断データ以外から取得した、稼働によって動的に変化する構成物に関する値（例えば累積燃料消費量）を含めてもよい。

なお、エッジ内コントローラ１０内部の異常状態を特定した場合、その要因はエッジ内コントローラ１０の場合もあれば、エッジ内コントローラ１０の外部（例えばエッジデバイス１２、エッジデバイス１２の他の構成物）である場合もある。よって、好ましくは、分析ルールと構成情報は、エッジ内コントローラ１０に限らず、エッジデバイス１２及びエッジデバイス１２の他の構成物に関する情報も含める。

分析ルール更新部１６は、診断シーケンス（又は設計データ１３）に変更があった場合に、変更に伴って分析ルール格納部に格納される分析ルールを更新する。このために、分析ルール更新部１６は、診断データ管理クラウド２６又は製造会社用計算機２１から設計データ１３を受信してもよい。

＜＜診断モデル定義画面と診断モデル＞＞
次に、図７を用いて診断モデル定義画面と診断モデルを説明する。

図７は、診断モデル定義画面の例を示す図である。診断モデル定義画面５００は、診断モデル定義部３により作成され、診断モデルを定義する際の入力情報を受け付けて入力情報を反映した出力情報を表示する画面である。そして、診断モデル定義部３は、診断モデル定義画面５００において入力された定義情報に基づいて、所定の診断モデルを作成して診断モデル格納部４に格納する。

診断モデル定義画面５００においては、設計データ１３をベースとしてビジュアルかつインタラクティブに製品の機能設計を行う画面が表示される。画面の利用者は、この画面を用いて抽象化された診断シーケンスを設計する。

診断モデル定義画面５００は、機能・データフロー定義エリア５０１と、ライブラリエリア５０２と、を含む。これらエリアは下記の意味を持つ。

＊ライブラリエリア５０２には、製品に含まれる構成物、又は製品にこれから含めるかもしれない構成物候補を示すノード（構成物メタノードと呼ぶ）が、種類別に配置されている。構成物メタノードは、一種類の構成物と対応してもよく、複数種類の構成物の集合体と対応してもよく、所定の種類の構成物の一部と対応してもよい。
＊機能・データフロー定義エリアには、製品に含まれる構成物を示すノード（構成物インスタンスノード）と、構成物インスタンスノードが示す構成物間のデータの流れを示すリンクオブジェクト（図中では矢印で表記）が含まれる。

なお、構成物メタノードには、複数の属性情報を付与することができる。なお、属性情報の一部又は全てを診断回路又は診断プログラムより取得指定できる。例えば、「ＧＰＵ」である構成物メタノードは下記が属性情報として付与可能である。
＊内部メモリエラーの有無
＊演算コア例外発生の有無
＊内部バスのエラーの有無

同様な属性情報は、リンクオブジェクトにも付与する。リンクオブジェクトの属性情報は例えば下記である。
＊リンクオブジェクトが示すデータの流れにおける、送信元構成物インスタンスノードの属性情報から、どの情報を送信先構成物インスタンスノードに送信するか、の指定情報
＊情報受信頻度

以上がリンクオブジェクトの属性情報である。なお、構成物インスタンスノードにも属性情報を付与可能としてもよい。当該属性情報は、例えば、対応する種類の構成物メタノードの属性情報のサブセットであってもよい。

画面利用者が新たな診断回路に対応した診断シーケンスを作成したいと考えた場合、画面利用者は下記の操作をする。
＊ライブラリエリア５０２の新たな診断回路に対応した構成物メタノードを作成し、属性情報を付与する。
＊作成した構成物メタノードを、機能・データフロー定義エリア５０１にドラッグアンドドロップし、インスタンス化する。これによって新たな診断回路に対応した構成物インスタンスノードが作成される。
＊診断回路が診断対象にしたい構成物に対応する構成物インスタンスノードをクリックし、次に作成した構成物インスタンスノードをクリックする。これによって、診断対象構成物から診断回路へのデータを流すことを意味するリンクオブジェクトを生成する。
＊作成したリンクオブジェクトの属性情報に、診断回路に診断させたい送信元構成物インスタンスノードの属性情報を設定する。

以上の操作後に保存操作を行うことで、診断モデルが診断モデル格納部４に格納される。診断シーケンス、診断回路、診断プログラムと比較すると、診断モデル定義画面の表示情報は、ハードウェア依存性がより低いため異種再利用性が高い。また、１つのノードまたはリンクオブジェクトに複数の属性情報を付与してまとめられるようにしたため、診断項目のグループ化が可能となる。

診断モデルは前述の診断モデル定義画面５００で作成した機能・データフロー定義エリアの内容が格納される。よって、診断モデルには例えば下記が格納される。
＊構成物メタノードの情報。当該情報には属性情報が含まれる。
＊構成物インスタンスノードの情報。当該情報には、生成時に指定した構成物メタノードの識別子を含む。また、当該情報には属性情報を含めてもよい。
＊リンクオブジェクトの情報。当該情報には、送信元構成物インスタンスオブジェクトの識別子と、送信元構成物インスタンスオブジェクトの識別子と、データを流す属性情報と、を含む。

ここで、診断モデル定義画面や診断モデルのハードウェア依存度を軽減する趣旨で、下記のようにしてもよい。
＊属性情報の名前を、診断シーケンスの診断項目を一般化した名前とする。
＊診断モデルには、診断シーケンスに含まれる診断項目のハードウェア依存情報（例えば説明済のパラメータ、加工パラメータ）を含めない。

＜＜計算機、クラウド、エッジデバイス間の連携の流れ＞＞
図６は、第１ソリューションにおける、計算機、クラウド、エッジデバイス間の連携の流れを示した図である。以下、各々について説明する。

（ステップＳ１Ｂ０１）診断データ管理クラウド２６（より具体的には診断モデル定義部３）は、診断シーケンスを生成する。
（ステップＳ１Ｂ０２）診断データ管理クラウド２６（より具体的には診断モデル定義部３）は、生成した診断シーケンスを送信する。図６では送信先としてエッジデバイス製造会社計算機２１を例として記載したが、本ソリューションでも送信先はこの計算機やクラウドに限られない。
（ステップＳ１Ａ０１）エッジデバイス製造会社は、エッジデバイス１２を製造する。このときに、Ｓ１Ｂ０２にて送信された診断シーケンスはエッジ内コントローラ１０に格納されている。
（ステップＳ１Ａ０２）エッジデバイス製造会社は、製造したエッジデバイス１２を出荷する。出荷先は図１及び関連する記載に示した会社や団体の他、個人（以後、まとめてエッジデバイス利用エンティティと呼ぶ）に出荷してもよい。なお、このステップで出荷したエッジデバイス１２を現世代のエッジデバイスと呼ぶことがある。

（ステップＳ１Ｃ０１）エッジデバイス利用エンティティは、エッジデバイス１２を稼働開始する。稼働開始したエッジデバイス１２は、自動運転等の自動稼働で移動したり、または充電や給油されたり、駐車場で一時的に稼働停止されたりする。
（ステップＳ１Ｃ０２）エッジデバイス１２（より具体的にはエッジ内コントローラ１０であり、さらに具体的には、状態データ診断部１１０）は、エッジデバイス１２が異常状態であると検知（または診断）する。その後、状態データ診断部１１０で説明した診断を行い、ＥＣＴＬ診断データを送信する。なお、図６では、当該データは診断データ管理クラウド経由で送信する場合（データフローＤ１１、Ｄ２６の流れ）を例示している。この流れのほうが、エッジデータ配信会社クラウド２４経由よりもよりリアルタイムに近く送信できるメリットがあるからであるが、他の経路でもよい。

（ステップＳ１Ｄ０１）分析アウトソーシングクラウド２７は、ＥＣＴＬ診断データを受信する。そして要因分析処理部８は、ＥＣＴＬ診断データが示した異常状態の要因を分析する。
（ステップＳ１Ｄ０２）分析アウトソーシングクラウド２７は、ステップＳ１Ｄ０１の分析後データを、エッジデバイス利用エンティティと、エッジデバイス製造会社計算機と、診断データ管理クラウド２６と、に送信する。なお、分析後データの内容は、エッジデバイス利用エンティティに送信する場合と、エッジデバイス製造会社計算機に送信する場合とで異なってもよい。なお、送信経路は図６に示した通り、データフローＤ２２、Ｄ２６、Ｄ２７である。なお、すでに説明したデータの具体例を本ステップで送信してもよい。

（Ｓ１Ｃ０３）エッジデバイス利用エンティティは、受信した分析後データを参照しなが、エッジデバイス１２を復旧させる。
（Ｓ１Ｂ０３）診断データ管理クラウド（より具体的には診断回路・制御更新部）は、受信した分析後データに基づいて、異常状態発生を軽減するように、診断回路又は診断プログラムを更新する。そして更新した診断回路又は診断プログラムを、エッジデバイス製造会社に送信する。なお、診断データ管理クラウド２６は、本ステップにて診断シーケンスを更新してもよく、エッジデバイス製造会社が設計担当する設計データ１３の一部を更新または更新提案してもよい。このようにして更新された診断回路と診断プログラムは、改善データであるともいえる。
（Ｓ１Ａ０３）エッジデバイス製造会社は、受信した分析後データに基づいて、次世代のエッジデバイス１２の設計データ１３を作成する。当該作成は、エッジデバイス製造会社は、改善データに基づいてもよい。

なお、図６の流れの後の処理として、エッジデバイス製造会社は、データＤ２６に基づいて、ステップＳ１Ｂ０１の診断シーケンス生成を行って、診断シーケンスを更新（つまり改善された診断シーケンス）を生成してもよい。なお、改善された診断シーケンスも、改善データの一つである。また、エッジデバイス製造会社は、エッジデバイス１２の設計上の問題点や注意点を解消するための機能アップデートを行う場合には、アップデート用のデータをエッジデータ配信会社クラウド２４に送信することで、エッジデバイス１２にアップデートデータを送り機能改善や不具合の改善を行うことができる。

以上が流れの説明である。本ソリューションでは、エッジデバイス利用エンティティはより迅速に異常からの復旧が可能になる。また、エッジデバイス製造会社は、異常発生を軽減した次世代エッジデバイスの設計がより簡易となる。

＜第２ソリューション（ディーラ又は修理会社向け）＞
分散システム１０００は、ディーラ又は修理会社に対して、ＥＣＴＬ診断データおよび分析後データを提供することが可能であるが、そのソリューションについて以下に例を挙げて説明する。本例は、本発明に係る分散システム１０００を利用する態様の一例にすぎず、本発明を適用可能な範囲を限定するものではない。

本例は、基本的には上述したエッジデバイス製造会社に対するソリューションと同様の構成を備える。そのため、重複する説明は省略し、差異のある点を中心に説明する。診断データクラウド３２は、エッジデバイス１２のディーラ又は修理会社に対して、要因分析の分析後データとに加えて、修理情報（交換対象部品、交換日程）を提供する。

＜＜計算機、クラウド、エッジデバイス間の連携の流れ＞＞
図８は、第２ソリューションにおける、計算機、クラウド、エッジデバイス間の連携の流れを示した図である。以下、各々について説明する。なお、第１ソリューションと同じ部分（特に図の番号が同じ部分）は説明を省略する。なお、以下の例ではエッジデバイス利用エンティティがＭａａＳやレンタル会社であると仮定して、異常発生したエッジデバイスに対して代替のデバイスをエンティティに貸与しているが、そうでなくてもよい。つまり、エッジデバイス１２の交換をせずに、ディーラまたは修理会社が修理を完了するまで待ってもよいということである。

（ステップＳ１Ｄ０１）分析アウトソーシングクラウド２７は、ＥＣＴＬ診断データを受信する。そして要因分析処理部８は、ＥＣＴＬ診断データが示した異常状態の要因を分析する。なお、分析内容は第１ソリューションと同じでもよく、異なってもよい。なお、本ソリューションでは、要因分析の処理の一部として、エッジデバイス１２に含まれる、交換すべき部品（構成物である）を特定する。さらに要因分析処理は、部品の想定交換時間、又は部品がエッジデバイス製造会社からディーラ又は修理会社に到着するまでの時間、を推定してもよい。なお、以後の説明ではこれら交換すべき部品の情報と、推定時間と、が分析後データに含まれるものとして説明する。

（ステップＳ１Ｄ０２）分析アウトソーシングクラウド２７は、ステップＳ２Ｄ０１の分析後データを、ディーラ又は修理会社クラウド２８にに送信する。なお、送信経路は図８に示した通り、データフローＤ３２である。
（ステップＳ２Ｃ０３）エッジデバイス仕様エンティティは、エッジデバイス１２を交換する。交換された異常状態を有するエッジデバイス１２は、ディーラ又は修理会社に送られる。なお、図８では、ディーラ又は修理会社クラウドが代替エッジデバイスの手配をすることは省略している。また、エッジデバイス仕様エンティティは、代替エッジデバイスを利用する。

（ステップＳ２Ｅ０１）ディーラ又は修理会社は、分析後データを受信したら、部品の在庫を確認し、在庫がない場合はエッジデバイス製造会社に送付を依頼する。なお、本判断は、異常が発生したエッジデバイス１２がディーラ又は修理会社に到着する前に行ってもよい。特にエッジデバイスが移動体で異常発生により移動ができない場合は、移動体をレッカー車で異常発生位置からディーラ又は修理会社の敷地まで移動させる必要がある場合等が考えられるため、長時間かかるおそれがある。このような分析後データ受信を契機とした手配は、修理時間を短くすることができる。加えて、推定時間を活用することで、ディーラ又は修理会社クラウドはより計画的に修理を行うことができる。そして、ディーラ又は修理会社は、エッジデバイス１２を修理する。

（ステップＳ２Ｅ０２）ディーラ又は修理会社は、修理が完了したエッジデバイス１２をエッジデバイス利用エンティティに送る。なお、このときのエンティティは交換前のエンティティとことなってもよく、同じでもよい。
（ステップＳ２Ｃ０４）エッジでアイス利用エンティティは、修理が完了したエッジデバイス１２の稼働を開始する。

＜＜要因分析処理後データ画面＞＞
図９は、ディーラ又は修理会社向け要因分析後データ画面６００の例を示す図である。当該画面で表示される情報は、ステップＳ２Ｄ０２で送信される分析後データに含まれるとみなしてよい。当該画面は、ディーラ又は修理会社の社員が利用する。当該画面はＷｅｂアプリケーションとして実現される。

ディーラ又は修理会社向け要因分析後データ画面６００には、要因分析の対象のエッジデバイスを示す名称・型番を表示するエリアと、利用エンティティの履歴を表示するエリアと、分析後データを表示するエリアと、が含まれる。以下、各エリアについて説明する。
＊名称・型番を表示するエリアには、例えば要因分析の対象のエッジデバイスが自動車である場合には、車両種類や型式、あるいは構成情報ＩＤが表示される。
＊利用エンティティを表示するエリアには、当該エッジデバイスを利用したエンティティのＩＤが履歴形式で表示される。なお、本エリアにはそのほかの履歴（例えば、稼働開始日、メンテナンス履歴）が表示されてもよい。

要因分析処理後データを表示するエリアには、例えばエッジデバイス１２に関する下記が表示される。なお、全ての表示が必須ではない。
＊異常状態の構成物のＩＤ。
＊異常状態発生の日時。
＊診断時に診断回路および診断プログラムにより取得したレジスタの値やメモリの値を示すレジスタダンプやメモリダンプ。当該値はエキスパート向けである。
＊通信ログ。
＊異常要因を示す情報。

ここで、異常要因には、発生した異常要因に応じて、ソフトウェア異常かハードウェア異常かを判断する情報が含まれる。ソフトウェア異常とハードウェア異常とでは、解消の方法が大きく異なることが多いためである。

以上、本ソリューションによればディーラ又は修理会社は迅速にエッジデバイスが異常状態になり、修理が必要なことを迅速に把握できる。また、ディーラ又は修理会社が設計データを用いて、交換が必要な部品の特定する必要がないため、より幅広い人が修理に従事できる。

＜第３ソリューション（保険会社向け）＞
分散システム１０００は、保険会社に対して、ＥＣＴＬ診断データおよび分析後データを提供することが可能であるが、そのソリューションについて以下に例を挙げて説明する。本例は、本発明に係る分散システム１０００を利用する態様の一例にすぎず、本発明を適用可能な範囲を限定するものではない。

本例は、基本的には上述したエッジデバイス製造会社に対するソリューションと同様の構成を備える。そのため、重複する説明は省略し、差異のある点を中心に説明する。診断データクラウド３２は、エッジデバイス１２に関連する保険会社に対して、要因分析の分析後データの一部として、検知した異常の発生要因と発生頻度等の統計情報を提供するものとする。なお、以後の説明では、保険会社が支払う金を保険金（ｉｎｓｕｒａｎｃｅ ｐａｙｏｕｔ）と呼び、契約エンティティが保険会社に支払う金を保険料（ｐｒｅｍｉｕｍ）と呼ぶ。

＜＜保険会社クラウド＞＞
本ソリューションにおける保険会社クラウド２９は、記憶リソースとして下記データが格納されている。
＊契約条件データ： 保険サービスの仕様に相当する契約条件を示すデータである。当該データには、保険金支払い条件（金額を含む）、保険料、契約期間、といった保険契約に規定された条件が格納されている。
＊契約エンティティデータ： 契約エンティティに関するデータである。当該データには、エンティティの名前、適用される契約条件を示すＩＤ、契約開始日が格納されている。なお、契約エンティティが特定のエッジデバイス１２を利用する時のみ適用される保険サービスの場合は、エッジデバイス１２を特定するデータ（例えば車両ナンバー）を含めてもよい。なお、当該データには、契約には直接関係ない、営業活動用のエンティティ関連データを格納してもよい。

＊保険金支払履歴データ：保険金の支払い履歴に関するデータである。当該データには、支払日、保険金額、支払先となる契約エンティティのＩＤ、契約条件のＩＤ、保険金額を決定するために用いたデータ（例えばどのような異常や事故であったかを示すデータ）が格納される。
＊保険料収納履歴：保険料の収納履歴に関するデータである。当該データには、受領日、保険料、支払元となる契約エンティティのＩＤ、契約条件のＩＤが格納される。

なお、上記説明におけるデータ全てが必須ではなく、また、各データが厳密に別々なテーブルや記憶領域に格納されている必要はない。

保険会社クラウドでは、保険会社による保険サービス提供のためのプログラム（以後、保険サービスプログラムと呼ぶ）が実行される。保険サービスプログラムは、上記データの元ととなるデータを契約対象者等から受信したり、保険料の収納や、保険金支払いに応じて、これらデータを更新する。

保険会社クラウド２９は、さらに契約条件分析プログラムを実行する。同プログラムは、上記データにアクセスすることで、契約条件の改定に必要な分析処理を行うプログラムである。契約条件分析プログラムは、例えば、下記の処理を行ってもよい。
＊前述のデータを用いて、所定の契約条件を仮定した時の保険契約数、契約数に基づいた保険料の合計、保険金合計を予想する。
＊前述のデータを用いて、保険会社の利益額又は利益率といった経営指標を仮定した場合に適合する契約条件の案を算出する。

＜＜計算機、クラウド、エッジデバイス間の連携の流れ＞＞
図１０は、第３ソリューションにおける、計算機、クラウド、エッジデバイス間の連携の流れを示した図である。以下、各々について説明する。なお、第１、第２ソリューションと同じ部分（特に図の番号が同じ部分）は説明を省略する。

（ステップＳ３Ｄ０１）分析アウトソーシングクラウド２７は、ＥＣＴＬ診断データを受信する。そして要因分析処理部８は、ＥＣＴＬ診断データが示した異常状態の要因を分析する。なお、分析内容は第１、第２ソリューションと同じでもよく、異なってもよい。なお、本ソリューションでは、要因分析の処理の一部として、検知した異常の発生要因と発生頻度等の統計情報を提供する。
（ステップＳ３Ｄ０２）分析アウトソーシングクラウド２７は、ステップＳ２Ｄ０１の分析後データを、保険会社クラウド２９に送信する。なお、送信経路は図８に示した通り、Ｄ３２である。
（ステップＳ３Ｆ０１）保険会社クラウド（より具体的には契約条件分析プログラム）は、受信した分析後データと記憶リソースに記憶された前述のデータと、を用いて保険契約条件の改定案を算出する。

以上が流れである。なお、保険の契約条件は、保険料が低額であっても、保険金支払いの条件が厳しいと契約エンティティが契約に至らない。一方で、保険金支払いの条件を緩和しすぎると保険会社の収支が悪化しすぎてサービスが継続できない。分析アウトソーシングクラウドが提供する加工後データにより、エッジ内コントローラ１０の内部の異常状態の発生頻度も踏まえて保険金支払い条件を設定できる。たとえば、もし特定の条件（例えばエッジデバイス１２の種類、利用環境、利用エンティティの種類）で、エッジ内コントローラの内部の異常状態の発生頻度が高くなる場合は、当該条件の場合の保険料を高め、反対に発生頻度が低い条件の場合は保険料を低くする、といった保険料の適正化が可能となる。このメリットは、自動稼働の普及によってエッジ内コントローラ１０が関連する異常が多くなる場合はより大きなメリットとなる。

＜第４ソリューション（レンタル会社又はＭａａＳ会社向け）＞
ディーラ又は修理会社向けの第２ソリューションは、レンタル会社又はＭａａＳ会社に対しても適用できる。しかし、レンタル会社又はＭａａＳ会社は、ディーラ又は修理会社と比較すると、エッジデバイス１２に対して細やかな修理は行わない。一方で、レンタル会社又はＭａａＳ会社が提供するサービスの場合、エッジデバイス１２が正常に稼働しているからこそサービスの利用者から適正な費用を得られる。よって、エッジデバイス１２の異常状態からの復旧時間は、より短くなる。

そのため、本ソリューションでレンタル会社又はＭａａＳ会社に提供する情報をよりカスタマイズさせることが好ましい。本ソリューションについてはまずレンタル会社又はＭａａＳ会社向けの要因分析後データ画面７００を差分を中心に説明する。

＜＜要因分析後データ画面＞＞
図１１は、レンタル会社又はＭａａＳ会社向け要因分析後データ画面７００の例を示す図である。当該画面は、レンタル会社又はＭａａＳ会社の社員が利用する。当該画面はＷｅｂアプリケーションとして実現される。なお、図１１の画面は図９の要因分析後データ画面（ディーラ又は修理会社向け）と同様な情報であるため、差分のある点を中心に説明する。当該画面は分析アウトソーシングクラウド２７の処理によって、レンタル会社又はＭａａＳ会社クラウド２２で表示される画面である。

要因分析後データ画面７００には、要因分析の対象のエッジデバイスを示す名称・型番を表示するエリアと、利用エンティティの履歴を表示するエリアと、分析後データを表示するエリアと、が含まれる。以下、各エリアについて説明する。
＊名称・型番を表示するエリアには、例えば要因分析の対象のエッジデバイスが自動車である場合には、車両種類や型式、あるいは構成情報ＩＤが表示される。
＊利用エンティティを表示するエリアには、当該エッジデバイスを利用したエンティティのＩＤが履歴形式で表示される。なお、本エリアにはそのほかの履歴（例えば、稼働開始日、メンテナンス履歴）が表示されてもよい。

要因分析処理後データを表示するエリアには、例えばエッジデバイス１２に関する下記が表示される。なお、全ての表示が必須ではない。
＊異常状態の構成物のＩＤ。
＊異常状態発生の日時。
＊異常状態発生の位置。
＊異常状態対応緊急度。
＊異常状態への対応必要期間。
＊異常状態への対応必要コスト。
＊異常要因を示す情報。
＊異常状態の発生履歴。

ここで、エッジデバイス１２の異常状態からの復旧時間をより短縮させるための情報は、位置、緊急度、対応必要時間である。レンタル会社又はＭａａＳ会社はこれら要素を考慮の上で適切な復旧方法を選択することができる。当該画面を提供されることで可能となる復旧方法は例えば下記である。
＊異常状態発生位置が、レンタル会社又はＭａａＳ会社の拠点位置より遠いエッジデバイスを優先して復旧作業する。当該優先が反映される例としては代替用のエッジデバイス１２の手配である。

＊緊急度が低い異常状態を緊急度が高い異常状態になる前に解消する。本ソリューションの場合、エッジ内コントローラ１０の内部状態に基づいてこまやかに緊急対応度を決定できるため、このようなことが可能となる。なお、この緊急度は、分析アウトソーシングクラウド２７で分析処理としてＥＣＴＬ診断診断データの相関性解析を行い、分析後データとして当該相関性を得て、緊急度設定に考慮してもよい。例えば単体ではエッジ内コントローラ１０に致命的ではない異常状態であれば優先度を低とすることができるが、相関性が高い異常状態が緊急度の高いものであれば、前者の異常状態を低よりも高い中や高にする。
＊緊急度に基づいた復旧作業の優先付け実施。特に同じエッジデバイス１２内で緊急度の異なる異常状態が発生した場合は、緊急度の高い異常状態の解消を行うことで緊急度が低い異常状態も解消していることがある。

＜＜計算機、クラウド、エッジデバイス間の連携の流れ＞＞
計算機、クラウド、エッジデバイス間の連携の流れは、第２ソリューションについて説明した図８と関連する説明の通りである。ただし、図１１で説明した画面を分析アウトソーシングクラウド２７で行われるステップＳ２Ｄ０１で実施するため、当該ステップで行う要因分析処理では、図１１で説明した情報を生成する処理が入る。なお、データ送信に関するステップＳ２Ｄ０２が送信するデータに図１１で説明した情報が含まれることは言うまでもないことである。

＜バリエーション＞
以上で各ソリューションの説明を終える。本発明は上記の実施形態に限定されるものではなく、以下の通り様々な変形例が含まれる。

エッジ内コントローラ１０がＥＣＴＬ診断データとして出力するデータは必ずしも異常状態又はハードウェア構成物の状態である必要はない。例えば、ソフトウェアの現在状態に加え、過去の処理の履歴（例えば、ニューラルネットワークのパラメータやハイパーパラメータ、その他機械学習の学習状態、自動運転プログラムの場合は、所定の制御を移動又は作動機構に行う理由となった自動運転ルールや分岐処理の位置（名前））をＥＣＴＬ診断データに含めてもよい。

また、会社が所定のサービスを提供するクラウドを有すると上述してきたが、必ずしもクラウドを構成するハードウェア資源を当該会社が所有する必要はない。同様に所定のサービスを提供するためのプログラムの一部又は全てを当該会社が所有している必要もない。

ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。

実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が通信ネットワーク、バス等により相互に接続されていると考えてもよい。

本発明に係る技術は、分散システムに限られず、計算機、コンピュータ読み取り可能なプログラム、分散処理方法などの様々な態様で提供できる。

＜まとめ＞
以上、本明細書では下記を説明した。なお、クラウドサーバは少なくとも１以上の計算機で構成されるため、代表して計算機で説明する。

＜＜視点１＞＞
自動稼働可能な移動体又は設備であるエッジデバイスと、診断データ計算機と、前記エッジデバイスの製造会社が有する計算機である、製造会社用計算機と、を有する分散システムであって、前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は前記作動機構を制御するエッジ内コントローラと、を有し、前記診断データ計算機は：前記エッジ内コントローラ内の内部状態を示す診断データを受信し、前記診断データに基づいて、前記エッジ内コントローラ内の状態の要因分析処理を行い、前記製造会社用計算機に、前記要因分析処理後のデータ、又は前記要因分析処理の結果に基づいた前記エッジデバイスの改善データを送信する、分散システム。

＜＜視点２＞＞
視点１記載の分散システムであって、前記診断データ計算機は、前記エッジデバイスで発生する状態の因果関係を格納した分析ルールを記憶リソースに格納し、前記診断データ計算機は、前記要因分析処理中に、前記分析ルールを参照する、分散システム。

＜＜視点３＞＞
視点１記載の分散システムであって、前記診断データ計算機が前記製造会社用計算機に前記改善データを送る場合、前記改善データは、前記エッジデバイスの次世代の設計データである、分散システム。

＜＜視点４＞＞
視点１記載の分散システムであって、前記診断データ計算機が前記製造会社用計算機に前記改善データを送る場合、前記前記改善データは、前記エッジ内コントローラの改善データであり、前記製造会社用計算機は、改善データを、前記エッジデバイスに送信する、分散システム。

＜＜視点５＞＞
視点４記載の分散システムであって、前記分散システムは、前記製造会社用計算機から前記改善データを受信して、前記エッジデバイスへ送信するエッジデータ配信会社用計算機を有し、前記エッジデータ配信会社用計算機は：前記診断データ計算機から、前記診断データを受信し、前記診断データを記憶リソースに格納し、所定のスケジュールに従って、前記記憶リソースに格納した前記診断データを、加工処理し、加工後の前記診断データを、所定のサービスを提供する会社の計算機である、サービス提供会社用計算機に送信する、分散システム。

＜＜視点６＞＞
視点１記載の分散システムであって、前記診断データ計算機は：所定のサービスを提供する会社の計算機である、サービス提供会社用計算機に、前記要因分析処理後のデータ、又は前記要因分析処理の結果に基づいた前記エッジデバイスの異常の要因を特定するデータ、を送信する、分散システム。

＜＜視点７＞＞
視点１記載の分散システムであって、前記診断データ計算機は：所定のサービスを提供する会社の計算機である、サービス提供会社用計算機に、前記要因分析処理後のデータ、又は前記要因分析処理の結果に基づいた前記エッジデバイスの異常の要因である部品および該部品の交換日程を特定するデータ、を送信する、分散システム。

＜＜視点８＞＞
自動稼働可能な移動体又は設備であるエッジデバイスと、所定のサービスを提供する会社の計算機である、サービス提供会社用計算機と、分析アウトソーシング計算機と、を有する分散システムであって、前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は作動機構を制御するエッジ内コントローラと、を有し、前記分析アウトソーシング計算機は：前記エッジ内コントローラの状態に基づいた、前記所定のサービスに関連した分析処理である、サービス関連分析処理を行い、前記サービス関連分析処理で得られたサービス関連分析後データを、前記サービス提供会社用計算機に送信する、分散システム。

＜＜視点９＞＞
視点８記載の分散システムであって、前記所定のサービスを提供する会社は、前記エッジデバイス、又は前記エッジデバイスの構成物に関して、設計又は製造を行わない会社である、分散システム。

＜＜視点１０＞＞
視点８記載の分散システムであって、前記所定のサービスは、前記エッジデバイスの修理サービスであり、前記サービス関連分析処理は、前記エッジ内コントローラの所定の内部状態の要因を特定する処理であり、前記サービス関連分析処理後データは、前記要因を解消する修理情報を生成する処理である、分散システム。

＜＜視点１１＞＞
視点８記載の分散システムであって、前記所定のサービスは、前記エッジデバイスが関連する保険サービスであり、前記サービス関連分析後データは、前記エッジデバイスの異常状態の発生頻度の情報を含む、分散システム。

＜＜視点１２＞＞
自動稼働可能な移動体又は設備であるエッジデバイスと、診断データ管理計算機と、分析アウトソーシング計算機と、エッジデータ配信会社用計算機と、所定のサービスを提供する会社の計算機である、サービス提供会社用計算機と、を有する分散システムであって、前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は作動機構を制御するエッジ内コントローラと、を有し、前記診断データ管理計算機は：前記エッジ内コントローラ内の状態を示す診断データを受信し、前記診断データを、前記エッジデータ配信会社用計算機に送信し、第１のスケジュールにて、前記診断データを、前記分析アウトソーシング計算機に送信し、前記エッジデータ配信会社用計算機は：前記診断データ管理計算機から、前記診断データを受信し、前記診断データを記憶リソースに格納し、前記第１のスケジュールよりも長いインターバルを持つ第２のスケジュールに従って、前記記憶リソースに格納した前記診断データを、加工処理し、加工後の前記診断データを、前記サービス提供会社用計算機に送信し、前記分析アウトソーシング計算機は：前記エッジ内コントローラの状態に基づいた、前記所定のサービスに関連した分析処理である、サービス関連分析処理を行い、前記サービス関連分析処理で得られたサービス関連分析後データを、前記サービス提供会社用計算機に送信する、分散システム。

＜＜視点１３＞＞
視点１２記載の分散システムであって、前記分析アウトソーシング計算機は、前記診断データ管理計算機と同じデータセンタ、又は同じ会社が有する、分散システム。

＜＜視点１４＞＞
自動稼働可能な移動体又は設備であるエッジデバイスと、診断データ計算機と、前記エッジデバイスの製造会社が有する計算機である、製造会社用計算機と、を有する分散システムであって、前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は前記作動機構を制御するエッジ内コントローラと、を有し、前記診断データ計算機は：前記エッジ内コントローラ内の内部状態を示す診断データを受信し、前記診断データ、又は加工後の前記診断データを、他の計算機に送信する、分散システム。

エッジデバイス・・・１２
エッジ内コントローラ・・・１０
ＥＣＴＬ診断データ・・・Ｄ１１
診断データ管理クラウド・・・２６
エッジデバイス製造会社計算機・・・２１
エッジデータ配信会社クラウド・・・２４
分析アウトソーシングクラウド・・・２７
データ活用層・・・３１
診断データクラウド・・・３２。

Claims (14)

1. 自動稼働可能な移動体又は設備であるエッジデバイスと、
   診断データ計算機と、
   前記エッジデバイスの製造会社が有する計算機である、製造会社用計算機と、
   を有する分散システムであって、
   前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は前記作動機構を制御するエッジ内コントローラと、を有し、
   前記診断データ計算機は：
   前記エッジ内コントローラ内の内部状態を示す診断データを受信し、
   前記診断データに基づいて、前記エッジ内コントローラ内の状態の要因分析処理を行い、
   前記製造会社用計算機に、前記要因分析処理後データ、又は前記要因分析処理の結果に基づいた前記エッジデバイスの改善データを送信する、
   分散システム。
2. 請求項１記載の分散システムであって、
   前記診断データ計算機は、前記エッジデバイスで発生する状態の因果関係を格納した分析ルールを記憶リソースに格納し、
   前記診断データ計算機は、前記要因分析処理において、前記分析ルールを参照する、
   分散システム。
3. 請求項１記載の分散システムであって、
   前記診断データ計算機が前記製造会社用計算機に前記改善データを送る場合、前記改善データは、前記エッジデバイスの次世代の設計データである、
   分散システム。
4. 請求項１記載の分散システムであって、
   前記診断データ計算機が前記製造会社用計算機に前記改善データを送る場合、前記改善データは、前記エッジ内コントローラの改善データであり、
   前記製造会社用計算機は、改善データを、前記エッジデバイスに送信する、
   分散システム。
5. 請求項４記載の分散システムであって、
   前記分散システムは、前記製造会社用計算機から前記改善データを受信して、前記エッジデバイスへ送信するエッジデータ配信会社用計算機を有し、
   前記エッジデータ配信会社用計算機は：
   前記診断データ計算機から、前記診断データを受信し、
   前記診断データを記憶リソースに格納し、
   所定のスケジュールに従って、前記記憶リソースに格納した前記診断データを、加工処理し、
   加工後の前記診断データを、所定のサービスを提供する会社の計算機である、サービス提供会社用計算機に送信する、
   分散システム。
6. 請求項１記載の分散システムであって、
   前記診断データ計算機は：
   所定のサービスを提供する会社の計算機である、サービス提供会社用計算機に、前記要因分析処理後のデータ、又は前記要因分析処理の結果に基づいた前記エッジデバイスの異常の要因を特定するデータ、を送信する、
   分散システム。
7. 請求項１記載の分散システムであって、
   前記診断データ計算機は：
   所定のサービスを提供する会社の計算機である、サービス提供会社用計算機に、前記要因分析処理後のデータ、又は前記要因分析処理の結果に基づいた前記エッジデバイスの異常の要因である部品および該部品の交換日程を特定するデータ、を送信する、
   分散システム。
8. 自動稼働可能な移動体又は設備であるエッジデバイスと、
   所定のサービスを提供する会社の計算機である、サービス提供会社用計算機と、
   分析アウトソーシング計算機と、
   を有する分散システムであって、
   前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は作動機構を制御するエッジ内コントローラと、を有し、
   前記分析アウトソーシング計算機は：
   前記エッジ内コントローラの状態に基づいた、前記所定のサービスに関連した分析処理である、サービス関連分析処理を行い、
   前記サービス関連分析処理で得られたサービス関連分析処理後データを、前記サービス提供会社用計算機に送信する、
   分散システム。
9. 請求項８記載の分散システムであって、
   前記所定のサービスを提供する会社は、前記エッジデバイス、又は前記エッジデバイスの構成物に関して、設計又は製造を行わない会社である、
   分散システム。
10. 請求項８記載の分散システムであって、
    前記所定のサービスは、前記エッジデバイスの修理サービスであり、
    前記サービス関連分析処理は、前記エッジ内コントローラの所定の内部状態の要因を特定する処理であり、
    前記サービス関連分析処理後データは、前記要因を解消する修理情報を生成する処理である、
    分散システム。
11. 請求項８記載の分散システムであって、
    前記所定のサービスは、前記エッジデバイスが関連する保険サービスであり、
    前記サービス関連分析処理後データは、前記エッジデバイスの異常状態の発生頻度の情報を含む、
    分散システム。
12. 自動稼働可能な移動体又は設備であるエッジデバイスと、
    診断データ管理計算機と、
    分析アウトソーシング計算機と、
    エッジデータ配信会社用計算機と、
    所定のサービスを提供する会社の計算機である、サービス提供会社用計算機と、
    を有する分散システムであって、
    前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は作動機構を制御するエッジ内コントローラと、を有し、
    前記診断データ管理計算機は：
    前記エッジ内コントローラ内の状態を示す診断データを受信し、
    前記診断データを、前記エッジデータ配信会社用計算機に送信し、
    第１のスケジュールにて、前記診断データを、前記分析アウトソーシング計算機に送信し、
    前記エッジデータ配信会社用計算機は：
    前記診断データ管理計算機から、前記診断データを受信し、
    前記診断データを記憶リソースに格納し、
    前記第１のスケジュールよりも長いインターバルを持つ第２のスケジュールに従って、前記記憶リソースに格納した前記診断データを、加工処理し、
    加工後の前記診断データを、前記サービス提供会社用計算機に送信し、
    前記分析アウトソーシング計算機は：
    前記エッジ内コントローラの状態に基づいた、前記所定のサービスに関連した分析処理である、サービス関連分析処理を行い、
    前記サービス関連分析処理で得られたサービス関連分析後データを、前記サービス提供会社用計算機に送信する、
    分散システム。
13. 請求項１２記載の分散システムであって、
    前記分析アウトソーシング計算機は、前記診断データ管理計算機と同じデータセンタ、又は同じ会社が有する、
    分散システム。
14. 自動稼働可能な移動体又は設備であるエッジデバイスと、
    診断データ計算機と、
    前記エッジデバイスの製造会社が有する計算機である、製造会社用計算機と、
    を有する分散システムであって、
    前記エッジデバイスは、自動稼働するための移動機構又は作動機構と、前記移動機構又は前記作動機構を制御するエッジ内コントローラと、を有し、
    前記診断データ計算機は：
    前記エッジ内コントローラ内の内部状態を示す診断データを受信し、
    前記診断データ、又は加工後の前記診断データを、他の計算機に送信する、
    分散システム。

Images