特開 2024-61957 車載装置、プログラム提供装置、車両用システム、機能部制御方法、プログラム保存方法及びプログラム提供方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024061957

(43)【公開日】2024-05-09

(54)【発明の名称】車載装置、プログラム提供装置、車両用システム、機能部制御方法、プログラム保存方法及びプログラム提供方法

(51)【国際特許分類】

   G06F 9/445 20180101AFI20240430BHJP

   B60R 16/02 20060101ALI20240430BHJP

【ＦＩ】

G06F9/445 130

B60R16/02 660T

【審査請求】未請求

【請求項の数】16

【出願形態】ＯＬ

(21)【出願番号】P 2022169622

(22)【出願日】2022-10-24

(71)【出願人】

【識別番号】000237592

【氏名又は名称】株式会社デンソーテン

(74)【代理人】

【識別番号】110001933

【氏名又は名称】弁理士法人 佐野特許事務所

(72)【発明者】

【氏名】奥原 誠

(72)【発明者】

【氏名】大築 ともえ

(72)【発明者】

【氏名】坂口 友理

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AA32

5B376AC13

5B376AC23

5B376FA11

5B376GA07

(57)【要約】

【課題】プログラムによる適正な車両制御を実現する。
【解決手段】複数の機能部を備えた車両に搭載される車載装置であって、１以上のアプリケーションプログラムを保存するメモリと、１以上のアプリケーションプログラムの何れかを実行することにより複数の機能部の何れかを制御するコントローラと、を備える。１以上のアプリケーションプログラムは、複数の機能部の何れかを制御対象とする対象アプリケーションプログラムを含む。コントローラは、制御対象に関して対象アプリケーションプログラムに付加された信頼レベルと、制御対象に対し車両にて定められた機能安全レベルと、に基づき、対象アプリケーションプログラムの実行可否、又は、対象アプリケーションプログラムの実行による制御対象の制御可否を決定する。
【選択図】図１１

【特許請求の範囲】

【請求項1】

複数の機能部を備えた車両に搭載される車載装置であって、
１以上のアプリケーションプログラムを保存するメモリと、
前記１以上のアプリケーションプログラムの何れかを実行することにより前記複数の機能部の何れかを制御するコントローラと、を備え、
前記１以上のアプリケーションプログラムは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムを含み、
前記コントローラは、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、前記対象アプリケーションプログラムの実行可否、又は、前記対象アプリケーションプログラムの実行による前記制御対象の制御可否を決定する
、車載装置。

【請求項2】

前記コントローラは、前記信頼レベル及び前記機能安全レベルが所定の許可条件を充足するとき、前記対象アプリケーションプログラムの実行を許可し、前記信頼レベル及び前記機能安全レベルが前記許可条件を逸脱するとき、前記対象アプリケーションプログラムの実行を禁止する
、請求項１に記載の車載装置。

【請求項3】

前記コントローラは、前記対象アプリケーションプログラムが前記メモリに保存された後、前記対象アプリケーションプログラムの実行を禁止すると決定した場合、前記対象アプリケーションプログラムを前記メモリから削除する
、請求項２に記載の車載装置。

【請求項4】

前記制御対象は、第１制御対象及び第２制御対象を含み、
前記信頼レベルは、前記第１制御対象に対する第１信頼レベルと前記第２制御対象に対する第２信頼レベルと、を含み、
前記コントローラは、前記第１信頼レベル、前記第２信頼レベル、前記第１制御対象に対し前記車両にて定められた第１機能安全レベル、及び、前記第２制御対象に対し前記車両にて定められた第２機能安全レベルに基づき、前記対象アプリケーションプログラムの実行による前記第１制御対象の制御可否と前記対象アプリケーションプログラムの実行による前記第２制御対象の制御可否を個別に決定する
、請求項１に記載の車載装置。

【請求項5】

前記コントローラは、前記第１信頼レベル及び前記第１機能安全レベルが所定の許可条件を充足する一方で、前記第２信頼レベル及び前記第２機能安全レベルが前記許可条件を逸脱するとき、前記対象アプリケーションプログラムの実行による前記第１制御対象の制御を許可する一方で前記対象アプリケーションプログラムの実行による前記第２制御対象の制御を禁止する
、請求項４に記載の車載装置。

【請求項6】

複数の機能部を備えた車両に搭載される車載装置であって、
１以上のアプリケーションプログラムを保存するメモリと、
前記１以上のアプリケーションプログラムの何れかを実行することにより前記複数の機能部の何れかを制御するコントローラと、
プログラム提供装置と通信を行う通信部と、を備え、
前記コントローラは、前記プログラム提供装置から受信したアプリケーションプログラムを前記メモリに保存させる保存処理を実行し、
前記コントローラは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムに対する前記保存処理の実行可否を、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、決定する
、車載装置。

【請求項7】

前記コントローラは、前記信頼レベル及び前記機能安全レベルが所定の許可条件を充足するとき、前記対象アプリケーションプログラムに対する前記保存処理を実行し、前記信頼レベル及び前記機能安全レベルが前記許可条件を逸脱するとき、前記対象アプリケーションプログラムに対する前記保存処理を禁止する
、請求項６に記載の車載装置。

【請求項8】

前記メモリは複数のプログラム記憶領域を有して、各プログラム記憶領域に１つのアプリケーションプログラムを保存可能に構成される
、請求項１～７の何れかに記載の車載装置。

【請求項9】

前記メモリは、各アプリケーションプログラムが使用するデータが格納されたデータテーブルを有する
、請求項１～７の何れかに記載の車載装置。

【請求項10】

請求項１～７の何れかの車載装置に対して前記対象アプリケーションプログラムを送信するプログラム提供装置であって、
前記車載装置に対して前記対象アプリケーションプログラムを送信する際、前記信頼レベルを前記対象アプリケーションプログラムに付加して前記車載装置に送信する
、プログラム提供装置。

【請求項11】

請求項１～７の何れかの車載装置と、
前記車載装置に対して前記対象アプリケーションプログラムを送信するプログラム提供装置と、を備えた車両用システムであって、
前記プログラム提供装置は、前記車載装置に対して前記対象アプリケーションプログラムを送信する際、前記信頼レベルを前記対象アプリケーションプログラムに付加して前記車載装置に送信する
、車両用システム。

【請求項12】

複数の機能部を備えた車両に搭載される車載装置と通信可能に構成されたプログラム提供装置であって、
複数のアプリケーションプログラムを保持するプログラムデータベースと、
前記車載装置と通信を行う通信部と、
前記通信部を用い、前記複数のアプリケーションプログラムの何れかを前記車載装置に送信するコントローラと、を備え、
前記車載装置において各アプリケーションプログラムが実行されることで各アプリケーションプログラムに対応する機能部が制御され、
前記複数のアプリケーションプログラムは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムを含み、
前記コントローラは、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、前記対象アプリケーションプログラムの前記車載装置への送信可否を決定する
、プログラム提供装置。

【請求項13】

前記コントローラは、前記信頼レベル及び前記機能安全レベルが所定の許可条件を充足するとき、前記対象アプリケーションプログラムを前記車載装置に送信し、前記信頼レベル及び前記機能安全レベルが前記許可条件を逸脱するとき、前記対象アプリケーションプログラムの前記車載装置への送信を禁止する
、請求項１２に記載のプログラム提供装置。

【請求項14】

複数の機能部を備えた車両にて用いられる機能部制御方法であって、
１以上のアプリケーションプログラムの何れかを実行することにより前記複数の機能部の何れかを制御する制御ステップと、
決定ステップと、を有し、
前記１以上のアプリケーションプログラムは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムを含み、
前記決定ステップでは、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、前記対象アプリケーションプログラムの実行可否、又は、前記対象アプリケーションプログラムの実行による前記制御対象の制御可否を決定する
、機能部制御方法。

【請求項15】

複数の機能部を備えた車両にて用いられるプログラム保存方法であって、
メモリに保存された１以上のアプリケーションプログラムの何れかを実行することにより前記複数の機能部の何れかを制御する制御ステップと、
プログラム提供装置から受信したアプリケーションプログラムを前記メモリに保存させる保存ステップと、
前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムに対する前記保存ステップの実行可否を決定する決定ステップと、を有し、
前記決定ステップでは、前記対象アプリケーションプログラムに対する前記保存ステップの実行可否を、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、決定する
、プログラム保存方法。

【請求項16】

複数の機能部を備えた車両に搭載される車載装置にプログラムを提供するためのプログラム提供方法であって、
複数のアプリケーションプログラムの何れかを前記車載装置に送信する送信ステップと、
決定ステップと、を有し、
前記車載装置において各アプリケーションプログラムが実行されることで各アプリケーションプログラムに対応する機能部が制御され、
前記複数のアプリケーションプログラムは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムを含み、
前記決定ステップでは、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、前記対象アプリケーションプログラムの前記車載装置への送信可否を決定する
、プログラム提供方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車載装置、プログラム提供装置、車両用システム、機能部制御方法、プログラム保存方法及びプログラム提供方法に関する。

【背景技術】

【0002】

車両には各種の機能部（エンジン、ワイパ、パワーウィンドウ、エアコンディショナ等）が設けられる。例えば、サーバ装置から機能部を制御するためのアプリケーションプログラムを車載装置にダウンロードするといったことが考えられる（例えば下記特許文献１参照）。車載装置にて当該アプリケーションプログラムを実行することで、快適な車内空間の提供、適正な運転支援又は適正な自動運転の提供等が可能となる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２０－１９４２６２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

但し、この種のアプリケーションプログラムの全てが妥当なものであるとは限らない。アプリケーションプログラムを利用するにあたり、適正な車両制御に向けた工夫が必要である。

【0005】

本発明は、適正な車両制御に寄与する車載装置、プログラム提供装置、車両用システム、機能部制御方法、プログラム保存方法及びプログラム提供方法を提供することを目的とする。

【課題を解決するための手段】

【0006】

本発明に係る車載装置は、複数の機能部を備えた車両に搭載される車載装置であって、１以上のアプリケーションプログラムを保存するメモリと、前記１以上のアプリケーションプログラムの何れかを実行することにより前記複数の機能部の何れかを制御するコントローラと、を備え、前記１以上のアプリケーションプログラムは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムを含み、前記コントローラは、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、前記対象アプリケーションプログラムの実行可否、又は、前記対象アプリケーションプログラムの実行による前記制御対象の制御可否を決定する。

【0007】

本発明に係る他の車載装置は、複数の機能部を備えた車両に搭載される車載装置であって、１以上のアプリケーションプログラムを保存するメモリと、前記１以上のアプリケーションプログラムの何れかを実行することにより前記複数の機能部の何れかを制御するコントローラと、プログラム提供装置と通信を行う通信部と、を備え、前記コントローラは、前記プログラム提供装置から受信したアプリケーションプログラムを前記メモリに保存させる保存処理を実行し、前記コントローラは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムに対する前記保存処理の実行可否を、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、決定する。

【0008】

本発明に係るプログラム提供装置は、複数の機能部を備えた車両に搭載される車載装置と通信可能に構成されたプログラム提供装置であって、複数のアプリケーションプログラムを保持するプログラムデータベースと、前記車載装置と通信を行う通信部と、前記通信部を用い、前記複数のアプリケーションプログラムの何れかを前記車載装置に送信するコントローラと、を備え、前記車載装置において各アプリケーションプログラムが実行されることで各アプリケーションプログラムに対応する機能部が制御され、前記複数のアプリケーションプログラムは、前記複数の機能部の何れかを制御対象とする対象アプリケーションプログラムを含み、前記コントローラは、前記制御対象に関して前記対象アプリケーションプログラムに付加された信頼レベルと、前記制御対象に対し前記車両にて定められた機能安全レベルと、に基づき、前記対象アプリケーションプログラムの前記車載装置への送信可否を決定する。

【発明の効果】

【0009】

本発明によれば、適正な車両制御に寄与する車載装置、プログラム提供装置、車両用システム、機能部制御方法、プログラム保存方法及びプログラム提供方法を提供することが可能となる。

【図面の簡単な説明】

【0010】

【図1】本発明の実施形態に係るシステムの全体構成図である。

【図2】本発明の実施形態に係り、データテーブル（掲示板）の構造図である。

【図3】本発明の実施形態に係り、データテーブル内のデータの取得方法及び配信方法に関わるフローチャートである。

【図4】本発明の実施形態に係り、或るアプリケーションプログラムの機能説明図である。

【図5】本発明の実施形態に属する第１実施例に係り、システムの全体構成図である。

【図6】本発明の実施形態に属する第１実施例に係り、機能安全テーブルの構造図である。

【図7】本発明の実施形態に属する第１実施例に係り、アプリケーションプログラムにアプリ情報テーブルが付加される様子を示す図（ａ）と、それらがアプリＤＢ又はコンテナに保存される様子を示す図（ｂ）、（ｃ）である。

【図8】本発明の実施形態に属する第１実施例に係り、アプリ情報テーブルの構造図である。

【図9】本発明の実施形態に属する第１実施例に係り、或るアプリケーションプログラム及び対応するアプリ情報テーブルを示す図である。

【図10】本発明の実施形態に属する第１実施例に係り、他のアプリケーションプログラム及び対応するアプリ情報テーブルを示す図である。

【図11】本発明の実施形態に属する第１実施例に係り、アプリのインストール動作に関わるシステムのフローチャートである。

【図12】本発明の実施形態に属する第１実施例に係り、更に他のアプリケーションプログラム及び対応するアプリ情報テーブルを示す図である。

【図13】本発明の実施形態に属する第１実施例に係り、アプリのインストール動作に関わるシステムの変形フローチャートである。

【図14】本発明の実施形態に属する第２実施例に係り、アプリのインストール動作に関わるシステムのフローチャートである。

【図15】本発明の実施形態に属する第２実施例に係り、アプリのインストール動作に関わるシステムの変形フローチャートである。

【図16】本発明の実施形態に属する第３実施例に係り、サーバ側フィルタ処理に関わるフローチャートである。

【図17】本発明の実施形態に属する第３実施例に係り、サーバ側フィルタ処理に関わる変形フローチャートである。

【図18】本発明の実施形態に属する第４実施例に係り、車両側制御部の機能ブロック図である。

【図19】本発明の実施形態に属する第４実施例に係り、サーバ側制御部の機能ブロック図である。

【発明を実施するための形態】

【0011】

以下、本発明の実施形態の例を、図面を参照して具体的に説明する。参照される各図において、同一の部分には同一の符号を付し、同一の部分に関する重複する説明を原則として省略する。尚、本明細書では、記述の簡略化上、情報、信号、物理量、機能部、回路、素子又は部品等を参照する記号又は符号を記すことによって、該記号又は符号に対応する情報、信号、物理量、機能部、回路、素子又は部品等の名称を省略又は略記することがある。例えば、後述の“１１”によって参照される駆動ＥＣＵは（図５参照）、駆動ＥＣＵ１１と表記されることもあるし、ＥＣＵ１１と略記されることもあり得るが、それらは全て同じものを指す。

【0012】

図１に本発明の実施形態に係るシステムＳＹＳの全体構成を示す。システムＳＹＳは、複数のノード１０と、セントラルゲートウェイ２０（以下、ＣＧＷ２０と称する）と、通信制御装置１００と、サーバ装置２００と、を備える。これらの内、複数のノード１０の全部又は一部と、ＣＧＷ２０と、通信制御装置１００とは、車両ＣＲに搭載される。但し、図１では全てのノード１０が車両ＣＲに搭載される様子が示されている。サーバ装置２００は車両ＣＲに外部に設置される。車両ＣＲは路面上を走行可能な自動車等である。

【0013】

通信制御装置１００及びサーバ装置２００は夫々に所定の通信網ＮＥＴに無線接続される。結果、通信制御装置１００及びサーバ装置２００に通信網ＮＥＴを介して互いに無線接続される。通信網ＮＥＴは、移動体通信網、インターネット、無線ＬＡＮ（Local Area Network）及び近距離無線通信回線の内、全部又は一部を含む。無線ＬＡＮは、例えばＷｉ－Ｆｉ（登録商標）に準拠したものであって良い。近距離無線通信回線は、例えばBluetooth（登録商標）に準拠したものであって良い。

【0014】

通信制御装置１００は、車両側制御部１１０、車両側メモリ１２０及び車両側通信部１３０を備える。車両側制御部１１０は、通信制御装置１００における各部位の動作の制御を行うコントローラである。車両側制御部１１０は、ＣＰＵ（Central Processing Unit）及びＧＰＵ（Graphics Processing Unit）等を含む演算処理部をハードウェア資源として備える。車両側メモリ１２０は、ＲＯＭ（Read only memory）又はフラッシュメモリ等の不揮発性メモリ、及び、ＲＡＭ（Random access memory）等の揮発性メモリを含む。車両側制御部１１０は車両側メモリ１２０内の任意のプログラムを実行できて良い。車両側メモリ１２０の全部又は一部は車両側制御部１１０に内蔵されたメモリであっても良い。

【0015】

車両側メモリ１２０は、掲示板と称することもできるデータテーブル１２１と、コンテナ部１２２と、を有する。尚、コンテナとは、アプリケーションプログラムをコンテナと呼ばれる動作環境にパッケージ化し、コンテナエンジン上で動かす仮想化技術のひとつである。コンテナ部１２２は複数のコンテナ１２２Ｃを有する。各コンテナ１２２Ｃはプログラム記憶領域である。各コンテナ１２２Ｃに１つのアプリケーションプログラムを保存することができる。コンテナ部１２２は不揮発性メモリにて構成されると良い。アプリケーションプログラムは、以下、アプリと略記されることがある。尚、任意のプログラムに関し、プログラムの保存、記憶、記録及び格納は互いに同義であると解して良い。同様に、任意のデータに関し、データの保存、記憶、記録及び格納は互いに同義であると解して良い。

【0016】

車両側通信部１３０は相手側機器との通信を実現する機能ブロックである。通信は双方向通信であって良いが、一方向通信であり得る。通信制御装置１００は車両側通信部１３０を用いて相手側機器との通信を行うが、以下の説明では、車両側通信部１３０の記述を省略することがある。

【0017】

通信制御装置１００にとっての相手側機器はサーバ装置２００を含む。通信制御装置１００は通信網ＮＥＴを介してサーバ装置２００と双方向通信を行う。

【0018】

通信制御装置１００にとっての相手側機器は車内ネットワークに接続された各ノード１０を含む。通信制御装置１００及びＣＧＷ２０は車両ＣＲ内に形成された車内ネットワークに接続される。複数のノード１０の内、全部又は一部も車内ネットワークに接続される。通信制御装置１００は車内ネットワーク及びＣＧＷ２０を介して各ノード１０と双方向通信を行う。但し、通信制御装置１００と幾つかのノード１０との通信は、一方向通信であり得る。車内ネットワークはＣＡＮ（Controller Area Network）及びＡＶＣＬＡＮ（Audio Visual Communication Local Area Network）を含む。

【0019】

ＣＧＷ２０は、通信制御装置１００と各ノード１０との間の通信を中継する。ＣＧＷ２０はセントラルゲートウェイ機能を持つＥＣＵ（Electronic Control Unit）にて形成される。

【0020】

尚、車両ＣＲ内に設けられる全ノード１０の内、一部のノード１０と、通信制御装置１００とは、ＣＧＷ２０を介することなく、車内ネットワーク又はＷｉ－Ｆｉ（登録商標）等を介して接続され且つ通信を行い得る。ＣＧＷ２０を介して通信制御装置１００と通信可能に接続されるノード１０は、セキュリティ性の高い各種機器であって、例えば車両の走行制御に関係する駆動系装置等が該当する。ユーザの持つスマートホン等の携帯機器がノード１０に該当する場合、当該携帯機器はＣＧＷ２０を介さずに通信制御装置１００と接続される場合が多い。ここで、ユーザとは車両ＣＲの運転手を指す。但し、運転手以外の車両ＣＲの搭乗者もユーザに該当して良い。本実施形態において、運転手とは、特に記述無き限り、車両ＣＲの運転手を指す。

【0021】

各ノード１０は、通信制御装置１００からの各種のデータ及び信号を受信して受信内容に基づく動作を行う、又は、通信制御装置１００に対して各種のデータ及び信号を送信する。以下に、ノード１０の例を挙げる。

【0022】

車両ＣＲの製造時に車両ＣＲに組み込まれる装置（以下、組み込み装置と称する）は、ノード１０の例に該当する。組み込み装置は、例えば、エンジン制御装置、操舵装置、ボディ制御装置、制動装置、パワーウィンドウ装置、エアコン装置、エアバッグ装置、シート制御装置、照明装置及びカメラ装置を含む。車両ＣＲの製造後、ユーザ又はディーラ等により車両ＣＲに対して追加設置される装置（以下、追加設置装置と称する）は、ノード１０の例に該当する。追加設置装置は、例えば、ナビゲーション装置、ドライブレコーダ装置、オーディオ装置及びビジュアル装置を含む。車両ＣＲの製造後、ユーザにより車両ＣＲ内に持ち込まれる装置（以下、持ち込み装置と称する）は、ノード１０の例に該当する。持ち込み装置は、例えば、スマートホンを含む携帯電話機、スマートウォッチ、ゲーム機器、タブレット及びパーソナルコンピュータを含む。

【0023】

車両センサはノード１０の例である。車両センサは、例えば、車両ＣＲの速度を検出する車速センサ、車室内の温度を検出する温度センサ、車室内の湿度を検出する湿度センサ、車室内のＣＯ_２濃度を検出するＣＯ_２センサ、車両ＣＲの位置（現在地）を検出するＧＰＳ位置センサ、及び、車両ＣＲの現在地における降雨を検出する降雨センサを含む。車両センサは一般的に組み込み装置に該当する。車室は車両ＣＲの車室を指す。ＧＰＳは“Global Positioning System”の略称である。

【0024】

バイタルセンサはノード１０の例である。バイタルセンサはユーザ（主として運転手）の生体情報を取得するセンサである。ユーザの生体情報は、例えば、ユーザの心拍数（又は脈拍数）、ユーザの脳波及びユーザの発汗量を含む。バイタルセンサは持ち込み装置に属することが多い。

【0025】

尚、上述の各装置の組み込み装置、追加設置装置及び追加設置装置への分類は例示であり、様々に変更され得る。例えば、ナビゲーション装置は組み込み装置に属する場合があるし、カメラ装置は追加設置装置に属する場合がある。また、幾つかのノード１０は車両ＣＲの車外に配置される場合もある。例えば、車両ＣＲと異なる車両に設置される装置、及び、信号機等のインフラ機器も、通信制御装置１００との通信が可能である限り、何れかのノード１０となり得る。

【0026】

サーバ装置２００は、サーバ側制御部２１０、サーバ側メモリ２２０及びサーバ側通信部２３０を備える。サーバ側メモリ２２０は、サーバ装置２００とは別に設けられた記録装置であって且つサーバ装置２００によりアクセス可能な記録装置を含んでいても良い。サーバ側制御部２１０は、サーバ装置２００における各部位の動作の制御を行うコントローラである。サーバ側制御部２１０は、ＣＰＵ及びＧＰＵ等を含む演算処理部をハードウェア資源として備える。サーバ側メモリ２２０は、ＲＯＭ又はフラッシュメモリ等の不揮発性メモリ、及び、ＲＡＭ等の揮発性メモリを含む。サーバ側制御部２１０はサーバ側メモリ２２０内の任意のプログラムを実行できて良い。サーバ側メモリ２２０の全部又は一部はサーバ側制御部２１０に内蔵されたメモリであっても良い。サーバ装置２００は通信網ＮＥＴに接続された１以上のコンピュータ装置にて構成されて良い。クラウドコンピューティングを利用してサーバ装置２００が構成されても良い。

【0027】

サーバ側メモリ２２０は複数のアプリが格納されたアプリＤＢ２２１（プログラムデータベース）を有する。アプリＤＢ２２１に格納された各アプリは、車両側制御部１１０にて実行されることを前提に設計されたプログラムである。

【0028】

サーバ側通信部２３０は相手側機器との通信を実現する機能ブロックである。サーバ装置２００はサーバ側通信部２３０を用いて相手側機器との通信を行うが、以下の説明では、サーバ側通信部２３０の記述を省略することがある。サーバ装置２００にとっての相手側機器は通信制御装置１００を含む。サーバ装置２００は通信網ＮＥＴを介して通信制御装置１００と双方向通信を行う。

【0029】

尚、サーバ装置２００は複数の相手側機器と通信を行うことができ、その複数の相手側機器の１つが本実施形態で注目する通信制御装置１００である。サーバ装置２００及び通信制御装置１００間で通信を行う際、通信信号に通信制御装置１００の識別情報を含めることなどにより、サーバ装置２００は、通信制御装置１００を他の装置と区別しつつ、通信制御装置１００との通信を実現する。

【0030】

［データの送受信について］
通信制御装置１００は、例えばＰｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ方式によって、任意のデータを、当該データを必要とするノード１０に配信できる。この際、通信制御装置１００は、例えばＭＱＴＴ（Message Queuing Telemetry Transport）を用いて、任意のデータを、当該データを必要とするノード１０に配信する。尚、本明細書において用語“配信”と用語“送信”は互いに同義であり、それらを読み替え可能である。

【0031】

図２にデータテーブル１２１の構造を示す。データテーブル１２１において複数の項目が設定され、項目ごとに当該項目の内容を示すデータ（以下、内容データと称され得る）がデータテーブル１２１に格納される。項目はＴＯＰＩＣと称される。ここでは、データテーブル１２１において、ＴＯＰＩＣ６１１～６１７を含む複数のＴＯＰＩＣが設定されているものとする。

【0032】

ＴＯＰＩＣ６１１は室温である。室温は車室内の温度を指す。ＴＯＰＩＣ６１１に対する内容データ６２１は、第１のノード１０である温度センサにて検出された温度を表す。
ＴＯＰＩＣ６１２は心拍数である。ＴＯＰＩＣ６１２における心拍数は運転手の心拍数を表す。ＴＯＰＩＣ６１２に対する内容データ６２２は、第２のノード１０であるバイタルセンサにて検出された運転手の心拍数を表す。心拍数は脈拍数であっても良い。心拍数のＴＯＰＩＣと脈拍数のＴＯＰＩＣが別々にデータテーブル１２１に設定されても良い。
ＴＯＰＩＣ６１３は最適温度である。ＴＯＰＩＣ６１３に対する内容データ６２３は、室温の最適値を示す。
ＴＯＰＩＣ６１４は最適風量である。ＴＯＰＩＣ６１４に対する内容データ６２４は、風量の最適値を示す。後述のエアコンディショナ３５（図５参照）の吹き出し口から車室内に向けて風が吹き出す風の強さが風量である。
ＴＯＰＩＣ６１５は車速である。車速とは車両ＣＲの速度を表す。ＴＯＰＩＣ６１５に対する内容データ６２５は、第３のノード１０である車速センサにて検出された車両ＣＲの速度を表す。
ＴＯＰＩＣ６１６は外気温である。外気温とは、車両ＣＲの現在地における車両ＣＲの外気の気温を指す。ＴＯＰＩＣ６１６に対する内容データ６２６は、第４のノード１０である外気温センサにて検出された外気温を表す。第４のノード１０は、外気温の情報を通信網ＮＥＴを介して取得可能なスマートホン等でも良い。
ＴＯＰＩＣ６１７は車室内のＣＯ_２濃度である。ＴＯＰＩＣ６１７に対する内容データ６２７は、第５のノード１０であるＣＯ_２センサにて検出されたＣＯ_２濃度（車室内のＣＯ_２濃度）を表す。

【0033】

通信制御装置１００はＭＱＴＴにおけるＢｒｏｋｅｒとして機能して良い。図３に、データテーブル１２１内のデータの取得方法及び配信方法に関わるフローチャートを示す。ノード１０の内、データを通信制御装置１００に対して出力するノード１０を特に出力元ノードと称する。ノード１０の内、通信制御装置１００からデータの配信を受けるノード１０を特に要求元ノードと称する。

【0034】

ステップＳ１において、車両側制御部１１０は出力元ノード１０よりデータを付加情報と共に取得する。付加情報は、取得されるデータが、何れのＴＯＰＩＣについてのデータであるかを指し示す。ステップＳ１の後、ステップＳ２に進む。ステップＳ２において、車両側制御部１１０は、ステップＳ１にて取得されたデータを所定の標準データ形式のデータに変換する。この変換により、ステップＳ１にて取得されたデータが、出力元ノード１０以外のノード１０によっても使用できるデータに変換される。続くステップＳ３において、車両側制御部１１０は、ステップＳ２での変換後のデータを、対応するＴＯＰＩＣに対応付けてデータテーブル１２１に格納する。

【0035】

要求元ノード１０は自身が起動すると、配信要求信号を通信制御装置１００に送信する。配信要求信号において、要求元ノード１０が必要とするＴＯＰＩＣが指定される。ステップＳ３に続くステップＳ４において、車両側制御部１１０は、配信要求信号に基づいて、要求元ノード１０が必要とするＴＯＰＩＣのデータをデータテーブル１２１から抽出し、抽出したデータを要求元ノード１０に配信する。

【0036】

尚、幾つかのＴＯＰＩＣのデータは、何れかのコンテナ１２２Ｃに格納されたアプリが車両側制御部１１０にて実行されることで生成され得る。また、幾つかのＴＯＰＩＣのデータは、取得又は生成段階において標準データ形式を有していても良く、この場合、上述の変換は不要である。

【0037】

[アプリの基本機能について］
コンテナ部１２２又はアプリＤＢ２２１に格納される各アプリには、必要ＴＯＰＩＣ、出力ＴＯＰＩＣ及び出力ノードが設定される。今、注目された任意の１つのアプリを注目アプリと称する。或る注目アプリに対する必要ＴＯＰＩＣは、注目アプリが必要とするＴＯＰＩＣである。或る注目アプリに対する出力ＴＯＰＩＣは、注目アプリが生成するデータのＴＯＰＩＣである。即ち、注目アプリは必要ＴＯＰＩＣのデータに基づき出力ＴＯＰＩＣのデータを生成する。注目アプリを実行する車両側制御部１１０は、必要ＴＯＰＩＣのデータをデータテーブル１２１から取得でき、生成した出力ＴＯＰＩＣのデータをデータテーブル１２１に格納できる。注目アプリに対する出力ノードは、注目アプリが生成したデータ（出力ＴＯＰＩＣのデータ）を、配信すべきノードを示す。注目アプリを実行する車両側制御部１１０は、注目アプリに従って生成した出力ＴＯＰＩＣのデータを出力ノードに対して配信できる。

【0038】

例として、図４に示すアプリ６４０の機能を説明する。アプリ６４０が何れかのコンテナ１２２Ｃに格納され、車両側制御部１１０により実行されたとする。アプリ６４０における必要ＴＯＰＩＣは室温及び心拍数であり、アプリ６４０における出力ＴＯＰＩＣは最適温度である。即ち、アプリ６４０は室温及び心拍数に基づき最適温度を導出するアプリである。アプリ６４０が車両側制御部１１０にて実行されるとき、車両側制御部１１０は、ＴＯＰＩＣ６１１及び６１２のデータ６２１及び６２２をデータテーブル１２１から取得し、データ６２１及び６２２に基づき最適温度を導出する。その後、車両側制御部１１０は、導出した最適温度をＴＯＰＩＣ６１３のデータ６２３としてデータテーブル１２１に格納する。この際、アプリ６４０にて導出された最適温度のデータが標準データ形式を有していなければ、当該データを標準データ形式のデータに変換してからデータテーブル１２１に格納する。更に、車両側制御部１１０は、最適温度の情報を必要とするノード１０（後述のエアコンＥＣＵ１３）に対してデータテーブル１２１内のデータ６２３を配信する。最適温度の情報を必要とするノード１０（後述のエアコンＥＣＵ１３）は、室温が配信にて受けた最適温度に向かうよう又は最適温度に保たれるよう、実際の室温を制御する。このように、各アプリ（例えばアプリ６４０）が使用するデータを格納したデータテーブル１２１を用意しておくことで、車両ＣＲへのアプリの適用が容易となる（例えばアプリの開発が容易となる、或いは、高機能のアプリを作成しやすくなる）。

【0039】

注目アプリに対する必要ＴＯＰＩＣ、出力ＴＯＰＩＣ及び出力ノードの設定情報は、注目アプリに付加された情報であっても良いし、注目アプリとは別にコンテナ部１２２又はアプリＤＢ２２１に保存されていても良い。尚、アプリによっては出力ＴＯＰＩＣが設定されないことがあっても良い。この際、アプリによっては対象のノード１０に信号又は情報（例えば、対象のノード１０の制御信号又は対象のノード１０が処理にて使用する情報）を直接出力することがある。

【0040】

サーバ装置２００は、ユーザからの要求に応じて又はユーザからの要求に依らず、アプリＤＢ２２１内の幾つかのアプリを通信制御装置１００に送信できる。アプリの利用により、快適な車内空間の提供、適正な運転支援又は適正な自動運転の提供等が可能となる。但し、これらのアプリは、自動車メーカ及び車載機器メーカの何れとも異なるアプリメーカによって作成されることも考えられ、また色々な車種の車両にて使用される。このため、アプリの機能によっては又は車種によっては、アプリの期待される性能が充分に発揮されず、機能又は性能向上の期待の観点又は安心感の提供の観点等から懸念が残る。

【0041】

このような懸念の解消に有益な技術、又は、それに関連する技術を、以下の複数の実施例の中で説明する。本実施形態にて上述した事項は、特に記述無き限り且つ矛盾無き限り、以下の各実施例に適用される。各実施例において、上述の事項と矛盾する事項がある場合には、各実施例での記載が優先されて良い。また矛盾無き限り、以下に示す複数の実施例の内、任意の実施例に記載した事項を、他の任意の実施例に適用することもできる（即ち複数の実施例の内の任意の２以上の実施例を組み合わせることも可能である）。

【0042】

＜＜第１実施例＞＞
システムＳＹＳの第１実施例を説明する。車両ＣＲは第１～第Ｎ機能部を備える。Ｎは２以上の任意の整数を表す。車両ＣＲに備えられる各アクチュエータは機能部の例である。

【0043】

図５に第１実施例に係るシステムＳＹＳの全体構成を示す。尚、図５では、図示の便宜上、車両ＣＲは示されていない。第１実施例では、複数のノード１０の内、４つのノード１０に相当する駆動ＥＣＵ１１、ボディＥＣＵ１２、エアコンＥＣＵ１３及びシートＥＣＵ１４に注目する（後述の第２及び第３実施例についても同様）。各ＥＣＵ１１～１４は車内ネットワーク及びＣＧＷ２０に接続される。このため、通信制御装置１００は車内ネットワーク及びＣＧＷ２０を介してＥＣＵ１１～１４と双方向通信を行う。機能部３１～３７の夫々はアクチュエータを含み、これら以外にも多数の機能部が車両ＣＲに搭載される。機能部３１、３２、３３、３４、３５、３６、３７は、夫々、エンジン、ワイパ、パワーウィンドウ、ファンモータ、エアコンディショナ、シート位置調整用のアクチュエータ、シート角度調整用のアクチュエータである。

【0044】

駆動ＥＣＵ１１は、エンジン３１に対して第１駆動信号を供給することでエンジン３１を駆動させる。エンジン３１が駆動することで車両ＣＲを走行させるための駆動力が発生する。第１駆動信号にてエンジン３１の駆動条件が指定され、エンジン３１は第１駆動信号にて指定された駆動条件で駆動する。エンジン３１は内燃機関又は電動機にて構成される、又は、内燃機関及び電動機の組み合わせにて構成される。駆動ＥＣＵ１１は、基本的には、車両ＣＲに設けられたアクセルペダルに対する運転手の踏み込み量に基づき第１駆動信号を生成して良い。

【0045】

ボディＥＣＵ１２は、ワイパ３２に対して第２駆動信号を供給することでワイパ３２を駆動させる。詳細には、ワイパ３２はワイパ用のモータを含み、ワイパ用のモータが第２駆動信号に基づき駆動することでワイパ３２が作動する。ワイパ用のモータが駆動することで、ワイパ３２を構成する清掃用部品が車両ＣＲのフロントガラス上の水滴等をふき取る動作を行う。第２駆動信号にてワイパ３２の駆動条件が指定され、ワイパ３２は第２駆動信号にて指定された駆動条件で駆動する。

【0046】

ボディＥＣＵ１２は、パワーウィンドウ３３に対して第３駆動信号を供給することでパワーウィンドウ３３を駆動させる。詳細には、パワーウィンドウ３３はパワーウィンドウ用のモータを含み、パワーウィンドウ用のモータが第３駆動信号に基づき駆動することでパワーウィンドウ３３が作動する。パワーウィンドウ用のモータが駆動することで、車両ＣＲのドアに設けられた窓であって且つパワーウィンドウ３３を構成する窓の状態が開状態及び閉状態間で変化する。第３駆動信号にてパワーウィンドウ３３の駆動条件が指定され、パワーウィンドウ３３は第３駆動信号にて指定された駆動条件で駆動する。ボディＥＣＵ１２は、基本的には、車両ＣＲに設けられた所定の操作部材に対する運転手の操作内容に基づき第２及び第３駆動信号を生成して良い。

【0047】

エアコンＥＣＵ１３は、ファンモータ３４に対して第４駆動信号を供給することでファンモータ３４を駆動させる。ファンモータ３４が駆動することで、車室内に設置されたエアコンディショナ３５の吹き出し口から車室内に向けて風が吹き出す。吹き出す風の強さが風量である。第４駆動信号にてファンモータ３４の駆動条件（従って風量）が指定され、ファンモータ３４は第４駆動信号にて指定された駆動条件で駆動する。エアコンＥＣＵ１３は第４駆動信号を変化させることで風量を変化させることができる。

【0048】

エアコンＥＣＵ１３は、エアコンディショナ３５に対して第５駆動信号を供給することでエアコンディショナ３５を駆動させる。エアコンディショナ３５が駆動することで車室内の温度が調整される。第５駆動信号にてエアコンディショナ３５の駆動条件が指定され、エアコンディショナ３５は第５駆動信号にて指定された駆動条件で駆動する。エアコンＥＣＵ１３は第５駆動信号を変化させることで車室内の温度の調整度合いを変化させ、以って車室内の温度を変化させることができる。エアコンＥＣＵ１３は、基本的には、車両ＣＲに設けられた所定の操作部材に対する運転手の操作内容に基づき第４及び第５駆動信号を生成して良い。尚、ファンモータ３４はエアコンディショナ３５の構成要素の一部であると解しても良い。

【0049】

シートＥＣＵ１４は、シート位置調整用のアクチュエータ３６に対して第６駆動信号を供給することでアクチュエータ３６を駆動させる。アクチュエータ３６が駆動することで車両ＣＲに設けられた運手席の位置が変化する。第６駆動信号にてアクチュエータ３６の駆動条件（従って運手席の位置）が指定され、アクチュエータ３６は第６駆動信号にて指定された駆動条件で駆動する。

【0050】

シートＥＣＵ１４は、シート角度調整用のアクチュエータ３７に対して第７駆動信号を供給することでアクチュエータ３７を駆動させる。アクチュエータ３７が駆動することで車両ＣＲに設けられた運手席の角度（リクライニング角度）が変化する。第７駆動信号にてアクチュエータ３７の駆動条件（従って運手席の角度）が指定され、アクチュエータ３７は第７駆動信号にて指定された駆動条件で駆動する。シートＥＣＵ１４は、基本的には、車両ＣＲに設けられた所定の操作部材に対する運転手の操作内容に基づき第６及び第７駆動信号を生成して良い。

【0051】

図６に機能安全テーブルＴＢＬ_Ｑの構造を示す。機能安全テーブルＴＢＬ_Ｑは車両側メモリ１２０又はＣＧＷ２０を構成するＥＣＵ内のメモリ（不図示）に予め格納されている。車両側制御部１１０は、任意のタイミングにおいて、車両側メモリ１２０又はＣＧＷ２０を構成するＥＣＵ内のメモリから機能安全テーブルＴＢＬ_Ｑ内のデータを読み出して参照することができる。

【0052】

機能安全テーブルＴＢＬ_Ｑには、車両ＣＲに設けられた機能部ごとにデータセットＤＳ_Ｑが格納される。任意の注目された１つの機能部を注目機能部と称する。注目機能部のデータセットＤＳ_Ｑは、注目機能部に対して固有に割り当てられた識別情報ＩＮＤＥＸ_Ｑを含む。ここでは、識別情報ＩＮＤＥＸ_Ｑは整数値にて表現されるものとし、機能部３１、３２、３３、３４、３５、３６、３７に割り当てられた識別情報ＩＮＤＥＸ_Ｑは、夫々、“１”、“２”、“３”、“４”、“５”、“６”、“７”であるとする。

【0053】

注目機能部のデータセットＤＳ_Ｑは、注目機能部が何れの機能部であるかを示す機能部情報と、注目機能部を駆動するＥＣＵが何れのＥＣＵであるかを示すＥＣＵ情報と、を更に含む。

【0054】

故に、“ＩＮＤＥＸ_Ｑ＝１”に対応する機能部情報及びＥＣＵ情報は夫々エンジン３１及び駆動ＥＣＵ１１を示す。“ＩＮＤＥＸ_Ｑ＝２”に対応する機能部情報及びＥＣＵ情報は夫々ワイパ３２及びボディＥＣＵ１２を示す。“ＩＮＤＥＸ_Ｑ＝３”に対応する機能部情報及びＥＣＵ情報は夫々パワーウィンドウ３３及びボディＥＣＵ１２を示す。“ＩＮＤＥＸ_Ｑ＝４”に対応する機能部情報及びＥＣＵ情報は夫々ファンモータ３４及びエアコンＥＣＵ１３を示す。“ＩＮＤＥＸ_Ｑ＝５”に対応する機能部情報及びＥＣＵ情報は夫々エアコンディショナ３５及びエアコンＥＣＵ１３を示す。ＩＮＤＥＸ_Ｑ＝６”に対応する機能部情報及びＥＣＵ情報は夫々アクチュエータ３６及びシートＥＣＵ１４を示す。ＩＮＤＥＸ_Ｑ＝７”に対応する機能部情報及びＥＣＵ情報は夫々アクチュエータ３７及びシートＥＣＵ１４を示す。

【0055】

注目機能部のデータセットＤＳ_Ｑは、注目機能部の機能安全レベルを更に含む。各機能部の機能安全レベルは所定規格により定められる。ここでは、各機能部の機能安全レベルは、ＩＳＯ２６２６２で定義されたＡＳＩＬ（Automotive Safety Integrity Level）であるとする。

【0056】

注目機能部を制御するソフトウェア又はハードウェアの機能不全により引き起こされるハザード（車両ＣＲのハザード）の程度によって、注目機能部の機能安全レベルは、Ａ、Ｂ、Ｃ及びＤの４段階のレベルに区分される。機能安全レベルは、Ａ、Ｂ、Ｃ及びＤの区別によって、レベルの高低が定義される。Ａ、Ｂ、Ｃ及びＤの機能安全レベルの内、Ａの機能安全レベルが最も低く、Ｂの機能安全レベルはＡの機能安全レベルよりも高く、Ｃの機能安全レベルはＢの機能安全レベルよりも高く、Ｄの機能安全レベルはＣの機能安全レベルよりも高い。

【0057】

機能部３１、３２、３３、３４、３５、３６、３７に対して設定された機能安全レベルは、夫々、Ｃ、Ｂ、Ｂ、Ａ、Ａ、Ｂ、Ｂである。ここでは、１つのＥＣＵに対応する複数の機能部に対し共通の機能安全レベルが設定されている。即ち例えば、ボディＥＣＵ１２に対応する２つの機能部（ワイパ３２及びパワーウィンドウ３３）に対し共通の機能安全レベル“Ｂ”が設定されている。しかしながら、１つのＥＣＵに対応する複数の機能部に対し互いに異なる機能安全レベルが設定され得る。

【0058】

一方、システムＳＹＳで取り扱われる各アプリにはアプリ情報テーブルが付加される。図７（ａ）に、任意の１つのアプリであるアプリ７００に対してアプリ情報テーブルＴＢＬ_Ｐが付加される様子を示す。上述のアプリ６４０（図４参照）はアプリ７００の一例である。アプリ７００がアプリＤＢ２２１に保存される際、図７（ｂ）に示す如く、アプリ７００とアプリ情報テーブルＴＢＬ_Ｐとが互いに対応付けられた状態でアプリＤＢ２２１に格納される。アプリ７００が１つのコンテナ１２２Ｃに保存される際、図７（ｃ）に示す如く、アプリ７００とアプリ情報テーブルＴＢＬ_Ｐとが互いに対応付けられた状態で１つのコンテナ１２２Ｃに格納される。

【0059】

図８にアプリ情報テーブルＴＢＬ_Ｐの構造を示す。アプリ７００において、車両ＣＲに設けられた第１～第Ｎ機能部の内、何れか１以上の機能部が制御対象に設定される。アプリ７００が車両側制御部１１０により実行されたとき、車両側制御部１１０はアプリ７００に従って制御対象を制御する（但し、制御がマスクされることもある；詳細は後述）。アプリ７００においてＭ個の機能部が第１～第Ｍ制御対象として設定されるものとする。Ｍは１以上の任意の整数であるが、“Ｍ≧２”であることを想定してアプリ情報テーブルＴＢＬ_Ｐの構造を説明する。

【0060】

アプリ情報テーブルＴＢＬ_Ｐには、アプリ７００の制御対象ごとにデータセットＤＳ_Ｐが格納される。第ｉ制御対象のデータセットＤＳ_Ｐは、第ｉ制御対象に対して固有に割り当てられた識別情報ＩＮＤＥＸ_Ｐを含む。識別情報ＩＮＤＥＸ_Ｐは整数値にて表現されるものとし、第ｉ制御対象に割り当てられた識別情報ＩＮＤＥＸ_Ｐは“ｉ”であるとする。ｉは任意の整数を表す。

【0061】

第ｉ制御対象のデータセットＤＳ_Ｐは、第ｉ制御対象を特定する情報である制御対象情報と、アプリ７００が第ｉ制御対象を制御することで実現されるサービスの内容を示すサービス情報と、を更に含む。尚、図８においてサービス情報の詳細は図示されていない。

【0062】

第ｉ制御対象を特定する情報は、第ｉ制御対象が何れの機能部であるかを示す情報である。故に例えば、第１制御対象がワイパ３２であれば、“ＩＮＤＥＸ_Ｐ＝１”のデータセットＤＳ_Ｐ中の制御対象情報はワイパ３２を指し示す。同様に例えば、第２制御対象がパワーウィンドウ３３であれば、“ＩＮＤＥＸ_Ｐ＝２”のデータセットＤＳ_Ｐ中の制御対象情報はパワーウィンドウ３３を指し示す。

【0063】

第ｉ制御対象のデータセットＤＳ_Ｐは、アプリ７００にて第ｉ制御対象が制御されるときの制御の信頼度を示す信頼レベルを更に含む。尚、図８において信頼レベルの詳細は図示されていない。信頼レベルはＡ、Ｂ、Ｃ及びＤの４段階のレベルにて規定される。信頼レベルは、Ａ、Ｂ、Ｃ及びＤの区別によって、レベルの高低が定義される。Ａ、Ｂ、Ｃ及びＤの信頼レベルの内、Ａの信頼レベルが最も低く、Ｂの信頼レベルはＡの信頼レベルよりも高く、Ｃの信頼レベルはＢの信頼レベルよりも高く、Ｄの信頼レベルはＣの信頼レベルよりも高い。

【0064】

図９（ａ）に示すアプリ７１０はアプリ７００の例である。アプリ７１０に付加されるアプリ情報テーブルＴＢＬ_Ｐはアプリ情報テーブルＴＢＬ_７１０である。図９（ｂ）にアプリ情報テーブルＴＢＬ_７１０の構造を示す。アプリ７１０において計３個の機能部が第１～第３制御対象として設定される。即ち、アプリ７１０において“Ｍ＝３”である。

【0065】

アプリ情報テーブルＴＢＬ_７１０において、“１”、“２”、“３”の識別情報ＩＮＤＥＸ_Ｐに対応付けられた制御対象は、夫々、ファンモータ３４、エアコンディショナ３５、パワーウィンドウ３３である。アプリ情報テーブルＴＢＬ_７１０において、“１”の識別情報ＩＮＤＥＸ_Ｐに対応付けられたサービス情報及び“２”の識別情報ＩＮＤＥＸ_Ｐに対応付けられたサービス情報は共に室内快適調整を示す。アプリ情報テーブルＴＢＬ_７１０において、“３”の識別情報ＩＮＤＥＸ_Ｐに対応付けられたサービス情報は自動窓開閉である。アプリ情報テーブルＴＢＬ_７１０において、“１”、“２”及び“３”の識別情報ＩＮＤＥＸ_Ｐに対応付けられた信頼レベルは全て“Ｂ”である。

【0066】

アプリ７１０が何れかのコンテナ１２２Ｃに格納され且つ車両側制御部１１０により実行されたとき、車両側制御部１１０はアプリ７１０に従って室内快適調整のサービス及び自動窓開閉のサービスを実現できる。

【0067】

室内快適調整のサービスについて説明する。室内快適調整のサービスにおける制御対象は“ＩＮＤＥＸ_Ｐ＝１”に対応するファンモータ３４及び“ＩＮＤＥＸ_Ｐ＝２”に対応するエアコンコンディショナ３５である。室内快適調整のサービスについて、アプリ７１０の必要ＴＯＰＩＣは室温及び心拍数であり、アプリ７１０の出力ＴＯＰＩＣは最適風量及び最適温度である。

【0068】

アプリ７１０の実行により室内快適調整のサービスが実現される際、車両側制御部１１０はアプリ７１０に従って、室温及び心拍数に基づき最適風量及び最適温度を導出する。具体的には、車両側制御部１１０は、データ６２１及び６２２をデータテーブル１２１から取得し（図２参照）、データ６２１及び６２２に基づき最適風量及び最適温度を導出する。その後、車両側制御部１１０は、導出した最適風量及び最適温度を夫々データ６２４及び６２３としてデータテーブル１２１に格納する。この際、必要に応じて上述のデータ形式の変換が行われる。更に、車両側制御部１１０は、最適風量及び最適温度の情報を必要とするエアコンＥＣＵ１３に対してデータテーブル１２１内のデータ６２４及び６２３を配信する。

【0069】

エアコンＥＣＵ１３は、ファンモータ３４の駆動による風量が、受信したデータ６２４にて示される最適風量となるよう、受信したデータ６２４に基づく第４駆動信号をファンモータ３４に供給する。エアコンＥＣＵ１３は、実際の室温が、受信したデータ６２３にて示される最適温度と一致するよう又は最適温度に向かうよう、受信したデータ６２３に基づく第５駆動信号をエアコンコンディショナ３５に供給する。このように室内快適調整のサービスにおいて、車両側制御部１１０はアプリ７１０に従ってエアコンＥＣＵ１３に対し必要な情報（データ６２４及び６２３）を配信し、これによってファンモータ３４及びエアコンコンディショナ３５を制御する。

【0070】

自動窓開閉のサービスについて説明する。自動窓開閉のサービスにおける制御対象は“ＩＮＤＥＸ_Ｐ＝３”に対応するパワーウィンドウ３３である。自動窓開閉のサービスについて、アプリ７１０の必要ＴＯＰＩＣは室温、外気温及びＣＯ_２濃度である。

【0071】

アプリ７１０の実行により自動窓開閉のサービスが実現される際、車両側制御部１１０はアプリ７１０に従って、室温、外気温及びＣＯ_２濃度に基づきパワーウィンドウ３３を構成する窓の適正状態を導出する。具体的には、車両側制御部１１０は、データ６２１、６２６及び６２７をデータテーブル１２１から取得し（図２参照）、データ６２１、６２６及び６２７に基づき上記窓の適正状態を導出する。その後、車両側制御部１１０は、導出した適正状態をアプリ７１０の出力ＴＯＰＩＣとしてデータテーブル１２１に格納しても構わない。この際、必要に応じて上述のデータ形式の変換が行われる。更に、車両側制御部１１０は、窓の適正状態の情報を必要とするボディＥＣＵ１２に対し、導出した適正状態を示すデータを配信する。

【0072】

ボディＥＣＵ１２は、パワーウィンドウ３３を構成する窓の状態が上記適正状態となるように、第３駆動信号をパワーウィンドウ３３に供給する。ここにおける第３駆動信号は、車両側制御部１１０からＣＧＷ２０を通じてボディＥＣＵ１２が受信したデータであって且つ上記適正状態を示すデータに基づき、設定される。このように自動窓開閉のサービスにおいて、車両側制御部１１０はアプリ７１０に従ってボディＥＣＵ１２に対し必要な情報（上記適正状態を示すデータ）を配信し、これによってパワーウィンドウ３３を制御する。

【0073】

任意のアプリ７００（図７（ａ）及び図８参照）に関して、車両側制御部１１０は、アプリ情報テーブルＴＢＬ_Ｐ及び機能安全テーブルＴＢＬ_Ｑに基づき、以下に示す車両側フィルタ処理を実行する。車両側フィルタ処理において、車両側制御部１１０は、アプリ７００にて設定される制御対象について、テーブルＴＢＬ_Ｐ内の信頼レベルとテーブルＴＢＬ_Ｑ内の機能安全レベルを比較する。そして、車両側フィルタ処理において、車両側制御部１１０は、比較された信頼レベル及び機能安全レベルが所定の許可条件を充足するとき、アプリ７００の実行による制御対象の制御を許可し、そうでないきアプリ７００の実行による制御対象の制御を禁止する。上記許可条件は予め定められる（詳細は後述）。アプリ７００の実行による制御対象の制御が許可される状態において、アプリ７００が車両側制御部１１０にて実行されると、実際に、アプリ７００に従い、車両側制御部１１０により制御対象が制御される。詳細には制御対象に対して駆動信号を与えるＥＣＵと車両側制御部１１０とが協働して、制御対象が制御されることになる。アプリ７００の実行による制御対象の制御が禁止される状態において、車両側制御部１１０はアプリ７００を実行しない。或いは、アプリ７００の実行による制御対象の制御が禁止される状態において、車両側制御部１１０はアプリ７００を実行することがあっても良いが、アプリ７００による制御対象の制御が行われないよう、アプリ７００の機能をマスクする。

【0074】

比較された信頼レベル及び機能安全レベルについて、信頼レベルが機能安全レベル以上であるとき許可条件が充足し、信頼レベルが機能安全レベル未満であるとき許可条件が充足しない。このような車両側フィルタ処理は、制御対象ごとに行われて良い。車両側フィルタ処理により、信頼性の足りないアプリにて制御対象が制御されることが抑制され、以って、安全性が担保される。

【0075】

信頼レベルにおける“Ａ”、“Ｂ”、“Ｃ”、“Ｄ”のレベルは、夫々、第１、第２、第３、第４レベルに相当する。機能安全レベルにおける“Ａ”、“Ｂ”、“Ｃ”、“Ｄ”のレベルも、夫々、第１、第２、第３、第４レベルに相当する。任意の整数ｉに関して、第（ｉ＋１）レベルは第ｉレベルよりも高い。任意の整数ｉに関して、信頼レベルにおける第ｉレベルと機能安全レベルにおける第ｉレベルは同一のレベルとみなされる。このため、注目した信頼レベルが“Ａ”である場合には、注目した機能安全レベルが“Ａ”であるときのみ、注目した信頼レベルは注目した機能安全レベル以上である。注目した信頼レベルが“Ｂ”である場合には、注目した機能安全レベルが“Ａ”又は“Ｂ”であるときのみ、注目した信頼レベルは注目した機能安全レベル以上である。注目した信頼レベルが“Ｃ”である場合には、注目した機能安全レベルが“Ａ”、“Ｂ”又は“Ｃ”であるときのみ、注目した信頼レベルは注目した機能安全レベル以上である。注目した信頼レベルが“Ｄ”である場合には、注目した機能安全レベルが“Ａ”、“Ｂ”、“Ｃ”及び“Ｄ”の何れであっても、注目した信頼レベルは注目した機能安全レベル以上である。

【0076】

各アプリに関する各信頼レベルは、機能安全レベルと同等又は近似の品質を持つよう定義され、各アプリがシステムＳＹＳに導入される前に予め規定される。各信頼レベルは第三者機関の認証の下で規定される。或いは、各アプリを使用可能な車両ＣＲの製造業者又は販売業者の許諾の下、各信頼レベルが規定される。例えば或る制御対象に関して、アプリ７００の信頼レベルとして“Ｂ”を得るためにはアプリ７００の信頼レベルとして“Ａ”を得るよりも、アプリ７００は、第三者機関で、より厳しい認証試験を合格する必要がある。

【0077】

図９（ａ）及び図９（ｂ）のアプリ７１０に関する許可条件の成否を説明する。アプリ７１０における制御対象はファンモータ３４及びエアコンディショナ３５を含み、アプリ７１０においてファンモータ３４及びエアコンディショナ３５に対する信頼レベルは “Ｂ”である。一方、機能安全テーブルＴＢＬ_Ｑにおいて、ファンモータ３４及びエアコンディショナ３５に対して定められた機能安全レベルは“Ａ”である。そうすると、アプリ７１０に関し、ファンモータ３４及びエアコンディショナ３５に対する信頼レベル（“Ｂ”のレベル）は、ファンモータ３４及びエアコンディショナ３５に対する機能安全レベル（“Ａ”のレベル）より高い。このため、アプリ７１０において、ファンモータ３４及びエアコンディショナ３５に対する許可条件は充足する。また、アプリ７１０における制御対象はパワーウィンドウ３３を含み、アプリ７１０においてパワーウィンドウ３３に対する信頼レベルは “Ｂ”である。一方、機能安全テーブルＴＢＬ_Ｑにおいて、パワーウィンドウ３３に対して定められた機能安全レベルは“Ｂ”である。そうすると、アプリ７１０に関し、パワーウィンドウ３３に対する信頼レベル（“Ｂ”のレベル）は、パワーウィンドウ３３に対する機能安全レベル（“Ｂ”のレベル）と一致する。このため、アプリ７１０において、パワーウィンドウ３３に対する許可条件は充足する。

【0078】

図１０（ａ）のアプリ７２０に関する許可条件の成否を説明する。図１０（ｂ）には、アプリ７２０に付加されたアプリ情報テーブルＴＢＬ_Ｐであるアプリ情報テーブルＴＢＬ_７２０が示される。アプリ７２０はアプリ７１０と全く同じアプリである。また、アプリ情報テーブルＴＢＬ_７２０はアプリ情報テーブルＴＢＬ_７１０と類似するが、アプリ情報テーブルＴＢＬ_７２０では各制御対象に対応付けられた信頼レベルが全て“Ａ”である。信頼レベルの相違を除き、アプリ情報テーブルＴＢＬ_７２０はアプリ情報テーブルＴＢＬ_７１０と同様である。アプリ７２０に関し、ファンモータ３４及びエアコンディショナ３５に対する信頼レベル（“Ａ”のレベル）は、ファンモータ３４及びエアコンディショナ３５に対する機能安全レベル（“Ａ”のレベル）と一致する。このため、アプリ７２０において、ファンモータ３４及びエアコンディショナ３５に対する許可条件は充足する。アプリ７２０に関し、パワーウィンドウ３３に対する信頼レベル（“Ａ”のレベル）は、パワーウィンドウ３３に対する機能安全レベル（“Ｂ”のレベル）より低い。このため、アプリ７２０において、パワーウィンドウ３３に対する許可条件は充足しない。

【0079】

図１１に、アプリのインストール動作（換言すれば、コンテナ部１２２へのアプリの保存動作）に関わるシステムＳＹＳのフローチャートを示す。通信制御装置１００が起動すると、ステップＳ１１において、車両側制御部１１０は、機能安全テーブルＴＢＬ_Ｑが格納されたメモリから機能安全テーブルＴＢＬ_Ｑを読み出す。その後、ステップＳ１２に進む。機能安全テーブルＴＢＬ_Ｑが格納されたメモリは、車両側メモリ１２０又はＣＧＷ２０を構成するＥＣＵ内のメモリである。

【0080】

車両側制御部１１０は、コンテナ部１２２に対して新たにアプリが保存されたかを継続的に監視する。システムＳＹＳでは、ユーザの指示等に基づき、サーバ装置２００のアプリＤＢ２２１に格納されている何れかのアプリがサーバ装置２００から通信制御装置１００に配信される。サーバ装置２００から配信されたアプリが通信制御装置１００にて受信されると、受信されたアプリが、何れかのコンテナ１２２Ｃに保存される。上述したように、任意のアプリにはアプリ情報テーブルが付加されており、アプリと、それに対応するアプリ情報テーブルとが、配信されてコンテナ１２２Ｃに保存される。

【0081】

ステップＳ１２において、車両側制御部１１０は、新たなアプリがコンテナ部１２２に保存されたか否かを確認する。新たなアプリがコンテナ部１２２に保存された場合には（ステップＳ１２のＹ）、ステップＳ１３に進み、そうでなければステップＳ１２の処理を繰り返す。ここで用語“対象アプリ”を導入する。第１実施例では、ステップＳ１３に進む場合における新たなアプリが対象アプリに該当する。説明の具体化のため、対象アプリは図７（ａ）のアプリ７００であると考える。対象アプリ７００に付加されたアプリ情報テーブルはアプリ情報テーブルＴＢＬ_Ｐ（図８参照）である。

【0082】

ステップＳ１３において、車両側制御部１１０は、コンテナ部１２２から対象アプリに付加されたアプリ情報テーブルＴＢＬ_Ｐを読み込む。また、ステップＳ１３において、車両側制御部１１０は自身が管理する変数ｉに“１”を代入する。ステップＳ１３の後、ステップＳ１４に進む。ステップＳ１４～Ｓ２３の各処理は対象アプリに関する処理である。故に、ステップＳ１４～Ｓ２３の各説明における識別情報ＩＮＤＥＸ_Ｐ、制御対象及び信頼レベルは、特に記述なき限り、対象アプリのアプリ情報テーブルＴＢＬ_Ｐ中の識別情報ＩＮＤＥＸ_Ｐ、制御対象及び信頼レベルを指す。

【0083】

ステップＳ１４において、車両側制御部１１０は、第ｉ制御対象に対して許可条件が充足するかを判断する。第ｉ制御対象の信頼レベルが第ｉ制御対象の機能安全レベル以上であるとき、第ｉ制御対象に対して許可条件が充足し、そうでないとき、第ｉ制御対象に対して許可条件が充足しない。ここにおける第ｉ制御対象は、アプリ情報テーブルＴＢＬ_Ｐにおける“ｉ”の識別情報ＩＮＤＥＸ_Ｐに対応する制御対象である（図８参照）。例えば、第ｉ制御対象がパワーウィンドウ３３であれば、パワーウィンドウ３３に対応する信頼レベルとパワーウィンドウ３３に対応する機能安全レベルとが比較され、信頼レベルが機能安全レベル以上であるときのみパワーウィンドウ３３に対し許可条件が充足する。

【0084】

ステップＳ１４において、第ｉ制御対象に対して許可条件が充足するとき（ステップＳ１４のＹ）ステップＳ１５に進み、第ｉ制御対象に対して許可条件が充足しないとき（ステップＳ１４のＮ）ステップＳ１６に進む。

【0085】

ステップＳ１５において車両側制御部１１０はフラグＦＬＧ［ｉ］に“１”を代入する。ステップＳ１６において車両側制御部１１０はフラグＦＬＧ［ｉ］に“０”を代入する。フラグＦＬＧ［ｉ］は車両側制御部１１０にて管理されるフラグである。ステップＳ１５又はＳ１６の後、ステップＳ１７に進む。

【0086】

ステップＳ１７において、車両側制御部１１０は“ｉ＝Ｍ”の成否を判断する。Ｍは、対象アプリ（ここではアプリ７００）における制御対象の総数を表す（図８参照）。“ｉ＝Ｍ”の成立時には（ステップＳ１７のＹ）ステップＳ１９に進む。“ｉ＝Ｍ”の非成立時には（ステップＳ１７のＮ）、ステップＳ１８にて変数ｉに“１”を加算してからステップＳ１４に戻る。このため、ステップＳ１９に進む段階では、第１～第Ｍ制御対象に対して許可条件が充足しているかが個別に判断済みであり、その判断結果がフラグＦＬＧ［１］～ＦＬＧ［Ｍ］に格納されている。

【0087】

ステップＳ１９において、車両側制御部１１０はフラグＦＬＧ［１］～ＦＬＧ［Ｍ］の値が全て“１”であるかを確認する。フラグＦＬＧ［１］～ＦＬＧ［Ｍ］の値が全て“１”である場合（ステップＳ１９のＹ）、ステップＳ２１に進み、そうでない場合（ステップＳ１９のＮ）、ステップＳ２０に進む。

【0088】

ステップＳ２０において、車両側制御部１１０はフラグＦＬＧ［１］～ＦＬＧ［Ｍ］の値に“１”と“０”が混在しているかを確認する。フラグＦＬＧ［１］～ＦＬＧ［Ｍ］の値に“１”と“０”が混在している場合（ステップＳ２０のＹ）、ステップＳ２２に進み、そうでない場合（ステップＳ２０のＮ）、ステップＳ２３に進む。

【0089】

ステップＳ２１において車両側制御部１１０は全許可処理を実行する。全許可処理では全ＯＫ通知が行われる。全ＯＫ通知では、対象アプリの全サービスが車両ＣＲ及び通信制御装置１００にて使用可能である旨が、ユーザに対して通知される。全ＯＫ通知並びに後述の一部ＯＫ通知及びＮＧ通知は所定のマンマシンインターフェースを用いて実現される。マンマシンインターフェースはユーザが視認可能な表示画面及びユーザからの任意の操作を受け付ける操作部を有する。マンマシンインターフェースは、通信制御装置１００に設けられていても良いし、何れかのノード１０に含まれていても良い。マンマシンインターフェースの表示画面での映像表示又は音声出力にて、全ＯＫ通知並びに後述の一部ＯＫ通知及びＮＧ通知が行われて良い。

【0090】

また全許可処理において車両側制御部１１０は対象アプリを全許可アプリに設定する。車両側制御部１１０は、全許可アプリの実行を許可すると共に全許可アプリの実行による全制御対象の制御を許可する。以後、全許可アプリは車両側制御部１１０により常時実行される又はユーザの要求に応じて実行される。全許可アプリが車両側制御部１１０にて実行されると、全許可アプリに従い、車両側制御部１１０は全許可アプリの各制御対象を制御する。

【0091】

ステップＳ２２において車両側制御部１１０は一部許可処理を実行する。一部許可処理では一部ＯＫ通知が行われる。一部ＯＫ通知では、対象アプリの一部のサービスのみが車両ＣＲ及び通信制御装置１００にて使用可能である旨が、ユーザに対して通知される。この際、フラグＦＬＧ［１］～ＦＬＧ［Ｍ］の値に基づき、対象アプリの全サービスの内、何れのサービスが使用可能であって、何れのサービスが使用不能であるかも通知される。

【0092】

また一部許可処理において車両側制御部１１０は対象アプリを一部許可アプリに設定する。車両側制御部１１０は、一部許可アプリの実行を許可するが、許可条件を満たす制御対象のみの制御を許可する。以後、一部許可アプリは車両側制御部１１０により常時実行される又はユーザの要求に応じて実行される。一部許可アプリが車両側制御部１１０にて実行されると、一部許可アプリに従い、車両側制御部１１０は一部許可アプリの制御対象の内、許可条件を満たす制御対象のみの制御を実行し、許可条件を満たさない制御対象の制御を非実行とする。

【0093】

ステップＳ２３において車両側制御部１１０は全禁止処理を実行する。全禁止処理では全ＮＧ通知が行われる。全ＯＫ通知では、対象アプリの全サービスが車両ＣＲ及び通信制御装置１００にて使用不可である旨が、ユーザに対して通知される。

【0094】

また全禁止処理において車両側制御部１１０は対象アプリを全禁止アプリに設定する。車両側制御部１１０は全禁止アプリの実行を禁止する。そうすると、全禁止アプリは車両側制御部１１０にて実行されず、全禁止アプリによる制御対象の制御が実際に行われることは無い。或いは、車両側制御部１１０は全禁止アプリを実行することがあっても良いが、その場合でも、全禁止アプリの制御対象を制御するための信号が対応するＥＣＵ（例えば制御対象がパワーウィンドウ３３であればボディＥＣＵ１２）に送信されないようマスク処理を行う。

【0095】

例えば、対象アプリが上述のアプリ７１０（図９（ａ）及び（ｂ）参照）である場合を考える。対象アプリ７１０において、第１、第２、第３制御対象は、夫々、ファンモータ３４、エアコンディショナ３５、パワーウィンドウ３３であり、第１、第２、第３制御対象に対応する信頼レベルは全て“Ｂ”である。そうすると、第１制御対象（ファンモータ３４）の信頼レベル“Ｂ”は第１制御対象の機能安全レベル“Ａ”よりも高いため、“ＦＬＧ［１］＝１”となる（１回目のステップＳ１５）。同様に、第２制御対象（エアコンディショナ３５）の信頼レベル“Ｂ”は第２制御対象の機能安全レベル“Ａ”よりも高いため、“ＦＬＧ［２］＝１”となる（２回目のステップＳ１５）。更に同様に、第３制御対象（パワーウィンドウ３３）の信頼レベル“Ｂ”は第３制御対象の機能安全レベル“Ｂ”と一致するため、“ＦＬＧ［３］＝１”となる（３回目のステップＳ１５）。結果、対象アプリ７１０については全許可処理が実行され、対象アプリ７１０は全許可アプリに設定される（ステップＳ２１）。

【0096】

ステップＳ２１を経て対象アプリ７１０は車両側制御部１１０にて実行される。そうすると、対象アプリ７１０に従い車両側制御部１１０によりファンモータ３４、エアコンディショナ３５及びパワーウィンドウ３３が制御されることで、対象アプリ７１０による室内快適調整及び自動窓開閉の各サービスが実現される。より詳細には例えば、対象アプリ７１０に従い車両側制御部１１０は、ファンモータ３４及びエアコンディショナ３５を制御するための制御信号をＣＧＷ２０を介してエアコンＥＣＵ１３に送信する。エアコンＥＣＵ１３は受信した制御信号に基づきファンモータ３４及びエアコンディショナ３５を駆動する。加えて例えば、対象アプリ７１０に従い車両側制御部１１０は、パワーウィンドウ３３を制御するための制御信号をＣＧＷ２０を介してボディＥＣＵ１２に送信する。ボディＥＣＵ１２は受信した制御信号に基づきパワーウィンドウ３３を駆動する。

【0097】

また例えば、対象アプリが上述のアプリ７２０（図１０（ａ）及び（ｂ）参照）である場合を考える。対象アプリ７２０において、第１、第２、第３制御対象は、夫々、ファンモータ３４、エアコンディショナ３５、パワーウィンドウ３３であり、第１、第２、第３制御対象に対応する信頼レベルは全て“Ａ”である。そうすると、第１制御対象（ファンモータ３４）の信頼レベル“Ａ”は第１制御対象の機能安全レベル“Ａ”と一致するため、“ＦＬＧ［１］＝１”となる（１回目のステップＳ１５）。同様に、第２制御対象（エアコンディショナ３５）の信頼レベル“Ａ”は第２制御対象の機能安全レベル“Ａ”と一致するため、“ＦＬＧ［２］＝１”となる（２回目のステップＳ１５）。但し、第３制御対象（パワーウィンドウ３３）の信頼レベル“Ａ”は第３制御対象の機能安全レベル“Ｂ”よりも低いため、“ＦＬＧ［３］＝０”となる（３回目のステップＳ１５）。結果、対象アプリ７２０については一部許可処理が実行され、対象アプリ７２０は一部許可アプリに設定される（ステップＳ２２）。

【0098】

ステップＳ２２を経て対象アプリ７２０が車両側制御部１１０にて実行される。そうすると、対象アプリ７２０に従い車両側制御部１１０によりファンモータ３４及びエアコンディショナ３５が制御されることで、対象アプリ７２０による室内快適調整のサービスが実現される。より詳細には例えば、対象アプリ７２０に従い車両側制御部１１０は、ファンモータ３４及びエアコンディショナ３５を制御するための制御信号をＣＧＷ２０を介してエアコンＥＣＵ１３に送信する。エアコンＥＣＵ１３は受信した制御信号に基づきファンモータ３４及びエアコンディショナ３５を駆動する。但し、“ＦＬＧ［３］＝０”であるが故に、車両側制御部１１０は対象アプリ７２０によるパワーウィンドウ３３の制御を実行しない。車両側制御部１１０は、対象アプリ７２０を実行しているときにおいて対象アプリ７２０に基づく制御信号がボディＥＣＵ１２に送信されることをマスクする（禁止する）。当該マスクはＣＧＷ２０にて行われても良い。

【0099】

図１２（ａ）に示すアプリ７３０はアプリ７００の他の例である。アプリ７３０に付加されるアプリ情報テーブルＴＢＬ_Ｐはアプリ情報テーブルＴＢＬ_７３０である。図１２（ｂ）にアプリ情報テーブルＴＢＬ_７３０の構造を示す。アプリ７３０において計２個の機能部が第１及び第２制御対象として設定される。即ち、アプリ７３０において“Ｍ＝２”である。アプリ情報テーブルＴＢＬ_７３０において、“１”、“２”の識別情報ＩＮＤＥＸ_Ｐに対応付けられた制御対象（即ち第１、第２制御対象）は、夫々、ワイパ３２、パワーウィンドウ３３である。アプリ情報テーブルＴＢＬ_７３０において、“１”の識別情報ＩＮＤＥＸ_Ｐに対応付けられたサービス情報は自動清掃を示し、“２”の識別情報ＩＮＤＥＸ_Ｐに対応付けられたサービス情報は自動窓開閉を示す。アプリ情報テーブルＴＢＬ_７３０において、“１”及び“２”の識別情報ＩＮＤＥＸ_Ｐに対応付けられた信頼レベルは全て“Ａ”である。アプリ７３０による自動清掃は、アプリ７３０に従ってワイパ３２を自動的に作動させるサービスである。

【0100】

対象アプリが上述のアプリ７３０である場合を考える。対象アプリ７３０に関し、第１制御対象（ワイパ３２）の信頼レベル“Ａ”は第１制御対象の機能安全レベル“Ｂ”より低いため、“ＦＬＧ［１］＝０”となる（１回目のステップＳ１５）。同様に、第２制御対象（パワーウィンドウ３３）の信頼レベル“Ａ”は第２制御対象の機能安全レベル“Ｂ”より低いため、“ＦＬＧ［２］＝０”となる（２回目のステップＳ１５）。結果、対象アプリ７３０については全禁止処理が実行され、対象アプリ７２０は全禁止アプリに設定される（ステップＳ２３）。

【0101】

従って対象アプリ７３０がコンテナ部１２２に格納されていたとしても、車両側制御部１１０は対象アプリ７３０を実行しない。或いは、車両側制御部１１０は対象アプリ７３０を実行することがあっても良いが、その場合でも、対象アプリ７３０によるワイパ３２及びパワーウィンドウ３３を制御するための信号がボディＥＣＵ１２に送信されないようマスクを行う。当該マスクはＣＧＷ２０にて行われても良い。何れにせよ、対象アプリ７３０に従ってワイパ３２及びパワーウィンドウ３３が制御されることは無い。

【0102】

また、図１１のフローチャートを図１３のフローチャートへと変更するようにしても良い。即ち、ステップＳ１９において、フラグＦＬＧ［１］～ＦＬＧ［Ｍ］の値が全て“１”である場合（ステップＳ１９のＹ）、ステップＳ２１に進み、そうでない場合（ステップＳ１９のＮ）、常にステップＳ２３に進むようにしても良い。図１３のフローチャートが採用される場合、対象アプリは必ず全許可アプリ及び全禁止アプリの何れかに設定されることになる。図１３のフローチャートが採用される場合、アプリ７１０は全許可アプリに設定される一方、アプリ７２０及び７３０は全禁止アプリに設定される。

【0103】

例えば、対象アプリにおける一部機能でも十分に有用な機能を実現できる場合は、図１１のフローチャートによる制御の採用が好ましい。一方、対象アプリにおける一部機能だけでは十分満足できる効果を発揮できない場合などにあっては、図１３のフローチャートによる制御が好ましい。

【0104】

尚、アプリ７１０、７２０及び７３０は何れも２以上の制御対象の制御を行うためのアプリであるが、上述したように、制御対象が１つのみのアプリもある。

【0105】

このように、車両側制御部１１０は、対象アプリの制御対象に関して対象アプリに付加された信頼レベルと、当該制御対象に対し車両ＣＲにて定められた機能安全レベルと、を参照する。そして、車両側制御部１１０は参照した信頼レベル及び機能安全レベルに基づき対象アプリの実行可否を決定する。また、車両側制御部１１０は参照した信頼レベル及び機能安全レベルに基づき対象アプリの実行による制御対象の制御可否を決定する。

【0106】

これにより、車両制御に適したアプリを実行できる又はアプリによる適正な車両制御が可能となる。信頼性の足りないアプリによる車両制御を抑制でき、安全性が担保される。

【0107】

具体的には、車両側制御部１１０は、参照した信頼レベル及び機能安全レベルが上述の許可条件を充足するとき、対象アプリの実行を許可し（Ｓ２１）、許可条件を逸脱するとき（換言すれば許可条件を満たさないとき）、対象アプリの実行を禁止する（Ｓ２３）。これにより、車両制御に適したアプリを実行できる。信頼性の足りないアプリによる車両制御を抑制でき、安全性が担保される。

【0108】

ステップＳ２３における全禁止処理において、車両側制御部１１０は対象アプリをコンテナ部１２２から削除するようにしても良い。これにより、利用不能なアプリがコンテナ部１２２から削除されるため、コンテナ部１２２の空き容量を増やすことができる。

【0109】

対象アプリの制御対象が複数ある場合、それらの制御可否が個別に決定されて良い。より具体的には、対象アプリの制御対象として第１及び第２制御対象に注目した場合、対象アプリに付加されたアプリ情報テーブルにおいて第１制御対象に対する第１信頼レベルと第２制御対象に対する第２信頼レベルが定められる。このとき車両側制御部１１０は、以下のように動作できる。即ち、車両側制御部１１０は、第１及び第２信頼レベルと、第１及び第２制御対象に対し車両ＣＲにて定められた第１及び第２機能安全レベル（機能安全テーブルＴＢＬ_Ｑにおける、第１及び第２制御対象に対する機能安全レベル）と、を参照する。そして、車両側制御部１１０は、参照した各信頼レベル及び各機能安全レベルに基づき、対象アプリの実行による第１制御対象の実行可否と対象アプリの実行による第２制御対象の実行可否とを個別に制御する。これにより、制御対象ごとにアプリによる制御実行の妥当性又は安全性が評価され、安全性が担保されたサービスのみを利用するといったことが可能となる。

【0110】

具体例として、第１信頼レベル及び第１機能安全レベルが許可条件を充足する一方で、第２信頼レベル及び第２機能安全レベルが許可条件を逸脱する特定ケースを考える。特定ケースにおいて、車両側制御部１１０は、対象アプリの実行による第１制御対象の制御を許可する一方で対象アプリの実行による第２制御対象の制御を禁止する。これにより、安全性が担保されたサービスのみを利用するといったことが可能となる。アプリ７２０（図１０（ａ）及び（ｂ）参照）が対象アプリである場合において、第１制御対象をファンモータ３４又はエアコンディショナ３５として捉え、且つ、第２制御対象をパワーウィンドウ３３として捉えたケースが、上記特定ケースに該当する。一部許可処理の実行を通じ、車両側制御部１１０は、対象アプリ７２０の実行による第１制御対象（３４又は３５）の制御を許可する一方で対象アプリの実行による第２制御対象（３３）の制御を禁止する。

【0111】

尚、車両側フィルタ処理はＣＧＷ２０にて行われるようにしても良い。図１１又は図１３に示す各ステップの処理の全部又は一部は、ＣＧＷ２０にて行われるようにしても良い。車両側フィルタ処理は車両側制御部１１０及びＣＧＷ２０の協働により行われるようにしても良く、故に図１１又は図１３に示す各ステップの処理を、車両側制御部１１０及びＣＧＷ２０の協働にて行われるようにしても良い。

【0112】

通信制御装置１００は車載装置の例である。特に車両側フィルタ処理がＣＧＷ２０にて行われる場合にあっては、通信制御装置１００及びＣＧＷ２０とで車載装置が形成されると考えても良い。

【0113】

サーバ装置２００は通信制御装置１００に対して任意のアプリ７００（対象アプリであり得る）を送信するプログラム提供装置として機能する。サーバ装置２００は、通信制御装置１００に対してアプリ７００を送信する際、アプリ７００に対応するアプリ情報テーブルＴＢＬ_Ｐ（図７（ａ）参照）をアプリ７００に付加して通信制御装置１００に送信する。

【0114】

通信制御装置１００及びサーバ装置２００を含んで形成されるシステムＳＹＳを、車両用システム、車両用通信システム又は車両用制御システムと称することができる。

【0115】

＜＜第２実施例＞＞
システムＳＹＳの第２実施例を説明する。車両側制御部１１０が行う処理であって、サーバ装置２００から受信したアプリをコンテナ部１２２に保存する処理を、アプリ保存処理と称する。第１実施例ではコンテナ部１２２に対象アプリを保存してからステップＳ１３以降の処理を行っているが、コンテナ部１２２に対象アプリを保存する前にステップＳ１３以降の処理を行うようにしても良い。具体的には以下のようにしても良い。

【0116】

図１４に、アプリのインストール動作（換言すれば、コンテナ部１２２へのアプリの保存動作）に関わるシステムＳＹＳのフローチャートであって、第２実施例に係るフローチャートを示す。通信制御装置１００が起動すると、ステップＳ１１において、車両側制御部１１０は、機能安全テーブルＴＢＬ_Ｑが格納されたメモリから機能安全テーブルＴＢＬ_Ｑを読み出す。その後、ステップＳ１２ａに進む。ステップＳ１２ａにおいて、車両側制御部１１０は、マンマシンインターフェースに対するユーザの選択操作等に基づき、アプリＤＢ２２１内の何れかのアプリを対象アプリに設定する。ステップＳ１２ａにおいて、車両側制御部１１０は、対象アプリに付加されたアプリ情報テーブルＴＢＬ_Ｐの送信要求信号をサーバ装置２００に送信する。ステップＳ１２ａの後、ステップＳ１３に進む。

【0117】

ステップＳ１３において、サーバ装置２００は、上記送信要求信号の受信に応答して対象アプリに付加されたアプリ情報テーブルＴＢＬ_Ｐを通信制御装置１００に送信する。ステップＳ１３において、車両側制御部１１０は受信したアプリ情報テーブルＴＢＬ_Ｐを車両側メモリ１２０に保存しつつ読み込む。第２実施例では、後述のステップＳ２４に至るまで対象アプリがサーバ装置２００から通信制御装置１００に配信されず、コンテナ部１２２に保存されない。また、ステップＳ１３において、車両側制御部１１０は自身が管理する変数ｉに“１”を代入する。ステップＳ１３の後、ステップＳ１４に進む。

【0118】

第２実施例において、ステップＳ１４に進んだ後、ステップＳ２１、Ｓ２２又はＳ２３に至るまでの動作並びにステップＳ２１～Ｓ２３での各処理は、第１実施例と同様である。但し、第２実施例では、ステップＳ２１の後にはステップＳ２４に進む、

【0119】

ステップＳ２４において車両側制御部１１０は、対象アプリを通信制御装置１００に送信することを要求する配信要求信号をサーバ装置２００に送信し、配信要求信号を受けてサーバ装置２００は対象アプリを通信制御装置１００に送信する。その後、ステップＳ２４において、車両側制御部１１０は、受信した対象アプリを何れかのコンテナ１２２Ｃに保存するアプリ保存処理を実行する。ここでは、アプリが保存されていない空のコンテナ１２２Ｃが存在するものとし、対象アプリを、対応するアプリ情報テーブルＴＢＬ_Ｐと共に、空のコンテナ１２２Ｃに保存する。

【0120】

ステップＳ２３に進んだ場合、対象アプリに対するアプリ保存処理を実行することなく図１４の動作を終える。

【0121】

図１４のフローチャートにおいてステップＳ２２の後にはステップＳ２５に進む。ステップＳ２２における一部ＯＫ通知が行われた後、ステップＳ２５にて車両側制御部１１０は、上記マンマシンインターフェースを用いてユーザからの操作の入力を受け付ける。この際、車両側制御部１１０は、対象アプリのサービスの一部が制限される旨をユーザに通知した上で、操作の入力を受け付ける。ユーザから、対象アプリのインストールを了承する旨の操作（了承操作）が入力された場合（ステップＳ２５のＹ）、ステップＳ２４に進んで上述のステップＳ２４の処理が実行される。一方、ユーザから了承操作が入力されなかった場合（ステップＳ２５のＮ）、例えば対象アプリのインストールを拒否する旨の操作（拒否操作）が入力された場合、対象アプリに対するアプリ保存処理を実行することなく図１４の動作を終える。

【0122】

尚、図１４のフローチャートを図１５のフローチャートへと変形するようにしても良い。即ち、ステップＳ２２に進んだ場合、ステップＳ２３に進んだ場合と同様に、常に、対象アプリに対するアプリ保存処理を実行することなく、図１４の動作を終えるようにしても良い。

【0123】

このように、車両側制御部１１０は、対象アプリの制御対象に関して対象アプリに付加された信頼レベルと、当該制御対象に対し車両ＣＲにて定められた機能安全レベルと、を参照する。そして、車両側制御部１１０は参照した信頼レベル及び機能安全レベルに基づき、対象アプリに対するアプリ保存処理の実行可否を決定する。

【0124】

これにより、車両制御に適したアプリを保存して当該アプリにて適正な車両制御が可能となる。信頼性の足りないアプリの保存及び当該アプリによる車両制御を抑制でき、安全性が担保される。

【0125】

具体的には、参照した信頼レベル及び機能安全レベルが上述の許可条件を充足するとき、車両側制御部１１０は対象アプリに対するアプリ保存処理を実行する（Ｓ２４の実行に対応）。一方、許可条件を逸脱するとき（換言すれば許可条件を満たさないとき）、車両側制御部１１０は対象アプリに対するアプリ保存処理を禁止する（Ｓ２４の非実行に対応）。これにより、車両制御に適したアプリを保存して当該アプリにて適正な車両制御が可能となる。信頼性の足りないアプリの保存及び当該アプリによる車両制御を抑制でき、安全性が担保される。

【0126】

＜＜第３実施例＞＞
システムＳＹＳの第３実施例を説明する。各アプリが車両ＣＲにて利用可能かどうかの判断をサーバ装置２００にて行うようにしても良い。これについて説明する。

【0127】

任意のアプリ７００（図７（ａ）及び図８参照）に関して、第３実施例に係るサーバ側制御部２１０は、アプリ情報テーブルＴＢＬ_Ｐ及び機能安全テーブルＴＢＬ_Ｑに基づき、以下に示すサーバ側フィルタ処理を実行する。アプリ７００はアプリＤＢ２２１に保存されるアプリであって、サーバ側フィルタ処理の実行前ではコンテナ部１２２に保存されていない。サーバ側フィルタ処理において、サーバ側制御部２１０は、アプリ７００にて設定される制御対象について、テーブルＴＢＬ_Ｐ内の信頼レベルとテーブルＴＢＬ_Ｑ内の機能安全レベルを比較する。そして、サーバ側フィルタ処理において、サーバ側制御部２１０は、比較された信頼レベル及び機能安全レベルが上述の許可条件を充足するとき、アプリ７００を通信制御装置１００に対して送信し、そうでないとき、アプリ７００を通信制御装置１００に対して送信しない。通信制御装置１００においてアプリ７００が受信されると、車両側制御部１１０は受信したアプリ７００をコンテナ部１２２に保存する。

【0128】

図１６にサーバ側フィルタ処理に関わるフローチャートを示す。まずステップＳ１１１において、サーバ側制御部２１０は通信網ＮＥＴを介した通信を通じて通信制御装置１００から車両ＣＲの機能安全テーブルＴＢＬ_Ｑを受信及び取得する。尚、機能安全テーブルＴＢＬ_Ｑはサーバ側メモリ２２０に予め格納されていても良い。

【0129】

続くステップＳ１１２において、サーバ側制御部２１０はアプリＤＢ２２１内の何れかのアプリを対象アプリに設定する。上述のマンマシンインターフェースに対してユーザが入力したアプリ選択操作に基づく配信要求信号が通信制御装置１００からサーバ装置２００に送信されて良く、サーバ側制御部２１０は当該配信要求信号に基づき対象アプリを設定して良い。或いは、所定のアルゴリズムに従って対象アプリが設定されても良い。ステップＳ１１２の後、ステップＳ１１３に進む。

【0130】

ステップＳ１１３において、サーバ側制御部２１０は、アプリＤＢ２２１から対象アプリに付加されたアプリ情報テーブルＴＢＬ_Ｐを読み込む。また、ステップＳ１１３において、サーバ側制御部２１０は自身が管理する変数ｉに“１”を代入する。ステップＳ１１３の後、ステップＳ１１４に進む。

【0131】

ステップＳ１１４～Ｓ１２３の処理の実行主体が車両側制御部１１０ではなくサーバ側制御部２１０である点を除き、ステップＳ１１４～Ｓ１２３の処理は夫々図１１に示されるステップＳ１４～Ｓ２３の処理と同様であり、第１実施例の記載が第３実施例にも適用される。この適用の際、第１実施例の記載中の車両側制御部１１０をサーバ側制御部２１０に読み替え、且つ、第１実施例の記載中の符号Ｓ１４～Ｓ２３を夫々符号Ｓ１１４～Ｓ１２３に読み替えれば良い。

【0132】

対象アプリが全許可アプリに設定されるステップＳ１２１の後、ステップＳ１２４に進む。ステップＳ１２４において、サーバ側制御部２１０は対象アプリを全許可アプリとして通信制御装置１００に対して送信する。この際、全許可アプリに対応するアプリ情報テーブルも通信制御装置１００に対して送信される。通信制御装置１００において全許可アプリ及び対応するアプリ情報テーブルが受信されると、車両側制御部１１０は受信した全許可アプリをアプリ情報テーブルと共にコンテナ部１２２に保存する。車両側制御部１１０での全許可アプリの取り扱いは上述した通りである。

【0133】

対象アプリが一部許可アプリに設定されるステップＳ１２２の後、ステップＳ１２５に進む。ステップＳ１２２の段階で対象アプリが一部許可アプリに設定された旨を示す信号がサーバ装置２００から通信制御装置１００に送信される。当該信号に基づきステップＳ１２５にて車両側制御部１１０は、上述のマンマシンインターフェースを用いてユーザからの操作の入力を受け付ける。この際、車両側制御部１１０は、対象アプリのサービスの一部が制限される旨をユーザに通知した上で、操作の入力を受け付ける。ユーザから、対象アプリの送信及びインストールを了承する旨の操作（了承操作）が入力された場合（ステップＳ１２５のＹ）、ステップＳ１２６に進む。一方、ユーザから了承操作が入力されなかった場合（ステップＳ１２５のＮ）、例えば対象アプリの送信及びインストールを拒否する旨の操作（拒否操作）が入力された場合、ステップＳ１２６に進むことなく図１６の動作を終える。

【0134】

ステップＳ１２６において、サーバ側制御部２１０は対象アプリを一部許可アプリとして通信制御装置１００に対して送信する。この際、一部許可アプリに対応するアプリ情報テーブルも通信制御装置１００に対して送信される。通信制御装置１００において一部許可アプリ及び対応するアプリ情報テーブルが受信されると、車両側制御部１１０は受信した一部許可アプリをアプリ情報テーブルと共にコンテナ部１２２に保存する。車両側制御部１１０での一部許可アプリの取り扱いは上述した通りである。サーバ側制御部２１０は、ステップＳ１１４からステップＳ１２１、Ｓ１２２又はＳ１２３に至るまでの段階において、対象アプリに対して導出したフラグＦＬＧ［１］～ＦＬＧ［Ｍ］の値を対象アプリに対応するアプリ情報テーブルに追記する。追記された値に基づき、車両側制御部１１０は、制御対象ごとに制御対象の制御が許可又は禁止されているのかを認識できる（許可条件を満たす制御対象と許可条件を満たさない制御対象とを区別できる）。

【0135】

対象アプリが全禁止アプリに設定されるステップＳ１２３の後は、ステップＳ１２４又はＳ１２６に進むことなく図１６の動作を終える。ステップＳ１２４又はＳ１２６に進まなかった場合、対象アプリはサーバ装置２００から通信制御装置１００に送信されず、故にコンテナ部１２２に保存されない。

【0136】

尚、図１６のフローチャートを図１７のフローチャートへと変形するようにしても良い。即ち、ステップＳ１２２に進んだ場合、ステップＳ１２３に進んだ場合と同様に、常に、対象アプリをサーバ装置２００から通信制御装置１００に送信しないようにしても良い。

【0137】

このように、サーバ側制御部２１０は、対象アプリの制御対象に関して対象アプリに付加された信頼レベルと、当該制御対象に対し車両ＣＲにて定められた機能安全レベルと、を参照する。そして、サーバ側制御部２１０は参照した信頼レベル及び機能安全レベルに基づき、通信制御装置１００に対する対象アプリの送信可否を決定する。

【0138】

これにより、車両制御に適したアプリを通信制御装置１００に対して送信でき、アプリによる適正な車両制御が可能となる。信頼性の足りないアプリによる車両制御を抑制でき、安全性が担保される。

【0139】

具体的には例えば、サーバ側制御部２１０は、参照した信頼レベル及び機能安全レベルが上述の許可条件を充足するとき、対象アプリを通信制御装置１００に送信し、許可条件を逸脱するとき（換言すれば許可条件を満たさないとき）、対象アプリの通信制御装置１００への送信を禁止する。これにより、車両制御に適したアプリを通信制御装置１００に対して送信でき、アプリによる適正な車両制御が可能となる。信頼性の足りないアプリによる車両制御を抑制でき、安全性が担保される。

【0140】

尚、サーバ側制御部２１０は、通信制御装置１００にて実行可能なアプリのリストを作成するリスト作成処理を実行しても良い。リスト作成処理において、サーバ側制御部２１０は、アプリＤＢ２２１に格納された複数のアプリの夫々を対象アプリとして捉えて、アプリごとに、ステップＳ１１３～Ｓ１２３から成る一連の処理を行う。これにより、アプリＤＢ２２１に格納された複数のアプリが、アプリごとに全許可アプリ、一部許可アプリ及び全禁止アプリの何れかに設定される。

【0141】

リスト作成処理において、サーバ側制御部２１０は、全許可アプリに設定された各アプリをリストに含め、全禁止アプリに設定された各アプリをリストから除外する。アプリをリストに含めるとは、アプリの要約情報（名称及び機能情報など）をリストに含めることを指し、アプリを構成する全てのプログラムをリストに含めるという意味ではない。一部許可アプリに設定された各アプリをリストに含めるか否かは任意である。一部許可アプリに設定された各アプリをリストに含める場合、全許可アプリと一部許可アプリとがユーザにて区別できるよう、適宜、リストに注釈等を含める。

【0142】

サーバ側制御部２１０は作成したリストを通信制御装置１００に送信できる。通信制御装置１００にてリストが受信されると、車両側制御部１１０はマンマシンインターフェースの表示画面に、受信したリストを表示する。ユーザは、リストを参照して、利用したいアプリの選択又は検討を行うことができる。

【0143】

＜＜第４実施例＞＞
システムＳＹＳの第４実施例を説明する。第４実施例では、車両側制御部１１０及びサーバ側制御部２１０の機能の観点から、それらの機能ブロック図を例示する。

【0144】

図１８は車両側制御部１１０の機能ブロック図の例である。図１８の車両側制御部１１０は、アプリ実行部１１１、アプリ評価部１１２及び保存処理部１１３を備える。アプリ実行部１１１はコンテナ部１２２に保存された各アプリを実行する。コンテナ部１２２に保存されて実行される各アプリは基本的に全許可アプリ又は一部許可アプリである。アプリ評価部１１２は、図１１のステップＳ１１～Ｓ２３の各処理又は図１３のステップＳ１１～Ｓ２１及びＳ２３の各処理を行う。或いは、アプリ評価部１１２は、図１４又は図１５のステップＳ１１、Ｓ１２ａ及びＳ１３～Ｓ２３の各処理を行う。保存処理部１１３は、図１４のステップＳ２４及びＳ２５の各処理又は図１５のステップＳ２４の処理を行う。

【0145】

図１９はサーバ側制御部２１０の機能ブロック図の例である。図１９のサーバ側制御部２１０は送信判定部２１１及び送信処理部２１２を備える。送信判定部２１１は、図１６又は図１７のステップＳ１１１～Ｓ１２３の各処理を行う。送信処理部２１２は、図１６のステップＳ１２４～Ｓ１２６の各処理を行う又は図１７のステップＳ１２４の処理を行う。

【0146】

＜＜第５実施例＞＞
システムＳＹＳの第５実施例を説明する。

【0147】

アプリ７００（図７（ａ）参照）の例を幾つか挙げたが、アプリ７００は車両ＣＲ内の何れか１以上の機能部を制御するためのアプリであれば任意である。例えば、アプリ７００は、エンジン３１を制御対象とし、運転手の心拍数に基づきエンジン３１の駆動状態を調整することで駆動力（車両ＣＲを走行させるための駆動力）を調整するアプリであっても良い。例えば、当該アプリは運転手の心拍数が所定値を超える場合など、運転手の心身状態に異常がみられる場合において駆動力を低下させるようエンジン３１の駆動状態を調整する。

【0148】

車両ＣＲに設けられる機能部として機能部３１～３７（図５参照）を例示したが、機能部３１～３７以外の機能部もアプリの制御対象となり得る。機能部３１～３７以外で、アプリの制御対象となり得る機能部として、照明装置（ヘッドランプ、ブレーキランプ、テールランプ、方向指示器等）、エアバッグ、制動装置、カメラ、レーダなどが挙げられる。

【0149】

車載装置又は各種ノード１０はバージョンアップされることがある。また、車両ＣＲへのオプション追加により、何れかのアプリの制御対象となる機能部が新たに追加されることがある。バージョンアップ又はオプション追加が行われた場合でも、上述の各実施例の処理による対応が可能である。

【0150】

アプリは第１種アプリと第２種アプリに大別される。第１種アプリは、車両ＣＲの製造又は出荷段階において、車両ＣＲの製造業者又は販売業者により通信制御装置１００に組み込まれるアプリである。第１種アプリは、製造業者又は販売業者により機能及び性能面等の保証が成されたアプリである。このため、第１種アプリは上述の各実施例にて述べられるアプリに該当しない（第１種アプリが上述の各実施例での対象アプリになることは無い）。これに対し、アプリ７００を含む上述の各実施例にて述べられるアプリは第２種アプリである。第２種アプリは、車両ＣＲの製造及び出荷後においてユーザの意思に基づき通信制御装置１００に組み込まれ得るアプリである。第２種アプリに関しては機能及び性能面等において確認が必要であり、上述の各実施例での対象アプリになり得る。第１種アプリが何れかコンテナ１２２Ｃに保存されて良く、第２種アプリが他の何れかコンテナ１２２Ｃに保存されて良い。

【0151】

本発明の実施形態にて述べた任意の方法をコンピュータに実行させるプログラム、及び、そのプログラムを記録した記録媒体であって且つコンピュータ読み取り可能な不揮発性の記録媒体は、本発明の実施形態の範囲に含まれる。本発明の実施形態における任意の処理は、半導体集積回路等のハードウェア、上記プログラムに相当するソフトウェア、又は、ハードウェアとソフトウェアの組み合わせによって実現されて良い。ここにおけるソフトウェア及びハードウェアは夫々に複数あっても良い。

【0152】

本発明の実施形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。以上の実施形態は、あくまでも、本発明の実施形態の例であって、本発明ないし各構成要件の用語の意義は、以上の実施形態に記載されたものに制限されるものではない。上述の説明文中に示した具体的な数値は、単なる例示であって、当然の如く、それらを様々な数値に変更することができる。

【符号の説明】

【0153】

ＳＹＳ システム
ＣＲ 車両
１０ ノード
１１ 駆動ＥＣＵ
１２ ボディＥＣＵ
１３ エアコンＥＣＵ
１４ シートＥＣＵ
２０ ＣＧＷ
３１ エンジン
３２ ワイパ
３３ パワーウィンドウ
３４ ファンモータ
３５ エアコンディショナ
３６ シート位置調整用のアクチュエータ
３７ シート角度調整用のアクチュエータ
１００ 通信制御装置
１１０ 車両側制御部
１２０ 車両側メモリ
１２１ データテーブル
１２２ コンテナ部
１２２Ｃ コンテナ
１３０ 車両側通信部
２００ サーバ装置
２１０ サーバ側制御部
２２０ サーバ側メモリ
２２１ アプリＤＢ
２３０ サーバ側通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】