JP2022191516A

JP2022191516A - 車両ｅｃｕソフトウェアのためのソフトウェアデルタ更新の構築およびツールチェーンに基づく異常検出

Info

Publication number: JP2022191516A
Application number: JP2022172935A
Authority: JP
Inventors: フォックスゾハール; Fox Zohar
Original assignee: Aurora Labs Ltd
Current assignee: Aurora Labs Ltd
Priority date: 2017-07-25
Filing date: 2022-10-28
Publication date: 2022-12-27
Anticipated expiration: 2038-07-24
Also published as: US20190034192A1; US10545814B2; US10789121B2; US20230221950A1; US20210342142A1; JP7169340B2; US11099836B2; US20200250023A1; US20190034185A1; US20200034139A1; US20210311726A1; US10481899B2; US20240004643A1; US20210255850A1; US20230060267A1; US11314502B2; US11055088B2; US11334346B2; US20210208870A1; US20220206784A1

Abstract

【課題】車両ＥＣＵソフトウェアのためのソフトウェアデルタ更新の構築およびツールチェーンに基づく異常検出の提供。【解決手段】開示される実施形態は、車両内の電子制御ユニット（ＥＣＵ）上のソフトウェアを更新するための更新パッケージを生成するステップに関する。動作は、車両内のＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性にアクセスするステップと、車両内のＥＣＵ上に記憶される現在のソフトウェアの対応する複数の属性にアクセスするステップと、複数の属性と対応する複数の属性を比較するステップと、比較において決定された複数の属性と対応する複数の属性との間の差異を表すデルタファイルを生成するステップと、デルタファイルをＥＣＵに提供するステップであってデルタファイルはデルタファイルが車両内のＥＣＵ内で実行することを有効にするＥＣＵ内のスタートアップコードによって処理されるように構成されるステップとを含む。【選択図】なし

Description

（関連出願の相互参照）
本願は、両方とも、参照することによってその全体として本明細書に組み込まれる、２０１７年７月２５日に出願された、米国仮特許出願第６２／５３６，７６７号および２０１７年９月１９日に出願された、米国仮特許出願第６２／５６０，２２４号の優先権を主張する。

現代の車両は、多くの電子制御ユニット（ＥＣＵ）を利用して、エンジン、パワートレイン、トランスミッション、ブレーキ、サスペンション、オンボードエンターテインメントシステム、通信システム、および同等物等のコンポーネントの動作を制御する。ＥＣＵは、パワーステアリングから、制動、加速まで、現代の車両の基本動作を制御する。加えて、ＥＣＵは、車両内の多数の付加装置および分析特徴を制御する。例えば、いくつかの車は、保険料を決定するために保険企業に提供され得る、運転データを収集および分析するように構成される、ＥＣＵを装備し得る。いくつかの車は、運転体験を向上させるように構成される、ＥＣＵを装備し得、いくつかの車は、高度な（または自動化された）運転補助を提供するように構成される、ＥＣＵを装備し得る。

ＥＣＵが、複雑性および精巧さを継続して増加させるにつれて、ＥＣＵ上におけるソフトウェア性能の管理、アップグレード、およびバグ修正が、課題となっている。現在、平均的車内には、約６０～７０のＥＣＵが存在する（高級車では、約１８０のＥＣＵ）。これらのＥＣＵは、数千万本ものコードに対応する。コードの維持は、ますます困難になっている。さらに、高度に精巧なソフトウェアは、ソフトウェアバグ、グリッチ、および較正問題等の脆弱性をより受けやすい傾向にある。ＥＣＵの製造業者または開発者は、これらの脆弱性が発見されるとすぐに、それらを速やかに修正することを所望し得る。

ＥＣＵ内のさらなるタイプの脆弱性は、ＥＣＵエラーまたは故障に関する。ＥＣＵエラーは、例えば、ランタイムエラー、スタックオーバーフロー、スタックアンダーフロー等であり得る。ＥＣＵ故障は、例えば、ＥＣＵの正常または予期される動作における逸脱であり得る（例えば、時間間隔あたりある回数だけ機能を実施するが、次いで、突然または経時的にゆっくりとのいずれかにおいて、異なる回数だけ機能を実施することに「ドリフト」する）。ＥＣＵソフトウェアの実行におけるゆっくりと実装されるドリフトは、ＥＣＵの動作への変更の任意の明白な兆候の所与の欠如を直ちに検出することが難しいため、特に困難な問題となり得る。

影響される車両におけるこれらの脆弱性に対処するための１つのアプローチは、リコールを発行することである。しかしながら、リコールは、時間がかかり得、それらは、影響される車両がタイムリーな様式において修正されるであろうことのいかなる保証も提供しない。代替として、製造業者または開発者は、オンボード診断（ＯＢＤ）ポートを通して、または無線通信を経由して（例えば、種々のタイプの無線通信技法を使用して）、修正を影響される車両に提供するように試み得る。それにもかかわらず、ＯＢＤポート自体が、車両に対する攻撃可能面となり、無線通信を経由した修正は、典型的には、非効率的で、車両所有者にとって不便であって、さらなる付加的バグを導入しやすい。

さらに、ＯＢＤおよび無線通信を経由した更新技法の現在の試みは、依然として、時間および空間効率の観点から限界を有する。例えば、無線通信を経由した更新技法の現在の試みは、製造業者が、ＥＣＵソフトウェア全体の新しいバージョンを置換パッケージとして影響される車両に配布することを要求する。置換パッケージが、影響される車両によって受信されると、影響される車両は、置換パッケージをスペアメモリ空間（すなわち、ＥＣＵによって使用されていないメモリ空間）の中に記憶し、ＥＣＵソフトウェアの現在のバージョンをＥＣＵによって使用されるメモリ空間から消去し、置換パッケージをスペアメモリ空間からＥＣＵによって使用されるメモリ空間の中にコピーし、ＥＣＵを再起動することを要求され、したがって、ＥＣＵソフトウェアの新しいバージョンをロードすることができる。これは、有意な記憶空間限界およびＥＣＵの機能の中断に起因して、ＥＣＵにおいては事実上不可能である。ＥＣＵは、既存のソフトウェアおよびデータですでにほぼ満杯であって、新しいソフトウェアまたはデータのための非常に限定された利用可能な記憶空間を有する。さらに、新しいソフトウェアをＥＣＵに提供することと関連付けられた有意なコスト限界が存在する。さらに、ＥＣＵの処理フローの中断は、ＥＣＵの役割および車両の条件に応じて、不便または非常に危険であり得る。

したがって、前述の欠点を伴わずに、ソフトウェアを更新するための更新パッケージを生成し、ＥＣＵ上で受信および処理するための技術的ソリューションの必要性が存在する。特に、無線を経由して、専用クライアントをＥＣＵ上に伴わずに、ソフトウェアモジュールまたはパッケージ全体ではなく、差分ソフトウェアを用いて車両を更新するためのソリューションの必要がある。さらに、ソリューションは、有意な付加的メモリ使用量またはＥＣＵ自体の任意の休止時間の要件を有するべきではない。加えて、そのようなソリューションは、ＥＣＵのメモリを再プログラムすることを要求すべきではない。さらに、そのようなソリューションは、ソフトウェアモジュール全体をダウンロードする必要なく、メモリを再プログラム（高価であって、時間がかかり、および破壊的であり得る）せずに、再び、有意なメモリ要件またはＥＣＵの任意の休止時間を伴わずに、ＥＣＵ上のソフトウェアバージョンを以前のバージョンにロールバックすることを可能にすべきである。

また、記憶または伝送するために大量のデータスループットを消費しないであろう、異常検出のためのデータを生成するための技術的ソリューションの必要性が存在する。そのような技法は、それが必要とする全てのそのリソースを用いて、付加的要求されるリソースを伴わずに、ＥＣＵ上の主要なアプリケーションを起動させたまま保つための限られた実行性能を提供すべきである。さらに、アクションのためのコールのみを応答性アクションを実施するための制御センタまたはサーバに送信する（例えば、機械学習を通した異常検出に基づいて）、分散型車両アーキテクチャソリューションを利用することが有利であろう。

さらに、車両内のＥＣＵ間の依存性に基づいて生じる問題のための技術的ソリューションの必要がある。例えば、１つのＥＣＵ上のソフトウェアが、更新されると、ＥＣＵが車両内の他のＥＣＵと通信することを不可能にさせ得る。これは、例えば、ＥＣＵへの更新が、そのネットワークアドレス、着信または発信通信ポリシ、データ通信のフォーマットまたはペイロード、通信のタイミング、通信のプロトコル、またはその機能性の種々の他の属性に影響を及ぼすときに生じ得る。したがって、ＥＣＵへのソフトウェア更新が、更新によって影響され得る全てのＥＣＵ上で協調および実施され得るように、ＥＣＵ間の依存性を管理することが可能であることが有利であろう。

開示される実施形態は、車両内の電子制御ユニット（ＥＣＵ）上のソフトウェアを更新するための更新パッケージを生成するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、ソフトウェアを更新するための更新パッケージを生成するための動作を車両内のＥＣＵ上で実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、車両内のＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性にアクセスするステップと、車両内のＥＣＵ上に記憶される現在のソフトウェアの対応する複数の属性にアクセスするステップと、複数の属性と対応する複数の属性を比較するステップと、比較において決定された複数の属性と対応する複数の属性との間の差異を表すデルタファイルを生成するステップと、デルタファイルをＥＣＵに提供するステップであって、デルタファイルは、デルタファイルが車両内のＥＣＵ内で実行することを有効にする、ＥＣＵ内のスタートアップコードによって処理されるように構成される、ステップとを含んでもよい。

開示される実施形態によると、スタートアップコードは、デルタファイルの中に統合される。

開示される実施形態によると、スタートアップコードは、デルタファイルがＥＣＵによって受信される前に、ＥＣＵ上にインストールされる。

開示される実施形態によると、スタートアップコードは、デルタファイルのランタイムライブラリを初期化するように構成される。

開示される実施形態によると、スタートアップコードは、ＥＣＵのプログラムカウンタを更新し、デルタファイル内に含有される命令を実行するように構成される。

開示される実施形態によると、デルタファイルは、ソフトウェア更新によって参照される変数の値を表す、変数データを備える。

開示される実施形態によると、スタートアップコードは、変数データをデルタファイルから抽出し、変数データをＥＣＵにアクセス可能なメモリの中に設置するように構成される。

開示される実施形態によると、デルタファイルは、ＥＣＵ内のメモリアドレスを更新するためのコードを備える。

開示される実施形態によると、スタートアップコードは、メモリアドレスを更新するためのコードを抽出し、ＥＣＵ内のメモリアドレスを更新するように構成される。

開示される実施形態によると、ＥＣＵ上のソフトウェアは、複数の機能ユニットにマッピングされ、ＥＣＵは、仮想ファイルシステム（ＶＦＳ）を利用して、複数の機能ユニットのそれぞれの１つ以上のバージョンを管理および追跡するように構成される。

開示される実施形態によると、ＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性は、ＶＦＳによって管理される複数の機能ユニットのうちの少なくとも１つを備える。

開示される実施形態によると、命令はさらに、第１のグリッドをソフトウェア更新に適用するステップと、第２のグリッドをＥＣＵ上に記憶される現在のソフトウェアに適用するステップと、第１および第２のグリッドの比較に基づいて、複数の属性および対応する複数の属性を識別するステップとを含む。

開示される実施形態によると、第１のグリッドは、ソフトウェア更新と関連付けられたバイナリデータと、ソフトウェア更新と関連付けられたソース属性と、ソフトウェア更新と関連付けられたマップファイルとのうちの少なくとも１つを含む１つ以上の次元におけるソフトウェア更新を表す。

開示される実施形態によると、複数の属性は、少なくとも部分的に、ソフトウェア更新を開発するために使用されるプログラミング言語に基づいて識別される。

開示される実施形態によると、複数の属性は、少なくとも部分的に、ソフトウェア更新のバイナリファイル分解能に基づいて識別される。

開示される実施形態によると、複数の属性は、少なくとも部分的に、ソフトウェア更新と関連付けられたマップファイルに基づいて識別される。

開示される実施形態によると、ソフトウェア更新は、モノリシックファイルである。

開示される実施形態によると、ソフトウェア更新は、他のファイルに相互依存するファイルである。

開示される実施形態によると、動作は、デルタファイルをＥＣＵに提供する前に、ＥＣＵのために提供されているデルタファイルに基づいて、任意の相互依存ＥＣＵが更新されるべきであるかどうかを決定するために依存性システムをチェックするステップを含む。

開示される実施形態によると、動作はさらに、付加的デルタファイルを相互依存ＥＣＵに自動的に提供し、相互依存ＥＣＵに関するソフトウェア更新を実施するステップを含む。

開示される実施形態によると、ソフトウェアを更新するためのシステムが、車両内のＥＣＵ上に実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、車両内のＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性にアクセスするステップと、車両内のＥＣＵ上に記憶される現在のソフトウェアの対応する複数の属性にアクセスするステップと、複数の属性と対応する複数の属性を比較するステップと、比較において決定された複数の属性と対応する複数の属性との間の差異を表すデルタファイルを生成するステップと、デルタファイルをＥＣＵに提供するステップであって、デルタファイルは、デルタファイルが車両内のＥＣＵ内で実行することを有効にする、ＥＣＵ内のスタートアップコードによって処理されるように構成される、ステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、ソフトウェアを更新するための方法が、車両内のＥＣＵ上に実装されてもよい。本方法は、車両内のＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性にアクセスするステップと、車両内のＥＣＵ上に記憶される現在のソフトウェアの対応する複数の属性にアクセスするステップと、複数の属性と対応する複数の属性を比較するステップと、比較において決定された複数の属性と対応する複数の属性との間の差異を表すデルタファイルを生成するステップと、デルタファイルをＥＣＵに提供するステップであって、デルタファイルは、デルタファイルが車両内のＥＣＵ内で実行することを有効にする、ＥＣＵ内のスタートアップコードによって処理されるように構成される、ステップとを含んでもよい。

開示される実施形態は、車両内でデルタファイルを受信および統合するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、車両内でデルタファイルを受信および統合するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、車両内の電子制御ユニット（ＥＣＵ）において、デルタファイルを受信するステップであって、デルタファイルは、ＥＣＵ上のソフトウェアのためのソフトウェア更新に対応する複数のデルタおよびデルタファイルをＥＣＵ内で実行するためのスタートアップコードを備える、ステップと、スタートアップコードに基づいて、デルタファイルをＥＣＵ内で実行するステップと、ＥＣＵ内のメモリアドレスを更新し、デルタファイルからの複数のデルタに対応させるステップとを含んでもよい。

開示される実施形態によると、デルタファイルは、ＥＣＵによって実行されるべき位置独立実行可能コードセグメントを備える。

開示される実施形態によると、スタートアップコードは、ＥＣＵ上への記憶のために、データをデルタファイルから抽出するように構成される。

開示される実施形態によると、スタートアップコードは、デルタファイルをデルタファイルと関連付けられた仮想ファイルシステム内の具体的機能にリンクさせるように構成される。

開示される実施形態によると、デルタファイルは、ＥＣＵと関連付けられたフラッシュメモリに書き込まれる。

開示される実施形態によると、デルタファイルは、フラッシュメモリからＥＣＵと関連付けられたランダムアクセスメモリにブートストラップされる。

開示される実施形態によると、デルタファイルは、ＥＣＵの継続される動作に影響を及ぼさずに、ＥＣＵによって実行可能である。

開示される実施形態によると、デルタファイルは、ＥＣＵをリブートせずに実行可能である。

開示される実施形態によると、デルタファイルを車両内のＥＣＵの中に受信および統合するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、車両内のＥＣＵにおいて、デルタファイルを受信するステップであって、デルタファイルは、ＥＣＵ上のソフトウェアのためのソフトウェア更新に対応する複数のデルタおよびＥＣＵ内でデルタファイルを実行するためのスタートアップコードを備える、ステップと、スタートアップコードに基づいて、デルタファイルをＥＣＵ内で実行するステップと、ＥＣＵ内のメモリアドレスを更新し、デルタファイルからの複数のデルタに対応するステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、デルタファイルは、車両のＥＣＵによって実行されるべき位置独立実行可能コードセグメントを備える。

開示される実施形態によると、デルタファイルは、ＥＣＵ内のメモリのコンテンツを削除すべきであるかどうかを決定するためのコードを備える。

開示される実施形態によると、スタートアップコードは、ＥＣＵに、ＥＣＵ内のメモリの特定のコンテンツを削除するように命令するように構成される。

開示される実施形態によると、デルタファイルは、ＥＣＵの継続される動作に影響を及ぼさずに実行可能である。

開示される実施形態によると、デルタファイルを車両内のＥＣＵの中に受信および統合するための方法が、実装される。本方法は、車両内のＥＣＵにおいて、デルタファイルを受信するステップであって、デルタファイルは、ＥＣＵ上のソフトウェアのためのソフトウェア更新に対応する複数のデルタおよびデルタファイルをＥＣＵ内で実行するためのスタートアップコードを備える、ステップと、スタートアップコードに基づいて、デルタファイルをＥＣＵ内で実行するステップと、ＥＣＵ内のメモリアドレスを更新し、デルタファイルからの複数のデルタに対応させるステップとを含んでもよい。

開示される実施形態は、車両のＥＣＵが動作している間、電子制御ユニット（ＥＣＵ）ソフトウェアへの更新を実施するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、車両のＥＣＵが動作している間、ＥＣＵソフトウェアへの更新を実施するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、車両のＥＣＵが動作している間、車両において、ＥＣＵソフトウェアのためのソフトウェア更新ファイルを受信するステップと、ＥＣＵが動作している間、ソフトウェア更新ファイルをＥＣＵのメモリ内の第１のメモリ場所の中に書き込むと同時に、ＥＣＵのメモリ内の第２のメモリ場所内で既存のコードのコードセグメントを実行するステップと、ソフトウェア更新ファイルに基づいて、ＥＣＵのメモリ内の第２のメモリ場所内で現在実行されているコードセグメントの実行を中断せずに、ＥＣＵのメモリと関連付けられた複数のメモリアドレスを更新するステップとを含んでもよい。

開示される実施形態によると、ＥＣＵソフトウェアは、複数の機能ユニットにマッピングされ、ＥＣＵは、仮想ファイルシステム（ＶＦＳ）を利用して、複数の機能ユニットのそれぞれの１つ以上のバージョンを管理および追跡するように構成される。

開示される実施形態によると、ＥＣＵのメモリと関連付けられた複数のメモリアドレスを更新するステップは、ＶＦＳを通して管理される複数の機能ユニットの複数のメモリアドレスを更新するステップを含む。

開示される実施形態によると、ソフトウェア更新ファイルは、デルタファイルである。

開示される実施形態によると、デルタファイルは、デルタファイルの中に統合され、デルタファイルをＥＣＵ内で実行するために構成される、スタートアップコードを備える。

開示される実施形態によると、命令はさらに、ソフトウェア更新ファイルをＥＣＵの第１のメモリ場所の中に書き込む前に、ランタイムライブラリを初期化するステップを含んでもよい。

開示される実施形態によると、スタートアップコードは、変数データをデルタファイルから抽出し、変数データをＥＣＵにアクセス可能なランダムアクセスメモリの中に設置するように構成される。

開示される実施形態によると、命令はさらに、ソフトウェア更新によって参照される変数の前の値を表すデータを削除するステップを含んでもよい。

開示される実施形態によると、デルタファイルは、ＥＣＵのメモリ内のメモリアドレスを更新するためのコードを備える。

開示される実施形態によると、スタートアップコードは、メモリアドレスを更新するためのコードを抽出し、ＥＣＵのメモリ内のメモリアドレスを更新するように構成される。

開示される実施形態によると、命令はさらに、ソフトウェア更新を完了した後、ＥＣＵのメモリをデフラグメントするステップを含んでもよい。

開示される実施形態によると、車両のＥＣＵが動作している間、ＥＣＵソフトウェアへの更新を実施するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、車両のＥＣＵが動作している間、車両において、ＥＣＵソフトウェアのためのソフトウェア更新ファイルを受信するステップと、ＥＣＵが動作している間、ソフトウェア更新ファイルをＥＣＵのメモリ内の第１のメモリ場所の中に書き込むと同時に、ＥＣＵのメモリ内の第２のメモリ場所内の既存のコードのコードセグメントを実行するステップと、ソフトウェア更新ファイルに基づいて、ＥＣＵのメモリ内の第２のメモリ場所内で現在実行されているコードセグメントの実行を中断せずに、ＥＣＵのメモリと関連付けられた複数のメモリアドレスを更新するステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、車両のＥＣＵが動作している間、ＥＣＵソフトウェアへの更新を実施するための方法が、実装されてもよい。本方法は、車両のＥＣＵが動作している間、車両において、ＥＣＵソフトウェアのためのソフトウェア更新ファイルを受信するステップと、ＥＣＵが動作している間、ソフトウェア更新ファイルをＥＣＵのメモリ内の第１のメモリ場所の中に書き込むと同時に、ＥＣＵのメモリ内の第２のメモリ場所内の既存のコードのコードセグメントを実行するステップと、ソフトウェア更新ファイルに基づいて、ＥＣＵのメモリ内の第２のメモリ場所内で現在実行されているコードセグメントの実行を中断せずに、ＥＣＵのメモリと関連付けられた複数のメモリアドレスを更新するステップとを含んでもよい。

開示される実施形態は、車両電子制御ユニット（ＥＣＵ）ソフトウェアバージョンを調節するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、車両電子制御ユニット（ＥＣＵ）ソフトウェアバージョンを調節するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行に車両のＥＣＵを調節するためのプロンプトを受信するステップと、プロンプトに応答して、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイルに基づいて、車両内のＥＣＵ上のＥＣＵソフトウェアの第２のバージョンを実行のために構成するステップと、プロンプトに応答して、車両内のＥＣＵ上のＥＣＵソフトウェアの第１のバージョンを実行不可能となるように構成するステップとを含んでもよい。

開示される実施形態によると、ＥＣＵソフトウェアの第２のバージョンは、ＥＣＵソフトウェアの第１のバージョンに続いて展開される。

開示される実施形態によると、ＥＣＵソフトウェアの第２のバージョンは、ＥＣＵソフトウェアの第１のバージョンに先立って展開される。

開示される実施形態によると、ＥＣＵ上のＥＣＵソフトウェアは、複数の機能ユニットにマッピングされ、ＥＣＵは、仮想ファイルシステム（ＶＦＳ）を利用して、複数の機能ユニットのそれぞれの１つ以上のバージョンを管理および追跡するように構成される。

開示される実施形態によると、ＥＣＵソフトウェアの第１のバージョンを実行不可能になるように構成するステップはさらに、ＶＦＳによって管理される１つ以上の機能ユニットに対応するＥＣＵ内のメモリアドレスを更新するステップを含む。

開示される実施形態によると、ＥＣＵソフトウェアの第２のバージョンは、ＶＦＳによって無効にされる１つ以上の機能ユニットを有する、ＥＣＵソフトウェアの第１のバージョンである。

開示される実施形態によると、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイルは、ＥＣＵ上に記憶される。

開示される実施形態によると、命令はさらに、プロンプトの受信に応じて、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイル内に含まれるスタートアップコードを実行し、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行にＥＣＵを調節するステップを含む。

開示される実施形態によると、命令はさらに、ＥＣＵのメモリの利用量が閾値を上回ることを決定するステップと、削除のためのＥＣＵのメモリの具体的コンテンツを識別するステップとを含む。

開示される実施形態によると、命令はさらに、削除を完了した後、ＥＣＵのメモリをデフラグメントするステップを含む。

開示される実施形態によると、車両ＥＣＵソフトウェアバージョンを調節するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行に車両のＥＣＵを調節するためのプロンプトを受信するステップと、プロンプトに応答して、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイルに基づいて、車両内のＥＣＵ上のＥＣＵソフトウェアの第２のバージョンを実行のために構成するステップと、プロンプトに応答して、車両内のＥＣＵ上のＥＣＵソフトウェアの第１のバージョンを実行不可能となるように構成するステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、ＥＣＵソフトウェアの第１のバージョンを実行不可能になるように構成するステップは、ＶＦＳによって管理される１つ以上の機能ユニットに対応するＥＣＵ内のメモリアドレスを更新するステップを含んでもよい。

開示される実施形態によると、車両ＥＣＵソフトウェアバージョンを調節するための方法が、実装されてもよい。本方法は、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行に車両のＥＣＵを調節するためのプロンプトを受信するステップと、プロンプトに応答して、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイルに基づいて、車両内のＥＣＵ上のＥＣＵソフトウェアの第２のバージョンを実行のために構成するステップと、プロンプトに応答して、車両内のＥＣＵ上のＥＣＵソフトウェアの第１のバージョンを実行不可能となるように構成するステップとを含んでもよい。

開示される実施形態は、車両内の電子制御ユニット（ＥＣＵ）異常を識別するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、車両内のＥＣＵ異常を識別するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、車両内において、ＥＣＵのリアルタイム処理アクティビティを表すデータを監視するステップと、車両内において、ＥＣＵの処理アクティビティに関連する履歴データにアクセスするステップであって、履歴データは、ＥＣＵの予期される処理アクティビティを表す、ステップと、車両内において、リアルタイム処理アクティビティデータと履歴データを比較し、ＥＣＵのリアルタイム処理アクティビティ内の少なくとも１つの異常を識別するステップと、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装するステップとを含んでもよい。

開示される実施形態によると、制御アクションは、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行にＥＣＵを調節するためのプロンプトを発行するステップを含む。

開示される実施形態によると、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行にＥＣＵを調節するステップは、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイルに基づいて、ＶＦＳによって管理される１つ以上の機能ユニットのメモリアドレスを更新するステップを含む。

開示される実施形態によると、命令はさらに、ＥＣＵの動作を監視し、履歴データを生成するステップを含む。

開示される実施形態によると、監視、アクセス、比較、および実装は、車両内のオーケストレータ内で生じ、オーケストレータは、ＥＣＵと別個である。

開示される実施形態によると、オーケストレータは、車両内の複数のＥＣＵのための監視、アクセス、比較、および実装を実施するように構成される。

開示される実施形態によると、少なくとも１つの異常は、ＥＣＵによって使用される具体的メモリ場所に対応する。

開示される実施形態によると、少なくとも１つの異常は、ＥＣＵによって使用されるメモリ場所の具体的シーケンスに対応する。

開示される実施形態によると、少なくとも１つの異常は、ＥＣＵ内外のデータフロー内の少なくとも１つのピークに対応する。

開示される実施形態によると、少なくとも１つの異常は、ＥＣＵのプロセッサによるデータ処理内の少なくとも１つのピークに対応する。

開示される実施形態によると、少なくとも１つの異常は、ＥＣＵの電力消費における少なくとも１つの異常に対応する。

開示される実施形態によると、制御アクションは、ＥＣＵと関連付けられたアラートを送信するステップを含む。

開示される実施形態によると、制御アクションは、ＥＣＵから送信される命令をブロックするステップを含む。

開示される実施形態によると、制御アクションは、ＥＣＵ上で起動するＥＣＵソフトウェアのバージョンのＥＣＵソフトウェアの以前のバージョンへのロールバックを含む。

開示される実施形態によると、車両内のＥＣＵ異常を識別するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、車両内において、ＥＣＵのリアルタイム処理アクティビティを表すデータを監視するステップと、車両内において、ＥＣＵの処理アクティビティに関連する履歴データにアクセスするステップであって、履歴データは、ＥＣＵの予期される処理アクティビティを表す、ステップと、車両内において、リアルタイム処理アクティビティデータと履歴データを比較し、ＥＣＵのリアルタイム処理アクティビティ内の少なくとも１つの異常を識別するステップと、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装するステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、車両内のＥＣＵ異常を識別するための方法が、実装されてもよい。本方法は、車両内において、ＥＣＵのリアルタイム処理アクティビティを表すデータを監視するステップと、車両内において、ＥＣＵの処理アクティビティに関連する履歴データにアクセスするステップであって、履歴データは、ＥＣＵの予期される処理アクティビティを表す、ステップと、車両内において、リアルタイム処理アクティビティデータと履歴データを比較し、ＥＣＵのリアルタイム処理アクティビティ内の少なくとも１つの異常を識別するステップと、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装するステップとを含んでもよい。

開示される実施形態は、車両内の電子制御ユニット（ＥＣＵ）異常を識別するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、車両内のＥＣＵ異常を識別するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、ＥＣＵのリアルタイム処理アクティビティを表すデータを監視するステップと、機能性がＥＣＵに匹敵すると見なされる少なくとも１つの他のＥＣＵの処理アクティビティに関連する匹敵するデータを受信するステップと、リアルタイム処理アクティビティデータと匹敵するデータを比較し、ＥＣＵのリアルタイム処理アクティビティ内の少なくとも１つの異常を識別するステップと、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装するステップとを含んでもよい。

開示される実施形態によると、匹敵するデータは、ＥＣＵに匹敵すると見なされる複数の他のＥＣＵの処理アクティビティに関連するリアルタイムで取得されるデータを備える。

開示される実施形態によると、匹敵するデータは、ＥＣＵに匹敵すると見なされる複数の他のＥＣＵの処理アクティビティに関連する以前に集められたデータを備える。

開示される実施形態によると、匹敵するデータを受信するステップはさらに、ＥＣＵ上で起動するＥＣＵソフトウェアと関連付けられたルールに基づいて、匹敵するデータを取得するステップを含む。

開示される実施形態によると、匹敵するデータを受信するステップはさらに、ＥＣＵ上で起動するＥＣＵソフトウェアの実行の既知の有効シーケンスに基づいて、匹敵するデータを取得するステップを含む。

開示される実施形態によると、匹敵するデータを受信するステップはさらに、ＥＣＵ上で起動するＥＣＵソフトウェアの実行の既知の潜在的に悪意のあるシーケンスに基づいて、匹敵するデータを取得するステップを含む。

開示される実施形態によると、匹敵するデータを受信するステップはさらに、ＥＣＵ上のＥＣＵソフトウェアと関連付けられたマップファイルに基づいて、匹敵するデータを取得するステップを含む。

開示される実施形態によると、匹敵するデータを受信するステップはさらに、観察データを他の車両から受信するステップと、観察データに基づいて、匹敵するデータを取得するステップとを含む。

開示される実施形態によると、制御アクションは、ＥＣＵと関連付けられたアラートを送信するステップ、ＥＣＵから送信される命令をブロックするステップ、またはＥＣＵ上で起動するソフトウェアのバージョンをソフトウェアの以前のバージョンにロールバックするステップのうちの少なくとも１つを含む。

開示される実施形態によると、車両内のＥＣＵ異常を識別するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、ＥＣＵのリアルタイム処理アクティビティを表すデータを監視するステップと、機能性がＥＣＵに匹敵すると見なされる少なくとも１つの他のＥＣＵの処理アクティビティに関連する匹敵するデータを受信するステップと、リアルタイム処理アクティビティデータと匹敵するデータを比較し、ＥＣＵのリアルタイム処理アクティビティ内の少なくとも１つの異常を識別するステップと、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装するステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、車両内のＥＣＵ異常を識別するための方法が、実装されてもよい。本方法は、ＥＣＵのリアルタイム処理アクティビティを表すデータを監視するステップと、機能性がＥＣＵに匹敵すると見なされる少なくとも１つの他のＥＣＵの処理アクティビティに関連する匹敵するデータを受信するステップと、リアルタイム処理アクティビティデータと匹敵するデータを比較し、ＥＣＵのリアルタイム処理アクティビティ内の少なくとも１つの異常を識別するステップと、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装するステップとを含んでもよい。

開示される実施形態は、車両内の電子制御ユニット（ＥＣＵ）ソフトウェアを好機をねらって更新するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、車両内の電子制御ユニット（ＥＣＵ）ソフトウェアを好機をねらって更新するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、車両内のコントローラにおいて、車両内の少なくとも１つのＥＣＵ上で起動するソフトウェアを更新する必要性を示す無線伝送を受信するステップと、車両の動作ステータスを監視し、車両がＥＣＵソフトウェア更新が禁止される第１の動作モードにあるかどうかを決定するステップと、動作ステータスが禁止されるとき、ＥＣＵソフトウェア更新を遅延させるステップと、車両の動作ステータスの監視を継続し、車両がＥＣＵソフトウェア更新が許可される第２の動作モードにあるかどうかを決定するステップと、車両が第２の動作モードにあると決定されると、遅延されたＥＣＵソフトウェア更新を用いて、少なくとも１つのＥＣＵの更新を有効にするステップとを含んでもよい。

開示される実施形態によると、車両の動作ステータスの監視を継続するステップは、事前に確立された間隔に従って、車両の動作ステータスを繰り返し監視するステップを含む。

開示される実施形態によると、命令はさらに、車両が第１の動作モードにあるとき、遅延された更新のために、ＥＣＵソフトウェア更新を車両上に位置するメモリ内に記憶するステップを含む。

開示される実施形態によると、遅延されたソフトウェア更新は、車両が第１の動作モードにあるとき、車両から遠隔のサーバ上に維持され、命令はさらに、車両が第２の動作モードにあるとき、メッセージを遠隔サーバに送信するステップと、メッセージに応答して、ＥＣＵソフトウェア更新を受信するステップと、車両が第２の動作モードにあるとき、車両内の少なくとも１つのＥＣＵに関するＥＣＵソフトウェア更新をインストールするステップとを含んでもよい。

開示される実施形態によると、第２の動作モードは、複数の所定の安全動作条件のうちの１つを備える。

開示される実施形態によると、第２の動作モードは、車両のパワーダウンステータスを備える。

開示される実施形態によると、第２の動作モードは、車両のアイドリングステータスを備える。

開示される実施形態によると、第２の動作モードは、強度の閾値を上回る無線通信強度の周期を備える。

開示される実施形態によると、第２の動作モードは、車両の事前に選択された環境条件を備える。

開示される実施形態によると、第２の動作モードは、閾値を下回るエラーレートを伴うネットワーク接続を備える。

開示される実施形態によると、ソフトウェアを更新する必要性を示す無線伝送は、更新がオーバライドステータスを伴うかどうかのインジケーションを備える。

開示される実施形態によると、命令はさらに、更新がオーバライドステータスとともに受信されるとき、車両が第１の動作モードにあるかどうかにかかわらず、ＥＣＵソフトウェアを更新するステップを含む。

開示される実施形態によると、車両内のＥＣＵソフトウェアを好機をねらって更新するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、車両内のコントローラにおいて、車両内の少なくとも１つのＥＣＵ上で起動するソフトウェアを更新する必要性を示す無線伝送を受信するステップと、車両の動作ステータスを監視し、車両がＥＣＵソフトウェア更新が禁止される第１の動作モードにあるかどうかを決定するステップと、動作ステータスが禁止されるとき、ＥＣＵソフトウェア更新を遅延させるステップと、車両の動作ステータスの監視を継続し、車両がＥＣＵソフトウェア更新が許可される第２の動作モードにあるかどうかを決定するステップと、車両が第２の動作モードにあると決定されると、遅延されたＥＣＵソフトウェア更新を用いて、少なくとも１つのＥＣＵの更新を有効にするステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、１つ以上のプロセッサはさらに、更新がオーバライドステータスとともに受信されるとき、車両が第１の動作モードにあるかどうかにかかわらず、ＥＣＵソフトウェアを更新するステップの動作を実施するように構成される。

開示される実施形態によると、車両内のＥＣＵソフトウェアを好機をねらって更新するための方法が、実装されてもよい。本方法は、車両内のコントローラにおいて、車両内の少なくとも１つのＥＣＵ上で起動するソフトウェアを更新する必要性を示す無線伝送を受信するステップと、車両の動作ステータスを監視し、車両がＥＣＵソフトウェア更新が禁止される第１の動作モードにあるかどうかを決定するステップと、動作ステータスが禁止されるとき、ＥＣＵソフトウェア更新を遅延させるステップと、車両の動作ステータスの監視を継続し、車両がＥＣＵソフトウェア更新が許可される第２の動作モードにあるかどうかを決定するステップと、車両が第２の動作モードにあると決定されると、遅延されたＥＣＵソフトウェア更新を用いて、少なくとも１つのＥＣＵの更新を有効にするステップとを含んでもよい。

開示される実施形態によると、ソフトウェアを更新する必要性を示す無線伝送は、更新がオーバライドステータスを伴うかどうかのインジケーションを備え、本方法はさらに、更新がオーバライドステータスとともに受信されるとき、車両が第１の動作モードにあるかどうかにかかわらず、ＥＣＵソフトウェアを更新するステップを含んでもよい。

開示される実施形態は、更新を少なくとも１つの車両に自動的に提供するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、更新を少なくとも１つの車両に自動的に提供するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、少なくとも１つの車両から遠隔のサーバにおいて、電子制御ユニット（ＥＣＵ）アクティビティデータを少なくとも１つの車両から受信するステップであって、ＥＣＵアクティビティデータは、少なくとも１つの車両内のＥＣＵの実際の動作に対応するステップと、サーバにおいて、ＥＣＵアクティビティデータに基づいて、少なくとも１つの車両に影響を及ぼすソフトウェア脆弱性を決定するステップであって、ソフトウェア脆弱性は、受信されたＥＣＵアクティビティデータと予期されるＥＣＵアクティビティデータとの間の逸脱に基づいて決定される、ステップと、サーバにおいて、決定されたソフトウェア脆弱性に基づいて、ＥＣＵソフトウェア更新を識別するステップと、サーバから、識別されたＥＣＵソフトウェア更新に対応するソフトウェア更新を用いてＥＣＵ上のソフトウェアを更新するように構成される、デルタファイルを送信するステップとを含んでもよい。

開示される実施形態によると、少なくとも１つの車両は、グループとして監視されている複数の車両を含む。

開示される実施形態によると、複数の車両は、共通ＥＣＵタイプを有する、第１のセットの車両を含む。

開示される実施形態によると、ソフトウェア脆弱性を決定するステップは、第１のセットの車両に影響を及ぼすソフトウェア脆弱性を決定するステップを含む。

開示される実施形態によると、ソフトウェア脆弱性を決定するステップはさらに、ＥＣＵアクティビティデータに基づいて、ソフトウェア脆弱性によって潜在的に影響される第２のセットの複数の車両を決定するステップを含む。

開示される実施形態によると、ソフトウェア更新を用いてＥＣＵ上のソフトウェアを更新するように構成される、デルタファイルを送信するステップは、複数のデルタファイルを第１のセットおよび第２のセットの車両に送信するステップを含む。

開示される実施形態によると、ＥＣＵソフトウェア更新は、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行にＥＣＵを調節するためのプロンプトを備える。

開示される実施形態によると、命令はさらに、プロンプトに応答して、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイルに基づいて、ＥＣＵ上のＥＣＵソフトウェアの第２のバージョンを実行のために構成するステップと、プロンプトに応答して、ＥＣＵ上のＥＣＵソフトウェアの第１のバージョンを実行不可能になるように構成するステップとを含む。

開示される実施形態によると、ＥＣＵソフトウェア更新は、ＥＣＵに関するＥＣＵソフトウェア更新をインストールするためのインストールエージェントを備える。

開示される実施形態によると、ＥＣＵソフトウェア更新は、複数の車両内のＥＣＵを再較正するように構成される。

開示される実施形態によると、命令はさらに、ＥＣＵソフトウェア更新に応答して、少なくとも１つの車両のＥＣＵに、リブートするように命令するステップを含む。

開示される実施形態によると、更新を少なくとも１つの車両に自動的に提供するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、少なくとも１つの車両から遠隔のサーバにおいて、電子制御ユニット（ＥＣＵ）アクティビティデータを少なくとも１つの車両から受信するステップであって、ＥＣＵアクティビティデータは、少なくとも１つの車両内のＥＣＵの実際の動作に対応するステップと、サーバにおいて、ＥＣＵアクティビティデータに基づいて、少なくとも１つの車両に影響を及ぼすソフトウェア脆弱性を決定するステップであって、ソフトウェア脆弱性は、受信されたＥＣＵアクティビティデータと予期されるＥＣＵアクティビティデータとの間の逸脱に基づいて決定される、ステップと、サーバにおいて、決定されたソフトウェア脆弱性に基づいて、ＥＣＵソフトウェア更新を識別するステップと、サーバから、識別されたＥＣＵソフトウェア更新に対応するソフトウェア更新を用いてＥＣＵ上のソフトウェアを更新するように構成される、デルタファイルを送信するステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、少なくとも１つの車両は、共通ＥＣＵタイプを有する、第１のセットの車両を含み、１つ以上のプロセッサはさらに、第１のセットの車両に影響を及ぼすソフトウェア脆弱性を決定するステップと、ＥＣＵアクティビティデータに基づいて、ソフトウェア脆弱性によって潜在的に影響される第２のセットの車両を決定するステップとの動作を実施するように構成される。

開示される実施形態によると、１つ以上のプロセッサはさらに、ＥＣＵソフトウェア更新を第１のセットおよび第２のセットの車両に送信するステップの動作を実施するように構成される。

開示される実施形態によると、更新を少なくとも１つの車両に自動的に提供するための方法が、実装されてもよい。本方法は、少なくとも１つの車両から遠隔のサーバにおいて、電子制御ユニット（ＥＣＵ）アクティビティデータを少なくとも１つの車両から受信するステップであって、ＥＣＵアクティビティデータは、少なくとも１つの車両内のＥＣＵの実際の動作に対応するステップと、サーバにおいて、ＥＣＵアクティビティデータに基づいて、少なくとも１つの車両に影響を及ぼすソフトウェア脆弱性を決定するステップであって、ソフトウェア脆弱性は、受信されたＥＣＵアクティビティデータと予期されるＥＣＵアクティビティデータとの間の逸脱に基づいて決定される、ステップと、サーバにおいて、ソフトウェア脆弱性に基づいて、ＥＣＵソフトウェア更新を識別するステップと、サーバから、識別されたＥＣＵソフトウェア更新に対応するソフトウェア更新を用いてＥＣＵ上のソフトウェアを更新するように構成される、デルタファイルを送信するステップとを含んでもよい。

開示される実施形態は、電子制御ユニット（ＥＣＵ）エラーまたは故障を遠隔監視サーバに報告するための非一過性コンピュータ可読媒体および方法を説明する。例えば、例示的実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、ＥＣＵエラーまたは故障を遠隔監視サーバに報告するための動作を実施させる、命令を含む、非一過性コンピュータ可読媒体が、存在してもよい。動作は、車両の通信ネットワーク内のプロセッサにおいて、動作データを車両内の複数のＥＣＵから受信するステップであって、動作データは、複数のＥＣＵの複数のランタイム属性を示す、ステップと、機械学習プロセスを通して、動作データの統計的モデルを生成するステップであって、機械学習プロセスは、複数のランタイム属性に基づく、ステップと、ライブランタイム更新を車両の通信ネットワーク内の複数のＥＣＵから受信するステップと、ライブランタイム更新に基づいて、車両の通信ネットワーク内のＥＣＵと関連付けられたＥＣＵエラーを識別するステップであって、ＥＣＵエラーは、ライブランタイム更新と動作データの統計的モデルの比較によって決定され、動作データからの少なくとも１つの逸脱を識別する、ステップと、ライブランタイム更新に基づいて、車両からの報告を遠隔監視サーバに無線で送信するステップであって、報告は、ＥＣＵおよび識別されたＥＣＵエラーを識別する、ステップとを含んでもよい。

開示される実施形態によると、動作は、正しいＥＣＵ動作を示す、ＥＣＵが行い得る１つ以上の正しい応答メッセージが存在することに応答して、要求メッセージをＥＣＵに送信するステップを含む。

開示される実施形態によると、ＥＣＵエラーは、ＥＣＵが要求メッセージに応答することに失敗することに基づいて、識別される。

開示される実施形態によると、ＥＣＵエラーは、ＥＣＵが要求メッセージに正しくなく応答することに基づいて、識別される。

開示される実施形態によると、ＥＣＵエラーは、ＥＣＵ内の検出されたスタックオーバーフローに基づいて、識別される。

開示される実施形態によると、遠隔監視サーバは、多層モデルに従って動作し、階層のうちの１つは、車両から、遠隔監視サーバにおけるさらなる分析のために、ライブランタイム更新のサンプルを受信するステップを含む。

開示される実施形態によると、遠隔監視サーバは、多層モデルに従って動作し、階層のうちの１つは、車両から、ＥＣＵ内の使用中のデルタファイルの識別を受信するステップを含む。

開示される実施形態によると、遠隔監視サーバは、多層モデルに従って動作し、階層のうちの１つは、ＥＣＵのソフトウェアバージョンを以前のソフトウェアバージョンにロールバックすることを決定するステップを含む。

開示される実施形態によると、遠隔監視サーバは、多層モデルに従って動作し、階層のうちの１つは、ＥＣＵのための安全モードを実装することを決定するステップを含む。

開示される実施形態によると、動作はさらに、識別されたＥＣＵエラーがＥＣＵに有害であるかどうかを決定するステップを含む。

開示される実施形態によると、機械学習プロセスは、ＥＣＵによるメモリ使用量のパターンに基づく。

開示される実施形態によると、機械学習プロセスは、ＥＣＵ上のソフトウェアの実行のパターンに基づく。

開示される実施形態によると、動作はさらに、ＶＦＳを通して管理される複数の機能ユニットのうちの１つ以上のもののメモリアドレスを更新するステップを含む、ＥＣＵ上のＥＣＵソフトウェアの第２のバージョンを実行のために構成するステップを含む。

開示される実施形態によると、ＥＣＵソフトウェアの第２のバージョンは、ＶＦＳによって無効にされる１つ以上の機能ユニットを有する、ＥＣＵソフトウェアの前のバージョンである。

開示される実施形態によると、動作データは、複数のＥＣＵの識別子を含む。

開示される実施形態によると、動作データは、複数のＥＣＵの最後の既知のポーリングを示すデータを含む。

開示される実施形態によると、命令はさらに、動作データおよびライブランタイム更新に基づいて、複数のＥＣＵに関する休止時間の確率を決定するステップを含む。

開示される実施形態によると、ＥＣＵエラーまたは故障を遠隔監視サーバに報告するためのシステムが、実装されてもよい。本システムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、１つ以上のプロセッサに、車両の通信ネットワーク内のプロセッサにおいて、動作データを車両内の複数のＥＣＵから受信するステップであって、動作データは、複数のＥＣＵの複数のランタイム属性を示す、ステップと、機械学習プロセスを通して、動作データの統計的モデルを生成するステップであって、機械学習プロセスは、複数のランタイム属性に基づく、ステップと、ライブランタイム更新を車両の通信ネットワーク内の複数のＥＣＵから受信するステップと、ライブランタイム更新に基づいて、車両の通信ネットワーク内のＥＣＵと関連付けられたＥＣＵエラーを識別するステップであって、ＥＣＵエラーは、ライブランタイム更新と動作データの統計的モデルの比較によって決定され、動作データからの少なくとも１つの逸脱を識別する、ステップと、ライブランタイム更新に基づいて、車両からの報告を遠隔監視サーバに無線で送信するステップであって、報告は、ＥＣＵおよび識別されたＥＣＵエラーを識別する、ステップとの動作を実施させる、命令を有する、１つ以上のメモリとを備えてもよい。

開示される実施形態によると、ＥＣＵエラーまたは故障を遠隔監視サーバに報告するための方法が、実装されてもよい。本方法は、車両の通信ネットワーク内のプロセッサにおいて、動作データを車両内の複数のＥＣＵから受信するステップであって、動作データは、複数のＥＣＵの複数のランタイム属性を示す、ステップと、機械学習プロセスを通して、動作データの統計的モデルを生成するステップであって、機械学習プロセスは、複数のランタイム属性に基づく、ステップと、ライブランタイム更新を車両の通信ネットワーク内の複数のＥＣＵから受信するステップと、ライブランタイム更新に基づいて、車両の通信ネットワーク内のＥＣＵと関連付けられたＥＣＵエラーを識別するステップであって、ＥＣＵエラーは、ライブランタイム更新と動作データの統計的モデルの比較によって決定され、動作データからの少なくとも１つの逸脱を識別する、ステップと、ライブランタイム更新に基づいて、車両からの報告を遠隔監視サーバに無線で送信するステップであって、報告は、ＥＣＵおよび識別されたＥＣＵエラーを識別する、ステップとを含んでもよい。

開示される実施形態の側面は、１つ以上のプロセッサによって実行されると、開示される実施形態と一致する方法、動作、および同等物のうちの１つ以上のものを実施および実行することが可能となるために構成される、ソフトウェア命令を記憶する、有形コンピュータ可読媒体を含んでもよい。また、開示される実施形態の側面は、実行されると、開示される実施形態と一致する１つ以上の動作を実施する、論理および命令でプログラムされる、ソフトウェア命令に基づく、特殊目的プロセッサとして構成される、１つ以上のプロセッサによって実施されてもよい。

前述の一般的説明および以下の詳細な説明は両方とも、例示的および説明的にすぎず、請求されるような開示される実施形態の制限ではないことを理解されたい。
例えば、本願は以下の項目を提供する。
（項目１）
非一過性コンピュータ可読媒体であって、前記非一過性コンピュータ可読媒体は、命令を含み、前記命令は、少なくとも１つのプロセッサよって実行されると、前記少なくとも１つのプロセッサに、車両内の電子制御ユニット（ＥＣＵ）上のソフトウェアを更新するための更新パッケージを生成するための動作を実施させ、前記動作は、
前記車両内のＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性にアクセスすることと、
前記車両内のＥＣＵ上に記憶される現在のソフトウェアの対応する複数の属性にアクセスすることと、
前記複数の属性と前記対応する複数の属性を比較することと、
前記比較において決定された前記複数の属性と前記対応する複数の属性との間の差異を表すデルタファイルを生成することと、
前記デルタファイルを前記ＥＣＵに提供することであって、前記デルタファイルは、前記デルタファイルが前記車両内のＥＣＵ内で実行することを有効にする前記ＥＣＵ内のスタートアップコードによって処理されるように構成される、ことと
を含む、非一過性コンピュータ可読媒体。
（項目２）
前記スタートアップコードは、前記デルタファイルの中に統合される、項目１に記載の非一過性コンピュータ可読媒体。
（項目３）
前記スタートアップコードは、前記デルタファイルが前記ＥＣＵによって受信される前に、前記ＥＣＵ上にインストールされる、項目１に記載の非一過性コンピュータ可読媒体。
（項目４）
前記スタートアップコードは、前記デルタファイルのランタイムライブラリを初期化するように構成される、項目１に記載の非一過性コンピュータ可読媒体。
（項目５）
前記スタートアップコードは、前記ＥＣＵのプログラムカウンタを更新し、前記デルタファイル内に含有される命令を実行するように構成される、項目１に記載の非一過性コンピュータ可読媒体。
（項目６）
前記デルタファイルは、前記ソフトウェア更新によって参照される変数の値を表す変数データを備える、項目１に記載の非一過性コンピュータ可読媒体。
（項目７）
前記スタートアップコードは、前記変数データを前記デルタファイルから抽出し、前記変数データを前記ＥＣＵにアクセス可能なメモリの中に設置するように構成される、項目６に記載の非一過性コンピュータ可読媒体。
（項目８）
前記デルタファイルは、前記ＥＣＵ内のメモリアドレスを更新するためのコードを備える、項目１に記載の非一過性コンピュータ可読媒体。
（項目９）
前記スタートアップコードは、メモリアドレスを更新するためのコードを抽出し、前記ＥＣＵ内のメモリアドレスを更新するように構成される、項目８に記載の非一過性コンピュータ可読媒体。
（項目１０）
前記ＥＣＵ上のソフトウェアは、複数の機能ユニットにマッピングされ、前記ＥＣＵは、仮想ファイルシステム（ＶＦＳ）を利用して、前記複数の機能ユニットのそれぞれの１つ以上のバージョンを管理および追跡するように構成される、項目１に記載の非一過性コンピュータ可読媒体。
（項目１１）
前記ＥＣＵ上に記憶されるべき前記ソフトウェア更新の複数の属性は、前記ＶＦＳによって管理される前記複数の機能ユニットのうちの少なくとも１つを備える、項目１０に記載の非一過性コンピュータ可読媒体。
（項目１２）
前記命令はさらに、
第１のグリッドを前記ソフトウェア更新に適用することと、
第２のグリッドを前記ＥＣＵ上に記憶される現在のソフトウェアに適用することと、
前記第１および第２のグリッドの比較に基づいて、前記複数の属性および前記対応する複数の属性を識別することと
を含む、項目１に記載の非一過性コンピュータ可読媒体。
（項目１３）
前記第１のグリッドは、
前記ソフトウェア更新と関連付けられたバイナリデータと、
前記ソフトウェア更新と関連付けられたソース属性と、
前記ソフトウェア更新と関連付けられたマップファイルと
のうちの少なくとも１つを含む１つ以上の次元における前記ソフトウェア更新を表す、項目１２に記載の非一過性コンピュータ可読媒体。
（項目１４）
前記複数の属性は、少なくとも部分的に、前記ソフトウェア更新を開発するために使用されるプログラミング言語に基づいて識別される、項目１に記載の非一過性コンピュータ可読媒体。
（項目１５）
前記複数の属性は、少なくとも部分的に、前記ソフトウェア更新のバイナリファイル分解能に基づいて識別される、項目１に記載の非一過性コンピュータ可読媒体。
（項目１６）
前記複数の属性は、少なくとも部分的に、前記ソフトウェア更新と関連付けられたマップファイルに基づいて識別される、項目１に記載の非一過性コンピュータ可読媒体。
（項目１７）
前記ソフトウェア更新は、モノリシックファイルである、項目１に記載の非一過性コンピュータ可読媒体。
（項目１８）
前記ソフトウェア更新は、他のファイルに相互依存するファイルである、項目１に記載の非一過性コンピュータ可読媒体。
（項目１９）
前記動作は、前記デルタファイルを前記ＥＣＵに提供する前に、依存性システムをチェックし、前記ＥＣＵのために提供されている前記デルタファイルに基づいて、任意の相互依存ＥＣＵが更新されるべきであるかどうかを決定することを含む、項目１に記載の非一過性コンピュータ可読媒体。
（項目２０）
前記動作はさらに、付加的デルタファイルを前記相互依存ＥＣＵに自動的に提供し、前記相互依存ＥＣＵに関するソフトウェア更新を実施することを含む、項目１９に記載の非一過性コンピュータ可読媒体。
（項目２１）
車両内の電子制御ユニット（ＥＣＵ）上のソフトウェアを更新するための更新パッケージを生成するためのシステムであって、前記システムは、
１つ以上のプロセッサと、
１つ以上のメモリであって、前記１つ以上のメモリは、命令を有し、前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
前記車両内のＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性にアクセスする動作と、
前記車両内のＥＣＵ上に記憶される現在のソフトウェアの対応する複数の属性にアクセスする動作と、
前記複数の属性と前記対応する複数の属性を比較する動作と、
前記比較において決定された前記複数の属性と前記対応する複数の属性との間の差異を表すデルタファイルを生成する動作と、
前記デルタファイルを前記ＥＣＵに提供する動作であって、前記デルタファイルは、前記デルタファイルが前記車両内のＥＣＵ内で実行することを有効にする前記ＥＣＵ内のスタートアップコードによって処理されるように構成される、動作と
を実施させる、１つ以上のメモリと
を備える、システム。
（項目２２）
前記スタートアップコードは、前記デルタファイルのランタイムライブラリを初期化するように構成される、項目２１に記載のシステム。
（項目２３）
車両内の電子制御ユニット（ＥＣＵ）上のソフトウェアを更新するための更新パッケージを生成するためのコンピュータ実装方法であって、前記方法は、
前記車両内のＥＣＵ上に記憶されるべきソフトウェア更新の複数の属性にアクセスすることと、
前記車両内のＥＣＵ上に記憶される現在のソフトウェアの対応する複数の属性にアクセスすることと、
前記複数の属性と前記対応する複数の属性を比較することと、
前記比較において決定された前記複数の属性と前記対応する複数の属性との間の差異を表すデルタファイルを生成することと、
前記デルタファイルを前記ＥＣＵに提供することであって、前記デルタファイルは、前記デルタファイルが前記車両内のＥＣＵ内で実行することを有効にする前記ＥＣＵ内のスタートアップコードによって処理されるように構成される、ことと
を含む、方法。
（項目２４）
前記スタートアップコードは、前記デルタファイルのランタイムライブラリを初期化するように構成される、項目２３に記載の方法。

本明細書内に組み込まれ、その一部を構成する、付随の図面は、開示される実施形態を図示し、説明とともに、開示される実施形態を説明する役割を果たす。

図１Ａは、開示される実施形態による、例示的システムのブロック図である。

図１Ｂは、開示される実施形態による、デルタファイルが作成および展開され得、ＥＣＵ動作が監視され得る、システム環境の例証である。

図１Ｃは、開示される実施形態による、車両通信ネットワークの例証である。

図２は、開示される実施形態による、例示的ＥＣＵソフトウェア更新プロセスを描写する、例証である。

図３は、開示される実施形態による、デルタファイルを生成するための例示的プロセスを描写する、例証である。

図４は、開示される実施形態による、ＥＣＵのプログラムカウンタを更新するように構成される、スタートアップコードを描写する、例証である。

図５は、開示される実施形態による、コードの異なるセグメントへのコード変更を含む、デルタファイルを描写する、例証である。

図６は、開示される実施形態による、更新のためにＥＣＵに利用可能となるデルタファイルを描写する、例証である。

図７は、開示される実施形態による、更新のためにＥＣＵに利用可能となるデルタファイルを描写する、別の例証である。

図８は、開示される実施形態による、更新のためにＥＣＵに利用可能となるデルタファイルを描写する、さらなる例証である。

図９は、開示される実施形態による、ＥＣＵに利用可能となるソフトウェア更新のタイムライン図を描写する、例証である。

図１０は、開示される実施形態による、車両内のＥＣＵ上のソフトウェアを更新するための更新パッケージを生成するためのプロセスを示す、例示的フローチャートである。

図１１は、開示される実施形態による、デルタファイルを車両内で受信および統合するためのプロセスを示す、例示的フローチャートである。

図１２は、開示される実施形態による、車両のＥＣＵが動作している間、更新をＥＣＵソフトウェアに実施するためのプロセスを示す、例示的フローチャートである。

図１３は、開示される実施形態による、車両ＥＣＵソフトウェアバージョンを調節するためのプロセスを示す、例示的フローチャートである。

図１４は、開示される実施形態による、車両内のＥＣＵ異常を識別するためのプロセスを示す、例示的フローチャートである。

図１５は、開示される実施形態による、車両内のＥＣＵ異常を識別するためのプロセスを示す、例示的フローチャートである。

図１６は、開示される実施形態による、車両内のＥＣＵソフトウェアを好機をねらって更新するためのプロセスを示す、例示的フローチャートである。

図１７は、開示される実施形態による、更新を１つ以上の車両に自動的に提供するためのプロセスを示す、例示的フローチャートである。

図１８は、開示される実施形態による、ＥＣＵエラーを遠隔監視サーバに報告するためのプロセスを示す、例示的フローチャートである。

以下の詳細な説明では、多数の具体的詳細が、開示される例示的実施形態の完全な理解を提供するために記載される。しかしながら、当業者によって、例示的実施形態の原理は、全ての具体的詳細を伴わずに実践されてもよいことが理解されるであろう。周知の方法、プロシージャ、およびコンポーネントは、例示的実施形態の原理を曖昧にしないように、詳細に説明されていない。明示的に述べられない限り、本明細書に説明される例示的方法およびプロセスは、特定の順序またはシーケンスに制約されない、または特定のシステム構成に制約されない。加えて、説明される実施形態またはその要素のうちのいくつかは、同時に、同一時点において、または並行して、生じる、または実施され得る。

ここで、開示される実施形態が詳細に参照され、その実施例は、付随の図面に図示される。

図１Ａは、開示される実施形態による、例示的システム１００のブロック図である。示されるように、システム１００は、通信チャネル１０６を経由して１つ以上の車両１０４と通信するように構成される、１つ以上のサーバ（またはコンピュータ）１０２を含む。通信チャネル１０６は、バス、ケーブル、無線通信チャネル、無線ベースの通信チャネル、インターネット、ローカルエリアネットワーク（ＬＡＮ）、無線ローカルエリアネットワーク（ＷＬＡＮ）、広域ネットワーク（ＷＡＮ）、セルラー通信ネットワーク、または任意のインターネットプロトコル（ＩＰ）ベースの通信ネットワーク、および同等物を含んでもよい。いくつかの実施形態では、通信チャネル１０６は、パブリッククラウドインフラストラクチャ、プライベートクラウドインフラストラクチャ、ハイブリッドパブリック／プライベートクラウドインフラストラクチャ、またはクラウドを使用しないインフラストラクチャに基づいてもよい。そのような異なる実施形態では、サーバ１０２および車両１０４はそれぞれ、同一または異なるネットワークまたはネットワークセグメント内にあってもよい。いくつかの実施形態では、車両１０４は、通信チャネル１０６を介したサーバ１０２との通信をサポートするように構成される、１つ以上の互換性がある受信機を装備してもよい。受信機は、例証的簡略化のために図１Ａに示されない。

サーバ１０２は、少なくとも１つのプロセッサ１０８を含んでもよい。複数のサーバ（例えば、サーバファーム）を伴う実施形態では、プロセッサ１０８は、１つ以上の専用処理ユニット、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡＳ）、またはプロセッサ実行可能コードを記憶するために構成される少なくとも１つの非一過性プロセッサ可読メモリ１１０と結合される、種々の他のタイプのプロセッサまたは処理ユニットを含んでもよい。プロセッサ実行可能コードが、プロセッサ１０８によって実行されると、プロセッサ１０８は、種々の異なる命令を行ってもよい（例えば、１つ以上の車両１０４内にインストールされる１つ以上のＥＣＵが更新される必要があるかどうかを決定する等のため）。プロセッサ１０８はまた、１つ以上の車両１０４内にインストールされる１つ以上のＥＣＵが更新される必要があると決定されると、ＥＣＵのための更新パッケージを生成する命令を行ってもよい。下記に議論されるように、プロセッサ１０８はまた、種々の他の機能を実施してもよい。

サーバ１０２は、種々のタイプのユーザにサービス提供するように構成されてもよいことが検討される。例えば、自動車製造業者は、サーバ１０２を利用して、ソフトウェア更新を生成し、自動車製造業者によって製造された車両上にインストールされるＥＣＵにロールアウトしてもよい。別の実施例では、部品製造業者（例えば、ＥＣＵ開発者またはその製品がＥＣＵを使用する製造業者）は、サーバ１０２を利用して、ソフトウェア更新を生成し、その部品製造業者によって生産または維持されるＥＣＵにロールアウトしてもよい。なおも別の実施例では、サービスプロバイダ（例えば、販売業者またはサービスセンタ）は、サーバ１０２を利用して、サービスプロバイダにおいて点検されている、車両上にインストールされるＥＣＵを更新してもよい。１つのみのサーバ１０２が、図１Ａに描写されるが、そのような描写は、単に、例示的であって、限定を意味するものではないことを理解されたい。本開示の精神および範囲から逸脱することなく、１つを上回るサーバ１０２が、利用されてもよく、異なるユーザが、異なるサーバ１０２を利用して、ソフトウェア更新を生成し、ＥＣＵにロールアウトしてもよいことが検討される。

図１Ｂは、デルタファイルおよびソフトウェア更新が生成および監視され得る、システム環境の例示的例証である。図示されるように、生産ツールチェーン１２２は、車両ＥＣＵ（例えば、ＥＣＵ１１２）上で起動するソフトウェアを開発および配布するためのプログラミングシステムまたはツールのグループであってもよい。生産ツールチェーン１２２は、ソフトウェアを車両ＥＣＵ上に開発および実装するためのソフトウェアコンポーネント（例えば、コンパイラ、リンカ、ライブラリ等）を含んでもよい。さらに下記に議論されるように、本開示の実施形態は、ソフトウェア更新のためのデルタファイルを生成するステップに関し、生産ツールチェーン１２２からの情報に基づいて生成されてもよい。例えば、下記に議論されるように、デルタファイルを構築するために使用されるマップファイル、ソース、およびバイナリデータ要素（例えば、図３に関連して）は、生産ツールチェーン１２２から生じてもよい。ソフトウェア更新は、デルタファイル１２４として開発されてもよく、これは、図１Ａに関連してさらに議論されるように、無線を経由して車両に送達されてもよい。

図１Ｂはまた、依存性管理システム１２６と、故障分析システム１２８と、更新管理システム１３０と、報告システム１３２とを図示する。下記に議論される種々の実施形態では、ソフトウェアバージョン間の依存性は、ソフトウェア内の機能とエンティティとの間の関係および依存性、ソフトウェアのサイズ、具体的メモリアドレス、メモリ場所に対応する具体的機能またはコマンド等を定義する、マップファイルとして表され得る。さらに、依存性管理システム１２６は、ＥＣＵ間の依存性を識別してもよい。例えば、ソフトウェア更新が、１つのＥＣＵのために実施されるとき、更新は、ＥＣＵが１つ以上の他のＥＣＵと通信することを不可能にさせ得る（または正しくなく通信する）。これは、例えば、ソフトウェア更新が、ＥＣＵのネットワークアドレス、ＥＣＵが使用するであろう通信のプロトコル、ＥＣＵの着信または発信通信ポリシ、ＥＣＵからの通信のヘッダまたはペイロード、ＥＣＵからの通信のタイミング、またはＥＣＵの機能性の種々の他の属性に影響を及ぼす場合に生じ得る。ソフトウェア更新がＥＣＵ上で実施され、他の相互依存ＥＣＵが影響されるときに生じる、競合を防止するために、依存性管理システム１２６は、ＥＣＵ間の依存性のリストまたはマッピングを維持するように構成されてもよい。リストまたはマッピングは、相互依存ＥＣＵを識別してもよく、また、その相互依存性に関する理由（例えば、予期または要求されるデータ通信の特定のフォーマット、特定のネットワークアドレス、特定の通信タイミング要件等）をさらに規定してもよい。本情報は、依存性管理システム１２６によって維持されてもよく、周期的に更新されてもよい（例えば、サーバ１０２から）。

さらに、下記に議論されるように、種々の異常、エラー、および故障が、ＥＣＵの動作時に検出され得る。そのようなデータおよびそのようなイベントを検出するためのアルゴリズムは、故障分析システム１２８によって管理されてもよい。更新管理システム１３０は、ＥＣＵソフトウェア更新が開発または伝送されるべきとき、更新を受信すべき車両または具体的ＥＣＵ、および種々の他のタイプの情報を決定するステップに関与してもよい。報告システム１３２は、更新を車両（例えば、ＥＣＵの観察されるアクティビティ）から受信する、または（例えば、実施するための更新に関する）報告を車両に送達するように構成されてもよい。いくつかの実施形態では、依存性管理システム１２６、故障分析システム１２８、更新管理システム１３０、および報告システム１３２は、サーバ１０２内で、または別個に、実装されてもよい。

図１Ｃは、（例えば、車両１０４－ａ、１０４－ｂ、１０４－ｃ、１０４－ｄ、または１０４－ｅ内の）車両通信ネットワーク内のアーキテクチャの例証である。例えば、テレマティック制御ユニット（ＴＣＵ）１３４が、ネットワークの中に統合され、車両のための種々の追跡特徴を実施してもよい。いくつかの実施形態では、ＴＣＵ１３４は、統合または別個の電気通信送受信機（例えば、セルラー、ＷｉＦｉ、衛星等）、全地球測位システム（ＧＰＳ）送受信機、および車両通信ネットワークの他のコンポーネントとインターフェースをとるためのコントローラを含んでもよい。ネットワークはまた、外部ネットワーク（例えば、サーバ１０２）および車両の内部ネットワークとの通信の中心点であり得る、ゲートウェイ１３６を含んでもよい。いくつかの実施形態では、ゲートウェイ１３６は、オーケストレータ（下記にさらに議論される）とインターフェースをとってもよく、これは、車両内のＥＣＵ１１２の１つ以上の動作を制御する。ネットワークはさらに、オンボード診断ポート１３８を含んでもよく、これは、診断、保守、および他の機能のために、車両ネットワークへの有線接続を可能にする、物理的ポートであってもよい。加えて、車両ネットワークは、ＥＣＵ１１２、１１２ａ、１１２ｂ、１１２ｃ、およびその他等の種々のＥＣＵを含んでもよい。図示されるように、ＥＣＵ１１２は、他の動作の中でもとりわけ、故障検出および休止時間予測１４０、ＥＣＵソフトウェアの以前のバージョンへの統合されたロールバック１４２、および統合された診断サービス（ＵＤＳ）更新１４４のためのソフトウェア命令で構成されてもよい。これらの機能はさらに、下記に議論される。

図２は、例示的ＥＣＵ１１２のソフトウェアを更新するためにサーバ１０２によって行われる例示的ＥＣＵソフトウェア更新プロセスを描写する、例証である。いくつかの実施形態では、プロセスは、サーバ１０２においてではなく、車両内でローカルで実施されてもよい（例えば、ＥＣＵ１１８を管理する、車両内のオーケストレータを通して）。図２に示されるように、サーバ１０２は、ＥＣＵ１１２によって使用されるべきＥＣＵソフトウェアの新しいバージョン（ソフトウェア更新２０２と称され得る）およびＥＣＵ１１２によって使用されるＥＣＵソフトウェアの現在のバージョン（現在のソフトウェア２０４と称され得る）の両方に関する情報にアクセスしてもよい。サーバ１０２は、種々の様式において、ソフトウェア更新２０２に関する情報にアクセスしてもよい。いくつかの実施形態では、ＥＣＵソフトウェアを開発または維持することに関与する自動車製造業者または部品製造業者は、ローカルで記憶されるべきソフトウェア更新２０２のコピーをサーバ１０２上に提供してもよい。いくつかの実施形態では、ソフトウェア更新２０２を開発するために使用されるワークステーションが、サーバ１０２としての役割を果たすように構成されてもよい。いくつかの実施形態では、自動車製造業者または部品製造業者はまた、ソフトウェア更新２０２のコピーをサーバ１０２にアクセス可能な１つ以上のネットワーク記憶デバイス内に記憶してもよい。いくつかの実施形態では、ソフトウェア更新２０２は、モノリシックファイルとして提供されてもよい。いくつかの実施形態では、ソフトウェア更新２０２は、他のファイルに相互依存するファイルとして提供されてもよい。

サーバ１０２は、種々の様式において、ＥＣＵ１１２によって使用される現在のソフトウェア２０４に関する情報にアクセスしてもよい。いくつかの実施形態では、サーバ１０２は、そのソフトウェアバージョン番号に関して、ＥＣＵ１１２にクエリしてもよい（例えば、通信チャネル１０６を介して）。いくつかの実施形態では、サーバ１０２は、ＥＣＵ１１２によって使用される現在のソフトウェア２０４が記憶される、メモリデバイス（例えば、フラッシュメモリ、ＲＡＭ、ＲＯＭ等）１２０への直接アクセスを要求してもよい。いくつかの実施形態では、サーバ１０２は、ＥＣＵに展開されるソフトウェアバージョンを記録し、記録を使用して、ＥＣＵ１１２によって使用される現在のソフトウェア２０４のバージョンを決定してもよい。具体的実装は、サーバ１０２がソフトウェア更新２０２および現在のソフトウェア２０４の両方に関する情報にアクセスすることができる限り、変動し得るが、サーバ１０２は、さらに下記に議論されるように、ソフトウェア更新２０２および現在のソフトウェア２０４の両方の属性を比較し、ソフトウェア更新２０２の属性と現在のソフトウェア２０４の対応する属性との間の差異を表す、デルタファイルを生成することができることが検討される。

図３は、そのようなデルタファイルを生成するためにサーバ１０２によって行われる例示的プロセスを描写する、例証である。図３に示されるように、サーバ１０２は、ソフトウェア更新２０２のソース、バイナリコード、およびマップファイルを含む、属性と、現在のソフトウェア２０４のその対応する属性を比較してもよい。上記に議論されるように、これらの属性は、直接、生産ツールチェーン１２２から取得されてもよい（例えば、ソフトウェアを構築および展開するプロセスの一部として、またはそれに続いて）。ソース属性は、例えば、ソースコード言語、バージョン、ソースコードがフラットであるかどうか、ソースコード内で参照されるオブジェクトの数またはタイプ、および他の属性を識別してもよい。バイナリ属性は、実行可能かつリンク可能なフォーマット（ＥＬＦ）コード（例えば、プログラムヘッダ、セクションヘッダ、データ等を伴う）として、純粋なバイナリとして、または他の形態において表され得る。マップファイルは、ソフトウェア２０２および／または２０４内の機能とエンティティとの間の関係および依存性、ソフトウェアのサイズ、具体的メモリアドレス、メモリ場所に対応する具体的機能またはコマンド等を説明してもよい。

ソフトウェア更新２０２および現在のソフトウェア２０４をそのソース、バイナリコード、およびマップファイル属性の観点から表すことは、「グリッド」表現と称され得、ソフトウェア更新２０２を表すグリッドと現在のソフトウェア２０４を表すグリッドとの間の比較は、多次元（例えば、３次元差分（または３Ｄｉｆｆ）比較）と称され得る。いくつかの実施形態では、より少ないまたは付加的次元も、同様に使用されてもよい。そのような３Ｄｉｆｆ比較または他の多次元比較は、ＥＣＵ１１２のバイナリおよび／またはソースコード２１０に行われる変更、ＥＣＵ１１２によって使用される１つ以上の変数２１２に行われる変更、およびＥＣＵ１１２によって参照されるメモリアドレス２１４に行われる変更を表すデータを含み得る、デルタファイル２０６を生産するために利用されてもよい。着目すべきこととして、そのような３Ｄｉｆｆファイルは、現在のソフトウェア２０４が、ソフトウェア更新２０２自体全体ではなく、３Ｄｉｆｆファイルのみを受信することによって、ソフトウェア更新２０２にアップグレードされ得るように、ソフトウェア更新２０２と現在のソフトウェア２０４との間の差異を表してもよい。

また、図３に示されるのは、スタートアップコード２０８であって、これは、３Ｄｉｆｆまたはデルタファイル２０６の中に統合されてもよい。代替として、スタートアップコード２０８は、現在のソフトウェア２０４の一部であって、デルタファイル２０６の一部ではなくてもよい。例えば、そのような実施形態では、スタートアップコード２０８は、ＥＣＵおよびそのソフトウェアと関連付けられた既存のスタートアップまたは初期化コードであってもよい。

いくつかの実施形態では、サーバ１０２は、スタートアップコード２０８をデルタファイル２０６のランタイムライブラリを初期化するように構成してもよい。いくつかの実施形態では、例えば、サーバ１０２は、スタートアップコード２０８を、ＥＣＵ１１２のプログラムカウンタを更新し、現在のソフトウェア２０４内に含有されるあるコードをスキップし、代わりに、デルタファイル２０６内に含有されるあるコードを実行するように構成してもよい。例えば、図４に示されるように、スタートアップコード２０８は、ＥＣＵ１１２が、現在のソフトウェア２０４内に含有されるコードのセグメントをスキップし（図４では、プログラムカウンタ更新「１」として描写される）、代わりに、デルタファイル２０６内に含有されるコードのセグメントを実行し得るように（図４では、プログラムカウンタ更新「２」として描写される）、ＥＣＵ１１２のプログラムカウンタを更新するように構成されてもよい。サーバ１０２はまた、デルタファイル２０６内に含有されるコードのセグメントの実行後、プログラムカウンタが、現在のソフトウェア２０４内に含有されるコードにリンクバックし得るように（図４では、プログラムカウンタ更新「３」として描写される）、スタートアップコード２０８をＥＣＵ１１２のプログラムカウンタを更新するように構成してもよい。このように、デルタファイル２０６内に含有されるコードのセグメントは、メモリ１２０内の任意の場所に設置されることができ、ＥＣＵ１１２のプログラムカウンタは、ＥＣＵ１１２の実行のために、コードのそのセグメントをメモリ（例えば、フラッシュ、ＲＡＭ等）の中にロードするために使用されることができる。言い換えると、デルタファイル２０６内に含有されるコードは、位置独立的であり得、ＥＣＵ１１２がメモリ１２０の任意の既存のコンテンツを消去することを要求せずに、メモリ１２０内に設置されることができる。さらに、スタートアップコード２０８は、デルタデータを３Ｄｉｆｆまたはデルタファイル２０６から抽出し、それをＥＣＵ１１２のメモリ（例えば、フラッシュ、ＲＡＭ、ＲＯＭ等）上に記憶するように構成されてもよい。データは、ソフトウェア２０２／２０４のランタイムの間に使用されるデータを含んでもよい。スタートアップコードはまた、ＥＣＵ１１２内のメモリの古いコンテンツが消去される必要があるかどうかを決定してもよい（例えば、記憶空間がほぼ満杯であるため）。

ＥＣＵ１１２のプログラムカウンタを使用して、デルタファイル２０６内に含有されるコードをＥＣＵ１１２のメモリの中にロードするステップは、単に、実施例として提示され、限定を意味するものではないことを理解されたい。いくつかの実施形態では、ブートストラップローダ（例えば、ＥＣＵ１１２のメモリ内に常駐するプログラム）が、代わりに、または併せて、デルタファイル２０６内に含有されるコードをＥＣＵ１１２のメモリの中にロードするために使用されてもよい。他の技法もまた、本開示の精神および範囲から逸脱することなく、実行のために、デルタファイル２０６内に含有されるコードをＥＣＵ１１２のメモリの中にロードするために使用されてもよいことを理解されたい。

また、図４は、ＥＣＵ１１２のプログラムカウンタを現在のソフトウェア２０４内に含有されるコードの１つのセグメントからデルタファイル２０６内に含有されるコードの別のセグメントにリダイレクトするステップを描写するが、そのような描写は、単に、例示的であることを理解されたい。デルタファイル２０６内に含有されるコード変更２１０は、現在のソフトウェア２０４内に含有されるコードの１つを上回るセグメントに行われる変更を表し得ることが検討される。例えば、図５に示されるように、デルタファイル２０６は、「シンボル１」、「シンボル２」、および「シンボル３」と称される、コードの３つの異なるセグメントへのコード変更を含んでもよい。これらのコード変更は、上記に説明されるものに類似する様式においてハンドリングされ得ることが検討される。すなわち、デルタファイル２０６内（または、代替として、現在のソフトウェア２０４内）に含有されるスタートアップコードは、ＥＣＵ１１２のプログラムカウンタを更新し、ＥＣＵ１１２の現在のソフトウェア２０４内に含有されるコードのあるセグメント（すなわち、シンボル）をスキップし、代わりに、実行のために、デルタファイル２０６内に含有されるコードの対応するセグメント（すなわち、対応するシンボル）をＥＣＵ１１２のメモリ（例えば、フラッシュ、ＲＡＭ等）の中にロードしてもよい。

いくつかの実施形態では、ＥＣＵ１１２は、仮想ファイルシステム（ＶＦＳ）２３０を利用して、シンボルを管理してもよい。本明細書に議論されるように、ＶＦＳ２３０は、種々の異なるタイプの仮想ファイルシステム、データベース、またはリストであってもよい。ＶＦＳ２３０は、ソフトウェア２０２／２０４の要約を提供してもよく、３Ｄｉｆｆファイルの要素（例えば、ソース、バイナリ、およびマップファイル属性）を表してもよい。いくつかの実施形態では、ＥＣＵ１１２は、ＶＦＳ２３０を利用して、異なるバージョンのシンボルを追跡してもよい。例えば、図６に示されるように、第２のデルタファイル２１６（第２のソフトウェア更新において行われる変更を表す）が、ＥＣＵ１１２に利用可能になる場合、かつ第２のデルタファイル２１６が、シンボル１およびシンボル２に行われるコード変更のバージョン２を含有する場合、ＥＣＵ１１２は、ＶＦＳ２３０を利用して、異なるバージョンのシンボルを追跡し、実行のために使用されるべき正しいバージョンを決定してもよい。第３のデルタファイル２２６（第３のソフトウェア更新に行われる変更を表す）が、ＥＣＵ１１２に利用可能になる場合、かつ第３のデルタファイル２２６が、シンボル１に行われるコード変更のバージョン３を含有する場合、ＥＣＵ１１２はまた、図７に示されるように、ＶＦＳ２３０を利用して、シンボル１のバージョン３を追跡してもよい。

いくつかの実施形態では、ＥＣＵ１１２は、ＶＦＳ２３０を利用して、必要とされる場合、ＥＣＵ１１２のソフトウェアへのある変更をロールバックしてもよい。例えば、ＥＣＵ１１２の性能におけるある異常（その詳細は、後で説明されるであろう）の検出に応じて、サーバ１０２は、シンボル１のバージョン３が、実行不可能にされる（または無効にされる）べきであって、ＥＣＵソフトウェアが、前のバージョン（例えば、第２のソフトウェア更新）に戻されるべきであることを決定してもよい。サーバ１０２は、ＥＣＵ１１２に第２のソフトウェア更新にロールバックするようにプロンプトすることによって、これを達成し得、ＥＣＵ１１２は、ひいては、図８に示されるように、ＶＦＳ２３０を利用して、これらのシンボルに対応するＥＣＵ１１２内のメモリアドレスを更新することによって、シンボル１、バージョン２を復元させてもよい（かつシンボル１、バージョン３を無効にする）。事実上、シンボル１のバージョン３は、ＥＣＵ１１２のメモリ（例えば、フラッシュ、ＲＡＭ等）から除去され得、シンボル１のバージョン２は、代わりに、実行のために、ＥＣＵ１１２のメモリの中にロードされ得る。しかしながら、着目すべきこととして、シンボル１のバージョン３を削除し、シンボル１のバージョン２のコピー全体をダウンロードする必要がない。代わりに、さらに下記に議論されるように、ＥＣＵ１１２は、単に、デルタファイル２０６を受信し、更新される必要がある（ソース、バイナリ、およびマップファイル属性に基づいて）ＥＣＵ１１２のメモリへの更新を識別し、シンボル１のバージョン２への復元を遂行し得る。本技法を使用して、帯域幅は、ＥＣＵ１１２への伝送において低減され、ＥＣＵ１１２内のメモリ空間もまた、節約される。本技法は、下記にさらに議論される。

ここで、図３に戻って参照する。コード変更をハンドリングすることに加え、サーバ１０２はまた、スタートアップコード２０８を、ＥＣＵ１１２によって使用される変数に行われる変更およびＥＣＵ１１２によって参照されるメモリアドレスに行われる変更をハンドリングするように構成してもよいことに留意されたい。具体的には、いくつかの実施形態では、サーバ１０２は、スタートアップコード２０８を、変数変更データ２１２をデルタファイル２０６から抽出し、抽出された変数データ（該当する場合）をＥＣＵ１１２のメモリ（例えば、フラッシュ、ＲＡＭ等）の中に設置するように構成してもよい。上記に述べられたように、スタートアップコード２０８は、デルタファイル２０６自体または現在のソフトウェア２０４内に位置してもよい。サーバ１０２はまた、スタートアップコード２０８を、古い（陳腐化した）変数データをＥＣＵ１１２のメモリから削除する命令を含むように構成してもよい。サーバ１０２はさらに、スタートアップコード２０８を、メモリアドレス変更データ２１４（該当する場合）をデルタファイル２０６から抽出し、適宜、ＥＣＵ１１２内のメモリアドレスを更新するように構成してもよい。このように、サーバ１０２は、単に、任意の変更を現在のソフトウェア２０４に行う必要なく、デルタファイル２０６をメモリ１２０の中に設置し、ＥＣＵ１１２にデルタファイル２０６または現在のソフトウェア２０４内に含有されるスタートアップコード２０８を実行させ、現在のソフトウェア２０４およびデルタファイル２０６をともにリンクさせ、ＥＣＵ１１２をリブートする必要なく、ソフトウェア更新２０２の機能均等物を形成し得る。

いくつかの実施形態では、デルタファイル２０６は、標準的１６進数またはバイナリファイル（またはＳＲｅｃｏｒｄ、Ｍｏｔｏｒｏｌａ（登録商標）、およびその他等の他のタイプ）として実装されてもよく、これは、ＥＣＵ１１２によって容易に処理されることができる。いくつかの実施形態では、ＥＣＵ１１２は、デルタファイル２０６がメモリ１２０の中に設置されるにつれて、その動作を継続してもよい（例えば、現在のソフトウェア２０４内に含有されるコードの実行を継続する）。いくつかの実施形態では、ＥＣＵ１１２は、上記に説明される更新プロセスを完了した後、メモリ１２０をデフラグメントしてもよい。しかしながら、メモリ１２０をデフラグメントするステップは、ソフトウェア更新毎にではなく、低頻度でのみ必要とされ得ることが検討される。

更新プロセスは、後続ソフトウェア更新が利用可能になるにつれて、数回、繰り返されてもよい。図９に図示されるように、時間Ｔ１において、第１のソフトウェア更新が、利用可能になり、サーバ１０２が、デルタファイル２０６を生成し、デルタファイル２０６をＥＣＵ１１２に提供したとする。いったんデルタファイル２０６が、ＥＣＵ１１２において受信される（かつメモリ１２０の中に記憶される）と、ＥＣＵ１１２は、上記に説明されるように、その中に含有されるスタートアップコードに基づいて、デルタファイル２０６を実行し、デルタファイル２０６をＥＣＵ１１２のソフトウェア２０４にリンクさせてもよい。時間Ｔ２において、第２のソフトウェア更新が利用可能になり、第１のソフトウェア更新に取って代わる場合、サーバ１０２は、上記に説明されるプロセスを繰り返してもよい（例えば、第２のソフトウェア更新とＥＣＵ１１２のソフトウェア２０４を比較し、第２のデルタファイル２１６を生成し、第２のデルタファイル２１６をＥＣＵ１１２に提供する）。いったん第２のデルタファイル２１６が、ＥＣＵ１１２において受信される（かつメモリ１２０の中に記憶される）と、ＥＣＵ１１２は、その中に含有されるスタートアップコードに基づいて、第２のデルタファイル２１６を実行し、第２のデルタファイル２１６をＥＣＵ１１２のソフトウェア２０４にリンクさせてもよい。同様に、時間Ｔ３において、第３のソフトウェア更新が利用可能になる場合、サーバ１０２は、第３のデルタファイル２２６をＥＣＵ１１２に提供してもよく、ＥＣＵ１１２は、適宜、第３のデルタファイル２２６をＥＣＵ１１２のソフトウェア２０４にリンクさせてもよい。

また、図９に図示されるのは、サーバ１０２が特定のソフトウェア更新にロールバックする能力である。例えば、時間Ｔ４におけるある異常（その詳細は、後で説明されるであろう）の検出に応じて、サーバ１０２は、第３のソフトウェア更新が、実行不可能にされるべきであって、ＥＣＵソフトウェアが、前のバージョン（例えば、第２のソフトウェア更新）に戻されるべきことを決定してもよい。サーバ１０２は、図９に示されるように、ＥＣＵ１１２に第３のデルタファイル２２６とＥＣＵ１１２のソフトウェア２０４との間のリンクを除去する（例えば、図８を参照して前述のように、デルタファイル２２６内に含有されるコード変更を実行不可能にする）、第２のデルタファイル２１６内に含有されるスタートアップコードを再実行し、第２のデルタファイル２１６とＥＣＵ１１２のソフトウェア２０４との間のリンクを再確立するようにプロンプトすることによって、これを達成し得る。

いくつかの実施形態では、ＥＣＵ１１２は、ロールバック動作後、第３のデルタファイル２２６をメモリ１２０内に保つように構成されてもよい。第３のデルタファイル２２６をメモリ１２０内に保つことは、ＥＣＵ１１２が、必要とされる場合、第３のソフトウェア更新を後で再アクティブ化することを可能にし得る。

いくつかの実施形態では、サーバ１０２は、ＥＣＵ１１２を将来的更新のために備えるための方法として、意図的に、第３のデルタファイル２２６をメモリ１２０の中にプッシュ配信してもよい。サーバ１０２は、例えば、第３のデルタファイル２２６がメモリ１２０の中にプッシュ配信されると、ＥＣＵ１１２に、第３のデルタファイル２２６内に含有されるスタートアップコードを一時的にバイパスするように命令してもよい。第２のデルタファイル２１６とＥＣＵ１１２のソフトウェア２０４との間のリンクは、したがって、サーバ１０２が、ＥＣＵ１１２に、次いで、第３のデルタファイル２２６をＥＣＵ１１２のソフトウェア２０４にリンクさせ、第３のソフトウェア更新の展開を完了させ得る、第３のデルタファイル２２６（または現在のソフトウェア２０４）内に含有されるスタートアップコードを実行するように命令するときのような時間まで、定位置に留まり得る。そのような動作は、ロールフォワードと称され得、これは、ＥＣＵソフトウェア更新のロールアウトを協調させるための技法として利用されてもよいことが検討される。

しかしながら、メモリ１２０内に記憶されることができるデルタファイルの数は、その記憶容量に起因して限定され得ることに留意されたい。したがって、いくつかの実施形態では、ＥＣＵ１１２は、ＥＣＵ１１２が、メモリ１２０の利用量が閾値を上回る（例えば、７５％または９０％満杯）ことを決定すると、削除のためのメモリ１２０内に記憶される具体的コンテンツを識別するように構成されてもよい。いくつかの実施形態では、ＥＣＵ１１２は、その対応する作成日、バージョン番号、ファイルサイズ、または同等物に基づいて、削除のためのコンテンツを識別してもよい。例えば、長期間にわたって使用されていない古いデルタファイルは、削除のための良好な候補であり得る。いくつかの実施形態では、ＥＣＵ１１２はまた、そのメモリコンテンツを全体的に置換することを選定してもよい。例えば、そのオリジナルソフトウェアに加え、過去数年にわたって受信された複数のデルタファイルを保つ代わりに、ＥＣＵ１１２は、メモリ１２０のコンテンツ全体を消去し、それを直近のＥＣＵソフトウェアのクリーンコピーと置換することを決定してもよい。ＥＣＵ１１２は、将来的更新のために、上記に説明されるデルタファイルベースの更新プロセスの使用を継続してもよい。

ここで、概して、図１Ａを参照する。上記の説明は、サーバ１０２が、通信チャネル１０６を介して、ソフトウェア更新を車両１０４に提供するための効率的技法を図示する、種々の実施例を提供したが、車両１０４もまた、通信チャネル１０６を利用して、情報をサーバ１０２に提供し、ソフトウェア更新プロセスをさらに向上させてもよいことに留意されたい。

例えば、いくつかの実施形態では、車両１０４－ｂは、プロセッサ実行可能コードを記憶するために構成される少なくとも１つの非一過性プロセッサ可読メモリ１１６と結合される、少なくとも１つのプロセッサ１１４を含んでもよい。プロセッサ実行可能コードが、プロセッサ１１４によって実行されると、プロセッサ１１４は、ＥＣＵ１１２のリアルタイム処理アクティビティを監視し、ＥＣＵ異常を識別する命令を行ってもよい。いくつかの実施形態では、プロセッサ１１４は、ＥＣＵ異常に関する情報をサーバ１０２および／または他の車両１０４に提供してもよい。

例証目的のために、ＥＣＵ１１２のリアルタイム処理アクティビティを監視し、ＥＣＵ異常に関する情報をサーバ１０２および／または他の車両１０４に提供するように構成される、プロセッサ１１４は、オーケストレータ１１４と称され得る。いくつかの実施形態では、オーケストレータ１１４は、ＥＣＵ１１２から分離されるユニットとして実装されてもよい。しかしながら、オーケストレータ１１４およびＥＣＵ１１２は、本開示の精神および範囲から逸脱することなく、あるハードウェアコンポーネントを共有してもよいことが検討される。付加的実施形態では、オーケストレータ１１４は、さらに下記に議論されるように、機械学習または人工知能機能を実施するように構成されてもよい（例えば、ＥＣＵから、車両の車隊内のＥＣＵから等のデータに基づいて）。

いくつかの実施形態では、オーケストレータ１１４は、ＥＣＵ１１２の処理アクティビティに関連する履歴データにアクセスするように構成されてもよい。いくつかの実施形態では、履歴データは、事前にＥＣＵ１１２またはオーケストレータ１１４によってメモリ１１６内にログ付けされてもよい。履歴データは、ＥＣＵ１１２の予期される処理アクティビティを表してもよい。オーケストレータ１１４は、リアルタイム処理アクティビティデータと履歴データを比較し、ＥＣＵ１１２のリアルタイム処理アクティビティ内の１つ以上の異常を識別してもよい。いくつかの実施形態では、オーケストレータ１１４は、種々のタイプの統計的モデルを実装し、比較を行ってもよい。いくつかの実施形態では、オーケストレータ１１４は、異常を識別するために、機械学習技法を含む、種々のタイプのデータ処理技法を実装してもよい。

いくつかの実施形態では、オーケストレータ１１４は、その発見をサーバ１０２に報告するように構成されてもよい（例えば、通信チャネル１０６を介して）。代替として、または加えて、いくつかの実施形態では、オーケストレータ１１４は、１つ以上の異常を識別すると、ＥＣＵ１１２のための１つ以上の制御アクションを実装してもよい。制御アクションは、例えば、ＥＣＵ１１２と関連付けられたアラートを発行するステップ、ＥＣＵ１１２から送信される命令をブロックするステップ、またはプロンプトをＥＣＵ１１２に発行し、ＥＣＵ１１２に、ＥＣＵソフトウェアの１つのバージョンから別のバージョンに実行を調節する（例えば、ＥＣＵ上で起動するＥＣＵソフトウェアのバージョンからＥＣＵソフトウェアの以前のバージョンにロールバックする）ように要求するステップを含んでもよい。

開示される実施形態に従って構成されるオーケストレータ１１４は、種々のタイプの異常を検出することが可能であり得ることが検討される。例えば、いくつかの実施形態では、検出された異常は、ＥＣＵ１１２によって使用される具体的メモリ場所に対応してもよい。ＥＣＵ１１２が、具体的メモリ場所外のメモリ場所にアクセスするように試みる場合、オーケストレータ１１４は、そのようなアクティビティを異常として識別してもよい。いくつかの実施形態では、検出された異常は、ＥＣＵ１１２によって使用されるメモリ場所の具体的シーケンスに対応してもよい。ＥＣＵ１１２が、具体的シーケンスと互換性がない順序でメモリ場所にアクセスするように試みる場合、オーケストレータ１１４は、そのようなアクティビティを異常として識別してもよい。いくつかの実施形態では、検出された異常は、ＥＣＵ１１２の内外のデータフロー内の少なくとも１つのピークに対応してもよい。ＥＣＵ１１２の内外にフローするデータが、異常に高い場合、オーケストレータ１１４は、異常を報告してもよい。いくつかの実施形態では、検出された異常は、ＥＣＵ１１２の１つ以上のプロセッサによるデータ処理内の少なくとも１つのピークに対応してもよい。ＥＣＵ１１２の１つ以上のプロセッサによるデータ処理が、異常に高い場合、オーケストレータ１１４は、異常を報告してもよい。いくつかの実施形態では、検出された異常は、ＥＣＵ１１２の電力消費における少なくとも１つの異常に対応してもよい。ＥＣＵ１１２の電力消費が、異常に高い場合、オーケストレータ１１４は、異常を報告してもよい。

いくつかの実施形態では、オーケストレータ１１４は、ＥＣＵ１１２に加え、他のＥＣＵを監視するように構成されてもよい。いくつかの実施形態では、オーケストレータ１１４は、車両１０４－ｂ内の複数のＥＣＵのリアルタイム処理アクティビティを監視するように構成されてもよい。例えば、いくつかの実施形態では、オーケストレータ１１４は、ＥＣＵ１１２に匹敵すると見なされる少なくとも１つの他のＥＣＵ１１８の処理アクティビティに関連する匹敵するデータを受信するように構成されてもよい。

ＥＣＵ１１８およびＥＣＵ１１２は、その製造業者または開発者によって、匹敵すると見なされ得ることが検討される。ＥＣＵ１１８およびＥＣＵ１１２はまた、ＥＣＵ１１８およびＥＣＵ１１２上で起動するＥＣＵソフトウェアと関連付けられたその制御機能および／またはルールに基づいて、匹敵すると見なされ得る。例えば、ＥＣＵ１１８およびＥＣＵ１１２が、その対応する実行のシーケンスが十分に類似することを確立している場合、ＥＣＵ１１８およびＥＣＵ１１２は、匹敵すると見なされ得る。別の実施例では、ＥＣＵ１１８およびＥＣＵ１１２の両方が、類似の悪意のある実行のシーケンスに悩まされる場合、ＥＣＵ１１８およびＥＣＵ１１２は、匹敵すると見なされ得る。さらに別の実施例では、ＥＣＵ１１８およびＥＣＵ１１２のマップファイルが、十分に類似する場合、ＥＣＵ１１８およびＥＣＵ１１２は、匹敵すると見なされ得る。なおも別の実施例では、オーケストレータ１１４は、他の車両１０４上に位置するプロセッサと通信し（例えば、通信チャネル１０６を介して）、他の車両１０４が匹敵すると見なし得るＥＣＵを観察してもよい。オーケストレータ１１４は、次いで、他の車両１０４のその観察に基づいて、匹敵すると見なされ得る車両１０４－ｂに位置するＥＣＵを決定してもよい。

いくつかの実施形態では、オーケストレータ１１４は、ＥＣＵ１１２から受信されたリアルタイム処理アクティビティデータとＥＣＵ１１８から受信された匹敵するデータを比較し、ＥＣＵ１１２のリアルタイム処理アクティビティ内の１つ以上の異常を識別するように構成されてもよい。いくつかの実施形態では、ＥＣＵ１１８から受信された匹敵するデータは、ＥＣＵ１１８から受信されたリアルタイム処理アクティビティデータを表してもよい。代替として、または加えて、いくつかの実施形態では、ＥＣＵ１１８から受信された匹敵するデータは、ＥＣＵ１１８から取得される以前に記録されたアクティビティデータを含んでもよい。

いくつかの実施形態では、オーケストレータ１１４は、種々のタイプの統計的モデルを実装し、ＥＣＵ１１２から受信されたリアルタイム処理アクティビティデータとＥＣＵ１１８から受信された匹敵するデータとの間の比較を行ってもよい。いくつかの実施形態では、オーケストレータ１１４は、異常を識別するために、機械学習技法を含む、種々のタイプのデータ処理技法を実装してもよい。いくつかの実施形態では、オーケストレータ１１４は、その発見をサーバ１０２に報告するように構成されてもよい。代替として、または加えて、いくつかの実施形態では、オーケストレータ１１４は、１つ以上の異常を識別すると、ＥＣＵ１１２のための１つ以上の制御アクションを実装してもよい。

いくつかの実施形態では、オーケストレータ１１４は、車両１０４－ｂ内のＥＣＵに電子的にポーリングし、ＥＣＵがポーリングに適切に応答するかどうかを決定するように構成されてもよい。オーケストレータ１１４は、次いで、車両１０４－ｂ内の１つ以上のＥＣＵと関連付けられた１つ以上のＥＣＵエラーまたは故障を識別してもよい。故障の実施例は、ＥＣＵが予期または許可されるものと異なる時間間隔あたりの回数で動作を実施することであり得る。ＥＣＵエラーまたは故障が、識別される場合、オーケストレータ１１４はまた、ＥＣＵの動作に関連するデータおよび識別されたＥＣＵエラーを収集してもよい。オーケストレータ１１４は、ＥＣＵおよび識別されたＥＣＵエラーを識別する報告を車両１０４－ｂからサーバ１０２に送信してもよい。サーバ１０２は、エラーの識別およびバグ修正の開発を含む、種々の目的のために、報告を利用してもよい。

用語「オーケストレータ」が、上記の実施例では使用されるが、用語は、限定することを意味するものではないことを理解されたい。オーケストレータは、車両内のＥＣＵに電子的にポーリングし、ＥＣＵがポーリングに適切に応答するかどうかを決定するように構成されてもよいことが検討される。加えて、オーケストレータ１１４は、機械学習または人工知能技法を利用して、ＥＣＵが適切に動作している（例えば、容認可能または予期される挙動エンベロープ内で動作している）かどうかを決定してもよい。例えば、オーケストレータ１１４は、ＥＣＵ（または複数のＥＣＵ）内の上位機能性（例えば、上位１０または１００の機能性）を監視し、観察される機能性のモデルまたはマップを開発するように構成されてもよい。本モデルまたはマップからの逸脱が、検出されると、異常が、宣言されてもよい。いくつかの実施形態では、オーケストレータ１１４は、特定のＥＣＵ（例えば、図１におけるＥＣＵ１１２）として実装されてもよい一方、他のＥＣＵは、データをオーケストレータ１１４ＥＣＵに報告するように構成される（例えば、プッシュ配信またはプル配信を介して）。このように、オーケストレータ１１４ＥＣＵは、他のＥＣＵの観察および予期される機能性に関する機械学習または人工知能内で使用されるためのデータを集めてもよい。

いくつかの実施形態では、オーケストレータ１１４は、車両内のＥＣＵのための予測保守または自己回復プロセスに関与してもよい。そのようなアプローチは、分散型人工免疫システム（ＡＩＳ）フレームワークに基づいてもよい。特に、車両全体を通したＥＣＵは、機械学習および人工知能のために、その動作および機能性に関するデータをオーケストレータ１１４（または別のＡＩＳ構成ＥＣＵ）に報告するように構成されてもよい（例えば、プッシュ配信またはプル配信を介して）。オーケストレータ１１４（または別のＡＩＳ構成ＥＣＵ）は、アルゴリズムを受信されたデータ上で実施し、ソフトウェア異常、エラー（例えば、ランタイムエラー）、および故障（例えば、ドリフト）を検出してもよい。そのようなアーキテクチャは、ＥＣＵ報告を多くのＥＣＵ間に広く分散させ、依然として、ＥＣＵ性能の多くの異なるパラメータを追跡することが可能であるため、効率的かつ低影響であり得る。さらに、オーケストレータ１１４（または別のＡＩＳ構成ＥＣＵ）は、分析を自律的および適応的に実施し、車両内のＥＣＵ動作の持続的に変化する性質を反映させてもよい。オーケストレータ１１４（または別のＡＩＳ構成ＥＣＵ）の機械学習または人工知的機能に基づいて、推奨される変更が、車両のＥＣＵの健康を維持するために、提案または自動的に実装されてもよい（例えば、ソフトウェアロールバックを実施する、ソフトウェア更新を実施する等）。いくつかの実施形態では、機械学習または人工知能機能は、サーバ（例えば、サーバ１０２）で実施され、車両の車隊全体（例えば、類似ＥＣＵ、類似ソフトウェアバージョン等を共有するもの）のための推奨される変更を提供してもよい。

オーケストレータ１１４（または別のＡＩＳ構成ＥＣＵ）のためのシステムアーキテクチャは、多層化されてもよい。いくつかの実施形態では、オーケストレータ１１４またはサーバ１０２は、中心ノードとしての役割を果たし、動作または機能データをそれに報告する個々のＥＣＵは、子またはエッジノードである。第１の階層（例えば、階層１）は、ＥＣＵの挙動のロープロファイル監視を実施してもよい。例えば、これは、機械学習モデルまたは人工知能アルゴリズムを適用し、個々のＥＣＵまたはＥＣＵのグループのアクティビティを分析するステップを伴ってもよい。これは、ＥＣＵメモリ占有面積、ＣＰＵ処理アクティビティ、コールされた機能、コールされた機能のシーケンス等を考慮し得る。第２の階層（例えば、階層２）は、オンデマンドベースで作用してもよい。例えば、機械学習または人工知能階層が、ＥＣＵの動作挙動内に潜在的異常を検出する場合、階層２に到達してもよく、これは、当該ＥＣＵのさらなる分析（例えば、メモリスタック分析、ＥＣＵ異常に関する情報をオーケストレータ１１４またはサーバ１０２に報告する等）を伴ってもよい。同様に、第３の階層の動作（例えば、階層３）では、ＥＣＵ動作のサンプル（例えば、コールされているメモリ場所、ソフトウェアバージョン、デルタファイルバージョン、ソフトウェアのコピー等）が、さらなる分析のために、オーケストレータ１１４またはサーバ１０２に返信されてもよい。第４の階層の動作（例えば、階層４）では、決定が、当該ＥＣＵまたはＥＣＵのグループのための制御アクションを実施するように行われてもよい。これは、例えば、ソフトウェアを以前のバージョンにロールバックするステップ（例えば、以前のバージョンのためのデルタファイルに基づいて）、ＥＣＵのための安全モードをアクティブ化する（例えば、ネットワーク通信をブロックする、機能性を調整する等）、またＥＣＵのための他の形態の制御を含んでもよい。

オーケストレータ１１４は、車両１０４－ｂに位置する１つ以上のプロセッサ１１４を利用して実装されてもよいことを理解されたい。いくつかの実施形態では、オーケストレータは、車両内のプロセッサ１１４または別個のプロセッサ上で実装されてもよい。いくつかの実施形態では、オーケストレータは、遠隔で実装されてもよい（例えば、サーバ１０２を介して）。例証的簡略化のために、下記の説明は、車両内のＥＣＵに電子的にポーリングし、ＥＣＵがポーリングに適切に応答するかどうかを決定する、または機械学習または人工知能機能をオーケストレータとして実施するように構成される、プロセッサを参照するであろう。

いくつかの実施形態では、オーケストレータは、要求メッセージをＥＣＵに送信し、ＥＣＵが１つ以上の応答メッセージを提供することを待機することによって、車両１０４－ｂ内のＥＣＵにポーリングしてもよい。オーケストレータは、例えば、プログラムが継続して起動しているかどうかを検出する、プロセッサ（例えば、ＥＣＵプロセッサ）内の統合されたハードウェアカウンタまたはモニタを指し得る。オーケストレータは、ＥＣＵがポーリングに応答することの失敗が検出されると、エラーまたは故障を実施または発生させたことを決定してもよい。上記に議論されるように、エラーおよび故障は、ランタイムエラー、スタックオーバーフローエラー、アプリケーション実行プロファイルの「ドリフト」（例えば、より低速になる、より高速になる、またはより長いまたはより短い周期にわたって生じる）等を含んでもよい。

いくつかの実施形態では、オーケストレータは、車両１０４－ｂ内の複数のＥＣＵにポーリングし、ＥＣＵが車両１０４－ｂの１つ以上のハードウェアコンポーネントに潜在的に影響を及ぼし得るＥＣＵソフトウェアを実行するかどうかを決定してもよい。例えば、ＥＣＵ１１２を更新した後、トランスミッションと相互作用する複数のＥＣＵが、誤った挙動を呈し始める場合、オーケストレータは、ＥＣＵ１１２のためのソフトウェア更新が、車両１０４－ｂのトランスミッションに潜在的に影響を及ぼすことを決定してもよい。オーケストレータはまた、種々のＥＣＵからの報告データ（例えば、ＥＣＵ識別子および／またはＥＣＵの最後の既知のポーリングを示すデータを含む）および車両１０４－ｂの種々のハードウェアコンポーネントからの報告データ（例えば、トランスミッションを含む）を収集してもよい。オーケストレータはまた、さらに下記に議論されるように、報告されるデータに基づいて、統計的分析、機械学習、または人工知能機能を実施してもよい。

いくつかの実施形態では、オーケストレータは、ＥＣＵ内の潜在的影響または異常が有害であるかどうかを決定してもよい。例えば、オーケストレータが報告されるデータに基づいて、通常動作の間のトランスミッションの平均温度が、数度増加していること、を決定する場合、オーケストレータは、トランスミッションへの潜在的影響が有害であることを決定してもよい。代替として、または加えて、いくつかの実施形態では、オーケストレータは、報告されるデータをサーバ１０２に提供し、サーバ１０２（またはそのユーザ）に、潜在的影響が有害であるかどうかを決定させるように構成されてもよい。

いくつかの実施形態では、オーケストレータは、報告されるデータに基づいて、ＥＣＵに関する休止時間の確率を決定してもよい。オーケストレータは、下記に議論される機械学習および人工知能技法を含む、統計的モデルまたは過去の挙動に基づいて、本決定を行なってもよい。いくつかの実施形態では、オーケストレータは、その決定をサーバ１０２に報告するように構成されてもよい。さらなる実施形態では、下記に議論されるように、オーケストレータは、潜在的影響が有害であることが決定されると、または休止時間の確率がある閾値を超えると、ＥＣＵ１１２のための１つ以上の制御アクションを実装してもよい。

ここで、概して、図１Ａに示される車両ネットワーク１００を参照する。上記に説明されるオーケストレータによって提供される機能性のうちのいくつかは、車両１０４上に位置するプロセッサ１１４によって行われることに加え（またはその代わりに）、ネットワーク１０６を経由して行われてもよいことが検討される。例えば、いくつかの実施形態では、サーバ１０２は、通信チャネル１０６を介して、ＥＣＵアクティビティデータを１つ以上の報告車両１０４から受信するように構成されてもよい。いくつかの実施形態では、報告車両１０４は、グループとして監視されている車両を含んでもよい。いくつかの実施形態では、報告車両は、共通タイプのＥＣＵ（例えば、車両１０４－ａ、１０４－ｂ、および１０４－ｃが全て、同一タイプのＥＣＵを有する場合、車両１０４－ａ、１０４－ｂ、および１０４－ｃは、グループとして監視されてもよい）または共通ソフトウェアバージョンを有する、車両のセットを含んでもよい。

いくつかの実施形態では、ＥＣＵアクティビティデータは、車両のグループ（例えば、上記の実施例では、車両１０４－ａ、１０４－ｂ、および１０４－ｃ）において動作する１つ以上のＥＣＵの実際の動作に対応してもよい。いくつかの実施形態では、サーバ１０２は、ＥＣＵアクティビティデータに基づいて、車両１０４－ａ、１０４－ｂ、および１０４－ｃに影響を及ぼすソフトウェア脆弱性を決定するように構成されてもよい。いくつかの実施形態では、サーバ１０２は、種々のタイプの統計的モデルを実装し、ＥＣＵアクティビティデータに基づいて、ソフトウェア脆弱性を決定してもよい。例えば、いくつかの実施形態では、サーバ１０２は、受信されたＥＣＵアクティビティデータと予期される（または履歴）ＥＣＵアクティビティデータとの間の逸脱に基づいて、ソフトウェア脆弱性を決定してもよい。いくつかの実施形態では、サーバ１０２は、機械学習技法を含む、種々の他のタイプのデータ処理技法を実装し、ソフトウェア脆弱性を決定してもよい。

いくつかの実施形態では、サーバ１０２は、車両１０４－ａ、１０４－ｂ、および１０４－ｃに影響を及ぼすソフトウェア脆弱性が存在することが決定される場合、ＥＣＵソフトウェア更新を識別するように構成されてもよい。サーバ１０２はまた、影響される車両１０４－ａ、１０４－ｂ、および１０４－ｃのＥＣＵ上のソフトウェアを更新するように構成される、デルタファイルを生成および送信してもよい。サーバ１０２は、上記に説明されるプロセスに従ってデルタファイルを生成してもよいことが検討される。また、車両１０４－ａ、１０４－ｂ、および１０４－ｃは、上記に説明されるように、デルタファイルを処理し、ＥＣＵソフトウェア更新プロセスを実施してもよいことが検討される。

いくつかの実施形態では、サーバ１０２はまた、上記で識別されたソフトウェア脆弱性によって潜在的に影響される第２のセットの車両を決定するように構成されてもよい。第２のセットの車両は、ＥＣＵアクティビティデータをサーバ１０２に最初に報告した車両のグループの一部ではない（例えば、車両１０４－ｄおよび１０４－ｅは、先の時間にサーバ１０２に接続することが不可能であった可能性がある）が、それにもかかわらず、更新されるべきＥＣＵを含有し得る、車両１０４－ｄおよび１０４－ｅを含んでもよい。サーバ１０２は、展開されたＥＣＵバージョン番号の記録に基づいて、またはこれらの車両に行われた照会に基づいて、そのような車両を識別してもよい（例えば、サーバ１０２は、全ての車両１０４に、そのＥＣＵソフトウェアバージョン番号、３Ｄｉｆｆバージョン、または他の識別子を報告するように求めてもよい）。いくつかの実施形態では、サーバ１０２は、デルタファイルを、更新されるべきＥＣＵを使用している全ての車両に送信するように構成されてもよい。いくつかの実施形態では、サーバ１０２は、車両１０４内にインストールされるＥＣＵを再較正する方法として、デルタファイルを全ての車両１０４にプッシュ配信するように構成されてもよい。

車両１０４上に位置する１つ以上のプロセッサ１１４は、サーバ１０２からのデルタファイルの受信に応じて、デルタファイルを対応するＥＣＵのメモリデバイスの中に設置し、ＥＣＵの動作を中断せずに、更新を実施してもよいことが検討される。しかしながら、また、ある状況では、車両１０４上に位置する１つ以上のプロセッサ１１４は、好機をねらって更新を実施することを決定してもよいことが検討される。

例えば、いくつかの実施形態では、車両１０４－ｂ上に位置するプロセッサ１１４は、車両１０４－ｂ内のＥＣＵ１１２上で起動するソフトウェアを更新する必要性を示す、無線伝送を受信してもよい。プロセッサ１１４は、車両１０４－ｂの動作ステータスを監視し、車両１０４－ｂが、ＥＣＵソフトウェア更新が禁止される、第１の動作モードにあるかどうかを決定してもよい。車両１０４－ｂは、車両１０４－ｂがサーバ１０２と安定接続を確立することができないとき、第１の動作モードにあり得る。車両１０４－ｂはまた、無線通信強度が閾値レベルを下回るとき、第１の動作モードにあり得る。さらに、車両１０４－ｂは、車両が制限されたエリア内にある、またはある動作を実施している（例えば、閾値を上回る速さで進行している）とき、第１の動作モードにあり得る。上記に提示される実施例は、例証的目的のためのものであって、限定を意味するものではないことを理解されたい。車両１０４－ｂは、本開示の精神および範囲から逸脱することなく、種々の他の理由に起因して、第１の動作モードにあり得ることが検討される。

いくつかの実施形態では、プロセッサ１１４が、車両１０４－ｂが第１の動作モードにあることを決定する場合、プロセッサ１１４は、ＥＣＵソフトウェア更新プロセスを遅延させるように選定してもよい。いくつかの実施形態では、プロセッサ１１４は、受信されたデルタファイルをメモリ１１６内に記憶してもよい。いくつかの実施形態では、プロセッサ１１４は、デルタファイルを破棄してもよい（プロセッサ１１４がＥＣＵソフトウェア更新をインストールする準備ができた後に要求され得る）。

プロセッサ１１４は、車両１０４－ｂの動作ステータスの監視を継続し、車両１０４－ｂがＥＣＵソフトウェア更新が許可される第２の動作モードに遷移するかどうかを決定してもよい。いくつかの実施形態では、プロセッサ１１４は、事前に確立された間隔に従って（例えば、１０分毎に）繰り返し、車両１０４－ｂの動作ステータスの監視を継続してもよい。プロセッサ１１４は、例えば、車両１０４－ｂが、閾値レベルを下回る速さで進行する、低電力またはパワーダウンステータスで動作する、事前に選択された環境条件で動作する、アイドリング、または同等物等の所定の安全動作条件のうちの１つに入ると、車両１０４－ｂが第２の動作モードにあることを決定してもよい。プロセッサ１１４はまた、車両１０４－ｂがサーバ１０２と安定接続を確立し得ると、車両１０４－ｂが第２の動作モードにあることを決定してもよい。例えば、プロセッサ１１４は、無線通信強度が強度の閾値を上回ると、またはサーバ１０２とのネットワーク接続が閾値を下回るエラーレートを有すると、車両１０４－ｂが第２の動作モードにあることを決定してもよい。

いったんプロセッサ１１４が、車両１０４－ｂが第２の動作モードにあることを決定すると、プロセッサ１１４は、ＥＣＵソフトウェア更新プロセスを有効にしてもよく、これは、上記に説明されるように、進められてもよい。ＥＣＵソフトウェア更新プロセスを遅延させるように決定されるとき、プロセッサ１１４が、受信されたデルタファイルのコピーをメモリ１１６内に記憶した場合、プロセッサ１１４は、受信されたデルタファイルのコピーをメモリ１１６から読み出し、デルタファイルをＥＣＵ１１２のメモリ１２０の中に書き込んでもよい。ＥＣＵソフトウェア更新プロセスを遅延させるように決定されるとき、プロセッサ１１４が、デルタファイルを破棄した場合、プロセッサ１１４は、メッセージをサーバ１０２に送信し、デルタファイルの別のコピーを要求してもよい。プロセッサ１１４は、デルタファイルをサーバ１０２からの返信メッセージ内で受信し、デルタファイルをＥＣＵ１１２のメモリ１２０の中に書き込み、上記に説明されるように、更新プロセスを実施してもよい。

プロセッサ１１４は、ＥＣＵソフトウェア更新プロセスの遅延に関するある程度の裁量を有してもよいが、そのような裁量は、いくつかの実施形態では、絶対ではない場合があることを理解されたい。例えば、いくつかの実施形態では、プロセッサ１１４は、ＥＣＵソフトウェア更新がオーバライドステータスを伴って実施されるべきであることを示す、無線伝送をサーバ１０２から受信し得る。ＥＣＵソフトウェア更新が、オーバライド状態を伴って受信される場合、プロセッサ１１４は、その裁量を行使することが不可能であり得、車両１０４－ｂが第１の動作モードにあるかどうかにかかわらず、ＥＣＵソフトウェアを更新する必要があり得る。オーバライドステータスを伴うそのような更新は、重要なＥＣＵ更新を遅延なく直ちに展開するために利用されてもよいことが検討される。

同様に、前述のように、開示される実施形態に従って構成されるデルタファイルを利用する、ＥＣＵソフトウェア更新プロセスは、リブートする必要なく、ＥＣＵが更新されることを可能にし得る。しかしながら、いくつかの実施形態では、サーバ１０２は、必須リブートを伴って所与のＥＣＵソフトウェア更新が実施されるべきであることを示し得る。ＥＣＵソフトウェア更新が、リブートするための要求とともに受信される場合、プロセッサ１１４は、ＥＣＵに、上記に説明されるような更新後、必須リブートを実施するように命令してもよい。

上記の説明から、開示される実施形態に従って構成されるデルタファイルを利用することは、ＥＣＵ更新プロセスの効率を改良し得ることを理解されたい。これらのデルタファイルは、それらがＥＣＵソフトウェア全体を含む必要がないため、サイズがより小さい。これらのデルタファイルはまた、直接、ＥＣＵメモリ空間に書き込まれることができ、これは、メモリ空間および電力消費の両方を低減させ得る。これらのデルタファイルはまた、コード変更、変数変更、およびメモリアドレス変更を含む、自己完結型パッケージとして実装されてもよい。これらのデルタファイルはさらに、ＥＣＵによって実行され、デルタファイルが位置独立的であることを可能にし、ＥＣＵが、そのオリジナルソフトウェアを変更する、またはその現在の動作を中断する必要なく、更新を行うことを可能にし得る、スタートアップコードを含有してもよい。

開示される実施形態に従って構成される仮想ファイルシステム（ＶＦＳ）もまた、ＥＣＵ更新プロセスの効率を改良し得る。ＶＦＳは、ＥＣＵソフトウェアの異なるバージョンを管理および追跡するために利用されてもよく、上記に説明される更新およびロールバック動作をサポートしてもよい。さらに、開示される実施形態に従って構成されるＶＦＳを使用して、ＥＣＵソフトウェアの異なるバージョンを管理および追跡することは、バージョン間の差異（デルタ）のみが、追跡される必要があって、複製されたコードが、記録される必要がないため、非常にわずかな空間オーバーヘッドを要求し得ることに留意されたい。

さらに、開示される実施形態に従って構成されるＶＦＳによって管理されるデルタファイルを利用することは、更新後、ＥＣＵを再起動する必要性を排除し得ることに留意されたい。具体的には、開示される実施形態に従って構成されるデルタファイルは、コード変更、変数変更、およびメモリアドレス変更を全て一度に実装し、オリジナルＥＣＵソフトウェアおよびデルタファイルをともに効果的にリンクさせ、リブートの必要なく、更新されたＥＣＵソフトウェアの機能均等物を形成し得る。

開示される実施形態に従って構成されるＥＣＵソフトウェア更新プロセスはまた、仮想ＥＣＵを更新するために利用されてもよいことが検討される。仮想ＥＣＵは、仮想機械上に実装されるＥＣＵまたは共有ハードウェアリソース上に常駐するハイパーバイザを指し得る。実質的に同一ＥＣＵソフトウェア更新プロセスは、本開示の精神および範囲から逸脱することなく、仮想ＥＣＵソフトウェアを更新するために利用されてもよいことが検討される。

ここで図１０を参照すると、車両内のＥＣＵ上でソフトウェアを更新するための更新パッケージを生成するためのプロセス１０００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１０００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１０００は、サーバ１０２によって実施されてもよい。上記に議論されるように、更新パッケージ（例えば、ソース、マップ、バイナリ等のソフトウェア属性に基づいて）は、生産ツールチェーン１２２から取得されてもよい。さらに、更新パッケージを生成するステップに関連して、依存性管理システム１２６が参照され得る。特に、依存性管理システム１２６は、新しい更新パッケージが車両内の他のＥＣＵと相互依存するＥＣＵと関連付けられるかどうかと、該当する場合、ソフトウェア更新がまた相互依存ＥＣＵのためにも実施されるべきであるかどうかとを決定するようにチェックされてもよい。上記に議論されるように、依存性管理システム１２６は、ＥＣＵ間の相互依存性がソフトウェア更新が実施される前に確認され得るように、ＥＣＵのリストまたはマッピングを維持してもよい。いくつかの実施形態では、リストまたはマッピングもまた、生産ツールチェーン１２２に基づく。

ステップ１００２では、プロセス１０００は、車両内のＥＣＵ（例えば、車両１０４－ｂ内のＥＣＵ１１２）上に記憶されるべきソフトウェア更新（例えば、図２に示されるソフトウェア更新２０２）の複数の属性にアクセスしてもよい。ステップ１００４では、プロセス１０００は、車両内のＥＣＵ上に記憶される現在のソフトウェア（例えば、車両１０４－ｂ内のＥＣＵ１１２上に記憶される現在のソフトウェア２０４）の複数の対応する属性にアクセスしてもよい。ステップ１００６では、プロセス１０００は、ソフトウェア更新の属性と現在のソフトウェアの対応する属性を比較してもよい。ステップ１００８では、プロセス１０００は、ソフトウェア更新の属性と現在のソフトウェアの対応する属性との間の差異を表す、デルタファイルを生成してもよい。ステップ１０１０では、プロセス１０００は、スタートアップコードをデルタファイルの中に統合してもよい。いくつかの実施形態では、スタートアップコードは、デルタファイルが車両内のＥＣＵ内で自己実行することを有効にしてもよい。

いくつかの実施形態では、ステップ１００６において、プロセス１０００は、ソフトウェア更新のソース、バイナリコード、およびマップファイルを含む、属性と、現在のソフトウェアのその対応する属性を比較してもよい。上記に議論されるように、ソフトウェア更新および現在のソフトウェアをそのソース、バイナリコード、およびマップファイル属性の観点から表すことは、「グリッド」表現と称され得、ソフトウェア更新を表すグリッドと現在のソフトウェアを表すグリッドとの間の比較は、３次元差分（または３Ｄｉｆｆ）比較と称され得る。いくつかの実施形態では、比較されている属性は、少なくとも部分的に、ソフトウェア更新を開発するために使用されるプログラミング言語に基づいて、少なくとも部分的に、ソフトウェア更新のバイナリファイル分解能に基づいて、または少なくとも部分的に、ソフトウェア更新と関連付けられたマップファイルに基づいて、識別されてもよい。

いくつかの実施形態では、ステップ１００８において、プロセス１０００は、そのような３Ｄｉｆｆ比較を利用して、ＥＣＵのバイナリおよび／またはソースコードに行われる変更、ＥＣＵによって使用される１つ以上の変数に行われる変更、およびＥＣＵによって参照されるメモリアドレスに行われる変更を表すデータを含み得る、デルタファイルを生産してもよい。例えば、いくつかの実施形態では、ステップ１００８－１において、プロセス１０００は、第１のグリッドをソフトウェア更新に適用してもよく、ステップ１００８－２では、プロセス１０００は、第２のグリッドをＥＣＵ上に記憶される現在のソフトウェアに適用してもよい。第１のグリッドは、ソフトウェア更新と関連付けられたバイナリデータ、ソフトウェア更新と関連付けられたソース属性、および／またはソフトウェア更新と関連付けられたマップファイルを含む１つ以上の次元におけるソフトウェア更新を表してもよい。ステップ１００８－３では、プロセス１０００は、第１および第２のグリッドの比較に基づいて、ソフトウェア更新の属性と現在のソフトウェアの対応する属性を識別してもよい。

いくつかの実施形態では、ステップ１０１０において、プロセス１０００は、デルタファイルのランタイムライブラリを初期化するように構成される、スタートアップコードを統合してもよい。いくつかの実施形態では、プロセス１０００は、スタートアップコードを、ＥＣＵのプログラムカウンタを更新し、現在のソフトウェア内に含有されるあるコードをスキップし、代わりに、デルタファイル内に含有されるあるコードを実行するように構成してもよい。スタートアップコードは、ＥＣＵ内のメモリの古いコンテンツが消去される必要があるかどうかを決定してもよい。さらに、スタートアップコードは、変数データをデルタファイルから抽出し、変数データをＥＣＵにアクセス可能なランダムアクセスメモリの中に設置してもよい。いくつかの実施形態では、スタートアップコードは、メモリアドレスを更新し、ＥＣＵ内のメモリアドレスを更新するためのコードを抽出してもよい。

ここで図１１を参照すると、車両内でデルタファイルを受信および統合するためのプロセス１１００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１１００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１１００は、車両１０４－ｂ内のＥＣＵ１１２によって実施されてもよい。

ステップ１１０２では、プロセス１１００は、ＥＣＵ（例えば、ＥＣＵ１１２）上のソフトウェアのためのソフトウェア更新およびデルタファイルをＥＣＵ内で実行するためのスタートアップコード（例えば、スタートアップコード２０８）に対応する複数のデルタ（または変更）を含むデルタファイル（例えば、デルタファイル２０６）を受信してもよい。ステップ１１０４では、プロセス１１００は、スタートアップコードに基づいて、デルタファイルをＥＣＵ内で実行してもよい。いくつかの実施形態では、スタートアップコードは、上記の実施形態に従って構成されてもよく、ステップ１１０６では、プロセス１１００は、ＥＣＵ内のメモリアドレスを更新し、デルタファイルからの複数のデルタに対応させてもよい。

いくつかの実施形態では、デルタファイルは、ＥＣＵと関連付けられたメモリデバイス（例えば、図１Ａに描写されるようなメモリデバイス１２０）に書き込まれてもよい。いくつかの実施形態では、デルタファイルは、メモリデバイスからＥＣＵと関連付けられたランダムアクセスメモリにブートストラップされてもよい。さらに、デルタファイルは、ＥＣＵの継続される動作に影響を及ぼすことなく、またはＥＣＵをリブートせずに、ＥＣＵによって実行可能であってもよい。

いくつかの実施形態では、デルタファイルは、ＥＣＵによって実行されるべき位置独立実行可能コードセグメント（例えば、図４に描写されるようなコード変更２１０）を含んでもよい。スタートアップコードは、図４に描写されるように、ＥＣＵのプログラムカウンタを更新し、デルタファイル内に含有される命令を実行するように構成されてもよい。

いくつかの実施形態では、ＥＣＵ上のソフトウェアは、複数の機能ユニットにマッピングされてもよく、ＥＣＵは、図５－８に描写されるように、仮想ファイルシステム（例えば、図５－８に描写されるようなＶＦＳ２３０）を利用して、これらの機能ユニットの１つ以上のバージョンを管理および追跡するように構成されてもよい。スタートアップコードは、図５－８に描写されるように、デルタファイルをデルタファイルと関連付けられたＶＦＳ内の具体的機能にリンクさせるように構成されてもよい。

ここで図１２を参照すると、車両のＥＣＵが動作している間、ＥＣＵソフトウェアへの更新を実施するためのプロセス１２００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１２００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１２００は、車両１０４－ｂ内のＥＣＵ１１２によって実施されてもよい。

ステップ１２０２では、プロセス１２００は、車両のＥＣＵ（例えば、車両１０４－ｂのＥＣＵ１１２）が動作している間、ＥＣＵソフトウェアのためのソフトウェア更新ファイル（例えば、デルタファイル２０６）を受信してもよい。ステップ１２０４では、ＥＣＵが依然として動作している間、プロセス１２００は、ソフトウェア更新ファイルをＥＣＵのメモリ（例えば、メモリ１２０）内の第１のメモリ場所（例えば、図４におけるデルタファイル２０６が記憶されるメモリ場所）の中に書き込むと同時に、ＥＣＵのメモリ内の第２のメモリ場所（例えば、図４における現在のソフトウェア２０４が記憶されるメモリ場所）内の既存のコードのコードセグメントを実行してもよい。ステップ１２０６では、プロセス１２００は、ソフトウェア更新ファイルに基づいて、ＥＣＵのメモリ内の第２のメモリ場所において現在実行されているコードセグメントの実行を中断せずに、ＥＣＵのメモリと関連付けられた複数のメモリアドレスを更新してもよい。

いくつかの実施形態では、ＥＣＵソフトウェアのためのソフトウェア更新ファイルは、上記に説明されるように、統合されたスタートアップコードを伴うデルタファイルを含んでもよい。プロセス１２００は、例えば、ソフトウェア更新ファイルをＥＣＵの第１のメモリ場所の中に書き込む前に、ランタイムライブラリを初期化してもよい。いくつかの実施形態では、プロセス１２００は、ステップ１２０８において、ソフトウェア更新の完了に応じて、ＥＣＵによって参照される変数の陳腐化された値を表すデータを削除するように構成されてもよい。さらに、プロセス１２００はさらに、ステップ１２１０において、ソフトウェア更新を完了後、またはソフトウェア更新から独立して（例えば、周期的に、または必要に応じて）、ＥＣＵのメモリ（例えば、メモリ１２０）をデフラグメントするように構成されてもよい。

ここで図１３を参照すると、車両ＥＣＵソフトウェアバージョンを調節するためのプロセス１３００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１３００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１３００は、車両１０４－ｂ内のＥＣＵ１１２によって実施されてもよい。

ステップ１３０２では、プロセス１３００は、車両のＥＣＵ（例えば、車両１０４－ｂのＥＣＵ１１２）をＥＣＵソフトウェアの第１のバージョン（例えば、図５に描写されるバージョン０）からＥＣＵソフトウェアの第２のバージョン（例えば、図５に描写されるバージョン１）に実行を調節するためのプロンプトを受信してもよい。ステップ１３０４では、プロセス１３００は、プロンプトに応答して、ＥＣＵソフトウェアの第２のバージョンに対応するデルタファイル（例えば、図５に描写されるデルタファイル２０６）に基づいて、車両内のＥＣＵ上のＥＣＵソフトウェアの第２のバージョンを実行のために構成してもよい。ステップ１３０６では、プロセス１３００はさらに、プロンプトに応答して、車両内のＥＣＵ上のＥＣＵソフトウェアの第１のバージョンを実行不可能になるように構成してもよい。

いくつかの実施形態では、ＥＣＵソフトウェアの第２のバージョンは、ＥＣＵソフトウェアの第１のバージョンに続いて展開されてもよい（例えば、図５－７、および図９、Ｔ１－Ｔ３に描写されるように）。代替として、ＥＣＵソフトウェアの第２のバージョンは、ＥＣＵソフトウェアの第１のバージョンに先立って展開されてもよい（例えば、図８および図９、Ｔ４に描写されるように）。

いくつかの実施形態では、ＥＣＵ上のＥＣＵソフトウェアは、複数の機能ユニットにマッピングされ、ＥＣＵは、仮想ファイルシステム（例えば、ＶＦＳ２３０）を利用して、これらの機能ユニットの１つ以上のバージョンを管理および追跡するように構成される。ステップ１３０６では、プロセス１３００は、ＶＦＳによって管理される１つ以上の機能ユニットに対応するＥＣＵ内のメモリアドレスを更新し、ＥＣＵソフトウェアの第１のバージョンを実行不可能にしてもよい。さらに、ＥＣＵソフトウェアの第２のバージョンは、ＶＦＳによって無効にされる１つ以上の機能ユニットを有する、ＥＣＵソフトウェアの第１のバージョンであってもよい。

いくつかの実施形態では、プロセス１３００は、ステップ１３０８において、ＥＣＵのメモリ（例えば、メモリ１２０）の利用量が、閾値を上回る（例えば、７５％または９０％満杯）ことを決定してもよい。プロセス１３００はまた、ステップ１３１０において、削除のためのＥＣＵのメモリの具体的コンテンツを識別してもよい。加えて、プロセス１３００は、その対応する作成日、バージョン数、ファイルサイズ、または同等物に基づいて、削除のためのコンテンツを識別してもよい。例えば、長時間（例えば、閾値時間量）にわたって使用されていない古いデルタファイルは、削除のための良好な候補であり得る。いくつかの実施形態では、プロセス１３００はまた、ＥＣＵのメモリのコンテンツ全体を置換するように選定してもよい。例えば、オリジナルソフトウェアに加え、過去数年にわたって受信された複数のデルタファイルを保つ代わりに、プロセス１３００は、ステップ１３１２において、メモリのコンテンツ全体を消去し、それを直近のＥＣＵソフトウェアのクリーンコピーと置換することを決定してもよい。プロセス１３００は、将来的更新のために、上記に説明されるデルタファイルベースの更新プロセスの使用を継続してもよい。

ここで図１４を参照すると、車両内のＥＣＵ異常を識別するためのプロセス１４００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１４００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１４００は、車両内のコントローラ（例えば、車両１０４－ｂ内のプロセッサ１１４）によって実施されてもよい。

ステップ１４０２では、プロセス１４００は、ＥＣＵ（例えば、ＥＣＵ１１２）のリアルタイム処理アクティビティを表すデータを監視してもよい。ステップ１４０４では、プロセス１４００は、ＥＣＵの処理アクティビティに関連する履歴データにアクセスしてもよい。いくつかの実施形態では、履歴データは、ＥＣＵの予期される処理アクティビティを表し得る。さらに、プロセス１４００は、ＥＣＵの動作を監視し、履歴データを生成してもよい。

ステップ１４０６では、プロセス１４００は、リアルタイム処理アクティビティデータと履歴データを比較し、ＥＣＵのリアルタイム処理アクティビティ内の１つ以上の異常を識別してもよい。いくつかの実施形態では、異常は、ＥＣＵによって使用される具体的メモリ場所に対応してもよい。さらに、異常は、ＥＣＵによって使用されるメモリ場所の具体的シーケンスに対応してもよい。異常は、ＥＣＵの内外のデータフロー内の少なくとも１つのピークに対応してもよい。さらに、異常は、ＥＣＵのプロセッサによるデータ処理内の少なくとも１つのピークに対応してもよい。加えて、異常は、ＥＣＵの電力消費における少なくとも１つの異常に対応してもよい。

ステップ１４０８では、プロセス１４００は、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装してもよい。いくつかの実施形態では、制御アクションは、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行にＥＣＵを調節する（例えば、ＥＣＵ上で起動するＥＣＵソフトウェアのバージョンをＥＣＵソフトウェアの以前のバージョンにロールバックする）ためのプロンプトを発行するステップを含んでもよい。制御アクションはまた、ＥＣＵと関連付けられたアラートを送信するステップを含んでもよい。さらに、制御アクションは、ＥＣＵから送信される命令をブロックするステップを含んでもよい。

いくつかの実施形態では、プロセス１４００は、車両内のオーケストレータ（例えば、上記に説明されるようなオーケストレータ１１４）によって行われてもよい。いくつかの実施形態では、オーケストレータは、ＥＣＵと別個の処理ユニットであってもよい。オーケストレータは、車両内の複数のＥＣＵ（例えば、ＥＣＵ１１２およびＥＣＵ１１８の両方）のための監視、アクセス、比較、および実装を実施するように構成されてもよい。

ここで図１５を参照すると、車両内のＥＣＵ異常を識別するためのプロセス１５００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１５００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１５００は、車両内のコントローラ（例えば、車両１０４－ｂ内のプロセッサ１１４）によって実施されてもよい。

ステップ１５０２では、プロセス１５００は、ＥＣＵ（例えば、ＥＣＵ１１２）のリアルタイム処理アクティビティを表すデータを監視してもよい。ステップ１５０４では、プロセス１５００は、ＥＣＵと機能性が匹敵すると見なされる少なくとも１つの他のＥＣＵの処理アクティビティに関連する匹敵するデータを受信してもよい。前述のように、いくつかの実施形態では、匹敵するデータは、ＥＣＵ（例えば、ＥＣＵ１１２）に匹敵すると見なされる他のＥＣＵ（例えば、ＥＣＵ１１８）の処理アクティビティに関連するリアルタイムで取得されるデータを含んでもよい。匹敵するデータは、ＥＣＵに匹敵すると見なされる他のＥＣＵの処理アクティビティに関連する事前に集められたデータを含んでもよい。いくつかの実施形態では、匹敵するデータは、ＥＣＵ上で起動するＥＣＵソフトウェアと関連付けられたルールに基づいて、取得されてもよい。さらに、匹敵するデータは、ＥＣＵ上で起動するＥＣＵソフトウェアの実行の既知の有効シーケンスに基づいて、取得されてもよい。いくつかの実施形態では、匹敵するデータは、ＥＣＵ上で起動するＥＣＵソフトウェアの実行の既知の潜在的に悪意のあるシーケンスに基づいて、取得されてもよい。いくつかの実施形態では、匹敵するデータは、ＥＣＵ上のＥＣＵソフトウェアと関連付けられたマップファイルに基づいて、取得されてもよい。匹敵するデータはまた、他の車両から受信された観察データに基づいて、取得されてもよい。

ステップ１５０４では、プロセス１５００は、リアルタイム処理アクティビティデータと匹敵するデータを比較し、ＥＣＵのリアルタイム処理アクティビティ内の１つ以上の異常を識別してもよい。いくつかの実施形態では、異常は、ＥＣＵによって使用される具体的メモリ場所に対応してもよい。いくつかの実施形態では、異常は、ＥＣＵによって使用されるメモリ場所の具体的シーケンスに対応してもよい。いくつかの実施形態では、異常は、ＥＣＵの内外のデータフロー内の少なくとも１つのピークに対応してもよい。異常は、ＥＣＵのプロセッサによるデータ処理内の少なくとも１つのピークに対応してもよい。異常はまた、ＥＣＵの電力消費における少なくとも１つの異常に対応してもよい。

ステップ１５０６では、プロセス１５００は、少なくとも１つの異常が識別されると、ＥＣＵのための制御アクションを実装してもよい。いくつかの実施形態では、制御アクションは、ＥＣＵソフトウェアの第１のバージョンからＥＣＵソフトウェアの第２のバージョンの実行にＥＣＵを調節する（例えば、ＥＣＵ上で起動するＥＣＵソフトウェアのバージョンをＥＣＵソフトウェアの以前のバージョンにロールバックする）ためのプロンプトを発行するステップを含んでもよい。制御アクションはまた、ＥＣＵと関連付けられたアラートを送信するステップを含んでもよい。さらに、制御アクションは、ＥＣＵから送信される命令をブロックするステップを含んでもよい。

ここで図１６を参照すると、車両内のＥＣＵソフトウェアを好機をねらって更新するためのプロセス１６００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１６００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１６００は、車両内のコントローラ（例えば、車両１０４－ｂ内のプロセッサ１１４）によって実施されてもよい。

ステップ１６０２では、プロセス１６００は、ＥＣＵ（例えば、ＥＣＵ１１２）上で起動するソフトウェアを更新する必要性を示す、無線伝送を受信するステップを含んでもよい。ステップ１６０４では、プロセス１６００は、車両の動作ステータスを監視し、車両が、ＥＣＵソフトウェア更新が禁止される、第１の動作モードにあるかどうかを決定してもよい。

ステップ１６０６では、プロセス１６００は、動作ステータスが禁止されるとき、ＥＣＵソフトウェア更新を遅延させてもよい。プロセス１６００は、車両が第１の動作モードにあるとき、更新を遅延されるために、ＥＣＵソフトウェア更新を車両上に位置するメモリ内に記憶してもよい。代替として、いくつかの実施形態では、プロセス１６００は、車両が第１の動作モードにあるとき、ＥＣＵソフトウェア更新を破棄してもよい（プロセス１６００は、ＥＣＵソフトウェア更新を後の時間に要求し得る）。

ステップ１６０８では、プロセス１６００は、車両の動作ステータスの監視を継続し、車両がＥＣＵソフトウェア更新が許可される第２の動作モードにあるかどうかを決定してもよい。プロセス１６００は、事前に確立された間隔に従って、車両の動作ステータスを繰り返し監視してもよい。いくつかの実施形態では、車両は、車両が所定の安全動作条件で動作するとき、第２の動作モードにあると決定されてもよい。いくつかの実施形態では、車両は、車両がパワーダウンまたはアイドリングステータスにあるとき、第２の動作モードにあると決定されてもよい。車両は、車両が強度の閾値を上回る無線通信強度の周期を有するとき、第２の動作モードにあると決定されてもよい。いくつかの実施形態では、車両は、車両が事前に選択された環境条件で動作するとき、第２の動作モードにあると決定されてもよい。いくつかの実施形態では、車両は、車両が閾値を下回るエラーレートを伴うネットワーク接続を有するとき、第２の動作モードにあると決定されてもよい。

ステップ１６１０では、プロセス１６００は、車両が第２の動作モードにあることが決定されると、遅延されたＥＣＵソフトウェア更新を伴うＥＣＵの更新を有効にしてもよい。プロセス１６００が、ＥＣＵソフトウェア更新のコピーを車両上に位置するメモリ内に記憶した場合、プロセス１６００は、ＥＣＵソフトウェア更新のコピーをメモリから読み出し、更新プロセスを進めてもよい。プロセス１６００が、車両が第１の動作モードにあるとき、ＥＣＵソフトウェア更新を破棄した場合、プロセス１１６は、メッセージをＥＣＵソフトウェア更新のコピーを提供し得る遠隔サーバに送信し、ＥＣＵソフトウェア更新を返信内で受信し、車両が第２の動作モードにあるとき、ＥＣＵに関するＥＣＵソフトウェア更新をインストールしてもよい。

いくつかの実施形態では、プロセス１６００は、ステップ１６１２において、ソフトウェアを更新する必要性を示す無線伝送が、更新がオーバライドステータスを伴うことのインジケーションを含むかどうかを決定してもよい。無線伝送が、更新がオーバライドステータスを伴うことのインジケーションを含む場合、プロセス１６００は、ステップ１６１４において、車両が第１の動作モードにあるかどうかにかかわらず、ＥＣＵソフトウェアを直ちに更新してもよい。

ここで図１７を参照すると、更新を１つ以上の車両に自動的に提供するためのプロセス１７００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１７００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１７００は、サーバ１０２によって実施されてもよい。

ステップ１７０２では、プロセス１７００は、ＥＣＵアクティビティデータ（例えば、車両１０４－ｂ内のＥＣＵ１１２のアクティビティデータ）を車両から受信してもよい。いくつかの実施形態では、ＥＣＵアクティビティデータは、車両内のＥＣＵの実際の動作に対応してもよい。

ステップ１７０４では、プロセス１７００は、ＥＣＵアクティビティデータに基づいて、車両に影響を及ぼすソフトウェア脆弱性を決定してもよい。いくつかの実施形態では、ソフトウェア脆弱性は、受信されたＥＣＵアクティビティデータと予期されるＥＣＵアクティビティデータとの間の逸脱に基づいて決定されてもよい。

ステップ１７０６では、プロセス１７００は、決定されたソフトウェア脆弱性に基づいて、ＥＣＵソフトウェア更新を識別してもよい。ステップ１７０８では、プロセス１７００は、識別されたＥＣＵソフトウェア更新に対応するソフトウェア更新を用いてＥＣＵ上のソフトウェアを更新するように構成される、デルタファイルを送信してもよい。

いくつかの実施形態では、プロセス１７００は、車両のグループ上で実施されてもよい。いくつかの実施形態では、車両のグループは、共通ＥＣＵタイプを有する、第１のセットの車両（例えば、車両１０４－ａ、１０４－ｂ、および１０４－ｃ）を含んでもよい。いくつかの実施形態では、プロセス１７００は、第１のセットの車両に影響を及ぼすソフトウェア脆弱性を決定することによって、ソフトウェア脆弱性を決定してもよい。

いくつかの実施形態では、プロセス１７００は、ステップ１７１０において、ソフトウェア脆弱性によって潜在的に影響される第２のセットの車両を決定してもよい。いくつかの実施形態では、プロセス１７００は、ステップ１７１２において、デルタファイルを第１のセットおよび第２のセットの車両の両方に送信してもよい。さらに、デルタファイルは、ＥＣＵに関するＥＣＵソフトウェア更新をインストールするためのインストールエージェント（例えば、前述のようなスタートアップコード）を含んでもよい。加えて、デルタファイルは、複数の車両内のＥＣＵを再較正するように構成されてもよい。プロセス１７００はまた、車両のＥＣＵに、ＥＣＵソフトウェア更新に応答して、リブートするように命令するステップを含んでもよい。

ここで図１８を参照すると、ＥＣＵエラーを遠隔監視サーバに報告するためのプロセス１８００を示す、例示的フローチャートが、示される。上記の実施形態によると、プロセス１８００は、図１Ａに描写されるシステム１００内に実装されてもよい。例えば、プロセス１８００は、車両の通信ネットワーク内のプロセッサ（例えば、車両１０４－ｂ内のプロセッサ１１４）またはサーバ１０２によって実施されてもよい。

ステップ１８０２では、プロセス１８００は、データを車両内のオーケストレータから受信してもよい。オーケストレータは、車両内の複数のＥＣＵ（例えば、車両１０４－ｂ内のＥＣＵ１１２および１１８）に電子的にポーリングし、それらがポーリングに適切に応答するかどうかを決定するように構成されてもよい。いくつかの実施形態では、データは、直接、ＥＣＵから受信されてもよい（すなわち、別個のオーケストレータを伴わずに）。さらに、上記に議論されるように、オーケストレータは、１つ以上の機械学習または人工知能機能をＥＣＵから報告されるデータに実施し、ＥＣＵが動作属性（例えば、ＣＰＵ処理、メモリコンテンツ、メモリアクセスパターン、運転者挙動属性等）の許可または予期されるエンベロープ内で動作しているかどうかを決定するように構成されてもよい。

ステップ１８０４では、プロセス１８００は、１つ以上のランタイム属性に基づいて、動作データの統計的モデルを生成するステップを伴う。上記に議論されるように、これは、ＥＣＵのための多層モデルの第１の階層の一部であってもよい。統計的モデルは、多変量または一変量時系列分析に基づいてもよく、ＣＰＵまたはメモリ使用量、アクセスされているメモリシーケンス、キャッシュコンテンツまたはアクセス履歴、ページ故障等の属性を考慮してもよい。統計的モデルはさらに、離散時間スライスにおけるメモリの占有面積における起動プロセスの相関に基づいてもよい。加えて、統計的モデルは、ＥＣＵ上で起動するソフトウェアの周波数または実行経路（例えば、ＶＦＳに基づいて）に基づいてもよい。さらに、統計的モデルは、運転者挙動属性（例えば、急ブレーキまたはソフトブレーキ、加速、または方向転換、または制動、加速、または方向転換の頻度等）に基づいてもよい。加えて、統計的モデルは、ＯＢＤエラーメッセージ等のＯＢＤメッセージを考慮してもよい。

ステップ１８０６では、プロセス１８００は、ライブランタイム更新を監視されている１つ以上のＥＣＵから受信するステップを伴う。上記に議論されるように、これは、プッシュ配信またはプル配信機能に基づいてもよい。ＥＣＵからのデータは、車両内のオーケストレータまたは遠隔サーバ（例えば、サーバ１０２）によって取得されてもよい。

ステップ１８０８では、プロセス１８００は、受信されたデータに基づいて、ＥＣＵと関連付けられたＥＣＵエラーを識別するステップを伴ってもよい。いくつかの実施形態では、ＥＣＵエラーは、統計的モデル（上記に説明されるように）とＥＣＵからのライブランタイム更新を比較することによって決定される。いくつかの実施形態では、収集されたデータは、ＥＣＵの識別子を含んでもよい。収集されたデータは、ＥＣＵの最後の既知のポーリングを示すデータを含んでもよい。いくつかの実施形態では、プロセス１８００は、収集されたデータに基づいて、ＥＣＵに関する休止時間の確率を決定してもよい。ステップ１８０８では、プロセス１８００は、収集されたデータに基づいて、報告（ＥＣＵおよび識別されたＥＣＵエラーを識別する）を車両から遠隔監視サーバ（例えば、サーバ１０２）に無線で送信してもよい。

いくつかの実施形態では、プロセス１８００は、要求メッセージをＥＣＵに送信し、ＥＣＵがポーリングに適切に応答しているかどうかを決定することによって、ＥＣＵにポーリングしてもよい。いくつかの実施形態では、プロセス１８００は、ＥＣＵがポーリングに応答することに失敗することに基づいて、ＥＣＵエラーを識別してもよい。プロセス１８００はまた、ＥＣＵがポーリングに正しくなく応答することに基づいて、ＥＣＵエラーを識別してもよい。いくつかの実施形態では、プロセス１８００は、ＥＣＵ内の検出されたスタックオーバーフローに基づいて、ＥＣＵエラーを識別してもよい。

いくつかの実施形態では、プロセス１８００は、ＥＣＵにポーリングし、ＥＣＵが車両の１つ以上のハードウェアコンポーネントに潜在的に影響を及ぼすＥＣＵソフトウェアを実行するかどうかを決定してもよい。プロセス１８００は、車両の１つ以上のハードウェアコンポーネントによって報告されるデータ上で実施される１つ以上の統計的分析に基づいて、ＥＣＵが潜在的に影響を及ぼすＥＣＵソフトウェアを実行するかどうかを決定してもよい。

ステップ１８１０では、プロセス１８００はさらに、検出されたＥＣＵおよびＥＣＵエラーを識別する報告を車両からサーバ（例えば、サーバ１０２）に無線で送信するステップを伴ってもよい。続いて、サーバ１０２は、さらなる分析をＥＣＵおよび識別されたエラー上で実施してもよい。いくつかの実施形態では、サーバ１０２はさらに、ＥＣＵから収集されたランタイムデータのサンプル、ＥＣＵにおいて起動しているデルタファイルの識別、ＥＣＵのソフトウェアバージョン、またはＥＣＵメモリの実際のコンテンツ等を受信してもよい。

プロセス１８００はまた、ステップ１８１２において、潜在的影響が有害であるかどうかを決定してもよい。そのような状況では、ステップ１８１３４において、制御アクションが、ＥＣＵのために実装されてもよい。例えば、ＥＣＵは、上記に説明されるデルタ－ファイルベースのソフトウェア更新プロセスを使用して、調節されてもよい。さらに、ＥＣＵは、ＥＣＵソフトウェアの以前のバージョンへのロールバックを実施する、またはＥＣＵソフトウェアの新しいバージョンへの更新を実施するように命令されてもよい。加えて、いくつかの実施形態では、制御アクションは、ＥＣＵをある機能（例えば、ネットワーク通信、メモリ修正等）が限定される安全動作モードに設定するステップを含んでもよい。

開示される実施形態は、必ずしも、その用途において、以下の説明に記載され、および／または図面および／または実施例に図示される、コンポーネントおよび／または方法の構造および配列の詳細に限定されないことを理解されたい。開示される実施形態は、変形例または種々の方法において実践される、または行われることが可能である。

開示される実施形態は、システム、方法、および／またはコンピュータプログラム製品において実装されてもよい。コンピュータプログラム製品は、プロセッサに本開示の側面を行わせるためのコンピュータ可読プログラム命令をその上に有する、コンピュータ可読記憶媒体（または複数の媒体）を含んでもよい。

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のための命令を留保および記憶し得る、有形デバイスであることができる。コンピュータ可読記憶媒体は、例えば、限定ではないが、電子記憶デバイス、磁気記憶デバイス、光学記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、または前述の任意の好適な組み合わせであってもよい。コンピュータ可読記憶媒体のより具体的実施例の非包括的リストは、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、消去可能なプログラム可能読取専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、ポータブルコンパクトディスク読取専用メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリスティック、フロッピー（登録商標）ディスク、その上に記録される命令を有する、パンチカードまたは溝内の隆起構造等の機械的にエンコードされたデバイス、および前述の任意の好適な組み合わせを含む。コンピュータ可読記憶媒体は、本明細書で使用されるように、それ自体では、無線波または他の自由に伝搬する電磁波、導波管または他の伝送媒体を通して伝搬する、電磁波（例えば、光ファイバケーブルを通して通過する、光パルス）、またはワイヤを通して伝送される、電気信号等の一過性信号であるとして解釈されるべきではない。

本明細書に説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体から個別のコンピューティング／処理デバイスに、またはネットワーク、例えば、インターネット、ローカルエリアネットワーク、広域ネットワーク、および／または無線ネットワークを介して、外部コンピュータまたは外部記憶デバイスにダウンロードされることができる。ネットワークは、銅伝送ケーブル、光学伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、および／またはエッジサーバを備えてもよい。各コンピューティング／処理デバイス内のネットワークアダプタカードまたはネットワークインターフェースは、コンピュータ可読プログラム命令をネットワークから受信し、個別のコンピューティング／処理デバイスの中のコンピュータ可読記憶媒体内への記憶のために、コンピュータ可読プログラム命令を転送する。

本開示の動作を行うためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはＳｍａｌｌｔａｌｋ、Ｃ＋＋、または同等物等のオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または類似プログラミング言語等の従来の手続型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書き込まれるソースコードまたはオブジェクトコードのいずれかであってもよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で完全に、ユーザのコンピュータ上で部分的に、独立型ソフトウェアパッケージとして、部分的にユーザのコンピュータ上および部分的に遠隔コンピュータ上で、または遠隔コンピュータまたはサーバ上で完全に実行されてもよい。後者のシナリオでは、遠隔コンピュータは、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む、任意のタイプのネットワークを通して、ユーザのコンピュータに接続されてもよい、または接続は、外部コンピュータに行われてもよい（例えば、インターネットサービスプロバイダを使用して、インターネットを通して）。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはプログラマブル論理アレイ（ＰＬＡ）を含む、電子回路が、本開示の側面を実施するために、コンピュータ可読プログラム命令の状態情報を利用して、電子回路を個人化することによって、コンピュータ可読プログラム命令を実行してもよい。

本開示の側面は、本開示の実施形態による、方法、装置（システム）、およびコンピュータプログラム製品のフローチャート図および／またはブロック図を参照して本明細書に説明される。フローチャート図および／またはブロック図の各ブロックおよびフローチャート図および／またはブロック図内のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装されることができることを理解されたい。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行される命令が、フローチャートおよび／またはブロック図のブロックまたは複数のブロックに規定される機能／行為を実装するための手段を作成するような機械を生産するために、汎用コンピュータ、特殊目的コンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供されてもよい。これらのコンピュータ可読プログラム命令はまた、その中に記憶される命令を有する、コンピュータ可読記憶媒体が、フローチャートおよび／またはブロック図のブロックまたは複数のブロックに規定される機能／行為の側面を実装する、命令を含む、製造品を構成するように、コンピュータ、プログラマブルデータ処理装置、および／または他のデバイスに、特定の様式において機能するように指示し得る、コンピュータ可読記憶媒体内に記憶されてもよい。

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラマブル装置、または他のデバイス上で実行される、命令が、フローチャートおよび／またはブロック図のブロックまたは複数のブロックに規定される機能／行為を実装するように、コンピュータ、他のプログラマブルデータ処理装置、または他のデバイス上にロードされ、一連の動作ステップをコンピュータ、他のプログラマブル装置、または他のデバイス上で実施させ、コンピュータ実装プロセスを生産させてもよい。

図中のフローチャートおよびブロック図は、本開示の種々の実施形態による、システム、方法、およびコンピュータプログラム製品の可能性として考えられる実装のアーキテクチャ、機能性、および動作を図示する。この点において、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つ以上の実行可能命令を備える、ソフトウェアプログラム、セグメント、またはコードの一部を表してもよい。また、いくつかの代替実装では、ブロック内に記載される機能は、図に記載の順序から外れて生じ得ることに留意されたい。例えば、連続して示される２つのブロックは、実際は、実質的に並行して実行されてもよい、またはブロックは、関わる機能性に応じて、時として、逆の順序で実行されてもよい。また、ブロック図および／またはフローチャート図の各ブロックおよびブロック図および／またはフローチャート図内のブロックの組み合わせは、規定された機能または行為を実施する、特殊目的のハードウェアベースのシステム、または特殊目的ハードウェアおよびコンピュータ命令の組み合わせによって実装されることができることに留意されたい。

本開示の種々の実施形態の説明は、例証目的のために提示されたが、包括的である、または開示される実施形態に限定されることを意図するものではない。多くの修正および変形例が、説明される実施形態の範囲および精神から逸脱することなく、当業者に明白となるであろう。本明細書で使用される専門用語は、実施形態の原理、市場に見出される技術に優る実践的用途または技術的改良を最良に説明する、または当業者が本明細書に開示される実施形態を理解することを可能にするように選定された。

本願からの特許権の存続期間が満期になるまでの間、多くの関連仮想化プラットフォーム、仮想化プラットフォーム環境、信頼クラウドプラットフォームリソース、クラウドベースのアセット、プロトコル、通信ネットワーク、セキュリティトークン、および認証証明書が、開発されるであろうことが予期され、これらの用語の範囲は、全てのそのような新しい技術を先験的に含むように意図される。

明確にするために別個の実施形態のコンテキストに説明される、本開示のある特徴はまた、単一実施形態における組み合わせを提供されてもよいことを理解されたい。逆に言えば、簡潔にするために単一実施形態のコンテキストに説明される、本開示の種々の特徴はまた、別個に、または任意の好適な副次的組み合わせにおいて、または本開示の任意の他の説明される実施形態において好適なものとして、提供されてもよい。種々の実施形態のコンテキストに説明される、ある特徴は、実施形態がそれらの要素を伴わずに動作不能ではない限り、それらの実施形態の不可欠な特徴と見なされるべきではない。

本開示は、その具体的実施形態と併せて説明されたが、多くの代替、修正、および変形例が、当業者に明白となるであろうことが明白である。故に、添付の請求項の精神および広義の範囲内にある、全てのそのような代替、修正、および変形例を包含するように意図される。

Claims

非一過性のコンピュータ読み取り可能な媒体であって、前記非一過性のコンピュータ読み取り可能な媒体は、命令を含み、前記命令は、少なくとも１つのプロセッサよって実行されると、コントローラ上のソフトウェアを更新するための更新パッケージを生成するための動作を実行することを前記少なくとも１つのプロセッサに行わせ、
前記動作は、
前記コントローラ上で実行されるべきソフトウェア更新の第１の属性にアクセスすることと、
前記コントローラ上に記憶されている現在のソフトウェアの第２の属性にアクセスすることと、
前記第１の属性と前記第２の属性とを比較することと、
前記比較において決定された前記第１の属性と前記第２の属性との間の差異に基づいてデルタファイルを生成することと、
前記デルタファイルを前記コントローラに提供することであって、前記デルタファイルは、前記コントローラ内で実行されるように構成されており、前記コントローラ内のスタートアップコードは、前記コントローラのプログラムカウンタを更新することにより、前記現在のソフトウェア内に含まれているコードのセグメントをスキップし、その代わりに前記デルタファイル内に含まれているコードのセグメントを実行するように構成されている、ことと
を含む、非一過性のコンピュータ読み取り可能な媒体。
前記スタートアップコードは、前記デルタファイルの中に統合されている、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記スタートアップコードは、前記デルタファイルが前記コントローラによって受信される前に、前記コントローラ上にインストールされている、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記スタートアップコードは、前記デルタファイル内に含まれる少なくとも１つの命令の実行を前記コントローラ上に記憶されている前記現在のソフトウェアに含まれるコードにリンクさせるように構成されている、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記現在のソフトウェアと前記デルタファイル内に含まれる少なくとも１つの命令との前記リンクされた実行は、前記コントローラをリブートする前に機能しているソフトウェア更新の機能均等物を形成する、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記デルタファイルは、容認可能な動作エンベロープからの前記コントローラの挙動の検出された逸脱に応答して、前記コントローラに提供される、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記容認可能な動作エンベロープは、前記コントローラの観察される機能性のモデルまたはマップによって表される、請求項６に記載の非一過性のコンピュータ読み取り可能な媒体。
前記デルタファイルは、位置独立コードを含む、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記コントローラは、第１のコントローラであり、
前記動作は、
相互依存性マッピングを使用して、前記第１のコントローラと第２のコントローラとの間の関係を決定することと、
前記第１のコントローラと前記第２のコントローラとの間の関係に基づいて、前記第２のコントローラにおいてソフトウェア変更をプロンプトすることと
をさらに含む、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記相互依存性マッピングは、予期または要求されているデータ通信の予期されたフォーマット、特定のネットワークアドレス、または、特定の通信のタイミング要求のうちの少なくとも１つに基づいている、請求項９に記載の非一過性のコンピュータ読み取り可能な媒体。
前記第１の属性および前記第２の属性のそれぞれは、ソースコード次元、バイナリコード次元、または、マップファイル次元のうちの少なくとも１つを含む、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記第１の属性は、前記ソフトウェア更新の複数の互いに異なるソフトウェア表現であり、
前記第２の属性は、前記現在のソフトウェアの複数の互いに異なるソフトウェア表現である、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記デルタファイルが、前記コントローラが動作している間に、前記コントローラの単一のメモリの第１の場所に記憶される一方で、前記単一のメモリの第２の場所に記憶されている現在のコントローラのソフトウェアのコードセグメントを同時に実行する、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記第１の属性と前記第２の属性とを比較することは、ソースコード言語を識別するソース属性、ソースコードのバージョン、ソースコードがフラットであるかどうか、ソースコード内で参照されるオブジェクトの数、または、ソースコード内で参照されるオブジェクトのタイプのうちの少なくとも１つに基づいている、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記第１の属性と前記第２の属性とを比較することは、現在のコントローラのソフトウェアまたは現在のソフトウェア更新内の機能とエンティティとの間の関係、前記現在のコントローラのソフトウェアまたは前記現在のソフトウェア更新のサイズ、具体的メモリアドレス、メモリ場所に対応する具体的機能、または、メモリ場所に対応するコマンドのうちの少なくとも１つを説明するマップファイルに基づいている、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記コントローラは、仮想ファイルシステム（ＶＦＳ）を使用して、前記コントローラに関連付けられた異なるコードのセグメントの異なるバージョンを追跡するように構成されている、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記デルタファイルは、バイナリファイルまたは１６進数ファイルである、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
前記デルタファイルは、第１のデルタファイルであり、
前記第１のデルタファイルが前記コントローラに提供されるとき、前記コントローラは、第２のデルタファイルを記憶する、請求項１に記載の非一過性のコンピュータ読み取り可能な媒体。
コントローラ上のソフトウェアを更新するための更新パッケージを生成するシステムであって、前記システムは、
１つ以上のプロセッサと、
１つ以上のメモリと
を備え、
前記１つ以上のメモリは、命令を有し、前記命令は、前記少なくとも１つのプロセッサよって実行されると、
前記コントローラ上で実行されるべきソフトウェア更新の第１の属性にアクセスすることと、
前記コントローラ上に記憶されている現在のソフトウェアの第２の属性にアクセスすることと、
前記第１の属性と前記第２の属性とを比較することと、
前記比較において決定された前記第１の属性と前記第２の属性との間の差異に基づいてデルタファイルを生成することと、
前記デルタファイルを前記コントローラに提供することであって、前記デルタファイルは、前記コントローラ内で実行されるように構成されており、前記コントローラ内のスタートアップコードは、前記コントローラのプログラムカウンタを更新することにより、前記現在のソフトウェア内に含まれているコードのセグメントをスキップし、その代わりに前記デルタファイル内に含まれているコードのセグメントを実行するように構成されている、ことと
を含む動作を実行することを前記少なくとも１つのプロセッサに行わせる、システム。
コントローラ上のソフトウェアを更新するための更新パッケージを生成するためのコンピュータ実装方法であって、前記方法は、
前記コントローラ上で実行されるべきソフトウェア更新の第１の属性にアクセスすることと、
前記コントローラ上に記憶されている現在のソフトウェアの第２の属性にアクセスすることと、
前記第１の属性と前記第２の属性とを比較することと、
前記比較において決定された前記第１の属性と前記第２の属性との間の差異に基づいてデルタファイルを生成することと、
前記デルタファイルを前記コントローラに提供することであって、前記デルタファイルは、前記コントローラ内で実行されるように構成されており、前記コントローラ内のスタートアップコードは、前記コントローラのプログラムカウンタを更新することにより、前記現在のソフトウェア内に含まれているコードのセグメントをスキップし、その代わりに前記デルタファイル内に含まれているコードのセグメントを実行するように構成されている、ことと
を含む、方法。