JP7149189B2

JP7149189B2 - 演算装置、演算方法

Info

Publication number: JP7149189B2
Application number: JP2019003818A
Authority: JP
Inventors: 雄介宇治土公; 勇樹堀田
Original assignee: Hitachi Astemo Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2019-01-11
Filing date: 2019-01-11
Publication date: 2022-10-06
Anticipated expiration: 2039-01-11
Also published as: WO2020145057A1; JP2020113080A

Description

本発明は、演算装置、および演算方法に関する。

近年、自動運転を実現する制御アプリケーションの機能高度化に伴い、アプリケーションの演算量が増加傾向にある。演算量が増加しつつあるアプリケーションを実時間で実行するためには、複数の演算コア上でアプリケーションを並列的に実行するスケジューリング、すなわちデータ並列化やパイプライン並列化などを行う必要がある。特許文献１には、それぞれの演算に必要なデータ数が演算単位データ数として定められており、それぞれが異なる演算を実行してデータを生成する複数の演算部と、演算部毎に、演算単位データ数を記憶するデータ数記憶部と、前記複数の演算部の中から、いずれかの演算部を、先行して演算を実行する先行演算部として選択し、他のいずれかの演算部を、前記先行演算部により生成されるデータを用いて演算を実行する後続演算部として選択する選択部と、前記選択部により選択された先行演算部が生成したデータを蓄積するデータ蓄積部と、前記データ蓄積部に蓄積されるデータのデータ数を監視し、前記データ蓄積部のデータ数が前記後続演算部の演算単位データ数に達した際に、前記データ蓄積部に蓄積されているデータを前記データ蓄積部から前記後続演算部に出力させるデータ監視部とを備えることを特徴とするデータ処理装置が開示されている。

特開２０１３－１１４３９１号公報

アプリケーションのスケジューリングを設計して演算器の性能をチューニングするためには、複数の並列化手法を単独で、および複数を組み合わせて試行することが必要である。そして試行結果に合わせて、アプリケーション間のデータの入出力の設計も必要となる。演算実行の性能チューニングのためには、スケジューリング設計の方針変更を反復することとなるが、その反復のたびに、データ入出力設計も合わせて反復せざるを得ない。特許文献１に記載されている発明では、データ入出力の変更に合わせてアプリケーションを再度作成する必要がある。

本発明の第１の態様による演算装置は、所定の対象要素に対応するデータ要素の集合であるオブジェクトデータ、および前記オブジェクトデータの出力方式に関する設定情報が格納される記憶部と、前記オブジェクトデータを管理するデータ管理部と、前記データ管理部から取得される前記オブジェクトデータである入力オブジェクトデータに基づいて前記オブジェクトデータである出力オブジェクトデータを演算し、前記出力オブジェクトデータを前記データ管理部に出力するソフト部品を複数備える実行制御部と、を備え、前記設定情報は、第１ソフト部品に対する前記入力オブジェクトデータであり第２ソフト部品が出力する前記出力オブジェクトデータと、前記第２ソフト部品が出力する前記出力オブジェクトデータを前記第１ソフト部品に対して出力する際の出力方式と、が対応付いた情報であり、前記データ管理部は、前記第２ソフト部品から受け取った前記オブジェクトデータを管理し、前記オブジェクトデータを、前記設定情報に規定された出力方式に基づき、前記第１ソフト部品に出力する。
本発明の第２の態様による演算方法は、所定の対象要素に対応するデータ要素の集合であるオブジェクトデータ、および前記オブジェクトデータの出力方式に関する設定情報が格納される記憶部にアクセス可能であり前記オブジェクトデータを管理するデータ管理部を備える演算装置が実行する演算方法であって、前記データ管理部から取得される前記オブジェクトデータである入力オブジェクトデータに基づいて前記オブジェクトデータである出力オブジェクトデータを演算し、前記出力オブジェクトデータを前記データ管理部に出力するソフト部品を複数備えることと、前記設定情報は、第１ソフト部品に対する前記入力オブジェクトデータであり第２ソフト部品が出力する前記出力オブジェクトデータと、前記第２ソフト部品が出力する前記出力オブジェクトデータを前記第１ソフト部品に対して出力する際の出力方式と、が対応付いた情報であり、前記データ管理部は、前記第２ソフト部品から受け取った前記オブジェクトデータを管理し、前記オブジェクトデータを、前記設定情報に規定された出力方式に基づき、前記第１ソフト部品に出力することとを含む。

本発明によれば、アプリケーションを変更することなくデータ入出力の変更に対応できる。

第１の実施の形態における車両制御システム１の構成を示すブロック図処理部１００の構成図アプリケーション入出力データ群１１１の一例を示す図設定情報群１１２の一例を示す図演算装置１０の動作例Ａを示す図演算装置１０の動作例Ｂを示す図演算装置１０の動作例Ｃを示す図データ管理部１０４のデータ入力処理を示すフローチャート図８のステップＳ７０４の詳細を示すフローチャートデータ管理部１０４のデータ出力処理を示すフローチャートデータ操作インタフェース２０１が解釈可能なＡＰＩの一例を示す図アプリケーションの記述様式の一例として擬似コード１０００を示す図対応表１１５の一例を示す図実行制御部１０２の設定情報切替処理を示すフローチャート第２の実施の形態における車両制御システム１Ａの構成を示すブロック図

―第１の実施の形態―
以下、図１～図１２を参照して、演算装置の第１の実施の形態を説明する。

（システム構成）
図１は、本発明に係る演算装置１０を含む車両制御システム１の構成を示すブロック図である。車両制御システム１は、演算装置１０、外界センサ群２０、車両センサ群３０、およびアクチュエータ群４０を備える。本実施の形態では、車両制御システム１は、車両９に搭載される。演算装置１０、外界センサ群２０、車両センサ群３０、およびアクチュエータ群４０は、車載ネットワーク５０により接続される。車両制御システム１は、車両９に搭載され、車両９の周辺における走行道路や周辺車両等の障害物の状況を認知した上で車両９の運転行動や車両制御を判断し、車両運動を制御することで自動運転を実現するシステムである。なお以下では、車両９を他の車両を区別する意味で「自車両」９と呼ぶこともある。

外界センサ群２０は、車両周辺の一定範囲の障害物、たとえば他車両、歩行者、物体などや、道路標識や白線などの特徴物を認識するセンサ群である。外界センサ群２０は、たとえば、カメラ、レーダ、ライダ等により構成される。外界センサ群２０は、検出した車両周辺の障害物や特徴物の情報、たとえば車両９からの相対距離と相対角度などを、外界センサ群２０や演算装置１０が接続されている車載ネットワーク５０に出力する。演算装置１０は、この車載ネットワーク５０を介して外界センサ群２０からの出力結果を取得できるように構成されている。なお本実施の形態では、外界センサ群２０で障害物や特徴物を検出する処理を実施する構成になっているが、外界センサ群２０から出力される信号やデータを用いて演算装置１０や他装置でこれらの検出処理を行ってもよい。

車両センサ群３０は、車両９の動きに関する情報、たとえば走行速度、操舵角、アクセルの操作量、ブレーキの操作量などを検出する装置群である。車両センサ群３０を構成するセンサは、「内界センサ」とも呼ばれる。車両センサ群３０は、たとえば、車載ネットワーク５０上に検出したこれらの状態量を出力する。車載ネットワーク５０に接続された演算装置１０や他装置は、この車載ネットワーク５０を通じて、車両センサ群３０から出力された各種部品の状態量を取得する。

アクチュエータ群４０は、車両９の動きを決定する操舵、ブレーキ、アクセル等の制御要素を制御する装置群である。アクチュエータ群４０は、運転者によるハンドル、ブレーキペダル、アクセルペダル等の操舵情報や、演算装置１０から出力される目標制御値に基づいて車両９の動きを制御する。

（演算装置の構成）
演算装置１０は、たとえばＥＣＵ（ＥｌｅｃｔｒｏｎｉｃＣｏｎｔｒｏｌＵｎｉｔ）であり、処理部１００と、記憶部１１０と、通信部１２０とを備える。なお演算装置１０の形態に特に制限はない。たとえば、演算装置１０は、外界センサ群２０に統合されてもよい。

処理部１００は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ：中央演算処理装置）、およびＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）を備え、ＣＰＵが記憶部１１０に格納された不図示のプログラムをＲＡＭに展開して実行することにより以下の機能を実現する。車両制御システム１には１つ以上のＣＰＵが搭載され、これらのＣＰＵ上で並列的にプログラムが実行される。処理部１００はその機能として、センサ入力部１０１、実行制御部１０２、アクチュエータ出力部１０３、およびデータ管理部１０４を備える。処理部１００は、演算装置１０に外部から停止命令が入力されると、センサ入力部１０１、実行制御部１０２、アクチュエータ出力部１０３、およびデータ管理部１０４に停止指令を出力する。

センサ入力部１０１は、車両９の周辺に関連する周辺環境情報と、車両９の動きに関連する車両センサ情報とを取得して、これらを「出力値」として後述するアプリケーション入出力データ群１１１に格納する。センサ入力部１０１は、出力値を外界センサ群２０および車両センサ群３０から取得する。周辺環境情報とは、たとえば車両９の周辺に存在する障害物の情報や、車両９の周辺における道路の特徴を示す特徴物等の情報等である。なお車両９の周辺に存在する障害物とは、たとえば車両９の周囲を移動している他車両、自転車、歩行者等の移動体や、車両９の周囲の道路上で静止している駐車車両、落下物、設置物等である。車両センサ情報とは、たとえば車両９の位置、走行速度、操舵角、アクセルの操作量、ブレーキの操作量等である。センサ入力部１０１により取得された周辺環境情報と車両センサ情報は、アプリケーション入出力データ群１１１として記憶部１１０に格納される。

実行制御部１０２は、演算装置１０上の１つ以上のＣＰＵ上で実行する各アプリケーションを実行する。実行制御部１０２は、記憶部１１０の設定情報群１１２に格納されているアプリケーションの実行スケジューリングの情報、およびスレッド数情報群１１３に格納されているアプリケーションごとのスレッド数の情報に基づいてアプリケーションを実行する。実行スケジューリングの情報とは、アプリケーションを逐次的または並列的に動作させるときの動作開始や終了のタイミング、および動作周期等が定義されたものである。たとえば、周期が１０ｍｓと設定されたアプリケーションに対しては、実行制御部が１０ｍｓで当該アプリケーションを実行する。またたとえば、データ並列化が設定されたアプリケーションに対しては、１つ以上のＣＰＵ上でアプリケーションを決められたタイミングで実行する等の制御を実行制御部１０２が行う。

アクチュエータ出力部１０３は、アプリケーション入出力データ群１１１から制御情報を取得し、車載ネットワーク５０に接続されたアクチュエータ群４０に対して出力する。

データ管理部１０４は、アプリケーション間でのデータ入出力を制御する。換言するとデータ管理部１０４は、異なるアプリケーション間でのデータ入出力を制御する。アプリケーション間で入出力されるデータは、アプリケーション入出力データ群１１１として集約的に管理されるが、アプリケーション入出力データ群１１１への全てのデータ入出力はデータ管理部１０４を介して行われる。

データ管理部１０４によるデータの制御は、設定情報群１１２に基づいて行われる。したがって、アプリケーション間のデータ入出力の設計を変更する際には、設定情報群１１２のみを変更するだけよい。データ管理部１０４は、アプリケーションとセンサ入力部の間、およびアプリケーションとアクチュエータ出力部の間においてもデータ入出力の制御を行ってもよく、これらも入出力制御の対象とする。

記憶部１１０は、たとえば、ＨＤＤ（ＨＡＲＤＤｉｓｋＤｒｉｖｅ）やフラッシュメモリである。ただしＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）を含んで構成されてもよい。記憶部１１０には、処理部１００がその機能を実現するために実行するプログラム、周期的に実行されるアプリケーション、および演算装置１０が動作するために必要なデータ群などが格納される。具体的には、記憶部１１０には、アプリケーション入出力データ群１１１、アプリケーション間の設定情報群１１２、スレッド数情報群１１３、およびアプリケーション群１１４が格納される。

アプリケーション群１１４は任意の複数のアプリケーションが含まれる。アプリケーション群１１４を構成するアプリケーションは任意であるが、たとえばＡＤＡＳ（Advanced Driver-Assistance Systems、先進運転支援システム）や自動運転向けの制御プログラムである。自動運転向けの制御プログラムはたとえば、センサフュージョンアプリ、地図フュージョンアプリ、行動予測アプリ、および軌道生成アプリなどである。

アプリケーション入出力データ群１１１には、アプリケーションに入力される情報、およびアプリケーションから出力される情報が格納される。具体的にはアプリケーション入出力データ群１１１には、車両９の周辺に関連する周辺環境情報や、車両９の動きに関連する車両センサ情報、およびアプリケーションがそれらを処理した情報が格納される。

本実施の形態では、アプリケーション入出力データ群１１１に格納される、所定の対象要素に対応するデータの集合を「オブジェクトデータ」と呼称し、このオブジェクトデータを単位としてデータの管理及び操作を行う。「対象要素」とは、オブジェクトデータとして一纏めにした個々の情報要素が共通して表現する概念的な対象である。「対象要素」はたとえば、外界センサ群２０や車両センサ群３０の検出対象やアクチュエータの制御対象、およびアプリケーションの演算処理結果が該当する。

外界センサ群２０を構成するセンサにおいては、認識された個々の環境要素（障害物、道路形状、交通ルール等）が対象要素に該当することが望ましい。すなわち、外界センサ群２０を構成する各センサというハードウェアそのものを抽象化するのではなく、検出対象である環境要素を単位として、データを抽象化する方式を採る。なお、車両センサ群３０を構成する各センサについては、自車両９という概念でオブジェクトデータを構成してもよいし、個々の検出対象ごと、たとえば車速センサであれば車速情報ごとにオブジェクトデータを構成してもよい。

本実施の形態ではこれ以降、オブジェクトデータを「データ」と呼ぶ。あるデータがアプリケーション入出力データ群１１１へ入出力される際には、そのデータの入力元のアプリケーションと出力先のアプリケーション、およびそのデータの種類に基づいてアプリケーション入出力データ群１１１内でデータ管理部１０４が管理する。

設定情報群１１２には、演算装置１０において実行されるアプリケーションのうちの、特定の２つのアプリケーション間で入出力されるデータの入出力の設定情報が記載されている。アプリケーション間で入出力されるデータの入出力の設定情報とは、たとえば、配列データの中で出力する要素の数やデータ出力のタイミングなどである。データ管理部１０４は、設定情報群１１２を利用して、アプリケーション間のデータの入出力を制御する。

通信部１２０は各種通信プロトコルに基づいて車両９に搭載された他の装置と通信する。通信部１２０は、たとえば、ＩＥＥＥ８０２．３またはＣＡＮ（ＣｏｎｔｒｏｌｌｅｒＡｒｅａＮｅｔｗｏｒｋ）等の通信規格に準拠したネットワークカードを含んで構成される。なお、通信部１２０と車両９に搭載された他の装置との間の接続形態は、Ｅｔｈｅｒｎｅｔのような有線接続に限定されることはなく、Ｂｌｕｅｔｏｏｔｈ（登録商標）や無線ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）などの近距離無線接続であってもよい。

図２は、本実施形態の処理部１００の構成図である。前述のとおり、処理部１００は、実行制御部１０２、データ管理部１０４、センサ入力部１０１、およびアクチュエータ出力部１０３を備える。

実行制御部１０２はアプリケーション群１１４に含まれる２つ以上のアプリケーションの実行を制御する。本実施の形態では一例として、実行制御部１０２が実行を制御するアプリケーションをセンサフュージョンアプリ１０２Ａ、地図フュージョンアプリ１０２Ｂ、行動予測アプリ１０２Ｃ、および軌道生成アプリ１０２Ｄの４つとして説明をする。これらのアプリケーションはセンサ入力部１０１が出力した出力データや、他のアプリケーションの入出力データにアクセスする際には、データ管理部の備えるデータ操作ＩＦ２０１を介して行う。

センサ入力部１０１は、カメラやレーダなどの各センサに対応する構成として、センサＡ入力部１０１Ａ、センサＢ入力部１０１Ｂなどの構成要素を内部に１つ以上備える。このセンサ入力部１０１は、各センサからの入力をセンサデータとして取得してもよいし、取得したセンサデータに対して何らかの演算を行ってもよい。

アクチュエータ出力部１０３は各アクチュエータに対応する構成として、アクチュエータＡ出力部１０３Ａ、アクチュエータＢ出力部１０３Ｂなどの構成要素を内部に１つ以上備える。アクチュエータ出力部１０３は、データ管理部１０４から出力されるデータをそのままアクチュエータに対して出力してもよいし、データ管理部１０４から出力されるデータに何らかの演算を行った結果を出力してもよい。

センサ入力部１０１やアクチュエータ出力部１０３の各構成要素がアプリケーション入出力データ群１１１にアクセスする際にも、データ管理部１０４の備えるデータ操作インタフェース２０１を介して行う。このようにアプリケーションやセンサ入力部１０１、およびアクチュエータ出力部１０３はデータ管理部１０４の備えるデータ操作インタフェース２０１を介してアプリケーション入出力データ群１１１にアクセスする構成となっている。

本実施の形態では、アプリケーションやセンサ入力部、およびアクチュエータ出力部の各構成部品をまとめて、抽象化した概念としてソフトウエアの一部分とみなして「ソフト部品」と呼称する。上述したように、ソフト部品はデータ管理部１０４の備えるデータ操作インタフェース２０１を介してアプリケーション入出力データ群１１１にアクセスする。

データ管理部１０４は、アプリケーションやセンサ入力部１０１、アクチュエータ出力部１０３へ入出力するデータをアプリケーション入出力データ群１１１として集約管理する。このように、データをすべてデータ管理部１０４が集約管理し、データ入出力のための共通インタフェースとして、データ操作インタフェースを介してアクセスさせる構成とすることで、次の利点がある。すなわち、アプリケーションのデータ入出力の制御は、データ管理部１０４の内部に隠蔽される。

実行制御部１０２により実行される各アプリケーションは、共通のインタフェースであるデータ操作インタフェース２０１を活用することにより次の利点がある。すなわち各アプリケーションは、データ入出力の設計が変更されたとしても、アプリケーションそのものを修正してインタフェースを変更する必要がない。換言すると各アプリケーションは、アプリケーションを修正することなく、様々なデータ入出力に対応することができる。

（アプリケーション入出力データ群１１１）
図３は、アプリケーション入出力データ群１１１の一例を示す図である。アプリケーション入出力データ群１１１は、データ管理部１０４が記憶部１１０上で管理しているデータの集合である。アプリケーション入出力データ群１１１は１以上のデータから構成され、各データにはデータ種類３０１、データＩＤ３０２、タイムスタンプ３０３、およびデータ固有属性群３０４が含まれる。

データ種類３０１は、各データの概念的な種別を示す。データ種類３０１はたとえば、他車両、歩行者、白線、標識などである。データＩＤ３０２は、データ種類３０１を共通に持つデータ群の中で対象のデータを一意に特定するための識別子である。同一の対象要素、たとえば同一の車両を示すと判断される場合は、同一の値が設定される。異なるデータ種類３０１をもつデータ群の中ではデータＩＤ３０２は重複しうる。

タイムスタンプ３０３は、データに付随する時間情報である。時間情報は、たとえば、データが表現している対象時刻が該当する。センサ入力部がデータの生成元の場合は、データをセンサが検出した時刻に相当する。タイムスタンプ３０３はたとえば年、月、日、時、分、秒、および小数点以下３ケタの秒数をスラッシュで繋げた書式で表され、たとえば図３の１行目に記載の「2018/1/1/01/00/00/001」は、２０１８年１月１日１時０分０．００１秒を表す。

以上の３点、すなわちデータ種類３０１、データＩＤ３０２、およびタイムスタンプ３０３は、データの種類に関わらず、いずれのデータも保持する情報である。次に説明するデータ固有属性群３０４はデータ種類３０１の値によって構成が異なる。データ固有属性３０４群は１以上のデータ固有情報から構成され、構成するデータ固有情報の数はデータの種類により異なる。たとえば、図３の１つ目のデータのようにデータ種類３０１が「自車両」のデータは、データ固有情報１として三次元の位置情報を有し、データ固有情報２として三次元の速度情報を有する。

なお図３に示すデータフォーマットは一例であり、アプリケーション入出力データ群１１１のデータフォーマットはこれに限定されない。たとえば、図３に示す例ではデータ種類を一列で一意に指定するフォーマットとしているが、データ種類を二層で表現してもよい。この場合はたとえばデータ種類３０１の大項目を「車両」とし、その小項目として「自車両」や「他車両」を設ける。フォーマットの形式によらず、統一的なデータフォーマットを作用することで、データに対する操作を汎用的に実装できる。たとえば、後述する図４の設定情報に記載されたソート方法４１０では「データＩＤソート」「タイムスタンプでソート」等のデータフォーマットに則るソートの方法を記載しているが、このようなソートを実現可能であるのは、データフォーマットを統一的に規定しておいたことによる。

（設定情報群１１２）
図４は、設定情報群１１２の一例を示す図である。設定情報群１１２は、記憶部１１０上に記録されている設定情報の集合である。設定情報群１１２は１以上の設定情報から構成される。各設定情報には、入力元アプリ４０１、出力先アプリ４０２、データ種類４０３、設定情報ＩＤ４０４、使用可否４０５、出力要素数４０６、通知待機４０７、種別４０８、コア数４０９、ソート方法４１０、および割当方法４１１が含まれる。なお以下では、出力先アプリ４０２を「第１ソフト部品」と呼ぶこともあり、入力元アプリ４０１を「第２ソフト部品」と呼ぶこともある。

設定情報群１１２のキーは、入力元アプリ４０１、出力先アプリ４０２、およびデータ種類４０３の組み合わせである。図４に示す例ではこれら３つの情報を別々の列で表現しているが、単一の列に統合した表としてもよい。これら３つの情報をもとにして対象のデータを特定し、そのデータを出力する際の制御の設定情報が表現されている。一つの対象データに対して複数の設定情報があってもよい。次に各列を順に説明する。

入力元アプリ４０１は、データの入力元アプリケーションの種類を示す。入力元アプリ４０１はたとえば、センサフュージョンや行動推定などである。ただし図４に示す例では、作図の都合によりセンサフュージョンを「ＳＦ」と記載している。なお入力元アプリ４０１に示されたアプリケーションは、複数の演算コアで並列的に演算されてもよいし、単一の演算コアで演算されてもよい。本項目はアプリケーションを特定する列挙値や識別値で記載されていてもよい。

出力先アプリ４０２は、データの出力先となるアプリケーションの種類を示す。出力先アプリ４０２はたとえば、センサフュージョン、行動推定、および地図フュージョンなどである。ただし図４に示す例では、作図の都合により地図フュージョンを「地図Ｆ」と記載している。出力先アプリ４０２に示されたアプリケーションは、複数の演算コアで並列的に演算されてもよいし、単一の演算コアで演算されてもよい。本項目はアプリケーションを特定する列挙値や識別値で記載されていてもよい。

データ種類４０３は、データの概念的な種別を示す。データ種類４０３はたとえば、他車両、歩行者、白線、標識などである。データ種類４０３は、入力元アプリ４０１と出力先アプリ４０２の間で受け渡しされるデータの種別である必要がある。本項目は図３に示す例におけるデータ種類３０１に相当する。データ種類３０１の場合と同様に、データ種類を一層で表現しても、二層で表現してもよい。

設定情報ＩＤ４０４は、アプリケーションの入出力設定のＩＤを示す。すなわち、設定情報群１１２のキーとなる、入力元アプリ４０１、出力先アプリ４０２、およびデータ種類４０３の組み合わせで特定される対象データに対する設定情報が複数存在する場合にそれら複数の設定情報を識別する識別子である。図４に示す例では、対象データに対して設定情報が単一の場合には、設定情報ＩＤ４０４は１が設定される。対象データに対して設定情報が複数存在する場合には、たとえば、図４に示すように設定情報ＩＤに異なる値が設定される。本項目は、設定情報群１１２として必須の項目ではなく、対象データに対して複数の設定情報が存在する場合のみ存在するものである。つまり対象データに対して単一の設定情報のみが存在する場合には本項目は不要である。

使用可否４０５は、対象データに対する設定情報が使用されるか否かを示す。換言すると使用可否４０５は、当該設定情報が有効か無効かを示す。図４に示す例では、入力元アプリ４０１がセンサフュージョン、出力先アプリ４０２が行動推定、データ種類４０３が他車両で特定されるデータに対して設定情報が３つ存在する。使用可否４０５はこの３つのうちいずれが使用されるかを示すものであり、１つのみが肯定的な設定、たとえば「Ｔｒｕｅ」に設定される。図４ではち設定情報ＩＤが「１」の設定情報のみ使用可否４０５がＴｒｕｅとなっており、有効である例が示されている。

なお使用可否４０５は、設定情報群１１２としては必須の項目ではなく、対象データに対して複数の設定情報が存在する場合のみ必要な項目である。対象データに対して単一の設定情報のみが存在する場合には本項目は不要である。

出力要素数４０６は、データ管理部１０４から出力先アプリ４０２に対して出力するデータの要素数を示す項目である。出力要素数４０６が「３」となっている場合には、配列の要素を３つずつ出力する。出力するデータの型が配列でない場合には本項目は不要である。

種別４０８は、データ管理部１０４から出力先アプリ４０２に対してデータ出力するタイミングが、Ｐｕｌｌ型とＰｕｓｈ型のいずれかであるかを示す。Ｐｕｌｌ型と指定されている場合には、データ管理部１０４が出力先アプリ４０２からデータ出力要求を受けたタイミングで出力する。Ｐｕｓｈ型と指定されている場合には、データ管理部１０４は、入力元アプリ４０１からデータ入力要求を受けたタイミングに、出力先アプリ４０２へデータ出力を行う。本項目は、そもそもＰｕｌｌ型とＰｕｓｈ型の両方をデータ管理部１０４のデータ出力として機能をサポートする場合に必要なものであり、Ｐｕｌｌ型もしくはＰｕｓｈ型のどちらか片方のみサポートする場合には不要である。

通知待機４０７は、データ管理部１０４が出力先アプリ４０２から出力要求を受けた際に、入力元アプリ４０１の処理完了を待機した上でデータを出力するか否かを示す。通知待機４０７が「Ｔｒｕｅ」と指定されていた場合には、全コアで動作している入力元アプリ４０１から完了通知を受け取ってから出力を行う。したがって本項目とコア数４０９はセットで扱われる。通知待機４０７が「Ｆａｌｓｅ」と指定されていた場合には、入力元アプリ４０１の処理完了に関わらず出力を行う。通知待機４０７は、種別４０８がＰｕｌｌ型に設定されている設定情報のみ参照される項目である。種別４０８がＰｕｓｈ型に設定されている設定情報では通知待機４０７は設定されなくてよい。

コア数４０９は、入力元アプリ４０１に記載されたアプリケーションがいくつのＣＰＵコア上で演算されるかを示す。通知待機４０７が「Ｔｒｕｅ」の場合には、演算を実行している全てのコアからの処理完了の通知を待機する必要があるので、コア数４０９の情報が必要となる。換言すると、通知待機４０７が「Ｆａｌｓｅ」の場合にはコア数４０９は参照の必要はなく、コア数４０９に情報が記載されなくてもよい。

ソート方法４１０は、データ管理部１０４が出力先アプリ４０２へ出力する対象のデータに対して、予め実行しておくソートの方法を示す。このソートの実行結果によって、どのような順序で要素が出力されるかが変化する。ソート方法４１０には次に説明する「データＩＤ」、「タイムスタンプ」、「データ固有情報」、および「距離ソート」が含まれてもよい。「データＩＤ」によるソートとは、図３で示したデータＩＤ３０２をキーとして、昇順または降順でソートする方法である。「タイムスタンプ」によるソートとは、図３で示したタイムスタンプ３０３をキーとして、昇順または降順でソートする方法である。「データ固有情報」によるソートとは、図３で示したデータ固有属性群３０４のいずれかの情報をキーとして、昇順または降順でソートする方法である。

さらに、データの値を直接ソートキーとして使う代わりに、データの値をもとに演算した結果をキーとしてソートしてもよい。たとえば、データが固有属性として位置情報を保持する場合に、自車両９と対象データの位置情報を用いてユークリッド距離を演算し、その演算結果である距離の長さに基づいてソートすることも考えられる。図４に示す例ではこの方法を「距離ソート」と記載している。さらにソート方法を独自関数で実装し、その関数の識別子を指定することも可能である。また、ソート方法を指定しないことも可能である。このソートの設定情報に基づくソート処理は、データ管理部１０４が、データを集約管理している場合に効果が発生するものである。

割当方法４１１は、出力先アプリへ出力するデータの指定方法を示す。割当方法４１１の例として、「出力要求順割当」および「空間領域割当」を説明するが、他の指定方法が選択可能でもよい。「出力要求順割当」とは、出力先アプリへデータ出力する契機があった場合に、インデックスの小さい順に出力する方法である。データのインデックスは生成された順番に付されてもよいし、ソート方法４１０に記載の方法でインデックスがソートされてもよい。「空間領域割当」とは、出力対象のデータがたとえば、車両９が存在する２次元平面グリッドマップを示すような際に、その平面を空間的に分割した上で、動作スレッドに対して分割空間領域に存在するデータ要素を割り当てる方法である。たとえば、車両前方と車両後方で空間領域を二分割して、車両前方は特定の動作スレッドに割り当てて、車両後方は別の特定の動作スレッドに割り当てるなどを行うことが考えられる。

ところで、この空間領域割当の例のように、出力先の動作スレッドを識別した上で、その動作スレッドごとに割当を決める場合には、データ管理部１０４は、出力要求を受けた動作スレッドを一意に特定する手段を有しておく必要がある。後述する、図９のデータ操作インタフェース２０１のＡＰＩの一例として記載のデータ出力要求ＡＰＩでは、データ出力要求を行う呼出元のアプリＩＤとして、アプリケーションの種類とその動作スレッドを識別する値を引数で渡される例を記載している。

演算装置１０は、この設定情報群１１２の各項目の情報に従って、データ管理部１０４が入力元アプリ４０１と出力先アプリ４０２の間のデータ入出力を制御する。そのため、たとえば並列化スケジューリング変更に伴ってデータ入出力の制御方法を変更したい場合には、設定情報群１１２のみ変更すればよい。

（動作例）
図５～図７は、演算装置１０のＡ～Ｃの３つの動作例を示す図である。図５に示す例Ａは、出力先アプリ４０２が演算コア１と演算コア２でデータ並列化されている。図６に示す例Ｂは、入力元アプリ４０１と出力先アプリ４０２がパイプライン並列化されている。図７に示す例Ｃは、入力元アプリ４０１と出力先アプリ４０２がともに演算コア１と演算コア２でデータ並列化されている。各例の詳細は後述する。

複数の演算コアを効率よく稼動させて、入力元アプリ４０１、たとえばセンサフュージョンアプリと出力先アプリ４０２、たとえば行動推定アプリ４とを高速に実行するための性能チューニングとして、スケジューリング設計を例Ａ、例Ｂ、例Ｃの間で相互に変更されることが想定される。そのようなスケジューリング設計が変更された場合にも、図４に示す設定情報群１１２の使用可否４０５を書き換えることで、データ管理部１０４がデータ出力制御を変更することが可能となる。

図５に示す例Ａでは、出力先アプリ４０２が演算コア１と演算コア２で並列化されている。入力元アプリ４０１の実行時間が、アプリケーション実行時間５０１として示されている。出力先アプリ４０２の実行時間が、演算コア２上でアプリケーション実行時間５０２、演算コア１上でアプリケーション実行時間５０３として示されている。この例Ａでは、入力元アプリ４０１から出力先アプリ４０２へのデータ出力の設計として、「出力データ要素は３つずつ」、「入力元アプリ４０１が処理完了した後に」、「出力先アプリ４０２から出力要求があるたびにデータを出力先アプリへ出力する」、という設計によるデータ出力の様子をシーケンス図で示している。

まず図５の左半分、すなわち符号５１０Ａの矢印の処理までを説明する。図５に示す例Ａでは、まず入力元アプリ４０１が演算を行い、演算結果が得られるたびに符号５１０で示すように演算結果を出力する。入力元アプリ４０１が出力を行っている最中に、符号５００で示すように出力先アプリ４０２から入力元アプリ４０１にデータが要求される。そして入力元アプリ４０１は符号５０１で示す時間を要して演算を完了させ、符号５１０Ａに示すように処理が完了した旨の通知を送信する。

データ管理部１０４は、図４の例に示す１行目の設定情報、すなわち、出力要素数４０６が「３」、通知待機４０７が「Ｔｒｕｅ」、種別４０８が「Ｐｕｌｌ」、コア数４０９が「１」を読み取り、図５に示す例の動作を行う。すなわち、符号５１０Ａで示す完了通知を「１」つ受信すると出力先アプリ４０２への出力を開始しており、符号５１１に示すように入力元アプリ４０１から受信したデータ「３」つを１つの塊として出力する。

図６に示す例Ｂでは、入力元アプリ４０１と出力先アプリ４０２がパイプライン並列化されている。入力元アプリ４０１の実行時間が、アプリケーション実行時間５０１として示されている。出力先アプリ４０２の実行時間が、アプリケーション実行時間５０５として示されている。これらのアプリケーションはそれぞれ別の演算コアで実行されており、時間的に同時並列的に動いている。入力元アプリ４０１の動作は例Ａと同様なので説明を省略する。

この例Ｂでは、入力元アプリ４０１から出力先アプリ４０２へのデータ出力の設計は、「出力データ要素は１つずつ」、「入力元アプリ４０１が処理完了するか否かに関わらず」、「入力元アプリ４０１からデータがアプリケーション入出力データ群１１１へ格納されるタイミングでデータを出力先アプリ４０２へ出力する」、という設計によるデータ出力の様子をシーケンス図で示している。

データ管理部１０４は、図４の例に示す２行目の設定情報、すなわち、出力要素数４０６が「１」、種別４０８が「Ｐｕｓｈ」を読み取り、図６に示す例の動作を行う。すなわちデータ管理部１０４は、入力元アプリ４０１からデータが「１」つ出力されると、種別４０８が「Ｐｕｓｈ」なので完了通知を待機せずに、即座に出力先アプリ４０２への送信を開始する。

図７に示す例Ｃでは、入力元アプリ４０１と出力先アプリ４０２がともに演算コア１と演算コア２でデータ並列化されている。演算コア１上で実行する入力元アプリ４０１の実行時間がアプリケーション実行時間６０１として、演算コア２上で実行する入力元アプリ４０１の実行時間がアプリケーション実行時間６０２として示されている。演算コア１上で実行する出力先アプリ４０２の実行時間がアプリケーション実行時間６０３として、演算コア１上で実行する出力先アプリ４０２の実行時間がアプリケーション実行時間６０４として示されている。

この例Ｃでは、データ出力の設計として、「出力データ要素は３つずつ」、「入力元アプリ４０１が処理完了した後に」、「データを出力先アプリ４０２へ出力する」、という設計によるデータ出力の様子をシーケンス図で示している。データ管理部１０４は、図４の例に示す３行目の設定情報、すなわち、出力要素数４０６が「３」、通知待機４０７が「Ｔｒｕｅ」、種別４０８が「Ｐｕｌｌ」、コア数４０９が「２」を読み取り、図７に示す例の動作を行う。

入力元アプリは演算コア１と演算コア２で並列動作して、それぞれのコアは演算が完了すると完了通知を出力する。演算コア２は処理が先に完了し、符号６１１で示すデータと、符号６１２で示す完了通知を出力する。この時点におけるデータ管理部１０４の判断は次のとおりである。すなわちデータ管理部１０４は、出力要素数４０６が「３」でありすでに入力元アプリ４０１から３つのデータを受信しているが、受信した完了通知は１つしか受信しておらず、コア数４０９の「２」よりも少ないため出力条件を満たしていないと判断する。

その後、演算コア１が演算を完了し、符号６１３に示す３つのデータの出力と、符号６１４に示す完了通知を送信すると、データ管理部１０４は出力条件を満たしたと判断して出力先アプリ４０２にデータを出力する。

（フローチャート）
図８～図１０を参照して、データ管理部１０４のデータ入出力処理を説明する。図８はデータ管理部１０４にデータが入力される際の処理であるデータ入力処理を示すフローチャートである。ただし図８では、所定の入力元アプリＸからデータ入力がされるとしてデータ管理部１０４の動作を説明する。

データ管理部１０４は、ステップＳ７０１において、入力元アプリＸからデータ入力要求を受けてステップＳ７０２に進む。本データ入力要求では後述する図９のデータ入力要求ＡＰＩを通じて、いずれの入力元アプリからも共通のＡＰＩにてアクセスされる。その際に、入力元アプリ４０１、データ種類４０３等の情報を入力データそのものとともに、ＡＰＩ引数としてデータ管理部１０４が受け取る。

データ管理部１０４は、ステップＳ７０２において、入力元アプリ４０１とデータ種類４０３の情報をもとに、アプリケーション入出力データ群１１１の該当アドレスにデータを格納してステップＳ７０３に進む。入力元アプリ４０１とデータ種類４０３の情報とデータを格納するアドレスを紐付けるテーブルは、データ管理部１０４が内部で保持してもよいし、別のモジュールが保持してそれをデータ管理部１０４が参照してもよい。

データ管理部１０４は、ステップＳ７０３において、所定の待機スレッドに対して、入力元アプリ４０１とデータ種類４０３のデータが新たに格納されたことを通知してステップＳ７０４に進む。この待機スレッドは後述するステップＳ７５２において待機している。データ管理部１０４は、ステップＳ７０４において、後述するＰｕｓｈ処理を実行してステップＳ７０５に進む。ステップＳ７０５において処理対象となるのは、設定情報群１１２において種別４０８が「Ｐｕｓｈ」である設定情報である。種別４０８が「Ｐｕｌｌ」である設定情報は、後述する図１０に示すフローチャートにおいて処理される。

データ管理部１０４は、ステップＳ７０５において、入力元アプリ４０１から完了通知があるか否かを判断する。なお以下では、「完了通知」は「アプリ処理完了通知」や「処理完了通知」とも呼ぶ。入力元アプリ４０１からのデータ処理完了通知は、後述する図１１のアプリ処理完了通知ＡＰＩを通じて受け付ける。データ管理部１０４は、データ処理完了通知があると判断する場合にはＳ７０６へ進み、ないと判断する場合は図８に示す処理を終了する。

データ管理部１０４は、ステップＳ７０６において、アプリケーション入出力データ群１１１へ完了通知を格納して図８に示す処理を終了する。本通知は、後に説明する図９に示すフローチャートにおいて参照される。

図９は、図８のステップＳ７０４の詳細を示すフローチャートである。データ管理部１０４はステップＳ７５１では、Ｐｕｓｈ処理対象の設定情報が存在するか否かを判断する。データ管理部１０４は、Ｐｕｓｈ処理対象の設定情報が存在すると判断する場合はステップＳ７５２に進み、Ｐｕｓｈ処理対象の設定情報が存在しないと判断する場合は図９に示す処理を終了する。データ管理部１０４は具体的には、設定情報群１１２において入力元アプリ４０１が「入力元アプリＸ」の種別であり、データ種類４０３が受信したデータのデータ種類であり、使用可否４０５が「Ｔｒｕｅ」であり、かつ種別４０８が「Ｐｕｓｈ」である設定情報が存在するか否かを判断する。

ステップＳ７５２ではデータ管理部１０４は、ステップＳ７５１において存在を確認した設定情報の出力条件を満たすか否かを判断する。データ管理部１０４は、出力条件を満たすと判断する場合はステップＳ７５３に進み、出力条件を満たさないと判断する場合はステップＳ７５２に留まる。具体的にはデータ管理部１０４は、出力要素数４０６の要素数分のデータがアプリケーション入出力データ群１１１に蓄積されているか否かを判断する。ただしステップＳ７５２において否定判断する場合は、ステップＳ７５２における待機が短時間で解消しない可能性もあるため、待機以下の処理を別スレッドで実行させて、次のデータ入力要求受付に備えて待機する。以下ではステップＳ７５２において否定判断されたことで生成されるスレッドを「待機スレッド」とも呼ぶ。

ステップＳ７５３ではデータ管理部１０４は、設定情報にソート方法４１０や割当方法４１１の記載がある場合には、その記載にしたがって、ソートや要素の割当を行いステップＳ７５４に進む。設定情報にソート方法４１０の記載がある場合には、その記載にしたがってソートを行う。たとえばデータＩＤで昇順もしくは降順にソートし要素を入れ替える。また設定情報に割当方法４１１の記載がある場合には、その記載にしたがって要素を割り当てる。割当の方法はインデックスを入れ替えるのでもよく、また別の方法としてスレッドごとに配列を確保して割当られた要素をコピーするなどしてもよい。データ管理部１０４は、ステップＳ７５４において、出力先アプリ４０２に対して指定要素分出力を行い図９に示す処理を終了する。

図１０はデータ管理部１０４が出力先アプリへデータを出力するデータ出力処理を示すフローチャートである。データ管理部１０４は、ステップＳ８００において、出力先アプリ４０２からデータ出力要求を受けるとステップＳ８０１に進む。本データ出力要求では後述する図１１のデータ出力要求ＡＰＩを通じて、いずれの出力先アプリからも共通のＡＰＩにてアクセスされる。その際に、入力元アプリ４０１、出力先アプリ４０２、データ種類４０３等の情報をＡＰＩ引数としてデータ管理部１０４が受け取る。

データ管理部１０４は、ステップＳ８０１において、設定情報群１１２を読み込んでステップＳ８０２に進む。具体的にはデータ管理部１０４は、入力元アプリ４０１、出力先アプリ４０２、データ種類４０３の情報をキーにして設定情報群１１２を検索して設定情報を特定し、その設定情報を読み込む。ただしデータ管理部１０４は、該当する設定情報が複数存在する場合には、使用可否４０５が「Ｔｒｕｅ」に設定されている設定情報のみを読み込む。

データ管理部１０４は、ステップＳ８０２～ステップＳ８０４において、設定情報群１１２に記載されている各種出力条件を満たしているかを判断する。データ管理部１０４はまずステップＳ８０２において、要素数の蓄積条件を満たすか否か、すなわち出力要素数４０６の要素数分のデータがアプリケーション入出力データ群１１１に格納されているか否かを判断する。データ管理部１０４は要素数の蓄積条件を満たすと判断する場合はステップＳ８０３に進み、要素数の蓄積条件を満たさないと判断する場合はステップＳ８０２に留まる。

ステップＳ８０３ではデータ管理部１０４は、通知待機４０７がＦａｌｓｅであるか否かを判断し、Ｆａｌｓｅであると判断する場合はステップＳ８０５に進み、Ｆａｌｓｅではない、すなわちＴｒｕｅであると判断する場合はステップＳ８０４に進む。ステップＳ８０４ではデータ管理部１０４は、入力元アプリ４０１のアプリ処理完了通知を受信済みであるか否かを判断し、受信済と判断する場合はステップＳ８０５に進み、受信していないと判断する場合はステップＳ８０５に留まる。なおステップＳ８０４における判断材料のアプリ処理完了通知とは、前述の図８におけるステップＳ７０６の処理によるものである。

なおデータ管理部１０４は、ステップＳ８０２およびステップＳ８０４において否定判断した際にステップＳ８０２に留まらず、ステップＳ８００におけるデータ出力要求の送信元にエラーを通知して図１０に示す処理を終了してもよい。ステップＳ８０５およびステップＳ８０６の処理のそれぞれは、ステップＳ７５３およびステップＳ７５４の処理のそれぞれと同様なので説明を省略する。

図１１は、データ操作インタフェース２０１が解釈可能なＡＰＩの一例を示す図である。記載例Ｃ９０１は、データ操作インタフェース２０１をＣ言語で記述した場合のヘッダファイルの一部を擬似コードで表現したものである。このＡＰＩには、データの入力要求、データの出力要求、およびアプリ処理完了通知等が含まれる。

記載例Ｃ９０１の最初に示す例であるデータの入力要求ＡＰＩ（dataInputRequest）は、データをアプリケーション入出力データ群１１１に格納する操作を要求するＡＰＩである。このＡＰＩの引数は、呼出元アプリを特定する呼出元アプリＩＤ、入力するデータ種類を指定する入力データ種類、データサイズ、およびデータアドレスを含む。呼出元アプリＩＤは、アプリケーションの種類を一意に特定できる識別子である必要がある。データ種類はデータ種類３０１は、データの概念的な種別を示すものである。たとえば、他車両、歩行者、白線、標識等があげられる。データサイズは入力されるデータの長さを示す。データアドレスは入力されるデータの格納される。このＡＰＩの呼出は、図８のステップＳ７０１に対応する。

記載例Ｃ９０１の２番目の例であるデータ出力要求ＡＰＩ（dataOutputRequest）は、データをアプリケーション入出力データ群１１１から出力する操作を要求するＡＰＩである。このＡＰＩの引数は、対象データをアプリケーション入出力データ群１１１に入力したアプリケーションを示す入力元アプリＩＤ、呼出元アプリを特定する呼出元アプリＩＤ、出力するデータの種類を指定する出力データ種類、格納先バッファサイズ、およびバッファアドレスから構成される。図４における割当方法４１１で実行スレッドＩＤに紐付くデータ割当方法が指定されるように設定情報が指定されていた場合には、本データ出力要求ＡＰＩにおける引数の呼出元アプリＩＤは、アプリケーションの種類とそのアプリケーションの動作スレッドの両者を一意に特定できる識別子である必要がある。このＡＰＩの呼出が、図１０のステップＳ８００に対応する。

記載例Ｃ９０１の３番目の例であるアプリ処理完了通知ＡＰＩは、入力元アプリ４０１が処理を完了した際に、入力元アプリ４０１から呼び出されるものである。これに基づいて、図７におけるステップＳ７０５での判定がなされる。

以上のように、データ管理部の備えるデータ操作インタフェース２０１は、アプリケーションの種類やアプリケーションの実行スケジューリングに依存しない引数が定義されている。そのため、データ並列化やパイプライン並列化等のアプリケーションの実行スケジューリングに変更があった場合にも、アプリケーションのインタフェース自体は変更する必要がない。

図１２は、アプリケーションの記述様式の一例として擬似コード１０００を示す図である。この記述様式を用いて、入力元アプリ４０１や出力先アプリ４０２を含めあらゆるアプリケーションが記述されることを想定している。擬似コード１０００の内部では、データが繰り返し処理される。たとえば、自車両周辺の他車両の行動を推定するアプリケーションの場合には、他車両１台ずつについて、その他車両の情報や周辺状況に基づいて、行動推定が繰り返される。

その繰り返し処理の先頭において処理部１００は、符号１０００Ａで示すように、まずアプリケーションはデータの出力要求ＡＰＩを用いてデータを取得する。図１２の擬似コード１０００では、単一のデータの出力要求するＡＰＩを一度呼び、その出力データに対して処理を行う記述となっている。たとえば、この単一のデータの中に複数のデータを構成した構造体としてもよい。また、別の方法として、別々のデータ構造体に分かれた複数のデータを取得するために、出力要求ＡＰＩを複数回呼ぶ構成としても構わない。図４における割当方法４１１で実行スレッドＩＤに紐付くデータ割当方法が指定されるように設定情報が指定されていた場合には、呼出元アプリＩＤは次の制約が課せられる。すなわち本データ出力要求ＡＰＩにおける引数の呼出元アプリＩＤは、アプリケーションの種類とそのアプリケーションの動作スレッドの両者を一意に特定できる識別子である必要がある。

次に処理部１００は、符号１０００Ｂで示すように、取得したデータに対してアプリケーション独自の処理を行う。データに対する処理結果として図１２の擬似コード１０００では、単一のデータを返り値として記述しているが、複数のデータを処理結果としてもよい。次に処理部１００は、符号１０００Ｃで示すように、処理結果を次にデータ管理部１０４のデータ入力要求ＡＰＩを用いて入力する。図１２の擬似コード１０００では、単一のデータを入力するために、データの入力要求を一度呼んでいるが、複数のデータを入力するためにデータの入力要求を複数回呼ぶ構成としてもよい。

次に処理部１００は、符号１０００Ｄで示すように、アプリケーションが処理するデータの出力元であるアプリケーションの処理完了通知がアプリケーション入出力データ群１１１に入っている場合には、アプリ処理完了通知を、データ管理部１０４に対して通知する。

図１２の擬似コード１０００のような記述様式としておくことで、アプリケーションからはデータ入出力設計の設定情報に関わらず統一的な記述が可能となる。データ入出力の制御に関しては、擬似コード１０００で呼ぶデータ管理部１０４の提供するデータ操作インタフェース２０１の内部に隠蔽される。

以上のように、本実施形態によれば、予めアプリケーションとアプリケーション間で入出力されるデータに対して、出力タイミングや出力データ数を定義した設定情報を演算装置１０に保持しておき、さらにアプリケーションから共通のインタフェースでデータ入出力可能なデータ管理部を介して、アプリケーションはデータを入出力することで、データ管理部は、設定情報に基づいて、アプリケーションへの出力データ数や出力タイミングを制御する。これにより、データの入出力設計の変更を設定情報の変更のみで行うことができ、アプリケーションのインタフェースを変更する必要がない。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）演算装置１０は、所定の対象要素に対応するデータ要素の集合であるオブジェクトデータ、すなわちアプリケーション入出力データ群１１１に格納される情報、およびオブジェクトデータの出力方式、すなわち設定情報群１１２の符号４０６～符号４１１の情報に関する設定情報を複数含む設定情報群１１２が格納される記憶部１１０と、オブジェクトデータを管理するデータ管理部１０４と、データ管理部１０４から取得されるオブジェクトデータである入力オブジェクトデータに基づいてオブジェクトデータである出力オブジェクトデータを演算し、出力オブジェクトデータをデータ管理部に出力するソフト部品を複数備える実行制御部１０２と、を備える。設定情報群１１２を構成するそれぞれの設定情報は、第１ソフト部品（出力先アプリ４０２）に対する入力オブジェクトデータであり第２ソフト部品（入力元アプリ４０１）が出力する出力オブジェクトデータ、すなわち設定情報群１１２の符号４０１～符号４０３により特定されるオブジェクトデータと、第２ソフト部品が出力する出力オブジェクトデータを第１ソフト部品に対して出力する際の出力方式、すなわち設定情報群１１２の符号４０６～符号４１１の情報と、が対応付いた情報である。データ管理部１０４は、第２ソフト部品（入力元アプリ４０１）から受け取ったオブジェクトデータを管理し、オブジェクトデータを、設定情報に規定された出力方式に基づき、第１ソフト部品（出力先アプリ４０２）に出力する。そのため演算装置１０は、アプリケーションを変更することなくデータ入出力の変更に対応できる。

（２）出力方式は、オブジェクトデータの出力要素単位情報、すなわち出力要素数４０６と、オブジェクトデータの出力開始タイミング情報、すなわち通知待機４０７および種別４０８と、オブジェクトデータのスレッド割当方法、すなわち割当方法４１１と、のいずれか１つ以上を含む。
（３）出力方式は、さらにオブジェクトデータのソート方法４１０を含む。そのため制御装置１０は、多彩な出力方式を設定可能である。

（４）演算装置１０は、データ管理部に対するオブジェクトデータの入出力を操作するためのデータ操作インタフェース２０１を備える。ソフト部品は、データ操作インタフェース２０１を介してデータ管理部１０４に対するオブジェクトデータの入出力を操作する。データ操作インタフェース２０１は、データ管理部１０４によるソフト部品に対するオブジェクトデータの出力方式に関わらず共通である。そのため、アプリケーションのデータ入出力の制御はデータ管理部１０４の内部に隠蔽できる。

（変形例１）
記憶部１１０は演算装置１０の外部に設けられてもよい。その場合は演算装置１０は、通信部１２０を介して記憶部１１０にアクセス可能に構成される。

（変形例２）
実行制御部１０２は、設定情報群１１２を書き換えてもよい。本変形例では、記憶部１１０に対応表１１５がさらに格納される。対応表１１５は、状態と設定値との対応を示す表である。

図１３は対応表１１５の一例を示す図である。実行制御部１０２は対応表１１５を読み込み、車両９が図示左側の欄に記載した状態に該当すると判断すると、設定情報群１１２を図示左側の欄に記載した設定値に書き換える。ただし図１３に示す例では、具体的な設定値の代わりにＤＥＦ１、ＤＥＦ２、などを記載している。この設定値は具体的には、使用可否４０５の項目の値である。たとえば図４に示す全ての設定情報についてのＴｒｕｅまたはＦａｌｓｅのいずれかの情報であってもよいし、Ｔｒｕｅである設定情報を特定する情報でもよいし、Ｆａｌｓｅである設定情報を特定する情報であってもよい。

図１４は、実行制御部１０２が設定情報群１１２を動的に書き換える設定情報切替処理のフローチャートである。ステップＳ１１００では実行制御部１０２は、対応表１１５を読み込む。続くステップＳ１１０１では実行制御部１０２は、外界センサ群２０および車両センサ群３０から取得した情報に基づき、車両９の状態を検出する。続くステップＳ１１０２では実行制御部１０２は、ステップＳ１１０１において検出した車両９の状態に対応する対応表１１５の設定値を読み取る。続くステップＳ１１０３では実行制御部１０２は、ステップＳ１１０２において読み取った設定値に設定情報群１１２を書き換えて図１４に示す処理を終了する。具体的には実行制御部１０２は、設定情報群１１２の使用可否４０５の値を書き換える。

このように、アプリケーションの実行スケジュールの切替に合わせて、データ管理部から参照される設定情報群１１２を書き換えておくことで、アプリケーションの実行スケジュールに合わせた、データ入出力の設計を、アプリケーションの変更なしに動的に実現することができる。図１３では、動的に設定情報を変更する処理フローＦ１１００を示したが、もちろん複数の設定情報に対して、アプリケーション動作中ではなく、静的にどの設定情報を有効化するかを変更してもよい。

この変形例２によれば次の作用効果が得られる。
（５）演算装置１０は、設定情報群１１２を書き換える実行制御部１０２を備える。そのため状況に応じて設定情報群１１２を書き換え、アプリケーションのデータ入出力を任意のタイミングで変更できる。なお本変形例では実行制御部１０２が設定情報群１１２を書き換えたが、実行制御部１０２以外が設定情報群１１２を書き換えてもよいし、演算装置１０が他の機能構成を備え、その機能構成が設定情報群１１２を書き換えてもよい。また実行制御部１０２は、動的に、すなわちアプリケーションの動作中に設定情報群１１２を書き換えてもよいし、静的に、すなわちアプリケーションの停止中に設定情報群１１２を書き換えてもよい。

（変形例３）
設定情報群１１２は、符号４０６から符号４１１に示す構成の少なくとも１つを含めばよい。設定情報群１１２に含まれない構成は既定の固定値としてもよい。たとえば設定情報群１１２から出力要素数４０６を削除し、全ての設定情報において出力要素数４０６を「１」として扱ってもよい。

―第２の実施の形態―
図１５を参照して、車両制御システムの第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、演算装置をテスト環境で動作させる点で、第１の実施の形態と異なる。

（構成）
図１５は、第２の実施の形態に係る車両制御システムの全体構成図である。第１の実施の形態との相違点は、車両制御システム１Ａが車両９ではなく車両９の外部に存在するテスト環境９Ａに置かれる点が大きく異なる。また第１の実施の形態において説明した外界センサ群２０、車両センサ群３０、アクチュエータ群４０、および車載ネットワーク５０Ａは車両９に備えられる構成なので、本実施の形態ではそれらに代わって、外界センサ群シミュレータ２０Ａ、車両センサ群シミュレータ３０Ａ、アクチュエータ群シミュレータ４０Ａ、およびネットワーク５０Ａが備えられる。さらに車両制御システム１Ａにはオペレータ端末６０Ａも備えられる。

外界センサ群シミュレータ２０Ａは、外界センサ群２０の動作をシミュレートする装置である。具体的には外界センサ群シミュレータ２０Ａは、予め定められたタイミングであらかじめ定められたデータを演算装置１０Ａに出力する。車両センサ群シミュレータ３０Ａは、車両センサ群３０の動作をシミュレートする装置である。具体的には車両センサ群シミュレータ３０Ａは、予め定められたタイミングであらかじめ定められたデータを演算装置１０Ａに出力する。アクチュエータ群シミュレータ４０Ａは、アクチュエータ群４０の動作をシミュレートする装置である。具体的にはアクチュエータ群シミュレータ４０Ａは、演算装置１０Ａからの動作指令を受ける。

なおアクチュエータ群シミュレータ４０Ａが演算装置１０Ａから入力される情報に基づき、外界センサ群シミュレータ２０Ａおよび車両センサ群シミュレータ３０Ａが出力する情報を加工してもよい。たとえば演算装置１０Ａがアクチュエータ群シミュレータ４０Ａにアクセルペダルの踏み込み量増加の指令を出力すると、車両センサ群シミュレータ３０Ａが出力する自車両９の速度の出力、すなわち速度の値を増加させてもよい。

ネットワーク５０Ａは、たとえば室内に敷設されたＬＡＮである。ただしネットワーク５０Ａは無線ＬＡＮであってもよい。オペレータ端末６０Ａはたとえばオペレータが操作するパーソナルコンピューターである。オペレータは、オペレータ端末６０Ａを介して１０Ａの内部に自由にアクセスができる。オペレータはオペレータ端末６０Ａを操作することで、設定情報群１１２の書き換え、および動作ログ１１６の取得が可能である。

本実施の形態における演算装置１０Ａの構成は、記憶部１１０に動作ログ１１６がさらに格納される点、および処理部１００がその機能としてログ記録部１０５をさらに有する点が第１の実施の形態と異なる。ログ記録部１０５は、時間の情報を付して処理部１００の動作を動作ログ１１６に記録する。

上述した第２の実施の形態によれば、車両９の外部で事前に様々な状況をテストすることができる。

（第２の実施の形態の変形例）
上述した第２の実施の形態では、外界センサ群シミュレータ２０Ａ、車両センサ群シミュレータ３０Ａ、およびアクチュエータ群シミュレータ４０Ａは演算装置１０Ａとは異なるハードウエアにより実現され、ネットワーク５０Ａにより接続された。しかし演算装置１０Ａ、外界センサ群シミュレータ２０Ａ、車両センサ群シミュレータ３０Ａ、およびアクチュエータ群シミュレータ４０Ａが同一のハードウエアにより実現されてもよい。換言すると、第２の実施の形態における構成は、全てが１台のコンピュータにおける仮想的な構成であってもよい。

演算装置１０が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースと演算装置１０が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、たとえば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡ（field programmable gate array）により実現されてもよい。上述した複数の変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１…車両制御システム
９…車両
１０…演算装置
１００…処理部
１０２…実行制御部
１０４…データ管理部
１０５…ログ記録部
１１０…記憶部
１１１…アプリケーション入出力データ群
１１２…設定情報群
１１２…データ入出力設定情報群
１１３…スレッド数情報群
１１４…アプリケーション群
２０１…データ操作インタフェース

Claims

所定の対象要素に対応するデータ要素の集合であるオブジェクトデータ、および前記オブジェクトデータの出力方式に関する設定情報が格納される記憶部と、
前記オブジェクトデータを管理するデータ管理部と、
前記データ管理部から取得される前記オブジェクトデータである入力オブジェクトデータに基づいて前記オブジェクトデータである出力オブジェクトデータを演算し、前記出力オブジェクトデータを前記データ管理部に出力するソフト部品を複数備える実行制御部と、を備え、
前記設定情報は、第１ソフト部品に対する前記入力オブジェクトデータであり第２ソフト部品が出力する前記出力オブジェクトデータと、前記第２ソフト部品が出力する前記出力オブジェクトデータを前記第１ソフト部品に対して出力する際の出力方式と、が対応付いた情報であり、
前記データ管理部は、前記第２ソフト部品から受け取った前記オブジェクトデータを管理し、前記オブジェクトデータを、前記設定情報に規定された出力方式に基づき、前記第１ソフト部品に出力する演算装置。
請求項１に記載の演算装置において、
前記出力方式は、
前記オブジェクトデータの出力要素単位情報と、前記オブジェクトデータの出力開始タイミング情報と、前記オブジェクトデータのスレッド割当方法と、のいずれか１つ以上を含む演算装置。
請求項２に記載の演算装置において、
前記出力方式は、さらに前記オブジェクトデータのソート方法を含む演算装置。
請求項１に記載の演算装置において、
前記設定情報を書き換える演算実行制御部をさらに備える演算装置。
請求項１に記載の演算装置において、
前記データ管理部に対する前記オブジェクトデータの入出力を操作するためのインタフェース部と、を更に備え、
前記ソフト部品は、前記インタフェース部を介して前記データ管理部に対する前記オブジェクトデータの入出力を操作し、
前記インタフェース部は、前記データ管理部によるソフト部品に対する前記オブジェクトデータの出力方式に関わらず共通である演算装置。
所定の対象要素に対応するデータ要素の集合であるオブジェクトデータ、および前記オブジェクトデータの出力方式に関する設定情報が格納される記憶部にアクセス可能であり前記オブジェクトデータを管理するデータ管理部を備える演算装置が実行する演算方法であって、
前記データ管理部から取得される前記オブジェクトデータである入力オブジェクトデータに基づいて前記オブジェクトデータである出力オブジェクトデータを演算し、前記出力オブジェクトデータを前記データ管理部に出力するソフト部品を複数備えることと、
前記設定情報は、第１ソフト部品に対する前記入力オブジェクトデータであり第２ソフト部品が出力する前記出力オブジェクトデータと、前記第２ソフト部品が出力する前記出力オブジェクトデータを前記第１ソフト部品に対して出力する際の出力方式と、が対応付いた情報であり、
前記データ管理部は、前記第２ソフト部品から受け取った前記オブジェクトデータを管理し、前記オブジェクトデータを、前記設定情報に規定された出力方式に基づき、前記第１ソフト部品に出力することとを含む演算方法。