JP2020074191A

JP2020074191A - 車載処理装置

Info

Publication number: JP2020074191A
Application number: JP2020009054A
Authority: JP
Inventors: 勇樹堀田; Yuuki Hotta; 櫻井　康平; Kohei Sakurai; 康平櫻井; 工藤　真; Makoto Kudo; 真工藤; 吉村　健太郎; Kentaro Yoshimura; 健太郎吉村
Original assignee: Hitachi Automotive Systems Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2020-01-23
Filing date: 2020-01-23
Publication date: 2020-05-14
Anticipated expiration: 2036-10-03
Also published as: JP6838776B2

Abstract

【課題】車載処理装置におけるアプリケーションソフトウェアの再利用性を向上させる。【解決手段】車載処理装置において処理部に演算処理を実行させるためのアプリケーションソフトウェア１３１は、所定の対象要素に対応するデータの集合であるオブジェクトデータを記憶部上で管理するためのデータ管理層２３０と、入力データ１４２に基づきオブジェクトデータを生成し、生成したオブジェクトデータをデータ管理層２３０に出力するためのデータ適合層２００と、データ管理層２３０からオブジェクトデータを取得し、取得したオブジェクトデータに基づき出力データ１４３を演算するためのデータ演算層２４０と、を有する。【選択図】図３

Description

本発明は、車載処理装置に関する。

従来から、車両に搭載されるＥＣＵ（ＥｌｅｃｔｒｏｎｉｃＣｏｎｔｒｏｌＵｎｉｔ）において、ＥＣＵのハードウェア構成や、ＥＣＵに接続されるセンサやアクチュエータを抽象化（モデル化）し、これらの間で情報の受け渡しを行うインタフェースをソフトウェアで構築する方式が提案されている。この方式によれば、ＥＣＵの内外のハードウェア構成が変更されても、上位のアプリケーションソフトウェアの再利用性を高めることができる（例えば、特許文献１参照）。

特開２０００−９７１０２号公報

従来のＥＣＵでは、車両や車両に搭載された部品に関する所定の状態量を検出するセンサ（内界センサ）の出力値に基づき制御情報を演算し、対象のアクチュエータや他ＥＣＵに対して制御情報を出力する構成が通例であった。このような従来のＥＣＵでは、センサの検出対象やアクチュエータの制御対象が明確に決まっているため、これらに対応するインタフェースをソフトウェアで構築することが容易である。例えば、車速センサについては、車速センサの検出対象である車速をモデル化してインタフェースを構築すればよいし、インジェクタについては、インジェクタの制御対象である燃料噴出量等をモデル化してインタフェースを構築すればよい。

しかし、近年のＡＤＡＳ（ＡｄｖａｎｃｅｄＤｒｉｖｅｒＡｓｓｉｓｔａｎｃｅＳｙｓｔｅｍｓ）や自動運転の進展に伴い、従来の内界センサに加えて、車両周辺の状態を検出するための外界センサを搭載した車両が増えてきている。このような外界センサの検出対象は、他車両や歩行者等の障害物、白線や路端等の道路形状、標識や信号等の交通ルール等、多岐にわたる。また、外界センサの種類は、その検出対象に応じて、カメラ、ミリ波レーダ、ソナー、ＬＩＤＡＲ（ＬＩｇｈｔＤｅｔｅｃｔｉｏｎＡｎｄＲａｎｇｉｎｇ）等、様々であり、たとえ同種のセンサであっても、製造メーカやバージョンによって、出力される情報の種類や量が大きく異なる。そのため、外界センサの出力データに基づき制御情報を演算するＥＣＵのソフトウェアでは、従来のＥＣＵのようにセンサをモデル化してインタフェースを構築するのが実質的に困難である。その結果、アプリケーションソフトウェアの再利用が難しいという問題がある。

また、ＡＤＡＳや自動運転に関するＥＣＵのように、多数の外界センサの出力結果から複雑な処理を経て車両の制御情報を演算するＥＣＵのアプリケーションソフトウェアは、センサフュージョンや移動体の行動予測等、多数の機能の集まりで構成されている。このようなアプリケーションソフトウェアの機能構成は、ＡＤＡＳや自動運転において実現される制御の内容や車種に応じて異なってくる場合が多いため、ソフトウェア内部の機能構成の変更時におけるアプリケーションソフトウェアの再利用性も重要になってきている。しかし、従来のＥＣＵでは、こうした場合のアプリケーションソフトウェアの再利用性について考慮されていない。

以上を踏まえ、本発明では、車載処理装置におけるアプリケーションソフトウェアの再利用性を向上させることを主な目的とする。

本発明による車載処理装置は、車両に搭載されるものであって、複数の装置からそれぞれ入力される入力信号に基づき、複数の対象要素に関する情報を含む入力データを生成する信号入力部と、前記入力データに基づき出力データを演算する演算処理を実行する処理部と、前記出力データに基づく出力信号を生成して出力する信号出力部と、前記処理部に前記演算処理を実行させるためのアプリケーションソフトウェアを記憶する記憶部と、を備え、前記アプリケーションソフトウェアは、前記入力データに基づき、前記対象要素ごとに前記情報を抽象化したオブジェクトデータを生成するデータ適合層と、前記オブジェクトデータに基づき前記出力データを演算するためのデータ演算層と、を有する。

本発明によれば、車載処理装置におけるアプリケーションソフトウェアの再利用性を向上させることができる。

本発明の一実施形態に係る車載処理装置を含む車両システムの構成の一例を示す機能ブロック図である。本発明の一実施形態に係る車載処理装置における処理ソフトウェアの構成の一例を示す図である。本発明の一実施形態に係る車載処理装置におけるアプリケーションソフトウェアの構成の一例を示す図である。オブジェクトデータ群に格納されているオブジェクトデータの一例を示す図である。設定情報データ群に格納されている設定情報の一例を示す図である。オブジェクトデータ操作インタフェースの一例を示す図である。オブジェクトデータ操作インタフェースの一例を示す図である。本発明の一実施形態に係る車載処理装置におけるアプリケーションソフトウェアの処理フローの一例を示す図である。オブジェクトデータのモデル化の一例を示す図である。認認知処理の部分更新に対応したオブジェクトデータの構造の一例を示す図である。本発明の一実施形態に係る車載処理装置における変更後のアプリケーションソフトウェアの構成の一例を示す図である。変更後の設定情報データ群に格納されている設定情報の一例を示す図である。システム変更を加えた場合のオブジェクトデータの構造の一例を示す図である。

以下、図面を参照して、本発明の一実施形態について説明する。なお、本実施形態では、本発明を適用した車載処理装置の一例として、ＡＤＡＳや自動運転システムにおいて車両の運転支援または走行制御を実現するための処理を行う装置を説明する。

（車両システムの構成）
図１は、本発明の一実施形態に係る車載処理装置を含む車両システム１の構成の一例を示す機能ブロック図である。本実施形態に係る車両システム１は、車両２に搭載され、車両２の周辺における走行道路や周辺車両等の障害物の状況を認識した上で、適切な運転支援あるいは走行制御を行うためのシステムである。図１に示すように、車両システム１は、車載処理装置１０、外界センサ群２０、内界センサ群３０、地図情報管理装置４０、アクチュエータ群５０、車載用ＨＭＩ装置６０、等を含んで構成される。

車載処理装置１０は、例えば、車両２に搭載されたＥＣＵ等であり、処理部１００と、信号入出力部１１０と、記憶部１２０と、を有する。なお、車両システム１には、実現しようとする処理の内容や制御対象とする装置の違いに応じて、様々な種類の車載処理装置１０が実際には搭載されているが、図１ではそのうち一つを代表例として示している。

処理部１００は、例えば、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ：中央演算処理装置）、ＧＰＵ（ＧｒａｐｈｉｃｓＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−ＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）等を含んで構成される。処理部１００は、記憶部１２０に格納されている処理ソフトウェア１３０を実行することで、車載処理装置１０の機能を実現する処理を行う。

信号入出力部１１０は、信号入力部１１１と信号出力部１１２で構成される。信号入力部１１１は、車載処理装置１０の外部からの入力信号のデータ化を行い、入力信号に基づく入力データを生成して処理部１００に出力する。この入力データに基づき、処理部１００は出力データの演算を行う。信号出力部１１２は、処理部１００から渡された出力データに基づき出力信号を生成し、生成した出力信号を車載処理装置１０の外部に出力する。信号入出力部１１０は、例えば、アナログ信号をＡ／Ｄ変換する回路、パルス信号を入力する回路、Ｅｔｈｅｒｎｅｔ（登録商標）又はＣＡＮ（ＣｏｎｔｒｏｌｌｅｒＡｒｅａＮｅｔｗｏｒｋ）等の通信規格に準拠したネットワークカード等を含んで構成され、車両２に搭載された他の装置と各種プロトコルに基づきデータの送受信を行う。

記憶部１２０は、例えば、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）や、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）、フラッシュメモリ、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）などの記憶装置を含んで構成される。記憶部１２０には、車載処理装置１０の機能実現のためのプログラムである処理ソフトウェア１３０や、その処理に必要なデータ群等が格納される。また、処理部１００が処理ソフトウェア１３０を実行する際の主記憶としても利用される。

外界センサ群２０は、車両２周辺の状態を検出する外界センサの集合であり、例えば、カメラ装置、ミリ波レーダ、ＬＩＤＡＲ、ソナー等が該当する。外界センサ群２０は、車両２から所定範囲の障害物（他車両、自転車、歩行者、落下物等）や道路形状（白線、路端等）、交通ルール（道路標識、信号等）等の環境要素に関する情報を検出し、その検出情報をＣＡＮ等の車載ネットワークを介して車載処理装置１０に出力するように構成されている。

内界センサ群３０は、車両２の状態に関する各種の状態量（例えば走行速度、操舵角、アクセルの操作量、ブレーキの操作量等）を検出する内界センサの集合である。内界センサ群３０は、検出した状態量をＣＡＮ等の車載ネットワークを介して車載処理装置１０に定期的に出力する。なお、車両システム１は、車載ネットワークに接続された車載処理装置１０を含む各装置が、内界センサ群３０から車載ネットワークを介して必要な状態量を取得することが可能となるように構成されている。

地図情報管理装置４０は、車両２周辺のデジタル地図情報を管理および提供する装置であり、例えば、ナビゲーション装置等が該当する。地図情報管理装置４０は、例えば、所定の地域全体あるいは車両２周辺の地域を表すデジタル道路地図データを備えており、全地球航法衛星システム（ＧＮＳＳ）受信装置等を通じて決定された車両２の位置情報に基づき、地図データ上で車両２の地図位置（走行中の道路、車線等）を特定するように構成されている。また、特定した車両２の地図位置やその周辺の地図データを車載処理装置１０に提供するように構成されている。

アクチュエータ群５０は、車両２の動きを決定する操舵、ブレーキ、アクセル等の制御要素を制御する装置群である。アクチュエータ群５０は、運転者によるハンドル、ブレーキペダル、アクセルペダル等の操作情報や車載処理装置１０から出力される制御情報に基づいて、車両２の動きを制御するように構成されている。

車載用ＨＭＩ装置６０は、例えば、車両２に搭載されたスピーカやディスプレイ装置等であり、車載処理装置１０から出力される周辺環境や運転支援に関する情報を、音声や画面を通じてドライバに通知するように構成されている。

図１の車両システム１において、車載処理装置１０は、その処理の内容に応じて、外界センサ群２０、内界センサ群３０、地図情報管理装置４０、アクチュエータ群５０、車載用ＨＭＩ装置６０のうち任意のハードウェアとの間で、情報の受け渡しを行う。すなわち、車両システム１において実際に搭載されている複数の車載処理装置１０がそれぞれ情報の受け渡しを行う外部ハードウェアの種類は、車載処理装置１０の種類ごとに異なっている。

（処理ソフトウェアの構成）
図２は、本発明の一実施形態に係る車載処理装置１０における処理ソフトウェア１３０の構成の一例を示す図である。図２に示すように、処理ソフトウェア１３０は、アプリケーションソフトウェア１３１と、基本ソフトウェア１３２と、で構成されている。

アプリケーションソフトウェア１３１は、車載処理装置１０の機能を実現するための処理や演算を処理部１００に実行させるソフトウェアである。アプリケーションソフトウェア１３１の構成は、当該車載処理装置１０が実現する処理の内容や、当該車載処理装置１０が情報の受け渡しを行う外部ハードウェアの構成に応じて、車載処理装置１０の種類ごとに異なっている。なお、アプリケーションソフトウェア１３１の構成の具体例については、後で図３を参照して説明する。

基本ソフトウェア１３２は、車載処理装置１０の動作に必要な基本機能を実現するための処理を処理部１００に実行させるソフトウェアである。基本ソフトウェア１３２が担う基本機能は、アプリケーションソフトウェア１３１の構成や、情報の受け渡しを行う外部ハードウェアの構成に拠らず、車両システム１に搭載される全ての車載処理装置１０について共通である。基本ソフトウェア１３２は、例えば、基本入出力システム（ＢＩＯＳ）１３４と、オペレーティングシステム（ＯＳ）１３５と、デバイスドライバ群１３６と、プロトコルスタック１３７と、で構成されている。車載処理装置１０において処理部１００は、基本ソフトウェア１３２を構成するこれらのソフトウェアを用いて、アプリケーションソフトウェア１３１の実行制御や、信号入出力部１１０との間でデータ入出力等を行うことができる。

ＢＩＯＳ１３４は、車載処理装置１０の起動時に必要な処理を処理部１００に実行させるためのソフトウェアである。処理部１００は、ＢＩＯＳ１３４を用いて、例えば起動時のＯＳ１３５の読み込みや、記憶部１２０等に対する基本的な入出力制御等を行う。

ＯＳ１３５は、処理部１００におけるアプリケーションソフトウェア１３１の実行制御に必要な処理を担うソフトウェアである。処理部１００は、ＯＳ１３５を用いて、例えばアプリケーションソフトウェア１３１の実行単位（スレッド、プロセス、タスク等）ごとに実行スケジュールの制御等を行う。

デバイスドライバ群１３６は、処理部１００が信号入出力部１１０との間でデータを入出力するためのソフトウェアである。デバイスドライバ群１３６は、アプリケーションソフトウェア１３１に対して、車載処理装置１０が情報の受け渡しを行う外部ハードウェアを抽象化して取り扱うためのインタフェースを提供する。

プロトコルスタック１３７は、アプリケーションソフトウェア１３１とデバイスドライバ群１３６との間で必要な通信プロトコル処理を実現するためのソフトウェアである。プロトコルスタック１３７は、信号入出力部１１０が処理する下位層の通信プロトコルに対して、その上位層で動作する通信プロトコルの処理を担う。これにより、デバイスドライバ群１３６と同様に、アプリケーションソフトウェア１３１に対して、車載処理装置１０が情報の受け渡しを行う外部ハードウェアを抽象化して取り扱うためのインタフェースを提供する。プロトコルスタック１３７が取り扱う通信プロトコルとしては、例えば、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）等が該当する。

アプリケーションソフトウェア１３１は、デバイスドライバ群１３６とプロトコルスタック１３７とが提供する汎用的なインタフェースを用いることで、外部ハードウェアの具体的なハードウェア構成や入出力信号を意識せずに、信号入出力部１１０との間でデータの入出力を行うことができる。なお、このような汎用的なインタフェースとしては、例えばソケットインタフェースが該当する。

処理部１００において、信号入出力部１１０から読み出された入力データ１４２は、対応するデバイスドライバ群１３６とプロトコルスタック１３７を介して、アプリケーションソフトウェア１３１に渡される。一方、アプリケーションソフトウェア１３１から渡された出力データ１４３は、同様にしてプロトコルスタック１３７とデバイスドライバ群１３６を介して、信号入出力部１１０に書き出される。

処理ソフトウェア１３０を図２のような構成とすることで、車載処理装置１０のハードウェア構成に変更があっても、基本ソフトウェア１３２の一部（ＢＩＯＳ１３４とデバイスドライバ群１３６）のみを変更すればよく、アプリケーションソフトウェア１３１を流用することが可能である。また、車載処理装置１０におけるアプリケーションソフトウェア１３１の構成や、車載処理装置１０に接続される外部ハードウェアの構成が変更されても、基本ソフトウェア１３２を変更する必要がない。

（アプリケーションソフトウェアの構成）
図３は、本発明の一実施形態に係る車載処理装置１０におけるアプリケーションソフトウェア１３１の構成の一例を示す図である。図３に示すように、アプリケーションソフトウェア１３１は、データ適合層２００と、データ管理層２３０と、データ演算層２４０と、の３階層で構成されている。

データ適合層２００は、基本ソフトウェア１３２で扱うデータ形式とデータ管理層２３０で扱うデータ形式との間で、データ形式の変換を行うための階層である。前述のように、基本ソフトウェア１３２のデバイスドライバ群１３６やプロトコルスタック１３７が提供するインタフェースにおいて扱われるデータは、通常、車載処理装置１０が通信相手である外部ハードウェアとの間でやり取りするデータそのものである。すなわち、アプリケーションソフトウェア１３１の入力データ１４２や出力データ１４３のデータ形式は、車載処理装置１０に外部ハードウェアとして接続される図１の外界センサ群２０、内界センサ群３０、地図情報管理装置４０、アクチュエータ群５０、車載用ＨＭＩ装置６０等の仕様に依存する。そのため、データ適合層２００は、これらの外部ハードウェアにそれぞれ対応する複数のソフト部品により構成されている。図３の例では、データ適合層２００は、外界センサ群２０または内界センサ群３０にそれぞれ対応するセンサＡデータ適合部２０１およびセンサＢデータ適合部２０２と、地図情報管理装置４０に対応する地図情報管理装置データ適合部２１１と、車載用ＨＭＩ装置６０に対応する車載用ＨＭＩ装置データ適合部２１２と、アクチュエータ群５０にそれぞれ対応するアクチュエータＡデータ適合部２２１およびアクチュエータＢデータ適合部２２２と、の各ソフト部品で構成されている。これらの各ソフト部品が、対応する外部ハードウェアとデータ管理層２３０との間で、それぞれのデータ形式に応じたデータ形式の変換を行う。

なお、データ管理層２３０では、後述するようにオブジェクトデータという抽象化したデータ形式を用いてデータの管理を行う。そのため、データ適合層２００の各ソフト部品は、入力データ１４２に基づきオブジェクトデータを生成してデータ管理層２３０へ出力したり、データ管理層２３０からのオブジェクトデータに基づき出力データ１４３を生成したりする。

また、車載処理装置１０と接続される外部ハードウェアによっては、車載処理装置１０との間でデータのやり取りをする際に、プロトコルスタック１３７よりも上位の通信プロトコルとして、そのハードウェアに特有の所定のデータ通信の手続（例えば、データ要求の送信等）が必要な場合がある。そのような、基本ソフトウェア１３２では対応できないハードウェア特有のデータ通信プロトコルの処理も、データ適合層２００において対応するソフト部品の中で吸収することが好ましい。例えば、地図情報管理装置データ適合部２１１は、上記のようなハードウェア特有の通信プロトコル処理として、地図情報管理装置４０から地図情報を入力データとして取得する際に、地図情報の提供を要求するメッセージを地図情報管理装置４０に対して送信する。

上記のように、アプリケーションソフトウェア１３１は、外部ハードウェアに対応する個々のソフト部品を互いに独立してデータ適合層２００を構成している。そのため、車載処理装置１０において外部ハードウェアの変更や追加があっても、それに対応するソフト部品のみ変更や追加をすればよく、他のソフト部品には影響を与えない。また、データ適合層２００では、個々のソフト部品により、外部ハードウェアに依存するデータ形式を依存しないデータ形式に変換することでオブジェクトデータを生成し、上位階層であるデータ管理層２３０やデータ演算層２４０に渡すようにしている。これにより、車載処理装置１０に接続される外部ハードウェアの構成に変更や追加があっても、データ管理層２３０やデータ演算層２４０には影響が及びにくい。

データ管理層２３０は、記憶部１２０上（特に、ＲＡＭ上）におけるデータの管理や操作を行う機能と、他の階層に対する共通インタフェースとを提供するための階層である。データ管理層２３０では、所定の対象要素に対応するデータの集合であるオブジェクトデータを単位として、記憶部１２０上でデータの管理および操作を行う。

なお、オブジェクトデータが対応する「対象要素」とは、オブジェクトデータとして一纏めにした個々の情報要素が共通して表現する概念的な対象であり、例えば、外界センサ群２０や内界センサ群３０を構成する各種センサの検出対象や、アクチュエータ群５０を構成する各種アクチュエータの制御対象などが該当する。好ましくは、特に外界センサ群２０を構成する各外界センサについては、当該外界センサで認識された個々の環境要素（障害物、道路形状、交通ルール等）が対象要素に該当する。すなわち、外界センサというハードウェアそのものを抽象化するのではなく、外界センサの検出対象である環境要素を単位としてデータを抽象化し、オブジェクトデータとする方式を採ることが好ましい。なお、内界センサ群３０を構成する各内界センサについては、各内界センサが状態量を検出する車両２を対象としてオブジェクトデータを構成しても良いし、個々の検出対象（例えば、車速センサであれば車速情報）毎にオブジェクトデータを構成しても良い。

データ管理層２３０は、オブジェクトデータ管理部２３１、オブジェクトデータ操作インタフェース２３２、オブジェクトデータ群２３３、および設定情報データ群２３４で構成される。

オブジェクトデータ管理部２３１は、オブジェクトデータ操作インタフェース２３２を介して他の階層から受けたデータ操作要求に基づき、記憶部１２０上で管理しているオブジェクトデータ群２３３に対してデータ操作を行い、その結果を返す。データ操作とは、例えば、オブジェクトデータの登録、更新、検索、統合等が含まれる。

オブジェクトデータ操作インタフェース２３２は、他の階層であるデータ適合層２００およびデータ演算層２４０がオブジェクトデータ管理部２３１の提供するデータ操作機能を利用するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）に相当する。オブジェクトデータ群２３３を構成する各オブジェクトデータは、その対象要素に応じてデータ構造が異なる。そのため、オブジェクトデータ操作インタフェース２３２は、任意のオブジェクトデータを共通の操作手法で操作可能とするためのインタフェース（ＡＰＩ）を提供する。

オブジェクトデータ群２３３は、オブジェクトデータ管理部２３１が記憶部１２０上で管理しているオブジェクトデータの集合である。

設定情報データ群２３４は、オブジェクトデータ管理部２３１がオブジェクトデータ群２３３の管理やデータ操作を行うために必要な設定情報の集合である。外界センサの構成変更等によりオブジェクトデータの構造が変更された場合は、それに合わせて、設定情報データ群２３４において当該オブジェクトデータに対応する設定情報が変更される。これにより、データ管理層２３０は、オブジェクトデータ管理部２３１やオブジェクトデータ操作インタフェース２３２に変更を加えずに、オブジェクトデータの変更に対応可能なように構成されている。

データ演算層２４０は、データ管理層２３０から演算対象とするオブジェクトデータを取得し、該オブジェクトデータに基づき出力データを演算するための階層である。通常、出力データを演算する処理は、その演算内容に応じて複数の処理ブロックで構成される。そのため、データ演算層２４０は、個々の処理ブロックに対応する複数のソフト部品により構成されている。図３の例では、データ演算層２４０は、センサフュージョン演算部２４１と、地図フュージョン演算部２４２と、行動予測演算部２４３と、自動運転制御演算部２４４と、の各ソフト部品で構成されている。これらの各ソフト部品が行う演算処理により、外界センサ群２０や内界センサ群３０で検出された各種情報に基づき、車載処理装置１０が搭載される車両２における自動運転の制御情報が演算される。

センサフュージョン演算部２４１は、外界センサ群２０に含まれる複数の外界センサで検出した同一の対象要素に対するオブジェクトデータを同定・統合したり、時系列情報に基づいて欠落データを補間したりする処理を行う。地図フュージョン演算部２４２は、外界センサの検出情報と、地図情報管理装置４０から取得した地図データの情報とを照合し、外界センサの検出情報に地図データの情報（例えば、他車両が走行している車線ＩＤ等）を属性として付加する処理を行う。行動予測演算部２４３は、外界センサで検出した移動体の将来の行動や移動軌道を予測する処理を行う。自動運転制御演算部２４４は、センサフュージョン演算部２４１、地図フュージョン演算部２４２および行動予測演算部２４３の演算結果に基づいて、車両２の運転行動や走行軌道、速度プロファイル等を決定する。また、決定したこれらの情報を基に、アクチュエータ群５０に対する制御情報や、車載用ＨＭＩ装置６０に対する表示情報を演算し、その演算結果をデータ適合層２００に出力する。なお、図３の例では、アクチュエータ群５０や車載用ＨＭＩ装置６０に固有の通信仕様を吸収するため、自動運転制御演算部２４４は、データ適合層２００の車載用ＨＭＩ装置データ適合部２１２やアクチュエータＡデータ適合部２２１、アクチュエータＢデータ適合部２２２を介して、出力データ１４３を生成している。しかし、このようにはせず、自動運転制御演算部２４４がアクチュエータ群５０や車載用ＨＭＩ装置６０の通信仕様に合わせたデータを生成し、データ適合層２００を介さずに直接基本ソフトウェア１３２に出力データ１４３を出力するような形態を取ってもよい。

ここで、本実施形態によるアプリケーションソフトウェア１３１の構成と、従来技術によるアプリケーションソフトウェアの構成との違いについて説明する。従来技術では、センサやアクチュエータのインタフェース（データ）を抽象化する階層、すなわち図３のデータ適合層２００に相当する階層と、抽象化されたデータを用いて演算する階層、すなわち図３のデータ演算層２４０に相当する階層との、言わば２階層の構成であった。それに対して、図３に例示したアプリケーションソフトウェア１３１の構成では、従来のデータ抽象化のアプローチに加えて、データの管理および操作を抽象化したデータ管理層２３０を導入している点が特徴である。

ＡＤＡＳや自動運転における演算処理は、主に、外界センサの検出情報等の情報に基づいて車両２の周辺環境を高次に理解する認知処理と、認知処理の結果に基づいて車両２の運転行動や走行軌道を判断する判断処理とで構成される。これらの処理は、基本的に他車両や白線等の環境要素を単位として行われるものである。そのため、認知処理と判断処理とでは、データ管理、対象データ検索、他ソフト部品に対するデータ提供等、環境要素単位でのデータ管理・操作が共通して含まれることが多い。本発明はこの点に着目したものであり、データ管理層２３０において環境要素単位でのデータ管理・操作を抽象化して共通利用できるようにすることにより、従来の演算処理部分におけるソフトウェアの開発効率を向上させている。

また、前述のようにデータ管理層２３０は、オブジェクトデータ管理部２３１で管理しているオブジェクトデータのデータ構造が変更されても、設定情報データ群２３４の設定を変更するだけで、他の階層に対するインタフェースを変更せずに利用できるように構成されている。そのため、従来のデータ抽象化のアプローチだけではソフトウェアの再利用性が限定的であった状況、例えばデータ構造の変更を必要とする外界センサの構成変更時などにおいても、高いソフトウェアの再利用性を維持することができる。

また、データ管理層２３０の導入により、アプリケーションソフトウェア１３１において、データ管理層２３０が担うデータ管理機能と、データ演算層２４０が担う演算処理とを、機能的に分離することができる。そのため、演算処理の独立性が向上し、演算処理の変更や追加が容易になるという効果がある。詳しく説明すると、従来の方式では、演算処理ごとの処理ブロックを構成するソフト部品間でのデータの受け渡しを実現するために、ソフト部品間で必要なデータ変換を行うインタフェースを、図３のデータ演算層２４０に相当する階層内に構築していた。しかしこの方式では、あるソフト部品の修正が他のソフト部品にも影響を及ぼす可能性が高い。それに対し、本実施形態によるアプリケーションソフトウェア１３１の構成では、データ演算層２４０において演算処理を行う各ソフト部品は、原則として、データ管理層２３０のオブジェクトデータ操作インタフェース２３２を介して、互いにデータの受け渡しを行う。オブジェクトデータ操作インタフェース２３２は、データ演算層２４０のソフト部品間で受け渡されるデータを抽象化されたオブジェクトデータとして取り扱うことで、各ソフト部品に対して共通のＡＰＩを提供している。そのため、データ演算層２４０の各ソフト部品は、操作対象のデータの提供元も利用先も意識する必要がない。その結果、各ソフト部品の独立性が高まり、他のソフト部品の変更や追加による影響を受けにくい。したがって、アプリケーションソフトウェア１３１の機能構成を変更した場合でも、高いソフトウェアの再利用性を維持することが可能である。

（オブジェクトデータ）
図４は、オブジェクトデータ群２３３に格納されているオブジェクトデータの一例を示す図である。前述のように、オブジェクトデータ群２３３は、オブジェクトデータ管理部２３１が記憶部１２０上で管理しているオブジェクトデータの集合である。図４に示すように、オブジェクトデータ群２３３の各オブジェクトデータは、全てのオブジェクトデータに共通する情報であるＩＤ４０１、データソース４０２、オブジェクト種別４０３およびタイムスタンプ４０４の各情報が格納される共通データ領域４００と、対象要素の種類に応じてオブジェクトデータごとに異なる情報が格納される固有データ領域４０５とで構成される。

ＩＤ４０１には、該オブジェクトデータが示す対象要素を識別するための識別子が格納される。同一の対象要素（例えば、同じ車両）を示す複数のオブジェクトデータには、ＩＤ４０１において同一の値が設定される。

データソース４０２には、該オブジェクトデータの生成元を示す情報が格納される。例えば、ＩＤ４０１の値がＩＤ＝１００であるオブジェクトデータ４１０は、データソース４０２に「センサＡ」が設定されている。これは、オブジェクトデータ４１０の生成元が外界センサ群２０に含まれるセンサＡ（実際には、センサＡデータ適合部２０１）であることを表している。また、ＩＤ４０１の値がＩＤ＝１０００であるオブジェクトデータ４１１は、データソース４０２に「センサフュージョン」が設定されている。これは、オブジェクトデータ４１１の生成元がセンサフュージョン演算部２４１であることを表している。

オブジェクト種別４０３には、該オブジェクトデータが示す対象要素の概念的な種別を表す情報が格納される。オブジェクト種別４０３に格納される対象要素の種別には、例えば他車両、歩行者、白線等が挙げられる。

タイムスタンプ４０４には、該オブジェクトデータに関する時間情報が格納される。タイムスタンプ４０４に設定される時間情報は、例えば、データソース４０２が表す該オブジェクトデータの生成元が外界センサ群２０や内界センサ群３０に含まれるセンサである場合は、該オブジェクトデータを検出した時刻に相当する。これにより、任意の時点における該オブジェクトデータの状態を推測する際に、該オブジェクトデータに時間に応じた補正をかけることが可能となる。なお、タイムスタンプ４０４には、車載処理装置１０におけるオブジェクトデータの時間管理のポリシーに応じて、例えばデータ管理層２３０における該オブジェクトデータの更新時刻など、別の時間情報を格納してもよい。

固有データ領域４０５には、データソース４０２とオブジェクト種別４０３の組合せに応じて、オブジェクトデータごとに異なるデータが格納されている。例えば、ＩＤ４０１の値がＩＤ＝１００であるオブジェクトデータ４１０と、ＩＤ４０１の値がＩＤ＝１０１であるオブジェクトデータ４１２とは、データソース４０２が表す生成元が共に「センサＡ」であるため、同じセンサＡの検出情報を表している。しかし、オブジェクト種別４０３が表す対象要素の種別は、オブジェクトデータ４１０では「他車両」であり、オブジェクトデータ４１２では「歩行者」である。したがって、これらのオブジェクトデータが表すセンサＡの検出情報の内容は、対象要素の違いに応じて互いに異なっており、固有データ領域４０５に格納されるデータも異なる。また、例えば、ＩＤ４０１の値がＩＤ＝１００であるオブジェクトデータ４１０と、ＩＤ４０１の値がＩＤ＝２００であるオブジェクトデータ４１３とは、オブジェクト種別４０３が表す対象要素の種別が共に「他車両」であるため、同じ他車両に関する検出情報を表している。しかし、データソース４０２が表す生成元は、オブジェクトデータ４１０では「センサＡ」であり、オブジェクトデータ４１３では「センサＢ」である。したがって、これらのオブジェクトデータが表す他車両に関する検出情報の内容は、センサＡとセンサＢの仕様の違いに応じて互いに異なっており、固有データ領域４０５に格納されるデータも異なる。

オブジェクトデータ管理部２３１は、共通データ領域４００のＩＤ４０１、データソース４０２、オブジェクト種別４０３およびタイムスタンプ４０４に格納された各情報を用いて、オブジェクトデータ群２３３に格納されている各オブジェクトデータのインデックステーブルを構築している。例えば、ＩＤ４０１の値に基づいたハッシュテーブルをオブジェクトデータ管理部２３１において構築することで、該当するオブジェクトデータを高速に検索できるように構成されている。また、例えば、データソース４０２に格納されている各オブジェクトデータの生成元や、オブジェクト種別４０３に格納されている各オブジェクトデータの対象要素の種別毎に、該当するオブジェクトデータに対する参照リストをオブジェクトデータ管理部２３１において構築することで、生成元や対象要素の種別が同一である複数のオブジェクトデータを高速に取得できるように構成されている。

なお、図４の例では、各オブジェクトデータの固有データ領域４０５に格納されるデータの一例を記載しているが、実際にはデータ管理層２３０は、固有データ領域４０５に格納されているデータの内容を意識しないで、各オブジェクトデータのデータ操作を行うように構成されている。そのため、外界センサ群２０や内界センサ群３０の構成が変わって対応するオブジェクトデータの構造が変更されても、データ管理層２３０のデータ操作に関するソフトウェアを修正する必要がない。

また、データ管理層２３０は、同一の対象要素に関する複数のオブジェクトデータ（すなわち、ＩＤ４０１の値が同一である複数のオブジェクトデータ）を、時系列で所定数管理できるように構成されている。図４の例では、ＩＤ４０１の値がいずれもＩＤ＝３００である過去３回分の３つのオブジェクトデータ４１４と、ＩＤ４０１の値がいずれもＩＤ＝３０１である過去３回分の３つのオブジェクトデータ４１５とが、それぞれ格納されている。こうした時系列での複数のオブジェクトデータの管理は、リングバッファ等の機構を利用することにより実現される。このような時系列での複数のオブジェクトデータは、該対象要素に関する欠落したデータの補間や将来の状態の予測に有効であり、例えば、センサフュージョン演算部２４１や行動予測演算部２４３等で利用される。

なお、図４では、オブジェクトデータ群２３３に格納されているオブジェクトデータの例として、各種センサの検出情報を表すオブジェクトデータを示しているが、それ以外の情報を表すオブジェクトデータをオブジェクトデータ群２３３に格納してもよい。例えば、地図情報管理装置４０から提供される地図情報を所定のデータ単位（例えば、道路区間単位）毎に分解し、オブジェクトデータとしてオブジェクトデータ群２３３に格納してもよい。また、データ演算層２４０を構成するソフト部品のうち、環境要素に関するものを除いたソフト部品からの出力結果を、オブジェクトデータとしてオブジェクトデータ群２３３に格納してもよい。前述の通り、オブジェクトデータの構造は汎用的に作られているため、任意の情報をオブジェクトデータとしてオブジェクトデータ群２３３に格納することが可能である。

また、図４では、共通データ領域４００にＩＤ４０１、データソース４０２、オブジェクト種別４０３およびタイムスタンプ４０４の各情報が設定されている例を示したが、これらの情報の全てを共通データ領域４００に設定しなくてもよい。個々のオブジェクトデータを適切に管理したり、目的のオブジェクトデータを適切に検索したりできるように、共通データ領域４００には任意の情報を設定することができる。

（設定情報）
図５は、設定情報データ群２３４に格納されている設定情報の一例を示す図である。前述のように、設定情報データ群２３４は、外界センサの構成変更等によってオブジェクトデータの構造が変わった場合に変更が必要なパラメータ群の設定値を規定した設定情報の集合である。オブジェクトデータ管理部２３１は、車載処理装置１０の起動時に設定情報データ群２３４から設定情報を読み込み、各オブジェクトデータに対応する設定情報に基づいて、オブジェクトデータ群２３３におけるオブジェクトデータのメモリ管理構造やデータ操作の適合化を行う。これにより、オブジェクトデータ操作インタフェース２３２を修正せずに、オブジェクトデータの変更に対応することを可能としている。図５に示すように、設定情報データ群２３４の各設定情報は、データソース５０１、オブジェクト種別５０２、データ長５０３、履歴数５０４および検索キー情報５０５で構成される。

データソース５０１およびオブジェクト種別５０２は、図４のデータソース４０２およびオブジェクト種別４０３とそれぞれ同様である。データソース５０１とオブジェクト種別５０２にそれぞれ格納される情報の組合せにより、各設定情報が対象とするオブジェクトデータの種別（データ種別）が規定される。

データ長５０３には、該データ種別に対応するオブジェクトデータのデータ長が格納される。

履歴数５０４には、該データ種別において、データ管理層２３０が同一対象要素の時系列データをいくつ管理するかを示す情報が格納される。例えば、履歴数５０４に格納された値が１の場合は、時系列データを持たずに、最新値を示すオブジェクトデータだけが保存されることを意味している。

検索キー情報５０５には、図４の固有データ領域４０５に格納されるオブジェクトデータの情報要素を用いて検索等のデータ操作を行う場合の設定情報が格納される。図５の例では、検索キー情報５０５において、該情報要素の識別子（Ｋｅｙ）、該情報要素のデータ型（Ｔｙｐｅ）、該オブジェクトデータの先頭アドレスから該情報要素のアドレスまでのオフセット値（Ｏｆｆｓｅｔ）が指定される。例えば、図５の最初のデータレコードにおける検索キー情報５０５は、生成元がセンサＡであり、対象要素の種別が他車両であるオブジェクトデータにおいて、「相対位置」と「相対速度」という情報要素が、「２ＤＶｅｃｔｏｒ（２次元ベクトル）」というデータ型で、それぞれ先頭から１２バイトと２０バイトの位置に格納されていることを示している。このように、固有データ領域４０５の情報要素についても、設定情報において検索キー情報５０５を付加することにより、オブジェクトデータ操作インタフェース２３２のデータ操作で扱うことを可能としている。すなわち、オブジェクトデータ操作インタフェース２３２によるオブジェクトデータの操作には、設定情報データ群２３４に格納されている設定情報に基づき、所定の検索条件に該当する固有データ領域４０５を有するオブジェクトデータを検索して取得する操作が含まれる。

なお、本実施形態では、設定情報データ群２３４の読み込みによって異なるオブジェクトデータに適合する形態を取っているが、設定情報データ群２３４が存在しなかったとしても、データ管理層２３０の実現性には影響しない。例えば、データ長５０３や履歴数５０４には十分大きな固定値を定めておいてもよいし、検索キー情報５０５は付加機能であるため存在しなくても問題がない。また、オブジェクトデータ管理部２３１がアプリケーションソフトウェア１３１の実行時に設定情報データ群２３４を読み込むような形態ではなく、他の形態、例えばコンパイル時に静的に設定情報データ群２３４を設定するような形態でもよい。

（オブジェクトデータ操作インタフェース）
図６および図７は、オブジェクトデータ操作インタフェース２３２の一例を示す図である。図６に示す疑似コード群Ｃ６０１および図７に示す疑似コード群Ｃ７０１は、オブジェクトデータ操作インタフェース２３２をＣ言語でそれぞれ記述した場合のヘッダファイルの一部を表現したものである。疑似コード群Ｃ６０１およびＣ７０１には、オブジェクトデータ操作インタフェース２３２のＡＰＩとデータ型の例がそれぞれ記載されている。

疑似コード群Ｃ６０１は、オブジェクトデータの登録ＡＰＩを表す疑似コード６１１と、オブジェクトデータの更新ＡＰＩを表す疑似コード６１２と、オブジェクトデータのＩＤ検索ＡＰＩを表す疑似コード６１３と、オブジェクトデータの検索ＡＰＩを表す疑似コード６１４と、オブジェクトデータの統合ＡＰＩを表す疑似コード６１５と、オブジェクトデータの履歴情報検索ＡＰＩを表す疑似コード６１６と、を含む。以下では、これらの疑似コードが表すＡＰＩについて説明する。

疑似コード６１１が表すオブジェクトデータの登録ＡＰＩ（registerData）は、データ管理層２３０に新たに入力されたオブジェクトデータをオブジェクトデータ群２３３に格納する操作である「登録操作」のＡＰＩである。この登録操作では、データ管理層２３０が複数のオブジェクトデータを時系列で管理する設定になっている場合は、既にオブジェクトデータ群２３３に格納されている複数のオブジェクトデータに、新たに入力されたオブジェクトデータを最新値として挿入（追加）し、格納されていた時系列データの世代を１つずつずらす操作を行う。一方、オブジェクトデータを時系列で管理しない設定になっている場合は、新たに入力されたオブジェクトデータと同一の対象要素を表すオブジェクトデータを、新しいオブジェクトデータに置き換える操作を行う。疑似コード６１１で表されるように、登録ＡＰＩの引数は、登録対象のオブジェクトデータのデータ長と、登録対象のオブジェクトデータのアドレスとで構成される。なお、登録対象のオブジェクトデータの先頭には、図４で示したように、ＩＤ４０１、データソース４０２、オブジェクト種別４０３およびタイムスタンプ４０４で構成される共通データ領域４００が必ず含まれている。オブジェクトデータ管理部２３１は、共通データ領域４００に格納されているこれらの情報に基づき、該オブジェクトデータの格納場所をオブジェクトデータ群２３３において特定し、その場所に格納する。

疑似コード６１２が表すオブジェクトデータの更新ＡＰＩ（updateData）は、オブジェクトデータ群２３３に格納されているオブジェクトデータの一部または全部の領域を、データ管理層２３０に新たに入力されたオブジェクトデータに基づいて書き換える操作である「更新操作」のＡＰＩである。なお、データ管理層２３０が複数のオブジェクトデータを時系列で管理する設定になっている場合は、前述の登録操作とは異なり、更新操作では、既にオブジェクトデータ群２３３に格納されている複数のオブジェクトデータのうち、最新のオブジェクトデータの一部または全部が、新たに入力されたオブジェクトデータに基づいて書き換えられる。疑似コード６１２で表されるように、更新ＡＰＩの引数には、登録ＡＰＩと同様の情報に加えて、当該オブジェクトデータにおける更新対象の領域を指定するための情報が追加されている。

疑似コード６１３が表すオブジェクトデータのＩＤ検索ＡＰＩ（getDataByID）は、オブジェクトデータ群２３３に格納されているオブジェクトデータの中から、指定するＩＤを持つオブジェクトデータの最新値を検索して返す操作である「ＩＤ検索操作」のＡＰＩである。疑似コード６１３で表されるように、ＩＤ検索ＡＰＩの引数は、検索対象のオブジェクトデータのＩＤと、検索結果を格納するバッファの情報とを含む。

疑似コード６１４が表すオブジェクトデータの検索ＡＰＩ（searchData）は、オブジェクトデータ群２３３に格納されているオブジェクトデータの中から、所定の検索条件に該当するオブジェクトデータを取得する操作である「検索操作」のＡＰＩである。疑似コード６１４で表されるように、検索ＡＰＩの引数は、検索条件式と、ソート条件式と、検索結果を格納するバッファの情報とを含む。この検索操作では、検索条件式に該当するオブジェクトデータのリストをソート条件式に従い整列した結果がバッファに格納される。

検索ＡＰＩにおける検索条件式とソート条件式は、例えば、図７の疑似コード群Ｃ７０１で表現される。疑似コード群Ｃ７０１は、検索条件式を表す疑似コード７１１と、ソート条件式を表す疑似コード７１２と、を含む。

疑似コード７１１は、検索条件式において検索対象とするオブジェクトデータの情報要素を指定するためのキー（key）と、キーで指定された情報要素の値を比較演算するための比較演算子（compOp）および比較対象値（value）と、比較演算の結果を論理演算するための論理演算子（logicOp）と、を定義している。検索条件式は、これらの配列として、例えば以下の式（１）、（２）のように表現される。ただし、式（１）、（２）では、引数に与えたキーに該当する値を返す連想配列（objectData）を用いて検索条件式を表現している。検索ＡＰＩでは、こうした検索条件式に従って、オブジェクトデータ群２３３に格納されているオブジェクトデータの中から、所定の検索条件に該当するオブジェクトデータを検索して取得することができる。
{objectData[key0] <compOp0> value0} <logicOp0> ・・・（１）
{objectData[key1] <compOp1> value1} <logicOp1> ・・・（２）

疑似コード７１２は、ソート条件式においてソート対象とオブジェクトデータの情報要素を指定するためのキー（key）と、キーで指定された情報要素をソートするためのソート順序（order）と、を定義している。ソート条件式は、これらの配列として表現される。検索ＡＰＩでは、こうしたソート条件式に従って、所定の検索条件に該当するオブジェクトデータを、指定されたキーの値を基準に指定されたソート順序（昇順、降順等）でソートして取得することができる。

なお、検索条件式やソート条件式のキーに相当する情報要素が当該オブジェクトデータにおいて複数存在する場合、比較演算やソートに用いるスカラー値の算出方法が別途定義されていてもよい。例えば、相対位置や相対速度の情報要素を含むオブジェクトデータに対して、検索条件式やソート条件式で「２ＤＶｅｃｔｏｒ」を指定した場合は、当該ベクトルの長さ（ベクトルの各要素の平方和）を用いて比較演算やソートが行われる。これにより、距離検索等の操作が可能となる。

図６に示す疑似コード群Ｃ６０１の説明に戻ると、疑似コード６１５が表すオブジェクトデータの統合ＡＰＩ（mergeData）は、オブジェクトデータ群２３３に格納されている２つのオブジェクトデータを１つに統合する「統合操作」のＡＰＩである。疑似コード６１５で表されるように、統合ＡＰＩの引数は、統合先のオブジェクトデータのＩＤ（destId）と、統合元のオブジェクトデータのＩＤ（srcId）とを含む。この統合操作では、データ管理層２３０が時系列で管理する複数のオブジェクトデータのうち、統合先ＩＤで指定される複数のオブジェクトデータに、統合元ＩＤで指定される複数のオブジェクトデータが組み込まれる。

疑似コード６１６が表すオブジェクトデータの履歴情報検索ＡＰＩ（getHistoryData）は、オブジェクトデータ群２３３に格納されている複数のオブジェクトデータの中から、指定するＩＤを持つ時系列で管理された複数のオブジェクトデータを、当該オブジェクトデータの時系列情報として取得する操作である「履歴情報検索操作」のＡＰＩである。疑似コード６１６で表されるように、履歴情報検索ＡＰＩの引数は、検索対象とするオブジェクトデータのＩＤと、検索結果を格納するバッファの情報とを含む。

以上のように、オブジェクトデータ操作インタフェース２３２は、オブジェクトデータのデータ構造に依存しないデータ型で引数が定義されている。そのため、車載処理装置１０に接続される外部ハードウェアの構成や、車載処理装置１０に搭載される機能構成等に変更があっても、オブジェクトデータ操作インタフェース２３２を修正する必要がない。

（アプリケーションソフトウェアの処理フロー）
図８は、本発明の一実施形態に係る車載処理装置１０におけるアプリケーションソフトウェア１３１の処理フローの一例である処理フロー８００を示す図である。図８に示す処理フロー８００は、アプリケーションソフトウェア１３１により、車載処理装置１０の処理部１００において、例えば所定の時間間隔（１００ｍｓ等）で定期的に実行される。なお、本実施形態では、逐次的に各処理ステップが実行される処理フロー８００としてアプリケーションソフトウェア１３１の処理を説明するが、各処理ステップは所定のイベントに基づいて非同期に実行しても良いし、並列実行しても良い。

処理フロー８００において、処理部１００は、初めに外部入力処理（Ｓ８０１）を実行する。この外部入力処理は、データ適合層２００の各ソフト部品が、基本ソフトウェア１３２から通知された入力データ１４２を処理して、データ管理層２３０にオブジェクトデータを登録する処理である。図３で示したように、データ適合層２００は、車載処理装置１０の外部に接続されるハードウェアからの入力データ１４２に対応するソフト部品として、センサＡデータ適合部２０１、センサＢデータ適合部２０２、地図情報管理装置データ適合部２１１等を有している。これらのソフト部品は、対応する外部ハードウェアからの入力データ１４２をそれぞれの通信仕様に基づいて解析し、対象要素に関する情報を抽出する。続いて、抽出した情報を該対象要素に対応するオブジェクトデータの形式に変換し、オブジェクトデータ操作インタフェース２３２の登録ＡＰＩを介して、オブジェクトデータ群２３３に格納する。なお、ここでのオブジェクトデータの形式とは、データ構造だけでなく、各情報要素の表現仕様（例えば、単位系、座標系、時刻系等）も含む。例えば、座標系については、車両２の基準点を原点とし、車両２の正面方向をｘ軸、左方向をｙ軸とした直交座標系で統一する。また、外界センサで表現されるデータは、当該センサの車両２での取り付け位置や当該センサの仕様に依存して変化するため、共通の座標系に変換することで、データ演算層２４０の各ソフト部品がセンサ固有の仕様を意識せずに演算処理を実行できるようにする。時刻系についても同様に、外界センサの仕様に応じて遅れ時間（対象要素を検出した時刻とデータを出力した時刻との差）が異なるので、その遅れ時間の分を補正して、オブジェクトデータのタイムスタンプを設定する。

なお、図４に示したように、オブジェクトデータは、ＩＤ４０１、データソース４０２、オブジェクト種別４０３およびタイムスタンプ４０４を含む共通データ領域４００と、固有データ領域４０５とで構成される。本実施形態では、外界センサの検出情報に対応するオブジェクトデータについては、さらに以下に説明するようにしてデータ構造のモデル化を行い、ソフトウェアの再利用性を高めることも可能である。

図９は、オブジェクトデータのモデル化の一例を示す図である。図９に示すオブジェクトデータの構造例において、共通データ領域９０１と固有データ領域９０２は、それぞれ図４の共通データ領域４００と固有データ領域４０５に該当する。固有データ領域９０２に格納される情報は、データソースやオブジェクト種別に応じて異なるが、同様の性質を持つ対象要素を表現する場合、固有データ領域４０５における情報要素の類似性は高くなる。そこで、性質が近い対象要素毎にデータモデルを構築し、固有データ領域９０２を、データモデルヘッダと固有データに分割する。具体的には、図９に示すように、オブジェクト種別が他車両、歩行者、自転車等であり、これらの物体に関する対象要素の各オブジェクトデータには、共通の物体データモデルヘッダ９１１を適用する。物体データモデルヘッダ９１１には、例えば、相対位置９１５、相対速度９１６等が含まれる。一方、オブジェクト種別が白線、駐車枠、道路境界等であり、境界線や領域に関する対象要素の各オブジェクトデータには、共通の境界データモデルヘッダ９２１を適用する。境界データモデルヘッダ９２１には、例えば、境界種別９２３（白線、駐車枠等）、境界点列情報９２４（境界形状を表現する点列）等が含まれる。このように、共通の性質を持つ対象要素を表現する複数のオブジェクトデータをまとめて、これらのオブジェクトデータに対して共通のデータモデルを構築することで、共通の定義によるデータ領域部分を規定することができる。これにより、オブジェクトデータ内で外界センサの構成変更に影響を受ける部分（各種固有データ９１２、９１３、９１４、９２２等）を局所化して、そうでない部分と区別することができる。そのため、さらにソフトウェアの再利用性を高めることが可能である。

図８の処理フロー８００に説明を戻す。ステップＳ８０１で外部入力処理が終了すると、続いて処理部１００は、データ演算層２４０の各種演算処理に移る。ステップＳ８０２〜Ｓ８０５は、それぞれ、センサフュージョン演算部２４１、地図フュージョン演算部２４２、行動予測演算部２４３、自動運転制御演算部２４４による演算処理である。

ステップＳ８０２〜Ｓ８０４の各演算処理は、車両２の周辺環境を理解（認知）するための演算処理である。そのため、以降ではステップＳ８０２〜Ｓ８０４の各演算処理を、認知処理とも称する。また、これらの演算処理（認知処理）を実行するセンサフュージョン演算部２４１、地図フュージョン演算部２４２、行動予測演算部２４３を、それぞれ環境認知ソフト部品とも称する。

環境認知ソフト部品で実行される認知処理とは、各外界センサから得られた断片的な検出情報や、地図や通信等で得られる情報等を組み合わせて、各対象要素の状態をより高次に推定するための処理である。例えば、車両２の先行車を対象要素とした場合、センサフュージョン演算処理（Ｓ８０２）では、外界センサだけで検出可能な相対位置や相対速度等の物理的な特性しか把握できない。一方、地図フュージョン演算処理（Ｓ８０３）では、地図データと照合することにより、先行車がどの車線を、車両２とどのような位置関係で走行しているのかを推定できるようになる。また、行動予測演算処理（Ｓ８０４）では、先行車が将来どのような動きをするのかを推定することができる。これらの処理は、該対象要素に関する新しい状態量を推定して追加していく処理、すなわち、該対象要素のオブジェクトデータに新しい情報要素を付加していく処理とみなすことができる。

上記のような認知処理の特徴を踏まえて、本実施形態では、図１０に示すようなデータ構造でオブジェクトデータを構成することも可能である。図１０は、認知処理の部分更新に対応したオブジェクトデータの構造の一例を示す図である。図１０に示すデータ構造では、オブジェクトデータにおける固有データ領域９０２を、それぞれの演算処理の更新対象に応じて分類し、別々のレコード（メモリ上で連続した領域）として構成している。具体的には、センサフュージョン演算処理の更新対象である基本情報レコード１００１と、地図フュージョン演算処理の更新対象である地図属性レコード１００２と、行動予測演算処理の更新対象である予測情報レコード１００３とで、固有データ領域９０２が構成されている。

図１０に示すデータ構造のオブジェクトデータにおいて、ステップＳ８０２でセンサフュージョン演算部２４１が実行したセンサフュージョン演算処理による対象要素の推定結果は、基本情報レコード１００１に格納される。一方、ステップＳ８０３で地図フュージョン演算部２４２が実行した地図フュージョン演算処理による対象要素の推定結果は、地図属性レコード１００２に格納される。また、ステップＳ８０４で行動予測演算部２４３が実行した行動予測演算処理による対象要素の推定結果は、予測情報レコード１００３に格納される。これにより、環境認知ソフト部品であるセンサフュージョン演算部２４１、地図フュージョン演算部２４２および行動予測演算部２４３の各々は、それぞれの認知処理による対象要素の状態の推定結果を、オブジェクトデータにおいて別々のデータ領域に格納することができる。

なお、図９に示したオブジェクトデータの構造例におけるデータモデルヘッダ、すなわち物体データモデルヘッダ９１１や境界データモデルヘッダ９２１を、図１０に示すデータ構造に含めても良い。この場合、基本情報レコード１００１の中にデータモデルヘッダが含まれていても良いし、基本情報レコード１００１、地図属性レコード１００２、予測情報レコード１００３の各レコードに分散してデータモデルヘッダが配置されていても良い。

図１０に示す疑似コードＣ１００４〜Ｃ１００７は、図１０の上記オブジェクトデータの構造体と、ステップＳ８０２〜Ｓ８０４の各認知処理におけるオブジェクト更新処理とをそれぞれ記述した例である。ステップＳ８０２のセンサフュージョン演算処理では、各種外界センサのオブジェクトデータを統合したオブジェクトデータを新しく生成するため、疑似コードＣ１００５で表されるように、オブジェクトデータの更新に登録ＡＰＩが使われる。それに対して、ステップＳ８０３の地図フュージョン演算処理やステップＳ８０４の行動予測演算処理では、疑似コードＣ１００６、Ｃ１００７でそれぞれ表されるように、更新ＡＰＩを用いて、地図属性レコード１００２、予測情報レコード１００３に相当する部分をそれぞれ更新する。

以上説明したようなデータ構造をオブジェクトデータにおいて採用することで、以下に説明する２つの効果がもたらされる。まず１点目の効果としては、疑似コードＣ１００６、Ｃ１００７でそれぞれ表されるオブジェクトデータの更新処理では、お互いに異なるメモリ領域が更新される。そのため、地図フュージョン演算処理と行動予測演算処理とを並列に実行することが可能となる。これにより、処理部１００が複数のプロセッサ、または複数のコアで構成されている場合に、効率的にこれらの演算処理を実行することが可能となる。次に２点目の効果としては、新しい演算処理に関するソフト部品の追加や変更時のソフトウェアの再利用性が向上する。すなわち、新しい演算処理を追加する場合は、疑似コードＣ１００４で表されるオブジェクトデータの構造体に新しいレコードを追加すれば良く、既存のプログラム上の参照関係に影響を及ぼさないため、疑似コードＣ１００６や疑似コードＣ１００７に修正を加えなくても良い。同様にして、演算処理の変更によりデータ構造を変える場合も、変更が必要な部分は基本情報レコード１００１、地図属性レコード１００２、予測情報レコード１００３の各レコード内に限定されるため、他の演算処理に影響を与えることはない。

ステップＳ８０５の自動運転制御演算処理は、ステップＳ８０２〜Ｓ８０４の各認知処理の結果に基づいて車両２の制御情報を演算する処理である。自動運転制御演算部２４４は、ステップＳ８０２〜Ｓ８０４の各認知処理によって生成されたオブジェクトデータに基づいて、車両２の運転行動（例えば、車線を追従するか、車線変更をするか等）や、それに基づく走行軌道（速度情報を含む）の計画を立てる。そして、該運転行動の実行や該走行軌道の追従に必要なアクチュエータ群５０に対する制御指令値を演算する。

図８の処理フロー８００に説明を戻す。ステップＳ８０５の自動運転制御演算処理が終了すると、処理部１００は、外部出力処理（Ｓ８０６）に移る。ステップＳ８０６の外部出力処理では、ステップＳ８０５で自動運転制御演算部２４４が演算したアクチュエータ群５０に対する制御指令値を、各アクチュエータの通信仕様に適合したデータ形式に変換し、変換後のデータを出力データ１４３として基本ソフトウェア１３２に出力する。このデータ形式の変換は、各アクチュエータに対応するデータ適合層２００のソフト部品、すなわち図３のアクチュエータＡデータ適合部２２１やアクチュエータＢデータ適合部２２２によって行われる。

以上のような処理の流れにより、図３で示したアプリケーションソフトウェア１３１の１サイクルの処理が実行される。車載処理装置１０では、定期的に（例えば１００ｍｓ毎に）処理フロー８００に従った処理が処理部１００において実行されることで、ＡＤＡＳや自動運転の機能が実現される。

（アプリケーションソフトウェアの修正）
次に、図１１の例を用いて、車載処理装置１０において外部ハードウェア構成や機能構成の変更があった場合のアプリケーションソフトウェア１３１の修正方法について説明する。図１１は、本発明の一実施形態に係る車載処理装置１０における変更後のアプリケーションソフトウェア１３１の構成の一例を示す図である。図１１では、車載処理装置１０に接続される外部ハードウェアとして無線通信装置を追加し、この無線通信装置からの情報を加味して自動運転制御を高度化するシステム変更を行った場合の、アプリケーションソフトウェア１３１の構成例を示している。

なお、上記の無線通信装置とは、例えば、道路インフラとの通信（路車間通信）や他車両との通信（車車間通信）を実現するための装置である。車載処理装置１０は、無線通信装置からの情報として、渋滞、工事、信号等の道路インフラに関する情報や、他車両内部の情報（アクセル開度、ブレーキ情報、走行経路情報等）を取得できるようになる。そのため、外界センサや地図情報では取得できない新しい付加情報があり、これらを用いることにより、自動運転制御の演算を高度化することが可能となる。

無線通信装置で取得できるデータ（以降、通信データと呼ぶ）では、通常、当該データが表す対象物の位置がグローバル座標系（緯度、経度）で表現される。それに対して、外界センサ群２０で取得されるデータは、車両２を中心とした車両座標系で表現される。そのため、センサデータと通信データを統合するためには、センサフュージョン演算部２４１によるセンサフュージョン演算処理を適用できず、新たな演算処理を追加する必要がある。また、通信データの情報を付加するにあたり、該当する対象要素（他車両等）のオブジェクトデータの構造も修正が必要である。本実施形態のアプリケーションソフトウェア１３１では、自動運転制御演算部２４４の修正に加えて、データ適合層２００における無線通信装置データ適合部１１０１の追加と、データ管理層２３０における設定情報データ群２３４への新しいオブジェクトデータの定義情報の追加と、データ演算層２４０における通信データフュージョン演算部１１０２の追加とにより、上記のようなシステム変更を実現できる。

まず、データ管理層２３０の修正部分について説明する。データ管理層２３０の修正は、設定情報データ群２３４の修正により実現される。図１２は、変更後の設定情報データ群２３４に格納されている設定情報の一例を示す図である。図１２では、無線通信装置から取得する各種データを格納するため、無線通信装置をデータソースとする設定情報レコードが追加されている。なお、図１２では他車両に関するオブジェクトデータに対応する設定情報レコードのみを追加の設定情報レコードとして示しているが、他のオブジェクトデータに対応する設定情報レコードをさらに追加してもよい。また、図１２では、通信データの情報付加のため、センサフュージョンに関するオブジェクトデータのうち、通信データと関連する一部のオブジェクトデータのデータ長が、情報付加分に合せて変更されている。データ管理層２３０では、これらの設定情報の修正だけでシステム変更が実現可能であり、オブジェクトデータ管理部２３１やオブジェクトデータ操作インタフェース２３２はそのまま利用することができる。

次に、データ適合層２００の修正部分について説明する。データ適合層２００の修正は、図１１に示したように、無線通信装置データ適合部１１０１の追加により実現される。無線通信装置データ適合部１１０１は、無線通信装置に特有の各種データの形式を、データ管理層２３０で管理するオブジェクトデータの形式に変換して、オブジェクトデータ群２３３に格納する。前述したように、データ適合層２００の各ソフト部品は互いに独立しているため、無線通信装置データ適合部１１０１の追加による影響を他のソフト部品が受けることはない。また、上述のように、データ管理層２３０のオブジェクトデータ操作インタフェース２３２も変更されないため、データ適合層２００の既存のソフト部品はそのまま利用することができる。

最後に、データ演算層２４０の修正部分について説明する。データ演算層２４０の修正は、自動運転制御演算部２４４の修正を除くと、図１１に示したように、通信データフュージョン演算部１１０２の追加により実現される。通信データフュージョン演算部１１０２は、オブジェクトデータ管理部２３１から、生成元が通信データと関連するセンサフュージョンであるオブジェクトデータと、生成元が無線通信装置であるオブジェクトデータとを含むデータ群を取得し、所定の演算に基づいて、同一の対象要素に対するオブジェクトデータを同定・統合する。例えば、他車両を示すセンサフュージョンにより生成されたオブジェクトデータと、同じく他車両を示す無線通信装置からのオブジェクトデータ（通信データ）とが、同一の対象要素に対応する場合には、前者のオブジェクトデータに通信データの情報を付加して更新する。

図１３は、システム変更を加えた場合のセンサフュージョンのオブジェクトデータの構造の一例を示す図である。図１３のデータ構造では、図１０に示したシステム変更を加える前のデータ構造と比較して、固有データ領域１２０１に通信情報レコード１２０２が追加されている。また、図１３に示す疑似コードＣ１２０３、Ｃ１２０４は、図１３の上記オブジェクトデータの構造体と、通信データフュージョン演算部１１０２が実行する通信データフュージョン演算とをそれぞれ記述した例である。疑似コードＣ１２０３では、図１０で示した変更前のオブジェクトデータの構造体を表す疑似コードＣ１００４に対して、通信情報レコード１２０２に相当する構造体が追加されている。通信データフュージョン演算部１１０２は、疑似コードＣ１２０４に示すような方法でデータ演算層２４０に実装され、通信データの情報をオブジェクトデータに付加、更新するためのデータフュージョン演算を実現する。

ここで、既存のソフト部品によるオブジェクトデータの更新処理を表す疑似コードＣ１００５、Ｃ１００６、Ｃ１００７は、図１０に示した内容から全く変更されていない。その一つ目の理由としては、データ演算層２４０の各ソフト部品は、抽象化されたオブジェクトデータ操作インタフェース２３２を介してデータの入出力を行っており、ソフト部品間に依存関係がないことに拠る。すなわち、ソフト部品間に依存関係がないため、データ演算層２４０に通信データフュージョン演算部１１０２が追加されたとしても、既存の他のソフト部品が影響を受けることがなく、したがって修正の必要もない。また、二つ目の理由としては、各ソフト部品で扱うメモリ領域を分けて定義していることで、操作対象のオブジェクトデータの構造を変更した場合でも、その影響が既存のソフト部品に伝播しないようになっているためである。以上の仕組みにより、システム変更が行われた場合でも、センサフュージョン演算部２４１、地図フュージョン演算部２４２、行動予測演算部２４３の各ソフト部品をそのまま利用することができる。

本実施形態では、以上説明したようなアプリケーションソフトウェア１３１の構成を採用することで、例えば車載処理装置１０のデータ構造や機能構成が変更された場合など、従来では再利用が困難であったケースでも、アプリケーションソフトウェア１３１の再利用性を高めることが可能である。したがって、様々な局面において、車載処理装置１０におけるアプリケーションソフトウェア１３１の再利用性を向上させることができる。

以上のように、本実施形態によれば、アプリケーションソフトウェア１３１をデータ適合層２００、データ管理層２３０、データ演算層２４０の３つに階層化し、データ管理・操作を抽象化して共通利用できるようにしている。これにより、従来では演算処理を行うソフト部品毎に個別に実装する必要があったデータ管理・操作部分を再利用することができるため、アプリケーションソフトウェア１３１の開発効率が向上する。また、データ管理層２３０のインタフェースは、管理するデータ構造が変更されても変わらないように構成されているため、外界センサの構成変更時のような場合でも、各ソフト部品のデータ管理・操作部分はそのまま利用することが可能である。

また、本実施形態によれば、アプリケーションソフトウェア１３１をデータ適合層２００、データ管理層２３０、データ演算層２４０の３つに階層化することにより、データ管理と演算処理とを機能的に分離することができる。そのため、演算処理の独立性が向上し、演算処理の変更や追加が容易になる。本ソフトウェア構成では、データ演算層２４０のソフト部品間のデータの受け渡しは、原則として、データ管理層２３０のオブジェクトデータ操作インタフェース２３２を介して行われる。オブジェクトデータ操作インタフェース２３２は抽象化されているため、データ演算層２４０の各ソフト部品は操作対象のデータの提供元も利用先も意識する必要がない。そのため、各ソフト部品の独立性が高まり、他のソフト部品の変更や追加による影響を受けにくく、機能構成変更時でも、既存のソフト部品を再利用できる可能性が高くなる。

以上説明した本発明の実施形態によれば、以下の作用効果を奏する。

（１）車両２に搭載される車載処理装置１０は、外部からの入力信号に基づく入力データ１４２を生成する信号入力部１１１と、入力データ１４２に基づき出力データ１４３を演算する演算処理を実行する処理部１００と、出力データ１４３に基づく出力信号を生成して外部に出力する信号出力部１１２と、処理部１００に演算処理を実行させるためのアプリケーションソフトウェア１３１を記憶する記憶部１２０とを備える。アプリケーションソフトウェア１３１は、所定の対象要素に対応するデータの集合であるオブジェクトデータを記憶部１２０上で管理するためのデータ管理層２３０と、入力データ１４２に基づきオブジェクトデータを生成し、生成したオブジェクトデータをデータ管理層２３０に出力するためのデータ適合層２００と、データ管理層２３０からオブジェクトデータを取得し、取得したオブジェクトデータに基づき出力データ１４３を演算するためのデータ演算層２４０と、を有する。このようにしたので、車載処理装置１０におけるアプリケーションソフトウェア１３１の再利用性を向上させることができる。

（２）データ管理層２３０は、データ管理層２３０が管理するオブジェクトデータをデータ適合層２００およびデータ演算層２４０が操作するためのオブジェクトデータ操作インタフェース２３２を有する。オブジェクトデータ操作インタフェース２３２は、データ構造が異なる複数のオブジェクトデータを共通の操作手法で操作可能に構成される。このようにしたので、例えば車載処理装置１０に接続される外部ハードウェアの変更や、車載処理装置１０における機能構成の変更など、様々なシステム構成の変更に対して柔軟に対応可能であり、高い再利用性を有するアプリケーションソフトウェア１３１を提供することができる。

（３）オブジェクトデータ操作インタフェース２３２によるオブジェクトデータの操作は、データ管理層２３０が管理するオブジェクトデータの中から、引数として指定可能な検索条件に該当するオブジェクトデータを取得する検索操作を含む。この検索操作における検索条件は、例えば式（１）、（２）のように、オブジェクトデータを構成する情報要素に関する比較演算を含む検索条件式で表現される。また、複数の比較演算の結果の論理演算をさらに含むこともできる。さらにこの検索操作では、引数として指定可能なソート条件に基づき、検索条件に該当するオブジェクトデータをソートして取得することもできる。このようにしたので、データ演算層２４０やデータ適合層２００の各ソフト部品は、全体のオブジェクトデータの中から所望するオブジェクトデータを抽出する処理を個別に実装することなく、任意の所望するオブジェクトデータを選択的に取得することが可能であり、高い再利用性を有するアプリケーションソフトウェア１３１を提供することができる。

（４）また、オブジェクトデータ操作インタフェース２３２によるオブジェクトデータの操作は、データ管理層２３０が管理するオブジェクトデータを、データ管理層２３０に新たに入力されたオブジェクトデータに置き換える登録操作と、データ管理層２３０が管理するオブジェクトデータの一部を、データ管理層２３０に新たに入力されたオブジェクトデータに基づいて書き換える更新操作と、を含む。このようにしたので、データ演算層２４０の各ソフト部品による演算結果や、データ適合層２００の各ソフト部品からの入力情報に基づき、データ管理層２３０において適切にオブジェクトデータの管理を行うことができる。

（５）データ管理層２３０は、同一の対象要素に関する複数のオブジェクトデータを時系列で管理できるように構成されている。この場合、オブジェクトデータ操作インタフェース２３２によるオブジェクトデータの操作は、データ管理層２３０が時系列で管理する複数のオブジェクトデータを取得する操作を含む。また、データ管理層２３０が時系列で管理する複数のオブジェクトデータに、データ管理層２３０に新たに入力されたオブジェクトデータを追加する登録操作と、データ管理層２３０が時系列で管理する複数のオブジェクトデータのうち最新のオブジェクトデータの一部を、データ管理層２３０に新たに入力されたオブジェクトデータに基づいて書き換える更新操作と、を含む。さらに、データ管理層２３０が時系列で管理する第１の対象要素に関する複数のオブジェクトデータに、データ管理層１２０が時系列で管理する第２の対象要素に関する複数のオブジェクトデータを組み込む統合操作を含む。このようにしたので、時系列での複数のオブジェクトデータについても、データ管理層２３０において適切に管理することができる。

（６）オブジェクトデータは、データ管理層２３０が管理する全てのオブジェクタデータに対して共通の情報が格納される共通データ領域４００と、対象要素の種類に応じて異なる情報が格納される固有データ領域４０５とを有する。共通データ領域４００には、対象要素を識別するための識別子であるＩＤ４０１と、当該オブジェクトデータの生成元を示す情報であるデータソース４０２と、対象要素の概念的な種別を示す情報であるオブジェクト種別４０３と、当該オブジェクトデータに関する時間情報であるタイムスタンプ４０４と、のいずれか１つ以上を含む。このようにしたので、データ管理層２３０において、データ構造が異なる個々のオブジェクトデータを共通のインタフェースで管理および操作することが可能となる。

（７）データ管理層２３０は、オブジェクトデータに関する設定情報の集合である設定情報データ群２３４を有する。オブジェクトデータ操作インタフェース２３２によるオブジェクトデータの操作は、データ管理層２３０が管理するオブジェクトデータの中から、引数として指定可能な検索条件に該当する固有データ領域４０５を有するオブジェクトデータを、設定情報における検索キー情報５０５に基づき取得する検索操作を含む。このようにしたので、オブジェクトデータ操作インタフェース２３２のデータ操作により、固有データ領域４０５の情報要素についても、任意のオブジェクトデータを検索して取得することができる。

（８）データ演算層２４０は、複数のソフト部品で構成されており、複数のソフト部品間におけるデータの受け渡しは、データ管理層２３０を介して行われる。このようにしたので、データ演算層２４０における各ソフト部品の独立性を高めることができ、車載処理装置１０における機能構成の変更時にも高い再利用性を有するアプリケーションソフトウェア１３１を提供することができる。

（９）データ演算層２４０における複数のソフト部品は、データ管理層２３０から取得したオブジェクトデータに基づき、車両２の周辺環境における対象要素の状態を推定するための認知処理を処理部１００に実行させる環境認知ソフト部品として、例えばセンサフュージョン演算部２４１、地図フュージョン演算部２４２、行動予測演算部２４３等を含む。これらの環境認知ソフト部品は、対象要素の状態の推定結果を、データ管理層２３０が管理するオブジェクトデータに格納する。このとき、これらの環境認知ソフト部品の各々は、対象要素の状態の推定結果を、データ管理層２３０が管理するオブジェクトデータにおいて別々のデータ領域、すなわち基本情報レコード１００１、地図属性レコード１００２、予測情報レコード１００３にそれぞれ格納する。このようにしたので、処理部１００が複数のプロセッサまたは複数のコアで構成されている場合に、複数の認知処理を並列に実行して処理の効率化を図ることができる。また、データ演算層２４０におけるソフト部品の追加や変更が容易となり、アプリケーションソフトウェア１３１の再利用性をさらに向上させることができる。

なお、以上で説明した実施形態は一例であり、本発明はこれに限られない。すなわち、様々な応用が可能であり、あらゆる実施の形態が本発明の範囲に含まれる。例えば、上記実施形態では、車載処理装置１０が処理部１００と記憶部１２０をそれぞれ一つずつ有しており、車載処理装置１０における各処理は、この処理部１００と記憶部１２０を用いて実行されるように記載している。しかし、車載処理装置１０が処理部１００と記憶部１２０をそれぞれ複数ずつ有するようにして、各処理が複数の処理部１００と記憶部１２０を用いて実行されるようにしてもよい。その場合は、例えば、同様の構成を持つ処理ソフトウェアが別々の記憶部１２０に搭載され、複数の処理部１００で分担して当該処理を実行することもできる。

また、上記の実施形態では、車載処理装置１０の各処理を、処理部１００と記憶部１２０をそれぞれ構成するプロセッサとＲＡＭを用いて、所定の動作プログラムを実行することで実現しているが、必要に応じて独自のハードウェアで実現することも可能である。また、上記の実施形態では、車載処理装置１０、外界センサ群２０、内界センサ群３０、地図情報管理装置４０、アクチュエータ群５０、車載用ＨＭＩ装置６０をそれぞれ個別の装置として記載しているが、必要に応じて任意のいずれか２つ以上を組み合せて実現することも可能である。

上記の実施形態では、本発明を車両システム１で用いられる車載処理装置１０のソフトウェアに適用した例を説明したが、他のシステムに搭載される処理装置や演算装置のソフトウェアに適用することも可能である。例えば、ロボットシステムに搭載されてロボットの制御に関する各種演算処理を実行する演算装置のソフトウェア等においても、本発明を適用可能である。

また、図面には、実施形態を説明するために必要と考えられる制御線や情報線を示しており、必ずしも、本発明が適用された実際の製品に含まれる全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてもよい。

１：車両システム、２：車両、１０：車載処理装置、２０：外界センサ群、３０：内界センサ群、４０：地図情報管理装置、５０：アクチュエータ群、６０：車載用ＨＭＩ装置、１００：処理部、１１０：信号入出力部、１１１：信号入力部、１１２：信号出力部、１２０：記憶部、１３０：処理ソフトウェア、１３１：アプリケーションソフトウェア、１３２：基本ソフトウェア、１３４：ＢＩＯＳ、１３５：ＯＳ、１３６：デバイスドライバ群、１３７：プロトコルスタック、２００：データ適合層、２３０：データ管理層、２４０：データ演算層

Claims

車両に搭載される車載処理装置であって、
複数の装置からそれぞれ入力される入力信号に基づき、複数の対象要素に関する情報を含む入力データを生成する信号入力部と、
前記入力データに基づき出力データを演算する演算処理を実行する処理部と、
前記出力データに基づく出力信号を生成して出力する信号出力部と、
前記処理部に前記演算処理を実行させるためのアプリケーションソフトウェアを記憶する記憶部と、を備え、
前記アプリケーションソフトウェアは、
前記入力データに基づき、前記対象要素ごとに前記情報を抽象化したオブジェクトデータを生成するデータ適合層と、
前記オブジェクトデータに基づき前記出力データを演算するためのデータ演算層と、を有する
ことを特徴とする車載処理装置。
前記オブジェクトデータは、
前記複数の装置からそれぞれ入力される前記入力信号において共通するデータを格納する対象要素共通データ領域と、
前記複数の装置からそれぞれ入力される前記入力信号において固有のデータを格納する対象要素固有データ領域と、を有する
ことを特徴とする請求項１に記載の車載処理装置。
前記対象要素共通データ領域は、
全ての前記対象要素について共通のデータを格納する第１のデータ領域と、
前記複数の対象要素のうちいずれか２つ以上の対象要素について共通のデータを格納する第２のデータ領域と、を有する
ことを特徴とする請求項２に記載の車載処理装置。
前記第１のデータ領域には、前記対象要素を識別するための識別子と、当該オブジェクトデータの生成元を示す情報と、前記対象要素の概念的な種別を示す情報と、当該オブジェクトデータに関する時間情報と、のいずれか１つ以上を含む
ことを特徴とする請求項３に記載の車載処理装置。
前記データ適合層は、複数のデータ適合部を有し、
前記複数のデータ適合部のそれぞれは、前記複数の装置のそれぞれに対応し、
前記複数のデータ適合部のそれぞれは、前記入力データのうち対応する前記装置に係るデータに基づき前記オブジェクトデータを生成する
ことを特徴とする請求項１から請求項４のいずれか一項に記載の車載処理装置。
前記データ演算層は、複数のソフト部品で構成されている
ことを特徴とする請求項１から請求項５のいずれか一項に記載の車載処理装置。
前記複数のソフト部品は、前記オブジェクトデータに基づき、前記車両の周辺環境における前記対象要素の状態を推定するための認知処理を前記処理部に実行させる環境認知ソフト部品を含み、
前記環境認知ソフト部品は、前記対象要素の状態の推定結果を前記オブジェクトデータに格納する
ことを特徴とする請求項６に記載の車載処理装置。
前記複数のソフト部品は、複数の前記環境認知ソフト部品を含み、
複数の前記環境認知ソフト部品の各々は、前記対象要素の状態の推定結果を前記オブジェクトデータにおいて別々のデータ領域に格納する
ことを特徴とする請求項７に記載の車載処理装置。