JP2020149610A - 遊休レーン走行管理サーバ装置、管理方法、プログラム及び車載装置 - Google Patents

Abstract

【課題】遊休レーンを有効に活用する。【解決手段】サーバ装置が受信部２１と処理部２２とを備え、前記受信部２１は、通信ネットワークを介して、遊休レーンのレーン状態／車両位置情報を受信し、前記受信部２１は、通信ネットワークを介して、車両１の自車両位置情報を受信し、前記受信部２１は、通信ネットワークを介して、前記車両１から遊休レーンの走行リクエストを受け付け、前記走行リクエストに応じて、前記処理部２２が、前記車両１の自車両位置情報と前記遊休レーンのレーン状態／車両位置情報とに基づいて、前記車両１が前記遊休レーンを走行できるか否かを判断する。【選択図】図２

Description

本開示は、遊休レーンの走行を管理するサーバ装置に関する。

また、本開示は、車両による遊休レーンの走行を管理する管理方法、走行管理プログラム、および車載端末にも関する。

特許文献１には、隘路において渋滞が発生しやすいことに鑑みて、車線変更時の交通を統制して隘路通過時の渋滞を緩和する渋滞緩和システム、地上システム及び渋滞予測制御装置を提供することが記載されている。

特許文献１に記載の渋滞緩和システムにおいては、地上システムは、所定部を通過する車両の識別情報を取得する第の識別情報取得手段と、所定部を通過した第１通過時刻を取得する第１の通過時刻取得手段と、隘路を通過した車両の識別情報を取得する第２の識別情報取得手段と、隘路を通過した第２通過時刻を取得する第２の通過時刻取得手段と、第１取得時刻に基づき前記隘路を通過する各車両の優先順位を決定する渋滞演算制御部と、優先順位を各車両に送信する送信装置と、を有し、渋滞予測制御装置は、優先順位を受信する受信装置と、優先順位を乗員に報知する報知装置と、を有する。

特開２００８−２６２４１８号公報

ところで、道路の渋滞は、一つの社会問題である。一般道路や高速道路等の、車両が走行できる道路の一部に車両が集中することにより、その車両の移動にかかる時間は増大し、混乱も生じる。よって、渋滞の解消が望まれている。

ここで、道路の使用率は１００％であるとは限らない。例えば、ある時間帯においては、ある道路の、ある走行車線（レーン）に車両が集中する。しかし、別のある時間帯には、走行可能なレーンが残っていることがある。また、状況にもよるが、同じ時間においても、走行可能なレーンが別に存在することもある。

道路はインフラであり、社会資本である。資本は、より使われた方が良い。そこで本開示においては、走行許可のない一般車両にとって、物理的には走行可能であるが、実際には未使用となっているレーンを「遊休レーン」と表現する。そして、遊休レーンをより活用することができれば、車両の乗員が渋滞を回避し得る。

本開示はかかる観点からなされたものであり、遊休レーンを有効に活用することを目的とする。

受信部と、処理部とを備えるサーバ装置において、前記受信部は、通信ネットワークを介して遊休レーンのレーン状態／車両位置情報を受信し、前記受信部は、通信ネットワークを介して車両の自車両位置情報を受信し、前記受信部は、通信ネットワークを介して前記車両から遊休レーンの走行リクエストを受け付け、前記走行リクエストに応じて、前記処理部が、前記車両の自車両位置情報と前記遊休レーンのレーン状態／車両位置情報とに基づいて、前記車両が前記遊休レーンを走行できるか否かを判断する。前記構成により、前記サーバ装置に接続された車両の乗員が、渋滞を回避することができる。また、遊休レーンは社会資本であるため、この社会資本が有効活用される。

本開示によれば、遊休レーンを有効に活用できる。

遊休レーン１０３を示す概念図 遊休レーン管理システムの一実施例を示すシステム構成図 出力部１１１が出力した、走行提案情報の一例を示す図 出力部１１１が乗員へ向けて出力した、走行許可／不許可情報の一例を示す図であり、（ａ）許可の場合、（ｂ）不許可の場合 車両１の乗員が遊休レーン１０３の走行を希望した場合の、車両１およびサーバ装置２の処理例を示すフロー図 出力部１１１による走行終了を示す情報の出力例を示す図 出力部１１１による課金情報の出力例を示す図

以下、車両はネットワーク接続された自動車（コネクテッドカー）であるという前提で、適宜図面を参照しながら詳細に説明する。かかる自動車は、自動運転のものであってもよい。なお、添付図面及び以下の説明は、当業者が本開示を十分に理解するために提供されるのであって、これらにより特許請求の範囲に記載の主題を限定することは意図されていない。

図１は、遊休レーン１０３を示す概念図である。図示しているように、車道１００には、複数のレーン１０１、１０２、１０３が存在し得る。車両Ｃ１〜Ｃ６が、通常レーン１０１、１０２をそれぞれ走行している。しかし、図示したように、車道１００では渋滞が発生している。

車両Ｃ１〜Ｃ６は、左あるいは右のウインカーを点滅させるなどして、適宜、レーンの変更を行うことができる。しかし、遊休レーン１０３は、何らかの理由により、車両が走行していない。

このような状況において、本開示の遊休レーン走行管理サーバ装置２は、遊休レーン１０３を例えば下記のように管理することができる。以下、遊休レーン走行管理サーバ装置２を、「サーバ装置２」と略記する。

図２は、本開示のサーバ装置２と、該サーバ装置２と接続された車両１と含む、遊休レーン管理システムの一実施例を示すシステム構成図である。

各情報処理の説明の前に、車両１とサーバ装置２が備える各機能ブロックについて説明する。なお、車両１内の機能ブロック構成およびサーバ装置２内の機能ブロック構成は、他の形態であってもよい。

まず、車両１について説明する。車両１は、図１に示した車両Ｃ１〜Ｃ６に相当する自動車である。車両１は、通信ネットワークを介してサーバ装置２と通信可能である。車両１は車載装置１１と車体１２とを有する。車体１２は、車両１の本体であり、一般的にはこの車体１２の中に、車載装置１１が設置される。車体１２が備える通知部１２１については後述する。

車載装置１１は、車両１に設けられた端末、あるいは端末群であり、出力部１１１、入力部１１２、送信部１１３、自車位置測定処理及び走行軌跡記録部１１４、受信部１１５を備える。なお、これら以外の機能ブロックを備えてもよい。また、複数の機能ブロックを、同じハードウェア資源によって実装してもよい。例えばＣＰＵやメモリ等を用いて、各機能を集約してもよい。逆に、複数の機能ブロックを、複数のハードウェア資源を相互接続させることで実装してもよい。車載装置１１は、例えば、車両１のフロントパネルに設けられたカーナビゲーションシステムと接続されたＥＣＵ等であってよい。

出力部１１１は、車両１に搭乗する乗員に対して、何らかの情報を出力する。視覚情報を出力してもよく、音声情報を出力してもよい。視覚情報、音声情報以外の情報を出力してもよい。出力部１１１は、典型的には、車両１のフロントパネルに備え付けられたモニタ機器等であってよい。車載装置１１は、上述のようにカーナビゲーションシステムと統合されていてよく、出力部１１１はカーナビゲーションシステムが備えるタッチパネル画面であってもよい。ただし、ハードウェア構成は、これらには限定されない。

入力部１１２は、車両１に搭乗する乗員からの何らかの情報入力を受け付ける。例えば上述のタッチパネル画面や、マイク入力等であってよいが、これらには限定されない。

なお、乗員が車両１を運転中の場合は、出力部１１１は音声を出力し、入力部１１２はマイク入力を受け付けるように構成してもよい。車両１が停止している場合は、出力部１１１は視覚情報を出力し、入力部１１２はタッチパネル操作を受け付けるように構成してもよい。

送信部１１３は、通信ネットワークＮ１を介して外部に情報を送信する。通信ネットワークＮ１は携帯電話ネットワークであってよい。ただし、これら以外の、ＩＰネットワーク等の通信ネットワークを排除する意図はない。送信部１１３から情報を送信する相手先は、典型的にはサーバ装置２であるが、車車間通信においては、車両１とは異なる車両が送信相手先であってもよい。送信部１１３は通信インタフェースを備えるか、またはこれと接続されていてよい。

自車位置測定処理及び走行軌跡記録部１１４は、車両１の位置情報を取得するセンサを含み、自車位置を特定し、その走行軌跡を記録する。ただし、当該センサの種類については特に限定はなく、例えば、ＧＰＳによって位置情報を取得してよい。それ以外の手段によって位置を取得してもよい。車両１の速度等の、他の情報を取得してもよい。

受信部１１５は、上述の通信ネットワークＮ１を介して、外部からの情報を受信する機能ブロックである。情報の送信元は、前記情報の送信先と同様に、サーバ装置２や、他の車両等であってよい。受信部１１５は通信インタフェースを備えるか、またはこれと接続されていてよい。

なお、図示は省略したが、車載装置１１は情報処理を行う装置であるので、処理部を備えていてよい。この処理部が、図２に示されている各機能ブロックを統括してよい。

次に、車両１の車体１２が備える通知部１２１について説明する。上述のように、車載装置１１が備える出力部１１１は、車両１に搭乗した乗員に向けて情報を出力するのに加え車体１２が備える通知部１２１への情報も出力する。車体１２が備える通知部１２１は、主に車両１に搭乗していない他者へ向けて、情報を通知する為のものである。例えば車両１が、図１に示した車両Ｃ５であった場合、通知部１２１は、他の車両Ｃ１〜Ｃ４、Ｃ６へ向けて、情報を通知するものである。

通知部１２１の通知形態は、典型的には、視覚情報の表示である。例えば、車体１２の外側に設けられたランプを点灯あるいは点滅させる、車体備えつけの電光掲示板に情報を表示させる、等の方法で、車両１の外部へ向けて情報を通知する。車体１２そのもの色を、本来の車体の色から別の色に変える、等の通知方法でもよい。スピーカによって音声として情報を通知してもよい。また、車車間通信が行える環境化であれば、車車間通信によって情報のみを通知してもよい。この通知情報を受信した他の車両は、例えばフロントパネルに備えられたモニタ等の手段によって、当該他の車両の乗員に通知を行うことができる。

次に、サーバ装置２側の構成例を説明する。本例において、サーバ装置２は、受信部２１と、処理部２２と、送信部２３を備えている。なお、他の構成要素を更に備えていてもよい。複数の機能ブロックを、同じハードウェア資源によって実装してもよい。複数の機能ブロックを、複数のハードウェア資源を相互接続させることで実装してもよい。

受信部２１は、通信ネットワークＮ１、Ｎ２等を介して、外部からの情報を受信する。情報の送信元は、車両１や、後述の監視サーバ装置３等であってよい。受信部２１は通信インタフェースを備えるか、またはこれと接続されていてよい。

なお、通信ネットワークＮ２は、上記の通信ネットワークＮ１と同様である。通信ネットワークＮ１と通信ネットワークＮ２は、同じネットワークであっても、互いに異なるネットワークであってもよい。また、通信ネットワークＮ２を介さずサーバ装置２内に監視サーバ装置３の機能を持つ構成であってもよい。

処理部２２は、受信部２１から受信した各種情報や、図示を省略する記憶部に格納されている情報等を用いて、判断（情報処理）を行う。後述の走行許可／不許可の判断以外の情報処理を、この処理部２２が行ってよい。この処理部２２は、サーバ装置２の情報処理を統括してよい。ハードウェア資源としては、ＣＰＵ等によって実装してよい。ただし構成はこれには限定されない。

送信部２３は、通信ネットワークＮ１を介して外部に情報を送信する機能ブロックである。ただし、他の通信ネットワークを介した情報送信を行ってもよい。送信部２３から情報を送信する相手先は、典型的には車両１であるが、これには限られない。送信部２３は通信インタフェースを備えるか、またはこれと接続されていてよい。

また、図示は省略するが、サーバ装置２は記憶部を備えていてよい。サーバ装置２が元から保持しておくべき情報や、サーバ装置２が外部から受信した各種情報をこの記憶部に格納しておき、必要に応じ当該情報を用いて、処理部２２が判断（情報処理）を行う。処理部２２の典型例はＣＰＵ等であるが、これには限定されない。また、サーバ装置２の記憶部は、サーバ装置２に後述の各処理を実行させる、走行管理プログラムを記憶していてよい。

一例として、サーバ装置２は、道路管理者が所有するデータセンタのサーバラックにマウントされた、上記のような機能を備えたブレード型サーバやタワー型サーバ等であって良いが、これには限定されない。

次に、監視サーバ装置３について説明する。監視サーバ装置３は、レーンの状態や、レーンを走行している車両位置等を示す各種情報を集約、統括しているサーバである。監視サーバ装置３は、図示されていない外部エンティティから、例えばレーンの混雑度を示す渋滞情報や、そのレーンを走行中の車両に関する情報（車両の現在位置、車種等）などを受信し、これを蓄積してよい。監視サーバ装置３は、レーン上を走行する緊急車両の情報等も、これを受信し蓄積してよい。また、監視サーバ装置３は、例えば倒木などの、車両の通行の妨げとなるオブジェクトが存在することを示す情報を、受信し蓄積してよい。監視サーバ装置３が受信、蓄積している上述のような情報を、本例では「レーン状態／車両位置情報」と表記する。

以上、図２に示したシステム構成を説明したが、上記のシステム構成は一例であり、これ以外のシステム構成を排除するという意図はない。

次に、上記のシステム構成に基づいた、遊休レーン１０３の管理に係る処理の一例を、引き続き図２に基づいて説明する。なお、便宜上、情報の種類ごとに（１）〜（５）の番号を振った。しかしながら、この番号の順番に情報を処理するとは限らない。

（１）レーン状態／車両位置情報
サーバ装置２は、前記監視サーバ装置３から、（１）レーン状態／車両位置情報を受信する。レーン状態／車両位置情報は、サーバ装置２の受信部２１を経由して処理部２２へと送られ、後述の走行許可／不許可の判断等に用いられる。なお、処理部２２が受け取った情報や、処理部２２がそれらの情報に基づいて生成した情報は、サーバ装置２の、図示を省略する記憶部等に記憶してよい。処理部２２は、この記憶された情報を適宜用いて、各情報処理を行ってよい。

サーバ装置２によるレーン状態／車両位置情報の受信は、一定時間毎に定常的に行われてよく、サーバ装置２から監視サーバ装置３への問合せによって随時受信してもよい。

（２）自車両位置情報
車両１の現在位置等は、車両１が備える自車位置測定処理及び走行軌跡記録部１１４によって取得可能である。上述のように、自車位置測定処理及び走行軌跡記録部１１４の典型例は、車載プローブである。自車位置測定処理及び走行軌跡記録部１１４が取得した自車両位置情報は通信ネットワークＮ１を介してサーバ装置２へと送信され、サーバ装置２の受信部２１がこれを受信する。なお、この情報送受信は定常的に行われてよく、サーバ装置２から車両１への問合せによって随時受信してもよい。

サーバ装置２の受信部２１が受信した自車両位置情報は処理部２２へと送られ、後述の走行許可／不許可の判断等に用いられる。なお、この情報はサーバ装置２の、図示を省略する記憶部等に記憶してよい。処理部２２は、この記憶された情報を適宜用いて、各情報処理を行ってよい。

なお、送信元となる車両の識別を可能とするため、自車両位置情報には、例えば車両ＩＤ情報等が含まれていてよい。

［処理部２２による、走行許可／不許可の判断］
サーバ装置２の処理部２２は、上述の（１）レーン状態／車両位置情報と、（２）自車両位置情報とに基づいて、車両１が遊休レーン１０３を走行可能か否か判断する。すなわち、走行許可／不許可の判断を行う。この走行許可／不許可の判断処理を発生させるトリガイベントは、（１）レーン状態／車両位置情報の受信や、（２）自車両位置情報の受信であってよい。

上述のように、監視サーバ装置３はレーン情報等を監視し、情報を蓄積している。したがって、現在どのレーンが渋滞しているかを示す情報が、（１）レーン状態／車両位置情報の中に含まれていてよい。すなわち、（１）レーン状態／車両位置情報を受信したサーバ装置２は、渋滞中のレーンを特定することができる。この渋滞中のレーン上を走行している車両について、処理部２２は走行許可／不許可の判断処理を開始することができる。

また、（２）自車両位置情報には、車両１が備えるプローブ等が取得した位置情報や、車両１の速度情報が含まれていてもよい。したがって、（２）自車両位置情報を受信部２１経由で取得した処理部２２は、車両１の位置や速度に基づいて、車両１が渋滞の中に居るか否かを判断することができる。具体例を挙げると、車両１のプローブデータから、時速５ｋｍ以下の走行が５分以上続いていた場合は、車両１が渋滞の中に居ると判断することができる。このような場合に、処理部２２は、車両１について走行許可／不許可の判断処理を開始することができる。

その他、例えば、車両１の乗員が目視で渋滞の発生を確認してもよい。具体例をあげると、図示を省略する渋滞通知ボタンを車載装置１１が備えている。渋滞を目視確認した車両１の乗員が、この渋滞通知ボタンを押すことで、通知がサーバ装置２へと送信される。この通知の受信をトリガイベントとして、処理部２２が走行許可／不許可の判断処理を開始することができる。

サーバ装置２の処理部２２による判断アルゴリズムは種々想定し得るが、例えば、（２）自車両位置情報から車両１の現在位置を特定し、この現在位置の近くに存在するレーンが、車両１が走行可能な遊休レーン１０３であるか否かを、（１）レーン状態／車両位置情報に基づいて判断してよい。

ここで、監視サーバ装置３から受信する（１）レーン状態／車両位置情報には、例えば以下のような情報Ａ〜Ｃが含まれていてもよい。
（情報Ａ）あるレーンに存在する、車両の通行の妨げとなるオブジェクトの情報。
（情報Ｂ）あるレーン上の、緊急車両等の走行情報。
（情報Ｃ）あるレーンを走行可能な車両タイプを示す情報。

前記情報Ａにつき、車両の通行の妨げとなるオブジェクトとは、例えば倒木などの障害物や、退避車両などである。退避車両とは、車両故障や事故、乗員の体調不良等によって、遊休レーンへの退避を余儀なくされている車両のことである。このような障害物や退避車両が遊休レーン上に存在する場合は、この遊休レーンが当該オブジェクトで塞がれているのであるから、車両１は当該遊休レーンを走行することはできない。したがって処理部２２は、受信した（１）レーン状態／車両位置情報に前記情報Ａが含まれていた場合、車両１に対して、走行は不許可であると判断する。

前記情報Ｂにつき、救急車などの緊急車両が、遊休レーンを走行することがあり得る。ここで上述のように、緊急車両の走行情報が、（１）レーン状態／車両位置情報に含まれていてよい。処理部２２は、受信した（１）レーン状態／車両位置情報に前記情報Ｂが含まれていた場合、車両１に対して、走行は不許可であると判断する。

なお、緊急車両の通行を優先させるために、サーバ装置２は、既に走行許可済の車両１に対して、走行不許可を示す後述の（５）走行不許可情報を送信してもよい。

前記情報Ｃにつき、遊休レーンは、車両が通行するには幅が狭い場合もあり得る。したがって、その遊休レーンを走行可能な車両のタイプ（大型、中型、小型、環境規制対応車等）を示す情報Ｃが、（１）レーン状態／車両位置情報に含まれていてよい。したがって処理部２２は、受信した（１）レーン状態／車両位置情報に前記情報Ｃが含まれていた場合、車両１が情報Ｃによって示された車両タイプに属するか否かを判断し、属しない場合は、車両１に対して、走行は不許可であると判断する。

なお、車両１のタイプを示す情報は、（２）自車両位置情報の中の、車両ＩＤ情報等から特定してもよい。ただしこのタイプ特定方法には限定しない。

（３）走行提案情報
例えば上述のような走行許可／不許可の情報処理である判断を、処理部２２は行う。そして、車両１が遊休レーン１０３を走行可能であると判断した場合、サーバ装置２は、（３）走行提案情報を、送信部２３から車両１へと送信する。

この走行提案情報には、車両１のＩＤ、走行可能な遊休レーン１０３のレーンＩＤ、走行可能な距離／走行時間、走行に必要な料金や課金方式（課金が発生する場合）等の、種々の情報が含まれていてよい。なお、例示した情報以外の情報を、走行提案情報が含んでいてよい。

車両１の受信部１１５が、（３）走行提案情報を受信すると、この情報は出力部１１１によって、乗員へ向けて出力される。この出力の際に、適宜フォーマットや表示形式の変換が行われてよい。

ここで、図３を参照する。図３は、車両１が受信した走行提案情報に基づき、出力部１１１が乗員へ向けて出力した、走行提案情報の一例を示す図である。

図３に示した例においては、入力部１１２を兼ねる出力部１１１として、カーナビゲーションシステムのタッチパネル画面を用いている。経路情報Ａ１に重畳して、メッセージボックスＡ２が出力（表示）される。メッセージボックスＡ２の中には、「遊休レーンを走行しますか？」の文字メッセージと共に、「はい」「いいえ」の２つのボタンが左右に並んで表示されている。また、画面右上には、遊休レーン１０３を走行する場合に必要な料金を示す料金表示部Ａ３が表示されている（課金を行う場合）。Ａ４は遊休レーン１０３であり、ハイライト表示され、また進路を示す矢印が表示されている。なお、このユーザインタフェースは一例であり、これ以外の形態で走行提案情報を出力してもよい。例えば、音声出力によって乗員に走行提案を行ってもよい。

（４）走行リクエスト情報
図２および図３を併せて参照する。車両１の乗員が、上記の「はい」ボタンをタップする。すると、乗員による走行の希望が、入力部１１２（本例では、タッチパネル画面）に入力されたことになる。すると車載装置１１は、走行リクエスト情報を、送信部１１３経由でサーバ装置２へと送信する。この走行リクエスト情報には、例えば、車両１の車両ＩＤ、走行したい遊休レーン１０３のレーンＩＤ、走行リクエスト情報の生成時刻情報等が含まれてよい。車両１の車種等の、車両１に係る属性情報を当該走行リクエスト情報に含めてもよい。走行リクエスト情報に、（２）自車両位置情報を含めて、一括送信してもよい。また、これら以外の情報を、走行リクエスト情報が含んでいてもよい。

走行リクエスト情報は、サーバ装置２の受信部２１経由で、処理部２２へと到達する。処理部２２は、この走行リクエスト情報に基づき、車両１による遊休レーン１０３の走行を許可するか否かを再び判断する。

（５）走行許可／不許可情報
処理部２２は、入手した（１）レーン状態／車両位置情報、（２）自車両位置情報、（４）走行リクエスト情報等に基づいて、車両１による遊休レーン１０３の走行を許可するか否かを判断する。この判断は、上述の（３）走行提案情報について既に説明したのとほぼ同様であるが、以下のような相違点もある。

処理部２２が（３）走行提案情報を車両１へ向けて送信した時間と、（４）走行リクエスト情報を受信した時間との間には、時間差がある。実際、車両１の乗員が出力部１１１による出力を受け、上述の「はい」ボタンをタップするまでの間に、外界の状況は変化していることもあり得る。例えば、車両１が前方へと走行したことで、車両１の位置が変わっていることがある。また、車両１と同様に遊休レーン１０３上の走行を始めようとする車両の数が一定の閾値を越えたり、緊急車両が遊休レーン１０３上の走行を始めたり、新たに倒木が発生して遊休レーン１０３自体が塞がれる、などの事態も発生し得る。

そこでサーバ装置２の処理部２２は、（３）走行提案情報を送信した時からさらに更新された、現時点で入手できる情報（１）（２）（４）等に基づいて、走行許可／不許可の判断を行ってよい。

続いてサーバ装置２は、上記走行許可／不許可の判断処理による判断結果に基づいて、走行許可、あるいは走行不許可を示す（５）走行許可／不許可情報を、送信部２３経由で車両１へと送信する。

走行許可／不許可情報を受信部１１５にて受信した車両１の車載装置１１は、２種類の出力を行うことができる。第１に、車両１の乗員への出力であり、第２に、車両１の乗員以外の者への通知である。以下、この２種類の出力について説明する。

まず、車両１の乗員への出力について説明する。受信部１１５から出力部１１１へと、走行許可／不許可情報が送られ、出力部１１１によって、この情報が乗員へ向けて出力される。この情報出力の際に、適宜フォーマットや表示形式の変換が行われてよい。なお、出力形式が視覚情報には限られず、例えば音声情報等も含み得ることは、上記の（３）走行提案出力と同様である。

ここで、図４を参照する。図４は、車両１が受信した走行許可／不許可情報に基づき、出力部１１１が乗員へ向けて出力した、走行許可／不許可情報の一例を示す図である。

図４に示した例においても、出力部１１１および入力部１１２として、カーナビゲーションシステムのタッチパネル画面を用いている。図４（ａ）が許可の場合、図４（ｂ）が不許可の場合である。

図４（ａ）に示した許可の場合、経路情報Ａ１に重畳して、メッセージボックスＡ２が表示される。メッセージボックスＡ２の中には、「車線変更してください」の文字メッセージが表示される。画面右上の料金表示部Ａ３には、遊休レーン１０３を走行するのに必要な料金が表示される（課金を行う場合）。例えば料金体系が走行１ｋｍごとに１００円の従量課金である場合、遊休レーン１０３の累積走行距離（図４（ａ）の時点では０ｋｍ）と、現時点での累積料金（図４（ａ）の時点では０円）を並列表記してよい。Ａ４に示した遊休レーン１０３は、点滅表示されている。さらに、車両１が今居るレーンから、右隣の遊休レーン１０３へと車線変更すべき旨を示す矢印Ａ５が重畳表示されている。なお、このユーザインタフェースは一例であり、これ以外の形態で走行許可情報を出力してもよい。例えば「右レーンをお進みください。料金は、・・円です」等の音声ナレーションによって走行許可情報を出力してもよい。車両１が自動運転の車両であった場合は、メッセージボックスＡ２の中には、「遊休レーンを走行します。右レーンに車線変更します」の文字メッセージが表示されてもよい。

図４（ｂ）に示した不許可の場合、経路情報Ａ１に重畳したメッセージボックスＡ２の中には「遊休レーンを走行できません」の文字メッセージが表示される。画面右上の料金表示部Ａ３には、何も表示されない。Ａ４が示す遊休レーン１０３は、ハイライト表示も点滅表示もされず、走行不許可を示すグレー色で表示される。矢印Ａ５は表示されない。なお、このユーザインタフェースは一例であり、これ以外の形態で走行不許可情報を出力してもよい。例えば、「遊休レーンを走行できません」との音声ナレーションによって走行不許可情報を出力してもよい。

以上、走行許可／不許可情報を受信部１１５にて受信した車載装置１１が、出力部１１１によって、車両１の乗員への情報出力を行う事について説明した。次に、車両１の乗員以外の者への通知について説明する。

図２に示すように、出力部１１１から車体１２の通知部１２１へと、走行許可情報が送信される。この許可情報を受信した、車体１２の通知部１２１は、車両１の外に居る、車両１に搭乗していない者への通知を行う。既に説明したように、例えば車体１２の外側に設けられた走行許可ランプや電光掲示板などによって、車両１の外部へ向けて情報を通知する。この通知がある事で、車両１に搭乗していない他者は、車両１が許可を得た上で遊休レーン１０３を走行している、という事実を認識することができる。

図５は、車両１の乗員が遊休レーン１０３の走行を希望した場合（上記（４）走行リクエスト情報、参照）の、車両１およびサーバ装置２の処理例を示すフロー図である。

図５に示すフロー図が、図２に示した例と違うのは、車両１に対する課金計算処理が、当該フロー図の中に組み込まれていることである。以下、図２も併せて参照しつつ、図５に示した処理フローについて説明する。

ステップＳ０１において、車両１の走行の希望（リクエスト）が、車載装置１１の入力部１１２に入力される。すると、ステップＳ０２において送信部１１３が、（４）走行リクエスト情報、（２）自車両位置情報に加えて、個人決済情報を、サーバ装置２へと送信する。この個人決済情報は、例えばクレジットカード番号、ＥＴＣカードＩＤ、ＥＴＣ車載器ＩＤや、携帯電話のキャリア決済に係る認証情報、または、既存のＷＥＢ決済サービスのアカウント情報等であってよいが、これらには限定されない。

ステップＳ０３において、上述の情報をサーバ装置２の受信部２１が受信する。続くステップＳ０４において、処理部２２が、監視サーバ装置３からの情報に基づき、レーン状態／車両位置を確認する。

続くステップＳ０５において、処理部２２が、車両１が遊休レーン１０３を走行可能であるか否かの判断を行う。この判断は、図１〜図４に基づいて上述したものと同様であってよい。ただし、ステップＳ０５においては、サーバ装置２は個人決済情報も入手している。そこで、この個人決済情報も加味して、許可／不許可判断を行ってもよい。例えば、個人決済情報がクレジットカード番号であった場合、このクレジットカード番号が有効なものであるか否かを外部システムへと問い合せてもよい。クレジットカード番号が有効なものではなかった場合、処理部２２は遊休レーン走行を不許可と判断してよい。ただし、処理部２２による判断の態様は、これらには限定されない。

上記ステップＳ０５において、処理部２２が走行許可と判断した場合の、後続のステップＳ０６〜Ｓ１５について、下記で説明する。その後に、処理部２２が走行不許可と判断した場合の、後続のステップＳ１６〜Ｓ１８について説明する。

ステップＳ０６において、サーバ装置２の送信部２３が、（５）走行許可情報を送信する。ステップＳ０７において、車両１の受信部１１５が、この走行許可情報を受信する。ステップＳ０８において、出力部１１１が、走行許可情報の出力を車両１の乗員に対して行う（図４（ａ）参照）。

また、ステップＳ０９において、車体１２の通知部１２１が、車両１の外に居る、車両１に搭乗していない者に対して通知を行う。例えば、車体１２の外側に設けられた走行許可ランプを点灯する。

走行許可が得られた車両１は、車線変更を行い、遊休レーン１０３上を走行する。遊休レーン１０３上の走行が終わった車両１は、再び車線変更を行い、通常レーン１０１または１０２に戻る（図１参照）。この時、車両１内に設けられたプローブのデータ等から、遊休レーン１０３上のどのくらいの距離を走行したかが分かる。

ステップＳ１０で、出力部１１１は走行終了を示す情報を出力する。図６はその出力例を示す図である。経路情報Ａ１に重畳して表示されたメッセージボックスＡ２の中には、「お疲れ様でした 一般レーンをお進みください」との文字メッセージが表示される。画面右上の料金表示部Ａ３には、遊休レーン１０３を走行した結果支払うべき料金が表示されている。ただし本例において、この料金は、この時点ではまだ未決済であるので、暫定的な額の表示である。Ａ４が示す遊休レーン１０３は、点滅やハイライト表示やグレー表示のない、通常表示へと戻る。なお、このユーザインタフェースは一例であり、これ以外の出力形態であってもよい。例えば、「お疲れ様でした。一般レーンをお進みください」等の音声ナレーションによって走行終了を出力してもよい。

ステップＳ１１で、送信部１１３は、遊休レーン１０３の走行結果を示す、走行結果情報をサーバ装置２へと送信する。走行結果情報には、上述の個人決済情報や、遊休レーン１０３を走行した走行距離などの情報が含まれる。また、走行結果情報には、車両１のＩＤや、自車両位置情報等が含まれてよい。

ステップＳ１２で、サーバ装置２の受信部２１は、前記走行結果情報を受信し、ステップＳ１３で、処理部２２による制御の下で、課金計算処理を行う。この課金計算処理は、どのような課金方式を採用するかによる。

例えばＥＴＣ車載器ＩＤを利用する場合、ステップＳ０２やステップＳ１１において送信部１１３が、車両１が備えたＥＴＣ車載器（図示省略）の機器番号を、個人決済情報として、サーバ装置２へと送信してよい。サーバ装置２は、処理部２２の制御の下、前記機器番号を利用者番号へと変換し、この利用者番号を利用して、課金計算処理を行ってよい。ただし前記はあくまで一例にすぎず、これ以外の課金計算処理を行ってもよい。

課金計算処理が終わったら、ステップＳ１４で、送信部２３が課金情報を車両１へと送信する。この課金情報には、例えば上述の個人決済情報や、決済によって確定した料金の額などが含まれてよい。プリペイド式の課金方式を採用した場合は、料金支払い後の残高の額などが含まれていてよい。ただし、例示したこれらの態様には限定されず、課金方式に応じて、適切な情報が課金情報に含まれていればよい。

ステップＳ１５で、車両１の受信部１１５が、この課金情報を受信する。そして、出力部１１１を介して、乗員に課金情報を出力する。図７は、課金情報の出力例を示す図である。経路情報Ａ１、メッセージボックスＡ２、およびＡ４が示す遊休レーン１０３については、図６と同様である。画面右上の料金表示部Ａ３に、確定後の料金がハイライト表示される。プリペイド式の課金方式である場合は、料金支払い後の残高の額が合わせて表示されてよい。このユーザインタフェースは一例であり、これ以外の形態で課金情報の出力を行ってもよい。例えば、「料金は、○○円です。一般レーンをお進みください」等の音声ナレーションによって課金情報の出力を行ってもよい。

次に、上述のステップＳ０５において、処理部２２が走行不許可と判断した場合の、後続のステップＳ１６〜Ｓ１８について説明する。ステップＳ１６において、サーバ装置２の送信部２３が、（５）走行不許可情報を車両１に対して送信する。ステップＳ１７において、車両１の受信部１１５が、この走行不許可情報を受信する。ステップＳ１８において、出力部１１１が、車両１の乗員に対して、走行不許可情報を出力する（図４（ｂ）参照）。

次に、課金方式についての変形例を説明する。

既に説明した例においては、課金方式として、遊休レーン１０３を走行した距離に応じる従量課金を例示した。しかし、課金方式はこれには限られない。例えば、ダイナミックプライシング方式であってよい。このダイナミックプライシングは、需給状況に応じて価格を変動させることによって、需要の調整を図る方式である。遊休レーンは社会資本（インフラ）であるから、そのインフラの需給バランスを何らかの方法により調整する事は重要である。一例として、本開示においては、そのバランス調整を、動的な料金変動によって実施する。

本開示におけるダイナミックプライシング課金は、例えば走行許可に係る遊休レーン１０３について受信した（４）走行リクエストの受信数、および／または、受信部２１が受信した（１）レーン状態／車両位置情報に含まれる、当該遊休レーンの混雑度に応じて行ってよい。

図２に基づいて上述したように、監視サーバ装置３からサーバ装置２が受信する（１）レーン状態／車両位置情報には、レーンがどの程度渋滞しているかを示す渋滞情報や、そのレーンを走行中の車両に関する情報（車両の現在位置、車種等）などが含まれている。そのため、サーバ装置２は、遊休レーンの混雑度を認識することができる。

また上述のように、車両１からサーバ装置２が受信する（２）自車両位置情報、（４）走行リクエスト情報等によって、車両１が走行したい遊休レーンも特定することができる。

したがってサーバ装置２は、走行リクエストの対象となる遊休レーンが、今現在どの程度渋滞しているのかを認識することができる。また、サーバ装置２は、その遊休レーンに、どの程度の数の走行リクエストが集中しているかも認識することができる。よってサーバ装置２は、これらの情報に基づいて、ダイナミックプライシング課金を行うことができる。例えば、遊休レーンが混雑している場合には料金を増額する、その遊休レーンに対する走行リクエストが集中している場合には料金を増額する、等の料金決定を、処理部２２が情報処理として行い得る。

なお、処理部２２が決定した増額後の料金を示す情報は、（３）走行提案情報の中に含まれていてよい。

また、別の課金方式として、走行リクエスト情報をサーバ装置２へと送信した車両１の、車種等の情報に基づいて、処理部２２が課金額を決定してもよい。例えば、小型車や環境規制対応車については料金を減額する、等である。

なお、課金方式としては、料金定額の固定料金制もあり得る。固定料金制の場合は、車両１による遊休レーンの走行距離が確定するのを待つ必要はない。そのため、サーバ装置２は、図５に示したフロー図におけるステップＳ０６の際等に、前記課金計算処理を行ってもよい。

以上のように、サーバ装置２による管理によって、車両１が遊休レーン１０３を走行できるようになる。その際に生じる利点は、以下のように多岐にわたる。第１に、渋滞を柔軟に緩和あるいは解消することができる。第２に、料金を払ってでも渋滞を避けたい乗員のニーズに応えることができる。第３に、サーバ装置２の管理者が、新たな収入源を持つことができる。また、第４に、レーンは社会資本（インフラ）であるから、この遊休社会資本をより有効活用できる。

上記構成において、サーバ装置は送信部をさらに備え、前記送信部は、前記遊休レーンの走行可否を示す走行許可／不許可情報を、前記車両に対して送信してよい。前記構成により、車両は、遊休レーンの走行可否を把握することができる。

上記構成において、前記送信部が走行許可情報を送信した送信先である車両が、当該許可に係る前記遊休レーンを走行した場合に、前記処理部が、当該車両についての課金計算処理を行ってよい。前記構成により、遊休レーンの走行にかかる料金を管理することができる。

上記構成において、前記課金計算処理において行われる課金は、前記車両の、前記走行許可に係る前記遊休レーンの走行距離に応じた従量課金であってよい。また、前記課金計算処理において行われる課金は、前記走行許可に係る前記遊休レーンについて前記受信部が受信した前記走行リクエストの受信数、および／または、前記受信部が受信した遊休レーンのレーン状態／車両位置情報に含まれる、当該遊休レーンの混雑度に応じた、ダイナミックプライシング課金であってよい。前記構成により、遊休レーンの走行にかかる料金を、車両の走行距離やインフラ情報等に基づいて柔軟に調整することができる。

上記構成において、前記受信部が受信した遊休レーンのレーン状態／車両位置情報の中に、前記走行リクエストに係る遊休レーン上に緊急車両が居ることを示す情報が含まれていた場合、前記処理部が、前記車両による前記遊休レーンの走行を不許可と判断してよい。前記構成により、遊休レーンを走行しようとする車両が、優先度の高い緊急車両の走行を妨害するという事態を回避することができる。

上記構成において、前記受信部が受信した遊休レーンのレーン状態／車両位置情報の中に、前記走行リクエストに係る遊休レーン上に、車両の通行の妨げとなるオブジェクトが存在することを示す情報が含まれていた場合、前記処理部が、前記車両による前記遊休レーンの走行を不許可と判断してよい。前記構成により、車両の安全な通行が可能である場合にのみ、遊休レーンの走行を許可することができる。そのため、車両は遊休レーンを安全に走行することができる。

また、受信部と、処理部とを備えるサーバ装置における、車両による遊休レーンの走行を管理する走行管理方法が、前記受信部が、通信ネットワークを介して、遊休レーンのレーン状態／車両位置情報を受信するステップと、前記受信部が、通信ネットワークを介して、車両の自車両位置情報を受信するステップと、前記受信部が、通信ネットワークを介して、前記車両から遊休レーンの走行リクエストを受け付けるステップと、前記走行リクエストに応じて、前記処理部が、前記車両の自車両位置情報と前記遊休レーンのレーン状態／車両位置情報とに基づいて、前記車両が前記遊休レーンを走行できるか否かを判断するステップと、を有していてよい。前記構成により、車両による遊休レーンの走行を管理することができる。

また、車両による遊休レーンの走行を管理する走行管理プログラムが、受信部と、処理部とを備えるサーバ装置に、前記受信部が、通信ネットワークを介して、遊休レーンのレーン状態／車両位置情報を受信するステップと、前記受信部が、通信ネットワークを介して、車両の自車両位置情報を受信するステップと、前記受信部が、通信ネットワークを介して、前記車両から遊休レーンの走行リクエストを受け付けるステップと、前記走行リクエストに応じて、前記処理部が、前記車両の自車両位置情報と前記遊休レーンのレーン状態／車両位置情報とに基づいて、前記車両が前記遊休レーンを走行できるか否かを判断するステップと、を実行させてよい。前記構成により、前記サーバが、車両による遊休レーンの走行を管理できるようになる。

また、車両に搭載される車載装置が、受信部と、出力部とを備え、前記受信部が、通信ネットワークを介して、遊休レーンの走行提案情報を受信した場合、前記出力部が、前記車両の乗員に対して、前記遊休レーンの走行提案情報を出力してよい。前記構成により、車両の乗員が、遊休レーンの走行提案を受けることができる。

上記構成において、前記受信部が、通信ネットワークを介して、前記遊休レーンの走行許可／不許可情報を受信した場合、前記出力部が、前記車両の乗員に対して、前記遊休レーンの走行許可／不許可情報を出力してよい。前記構成により、車両の乗員が、遊休レーンの走行の許可／不許可を適切に把握することができる。

上記構成において、前記受信部が、通信ネットワークを介して、前記遊休レーンの走行許可情報を受信した場合、前記出力部が、前記車両が備える通知部に、前記遊休レーンの走行許可情報を出力してよい。前記構成により、当該車載装置を搭載した車両が、遊休レーンの走行許可を得ていることを、外部に対して通知することができる。

以上、図面を参照しながら各種の実施形態について説明したが、本開示はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本開示の技術的範囲に属するものと了解される。また、開示の趣旨を逸脱しない範囲において、上記実施形態における各構成要素を任意に組み合わせてもよい。

本開示は、遊休レーンを利用可能化するシステムに適用が可能である。なお、上記で例示した車両１は、通信ネットワークを介してサーバ装置２等と通信可能なものであった。そのような常時コネクテッドな移動体が社会により普及し、かつ、車両のプローブデータ等に基づいて、その走行軌跡をレーン管理者がリアルタイムに把握できるようになった条件下であれば、遊休社会資本であるレーンをより一層、有効活用できるようになる。例えば、一般車両について未使用となっているレーン（一般道の専用通行帯や高速道路の路側帯等も含まれ得る）も、前記条件を満たしているのであれば、一時的に走行可能な遊休レーンと解釈することも、将来的には可能であるかもしれない。ただし、交通の安全や、法令の遵守等が優先されることは自明である。

１ 車両
２ サーバ装置
３ 監視サーバ装置
１１ 車載装置
１２ 車体
２１ 受信部
２２ 処理部
２３ 送信部
１００ 車道
１０１ 通常レーン
１０２ 通常レーン
１０３ 遊休レーン
１１１ 出力部
１１２ 入力部
１１３ 送信部
１１４ 自車位置測定処理及び走行軌跡記録部
１１５ 受信部
１２１ 通知部
Ａ１ 経路情報
Ａ２ メッセージボックス
Ａ３ 料金表示部
Ａ４ 遊休レーン表示
Ａ５ 矢印
Ｃ１〜Ｃ６ 車両
Ｎ１ 通信ネットワーク
Ｎ２ 通信ネットワーク

Claims (12)

1. サーバ装置であって、
   受信部と、処理部とを備え、
   前記受信部は、通信ネットワークを介して、遊休レーンのレーン状態／車両位置情報を受信し、
   前記受信部は、通信ネットワークを介して、車両の自車両位置情報を受信し、
   前記受信部は、通信ネットワークを介して、前記車両から遊休レーンの走行リクエストを受け付け、
   前記走行リクエストに応じて、前記処理部が、前記車両の自車両位置情報と前記遊休レーンのレーン状態／車両位置情報とに基づいて、前記車両が前記遊休レーンを走行できるか否かを判断する、
   サーバ装置。
2. 請求項１に記載のサーバ装置であって、
   送信部をさらに備え、
   前記送信部は、前記遊休レーンの走行可否を示す走行許可／不許可情報を、前記車両に対して送信する、
   サーバ装置。
3. 請求項２に記載のサーバ装置であって、
   前記送信部が走行許可情報を送信した送信先である車両が、当該許可に係る前記遊休レーンを走行した場合に、前記処理部が、当該車両についての課金計算処理を行う、
   サーバ装置。
4. 請求項３に記載のサーバ装置であって、
   前記課金計算処理において行われる課金は、前記車両の、前記走行許可に係る前記遊休レーンの走行距離に応じた従量課金である、
   サーバ装置。
5. 請求項３に記載のサーバ装置であって、
   前記課金計算処理において行われる課金は、前記走行許可に係る前記遊休レーンについて前記受信部が受信した前記走行リクエストの受信数、および／または、前記受信部が受信した遊休レーンのレーン状態／車両位置情報に含まれる、当該遊休レーンの混雑度に応じた、ダイナミックプライシング課金である、
   サーバ装置。
6. 請求項１から請求項５のいずれか１項に記載のサーバ装置であって、
   前記受信部が受信した遊休レーンのレーン状態／車両位置情報の中に、前記走行リクエストに係る遊休レーン上に緊急車両が居ることを示す情報が含まれていた場合、前記処理部が、前記車両による前記遊休レーンの走行を不許可と判断する、
   サーバ装置。
7. 請求項１から請求項６のいずれか１項に記載のサーバ装置であって、
   前記受信部が受信した遊休レーンのレーン状態／車両位置情報の中に、前記走行リクエストに係る遊休レーン上に、車両の通行の妨げとなるオブジェクトが存在することを示す情報が含まれていた場合、前記処理部が、前記車両による前記遊休レーンの走行を不許可と判断する、
   サーバ装置。
8. サーバ装置における、車両による遊休レーンの走行を管理する走行管理方法であって、
   前記サーバ装置は受信部と、処理部とを備えており、
   前記走行管理方法が、
   前記受信部が、通信ネットワークを介して、遊休レーンのレーン状態／車両位置情報を受信するステップと、
   前記受信部が、通信ネットワークを介して、車両の自車両位置情報を受信するステップと、
   前記受信部が、通信ネットワークを介して、前記車両から遊休レーンの走行リクエストを受け付けるステップと、
   前記走行リクエストに応じて、前記処理部が、前記車両の自車両位置情報と前記遊休レーンのレーン状態／車両位置情報とに基づいて、前記車両が前記遊休レーンを走行できるか否かを判断するステップと、
   を有する、
   走行管理方法。
9. 車両による遊休レーンの走行を管理する走行管理プログラムであって、
   受信部と、処理部とを備えるサーバ装置に、
   前記受信部が、通信ネットワークを介して、遊休レーンのレーン状態／車両位置情報を受信するステップと、
   前記受信部が、通信ネットワークを介して、車両の自車両位置情報を受信するステップと、
   前記受信部が、通信ネットワークを介して、前記車両から遊休レーンの走行リクエストを受け付けるステップと、
   前記走行リクエストに応じて、前記処理部が、前記車両の自車両位置情報と前記遊休レーンのレーン状態／車両位置情報とに基づいて、前記車両が前記遊休レーンを走行できるか否かを判断するステップと、
   を実行させる、
   走行管理プログラム。
10. 車両に搭載される車載装置であって、
    受信部と、出力部とを備え、
    前記受信部が、通信ネットワークを介して、遊休レーンの走行提案情報を受信した場合、
    前記出力部が、前記車両の乗員に対して、前記遊休レーンの走行提案情報を出力する、
    車載装置。
11. 請求項１０に記載の車載装置であって、
    前記受信部が、通信ネットワークを介して、前記遊休レーンの走行許可／不許可情報を受信した場合、
    前記出力部が、前記車両の乗員に対して、前記遊休レーンの走行許可／不許可情報を出力する、
    車載装置。
12. 請求項１１に記載の車載装置であって、
    前記受信部が、通信ネットワークを介して、前記遊休レーンの走行許可情報を受信した場合、
    前記出力部が、前記車両が備える通知部に、前記遊休レーンの走行許可情報を出力する、
    車載装置。

Images