本発明に係る物流管理システム、物流管理端末および物流管理方法の実施の形態について、添付図面を参照して説明する。
(第1の実施形態)
図1は、本発明の一実施形態に係る物流管理システム11(物流管理端末12を含む)の一例を示す全体構成図である。
物流管理システム(以下、管理システムという)11には、通信サービスの提供エリアを所望の大きさに分割したセル内にそれぞれ固定無線局である基地局13が設置されており、公衆移動電話機(携帯電話機)の事業者(オペレータ)ごとに、セル内にそれぞれ基地局13が設置されている。たとえばオペレータAの場合、オペレータAが管理する基地局13−1として複数の基地局13−1−1乃至13−1−nが設置されている。また、オペレータBの場合、オペレータBが管理する基地局13−2として複数の基地局13−2−1乃至13−2−nが設置されている。
なお、図1には公衆移動電話機(携帯電話機)のオペレータがn個である場合について記載したが、このオペレータ数nは1つ以上であればよい。また、本実施形態において、物流管理端末(以下、管理端末という)12は、複数のオペレータのうちいずれかのオペレータが管理する基地局13に接続される。
これらの基地局13−1乃至13−nには、移動無線局である管理端末12が例えばW-CDMA(Wideband-Code Division Multiple Access)と呼ばれる符号分割多元接続方式や、GSM(登録商標;Global System for Mobile Communications)方式などの種々の無線接続方式によって無線接続される。この管理端末12は、国内間または国際間を移動する輸送車両(輸送船)あるいは貨物自体に取り付けられる。したがって、管理端末12は、一般的には、輸送する貨物(あるいは輸送車両など)の量に応じて複数存在する。
この管理端末12は、GPS衛星14−1乃至14−4からのGPS波(GPS情報)を受信し、GPS情報にもとづいて自端末の位置情報を取得する。
また、基地局13−1乃至13−nは、移動体通信網群15に接続される。移動体通信網群15は、国内移動体通信網16と国外ローミング網群17を含む。携帯電話機の事業者(オペレータ)ごとに1つの移動体通信網(ローミング網)が設置されて管理されている。たとえばオペレータAには、ローミング網15−1が設置されて管理されている。また、たとえばオペレータBには、ローミング網15−2が設置されて管理されている。
移動体通信網群15には、インターネットサービスプロバイダのアクセスサーバのゲートウェイ(図示せず)を介して有線または無線のネットワーク18(例えば、インターネット(IP)網、LAN(Local Area Network)、WAN(Wide Area Network)、その他の各種のネットワークを含む)が接続されている。すなわち、移動体通信網群15とネットワーク18とは、インターネットワークを構成する。
ネットワーク18には、物流管理装置(以下、管理サーバという)19が接続される。管理サーバ19は、貨物に付帯された管理端末12から、移動体通信網群15とネットワーク18とを介して種々の情報を取得する。種々の情報には、貨物の状態を示す情報や貨物の位置情報などが含まれる。また、ネットワーク18には、さらに、管理端末12の追跡・管理を所望するユーザが所有または管理する操作端末20が接続される。
なお、基地局13−1乃至13−nは、以下において、それぞれを個々に区別する必要がない場合、基地局13と総称する。また、管理端末12は、以下において、それぞれを個々に区別する必要がない場合、管理端末12と称する。
また、ネットワーク18には、注目領域確認画像情報および注目領域編集画面画像情報を操作端末20に提供するコンテンツサーバ21が接続される。また、ネットワーク18には、地図情報を提供する地図コンテンツサーバ22も接続される。
図2は、第1実施形態に係る管理端末12の内部構成例を概略的に示すブロック図である。
管理端末12は、GPS用アンテナ31、GPS受信部32、移動体通信用アンテナ33、移動体通信部34、給電部35、給電制御部36、切替部37、状態検出部38、時刻情報出力部39、記憶部40および主制御部41を有する。
GPS受信部32は、主制御部41の制御に従い、GPS衛星14−1乃至14−4からのGPS波(GPS情報)を、GPS用アンテナ31を介して受信する。このGPS情報には、例えばそれぞれのGPS衛星14−1乃至14−4からの発信時刻情報が含まれている。GPS受信部32は、このGPS情報を用いて、管理端末12の現在地を示す位置情報(緯度経度の情報)を計算し(なお、例えば3つ乃至4つのGPS情報から計算することが望ましい)、管理端末12の現在地を示す位置情報であるGPS測位に基づく位置情報を求める。そして、GPS受信部32は、この位置情報を主制御部41に与える。
なお、このGPS情報に基づいて求められる位置情報として緯度経度を取得することが一般的であるが、更に緯度経度に対応した住所情報を取得するようにしてもよい。従って、「GPS測位に基づく位置情報」とは、GPS情報から計算された位置情報(例えば緯度経度情報)や、その情報に対応する住所情報などの情報も含むものとする。
移動体通信部34は、主制御部41に制御されて、移動体通信用アンテナ33を介して、移動体通信網群15を用いた国際ローミングを利用して通信することができるよう構成される。このため、管理端末12は、貨物に付帯されて国外に持ち出された際にも、国際ローミングサービスを利用して管理サーバ19とデータ送受信可能である。
給電部35は、たとえば乾電池などの電池により構成される。管理端末12は、貨物に取り付けられるなどして貨物に付帯して輸送される。給電部35を化学電池などの電池により構成することにより、本実施形態に係る管理端末12は、たとえ貨物に付帯して輸送されている最中であって商用電源を利用困難な状況下に載置されていても、貨物の状態や貨物の位置などの情報を、貨物の輸送中にリアルタイムに管理サーバ19に送信することができる。
しかし、乾電池などの電池は、電力量に制限がある。このため、特に長期間にわたって輸送される貨物に対して管理端末12が付帯する場合には、できるだけ電池の消費を抑制することが好ましい。管理端末12の各コンポーネントのうち、特に消費電力が高いと考えられるのは、通信に関する構成であるGPS受信部32および移動体通信部34である。
そこで、本実施形態に係る管理端末12は、給電制御部36により各コンポーネントに対する供給電力を制御する。また、GPS受信部32および移動体通信部34に対しては、切替部37のGPS用スイッチ42および移動体通信用スイッチ43をそれぞれ制御することにより、他のコンポーネントとは独立して給電制御する。なお、切替部37のGPS用スイッチ42および移動体通信用スイッチ43は、主制御部41によって制御されてもよいし、手動により切り換えられるよう構成されてもよい。
状態検出部38は、主制御部41により制御されて、貨物が出発地から目的地に輸送されるまでの輸送期間内に、所定の周期で管理端末12の状態を検出する。状態検出部38は、たとえば温度センサ44、加速度センサ45、湿度センサ46、照度センサ47などを有する。これらのセンサ44〜47は、それぞれ従来各種のものが知られており、これらのうち任意のものを使用することが可能である。
たとえば、加速度センサ45は、貨物の加速度を検出し、検出した加速度に応じた信号を出力して主制御部41に与える。この加速度センサ45としては、たとえば非常に小型ながら高精度であるために携帯型の情報処理装置に広く用いられている3軸加速度センサを用いるとよい。加速度センサ45として3軸加速度センサを用いる場合、加速度センサ45は、X軸、Y軸、Z軸の3軸方向の加速度αx、αy、αzをそれぞれアナログ電圧値として出力する。
なお、状態検出部38を構成する各種センサ等の検出器は、貨物の輸送中に状態検出を行うが、そのタイミングは所定の周期ごとに行ってもよいし、あらかじめ定められたスケジュールに沿って(たとえば時間帯によって周期を変更するなどして)もよい。また、検出タイミングは全ての検出器で必ずしも同一でなくてもよく、検出器ごとに異なっていてもよい。
以下の説明では、状態検出部38によるデータ収集(データロギング)が所定の周期(第1の周期)で実行される場合の例について説明する。データロギングに限らず、他の処理も含めて処理のタイミングを同期して行うことにより、ローパワーモードへの移行タイミングもまた同期させやすく、消費電力低下の観点からは有利である。
なお、これらのセンサとは異なる対象を検出するための検出器を用いてもかまわない。
時刻情報出力部39は、たとえばRTC(Real Time Clock)により構成され、主制御部41に対して現在時刻情報を出力する。主制御部41は、時刻情報出力部(RTC)39の出力を用いることにより各種ソフトウエアタイマを動作させることができる。
記憶部40は、磁気的もしくは光学的記録媒体または半導体メモリなどの、CPUにより読み取り可能な記録媒体を含んだ構成を有し、記憶部40に格納されるプログラムおよびデータの一部は電子ネットワークを介してまたは光ディスクやUSBメモリなどの可搬型記憶媒体を介して更新されるように構成してもよい。
記憶部40は、ログデータ48を記憶するほか、各種閾値(温度閾値や加速度閾値など)を記憶する。ログデータ48は、状態ログデータ50、状態イベント情報51および位置ログデータ52を有する。
ログデータ48の状態ログデータ50は、状態検出部38により所定の周期で検出された貨物の状態と検出時刻とを関連づけたデータであり、いわゆるデータロギングにより得られるデータである。
状態イベント情報51は、状態検出部38によりデータロギングで検出された貨物の状態のうち、あらかじめ定められた閾値を用いた判定によって異常な状態と判定されたデータとこのデータの検出時刻とを関連づけたデータである。この閾値は、貨物に応じて異ならせてもよい。
たとえば、温度センサ44の検出値(温度)についての閾値は、貨物によっては上限値および下限値の両者を定めておき、検出温度が上限値から下限値までの範囲外であると異常な温度であると判定するようにしてもよい。また、たとえば加速度センサ45の検出値(加速度の大きさに応じた信号)は、貨物に加わる衝撃に応じた値であると考えられる。このため、加速度センサ45についての閾値は、慎重に扱うべき貨物ほど小さな値としてもよい。
位置ログデータ52は、GPS受信部32を用いたデータロギングで所定の周期で検出された貨物の位置情報と位置の検出時刻とを関連づけたデータである。
また、管理端末12は、近距離無線通信部53を有してもよい。近距離無線通信部53は、IrDA、RFIDや、IEEE802.15.x、ISO/IEC18092、14443、21481などの近距離無線通信規格に準拠した通信方式によって、他の近距離無線通信部と無線通信を行う。管理端末12が近距離無線通信部53を有する場合、管理端末12は、たとえばこの近距離無線通信部53と無線通信可能な他の近距離無線通信部を有する電子機器などの外部の情報通信手段によってリモートコントロールされてもよい。ここで、外部の情報通信手段としては、いわゆるリモートコントローラのほか、RFIDのICタグ(RFIDタグ)を有するいわゆるICカードなどであってもよい。
具体的には、給電制御部36は、無線通信により近距離無線通信部53を介して外部の情報通信手段から受けた情報(たとえばリモートコントローラから受けた指示内容や、ICカードから取得した識別情報)に応じて、GPS受信部32および移動体通信部34のそれぞれの給電経路に設けられたGPS用スイッチ42および移動体通信用スイッチ43の短絡および開放を切り替える。
なお、外部の情報通信手段としてICカードを用いる場合、近距離無線通信部53をRFIDリーダにより構成するとともに、あらかじめ所定のICリーダの識別情報と各識別情報に対応する情報(たとえば給電制御を許可するか否かや給電制御方法その他の給電制御に関する情報など)とを関連付けて、記憶部40に記憶させておく。
管理端末12が近距離無線通信部53を有する場合、たとえば、本実施形態に係る管理端末12を取り付けた貨物を航空機に持ち込む際に、管理端末12を直接操作せずとも、近距離無線通信部53と無線通信可能な外部の情報通信手段(たとえばICカードなど)を用い、近距離無線通信部53を介した無線通信によりこの外部の情報通信手段の操作に応じて(たとえばICカードを近距離無線通信部53に近づけることで)切替部37を制御することにより、機内におけるGPS機能および移動体通信機能を容易に停止させることができる。
また、状態検出部38の検出器が近距離無線信号の送信が可能であり、かつ複数の管理端末12が近距離に集まっていれば、複数の管理端末12のそれぞれが有する複数の検出器の無線信号出力を1つの管理端末12の近距離無線通信部53でまとめて受信することができ、便利である。
また、管理端末12が有する検出器に限らず、管理端末12の近くに設けられた他の検出器(周囲の環境状態(温度、加速度、湿度、照度など)の検出を行う検出器)が管理端末12と近距離無線通信可能に構成されていれば、管理端末12の主制御部41は、この他の検出器の検出した情報を無線通信により近距離無線通信部53を介して取得してもよい。たとえば、貨物が大きく、管理端末12が付帯する位置と、同一の貨物の別の位置(たとえば対角の位置など)とで状態が異なるおそれがある場合を考える。この場合、この別の位置に他の検出器を設け、他の検出器の検出した情報を無線通信により取得することにより、管理端末12の付帯位置において状態検出部38が検出した貨物の状態の情報に加え、別の位置に設けられた他の検出器の検出した貨物の状態の情報を容易に得ることができる。
また、貨物の搬送車両等や搬送先倉庫などの扉のカギに近距離無線信号の受信部が設けられている場合、管理端末12の近距離無線通信部53をこの受信部に近づけることでドアロックが解除されるようにすれば、カギを取り出す手間が省けるほかセキュリティも向上する。さらに、後述する管理端末12の位置イベント発生条件をあらかじめ目的地の倉庫中心スポットに入った場合としておき、目的地の倉庫の開錠条件にこの位置イベント発生をふくめておけば、よりセキュリティを高めることができる。
なお、位置イベントとは、GPS測位から得られる位置情報と、あらかじめ設定された注目領域設定情報にもとづいて、貨物の現在の位置が貨物の出発地点スポット(またはエリア)から出た場合や目的地点スポット(エリア)に入った場合、またはあらかじめ設定された経路から外れた場合などの、管理端末の位置に関してあらかじめ設定された条件が満たされた事象を指すものとする。
主制御部41は、CPU、RAMおよびROMをはじめとする記憶媒体などにより構成され、この記憶媒体に記憶されたプログラムに従って、管理端末12の処理動作を制御する。
主制御部41のCPUは、ROMをはじめとする記憶媒体に記憶された物流管理プログラムおよびこのプログラムの実行のために必要なデータをRAMへロードし、このプログラムに従って、国際間の物流取引において、輸送過程で貨物に生じる状態異常を容易かつ的確に管理する処理を実行する。
主制御部41のRAMは、CPUが実行するプログラムおよびデータを一時的に格納するワークエリアを提供する。
主制御部41のROMをはじめとする記憶媒体は、管理端末12の起動プログラム、物流管理プログラムや、これらのプログラムを実行するために必要な各種データを記憶する。また、主制御部41の機能実現部が実行する各種処理の設定時間(たとえば周期動作の周期や、エラー対応時の待機時間など)の設定パラメータを記憶する。
なお、ROMをはじめとする記憶媒体は、磁気的もしくは光学的記録媒体または半導体メモリなどの、CPUにより読み取り可能な記録媒体を含んだ構成を有し、これら記憶媒体内のプログラムおよびデータの一部または全部は電子ネットワークを介してダウンロードされるように構成してもよい。
図3は、第1実施形態に係る管理端末12の主制御部41のCPUによる機能実現部の構成例を示す概略的なブロック図である。なお、この機能実現部は、CPUを用いることなく回路などのハードウエアロジックによって構成してもよい。
図3に示すように、主制御部41のCPUは、物流管理プログラムによって、少なくともスケジュール管理部61、状態取得部62、状態イベント判定部63、通信制御部64、省電力制御部65、コマンド処理部66、および位置情報取得部67として機能する。この各部61〜67は、RAMの所要のワークエリアを、データの一時的な格納場所として利用する。
スケジュール管理部61は、時刻情報出力部39の出力をもちいてタイマを張り、主制御部41の記憶媒体に記憶された設定パラメータにもとづいて主制御部41の機能実現部が実行する各種処理の時間管理を行う。
状態取得部62は、状態検出部38が出力した検出信号を必要に応じて解析し、各データロギング時点での貨物の状態を取得するとともに、取得した貨物の状態とこの状態が検出された時刻とを関連付けて状態ログデータ50に記憶させる。
また、上述の通り、管理端末12が近距離無線通信部53を有し、管理端末12が付帯する位置とは異なる別の位置に無線通信可能な他の検出器が設けられる場合には、状態取得部62は、他の検出器の検出した情報を無線通信により取得する。
状態イベント判定部63は、状態検出部38によるデータ収集(データロギング)で検出された貨物の状態のうち、あらかじめ定められた閾値を用いて異常な状態か否かを判定する。温度センサ44に対して上限の閾値が設定されていた場合は、状態イベント判定部63は、温度センサ44が検出値を出力するごとに、この検出値(温度)が閾値を超えているか否かを判定する。この場合、閾値を超えると異常な状態である(状態イベントが発生した)と判定し、状態イベント情報を生成する。状態イベント情報は、この状態を検出した時刻と、イベント情報(検知したイベントの内容)と、そのときの位置情報などを含む。
通信制御部64は、所定の周期で状態検出部38により検出された貨物の状態と、貨物の状態が検出された時刻と、を関連付けた情報を、輸送期間内に所定の周期(第2の周期)で移動体通信部34を介して管理サーバ(物流管理装置)19に与える。また、この情報には検出時の貨物の位置情報がさらに関連づけられてもよい。また、上述の通り、管理端末12が近距離無線通信部53を有し、状態取得部62が他の検出器の検出した情報を無線通信により取得した場合は、通信制御部64はさらに、他の検出器が検出した他の位置の状態と、他の位置の状態が検出された時刻とを関連付けた情報を、上記の貨物の状態とあわせて第2の周期で、または異なるタイミングで、移動体通信部34を介して管理サーバ19に与えてもよい。
また、通信制御部64は、状態イベントが発生した場合に、その旨の情報と、イベント発生時刻とを関連付けた情報を、移動体通信部34を介して管理サーバ19に与える。
省電力制御部65は、給電部35を構成する電池の消耗を防ぐよう、各種の一連の処理が終了または一段落すると管理端末12のシステム状態をローパワーモード(低消費電力モード)に移行させる。
コマンド処理部66は、管理サーバ19からコマンドを受信すると、コマンドの内容を解析してコマンドに応じた処理を実行する。たとえば、コマンドの内容が設定パラメータの変更指示であると、コマンド処理部66は、主制御部41の記憶媒体に記憶された設定パラメータを変更指示に応じて変更する。
ここで、特に国際ローミングを利用する場合には、管理端末12に対して管理サーバ19がトリガをかけてコマンドを送ることができない点に注意が必要である。たとえば管理サーバ19はインターネット網に接続されている場合、管理サーバ19から管理端末12に対してコマンドを送信するためには管理端末12のIPアドレスを特定する必要がある。しかし、外国のオペレータが国際ローミングサービス利用者に対して静的なIPアドレスを割り当てることはほとんどなく、しかも貨物輸送中は管理端末12が移動しているため、接続基地局も時間とともに変化してしまう。
そこで、本実施形態に係る物流管理システム11は、国際ローミングを利用する場合でも管理サーバ19から管理端末12にコマンドを送信することができるように、管理サーバ19は、管理端末12からデータが送信されてくるタイミングまでコマンド送信を待機し、管理端末12からデータを受信すると、これに対する返答ACK/NAKを送信する際にコマンドもあわせて送信する。
位置情報取得部67は、所定の周期でGPS測位を用いて管理端末12の位置情報を取得するとともに、取得した位置情報とその位置に管理端末12が存在すると検出された時刻とを関連付けて位置ログデータ52に記憶させる。なお、この位置情報の取得周期は、状態検出部38の検出タイミングと異なっていてもよい。
図4は、第1実施形態に係る管理サーバ19の内部構成例を概略的に示すブロック図である。
管理サーバ19は、ネットワーク接続部70、時刻情報出力部71、記憶部72および制御部73を有する。
ネットワーク接続部70は、ネットワーク18の形態に応じた情報通信用プロトコル(たとえばTCP/IPプロトコル)を実装する。ネットワーク接続部70は、このプロトコルに従って管理サーバ19と管理端末12および操作端末20などの他の電気機器とを接続する。
時刻情報出力部71は、たとえばRTC(Real Time Clock)により構成され、制御部73に対して現在時刻情報を出力する。制御部73は、時刻情報出力部71(RTC)の出力を用いることにより各種ソフトウエアタイマを動作させることができる。また、制御部73は、管理端末12とデータの送受信を行う際に、時刻情報出力部71の出力にもとづいて現在の管理サーバ19の時刻情報を管理端末12に送信する。管理端末12は、管理サーバ19から送信された時刻情報を用いて、管理端末12の時刻情報出力部(RTC)39を管理サーバ19に同期させる。
記憶部72は、端末別ログデータのデータベース74、端末別イベントデータのデータベース75およびイベント情報送信先テーブル76および注目領域設定情報DB77を記憶する。イベント情報送信先テーブル76は、イベント情報を受信した際に、その旨の情報および少なくともイベント情報を内容として含む電子文書(電子メールなど)を送信すべきユーザのメールアドレスが記憶される。
制御部73は、CPU、RAMおよびROMをはじめとする記憶媒体などにより構成され、この記憶媒体に記憶されたプログラムに従って、管理サーバ19の処理動作を制御する。
制御部73のCPUは、ROMをはじめとする記憶媒体に記憶された物流管理プログラムおよびこのプログラムの実行のために必要なデータをRAMへロードし、このプログラムに従って、国際間の物流取引において、輸送過程で貨物に生じる状態異常を容易かつ的確に管理する処理を実行する。制御部73のRAMは、CPUが実行するプログラムおよびデータを一時的に格納するワークエリアを提供する。制御部73のROMをはじめとする記憶媒体は、管理サーバ19の起動プログラム、物流管理プログラムや、これらのプログラムを実行するために必要な各種データを記憶する。
なお、ROMをはじめとする記憶媒体は、磁気的もしくは光学的記録媒体または半導体メモリなどの、CPUにより読み取り可能な記録媒体を含んだ構成を有し、これら記憶媒体内のプログラムおよびデータの一部または全部は電子ネットワークを介してダウンロードされるように構成してもよい。
図4に示すように、制御部73のCPUは、物流管理プログラムによって、少なくともログデータ受信部78、検索部79、位置イベント判定部80、注目領域設定部81、イベント解析部82およびイベント発生情報送信部83として機能する。この各部78〜83は、RAMの所要のワークエリアを、データの一時的な格納場所として利用する。
ログデータ受信部78は、管理端末12から所定の周期で定期的にログデータ48を受信する。なお、この所定の周期は、状態検出部38の動作周期などのロギング周期よりも長くしておくとよいが、ログデータ48のリアルタイム性を確保するためには長くしすぎないほうが好ましい。ログデータ受信部78は、この定期通信処理で受信したログデータ48を記憶部72の端末別ログデータDB74に記憶させる。
検索部79は、ネットワーク接続部70を介して操作端末20から記憶部72の端末別ログデータDB74の閲覧要求があると、閲覧要求の内容に応じて記憶部72を検索し、閲覧要求に応じた情報を操作端末20に与える。閲覧要求においては、管理端末12の識別情報、閲覧したいデータの期間のほか、ミッション名であってもよい。
ここで、ミッションとは、貨物輸送における一連の輸送動作をいうものとする。すなわち、1つのミッションとは、たとえば貨物が出発地点を出発してから目的地に到着するまでを1つのミッションという。
ミッションを定義することにより、たとえば貨物Aに付帯されて東京から新潟に輸送された管理端末12が数日後、新潟から別の貨物Bに付帯されて東京に輸送される場合のように、同一の管理端末12を用いる場合でも、一連の輸送動作ごとにログデータを容易に抽出することができる。このため、管理端末12の識別情報を用いたグルーピングとは全く異なるグルーピングを行うことが可能となり、ユーザの利便性が高くなる。
また、管理端末12は、ミッションが終了し次のミッションが開始するまでの期間にその機能が必要とされることはあまりない。このため、ミッション単位で電力を制御し、ミッションとミッションの間の期間は省電力モードまたはシャットダウン状態となるようにすることでより一層の消費電力削減を図ることができる。
位置イベント判定部80は、ログデータ受信部78により受信されたログデータに含まれる位置ログデータと、あらかじめ設定された注目領域設定情報にもとづいて、貨物の現在の位置が貨物の出発地点スポット(またはエリア)から出た場合や目的地点スポット(エリア)に入った場合、またはあらかじめ設定された経路から外れた場合などに位置イベントが発生した(あらかじめ定めた状態である)と判定し、位置イベント情報を生成してイベント解析部82に与える。位置イベント情報は、この状態を検出した時刻と、イベント情報(検知したイベントの内容)と、そのときの位置情報などを含む。
注目領域設定部81は、操作端末20を介してユーザにより管理端末12ごとに設定される。注目領域としては、スポットやエリアのほか、輸送経路を線とした場合、この線に対して所定の幅を持たせた領域などが設定される(なお、注目領域の設定方法は、図10−12を用いて後述する)。
イベント解析部82は、管理端末12から状態イベント情報を受信すると、あるいは位置イベント判定部80から位置イベント情報を受けると、各イベント情報を解析して端末別イベントデータDB75に格納する。
イベント発生情報送信部83は、イベント情報の解析結果にもとづいてユーザに対してイベント情報を受信した旨の情報を与えるべきか否かを判定し、与えるべきと判定した場合は、イベント情報を受信した旨の情報および少なくともイベント情報を内容として含む電子文書(電子メールなど)を生成し、イベント情報送信先テーブル76に記憶されたユーザのメールアドレス宛に送信する。
図5は、操作端末20の内部構成例を概略的に示すブロック図である。
図5に示すように、操作端末20は、ネットワーク接続部86、入力部87、表示部88および制御部89を有する。なお、ネットワーク接続部86の構成は管理サーバ19の構成と同一であるため説明を省略する。
操作端末20は、ネットワーク18を介して管理サーバ19とデータ送受信可能であればよく、一般的なパーソナルコンピュータや携帯電話機、PDA(Personal Digital Assistant)などの情報処理装置により構成することができる。
入力部87は、たとえばキーボード、タッチパネル、テンキーなどの一般的な入力装置により構成され、ユーザの操作に対応した操作入力信号を制御部89に出力する。
表示部88は、たとえば液晶ディスプレイやOLED(Organic Light Emitting Diode)ディスプレイなどの一般的な表示出力装置により構成され、制御部89の制御に従って管理サーバ19から受けた管理端末12のログデータを示す画像を表示するほか、コンテンツサーバ21から受けた注目領域確認画像情報および注目領域編集画面画像などの各種情報を表示する。
制御部89はCPU、RAMおよびROMをはじめとする記憶媒体などにより構成されて、管理サーバ19に対してログデータの閲覧要求を行う。
図6は、管理端末12の動作遷移を概略的に説明するための図である。
管理端末12は、状態検出部38により周期的に貨物の状態を検出する(データロギングする)。このとき、イベントが発生すると、定期通信の周期到来前であっても管理端末12から管理サーバ19に対して発生したイベントの情報が送信される。また、管理端末12と管理サーバ19とは、所定の周期で定期通信を行ってログデータを共有する。このため、管理サーバ19はリアルタイムに管理端末12の現在位置および貨物の状況を容易に把握することができる。また、給電部35を構成する電池の消耗を抑制するよう、管理端末12は、各種処理の合間にはできるだけシステム状態をローパワーモードに移行しておく。
本実施形態に係る管理システム11は、移動体通信部34が国際ローミングで通信を行うことができるとともに、貨物の輸送中であっても貨物の状態や貨物の位置について、定期通信やイベント通信を行うことができる。このため、国際間の物流取引において、輸送過程における貨物の状態を容易かつ的確に管理することができる。また、輸送過程において貨物の状態があらかじめ定めた状態である場合には、管理端末12は定期通信を待たずにイベント情報を管理サーバ19に与えることができる。したがって、貨物の状態に重大な問題がおき始めている場合にも早期にトラブルに気付きやすく、大変便利である。
次に、本実施形態に係る物流管理システム11(物流管理端末12を含む)の動作の一例について説明する。
図7(a)は、管理端末12の主制御部41により実行される、データロギングにおける衝撃情報の取得処理の手順の一例を示すフローチャートである。また、図7(b)は、衝撃情報取得処理により取得された最大加速度の更新処理の手順の一例を示すフローチャートである。図7において、Sに数字を付した符号は、フローチャートの各ステップを示す。
この手順は、管理端末12に対して電源が投入された時点でスタートとなる。
まず、ステップS1において、スケジュール管理部61は、時刻情報出力部(RTC)39の出力を用いて更新間隔タイマを起動する。なお、この更新間隔タイマにセットされる時間の長さは、データロギングのデータ更新間隔よりも短いかまたはほぼ同一である。
次に、ステップS2において、状態取得部62は、加速度センサ45から所定期間ごと(たとえば2msecごと)に加速度データを取得する。この加速度データは、大きさAの加速度ベクトルA(Ax、Ay、Az)の情報を内容とするデータである。次に、ステップS3において、状態取得部62は加速度ベクトルAの大きさを計算する。そして、ステップS1で開始された今回のデータ更新間隔において、加速度ベクトルの大きさAが最大の加速度データをRAMの所要のワークエリアなどの記憶媒体に保持する。
次に、ステップS4において、スケジュール管理部61は、更新間隔タイマがタイムアウト信号を出力したか否かを判定する。タイムアウト信号を出している場合はステップS5に進む。一方、まだタイムアウトしていないとステップS2に戻る。
そして、次のデータ更新間隔ごとの測定開始トリガを受信すると(ステップS5)、再度ステップS1からS4の手順を繰り返す。
また、図7(a)のステップS4で更新間隔タイマがタイムアウト信号を出力すると、図7(b)に示す最大加速度更新処理がスタートする。まず、ステップS6において、状態取得部62は、RAMの所要のワークエリアなどの記憶媒体に保持された加速度データ(以下、Amaxという)をログデータとして、状態ログデータ50に時刻と関連づけて記憶させる。なお、この時点でRAMの所要のワークエリアなどの記憶媒体に保持されている加速度データAmaxは、直前のデータ更新間隔において所定期間ごとに取得された加速度データのうち最大の大きさをもつ加速度データである(ステップS3参照)。
次に、ステップS7において、状態イベント判定部63は、今回取得したAmaxがあらかじめ設定された閾値Athより大きいか否かを判定する。大きい場合は、貨物に対して予定していたよりも大きな衝撃が加わったおそれがあるため、イベント通信処理を実行し、時刻とイベント情報とAmaxベクトルとを関連づけた状態イベント情報を管理サーバ19に与え、一連の処理は終了となる(ステップS8)。一方、閾値より小さい場合にはイベント通信処理は行わず、一連の処理は終了となる。なお、イベント通信処理の詳細については後述する。
以上の手順により、データロギングにおいて衝撃情報を取得することができるとともに、状態イベントが発生した場合には管理サーバ19に状態イベント情報を与えることができる。また、処理を実行していない際にはシステムを確実にローパワーモードに移行させることができる。
図8は、管理端末12の主制御部41により実行される、データロギングにおける温度情報の取得処理の手順の一例を示すフローチャートである。図8において、Sに数字を付した符号は、フローチャートの各ステップを示す。
この手順は、管理端末12に対して電源が投入された時点でスタートとなる。
まず、ステップS21において、スケジュール管理部61は、温度データ取得に向けてシステムをローパワーモードから通常モードに移行させる。なお、通常モードでなくても温度データ取得に必要なコンポーネントが稼動可能であればよい。
次に、ステップS22において、状態取得部62は、取得した温度データTempをログデータとして、状態ログデータ50に時刻と関連づけて記憶させる。
次に、ステップS23において、状態イベント判定部63は、今回取得したTempがあらかじめ設定された上限閾値Tth(上限)より大きいか又は下限閾値Tth(下限)より小さいかのいずれかを満たすか否かを判定する。いずれかを満たす場合は、貨物が高すぎる温度にさらされた又は低すぎる温度にさらされたおそれがあるため、イベント通信処理を実行し、時刻とイベント情報とTempとを関連づけた状態イベント情報を管理サーバ19に与える(ステップS24)。一方、閾値より小さい場合にはイベント通信処理は行わず、ステップS25において、省電力制御部65によりシステムはローパワーモードに移行する。なお、イベント通信処理の詳細については後述する。
そして、次のデータ更新間隔ごとの測定開始トリガを受信すると(ステップS26)、再度ステップS21からS25の手順を繰り返す。
以上の手順により、データロギングにおいて温度情報を取得することができるとともに、状態イベントが発生した場合には管理サーバ19に状態イベント情報を与えることができる。また、処理を実行していない際にはシステムを確実にローパワーモードに移行させることができる。
なお、図8には温度データの閾値に上限と下限の2つを用いる場合の例について示したが、閾値は下限のみまたは上限のみでもかまわない。また、図8には図7に示した衝撃情報取得時とは異なり、タイマセットは行っていない。これは、温度データの時間変化率が加速度データよりも小さいことを考慮したものである。
図9は、第1実施形態に係る管理端末12の主制御部41により実行される、データロギングにおける位置情報の取得処理の手順の一例を示すフローチャートである。図9において、Sに数字を付した符号は、フローチャートの各ステップを示す。
この手順は、管理端末12に対して電源が投入された時点でスタートとなる。
まず、ステップS31において、スケジュール管理部61は、RAMの所要のワークエリアに格納した測位不成功回数カウンタをクリアする。
次に、ステップS32において、スケジュール管理部61は、切替部37のGPS用スイッチ42を切り換えてGPS受信部32の電源を投入するよう給電制御部36に指示する。
次に、位置情報取得部67は、GPS受信部32からの出力データを監視し(ステップS33)、GPS測位に基づく位置情報の測位精度が有効であるか否か、すなわち、GPS測位に基づく位置情報が測位精度の高い状態で取得されたか否かを判定する(ステップS34)。
例えばGPS測位に基づく測位精度がレベル1乃至3までの中で最低のレベル1であった場合、管理端末12の現在の位置を示す位置情報として用いることが望ましくないことから、GPS測位に基づく位置情報の測位精度が有効ではないと判定される(ステップS34のNO)。
測位精度が有効であると判定されると(ステップS34のYES)、ステップS35において、位置情報取得部67は、測位成功情報を上書き保存するとともに、測位成功情報をログデータとして、位置ログデータ52に時刻と関連づけて記憶させる(ステップS35)。
また、測位成功を受けて測位条件が回復したものとみなし、ロングスリープ時間が設定されていればこれを解除して測位間隔を元に戻すとともに、測位不成功回数カウンタをクリアする(ステップS36)。
次に、ステップS37において、省電力制御部65は、切替部37のGPS用スイッチ42を切り換えてGPS受信部32の電源を切断するよう給電制御部36に指示する。
そして、次のデータ更新間隔ごとの測定開始トリガを受信すると(ステップS38)、再度ステップS32を実行する。
一方、ステップS34で位置情報の測位精度が有効ではないと判定されると、スケジュール管理部61は、測位タイマがタイムアウトしたか否かを判定する。測位タイマがタイムアウトしていなければステップS33に戻りGPS受信部32の出力を引き続き監視する。一方、タイムアウトした場合、ステップS41において、位置情報取得部67は、測位不成功の情報をログデータとして、位置ログデータ52に時刻と関連づけて記憶させる。また、測位不成功回数カウンタを1増加させる(ステップS41)。
この結果、測位不成功回数カウンタの数が閾値n以上となると(ステップS42のYES)、スケジュール管理部61は測位条件が不良と判定して、ロングスリープ時間を設定して測位間隔を延長し(ステップS43)、測位不成功回数カウンタをクリアしてから(ステップS44)、GPS受信部32の電源を切る(ステップS37)。
他方、測位不成功回数カウンタの数が閾値nより小さければ(ステップS42のNO)、スケジュール管理部61は、切替部37のGPS用スイッチ42を切り換えてGPS受信部32の電源を一旦切断するよう給電制御部36に指示するとともに、所要の時間(測位リトライ開始時間)だけ待機してから、GPS受信部32の電源を再投入するよう給電制御部36に指示する(ステップS45)。そして、電源の再投入後、ステップS33に戻りGPS受信部32の出力を引き続き監視する。
以上の手順により、データロギングにおいて位置情報を取得することができる。また、処理を実行していない際にはGPS受信部32の電源を確実に落としておくことができる。
続いて、管理サーバ19により実行される位置イベント判定処理について説明する。まず、位置イベント判定処理に必要な、注目領域の設定方法について説明する。
図10は、操作端末20により注目領域設定が行われる際の手順の一例を示すフローチャートである。図10において、Sに数字を付した符号はフローチャートの各ステップを示す。
まず、ステップS51において、操作端末20の制御部89は、管理サーバ19との間でネットワーク接続部86およびネットワーク18を介して接続を確立する。
次に、ステップS52において、制御部89は、ユーザにより入力部87が操作されることにより、注目領域設定処理を開始するとの指示が受け付けられたか否かを判定し、エリア設定処理を開始するとの指示が受け付けられるまで待機する。
注目領域設定処理の開始指示が受け付けられたと判定すると、制御部89は、ステップS53において、注目領域設定画面に関するHTMLファイルを管理サーバ19からネットワーク18を介して受信する。
次に、ステップS54において、制御部89は、管理サーバ19から受信された注目領域設定画面に関するHTMLファイルの字句解析および構文解析を行って注目領域設定画面画像情報を取得する(ステップS55)。
ステップS56において、制御部89は、注目領域設定画面画像情報にもとづいて、表示部88に注目領域設定画面を表示させる。注目領域設定画面には、ユーザが注目領域を設定しやすいように注目領域の検索欄を設けておくとよい。
また、管理端末12が出発地点Aに設定される出発地点スポットを出たことを位置イベント発生と判定するか、また管理端末12が到着地点Bに設定される到着地点スポットに入ったことを位置イベント発生と判定するかなどの位置イベント発生に係る選択を受け付けるための画像や、位置イベントが発生したと判定された際にメールを送信するか否かの選択を受け付ける画像を表示させておくとよい。
さらに、出発地点スポットと到着地点スポットは、例えば領域選択やライン選択、円選択を行うことで種々の形状に規定することが可能であり、これらの形状は緯度経度により表される。また、出発地点Aと到着地点Bとの間における輸送経路を設定する場合、出発地点Aと到着地点Bとの間で連続する複数の地点(例えば選択地点1乃至4など)を選択し、これらを結ぶことで形成される折れ線を中心線として所定の幅(例えば数メートルなど)をもたせた領域とすることもできる。また、経路が有する幅は適宜変更することができる。
次に、ステップS57において、制御部89は、表示部88に表示されたこのような注目領域設定画面をみたユーザによる入力部87を介した注目領域設定に関する種々の入力を受け付ける。
そして、ステップS58において、制御部89は、この受け付けた注目領域設定に関する入力情報(注目領域設定情報)を管理端末12の識別情報(例えば通信端末番号など)とともにネットワーク接続部86およびネットワーク18を介して管理サーバ19に送信する。
以上の手順により、管理端末12の識別情報と、注目領域の情報と、位置イベント発生条件とからなる注目領域設定情報を設定して管理サーバ19に与えることができる。
図11は、管理サーバ19における注目領域設定処理の手順の一例を示すフローチャートである。図11において、Sに数字を付した符号は、フローチャートの各ステップを示す。
まず、ステップS61において、管理サーバ19は、ネットワーク18を介して操作端末20から送信されてきた注目領域設定情報を受信する。
次に、ステップS62において、管理サーバ19の制御部73の注目領域設定部81は、この注目領域設定情報にもとづいて、管理端末12の注目領域(たとえば出発地点スポットと到着地点スポット)を設定する。このとき、設定された注目領域設定情報には、出発地点スポットと到着地点スポットを規定する経度緯度情報だけでなく、位置イベント判定を行う場合には判定後のメール送信の有無に関する情報などが含まれる。
次に、ステップS63において、注目領域設定部81は、設定された注目領域設定情報を管理端末12の識別情報と関連付けて記憶部72の注目領域設定情報データベース77に記憶させる。
以上の手順により、注目領域設定情報を管理サーバ19の記憶部72に登録することができる。
図12は、管理サーバ19により実行される位置イベント判定処理の手順の一例を示すフローチャートである。図12において、Sに数字を付した符号は、フローチャートの各ステップを示す。この手順は、管理サーバ19のログデータ受信部78が、定期通信により管理端末12からログデータを受信するたび(後述する図14のステップS121参照)に実行される。
なお、図12には、注目領域設定情報において、位置イベント発生条件が「管理端末12が出発地点Aに設定される出発地点スポットを出たこと」および「管理端末12が到着地点Bに設定される到着地点スポットに入ったこと」とされている場合の例について示した。
ステップS71において、位置イベント判定部80は、ログデータ受信部78により受信されたログデータに含まれる位置ログデータからGPS測位にもとづく位置情報を取得する。
次に、ステップS72において、位置イベント判定部80は、管理端末12の位置が出発地点に設定されているスポット(出発地点スポット)の内側か否かを判定する。内側の場合は、そのように認識して一連の手順は終了となる。
一方、管理端末12の位置が出発地点スポットの外側の場合であって(ステップS73のNO)、管理端末12の直前の位置が出発地点スポット内にある場合(ステップS74のYES)、管理端末12が出発地点スポットを出たと認識する(ステップS75)。そして、管理端末12が出発地点スポットを出た旨を内容とする位置イベント情報を生成して(ステップS76)、一連の手順は終了となる。なお、位置イベント情報は、図20のステップS151で利用される。
他方、ステップS74でNOと判定されると管理端末12の位置が到着地点スポット内にあるか否かを判定し(ステップS77)、到着地点スポット内にもない場合は管理端末12が経路中に存在すると認識して(ステップS78)一連の手順は終了となる。一方、到着地点スポット内にある場合は、直前の位置が到着地点スポット外にあったかを判定する(ステップS79)。スポット外にあった場合(ステップS79のYES)、管理端末12が到着地点スポットに入ったと認識し(ステップS80)、管理端末12が到着地点スポットに入った旨を内容とする位置イベント情報を生成して(ステップS81)、一連の手順は終了となる。なお、位置イベント情報は、図20のステップS151で利用される。ステップS79において直前の位置が到着地点スポット内だったと判定されると、前回から既に到着地点スポットに存在すると認識し(ステップS82)、一連の手順は終了となる。
以上の手順により、GPS測位から得られる位置情報と、あらかじめ設定された注目領域設定情報にもとづいて、貨物の現在の位置が貨物の出発地点スポット(またはエリア)から出た場合や目的地点スポット(エリア)に入った場合、またはあらかじめ設定された経路から外れた場合などに位置イベントが発生した(あらかじめ定めた状態である)と判定し、位置イベント情報を生成することができる。本実施形態においては、この位置イベント判定処理を管理サーバ19が行う。
図13は、管理端末12と管理サーバ19が協調して行う定期通信処理の手順の一例を示すフローチャートである。図13において、Sに数字を付した符号は、フローチャートの各ステップを示す。
まず、ステップS101において、管理端末12のスケジュール管理部61は、定期通信間隔ごとの動作開始トリガを受信する。
次に、ステップS102において、スケジュール管理部61は、定期通信処理に向けてシステムをローパワーモードから通常モードに移行させる。
次に、ステップS103において、通信制御部64は移動体通信部34を介して発呼し、管理サーバ19への接続処理を開始する。
次に、ステップS104において、スケジュール管理部61は、オペレータ検出がタイムアウトしたか否かを判定する。タイムアウトした場合は、システムをローパワーモードへ移行しつ、動作開始トリガを無視して所定時間待機する(ステップS105)。
一方、タイムアウトしなかった場合は、ステップS106においてスケジュール管理部61は通信タイムアウトになったか否かを判定し、タイムアウトになった場合はステップS116に進んでローパワーモードに移行する。
一方、通信タイムアウトにならず、接続が確立された場合は(ステップS107)、状態ログデータおよびイベント発生履歴が管理端末12から管理サーバ19に送信される(ステップS108)。また、管理サーバ19から管理端末12へは受信確認のACK/NAKが少なくとも送信される(ステップS109)。また、このステップS109と同時のタイミングで、必要に応じて管理サーバ19から管理端末12へコマンドが送信される。次に、スケジュール管理部61は、管理端末12の時刻情報出力部(RTC)39は、管理サーバ19の時刻と同期する(ステップS110)。
また、ACK/NAKと同時に管理サーバ19から管理端末12に対してコマンドが送信された場合(S111のYES)は、コマンドに応じたデータの送受信がすんでから(ステップS112、S113)、受信したコマンドに応じた動作を実行する。たとえば、コマンドの内容が設定パラメータの変更指示であると、コマンド処理部66は、主制御部41の記憶媒体に記憶された設定パラメータを変更指示に応じて変更する(ステップS114)。
次に、通信制御部64およびネットワーク接続部70は互いの接続を切断し(ステップS115)、省電力制御部65によりローパワーモードに移行して一連の手順は終了となる。
以上の手順により管理端末12と管理サーバ19とで定期通信処理を行うことができる。なお、定期通信処理の周期(第2の周期)は、状態検出部38などのロギングの周期(第1の周期)よりも長いほうが一度に多くのログデータを送信できるものの、あまり長くするとリアルタイム性を損なうことになる。
図14は、管理サーバ19と操作端末20が協調して行う定期通信処理の手順の一例を示すフローチャートである。図14において、Sに数字を付した符号は、フローチャートの各ステップを示す。
また、図15は、操作端末20の表示部88に表示されるログデータ検索用画像91およびログデータ一覧画像92の一例を示す説明図である。
ステップS120において、管理サーバ19のログデータ受信部78は、管理端末12からログデータ48を受信する(図13のステップS108参照)。
次に、ステップS121において、ログデータ受信部78は、受信したログデータを時系列で端末別ログデータDB74に保存する。また、ステップS122において、位置イベント判定部80は、ログデータ受信部78により受信されたログデータに含まれる位置ログデータからGPS測位にもとづく位置情報を取得して(図12のステップS71参照)、図12に示した位置イベント判定処理を実行する。
次に、ステップS123において、たとえば所定の時間、操作端末20から閲覧要求がないと、ステップS121に戻る。
次に、ステップS124において操作端末20を利用するユーザは、ログデータ検索用画像91を用いたログデータの閲覧要求を行う(図15参照)。閲覧要求の内容には、閲覧したいログデータを生成した管理端末12の名称やデータの期間、ミッション名などを含めておく。
次に、ステップS125においてこの閲覧要求が管理サーバ19に受信されると、ステップS126において、検索部79は、閲覧要求内容に応じて端末別ログデータDB74を検索し、検索したログデータを操作端末20に送信する。
次に、ステップS127において、操作端末20は、管理サーバ19から受けたログデータの一覧画像92を画面表示する(図15参照)。
図16は、ログデータ一覧画像92に対する地図表示要求に応じて表示される、地図上に管理端末12の位置が重畳された画像の一例を示す説明図である。
図16に示すように、ログデータ一覧画像92にある地図表示指示ボタン93を押下することにより、地図上に管理端末12の位置を重畳表示することができる(ステップS128)。
図17は、ログデータ一覧画像92に対するグラフ表示要求に応じて表示される、ログデータにもとづくグラフ94の一例を示す説明図である。
図17に示すように、ログデータ一覧画像92にあるグラフ表示指示ボタン95を押下することにより、ログデータにもとづくグラフ94を表示することができる(ステップS129)。
図18は、ログデータにもとづくグラフ94のプロットをクリックした場合に、地図上にこのプロットに対応する位置が表示される様子の一例を示す説明図である。
図18に示すように、ログデータにもとづくグラフ94のプロットをクリックすると、地図上にこのプロットに対応する位置が表示される(ステップS130)。
以上の手順により、管理サーバ19と操作端末20とで定期通信処理を行うことができる。
図19は、管理端末12と管理サーバ19が協調して行うイベント通信処理の手順の一例を示すフローチャートである。図19において、Sに数字を付した符号は、フローチャートの各ステップを示す。なお、図13と同等のステップには同一の符号を付して説明を省略する。本実施形態においては、このイベント通信処理で送受信されるイベント情報は状態イベント情報である。
ステップS141において、状態イベント判定部63は、状態イベントが発生した(図7ステップS8、図8ステップS24参照)と判定する。
次に、ステップS142において、通信制御部64は、現在、管理サーバ19と接続が確立した状態か否かを判定する。接続中の場合はステップS146に進む。一方、接続中でない場合はステップS102に進む。
ステップS143において、スケジュール管理部61は通信タイムアウトになったか否かを判定し、タイムアウトになった場合はステップS144に進み、リトライ数がn以上であるかを判定する。リトライ数がn以上である場合は、ステップ116に進んでローパワーモードへ移行する。一方、リトライ数がnより小さい場合は、ステップS145に進み、スケジュール管理部61は、リトライ開始時間だけ待ってから、接続動作をリトライすべくステップS143に戻る。このとき、リトライ数を1増加させる。
ステップS107で接続が確立さると、ステップS146において、状態イベント情報が管理端末12から管理サーバ19に送信される。また、管理端末12は、管理サーバ19に送信した状態イベント情報を自端末の記憶部40の状態イベント情報51に記憶させる。なお、ステップS146で状態イベント情報に加えてステータス情報を管理サーバ19に送信するとともに、ステップS147でステータス情報を記憶部40に記憶させてもよい。ステータス情報は、管理端末12の動作についての情報であり、諸動作の開始、通信の成功/失敗などに関する情報などを含む。
以上の手順により、管理端末12と管理サーバ19で協調してイベント通信処理を行うことができる。このため、状態イベント判定部63によりイベントが発生したと判定されると、速やかにその旨の情報およびイベントの内容が管理サーバ19に与えられる。
図20は、管理サーバ19と操作端末20が協調して行うイベント通信処理の手順の一例を示すフローチャートである。図20において、Sに数字を付した符号は、フローチャートの各ステップを示す。なお、図14と同等のステップには同一の符号を付して説明を省略する。
ステップS151において、位置イベント判定部80により位置イベント情報が生成されてイベント解析部82がこの位置イベント情報を取得し(図12のステップS76またはS81参照)、あるいは管理サーバ19のログデータ受信部78が管理端末12から状態イベント情報を受信すると(図19のステップS146参照)、ステップS152において、イベント解析部82は、取得したイベントデータを端末別イベントデータDB75に保存する。
次に、ステップS153において、イベント発生情報送信部83は、イベント情報を解析し、解析結果にもとづいてユーザに対してイベント情報を受信した旨の情報を与えるべきか否かを判定する。イベント情報を受信した旨の情報を与えるべきと判定した場合は、イベント情報を受信した旨の情報および少なくともイベント情報を内容として含む電子文書(電子メールなど)を生成し、イベント情報送信先テーブル76に記憶されたユーザのメールアドレス宛に送信する(ステップS154)。そして、イベント情報送信先テーブル76に記憶されたユーザが操作する操作端末20はこの電子文書を受信する(ステップS155)。
また、ステップS156において、たとえば所定の時間、操作端末20から閲覧要求がないと、ステップS151に戻る。
以上の手順により、管理サーバ19と操作端末20とでイベント通信処理を行うことができる。
本実施形態に係る管理端末12は、貨物が輸送中にログデータを蓄積しておき目的地に到着してからまとめて取り出す従来の方法に比べ、貨物が輸送中に所定の周期で貨物の状態および貨物の位置情報を内容とするログデータを逐次管理サーバ19に送信する。また、このログデータは、管理端末12が国際ローミングを行っている際にも管理サーバ19に送信される。このため、本実施形態に係る管理システム11によれば、グローバルな物流取引において、貨物の状態を容易かつ適切に、リアルタイムに把握することができる。
また、ユーザは、操作端末20を介して容易にログデータを閲覧することができる。さらに、操作端末20はネットワーク18に接続可能であれば世界中どこにあってもよく、したがって、ユーザもまた、世界中どこにいても、輸送中の貨物の状態をリアルタイムにきわめて容易に確認することができる。
また、本実施形態に係る管理システム11は、定期通信時に電波状況などにより正常な通信ができなかった場合にも、管理端末12はログデータを蓄積し続け、電波状況の回復次第速やかに蓄積したデータを管理サーバ19に送信する。このため、現実の厳しい輸送環境であっても、通信の失敗でログデータを失うことがないとともに、通信環境が復活すれば速やかに通常のリアルタイム性を取り戻すことができる。
また、本実施形態に係る管理システム11は、管理端末12により貨物の状態があらかじめ定めた状態であると判定されると、その旨の情報と判定された時刻とを関連付けた情報が管理端末12から管理サーバ19に与えられる。このため、ユーザは容易に貨物の状態に異常が生じたことを認識することができる。また、管理サーバ19は、管理端末12から受信した位置情報にもとづいて管理端末12の位置に関して(移動状況に関して)あらかじめ設定された条件を満たす位置イベント(たとえば目的地点スポット(エリア)に入ったというイベントなど)が発生したか否かを判定することができる。このため、ユーザは容易に管理端末12の位置イベントの有無を認識することができる。
また、本実施形態に係る管理システム11は、特に電力の消費が激しいGPS受信部32および移動体通信部34を、個別に給電制御することができる。このため、たとえば他のコンポーネントが間欠動作やスリープ状態に移行するタイミングでもこの両者には完全に給電を停止する対応をとることも可能である。したがって、管理システム11全体の電力消費量を大幅に削減することができる。さらに、GPS電波や移動体通信用電波が届かない場合には、ロングスリープ状態に移行することによって時間当たりのリトライ回数を減らすことができるため、無駄な電力消費を未然に防ぐことができる。
また、本実施形態に係る物流管理システム11は、管理サーバ19は、管理端末12からデータが送信されてくるタイミングまでコマンド送信を待機し、管理端末12からデータを受信すると、これに対する返答ACK/NAKを送信する際にコマンドもあわせて送信する。このため、国際ローミングを利用する場合でも管理サーバ19から管理端末12にコマンドを送信することができる。
(第2の実施形態)
次に、本発明に係る物流管理システムの第2実施形態について説明する。
この第2実施形態に示す物流管理システム11は、位置イベント判定処理が管理端末12Aで行われる点で第1実施形態に示す物流管理システム11と異なる。他の構成および作用については図1に示す物流管理システム11と実質的に異ならないため、同じ構成には同一符号を付して説明を省略する。
図21は、第2実施形態に係る管理端末12Aの内部構成例を概略的に示すブロック図である。また、図22は、第2実施形態に係る管理端末12Aの主制御部41AのCPUによる機能実現部の構成例を示す概略的なブロック図である。
図21に示すように、管理端末12Aの記憶部40Aは、ログデータ48Aおよび注目領域設定情報DB101を記憶するほか、各種閾値(温度閾値や加速度閾値など)を記憶する。第2実施形態においては、注目領域設定情報が管理サーバ19から管理端末12Aに与えられて、管理端末12Aの記憶部40Aの注目領域設定情報DB101にも記憶されている。
ログデータ48Aは、状態ログデータ50、状態イベント情報51、位置ログデータ52に加え、さらに位置イベント情報102を有する。位置イベント情報102には、位置イベント情報(位置イベントの内容と位置イベントの発生時刻とを関連づけたデータ)が蓄積される。
本実施形態に係る管理端末12Aの主制御部41AのCPUは、図22に示すように、物流管理プログラムによって少なくともスケジュール管理部61、状態取得部62、状態イベント判定部63、通信制御部64A、省電力制御部65、コマンド処理部66、位置情報取得部67および位置イベント判定部103として機能する。
通信制御部64Aは、第1実施形態に係る通信制御部64の機能に加え、さらに、状態イベントや位置イベントが発生した場合に、その旨の情報と、イベント発生時刻とを関連付けた情報を、移動体通信部34を介して管理サーバ19に与える機能を有する。
位置イベント判定部103は、GPS受信部32の受信信号にもとづくGPS測位から得られる位置情報と、注目領域設定情報DB101に記憶されたあらかじめ設定された注目領域設定情報にもとづいて、位置イベントが発生したか(あらかじめ定めた状態であるか)否かを判定し、位置イベント情報を生成する。
図23は、第2実施形態に係る管理サーバ19Aの内部構成例を概略的に示すブロック図である。
本実施形態に係る管理サーバ19Aの制御部73AのCPUは、図23に示すように、物流管理プログラムによって少なくともログデータ受信部78、検索部79、注目領域設定部81、イベント解析部82Aおよびイベント発生情報送信部83として機能する。すなわち、本実施形態において、制御部73AのCPUは、位置イベント判定部80として機能せずともよい。
イベント解析部82Aは、管理端末12から状態イベント情報または位置イベント情報を受信すると、各イベント情報を解析して端末別イベントデータDB75に格納する。
図24は、第2実施形態に係る管理端末12Aの主制御部41Aにより実行される、データロギングにおける位置情報の取得処理の手順の一例を示すフローチャートである。図24において、Sに数字を付した符号は、フローチャートの各ステップを示す。なお、図9と同等のステップには同一符号を付し、重複する説明を省略する。
本実施形態においては、ステップS36で位置情報取得部67により測位条件が回復したとみなされると、ステップS201において管理端末12Aの主制御部41Aにより位置イベント判定処理が行われる。
図25は、第2実施形態に係る管理端末12Aにより、図24のステップS201で実行される位置イベント判定処理の手順の一例を示すサブルーチンフローチャートである。図25において、Sに数字を付した符号はフローチャートの各ステップを示す。
ステップS211において、位置情報取得部67は、GPS受信部32を用いたGPS測位にもとづいて位置情報を取得する。
次に、ステップS212において、位置イベント判定部103は、管理端末12Aの位置が出発地点スポットの内側か否かを判定し、内側の場合は、そのように認識して図24のステップS37に進む(ステップS213)。
一方、管理端末12Aの位置が出発地点スポットの外側の場合であって(ステップS213のNO)、管理端末12Aの直前の位置が出発地点スポット内にある場合(ステップS214のYES)、管理端末12Aが出発地点スポットを出たと認識する(ステップS215)。そして、図19に示すイベント通信処理を実行し(ステップS216)、図24のステップS37に進む。
他方、ステップS214でNOと判定されると管理端末12Aの位置が到着地点スポット内にあるか否かを判定し(ステップS217)、到着地点スポット内にもない場合は管理端末12Aが経路中に存在すると認識して(ステップS218)、図24のステップS37に進む。一方、到着地点スポット内にある場合は、直前の位置が到着地点スポット外にあったかを判定する(ステップS219)。
スポット外にあった場合(ステップS219のYES)、管理端末12が到着地点スポットに入ったと認識し(ステップS220)、図19に示すイベント通信処理を実行して(ステップS221)、図24のステップS37に進む。ステップS219において直前の位置が到着地点スポット内だったと判定されると、前回から既に到着地点スポットに存在すると認識し(ステップS222)、図24のステップS37に進む。
本実施形態においては、上述したとおり管理サーバ19の制御部73Aは位置イベント判定部80の機能を備えずともよい。また、図14のステップS122は不要となる。また、図19のステップS146、147で扱われるイベント情報は状態イベントまたは位置イベントであり、図20のステップS151では、ログデータ受信部78が図19のステップS146で管理端末12から送信された状態イベント情報または位置イベント情報を受信する。
この第2実施形態に係る物流管理システム11によっても、第1実施形態に係る物流管理システム11と同様の効果を奏する。
また、第2実施形態に係る物流管理システム11は、管理端末12Aによって自らの位置に関して(移動状況に関して)あらかじめ設定された条件を満たす位置イベント(たとえば目的地点スポット(エリア)に入ったというイベントなど)が発生したか否かを判定することができ、管理サーバ19Aの処理負担を低減することができる。
なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
また、本発明の実施形態では、フローチャートの各ステップは、記載された順序に沿って時系列的に行われる処理の例を示したが、必ずしも時系列的に処理されなくとも、並列的あるいは個別実行される処理をも含むものである。