JP2019117493A - サーバー装置および車載機配備管理方法 - Google Patents

Abstract

【課題】煩雑な管理情報の入力操作を必要としないサーバー装置および車載機配備管理方法を提供する。【解決手段】車載機配備管理システム１において、サーバー装置は、車両の利用状態を特定する車両状態情報と、車載機の利用状態を特定する車載機状態情報と、を記憶する記憶部と、通信部と、車両の識別情報と、該車両の識別情報に対応付けられた車載機の識別情報と、を外部の装置から通信部を介して受信する報知受信部と、車載機からの通信の履歴に応じて車両および車載機の利用状態を推定する状態推定部と、状態推定部により推定された利用状態に応じた車両状態情報及び車載機状態情報を作成する状態情報作成部と、車両状態情報及び車載機状態情報を記憶部に記憶させる状態情報更新部と、を備える。【選択図】図１

Description

本発明は、サーバー装置および車載機配備管理方法の技術に関するものである。

「車両に搭載された複数の車載機器を制御する制御システムであって、前記制御システムは、前記複数の車載機器の機能に応じて予め複数のドメインに区分けされ、それら複数のドメインにおいて、それぞれ、前記車載機器を制御するための機器制御部と、前記機器制御部を統括するドメイン制御部とに階層化され、さらに、前記制御システムは、前記複数のドメインの各ドメイン制御部の上位に位置付けられ、各ドメイン制御部を統括する統合制御部を備え、少なくとも前記統合制御部とドメイン制御部とは、前記制御システムの構成情報として、自身の制御機能に関する情報と、自身の下位の制御部の制御機能に関する情報とを保有するように構成され、前記制御システムの構成情報が、前記統合制御部と前記ドメイン制御部とに分散して保有される制御システム。」に係る技術が、特許文献１に記載されている。

特開２０１７−０６１２７８号公報

上記のような技術では、車載機器同士の情報統制に係る変更管理はなされるが、車載機の配備管理は考慮されていない。多数の業務用車両の管理を行う場合には、車両の故障管理とともに、車載機の故障管理や車載機の搭載先の管理の要望があるが、これには煩雑な管理情報の入力操作を必要とする場合が多く、管理上の漏れや誤りが頻発し、取り外した車載機の紛失等の問題が発生しがちである。

本発明の目的は、煩雑な管理情報の入力操作を必要としないサーバー装置および車載機配備管理方法を提供することにある。

本発明は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下のとおりである。上記課題を解決すべく、本発明に係るサーバー装置は、車両の利用状態を特定する車両状態情報と、車載機の利用状態を特定する車載機状態情報と、を記憶する記憶部と、通信部と、上記車両の識別情報と、該車両の識別情報に対応付けられた上記車載機の識別情報と、を外部の装置から上記通信部を介して受信する報知受信部と、上記車載機からの通信の履歴に応じて上記車両および上記車載機の利用状態を推定する状態推定部と、上記状態推定部により推定された利用状態に応じた上記車両状態情報及び上記車載機状態情報を作成する状態情報作成部と、上記車両状態情報及び上記車載機状態情報を上記記憶部に記憶させる状態情報更新部と、を備えることを特徴とする。

本願発明によれば、煩雑な管理情報の入力操作を必要としないサーバー装置および車載機配備管理方法を提供することが可能となる。上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

本発明に係る実施形態を適用した車載機配備管理システムの構造を示す図である。 車載機のハードウェア構造例を示す図である。 サーバー装置のハードウェア構造例を示す図である。 車両状態情報のデータ構造例を示す図である。 車載機状態情報のデータ構造例を示す図である。 状態遷移テーブルのデータ構造例を示す図である。 車載機取付時処理の流れを示す図である。 状態決定処理の流れを示す図である。 状態確認画面の例を示す図である。

以下に、本発明に係る、車載機とサーバー装置と管理端末とを含む車載機配備管理システムについて、図面を参照して説明する。なお、図１〜図９は、車載機配備管理システム１の全ての構成を示すものではなく、理解容易のため、適宜、構成の一部を省略して描いている。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する場合がある。また、以下の実施の形態において、その構成要素（要素ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、「Ａからなる」、「Ａよりなる」、「Ａを有する」、「Ａを含む」と言うときは、特にその要素のみである旨明示した場合等を除き、それ以外の要素を排除するものでないことは言うまでもない。同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。

図１に、本発明に係る実施形態を適用した車載機配備管理システムの構造を示す。本発明に係る実施形態を適用した車載機配備管理システム１においては、車載機１００、管理端末２００および管理サーバーとなるサーバー装置３００の制御の一部に、アプリケーションソフトウェアによる制御が含まれる。また、車載機１００においては、アプリケーションソフトウェアの機能は、車載機１００のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）等の管理下で動作するアプリケーションソフトウェアプログラムによりハードウェアが制御されて実現されるものとする。一方で、管理端末２００およびサーバー装置３００においては、アプリケーションソフトウェアの機能は、管理端末２００およびサーバー装置３００のＯＳ等の管理下で動作するアプリケーションソフトウェアプログラムによりハードウェアが制御されて実現されるものとする。

車載機１００は、車両に搭載され各種のソフトウェアを実行可能な情報処理装置である。なお、車載機１００は、本実施形態においては、ＯＳを備え、複数のソフトウェア等のコンテンツをウェブブラウザ等において使用可能であり、並列してアプリケーションソフトウェア等のコンテンツを実行することも可能であるものとするが、これに限られず、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等のハードウェアで実現されてもよい。ただし、車載機１００は、車載の状態で使用される専用の装置に限られず、パーソナルコンピューターやスマートフォン、タブレット端末等の各種の独立動作可能な装置であってもよい。

車載機１００は、記憶部１１０と、制御部１２０と、通信部１３０と、タッチパネル１４０と、ディスプレイ１５０と、を含んで構成される。記憶部１１０には、搭載車両情報１１１と、車載機識別情報１１２と、が含まれる。制御部１２０には、入力制御部１２１と、画面制御部１２２と、利用開始処理部１２３と、車両制御処理部１２４と、アライブ報知部１２５と、の処理部が含まれる。

搭載車両情報１１１は、車載機１００が搭載される車両を特定する情報を含む。具体的には、搭載車両情報１１１は、車載機１００の搭載されている車両のナンバープレートや、車台番号、その他の登録された識別可能な番号を含む。搭載車両情報１１１は、車種や導入年月日等の情報を含んでいてもよいが、必ずしも必要ではない。

車載機識別情報１１２は、車載機１００を他の車載機から区別しうる識別情報を含む。具体的には、車載機識別情報１１２は、車載機１００に固有な製造番号等その他登録された識別可能な番号を含む。車載機識別情報１１２は、機種番号や導入年月日等の情報を含んでいてもよいが、必ずしも必要ではない。

入力制御部１２１は、タッチパネル１４０あるいは図示しないハードウェアキーからの入力を受け付ける。画面制御部１２２は、ディスプレイ１５０への画面表示を制御する。利用開始処理部１２３は、後述する車載機取付時処理を行う。具体的には、取り付けされる車両の識別情報を受け付けて、車載機と車両の関連付けをサーバー装置３００へ依頼する。

車両制御処理部１２４は、取り付けされた車両の制御処理またはその一部の処理を担う。例えば、車両制御処理部１２４は、車両の自動運転の補助処理を実施し、走行経路の誘導処理を行う。あるいは、車両制御処理部１２４は、ブレーキ制御の補助処理を実施する。

アライブ報知部１２５は、車載機１００の起動時に、通信部１３０を介してサーバー装置３００へ所定のアライブ情報を送信する。アライブ情報には、車載機１００を特定する情報（車載機識別情報１１２）が含まれる。

通信部１３０は、携帯電話網（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、あるいは無線ＬＡＮ（ＷｉＦｉ：登録商標）等を介してサーバー装置３００と通信を行う。タッチパネル１４０は、静電式あるいは感圧式のセンサを用いて、タッチ入力されたパネル上の位置を特定することができる。ディスプレイ１５０は、例えば有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）や液晶等の表示デバイスである。ディスプレイ１５０上にタッチパネル１４０を組み込むことで、表示画面上の表示物へのタッチ入力を検出することが可能となっている。

サーバー装置３００は、インターネット等のネットワークを介して車載機１００および管理端末２００と通信可能に接続される。サーバー装置３００は、いわゆるコンピューターサーバー装置であり、記憶部３１０と、制御部３２０と、通信部３３０と、を備える。

記憶部３１０には、車両状態情報３１１と、車載機状態情報３１２と、状態遷移テーブル３１３と、が格納される。制御部３２０には、利用開始報知受信部３２１と、アライブ報知受信部３２２と、状態推定部３２３と、状態情報作成部３２４と、状態情報更新部３２５と、管理サービス部３２６と、が含まれる。

図４は、車両状態情報のデータ構造例を示す図である。車両状態情報３１１には、車両識別子３１１ａと、車載機識別子３１１ｂと、状態３１１ｃと、最終通信日３１１ｄと、状態更新日３１１ｅと、が含まれる。

車両識別子３１１ａは、車載機１００が搭載される車両を識別する情報である。車載機識別子３１１ｂは、車両識別子３１１ａにより特定される車両に搭載される車載機１００を識別する情報である。状態３１１ｃは、車両の利用の状態を示す情報である。例えば、状態３１１ｃは、「正常動作」、「車両故障推定」等のステータスにより利用の状況を区別する情報である。最終通信日３１１ｄは、車両に搭載された車載機１００から最後に通信（アライブ報知も通信に含む）のあった日を特定する情報である。状態更新日３１１ｅは、車両の状態が最後に更新された日を特定する情報である。

図５は、車載機状態情報のデータ構造例を示す図である。車載機状態情報３１２には、車載機識別子３１２ａと、状態３１２ｂと、最終通信日３１２ｃと、状態更新日３１２ｄと、が含まれる。

車載機識別子３１２ａは、車載機１００を識別する情報である。状態３１２ｂは、車載機１００の利用の状態を示す情報である。例えば、状態３１２ｂは、「正常動作」、「状態要確認」、「取外し」、「修理中」、「修理完了」等、あるいは推定される状態として「保管品（使用状態になく、車載機修理者が保持する保管状態にある品）」、「予備品（使用状態になく、車両保有者が保持する予備状態にある品）」等のステータスにより利用の状況を区別する情報である。最終通信日３１２ｃは、車載機１００から最後に通信（アライブ報知も通信に含む）のあった日を特定する情報である。状態更新日３１２ｄは、車載機の状態が最後に更新された日を特定する情報である。

図６は、状態遷移テーブルのデータ構造例を示す図である。状態遷移テーブル３１３は、主として車載機の状態３１３ａを縦軸にとり、発生したイベント（３１３ｂ〜３１３ｆ）を横軸にとり、どのような状態でどのようなイベントが発生するとどのような状態に遷移するか、すなわち状態の変化の組み合わせをマトリックス上に表現した情報である。状態遷移テーブル３１３は、このようなデータ構造に限られず、他のデータ構造であってもよいが、本実施例では図６に示すテーブルの形式で記憶される。

イベントには、通信あり３１３ｂ、不通期限徒過３１３ｃ、取り付け車両に別の車載機取付あり３１３ｄ、修理入力あり３１３ｅ、修理完了入力あり３１３ｆ、が含まれる。イベント「通信あり」３１３ｂは、所定の期間内（例えば、１営業日以内）に利用開始の登録依頼、アライブ報知、その他通常利用上の通信等の何らかの通信がサーバー装置３００になされている場合に該当する。

イベント「不通期限徒過」３１３ｃは、所定の不通期限（例えば、５営業日以内）に利用開始の登録依頼、アライブ報知、その他通常利用上の通信等を含め何らの通信もサーバー装置３００になされていない場合（すなわち、不通状態にある場合）に該当する。

イベント「取り付け車両に別の車載機取付あり」３１３ｄは、既に車載機１００と対応付けされていた車両について、利用開始の登録依頼がなされた場合であって当該車載機１００と異なる車載機との対応付けの登録依頼である場合に該当する。イベント「修理入力あり」３１３ｅは、車載機１００について、管理端末２００から修理状態にあるとの入力を受け付ける場合に該当する。イベント「修理完了入力あり」３１３ｆは、車載機１００について、管理端末２００から修理が完了した旨の入力を受け付ける場合に該当する。

例えば、図６では、「正常動作」状態において、「不通期限徒過」３１３ｃのイベントが発生すると、両者の交差点となる「状態要確認」の状態へと車載機１００の状態が遷移することを示している。また、「修理中」において「不通期限徒過」３１３ｃのイベントが発生しても、状態は「−」、つまり変化しない（「修理中」のまま状態維持）。

また例えば、「正常動作」状態において、「取付車両に別の車載機取付あり」３１３ｄのイベントが発生すると、すなわち別の車載機との対応付けの登録依頼を受けた場合には、元の車載機１００は「取外し」状態へと遷移する。通常の運用ではこのような場合には車載機の故障による「取外し」を想定するため、その直前の不通の期間には車載機故障が推定されることとなる。

制御部３２０の利用開始報知受信部３２１は、車載機取付時処理において報知される登録依頼を受信して、車両状態情報３１１および車載機状態情報３１２に反映させる。アライブ報知受信部３２２は、車載機１００のアライブ報知部１２５により報知されるアライブ報知を受信して、車両状態情報３１１および車載機状態情報３１２の最終通信日を更新する。

状態推定部３２３は、車載機１００からの通信の履歴に応じて車両および車載機１００の利用状態を推定する。具体的には、状態推定部３２３は、車両状態情報３１１と、車載機状態情報３１２と、状態遷移テーブル３１３と、を読み出して、車載機１００からの通信の履歴に基づくイベントの発生を検出すると、状態と発生したイベントに応じて状態遷移テーブル３１３に該当する遷移先の状態を特定し車載機および車両の状態を推定する。

状態情報作成部３２４は、状態推定部３２３が推定した現在の状態および過去の状態の推定に基づいて、その状態の期間等を含めた状態に応じ、車両状態情報３１１、車載機状態情報３１２を更新するための所定の情報を生成する。

状態情報更新部３２５は、状態情報作成部３２４が作成した所定の情報を用いて、車両状態情報３１１、車載機状態情報３１２を更新する。

管理サービス部３２６は、管理端末２００からの車両状態情報３１１、車載機状態情報３１２の参照要求に応じて応答画面の情報を生成して返却する。具体的には、管理サービス部３２６は、車両識別子の入力を受け付けて、車両状態の情報及び搭載されている車載機の状態情報を表示させる画面情報を管理端末２００へ返す。また、車両あるいは車載機の状態の変化について手動入力を受け付ける画面を管理端末２００へ返し、入力された状態の情報を用いてそれぞれの状態情報を更新する。

通信部３３０は、携帯電話網（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、あるいは無線ＬＡＮ（ＷｉＦｉ：登録商標）等を介して車載機１００および管理端末２００と通信を行う。

管理端末２００は、インターネット等のネットワークを介してサーバー装置３００と通信可能に接続される。管理端末２００は、いわゆるコンピューター装置であり、制御部２２０と、通信部２３０と、を少なくとも備える。

制御部２２０には、状態情報提示部２２１と、状態情報更新部２２２と、入力制御部２２３と、画面制御部２２４と、が含まれる。状態情報提示部２２１は、サーバー装置３００に車両及び車載機の状態情報の要求を行い、受け取った状態情報を提示する出力画面を生成し、画面制御部２２４から出力させる。

状態情報更新部２２２は、車両または車載機の状態について更新がある場合に更新の入力を受け付けると、サーバー装置３００へ送信し、車両または車載機の状態を更新するよう状態情報更新部３２５へ依頼する。

入力制御部２２３は、図示しないハードウェアキーやディスプレイからの入出力を受け付ける。画面制御部２２４は、ディスプレイへの画面表示を制御する。通信部２３０は、携帯電話網あるいは無線ＬＡＮ（ＷｉＦｉ：登録商標）等を介して車載機１００およびサーバー装置３００と通信を行う。

図２は、車載機のハードウェア構造例を示す図である。車載機１００は、入力受付装置１０１と、演算装置１０２と、通信装置１０３と、主記憶装置１０４と、外部記憶装置１０５と、表示装置１０６と、これらをつなぐバス１０９と、を含んで構成される。

入力受付装置１０１は、ハードウェアボタンやタッチパネル等の各種入力装置である。演算装置１０２は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置である。

通信装置１０３は、携帯電話網や、無線ネットワーク等を介して、他の装置と通信経路を確立し情報を送受信するネットワークモジュール等の装置である。

主記憶装置１０４は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などのメモリ装置である。

外部記憶装置１０５は、例えばハードディスクやＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、その他各種の不揮発性記憶媒体に情報を書き込み、あるいは不揮発性記憶媒体から所定の情報を読み出す装置である。

表示装置１０６は、例えば液晶ディスプレイや、有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等の表示出力を行う装置である。

上記した制御部１２０の各機能部、すなわち入力制御部１２１、画面制御部１２２、利用開始処理部１２３、車両制御処理部１２４、アライブ報知部１２５は、演算装置１０２が所定のプログラムを読み込み実行することにより構築される。そのため、主記憶装置１０４には、各機能部の処理を実現するためのプログラムが記憶されている。

また、上記した記憶部１１０は、主記憶装置１０４あるいは外部記憶装置１０５により、タッチパネル１４０は、入力受付装置１０１により、ディスプレイ１５０は、表示装置１０６により、通信部１３０は、通信装置１０３により、それぞれ実現される。

なお、上記した各構成要素は、車載機１００の構成を、理解を容易にするために、主な処理内容に応じて分類したものである。そのため、構成要素の分類の仕方やその名称によって、本願発明が制限されることはない。車載機１００の構成は、処理内容に応じて、さらに多くの構成要素に分類することもできる。また、１つの構成要素がさらに多くの処理を実行するように分類することもできる。

また、制御部１２０の各機能部は、ＣＰＵに限らずハードウェア（ＡＳＩＣ、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）など）により構築されてもよい。また、各機能部の処理が一つのハードウェアで実行されてもよいし、複数のハードウェアで実行されてもよい。

図３は、サーバー装置３００のハードウェア構造例を示す図である。サーバー装置３００は、入力受付装置３０１と、演算装置３０２と、通信装置３０３と、主記憶装置３０４と、外部記憶装置３０５と、表示装置３０６と、これらをつなぐバス３０９と、を含んで構成される。

入力受付装置３０１は、ハードウェアボタンやタッチパネル等の各種入力装置である。演算装置３０２は、例えばＣＰＵなどの演算装置である。

通信装置３０３は、携帯電話網や、無線ネットワーク等を介して、他の装置と通信経路を確立し情報を送受信するネットワークモジュール等の装置である。

主記憶装置３０４は、例えばＲＡＭなどのメモリ装置である。

外部記憶装置３０５は、例えばハードディスクやＳＳＤ、その他各種の不揮発性記憶媒体に情報を書き込み、あるいは不揮発性記憶媒体から所定の情報を読み出す装置である。

表示装置３０６は、例えば液晶ディスプレイや、有機ＥＬディスプレイ等の表示出力を行う装置である。

上記した制御部３２０の各機能部、すなわち利用開始報知受信部３２１、アライブ報知受信部３２２、状態推定部３２３、状態情報作成部３２４、状態情報更新部３２５、管理サービス部３２６は、演算装置３０２が所定のプログラムを読み込み実行することにより構築される。そのため、主記憶装置３０４には、各機能部の処理を実現するためのプログラムが記憶されている。

また、上記した記憶部３１０は、主記憶装置３０４あるいは外部記憶装置３０５により、通信部３３０は、通信装置３０３により、実現される。

なお、上記した各構成要素は、サーバー装置３００の構成を、理解を容易にするために、主な処理内容に応じて分類したものである。そのため、構成要素の分類の仕方やその名称によって、本願発明が制限されることはない。サーバー装置３００の構成は、処理内容に応じて、さらに多くの構成要素に分類することもできる。また、１つの構成要素がさらに多くの処理を実行するように分類することもできる。

また、制御部３２０の各機能部は、ＣＰＵに限らずハードウェアにより構築されてもよい。また、各機能部の処理が一つのハードウェアで実行されてもよいし、複数のハードウェアで実行されてもよい。なお、管理端末２００についても、基本的にサーバー装置３００と同様のハードウェア構成を備える。

［動作の説明］次に、車載機取付時の処理に関する動作について説明する。図７は、車載機取付時処理の流れを示す図である。車載機取付時処理は、車載機１００を車両に取付ける初回において、取付け後、車載機１００の初回起動時に開始される。

まず、利用開始処理部１２３は、車両識別子の設定入力を受け付けたか否かを判定する（ステップＳ００１）。具体的には、利用開始処理部１２３は、車載機１００が搭載される車両について車両識別子の入力を受け付ける所定の設定入力画面を表示させ、入力を受け付ける。そして、利用開始処理部１２３は、入力を受け付けたか否かを判定する。利用開始処理部１２３は、車両識別子の設定入力を受け付けなかった場合（ステップＳ００１にて「Ｎｏ」の場合）には、車載機取付時処理を終了させる。

車両識別子の設定入力を受け付けた場合（ステップＳ００１にて「Ｙｅｓ」の場合）には、利用開始処理部１２３は、車両識別子を搭載車両情報１１１に格納する（ステップＳ００２）。

そして、利用開始処理部１２３は、車両識別子と車載機識別子とを含む登録依頼をサーバー装置３００に送信する（ステップＳ００３）。具体的には、利用開始処理部１２３は、搭載車両情報１１１から車両識別子を読み出し、車載機識別情報１１２から車載機識別情報を読み出し、両者を含む所定の登録依頼情報を生成してサーバー装置３００に送信する。

利用開始報知受信部３２１は、車両識別子と車載機識別子とを含む登録依頼を受信し、車両状態情報に反映する（ステップＳ００４）。具体的には、利用開始報知受信部３２１は、車両識別子と車載機識別子とを含む登録依頼を受信し、車両状態情報３１１の車両識別子３１１ａに受信した車両識別子を格納し、対応する車載機識別子３１１ｂに受信した車載機識別子を格納するとともに、直前の車載機識別子をバッファに退避しておく。そして、利用開始報知受信部３２１は、最終通信日３１１ｄ、状態更新日３１１ｅにそれぞれ処理時点の日を特定する情報を格納する。

そして、利用開始報知受信部３２１は、車両識別子に対応付けられた直前の車載機識別子から変更があったか否か判定する（ステップＳ００５）。具体的には、利用開始報知受信部３２１は、ステップＳ００４においてバッファに退避した車載機識別子と、ステップＳ００４において受信した車両識別子と、を比較して、変化があったか否かを判定する。変化が無かった場合（ステップＳ００５にて「Ｎｏ」の場合）には、利用開始報知受信部３２１は、バッファをクリアして、サーバー装置側の処理を終了させる。

変化があった場合（ステップＳ００６にて「Ｙｅｓ」の場合）には、状態推定部３２３は、元の車載機の状態を「取外し」、新たな車載機の状態を「正常動作」と推定して車載機状態情報に反映する（ステップＳ００６）。具体的には、状態推定部３２３は、バッファに退避された車載機識別子にて対応付けられていた車載機については、元の車載機の状態を「取外し」と推定する。そして、当該推定に基づいて、状態情報作成部３２４は、車載機状態情報３１２の車載機識別子３１２ａに車載機識別子を格納し、状態３１２ｂに「取外し」を格納し、最終通信日３１２ｃ、状態更新日３１２ｄにそれぞれ処理時点の日を特定する情報を作成する。また、状態推定部３２３は、新たな車載機識別子にて対応付けられる車載機については、車載機状態情報３１２の車載機識別子３１２ａに車載機識別子を格納し、状態３１２ｂに「正常動作」を格納し、最終通信日３１２ｃ、状態更新日３１２ｄにそれぞれ処理時点の日を特定する情報を作成する。そして、作成された情報を用いて、状態情報更新部３２５が車載機状態情報３１２を更新する。

以上が、車載機取付時処理の流れである。車載機取付時処理によれば、車載機の取付けにより車両との対応付けが記憶される。また、従来取り付けられていた車載機が交換された場合には、特段の入力作業を要することなく従来取り付けられていた車載機の状態を「取り外し」として記録することができる。

図８は、状態決定処理の流れを示す図である。状態決定処理は、アライブ報知部１２５からの報知をアライブ報知受信部３２２が受信する都度、あるいは周期的に（例えば、１日１回）開始される。

まず、状態推定部３２３は、未処理の車載機を選択する（ステップＳ１０１）。具体的には、状態推定部３２３は、車載機状態情報３１２の車載機識別子３１２ａを参照して、未処理の車載機を一つ特定する。

そして、状態推定部３２３は、車載機が所定間隔未満で通信を行えているか否かを判定する（ステップＳ１０２）。具体的には、状態推定部３２３は、ステップＳ１０１にて選択した車載機の車載機状態情報３１２について、最終通信日３１２ｃを参照して、処理時点から所定の期間内か否かを判定する。所定の期間内であれば（ステップＳ１０２にて「Ｙｅｓ」の場合には）、状態推定部３２３は、車載機が所定間隔未満で通信を行えていると判定し、ステップＳ１０３へ制御を進める。

状態推定部３２３は、車載機の現状（最新の状態）を取得する（ステップＳ１０３）。具体的には、状態推定部３２３は、車載機状態情報３１２を参照して、ステップＳ１０１にて選択した車載機にかかる最新の状態３１２ｂを読み出し、現状とする。

そして、状態推定部３２３は、現状からイベント「通信あり」に該当する状態へと遷移させる（ステップＳ１０４）。具体的には、状態推定部３２３は、状態遷移テーブル３１３を参照して、ステップＳ１０３で取得した現在の状態である現状３１３ａから、イベント「通信あり」３１３ｂ発生の場合に相当する状態を特定し、これを車両および車載機１００の状態として推定する。なお、車載機１００の状態の推定に加えて、車両の状態が推定可能な組み合わせの場合には、状態遷移テーブル３１３においては車両の状態も含まれているため、車両および車載機１００の状態を推定および遷移可能である。

そして、状態情報作成部３２４は、状態推定部３２３の推定に基づき、車両の状態と、車載機の状態と、のそれぞれの状態について状態情報を変更するための情報（例えば、車載機識別子とその状態、始期と終期等、車両識別子とその状態、始期と終期等を特定する情報）を作成する。そして、状態情報更新部３２５は、状態情報を変更するための情報を作成し、車両と車載機の状態情報をそれぞれ更新する。なお、状態情報更新部３２５は、過去の不通状態の推定が含まれるものであれば、過去の不通状態についての状態情報についても更新する。

車載機が所定間隔未満で通信を行えていない場合、すなわち最終通信日３１２ｃが処理時点から所定の期間内で無い場合（ステップＳ１０２にて「Ｎｏ」の場合）には、状態推定部３２３は、所定の不通期限（通信が途絶している期間の限度）を徒過したか否かを判定する（ステップＳ１０５）。具体的には、状態推定部３２３は、車載機状態情報３１２の最終通信日３１２ｃを参照して、最終の通信日から５営業日を徒過しているか否か判定する。不通期限を徒過していない場合（ステップＳ１０５にて「Ｎｏ」の場合）には、状態推定部３２３は、状態決定処理を終了させる。

不通期限を徒過している場合（ステップＳ１０５にて「Ｙｅｓ」の場合）には、状態推定部３２３は、車載機の現状（最新の状態）を取得する（ステップＳ１０６）。具体的には、状態推定部３２３は、車載機状態情報３１２を参照して、ステップＳ１０１にて選択した車載機にかかる最新の状態３１２ｂを読み出し、現状とする。

そして、状態推定部３２３は、現状からイベント「不通期限徒過」に該当する状態へと遷移させる（ステップＳ１０７）。具体的には、状態推定部３２３は、状態遷移テーブル３１３を参照して、ステップＳ１０３で取得した現在の状態である現状３１３ａから、イベント「不通期限徒過」３１３ｃ発生の場合に相当する状態を特定し、これを車両および車載機１００の状態として推定する。なお、車載機１００の状態の推定に加えて、車両の状態が推定可能な組み合わせの場合には、状態遷移テーブル３１３においては車両の状態も含まれているため、車両および車載機１００の状態を推定および遷移可能である。

そして、状態情報作成部３２４は、状態推定部３２３の推定に基づき、車両の状態と、車載機の状態と、のそれぞれの状態について状態情報を変更するための情報（例えば、車載機識別子とその状態、始期と終期等、車両識別子とその状態、始期と終期等を特定する情報）を作成する。そして、状態情報更新部３２５は、状態情報を変更するための情報を作成し、車両と車載機の状態情報をそれぞれ更新する。なお、状態情報更新部３２５は、過去の不通状態の推定が含まれるものであれば、過去の不通状態についての状態情報についても更新する。

以上が、状態決定処理の流れである。状態決定処理によれば、車載機の通信状況により車両と車載機との状態の決定がなされる。そのため、特段の入力作業を要することなく車両と車載機の状態を記録することができる。例えば、車載機が正常動作していても不通期間が長くなると、状態を確認する必要があるという状態（「状態要確認」）になるため、これを参照すれば状態を管理できなくなる可能性を抑えることができる。特に、「取外し」状態にある場合に、不通期間が所定以上長くなると、放置すなわち車両に取り付けられず、修理されてもいない状態にあるおそれがあるため、状態要確認とされ、紛失あるいは盗難されることを未然に防止しうる。

図９は、状態確認画面の例を示す図である。状態確認画面４００は、管理端末２００の状態情報提示部２２１から要求を受け付けると、管理サービス部３２６が作成し、通信部３３０により管理端末２００へ送信される画面である。状態確認画面４００は、車両識別子入力領域４０１と、車両状態表示領域４０２と、車載機状態表示領域４０３と、履歴表示指示入力領域４１０と、を含む。車両識別子入力領域４０１は、車両識別子の入力を受け付ける領域である。車両状態表示領域４０２は、車両識別子入力領域４０１に入力された車両識別子により識別される車両について、状態および状態の履歴となる車両状態情報３１１をリスト表示する領域である。車載機状態表示領域４０３は、車両識別子入力領域４０１に入力された車両識別子により識別される車両に対応付けられたことのある車載機１００の夫々について、状態および状態の履歴となる車載機状態情報３１２をリスト表示する領域である。

履歴表示指示入力領域４１０は、入力を受け付けると、管理サービス部３２６に制御を受け渡す。管理サービス部３２６は、車両識別子入力領域４０１に入力された車両識別子の車両について、車両状態情報３１１を参照して車両状態の現状と履歴とを車両状態表示領域４０２に表示するよう構成させる。また、管理サービス部３２６は、車両識別子入力領域４０１に入力された車両識別子の車両に搭載された車載機１００のすべてを車両状態情報３１１を参照して特定する。そして、管理サービス部３２６は、車載機状態情報３１２を参照して車載機の状態の現状と履歴とを車載機状態表示領域４０３に表示するよう画面情報を構成する。そして、管理サービス部３２６は、通信部３３０に指示して、状態確認画面４００を管理端末２００へ送信させる。

以上が、本発明に係る実施形態を適用した車載機配備管理システム１である。車載機配備管理システム１によれば、煩雑な管理情報の入力操作を必要としないサーバー装置および車載機配備管理方法を提供することができる。

ただし、本発明は、上記の実施形態に制限されない。上記の実施形態は、本発明の技術的思想の範囲内で様々な変形が可能である。例えば、状態遷移テーブル３１３に規定された「状態」については、管理目的に応じてさまざまに細分化あるいは統合化されてもよい。あるいは、車両の位置情報を用いることで、車両の故障の推定の精度を高めるようにしてもよい。例えば、車両の位置情報の履歴をサーバー装置３００において記録しておき、所定期間に移動した距離が極端に短い場合には、整備工場内で故障修理を行っている可能性を高く推定するようにしてもよい。

１・・・車載機配備管理システム、１００・・・車載機、１１０・・・記憶部、１１１・・・搭載車両情報、１１２・・・車載機識別情報、１２０・・・制御部、１２１・・・入力制御部、１２２・・・画面制御部、１２３・・・利用開始処理部、１２４・・・車両制御処理部、１２５・・・アライブ報知部、１３０・・・通信部、１４０・・・タッチパネル、１５０・・・ディスプレイ、２００・・・管理端末、２２０・・・制御部、２２１・・・状態情報提示部、２２２・・・状態情報更新部、２２３・・・入力制御部、２２４・・・画面制御部、２３０・・・通信部、３００・・・サーバー装置、３１０・・・記憶部、３１１・・・車両状態情報、３１２・・・車載機状態情報、３１３・・・状態遷移テーブル、３２０・・・制御部、３２１・・・利用開始報知受信部、３２２・・・アライブ報知受信部、３２３・・・状態推定部、３２４・・・状態情報作成部、３２５・・・状態情報更新部、３２６・・・管理サービス部、３３０・・・通信部

Claims (12)

1. 車両の利用状態を特定する車両状態情報と、車載機の利用状態を特定する車載機状態情報と、を記憶する記憶部と、
   通信部と、
   前記車両の識別情報と、該車両の識別情報に対応付けられた前記車載機の識別情報と、を外部の装置から前記通信部を介して受信する報知受信部と、
   前記車載機からの通信の履歴に応じて前記車両および前記車載機の利用状態を推定する状態推定部と、
   前記状態推定部により推定された利用状態に応じた前記車両状態情報及び前記車載機状態情報を作成する状態情報作成部と、
   前記車両状態情報及び前記車載機状態情報を前記記憶部に記憶させる状態情報更新部と、
   を備えることを特徴とするサーバー装置。
2. 請求項１に記載のサーバー装置であって、
   前記状態推定部は、前記車両の識別情報に対して前記車載機の識別情報の変化があった場合には、変化前の前記車載機の状態を車両から取り外された状態と推定する、
   ことを特徴とするサーバー装置。
3. 請求項１に記載のサーバー装置であって、
   前記状態推定部は、前記車載機からの通信が不通の期間が、所定の期間を徒過する場合に、前記車載機は状態の確認を要する状態と推定する、
   ことを特徴とするサーバー装置。
4. 請求項１に記載のサーバー装置であって、
   前記状態推定部は、前記車載機が、状態の確認を要する場合であって、前記車載機からの通信があった場合には、前記通信が不通の期間において前記車載機は正常動作状態にあり、前記車両は故障の状態にあったと推定する、
   ことを特徴とするサーバー装置。
5. 請求項１に記載のサーバー装置であって、
   前記状態推定部は、前記車載機の状態が修理完了後であって、前記車載機からの通信が不通の期間が、所定の期間を徒過する場合は、前記車載機は保管状態にあると推定する、
   ことを特徴とするサーバー装置。
6. 請求項１に記載のサーバー装置であって、
   前記状態推定部は、前記車載機が車両から取り外された状態にある場合に通信が継続している場合には、前記取り外された状態において前記車載機は正常動作状態にあり、前記車両は故障の状態にあったと推定する、
   ことを特徴とするサーバー装置。
7. サーバー装置による車載機配備管理方法であって、
   前記サーバー装置は、
   車両の利用状態を特定する車両状態情報と、車載機の利用状態を特定する車載機状態情報と、を記憶する記憶部と、通信部と、制御部と、を備え、
   前記制御部は、
   前記車両の識別情報と、該車両の識別情報に対応付けられた前記車載機の識別情報と、を外部の装置から前記通信部を介して受信する報知受信ステップと、
   前記車載機からの通信の履歴に応じて前記車両および前記車載機の利用状態を推定する状態推定ステップと、
   前記状態推定ステップにおいて推定された利用状態に応じた前記車両状態情報及び前記車載機状態情報を作成する状態情報作成ステップと、
   前記車両状態情報及び前記車載機状態情報を前記記憶部に記憶させる状態情報更新ステップと、
   を実施することを特徴とする車載機配備管理方法。
8. 請求項７に記載の車載機配備管理方法であって、
   前記状態推定ステップでは、前記車両の識別情報に対して前記車載機の識別情報の変化があった場合には、変化前の前記車載機の状態を車両から取り外された状態と推定する、
   ことを特徴とする車載機配備管理方法。
9. 請求項７に記載の車載機配備管理方法であって、
   前記状態推定ステップでは、前記車載機からの通信が不通の期間が、所定の期間を徒過する場合に、前記車載機は状態の確認を要する状態と推定する、
   ことを特徴とする車載機配備管理方法。
10. 請求項７に記載の車載機配備管理方法であって、
    前記状態推定ステップでは、前記車載機が、状態の確認を要する場合であって、前記車載機からの通信があった場合には、前記通信が不通の期間において前記車載機は正常動作状態にあり、前記車両は故障の状態にあったと推定する、
    ことを特徴とする車載機配備管理方法。
11. 請求項７に記載の車載機配備管理方法であって、
    前記状態推定ステップでは、前記車載機の状態が修理完了後であって、前記車載機からの通信が不通の期間が、所定の期間を徒過する場合は、前記車載機は保管状態にあると推定する、
    ことを特徴とする車載機配備管理方法。
12. 請求項７に記載の車載機配備管理方法であって、
    前記状態推定ステップでは、前記車載機が車両から取り外された状態にある場合に通信が継続している場合には、前記取り外された状態において前記車載機は正常動作状態にあり、前記車両は故障の状態にあったと推定する、
    ことを特徴とする車載機配備管理方法。

Images