(57)【特許請求の範囲】
【請求項１】
複数の機能を予め決められた機能グループの単位で管理し、実行する制御コントローラであって、
動的に機能グループ単位を変更するパーティション更新部と、
前記制御コントローラの外部から、システムの稼働環境の変化に応じて機能グループの変更を指示する機能グループ変更実施要求を受信し、当該機能グループ変更実施要求に応答して、前記パーティション更新部によって変更された前記機能グループの実行を許可するモード変更部と、を備え、
前記パーティション更新部は、前記機能グループ単位に使用するメモリ空間を別にする空間分離と前記機能グループ単位に実行する時間を別にする時間分離とに基づいて、前記複数の機能のパーティショニングを実行する、制御コントローラ。
【請求項２】
請求項１において、
前記モード変更部は、前記機能グループ変更実施要求を受信する前に、前記制御コントローラの外部から、前記機能グループの変更の準備を要求する機能グループ変更準備要求を受信し、当該機能グループ変更準備要求に応答して、前記制御コントローラの外部から変更すべき事項が記述された変更情報を取得し、前記パーティション更新部に前記機能グループのパーティションの変更を指示し、
前記パーティション更新部は、前記変更情報に基づいて、前記機能グループのパーティショニングを再設定する、制御コントローラ。
【請求項３】
請求項１において、
前記機能グループは、少なくとも、複数の状況において共通に実行される機能である共通機能グループと状況に応じて実行される機能が異なる個別機能グループとを含む、制御コントローラ。
【請求項４】
請求項３において、
前記空間分離において、前記共通機能グループのメモリアドレス空間と前記個別機能グループのメモリアドレス空間が区別されており、前記共通機能グループと前記個別機能グループとの間のメモリ領域は共有メモリ空間を介して構成される、制御コントローラ。
【請求項５】
請求項３において、
前記制御コントローラは、シングルコアプロセッサで構成され、
前記パーティション更新部は、前記時間分離として、時分割スケジューリングによってタイムパーティショニングを実現し、
前記制御コントローラは、さらに、前記機能グループ毎にスロットを割り当てる時分割制御部を備える、制御コントローラ。
【請求項６】
請求項３において、
前記制御コントローラは、マルチコアプロセッサで構成され、
前記共通機能グループと前記個別機能グループとは異なるコアプロセッサで実行される、制御コントローラ。
【請求項７】
請求項３において、
前記制御コントローラに含まれるプロセッサは、更新対象である前記個別機能グループに含まれるタスクを更新している間に、更新対象以外の前記共通機能グループに含まれるタスクの処理を継続的に実行する、制御コントローラ。
【請求項８】
請求項５において、
前記モード変更部は、前記時分割制御部によって前記機能グループに割り当てられているスロット以外のスロットで、前記パーティション更新部にパーティション変更を指示し、前記パーティション更新部によるパーティション更新後、更新機能グループを起動する、制御コントローラ。
【請求項９】
請求項３において、
前記パーティション更新部は、前記個別機能グループに対しては、実行、書き込み、および読み出しが可能となるように前記メモリ空間を割り当て、少なくとも前記共通機能グループに対しては、前記個別機能グループに割り当てられた前記メモリ空間からの読み出しが可能となるように前記メモリ空間を設定する、制御コントローラ。
【請求項１０】
請求項１において、
前記パーティション更新部は、前記機能グループ単位でのメモリ空間の割り当てとスロットの割り当てに失敗した場合に、動的機能更新エラーを示すイベントを生成し、出力する、制御コントローラ。
【請求項１１】
請求項５において、
前記機能グループに含まれるタスクについてデッドライン判定が有効であり、かつ前記スロットの終了時に当該スロットに割り当てられた前記タスクが未終了の場合、前記時分割制御部は、当該未終了のタスクを異常停止させ、デッドラインミスイベントを生成し、出力する、制御コントローラ。
【請求項１２】
請求項５において、
前記個別機能グループは、当該個別機能グループに含まれるタスクの初期化処理を実行する初期化処理部を含み、
前記初期化処理部は、前記初期化処理を実行する場合には、前記タスクのデッドライン判定を無効にし、当該タスクの初期化処理を完了させた後に前記デッドライン判定を有効にする、制御コントローラ。
【請求項１３】
請求項３において、
前記共通機能グループは、車両制御システムの安全性を保証する処理を実行する機能であり、
前記個別機能グループは、前記車両制御システムの可用性を向上させる処理を実行する機能である、制御コントローラ。
【請求項１４】
第１の制御コントローラと、
第２の制御コントローラと、を備え、
前記第１の制御コントローラは、請求項１に記載の制御コントローラであり、
前記第２の制御コントローラは、前記機能グループ変更実施要求を発行し、前記第１の制御コントローラに送信する、車両制御システム。
【請求項１５】
請求項１４において、
前記第２の制御コントローラは、前記機能グループ変更実施要求を発行する前に、前記
機能グループの変更の準備を要求する機能グループ変更準備要求を発行して前記第１の制御コントローラに送信し、
前記第１の制御コントローラの前記モード変更部は、前記第２の制御コントローラから、前記機能グループ変更準備要求を受信し、当該機能グループ変更準備要求に応答して、前記制御コントローラの外部から変更すべき事項が記述された変更情報を取得し、前記パーティション更新部に前記機能グループのパーティションの変更を指示し、
前記第１の制御コントローラの前記パーティション更新部は、前記変更情報に基づいて、前記機能グループのパーティショニングを再設定する、車両制御システム。
【請求項１６】
請求項１５において、
前記パーティション更新部は、空間分離および時間分離に基づいて、前記複数の機能のパーティショニングを実行する、車両制御システム。
【請求項１７】
請求項１６において、
前記第１の制御コントローラは、第１の機能の処理を実行しつつ、当該第１の機能とは異なる第２の機能を更新する、車両制御システム。
【請求項１８】
請求項１７において、
前記機能グループは、少なくとも、複数の状況において共通に実行される機能である共通機能グループと状況に応じて実行される機能が異なる個別機能グループとを含み、
前記第１の制御コントローラは、第１の状況に応じた第１の機能グループの処理を実行しつつ、前記第１の状況とは異なる第２の状況に応じた第２の機能グループの処理を更新する、車両制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、制御コントローラおよび車両制御システムに関する。
【背景技術】
【０００２】
組込み制御システムは、様々な状況で安全に動作することが求められる。例えば、状況Ａで最適に動作するアルゴリズムと状況Ｂで最適に動作するアルゴリズムが異なる場合には両者のプログラムを搭載する必要がある。しかしながら、両者のプログラムを搭載するためには更に高性能なＣＰＵやメモリが必要となるため、システムのハードウェアコストが高くなる課題がある。例えば、自動運転システムの標識認識プログラムにおいて国Ａと国Ｂの標識を高精度で識別するためには、各国ごとに最適化された２つのプログラムを用意する必要がある。これは２国に限らず、国Ｃや国Ｄなどと更に増える可能性があり、全てのプログラムをシステムに搭載することはコスト増に繋がるため現実的に困難である。
そこで、例えばＯＴＡ（Over The Air）と呼ばれる、必要となった状況で必要なプログラムをダウンロードする技術が提唱されている。【０００３】
また、前述の標識認識プログラムの例の他に、例えば、システムの状況が故障のない通常走行モード（状況Ａ）からコントローラ故障が発生したモード（状況Ｂ）に切り替わった際に、残存コントローラの性能に応じて、制御機能を再構成し、フェールオペレーショナルを試みるユースケースも考えられる。コントローラは、電子制御ユニット（ＥＣＵ）と呼ばれ、ＥＣＵ間は車載ネットワークで接続される。ＥＣＵ間は制御データやプログラムの転送がネットワークを介して可能である。【０００４】
例えば、特許文献１は、ＥＣＵのマイコン故障が発生した際には、残存するＥＣＵの中から優先度に基づいて機能代替するＥＣＵを動的に選定し、選定対象に対して、機能代替するプログラムを転送し、システムの縮退制御を実現可能とする一連の流れを示している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４３９９９８７号公報
【非特許文献】
【０００６】
【非特許文献１】ＩＳＯ２６２６２
【非特許文献２】AVIONICS APPLICATION SOFTWARE STANDARD INTERFACE, PART 1 - REQUIRED SERVICES, ARINC SPECIFICATION 653P1-3, 2010
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１では走行中にプログラムを入れ替えることは考慮されていない。このため、特許文献１の技術には、複数のプログラムを１つのＥＣＵのマイコン上で動作させる際に互いに干渉し、制御性能に影響を与えるという課題があり、処理切り替え後の動作を保証するものではない。【０００８】
一方、無干渉とする方法として、非特許文献１に示す自動車向け機能安全規格ＩＳＯ２６２６２は、Freedom From Interferenceとして無干渉とする方法について開示している。また、一つの実現方法として、非特許文献２では時分割スケジューリングが示されている。【０００９】
しかしながら、非特許文献２による時分割スケジューリングでは、静的にスロットを設計する必要がある。このため、故障後の処理に対しても予めスロットを割り当てておく必要がある。つまり、故障後にも故障前の割り当てが残存し、逆に故障前でも故障後のための割り当てが設定された状態となっている。これは状況Ａや状況Ｂだけでなくすべての状況に対して予めスロット（リソース）を割り当てておくことを示しており、非特許文献２の技術には、リソースを有効利用できないという課題がある。【００１０】
本開示はこのような状況に鑑みてなされたものであり、状況変化に応じて、動的に一部のプログラムを入れ替える際に、他のプログラムの動作に影響を与えずにシステムを更新する技術を提供する。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本開示による制御コントローラは、複数の機能を予め決められた機能グループの単位で管理し、実行する制御コントローラであって、動的に機能グループ単位を変更するパーティション更新部と、制御コントローラの外部から、システムの稼働環境の変化に応じて機能グループの変更を指示する機能グループ変更実施要求を受信し、当該機能グループ変更実施要求に応答して、パーティション更新部によって変更された機能グループの実行を許可するモード変更部と、を備える。【００１２】
本開示に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本開示の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される請求の範囲の様態により達成され実現される。
本明細書の記述は典型的な例示に過ぎず、本開示の請求の範囲又は適用例を如何なる意味においても限定するものではないことを理解する必要がある。
【発明の効果】
【００１３】
本開示の制御コントローラによれば、制御に影響を与えずに状況に応じてシステムの機能を変更可能となるため、可用性と安全性を担保できる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態による車両システム１０のユースケース（車両システムにおける状態遷移）を示す図である。
【図２】本実施形態による車両システム１０の概略構成例を示す図である。
【図３】本実施形態におけるＥＣＵ−Ａ１１の状態遷移の例を示す図である。
【図４】本実施形態による機能グループのデータフローの例を示す図である。
【図５】第１の実施形態の更新前（状況Ａ０１）におけるタスク構成１１１１の例を示す図である。
【図６】第１の実施形態の更新中（状況ＡｔｏＢ０２）における更新機能グループのタスク情報１１１２と実行管理設定１１１３の構成例を示す図である。
【図７】第１の実施形態の更新後（状況Ｂ０３）におけるタスク構成１１１４の例を示す図である。
【図８】第１の実施形態に係るスロット（タイムスロット）設計の例を示す図である。
【図９】第１の実施形態によるタスクのスケジューリング例を示す図である。
【図１０】本実施形態におけるメモリ保護設定の例を示す図である。
【図１１】本実施形態におけるメモリマップの例を示す図である。
【図１２】走行計画部１１０１よる走行計画生成処理を説明するためのフローチャートである。
【図１３】判断機能部１１０２による走行軌道決定処理を説明するためのフローチャートである。
【図１４】共通初期化部１１０３による共通初期化処理を説明するためのフローチャートである。
【図１５】周辺認識１部１１０４による周辺認識処理を説明するためのフローチャートである。
【図１６】状況Ａ固有初期化部１１０５による状況Ａ固有初期化処理を説明するためのフローチャートである。
【図１７】周辺認識２部１１０６による周辺認識処理を説明するためのフローチャートである。
【図１８】状況Ｂ固有初期化部１１０７による状況Ｂ固有初期化処理を説明するためのフローチャートである。状況Ｂ固有初期化部の動作フロー
【図１９】モード変更部１１０８によるモード変更処理を説明するためのフローチャートである。
【図２０】パーティション更新部１１０９によるパーティション更新処理（ステップ１９０３の詳細）を説明するためのフローチャートである。
【図２１】時分割制御部１１１０による時分割制御処理を説明するためのフローチャートである。
【図２２】ＥＣＵ−Ｂ１２の画面表示部１２０１より画面表示処理を説明するためのフローチャートである。
【図２３】ＥＣＵ−Ｂ１２の更新準備指示部１２０２による更新準備指示処理を説明するためのフローチャートである。
【図２４】ＥＣＵ−Ｂ１２の更新実施指示部１２０３による更新実施指示処理を説明するためのフローチャートである。
【図２５】第２の実施形態の、状況ＡｔｏＢ０２における更新機能グループのタスク情報２１１２と状況Ｂ０３におけるタスク情報２１１４の例を示す図である。
【図２６】第２の実施形態によるスロット設計の例を示す図である。
【図２７】第２の実施形態によるタスクスケジューリングの例を示す図である。
【発明を実施するための形態】
【００１５】
本実施形態に係る制御コントローラは、制御システムの制御機能を動的に更新するための技術に関するものである。例えば、当該制御コントローラは、機能グループ同士を無干渉とする、時間的および空間的パーティショニングを実行しつつ、稼働状況に応じて機能グループの一部を入れ替えることにより、システムの可用性と安全性を担保することができる制御システムの制御機能を提供する。
【００１６】
以下、添付図面を参照して本開示の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本開示の原理に則った具体的な実施形態と実装例を示しているが、これらは本開示の理解のためのものであり、決して本開示を限定的に解釈するために用いられるものではない。
【００１７】
本実施形態では、当業者が本開示の技術を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本開示の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。
【００１８】
更に、本開示の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。
【００１９】
なお、以後の説明では「テーブル」形式によって本開示の各情報について説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。
【００２０】
また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。
【００２１】
本実施形態では、各ＥＣＵが所定の判断をするように設定されている場合について説明するが、各ＥＣＵを制御する制御装置が設けられ、当該制御装置が上記所定の判断をするように設定してもよい。
【００２２】
（１）第１の実施形態
＜車両システムのユースケース＞
図１は、本実施形態による車両システム１０のユースケース（車両システムにおける状態遷移）を示す図である。
【００２３】
図１に示されるように、車両システム１０は、状況Ａ０１では、状況Ａに適した機能構成で走行するシステム１となる。また、車両システム１０は、状況Ａから状況Ｂに移動する際の状況Ｂ付近の状況Ａ（状況ＡｔｏＢ０２）では、状況Ｂに適した機能構成で走行する準備を行うシステム２となる。さらに、車両システム１０は、状況Ｂ０３では、状況Ｂに適した機能構成で走行するシステム３となる。
【００２４】
例えば、状況Ａを車両システム１０がＡ国（Ｂ国との国境付近ではない場所）にいる状況とし、状況ＡｔｏＢを車両システム１０がＡ国とＢ国の国境付近にいる状況とし、状況Ｂを車両システム１０がＢ国（Ａ国との国境付近ではない場所）にいる状況とすることができる。また、例えば、状況Ａを各ＥＣＵが正常に動作している状況とし、状況ＡｔｏＢを何れかのＥＣＵで故障が発生しそうな状況とし、状況Ｂを何れかのＥＣＵで故障が発生した後の状況とすることができる。
【００２５】
＜車両システムの構成＞
図２は、本実施形態による車両システム１０の概略構成例を示す図である。車両システム１０は、例えば、ＥＣＵ−Ａ１１とＥＣＵ−Ｂ１２とその他のＥＣＵで構成され、ネットワークバス１３で接続される。第１の実施形態では、各ＥＣＵがネットワークバス１３で接続されているが、このような形態に限られず、各ＥＣＵが１対１に接続されるようなネットワークトポロジであってもよい。
【００２６】
車両システム１０が状況Ａ０１にあるときのシステム１におけるＥＣＵ―Ａ１１は、例えば、プログラムとしての、走行計画部１１０１と、判断機能部１１０２と、共通初期化部１１０３と、周辺認識１部１１０４と、状況Ａ固有初期化部１１０５と、モード変更部１１０８と、パーティション更新部１１０９と、時分割制御部１１１０とによって構成される。また、当該システム１におけるＥＣＵ―Ｂ１２は、プログラムとしての、画面表示部１２０１と、更新準備指示部１２０２と、更新実施指示部１２０３とによって構成される。車両システム１０が状況ＡｔｏＢにあるときのシステム２は、ＥＣＵ−Ａ１１において、システム１の構成と、プログラムとしての、周辺認識２部１１０６と、状況Ｂ固有初期化部１１０７とによって構成されている。
【００２７】
車両システム１０が状況Ｂにあるときのシステム３は、ＥＣＵ−Ａ１１において、システム２の構成から、プログラムとしての、周辺認識１部１１０４と、状況Ａ固有初期化部１１０５とが削除されている構成となっている。なお、状況Ａ固有初期化部１１０５の削除は、ＥＣＵ−Ａ１１が実行してもよいし、各ＥＣＵを管理・制御する制御装置（図示せず）が実行してもよい。
【００２８】
＜ＥＣＵ−Ａの状態遷移＞
図３は、本実施形態におけるＥＣＵ−Ａ１１の状態遷移の例を示す図である。ＥＣＵ−Ａ１１は、はキーＯＮによりシステム初期化モード００１となり、全体初期化処理（共通初期化処理）を行う。初期化終了後、ＥＣＵ−Ａ１１は、パーティションを有効とし、それにより、状態は走行モード００２に遷移する。ここで、本実施形態における「パーティション」とは、メモリを複数の領域に区切り、処理すべきデータを各領域に適切に割り当てること（空間分離）、および時間分離で各種処理をスケジューリングし、このスケジュールに従って処理を実行（ＣＰＵを使うときに影響を受けない）すること（時間分離）を意味する。なお、時間分離の場合、ＣＰＵがシングルコアの場合とマルチコアの場合とでは処理の態様が異なる。前者の場合、時分割でスケジューリングして処理が実行され、後者の場合、例えば、１つ目のコアが共通機能グループの処理を実行し、２つ目のコアが個別機能グループの処理を実行する。また、後者の場合、物理メモリは共通となるが、使用されるメモリ領域（アドレス空間）は異なってくる。
【００２９】
走行モード００２では、最初は状況Ａ走行モード００２１となり、共通機能グループと状況Ａ向け機能グループを実行する（状況Ａの機能の実行）。ＥＣＵ−Ａ１１は、外部（例えば、ＥＣＵ−Ｂ１２や図示しない全体を制御する制御装置など）から更新準備要求を受信すると、状態を機能更新モード００２２に遷移させる。
【００３０】
機能更新モード００２２では、ＥＣＵ−Ａ１１は、更新プログラムと設定情報（更新情報）を取得し、その情報に基づいてパーティションの部分更新と部分初期化処理を実施する。ＥＣＵ−Ａ１１は、部分更新と部分初期化処理と同時に、継続実行対象の機能処理を実行し続ける。例えばＥＣＵ−Ｂ１２から更新実施要求を受信した場合、ＥＣＵ−Ａ１１は、使用しない機能をＯＦＦにし、状態を状況Ｂ走行モード００２３に遷移させる。状況Ｂ走行モード００２３では、ＥＣＵ−Ａ１１は、共通機能グループと状況Ｂ向け機能グループを実行する。
【００３１】
なお、本実施形態では、更新プログラムおよび設定情報は、すでに車両システム１０内のＥＣＵに保存され、ネットワークバス１３経由で配信されることを想定しているが、これに限らない。更新プログラムと設定情報は車両システム外のサーバに保存され、ＯＴＡに基づいて配信されてもよいし、これ以外の方法でも良い。また、更新プログラムや設定情報は、予め、ＥＣＵ−Ａ１１内のメモリ（図示せず）に格納されており、ＥＣＵ−Ａ１１がそこから取得するようにしてもよいし、ＥＣＵ−Ａ１１の外部に専用のメモリ領域が設けられ、ＥＣＵ−Ａ１１がそこから取得するようにしてもよい。
【００３２】
＜機能グループのデータ処理の流れ＞
図４は、本実施形態による機能グループのデータフローの例を示す図である。
図４において、状況Ａ０１では、周辺認識１部１１０４は、カメラ画像とポイントクラウド情報（点群（形状）と距離の情報）を入力とし、走行環境情報を出力する。走行計画部１１０１は、走行環境情報を入力とし、起動候補情報を出力する。また、判断機能部１１０２は、起動候補情報を入力とし、走行軌道情報を出力する。
【００３３】
状況Ｂ０３では、周辺認識１部１１０４が周辺認識２部１１０６に入れ替わる。また、入力と出力情報には変更がない。なお、状況Ａ０２は、状況Ａ０１と同様であるので、説明は省略する。
【００３４】
＜更新前のタスク構成＞
図５は、第１の実施形態の更新前（状況Ａ０１）におけるタスク構成１１１１の例を示す図である。なお、当該タスク構成１１１１（テーブル）は、例えば、ＥＣＵ−Ａ１１のメモリ（図示しない）に設定されて管理される。最初からデータとしてメモリ上に設定されていてもよいし、例えばＥＣＵ−Ｂ１２からデータが送信されてきて設定されるようにしてもよい。
【００３５】
タスク構成１１１１は、タスク名１１１１１と、タスクＩＤ１１１１２と、実行周期１１１１３と、タスク優先度１１１１４と、通常実行期間１１１１５と、初期化実行時間１１１１６と、機能グループ１１１１７と、スケジューリング１１１１８とを構成項目としている。
【００３６】
タスク名１１１１１は、実行する機能をタスクの名称として示す情報である。例えば、走行計画タスクは走行計画部１１０１を、判断機能タスクは判断機能部１１０２を、周辺認識１タスクは周辺認識１部１１０４を、モード変更タスクはモード変更部１１０８を、それぞれ実行する。
【００３７】
タスクＩＤ１１１１２は、タスクを一意に識別・特定することができる識別情報である。実行周期１１１１３は、タスクを起動する周期を示す情報である。単位は例えばミリ秒である。第１の実施形態では、すべての実行周期を同じにしているがこれに限らない。異なる周期であってもよい。
【００３８】
タスク優先度１１１１４は、タスクの優先度を示す情報である。この優先度は、タスクが同時に実行可能状態であるときに、優先して実行される度合いを示しており、数字が小さいほど優先度が高い。この考え方は優先度スケジューリングに基づいている。
【００３９】
通常実行時間１１１１５は、初期化終了後のタスク実行時間（タスク実行に割り当てられた時間）を示す情報である。初期化実行時間１１１１６は、初期化処理の実行時間（初期化処理に割り当てられた時間）を示す情報である。第１の実施形態では、通常実行時間１１１１５と初期化実行時間１１１１６を、最長の実行時間を設定することを想定しているが、これに限らない。例えば、最長の実行時間にマージンを加えたものであってもよいし、別の態様でもよい。
【００４０】
機能グループ１１１１７は、タスクが所属する機能グループを示す情報である。例えば、共通機能グループは、状況に左右されずに実行されるアプリケーションプログラムである。状況Ａ向け機能グループは、状況Ａで実行される機能グループである。システムグループは、基本ソフトウェアの機能グループである。
【００４１】
スケジューリング１１１１８は、タスクが実行されるスケジューリングポリシーを示す情報である。第１の実施形態では、複数のスケジューリングポリシーが共存することを想定しているが、これに限らない。例えば、１つのスケジューリングで統一されていてもよい。ＦＩＦＯ（First-In-First-Out）スケジューリングでは、タスク優先度１１１１４の優先度に基づいて実行され、タスクの終了まで継続して実行される。ＥＤＦ（Earliest Deadline First）は、タスクの実行周期１１１１３をデッドラインと見なすポリシーである（動的スケジューリング）。つまり、ＥＤＦでは、プロセスは優先度付きキューに置かれ、スケジューリングイベントが発生すると(タスク終了、新規タスク生成など)、そのキューを探索して最も実行期限(デッドライン)が近いプロセスが選択され、そのプロセスが次に実行すべきものとしてスケジュールされる。より具体的に説明すると、次の周期が始まる時刻から実行時間通常１１１１５を引いた時間を余裕時間とし、余裕時間がないほど優先度が高く設定される。例えば、ある処理によって実行時間が消費されたが、他にも実行すべきタスクが複数あり、全てのタスクを実行していると５０ｍｓ内に収まらないときに、ＥＤＦがポリシーとして与えられているタスクが５０ｍｓ内に必ず実行されるように優先度が動的に高く設定されることになる。なお、時分割制御の優先度はこれらのタスクの優先度よりも高く設定されるため、時分割制御の動作は保証される。第１の実施形態では、機能グループをタスク単位としているがこれに限らない。例えば、関数単位（プログラム単位）としてもよい。この場合、１つのタスクが複数の機能グループを実行することがありえる。
【００４２】
＜更新中のタスク構成＞
図６は、第１の実施形態の更新中（状況ＡｔｏＢ０２）における更新機能グループのタスク情報１１１２と実行管理設定１１１３の構成例を示す図である。なお、当該タスク構成１１１２および実行管理設定１１１３（テーブル）は、例えば、ＥＣＵ−Ａ１１のメモリ（図示しない）に設定されて管理される。最初からデータとしてメモリ上に設定されていてもよいし、例えばＥＣＵ−Ｂ１２からデータが送信されてきて設定されるようにしてもよい。
【００４３】
（i）タスク情報１１１２は、タスク名１１１２１と、タスクＩＤ１１１２２と、実行周期１１１２３と、タスク優先度１１１２４と、通常実行時間１１１２５と、初期化実行時間１１１２６と、機能グループ１１１２７と、スケジューリング１１１２８とを構成項目としている。
【００４４】
タスク名１１１２１は、実行する機能をタスクの名称として示す情報である。例えば、周辺認識２タスクでは、周辺認識２部１１０６が実行される。タスクＩＤ１１１２２は、タスクを一意に識別・特定することができる識別情報である。実行周期１１１２３は、タスクを起動する周期を示す情報である。単位はミリ秒である。
【００４５】
タスク優先度１１１２４は、タスクの優先度を示す情報である。通常実行時間１１１２５は、初期化終了後の実行時間を示す情報である。初期化実行時間１１１２６は、初期化処理の実行時間を示す情報である。
【００４６】
機能グループ１１１２７は、タスクが所属する機能グループを示す情報である。例えば、状況Ｂ向け機能グループは、状況Ｂで実行される機能グループを意味する。スケジューリング１１１１８は、タスクが実行されるスケジューリングポリシーを示す情報である。
【００４７】
第１の実施形態では、機能グループをタスク単位としているがこれに限らない。例えば関数単位（プログラム単位）としてもよい。この場合、１つのタスクが複数の機能グループを実行することがありえる。
【００４８】
（ii）実行管理設定１１１３は、タスク名１１１３１と、タスクＩＤ１１１３２と、実行管理１１１３３と、機能グループ１１１３４と、スケジューリング１１１３５とを構成項目としている。
タスク名１１１３１は、タスク名称を示す情報である。タスクＩＤ１１１３２は、タスクを一意に識別・特定することができる識別情報である。
【００４９】
実行管理１１１３３は、状況の変化に応じて、処理を終了する機能グループと処理を開始する機能グループを示す情報である。例えば、ＯＦＦは処理の終了、ＯＮは処理の開始を意味する。ＯＮとＯＦＦは機能グループごとに管理される。状況ＡｔｏＢでは、周辺認識２タスクがＯＮとなるように制御され、状況ＡでＯＮであった周辺認識１タスクはＯＦＦとなるように制御される。
【００５０】
機能グループ１１１３４は、タスクが所属する機能グループを示す情報である。スケジューリング１１１３５は、タスクが実行されるスケジューリングポリシーを示す情報である。
【００５１】
＜更新後のタスク構成＞
図７は、第１の実施形態の更新後（状況Ｂ０３）におけるタスク構成１１１４の例を示す図である。なお、当該タスク構成１１１４（テーブル）は、例えば、ＥＣＵ−Ａ１１のメモリ（図示しない）に設定されて管理される。最初からデータとしてメモリ上に設定されていてもよいし、例えばＥＣＵ−Ｂ１２からデータが送信されてきて設定されるようにしてもよい。
【００５２】
タスク構成１１１４は、更新前と同様に、タスク名１１１４１と、タスクＩＤ１１１４２と、実行周期１１１４３と、タスク優先度１１１４４と、通常実行時間１１１４５と、初期化実行時間１１１４６と、機能グループ１１１４７と、スケジューリング１１１４８とを構成項目としている。
【００５３】
タスク名１１１４１は、実行する機能をタスクの名称として示す情報である。例えば、走行計画タスクは走行計画部１１０１を、判断機能タスクは判断機能部１１０２を、周辺認識２タスクは周辺認識２部１１０６を、モード変更タスクはモード変更部１１０８を、それぞれ実行する。
【００５４】
タスクＩＤ１１１４２は、タスクを一意に識別・特定することができる識別情報である。実行周期１１１４３は、タスクを起動する周期を示す。単位はミリ秒である。第１の実施形態ではすべての実行周期を同じにしているがこれに限らず、異なる周期であってもよい。
【００５５】
タスク優先度１１１４４は、タスクの優先度を示す情報である。この優先度は、タスクが同時に実行可能状態であるときに、優先して実行される度合いであり、数字が小さいほど優先度が高い。この考え方は優先度スケジューリングに基づいている。
【００５６】
通常実行時間１１１４５は、初期化終了後の実行時間を示す情報である。初期化実行時間１１１４６は、初期化処理の実行時間を示す情報である。第１の実施形態では、通常実行時間と初期化実行時間を、最長の実行時間を設定することを想定しているが、これに限らない。例えば、最長の実行時間にマージンを加えたものであってもよいし、別の態様であってもよい。
【００５７】
機能グループ１１１４７は、タスクが所属する機能グループを示す情報である。例えば、共通機能グループは、状況に左右されずに実行されるアプリケーションプログラムであり、状況Ｂ向け機能グループは状況Ｂで実行される機能グループである。システムグループは、基本ソフトウェアの機能グループである。
【００５８】
スケジューリング１１１４８は、タスクが実行されるスケジューリングポリシーを示す情報である。第１の実施形態では、複数のスケジューリングポリシーが共存することを想定しているがこれに限らない。例えば、１つのスケジューリングで統一されていてもよい。ＦＩＦＯ（First-In-First-Out）スケジューリングでは、タスク優先度１１１１４の優先度に基づいてタスクが実行され、タスクの終了まで継続して実行される。ＥＤＦ(Earliest Deadline First)は、タスクの実行周期１１１４３をデッドラインと見なすポリシーである。次の周期が始まる時刻から実行時間通常１１１４５を引いた時間を余裕時間とし、余裕時間がないほど優先度が高く設定される方式である。なお、時分割制御の優先度はこれらのタスクの優先度よりも高く設定されるため、時分割制御の動作は保証される。実施の形態１では機能グループをタスク単位としているがこれに限らない。例えば、関数単位（プログラム単位）としてもよい。この場合、１つのタスクが複数の機能グループを実行することがありえる。
【００５９】
＜スロット設計＞
図８は、第１の実施形態に係るスロット（タイムスロット）設計の例を示す図である。図８では、状況Ａと、状況ＡｔｏＢと、状況Ｂのときのスロット設計が示されている。スロット設計は、スロットＩＤ１１１５１、１１１６１、および１１１７１と、開始時間１１１５２、１１１６２、および１１１７２と、終了時間１１１５３、１１１６３、および１１１７３と、実行対象１１１５４、１１１６４、および１１１７４と、を構成項目としている。
【００６０】
（i）状況Ａ０１のスロット設計１１１５
スロットＩＤ１１１５１は、スロットを一意に識別・特定できる識別情報である。開始時間１１１５２は、スロットと定めた時間の開始時刻を示す情報である。終了時刻１１１５３は、スロットと定めた時刻の終了時刻を示す情報である。実行対象１１１５４は、該当するスロットで実行許可されている機能グループを示す情報である。
【００６１】
（ii）状況ＡｔｏＢ０２のスロット設計１１１６
スロットＩＤ１１１６１は、スロットを一意に識別・特定できる識別情報である。開始時間１１１６２は、スロットと定めた時間の開始時刻を示す情報である。終了時刻１１１６３は、スロットと定めた時刻の終了時刻を示す情報である。実行対象１１１６４は、該当するスロットで実行許可されている機能グループを示す情報である。
【００６２】
（iii）状況Ｂ０３のスロット設計１１１７
スロットＩＤ１１１７１は、スロットを一意に識別・特定できる識別情報である。開始時間１１１７２は、スロットと定めた時間の開始時刻を示す情報である。終了時刻１１１７３は、スロットと定めた時刻の終了時刻を示す情報である。実行対象１１１７４は、該当するスロットで実行許可されている機能グループを示す情報である。
【００６３】
第１の実施形態では、一例として、時分割制御のシステム周期を５０ｍｓとしている。システム周期とは前述のスロット設計に基づいて繰り返し実行される周期である。例えば、スロットＩＤ１１１５１が「１」のスロットは、開始時刻１１１５２が０であるため、０ｍｓ目、５０ｍｓ目、１００ｍｓ目、・・・、というように、５０ｍｓ毎に実行される。
【００６４】
また、状況Ａ０１において、スロット２と４の間に、空き時間（待機時間）が設けられている。この空き時間は、情報ＡｔｏＢ０２において、スロット３が割り当てられている。さらに、同様に、状況Ｂ０３では、スロット１と２の間に、空き時間（待機時間）が設けられている。
【００６５】
＜タスクスケジューリング＞
図９は、第１の実施形態によるタスクのスケジューリング例を示す図である。当該スケジューリング例は、図８のスロット設計に基づいてなされたものである。図８は、時分割（時間分離）パーティショニングによるタスクスケジューリングについて示している。
【００６６】
状況Ａ走行モード００２１では、スロットＩＤ１において、タスクＩＤ１および２のタスク（共通機能グループのタスク）が実行され、スロットＩＤ２において、タスクＩＤ３のタスク（状況Ａ向け機能グループのタスク）が実行され、スロットＩＤおいて、タスクＩＤ５のタスク（システムグループのタスク）が実行される。システム周期１１１５５は５０ｍｓである。
【００６７】
機能更新モード００２２では、スロットＩＤ１において、タスクＩＤ１と２のタスク（共通機能グループのタスク）が実行され、スロットＩＤ２において、タスクＩＤ３のタスク（状況Ａ向け機能グループのタスク）が実行され、スロットＩＤ３において、タスクＩＤ４（状況Ｂ向け機能グループのタスク）のタスクが実行され、スロットＩＤ４において、タスクＩＤ５（システムグループのタスク）が実行される。システム周期１１１６５は５０ｍｓである。スロットＩＤ３では、デッドライン判定が無効（デッドライン監視がＯＦＦ）になっているため、タスクＩＤ４のタスクが初期化処理を実行する。そのスロット時間以内に終了しない場合、初期化処理は、スロット終了時に中断されるが、次のスロット開始時刻に再開される。
【００６８】
状況Ｂ走行モード００２３では、スロットＩＤ１において、タスクＩＤ１と２のタスク（共通機能グループのタスク）が実行され、スロットＩＤ３において、タスクＩＤ４のタスク（状況Ｂ向け機能グループのタスク）が実行され、スロットＩＤ４において、タスクＩＤ５のタスク（システムグループのタスク）が実行される。システム周期１１１７５は、上述と同様に、５０ｍｓである。
【００６９】
＜メモリ保護設定＞
図１０は、本実施形態におけるメモリ保護設定の例を示す図である。メモリ保護設定は、表形式で実現され（ただし、表形式に限定されない）、対象となる機能グループの名称（種別であってもよい）を示す機能グループ４１１、４２１、および４３１と、対応する機能グループがアクセスできるメモリ領域を示すアクセス可能領域４１２、４２２、および４３２と、対応する機能グループがアクセスできないメモリ領域を示すアクセス不可領域４１３、４２３、および４３３と、を構成項目として有している。
【００７０】
状況Ａ０１、状況ＡｔｏＢ、および状況Ｂ０３において、アクセス可能領域４１２、４２２、および４３２は、書き込み、読み出し、関数実行が許可されている領域を示す。アクセス不可領域４１３、４２３、および４３３は、データの書き込み、データの読み出し、関数実行が許可されていない領域を示す。
【００７１】
なお、本実施形態では、アクセス可能領域４１２、４２２および４３２とアクセス不可領域４１３、４２３、および４３３の２つ（２種類）でメモリアクセスを管理しているが、これに限らない。例えば、限定アクセス可能領域として、データの読み出しのみ許可されている領域を設定できるようにしてもよいし、これにも限らない。例えば、各状況において、個別機能グループ（例えば、状況Ａ向け機能グループおよび状況Ｂ向け機能グループ）に割り当てられたメモリアドレス空間（領域）に対しては、個別機能グループの各タスクの実行、書き込み、読み出しが許可されているが、共通機能グループのタスクは読み出しのみ許可されるように構成してもよい。
【００７２】
＜メモリマップ＞
図１１は、本実施形態におけるメモリマップの例を示す図である。図１１の例では、ＥＣＵ−Ａ１１が使用するメモリは、４つ領域（領域ＡからＤ）に分割されている（空間分離）。ただし、本実施形態によるメモリマップでは、非特許文献１とは異なり、各領域にアクセスできる機能グループが固定となっていない。例えば、外部からの指令に従って、ＥＣＵ−Ａ１１が各機能グループについて使用するメモリ領域を割り当てることも可能である（例えば、第２の実施形態参照）。
【００７３】
状況Ａ０１のメモリマップ５１では、共通機能グループ５１１が領域Ａ５１７にマッピングされ、共有メモリ領域５１２と空きメモリ領域５１３が領域Ｂ５１８にマッピングされ、状況Ａ向け機能グループ５１４と空きメモリ領域５１５が領域Ｃ５１９にマッピングされ、空きメモリ領域５１６が領域Ｄ５１０にマッピングされている。
【００７４】
状況ＡｔｏＢ０２のメモリマップ５２では、共通機能グループ５２０１が領域Ａ５２０８にマッピングされ、共有メモリ領域５２０２と空きメモリ領域５２０３が領域Ｂ５２０９にマッピングされ、状況Ａ向け機能グループ５２０４と空きメモリ領域５２０５が領域Ｃ５２１０にマッピングされ、状況Ｂ向け機能グループ５２０６と空きメモリ領域５２０７が領域Ｄ５２１１にマッピングされている。
【００７５】
状況Ｂ０３のメモリマップ５３では、共通機能グループ５３１が領域Ａ５３７にマッピングされ、共有メモリ領域５３２と空きメモリ領域５３３が領域Ｂ５３８にマッピングされ、空きメモリ領域５３４が領域Ｃ５３９にマッピングされ、状況Ｂ向け機能グループ５３５と空きメモリ領域５３６が領域Ｄ５３０にマッピングされている。
【００７６】
＜走行計画生成処理＞
図１２は、走行計画部１１０１よる走行計画生成処理を説明するためのフローチャートである。ここでは、走行計画部１１０１を動作主体としているが、走行計画部１１０１はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【００７７】
ステップ１２０１において、走行計画部１１０１は、周辺状況に応じた走行軌道の候補を算出し、保存する。周辺状況は、例えば、カメラによって撮像された画像とポイントクラウド情報を用いて周辺認識１部１１０４によって演算される。周辺状況の情報としては、例えば、前方の車両の有無やその距離、道路の車線の情報、周辺の地物の情報などである。
【００７８】
＜走行軌道決定処理＞
図１３は、判断機能部１１０２による走行軌道決定処理を説明するためのフローチャートである。ここでは、判断機能部１１０２を動作主体としているが、判断機能部１１０２はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【００７９】
（i）ステップ１３０１
判断機能部１１０２は、走行計画生成処理（図１２）で得られた走行軌道の候補から採用する走行軌道を決定する。
【００８０】
（ii）ステップ１３０２
判断機能部１１０２は、ステップ１３０１で決定した走行軌道を、ネットワークバス１３を介してＥＣＵ−Ａ１１の外部（例えば、ＥＣＵ−Ｂ１２や各ＥＣＵを制御する制御装置）に送信する。
【００８１】
＜共通初期化処理＞
図１４は、共通初期化部１１０３による共通初期化処理を説明するためのフローチャートである。ここでは、共通初期化部１１０３を動作主体としているが、共通初期化部１１０３はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【００８２】
（i）ステップ１４０１
共通初期化部１１０３は、走行計画部１１０１と判断機能部１１０２の初期化を実施する。
【００８３】
（ii）ステップ１４０２
共通初期化部１１０３は、パーティションを有効にする。つまり、メモリ保護（空間的分離：図１１）と時分割スケジューリングのデッドライン判定（時間的分離：図９）を有効にする。
【００８４】
なお、時分割スケジューリングは、ＣＰＵがシングルコアの場合に行われるが、ＣＰＵがマルチコアの場合には、例えば共通機能グループのプログラムと個別機能グループのプログラムを異なるコアに割り当てることにより時間分離が実現されることになる。
【００８５】
（iii）ステップ１４０３
共通初期化部１１０３は、現在の状況に応じた機能の実行許可イベントを発行する。
【００８６】
（iv）ステップ１４０４
共通初期化部１１０３は、時分割スケジューリングを開始する。具体的には、時分割制御部１１１０を実行するためにタイマをセットする。
【００８７】
＜周辺認識処理１＞
図１５は、周辺認識１部１１０４による周辺認識処理を説明するためのフローチャートである。ここでは、周辺認識１部１１０４を動作主体としているが、周辺認識１部１１０４はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【００８８】
（i）ステップ１５０１
周辺認識１部１１０４は、状況Ａ固有初期化部１１０５に対して、状況Ａ固有初期化処理を実行するように命令する。なお、ステップ１５０１の詳細は後述する（図１６参照）。
【００８９】
（ii）ステップ１５０２
状況Ａ固有初期化処理が完了すると、周辺認識１部１１０４は、状況Ａに適したアルゴリズムを用いて、受信した画像とポイントクラウドを解析し、周囲の状況を認識する。
【００９０】
（iii）ステップ１５０３
周辺認識１部１１０４は、認識結果を周辺情報としてメモリ（図示せず）に保存する。
【００９１】
＜状況Ａ固有初期化処理＞
図１６は、状況Ａ固有初期化部１１０５による状況Ａ固有初期化処理を説明するためのフローチャートである。ここでは、状況Ａ固有初期化部１１０５を動作主体としているが、状況Ａ固有初期化部１１０５はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。なお、本実施形態では、初期化処理には２種類ある。１つはエンジンを掛けたとき（ステップ１５０１６）、もう１つは走行中に状況が変化したとき（状況Ａから状況ＡｔｏＢになったとき）である。
【００９２】
（i）ステップ１５０１１
状況Ａ固有初期化部１１０５は、パーティションが有効中であるか、即ち空間分離（メモリ保護）および時間分離（時分割スケジューリング）が有効であるか判定する。パーティションが有効中（時分割スケジューリング中（走行中））である場合（ステップ１５０１１でＹｅｓの場合）、処理はステップ１５０１２に移行する。パーティションが有効中でない場合（例えば、エンジンを掛けたとき：ステップ１５０１１でＮｏの場合）、処理はステップ１５０１６に移行する。
【００９３】
（ii）ステップ１５０１２
状況Ａ固有初期化部１１０５は、状況Ａで実行される機能グループのデッドライン監視をＯＦＦに設定する。つまり、初期化処理時には、デッドラインタスクは実行されない。
【００９４】
（iii）ステップ１５０１３
状況Ａ固有初期化部１１０５は、周辺認識１部１１０４の初期化を実施する。
【００９５】
（iv）ステップ１５０１４
状況Ａ固有初期化部１１０５は、実行許可イベントを待つ。待っている間、時分割スケジューリングが実行されている場合は、ディスパッチが発生する。
【００９６】
（v）ステップ１５０１５
状況Ａ固有初期化部１１０５は、状況Ａで実行される機能グループのデッドライン監視をＯＮ（デッドライン判定を有効）にする。
【００９７】
（vi）ステップ１５０１６
状況Ａ固有初期化部１１０５は、周辺認識１部１１０４の初期化を実施する。
【００９８】
＜周辺認識処理２＞
図１７は、周辺認識２部１１０６による周辺認識処理を説明するためのフローチャートである。ここでは、周辺認識２部１１０６を動作主体としているが、周辺認識２部１１０６はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【００９９】
（i）ステップ１７０１
周辺認識２部１１０６は、状況Ｂ固有初期化部１１０７に対して、状況Ｂ固有初期化処理を実行するように命令する。なお、ステップ１７０１の詳細は後述する（図１８参照）。
【０１００】
（ii）ステップ１７０２
状況Ｂ固有初期化処理が完了すると、周辺認識２部１１０４は、状況Ｂに適したアルゴリズムを用いて、受信した画像とポイントクラウドを解析し、周囲の状況を認識する。
【０１０１】
（iii）ステップ１７０３
周辺認識２部１１０６は、認識結果を周辺情報としてメモリ（図示せず）に保存する。
【０１０２】
＜状況Ｂ固有初期化処理＞
図１８は、状況Ｂ固有初期化部１１０７による状況Ｂ固有初期化処理を説明するためのフローチャートである。ここでは、状況Ｂ固有初期化部１１０７を動作主体としているが、状況Ｂ固有初期化部１１０７はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。なお、本実施形態では、初期化処理には２種類ある。１つはエンジンを掛けたとき（ステップ１７０１６）、もう１つは走行中に状況が変化したとき（状況Ｂから状況ＡｔｏＢになったとき）である。
【０１０３】
（i）ステップ１７０１１
状況Ｂ固有初期化部１１０７は、パーティションが有効中であるか、即ち空間分離（メモリ保護）および時間分離（時分割スケジューリング）が有効であるか判定する。パーティションが有効中（時分割スケジューリング中（走行中））である場合（ステップ１５０１１でＹｅｓの場合）、処理はステップ１７０１２に移行する。パーティションが有効中でない場合（例えば、エンジンを掛けたとき：ステップ１７０１１でＮｏの場合）、処理はステップ１７０１６に移行する。
【０１０４】
（ii）ステップ１７０１２
状況Ｂ固有初期化部１１０７は、状況Ｂで実行される機能グループのデッドライン監視をＯＦＦに設定する。つまり、初期化処理時には、デッドラインタスクは実行されない。
【０１０５】
（iii）ステップ１７０１３
状況Ｂ固有初期化部１１０７は、周辺認識２部１１０６の初期化を実施する。
【０１０６】
（iv）ステップ１７０１４
状況Ｂ固有初期化部１１０７は、実行許可イベントを待つ。待っている間、時分割スケジューリングが実行されている場合は、ディスパッチが発生する。
【０１０７】
（v）ステップ１７０１５
状況Ｂ固有初期化部１１０７は、状況Ｂで実行される機能グループのデッドライン監視をＯＮ（デッドライン判定を有効）にする。
【０１０８】
（vi）ステップ１７０１６
状況Ｂ固有初期化部１１０７は、周辺認識２部１１０６の初期化を実施する。
【０１０９】
＜モード変更処理＞
図１９は、モード変更部１１０８によるモード変更処理を説明するためのフローチャートである。ここでは、モード変更部１１０８を動作主体としているが、モード変更部１１０８はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【０１１０】
（i）ステップ１９０１
モード変更部１１０８は、更新準備要求が受信しているかを判定する。ＥＣＵＡ−１１が外部（例えば、ＥＣＵＢ−１２や図示しない各ＥＣＵを全体制御する制御装置）から受信するのは更新準備要求あるいは更新実施要求である。
【０１１１】
更新準備要求を受信した場合（ステップ１９０１でＹｅｓの場合）、処理はステップ１９０２に移行する。更新準備要求を受信しなかった場合（ステップ１９０１でＮｏの場合：更新実施要求を受信した場合、あるいは何の要求も受信しなかった場合）、処理はステップ１９０５に移行する。
【０１１２】
（ii）ステップ１９０２
モード変更部１１０８は、プログラムと設計情報を外部から受信する。本実施形態では、受信対象をプログラムとしているが、これに限らない。例えば、パラメータのみを受信し、プログラムがパラメータを変更するだけで状況変化に追従できる構成であってもよい。
【０１１３】
（iii）ステップ１９０３
モード変更部１１０８は、パーティション更新部１１０９を呼び出してパーティションを変更する。ステップ１９０３の詳細については後述する（図２０参照）。
【０１１４】
（iv）ステップ１９０４
モード変更部１１０８は、更新機能グループを起動する。本実施形態では状況Ａから状況Ｂに移行する例が示されているため、状況Ｂ向け機能グループが起動されることになる。
【０１１５】
（v）ステップ１９０５
モード変更部１１０８は、更新実施要求を受信しているかを判定する。更新実施要求を受信した場合（ステップ１９０５でＹｅｓの場合）、処理はステップ１９０６に移行する。更新実施要求を受信しなかった場合（ステップ１９０５でＮｏの場合：何の要求も受信しなかった場合）、モード変更処理は終了する。
【０１１６】
（vi）ステップ１９０６
モード変更部１１０８は、実行許可イベントを発行する。
【０１１７】
＜パーティション更新処理＞
図２０は、パーティション更新部１１０９によるパーティション更新処理（ステップ１９０３の詳細）を説明するためのフローチャートである。ここでは、パーティション更新部１１０９を動作主体としているが、パーティション更新部１１０９はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【０１１８】
（i）ステップ１９０３１
パーティション更新部１１０９は、受信したプログラムを空きメモリ領域に保存し、メモリ保護を実施する。具体的には、図１１における状況ＡｔｏＢのときの処理である。
【０１１９】
（ii）ステップ１９０３２
パーティション更新部１１０９はメモリ保護を実施できたかを判定する。メモリ保護ができた場合（ステップ１９０３２でＹｅｓの場合）、処理はステップ１９０３３に移行する。メモリ保護ができなかった場合（ステップ１９０３２でＮｏの場合）、処理はステップ１９０３６に移行する。
【０１２０】
（iii）ステップ１９０３３
パーティション更新部１１０９は、外部から送信されてきた設計情報（なお、ＥＣＵ−Ａ１１内部に保持している設計情報でもよい）に基づいて、空きスロットの範囲内でスロットを設計する。例えば、空きスロットの時間から対象とするタスクの実行時間を引き、正の数である場合にはタスクの実行時間をスロットの時間とする。ただし、この方法に限定されるものではない。
【０１２１】
（iv）ステップ１９０３４
パーティション更新部１１０９は、スロット設計を実施できたか判定する。スロット設計が実施できた場合（ステップ１９０３４でＹｅｓの場合）、処理はステップ１９０３５に移行する。スロット設計が実施できなかった場合（ステップ１９０３４でＮｏの場合）、処理はステップ１９０３６に移行する。
【０１２２】
（v）ステップ１９０３５
パーティション更新部１１０９は、動的機能更新準備環境を示すイベントをネットワークバス１３に送信する。例えば、ＥＣＵ−Ｂ１２や外部のサーバ（図示せず）が当該イベントを受信し、状況Ｂ走行モードの更新実施要求をＥＣＵ−Ａ１１に送信する。
【０１２３】
（vi）ステップ１９０３６
パーティション更新部１１０９は、動的機能更新エラーを示すイベントをネットワークバス１３に送信する。この場合、ユーザへの注意喚起のため、動的機能更新がエラーとなったことが表示部の画面上に表示されるようにしてもよい。
【０１２４】
＜時分割制御処理＞
図２１は、時分割制御部１１１０による時分割制御処理を説明するためのフローチャートである。ここでは、時分割制御部１１１０を動作主体としているが、時分割制御部１１１０はプログラムで実現されるので、ＥＣＵＡ−１１を動作主体としてもよい。
【０１２５】
（i）ステップ２１０１
時分割制御部１１１０は、現スロットの前のスロット（スロットＩＤが１つ前のスロット）の処理が終了しているか判断する。前のスロットの処理が終了している場合（ステップ２１０１でＹｅｓの場合：当該スロットについて最初の実行の場合）、処理はステップ２１０６に移行する。前のスロットの処理が終了していない場合（ステップ２１０１でＮｏの場合）、処理はステップ２１０２に移行する。
【０１２６】
（ii）ステップ２１０２
時分割制御部１１１０は、対象タスクのデッドライン判定が有効であるか（デッドライン監視がＯＮか）を判定する。デッドライン判定が有効である場合（ステップ２１０２でＹｅｓの場合）、処理はステップ２１０３に移行する。デッドライン判定が無効である場合（ステップ２１０２でＮｏの場合）、処理はステップ２１０４に移行する。
【０１２７】
（iii）ステップ２１０３
時分割制御部１１１０は、前スロットにおける未終了の処理を強制停止させる。スロットの終端に来たにも拘らず処理が終了していないときには、そのままその未了の処理を実行し続けると次の処理のために使うＣＰＵ（プロセッサ）を使ってしまう。また、この段階ではパーティショニングがされていないため、未終了の処理を強制終了させる。例えば、状況ＡｔｏＢになったとき、最初は初期化処理が実行されるが、初期化処理は、図６に示されるように、通常の処理も処理時間が長くなることが多い。このため、初期化処理が実行周期（例えば、５０ｍｓ）の間に終了しないことがある。この未終了という事象は処理が異常であったから発生したわけではないため、未終了の処理は強制停止されることになる。
【０１２８】
（iv）ステップ２１０４
時分割制御部１１１０は、前スロットにおける未終了の処理を異常停止させる（例えば、デッドラインオーバしてしまったため、異常と判断し処理を停止させる）。
【０１２９】
（v）ステップ２１０５
時分割制御部１１１０は、デッドラインミスを通知するイベントをネットワークバス１３に送信する。これにより、例えば、他のＥＣＵ（ＥＣＵ−Ｂ１２）や各ＥＣＵの全体制御を実行する制御装置は、異常停止のタスクを認識することができる。
【０１３０】
（vi）ステップ２１０６
時分割制御部１１１０は、スロット設計表に基づいて次のスロットで実行する特定のタスクを指定スケジューリングで起動する。前回強制停止の場合には、時分割制御部１１１０は、強制終了したタスクを再開する。ただし、前回異常停止の場合にはタスクを再度起動しない。
【０１３１】
（vii）ステップ２１０７
時分割制御部１１１０は、次のスロットの終了時間に時分割制御部１１１０を起動するタイマをセットする。
【０１３２】
＜画面表示処理＞
図２２は、ＥＣＵ−Ｂ１２の画面表示部１２０１より画面表示処理を説明するためのフローチャートである。ここでは、画面表示部１２０１を動作主体としているが、画面表示部１２０１はプログラムで実現されるので、ＥＣＵ−Ｂ１２を動作主体としてもよい。
【０１３３】
（i）ステップ２２０１
画面表示部１２０１は、ＥＣＵ−Ａ１１の時分割制御部１１１０から受信したデッドラインミスイベントに基づいて画面にエラーを表示する。
【０１３４】
（ii）ステップ２２０２
画面表示部１２０１は、ＥＣＵ−Ａ１１のパーティション更新部１１０９から受信した動的機能更新エラーイベントに基づいて画面にエラーを表示する。
【０１３５】
本実施形態ではエラー時に画面表示を行っているが、これに限らない。システムを安全に停止するようなフェールセーフを行ってもよい。また、図示しないサーバにこれを通知し、再度実行してもよいが、これに限られるわけではない。
【０１３６】
＜更新準備指示処理＞
図２３は、ＥＣＵ−Ｂ１２の更新準備指示部１２０２による更新準備指示処理を説明するためのフローチャートである。ここでは、更新準備指示部１２０２を動作主体としているが、更新準備指示部１２０２はプログラムで実現されるので、ＥＣＵ−Ｂ１２を動作主体としてもよい。
【０１３７】
（i）ステップ２３０１
更新準備指示部１２０２は、状況が遷移状態（境界）にあるとき（例えば、状況ＡｔｏＢのとき、あるいは状況ＢｔｏＡのとき）に、更新準備要求をネットワークバス１３に送信する。
【０１３８】
（ii）ステップ２３０２
更新準備指示部１２０２は、ネットワークバス１３を介して更新プログラムと設計情報をＥＣＵ−Ａ１１に送信し、ＥＣＵ−Ａ１１がそれらを利用できるようにする。
【０１３９】
＜更新実施指示処理＞
図２４は、ＥＣＵ−Ｂ１２の更新実施指示部１２０３による更新実施指示処理を説明するためのフローチャートである。ここでは、更新実施指示部１２０３を動作主体としているが、更新実施指示部１２０３はプログラムで実現されるので、ＥＣＵ−Ｂ１２を動作主体としてもよい。
【０１４０】
（i）ステップ２４０１
更新実施指示部１２０３は、動的機能更新準備の完了イベントを受信したかを判定する。動的機能更新準備の完了イベントを受信している場合（ステップ２４０１でＹｅｓの場合）、処理はステップ２４０２に移行する。動的機能更新準備の完了イベントを受信していない場合（ステップ２４０１でＮｏの場合）、更新実施指示処理は終了する。
【０１４１】
（ii）ステップ２４０２
更新実施指示部１２０３は、状況が切り替わったとき（例えば、状況ＡｔｏＢから状況Ｂに切り替わったとき、あるいは状況ＢｔｏＡから状況Ａに切り替わったとき）に、ネットワークバス１３を介して更新実施要求をＥＣＵ−Ａ１１に送信する。
【０１４２】
＜第１の実施形態のまとめ＞
第１の本実施形態によれば、機能グループ単位で更新が可能となるため、ハードウェアリソースを節約できる。また、状況に応じて適した機能グループを選択し、車両走行が可能となるため、安全で快適な走行が可能となる。
【０１４３】
（２）第２の実施形態
＜更新機能グループのタスク情報とタスク構成＞
図２５は、第２の実施形態の、状況ＡｔｏＢ０２における更新機能グループのタスク情報２１１２と状況Ｂ０３におけるタスク情報２１１４の例を示す図である。構成項目は第１の実施形態と同様である。なお、図２５では、状況Ａのタスク情報は第１の実施形態と同じであるため、省略されている（図５参照）。
【０１４４】
（i）状況ＡｔｏＢ０２において、タスク情報２１１２のタスク名２１１２１は、実行する機能のタスクの名称を示している。例えば、周辺認識２タスクは周辺認識２部１１０６を実行する。
タスクＩＤ２１１２２は、タスクを識別可能なＩＤを示す。実行周期２１１２３はタスクを起動する周期を示す。単位はミリ秒である。
【０１４５】
タスク優先度２１１２４は、タスクの優先度を示す。ただし、スケジューリングがＥＤＦ（Earliest Deadline First）の場合には、タスク優先度は設定されない（表には数値は入力されない）。通常の実行時間２１１２５は、初期化処理終了後の通常タスクの実行時間を示す。初期化実行時間２１１２６は、初期化処理の実行時間を示す。
【０１４６】
機能グループ２１１２７は、タスクが所属する機能グループを示す。状況Ｂ向け機能グループは状況Ｂで実行される機能グループを意味する。スケジューリング２１１１８は、タスクが実行されるスケジューリングポリシーを示す。
第２の実施形態では、第１の実施形態と比べて、初期化実行時間２１１２６が短く設定されている。
【０１４７】
（ii）状況Ｂ０３において、第２の実施形態に係る更新後（状況Ｂ０３）のタスク構成２１１４におけるタスク名２１１４１は、実行する機能をタスクの名称を示している。例えば、走行計画タスクは走行計画部１１０１を、判断機能タスクは判断機能部１１０２を、周辺認識２タスクは周辺認識２部１１０６を、モード変更タスクはモード変更部１１０８を、それぞれ実行する。
【０１４８】
タスクＩＤ２１１４２は、タスクを識別可能なＩＤを示す。実行周期２１１４３は、タスクを起動する周期を示す。単位はミリ秒である。タスク優先度２１１４４は、タスクの優先度を示す。
【０１４９】
通常の実行時間２１１４５は、初期化終了後の通常タスクの実行時間を示す。初期化実行時間２１１４６は、初期化処理の実行時間を示す。第２の実施形態では通常実行時間と初期化実行時間を、最長の実行時間を設定することを想定しているが、これに限らない。例えば、最長の実行時間にマージンを加えたものであってもよい。ただし、これに限られるわけではない。
【０１５０】
機能グループ２１１４７は、タスクが所属する機能グループを示す。スケジューリング２１１４８は、タスクが実行されるスケジューリングポリシーを示す。
【０１５１】
＜スロット設計＞
図２６は、第２の実施形態によるスロット設計の例を示す図である。構成項目は第１の実施形態と同様である。以下、各状況に対応したスロット設計について説明する。
【０１５２】
（i）状況Ａ０１において、スロット設計表２１１５のスロットＩＤ２１１５１は、スロットを識別可能なＩＤを示す。開始時間２１１５２は、スロットと定めた時間の開始時刻を示す。終了時刻２１１５３は、スロットと定めた時刻の終了時刻を示す。実行対象２１１５４は、該当のスロットで実行許可されている機能グループを示す。
【０１５３】
（ii）状況ＡｔｏＢ０２において、スロット設計表２１１６のスロットＩＤ２１１６１は、スロットを識別可能なＩＤを示す。開始時間２１１６２は、スロットと定めた時間の開始時刻を示す。終了時刻２１１６３は、スロットと定めた時刻の終了時刻を示す。実行対象２１１６４は、該当のスロットで実行許可されている機能グループを示す。
【０１５４】
（iii）状況Ｂ０３において、スロット設計表２１１７のスロットＩＤ２１１７１は、スロットを識別可能なＩＤを示す。開始時間２１１７２はスロットと定めた時間の開始時刻を示す。終了時刻２１１７３はスロットと定めた時刻の終了時刻を示す。実行対象２１１７４は該当のスロットで実行許可されている機能グループを示す。実施の形態２は実施の形態１の差は、状況ＡｔｏＢ０２において状態Ｂ向け機能グループが実行されていない点である。
【０１５５】
＜タスクスケジューリング＞
図２７は、第２の実施形態によるタスクスケジューリングの例を示す図である。以下、各状況に対応したタスクスケジューリングについて説明する。
【０１５６】
（i）状況Ａ走行モード００２１では、ＩＤ＝１のスロットにおいて、ＩＤ＝１および２のタスクが実行される。また、ＩＤ＝２のスロットにおいて、ＩＤ＝３のタスクが実行される。さらに、ＩＤ＝３のスロットにおいて、ＩＤ＝５のタスクが実行される。システム周期２１１５０は５０ｍｓに設定されている。
【０１５７】
（ii）状況ＡｔｏＢ機能更新モード００２２では、ＩＤ＝１のスロットにおいて、ＩＤ＝１および２のタスクが実行される。また、ＩＤ＝２のスロットにおいて、ＩＤ＝３のタスクが実行される。さらに、ＩＤ＝３のスロットにおいて、ＩＤ＝５のタスクが実行される。この場合も、システム周期１１１６５は５０ｍｓに設定されている。
【０１５８】
（iii）状況Ｂ走行モード００２３では、ＩＤ＝１のスロットにおいて、ＩＤ＝１および２のタスクが実行される。また、ＩＤ＝２のスロットにおいて、ＩＤ＝４のタスクが実行される。この場合も、システム周期１１１７５は５０ｍｓｎ設定されている。
【０１５９】
＜第２の実施形態のまとめ＞
第２の実施形態によれば、異なる状況における同じスロットの時間において、異なる機能グループを動作させることが可能となる、したがって、ハードウェアリソースを節約できる。また、初期化処理の時間が短い際にはデッドラインを有効のまま、機能更新が可能になり、煩雑な設計を回避可能となる。
【０１６０】
（３）変形例
第１および第２の実施形態によると、シングルコアにおいてタイムパーティションを実現するために時分割スケジューリングを使用したが、これに限らない。例えば、マルチコアシステムにおいて、継続する機能グループと更新する機能グループを異なるコアで実行させることで、タイムパーティショニングを実現してもよい。この場合、第１および第２の実施形態と同様にメモリ保護は必要となり、モード変更部１１０８は継続する機能グループと同様のコアで実行され、他のコアの機能グループを更新することとなる。
【０１６１】
（４）総括
（i）本実施形態によれば、車両制御システムの制御コントローラ（ＥＣＵ−Ａ）は、複数の機能を予め決められた機能グループの単位で管理し、実行する。当該制御コントローラ（ＥＣＵ−Ａ）は、動的に機能グループ単位を変更し（パーティション更新部）、制御コントローラの外部（別のＥＣＵ（ＥＣＵ−Ｂ）や図示しないサーバ）から、システムの稼働環境の変化に応じて機能グループの変更を指示する機能グループ変更実施要求を受信し、当該機能グループ変更実施要求に応答して、パーティション更新（変更）された機能グループの実行を許可する（モード変更部）ように構成されている。これにより、状況変化を検知した外部のＥＣＵやサーバからの指令にと応答してシステムの機能を変更することができ、システムの可用性と安全性を担保することができる。
【０１６２】
また、制御コントローラ（ＥＣＵ−Ａのモード変更部）は、機能グループ変更実施要求を受信する前に、外部（別のＥＣＵ（ＥＣＵ−Ｂ）、図示しない車両制御システム内の全体制御装置やサーバ）から、機能グループの変更の準備を要求する機能グループ変更準備要求を受信し、当該機能グループ変更準備要求に応答して、外部（別のＥＣＵ（ＥＣＵ−Ｂ）、図示しない車両制御システム内の全体制御装置やサーバ）から変更すべき事項が記述された変更情報を取得し、当該変更情報に基づいて、機能グループのパーティションの変更を実行する（機能グループのパーティショニングの再設定）。このように、状況が変化してから機能グループの構成を変更するのではなく、状況変化が起こりつつある状態で機能グループの構成の変更を開始するので、実際に状況が変化した段階では即座に変化した状況に対応したシステムの機能に遷移することが可能となる。
【０１６３】
（ii）本実施形態では、ＥＣＵ−Ａにおいて、空間分離および時間分離に基づいて、複数の機能のパーティショニングが実行される。具体的には、ＥＣＵ−Ａは、例えば、空間分離として機能グループ単位に使用するメモリ空間を別にし、時間分離として、機能グループ単位に実行する時間を別にするように構成されている。このように空間分離および時間分離によってパーティショニングを実行することにより、スロット設計の自由度を高くすることができ、ハードウェアリソースを有効に活用することができるようになる。
【０１６４】
さらに、具体的には、機能グループは、少なくとも、複数の状況において共通に実行される機能である共通機能グループと状況に応じて実行される機能が異なる個別機能グループとを含む。そして、空間分離において、共通機能グループのメモリアドレス空間と個別機能グループのメモリアドレス空間が区別されており、共通機能グループと個別機能グループとの間のメモリ領域は共有メモリ空間を介して構成される。共通機能グループは、車両制御システムの安全性を保証する処理を実行する機能であり、個別機能グループは、車両制御システムの可用性を向上させる処理を実行する機能である。
【０１６５】
時間分離の実現に関しては、制御コントローラにおけるプロセッサ構成をシングルコアやマルチコアとすることができる。前者の場合、時分割スケジューリングによってタイムパーティションジングが実現される。この場合、制御コントローラは、機能グループ毎にスロット（各機能に相当するタスクを実行するためのタイムスロット）を割り当てる（時分割制御部）。一方、後者の場合、共通機能グループと個別機能グループとを異なるコアプロセッサで実行し、時間分離を実現する。
【０１６６】
（iii）時間分離でパーティショニングされる場合、制御コントローラ（ＥＣＵ−Ａ）は、更新対象である個別機能グループに含まれるタスクを更新している間に、更新対象以外の共通機能グループに含まれるタスクの処理を継続的に実行する。このようにすることにより、他のプログラムの動作に影響を与えず、状況変化に伴うシステム更新（変更）を実現することができるようになる。
【０１６７】
（iv）時分割制御の場合、制御コントローラ（ＥＣＵ−Ａ：モード変更部）は、時分割制御によって機能グループに割り当てられているスロット以外のスロットで、パーティションを更新（パーティション更新部）した後に、更新機能グループを起動する。確実にスロットを割り当てた後に更新された機能を実行するので、システムの安全性を担保することができる。
【０１６８】
（v）空間分離の場合、個別機能グループに対しては、実行、書き込み、および読み出しが可能となるようにメモリ空間が割り当てられ、共通機能グループやシステムグループに対しては、個別機能グループに割り当てられたメモリ空間からの読み出しが可能となるようにメモリ空間が設定される。このようにメモリ空間を設定することにより、メモリを保護することができ、システム稼働の安定性を実現することができる。
【０１６９】
なお、機能グループ単位でのメモリ空間の割り当てとスロットの割り当てに失敗した場合に、制御コントローラ（ＥＣＵ−Ａ）は、動的機能更新エラーを示すイベントを生成し、ネットワークへ出力する。これにより、状況変化に伴うパーティショニング更新が正常に終了したかを監視することができるようになる。
【０１７０】
（vi）時分割制御を実行する際に、機能グループに含まれるタスクについてデッドライン判定が有効であり、かつスロットの終了時に当該スロットに割り当てられたタスクが未終了の場合、制御コントローラ（ＥＣＵ−Ａ：時分割制御部）は、当該未終了のタスクを異常停止させ、デッドラインミスイベントを生成し、出力する。これにより、タスク処理が完了していない場合でも異常によって完了していないのか、あるいは単なる遅延で完了していないのか判断することができ、処理遅延に対して適切に対処することができる。
【０１７１】
（vii）本実施形態は、ソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本開示を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【０１７２】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【０１７３】
さらに、実施形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【０１７４】
最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本開示は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本開示を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。
【０１７５】
さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。
【０１７６】
加えて、本技術分野の通常の知識を有する者には、本開示のその他の実装がここに開示された本開示の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本開示の範囲と精神は後続する請求の範囲で示される。
【符号の説明】
【０１７７】
０１  状況Ａ
０２  状況ＡｔｏＢ
０３  状況Ｂ
１１  ＥＣＵ−Ａ
１２  ＥＣＵ−Ｂ
１１０１  走行計画部
１１０２  判断機能部
１１０３  共通初期化部
１１０４  周辺認識１部
１１０５  状況Ａ固有初期化部
１１０６  周辺認識２部
１１０７  状況Ｂ固有初期化部
１１０８  モード変更部
１１０９  パーティション更新部
１１１０  時分割制御部
１２０１  画面表示部
１２０２  更新準備指示部
１２０３  更新実施指示部
【図１】
0006975854.tif 000002
【図２】
0006975854.tif 000003
【図３】
0006975854.tif 000004
【図４】
0006975854.tif 000005
【図５】
0006975854.tif 000006
【図６】
0006975854.tif 000007
【図７】
0006975854.tif 000008
【図８】
0006975854.tif 000009
【図９】
0006975854.tif 000010
【図１０】
0006975854.tif 000011
【図１１】
0006975854.tif 000012
【図１２】
0006975854.tif 000013
【図１３】
0006975854.tif 000014
【図１４】
0006975854.tif 000015
【図１５】
0006975854.tif 000016
【図１６】
0006975854.tif 000017
【図１７】
0006975854.tif 000018
【図１８】
0006975854.tif 000019
【図１９】
0006975854.tif 000020
【図２０】
0006975854.tif 000021
【図２１】
0006975854.tif 000022
【図２２】
0006975854.tif 000023
【図２３】
0006975854.tif 000024
【図２４】
0006975854.tif 000025
【図２５】
0006975854.tif 000026
【図２６】
0006975854.tif 000027
【図２７】
0006975854.tif 000028