【実施例1】
【0032】
<ガス容器交換システム2>
図4は、実施例1に係るガス容器交換システム2を示している。
図4において、
図1と共通部分には同一符号を付してある。
このガス容器交換システム2にはガス容器交換装置30が備えられる。このガス容器交換装置30には管理サーバー32、通信部26−2、情報提示部16が備えられる。管理サーバー32は既述の処理部12の一例であり、コンピュータで構成される。この管理サーバー32には通信部26−3、プロセッサ34、クロック生成部36、入出力部(I/O)38、既述の記憶部14として記憶部14−1、14−2が備えられる。
【0033】
記憶部14−1はOS(Operating System)、ガス容器交換プログラムなどの記録に用いられる。この記憶部14−1にはROM(Read-Only Memory)、EEPROM(Electrically Erasable Programmable Read-Only Memory )、RAM(Random-Access Memory)などの記憶素子の他、ハードディスク装置を用いればよい。ROMやEEPROMにはOSや検針データSの処理プログラムなどのプログラムが格納される。RAMは検針データSの取得や記憶、トレンドデータTDの作成や記憶、トレンドの割り出し、検針データSやトレンドデータTDの送出または送信などの情報処理エリアとして用いられる。
記憶部14−2は、記憶部14−1に対して外部記憶手段を構成する。この記憶部14−2には既述したROM、EEPROMなど、半導体記憶素子の他、ハードディスク装置を用いればよい。この記憶部14−2には、検針データSやトレンドデータTDなどの変動データを格納するデータベースが構築され、これら変動データの格納およびデータ更新が可能である。この記憶部14−2にはたとえば、ガス容器交換データテーブル46−1(
図9)が格納される。さらに記憶部14−2には、交換日や配送ルートを決定するための情報を格納するデータベースとして、たとえば顧客情報データテーブル50(
図10)、配送情報データテーブル60(
図11)、配送ルートデータテーブル70(
図12)、配送日の状態情報データテーブル80としての気象・交通情報テーブル(
図13)などが構築される。これにより記憶部14−2には、たとえば配送先またはガス容器を識別する識別情報、ガス容器交換候補日、配送区間、配送ルート、所要時間、気象情報、交通情報のいずれかまたは2以上と、検針データ、トレンドデータ、検針タイミングまたは検針間隔を表す情報のいずれかまたは2以上が格納される。
【0034】
通信部26−2は通信部26−1とのデータ通信に用いられ、検針データSやトレンドデータTDなどの検針データに関するデータの送受信に用いられる。これに対し、通信部26−3はプロセッサ34により制御され、管理サーバー32の出力データに関するデータの送受信に用いられる。通信部26−3はたとえば、情報提示部16の一例である情報通信端末44との無線による送受信に用いられる。
プロセッサ34は、記憶部14−1にあるOSを実行し、ガス容器交換プログラムなどを実行する。このガス容器交換プログラムの実行により、既述のデータ取得部8および通信部26−1の情報処理A、B、Cの実行とともに、情報処理D、E、F、G、Hの機能がコンピュータで実現される。
【0035】
クロック生成部36は一定周期のクロック信号を生成する。このクロック信号は、検針タイミングST、検針データSの取得、生成、送出、送信、トレンドデータTDの作成、ガス容器交換タイミングなどの基準信号に用いられる。I/O38はガス容器交換タイミングやガス容器交換日の出力などに用いられる。
情報提示部16には表示部40、プリンタ42、情報通信端末44が含まれる。表示部40にはたとえば、LCD(Liquid Crystal Display)が備えられ、ガス容器交換日などの情報提示が行われる。プリンタ42は、ガス容器交換日などの情報提示の一例である帳票出力に用いられる。情報通信端末44はタブレット端末やスマートフォンなどであり、通信部26−3からガス容器交換日などの提示情報を受信し、この提示情報を画面に表示することができる。この情報通信端末44は、たとえばガス容器18の交換を行う配送者に所持させる端末装置、または配送車両に設置する情報処理端末、走行データなどを取得するデータロガーなどが含まれる。情報通信端末44には、たとえば配送車両の走行ログや現在地情報、気温や湿度、露点などの気象情報を取得する機能を備えてもよい。
【0036】
<ガス容器交換の処理シーケンス>
このガス容器交換システム2では
図5に示すように、ガス容器交換の処理シーケンスによるデータ処理が実行される。
データ取得部8側では、ガス容器交換タイミングCH、または管理サーバー32からの検針タイミングSTの受信(S201)により、ガス容器18の交換タイミングCHまたは検針タイミングSTで、計測部6から検針データSを取得し(S202)、検針データSの管理サーバー32への送信(S203)などが実行される。
管理サーバー32では、データ取得部8からの検針データSの取得(S204)、トレンドデータTDの作成(S205)、検針タイミングSTの決定(S206)、検針タイミングSTのデータ取得部8への送信(S207)、トレンドによるガス容器交換候補日の割り出し(S208)、ガス容器18の交換情報の提示(S209)などが実行される。また割り出されたガス容器18の交換候補日に対し、配送日および配送ルートが決定され(S210)、この配送日および配送ルートは管理サーバー32から情報通信端末44側に送信される(S211)。
情報通信端末44では、決定された配送日および配送ルートを取得する(S212)。
【0037】
<ガス容器交換の処理手順1>
図6は、ガス容器交換から次回のガス容器交換に至る処理手順1を示している。
この処理手順では、既述した片切れ(たとえば、先行使用のガス容器18−1のガス切れ)、両切れ(たとえば、先行使用のガス容器18−1のガス切れから予備側のガス容器18−2のガス切れ)の何れも想定し得る。
この処理手順において、tn:検針データSの取得日時、n:検針データSの取得回数、N:検針データSの取得回数のしきい値、T、T’:検針間隔、K:トレンドから予測するガス容器18−1、18−2の片切れないし両切れの日時、L:ガス容器18−1、18−2のガス残量のしきい値である。
この処理手順ではたとえば、ガス容器18−1を交換し(S301)、この直後、n←1とする(S302)。時点tnに第n検針データSnの取得を実行する(S303)。
【0038】
検針データSの取得回数nがしきい値N以上(n≧N)であるかを判断する(S304)。n≧Nでなければ(S304のNO)、t(n+1)←tn+T(たとえば、T=24時間)、n←(n+1)にインクリメントし(S305)、S303〜S304の処理を継続する。
n≧Nであれば(S304のYES)、検針データS1、S2・・・Snからトレンドを把握し、このトレンドからKを算出する(S306)。
t(n+1)←tn+T’、n←(n+1)に更新する(S307)。なお、更新したtnの日時は必ずKより前になる。検針間隔T’はたとえば、式(3) で示すように、
T’=(K−tn)/2 ・・・(3)
から求め設定してよい。
【0039】
時点tnに第n検針データSnを取得する(S308)。この検針データSnが表すガス残量について、ガス残量のしきい値Lと比較し、ガス残量のしきい値L以下(Sn≦L)であるかを判断する(S309)。
Sn≦Lでなければ(S309のNO)、S306〜S309の処理を継続し、検針データSの取得、トレンドの把握を切り返す。
ガス残量がしきい値L以下(Sn≦L)に到達すれば(S309のYES)、ガス容器18の交換候補日を設定する(S310)。そして、この交換候補日に基づいてガス容器18の交換日を設定するとともに、配送ルートを設定し、その情報を提示して(S311)、この処理を終了する。
【0040】
なお、この処理手順において、検針タイミングSTは、検針間隔Tを指定して定期的に実施してもよいが、これに限定されず、具体的な検針日時を設定して検針日時毎の検針タイミングを設定してもよい。
S301〜S304の処理について、既にトレンドが存在する場合、S301〜S304を省略してもよい。
Kはガス切れタイミングの一例であるから、tn、Kの設定はガス容器交換装置30側で実施してもよく、中継局などのローカル局が自立的な処理で設定してもよい。
検針タイミングSTは、検針間隔Tを指定して定期的に実施してもよいが、これに限定されず、具体的な検針日時を設定して検針日時毎の検針タイミングを設定してもよい。
【0041】
<しきい値L>
しきい値Lはガス切れタイミングなどを決定するための基準であり、検針データSと比較するための比較基準値である。検針データSがガス使用量またはガス残量の何れでもよいから、しきい値Lは検針データSがガス使用量またはガス残量によって異なる値となる。実施例1ではこのしきい値Lに一例としてガス残量のしきい値を用いている。
このしきい値Lは既述した式(1) の関係から設定すればよい。この場合、有限の容積を持つガス容器18のガス使用量が前提となるので、ガス使用量が増加すれば、ガス容器18のガス残量は減少するから、ガス使用量とガス残量は逆の増減関係にある。つまり、ガス使用量またはガス残量でガス容器交換候補日が決定されるので、ガス使用量ではしきい値以上でガス交換候補日が決定されるのに対し、ガス残量ではしきい値以下でガス交換候補日が決定されることになる。
このしきい値Lは固定値または変動値のいずれでもよい。シミュレーションの結果、配送先のガス使用のトレンドを想定した複数の値からしきい値を選択してもよいし、ガス使用量やガス残量のトレンドに応じてしきい値Lの大きさを段階的に変更してもよい。つまり、レベルの異なるたとえば、複数のしきい値L1、L2、L3などを設定すれば、しきい値L1、L2、L3毎にガス容器交換候補日を算出することができる。
特定のガス容器交換日とガス切れタイミングとの間の期間で複数のガス容器交換日を設定してもよいし、最適なガス容器交換日前に任意の複数のガス容器交換日を設定してもよい。
【0042】
<検針データの処理手順2>
図7は、データ処理に基づく処理手順2を示している。この処理手順2はガス容器交換のプログラムまたはその処理方法の一例であり、処理手順1を具体化した処理を示している。
この処理手順2では、ガス容器18の交換を判断する(S401)、ガス容器18の交換まで待機状態が維持される。ガス容器18の交換であれば(S401のYES)、データの初期化を行う(S402)。この例では、時点t1から時点t2までの一定期間T1−2に管理サーバー32がデータ取得部8から検針データSを取得する(S403)。
【0043】
容器交換情報を提示する時期かの判断として、検針データSがガス残量のしきい値L以下(Sn≦L)であるかを判断する(S404)。
Sn>Lであれば(S404のNO)、取得した検針データSを記憶部14に格納し、または検針データSの更新を行う(S405)。管理サーバー32は検針データSを用いてトレンドデータTDを作成する(S406)。
管理サーバー32はトレンドデータTDから検針タイミングSTおよびガス切れタイミングを決定する(S407)。検針タイミングSTおよびガス切れタイミングを生成し、記憶部14−2にある既存のデータを更新し(S408)、S404に戻る。
そして、検針データSnがしきい値L以下(Sn≦L)であるかを判断し(S404)、Sn≦Lであれば(S404のYES)、予測によりガス容器18の交換候補日を設定し(S409)、この交換候補日を利用してガス容器18の交換日や配送ルートを設定して(S410)、この処理を終了する。
【0044】
<検針データの収集およびその処理>
図8は、ガス残量の推移、検針データSの取得、トレンドデータTDの作成、検針間隔Tおよび検針タイミングSTの送出のデータ処理を示している。このデータ処理は、
図7に示す処理手順に準拠している。
図8において、Aはガス残量Gを示すガス残量線LC、BはトレンドデータTD、Cは検針間隔T、Dは検針タイミングSTを表す検針タイミング信号St1〜St7を示している。ガス残量線LCは一例として直線的な漸減傾向を示す直線で示しているが、漸減傾向により曲線となる。
管理サーバー32では
図8のAに示すように、時点t1から時点t8までの間、計測部6から複数の検針データS1、S2、S3・・・S7が取り込まれる。時点t1はガス容器18の交換タイミングCHでの検針タイミングであり、つまり、ガス容器18の第1検針日に相当する。ガス残量Gは、時点t1の最大ガス残量Gmaxからガス使用に応じて漸減し、ガス容器18の交換候補日の一つである時点t7で最小ガス残量Gmin、時点t8がガス切れ時点であり、ガス残量G0=0である。
【0045】
この検針データSの取得により、管理サーバー32には
図8のBに示すように、取得した検針データSからガス使用量またはガス残量のトレンドを把握するためのトレンドデータとして、時間経過に応じ複数のトレンドデータTD1、TD2、TD3・・・TD7が作成されている。トレンドデータTD1は時点t1〜t2の一定期間の検針データSから作成され、トレンドデータTD2は時点t2〜t3の一定期間の検針データSから作成され、トレンドデータTD3は時点t3〜t4の一定期間の検針データSから作成され、同様に、トレンドデータTD4、TD5、TD6、TD7が作成される。
管理サーバー32では
図8のCに示すように、データ収集期間である検針間隔T1−2、T2−3・・・T6−7が生成される。T1−2は第1検針日である時点t1からの一定期間での初期の検針間隔(t1≦T1−2<t2)、T2−3は時点t2からの検針間隔(t2≦T2−3<t3)、T3−4は時点t3からの検針間隔(t3≦T3−4<t4)、T4−5は時点t4からの検針間隔(t4≦T4−5<t5)、T5−6は時点t5からの検針間隔(t5≦T5−6<t6)、T6−7は時点t6からの検針間隔(t6≦T6−7<t7)である。
【0046】
そして、管理サーバー32には
図8のDに示すように、検針データSを取得するための検針タイミング信号St1、St2、St3・・・St7が生成される。つまり、検針タイミング信号St1は第1検針日の検針タイミングに相当する。トレンドデータTDはたとえば複数の検針タイミングで得られる検針データSが必要である。一例として、
図8のDでは、時点t1とt2の検針データS1、S2からトレンドデータTD2が作成され、このトレンドデータTD2を用いてタイミング信号St3が生成される。同様に、時点t2とt3の検針データS2、S3からトレンドデータTD3が作成され、このトレンドデータTDを用いてタイミング信号St4が生成される。このような処理が繰り返されてトレンドデータTD7の作成に至る。タイミング信号St2については、適当な初期値または過去のトレンドを用いて設定すればよいし、トレンドデータTD1は初期値、または過去の検針データから設定されている。この例では、直近の検針データSから得た検針データSから得られるトレンドデータによるトレンドを用いているが、過去のトレンドに直近のトレンドを加味して検針タイミングSTを割り出してもよい。
図8のDの各タイミング信号Stについて、一例としてHは高レベル区間、Lは低レベル区間を示すが、これらは逆の関係であってもよい。
【0047】
<ガス容器交換データテーブル46−1>
図9は、
図8に示すデータ処理により作成された第1のガス容器交換データテーブル46−1の一例を示している。このガス容器交換データテーブル46−1は検針データベースの一例である。このガス容器交換データテーブル46−1には時点t、検針データS、トレンドデータTD、検針タイミングSTおよび交換タイミングCHが格納されている。検針タイミングSTには検針間隔Tおよびタイミング信号St1、St2・・・St7が含まれる。
検針間隔T2−3、T3−4、T4−5、T5−6、T6−7はトレンドデータTDから得たトレンドの把握により検針タイミングST毎に修正、更新される。この結果、ガス残量の推移に応じたトレンドを以て割り出された検針間隔Tと検針タイミング信号Stにより、ガス容器18の交換への移行を示す交換候補日や交換処理を実行する交換日を表す交換タイミングCHが最適化される。
【0048】
次に、交換日の設定および配送ルートの決定処理に用いられるデータやデータテーブルを説明する。
<顧客情報データテーブル50>
顧客情報データテーブル50は、ガス容器18の配送処理を行う契約したユーザーの配送先などを管理するデータベースの一例であって、たとえば
図10に示すように、顧客名情報51、領域情報52、住所情報53、ガス容器交換候補日情報54、ガス容器交換日情報55、ガス切れ予測日情報56などが含まれる。顧客名情報51は、ユーザーを特定する名称が登録される。領域情報52は、たとえばガス容器18の配送エリアを所定の条件によって領域に区分けし、各領域に含まれるユーザーを識別し管理するための情報の一例である。この領域情報52は、たとえばガス容器18を供給する拠点や、その拠点に対する配送者の配属先を示す情報として利用すればよい。住所情報53は、ユーザーの配送先情報の一例である。ガス容器交換候補日情報54は、ガス使用量やガス残量などの検針データSにより決定された交換候補日が登録される。交換候補日は、たとえばガス使用量やガス残量に対して設定したしきい値L以上またはしきい値L以下と成る単一または複数の日が設定される。ガス容器交換日情報55は、後述する交換候補日や気象情報、道路情報などの情報を利用して設定されたガス容器の交換指示日が登録される。ガス切れ予測日情報56は、ガス使用量の検針処理において算出されたトレンドを利用して予測したガス容器が空となる時点t8の日付けが登録される。ガス容器の交換日の決定では、たとえば容器交換候補日とガス切れ予測日との間、または容器交換候補日よりも前に交換日が決定されればよい。
【0049】
<配送情報データテーブル60>
配送情報データテーブル60は、ガス容器交換装置30の記憶部14−2に格納されるデータベースの一例であり、たとえば過去の気象情報に関連付けられた配送区間や配送時間の実績情報が記憶される。配送情報データテーブル60には、たとえば
図11に示すように、登録された気象状態情報61、配送区間情報62、実績所要時間情報63、記録日時64が含まれる。気象状態情報61は、過去の配送時の天候が記憶される。天候は、たとえば「晴れ」や「雨」、「雪」など道路状態に影響がある天候の種類が記憶される。そのほか、気象状態として、気温や湿度などを記憶してもよい。
配送区間情報62は、本開示の配送区間の一例であり、たとえば登録されているユーザー同士、またはガス容器を管理、ガスの充填を行う配送拠点と特定のユーザーなど、二地点間の配送区間を示す情報が記憶される。この配送区間情報62には、たとえばユーザーや拠点を示す登録番号とともに、図示しない配送時に利用した道路名や地図上の座標情報など、配送経路を示す情報が格納されてもよい。
実績所要時間情報63は、本開示の所要時間の一例であり、登録された配送区間に対して配送処理に要した時間情報が格納される。配送情報データテーブル60には、たとえば同一区間に対して全ての配送記録が登録されてもよく、または気象状態毎に実績所要時間を登録してもよい。ここでは配送区間「1−2」に対して、たとえば「晴れ」、「雨」、「雪」の場合の実績所要時間が登録されている。「雨」や「雪」の場合には、たとえば道路の走行状態が変化するほか、交通渋滞が発生することで「晴れ」の場合に対して配送に時間を要する場合がある。
記録日時64は、たとえば配送区間毎の配送記録を登録した日付け情報などが登録される。
【0050】
<配送ルートの設定処理>
図12は、配送ルートの設定例を示す図である。この配送ルートの設定手順や処理内容は一例である。
図12のAは、配送ルートデータテーブル70を示している。また
図12のBは、地図上での配送経路設定状態の一例を示している。この配送ルートデータテーブル70は、配送区間や配送ルート候補の一例であって、たとえば配送情報データテーブル60の配送区間情報62に関連付けて登録された配送経路情報である。配送ルートデータテーブル70にはたとえば二地点間の配送経路の具体的な情報が登録されており区間情報71、配送経路情報72、経過時間情報73などが登録される。区間情報71は、ガス容器交換日に配送する配送先を含む配送区間を示す情報である。配送情報データテーブル60の配送区間情報62が選択されることで、配送ルートデータテーブル70が読み出されるようにしてもよい。
配送経路情報72は、配送区間に対してどの道路や地点を通過したかを登録した配送ルートの実績情報の一例である。この配送経路情報72には、たとえばユーザーや拠点を始点とし、通過する道路名や地図上の座標情報のいずれかまたは両方、さらに各道路の移動距離、配送先の終点の位置情報などの経路が示されている。この配送経路情報72は、たとえば配送者が把握可能な文字情報が登録されてもよく、またはコンピュータが処理するプログラムのみが登録されてもよい。
経過時間情報73は、配送情報データテーブル60の実績所要時間情報63や、この時間情報に加え、ガス容器18の交換に要した時間を加えた時間情報などが登録される。ガス容器18の交換に要する時間は、交換本数などに応じて増減する。
【0051】
配送ルートの設定では、たとえば気象状態に応じて配送情報データテーブル60から配送区間情報が選択されると、配送ルートデータテーブル70が読み出され、登録されている配送経路情報が選択される。配送経路情報の選択では、たとえば各区間に対して複数の配送経路が登録されている場合、所定の配送条件を満たす情報が選択される。この配送条件には、たとえば経過時間が最少になることや、所定の道路を通過すること、通過する道路の数が少ないなどが含まれる。この配送ルートの設定処理では、たとえば
図12のBに示すように、地図データ74に対して二地点間の配送先情報75、経過時間情報76、通過する道路を明示させる経路表示情報77が含まれる。
そして管理サーバー32は配送者毎に割り当てられた配送先に対し、二地点間の配送経路情報を抽出し、配送条件に合うように全ての配送先を結ぶ配送経路を生成する。
【0052】
<気象・交通情報テーブル80>
図13は、配送日に関係付けられた状態情報の一例として気象・交通情報テーブル80を示している。この気象・交通情報テーブル80は、配送日の状態として、ガス容器の交換候補日または交換日当日の気象情報の予測または観測情報やガス容器の配送を担当するエリアの交通情報を登録するデータベースの一例である。この配送日の状態として、たとえば日付情報81、領域情報82、気象情報83、道路識別情報84、交通情報85などが登録される。日付情報81は、たとえば日毎または所定時間毎の気象予測または観測した気象情報が登録される。領域情報82には、配送範囲を区分して特定する情報が記憶される。この領域は、顧客情報データテーブル50の領域情報52と同じ情報であってもよい。気象情報83には、気象予測としてたとえばネットワークを通じて取得した気象情報が登録される。交通情報85には、たとえば道路識別情報84毎に渋滞情報、事故情報などが登録される。
【0053】
<配送指示情報テーブル90>
情報通信端末44には、たとえば
図14のAに示すように、配送者に割り当てられた配送先を示す配送指示情報が登録された配送指示情報テーブル90が備えられる。この配送指示情報には、たとえば配送順情報91、本数情報92、配送経路情報93、配達時刻情報94などが登録されている。配送順情報91には、たとえば上位から配送を行うように、割り当てられたユーザー名が登録されている。
本数情報92は、ユーザー毎に契約したガス容器の本数、または検針情報によりガス切れとなっている、または所定のガス残量に達したガス容器18の本数であって、交換を行うガス容器18の本数が指定されている。
【0054】
配送経路情報93は、配送先までルートを示す道路データが登録されている。この道路データは、たとえば既述の配送ルートデータテーブル70に登録された配送経路情報72と同じ内容が登録されてもよい。道路データは、文字情報などにより利用者が理解可能な表示内容としてもよく、または
図14のBに示す地図アプリが表示される表示手段45に表示されてもよい。
配達時刻情報94は、配送開始から配送先に到達、または交換作業を完了する基準時刻を指定する情報の一例である。この配達時刻は、たとえば後述する遅延管理や、配送者の休憩時間の指示などに利用される。
配送指示情報を受信した情報通信端末44は、たとえば
図14のBに示すように、表示手段45に地図情報を表示させるとともに、この地図上に配送先表示95や配送経路表示96を表示させる。さらに、表示手段45には、たとえば配達時刻情報94や遅延警告表示、休憩指示表示などを表示してもよい。
【0055】
<配送管理処理手順>
図15は、配送ルートの設定処理の一例を示している。この処理では、当日の配送予定データである交換情報および交換タイミング情報を読み出す(S501)。ガス容器の交換情報が生成されているユーザーについて、それぞれ二地点間の気象実績に応じた移動時間を設定する(S502)。この移動時間の設定では、たとえば気象情報と配送区間に基づいて配送情報データテーブル60を読み出す。そして当日の気象予測をもとに二地点間の移動時間を決定するとともに、ガス容器であるボンベ1つの交換時間を決定する(S503)。この処理では、配送先や天候情報により配送ルートデータテーブル70の配送経路情報から所定条件に有った情報を抽出する。そして移送時間、交換時間をもとに配送者毎の配送ルートを設定する(S504)。設定した配送ルートは配送指示情報として情報通信端末44に送信される。
【0056】
次に、配送管理として、管理サーバー32は、配送者毎に配送処理の終了時刻になっているか否かを判断し(S505)、終了時刻でなければ(S505のNO)、渋滞情報があるかまたは実気象が予測と違うかを情報通信端末44に問い合わせ、配送処理に遅延が生じているか否かの判断処理を行う。管理サーバー32は、渋滞情報や配送時の実際の気象情報を読み出し、改めて二地点間の移動時間を再計算し、配送者の配送ルートを再度設定して(S506)、情報通信端末44に通知する。なお、管理サーバー32は、たとえば渋滞情報が無い場合や配送時の実際の気象情報が当初予測した気象と一致またはそれに近い状態、つまり、予測した配送時間が変化しないものである場合には、配送ルートの再設定を行わなくてもよい。新たな配送ルートの通知をした後、一定時間経過させ(S507)、再び配送処理の終了時間か否かの判断を行う(S505)。
【0057】
<配送状態の管理データテーブル100>
図16は、配送状態の管理例として管理データテーブル100を示している。管理サーバー32は、例えば
図16に示すように配送状態の管理データを生成している。この管理データは、たとえば配送処理時間中に継続して情報処理を行えばよい。配送状態の管理処理では、各配送者の配送作業に対し、遅延やその他のトラブルが発生しているか否かを監視している。すなわち、配送開始前に各配送者に送信した配送指示情報に従って配送処理が行えない事態が生じているか否か、または生成した配送指示情報に誤りがあるか否かを管理する。
配送状態の管理データテーブル100には、たとえば配送者情報101、現在地情報102、次の配送先情報103、配送の予定時刻情報104、気象情報105、道路情報106が含まれる。
配送者情報101は、配送指示情報を受信した担当者の情報が登録される。
現在地情報102は、たとえば配送車両や情報通信端末44の位置情報であって、GPS(Global Positioning System )情報や配送が完了した配送先のガスメータ4から通知された配送完了情報などを利用してもよい。
次の配送先情報103は、現在の配送順序を示す情報であり、たとえばガスメータ4から取り込んだ情報であって、ガス容器18の交換時に行われる第1回目の検針情報、配送完了情報などを利用してもよい。
【0058】
配送の予定時刻情報104は、配送指示情報テーブル90の配達時刻情報94と同じ情報が登録されればよく、次の配送先に対して設定されたガス容器18の配送予定時刻が記録される。
気象情報105は、各情報通信端末44や外部のWebサイトなどから取得した各配送先の気象情報である。この気象情報105は、配送指示情報の生成において利用した天候情報と現在の気象とが一致するか否かの判断に利用される。
道路情報106は、配送処理に遅延が生じているか、または遅延が生じるおそれを予測するための情報の一例であり、情報通信端末44から受信し、または外部のWebサイトなどから収集した情報が登録される。
このように配送状態を管理することで、配送遅延の発生を早く把握し、配送不能による配送先のガス切れの発生のリスクを低減させる。
【0059】
<実施例1の効果>
この実施例1によれば、次の効果が得られる。
(1) 従前のガス容器交換では過去のデータに基づいて設定された安全率や安全日といった指標を用いていたのに対し、実施例1では、ガス容器の交換タイミングや検針タイミングから所定期間で取得した検針データによってガス使用量またはガス残量のトレンドを把握し、次の交換タイミングや検針タイミングを決定し、またはガス容器交換候補日から交換日を決定し、検針タイミングの検針間隔をトレンドによって増減させるので、ガス切れの回避とともにガス残量の少ないガス容器の交換タイミングの精度を高めることができる。
(2) ガス容器の交換頻度、配送頻度を低減でき、ガス切れを回避しつつガス容器の交換効率を高めることができる。
【0060】
(3) 検針データからトレンドデータを作成してガス使用量やガス容器のガス残量のトレンドを把握するので、検針データには検針値の他、アラーム情報、ロードサーベイやガスメータのパルス値など、検針値と同様にガス使用量やガス残量を示すデータ、アラーム情報、ガス使用量やガス残量を表す容器内圧力を表すデータのいずれかまたはこれらの2以上を組みあわせたデータを利用でき、検針データのトレンドを把握するための自由度を高めることができる。
(4) 検針タイミング、検針間隔は検針データから把握したトレンド、つまりトレンドデータによって動的に変動させるので、ガス使用量、ガス残量のリアルタイムでの検針データを取得でき、たとえば、一方のガス容器18−1のガス切れ(片切れ)の直前期間、または双方のガス容器18−1、18−2のガス切れ(全切れ)の直前期間では検針データSの検針間隔Tを狭めて検針密度を高くでき、この結果、ガス残量の計測精度が高められ、ガス切れ直前のタイミングまでガスを使用した後、タイムリーにガス容器交換が可能であるとともに、ガス容器交換時のガス残量を少なくすることができる。
(5) 実施例1のガス容器交換システム2では、ガスメータ4側に通信機能を備えて、ガス容器交換装置30は無線による検針タイミングSTの設定とともに、検針データSの取得を行い、効率的なガス容器交換を実現でき、ガス切れなどの不測の事態を回避できる。
【0061】
(6) 交換対象となるガス容器のガス残量を抑制できるので、ガス容器の交換効率を高め、ガス容器の交換コストを低減できる。
(7) ガス容器の交換情報は表示部40の画面表示やプリンタ42による帳票印刷だけでなく、情報通信端末44でも確認することができ、配送途上におけるトレンド変化など、緊急時の対応もタイムリーに行うことができる。
(8) ガス使用の季節的な増減や温度変化による変動要素を吸収し、検針タイミング、検針間隔、ガス切れタイミング、ガス容器交換日の推定精度を高めることができる。
(9) ユーザーのガス切れを防止できるとともに配送頻度を少なくでき、予備系のガス容器の使用状況も正確に把握できるので、予備系のガス容器18−2の設置数を削減でき、予備系のガス容器18−2側のガス使用もガス切れ直前まで使用できる上、ガス容器交換の信頼性を高めることができる。
【0062】
(10) 配送実績として登録された気象情報や区間情報、配送経路情報を利用して配送経路を組み合せることで、配送者の経験値に依らずに、ガス切れを起こさせずに、効率的にガス容器の交換が行える配送日および配送経路の生成処理が行える。
(11) 配送処理の実行中に配送状態を監視し、道路情報や気象情報を取得して配送経路の再設定を行うことで、配送遅延の発生やその発生の可能性に対して一早く対処でき、ガス切れによるユーザーの信頼喪失の可能性を回避することができる。
(12) 過去の配送実績および配送処理に影響を与える気象情報を利用して精緻な配送指示情報を生成することで、ガス容器の交換タイミングについて安全率や安全日の設定を無くし、または最小限に抑えることができるので、配送回数の低減や配送者の作業負荷の軽減が図れる。