JP2023026295A - 公共輸送システムの制御装置、公共輸送システム、適応出発時間決定方法およびコンピュータプログラム製品 - Google Patents

Abstract

【課題】公共輸送システムの制御の自動化レベルを改善する。【解決手段】輸送サービスを使用する乗客の移動履歴データを格納するように構成されたデータベース１１０５と、移動計画１２０１を輸送サービスを使用している乗客の複数の携帯デバイス１２００それぞれから受信し乗換え需要値として決定するように構成された乗換え需要予測部１１０１と、第１の輸送サービスと第２の輸送サービスとの間で乗り換える駅における第１の輸送サービスの輸送車両の到着時間を予測するように構成された到着時間予測部１１０２と、予測到着時間に基づいて駅における輸送車両の巡航速度および／または第２の輸送サービスの１つもしくは複数のドウェル時間を決定するように構成されたドウェル時間分析部１１０３とを有する。【選択図】図１

Description

本発明は、公共輸送システムの制御装置、公共輸送システム、適応出発時間決定方法およびコンピュータプログラム製品に関する。

従来技術として特許文献１は、複数の車両の位置を取得する車両位置取得部と、渋滞情報に基づいて、存在する複数の車両の密度を増加させる基準である駅を識別し、基準である駅の手前にある各駅における、駅の手前にある駅に停車している複数の車両に関する待機時間を設定する、間隔調節部と、待機時間に基づいて、駅の手前にある各駅からの複数の車両の出発時間を調節する出発決定部と、を備える、複数の車両の運行を管理する運行管理デバイスについて記載している。

上述の従来技術によるシステムは更に、客車の位置情報を受信し、その情報を車両位置取得部に伝送する。システムは次に、輸送サービスの走行路線における渋滞を排除するために、列車の間隔を調節する。

ＵＳ２０１５／０３６０７０６

しかしながら、特許文献１のシステムは、輸送システムにおける遅延、渋滞などが、上記輸送システムを使用する乗客に与える影響、第１の輸送サービスの輸送車両が第１と第２の輸送サービスの間の乗換え駅に遅れて到着した場合の、乗換え接続を介して第１の輸送サービスに連結された第２の輸送サービスの乗客および輸送車両、または第２の輸送システムの輸送車両の作業負荷の管理に対する影響を考慮していない。

更に、特許文献１には、輸送システムの駅における乗換え需要を自動的に決定するため、また到着時間をリアルタイムで自動的に提供するために、（リアルタイムの）乗客データを使用することは記載されていない。

本発明の目的は、公共輸送システムの制御の自動化レベルを改善することにある。

本発明に一態様の公共輸送システムの制御装置は、輸送サービスを使用する乗客の移動履歴データを格納するように構成されたデータベースと、移動計画を前記輸送サービスを使用している前記乗客の複数の携帯デバイスのそれぞれから受信し、受信した前記移動計画および前記移動履歴データに基づいて、乗換え需要値として第１の輸送サービスと第２の輸送サービスの間で乗り換えようとしている前記乗客の数を決定するように構成された乗換え需要予測部と、前記第１の輸送サービスと前記第２の輸送サービスとの間で乗り換える駅における前記第１の輸送サービスの輸送車両の到着時間を予測するように構成された到着時間予測部と、前記乗換え需要値を前記乗換え需要予測部から第１の輸送車両の前記予測到着時間を前記到着時間予測部から受信し、前記予測到着時間に基づいて、駅における前記輸送車両の巡航速度および前記第２の輸送サービスの少なくとも１つのドウェル時間を決定するように構成されたドウェル時間分析部とを有する。

本発明に一態様によれば、公共輸送システムの制御の自動化レベルを改善することができる。。

装置を使用して出発時間を決定するシステムを示す概略図である。 図１に示される装置をより詳細な形で示す図である。 乗客の携帯デバイスの画面画像を示す図である。 スマートカードデータから移動需要を予測するトリップチェーンの構築を説明するフローチャートである。 スマートカードデータから移動需要を予測するアルゴリズムを示す図である。 スマートカード使用の記録を示す例示的な表である。 公共輸送路線の座標を示す例示的な表である。 バスおよび列車の到着時間記録を示す例示的な表である。 トリップチェーン構築の結果を示す例示的な表である。 移動表の構築の結果を示す例示的な表である。 ｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングデータから移動需要を予測するアルゴリズムを示す図である。 ｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングから追跡した移動経路を示す例示的な表である。 乗客座標と輸送サービス路線の座標との整合の結果を示す例示的な表である。 移動需要予測のプロセスを説明するフローチャートである。 気象履歴データを示す例示的な表である。 駅間の地理的距離を示す例示的な表である。 乗換え需要予測の結果を示す例示的な表である。 到着時間予測のプロセスを説明するフローチャートである。 輸送サービス区間に対応する地理的距離を示す例示的な表である。 複数の輸送サービス区間の抽出移動時間を示す例示的な表である。 所与の輸送サービス区間の移動時間を示す例示的な表である。 輸送サービス路線の後続の停留所における輸送車両の予測到着時間を示す例示的な表である。 推奨ドウェル時間および／または巡航速度実現のプロセスを説明するフローチャートである。

本発明の実施形態は、特に、公共輸送システムの制御を改善する装置に関する。対応するシステム、方法、およびコンピュータプログラム製品も提供される。

輸送システムの制御は、特に、人間のオペレータがそれに基づいて輸送システムを制御することができる制御情報を、公共輸送システムの人間のオペレータに自動的に提供することによって、またはオペレータが、自動的に生成された制御情報に基づいて輸送システムを制御する別のコンピュータベースのエンティティ／ユニットである輸送システムの自動制御を可能にすることによって改善される。

自動的に提供される制御情報は、特に、輸送サービスを使用する乗客からの（リアルタイム）移動データに基づいて動的に決定することができる、輸送システムの車両のドウェル時間および／または巡航速度に関する。移動データは、乗換え需要予測部および到着時間予測部によって処理することができ、これは機械学習／人工知能部によって可能にされてもよい。

それに対応して、更に自動化された、より信頼性の高い公共輸送向けのシステムを提供することができる。更に、上記システムが備える輸送車両の技術的な輸送能力を、より効率的に使用できるようにすることができる。制御システムの相乗的な改善に役立つ更なる態様については、以下から明白となるであろう。

本発明の目的は、公共輸送システムの制御の観点で更に改善された、装置、それに対応するシステム、方法、およびコンピュータプログラム製品を提供することである。

特に、１つの目的は、公共輸送システムの制御の自動化レベルを改善することである。より具体的には、また特に、上記輸送システムの輸送車両のドウェル時間および／または巡航速度に関する判断は、更に自動化できるようにすべきであり、ならびに輸送システムの駅における乗換え需要およびリアルタイムの到着時間の決定は自動化すべきである。

好ましくは、これは、パラメータおよび値をそこから導き出すことができる、乗客の履歴および／またはリアルタイムの移動データを使用することによって可能にすべきである。更に、コントローラ（人間またはコンピュータベース）が、輸送サービスのドウェル時間および／または走行速度の適応に関して、より良好な判断を行うことを可能にすべきである。これは添付の特許請求の範囲の主題によって解決される。

本発明の公共輸送システムの制御装置は、輸送サービスを使用する乗客の移動履歴データを格納するように構成されたデータベース（１１０５）と、移動計画（１２０１）を前記輸送サービスを使用している前記乗客の複数の携帯デバイス（１２００）それぞれから受信し、受信した前記移動計画（１２０１）および前記移動履歴データに基づいて、乗換え需要値として、第１と第２の輸送サービスの間で乗り換えようとしている前記乗客の数を決定するように構成された、乗換え需要予測部（１１０１）と、前記第１の輸送サービスと前記第２の輸送サービスとの間で乗り換える駅における前記第１の輸送サービスの輸送車両の到着時間を予測するように構成された、到着時間予測部（１１０２）と、前記乗換え需要値を前記乗換え需要予測部（１１０２）から、１つまたは複数の第１の輸送車両の前記予測到着時間を前記到着時間予測部（１１０２）から受信し、前記予測到着時間に基づいて、駅における前記輸送車両の巡航速度および／または前記第２の輸送サービスの１つもしくは複数のドウェル時間を決定するように構成された、ドウェル時間分析部（１１０３）とを有する。

第１の態様によれば、公共輸送システムを制御する装置が提案される。装置は、好ましくは、定置型のバックエンドサーバシステムに配置される。サーバは、無線データ接続を介して乗客の携帯デバイスに接続される。携帯デバイスは、スマートフォン、タブレット、ラップトップ、スマートウォッチなどであってもよい。携帯デバイスは更に、関連情報を携帯デバイスのユーザに対して表示する、グラフィカルユーザインターフェースを有する。

装置は、輸送サービスを使用する乗客の移動履歴データを格納するように構成されてもよい、データベースを含む。データ格納部自体は、いずれの種類のハードウェアメモリデバイスであってもよい。データベースの数は１つまたは複数であってもよく、異なる種類のデータが格納され、１つまたは複数のデータベースにわたって分配されてもよい。

輸送サービスという用語は、好ましくは、列車、バス、鉄道駅、バスステーション、列車路線、バス路線、および／またはその他を含む、公共輸送サービスとして理解されるものとする。換言すれば、輸送サービスという用語は、以下で乗客と称する人が使用する公共輸送向けのシステムの一部である、輸送インフラストラクチャおよび輸送車両を指すのに使用されることがある。公共輸送システムは複数の輸送サービスを備えてもよい。

輸送サービスを使用する乗客の移動履歴データは、乗客が輸送のために輸送サービスを使用するイベントの蓄積された履歴を含んでもよい。それに対応して、データは、それぞれの乗客を識別するとともに、ｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングから得られる、使用された輸送サービスまたは記録または追跡した移動経路の詳細を識別する、乗客のスマートカード使用の記録を含んでもよい。スマートカードは、例えば、ＮＦＣ技術に基づいた、電子移動サービスチケットであってもよい。移動履歴データは、例えば、乗客のＩＤ、発着駅、日時スタンプ、および／または輸送サービスの使用中の地理的位置を含んでもよい。データは、乗客の携帯ユーザデバイス、スマートチケットなどから生じるものであってもよい。

装置は更に、輸送サービスを使用する乗客の複数の携帯デバイスから移動計画を受信し、受信した移動計画およびデータベースに格納された移動履歴データに基づいて、乗換え需要値として、第１と第２の輸送サービスの間で乗り換える（計画／予定の）乗客の数を決定するように構成された、乗換え需要予測部を備える。

ここで、移動計画は、好ましくは、輸送システムを使用している間の乗客の旅程の出発地および目的地に関する情報に対応するものと理解されるものとする。移動計画は、乗客の旅程の始点および乗客の旅程の終点に関する情報を含んでもよい。好ましくは、移動計画の始点および終点は、バスステーションまたは鉄道駅など、輸送システムの駅を示す。更に、移動計画は、乗客の旅程の始点を指す第１の輸送サービスの駅と、乗客の旅程の終点を指す第２の輸送サービスの駅との間にある乗換え駅に関する情報を含んでもよい。移動計画は、ユーザが旅程を開始する時またはその前に、ユーザの携帯デバイスで動作するソフトウェアアプリケーションにユーザによって入力されてもよい。

乗換え需要値という用語は、好ましくは、２つの異なる輸送サービス間での乗換えが可能である接続可能な駅ごとの、乗客の数として理解されるべきである。換言すれば、乗客の旅程が、２つ以上の異なる輸送サービスの使用を必要とする場合、異なる輸送機関間での乗換え需要が作成される。複数の乗客が、１つの輸送サービスから別のものへの乗換えを必要とすることがあるので、それらの乗客の数に対応する乗換え需要値を決定することができる。

日時スタンプおよび乗客の位置／所在地情報が、携帯デバイスによって決定されてもよい。携帯デバイスは、位置情報データを受信して、受信した情報に基づいて乗客の所在地情報を決定するように構成された、位置決定部を備える。受信した情報は、全地球衛星航法システムの一部である１つまたは複数の衛星によって伝送される、乗客が使用している携帯デバイスの緯度、経度、および高度に関するデータを含む。これにより、位置情報データを高い信頼性で獲得することが容易になるとともに、衛星航法システムの単方向信号送信により、データトラフィックが低減される。

より好ましくは、全地球衛星航法システムは、単方向でデータを送信して位置決定してもよい、ＧＰＳ、ガリレオ、ＧＬＯＮＡＳＳなどの主要な確立された全地球衛星航法システムの１つであってもよい。また、所在地情報は、携帯デバイスの内部クロックによって提供される、位置決定の各サンプリング地点におけるタイムスタンプで補完される。携帯デバイスの内部クロックは、セルラー電話ネットワークまたはＷｉ－Ｆｉ接続などの無線通信を介して携帯デバイスが受信する、外部時間信号と同期されてもよい。更に、所在地情報およびタイムスタンプはまた、乗客の旅程の間追跡することができるｂｅ－ｉｎ－ｂｅ－ｏｕｔチケットから、またはスマートチケットの使用から、例えば駅の入口もしくは出口でチケットがスワイプされたときに、提供されてもよい。

更に、装置の到着時間予測部は、第１の輸送サービスと第２の輸送サービスとの間で乗り換える駅における、第１の輸送サービスの輸送車両の到着時間を予測するように構成される。

更に、装置は、乗換え需要値を乗換え需要予測部から、１つまたは複数の第１の輸送車両の予測到着時間を到着時間予測部から受信し、輸送車両の予測到着時間および／または巡航速度に基づいて、駅における第２の輸送サービスの１つまたは複数のドウェル時間を決定するように構成された、ドウェル時間分析部を備えてもよい。

分析のために考慮されるべき第１の輸送車両の数に応じて、予測到着時間の数は１つまたは複数であってもよい。好ましくは、数は１であり、特定の瞬間に分析が実施されるべき１つの第１の輸送車両に関する。

ドウェル時間という用語は、好ましくは、乗客が輸送車両を乗降するのを可能にするため、または他のいずれかの理由で輸送車両が駅に留まる／待機する／停車する、予定された期間として理解されるべきである。この期間は、そうしなければ輸送機関に時間通りに着いて乗り込むことができないかも知れない乗客を待つために、予定されたドウェル時間に対して延長されてもよい。

より具体的には、自身の移動計画にしたがって旅程を継続するために第２の輸送サービスの輸送車両に乗るつもりでいる、遅延輸送車両に乗っている第１の輸送サービスの乗客は、上記輸送車両の駅でのドウェル時間の延長により、第２の輸送サービスの輸送車両に乗ることができる。計算されるドウェル時間値の数は１つまたは複数であってもよく、１つを超える場合、ドウェル時間（値）のセットが好ましくは決定されてもよく、そこからオペレータまたは操作部が１つのドウェル時間値を選択してもよい。

ドウェル時間値は、好ましい一例では、輸送車両が遅延した場合に、遅延輸送車両の乗客（遅延輸送車両を待っている乗客を含む）のうち少なくとも既定の割合が接続に間に合わないことがないように、ドウェル時間を調節することによって決定されてもよい。それに対応して、例えば、更なる停留所に対する影響を低減するように、第２の輸送サービスに関しては増加させることによって巡航速度／走行速度が設定されてもよい。更に、非常に好ましくは、ドウェル時間および／または走行速度の適応が、輸送サービスおよびそれを使用するまたは使用したい乗客に対する影響を表す影響パラメータに基づいて決定されることも可能である。

より具体的には、ドウェル時間／巡航速度値は、非常に信頼性が高く計算の複雑性が低い計算プロセスに基づいて判断を行うことができるという技術的利点を有する、更に後述する影響パラメータを最小限に抑えることに基づいて決定されてもよい。

ここで、巡航速度という用語は、好ましくは、輸送サービスの駅間で輸送車両が維持する速度として理解されるべきである。上記駅間での異なる巡航速度を実現することによって、輸送車両が輸送サービスの後続の予定駅に着くのに要する時間間隔を調節することが可能である。例えば、第１の選択肢として、ドウェル時間が増加した場合、またこれを、例えば第２の輸送サービスの巡航速度を増加することによって修正すべきである場合、第１および／または第２の輸送サービスの巡航速度を増加させてもよい。

更に、巡航速度は、別の選択肢では、ドウェル時間を長時間延長することができない場合、低減されてもよい。例えば、第１の輸送サービスの輸送車両に関する到着時間の決定が、第１の輸送サービスの輸送車両の遅延をもたらす場合、第２の輸送サービスの輸送車両に対して巡航速度が推奨されてもよい。それに対応して、第１の輸送サービスから第２の輸送サービスに乗り換えるつもりでいる乗客に、第２の輸送サービスの輸送車両に乗る機会を与えるために、駅におけるドウェル時間の延長の代わりにまたはそれに加えて、低減された巡航速度が実現されてもよい。

更にまた、輸送サービスの特定の駅における先行輸送車両の予定ドウェル時間を上回るドウェル時間を実現すべきである場合、同じ輸送サービスの輸送車両間の予め定められた距離を維持するために、低減された巡航速度が後続輸送車両に対して推奨されてもよい。巡航速度は、一例として、２つの駅間の既知の距離と、所望の到着／移動時間とに基づいて計算されてもよい。

輸送システムの制御は、特に、人間のオペレータがそれに基づいて輸送システムを制御するようにガイドすることができる、公共輸送システムの人間のオペレータに対して自動化された制御情報を提供することによって、またはオペレータが、自動的に生成された制御情報に基づいて輸送システムを制御する別のコンピュータベースのエンティティ／ユニットである、輸送システムの自動制御を可能にすることによって、改善される。自動的に提供された制御情報は、特に、輸送システムの車両のドウェル時間および／または巡航速度に関する。それに対応して、更に自動化された、より信頼性の高い公共輸送向けのシステムを提供することができる。

したがって、公共輸送システムの制御における自動化のレベルを更に改善することができる。より具体的には、また特に、上記輸送システムの輸送車両のドウェル時間および／または巡航速度に関する判断を、更に自動化することができ、輸送サービスを使用する乗客のデータは、巡航速度および／またはドウェル時間の適応に関する（リアルタイムの）データ駆動の制御判断を可能にするのに、自動的に使用される。輸送車両のスケジュールが更新されたドウェル時間も、例えば、ＥＰ３５３９８４４Ａ１に記載されているように、更新後スケジュール生成部によって生成されてもよい。

更に、装置は、第１の輸送サービスの駅から第２の輸送サービスの駅までの、上記輸送サービス間での乗換えを伴う旅程を完了するために、複数の輸送サービスを使用して乗客をより効率的に輸送する技術的効果を提供する。この駅は、以下、乗換え駅と呼ばれる。この用語は、乗客が２つ以上の輸送サービス間で乗り換えることができる駅にも当てはまる。

また、装置は、例えば、第１の輸送サービスの運行の遅延が理由で第２の輸送サービスの輸送車両に間に合わなかったであろう複数の乗客が、乗換え駅における上記輸送車両のドウェル時間の延長によって第２の輸送サービスの輸送車両に間に合うことができるとき、作業負荷ピークを回避することによって、輸送車両の輸送能力をより効率的に使用できるようにする。更に、第２の輸送サービスの輸送車両の作業負荷は、
したがって、本発明の装置によって均等化することができ、第１の輸送サービスの遅延によって引き起こされる作業負荷ピークの低減は、輸送車両の摩耗および亀裂の低減をもたらす。ここで、摩耗は、人員積載量の最大稼働率で多数の乗客を輸送することによって引き起こされる、車両の技術的構成要素に対するひずみの増加による輸送車両の劣化を意味する。また、この用語は、内装材および内装品など車両内部の摩耗を含む。

特に、公共輸送システムを制御する装置を提供するという観点で、制御されるシステムの予定運行の乱れ、およびしたがって信頼性の高い乗客輸送に対して起こり得る悪影響は、装置によるドウェル時間および／または巡航速度の自動決定によって軽減される。そのため、その実現は、コンピュータ誘導のアクションで人間のオペレータによって実施されてもよく、またはオペレータは、決定されたドウェル時間および／または巡航速度の適応を適用する別のコンピュータ制御であることができる。

更に、ドウェル時間分析部は、推奨データを輸送車両オペレータに対して発行するように更に構成されてもよく、それに基づいて、第２の輸送サービスの輸送車両のドウェル時間および／または輸送車両の巡航速度を選択することができ、輸送車両オペレータは、人間のオペレータおよび／またはコンピュータベースの制御エンティティである。

ここで、推奨データは、列車オペレータによって実現されてもよい、１つもしくは複数の推奨ドウェル時間および／または巡航速度を含む、データのセットであってもよい。推奨データの生成は、乗換え需要予測部によって決定される第１および第２の輸送サービス間の乗換え需要、ならびに到着時間予測部によって予測される乗換え駅における第１の輸送サービスの車両の到着時間に基づいて、ドウェル時間分析部によって実施されてもよい。１つを超えるドウェル時間が決定された場合、コントローラは、より好適なものを選択する選択権を有してもよい。更に、出発時間を変更すべき１つを超える第２の輸送サービスがある場合にも、複数のドウェル時間が発行されてもよい。

推奨データに基づいて、オペレータは、ドウェル時間の適応および／または巡航速度の適応を実現するように判断することができる。選択可能なドウェル時間および／または巡航速度のセットが推奨データとともに提示された場合、オペレータは、一例として値を選択することができる。オペレータが別の制御コンピュータである場合、推奨データは制御入力データとみなすことができ、制御コンピュータ（オペレータ）はそれに基づいて値を選択する。代替の値／選択肢のセットが制御コンピュータ（オペレータ）に提供される場合、制御コンピュータは内部制御構成を含んでもよく、それに基づいて選択を実施することができ、例えば、制御構成は、制御コンピュータ（オペレータ）が、最短ドウェル時間、最適巡航速度、後に引き起こされる渋滞が最も少ないドウェル時間などを常に選択することを含んでもよい。

巡航速度およびドウェル時間は、好ましくはそれらの適応を指すことに留意されたい。更に、巡航速度は、第１および／または第２の輸送サービスに対して、好ましくは、ドウェル時間の増加によって引き起こされた遅延を低減すべきである場合、第２の輸送サービスに対して、適応されてもよい。

制御装置は更に、ドウェル時間分析部によって決定されるドウェル時間または巡航速度に関する／それらによって引き起こされる、遅延（遅延の値）を決定するように構成されてもよく、遅延は、第２の輸送サービスの駅における輸送車両の遅延時間、および第２の輸送サービスの他の輸送車両の遅延時間を含んでもよい。遅延が既定の閾値未満の場合、ドウェル時間分析部は、ドウェル時間および／または巡航速度を選択する推奨を含む推奨データを生成してもよい。上述したように、推奨データは異なる好ましい計算の選択肢に基づいてもよい。手順が使用されてもよく、それにしたがって、ドウェル時間値および／または巡航速度の適応のどこで、接続に間に合わない乗客の数が特定の閾値を上回るかが、比較的単純に計算される。更に、遅延が閾値未満に低減されるように、適応が計算されてもよい。更に、コスト計算を実施することができ、どの適応がコストの最小化につながるかを決定することによって、ドウェル時間および／または巡航速度の適応を実施することができる。

特に、遅延は、乗換え駅自体に対して、および／または第２の輸送サービスのその先の各駅に対して、通常の方式で決定されてもよい。更に、遅延は、すぐ次の第２の輸送サービスだけではなく、同じ線または別の線の後続の列車、バスなど、後々のサービスにも影響することがある。これら「他の輸送車両」も遅延によって影響を受けることがあり、これは同様に既知の方式で計算されてもよい。

遅延または遅延時間という用語は、輸送サービスの駅における輸送車両の予定到着時間からの逸脱として理解されてもよい。それに対応して、駅到着の遅延を上記駅における輸送車両の予定ドウェル時間によって相殺できない場合、上記輸送車両の予定された出発が影響を受けることがある。装置の上述の構成に関連して、遅延という用語は、特に、ドウェル時間分析部によって決定されたドウェル時間および／または巡航速度の実現／適応によって引き起こされる遅延を指すものとする。

遅延は既定の閾値と比較されてもよい。より具体的には、閾値は、乗客に対する上記影響に応じて決まるように設定されてもよく、遅延が、公共輸送の通常運行およびシステムを使用する乗客に対する重大な影響が予期される大きさに達するのを防ぐために設定されてもよい。それに対応して、遅延が閾値よりも大きい場合、ドウェル時間および／または巡航速度の実現が、公共輸送システムの運行および乗客の輸送を許容できない形で妨げるであろうことから、推奨データの生成は実施されなくてもよい。更に、あるいは、推奨データは、ドウェル時間および／または巡航速度を適応させるべきではないという指示を含んでもよい。

輸送サービスの他の車両の遅延を考慮することで、後続として輸送サービスで運行される輸送車両の作業負荷ピークが確実に回避されるという利点が提供される。換言すれば、輸送車両の過度のドウェル時間が駅において実現された場合、輸送サービスの渋滞を引き起こすことがあり、ドウェル時間の延長を実現した輸送車両の後続の輸送車両に乗ることを当初計画していた乗客が、ここでその到着の遅延によって上記輸送車両に乗ることがある。それに対応して、輸送サービスの他の輸送車両に対するドウェル時間および／または巡航速度の影響を考慮することは、輸送車両の輸送能力を効率的に使用できるようにするために、特に有益である。上記影響に基づいて、上記車両の過度のドウェル時間およびしたがって非効率的な使用の実現によって引き起こされる、輸送サービスの渋滞による、輸送車両の停滞を回避することができる。

制御装置は更に、総コストパラメータに関連する影響パラメータを決定するように構成されてもよく、影響パラメータは、ドウェル時間および／または巡航速度の適応によってもたらされる、乗客および／または輸送サービス事業者の総コスト（の増加）に基づいて決定されてもよい。総コストパラメータは、したがって、予定された移動計画の適応の影響を決定する、単純に計算可能な測定基準であり、上記総コストパラメータ値を最小限に抑えることで、乗客および事業者に対する影響をできるだけ低く抑える、可能な最良のドウェル時間適応値および／または巡航速度適応値を選択できるようになる。影響パラメータが既定の閾値未満の場合、ドウェル時間分析部は、好ましくは（特定の）ドウェル時間および／または巡航速度を選択する推奨も含む、推奨データを生成してもよい。

上述したように、遅延は、ドウェル時間／巡航速度の適応に関して判断するための可能な手段であり、影響パラメータは別の好ましい選択肢である。遅延輸送車両が駅に到着するのを待っている乗客の数が多いほど、より多くの乗客が遅延による影響を受けるので、遅延の影響は大きくなる。また、１つの輸送サービスから別のものに乗り換えようとしている乗客の数が多いほど、または換言すれば、乗換え需要が大きいほど、より多くの乗客が遅延による影響を受けるので、遅延の影響は大きくなる。したがって、影響の大きさは、ドウェル時間および／または巡航速度が実現されてもよい輸送車両に乗るために待っている、またはそれに乗り換えようと乗客の数に応じて決まる。好ましくは総コストパラメータである影響パラメータは、影響を可視化し、その最適化を可能にする。

影響パラメータは既定の閾値と比較され、影響パラメータが閾値未満の場合、ドウェル時間分析部は、輸送車両のオペレータによってドウェル時間および／または巡航速度を選択する推奨を含む、推奨データを生成してもよい。閾値は、影響が、システムを使用する乗客に対する重大な影響が予期される大きさに達するのを防ぐために設定されてもよい。

更に、好ましくは、装置は更に、第２の輸送サービスの車両の更新後出発時間を上記輸送車両のオペレータから受信し、更新後出発時間を複数の乗客デバイスに伝送するように構成された、フィードバック列車出発時間更新部を備える。

ここで、更新後出発時間は、乗客が移動計画にしたがって乗ろうとしている輸送車両の実際の出発時間を示してもよい。それに対応して、更新後出発時間は、駅におけるドウェル時間の延長／適応および／または巡航速度の実現により、輸送車両の予定出発時間から逸脱してもよい。

輸送車両のオペレータが、輸送車両オペレータインターフェースに表示された推奨データにしたがって、ドウェル時間および／または巡航速度を実現すると判断すると、オペレータは上記判断を確認し、また結果として判断の含意が、フィードバック列車出発時間更新部によって更新後出発時間の形態で乗客デバイスに伝送される。同様に、オペレータが、公共輸送システムの全自動制御を実施する装置によって実現されるドウェル時間および／または巡航速度を確認すると、上記ドウェル時間および／または巡航速度の含意が、フィードバック列車出発時間更新部によって更新後出発時間の形態で乗客デバイスに伝送される。

フィードバック列車出発時間更新部は、バックエンドサーバの一部であって、一方では輸送車両オペレータインターフェースと、他方では乗客デバイスと通信するように構成されてもよい。

上記により、乗客に情報が提供され、それに基づいて自身の移動計画を更に続行するかまたは自身の旅程を変更するかを判断することができるので、特許請求する装置によって容易になる、ガイドされる人間・機械間の相互作用が相乗的に増加する。それらの変更は、別の輸送車両または輸送サービスを選ぶこと、およびそれによって、修正された移動計画に従うこと、または公共輸送システム以外の輸送モードを選ぶことを含んでもよい。

更に、輸送車両のオペレータが人間のオペレータである場合、制御装置は更に、推奨データを表示し、適応されたドウェル時間および／または巡航速度を選択し実現するよう人間のオペレータに指示するように構成されてもよい、グラフィカルユーザインターフェースを含んでもよい。輸送車両のオペレータがコンピュータベースの制御エンティティである場合、輸送車両のオペレータは、推奨データを受信し、ドウェル時間および／または巡航速度を適用することを含めて、制御信号を輸送車両に発行してもよい。

グラフィカルユーザインターフェースは、接触感知式ディスプレイ表面、マウス、および／またはキーボードなどの出力および入力デバイスとして、液晶ディスプレイまたは薄膜トランジスタディスプレイを備えるグラフィカルユーザインターフェースであってもよい。

推奨データをグラフィカルユーザインターフェースに表示することで、列車オペレータに、適応されたドウェル時間および／または巡航速度を実現するか否かを判断する機会が与えられる。これは、公共輸送システムの改善されたコンピュータ誘導制御を提供する可能性をもたらす。これは、上記輸送車両および公共輸送システムの制御などの技術的タスクを、オペレータが実施するのを支援するという観点で、特に有益である。

オペレータがコンピュータベースの制御エンティティである場合、公共輸送システムの全自動制御は、ドウェル時間および／または巡航速度の実現をもたらす形で輸送車両を運行する、制御信号を直接自動的に発行することによって、更に改善することができる。

更に、好ましくは、データベースは更に、路線および駅の座標、利用可能な輸送サービスのスケジュールデータ、ならびに輸送サービスの到着および出発時間履歴を含んでもよい。また、制御装置は、輸送サービスの移動データおよび出発時間履歴をデータベースから受信するように構成された、移動需要予測部を含んでもよい。移動需要予測部は更に、移動履歴データを路線および駅の座標と整合することによる乗客旅程履歴、ならびに／あるいは輸送サービスの到着および出発時間履歴を含む、移動発着地表を生成するように構成されてもよい。

路線および駅ならびに利用可能な輸送サービスの座標は、輸送車両の走行路線およびそれらの路線にある駅など、輸送サービスの基盤構成要素の経度および緯度を表すデータとして理解されるものとする。

スケジュールデータという用語は、好ましくは、上述の公共輸送向けのシステムの一部である、輸送サービスごとの到着および出発時間を含むデータとして理解されるべきである。換言すれば、スケジュールデータは、公共輸送システムの異なる駅における公式／計画到着および出発時間を含み、それに基づいて公共輸送向けのシステムが運行される。

輸送サービスの到着および出発時間履歴は、輸送サービスの駅における輸送車両の到着および出発の記録された時点を含んでもよい。これらの時点は、交通渋滞、輸送サービスの運行中の不測のイベント、気象条件などの外的要因により、駅における輸送車両の予定到着および出発データとは異なってもよい。

ここで、移動需要値の決定は、乗客のスマートカード、ｂｅ－ｉｎ－ｂｅ－ｏｕｔカード、および／または携帯デバイスの使用履歴、ならびに、スマートカード使用の記録、輸送路線の座標、および輸送サービスのスケジュールデータが、スマートカードのスワイプデータと上記トリップチェーンデータとの空間的および時間的整合を行うのに使用される、スマートチケッティングによるリアルタイムの旅程を使用して構築される、一人または複数の乗客の移動発着地ＯＤ表またはトリップチェーンデータに基づいてもよい。

ここで、スマートチケッティングは、乗車券をマイクロチップに電子的に格納し、それが通常はスマートカードに埋め込まれる、システムであってもよい。スマートカードは、公共輸送機関の乗客が、現金または切符購入のような従来の支払いシステムを使用する必要なく、バス、路面電車、または列車にシームレスで乗り降りするのを可能にすることができる。非接触式スマートカードは、固定もしくは手持ち式の券売機または改札のどちらかで読み取られて、輸送サービスの使用を認証する。

トリップチェーンという用語は、乗客が毎日日常的に実施してもよい、乗客の移動計画にしたがった一連の予定イベントとして理解されてもよい。それらのイベントとしては、第１の輸送サービスの輸送車両に乗ること、上記輸送車両によって１つまたは複数の輸送サービス区間を移動すること、第１の輸送サービスおよび第２の輸送サービスを連結する乗換え駅で第１の輸送サービスの輸送車両から降りること、第２の輸送車両の輸送車両に乗ること、上記輸送車両で１つまたは複数の輸送サービス区間を移動すること、ならびに第２の輸送サービスの輸送サービス車両から降りることを挙げることができる。この乗客旅程はまた、乗客旅程の始点と終点との間での、２つを超える異なる輸送サービス間の乗換えを含んでもよい。トリップチェーンはまた、例えば、乗客が行う毎日の通勤の一部として、反対方向での記載した乗客旅程を含んでもよい。

リアルタイムの旅程という用語は、乗客の移動計画における現在のイベントのチェーンとして理解されてもよい。換言すれば、リアルタイムの旅程は、乗客の現在の状態および位置に関する情報を提供する。この情報を、乗客のスマートカードの使用データ履歴と併せて使用して、公共輸送システムを使用する各乗客のトリップチェーンを構築することができる。

スマートカードのスワイプデータの空間的および時間的整合は、好ましくは、乗換え需要予測部が、空間的成分として、全ての利用可能な輸送サービスの路線および駅の座標と、携帯デバイスまたはｂｅ－ｉｎ－ｂｅ－ｏｕｔチケットによって決定される乗客位置との整合動作を、また時間的成分として、全ての利用可能な輸送機関の予定到着および出発時間と、現在の時刻との整合動作を、それぞれ実施することを意味する。

乗客旅程とトリップチェーンとの空間的および時間的整合を実施することによって、乗換え需要値の決定に関して、相乗的に有益な効果を達成することができる。特に、乗換え需要値は、乗客旅程のリアルタイムデータと履歴データとを組み合わせて、乗客の日課および移動習慣を再現して乗客旅程を作成することによって、より正確に決定することができる。

また、移動需要値の決定は、Ｂｅ－Ｉｎ／Ｂｅ－Ｏｕｔスマートチケッティングの履歴データに基づいてもよく、Ｂｅ－Ｉｎ／Ｂｅ－Ｏｕｔスマートチケッティングシステムは、乗客の移動経路の座標を輸送サービス路線の座標と整合することによって、輸送サービスの路線に沿った乗客の所在地を直接追跡するように構成される。

公共輸送システムのＢｅ－Ｉｎ／Ｂｅ－Ｏｕｔ（ＢＩＢＯ）チケッティングサービスは、暗黙的な相互作用を利用し、乗客が輸送車両の内部にいることによって仮想チケットを得られるようにしてもよい。基盤の機器は、乗客の存在を検出し、気づかれないチケッティングサービスを背景で開始する。ＢＩＢＯシステムを実現するための実現技術として、ブルートゥース（登録商標）低エネルギー（ＢＬＥ）が使用されてもよい。

上記に、スマートカードスワイプデータに対して、乗客旅程の空間的および時間的整合がどのように実施されるかについて記載した。しかしながら、この例では、空間的および時間的整合の代わりにマップマッチングが実施されてもよい。ここで、乗客の移動経路の座標を公共輸送システムの利用可能な路線および駅の座標と整合するマップマッチングから、移動需要値を得ることができる。

それに対応して、乗換え需要値のより正確な決定は、公共輸送システムのより信頼性が高い制御という利点を提供する。また、公共輸送システムが備える輸送車両の輸送能力を効率的に利用するという観点で、乗換え需要値のより正確な決定は、上述の理由から望ましい。

更に、上記に関連して、移動履歴データは、全旅程に沿った乗客の各所在地に対する所在地情報およびタイムスタンプを含む、乗客のスマートカードまたは携帯デバイスからのデータを含んでもよく、ならびに／あるいは履歴データは、既存の輸送システムに乗降する時の乗客の所在地およびタイムスタンプを含む、Ｂｅ－Ｉｎ／Ｂｅ－Ｏｕｔスマートチケットおよび／または携帯デバイスからのデータを含んでもよい。

更に、乗換え需要予測部は、入力として、移動ＯＤ表データまたはトリップチェーンデータそれぞれを、ならびに／あるいは実際の乗換え需要を乗客から受信して、予測乗換え需要値を生成してもよい、訓練済み機械学習部を含んでもよい。

この場合、機械学習部は、整合学習技術を使用してもよい。機械学習部は、公共輸送システムの輸送駅間の移動需要値履歴、および地理的距離を使用して訓練される。

実際の乗換え需要は、携帯デバイスを介して乗客によって提供される移動計画から推論されてもよく、または乗客によって、携帯デバイスで動作するソフトウェアアプリケーション（スマートチケッティングソフトウェア）に直接入力されてもよい。

移動需要値履歴は、公共輸送システムの利用可能な輸送サービスを使用した乗客数履歴を含んでもよい。移動需要値履歴は、１つの輸送サービスから別のものに乗り換える乗客の数を決定するためのデータ基盤を作成するのに、異なる輸送サービス間の乗換え駅である、公共輸送システムの駅ごとに格納される。乗換え需要値履歴を参照することで、現在の乗換え需要値の決定に統計的推論を含めることができるので、乗換え需要値履歴の使用は、精度が向上するという利益を提供する。

移動需要値の決定は、乗客旅程の最初と最後の駅の間での移動需要値履歴および地理的距離に基づいてもよいので、乗換え需要値をより正確に決定することができる。地理的距離が大きいと、乗客が輸送サービス間の乗換えを必要とする可能性が高くなり、それによって、乗客の移動計画と組み合わせて乗換え需要値をより正確に決定できるようになる。

上記にしたがって、輸送車両の輸送能力をより効率的に利用することにおける装置の信頼性は、乗換え需要値を決定するための基礎として、より正確な移動需要値を決定することによって向上することができる。換言すれば、駅におけるドウェル時間および／または予定にない巡航速度を実現するか否かを判断するための基礎の改善は、乗換え需要値の決定における精度の向上によって提供される。

それに対応して、機械学習プロセスを使用することで、統計的推論を移動需要の推定プロセスに組み込むことにより、乗換え需要値のより正確な推定を容易にすることによって、装置の利点が相乗的に増加する。

更に、乗換え需要予測部は、データベースに格納された、異なる輸送サービスの駅間の地理的距離に関するデータを受信してもよい。更に、訓練済み機械学習部は、乗換え需要値を決定するための更なる入力として、地理的距離を使用してもよい。

格納された地理的距離（地理的関係）は、公共輸送システムの駅を連結する輸送サービス区間に対応してもよい。輸送サービス区間という用語は、好ましくは、公共輸送システムの２つの駅間の距離を網羅するために、乗客が移動しなければならない距離として理解されるものとする。

地理的距離という用語は、公共輸送システム全体に対して２つの駅間にある道のりの長さを示してもよい。これはまた、２つの異なる輸送サービスの駅間の道のりの長さを含んでもよい。更に、地理的距離という用語はまた、公共輸送システムの２つの駅を連結する利用可能な輸送路線に基づいた、それらの駅間の距離に該当する。上記距離はまた、２つ以上の異なる輸送サービスの路線にわたって延在してもよい。

したがって、地理的距離および輸送サービス区間は、任意の好適な量で測定することができる、乗客旅程の長さであってもよい。本出願では、キロメートルの距離単位が使用される。

地理的距離を、乗換え需要値を決定するための更なる入力として使用することは、乗換え需要をより広範に決定するためのデータ基盤を作る際の助けとなる。

それに対応して、乗換え需要値のより正確な決定は、公共輸送システムのより信頼性が高い制御という利点を提供する。また、公共輸送システムが備える輸送車両の輸送能力を効率的に利用するという観点で、乗換え需要値のより正確な決定は、上述の理由から望ましい。

更に、データベースは、気象情報を格納するように構成されてもよく、乗換え需要予測部の訓練済み機械学習部は更に、気象情報に関する追加情報に基づいて、第１の輸送サービスの各駅と第２の輸送サービスの各駅との間の乗換え需要値を推定するように構成されてもよい。

気象情報という用語は、輸送サービス間の乗換え需要に影響することがある、公共輸送システムのそれぞれのエリアにおいて広く見られる気象条件に関する情報として理解されるべきである。これは、降雨または低気温などの気象条件が、公共輸送サービスを使用する乗客数の増加につながることがある一方、晴れて乾燥した条件は乗客数の減少につながることがあることを意味する。移動需要は、公共輸送システムを使用する乗客の数に直接結びつけられるので、気象情報を乗換え需要値の推定に含めることで、乗換え需要値の精度が向上するという利点が提供される。

気象情報を、乗換え需要値を決定するための更なる入力として使用することは、乗換え需要をより広範に決定するためのデータ基盤を作る際の助けとなる。

それに対応して、乗換え需要値のより正確な決定は、公共輸送システムのより信頼性が高い制御という利点を提供する。また、公共輸送システムが備える輸送車両の輸送能力を効率的に利用するという観点で、乗換え需要値のより正確な決定は、上述の理由から望ましい。

更に、到着時間予測部は、輸送サービスを使用する乗客の複数の携帯デバイスから、所在地情報およびタイムスタンプを受信し、それらを、データベースに格納された路線および駅の座標ならびに利用可能な輸送サービスのスケジュールデータと整合するように構成されてもよい。更に、到着時間予測部は、複数の携帯デバイスからの所在地情報に基づいて、輸送サービスの実際の移動時間を評価し、移動履歴データに基づいて輸送サービスの移動時間を評価し、輸送サービスの次の駅の予測到着時間を推定するように構成されてもよい、訓練済み機械学習部を含んでもよい。

換言すれば、上記機械学習部は更に、機械学習アルゴリズムに基づいて、前の輸送サービス区間における輸送車両の移動時間、輸送サービス区間における車両の移動時間の履歴データ、および地理的距離を使用して、輸送サービス区間における輸送車両の移動時間を決定するように構成されてもよい。

ここで、移動時間は、輸送サービス車両が輸送サービス区間を完走するのに要する期間であってもよい。それに対応して、移動時間の履歴データは、公共輸送サービスの輸送車両が前の運行過程の間に特定の輸送サービス区間を網羅するのに要した期間を含むデータであってもよい。

これは、装置が、乗客が第１の輸送サービスから第２の輸送サービスに乗り換えようとする駅における、第１の輸送サービスの輸送車両の実際の到着時間を決定できるようにするという利点を提供する。したがって、決定された到着時間が予定到着時間から逸脱している場合、第１の輸送サービスの輸送車両の遅延を導き出すことができ、予測到着時間を機械学習部によって出力することができる。

これにより、第２の輸送サービスに乗り換えようとする第１の輸送サービスの乗客が、自身の予定の接続に間に合うことを可能にするため、第２の輸送サービスの輸送車両によって実現されてもよい、ドウェル時間および／または巡航速度のより正確で信頼性が高い決定が相乗的に増加する。したがって、公共輸送システムのより信頼性が高い運行も提供することができる。

更に、輸送サービスを使用する乗客のタイムスタンプを含む移動計画および所在地情報を伝送するように構成された、複数の乗客携帯デバイスと、輸送車両のオペレータおよび／またはコンピュータベースの制御装置のためのグラフィカルユーザインターフェースと、複数の乗客携帯デバイスおよびオペレータと通信するように構成された、バックエンドサーバシステムとを備える、輸送システムが特許請求されてもよい。バックエンドサーバシステムは更に、上述の制御装置を備える。

更に、推奨／適応出発時間を決定する方法は、輸送サービスを使用する乗客の複数の携帯デバイスから、移動計画および所在地情報を受信するステップ、受信した移動計画および移動履歴データに基づいて、２つの異なる輸送サービス間で乗り換えようとする乗客の数に対応する乗換え需要を推定するステップ、乗客の携帯デバイスから受信した所在地情報およびタイムスタンプを、第１のサービスの路線およびスケジュールデータと比較することによって、乗客が使用する第１の輸送サービスの車両を識別するステップ、移動履歴データに基づいて、第１のサービスと第２のサービスの間で乗り換えるための乗換駅の到着時間を予測するステップ、ならびに／あるいは、第１のサービスの推定到着時間に基づいて、駅における第２のサービスの車両のドウェル時間を計算するステップを含む。

また、コンピュータによって実施されると、コンピュータに上述の方法を実施させる、メモリに格納可能なコンピュータプログラム製品が特許請求される。

換言すれば、特許請求する装置の各構成はまた、それ自体が特許請求されてもよい方法として、および／またはコンピュータプログラム製品クレームとして包含されるものとする。

本発明の実施形態によれば、特に、公共輸送システムの自動化および信頼性に関して技術的利益を提供し、乗客と公共輸送システムとのガイドされる相互作用も可能にする解決策が提供される。それに加えて、提供される解決策は、作業負荷を均等化する一方で、輸送車両の摩耗および亀裂を低減するのも容易にすることによって、輸送車両の輸送能力のより効率的な使用も可能にする。

以下、図面を参照して本発明の実施例について詳細に説明する。

図１は、バックエンドサーバシステムまたはバックエンドオフィス１１００と、乗客の携帯デバイス１２００と、列車運行管理システム（ＴＭＳ）１４００と、輸送車両オペレータ１３００とを備える、特許請求するシステムの概略図を示している。バックエンドサーバシステムは更に、乗換え需要予測部１１０１と、データベース１１０５と、到着時間予測部１１０２と、ドウェル時間分析部１１０３と、フィードバック部１１０４とを備える。

携帯デバイス１２００は、スマートフォン、タブレット、スマートウォッチ、ラップトップ、または他の任意のコンピューティングデバイスである。携帯デバイスは更に、全地球衛星航法システム（ＧＰＳ）から位置情報を取得するように構成された位置決定部と、乗客が第１の輸送サービスから、この図では例示的に列車によって表される第２の輸送サービスの車両に乗換え駅１０００で乗り換えようとする駅における、第１の輸送システムの、この図では例示的にバスによって表される輸送車両の推定到着時間を表示するように構成されたグラフィカルユーザインターフェースとを有する。

第１の輸送サービスから第２の輸送サービスに乗り換えようとする、第１の輸送サービスに属するバスを使用する、携帯デバイス１２００を有する複数の乗客の位置情報は、それらの携帯デバイス１２００によってバックエンドサーバシステム１１００に伝送される。バックエンドサーバシステム１１００は、乗客の位置情報を使用して、乗換え駅１０００におけるバスの到着時間を決定するとともに、乗換え需要値の決定を実施し、それら両方が次にドウェル時間分析部１１０３に転送される。

具体的には、ドウェル時間分析部１１０３（図２を参照）は、ドウェル時間および／または巡航速度を実現することに関連するリスクに対応する影響パラメータを決定する。影響パラメータに基づいた推奨巡航速度および／またはドウェル時間を含む推奨データは、輸送車両オペレータに伝送される。列車オペレータ１３００は次に、ドウェル時間および／または巡航速度を実現するか否かを判断し、あるいはオペレータがコンピュータベースの制御エンティティである場合、オペレータは、ドウェル時間および／または巡航速度を実現する制御コマンドを自動的に直接発行する。

列車オペレータ１３００の制御コマンドは次に、フィードバック出発時間更新部１１０４および列車管理システム１４００に伝送される。フィードバック出発時間更新部１１０４は次に、乗換え駅１０００における列車のドウェル時間に対応するアップロードされた列車出発時間と、乗換え駅１０００におけるバスの決定された到着時間とを、バスの乗客の旅程の詳細に関して通知するためにそれらの携帯デバイスに伝送する。

第２の輸送サービスにおける輸送車両の出発時間の決定に関与するプロセスの更なる詳細は、図２に示される装置の説明から明白となるであろう。

図２は、バックエンドサーバシステムを含む、特許請求する装置の構造の概略図を示している。バックエンドサーバシステムは更に、乗換え需要予測部１１０１と、データベース１１０５と、到着時間予測部１１０２と、ドウェル時間分析部１１０３とを備える。更に、バックエンドサーバシステムはまた、フィードバック出発時間更新部１１０４を備える。

データベース１１０５は、路線および駅の座標と、公共輸送システムの利用可能な輸送サービスのスケジュールデータとを格納するように構成される。更に、データベースは、気象情報および移動履歴データを格納するように構成される。

乗換え需要予測部１１０１は、移動計画１２０１、所在地情報１２０２、およびタイムスタンプを、輸送サービスを使用している乗客の複数の携帯デバイス１２００から受信し、受信した移動計画１２０１および移動履歴データに基づいて、乗換え需要値として、第１と第２の輸送サービスの間で乗り換えようとしている乗客の数を決定するように構成される。

これは、図２において、乗換え需要予測部１１０１を概略的に表す、参照符号１１０１で示すボックスに示されている。上記乗換え需要予測部１１０１は、例えば、乗客が自身の旅程の始点／出発地および目的地をモバイルアプリケーションプログラムに入力したときに、乗客の移動計画１２０１を受信するように示されている。上記情報に基づいて、また移動履歴データを含むデータベースからの入力と組み合わせて（履歴データから移動需要を予測するユニット１１０１Ａを参照）、乗換え需要値を決定する乗換え需要が推定される。乗換え需要を決定する好ましい特定のプロセスについては、図１４に関連して更に記載する。

到着時間予測部１１０２は、乗客所在地およびタイムスタンプを複数の携帯デバイス１２００から好ましくはリアルタイムで受信し、所在地情報およびタイムスタンプを第１の輸送サービスの路線およびスケジュールデータと比較することにより、乗客が使用している第１の輸送サービスの輸送車両を識別することによって、第１の輸送サービスと第２の輸送サービスとの間で乗り換える駅における第１の輸送サービスの輸送車両の到着時間を予測し、移動履歴データに基づいて、第１の輸送サービスと第２の輸送サービスとの間で乗り換える乗換え駅１０００の到着時間を予測するように構成される。

上述したように、好ましくは、複数の乗客およびそれらの携帯デバイスそれぞれからのタイムスタンプを含む所在地に関するデータは、リアルタイムデータなので、既知の残りの移動距離および乗客の位置に基づいて、到着時間を決定することができる。図２は、上述のリアルタイムデータに基づいて位置および移動速度が決定される、同部１１０２のサブブロックによって、この決定を示している。データは次に、輸送デバイスの移動路線と整合させると、移動時間推定に使用することができ、それに基づいて距離を決定することができる。更に、図２には、データベース１１０５が乗客旅程（「トリップチェーン」）の履歴データを移動時間推定にも提供することも示されている。

図２は、一例として、バスの到着時間が決定されることを示している。この例は、バスが第１の輸送サービスであり、第２のサービスとしての地下鉄などと接続されていると仮定している。しかしながら、他の任意の公共輸送車両が他の例では相応に仮定されてもよい。到着時間を決定する好ましいプロセスに関する更に詳細な説明については、図１８に関連して説明する。

ドウェル時間分析部１１０３は、乗換え需要値を乗換え需要予測部１１０１から、１つまたは複数の第１の輸送車両の予測到着時間を到着時間予測部１１０２から受信するように構成され、これは図２の下側および図１の右側の矢印によって示される。ドウェル時間分析部１１０３は次に、輸送車両の予測到着時間および／または巡航速度に基づいて、駅における第２の輸送サービスの１つまたは複数のドウェル時間を決定してもよい。

バックエンドサーバシステム１１００に送信されるデータの中には、乗客携帯デバイス１２００の位置、および乗客旅程のイベントからのタイムスタンプがある。また、乗客携帯デバイス１２００は、上記移動計画の出発地および目的地ならびにスマートチケッティングによって取得されるリアルタイム移動イベントに関する情報を含む、乗客の移動計画を含む情報を、バックエンドサーバシステム１１００に送信する。

バックエンドサーバシステム１１００から乗客携帯デバイスが受信するデータの中には、第１の輸送サービスで移動している乗客が第２の輸送サービスに乗り換えようとしている乗換え駅１０００における、ドウェル時間に対応する輸送車両の更新後出発時間を含む、フィードバック出発時間更新部１１０４によって伝送される更新がある。また、フィードバック時間更新部１１０４は、乗客が第２の輸送サービスの輸送車両に乗り換えようとしている駅における、第１の輸送サービスの輸送車両の決定された到着時間に関する情報を伝送する。

ドウェル時間分析部１１０３が、乗換え需要値を乗換え需要予測部１１０１から、決定された到着時間を到着時間予測部１１０２から受信し、次にドウェル時間を決定した後、ドウェル時間および／または巡航速度がそれに基づいて実現されるべきである影響パラメータが、推奨データとして列車オペレータ１３００に対して出力される。

推奨データは次に、この例では、輸送車両オペレータインターフェースで列車オペレータ１３００に対して表示され、オペレータは推奨ドウェル時間および／または巡航速度を実現するか否かの判断を行ってもよい。この判断は、図２によって示されるように、列車運行管理システム１４００にも伝送される。更に、判断は、フィードバック出発時間更新部１１０４にも伝送され、それが次に、上述したように、乗換え駅１０００における第１の輸送サービスの輸送車両の到着時間と、乗換え駅１０００における第２の輸送サービスの輸送車両の出発時間とに関する更新後情報を伝送する。

乗換え需要値の決定ならびにドウェル時間の決定がそれらに基づく、本明細書で提案する移動需要予測および到着時間予測の好ましいプロセスについては、図３～図２３を参照することによって以下に記載する。

図３は、乗客の携帯デバイス１２００の画面画像の例示画面を示している。この例では、第２の輸送サービスの輸送車両である列車の出発時間が更新されており、新しい出発時間として表示されている。更に、到着時間予測部１１０２によって決定されている、第１の輸送サービスに属するバス停留所Ｃにおける到着時間も表示されている。換言すれば、ドウェル時間延長の実現によって予定出発時間から変更されている、更新後列車出発時間が乗客に表示される。

図４は、特許請求する装置によって実施されるトリップチェーン構築の例示の画像を示している。例えば、乗客が毎日の通勤のために３つの異なる輸送サービスを使用する、例示的な乗客のトリップチェーンの構造が示されている。この例では、乗客は、バスサービスを第１の輸送サービスとして、列車サービスを第２の輸送サービスとして、別のバスサービスを第３の輸送サービスとして使用する。トリップチェーンの構築は、乗客のスマートカードの使用履歴、またはスマートチケッティングからのリアルタイムの旅程のどちらかを使用して実施することができる。しかしながら、この例の場合、スマートカードデータの使用履歴がトリップチェーンを構築するのに使用される。

乗客は、第１の輸送サービスの輸送車両に乗るときに自身のスマートカードを有効化するが、上記車両から降りるときは有効化する必要がない。乗客が第２の輸送サービスの輸送車両を乗降する場合、両方の輸送イベントに対して自身のスマートカードを有効化しなければならない。次に、乗客は、第３の輸送サービスの輸送車両に乗るときに自身のスマートカードを再び有効化するが、自身の旅程の目的地に到着して輸送車両から降りるときは有効化する必要がない。したがって、図４に記載する毎日の通勤では、乗客は、毎日の通勤を完了するために７回スマートカードを有効化する必要があることになる。取得した有効化データから、公共輸送サービスの各乗客のトリップチェーンを再構築し、データベース１１０５に保存して、移動履歴データとして使用することができる。

図５は、スマートカードデータから移動需要履歴データを決定するプロセスの構造を示している。第１のステップＳ００１として、乗換え需要予測部１１０１は、スマートカード使用データをデータベース１１０５に格納された公共輸送システムの乗客から収集する。第２のステップＳ００２で、空間的および時間的整合が実施され、利用可能な輸送サービスのロエンおよび駅の座標が、乗客のスマートカードが有効化された位置と整合され、異なる輸送サービスの予定到着および出発時間が、乗客のスマートカードが有効化された時点と整合される。

ここでは、バスおよび列車の例を使用する。しかしながら、他の輸送手段が同様に使用されてもよい。第３のステップＳ００３で、図４に記載したようなトリップチェーンの構築が実施される。公共輸送システムの全ての乗客に対してトリップチェーンの（再）構築を実施した結果は、Ｓ００４で、同じ輸送サービスの２つの駅間、または駅間での少なくとも一回の乗換えを要する少なくとも２つの異なる輸送サービスの駅間の移動が関与する、可能性がある乗客旅程ごとの移動需要として表される。「移動ＯＤ表」という用語は、図５のステップＳ００４に関連するボックスに示されるような上記プロセスの結果に対して使用されてもよい。

図６は、トリップチェーン構築に使用されるスマートカード使用の記録の例示的な表を示している。この例示的な表は、公共輸送システムの乗客と関連付けられたスマートカードＩＤ、乗客旅程の間にスマートカードが有効化された日時（タイムスタンプ）を含む上記スマートカードのスワイプ時間、輸送サービスを表す線番号、上記輸送サービスの輸送車両を表す車両ＩＤ、およびスマートカードの有効化が行われた輸送サービスの駅を表す駅ＩＤに関するデータを含む。

この表に含まれるデータは、図５に関連して説明する、スマートカードデータから移動需要履歴を決定するプロセスの第１のステップＳ００１におけるスマートカード使用履歴データとして使用される。例えば、ＩＤ「ＸＸＸＡ１２３」のスマートカードを所持している乗客は、朝、線「Ｂ１２」および「ＶＥＨ００１」に入るとき、および同日の夜、駅「ＲＳＴ００１」で線を出るときに、スマートカードをスワイプしていることが、図６によって示されている。

図７は、乗客旅程の空間的整合に使用される公共輸送システムの路線の座標の例示的な表を示している。この例では、表は、輸送サービスの識別子、輸送サービス区間の緯度および経度（位置座標）、輸送サービスの輸送サービス区間の識別子、ならびに輸送サービス区間の始点および輸送区間の終点を指定する駅ＩＤの形態のマーカに関するデータを含む。この表に含まれるデータは、スマートカードデータから移動需要履歴を決定するプロセスの第２のステップＳ００２、ならびにｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングデータから移動需要履歴を決定するプロセス（図１１に関連して記載する）の第２のステップで実施される空間的整合に使用される。例えば、図７に示される座標は、停留所ＩＤおよび２つの停留所間の区間ＩＤを含むバス路線「Ｂ１２」を含む。図７の表には、ＩＤ「ＳＴ０１」から「ＳＴ０６」までの停留所が列挙されている。

図８は、乗客旅程の時間的整合に使用されるバスおよび列車の到着および出発時間記録の例示的な表を示している。この例では、第１の輸送サービスはバスサービスであり、第２の輸送サービスは列車サービスである。表は、輸送車両の識別子を含む車両ＩＤ、路線ＩＤ、輸送車両が向かっている最終目的地のインジケータ、輸送サービスの駅における輸送車両の到着時間、輸送サービスの駅における輸送車両の出発時間、ならびに到着およびそれに続く出発が行われる駅を指定する駅ＩＤに関するデータを含む。この表に含まれるデータは、スマートカードデータから移動需要履歴を決定するプロセスの第２のステップＳ００２で実施される時間的整合に使用される。

図８は、一例として、表が、場所「Ｒｏｖｅｒｅｔｏ ＦＳ」に向かうＩＤ「Ｒ１」の路線に関するＩＤ「ＴＲ００１」の車両と、３つの駅「ＲＳＴ００１～００３」に関する朝０８：００ＡＭ～０８：１３ＡＭの間の３つの予定到着および出発時間とに関するデータを保持していることを示している。

図９は、トリップチェーン構築の結果の例示的な表を示している。表は、乗客と関連付けられたスマートカードＩＤ、路線ＩＤ、輸送車両が向かっている最終目的地のインジケータ、乗車駅ＩＤ、乗車時間、乗客が第１の輸送サービスの輸送車両から降りた駅の識別子、および乗客が輸送車両から降りた日時を表す降車時間を含む。この表に含まれるデータは、スマートカードデータから移動需要履歴を決定するプロセスの第３のステップＳ０００３で実施されるトリップチェーン構築に使用される。ここで、例示のデータは、スマートカード「ＸＸＸＡ１２３」に関して二回、スマートカード「ＸＸＸＡ１２４」に関して一回のデータを示しており、「ＸＸＸＡ１２３」の２つのデータセットは、それぞれのスマートカードの保持者が使用した路線および輸送サービスを含む旅程、およびいつ使用したかを示している。

図１０は、データベース１１０５に保存される、移動需要履歴を決定した結果の例示の表を示している。この例では、表は、一日のうち予め定められた期間を表すタイムスロット、乗客旅程の出発点を表す駅のＩＤ、乗客旅程の目的地を表す駅のＩＤ、および公共輸送システムの１つの駅から別の駅までの旅程を完了するのに公共輸送システムを使用する人数に対応する乗換え需要値を含む。具体的には、図１０の例は、異なるタイムスロットおよび異なる路線／輸送サービスでは、図１０の例示の路線および時間の場合の１０人、２５人、および１５人など、異なる数の乗客が予期されることを示している。

図１１は、ｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングデータから移動需要履歴データを決定するプロセスの構造を示している。第１のステップＳ０１１として、乗換え需要予測部１１０１は、乗客の座標および対応するタイムスタンプのリストを生成する。第２のステップＳ０１２で、利用可能な輸送サービスの座標が乗客旅程中に得られる乗客の座標と整合される、マップ整合が実施される。第３のステップＳ０１３で、前のステップで利用可能な輸送サービスの座標と整合された乗客の座標のリストが、今度は乗客旅程の対応するタイムスタンプと組み合わされる。第４のステップＳ０１４で、前のステップにおける時間分解マップ整合の結果に基づいて構築された、トリップチェーンが抽出される。第５のステップＳ０１５で、同じ輸送サービスの２つの駅間、または駅間での少なくとも一回の乗換えを要する少なくとも２つの異なる輸送サービスの駅間の移動が関与する、可能性がある乗客旅程ごとに移動需要（「移動ＯＤ表」）が決定される。

図１２は、ｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングによって取得される追跡した乗客旅程の例示的な表を示している。表は、乗客と関連付けられたユーザＩＤ、時間を表すタイムスタンプ、ならびに各タイムスタンプに対する乗客の横および縦座標を含む。この表に含まれるデータは、ｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングデータから移動需要履歴を決定するプロセスの第１のステップＳ０１１に対応して乗客の座標のリストを生成するのに使用される。図１２の例示のデータセットは、例えば、位置、速度などをデータから決定することができるように、３０秒ごとに乗客の位置座標が追跡されることを示している。

図１３は、ｂｅ－ｉｎ－ｂｅ－ｏｕｔスマートチケッティングデータから移動需要履歴を決定するプロセスの第３のステップＳ０１３で実施される、乗客旅程の移動経路と利用可能な輸送システムの路線とのマップ整合の結果の例示的な表を示している。表は、ユーザＩＤ、タイムスタンプ、タイムスタンプに対応する乗客の座標、バス路線ＩＤ、利用可能な輸送サービスの路線とマップ整合した後の乗客の補正後座標、輸送車両に乗っている乗客の走行速度を示す速度値、および乗客が現在移動している輸送サービス区間を識別する輸送区間ＩＤを含む。図１３の例は、この例では、「ＩＤ１」の乗客をバス路線「Ｂ１２」にどのようにマッピングすることによって、上記バス路線のどの区間にいつ乗客がいて、どの程度の速度で乗客（バス）が移動するかを決定できるようにすることができるかを示している。

図１４は、乗換え需要予測部１１０１によって実施される、公共輸送システムの輸送サービス間における乗換え需要値を決定する、好ましいプロセスを説明するフローチャートを示している。第１のステップＳ０２１で、乗換え需要予測部１１０１は、図５および図１１に記載したプロセスにしたがって決定された移動需要履歴データと、好ましくは、データベース１１０５からの気象履歴データとを抽出し、上記データセットの両方（気象データセットが使用される場合）を整合することによって乗換え需要値履歴を決定する。

第２のステップＳ０２２で、全てのユーザの移動計画にしたがった乗換え需要が、移動需要履歴データと組み合わされ、第２の輸送サービスと連結する、例えば第１の輸送サービスおよび第２の輸送サービスを連結する乗換駅１０００ｓの地理的距離と整合される。第３のステップＳ０２３で、移動需要履歴データ、公共輸送システムを使用する全ての乗客の移動計画、気象データ、および第２の輸送サービスの乗換駅１０００ｓとの間の地理的距離が、訓練済み機械学習部またはその目的のために訓練される人工知能（ＡＩ）に対する入力として使用される。第４のステップＳ０２４で、乗換え需要値が機械学習部／ＡＩ部の結果として出力される。

乗換え需要値の決定については、以下の例にしたがってさらに説明する。以下の表は、乗換え需要値を決定する際に使用されるものとする、機械学習部／ＡＩ部の訓練中に使用されてもよい例示的なデータセットを示す。

表１は、バス路線４で市の中心地に到着する乗客に接続を提供する、列車路線ＴＲ１の例示的な詳細を示している。この例は月曜のものであるが、他の任意の日、時間、路線などに対してより大きいデータセットを使用することができる。

表２は、一対の輸送サービス間の各停留所で乗り降りする乗客の履歴データを示している。

表３は、上記表２に示される移動需要履歴から、７：００～８：００ＡＭの期間中におけるバス４と列車ＴＲ１との間の乗換え需要を抽出した結果を示している。

表４は、異なる日の異なるタイムスロットに対する、バス４および列車ＴＲ１以外のサービス間での乗換え需要を示している。

表５は、機械学習部を訓練するのに使用される気象データの例示的なデータセットを示している。

表６は、公共輸送システムの駅間の地理的距離の表を示している。

表７は、スマートチケッティングからの履歴データによる、１つの輸送サービスから別のものに乗り換えた乗客の例示的な数を示している。

表８は、例示的な現在の日の気象読取値を示している。

表９は、機械学習プロセスに基づいて乗換え需要を決定した結果を示している。

上記の表１～９は、機械学習部／ＡＩ部の訓練に使用されてもよいデータセットの簡潔な例を表しており、当然ながら、より多くの／より大きいデータセットが使用されてもよく、訓練プロセスは、多くの対応するデータセットを用いて複数回繰り返されてもよい。

図１５は、乗換え需要値の決定に使用される気象履歴データの例示的な表を示している。表は、日付、時間、日時に対応する温度値、および日時に対応する降雨値を含む。この表に含まれるデータは、乗換え需要予測のプロセスのステップＳ０２１で乗換え需要履歴を決定するのに使用される。

図１６は、乗換え需要値を決定するのに使用される、第１の輸送サービスの駅と第２の輸送サービスの駅との間の地理的距離の例示的な表を示している。表は、第１の輸送サービスの駅の駅ＩＤ、第２の輸送サービスの駅の駅ＩＤ、および第１の輸送サービスの駅と第２の輸送サービスの駅との間の地理的距離を含む。表に含まれるデータは、乗換え需要値を決定するプロセスの第２のステップＳ０２２で使用される。「関係」の値は、好ましくは、距離／長さの単位を有するものとみなされる。

図１７は、第１の輸送サービスの駅と第２の輸送サービスの駅との間の乗換え需要予測の結果の例示的な表を示している。表は、一日の間の予め定められた間隔を表すタイムスロット、乗客旅程の始点を表す第１の輸送サービスの駅の駅ＩＤ、乗客旅程の終点を表す第２の輸送サービスの駅の駅ＩＤ、および乗換え需要予測部によって決定される乗換え需要値を含む。

図１８は、到着時間予測部１１０２によって実施される到着時間予測のアルゴリズムを説明するフローチャートを示している。第１のステップＳ０３１で、到着時間予測部は、座標および対応するタイムスタンプを乗客の携帯デバイス１２００から受信する。第２のステップＳ０３２および第３のステップＳ０３３で、到着時間予測部１１０２は、特定の乗客が使用する輸送サービスおよび乗客が乗る輸送車両を識別するために、乗客の座標および対応するタイムスタンプと、データベースから取得した利用可能な輸送路線のスケジュールデータおよび座標とのマップ整合を実施する。

第４のステップＳ０３４で、データベース１１０５から抽出した以前の輸送サービス区間の移動時間および上記輸送サービス区間の移動時間履歴と、各輸送サービス区間に対応する地理的距離とが組み合わされ、訓練済み機械学習部またはＡＩ部に入力される。第５のステップＳ０３５で、訓練済み機械学習部は、入力データに基づいて、この先にある輸送サービス区間の移動時間を決定する。第６のステップＳ０３６で、訓練済み機械学習部はまた、輸送車両が現在通っている輸送サービス区間の先にある駅における輸送車両の到着時間を決定する。第７のステップＳ０３７で、予測到着時間が到着時間予測部１１０２によって出力される。

到着時間の決定については、以下の例にしたがって更に説明する。以下の表は、到着時間の決定に使用される訓練済み機械学習部／ＡＩ部の訓練で使用することができる、例示的なデータセットを示している。

表１０は、列車路線１への接続を提供するバス路線４の詳細を示している。

表１１は、乗客ＧＰＳログの一例を示している。ＩＤ１の乗客は、停留所１８２にちょうど到着したバス＃１８２４に乗っている。乗客は、所在地シーケンス１でバスに乗ってから追跡されている。

表１２は、座標ならびに対応する乗客のタイムスタンプおよび公共輸送システムのスケジュールデータを参照しながら、乗客の所在地が輸送車両および輸送サービス区間のＩＤと整合される、マップ整合の一例を示している。

表１３は、第１の輸送サービスにおける輸送車両の履歴移動時間の一例を示している。

表１４は、乗客が前の区間２４４＿１８０および１８０＿１８２を通った後の、機械学習モデルによる後続の輸送サービス区間１８２＿１９１および１９１＿１８７の移動時間の一例を示している。

表１５は、輸送車両が上記に示した後続の輸送サービス区間を通るのにかかるであろう移動時間を機械学習モデルが決定した後の、到着時間の推定値を示している。

図１９は、到着時間予測に使用される、第１の輸送サービスにおける輸送サービス区間の間の地理的距離の例示的な表を示している。表は、第１の輸送サービス区間の区間ＩＤ、第２の輸送サービス区間の区間ＩＤ、および第１の輸送サービス区間と第２の輸送サービス区間との間の地理的距離を含む。この表に含まれるデータは、到着時間予測のアルゴリズムのステップ４で使用される。

図２０は、到着時間予測に使用される、第１の輸送サービスにおける各輸送サービス区間の抽出した移動時間の例示的な表を示している。表は、輸送サービス区間ＩＤ、一日の間の予め定められた間隔を表すタイムスロット、輸送車両ＩＤ、および輸送車両がそれぞれの輸送サービス区間を移動するのにかかった時間を表す移動時間を含む。この表に含まれるデータは、到着時間予測のアルゴリズムのステップ４で使用される。

図２１は、第１の輸送サービスにおける所与の輸送サービス区間の予測移動時間の例示的な表を示している。表は、輸送サービス区間ＩＤ、一日の間の予め定められた間隔を表すタイムスロット、およびそれぞれの輸送サービス区間における輸送車両の予測移動時間を含む。

図２２は、対応する輸送サービスの後続の停留所それぞれにおける、輸送車両によって移動する各乗客の予測到着時間の例示的な表を示している。表は、乗客と関連付けられたユーザＩＤ、タイムスタンプ、タイムスタンプに対応する乗客の現在の座標、輸送車両に乗っている乗客の走行速度、および輸送サービスの後続の停留所それぞれに到着するまでの時間のインジケータを含む。

図２３は、ドウェル時間分析部１１０３によって実施されるドウェル時間決定のアルゴリズムを説明するフローチャートを示している。第１のステップＳ０４１で、ドウェル時間分析部は、第１の輸送サービスと第２の輸送サービスとの間の乗換え駅１０００における第１の輸送サービスの車両の予測到着時間、および上記乗換え駅１０００における第２の輸送サービスの輸送車両の出発時間から、可能なドウェル時間のセットを決定する。第２のステップＳ０４２で、輸送車両のドウェル時間の延長および／または巡航速度の低減が実現された場合の、第２の輸送サービスの輸送車両の遅延、および第２の輸送サービスの他の輸送車両の遅延が決定される。

第３のステップＳ０４３で、ドウェル時間および／または巡航速度によって引き起こされる、第２の輸送サービスの輸送車両に乗っているかまたはそれを待っている乗客に対する影響を表す影響パラメータが決定される。このステップは、乗換え駅１０００における乗換え需要値、差し迫った乗換え駅１０００の後の駅における乗換え需要値、および差し迫った乗換駅１０００に輸送車両に続いて達する列車の乗換え需要値を使用して実施される。それぞれの乗換え需要値は、図１４に記載したような乗換え需要予測部によって以前に決定されている。

第４のステップＳ０４４で、ドウェル時間分析部１１０３は、影響パラメータの値が予め定められた閾値を上回るかまたは下回るかを決定してもよい。第５のステップＳ０４５で、値が予め定められた閾値を上回る場合、ドウェル時間および／または巡航速度を含む推奨データは発行されない。値が予め定められた閾値を下回る場合、ドウェル時間および／または巡航速度を含む推奨データが発行される。公共輸送システムが全自動方式で制御される場合、ドウェル時間および／または巡航速度は直接実現されてもよい。推奨ドウェル時間および／または巡航速度が推奨データの形態で車両オペレータインターフェースに伝送される場合、列車オペレータが、ドウェル時間および／または巡航速度を実現するか否かを判断する。

影響パラメータは、総コストパラメータまたは上記コストパラメータの値それぞれによって表されてもよい。コストパラメータは、総コストパラメータ値を決定するのに合計されてもよい、システムの異なる部分の想定コストに基づいて計算されてもよい。コストが計算されてもよいシステムの部分は、乗客のコストおよび輸送サービス事業者のコストを含んでもよい。乗客のコストは、各乗客の平均値を仮定することによって決定されてもよく、例えば、ある乗客の一時間は既定の金額の時間値を有してもよい。既定の額は、その国で一人が一時間当たり稼ぐ平均金額などに基づいて規定されてもよい。乗客の平均時間値に基づいて、接続に間に合わないことによって引き起こされる待機コスト、移動の遅延による移動コストの増加、乗換えコストなど、異なるコストが計算され合計されてもよい。

更に、乗客のコストをデフォルト条件と比較することが可能であり、即ち、予定時間表／移動計画と比較したコストの増加を、絶対コストの代わりに計算することができる。更に、事業者コストは乗客コストと同様に計算されてもよく、平均時間値は、事業者の一時間当たりの平均キャッシュフローまたは一時間当たりの平均運行コストなどに基づいて仮定または予め規定されてもよい。ドウェル時間の遅延または適応が、多数の乗客が接続に間に合わないことにつながるような場合、影響は、総コストパラメータ値によって、例えば、乗客の数を移動時間の増加および平均時間値で乗算することによって、表すことができる。

同じことを輸送サービスの事業者に対して実施することができ、例えば、事業者は、追加のサービス人員、追加車両などを提供することによる、追加コストを有することがある。事業者の総コストが分かっているか、または別の方法で決定することができる場合、値は、上述した事業者の時間値を使用せずに計算することもできる。ドウェル時間の増加、走行速度の低減、遅延などによって引き起こされる、乗客コストの合計と事業者コストの合計との合計であってもよい、総コストパラメータ値の上述の計算に基づいて、影響、即ち影響パラメータを決定することができる。好ましくは、影響パラメータは総コストパラメータであり、上記総コストパラメータ値が大きいほど、走行速度および／またはドウェル時間の変化によって引き起こされる望ましくない影響は大きくなる。

したがって、最大許容可能な影響を示す閾値が、前もって設定されてもよく、走行速度および／またはドウェル時間を適応させる推奨は、総コスト／影響パラメータ値と閾値との比較に基づいて判断されてもよい。走行速度および／またはドウェル時間を適応させる推奨を発行するための別の選択肢は、ドウェル時間分析部が、異なるドウェル時間のセットを決定し、各ドウェル時間（および／または走行速度）に対して総コストパラメータ値を計算することであってもよい。適応されたドウェル時間（および／または走行速度）のうち１つに対する総コストパラメータ値が、例えば輸送車両の遅延が起こったとき、ドウェル時間を適応することなく走行計画の値未満であるべきであることが見出された場合、それによって推奨の発行も行われてもよい。換言すれば、ドウェル時間分析部によって決定されるようなドウェル時間および／または走行速度の適応は、総コストパラメータ値を最小限に抑えるものとする。

更に、輸送デバイスのドウェル時間または走行／巡航速度が適応されるべきである場合、好ましくは総コストパラメータである影響パラメータは、好ましくは最小限に抑えられ、つまり、最も低い可能な影響パラメータ値が決定され、ドウェル時間および／または走行速度の対応する適応が推奨に使用される。

概して、本開示は、第１の輸送サービスの駅から第２の輸送サービスの駅までの、上記輸送サービス間での乗換えを伴う旅程を完了するために、複数の輸送サービスを使用して乗客をより効率的に輸送する技術的効果を提供する、特許請求する装置によって提供される、公共輸送システムの全自動または一部自動の制御を提供する。

更に、特許請求する装置、システム、および対応する方法は、例えば、第１の輸送サービスの運行の遅延が理由で第２の輸送サービスの輸送車両に間に合わなかったであろう複数の乗客が、乗換え駅１０００における上記輸送車両のドウェル時間の延長によって第２の輸送サービスの輸送車両に間に合うことができるとき、作業負荷ピークを回避することによって、輸送車両の輸送能力をより効率的に使用できるようにする。更に、第２の輸送サービスの輸送車両の作業負荷は、したがって、特許請求する装置によって均等化することができ、第１の輸送サービスの遅延によって引き起こされる作業負荷ピークの低減は、輸送車両の摩耗および亀裂の低減をもたらす。

これはまた、制御される公共輸送システムの予定運行の乱れが、特許請求する主題によるドウェル時間の決定によって軽減されるという利点を提供する。

当業者には認識されるように、本開示は、上記および添付図面に記載するように、方法、装置（デバイス、機械、システム、コンピュータプログラム製品、および／または他の任意の装置を含む）、あるいは上記の組み合わせとして具体化されてもよい。

したがって、本開示の実施形態は、全体的にハードウェアの実施形態、全体的にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本明細書では一般に「システム」と呼ばれることがある、ソフトウェアとハードウェアの態様を組み合わせた実施形態の形態を取ってもよい。更に、本開示の実施形態は、コンピュータ実行可能プログラムコードが媒体上で具体化された、コンピュータ可読媒体上のコンピュータプログラム製品の形態を取ってもよい。

２つ以上のエンティティが関与する通信、転送、または他の作業を表すため、矢印が図面中で使用されることがあることが注目されるべきである。両側矢印は、一般に、作業が両方向で起こり得ることを示すが（例えば、一方向でのコマンド／要求と、それに対応する他方向での返信、またはどちらかのエンティティによって開始されるピアツーピア通信）、状況によっては、作業は必ずしも両方向で起こらなくてもよい。

片側矢印は、一般に、排他的または主に一方向の作業を示すことがあるが、特定の状況では、かかる指向性の作業は、実際には両方向での作業を伴うことがある（例えば、送信者から受信者へのメッセージと、受信者から送信者への受領の返信、または転送前の接続の確立と、転送後の接続の終了）ことが注目されるべきである。したがって、特定の作業を表すのに特定の図で使用される矢印のタイプは、例示であって限定と見るべきではない。

方法および装置のフローチャート図および／またはブロック図を参照して、またそれらの方法および／または装置によって生成されるグラフィカルユーザインターフェースの多数のサンプル図を参照して、態様について上述している。フローチャート図および／またはブロック図における各ブロック、ならびに／あるいはフローチャート図および／またはブロック図におけるブロックの組み合わせ、ならびにグラフィカルユーザインターフェースは、コンピュータ実行可能プログラムコードによって実現できることが理解されるであろう。

コンピュータ実行可能プログラムコードは、特定の機械を作成するのに、汎用コンピュータ、専用コンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供されてもよく、それによって、コンピュータまたは他のプログラマブルデータ処理装置を介して実行するプログラムコードは、フローチャート、ブロック図のブロック、図面、および／または記述において指定された機能／行為／出力を実現する手段を作成する。

これらのコンピュータ実行可能プログラムコードはまた、コンピュータまたは他のプログラマブルデータ処理装置に特定の方式で機能するように指令することができる、コンピュータ可読メモリに格納されてもよく、それによって、コンピュータ可読メモリに格納されたプログラムコードは、フローチャート、ブロック図のブロック、図面、および／または記述において指定された機能／行為／出力を実現する命令手段を含む、製品を作成する。

コンピュータ実行可能プログラムコードはまた、コンピュータまたは他のプログラマブルデータ処理装置にロードされて、一連の動作ステップをコンピュータまたは他のプログラマブル装置上で実施させて、コンピュータ実装プロセスを生成してもよく、それによって、コンピュータまたは他のプログラマブル装置上で実行するプログラムコードは、フローチャート、ブロック図のブロック、図面、および／または記述において指定された機能／行為／出力を実現するステップを提供する。あるいは、コンピュータプログラムが実現するステップまたは行為は、実施形態を実施するために、オペレータまたは人が実現するステップもしくは行為と組み合わされてもよい。

「サーバ」および「プロセッサ」などの用語は、本明細書では、特定の実施形態で使用されてもよいデバイスについて記載するのに使用されることがあり、文脈において別段の必要性がない限り、任意の特定のデバイスタイプに限定するものと解釈すべきではないことが注目されるべきである。したがって、デバイスは、非限定的に、ブリッジ、ルータ、ブリッジルータ（ブルータ）、スイッチ、ノード、サーバ、コンピュータ、器具、または他のタイプのデバイスを含んでもよい。かかるデバイスは、一般的に、通信ネットワークを通じて通信するための１つまたは複数のネットワークインターフェースと、デバイス機能を適宜実施するように構成されたプロセッサ（例えば、メモリおよび他の周辺機器および／または特定用途向けハードウェアを備えたマイクロプロセッサ）とを含む。

通信ネットワークは、一般に、公衆および／または私設ネットワークを含んでもよく、ローカルエリア、ワイドエリア、メトロポリタンエリア、ストレージ、および／または他のタイプのネットワークを含んでもよく、アナログ技術、デジタル技術、光学技術、無線技術（例えば、ブルートゥース（登録商標））、ネットワーキング技術、およびインターネットワーキング技術を含むがいかなる形でもそれらに限定されない、通信技術を採用してもよい。

また、デバイスは、通信プロトコルおよびメッセージ（例えば、デバイスによって作成、送信、受信、格納、および／または処理されるメッセージ）を使用してもよく、かかるメッセージは、通信ネットワークまたは媒体によって搬送されてもよいことが注目されるべきである。

文脈において別段の必要性がない限り、本開示は、任意の特定の通信メッセージタイプ、通信メッセージ形式、または通信プロトコルに限定されるものと解釈されるべきではない。したがって、通信メッセージは、一般に、フレーム、パケット、データグラム、ユーザデータグラム、セル、または他のタイプの通信メッセージを非限定的に含んでもよい。

文脈において別段の必要性がない限り、特定の通信プロトコルについての言及は例示であり、代替実施形態は、適切であれば、かかる通信プロトコルの変形例（例えば、たびたび行われることがあるプロトコルの修正もしくは拡張）、または既知であるかもしくは将来開発される他のプロトコルを採用してもよいことが理解されるべきである。

また、論理フローは、本明細書では様々な態様を実証するために記載されることがあり、本開示を任意の特定の論理フローまたは論理実装に限定するものと解釈されるべきではないことが、注目されるべきである。記載する論理は、全体の結果を変えることなく、異なる論理ブロック（例えば、プログラム、モジュール、機能、またはサブルーチン）に分割されてもよい。

多くの場合、論理素子は、全体の結果を変えることなく、追加、修正、省略、異なる順序で実施、または異なる論理構成概念（例えば、論理ゲート、ループ型プリミティブ、条件付き論理、および他の論理構成概念）を使用して実装されてもよい。

本開示は、プロセッサ（例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、もしくは汎用コンピュータ）とともに使用されるコンピュータプログラム論理、プログラマブル論理デバイス（例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のＰＬＤ）とともに使用されるプログラマブル論理、離散的構成要素、集積回路類（例えば、特定用途向け集積回路（ＡＳＩＣ））、またはそれらの任意の組み合わせを含む他の任意の手段を含むがいかなる形でもそれらに限定されない、多くの異なる形態で具体化されてもよい。

記載した機能性の一部または全てを実現するコンピュータプログラム論理は、一般的に、コンピュータ実行可能な形態に変換され、それ自体でコンピュータ可読媒体に格納され、オペレーティングシステムの制御下でマイクロプロセッサによって実行される、一連のコンピュータプログラム命令として実現される。記載した機能性の一部または全てを実現するハードウェアベースの論理は、１つまたは複数の適切に構成されたＦＰＧＡを使用して実現されてもよい。

本明細書に上述した機能性の全てまたは一部を実現するコンピュータプログラム論理は、ソースコード形態、コンピュータ実行可能な形態、および様々な中間形態（例えば、アセンブラ、コンパイラ、リンカ、もしくはロケータによって生成される形態）を含むがいかなる形でもそれらに限定されない、様々な形態で具体化されてもよい。

ソースコードは、様々なオペレーティングシステムまたはオペレーティング環境とともに使用するため、様々なプログラミング言語（例えば、オブジェクトコード、アセンブリ言語、またはＦｏｒｔｒａｎ、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、もしくはＨＴＭＬなどの高水準言語）のいずれかで実現される、一連のコンピュータプログラム命令を含んでもよい。ソースコードは、様々なデータ構造および通信メッセージを定義し使用してもよい。ソースコードは、（例えば、インタープリタを介して）コンピュータ実行可能な形態であってもよく、またはソースコードは、（例えば、トランスレータ、アセンブラ、もしくはコンパイラを介して）コンピュータ実行可能な形態に変換されてもよい。

本開示の実施形態の動作を実施するためのコンピュータ実行可能プログラムコードは、Ｊａｖａ、Ｐｅｒｌ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋など、オブジェクト指向、スクリプト型、または非スクリプト型のプログラミング言語で書かれてもよい。しかしながら、実施形態の動作を実施するためのコンピュータプログラムコードはまた、「Ｃ」プログラミング言語または類似のプログラミング言語など、従来の手続き型プログラミング言語で書かれてもよい。

本明細書に上述した機能性の全てまたは一部を実現するコンピュータプログラム論理は、単一のプロセッサにおいて異なる時間に（例えば、同時に）実行されてもよく、または複数のプロセッサで同じもしくは異なる時間に実行されてもよく、単一のオペレーティングシステムプロセス／スレッド下で、もしくは異なるオペレーティングシステムプロセス／スレッド下で稼働してもよい。

したがって、「コンピュータプロセス」という用語は、一般に、異なるコンピュータプロセスが同じプロセッサもしくは異なるプロセッサのどちらで実行されるかにかかわらず、また異なるコンピュータプロセスが同じオペレーティングシステムプロセス／スレッド下もしくは異なるオペレーティングシステムプロセス／スレッド下のどちらで稼働するかにかかわらず、一連のコンピュータプログラム命令を実行することを指してもよい。

コンピュータプログラムは、半導体メモリ素子（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、もしくはフラッシュプログラマブルＲＡＭ）、磁気メモリ素子（例えば、ディスケットもしくは固定ディスク）、光学メモリ素子（例えば、ＣＤＲＯＭ）、ＰＣカード（例えば、ＰＣＭＣＩＡカード）、または他のメモリ素子など、有形記憶媒体内で、任意の形態（例えば、ソースコード形態、コンピュータ実行可能形態、もしくは中間形態）で恒久的または過渡的に固定されてもよい。

コンピュータプログラムは、アナログ技術、デジタル技術、光学技術、無線技術（例えば、ブルートゥース（登録商標））、ネットワーキング技術、およびインターネットワーキング技術を含むがそれらに限定されない、様々な通信技術の任意のものを使用してコンピュータに伝送可能な、任意の形態の信号で固定されてもよい。

コンピュータプログラムは、印刷文書または電子文書を備えたリムーバブル記憶媒体（例えば、シュリンク包装されたソフトウェア）として任意の形態で配布され、コンピュータシステムに（例えば、システムＲＯＭもしくは固定ディスクに）事前ロードされるか、またはサーバもしくは電子掲示板から通信システム（例えば、インターネットもしくはワールドワイドウェブ）を通じて配布されてもよい。

本明細書に上述した機能性の全てまたは一部を実現するハードウェア論理（プログラマブル論理デバイスとともに使用されるプログラマブル論理を含む）は、従来の手動方法を使用して設計されてもよく、またはコンピュータ支援設計（ＣＡＤ）、ハードウェア記述言語（例えば、ＶＨＤＬもしくはＡＨＤＬ）、またはＰＬＤプログラミング言語（例えば、ＰＡＬＡＳＭ、ＡＢＥＬ、もしくはＣＵＰＬ）などの様々なツールを使用して、設計、キャプチャ、シミュレート、または電子文書化されてもよい。

任意の適切なコンピュータ可読媒体が利用されてもよい。コンピュータ可読媒体は、例えば、それらに限定されないが、電子、磁気、光学、電磁、赤外、または半導体システム、装置、デバイス、または媒体であってもよい。

コンピュータ可読媒体のより具体的な例としては、１つもしくは複数のワイヤを有する電気接続、あるいはポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読出し専用メモリ（ＥＰＲＯＭもしくはフラッシュメモリ）、コンパクトディスク読出し専用メモリ（ＣＤ－ＲＯＭ）、または他の光学もしくは磁気記憶素子など、他の有形記憶媒体が挙げられるが、それらに限定されない。

プログラマブル論理は、半導体メモリ素子（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、もしくはフラッシュプログラマブルＲＡＭ）、磁気メモリ素子（例えば、ディスケットもしくは固定ディスク）、光学メモリ素子（例えば、ＣＤ－ＲＯＭ）または他のメモリ素子など、有形記憶媒体内で恒久的または過渡的に固定されてもよい。

プログラマブル論理は、アナログ技術、デジタル技術、光学技術、無線技術（例えば、ブルートゥース（登録商標））、ネットワーキング技術、およびインターネットワーキング技術を含むがいかなる形でもそれらに限定されない、様々な通信技術の任意のものを使用してコンピュータに送信可能な信号の形で固定されてもよい。

プログラマブル論理は、印刷文書または電子文書を備えたリムーバブル記憶媒体（例えば、シュリンク包装されたソフトウェア）として配布され、コンピュータシステムに（例えば、システムＲＯＭもしくは固定ディスクに）事前ロードされるか、あるいはサーバまたは電子掲示板から通信システム（例えば、インターネットもしくはワールドワイドウェブ）を通じて配布されてもよい。当然ながら、いくつかの態様は、ソフトウェア（例えば、コンピュータプログラム製品）およびハードウェア両方の組み合わせとして実現されてもよい。更に他の実施形態は、全体的にハードウェアまたは全体的にソフトウェアとして実現されてもよい。

特定の例示的態様について記載し添付図面に図示してきたが、かかる態様は例証であり、上記段落で説明したものに加えて、他の様々な変更、組み合わせ、省略、修正、および置換が可能であるため、実施形態は、図示し記載した特定の構造および構成に限定されないことが、理解されるべきである。

当業者であれば、上述の実施形態の様々な適応、修正、および／または組み合わせを構成できることを認識するであろう。したがって、添付の特許請求の範囲内で、本明細書に具体的に記載する以外の形で本開示が実践されてもよいことが理解されるべきである。例えば、別段の明示的な言及がない限り、本明細書に記載するプロセスのステップは、本明細書に記載するのとは異なる順序で実施されてもよく、１つもしくは複数のステップが組み合わされるか、分割されるか、または同時に実施されてもよい。また、当業者であれば、本開示に照らして、本明細書に記載する異なる実施形態または態様が組み合わされて、他の実施形態を形成してもよいことを認識するであろう。

１０００ 乗換え駅
１１００ バックエンドサーバシステム
１１０１ 乗換え需要予測部
１１０２ 到着時間予測部
１１０３ ドウェル時間分析部
１１０４ フィードバック部
１１０５ データベース
１２００ 乗客の携帯デバイス
１２０１ 移動計画
１２０２ 所在地情報
１３００ 輸送車両オペレータ
１４００ 列車運行管理システム

Claims (15)

1. 輸送サービスを使用する乗客の移動履歴データを格納するように構成されたデータベースと、
   移動計画を前記輸送サービスを使用している前記乗客の複数の携帯デバイスのそれぞれから受信し、受信した前記移動計画および前記移動履歴データに基づいて、乗換え需要値として第１の輸送サービスと第２の輸送サービスの間で乗り換えようとしている前記乗客の数を決定するように構成された乗換え需要予測部と、
   前記第１の輸送サービスと前記第２の輸送サービスとの間で乗り換える駅における前記第１の輸送サービスの輸送車両の到着時間を予測するように構成された到着時間予測部と、
   前記乗換え需要値を前記乗換え需要予測部から前記第１の輸送サービスの輸送車両の前記予測到着時間を前記到着時間予測部から受信し、前記予測到着時間に基づいて、駅における前記輸送車両の巡航速度および前記第２の輸送サービスの少なくとも１つのドウェル時間を決定するように構成されたドウェル時間分析部と、
   を有する公共輸送システムの制御装置。
2. 前記データベースは、
   路線および駅の座標、利用可能な輸送サービスのスケジュールデータおよび前記輸送サービスの到着および出発時間履歴を更に格納し、
   前記制御装置は、
   前記移動履歴データ、前記路線、前記駅の前記座標、前記輸送サービスの前記到着および出発時間履歴を前記データベースから受信するように構成された移動需要予測部を有し、
   前記移動需要予測部は、
   前記移動履歴データを前記路線及び前記駅の前記座標と整合することによる乗客旅程履歴、前記輸送サービスの前記到着および出発時間履歴を含む移動発着地表データを生成するように構成された請求項１に記載の公共輸送システムの制御装置。
3. 前記移動履歴データは、
   全旅程に沿った乗客の各所在地に対する所在地情報およびタイムスタンプを含む前記乗客のスマートカードまたは前記携帯デバイスからのデータを含み、
   前記履歴データは、
   既存の輸送システムに乗降する時の前記乗客の所在地および前記タイムスタンプを含むｂｅ－ｉｎ／ｂｅ－ｏｕｔスマートチケットからのデータを含む請求項２に記載の公共輸送システムの制御装置。
4. 前記乗換え需要予測部は、
   入力として、前記移動発着地表データおよび実際の乗換え需要を前記乗客から受信して、前記乗換え需要値を生成する訓練済み機械学習部を有する請求項２に記載の公共輸送システムの制御装置。
5. 前記乗換え需要予測部は、
   前記データベースに格納された異なる輸送サービスの駅間の地理的距離に関するデータを受信し、
   前記訓練済み機械学習部は、
   前記乗換え需要値を決定するための更なる入力として、前記地理的距離を使用する請求項４に記載の公共輸送システムの制御装置。
6. 前記データベースは、
   気象情報を格納するように構成され、
   前記乗換え需要予測部の前記訓練済み機械学習部は、
   前記気象情報に関する追加情報に基づいて、前記第１の輸送サービスの各駅と前記第２の輸送サービスの各駅との間の前記乗換え需要値を推定するように構成された請求項４に記載の公共輸送システムの制御装置。
7. 前記到着時間予測部は、
   前記輸送サービスを使用する前記乗客の前記複数の携帯デバイスから前記タイムスタンプを受信し、前記タイムスタンプを前記データベースに格納された前記路線および前記駅の前記座標および前記利用可能な輸送サービスの前記スケジュールデータと整合するように構成され、
   前記到着時間予測部は、
   前記複数の携帯デバイスからの前記所在地情報に基づいて、前記輸送サービスの実際の移動時間を評価し、前記移動履歴データに基づいて前記輸送サービスの前記移動時間を評価し、前記輸送サービスの次の駅の予測到着時間を推定するように構成された訓練済み機械学習部を有する請求項１に記載の公共輸送システムの制御装置。
8. 前記ドウェル時間分析部は、
   推奨データを輸送車両オペレータに対して発行するように構成され、
   前記推奨データに基づいて、前記第２の輸送サービスの前記輸送車両の前記ドウェル時間および前記輸送車両の前記巡航速度の少なくとも１つを選択するように構成され、
   前記輸送車両オペレータが、人間のオペレータおよびコンピュータベースの少なくとも１つの制御エンティティである請求項１に記載の公共輸送システムの制御装置。
9. 前記ドウェル時間分析部によって決定される前記ドウェル時間または前記巡航速度に関する遅延を決定するように構成され、
   前記遅延は、
   前記第２の輸送サービスの前記駅における前記輸送車両の遅延時間、前記輸送車両内の前記乗客の遅延および前記第２の輸送サービスの他の輸送車両の遅延時間の少なくとも１つを含み、
   前記遅延が既定の閾値未満の場合、前記ドウェル時間分析部は、
   前記ドウェル時間および前記巡航速度の少なくとも１つを選択する推奨を含む前記推奨データを生成するように構成された請求項８に記載の公共輸送システムの制御装置。
10. 総コストパラメータに関する影響パラメータを決定するように構成され、
    前記影響パラメータが既定の閾値未満の場合、前記ドウェル時間分析部は、
    前記ドウェル時間および前記巡航速度の少なくとも１つを選択する前記推奨を含む前記推奨データを生成するように構成された請求項８に記載の公共輸送システムの制御装置。
11. 前記制御装置は、
    前記第２の輸送サービスの前記輸送車両の更新後出発時間を前記輸送車両の前記オペレータから受信し、前記更新後出発時間を前記複数の乗客デバイスに伝送するように構成されたフィードバック出発時間更新部を有する請求項１に記載の公共輸送システムの制御装置。
12. 前記輸送車両オペレータが前記人間のオペレータである場合、
    前記制御装置は、
    前記推奨データを表示し、前記ドウェル時間および前記巡航速度の少なくとも１つを選択するよう前記人間のオペレータに指示するように構成されたグラフィカルユーザインターフェースを有し、
    前記輸送車両オペレータが前記コンピュータベースの制御エンティティである場合、
    前記輸送車両オペレータは、
    前記推奨データを受信し、前記ドウェル時間および前記巡航速度の少なくとも１つを適用することを含む制御信号を発行する請求項１に記載の公共輸送システムの制御装置。
13. 輸送サービスを使用する乗客のタイムスタンプを含む移動計画および所在地情報を送信するように構成された複数の乗客携帯デバイスと、
    輸送車両のオペレータおよびコンピュータベースの少なくとも１つの制御装置のためのグラフィカルユーザインターフェースと、
    前記複数の乗客携帯デバイスおよび前記オペレータまたは前記コンピュータベースの制御装置と通信するように構成されたバックエンドサーバシステムと、を有し、
    前記バックエンドサーバシステムは、
    請求項１の前記制御装置を有する公共輸送システム。
14. 輸送サービスを使用する乗客の複数の携帯デバイスから、移動計画および所在地情報を受信するステップと、
    受信した前記移動計画および移動履歴データに基づいて、２つの異なる輸送サービス間で乗り換えようとする乗客の数に対応する乗換え需要を推定するステップと、
    前記乗客の前記携帯デバイスから受信した前記所在地情報およびタイムスタンプを、第１のサービスの路線およびスケジュールデータと比較することによって、前記乗客が使用する第１の輸送サービスの車両を識別するステップと、
    前記移動履歴データに基づいて、前記第１のサービスおよび第２のサービスの間で乗り換えるための乗換駅の到着時間を予測するステップと、
    前記第１のサービスの前記推定到着時間に基づいて、駅における前記第２のサービスの輸送車両のドウェル時間を計算するステップと、
    有する適応出発時間決定方法。
15. コンピュータによって実施されたとき、前記コンピュータに請求項１４の前記適応出発時間決定方法を実施させるメモリに格納可能なコンピュータプログラム製品。

Images