図面 (/)

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

出願人 オーロラ ラブズ リミテッド
発明者 フォックス,ゾハール
出願日 2018年7月24日 (2年5ヶ月経過) 出願番号 2020-504213
公開日 2020年9月24日 (3ヶ月経過) 公開番号 2020-528629
状態 未査定
技術分野 ストアードプログラムにおける機密保護 ストアードプログラム 計算機間の情報転送 車両用電気・流体回路
主要キーワード 回る速さ 人工知能アルゴリズム 共通タイプ 部品製造業者 機械依存 生産ツール 電子記憶デバイス 故障分析
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年9月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

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

概要

背景

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

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

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

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

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

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

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

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

概要

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

目的

いくつかの車は、運転体験を向上させるように構成される、ECUを装備し得、いくつかの車は、高度な(または自動化された)運転補助を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

一過性コンピュータ可読媒体であって、前記非一過性コンピュータ可読媒体は、命令を含み、前記命令は、少なくとも1つのプロセッサよって実行されると、前記少なくとも1つのプロセッサに、車両内電子制御ユニット(ECU)上のソフトウェア更新するための更新パッケージを生成するための動作を実施させ、前記動作は、前記車両内のECU上に記憶されるべきソフトウェア更新の複数の属性アクセスすることと、前記車両内のECU上に記憶される現在のソフトウェアの対応する複数の属性にアクセスすることと、前記複数の属性と前記対応する複数の属性を比較することと、前記比較において決定された前記複数の属性と前記対応する複数の属性との間の差異を表すデルタファイルを生成することと、前記デルタファイルを前記ECUに提供することであって、前記デルタファイルは、前記デルタファイルが前記車両内のECU内で実行することを有効にする前記ECU内のスタートアップコードによって処理されるように構成される、こととを含む、非一過性コンピュータ可読媒体。

請求項2

前記スタートアップコードは、前記デルタファイルの中に統合される、請求項1に記載の非一過性コンピュータ可読媒体。

請求項3

前記スタートアップコードは、前記デルタファイルが前記ECUによって受信される前に、前記ECU上にインストールされる、請求項1に記載の非一過性コンピュータ可読媒体。

請求項4

前記スタートアップコードは、前記デルタファイルのランタイムライブラリ初期化するように構成される、請求項1に記載の非一過性コンピュータ可読媒体。

請求項5

前記スタートアップコードは、前記ECUのプログラムカウンタを更新し、前記デルタファイル内に含有される命令を実行するように構成される、請求項1に記載の非一過性コンピュータ可読媒体。

請求項6

前記デルタファイルは、前記ソフトウェア更新によって参照される変数の値を表す変数データを備える、請求項1に記載の非一過性コンピュータ可読媒体。

請求項7

前記スタートアップコードは、前記変数データを前記デルタファイルから抽出し、前記変数データを前記ECUにアクセス可能メモリの中に設置するように構成される、請求項6に記載の非一過性コンピュータ可読媒体。

請求項8

前記デルタファイルは、前記ECU内のメモリアドレスを更新するためのコードを備える、請求項1に記載の非一過性コンピュータ可読媒体。

請求項9

前記スタートアップコードは、メモリアドレスを更新するためのコードを抽出し、前記ECU内のメモリアドレスを更新するように構成される、請求項8に記載の非一過性コンピュータ可読媒体。

請求項10

前記ECU上のソフトウェアは、複数の機能ユニットマッピングされ、前記ECUは、仮想ファイルシステム(VFS)を利用して、前記複数の機能ユニットのそれぞれの1つ以上のバージョンを管理および追跡するように構成される、請求項1に記載の非一過性コンピュータ可読媒体。

請求項11

前記ECU上に記憶されるべき前記ソフトウェア更新の複数の属性は、前記VFSによって管理される前記複数の機能ユニットのうちの少なくとも1つを備える、請求項10に記載の非一過性コンピュータ可読媒体。

請求項12

前記命令はさらに、第1のグリッドを前記ソフトウェア更新に適用することと、第2のグリッドを前記ECU上に記憶される現在のソフトウェアに適用することと、前記第1および第2のグリッドの比較に基づいて、前記複数の属性および前記対応する複数の属性を識別することとを含む、請求項1に記載の非一過性コンピュータ可読媒体。

請求項13

前記第1のグリッドは、前記ソフトウェア更新と関連付けられたバイナリデータと、前記ソフトウェア更新と関連付けられたソース属性と、前記ソフトウェア更新と関連付けられたマップファイルとのうちの少なくとも1つを含む1つ以上の次元における前記ソフトウェア更新を表す、請求項12に記載の非一過性コンピュータ可読媒体。

請求項14

前記複数の属性は、少なくとも部分的に、前記ソフトウェア更新を開発するために使用されるプログラミング言語に基づいて識別される、請求項1に記載の非一過性コンピュータ可読媒体。

請求項15

前記複数の属性は、少なくとも部分的に、前記ソフトウェア更新のバイナリファイル分解能に基づいて識別される、請求項1に記載の非一過性コンピュータ可読媒体。

請求項16

前記複数の属性は、少なくとも部分的に、前記ソフトウェア更新と関連付けられたマップファイルに基づいて識別される、請求項1に記載の非一過性コンピュータ可読媒体。

請求項17

前記ソフトウェア更新は、モノリシックファイルである、請求項1に記載の非一過性コンピュータ可読媒体。

請求項18

前記ソフトウェア更新は、他のファイルに相互依存するファイルである、請求項1に記載の非一過性コンピュータ可読媒体。

請求項19

前記動作は、前記デルタファイルを前記ECUに提供する前に、依存性ステムチェックし、前記ECUのために提供されている前記デルタファイルに基づいて、任意の相互依存ECUが更新されるべきであるかどうかを決定することを含む、請求項1に記載の非一過性コンピュータ可読媒体。

請求項20

前記動作はさらに、付加的デルタファイルを前記相互依存ECUに自動的に提供し、前記相互依存ECUに関するソフトウェア更新を実施することを含む、請求項19に記載の非一過性コンピュータ可読媒体。

請求項21

車両内の電子制御ユニット(ECU)上のソフトウェアを更新するための更新パッケージを生成するためのシステムであって、前記システムは、1つ以上のプロセッサと、1つ以上のメモリであって、前記1つ以上のメモリは、命令を有し、前記命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、前記車両内のECU上に記憶されるべきソフトウェア更新の複数の属性にアクセスする動作と、前記車両内のECU上に記憶される現在のソフトウェアの対応する複数の属性にアクセスする動作と、前記複数の属性と前記対応する複数の属性を比較する動作と、前記比較において決定された前記複数の属性と前記対応する複数の属性との間の差異を表すデルタファイルを生成する動作と、前記デルタファイルを前記ECUに提供する動作であって、前記デルタファイルは、前記デルタファイルが前記車両内のECU内で実行することを有効にする前記ECU内のスタートアップコードによって処理されるように構成される、動作とを実施させる、1つ以上のメモリとを備える、システム。

請求項22

前記スタートアップコードは、前記デルタファイルのランタイムライブラリを初期化するように構成される、請求項21に記載のシステム。

請求項23

車両内の電子制御ユニット(ECU)上のソフトウェアを更新するための更新パッケージを生成するためのコンピュータ実装方法であって、前記方法は、前記車両内のECU上に記憶されるべきソフトウェア更新の複数の属性にアクセスすることと、前記車両内のECU上に記憶される現在のソフトウェアの対応する複数の属性にアクセスすることと、前記複数の属性と前記対応する複数の属性を比較することと、前記比較において決定された前記複数の属性と前記対応する複数の属性との間の差異を表すデルタファイルを生成することと、前記デルタファイルを前記ECUに提供することであって、前記デルタファイルは、前記デルタファイルが前記車両内のECU内で実行することを有効にする前記ECU内のスタートアップコードによって処理されるように構成される、こととを含む、方法。

請求項24

前記スタートアップコードは、前記デルタファイルのランタイムライブラリを初期化するように構成される、請求項23に記載の方法。

技術分野

0001

(関連出願の相互参照
本願は、両方とも、参照することによってその全体として本明細書に組み込まれる、2017年7月25日に出願された、米国仮特許出願第62/536,767号および2017年9月19日に出願された、米国仮特許出願第62/560,224号の優先権を主張する。

背景技術

0002

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

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

課題を解決するための手段

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

開示される実施形態によると、ECUソフトウェアの第2のバージョンは、VFSによって無効にされる1つ以上の機能ユニットを有する、ECUソフトウェアの第1のバージョンである。

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0091

開示される実施形態によると、ECUソフトウェアの第2のバージョンは、VFSによって無効にされる1つ以上の機能ユニットを有する、ECUソフトウェアの第1のバージョンである。

0092

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

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

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

0100

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

0101

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

0102

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

0103

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

0104

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

0105

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

0106

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

0107

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

0108

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

0109

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

0110

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

0111

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

0112

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

0113

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

0114

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

0115

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

0116

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

0117

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

0118

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

0119

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

0120

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

0121

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

0122

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

0123

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

0124

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

0125

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

0126

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

0127

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

0128

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

0129

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

0130

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

0131

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

0132

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

0133

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

0134

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

0135

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

0136

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

0137

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

0138

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

0139

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

0140

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

0141

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

0142

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

0143

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

0144

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

0145

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

0146

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

0147

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

0148

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

0149

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

0150

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

0151

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

0152

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

0153

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

0154

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

0155

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

0156

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

0157

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

0158

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

0159

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

0160

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

0161

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

0162

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

0163

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

0164

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

0165

開示される実施形態によると、ECUソフトウェアの第2のバージョンは、VFSによって無効にされる1つ以上の機能ユニットを有する、ECUソフトウェアの第1のバージョンである。

0166

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

0167

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

0168

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

0169

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

0170

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

0171

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

0172

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

0173

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

0174

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

0175

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

0176

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

0177

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

0178

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

0179

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

0180

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

0181

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

0182

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

0183

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

0184

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

0185

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

0186

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

0187

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

0188

開示される実施形態によると、ECUソフトウェアの第2のバージョンは、VFSによって無効にされる1つ以上の機能ユニットを有する、ECUソフトウェアの前のバージョンである。

0189

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

0190

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

0191

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

0192

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

0193

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

0194

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

0195

前述の一般的説明および以下の詳細な説明は両方とも、例示的および説明的にすぎず、請求されるような開示される実施形態の制限ではないことを理解されたい。

図面の簡単な説明

0196

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

0197

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

0198

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

0199

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

0200

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

0201

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

0202

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

0203

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

0204

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

0205

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

0206

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

0207

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

0208

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

0209

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

0210

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

0211

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

0212

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

0213

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

0214

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

0215

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

0216

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

実施例

0217

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

0218

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

0219

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

0220

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

0221

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

0222

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

0223

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

0224

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

0225

図1Cは、(例えば、車両104−a、104−b、104−c、104−d、または104−e内の)車両通信ネットワーク内のアーキテクチャの例証である。例えば、テレマティック制御ユニット(TCU)134が、ネットワークの中に統合され、車両のための種々の追跡特徴を実施してもよい。いくつかの実施形態では、TCU134は、統合または別個の電気通信送受信機(例えば、セルラー、WiFi、衛星等)、全地球測位システム(GPS)送受信機、および車両通信ネットワークの他のコンポーネントとインターフェースをとるためのコントローラを含んでもよい。ネットワークはまた、外部ネットワーク(例えば、サーバ102)および車両の内部ネットワークとの通信の中心点であり得る、ゲートウェイ136を含んでもよい。いくつかの実施形態では、ゲートウェイ136は、オーケストレータ(下記にさらに議論される)とインターフェースをとってもよく、これは、車両内のECU112の1つ以上の動作を制御する。ネットワークはさらに、オンボード診断ポート138を含んでもよく、これは、診断保守、および他の機能のために、車両ネットワークへの有線接続を可能にする、物理的ポートであってもよい。加えて、車両ネットワークは、ECU112、112a、112b、112c、およびその他等の種々のECUを含んでもよい。図示されるように、ECU112は、他の動作の中でもとりわけ、故障検出および休止時間予測140、ECUソフトウェアの以前のバージョンへの統合されたロールバック142、および統合された診断サービス(UDS)更新144のためのソフトウェア命令で構成されてもよい。これらの機能はさらに、下記に議論される。

0226

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

0227

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

0228

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

0229

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

0230

また、図3に示されるのは、スタートアップコード208であって、これは、3Diffまたはデルタファイル206の中に統合されてもよい。代替として、スタートアップコード208は、現在のソフトウェア204の一部であって、デルタファイル206の一部ではなくてもよい。例えば、そのような実施形態では、スタートアップコード208は、ECUおよびそのソフトウェアと関連付けられた既存のスタートアップまたは初期化コードであってもよい。

0231

いくつかの実施形態では、サーバ102は、スタートアップコード208をデルタファイル206のランタイムライブラリを初期化するように構成してもよい。いくつかの実施形態では、例えば、サーバ102は、スタートアップコード208を、ECU112のプログラムカウンタを更新し、現在のソフトウェア204内に含有されるあるコードをスキップし、代わりに、デルタファイル206内に含有されるあるコードを実行するように構成してもよい。例えば、図4に示されるように、スタートアップコード208は、ECU112が、現在のソフトウェア204内に含有されるコードのセグメントをスキップし(図4では、プログラムカウンタ更新「1」として描写される)、代わりに、デルタファイル206内に含有されるコードのセグメントを実行し得るように(図4では、プログラムカウンタ更新「2」として描写される)、ECU112のプログラムカウンタを更新するように構成されてもよい。サーバ102はまた、デルタファイル206内に含有されるコードのセグメントの実行後、プログラムカウンタが、現在のソフトウェア204内に含有されるコードにリンクバックし得るように(図4では、プログラムカウンタ更新「3」として描写される)、スタートアップコード208をECU112のプログラムカウンタを更新するように構成してもよい。このように、デルタファイル206内に含有されるコードのセグメントは、メモリ120内の任意の場所に設置されることができ、ECU112のプログラムカウンタは、ECU112の実行のために、コードのそのセグメントをメモリ(例えば、フラッシュ、RAM等)の中にロードするために使用されることができる。言い換えると、デルタファイル206内に含有されるコードは、位置独立的であり得、ECU112がメモリ120の任意の既存のコンテンツを消去することを要求せずに、メモリ120内に設置されることができる。さらに、スタートアップコード208は、デルタデータを3Diffまたはデルタファイル206から抽出し、それをECU112のメモリ(例えば、フラッシュ、RAM、ROM等)上に記憶するように構成されてもよい。データは、ソフトウェア202/204のランタイムの間に使用されるデータを含んでもよい。スタートアップコードはまた、ECU112内のメモリの古いコンテンツが消去される必要があるかどうかを決定してもよい(例えば、記憶空間がほぼ満杯であるため)。

0232

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

0233

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

0234

いくつかの実施形態では、ECU112は、仮想ファイルシステム(VFS)230を利用して、シンボルを管理してもよい。本明細書に議論されるように、VFS230は、種々の異なるタイプの仮想ファイルシステム、データベース、またはリストであってもよい。VFS230は、ソフトウェア202/204の要約を提供してもよく、3Diffファイルの要素(例えば、ソース、バイナリ、およびマップファイル属性)を表してもよい。いくつかの実施形態では、ECU112は、VFS230を利用して、異なるバージョンのシンボルを追跡してもよい。例えば、図6に示されるように、第2のデルタファイル216(第2のソフトウェア更新において行われる変更を表す)が、ECU112に利用可能になる場合、かつ第2のデルタファイル216が、シンボル1およびシンボル2に行われるコード変更のバージョン2を含有する場合、ECU112は、VFS230を利用して、異なるバージョンのシンボルを追跡し、実行のために使用されるべき正しいバージョンを決定してもよい。第3のデルタファイル226(第3のソフトウェア更新に行われる変更を表す)が、ECU112に利用可能になる場合、かつ第3のデルタファイル226が、シンボル1に行われるコード変更のバージョン3を含有する場合、ECU112はまた、図7に示されるように、VFS230を利用して、シンボル1のバージョン3を追跡してもよい。

0235

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

0236

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

0237

いくつかの実施形態では、デルタファイル206は、標準16進数またはバイナリファイル(またはS Record、Motorola(登録商標)、およびその他等の他のタイプ)として実装されてもよく、これは、ECU112によって容易に処理されることができる。いくつかの実施形態では、ECU112は、デルタファイル206がメモリ120の中に設置されるにつれて、その動作を継続してもよい(例えば、現在のソフトウェア204内に含有されるコードの実行を継続する)。いくつかの実施形態では、ECU112は、上記に説明される更新プロセスを完了した後、メモリ120をデフラグメントしてもよい。しかしながら、メモリ120をデフラグメントするステップは、ソフトウェア更新毎にではなく、低頻度でのみ必要とされ得ることが検討される。

0238

更新プロセスは、後続ソフトウェア更新が利用可能になるにつれて、数回、繰り返されてもよい。図9に図示されるように、時間T1において、第1のソフトウェア更新が、利用可能になり、サーバ102が、デルタファイル206を生成し、デルタファイル206をECU112に提供したとする。いったんデルタファイル206が、ECU112において受信される(かつメモリ120の中に記憶される)と、ECU112は、上記に説明されるように、その中に含有されるスタートアップコードに基づいて、デルタファイル206を実行し、デルタファイル206をECU112のソフトウェア204にリンクさせてもよい。時間T2において、第2のソフトウェア更新が利用可能になり、第1のソフトウェア更新に取って代わる場合、サーバ102は、上記に説明されるプロセスを繰り返してもよい(例えば、第2のソフトウェア更新とECU112のソフトウェア204を比較し、第2のデルタファイル216を生成し、第2のデルタファイル216をECU112に提供する)。いったん第2のデルタファイル216が、ECU112において受信される(かつメモリ120の中に記憶される)と、ECU112は、その中に含有されるスタートアップコードに基づいて、第2のデルタファイル216を実行し、第2のデルタファイル216をECU112のソフトウェア204にリンクさせてもよい。同様に、時間T3において、第3のソフトウェア更新が利用可能になる場合、サーバ102は、第3のデルタファイル226をECU112に提供してもよく、ECU112は、適宜、第3のデルタファイル226をECU112のソフトウェア204にリンクさせてもよい。

0239

また、図9に図示されるのは、サーバ102が特定のソフトウェア更新にロールバックする能力である。例えば、時間T4におけるある異常(その詳細は、後で説明されるであろう)の検出に応じて、サーバ102は、第3のソフトウェア更新が、実行不可能にされるべきであって、ECUソフトウェアが、前のバージョン(例えば、第2のソフトウェア更新)に戻されるべきことを決定してもよい。サーバ102は、図9に示されるように、ECU112に第3のデルタファイル226とECU112のソフトウェア204との間のリンクを除去する(例えば、図8を参照して前述のように、デルタファイル226内に含有されるコード変更を実行不可能にする)、第2のデルタファイル216内に含有されるスタートアップコードを再実行し、第2のデルタファイル216とECU112のソフトウェア204との間のリンクを再確立するようにプロンプトすることによって、これを達成し得る。

0240

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

0241

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

0242

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

0243

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

0244

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

0245

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

0246

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

0247

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

0248

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

0249

いくつかの実施形態では、オーケストレータ114は、ECU112に加え、他のECUを監視するように構成されてもよい。いくつかの実施形態では、オーケストレータ114は、車両104−b内の複数のECUのリアルタイム処理アクティビティを監視するように構成されてもよい。例えば、いくつかの実施形態では、オーケストレータ114は、ECU112に匹敵すると見なされる少なくとも1つの他のECU118の処理アクティビティに関連する匹敵するデータを受信するように構成されてもよい。

0250

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

0251

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

0252

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

0253

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

0254

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

0255

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

0256

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

0257

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

0258

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

0259

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

0260

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

0261

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

0262

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

0263

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

0264

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

0265

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

0266

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

0267

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

0268

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

0269

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

0270

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

0271

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士通クライアントコンピューティング株式会社の「 情報処理システムおよび中継装置」が 公開されました。( 2020/10/29)

    【課題】情報処理システムの正常性を確保する。【解決手段】第1情報処理装置2Aの更新制御部40Aは、中継装置3に設けられた電源制御マイコン302のファームウェアを更新する。第1情報処理装置2Aの再起動通... 詳細

  • 三菱電機株式会社の「 電子制御装置」が 公開されました。( 2020/10/29)

    【課題】本願は、ケースの外周位置とカバーの外周位置に形成された環状シール部の密閉性を向上することができる電子制御装置を提供するものである。【解決手段】ケース(200A)の外周位置とカバー(300A)の... 詳細

  • 株式会社BSAの「 検索管理装置」が 公開されました。( 2020/10/29)

    【課題】ユーザが情報を検索するために必要な負荷を低減できる検索管理装置を提供する。【解決手段】検索管理装置10は、Webサーバ30にインターネットを介して接続され、クラウド上で提供されるサービスを利用... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ