携帯端末及びその障害検出システム
【課題】携帯端末の故障時の衝撃の原因を速やかに特定することの可能な携帯端末及びその障害検出システムを提供する。
【解決手段】障害検出システムは、携帯端末に加速度センサと、衝撃あるいは振動を受けたときの加速度の時間変化である衝撃パターンを格納する衝撃データベースとを備える。加速度センサが検出した加速度の時間変化が、衝撃パターンと一致した場合には、携帯端末に取り扱いに関する警告を表示する。衝撃データベースは、携帯端末とネットワークで接続するサーバに設けても良い。サーバは、携帯端末から送られてくる加速度の時間変化を衝撃パターンと照合し、一致した場合には、必要に応じて携帯端末に警告を発する。サーバでは、異なる携帯端末で同様の衝撃パターンに一致する加速度の時間変化を検出した場合には、同一環境内の全携帯端末に警告を発するようにしても良い。
【解決手段】障害検出システムは、携帯端末に加速度センサと、衝撃あるいは振動を受けたときの加速度の時間変化である衝撃パターンを格納する衝撃データベースとを備える。加速度センサが検出した加速度の時間変化が、衝撃パターンと一致した場合には、携帯端末に取り扱いに関する警告を表示する。衝撃データベースは、携帯端末とネットワークで接続するサーバに設けても良い。サーバは、携帯端末から送られてくる加速度の時間変化を衝撃パターンと照合し、一致した場合には、必要に応じて携帯端末に警告を発する。サーバでは、異なる携帯端末で同様の衝撃パターンに一致する加速度の時間変化を検出した場合には、同一環境内の全携帯端末に警告を発するようにしても良い。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯端末及び携帯端末の障害検出システムに関する。
【背景技術】
【０００２】
今日、商品を販売する店舗においては、ＰＯＳ(Point Of Sale)システムが広く使われているが、百貨店や専門店などにおいては、購入する商品が１点から数点と少量であることが多い。このような場合、商品をＰＯＳカウンターに持って行き決済を行なうより、商品の販売場所において決済を行なうほうが、移動時間やＰＯＳカウンターでの待ち時間が短縮され顧客利便性が向上する。そのためには、決済を行なうためのツールを店員が持ち運びできるようにする必要がある。このような用途のために、モバイルＰＯＳというシステムが存在する。店員は、カードの読み取り器や、バーコードの読み取り器等、決済に必要となるツールが搭載された携帯端末を持ち、商品の販売場所において、この携帯端末を用いて決済を行なう。
【０００３】
このようなモバイルＰＯＳシステムを使用する場合、１つの店舗に多くの同様な携帯端末を配備し、携帯端末が店舗に配置されたサーバと通信することによって決済処理を行う。このような携帯端末は、店内で多くの店員が商品の販売をしながら扱うので、携帯端末を落としたり、壁にぶつけたりしがちである。携帯端末に激しい衝撃が加わると故障の原因になるが、不注意な携帯端末の扱いを複数の店員が行なっていると、類似障害が発生する。このような障害の発生を防ぐための手段が望まれる。
【０００４】
携帯端末が落下故障した場合には、携帯端末を修理に出すのであるが、修理の際に、モールドカバーや基板の破損状態から落下方向、衝撃力分析を行なったり、板金部材の歪み量からの落下方向、衝撃力分析を行なうなどの障害分析が行なわれる。
【０００５】
しかし、このような障害分析は困難な場合が多いので、携帯端末に加速度センサを設け、障害発生時の状況を記録することが考えられる。
従来の携帯機器における加速度センサ技術としては、既に様々なものが知られている。例えば、ハードディスクドライブ（ＨＤＤ）などにおいては、落下（無重力）を検出し、ＨＤＤの磁気ヘッドの固定エリア退避を行なうことが知られている。また、他の加速度センサの用途としては、耐タンパ性を有する高セキュリティ装置において、衝撃あるいは高加速度を検出し、装置を破壊しようとした試みを検出するものがある。更に、カメラ手振れ防止のために、加速度センサで振動を検出したり、ゲームコントローラにおいて、移動、方向検出、端末上下検出などを行なうものも知られている。
【０００６】
その他、加速度センサを利用した故障分析の従来技術には、衝撃時の加速度と時間変化を用いて衝撃度を検出するものや、端末の衝撃時の加速度を記録し、落下故障を特定するものがある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−１６２７０３号公報
【特許文献２】特開２００８−２３２６３１号公報
【特許文献３】特開２００９−０５３９４９号公報
【特許文献４】特開２００５−２４１３３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、従来では、下記の問題が発生していた。
・故障返却された装置を調べても、落下衝撃の位置、方向、頻度等の詳細情報が記録されていないため、落下した根本原因の調査において破損状態の外観確認に頼ることとなり、調査に長時間を要している。
・小さな衝撃の蓄積による疲労は、外観に痕跡が残りにくく、障害原因が断定できないことがあった。
・大規模運用において、複数端末で問題が発生しても、リアルタイムの改善対策ができなかった。
【０００９】
本発明の課題は、携帯端末の故障時の衝撃の原因を速やかに特定することの可能な携帯端末及びその障害検出システムを提供することである。
【課題を解決するための手段】
【００１０】
本発明の一側面における携帯端末は、メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサと、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該表示部に表示させる制御部とを備える。
【００１１】
本発明の一側面における障害検出システムは、携帯端末と通信することによって障害が発生する状況を検出する障害検出システムであって、メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサとを備える携帯端末と、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の該表示部に表示させる、該携帯端末とネットワークにより接続されたサーバとを備える。
【発明の効果】
【００１２】
本発明によれば、携帯端末の故障時の衝撃の原因を速やかに特定することの可能な携帯端末及びその障害をリアルタイムに検出して携帯端末に警告表示するシステムを提供することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態に従った、スタンドアローン型携帯端末の機能ブロック構成図である。
【図２】本実施形態に従った、サーバ接続型の障害検出システムのシステム構成図である。
【図３】サーバ接続型障害検出システムの機能ブロック構成図である。
【図４】衝撃ＤＢに格納されるデータの例を示す図である。
【図５】携帯端末の外観図である。
【図６】衝撃検出処理のフローチャートである。
【図７】本実施形態に従った、サーバ型障害検出システムであって、サーバから複数の携帯端末に同時に警告メッセージを送出する構成のシステム構成図である。
【図８】図７の構成例のサーバ型障害検出システムの機能ブロック構成図である。
【図９】サーバメモリに格納されるデータの例を示した図である。
【図１０】図７の構成例におけるサーバの動作のフローチャートである。
【図１１】事前に衝撃ＤＢの衝撃パターンのデータを作成する処理のフローチャートである。
【図１２】サーバ型の障害検出システムにおいて、リアルタイムで衝撃ＤＢのデータを作成する処理のフローチャートである。
【図１３】本実施形態に従ったサーバ型障害検出システムであって、サーバが衝撃ＤＢを備える場合の衝撃ＤＢの作成処理のフローチャートである。
【図１４】衝撃データのフォーマットを説明する図である。
【図１５】衝撃パターンのパターンマッチング処理のフローチャートである。
【発明を実施するための形態】
【００１４】
本実施形態においては、以下のような構成を備える。
(1)-1予め携帯端末を様々な方向・高さから落下させたり、衝撃、振動を与え、加速度とその時間変化を衝撃パターンとしてデータベース化して保持する(衝撃ＤＢ)。
(1)-2 上記の衝撃ＤＢを携帯端末またはサーバに搭載し、端末の加速度を記録して衝撃ＤＢと比較することで、落下故障時の衝撃の原因を速やかに特定する。
(2) 複数の端末の衝撃検出情報をサーバに集約し、同一の故障原因の発生が複数見られた場合に、リアルタイムに全端末に改善指示を発することで、故障の予防を図る。
【００１５】
以上によって、携帯端末の故障時の衝撃の原因を速やかに特定する。
従来の衝撃分析は、障害発生装置の外観調査等により、衝撃原因の特定まで数時間を要していたが、本実施形態によれば、衝撃ＤＢのパターン比較により、リアルタイムで衝撃原因を特定することが可能となる。
【００１６】
また、従来では検出できなかった、小振動や小さな衝撃の蓄積による障害も、衝撃ＤＢに振動パターンを登録しておくことで、速やかな原因特定が可能となる。
また、複数の携帯端末の運用において、リアルタイムに故障の予防を図ることが可能となる。
【００１７】
従来は、同一傾向の障害の端末が複数台修理センタに返却された後、原因の分析を行い、数日を要して運用改善の指示を行っていたが、本実施形態では、リアルタイムのスタンドアローンまたはサーバ分析により、障害発生時にリアルタイムで警告を表示できる。
【００１８】
図１は、本実施形態に従った、スタンドアローン型携帯端末の機能ブロック構成図である。
本実施形態のスタンドアローン型携帯端末９では、衝撃ＤＢ１５を内蔵する。メモリ１２は、携帯端末９を動作させるＯＳ等が格納されており、ＣＰＵ１１がこれを実行することにより、携帯端末９を動作させる。操作部１３は、携帯端末９のユーザからの入力を受け付ける。操作部１３からの入力は、ＣＰＵ１１によって処理され、表示部１０に表示される。表示部１０は、商品の決済処理において発生する情報を表示する。携帯端末９には、加速度センサ１４が搭載され、検出した加速度とその時間変化を衝撃パターンとして、メモリ１２に格納する。データベース（衝撃ＤＢ）１５には、予め携帯端末９の設計・開発時に、テストとして、様々な衝撃や振動を与えたときの加速度とその時間変化が衝撃パターンとして予め格納されている。
【００１９】
ＣＰＵ１１は、メモリ１２に格納されている加速度センサ１４が検出した衝撃パターンが衝撃ＤＢ１５の衝撃パターンと一致するか否かを判断し、一致したものがあった場合には、衝撃ＤＢ１５に衝撃パターンに対応して格納される警告メッセージを読み出し、警告表示を表示部１０に表示させる。
【００２０】
以上は、スタンドアローン型携帯端末の構成であったが、携帯端末をネットワークを介してサーバに接続する形態の障害検出システムを構成することも可能である。
【００２１】
図２は、本実施形態に従った、サーバ接続型の障害検出システムのシステム構成図である。
店員はそれぞれ１つずつ携帯端末２０を保持する。携帯端末２０は、アクセスポイント２５を介して、ネットワーク２６に接続されたサーバ２１にアクセスする。この場合、衝撃ＤＢ１５は、携帯端末２０あるいはサーバ２１に設けられる。ここでは、衝撃ＤＢ１５は、サーバ２１に設けられるものとして説明する。携帯端末２０は、内蔵の加速度センサが検出した衝撃パターンをサーバ２１に送信し、サーバ２１において、検出された衝撃パターンと衝撃ＤＢに格納された衝撃パターンの照合が行なわれる。
【００２２】
サーバ２１は、例えば、モバイルＰＯＳシステムの場合、店舗内に配置されたり、モバイルＰＯＳシステムの管理センターなどに配置される。
【００２３】
図３は、サーバ接続型障害検出システムの機能ブロック構成図である。
図３において、図１と同じ構成要素には同じ参照符号を付し、それらの説明を省略する。
携帯端末２０は、衝撃ＤＢ１５を備えず、その代わりに、通信部２２を備える。通信部２２は、ネットワークを介して、サーバ２１にアクセスする。サーバ２１は、通信部２３を用いて、携帯端末２０と通信を行う。サーバ２１は、携帯端末２０から送られてくる、検出された衝撃パターンを受け取り、衝撃ＤＢ１５内の衝撃パターンと照合し、一致するものがあるか否かを検出する。サーバ２１は、オペレータによって監視されており、携帯端末２０から送られてきた衝撃パターンと、衝撃ＤＢ１５内の衝撃パターンとの一致が得られた場合には、オペレータにその旨の表示を行なう。
【００２４】
オペレータは、サーバ２１によって表示された内容から、衝撃パターンの一致を見た携帯端末２０に対し、警告を発するか否かを判断する。警告を発する場合には、警告メッセージを携帯端末２０に送り、表示部１０に警告表示を表示させる。
【００２５】
なお、図３においては、衝撃ＤＢ１５は、サーバ２１に設けられるとしたが、携帯端末２０にも受けても良い。そして、携帯端末２０が衝撃パターンの照合を行い、一致した場合には、衝撃パターンと共にその旨をサーバ２１に通知するようにしても良い。
【００２６】
図４は、衝撃ＤＢに格納されるデータの例を示す図である。
衝撃ＤＢには、衝撃パターンとその衝撃パターンが得られた際の落下・振動条件とを警告メッセージと対応付けたデータが格納される。落下・振動条件は、携帯端末にどのような加速度、振動が加えられたかを記述するものである。このような落下・振動条件において、加速度センサが検出した衝撃パターンが、対応付けられて格納される。衝撃パターンは、携帯端末を基準にした、ｘ、ｙ、ｚ軸方向の加速度とその時間変化である。そして、そのような衝撃パターンを受けた際に、ユーザに取り扱い上の注意を促すための警告メッセージが格納される。
【００２７】
例えば、Ｎｏ．１の衝撃パターンは、１．５ｍの高さから、ＬＣＤ画面を下にして落下した状態で得られたものであるので、「高所に持ち込むな」という警告メッセージを登録している。Ｎｏ．２の衝撃パターンは、１．２ｍの高さから、ＬＣＤ画面を下にして落下した状態で得られたものであるので、「ストラップを付けろ」という警告メッセージを登録している。１．５ｍからの落下は、高所に置かれている場合が想定でき、１．２ｍからの落下は、ユーザの手から落ちたことが想定できるからである。
【００２８】
また、Ｎｏ．３の衝撃パターンは、トラックに携帯端末を搭載し、砂利道を走った場合であって、携帯端末を横向きにおいた場合である。この場合には、携帯端末がクレードルに正しくは取り付けられていないために振動が起きている可能性があるので、「クレードル取り付けを確認」という警告メッセージが登録されている。Ｎｏ．４の衝撃パターンは、トラックに携帯端末を搭載し、砂利道を走った場合であって、携帯端末を縦向きに置いた場合である。この場合には、携帯端末をクレードルに取り付ける位置がおかしい可能性があるので、「クレードル位置がおかしい」という警告メッセージが登録されている。
【００２９】
そのほかの例として、電池ケース部を１．３Ｎで殴打した場合は、「丁寧に操作してください」という警告メッセージが登録されている。このような衝撃パターンが生じたのは携帯端末を何かにぶつけた可能性が高いからである。
【００３０】
以上のような警告メッセージは、衝撃パターンを登録する際に、作業者が落下・振動条件から想定される実際の携帯端末の状況を想定して、適切と思われるメッセージを登録するようにする。
【００３１】
図５は、携帯端末の外観図である。
携帯端末３０の本体は、表示画面３２、入力キー３３が表面に配置されており、裏面には、不図示であるが、カード読み取り器や、バーコード読み取り器などが配置されている。クレードル３１は、携帯端末３０を保持する筐体で、携帯端末３０を使用しない場合には、携帯端末３０をクレードル３１に取り付けて保管する。なお、クレードル３１には、携帯端末３０を保持する以外に、充電機能を持っても良い。
【００３２】
図６は、衝撃検出処理のフローチャートである。
衝撃検出を開始すると、ステップＳ１０において、現在の加速度値を収集する。ステップＳ１１において、加速度値をメモリに書き込む。ステップＳ１２において、過去Ｘ回（Ｘは設計者が適宜決定するものとする）の加速度ベクタ（ｘ成分、ｙ成分、ｚ成分の組からなる加速度値を加速度ベクタと呼んでいる）を含む衝撃パターンと衝撃ＤＢの衝撃パターンをパターンマッチングする。ステップＳ１３において、一致パターンがあるか否かを判断する。ステップＳ１３の判断がＮｏの場合には、ステップＳ１０に戻り、ステップＳ１３の判断がＹｅｓの場合には、ステップＳ１４に進む。ステップＳ１４においては、衝撃ＤＢに格納されている一致した衝撃パターンの警告メッセージを携帯端末に表示して処理を終了する。
【００３３】
図７は、本実施形態に従った、サーバ型障害検出システムであって、サーバから複数の携帯端末に同時に警告メッセージを送出する構成のシステム構成図である。
この構成例では、携帯端末２０は、アクセスポイント２５にアクセスし、ネットワーク２６を介してサーバ２１に、衝撃パターンを送信する。サーバ２１は、受信した衝撃パターンと内蔵の衝撃ＤＢの衝撃パターンとを比較し、一致するかを判断する。そして、一致した場合には、どの携帯端末からの衝撃パターンが、所定時間内に、衝撃ＤＢのどの衝撃パターンと何回一致したかをメモリに格納する。そして、例えば、異なる携帯端末からの衝撃パターンが、衝撃ＤＢの同じ衝撃パターンと所定回一致した場合には、そのような状況がその他の携帯端末にも生じうると判断して、全携帯端末に警告メッセージを表示させる。このようにすることにより、多くの携帯端末で発生しがちな障害を発生する状況をいち早く検知し、全携帯端末に警告を送り、障害発生を未然に防ぐことが出来る。
【００３４】
図８は、図７の構成例のサーバ型障害検出システムの機能ブロック構成図である。
図８において、図３と同じ構成要素には同じ参照符号を付し、それらの説明を省略する。
【００３５】
図８においては、サーバ２１にメモリ４０（サーバメモリ）が設けられている。メモリ４０には、携帯端末２０から送られてくる衝撃パターンと、衝撃ＤＢ１５の衝撃パターンとのパターンマッチング結果が格納される。パターンマッチングの結果において、異なる携帯端末からの衝撃パターンが、所定時間内に所定回、衝撃ＤＢ１５の衝撃パターンと一致した場合には、全携帯端末において、同様な状況が発生し、同様な障害が発生する可能性が高いと判断する。そして、そのように判断された場合には、全携帯端末に警告メッセージを表示させる。
【００３６】
図９は、サーバメモリに格納されるデータの例を示した図である。
サーバメモリのデータには、衝撃パターンの発生時刻と、衝撃パターンを送信してきた携帯端末の識別子と、一致した衝撃パターンの識別子と、一致回数と、全携帯端末への警告を行なったか否かの情報が対応付けられて格納される。
【００３７】
図９において、端末Ｄからの衝撃パターンは、衝撃Ｎｏ．１６５と一致している。衝撃Ｎｏ．１６５は、端末Ｃからの衝撃パターンと同じであり、端末Ｄから衝撃パターンを受け取ったことにより、異なる端末で同じ衝撃パターンに一致した回数が２回となっている。この場合、異なる端末で同じ衝撃パターンが発生したことから、他の端末でも同様の衝撃パターンが発生する可能性が高いと判断できる。したがって、端末Ｄから衝撃パターンを受け取ったときに、全端末へ警告メッセージを送信し、全端末の表示画面に警告表示を行なわせる。
【００３８】
なお、ここでは、一致を検出する際の所定時間内の所定回数として、２回を例示したが、この回数は、設計者により適宜設定されるべきものである。
以上の処理により、複数の携帯端末で同様な障害が発生する状況を避けるように、ユーザに予め警告をすることが出来るので、複数の携帯端末が同じ原因により故障するということを防止することが出来る。
【００３９】
図１０は、図７の構成例におけるサーバの動作のフローチャートである。
ステップＳ２０において、携帯端末から衝撃パターンのデータを受信する。このデータを、ステップＳ２１において、サーバメモリに書き込む。ステップＳ２２において、過去の全てまたは指定時間内の衝撃パターンに同一パターンがあるか否かを検索する。ここで、過去の指定時間内の衝撃パターンについてのみ同一パターンの検索を行なうのは、同様の衝撃パターンが発生しても問題にならないよう既に運用改善される場合があるからである。指定時間としては、一週間とか、一ヶ月とか、店舗の売り上げの回転率などを考えて、オペレータが設定するようにする。
【００４０】
ステップＳ２３において、ステップＳ２２の検索において同一パターンが見つかったか否かを判断する。ステップＳ２３の判断がＮｏの場合には、ステップＳ２０に戻る。ステップＳ２３の判断がＹｅｓの場合には、ステップＳ２４において、全端末へ警告メッセージを送信し、表示させて、処理を終了する。
【００４１】
図１１は、事前に衝撃ＤＢの衝撃パターンのデータを作成する処理のフローチャートである。
衝撃パターンの作成を開始すると、ステップＳ３０において、現在の時刻、及び加速度を最終記録として保存しておく。ステップＳ３１において、衝撃が発生すると、加速度の測定期間内であるか否かを判断する。ステップＳ３１の判断がＹｅｓの場合には、ステップＳ３２において、ステップＳ３０で記録された最終記録の加速度と現在の加速度の差を比較し、ステップＳ３３において、当該差が閾値を超えているか否かを判断する。この閾値は、測定の誤差や、問題とならない加速度の変化を取り除くためのものである。閾値の値は、設計者が予め決定しておく。ステップＳ３３の判断がＮｏの場合には、ステップＳ３１に戻る。ステップＳ３３の判断がＹｅｓの場合には、ステップＳ３４において、最終記録と現在の時間差、加速度を１組としてメモリに追加する。ステップＳ３５において、現在の時刻、加速度を最終記録として保存し、ステップＳ３１に戻る。
【００４２】
ステップＳ３１の判断がＮｏの場合には、ステップＳ３６において、測定開始から完了までに追加した全組のデータを衝撃パターンとして衝撃ＤＢに記録して、処理を終了する。
【００４３】
以上の処理は、１つの衝撃パターンの作成処理なので、これを、様々な落下・振動条件について繰り返すことにより、衝撃ＤＢの衝撃パターンを蓄積する。
上記処理は、衝撃ＤＢの衝撃パターンのデータを予め蓄積しておくためのものであったが、リアルタイムに順次衝撃パターンを蓄積することも可能である。
【００４４】
図１２は、サーバ型の障害検出システムにおいて、リアルタイムで衝撃ＤＢのデータを作成する処理のフローチャートである。
図１２の処理においては、特に、携帯端末がローカルに衝撃ＤＢを持っていて、ローカルな衝撃ＤＢに衝撃パターンをリアルタイムに格納する場合を示す。
【００４５】
ステップＳ４０において、現在の時刻、加速度を最終記録として保存しておく。ステップＳ４１において、衝撃が発生すると、（現在の時刻）−（最終記録の時刻）を演算して、閾値と比較する。ステップＳ４１において、演算値が閾値未満である場合には、ステップＳ４２において、最終記録の加速度と現在の加速度の差を比較し、ステップＳ４３において、差が閾値を超えているか否かを判断する。
【００４６】
ステップＳ４３の判断がＮｏの場合には、ステップＳ４１に戻る。ステップＳ４３の判断がＹｅｓの場合には、ステップＳ４４において、最終記録と現在の時間差、加速度を１組として、衝撃ＤＢに追加する。ステップＳ４３の閾値は、図１１のステップＳ３３と同様の意味を持つものである。ステップＳ４５においては、現在の時刻、加速度を最終記録として保存し、ステップＳ４１に戻る。
【００４７】
ステップＳ４１の判断で、演算値が閾値以上であると判断された場合には、ステップＳ４６に進む。これは、衝撃パターンの時間長の閾値以上であると判断するものである。すなわち、ステップＳ４１の閾値は、衝撃パターンが、どのくらいの時間加速度を記録するかを設定するものである。この閾値は、設計者が適宜設定する。
【００４８】
ステップＳ４６においては、測定開始から完了までに追加した全組のデータを衝撃パターンとして、衝撃ＤＢを検索する。ステップＳ４７において、類似パターンが既にあるか否かを判断する。ステップＳ４７の判断がＮｏの場合には、ステップＳ４８において、衝撃パターンを衝撃ＤＢに記録し、ステップＳ４９に進む。ステップＳ４７の判断がＹｅｓの場合には、そのままステップＳ４９に進む。ステップＳ４９においては、衝撃が発生したことをサーバに通知するために、衝撃パターンをサーバへ通知する。
【００４９】
図１３は、本実施形態に従ったサーバ型障害検出システムであって、サーバが衝撃ＤＢを備える場合の衝撃ＤＢの作成処理のフローチャートである。
図１３の場合は、サーバに衝撃ＤＢが設けられている場合である。
【００５０】
ステップＳ５５において、現在の時刻、加速度を携帯端末から受信し、最終記録として保存しておく。ステップＳ５６において、衝撃が発生すると、現在の時刻、加速度を携帯端末から受信する。ステップＳ５７において、（携帯端末の現在時刻）−（携帯端末の最終記録の時刻）を演算する。ステップＳ５７の演算値が閾値未満の場合、ステップＳ５８に進む。ステップＳ５８では、最終記録の加速度と現在の加速度の差を比較し、ステップＳ５９において、差が閾値を超えているか否かを判断する。ステップＳ５９の判断がＮｏの場合には、ステップＳ５６に戻り、ステップＳ５９の判断がＹｅｓの場合には、ステップＳ６０に進む。ステップＳ５９の閾値は、図１２のステップＳ４３と同様のものである。
【００５１】
ステップＳ６０においては、最終記録と現在の時間差、加速度を１組としてメモリに追加する。ステップＳ６１において、現在の時刻、加速度を最終記録として保存し、ステップＳ５６に戻る。ステップＳ５７の判断で、演算値が、衝撃パターンの時間長の閾値以上であると判断された場合には、ステップＳ６２に進む。ここでの閾値は図１２のステップＳ４１と同様である。
【００５２】
ステップＳ６２においては、測定開始から完了までに追加した全組のデータを衝撃パターンとしてメモリ内のデータを検索する。ステップＳ６３において、類似パターンが既にあるか否かを判断する。ステップＳ６３の判断がＹｅｓの場合には、ステップＳ６４において、衝撃パターンをサーバに送り、衝撃ＤＢに記録して処理を終了する。ステップＳ６３の判断がＮｏの場合には、そのまま処理を終了する。
【００５３】
図１４は、衝撃データのフォーマットを説明する図である。
図１４（ａ）は、加速度データのフォーマットである。加速度のｘ、ｙ、ｚ成分のいずれかが閾値ａを超えて変化した場合に、前回の送信したときからの経過時間と、ｘ方向加速度値、ｙ方向加速度値、ｚ方向加速度値を１レコードのデータとして生成する。
【００５４】
図１４（ｂ）は、例として、装置が机から落下し、数回バウンドした場合のデータ例を示している。
装置が落下したときは、前回の衝撃時からかなり時間が経っているので、前回送信からの時間は例として「９９９９９」としている。このとき、落下によって加速度値が０となる方向が発生している。その後、落下の衝撃により、前回送信からの時間が「４５０」のとき、ｘ方向加速度値が大きな値を示している。その後、前回送信からの時間が「３」のとき、空中に装置が跳ね上がり、ｘ方向加速度値が「０」となっている。前回送信からの時間が「９１」のとき、再び衝撃が発生し、ｙ方向加速度値が大きな値を示している。前回送信からの時間が「２」のとき、再び空中に装置が跳ね上がり、ｙ方向加速度値が「０」となり、前回送信からの時間が「２０」のとき、装置が床に付いて、ｘ方向加速度値が大きな値となっている。
【００５５】
ここで、前回送信からの時間の単位は、落下の跳ね上がり状態等を検出するためには、ミリ秒単位が好ましい。
サーバ型障害検出システムの場合、携帯端末がサーバ接続時には、図１４（ａ）のようなフォーマットのデータがリアルタイムにサーバに通知される。
【００５６】
図１５は、衝撃パターンのパターンマッチング処理のフローチャートである。
図１５において、発生した衝撃パターンが衝撃ＤＢのどのパターンと一致するかは、パターンマッチングにより、最も類似度の高いパターンを抽出し、そのパターンの類似度が閾値を超えているかどうかで判定する。
【００５７】
パターンマッチングのアルゴリズムは、簡易な方法として、時間／加速度値の差の絶対値の合計（後述の類似度を負にしたもの）が最小となるパターンを選ぶ方法や、ＤＰ(Dynamic Programming)マッチング等の伸縮マッチング手法を用いることが出来る。
【００５８】
ステップＳ７０において、現在の最大類似度を０に設定する。ステップＳ７１において、衝撃ＤＢに残りパターンがあるか否かを判断する。ステップＳ７１の判断がＹｅｓの場合には、ステップＳ７２において、衝撃ＤＢの次のパターンを読み込む。ステップＳ７３において、発生パターンと衝撃ＤＢから読み出した衝撃パターンの類似度を計算する。ステップＳ７４において、類似度が最大か否かを判断する。ステップＳ７４の判断がＮｏの場合には、ステップＳ７１に戻る。ステップＳ７４の判断がＹｅｓの場合には、ステップＳ７５において、最大類似度の値を現在の類似度で更新し、ステップＳ７１に戻る。
【００５９】
ステップＳ７１の判断がＮｏの場合には、ステップＳ７６において、最大類似度が閾値以上か否かを判断する。ステップＳ７６の判断がＹｅｓの場合には、ステップＳ７７において、類似衝撃パターンを検出したとし、ステップＳ７６の判断がＮｏの場合には、ステップＳ７８において、類似衝撃パターンがないと判断して、処理を終了する。
【符号の説明】
【００６０】
９、２０、３０ 携帯端末
１０、３２ 表示部
１１ ＣＰＵ
１２、４０ メモリ
１３ 操作部
１４ 加速度センサ
１５ 衝撃データベース
２１ サーバ
２２、２３ 通信部
２５ アクセスポイント
２６ ネットワーク
３１ クレードル
３３ 入力キー
【技術分野】
【０００１】
本発明は、携帯端末及び携帯端末の障害検出システムに関する。
【背景技術】
【０００２】
今日、商品を販売する店舗においては、ＰＯＳ(Point Of Sale)システムが広く使われているが、百貨店や専門店などにおいては、購入する商品が１点から数点と少量であることが多い。このような場合、商品をＰＯＳカウンターに持って行き決済を行なうより、商品の販売場所において決済を行なうほうが、移動時間やＰＯＳカウンターでの待ち時間が短縮され顧客利便性が向上する。そのためには、決済を行なうためのツールを店員が持ち運びできるようにする必要がある。このような用途のために、モバイルＰＯＳというシステムが存在する。店員は、カードの読み取り器や、バーコードの読み取り器等、決済に必要となるツールが搭載された携帯端末を持ち、商品の販売場所において、この携帯端末を用いて決済を行なう。
【０００３】
このようなモバイルＰＯＳシステムを使用する場合、１つの店舗に多くの同様な携帯端末を配備し、携帯端末が店舗に配置されたサーバと通信することによって決済処理を行う。このような携帯端末は、店内で多くの店員が商品の販売をしながら扱うので、携帯端末を落としたり、壁にぶつけたりしがちである。携帯端末に激しい衝撃が加わると故障の原因になるが、不注意な携帯端末の扱いを複数の店員が行なっていると、類似障害が発生する。このような障害の発生を防ぐための手段が望まれる。
【０００４】
携帯端末が落下故障した場合には、携帯端末を修理に出すのであるが、修理の際に、モールドカバーや基板の破損状態から落下方向、衝撃力分析を行なったり、板金部材の歪み量からの落下方向、衝撃力分析を行なうなどの障害分析が行なわれる。
【０００５】
しかし、このような障害分析は困難な場合が多いので、携帯端末に加速度センサを設け、障害発生時の状況を記録することが考えられる。
従来の携帯機器における加速度センサ技術としては、既に様々なものが知られている。例えば、ハードディスクドライブ（ＨＤＤ）などにおいては、落下（無重力）を検出し、ＨＤＤの磁気ヘッドの固定エリア退避を行なうことが知られている。また、他の加速度センサの用途としては、耐タンパ性を有する高セキュリティ装置において、衝撃あるいは高加速度を検出し、装置を破壊しようとした試みを検出するものがある。更に、カメラ手振れ防止のために、加速度センサで振動を検出したり、ゲームコントローラにおいて、移動、方向検出、端末上下検出などを行なうものも知られている。
【０００６】
その他、加速度センサを利用した故障分析の従来技術には、衝撃時の加速度と時間変化を用いて衝撃度を検出するものや、端末の衝撃時の加速度を記録し、落下故障を特定するものがある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−１６２７０３号公報
【特許文献２】特開２００８−２３２６３１号公報
【特許文献３】特開２００９−０５３９４９号公報
【特許文献４】特開２００５−２４１３３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、従来では、下記の問題が発生していた。
・故障返却された装置を調べても、落下衝撃の位置、方向、頻度等の詳細情報が記録されていないため、落下した根本原因の調査において破損状態の外観確認に頼ることとなり、調査に長時間を要している。
・小さな衝撃の蓄積による疲労は、外観に痕跡が残りにくく、障害原因が断定できないことがあった。
・大規模運用において、複数端末で問題が発生しても、リアルタイムの改善対策ができなかった。
【０００９】
本発明の課題は、携帯端末の故障時の衝撃の原因を速やかに特定することの可能な携帯端末及びその障害検出システムを提供することである。
【課題を解決するための手段】
【００１０】
本発明の一側面における携帯端末は、メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサと、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該表示部に表示させる制御部とを備える。
【００１１】
本発明の一側面における障害検出システムは、携帯端末と通信することによって障害が発生する状況を検出する障害検出システムであって、メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサとを備える携帯端末と、所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の該表示部に表示させる、該携帯端末とネットワークにより接続されたサーバとを備える。
【発明の効果】
【００１２】
本発明によれば、携帯端末の故障時の衝撃の原因を速やかに特定することの可能な携帯端末及びその障害をリアルタイムに検出して携帯端末に警告表示するシステムを提供することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態に従った、スタンドアローン型携帯端末の機能ブロック構成図である。
【図２】本実施形態に従った、サーバ接続型の障害検出システムのシステム構成図である。
【図３】サーバ接続型障害検出システムの機能ブロック構成図である。
【図４】衝撃ＤＢに格納されるデータの例を示す図である。
【図５】携帯端末の外観図である。
【図６】衝撃検出処理のフローチャートである。
【図７】本実施形態に従った、サーバ型障害検出システムであって、サーバから複数の携帯端末に同時に警告メッセージを送出する構成のシステム構成図である。
【図８】図７の構成例のサーバ型障害検出システムの機能ブロック構成図である。
【図９】サーバメモリに格納されるデータの例を示した図である。
【図１０】図７の構成例におけるサーバの動作のフローチャートである。
【図１１】事前に衝撃ＤＢの衝撃パターンのデータを作成する処理のフローチャートである。
【図１２】サーバ型の障害検出システムにおいて、リアルタイムで衝撃ＤＢのデータを作成する処理のフローチャートである。
【図１３】本実施形態に従ったサーバ型障害検出システムであって、サーバが衝撃ＤＢを備える場合の衝撃ＤＢの作成処理のフローチャートである。
【図１４】衝撃データのフォーマットを説明する図である。
【図１５】衝撃パターンのパターンマッチング処理のフローチャートである。
【発明を実施するための形態】
【００１４】
本実施形態においては、以下のような構成を備える。
(1)-1予め携帯端末を様々な方向・高さから落下させたり、衝撃、振動を与え、加速度とその時間変化を衝撃パターンとしてデータベース化して保持する(衝撃ＤＢ)。
(1)-2 上記の衝撃ＤＢを携帯端末またはサーバに搭載し、端末の加速度を記録して衝撃ＤＢと比較することで、落下故障時の衝撃の原因を速やかに特定する。
(2) 複数の端末の衝撃検出情報をサーバに集約し、同一の故障原因の発生が複数見られた場合に、リアルタイムに全端末に改善指示を発することで、故障の予防を図る。
【００１５】
以上によって、携帯端末の故障時の衝撃の原因を速やかに特定する。
従来の衝撃分析は、障害発生装置の外観調査等により、衝撃原因の特定まで数時間を要していたが、本実施形態によれば、衝撃ＤＢのパターン比較により、リアルタイムで衝撃原因を特定することが可能となる。
【００１６】
また、従来では検出できなかった、小振動や小さな衝撃の蓄積による障害も、衝撃ＤＢに振動パターンを登録しておくことで、速やかな原因特定が可能となる。
また、複数の携帯端末の運用において、リアルタイムに故障の予防を図ることが可能となる。
【００１７】
従来は、同一傾向の障害の端末が複数台修理センタに返却された後、原因の分析を行い、数日を要して運用改善の指示を行っていたが、本実施形態では、リアルタイムのスタンドアローンまたはサーバ分析により、障害発生時にリアルタイムで警告を表示できる。
【００１８】
図１は、本実施形態に従った、スタンドアローン型携帯端末の機能ブロック構成図である。
本実施形態のスタンドアローン型携帯端末９では、衝撃ＤＢ１５を内蔵する。メモリ１２は、携帯端末９を動作させるＯＳ等が格納されており、ＣＰＵ１１がこれを実行することにより、携帯端末９を動作させる。操作部１３は、携帯端末９のユーザからの入力を受け付ける。操作部１３からの入力は、ＣＰＵ１１によって処理され、表示部１０に表示される。表示部１０は、商品の決済処理において発生する情報を表示する。携帯端末９には、加速度センサ１４が搭載され、検出した加速度とその時間変化を衝撃パターンとして、メモリ１２に格納する。データベース（衝撃ＤＢ）１５には、予め携帯端末９の設計・開発時に、テストとして、様々な衝撃や振動を与えたときの加速度とその時間変化が衝撃パターンとして予め格納されている。
【００１９】
ＣＰＵ１１は、メモリ１２に格納されている加速度センサ１４が検出した衝撃パターンが衝撃ＤＢ１５の衝撃パターンと一致するか否かを判断し、一致したものがあった場合には、衝撃ＤＢ１５に衝撃パターンに対応して格納される警告メッセージを読み出し、警告表示を表示部１０に表示させる。
【００２０】
以上は、スタンドアローン型携帯端末の構成であったが、携帯端末をネットワークを介してサーバに接続する形態の障害検出システムを構成することも可能である。
【００２１】
図２は、本実施形態に従った、サーバ接続型の障害検出システムのシステム構成図である。
店員はそれぞれ１つずつ携帯端末２０を保持する。携帯端末２０は、アクセスポイント２５を介して、ネットワーク２６に接続されたサーバ２１にアクセスする。この場合、衝撃ＤＢ１５は、携帯端末２０あるいはサーバ２１に設けられる。ここでは、衝撃ＤＢ１５は、サーバ２１に設けられるものとして説明する。携帯端末２０は、内蔵の加速度センサが検出した衝撃パターンをサーバ２１に送信し、サーバ２１において、検出された衝撃パターンと衝撃ＤＢに格納された衝撃パターンの照合が行なわれる。
【００２２】
サーバ２１は、例えば、モバイルＰＯＳシステムの場合、店舗内に配置されたり、モバイルＰＯＳシステムの管理センターなどに配置される。
【００２３】
図３は、サーバ接続型障害検出システムの機能ブロック構成図である。
図３において、図１と同じ構成要素には同じ参照符号を付し、それらの説明を省略する。
携帯端末２０は、衝撃ＤＢ１５を備えず、その代わりに、通信部２２を備える。通信部２２は、ネットワークを介して、サーバ２１にアクセスする。サーバ２１は、通信部２３を用いて、携帯端末２０と通信を行う。サーバ２１は、携帯端末２０から送られてくる、検出された衝撃パターンを受け取り、衝撃ＤＢ１５内の衝撃パターンと照合し、一致するものがあるか否かを検出する。サーバ２１は、オペレータによって監視されており、携帯端末２０から送られてきた衝撃パターンと、衝撃ＤＢ１５内の衝撃パターンとの一致が得られた場合には、オペレータにその旨の表示を行なう。
【００２４】
オペレータは、サーバ２１によって表示された内容から、衝撃パターンの一致を見た携帯端末２０に対し、警告を発するか否かを判断する。警告を発する場合には、警告メッセージを携帯端末２０に送り、表示部１０に警告表示を表示させる。
【００２５】
なお、図３においては、衝撃ＤＢ１５は、サーバ２１に設けられるとしたが、携帯端末２０にも受けても良い。そして、携帯端末２０が衝撃パターンの照合を行い、一致した場合には、衝撃パターンと共にその旨をサーバ２１に通知するようにしても良い。
【００２６】
図４は、衝撃ＤＢに格納されるデータの例を示す図である。
衝撃ＤＢには、衝撃パターンとその衝撃パターンが得られた際の落下・振動条件とを警告メッセージと対応付けたデータが格納される。落下・振動条件は、携帯端末にどのような加速度、振動が加えられたかを記述するものである。このような落下・振動条件において、加速度センサが検出した衝撃パターンが、対応付けられて格納される。衝撃パターンは、携帯端末を基準にした、ｘ、ｙ、ｚ軸方向の加速度とその時間変化である。そして、そのような衝撃パターンを受けた際に、ユーザに取り扱い上の注意を促すための警告メッセージが格納される。
【００２７】
例えば、Ｎｏ．１の衝撃パターンは、１．５ｍの高さから、ＬＣＤ画面を下にして落下した状態で得られたものであるので、「高所に持ち込むな」という警告メッセージを登録している。Ｎｏ．２の衝撃パターンは、１．２ｍの高さから、ＬＣＤ画面を下にして落下した状態で得られたものであるので、「ストラップを付けろ」という警告メッセージを登録している。１．５ｍからの落下は、高所に置かれている場合が想定でき、１．２ｍからの落下は、ユーザの手から落ちたことが想定できるからである。
【００２８】
また、Ｎｏ．３の衝撃パターンは、トラックに携帯端末を搭載し、砂利道を走った場合であって、携帯端末を横向きにおいた場合である。この場合には、携帯端末がクレードルに正しくは取り付けられていないために振動が起きている可能性があるので、「クレードル取り付けを確認」という警告メッセージが登録されている。Ｎｏ．４の衝撃パターンは、トラックに携帯端末を搭載し、砂利道を走った場合であって、携帯端末を縦向きに置いた場合である。この場合には、携帯端末をクレードルに取り付ける位置がおかしい可能性があるので、「クレードル位置がおかしい」という警告メッセージが登録されている。
【００２９】
そのほかの例として、電池ケース部を１．３Ｎで殴打した場合は、「丁寧に操作してください」という警告メッセージが登録されている。このような衝撃パターンが生じたのは携帯端末を何かにぶつけた可能性が高いからである。
【００３０】
以上のような警告メッセージは、衝撃パターンを登録する際に、作業者が落下・振動条件から想定される実際の携帯端末の状況を想定して、適切と思われるメッセージを登録するようにする。
【００３１】
図５は、携帯端末の外観図である。
携帯端末３０の本体は、表示画面３２、入力キー３３が表面に配置されており、裏面には、不図示であるが、カード読み取り器や、バーコード読み取り器などが配置されている。クレードル３１は、携帯端末３０を保持する筐体で、携帯端末３０を使用しない場合には、携帯端末３０をクレードル３１に取り付けて保管する。なお、クレードル３１には、携帯端末３０を保持する以外に、充電機能を持っても良い。
【００３２】
図６は、衝撃検出処理のフローチャートである。
衝撃検出を開始すると、ステップＳ１０において、現在の加速度値を収集する。ステップＳ１１において、加速度値をメモリに書き込む。ステップＳ１２において、過去Ｘ回（Ｘは設計者が適宜決定するものとする）の加速度ベクタ（ｘ成分、ｙ成分、ｚ成分の組からなる加速度値を加速度ベクタと呼んでいる）を含む衝撃パターンと衝撃ＤＢの衝撃パターンをパターンマッチングする。ステップＳ１３において、一致パターンがあるか否かを判断する。ステップＳ１３の判断がＮｏの場合には、ステップＳ１０に戻り、ステップＳ１３の判断がＹｅｓの場合には、ステップＳ１４に進む。ステップＳ１４においては、衝撃ＤＢに格納されている一致した衝撃パターンの警告メッセージを携帯端末に表示して処理を終了する。
【００３３】
図７は、本実施形態に従った、サーバ型障害検出システムであって、サーバから複数の携帯端末に同時に警告メッセージを送出する構成のシステム構成図である。
この構成例では、携帯端末２０は、アクセスポイント２５にアクセスし、ネットワーク２６を介してサーバ２１に、衝撃パターンを送信する。サーバ２１は、受信した衝撃パターンと内蔵の衝撃ＤＢの衝撃パターンとを比較し、一致するかを判断する。そして、一致した場合には、どの携帯端末からの衝撃パターンが、所定時間内に、衝撃ＤＢのどの衝撃パターンと何回一致したかをメモリに格納する。そして、例えば、異なる携帯端末からの衝撃パターンが、衝撃ＤＢの同じ衝撃パターンと所定回一致した場合には、そのような状況がその他の携帯端末にも生じうると判断して、全携帯端末に警告メッセージを表示させる。このようにすることにより、多くの携帯端末で発生しがちな障害を発生する状況をいち早く検知し、全携帯端末に警告を送り、障害発生を未然に防ぐことが出来る。
【００３４】
図８は、図７の構成例のサーバ型障害検出システムの機能ブロック構成図である。
図８において、図３と同じ構成要素には同じ参照符号を付し、それらの説明を省略する。
【００３５】
図８においては、サーバ２１にメモリ４０（サーバメモリ）が設けられている。メモリ４０には、携帯端末２０から送られてくる衝撃パターンと、衝撃ＤＢ１５の衝撃パターンとのパターンマッチング結果が格納される。パターンマッチングの結果において、異なる携帯端末からの衝撃パターンが、所定時間内に所定回、衝撃ＤＢ１５の衝撃パターンと一致した場合には、全携帯端末において、同様な状況が発生し、同様な障害が発生する可能性が高いと判断する。そして、そのように判断された場合には、全携帯端末に警告メッセージを表示させる。
【００３６】
図９は、サーバメモリに格納されるデータの例を示した図である。
サーバメモリのデータには、衝撃パターンの発生時刻と、衝撃パターンを送信してきた携帯端末の識別子と、一致した衝撃パターンの識別子と、一致回数と、全携帯端末への警告を行なったか否かの情報が対応付けられて格納される。
【００３７】
図９において、端末Ｄからの衝撃パターンは、衝撃Ｎｏ．１６５と一致している。衝撃Ｎｏ．１６５は、端末Ｃからの衝撃パターンと同じであり、端末Ｄから衝撃パターンを受け取ったことにより、異なる端末で同じ衝撃パターンに一致した回数が２回となっている。この場合、異なる端末で同じ衝撃パターンが発生したことから、他の端末でも同様の衝撃パターンが発生する可能性が高いと判断できる。したがって、端末Ｄから衝撃パターンを受け取ったときに、全端末へ警告メッセージを送信し、全端末の表示画面に警告表示を行なわせる。
【００３８】
なお、ここでは、一致を検出する際の所定時間内の所定回数として、２回を例示したが、この回数は、設計者により適宜設定されるべきものである。
以上の処理により、複数の携帯端末で同様な障害が発生する状況を避けるように、ユーザに予め警告をすることが出来るので、複数の携帯端末が同じ原因により故障するということを防止することが出来る。
【００３９】
図１０は、図７の構成例におけるサーバの動作のフローチャートである。
ステップＳ２０において、携帯端末から衝撃パターンのデータを受信する。このデータを、ステップＳ２１において、サーバメモリに書き込む。ステップＳ２２において、過去の全てまたは指定時間内の衝撃パターンに同一パターンがあるか否かを検索する。ここで、過去の指定時間内の衝撃パターンについてのみ同一パターンの検索を行なうのは、同様の衝撃パターンが発生しても問題にならないよう既に運用改善される場合があるからである。指定時間としては、一週間とか、一ヶ月とか、店舗の売り上げの回転率などを考えて、オペレータが設定するようにする。
【００４０】
ステップＳ２３において、ステップＳ２２の検索において同一パターンが見つかったか否かを判断する。ステップＳ２３の判断がＮｏの場合には、ステップＳ２０に戻る。ステップＳ２３の判断がＹｅｓの場合には、ステップＳ２４において、全端末へ警告メッセージを送信し、表示させて、処理を終了する。
【００４１】
図１１は、事前に衝撃ＤＢの衝撃パターンのデータを作成する処理のフローチャートである。
衝撃パターンの作成を開始すると、ステップＳ３０において、現在の時刻、及び加速度を最終記録として保存しておく。ステップＳ３１において、衝撃が発生すると、加速度の測定期間内であるか否かを判断する。ステップＳ３１の判断がＹｅｓの場合には、ステップＳ３２において、ステップＳ３０で記録された最終記録の加速度と現在の加速度の差を比較し、ステップＳ３３において、当該差が閾値を超えているか否かを判断する。この閾値は、測定の誤差や、問題とならない加速度の変化を取り除くためのものである。閾値の値は、設計者が予め決定しておく。ステップＳ３３の判断がＮｏの場合には、ステップＳ３１に戻る。ステップＳ３３の判断がＹｅｓの場合には、ステップＳ３４において、最終記録と現在の時間差、加速度を１組としてメモリに追加する。ステップＳ３５において、現在の時刻、加速度を最終記録として保存し、ステップＳ３１に戻る。
【００４２】
ステップＳ３１の判断がＮｏの場合には、ステップＳ３６において、測定開始から完了までに追加した全組のデータを衝撃パターンとして衝撃ＤＢに記録して、処理を終了する。
【００４３】
以上の処理は、１つの衝撃パターンの作成処理なので、これを、様々な落下・振動条件について繰り返すことにより、衝撃ＤＢの衝撃パターンを蓄積する。
上記処理は、衝撃ＤＢの衝撃パターンのデータを予め蓄積しておくためのものであったが、リアルタイムに順次衝撃パターンを蓄積することも可能である。
【００４４】
図１２は、サーバ型の障害検出システムにおいて、リアルタイムで衝撃ＤＢのデータを作成する処理のフローチャートである。
図１２の処理においては、特に、携帯端末がローカルに衝撃ＤＢを持っていて、ローカルな衝撃ＤＢに衝撃パターンをリアルタイムに格納する場合を示す。
【００４５】
ステップＳ４０において、現在の時刻、加速度を最終記録として保存しておく。ステップＳ４１において、衝撃が発生すると、（現在の時刻）−（最終記録の時刻）を演算して、閾値と比較する。ステップＳ４１において、演算値が閾値未満である場合には、ステップＳ４２において、最終記録の加速度と現在の加速度の差を比較し、ステップＳ４３において、差が閾値を超えているか否かを判断する。
【００４６】
ステップＳ４３の判断がＮｏの場合には、ステップＳ４１に戻る。ステップＳ４３の判断がＹｅｓの場合には、ステップＳ４４において、最終記録と現在の時間差、加速度を１組として、衝撃ＤＢに追加する。ステップＳ４３の閾値は、図１１のステップＳ３３と同様の意味を持つものである。ステップＳ４５においては、現在の時刻、加速度を最終記録として保存し、ステップＳ４１に戻る。
【００４７】
ステップＳ４１の判断で、演算値が閾値以上であると判断された場合には、ステップＳ４６に進む。これは、衝撃パターンの時間長の閾値以上であると判断するものである。すなわち、ステップＳ４１の閾値は、衝撃パターンが、どのくらいの時間加速度を記録するかを設定するものである。この閾値は、設計者が適宜設定する。
【００４８】
ステップＳ４６においては、測定開始から完了までに追加した全組のデータを衝撃パターンとして、衝撃ＤＢを検索する。ステップＳ４７において、類似パターンが既にあるか否かを判断する。ステップＳ４７の判断がＮｏの場合には、ステップＳ４８において、衝撃パターンを衝撃ＤＢに記録し、ステップＳ４９に進む。ステップＳ４７の判断がＹｅｓの場合には、そのままステップＳ４９に進む。ステップＳ４９においては、衝撃が発生したことをサーバに通知するために、衝撃パターンをサーバへ通知する。
【００４９】
図１３は、本実施形態に従ったサーバ型障害検出システムであって、サーバが衝撃ＤＢを備える場合の衝撃ＤＢの作成処理のフローチャートである。
図１３の場合は、サーバに衝撃ＤＢが設けられている場合である。
【００５０】
ステップＳ５５において、現在の時刻、加速度を携帯端末から受信し、最終記録として保存しておく。ステップＳ５６において、衝撃が発生すると、現在の時刻、加速度を携帯端末から受信する。ステップＳ５７において、（携帯端末の現在時刻）−（携帯端末の最終記録の時刻）を演算する。ステップＳ５７の演算値が閾値未満の場合、ステップＳ５８に進む。ステップＳ５８では、最終記録の加速度と現在の加速度の差を比較し、ステップＳ５９において、差が閾値を超えているか否かを判断する。ステップＳ５９の判断がＮｏの場合には、ステップＳ５６に戻り、ステップＳ５９の判断がＹｅｓの場合には、ステップＳ６０に進む。ステップＳ５９の閾値は、図１２のステップＳ４３と同様のものである。
【００５１】
ステップＳ６０においては、最終記録と現在の時間差、加速度を１組としてメモリに追加する。ステップＳ６１において、現在の時刻、加速度を最終記録として保存し、ステップＳ５６に戻る。ステップＳ５７の判断で、演算値が、衝撃パターンの時間長の閾値以上であると判断された場合には、ステップＳ６２に進む。ここでの閾値は図１２のステップＳ４１と同様である。
【００５２】
ステップＳ６２においては、測定開始から完了までに追加した全組のデータを衝撃パターンとしてメモリ内のデータを検索する。ステップＳ６３において、類似パターンが既にあるか否かを判断する。ステップＳ６３の判断がＹｅｓの場合には、ステップＳ６４において、衝撃パターンをサーバに送り、衝撃ＤＢに記録して処理を終了する。ステップＳ６３の判断がＮｏの場合には、そのまま処理を終了する。
【００５３】
図１４は、衝撃データのフォーマットを説明する図である。
図１４（ａ）は、加速度データのフォーマットである。加速度のｘ、ｙ、ｚ成分のいずれかが閾値ａを超えて変化した場合に、前回の送信したときからの経過時間と、ｘ方向加速度値、ｙ方向加速度値、ｚ方向加速度値を１レコードのデータとして生成する。
【００５４】
図１４（ｂ）は、例として、装置が机から落下し、数回バウンドした場合のデータ例を示している。
装置が落下したときは、前回の衝撃時からかなり時間が経っているので、前回送信からの時間は例として「９９９９９」としている。このとき、落下によって加速度値が０となる方向が発生している。その後、落下の衝撃により、前回送信からの時間が「４５０」のとき、ｘ方向加速度値が大きな値を示している。その後、前回送信からの時間が「３」のとき、空中に装置が跳ね上がり、ｘ方向加速度値が「０」となっている。前回送信からの時間が「９１」のとき、再び衝撃が発生し、ｙ方向加速度値が大きな値を示している。前回送信からの時間が「２」のとき、再び空中に装置が跳ね上がり、ｙ方向加速度値が「０」となり、前回送信からの時間が「２０」のとき、装置が床に付いて、ｘ方向加速度値が大きな値となっている。
【００５５】
ここで、前回送信からの時間の単位は、落下の跳ね上がり状態等を検出するためには、ミリ秒単位が好ましい。
サーバ型障害検出システムの場合、携帯端末がサーバ接続時には、図１４（ａ）のようなフォーマットのデータがリアルタイムにサーバに通知される。
【００５６】
図１５は、衝撃パターンのパターンマッチング処理のフローチャートである。
図１５において、発生した衝撃パターンが衝撃ＤＢのどのパターンと一致するかは、パターンマッチングにより、最も類似度の高いパターンを抽出し、そのパターンの類似度が閾値を超えているかどうかで判定する。
【００５７】
パターンマッチングのアルゴリズムは、簡易な方法として、時間／加速度値の差の絶対値の合計（後述の類似度を負にしたもの）が最小となるパターンを選ぶ方法や、ＤＰ(Dynamic Programming)マッチング等の伸縮マッチング手法を用いることが出来る。
【００５８】
ステップＳ７０において、現在の最大類似度を０に設定する。ステップＳ７１において、衝撃ＤＢに残りパターンがあるか否かを判断する。ステップＳ７１の判断がＹｅｓの場合には、ステップＳ７２において、衝撃ＤＢの次のパターンを読み込む。ステップＳ７３において、発生パターンと衝撃ＤＢから読み出した衝撃パターンの類似度を計算する。ステップＳ７４において、類似度が最大か否かを判断する。ステップＳ７４の判断がＮｏの場合には、ステップＳ７１に戻る。ステップＳ７４の判断がＹｅｓの場合には、ステップＳ７５において、最大類似度の値を現在の類似度で更新し、ステップＳ７１に戻る。
【００５９】
ステップＳ７１の判断がＮｏの場合には、ステップＳ７６において、最大類似度が閾値以上か否かを判断する。ステップＳ７６の判断がＹｅｓの場合には、ステップＳ７７において、類似衝撃パターンを検出したとし、ステップＳ７６の判断がＮｏの場合には、ステップＳ７８において、類似衝撃パターンがないと判断して、処理を終了する。
【符号の説明】
【００６０】
９、２０、３０ 携帯端末
１０、３２ 表示部
１１ ＣＰＵ
１２、４０ メモリ
１３ 操作部
１４ 加速度センサ
１５ 衝撃データベース
２１ サーバ
２２、２３ 通信部
２５ アクセスポイント
２６ ネットワーク
３１ クレードル
３３ 入力キー
【特許請求の範囲】
【請求項１】
メッセージを表示する表示部と、
衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサと、
所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、
該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該表示部に表示させる制御部と、
を備えることを特徴とする携帯端末。
【請求項２】
携帯端末と通信することによって障害が発生する状況を検出する障害検出システムであって、
メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサとを備える携帯端末と、
所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の該表示部に表示させる、該携帯端末とネットワークにより接続されたサーバと、
を備えることを特徴とする障害検出システム。
【請求項３】
前記衝撃データベースは、前記携帯端末に設けられることを特徴とする請求項２に記載の障害検出システム。
【請求項４】
前記衝撃データベースは、前記サーバに設けられることを特徴とする請求項２に記載の障害検出システム。
【請求項５】
前記サーバは、複数の携帯端末とネットワークにより接続され、
異なる携帯端末の加速度センサが検出した加速度の時間変化が、所定時間内に所定回数、同じ衝撃パターンに一致した場合には、該サーバに接続されている該複数の携帯端末の全てに警告メッセージを表示させることを特徴とする請求項２に記載の障害検出システム。
【請求項６】
前記衝撃データベースは、事前に作成されることを特徴とする請求項２に記載の障害検出システム。
【請求項７】
前記衝撃データベースは、前記携帯端末が新たに加速度の変化を検出するごとに、エントリが追加されることを特徴とする請求項２に記載の障害検出システム。
【請求項８】
携帯端末と通信することによって障害が発生する状況を検出する障害検出システムの処理方法であって、
該携帯端末に設けられた加速度センサが検出する、衝撃や振動や落下の際の加速度の時間変化を、衝撃データベースに格納された、所定の状況の下での加速度の時間変化のパターンを衝撃パターンと比較し、
該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の表示部に表示させる、
ことを特徴とする処理方法。
【請求項１】
メッセージを表示する表示部と、
衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサと、
所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、
該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該表示部に表示させる制御部と、
を備えることを特徴とする携帯端末。
【請求項２】
携帯端末と通信することによって障害が発生する状況を検出する障害検出システムであって、
メッセージを表示する表示部と、衝撃や振動や落下の際の加速度の時間変化を検出する加速度センサとを備える携帯端末と、
所定の状況の下での加速度の時間変化のパターンを衝撃パターンとして格納する衝撃データベースと、該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の該表示部に表示させる、該携帯端末とネットワークにより接続されたサーバと、
を備えることを特徴とする障害検出システム。
【請求項３】
前記衝撃データベースは、前記携帯端末に設けられることを特徴とする請求項２に記載の障害検出システム。
【請求項４】
前記衝撃データベースは、前記サーバに設けられることを特徴とする請求項２に記載の障害検出システム。
【請求項５】
前記サーバは、複数の携帯端末とネットワークにより接続され、
異なる携帯端末の加速度センサが検出した加速度の時間変化が、所定時間内に所定回数、同じ衝撃パターンに一致した場合には、該サーバに接続されている該複数の携帯端末の全てに警告メッセージを表示させることを特徴とする請求項２に記載の障害検出システム。
【請求項６】
前記衝撃データベースは、事前に作成されることを特徴とする請求項２に記載の障害検出システム。
【請求項７】
前記衝撃データベースは、前記携帯端末が新たに加速度の変化を検出するごとに、エントリが追加されることを特徴とする請求項２に記載の障害検出システム。
【請求項８】
携帯端末と通信することによって障害が発生する状況を検出する障害検出システムの処理方法であって、
該携帯端末に設けられた加速度センサが検出する、衝撃や振動や落下の際の加速度の時間変化を、衝撃データベースに格納された、所定の状況の下での加速度の時間変化のパターンを衝撃パターンと比較し、
該加速度センサが検出した加速度の時間変化が、該衝撃データベースの衝撃パターンと一致した場合に、警告メッセージを該携帯端末の表示部に表示させる、
ことを特徴とする処理方法。
【図１】
【図６】
【図１０】
【図１１】
【図１２】
【図１３】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図７】
【図８】
【図９】
【図１４】
【図６】
【図１０】
【図１１】
【図１２】
【図１３】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図７】
【図８】
【図９】
【図１４】
【公開番号】特開２０１２−２３４２５３（Ｐ２０１２−２３４２５３Ａ）
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願番号】特願２０１１−１００７３７（Ｐ２０１１−１００７３７）
【出願日】平成２３年４月２８日（２０１１．４．２８）
【出願人】（０００２３７６３９）富士通フロンテック株式会社 (667)
【公開日】平成２４年１１月２９日（２０１２．１１．２９）
【国際特許分類】
【出願日】平成２３年４月２８日（２０１１．４．２８）
【出願人】（０００２３７６３９）富士通フロンテック株式会社 (667)
[ Back to top ]