JP5299012B2

JP5299012B2 - アプリケーション実行制御装置、およびアプリケーション実行制御プログラム

Info

Publication number: JP5299012B2
Application number: JP2009074339A
Authority: JP
Inventors: 洋介佐藤
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2009-03-25
Filing date: 2009-03-25
Publication date: 2013-09-25
Anticipated expiration: 2029-03-25
Also published as: JP2010221961A

Description

本発明は、車両に搭載された複数のアプリケーションの実行を制御するアプリケーション実行制御装置、およびアプリケーション実行制御プログラムに関する。

情報処理の分野において、入力された条件に応じて、どのような処理を実施するかを選択するアプリケーションが広く知られている。このようなアプリケーションとしては、例えば、車両において目的地までの経路案内をする場合に、運転者の運転特性を入力し、この入力結果から運転者が渋滞を回避する経路を選択する運転特性があると判断できれば、多少遠回りになったとしても渋滞を回避する経路を自動的に選択するものが知られている（例えば特許文献１参照）。

特開２００８−０５８１９３号公報

しかしながら、上記アプリケーションでは、アプリケーション自体の起動および終了を管理する機能が備えられていない。このため、使用者が操作によってアプリケーションを起動または終了を指示しなければ、アプリケーションが処理を開始したり終了したりすることができない。特に車両において運転者が操作によってアプリケーションの起動または終了を指示しようとすると、運転者による運転操作に支障を来たす虞があった。

このような問題を解決するためには、例えば自動車のオートライトシステムのように、使用する可能性があるアプリケーションを待機状態で常時起動しておくことが考えられるが、多数のアプリケーションを待機状態にしておくことは、電力を多く消費してしまうことから好ましくない。

そこで、このような問題点を鑑み、電力を節約しつつ、複数のアプリケーションの起動および終了を管理することができる技術を提供することを本発明の目的とする。

かかる目的を達成するために成された本発明に記載のアプリケーション実行制御装置において、状況取得手段は、当該車両がおかれた状況を表す車両状況の検出結果である状況データを取得する。そして、検索手段は、状況データと対応してアプリケーション毎の作動条件または終了条件が記録された条件データベースを参照し、取得した状況データが一致する作動条件または終了条件に対応するアプリケーションを検索する。すると、送信手段は、検索によりヒットしたアプリケーションを作動または終了させる指令を送信する。

このようなアプリケーション実行制御装置によれば、車両状況に応じてアプリケーション自体の起動および終了を自律的に管理することができる。また、各アプリケーションを待機状態にしておく必要がないため、消費電力を節約することができる。

なお、本発明において「車両状況」とは、車両に搭載されたセンサによって検出可能なパラメータや、車両の現在地によって特定されうる天気や路面状態等の車両環境を表す。
また、請求項１に記載のアプリケーション実行制御装置においては、当該アプリケーション実行制御装置に対する要求である要求データを取得する要求取得手段と、各取得手段によって取得されたデータの種別が状況データであるか要求データであるかを判定するデータ種別判定手段と、データの種別が要求データであると判定された場合に、この要求データを第１記録手段に保存するとともに、データの種別が状況データであると判定された場合に、この状況データの少なくとも一部を間引きして第２記録手段に保存する保存制御手段と、を備えており、検索手段は、第２記録手段に記録された状況データを読み出して、この状況データが一致する作動条件または終了条件に対応するアプリケーションを検索する。

このような通信装置によれば、データを記録する際に、データの種別が要求データか状況データかを判定し、状況データについては少なくとも一部を間引きするので、第２記録手段の容量を節約することができる。一方で、要求データについては全て第１記録手段に保存するので、要求を漏れなく処理することができる。

なお、第１記録手段と第２記録手段とは、同一の記録手段として構成されていてもよい。また、本発明において「間引きする」とは、データの一部または全部を消去し、データ量を減少させることを意味する。

さらに、請求項１に記載のアプリケーション実行制御装置においては、請求項２に記載のように、要求取得手段は、要求データとして、新たな条件データベースを含むアプリケーションの変更要求を取得し、データ書換手段が第１記録手段に記録された要求データを読み出して、この要求データにアプリケーションの変更要求が含まれる場合に、条件データベースを書き換えるようにしてもよい。

このようなアプリケーション実行制御装置によれば、条件データベースを書き換える処理を自動的に行うことができる。
また、請求項１または請求項２に記載のアプリケーション実行制御装置においては、請求項３に記載のように、各アプリケーションが搭載された車両の外部に配置されていてもよい。

このようなアプリケーション実行制御装置によれば、車両の外部で車両において実行させるアプリケーションを選択することができる。よって、アプリケーションの作動条件や終了条件を変更する場合に、車両において設定を変更する必要がなく便利である。

また、１台のアプリケーション実行制御装置で複数の車両において実行させるアプリケーションを選択することもできる。この際には、車両を特定する周知の技術を利用しつつ、車両毎に状況データを取得し、車両毎にアプリケーションを作動または終了させる指令を送信すればよい。

次に、請求項４に記載の通信プログラムは、コンピュータを、請求項１〜請求項３の何れかに記載のアプリケーション実行制御装置を構成する各手段として機能させることを特徴としている。

このようなアプリケーション実行制御プログラムによれば、少なくとも請求項１のアプリケーション実行処理装置と同様の効果を享受することができる。

通信システムの概略構成を示すブロック図（ａ）、および通信ＥＣＵのソフトウェア構成を示す概念図（ｂ）である。 ASS DB（ａ）、起動条件ＤＢ（ｂ）、および終了条件ＤＢ（ｃ）の一例を示す説明図である。データ受信処理を示すフローチャート（ａ）、およびデータの種別を示す説明図（ｂ）である。実施形態のサービスプロセス作動処理を示すフローチャートである。変形例のサービスプロセス作動処理を示すフローチャート、およびサーバ処理を示すフローチャートである。

以下に本発明にかかる実施の形態を図面と共に説明する。
［本実施形態の構成］
図１（ａ）は本発明が適用された通信システム１の概略構成を示すブロック図、図１（ｂ）は通信ＥＣＵ１０のソフトウェア構成を示す概念図である。

図１（ａ）に示すように、通信システム１は、車両１００外部のサーバ２４と、車両１００に搭載された装置とが通信するよう構成されたシステムである。具体的には、車両１００には、通信ＥＣＵ１０（アプリケーション実行制御装置）（ＥＣＵは電子制御装置）と、センサ類４１と、通信ＥＣＵ１０以外の他のＥＣＵ４２と、が備えられており、これらは、車内の通信線３０によって互いに通信可能に接続されている。

通信ＥＣＵ１０は、マイクロプロセッサ（ＭＰＵ）１１、ＲＯＭ１２、ＲＡＭ１３（第１記録手段、第２記録手段）を備えた周知のマイコンとして構成されている。そして、通信ＥＣＵ１０は、アンテナ１６を介して車両外部との通信を行うための外部通信インタフェース（Ｉ／Ｆ）１４と、車両内部において通信線３０を介した通信を行うための車内通信Ｉ／Ｆ１５とを備えている。

外部通信Ｉ／Ｆ１４は、例えば、携帯電話モジュールとして構成されており、車両外部のアンテナ２２を有する基地局２１との通信を実施し、この基地局２１がインターネント網や電話回線網等のネットワーク２３に接続されたサーバ２４と車両１００との通信を媒介する。

なお、センサ類４１や他のＥＣＵ４２は、車両１００の外部のサーバ２４に車両の状況を通知するとき、およびサーバ２４に何らかの要求をするときに、通信ＥＣＵ１０にデータを送信するよう依頼を行う。また、サーバ２４は、車両１００からデータを受けると、受けたデータに対応した所定の処理を行い、処理結果を車両１００に返すよう構成されている。

通信ＥＣＵ１０のソフトウェア構成においては、図１（ｂ）に示すように、例えばオペレーションソフト等の車載プラットフォーム（ＰＦ）５１の上位に、ミドルウェア５４が配置され、さらに、ミドルウェアの上位に、サービスプロセスマネージャ６０（Service Process Manager）や多数のＳＷＣ５５（Software Component）等のコンポーネントが配置された階層構造に構成されている。

即ち、ミドルウェア５４は、実行するアプリケーションソフトに応じて適宜車載ＰＦ５１の機能を利用でき、各コンポーネントは、ミドルウェア５４および車載ＰＦ５１の機能を利用できることを示す。

ここで、車載ＰＦ５１には、各通信Ｉ／Ｆ１４，１５を用いて通信ＥＣＵ１０の外部（通信ＥＣＵ１０以外の車両１００の内部や車両１００の外部）との通信を行う機能を備えており、通信ＥＣＵ１０の内部的な処理の大半はミドルウェア５４およびコンポーネントが実施する。そして、本実施形態においては、車載ＰＦ５１とミドルウェア５４との間に、データのバッファリングを管理するプログラムであるＡＳＳ（Automotive Service Space）５２を備えている。

ＡＳＳ５２は、通信ＥＣＵ１０とその外部との間でやりとりされるデータに対するバッファリングを管理するプログラムである。なお、ＡＳＳ５２は、車両１００の外部と通信する際のバッファリングを管理するのみとし、車両１００の内部と通信する際のバッファリングは、例えばＡＣＳ（Automotive Component Space）等の別のプログラムを利用して管理してもよい。このようにＡＳＳ５２を設けておくことによって、通信速度と通信ＥＣＵ１０での処理速度との際が生じたときであっても、効率的に処理を実施することができる。

サービスプロセスマネージャ６０は、多数のサービスプロセス６１（Service Process）や、ＣＩＥ６２（Context Inference Engine）を備えて構成されており、ＣＩＥ６２が各サービスプロセス６１の実行状態（作動および終了のタイミング）を管理するように構成されている。

なお、本実施形態において、車載ＰＦ５１、ミドルウェア５４等の各プログラムを実行する主体はＭＰＵ１１であるが、本実施形態においては、各プログラムを主体として記述する。具体的には、例えば、ＭＰＵ１１が車載ＰＦの機能を利用して処理を行う場合、「車載ＰＦが処理を行う」というように記述する。また、サービスプロセス６１には、サーバ２４との間でデータをやりとりするアプリケーションが含まれている。

ここで、ＲＡＭ１３には、ASS DB（図２（ａ）参照）、起動条件ＤＢ（図２（ｂ）参照、Service Process Start Up Rule DB）、および終了条件ＤＢ（図２（ｃ）参照、Service Process Termination Rule DB）が所定の記録領域に格納されている。ASS DBには、図２（ａ）に示すように、データの名称（Situation）、データの型（種別）、およびデータの値がデータ毎に記録されている。

また、起動条件ＤＢには、図２（ｂ）に示すように、起動条件と、この起動条件で起動すべきサービスプロセス名とが対応付けて記録されている。図２（ｂ）に示す例では、温度が２０℃以上のときにエアコンＯＮに関するサービスプロセス６１を起動させる旨が記載されている。

さらに、終了条件ＤＢには、図２（ｃ）に示すように、終了条件と、この終了条件で終了すべきサービスプロセス名とが対応付けて記録されている。図２（ｃ）温度が１５度以下のときにエアコンＯＮに関するサービスプロセス６１を終了させる旨が記載されている。なお、各データベースには、多数のデータまたは条件を記録することができるように構成されている。

［本実施形態の処理］
このように構成された通信システム１において、通信ＥＣＵ１０が車両１００の外部または内部から受信した通信データをＲＡＭ１３に格納する際の処理について図３（ａ）を用いて説明する。図３（ａ）は通信ＥＣＵ１０のＭＰＵ１１（ＡＳＳ５２）が実行するデータ受信処理を示すフローチャートである。

データ受信処理は、イグニッションスイッチ（図示省略）等の車両の電源がＯＮ状態にされると開始され、その後、繰り返し実施される処理である。データ受信処理においては、まず、サービスプロセス６１等の処理に伴って、通信線３０や車両１００の外部から取得したデータの有無を判定する（Ｓ１１０：状況取得手段、要求取得手段）。

取得したデータが無ければ（Ｓ１１０：ＮＯ）、直ちにデータ受信処理を終了する。また、取得したデータがあれば（Ｓ１１０：ＹＥＳ）、取得したデータの種別が状況データであるか要求データであるかを判定する（Ｓ１２０：データ種別判定手段）。

ここで、本実施形態において、データの種別には、車両１００に対する要求や指示であるEvent（要求データ）と、車両１００がおかれた状況を表す車両状況の検出結果であるData（状況データ）との２つがある。また、Eventとしては、図３（ｂ）に示すように、ヘッドライトの点灯指示やエアコンＯＮの指示等がある。

取得したデータの種別がDataであれば（Ｓ１２０：ＹＥＳ）、ＡＳＳ５２がデータの名称（Situation）毎に最後（最新）のデータのみをＲＡＭ１３に保持する（Ｓ１３０：保存制御手段）。つまり、データの一部を間引きしてＲＡＭ１３に保持する。

また、データの種別がEventであれば（Ｓ１２０：ＮＯ）、ＡＳＳ５２が全てのデータをＲＡＭ１３に保持する（Ｓ１４０：保存制御手段）。Ｓ１３０またはＳ１４０の処理が終了すると、データ受信処理を終了する。

ここで、通信ＥＣＵ１０（ＣＩＥ６２）は、データ受信処理にて、Event（要求）のデータを受けると、データ受信処理とは別の処理にて、この要求に応じた処理を実施する。例えば、ベッドライト点灯の指示を受けた場合には、ヘッドライトの点灯を制御する他のＥＣＵ４２に対してヘッドライトの点灯を指示する。

また、Eventとして、新たなデータベース等を含むアプリケーション（サービスプロセス６１等）の追加または変更の要求を取得すると、データ受信処理とは別の処理にて、データベースを書き換える処理を行う（データベース書換手段）。この処理によって、サーバ２４の外部装置を利用して車両１００内の各データベース（特に、起動条件ＤＢ、終了条件ＤＢ）を書き換えることができるようにしている。

次に、ＲＡＭ１３に格納された各種データベースを利用してサービスプロセス６１を起動および終了させる処理について図４を用いて説明する。図４は、通信ＥＣＵ１０のＭＰＵ１１（ＣＩＥ６２）が実行するサービスプロセス作動処理を示すフローチャートである。

サービスプロセス作動処理は、イグニッションスイッチ（図示省略）等の車両の電源がＯＮ状態にされると開始され、その後、定期的（例えば１００ｍｓ毎）に起動される処理である。この処理においては、起動条件に合致したサービスプロセス６１を起動させる起動処理（Ｓ２００）と、終了条件に合致したサービスプロセス６１を終了させる終了処理（Ｓ３００）とを実施する。

なお、起動処理および終了処理において、Ｓ２１０〜Ｓ２３０およびＳ３１０〜Ｓ３３０の処理は、本発明でいう検索手段に相当する。
起動処理においては、まず、起動条件ＤＢを参照し、起動条件の１つを選択する（Ｓ２１０）。そして、ASS DBの内容を読み出し（Ｓ２２０）、ASS DBの内容のうち、選択した起動条件に合致しているものを検索する（Ｓ２３０）。

検索の結果、起動条件に合致しているものがあれば（Ｓ２３０：ＹＥＳ）、合致した起動条件に対応付けられたサービスプロセス６１の全てを起動させるよう指示し（Ｓ２４０：送信手段）、Ｓ２５０の処理に移行する。検索の結果、起動条件に合致しているものがなければ（Ｓ２３０：ＮＯ）、直ちにＳ２５０の処理に移行する。

Ｓ２５０の処理では、起動条件ＤＢのうちの全ての起動条件を選択したか否かを判定する（Ｓ２５０）。何れかの起動条件を選択していなければ（Ｓ２５０：ＮＯ）、起動条件ＤＢのうちの未選択の起動条件を選択し（Ｓ２６０）、Ｓ２２０以下の処理を繰り返す。

また、全ての起動条件を選択していれば（Ｓ２５０：ＮＯ）、起動処理を終了する。
次に、終了処理においては、まず、終了条件ＤＢを参照し、終了条件の１つを選択する（Ｓ３１０）。そして、ASS DBの内容を読み出し（Ｓ３２０）、ASS DBの内容のうち、選択した終了条件に合致しているものを検索する（Ｓ３３０）。

検索の結果、終了条件に合致しているものがあれば（Ｓ３３０：ＹＥＳ）、合致した終了条件に対応付けられたサービスプロセス６１の全てを終了させるよう指示し（Ｓ３４０：送信手段）、Ｓ３５０の処理に移行する。検索の結果、終了条件に合致しているものがなければ（Ｓ３３０：ＮＯ）、直ちにＳ３５０の処理に移行する。

Ｓ３５０の処理では、終了条件ＤＢのうちの全ての終了条件を選択したか否かを判定する（Ｓ３５０）。何れかの終了条件を選択していなければ（Ｓ３５０：ＮＯ）、終了条件ＤＢのうちの未選択の終了条件を選択し（Ｓ３６０）、Ｓ３２０以下の処理を繰り返す。

また、全ての終了条件を選択していれば（Ｓ３５０：ＮＯ）、終了処理を終了する。
［本実施形態による作用および効果］
以上のように詳述した通信システム１において、通信ＥＣＵ１０は、データ受信処理にて、車両１００がおかれた状況を表す車両状況の検出結果である状況データを取得する。そして、通信ＥＣＵ１０は、アプリケーション作動処理にて、状況データと対応してアプリケーション毎の作動条件または終了条件が記録された条件データベースを参照し、取得した状況データが一致する作動条件または終了条件に対応するアプリケーションを検索する。続いて、通信ＥＣＵ１０は、検索によりヒットしたアプリケーションを作動または終了させる指令を送信する。

このような通信システム１によれば、車両状況に応じてアプリケーション自体の起動および終了を自律的に管理することができる。また、各アプリケーションを待機状態にしておく必要がないため、消費電力を節約することができる。さらに、通信システム１によれば、車両１００の現在地に応じて異なる車両状況に対応したアプリケーションを作動させることができる。

なお、本発明において「車両状況」とは、車両１００に搭載されたセンサによって検出可能なパラメータや、車両１００の現在地によって特定されうる天気や路面状態等の車両環境を表す。

また、通信システム１において通信ＥＣＵ１０は、データ受信処理にて、通信システム１に対する要求である要求データを取得し、取得されたデータの種別が状況データであるか要求データであるかを判定する。そして、データの種別が要求データであると判定された場合に、この要求データをＲＡＭ１３に保存するとともに、データの種別が状況データであると判定された場合に、この提供データの少なくとも一部を間引きしてＲＡＭ１３に保存する。さらに、通信ＥＣＵ１０は、アプリケーション作動処理にて、ＲＡＭ１３に記録された状況データを読み出して、この状況データが一致する作動条件または終了条件に対応するアプリケーションを検索する。

このような通信システム１によれば、データを記録する際に、データの種別が要求データか状況データかを判定し、状況データについては少なくとも一部を間引きするので、ＲＡＭ１３の容量を節約することができる。一方で、要求データについては全てＲＡＭ１３に保存するので、要求を漏れなく処理することができる。なお、ＲＡＭ１３とＲＡＭ１３とは、同一の記録手段として構成されていてもよい。

さらに、通信システム１において通信ＥＣＵ１０は、データ受信処理にて、要求データとして、新たな条件データベースを含むアプリケーションの変更要求を取得し、データ書換手段がＲＡＭ１３に記録された要求データを読み出して、この要求データにアプリケーションの変更要求が含まれる場合に、条件データベースを書き換える。

このような通信システム１によれば、条件データベースを書き換える処理を自動的に行うことができる。
［その他の実施形態］
本発明の実施の形態は、上記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。例えば、上記実施形態においては、データ受信処理（図３）を車両１００側のみにて実施したが、サーバ２４等の他の装置が実施してもよい。

また、サービスプロセスマネージャ６０をサーバ２４に備えるようにし、サーバ２４が車両１００において起動または終了させるサービスプロセスを指示するようにしてもよい。この場合には、各データベース（ASS DB、起動条件ＤＢ、終了条件ＤＢ）をサーバ２４に持たせ、車両１００では、ASS DBのみを保持すればよい。

具体的な処理については、図５を用いて説明する。図５は変形例のサービスプロセス作動処理を示すフローチャート、およびサーバ２４に備えられたＭＰＵ（図示省略）が実行するサーバ処理を示すフローチャートである。なお、サーバ処理は、サーバ２４の電源が投入されると開始され、その後、繰り返し実施される処理である。

変形例のサービスプロセス作動処理では、ASS DBの中身に相当するデータ（サーバ２４に対する要求や車両状況を示すデータ）をサーバ２４に対して送信する（Ｓ４１０）。その後、タイムアウトとなる時間（例えば３０秒）以内にサーバ２４からのコマンドを受けたか否かを繰り返し判定する（Ｓ４２０，Ｓ４３０）。

タイムアウトになる前にサーバ２４からのコマンドを受ければ（Ｓ４２０：ＹＥＳ）、コマンドに基づく処理を実施し（Ｓ４４０）。サービスプロセス作動処理を終了する。一方、タイムアウトになれば（Ｓ４３０：ＮＯ）、直ちにサービスプロセス作動処理を終了する。

次にサーバ処理では、まず、外部からのデータ（特に、ASS DBの中身に相当するデータ）を受信したか否かを判定する（Ｓ５１０：状況取得手段）。この処理はデータを受信するまで繰り返され（Ｓ５１０：ＮＯ）、データを受信すると（Ｓ５１０：ＹＥＳ）、受信したデータをASS DBに記録する（Ｓ５２０）。

そして、前述の起動処理（Ｓ５３０）および終了処理（Ｓ５４０）を実施する。ただし、Ｓ２４０，Ｓ３４０の処理では、サービスプロセス６１を起動または終了させる処理は実施せずに、起動または終了させるサービスプロセス６１をサーバ２４内のメモリに記録させる。

続いて、サーバ２４内のメモリを参照し、起動または終了させるサービスプロセス６１について、起動コマンドまたは終了コマンドを車両１００に対して送信し（Ｓ５５０：送信手段）、サーバ処理を終了する。

このコマンドを受けた車両１００では、Ｓ４４０の処理にて、指示を受けたサービスプロセス６１を起動または終了させることになる。
このような変形例の通信システムによれば、車両状況に応じてアプリケーション自体の起動および終了を自律的に管理することができる。

また、変形例の通信システムによれば、車両１００の外部で車両１００において実行させるアプリケーションを選択することができる。よって、アプリケーションの作動条件や終了条件を変更する場合に、車両１００において設定を変更する必要がなく便利である。

また、１台の通信システムで複数の車両１００において実行させるアプリケーションを選択することもできる。この際には、車両１００を特定する周知の技術を利用しつつ、車両１００毎に状況データを取得し、車両１００毎にアプリケーションを作動または終了させる指令を送信すればよい。

１…通信システム、１０…通信ＥＣＵ、１１…ＭＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…外部通信Ｉ／Ｆ、１５…車内通信Ｉ／Ｆ、１６…アンテナ、２１…基地局、２２…アンテナ、２３…ネットワーク、２４…サーバ、３０…通信線、４１…センサ類、５１…車載ＰＦ、５２…ＡＳＳ、５４…ミドルウェア、５５…ＳＷＣ、６０…サービスプロセスマネージャ、６１…サービスプロセス、６２…ＣＩＥ、１００…車両。

Claims

車両に搭載された複数のアプリケーションの実行を制御するアプリケーション実行制御装置であって、
当該車両がおかれた状況を表す車両状況の検出結果である状況データを取得する状況取得手段と、
状況データと対応してアプリケーション毎の作動条件または終了条件が記録された条件データベースを参照し、前記取得した状況データが一致する作動条件または終了条件に対応するアプリケーションを検索する検索手段と、
前記検索によりヒットしたアプリケーションを作動または終了させる指令を送信する送信手段と、
当該アプリケーション実行制御装置に対する要求である要求データを取得する要求取得手段と、
前記各取得手段によって取得されたデータの種別が前記状況データであるか前記要求データであるかを判定するデータ種別判定手段と、
前記データ種別判定手段によってデータの種別が前記要求データであると判定された場合に、該要求データを第１記録手段に保存するとともに、データの種別が前記状況データであると判定された場合に、該状況データの少なくとも一部を間引きして第２記録手段に保存する保存制御手段と、
を備え、
前記検索手段は、前記第２記録手段に記録された状況データを読み出して、該状況データが一致する作動条件または終了条件に対応するアプリケーションを検索すること
を特徴とするアプリケーション実行制御装置。
請求項１に記載のアプリケーション実行制御装置において、
前記要求取得手段は、前記要求データとして、新たな条件データベースを含むアプリケーションの変更要求を取得するとともに、
前記第１記録手段に記録された要求データを読み出して、該要求データにアプリケーションの変更要求が含まれる場合に、前記条件データベースを書き換えるデータベース書換手段、
を備えたことを特徴とするアプリケーション実行制御装置。
請求項１または請求項２に記載のアプリケーション実行制御装置において、
当該アプリケーション実行制御装置は、前記各アプリケーションが搭載された車両の外部に配置されていること
を特徴とするアプリケーション実行制御装置。
コンピュータを、請求項１〜請求項３の何れかに記載のアプリケーション実行制御装置を構成する各手段として機能させるアプリケーション実行制御プログラム。