JP2022040171A - モータ車両運転者支援システムに関する方法 - Google Patents

Abstract

【課題】車両のＥＣＵへのプログラムのインストールを安全に行うための方法を提供すること。【解決手段】前記複数のノードに、前記ＥＣＵの動作命令を示す初期プログラム又は更新プログラムを格納する工程であり、前記複数のノードの各々は、前記動作命令の異なるバージョンが記憶される複数のブロックを含む分散型のブロックチェーンを構築するように構成された、当該工程と；前記複数のノードに、前記ブロックチェーンのコピーを格納する工程と；前記ブロックチェーンのコピーが、各ノード間で同一であるかを検証する工程と；前記ノードの何れかで同一でないことが検出されたときに、当該コピーを欠陥コピーとしてインセキュアのフラグ立て、前記ネットワーク内において、前記欠陥コピーの使用を禁止し、前記欠陥コピーの前記ブロック内に含まれる前記動作命令の前記ＥＣＵへのインストールを禁止する工程と；を含む。【選択図】図６

Description

本発明は、運転者支援システムの動作をセキュア化する方法に関し、より具体的には、運転者支援システムの動作命令、及びその追跡可能性を変化からセキュア化する方法に関する。

事故が回避され、運転に関する法律が遵守されるために、車両を運転することは、運転者の集中を多くの場合長時間必要とする。運転者が集中を誤ると、事故のリスクの増加及び／又は法律の非遵守につながる。ますます、支援機能を実行することが可能な運転者支援システムが、運転者の車両（以下、「自車両」と称する）に装着されるようになっている。例えば、支援機能は、運転者から彼／彼女の運転責務のいくつかを解放することを含んでもよく、又はエラーが予測及び／若しくは回避され得るように、運転者のパフォーマンスを監視することを含んでもよい。

代替的に、支援機能は、運転者に通常利用可能ではないいくつかの付加的な機能を導入することができる。かかる付加的な機能は、運転者が、運転タスクをより容易に又は安全に実行することができるように、運転者が通常行われるよりも多くの情報を有することを可能にし得る。例えば、逆動時に運転者にビデオフィードを提供することができる後ろ向きのカメラは、かかる付加的な機能の一例を構成する。この実施例では、ビデオフィードは、運転者がより容易かつ安全に後ろ向き駐車することを可能にするが、実際には、必ずしも運転者のパフォーマンスを監視する、又は運転者の代わりにタスクを直接実行しているわけではない。

したがって、運転者支援システムは、自車両の運転者、彼／彼女の乗員、及び他の道路使用者のリスクを軽減する。最終的には、運転者支援機能は、自車両を運転するほとんどの又は全ての態様を制御することができる程度に開発されるであろう。この場合、運転者支援システムは、自律駆動システムである。

運転者支援システムは、例えば、自車両の速度を変更することによって、自車両の動作に能動的に介在することができる能動デバイスを含んでもよい。運転者支援システムは、代替的に又は付加的に、例えば、ユーザが通知に反応することができるように、特定の駆動状況を運転者に通知する、受動デバイスを含んでもよい。例えば、運転者支援システムは、自車両が路面標識を不意に越えて外れたとき、可聴信号を作成することができる。所与の自車両は、受動システム及び能動システムの両方を含んでもよい。

一般に、運転者支援システムは、少なくとも１つのセンサを含むことができる。特定のセンサは、自車両及び／又はその周囲を説明するパラメータを測定する。複数のセンサからのデータは、組み合わされ得る。かかるセンサ又は複数のセンサからのデータは、センサ測定値に基づいて結論を引き出すために処理される。運転者支援システムは、結論の結果に基づいて、自車両との相互作用、又は運転者との相互作用をトリガし得る。自律駆動システムの場合、実質的に全ての駆動機能は、システムによって制御される。

運転者支援システム及び自律駆動システム内で使用される潜在的センサの実施例は、ＲＡＤＡＲシステム、ＬＩＤＡＲシステム、複数のカメラ又はカメラ、車両間通信（又は、車両対車両通信）、及び車両対インフラストラクチャ通信を含む。

運転者支援システムは、安全駆動又は運転者の監視の様々な異なる態様を制御するために使用され得る。例えば、ＡＣＣ（「適応クルーズ制御、Adaptive Cruise Control、ＡＣＣ」）は、自車両と道路上のすぐ前の車両との間の距離を監視するために、ＲＡＤＡＲ又はＬＩＤＡＲシステムを使用してもよい。かかるセンサは、前方の車両までの距離を判定することができる。運転者支援システムはまた、自車両の速度を知り、かつ制御することができる。運転者支援システムは、前方車両に対して予め定義された安全条件を維持するために、自車両の速度を制御し得る。例えば、運転者支援システムは、自車両と前方車両との間の特定の距離を維持するために、速度を制御し得る。代替的に、運転者支援システムは、点を通過する前方車両と同じ点を通過する自車両との間の所定の時間を維持するために、速度を制御し得る。

自車両の周囲を監視して、自車両が走行している道路上又は道路の周りの他の車両及び実体の位置を特定する、既存の運転支援システムが存在する。周囲を監視することによって、かかる運転者支援システムは、自車両の状況認識を維持することができる。この状況認識は、ユーザに潜在的な危険を通知するために使用することができる。例えば、第２の車両が死角にあるとき、自車両が車線変更すること、又は、自車両の経路への第２の車両の割り込みを検出することが、運転者に通知されてもよい。状況認識はまた、例えば、ＡＣＣシステムへの入力として使用されてもよい。

一般に、運転者支援システムの動作は、運転者支援システムの一部を形成する少なくとも１組の動作命令によって指示される。動作命令は、例えば、マシンコード、ソフトウェア、コンパイルされた実行テーブル、ライブラリ、ファームウェア、及び当業者が理解する他の実施例を含み得る。

特定の運転者支援システムの動作命令は、更新することができる。更新は、パッチを適用することと、機能を追加することと、及び単に初めての動作命令をインストールすることと、を含んでもよい。動作命令を更新することは、動作命令を運転者支援システム（又はその一部）上に「点滅させること」に対応してもよい。運転者支援システムの動作命令を更新することは、安全かつ信頼性の高い方式で追跡可能であることが重要である。この文書の残りの部分では、動作命令は、概して、ＥＣＵの動作を指示するものとして説明される。しかしながら、動作命令は、運転者支援システムの他の要素、例えば、センサの動作を指示することができることが理解されるであろう。

自律駆動システムは、概して、より包括的な運転者支援システムに対応し得ることが理解されるであろう。このため、以下の考察は、運転者支援システム上に焦点を合わせながら、本発明はまた、自律駆動システムにも容易に適用可能であることを意図する。

運転者支援システムは、様々な安全性の重要な機能（車両の運転者及び他の運転者両方の安全性）を実行することができるので、運転者支援システム及びその動作との不正干渉が検出され、必要に応じて作用されることが重要である。

運転者支援システムの動作は、動作命令によって指示されるので、運転者支援システムの安全性の重要な要素、及びその安全かつ信頼性の高い動作は、動作命令をセキュア化することによって達成される。

一般に、運転者支援システムは、電子制御ユニット（electronic control unit、ＥＣＵ）を含む。ＥＣＵは、動作命令によりタスクを実行することができる実用的なコンピューティングデバイスであり、これは、「運転者支援システムの脳」と考えることができる。動作命令は、概してＥＣＵ上に記憶され、ソフトウェア及びファームウェアの両方を含み得る。ソフトウェアは、コンパイルされたマシンコードであってもよく、ソースコードであってもよく、又は、ジャストインタイム（Just In Time、ＪＩＴ）をコンパイルするコードであってもよい。キー機構は、動作命令がＥＣＵの動作、したがって運転者支援システムの少なくとも一部を指示することである。単一の自車両は、その中に設置された複数のＥＣＵを有してもよい。それに対応して、単一の運転者支援システムは、複数の組の動作命令を使用することができる。

動作命令は、例えば、ＥＣＵの機能を増大又は変更するために更新されてもよい。更新は、例えば、ネットワークへの無線接続を介して、最終的には更新のソースから、「地上波で」行われてもよい。更新は、運転者支援システムに無線で送信され、その時点で動作命令が更新される。代替的に、更新は、運転者支援システムへの物理的接続にわたって実行されてもよい。物理的接続更新は、例えば、自車両が使用可能であるときに実行されてもよい。

いずれの場合も、運転者支援システムに関する動作命令への更新は、信頼されたソースから来るものとして検証され、動作命令は、改ざんされていない、危殆化されていない、又は偶発的に変更されていないことが重要である。動作命令が検証されていない場合、動作命令に望ましくない変更が生じる可能性がある。動作命令に対するかかる望ましくない変化は、悪意のある又は偶発的であり得る。その原因に関わらず、動作命令へのかかる変更は、深刻な安全リスクを提示し得る、運転者支援システムの不正確な、信頼できない、又は失敗した動作をもたらし得る。

動作命令への悪意のある変更の場合、悪意のある当事者は、動作命令を変更してもよく、そのため、実際には、運転者支援システムは適当に動作せず、運転者支援システムの動作は安全でないか、又は制御されていないとき、運転者に、運転者支援システムが適当に動作しているように見える。このため、運転者支援システム上の悪意のある攻撃に抗して保護することが特に重要である。

要約すると、動作命令への変更は、権限のある当事者によってのみ行われ得ることが重要である。

上記の説明は、動作命令に対する更新に焦点を当てているが、動作命令の初期のインストールを検証することも重要である。かかる初期設置は、運転者支援システムの製造時に発生し得る。

本発明の目的は、運転者支援システムの動作をセキュア化する方法を提供することであり、これらの問題のいくつか又は全てに対処しようとするものである。

第１の態様によれば、モータ車両の運転者支援システムに関する動作命令をセキュア化する方法が提供され、本方法は、ａ）複数のブロックを含む分散型ブロックチェーンを実装することであって、ブロックチェーンのコピーが複数のノードの各々上に記憶され、各ブロックが、動作命令の異なるバージョンを含む、実装することと、ｂ）ブロックチェーンのコピーが同一であることをチェックすることを含む、検証ルーチンを実行することと、ブロックチェーンの故障コピーが同一ではない場合、故障コピーをインセキュアとしてフラグ立てすることと、故障コピーの使用を防止し、このため、故障コピーのブロック内に含まれる動作命令のインストールを防止することと、を含む。

好ましくは、方法は、新規ブロックを各ノード上のブロックチェーンのコピーに追加することを含む、バージョン追加ルーチンを更に含み、新規ブロックが、動作命令の更新されたバージョンを含む。

好都合には、運転者支援システムは、安全電子制御ユニット（「ＥＣＵ」）を含み、動作命令は、当該安全ＥＣＵの動作を指示する。

有利には、本方法は、インストールブロックからの動作命令のインストールバージョンを運転者支援システム上にインストールすることを含む、ＥＣＵ更新ルーチンを更に含み、インストールブロックは、故障コピー内に含まれない。

好ましくは、本方法は、インストールブロックの全体をＥＣＵにコピーすることを更に含む。

好都合には、各ブロックは、動作命令のそれぞれのバージョンを含む入力データに対して計算された、検証されたハッシュ値を含む。

有利には、本方法は、動作命令のインストールバージョンの検証されたハッシュ値を、安全ＥＣＵ上の検証されたハッシュ記憶手段にコピーすることを更に含む。

好ましくは、検証されたハッシュ値は、インストールブロックのインストールブロックメタデータの少なくとも一部分を含む入力データに対して計算される。

好都合には、ブロックチェーンは、アクセサリ制御される。

有利には、ブロックチェーンは、暗号化される。

第２の態様によれば、モータ車両用の運転者支援システムに関する動作命令を追跡する方法が提供され、本方法は、ａ）複数のブロックを含む分散型ブロックチェーンを実装することであって、ブロックチェーンのコピーが複数のノードの各々上に記憶され、各ブロックが、少なくとも１つのインストール記録を含み、各インストール記録が、少なくとも運転者支援システム固有識別子及び動作命令識別子を含む、実装することと、ｂ）ブロックチェーンの各ブロックが、ブロックチェーンのコピーにわたって同一であることをチェックすることを含む検証ルーチンを実行することと、ブロックチェーンの故障コピーが同一ではない場合、故障コピーをインセキュアとしてフラグ立てすることと、故障コピーの使用を防止することによって、故障コピーのブロック内に含まれるインストール記録の使用を防止することと、を含む。

好ましくは、当該動作命令識別子は、当該インストールされた動作命令のバージョン識別子を含む。

好都合には、運転者支援システムは、安全電子制御ユニット（「ＥＣＵ」）を含み、インストールされた動作命令は、当該安全ＥＣＵの動作を指示する。

有利には、本方法は、ｃ）故障コピーではないブロックチェーンのコピーがクエリされて、インストールされた動作命令のより最近のバージョンがブロックチェーンのコピー内で利用可能であるかどうかを識別することを許容することと、より最近のバージョンが利用可能である場合、動作命令の当該より最近のバージョンを運転者支援システム上にインストールすることと、を更に含む。

好ましくは、少なくとも１つのインストール記録は、運転命令識別子に対応する動作命令が、運転者支援システム固有識別子に対応する運転者支援システム上にインストールされたインストール時間、運転者支援システム固有識別子に対応する運転者支援システムの動作の試験結果、のうちの少なくとも１つを含む。

本発明がより容易に理解され得、その更なる特徴が理解され得るように、本発明の実施形態は、添付図面を参照して、例として説明されるであろう。
運転者支援システムの一実施例を含む、自車両の概略図を示す。 運転者支援システム内に含まれる安全電子制御ユニット（ＥＣＵ）の概略図を示す。 図２の安全ＥＣＵを含む、自車両の概略図を示す。 自車両が接続され得る、複数のノードを有するネットワークの概略図を示す。 ネットワークの１つのノードの概略図を示す。 車両が接続し得る、分散型ブロックチェーンの概略図を示す。 車両が切断されたノードと接続することができる、分散型ブロックチェーンの概略図を示す。 本発明の第１の態様による、ノード上のブロックチェーンのコピーの概略図を示す。 本発明の第２の態様による、ノード上のブロックチェーンのコピーの概略図を示す。

ここで図１をより詳細に考察すると、自車両２内にインストールされた例示的な運転者支援システム１の例解された概略表現である（車両の配向を示すために、車両の一方のパネルのみが、図１に示される）。運転者支援システム１は、自車両２上の適切な位置に取り付けられた、多数の異なるタイプのセンサを備える。具体的には、示されるシステム１は、車両２のそれぞれのフロント角に取り付けられた一対の発散型かつ外向きに方向付けられた中央範囲レーダー（「mid-range radar、ＭＲＲ」）センサ３と、車両のそれぞれの後角に取り付けられた、同様の一対の発散型かつ外向きに方向付けられた多機能レーダーセンサ４と、車両２の前方で中央に取り付けられた前方に方向付けられた長範囲レーダー（「long-range radar、ＬＲＲ」）センサ５と、例えば、車両のフロントガラスの上縁部の領域内に装着され得る、ステレオビジョンシステム（「stereo vision system、ＳＶＳ」）７の一部を形成する一対の概して前方に方向付けられた光学センサ６（カメラ）と、を含む。様々なセンサ３～６は、車両内の好都合な場所に取り付けられた統合電子制御ユニット（ＥＣＵ）８の形態で典型的に提供される、中央電子制御システムに動作可能に接続される。示された特定の構成では、前側及び後側ＭＲＲセンサ３、４は、従来のコントローラエリアネットワーク（「Controller Area Network、ＣＡＮ」）バス９を介してＥＣＵ８に接続され、ＬＲＲセンサ５及びＳＶＳ７のセンサは、より速いＦｌｅｘＲａｙシリアルバス９、又は既知のそのようなタイプのものを介してＥＣＵ８に接続される。

総じて、ＥＣＵ８の制御下で、様々なセンサ３～６は、例えば、死角モニタリング、適応クルーズ制御、衝突防止支援、レーン離脱保護、及び後方衝突緩和などの様々な異なるタイプの運転者支援機能を提供するために使用され得る。同様のセンサは、自律駆動システム内で使用することができる。

システムはまた、少なくとも１つの二次ＥＣＵを含んでもよい。二次ＥＣＵは、ＣＡＮバス又はＦｌｅｘＲａｙシリアルバス９を介してＥＣＵ８と通信してもよい。二次ＥＣＵは、以下でより詳細に考察される。

本発明による装置の一例が、図２に示される。システムは、図１に示されるタイプの電子制御ユニット（ＥＣＵ）８を含む。ＥＣＵは、いわゆる安全又は主ＥＣＵである。安全ＥＣＵ８は、自車両２内の自車両通信ネットワーク９に接続される。自車両通信ネットワーク９は、例えば、ＣＡＮバス又はＦｌｅｘＲａｙシステムであってもよい。特定のＥＣＵ８は、同じタイプである必要はない、２つ以上のかかるネットワークに接続されてもよい。安全ＥＣＵ８は、自車両通信ネットワーク９を介して、自車両内の他のＥＣＵと通信してもよい。

安全ＥＣＵ８は、少なくとも１つのセンサ１０に接続される。図２に示される実施例では、３つのセンサ１０が、安全ＥＣＵ８に接続されるが、このセンサの数は、限定的であると見なされるべきではない。センサ１０の各々の安全ＥＣＵ８への接続は、有線又は無線であってもよい。センサ接続はまた、自車両通信ネットワーク９を介してもよい。各センサ１０と安全ＥＣＵ８との間の接続は、双方向接続であってもよく、すなわち、安全ＥＣＵ８は、センサ１０からデータを受信してもよく、安全ＥＣＵ８は、センサ１０にデータ及び／又はコマンドを送信してもよい。センサ１０は、自車両自体の状態及び／又は周囲環境の状態に関する情報を提供することができる。センサ１０はまた、いくつかのデータ低減能力を提供してもよく、すなわち、センサ１０がセンサ１０によって実行された生測定値を安全ＥＣＵ８に送るのではなく（又は加えて）、判定されたパラメータは、センサ１０において計算され、センサ１０から安全ＥＣＵ８に送信されてもよい。

安全ＥＣＵ８はまた、２ウェイ無線通信リンク１１にわたって、インターネットと無線通信することが可能である。インターネットは、安全ＥＣＵ８が処理タスクをオフロードし得る、クラウドコンピューティング能力１２を含む。無線通信リンク１１は、例えば、携帯電話通信ネットワークへの接続を含み得る。安全ＥＣＵ８は、無線通信リンク１１にわたってクラウド１２に処理タスクを送信してもよく、処理タスクの結果が無線通信リンク１１にわたって安全ＥＣＵ８に返送される前に、処理タスクがクラウド１２内で実行される。

無線通信リンク１１はまた、ＥＣＵ８に直ちに利用できないデータへのアクセスを提供してもよい。かかるデータは、例えば、マップデータを含んでもよい。

安全ＥＣＵ８はまた、自車両２の外部の分散型機能１４へのアクセスを提供する、第２の通信リンク１３を有する。分散型機能は、車両対車両通信、及び／又は車両対インフラストラクチャ通信を含み得る。これらは、情報が自車両２と共有され得、並びに／又は、自車両２が第２の通信リンク１３にわたって情報を共有することができる、運転者支援機能及び／若しくは自律駆動機能を許容し得る。

図３は、自車両２の図を示す。自車両２は、安全ＥＣＵ８を含む。また自車両２には、２つの二次ＥＣＵ１５、１６が含まれる。安全ＥＣＵ８及び二次ＥＣＵ１５、１６は、車載通信ネットワーク１７を介して接続される。車載通信ネットワーク１７は、例えば、ＣＡＮバス、ＦｌｅｘＲａｙバス、ローカルインターコネクトネットワーク（Local Interconnect Network、ＬＩＮ）、又はイーサネットネットワークであってもよい。

自車両２はまた、ＥＣＵ８に動作可能に接続された無線通信送受信機１８を含む（その接続は図３には示されていない）。無線通信送受信機１８は、双方向無線通信リンク２０を介してネットワーク１９と無線通信するように構成される。ネットワーク１９は、少なくとも１つの記憶場所２１内に、動作命令の記憶、及び／又は動作命令更新を含む。

図４は、ネットワーク１９の概略図を示す。ネットワーク１９は、分散化されたブロックチェーンを含む。分散化されたブロックチェーンは、複数のノード２２を含む。分散化されたブロックチェーンの各ノード２２は、ブロックチェーンのコピーを含有する（当該コピーのいずれかへの変化がない場合）。換言すれば、ノードの各々は、ブロックチェーンのコピーを有し、共にノードは、分散型ブロックチェーンを形成する。ブロックチェーンは、許可され得る。すなわち、ブロックチェーンへの参加は、制御される（すなわち、ブロックチェーンのコピーを有するノード）。換言すれば、潜在的ノードは、分散型ブロックチェーン内に参加するための許可を必要とする。

ノード２２は、複数の接続２２Ａを介して互いに相互接続される。各ノード２２が、他のノード２２ごとに直接接続される必要はない。同様に、図４に示される特定の接続２２Ａは、限定的であると見なされるべきではない。ノード２２は、例えば、ピア対ピアネットワークの様式で共に接続されてもよく、このことは、当業者は、個々の接続２２Ａに関して多くの異なる可能性を含むことを理解するであろう。個々の接続２２Ａは、時間の関数として行われてもよいか、又は切断されてもよい。接続２２Ａは、ローカルエリアネットワーク又はワイドエリアネットワークにわたって行われてもよい。接続２２Ａは、インターネットにわたって行われてもよい。

いずれの場合にも、ノード２２が形成される物理サーバは、互いに物理的に遠隔に配置されてもよい。それは、異なる、異種の、物理的場所である。異なる場所は、数マイル離れていても、及び／又は異なる国であってもよい。これにより、２つ以上のノードへの同時の物理的アクセス（又は全てのノードへのアクセス）を得ることは、攻撃者予備軍にとって非常に困難とする。ノード２２は、単一の当事者によって動作及び制御される異なる施設内に配置されてもよい。例えば、ノード２２は、別個の生産及び開発施設内に配置されてもよい。当事者プロバイダの顧客は、顧客にローカルに配置されるノードを有してもよい。

図５は、分散化されたブロックチェーンの単一ノード２２の概略図を示す。ノード２２は、４つのブロック２３を含む、ブロックチェーンのコピーを含む。共にブロック２３は、ブロックチェーンのローカルコピー（ノード２２に対してローカル）を形成する。各ブロック２３は、データ区分２３Ａを含む。各ブロックはまた、ブロックメタデータ２３Ｂを含む。ブロックメタデータ２３Ｂは、ブロックチェーンの機能が達成されることを可能にする。実際には、ブロック２３は、線状シーケンスで比ゆ的に共に相互に連鎖している。鎖効果は、以下に簡単に説明されるハッシュ関数によって形成されるハッシュ値に依存する。

一般に、ハッシュ関数（又はハッシュアルゴリズム）は、所与の入力データが、当該入力データのハッシュ値（代替的にハッシュコード、ダイジェスト、又はハッシュとして既知）を生成する計算ルーチンである。ハッシュ関数は、任意のサイズの入力データを固定サイズ（ハッシュ値）のビットストリングにマッピングする数学的アルゴリズムである。ハッシュ関数自体が既知であり、ここでは詳細に説明されない。例えば、第１の入力データに関して、ハッシュ関数は、第１のハッシュ値を生成する。第１の入力データが、ごくわずかな量だけ変更される場合、ハッシュ関数が（入力データ上で再び実行されるとき）第１のハッシュ値とは異なる第２のハッシュ値を生成する確率が非常に高い。このため、同じハッシュ関数によって生成された入力データの断片のハッシュ値を２つの異なる時間で比較することにより、入力データが変更されたか否かを、少量であっても、極めて高い確実性を伴って判定することが可能である。入力データの基礎的な意味又はコンテンツは、ハッシュ関数の目的に無関係であることに留意されたい。ハッシュ関数は、入力データ上でバイナリレベルで動作する。

一例として、ハッシュ関数は、セキュアハッシュアルゴリズム、第２世代である、ＳＨＡ－２アルゴリズムであってもよい。記載される実施形態内で使用される特定のアルゴリズムは、２５６ビットハッシュ値を生成し、ＳＨＡ－２５６として既知である。しかしながら、本発明は、ＳＨＡ－２５６又はＳＨＡ－２アルゴリズムに限定されるべきではない。本開示を考慮すると、一般にハッシュ関数が本発明で使用するのに好適であることは、当業者には明らかであろう。

ここで本発明のブロックチェーンに戻ると、所与のブロック２３のためのブロックメタデータ２３Ｂは、ブロックチェーン内の先行するブロック２３のブロックハッシュ値を含む。以前のブロック２３のデータになされた任意の変更は、そのブロックのブロックハッシュ値への変更を必要とし、この変更は、（変更が検出されない場合）、以下のブロックにおいて再計算及び変更されなければならない。次に、これは、次のブロックのブロックハッシュ値を変更し、これは、データへの変更が検出されない場合にも、再計算されなければならない。これは、ブロックのデータコンテンツが先行するブロックのデータコンテンツに依存するデイジーチェーン効果を起こす。

一般に、単一のハッシュ値を計算することは、通常、比較的計算的に安価である。しかしながら、ブロックハッシュ値の許容値は、制約される。一般に、所定の変更がハッシュアルゴリズムへの入力データに行われるときにハッシュ値への変更を予測することは不可能であるため、制約を満たすハッシュ値を見つける唯一の方法は、総当たりによってである。すなわち、入力データを変更すること、ハッシュ値を計算すること、ハッシュ値が制約を満たすかどうかを評価すること、及びそれがない場合、繰り返すこと、である。

ブロックチェーン制約が満たされ得るように、ブロックハッシュ値を変更することを可能にするために、ブロックが作成されるとき、ハッシュ関数への入力データは、変更することができなければならない。これを達成するために、「ナンス」と呼ばれるブロックメタデータ２３Ｂの一部が、変更され得る。ナンスが変更され得るため、（以下のブロックに記憶されるような）そのブロックのブロックハッシュ値もまた変化する。ナンスは、繰り返し変更され、ブロックハッシュ値は、ブロックチェーンに対して設定された制約（複数可）を満たすブロックハッシュ値が達成されるまで、各変更後に再計算される。ハッシュアルゴリズムのナンス及び動作のこの繰り返される変更は、例えば、制約を満たすブロックハッシュ値が見つかることが予想され得る前に、膨大な試行を必要とし得る。有効なブロックハッシュ値を見つける前に必要とされる試みの数は、ブロックハッシュ値を決定することが、計算コストの高い可能性があり、したがって、実際に達成するのに時間がかかることを意味する。ブロックハッシュ値を見つける計算的な困難は、ブロックチェーンに対する制約（複数可）の厳密性を含む、多数の因子に依存する。

ブロックハッシュ値及びナンスに加えて、他の情報もまた、ブロックメタデータ２３Ｂ内に含まれてもよい。

悪意のある当事者がブロックのデータコンテンツを変更する場合、チェーン内の全ての後続のブロック内のブロックハッシュ値は、対応する先行ブロックのデータコンテンツに一致しないことになり、変化が、検出され得る。データへの変更を行い、それが未検出のままであるようにするために、悪意のある当事者は、変更を行い、次いで、変更されたブロック及び全ての後続のブロックについて有効なブロックハッシュ値（すなわち、制約を満たす）を再計算する必要がある。好適に選択された制約条件では、これは、非常に計算コストが高く、時間を要する場合がある。このため、ブロックチェーンのデータコンテンツがセキュア化され、ブロックチェーンへの変化が、検出され得る。

ブロックチェーンデータの各ローカルコピーは、ブロックチェーンセキュリティチェックにおいて検証されてもよく、ここでブロックチェーンメタデータ２３Ｂ内のブロックハッシュ値が、ブロックのデータについて計算された試験ハッシュ値に対してチェックされる。いずれかの変化（悪意のある又は偶発的）がブロックチェーンコピー内で行われる場合、変化の発生が認められ、ブロックチェーンコピーは、変更されたものとして識別される。このブロックチェーンセキュリティチェックは、単一ノード内で行うことができ、ノードの外部の接続は必要ではない。このため、このプロセスは、ノード内セキュリティモードと呼ばれ得る。各ノードは、ブロックチェーンコピー上で動作するかかるブロックチェーンセキュリティチェックを実行するように構成される。ブロックチェーンセキュリティチェックは、各ノードによって定期的に実行されてもよい。ブロックチェーンセキュリティチェックは、例えば、読み取り要求が当該ノードに行われるときはいつでも実行されてもよい。ブロックチェーンセキュリティチェックは、新規ブロックがブロックチェーンのコピーに追加される前に実行されてもよい。

図６は、ノード２２にわたって分散されたブロックチェーンデータのコピーのクロスチェックの概略図である。これは、ブロックチェーンのコピーが同一である分散型ブロックチェーンの検証ルーチンを形成する。検証ルーチンは、クロスチェック２４を含み、そのうちのいくつかが、矢印によって図６に示される。各クロスチェックは、ブロックの比較を含み得る。全てのブロックの比較は、それらのブロックのブロックハッシュ値の比較を含み得る。危殆化されたノード上のブロックチェーンのコピーが変更される場合（無許可の当事者がブロックチェーンセキュリティチェックが変更を認めないように行う際の、ブロックハッシュ値の修正を含む、上記参照）、コピーは、故障コピーとしてフラグを立てられる。故障コピーのデータへの変更は、悪意のある又は偶発的であり得る。検証ルーチンは、ブロックチェーンの故障コピーと他のノードのうちの少なくとも１つ上の変更されていないコピーとの間で、不一致が認められることを可能にする。

ノード／ブロックチェーンコピーが、故障コピーとして識別されるとき、その故障コピー内のデータの使用がブロックされる。検証ルーチンを使用すると、変更が特定されることなく、ブロックチェーンのコピー内のデータへの変更が不可能である。このため、ブロックチェーンのブロック２３のデータ区分２３Ａ内のデータは、変更からセキュア化され、気付かずに進むことができない。この検証ルーチンは、分散型ブロックチェーンのノード間で発生する。このため、このプロセスは、ノード間セキュリティモードと呼ばれる。

検証ルーチンは、ノード間のコンセンサスが求められるコンセンサスプロトコルを実装してもよい。コンセンサスプロトコルは、例えば、様々なカテゴリ、例えば、
・ＰｏＷ、Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ－プルーフオブワーク、
・ＰｏＳ、Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ－プルーフオブステーク、
・ＰｏＥＴ、Ｐｒｏｏｆ ｏｆ Ｅｌａｐｓｅｄ Ｔｉｍｅ－プルーフオブイラプスタイム、
・ＢＦＴ、Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ－ビザンチンフォルトトーレランス及びその変異体、に分類することができる。例えば、プラクティカルビザンチンフォルトトーレランスアルゴリズム（Practical Byzantine Fault Tolerance algorithm、ＰＢＦＴ）、シーブコンセンサスプロトコル、又はクロスフォルトトーレランス（Cross-Fault Tolerance、ＸＦＴ）、
・Ｆｅｄｅｒａｔｅｄ ＢＦＴ、例えば、リップルコンセンサスプロトコルアルゴリズム又はステラ－コンセンサスプロトコルである。

コンセンサスプロトコルは、故障の２つのカテゴリ、フェイルストップ故障、及びいわゆる「ビザンチン」タイプの故障を許容することができる。フェイルストップ故障は、ノード故障によって引き起こされる。例えば、コンセンサスプロトコルに続いて停止するノードは、フェイルストップ故障である。ビザンチンタイプの故障は、不規則にふるまうノード又は複数のノードによって引き起こされる故障である。ビザンチンタイプの故障は、危殆化されているノードによって引き起こされ得る。かかる危殆化されたノードは、分配されたブロックチェーンノードの残りに対する意図的に誤った又はまぎらわしい情報を提供し得る。コンセンサスプロトコルは、フェイルストップ及び／又はビザンチンタイプの故障の存在下でノード間のコンセンサスに到達することができる。

図７は、ブロックチェーンの他のノード２２から切断された、切断ノード２５の概略図である。切断ノードと他のノード２２とをネットワーク上で以前相互接続した破壊ネットワーク接続２６が、破壊されている。この切断は、一時的であってもよい。破壊ネットワーク接続２６が切断されたままである間、切断されたノード２５上のブロックチェーンのコピーと他のノード２２にわたって分散されたブロックチェーンのコピーとのクロスチェックは、不可能である。ネットワーク接続のうちの少なくとも１つが復元されるとき、上記のように、検証ルーチンは、再開することができる。

図８は、本発明の第１の実施形態によるブロックチェーンの３つのブロック２３を示す。一般に、各ブロック２３は、動作命令の検証されたバージョンと、動作命令の当該検証されたバージョンのための検証されたハッシュ値と、を含む。例えば、図８に示された実施形態では、各データ区分２３Ａは、運転者支援システムの安全ＥＣＵ８のための動作命令２７の検証されたバージョンを含む。各データ区分２３Ａはまた、検証された、信頼された、動作命令２７のコピーについて計算された、検証されたハッシュ値２８を含む。検証されたハッシュ値２８は、データ区分２３Ａ内に記憶された、検証された動作命令２７に対応するデータ上でハッシュ関数を実行する結果である。検証されたハッシュ値２８は、元来動作命令２７の対応するバージョンを作成した動作命令の信頼できるソースによって形成されてもよい。データ区分２３Ａ内に記憶された動作命令２７に対応するデータが変更される場合、その変更されたデータについて計算された試験ハッシュ値は、検証されたハッシュ値２８と同一ではない。

代替的に、動作命令に関して検証されたハッシュ値２８は、ブロックメタデータ２３Ｂ内に含まれてもよい。検証されたハッシュ値は、ブロックメタデータの少なくとも一部分を含み得るか、又はその部分から形成されてもよい。例えば、動作命令に関して検証されたハッシュ値は、その中に当該動作命令を含むブロックについて、対応するブロックメタデータ２３Ｂ内に記憶されたブロックハッシュ値に等しくてもよい。

第１の実施形態による分散型ブロックチェーンは、動作命令をセキュア化するために、ブロックチェーンセキュリティチェック（ノード内ベース）及び検証ルーチン（ノード間ベース）の両方を実施する。

このようにして、検証された動作命令のバージョンのセキュアコピーが、ブロックチェーン内に維持される。動作命令のセキュリティは、ノード間クロスチェック、並びにブロックチェーンの固有の機能（すなわち、ブロックハッシュ値を使用）によって維持される。換言すれば、分散型ブロックチェーンは、動作命令のセキュアコピーの運転者支援システムへの供給を可能にする。

動作命令の検証されたバージョンが安全ＥＣＵ上にインストールされるとき、ＥＣＵ更新ルーチンが実行される。安全ＥＣＵ上にインストールされる動作命令のバージョンが識別され、これはインストールバージョンである。インストールバージョンは、ブロックチェーンのインストールブロック内に含まれる。分散型ブロックチェーンのノード上のインストールバージョンのコピーが、識別される。

インストールブロックが、ブロックチェーンの故障コピー内に含まれているか否かをチェックすることができる。インストールブロックが故障コピー内に含まれていない場合、インストールバージョンは、インストールブロックから安全ＥＣＵ上にインストールされてもよい。

インストールコピーの検証されたハッシュ値は、インストールブロックのブロックメタデータを含む、入力データに関して計算され得る。インストールコピーの検証されたハッシュ値は、インストールブロックのブロックメタデータの少なくとも一部分を含む、入力データに関して計算され得る。インストールコピーが安全ＥＣＵ上にインストールされるとき、検証されたハッシュ値は、安全ＥＣＵにコピーされ得る。例えば、検証されたハッシュ値は、安全ＥＣＵ上の検証されたハッシュ記憶手段にコピーされてもよい。

更に、インストールブロックメタデータからの追加情報はまた、ＥＣＵ更新ルーチン中に安全ＥＣＵにコピーされてもよい。代替的に、インストールブロック（ブロックメタデータ及びデータ区分を含む）の全体は、ＥＣＵ更新ルーチン中に安全ＥＣＵにコピーされてもよい。これにより、ブロックチェーン内に記憶されたものと同じハッシュの値と比較される、インストールブロック全体のハッシュのチェックが可能になる。また、これにより、ＥＣＵ更新ルーチン中の動作命令のセキュリティのチェックが可能になる。

第１の実施形態では、動作命令２７の新規の又は更新されたバージョンが生成されるとき、新規ブロック２３が形成され、各ブロックチェーンコピーの最後に付される。分散型ブロックチェーンは、それによって、１つのブロック分の長さが増加する。新規ブロックは、接続２２Ａにわたりノードに伝達され、ブロックチェーンのコピーの各々の最後に追加される。新規ブロックは、他のノード２２に伝達される前にノード２２のうちの１つにおいて形成されてもよい。新規ブロックは、ブロックハッシュ値がブロックチェーンデータのそのノードのコピー内の直前のブロックのデータコンテンツに従うべきかを、推定の新規ブロックのブロックチェーンメタデータ２３Ｂ内のブロックハッシュ値をノード自体の計算と比較することにより、任意のノード２２によって検証することができる。

図９は、本発明の第２の実施形態によるブロックチェーンの３つのブロック２３を示す。各データ区分２３Ａは、複数のインストール記録２９を含む。図９では、各ブロック２３が、同じ数のインストール記録２９を含んで示されるが、これに限定的であると見なされるべきではない。ブロックチェーンのブロック２３は、各々ブロックチェーンの他のブロック２３に対して異なる数の記録２９を含むことができる。

各インストール記録２９は、少なくとも運転者支援システム固有識別子（例えば、安全ＥＣＵのシリアル番号）及び動作命令識別子（例えば、動作命令バージョン番号）を含む。各インストール記録２９は、安全ＥＣＵ識別子に対応する安全ＥＣＵ上の動作命令識別子に対応する動作命令のインストールのドキュメンテーションを示す。単一のＥＣＵ識別子を有する所与の安全ＥＣＵは、分散型ブロックチェーン内に複数のインストール記録２９を有してもよい。例えば、元の動作命令が安全ＥＣＵにインストールされるときの第１のインストール記録が、安全ＥＣＵ上の動作命令の更新に対応する少なくとも１つの更新インストール記録によって動作命令の異なる（例えば、後続の）バージョンに続く。いくつかの又は全てのインストール記録はまた、更なる情報、例えば、インストールの時間及び日付を含み得る。安全ＥＣＵの挙動の試験結果、又はＥＣＵ内のパラメータのトリミングは、インストール記録の少なくとも一部を形成し得る、スマートコントラクト内に記憶されてもよい。インストール記録２９は、全てフォーマット（すなわち、同じフィールド）を有する必要はない。所与のブロックは、異なる運転者支援システム固有識別子に対応するインストール記録を含み得る。

ノード上のブロックチェーンのコピーは、故障コピーとしてインセキュアとフラグが立てられていない場合にのみクエリされ得る。換言すれば、ブロックチェーンのコピーの使用は、ブロックチェーンのコピーが故障コピーではない場合にのみ許可される。ブロックチェーンのコピーが故障コピーとしてフラグを立てられた場合、ブロックチェーンのコピーの使用がブロックされる。次に、これは、故障コピーが、クエリされることができず、内部データを使用することができないことを意味する。

ブロックチェーンのコピーが故障コピーではない場合、ブロックチェーンのコピーは、データベースの様式でクエリされ得る。例えば、クエリは、クエリ運転者支援システム固有識別子に基づいてもよく、その場合、そのクエリ運転者支援システム固有識別子に対応する全てのインストール記録が返され得る。この実施例では、特定の運転者支援システムの検証されたインストール履歴が、見出され得る。別の実施例では、クエリは、クエリ動作命令識別子に基づいてもよく、その場合、クエリ動作命令識別子に対応する全てのインストール記録が返され得る。この実施例では、その上にインストールされた動作命令のクエリバージョンを有する安全ＥＣＵの検証されたリストが、識別され得る。次いで、これらの特定の安全ＥＣＵを含む自車両は、利用可能である場合、それらの動作命令に対する更新を標的とすることができる。

第２の実施形態による分散型ブロックチェーンは、ブロックチェーンセキュリティチェック（ノード内ベース）及び検証ルーチン（ノード間ベース）の両方を実装して、インストール記録をセキュア化する。

このようにして、特定の安全ＥＣＵ上にインストールされた動作命令のセキュア記録が、維持される。記録の精密さは、検証ルーチン及びブロックチェーンセキュリティ機能によって（すなわち、ブロックハッシュ値を使用して）維持される。換言すれば、ブロックチェーンは、運転者支援システムの動作命令のセキュアな追跡可能性を可能にする。

動作命令が特定の安全ＥＣＵ上で更新されるとき、例えば、新規のインストール記録が、その更新に対応して生成される。インストール記録は、ブロックチェーンに追加される必要がある。より具体的には、記録は、ブロックチェーンに追加される新規ブロックのデータ区分２３Ａに追加される。複数の記録が、単一の新規ブロックに収集されてもよく、次いで、各ブロックチェーンコピーの最後に付される。ブロックチェーンは、それによって、１つのブロック２３分の長さが増加する。新規ブロック２３は、ノードに伝達され、ブロックチェーンのコピーの各々の最後に追加される。新規ブロック２３は、他のノード２２に伝達される前にノード２２のうちの１つで形成されてもよい。新規ブロック２３は、ブロックハッシュ値がブロックチェーンのそのノードのコピー内の直前のブロックのデータに従うべきかを、推定の新規ブロックのブロックチェーンメタデータ２３Ｂ内のブロックハッシュ値をノード自体の計算と比較することにより、任意のノード２２による検証をすることができる。

両方の実施形態において、ブロックチェーンのコンテンツを検証するために実行され得る２つのチェックがあり、各ブロックチェーンコピー及び検証ルーチンのブロックチェーンセキュリティチェックが行われる。この組み合わせは、改善された動作命令セキュリティ又は動作命令インストール追跡可能性を可能にし得る。ブロックチェーンの故障コピーはまた、ブロックチェーンセキュリティチェックによって識別されてもよい。

両方の実施形態では、ブロックチェーンへのアクセスが制御され得る。例えば、特定の当事者のみが、新規ブロックを追加することができる場合があり、及び／又は（潜在的に異なる若しくは重複する）特定の当事者のみが、ブロックチェーンを読み取ることができる場合がある。ブロックチェーンは、許容可能なブロックチェーンであってもよい。

両方の実施形態では、ブロックチェーンは、暗号化されてもよい。すなわち、ブロックチェーンのコピーは、ノード上で暗号化され得る。更に、第１の実施形態のブロックチェーンから抽出された又はそこに送信されるデータ、例えば、動作命令のあるバージョン及び対応する検証されたハッシュ値、又はブロックのコピーは、それが伝達される際に暗号化されてもよい。第２の実施形態のブロックチェーンから抽出され、及び／又はそこに送信されたデータはまた、伝達される際に暗号化されてもよい。両方の場合では、単に例として、暗号化は、トランスポート層セキュリティ（Transport Layer Security、ＴＬＳ）又はセキュアソケット層（Secure
Sockets Layer、ＳＳＬ）プロトコルを使用してもよい。自車両とブロックチェーンとの間の通信は、１つ以上のかかる暗号化プロトコルを使用することができる。

本明細書及び請求項内で使用されるとき、「含む（comprises）」及び「含む（comprising）」という用語及びその変形は、指定された特徴、工程、又は整数が含まれることを意味する。用語は、他の特徴、工程、又は整数の存在を除外するように解釈されるべきではない。

前述の説明において、又は以下の特許請求の範囲において、又は添付図面内において、それらの特定の形態で、又は開示された機能を実行するための手段の観点から表現される、開示された特徴、若しくは、開示された結果を得るための方法又はプロセスは、適宜、別個に、又はかかる特徴の任意の組み合わせで、本発明を多様な形態で再利用するために利用することができる。

本発明を、上記の例示的な実施形態と併せて説明してきたが、所与の本開示を考慮すると、当業者には多くの等価な修正及び変形が明らかとなるであろう。したがって、上述の本発明の例示的な実施形態は、例示的であり、限定的ではないと考えられる。説明される実施形態に対する様々な変更が、本発明の趣旨及び範囲から逸脱することなく行われてもよい。

Claims (15)

1. 車両の運転支援システムの動作命令をセキュア化する方法であって、
   前記車両には、運転動作を制御する制御ユニット（ＥＣＵ）が備えられ、
   前記ＥＣＵに有線又は無線で接続され、複数のノードを含むネットワークが備えられ、
   当該方法は：
   － 前記複数のノードに、前記ＥＣＵの動作命令を示す初期プログラム又は更新プログラムを格納する工程であり、前記複数のノードの各々は、前記動作命令の異なるバージョンが記憶される複数のブロックを含む分散型のブロックチェーンを構築するように構成された、当該工程と；
   － 前記複数のノードに、前記ブロックチェーンのコピーを格納する工程と；
   － 前記ブロックチェーンのコピーが、各ノード間で同一であるかを検証する工程と；
   － 前記ノードの何れかで同一でないことが検出されたときに、当該コピーを欠陥コピーとしてインセキュアのフラグ立て、前記ネットワーク内において、前記欠陥コピーの使用を禁止し、前記欠陥コピーの前記ブロック内に含まれる前記動作命令の前記ＥＣＵへのインストールを禁止する工程と；を含むことを特徴とする方法。
2. 前記複数のノードの各々は、前記ネットワークに接続されたサーバに形成されることを特徴とする請求項１に記載の方法。
3. 新規ブロックを各ノード上の前記ブロックチェーンのコピーに追加するバージョン追加ルーチンを含み、
   前記新規ブロックが、前記動作命令の更新バージョンを含む、請求項１又は２に記載の方法。
4. 前記欠陥コピーに含まれていない前記ブロックチェーンのインストールブロックから、前記動作命令のインストールバージョンを前記運転支援システム上にインストールするＥＣＵ更新ルーチンを更に含むことを特徴とする、請求項１乃至３の何れか１項に記載の方法。
5. 前記インストールブロックの全体を前記ＥＣＵにコピーすることを含む、請求項４に記載の方法。
6. 各ブロックが、前記動作命令のそれぞれのバージョンを含む入力データに対して計算された、検証されたハッシュ値を含む、請求項４又は５に記載の方法。
7. 前記動作命令の前記インストールバージョンの前記検証されたハッシュ値を、前記ＥＣＵ上の検証されたハッシュ記憶手段にコピーする工程を更に含むことを特徴とする、請求項６に記載の方法。
8. 前記検証されたハッシュ値が、前記インストールブロックのインストールブロックメタデータの少なくとも一部分を含む入力データに対して計算されている、請求項７に記載の方法。
9. 前記ブロックチェーンが、アクセス制御されている、請求項１～８のいずれかに記載の方法。
10. 前記ブロックチェーンが、暗号化されている、請求項１～９のいずれかに記載の方法。
11. 制御ユニット（ＥＣＵ）を有する車両の運転支援システムの動作命令を追跡する方法であって、
    ａ）前記ＥＣＵに有線又は無線で接続され、複数のノードを含むネットワークを構築する工程と、
    ｂ）前記複数のノードの各々について、前記動作命令の異なるバージョンが記憶される複数のブロックを含む分散型のブロックチェーンを構築する工程と、
    ｃ）前記ブロックチェーンのコピーを前記複数のノードに記憶する工程であり、各ブロックが、少なくとも１つのインストール記録を含み、各インストール記録が、前記運転支援システム固有識別子及び動作命令識別子を含む、当該工程と、
    ｄ）前記ブロックチェーンの各ブロックが、対応する前記コピー全体にわたり、且つ、前記複数のノード全体にわたり、同一であることをチェックする検証ルーチンを実行する工程と、
    ｅ）前記検証ルーチンにおいて、前記ノードの何れかで同一でない前記コピーが検出されたときに、当該ノードにおける前記ブロックチェーンの変更されたコピーを欠陥コピーとして、当該欠陥コピーに対してインセキュアのフラグ立てる工程と、
    ｆ）前記ネットワーク内において、前記欠陥コピーの使用を禁止し、前記欠陥コピーの前記ブロック内に含まれる前記インストール記録の使用を禁止する工程と、を含むことを特徴とする方法。
12. 前記複数のノードの各々は、前記ネットワークに接続されたサーバに形成されることを特徴とする請求項１１に記載の方法。
13. 前記動作命令識別子が、インストールされた前記動作命令のバージョン識別子を含む、請求項１１又は１２に記載の方法。
14. ｃ）前記故障コピーではない前記ブロックチェーンのコピーがクエリされることを許容して、インストールされた前記動作命令のより最近のバージョンが前記ブロックチェーンの前記コピー内で利用可能であるかどうかを識別し、かつより最近のバージョンが利用可能である場合、前記動作命令の前記より最近のバージョンを前記運転支援システム上にインストールすることを更に含む、請求項１１～１３のいずれか一項に記載の方法。
15. 少なくとも１つのインストール記録が、
    前記動作命令識別子に対応する前記動作命令が、前記運転支援システム固有識別子に対応する前記運転者支援システム上にインストールされた、インストール時間と、
    前記運転支援システム固有識別子に対応する前記運転支援システムの動作の試験結果と、のうちの少なくとも１つを含む、請求項１１～１４のいずれか一項に記載の方法。

Images