WO2023228779A1

WO2023228779A1 - 車両制御システム、車両制御プログラム、位置確認装置

Info

Publication number: WO2023228779A1
Application number: PCT/JP2023/017908
Authority: WO
Inventors: 康平二村; 竜介石川
Original assignee: 株式会社デンソー
Priority date: 2022-05-26
Filing date: 2023-05-12
Publication date: 2023-11-30
Also published as: JP2023173767A

Abstract

統括ＥＣＵ（４１）は、ユーザによって施錠操作が行われたことを検出すると、各認証ＥＣＵ（６ｘ）に向けて、車外近傍エリアとキャビン内の２つのエリアを探索対象エリアと指定し、且つ、全てのユーザを探索対象に指定した認証要求パケットを、各認証ＥＣＵ（６ｘ）に送信する。各認証ＥＣＵ（６ｘ）は、受信した要求内容をもとに自装置の認証方式、位置判定方式に応じた態様で、ターゲットの探索を実施し、その結果を統括ＥＣＵ（４１）に返送する。

Description

車両制御システム、車両制御プログラム、位置確認装置

関連出願の相互参照

　この出願は、２０２２年５月２６日に日本に出願された特許出願第２０２２－０８６２３８号を基礎としており、基礎の出願の内容を、全体的に、参照により援用している。

　本開示は、ユーザ又はキーデバイスが車両の所定エリアに存在することが確認できていることを条件に車両の施錠や開錠といった車両制御を実施する技術に関する。

　電子キーに加えて、スマートフォンなどの汎用的な携帯デバイスを、キーデバイスとして使用可能な車載システムがある。ここでの電子キーとは、車両の鍵としての機能を備える専用的なデバイスであって、キーフォブ、スマートキー、キーカードなどと呼ばれうる。キーデバイスとは、車両の鍵として機能するデバイスであって、車両を使用しようとする人物の正当性を証明するためのデバイスである。車載システムは、所定エリアにキーデバイスが存在することを確認できていることを条件として、施錠又は開錠を実施する。

　スマートキーが所定エリアに存在することの確認処理は、特許文献１に開示されているように車両の複数箇所に設置されたＬＦ（Low Frequency）アンテナを用いて電子キーと通信することによって実現される事が多い。また、携帯デバイスの位置確認は、Bluetooth（登録商標）に準拠した無線通信によって実現される事がある。

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

　車両に対するキーデバイス又はユーザの位置を確認する装置である位置確認装置の具体的な構成は、多様化しつつある。近年は、ＬＦ信号やBluetooth（登録商標）の他に、ＵＷＢ（Ultra Wide Band）を用いてキーデバイスの位置を確認する構成も検討されている。また、顔認証又は指紋認証によって、ユーザが所定位置に存在することを確認する装置が車両に搭載される可能性がある。さらには、キーデバイスとして利用可能な装置も多様化しつつある。

　それぞれ探索対象とするターゲットや判定方法が異なる複数種類の位置確認装置が車両に搭載されている場合、１つの制御装置がこれらを統括的に制御するほうが、セキュリティ、消費電力、ユーザビリティ或いはその他の観点において好適でありうる。

　しかしながら、車両モデルごとに、搭載される位置確認装置のバリエーション又は型式は異なりうる。また、一部の位置確認装置が工場出荷後にグレードアップされたり、追加されたりすることにより、制御装置に連なる位置確認装置の組み合わせが変わることも起こりうる。

　そのような事情を踏まえると、複数の位置確認装置を統括的に管理して動作させるシステムは、車両モデルごとの位置確認装置の違いや、経時的な位置確認装置の入れ替え／機能変更に対して柔軟性を有することが好ましい。

　本開示は、上記の検討に基づいて成されたものであり、その目的の１つは、車両に搭載される位置確認装置の変更に対して柔軟に適合可能な車両制御システム、車両制御プログラム、位置確認装置を提供することにある。

　ここに開示される車両制御システムは、装置ごとに予め登録されているターゲットの位置確認をそれぞれ異なる方式で行う複数の位置確認装置と、複数の位置確認装置からの信号に基づいて車両制御にかかるアプリケーションを実行する統括制御装置と、を含む車両制御システムであって、統括制御装置は、車載センサからの信号に基づき所定の確認イベントの発生を検知することと、確認イベントが検知されたことに基づいて、複数の位置確認装置に対し、要求事項を示す共通の確認要求メッセージを送信することと、を実行し、位置確認装置は、統括制御装置から送信された確認要求メッセージを受信することと、受信した確認要求メッセージに示される要求内容を自装置の機能に応じた内容に変換した上で、要求内容に応じた態様で位置確認を実行することと、位置確認の結果を示す結果通知メッセージを統括制御装置に返送することと、を実行し、統括制御装置が、位置確認装置から返送されてくる結果通知メッセージをもとに、車両制御の実行可否を判断するように構成されている。

　上記の構成では、統括制御装置は、ターゲットの位置確認に係る処理の実行を要求する相手によらずに共通の確認要求メッセージを送信する。各位置確認装置は、確認要求メッセージの内容を自装置の機能に応じた内容に変換した上で、要求内容に応じた態様でターゲットの位置確認を実施し、その結果を統括制御装置に返送する。

　このような構成によれば、統括制御装置は位置確認装置ごとに個別の指示を出力する必要がない。よって、車両モデルごとの位置確認装置の違いや、経時的な位置確認装置の入れ替え／機能変更に対して柔軟性を有する車両制御システムを実現可能となる。

　また、本開示される車両制御プログラムは、装置ごとに予め登録されているターゲットの位置確認をそれぞれ異なる方式で行う複数の位置確認装置と接続されて使用されるコンピュータに、車載センサからの信号に基づき所定の確認イベントの発生を検知することと、確認イベントが検知されたことに基づいて、複数の位置確認装置に対し、希望する要求事項を示す共通の確認要求メッセージを送信することと、位置確認装置から確認要求メッセージに基づく位置確認の結果を示す結果通知メッセージを受信することと、位置確認装置から返送されてくる結果通知メッセージをもとに、検出された確認イベントに対応する車両制御の実行可否を判断することと、を実行させるための命令を含む。

　上記の車両制御プログラムは、コンピュータを、上記の車両制御システムが備える統括制御装置として機能させるためのプログラムである。上記命令を含む構成によれば、コンピュータを統括制御装置として動作させることができ、その結果として車両制御システムと同様の効果を奏しうる。

　本開示の位置確認装置は、車両制御にかかるアプリケーションを実行する統括制御装置からの指示信号に基づき、予め登録されているターゲットの位置確認を実施する位置確認装置であって、統括制御装置から位置確認での要求事項を示す確認要求メッセージを受信することと、受信した確認要求メッセージに示される要求内容を自装置の機能に応じた内容に変換した上で、要求内容に応じた態様で位置確認を実行することと、位置確認の結果を示す結果通知メッセージを統括制御装置に返送することと、を実行するように構成されている。

　上記装置は、上記の車両制御システムが備える位置確認装置である。上記装置によれば、統括制御装置との連携により、車両制御システムと同様の効果を奏しうる。

　なお、請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

車両用電子キーシステムの全体像を示す図である。通信機の設置位置の一例を示す図である。カメラ及び指紋リーダの設置位置の一例を示す図である。位置確認処理の流れを示すフローチャートである。エリア設定の一例を説明するための図である。統括ＥＣＵの機能ブロック図である。確認要求パケットに収容するペイロードのフォーマットの一例を示す図である。装置フィールドにおける値の定義例を示す図である。レンジフィールドにおける値の定義例を示す図である。エリアフィールドにおける値の定義例を示す図である。車外を細分化したエリア設定例を示した図である。ターゲットフィールドにおける値の定義例を示す図である。セキュリティフィールドにおける値の定義例を示す図である。手段フィールドにおける値の定義例を示す図である。開錠操作受付時のシステムの作動を説明するためのシーケンス図である。開錠操作に反応して統括ＥＣＵが送信する確認要求パケットの例を示す図である。スマートキー認証ＥＣＵが送信する結果通知パケットのペイロードの一例を示す図である。モバイル認証ＥＣＵが送信する結果通知パケットのペイロードの一例を示す図である。施錠操作に反応して統括ＥＣＵが送信する確認要求パケットの例を示す図である。スマートキー認証ＥＣＵが送信する結果通知パケットのペイロードの一例を示す図である。モバイル認証ＥＣＵが送信する結果通知パケットのペイロードの一例を示す図である。車載システムの他の構成例を示すブロック図である。

　以下、本開示の実施形態について図を用いて説明する。

　＜前置き＞
　図１は、車両用電子キーシステムＳｙｓの概略的な構成の一例を示す図である。図１に示すように車両用電子キーシステムＳｙｓは、車載システム１と、複数のスマートキー２と、複数の携帯デバイス３とを含む。車載システム１は、車両Ｈｖに搭載されているシステムである。スマートキー２は、車両Ｈｖの電子キーとしての専用デバイスである。携帯デバイス３は、車両Ｈｖのユーザによって携帯される汎用的な情報処理端末である。

　車両Ｈｖは電動車、より具体的には外部充電可能なハイブリッド車、いわゆるプラグインハイブリッド車である。電動車の概念には、電気自動車の他、ハイブリッド車、及び燃料電池車も含まれる。尚、ハイブリッド車は動力源としてエンジンとモータを備える車両である。他の態様として車両Ｈｖは、エンジン車であってもよい。車両Ｈｖは複数のユーザによって利用されうる。

　車両Ｈｖは、右側に運転席が設けられている。他の態様として、車両Ｈｖは左側に運転席が設けられた車両でも良い。以下の説明における前後、左右、上下の各方向は、基準方向に関する注釈がない場合には（つまり基本的には）、車両Ｈｖを基準として規定される。以下の説明は、車両Ｈｖが使用される地域の法規及び慣習に適合するように適宜変更して実施可能である。

　車載システム１とスマートキー２は、ＬＦ（Low Frequency）帯の電波と、ＲＦ帯の電波を用いて無線通信可能に構成されている。ＬＦ帯とは、１２５ｋＨｚ又は１３４ｋＨｚといった、３００ｋＨｚ以下の周波数帯を指し、２０ｋＨｚから３０ｋＨｚまでの周波数も含みうる。車両用電子キーの技術分野において、ＲＦ帯は３１５ＭＨｚ又は９２０ＭＨｚといった、ＵＨＦ（Ultra High Frequency）帯と解されて良い。

　車載システム１は、ＬＦ信号を送信するとともに、ＲＦ信号を受信可能に構成されている。ＬＦ信号とは、ＬＦ帯に属する所定周波数の無線信号である。ＲＦ信号とはＲＦ帯に属する所定周波数の無線信号である。ＬＦ信号とは、例えば、ウェイク信号、及び、チャレンジ信号である。ウェイク信号は、スマートキー２をアクティブモードに移行させるためのコードを含むＬＦ信号である。チャレンジ信号は、認証のためのレスポンスコードの返送を要求するＬＦ信号である。チャレンジ信号は、乱数であるチャレンジコードを含む。スマートキー２は、受信したＬＦ信号に応じた応答データを、ＲＦ帯の電波を用いて車載システム１に返送する。本開示ではＬＦ信号とＲＦ信号を用いた双方向通信をＬＦ－ＲＦ通信とも称する。

　車載システム１と携帯デバイス３はそれぞれ、近距離通信可能に構成されている。ここでの近距離通信とは、実質的な通信可能距離が５ｍから３０ｍ、最大でも１００ｍ程度となる所定の近距離無線通信規格に準拠した通信である。近距離通信の規格は、Bluetooth（登録商標）、又はWi-Fi（登録商標）等であってよい。Bluetooth規格は、Bluetooth Classicでもよいし、ＢＬＥ（Bluetooth Low Energy）でもよい。

　以下では、車載システム１と携帯デバイス３は、近距離通信として、ＢＬＥ規格に準拠した無線通信（以降、ＢＬＥ通信）を実施する場合を例にとって各部の作動を説明する。車載システム１が携帯デバイス３との通信におけるマスターとして振る舞い、携帯デバイス３がスレーブとして振る舞うように設定されている。他の実施形態としては、携帯デバイス３が車載システム１との通信におけるマスターとして動作するように構成されていても良い。本開示では、ＢＬＥ通信で送受信される無線信号をＢＬＥ信号とも記載する。スマートキー２や携帯デバイス３が車載システム１に向けて送信するＢＬＥ信号には、送信元を示す情報としてデバイスＩＤが含まれる。

　スマートキー２及び携帯デバイス３は、車両Ｈｖを使用するための鍵コードを保持しており、当該鍵コードを用いて車両Ｈｖの電子キーとして機能するデバイスである。ここでの鍵コードとは、後述する認証処理で使用されるデータである。鍵コードは、車両Ｈｖにアクセスしようとしている人物がユーザであること、つまり、車両Ｈｖにアクセスしようとしている人物の正当性を証明するためのデータである。本開示では、スマートキー２及び携帯デバイス３のことをまとめてキーデバイスとも称する。鍵コードは、キーデバイス毎に異なりうる。

　なお、本開示のように携帯デバイス３をキーデバイスとして利用可能に構成されている車載システム１においても、スマートキー２は、今後も車両の付属品として販売／配布されることが予見される。また、ユーザの中には、その好みによって、あえて携帯デバイス３ではなくスマートキー２を車両の鍵として使用し続けるユーザの存在も想定される。つまり、車載システム１の構成としては、スマートキー２と携帯デバイス３の双方と通信可能であることが求められうる。

　＜スマートキー２について＞
　スマートキー２は、ユーザが車両Ｈｖを操作するための専用デバイスである。スマートキー２は、車両Ｈｖの購入時に、車両Ｈｖとともにオーナに配布されうる。スマートキー２は、扁平な直方体型や、扁平な楕円体型（いわゆるフォブタイプ）、カード型など、多様な形状であってよい。スマートキー２は、車両用携帯機、キーフォブ、キーカード、又はアクセスキーと呼ばれうる。スマートキー２は、車両Ｈｖの付属物であることから付属キーと言い換えられて良い。

　スマートキー２は、ＬＦ受信部、ＲＦ送信部、及び、キー制御部を備える。ＬＦ受信部は、ＬＦ信号を受信するための回路である。ＬＦ受信部は、ＬＦ信号を受信するためのアンテナ、及び、受信信号を復調する回路（いわゆる復調回路）を含む。ＲＦ送信部は、ＲＦ信号を送信するための構成である。ＲＦ送信部は、ＲＦ信号を送信するためのアンテナ、及びキー制御部から入力されたベースバンド信号を変調する変調回路を含む。

　キー制御部は、ＣＰＵ（Central Processing Unit）やＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）を備えるマイクロコンピュータとして構成されている。キー制御部はＩＣ（Integrated Circuit）やＦＰＧＡ（Field-Programmable Gate Array）を用いて実現されていてもよい。ＲＯＭには、キーＩＤや、当該スマートキー２で施開錠可能な車両Ｈｖの車両ＩＤ、鍵コード、スマートキー制御プログラムが保存されている。キーＩＤは、車載システム１がスマートキー２を識別するためのＩＤであって、スマートキー２ごとに異なる値が割り当てられている。車両ＩＤは車両ごとに固有の値である。

　キー制御部は、ＬＦ受信部が所定の閾値以上の強度を有するウェイク信号を受信したことに基づいて起動し、スマートキー２全体をスリープモードからアクティブモードに移行させる。アクティブモードは、キー制御部やＲＦ送信部が駆動している動作モードである。スリープモードは、アクティブモードと比較して実行可能な機能を限定することで消費電力を抑制する動作モードである。スリープモードは、キー制御部の大部分及びＲＦ通信部が停止している動作モードに相当する。

　アクティブモード時においてキー制御部は、ＬＦ受信部がチャレンジコードを受信した場合にはＲＯＭに保存されている鍵コードを用いてレスポンスコードを生成し、ＲＦ送信部からに無線送信させる。

　なお、スマートキー２はより好ましい態様として、車載システム１との通信手段のバックアップとしてトランスポンダを備える。トランスポンダは、車載システム１が備えるＴＰステーション４７から無線給電される電力で動作し、ＴＰステーション４７から送信されてくるチャレンジコードに応じたレスポンスコードを車載システム１に返送する。つまり、スマートキー２は、トランスポンダを用いて車載システム１と認証のための無線通信を実施可能に構成されている。

　＜携帯デバイス３について＞
　携帯デバイス３は、ＢＬＥ通信機能を備えた、携帯可能かつ汎用的な情報処理端末である。携帯デバイス３は、スマートフォン又はウェアラブルデバイスといった、任意の通信端末であってよい。ウェアラブルデバイスは、ユーザの身体に装着されて使用されるデバイスである。ウェアラブルデバイスは、リストバンド型、腕時計型、指輪型、メガネ型、又はイヤホン型といった、多様な形状を有していてよい。

　携帯デバイス３は、ＢＬＥ通信部、ＮＦＣ通信部、及び、デバイス制御部を備える。ＢＬＥ通信部は、ＢＬＥ通信を実施するための通信モジュールである。ＮＦＣ通信部は、ＮＦＣ（Near Field Communication）の規格に従った無線通信であるＮＦＣ通信を実施するための通信モジュールである。ここでのＮＦＣ通信は、通信可能な距離が数ｃｍから数十ｃｍ程度となる通信である。ＮＦＣ通信は、近接場通信、あるいは、タッチ通信と呼ぶことができる。近接場通信は、ＢＬＥ通信よりも通信可能な距離が十分に小さい通信方式に相当する。

　デバイス制御部は、プロセッサ、メモリ、及びストレージ等を備えた、コンピュータである。ストレージには、携帯デバイス３を車両Ｈｖの電子キーとして機能させるためのアプリケーションであるデジタルキーアプリがインストールされている。また、ストレージには、鍵コードが保存されている。デバイス制御部は、車載システム１との通信接続、及び、認証に係る処理を実施する。

　携帯デバイス３は、ＢＬＥ通信部からアドバタイズ信号を定期的に送信する。また携帯デバイス３は、車載システム１とのＢＬＥ通信により、チャレンジコードを受信した場合には、ストレージに保存されている鍵コードを用いてレスポンスコードを生成し、車載システム１に返送する。なお、携帯デバイス３はＮＦＣ通信で車載システム１からチャレンジコードを受信した場合にもレスポンスコードを生成する。そして携帯デバイス３は、当該生成したレスポンスコードをＮＦＣ通信で車載システム１に返送する。

　＜車載システム１の構成について＞
　車載システム１は、図１に示すように、統括ＥＣＵ４１、施開錠センサ４２、スタートスイッチ４３、制御対象４４、ＬＦ送信機４５、ＲＦ受信機４６、ＴＰステーション４７、ＢＬＥ通信機４８、ＮＦＣ通信機４９、カメラ５０、及び指紋リーダ５１を備える。また、車載システム１は、上記のデバイスに加えて、スマートキー認証ＥＣＵ６１、モバイル認証ＥＣＵ６２、顔認証ＥＣＵ６３、及び指紋認証ＥＣＵ６４を備える。部材名称中のＥＣＵは、Electronic Control Unitの略であり、電子制御装置を意味する。また、ＴＰステーション４７の「ＴＰ」は、トランスポンダを表す。部材名称中のモバイルは携帯デバイス３を意図しているが、携帯デバイス３は必ずしも通話機能を備えていなくともよい。

　統括ＥＣＵ４１は、施開錠センサ４２、スタートスイッチ４３、制御対象４４、スマートキー認証ＥＣＵ６１、モバイル認証ＥＣＵ６２、顔認証ＥＣＵ６３、及び指紋認証ＥＣＵ６４のそれぞれと車両内ネットワークＮｗを介して相互通信可能に接続されている。車両内ネットワークＮｗは、車両Ｈｖ内に構築されている通信ネットワークである。車両内ネットワークＮｗの規格としては、多様な規格を採用可能である。スマートキー認証ＥＣＵ６１は、ＬＦ送信機４５、ＲＦ受信機４６、及びＴＰステーション４７のそれぞれと、専用の通信ケーブルで接続されていてよい。モバイル認証ＥＣＵ６２は、ＢＬＥ通信機４８及びＮＦＣ通信機４９のそれぞれと通信ケーブルを用いて相互通信可能に接続されている。顔認証ＥＣＵ６３はカメラ５０と映像信号線で接続されている。指紋認証ＥＣＵ６４は指紋リーダ５１と有線接続されている。図１に示す装置同士の接続形態は一例であって、具体的な装置同士の接続態様は適宜変更可能である。

　車載システム１は、ユーザ又はキーデバイスの位置確認にかかる複数のサブシステム（以降、認証システム）を含む。スマートキー認証ＥＣＵ６１は、ＬＦ送信機４５、ＲＦ受信機４６、及びＴＰステーション４７とともに、スマートキー２の位置を確認するサブシステムであるスマートキー探索システムＳｂ１を構築する。また、モバイル認証ＥＣＵ６２は、ＢＬＥ通信機４８及びＮＦＣ通信機４９とともに、携帯デバイス３の位置を確認するサブシステムであるモバイル探索システムＳｂ２を構築する。顔認証ＥＣＵ６３は、カメラ５０の撮影画像に基づいてユーザの認証を行う顔認証システムＳｂ３を構築する。指紋認証ＥＣＵ６４は、指紋リーダ５１が読み取った指紋パターンに基づいてユーザ認証をする指紋認証システムＳｂ４を構築する。

　以降では、スマートキー認証ＥＣＵ６１、モバイル認証ＥＣＵ６２、顔認証ＥＣＵ６３、指紋認証ＥＣＵ６４をまとめて認証ＥＣＵ６ｘとも記載する。認証ＥＣＵ６ｘが位置確認装置に相当する。本開示における位置確認とは、基本的には単なる位置の判定だけでなく、判定対象とするデバイス／人物の正当性を検証（つまり認証）することを含む。位置確認に認証処理を含めるか否かは、統括ＥＣＵ４１からの指示、換言すれば、位置確認を実施するシーンによって定まりうる。また、ターゲットを認証する際には位置の判定も伴う。以下における認証との記載は、位置確認或いは探索と読み替えることができる。

　統括ＥＣＵ４１は、複数の認証システムの動作を統括的に制御するＥＣＵである。統括ＥＣＵ４１が統括制御装置に相当する。統括ＥＣＵ４１は、コンピュータを用いて実現されている。すなわち、統括ＥＣＵ４１は、プロセッサＥ１、メモリＥ２、ストレージＥ３、入出力回路Ｅ４（図中のＩ／Ｏ）、及びこれらの構成を接続するバスラインを備えている。なお、スマートキー認証ＥＣＵ６１、モバイル認証ＥＣＵ６２、顔認証ＥＣＵ６３、及び指紋認証ＥＣＵ６４などといった、統括ＥＣＵ４１以外のＥＣＵもまた、それぞれプロセッサやメモリ、ストレージを備える。

　プロセッサＥ１はメモリＥ２と結合された演算処理のためのハードウェア（換言すれば演算コア）である。プロセッサＥ１は、メモリＥ２へのアクセスにより、種々の処理を実行する。メモリＥ２は、揮発性の記憶媒体（例えばＲＡＭ）である。ストレージＥ３は、フラッシュメモリといった、不揮発性の記憶媒体を含む構成である。ストレージＥ３には、プロセッサＥ１によって実行される車両制御プログラムが格納されている。プロセッサＥ１が車両制御プログラムを実行することは、当該車両制御プログラムに対応する車両制御方法が実行されることに相当する。入出力回路Ｅ４は、他装置と通信するための回路モジュールである。

　統括ＥＣＵ４１のストレージＥ３には、ユーザごとに固有の識別情報であるユーザＩＤが管理ＩＤと紐付けられている。管理ＩＤは、各認証ＥＣＵ６ｘが保有する、同一ユーザについての認証用データを紐づけて管理するための識別番号である。管理ＩＤはユーザＩＤと１対１で対応しうる。ここでは一例として管理ＩＤは１番から４番までが使用されている。なお、ユーザＩＤ自体が管理ＩＤとして使用されてもよい。

　統括ＥＣＵ４１は、複数のアプリケーションソフトウェア（以降、アプリ）を実行可能に構成されている。アプリは、ＥＣＵ上で動作するプログラムである。本開示の「アプリケーション」／「アプリ」との記載は、アプリケーションを実行する装置／演算コアと読み替えることができる。演算コアは、プロセッサＥ１に対応する。統括ＥＣＵ４１は、認証制御アプリＡｐ１と車両制御アプリＡｐ２を実行する。

　認証制御アプリＡｐ１は、各認証システム、実体的には各認証ＥＣＵ６ｘを制御するアプリである。車両制御アプリＡｐ２は、認証結果に基づいて所定の車両制御を実行するアプリである。ここでの車両制御とは、開錠や、施錠、走行用電源をオンオフ制御、ウェルカム制御、リモート駐車、リモート出庫などの少なくとも何れか１つと解されて良い。ウェルカム制御とは、ユーザが車両Ｈｖに接近したことに基づいて車載照明設備を点灯させたり、空調を作動させたりする制御である。認証制御アプリＡｐ１及び車両制御アプリＡｐ２の機能の詳細は別途後述する。

　施開錠センサ４２は、ユーザが車両Ｈｖのドアを開錠及び施錠するためのタッチセンサである。施開錠センサ４２は、各ドアに設けられている外側ドアハンドルに設けられている。外側ドアハンドルとは、ドアの外側面に設けられた、ドアを開閉するための把持部材である。施開錠センサ４２は、ユーザにタッチされたことを静電容量の変化あるいは圧力の変化から検出し、その旨を示す電気信号をモバイル認証ＥＣＵ６２に出力する。尚、ユーザの開錠指示及び施錠指示の少なくとも何れか一方を受け付けるための構成は、ボタン式のスイッチであってもよい。ボタン式スイッチは、施開錠センサ４２の代わりに、又は、施開錠センサ４２とともに各ドアハンドルに設けられうる。

　スタートスイッチ４３は、ユーザが走行用電源をオン／オフを切り替えるためのプッシュスイッチである。走行用電源は、車両Ｈｖが走行するための電源であって、システムメインリレーである。仮に車両Ｈｖがエンジン車である場合にはイグニッション電源が走行用電源に相当する。スタートスイッチ４３は、ユーザによってプッシュ操作がされると、その旨を示す電気信号をモバイル認証ＥＣＵ６２に出力する。施開錠センサ４２やスタートスイッチ４３が車載センサの一例に相当する。

　制御対象４４は、統括ＥＣＵ４１が制御可能なアクチュエータ及び電装設備である。統括ＥＣＵ４１には、制御対象４４が接続されている。制御対象４４は、ドアロックモータ、電源ＥＣＵ、スピーカ、車載照明装置、空調装置、又はディスプレイであってよい。ドアロックモータは、各ドアのロック機構の状態（施錠、開錠）を切り替えるためのモータである。電源ＥＣＵは、車両Ｈｖに搭載された走行用電源のオンオフ状態を制御するＥＣＵである。電源ＥＣＵは、統括ＥＣＵ４１からの指示信号に基づき、走行用電源をオフからオンに切り替える。車載照明装置は、ヘッドライトや、車内灯、ウェルカムランプなどである。ディスプレイは、車内に配置された液晶／有機ＥＬディスプレイ、又は、車両のサイドウィンドウ／路面に画像を投影するプロジェクタであってよい。

　ＬＦ送信機４５は、モバイル認証ＥＣＵ６２からの指示に基づき、ウェイク信号やチャレンジ信号といった、ＬＦ信号を送信する装置である。ＬＦ送信機４５は、ＬＦ送信回路とＬＦ送信アンテナとを備える。ＬＦ送信回路は、デジタルアナログ変換、周波数変換、又は変調といった、所定の信号処理を行う回路である。

　本実施形態の車載システム１は、図２に示すようにＬＦ送信機４５ａ、４５ｂ、４５ｃ、４５ｄ、４５ｅ、４５ｐ、４５ｑを備える。ＬＦ送信機４５ａは運転席用の外側ドアハンドルに設けられたＬＦ送信機４５である。ＬＦ送信機４５ｂは助手席用の外側ドアハンドルに設けられたＬＦ送信機４５である。ＬＦ送信機４５ｃはトランクドア付近に設けられたＬＦ送信機４５である。ＬＦ送信機４５ｐは、キャビン内に配置されたＬＦ送信機４５である。ＬＦ送信機４５ｐは、トランク内に配置されたＬＦ送信機４５である。ＬＦ送信機４５ｐは、インストゥルメントパネルの車幅方向中央部又は運転席正面部に配置されていてよい。ＬＦ送信機４５ｑは、後部座席の着座面や足元付近に配置されていてよい。

　ＬＦ送信機４５ａの通信範囲は、車外の運転席用ドア付近に限定されており、ＬＦ送信機４５ｂの通信範囲は、車外の助手席用ドア付近に限定されており、ＬＦ送信機４５ｃの通信範囲は、車外のリアバンパ付近に限定されている。ＬＦ送信機４５ｐの通信範囲は、キャビン内に限定されている。ＬＦ送信機４５ｑの通信範囲は、トランク内に限定されている。

　なお、ＬＦ送信機４５ａ、４５ｂ、４５ｃといった車外向けＬＦ送信機は、より好ましい態様として、送信電力を基本探索レベルと拡張探索レベルとに切り替え可能に構成されている。基本探索レベルは、アンテナから１ｍ以内を通信範囲とする電力値に設定されている。また、拡張探索レベルはアンテナから６ｍ以内を通信範囲とする電力値に設定されている。拡張探索レベルは、後述する車外遠方エリアにスマートキー２が存在するか否かを判定するために供される。ＬＦ送信機４５ａ～４５ｃの通信範囲（送信電力）はスマートキー認証ＥＣＵ６１によって制御される。

　ＲＦ受信機４６は、ＲＦ信号、すなわちスマートキー２からの応答信号を受信するためのモジュールである。ＲＦ受信機４６は、受信信号に対応するデータをスマートキー認証ＥＣＵ６１に出力する。ＲＦ受信機４６は、車内の天井部やインストゥルメントパネルに設けられている。ＲＦ受信機４６は、スマートキー認証ＥＣＵ６１に内蔵されていても良い。

　ＴＰステーション４７は、スマートキー２のトランスポンダと通信を実施するための構成であって、ループアンテナあるいはコイルを用いて実現されている。ＴＰステーション４７は、スタートスイッチ４３付近、運転席の外側ドアハンドル、及びトランクの外側ドアハンドルに配置されていてよい。各ＴＰステーション４７は、スマートキー認証ＥＣＵ６１の指示に基づき動作する。

　ＢＬＥ通信機４８は、携帯デバイス３とＢＬＥ通信を実施するための通信モジュールである。ＢＬＥ通信機４８は、車両Ｈｖに少なくとも１つ設けられている。本実施形態の車載システム１は一例として、図２に示すように、ＢＬＥ通信機４８として、ＢＬＥ通信機４８ａ、４８ｂ、４８ｃ、４８ｐ、４８ｑを備える。ＢＬＥ通信機４８ａは運転席側のＢピラーに配置されており、ＢＬＥ通信機４８ｂは助手席側のＢピラーに配置されており、ＢＬＥ通信機４８ｃはリアバンパ付近に配置されている。本開示では、ＢＬＥ通信機４８ａ～４８ｃをまとめて車外向けＢＬＥ通信機とも記載する。車外向けＢＬＥ通信機は車両Ｈｖの外面部（側面部や背面部）に配置されたＢＬＥ通信機４８である。ＢＬＥ通信機４８ｐはスタートスイッチ４３付近に配置されており、ＢＬＥ通信機４８ｑはトランク内に配置されている。本開示では、ＢＬＥ通信機４８ｐ、４８ｑといった、車内に配置されたＢＬＥ通信機４８を車内向けＢＬＥ通信機とも記載する。

　各ＢＬＥ通信機４８は、駆動中、キーデバイスとして登録されている携帯デバイス３からの信号の受信状況を示すデータをモバイル認証ＥＣＵ６２に出力する。受信状況には、受信の有無、受信強度（Received Signal Strength Indicator/Indication）が含まれる。各ＢＬＥ通信機４８の動作状態（駆動／停止）は、モバイル認証ＥＣＵ６２によって制御される。

　本実施形態のモバイル認証ＥＣＵ６２は、複数のＢＬＥ通信機４８のうちの１つのみを携帯デバイス３とのデータ通信に使用し、その他のＢＬＥ通信機４８を携帯デバイス３の位置判定用の通信機として使用する。位置判定用のＢＬＥ通信機４８とは、１つの局面においては、携帯デバイス３からの信号の受信強度を測定するための通信機である。本開示では携帯デバイス３とのデータ通信に使用されるＢＬＥ通信機４８を代表機とも称する。また、位置判定用のＢＬＥ通信機４８のことを本開示では観測機とも称する。本実施形態のモバイル認証ＥＣＵ６２は一例としてＢＬＥ通信機４８ｐを代表機として運用し、その他を観測機として運用する。代表機の設定はモバイル認証ＥＣＵ６２によって動的に変更されても良い。

　尚、ＢＬＥ通信では、デバイス間の通信接続が確立している状態では、複数のチャンネルを逐次変更しながらデータの送受信を実施する。すなわち、コネクション確立後のデータ通信時は周波数ホッピングが行われる。そのため、通常は、代表機しか携帯デバイス３からのデータ信号を捕捉できない。観測機はデバイス信号を観測できなくなる。

　そのような事情に対応する構成として、本実施形態のモバイル認証ＥＣＵ６２は、代表機から携帯デバイス３との通信に使用するチャンネルを示す情報（以降、チャンネル情報）及びデバイスＩＤを、各観測機に参照情報として配信する。各観測機は、参照情報に示されるチャンネル情報によって、ＢＬＥで使用可能な多数のチャンネルのうち、何れのチャンネルを受信すれば、接続デバイスからの信号を受信できるのかを認識可能となる。その結果、観測機は、通信接続せずともデバイス信号の受信強度を検出及び報告可能となる。ちろん、他の態様としては、各ＢＬＥ通信機４８が個別に携帯デバイス３と双方向通信を実施し、受信強度をモバイル認証ＥＣＵ６２に送信するように構成されていてもよい。

　ＮＦＣ通信機４９は、近接場通信を実施するためのモジュールである。車載システム１は、ＮＦＣ通信機４９として、例えば右側Ｃピラーなど、車両Ｈｖの外面部に配置されたＮＦＣ通信機４９ａと、車内の運転席付近に配置されているＮＦＣ通信機４９ｐを備える。各ＮＦＣ通信機４９の動作状態は、モバイル認証ＥＣＵ６２によって制御される。

　カメラ５０は、ユーザの顔認証に使用される画像を生成する装置である。車載システム１は、カメラ５０として、カメラ５０ａ、５０ｂ、５０ｃ、５０ｐを備える。各カメラ５０の動作は顔認証ＥＣＵ６３からの信号に基づき駆動する。

　カメラ５０ａは、運転席側の車外に存在するユーザの顔を撮像可能なカメラ５０である。カメラ５０ａは、運転席側のＢピラー、ルーフ縁部、又はサイドミラーに配置されていてよい。カメラ５０ｂは、助手席側の車外に存在するユーザの顔を撮像可能なカメラ５０である。カメラ５０ｂは、助手席側のＢピラー、ルーフ縁部、又はサイドミラーに配置されていてよい。カメラ５０ｃは、トランクの前に存在するユーザの顔を撮像可能なカメラ５０である。カメラ５０ｃは、リアウィンドウの上端／下端、トランクドア、又はリアバンパ付近に配置されていてよい。カメラ５０ａ～５０ｃは、運転支援／自動運転などの制御にも利用される、周辺監視用のカメラであってもよい。カメラ５０ｐは運転席に着座している乗員の顔を撮像可能なカメラである。カメラ５０ｐは、光軸が運転席のヘッドレストが存在する方向に向いた姿勢にて、ステアリングコラムカバー又はフロントウィンドウの上端部等に設置されていてよい。カメラ５０ｐは、ドライバの状態（眠気等）を検出するドライバステータスモニタ用のカメラであってもよい。各カメラ５０は、光学カメラであってもよいし赤外線カメラであってもよい。

　指紋リーダ５１は、指紋情報を読取る装置である。指紋リーダ５１は、例えば複数の電極が形成する静電容量の分布パターン、又は、当該分布パターンに基づいて定まる特徴点の分布パターンを示すデータを出力する。なお、指紋リーダ５１は光学式のものであってもよいし、超音波式のものであってもよい。車載システム１は、図３に示すように指紋リーダ５１ａ、５１ｐを備える。

　指紋リーダ５１ａは、運転席用の外側ドアハンドルといった、車両Ｈｖの外面部に設けられている。指紋リーダ５１ａは、車外に存在するユーザが車両Ｈｖを施錠したり開錠したりするために供される。指紋リーダ５１ｐは、ステアリングホイール又はインストゥルメントパネルといった、車内の運転席周りに配置されている。指紋リーダ５１ｐは、ドライバとしてのユーザが、走行用電源をオフからオンに切り替えるために供される。

　スマートキー認証ＥＣＵ６１は、統括ＥＣＵ４１からの指示に基づき、スマートキー２を探索する処理を実施するＥＣＵである。スマートキー認証ＥＣＵ６１のストレージには、スマートキー２毎のキーＩＤがユーザＩＤ及び管理ＩＤと紐付けられて登録されている。スマートキー２の探索処理については別途後述する。

　モバイル認証ＥＣＵ６２は、ＢＬＥ通信機４８等との協働により、車両Ｈｖに対する携帯デバイス３の位置を判定するＥＣＵである。モバイル認証ＥＣＵ６２のストレージには、携帯デバイス３毎のデバイスＩＤが管理ＩＤ及びユーザＩＤと紐付けられて登録されている。また、ストレージＥ３には、各ＢＬＥ通信機４８の車両Ｈｖにおける搭載位置を示す通信機設定データが格納されている。各ＢＬＥ通信機４８の搭載位置は、車両座標系上の点として表現されてよい。車両座標系は、車両Ｈｖの任意の位置を中心とし、車両Ｈｖの幅方向及び前後方向の両方に平行な２次元座標系である。車両座標系を形成するｘ軸は車幅方向に平行に、ｙ軸は車両の前後方向に平行に設定されていてよい。座標系の中心は、車体の中心であってよい。車両座標系は、高さ方向に平行なｚ軸を含む、３次元座標系であってもよい。モバイル認証ＥＣＵ６２の作動の詳細については別途後述する。

　顔認証ＥＣＵ６３は、カメラ５０で撮像された画像に含まれる顔画像を解析することによってユーザを認証するＥＣＵである。顔認証ＥＣＵ６３のストレージにはユーザごとの顔の特徴量データとユーザＩＤが管理ＩＤと紐付けられた状態で保存されている。顔認証ＥＣＵ６３は、統括ＥＣＵ４１からの要求に基づき、複数のカメラ５０を選択的に動作させ、当該カメラ５０の撮影映像に含まれる顔部の特徴量に基づいてユーザを認証する。

　顔認証ＥＣＵ６３は、統括ＥＣＵ４１から車外近傍エリアにユーザがいるか否かを確認するように指示された場合、カメラ５０ａ、５０ｂ、５０ｃを用いてユーザの顔画像の取得を試行する。カメラ５０ａ、５０ｂ、５０ｃのいずれかを用いてユーザ認証が成功した状態とは、ユーザが車外近傍エリアに存在することが確認された状態に相当する。また、顔認証ＥＣＵ６３は、統括ＥＣＵ４１からキャビン内にユーザがいるか否かを確認するように指示された場合には、カメラ５０ｐを用いてユーザの顔画像の取得を試行する。

　指紋認証ＥＣＵ６４は、指紋リーダ５１で読み取られた指紋情報に基づいて、ユーザを認証するＥＣＵである。指紋認証ＥＣＵ６４のストレージにはユーザごとの指紋の特徴量データとユーザＩＤが管理ＩＤと紐付けられた状態で保存されている。指紋認証ＥＣＵ６４は、統括ＥＣＵ４１からの要求に基づき、複数の指紋リーダ５１を選択的に動作させ、当該指紋リーダ５１で読み取られた指紋情報をもとにユーザを識別する。

　指紋認証ＥＣＵ６４は、統括ＥＣＵ４１から車外近傍エリアにユーザがいるか否かを確認するように指示された場合、指紋リーダ５１ａを用いてユーザの指紋情報の取得を試行する。また、指紋認証ＥＣＵ６４は、統括ＥＣＵ４１からキャビン内にユーザがいるか否かを確認するように指示された場合には、指紋リーダ５１ｐを用いてユーザの指紋情報の取得を試行する。指紋リーダ５１ｐを用いてユーザ認証が成功した状態とは、ユーザがキャビン内に存在することが確認された状態に相当する。

　以上で述べたように、各認証ＥＣＵ６ｘのストレージには、管理ＩＤとユーザＩＤと認証用データの対応関係を示すデータが登録されている。各認証ＥＣＵ６ｘは、統括ＥＣＵ４１から指定された管理ＩＤに対応する鍵コードや生体情報を読み出し、ターゲットの位置確認を実施可能に構成されている。ここでのターゲットとは、ユーザ及びキーデバイスといった、位置確認の対象とする人／ものを指す。なお、キーデバイス／ユーザと管理ＩＤとの対応付けは、例えば新規のユーザ情報／キーデバイス情報を認証ＥＣＵ６ｘに登録した際に、認証ＥＣＵ６ｘと統括ＥＣＵ４１とが双方向通信を実施することにより実施されてよい。

　統括ＥＣＵ４１には、上述したセンサ／スイッチ／ＥＣＵ以外にも、多様なデバイスが直接的に又は間接的に接続されていてよい。例えば統括ＥＣＵ４１には、カーテシスイッチや、着座センサ、シートベルトセンサ、ブレーキセンサ、及びシフトポジションセンサの出力信号が入力されてよい。カーテシスイッチは、ドアの開閉状態を示す信号を出力するスイッチである。着座センサは着座状態を示す信号を出力するセンサである。着座センサは、座面に配置された圧力センサであってよい。シフトポジションセンサは現在のシフトポジションを示す信号を出力するセンサである。

　統括ＥＣＵ４１及び各認証ＥＣＵ６ｘは、車両内ネットワークＮｗを介して、車両Ｈｖの状態、及び、車両Ｈｖに対するユーザの操作を示す種々の車両情報を取得する。統括ＥＣＵ４１は、走行用電源の状態（オン／オフ）、各ドアの開閉状態、各ドアの施錠／開錠状態、施開錠センサ４２の出力レベル、及びスタートスイッチ４３の出力レベルを取得する。統括ＥＣＵ４１は、ブレーキペダルの踏込量／踏込力を検出するブレーキセンサの出力値、及びパーキングブレーキの作動状態を示す信号を取得してよい。

　＜スマートキーの認証について＞
　ここではスマートキーの認証方法の一例について説明する。スマートキー認証ＥＣＵ６１は、ウェイク信号の送信に対するスマートキー２からの応答の有無に基づいて、スマートキー２の位置を判定する。スマートキー認証ＥＣＵ６１は、ＬＦ送信機４５ａからウェイク信号を基本探索レベルで送信させた結果として、スマートキー２からの応答が得られた場合、運転席外側エリアにスマートキー２が存在すると仮判定する。ＬＦ送信機４５ａの送信電力が基本探索レベルに設定されている場合、運転席外側エリアは、車外のうち、運転席用の外側ドアハンドルから１ｍ以内となるエリアに相当する。

　また、スマートキー認証ＥＣＵ６１は、ウェイク信号に対する応答を返送してきたスマートキー２である応答キーとコード照合を実施し、コード照合が成功した場合に、当該スマートキー２が、応答取得エリアに存在するとの判定を確定する。応答取得エリアとは、スマートキー２が応答信号を返送するトリガとなったウェイク信号を送信したＬＦ送信機４５の通信エリアである。上記の例では運転席外側エリアが応答取得エリアに相当する。

　コード照合処理は、チャレンジ－レスポンス方式で通信相手を認証する処理である。コード照合は、認証側装置から認証対象に向けてチャレンジコードを送信するステップと、認証側装置が検証用コードを生成するステップと、認証対象がレスポンスコードを返送するステップと、認証側装置が検証用コードとレスポンスコードが一致するか判定するステップを含む。ここではスマートキー認証ＥＣＵ６１が認証側装置に相当し、応答キーが認証対象に相当する。チャレンジコード自体は、乱数表やランダム関数を用いて生成される、照合ごとに異なるコードであってよい。

　スマートキー認証ＥＣＵ６１は、或るＬＦ送信機４５から送信させたウェイク信号に対する応答を受信した場合、コード照合処理の第１ステップとして、当該ＬＦ送信機４５からチャレンジ信号を応答キーに向けて送信する。また、スマートキー認証ＥＣＵ６１は、コード照合処理の第２ステップとして、当該チャレンジコードと、通信相手に応じた鍵コードとを用いて所定の手順により検証用コードを生成する。そして、スマートキー認証ＥＣＵ６１は、コード照合処理の第３ステップとして、通信相手から返送されてきたレスポンスコードと検証用コードとを照らし合わせる。ここで、検証用コードと受信したレスポンスコードが一致している場合に、スマートキー認証ＥＣＵ６１は認証成功と判定する。

　このようにスマートキー２の認証は、応答が得られたＬＦ送信機４５の設置位置に応じた位置判定のステップと、コード照合による通信相手の認証を行うステップとを含む。その他、スマートキー２の認証は、スマートキー２で観測されるＬＦ信号の受信強度、又は、スマートキー２から返送されてきた応答信号の受信強度を用いた中継検証ステップを含んでいても良い。中継検証ステップは、車載システム１－スマートキー２間の通信が不正に中継されているか否かを判定するためのステップである。スマートキー認証ＥＣＵ６１は、観測された受信強度が所定値以上であることに基づいて、車載システム１－スマートキー２間の通信が中継されていると判定してよい。

　スマートキー認証ＥＣＵ６１は、統括ＥＣＵ４１から要求される探索対象エリアに応じて、ウェイク信号を送信させるＬＦ送信機４５を選択する。仮に統括ＥＣＵ４１から探索対象エリアとして車外近傍エリアが指定された場合、スマートキー認証ＥＣＵ６１は、ＬＦ送信機４５ａ～４５ｃから順番にウェイク信号を送信させる。また、仮に統括ＥＣＵ４１から探索対象エリアとして車内が指定された場合、スマートキー認証ＥＣＵ６１は、ＬＦ送信機４５ｐ、４５ｐから順番にウェイク信号を送信させる。

　その他、スマートキー認証ＥＣＵ６１は、統括ＥＣＵ４１から探索対象エリアとして指定されたエリアに対応するＴＰステーション４７を駆動して、スマートキー２の認証を試行する。本開示ではＬＦ－ＲＦ通信を用いた認証処理を、ＬＦ認証とも記載する。また、ＴＰステーション４７を用いたスマートキー２の認証処理を、トランスポンダ認証とも記載する。

　＜携帯デバイスの認証について＞
　ここでは携帯デバイス３の認証方法の一例について説明する。モバイル認証ＥＣＵ６２は、携帯デバイス３の位置判定にかかる準備動作として、携帯デバイス３から送信されるＢＬＥ信号を受信したことに基づいて、携帯デバイス３（ひいてはユーザ）が車両Ｈｖ周辺に存在することを認識する。モバイル認証ＥＣＵ６２は、パッシブスキャン方式にて車両周辺に存在する携帯デバイス３を検出してよい。

　なお、モバイル認証ＥＣＵ６２は、スキャン要求の送信を伴うアクティブスキャン方式によって携帯デバイス３を探索しても良い。２種類のスキャン方式はシーンによって使い分けられても良い。例えば駐車中の待機シーンにおいてはパッシブスキャン方式を採用する一方、スタートスイッチ４３の押下などの所定の確認イベント検出時にはアクティブスキャン方式が採用されても良い。モバイル認証ＥＣＵ６２は、ＢＬＥ通信機４８から、通信接続している携帯デバイス３のデバイスＩＤを取得する。

　携帯デバイス３の認証方法もまた、スマートキー２の認証と同様に、図４に示すように位置判定ステップ（Ｓ０１）と、コード照合ステップ（Ｓ０２）と、中継検証ステップ（Ｓ０３）とを含む。位置判定ステップは、車両Ｈｖに対する携帯デバイス３の相対位置を判定するステップである。コード照合ステップは、チャレンジコードを用いた照合処理を実施するステップである。中継検証ステップは、中継器を用いて車載システム１と携帯デバイス３との間の無線通信が不正に実行されていないかを検証するステップである。

　位置判定ステップは、モバイル認証ＥＣＵ６２が各ＢＬＥ通信機４８で観測された受信強度に基づいて、車両Ｈｖに対する接続デバイスの位置を判定するステップである。接続デバイスとは、統括ＥＣＵ４１に登録されている携帯デバイス３のうち、実際にモバイル認証ＥＣＵ６２と通信接続している携帯デバイス３を意味する。モバイル認証ＥＣＵ６２は、各ＢＬＥ通信機４８で観測されている接続デバイスの受信強度に基づき、図５に示すキャビン内、トランク内、車外近傍エリア、車外遠方エリア、及び無効エリアの何れのエリアに接続デバイスが存在するかを判定する。図５のＡ１はキャビン内を、Ａ２はトランク内を、Ａ３は車外近傍エリアを、Ａ４は車外遠方エリアを、Ａ５は無効エリアをそれぞれ示している。

　キャビン内は、運転席などの座席が設けられている空間である。キャビン内は、前席エリアと後席エリアなどに細分化されていても良い。トランク内は、トランクの内側空間を指す。本開示ではキャビン内とトランク内をまとめて車内とも記載する。

　車外近傍エリアは、車外のうち車両Ｈｖから１ｍ以内となる範囲といった、車外のうち、車両Ｈｖの近傍とみなせる範囲を意味する。車外近傍エリアは、パッシブエントリエリアあるいは施開錠エリアと言い換えられて良い。車両Ｈｖの近傍とみなす距離パラメータである第１距離は、１ｍではなく、０．７５ｍや１．５ｍなどであってもよい。第１距離は、車外向けＬＦ送信機から基本探索レベルで発信させた際の通信エリアの大きさに対応する。

　車外遠方エリアは、車外のうち、車両Ｈｖから６ｍ以内であって、かつ車外近傍エリアよりも外側の範囲である。無効エリアは、車外遠方エリアよりも外側、すなわち、車両Ｈｖから６ｍ以上遠方となる領域である。車外遠方エリアの外側境界を規定する距離パラメータである第２距離は、６ｍではなく、５ｍや８ｍであってもよい。車外遠方エリアは、ウェルカム制御を開始するためのエリアである、ウェルカムエリアとみなすこともできる。

　モバイル認証ＥＣＵ６２は、通信接続していない携帯デバイス３に関しては無効エリアに存在すると見なしてよい。また、モバイル認証ＥＣＵ６２は、接続デバイスが車内、車外近傍エリア、及び車外遠方エリアの何れにも存在しないと判定している場合には、当該携帯デバイス３は無効エリアに存在すると判定してもよい。

　モバイル認証ＥＣＵ６２が実行するコード照合処理の流れは、スマートキー認証ＥＣＵ６１が実施するコード照合と、通信相手や通信手段が異なるだけで、中身は同じであってよい。モバイル認証ＥＣＵ６２がコード照合処理を実施するタイミングは、統括ＥＣＵ４１からの認証要求を受信したタイミングであってよい。他の態様として、モバイル認証ＥＣＵ６２は、ＢＬＥ通信機４８と携帯デバイス３との通信接続が確立したタイミングで接続デバイスとのコード照合を実施してもよい。モバイル認証ＥＣＵ６２は携帯デバイス３と通信接続している間、所定の周期でコード照合処理を実施するように構成されていても良い。

　中継検証ステップは、例えば代表機に接続デバイスと測距用の通信を実施させることによって定まる測距値が、所定の範囲内となっているか否かを判定するステップである。モバイル認証ＥＣＵ６２は、測距値が所定値（例えば６ｍ）以上となっている場合、中継が行われていると判定する。

　ここでの測距値とは、携帯デバイス３から送信された信号がＢＬＥ通信機４８で受信されるまでの信号の飛行時間（ＴｏＦ：Time of Flight）を示すパラメータである。測距値は、受信強度とは異なるパラメータである。測距値は、具体的には、ラウンドトリップ時間（ＲＴＴ：Round-Trip Time）又は２周波位相差である。測距通信とは、ＲＴＴ又は２周波位相差を測定するための通信と解されて良い。測距値は、片道分又は往復分のＴｏＦを示すため、ＴｏＦ関連値と言い換えられて良い。モバイル認証ＥＣＵ６２は、観測された２周波位相差又はＲＴＴをそのまま測距値として取り扱っても良い。測距値は、２周波位相差又はＲＴＴを、距離の次元に換算したパラメータであってもよい。

　その他、モバイル認証ＥＣＵ６２は、統括ＥＣＵ４１から探索対象エリアとして指定されたエリアに対応するＮＦＣ通信機４９を駆動して、携帯デバイス３の認証を試行する。以降ではＢＬＥ通信を用いて携帯デバイス３を認証する処理を、ＢＬＥ認証と記載する。また、ＮＦＣ通信を用いた携帯デバイス３の認証処理を、ＮＦＣ認証と記載する。

　ＬＦ認証及びＢＬＥ認証は、ユーザがキーデバイスをカバンや衣類のポケットに入れたまま実施可能な無線認証処理である。ＬＦ認証やＢＬＥ認証のようにユーザがキーデバイスを手にもつことなる実施可能な無線認証のことを本開示ではスマート認証と称する。一方、トランスポンダ認証及びＮＦＣ認証は、ＴＰステーション４７又はＮＦＣ通信機４９といったスキャナに、キーデバイスをかざす（略接触させる）といったアクションが必要な無線認証である。本開示では、トランスポンダ認証及びＮＦＣ認証を、略接触型認証とも記載する。

　＜統括ＥＣＵ４１の機能について＞
　ここでは統括ＥＣＵ４１の機能及び作動について説明する。統括ＥＣＵ４１は、ストレージＥ３に保存されているプログラムを実行することにより、図６に示す種々の機能ブロックに対応する機能を提供する。すなわち、統括ＥＣＵ４１は機能部として、確認イベント検出部Ｆ１、認証要求部Ｆ２、及び車両制御部Ｆ３を備える。確認イベント検出部Ｆ１及び認証要求部Ｆ２は認証制御アプリＡｐ１に属する機能ブロックであり、車両制御部Ｆ３は車両制御アプリＡｐ２に属する機能ブロックである。

　確認イベント検出部Ｆ１は、車両内ネットワークＮｗから入力される種々のデータ／信号に基づいて、確認イベントの発生を検出する。確認イベントは、開錠操作、及び施錠操作であってよい。開錠操作は、車両Ｈｖを開錠するためのユーザ操作である。開錠操作は、車両Ｈｖが施錠された状態における施開錠センサ４２へのタッチ操作であってよい。施錠操作は、車両Ｈｖを施錠するためのユーザ操作である。施錠操作は、車両Ｈｖが開錠されており、かつ、走行用電源がオフに設定された状態における、施開錠センサ４２へのタッチ操作であってよい。確認イベント検出部Ｆ１は、車両Ｈｖの状態と、施開錠センサ４２からの出力信号との組合せにより、確認イベントとしての開錠操作及び施錠操作を検出しうる。

　確認イベント検出部Ｆ１は、始動操作を確認イベントとして検出してもよい。始動操作は、ブレーキペダルが踏み込まれた状態でのスタートスイッチ４３の押下であってよい。確認イベント検出部Ｆ１は、開かれていたドアが閉じられたことを確認イベントとして検出しても良い。より具体的には、車両Ｈｖの施錠操作を受け付けた状態で、全てのドアが閉じられたことが確認イベントとして登録されていても良い。その他、確認イベント検出部Ｆ１は、ブレーキペダルが踏み込まれたことを示す信号がブレーキペダルセンサから入力されたことを確認イベントとして検出しても良い。

　その他、車載システム１は、ドア下に検知エリアを形成する赤外線センサの出力信号に基づいて、ユーザの開錠操作を検出するように構成されていても良い。その場合、確認イベント検出部Ｆ１は、上記赤外線センサから、ユーザが検知エリアに足をかざしたことを示す信号が入力された場合に、確認イベントが発生したと判定して良い。

　認証要求部Ｆ２は、確認イベント検出部Ｆ１にて確認イベントが検出されたことを受けて、その検出された確認イベントの種別、及び、車両Ｈｖの状態に応じた確認要求パケットを、各認証ＥＣＵ６ｘに向けて出力する。本実施形態の認証要求部Ｆ２は、各認証ＥＣＵ６ｘに対して、ペイロード（中身）が同一の確認要求パケットをマルチキャストする。もちろん、確認要求パケットの送信態様は、マルチキャストではなくユニキャストであっても良い。認証要求部Ｆ２は、複数の認証ＥＣＵ６ｘのそれぞれに対して、同一のペイロードを有する確認要求パケットを順番にユニキャストしてもよい。確認要求パケットの構成については別途後述する。認証要求部Ｆ２は、位置確認の要求先として指定した各認証ＥＣＵ６ｘから、位置確認処理の結果を示す結果通知パケットを取得する。確認要求パケットが確認要求メッセージに相当する。また、結果通知パケットが結果通知メッセージに相当する。

　車両制御部Ｆ３は、確認イベントの内容、デバイス／ユーザの存在が確認できている位置、及び、車両Ｈｖの状態に応じた車両制御を実行する構成である。車両制御部Ｆ３は、施錠操作を受けつけたことをトリガとして実行させた位置確認の結果として、携帯デバイス３が車内に存在せず、かつ、車外近傍エリアにキーデバイスが存在することが確認できた場合、車両Ｈｖを施錠する。また、車両制御部Ｆ３は、開錠操作を受けつけたことをトリガとして実行させた位置確認の結果として、携帯デバイス３が車外近傍エリアに存在すると判定された場合には、ボディＥＣＵ５６と協働してドアを開錠する。車両制御部Ｆ３は、施錠操作を受けつけたことをトリガとして実行させた位置確認の結果として、携帯デバイス３が車内に存在すると判定された場合、スピーカやディスプレイを用いてキーデバイスの閉じ込めを警告してもよい。

　なお、車両制御部Ｆ３は、車内や車外近傍エリアにキーデバイスの存在が確認できなかった場合でも、顔認証ＥＣＵ６３又は指紋認証ＥＣＵ６４にて、所定位置にユーザの存在が確認できている場合には、ユーザ位置及び車両の状態車両制御を実行する。

　＜確認要求パケットの構成例＞
　統括ＥＣＵ４１と認証ＥＣＵ６ｘとの間において認証要求として送受信される通信パケットのペイロードは、一定のフォーマットを有する。確認要求パケットは、認証ＥＣＵ６ｘごとの仕様や機能、特性に依存しないレベルまで、指示内容（要求事項）を抽象化して示すフォーマットを備える。当該構成によれば、車載システム１が備える認証ＥＣＵ６ｘの組み合わせや機能の変更に対して、統括ＥＣＵ４１のプログラムを修正する手間を低減する効果が期待できる。

　確認要求パケット及び結果通知パケットのペイロードは、図７に示すように、装置フィールドＦｄ１、レンジフィールドＦｄ２、第１要求フィールドＦｑ１、及び第２要求フィールドＦｑ２を備える。第１要求フィールドＦｑ１及び第２要求フィールドＦｑ２は同じ構成を有する。第１要求フィールドＦｑ１及び第２要求フィールドＦｑ２はそれぞれ、エリアフィールドＦｄ３、ターゲットフィールドＦｄ４、セキュリティフィールドＦｄ５、手段フィールドＦｄ６を備える。

　・装置フィールドについて
　確認要求パケットにおける装置フィールドＦｄ１は、要求対象を指定するフィールドである。要求対象は、認証処理を実行させる装置（認証ＥＣＵ６ｘ）を意味する。ここでは一例として、装置フィールドＦｄ１は４ビットに設定されており、ビットごとに異なる認証ＥＣＵ６ｘが割り当てられている。装置フィールドＦｄ１の第１ビットにはスマートキー認証ＥＣＵ６１が、第２ビットにはモバイル認証ＥＣＵ６２が、第３ビットには顔認証ＥＣＵ６３が、第４ビットには指紋認証ＥＣＵ６４が、それぞれ割り当てられている。なお、ここでは右端のビットが第１ビットである。統括ＥＣＵ４１は、認証処理を実行させたい認証ＥＣＵ６ｘに対応するビットに「１」を設定した確認要求パケットを送信する。例えば統括ＥＣＵ４１は、スマートキー認証ＥＣＵ６１とモバイル認証ＥＣＵ６２に対して認証処理の実行を要求する場合、装置フィールドＦｄ１に「００１１」に設定した確認要求パケットを送信する。図８は、装置フィールドＦｄ１における設定値ごとの要求対象の組み合わせの対応関係の一例を示している。

　なお、上記の例では認証ＥＣＵ６ｘの数の増大に比例して装置フィールドＦｄ１のビット数を拡張する必要が生じる。他の態様として、装置フィールドＦｄ１は、認証処理の要求先／報告元を示すＥＣＵの識別番号（以降、ＥＣＵ－ＩＤ）を示すビット列が挿入されるフィールドであってもよい。装置フィールドＦｄ１の長さは、可変であってもよい。装置フィールドＦｄ１には、要求対象とする複数のＥＣＵ－ＩＤが挿入されても良い。

　また、通信パケットは、ヘッダに示される宛先アドレス情報により、送信先を指定可能である。認証処理の要求先や報告元は、宛先アドレスや送信元アドレスで識別可能であるため装置フィールドＦｄ１は省略されても良い。確認要求パケットは装置フィールドＦｄ１を備えていなくとも良い。統括ＥＣＵ４１は、要求対象とする複数の認証ＥＣＵ６ｘに向けて同一の中身を有する確認要求パケットを送信するように構成されていればよい。

　・レンジフィールドについて
　レンジフィールドＦｄ２は、車外におけるキーデバイス／ユーザの探索範囲を指定するビット値が挿入されるフィールドである。ここでは一例としてレンジフィールドＦｄ２の長さは２ビットに設定されている。統括ＥＣＵ４１は、車外の探索範囲として、例えば近傍エリアのみを指定する場合、レンジフィールドＦｄ２に「０１」に設定した確認要求パケットを送信する。また、統括ＥＣＵ４１は、車外の探索範囲として、車外近傍エリアと車外近傍エリアを含む範囲を指定する場合、レンジフィールドＦｄ２に「１１」に設定した確認要求パケットを送信する。図９は、レンジフィールドＦｄ２の値の定義の一例を示している。レンジフィールドＦｄ２には、１ｍ又は６ｍといった、具体的な距離値を示すコードが挿入されても良い。

　・エリアフィールドについて
　エリアフィールドＦｄ３は、キーデバイス／ユーザの探索対象エリアを指定するビット値が挿入されるフィールドである。ここでは一例としてエリアフィールドＦｄ３の長さは４ビットに設定されている。例えば統括ＥＣＵ４１は、探索対象エリアとして、車外を指定する場合、レンジフィールドＦｄ２に「０００１」に設定した確認要求パケットを送信する。車外のどこまでを探索範囲とするかは前述のレンジフィールドＦｄ２の設定値にて規定されうる。また、統括ＥＣＵ４１は、探索対象エリアとして、車内を指定する場合、レンジフィールドＦｄ２に「１０００」に設定した確認要求パケットを送信する。図１０は、エリアフィールドＦｄ３の値の定義の一例を示している。なお、図１０におけるトランク外とは、車外のうち、トランクから所定距離以内となる範囲である。フード外とは、車外のうち、車両の前端から所定距離以内となる範囲である。

　なお、他の態様においてレンジフィールドＦｄ２は、エリアフィールドＦｄ３に統合されていても良い。仮に車外のエリアが、方向と距離の組み合わせによって、図１１に示すようにサブエリアＡ３１～Ａ３６、Ａ４１～Ａ４６に細分化されている場合、レンジフィールドＦｄ２は省略可能である。エリアフィールドＦｄ３には、探索対象エリアとするサブエリアに対応するコードが挿入されれば良い。なお、図１０に示す探索対象エリアの設定例は一例である。探索対象エリアの区分は、車外と車内の２つだけであってもよい。また、探索対象エリアの指定区分は、キャビン内、トランク内、車外近傍エリア、車外の４つであってもよい。その他、エリアフィールドＦｄ３の長さは、可変であってもよい。エリアフィールドＦｄ３の長さが可変に設定可能な場合、統括ＥＣＵ４１は探索対象とするエリアごとのコードをエリアフィールドＦｄ３に挿入した確認要求パケットを送信すれば良い。

　・ターゲットフィールドについて
　ターゲットフィールドＦｄ４は、位置確認（探索）のターゲットとするキーデバイス／ユーザを指定するビット値が挿入されるフィールドである。ターゲットの指定は管理ＩＤを用いて実現される。ここでは一例としてターゲットフィールドＦｄ４の長さは５ビットに設定されており、各ビットに管理ＩＤが割り当てられている。例えば第１ビットは管理ＩＤ＝１、第２ビットは管理ＩＤ＝２、第３ビットは管理ＩＤ＝３、第４ビットは管理ＩＤ＝４がそれぞれ割り当てられている。なお、最上位ビット（左端ビット）は、未割り当てである。図１２は、ターゲットフィールドＦｄ４の設定値ごとの定義の一例を示している。

　統括ＥＣＵ４１は、探索対象として、管理ＩＤ＝１に対応するデバイス／ユーザを指定する場合、ターゲットフィールドＦｄ４に「００００１」に設定した確認要求パケットを送信する。また、統括ＥＣＵ４１は、探索対象として、管理ＩＤ＝１～２に対応するデバイス／ユーザを指定する場合、ターゲットフィールドＦｄ４に「０００１１」に設定した確認要求パケットを送信する。本実施形態では管理ＩＤは４番までしか使われていないため、ターゲットフィールドＦｄ４に「０１１１１」を設定した確認要求パケットはすべてのデバイス／ユーザを探索対象に指定した確認要求パケットに相当する。

　なお、上記の例では管理ＩＤの最大数がターゲットフィールドＦｄ４のビット数に依存する。故に、登録可能なユーザ数には上限値が存在しうる。また、登録可能なユーザ数を増やすためにはターゲットフィールドＦｄ４のビット数を拡張する必要がある。このような課題を解決するための１つの構成としてターゲットフィールドＦｄ４の長さは、可変であってもよい。また、他の態様として、ターゲットフィールドＦｄ４は、認証対象を示す管理ＩＤが挿入されるフィールドであってもよい。その場合、ターゲットフィールドＦｄ４は管理ＩＤの長さに応じたビット数を有する。また、複数の認証対象を指定可能なように、確認要求パケットは、複数のターゲットフィールドＦｄ４を備えていても良い。統括ＥＣＵ４１は、すべての管理ＩＤを指定するコードである全指定コードを利用可能に構成されていても良い。全指定コードは、すべてのビットに１を設定したコード（１１１１１）、又は、特定の制御ビットに１を設定したコード（１００００）といった、所定のコードであってよい。

　各認証ＥＣＵ６ｘはターゲットフィールドＦｄ４で指定された管理ＩＤを、自装置の機能に応じたターゲット識別番号に変換した上で作動する。例えばスマートキー認証ＥＣＵ６１は、管理ＩＤ＝１が設定された確認要求パケットを受信した場合、管理ＩＤ＝１に紐づくキーＩＤを有するスマートキー２を探索する。また、モバイル認証ＥＣＵ６２は、管理ＩＤ＝１が設定された確認要求パケットを受信した場合、管理ＩＤ＝１に紐づくデバイスＩＤを有する携帯デバイス３を探索する。顔認証ＥＣＵ６３や指紋認証ＥＣＵ６４は、管理ＩＤ＝１が設定された確認要求パケットを受信した場合、管理ＩＤ＝１に紐づくユーザを認証するための処理を実行する。このように各認証ＥＣＵ６ｘは、探索対象にかかる共通の指示内容に対して、自装置の機能に応じた個別の解釈を行い、動作する。

　・セキュリティフィールドについて
　セキュリティフィールドＦｄ５は、位置確認の確実性（安全性）を示すセキュリティレベルを指定するビット値が挿入されるフィールドである。ここでは一例として統括ＥＣＵ４１はセキュリティレベルを１～３の３段階で指定可能に構成されている。それに伴い、ターゲットフィールドＦｄ４の長さは２ビットに設定されている。統括ＥＣＵ４１は、セキュリティレベルとして、レベル１を指定する場合、セキュリティフィールドＦｄ５に「０１」に設定した確認要求パケットを送信する。また、統括ＥＣＵ４１は、セキュリティレベルとして、レベル２を指定する場合、セキュリティフィールドＦｄ５に「１０」に設定した確認要求パケットを送信する。統括ＥＣＵ４１は、セキュリティレベルとしてレベル３を指定する場合、セキュリティフィールドＦｄ５に「１１」に設定した確認要求パケットを送信する。図１３は、セキュリティフィールドＦｄ５の値ごとの定義例を示している。

　認証ＥＣＵ６ｘごとに、セキュリティレベルの設定値の解釈（作動）は異なっていてよい。例えばスマートキー認証ＥＣＵ６１及びモバイル認証ＥＣＵ６２といった、無線認証ＥＣＵにとってのセキュリティレベル２は、コード照合は実施するものの、中継検証処理は省略するレベルであってよい。無線認証ＥＣＵにとってのセキュリティレベル３は、コード照合及び中継検証処理を実行するレベルであってよい。セキュリティレベル１は、コード照合すら実施しないレベルであってよい。セキュリティレベル１は、デバイスＩＤ／キーＩＤによる通信相手の特定と位置判定のみを実施するレベルであってよい。無線認証ＥＣＵにとってのセキュリティレベルは、コード照合の必要性や、中継判定の必要性を示す情報に相当する。また、顔認証ＥＣＵ６３及び指紋認証ＥＣＵ６４といった生体認証ＥＣＵは、セキュリティレベルが高いほど多くの特徴量を用いて高精度に識別処理を行ってよい。各認証ＥＣＵ６ｘは、セキュリティレベルにかかる共通の指示内容に対して、自装置の機能に応じた個別の解釈を行い、動作してよい。

　・手段フィールドについて
　手段フィールドＦｄ６は、認証手段／認証方式を指定するビット値が挿入されるフィールドである。ここでは一例として手段フィールドＦｄ６の長さは２ビットに設定されている。統括ＥＣＵ４１は、認証手段として第１手段を指定する場合、手段フィールドＦｄ６に「０１」に設定した確認要求パケットを送信する。また、統括ＥＣＵ４１は、認証手段として第２手段を指定する場合、手段フィールドＦｄ６に「１０」に設定した確認要求パケットを送信する。認証手段として第１手段と第２手段の両方を使用することを指定する場合、手段フィールドＦｄ６に「１１」に設定した確認要求パケットを送信する。図１４は、手段フィールドＦｄ６の値ごとの定義例を示す図である。

　第１手段はメインの（通常の）認証手段に対応し、第２手段はサブ（予備）の認証手段に対応しうる。スマートキー認証ＥＣＵ６１にとっての第１手段とはＬＦ認証であり、第２手段とはトランスポンダ認証である。モバイル認証ＥＣＵ６２にとっての第１手段とはＢＬＥ認証を指し、第２手段とはＮＦＣ認証である。認証手段を１つしか持っていない認証ＥＣＵ６ｘにとっては手段フィールドＦｄ６の値によらず、当該認証手段を適用してよい。例えば顔認証ＥＣＵ６３及び指紋認証ＥＣＵ６４は、手段フィールドＦｄ６の値によらず、顔画像／指紋情報を用いた認証処理を実施してよい。このように各認証ＥＣＵ６ｘは、認証手段にかかる共通の指示内容に対して、自装置の機能に応じた個別の解釈を行い、動作する。探索の手段は、探索方法と言いかえることができる。

　第２要求フィールドＦｑ２は、第１要求フィールドＦｑ１で指定したエリアとは別のエリアを対象としたターゲットの探索を要求するためのフィールドである。第２要求フィールドＦｑ２の構成は第１要求フィールドＦｑ１と同様である。なお、第１要求フィールドＦｑ１で指定した内容で必要十分である場合、第２要求フィールドＦｑ２の全てのビットは０に設定されうる。

　＜開錠制御にかかるシステム作動について＞
　ここでは図１５に示すシーケンス図を用いて、統括ＥＣＵ４１が開錠操作を受け付けた際の統括ＥＣＵ４１及び各認証ＥＣＵ６ｘの作動について説明する。前提として車両Ｈｖは施錠された状態である。また、開錠操作を行ったユーザは、スマートキー２は保持しているものの、携帯デバイス３は保持していない状態で、運転席用のドアから１ｍ以内に立っているものとする。当該ユーザが保持するスマートキー２のキーＩＤは１であり、対応する管理ＩＤも１に設定されているものとする。

　まず統括ＥＣＵ４１が、施開錠センサ４２等からの入力信号に基づいて、ユーザによる開錠操作を検出すると（Ｓ１１）、各認証ＥＣＵ６ｘに向けて確認要求パケットを送信する。前述の通り、統括ＥＣＵ４１は、確認要求パケットを各認証ＥＣＵ６ｘへ向けて順次ユニキャストしても良いし、マルチキャストの態様で一斉送信しても良い。ここでは一例として統括ＥＣＵ４１は、ユーザの開錠操作に反応して、図１６に示すようにスマートキー認証ＥＣＵ６１とモバイル認証ＥＣＵ６２を要求対象に設定した確認要求パケットを送信する。すなわち、装置フィールドＦｄ１に「００１１」を設定した確認要求パケットを送信する。要求対象に指定する認証ＥＣＵ６ｘの組合せは、設計者やユーザ設定によって適宜変更されてよい。統括ＥＣＵ４１は、ユーザの開錠操作に反応して、全ての認証ＥＣＵ６ｘを要求対象に設定した確認要求パケットを送信してもよい。また、要求対象は車両Ｈｖの状態や、スマート認証処理の結果に応じて動的に変更されても良い。統括ＥＣＵ４１は直近所定時間（１分）以内にＬＦ認証やＢＬＥ認証が失敗した履歴が存在する場合には、生体認証ＥＣＵを要求対象に加えた確認要求パケットを送信しても良い。

　統括ＥＣＵ４１は、ユーザの開錠操作を検出した場合、基本的には車外近傍エリアを探索対象エリアに指定するとともに、全てのキーデバイス／ユーザをターゲットに設定した確認要求パケットを送信する。具体的にはレンジフィールドＦｄ２を「０１」に、エリアフィールドＦｄ３を「０００１」に、ターゲットフィールドＦｄ４を「０１１１１」にそれぞれ設定した確認要求パケットを送信する。なお、開錠操作受付時の探索対象エリアは車外近傍エリアだけでよい。換言すれば、その他のエリアまで探索する必要はない。そのため、第２要求フィールドＦｑ２は空白であってよい。

　統括ＥＣＵ４１は、シーンに応じてセキュリティレベルを選択する。例えば統括ＥＣＵ４１は、車両Ｈｖの開錠や走行用電源オンといった利用開始にかかる認証時には、セキュリティレベルを最高レベルである３（「１１」）に設定する。一方、統括ＥＣＵ４１は、車両Ｈｖの施錠や走行電源オフといった利用終了にかかる認証時にはセキュリティレベルを２（「１０」）に設定する。他の態様として統括ＥＣＵ４１は常にセキュリティレベルを３（「１１」）に設定してもよい。

　本実施形態の統括ＥＣＵ４１は、常に手段フィールドＦｄ６には「１１」に設定する。もちろん、統括ＥＣＵ４１は、特定のシチュエーションにおいては、手段フィールドＦｄ６に「１０」や「０１」を設定しても良い。

　各認証ＥＣＵ６ｘは確認要求パケットを受信すると（Ｓ１２Ｂ）、自装置が要求対象として指定されているか否かを判定する。要求対象に設定されていない認証ＥＣＵ６ｘは、仮に確認要求パケットを受信しても作動せずに待機状態／スリープ状態を維持する。なお、そもそも統括ＥＣＵ４１は要求対象にのみ確認要求パケットを送信しても良い。自装置が要求対象として指定された確認要求パケットを受信した認証ＥＣＵ６ｘは、要求内容に応じた態様でターゲットの探索を実施する。

　ここではステップＳ１１で送信された確認要求パケットに対し、スマートキー認証ＥＣＵ６１とモバイル認証ＥＣＵ６２は反応する一方、顔認証ＥＣＵ６３や指紋認証ＥＣＵ６４は確認要求パケットに対して反応しない。なお、顔認証ＥＣＵ６３や指紋認証ＥＣＵ６４といった要求対象以外の認証ＥＣＵ６ｘは、認証自体は実行しないものの、確認要求パケットを受信したことを示す応答（Ａｃｋ／Ｎａｃｋ）は返送するように構成されていても良い。

　スマートキー認証ＥＣＵ６１は、受信した確認要求パケットにもとづきスマートキー２の探索処理を実行する（Ｓ１３）。すなわち、スマートキー認証ＥＣＵ６１は、車外に通信エリアを形成する各ＬＦ送信機４５から順にＬＦ信号を送信し、且つ、応答が得られたＬＦ送信機４５を用いたコード照合処理及び中継検証処理を実施する。探索対象とするスマートキー２はターゲットフィールドＦｄ４の設定値に応じて定まる。ここでは、車両Ｈｖに紐付けられている全てのスマートキー２が探索される。

　モバイル認証ＥＣＵ６２もまた、受信した確認要求パケットにもとづき携帯デバイス３の探索処理を実行する（Ｓ１４）。すなわち、モバイル認証ＥＣＵ６２に登録されている全ての携帯デバイス３を対象として、位置判定、コード照合、中継判定を順に実施する。

　要求対象に指定された認証ＥＣＵ６ｘは、探索処理が完了次第、その結果を示すパケットである結果通知パケットを統括ＥＣＵ４１に返送する。本例ではスマートキー認証ＥＣＵ６１及びモバイル認証ＥＣＵ６２は、それぞれ一連の探索処理が完了すると、その結果を示すパケットである結果通知パケットを統括ＥＣＵ４１に返送する（Ｓ１５ａ、Ｓ１６ａ）。

　結果通知パケットのペイロードもまた、図１７及び図１８に示すように、確認要求パケットと同様のフォーマットを備える。すなわち、結果通知パケットは、装置フィールドＦｄ１、レンジフィールドＦｄ２、エリアフィールドＦｄ３、ターゲットフィールドＦｄ４、セキュリティフィールドＦｄ５、手段フィールドＦｄ６を備える。なお、図１７はスマートキー認証ＥＣＵ６１が送信する結果通知パケットのペイロードの一例を、図１８はモバイル認証ＥＣＵ６２が送信する結果通知パケットのペイロードの一例を、それぞれ示している。

　結果通知パケットにおける装置フィールドＦｄ１は、報告元を示す。例えばスマートキー認証ＥＣＵ６１が出力する結果通知パケットの装置フィールドＦｄ１には「０００１」が設定される。結果通知パケットのレンジフィールドＦｄ２及びエリアフィールドＦｄ３には、実際にターゲットを探索した範囲、すなわち確認要求パケットのレンジフィールドＦｄ２及びエリアフィールドＦｄ３と同じ値が設定される。なお、他の態様として、エリアフィールドＦｄ３には指定された探索対象エリアのうち、実際にターゲットが発見されたエリアを示すビット列（コード）が挿入されても良い。例えばスマートキー認証ＥＣＵ６１は、運転席の外側でスマートキー２を発見した場合には、エリアフィールドＦｄ３に「００１０」を設定した結果通知パケットを送信しても良い。

　結果通知パケットにおけるターゲットフィールドＦｄ４には、発見されたターゲットの管理ＩＤに対応する値が挿入される。例えば認証ＥＣＵ６ｘは管理ＩＤ＝２に対応するターゲットを発見できた場合、ターゲットフィールドＦｄ４に「０００１０」を設定した結果通知パケットを送信する。また、ターゲットを１つも発見できなかった認証ＥＣＵ６ｘは、ターゲットフィールドＦｄ４に「０００００」を設定した結果通知パケットを送信する。

　今回の例示ではスマートキー認証ＥＣＵ６１は、管理ＩＤ＝１のスマートキー２を発見するため、ターゲットフィールドＦｄ４に「００００１」を設定した結果通知パケットを送信する。一方、モバイル認証ＥＣＵ６２は、携帯デバイス３を発見できないため、ターゲットフィールドＦｄ４に「０００００」を設定した結果通知パケットを送信する。

　結果通知パケットにおけるセキュリティフィールドＦｄ５には、確認要求パケットのセキュリティフィールドＦｄ５と同じ値が設定される。結果通知パケットにおける手段フィールドＦｄ６には、ターゲットの発見に使用された手段に対応する値が設定される。例えばスマートキー認証ＥＣＵ６１は第１手段としてのＬＦ認証でスマートキー２を発見した場合には、手段フィールドＦｄ６に「０１」を設定する。なお、認証ＥＣＵ６ｘは、統括ＥＣＵ４１から指定された手段で１つもターゲットを発見できなかった場合、手段フィールドＦｄ６には、確認要求パケットの手段フィールドＦｄ６と同じ値（例えば「１１」）が設定される。

　統括ＥＣＵ４１は、確認要求パケットを送信後、随時、各認証ＥＣＵ６ｘからの結果通知パケットを順に受信する。本例では統括ＥＣＵ４１はスマートキー認証ＥＣＵ６１及びモバイル認証ＥＣＵ６２のそれぞれから結果通知パケットを受信する（Ｓ１５Ｂ、Ｓ１６Ｂ）。そして、統括ＥＣＵ４１は、各認証ＥＣＵ６ｘでの探索結果を統合する（Ｓ１７）。ここでの探索結果との統合は、車両Ｈｖのキーデバイス／ユーザの存在が確認された場所を取りまとめることに相当する。

　上記説明の通り、本例ではスマートキー認証ＥＣＵ６１からの結果通知パケットは、管理ＩＤ＝１に紐づくスマートキー２が車外近傍エリアに存在することを示すデータとなっている。また、モバイル認証ＥＣＵ６２からの結果通知パケットは、何れの携帯デバイス３も発見できなかったことを示すデータとなっている。探索結果を統合した結果は、スマートキー２が車外近傍エリアに存在することを示すデータとなる。統括ＥＣＵ４１は、照合済みのスマートキー２が車外近傍エリアに存在することを踏まえ、ドアロックモータを制御し、各ドアを開錠する。すなわち、車両Ｈｖを開錠状態に設定する（Ｓ１８）。

　＜施錠制御にかかるシステム作動について＞
　次に、統括ＥＣＵ４１が施錠操作を受け付けた際の統括ＥＣＵ４１及び各認証ＥＣＵ６ｘの作動について説明する。前提として車両Ｈｖは開錠状態である。また、施錠操作を行ったユーザは、管理ＩＤ＝２に対応する携帯デバイス３は保持しているものの、スマートキー２は保持していない状態で、運転席用のドアから１ｍ以内に立っているものとする。なお、車内にはスマートキー２や携帯デバイス３の置き忘れはないものとする。

　施錠操作受け付け時の作動シーケンスは、概略的には開錠操作受付時と同じである。統括ＥＣＵ４１は、施開錠センサ４２等からの入力信号に基づいて、ユーザによる施錠操作を検出すると、各認証ＥＣＵ６ｘに向けて確認要求パケットを送信する。ここでは一例として統括ＥＣＵ４１は、ユーザの施錠操作に反応して、図１９に示すようにスマートキー認証ＥＣＵ６１とモバイル認証ＥＣＵ６２を要求対象に設定した確認要求パケットを送信する。もちろん、要求対象に指定する認証ＥＣＵ６ｘの組合せは、設計者やユーザ設定によって適宜変更可能である。一例としてレンジフィールドＦｄ２の設定値は「０１」とするが、レンジフィールドＦｄ２の設定値は「１１」であってもよい。

　施錠制御に向けた認証要求では、キャビン内へのキーデバイスの置き忘れを警告するために、車外近傍エリアだけでなく、キャビン内も探索対象に含めることが好ましい。そのような事情から本実施形態の統括ＥＣＵ４１は、第１要求フィールドＦｑ１は車外近傍エリアを探索対象エリアに指定するフィールドとして用い、第２要求フィールドＦｑ２はキャビン内を探索対象エリアに指定するフィールドとして用いる。

　具体的には、第１のエリアフィールドＦｄ３を「０００１」に、第２のエリアフィールドＦｄ３を「１００１」に、それぞれ設定した確認要求パケットを送信する。第１のエリアフィールドとは、第１要求フィールドＦｑ１のエリアフィールドＦｄ３である。第２のエリアフィールドとは、第２要求フィールドＦｑ２のエリアフィールドＦｄ３である。探索対象は第１、第２要求フィールドともに全てのキーデバイス／ユーザを意味するコード（「０１１１１」など）を採用可能である。

　施錠に向けた認証時には中継検証処理まで行う必要性は高くない。そのため、統括ＥＣＵ４１は、施錠操作をトリガとして送信する確認要求パケットにおいては、セキュリティレベルを２（「１０」）に設定可能である。車外の認証においてはスマート認証だけでなく略接触型認証を含めるべく手段フィールドＦｄ６に「１１」を設定する。一方、施錠時にはキャビン内に乗員がいないことを前提とするため、略接触型認証に相当する第２手段は除外可能である。よって、第２要求フィールドＦｑ２の手段フィールドＦｄ６は「０１」が設定される。

　各認証ＥＣＵ６ｘは、自装置が要求対象として指定された確認要求パケットを受信すると、要求内容に応じた態様でターゲットの探索を実施する。例えばスマートキー認証ＥＣＵ６１は、車外向けＬＦ送信機を用いて車外近傍エリアにスマートキー２が在るか否かの判定を実施したのちに、ＬＦ送信機４５ｐを用いてキャビン内にスマートキー２が在るか否かを判定する。また、モバイル認証ＥＣＵ６２は、受信強度に基づく位置判定を実施した後に、接続デバイスのコード照合を実施する。

　要求対象に指定された認証ＥＣＵ６ｘは、探索処理が完了すると、その結果を示すパケットである結果通知パケットを統括ＥＣＵ４１に返送する。本例ではスマートキー認証ＥＣＵ６１は、図２０に示すように、第１要求フィールドＦｑ１及び第２要求フィールドＦｑ２のターゲットフィールドＦｄ４に「０００００」を設定した結果通知パケットを送信する。つまりスマートキー認証ＥＣＵ６１は、指定された２つのターゲットフィールドＦｄ４の何れにもキーデバイスを発見しなかったことを示すコードを配置して返送する。

　また、モバイル認証ＥＣＵ６２は、図２１に示すように第１要求フィールドＦｑ１のターゲットフィールドＦｄ４に「０００１０」を、第２要求フィールドＦｑ２のターゲットフィールドＦｄ４には「０００００」を設定した結果通知パケットを送信する。つまりモバイル認証ＥＣＵ６２は、第１ターゲットフィールドＦｄ４に管理ＩＤ＝２に対応するキーデバイスを発見したことを示すコードを配置して返送する。

　統括ＥＣＵ４１は各認証ＥＣＵ６ｘからの結果通知パケットを受信すると、これらの探索結果を統合し、統合結果に応じた制御を実施する。本例では、統括ＥＣＵ４１は携帯デバイス３が車外近傍エリアに存在し、かつ、キャビン内にキーデバイスが存在しないことを踏まえ、ドアロックモータを制御し、各ドアを施錠する。すなわち、車両Ｈｖを施錠状態に設定する。

　なお、施錠時の探索結果として車内にキーデバイスが残っていることが検知された場合、統括ＥＣＵ４１は、閉じ込め警告処理を実施しても良い。閉じ込め警告処理は、スピーカやディスプレイを用いてユーザにキーデバイスが車内に残っていることを通知する処理である。また、施錠時の探索結果として車内にキーデバイスが残っていることが検知された場合、車外での認証が成功していることを条件として、残留デバイス無効化処理を実施しても良い。残留デバイス無効化処理は、車内に残されたキーデバイスを無効化する処理である。無効化とは、一時的に車両Ｈｖのキーとして機能させなくすることを意味する。無効化は、通信相手から除外すること、又は、無線認証処理の対象外に設定することであってよい。残留デバイスを無効化しておくことで第３者が不正に車両Ｈｖを開錠する恐れを低減できる。

　＜効果＞
　上記の構成によれば統括ＥＣＵ４１は各認証ＥＣＵ６ｘに対して共通の指示を出力すればよい。換言すれば、認証ＥＣＵ６ｘごとの機能に応じた認証ＥＣＵ６ｘごとに個別の指示信号を出力する必要はない。各認証ＥＣＵ６ｘは、統括ＥＣＵ４１から入力される共通化された指示を、自装置の機能に応じた指示内容へと変換した上で、作動するためである。

　そのため、上記のシステム構成によれば、統括ＥＣＵ４１の処理負荷を低減できる。また、認証ＥＣＵ６ｘを新規に追加した場合であっても、統括ＥＣＵ４１には要求対象の候補を追加するだけでよい。認証ＥＣＵ６ｘの変更や追加に伴って、統括ＥＣＵ４１のプログラムを大幅に修正する必要は生じない。つまり、上記構成によれば、車両モデルごとの認証装置の違いや、経時的な認証装置の入れ替え／機能変更に対する柔軟性を高めることができる。

　以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。下記の種々の補足及び変形例は、技術的な矛盾が生じない範囲において適宜組み合わせて実施されてよい。なお、以上で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略することがある。また、構成の一部のみに言及している場合、他の部分については上記説明を適用することができる。

　＜各種通信機の設置位置についての補足＞
　以上で述べたＬＦ送信機４５、ＴＰステーション４７、ＢＬＥ通信機４８、ＮＦＣ通信機４９、カメラ５０、及び指紋リーダ５１の配置態様は一例であって、各デバイスの設置数及び設置箇所は適宜変更されてよい。ＬＦ送信機４５は、後部座席用の外側ドアハンドル、又は車両前端部にも配置されていても良い。ＢＬＥ通信機４８は、Ｃピラー、車内天井部、又は、ブレーキペダル付近に配置されていても良い。

　＜携帯デバイスの位置判定方法の変形例＞
　モバイル認証ＥＣＵ６２は、複数のＢＬＥ通信機４８での測距値と、各ＢＬＥ通信機４８の車両Ｈｖにおける搭載位置を組み合わせることにより、車両Ｈｖに対する携帯デバイス３の位置座標を特定してもよい。各ＢＬＥ通信機４８の設置位置は既知である。そのため、モバイル認証ＥＣＵ６２は、３つ以上のＢＬＥ通信機４８から携帯デバイス３までの距離情報を取得できれば、３点測位／多点測位により携帯デバイス３の位置座標を特定可能である。携帯デバイス３の位置座標は、車両座標系で表現されてよい。モバイル認証ＥＣＵ６２は、測距値を用いて算出されたデバイス位置座標に基づいて携帯デバイス３が存在するエリアを判定してもよい。

　＜携帯デバイスと車載システムとの通信方式の変形例＞
　車載システム１と携帯デバイス３との通信規格としては、Ｗｉ－Ｆｉ（登録商標）やEnOcean（登録商標）、Ｗｉ－ＳＵＮ（Wireless Smart Utility Network）などであってよい。Ｗｉ－Ｆｉ規格は、ＩＥＥＥ８０２．１１ｎやＩＥＥＥ８０２．１１ａｘといった、任意の規格であってよい。尚、ＩＥＥＥ（登録商標）は、Institute of Electrical and Electronics Engineersの略であり、米国電気電子学会を意味する。

　その他、車載システム１と携帯デバイス３との通信方式、換言すれば、近距離通信方式は、３ＧＨｚ以上の周波数帯を用いるＵＷＢ－ＩＲ（Ultra Wide Band - Impulse Radio）であってもよい。近距離通信は高周波電波を用いて実施される。本開示における高周波電波とは、例えば２．４ＧＨｚなど、９００ＭＨｚ以上の電波を指す。高周波電波には１ＧＨｚ以上の電波に限らず、９２０ＧＨｚなどのサブギガ帯の電波も含まれる。

　＜認証ＥＣＵの役割分担についての補足＞
　車載システム１は、デバイスタイプごとではなく、通信方式ごと、又は、認証手段ごとに認証ＥＣＵ６ｘを備えていても良い。例えば車載システム１は図２２に示すように、通信方式ごとの認証ＥＣＵ６ｘを備えていても良い。図２２に示すＬＦ認証ＥＣＵ６Ａは、ＬＦ認証を実施するＥＣＵであり、ＢＬＥ認証ＥＣＵ６ＢはＢＬＥ認証を実施するＥＣＵである。ＮＦＣ認証ＥＣＵ６Ｃは、ＮＦＣ認証を実施するＥＣＵであり、トランスポンダ認証ＥＣＵ６Ｄはトランスポンダ認証を実施するＥＣＵである。ＵＷＢ認証ＥＣＵ６Ｅは、ＵＷＢ通信を用いてキーデバイスの探索を行うＥＣＵである。顔認証ＥＣＵ６Ｆ及び指紋認証ＥＣＵ６Ｇは前述の顔認証ＥＣＵ６３、指紋認証ＥＣＵ６４に相当する。車載システム１が備える認証ＥＣＵ６ｘの組合せや機能配置は適宜変更可能である。

　＜測距値の算出方法の補足＞
　ＲＴＴは、通信相手に向けて応答要求信号を送信してから、通信相手からの応答信号を受信するまでの時間である。ＢＬＥ通信機４８は、実際に信号を送信してから受信するまでの経過時間に対し、所定の補正処理を施した値をＲＴＴとして用いてもよい。補正処理は、携帯デバイス３で生じる応答処理時間の想定値の減算、又は、ＢＬＥ通信機４８で生じうる遅延時間の想定値の減算であってよい。また、２周波位相差は、ＢＬＥ通信機４８と携帯デバイス３とが連続波（ＣＷ：Continuous Wave）信号を送受信することで特定されるパラメータであって、２つの周波数のそれぞれで観測された送受信位相差の差である。２周波位相差は、周波数の変化による送受信位相差の変位量に対応する。

　ＢＬＥ通信機４８は、ＢＬＥ通信に供される周波数の組み合わせごとに２周波位相差を算出及び出力してもよい。測距値の生成（演算）機能は、ＢＬＥ通信機４８に内蔵されていても良いし、モバイル認証ＥＣＵ６２が備えていても良い。ＢＬＥ通信機４８とモバイル認証ＥＣＵ６２との機能分担は適宜変更されてよい。

　＜適用車両のバリエーションについて＞
　上記の説明における車両Ｈｖは、一例として個人によって所有される４輪自動車である。車両Ｈｖのユーザは、所有者（オーナー）、及び、その家族／友人であってよい。車両Ｈｖは、会社組織が保有する社用車や、公的機関が保有する公用車であってもよい。車両Ｈｖが社用車や公用車である場合には、当該車両Ｈｖを管理する組織に属する人物がユーザとなりうる。車両Ｈｖは、貸出サービスに供される車両（いわゆるレンタカー）であってもよいし、カーシェアリングサービスに供される車両（いわゆるシェアカー）であってもよい。車両Ｈｖが上記サービスに供される車両である場合には、それらのサービスの利用契約を行っており、且つ、サービスの利用予約に基づき、一時的に当該車両Ｈｖを利用する権限を有する人物がユーザとなりうる。

　＜付言（１）＞
　本明細書には、以下に列挙する複数の技術的思想と、それらの複数の組み合わせが開示されている。また、以下の車両制御システムに対応する位置確認装置、位置確認方法、コンピュータに下記の処理を実行させる命令を含むプログラム、及び、そのプログラムを記録した記憶媒体も本開示の範囲に含まれる。

　［技術的思想１］
　装置ごとに予め登録されているターゲットの位置確認をそれぞれ異なる方式で行う複数の位置確認装置（６ｘ）と、
　複数の位置確認装置からの信号に基づいて車両制御にかかるアプリケーションを実行する統括制御装置（４１）と、を含む車両制御システムであって、
　統括制御装置は、
　車載センサからの信号に基づき所定の確認イベントの発生を検知することと、
　確認イベントが検知されたことに基づいて、複数の位置確認装置に対し、要求事項を示す共通の確認要求メッセージを送信することと、を実行し、
　位置確認装置は、
　統括制御装置から送信された確認要求メッセージを受信することと、
　受信した確認要求メッセージに示される要求内容を自装置の機能に応じた内容に変換した上で、要求内容に応じた態様で位置確認を実行することと、
　位置確認の結果を示す結果通知メッセージを統括制御装置に返送することと、を実行し、
　統括制御装置が、位置確認装置から返送されてくる結果通知メッセージをもとに、車両制御の実行可否を判断するように構成されている車両制御システム。

　［技術的思想２］
　複数のターゲットが登録されている、技術的思想１に記載の車両制御システムであって、
　確認要求メッセージは、複数のターゲットのうち、探索対象とするターゲットを指定するコードを含み、
　位置確認装置は、確認要求メッセージで指定されているターゲットを探索する、車両制御システム。

　［技術的思想３］
　技術的思想１又は２に記載の車両制御システムであって、
　確認要求メッセージは、ターゲットを探索するエリアである探索対象エリアのコードを含み、
　位置確認装置は、確認要求メッセージで指定されている探索対象エリアにターゲットが存在するか否かを判定する、車両制御システム。

　［技術的思想４］
　技術的思想３に記載の車両制御システムであって、
　確認要求メッセージは、探索対象エリアを２つ以上設定可能であって、かつ、各探索対象エリアごとにターゲットを指定可能に構成されている車両制御システム。

　［技術的思想５］
　技術的思想１から４の何れか１つに記載の車両制御システムであって、
　確認要求メッセージは、位置確認のセキュリティレベルを指定するコードを含み、
　位置確認装置は、指定されたセキュリティレベルに応じた態様で位置確認を実施する、車両制御システム。

　［技術的思想６］
　複数の探索方法でターゲットを探索可能に構成された位置確認装置を含む、技術的思想１から５の何れか１つに記載の車両制御システムであって、
　確認要求メッセージは、ターゲットの探索方法を指定する情報を含む、車両制御システム。

　［技術的思想７］
　技術的思想１から６の何れか１つに記載の車両制御システムであって、
　確認要求メッセージは、複数の位置確認装置のうち、動作させる位置確認装置である要求対象を指定するコードを含み、
　確認要求メッセージにて要求対象に指定されている位置確認装置は、当該確認要求メッセージに示される内容に応じた位置確認を実行する一方、
　確認要求メッセージにて要求対象に指定されていない位置確認装置は、位置確認を実行しない、車両制御システム。

　［技術的思想８］
　車両に搭載された通信機との無線通信によって車両の鍵として機能するキーデバイスとして、スマートキーと携帯デバイスとを登録可能に構成されている技術的思想１から７の何れか１つに記載の車両制御システムであって、
　確認要求メッセージは、探索対象とするキーデバイスの種類を指定するコードを含み、
　確認要求メッセージで指定されている種類のキーデバイスを探索可能な位置確認装置は、当該確認要求メッセージに示される内容に応じた位置確認を実行する一方、
　確認要求メッセージで指定されている種類のキーデバイスを探索不能な位置確認装置は、位置確認を実行しない、車両制御システム。

　［技術的思想９］
　技術的思想１から８の何れか１つに記載の車両制御システムであって、
　結果通知メッセージは、発見されたターゲットの情報を含む、車両制御システム。

　［技術的思想１０］
　技術的思想１から９の何れか１つに記載の車両制御システムであって、
　結果通知メッセージは、ターゲットが発見されたエリアの情報を含む、車両制御システム。

　＜付言（２）＞
　本開示に示す種々のフローチャートは何れも一例であって、フローチャートを構成するステップの数や、処理の実行順は適宜変更可能である。また、本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。プロセッサ（演算コア）としては、ＣＰＵや、ＭＰＵ、ＧＰＵ、ＤＦＰ（Data Flow Processor）などを採用可能である。本開示のコンピュータは、システムオンチップ（ＳｏＣ：System-on-Chip）、ＩＣ、及びＦＰＧＡの何れかを用いて実現されていてもよい。ＩＣの概念には、ＡＳＩＣ（Application Specific Integrated Circuit）も含まれる。コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体（non- transitory tangible storage medium）に記憶されていればよい。プログラムの記録媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等を採用可能である。

Claims

　装置ごとに予め登録されているターゲットの位置確認をそれぞれ異なる方式で行う複数の位置確認装置（６ｘ）と、
　複数の前記位置確認装置からの信号に基づいて車両制御にかかるアプリケーションを実行する統括制御装置（４１）と、を含む車両制御システムであって、
　前記統括制御装置は、
　車載センサからの信号に基づき所定の確認イベントの発生を検知することと、
　前記確認イベントが検知されたことに基づいて、複数の前記位置確認装置に対し、要求事項を示す共通の確認要求メッセージを送信することと、を実行し、
　前記位置確認装置は、
　前記統括制御装置から送信された前記確認要求メッセージを受信することと、
　受信した前記確認要求メッセージに示される要求内容を自装置の機能に応じた内容に変換した上で、前記要求内容に応じた態様で前記位置確認を実行することと、
　前記位置確認の結果を示す結果通知メッセージを前記統括制御装置に返送することと、を実行し、
　前記統括制御装置が、前記位置確認装置から返送されてくる前記結果通知メッセージをもとに、前記車両制御の実行可否を判断するように構成されている車両制御システム。
　複数の前記ターゲットが登録されている、請求項１に記載の車両制御システムであって、
　前記確認要求メッセージは、複数の前記ターゲットのうち、探索対象とする前記ターゲットを指定するコードを含み、
　前記位置確認装置は、前記確認要求メッセージで指定されている前記ターゲットを探索する、車両制御システム。
　請求項１又は２に記載の車両制御システムであって、
　前記確認要求メッセージは、前記ターゲットを探索するエリアである探索対象エリアのコードを含み、
　前記位置確認装置は、前記確認要求メッセージで指定されている前記探索対象エリアに前記ターゲットが存在するか否かを判定する、車両制御システム。
　請求項１又は２に記載の車両制御システムであって、
　前記確認要求メッセージは、前記位置確認のセキュリティレベルを指定するコードを含み、
　前記位置確認装置は、指定された前記セキュリティレベルに応じた態様で前記位置確認を実施する、車両制御システム。
　複数の探索方法で前記ターゲットを探索可能に構成された前記位置確認装置を含む、請求項１又は２に記載の車両制御システムであって、
　前記確認要求メッセージは、前記ターゲットの探索方法を指定する情報を含む、車両制御システム。
　請求項１に記載の車両制御システムであって、
　前記確認要求メッセージは、複数の前記位置確認装置のうち、動作させる前記位置確認装置である要求対象を指定するコードを含み、
　前記確認要求メッセージにて前記要求対象に指定されている前記位置確認装置は、当該確認要求メッセージに示される内容に応じた前記位置確認を実行する一方、
　前記確認要求メッセージにて前記要求対象に指定されていない前記位置確認装置は、前記位置確認を実行しない、車両制御システム。
　車両に搭載された通信機との無線通信によって前記車両の鍵として機能するキーデバイスとして、スマートキーと携帯デバイスとを登録可能に構成されている請求項１又は２に記載の車両制御システムであって、
　前記確認要求メッセージは、探索対象とする前記キーデバイスの種類を指定するコードを含み、
　前記確認要求メッセージで指定されている種類の前記キーデバイスを探索可能な前記位置確認装置は、当該確認要求メッセージに示される内容に応じた前記位置確認を実行する一方、
　前記確認要求メッセージで指定されている種類の前記キーデバイスを探索不能な前記位置確認装置は、前記位置確認を実行しない、車両制御システム。
　請求項１又は２に記載の車両制御システムであって、
　前記結果通知メッセージは、発見された前記ターゲットの情報を含む、車両制御システム。
　請求項１又は２に記載の車両制御システムであって、
　前記結果通知メッセージは、ターゲットが発見されたエリアの情報を含む、車両制御システム。
　請求項３に記載の車両制御システムであって、
　前記確認要求メッセージは、前記探索対象エリアを２つ以上設定可能であって、かつ、各前記探索対象エリアごとに前記ターゲットを指定可能に構成されている車両制御システム。
　装置ごとに予め登録されているターゲットの位置確認をそれぞれ異なる方式で行う複数の位置確認装置（６ｘ）と接続されて使用されるコンピュータに、
　車載センサからの信号に基づき所定の確認イベントの発生を検知することと、
　前記確認イベントが検知されたことに基づいて、複数の前記位置確認装置に対し、希望する要求事項を示す共通の確認要求メッセージを送信することと、
　前記位置確認装置から前記確認要求メッセージに基づく前記位置確認の結果を示す結果通知メッセージを受信することと、
　前記位置確認装置から返送されてくる前記結果通知メッセージをもとに、検出された前記確認イベントに対応する車両制御の実行可否を判断することと、を実行させるための命令を含む車両制御プログラム。
　車両制御にかかるアプリケーションを実行する統括制御装置からの指示信号に基づき、予め登録されているターゲットの位置確認を実施する位置確認装置であって、
　前記統括制御装置から前記位置確認での要求事項を示す確認要求メッセージを受信することと、
　受信した前記確認要求メッセージに示される要求内容を自装置の機能に応じた内容に変換した上で、前記要求内容に応じた態様で前記位置確認を実行することと、
　前記位置確認の結果を示す結果通知メッセージを前記統括制御装置に返送することと、を実行するように構成されている位置確認装置。