特許 7659396 料金収受システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-04-01

(45)【発行日】2025-04-09

(54)【発明の名称】料金収受システム

(51)【国際特許分類】

   G06F 11/20 20060101AFI20250402BHJP

【ＦＩ】

G06F11/20 625

【請求項の数】 5

(21)【出願番号】P 2021009972

(22)【出願日】2021-01-26

(65)【公開番号】P2022113940

(43)【公開日】2022-08-05

【審査請求日】2023-11-14

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】598076591

【氏名又は名称】東芝インフラシステムズ株式会社

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(72)【発明者】

【氏名】笠井 勇生

(72)【発明者】

【氏名】弓倉 陽介

【審査官】三坂 敏夫

(56)【参考文献】

【文献】特開２００４－１０２６６６（ＪＰ，Ａ）

【文献】特開２０１１－１５０４５９（ＪＰ，Ａ）

【文献】特開２０２０－１３５２０１（ＪＰ，Ａ）

【文献】特開２０１７－１８２３８０（ＪＰ，Ａ）

【文献】特開２０１９－００８６５７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １１／１６－１１／２０

Ｇ０７Ｂ １５／００－１６／００

(57)【特許請求の範囲】

【請求項1】

有料道路を利用する車両の道路利用情報を収集する複数の料金所装置と、
前記料金所装置の設置場所とは異なるメインサイトにオンプレミスで構築され、前記複数の料金所装置と通信して前記収集された道路利用情報を記憶する運用系データベースを備え、当該複数の料金所装置を統制する運用系システムと、
前記運用系システムに対する待機系としてクラウド上に構築され、前記料金所装置で前記収集された道路利用情報を記憶する待機系データベースを備える待機系システムと、
前記運用系システムと前記待機系システムとを遠隔から切り替え運用するリモートサーバとを具備し、
前記リモートサーバは、
前記待機系データベースを前記運用系データベースに同期させる同期処理部と、
少なくとも１つの料金所装置と前記運用系システムとの通信障害を検知する障害検知部と、
前記障害検知部により通信障害が検出した場合に、前記運用系システムに対して、残存する料金所装置の識別子および通信アドレスを前記待機系システムに通知することと、同期が未完了の道路利用情報を前記待機系システムに送信することとを含む引継ぎ処理を実行させることにより、前記運用系システムの統制機能を前記待機系システムに引き継がせる切替制御部とを備える、料金収受システム。

【請求項2】

前記待機系システムは、前記運用系システムの設置場所から、同じ災害でダウンしない程度に地理的に離間した場所に設置する、
請求項１に記載の料金収受システム。

【請求項3】

前記同期処理部は、前記運用系システムが運用状態にあって、前記待機系システムは待機状態にある状態の時に、前記運用系システムに同期要求コマンドを送信し、これを受けた前記運用系システムが、前記待機系システムとの間で各データベースのデータを同期させる同期処理を行う、
請求項１に記載の料金収受システム。

【請求項4】

前記障害検知部は、前記通信障害の復旧を検知し、
前記切替制御部は、前記復旧が検知された場合に、前記待機系システムの前記統制機能を前記運用系システムに切り戻す、
請求項１に記載の料金収受システム。

【請求項5】

前記複数の料金所装置は、前記待機系システムと無線通信リンクを経由して通信する、
請求項１に記載の料金収受システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、料金収受システムに関する。

【背景技術】

【0002】

ＥＴＣ（Electronic Toll Collection System）は、有料道路等で既に広く普及している。この種の料金収受システムは、道路事業者により運営され、高い信頼性を求められる。殊に近年、豪雨災害や土砂災害の発生することが多くなってきており、ＥＴＣサイトなどが被災することも懸念される。このような背景から料金収受システムにおいても、いわゆるディザスタリカバリサイトを構築することが意識されるようになってきている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１１－１５０４５９号公報

【文献】特開２０１７－１１２６３１号公報

【文献】特開２０１８－５５５１８号公報

【文献】特開２００１－２４３５８７号公報

【発明の概要】

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

【0004】

ディザスタリカバリサイトは、通常時に運用されるメインサイトのバックアップとして捉えることができ、システム運用の継続性や、事業の継続性を確保するための手段として注目されている。しかし、料金収受システムのディザスタリカバリサイトを構築するには、費用や運用などの面で様々な困難があり、実現することが難しかった。特に、比較的小規模な運営事業体にとっては負担が大きい。運用継続性を担保する観点からも何らかの技術革新が求められる。
そこで、目的は、運用継続性を高めた料金収受システムを低コストで提供することにある。

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

【0005】

実施形態の料金収受システムは、有料道路を利用する車両の道路利用情報を収集する、複数の料金所装置を具備する料金収受システムである。この料金収受システムは、さらに、運用系システムと、待機系システムと、リモートサーバとを具備する。運用系システムは、料金所装置の設置場所とは異なるメインサイトにオンプレミスで構築され、複数の料金所装置と通信して当該複数の料金所装置を統制する統制機能を有する。待機系システムは、運用系システムに対する待機系としてクラウド上に構築される。リモートサーバは、運用系システムと待機系システムとを遠隔から切り替え運用する。

【図面の簡単な説明】

【0006】

【図1】図１は、実施形態に係わる料金収受システムの一例を示すシステム図である。

【図2】図２は、図１に示されるリモートサーバ２００の一例を示す機能ブロック図である。

【図3】図３は、実施形態に係わる料金収受システムで実行される処理手順の一例を示すシーケンス図である。

【図4】図４は、実施形態に係わる料金収受システムにおける運用の一例を示す模式図である。

【発明を実施するための形態】

【0007】

以下、図面を参照して実施形態について説明する。

【0008】

図１は、実施形態に係わる料金収受システムの一例を示すシステム図である。このシステムは、複数の料金所装置１１～１ｎ、リモートサーバ２００、およびメインサイト３００を備え、これらはネットワーク１００を介して互いに通信可能に接続される。さらに、料金所装置１１～１ｎ、リモートサーバ２００、およびメインサイト３００はネットワーク１００を経由して、クラウド４００の各種リソースやサービスを利用することができる。特に、ネットワーク１００は通信ノード２１～２ｎを備える。料金所装置１１～１ｎは無線通信リンクを介してそれぞれ通信ノード２１～２ｎに接続されることができる。

【0009】

図１において、料金所装置１１～１ｎはそれぞれ有料道路の入り口、出口、またはチェックポイント等の、道路事業者の管理区域に設置される。料金所装置１１～１ｎは、有料道路を利用する車両が通過するガントリＧに接続され、ガントリＧを通過した車両の道路利用情報を取得する。道路利用情報は、無線通信リンク、通信ノード２１～２ｎ、およびネットワーク１００を介してメインサイト３００に伝送される。

【0010】

メインサイト３００は、例えば道路事業者のオフィスなどの、料金所装置１１～１ｎの設置場所とは異なる場所に設置される。メインサイト３００は、運用系データベース３０２を有する運用系システム３０１を備える。

【0011】

運用系システム３０１は、メインサイト３００にオンプレミスで構築され、料金所装置１１～１ｎとネットワーク１００経由で通信して、料金所装置１１～１ｎを統制する。この機能を、統制機能と称する。運用系システム３０１は、料金所装置１１～１ｎから収集した道路利用情報を運用系データベース３０２に記憶する（道路利用情報３０３）。

【0012】

一方、実施形態においてクラウド４００は、待機系システム４０１を備える。待機系システム４０１は、運用系システム３０１に対する待機系としてクラウド４００上に構築される。ここで、待機系システム４０１は、例えば実コンピュータ上に仮想化技術により形成される仮想サーバであって良い。待機系システム４０１は、待機系データベース４０２を有する。待機系データベース４０２は運用系データベース３０２と同期され、道路利用情報４０３を記憶する、
リモートサーバ２００は、運用系システム３０１と待機系システム４０１とを、ネットワーク１００経由で遠隔から切り替え運用する。リモートサーバ２００は、料金所装置１１～１ｎ、メインサイト３００とは比較的離れた遠隔地に設置される。例えば、料金所装置１１～１ｎとメインサイト３００が同じ県内に設置されているとすれば、リモートサーバ２００は異なる県に設置されることが想定される。つまりリモートサーバ２００は、料金所装置１１～１ｎ、メインサイト３００が豪雨や土砂崩れなどの災害に仮に被災したとしても、同じ災害でダウンしない程度に地理的に離間することが好ましい。

【0013】

図２は、リモートサーバ２００の一例を示す機能ブロック図である。リモートサーバ２００は、ＲＯＭ（Read Only Memory）２２０、ＲＡＭ（Random Access Memory）２３０、および記憶部２４０と、プロセッサ２５０とを備えるコンピュータである。

【0014】

記憶部２４０は、例えばハードディスクドライブ（Hard Disk Drive：ＨＤＤ）、あるいはソリッドステートドライブ（Solid State Drive：ＳＳＤ）などの不揮発性ストレージであり、プロセッサ２５０により実行されるプログラム２４０ａを記憶する。

【0015】

ＲＯＭ２２０は、ＢＩＯＳ（Basic Input Output System）やＵＥＦＩ（Unified Extensible Firmware Interface）などの基本プログラム、および各種の設定データ等を記憶する。ＲＡＭ２３０は、記憶部２４０からロードされたプログラムやデータを一時的に記憶する。

【0016】

リモートサーバ２００は、さらに、光学メディアドライブ２６０、および、通信部２７０を備える。
光学メディアドライブ２６０は、ＣＤ－ＲＯＭ２８０などの記録媒体に記録されたディジタルデータを読み取る。リモートサーバ２００で実行される各種プログラムは、例えばＣＤ－ＲＯＭ２８０に記録されて頒布される。このＣＤ－ＲＯＭ２８０に格納されたプログラムは光学メディアドライブ２６０により読み取られ、記憶部２４０にインストールされる。

【0017】

通信部２７０は、通信機能を備え、ネットワーク１００との通信を制御する。リモートサーバ２００で実行される各種プログラムを、例えば通信部２７０を介してサーバからダウンロードし、記憶部２４０にインストールすることもできる。クラウド４００から通信部２７０を介して最新のプログラムをダウンロードし、インストール済みのプログラムをアップデートすることもできる。

【0018】

プロセッサ２５０は、ＯＳ（Operating System）および各種のプログラムを実行する。また、プロセッサ２５０は、実施形態に係る処理機能として同期処理部２５０ａ、障害検知部２５０ｂ、および、切替処理部２５０ｃを備える。同期処理部２５０ａ、障害検知部２５０ｂ、および、切替処理部２５０ｃは、記憶部２４０に記憶されたプログラム２４０ａがＲＡＭ２３０にロードされ、当該プログラムの進行に伴ってプロセッサ２５０が演算処理を実行することで生成されるプロセスとして、理解され得る。つまりプログラム２４０ａは、コンピュータであるリモートサーバ２００を、同期処理部２５０ａ、障害検知部２５０ｂ、および、切替処理部２５０ｃとして機能させる。

【0019】

同期処理部２５０ａは、定期的、あるいは不定期に、運用系システム３０１（または待機系システム４０１）にデータ同期要求コマンドを送信し、待機系データベース４０２を、運用系データベース３０２に同期させる。これにより、運用系データベース３０２に記憶される道路利用情報３０３と、待機系データベース４０２に記憶される道路利用情報４０３は同期した状態になる。
障害検知部２５０ｂは、料金所装置１１～１ｎと運用系システム３０１との通信状態を監視する。そして、料金所装置１１～１ｎのうち少なくとも１つと運用系システム３０１との通信障害を検知すると、切替処理部２５０ｃにそのことを通知する。また、通信できなくなっていた料金所装置と運用系システム３０１との間の通信が回復すると、障害検知部２５０ｂは通信障害の復旧を検知し、切替処理部２５０ｃにそのことを通知する。

【0020】

切替処理部２５０ｃは、上記通信障害が検出された場合に、運用系システム３０１の統制機能を待機系システム４０１に引き継がせるための制御を行う。また、切替処理部２５０ｃは、通信の復旧が検知された場合に、待機系システム４０１の統制機能を運用系システム３０１に切り戻すための制御を行う。すなわち障害検知部２５０ｂから通信障害の発生を通知されると、切替処理部２５０ｃは、運用系システム３０１（または待機系システム４０１）に切替え要求コマンドを出す。また、障害検知部２５０ｂから通信障害の復旧を通知されると、切替処理部２５０ｃは、待機系システム４０１（または運用系システム３０１）に切り戻し要求コマンドを出す。

【0021】

次に、上記構成における作用を説明する。
図３は、実施形態に係わる料金収受システムで実行される処理手順の一例を示すシーケンス図である。図３において、運用系システム３０１が運用状態にあり（ステップＳ１）、待機系システム４０１は待機状態にあるとする（ステップＳ２）。この状態からリモートサーバ２００は、運用系システム３０１に同期要求コマンドを送信する（ステップＳ３）。これを受けた運用系システム３０１は、待機系システム４０１との間で各データベースのデータを同期させる同期処理を行う（ステップＳ４）。

【0022】

これにより、待機系データベース４０２に記憶されるデータは、運用系データベース３０２に記憶されるデータと常時、同期した状態にある。また、システム切替の直後から待機系システム４０１が稼働を開始できるとともに、運用系システム３０１により収集された車両の道路利用情報を保護することも可能になる。

【0023】

この状態から、豪雨災害などで障害が発生し、リモートサーバ２００によりそのことが検知されたとする（ステップＳ５）。そうするとリモートサーバ２００は、運用系システム３０１に切替要求コマンドを送信する（ステップＳ６）。これを受けた運用系システム３０１は、待機系システム４０１との間で引継ぎ処理を行う（ステップＳ７）。

【0024】

引継ぎ処理には、例えば、被災せずに残存する料金所装置の識別子や通信アドレスの通知、直前にバッファされた（同期が未完了の）道路利用情報の送信等がある。

【0025】

引継ぎが完了すると、運用系システム３０１は待機状態になり（ステップＳ８）、クラウド４００の待機系システム４０１が運用状態となる（ステップＳ９）。稼働を開始した待機系システム４０１は、残存する料金所装置から道路利用情報を収集し（ステップＳ１０）、待機系データベース４０２に記憶する。

【0026】

この状態から、災害が復旧し、障害からの復旧がリモートサーバ２００により検知されたとする（ステップＳ１１）。そうするとリモートサーバ２００は、待機系システム４０１に切戻し要求コマンドを送信する（ステップＳ１２）。これを受けた待機系システム４０１は、運用系システム３０１との間で切り戻し処理を行う（ステップＳ１３）。

【0027】

切り戻し処理には、例えば、障害の継続中に待機系システム４０１で収集され、待機系データベース４０２に蓄積された道路利用情報を運用系データベース３０２に送信する処理等がある。

【0028】

そうして、切戻し処理が完了すると、運用系システム３０１が運用状態に戻り（ステップＳ１４）、待機系システム４０１は再び待機状態になる（ステップＳ１５）。以上の処理手順は、システムが実施運用されている間、繰り返される。

【0029】

図４は、実施形態に係わる料金収受システムにおける運用の一例を示す模式図である。図４において、災害時にメインサイトが被災し、料金所装置も一部が被災したが、被災することを免れた料金所装置があるケースを想定する。
図４に示されるように、オンプレミスのメインサイト３００のデータは、クラウド４００上にリフトアップされ、メインサイト３００、クラウド４００の各データベースに記憶されるデータは常時、同期した状態にある。これにより、メインサイト３００で収集された、道路利用情報を含む各種データを災害から守ることができる。

【0030】

この状態からメインサイト３００、あるいは料金所装置１１～１ｎのいずれかが被災して通信できなくなると、リモートサーバ２００からの遠隔制御によりクラウド４００に統制機能が引き継がれる。これにより、料金収受システムの運用が継続される。

【0031】

既存の技術において、道路事業者の料金収受システムは全てオンプレミスで構築され、機器や構成部品の冗長化により、機器障害に対する可用性を確保している。火災や地震等の災害への対策としては、通常業務を行うサイト（メインサイト）とは別のサイト（ディザスタリカバリサイト）をオンプレミスで用意することで、運用継続を担保していた。しかしながら主に以下の事情から、特に小規模な道路事業者は、物理的なディザスタリカバリサイトを導入することが困難であった。

【0032】

（１） ディザスタリカバリサイトでは、通常運用では利用しない施設と機器を用意する必要があるとともに、日々システムの保守を行う必要がある。このため小規模道路事業者にとっては、費用面、管理面での負担が重く、対応が困難である。

【0033】

（２） 小規模道路事業者の場合、管理している地域が小さく、通常業務を行うサイト（メインサイト）とディザスタリカバリサイトが地理的に近い場所にしか設けられない。このためメインサイト被災時には、ディザスタリカバリサイトもろとも被災し、運用継続が困難であるとともに、データを消失する恐れがある。

【0034】

（３） 災害時にシステムトラブルがあった場合、ディザスタリカバリサイトと保守メーカーの拠点間の距離が遠く、現地到達までに時間がかかるため、復旧に時間がかかる。

【0035】

これに対し、実施形態では、オンプレミスシステムに実装している料金収受機能と同様の機能をクラウド上に備えることで、料金収受システム全体の運用を継続させるようにした。これにより、被害を受けず残存している統制対象のシステムは、クラウドからの制御により継続して運用することが可能になる。また、オンプレミスシステムのデータをクラウド上で保護することができる。また、遠隔地から料金収受システムを操作、保守するとともに、被災状況の確認を行うことができる。さらに、施設が復旧すると、リモートサーバ２００からの制御によりデータをオンプレミス側に戻すことができる。
つまり実施形態によれば、主に運用面での利点として以下の効果がある。
・被害のない統制対象のシステム（料金所装置等）を運用継続させることができること。
・メインサイトが被災した状態でも運用を復旧させることができること。
・料金収受に関する道路利用情報が保護されること。

【0036】

また、主に費用面での利点として以下の効果がある。
・施設建設や用地取得の必要がないため、ディザスタリカバリサイト構築にかかる費用と時間が大きく減らせること。
・ディザスタリカバリサイトの保守要員の確保及び電気代等のランニングコストも、物理サイトを運用する場合に比べて大きく減らせること。

【0037】

これらのことから、実施形態によれば、運用継続性を高めた料金収受システムを低コストで提供することが可能となる。

【0038】

実施形態を説明したが、この実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0039】

１１～１ｎ…料金所装置、２１～２ｎ…通信ノード、１００…ネットワーク、２００…リモートサーバ、２２０…ＲＯＭ、２３０…ＲＡＭ、２４０…記憶部、２４０ａ…プログラム、２５０…プロセッサ、２５０ａ…同期処理部、２５０ｂ…障害検知部、２５０ｃ…切替処理部、２６０…光学メディアドライブ、２７０…通信部、３００…メインサイト、３０１…運用系システム、３０２…運用系データベース、３０３…道路利用情報、４００…クラウド、４０１…待機系システム、４０２…待機系データベース、４０３…道路利用情報。

【図1】

【図2】

【図3】

【図4】