特開 2024-5055 通信装置および通信システム

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

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

(11)【公開番号】P2024005055

(43)【公開日】2024-01-17

(54)【発明の名称】通信装置および通信システム

(51)【国際特許分類】

   B60R 16/02 20060101AFI20240110BHJP

【ＦＩ】

B60R16/02 660A

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2022105045

(22)【出願日】2022-06-29

(71)【出願人】

【識別番号】000237592

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

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】坂口 友理

(72)【発明者】

【氏名】奥原 誠

(72)【発明者】

【氏名】大築 ともえ

(57)【要約】

【課題】車載器の制御を適切に行うことができる通信装置および通信システムを提供すること。
【解決手段】実施形態に係る通信装置は、複数のノードが接続可能な通信装置であって、コントローラを有する。コントローラは、接続されたノードから取得したデータに基づき生成した車両に搭載された車載器の制御データを、車載器に送信して車載器の制御を行うコントローラを有する。コントローラは、車両の状態を示す車両情報に基づいて、制御データによる車載器の制御の可否を決定する。
【選択図】図１Ａ

【特許請求の範囲】

【請求項1】

複数のノードが接続可能な通信装置であって、
接続されたノードから取得したデータに基づき生成した車両に搭載された車載器の制御データを、前記車載器に送信して前記車載器の制御を行うコントローラを有し、
前記コントローラは、
前記車両の状態を示す車両情報に基づいて、前記制御データによる前記車載器の制御の可否を決定する
通信装置。

【請求項2】

前記制御データによる前記車載器の制御の許可条件を示す許可条件情報を記憶する記憶部をさらに備え、
前記コントローラは、
前記車両情報が前記許可条件情報における許可条件を満たすか否かにより、前記制御データによる前記車載器の制御の可否を決定する
請求項１に記載の通信装置。

【請求項3】

前記ノードは前記車載器を含む
請求項１に記載の通信装置。

【請求項4】

前記コントローラは、
前記制御データによる前記車載器の制御を禁止すると決定した状況が予め定めた所定回数以上連続する場合、前記車両の搭乗者に対してアラートを通知する
請求項１～３のいずれか１つに記載の通信装置。

【請求項5】

前記コントローラは、
前記制御データによる前記車載器の制御を禁止すると決定した状況が予め定めた所定回数以上連続する場合、前記制御データの生成を禁止する
請求項１～３のいずれか１つに記載の通信装置。

【請求項6】

前記制御データの生成を行うための各アプリケーションプログラムを記憶するコンテナを形成する記憶部をさらに備え、
前記コントローラは、
接続された複数のノードに応じて実行するアプリケーションプログラムを前記コンテナから選択して実行することにより、前記制御データを生成する
請求項１～３のいずれか１つに記載の通信装置。

【請求項7】

アプリケーションプログラムが使用するデータを記憶する掲示板を形成する記憶部を備え、
前記コントローラは、
接続された複数のノードから取得したデータを、前記各アプリケーションプログラムが使用できる形態に変換して前記掲示板に記憶する
請求項６に記載の通信装置。

【請求項8】

前記コントローラは、
接続されたノードを識別する情報を、外部のアプリケーションプログラム提供装置に送信し、
前記アプリケーションプログラム提供装置から送信される接続されたノードに応じたアプリケーションプログラムを受信し、前記コンテナに記憶する
請求項６に記載の通信装置。

【請求項9】

複数のノードが接続可能な車両に搭載された通信装置と、前記車両に搭載された車載器とを有する通信システムであって、
前記通信装置は、
接続されたノードから取得したデータに基づき前記車載器の制御データを生成し、
前記車両の状態を示す車両情報に基づいて、前記制御データによる前記車載器の制御の可否を決定して、前記車載器の制御が可と決定した場合に前記制御データを前記車載器に送信し、
前記車載器は、
前記通信装置から送信された制御データを受信し、当該制御データに基づき車載器の動作制御を行う、
通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信装置および通信システムに関する。

【背景技術】

【0002】

従来、車両ネットワークを介して車種やメーカ、製造年度に依存しない方法で車両データにアクセス可能とする方法が知られている（例えば、特許文献１参照）。また、この種の技術では、記憶した車両データを使用して車載器の制御データを生成し、車載器へ送信することで当該車載器を制御する技術がある。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

しかしながら、従来の技術では、車両の走行状態等によっては、制御データに基づく車載器の制御が適切ではない状況が起こりうる。

【0005】

本発明は、上記に鑑みてなされたものであって、車載器の制御を適切に行うことができる通信装置および通信システムを提供することを目的とする。

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

【0006】

上述した課題を解決し、目的を達成するために、本発明に係る通信装置は、複数のノードが接続可能な通信装置であって、コントローラを有する。前記コントローラは、接続されたノードから取得したデータに基づき生成した車両に搭載された車載器の制御データを、前記車載器に送信して前記車載器の制御を行う。前記コントローラは、前記車両の状態を示す車両情報に基づいて、前記制御データによる前記車載器の制御の可否を決定する。

【発明の効果】

【0007】

本発明によれば、車載器の制御を適切に行うことができる。

【図面の簡単な説明】

【0008】

【図1A】図１Ａは、実施形態に係る通信システムの概要を示す図である。

【図1B】図１Ｂは、実施形態に係るコントローラが有する制御可否決定機能を説明する説明図である。

【図2】図２は、実施形態に係る通信装置の機能構成を示すブロック図である。

【図3】図３は、実施形態に係る通信装置が実行する処理の処理手順を示すフローチャートである。

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

【0009】

以下、添付図面を参照して、本願の開示する通信装置および通信システムの実施形態を詳細に説明する。なお、以下に示す実施形態により本発明が限定されるものではない。

【0010】

まず、図１Ａを用いて、実施形態に係る通信システムの概要について説明する。図１Ａは、実施形態に係る通信システムの概要を示す概念図である。なお、図１Ａでは、通信システム全般の動作を分かりやすくするため、構成要素（構成的表現）、機能要素（機能的表現）を、適宜、混在使用している。

【0011】

図１Ａに示すように、通信システムＳは、通信装置１と、複数のノード１０と、サーバ装置５０とを含む。そして、通信装置１および複数のノード１０は、セントラルゲートウェイ（以下、ＣＧＷ）２０を介して、あるいはＣＧＷ２０を介さずに車両用通信網のＣＡＮ（Controller Area Network）や、Ｗｉ-Ｆｉ（登録商標）等のネットワークに接続されて互いに通信が可能となり、各種情報を送受信する。なお、ＣＧＷ２０を介して接続されるノード１０は、セキュリティ性の高い各種機器で、例えば車両の走行制御に関係する駆動系装置等が該当し、ユーザの持つスマートフォン等の携帯機器に関してはＣＧＷ２０を介さずに通信装置１に接続する場合が多くなる。また、通信装置１およびサーバ装置５０は、例えば、インターネット網等のネットワークに接続され、各種情報を送受信する。

【0012】

ノード１０は、通信装置１と接続されて各種データの送信、または受信を行うもので、独立してある機能を実現する各種装置（通信装置１からのデータの利用、または通信装置１へのデータの提供、を行う）、測定データを通信装置１に提供する各種センサ、また通信装置１からのデータを報知（表示等）するディスプレイ装置やスピーカ装置等の出力デバイス、ユーザの操作内容を示すデータを通信装置１に提供するタッチパネル等の入力デバイス等である。

【0013】

そして、ノード１０は、車両に搭載される車載器を含む。車載器は、搭乗者により車両内に持ち込まれて、あるいは車両に近接状態にされて（車両周辺に位置されて）通信装置１に通信接続される装置、車両製造時に組み込まれる装置、車両製造後、および販売後にユーザ等により新たに追加設置される装置、と言った形態のものがある。なお、車両の構造により各ノード１０の規模は異なるが、車両製造時に組み込まれる各種装置（ノード１０）としては、例えばエンジン制御装置、操舵装置、制動装置、パワーウインドウ装置およびエアコン装置等といったがある。

【0014】

また、ユーザ等により新たに追加設置される装置（ノード１０）としては、例えばナビゲーション装置、ドライブレコーダ装置、およびオーディオ・ビジュアル装置等がある。また、搭乗者により車両に持ち込まれる（あるいは近接状態にされる）装置（ノード１０）としては、スマートフォン、携帯電話、スマートウォッチ、ゲーム機（通信機能付き）、デスクトップ型ＰＣ、ノート型ＰＣ、およびタブレット型ＰＣ等がある。

【0015】

また、各種センサ（各種装置内蔵分以外）としては、例えば、湿度センサ（車内環境確認用）、降雨センサ等がある。そして、出力デバイスおよび出力デバイスとしては、例えば、集中操作パネルや後席用ディスプレイ等がある。

【0016】

なお、車両製造時に組み込まれる各種装置例、追加設置される装置例、車両に持ち込まれる装置例に分類したが、例示した装置は当該分類に限られるものではなく、他の分類に属するものである場合もある。例えば、ナビゲーション装置は車両製造時に組み込まれる場合もある。さらに、他の車両の各種装置、および信号機などのインフラ機器等も、通信装置１との通信が可能な範囲においては、ノード１０となり得る。

【0017】

また、特定のノード１０は、当該ノード１０の各種機能を実現するために必要な各種センサを構成部品として含む。ノード１０が含む各種センサは、例えば、車速センサ、バイタルセンサ、車室の温度を検出する温度センサ、および車室のＣＯ２濃度を検出するＣＯ２センサ、車両の位置を検出するＧＰＳ（Global Positioning System）位置センサ、降雨を検出する降雨センサ（雨滴センサ）などである。なお、バイタルセンサは生体情報を取得するセンサで、例えば、脳波を検出する脳波センサ、および脈拍を検出する脈拍センサ等である。

【0018】

また、独立してある機能を実現するノード１０は、ＥＣＵ（Electronic Control Unit）、所謂コントローラを構成部品として含む。ＥＣＵは、当該ＥＣＵが搭載されたノード１０（装置）の動作を制御する。ＥＣＵは、例えば、パワートレインＥＣＵ、運転支援系ＥＣＵ、マルチメディア系ＥＣＵ、エアコンＥＣＵである。

【0019】

サーバ装置５０は、各種機能を実現するプログラムである各種アプリケーション（以下、アプリ）を記憶しており、適当なアプリを通信装置１に提供する。つまり、サーバ装置５０は、アプリケーションプログラム提供装置である。これらアプリは、各種ノード１０の出力するデータ、例えばノード１０が内蔵するセンサのデータを利用するアプリである。そして、各アプリは、当該アプリを利用するために必要なデータ種別と、当該アプリが出力するデータ種別（制御用のデータ、指令データ（所謂コマンド）等）、後述する許可条件情報のデータに関連付けられて、サーバ装置５０にアプリＤＢ５２として記憶されている。

【0020】

また、サーバ装置５０には、ノード１０の種別（識別情報）とノード１０の持つセンサ（測定データ）種別と、ノード１０が使用できる外部からのデータ（制御用のデータ、指令データ（所謂コマンド）等）種別が関連付けられたデータベースが、ノード情報ＤＢ５４として記憶されている。つまり、サーバ装置５０は、ノード１０の組み合わせに基づき、ノード情報ＤＢ５４とアプリＤＢ５２により、当該ノード１０の組み合わせに対して適当なアプリを選択することが可能となる。

【0021】

通信装置１は、車両に搭載され、ノード１０やサーバ装置５０との各種データの送受信、データの加工等を実行する。通信装置１は、通信部２と、コンテナ４２１と、掲示板４１と、コントローラ３と、を有する。

【0022】

そして、通信部２は、通信装置１とサーバ装置５０との間のデータ通信、および通信装置１と各ノード１０間のデータ通信を行う。コンテナ４２１は、アプリを記憶するもので、書き込みおよび消去可能なメモリで構成される。また、各コンテナ４２１はメモリ領域を適宜分割する等の方法により構成され、各コンテナ４２１には１つのアプリが記憶されるようになっている。

【0023】

掲示板４１は、各ノード１０からのセンサ測定値やその加工データ等を記憶するもので、メモリにより構成される。また、掲示板４１は、ノード１０からのアクセスが可能となっており、ノード１０がノード１０の持つセンサの測定値を書き込んだり、ノード１０が掲示板４１に記憶されたデータを読み取って利用したりすることができる。

【0024】

なお、コンテナ４２１および掲示板４１は、通信装置１がオフの場合でも記憶データが保持されるように、不揮発性のメモリ（フラッシュメモリ、あるいはバックアップ電源付加、等）で構成される。

【0025】

コントローラ３は、通信装置１の各種制御、例えば、通信部２、コンテナ４２１、掲示板４１等の制御、データ加工、データの送受信および書込／消去、等を行う、コントローラであり、マイクロコンピュータ等で構成される。また、コントローラ３は、コンテナ４２１に記憶されたアプリを実行するコンテナエンジンの機能も持つ。

【0026】

通信装置１は、例えば、Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ方式に基づいたＭＱＴＴ（Message Queuing Telemetry Transport）を用いて、データをノード１０やアプリを実行する後述のコンテナエンジンに配信する（ノード１０やコンテナエンジンが、掲示板４１にアクセスしてデータを取得する）。具体的には、通信システムＳでは、プロバイダである通信装置１が、Ｐｕｂｌｉｓｈｅｒであるノード１０からデータを取得し、Ｓｕｂｓｃｒｉｂｅｒであるアプリを実行するコンテナエンジンやノード１０にデータを配信する。

【0027】

なお、アプリは、ノード１０から取得したデータを使用して、例えば、車両に搭載されたノード１０における各種制御に関わる処理を行う。つまり、アプリは、掲示板４１に掲載されたデータを取り込んで使用することで車載器等のノード１０を制御するための制御データを生成し、当該制御データを通信部２を介して制御対象のノード１０へ送信することで、対象のノード１０の制御を行う。

【0028】

このようなアプリにより、ノード１０は、他のノード１０が持つセンサ（当該ノード１０が持たないセンサ）の測定値を利用した、より高度なあるいは他の機能を実現できる。例えば、ノード１０であるエアコンが、自己の持つ車室内温度センサによる車室内温度に加え、他ノード１０が持つ車室内湿度センサによる車室内湿度も使用して最適なエアコン制御を行えるようになる。なお、このような制御は、コンテナ４２１に記憶された対応するアプリが実行して、ノード１０（この例ではエアコン）を制御することになる。また、ノード１０（例えば、エアコン）が対応の機能を持っていれば、エアコン（例えば、エアコン）が掲示板４１のデータを読み取って行うことも可能である。

【0029】

また、アプリは通信装置１に接続されたノード１０に応じて、サーバ装置５０から適宜選択されて取得されることになる。具体的には、通信装置１に接続された各ノード１０の識別情報がサーバ装置５０に送信される。サーバ装置５０では、受信した各ノード１０の識別情報を用いてノード情報ＤＢ５４の照合処理を行ない、通信装置１が各ノード１０から取得可能なデータ種別（内容）を把握する。そして、サーバ装置５０は、把握したこれらデータ種別（内容）に用いてアプリＤＢの照合処理を行ない、通信装置１が利用可能な適当なアプリを選択し、通信装置１に提供（送信）する。そして、通信装置１は提供を受けた（受信した）アプリをコンテナ４２１に記憶し、利用する（コンテナエンジンが当該アプリを実行する）。

【0030】

以上が通信システムＳ（通信装置１）の基本的な構成および機能の概要であるが、次に通信装置１における、コントローラ３および掲示板４１の特徴ある機能について説明する。なお、通信装置１の詳細構成については、後述の図２を用いた説明等で説明する。

【0031】

コンテナエンジン（コントローラ３の処理により実現）は、通信装置１のコンテナに記憶されたアプリを実行する。具体的には、コンテナエンジンは、ノード１０からアプリの実行要求を受け付けた場合に、当該ノード１０に対応するアプリを実行する。そして、コンテナエンジンは、アプリの実行に伴い、アプリが行う処理に必要なデータを掲示板４１から取り込む。そして、コンテナエンジンは、アプリの実行結果により生成された制御データを制御対象のノード１０へ出力する。

【0032】

掲示板４１は、通信装置１の記憶部４に割り当てられた記憶領域で構成され、各ノード１０から取得したデータを記憶する。具体的には、通信装置１は、各ノード１０から取得したデータを、そのまま、あるいは取得元以外の各ノード１０（当該データを必要とするノード１０）によっても使用可能な形式に変換して、掲示板４１に掲載（記憶）する。より具体的には、通信装置１は、ノード１０から取得したデータを各ノード１０が使用できるようにデータの規格を統一して、掲示板４１に掲載（記憶）する。

【0033】

掲示板４１に記憶されるデータは、データの種類に対応したＴＯＰＩＣ毎に分類される。例えば、異なるノード１０からそれぞれ得られた位置情報（ＧＰＳ）のデータについては、位置情報用のＴＯＰＩＣに分類され、異なるノード１０からそれぞれ得られた心拍（HeartRate）のデータは、心拍用のＴＯＰＩＣに分類される。

【0034】

掲示板４１に記憶されたデータは、前述のようにノード１０からアプリ実行要求があった場合に、コンテナエンジンによるアプリ実行に伴いコンテナエンジンに配信され（コンテナエンジンによりアクセスされ）、使用される。また、掲示板４１に記憶されたデータは、ノード１０が自身の持つアプリの実行に伴い、ノード１０に配信され（ノード１０によりアクセスされ）、使用される。

【0035】

制御可否決定機能（コントローラ３の処理により実現）は、車両の状態を示す車両情報に基づいて、コンテナエンジンのアプリ実行により生成された制御データによる制御対象車載器（ノード１０）の制御の可否を決定する。具体的には、制御可否決定機能は、生成した制御データを車載器へ送信するか否かを決定する。

【0036】

ここで、制御可否決定機能について、図１Ｂを用いて説明する。図１Ｂは、実施形態に係るコントローラ３が有する制御可否決定機能を説明する説明図である。なお、図１Ｂでは、車両のパワーウインドウ装置に対してパワーウインドウをオープンする制御を指示する制御データが生成された例を示している。

【0037】

図１Ｂに示すように、コントローラ３は、制御データを生成した場合、車両の状態を示す車両情報と、許可条件ＤＢに登録された許可条件情報とを比較する。車両情報は、例えば、掲示板４１から取り込んだデータである。許可条件ＤＢは、制御データの内容毎の許可条件情報を含むデータベースである。許可条件ＤＢの各データは、通信装置１に新たなアプリの追加があった場合に、サーバ装置５０から新たに追加されたアプリに付加されて提供される当該アプリに関する許可条件情報よって更新される。なお、許可条件ＤＢの各データは、サーバ５０（アプリＤＢ５２）へのアプリ登録に際して、当該登録アプリに付随する情報として、アプリ開発者等により登録される。

【0038】

そして、コントローラ３は、車両の状態が許可条件を満たす場合に、アプリ実行により生成された制御データによる車載器の制御を許可すると判断し、当該制御データを制御対象のノード１０に送信する（送信を許可する）。

【0039】

具体的には、図１Ｂに示す例では、コントローラ３は、制御データ「パワーウインドウ：ＯＰＥＮ」が生成された場合、許可条件ＤＢの中から「パワーウインドウ：ＯＰＥＮ」に対応する許可条件情報である「車速条件：６０Ｋｍ以下の場合許可」、「天候：晴れまたは曇りの場合許可」を取り込む。また、コントローラ３は、許可条件情報に対応する車両情報「車速条件：４０Ｋｍ」、「天候：曇り」を掲示板４１から取り込み、これら情報と許可条件情報を比較する。この場合、許可条件「車速条件：６０Ｋｍ以下の場合許可」、「天候：晴れまたは曇り場合許可」を、車両状態「車速条件：４０Ｋｍ」、「天候：曇り」が満たすので、コントローラ３は、「パワーウインドウ：ＯＰＥＮ」を行っても良いと判断し、「パワーウインドウ：ＯＰＥＮ」の情報（指令信号）をパワーウインドウ装置にＣＧＷ２０を介して送信する。

【0040】

なお、コントローラ３は、車両情報の各データのうち、少なくとも１つのデータが許可条件情報における条件を満たしていない場合には、制御データの送信を行わない、つまり当該制御を禁止する。なお、制御データによっては、車両情報の各データのうち少なくとも１つのデータが許可条件情報における条件を満たしている場合に当該制御を禁止すると言う場合等、制御データに適したいろいろな条件が存在するので、許可条件ＤＢには制御データに応じた各種条件（各種条件の組み合わせ方法も含めた）が記憶されることになる。

【0041】

具体的には、図１Ｂの例において、車両情報における天候のデータが雨であった場合には、当該車両状態が許可条件情報における天候の条件（「天候：晴れ」）を満たさないため、コントローラ３は制御データ「パワーウインドウ：ＯＰＥＮ」のパワーウインドウ装置へ送信を禁止、つまり「パワーウインドウ：ＯＰＥＮ」の制御を禁止する。

【0042】

このように、実施形態に係る通信装置１によれば、車両情報に基づいて、生成した制御データによる制御対象ノード１０（車載器）の制御の可否を決定することで、車両の状態に適していない車載器の制御を回避できる。従って、実施形態に係る通信装置１によれば、車両の状態に応じた車載器の適切な制御を行うことができる。

【0043】

次に、図２を用いて、実施形態に係る通信装置１の構成例について説明する。図２は、実施形態に係る通信装置１の機能構成を示すブロック図である。図２に示すように、通信装置１は、通信部２と、コントローラ３と、記憶部４とを備える。コントローラ３は、取得部３１と、変換部３２と、コンテナエンジン３３と、許可部３４とを備える。記憶部４は、掲示板４１と、コンテナ部４２と、許可条件ＤＢ４３とを備える。

【0044】

通信部２は、上述した通信機能を有し、各ノード１０と通信装置１とを通信可能に接続する。通信部２は、例えば、有線方式であるＣＡＮ、イーサネット（登録商標）、ＬＩＮ（Local Interconnect Network）、ＵＳＢ（Universal Serial Bus）等や、無線方式であるＷｉ-Ｆｉ、ＬＴＥ（Long Term Evolution）、ＢＬＥ（Bluetooth（登録商標） Low Energy）、Ｚｉｇｂｅｅ（登録商標）、ＵＷＢ（Ultra-Wide Band）等によって実現され、各ノード１０と有線または無線により通信を行う。

【0045】

コントローラ３は、たとえば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、フラッシュメモリ、入出力ポートなどを有するコンピュータや各種の回路等により構成される。

【0046】

コンピュータのＣＰＵは、ＲＯＭに記憶されたプログラムを読み出して実行することによって、コントローラ３の取得部３１、変換部３２、コンテナエンジン３３および許可部３４として機能する。

【0047】

また、コントローラ３の取得部３１、変換部３２、コンテナエンジン３３および許可部３４のうち、少なくともいずれか一つまたは全部をＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで構成することもでき、さらに複数のＣＰＵ、ＡＳＩＣ等を機能分担させて（例えば、コンテナエンジン３３を別ＣＰＵで構成する）構成することもできる。

【0048】

また、記憶部４は、ＲＡＭやフラッシュメモリで構成される。記憶部４は、適当な記憶領域設定等により、掲示板４１や、コンテナ部４２、許可条件ＤＢ４３、各種プログラムの記憶部が形成され、各ノード１０の各種センサによる測定データ、アプリ等の各種プログラム、等の各種情報等を記憶することができる。なお、通信装置１は、有線や無線のネットワークで接続された他のコンピュータ、サーバや可搬型記録媒体を介して上記したプログラムや各種情報を取得することとしてもよい。

【0049】

掲示板４１は、ノード１０から取得したデータを掲載（記憶）する。また、掲示板４１は、各ノード１０、コンテナエンジン３３、許可部３４が、データの登録、更新、読み取りができるように、コントローラ３によって適宜アクセス制御が行われる。

【0050】

コンテナ部４２は、記憶部４に割り当てられた記憶領域で構成され、アプリをインストール（記憶）可能な複数のコンテナ４２１を含んで構成されている。各コンテナ４２１には、それぞれ１つのアプリが記憶される形式になっている。つまり、構成されたコンテナ４２１の数だけ、アプリをインストール可能である。アプリは、不図示の外部装置（アプリ提供用の外部サーバ等（図１Ａ図示のサーバ装置５０））から取得され、空のコンテナ４２１（空コンテナ）に設定（記憶）される。また、不要となったアプリはコンテナ４２１から消去され、当該コンテナ４２１は空コンテナとなる。なお、アプリは、不要となった都度コンテナ４２１から消去してもよく、コンテナ４２１に余裕がある場合（空コンテナが別に存在する場合）には、新たなアプリのインストールに空コンテナが必要となった際に不要となったアプリを消去することとしてもよい。

【0051】

許可条件ＤＢ４３は、コンテナ４２１にインストールされたアプリの実行によって生成された制御データによるノード１０の制御を許可するか否かを決定するための許可条件を示す許可条件情報を記憶する。許可条件情報は、コンテナ４２１にアプリをインストールした際に、インストール元である外部装置（サーバ装置５０）から当該アプリに付随して取得され許可条件ＤＢ４３に記憶される。つまり、許可条件情報は、インストール元である外部装置からアプリのプログラムと共に提供され、アプリ（のプログラム）はコンテナ４２１に記憶され、許可条件情報は許可条件ＤＢ４３に記憶される。なお、許可条件ＤＢ４３をコンテナ４２１内に備える構成、つまりコンテナ４２１内にアプリのプログラムと当該アプリの許可条件情報を分離可能（区切り符号データを挟んでプログラムと許可条件情報を記憶し、使用する際に使用する情報を分離して取り出す）に記憶する構成を適用することも可能である。なお、許可条件情報は、車両に組付けられるノード１０の制御に関するものの場合、車両組付け時に作業者の作業により許可条件情報を許可条件ＤＢ４３に記憶させるようにすることもできる。

【0052】

次に、コントローラ３（取得部３１、変換部３２、コンテナエンジン３３および許可部３４）について詳細に説明する。

【0053】

取得部３１は、通信部２を介して、各種外部機器から各種情報を取得する。具体的には、取得部３１は、各種ネットワークにより通信装置１に接続されたノード１０からデータを、通信部２を介して取得する。例えば、取得部３１は、ノード１０が有するセンサで検知されたセンサデータを取得する。

【0054】

また、取得部３１は、ユーザによる端末装置（通信装置１の入力操作機（タッチパネル等）、あるいは通信装置１への操作入力機能を有するノード１０（例えば、通信装置１に通信接続されたユーザの携帯端末（スマートホン等）））へのアプリインストール操作入力に基づき、当該端末装置からアプリをコンテナ４２１にインストールするインストール指示を取得する。また、取得部３１は、ユーザの端末装置等からコンテナ４２１に記憶されたアプリのアップデートを行うアップデート指示を取得する。また、取得部３１は、通信装置１に新たなノード１０が接続された際に、当該ノード１０から当該ノード１０に関する情報、例えば、ノード１０の種別情報、ノード１０との通信接続のための通信接続用情報、ノード１０の有するセンサに関するセンサ情報等を取得する。

【0055】

取得部３１は、外部装置（サーバ装置５０）からインストール対象アプリを取得し、コンテナ４２１に記憶する。具体的には、取得部３１は、インストール指示を取得した場合、あるいは新たなノード１０が接続された場合、アプリを提供する外部装置に接続されたノード１０の情報を送信する。そして、取得部３１は、接続されたノード１０に応じて外部装置から提供されたアプリを取得して、コンテナ４２１に記憶する。なお、取得部３１は、インストールする（コンテナ４２１に記憶する）アプリを、取得部３１が取得したアプリからユーザの選択操作により選択するようにしても良い。あるいは、取得部３１は、アプリ提供前に外部装置から送信される適当なアプリリストからユーザの選択操作に基づきインストールするアプリを選択し、当該選択したアプリの情報を外部装置に送信する。そして、取得部３１は、これに対して外部装置から提供（送信）されたアプリをインストールする（コンテナ４２１に記憶する）方法も適用可能である。

【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】

１ 通信装置
２ 通信部
３ コントローラ
４ 記憶部
１０ ノード
３１ 取得部
３２ 変換部
３３ コンテナエンジン
３４ 許可部
４１ 掲示板
４２ コンテナ部
４３ 許可条件ＤＢ
５０ サーバ装置
４２１ コンテナ
Ｓ 通信システム

【図1A】

【図1B】

【図2】

【図3】