JP2023170483A - 電子制御装置、車両情報提供方法及び車両情報提供プログラム - Google Patents

Abstract

【課題】複数のアプリの個々が所定の通信プロトコルに準拠するデータに基づいた車両情報を容易に且つ適切に利用する装置、方法及びプログラムを提供する。
【解決手段】車両内の電子制御装置のミドルウェア層であるカーデータコーデ１２は、所定の通信プロトコルに準拠するデータフレームからデータを抽出するデータ抽出部１２ａと、データ抽出部により抽出されたデータに基づいて車両情報を生成する車両情報生成部１２ｂと、車両情報生成部により生成された車両情報を保存する車両情報保存部１２ｃと、車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する車両情報提供部１２ｇと、を備える。
【選択図】図４

Description

本発明は、電子制御装置、車両情報提供方法及び車両情報提供プログラムに関する。

車両制御システムにおいて、例えば電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）がＣＡＮ（Controller Area Network）（登録商標）バスに接続されている構成が供されている（例えば特許文献１参照）。

特開２０１１－２１８９７４号公報

ＥＣＵがＣＡＮバスに接続されており、ＥＣＵに搭載されている制御部が複数のアプリを実行する場合には、それら複数のアプリの個々がＣＡＮフレームからＣＡＮデータを抽出し、その抽出したＣＡＮデータに基づいて車両情報を生成する。しかしながら、複数のアプリの個々が車両情報を別々に生成する構成では、車両情報を生成するためのプログラムモジュールをアプリ毎に用意する必要があり、アプリを制作するに際してコスト増大や多大な手間が発生する等の問題がある。又、アプリ毎のプログラムモジュールを保存するためのストレージのメモリ容量を無駄に消費することになる。更に、ＣＡＮデータに基づいて車両情報を生成するロジックがアプリ間で異なると、同一のＣＡＮデータから異なる車両情報を生成してしまう虞があり、その異なった車両情報を利用してしまうと、アプリ間の動作で不具合が発生する虞もある。

本発明は、上記した事情に鑑みてなされたものであり、その目的は、複数のアプリの個々が所定の通信プロトコルに準拠するデータに基づいた車両情報を容易に且つ適切に利用することができる電子制御装置、車両情報提供方法及び車両情報提供プログラムを提供することにある。

請求項１に記載した発明によれば、複数のアプリを実行する制御部（６）を備える。データ抽出部（１２ａ）は、所定の通信プロトコルに準拠するデータフレームからデータを抽出する。車両情報生成部（１２ｂ）は、データ抽出部により抽出されたデータに基づいて車両情報を生成する。車両情報保存部（１２ｃ）は、車両情報生成部により生成された車両情報を保存する。車両情報提供部（１２ｇ）は、車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する。

所定の通信プロトコルに準拠するデータフレームからデータを抽出し、その抽出したデータに基づいて車両情報を生成して保存し、その保存している車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供するようにした。

車両情報を生成するためのプログラムモジュールをアプリ毎に用意する必要がなくなり、アプリを制作するに際してコスト増大や多大な手間の発生を抑えることができ、ストレージのメモリ容量の消費を抑えることもできる。更に、所定の通信プロトコルに準拠する同一のデータから異なる車両情報を生成してしまう虞がなくなり、アプリ間の動作で不具合が発生する虞もなくなる。これにより、複数のアプリの個々が所定の通信プロトコルに準拠するデータに基づいた車両情報を容易に且つ適切に利用することができる。

本開示は、特許請求の範囲に記載の発明に加え、以下のような発明を含む。
［１］
複数のアプリを実行する制御部（６）を備える電子制御装置（１）であって、
所定の通信プロトコルに準拠するデータフレームからデータを抽出するデータ抽出部（１２ａ）と、
前記データ抽出部により抽出されたデータに基づいて車両情報を生成する車両情報生成部（１２ｂ）と、
前記車両情報生成部により生成された車両情報を保存する車両情報保存部（１２ｃ）と、
前記車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する車両情報提供部（１２ｇ）と、を備える電子制御装置。

［２］
前記複数のアプリの個々からの登録要求を受け付ける登録要求受け付け部（１２ｄ）を備え、
前記車両情報提供部は、前記車両情報保存部により保存されている車両情報を、登録要求が前記登録要求受け付け部により受け付けられたアプリへ提供する［１］に記載した電子制御装置。

［３］
前記車両情報保存部により保存されている車両情報の更新有無を判定する更新有無判定部（１２ｅ）を備え、
前記車両情報提供部は、前記車両情報保存部により保存されている車両情報が前記更新有無判定部により更新されたことを契機とし、前記車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する［１］又は［２］に記載した電子制御装置。

［４］
前記複数のアプリの個々からの提供要求を受け付ける提供要求受け付け部（１２ｆ）を備え、
前記車両情報提供部は、アプリからの提供要求が前記提供要求受け付け部により受け付けられたことを契機とし、前記車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する［１］から［３］の何れか一項に記載した電子制御装置。

［５］
前記データ抽出部、前記車両情報生成部、前記車両情報保存部及び前記車両情報提供部は、前記制御部により実行される［１］から［４］の何れか一項に記載した電子制御装置。

［６］
前記車両情報提供部は、異なる粒度の車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する［１］から［５］の何れか一項に記載した電子制御装置。

一実施形態を示す機能ブロック図 プロトコル変換を説明する図 ＣＡＮフレームの受信時の流れを示す図 カーデータコーデの機能ブロック図 車両情報の生成時の流れを示す図 ＣＡＮデータ及び車両情報を示す図 車両情報リストを示す図 車両情報リストを示す図 車両情報リストを示す図 サービス提供リストを示す図 登録要求受け付け処理を示すフローチャート 車両情報保存処理を示すフローチャート 更新時処理を示すフローチャート 提供要求受け付け処理を示すフローチャート シーケンス図 シーケンス図 シーケンス図 シーケンス図

以下、一実施形態について図面を参照して説明する。図１に示すように、車両に搭載されているマスタＥＣＵ１は、例えばパワトレＥＣＵ、ボデーＥＣＵ、コックピットＥＣＵ、シャシＥＣＵ、セーフティＥＣＵ等から情報を取得し、又は各ＥＣＵに指示することで車両を制御する。これを実現するために、マスタＥＣＵ１は、複数のアプリと、複数のミドルウェアとを備える。マスタＥＣＵ１は、例えば機能向上や不具合改修等を目的としたリプロの実施を管理する更新マスタとして機能する。

マスタＥＣＵ１は、ＣＡＮバス２（Controller Area Network）（登録商標）（通信バスに相当する）を介して複数のＥＣＵ３，４とデータ通信可能に接続されており、動作指示を複数のＥＣＵ３，４へ指示したり複数のＥＣＵ３，４から動作状態を取得したりすることで、複数のＥＣＵ３，４を統合管理する。マスタＥＣＵ１とＣＡＮバス２を介して接続されるＥＣＵの個数は、２個に限らず任意である。複数のＥＣＵ３，４は、例えばパワトレＥＣＵ、ボデーＥＣＵ、コックピットＥＣＵ、シャシＥＣＵ、セーフティＥＣＵ等である。

マスタＥＣＵ１は、データ通信機として機能するＤＣＭ（Data Communication Module）と接続されている。ＤＣＭは、外部と通信ネットワークを介して無線接続することでデータを送受信可能とする。ＤＣＭは、ＯＴＡセンターと通信ネットワークを介して無線接続することで当該ＯＴＡセンターから送信された配信パッケージを受信可能となる。ＤＣＭは、ＯＴＡセンターから送信された配信パッケージを受信すると、その受信した配信パッケージをマスタＥＣＵ１へ転送する。マスタＥＣＵ１は、複数のＥＣＵの中からリプロ対象として機能するリプロ対象ＥＣＵを特定し、ＤＣＭから配信パッケージが転送されると、その転送された配信パッケージから更新プログラムを抽出し、その抽出した更新プログラムの書き込みをリプロ対象ＥＣＵへ指示することでリプロを実施する。

マスタＥＣＵ１は、第１制御部５と、第２制御部６（制御部に相当する）と、ストレージ７とを備える。第１制御部５及び第２制御部６は、それぞれＣＰＵ（Central Processing Unit）を有するマイクロコンピュータにより構成されている。マスタＥＣＵ１は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）及びＩ／Ｏ（Input／Output）を有する。第１制御部５及び第２制御部６は、それぞれ非遷移的実体的記憶媒体に格納されている制御プログラムを実行することで当該制御プログラムに対応する処理を実行し、連携してマスタＥＣＵ１の動作全般を制御する。第２制御部６が実行する制御プログラムは車両情報提供プログラムを含む。

第１制御部５は、ＣＡＮバス２を介してＥＣＵ３，４に接続されており、ＣＡＮプロトコル（所定の通信プロトコルに相当する）に準拠するデータ通信をＥＣＵ３，４との間で行う。第１制御部５と第２制御部６とは、イーサーネット８を介して接続されており、イーサーネットプロトコルに準拠するデータ通信を両者の間で行う。即ち、第１制御部５は、ＣＡＮバス２に直接接続されている。第２制御部６は、ＣＡＮバス２に直接接続されておらず、イーサーネット８を介してＣＡＮバス２に接続されている。イーサーネットプロトコルによるデータ通信は、ＣＡＮプロトコルによるデータ通信よりも高速大容量である。第１制御部５と第２制御部６は複数のＣＰＵに相当する。

マスタＥＣＵ１のハードウェアアーキテクチャにおいて、第１ＣＰＵは、ＣＡＮバス２に接続されており、ＣＡＮバス２に直接アクセスする構成となっており、第２ＣＰＵは、ＣＡＮバス２に接続されておらず、ＣＡＮバス２に直接アクセスしない構成となっている。同一の基盤内において、第２ＣＰＵは、第１ＣＰＵとイーサーネットによりデータ通信可能に接続されている。尚、複数のＣＰＵの代わりに、同じ機能をソフトウェアにて実現している仮想マシンでも良い。

ストレージ７は、例えばＮＯＲ型フラッシュメモリやＮＡＮＤ型フラッシュメモリを主体とする不揮発性メモリであり、第１制御部５や第２制御部６により実行される複数のアプリで共有される。即ち、複数のアプリがそれぞれストレージ７にアクセスしてデータの書き込み及びデータの読み出しを実施する。本実施形態では、ストレージ７がマスタＥＣＵ１に内蔵されている構成を例示しているが、ストレージ７がマスタＥＣＵ１の外部に配置されている構成に適用することも可能である。又、第１制御部５や第２制御部６により実行される複数のアプリでストレージ７を共有する構成を例示しているが、マスタＥＣＵ１とデータ通信可能に接続されている別のＥＣＵの制御部により実行されるアプリでストレージ７を共有しても良い。

アプリ層９に属する各アプリ９ａは、車両に関する情報を要求する場合に、要求する情報の粒度に応じてミドルウェア層１０に属するＣＡＮサービス１１、カーデータコーデ１２、シーンコーデ１３の何れかに情報の送信を要求する。ＣＡＮサービス１１、カーデータコーデ１２、シーンコーデ１３には、それぞれ情報を提供可能となるようにアプリケーションプログラミングインタフェース（以下、ＡＰＩ（Application Programming Interface）と称する）が設定されている。

第１制御部５は、上記したようにＣＡＮバス２に直接接続されているので、ＣＡＮプロトコルに準拠したデータであるＣＡＮデータを含むＣＡＮフレームの送受信を制御する機能を有する。又、第１制御部５は、ＣＡＮフレームをイーサーネットフレームへプロトコル変換する機能を有する。即ち、図２に示すように、第１制御部５は、ＣＡＮバス２からＣＡＮフレームを受信すると、その受信したＣＡＮフレームをイーサーネットフレームへプロトコル変換し、そのプロトコル変換したイーサーネットフレームをＣＡＮサービス１１へ送信する。

図３に示すように、ＣＡＮサービス１１は、第１制御部５から送信されたイーサーネットフレームを受信すると、その受信したイーサーネットフレームからＣＡＮプロトコルデータユニット（以下、ＰＤＵ（Protocol Data Unit）と称する）を抽出し、その抽出したＣＡＮＰＤＵをカーデータコーデ１２へ送信する。ＰＤＵは、送受信される情報の単位であり、通信プロトコルで定義されている制御情報の部分と、データの中身であるペイロードとを含む。ＣＡＮフレームのＩＤ、コントロールフィールド、データフィールドがそれぞれイーサーネットフレームのＣＡＮＩＤ、ＤＬＣ、ＣＡＮデータに対応する。

カーデータコーデ１２は、ＣＡＮサービス１１から送信されたＣＡＮＰＤＵを受信すると、その受信したＣＡＮＰＤＵに基づいて車両情報を生成し、その生成した車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する機能を有する。以下、カーデータコーデ１２の構成について図４及び図５を参照して説明する。カーデータコーデ１２は、データ抽出部１２ａと、車両情報生成部１２ｂと、車両情報保存部１２ｃと、登録要求受け付け部１２ｄと、更新有無判定部１２ｅと、提供要求受け付け部１２ｆと、車両情報提供部１２ｇとを備える。これらのカーデータコーデ１２の動作を制御する各部１２ａ～１２ｇは、第２制御部６により実行される。

データ抽出部１２ａは、ＣＡＮサービス１１から送信されたＣＡＮＰＤＵを受信すると、その受信したＣＡＮＰＤＵからＣＡＮデータを抽出する。ＣＡＮデータは、ＣＡＮの通信プロトコルに準拠するデータ形式である。車両情報生成部１２ｂは、ＣＡＮデータがデータ抽出部１２ａにより抽出されると、その抽出されたＣＡＮデータを解釈して車両情報を生成する。図６に示すように、車両情報生成部１２ｂは、例えば車速が「６０ｋｍ／ｈ」であるときのＣＡＮデータが「０１ ２３ ４５ ６７ ａｂ ・・・・」であれば、車両情報として車速「６０ｋｍ／ｈ」を示すデータを生成する。車両情報として生成されるデータは、ＣＡＮデータから一義的に特定されるデータである。例えば車両情報として生成されるデータは、ＣＡＮデータよりも少ないデータ量で表現されるデータである。

車両情報保存部１２ｃは、車両情報が車両情報生成部１２ｂにより生成されると、その生成された車両情報を、図７に示す車両情報リストに保存可能である。この場合、車両情報保存部１２ｃは、未だ車両情報が保存されていない場合には、今回の生成された車両情報を新規保存する。車両情報保存部１２ｃは、車両情報が既に保存されているが今回の生成された車両情報が当該既に保存されている車両情報と一致しない場合には、今回の生成された車両情報を上書き保存する。一方、車両情報保存部１２ｃは、車両情報が既に保存されており、今回の生成された車両情報が当該既に保存されている車両情報と一致する場合には、今回の生成された車両情報を保存せずに破棄する。

車両情報リストに保存される車両情報は、上記した車速の他に、スマートキーの有無、ハザード状態、運転席ドア、燃料消費量、ＩＧリレー状態、オドメータの数値、車両位置、日付に関する情報がある。各車両情報の内容は以下の通りある。

「スマートキーの有無」：スマートキーの有無に関する情報であり、キーが車内に存在する場合は「Ｔｒｕｅ」であり、キーが車内に存在しない場合は「Ｆａｌｓｅ」である。
「ハザード状態」：ハザードランプの状態に関する情報であり、点滅状態の場合は「オン」であり、消灯状態の場合は「オフ」である、
「運転席ドア」：運転席ドアに関する情報であり、運転席のドアが開状態の場合は「開状態」であり、運転席のドアが閉状態でロック状態である場合は「ロック」であり、運転席のドアが閉状態でアンロック状態である場合は「アンロック」である。
「燃料消費量」：燃料消費量に関する情報であり、「０ｍｌ」～「３２ｍｌ」の数値である。
「ＩＧリレー状態」：ＩＧリレーの駆動状態に関する情報であり、ＩＧリレーがオン状態の場合は「オン」であり、ＩＧリレーがオフ状態の場合は「オフ」である。
「オドメータの数値」、オドメータの数値に関する情報であり、オドメータに表示される距離情報である。
「車速」：車速に関する情報であり、車速パルス信号の積算値であってパルスのカウンタ数により特定される情報である。
「車両位置」：車両位置に関する情報である、ナビゲーション装置により特定される緯度経度である。
「日付」：日付に関する情報であり、年、月、日、時、分、秒により特定される情報である。

尚、車両情報保存部１２ｃは、タイムスタンプを付与して車両情報を保存しても良い。図８に示すように、車両情報保存部１２ｃは、例えば「スマートキーの有無」についてキーが車内に存在するか否かの状態が更新される毎にタイプスタンプを付与しても良い。タイムスタンプを付与することで、スマートキーの有無に関する履歴を保存することができ、スマートキーの有無に関する過去の車両情報を遡って取得することが可能となる。又、図９に示すように、車両情報保存部１２ｃは、例えば「ハザード状態」についてハザードランプの点滅状態と消灯状態とが更新される毎にタイプスタンプを付与しても良い。タイムスタンプを付与することで、ハザード状態に関する履歴を保存することができ、ハザード状態に関する過去の車両情報を遡って取得することが可能となる。「スマートキーの有無」及び「ハザード状態」以外の車両情報についても同様である。

登録要求受け付け部１２ｄは、複数のアプリ９ａの個々からの登録要求を受け付け、その受け付けた登録要求をサービス提供リストに登録する。登録要求は、車両情報の提供を受けたいアプリ９ａが、アプリ９ａを示すアプリＩＤと、提供を受けたい車両情報種別とを対応付けて登録する要求である。図１０に示すように、登録要求受け付け部１２ｄは、例えばアプリＡから車両情報種別として「スマートキーの有無」の登録要求を受け付けると、アプリＡのアプリＩＤと「スマートキーの有無」とを対応付けて登録する。登録要求受け付け部１２ｄは、アプリＢから車両情報種別として「車速」及び「車両位置」の登録要求を受け付けると、アプリＢのアプリＩＤと「車速」及び「車両位置」とを対応付けて登録する。尚、登録要求受け付け部１２ｄは、他のミドルウェアをアプリ９ａと同様に扱うことで、他のミドルウェアからの登録要求を受け付け、その受け付けた登録要求をサービス提供リストに登録しても良い。

更新有無判定部１２ｅは、車両情報保存部１２ｃにより保存されている車両情報の更新有無を判定する。更新有無判定部１２ｅは、今回の生成された車両情報が車両情報保存部１２ｃにより新規保存された、又は上書き保存された場合に、車両情報保存部１２ｃにより保存されている車両情報の更新有を判定する。即ち、更新有無判定部１２ｅは、ＣＡＮデータが更新されたことに応じて車両情報が車両情報保存部１２ｃにより新規保存された、又は上書き保存される都度、車両情報の更新有を判定する。換言すると、車両情報保存部１２ｃは、常時最新の車両情報を保存する。

提供要求受け付け部１２ｆは、複数のアプリ９ａの個々からの車両情報の提供要求を受け付ける。車両情報提供部１２ｇは、車両情報保存部１２ｃにより保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリ９ａへ提供する。この場合、車両情報提供部１２ｇは、異なる粒度の車両情報を、当該車両情報の提供を要求した要求元のアプリ９ａへ提供することが可能である。即ち、アプリ９ａは、任意の粒度の車両情報を取得することが可能である。車両情報提供部１２ｇが車両情報を提供する場合としては、車両情報の更新有が更新有無判定部１２ｅにより判定されたことを契機とする場合と、アプリ９ａからの車両情報の提供要求が提供要求受け付け部１２ｆにより受け付けられたことを契機とする場合とがある。

次に、上記した構成の作用について図１１から図１８を参照して説明する。マスタＥＣＵ１において、カーデータコーデ１２が行う登録要求受け付け処理、車両情報保存処理、更新時処理、提供要求受け付け処理について順次説明する。

（１）登録要求受け付け処理（図１１参照）
カーデータコーデ１２は、アプリ９ａからの登録要求を受け付けたことで登録要求受け付け処理の開始条件が成立すると、登録要求受け付け処理を開始する。カーデータコーデ１２は、登録要求受け付け処理を開始すると、アプリ９ａから通知されたアプリＩＤと車両情報種別を取得する（Ｓ１）。カーデータコーデ１２は、その取得したアプリＩＤと車両情報種別とを対応付けてサービス提供リストに登録し（Ｓ２）、登録要求受け付け処理を終了する。

（２）車両情報保存処理（図１２参照）
カーデータコーデ１２は、ＣＡＮサービス１１からＣＡＮＰＤＵを受信したことで車両情報保存処理の開始条件が成立すると、車両情報保存処理を開始する。カーデータコーデ１２は、車両情報保存処理を開始すると、その受信したＣＡＮＰＤＵからＣＡＮデータを抽出する（Ｓ１１、データ抽出手順に相当する）。カーデータコーデ１２は、その抽出したＣＡＮデータを解釈して車両情報を生成する（Ｓ１２、車両情報生成手順に相当する）。カーデータコーデ１２は、車両情報リストを参照し（Ｓ１３）、今回の生成した車両情報を保存対象とするか否かを判定する（Ｓ１４）。

カーデータコーデ１２は、未だ車両情報を保存していない、又は車両情報を既に保存しているが今回の生成した車両情報が当該既に保存している車両情報と一致しないと判定すると、今回の生成した車両情報を保存対象とすると判定し（Ｓ１４：ＹＥＳ）、今回の生成した車両情報を車両情報リストに保存し（Ｓ１５、車両情報保存手順に相当する）、車両情報保存処理を終了する。カーデータコーデ１２は、例えば今回の車両情報として車速「６０ｋｍ／ｈ」を生成した場合に、車両情報リストの「車速」の保存領域が空である、又は車両情報リストの「車速」の保存領域に既に保存している車両情報が車速「６０ｋｍ／ｈ」以外であり、前回から車両情報が更新されていると、今回の車両情報として生成した車速「６０ｋｍ／ｈ」を車両情報リストに保存する。

一方、カーデータコーデ１２は、車両情報を既に保存しており、今回の生成した車両情報が当該既に保存している車両情報と一致すると判定すると、今回の生成した車両情報を保存対象としないと判定し（Ｓ１４：ＮＯ）、今回の生成した車両情報を車両情報リストに保存せずに廃棄し（Ｓ１６）、車両情報保存処理を終了する。カーデータコーデ１２は、例えば今回の車両情報として車速「６０ｋｍ／ｈ」を生成した場合に、車両情報リストの「車速」の保存領域に既に保存している車両情報が車速「６０ｋｍ／ｈ」であり、前回から車両情報が更新されていないと、今回の車両情報として生成した車速「６０ｋｍ／ｈ」を車両情報リストに保存せずに破棄する。

（３）更新時処理（図１３参照）
カーデータコーデ１２は、上記した車両情報保存処理において車両情報が更新され、今回の生成した車両情報を車両情報リストに保存したことで更新時処理の開始条件が成立すると、更新時処理を開始する。カーデータコーデ１２は、更新時処理を開始すると、サービス提供リストを参照し（Ｓ２１）、更新対象となった車両情報に対応付けられている当該車両情報の提供先のアプリ９ａを特定する（Ｓ２２）。カーデータコーデ１２は、車両情報の提供先のアプリ９ａを特定すると、車両情報リストを参照し（Ｓ２３）、車両情報リストに保存されている車両情報を、その車両情報の提供先として特定したアプリ９ａへ提供し（Ｓ２４、車両情報提供手順に相当する）、更新時処理を終了する。即ち、カーデータコーデ１２は、車両情報の最新値を、車両情報の提供先として特定したアプリ９ａへ提供する。

カーデータコーデ１２は、図１０に示したサービス提供リストにおいて、例えば今回の生成した車両情報が「車速」である場合には、「車速」に対応付けられているアプリＢを車両情報の提供先として特定し、「車速」の最新値をアプリＢへ提供する。同様に、カーデータコーデ１２は、図１０に示したサービス提供リストにおいて、今回の生成した車両情報が「車両位置」である場合には、「車両位置」に対応付けられているアプリＢ，Ｄを車両情報の提供先として特定し、「車両位置」の最新値をアプリＢ，Ｄへ提供する。

（４）提供要求受け付け処理（図１４参照）
カーデータコーデ１２は、アプリ９ａからの提供要求を受け付けたことで提供要求受け付け処理の開始条件が成立すると、提供要求受け付け処理を開始する。カーデータコーデ１２は、提供要求受け付け処理を開始すると、アプリ９ａから通知されたアプリＩＤと指定車両情報を取得する（Ｓ３１）。カーデータコーデ１２は、その取得したアプリＩＤに基づいて車両情報の提供先のアプリ９ａを特定し（Ｓ３２）、その取得した指定車両情報に基づいて提供先のアプリ９ａへ提供する車両情報種別を特定する（Ｓ３３）。カーデータコーデ１２は、車両情報リストを参照し（Ｓ３４）、その特定した車両情報種別に対応する車両情報を、その車両情報の提供先として特定したアプリ９ａへ提供し（Ｓ３５、車両情報提供手順に相当する）、提供要求受け付け処理を終了する。

カーデータコーデ１２は、例えばアプリＸが「スマートキーの有無」の提供要求を通知した場合には、アプリＸを車両情報の提供先として特定し、「スマートキーの有無」の最新値をアプリＸへ提供する。

次に、ＣＡＮサービス１１及びカーデータコーデ１２が連携して行う処理について図１５から図１８を参照して説明する。カーデータコーデ１２は、例えばマスタＥＣＵ１が起動すると、オープン指示をＣＡＮサービス１１へ通知する（ｔ１）。ＣＡＮサービス１１は、カーデータコーデ１２からオープン指示が通知されると、その通知されたオープン指示に対する応答をカーデータコーデ１２へ通知し（ｔ２）、一時的なデータ記憶領域を作成する。

カーデータコーデ１２は、セットＩＤフィルタ指示をＣＡＮサービス１１へ通知する（ｔ３）。ＣＡＮサービス１１は、カーデータコーデ１２からセットＩＤフィルタ指示が通知されると、その通知されたセットＩＤフィルタ指示に対する応答をカーデータコーデ１２へ通知し（ｔ４）、その通知されたセットＩＤフィルタ指示により指定されたＩＤを保持する。

ＣＡＮサービス１１は、第１制御部５からイーサーネットフレームを受信すると（ｔ５）、その保持しているＩＤと、その受信したイーサーネットフレームに格納されているＣＡＮＩＤとを照合する。ＣＡＮサービス１１は、その保持しているＩＤと一致するＣＡＮＩＤを格納しているイーサーネットフレームを特定すると、その特定したイーサーネットフレームからＣＡＮＰＤＵを抽出し、その抽出したＣＡＮＰＤＵをデータ記憶領域に保存する。ＣＡＮサービス１１は、その保持しているＩＤと一致しないＣＡＮＩＤを格納しているイーサーネットフレームを特定すると、その特定したイーサーネットフレームからＣＡＮＰＤＵを抽出せずに破棄する。これ以降、ＣＡＮサービス１１は、第１制御部５からイーサーネットフレームを受信する都度（ｔ１０，ｔ１４，ｔ１７）、上記した処理を繰り返す。

カーデータコーデ１２は、アプリ９ａから登録要求が通知されると（ｔ６）、上記した図１１で説明した登録要求受け付け処理を実施する。カーデータコーデ１２は、その通知された登録要求により指定されているアプリＩＤと車両情報種別を取得し、その取得したアプリＩＤと車両情報種別とを対応付けてサービス提供リストに登録する。

カーデータコーデ１２は、リード指示をＣＡＮサービス１１へ所定周期（例えば数ミリ秒周期）で通知する（ｔ７）。ＣＡＮサービス１１は、カーデータコーデ１２からリード指示が通知されると、データ記憶領域に保存しておいたＣＡＮＰＤＵをカーデータコーデ１２へ通知する（ｔ８）。カーデータコーデ１２は、ＣＡＮサービス１１からＣＡＮＰＤＵを取得すると、上記した図１２で説明した車両情報保存処理を実施する。カーデータコーデ１２は、その取得したＣＡＮＰＤＵからＣＡＮデータを抽出し、その抽出したＣＡＮデータを解釈して車両情報を生成し、車両情報リストを参照し、今回の生成した車両情報を保存対象とするか否かを判定する。これ以降、カーデータコーデ１２及びＣＡＮサービス１１は、カーデータコーデ１２がリード指示を通知する周期で上記した処理を繰り返す（ｔ１１，ｔ１２，ｔ１５，ｔ１６，ｔ１８，ｔ１９）。

カーデータコーデ１２は、車両情報が更新されていないと判定すると、今回の生成した車両情報を車両情報リストに保存せずに廃棄する。一方、カーデータコーデ１２は、車両情報が更新されていると判定すると、今回の生成した車両情報を車両情報リストに保存し、上記した図１３で説明した更新時処理を実施する。カーデータコーデ１２はサービス提供リストを参照し、車両情報の提供先のアプリ９ａを特定し、車両情報リストを参照し、車両情報リストに保存されている車両情報、即ち、車両情報の最新値を、その車両情報の提供先として特定したアプリ９ａへ通知する（ｔ９、ｔ１３，ｔ２０）。

図１７及び図１８の例示では、アプリ９ａから通知された登録要求により車両情報種別として「車速」が指定されている場合を示している。この場合、カーデータコーデ１２は、アプリ９ａから登録要求が通知された直後の最初にＣＡＮサービス１１から取得したＣＡＮＰＤＵに基づいて生成した車両情報をアプリ９ａへ通知する（ｔ９）。これ以降、カーデータコーデ１２は、例えばＣＡＮサービス１１から「ｔ８」のタイミングで取得したＣＡＮＰＤＵに基づいて生成した車両情報が車速「５８ｋｍ／ｈ」であり、ＣＡＮサービス１１から「ｔ１２」のタイミングで取得したＣＡＮＰＤＵに基づいて生成した車両情報が車速「６０ｋｍ／ｈ」であると、車両情報が前回から更新されているので、車両情報として車速「６０ｋｍ／ｈ」をアプリ９ａへ通知する（ｔ１３）。

カーデータコーデ１２は、ＣＡＮサービス１１から「ｔ１６」のタイミングで取得したＣＡＮＰＤＵに基づいて生成した車両情報が車速「６０ｋｍ／ｈ」であると、車両情報が前回から更新されていないので、車両情報をアプリ９ａへ通知せずに破棄する。カーデータコーデ１２は、ＣＡＮサービス１１から「ｔ１９」のタイミングで取得したＣＡＮＰＤＵに基づいて生成した車両情報が車速「６２ｋｍ／ｈ」であると、車両情報が前回から更新されているので、車両情報として車速「６２ｋｍ／ｈ」をアプリ９ａへ通知する（ｔ２０）。以上は、車両情報種別として「車速」が指定されている場合を説明したが、他の車両情報種別でも同様である。

以上に説明したように本実施形態によれば、次に示す作用効果を得ることができる。
マスタＥＣＵ１において、ＣＡＮフレームからＣＡＮデータを抽出し、その抽出したＣＡＮデータに基づいて車両情報を生成して保存し、その保存している車両情報を、当該車両情報の提供を要求した要求元のアプリ９ａへ提供するようにした。車両情報を生成するためのプログラムモジュールをアプリ毎に用意する必要がなくなり、アプリ９ａを制作するに際してコスト増大や多大な手間の発生を抑えることができ、ストレージ７のメモリ容量の消費を抑えることもできる。更に、同一のＣＡＮデータから異なる車両情報を生成してしまう虞がなくなり、アプリ９ａ間の動作で不具合が発生する虞もなくなる。これにより、複数のアプリ９ａの個々がＣＡＮデータに基づいた車両情報を容易に且つ適切に利用することができる。

マスタＥＣＵ１において、保存している車両情報が更新されたことを契機とし、その保存している車両情報を、当該車両情報の提供を要求した要求元のアプリ９ａへ提供するようにした。車両情報が更新されたタイミングで、最新の車両情報をアプリ９ａへ提供することができる。即ち、アプリ９ａが提供要求を通知することなく、最新の車両情報をアプリ９ａへ提供することができる。

マスタＥＣＵ１において、アプリ９ａからの提供要求が受け付けられたことを契機とし、その保存している車両情報を、当該車両情報の提供を要求した要求元のアプリ９ａへ提供するようにした。車両情報が前回から更新されたか否かに関係なく、アプリ９ａが提供要求を通知する任意のタイミングで、最新の車両情報をアプリ９ａへ提供することができる。

マスタＥＣＵ１において、ＣＡＮバス２から受信したＣＡＮフレームをイーサーネットフレームへプロトコル変換し、そのプロトコル変換したイーサーネットフレームからＣＡＮデータを抽出するようにした。ＣＡＮバス２に直接接続されていない第２制御部６により実行されるアプリ９ａを対象とし、複数のアプリ９ａの個々がＣＡＮデータに基づいた車両情報を容易に且つ適切に利用することができる。

本開示は、実施例に準拠して記述されたが、当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、更には、それらに一要素のみ、それ以上、或いはそれ以下を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することにより提供された専用コンピュータにより実現されても良い。或いは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によりプロセッサを構成することにより提供された専用コンピュータにより実現されても良い。若しくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路により構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより実現されても良い。又、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていても良い。

図面中、１はマスタＥＣＵ（電子制御装置）、５は第１制御部、６は第２制御部（制御部）、１２はカーデータコーデ、１２ａはデータ抽出部、１２ｂは車両情報生成部、１２ｃは車両情報保存部、１２ｄは登録要求受け付け部、１２ｅは更新有無判定部、１２ｆは提供要求受け付け部、１２ｇは車両情報提供部である。

Claims (8)

1. 複数のアプリを実行する制御部（６）を備える電子制御装置（１）であって、
   所定の通信プロトコルに準拠するデータフレームからデータを抽出するデータ抽出部（１２ａ）と、
   前記データ抽出部により抽出されたデータに基づいて車両情報を生成する車両情報生成部（１２ｂ）と、
   前記車両情報生成部により生成された車両情報を保存する車両情報保存部（１２ｃ）と、
   前記車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する車両情報提供部（１２ｇ）と、を備える電子制御装置。
2. 前記複数のアプリの個々からの登録要求を受け付ける登録要求受け付け部（１２ｄ）を備え、
   前記車両情報提供部は、前記車両情報保存部により保存されている車両情報を、登録要求が前記登録要求受け付け部により受け付けられたアプリを当該車両情報の提供を要求した要求元のアプリとして提供する請求項１に記載した電子制御装置。
3. 前記車両情報保存部により保存されている車両情報の更新有無を判定する更新有無判定部（１２ｅ）を備え、
   前記車両情報提供部は、前記車両情報保存部により保存されている車両情報が前記更新有無判定部により更新有と判定されたことを契機とし、前記車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する請求項１に記載した電子制御装置。
4. 前記複数のアプリの個々からの提供要求を受け付ける提供要求受け付け部（１２ｆ）を備え、
   前記車両情報提供部は、アプリからの提供要求が前記提供要求受け付け部により受け付けられたことを契機とし、前記車両情報保存部により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する請求項１に記載した電子制御装置。
5. 前記データ抽出部、前記車両情報生成部、前記車両情報保存部及び前記車両情報提供部は、前記制御部により実行される請求項１に記載した電子制御装置。
6. 前記車両情報提供部は、異なる粒度の車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する請求項１に記載した電子制御装置。
7. 複数のアプリを実行する制御部（６）を備える電子制御装置（１）において、
   所定の通信プロトコルに準拠するデータフレームからデータを抽出するデータ抽出手順と、
   前記データ抽出手順により抽出したデータに基づいて車両情報を生成する車両情報生成手順と、
   前記車両情報生成手順により生成した車両情報を保存する車両情報保存手順と、
   前記車両情報保存手順により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する車両情報提供手順と、を行う車両情報提供方法。
8. 複数のアプリを実行する制御部（６）を備える電子制御装置（１）に、
   所定の通信プロトコルに準拠するデータフレームからデータを抽出するデータ抽出手順と、
   前記データ抽出手順により抽出したデータに基づいて車両情報を生成する車両情報生成手順と、
   前記車両情報生成手順により生成した車両情報を保存する車両情報保存手順と、
   前記車両情報保存手順により保存されている車両情報を、当該車両情報の提供を要求した要求元のアプリへ提供する車両情報提供手順と、を実行させる車両情報提供プログラム。

Images