図面 (/)

技術 移動サービスシステムおよび移動サービス提供方法

出願人 株式会社日立製作所
発明者 江端智一矢野浩仁堀悟鈴木敬
出願日 2019年3月25日 (1年11ヶ月経過) 出願番号 2019-057161
公開日 2020年10月1日 (4ヶ月経過) 公開番号 2020-160605
状態 未査定
技術分野 交通制御システム
主要キーワード 停留場所 類似事象 出発方向 水上交通 リクエスト時刻 音量計測 基本経路 節点情報
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年10月1日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (18)

課題

利用者不満度合いを車両の運行に反映させることで、利用者への交通サービスの向上を可能にする移動サービスシステムを提供する。

解決手段

移動サービスシステムは、利用者に発生する不満を数値で取得し、不満に応じて、移動リソース運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを第1データベースに記録し、その利用者に付与されているポイントと引き換えに、要求と第2データベースに管理されている移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更する。

概要

背景

一般的に、公共交通サービスでは、サービス提供者サービス内容を予め決定し、運用している。つまり、サービス提供者が予め車両運行スケジュールダイヤ)を定め、そのスケジュールに従って車両を運行している。

これに対して、特許文献1には、タイムテーブルに従って運行行路を運行するバスが所定の時刻チェックポイントに到達していないと判定した場合、臨時乗り物出動させる技術が開示されている。

特許文献2には、提供者の車両に他の利用者相乗りさせるための技術が開示されている。提供者の車両の移動経路の過去の実績情報蓄積し、その実績情報を参照して移動計画立案した後、車両の提供者に相乗りの受け入れ依頼し、提供者が依頼を受け入れたら、提供者の車両に相乗り希望者を相乗りさせる。
特許文献3には、車両の疑似する仮想オブジェクトを使ったコンピュータシミュレーションによって、交通状況再現して評価する技術が開示されている。

非特許文献1には、人の移動(乗用車)と物の移動(貨物車)について交通量を推計し、発生集中交通量分布交通量、および配分交通量を含む将来の交通需要を推計する計算式およびパラメータが開示されている。

概要

利用者の不満度合いを車両の運行に反映させることで、利用者への交通サービスの向上を可能にする移動サービスシステムを提供する。移動サービスシステムは、利用者に発生する不満を数値で取得し、不満に応じて、移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを第1データベースに記録し、その利用者に付与されているポイントと引き換えに、要求と第2データベースに管理されている移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更する。

目的

本開示のひとつの目的は、利用者の不満の度合いを車両の運行に反映させることで、利用者への交通サービスの向上を可能にする技術を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

移動リソース運行して利用者を移動させるサービスを提供する移動サービスシステムであって、前記利用者に関する第1データベースを記憶し、前記利用者の要求を管理する第1管理装置と、前記移動リソースに関する第2データベースを記憶し、前記移動リソースの運行の状態を管理する第2管理装置と、前記第1管理装置および前記第2管理装置と連携して、前記移動リソースの運行を変更する第3管理装置と、を有し、前記第3管理装置は、前記利用者に発生する不満数値で取得し、前記第1管理装置は、前記不満に応じて、前記移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを前記第1データベースに記録し、前記第3管理装置は、前記利用者から要求を受けて、前記第1データベースに管理されている該利用者に付与されているポイントと引き換えに、前記要求と前記第2データベースに管理されている前記移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更する、移動サービスシステム。

請求項2

前記第3管理装置は、前記移動リソースの運行の計画を変更したとすると、前記移動リソースの他の利用者に発生する不満を推定し、前記他の利用者の不満と、前記要求を発した利用者のポイントとに基づいて、前記移動リソースの運行の計画の変更が可能であるか否か判定する、請求項1に記載の移動サービスシステム。

請求項3

前記第3管理装置は、前記移動リソースの運行を計画を変更すると、前記要求を発した利用者のポイントから、前記他の利用者の不満に相当する分を減算する、請求項2に記載の移動サービスシステム。

請求項4

前記第3管理装置は、前記不満の対象となる複数のサービス品質項目について、前記利用者による重視度合いを係数とし、前記サービス品質項目についての事象計測値変数とし、前記サービス品質項目毎の前記係数と前記変数の積を前記複数のサービス品質項目について合計し、合計値を前記利用者の前記不満の値とする、請求項1に記載の移動サービスシステム。

請求項5

前記第3管理装置は、前記利用者からの前記要求にて前記サービス品質項目に対する嗜好の情報を取得して前記係数を更新する、請求項4に記載の移動サービスシステム。

請求項6

前記第3管理装置は、前記利用者が前記移動リソースにより移動したときに前記利用者から不満の有無を知得し、前記不満が有りであれば、前記事象の計測値に基づいて前記第1管理装置に前記利用者の前記不満の値を更新させる、請求項5に記載の移動サービスシステム。

請求項7

前記第3管理装置は、前記他の利用者の不満と、前記要求を発した利用者のポイントとに基づき、前記移動リソースの運行の計画の可能な変更を抽出し、前記要求を発した利用者に提示し、前記利用者の選択した変更を実施する、請求項2に記載の移動サービスシステム。

請求項8

前記第3管理装置は、前記サービスが提供されるサービスエリア区分けした複数のエリアのそれぞれについて前記不満の値を集計し、集計結果を表示する、請求項1に記載の移動サービスシステム。

請求項9

前記第1管理装置は、前記集計結果に基づいて、前記エリアにおける前記不満の原因を解析し、前記原因を低減するように、前記エリアにおける前記移動リソースの運行の計画を提案する、請求項8に記載の移動サービスシステム。

請求項10

前記サービス品質項目には、前記移動リソースへ登場する場所、前記移動リソースを利用するために要する時間、前記移動リソース内の混雑、前記移動リソースにおける着席可否、または移動リソース内の騒音少くとも1つが含まれる、請求項4に記載の移動サービスシステム。

請求項11

前記第1管理装置は、前記第1データベースにて、利用者毎の不満の値を管理し、所定時間継続して新たな不満が発生しなかった利用者の不満の値を所定の初期値にする、請求項1に記載の移動サービスシステム。

請求項12

移動リソースを運行して利用者を移動させるサービスを提供するための移動サービス提供方法であって、前記利用者に関する第1データベースを記憶し、前記利用者の要求を管理する第1管理装置と、前記移動リソースに関する第2データベースを記憶し、前記移動リソースの運行の状態を管理する第2管理装置と、前記第1管理装置および前記第2管理装置と連携して、前記移動リソースの運行を変更する第3管理装置と、を有するシステムにおいて、前記第3管理装置が、前記利用者に発生する不満を数値で取得し、前記第1管理装置が、前記不満に応じて、前記移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを前記第1データベースに記録し、前記第3管理装置が、前記利用者から要求を受けて、前記第1データベースに管理されている該利用者に付与されているポイントと引き換えに、前記要求と前記第2データベースに管理されている前記移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更する、移動サービス提供方法。

技術分野

0001

本発明は、利用者不満度合いを利用して交通サービス車両運行を制御する技術に関する。

背景技術

0002

一般的に、公共交通サービスでは、サービス提供者サービス内容を予め決定し、運用している。つまり、サービス提供者が予め車両運行のスケジュールダイヤ)を定め、そのスケジュールに従って車両を運行している。

0003

これに対して、特許文献1には、タイムテーブルに従って運行行路を運行するバスが所定の時刻チェックポイントに到達していないと判定した場合、臨時乗り物出動させる技術が開示されている。

0004

特許文献2には、提供者の車両に他の利用者を相乗りさせるための技術が開示されている。提供者の車両の移動経路の過去の実績情報蓄積し、その実績情報を参照して移動計画立案した後、車両の提供者に相乗りの受け入れ依頼し、提供者が依頼を受け入れたら、提供者の車両に相乗り希望者を相乗りさせる。
特許文献3には、車両の疑似する仮想オブジェクトを使ったコンピュータシミュレーションによって、交通状況再現して評価する技術が開示されている。

0005

非特許文献1には、人の移動(乗用車)と物の移動(貨物車)について交通量を推計し、発生集中交通量分布交通量、および配分交通量を含む将来の交通需要を推計する計算式およびパラメータが開示されている。

0006

特開2006−163738号公報
特開2015−191364号公報
特開2013−080272号公報

先行技術

0007

「技術調査将来交通需要推計の見直し」、国土交通省、(http://www.mlit.go.jp/tec/tec_mn_000003.html(2018年12月11日))

発明が解決しようとする課題

0008

上述したように、従来の公共交通サービスには、利用者が抱く不満を定量的に車両の運行に反映させるものはなかった。
本開示のひとつの目的は、利用者の不満の度合いを車両の運行に反映させることで、利用者への交通サービスの向上を可能にする技術を提供することである。

課題を解決するための手段

0009

本開示によるひとつの移動サービスシステムは、移動リソースを運行して利用者を移動させるサービスを提供する移動サービスシステムであって、前記利用者に関する第1データベースを記憶し、前記利用者の要求を管理する第1管理装置と、前記移動リソースに関する第2データベースを記憶し、前記移動リソースの運行の状態を管理する第2管理装置と、前記第1管理装置および前記第2管理装置と連携して、前記移動リソースの運行を変更する第3管理装置と、を有し、前記第3管理装置は、前記利用者に発生する不満を数値で取得し、前記第1管理装置は、前記不満に応じて、前記移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを前記第1データベースに記録し、前記第3管理装置は、前記利用者から要求を受けて、前記第1データベースに管理されている該利用者に付与されているポイントと引き換えに、前記要求と前記第2データベースに管理されている前記移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更する。

発明の効果

0010

本開示によれば、利用者の不満の度合いを車両の運行に反映させることで、利用者への交通サービスの向上を可能にする。

図面の簡単な説明

0011

本実施形態に係る需要マネジメント型交通サービスシステムハードウェア構成を示すブロック図である。
本実施形態の需要マネジメント型交通サービスシステムの各サーバ装置のハードウェア構成を説明するためのブロック図である。
本実施形態の需要マネジメント型交通サービスシステムの各端末装置のハードウェア構成を説明するためのブロック図である。
乗客情報管理サーバが備える住民データベースER図である。
住民パラメータのスキーマを示すテーブルである。
バス運行管理サーバが備えるバスデータベースのER図である。
バス走行ログ13−45のスキーマを示すテーブルである。
運行計画サーバが備える集計データベースのER図である。
エリア別集計結果のスキーマを示すテーブルである。
本実施形態の需要マネジメント型交通サービスシステムが適用される全体サービスエリアの一例を示す図である。
本実施形態の需要マネジメント型交通サービスシステムによるオンラインでの運行計画の変更の様子を示す路線概念図である。
運行計画を変更するときの乗客情報端末画面例を示す図である。
本実施形態の需要マネジメント型交通サービスシステムによるリクエストの処理を示すシーケンス図である。
需要マネジメント型交通サービスシステムが乗客からアンケートへの回答を取得する処理のシーケンス図である。
不満を集計した結果を表示したGUIの画面例を示す図である。
エリアの不満を集計した結果をエリア毎に表示したGUIの画面例を示す図である。
バス運行計画を立案する処理を示すシーケンス図である。

実施例

0012

本実施形態では乗客を移動させるために運行する移動リソースとしてバスを例示する。本実施形態のシステムは、バスを運行して乗客を移動させるサービスを提供するシステムである。本サービスは、乗客となりうる利用者がバスの運行の変更を要求することが可能なサービスである。バスは、移動リソースの一例であり、これに限定されるものではない。本例の他の交通手段であっても良いし、水上交通手段や空中交通手段などであってもよい。
以下、本実施形態について図面を参照して説明する。
なお、以下に説明する実施形態は発明を限定するものではない。また、実施形態の中で説明されている諸要素及びその組み合わせの全てが発明に必須ではない。
図1は、本実施形態に係る需要マネジメント型交通サービスシステムのハードウェア構成を示すブロック図である。

0013

図1において、需要マネジメント型交通サービスシステムは、運行計画サーバ11、乗客情報管理サーバ12、バス運行管理サーバ13、およびバス運行指示端末14を含んでいる。バス運行指示端末14は、乗務員が操作可能にバス車両に搭載されるか、あるいはバスの乗務員が携帯する情報処理端末である。バス運行指示端末14には乗務員にバスの運行を指示する情報が表示される。

0014

乗客情報端末15は、バスを利用する乗客が携帯する端末であり、乗客が所有するスマートホンなどのモバイル端末であってよい。

0015

運行計画サーバ11は、乗客情報管理サーバ12、バス運行管理サーバ13、バス運行指示端末14、および乗客情報端末15とネットワーク16で相互に接続される。

0016

ネットワーク16の態様は、例えば、乗客情報管理サーバ12およびバス運行管理サーバ13では有線ネットワークで接続され、バス運行指示端末14および乗客情報端末15は無線ネットワークで接続されるケースがある。しかし、ネットワーク16のどの部分が有線ネットワークあるいは無線ネットワークかについては特に限定されない。

0017

図2は、本実施形態の需要マネジメント型交通サービスシステムの各サーバ装置のハードウェア構成を説明するためのブロック図である。運行計画サーバ11と乗客情報管理サーバ12とバス運行管理サーバ13は基本的なハードウェア構成が共通する情報処理装置であり、そのハードウェア構成が図2に示されている。

0018

図2を参照すると、情報処理装置は、CPU1−01、メモリ1−02、通信NIC(Network Interface Card)1−03、ハードディスクドライブ(以下、HDDという)1−04、入出力コントローラ1−05、モニタコントローラ1−06、バス1−07、ディスプレイ1−13、キーボード1−11、およびマウス1−12を有している。CPU1−01、メモリ1−02、通信NIC 1−03、HDD 1−04、入出力コントローラ1−05およびモニタコントローラ1−06はバス1−07に接続されている。入出力コントローラ1−05は、キーボード1−11およびマウス1−12に接続されている。モニタコントローラ1−06には、ディスプレイ1−13が接続されている。
CPU1−01は、メモリ1−02上のソフトウェアプログラムを実行することで各サーバの機能を実現する。
メモリ1−02は、サーバの機能を実現するためのソフトウェアプログラムおよびそのソフトウェアの処理に利用される各種データを記憶する装置である。
通信NIC 1−03は、サーバがネットワーク16に接続し、データ等を送受信するための装置である。

0019

HDD1−04は、サーバの処理に利用されるデータベースが格納されている。例えば、乗客情報管理サーバ12のHDD 1−04には、住民に関する情報を蓄積したデータベースが格納される。また、バス運行管理サーバ13のHDD 1−04には、バスに関する情報を蓄積したデータベースが格納される。
入出力コントローラ1−05は、キーボード1−11およびマウス1−12によるサーバへのデータの入出力を制御する装置である。
モニタコントローラ1−06は、ディスプレイ1−13への画面の表示を制御する装置である。
ディスプレイ1−13は、操作者に対して、画像やテキストを含む画面を表示する表示装置である。
キーボード1−11、およびマウス1−12は、操作者による操作を受け、操作のデータを入出力コントローラ1−05に出力する装置である。

0020

図3は、本実施形態の需要マネジメント型交通サービスシステムの各端末装置のハードウェア構成を説明するためのブロック図である。バス運行指示端末14と乗客情報端末15は基本的なハードウェア構成が類似する情報処理装置であり、その説明のためのハードウェア構成が図3に示されている。

0021

図3端末装置は、図2のサーバ装置におけるキーボード1−11、マウス1−12およびディスプレイ1−13の代わりにタッチパネル1−15を有している。なお、端末装置のうち乗客情報端末15は、GPS(Global Positioning System)モジュール1−08とICリーダモジュール1−14を有している。
タッチパネル1−15は、乗客に対して画面を表示し、かつ、乗客による画面への操作を受け付ける装置である。

0022

GPSモジュール1−08は、GPS衛星からの電波を受信し、自身の位置情報を出力する装置である。位置情報は、乗客の位置を示す情報として処理に利用される。

0023

ICリーダモジュール1−14は、ICカードに記録されたデータを読みだして出力する装置である。ICカードから読み出したデータは処理に利用されてもよい。

0024

図4は、乗客情報管理サーバが備える住民データベースのER(Entity Relationship)図である。住民データベース12−40は、本需要マネジメント型交通サービスシステムがサービスを提供するサービスエリアの住民である。この住民がバスの乗客となることが想定されている。住民データベース12−40には、住民パラメータ12−41、リクエスト発行情報12−42、およびリクエスト消化ログ12−43が含まれている。住民パラメータ21−41には、本システムのバスの乗客となりうる地域の各住民に関する各種情報が設定されている。リクエスト発行情報12−42には、住民が発行したリクエストに関する情報が設定されている。住民パラメータ12−41にて管理されている1人の住民に、0個以上のリクエストが対応しうる。

0025

リクエストには、乗客(バスに乗車しようとしている住民)がバスへの乗車に関して要求する要求事項が含まれている。バスの運行を変更する必要のあるような要求がリクエストに含まれている場合もある。リクエストが採用され、実施されると、そのリクエストは消化される。

0026

リクエスト消化ログ12−43は、住民が発行したリクエストの消化に関する情報である。リクエストが発行されると、リクエスト発行情報テーブル12−42にそのリクエストのインデックス(不図示)が登録される。インデックスには、リクエストを発行した乗客、その乗客が乗車するバス、乗客がバスに乗車する乗車場所、乗客が降車する降車場所の情報が含まれている。

0027

その後、そのリクエストが実行されると、そのリクエストが消化されたことがリクエスト消化ログテーブル12−43にログ情報として記録される。リクエストは、乗客がバスへ乗車し降車することにより実行される。バスの運行の変更を要するリクエストが採用された場合には、リクエストの実行はバスの運行の変更を伴う。

0028

需要マネジメント型交通サービスシステムの提供するサービスに対して生じた住民の不満はポイントとして蓄積される。住民が乗客としてバスを利用すると、需要マネジメント型交通サービスシステムは、その住民がバスの運行に関連して抱いた不満を、その乗客がバスから降車するときにアンケートへの回答を求めることにより、知得する。ポイントは、バスの運行を自身の都合の良いように変更することを要求するために利用可能な仮想債券である。バスの乗客となるある住民が発行したリクエストが採用されると、リクエストの採用に伴い、リクエストを発行した住民の不満度は低下することが期待できる。そして、その住民の所持しているポイントは、そのリクエストの採用により発生が推定される他の住民(同じバスに乗車している他の乗客)の不満を相殺するだけのポイントが消化される。一方、同じバスに乗車している他の乗客には、別途される不満の表明に応じてポイントが付与される。

0029

住民パラメータ12−41には、住民ID、不満度(時間/混雑着席騒音/場所)、不満度に係る係数(時間/混雑/着席/騒音/場所)、所有ポイント、住民の住所座標経度緯度)、徒歩速度[km/h]、騒音の発生レベルを表すパラメータ、リクエスト時刻決定用の乱数生成パラメータ往路μ、往路σ、復路μ、復路σ)、住民の属性性別年齢職業、その他)という項目が含まれている。図5は、住民パラメータのスキーマを示すテーブルである。住民パラメータ12−41の各項目には、図5に示されたスキーマに従って情報が設定される。

0030

住民IDは、各住民を個々に識別する識別情報である。

0031

不満度は、当該住民の不満の度合いを数値で示す情報である。不満には、時間に関する不満、混雑に関する不満、着席に関する不満、騒音に関する不満、場所に関する不満が含まれている。時間に関する不満とは、バスの到着遅れにより当該住民がバスの停留所バス停)で待つ時間に対する不満である。混雑に関する不満とは、当該住民が搭乗したバス内の混雑に対する不満である。着席に関する不満とは、当該住民が搭乗したバスにおいて座席に座れないことに対する不満である。騒音に関する不満とは、当該住民が搭乗したバス内の騒音に対する不満である。場所に関する不満とは、バスの搭乗の前あるいは後に当該住民が歩く距離に対する不満である。例えば出発場所と乗車場所が異なれば住民はその間を歩く必要がある。また、降車場所と到着場所が異なれば住民はその間を歩く必要がある。

0032

不満度に係る係数は、時間、混雑、着席、騒音、または場所のそれぞれに対する不満に対する当該住民の重視の度合いを示す値である。

0033

所有ポイントは、当該住民が所有しているポイントを示す情報である。

0034

住民の住所座標は、当該住民の住所を示す情報であり、経度および緯度により示される。

0035

徒歩速度は、当該住民の歩く速度を示す情報であり、km/hという単位で示される。

0036

騒音の発生レベルを表すパラメータは、当該住民が搭乗することによりバス内の騒音が増大する度合いを示すパラメータである。

0037

リクエスト時刻決定用の乱数生成パラメータは、リクエストが発行される時刻を決定するためのパラメータである。リクエスト時刻決定用の乱数生成パラメータとして、往路の出発時刻平均値μおよび標準偏差σと、復路の出発時刻の平均値μおよび標準偏差σとが設定される。

0038

住民の属性は、当該住民の各種属性を示す情報である。住民の属性には、性別、年齢、職業等が含まれる。

0039

図6は、バス運行管理サーバが備えるバスデータベースのER図である。バスデータベース13−40には、バス車体パラメータ13−41、バス折返し発車予定時刻13−42、バス基本経路移動順序−停留所対応表13−43、基本経路上の停留所13−44、およびバス走行ログ13−45が含まれている。

0040

バス車体パラメータ13−41は、本システムの移動リソースとして乗客を移動させる各バス車体に関する情報である。バス車体パラメータテーブル13−41には、バス車体ID、バス識別名、バス基本経路ID、運賃収入[円]、走行距離[km]、運賃計算用の係数のインデックスがあり、各インデックスに情報が記載される。

0041

バス折返し発車予定時刻13−42は、各バス車体の始発場所からの運行に関する情報である。通常、1台のバス車体が1回以上の運行に利用されるので、バス折返し発車予定時刻テーブル13−42には、1台のバス車体に対して1つ以上の運行に関する情報が記録される。バス折返し発車予定時刻テーブル13−42には、バス車体ID、バスの出発方向(例えば逆方向か否か)、発車時刻のインデックス(不図示)があり、各インデックスに情報が記載される。

0042

バス基本経路の移動順序−停留所対応表13−43は、各バス車体の運行における基本経路に関する情報である。基本経路は、変更のリクエストが無ければバスが運行する予定経路である。通常、ひとつの基本経路を複数のバス車体が運行する。また通常、1台のバス車体は複数の基本経路を運行する。バス基本経路の移動順序−停留所対応表テーブル13−43には、バス基本経路ID、停留所順序番号、停留所IDのインデックス(不図示)があり、各インデックスに情報が記載される。

0043

基本経路上の停留所13−44は、基本経路上にある各停留所に関するテーブル情報である。基本経路上の停留所13−44のテーブルには、各停留所の停留所ID、停留所名称GI節点ID、停留所種別のインデックス(不図示)があり、各インデックスに情報が記載される。

0044

GIS節点IDは、地理情報システム(GIS(Geographic Information System)の節点を個々に識別する識別情報である。GIS節点は例えば交差点である。GIS節点は、例えば、節点番号、経度、緯度、ジオメトリ情報により示される。

0045

バス走行ログ13−45は、各バス車体の運行に関する履歴情報のテーブルである。バス走行ログ13−45のテーブルには、車体ID、日付番号(何日目)、始発時刻、始発停留所終着時刻、終着停留所、方向(逆方向か否か)、延べ乗車人数走行1回分の運賃収入[円]、走行1回分の走行距離[km]のインデックス(不図示)があり、各インデックスに情報が記載される。図7は、バス走行ログ13−45のスキーマを示すテーブルである。バス走行ログ13−45の各インデックスには、図5に示されたスキーマに従って情報が設定される。

0046

図8は、運行計画サーバが備える集計データベースのER図である。集計データベース11−40には、集計結果11−41、エリア別集計結果11−42、およびエリア定義11−43が含まれている。

0047

集計結果11−41は、バス運行の結果を集計した情報である。集計結果11−41のテーブルには、日付番号(何日目)、バスの総運賃収入(日計)[円]、バスの総走行距離(日計)[km]のインデックスがあり、各インデックスに情報が記載される。

0048

エリア別集計結果11−42は、バス運行の結果をエリア毎に集計した情報である。エリアは、全体サービスエリアを所定サイズの矩形区分けしたエリアである。図9は、エリア別集計結果のスキーマを示すテーブルである。エリア別集計結果11−42のテーブルには、日付番号(何日目)、エリアID、エリア別満足度平均(終値)のインデックス(不図示)があり、各インデックスには、図9に示したスキーマに従った情報が記載される。エリア別満足度平均は、エリア毎に、時間、混雑、着席、騒音、および場所の全項目の不満の合計値負数にした値である。更に、時間、混雑、着席、騒音、および場所の項目毎にエリア別満足度平均を求め、集計結果11−42に含めて記録してもよい。

0049

エリア定義11−43は、全体サービスエリアに含まれる各エリアの定義情報である。エリア定義11−43のテーブルには、エリアID、矩形座標左上座標、右下座標)のインデックス(不図示)があり、各インデックスに情報が記載される。

0050

図10は、本実施形態の需要マネジメント型交通サービスシステムが適用される全体サービスエリアの一例を示す図である。一例として、全体サービスエリアは、面積約30平方キロメートル、人口約12万人で、バスの利用者数が約4500人/日である。

0051

この全体サービスエリアには、5つのバス定期運行の路線があるとする。それらは、それぞれGreen Line(GL)、Red Line(RL)、Aqua Line(AL)、Blue Line(BL)、Yellow Line(YL)と称呼される路線である。

0052

図11は、本実施形態の需要マネジメント型交通サービスシステムによるオンラインでの運行計画の変更の様子を示す路線概念図である。図12は、運行計画を変更するときの乗客情報端末の画面例を示す図である。

0053

図11に示されたバス8−10は、その情報がバス車体パラメータテーブル13−41に記載されているバスであるとする。バス8−10は、バス基本経路の移動順序−停留所対応表テーブル13−43に記載されている出発停留所8−01から到着停留所8−04に向けて運行をする。基本経路は、出発停留所8−01、固定停留所8−02、固定停留所8−03、到着停留所8−04とたどる経路である。固定停留所8−02、8−03は、運行計画を変更するときにも必ず通る必要のある停留所であるとする。

0054

ここで、住民パラメータテーブル12−41に記載されている、ある乗客8−05が、乗客情報端末15を使って、バスへの乗車を要求するリクエストを発行したものとする。このリクエストは、乗客情報管理サーバ12にてリクエスト発行情報12−42テーブルに登録される。

0055

乗客8−05は、リクエストにおいて、乗客自身の出発場所8−06と到着場所8−07を任意に指定できる。例えば、自宅をを出発場所とし、最終的に行きたい場所を到着場所に指定することができる。図12に示された乗客情報端末15の画面例8−0501には出発場所と到着場所を指定する例が示されている。画面例8−0501には、出発場所として自宅を指定し、到着場所としてA病院を指定した例が示されている。また、乗客8−05は、リクエストにおいて、出発場所に近い場所8−08にバスを停車してもらうという希望および/または到着場所に近い場所8−09にバスを停車してもらうという希望を提示することができてもよい。

0056

また、乗客8−05はリクエストにおいて他の様々な希望について優先づけを指定することもできる。例えば、希望の場所への停車を他の項目よりも優先すること(場所優先)を指定できる。また、バス停にて待つ時間を短くすることを他の項目よりも優先すること(時間優先)を指定できる。また、車内が空いており空間的に余裕のあるバスを他の項目よりも優先すること(間隙優先)を指定できる。また、座席に座ることができることを他の項目よりも優先すること(着席優先)を指定できる。また、車内の騒音レベルが低いことを他の項目よりも優先すること(静寂優先)を指定できる。図12の画面例8−0502には、到着希望時刻と共に時間優先を指定するときの画面例が示されている。図12の画面例8−0502は画面例8−0501を下方にスクロールした一連の画面である。

0057

乗客8−05からのリクエストは、需要マネジメント型交通サービスシステムにて処理される。リクエストの処理の詳細は後述する。処理の結果、バス8−10は、予め定められた基本路線から外れ、ある程度出発場所または到着場所に近い場所(例えば、図11の場所8−11)に停車する場合もあるし、予め定められた基本路線上の場所8−12に停車する場合もある。リクエストに応じたバスの運行が行われると、バスの運行の結果は、リクエスト消化ログ12−43に記録される。

0058

更に、乗客8−05がバスを降車する場所(例えば、図11の場所8−09)にバス8−10が到着すると、需要マネジメント型交通サービスシステムは、乗客8−05の乗客情報端末15にアンケートを提示し、乗客8−05の回答を取得する。乗客8−05は、バスの利用において不満があった場合にはこの回答にて不満を表明することができる。図12の画面例8−0503には、アンケートを表示し、乗客へ回答を促す画面の例が示されている。需要マネジメント型交通サービスシステムが乗客からアンケートへの回答を取得する処理の詳細は後述する。
図13は、本実施形態の需要マネジメント型交通サービスシステムによるリクエストの処理を示すシーケンス図である。

0059

乗客情報端末15はバスの乗車に関するリクエストを運行計画サーバ11に送信(15−911)する。リクエストを受信した運行計画サーバ11は、バス運行管理サーバ13に、出発場所および到着場所を提示して、乗客が利用可能なバスを問い合わせる(11−911)。問い合わせを受けたバス運行管理サーバ13は、提示された出発場所および到着場所を基に、利用可能なバスを選択し(13−911)、運行計画サーバ11に通知する。このとき1つ以上のバスが通知される。
乗客が利用可能なバスの通知を受けた運行計画サーバ11は、通知されたバスの中に、乗客の希望を満たすバスがあるか否か調べる(11−912)。
乗客の希望を満たすバスがある場合は、運行計画サーバ11は、そのバスを選択する(13−913)。

0060

次に、運行計画サーバ11は、リクエストに、出発場所または到着場所に近い場所へのバスのルートを変更することの要求(以下、付近ピックアップ要求という)が含まれているか否か調べる(11−914)。付近ピックアップ要求が場合には、運行計画サーバ11は、出発場所に近い停留所を乗客が乗車すべき停留所とし、到着場所に近い停留所を乗客が降車すべき停留所として、それら停留所を停車ポイントとし(11−915)、乗客が利用可能な1以上のバスの候補を、停車ポイントと共に乗客情報端末15に通知する。乗客情報端末15は通知されたバスの情報を乗客が利用する候補として表示する(15−912)。

0061

テップ11−914にて、付近ピックアップ要求があった場合、すなわち、ルート変更の要求があった場合、バス運行管理サーバ13は、リクエストを発行した乗客が利用可能なバスに既に乗車している乗客に生じると予測される不満の情報と、バスの運行を変更することにより生じるコストとの情報を、バス運行管理サーバ13に要求する。バスの運行が変更されたとき、そのバスに乗車している乗客は、自身の降車場所へのバスの到着時刻が遅れれば、不満を抱くことが考えられる。更に、バス運行管理サーバ13は、リクエストを発行した乗客の所持しているポイントの情報を乗客情報管理サーバ123に要求する。

0062

バス運行管理サーバ13は、当該バスに乗車している乗客を把握しており、乗客情報管理サーバ12は、全ての住民の不満度係数を把握している。バス運行管理サーバ13は、乗客情報管理サーバ12と連携して当該バスに乗車している全ての乗客の不満度係数の情報を取得し、その不満度係数に基づいて、全ての乗客に生じる不満の合計値を算出する。例えば、バス運行管理サーバ13は、当該バスの運行を変更したとき当該バスの全ての乗客が不満を表明した場合に生じる不満の合計値を算出すればよい。また、バス運行管理サーバ13は、当該バスの運行を変更することにより生じるコストを算出する。そして、バス運行管理サーバ13は、算出した不満の合計値の情報と算出したコストの情報とを運行計画サーバ11に通知する(13−912)。

0063

また、乗客情報管理サーバ12は、全ての住民の所持しているポイントを把握しているので、その中から、リクエストを発行した乗客の所持しているポイントの情報を運行計画サーバ11に通知する(12−911)。
ここで、図13を用いたリクエスト処理の説明を一旦中断し、本システムにおける「不満」と「ポイント」について説明する。

0064

本実施形態における「不満」はバスの運行あるいは乗車に対する不満である。不満には、上述したように、時間に関する不満、混雑に関する不満、着席に関する不満、騒音に関する不満、場所に関する不満という5つの項目の不満が含まれている。バスの運行あるいは乗車に対する不満は、これら5つの項目の不満の合計である。本実施形態では、時間、混雑、着席、騒音、場所に対する不満と、それらの合計であるバスの運行あるいは乗車に対する不満とは、数値により表現したり演算したりを可能としている。

0065

「不満」は、過去30日間の「不満変数」と「不満度係数」という2つの要素の積の総計である。「不満度係数」は、「不満変数」に対する係数であり、乗客の嗜好によって値が変動する。ただし、「不満度係数」が30日間にわたりに変動しなかった場合、乗客情報管理サーバ12は、「不満度係数」を予め定められた一定値初期化する。

0066

行動心理学において、「不満」は長期間維持しないが、短期間繰り返されることで蓄積し続ける」ことが知られている。また、類似事象である鉄道の運行の例では乗客の不満は2週間程度で忘却されることが経験的に推定されている。上記30日は、一例として、マージンを含めて2週間の約2倍の期間を設定したものである。

0067

一方、本実施形態における「ポイント」は、「不満」に対する代償として、バス会社から与えられる仮想的な債券である。「ポイント」は、上述した「不満」とは異なり、時間の経過で減失することはない。

0068

需要マネジメント型交通サービスシステムは、リクエストを発行した乗客の所持している「ポイント」を、そのリクエストにより提示された希望を実現するか否かを判断する材料として使用する。そして、その希望を実現すると、需要マネジメント型交通サービスシステムは、実現した希望に応じた「ポイント」を消滅あるいは回収する。

0069

このように「ポイント」は、乗客同士の互いに対立する利害を調整する媒体として使用される。「ポイント」の使用の結果として、乗客の「不満」が解消されることもある。

0070

次に本実施形態における不満の算出について説明する。
本実施形態における不満は以下の式(1)により算出される。
Dis=Pt・T+Pi・I+Ps・S+Pa・A+Pl・L …(1)

0071

式(1)において、Disは乗客の不満を示す。不満Disは、直近の過去30日についての不満度係数と不満変数の積の合計である。上記30日は、類似事象である鉄道の運行の例では乗客の不満は2週間程度で忘却されるという経験則に基づき、マージンを含めて2週間の約2倍の期間を設定した例である。

0072

Ptは、Priority of timeの略であり、時間に関する不満に対する係数(不満度係数)である。時間優先が指定されると係数Ptの値が大きくなる。Tは、乗客が停留所等でバスを待った時間を示す不満変数である。Piは、Priority of intervalの略であり、混雑に関する不満に対する係数である。Iは、バスの定員に対する実際に乗車している乗客の人数の割合すなわち乗車率を示す不満変数である。乗車率が低ければ、バス内での乗客同士の間隙が大きくなる。間隙優先が指定されると係数Piの値が大きくなる。Psは、Priority of seatの略であり、着席に関する不満に対する係数である。Sは、乗客がバスに乗っている間に吸われたか否かを示す不満変数である。着席優先が指定されると、係数Psの値が大きくなる。Paは、Priority of atmosphereの略であり、騒音に関する不満に対する係数である。Aは、バス内の騒音レベルを示す不満変数である。静寂優先が指定されると係数Paの値が大きくなる。Plは、Priority of placeの略であり、乗車する場所に関する不満に対する係数である。Lは、出発場所から乗車した場所までの歩行距離を示す不満変数である。場所優先が指定されると係数Plの値が大きくなる。

0073

以下、時間、混雑、着席、騒音、および場所の不満度係数の更に具体的な例について説明する。なお、不満および不満度係数の項目である混雑は、優先付けにおける間隙に対応する。つまり、間隙優先は混雑が低いことを優先させることである。同様に、不満および不満度係数の項目である騒音は優先付けにおける静寂に対応する。

0074

時間、混雑、着席、騒音、および場所の各項目の不満度係数は、初期状態では、全て0.1となる。そして、図12の画面例8−0502にチェックを入れ、優先する項目として指定されると、指定された項目の不満度係数に0.1が加算される。乗客が当該項目を優先するということは、その項目に関する不満は他の項目に関する不満よりも大きく感じることを考慮し、当該項目が乗客の感じた不満の数値に強く反映されるようにしている。ただし、不満度係数の上限は1.0とする。

0075

なお、図12の画面例8−0502において優先する項目のチェックボックスは、いずれか1つだけしかチェックが入れられないものとしてもよいし、複数にチェックが入れられるものとしてもよい。

0076

そして、図12の画面例8−0502から何れの項目に対するチェックも行われない期間が30日間継続したら、全ての項目の不満度係数が0.1に初期化される。いずれかの項目にチェックがされてから30日間が経過する前にいずれかの項目にチェックがされた場合には全ての項目の不満度係数は初期化されない。
なお、ここに示した30日という期間は例示であり、これに限定されることはない。不満度係数の初期化の処理に用いる期間は任意に設定できるものとする。

0077

続いて、時間、混雑、着席、騒音、および場所の各項目の不満変数の具体例について説明する。

0078

上述のように、不満Disは、直近の過去30日間の不満度係数と不満変数の積の合計値である。不満変数T、I、S、A、Lは乗客がバスを利用するごとに取得される。

0079

不満変数Tは、単位が時間である。時間に関する不満は、一例として、乗客が乗車する停留所へのバスの到着が遅れたことにより乗客が待たされた時間で示されるが、ここでは具体例として、その時間に、更に、乗客が乗車したバスが乗客が降車する停留所へ到着するのが遅れた時間と、乗客がバス利用を要求を発行してからその要求に対する応答として乗客が乗車可能なバスの候補が提示されるまでの応答時間とを加えた合計時間を用いるものとする。

0080

不満変数Iは、乗車率であり、パーセント正規化した単位を用いる。乗車率が100%であるとき不満変数Iを0とし、乗車率が150%であるとき不満変数Iを1とする。乗車率が100%未満であるときの不満変数Iを0とする。乗車率が150%以上であるときの不満変数Iを1とする。乗車率が100%から150%の間は、不満変数Iは乗車率の変化に対して一定の度合いで変化する線形の値であるとする。

0081

不満変数Sは、着席できたか否かを示す値であり、着席できたら値は0とし、着席できなかったら値は1とする。

0082

不満変数Aは、バス内の騒音レベルである。例えば、バス車内に音量計測センサを設置し、その計測値を正規化して不満変数Aとしてもよい。あるいは、バス車内は騒音レベルがどの程度高くなる状況であるかを数値で表し、その数値を正規化して不満変数Aとしてもよい。例えば、対象の乗客が乗車したバスの同乗者における10代の乗客の人数を用いてもよい。10才代の同乗者が5人であるとき不満変数Aを0とし、10才代の同乗者が10人であるとき不満変数Aを1とし、10才代の同乗者が5人から10人の間であれば、人数の変化に対して一定の度合いで変化する線形の値であるとする。そして、10才代の同乗者が5人未満であれば不満変数Aは0とし、10才代の同乗者が10人以上であれば不満変数を1とする。

0083

不満変数Lは、付近ピックアップ要求が採用されたか否かを示す値であり、付近ピックアップ要求が採用されたのであれば不満変数Lは0とし、ある場所を指定した付近ピックアップ要求が採用されず基本経路上の停留所での乗車が指示されたのであれば不満変数Lは1とする。付近ピックアップ要求で指定した場所と、基本路線上の停留所との間にある場所での乗車が指示されたのであれば、不満変数Lは、乗車が指示された場所と付近ピックアップ要求で指定した場所との距離と、乗車が指示された場所と基本路線上の停留所との距離との割合に応じて0と1の間の値とする。
次に、本実施形態における「ポイント」について説明する。

0084

本実施形態のポイントは以下に示す式(2)および式(3)により算出することができる。式(2)は、需要マネジメント型交通サービスシステムの運営者(バス会社)がバスの乗客にポイントを付与するときの計算式であり、式(3)は、バス会社がポイントを回収するときの計算式である。
Point+=Dis (降車時) …(2)
Point−=Σ(バスの乗客のDisの予測値) (ルート確定時) …(3)

0085

リクエストを発行した乗客のポイントは、そのリクエストに基づいてバスの運行経路が確定した時点で、式(3)に示されているようにバス会社により回収される。また、リクエストによりバスの運行経路が変更され、他の乗客に不満が生じる場合にその乗客に付与されるポイントは、式(2)により算出される。

0086

ポイントは0以上の数値を取り、また上述した不満とは異なり所定期間の経過により焼失することはない。

0087

以上説明した「不満」と「ポイント」についてまとめると以下のようなことが言える。
<1>不満とポイントは同量とならない。
<2>ポイントは不満を参照として生成されるが、基本的に両者は独立した値である。
<3>不満は、短期間に繰替えさせることで増大するが、時間とともに減失していく。

0088

ここで図13の説明に戻る。

0089

運行計画サーバ11は、出発場所から基本経路上の停留所までの間で付近ピックアップが可能となる条件を満たすバスおよび乗車場所を抽出し、リクエストの発行した乗客の乗車するバスの候補を選出する(11−916)。

0090

運行計画サーバ11は、ステップ11−915あるいはステップ11−916において、リクエストを発行した乗客が乗車するバスの候補を選出する。このとき、運行計画サーバ11は、乗車を希望しリクエストを発行した乗客が所持しているポイントと、その時点で、リクエストに基づいてバスの運行を変更した場合に生じることが予測されるバスの乗客の全員の不満(Σ(バスの乗客のDisの予測値))とを比較する。リクエストを発行した乗客が所持しているポイントの方がバスの乗客の全員の予測易される不満よりも大きければ、リクエストに基づくバスの運行の変更が可能と判断され、リクエストを発行した乗客による選択を経て実行が決定される。バスの運行の変更が決定されると、リクエストを発行した乗客からポイントが回収される。この場合も、バスの運行が変更されたか否かとは関係なく、バスの乗客における不満は計算され、上述した方法で乗客にポイントが付与される。

0091

逆に、乗客全員の予測される不満の合計値が、リクエストを発行した乗客の所持しているポイントよりも大きい場合、リクエストに基づくバスの運行の変更は実現されず、リクエストを発行した乗客からポイントは回収されない。ただし、この場合も、バスに乗車している乗客の不満は、バスの運行が変更されなかったこととは関係なく計算され、必要に応じて乗客にポイントが付与される。

0092

なお、運行計画サーバ11は、リクエストを発行した乗客が乗車するバスおよび乗車場所の候補を選出するとき、過去のリクエストの発行および消化の履歴に基づいてこれから発生が予想されるリクエストを、乱数を用いて疑似的に発生させ、予想されるリクエストを、候補の選出の際に考慮することにしてもよい。

0093

また、運行計画サーバ11は、乗車を希望しリクエストを発行した乗客が所持しているポイントと、予測されるバスの乗客の全員の不満との比較だけでなく、リクエストに基づいてバスの運行を変更した場合に生じる追加コストが所定の閾値以下となるように候補を選出することにしてもよい。運行計画サーバ11は、ポイントおよび不満による条件、あるいは更に追加コストによる条件が満たされるのであれば、複数の候補を選出してもよい。

0094

リクエストを発行した乗客の乗客情報端末15は、運行計画サーバ11で選出された候補を表示し、乗客に選択を促す(15−912)。乗車を希望しリクエストを発行した乗客が、例えば、乗客情報端末15に表示された候補の中からいずれか1つを選択すると、乗客情報端末15は選択された候補を示す情報を運行計画サーバ11に通知する(15−913)。

0095

運行計画サーバ11は、乗客情報端末15から通知された候補のバスと乗車場所とに基づいてバスの運行を変更し、それに伴ってバスの運行ダイヤ更新する(11−917)。そして、運行計画サーバ11は、新たなダイヤをバス運行管理サーバ13およびバス運行指示端末14に通知する。バス運行管理サーバ13は、運行計画サーバ11から通知された新しいダイヤをデータベースに記録する(13−913)。また、バス運行指示端末14は、運行計画サーバ11から通知された新しいダイヤを表示する(14−911)。

0096

図14は、需要マネジメント型交通サービスシステムが乗客からアンケートへの回答を取得する処理のシーケンス図である。需要マネジメント型交通サービスシステムは乗客の降車時にアンケートへの回答を取得する。

0097

各バスのバス運行指示端末14は、当該バスが運行し停留場所に停車すると、その停留場所に停車した旨をバス運行管理サーバ13と運行計画サーバ11に報告する(14−1011)。停留場所は、予め定められた停留所であっても良いし、乗客からのリクエストにより停車することになった停留所あるいは停留所でない場所であってもよい。
バス運行管理サーバ13は、停車の報告を受信すると、当該報告を走行ログテーブル13−45に付随する情報として記録してもよい(13−1011)。

0098

運行計画サーバ11は、停車の報告を受信すると、当該報告に基づき停車するバスと停留場所とを確認し(11−1011)、リクエスト発行情報12−42から、当該バスから当該停留場所で降車する乗客を抽出する(11−1012)。更に、運行計画サーバ11は、抽出した乗客の乗客情報端末15にアンケートを送信する(11−1013)。

0099

乗客情報端末15は、アンケートを受信して画面に表示する(15−1011)。本実施形態におけるアンケートは図12の画面例8−0503のように表示される。本実施形態では、バスの利用に満足したか否かを問う単純なアンケートが用いられている。乗客は、アンケートへの回答として満足または不満と回答するかあるいは無回答とすることができる。乗客情報端末15は、アンケートに対して乗客が入力した回答を示すアンケート情報を乗客情報管理サーバ12に送信する(15−1012)。

0100

乗客情報管理サーバ12は、アンケート情報を受信すると(12−1011)、そのアンケート情報に基づいて、当該乗客の不満の値とポイントとを更新する(12−1012)。回答が不満であったら、乗客情報管理サーバ12は、上述した式(1)により不満の値を算出し、上述した式(2)により、その不満の値をポイントに加算する。そして、乗客情報管理サーバ12は、その更新結果を住民パラメータテーブル12−41に反映させる(12−1013)。

0101

バスが終着停留所に到着すると、当該バスのバス運行指示端末14は、終着停留所に停車した旨をバス運行管理サーバ13と運行計画サーバ11に報告する(14−1012)。ここでは終着停留所は乗客が降車する停留所ではないものとする。

0102

バス運行管理サーバ13は、停車の報告を受信すると、当該報告に基づいて走行ログテーブル13−45を更新する(13−1011)。運行計画サーバ11は、停車の報告を受信すると、当該報告に基づき停車するバスと停留場所とを確認する(11−1014)。

0103

本実施形態による運行計画サーバ11は、住民の不満を様々な条件で集計し、表示することができる。一例として、運行計画サーバ11は、エリア毎に、時間、混雑、着席、および騒音の項目毎にエリア毎の不満の合計値を算出し、グラフにして表示する。これにより、バス会社は、乗客を含む住民がどのようなことに不満を持っているかを容易に知ることができ、バスの運行やサービスの改善に役立てることができる。

0104

運行計画サーバ11は、例えば、以下に示す式(4)により、エリア別満足度平均を算出するとともに、各項目の不満の合計値あるいは不満の一人当たりの平均値をも算出する。

0105

0106

式(4)において、Aはエリアである。Pは不満度係数である。Vは不満変数である。Zは不満の項目であり、時間、混雑、着席、騒音、場所の各項目を含む。uはエリアに属する住民である。全住民数はエリアの住民の総数である。

0107

また、運行計画サーバ11は、変形例として、バスの乗客の不満を降車時に取得するだけでなく、更に、バスの乗客の停留所での待ち時間に関する不満を乗車時に取得し、住民からバスの乗車の有無に関わらず不満を適時に取得してもよい。そして、運行計画サーバ11は、バス待ち客の不満、バスの乗車の有無に関わらない住民の不満、バスの乗客の不満をグラフにして表示してもよい。

0108

図15は、不満を集計した結果を表示したGUI(Graphical User Interface)の画面例を示す図である。図15には複数のグラフ11−1101、11−1102、11−1103を含む画面例11−110が示されている。図15のグラフ11−1101、1102、1103は、中央部分を中心から上下左右に4つの領域に区切り、それぞれを時間、騒音、着席、混雑という項目が割り当てられている。各項目の領域には、中心付近扇形欠けた扇形の領域が、その半径により不満の度合いを示すように描かれる。

0109

グラフ11−1102には、あるエリアに関わる(バスの乗車の有無の両方を含む)住民の各項目の不満の合計値が示されている。グラフ11−1101には、バスを利用した乗客のバス待ち時の各項目の不満の合計値が示されている。グラフ11−1103には、バスを利用した乗客の各項目の不満の合計値が示されている。ここでは不満の合計値をグラフ化する例を示したが、不満の一人当たりの平均値をグラフ化してもよい。

0110

また、本実施形態の運行計画サーバ11は、全体サービスエリアに含まれる各エリアにおけるバスを利用した乗客の不満をエリア毎に表示することができる。

0111

図16は、各エリアの不満を集計した結果をエリア毎に表示したGUIの画面例を示す図である。ここでは図10に示した全体サービスエリアには、図16に示すように9つのエリアがあるものとする。

0112

図16には、全体サービスエリアの地図上に各エリアを区分けする境界線が引かれ、各エリアの領域の濃淡により不満の度合いを示す画面例が示されている。ここでは濃淡が濃いほど不満が高いことを意味している。

0113

なお、乗客の不満がどのエリアにおける不満かを決める方法として、例えば、そのエリア内で乗車した乗客の不満はそのエリアにおける不満とすることにしてもよい。あるいは、そのエリア内で降車した乗客の不満はそのエリアにおける不満とすることにしてもよい。

0114

また、図16では、全体サービスエリアに9つのエリアが属する例を示しているが、全体サービスエリアに属するエリア数に上限はない。

0115

また、図16では、全体サービスエリアに属する各エリアの形状が矩形である例を示しているが、エリアの形状は特に限定されることはない。エリアが矩形や正六角形など等しい形状であっても良いし、エリア毎に異なる形状であってもよい。

0116

また、本実施形態による需要マネジメント型交通サービスシステムは、住民から収集した不満の情報に基づいて、新たなバスの運行計画を立案することができる。

0117

図17は、バス運行計画を立案する処理を示すシーケンス図である。本処理はバスを運行する営業時間が終了した後にバッチ処理として実施してもよい。

0118

乗客情報管理サーバ12は、各エリアの各項目の不満を算出する(12−1311)。このとき、乗客情報管理サーバ12は、図4に示したリクエスト消化ログ12−43から乗客のバスへの乗車の情報から、各エリアと乗客とを対応付け、各エリアに対応する乗客の不満をそのエリアにおける不満とする。乗客が乗車した場所があるエリア内であれば、その乗客が降車時に取得された不満はそのエリアにおける不満として扱う。

0119

そして、乗客情報管理サーバ12は、住民パラメータ12−41を参照して住民の不満の値(不満度)と不満度係数とを取得し、エリア毎の乗客の不満の値の総和を算出する。更に、乗客情報管理サーバ12は、エリアについて算出した不満の値の総和を、そのエリアの全住民数で除算することで、そのエリアに関わった乗客の不満の値の総和の平均値を算出する。

0120

なお、ここでは、乗客がバスへ乗車した場所の属するエリアをその乗客の不満を集計するエリアとするものとしているが、これに限定されることはない。他の例として、乗客がバスを降車した場所の属するエリアをその乗客の不満を集計するエリアとしてもよい。また、乗客の住所の属するエリアをその乗客の不満を集計するエリアとしてもよい。

0121

また、ここでは、住民から収集した不満の値を基にバスの運行計画を立案することにしているが、必ずしも不満の値を基にしなくてもよい。他の例として、不満の値の代わりにポイントを用い、住民の所持しているポイントを基にバスの運行計画を立案することにしてもよい。

0122

再び図17を参照すると、乗客情報管理サーバ12は、各エリアの不満の性質分析する(12−1312)。具体的には、乗客情報管理サーバ12は、各エリアにおける、時間、混雑、着席、騒音、および場所という各項目(不満の種類)の不満をそれぞれ算出し、エリアの住民の数および属性と関連付ける。各エリアの各項目の不満と各エリアの住民の数および属性との関連付けの手法は特に限定されないが、例えば重回帰分析あるいはベイズ推定法などを利用して相関を算出することにしても良い。

0123

次に、乗客情報管理サーバ12は、各エリア間における不満の性質を分析する(12−1313)。具体的には、乗客情報管理サーバ12は、2つのエリアの不満の相関を算出する。図16に示した全体サービスエリアおよびエリアの例では、9つのエリアがあるので、エリアの組合せは36個となり、その36個の組合せのそれぞれについてエリア間の相関を算出する。
不満に強い相関のある2つのエリアには共通する不満の要素があると推定される。

0124

次に、乗客情報管理サーバ12は、エリア間の不満の相関に基づいて、新規に設けるバス路線の案を作成する(12−1314)。具体的には、乗客情報管理サーバ12は、相関の強いエリアの間の乗客のバスの利用のうち、その相関を強くしているバスの利用を特定する。更に、乗客情報管理サーバ12は、その相関を強くしているバスの利用における乗車時刻および乗車場所と降車時刻および降車場所を抽出する。更に、乗客情報管理サーバ12は、その乗車時刻および降車時刻を含む時間帯における、その乗車場所から降車場所へのバスの不足あるいは欠如が不満要因であると推定し、その時間帯にその経路を運行するバス路線を新規に設けることを提案する。例えば、15:00〜16:00の時間帯における、あるエリアからショッピングモールへのバスが不満要因と推定されたのであれば、乗客情報管理サーバ12は、そのエリアの代表地点からショッピングモールまで運行する直通バスを新路線として提案すればよい。
乗客情報管理サーバ12は、提案する新路線の情報をバス運行管理サーバ13に通知する。

0125

バス運行管理サーバ13は、提案された新路線の運行に要するコストを算出する(13−1311)。例えば新路線におけるバスの走行距離からコストを算出してもよい。

0126

更に、バス運行管理サーバ13は、算出したコストを基に、新路線の採用の可否を判断する(13−1312)。例えば、コストが所定の閾値以下であれば採用可能と判断することにしてもよい。

0127

新路線が採用できないものであれば、バス運行管理サーバ13は、その旨を乗客情報管理サーバ12に通知し、乗客情報管理サーバ12は、その通知を受けて処理を終了する(12−1315)。

0128

一方、新路線が採用できるものであれば、バス運行管理サーバ13は、その旨を乗客情報管理サーバ12に通知するとともに、新路線を含むバスの運行ダイヤを作成する。新路線が採用できる旨の通知を受けた乗客情報管理サーバ12は、住民へ新路線の導入を告知する情報を作成し、乗客情報端末15に送信する(12−1316)。告知の情報を受信した乗客情報端末15は、その情報に基づいて、新路線の導入を告知する広告を表示する(15−1311)。

0129

また、バス運行管理サーバ13は、作成した運行ダイヤと共に、新路線の運行計画をバス運行指示端末14に通知する(13−1313)。通知を受けたバス運行指示端末14は、運行計画を受理し(14−1311)、新たな運行ダイヤによるバスの運行の指示を開始する。

0130

上記の実施形態の一部又は全部は以下のような事項を含んでいる。ただし、本実施形態の開示が以下の事項に限定されるものではない。

0131

移動リソース(バス)を運行して利用者(住民、乗客)を移動させるサービスを提供する移動サービスシステムは、利用者に関する第1データベース(住民データベース)を記憶し、利用者の要求を管理する第1管理装置(乗客情報管理サーバ)と、移動リソースに関する第2データベース(バスデータベース)を記憶し、移動リソースの運行の状態を管理する第2管理装置(バス運行管理サーバ)と、第1管理装置および第2管理装置と連携して、移動リソースの運行を変更する第3管理装置(運行計画サーバ)と、を有する。第3管理装置は、利用者に発生する不満を数値で取得し、第1管理装置は、不満に応じて、移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを第1データベースに記録し、第3管理装置は、利用者から要求を受けて、第1データベースに管理されているその利用者に付与されているポイントと引き換えに、要求と第2データベースに管理されている移動リソースの運行の状態とに基づき、移動リソースの運行の計画を変更する。

0132

これによれば、利用者の不満の度合いを定量化し、その不満に応じて利用者にポイントを付与し、ポイントで移動リソースの運用の変更の要求を実現させるので、各利用者の不満の度合いを移動リソースの運用に反映させることができる。その結果、複数の利用者の不満をバランスさせ、利用者全体の満足の度合いを向上させるように移動リソースを運用することが可能となる。

0133

また、第3管理装置は、移動リソースの運行の計画を変更したとすると、移動リソースの他の利用者に発生する不満を推定し、他の利用者の不満と、要求を発した利用者のポイントとに基づいて、移動リソースの運行の計画の変更が可能であるか否か判定する。これによれば、利用者が不満に応じて付与されたポイントを利用して移動リソースの運行を変更するとき、その利用者が所持しているポイントと、その変更により他の利用者が抱くであろう不満と、に基づいて、その要求を実施できるか否か判定するので、利用者間の不満をバランスさせることができる。

0134

また、第3管理装置は、移動リソースの運行を計画を変更すると、要求を発した利用者のポイントから、他の利用者の不満に相当する分を減算する。これによれば、利用者の要求で移動リソースの運行を計画を変更すると、その要求を発した利用者のポイントから、他の利用者の不満の度合いに相当する分を減算するので、利用者の不満をバランスさせながら、利用者の要求に応じた移動リソースの運行を調整することができる。

0135

また、第3管理装置は、不満の対象となる複数のサービス品質項目について、利用者による重視の度合いを係数とし、サービス品質項目についての事象の計測値を変数とし、サービス品質項目毎の係数と変数の積を複数のサービス品質項目について合計し、合計値を利用者の不満の値とする。これによれば、複数のサービス品質項目に分けて重視の度合いを考慮して利用者の不満の値を算出するので、サービスを多面的に捉えて利用者の項目毎の不満を的確に移動リソースの運用に反映させることが可能となる。

0136

また、第3管理装置は、利用者からの要求にてサービス品質項目に対する嗜好の情報を取得して係数を更新する。これによれば、利用者が行った要求にて利用者のサービス品質項目に関する嗜好を取得するので、利用者による重視の度合いを反映させるために、利用者が別途嗜好を入力する手間を低減することができる。

0137

また、第3管理装置は、利用者が移動リソースにより移動したときに利用者から不満の有無を知得し、不満が有りであれば、事象の計測値に基づいて第1管理装置に利用者の不満の値を更新させる。これによれば、利用者が移動したときに不満の発生を取得するので、利用者にて生じた不満を的確に把握し、不満の度合いとして算出することができる。

0138

また、第3管理装置は、他の利用者の不満と、要求を発した利用者のポイントとに基づき、移動リソースの運行の計画の可能な変更を抽出し、要求を発した利用者に提示し、利用者の選択した変更を実施する。これによれば、複数の変更の案を利用者に提示し、選択された変更を実施するので、利用者は要求を満たす中で、より好ましいを変更の仕方を選択することができ、利用者の利便性がより向上する。

0139

また、第3管理装置は、サービスが提供されるサービスエリアを区分けした複数のエリアのそれぞれについて不満の値を集計し、集計結果を表示する。これによれば、エリア毎に不満を集計し表示するので、エリア毎の不満の様子を視認し、移動リソースが適切に提供されているかどうか確認することができる。

0140

また、第1管理装置は、集計結果に基づいて、エリアにおける不満の原因を解析し、原因を低減するように、エリアにおける移動リソースの運行の計画を提案する。これによれば、エリア毎の不満の集計結果に基づき不満の原因を解析し、原因を低減するような計画を提案するので、エリア毎の利用者の不満の状況に応じた移動リソースの運行計画の見直しが可能とある。

0141

また、サービス品質項目には、移動リソースへ登場する場所、移動リソースを利用するために要する時間、移動リソース内の混雑、移動リソースにおける着席可否、または移動リソース内の騒音の少くとも1つが含まれる。これによれば、移動手段の利用に際して感じる不満を、移動リソースへ登場する場所、移動リソースを利用するために要する時間、移動リソース内の混雑、移動リソースにおける着席可否、または移動リソース内の騒音といったパラメータで計測するので、利用者の不満を適切に不満の値に反映させることができる。

0142

また、第1管理装置は、第1データベースにて、利用者毎の不満の値を管理し、所定時間継続して新たな不満が発生しなかった利用者の不満の値を所定の初期値にする。これによれば、行動心理学における不満の継続性適合した演算により、利用者の感じている不満を適切に数値で表現することができる。

0143

11…運行計画サーバ、12…乗客情報管理サーバ、13…バス運行管理サーバ、14…バス運行指示端末、15…乗客情報端末、1−01…CPU、1−02…メモリ、1−03…通信NIC、1−04…ハードディスクドライブ、1−05…入出力コントローラ、1−06…モニタコントローラ、1−07…バス、1−08…GPSモジュール、1−11…キーボード、1−12…マウス、1−13…ディスプレイ、1−14…ICカードリーダーモジュール、1−15…タッチパネル、11−40…集計データベース、11−41…集計結果テーブル、11−42…エリア別集計結果テーブル、11−43…エリア定義テーブル、11−44…GIS節点情報テーブル、11−45…GIS節点情報、12−40…住民データベース、12−41…住民パラメータテーブル、12−42…リクエスト発行情報テーブル、12−43…リクエスト消化ログテーブル、13−40…バスデータベース、13−41…バス車体パラメータテーブル、13−42…バス折返し発車予定時刻テーブル、13−43…バス基本経路の移動順序−停留所対応表テーブル、13−44…基本経路上の停留所テーブル、13−45…バス走行ログテーブル

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士通株式会社の「 物体情報生成装置及び物体情報生成プログラム」が 公開されました。( 2021/01/07)

    【課題・解決手段】移動体に搭載される単眼カメラに基づいて、第1時点及び前記第1時点よりも前の時点を含む複数の時点での物体の第1個所の位置を表す測定値を算出する測定値算出部と、前記第1個所の位置の採用値... 詳細

  • 日産自動車株式会社の「 駐車制御方法及び駐車制御装置」が 公開されました。( 2021/01/07)

    【課題・解決手段】車両の外の操作者Mから取得した操作指令に基づき、車両を目標駐車位置に移動させる駐車制御を行い、目標駐車位置への駐車制御を中断して車両が目標駐車位置から離れる場合、少なくとも車両の一部... 詳細

  • ヤマハ発動機株式会社の「 オンデマンド既定ルート自動走行車両」が 公開されました。( 2021/01/07)

    【課題・解決手段】オンデマンド既定ルート自動走行車両100の利用要求を行った利用者701の待ち時間を短縮しつつ、エネルギー搭載量を減らして車両の設計自由度を向上させる。オンデマンド既定ルート自動走行車... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ