JP2023161698A - 電子制御装置 - Google Patents

Abstract

【課題】ソフトウェアプログラムの開発コストの削減可能な電子制御装置を提供する。【解決手段】電子制御装置１００は、アプリケーション処理を行うアプリケーション処理部２２を有する演算処理部１Ａ，１Ｂと、演算処理部１Ａ，１Ｂで処理されるデータを保存するデータ保存部２Ａと、データ保存部２Ａから読み出したデータを他の電子制御装置に送信し、又は他の電子制御装置からデータを受信するペリフェラル３と、を備える。演算処理部１Ａ，１Ｂがアプリケーション処理のためにデータ保存部２Ａにデータを入出力する第１タイミングと、演算処理部１Ａ，１Ｂがデータ保存部２Ａから読み出したデータをペリフェラル３に渡して、ペリフェラル３が他の電子制御装置にデータを送信する第２タイミングとが予め固定される。【選択図】図２

Description

本発明は、電子制御装置に関する。

車両に複数の電子制御装置（ＥＣＵ：Electronic Control Unit）が搭載されるようになり、電子制御装置の開発コストを低減することが求められている。そこで、電子制御装置の開発コストを低減するため特許文献１及び２に記載された技術が知られている。特許文献１には、「ドライバは、複数のアプリケーションプログラムに対応した複数のインターフェース部と、複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、複数のアプリケーションプログラム間の通信は、ドライバの制御下で行われる」と記載されている。

また、特許文献２には、「外部機器と接続する外部バスから通信フレームに載せて送られてくるデータを受信データとし、その受信データが少なくとも格納されるメッセージボックスと、当該電子制御装置の内部バスを介して転送されてくる受信データの書込み及び読出しが可能な複数の格納領域を有する内部メモリとを備える。」と記載されている。

特開２０１３－０６２７３４号公報 特開２０１１－２５０１１０号公報

特許文献１に開示された技術では、複数のアプリケーションプログラムを搭載した電子制御装置に関して、ドライバの構成要素としてアプリケーションプログラムの各々が使用するバッファが設置される。このバッファにより、ペリフェラル（例えばＣＡＮ（Controller Area Network）コントローラやＣＡＮトランシーバ）を複数個用意しなくても、各アプリケーションプログラムが１個のペリフェラルを共有する構成としている。

しかしながら、複数のアプリケーションプログラムがペリフェラルを共有する場合と、ペリフェラルを共有しない場合とを比較すると、各アプリケーションプログラムがデータを生成してから該データがペリフェラルに到達するまでのタイミングが異なっている。このため、複数のアプリケーションプログラムがペリフェラルを共有する場合と、共有しない場合で電子制御装置の振る舞い（例えばＣＡＮメッセージの送信タイミング及び送信の順序）が変化する。この結果、変化した電子制御装置の動作の検証、及びデータの入出力タイミングの再設計にコストを要していた。

特許文献２に開示された技術では、ＣＰＵ（Central Processing Unit）が制御対象機器を制御するための処理を行う状況において、通信処理の一部をＤＭＡ（Direct Memory Access）コントローラが代替する構成としたものである。しかしながら、一般にＣＰＵとＤＭＡコントローラでは処理速度が異なる。このため、従来、ＣＰＵで実行していた処理をＤＭＡコントローラに代替すると、代替の前後でアプリケーション処理及び通信処理を含むＣＰＵのスケジューリングが変化する。この結果、特許文献２に開示された技術では、特許文献１に開示された技術と同様に、電子制御装置の動作の検証、及びデータのタイミングの再設計にコストを要していた。

本発明はこのような状況に鑑みて成されたものであり、ソフトウェアプログラムの開発コストの削減を目的とする。

本発明に係る電子制御装置は、アプリケーション処理を行うアプリケーション処理部を有する演算処理部と、演算処理部で処理されるデータを保存するデータ保存部と、データ保存部から読み出したデータを他の電子制御装置に送信し、又は他の電子制御装置からデータを受信するペリフェラルと、を備え、演算処理部がアプリケーション処理のためにデータ保存部にデータを入出力する第１タイミングと、演算処理部がデータ保存部から読み出したデータをペリフェラルに渡して、ペリフェラルが他の電子制御装置にデータを送信する第２タイミングとが予め固定される。

本発明によれば、第１及び第２タイミングが予め固定されるので、ソフトウェアプログラムの開発コストを削減することが可能となる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の第１の実施形態に係る電子制御装置の概略構成例を示す図である。 本発明の第１の実施形態に係る電子制御装置の各部の内部構成例を示すブロック図である。 本発明の第１の実施形態に係る電子制御装置を搭載した車両制御装置の内部構成例を示すブロック図である。 本発明の第１の実施形態に係るカメラ物体検知データの構成例を示した図である。 第一の電子制御装置（カメラＥＣＵ）と第二の電子制御装置（自動運転ＥＣＵ）の時刻同期の必要性を示した図である。 時刻同期された電子制御装置間におけるデータフローの変化の例を示す図である。 非特許文献１にて提案されたＬＥＴ及びＬＣＴの概要を示した図である。 第一の電子制御装置（カメラＥＣＵ）に従来のソフトウェアアーキテクチャを適用した例を示す図である。 第二の電子制御装置（自動運転ＥＣＵ）における従来のソフトウェアアーキテクチャを適用した例を示す図である。 非特許文献１にて提案されたＬＥＴ及びＬＣＴを、図８及び図９に示したモジュール及びタスクにマッピングした例を示す図である。 第一の電子制御装置（カメラＥＣＵ）において大量のデータ送信を行う場合における通信ミドルウェアと車載ネットワークのタイミングチャートである。 本発明の第１の実施形態に係る通信準備処理部とペリフェラルアクセス部の処理の概要について、ＡＵＴＯＳＡＲを例として説明する図である。 第一の電子制御装置（カメラＥＣＵ）における本実施形態に係るソフトウェアアーキテクチャを示した図である。 第二の電子制御装置（自動運転ＥＣＵ）における本実施形態に係るソフトウェアアーキテクチャを示した図である。 本発明の第１の実施形態に係るＬＥＴ及びＬＣＴを、本実施形態に係る各モジュール及びタスクに適用した例を示す図である。 本発明の第１の実施形態に係る技術と、非特許文献１に開示された技術とを比較したタイミングチャートである。 本発明の第２の実施形態に係る第一の電子制御装置（カメラＥＣＵ）におけるソフトウェアアーキテクチャを示した図である。 本発明の第２の実施形態に係る第二の電子制御装置（自動運転ＥＣＵ）におけるソフトウェアアーキテクチャを示した図である。 本発明の第２の実施形態に係るＬＥＴ及びＬＣＴを、本実施形態に係る各モジュール及びタスクにマッピングした例を示す図である。 本発明の第３の実施形態に係る第三の電子制御装置（セントラルＥＣＵ）を搭載した車両制御装置の構成例を示した図である。 本発明の第３の実施形態に係る第三の電子制御装置（セントラルＥＣＵ）におけるソフトウェアアーキテクチャを示した図である。

以下、本発明を実施するための形態について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。

［第１の実施形態］
以下に説明する、本発明の第１の実施形態は、電子制御装置及び車両制御装置に本発明を適用したものであって、特に、ネットワークに接続され、車両内外の他の電子制御装置（ＥＣＵ）との間で通信を行うものに関する。第１の実施形態においては、カメラから取得した画像データを用いて、ステアリング、アクセル及びブレーキを制御する自動運転車両に搭載される車両制御装置を例に挙げて、電子制御装置及び車両制御装置の構成例及び動作例を説明する。ただし、自動運転車両に限らず、自動運転を行わない車両にも本発明を適用可能である。また、ネットワークに接続され、車両内外の他の電子制御装置（ＥＣＵ）との間で通信を行うように構成されたリアルタイムシステムに対しても本発明を適用可能である。例えば、ロボット、建設機械、自律フォークリフト等のＣＰＵがマルチコアで構成され、リアルタイムでソフトウェアプログラムが稼働する製品に第１の実施形態に係る電子制御装置及び車両制御装置を適用可能である。

＜電子制御装置の構成例＞
図１は、第１の実施形態に係る電子制御装置の概略構成例を示す図である。
電子制御装置１００は、ＣＰＵ１、ＲＡＭ２及びペリフェラル３を備える。
ＣＰＵ１は、複数のコアを搭載する。説明のため、本実施形態において、コアは二つとし、第一のコア１１と第二のコア１２が含まれるとするが、ＣＰＵ１に３つ以上のコアが搭載されている場合においても本発明は適用可能である。

ペリフェラル３は、電子制御装置１００の外部（例えば、他の電子制御装置１００）と通信を行うために使用されるハードウェアであり、内部にレジスタ３１を含む。このペリフェラル３は、具体的にはＣＡＮコントローラやＥｔｈｅｒｎｅｔ（登録商標）の物理層（Physical Layer）に例示されるハードウェアであって、車載ネットワーク４に接続される。複数の電子制御装置（第一の電子制御装置（カメラＥＣＵ）６、第二の電子制御装置（自動運転ＥＣＵ）７）は、ペリフェラル（ペリフェラル３）を通じて互いに車載ネットワーク（車載ネットワーク４）によりデータの通信を行うことができる。そして、ペリフェラル（ペリフェラル３）は、データ保存部（データ保存部２Ａ）（図２参照）から読み出したデータを他の電子制御装置に送信し、又は他の電子制御装置からデータを受信する。

ＣＰＵ１の第一のコア１１又は第二のコア１２がハードウェア固有の送信用のレジスタ３１に値を書き込むことにより、通信データが車載ネットワーク４に送信される。逆に、ペリフェラル３が、他の電子制御装置１００が送信した通信データを車載ネットワーク４から受信した場合は、ハードウェア固有の受信用のレジスタ３１に値が書き込まれる。この通信データは、第一のコア１１と第二のコア１２が利用可能な形式に変換され、ＲＡＭ２に保存される。そして、第一のコア１１と第二のコア１２は、ＲＡＭ２からデータを読み出し、各コアが備えるアプリケーションモジュール（アプリケーションプログラムの一例）によるアプリケーション処理に用いることが可能である。

＜電子制御装置の各部の内部構成例＞
図２は、第１の実施形態に係る電子制御装置１００の各部の内部構成例を示すブロック図である。
図２に示すブロック図では、図１に示したＣＰＵ１の第一のコア１１に相当する機能部として演算処理部１Ａが設けられ、第二のコア１２に相当する機能部として演算処理部１Ｂが設けられる。また、図１に示したＲＡＭ２に相当する機能部としてデータ保存部２Ａが設けられる。この演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）は、アプリケーション処理を行うアプリケーション処理部（アプリケーション処理部２２）を有する。また、演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）は、アプリケーション処理部（アプリケーション処理部２２）と、アプリケーション処理により生成されたアプリケーションデータの通信準備を行う通信準備処理部（通信準備処理部２０１）を有している。

演算処理部１Ａは、アプリケーション処理部２２、通信準備処理部２０１、ペリフェラルアクセス部２０２、及びタスク起動時刻管理部２６を備える。ここで、少なくとも一つの演算処理部（演算処理部１Ａ、第一のコア１１）は、通信データ保存部（通信データ保存部２８）及びペリフェラル（ペリフェラル３）にアクセスするペリフェラルアクセス部（ペリフェラルアクセス部２０２）と、ペリフェラルアクセス部（ペリフェラルアクセス部２０２）とを起動する起動時刻を管理する起動時刻管理部（タスク起動時刻管理部２６）を有する。

演算処理部１Ａのアプリケーション処理部２２は、演算処理部１Ａが担う機能を実現するためのアプリケーション処理を行う。アプリケーション処理により生成されたアプリケーションデータは、アプリケーションデータ保存部２３に保存される。

演算処理部１Ａの通信準備処理部２０１は、電子制御装置１００が他の電子制御装置との通信するための通信準備処理を行い、通信データを通信データ保存部２８に保存する。また、通信準備処理部２０１は、他の電子制御装置１００から受信された通信データを通信データ保存部２８から読み出して、アプリケーション処理部２２が利用可能な形式に変換した後、この変換後のデータをアプリケーションデータ保存部２３に保存することもできる。

ペリフェラルアクセス部２０２は、通信データ保存部２８と通信し、タスク起動時刻管理部２６から入力される起動指示に従って、ペリフェラル３及び通信データ保存部２８にアクセスする。

タスク起動時刻管理部２６は、ペリフェラルアクセス部２０２の起動をタスクとした時に、ペリフェラルアクセス部２０２の起動時刻を管理する。そして、起動時刻管理部（タスク起動時刻管理部２６）は、予め決められた内部時刻に基づいて、第１タイミングでアプリケーション処理部（アプリケーション処理部２２）を動作させ、第２タイミングでペリフェラルアクセス部（ペリフェラルアクセス部２０２）を動作させる。後述するように、第１の実施形態に係る第１タイミングは、アプリケーション処理部（アプリケーション処理部２２）がアプリケーションデータ保存部（アプリケーションデータ保存部２３）に対してデータを入出力するタイミングとして固定される。また、第２タイミングは、ペリフェラルアクセス部（ペリフェラルアクセス部２０２）が通信データ保存部（通信データ保存部２８）に保存された通信データをペリフェラル（ペリフェラル３）に転送するタイミングとして固定される。また、内部時刻は、電子制御装置１００が外部から受信する時刻同期用の信号により補正される。このため、複数の電子制御装置１００の内部時刻が同期する。

演算処理部１Ｂは、アプリケーション処理部２２、及び通信準備処理部２０１を備える。
演算処理部１Ｂのアプリケーション処理部２２は、演算処理部１Ｂが担う機能を実現するためのアプリケーション処理を行う。アプリケーション処理により生成されたアプリケーションデータは、アプリケーションデータ保存部２３に保存される。
演算処理部１Ｂの通信準備処理部２０１は、電子制御装置１００が他の電子制御装置との通信するための通信準備処理を行い、通信データを通信データ保存部２８に保存する。演算処理部１Ｂの通信準備処理部２０１の処理は、演算処理部１Ａの通信準備処理部２０１の処理と同様である。

データ保存部（データ保存部２Ａ）は、演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）で処理されるデータを保存する。このデータ保存部（データ保存部２Ａ）は、アプリケーションデータを保存するアプリケーションデータ保存部（アプリケーションデータ保存部２３）と、通信準備処理部（通信準備処理部２０１）により生成された通信データを保存する通信データ保存部（通信データ保存部２８）とを有している。

アプリケーションデータ保存部２３は、演算処理部１Ａ，１Ｂのアプリケーション処理部２２で処理されたアプリケーションデータを保存する。アプリケーションデータ保存部（アプリケーションデータ保存部２３）は、それぞれのアプリケーション処理部（アプリケーション処理部２２）がアプリケーション処理の途中のデータを一時的に保存する領域として、処理を実行しているアプリケーション処理部（アプリケーション処理部２２）だけが使用するローカル領域（ローカル領域２３ａ）を有する。ローカル領域２３ａは、図１に示したＲＡＭ２の内部に設けられる領域である。ローカル領域２３ａに保存されるデータは、各アプリケーション処理部２２だけが個別にアクセス可能であるため、他のアプリケーション処理部２２により変更されない。

また、アプリケーションデータ保存部（アプリケーションデータ保存部２３）は、アプリケーション処理部（アプリケーション処理部２２）が処理を完了した結果のデータを保存し、他のアプリケーション処理部（アプリケーション処理部２２）にデータを使用可能に公開するグローバル領域（グローバル領域２３ｂ）を有する。グローバル領域２３ｂは、ＲＡＭ２に設けられる領域である。グローバル領域２３ｂに保存されるデータは、各アプリケーション処理部２２が相互にアクセス可能であり、データを利用することができる。このため、アプリケーション処理部（アプリケーション処理部２２）は、第１タイミングでグローバル領域（グローバル領域２３ｂ）にアクセスする。また、アプリケーションデータ保存部２３のグローバル領域２３ｂに保存されたアプリケーションデータは、演算処理部１Ａ，１Ｂの通信準備処理部２０１が読み出し可能である。

後述する図８、図９、図１３、図１４に示すデータ取得タスク２４がローカル領域２３ａ又はグローバル領域２３ｂからデータを読み出すことが可能である。また、データ公開タスク２５がグローバル領域２３ｂにデータを書き込むことが可能である。ローカル変数やグローバル変数はコンパイラによって区別され、ＲＡＭ２の内部で、ローカル変数がローカル領域２３ａに配置され、グローバル変数がグローバル領域２３ｂに配置される。ＲＡＭ２のどの領域がローカル領域２３ａでどの領域がグローバル領域２３ｂかは電子制御装置１００に依存する。

通信データ保存部２８は、演算処理部１Ａ，１Ｂの通信準備処理部２０１で処理された通信データを保存する。通信データ保存部２８に保存された通信データは、ペリフェラルアクセス部２０２により読み出し可能である。

ペリフェラル３は、タスク起動時刻管理部２６により起動されたタイミングでペリフェラルアクセス部２０２から出力されたデータを、車載ネットワーク４（以下、バスとも呼ぶ）を介して他の電子制御装置に送信する。また、ペリフェラル３は、車載ネットワーク４を介して他の電子制御装置から受信したデータをペリフェラルアクセス部２０２に出力する。タスク起動時刻管理部２６により起動されたタイミングでペリフェラルアクセス部２０２がペリフェラル３から取得した通信データは、通信データ保存部２８に保存される。その後、演算処理部１Ａ，１Ｂの通信準備処理部２０１が通信データ保存部２８から通信データを取得し、アプリケーション処理部２２が処理可能なデータに変換し、アプリケーションデータ保存部２３のグローバル領域２３ｂに保存する。演算処理部１Ａ，１Ｂのアプリケーション処理部２２は、アプリケーションデータ保存部２３からデータを読み出して、各アプリケーションの処理に用いる。

そして、第１の実施の形態に係る電子制御装置１００では、演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）がアプリケーション処理のためにデータ保存部（データ保存部２Ａ）にデータを入出力する第１タイミングと、演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）がデータ保存部（データ保存部２Ａ）から読み出したデータをペリフェラル（ペリフェラル３）に渡して、ペリフェラル（ペリフェラル３）が他の電子制御装置にデータを送信する第２タイミングとが予め固定される。以下、本実施の形態に係る、予め固定される処理のタイミングについて、従来の技術と比較しつつ説明する。

＜車両制御装置の内部構成例＞
図３は、第１の実施形態に係る電子制御装置を搭載した車両制御装置の内部構成例を示すブロック図である。ここでは、車両制御装置５に搭載される電子制御装置として、第一の電子制御装置（カメラＥＣＵ）６と第二の電子制御装置（自動運転ＥＣＵ）７とを例に示す。

車両制御装置５は、第一の電子制御装置（カメラＥＣＵ）６、第二の電子制御装置（自動運転ＥＣＵ）７、カメラ８、ステアリング１６、アクセル１７及びブレーキ１８を備える。第一の電子制御装置（カメラＥＣＵ）６と第二の電子制御装置（自動運転ＥＣＵ）７は、互いに車載ネットワーク４にて接続される。第一の電子制御装置（カメラＥＣＵ）６と第二の電子制御装置（自動運転ＥＣＵ）７の内部のハードウェア構成はそれぞれ図１に示した電子制御装置１００と同様である。

カメラ８は、例えば、１００ミリ秒周期で車両前方の画像を撮影し、ＪＰＥＧ（Joint Photographic Experts Group）などの公知の手法によりカメラ画像データ９を生成する。カメラ８が生成したカメラ画像データ９は、第一の電子制御装置（カメラＥＣＵ）６に入力される。

第一の電子制御装置（カメラＥＣＵ）６は、カメラ８からカメラ画像データ９を受け取り、カメラ物体検知データ１０を生成する。ここで、カメラ物体検知データ１０の構成例について説明する。
図４は、カメラ物体検知データ１０の構成例を示した図である。

カメラ物体検知データ１０は、物体の番号（識別子）、物体種別、及び座標の項目で構成される。
番号（識別子）の項目には、第一の電子制御装置（カメラＥＣＵ）６が有する画像認識アプリケーションモジュール２２１，２２２（後述する図８を参照）によりカメラ画像データ９から検知された物体毎に特定の番号が割り当てられる。
物体種別の項目には、検知された物体ごとに、例えば、自動車、歩行者等の物体種別が格納される。
座標の項目には、画像認識アプリケーションモジュール２２１，２２２により検知された物体のカメラ画像データ９内における座標情報が格納される。

第一の電子制御装置（カメラＥＣＵ）６に入力されるカメラ画像データ９は、ＪＰＥＧやＰＮＧ（Portable Network Graphics）など公知の圧縮形式により圧縮された画像データ、又はカメラ８のイメージングセンサが感知した数値列そのものであり、一般にｒａｗデータと呼ばれる。一方、第一の電子制御装置（カメラＥＣＵ）６から出力されるカメラ物体検知データ１０は、カメラ画像データ９から検知された物体の番号（識別子）、物体種別、及び座標の項目で構成される。このため、カメラ画像データ９は、カメラ物体検知データ１０と比較して、送受信するデータのサイズが大きく、数メガバイト程度である。

図３に示すように、第一の電子制御装置（カメラＥＣＵ）６は、車載ネットワーク４を介して第二の電子制御装置（自動運転ＥＣＵ）７にカメラ物体検知データ１０を送信する。カメラ物体検知データ１０のデータサイズは、カメラ画像データ９よりも小さいので、車載ネットワーク４の帯域を占有しないですむ。なお、第一の電子制御装置（カメラＥＣＵ）６の内部ロジックについては、本発明に直接関係しないため例示を省略する。

第二の電子制御装置（自動運転ＥＣＵ）７は、例えば、１００ミリ秒周期で第一の電子制御装置（カメラＥＣＵ）６からカメラ物体検知データ１０を受信する。そして、第二の電子制御装置（自動運転ＥＣＵ）７は、カメラ物体検知データ１０に基づき、車両の進行方向（軌道）を計画し、該計画を実現するためのステアリング制御指令１３、アクセル制御指令１４及びブレーキ制御指令１５を生成する。ステアリング制御指令１３は、ステアリング１６の動作を制御するための指令データである。アクセル制御指令１４は、アクセル１７の動作を制御するための指令データである。ブレーキ制御指令１５は、ブレーキ１８の動作を制御するための指令データである。

ステアリング１６は、ステアリング制御指令１３により制御され、車両の進行方向を変える。アクセル１７は、アクセル制御指令１４により制御され、車両を加速する。ブレーキ１８は、ブレーキ制御指令１５により制御され、車両を減速する。このように車両の進行方向、加減速が制御されることを「車両制御」と呼ぶ。なお、第二の電子制御装置（自動運転ＥＣＵ）７におけるカメラ物体検知データ１０の解析処理、及び各制御指令の生成を行うロジック、並びに各制御指令のデータ形式については、本発明に直接関係しないため例示を省略する。

＜時刻同期＞
次に、第一の電子制御装置（カメラＥＣＵ）６と第二の電子制御装置（自動運転ＥＣＵ）７の時刻同期について説明する。
図５は、第一の電子制御装置（カメラＥＣＵ）６と第二の電子制御装置（自動運転ＥＣＵ）７の時刻同期の必要性を示した図である。図５Ａは、時刻同期のパターン１を示す図であり、図５Ｂは、時刻同期のパターン２を示す図である。

第一の電子制御装置（カメラＥＣＵ）６においては、カメラ画像データ９からカメラ物体検知データ１０を生成するために１００ミリ秒ごとの周期処理が行われる。第二の電子制御装置（自動運転ＥＣＵ）７においては、カメラ物体検知データ１０から各制御指令を生成するために１００ミリ秒ごとの周期処理が行われる。通常、これらの周期処理は電子制御装置６，７の内部に搭載されたハードウェアカウンタのタイムアウト処理を用いて実装される。しかし、ハードウェアカウンタの動作クロックが異なると電子制御装置６，７間で時刻にずれが生じるため、データフローの一貫性が保たれず、車両制御に影響を与える可能性がある。

図５Ａに示すパターン１において、第一の電子制御装置（カメラＥＣＵ）６が１周期目に生成したデータは、車載ネットワーク４を介して第二の電子制御装置（自動運転ＥＣＵ）７の２周期目の開始より前に到達する。このため、第二の電子制御装置（自動運転ＥＣＵ）７は、２周期目において第一の電子制御装置（カメラＥＣＵ）６が１周期目に生成したデータを使用して計算処理を実行可能である。

一方、図５のパターン２において、第一の電子制御装置（カメラＥＣＵ）６が１周期目に生成したデータは、車載ネットワーク４を介して第二の電子制御装置（自動運転ＥＣＵ）７の２周期目の開始より後に到達する。このため、第二の電子制御装置（自動運転ＥＣＵ）７は、２周期目ではなく次の３周期目に第一の電子制御装置（カメラＥＣＵ）６が１周期目に生成したデータを使用して計算処理を実行可能となる。このように、電子制御装置６，７の内部時刻にずれが生じるとシステムの振る舞いに変動が生じる。

ここで、システム開発者は、複数の電子制御装置の内部時刻のずれによる、複数の電子制御装置の全体を含むシステムの振る舞いの変動が車両制御に影響を与えないことを検証する必要がある。この検証作業は、ソフトウェア開発コストの増大の一因となっていた。そこで、第１の実施形態では、第一の電子制御装置（カメラＥＣＵ）６と、第二の電子制御装置（自動運転ＥＣＵ）７の間で時刻がずれないよう同期を行う制御が行われる。電子制御装置間の時刻同期の手法は、車載ソフトウェアの標準規格であるＡＵＴＯＳＡＲ（AUTomotive Open System Architecture）に規定されている。ただし、電子制御装置間の時刻同期の手法は本発明に直接関連しないためＡＵＴＯＳＡＲの詳細の例示は省略する。

＜時刻同期された電子制御装置間におけるデータフローの変化＞
図６は、時刻同期された電子制御装置間におけるデータフローの変化の例を示す図である。図６Ａは、図５Ａと同じ時刻同期のパターン１を示す図であり、図６Ｂは、変化したデータフローのパターン３を示す図である。図６では、図５の場合と異なりパターン１とパターン３では共に第一の電子制御装置（カメラＥＣＵ）６と第二の電子制御装置（自動運転ＥＣＵ）７が時刻同期されている。

図６では１００ミリ秒ごとの周期タスクの開始タイミングが二つの電子制御装置間で一致している。ただし、１００ミリ秒ごとの周期タスクの開始タイミング（位相）がずれている場合であっても、このずれが一定であれば時刻同期されていると考えてよい。しかしながら、パターン３に示すように、１周期目における第一の電子制御装置（カメラＥＣＵ）６の処理時間が長くなった場合、車載ネットワーク４で伝送されるカメラ物体検知データ１０の通信時間が２周期目にかかっている。この場合、第二の電子制御装置（自動運転ＥＣＵ）７の２周期目の開始までにカメラ物体検知データ１０が到達しないので、第二の電子制御装置（自動運転ＥＣＵ）７の２周期目において処理抜けが発生し、データフローの一貫性が保たれなくなる。

このようなデータ送信側の電子制御装置における処理時間の変動は、交通量の少ない高速道路における直進走行時と、交通量の多い繁華街における交差点右折走行時のように車両の周辺環境から得られる情報量の差によって発生し、車両制御に重大な影響を与える。したがって、システム開発者は、交通量の多寡によらず、図６Ｂのパターン３に示すようなデータフローの一貫性の破綻が発生しないことを検証しなければならない。また、システム開発者は、必要に応じてタイミングやＣＰＵのスケジューリングを再設計することが必要となるため、車載ネットワーク４で伝送されるデータのデータ量の変化は、ソフトウェア開発コストを上昇させる一つの要因であった。

＜ＬＥＴ及びＬＣＴ＞
ここで、非特許文献１に開示されたＬＥＴ（Logical Execution Time）及びＬＣＴ（Logical Communication Time）の概要について説明する。
図７は、非特許文献１にて提案されたＬＥＴ及びＬＣＴの概要を示した図である。非特許文献１は、以下の文献である。
”Kai-Bjorn Gemlau, Leonie KOHLER, Rolf Ernst, and Sophie Quinton. 2021. “System-level Logical Execution Time: Augmenting the Logical Execution Time Paradigm for Distributed Real-time Automotive Software.” ACM Trans. Cyber-Phys. Syst. 5, 2, Article 14 (January 2021), 27 pages. DOI:https://doi.org/10.1145/3381847”
この非特許文献１には、ＬＥＴと呼ばれるスケジューリング手法をＥＣＵ間に拡張する手法に関して記載されている。

図７Ａは、ＬＥＴとＬＣＴの定義を示す図である。図７Ａに示すように、第一の電子制御装置、車載ネットワーク、第二の電子制御装置の各周期の期間は１００ミリ秒で一定である。

第一の電子制御装置における１周期目、２周期目、３周期目、４周期目のＬＥＴには、それぞれ第１の処理、第２の処理、第３の処理、第４の処理が割り当てられる。各処理の始めのリードタイミングでデータの読み出しが行われ、各処理の終わりのライトタイミングで処理後のデータの書き込みが行われる。異なる装置及び車載ネットワークは、ある周期の最後にＲＡＭ２、ペリフェラル３等に書き込まれたデータを、次の周期の最初に読み出すことができる。

車載ネットワークでは、第一の電子制御装置で処理されたデータの通信処理が示される。例えば、車載ネットワークにおける２周期目のＬＣＴには、第一の電子制御装置による１周期目の第１の処理の結果であるデータを第二の電子制御装置に通信する第１の処理が割り当てられる。同様に、車載ネットワークにおける３周期目、４周期目のＬＣＴには、第一の電子制御装置による２周期目、３周期目の第１の処理の結果であるデータを第二の電子制御装置に通信する第２の処理、第３の処理が割り当てられる。

そして、第二の電子制御装置における３周期目、４周期目のＬＥＴには、それぞれ車載ネットワークを介して受信したデータを用いる、第二の電子制御装置の第１の処理、第２の処理が割り当てられる。

図７Ｂは、各電子制御装置の処理時間と、車載ネットワークの通信時間の例を示す図である。第一の電子制御装置、車載ネットワーク、第二の電子制御装置の各周期の期間は固定されているので、第一の電子制御装置及び第二の電子制御装置で行われる処理は、ＬＥＴ内のどこかで実行する。また、車載ネットワークで行われる通信処理は、ＬＣＴ内のどこかで実行する。例えば、第一の電子制御装置は、ある周期でＬＥＴ内のどこかで処理を実行する。次の周期で、車載ネットワークは、ＬＥＴ内のどこかでデータを第二の電子制御装置に通信する。さらに次の周期で、第二の電子制御装置は、車載ネットワークからデータを取得して、ＬＥＴ内のどこかで処理を実行する。

非特許文献１に提案された手法は、電子制御装置に搭載されるアプリケーションの処理、及び車載ネットワークの通信処理のそれぞれに対して、その開始時刻及び終了時刻を予め固定し、変化させないというものである。ここで、開始時刻とは、電子制御装置に搭載されるアプリケーションの処理、及び車載ネットワークの通信処理が必要なデータを取得する時刻である。また、終了時刻とは、電子制御装置に搭載されるアプリケーションの処理、及び車載ネットワークの通信処理で生成されたデータを、次の周期の電子制御装置又は車載ネットワークに公開する時刻である。非特許文献１に提案された手法を用いることで、ペリフェラルの共有やＤＭＡコントローラによる処理の代替、ひいてはアプリケーションのアップデートやコア割り付けの変更、ハードウェアの変更を行う場合においても、各アプリケーション処理及び各通信処理の順序が変化せず、データフローの一貫性が保たれる。このため、検証及びタイミングの再設計に関するソフトウェア開発コストが削減されると期待されていた。

しかしながら、非特許文献１に開示された手法に従ってアプリケーションの処理及び通信処理の開始及び終了時刻を固定すると、以下の問題が発生することが判明した。この問題とは、各メッセージ（データ）の通信処理に要する処理時間が長い場合、各メッセージの処理に要するＣＰＵ処理時間に起因して、通信処理の開始から終了までの時間に通信可能なメッセージ量（すなわちデータ量）が制約されるというものであった。

したがって、高画質な車載カメラやゾーンＥＣＵ及びセントラルＥＣＵに例示される大量のデータ通信を必要とするアプリケーションに対して、非特許文献１に開示された手法をそのまま適用することはできなかった。なお、通信処理の開始時刻から終了時刻までの時間を長くした場合、データ通信量を増加させることが可能であるが、アプリケーション間のデータ交換に要する時間が長くなるため、レイテンシ（通信遅延）が悪化するという問題があった。

図６を参照して説明したように、各ＥＣＵのＣＰＵ１が各アプリケーションの処理に要する時間は、車両の周辺環境あるいは車両の内部状態によって変動する。そこで、非特許文献１に係る技術では、図２に示した各アプリケーション処理部２２で実行する各アプリケーションの処理は全て他のアプリケーション処理部２２とデータを共有しないローカル変数を用いて内部の処理を行うこととする。また、各アプリケーション処理部２２における処理の開始時と終了時に複数のアプリケーション処理部２２の間で互いに共有されるグローバル変数をリード及びライトする。さらに各アプリケーション処理部２２がグローバル変数のリード及びライトを行うタイミングを固定する。これにより、各アプリケーション処理部２２がアプリケーション処理に要する時間を、固定したグローバル変数のリードのタイミングから固定したグローバル変数のライトのタイミングまでの時間とみなし、この時間をＬＥＴと呼ぶように定義した。このようにＬＥＴを定義することで、各アプリケーション処理部２２に要する処理時間を常に一定とみなすことができ、前述のようなデータフローの一貫性の破綻が生じないと考えられる。

同様に、データ通信に関しても、送信元の電子制御装置が備えるＲＡＭ２からグローバル変数を読み出すタイミングと、受信先の電子制御装置が備えるＲＡＭ２にグローバル変数の値を書き込むタイミングを固定する。そして、グローバル変数をリードするタイミングからグローバル変数の値をライトするタイミングまでの時間をＬＣＴとみなす。

ＬＣＴの間のいずれかのタイミングにおいて送信元の電子制御装置（第一の電子制御装置（カメラＥＣＵ）６）上のＢＳＷ（Basic Software）による送信処理と、車載ネットワーク４上の物理的なデータ転送と、受信先の電子制御装置（第二の電子制御装置（自動運転ＥＣＵ）７）上のＢＳＷによる受信処理とが実行される。

本実施形態においては、車載ネットワーク４における通信負荷（バス負荷とも呼ぶ）は十分小さいとする。そこで、通信周期の短い通信メッセージ（通信データ）に対して優先度を高く設定する。この設定により、通信周期の異なる、どの通信メッセージに関しても次の通信周期が開始するタイミングまでに、送信先の電子制御装置（第二の電子制御装置（自動運転ＥＣＵ）７）のペリフェラル３のレジスタ３１（図１を参照）に必ずデータが到達する。ここで、ＣＡＮの場合、バス負荷が２５％以下であれば十分であることが知られている。そこで、図１に示した第一の電子制御装置（カメラＥＣＵ）６及び第二の電子制御装置（自動運転ＥＣＵ）７の処理周期は１００ミリ秒であるから、ＬＣＴも１００ミリ秒と設定すればよい。

＜ＬＥＴ及びＬＣＴの実装＞
次に、非特許文献１にて提案されたＬＥＴ及びＬＣＴを実装するための従来のソフトウェアアーキテクチャについて、図８～図１１を参照して説明する。
図８は、第一の電子制御装置（カメラＥＣＵ）６に従来のソフトウェアアーキテクチャを適用した例を示す図である。

第一の電子制御装置（カメラＥＣＵ）６における第一のコア１１を通信専用、第二のコア１２をアプリケーション専用とする。すなわち、第一のコア１１に対して、ＯＳ（Operating System）１９、通信ミドルウェア２０及び通信ドライバ２１が割り付けられる。また、第二のコア１２に対して、ＯＳ１９、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２、データ取得タスク２４、データ公開タスク２５が割り付けられる。

画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２は、いずれもアプリケーション処理を実行するモジュールである。
データ取得タスク２４は、各アプリケーションモジュールの処理開始時に各アプリケーション処理部２２に必要なデータをＲＡＭ２（図１を参照）から取得する。データ取得タスク２４は、アプリケーションデータ保存部２３（図２を参照）のローカル領域２３ａ又はグローバル領域２３ｂからデータを取得できる。

データ公開タスク２５は、各アプリケーションモジュールの処理終了時に、各アプリケーション処理の結果をＲＡＭ２に含まれるアプリケーションデータ保存部２３に保存する。データ公開タスク２５は、第一のコア１１及び第二のコア１２の双方からアクセス可能な領域（グローバル領域２３ｂ）をアプリケーションデータ保存部２３に設定し、このグローバル領域２３ｂに各アプリケーション処理の結果を保存する。このため、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２が生成し、他のアプリケーションモジュールで用いられるデータは、データ公開タスク２５によってグローバル領域２３ｂに保存される。

通信ミドルウェア２０は、グローバル領域２３ｂに保存されたデータに対し、ヘッダ生成等を含む通信に必要なデータを付加し、通信データを生成する機能を有する。この通信データは、例えば、イーサネットで用いられるフレームである。
通信ドライバ２１は、通信データを、図１に示したペリフェラル３のレジスタ３１にライトする。

データ取得タスク２４とデータ公開タスク２５を起動するタイミングは固定されている。また、データ取得タスク２４とデータ公開タスク２５の処理は、ＲＡＭ２へのアクセスのみである。このため、データ取得タスク２４とデータ公開タスク２５のＣＰＵ処理時間は一定とみなすことができる。その結果、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２のＣＰＵ処理時間（アプリケーション処理時間）が変動しても、データ取得タスク２４が起動されるタイミングとデータ公開タスク２５が完了するタイミングは変動しない。

データフローの観点から見ると、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２の実行時間は、データ取得タスク２４が起動されるタイミングから起算してデータ公開タスク２５が完了するタイミングまでの時間として一定である。この一定時間が画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２に関するＬＥＴとして実装される。

なお、電子制御装置１００に含まれる各アプリケーションモジュール及び各タスクを所定のタイミングに起動する操作は、タスク起動時刻管理部２６によって管理及び実行される。タスク起動時刻管理部２６は、ＯＳ１９から提供されるタスクスケジューリング機能を実現する機能部である。

図９は、第二の電子制御装置（自動運転ＥＣＵ）７における従来のソフトウェアアーキテクチャを適用した例を示す図である。

第二の電子制御装置（自動運転ＥＣＵ）７における第一のコア１１を通信専用、第二のコア１２をアプリケーション専用とする。すなわち、第一のコア１１に対して、ＯＳ（Operating System）１９、通信ミドルウェア２０及び通信ドライバ２１を割り付ける。また、第二のコア１２に対して、ＯＳ１９、軌道生成アプリケーションモジュール２２３、制御指令生成アプリケーションモジュール２２４、データ取得タスク２４、データ公開タスク２５を割り付ける。

軌道生成アプリケーションモジュール２２３は、車両が走行する軌道を生成する。
制御指令生成アプリケーションモジュール２２４は、生成された軌道に従って、図３に示したステアリング１６、アクセル１７及びブレーキ１８に対する制御指令（ステアリング制御指令１３、アクセル制御指令１４及びブレーキ制御指令１５）を生成する。

軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４の実行時間は、データ取得タスク２４が起動されるタイミングから起算してデータ公開タスク２５が完了するタイミングまでの時間として一定である。該時間が軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４に関するＬＥＴとして実装される。
データ取得タスク２４、データ公開タスク２５、及びタスク起動時刻管理部２６については、図８を参照して説明したものと同じであるので、詳細な説明を省略する。

次に、ＬＣＴの実装を考えるため、通信ミドルウェア２０の処理について説明する。
図８と図９に示した通信ミドルウェア２０は、周期的に起動され、他の電子制御装置に対して通信データの送信処理を行う。そこで、通信ミドルウェア２０は、図２に示したアプリケーションデータ保存部２３のグローバル領域２３ｂに保存されたデータをデータ公開タスク２５により読み取る。その後、通信ミドルウェア２０は、通信に必要なデータ（通信ヘッダ等）を読み取ったデータに付加し、通信ドライバ２１をコールすることにより、図１に示したペリフェラル３のレジスタ３１に通信データを書き込む。

また、通信ミドルウェア２０は、ペリフェラル３のデータ受信割り込みによっても起動され、他の電子制御装置から送信された通信データの受信処理を行うこともできる。通信ミドルウェア２０は、データの受信処理に際して、通信ドライバ２１を用いてペリフェラル３のレジスタ３１に保存された通信データを読み取る。そして、通信ミドルウェア２０は、通信ヘッダの除去やＣＲＣ（Cyclic Redundancy Check）など通信プロトコルによって規定されるデータ受信に関して必要な所定の処理を実行する。その後、通信ミドルウェア２０は、アプリケーションデータ保存部２３において、特に第一のコア１１からアクセス可能であって、第二のコア１２からアクセス可能ではないＲＡＭ２のローカル領域２３ａに、受信処理後のデータを保存する。

また、通信ミドルウェア２０は、周期的に起動され、ＲＡＭ２のローカル領域２３ａに保存された受信データを、ＲＡＭ２のグローバル領域２３ｂに保存することもできる。このため、第一のコア１１及び第二のコア１２の双方でグローバル領域２３ｂにアクセス可能である。

ＬＣＴは、以下の処理で規定される。
すなわち、第一の電子制御装置（カメラＥＣＵ）６に搭載された通信ミドルウェア２０が送信処理のために起動される時刻から起算されると、第二の電子制御装置（自動運転ＥＣＵ）７に搭載された通信ミドルウェア２０も起動する。第二の電子制御装置（自動運転ＥＣＵ）７に搭載された通信ミドルウェア２０は、図２に示したアプリケーションデータ保存部２３のうち、特に第一のコア１１からアクセス可能であって、第二のコア１２からアクセス可能ではないローカル領域２３ａに保存されたデータを取り出す。そして、通信ミドルウェア２０は、アプリケーションデータ保存部２３のうち、特に第一のコア１１及び第二のコア１２の双方からアクセス可能なグローバル領域２３ｂにデータを保存する。このように通信ミドルウェア２０が送信処理のために起動される時刻から起算され、グローバル領域２３ｂにデータを保存するまでの時刻がＬＣＴとして規定される。

車載ネットワーク４の状況により第一の電子制御装置（カメラＥＣＵ）６から第二の電子制御装置（自動運転ＥＣＵ）７への通信に要する時間は変動しうる。ただし、データフローの観点で見れば、変動した時間もＬＣＴとして一定とみなすことができる。

ここで、非特許文献１にて提案された技術を用いて、アプリケーション処理及び通信処理を行う例について説明する。
図１０は、非特許文献１にて提案されたＬＥＴ及びＬＣＴを、図８及び図９に示したモジュール及びタスクにマッピングした例を示す図である。

第一の電子制御装置（カメラＥＣＵ）６のタイミングチャートで行われる処理は、第一の電子制御装置（カメラＥＣＵ）６のアプリケーション専用の第二のコア１２で行われる処理を表している。また、車載ネットワーク４のタイミングチャートで行われる前半の処理（図の左側のリードタイミングを含む）は、第一の電子制御装置（カメラＥＣＵ）６の通信専用の第一のコア１１で行われる処理を表している。一方、車載ネットワーク４のタイミングチャートで行われる後半の処理（図の右側のライトタイミングを含む）は、第二の電子制御装置（自動運転ＥＣＵ）７の通信専用の第一のコア１１で行われる処理を表している。そして、第二の電子制御装置（自動運転ＥＣＵ）７のタイミングチャートで行われる処理は、第二の電子制御装置（自動運転ＥＣＵ）７のアプリケーション専用の第二のコア１２で行われる処理を表している。

（１周期目）
第一の電子制御装置（カメラＥＣＵ）６では、１周期目の始めにデータ取得タスク２４がアプリケーション処理に必要なデータを取得する。そして、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２（図中では、「画像認識（車両前方）２２１及び画像認識（車両後方）２２２」と略記する）が処理を実行する。処理後のデータは、１周期目の終わりでデータ公開タスク２５によりペリフェラル３に書き込まれる。図中の「処理」と記載される領域は、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２が処理を実行する時間を表す。

（２周期目）
次に、車載ネットワーク４では、２周期目の始めに第一の電子制御装置（カメラＥＣＵ）６における通信ミドルウェア２０がデータを読み出して、第二の電子制御装置（自動運転ＥＣＵ）７に向けて通信処理を実行する。図中の「通信」と記載される領域は、バス（車載ネットワーク４）をデータが流れている時間を表す。その後、２周期目の終わりで第二の電子制御装置（自動運転ＥＣＵ）７における通信ミドルウェア２０が受信したデータをＲＡＭ２に書き込む。

（３周期目）
次に、第二の電子制御装置（自動運転ＥＣＵ）７では、３周期目の始めにデータ取得タスク２４がペリフェラル３からデータを取得する。そして、軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４（図中では、「軌道生成２２３及び制御指令生成２２４」と略記する）が処理を実行する。処理後のデータは、３周期目の終わりでデータ公開タスク２５によりペリフェラル３に書き込まれる。図中の「処理」と記載される領域は、軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４が処理を実行する時間を表す。

＜データ通信量の制約＞
図１１は、第一の電子制御装置（カメラＥＣＵ）６において大量のデータ送信を行う場合における通信ミドルウェア２０と車載ネットワーク４のタイミングチャートである。図１１を参照しながらデータ通信量の制約について説明する。図１１の上側のタイミングチャートは、図１０に示したタイミングチャートと同様である。

通信ミドルウェア２０におけるデータ公開タスク２５により、アプリケーションデータ保存部２３において特に第一のコア１１及び第二のコア１２双方からアクセス可能な領域（グローバル領域２３ｂ）に保存されたデータを読み取り、通信ヘッダ等の通信に必要なデータを付加してペリフェラル３のレジスタ３１に該データを書き込む処理がある。この処理では、例えば車載ソフトウェア標準規格ＡＵＴＯＳＡＲにおけるＥｔｈｅｒｎｅｔ通信の場合、後述する図１２の左側に示すように、ＲＴＥ（RunTime Environment）からCommunication (ＣＯＭ) Serviceに所属するＣｏｍとＰｄｕＲ（Protocol data unit router）と呼ばれるモジュールを経由して行われる。さらに、この処理では、Communication Hardware abstractionに所属するInterfaceとTransceiverと呼ばれるモジュールを経由した後、Driverをコールする必要がある。この処理は全てＣＰＵで実行されるため、１００マイクロ秒～１ミリ秒程度のオーダのＣＰＵ処理時間となる。本実施形態ではＣＰＵ処理時間を１５０マイクロ秒とする。

一方、１ギガビット毎秒の通信速度を許容するＥｔｈｅｒｎｅｔに関して、通信単位であるフレームのサイズを１キロバイトとする。この場合、車載ネットワーク４上を該フレームが物理信号として流れる時間は、１Ｋバイトが８０００ビットであるので、８０００／１０＾９＝８０＊１０＾（－６）、すなわち８０マイクロ秒程度である。ここで、フレームが車載ネットワーク４を流れている時間（８０マイクロ秒）よりも通信ミドルウェア２０のＣＰＵ処理時間（１５０マイクロ秒）のほうが長いため、１５０マイクロ秒－８０マイクロ秒＝７０マイクロ秒の時間分の待ち時間が生じる。

図１１の下側に示すタイミングチャートでは、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２がそれぞれ生成したカメラ物体検知データ１０の処理時間の関係が示される。上述したように画像認識アプリケーションモジュール（車両前方）２２１が生成したカメラ物体検知データ１０に対する通信ミドルウェア２０のＣＰＵ処理時間が１５０マイクロ秒であり、次に、通信ミドルウェア２０で処理されたカメラ物体検知データ１０のフレームが車載ネットワーク４を流れる時間が８０マイクロ秒であることが示される。図１０に示したように、車載ネットワーク４においても、第一の電子制御装置（カメラＥＣＵ）６のＣＰＵ１によりフレーム（データ）を流すための通信処理が行われる。

ここで、画像認識アプリケーションモジュール（車両前方）２２１のカメラ物体検知データ１０に対するＣＰＵ処理が終わると、次に、画像認識アプリケーションモジュール（車両後方）２２２のカメラ物体検知データ１０に対するＣＰＵ処理が行われる。このように従来は、アプリケーション専用の第二のコア１２で、画像認識アプリケーションモジュール（車両前方）２２１、画像認識アプリケーションモジュール（車両後方）２２２の順で通信ミドルウェア２０を用いたＣＰＵ処理が行われていた。

ここで、画像認識アプリケーションモジュール（車両前方）２２１のＣＰＵ処理後のカメラ物体検知データ１０が車載ネットワーク４に流す処理が終了した直後に、画像認識アプリケーションモジュール（車両後方）２２２のＣＰＵ処理後のカメラ物体検知データ１０が車載ネットワーク４に流す処理が開始することが望ましい。しかし、画像認識アプリケーションモジュール（車両後方）２２２は、画像認識アプリケーションモジュール（車両前方）２２１のＣＰＵ処理が終了した後でなければ動作しない。この結果、画像認識アプリケーションモジュール（車両前方）２２１のフレームの送信が終了してから画像認識アプリケーションモジュール（車両後方）２２２のフレームを生成する処理が終了するまで、７０マイクロ秒のＣＰＵ処理の待ち時間が生じてしまう。

画像認識アプリケーションモジュール（車両前方）２２１のカメラ物体検知データ１０の送信が完了してから画像認識アプリケーションモジュール（車両後方）２２２のカメラ物体検知データ１０の送信を開始するまでの７０マイクロ秒間は、第一の電子制御装置（カメラＥＣＵ）６が車載ネットワーク４の帯域を使用できない。このため、ＣＰＵ処理の待ち時間である７０マイクロ秒間においては、車載ネットワーク４で通信可能なデータ量が制約されてしまう。

＜通信準備処理部及びペリフェラルアクセス部＞
図１２は、図２に示した通信準備処理部２０１とペリフェラルアクセス部２０２の処理の概要について、ＡＵＴＯＳＡＲを例として説明する図である。

図１２の左側には、従来の通信ミドルウェア２０と通信ドライバ２１の構成例が示される。通常、ＡＵＴＯＳＡＲにおいては、各アプリケーションモジュールが生成したアプリケーションデータ保存部２３のグローバル領域２３ｂに保存されたデータを、通信ミドルウェア２０がＲＴＥ＿ｒｅａｄ（）により読み取る。その後、通信ミドルウェア２０は、ＣＯＭ、ＰｄｕＲ、Ｔｐ（Transport Protocol）、Ｉｆ（Interface）、Ｄｒｉｖｅｒ（通信ドライバ２１）を順にコールしてペリフェラル３にアクセスし、送信データをレジスタ３１に格納する。ＡＵＴＯＳＡＲにおいて、ＣＯＭ、ＰｄｕＲ、Ｔｐはサービスレイヤに属し、ＩｆはＨＷ（ハードウェア）抽象化レイヤに属する。

通信ミドルウェア２０は、Ｒｔｅ＿ｒｅａｄ（）からＩｆまでの処理を担う。ＲＴＥ＿ｒｅａｄ（）から処理を開始し、Ｄｒｉｖｅｒが処理を完了するまで、上述した通り、およそ１５０マイクロ秒を要する。

そこで、本実施形態においては、図８と図９に示した通信ミドルウェア２０と通信ドライバ２１の処理を、図２に示した通信準備処理部２０１とペリフェラルアクセス部２０２に分割する。
図１２の右側には、本実施形態に係る通信準備処理部２０１とペリフェラルアクセス部２０２の構成例が示される。図２に示したように、通信準備処理部２０１とペリフェラルアクセス部２０２は、演算処理部１Ａに設けられる。なお、演算処理部１Ｂには、通信準備処理部２０１が設けられるが、ペリフェラルアクセス部２０２は設けられない。また、本実施形態では、ＩｆとＤｒｉｖｅｒの間にバッファとして通信データ保存部２８を設置する。図２に示したように、通信データ保存部２８は、データ保存部２Ａに設けられる。

ここで、通信準備処理部２０１にあるＩｆを改造することで、第一のコア１１及び第二のコア１２（演算処理部１Ａ，１Ｂ）がＤｒｉｖｅｒを直接コールするのではなく、該Ｄｒｉｖｅｒをコールする際に渡す引数を通信データ保存部２８に保存するように構成する。そして、ＲＴＥ＿ｒｅａｄ（）から改造したＩｆまでを通信準備処理部２０１としている。図２に示したように、通信準備処理部２０１は、アプリケーションデータ保存部２３のグローバル領域２３ｂに保存されたデータを入力とし、図１２の右側に示すＲＴＥ＿ｒｅａｄ（）から改造したＩｆまでの処理を行った後、通信データ保存部２８にデータを出力する。

さらに本実施形態では、通信データ保存部２８からデータを取り出し、該取り出したデータを引数としてＤｒｉｖｅｒをコールする処理を実行可能な機能部をペリフェラルアクセス部２０２とする。そして、通信準備処理部（通信準備処理部２０１）は、ＡＵＴＯＳＡＲ（登録商標）に規定されるサービスレイヤとハードウェア抽象化レイヤであり、ペリフェラルアクセス部（ペリフェラルアクセス部２０２）は、ＡＵＴＯＳＡＲに規定されるドライバである。通信データ保存部（通信データ保存部２８）は、ハードウェア抽象化レイヤと、ドライバとの間に設けられている。

図２に示したように、通信データ保存部２８の実体は、第一のコア１１と第二のコア１２の双方からアクセス可能なＲＡＭ２の領域に確保することとし、アプリケーションデータ保存部２３とは別の領域とする。Ｒｔｅ＿ｒｅａｄ（）からＤｒｉｖｅｒが処理を完了するまでのＣＰＵ処理の大部分は通信準備処理部２０１で行われる処理であり、通信準備処理部２０１が要するＣＰＵ処理時間は１３０マイクロ秒程度である。一方、ペリフェラルアクセス部２０２は、通信データ保存部２８からのデータ取り出しと、Ｄｒｉｖｅｒ（通信ドライバ２１）のコールのみを行うため、ペリフェラルアクセス部２０２が要するＣＰＵ処理時間は２０マイクロ秒程度である。さらに、通信準備処理部２０１は、第一のコア１１及び第二のコア１２（図２に示した演算処理部１Ａ，１Ｂ）の双方に設けられるため、第一のコア１１及び第二のコア１２がそれぞれ通信準備処理部２０１を並列実行することが可能である。

図１２の右側に示したように、演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）は、予め決められた内部時刻に基づいて、通信準備処理部（通信準備処理部２０１）、ペリフェラルアクセス部（ペリフェラルアクセス部２０２）の順に起動することで、他の電子制御装置１００にデータを送信する。そして、通信準備処理部（通信準備処理部２０１）が通信データ保存部（通信データ保存部２８）に通信データを保存する処理と、ペリフェラルアクセス部（ペリフェラルアクセス部２０２）が通信データ保存部（通信データ保存部２８）から読み出した通信データであって、ペリフェラル（ペリフェラル３）が他の電子制御装置に送信するデータをペリフェラル（ペリフェラル３）に格納する処理とを行う。

逆に、演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）は、予め決められた内部時刻に基づいて、ペリフェラルアクセス部（ペリフェラルアクセス部２０２）、通信準備処理部（通信準備処理部２０１）の順に起動することで、他の電子制御装置１００からデータを受信する。そして、ペリフェラル（ペリフェラル３）が他の電子制御装置から受信したデータをペリフェラルアクセス部（ペリフェラルアクセス部２０２）が取得し、通信データ保存部（通信データ保存部２８）に書き込む処理と、通信準備処理部（通信準備処理部２０１）が通信データ保存部（通信データ保存部２８）から読み出した通信データをアプリケーションデータ保存部（アプリケーションデータ保存部２３）に書き込む処理とを行う。

＜本実施形態に係るソフトウェアアーキテクチャ＞
次に、本実施形態に係るソフトウェアアーキテクチャについて、図１３と図１４を参照して説明する。
本実施形態に係るソフトウェアアーキテクチャでは、図８と図９を参照して説明した非特許文献１における方式を適用した例のように第一のコア１１を通信専用、第二のコア１２をアプリケーション専用とするのではなく、第一のコア１１と第二のコア１２をアプリケーションと通信の兼用とする。

図１３は、第一の電子制御装置（カメラＥＣＵ）６における本実施形態に係るソフトウェアアーキテクチャを示した図である。

第１の実施形態に係る複数の電子制御装置の一つ（第一の電子制御装置（カメラＥＣＵ）６）は、カメラが撮像したカメラ画像データ（カメラ画像データ９）から物体検知を行った結果であるカメラ物体検知データ（カメラ物体検知データ１０）を車載ネットワーク（車載ネットワーク４）に送信する。この第一の電子制御装置（カメラＥＣＵ）６では、第一のコア１１に対して、ＯＳ１９、画像認識アプリケーションモジュール（車両前方）２２１、データ取得タスク２４、データ公開タスク２５、通信準備処理部２０１が割り付けられる。また、第二のコア１２に対して、ＯＳ１９、画像認識アプリケーションモジュール（車両後方）２２２、データ取得タスク２４、データ公開タスク２５、通信準備処理部２０１が割り付けられる。

ＯＳ１９では、第一のコア１１と第二のコア１２の双方からタスク起動時刻管理部２６を実行可能である。
第一の電子制御装置（カメラＥＣＵ）６のペリフェラルアクセス部２０２は、第一のコア１１又は第二のコア１２のいずれかで実行可能とする。図２では、ペリフェラルアクセス部２０２が第一のコア１１に相当する演算処理部１Ａで実行される形態としたが、第二のコア１２に相当する演算処理部１Ｂで実行される形態としてもよい。

図１４は、第二の電子制御装置（自動運転ＥＣＵ）７における本実施形態に係るソフトウェアアーキテクチャを示した図である。

第１の実施形態に係る複数の電子制御装置の一つ（第二の電子制御装置（自動運転ＥＣＵ）７）は、カメラ物体検知データ（カメラ物体検知データ１０）に基づいて、車両の制御対象であるステアリング（ステアリング１６）の目標角度の制御指令値、アクセル（アクセル１７）の目標加速力の制御指令値、及びブレーキ（ブレーキ１８）の目標減衰力の制御指令値のうち、少なくとも一つを生成して制御対象に制御指令値を送信する。この第二の電子制御装置（自動運転ＥＣＵ）７では、第一のコア１１に対して、ＯＳ１９、軌道生成アプリケーションモジュール２２３、データ取得タスク２４、データ公開タスク２５、通信準備処理部２０１が割り付けられる。また、第二のコア１２に対して、ＯＳ１９、制御指令生成アプリケーションモジュール２２４、データ取得タスク２４、データ公開タスク２５、通信準備処理部２０１が割り付けられる。

ＯＳ１９では、第一のコア１１と第二のコア１２の双方からタスク起動時刻管理部２６を実行可能である。
また、第二の電子制御装置（自動運転ＥＣＵ）７のペリフェラルアクセス部２０２は、第一のコア１１又は第二のコア１２のいずれかで実行可能とする。図２では、ペリフェラルアクセス部２０２が第一のコア１１に相当する演算処理部１Ａで実行される形態としたが、第二のコア１２に相当する演算処理部１Ｂで実行される形態としてもよい。

図１３と図１４に示したように、第一のコア１１と第二のコア１２はいずれもアプリケーション処理と通信の処理（特に通信準備処理部２０１）を実行し、第一のコア１１は通信を実行するペリフェラル３にアクセスするためのペリフェラルアクセス部２０２も実行する。

第一のコア１１に搭載されたデータ取得タスク２４は、予め決められた時刻になると起動される。また、第一のコア１１に搭載されたデータ取得タスク２４は、同じく第一のコア１１に搭載されたアプリケーションモジュールである画像認識アプリケーションモジュール（車両前方）２２１の処理に必要なデータを取得する役割を持つ。データ取得タスク２４が取得するデータが同一の電子制御装置内に搭載された画像認識アプリケーションモジュール（車両後方）２２２により生成される場合がある。この場合、データ取得タスク２４は、アプリケーションデータ保存部２３のグローバル領域２３ｂに保存されたデータを取得する。

データ取得タスク２４が取得するデータが、異なる電子制御装置に搭載されたアプリケーションモジュールにより生成され、ペリフェラル３が受信したものである場合、第一のコア１１はペリフェラルアクセス部２０２を起動する。異なる電子制御装置に搭載されたアプリケーションモジュールとは、例えば、第一の電子制御装置（カメラＥＣＵ）６の外部の第二の電子制御装置（自動運転ＥＣＵ）７に搭載された、図１４に示す軌道生成アプリケーションモジュール２２３、又は制御指令生成アプリケーションモジュール２２４である。第一のコア１１により起動されたペリフェラルアクセス部２０２は、図１に示したレジスタ３１に格納されたデータを、図１２に示した通信ドライバ２１を用いて取得し、図１２に示した通信データ保存部２８に格納する。

第一のコア１１に搭載されたデータ取得タスク２４の処理と同様に、第二のコア１２に搭載されたデータ取得タスク２４は、同じ第二のコア１２に搭載されたアプリケーションモジュールである画像認識アプリケーションモジュール（車両後方）２２２の実行に必要なデータを取得する役割を持つ。

第一のコア１１に搭載された画像認識アプリケーションモジュール（車両前方）２２１は、非特許文献１に開示された技術と同様に、データ取得タスク２４の完了後からデータ公開タスク２５の開始時刻の前までの間の任意の時刻に実行される。ただし、画像認識アプリケーションモジュール（車両前方）２２１が取得するデータのうち、異なる電子制御装置に搭載されたアプリケーションモジュールから取得したもの、すなわち外部から受信したデータが存在する場合がある。この場合、画像認識アプリケーションモジュール（車両前方）２２１は、処理を実行する前に、同じ第一のコア１１に搭載された通信準備処理部２０１をコールする。

コールされた通信準備処理部２０１は、図１２に示した通信データ保存部２８からデータを取り出し、Ｔｐ、ＰｄｕＲ、ＣＯＭ、Ｒｔｅ＿ｗｒｉｔｅ（）の順に処理し、アプリケーションデータ保存部２３にデータを保存する。なお、ここで説明する処理は、データの受信処理であるため、図１２に示したフローではＲｔｅ＿ｒｅａｄ（）ではなくＲｔｅ＿ｗｒｉｔｅ（）となる。この結果、通信データ保存部２８から取り出されたデータが画像認識アプリケーションモジュール（車両前方）２２１からアクセス可能となる。

また、画像認識アプリケーションモジュール（車両前方）２２１の処理完了後、画像認識アプリケーションモジュール（車両前方）２２１が生成したデータのうち、異なる電子制御装置に搭載されたアプリケーションモジュールに対してデータを公開する場合がある。このように外部（例えば、異なる電子制御装置）に公開するデータは、外部に送信される必要がある。そこで、第一のコア１１は、外部に送信される必要があるデータを引数として、通信準備処理部２０１を直ちにコールする。そして、通信準備処理部２０１は、図１２に示したようにＲｔｅ＿ｒｅａｄ（）、ＣＯＭ、ＰｄｕＲ、Ｔｐを順に処理し、Ｉｆにおいて該データを通信データ保存部２８に保存する。

第一のコア１１に搭載された画像認識アプリケーションモジュール（車両前方）２２１と同様に、第二のコア１２に搭載された画像認識アプリケーションモジュール（車両後方）２２２による処理が行われる。画像認識アプリケーションモジュール（車両後方）２２２による処理は、データ取得タスク２４のタスク処理の完了後からデータ公開タスク２５の開始時刻の前までの間の任意の時刻に実行される。

ただし、画像認識アプリケーションモジュール（車両後方）２２２が取得するデータのうち、異なる電子制御装置に搭載されたアプリケーションモジュールから取得したデータ、すなわち外部から受信したデータが存在する場合がある。この場合、画像認識アプリケーションモジュール（車両後方）２２２は、処理を実行する前に通信準備処理部２０１をコールする。このとき、通信準備処理部２０１は、通信データ保存部２８からデータを取り出し、図１２に示した処理の逆順でＴｐ、ＰｄｕＲ、ＣＯＭ、Ｒｔｅ＿ｗｒｉｔｅ（）を処理する。このような処理を経て、通信データ保存部２８から取り出したデータを画像認識アプリケーションモジュール（車両後方）２２２からアクセス可能とする。

また、画像認識アプリケーションモジュール（車両後方）２２２の処理が完了した後、画像認識アプリケーションモジュール（車両後方）２２２の生成したデータのうち、異なる電子制御装置に搭載されたアプリケーションモジュールに対してデータを公開する場合がある。このように外部（例えば、異なる電子制御装置）に送信する必要があるデータに関しては、第二のコア１２が該外部に送信する必要があるデータを引数として通信準備処理部２０１を直ちにコールする。そして、通信準備処理部２０１は、Ｒｔｅ＿ｗｒｉｔｅ（）、ＣＯＭ、ＰｄｕＲ、Ｔｐを順に処理し、Ｉｆにおいて該データを通信データ保存部２８に保存する。

ここで、非特許文献１に開示された技術では、第一のコア１１を通信専用としているため全ての通信処理が同一のコアで実行されていた。一方、データの送信及び受信の処理において、本実施形態に係る通信準備処理部２０１は、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２の処理の前後に、第一のコア１１と第二のコア１２によってそれぞれ実行される点に注意されたい。

第一のコア１１に搭載されたデータ公開タスク２５は、予め決められた時刻になると起動される。第一のコア１１に搭載されたデータ公開タスク２５は、同じ第一のコア１１に搭載されたアプリケーションモジュールである画像認識アプリケーションモジュール（車両前方）２２１の実行結果（アプリケーションデータ）を公開する役割を持つ。そして、アプリケーションデータ保存部２３は、同一の電子制御装置内にあるアプリケーションモジュールに公開するデータを、グローバル領域２３ｂに保存する。

また、第一のコア１１に搭載されたデータ公開タスク２５は、処理が完了すると、直ちにペリフェラルアクセス部２０２を起動する。ペリフェラルアクセス部２０２は、通信データ保存部２８に保存されたデータを取得し、図１２に示した通信ドライバ２１をコールして該データをペリフェラル３のレジスタ３１に書き込む。同様に、第二のコア１２に搭載されたデータ公開タスク２５は、予め決められた時刻になると起動される。

一方、第二のコア１２に搭載されたデータ公開タスク２５は、同じ第二のコア１２に搭載されたアプリケーションモジュールである画像認識アプリケーションモジュール（車両後方）２２２の実行結果を公開する役割を持つ。そこで、アプリケーションデータ保存部２３は、同一の電子制御装置内にあるアプリケーションモジュールに対して公開するデータをグローバル領域２３ｂに保存する。

なお、画像認識アプリケーションモジュール（車両後方）２２２は、外部送信データに関する通信準備処理部２０１を既に完了している。また、ペリフェラル３へのアクセスは全て、第一のコア１１に搭載されたペリフェラルアクセス部２０２により実行される。このため、第二のコア１２に搭載されたデータ公開タスク２５は、異なる電子制御装置内のアプリケーションモジュールに対して公開するデータに関しては特に処理を行わない。

＜非特許文献１に開示された技術と、本実施形態に係る技術との差分＞
次に、非特許文献１に開示された技術と、本実施形態に係る技術との差分について、図１５と図１６を参照して説明する。
図１５は、本実施形態に係るＬＥＴ及びＬＣＴを、本実施形態に係る各モジュール及びタスクに適用した例を示す図である。ここで、ＬＥＴ及びＬＣＴが適用される各モジュール及びタスクは、図１３と図１４に示したものである。以下に説明する通信準備処理部２０１及びペリフェラルアクセス部２０２がデータの受信処理を行う場合に（受信側）と付し、データの送信処理を行う場合に（送信側）と付す。

そして、送信側の電子制御装置（第一の電子制御装置（カメラＥＣＵ）６）が車載ネットワーク（車載ネットワーク４）にデータを送信する処理の完了時刻と、受信側の電子制御装置（第二の電子制御装置（自動運転ＥＣＵ）７）が車載ネットワーク（車載ネットワーク４）からデータを受信する処理の開始時刻とが規定されている。また、複数の電子制御装置（第一の電子制御装置（カメラＥＣＵ）６、第二の電子制御装置（自動運転ＥＣＵ）７）のそれぞれが有する起動時刻管理部（タスク起動時刻管理部２６）は、規定された完了時刻及び開始時刻に基づいて、複数の電子制御装置のそれぞれが有するペリフェラルアクセス部（ペリフェラルアクセス部２０２）を起動する。図１５に示すように、第一の電子制御装置（カメラＥＣＵ）６がデータを送信する処理の完了時刻と、第二の電子制御装置（自動運転ＥＣＵ）７がデータを受信する処理の開始時刻の間は、１００ミリ秒で固定されている。このため、第一の電子制御装置（カメラＥＣＵ）６と、第二の電子制御装置（自動運転ＥＣＵ）７における各処理の期間と、車載ネットワーク４にデータを送信する期間とを合わせることができる。

（１周期目）
＜データ取得タスク及びデータ公開タスクによる第１処理＞
第一の電子制御装置（カメラＥＣＵ）６では、１周期目が開始されるリードタイミングでデータ取得タスク２４が画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２に必要なデータ（例えば、カメラ画像データ９）を取得する。次に、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２がアプリケーション処理を行ってアプリケーションデータ（例えば、カメラ物体検知データ１０）を生成する。このように、第一のコア１１及び第二のコア１２には、それぞれ割り付けられた画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２が割り付けられているので、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２が同時にそれぞれのアプリケーション処理を実行できる。そして、データ公開タスク２５は、アプリケーションデータをアプリケーションデータ保存部２３のグローバル領域２３ｂに保存してアプリケーションデータを公開する。

＜ペリフェラルアクセス部及び通信準備処理部による第２処理＞
１周期目では、他の電子制御装置から受信した通信データに基づいた処理も行われる。
タスク起動時刻管理部２６により起動管理されるペリフェラルアクセス部２０２（受信側）は、リードタイミングでペリフェラル３にアクセスし、通信データを読み出すと、通信データ保存部２８に保存する。通信準備処理部２０１（受信側）は、通信データ保存部２８から読み出した通信データに対して、各アプリケーションモジュールが処理可能なアプリケーションデータに変換し、変換後のアプリケーションデータをアプリケーションデータ保存部２３に保存する。画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２は、アプリケーションデータ保存部２３から読み出したアプリケーションデータを用いてアプリケーション処理を実行する。

上記の第１及び第２の処理が完了すると、アプリケーションデータ保存部２３に処理後のアプリケーションデータが保存される。通信準備処理部２０１は、アプリケーションデータ保存部２３から読み出したアプリケーションデータの通信準備処理を行い、通信データ保存部２８に通信データを保存する。その後、ペリフェラルアクセス部２０２が通信データ保存部２８から通信データを読み出し、ライトタイミングでペリフェラル３のレジスタ３１に通信データを書き込む。ここで、第一の電子制御装置（カメラＥＣＵ）６におけるリードタイミングからライトタイミングまでは、１００ミリ秒で固定されている。

（２周期目）
車載ネットワーク４のバスでは、通信データの通信処理が行われ、第一の電子制御装置（カメラＥＣＵ）６のペリフェラル３から、第二の電子制御装置（自動運転ＥＣＵ）７のペリフェラル３に向けて通信データが送信される。

（３周期目）
３周期目の処理も１周期目の処理と同様に、データ取得タスク２４及びデータ公開タスク２５による第１処理、又はペリフェラルアクセス部２０２及び通信準備処理部２０１による第２処理が行われる。なお、３周期目の処理は、第二の電子制御装置（自動運転ＥＣＵ）７で行われるため、軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４がアプリケーション処理を実行する点が１周期目と異なる。

本実施形態に係る技術は、非特許文献１に開示された技術とは異なり、固定するタイミングをアプリケーションモジュールの開始時刻と終了時刻ではなく、アプリケーションモジュールと通信準備処理部２０１を合わせた処理の開始時刻と終了時刻とする。また、通信準備処理部２０１は第一のコア１１及び第二のコア１２の両方で実行される。したがって、図１１に示した１５０マイクロ秒のＣＰＵ処理時間を要していた通信処理のうち、１３０マイクロ秒分の処理が通信準備処理部２０１の処理として並列化される。

図１６は、第１の実施形態に係る技術と、非特許文献１に開示された技術とを比較したタイミングチャートである。

図１６の上側には、第１の実施形態に係る各処理のタイミングの例が示される。第一のコア１１と第二のコア１２の処理は同時に開始可能である。そして、第一のコア１１と第二のコア１２は、ＣＰＵによる通信処理を通信準備処理部（１３０マイクロ秒）とペリフェラルアクセス部（２０マイクロ秒）に分離する。

第一のコア１１のペリフェラルアクセス部２０２（受信側）は、２０マイクロ秒で受信処理を行う。その後、第一のコア１１と第二のコア１２は、通信準備処理部２０１（受信側）と通信準備処理部２０１（送信側）を並列処理とし、アプリケーション処理（画像認識アプリケーション（前方）と画像認識アプリケーション（後方））も並列で実行する。そして、第一のコア１１は、ペリフェラルアクセス部２０２（送信側）を一つのコアで実行する。このため、車載ネットワーク４で行われる通信処理は、ＣＰＵ１の処理を待たなくてよくなり、車載ネットワーク４の帯域の制限が解消される。

図１６の下側には、非特許文献１に開示された技術に係る各処理のタイミングの例が示される。非特許文献１に開示された技術では、図８と図９に示したように、通信専用の第一のコア１１と、アプリケーション専用の第二のコア１２に分離されている。このため、アプリケーション専用の第二のコア１２で順に、画像認識アプリケーション（車両前方）と画像認識アプリケーション（車両後方）の処理が行われた後、第一のコア１１で通信処理が行われる。そして、通信専用の第一のコア１１は、画像認識アプリケーション（車両前方）の処理データと、画像認識アプリケーション（車両後方）の処理データを順に車載ネットワーク４を介して第二の電子制御装置（自動運転ＥＣＵ）７に送信するための通信処理を行う。

ここで、通信専用の第一のコア１１で画像認識アプリケーション（車両前方）の処理データの通信処理が終わると、車載ネットワーク４で画像認識アプリケーション（車両前方）の処理データが通信される。しかし、車載ネットワーク４が、例えば、１ギガビットイーサネットのような高速大容量通信とした場合には、第一のコア１１が通信に要するＣＰＵ処理（１５０マイクロ秒）が、フレームデータが車載ネットワーク４のバスを流れている時間（８０マイクロ秒）よりも長い。このため、車載ネットワーク４では、通信専用の第一のコア１１が画像認識アプリケーション（車両後方）の処理データの通信処理を終えるまで処理待ちが発生する。通信専用の第一のコア１１における通信処理が終わると、車載ネットワーク４が、画像認識アプリケーション（車両後方）のフレームデータを車載ネットワーク４のバスに流すことができる。このように車載ネットワーク４の通信帯域には制限が生じてしまう。

以上説明した第１の実施形態に係る電子制御装置１００では、ＬＥＴとして固定するタイミングを、各アプリケーション処理部におけるアプリケーション処理の開始時刻と終了時刻ではなく、各アプリケーション処理部におけるアプリケーション処理の開始時刻から通信準備処理の終了時刻とする。そして、各コアには、通信準備処理部２０１をそれぞれ設けた。このようにＬＥＴを固定することにより、複数のコアで通信準備処理を同時に実行することができる。このため、従来は、一つのコアで通信準備処理を行った後、バスにフレームを送信していたので、あるアプリケーションモジュールによる通信準備処理が終わらなければ、別のアプリケーションモジュールによる通信準備処理が開始できず、結果としてフレームをバスに送信するまで待機時間が生じていた。そして、制御周期が短くなるほど、待機時間の発生により、バスに送信可能なデータ量が減少するトレードオフが発生していた。一方、本実施の形態に係る電子制御装置では、制御周期が短くなっても、バスに送信可能なデータ量を減少させなくてよい。また、複数の電子制御装置間で大量のデータ通信が必要な場合においても、ＬＥＴ（タイミング固定）を導入することが可能となるので、ソフトウェアの開発コストを削減する効果を有する。

また、上述したように第１の実施形態に係る電子制御装置１００では、ＬＥＴの開始時刻と終了時刻を固定する単位を、アプリケーションの処理と通信処理とするのではなく、アプリケーション処理と、通信準備処理及びペリフェラルアクセス処理とする。このため、処理の開始時刻と終了時刻の固定を保ちながら通信処理の大部分を各コア（演算処理部）において並列して実行することが可能となる。また、大量のデータ通信が必要な場合においても通信に関する処理の開始時刻から終了時刻までの時間延長が不要となるため、レイテンシ（通信遅延）を改善することが可能となる。

なお、第１の実施形態に係る電子制御装置１００は、標準的なＡＵＴＯＳＡＲを例に挙げて電子制御装置の構成及び処理の例を説明した。ただし、通信ミドルウェア２０は標準的なベーシックソフトウェアモジュールではなく、コンプレックスデバイスドライバでもよい。コンプレックスデバイスドライバは、ユーザが独自仕様で組み込み可能なソフトウェアである。

また、ＡＵＴＯＳＡＲ以外の一般的なリアルタイムオペレーティングシステムを搭載した電子制御装置においても本発明を適用可能である。

また、図１５に示したデータフローが保たれていることを検証するため、通信準備処理部２０１（送信側）は、送信時刻を示すタイムスタンプをフレームデータに付加してフレームの送信処理を行う。一方、通信準備処理部２０１（受信側）は、フレームの受信時に、受信したフレームに付加されたタイムスタンプを確認する処理を入れてもよい。

［第２の実施形態］
次に、本発明の第２の実施形態に係る電子制御装置の構成例及び処理方法について説明する。第２の実施形態に係る電子制御装置が第１の実施形態と異なる点は、通信ミドルウェア２０が軽量通信ドライバとなっている点である。なお、第１の実施形態と同様の構成については、同一の符号を付してその説明を省略する。

＜軽量通信ドライバ＞
軽量通信ドライバを実行可能な第一の電子制御装置（カメラＥＣＵ）６Ａ及び第二の電子制御装置（自動運転ＥＣＵ）７Ａの構成例について、図１７と図１８を参照して説明する。
図１７は、第２の実施形態に係る第一の電子制御装置（カメラＥＣＵ）６Ａにおけるソフトウェアアーキテクチャを示した図である。

演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）は一以上設けられ、演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２）がそれぞれアプリケーション処理部（アプリケーション処理部２２）を有する構成としてよい。図１７では、第一の電子制御装置（カメラＥＣＵ）６Ａは、通信処理及びアプリケーション処理に兼用される第一のコア１１だけを持つ構成として説明する。

第一のコア１１に対して、ＯＳ１９、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２、データ取得タスク２４、データ公開タスク２５、及び軽量通信ドライバ２９を割り付ける。ＯＳ１９には、タスク起動時刻管理部２６が割り付けられる。

図１８は、第２の実施形態に係る第二の電子制御装置（自動運転ＥＣＵ）７Ａにおけるソフトウェアアーキテクチャを示した図である。

第二の電子制御装置（自動運転ＥＣＵ）７Ａは、通信処理及びアプリケーション処理に兼用される第一のコア１１だけを持つ。
第一のコア１１に対して、ＯＳ１９、軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４、データ取得タスク２４、データ公開タスク２５、及び軽量通信ドライバ２９を割り付ける。ＯＳ１９には、タスク起動時刻管理部２６が割り付けられる。

図８と図９では通信専用の第一のコア１１に割り付けられた、データの送信及び受信を行うための通信ミドルウェア２０と通信ドライバ２１の例を示した。ここで、通信準備処理部（通信準備処理部２０１）とペリフェラルアクセス部（ペリフェラルアクセス部２０２）の実行に要する処理時間の合計が、他の電子制御装置との間で通信されるデータの通信時間よりも短い場合がある。例えば、データフレームが車載ネットワーク４のバスを流れている時間よりも、通信ミドルウェア２０と通信ドライバ２１のＣＰＵ処理時間の合計が短い場合がある。この場合、演算処理部（演算処理部１Ａ、第一のコア１１）は、通信準備処理部（通信データ保存部２０１）及びペリフェラルアクセス部（ペリフェラルアクセス部２０２）を一体化した軽量通信ドライバ（軽量通信ドライバ２９）とし、軽量通信ドライバ（軽量通信ドライバ２９）が通信データの送受信処理を行う。そこで、通信ミドルウェア２０と通信ドライバ２１を合わせて「軽量通信ドライバ」と呼ぶ。図１７と図１８に示した軽量通信ドライバ２９は、１つのコア（第一のコア１１）で連続して送受信処理を実行しても、図１６に示したようなＣＰＵの処理待ちが発生しない。

ただし、第２の実施形態では、通信準備処理部２０１とペリフェラルアクセス部２０２を分けなくてよい。また、データ取得タスク２４は、グローバル領域２３ｂにアクセスすることで、アプリケーションモジュールの処理に必要なデータを、同一の電子制御装置内の他のアプリケーションモジュールから取得する。

図１９は、本実施形態に係るＬＥＴ及びＬＣＴを、本実施形態に係る各モジュール及びタスクにマッピングした例を示す図である。ここで、ＬＥＴ及びＬＣＴをマッピングする各モジュール及びタスクは、図１７と図１８に示したものである。以下に説明する各モジュール及びタスクのうち、（受信側）と付した各モジュール及びタスクはデータの受信処理を担い、（送信側）と付した各モジュール及びタスクはデータの送信処理を担うものとする。

（１周期目）
第一の電子制御装置（カメラＥＣＵ）６Ａでは、１周期目が開始されるリードタイミングにマッピングされたデータ取得タスク２４がデータを取得する。次に、軽量通信ドライバ２９（受信側）が受信したデータの受信処理を行う。次に、画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２が処理を実行する。そして、１周期目が終了するライトタイミングで、データ公開タスク２５が処理後のデータをペリフェラル３のレジスタ３１に書き込み、軽量通信ドライバ２９（送信側）が車載ネットワーク４にデータを送信する送信処理を行う。

（２周期目）
車載ネットワーク４のバスでは、第一の電子制御装置（カメラＥＣＵ）６Ａから第二の電子制御装置（自動運転ＥＣＵ）７Ａに向けてデータが通信される。

（３周期目）
第二の電子制御装置（自動運転ＥＣＵ）７Ａでは、３周期目が開始されるリードタイミングにマッピングされたデータ取得タスク２４がデータを取得する。次に、軽量通信ドライバ２９（受信側）がデータの受信処理を行う。次に、軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４が処理を実行する。そして、３周期目が終了するライトタイミングで、データ公開タスク２５が処理後のデータをペリフェラル３のレジスタ３１に書き込み、軽量通信ドライバ２９（送信側）がデータの送信処理を行う。

図１９に示したように、データ取得タスク２４による処理の終了後は、タスク起動時刻管理部２６が直ちに軽量通信ドライバ２９をコールしてデータの受信処理を行う。そして、データ公開タスク２５はアプリケーションモジュールの処理結果をグローバル領域２３ｂに書き込むことにより同一電子制御装置内の他のアプリケーションモジュールに対してデータを公開する。また、データ公開タスク２５の処理の終了後は、タスク起動時刻管理部２６が直ちに軽量通信ドライバ２９をコールしてデータの送信処理を行う。

以上説明した第２の実施形態に係る電子制御装置１００では、コアが１つしか存在しない場合においても、タイミング固定によるソフトウェアの開発費削減を実現することができる。また、電子制御装置１００がマルチコアで構成される場合においても、非特許文献１に開示された技術と異なり、通信専用コアを設置する必要がない。このため、電子制御装置１００で使用するＣＰＵのコア数を削減することができる。このように、第２の実施形態に係る電子制御装置１００では、図８に示した通信ミドルウェア２０と通信ドライバ２１を改造することなく、また使用可能なコア数に制限がある場合においても、タイミング固定によるソフトウェアの開発費削減が実現される効果を有する。

［第３の実施形態］
次に、本発明の第３の実施形態に係る電子制御装置の構成例及び処理方法について、図２０～図２１を参照して説明する。
第３の実施形態に係る電子制御装置が、第１の実施形態に係る電子制御装置と異なる点は、第一の電子制御装置に搭載されたアプリケーションモジュールを、第二の電子制御装置に搭載するように変更した点である。なお、第１の実施形態と同様の構成については、同一の符号を付してその説明を省略する。
図２０は、第３の実施形態に係る第三の電子制御装置（セントラルＥＣＵ）７１を搭載した車両制御装置５Ａの構成例を示した図である。

＜車両制御装置５Ａ＞
車両制御装置５Ａは、第二の電子制御装置（自動運転ＥＣＵ）７の代わりに第三の電子制御装置（セントラルＥＣＵ）７１を備える。
第三の電子制御装置７１は、中央コンピュータであって、ＡＩ（Artificial Intelligence）や画像処理など、負荷の重い演算を担うため、計算性能が重視された電子制御装置が用いられる。第三の電子制御装置（セントラルＥＣＵ）７１に対して、不図示のゾーンＥＣＵが設けられる。ゾーンＥＣＵは、車両を区分けしたゾーンごとにセンサ制御、アクチュエータ制御などの負荷の軽い演算を担っており、安全性が重視された電子制御装置が用いられる。

車両制御装置５Ａに含まれる第一の電子制御装置（カメラＥＣＵ）６Ｂは、第１の実施形態と異なり、カメラ８から取得したカメラ画像データ９を予め決められた時刻に車載ネットワーク４に送信する役割のみを持つ。第一の電子制御装置（カメラＥＣＵ）６Ｂにより車載ネットワーク４に送信されたカメラ画像データ９は、第三の電子制御装置（セントラルＥＣＵ）７１が受信する。

第三の電子制御装置（セントラルＥＣＵ）７１は、カメラ画像データ９に基づいて、ステアリング制御指令１３、アクセル制御指令１４及びブレーキ制御指令１５を生成する。そして、第三の電子制御装置（セントラルＥＣＵ）７１は、各指令を出力することで、ステアリング１６、アクセル１７及びブレーキ１８の動作を制御する。

また、第三の電子制御装置（セントラルＥＣＵ）７１は、公知のＯＴＡ（Over the air）技術によって、第三の電子制御装置（セントラルＥＣＵ）７１で動作するソフトウェアを更新可能である。

図２１は、本実施形態に係る第三の電子制御装置（セントラルＥＣＵ）７１におけるソフトウェアアーキテクチャを示した図である。

第３の実施形態に係る複数の電子制御装置の一つ（第三の電子制御装置（セントラルＥＣＵ）７１）は、複数の演算処理部（演算処理部１Ａ，１Ｂ、３つのコア（第一のコア１１、第二のコア１２及び第三のコア７２））を有する。第一のコア１１、第二のコア１２及び第三のコア７２は、いずれもアプリケーションと通信の兼用とする。複数の演算処理部（演算処理部１Ａ，１Ｂ、第一のコア１１、第二のコア１２及び第三のコア７２）のそれぞれに一つ以上のアプリケーション処理部（アプリケーション処理部２２）が設けられる。そして、複数の演算処理部の一つ（第一のコア１１）に、アプリケーション処理部（アプリケーション処理部２２）の機能を更新する更新部（ソフトウェア更新部７３）を有する。

第一のコア１１には、図１４に示した第１の実施形態に係る第二の電子制御装置（自動運転ＥＣＵ）７に搭載されていた軌道生成アプリケーションモジュール２２３、ＯＳ１９、データ取得タスク２４、データ公開タスク２５、通信準備処理部２０１、ペリフェラルアクセス部２０２が割り付けられる。第一のコア１１のＯＳ１９は、タスク起動時刻管理部２６を実行可能である。また、第一のコア１１には、新たにソフトウェア更新部７３が割り付けられる。

第二のコア１２には、図１４に示した第１の実施形態に係る第二の電子制御装置（自動運転ＥＣＵ）７に搭載されていた制御指令生成アプリケーションモジュール２２４、ＯＳ１９、データ取得タスク２４、データ公開タスク２５及び通信準備処理部２０１が割り付けられる。第二のコア１２のＯＳ１９は、タスク起動時刻管理部２６を実行可能である。

第三のコア７２には、図１３に示した第１の実施形態に係る第一の電子制御装置（カメラＥＣＵ）６に搭載されていた画像認識アプリケーションモジュール（車両前方）２２１及び画像認識アプリケーションモジュール（車両後方）２２２、ＯＳ１９、データ取得タスク２４、データ公開タスク２５及び通信準備処理部２０１が割り付けられる。

第一のコア１１に搭載されるソフトウェア更新部７３は、ＯＴＡ（Over the air）技術によって、第三の電子制御装置（セントラルＥＣＵ）７１に搭載されたアプリケーションモジュールを更新可能である。すなわち、ソフトウェア更新部７３は、画像認識アプリケーションモジュール（車両前方）２２１、画像認識アプリケーションモジュール（車両後方）２２２、軌道生成アプリケーションモジュール２２３及び制御指令生成アプリケーションモジュール２２４を更新する役割をもつ。

ソフトウェア更新部７３が行うソフトウェア更新は、通常は、各アプリケーションモジュールの起動時か、終了後に実施される。多くのコンピュータでは、マスターコアとスレーブコアが指定され、マスターコアがスレーブコアを含めてソフトウェアの更新を実施する。マスターコアのコア番号は「０」であることが多い。このため、第一のコア１１をマスターコアとすると、ソフトウェア更新部７３は、第一のコア１１で実行される。このソフトウェア更新部７３は、軌道生成アプリケーションモジュール２２３、制御指令生成アプリケーションモジュール２２４もアップデートすることは可能である。

ソフトウェア更新部７３は、自動運転における軌道生成アプリケーションモジュール２２３、制御指令生成アプリケーションモジュール２２４の機能を随時アップデートすることが可能となる。また、ソフトウェア更新部７３は、カメラ画像データ９に対して行われる画像認識アプリケーションモジュール２２１，２２２の画像処理機能についてもアップデートを行うことで、各モジュールの画像認識の性能を改善することが可能となる。

第１の実施形態においては、第一の電子制御装置（カメラＥＣＵ）６から第二の電子制御装置（自動運転ＥＣＵ）７に送信されるデータはカメラ物体検知データ１０であった。一方、第３の実施形態においては、第一の電子制御装置（カメラＥＣＵ）６Ｂから第三の電子制御装置（セントラルＥＣＵ）７１に送信されるデータはカメラ画像データ９である。第３の実施形態では、第１の実施形態のような第一の電子制御装置（カメラＥＣＵ）６から第二の電子制御装置（自動運転ＥＣＵ）７に車載ネットワーク４を通じてカメラ物体検知データ１０を送信する処理が不要となる。このため、第三の電子制御装置（セントラルＥＣＵ）７１が画像認識後、自動運転のための軌道生成及び制御指令生成を行う処理が短縮され、車両の速やかな運転制御が可能となる。

また、図４を参照して説明したように、カメラ画像データ９のデータサイズは数メガバイト程度あるため、非特許文献１に開示された技術では通信帯域に制限が生じていたためカメラ画像データ９を送受信することは不可能であった。一方、第３の実施形態に係る技術では、通信帯域に制限が生じないため、このようなアプリケーションモジュールの配置が可能となる。

以上説明した第３の実施形態に係る車両制御装置５Ａでは、第１の実施形態に係る車両制御装置５において第一の電子制御装置（カメラＥＣＵ）６と第二の電子制御装置（自動運転ＥＣＵ）７に分散して搭載されていた各アプリケーションモジュールが一つの第三の電子制御装置（セントラルＥＣＵ）７１に統合される。そして、ソフトウェア更新部７３により任意のタイミングでアプリケーションモジュールの機能が更新される。このため、機能が向上したアプリケーションモジュールを用いて、画像認識、車両の運転制御の精度を高めることができる。

また、本発明はタイミング固定によるソフトウェア開発コスト削減を目的としたものである。そして、アプリケーションモジュールの更新により、更新前後で各アプリケーションモジュールの入力及び出力のタイミングが変動する可能性が排除される。このため、ＯＴＡによるソフトウェア更新は、第３の実施形態に係る第三の電子制御装置（セントラルＥＣＵ）７１に対して特に有用となる。

このため、第３の実施形態に係る車両制御装置５Ａでは、車両内のアプリケーションモジュールの配置を柔軟に変えることができる。また、複数の電子制御装置を統合し、複数のアプリケーションモジュールの更新を容易に実行可能とする効果を有する。

なお、本発明は上述した各実施形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した各実施形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施形態の構成の一部を他の実施形態の構成に置き換えることは可能であり、さらにはある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１…ＣＰＵ、１Ａ，１Ｂ…演算処理部、２…ＲＡＭ、２Ａ…データ保存部、３…ペリフェラル、４…車載ネットワーク、５…車両制御装置、６…第一の電子制御装置（カメラＥＣＵ）、７…第二の電子制御装置（自動運転ＥＣＵ）、１１…第一のコア、１２…第二のコア、１９…ＯＳ、２２…アプリケーション処理部、２３…アプリケーションデータ保存部、２４…データ取得タスク、２５…データ公開タスク、２６…タスク起動時刻管理部、２８…通信データ保存部、１００…電子制御装置、２０１…通信準備処理部、２０２…ペリフェラルアクセス部、２２１～２２４…アプリケーションモジュール

Claims (11)

1. アプリケーション処理を行うアプリケーション処理部を有する演算処理部と、
   前記演算処理部で処理されるデータを保存するデータ保存部と、
   前記データ保存部から読み出した前記データを他の電子制御装置に送信し、又は他の前記電子制御装置からデータを受信するペリフェラルと、を備え、
   前記演算処理部が前記アプリケーション処理のために前記データ保存部に前記データを入出力する第１タイミングと、前記演算処理部が前記データ保存部から読み出した前記データを前記ペリフェラルに渡して、前記ペリフェラルが他の前記電子制御装置に前記データを送信する第２タイミングとが予め固定される
   電子制御装置。
2. 前記演算処理部は、前記アプリケーション処理部と、前記アプリケーション処理により生成されたアプリケーションデータの通信準備を行う通信準備処理部とを有し、
   前記データ保存部は、前記アプリケーションデータを保存するアプリケーションデータ保存部と、前記通信準備処理部により生成された通信データを保存する通信データ保存部とを有し、
   少なくとも一つの前記演算処理部は、前記通信データ保存部及び前記ペリフェラルにアクセスするペリフェラルアクセス部と、前記ペリフェラルアクセス部とを起動する起動時刻を管理する起動時刻管理部とを有し、
   前記起動時刻管理部は、予め決められた内部時刻に基づいて、前記第１タイミングで前記アプリケーション処理部を動作させ、前記第２タイミングで前記ペリフェラルアクセス部を動作させる
   請求項１に記載の電子制御装置。
3. 前記第１タイミングは、前記アプリケーション処理部が前記アプリケーションデータ保存部に対して前記データを入出力するタイミングとして固定され、
   前記第２タイミングは、前記ペリフェラルアクセス部が前記通信データ保存部に保存された前記通信データを前記ペリフェラルに転送するタイミングとして固定される
   請求項２に記載の電子制御装置。
4. 前記内部時刻は、外部から受信する時刻同期用の信号により補正される
   請求項３に記載の電子制御装置。
5. 前記アプリケーションデータ保存部は、それぞれの前記アプリケーション処理部が前記アプリケーション処理の途中のデータを一時的に保存する領域として、処理を実行している前記アプリケーション処理部だけが使用するローカル領域と、前記アプリケーション処理部が処理を完了した結果のデータを保存し、他の前記アプリケーション処理部に前記データを使用可能に公開するグローバル領域と、を有し、
   前記アプリケーション処理部は、前記第１タイミングで前記グローバル領域にアクセスする
   請求項４に記載の電子制御装置。
6. 前記演算処理部は、予め決められた内部時刻に基づいて、前記通信準備処理部、前記ペリフェラルアクセス部の順に起動して、前記通信準備処理部が前記通信データ保存部に前記通信データを保存する処理と、前記ペリフェラルアクセス部が前記通信データ保存部から読み出した前記通信データであって、前記ペリフェラルが他の前記電子制御装置に送信するデータを前記ペリフェラルに格納する処理とを行い、
   予め決められた内部時刻に基づいて、前記ペリフェラルアクセス部、前記通信準備処理部の順に起動して、前記ペリフェラルが他の前記電子制御装置から受信したデータを前記ペリフェラルアクセス部が取得し、前記通信データ保存部に書き込む処理と、前記通信準備処理部が前記通信データ保存部から読み出した前記通信データを前記アプリケーションデータ保存部に書き込む処理とを行う
   請求項５に記載の電子制御装置。
7. 前記通信準備処理部は、ＡＵＴＯＳＡＲ（登録商標）に規定されるサービスレイヤとハードウェア抽象化レイヤであり、
   前記ペリフェラルアクセス部は、ＡＵＴＯＳＡＲに規定されるドライバであり、
   前記通信データ保存部は、前記ハードウェア抽象化レイヤと、前記ドライバとの間に設けられる
   請求項３に記載の電子制御装置。
8. 前記通信準備処理部と前記ペリフェラルアクセス部の実行に要する処理時間の合計が、他の前記電子制御装置との間で通信される前記データの通信時間よりも短い場合に、前記演算処理部は、前記通信準備処理部及び前記ペリフェラルアクセス部を一体化した軽量通信ドライバとし、前記軽量通信ドライバが前記通信データの送受信処理を行う
   請求項３に記載の電子制御装置。
9. 複数の前記演算処理部の一つに、前記アプリケーション処理部の機能を更新する更新部を有する
   請求項３に記載の電子制御装置。
10. 複数の前記電子制御装置は、前記ペリフェラルを通じて互いに車載ネットワークにより前記データの通信を行い、
    送信側の前記電子制御装置が前記車載ネットワークに前記データを送信する処理の完了時刻と、受信側の前記電子制御装置が前記車載ネットワークから前記データを受信する処理の開始時刻とが規定され、
    複数の前記電子制御装置のそれぞれが有する起動時刻管理部は、規定された前記完了時刻及び前記開始時刻に基づいて、複数の前記電子制御装置のそれぞれが有するペリフェラルアクセス部を起動する
    請求項３に記載の電子制御装置。
11. 複数の前記電子制御装置の一つは、カメラが撮像したカメラ画像データから物体検知を行った結果であるカメラ物体検知データを前記車載ネットワークに送信し、
    複数の前記電子制御装置の一つは、前記カメラ物体検知データに基づいて、車両の制御対象であるステアリングの目標角度の制御指令値、アクセルの目標加速力の制御指令値、及びブレーキの目標減衰力の制御指令値のうち、少なくとも一つを生成して前記制御対象に前記制御指令値を送信する
    請求項１０に記載の電子制御装置。

Images