WO2021261227A1 - 駐停車地点管理装置、駐停車地点管理方法、車両用装置 - Google Patents

Abstract

複数の車両は、地図サーバ（２）より路駐車両が存在すると通知されている路駐地点付近を通過する際、自車両の挙動を示すデータ及び周辺監視センサのセンシング情報路駐地点報告として地図サーバ（２）にアップロードする。地図サーバ（２）は、複数の車両から提供された車両挙動データ及びセンシング情報をもとに、路駐車両の出現ポイントを特定し、路駐地点として路駐地点ＤＢ（２５１）に登録する。また、地図サーバ（２）は、路駐地点付近を通過する車両の挙動に路駐車両を回避するような行動が見られなくなったことや、周辺監視センサで停車車両が検出されなくなったことに基づいて路駐車両が消失（移動）したと判定する。

Description

駐停車地点管理装置、駐停車地点管理方法、車両用装置 関連出願の相互参照

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

　本開示は、車両の通行を妨げうる障害物を検出する技術に関し、特に、道路上において車両が駐停車している地点の位置情報を管理する駐停車地点管理装置、駐停車地点管理方法に関する。

　路上の障害物を検出する技術としては、例えば、特許文献１には車載カメラの画像から、動物の死骸、倒木、及び走行車両からの落下物を、車載カメラを用いて検出する構成が開示されている。落下物としては、箱やはしご、スキー板などが想定されている。また、特許文献１では、車両が車載カメラを用いてサーバから通知された落下物がまだ残存しているかどうかを確認し、その結果をサーバに返送するとともに、サーバは車両からの確認結果をもとに落下物の存続状況を更新する構成が開示されている。その他、特許文献１には、落下物の種別から、障害物の撤去に要する時間を大まかに予測し、この予測した時間を配信する構成についても言及されている。

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

　特許文献１で想定される障害物としては、動物の死骸、倒木、車両からの落下物など、道路管理者によって撤去されるべき物体、すなわち自律的には移動しない静止物しか想定されていない。特許文献１においては、道路端付近などに駐車又は停車（以降、駐停車）されている車両は障害物として想定されていない。道路上に駐停車している車両は、落下物等の静止物とは異なり、当該車両の利用者によって移動を再開するため、その存続状態は、落下物等よりも相対的にダイナミックに変化しうる。つまり、駐停車している車両の存続期間等の特性は、特許文献１で想定されている障害物とは相違する。

　そして、路上に駐停車している車両の存在は、例えば一般道路における自動運転機能などのサービスの妨げとなりうる。仮に、車両が駐停車されている位置等を地図データとして取得可能であれば、当該地点を避ける走行計画の策定や、事前のハンドオーバーなどを実行可能となる。すなわち、自動運転技術の実用化や安全性・利便性向上のため、道路上において車両が駐停車されている地点を速やかに検出可能な技術が求められている。

　本開示は、この事情に基づいて成されたものであり、その目的とするところは、道路上において車両が駐停車している地点を検出可能な駐停車地点管理装置、駐停車地点管理方法、車両用装置を提供することにある。

　その目的を達成するための駐停車地点管理装置は、少なくとも１つの車両の挙動を示す車両挙動データ、及び、車両に搭載されている周辺監視センサのセンシング情報の少なくとも何れか一方を位置情報と対応付けて取得する判断材料取得部と、判断材料取得部が取得した情報に基づいて、道路上に車両が駐停車している地点を検出する駐停車地点検出部と、駐停車地点検出部が検出した、車両が駐停車している地点である駐停車地点に、車両がまだ存在しているか否かを、判断材料取得部が取得した情報に基づいて判定する存続状態判定部と、を備える。

　上記構成によれば、車両が駐停車されている地点が、当該地点を通行する少なくとも１台の車両の挙動データ又はセンシング情報に基づいて検出される。

　また、上記目的を達成するための駐停車地点管理方法は、少なくともの１つのプロセッサを用いて実行される、路上において車両が駐停車している地点情報を管理するための方法であって、少なくとも１つの車両の挙動を示す車両挙動データ、及び、車両に搭載されている周辺監視センサのセンシング情報の少なくとも何れか一方を位置情報と対応付けて取得する判断材料取得ステップと、判断材料取得ステップで取得した情報に基づいて、道路上に車両が駐停車している地点を検出する駐停車地点検出ステップと、駐停車地点検出ステップで検出された、車両が駐停車している地点である駐停車地点に、車両がまだ存在しているか否かを、判断材料取得ステップで取得した情報に基づいて判定する存続判定ステップと、を含む。

　上記方法によれば、車両挙動データ及び／又は周辺監視センサのセンシング情報といった、道路を通行する車両からの情報に基づいて、道路上において車両が駐停車している地点を検出可能となる。

　さらに、上記目的を達成するための車両用装置は、道路上に車両が駐停車している地点である駐停車地点についての情報を所定のサーバに送信するための車両用装置であって、自車両に搭載された周辺監視センサからの入力信号に基づき、道路上に停止している他車両である停止車両についての情報を取得する停止車両情報取得部と、停止車両情報取得部が取得した停止車両についての情報に基づき、停止車両が路上に駐車された路駐車両に該当するのか、移動可能な状態を保持した一時停車車両に該当するのかを判断する駐車判定部と、駐車判定部が路駐車両に該当すると判定した停止車両が存在する場合に、サーバに、路駐車両が存在する地点を示すデータセットを送信する報告処理部と、を備える。

　上記の車両用装置によれば、道路上において車両が駐停車されている可能性がある地点の情報がサーバに集まる。そのため、サーバは複数の車両から集めた情報に基づいて駐停車地点を検出可能となる。つまり、駐停車している車両の存在箇所及びその存続状態をリアルタイムに認識可能となりうる。

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

路駐情報配信システム１００の構成を説明するための図である。 車載システム１の構成を示すブロック図である。 ロケータ１４の構成を示すブロック図である。 路駐車両通知画像８０の一例を示す図である。 地図連携装置５０の構成を示すブロック図である。 アップロード処理の一例を示すフローチャートである。 路駐地点報告に含める車両挙動データの範囲を説明するための図である。 アップロード処理の一例を示すフローチャートである。 地図連携装置５０の作動例を示すフローチャートである。 地図連携装置５０の作動例を示すフローチャートである。 地図サーバ２の構成を示すブロック図である。 サーバプロセッサ２１が提供する地図サーバ２の機能を示すブロック図である。 地図サーバ２での処理を説明するためのフローチャートである。 出現判定部Ｇ３１の作動を説明するための図である。 出現判定部Ｇ３１が障害物は存在すると判定する基準の一例を示す図である。 消失判定部Ｇ３２が障害物は消失したと判定する基準の一例を示す図である。 路駐地点情報を用いた車両制御の一例を示すフローチャートである。 路駐情報配信システム１００の効果を説明するための図である。 検出された停止車両が路駐車両に該当するか否かを地図データを用いて判定する処理を説明するためのフローチャートである。 路駐車両の有無の判断材料として運転席乗員の視線を用いる構成を説明するための図である。 駐車列のギャップに自車両が駐車した場合の作動例を示すフローチャートである。 路駐有無判定部Ｆ５１が検出信頼度を算出する際の基準の一例を示す図である。 地図サーバ２の変形例を示す図である。 地図サーバ２による路駐車両の実在確度の算出規則の一例を概念的に示す図である。 路駐地点をグループ化して配信する構成を説明するための図である。 路駐地点のグループ化について説明するための図である。 路駐地点のグループ化の規則の一例を説明するための図である。 グループ化部Ｇ３４の作動を説明するための図である。 渋滞区間に関する情報をアップロードする地図連携装置５０の構成を示した図である。 車両からの報告に基づき渋滞区間の末尾等を検出及び配信する地図サーバ２の構成を示した図である。 路駐地点情報及び渋滞情報に基づいて自動運転不可区間を動的に設定に利用するシステムの構成を示す図である。

　以下、本開示の実施形態について図を用いて説明する。図１は、本開示に係る路駐情報配信システム１００の概略的な構成の一例を示す図である。図１に示すように、路駐情報配信システム１００は、複数の車両Ｍａ，Ｍｂの各々に構築されている複数の車載システム１と、地図サーバ２と、を備える。路駐情報配信システム１００は、地図サーバ２が一般道路上において路駐車両が存在する地点の情報を配信するシステムである。ここでの路駐車両とは、一般道路の路肩／道路端に沿って駐停車されている車両を指す。駐停車との記載は駐車又は停車と読み替えることができる。路駐車両がある地点である路駐地点が、駐停車地点に対応する。

　本開示では、路駐車両との区別のため、信号待ち等のために一時的に停止している車両のことを一時停車車両と記載する。路駐車両と一時停車車両とを区別しない場合には停止車両または停車車両と記載する。つまり、停止車両／停車車両の概念には、路駐車両と一時停車車両の双方が含まれる。一時停車車両とは、信号待ちや、歩行者／動物の横断待ち、対向車／電車の通過待ちなど（以降、信号待ち等）のために停車している車両である。一時停止車両は、すぐに移動可能な状態を保持しており、かつ、数分以内、長くとも５分以内には別の地点へ移動することが期待できる車両を指す。一方、路駐車両は、概念的には５分以上同一地点で停止し続けることが予想される車両である。路駐車両は、例えば車室内に乗員がいない状態の車両などを指す。路駐車両は、当該車両の後ろに並ばずに回避して移動を継続すべき停止車両に該当する一方、一時停車車両は、当該車両の後ろに自車両も並ぶべき停止車両に該当しうる。渋滞の末尾に関しては、ここでは一例として一時停車車両に類するものとみなすが、これに限らない。右折専用レーンや左折専用レーンなどの一部のレーンにのみ渋滞が生じている場合であって、自車両が当該レーンを走行する必要がない場合、渋滞の末尾に位置する車両は回避対象としての路駐車両に含めることができる。渋滞の末尾もまた駐停車地点として扱うことができる。

　なお、ここでは一例として路駐情報配信システム１００が左側通行の地域で使用される場合を想定して、進行方向を同一とするレーンの中で左端のレーンを第１レーンと称する。また、それに伴い、車両は一方通行ではない路上に駐停車する場合には、進行方向左側の道路端に沿うように駐停車するものとする。右側通行の地域で使用される場合には上記の左右を逆にすることにより本開示の構成を実施可能である。例えば右側通行の地域においては第１レーンとは進行方向を同一とするレーンの中で右端のレーンを指す。以下で述べる路駐情報配信システム１００は、使用される地域の交通法規に適合するように変更して実施可能である。なお、一方通行の道路において駐停車位置は道路の左側及び右側の何れか一方に限らない。

　なお、図１では、便宜上、車載システム１が搭載されている車両として、車両Ｍａと車両Ｍｂの２台しか図示していないが、実際には３台以上存在する。車載システム１は、道路上を走行可能な車両に搭載可能であって、車両Ｍａ、Ｍｂは、四輪自動車のほか、二輪自動車、三輪自動車等であってもよい。原動機付き自転車も二輪自動車に含めることができる。以降では車載システム１から見て、当該システム（つまり自分自身）が搭載されている車両のことを自車両とも記載する。

　＜全体構成の概要＞
　各車両に搭載されている車載システム１は、広域通信網３に無線接続可能に構成されている。ここでの広域通信網３とは、携帯電話網やインターネット等の、電気通信事業者によって提供される公衆通信ネットワークを指す。図１に示す基地局４は、車載システム１が広域通信網３に接続するための無線基地局である。

　各車載システム１は、自車両の状態を示す通信パケットである車両状態報告を、所定の周期で、基地局４及び広域通信網３を介して地図サーバ２へ送信する。車両状態報告には、その通信パケットを送信した車両（つまり送信元車両）を示す送信元情報の他、当該データの生成時刻、送信元車両の現在位置などが含まれる。送信元情報とは、送信元車両に対して予め割り当てられた、他の車両と区別するための識別情報（いわゆる車両ＩＤ）である。車両状態報告には、上記情報の他、自車両の進行方向や、走行レーンＩＤ、走行速度、加速度、ヨーレートなどが含まれていても良い。走行レーンＩＤは、左端または右端の道路端から何番目のレーンを自車両が走行しているかを示す。さらに、車両状態報告には、方向指示器の点灯状態や、レーン境界線をまたいで走行しているか否かなどの情報が含まれていてもよい。

　また、各車載システム１は、地図サーバ２から通知される路駐地点に関連する情報を示す通信パケット（以降、路駐地点報告）を地図サーバ２にアップロードする。路駐地点に関連する情報とは、路駐車両の存続状況を地図サーバ２が判断するための判断材料として使用される情報である。路駐地点報告は、車両状態報告に含められてもよい。路駐地点報告と車両状態報告とは別々に送信されても良い。

　地図サーバ２は、各車両からアップロードされてくる路駐地点報告に基づいて路駐車両が存在する位置や、路駐車両が消失した地点などを検出する。そして、路駐車両の出現／消失に関する情報を、当該情報を配信すべき車両へマルチキャスト配信する。

　地図サーバ２は、路駐車両の出現／消失についての情報の配信先を決定するためのサブ機能として、各車両の現在位置を管理する機能を備える。各車両の現在位置の管理は、所定のデータベースである車両位置データベースを用いて実現されればよい。当該データベースにおいて各車両の現在位置は、車両ＩＤなどと対応付けられて保存されている。地図サーバ２は、車両状態報告を受信する度に、その内容を参照して、データベースに登録されている送信元車両の現在位置を更新する。なお、路駐地点情報をプル配信する構成においては、例えば車両位置データベースなど、路駐地点情報の配信先を決定するための構成は必ずしも必要ではない。配信先を決定するための各車両の位置を管理する機能は任意の要素である。車載システム１における車両状態報告の送信も任意の要素である。

　＜車載システム１の概要＞
　図２に示すように車載システム１は、前方カメラ１１、ミリ波レーダ１２、車両状態センサ１３、ロケータ１４、Ｖ２Ｘ車載器１５、ＨＭＩシステム１６、地図連携装置５０、及び運転支援ＥＣＵ６０を備える。なお、部材名称中のＥＣＵは、Electronic Control Unitの略であり、電子制御装置を意味する。また、ＨＭＩは、Human Machine Interfaceの略である。Ｖ２ＸはVehicle to X（Everything）の略で、車を様々なものをつなぐ通信技術を指す。

　車載システム１を構成する上記の種々の装置またはセンサは、ノードとして、車両内に構築された通信ネットワークである車両内ネットワークＮｗに接続されている。車両内ネットワークＮｗに接続されたノード同士は相互に通信可能である。なお、特定の装置同士は、車両内ネットワークＮｗを介することなく直接的に通信可能に構成されていてもよい。例えば地図連携装置５０と運転支援ＥＣＵ６０とは専用線によって直接的に電気接続されていても良い。また、図２において車両内ネットワークＮｗはバス型に構成されているが、これに限らない。ネットワークトポロジは、メッシュ型や、スター型、リング型などであってもよい。ネットワーク形状は適宜変更可能である。車両内ネットワークＮｗの規格としては、例えばController Area Network（以降、ＣＡＮ：登録商標）や、イーサネット（イーサネットは登録商標）、FlexRay（登録商標）など、多様な規格を採用可能である。

　以降では自車両の運転席に着座している乗員である運転席乗員をユーザとも記載する。なお、以下の説明における前後、左右、上下の各方向は、自車両を基準として規定される。具体的に、前後方向は、自車両の長手方向に相当する。左右方向は、自車両の幅方向に相当する。上下方向は、車両高さ方向に相当する。別の観点によれば、上下方向は、前後方向及び左右方向に平行な平面に対して垂直な方向に相当する。

　＜車載システム１の各構成要素＞
　前方カメラ１１は、車両前方を所定の画角で撮像するカメラである。前方カメラ１１は、例えばフロントガラスの車室内側の上端部や、フロントグリル、ルーフトップ等に配置されている。前方カメラ１１は、画像フレームを生成するカメラ本体部と、画像フレームに対して認識処理を施す事により、所定の検出対象物を検出するＥＣＵと、を備える。カメラ本体部は少なくともイメージセンサとレンズとを含む構成であって、所定のフレームレート（例えば６０ｆｐｓ）で撮像画像データを生成及び出力する。カメラＥＣＵは、ＣＰＵや、ＧＰＵなどを含む画像処理チップを主体として構成されており、機能ブロックとして識別器を含む。識別器は、例えば画像の特徴量ベクトルに基づき、物体の種別を識別する。

　前方カメラ１１は、所定の検出対象物を検出するとともに、当該検出物の自車両に対する相対位置等を特定する。ここでの検出対象物とは、例えば、歩行者、他車両、ランドマークとしての地物、道路端、路面標示などである。他車両には自転車や原動機付き自転車、オートバイも含まれる。ランドマークは、道路沿いに設置されている立体構造物である。道路沿いに設置される構造物は、例えば、ガードレール、縁石、樹木、電柱、道路標識、信号機などである。道路標識には、方面看板や道路名称看板などの案内標識などが含まれる。ランドマークとしての地物は、後述するローカライズ処理に利用される。路面標示とは、交通制御、交通規制のための路面に描かれたペイントを指す。例えば、車線の境界を示す車線区画線（いわゆるレーンマーク）や、横断歩道、停止線、導流帯、安全地帯、規制矢印などが路面標示に含まれる。車線区画線には、黄色又は白色の塗料を用いて破線又は連続線状に形成されているペイントの他、チャッターバーやボッツドッツなどの道路鋲によって実現されるものも含まれる。車線区画線はレーンマークやレーンマーカとも称される。

　また、前方カメラ１１は、車両を検出した場合に、当該検出車両の相対速度に基づき、停車車両（停止車両）であるか否かを判定する。そして、前方カメラ１１は、例えば停車車両の道路上の位置或いは自車両に対する相対位置を示す情報を出力する。なお、前方カメラ１１は自車両が走行しているレーンだけでなく、隣接レーンに相当する領域に存在する停車車両も検出可能に構成されていることが好ましい。ここでは一例として、前方カメラ１１は自車走行レーンと、左右の隣接レーン上の車両を検出可能に構成されているものとする。

　前方カメラ１１が備える画像プロセッサは、色、輝度、色や輝度に関するコントラスト等を含む画像情報に基づいて、撮像画像から背景と検出対象物とを分離して抽出する。例えば、前方カメラ１１は、レーン境界線や道路端、車両といった検出対象物の自車両からの相対距離および方向（つまり相対位置）、移動速度などを、ＳｆＭ（Structure from Motion）処理等を用いて画像から算出する。自車両に対する検出物の相対位置は、画像内における検出物の大きさや傾き度合いに基づいて特定してもよい。そして、検出物の位置や種別等を示す検出結果データを、地図連携装置５０及び運転支援ＥＣＵ６０に逐次提供する。

　ミリ波レーダ１２は、車両前方に向けてミリ波又は準ミリ波を送信するとともに、当該送信波が物体で反射されて返ってきた反射波の受信データを解析することにより、自車両に対する物体の相対位置や相対速度を検出するデバイスである。ミリ波レーダ１２は、例えば、フロントグリルや、フロントバンパに設置されている。ミリ波レーダ１２には、検出物体の大きさや移動速度、受信強度に基づいて、検出物の種別を識別するレーダＥＣＵが内蔵されている。レーダＥＣＵは、検出結果として、検出物の種別や、相対位置（方向と距離）、受信強度を示すデータを地図連携装置５０等に出力する。ミリ波レーダ１２もまた、前述の路駐車両の一部又は全部を検出可能に構成されている。例えばミリ波レーダ１２は、検出物の位置や、移動速度、大きさ、反射強度に基づいて、停車車両を検出する。

　前方カメラ１１及びミリ波レーダ１２は、認識結果を示すデータ以外に、例えば画像データなど、物体認識に用いた観測データも車両内ネットワークＮｗを介して運転支援ＥＣＵ６０等に提供するように構成されていても良い。例えば前方カメラ１１にとっての観測データとは、画像フレームを指す。ミリ波レーダの観測データとは、検出方向及び距離毎の受信強度及び相対速度を示すデータ、または、検出物の相対位置及び受信強度を示すデータを指す。観測データは、センサが観測した生のデータ、あるいは認識処理が実行される前のデータに相当する。なお、前方カメラ１１及びミリ波レーダ１２は何れも車両の外界をセンシングするセンサに相当する。故に、前方カメラ１１及びミリ波レーダ１２を区別しない場合には周辺監視センサとも記載する。

　周辺監視センサが生成する観測データに基づく物体認識処理は、運転支援ＥＣＵ６０など、センサ外のＥＣＵが実行しても良い。前方カメラ１１やミリ波レーダ１２の機能の一部は、運転支援ＥＣＵ６０に設けられていても良い。その場合、前方カメラ１１としてのカメラやミリ波レーダは、画像データや測距データといった観測データを検出結果データとして運転支援ＥＣＵ６０に提供すればよい。

　車両状態センサ１３は、自車両の走行制御に関わる状態量を検出するセンサである。車両状態センサ１３には、例えば３軸ジャイロセンサ及び３軸加速度センサなどの慣性センサが含まれる。３軸加速度センサは、自車両に作用する前後、左右、上下方向のそれぞれの加速度を検出するセンサである。ジャイロセンサは検出軸回りの回転角速度を検出するものであって、３軸ジャイロセンサは互いに直交する３つの検出軸を有するものを指す。また、車両状態センサ１３にはシフトポジションセンサ、操舵角センサ、車速センサなども含めることができる。シフトポジションセンサは、シフトレバーのポジションを検出するセンサである。操舵角センサは、ハンドルの回転角（いわゆる操舵角）を検出するセンサである。車速センサは、自車両の走行速度を検出するセンサである。

　車両状態センサ１３は、検出対象とする物理状態量の現在の値（つまり検出結果）を示すデータを車両内ネットワークＮｗに出力する。各車両状態センサ１３の出力データは、車両内ネットワークＮｗを介して地図連携装置５０等で取得される。なお、車両状態センサ１３として車載システム１が使用するセンサの種類は適宜設計されればよく、上述した全てのセンサを備えている必要はない。

　ロケータ１４は、複数の情報を組み合わせる複合測位により、自車両の高精度な位置情報等を生成する装置である。ロケータ１４は、例えば図３に示すように、ＧＮＳＳ受信機１４１、慣性センサ１４２、地図記憶部１４３、及び位置演算部１４４を用いて実現されている。

　ＧＮＳＳ受信機１４１は、ＧＮＳＳ（Global Navigation Satellite System）を構成する測位衛星から送信される航法信号を受信することで、当該ＧＮＳＳ受信機１４１の現在位置を逐次検出するデバイスである。例えばＧＮＳＳ受信機１４１は４機以上の測位衛星からの航法信号を受信できている場合には、１００ミリ秒ごとに測位結果を出力する。ＧＮＳＳとしては、ＧＰＳ、ＧＬＯＮＡＳＳ、Ｇａｌｉｌｅｏ、ＩＲＮＳＳ、ＱＺＳＳ、Ｂｅｉｄｏｕ等を採用可能である。慣性センサ１４２は、例えば３軸ジャイロセンサ及び３軸加速度センサである。

　地図記憶部１４３は、高精度地図データを記憶している不揮発性メモリである。ここでの高精度地図データは、道路構造、及び、道路沿いに配置されている地物についての位置座標等を、自動運転に利用可能な精度で示す地図データに相当する。高精度地図データは、例えば、道路の３次元形状データや、車線データ、地物データ等を備える。上記の道路の３次元形状データには、複数の道路が交差、合流、分岐する地点（以降、ノード）に関するノードデータと、その地点間を結ぶ道路（以降、リンク）に関するリンクデータが含まれる。リンクデータには、自動車専用道路であるか、一般道路であるかといった、道路種別を示すデータも含まれていてもよい。ここでの自動車専用道路とは、歩行者や自転車の進入が禁止されている道路であって、例えば高速道路などの有料道路などを指す。道路種別は、自律走行が許容される道路であるか否かを示す属性情報を含んでもよい。車線データは、車線数や、車線区画線（いわゆるレーンマーカー）の設置位置座標、車線ごとの進行方向、車線レベルでの分岐／合流地点を示す。地物データは、一時停止線などの路面表示の位置及び種別情報や、ランドマークの位置、形状、及び種別情報を含む。ランドマークには、交通標識や信号機、ポール、商業看板など、道路沿いに設置された立体構造物が含まれる。

　位置演算部１４４は、ＧＮＳＳ受信機１４１の測位結果と、慣性センサ１４２での計測結果とを組み合わせることにより、自車両の位置を逐次測位する。例えば、位置演算部１４４は、トンネル内などＧＮＳＳ受信機１４１がＧＮＳＳ信号を受信できない場合には、ヨーレートと車速を用いてデッドレコニング（Dead Reckoning ／自律航法）を行う。デッドレコニングに用いるヨーレートは、ＳｆＭ技術を用いて前方カメラ１１で算出されたものでもよいし、ヨーレートセンサで検出されたものでもよい。測位した車両位置情報は車両内ネットワークＮｗに出力され、地図連携装置５０等で利用される。また、位置演算部１４４は、上記構成で特定された自車位置座標に基づいて、道路において自車両が走行しているレーン（以降、走行レーン）のＩＤを特定する。

　なお、ロケータ１４は、ローカライズ処理を実施可能に構成されていても良い。ローカライズ処理は、前方カメラ１１で撮像された画像に基づいて特定されたランドマークの座標と、高精度地図データに登録されているランドマークの座標とを照合することによって自車両の詳細位置を特定する処理を指す。ローカライズ処理は、ＬｉＤＡＲ（Light Detection and Ranging/Laser Imaging Detection and Ranging）が出力する３次元の検出点群データと、３次元地図データとの照合により実施されても良い。また、ロケータ１４は、前方カメラ１１やミリ波レーダ１２で検出されている道路端からの距離に基づいて走行レーンを特定するように構成されていても良い。ロケータ１４が備える一部又は全部の機能は、地図連携装置５０又は運転支援ＥＣＵ６０が備えていてもよい。

　Ｖ２Ｘ車載器１５は、自車両が他の装置と無線通信を実施するための装置である。なお、Ｖ２Ｘの「Ｖ」は自車両としての自動車を指し、「Ｘ」は、歩行者や、他車両、道路設備、ネットワーク、サーバなど、自車両以外の多様な存在を指しうる。Ｖ２Ｘ車載器１５は、通信モジュールとして広域通信部と狭域通信部を備える。広域通信部は、所定の広域無線通信規格に準拠した無線通信を実施するための通信モジュールである。ここでの広域無線通信規格としては例えばＬＴＥ（Long Term Evolution）や４Ｇ、５Ｇなど多様なものを採用可能である。なお、広域通信部は、無線基地局を介した通信のほか、広域無線通信規格に準拠した方式によって、他の装置との直接的に、換言すれば基地局を介さずに無線通信を実施可能に構成されていても良い。つまり、広域通信部はセルラーＶ２Ｘを実施するように構成されていても良い。自車両は、Ｖ２Ｘ車載器１５の搭載により、インターネットに接続可能なコネクテッドカーとなる。例えば地図連携装置５０は、Ｖ２Ｘ車載器１５との協働により、地図サーバ２から最新の高精度地図データをダウンロードして、地図記憶部１４３に格納されている地図データを更新できる。

　Ｖ２Ｘ車載器１５が備える狭域通信部は、通信距離が数百ｍ以内に限定される通信規格
（以降、狭域通信規格）によって、自車両周辺に存在する他の移動体や路側機と直接的に無線通信を実施するための通信モジュールである。他の移動体としては、車両のみに限定されず、歩行者や、自転車などを含めることができる。狭域通信規格としては、ＩＥＥＥ１７０９にて開示されているＷＡＶＥ（Wireless Access in Vehicular Environment）規格や、ＤＳＲＣ（Dedicated Short Range Communications）規格など、任意のものを採用可能である。狭域通信部は、例えば所定の送信周期で自車両についての車両情報を周辺車両に向けて同報送信するとともに、他車両から送信された車両情報を受信する。車両情報は、車両ＩＤや、現在位置、進行方向、移動速度、方向指示器の作動状態、タイムスタンプなどを含む。

　ＨＭＩシステム１６は、ユーザ操作を受け付ける入力インターフェース機能と、ユーザへ向けて情報を提示する出力インターフェース機能とを提供するシステムである。ＨＭＩシステム１６は、ディスプレイ１６１とＨＣＵ（HMI Control Unit）１６２を備える。なお、ユーザへの情報提示の手段としては、ディスプレイ１６１の他、スピーカや、バイブレータ、照明装置（例えばＬＥＤ）等を採用可能である。

　ディスプレイ１６１は、画像を表示するデバイスである。ディスプレイ１６１は、例えば、インストゥルメントパネルの車幅方向中央部（以降、中央領域）の最上部に設けられた、いわゆるセンターディスプレイである。ディスプレイ１６１は、フルカラー表示が可能なものであり、液晶ディスプレイ、ＯＬＥＤ（Organic Light Emitting Diode）ディスプレイ、プラズマディスプレイ等を用いて実現できる。なお、ＨＭＩシステム１６がディスプレイ１６１として、フロントガラスの運転席前方の一部分に虚像を映し出すヘッドアップディスプレイを備えていてもよい。また、ディスプレイ１６１は、メータディスプレイであってもよい。

　ＨＣＵ１６２は、ユーザへの情報提示を統合的に制御する構成である。ＨＣＵ１６２は、例えばＣＰＵやＧＰＵなどのプロセッサと、ＲＡＭと、フラッシュメモリ等を用いて実現されている。ＨＣＵ１６２は、地図連携装置５０から提供される情報や、図示しない入力装置からの信号に基づき、ディスプレイ１６１の表示画面を制御する。例えばＨＣＵ１６２は、地図連携装置５０又は運転支援ＥＣＵ６０からの要求に基づき、図４に例示する路駐車両通知画像８０をディスプレイ１６１に表示する。

　路駐車両通知画像８０は、路駐車両に関する情報をユーザに通知するための画像である。路駐車両通知画像８０は、例えば路駐車両までの距離や、路駐車両の特徴（車種やボディカラーなど）、レーンへのはみ出し度合いなどの情報を含むことが好ましい。図４中の画像８１は自車両を表しており、画像８２はレーン境界線を示している。画像８３は路駐車両を示しており、画像８４は道路端を示している。路駐車両を示す画像８３の色合いは、実際の路駐車両と類似する色とすることが好ましい。また、路駐車両通知画像８０は、路駐車両が存在する地点までの残り距離を示す画像８５を含んでいても良い。路駐車両の位置等を示す路駐車両通知画像８０は、運転席乗員からみた現実世界と重なるようにヘッドアップディスプレイに表示されても良い。

　地図連携装置５０は、地図サーバ２から路駐地点情報を含む地図データを取得するとともに、自車両で検出された路駐車両についての情報を地図サーバ２にアップロードするデバイスである。地図連携装置５０の機能の詳細については別途後述する。地図連携装置５０は、処理部５１、ＲＡＭ５２、ストレージ５３、通信インターフェース５４、及びこれらを接続するバス等を備えたコンピュータを主体として構成されている。処理部５１は、ＲＡＭ５２と結合された演算処理のためのハードウェアである。処理部５１は、ＣＰＵ（Central Processing Unit）等の演算コアを少なくとも一つ含む構成である。処理部５１は、ＲＡＭ５２へのアクセスにより、路駐車両の存在／消失判定のための種々の処理を実行する。ストレージ５３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。ストレージ５３には、処理部５１によって実行されるプログラムである路駐車両報告プログラムが格納されている。処理部５１が路駐車両報告プログラムを実行することは、路駐車両報告プログラムに対応する駐停車地点管理方法が実行されることに相当する。通信インターフェース５４は、車両内ネットワークＮｗを介して他の装置と通信するための回路である。通信インターフェース５４は、アナログ回路素子やＩＣなどを用いて実現されればよい。

　なお、地図連携装置５０は、例えばナビゲーション装置に含まれていても良い。地図連携装置５０は、運転支援ＥＣＵ６０や自動運転ＥＣＵに含まれていてもよい。地図連携装置５０はＶ２Ｘ車載器１５に含まれていても良い。地図連携装置５０の機能配置は適宜変更可能である。地図連携装置５０が車両用装置に相当する。

　運転支援ＥＣＵ６０は、前方カメラ１１及びミリ波レーダ１２といった周辺監視センサの検出結果や、地図連携装置５０が取得した地図情報をもとに運転席乗員の運転操作を支援するＥＣＵである。例えば運転支援ＥＣＵ６０は、路駐車両の位置等を示す路駐車両通知画像などの運転支援情報を提示する。また、運転支援ＥＣＵ６０は、周辺監視センサの検出結果と地図連携装置５０が取得した地図情報をもとに、走行用のアクチュエータ類である走行アクチュエータを制御することにより、運転操作の一部または全部を運転席乗員の代わりに実行する。走行アクチュエータは、例えば、ブレーキアクチュエータや、電子スロットル、操舵アクチュエータなどを含む。

　運転支援ＥＣＵ６０は、車両制御機能の１つとして、車線変更を自動で実施する機能（以降、自動車線変更機能）を提供する。例えば運転支援ＥＣＵ６０は、別途生成される走行計画上の車線変更予定地点に到達すると、ＨＭＩシステム１６と連携して車線変更を実施するか否かを運転席乗員に問い合わせる。そして、運転席乗員によって車線変更の実施を指示する操作が入力装置に行われたと判定した場合に、目標レーンの交通状況を鑑みて、目標レーンに向かう方向への操舵力を発生させ、自車両の走行位置を目標レーンへ移す。車線変更の予定地点は、ある程度の長さを持った区間として定義可能である。

　このような運転支援ＥＣＵ６０は、地図連携装置５０と同様に、処理部、ＲＡＭ、ストレージ、通信インターフェース、及びこれらを接続するバス等を備えたコンピュータを主体として構成されている。各要素の図示は省略している。運転支援ＥＣＵ６０が備えるストレージには、処理部によって実行されるプログラムである運転支援プログラムが格納されている。処理部が運転支援プログラムを実行することは、運転支援プログラムに対応する方法が実行されることに相当する。

　＜地図連携装置５０の詳細＞
　ここでは図５を用いて地図連携装置５０の機能及び作動について説明する。地図連携装置５０は、ストレージ５３に保存されている路駐車両報告プログラムを実行することにより、図５に示す種々の機能ブロックに対応する機能を提供する。すなわち、地図連携装置５０は機能ブロックとして、自車位置取得部Ｆ１、地図取得部Ｆ２、自車挙動取得部Ｆ３、検出物情報取得部Ｆ４、報告データ生成部Ｆ５、及び通知処理部Ｆ６を備える。地図取得部Ｆ２は路駐情報取得部Ｆ２１を備える。報告データ生成部Ｆ５は、路駐有無判定部Ｆ５１を備える。

　自車位置取得部Ｆ１は、ロケータ１４から自車両の位置情報を取得する。また、ロケータ１４から走行レーンＩＤを取得する。なお、ロケータ１４の機能の一部又は全部は、自車位置取得部Ｆ１が備えていても良い。

　地図取得部Ｆ２は、地図記憶部１４３から、現在位置を基準として定まる所定範囲の地図データを読み出す。また、地図取得部Ｆ２は、Ｖ２Ｘ車載器１５を介して地図サーバ２から自車両の前方所定距離以内に存在する路駐地点情報を取得する。路駐地点情報は別途後述するように路駐車両が存在する地点についてのデータであって、路駐車両が存在する位置座標やその路駐車両の種別などを含む。地図サーバ２から路駐地点情報を取得する構成が路駐情報取得部Ｆ２１に相当する。

　路駐情報取得部Ｆ２１は、自車位置に応じた路駐地点情報を地図サーバ２に要求することで路駐地点情報を取得可能である。このような配信態様はプル配信とも称される。また、地図サーバ２が、路駐車両付近に存在する車両に対して自動的に路駐地点情報を配信しても良い。このような配信態様はプッシュ配信とも称される。つまり、路駐地点情報は、プル配信及びプッシュ配信のどちらで取得されても良い。ここでは一例として、地図サーバ２が各車両の位置情報に基づいて配信対象とする車両を選定し、当該配信対象に対してプッシュ配信するように構成されているものとする。

　地図取得部Ｆ２が取得した路駐地点情報は、ＲＡＭ５２等を用いて実現されるメモリＭ１に一時保存される。また、メモリＭ１に保存されている路駐地点情報は、当該データに示される地点を車両が通過した場合や、一定時間経過した場合に削除されれば良い。便宜上、地図サーバ２から取得した路駐地点情報のことを、地図上路駐地点情報とも記載する。

　自車挙動取得部Ｆ３は、車両状態センサ１３から、自車両の挙動を示すデータを取得する。例えば走行速度や、ヨーレート、横加速度、縦加速度などを取得する。また、自車挙動取得部Ｆ３は、前方カメラ１１からレーン境界線をまたいでいるか否かを示す情報や、レーン中心に対する右又は左への走行位置のオフセット量を取得する。ここでの縦加速度は前後方向の加速度に相当し、横加速度は左右方向の加速度に相当する。

　検出物情報取得部Ｆ４は、前方カメラ１１やミリ波レーダ１２によって検出された停車車両についての情報（以降、停車車両検出情報）を取得する。検出物情報取得部Ｆ４が停止車両情報取得部に相当する。停車車両検出情報は、例えば、停車車両が存在する位置や、その種別、大きさなどを含む。停車車両の検出位置は、例えばＷＧＳ８４（World Geodetic System 1984）など、任意の絶対座標系で表現することができる。検出された停車車両の絶対位置は、自車両の現在位置座標と、周辺監視センサで検出された自車両に対する停車車両等の相対位置情報とを組み合わせることで算出可能である。検出物情報取得部Ｆ４は、種々の周辺監視センサによる認識結果だけでなく、例えば前方カメラ１１が撮像した画像データ等、観測データそのものも取得しうる。検出物情報取得部Ｆ４は外界情報取得部と呼ぶこともできる。

　停車車両の検出位置情報には、道路端から当該停車車両までの距離情報や、レーン境界線に対する停車車両との相対位置情報を含んでいることが好ましい。例えば、停車車両がレーンにはみ出しているか否か、及び、レーン内への停車車両のはみ出し度合いを示す情報を含んでいてもよい。或いは、レーン内における停車車両の端部の横位置を含んでいてもよい。レーン内における停車車両の端部の横位置情報は、当該停車車両が路駐車両である場合、路駐車両がどれくらいレーンを塞いでいるかを示す情報として使用可能である。

　自車位置取得部Ｆ１や、自車挙動取得部Ｆ３、検出物情報取得部Ｆ４が逐次取得する種々のデータは、ＲＡＭ５２等のメモリに保存され、地図取得部Ｆ２や報告データ生成部Ｆ５などによって参照により利用される。なお、各種情報は、例えばデータの取得時刻を示すタイムスタンプが付与された上で種別ごとに区分されてメモリに保存される。タイムスタンプは、同一時刻における異なる種別の情報を紐付ける役割を担う。タイムスタンプを用いることにより地図連携装置５０は、例えば車外動画に同期した車両挙動等を特定可能となる。なおタイムスタンプは取得時刻の代わりに、出力源におけるデータの出力時刻や、生成時刻などであっても良い。タイムスタンプとして出力時刻や生成時刻を採用する場合には各車載装置の時刻情報は同期されていることが好ましい。地図連携装置５０が取得した種々の情報は、例えば最新のデータが先頭となるようにソートされて保存されうる。取得から一定時間が経過したデータは破棄されうる。

　報告データ生成部Ｆ５は、地図サーバ２に送信するデータセットを生成し、Ｖ２Ｘ車載器１５に出力する構成である。報告データ生成部Ｆ５は例えば冒頭に記載の車両状態報告を所定の間隔で生成してＶ２Ｘ車載器１５を介して地図サーバ２にアップロードする。また、報告データ生成部Ｆ５は、別途後述するアップロード処理として、路駐地点報告を生成して地図サーバ２にアップロードする。報告データ生成部Ｆ５が報告処理部に相当する。

　路駐有無判定部Ｆ５１は、検出物情報取得部Ｆ４が取得している停車車両検出情報及び自車挙動取得部Ｆ３が取得した自車両の挙動データに基づいて、路駐車両が存在するか否かを判定する構成である。例えば路駐有無判定部Ｆ５１は、周辺監視センサによって検出された停車車両が、路駐車両条件を充足している場合に、当該停車車両を路駐車両とみなす。路駐車両条件は、信号待ちや渋滞などによるレーン内における一時停車と、路肩に寄せた駐停車とを区別するための条件である。

　例えば路駐車両条件としては（ア）停車車両から道路進行方向側、所定の第１距離以内に交差点または信号機が存在しないこと、及び、（イ）道路端から停車車両までの距離が所定の第２距離未満であること、などを採用可能である。第１距離は例えば１０ｍなどとすることができる。第２距離は例えば０．７５ｍなどとすることができる。交差点との位置関係は地図データを参照することにより特定可能である。また、道路端から停車車両までの横方向距離は前方カメラ１１などの周辺監視センサの検出結果をもとに判断可能である。なお、路駐有無判定部Ｆ５１は、地図データを用いて道路端から停車車両までの距離を特定しても良い。例えば路駐有無判定部Ｆ５１は、ローカライズ処理の結果として定まる自車位置と、検出物情報取得部Ｆ４が取得した自車両に対する停車車両の相対位置を組み合わせることで、停車車両の地図上位置を特定する。そして、地図データに示される道路端の位置情報と、停車車両の位置情報に基づいて道路端から停車車両までの横方向距離を特定しても良い。

　路駐車両条件には、（ウ）駐車禁止区間ではないことを含めてもよい。また、（エ）停車車両がハザードランプを点灯させていること、（オ）ブレーキランプが点灯していないこと、（カ）停車車両のドアが開いていること、（キ）レーン境界線をまたいでいること、などを路駐車両か否かの判断材料として使用しても良い。その他、右左折待ちの渋滞と区別するために、（ク）複数の停車車両が列をなしている場合、当該列が交差点に接続していないこと、などを含めても良い。駐車禁止区間は、道路標識や路面表示、道路端としての縁石の色などに対する前方カメラ１１の認識結果から判断可能である。駐車禁止区間かどうかは地図データを用いて判断しても良い。ハザードランプ及びブレーキランプの点灯状態や、ドアの開閉状態は、前方カメラ１１の認識結果に基づいて判断可能である。なお、路駐車両条件としては（ア）～（ク）の全てを含む必要はない。（ア）～（ク）の一部、又は、上記以外の観点を路駐車両と判定するための条件として採用可能である。

　このような路駐有無判定部Ｆ５１は、１つの側面において、周辺監視センサからの入力信号に基づき検出された、道路上で停止している車両である停止車両が、路駐車両に該当するか、一時停車車両に該当するかを識別する構成に相当する。路駐有無判定部Ｆ５１が駐車判定部に相当する。

　また、路駐有無判定部Ｆ５１は、周辺監視センサが自車走行レーン付近に停車車両を検出している状況において、自車両が当該停車車両を避けるための回避行動を実施したか否かによって路駐車両が存在するか否かを判定しても良い。

　ここでの回避行動とは、例えば路駐車両を避けるための車両挙動であって、例えば走行位置の変更を指す。ここでの走行位置の変更とは、道路上における車両の横方向の位置を変更することを指す。走行位置の変更には、車線変更だけでなく、同一レーン内における走行位置を左右のどちらか隅部に寄せる動きや、レーン境界線をまたいで走行する態様も含まれる。なお、通常の車線変更との違いを明確とするために、回避行動は、減速及びその後の加速を伴う走行位置の変更／操舵とすることが好ましい。例えば減速操作を伴う走行位置の変更や、所定の速度以下までの減速を伴う走行位置の変更を回避行動とすることができる。なお、上記の回避行動について説明は、本開示で想定する回避行動の概念を示したものである。回避行動としての走行位置の変更を実行したか否かは、別途後述するように、走行軌跡のほか、横加速度の変化パターンや、方向指示器の作動履歴などから判定可能である。

　路駐有無判定部Ｆ５１は、周辺監視センサで検出された停車車両を路駐車両と判断した場合には、当該路駐車両に対して検出物情報取得部Ｆ４が取得している停車車両検出情報を路駐車両検出情報として保存する。路駐車両検出情報は、停車車両検出情報と同様のデータ構造を有し、例えば、路駐車両が存在する位置や、その車両種別などを含む。路駐車両検出情報は、路駐車両の色合いや、道路端から路駐車両までの距離や、レーン境界線に対する路駐車両との相対位置情報を含んでもよい。さらに、路駐車両検出情報は、前方カメラ１１で撮像された路駐車両の画像データを含んでも良い。路駐車両検出情報及び停車車両検出情報の少なくとも何れか一方が周辺監視センサのセンシング情報に相当する。

　通知処理部Ｆ６は、地図上路駐情報に基づき、車両前方に存在する路駐車両についての情報をＨＭＩシステム１６と連携して運転席乗員に通知する構成である。例えば通知処理部Ｆ６は、地図上路駐情報に基づき図４に例示する路駐車両通知画像を生成してディスプレイ１６１に表示させる。なお、路駐車両の通知は、音声メッセージなどで通知してもよい。通知処理部Ｆ６は、運転支援ＥＣＵ６０が備えていてもよい。

　＜アップロード処理＞
　ここでは図６に示すフローチャートを用いて地図連携装置５０が実行するアップロード処理について説明する。図６に示すフローチャートは例えば車両の走行用電源がオンとなっている間、例えば１００ミリ秒毎など所定の周期で実行される。走行用電源は、車両を走行可能な状態にする電源であって、例えばエンジン車両においてはイグニッション電源である。電気自動車においてはシステムメインリレーが走行用電源に相当する。アップロード処理は一例としてステップＳ１０１～Ｓ１０４を備える。

　ステップＳ１０１では報告データ生成部Ｆ５がメモリＭ１に保存されている地図上路駐地点情報を読み出して、ステップＳ１０２に移る。ステップＳ１０２では地図上路駐地点情報に基づき、車両前方の所定距離（以降、参照距離）以内に路駐車両が存在するか否かを判定する。参照距離は例えば２００ｍや３００ｍなどである。参照距離は、前方カメラ１１が物体を認識できる距離の限界値よりも長いことが好ましい。参照距離は、車両の走行速度に応じて変更されても良い。例えば、車両の走行速度が大きいほど参照距離は長く設定されても良い。例えば３０秒などの所定時間以内に到達する距離を自車両の速度に応じて算出し、当該距離を参照距離として採用しても良い。

　ステップＳ１０２において参照距離以内に地図サーバ２が認識している路駐車両が存在しない場合、本フローを終了する。一方、参照距離以内に路駐車両が存在する場合にはステップＳ１０３を実行する。

　ステップＳ１０３では、地図上の路駐地点の前後、所定の報告対象距離以内を走行する際の車両挙動を取得してステップＳ１０４に移る。ステップＳ１０４では、ステップＳ１０３で取得した車両挙動の時系列データと、送信元情報と、報告対象地点情報を含むデータセットを路駐地点報告して生成する。報告対象地点情報は、どの地点についての報告であるかを示す情報である。例えば報告対象地点情報には、地図上の路駐地点の位置座標が設定される。

　報告対象距離は、運転席乗員や周辺監視センサが地図上路駐地点の状況を認識可能な距離に設定されていることが好ましい。例えば報告対象距離は図７に示すように地図上路駐地点の前後１００ｍに設定されている。この場合、路駐地点報告は例えば地図上路駐地点の前後１００ｍ分の車両挙動を示すデータセットとなる。地図上路駐地点の前後、報告対象距離以内となる区間を報告対象区間とも記載する。

　路駐地点報告に含める車両挙動データは、路駐車両が存在するレーンを走行している自車両が路駐車両を避ける動き（つまり回避行動）をしたかどうかを示すデータとする。例えば、車両挙動を示すデータとしては、地図上路駐地点付近を通過する際の各時点における車両位置座標、進行方向、走行速度、縦加速度、横加速度、ヨーレートなどを採用することができる。地図上路駐地点の付近とは、例えば、地図上路駐地点の２０ｍ以内を指す。なお、地図上路駐地点の前後５０ｍ以内や１００ｍ以内を地図上路駐地点の付近とみなしても良い。地図上路駐地点付近とみなす範囲は道路種別や法定上限速度に応じて変更されてもよい。前述の報告対象距離は、どこまでを地図上路駐地点の付近と見なすかに応じて決定される。また、車両挙動を示すデータとしては、操舵角や、シフトポジション、方向指示器の作動状態、ハザードランプの点灯状態、レーン境界線をまたいだか否か、車線変更を実施したか否か、レーン中心からのオフセット量を含めることができる。

　路駐地点報告には、地図上路駐地点付近を通過する際の各時点における走行レーンＩＤが含まれていることが好ましい。走行レーンＩＤを含めることにより、路駐車両の影響を受けるレーン（つまり第１レーン）を走行してきた車両からの報告であるか否かを地図サーバ２が判別可能となるためである。もちろん、地図サーバ２は、路駐地点報告に含まれる位置座標の時系列データに基づいて、路駐車両の影響を受けるレーンを走行してきた車両からの報告であるか否かを判別してもよい。

　また、路駐地点報告には、地図上路駐地点に至るまでの車両挙動だけでなく、地図上路駐地点を通過した後の車両挙動情報も含めることが好ましい。或る車両によって実施された車線変更や操舵が、路駐車両を避けるためのものであれば、路駐車両通過後に元のレーンに戻る動きが行われる可能性が高いためである。つまり、地図上路駐地点の通過後の車両挙動も路駐地点報告に含めることで、車両が実施した動きが路駐車両を避けるためのものだったのか否か、ひいては真に路駐車両が存在するのか否かの判定精度を高めることが可能となる。

　路駐地点報告は、報告対象区間を走行中の、例えば１００ミリ秒ごとの車両状態を示すデータとすることができる。車両挙動のサンプリング間隔は、１００ミリ秒に限らず、２００ミリ秒などであってもよい。サンプリング間隔が短いほど、データサイズが大きくなってしまうため、通信量抑制の観点からは、サンプリング間隔は、車両の動きを解析可能な程度に長くすることが好ましい。

　報告対象距離は短すぎると、例えば回避行動を実施した後のデータしか地図サーバ２に集まらなくなってしまい、回避行動が行われているのかどうかが不明となる。一方、報告対象距離を長く設定すれば回避行動を示すデータの漏れが少なくなるが、データサイズが大きくなる。報告対象距離は、路駐車両に対する回避行動が実施されることが想定される地点が含まれるように報告対象距離は設定されることが好ましい。例えば報告対象距離は２５ｍ以上に設定されることが好ましい。

　なお、報告対象距離の長さは、一般道路か自動車専用道路かによって変更されても良い。自動車専用道路とは、歩行者や自転車の進入が禁止されている道路であって、例えば高速道路などの有料道路が含まれる。例えば、一般道における報告対象距離は自動車専用道路における報告対象距離よりも短く設定されていてもよい。具体的には自動車専用道路向けの報告対象距離は１００ｍ以上とする一方、一般道路向けの報告対象距離は３０ｍなど、５０ｍ以下に設定されていても良い。自動車専用道路は一般道路よりも前方の視認性がよく、路駐車両が存在する地点から離れた地点から回避行動がなされる可能性があるためである。

　サンプリング間隔もまた、自動車専用道路か一般道路かといった道路種別に応じて変更されてもよい。自動車専用道路向けのサンプリング間隔は、一般道路向けのサンプリング間隔よりも短くしても良い。サンプリング間隔を長くすることでデータサイズを抑制できる。その他、報告対象距離が長いほどサンプリング間隔を疎とするように構成されていても良い。そのような構成によれば路駐地点報告のデータサイズを一定の範囲内に収めることが可能となる。

　なお、報告対象距離やサンプリング間隔は、地図サーバ２からの指示信号によって動的に決定されても良い。また、路駐地点報告に含める情報種別（換言すれば項目）もまた地図サーバ２からの指示信号によって動的に決定されても良い。

　加えて、報告対象距離、サンプリング間隔、及び路駐地点報告に含める項目は、路駐車両の種別や大きさ、レーンの塞ぎ度合いに応じて変更されても良い。例えば路駐車両がレーンを半分以上塞いでいる場合など、回避挙動としての車線変更が必須となるケースにおいては、路駐地点報告は、報告車両が車線変更を実施したか否かを判定するための情報に限定されても良い。車線変更を実施したか否かは、走行軌跡や、走行レーンＩＤの変化の有無などから判定可能である。

　なお、路駐地点報告には、周辺監視センサで路駐車両が検出されたか否かを示す検出結果情報を含めても良い。路駐車両検出結果は、前方カメラ１１及びミリ波レーダ１２のそれぞれの検出結果とすることができる。路駐車両の検出結果は、路駐有無判定部Ｆ５１の判定結果であっても良い。路駐車両が検出されている場合、路駐地点報告には、周辺監視センサのセンシング情報として、路駐車両検出情報及び停車車両検出情報の少なくとも何れか一方を含めても良い。例えば、路駐地点報告には、地図上路駐地点から所定距離手前
（例えば１０ｍ手前）で撮像された前方カメラ１１の画像データを含めても良い。

　なお、アップロード処理の態様は上述した内容に限定されない。例えばアップロード処理は図８に示すように、ステップＳ２０１～Ｓ２０６を含むように構成されていてもよい。図８に示すステップＳ２０１～Ｓ２０３は前述のステップＳ１０１～Ｓ１０１と同様である。ステップＳ２０３が完了するとステップＳ２０４を実行する。

　ステップＳ２０４では、地図上路駐地点付近を通過する際の前方カメラ１１及びミリ波レーダ１２の少なくともの一方のセンシング情報を取得する。ここでのセンシング情報には、観測データに基づく認識結果のほか、観測データそのものを含めることができる。ここでは一例として、前方カメラ１１とミリ波レーダ１２の停車車両に関する認識結果と、前方カメラ１１の撮像画像を取得する。ここでの停車車両は路駐車両の候補に相当する。センシング情報の収集期間は例えば車両挙動情報と同様に、地図上路駐地点までの残り距離が報告対象距離以下となる地点を通過してから、地図上路駐地点が報告対象距離後方に位置するまでとすることができる。なお、車両後方を検出範囲とする周辺監視センサを備えない場合には、センシング情報の収集期間は、地図上路駐地点までの残り距離が報告対象距離以下となってから、地図上路駐地点を通過するまでとしてもよい。ステップＳ２０４が完了するとステップＳ２０５を実行する。

　ステップＳ２０５ではステップＳ２０４で収集したセンシング情報に基づいて、地図上路駐地点の現在の状況を示す現況データを生成する。例えば現況データには、センシング情報の収集期間における２５０ミリ秒毎の周辺監視センサの認識結果が含まれる。また、当該期間内において前方カメラ１１にて停車車両が検出されている場合には、当該停車車両の検出に使用された画像データを少なくとも１フレーム含める。現況データに地図上路駐地点を移した画像フレームを少なくとも１つ含めることで、地図サーバ２での解析性を高めることができる。

　なお、現況データに含める画像フレームは、センシング情報の収集期間において撮像された全フレームとしてもよいし、２００ミリ秒間隔で撮像された画像フレームとしてもよい。現況データに含める画像フレームの数は、多くするほど地図サーバ２での解析性が高まる一方、通信量が増大する。現況データに含める画像フレームの量はデータ量が所定の上限値以下となるように選定されても良い。また、画像フレーム全体ではなく、路駐車両が映っている画像領域だけを抽出して現況データに含めるように構成されていても良い。

　ステップＳ２０５が完了するとステップＳ２０６を実行する。ステップＳ２０６では、ステップＳ２０３で取得した車両挙動を示すデータと、ステップＳ２０５で生成した現況データを含むデータセットを路駐地点報告として生成し、地図サーバ２にアップロードする。

　上記の構成によれば、車両挙動だけでなく、周辺監視センサの認識結果や、画像データも地図サーバ２に集めることができる。その結果、路駐車両がまだ存続しているのか、消失したのかをより一層精度良く検証可能となる。また、第２レーンを走行する車両である第２レーン走行車両は、路駐車両に対する回避行動を行わないが、当該車両の前方カメラ１１やミリ波レーダ１２でも路駐車両は観測されうる。つまり、路駐車両は、第２レーン走行車両でも観測されうる。第３レーンや第４レーンを走行する車両においても、確率や精度は落ちるが同様に路駐車両を観測しうる。上記の構成によれば地図サーバ２は、路駐車両の側方を走行する車両において収集されたセンシング情報を収集可能となるため、路駐車両が存在するのか否かをより一層精度よく検証可能となる。

　その他、以上ではアップロード処理として、自車両の前方に地図上路駐地点付近を走行したときの状況を路駐地点報告としてアップロードする態様を開示したがこれに限らない。地図連携装置５０は、地図上路駐地点が存在しない場合にも、例えば路駐車両の存在を示唆する車両挙動またはセンシング情報が得られた場合に路駐地点報告をアップロードするように構成されていても良い。

　例えば地図連携装置５０は、図９に示すように、ステップＳ３０１～Ｓ３０４を含む処理を実行するように構成されていても良い。図９に示す処理フローは例えば所定の実行間隔でアップロード処理とは独立して実行される。なお、図９に示す処理フローは例えばアップロード処理において地図上路駐地点がない（ステップＳ１０２又はステップＳ２０２　ＮＯ）と判断された場合に実行されても良い。

　ステップＳ３０１では自車挙動取得部Ｆ３が、車両状態センサ１３及び前方カメラ１１から提供された、直近所定時間（例えば１０秒間）の車両挙動を取得してステップＳ３０２を実行する。ステップＳ３０２では、上記の時間帯の中で、第１レーンを走行していた時点があるかどうかを判定する。第１レーンを走行していた時点が存在しない場合にはステップＳ３０２を否定判定して本フローを終了する。一方、第１レーンを走行していた時点がある場合にはステップＳ３０２を肯定判定してステップＳ３０３に移る。

　ステップＳ３０３では、ステップＳ３０１で取得した車両挙動データの時系列データを解析することにより、回避行動を実施したか否かを判定する。例えば減速や停止を伴う走行位置の変更や、急な操舵などが実施されている場合に、回避行動を実施したと判定する。走行位置を変更したかどうかは、自車位置の軌跡から判断しても良いし、ヨーレートや操舵角、横加速度の経時変化、方向指示器の点灯状態などから判別可能である。また、レーン境界線をまたいだか否かに基づいて走行位置を変更したか否かを判別しても良い。さらに、ヨーレートや操舵角、横加速度が所定値以上となったことに基づいて回避行動を実施したと判定してもよい。

　ステップＳ３０２において回避行動が行われたと判定した場合には、ステップＳ３０３に移り、前述のステップＳ１０３やステップＳ２０６等と同様に、路駐地点報告を生成及び送信する。なお、路駐車両は基本的に路肩又は第１レーンに存在するため、路駐車両の直接的な影響を受けるのは第１レーンを走行している車両である。第１レーンを走行中に回避行動を実施したということは、路駐車両の存在を示唆する。また、ステップＳ３０３で送信される路駐地点報告は、まだ地図サーバ２が認識していない路駐車両の存在を示唆するデータに相当する。

　ステップＳ３０３で生成する路駐地点報告の報告地点情報には、回避行動を実施したと判定する直前の車両位置が設定されればよい。回避行動を実施する前の車両位置を設定することにより、路駐車両が存在するレーンが誤特定されるおそれを低減できる。なお、回避行動を実施する前の車両位置から所定距離（例えば２０ｍ）進行方向側の地点を報告地点に設定しても良い。

　また、地図連携装置５０は、図１０に示すように、ステップＳ４０１～Ｓ４０３を含む処理を実行するように構成されていてもよい。図１０に示す処理フローは例えば所定の実行間隔でアップロード処理とは独立して実行されてもよいし、アップロード処理において地図上路駐地点がない（ステップＳ１０２又はステップＳ２０２　ＮＯ）と判断された場合に実行されても良い。

　ステップＳ４０１では直近所定時間（例えば５秒間）のセンシング情報を取得してステップＳ４０２を実行する。ステップＳ４０２では路駐有無判定部Ｆ５１が、ステップＳ４０１で取得したセンシング情報及び自車両の挙動履歴を解析することにより、路駐車両が存在するのか否かを判定する。路駐車両が存在すると判定した場合には、ステップＳ２０６と同様に路駐地点報告を作成してアップロードする。なお、ステップＳ４０３でアップロードする路駐地点報告に含めるセンシング情報は、例えば路駐車両が存在すると判定した時点の各周辺監視センサの認識結果及び画像フレームなどとすることができる。ステップＳ４０３で送信される路駐地点報告もまた、ステップＳ３０３で送信される路駐地点報告と同様に、地図サーバ２がまだ認識していない路駐車両の存在を示唆するデータに相当する。

　＜地図サーバ２の構成＞
　次に地図サーバ２の構成について説明する。地図サーバ２は、複数の車両から送信された路駐地点報告に基づいて、路駐車両の発生及び消失を検出し、車両に路駐地点情報として配信する構成である。地図サーバ２が駐停車地点管理装置に相当する。なお、地図サーバ２の通信相手としての車両との記載は、車載システム１又は地図連携装置５０と読み替えることができる。

　地図サーバ２は、図１１に示すように、サーバプロセッサ２１、ＲＡＭ２２、ストレージ２３、通信装置２４、及び地図ＤＢ２５、及び車両位置ＤＢ２６を備える。部材名称中のＤＢはデータベース（Database）を指す。サーバプロセッサ２１は、ＲＡＭ５２と結合された演算処理のためのハードウェアである。サーバプロセッサ２１は、ＣＰＵ（Central Processing Unit）等の演算コアを少なくとも一つ含む構成である。サーバプロセッサ２１は、ＲＡＭ２２へのアクセスにより、路駐車両の存続状態の判定など、種々の処理を実行する。ストレージ２３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。ストレージ２３には、サーバプロセッサ２１によって実行されるプログラムである路駐情報管理プログラムが格納されている。サーバプロセッサ２１が路駐情報生成プログラムを実行することは、路駐情報管理プログラムに対応する駐停車地点管理方法が実行されることに相当する。通信装置２４は、広域通信網３を介して各車載システム１などの他の装置と通信するための装置である。

　地図ＤＢ２５は、例えば高精度地図データが格納されているデータベースである。また、地図ＤＢ２５には、路駐車両が検出されている地点に関する情報を格納する路駐地点ＤＢ２５１を備える。地図ＤＢ２５及び路駐地点ＤＢ２５１は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。地図ＤＢ２５及び路駐地点ＤＢ２５１は、サーバプロセッサ２１によるデータの書き込み、読出、削除等が実施可能に構成されている。

　路駐地点ＤＢ２５１には、路駐車両が検出されている地点を示すデータ（以降、路駐地点データ）が保存されている。路駐地点データは、路駐地点毎の位置座標や、路駐車両が存在レーン、路駐車両の種別、大きさ、第１レーンへのはみ出し量、出現時刻、最新の存続判定時刻などを示す。或る路駐地点についてのデータは、当該地点に対する車両からの路駐地点報告に基づき、路駐情報管理部Ｇ３によって例えば定期的に更新される。路駐地点データを構成する路駐地点毎のデータは、リスト形式など、任意のデータ構造によって保持されていれば良い。路駐地点ごとのデータは、例えば、所定の区画ごとに分けて保存されていても良い。区画単位は、高精度地図のメッシュであってもよいし、行政区画単位であってもよいし、他の区画単位であってもよい。例えば道路リンク単位であっても良い。地図のメッシュとは、地図を一定の規則に従って分割してなる複数の小領域を指す。メッシュはマップタイルと言いかえることもできる。

　車両位置ＤＢ２６は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。車両位置ＤＢ２６は、サーバプロセッサ２１によるデータの書き込み、読出、削除等が実施可能に構成されている。車両位置ＤＢ２６には、路駐情報配信システム１００を構成する各車両の位置を含む現在の状況を示すデータ（以降、車両位置データ）が、車両ＩＤと対応付けられて保存されている。車両位置データは、車両毎の位置座標や、走行レーン、進行方向、走行速度などを示す。或る車両についてのデータは当該車両からの車両状態報告を受信する度に、後述する車両位置管理部Ｇ２によって更新される。車両位置データを構成する車両毎のデータは、リスト形式など、任意のデータ構造によって保持されていれば良い。車両ごとのデータは、例えば、所定の区画ごとに分けて保存されていても良い。区画単位は、地図のメッシュであってもよいし、行政区画単位であってもよいし、他の区画単位（例えば道路リンク単位）であってもよい。

　地図サーバ２は、サーバプロセッサ２１がストレージ２３に保存されている路駐情報生成プログラムを実行することにより、図１２に示す種々の機能ブロックに対応する機能を提供する。すなわち、地図サーバ２は機能ブロックとして、報告データ取得部Ｇ１、車両位置管理部Ｇ２、路駐情報管理部Ｇ３、及び配信処理部Ｇ４を備える。路駐情報管理部Ｇ３は、出現判定部Ｇ３１、及び消失判定部Ｇ３２を備える。

　報告データ取得部Ｇ１は、車載システム１からアップロードされてきた車両状態報告及び路駐地点報告を、通信装置２４を介して取得する。報告データ取得部Ｇ１は、通信装置２４から取得した車両状態報告を車両位置管理部Ｇ２に提供する。また、報告データ取得部Ｇ１は通信装置２４から取得した路駐地点報告を路駐情報管理部Ｇ３に提供する。報告データ取得部Ｇ１が判断材料取得部に相当する。

　車両位置管理部Ｇ２は、各車両から送信されてくる車両状態報告に基づいて、車両位置ＤＢ２６に保存されている車両毎の位置情報等を更新する。すなわち、報告データ取得部Ｇ１が車両状態報告を受信する度に、車両位置ＤＢ２６に保存されている、車両状態報告の送信元についての位置情報や、走行レーン、進行方向、走行速度などの所定の管理項目を更新する。

　路駐情報管理部Ｇ３は、各車両から送信されてくる路駐地点報告に基づいて、路駐地点ＤＢ２５１に保存されている路駐地点ごとのデータを更新する。路駐情報管理部Ｇ３が備える出現判定部Ｇ３１及び消失判定部Ｇ３２は何れも路駐地点ごとのデータを更新するための要素である。出現判定部Ｇ３１は、路駐車両が出現したことを検出するための構成である。消失判定部Ｇ３２は、出現判定部Ｇ３１によって検出された路駐車両がまだ存在しているか否か、換言すれば、検出済みの路駐車両が消失したか否かを判定する構成である。消失判定部Ｇ３２は、駐停車地点の登録後に受信した車両挙動データやセンシング情報に基づいて、当該駐停車地点における路駐車両の存続状態を判定する構成に相当する。出現判定部Ｇ３１や消失判定部Ｇ３２の詳細については別途後述する。出現判定部Ｇ３１が駐停車地点検出部に相当し、消失判定部Ｇ３２が存続状態判定部に相当する。

　配信処理部Ｇ４は、路駐地点情報を配信する構成である。例えば配信処理部Ｇ４は路駐地点通知処理を実施する。路駐地点通知処理は、路駐車両が存在する地点（つまり路駐地点）について情報を示す通信パケットである路駐地点通知パケットを、当該路駐地点を通過予定の車両に配信する処理である。路駐地点通知パケットは、路駐車両の位置座標や、路駐車両の特徴（種別や色合い）などを示す。路駐地点通知パケットの宛先は、例えば路駐地点を、例えば１分や２分、５分など、所定時間以内に通過する予定の車両とすることができる。路駐地点を走行予定かどうかは、例えば各車両の走行予定経路を取得して判定しても良い。また、路駐車両が存在する道路／レーンと同一又は接続している道路／レーンを走行している車両を、路駐地点を通過予定の車両として選択しても良い。路駐地点までの到達所要時間は、車両の現在位置から路駐地点までの距離と、車両の走行速度から算出可能である。

　配信処理部Ｇ４は、道路リンクや高さ情報を用いて路駐地点通知パケットの宛先を選定する。これにより、路駐車両が存在する道路の上／下側に併設されている道路を走行している車両に誤配信するおそれを低減できる。換言すれば、高架道路やダブルデッキ構造を有する道路区間における配信対象の誤特定を抑制可能となる。配信対象は、車両位置ＤＢ２６に登録されている各車両の位置情報や走行速度などに基づいて抽出されれば良い。

　また、配信対象の抽出条件に、路駐地点に到達するまでの時間条件を加えることで、不要な配信を抑制することができる。路駐車両は存続状態が動的に変化しうるため、例えば到達まで３０分以上残っている車両にまで配信しても、当該車両が到達するころには路駐車両が消失している可能性が高いためである。なお、路駐地点に到達するまでの時間条件は任意の要素であり、配信対象の抽出条件に含めなくともよい。

　配信対象は、レーン単位で判断されても良い。例えば路駐車両の影響を受けるのは第１レーン走行中の車両である。第１レーンを走行中／走行予定の車両は配信対象に含める。一方、第１レーンから離れた第３レーンや第４レーンを走行中の車両は路駐車両の影響を受けにくい。よって、第３レーンなどの第１レーンと隣接しないレーンを走行予定の車両は、配信対象から除外してもよい。なお、第２レーンを走行中の車両については、第１レーンからの割り込みを警戒する必要があるため、配信対象に含めてもよい。

　路駐地点通知パケットは、例えば上記配信対象の条件を満たす複数の車両に対してマルチキャストで配信可能である。路駐地点通知パケットはユニキャストで配信してもよい。路駐地点通知パケットをユニキャスト配信する場合には、路駐地点に近いもの、あるいは、車速を考慮して到着時刻が早いものから優先的に順次送信してもよい。路駐車両の位置等を通知しても制御への反映や、報知には間に合わないほど近くにいる車両は配信対象から除外しても良い。

　その他、配信処理部Ｇ４は、路側機を介して路駐地点通知パケットを送信するように構成されていても良い。そのような構成において路側機は、配信処理部Ｇ４から受信した路駐地点通知パケットを狭域通信により、当該路側機の通信エリア内に存在する車両に対してブロードキャストする。また、路駐地点通知パケットはジオキャスト方式で、障害物登録地点から所定距離以内の車両に配信されても良い。情報の配信方式としては多様な方式を採用可能である。

　また、配信処理部Ｇ４は消失通知処理を実施する。消失通知処理は、路駐車両が消失したことを示す通信パケット（以降、消失通知パケット）を配信する処理である。消失通知パケットは、例えば、路駐地点通知パケットを送付済みの車両に対して、例えばマルチキャストで配信可能である。消失通知パケットは消失判定部Ｇ３２にて路駐車両が消失したと判定され次第、可及的速やかに配信する。なお、消失通知パケットは、路駐地点通知パケットと同様にユニキャストで配信してもよい。消失通知パケットをユニキャストで配信する場合には、路駐地点に近いもの、あるいは、車速を考慮して到着時刻が早いものから優先的に順次送信してもよい。路駐車両が消失したことを通知しても制御への反映や、報知には間に合わないほど近くにいる車両は配信対象から除外しても良い。なお、消失通知パケットの配信対象は、路駐車両の存在を通知済みの車両に限定されるため、道路リンクや高さ情報を用いて配信対象を選定することとなる。

　配信処理部Ｇ４は、路駐地点通知パケットを送信済みの車両の情報を、路駐地点ＤＢ２５１で管理しても良い。路駐地点通知パケットを送信済みの車両を管理することで、消失通知パケットの配信対象の選定も容易に実行可能となる。同様に配信処理部Ｇ４は、消失通知パケットを送信した車両の情報を路駐地点ＤＢ２５１で管理しても良い。路駐地点通知パケット／消失通知パケットを通知済みであるか否かを地図サーバ２にて管理することで、同じ情報が繰り返し配信されることを抑制可能となる。なお、路駐地点通知パケット／消失通知パケットを取得済みであるか否かは、車両側にてフラグ等を用いて管理されても良い。路駐地点通知パケットや消失通知パケットが路駐地点情報に相当する。

　＜サーバ側処理＞
　地図サーバ２が実施する路駐地点登録処理について図１３に示すフローチャートを用いて説明する。図１３に示すフローチャートは例えば所定の更新周期で実行されればよい。更新周期は例えば５分や１０分など、相対的に短い時間とすることが好ましい。

　地図サーバ２においてサーバプロセッサ２１は、車両から送信される路駐地点報告を受信する処理を一定周期で繰返す（ステップＳ５０１）。ステップＳ５０１が判断材料取得ステップに相当する。サーバプロセッサ２１は、路駐地点報告を受信すると、その受信した路駐地点報告が報告対象とする地点を特定し（ステップＳ５０２）、受信した路駐地点報告を地点毎に区分して保存する（ステップＳ５０３）。なお、路駐地点報告で報告される位置情報にはばらつきがあることを考慮し、路駐地点報告は、所定の長さを有する区間ごとに保存されても良い。

　そして、サーバプロセッサ２１は、所定の更新条件が充足している地点を抽出する（ステップＳ５０４）。例えば、所定時間以内の報告受信回数が所定の閾値以上であって、路駐車両の存在／不在の判定処理を前回実施してから所定の待機時間経過している地点を、更新対象地点として抽出する。待機時間は例えば３分や５分など、相対的に短い時間とすることができる。なお、更新条件は、報告受信回数が所定の閾値以上の地点としてもよいし、前回の更新から所定の待機時間経過した地点としても良い。

　後述する出現判定処理の実施条件と、消失判定処理の実施条件は異なっていても良い。出現判定処理を実行するための報告受信回数は、消失判定処理を実行するための報告受信回数よりも少なくともよい。例えば出現判定処理を実行するための報告受信回数は３回とする一方、消失判定処理を実行するための報告受信回数はその２倍の６回としてもよい。当該構成によれば迅速に路駐車両の出現を検出できるとともに、路駐車両の消失の判定精度を高めることができる。

　更新対象地点の抽出が完了するとそれらのうちの任意の１つを処理対象に設定し（ステップＳ５０５）、路駐地点として登録済みの場所であるか、未登録の場所であるかを判別する。処理対象地点が路駐地点として未登録の場所である場合には、出現判定部Ｇ３１が出現判定処理を実施する（ステップＳ５０７）。ステップＳ５０７が駐停車地点検出ステップに相当する。一方、処理対象地点が路駐地点として登録済みの場所である場合には、消失判定部Ｇ３２が消失判定処理を実施する（ステップＳ５０８）。ステップＳ５０８が存続判定ステップに相当する。そして、出現判定処理または消失判定処理の判定結果に基づいて路駐地点ＤＢ２５１の登録内容を更新する（ステップＳ５０９）。

　例えば路駐車両が出現したと判定された地点についてはその情報を路駐地点ＤＢ２５１に追加登録する。路駐車両が消失したと判定された地点については、路駐地点ＤＢ２５１から当該地点情報を削除するか、消失したこと示すフラグを設定する。消失フラグが設定されている路駐地点のデータについてはフラグ設定から所定時間（例えば１時間）経過したタイミングで削除されても良い。なお、存続状況に変化がない地点については登録内容の変更は省略可能である。存続状況に変化がない地点について判定を実施した時刻情報だけ最新情報（つまり現在時刻）に更新しても良い。

　ステップＳ５０４で抽出された全ての更新対象地点について、出現判定処理または消失判定処理が完了すると本フローを終了する。一方、未処理の地点が残っている場合には当該未処理地点を対象地点に設定して出現判定処理又は消失判定処理を実行する（ステップＳ５１０）。

　＜出現判定処理＞
　ここでは出現判定部Ｇ３１が実施する出現判定処理について説明する。出現判定部Ｇ３１は、車線変更や、通行車両の加減速の変化パターン、カメラ画像、車載システム１による路駐車両の検出結果、レーンごとの通行量の変化パターンなどを用いて、判定対象とする地点に路駐車両が出現したかどうかを判定する。ここでの地点という表現には所定の長さを有する区間の概念が含まれる。

　出現判定部Ｇ３１は、例えば一定時間以内に第１レーンから第２レーンへの車線変更が実施された回数が所定の閾値以上となっている地点に路駐車両が存在すると判定する。車線変更の実施の有無は、車両での判断結果や報告を用いて判定しても良いし、車両の走行軌跡から検出してもよい。また、出現判定部Ｇ３１は、車線変更が所定数（例えば３台）以上連続して実施されている地点に路駐車両が存在していると判定してもよい。

　車線変更に基づく路駐車両の位置は、例えば、図１４に示すように車線変更を実施した複数の車両の軌跡のうち、車線変更のタイミングが最も遅かった走行軌跡Ｔｒ１に基づいて決定することができる。例えば、第１レーンにおいて最も進行方向側に位置する離脱ポイント（以降、最奥離脱ポイント）Ｐｄ１からさらに所定距離（例えば５ｍ）進行方向側の地点に路駐車両Ｐｖが存在すると判定する。離脱ポイントは、操舵角が所定の閾値上となった地点としてもよいし、レーン中心からのオフセット量が所定の閾値以上となった地点としてもよい。或いはレーン境界線をまたぎ始めた地点としても良い。ここでの路駐地点は、ある程度の誤差を許容するために、前後方向に所定の幅を有するものとする。ここでの前後方向とは道路が延設されている方向に相当する。

　なお、路駐車両の位置は、最奥離脱ポイントＰｄ１に最も近い復帰ポイント（以降、最前復帰ポイント）Ｐｅ１の位置に基づいて決定されてもよい。例えば最奥離脱ポイントＰｄ１と最前復帰ポイントＰｅ１の中間点としてもよい。復帰ポイントは、第２レーンから第１レーンに車線変更で進入してきた車両の操舵角が所定の閾値未満となった地点とすることができる。なお、復帰ポイントは、第１レーンに車線変更で進入してきた車両のレーン中心からのオフセット量が所定の閾値未満となった地点でも良い。操舵角の代わりに道路延設方向に対する車体の角度を採用しても良い。その他、路駐車両の位置は、路駐地点報告に含まれる検出位置情報に基づいて決定されてもよい。複数の車両から、同一路駐地点についての路駐車両の検出位置情報を取得できている場合には、それらの平均位置を路駐車両の位置として採用しても良い。

　ところで、路駐車両を避けるための回避行動としては、第１レーンから第２レーン側への走行位置の変更（以降、回避用位置変更）と、第１レーンのレーン中心に戻るための位置変更（以降、復帰用位置変更）とがセットで実施される場合が多い。しかしながら、走行軌跡Ｔｒ１に示すように、路駐車両を避けて第２レーンに車線変更した車両が、必ずしも第１レーンに戻るとは限らない。例えば、路駐車両の側方を通過後に右折する予定がある場合や、他車両によって元のレーンに戻る空きスペースが存在しない場合には、第１レーンには復帰しない。また、手動運転車両においては運転席乗員の気分や習慣に依って第１レーンに戻るか否かが変わる。加えて、走行軌跡Ｔｒ２として例示するように、第２レーンを走行していた車両が路駐車両の横を通過後に、第１レーンへと車線変更することも考えられる。本開示のサーバプロセッサ２１は、離脱用位置変更と復帰用位置変更との両方を実施した車両の台数をカウントするのではなく、それぞれの種類の位置変更が集中している箇所を路駐地点として抽出する事により、より速やかに路駐車両の出現を検知可能となる。もちろん、他の態様として離脱用位置変更と復帰用位置変更との両方を実施した車両の台数に基づいて路駐地点を検出しても良い。

　また、図１４に示すように、路駐車両が存在する地点は、地図上においては、左右の道路端付近において一時的に車両の走行軌跡が存在しない領域（以降、無軌道領域Ｓｐ）として現れる。出現判定部Ｇ３１は、所定時間以内の複数の車両の走行軌跡をもとに無軌道領域Ｓｐの有無を判定してもよい。そして、出現判定部Ｇ３１は、無軌道領域Ｓｐとなっている地点を障害物地点に設定してもよい。つまり出現判定部Ｇ３１は、無軌道領域Ｓｐが発生したことに基づいて、路駐車両が出現したことを検出しても良い。

　また、出現判定部Ｇ３１は、路駐地点報告に含まれる画像データに基づいて路駐車両の出現を検出しても良い。例えば複数の車両のカメラ画像から、レーン上に路駐車両が存在していることが確認されたことに基づいて、路駐車両が存在すると判定しても良い。また、出現判定部Ｇ３１は、路駐地点報告に含まれる、路駐有無判定部Ｆ５１での路駐車両の検出結果に基づいて、路駐車両が存在すると判定しても良い。例えば直近所定時間以内において路駐車両が存在することを示す報告の数が所定の閾値以上となった場合に、当該報告が送信された地点に路駐車両が存在すると判定しても良い。その他、出現判定部Ｇ３１は、路駐地点報告に含まれる、周辺監視センサでの停車車両の検出結果に基づいて、路駐車両が存在すると判定しても良い。例えば複数の車両での検出結果をもとに５分以上同一箇所に滞在している停車車両は路駐車両と判定しても良い。

　その他、出現判定部Ｇ３１は、第１レーンにおいて所定の加減速パターンが発生している地点を路駐地点として検出してもよい。通常、車両前方に路駐車両が存在することを認識した運転席乗員／自動運転システムはいったん減速し、走行位置の変更をした後に再加速を行う。つまり路駐地点付近では、減速から再加速といった加減速パターンが観測されることが想定される。逆説的に、直近所定時間以内において上記の加減速パターンの発生頻度／連続発生数が所定のしきい値以上となっているエリアを路駐地点として抽出しても良い。ここでの走行位置の変更には、車線変更だけでなく、第１レーン内における走行位置を第２レーン側に寄せる動きや、第１レーンと第２レーンの境界線をまたいで走行する態様も含まれる。

　なお、例えば、鳥や歩行者、野生動物などの移動体が瞬間的な路駐車両として存在する場合にも、一旦減速してから再加速するといった加減速パターンが観測されうる。そのような事情を踏まえると、加減速パターンを用いた路駐地点の検出は、走行位置の変更を伴うものを母集団として実行することが好ましい。換言すれば、出現判定部Ｇ３１は、所定の加減速パターンが走行位置の変更と合わせて観測されているエリアを路駐地点として検出することが好ましい。

　以上では前後方向の加速度を路駐地点の検出に利用する態様を開示したが、路駐車両を避けるための走行位置の変更をする場合には、横方向の加速度にも所定のパターンが生じることが想定される。例えば直近所定時間以内において左右方向に所定の加減速パターンが発生している頻度／連続発生数が所定のしきい値以上となっているエリアを路駐地点として抽出しても良い。

　その他、路駐車両が存在する場合、第１レーンの交通量は、第２レーンの交通量と比べると、少なくなることが予想される。直近所定時間における第１レーンの交通量が所定時間前に比べて所定値／所定割合減少しており、且つ、同時間帯における第２レーンの交通量が増加している場合には、当該第１レーンに路駐車両が存在すると判定しても良い。なお、上記方法によって検出した第１レーンのどこに路駐車両があるかは、当該レーンを走行した車両の走行軌跡などから特定されれば良い。

　また、出現判定部Ｇ３１は、自動運転装置が運転席乗員に権限移譲したこと、或いは、運転席乗員がオーバーライドしたことに基づいて、路駐地点を検出しても良い。例えば、自動運転装置が乗員に権限移譲した際、或いは、運転席乗員によるオーバーライドを検出した際の前方カメラ１１の画像を取得及び解析して、その原因が路駐車両であるか否かを判定することにより路駐車両の出現を検出しても良い。

　以上、路駐車両が出現したと判定するための観点を複数列挙したが、出現判定部Ｇ３１は上記の何れか１つを用いて路駐車両が出現したと判定しても良い。また、複数の観点を複合的に組み合わせて用いて路駐車両が出現したと判定しても良い。複数の観点を複合的に組み合わせて用いて路駐車両が出現したと判定する場合には、判断材料の種別に応じた重みを付けて判断しても良い。例えば回避行動に対する重みを１とした場合に、カメラ単体での認識結果を１．２、フュージョンでの認識結果を１．５などとしても良い。

　また、図１５に示すように、車両から提供された画像をサーバプロセッサ２１が解析した結果として、路駐車両の存在が確認できたか否かに応じて、路駐車両が存在すると判定するための、回避行動を実施した車両台数についての閾値を変更してもよい。ここでの回避行動は第１レーンから第２レーン側へ走行位置を移す挙動を意味し、回避行動を実施した車両台数は、路駐地点に近づくまで第１レーンを走行していた車両を母集団に計上されるものとする。画像に基づく路駐車両の存在確認は、オペレータが行ってもよい。また、車両の周辺監視センサ又は路駐有無判定部Ｆ５１で路駐車両が検出されているかどうかで、路駐車両あり判定に要する回避行動を実施した車両の台数を変更してもよい。なお、図１５における車両台数の欄は、回避行動を実施した車両の数の比率や、回避行動を実施したことを示す路駐地点報告を連続して受信した回数に置き換えることができる。また、画像解析の結果、路駐車両がレーン外の路肩領域に完全に収まっていることが確認できた場合には、回避行動を示す車両挙動データがなくとも、路駐車両が出現したと判定しても良い。ただし、その場合には、レーンへのはみ出し量が０であることを対応付けて路駐地点ＤＢ２５１に登録することが好ましい。

　＜消失判定処理＞
　ここでは消失判定部Ｇ３２が実施する消失判定処理について説明する。消失判定部Ｇ３２は、出現判定部Ｇ３１に検出された路駐地点にまだ路駐車両が存在しているかを、路駐地点報告をもとに定期的に判断する構成である。路駐車両がなくなったことの判断材料としては、車線変更の有無や、車両の走行軌跡、通行車両の加減速の変化パターン、カメラ画像、車載システム１による路駐車両の認識結果、レーンごとの通行量の変化パターンなどを採用可能である。

　例えば消失判定部Ｇ３２は、路駐地点において車線変更が実行された回数が減少したことに基づいて判定可能である。例えば、路駐地点付近での車線変更の回数が所定の閾値未満となった場合に、路駐車両がなくなったと判定しても良い。また、消失判定部Ｇ３２は、車両挙動として路駐地点付近での車線変更の回数が減少したことを、路駐車両が検出された時点と比較して、統計的に有意な差が表れた場合に、路駐車両が消失したと判断してもよい。

　消失判定部Ｇ３２は路駐地点付近において第１レーンと第２レーンの境界線をまたいで走行する車両の数が減少したことに基づいて、路駐車両が消失したと判定しても良い。また、消失判定部Ｇ３２は第１レーンにおけるレーン中心から第２レーン側へのオフセット量の平均値が所定の閾値以下となったことに基づいて路駐車両が消失したと判定してもよい。つまり消失判定部Ｇ３２は、路駐地点付近を通行する車両の横位置変化量が所定の閾値以下となった場合に、路駐車両がなくなったと判定しても良い。

　消失判定部Ｇ３２は、路駐地点を、車線変更等の回避行動せずにそのまま通行する（つまり直進する）車両が出現したことに基づいて、路駐車両がなくなったと判定してもよい。路駐地点を走行する車両の出現は、例えば走行軌跡から判断可能である。より具合的には、ある車両の走行軌跡が路駐地点上を通過している場合に、路駐車両はなくなったと判定しても良い。また、その台数が所定の閾値を超過した場合に路駐車両が消失したと判定してもよい。

　また、消失判定部Ｇ３２は、路駐地点報告にカメラ画像が含まれる場合、当該カメラ画像を解析することにより、路駐車両がまだあるかどうかを判定しても良い。消失判定部Ｇ３２は複数の車両からの画像データの解析結果を統計的に処理して、路駐車両が存続しているか否かを判断しても良い。ここでの統計的な処理には多数決や平均化が含まれる。

　消失判定部Ｇ３２は、路駐地点報告に、路駐有無判定部Ｆ５１の判定結果が含まれている場合には、複数の車両での路駐有無判定結果を統計的に処理することにより、路駐車両がまだ存在するか消失したかを判定しても良い。例えば路駐車両は存在しないことを示す報告の受信回数が所定の閾値以上となった場合に、路駐車両は消失したと判定しても良い。また、消失判定部Ｇ３２は、路駐地点報告に周辺監視センサによる停車車両の検出結果が含まれる場合には、複数の車両での停車車両の検出結果を統計的に処理することにより、路駐車両がまだ存在するか消失したかを判定しても良い。

　消失判定部Ｇ３２は、路駐地点付近を通行する車両の挙動として、所定の加減速パターンが観測されなくなった場合に、路駐車両は消失したと判定してもよい。また、第１レーンの交通量と第２レーンの交通量に有意な差がなくなったことや、その差が縮まったこと、第１レーンの通行量が増加したことに基づいて、路駐車両が消失したと判定してもよい。通行量は、例えば路駐地点からその手前４００ｍまでの道路区間における単位時間の通過車両数とすることができる。

　以上、路駐車両が消失した判定するための観点を複数列挙したが、消失判定部Ｇ３２は上記の何れか１つを用いて路駐車両が消失したと判定しても良いし、複数の観点を複合的に組み合わせて用いて路駐車両が消失したと判定しても良い。複数の観点を複合的に組み合わせて用いて路駐車両が消失したと判定する場合には、判断材料の種別に応じた重みを付けて判断しても良い。

　また、図１６に示すように、車両から提供された画像をサーバプロセッサ２１が解析した結果として路駐車両の消失が確認できたか否かに応じて、路駐車両が消失したと判定するための、対象地点を直進した車両台数等についての閾値を変更してもよい。なお、画像の解析（画像確認）はサーバプロセッサ２１の代わりにオペレータが行っても良い。また、車両の周辺監視センサ又は路駐有無判定部Ｆ５１で路駐車両が検出されているかどうかで、路駐車両消失判定に要する、該当地点を直進した車両台数の閾値を変更してもよい。ここでの直進とは、第１レーンから第２レーン側への走行位置の変更をせずに、第１レーンを道なりに沿って走行することを指す。ここでの直進とは必ずしも操舵角を０°に維持して走行するものではない。また、直進した車両台数は、第１レーンを走行してきた車両を母集団として計上されればよい。なお、図１６における車両台数の欄は、該当地点を直進した車両の割合や、路駐車両が存在しないことを示す路駐地点報告を連続して受信した回数に置き換えることが可能である。

　なお、サーバプロセッサ２１での路駐地点の画像確認結果として路駐車両が存在するにも関わらず、当該地点を多くの車両の直進している場合には、路駐情報管理部Ｇ３は、路駐車両が路側帯に収まっており、第１レーンにはみ出していないと判定してもよい。ここでの路側帯とはレーンの外側の領域を指す。路側帯には路肩の概念を含めることができる。

　＜路駐車両の出現及び消失の判定方法の補足＞
　道路構造などの静的な地図要素は経時的な変化が乏しい地図要素であるため、それらについての地図データの更新には、例えば１週間又は１ヶ月など、所定期間内に蓄積された多数の走行軌跡を用いることができる。多数の車両からの報告を母集団として地図データを更新する構成によれば、精度を高めることが期待できる。

　しかしながら、路駐車両は、道路構造等に比べて存続状態が相対的に短い時間で変化する、動的な地図要素に相当する。そのため、路駐車両の発生検知及び消失検知においてはより一層のリアルタイム性が要求される。路駐車両の存続状態や位置等の情報の精度を高めるためには、多数の車両からの報告を母集団とすることが好ましいが、車両からの報告をより多く集めようとすると時間がかかり、リアルタイム性が損なわれる。つまり、路駐車両の存在／消失を検出する構成においては、静的地図を生成する場合よりもリアルタイム性を確保するために、より少ない車両報告から、できる限り精度よく判定して配信する必要がある。

　そのような事情から、上記の出現判定部Ｇ３１は、例えば、現時点から所定の第１時間以内に取得された路駐地点報告に基づいて路駐地点の検出を行う。また、消失判定部Ｇ３２は、所定の第２時間以内に取得された路駐地点報告を元に路駐車両の消失／存続判定を行う。第１時間、及び第２時間は何れもリアルタイム性を確保するために、例えば９０分よりも短い時間に設定されていることが好ましい。例えば第１時間は、１０分や、２０分、３０分などに設定される。第２時間もまた、１０分や、２０分、３０分とすることができる。第１時間と第２時間は同じ長さであっても良いし、異なる長さとなっていても良い。第１時間や第２時間は５分や１時間などであってもよい。

　路駐車両が出現したとの情報は、路駐車両がなくなったとの情報よりも、走行制御上の有用性が大きいとの考え方がある。路駐車両が存在するレーンについての情報が地図データとして事前に取得できれば、余裕を持った回避行動を計画及び実施可能となるためである。これに伴い、路駐車両が存在することについては、より早く検出して配信したいといった需要も想定される。そのような事情から、路駐車両が存在することの検出及び配信開始を早期に実施可能とするために、第１時間は第２時間よりも短く設定されていても良い。

　また、路駐車両がまだ存在しているにもかかわらず路駐車両がなくなったと誤判定及び誤配信することは避けたいといった需要も想定される。そのような需要を鑑みて、第２時間は第１時間よりも長く設定されても良い。第２時間は第１時間よりも長く設定した構成によれば、路駐車両の発生を迅速に通知可能となるとともに、路駐車両が消失したと誤判定するおそれも低減可能となる。

　出現判定部Ｇ３１及び消失判定部Ｇ３２は、取得時刻が新しい報告に示される情報を、例えば重みを大きくするなど、優先的に用いて路駐車両の出現／存続状態を判定するように構成されていても良い。例えば１０分以内に取得した情報の重みを１とした場合に、３０分以内であって１０分以上過去に取得した情報の重みは０．５、それよりも過去に取得した情報の重みは０．２５など、情報の鮮度に応じた重み係数をかけて統計処理しても良い。そのような構成によれば、最新の状態をより強く判断結果に反映させることができ、リアルタイム性を高めることができる。

　また、路駐情報管理部Ｇ３は、報告元の特性に応じて重みをかけて、複数の車両からの報告を統計処理し、路駐車両の出現及び消失を判定しても良い。例えば自動運転車からの報告の重みは、手動運転車からの報告よりも大きく設定されても良い。自動運転車は相対的に高性能なミリ波レーダ１２や前方カメラ１１、ＬｉＤＡＲなどを搭載していることが期待できる。また、自動運転車は不必要に走行位置の変更する可能性は低い。自動運転車による走行位置の変更は、相対的に路駐車両を回避するための動きである可能性が高い。よって、自動運転車からの報告を優先的に使用することにより、路駐車両の有無の判定精度を高めることができる。

　また、出現判定部Ｇ３１及び消失判定部Ｇ３２は、車線変更などの走行位置の変更を頻繁に実施する車両である走行位置不安定車両からの報告はノイズとみなして判定処理に使用しないように構成されていても良い。走行位置不安定車両は、車両位置管理部Ｇ２が、逐次アップロードされてくる車両状態報告に基づき特定され、フラグ等により管理されれば良い。そのような構成によれば、車線変更を頻繁に実施するユーザが運転する車両からの報告に基づいて路駐車両の有無を誤判定するおそれを低減できる。走行位置不安定車両とみなす条件は多様な条件を適用できる。例えば一定時間以内の車線変更の実施回数が所定の閾値以上となっている車両を、走行位置不安定車両として抽出しても良い。ここでの閾値は、路駐車両回避のための車線変更（離脱と復帰の２回）を除くため、３回以上に設定されていることが好ましい。例えば走行位置不安定車両は、例えば１０分などの一定時間以内に車線変更を４回以上実施している車両とすることができる。

　また、図１５及び図１６に例示したように、路駐車両が出現したと判定する条件（例えば閾値）と、路駐車両が消失したと判定する条件は異なっていても良い。例えば路駐車両が消失したと判定する条件は路駐車両が出現した判定する条件よりも厳しく設定されていても良い。路駐車両が出現したことの判断材料と、路駐車両が消失したことの判断材料は相違していてもよい。また、出現判定時と消失判定時とで、情報種別毎の重みは異なっていても良い。例えば路駐車両が出現したと判定する場合には、カメラ画像の解析結果の重みを車両挙動データよりも大きくする一方、路駐車両が消失したと判定する場合には、車両挙動データの重みをカメラ画像の解析結果よりも大きくしても良い。カメラ画像は物体があることの検証には向いている一方、物体がないことの検証には、例えば別の場所を撮像している可能性を考慮すると信頼度が劣るためである。

　＜車両制御処理＞
　次に路駐情報を用いた車両制御の例について図１７を用いて説明する。図１７は例えば前述のアップロード処理などとは独立して実行されれば良い。図１７に示す車両制御処理は例えば運転支援ＥＣＵ６０による自動車線変更機能がユーザ操作に基づいて有効化されている場合に、所定の周期で実行されればよい。なお、自動車線変更機能が有効化されている状態には、所定の走行計画に従って車両を自律的に走行させる自動運転中も含まれる。図１７に示す車両制御処理は一例としてステップＳ６０１～Ｓ６０８を含む。ステップＳ６０１～Ｓ６０８は運転支援ＥＣＵ６０及び地図連携装置５０が連携して実行される。

　まずステップＳ６０１では、地図連携装置５０がメモリＭ１に保存されている地図上路駐情報を読み出し、運転支援ＥＣＵ６０に提供してステップＳ６０２に移る。ステップＳ６０２では運転支援ＥＣＵ６０が、地図上路駐情報に基づき、自車両の走行レーン上、前方所定距離以内に路駐車両が存在するか否かを判定する。路駐車両が存在しない場合ステップＳ６０２を否定して本フローを終了する。その場合、別途作成されている走行計画に基づいた走行制御を継続する。一方、路駐車両が存在する場合ステップＳ６０２を肯定判定してステップＳ６０３を実行する。

　ステップＳ６０３では前方カメラ１１の出力信号に基づき、自車両が第１レーンを走行しているか否かを判定する。第１レーンを走行している場合には、ステップＳ６０３を肯定判定してステップＳ６０４を実行する。一方、第１レーンを走行していない場合には、ステップＳ６０３を否定判定してステップＳ６０７を実行する。

　ステップＳ６０４では、路駐車両を避けるような走行軌道となるように、走行計画を修正する。例えば、第１レーンから第２レーンへと車線変更する内容を含む走行計画を作成する。修正後の走行計画には、第１レーンから第２レーンへと離脱するポイント（つまり車線変更点）の設定も含まれる。ステップＳ６０４が完了するとステップＳ６０５を実行する。ステップＳ６０５ではＨＭＩシステム１６と連携して、修正後の走行計画に関する情報を提示する。例えば路駐車両を避けるための車線変更を実施することを乗員に通知する。ステップＳ６０５が完了するとステップＳ６０６に移る。ステップＳ６０６では車線変更を実行して本フローを終了する。

　ステップＳ６０７では、前方カメラ１１の出力信号に基づき、自車両が第２レーンを走行しているか否かを判定する。第２レーンを走行している場合には、ステップＳ６０７を肯定判定してステップＳ６０８を実行する。一方、第２レーンを走行していない場合には、ステップＳ６０７を否定判定して本フローを終了する。ステップＳ６０８では割り込み警戒処理を実行する。例えば割り込み警戒処理として、ＨＭＩシステム１６と連携して、第１レーンからの割り込みに対する注意を促す情報を提示する。また、割り込み警戒処理として、第１レーンを走行している車両が第２レーンに入ってきやすいように、先行車両との車間距離を長めに設定してもよい。

　なお、以上では、自車走行レーンが第１、第２レーンの何れでもない場合には、特段の処理を実施しない構成を開示したがこれに限らない。自車両の走行位置が第３レーンである場合にも、路駐車両の存在を通知してもよい。なお、走行レーンが第１レーンから離れるほど、路駐車両についての情報提示の態様は弱めることが好ましい。走行レーンが第１レーンから離れるほど、路駐車両の影響は受けにくく、ユーザにとっては情報の有用性が低下するためである。走行レーンが第１レーンから離れるほど、路駐車両についての情報提示の態様は弱めることにより、ユーザに煩わしさを与えるおそれを低減できる。

　＜上記システムの作動とその効果の一例について＞
　上記のシステム構成によれば、まず地図連携装置５０が路駐車両を検出したことをトリガとして路駐地点報告をアップロードする。地図サーバ２は、車両からアップロードされてくる情報に基づいて路駐車両が存在する地点（つまり路駐地点）を検出する。そして、当該路駐地点付近を走行予定の車両に対して当該路駐車両の存在を通知する。また、地図連携装置５０は、地図サーバ２から通知された路駐地点付近を通過する際の自車両の挙動を示す車両挙動データ、及び、センシング情報の少なくとも何れか一方を地図サーバ２に送信する。

　ここで、仮に路駐車両が残存しており、自車両が、例えば第１レーンなど、路駐車両の影響を受けるレーンを走行している場合には、地図連携装置５０が地図サーバ２に送信する車両挙動データは、回避行動が行われたことを示す。また、仮に自車両が路駐車両のないレーンを走行している場合であっても、路駐車両を避けるために車線変更してきた車両との衝突を避けるために減速しうる。つまり、割り込み車両との衝突を避けるための減速及び再加速といった、巡航時には見られない挙動が観測されうる。一方、路駐車両が消失している場合には、路駐車両や割り込み車両を避けるための車両挙動は観測されなくなる。つまり、路駐車両登録地点付近を通過する際の車両挙動データは、路駐車両が残存しているか否かの指標として機能する。

　また、仮に路駐車両が残存している場合には、停止車両が検出されていること、あるいは当該路駐車両の画像を含むセンシング情報が地図サーバ２に送信される。一方、路駐車両が消失している場合には上記の情報はセンシング情報に含まれなくなる。よって、センシング情報もまた、路駐車両が残存しているか否かの指標として機能する。つまり、路駐地点付近を通過する際の車両挙動データやセンシング情報は、路駐車両が残存しているか否かの指標として機能する。

　故に、地図サーバ２は、複数の車両から提供される車両挙動データ及びセンシング情報の少なくとも何れか一方に基づき、路駐地点にまだ路駐車両が残存しているのか、消失したのかを特定可能となる。また、当該路駐地点を通行する車両からの報告に基づいて路駐車両の消失を検知した場合には、路駐情報を配信済みの車両に対して配信する。上記の構成によれば、駐停車している車両の存在箇所及びその存続状態をリアルタイムに認識可能となりうる。なお、地図サーバ２は、車両からの路駐地点報告が受信しなくなったことに基づいて駐停車されていた車両が移動したことを検知してもよい。

　図１８は地図上路駐地点情報の有無による車両の挙動の変化を概念的に示した図である。地図上路駐地点情報が存在しない場合には、図１８の（Ａ）に示すように、前方カメラ１１が路駐車両を認識可能な位置に達してから、車線変更等の回避行動が実施される。地図サーバ２はそのような車両挙動を収集することで、路駐車両の存在／出現を検知し、路駐地点情報として配信し始める。認識可能位置は、前方カメラ１１やミリ波レーダ１２の性能及び路駐車両の大きさ等によって変動しうる。認識可能位置は、晴天時など良好な環境下において、路駐車両から例えば１００ｍから２００ｍ程度手前の地点となる。

　図１８の（Ｂ）は、地図サーバ２から路駐地点情報を取得済みの車両の挙動を概念的に示している。地図サーバ２から地図データとして路駐地点情報を取得済みの車両は、図１８（Ｂ）に示すように、認識可能な位置に達する前から車線変更を実施可能となる。つまり、余裕をもって車線変更や、ハンドオーバー等の対応を実施可能となる。

　一方、路駐車両は時間の経過に伴い、移動するなどして消失する。現実世界において路駐車両が消失してからそのことを地図サーバ２が検知するまでには所定の時間差（すなわち遅延）が存在する。そのため、現実世界において路駐車両が消失した直後においては図１８の（Ｃ）に示すように、実際には路駐車両が存在しないにも関わらず、地図上路駐情報に基づいて車線変更を実施した車両が通過するケースが発生する。

　しかしながら、本開示の地図サーバ２は、路駐地点付近を通過する車両から、路駐地点報告を取得可能に構成されているため、当該路駐地点報告に基づいて速やかに路駐車両の消失を認識できる。その結果、路駐車両の消失を車両に速やかに配信可能となり、車両側にて不要な車線変更やハンドオーバー等が実施されるおそれを低減できる。図１８の（Ｄ）は路駐車両の消失が地図サーバ２で確認された後の様子を示している。

　また、本開示の地図サーバ２は、複数の車両からの報告に基づいて、及び／又は、複数の観点で路駐車両が真に消失したか否かを検証する。このような構成によれば、実際には路駐車両が存在しているにも関わらず、路駐車両が消失したと誤配信するおそれを低減できる。

　また本開示の構成によれば、車両からアップロードされた画像を解析結果として路駐車両が消失したとの判定結果が得られている場合には、路駐車両が消失したと判定するための、回避行動をしなかった車両の台数等に対する閾値を低減する。また、複数の車両での周辺監視センサでのセンシング情報を統計処理することにより路駐車両が消失したとの判定結果が得られている場合には、路駐車両が消失したと判定するための、回避行動をしなかった車両の台数等に対する閾値を低減する。

　例えば、サーバプロセッサ２１での画像解析の結果からも路駐車両が消失したことが確認できている場合には、１台又は数台の車両挙動情報から路駐車両が消失したと判定してもよい。当該構成によれば、より迅速に路駐車両が消失したとの判定を確定できる。その結果、例えば図１８の（Ｃ）から（Ｄ）への移行期間を短縮可能となる。車両挙動と画像解析を組み合わせて路駐車両の存続状況を判定する構成によれば、リアルタイム性と情報の信頼性を両立可能となる。

　また、地図サーバ２は一例として、車両が当該路駐車両を回避するための行動をしなくなったことを条件として、路駐車両が消失したとの判定を確定してもよい。そのような構成によれば、画像だけでは判断しないため、路駐車両が偶発的にカメラに写っていない場合に路駐車両が消失したと誤判定するおそれを低減できる。

　また上記構成では一般道路における駐車車両（つまり路駐車両）を検出する。一般道路における路駐車両は、第１レーンを半分近く塞ぐように存在していることがあり、自動運転／運転支援機能の障害となりうる。例えば、路駐車両が第１レーンを塞いでいることに基づいて、自動運転等のサービスが中断される可能性がある。上記のように路駐車両の位置を配信する構成によれば、余裕をもってハンドオーバーを実行したり、路上駐車車両が存在しない経路を採用したりすることが可能となる。

　なお、一般道路における駐車車両は、車両からの落下物等の静止物とは異なり、当該車両の利用者によって移動を再開するため、その存続状態は、落下物等よりも相対的にダイナミックに変化しうる。つまり、駐停車両の検出／消失の判定は、落下物よりもより一層のリアルタイム性が要求される。

　また、都市部においては、路駐車両の発生頻度は落下物などよりも高い。特に、路駐車両は、駅や施設の周りに発生しやすい。加えて、或る路駐車両の前後には、新たな路駐車両が出現するなど、路駐車両の影響を受ける範囲は経時的に伸び縮みする。その他、路駐車両は、人々の移動が活発な昼間は発生しやすい一方、深夜から早朝にかけては発生しにくいなどの傾向もある。あるいは、日中は法律等の規制により路駐車両が出現しない一方、深夜においては規制が解除されて駐車車両が出現しやすいエリアの存在も想定されうる。つまり、路駐車両には発生しやすい時間帯や場所があり、落下物とは障害物としての特性が異なる。

　また、路駐車両はあくまで車両であるため、画像だけでは路駐車両なのか、信号待ちなどのための一時停車車両なのかの判別が難しい。これに対し、道路端からの距離や信号機からの距離など、道路構造物に対する停車車両の相対的な位置関係を示す情報を用いて路駐車両を検出する構成によれば、路駐車両なのか、信号待ちしている車両なのかの判別精度を高めることができる。

　加えて、上記の構成によれば、車載システム１は地図サーバ２からの配信情報に基づき、交差点右左折後や、カーブ出口付近など、周辺監視センサの死角となりやすい場所に路駐車両が存在することも事前に検知可能となる。その結果、自動運転装置または運転支援ＥＣＵ６０が適切なパスプランを作成可能となる。具体的には、交差点を左折する際のパスプランとして、左折後は第１レーンに入るパスプランを基本パスプランとして作成する自動運転装置が想定される。このような自動運転装置においては、左折後の第１レーンが路駐車両でふさがっている場合は、交差点内のパスプランの変更が必要になる。例えば第１レーンではなく第２レーンに入るような経路を生成することとなる。

　仮に地図データとして路駐車両の情報を取得できていない場合、上記の自動運転装置は交差点退出後に路駐車両を検出してから急遽パスプランを変更することとなり、ユーザに不快な横加速度を感じさせてしまう可能性がある。或いは、急に走行位置を変更することになるため周辺車両のドライバを戸惑わせる可能性がある。そのような課題に対し、本開示の路駐情報配信システムを利用する自動運転装置は、左折後に路駐車両が存在することを踏まえたパスプランを事前に作成可能となる。故に、ユーザに所定値以上の横加速度を感じさせたり、周辺車両のドライバを困惑させたりする恐れを低減できる。以上では自動運転装置がパスプランを作成する場合の効果について言及したが、人間が運転操作をする場合も同様である。ＨＭＩシステム１６にて右左折後などの死角に路駐車両が存在することを通知されることにより、それを踏まえた運転操作が可能となる。つまり、本開示のシステムによれば、自動運転装置やドライバによる車両制御の安定性や、ユーザ利便性を高めることができる。

　また、上記構成によれば、車載システム１は路駐車両によって路肩がふさがっているか否かを取得することができる。自動運転装置には、自動運転が継続困難となった場合、ＭＲＭ（Minimum Risk Maneuver）にて路肩等の安全に停車できる場所まで退避走行する機能が実装される。一般道においては安全に停車できるはずの場所が、路駐車両により一時的に使えなくなっている可能性もある。上記の路駐情報配信システム１００によって配信される駐車地点情報は、ＭＲＭ時の目的地設定に利用することができる。例えば車載システム１は、ＭＲＭ実行時に最寄りの安全な停車場所に駐車車両がある場合には、別の場所を探す、或いは、現在の走行レーン上に緩やかな減速で停車するなどの処置を取ることが可能となる。

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

　＜路駐地点の出現／消失判定処理の補足＞
　カメラ画像に基づき道路上に列をなすように停車している複数の車両を地図連携装置５０が認識した場合、それらが信号待ち等による車列である一時停車列か、路駐車両による列であるかの判断が難しいことがある。ただし、検出された車列の中に、車体の向きが他の車両と反対向きである車両が混在している場合には、当該車列が一時停車列である可能性は極めて小さい。向きが不揃いな車列については、信号待ち等の車列ではなく、駐車車両による列と判定しても良い。車両の向きは画像解析により特定可能である。このように路駐有無判定部Ｆ５１は、停止車両の列を検出した場合に、それらの車体向きが整合しているか否かに基づき、各車両が路駐車両に該当するか否かを判定しても良い。その他、路駐有無判定部Ｆ５１は、サイドミラーが格納されている停止車両については路駐車両と判定しても良い。

　路駐有無判定部Ｆ５１は、前述の通り、周辺監視センサで検出された停止車両の地図データ上の位置を特定することによって、当該停止車両が路駐車両であるのか、信号待ち等の一時停車車両なのかを識別しても良い。より具体的には図１９に示す手順により、路駐有無判定部Ｆ５１は、検出された停止車両が信号待ち等による一時停車車両であるのか、路駐車両であるのかを識別しても良い。図１９に示すフローチャートは一例としてステップＳ７０１～Ｓ７０９を含む。フローチャートが備えるステップ数や処理順序等は適宜変更可能である。当該処理フローは、前述の種々の処理と並列的に、又は、組み合わせて、又は置き換えて実施可能である。

　まず、ステップＳ７０１では地図取得部Ｆ２が、車両内または外部に配されている地図記憶部１４３から現在位置を基準として定まる所定範囲の地図データを取得してステップＳ７０２に移る。なお、ここで読み出される地図データは、少なくとも道路端の位置を示す情報を含んでいればよい。

　ステップＳ７０２では検出物情報取得部Ｆ４が周辺監視センサからセンシング情報を取得してステップＳ７０３に移る。ステップＳ７０３では自車位置取得部Ｆ１がセンシング情報に含まれるランドマーク等の情報と、地図データとに基づきローカライズ処理を実施してステップＳ７０４に移る。なお、ステップＳ７０４は単純にＧＮＳＳ受信機での測位結果を取得する処理であってもよい。

　ステップＳ７０４では路駐有無判定部Ｆ５１が、ステップＳ７０２で取得したセンシング情報に基づき、停止車両が検出されているか否かを判定する。停止車両が検出されていない場合には、ステップＳ７０４を否定判定して本フローを終了する。一方、停止車両が検出されている場合には、ステップＳ７０５に進む。ステップＳ７０５では、検出されている停止車両の自車両に対する相対位置と、ステップＳ７０３で特定されている自車両の位置情報とから、当該停止車両の地図上位置を特定してステップＳ７０６に進む。当該処理により、地図データを用いて道路端から停止車両までの距離が算出可能となる。

　ステップＳ７０６では、ステップＳ７０５での演算結果に基づき、道路端から停止車両までの距離が所定の駐車判定閾値未満であるか否かを判定する。ここでの駐車判定閾値は、検出された停止車両が、路駐車両か、信号待ち等の一時停車車両かを切り分けるためのパラメータであって、前述の第２距離に対応する。駐車判定閾値は例えば０．７５ｍや１ｍなどに設定されうる。

　道路端から停止車両までの距離が駐車判定閾値未満である場合には、ステップＳ７０７にて当該停止車両は路駐車両であると判定し、ステップＳ７０８に移る。ステップＳ７０８では当該路駐車両の情報を含む路駐地点報告を生成し、地図サーバ２に送信してフローを終了する。

　一方、道路端から停止車両までの距離が駐車判定閾値以上である場合には、ステップＳ７０９にて当該停止車両は、路駐車両ではなく、信号待ち等による一時停止車両と判定して本フローを終了する。

　以上の構成は、１つの側面において地図データを用いて停止車両が道路端から所定距離以上離れているか否かを推定し、当該推定結果に基づき、検出された停止車両が路駐車両に該当するか否かを識別する構成に相当する。一般的に、停止車両が１台程度であったり、停止車両の前後に十分な空間があったりする場合には、周辺監視センサが道路端を認識することが期待できる。一方、停止車両が狭い間隔で列をなしている場合、停止車両列よりも外側の道路情報は、周辺監視センサでは検出困難となりうる。停止車両が遮蔽物となって周辺監視センサでは道路端等が検出できなくなるためである。その為、周辺監視センサだけでは、道路端から停止車両までの距離を算出することも困難となりうる。

　そのような課題に対し、上記のように道路端等の位置情報を含む静的な地図データを用いる構成によれば、周辺監視センサでは道路端の位置を検出できない／検出困難な状況下においても、検出した停止車両が路駐車両に該当するか否かの判定精度を向上可能となる。なお、ここでの停止車両列よりも外側とは、停止車両列から見て自車両とは反対側を指す。路面情報は、区画線又は道路端の位置情報を指す。

　その他、路駐有無判定部Ｆ５１は次のように交差点の位置情報を用いて、周辺監視センサで検出した停止車両が路駐車両に該当するか否かを判定するように構成されていても良い。すなわち、交差点の入り口側の道路に停車している車両は信号待ちで停車している可能性がある一方、交差点の出口側（換言すれば退出側）に停車している車両は、信号待ちである可能性は低い。故に、停車車両が路駐車両であるか否かの判別には、その停車位置は交差点の出口側であるか入り口側であるかを用いて判断しても良い。例えば、交差点入口側の路肩に停車している車両は路駐車両とは判定しない一方、交差点出口側の路肩に停車している車両は路駐車両と判定しても良い。なお、交差点の入り口側とは、換言すれば交差点の手前側に相当する。

　障害物としての路駐車両は上述したとおり、発生しやすい時間帯や場所がある。地図サーバ２は、過去の検出履歴をもとに、路駐車両が発生しやすい時間帯、場所を特定／学習し、当該特定結果をもとに、路駐車両の検出条件を調整してもよい。例えば、路駐車両が発生しやすい条件を満たす地点及び時間帯においては、路駐車両が出現した判断するための条件を緩和してもよい。例えば回避行動を実施した車両の台数等に対する閾値を小さくしてもよい。閾値を小さくする態様には閾値を０に設定する態様も含まれる。そのような態様によれば、路駐車両が出現したことを速やかに路駐地点ＤＢ２５１に追加登録可能となる。

　また、路駐されやすい場所は、路駐車両が消失しても、まもなく別の車両が路駐をする可能性が高い。車両が入れ替わっても、当該地点に路駐車両が存在することには変わりない。故に、路駐車両が発生しやすい地点においては、他の地点よりも、路駐車両が消失したと判定する条件を厳しく設定しても良い。例えば回避行動をしなかった車両の台数等に対する閾値を高く設定してもよい。当該構成によれば、路駐車両が入れ替わりによって地図サーバ２が路駐地点ＤＢ２５１の登録内容を書き換える頻度が高くなるおそれを低減できる。

　また、地図サーバ２は全ての一般道路の路駐状況を同時に判断することは難しい。更新条件を満たす地点のなかで優先順序をつけて処理していく必要がある。例えば、交差点の出口側の路上駐車は、車両制御への影響が大きい。故に、交差点出口から所定距離（例えば５０ｍ）以内にある地点について優先的に出現判定処理又は消失判定処理を実行するように構成されていても良い。また、交通量が多い道路上の地点や、駅や大型商業施設から近い地点から優先的に出現／消失判定を実行するように構成されていても良い。田園部や平均通行量が所定の閾値以下の道路における路駐地点情報を更新する優先度は相対的に低めに設定しても良い。そのような構成によれば、路駐地点情報の有用性が高い地域から優先的に登録内容が更新され、リアルタイム性が確保されやすくなる。その結果、路駐情報配信システム１００の有用性を高めることができる。

　その他、消失判定部Ｇ３２は、車両状態報告に基づき路駐地点を走行位置の変更等をせずに通過する車両が出現したか否かを判定し、路駐地点を直進する車両が生じたことに基づいて路駐車両が消失したと判定してもよい。そのような構成によれば、車両状態報告とは別に路駐地点報告を送信させる必要はない。その結果、車両側での処理が簡略化される。つまり、各車両に車両状態報告を送信させる構成においては、当該車両状態報告の内容を車両挙動データとして援用できるため、路駐地点報告は任意の要素となる。

　＜路駐車両の検出／消失の判定材料についての補足＞
　以上では車載システム１は、前方カメラ１１を用いて路駐車両を検出する構成を開示したが、これに限らない。車両の側方を撮像する側方カメラや、後方を撮像する後方カメラを用いて、路駐車両を検出するように構成されていても良い。同様に、車両の側方に向けて探査波を送信する側方ミリ波レーダや、斜め後ろに相当する後側方を検知範囲とする後側方ミリ波レーダを用いて、路駐車両を検出するように構成されていても良い。

　例えば、車載システム１または地図サーバ２は、側方カメラの画像を用いて路駐車両の有無を判断してもよい。路駐車両が第１レーンを塞ぐ場合、第２レーンへの車線変更の実施が予想されるが、車線変更後は第２レーンを走行するので、前方カメラ１１に路駐車両が写りにくくなる。その結果、車線変更後は路駐車両がないと判定されてしまう恐れがある。路駐車両が存在する方の側方カメラの画像データを路駐車両の有無の判断に使用する構成によれば、路駐車両の側方通過時に路駐車両を見失うおそれを低減できる。なお、側方カメラは、サイドミラーに設けられた後側方をみるものでもよい。加えて、側方カメラと前方カメラ１１は相補的に使用されても良い。例えば報告データ生成部Ｆ５は、路駐地点接近中に撮像された前方カメラ１１の画像と、走行位置変更後に撮像された側方カメラの画像とを含む路駐地点報告をアップロードするように構成されていてもよい。

　また、車両が複数のカメラを備える場合には、車両の周辺環境に応じて、路駐車両認識に使用するカメラや、アップロードするカメラ画像を切り替えてもよい。例えば、前方車間距離が所定の閾値未満であって、且つ後方車間距離が所定の閾値以上である場合には、前方カメラ１１の画像の代わりに、後方カメラや側方カメラの画像を車載システム１又は地図サーバ２による路駐車両の有無の判断材料として使用してもよい。また、先行車両がトラックや消防車などの大型車両であり、且つ、後続車両が軽自動車などの小型車両である場合も同様に、後方カメラや側方カメラを、路駐車両の有無判定に使用するカメラとして採用してもよい。つまり、前方の視界が開けているか否かに応じて、路駐車両の有無判定に使用するカメラを使い分けても良い。ミリ波レーダについても同様に、複数のミリ波レーダを備える場合には、それら複数のミリ波レーダを周辺環境に応じて使い分けても良い。

　また、路駐車両を検出するためのデバイスとしては、ＬｉＤＡＲや、ソナーなどを使用してもよい。これらのデバイスも周辺監視センサに含まれる。ミリ波レーダや、ＬｉＤＡＲ、ソナーなどは測距センサと呼ぶこともできる。地図連携装置５０は、複数種類の周辺監視センサを併用して路駐車両等を検出するように構成されていてもよい。例えば地図連携装置５０はセンサフュージョンによって路駐車両を検出しても良い。

　路駐有無判定部Ｆ５１または路駐情報管理部Ｇ３は、図２０に示すようにＤＳＭ（Driver Status Monitor）１７が検出する運転席乗員の目の動きから、路駐車両の有無を判定しても良い。ＤＳＭ１７は、近赤外カメラを用いて運転席乗員の顔部を撮影し、その撮像画像に対して画像認識処理を施すことで、運転席乗員の顔の向きや視線方向、瞼の開き度合い等を逐次検出するデバイスである。ＤＳＭ１７は、運転席乗員の顔を撮影可能なように、例えば運転席のヘッドレスト部に近赤外カメラを向けた姿勢にて、ステアリングコラムカバーの上面や、インストゥルメントパネルの上面、ルームミラー等に配置されている。

　例えば路駐有無判定部Ｆ５１または路駐情報管理部Ｇ３は、路駐車両の側方を通行する際に、路駐車両があると判断されている方向に運転席乗員の視線が向けられたことに基づいて路駐車両があると判定してもよい。路駐車両が存在する場合には、その路駐車両の影から人が飛び出してこないかを確認するために、運転席乗員は路駐車両の方に視線を向けることが期待できるためである。また、第２レーンを走行している車両の乗員が、路駐車両が存在する方向を見なくなったことに基づいて、路駐車両は消失したと判定しても良い。つまり、路駐車両の側方を通行する際の運転席乗員の目の動きもまた、路駐車両の有無の判断材料となりうる。車載システム１は、路駐車両の側方を通行する際の運転席乗員の視線方向の時系列データを路駐地点報告としてアップロードしても良い。また、車載システム１は路駐車両の側方を通行する際、地図上路駐地点に運転席乗員の視線が向けられたか否かの判定結果をアップロードしても良い。路駐情報管理部Ｇ３は、乗員の視線情報に基づいて路駐車両が存在するのか否かを判定しても良い。

　また、地図連携装置５０は、周辺車両の挙動を路駐車両が存在するか否かの判断材料として地図サーバ２にアップロードしても良い。例えば第１レーン走行時、先行車両が走行位置を第２レーン側へ変更したことを検出した場合には、先行車両が第２レーン側へ走行位置を変更したことをアップロードしてもよい。具体的には前方カメラ１１で前方の車両のレーン中心に対するオフセット量をデータ化し、地図上路駐地点の手前で車線変更したか否かを判定し、その判定結果を含む路駐地点報告を送信しても良い。自車両の前方を走行する車両の挙動を判断する技術としてはＳＬＡＭ（Simultaneous Localization and Mapping）などを援用できる。また、上記の先行車両に限らず、後続車両が車線変更したか否かをアップロードしても良い。アップロードする周辺車両の挙動は、車線変更に限らず、第１レーン内における走行位置の変化などであってもよい。また、自車両が第２レーンを走行している場合には、第１レーンからの割り込みを、路駐車両があることの指標として地図サーバ２にアップロードしてもよい。周辺車両の挙動を示すデータが他車挙動データに相当する。以降では他車挙動データとの区別のため、自車両についての車両挙動データを自車挙動データとも称する。

　ところで、地図連携装置５０を搭載している車両である搭載車両は、地図サーバ２から路駐地点情報を取得できている場合、事前に第２レーン等に車線変更した上で、路駐車両の側方を通過することが想定される。故に、或る地点に路駐車両が存在することを地図サーバ２が認識している状態においては、搭載車両は当該路駐地点付近で回避行動を行いにくくなる。地図サーバ２が路駐車両を認識し、各搭載車両に向けて路駐車両の存在の配信を開始している状況において、通知対象に設定されている路駐地点直前で回避行動を行う車両は、せいぜい地図連携装置５０を搭載していない車両である非搭載車両となりうる。もちろん、路駐車両の情報配信開始後も、例えば非搭載車両の割り込みに由来する減速など、路駐車両の存在を示唆する挙動を搭載車両は行いうる。しかしながら、割り込み車両に対する減速がいつも行われるわけではない。或る地点に路駐車両が存在するとの情報の配信開始後は、配信開始前よりも、該当地点における自車挙動データの有用性は相対的に下がってしまう。

　そのような事情に基づき、地図連携装置５０は、事前に地図サーバ２から通知されている路駐地点付近を通過する際、路駐地点報告として、周辺車両の挙動データや周辺監視センサの検出結果を自車挙動データよりも優先的に送信しても良い。例えば、自車両の挙動データは送らずに、周辺車両の挙動データ及び周辺監視センサの検出結果の少なくとも何れか一方を送信してもよい。ここで報告対象とする周辺車両とは、第１レーンを走行する他車両とすることが好ましい。第１レーンが最も路駐車両の影響を受けやすく、路駐車両が残存しているか否かの指標として有用性が高いためである。上記の構成によれば、路駐車両の消失検知に関して、有用性の低い情報のアップロードを抑制できる。また、路駐車両の消失検知に際して有用性の高い情報を優先的に地図サーバ２に集めることが可能となる。

　なお、搭載車両は、路駐地点情報を取得済みの場合であっても、ドライバの指示に基づき第１レーンを走行することもありえる。地図連携装置５０は、地図サーバ２から通知された路駐地点よりも所定距離手前の判定ポイントにて、自車走行レーンが第１レーンである場合には、他車挙動データよりも優先的に自車挙動データをアップロードしても良い。地図連携装置５０は、判定ポイントでの自車走行レーンが第１レーンである場合には路駐地点報告として自車挙動データを含むデータセットを送信する一方、自車走行レーンが第１レーンではない場合には自車挙動データを含まないデータセットを送信しても良い。具体的には、地図連携装置５０は、判定ポイントでの自車走行レーンが第１レーンである場合には路駐地点報告として自車挙動データと前方カメラ１１の撮像画像を含むデータセットを送信する。一方、判定ポイント通過時の自車走行レーンが第１レーンではない場合には、第１レーンを走行している他車両の挙動と、周辺監視センサの検出結果と、を含むデータセットを送信しても良い。判定ポイントは、例えば登録されている路駐地点から報告対象距離、自車両側となる地点に設定されうる。

　上記の地図連携装置５０は、判定ポイントでの自車走行レーンが第１レーンではない場合には第１レーンである場合に比べて、受信済みの路駐地点付近を通過した際に送信する路駐地点報告に含める自車挙動データの情報量を削減する構成に相当する。自車挙動データサイズの削減は、例えばサンプリング間隔を長くしたり、自車挙動データとして送信する項目数を削減したりすることによって実現されうる。路駐地点報告に含まれる自車挙動の情報量を削減した態様には、路駐地点報告が自車挙動データを一切含まない場合も含まれる。また、上記の構成は、判定ポイント通過時に第１レーンを走行していたか否かに応じて路駐地点報告として送信する内容を変更する構成に相当する。

　さらに、地図連携装置５０は、地図サーバ２から通知されていない路駐車両を発見した場合と、地図サーバ２から通知されている路駐地点を通過した場合とで、地図サーバ２に送信するデータセットの中身を変更するように構成されていても良い。便宜上、地図サーバ２から通知されていない路駐車両を発見した場合に送信する、路駐地点報告としてのデータセットのことを未登録地点報告とも記載する。また、地図サーバ２から通知されている路駐地点の通過時に地図サーバ２に送信する、路駐地点報告としてのデータセットのことを登録済み地点報告とも記載する。未登録地点報告は、例えば自車挙動データと周辺監視センサから入力データとを含むデータセットとする一方、登録済み地点報告は、例えば他車挙動データと周辺監視センサから入力データとを含むデータセットとすることができる。登録済み地点報告は、未登録地点報告よりも自車挙動データのサイズが半分以下に抑制されたデータセットとする事ができる。当該構成によれば、路駐車両の出現判定及び消失判定のそれぞれの特性に応じた情報を効率的に地図サーバ２に集める事が可能となる。

　なお、周辺車両の挙動をアップロードする構成では、地図サーバ２に同一車両の挙動が多重報告される可能性が生じる。同一車両の挙動が地図サーバ２で多重にカウントされることを防ぐため、自車両及び周辺車両の挙動はそれぞれの車両ＩＤと対応づけてアップロードすることが好ましい。周辺車両の車両ＩＤは、車車間通信で取得したものであってもよいし、ナンバープレートを画像認識することで取得したものであってもよい。

　地図連携装置５０は、自車両が駐車されたこと、及び、発進したことなどを地図サーバ２に送信するように構成されていても良い。便宜上、自車両が駐車したことを示すデータセットを自車駐車報告と称するとともに、自車両が発進したことを示すデータセットを自車発進報告と称する。自車駐車報告は、少なくとも自車両が駐車した位置情報を含むデータセットである。自車発進報告は、少なくとも自車両が駐車されていた位置情報を含むデータセットであって、当該地点から駐車車両が消失したことを示すデータセットに相当する。自車駐車報告及び自車発進報告は、路駐地点報告又は車両状態報告の一種と解する事ができる。

　仮に地図連携装置５０が自車駐車報告を送信しない構成では、自車両が路上に駐車した場合にも、そのことを他車両が検出し、自車両にかかる路駐地点報告を地図サーバ２に送信するまでは地図サーバ２はそのことを認識できない。これに対して、地図連携装置５０が自車駐車報告を自発的に送信する構成によれば、地図サーバ２は、自車両の挙動に由来する路駐地点をリアルタイムに認識可能となる。また、地図連携装置５０は自車発進報告を送信する構成によれば、地図サーバ２は、他車両からの報告を待つことなく、路駐車両としての自車両がいなくなった地点をリアルタイムに認識可能となる。

　なお、自車両が駐車されたことは例えば車速が０となったことに基づいて特定可能である。自車両の駐車は、走行用電源がオフに設定されたことに基づいて特定されてもよい。自車両の発進は、走行用電源がオンとなったのちに車速が所定の閾値（例えば１０ｋｍ／ｈ）以上となったことに基づいて検出されうる。自車両が駐車されたか否か、及び、自車両が発進したか否かの判定方法としては多様な方法を採用可能である。

　路駐有無判定部Ｆ５１は、例えば図２１に示す手順により、既存の駐車列の隙間に自車両が駐車したことを地図サーバ２に報告するように構成されていても良い。図２１に示すフローチャートは一例としてステップＳ８０１～Ｓ８０５を含む。前述の通り、フローチャートが備えるステップ数や処理順序等は適宜変更可能である。図２１に示す処理フローは、前述の種々の処理と並列的に、又は、組み合わせて、又は置き換えて実施可能である。図２１に示す処理は車両の走行用電源がオンである間、定期的に実施されうる。

　まずステップＳ８０１では検出物情報取得部Ｆ４が周辺監視センサからセンシング情報を取得してステップＳ８０２に移る。ステップＳ８０２ではステップＳ８０１で取得したセンシング情報に基づき、道路端に沿って並ぶ複数の路駐車両、すなわち路駐車両列が検出されているか否かを判定する。路駐車両の列が検出されている場合にはステップＳ８０２を肯定判定してステップＳ８０３に進む。一方、路駐車両の列が検出されていない場合にはステップＳ８０２を否定判定してステップＳ８０３に移る。なお、停止車両が路駐車両に該当するか否かは、路駐情報取得部Ｆ２１が地図サーバ２から取得した路駐地点情報を併用して判定されても良い。

　ステップＳ８０３では報告データ生成部Ｆ５が、ステップＳ８０１で取得したセンシング情報に基づき、路駐車両同士の隙間であるギャップを検出する。なお、報告データ生成部Ｆ５は、センシング情報と代替的に／相補的に路駐情報取得部Ｆ２１が取得した路駐地点情報に基づき、ギャップを検出しても良い。ギャップを検出することはギャップがある領域を特定することに相当する。ギャップは、少なくとも自車両が縦列駐車可能な長さを有する空き空間である。例えば道路端に沿って２ｍ以上の長さを有する空き空間がギャップに相当する。ステップＳ８０３においてギャップが存在しなかった場合には本フローは終了されうる。

　ステップＳ８０４では報告データ生成部Ｆ５が、ステップＳ８０３で検出されたギャップに自車両が駐車したか否かを判定する。ギャップに駐車したことは、例えばギャップ内で車速が０となったことに基づいて判断できる。自車両がギャップに駐車した場合、報告データ生成部Ｆ５は、自車駐車報告を生成し、地図サーバ２に送信する（ステップＳ８０５）。ステップＳ８０３で検出されたギャップに自車両が駐車しなかった場合、例えば当該ギャップの側方を自車両が通り過ぎた場合には、本フローを終了する。なお、上記のフローは車両の移動に伴って、あるいは、一定時間ごとに実施されうる。

　上記のように地図連携装置５０が自車駐車報告を送信する構成によれば、地図サーバ２は、車両が路上駐車されている地点をリアルタイムに認識可能となる。特に路駐車列のギャップに自車両が駐車したことに基づいて自車駐車報告を送信する構成によれば、地図サーバ２は、後述する路駐エリアの延長／結合や、路駐エリアの分断などをリアルタイムに処理可能となる。

　なお、以上では既存の駐車列の隙間に自車両が駐車した場合について例示したが、自車駐車報告を生成及び送信するシーンはこれに限定されない。路駐車列のギャップに限らず、自車両が道路上に駐車されたことに基づいて自車駐車報告を送信しても良い。地図連携装置５０は、例えば道路端に沿うように自車両が駐車したことに基づいて、自車駐車報告を生成及び送信してもよい。道路端に沿った駐車とは、道路端から自車両の側面部までの距離が駐車判定距離以内であって、自車両の前後方向と道路端とがなす角度が所定値（例えば３０度）未満である駐車態様を指す。道路端から自車両の側面部までの距離や、道路端に対する自車両の向きは周辺監視センサの検知結果に基づき特定可能である。自車発進報告も、駐車列から退出する場合だけでなく、発進する際は常に送信されてもよい。また、道路上に駐車したことを条件として、自車駐車報告や自車発進報告を送信するように構成されていても良い。

　＜地図連携装置５０による検出信頼度の算出＞
　路駐有無判定部Ｆ５１は、前方カメラ１１で検出されているか否か、ミリ波レーダ１２で検出されているか、及び回避行動の有無の組み合わせによって、路駐車両が実際に存在する可能性を検出信頼度として算出しても良い。例えば図２２に示すように路駐車両が存在することを示唆する観点（センサや挙動など）が多いほど、検出信頼度を高く算出するように構成されていても良い。なお、図２２に示す検出信頼度の決定態様は一例であって適宜変更可能である。

　なお、図２２の車両挙動は、自車両が第１レーン走行中である場合には、自車両の回避行動を指すものとなる。自車両が第２レーン走行中である場合には、第１レーンを走行する周辺車両の挙動を検出信頼度の算出に代用可能である。例えば、第１レーンから第２レーンへの車線変更（換言すれば割り込み）の有無を、検出信頼度を算出するための観点として採用可能である。また、第１レーンから第２レーンへの割り込みがある場合には、第２レーンの車の流れも遅くなることが見込まれる。故に、自車両が第２レーンを走行している場合において、地図上路駐地点の手前で走行速度の低下が見られた場合には、周辺車両が回避行動を実施していると判定しても良い。

　路駐地点報告には、路駐有無判定部Ｆ５１が算出した、上記の検出信頼度が含まれていても良い。地図サーバ２は複数の車両からの報告に含まれる検出信頼度を統計処理して、路駐車両が存在するか否かを判定してもよい。検出信頼度は、ＤＳＭ等にて検出される乗員の視線情報を併用して評価されても良い。例えば路駐車両の側方を通行する際に、路駐車両があると判断されている方向に運転席乗員の視線が向けられていた場合には検出信頼度をより高く設定しても良い。

　上記の検出信頼度は、路駐車両が存在するという報告の信頼度を示す。故に、上記の検出信頼度は存在報告信頼度とも呼ぶことができる。なお、路駐有無判定部Ｆ５１は、前方カメラ１１で検出されているか否か、ミリ波レーダ１２で検出されているか、及び回避行動の有無の組み合わせによって、路駐車両が存在しない可能性を不検出信頼度として算出しても良い。不検出信頼度は、上記検出信頼度の裏返しに相当する。検出信頼度が高いほど、不検出信頼度は低く設定されれば良い。不検出信頼度は、路駐車両が存在しないという報告の信頼度を示す。故に、上記の不検出信頼度は不在報告信頼度とも呼ぶことができる。

　＜路駐車両が存在する確度について＞
　地図サーバ２は、路駐車両が存在する可能性を実在確度として算出して配信するように構成されていても良い。実在確度は、路駐車両が存在するという判定結果及び通知の信頼度に相当する。例えば路駐情報管理部Ｇ３は、図２３に示すように路駐車両が存在するとの判定結果の信頼度を実在確度として算出する確度算出部Ｇ３３を備えていてもよい。

　確度算出部Ｇ３３は、複数の車両の挙動データをもとに、回避行動を実施した車両の割合等に基づいて実在確度を算出する。例えば確度算出部Ｇ３３は、図２４に示すように、路駐車両の存在を示唆する報告を行った車両の台数が多いほど、実在確度を高く設定する。路駐車両の存在を報告した車両とは、第１レーンから第２レーン側への走行位置の変更を実施した車両のほか、例えば第２レーンを走行していた車両であって、路駐車両の検出結果をアップロードした車両が含まれる。また、確度算出部Ｇ３３は、サーバプロセッサ２１による画像解析またはオペレータの目視によって路駐車両の存在を確認できた場合を１００として、路駐車両の存在を示す報告の数や種類に応じて実在確度を算出しても良い。例えば、回避行動を実施した車両の数や、周辺監視センサで路駐車両を検出した車両の数が多いほど、実在確度を高く設定しても良い。

　確度算出部Ｇ３３は、路駐車両が存在するとの報告の数と、路駐車両が存在しなかったとの報告の数の差分に基づいて算出されても良い。例えば路駐車両が存在するとの報告の数と、路駐車両が存在しなかったとの報告の数が同数である場合を実在確度５０％としても良い。確度算出部Ｇ３３は、複数の車両からの報告に含まれる検出信頼度を統計処理して、実在確度を算出してもよい。確度算出部Ｇ３３は、実在確度を定期的に算出してもよい。

　配信処理部Ｇ４は、上述した実在確度を含む路駐地点通知パケットを配信しても良い。配信処理部Ｇ４は、ある地点における路駐車両の実在確度が変化した場合には、当該地点についての路駐地点通知パケットを配信済みの車両に対しても、更新された実在確度を含む路駐地点通知パケットを配信しても良い。配信処理部Ｇ４は、例えば、路駐車両の存在する確率を含む情報とともに定期的に路駐地点通知パケットを配信しても良い。配信処理部Ｇ４は、実在確度を「まだ有る」、「まだある可能性が高い」、「無くなった可能性が高い」などの３段階で表した路駐地点通知パケットを一定間隔で配信してもよい。

　また、実在確度を１００％から引いた値は、路駐車両が消失した確率を示す消失確度に相当する。配信処理部Ｇ４は、路駐車両の消失確度を含む消失通知パケットを送信しても良い。

　＜商用車の運行情報の利用＞
　バスやタクシー、トラック、引っ越し作業用車などの商用車は、停車及び移動したことをリアルタイムに地図サーバ２に報告するように構成されていても良い。商用車には工事作業車を含めることができる。例えば上記の商用車は、停車位置及び移動状態を報告するように構成された地図連携装置５０としての商用車向け車載器が搭載されることにより、その停車位置等を地図サーバ２が把握可能に構成されていてもよい。そのようなシステム構成において地図サーバ２は、上記商用車向け車載器から取得した停車位置が道路上である場合には、その地点を路駐地点として登録する。また、商用車向け車載器から移動を再開した旨の報告を受けた場合には、当該車両に対応する路駐地点の設定を解除する。

　地図サーバ２の配信処理部Ｇ４は、商用車向け車載器からの停車報告に基づく路駐地点情報は実在確度を高レベルに設定して即時配信してもよい。また、配信処理部Ｇ４は、商用車向け車載器からの発進報告に基づく消失通知パケットは消失確度を高レベルに設定して即時配信してもよい。いずれの情報も、当事者からの申告に基づくものであり、信頼性が高いためである。なお、地図サーバ２は、上記商用車の停車位置及び移動再開情報等を、車両の運行を管理する運行会社／運行管理サーバから間接的に取得しても良い。また、駐車及び発進の情報を地図サーバ２に送信する構成は、自家用車など商用車以外の車両向けの地図連携装置５０に適用されても良い。

　＜路駐情報の配信態様についての補足＞
　路駐地点通知パケットには、路駐車両の位置、種別、大きさが含まれていることが好ましい。また、路駐車両の位置情報には、位置座標だけでなく、詳細位置情報として第１レーンへのはみ出し量が含まれていても良い。さらに、路駐地点通知パケットには、路駐車両によって塞がれている部分を除いた、第１レーンにおいて車両が走行可能な領域の幅情報が含まれていても良い。

　路駐地点通知パケットに路駐車両のはみ出し量や走行可能幅が含まれている構成によれば、路駐地点通知パケットを受信した車両は、車線変更が必要なのか、横位置調整で回避可能なのかが判別可能となる。また、レーン境界線をまたいで走行する場合においても、第２レーンへのはみ出し量を演算可能となる。第２レーンのはみ出し量を算出できれば、第２レーンを走行する車両に対して自車両のはみ出し量を車々間通信で通知可能となり、周辺車両と走行位置の協調を図ることが可能となる。

　また、路駐地点通知パケットには、路駐車両が発生したと判定した時刻情報や、当該路駐車両がまだ存在していると判定した最新（換言すれば最終）時刻が含まれていても良い。これらの判定時刻が含まれていることにより、情報の受け手側である車両は受信した情報の信頼性を推定可能となる。例えば最終判定時刻からの経過時間が少ないほど信頼性が高い。路駐地点通知パケットは、当該路駐車両の存在を確認した車両の台数などの情報が含まれていても良い。路駐車両の存在を確認した台数が多いほど、当該路駐情報の信頼性を高く見積もることができる。なお、路駐情報の信頼性が高さに応じて、車両制御に用いるか、乗員への通知に留めるかといった車両での制御態様を変更してもよい。

　路駐地点通知パケットには、路駐車両の色合いなどの特徴情報が含まれていても良い。また、或る車両で撮像された路駐車両の画像が含まれていても良い。当該構成によれば、路駐地点を通過予定の車載システム１又は乗員は、地図サーバ２から通知されている路駐車両と現実世界との路駐車両との対応付けが容易となる。その結果として、地図サーバ２から通知されている路駐車両がまだ存在するのか消失したのかの判定精度が向上する。

　配信処理部Ｇ４は、路駐車両レーンにおいて、路駐地点の所定距離手前の地点に、車線変更推奨ＰＯＩ（Point of Interest）を設定して配信してもよい。車線変更推奨ＰＯＩは、車線変更の実行を推奨する地点を指す。このように地図サーバ２にて車線変更推奨ＰＯＩを設定して配信する構成によれば、車両側にて車線変更点を算出する処理を省略可能となり、処理部５１や運転支援ＥＣＵ６０の処理負荷を低減できる。車線変更をユーザに提案する構成においても、車線変更推奨ＰＯＩを用いて路駐車両通知画像を表示するタイミングを決定可能となる。

　路駐地点通知パケットには、路駐車両がなくなったのかなどといった、その場所でのリスクが残っていそうかを示す情報を含めてもよい。その場所にリスクが残っていそうかは前述の実在確度によって表現されても良い。路駐車両消失パケットもまた、路駐地点通知パケットと同様に、路駐車両の特徴や、消失判定した時刻などが含まれていることが好ましい。

　また配信処理部Ｇ４は、例えば自動運転アプリなどの所定のアプリケーションを実行中の車両に対してのみ、路駐地点通知パケットを配信するように構成されていても良い。所定のアプリケーションとしては自動運転を行うアプリケーションの他に、ＡＣＣ（Adaptive Cruise Control）、ＬＴＣ（Lane Trace Control）、ナビゲーションアプリなどを含めることができる。また、路駐地点情報をプル配信する構成においては、地図連携装置５０は、特定のアプリケーションを実行中であることを条件として地図サーバ２に対して路駐地点情報を要求するように構成されていても良い。上記構成によれば、過剰な情報配信を抑制しつつ、運転支援ＥＣＵ６０による制御の安定性を高めることができる。また、配信処理部Ｇ４は、ユーザ設定に基づき、路駐地点情報の受信設定として自動的に受信するように設定されている車両に対してのみ、路駐地点通知パケットをプッシュ配信するように構成されていても良い。そのような構成によれば、ユーザが意図せずに、地図サーバ２と地図連携装置５０とが無線通信するおそれを低減できる。

　さらに、配信処理部Ｇ４は、メッシュ／マップタイル単位で路駐地点情報を配信してもよい。例えばマップタイルにおける路駐地点情報を、当該マップタイルに存在する車両や、当該マップタイルの地図を要求している車両に向けて配信しても良い。そのような構成によれば、配信対象の選定が簡略化されるとともに、複数の路駐地点の情報を一括して配信可能となる。その結果、地図サーバ２の処理負荷を低減可能となる。なお、受信した路駐地点情報をどのように使うかは車載システム１でどのようなアプリが起動しているかに依る。上記構成によれば、車載システム１での路駐地点情報の使いみちの多様性、柔軟性を高めることができる。

　＜車載システム１のアップロード処理について＞
　地図連携装置５０は、路駐情報として、地図に登録されている内容と、車両が観測した内容とが相違する場合のみ、路駐地点報告を送信するように構成されていても良い。換言すれば、地図の内容と実際の状況が一致している場合には路駐地点報告を送信しないように構成されていてもよい。例えば路駐車両の存在が地図に登録されていない地点に路駐車両を観測した場合や、路駐車両があると地図に登録されている地点で路駐車両が存在しなかった場合に路駐地点報告を送信する。上記の構成によれば通信量を抑制できる。また、現実世界と地図登録内容とが一致している部分については、サーバプロセッサ２１は路駐車両の有無に関わる判定処理を実施しなくてよくなる。つまり、サーバプロセッサ２１の処理負荷も軽減可能となる。

　また、地図連携装置５０は、路駐車両付近を通行する際に自発的に車両挙動データを地図サーバ２にアップロードする構成を開示したが、地図連携装置５０の構成はこれに限らない。他の態様として、地図連携装置５０は、車線変更や急減速などの所定の動きを実施した場合にのみ車両挙動データを地図サーバ２にアップロードする構成も考えられる。各車両が特定の動きをした場合にのみ車両挙動データをアップロードする構成では、地図サーバ２に路駐車両が消失したのか否かを判断するための情報が集まりにくくなってしまうといった課題が懸念される。路駐車両が消失すると車両は特別な動きをしなくなるためである。

　上記懸念を踏まえ、サーバプロセッサ２１は、地図上路駐地点を通過中／通過予定の車両に対して、路駐地点報告をアップロードするように指示する制御信号であるアップロード指示信号を送信しても良い。換言すれば地図連携装置５０は、地図サーバ２からの指示に基づいて、路駐地点報告をアップロードするか否かを決定するように構成されていてもよい。そのような構成によれば、地図サーバ２の判断により、各車両による路駐地点報告のアップロード状況を制御可能となり、不要な通信を抑制可能となる。例えば路駐車両の出現や消失に関する情報を十分に収集できている場合には、車両からのアップロードを抑制するといった対応も採用可能となる。

　加えてサーバプロセッサ２１は、車両状態報告を元に路駐車両の存在を示唆する車両挙動が見られた地点を検証地点に設定し、検証地点を通過予定の車両に対して、アップロード指示信号を送信しても良い。路駐車両の存在を示唆する車両挙動が見られた地点とは、例えば２、３台の車両が連続して車線変更を行った地点である。当該構成によれば、路駐車両が存在する疑いがある地点についての情報を集中的にかつ迅速に収集可能となり、路駐車両の存続状態をリアルタイムに検出可能となる。

　また、路駐地点報告をアップロードするか否かは、車両側で設定可能に構成されていても良い。例えばユーザが入力装置を介して路駐地点報告をアップロードするか否かを設定可能に構成されていても良い。さらに、路駐地点報告としてアップロードする情報項目もまたユーザが設定変更可能に構成されていてもよい。そのような構成によれば、ユーザが意図せずに車両挙動データが地図サーバ２にアップロードされ、通信量が増加するおそれを低減できる。なお、プライバシー保護の観点から、送信元情報は所定の暗号化コードを用いて、実際の車両ＩＤとは相違する番号に書き換えて地図サーバ２にアップロードするように構成されていても良い。

　また、路駐情報配信システム１００は、路駐車両に関する情報を積極的にアップロードしたユーザに対してインセンティブを付与するように構成されていても良い。路駐地点報告の送信にインセンティブを設けることで、路駐車両に関する情報を収集しやすくなり、路駐情報配信システム１００の実効性を向上させることができる。インセンティブとしては、自動車に関わる税金の軽減や、地図サービスの利用料金の低減、物品の購入やサービス利用に使用可能なポイントの付与などとすることができる。所定の物品の購入やサービスの利用に使用可能なポイントには、電子マネーの概念も含まれる。

　＜路駐地点のグループ化について＞
　路駐車両は上記のように駐車されやすい場所及び時間帯があるため、最初は一台しか路駐車両がなかった地点であっても、経時的にその前後に新たな路駐車両が出現し、一定の区間が路駐車両で埋まるケースが考えられる。地図サーバ２は、そのようなケースを踏まえ、複数の路駐車両がまとまっている地点を路駐エリアとしてグループ化して配信するように構成されていても良い。例えば地図サーバ２は、路駐車両が１台だけの時はポイントでの通知とし、その前後に別の車両による駐停車が検出された場合にそれらを路駐エリアとして定義して配信してもよい。図２５は当該技術思想に対応する地図サーバ２の構成を示した図であって、グループ化部Ｇ３４を備える。

　グループ化部Ｇ３４は、複数の路駐地点を所定の規則によりグループ化する構成である。グループ化された路駐地点が上述の路駐エリアに相当する。グループ化部Ｇ３４は、例えば、道路延設方向における間隔が所定の閾値（以降、連結距離）未満である路駐地点同士を１つのグループにする。連結距離は例えば２５ｍや、５０ｍ、１００ｍ、２００ｍ、２５０ｍなどとする事ができる。連結距離が短いと路駐エリアが細分化し、例えば自動運転車両に対して頻繁に車線変更を促す事になる。そのため、グループ化のための閾値としての連結距離はある程度の長さを有する事が望ましい。なお、連結距離は、道路種別（国道、県道など）や、制限速度に応じて変更しても良い。道路規模が大きいほど、及び、制限速度が高いほど連結距離が長く設定してもよい。

　なお、前後の路駐車両との間隔が、連結距離以上離れている路駐地点は、別のグループ又はポイントとして扱う。例えば図２６に示すように、連結距離を例えば１００ｍに設定されている場合、車両間隔が１００ｍ以下である路駐車両Ｐｖ１～Ｐｖ３は同一のグループＧｒ１とする。一方、路駐車両Ｐｖ１との間隔が１００ｍ以上となっている路駐車両Ｐｖ４は別グループ又はポイント扱いとする。なお、ここでのポイントとは、何れのグループ（加減すれば路駐エリア）にも含まれない、単独の路駐車両を指す。

　また、グループ化部Ｇ３４は、前後の路駐車両との間隔が連結距離以内であっても、例えば図２７に示すように、その途中に別の道路（以降、分岐路Ｒ１）との接続点がある場合には、当該接続点を節目として、別グループＧｒ２、Ｇｒ３に分けても良い。このように分岐路Ｒ１との接続点を節目に、路駐エリアを分割することにより、路駐エリア情報によって車両が当該道路へ進入できなくなってしまうことを抑制できる。なお、地図サーバ２が、各車載システム１からパスプランを取得可能に構成されている場合であって、分岐路Ｒ１に入る経路を計画している車両が存在しない場合には、分岐路Ｒ１を無視して複数の路駐車両をグループ化するように構成されていても良い。例えばグループＧｒ２、Ｇｒ３を１つのグループに統合してもよい。換言すれば、分岐路Ｒ１を介して存在する複数の路駐地点を１つの路駐エリアと定義しても良い。

　グループ化部Ｇ３４は、路駐地点の出現及び消失に伴って、路駐エリアの大きさ（ひいてはグループの構成）を更新する。例えば図２８に示すように、１つの路駐エリア（グループＧｒ４）を構成していた路駐車両Ｐｖ５、Ｐｖ６が消失したことで、路駐エリア内に連結距離以上の空白が生じた場合には、当該エリアを２つの路駐エリア（グループＧｒ５、Ｇｒ６）に分割する。このような構成によれば、古い路駐エリア情報によって、路肩に寄せて駐停車したいのに駐停車できないといった問題が生じる恐れを低減できる。なお、各地図連携装置５０が自車駐車報告や自車発進報告を送信する構成においては、グループ化部Ｇ３４は、それらの報告に基づいて路駐エリアをリアルタイムに更新可能となる。

　上記のようにグループ化部Ｇ３４を備える構成においては、配信処理部Ｇ４は、同一グループに属する複数の路駐地点についての情報は、路駐エリア情報としてまとめて配信しても良い。路駐エリア情報は、当該エリアの始端位置座標と、その距離を含む。路駐エリア情報は、路駐エリアを構成する駐車車両の台数や、エリアの末尾の位置情報、路駐エリアが伸びる方向などを含んでもよい。また、路駐エリア情報には、エリアの始端及び終端の車両の特徴（色や車種）を含んでも良い。路駐エリア情報に、先頭車両及び末尾車両の特徴情報が含まれていれば、地図連携装置５０においても当該路駐エリア情報で示される地点の現況を検証しやすくなる。例えば路駐エリアが伸びたのか縮んだのかを検証しやすくなる。また、複数の路駐地点情報を路駐エリア情報としてまとめて配信する構成によれば、全体としての通信量を削減することができる。地図連携装置５０もまた、複数の路駐地点を個別に処理する必要がなくなるため、地図連携装置５０の処理負荷も低減可能となる。

　なお、地図連携装置５０は路駐エリアとして定義されている地点を走行する際にアップロードする路駐地点報告は、駐車エリアの始点及び終点付近のデータに限定してもよい。駐車エリアが長い場合、該当区間を走行し常に画像データ等をアップロードしようとすると、通信コストやトラフィックが多くなってしまう懸念が有るためである。ただし、路駐エリアとして通知されている領域内に、路駐車両の移動により、連結距離以上の空きスペースが生じている可能性もある。路駐エリアを通行する際は、例えば連結距離毎、或いは連結距離の半分の距離を走行するたびに、画像データをアップロードするように構成されていても良い。

　配信処理部Ｇ４は、何れの路駐エリア／グループにも属していない路駐地点については、ポイントとして通知すればよい。なお、路駐エリアを構成していた車両が減り、ポイント扱いになった場合、換言すればグループ化が解消された場合は、路駐エリア情報しての配信から、ポイント通知に切り替えればよい。複数の路駐地点の情報をまとめてなる路駐エリア情報もまた、路駐地点情報の概念に含まれる。

　＜駐停車をしている車両群情報の援用例＞
　以上では、一般道路の道路端沿いに駐停車をしている車両の位置を、その周りを通行する車両の挙動データや周辺監視センサの検出結果に基づいてリアルタイムに検出する態様について開示した。しかしながら、上記の駐停車車両の位置の検出方法は、例えば渋滞末尾の位置情報をリアルタイムに検出する技術にも援用できる。以下、車両からの報告に基づいて渋滞区間を判定して配信する渋滞情報配信システムの一例について図２９及び図３０を用いて説明する。

　本開示の渋滞情報配信システムを構成する地図連携装置５０は図２９に示すように、自車位置取得部Ｆ１等に加えて、渋滞情報取得部Ｆ２２を備える。また地図サーバ２は、図３０に示すように、報告データ取得部Ｇ１や配信処理部Ｇ４に加えて、渋滞情報管理部Ｇ５、及び渋滞地点ＤＢ２７を備える。渋滞情報管理部Ｇ５は、発生判定部Ｇ５１及び末尾判定部Ｇ５２を備える。

　渋滞情報取得部Ｆ２２は、地図サーバ２から渋滞区間やその末尾の位置を取得する構成である。報告データ生成部Ｆ５は、自車挙動取得部Ｆ３及び検出物情報取得部Ｆ４が取得した情報に基づいて、地図サーバ２から通知されている渋滞区間である渋滞通知区間の現在の状況を示すデータを渋滞区間報告として地図サーバ２にアップロードする。渋滞区間報告としてアップロードする内容は渋滞通知区間を通行する際の車両挙動データとしてもよいし、渋滞通知区間を撮像した画像データであってもよい。また、周辺監視センサによる停車車両の検出位置情報であってもよい。さらに、上記の複数種類の情報を含んでも良い。

　渋滞情報管理部Ｇ５は、車両からアップロードされてくる渋滞区間報告に基づいて、渋滞末尾の位置や、長さを更新する構成である。発生判定部Ｇ５１は、前時刻においては渋滞区間ではないと判定した地点に、停車している車両が存在する場合には、当該地点を渋滞区間に設定する。渋滞地点の発生を検出する方法は、路駐地点の出現判定と同様の方法を援用することができる。なお、道路上の停車車両の列が、渋滞に依るものか、路上駐車によるにものかは、道路端からの横方向距離やレーンＩＤによって判別されれば良い。例えば、道路端から所定距離（例えば０．５ｍ）以上離れた位置に存在する車列や、第２レーンや第３レーンに存在する車列は、渋滞によるものと判定すればよい。

　末尾判定部Ｇ５２は、車両からの報告に基づいて渋滞末尾の位置を更新するための構成である。例えば末尾判定部Ｇ５２は、前回判定時に渋滞末尾に設定した位置を所定の閾値上の速度で通行する車両が存在する場合には渋滞区間は縮んだものとして、渋滞末尾位置を再計算する。渋滞末尾の位置が代わったことは、例えば路駐車両の出現／消失判定と同様の判定ロジックを採用することができる。なお、渋滞区間の検出に使用する車両挙動は、路駐地点検出時のような第１レーンから第２レーン側への走行位置の変更に限らない。任意の走行レーンから別のレーンへの車線変更を、渋滞末尾位置を特定するための車両挙動データとして採用する事ができる。また、信号機から所定距離以上離れた地点での停車や、ハザードランプの点灯なども渋滞末尾位置を特定するための車両挙動データ（換言すれば判断材料）として採用できる。ここでは、渋滞の有無及び渋滞末尾の位置といった渋滞状況をレーン単位で判定するものとするが、他の態様として道路単位で判定されても良い。

　渋滞地点ＤＢ２７は、渋滞情報管理部Ｇ５によって生成された渋滞区間の情報を保存するデータベースである。渋滞地点ＤＢ２７に保存されている渋滞区間データは、随時渋滞情報管理部Ｇ５によって更新される。渋滞情報管理部Ｇ５による渋滞区間の更新処理は、車両からの報告数が所定閾値を超えた地点から順番に実行されれば良い。配信処理部Ｇ４は、渋滞地点ＤＢ２７に保存されているデータを車両に配信する。

　上記構成によれば、渋滞の有無及び渋滞末尾の位置といった渋滞状況をレーン単位で特定可能となる。渋滞状況をレーン単位で判定する構成によれば、右折待ち／左折待ちの渋滞と、道路全体の渋滞とを区別して配信する事ができる。交差点を直進予定の車両は、自車走行レーンの前方に右左折待ちの渋滞が生じていることを取得することにより、車線変更するなどの対応を取ることが可能となる。

　以上の構成によれば、渋滞区間の情報、特に渋滞末尾のリアルタイムな位置情報を各車両に配信することができる。各車載システム１は、渋滞末尾のリアルタイム内地情報を取得することにより、時間的／距離的な余裕をもって車線変更や減速などの車両制御を実行可能となる。

　＜自動運転への適用例＞
　地図サーバ２が生成した路駐情報やレーンごとの渋滞情報は、例えば、自動運転の実行の可否判断に利用されても良い。自動運転するための道路条件としては、車線数が所定数ｎ以上であることが規定されている構成もあり得る。所定数ｎは「２」以上の整数であり、例えば「２」、「３」、「４」等である。そのような構成では、路駐車両または右左折待ちの渋滞により有効な車線数がｎ未満となっている区間が自動運転不可区間となりうる。有効車線数とは、車両が実質的に走行可能な車線の数である。例えば片側２車線の道路において１車線が路上路駐車両により塞がっている場合であれば、当該道路の有効車線数は「１」となる。

　自動運転不可区間に該当するか否かは車両側（例えば運転支援ＥＣＵ６０や自動運転ＥＣＵ）で判断するように構成されていても良い。また、地図サーバ２が路駐情報に基づいて自動運転不可区間を設定し、当該自動運転不可区間を配信してもよい。例えば、地図サーバ２において、路駐車両による有効車線数が不足している区間を自動運転不可区間に設定して配信するとともに、当該路駐車両の消失が確認された場合に、自動運転不可設定を解除して配信する。なお、自動運転不可区間の設定等を配信するサーバは、自動運転管理サーバ７として、図３１に示すように、地図サーバ２とは別に設けられていても良い。自動運転管理サーバは、自動運転可能／不可能な区間を管理するサーバに相当する。上記のように、路駐情報は、車両毎に設定されている運行設計領域（ＯＤＤ：Operational Design Domain）を充足しているか否かの判断に利用可能である。図３１に示すように、路上路駐情報に基づいて自動運転の可否に関する情報を車両に配信するシステムを自動運転不可区間配信システムと称する。

　＜付言（１）＞
　本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。また、本開示に記載の装置及びその手法は、専用ハードウェア論理回路により、実現されてもよい。さらに、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。例えば、地図連携装置５０及び地図サーバ２が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供できる。地図連携装置５０及び地図サーバ２が備える機能の一部又は全部はハードウェアとして実現されても良い。或る機能をハードウェアとして実現する態様には、１つ又は複数のＩＣなどを用いて実現する態様が含まれる。例えばサーバプロセッサ２１は、ＣＰＵの代わりに、ＭＰＵやＧＰＵを用いて実現されていてもよい。また、サーバプロセッサ２１は、ＣＰＵや、ＭＰＵ、ＧＰＵなど、複数種類の演算処理装置を組み合せて実現されていてもよい。さらに、ＥＣＵは、ＦＰＧＡ（field-programmable gate array）や、ＡＳＩＣ（application specific integrated circuit）を用いて実現されていても良い。処理部５１も同様である。各種プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよい。プログラムの保存媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、ＥＰＲＯＭ（Erasable Programmable ROM）、フラッシュメモリ、ＵＳＢメモリ、ＳＤ（Secure Digital）メモリカード等、多様な記憶媒体を採用可能である。

　＜付言（２）＞
　本開示には以下の構成も含まれる。なお以降における地図サーバは、駐停車地点管理装置に相当し、出現判定部は駐停車地点検出部に相当し、消失判定部は存続状態判定部に相当する。また、情報提示制御装置はＨＭＩシステム／ＨＣＵに相当する。運転支援装置は運転支援ＥＣＵに相当する。
・出現判定部と消失判定部は、路駐車両が存在すると判定するための条件が異なっている、地図サーバ。
・路駐車両が存在する地点を撮像した画像を車両から取得可能に構成されており、消失判定部は、路駐地点において、回避行動をしなかった車両の台数又は割合が閾値を超過していることに基づいて路駐車両が移動したと判定するものであって、上記の画像に路駐車両が映っているかに基づいて、路駐車両が消失したと判定するための閾値を変更する、地図サーバ。
・路駐地点を通過予定の車両に対して、車両挙動データを含む、路駐車両の存続状況を判断するための所定の種別の情報を送信するように指示するように構成されている、地図サーバ。
・出現判定部及び消失判定部の少なくとも何れか一方は、複数車両の車両挙動データに加えて、車両で撮像されたカメラ画像を用いて、路駐車両が存在するか否かを判定するように構成されている地図サーバ。
・路駐車両の出現判定時と消失判定時とで、路駐車両が存在すると判断するための情報種別の組み合わせを変更するように構成されている地図サーバ。
・出現判定時は車載カメラで撮像された画像の解析結果を併用する一方、消失判定時は車載カメラで撮像された画像の解析結果を使用しないように構成された地図サーバ。
・路駐車両の出現判定時と消失判定時とで路駐車両が存在すると判断するための情報種別ごとの重みを変更するように構成されている地図サーバ。
・路駐車両が存在するか否かの判断材料として、車載カメラで撮像された画像の解析結果を使用する構成において、消失判定時には出現判定時よりも、画像の解析結果の重みを小さくするように構成されている地図サーバ。
・レーン毎の通行量を比較することで路駐車両の出現及び消失を判定するように構成されている地図サーバ。
・減速後に実行された車線変更を回避行動として採用するように構成されている地図サーバ。尚、当該構成によれば追い越しのための車線変更を除外することが可能となる。
・第１レーンから１車線以上離れたレーンを走行中／走行予定である車両に対しては路駐地点情報を配信しないように構成されている地図サーバ。
・カメラで路駐車両が検出されている場合であっても、測距センサで立体物が検出されていない場合には、路駐車両が存在するとは判定しない路駐有無判定装置または地図サーバ。
・地図サーバから通知されている路駐地点から一定範囲を走行する場合に、車両挙動を含む路駐地点報告を、地図サーバからの指示に基づき、又は自発的に地図サーバにアップロードするように構成されている、車両用装置としての地図連携装置。
・地図サーバから取得した路駐地点付近を通過した場合には、自車両の挙動を示す自車挙動データ、他車両の挙動を示す他車挙動データ、及び、車載カメラ画像の少なくとも何れか１つを含むデータセットを路駐地点報告としてサーバに送信する報告処理部を備える地図連携装置。
・上記の報告処理部は、通知されている路駐地点から所定距離手前となる判定ポイントにおける自車走行レーンが道路端に隣接するレーンであったか否かに応じて、路駐地点報告としてサーバに送信する内容を変更するように構成されている地図連携装置。
・地図サーバから取得した路駐地点情報をナビゲーション装置または自動運転装置に出力する地図連携装置。
・地図サーバから取得した路駐地点情報に基づいて生成される路駐車両通知画像をディスプレイに表示する情報提示制御装置。
・第１レーンから１車線以上離れたレーンを走行中／走行予定である場合には路駐車両についての情報を乗員に通知しない情報提示制御装置。
・地図サーバから通知された路駐車両の実在確度に基づいて、当該情報に基づいた車両制御を実行するか、情報提示に留めるかを切り替えるように構成されている運転支援装置。

Claims (17)

1. 　少なくとも１つの車両の挙動を示す車両挙動データ、及び、前記車両に搭載されている周辺監視センサのセンシング情報の少なくとも何れか一方を位置情報と対応付けて取得する判断材料取得部（Ｇ１）と、
   　前記判断材料取得部が取得した情報に基づいて、道路上に車両が駐停車している地点を検出する駐停車地点検出部（Ｇ３１）と、
   　前記駐停車地点検出部が検出した、車両が駐停車している地点である駐停車地点に、車両がまだ存在しているか否かを、前記判断材料取得部が取得した情報に基づいて判定する存続状態判定部（Ｇ３２）と、を備える駐停車地点管理装置。
2. 　請求項１に記載の駐停車地点管理装置であって、
   　前記駐停車地点検出部は、前記駐停車地点として、一般道路において車両が駐車されている地点である路駐地点を検出するものであって、
   　道路上に駐停車している車両と道路端との距離が所定距離以内であることに基づいて、当該車両が存在する場所を前記路駐地点に設定するように構成されており、
   　前記駐停車地点検出部によって検出されている前記路駐地点についての情報を車両に配信する配信処理部（Ｇ４）を備える、駐停車地点管理装置。
3. 　請求項２に記載の駐停車地点管理装置であって、
   　前記配信処理部は、
   　前記路駐地点を通過予定の車両に対して、前記路駐地点の情報を示す通信パケットである路駐地点通知パケットを配信するとともに、
   　前記存続状態判定部によって前記路駐地点から車両が消失したと判定された場合には、当該路駐地点についての前記路駐地点通知パケットを配信済みの車両に対して、駐車車両が消失したことを示す通信パケットである消失通知パケットを配信するように構成されている、駐停車地点管理装置。
4. 　請求項２又は３に記載の駐停車地点管理装置であって、
   　前記駐停車地点検出部によって検出されている複数の前記路駐地点を、それらの位置関係に基づきグループ化することにより、複数の前記路駐地点を含む路駐エリアを設定するグループ化部（Ｇ３４）を備え、
   　前記配信処理部は、前記グループ化部でグループ化されている前記路駐地点については、前記路駐エリアの始端位置座標を含む路駐エリア情報として配信するように構成されている、駐停車地点管理装置。
5. 　請求項４に記載の駐停車地点管理装置であって、
   　前記グループ化部は、道路延設方向における間隔が所定の閾値以下となっている前記路駐地点をグループ化することによって前記路駐エリアを設定するように構成されている、駐停車地点管理装置。
6. 　請求項４又は５に記載の駐停車地点管理装置であって、
   　前記配信処理部は、前記路駐エリアの先頭車両の位置座標に加えて、前記路駐エリアの末尾に位置する車両の位置座標、及び、前記路駐エリアの長さの少なくとも何れか一方を含む前記路駐エリア情報を配信するように構成されている、駐停車地点管理装置。
7. 　請求項４から６の何れか１項に記載の駐停車地点管理装置であって、
   　前記配信処理部は、前記路駐エリアの先頭車両の特徴情報、及び、前記路駐エリアの末尾に位置する車両の特徴情報の少なくとも何れか一方を含む前記路駐エリア情報を配信するように構成されており、
   　前記特徴情報は、車体の色及び車種の少なくとも何れか一方を含む、駐停車地点管理装置。
8. 　請求項２から７の何れか１項に記載の駐停車地点管理装置であって、
   　前記駐停車地点検出部は、交差点の退出側に位置する道路における前記路駐地点を前記交差点の入り口側に位置する道路における前記路駐地点よりも優先的に検出するように構成されている、駐停車地点管理装置。
9. 　請求項２から８の何れか１項に記載の駐停車地点管理装置であって、
   　前記判断材料取得部は、複数の車両から前記車両挙動データを取得可能に構成されており、
   　前記駐停車地点検出部及び前記存続状態判定部は、前記車両挙動データに基づいて、第１レーンから第２レーン側に走行位置を移す回避行動を実施しているか否かを判定可能に構成されており、
   　前記駐停車地点検出部は、処理対象とする地点付近において少なくとも１つの車両が前記回避行動をしていることに基づいて当該地点に車両が駐停車していると判定し、
   　前記存続状態判定部は、前記駐停車地点を前記回避行動をせずに通過する車両が出現したことに基づいて、前記駐停車地点に駐停車していた車両はいなくなったと判定する、駐停車地点管理装置。
10. 　請求項２から９の何れか１項に記載の駐停車地点管理装置であって、
    　前記判断材料取得部は、複数の車両から前記センシング情報を取得可能に構成されており、
    　前記駐停車地点検出部は、複数の車両から提供された前記センシング情報に基づいて前記駐停車地点を検出し、
    　前記存続状態判定部は、前記駐停車地点の周辺を通過する車両から提供された前記センシング情報に基づいて、前記駐停車地点にまだ車両が存在するか否かを判定する、駐停車地点管理装置。
11. 　請求項１０に記載の駐停車地点管理装置であって、
    　前記駐停車地点検出部は、前記センシング情報に基づき、前記路駐地点に駐車している車両が第１レーンを塞いでいる横方向の長さを、はみ出し量として特定するように構成されており、
    　前記配信処理部は、前記はみ出し量を前記路駐地点の位置情報と対応付けて配信するように構成されている、駐停車地点管理装置。
12. 　請求項１に記載の駐停車地点管理装置であって、
    　前記駐停車地点検出部は、前記駐停車地点として渋滞の末尾を検出するものであって、
    　前記判断材料取得部が取得した前記車両挙動データまたは前記センシング情報に基づいて道路上において停車車両が存在する地点を検出し、
    　道路上に停車している車両と道路端との距離が所定距離以上であること、及び、停車している車両から進行方向側、所定距離以内に信号機が存在しないことの少なくとも何れか一方に基づいて、停車車両が存在する場所を渋滞の末尾に設定するように構成されており、
    　前記駐停車地点検出部によって検出されている渋滞の末尾の位置情報を車両に配信する配信処理部（Ｇ４）を備える、駐停車地点管理装置。
13. 　少なくともの１つのプロセッサを用いて実行される、路上において車両が駐停車している地点情報を管理するための方法であって、
    　少なくとも１つの車両の挙動を示す車両挙動データ、及び、前記車両に搭載されている周辺監視センサのセンシング情報の少なくとも何れか一方を位置情報と対応付けて取得する判断材料取得ステップ（Ｓ５０１）と、
    　前記判断材料取得ステップで取得した情報に基づいて、道路上に車両が駐停車している地点を検出する駐停車地点検出ステップ（Ｓ５０７）と、
    　前記駐停車地点検出ステップで検出された、車両が駐停車している地点である駐停車地点に、車両がまだ存在しているか否かを、前記判断材料取得ステップで取得した情報に基づいて判定する存続判定ステップ（Ｓ５０８）と、を含む駐停車地点管理方法。
14. 　道路上に車両が駐停車している地点である駐停車地点についての情報を所定のサーバ（２）に送信するための車両用装置であって、
    　自車両に搭載された周辺監視センサからの入力信号に基づき、道路上に停止している他車両である停止車両についての情報を取得する停止車両情報取得部（Ｆ４）と、
    　前記停止車両情報取得部が取得した前記停止車両についての情報に基づき、前記停止車両が路上に駐車された路駐車両に該当するのか、移動可能な状態を保持した一時停車車両に該当するのかを判断する駐車判定部（Ｆ５１）と、
    　前記駐車判定部が前記路駐車両に該当すると判定した前記停止車両が存在する場合に、前記サーバに、前記路駐車両が存在する地点を示すデータセットを送信する報告処理部（Ｆ５）と、を備える車両用装置。
15. 　請求項１４に記載の車両用装置であって、
    　前記停止車両情報取得部は、前記停止車両の自車両に対する相対位置を取得し、
    　地図上における自車両の位置を取得する自車位置取得部（Ｆ１）を備え、
    　前記駐車判定部は、
    　前記自車位置取得部が取得している自車両の位置と、前記停止車両情報取得部が取得している前記停止車両の相対位置に基づいて、当該停止車両の地図上の位置を特定することにより、道路端から前記停止車両までの距離を特定するとともに、
    　前記道路端からの距離が所定の駐車判定閾値以上である前記停止車両については前記路駐車両とは判定しないように構成されている車両用装置。
16. 　請求項１４又は１５に記載の車両用装置であって、
    　自車両の挙動として自車両が駐車されたことを検出する自車挙動取得部（Ｆ３）を備え、
    　前記報告処理部は、
    　前記周辺監視センサからの入力信号に基づいて、自車両が駐車された際の周辺環境を特定し、
    　自車両が道路端に沿うように駐車された場合には、自車両が駐車された位置を含むデータセットを前記サーバに送信するように構成されている車両用装置。
17. 　請求項１４から１６の何れか１項に記載の車両用装置であって、
    　前記停止車両情報取得部は、前記停止車両の位置及び向きを取得し、
    　前記駐車判定部は、複数の前記停止車両による列の中に、車体の向きが他の車両と反対向きの車両が混在している場合には、当該列を構成する前記停止車両は路駐車両であると判定する車両用装置。

Images