JP3100052U

JP3100052U - バス情報配信サービス装置

Info

Publication number: JP3100052U
Application number: JP2003270769U
Authority: JP
Inventors: 福井　泰代
Original assignee: 株式会社ナビット
Priority date: 2003-08-26
Filing date: 2003-08-26
Publication date: 2004-04-30
Anticipated expiration: 2009-08-26

Abstract

【課題】大がかりな設備投資がなくても、バスが目的地に到着する予定時間を計算できる手段を開発し、利用者に到着予想時間として配信サービスする装置を提供する。
【解決手段】固定区間を運行しているバスで目的地までの予想時間を計算して利用者の端末にデータ送信する装置において、(1)バスの過去の運行時間を路線ごとに情報として収集し、路線、季節、天候、時間帯、交通渋滞情報等をパラメータに該情報分析して運行パターンを作成してデータベース化する機構、(2)運行パターン、リアルタイムの渋滞情報、バスネットワークデータ路線情報および地図情報とから、問い合わせのあったバス停から目的地のバス停までの所要時間あるいは予想到着時間を計算して利用者の端末に配信サービスする機構、を備えたバスの目的地到着予想時間情報配信サービス装置とする。
【選択図】図１

Description

　本考案は、過去のバスの運行パターンとリアルタイムに収集した交通渋滞状態情報とから、現在運行中のバスの目的地までの到着予想時間を割り出して利用者に配信サービスする装置に関する。　

　ナビゲーションシステムは様々な場所で活躍している。例えば最もポピュラーなものとして普及しているのが自動車のナビゲーション、すなわちカーナビである。カーナビはＧＰＳや基地局を利用して車の位置を特定し、出発地から目的地までの道順を最適なルートでリアルタイムに案内するものである。出発地や目的地の入力は、ディスプレイを見ながらキー操作あるいはタッチパネル操作で行えるようになっている。また最近は、音声によってデータ入力する方式も考えられている。

　鉄道のナビゲーションシステムでは運行時間が安定しているために、目的地までの所要時間は厳密に算出できる（到着時間は所要時間から算出可）。これに対してカーナビによる目的地までの所要時間は交通渋滞という障害が存在するために、リアルタイムの渋滞情報を加味しなければならない。このため、現在のカーナビは交通渋滞情報も加味して、最適な経路の探索と所要時間の割り出しを行っている。

　バスに関するナビゲーションシステムも数多く、公開特許で提唱されている。バスの場合、鉄道ナビとカーナビの中間的な存在であるために、時刻表と渋滞情報の両方が加味されたシステムになっている。例えば、『固定経路移動体管理システムおよび固定経路移動体管理方法』（特許文献１）では、ＧＰＳと固定局および移動体の時刻表とから移動体の位置を測定し、移動体の通過位置を利用者の端末に配信する手段を提唱している。またリアルタイムに入手した交通渋滞情報も配信できるように工夫されている。『移動体運行状況取得システム、移動体運行状況取得方法、および、記録媒体』（特許文献２）では、前記の発明の機能をさらに拡大し、移動体の時刻表と現在位置とから目的地までの所要時間を算出し、利用者の端末に配信サービスするシステムについて触れられている。

　渋滞情報を扱ったものとしては、『渋滞情報提供センタ及び方法』（特許文献３）がある。ここでは、各停留所間のバスの走行所要時間を算出し、算出した走行所要時間に基づいて、渋滞の発生している渋滞区間を判別し、渋滞区間のレベルを設定している。『バス運行情報表示システム』（特許文献４）では、ＰＨＳやパケット無線電話システムを利用して、走行中のバスの現在位置やバス停までの到着時間、目的地までの所要時間を自動表示する手段について触れられている。
特開２００１−３３８３９５号公報特開２００２−１５４００号公報特開２００２−３６７０８９号公報特開２００２−２３６９９６号公報

　バスの運行状況を正確に把握しようとすると、ＧＰＳやパケット通信端末機器等の車両搭載機器が必要なだけでなく、定点観測局（バスの所在を検出する基地）を設ける必要がある。従来技術で挙げた発明においては、現在の交通状態やバス（移動体）の現在位置把握などを前記の機器で把握し、バスの到着時間や目的地までの所要時間を割り出している。したがって、設備投資が嵩むシステムとなっている。

　そこで本考案が解決しようとする課題は、上記のような大がかりな設備投資がなくても、バスが目的地に到着する予定時間を計算できる手段を開発し、利用者に到着予想時間として配信サービスする装置を提唱することである。

　上記課題を解決するために、請求項１に記載された考案は、固定区間を運行しているバスで目的地までの予想時間を計算して利用者の端末にデータ送信する装置において、
(1)バスの過去の運行時間を路線ごとに情報として収集し、路線、季節、天候、時間帯、交通渋滞情報等をパラメータに該情報分析して運行パターンを作成してデータベース化する機構、
(2)前記の運行パターン、リアルタイムの渋滞情報、バスネットワークデータ路線情報および地図情報とから、問い合わせのあったバス停から目的地のバス停までの所要時間あるいは予想到着時間を計算して利用者の端末に配信サービスする機構、
を備えたことを特徴とするバスの目的地到着予想時間情報配信サービス装置であるとする。

　従来技術でも述べたように、バスは一般車両（公道を走る自動車）と鉄道車両の中間に位置する交通手段である。すなわち、一般車両には時刻表はないが、バスには鉄道と同様に時刻表がある。厄介なのは、一般車両と同様に交通渋滞に巻き込まれる点である。しかし一般車両と違う点は、場所やバス路線、あるいは時間帯によってバスには優先路線が設けられていることである。このような状況を加味すると、バスの運行には季節、時間帯、天候などの要素によって、同じ渋滞であっても目的地までの到着時間が異なることがわかる。そこで考案が解決しようとする課題を解決するために、本考案では実際のバスの運行状況を収集し、前記の季節、時間帯、天候、路線、渋滞度等をパラメータとして分析して運行パターンを作成し、データベース化する。このデータベースを「分析済運行情報データベース」と呼ぶことにする。この分析済運行情報データベースとリアルタイムに集積される交通渋滞情報とから、端末を利用して利用者から問い合わせのあったバス路線の乗車地から到着地までの所要時間を割り出し、バスの予定到着時間を計算して利用者の端末に配信する。

　バスの目的地到着予想時間情報配信サービス装置は、基本的に過去の運行情報を基に現在の渋滞情報（場合によっては天候なども加味）とから目的地（降車バス停）への予定到着時間を算出するものである。従って、ＧＰＳや定点観測基地などは必要としない。もちろん、現在すでにこのような機器や基地が存在している場合等、これらの情報が得られる路線に関しては、本考案の到着予想時間情報とを組み合わせて、より正確なバスの目的地到着時間を算定することができる。

　本考案の目的地到着予想時間情報配信サービス装置はインターネットを利用しての情報配信サービスであるから、利用者が本考案のサービスを受ける情報端末としては携帯電話、ＰＨＳ、携帯情報端末、パソコン、固定端末等の機器が対象となる。目的地到着予定時間は音声で受け取ることもできるが、表示装置を有する端末の場合には、地図情報、交通渋滞情報、バス停ごとの時刻表などの配信も受信できるようにしてある。システム装置の具体的な内容は、考案の実施の形態で説明する。

　本考案の実施の形態を図を用いて説明する。なお以下では、バスの目的地到着予想時間情報配信サービスシステムを提供するための装置を“ＢＮＳ”、データベースを“ＤＢ”と記述する。図１は本考案のＢＮＳの仕組みを示す概念図である。ＢＮＳはバス事業本部1が管理する。ＢＮＳはリアルタイム渋滞情報収集サーバー120（ＶＩＣＳ、ＡＴＩＳなど）と情報配信サーバー100、および情報配信サーバーの管理下にあるＤＢ群110から構成されている。ＤＢ群にはバスネットワーク路線情報ＤＢ111、地図情報ＤＢ112、分析済運行情報ＤＢ113などから構成される。バスネットワーク路線情報ＤＢはバスの系統図や運行表（時刻表）が、地図情報ＤＢは端末に送信して地図を表示するための地図データが、分析済運行情報ＤＢには本考案の過去のバス運行実績を分析して運行パターン化したデータが、それぞれ保管されている。渋滞情報収集サーバーはリアルタイムに交通状況を受信する通信装置で、この装置で収集した渋滞データはＢＮＳサーバーで参照することができる。

　利用者からの問い合わせは、インターネット9に接続のユーザー端末2で行う。ユーザー端末としては、携帯電話210（ＰＨＳやＰＤＡなども可）や固定端末220（パソコンや街頭端末等）などが対象になる。また情報配信サービス会社3などにもインターネットを通じて配信することもできる。情報配信サービス会社としてはＣＰ、カーナビメーカー、ケーブルテレビ、地域ポータサイトなどが含まれる。ＤＢ群は情報配信サービス会社に販売してそっくり移植することもできる。この場合には、情報配信サービス会社は、バス事業本部と同じ種類の交通情報サービスを利用者に提供できるし、またＤＢ群をもとに独自にＤＢに含まれるデータ（とくに分析済運行情報ＤＢのデータ）を加工・編集して利用者に配信サービスすることもできる。

　分析済運行情報ＤＢを作成するために、まず過去のバスの運行状況を収集する。例えば図２に示すように、バス路線（系列）、区間、季節、曜日、渋滞度、優先路線の有無、時間帯ごとのバスの運行実績を調査してまとめる。図では時間帯は始バスから終バスまでの時間を１時間単位に取っているが、通勤時などはもっときめ細かな時間細分が必要な場合もある。逆に通勤以外の日中は、ほぼ同じパターンの乗車数が考えられるので、２時間単位とか３時間単位でまとめともよい。季節についても、春夏秋冬の４区分になっているが、通学がなくなる夏休みや冬休み、夏のお盆時期（帰省時）、正月などに細分して調査する必要もある。曜日も、祭日などが含まれるときがあるので、その場合の考慮も必要となる。図の例は、データ収集の概念図と考えてもらいたい。いずれにしろ、最終的にはどの要素がどの程度バスの運行に影響しているかを分析する必要があり、そのための収集データの指標が図の表である。図では記していないが、天候などもバスの運行時間に影響する。例えば30mm以上の雨になると、バスは徐行運転が必要になり、時刻表に影響する。また同じ雨でも、路線や区間などによっても運行に影響する（路面状態や道幅などが違うため）。このようなデータも、独自に収集する必要がある。

　図では優先路線の有無と時間帯ごとの運行時間を記述しているが、多くの場合、時間帯で優先路線が決められているから、優先路線の有無から得られる所要時間データは多くの場合、どちらか一方になる。渋滞度は、渋滞の度合いを表すもので、数字の大きいほど渋滞していることを表す。渋滞情報収集サーバーが収集する渋滞情報は、ｋｍあるいは分である。例えば５ｋｍの渋滞とか、２０分の遅れといったデータで収集する。これをいくつかに分割し、ナンバリングしたものが渋滞度である。渋滞度０は渋滞のない状態を表す。交通渋滞がなければ時刻表通りの運行といくはずであるが、バスの場合にはそうならないところに本考案の実績運行情報が生きてくる。例えば通勤・通学の混雑時には、客の乗降車のために運行時間が遅れる。また季節では冬の着膨れの時期は通常よりも込み合うために、やはり運行時間に影響する。これらの情報を収集した結果をまとめたものが図２の表であり、ｍ±△ｍ（優先路線ありの場合）、ｎ±△ｎ（優先路線なしの場合）である。最初のｍ、ｎは観測値の平均値であり、△ｍ、△ｎは平均的ばらつきである。バス優先路線がある区間でも、渋滞時は優先路線に一般車が割り込むことがあり、必ずしも時刻表通りに運行するとは限らない。従って、観測が必要となる。まったく障害（渋滞や混雑等）のない場合は、ｍまたはｎは若干の時間的ズレはあっても、時刻表と同じになる。実際に、時刻表はそのように作られている。

　図２に示すような表ができれば、渋滞情報収集サーバーがリアルタイムに入手する渋滞情報から、表をたどって各区間の所要時間を求めることができる。しかし、現実には図のような表を得るためのデータをすべて集めることは難しいし、第一、データ量が膨大になりすぎる。そこで本考案では、図２の表のようなデータを収集し、各要素ごとの運行時間に与える影響度（具体的にはスケジュールから遅延時間）を求める。例えば、
　　　　状況　　　　　　　　　　　　遅延時間　　　
　　＝＝＝＝＝＝＝＝＝＝＝＝　　　＝＝＝＝＝＝　
　　平常運転時（ノーマル）　　　：　０　　　　　　
　　曜日別遅延時間　　　　　　　：　ｔ（ｉ）　　　
　　渋滞度別優先路線別遅延時間　：　ｔ（ｊ，ｋ）
　　時間帯別遅延時間　　　　　　：　ｔ（ｌ）　　　
　　季節別遅延時間　　　　　　　：　ｔ（ｍ）　　　
　　天候別遅延時間　　　　　　　：　ｔ（ｎ）　　　
　　　　　　　　　　　　　　　　：
　　　　　　　　　　　　　　　　：
を求める。ここでｉは１（月曜）１〜７（各曜日）、ｊは渋滞度、ｋは１（優先路線あり）、２（優先路線なし）、ｌは始バスから終バスまでの時間を分割した係数（添字）、ｍは季節とくに着膨れ時期、正月、春休み、ゴールデンウィーク、夏休み、お盆休み、年末などを表す添字、ｎは雨、雪とその降雨量を表す添字である。上記の遅延時間ｔ（ｘ）は、他の要素が影響しないとしたときの運行遅延時間である。

　しかし、上記のような遅延時間を各要素の総和として合計遅延時間を求めることは現実的でない。例えば、２ｋｍ（渋滞度２）の渋滞でｔ１の遅れがあり、着膨れの時期でｔ２の遅れがあると判断した場合に、遅延時間は単純にｔ１＋ｔ２とはならない。なぜなら渋滞の遅れの間、客の乗降車ができるからである。また普段（月〜金曜日）の通勤通学であっても、通学のなくなる夏休み時には、通勤客だけの混雑のみを考慮しなければならない。このようなことを実績データを分析し、
　　Ｔ（ｘ）＝Σｆ（ｘ，ｙ）ｔ（ｙ）
なる関係式を導く。ここでＴは条件ｘ時の遅延時間、ｆは条件ｘと条件ｙとで決まる運行パターン係数、ｔ（ｙ）は条件ｙ時の遅延時間である。ｘは先に挙げた｛ｉ、ｊ、ｋ、ｌ、ｍ……｝の組み合わせからなる条件であり、ｙは｛ｉ、ｊ、ｋ、ｌ、ｍ……｝のいずれかであり、Σはｙの総和を表す。例えば、ｘ＝（ｉｊｋｌｍｎｐ）の係数ｆ（ｘ）は、曜日ｉ、渋滞度ｊ、優先路線有無k、時間帯ｌ、季節ｍ、天候ｎ、区間ｐの要素から決まる運行パターン係数である。実際の調査では細分した要素ごとのデータを収集するが、実績データからパターン化する際は、ｉは平日、土曜、日（祭日も含む）の３段階、区間ｐは同じパターン（広い通り、狭い通りなど）に属する区間群でくくれる。運行パターン係数ｆは実績値Ｔとｔから求め、路線ごとに作られる。リアルタイムに入手する渋滞度ｊと天候ｎ以外の要素は照会のあった日時と経路から求められる。従ってリアルタイムに渋滞度と天候を入手すればｆが決まるから、照会の目的値までの到着遅延時間Ｔが求められ、正常の運行時間に予想遅延時間Ｔを加えれば、目的地予想到着時間が計算できる。なお一般には天候の影響は少ないから、省いて考えても差し支えない。

　上記の運行パターン係数ｆはバス系列（路線）ごとに計算し、分析済運行情報ＤＢに登録しておく。しかし、同じ地域の場合には違うバス系列でも同じ運行パターンになっている。従って、ｆを系列を超えて集約化してＤＢを作成することもできる。これにより、データ量を減らすことができる。

　本考案を用いた利用例を図３に示す。利用者は携帯電話210から情報配信サーバーに接続する。該サーバーに接続し、「バス渋滞ナビ」を選択すると、該サーバーからバス渋滞ナビのメインメニュー画面211が送信され、ディスプレイに表示される。このバス渋滞ナビの例では、
　　１．経路探索
　　２．渋滞情報
　　３．所要時間
のメニューが用意されている。メニューは階層化されていて、メインメニューから様々な情報を引き出すことができる。「１．経路探索」では出発地と目的地を設定すると、目的地までの最適なバス経路が検索され、照会される。このようにして情報を得た後、「３．所要時間」を選択し、予定乗車時間を入力すれば、乗車可能なバスの到着時間と目的地到着時間が計算されて、画面212表示される。ここで表示される目的地到着時間は、本考案の分析済運行情報ＤＢをもとに計算された予想到着時間である。さらに次の画面を選択（矢印キーの選択）すると、バスの路線地図が画面213表示される。さらに次の画面を選択すると、渋滞情報画面214となる。この画面は「２．渋滞情報」からも引き出せる。渋滞情報は渋滞情報収集サーバーがリアルタイムに入手したデータをもとに、情報配信サーバーが加工・編集したものである。また利用者は「１．経路探索」後、選択路線のバスの時刻表も入手することもできる（画面215）。なお画面213の路線地図は地図情報ＤＢに記録されている地図情報を加工・編集したものであり、画面215の時刻表はバスネットワーク路線情報ＤＢに記録されている路線ごとの時刻表を編集したものである。

　本考案の最大の特徴は、過去のバス運行データとリアルタイムに入手する交通渋滞情報をもとに、目的地への到着時間を計算している点である。これまでのバスナビでは、ＧＰＳや各地点に設置の基地局からのバス運行状況から、バスの到着時間や目的地への到着時間を計算している。従って、ＧＰＳ受信端末、パケット通信端末、各地点の検索局とセンサーなどを必要とした。これに対して本考案では過去の運行データのみで目的地到着時間を算出しているために、前記のような装置や設備が必要がなく、システム導入が容易であり、かつローコストの導入・ローコストの運営が可能となっている。とくにバス運行に影響する最大の要因であるリアルタイムの渋滞情報を用いているために、リアルタイムで現実に近い目的地到着時間が算出される点も、本考案の特徴である。交通渋滞情報の取得には、すでに一般化し広く利用されている既存の施設が利用できるために、本考案の導入の障害とはならない。

　過去の運行状況については、過去のデータをパターン化してＤＢ化しているから、データ量が押さえられるだけでなく、同じ運行パターンを有する他の路線への応用も容易である（もちろん、若干の加工は必要だが）。このようなことから、本システムを支えている各種のＤＢを他の情報配信サービス会社に譲渡することも容易であり、譲渡した各社がそのままＤＢを利用することも、また独自にデータを加工して新たなサービスを始めたり、別の利用法を開発することも可能となっている。すなわち、本装置は新たなビジネス拡大の可能性を秘めている。

本考案のバスの目的地到着予想時間情報配信サービスを提供するための装置のシステム構成図である。本考案のバスの目的地到着予想時間情報配信サービスを提供するための装置の基礎となっているバス運行情報の収集とその内容を説明するための路線別区間別運行実績表である。本考案のバスの目的地到着予想時間情報配信サービスを提供するための装置の利用例の説明図である。

符号の説明

１　　　　バス事業本部（ナビゲーションセンター）
１００　　情報配信サーバー
１１０　　データベース群（ＤＢ群）
１１１　　バスネットワーク路線情報データベース
１１２　　地図情報データベース
１１３　　分析済運行情報データベース
１２０　　リアルタイム渋滞情報収集サーバー
２　　　　利用者端末（ユーザー端末）
２１０　　携帯端末（携帯電話、ＰＨＳ、ＰＤＡ等）
２１１〜２１５　　画面
２２０　　固定端末（パソコン、街頭端末等）
３　　　　情報配信サービス会社
９　　　　インターネット

Claims

固定区間を運行しているバスで目的地までの予想時間を計算して利用者の端末にデータ送信する装置において、
(1)バスの過去の運行時間を路線ごとに情報として収集し、路線、季節、天候、時間帯、交通渋滞情報等をパラメータに該情報分析して運行パターンを作成してデータベース化する機構、
(2)前記の運行パターン、リアルタイムの渋滞情報、バスネットワークデータ路線情報および地図情報とから、問い合わせのあったバス停から目的地のバス停までの所要時間あるいは予想到着時間を計算して利用者の端末に配信サービスする機構、
を備えたことを特徴とするバスの目的地到着予想時間情報配信サービス装置。