WO2019021668A1

WO2019021668A1 - 車両制御装置

Info

Publication number: WO2019021668A1
Application number: PCT/JP2018/022682
Authority: WO
Inventors: 勇樹堀田; 悠史福島; 成沢　文雄; 林　正人
Original assignee: Hitachi Automotive Systems Ltd
Current assignee: Astemo Ltd
Priority date: 2017-07-25
Filing date: 2018-06-14
Publication date: 2019-01-31
Anticipated expiration: 2020-01-25
Also published as: US20200150648A1; DE112018003291T5; JP2019028506A; JP6853746B2

Abstract

車両制御装置は、外部装置と通信可能に接続された車両制御装置であって、外部装置とのデータ送受信を制御する通信制御部と、オブジェクトデータを管理するデータ管理部と、データ管理部または通信制御部から取得されるオブジェクトデータを用いて所定の演算を行い、所定の演算により得られたオブジェクトデータである出力オブジェクトデータをデータ管理部に出力する１つ以上の機能部品と、機能部品ごとに出力オブジェクトデータの書き込み先に関する情報が格納される設定情報、およびオブジェクトデータを記憶する記憶部とを備え、データ管理部は、出力オブジェクトデータの書込み先を、設定情報に基づいて制御する。

Description

車両制御装置

　本発明は、車両制御装置に関する。

　ネットワークで接続された複数の組込み装置から構成される制御システムにおいて、プログラムの修正なくアプリケーションソフトウェア（以降、アプリケーション）の配置変更に対応可能とする技術が提案されている。この技術は、各組込み装置上で共通して動作するミドルウェアが、アプリケーションが演算に用いるデータの格納先を設定情報に基づいて制御することにより実現される。アプリケーションの配置変更としては、組込み装置の非実行状態の時（設計時や装置停止時等）に行う「静的な配置変更」と、実行状態の時に行う「動的な配置変更」がある。静的な配置変更としては、アプリケーションを異なる装置構成のシステムに適用する場合（例えば、異なる車種への展開）等が例として挙げられる。一方、動的な配置変更が必要となる例としては、制御システム上のある組込み装置が故障した場合に、その故障した組込み装置上で動作していたアプリケーションを他の組込み装置上で立ち上げることにより、制御システムを維持するというフェールオペレーショナルシステム等が挙げられる。
　たとえば特許文献１には、他の通信装置との通信手段を備える通信装置において、複数の異なるアプリケーションプログラムを実行する手段と、他の通信装置と共通のプラットフォームプログラムを実行する手段と、データを記憶する記憶手段と、前記プラットフォームプログラムの処理により、前記記憶手段と前記アプリケーションプログラムとのデータの授受、他の通信装置とのデータの送受信、及び前記通信手段により他の通信装置から受信したデータの前記記憶手段への記憶を、他の通信装置と共通に行なう手段と、前記プラットフォームプログラムの処理により、前記記憶手段が記憶したデータの内の一又は複数を用いて他のデータを生成する生成手段とを備え、前記生成手段が生成したデータを前記通信手段により他の通信装置へ送信するようにしてあることを特徴とする通信装置が開示されている。

日本国特願２００８－１５３２７１号公報

　特許文献１に記載されている発明では、ネットワーク帯域や各組込み装置の記憶容量を無駄に消費する。

　本発明の第１の態様による車両制御装置は、外部装置と通信可能に接続された車両制御装置であって、前記外部装置とのデータ送受信を制御する通信制御部と、オブジェクトデータを管理するデータ管理部と、前記データ管理部または前記通信制御部から取得されるオブジェクトデータを用いて所定の演算を行い、前記所定の演算により得られたオブジェクトデータである出力オブジェクトデータを前記データ管理部に出力する１つ以上の機能部品と、前記機能部品ごとに前記出力オブジェクトデータの書き込み先に関する情報が格納される設定情報、およびオブジェクトデータを記憶する記憶部とを備え、前記データ管理部は、前記出力オブジェクトデータの書込み先を、前記設定情報に基づいて制御する。

　本発明によれば、不要なデータの保存や通信を低減することができる。

車両システム１の機能ブロック図設定情報データ群１４１の一例を示す図オブジェクトデータ群１４２の一例を示す図図４（ａ）は設定変更用データ群１４３ａの一例を示す図、図４（ｂ）は設定変更用データ群１４３ｂの一例を示す図図５（ａ）は設定情報テーブルａの一例を示す図、図５（ｂ）は設定情報テーブルＢの一例を示す図図６（ａ）はモジュールリストＭ１の一例を示す図、図６（ｂ）はモジュールリストＭ２の一例を示す図オブジェクトデータ操作インタフェース１２５のＡＰＩ群の一例を示す図実行制御部１４の周期処理を表すフローチャートオブジェクトデータ更新処理を表すフローチャート完了通知受信処理を表すフローチャートオブジェクトデータ更新操作要求メッセージの一例を示す図動的な配置変更の動作例を説明する図変形例１における設定変更用データ群１４３ｐの一例を示す図第２の実施の形態における開発用システム１ａの機能ブロック図操作用装置６の機能ブロック図第２の実施の形態における車両制御装置２の設定情報データ群１４１ａの一例を示す図地図フュージョン演算部１３２のデバッグを行うための開発用システム１ａの機能ブロック図地図フュージョン演算部１３２のデバッグを行うための操作用装置６の機能ブロック図図１７における設定情報データ群１４１ａの一例を示す図

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

（車両システムの構成）
　図１は、車両制御装置を含む車両システム１の構成の一例を示す機能ブロック図である。車両システム１は、車両に搭載され、車両の周辺における走行道路や周辺車両等の障害物の状況を認識した上で、適切な運転支援あるいは走行制御を行うためのシステムである。図１に示すように、車両システム１は、車両制御装置２ａ、車両制御装置２ｂ、センサ群３、アクチュエータ群４、および地図情報管理装置５を含んで構成される。センサ群３は、符号３ａで示すセンサＡと符号３ｂで示すセンサＢとを含む。ただしセンサ群３は３以上のセンサにより構成されてもよい。アクチュエータ群４は、符号４ａで示すアクチュエータＡと符号４ｂで示すアクチュエータＢとを含む。ただしアクチュエータ群４は、３以上のアクチュエータにより構成されてもよい。以下では、車両制御装置２ａと車両制御装置２ｂとをまとめて「車両制御装置２」とも呼ぶ。

　車両制御装置２は、例えば、車両に搭載された電子制御装置（ＥＣＵ：Electronic Control Unit）である。車両制御装置２ａは、処理部１０ａと、記憶部４０ａと、通信制御部５０ａとを有する。車両制御装置２ｂは、処理部１０ｂと、記憶部４０ｂと、通信制御部５０ｂとを有する。ただし以下では、処理部１０ａと処理部１０ｂとをまとめて「処理部１０」とも呼び、記憶部４０ａと記憶部４０ｂとをまとめて「記憶部４０」とも呼び、通信制御部５０ａと通信制御部５０ｂとをまとめて「通信制御部５０」とも呼ぶ。

　車両システム１は、自動運転に必要な演算を車両制御装置２ａ、および車両制御装置２ｂが実行する。すなわち車両制御装置２ａと車両制御装置２ｂの協調動作により自動運転が実現される。ただし本実施の形態において車両システム１が実現する機能は一例であり、車両システム１は自動運転以外の機能を実現してもよい。

　処理部１０は、たとえば、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ：中央演算処理装置）やＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）を含んで構成される。処理部１０は、記憶部４０または不図示のＲＯＭに格納されているプログラムを不図示のＲＡＭに展開して実行することで、車両制御装置２の機能を実現する。ただし処理部１０が備える機能の一部または全部は、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）やハードウエア回路により実現されてもよい。

　処理部１０ａはその機能として、データ適合部１１ａ、データ管理部１２ａ、データ演算部１３ａ、実行制御部１４ａ、および診断部１５ａを備える。処理部１０ｂはその機能として、データ適合部１１ｂ、データ管理部１２ｂ、データ演算部１３ｂ、実行制御部１４ｂ、および診断部１５ｂを備える。以下では、データ適合部１１ａとデータ適合部１１ｂとをまとめて「データ適合部１１」と呼び、データ管理部１２ａとデータ管理部１２ｂとをまとめて「データ管理部１２」と呼び、データ演算部１３ａとデータ演算部１３ｂとをまとめて「データ演算部１３」と呼び、実行制御部１４ａと実行制御部１４ｂとをまとめて「実行制御部１４」と呼び、診断部１５ａと診断部１５ｂとをまとめて「診断部１５」と呼ぶ。

　データ適合部１１は、通信制御部５０を介して他の車両制御装置２と送受信するデータ形式とデータ管理部１２で扱うデータ形式との間の、データ形式の変換を行う機能部品群である。ただし機能部品とは、処理部１０が実現する機能の一部を実現する機能ブロックであり、ＣＰＵ、ＧＰＵ、ＦＰＧＡ、またはハードウエア回路により実現される。

　車両制御装置２ａのデータ適合部１１ａは、符号３ａで示すセンサＡ及び符号３ｂで示すセンサＢにそれぞれ対応するセンサＡ適合部１１１及びセンサＢ適合部１１２と、地図情報管理装置５に対応する地図装置適合部１１３とを備える。車両制御装置２ｂのデータ適合部１１ｂは、符号４ａで示すアクチュエータＡ及び符号４ｂで示すアクチュエータＢにそれぞれ対応するアクチュエータＡ適合部１１４及びアクチュエータＢ適合部１１５を備える。これらの各機能部品が、対応する外部装置とデータ管理部１２との間で、それぞれのデータ形式に応じたデータ形式の変換を行う。

　ただし車両制御装置２ａおよび車両制御装置２ｂのＲＯＭには、センサＡ適合部１１１、センサＢ適合部１１２、地図装置適合部１１３、アクチュエータＡ適合部１１４、およびアクチュエータＢ適合部１１５を機能させるためのソフトウエアが格納されている。すなわち後述するように、車両制御装置２ａがさらにアクチュエータＡ適合部１１４、およびアクチュエータＢ適合部１１５を機能させることも可能である。

　なお、データ管理部１２では、後述するように抽象化したデータ形式（以下、「オブジェクトデータ」）を用いてデータの管理を行う。そのためデータ適合部１１の動作を詳述すれば、データ適合部１１の各機能部品の機能は次の２つを含む。すなわち第１に、通信制御部５０を介して他の車両制御装置２から取得したデータのデータ形式を変換し、オブジェクトデータを生成してデータ管理部１２へ出力する機能である。第２に、データ管理部１２から出力されるオブジェクトデータのデータ形式を変換し、他の車両制御装置２への送信するデータを生成する機能である。

　データ管理部１２は、車両制御装置２の記憶部４０に格納されたオブジェクトデータの管理および操作を行う機能と、他の車両制御装置２のデータ管理部１２とのオブジェクトデータ操作要求の送受信を行う機能と、他の機能部品に対する共通インタフェースを提供する機能と、を有する機能部品群である。

　データ管理部１２は、所定の対象要素に対応するデータの集合であるオブジェクトデータを単位として、記憶部４０上でデータの管理および操作を行う。なお「対象要素」とは、オブジェクトデータとして一纏めにした個々の情報要素が共通して表現する概念的な対象であり、例えば、センサ群３の検出対象や、アクチュエータ群４の制御対象等が該当する。好ましくは、特に外界センサについては、当該外界センサで認識された個々の環境要素（障害物、道路形状、交通ルール等）が対象要素に該当する。すなわち、外界センサというハードウェアそのものを抽象化するのではなく、外界センサの検出対象である環境要素を単位としてデータを抽象化し、オブジェクトデータとする方式を採ることが好ましい。

（データ管理部）
　データ管理部１２は、オブジェクトデータ操作実行部１２１、オブジェクトデータ操作実行制御部１２２、設定情報管理部１２３、オブジェクトデータ操作インタフェース１２５、および設定インタフェース１２６を備える。

　オブジェクトデータ操作実行部１２１は、データ管理部１２が他の機能部品から受けたデータ操作要求に基づき、記憶部４０上で管理しているオブジェクトデータ群１４２に対してデータ操作を行う。このデータ操作要求は、オブジェクトデータ操作インタフェース１２５を介して入力される。データ管理部１２は、データ操作を行うとその結果をデータ操作要求の送信元に返す。なおオブジェクトデータのデータ操作には、オブジェクトデータの更新、すなわち登録、上書き、および削除だけでなく、オブジェクトデータの検索が含まれる。

　オブジェクトデータ操作実行制御部１２２は、データ管理部１２が他の機能部品から受けたオブジェクトデータへの書込みを伴うオブジェクトデータ操作要求、すなわち更新操作に対して、当該車両制御装置の記憶部４０へのデータ書込み要否や、別の車両制御装置に対する転送要否を判断する。この際にオブジェクトデータ操作実行制御部１２２は、後述する設定情報データ群１４１を参照してこれらの要否を判断する。このデータ操作要求は、オブジェクトデータ操作インタフェース１２５を介して入力される。オブジェクトデータ操作実行制御部１２２は、データ書込みが必要と判断する場合は、当該オブジェクトデータ操作要求をオブジェクトデータ操作実行部１２１に渡す。これにより、要求されたオブジェクトデータ群１４２に対する書込み操作が実行される。

　オブジェクトデータ操作実行制御部１２２は、別の車両制御装置に対する転送が必要と判断する場合は、必要に応じてオブジェクトデータ操作実行部１２１を介して所定の条件を満たすオブジェクトデータの抽出、すなわち検索操作を実行し、通信制御部５０を介してネットワークに当該オブジェクトデータ操作要求を出力する。そのため、設定情報データ群１４１を適切に設定することにより、データ適合部１１やデータ演算部１３の各機能部品を修正することなく、換言するとプログラムの修正やハードウエアの再構成をすることなく、それらによるオブジェクトデータの書込み場所を制御することが可能となる。

　またオブジェクトデータ操作実行制御部１２２は、実行制御部１４からの通知を受けて、オブジェクトデータ操作実行部１２１を介して所定の条件を満たすオブジェクトデータを抽出し、通信制御部５０を介して当該オブジェクトデータに関する書込み操作要求をネットワークに出力する機能も有する。

　設定情報管理部１２３は、データ管理部１２が設定インタフェース１２６を介して実行制御部１４から受けた要求に従い、設定情報データ群１４１の取得または変更を制御する機能部品である。

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

　設定インタフェース１２６は、実行制御部１４等の他の機能部品群が、データ管理部１２の振る舞いを規定する設定情報データ群１４１を取得したり、変更したりすることを可能とするためのインタフェースを提供する。

（データ演算部）
　データ演算部１３は、車両制御装置２の機能を実現するためのアプリケーション群である。データ演算部１３は、データ管理部１２のオブジェクトデータ操作インタフェース１２５から入力されたデータに基づいて演算を行い、演算により得られたデータをオブジェクトデータ操作インタフェース１２５に出力する機能部品群である。自動運転のような複雑な機能を実現する演算処理は複数の処理ブロックで構成され、データ演算部１３は個々の処理ブロックに対応する複数の機能部品で構成されている。すなわち本実施の形態では自動運転機能は３つの機能部品、すなわちセンサフュージョン演算部１３１、地図フュージョン演算部１３２、および走行制御演算部１３３により構成される。そしてこの３つの機能部品は、センサフュージョン演算部１３１と地図フュージョン演算部１３２が車両制御装置２ａに搭載され、走行制御演算部１３３が車両制御装置２ｂに搭載される。これらの各機能部品が行う演算処理により、センサ群３で検出された各種情報に基づき、車両制御装置２が搭載される車両における自動運転の制御情報が演算され、アクチュエータ群４に出力される。

　ただし車両制御装置２ａおよび車両制御装置２ｂのＲＯＭには、センサフュージョン演算部１３１、地図フュージョン演算部１３２、および走行制御演算部１３３を機能させるためのソフトウエアが格納されている。すなわち後述するように、車両制御装置２ａだけでセンサフュージョン演算部１３１、地図フュージョン演算部１３２、および走行制御演算部１３３の全ての演算を行うことも可能である。

　センサフュージョン演算部１３１は、センサ群３に含まれる複数の外界センサで検出した同一の対象要素に対するオブジェクトデータの同定・統合処理、および時系列情報に基づく欠落データの補間処理を行う。
　地図フュージョン演算部１３２は、センサフュージョン演算部１３１が同定・統合したオブジェクトデータと地図情報管理装置５から取得した地図データの情報とを照合し、当該オブジェクトデータに地図データの情報（例えば、他車両が走行している車線ＩＤ等）を属性として付加する処理を行う。

　走行制御演算部１３３は、センサフュージョン演算部１３１、地図フュージョン演算部１３２の演算結果に基づいて、当該車両の運転行動や走行軌道、速度プロファイル等を決定する。また走行制御演算部１３３は、決定したこれらの情報を基に、アクチュエータ群４に対する制御情報を演算し、その演算結果をデータ管理部１２（図１の場合は１２ｂ）に出力する。なお、データ管理部１２に出力された制御情報は、データ適合部１１のアクチュエータＡ適合部１１４、およびアクチュエータＢ適合部１１５によりそれぞれのアクチュエータに対応する通信データ形式に変換され、通信制御部５０ｂを介してネットワークに出力される。

（実行制御部）
　実行制御部１４は、データ適合部１１及びデータ演算部１３の機能部品等、データ管理部１２にアクセスする各機能部品の実行を制御する機能部品である。実行制御部１４は、後述するモジュールリストに記載された順序に従って、データ管理部１２にアクセスする各機能部品の演算を実行するための関数、すなわち実行関数を呼び出し、車両制御装置２の一連の演算処理を実現する。その際に実行制御部１４は、データ管理部１２の設定インタフェース１２６を介して設定情報データ群１４１を参照し、データ管理部１２にアクセスする各機能部品の実行要否を判断する。実行制御部１４は、実行不要と設定されている機能部品については実行関数を呼び出さずに、次の機能部品の処理に移行する。

（診断部）
　診断部１５は、自身の車両制御装置２やネットワークで接続された外部装置の状態を診断し、故障を検出する機能部品である。自身の装置内の故障は、例えば、ウォッチドックタイマー等により内部状態を監視することにより検出可能である。また、外部装置の故障は、例えば、キープアライブ等の手法により検出可能である。診断部１５は、各種故障を検出すると実行制御部１４に通知する。

（記憶部）
　記憶部４０は、例えば、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）、フラッシュメモリ、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）などの記憶装置や、ＲＡＭなどのメモリを含んで構成される。記憶部４０には、処理部１０が処理するプログラムや、その処理に必要なデータ群、すなわち設定情報データ群１４１、オブジェクトデータ群１４２、及び設定変更用データ群１４３が格納される。また記憶部４０は、処理部１０がプログラムを実行する際の主記憶装置として、一時的にプログラムの演算に必要なデータを格納する用途にも利用される。

　設定情報データ群１４１は、データ管理部１２の振る舞いを規定する設定情報に関するデータの集合である。オブジェクトデータ群１４２は、データ管理部１２が記憶部４０上で管理しているオブジェクトデータの集合である。設定変更用データ群１４３は、実行制御部１４が設定情報データ群１４１を動的に変更する際に参照するデータの集合である。設定情報データ群１４１、オブジェクトデータ群１４２、及び設定変更用データ群１４３の具体例は後述する。

（通信制御部）
　通信制御部５０は、例えば、ＩＥＥＥ８０２．３又はＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）等の通信規格に準拠したネットワークカード等を含んで構成される。通信制御部５０は、車両システム１における他の装置と各種プロトコルに基づきデータの送受信を行う。通信制御部５０が提供するデータ送受信のためのインタフェースは、車両制御装置２のハードウェアや外部装置との接続形態に依存しない形式で構成されている。例えば、デバイスドライバ群により車両制御装置２のハードウェアデバイスを抽象化して扱うためのインタフェースが提供され、その上でＴＣＰ／ＩＰ等の汎用的な通信プロトコルが動作する。これにより、いずれの車両制御装置上においても、共通のインタフェース、たとえばソケットインタフェース等を用いて任意のデータを他装置と送受信可能なように構成されている。

　なお図１では通信制御部５０を処理部１０と分けて記載しているが、処理部１０の中で通信制御部５０の処理の一部が実行されてもよい。例えば、通信処理におけるハードウェアデバイス相当が通信制御部５０に位置し、それ以外のデバイスドライバ群や通信プロトコル処理等は、処理部１０の中に位置するように構成することも可能である。そのような構成においても、データを送受信するためのインタフェースは変わらないため、処理部１０におけるデータ適合部１１、データ管理部１２、データ演算部１３、実行制御部１４の機能部品群の振る舞いは変わることはない。

　センサ群３は、車両周辺の状態を検出する装置である外界センサ群や、車両の状態を検出している装置である内界センサ群の集合である。外界センサ群はたとえば、カメラ装置、ミリ波レーダ、レーザレーダ、およびソナーなどである。車両の状態とはたとえば、走行速度、操舵角、アクセルの操作量、およびブレーキの操作量などである。センサ群３を構成するそれぞれの装置は、その検出情報を車載ネットワーク上に出力する。外界センサ群は、車両から所定範囲に存在する他車両、自転車、歩行者、落下物などの障害物や、白線や路端などの道路形状、および道路標識や信号などの交通ルール等の環境要素を検出して出力する。本実施の形態では、センサ群３は、符号３ａで示すセンサＡと符号３ｂで示すセンサＢとを含む。

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

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

　ここで、本実施形態による車両制御装置２における処理部１０を構成する機能部品（以下、「処理機能部品」）の特徴を説明する。前述のとおり処理機能部品は、データ管理部１２を介してデータの受渡しを行うように構成されている。そのため、車両制御装置２ａと車両制御装置２ｂにおける処理機能部品の配置が変更されても、それぞれのデータ管理部１２が処理機能部品のデータ入出力のインタフェースであることに変わりはない。

　上述のようにデータ管理部１２は、設定情報データ群１４１に基づいて各機能部品から出力されたオブジェクトデータの書込み場所を制御する。そのため、設計やハードウェア構成の変更等により車両制御装置２に対するデータ演算を行う各機能部品の配置関係が変更されても、以下のように影響が限定的である。すなわち処理部１０は、機能部品の配置が変更されても設定情報データ群１４１を適切に設定することにより、当該機能部品の入出力インタフェースを変更せずに、車両システム１における一連の演算処理を実現できる。すなわち、機能部品を改修することなく機能部品の静的な配置変更を実現できる。

　また実行制御部１４は、設定情報データ群１４１に基づいて、データ管理部１２にアクセスする各機能部品の実行を動的に制御可能である。すなわち、各機能部品の実行とそれに合わせたオブジェクトデータの配置を連動させて切り替えることが可能であるため、以下の利点を有する。その利点とは、設定インタフェース１２６を介して設定情報データ群１４１を適切に変更することにより、車両システム１における一連の演算処理を継続しながら機能部品の配置変更、すなわち動的な配置変更を実現できることである。

　なお図１では、通信制御部５０とデータ管理部１２の間のデータ形式の変換を行うデータ適合部１１を、データ演算部１３と分けて記載している。しかしこれらは、入力されたデータに対して所定の演算を行い、出力データを生成する点では共通している。そのため、データ適合部１１をデータ演算部１３の一部として扱うことも可能である。その場合は、データ演算部１３の機能部品群は、通信制御部５０もしくはデータ管理部１２を介してデータの受渡しを行う。

（設定情報データ群１４１）
　図２は、設定情報データ群１４１に格納されている設定情報の一例を示す図である。図２（ａ）は車両制御装置２ａに格納される設定情報データ群１４１ａを示す図、図２（ｂ）は車両制御装置２ｂに格納される設定情報データ群１４１ｂを示す図である。前述のように、設定情報データ群１４１は記憶部４０に格納されており、データ管理部１２の振る舞いを規定する設定情報に関するデータの集合である。データ管理部１２の設定情報管理部１２３は、車両制御装置２の起動時に設定変更用データ群１４３を読み込み、起動時に対応する設定情報テーブルに基づいて、メモリ上の設定情報データ群１４１を設定する。図２に示すように、設定情報データ群１４１は複数のレコードから構成され、各レコードは、モジュールＩＤ３０１、実行要否３０２、格納要否３０３、出力要否３０４、出力タイミング３０５及び検索式３０６のフィールドを有する。

　モジュールＩＤ３０１のフィールドには、データ管理部１２にアクセスするデータ適合部１１及びデータ演算部１３の機能部品を識別するための情報が格納される。図２では「センサＡ適合部」等、図１で示した機能部品名を記載しているが、実際には各機能部品に紐付けられた識別子、たとえば機能部品ＩＤが用いられる。以下では、あるレコードにおいて機能部品ＩＤのフィールドの値により特定される機能部品を「対象機能部品」と呼ぶ。実行要否３０２のフィールドには、当該車両制御装置において対象機能部品の演算を実行するか否かを示す情報が格納される。

　格納要否３０３のフィールドには、対象機能部品からのオブジェクトデータの書込み操作要求を当該車両制御装置で処理するか否かを示す情報が格納される。出力要否３０４のフィールドには、該機能部品からのオブジェクトデータの書込み操作要求をネットワークで接続された外部装置に転送するか否かを示す情報が格納される。図２では要否を示す「Ｙｅｓ」「Ｎｏ」で表現しているが、出力先の識別子、たとえばＩＰアドレスやホスト名などを記載しても良い。その場合は、たとえば、出力先情報が記載されていない場合は転送不要とし、出力先が記載されている場合はその出力先に該当する装置に対して転送する。

　出力タイミング３０５のフィールドは、出力要否３０４のフィールドに「Ｙｅｓ」が格納される場合に設定される。出力タイミング３０５のフィールドには、外部装置への転送を行うタイミングを示す情報が格納される。出力タイミング３０５のフィールドにはたとえば、「演算完了時」または「操作実行時」が格納される。「演算完了時」は、対象機能部品の演算処理が完了した際に転送を実行することを意味する。「操作実行時」は、対象機能部品から要求された各オブジェクトデータ書込み操作の実行時に転送を実行することを意味する。

　検索式３０６のフィールドは、出力要否３０４のフィールドに「Ｙｅｓ」が格納される場合に設定される。検索式３０６のフィールドには外部装置への転送対象を抽出するための条件文が格納される。また検索式３０６のフィールドの値は、出力タイミング３０５のフィールドの値とも以下のように連動している。出力タイミング３０５のフィールドに「演算完了時」が格納される場合は、記憶部４０に格納されているオブジェクトデータ群１４２全体に検索式３０６のフィールドに格納された検索が適用される。その一方で、出力タイミング３０５のフィールドに「操作実行時」が格納される場合は、対象機能部品から書込み要求がされたオブジェクトデータを対象として、検索式３０６のフィールドに格納された検索が適用される。

　検索式３０６のフィールドには、所定の文法に従って作成された条件文が格納される。条件文はたとえば、オブジェクトデータのデータ要素や検索式パラメータを指定するキー文字列、算出演算子、論理演算子、比較演算子等の組合せで表現される。図２の例では、地図フュージョン演算部における検索式３０６のフィールドには「ｄａｔａｓｒｃ＝“フュージョン”　ＡＮＤ　ｘ^２＋ｙ^２＜１００００」という条件式と、「ｓｏｒｔｔｙｐｅ＝“ａｓｃｅｎｄｉｎｇ”」「ｓｏｒｔｔａｒｇｅｔ＝ｘ^２＋ｙ^２」「ｏｂｊｎｕｍ＝２０」という検索パラメータが格納される。上述した条件式は、データソースが「フュージョン」で、かつ相対距離が１００ｍ未満のオブジェクトデータを抽出する検索式を表している。上述した３つの検索パラメータのうち先の２つは、検索結果のソートに関するパラメータを表しており、それぞれソートの並び順序、ソートをかける対象を指定している。この例においては、ｘ^２＋ｙ^２の値に対して昇順でソートしている。

　３つ目の検索パラメータは、出力するオブジェクトデータの数の上限値を指定するものである。この例では、オブジェクトデータは２０個まで送信可能としている。これらの条件式により、必要なオブジェクトデータのみを抽出して転送することを可能にすると同時に、該当するオブジェクトデータ数が多すぎた場合であっても、所定の優先順位に基づき転送数の上限を抑えることが可能になる。なお、この検索式３０６の表現形態はこれに拠らず、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ）等により表現しても良い。そのような文法を用いることで、異なるオブジェクトデータの値である自車両の速度ｖｅを参照して比較する以下のような条件式を構築することも可能である。すなわち「ｘ＞０　ＡＮＤ　ｘ^２＋ｙ^２＜（“自車両の速度ｖ_ｅ”×５）^２」（５秒間に進む前方範囲内のオブジェクトデータの抽出）という条件式が構築可能である。

　図２では、車両制御装置２ａ、２ｂの設定情報データ群１４１ａ、１４１ｂの例をそれぞれ示しているが、これは図１に示した車両システム１における設定情報に該当する。
　すなわち図２（ａ）に示す設定情報データ群１４１ａでは、車両制御装置２ａにおいてセンサＡ適合部１１１、センサＢ適合部１１２、地図装置適合部１１３、センサフュージョン演算部１３１、地図フュージョン演算部１３２が動作しているため、それらに該当する実行要否３０２のフィールドの値が「Ｙｅｓ」に設定されている。また、センサフュージョン演算部１３１および地図フュージョン演算部１３２の演算に必要なオブジェクトデータが、記憶部４０ａのオブジェクトデータ群１４２ａに格納されている必要があるため、以下の設定がされている。すなわちセンサＡ適合部１１１、センサＢ適合部１１２、地図装置適合部１１３、およびセンサフュージョン演算部１３１の出力結果が格納されるように、それらに該当する格納要否３０３のフィールドに「Ｙｅｓ」が設定されている。一方、地図フュージョン演算部１３２の出力結果は、車両制御装置２ｂにおいて実行される走行制御演算部１３３に利用されるため、地図フュージョン演算部１３２の出力要否３０４のフィールドの値は「Ｙｅｓ」に設定され、その際の各種条件が出力タイミング３０５と検索式３０６のフィールドに設定されている。

　一方、車両制御装置２ｂでは、アクチュエータＡ適合部１１４、アクチュエータＢ適合部１１５、走行制御演算部１３３が動作しているため、それらに該当する実行要否３０２のフィールドに「Ｙｅｓ」が設定されている。また、走行制御演算部１３３の演算や、アクチュエータＡ適合部１１４、アクチュエータＢ適合部１１５の出力に必要なオブジェクトデータが、記憶部４０ｂのオブジェクトデータ群１４２ｂに格納されている必要があるため、以下の設定がされている。すなわち地図フュージョン演算部１３２、走行制御演算部１３３の出力結果が格納されるように、それらに該当する格納要否３０３のフィールドに「Ｙｅｓ」が設定されている。

（オブジェクトデータ群１４２）
　図３は、オブジェクトデータ群１４２に格納されているオブジェクトデータの一例を示す図である。前述のようにオブジェクトデータ群１４２は記憶部４０に格納され、データ管理部１２により管理されるオブジェクトデータの集合である。図３に示すように、オブジェクトデータ群１４２は複数のレコードを有し、各レコードが１つのオブジェクトデータに対応する。以下では、あるレコードにおいて説明の対象としているオブジェクトデータを「対象オブジェクトデータ」と呼ぶ。また以下ではレコードを「データエントリ」とも呼ぶ。

　オブジェクトデータ群１４２の各レコードは、ＩＤ２０１、データソース２０２、オブジェクト種別２０３、タイムスタンプ２０４、相対位置２０５、相対速度２０６、およびデータソースや対象要素の種類に応じて異なる情報が格納される固有情報２０７から構成される。各データ要素には、設定情報データ群１４１の検索式３０６のフィールドにおいて指定できるキー文字列が設定されている。すなわち、ＩＤ２０１には「ｉｄ」、データソース２０２には「ｄａｔａｓｒｃ」、オブジェクト種別２０３には「ｏｂｊｔｙｐｅ」、タイムスタンプ２０４には「ｔｉｍｅｓｔａｍｐ」、相対位置２０５には「ｘ」と「ｙ」、相対速度２０６には「ｖ_ｘ」と「ｖ_ｙ」が設定されている。なお、図３では記載していないが、固有情報２０７に格納されるデータ要素に対しても、それぞれ所定のキー文字列が割り当てられているものとする。

　ＩＤ２０１のフィールドには、対象オブジェクトデータが示す対象要素を識別するための識別子が格納される。同一の対象要素、たとえば同じ車両を示す複数のオブジェクトデータには、ＩＤ２０１のフィールドに同一の値が設定される。図３の例では、オブジェクトデータ群１４２全体で重複がないように値が設定されているが、データソース２０２等との組み合わせでユニーク性を保証する形態でも良い。データソース２０２のフィールドには、対象オブジェクトデータの生成元を示す情報が格納される。例えば、図３の一つ目のデータエントリ（ｉｄ＝１）では、データソース２０２のフィールドに「センサＡ」が設定されている。これは、対象オブジェクトデータの生成元がセンサ群３に含まれるセンサＡ、厳密にはセンサＡ適合部１１１であることを表している。

　オブジェクト種別２０３のフィールドには、対象オブジェクトデータが示す対象要素の概念的な種別を表す情報が格納される。オブジェクト種別２０３に格納される対象要素の種別とは、たとえば他車両、歩行者、白線等が挙げられる。タイムスタンプ２０４のフィールドには、対象オブジェクトデータに関する時間情報が格納される。タイムスタンプ２０４のフィールドに格納される時間情報は、例えば、データソース２０２が表す対象オブジェクトデータの生成元がセンサ群３に含まれるセンサである場合は、対象オブジェクトデータを検出した時刻に相当する。これにより、任意の時点における対象オブジェクトデータの状態を推測する際に、対象オブジェクトデータに時間に応じた補正をかけることが可能となる。なお、タイムスタンプ２０４には、車両制御装置２におけるオブジェクトデータの時間管理のポリシーに応じて、例えば記憶部４０における対象オブジェクトデータの更新時刻など、別の時間情報を格納してもよい。

　相対位置２０５のフィールドは、当該車両に対する対象オブジェクトデータが示す対象要素の相対位置を示す情報が格納される。相対位置の座標は、例えば、当該車両を中心としたｘ－ｙ座標系で表現され、ｘ軸は当該車両の参照点、たとえば車両の重心を前後方向に貫く中心軸（前方向が正）、ｙ軸は当該車両の参照点を左右方向に貫く中心軸（左方向が正）とする。例えば、図３の一つ目のデータエントリ（ｉｄ＝１）は、当該車両から３０ｍ前方かつ０．１ｍ左方に、該対象要素が位置することを意味する。相対速度２０６のフィールドには、当該車両に対する対象オブジェクトデータが示す対象要素の相対速度を示す情報が格納される。相対速度の座標軸は、相対位置２０５と共通とする。

　固有情報２０７のフィールドには、データソース２０２とオブジェクト種別２０３の組合せに応じて、オブジェクトデータごとに異なるデータが格納されている。例えば、ｄａｔａｓｒｃ＝“センサＡ”かつｏｂｊｔｙｐｅ＝”他車両”のオブジェクトデータにはウィンカー情報が格納されているのに対し、ｏｂｊｔｙｐｅ＝”歩行者”のオブジェクトデータや、ｄａｔａｓｒｃ＝“センサＢ”のオブジェクトデータには格納されていない。これはセンサごとに検出可能な情報が異なることや、対象要素の種別に応じて識別される情報が異なることが原因である。

（設定変更用データ群１４３）
　図４は、設定変更用データ群１４３の一例を示す図である。図４（ａ）は設定変更用データ群１４３ａの一例を示す図、図４（ｂ）は設定変更用データ群１４３ｂの一例を示す図である。前述のように、設定変更用データ群１４３は記憶部４０に格納される。設定変更用データ群１４３は、実行制御部１４が設定情報データ群１４１を動的に変更する際に参照するデータの集合である。設定変更用データ群１４３は、複数のレコードから構成され、各レコードには、設定変更を実行させるトリガーとなるイベントと、変更後の設定情報とが格納される。実行制御部１４は所定のイベントを検出すると、設定変更用データ群１４３において当該イベントが該当する設定情報に設定情報データ群１４１を変更する。図４に示すように、設定変更用データ群１４３の各レコードは、イベント種別４０１、変更先設定情報４０２、およびモジュールリスト４０３のフィールドを有する。

　イベント種別４０１のフィールドには、設定変更を実行させるトリガーとなるイベントを示す情報が格納される。「装置起動」とは、車両制御装置２の起動イベントを意味する。「車両制御装置２ｂ故障」とは、車両制御装置２ｂの故障検知イベントを意味する。「車両制御装置２ｂ復帰」とは、車両制御装置２ｂが故障後、再起動などを通じて復帰したことを検知したイベントを意味する。

　変更先設定情報４０２のフィールドには、イベント種別４０１のイベント発生時に変更すべき設定情報が格納される。ここでの設定情報とは、設定情報データ群１４１に相当する情報である。モジュールリスト４０３のフィールドには、イベント種別４０１のイベント発生以後に使用するモジュールリストの名称が格納される。モジュールリストとは、機能部品を実行すべき順番に並べたリストである。

　図５（ａ）は符号４１０で示す設定情報テーブルＡの一例を示す図、図５（ｂ）は符号４２０で示す設定情報テーブルＢの一例を示す図である。符号４１０で示す設定情報テーブルＡは、構造および格納される情報が図２（ａ）に示す設定情報データ群１４１ａと同一である。符号４２０で示す設定情報テーブルＢは、構造は設定情報データ群１４１ａと構造は同一であるが格納される情報が異なる。図５を参照した動作例は後に説明する。

　図６（ａ）はモジュールリストＭ１の一例を示す図、図６（ｂ）はモジュールリストＭ２の一例を示す図である。ただし図６は図５に対応している。すなわち図５（ａ）において実行要否のフィールドに「ＹＥＳ」が格納されているモジュール種別、すなわち機能部品が、図６（ａ）のモジュールリストＭ１に記載されている。同様に、図５（ｂ）において実行要否のフィールドに「ＹＥＳ」が格納されているモジュール種別、すなわち機能部品が、図６（ｂ）のモジュールリストＭ２に記載されている。なお図５と図６において記載順番が一致していることに特に理由はない。設定情報テーブルにおける機能部品の記載順番と、機能部品の実行順番は何ら関係はない。

（オブジェクトデータ操作インタフェース）
　図７に示す疑似コード群Ｃ５０１は、オブジェクトデータ操作インタフェース１２５をＣ言語でそれぞれ記述した場合のヘッダファイルの一部を表現したものである。疑似コード群Ｃ５０１は、オブジェクトデータの更新用ＡＰＩを表す疑似コード５１１と、オブジェクトデータの検索ＡＰＩを表す疑似コード５１２と、モジュールイベント通知ＡＰＩを表す疑似コード５１３と、を含む。以下では、これらの疑似コードが表すＡＰＩについて説明する。

　疑似コード５１１が表すオブジェクトデータの更新ＡＰＩである”updateData”は、車両システム１の所定の車両制御装置２のオブジェクトデータ群１４２に対する更新操作を行うＡＰＩである。オブジェクトデータ群１４２に対する更新操作には、「登録操作」、「上書き操作」、および「削除操作」が含まれる。登録操作とは、オブジェクトデータ群１４２に対して新しいオブジェクトデータを挿入する操作である。上書き操作とは、オブジェクトデータ群１４２に格納されている所定のオブジェクトデータを、新しいオブジェクトデータで上書きする操作である。削除操作とは、オブジェクトデータ群１４２に格納されている所定のオブジェクトデータを削除する操作である。疑似コード５１１で表されるように、更新ＡＰＩの引数は、当該ＡＰＩを呼び出した機能部品を識別するモジュールＩＤである”moduleID”と、操作対象のオブジェクトデータのデータ長である”dataSize”と、操作対象のオブジェクトデータのアドレスである”data”と、実行する更新操作の種別を識別する操作モードである”mode”と、で構成される。本引数におけるモジュールＩＤは、図２のモジュールＩＤ３０１に相当する。操作対象のオブジェクトデータのデータ長及びアドレスは、操作モードが登録操作または上書き操作の場合のみ引数値として格納される。

　オブジェクトデータの更新ＡＰＩが呼ばれると、オブジェクトデータ操作実行制御部１２２に引数情報が渡される。指定された更新操作が実行される車両制御装置２は、前述のように設定情報データ群１４１の設定に基づいて決定されるため、必ずしも当該ＡＰＩが呼び出された車両制御装置２上のオブジェクトデータ群１４２に対して適用されるとは限らない。オブジェクトデータ群１４２に対して適用される場合は、オブジェクトデータ操作実行部１２１に引数情報が渡され、指定された更新操作が実行される。

　疑似コード５１２が表すオブジェクトデータの検索ＡＰＩである”searchData”は、当該ＡＰＩが呼び出された車両制御装置２のオブジェクトデータ群１４２の中から、所定の検索条件に該当するオブジェクトデータを取得する操作である「検索操作」のＡＰＩである。疑似コード５１２で表されるように、検索ＡＰＩの引数は、モジュールＩＤである”moduleID”と、検索式である”searchCond”と、検索結果を格納するバッファの情報である”dataSize、data”とを含む。当該ＡＰＩの検索式は、図２の検索式３０６に相当する。

　オブジェクトデータの検索ＡＰＩが呼ばれると、オブジェクトデータ操作実行部１２１に引数情報が渡される。オブジェクトデータ操作実行部１２１は、渡された検索式の文字列を所定の文法に従って解析・解釈し、オブジェクトデータ群１４２の中から所定の条件に該当するオブジェクトデータのリストを抽出する。そして、検索式の中にソート条件が設定されている場合は、それに従い整列した結果をバッファに格納して、呼び出し元に返す。

　疑似コード５１３が表すモジュールイベント通知ＡＰＩである”notifyModuleEvent”は、指定されたモジュールＩＤに関するイベントをデータ管理部１２に通知するためのＡＰＩである。疑似コード５１３で表されるように、当該ＡＰＩの引数は、モジュールＩＤである”moduleID”と、通知種別である”notifyType”と、で構成される。本引数における通知種別としては、例えば、「演算実行完了通知」が挙げられる。演算実行完了通知は、本引数におけるモジュールＩＤに該当する機能部品の演算実行が完了したことをデータ管理部１２に通知するときに用いられる。

（周期処理のフローチャート）
　図８は、車両制御装置２における実行制御部１４の周期処理を表すフローチャートである。実行制御部１４は所定の時間間隔で、たとえば１００ｍｓ周期で図８に示す周期処理を実行する。なお以下では、機能部品を「モジュール」とも呼ぶ。

　実行制御部１４は、初めにＳ６０１において実行制御対象のモジュールリストＭを取得する。ただしこのモジュールリストＭは、設定変更用データ群１４３においてモジュールリスト４０３のフィールドに格納されたモジュールリストのコピーである。たとえば直前のイベントが「装置起動」の場合は、モジュールリストＭ１のコピーをモジュールリストＭとして取得する。なおモジュールリストＭはモジュールリストＭ１のコピーなので、以下ではモジュールリストＭの一部を削除するが、この処理はモジュールリストＭ１には影響を与えない。

　続くＳ６０２では実行制御部１４はモジュールリストＭが空集合であるか否かを判断し、空集合ではないと判断する場合はＳ６０３に進み、空集合であると判断する場合はＳ６０７に進む。Ｓ６０３では実行制御部１４はモジュールリストＭの先頭のモジュールｍを取得する。続くＳ６０４では実行制御部１４はモジュールｍの実行関数を呼び出し、モジュールｍの演算を実行する。そして実行制御部１４は、演算の実行が完了すると、図７に示したデータ管理部１２のオブジェクトデータ操作インタフェース１２５のモジュールイベント通知ＡＰＩを用いて、モジュールｍの演算実行完了イベントをデータ管理部１２に通知し（Ｓ６０５）、モジュールリストＭから演算実行済みのモジュールｍを削除して（Ｓ６０６）、Ｓ６０２に戻る。

　Ｓ６０３からＳ６０６の処理がモジュールリストＭのすべてのモジュールに対して適用されると、モジュールリストＭがカラ、すなわち空集合になるため、Ｓ６０７に進む。Ｓ６０７では、実行制御部１４は、モジュールの配置変更イベントの有無を判断する。ここでモジュールの配置変更イベントとは、図４の設定変更用データ群１４３のイベント種別４０１に相当するものであり、診断部１５により検出される。モジュールの配置変更イベントがないと判断する場合は（Ｓ６０７：Ｎ）、図８に示す処理を終了する。モジュールの配置変更イベントが生じていたと判断する場合は（Ｓ６０７：Ｙ）、実行制御部１４は設定情報を変更して（Ｓ６０８）から図８に示す処理を終了する。詳述すると実行制御部１４は、設定変更用データ群１４３を参照して、該イベントに該当する変更先設定情報４０２を特定し、データ管理部１２の設定インタフェース１２６を用いて、設定情報管理部１２３を介して設定情報データ群１４１を書き換える。

　以上説明した処理により、車両制御装置２の機能を実現するための１サイクルの演算処理、すなわちアプリケーション処理が実行される。車両制御装置２では、定期的に図８に示す処理を実行することにより、車両システム１におけるＡＤＡＳ又は自動運転の機能が実現される。

（オブジェクトデータ更新処理のフローチャート）
　図９は、データ管理部１２のオブジェクトデータ操作実行制御部１２２によるオブジェクトデータ更新処理を示すフローチャートである。データ管理部１２は、データ適合部１１またはデータ演算部１３の機能部品により前述したオブジェクトデータの更新ＡＰＩが呼ばれると、図９に示す処理を実行する。

　オブジェクトデータ操作実行制御部１２２は、モジュールｍからオブジェクトデータの更新操作要求を取得する（Ｓ７０１）。これは、データ適合部１１及びデータ演算部１３による更新ＡＰＩの呼び出しに相当し、オブジェクトデータの更新操作要求は、更新ＡＰＩの引数として渡されたデータ群に相当する。次に、オブジェクトデータ操作実行制御部１２２は、Ｓ７０２において、設定情報データ群１４１におけるモジュールｍに該当するデータエントリの格納要否３０３を参照し、更新操作要求に基づき要求を受けたオブジェクトデータを当該装置のオブジェクトデータ群１４２に格納するか否かを判断する。オブジェクトデータ操作実行制御部１２２は、モジュールｍの格納要否３０３のフィールドに「Ｎｏ」が格納されていると判断する場合は（Ｓ７０２：Ｎ）、更新操作を実行せずにＳ７０４に移る。モジュールｍの格納要否３０３が「Ｙｅｓ」の場合は（Ｓ７０２：Ｙ）、更新操作要求をオブジェクトデータ操作実行部１２１に渡して、Ｓ７０３に移る。

　Ｓ７０３ではオブジェクトデータ操作実行部１２１は、更新操作要求の指示に従い、記憶部４０に格納しているオブジェクトデータ群１４２に対してデータ操作を実行して、Ｓ７０４に進む。なおデータ操作には前述のように「登録操作」、「上書き操作」、および「削除操作」が含まれるが、いずれもオブジェクトデータ群１４２の中から、更新操作要求対象のオブジェクトデータに相当するデータエントリを特定して、その次に指定された操作（登録、上書き、削除）を実行する。なお、データエントリの特定は、オブジェクトデータの中に含まれる所定のデータ要素もしくは複数のデータ要素の組合せ、たとえば図３のＩＤ２０１とデータソース２０２の組合せにより行われる。

　Ｓ７０４ではオブジェクトデータ操作実行制御部１２２は、設定情報データ群１４１におけるモジュールｍに該当するデータエントリの出力要否３０４を参照し、オブジェクトデータ更新操作要求メッセージとして更新操作要求を外部に出力するか否かを判断する。オブジェクトデータ操作実行制御部１２２はモジュールｍの出力要否３０４が「Ｎｏ」であると判断する場合は（Ｓ７０４：Ｎ）、図９に示す処理を終了する。オブジェクトデータ操作実行制御部１２２はモジュールｍの出力要否３０４が「Ｙｅｓ」であると判断する場合は（Ｓ７０４：Ｙ）Ｓ７０５に進む。Ｓ７０５ではオブジェクトデータ操作実行制御部１２２は、設定情報データ群１４１におけるモジュールｍに該当するデータエントリの出力タイミング３０５を参照し、設定値が「操作実行時」、および「演算完了時」のいずれであるかを判断する。出力タイミング３０５の設定値が「演算完了時」であると判断する場合は（Ｓ７０５：Ｎ）、図９に示す処理を終了する。オブジェクトデータ操作実行制御部１２２は出力タイミング３０５の設定値が「操作実行時」であると判断する場合は（Ｓ７０５：Ｙ）、Ｓ７０６に進む。

　Ｓ７０６ではオブジェクトデータ操作実行制御部１２２は、設定情報データ群１４１におけるモジュールｍに該当するデータエントリの検索式３０６を参照し、検索式３０６のフィールドに検索式が記載されているか否かを確認する。オブジェクトデータ操作実行制御部１２２は検索式が記載されていないと判断する場合は（Ｓ７０６：Ｎ）、更新操作要求をそのまま転送用更新操作要求として設定し（Ｓ７０８）、オブジェクトデータ更新操作要求メッセージとして当該装置の外部に転送し（Ｓ７０９）、図９に示す処理を終了する。オブジェクトデータ操作実行制御部１２２は検索式が記載されていると判断する場合は（Ｓ７０６：Ｙ）Ｓ７０７に進み、更新要求の対象のオブジェクトデータに対して記載されている検索式を適用して、転送対象のオブジェクトデータを抽出する。その上でオブジェクトデータ操作実行制御部１２２は、転送対象のオブジェクトデータに対応する転送用更新操作要求を生成し、オブジェクトデータ更新操作要求メッセージとして当該装置の外部に転送し（Ｓ７０９）、図９に示す処理を終了する。

（完了通知受信処理のフローチャート）
　図１０は、データ管理部１２が演算実行完了通知を受信した際の処理である完了通知受信処理を示すフローチャートである。図１０に示す完了通知受信処理は、実行制御部１４により、前述したモジュールイベント通知ＡＰＩが呼ばれると実行される。

　オブジェクトデータ操作実行制御部１２２はまずＳ８０１において、実行制御部１４からモジュールｍの演算実行完了通知を受信する。この受信は、引数の通知種別として「演算実行完了通知」が指定されたモジュールイベント通知ＡＰＩの呼び出しに相当する。オブジェクトデータ操作実行制御部１２２はＳ８０２において、設定情報データ群１４１におけるモジュールｍに該当するデータエントリのタイミング３０５を参照し、設定値が「演算完了時」であるか否かを判断する。オブジェクトデータ操作実行制御部１２２は、設定値が「演算完了後」ではないと判断する場合は（Ｓ８０２：Ｎ）図１０に示す処理を終了する。オブジェクトデータ操作実行制御部１２２は、設定値が「演算完了後」であると判断する場合は（Ｓ８０２：Ｙ）Ｓ８０３に進む。

　Ｓ８０３ではオブジェクトデータ操作実行制御部１２２は、設定情報データ群１４１におけるモジュールｍに該当するデータエントリの検索式３０６を参照し、設定されている検索式に基づき、オブジェクトデータ群１４２から対象となるオブジェクトデータを取得する。具体的には、オブジェクトデータ操作実行制御部１２２がその検索式を用いた検索操作要求を生成し、オブジェクトデータ操作実行部１２１に渡す。そしてオブジェクトデータ操作実行部１２１が、その検索操作要求に従い記憶部４０のオブジェクトデータ群１４２に対して検索操作を実行し、抽出した結果をオブジェクトデータ操作実行制御部１２２に返す。

　続くＳ８０４ではオブジェクトデータ操作実行制御部１２２は、Ｓ８０３において取得したオブジェクトデータに対応する転送用更新操作要求を生成し、オブジェクトデータ更新操作要求メッセージとして当該装置の外部に転送して図１０に示す処理を終了する。

（オブジェクトデータ更新操作要求メッセージ９００）
　図１１は、車両制御装置２が送信するオブジェクトデータ更新操作要求メッセージ９００の一例を示す図である。ただし図１１では、通信プロトコルに関するヘッダ情報等の図示は割愛している。オブジェクトデータ更新操作要求メッセージ９００は、モジュールＩＤ９０１、操作種別９０２、オブジェクトデータ数９０３、およびオブジェクトデータ群９０４を含む。オブジェクトデータ群９０４は、オブジェクトデータ９０４－１、オブジェクトデータ９０４－２、、、およびオブジェクトデータ９０４－ｎから構成される。

　オブジェクトデータ更新操作要求メッセージ９００は、オブジェクトデータ操作インタフェース１２５の更新用ＡＰＩの引数に相当する情報である。オブジェクトデータ更新操作要求メッセージ９００を受信した車両制御装置２は、受信したオブジェクトデータ更新操作要求メッセージ９００を引数としてオブジェクトデータ操作インタフェース１２５の更新用ＡＰＩを呼び出すことができる。モジュールＩＤ９０１は該更新操作の呼び出し元の機能部品に相当するモジュールＩＤ、すなわち図７に示した更新用ＡＰＩ疑似コード５１１の第一引数を表す。また操作種別９０２は、更新操作の操作種別、すなわち図７に示した更新用ＡＰＩ疑似コード５１１の第二引数を表している。オブジェクトデータ数９０３は、オブジェクトデータ群９０４のエントリ数を表す。オブジェクトデータ群９０４は、更新操作対象のオブジェクトデータのリストである。すなわち図１１に示す例ではオブジェクトデータ数が「ｎ」なのでオブジェクトデータ群９０４は、オブジェクトデータ９０４－１、オブジェクトデータ９０４－２、、、およびオブジェクトデータ９０４－ｎから構成される。

　以上説明した処理により、車両システム１における一連の演算処理を継続しながら機能部品の配置変更、すなわち動的な配置変更を実現することが可能である。

（動作例）
　図１２は、車両システム１における動的な配置変更の動作例を説明する図である。図１２では、車両システム１が図１の状態で動作中に車両制御装置２ｂが故障したため、車両制御装置２ｂで動作していたアプリケーションを車両制御装置２ａで立ち上げて、車両システム１の機能維持、すなわちフェールオペレーショナルを実現している様子を表している。以下では、図１に示すように車両制御装置２ａと車両制御装置２ｂとが協調して動作している状態を協調動作状態と呼び、図１２に示すように車両制御装置２ａが単独で動作している状態を単独動作状態と呼ぶ。

　車両システム１の機能を維持するためには、センサ群３のデータ入力に対する車両制御装置２ａの演算結果、換言するとアクチュエータ群４へのデータ出力が、図１と同等である必要がある。そのためには図１２のデータ適合部１１ａ及びデータ演算部１３ａの機能部品間の入出力関係が、図１と同等である必要がある。

　図１２では、図１の状態に対して、車両制御装置２ａ上で走行制御演算部１３３とアクチュエータに対する適合部１１４、１１５が追加されている点で異なる。そのため、単独動作状態では少なくともこれらの機能部品も車両制御装置２ａ上で実行する必要がある。また、地図フュージョン演算部１３２の演算結果は、それまで車両制御装置２ｂに送信する必要があったが、走行制御演算部１３３が車両制御装置２ａに移動したため、車両制御装置２ａの記憶部４０ａに格納するように変更する必要がある。このように、動的な配置変更を行う際は、車両制御装置で実行する機能部品対象と、各機能部品の演算結果の格納場所の整合性を持たせながら変更する必要がある。

　車両制御装置２ｂの故障時における、車両制御装置２ａの動作を説明する。まず、車両制御装置２ｂの故障は、車両制御装置２ａの診断部１５ａにより、キープアライブの欠落等を通じて検知され、実行制御部１４ａにイベントとして通知される。その状態において、実行制御部１４ａは、周期的に実行される図８に示す周期処理のＳ６０７において、車両制御装置２ｂの故障という配置変更イベントが生じていると判断し（Ｓ６０７：Ｙ）、Ｓ６０８に進む。実行制御部１４ａはＳ６０８において、図４の設定変更用データ群１４３ａの該当エントリを参照し、変更先設定情報を特定する。図４の例では、設定情報テーブルＢが該当するため、実行制御部１４ａは、データ管理部１２ａの設定インタフェース１２６を用いて、設定情報管理部１２３を介して設定情報データ群１４１ａを設定情報テーブルＢの内容に書き換える。

　この設定情報データ群１４１ａの書き換えにより、次の周期で実行制御部１４ａが図８の処理を実行する際には、設定情報テーブルＢの設定情報に基づいて、モジュールの実行及びそのデータの格納先が制御される。故障前の設定情報データ群１４１ａの設定情報と故障後の設定情報データ群１４１ａの設定情報とでは、走行制御演算部１３３、アクチュエータに対する適合部１１４、１１５に対する実行要否３０２が「Ｙｅｓ」に変更されている点と、地図フュージョン演算部の格納要否３０３が「Ｙｅｓ」、出力要否３０４が「Ｎｏ」に変更されている点と、が主に異なる。この設定により、図１２に示すような機能部品の実行とデータ入出力関係を実現することができ、車両システム１の機能を図１のときと同等に維持することができる。なお、上述のように、機能部品の入出力インタフェースは、データ管理部１２のオブジェクトデータ操作インタフェース１２５、または通信制御部５０が提供するインタフェースであり、いずれも装置に依存しない汎用インタフェースであるため、配置変更に伴うプログラムの修正は発生しない。

　上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）車両制御装置２ａは、外部装置である車両制御装置２ｂと通信可能に接続される。車両制御装置２ａは、車両制御装置２ｂとのデータ送受信を制御する通信制御部５０ａと、オブジェクトデータを管理するデータ管理部１２ａと、データ管理部１２ａまたは通信制御部５０ａから取得されるオブジェクトデータを用いて所定の演算を行い、所定の演算により得られたオブジェクトデータをデータ管理部１２ａに出力する１つ以上の機能部品を備えるデータ適合部１１ａおよびデータ演算部１３ａと、機能部品ごとにオブジェクトデータの書き込み先に関する情報、すなわち格納要否３０３および出力要否３０４のフィールドの値が格納される設定情報データ群１４１ａ、およびオブジェクトデータを記憶する記憶部４０ａとを備える。データ管理部１２ａは、オブジェクトデータの書込み先を、設定情報データ群１４１ａに基づいて制御する。

　このように、本実施形態によれば、機能部品の入出力インタフェースを変えないまま、設定情報データ群１４１を用いて機能部品の実行とデータの出力先、すなわち格納先を制御できるようなソフトウェア構成にすることにより、アプリケーションの動的な配置変更に対応することが可能である。また、設定情報データ群１４１を変更することによって、アプリケーションの静的な配置変更に対応することも可能である。すなわち不要なデータの保存や通信を低減することができる。

　また、本実施形態によれば、機能部品が演算結果として出力するオブジェクトデータの格納先は、設定情報データ群１４１に基づいて制御される。設定情報データ群１４１は、設定情報をオブジェクトデータの出力元の機能部品に関連付けて管理しているため、機能部品の更新操作インタフェースには、該機能部品を識別する情報が含まれていれば良い。そのため、各機能部品は該オブジェクトデータの出力先を意識する必要はなく、例えば、該オブジェクトデータを利用する機能部品が追加されたり、削除されたりしても、出力元の機能部品を修正する必要がない。そのため、静的または動的な機能部品の追加や削除を柔軟に行うことが可能である。

　また、本実施形態によれば、演算処理に関わる各機能部品の入出力インタフェースに、汎用的にデータの検索操作及び更新操作等を可能とする共通インタフェースを採用している。そのため、演算処理に関わるすべての機能部品間のデータ受渡しを、該共通インタフェースの呼び出し実行の中で統一的に制御することが可能である。これにより、上述のように、設定情報によりデータの格納先を容易に制御することが可能となる。もしも、このような共通インタフェースを使用しない場合は、データ管理部１２は各機能部品に対して、個別にインタフェースを生成することになるため、設定情報等により統一的にデータの格納先等を制御するのは困難である。

（２）設定情報データ群１４１ａは、機能部品ごとにオブジェクトデータの外部装置への出力要否に関する外部出力要否情報、すなわち出力要否３０４のフィールドの値を含む。データ管理部１２ａは、外部出力要否情報が出力要、すなわち「Ｙｅｓ」が格納されている場合に、通信制御部５０ａを介して車両制御装置２ｂにオブジェクトデータを出力する。

　そのため、機能部品の配置変更時に、データの格納先の設定を動的に変更するため、従来技術のように予めすべてのデータを複数の装置間で共有しておく必要がない。そのため、使用されない不要なデータの転送や保存を削減することができ、ネットワーク帯域や記憶容量の消費を低減することが可能となる。

（３）車両制御装置２ａは、機能部品の実行を制御する演算実行制御部１４ａを備える。設定情報データ群１４１ａは、機能部品の実行要否に関する実行要否情報、すなわち実行要否３０２のフィールドの値を含む。演算実行制御部１４ａは、実行要否情報が実行要の場合に、機能部品の所定の演算を実行する。そのため車両制御装置２ａは、機能部品の実行を容易に制御することができる。

（４）記憶部４０ａには、複数のイベントのそれぞれに対応する複数の設定情報、たとえば図５に示す設定情報テーブルＡおよび設定情報テーブルＢが格納される。データ管理部１２ａおよび演算実行制御部１４ａは、複数のイベントのいずれかのイベントが検出されると、検出されたイベントに対応する設定情報に基づき動作する。そのため車両制御装置２ａは、検出されたイベントに対応する設定に変更し、動作を変更することができる。

（５）記憶部４０ａは、イベントとイベントが検出された際に適用する設定情報とが関連付けられた設定変更用データ群１４３ａを記憶する。データ管理部１２ａおよび演算実行制御部１４ａは、複数のイベントのいずれかのイベントが検出されると、設定変更用データ群１４３ａを参照して適用する設定情報データ群１４１ａを特定し、特定した設定情報データ群１４１ａに基づき動作する。そのため車両制御装置２ａは、予め設定された設定変更用データ群１４３ａを参照して動作を変更することができる。

（６）イベントには、車両制御装置２ｂで動作している機能部品である走行制御演算部１３３の故障である「車両制御用装置２ｂ故障」が含まれる。「車両制御装置２ｂ故障」に対応する設定情報テーブルＢには、走行制御演算部１３３が実行要であることを含む。そのため車両制御装置２ａは、故障が検出された他の装置において実行されていた機能部品を自ら実行することで車両システム１の機能を維持することができる。

（７）設定情報データ群１４１ａには、データ管理部１２ａが管理するオブジェクトデータの中から車両制御装置２ｂに出力する対象を読出すための条件式を検索式３０６のフィールドに機能部品ごとに含めることができる。実行制御部１４ａは、所定の演算を実行した機能部品について設定情報データ群１４１ａにおいて検索式３０６が含まれる場合は、データ管理部１２ａが管理するオブジェクトデータの中から検索式３０６に適合するオブジェクトデータを読出し（図１０のＳ８０４）、車両制御装置２ｂに出力する。

　本実施形態によれば、演算処理に関わる各機能部品は、データ管理部１２が管理しているオブジェクトデータ群１４２から検索操作で必要なデータを抽出して取得する構成になっている。そのため、該機能部品の演算に必要なデータエントリがオブジェクトデータ群１４２に含まれていれば、他の不要なデータエントリが含まれているかどうかに関わらず、検索操作により同じように必要なデータエントリを抽出することが可能である。

　例えば、図１２では、走行制御演算部１３３は、地図フュージョン演算部１３２の実行後のすべてのオブジェクトデータが含まれているオブジェクトデータ群１４２ａに対して、走行制御演算部１３３はオブジェクトデータ操作インタフェース１２５を介して検索操作を実行することにより、必要なデータエントリを抽出して取得する。それに対し、配置変更前の図１の状態では、走行制御演算部１３３が検索操作をオブジェクトデータ群１４２ｂに対して実行するが、オブジェクトデータ群１４２ｂには、図２における地図フュージョン演算部１３２のデータエントリの検索式３０６の条件に合致するオブジェクトデータしか格納されていない。ここで指定された検索式３０６は、走行制御演算部１３３が必要なオブジェクトデータを抽出して、転送することが目的なので、走行制御演算部１３３が実行する検索操作で指定する検索式と同等である。そのため、走行制御演算部１３３の演算に必要なデータエントリのみがオブジェクトデータ群１４２ｂに含まれている状態になり、走行制御演算部１３３が検索操作により取得可能なデータは図１２のときと同等になる。もしも、機能部品が検索操作を用いない構造の場合は、図１と図１２で異なる量のオブジェクトデータ群を扱うことになるため、プログラムの修正なく同じ演算結果を得るのは困難である。つまり、機能部品が検索操作によりデータを取得する構成になっていることにより、別装置へのデータの転送する際に不要なデータを除いて転送しても、プログラム修正なく配置変更することができるようになっていると言える。

（８）設定情報データ群１４１ａには、出力するオブジェクトデータの中から車両制御装置２ｂに出力する対象を選定するための条件式を検索式３０６のフィールドに含む。データ管理部１２ａは、出力するオブジェクトデータの中から検索式３０６に適合する対象データを抽出し（図９のＳ７０７）、車両制御装置２ｂに出力する（Ｓ７０９）。

　本実施形態によれば、図２で示したように、他の装置にデータを転送する必要がある場合に、検索式を指定することにより、転送先に必要なデータエントリのみを抽出して転送することができる。そのため、従来技術ではデータ種別単位で転送設定するため、不要なデータエントリも含めて転送する必要があったが、本実施形態では、検索式により必要なデータエントリのみに限定して転送可能なため、不要なデータ転送によるネットワーク帯域や記憶容量の消費を低減することが可能となる。

（９）設定情報データ群１４１ａは、機能部品ごとに出力するオブジェクトデータの記憶部４０ａへの書込み要否に関する書込み要否３０２のフィールドの値を含む。データ管理部１２ａは、書込み要否情報が要の場合に、出力するオブジェクトデータの記憶部４０ａへの書込みを実行し、書込み要否情報が否の場合に、出力するオブジェクトデータの記憶部４０ａへの書込みを実行しない。そのため車両制御装置２ａは、不要なデータの保存を回避することができる。

（１０）データ管理部１２ｂは、車両制御装置２ａから出力された出力オブジェクトデータを通信制御部５０ｂを介して取得する。オブジェクトデータを出力した機能部品の設定情報における書込み要否情報に基づいて、出力オブジェクトデータの記憶部４０ｂへの書込みの実行を制御する。たとえば設定情報データ群１４１ｂにおいて地図フュージョン演算部１３２の格納要否３０３のフィールドの値は「Ｙｅｓ」なので、通信制御部５０ｂを介して取得する地図フュージョン演算部１３２が出力するオブジェクトデータを記憶部４０ｂに格納する。そのため車両制御装置２ａは、適切にデータを保存することができる。

（変形例１）
　診断部１５は、通信制御部５０を介して外部から設定変更要求を受信するとこれを実行制御部１４に出力してもよい。さらに外部から受信する設定変更要求は、付加的な情報、たとえば変更する設定を特定する情報が追加されてもよい。

　図１３は、変形例１における設定変更用データ群１４３ｐの一例を示す図である。設定変更用データ群１４３ｐによれば、外部から受信する設定変更要求に「変更指令Ｐ」、「変更指令Ｑ」、および「変更指令Ｒ」が含まれ、それぞれに対応する設定情報およびモジュールリストが規定される。

　本変形例によれば、上述した第１の実施の形態における作用効果に加えて次の作用効果が得られる。
（１１）イベントには、車両制御装置２ｂからの設定変更要求の受信が含まれる。そのため車両制御装置２は、外部からの要求に応じて動作を変更することができる。具体的には車両制御装置２は、外部からの設定変更要求に応じて設定変更用データ群１４３ｐから適切な設定情報テーブルを読み込み、以降に実行すべきモジュールリストを決定する。

―第２の実施の形態―
　第１の実施の形態では、車両制御装置２ａと車両制御装置２ｂとの間でアプリケーションの配置変更を行ってフェールオペレーショナルを実現する車両システム１を示した。第２の実施形態では、車両制御装置２の開発用システムを説明する。

（構成）
　図１４および図１５は、本発明の第２の実施の形態に係る車両制御装置を含む開発用システム１ａの構成を示す機能ブロック図である。操作用装置６の構成は次の図１５に示す。開発用システム１ａは、車両に搭載され、第１の実施の形態で示した車両制御装置２、センサ群３、アクチュエータ群４、地図情報管理装置５に加え、操作用装置６を含む。車両制御装置２の構成は第１の実施の形態と同様なので説明を省略する。

　図１５に示す操作用装置６は、例えば、パーソナルコンピュータのような汎用的な処理装置であり、車両制御装置２の開発者により、車両制御装置２の状態監視や制御に利用される。操作用装置６は、通信制御部５０ｃ、ログ入出力制御部６０、および設定変更操作部７０を備える。通信制御部５０ｃは、車両制御装置２の通信制御部５０ａに相当する。また、データ適合部１１ｃ、データ管理部１２ｃ、データ演算部１３ｃ、実行制御部１４ｃ、設定情報データ群１４１ｃ、およびオブジェクトデータ群１４２ｃは、車両制御装置２のデータ適合部１１ａ、データ管理部１２ａ、データ演算部１３ａ、実行制御部１４ａ、設定情報データ群１４１ａ、およびオブジェクトデータ群１４２ａに相当する。

　ログ入出力制御部６０は、車両制御装置２からネットワーク上に出力されたオブジェクトデータ更新操作要求メッセージをログデータ群１６１として保存する。ログ入出力制御部６０はまた、ログデータ群１６１から取得したオブジェクトデータ更新操作要求メッセージを所定のタイミングでネットワークに出力する。設定変更操作部７０は、車両制御装置２の実行制御部１４ａを介して、車両制御装置２ａの設定情報データ群１４１ａを変更する操作インタフェースを提供する。

　図１６は、車両制御装置２の設定情報データ群１４１ａの一例を示す図である。第１の実施の形態における設定情報と比較して異なる点は、いくつかの機能部品において、出力要否３０４のフィールドの値が「Ｙｅｓ」、出力タイミング３０５のフィールドの値が「操作実行時」となっている点である。これらの機能部品では、格納要否３０３のフィールドの値も「Ｙｅｓ」となっているため、演算結果を車両制御装置２のオブジェクトデータ群１４２ａに格納しつつ、外部にも出力することを意味する。これは、各機能部品の演算結果のログ出力に該当し、出力されるデータ（図１１のオブジェクトデータ更新操作要求メッセージ９００に該当）は、操作用装置６のログ入出力制御部６０により取得され、ログデータ群１６１に格納される。このとき、各ログデータは出力された時刻情報と関連付けて管理される。

　なお、図１６の設定情報では、オブジェクトデータ群１４２ａに格納されるものをすべて出力するようになっていたが、出力要否３０４の設定を調整することにより、特定の機能部品の演算結果のみを出力するようにすることが可能である。

（特定アプリケーションのデバッグ例）
　図１７～図１９を用いて、取得したログデータを再生して特定のアプリケーションのデバッグを行う例について説明する。

　図１７および図１８は、地図フュージョン演算部１３２のデバッグを行うためのシステムの構成の一例を示す機能ブロック図である。ここでは、図１４のシステム構成において車両制御装置２の動作確認中に、地図フュージョン演算部１３２の不具合が発見された想定である。その不具合が発生した前後の各機能部品の演算結果のログデータは、操作用装置６のログデータ群１６１に格納されている。図１７および図１８に示すシステム構成は、図１４および図１５に示すシステム構成と同一であるが、以下に説明するデバッグで動作させない機能部品は破線で示している。また図１７および図１８では、デバッグにおいて主なデータが流通する経路を太い矢印で示している。

　図１８では、ログ入出力制御部６０が、当該ログデータに関連付けて保存されている時刻情報に基づいて、車両制御装置２にログデータを出力する。上述のようにここでのログデータは、オブジェクトデータ更新操作要求メッセージに相当する。そのため、車両制御装置２のオブジェクトデータ操作実行制御部１２２の転送データと同じ扱いになり、オブジェクトデータ操作インタフェース１２５を介して、オブジェクトデータ操作実行制御部１２２に渡され、図９に示したオブジェクトデータ更新処理が実行される。

　図１９は、図１７における設定情報データ群１４１ａの一例を示す図である。図１７に示す構成は地図フュージョン演算部１３２のデバッグを目的とするため、図１９に示すように地図フュージョン演算部１３２を除いた機能部品は実行要否３０２のフィールドに「Ｎｏ」が設定される。地図フュージョン演算部１３２は、センサフュージョン演算部１３１の出力結果と、地図情報管理装置５から提供される地図情報と、を演算に用いるため、それらが入力データとして必要となる。そのため、地図装置適合部１１３とセンサフュージョン演算部１３１の格納要否３０３のフィールドの値が「Ｙｅｓ」に設定される。

　以上の設定情報により、ログ入出力制御部６０から再生出力されるセンサフュージョン演算部１３１と地図装置適合部１１３のオブジェクトデータ更新操作がオブジェクトデータ群１４２ａに反映されるため、地図フュージョン演算部１３２は、不具合が発生したのと同等の入力データに基づいて演算処理を行うため、高い確率で不具合を再現させることができるようになる。これにより、問題解析が容易になり、アプリケーションのデバッグを効率化することが可能となる。

　本実施形態によれば、機能部品の演算結果出力のログ出力や、ログ再生による所定のアプリケーションをデバッグするためにシステム環境構築を、操作用装置から設定情報を適切に変更することにより、プログラムを修正することなく実現することができる。

　なお、以上で説明した実施形態は一例であり、本発明はこれに限られない。すなわち、様々な応用が可能であり、あらゆる実施の形態が本発明の範囲に含まれる。
　例えば、上記実施形態では、車両制御装置２において、各処理は、同一の処理部及び記憶部で実行される想定で記載しているが、複数の異なる処理部及び記憶部で実行されてもよい。その場合は、例えば、同様の構成を持つ処理ソフトウェアがそれぞれの記憶部に搭載され、それぞれの処理部で分担して当該処理を実行する形になる。
　また、車両制御装置２の各処理を、プロセッサとＲＡＭを用いて、所定の動作プログラムを実行することで実現しているが、必要に応じて独自のハードウェアで実現することも可能である。また、上記の実施形態では、車両制御装置、センサ群、地図情報管理装置、アクチュエータ群を個別の装置として記載しているが、必要に応じて任意のいずれか２つ以上を組合せて実現することも可能である。
　また、図面には、実施形態を説明するために必要と考えられる制御線及び情報線を示しており、必ずしも、本発明が適用された実際の製品に含まれる全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

　次の優先権基礎出願の開示内容は引用文としてここに組み込まれる。
　日本国特許出願２０１７－１４３７３８（２０１７年７月２５日出願）

　１：車両システム、２：車両制御装置、３：センサ群、３ａ：センサＡ，３ｂ：センサＢ、４：アクチュエータ群、４ａ：アクチュエータＡ、４ｂ：アクチュエータＢ、５：地図情報管理装置、１０：処理部、１１：データ適合部、１２：データ管理部、１３：データ演算部、１４：実行制御部、１５：診断部、４０：記憶部、５０：通信制御部、１１１：センサＡ適合部、１１２：センサＢ適合部、１１３：地図装置適合部、１１４：アクチュエータＡ適合部、アクチュエータＢ適合部、１２１：オブジェクトデータ操作実行部、１２２：オブジェクトデータ操作実行制御部、１２３：設定情報管理部、１２５：オブジェクトデータ操作インタフェース、１２６：設定インタフェース、１３１：センサフュージョン演算部、１３２：地図フュージョン演算部、１３３：走行制御演算部

Claims

　外部装置と通信可能に接続された車両制御装置であって、
　前記外部装置とのデータ送受信を制御する通信制御部と、
　オブジェクトデータを管理するデータ管理部と、
　前記データ管理部または前記通信制御部から取得されるオブジェクトデータを用いて所定の演算を行い、前記所定の演算により得られたオブジェクトデータである出力オブジェクトデータを前記データ管理部に出力する１つ以上の機能部品と、
　前記機能部品ごとに前記出力オブジェクトデータの書き込み先に関する情報が格納される設定情報、およびオブジェクトデータを記憶する記憶部とを備え、
　前記データ管理部は、前記出力オブジェクトデータの書込み先を、前記設定情報に基づいて制御する車両制御装置。
　請求項１に記載の車両制御装置において、
　前記設定情報は、前記機能部品ごとに前記出力オブジェクトデータの前記外部装置への出力要否に関する外部出力要否情報を含み、
　前記データ管理部は、前記外部出力要否情報が出力要の場合に、前記通信制御部を介して前記外部装置に前記出力オブジェクトデータを出力する車両制御装置。
　請求項２に記載の車両制御装置において、
　前記機能部品の実行を制御する演算実行制御部をさらに備え、
　前記設定情報は、前記機能部品の実行要否に関する実行要否情報をさらに含み、
　前記演算実行制御部は、前記実行要否情報が実行要の場合に、前記機能部品の前記所定の演算を実行する車両制御装置。
　請求項３に記載の車両制御装置において、
　前記記憶部には、複数のイベントのそれぞれに対応する複数の前記設定情報が格納され、
　前記データ管理部および前記演算実行制御部は、前記複数のイベントのいずれかのイベントが検出されると、検出されたイベントに対応する前記設定情報に基づき動作する車両制御装置。
　請求項４に記載の車両制御装置において、
　前記記憶部は、イベントと前記イベントが検出された際に適用する前記設定情報とが関連付けられた設定変更情報テーブルをさらに記憶し、
　前記データ管理部および前記演算実行制御部は、前記複数のイベントのいずれかのイベントが検出されると、前記設定変更情報テーブルを参照して適用する前記設定情報を特定し、前記特定した前記設定情報に基づき動作する車両制御装置。
　請求項４に記載の車両制御装置において、
　前記イベントには、前記外部装置で動作している機能部品である第１機能部品の故障である第１機能部品故障イベントが含まれ、
　前記第１機能部品故障イベントに対応する前記設定情報には、前記第１機能部品が実行要であることを含む車両制御装置。
　請求項４に記載の車両制御装置において、
　前記イベントには、前記外部装置からの設定変更要求の受信が含まれる車両制御装置。
　請求項３に記載の車両制御装置において、
　前記設定情報には、前記データ管理部が管理するオブジェクトデータの中から前記外部装置に出力する対象を読出すための条件式を前記機能部品ごとに含めることができ、
　前記演算実行制御部は、前記所定の演算を実行した前記機能部品について前記設定情報において前記条件式が含まれる場合は、前記データ管理部が管理するオブジェクトデータの中から前記条件式に適合するオブジェクトデータを読出し、前記外部装置に出力する車両制御装置。
　請求項２に記載の車両制御装置において、
　前記設定情報には、前記出力オブジェクトデータの中から前記外部装置に出力する対象を選定するための条件式を含み、
　前記データ管理部は、前記出力オブジェクトデータの中から前記条件式に適合する対象データを抽出し、前記外部装置に出力する車両制御装置。
　請求項２に記載の車両制御装置において、
　前記設定情報は、前記機能部品ごとに前記出力オブジェクトデータの前記記憶部への書込み要否に関する書込み要否情報を含み、前記データ管理部は、前記書込み要否情報が要の場合に、前記出力オブジェクトデータの前記記憶部への書込みを実行し、
　前記書込み要否情報が否の場合に、前記出力オブジェクトデータの前記記憶部への書込みを実行しない車両制御装置。
　請求項１０に記載の車両制御装置において、
　前記データ管理部は、前記外部装置から出力された前記出力オブジェクトデータを前記通信制御部を介して取得し、
　前記出力オブジェクトデータを出力した前記機能部品の前記設定情報における前記書込み要否情報に基づいて、前記出力オブジェクトデータの前記記憶部への書込みの実行を制御する車両制御装置。