JP3778084B2

JP3778084B2 - Vending machine and vending machine failure diagnosis terminal device

Info

Publication number: JP3778084B2
Application number: JP2001398333A
Authority: JP
Inventors: 賢哉村上; 智律前川; 純一平松; 幸雄槙田
Original assignee: Fuji Electric Retail Systems Co Ltd
Current assignee: Fuji Electric Retail Systems Co Ltd
Priority date: 2001-12-27
Filing date: 2001-12-27
Publication date: 2006-05-24
Anticipated expiration: 2021-12-27
Also published as: JP2003196714A

Description

【０００１】
【発明の属する技術分野】
本発明は自動販売機の管理法方式に係り、更に詳しくは自動販売機の設定データや、運転制御状態のデータ、およびそれらの履歴データなどを、例えばモバイル端末上で簡単に表示、および設定でき、また自動販売機の故障診断などを容易とするための自動販売機、および自動販売機故障診断用端末装置に関する。
【０００２】
【従来の技術と発明が解決しようとする課題】
自動販売機はコーヒーやジュース、ビールなどの飲物だけに限られず、今日では非常に多くの種類の商品の販売に用いられている。自動販売機を安定して運用・管理するためには商品の価格、温度などの各種のデータを設定することが必要であると共に、押されたボタン、投入金種／金額、つり銭金種／金額、扉の開閉、電源のオン／オフなど、各種の運転制御状態のデータの収集なども必要となることがある。
【０００３】
従来は自動販売機に対するデータの設定などでは、自動販売機と例えば有線で接続されるリモコン装置などを用いて、データを１つずつ設定するような方法がとられていた。また各種の運転制御状態のデータはメモリカードなどに記憶され、工場や管理センターにそのカードが持ち帰られて解析されるという管理方式が用いられていた。
【０００４】
このような自動販売機の制御については次のような文献がある。
文献１）特開２００１−６０２８２「自動販売機制御装置」
文献２）特開２００１−９３０２９「自動販売機のサービス装置」
文献１には、自動販売機の各種の制御データを確認、変更するための操作履歴を自動販売機制御装置内に記憶しておき、その操作履歴を用いて制御データの確認、および変更作業を行うことによって、自動販売機の操作要員の負荷を少なくすることができる自動販売機制御装置が開示されている。
【０００５】
文献２では、サービスマンがＩＣカードを自動販売機に装着するだけでそのＩＣカード内のプログラムが実行可能となり、自動販売機に対応した修理用の判定動作や設定変更動作を行わせることができる自動販売機のサービス装置が開示されている。
【０００６】
次に自動販売機などの故障診断については、故障復旧知識を容易に獲得、および整理可能とする必要があるが、そのようなシステムについて次の文献がある。
文献３）特開平９−１０６３５０号
「故障事例獲得・整理装置及び知識獲得型故障診断システム」
文献３には、故障診断対象設備に関する用語が登録された用語辞書を備え、入力される入力用語を統一して管理すると共に、発生した故障事例の原因追及ステップから故障復旧ステップまでの一連の故障因果関係の知識を入力し、入力された知識の洗練化を支援する故障診断システムが開示されている。
【０００７】
以上に述べたように、自動販売機の設定データを確認したり、変更したりするためには、例えばリモコン装置の小さな液晶画面を用いて設定データを１つずつ表示し、設定変更を行うなどサービスマンの操作が複雑で、面倒であるという問題点があった。
【０００８】
また自動販売機の運転制御状態などの各種の動作履歴のデータは、メモリカードに記憶されて工場などに持ち帰られる形式であったために、その動作履歴をサービスマンが現場で見ることができず、現場でのサービスマンによる故障診断が困難であるという問題点があった。
【０００９】
本発明の課題は上述の問題点に鑑み、自動販売機の設定データや運転制御状態の動作履歴データなどを、サービスマンがモバイル端末などを用いて、例えば一覧表示させ、データの設定や自販機の故障診断を容易にさせることのできる自動販売機、および自動販売機故障診断用端末装置を提供することである。
【００１０】
【課題を解決するための手段】
図１は本発明の自動販売機の原理構成ブロック図である。図１において、自動販売機１の内部の履歴データ格納手段２は、自動販売機の運転制御状態の履歴データ、および／または設定データを格納するものであり、データ出力手段３は履歴データ格納手段２に格納されたデータを外部端末に対して有線、または無線で出力するものである。
【００１１】
本発明の自動販売機１は、例えば２つの中央処理装置（ＣＰＵ）を備えるものとする。第１の中央処理装置４は自動販売機の運転を制御するものであり、第２の中央処理装置５は履歴データ格納手段２へのデータの格納と、格納されたデータのデータ出力手段３による外部端末への出力とを制御するものである。
【００１２】
更に、自動販売機１は、第２の中央処理装置５によって制御され、第１の中央処理装置４の動作状態の監視を行う監視手段を備え、例えば第１の中央処理装置がダウンした場合などには第２の中央処理装置は第１の中央処理装置の再起動を行ったり、第１の中央処理装置に代わって自動販売機の運転を制御することもできる。
【００１３】
また実施の形態においては、自動販売機１は第１の中央処理装置４によって自動販売機の設定データが格納される設定データ格納手段を更に備え、設定データ格納手段に格納されているデータが消去された時、第２の中央処理装置５が履歴データ格納手段２に格納されている設定データをバックアップデータとして設定データ格納手段に格納させる制御を行うこともできる。
【００１４】
実施の形態においては履歴データ格納手段２は互いに干渉する複数の設定データの組合わせを更に格納することも、また設定データに対しても、その履歴データを格納することもできる。
【００１５】
更に実施の形態において、自動販売機１は外部端末で用いられるソフトウェアを格納するソフトウェア格納手段と、格納されているソフトウェアを外部端末に有線、または無線でダウンロードするソフトウェアダウンロード手段とを更に備えることもでき、また自動販売機の故障診断ロジックを格納する診断ロジック格納手段と、診断ロジック格納手段に格納された診断ロジックを履歴データ格納手段２に格納されている履歴データに適用して故障診断を行う故障診断手段とを更に備えることもできる。
【００１６】
次に本発明の自動販売機故障診断用端末装置は、故障診断のフローを表示する表示手段と、該表示されたフロー上の判定ステップに対する判定結果を受取る入力手段と、フロー上でたどられた経路を診断履歴として記憶する記憶手段とを備える。
発明の実施の形態においては、自動販売機故障診断用端末装置は、記憶された診断履歴上でたどられた回数の多い経路を抽出する抽出手段を更に備え、表示手段が抽出された経路と他の経路とをフロー上で異なる表示基準を用いて表示することもできる。
【００１７】
次に本発明の自動販売機、すなわち自動販売機の運転を制御する第１の中央処理装置に加えて、第２の中央処理装置を備える自動販売機によって用いられるプログラムとして、自動販売機の運転制御状態の履歴データ、および／または設定データをメモリに格納する手順と、格納されたデータを外部端末に対して有線、または無線で出力する手順と、第１の中央処理装置の動作状態を監視する手順とを第２の中央処理装置に実行させるためのプログラムが用いられる。
【００１８】
以上のように本発明によれば、自動販売機の運転制御状態の履歴データや設定データが外部端末に対して有線、または無線で出力される。
【００１９】
【発明の実施の形態】
図２は本発明の自動販売機（自販機）の構成ブロック図である。同図において自販機８は、外部端末９とインタフェース１０を介して接続されている。インタフェース１０としては赤外線インタフェースや、ネットワークとの接続インタフェースなどが用いられる。また外部端末９としては、例えばパソコン（ＰＣ）や、パーソナル・ディジタル・アシスタンツ（ＰＤＡ）を用いることができる。
【００２０】
自販機８の内部には、自販機の運転を制御するマスタＣＰＵ１１に加えて、運転制御状態の履歴データや、設定データなどのメモリへの格納と、そのデータの通信ライン、例えばＲＳ２３２−Ｃ、およびインタフェース１０を介しての外部端末９への出力を制御するための付加ＣＰＵ１２の２つのＣＰＵを備えており、マスタＣＰＵ１１に対してはメモリ１３、付加ＣＰＵ１２に対してはメモリ１４がそれぞれ基本的に専用のメモリとして接続されている。
【００２１】
本実施形態では、このように自販機の運転を制御するマスタＣＰＵ１１に加えて、付加ＣＰＵ１２を備える点に大きな特徴がある。すなわち従来から自販機の運転を制御するために備えられていたマスタＣＰＵ１１に加えて、データの外部端末への出力や、自販機の故障診断を容易とするために、専用の付加ＣＰＵ１２を追加することによって、マスタＣＰＵ１１の処理に影響を与えることなく、データの収集や故障診断などが可能となる。
【００２２】
このように付加ＣＰＵ１２を用いることによって、マスタＣＰＵ１１の動作を監視し、異常があれば必要な処理を行うこともできる。例えば付加ＣＰＵ１２によって、随時マスタＣＰＵ１１に対する監視信号を送り、その反応によってマスタＣＰＵ１１の動作状態を判定することができる。マスタＣＰＵ１１がダウンした場合には、付加ＣＰＵ１２がマスタＣＰＵ１１の再起動を行ったり、マスタＣＰＵ１１に代わって自販機の運転を制御するＣＰＵ二重化などを実現することができる。
【００２３】
自販機８の内部では、マスタＣＰＵ１１に対して各種のボックス、ここでは電源ボックス１５、コインメック（硬貨鑑別機）１６、ビルバリデータ（紙幣鑑別機）１７、およびスレーブボックス１８が通信ラインによって接続され、更にスレーブボックス１８にはサーミスタ１９、圧縮機・ヒータ・電磁弁２０などが接続されている。
【００２４】
ここでスレーブボックス１８は、マスタＣＰＵ１１からサーミスタ１９や圧縮機・ヒータ・電磁弁２０などを制御するための大まかな指令を受取るものであり、受取った指令に応じてサーミスタ１９、圧縮機・ヒータ・電磁弁２０などの細かい制御を行うものである。
【００２５】
図３は自販機、営業所、および本社・センターによって構成される自販機管理システムにおけるデータ収集方法の説明図である。同図において本社・センターの通信サーバ２２は、ネットワーク２３、例えばインターネット、公衆回線、または専用線を用いて、ネットワークインタフェース２４を介して自販機２５からデータ収集を行い、本社・センター内のＤＢサーバ２９によって管理されるデータベース３０にそのデータを格納する。
【００２６】
あるいはサービスマンの所持するＰＤＡ２７に、自販機２５からのデータが赤外線インタフェース２６を介してダウンロードされて保存され、営業所にそのＰＤＡ２７が持ち帰られて、ダウンロードされたデータが営業所のパソコン２８を経由してＤＢサーバ２９によって管理されるデータベース３０に格納される。
【００２７】
このように自販機２５からＰＤＡ２７にデータをダウンロードする場合などに、ＰＤＡ２７側で用いられるソフトウェアを、例えば図２のメモリ１４に格納しておき、付加ＣＰＵ１２がそのソフトウェアをＰＤＡ２７にダウンロードすることも可能である。
【００２８】
自動販売機と連携動作を行うことができるＰＤＡのソフトウェアとして、保全管理を含めて複数の種類が考えられ、それを全てＰＤＡ２７にインストールしておくのは面倒であり、その複数種類のソフトウェアをメモリ１４に格納しておき、必要に応じて付加ＣＰＵ１２がそのソフトウェアをＰＤＡ２７にダウンロードすることによって、ＰＤＡ２７にはあらかじめ特にソフトウェアをインストールしておく必要はなく、ＰＤＡの管理が簡単になる。
【００２９】
図４は本社・センターと自販機とによって構成されるシステムにおける故障診断方式の説明図である。同図において故障診断ソフトウェアライブラリ３１が本社・センター内に備えられており、オンラインの自販機２５ａ，２５ｂに対しては、そのライブラリ３１内に格納されている故障診断ソフトウェアが通信サーバ２２によってネットワーク２３を介してダウンロードされる。またオフライン自販機２５ｃに対しては、故障診断ソフトウェアライブラリ３１に格納されているソフトウェアが、ＰＤＡ２７ａに格納されて、例えばサービスマンや日常の商品補充を行うルートマンによってオフライン自販機に対してそのソフトウェアがダウンロードされる。
【００３０】
自販機２５ａ〜２５ｅに対する故障・修理の実績データは、自販機からＰＤＡ２７ｂにサービスマンによって入力され、そのＰＤＡ２７ｂが本社・センターに持ち帰られることによって、故障・修理実績データが故障・修理実績ＤＢサーバ３２によって故障修理実績データベース３３に格納される。
【００３１】
オンライン自販機２５ａ，２５ｂからは故障・修理情報をネットワーク２３を介してセンターの故障・修理実績ＤＢサーバ３２に送信するようにしてもよい。そしてこのような実績データは分析ロジックを用いて分析され、また故障診断ロジック・ソフトウェアの開発などに使用される。
【００３２】
図５は本社・センター、自販機、および営業所によって構成される自販機管理システムにおける診断フロー管理方式の説明図である。同図において本社・センターには、診断フロー管理部４０、および診断フローマスターデータベース４１が備えられ、診断フローマスタデータベース４１に格納されている診断フローマスタ４２は、営業所のパソコン２８を経由してＰＤＡ２７に営業所内でダウンロードされ、サービスマンは自販機２５の現場で、ＰＤＡ２７に格納された診断フローを用いて自販機２５の点検・診断を行い、診断フローの実績をＰＤＡ２７に入力する。
【００３３】
ＰＤＡ２７に入力された診断フロー実績４３は、営業所のパソコン２８にアップロードされ、本社・センター内の診断事例データベースサーバ４４に送られ、事例データベース４５に格納される。格納された診断事例は、必要に応じて診断フロー管理部４０内の診断フロー更新部によって、診断フローマスタデータベース４１の格納内容の更新に用いられる。
【００３４】
次に図２の自販機８と外部端末９によって実行される処理のフローチャートについて説明する。図６は図２の付加ＣＰＵ１２による運転制御状態の履歴データなどのメモリ１４への格納処理のフローチャートである。同図において、マスタＣＰＵ１１側でステップＳ１でイベントがあったか否かが判定され、自販機の扉の開閉や商品の販売、釣銭切れ、あるいは圧縮機・ヒータ・電磁弁２０などの動作状態の変更などが、イベントとしてマスタＣＰＵ１１に伝えられると、そのイベントが、イベントに対応するデータが添付されて付加ＣＰＵ１２に送られる。
【００３５】
付加ＣＰＵ１２側では、ステップＳ２でイベントデータを受信し、ステップＳ３でイベントデータをメモリ１４に保存し、その履歴データなどはステップＳ４でメモリ１４に格納される。
【００３６】
このようにデータをメモリに格納する場合には動作履歴、すなわち運転制御状態の履歴データに限らず、設定データの履歴データもメモリに格納することができる。設定データは商品の販売価格や、冷却・加温の条件設定など、自販機が動作する条件を設定したもので、動作履歴のように自販機の動作、すなわちトランザクション毎に発生するものではない。
【００３７】
このような設定データについても、例えばサービスマンが設定しなおすことがあり、この設定データの履歴もメモリに格納するものとするが、そのタイミングとしては次の３つが考えられる。第１のタイミングは設定データが変更される時点であり、マスタＣＰＵ１１が付加ＣＰＵ１２にそれを通知し、付加ＣＰＵ１２側で変更された設定データを、例えば変更の時刻と共に取得して、メモリ１４に保存する。
【００３８】
第２のタイミングとしては、付加ＣＰＵ１２側でデータを取得するたびに前回の設定データと比較し、変更があった部分、すなわち差分だけを保存する方法がある。これによって毎回全ての設定データを保存するよりも保存するデータ量が少なくなる。最新の全設定データがある場合には、最新のデータと差分の履歴とを用いて、過去に設定データがどう設定されていて、どのように変更されてきたかが判明する。
【００３９】
例えばデータのバックアップ用としては、過去のある時点での設定データ全体を持ち、その過去の時点から現在に向かってデータの変更履歴をたどることによって、現在を含め、各時点での設定データ全体を知ることができる。
【００４０】
第３のタイミングは、図６で説明したようなイベントの発生時点である。この方法では、設定データの変更が発生するたびに付加ＣＰＵ１２によるデータ収集が行われるのでなく、イベントとイベントの間の変更をいくつかまとめた履歴がとれることになり、設定データの変更が発生するたびにデータの収集を行うよりもデータ取得の頻度も少なく、またメモリ１４の格納領域の有効な利用が可能となる。
【００４１】
図７は図６と同様の付加ＣＰＵ１２による履歴データ収集処理のフローチャートであるが、マスタＣＰＵ１１から送られるイベントに必要なデータが添付されていない場合の処理を示す。同図においてマスタＣＰＵ１１側で、ステップＳ６においてイベントがあったか否かが判定され、あった場合には付加ＣＰＵ１２側にイベントが送られる。
【００４２】
付加ＣＰＵ１２側ではステップＳ７でイベントを受信し、ステップＳ８でマスタＣＰＵ１１に対してデータの要求を送る。マスタＣＰＵ１１側ではこの要求をステップＳ９で受信し、要求されたデータをステップＳ１０で付加ＣＰＵ１２に送信する。
【００４３】
付加ＣＰＵ１２側ではステップＳ１１で送られたデータを受信し、ステップＳ１２でそのデータをメモリ１４に保存し、ステップＳ１３でメモリ１４に履歴データなどが格納される。
【００４４】
図８は付加ＣＰＵ１２による履歴データなどのメモリ１４への格納処理のフローチャートであるが、データ収集が付加ＣＰＵ１２側でのイベントがあった時点、すなわち付加ＣＰＵ１２側でのトリガーによって開始される場合の処理である。付加ＣＰＵ１２内でのイベントとしては、例えば一定周期で発生するイベントなどがあり、そのイベントがあったことがステップＳ１５で判定されると、ステップＳ１６でマスタＣＰＵ１１に対してデータの要求が送られる。
【００４５】
マスタＣＰＵ１１側ではステップＳ１７でこの要求を受信し、ステップＳ１８でデータを付加ＣＰＵ１２側に返信し、付加ＣＰＵ１２側ではステップＳ１９でデータを受信し、ステップＳ２０でそのデータをメモリ１４に保存し、履歴データなどがステップＳ２１でメモリ１４に格納される。
【００４６】
図９は付加ＣＰＵ１２によるマスタＣＰＵ１１側でのデータの取得処理、すなわちマスタＣＰＵ１１側でメモリ１３に格納されるデータを、付加ＣＰＵ12側でメモリ１４に格納しておく処理のフローチャートである。
【００４７】
図９において、マスタＣＰＵ１１と付加ＣＰＵ１２との間で、図７のステップＳ６〜Ｓ１１と同様の処理がステップＳ２５〜Ｓ３３で行われ、例えば設定データについて最新の全データが受信される。
【００４８】
付加ＣＰＵ１２側でのデータの保持の方式として、第１に初期データと差分履歴データとを保持する方式と、第２に前回データと差分履歴データとを保持する方式とがある。ここで初期データは初期の全設定データ、前回データは付加ＣＰＵ１２側で前回取得した全設定データを意味する。
【００４９】
初期データは必ずしも１番最初の設定データでなくともよく、その時点以降の差分を保持してもよい。メモリ量の制約から、１番最初のデータから全ての差分を取って保存しておくことは不可能であることが多く、初期データ自体を更新して、メモリ内に格納できる１番古いデータを初期データとして扱うのが、メモリ量の節約の上で効率的である。
【００５０】
初期データと差分履歴データとを保持する場合には、初期データから未来に向かって、また前回データと差分履歴データを保持する場合には、前回データから過去に向かって、過去にあった設定データの変更内容を復元、すなわち再現することが可能である。
【００５１】
図９において、ステップＳ３３でマスタＣＰＵ１１から最新の全ての設定データが受信された後に、ステップＳ３４〜Ｓ３７の処理が行われる。ここで初期データと差分履歴データを付加ＣＰＵ１２側で保持する場合には、初期データから未来に向かってデータを復元することにより、前回データ、すなわち前回付加ＣＰＵ１２が取得した全設定データが復元され、これと今回マスタＣＰＵ１１側から取得した最新のデータとが比較されて、その差分データが求められ、この最新のデータが前回のデータに置き換え、すなわち上書きされる。
【００５２】
図１０は外部端末による自販機からのデータの取得処理のフローチャートである。図２の外部端末９は、付加ＣＰＵ１２によって収集された履歴データなどが格納されているメモリ１４のデータを取得するために、ステップＳ４０でデータの要求を付加ＣＰＵ１２に送る。
【００５３】
付加ＣＰＵ１２側ではステップＳ４１でこの要求を受信し、メモリ１４からステップＳ４２で履歴データなどを読み出し、読み出したデータをステップＳ４３で外部端末９に向けて送信する。このデータは外部端末９側でステップＳ４４で受信され、ステップＳ４５で外部端末９内のメモリに格納され、ステップＳ４６で外部端末の表示画面上にそのデータが表示される。
【００５４】
図１１は外部端末によるデータの取得処理のフローチャートであり、付加ＣＰＵ１２のメモリ１４上に履歴データが差分として保存されている場合の処理を示す。外部端末９から、図１０におけるステップＳ４０と同様にデータの要求が付加ＣＰＵ１２に送られ、その要求はステップＳ４１で受取られる。
【００５５】
付加ＣＰＵ１２側では、メモリ１４に格納されている、例えば商品の価格などの各種の設定データの初期データまたは前回データと、差分履歴データとがステップＳ４２で読み出され、ステップＳ４３で外部端末９に向けて送信される。
【００５６】
外部端末９側ではステップＳ４４で送られたデータを受信し、ステップＳ４７で初期データと差分履歴データとを用いて全データ、すなわち変更が検出された各時点での全データが復元され、ステップＳ４８でメモリ１４上にデータが格納され、ステップＳ４９でそのデータが端末９の表示画面上に表示される。
【００５７】
ここでステップＳ４８でメモリ１４に格納されるデータは最新の全データでもよく、それに加えて初期データと差分履歴データとを格納してもよく、あるいは付加ＣＰＵ１２から送られたデータそのものでもよい。なおここでは付加ＣＰＵ１２側のメモリ１４に、例えば設定データの初期データとその初期データに対する差分履歴データとが格納されているものとしたが、初期データの代わりにある時点の全体のデータを格納し、差分履歴データとしてはその時点からの履歴データを格納しておくこともできる。
【００５８】
図１２は、図１１のバックアップ処理によって付加ＣＰＵ１２側のメモリ１４に格納された収集データの、マスタＣＰＵ１１側のメモリ１３へのリストア処理のフローチャートである。同図においては外部端末９のメモリに格納されている時刻データを基準として、その時刻における、例えば設定データがマスタＣＰＵ１１側のメモリ１３にリストアされるものとする。このようなデータのリストアは、例えば図２の電源ボックスなどの各種ボックスの交換時にも行われる。
【００５９】
図１２において、外部端末９の図示しないメモリに格納されている時刻データがステップＳ５０で出力され、外部端末９からその時刻データと共に、データ設定要求がステップＳ５１で付加ＣＰＵ１２に送られる。
【００６０】
付加ＣＰＵ１２側ではこの要求をステップＳ５２で受取り、ステップＳ５３でメモリ１４から、例えば設定データの初期データまたは前回データと差分履歴データとが出力される。この差分履歴データは、差分が取られた時刻も添付されているデータであるとする。そしてステップＳ５４でマスタＣＰＵ１１へのデータ設定要求と、初期データまたは前回データおよび差分履歴データが送られる。
【００６１】
マスタＣＰＵ１１側ではステップＳ５５で付加ＣＰＵ１２からのデータ設定要求とデータを受信し、ステップＳ５６でメモリ１３へのデータ設定を行い、ステップＳ５７でメモリ１３にデータが格納される。
【００６２】
図１３は外部端末９、例えばＰＤＡの画面上の設定データ表示結果の例である。この表示は、付加ＣＰＵ１２からＰＤＡに自販機設定データの一覧として送られたものであり、ＰＤＡの自由な表示形式に従って自販機の設定データを一目で確認し、設定の間違いなどを修正することができる。これによって従来行われていたリモコンによる設定データ項目の順次表示、および修正操作に比べて、サービスマンの手間を減らすことができる。
【００６３】
図１３の表示例においてコラム別価格のコラムとは商品、例えば飲料の缶が格納されている縦の棚に相当し、１つのコラムには１種類の商品だけが格納され、従って価格はコラム別に設定される。
【００６４】
交互販売とは２つ以上のコラムに同一の商品が収納されており、複数のコラムから順番に商品が搬出されることを示す。このような交互販売に対応して、同一の商品が収納されている複数のコラムのコラム別価格として、互いに干渉する設定データの組合わせが設定されることになる。
【００６５】
このため、例えば交互販売になっているため、一方のコラムだけでは価格設定を変更できないとか、スクールタイマーの販売休止時間帯、例えば授業中のため販売できないなどの条件を考慮して、設定の間違いを一目で確認することが可能になる。なお設定データを全部表示することは必ずしも必要がなく、故障に関係のありそうなデータの組合わせだけを表示することによって、故障に関連する可能性のあるデータの調査を行うことができる。
【００６６】
図１４は自販機の運転制御状態の履歴データの表示例である。付加ＣＰＵ１２から、例えばＰＤＡにこのような運転履歴データが送られることによって、故障原因の早期かつ詳細な特定が可能となる。またこのような運転履歴データを取得することによって、そのデータを活用して新しい診断ロジックの作成、すなわちナレッジの抽出も可能となる。
【００６７】
図１４の表示画面の上の図において、１４時以降にファンが動作しているにもかかわらず温度が上昇しており、何らかの故障があると診断できる。すなわちモータコントローラやファンが動作しているにもかかわらず、温度が上昇しているということから、そのファンに対する制御出力に異常があると判定することができる。
【００６８】
原因不明の故障が頻発する場合などは、関係しそうな箇所のデータのログをとって本社・センターなどに持ち帰って解析することが可能であり、またサービスマンでは故障を修理できない場合には、本社・センターに関係しそうなデータを送信して解析してもらうことも可能である。
【００６９】
図１５は、図１４と同様の運転制御状態の履歴の外部端末における表示例である。同図においてＰＣはピックカット、ＰＳはピークシフトを意味する。ピークシフトとは、例えば真夏で午後２時頃に電力消費がピークとなるような季節において、例えば１１時頃までに冷却機をフルに動かし、商品を十分に冷やしておいて午後２時頃には冷却機を動かさないようにすること、すなわちピークをシフトさせることを意味し、ピークカットは午後２時頃の電力消費をカットすることを意味する。このようなＰＣ／ＰＳなどを運転制御状態の要因という。
【００７０】
図１６は外部端末における運転履歴データの他の表示例である。ここでは図２で説明した各種ボックス、例えば電源ボックス１５やスレーブボックス１８、あるいは他の部品への入出力信号の履歴データが示されており、例えば１０時３０分にあるボックスの出力端子の２番目のピンから信号が出力されたことが示されている。
【００７１】
図１７は運転制御状態の履歴データに基づくデータマイニング手法による故障診断の説明図である。同図においてはカイ２乗検定による故障診断、すなわちＣＨＡＩＤ（カイ−スクエア・テスト・オートマチック・インターアクション・ディテクタ）分析によって、故障の要因を見つけ出すための故障診断が行われる。データマイニング手法としてはニューロを用いる方法など各種の公知の方法も利用できる。
【００７２】
図１７においては商品が出なかった故障に対する診断を行うために、まずメインコントロールボックスの信号がチェックされ、第１要因として押しボタンによる違いが検討され、第２要因としてＡメック、例えば図２のコインメック１６による違いが検討され、販売された商品１０００個についての履歴データから第１チェックポイントが分析されている。
【００７３】
次に図４で説明した自販機の故障診断ロジックの更新について説明する。例としてコインメック、すなわち硬貨鑑別機の清掃時期の決定基準や、蛍光灯交換時期の決定などの簡単な場合を考えると、故障診断ロジックとしてルートマン、すなわち商品補充者の日常の管理業務の中で、予防保全のためにルートマンが実行すべきことをガイダンスするようなロジックも考えられる。
【００７４】
例えばコインメックを通過するコインの通過枚数がある設定された値を越えた場合、また蛍光灯の連続点灯時間がある設定された値を越えた場合には、オンラインであれば自販機が発呼することによって、オフラインなら例えばアラームとしてルートマンにそれを通知することによって、ルートマンによるコインメックの清掃や、蛍光灯交換を促すことができる。
【００７５】
この場合、コインメックの清掃時期の判断基準としてはコインの通過枚数だけでよいか否かが問題であり、逆にコインが通過しない時間の長さなどを考慮したりする必要があり、蛍光灯の交換時期も外部環境や調光時間の設定などによって著しく異なるため、このようなロジックをどのように組むかはなかなか難しい問題である。
【００７６】
すなわち図４で説明したように、例えばＰＤＡを用いて故障・修理の実績データとして室外温度、庫内温度、商品温度、ファン制御状態、ヒータ制御状態、バルブ制御状態、モータコントローラなどのデータ、マスタＣＰＵの故障コードなどがとられ、故障診断ロジックを用いて故障発生を示すアラーム発生や、設定データの自動調整などの予防措置を行うことができるが、故障診断ロジックはその有効性が必ずしも明確でなく、季節／地域性／機種（型番）などによって故障の内容が異なるため固定的なものを用いることができず、頻繁な更新や追加が必要となる。
【００７７】
図１８はこのような故障診断ロジックの更新、および開発の説明図である。同図においては故障修理履歴データ、サービスマン日報、ヘルプデスクなどのデータを用いて分析結果が得られ、分析結果に基づいて故障診断・予防保全対策が設定され、その対策がロジック化されて、例えばＪＡＶＡプログラムとして自販機に一括で簡単にダウンロードされることによって、季節・地域・機種・顧客別などに応じた故障診断ロジックが使用可能となる。なお図１８の
１．分析結果のＢ：のベンドメックは図２のベンドメック２１に対応し、また
２．故障診断・予防保全対策のＣ：の排除率とはコインの選別基準の厳密度に相当する。
【００７８】
次に本発明における自販機故障診断用端末装置の動作について説明する。図１９は、図５で説明した診断フローマスタを活用した外部端末による故障診断例の説明図である。同図においては付加ＣＰＵ１２からＰＤＡに自販機や部品の形式がダウンロードされ、それに対応した診断フローが外部端末の画面上に表示される。サービスマンはそのフローに対応してフロー内の判定ステップに対してイエス、またはノーを入力することによって、サービスマンがフロー内でどのルートをたどったかが記録され、その結果は診断フロー実績４３として本社・センター内の事例データベース４５に格納される。
【００７９】
このように診断フローを外部端末上に表示する時、過去の診断事例に基づいて診断フローチャートの中でよく用いられるルートをより大きく明確に表示したり、あまり使われないルートを小さく表示したり、あるいは削除したりすることもでき、更に新しいルートを追加できる機能を持たせることも可能である。
【００８０】
図２０は図５の事例データベース４５に保存された診断事例を外部端末で利用する例の説明図である。同図において事例検索の画面上で、故障内容と主修理内容に対応する詳細ボタンを押すことによって、過去に行われた理想的あるいは典型的な修理対応のフローが表示され、サービスマンによる診断が有効に利用される。
【００８１】
【発明の効果】
以上詳細に説明したように、本発明によれば自動販売機の設定データや運転制御状態の履歴データなどを、例えばモバイル端末に表示することによって、サービスマンによる設定データの変更や履歴データを用いた故障診断などが容易となり、サービスマンの負担を大幅に軽減させることができる。
【００８２】
またモバイル端末などによって収集された故障・修理の実績データを管理センターなどに持ち帰ることにより、故障診断ソフトウェアの開発などに有効に利用することが可能となる。
【００８３】
更に端末装置に故障診断のフローを表示し、表示されたフロー上の判定ステップに対するサービスマンによる判定の結果を診断履歴として利用することが可能となり、自動販売機管理システムの実用性の向上に寄与するところが大きい。
【図面の簡単な説明】
【図１】本発明の原理構成ブロック図である。
【図２】本実施形態における自動販売機の構成を示すブロック図である。
【図３】自販機管理システムにおけるデータ収集方法の説明図である。
【図４】自販機管理システムにおける故障診断方式の説明図である。
【図５】自販機管理システムにおける診断フロー管理方式の説明図である。
【図６】付加ＣＰＵによるデータ収集処理のフローチャートの第１の例である。
【図７】付加ＣＰＵによるデータ収集処理のフローチャートの第２の例である。
【図８】付加ＣＰＵによるデータ収集処理のフローチャートの第３の例である。
【図９】付加ＣＰＵによるデータ収集処理のフローチャートの第４の例である。
【図１０】外部端末によるデータ取得処理のフローチャートの第１の例である。
【図１１】外部端末によるデータ取得処理のフローチャートの第２の例である。
【図１２】収集データのリストア処理のフローチャートである。
【図１３】外部端末の画面上の設定データ表示結果の例である。
【図１４】自販機の運転制御状態履歴データの第１の表示例である。
【図１５】自販機の運転制御状態履歴データの第２の表示例である。
【図１６】自販機の運転制御状態履歴データの第３の表示例である。
【図１７】データマイニング手法による故障診断の説明図である。
【図１８】故障診断ロジックの更新および開発の説明図である。
【図１９】外部端末による故障診断例の説明図である。
【図２０】診断事例を外部端末で利用する例の説明図である。
【符号の説明】
１，８自動販売機
２履歴データ格納手段
３データ出力手段
４第１の中央処理装置
５第２の中央処理装置
９外部端末
１０インタフェース
１１マスタＣＰＵ
１２付加ＣＰＵ
１３，１４メモリ
１５電源ボックス
１６コインメック
１７ビルバリデータ
１８スレーブボックス
１９サーミスタ
２０圧縮機・ヒータ・電磁弁
２１ベンドメック
２２通信サーバ
２３ネットワーク
２７パーソナル・ディジタル・アシスタンツ（ＰＤＡ）
２８営業所パソコン（ＰＣ）
２９ＤＢサーバ
３０データベース[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a vending machine management method, and more particularly, vending machine setting data, operation control status data, and history data thereof can be easily displayed and set on, for example, a mobile terminal. The present invention also relates to a vending machine for facilitating fault diagnosis of a vending machine and a terminal device for vending machine fault diagnosis.
[0002]
[Prior art and problems to be solved by the invention]
Vending machines are not limited to drinks such as coffee, juice, and beer, and today they are used to sell a great variety of products. In order to operate and manage the vending machine stably, it is necessary to set various data such as product price, temperature, etc., as well as the pressed button, input denomination / amount, change denomination / amount. It may also be necessary to collect data on various operation control states such as opening / closing doors and turning on / off power.
[0003]
Conventionally, in setting data for a vending machine, a method has been adopted in which data is set one by one using a remote control device connected to the vending machine, for example, by wire. In addition, a management method was used in which data of various operation control states were stored in a memory card or the like, and the card was taken back to a factory or management center for analysis.
[0004]
The following documents are available for controlling such vending machines.
Reference 1) Japanese Patent Laid-Open No. 2001-60282 “Vending Machine Control Device”
Reference 2) Japanese Patent Laid-Open No. 2001-93029 "Vending Machine Service Device"
In Document 1, an operation history for confirming and changing various control data of the vending machine is stored in the vending machine control device, and control data is confirmed and changed using the operation history. By doing so, a vending machine control device is disclosed that can reduce the burden on the operation personnel of the vending machine.
[0005]
In Document 2, a serviceman can execute a program in an IC card simply by attaching the IC card to a vending machine, and can perform a determination operation or a setting change operation for repair corresponding to the vending machine. A vending machine service device is disclosed.
[0006]
Next, for fault diagnosis of vending machines or the like, it is necessary to easily acquire and organize fault recovery knowledge.
Reference 3) JP-A-9-106350
"Failure case acquisition / arrangement device and knowledge acquisition type fault diagnosis system"
Reference 3 includes a term dictionary in which terms related to the equipment to be diagnosed are registered, and the input terms that are input are managed in a unified manner, and a series of failures from the cause search step to the failure recovery step of the failure case that has occurred. A fault diagnosis system that inputs causal knowledge and supports the refinement of the input knowledge is disclosed.
[0007]
As described above, in order to check or change the setting data of the vending machine, for example, the setting data is displayed one by one using a small liquid crystal screen of the remote control device, and the setting is changed. There was a problem that the operation of the service person was complicated and troublesome.
[0008]
In addition, since the data of various operation histories such as the operation control status of the vending machine was stored in a memory card and brought back to the factory etc., the service histories could not be seen on site by service personnel, There was a problem that failure diagnosis by a service person on site was difficult.
[0009]
In view of the above problems, the problem of the present invention is that a serviceman uses a mobile terminal or the like to display a list of vending machine setting data, operation control state operation history data, etc., and data setting or vending machine It is an object of the present invention to provide a vending machine capable of facilitating failure diagnosis, and a vending machine failure diagnosis terminal device.
[0010]
[Means for Solving the Problems]
FIG. 1 is a block diagram showing the principle configuration of a vending machine according to the present invention. In FIG. 1, the history data storage means 2 inside the vending machine 1 stores the history data and / or setting data of the operation control state of the vending machine, and the data output means 3 is the history data storage means. The data stored in 2 is output to an external terminal by wire or wirelessly.
[0011]
The vending machine 1 according to the present invention includes, for example, two central processing units (CPUs). The first central processing unit 4 controls the operation of the vending machine, and the second central processing unit 5 stores data in the history data storage means 2 and the data output means 3 for the stored data. It controls output to an external terminal.
[0012]
More The vending machine 1 is controlled by the second central processing unit 5 and monitoring means for monitoring the operating state of the first central processing unit 4 Be equipped For example, when the first central processing unit goes down, the second central processing unit restarts the first central processing unit, or operates the vending machine in place of the first central processing unit. Can also be controlled.
[0013]
In the embodiment, the vending machine 1 further includes setting data storage means for storing the setting data of the vending machine by the first central processing unit 4, and the data stored in the setting data storage means is erased. At this time, the second central processing unit 5 can also control to store the setting data stored in the history data storage means 2 in the setting data storage means as backup data.
[0014]
In the embodiment, the history data storage means 2 can further store a combination of a plurality of setting data that interfere with each other, and can also store the history data for the setting data.
[0015]
Furthermore, in the embodiment, the vending machine 1 may further include software storage means for storing software used in the external terminal, and software download means for downloading the stored software to the external terminal by wire or wirelessly. The diagnosis logic storage means for storing the failure diagnosis logic of the vending machine and the diagnosis logic stored in the diagnosis logic storage means are applied to the history data stored in the history data storage means 2 to perform the failure diagnosis. Failure diagnosis means can also be provided.
[0016]
Next, the terminal device for fault diagnosis of the vending machine according to the present invention is traced on the flow, a display means for displaying a flow of fault diagnosis, an input means for receiving a judgment result for a judgment step on the displayed flow. Storage means for storing the route as a diagnosis history.
In an embodiment of the invention, the vending machine failure diagnosis terminal device further comprises an extraction means for extracting a route that has been frequently visited on the stored diagnosis history, and the route from which the display means is extracted; Other routes can also be displayed using different display criteria on the flow.
[0017]
Next, in addition to the vending machine of the present invention, that is, the first central processing unit that controls the operation of the vending machine, the operation of the vending machine is used as a program used by the vending machine including the second central processing unit. A procedure for storing control state history data and / or setting data in a memory, and a procedure for outputting the stored data to an external terminal in a wired or wireless manner; , A procedure for monitoring the operating state of the first central processing unit; Is used by the second central processing unit.
[0018]
As described above, according to the present invention, the history data and setting data of the operation control state of the vending machine are output to the external terminal by wire or wirelessly.
[0019]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 2 is a block diagram showing the configuration of the vending machine (vending machine) according to the present invention. In the figure, a vending machine 8 is connected to an external terminal 9 via an interface 10. As the interface 10, an infrared interface, a connection interface with a network, or the like is used. Further, as the external terminal 9, for example, a personal computer (PC) or a personal digital assistant (PDA) can be used.
[0020]
In the vending machine 8, in addition to the master CPU 11 for controlling the operation of the vending machine, storage of operation control state history data and setting data in a memory, and a communication line of the data, for example, RS232-C, and an interface 10 includes two CPUs, an additional CPU 12 for controlling output to the external terminal 9 via 10, and a memory 13 is basically dedicated to the master CPU 11, and a memory 14 is basically dedicated to the additional CPU 12. Connected as a memory.
[0021]
In this embodiment, in addition to the master CPU 11 that controls the operation of the vending machine as described above, there is a great feature in that the additional CPU 12 is provided. That is, in addition to the master CPU 11 that has been conventionally provided for controlling the operation of the vending machine, a dedicated additional CPU 12 is added to facilitate the output of data to an external terminal and the failure diagnosis of the vending machine. Data collection and failure diagnosis can be performed without affecting the processing of the master CPU 11.
[0022]
By using the additional CPU 12 in this way, it is possible to monitor the operation of the master CPU 11 and perform necessary processing if there is an abnormality. For example, the additional CPU 12 can send a monitoring signal to the master CPU 11 at any time, and the operation state of the master CPU 11 can be determined based on the reaction. When the master CPU 11 is down, the additional CPU 12 can restart the master CPU 11 or can realize a CPU duplication that controls the operation of the vending machine in place of the master CPU 11.
[0023]
Inside the vending machine 8, various boxes, in this case, a power supply box 15, a coin mech (coin discriminator) 16, a bill validator (banknote discriminator) 17, and a slave box 18 are connected by a communication line to the master CPU 11. Further, a thermistor 19, a compressor / heater / electromagnetic valve 20, etc. are connected to the slave box 18.
[0024]
Here, the slave box 18 receives a rough command for controlling the thermistor 19 and the compressor / heater / solenoid valve 20 from the master CPU 11, and the thermistor 19, the compressor / heater, and the like are controlled according to the received command. Fine control of the solenoid valve 20 and the like is performed.
[0025]
FIG. 3 is an explanatory diagram of a data collection method in a vending machine management system including a vending machine, a sales office, and a head office / center. In the figure, a head office / center communication server 22 collects data from a vending machine 25 via a network interface 24 using a network 23, for example, the Internet, a public line, or a dedicated line, and a DB server 29 in the head office / center. The data is stored in the database 30 managed by.
[0026]
Alternatively, the data from the vending machine 25 is downloaded and stored in the PDA 27 owned by the service person via the infrared interface 26, the PDA 27 is brought back to the sales office, and the downloaded data passes through the personal computer 28 in the sales office. And stored in the database 30 managed by the DB server 29.
[0027]
Thus, when data is downloaded from the vending machine 25 to the PDA 27, the software used on the PDA 27 side can be stored in the memory 14 of FIG. 2, for example, and the additional CPU 12 can download the software to the PDA 27. is there.
[0028]
There are several types of PDA software that can perform cooperative operations with vending machines, including maintenance management, and it is troublesome to install all of them in the PDA 27. 14 and the additional CPU 12 downloads the software to the PDA 27 as necessary, so that it is not necessary to install the software in the PDA 27 in advance, and the management of the PDA is simplified.
[0029]
FIG. 4 is an explanatory diagram of a failure diagnosis method in a system including a head office / center and a vending machine. In the figure, a fault diagnosis software library 31 is provided in the head office / center. For online vending machines 25a and 25b, the fault diagnosis software stored in the library 31 is connected to the network 23 by the communication server 22. Downloaded via. For the offline vending machine 25c, the software stored in the failure diagnosis software library 31 is stored in the PDA 27a, and the software is downloaded to the offline vending machine by, for example, a serviceman or a routeman who performs daily product replenishment. Is done.
[0030]
The failure / repair record data for the vending machines 25a to 25e is input from the vending machine to the PDA 27b by the service person, and when the PDA 27b is brought back to the head office / center, the failure / repair record data is broken by the failure / repair record DB server 32. It is stored in the repair record database 33.
[0031]
The online vending machines 25a and 25b may transmit failure / repair information to the failure / repair record DB server 32 of the center via the network 23. Such performance data is analyzed using analysis logic, and is used for development of fault diagnosis logic software.
[0032]
FIG. 5 is an explanatory diagram of a diagnostic flow management method in a vending machine management system including a head office / center, a vending machine, and a sales office. In the figure, the head office / center is provided with a diagnostic flow management unit 40 and a diagnostic flow master database 41. The diagnostic flow master 42 stored in the diagnostic flow master database 41 passes through the personal computer 28 of the sales office. The service person downloads the data to the PDA 27 in the sales office, and checks and diagnoses the vending machine 25 using the diagnosis flow stored in the PDA 27 at the site of the vending machine 25, and inputs the results of the diagnosis flow to the PDA 27.
[0033]
The diagnosis flow record 43 input to the PDA 27 is uploaded to the personal computer 28 of the sales office, sent to the diagnosis case database server 44 in the head office / center, and stored in the case database 45. The stored diagnosis cases are used for updating the stored contents of the diagnosis flow master database 41 by the diagnosis flow update unit in the diagnosis flow management unit 40 as necessary.
[0034]
Next, a flowchart of processing executed by the vending machine 8 and the external terminal 9 shown in FIG. 2 will be described. FIG. 6 is a flowchart of the storing process of the history data of the operation control state in the memory 14 by the additional CPU 12 of FIG. In the figure, it is determined whether or not an event has occurred in step S1 on the master CPU 11 side, such as opening / closing of the vending machine door, sale of goods, running out of change, or change of the operating state of the compressor / heater / electromagnetic valve 20 or the like. When the event is transmitted to the master CPU 11 as an event, the event is sent to the additional CPU 12 with data corresponding to the event attached.
[0035]
On the additional CPU 12 side, the event data is received in step S2, the event data is stored in the memory 14 in step S3, and the history data and the like are stored in the memory 14 in step S4.
[0036]
Thus, when data is stored in the memory, not only the operation history, that is, the operation control state history data, but also the setting data history data can be stored in the memory. The setting data sets conditions for operating the vending machine, such as product sales price and cooling / heating condition settings, and does not occur for each vending machine operation, that is, for each transaction, as in the operation history.
[0037]
Such setting data may be set again by, for example, a service person, and the history of the setting data is also stored in the memory, and the following three timings are conceivable. The first timing is when the setting data is changed. The master CPU 11 notifies the additional CPU 12 of the change, and the setting data changed on the additional CPU 12 side is acquired together with the time of change, for example, and stored in the memory 14. To do.
[0038]
As the second timing, there is a method of comparing only the setting data of the previous time every time data is acquired on the additional CPU 12 side, and storing only the changed portion, that is, the difference. As a result, the amount of data to be saved is smaller than saving all setting data each time. When there is all the latest setting data, it is determined how the setting data has been set and how it has been changed in the past using the latest data and the difference history.
[0039]
For example, for data backup, you have the entire setting data at a certain point in the past and follow the change history of the data from the past point to the present, so that the entire setting data at each point in time is included. I can know.
[0040]
The third timing is the time of occurrence of the event as described in FIG. In this method, every time a change in setting data occurs, data collection by the additional CPU 12 is not performed, but a history that summarizes some changes between events is obtained, and a change in setting data occurs. Data is collected less frequently than data is collected every time, and the storage area of the memory 14 is effectively used. But It becomes possible.
[0041]
FIG. 7 is a flowchart of history data collection processing by the additional CPU 12 similar to FIG. 6, but shows processing when data necessary for an event sent from the master CPU 11 is not attached. In the figure, the master CPU 11 side determines whether or not an event has occurred in step S6, and if so, the event is sent to the additional CPU 12 side.
[0042]
The additional CPU 12 side receives the event in step S7, and sends a data request to the master CPU 11 in step S8. The master CPU 11 receives this request at step S9 and transmits the requested data to the additional CPU 12 at step S10.
[0043]
The additional CPU 12 receives the data sent in step S11, stores the data in the memory 14 in step S12, and stores the history data and the like in the memory 14 in step S13.
[0044]
FIG. 8 is a flowchart of processing for storing history data and the like in the memory 14 by the additional CPU 12, but processing when data collection is triggered by an event on the additional CPU 12, that is, triggered by a trigger on the additional CPU 12 side. It is. The event in the additional CPU 12 includes, for example, an event that occurs at a constant cycle. When it is determined in step S15 that the event has occurred, a data request is sent to the master CPU 11 in step S16.
[0045]
The master CPU 11 side receives this request at step S17, returns the data to the additional CPU 12 side at step S18, the additional CPU 12 side receives the data at step S19, and stores the data in the memory 14 at step S20. Data and the like are stored in the memory 14 in step S21.
[0046]
FIG. 9 is a flowchart of data acquisition processing on the master CPU 11 side by the additional CPU 12, that is, processing for storing data stored in the memory 13 on the master CPU 11 side in the memory 14 on the additional CPU 12 side.
[0047]
In FIG. 9, processing similar to steps S6 to S11 in FIG. 7 is performed between the master CPU 11 and the additional CPU 12 in steps S25 to S33. For example, all the latest data regarding the setting data is received.
[0048]
As a method for holding data on the additional CPU 12 side, there are a first method for holding initial data and difference history data, and a second method for holding previous data and difference history data. Here, the initial data means all initial setting data, and the previous data means all setting data previously acquired on the additional CPU 12 side.
[0049]
The initial data is not necessarily the first setting data, and the difference after that point may be held. Due to memory constraints, it is often impossible to save all the differences from the first data, and the initial data itself can be updated and stored in memory. wear Handling the oldest data as initial data is efficient in terms of saving memory.
[0050]
Setting data that existed in the past from the initial data to the future when retaining the initial data and difference history data, and from the previous data toward the past when retaining the previous data and difference history data It is possible to restore, that is, reproduce the contents of the change.
[0051]
In FIG. 9, after all the latest setting data is received from the master CPU 11 in step S33, the processes in steps S34 to S37 are performed. When the initial data and the difference history data are held on the additional CPU 12 side here, by restoring the data from the initial data to the future, the previous data, that is, all setting data acquired by the previous additional CPU 12 is restored, This is compared with the latest data acquired from the master CPU 11 side this time, the difference data is obtained, and this latest data is replaced with the previous data, that is, overwritten.
[0052]
FIG. 10 is a flowchart of data acquisition processing from a vending machine by an external terminal. The external terminal 9 in FIG. 2 sends a data request to the additional CPU 12 in step S40 in order to acquire data in the memory 14 in which history data collected by the additional CPU 12 is stored.
[0053]
The additional CPU 12 side receives this request at step S41, reads history data from the memory 14 at step S42, and transmits the read data to the external terminal 9 at step S43. This data is received by the external terminal 9 in step S44, stored in the memory in the external terminal 9 in step S45, and the data is displayed on the display screen of the external terminal in step S46.
[0054]
FIG. 11 is a flowchart of data acquisition processing by an external terminal, and shows processing when history data is stored as a difference in the memory 14 of the additional CPU 12. A request for data is sent from the external terminal 9 to the additional CPU 12 as in step S40 in FIG. 10, and the request is received in step S41.
[0055]
On the additional CPU 12 side, initial data or previous data of various setting data such as product prices stored in the memory 14 and difference history data are read in step S42, and the external terminal 9 is read in step S43. Sent to.
[0056]
On the external terminal 9 side, the data sent in step S44 is received, and in step S47, all data, that is, all data at each time when a change is detected is restored using the initial data and difference history data, and step S48 is performed. In step S49, the data is displayed on the display screen of the terminal 9.
[0057]
Here, the data stored in the memory 14 in step S48 may be all the latest data, in addition to the initial data and the difference history data, or the data itself sent from the additional CPU 12. Here, for example, the initial data of the setting data and the difference history data for the initial data are stored in the memory 14 on the additional CPU 12 side. However, the entire data at a certain point in time is stored instead of the initial data. The history data from that point of time can be stored as the difference history data.
[0058]
FIG. 12 is a flowchart of restoration processing of the collected data stored in the memory 14 on the additional CPU 12 side by the backup processing of FIG. 11 to the memory 13 on the master CPU 11 side. In the figure, with reference to time data stored in the memory of the external terminal 9, for example, setting data at that time is restored to the memory 13 on the master CPU 11 side. Such data restoration is also performed when, for example, various boxes such as the power supply box in FIG. 2 are replaced.
[0059]
In FIG. 12, time data stored in a memory (not shown) of the external terminal 9 is output in step S50, and a data setting request is sent from the external terminal 9 together with the time data to the additional CPU 12 in step S51.
[0060]
The additional CPU 12 side receives this request in step S52, and in step S53, for example, initial data of setting data or previous data and difference history data are output from the memory 14. This difference history data is data to which the time when the difference is taken is also attached. In step S54, a data setting request to the master CPU 11 and initial data or previous data and difference history data are sent.
[0061]
The master CPU 11 receives the data setting request and data from the additional CPU 12 in step S55, sets data in the memory 13 in step S56, and stores the data in the memory 13 in step S57.
[0062]
FIG. 13 shows an example of setting data display results on the screen of the external terminal 9, for example, a PDA. This display is sent from the additional CPU 12 to the PDA as a list of vending machine setting data, and the setting data of the vending machine can be confirmed at a glance according to a free display format of the PDA, and a setting error can be corrected. As a result, it is possible to reduce the labor of the service person as compared with the sequential display and setting operation of the setting data items by the remote controller.
[0063]
In the display example of FIG. 13, the column for each column price corresponds to a vertical shelf in which products, for example, beverage cans are stored, and only one type of product is stored in one column. Is set.
[0064]
The alternating sale means that the same product is stored in two or more columns, and the products are sequentially carried out from a plurality of columns. Corresponding to such alternate sales, combinations of setting data that interfere with each other are set as column-specific prices of a plurality of columns in which the same product is stored.
[0065]
For this reason, for example, because it is sold alternately, it is not possible to change the price setting with only one column, or due to conditions such as the school timer's sales suspension period, for example, it cannot be sold because it is in class, etc. Can be confirmed at a glance. It is not always necessary to display all the setting data. By displaying only a combination of data that is likely to be related to the failure, it is possible to investigate data that may be related to the failure.
[0066]
FIG. 14 is a display example of history data of the operation control state of the vending machine. By sending such operation history data from the additional CPU 12 to, for example, a PDA, the cause of the failure can be identified early and in detail. Also, by acquiring such operation history data, it is possible to create new diagnostic logic, that is, extract knowledge by using the data.
[0067]
In the upper diagram of the display screen of FIG. 14, the temperature rises despite the fan operating after 14:00, and it can be diagnosed that there is some failure. That is, it can be determined that there is an abnormality in the control output for the fan because the temperature has risen despite the motor controller and the fan operating.
[0068]
If troubles of unknown cause occur frequently, it is possible to log the data of places that seem to be related and take it back to the head office / center for analysis, and if the service person cannot repair the trouble, the head office -It is also possible to send data that seems to be related to the center for analysis.
[0069]
FIG. 15 is a display example on the external terminal of the history of the operation control state similar to FIG. In the figure, PC means pick cut and PS means peak shift. The peak shift is, for example, in midsummer when the power consumption reaches a peak at around 2 pm. For example, the cooler is fully moved by 11:00 and the product is sufficiently cooled at around 2 pm Means that the cooler is not moved, that is, the peak is shifted, and the peak cut means that the power consumption around 2 pm is cut. Such PC / PS is called a factor of the operation control state.
[0070]
FIG. 16 is another display example of the driving history data in the external terminal. Here, the history data of the input / output signals to various boxes described in FIG. 2, for example, the power supply box 15 and the slave box 18, or other parts is shown. For example, 2 of the output terminals of the box at 10:30. It is shown that a signal is output from the second pin.
[0071]
FIG. 17 is an explanatory diagram of failure diagnosis by a data mining method based on operation control state history data. In the figure, failure diagnosis for finding the cause of a failure is performed by failure diagnosis by chi-square test, that is, CHAID (chi-square test automatic interaction detector) analysis. As the data mining method, various known methods such as a method using a neuron can be used.
[0072]
In FIG. 17, in order to diagnose a failure in which no product has been produced, first, the signal of the main control box is checked, the difference due to the push button is examined as the first factor, and the A mec as the second factor, for example, FIG. Differences due to the coin mech 16 are examined, and the first checkpoint is analyzed from the history data of 1000 sold products.
[0073]
Next, updating of the failure diagnosis logic of the vending machine described in FIG. 4 will be described. As an example, considering the simple criteria such as the coin-mec, that is, the criteria for determining the cleaning time of a coin discriminator and the timing for replacing the fluorescent lamp, as the failure diagnosis logic, rootman, that is, the product replenisher's daily management work Thus, logic that guides what rootman should do for preventive maintenance can be considered.
[0074]
For example, when the number of coins passing through the coin mech exceeds a preset value, or when the continuous lighting time of the fluorescent lamp exceeds a preset value, the vending machine calls if online. Thus, if it is offline, for example, by notifying the route man as an alarm, it is possible to prompt the root man to clean the coin mech or replace the fluorescent lamp.
[0075]
In this case, the only criterion for determining the coin mech cleaning time is whether or not only the number of passing coins is necessary. Conversely, it is necessary to consider the length of time that the coins do not pass. Since the replacement time of the battery varies significantly depending on the external environment, dimming time setting, etc., it is a difficult problem how to build such logic.
[0076]
That is, as described with reference to FIG. 4, for example, as a result data of failure / repair using a PDA, outdoor temperature, internal temperature, product temperature, fan control status, heater control status, valve control status, motor controller data, master data, etc. The failure code of the CPU is taken, and the failure diagnosis logic can be used to take precautions such as generating an alarm indicating the occurrence of a failure or automatically adjusting the setting data. However, the effectiveness of the failure diagnosis logic is not always clear. In addition, since the contents of the failure differ depending on the season / regionality / model (model number) and the like, a fixed one cannot be used, and frequent updating or addition is necessary.
[0077]
FIG. 18 is an explanatory diagram of such update and development of the failure diagnosis logic. In the figure, analysis results are obtained using data such as failure repair history data, serviceman daily report, help desk, etc., failure diagnosis / preventive maintenance measures are set based on the analysis results, and the measures are logicized, For example, the failure diagnosis logic can be used according to the season, region, model, customer type, etc. by being easily downloaded to the vending machine as a JAVA program. In FIG.
1. B: Bendmec of the analysis result corresponds to Bendmec 21 in FIG.
2. The C: rejection rate of failure diagnosis / preventive maintenance measures corresponds to the strictness of the coin selection criteria.
[0078]
Next, the operation of the vending machine failure diagnosis terminal device according to the present invention will be described. FIG. 19 is an explanatory diagram of an example of failure diagnosis by an external terminal utilizing the diagnosis flow master described in FIG. In the figure, the vending machine and the part format are downloaded from the additional CPU 12 to the PDA, and the corresponding diagnosis flow is displayed on the screen of the external terminal. In response to the flow, the service person inputs yes or no to the determination step in the flow to record which route the service person has taken in the flow. Stored in the case database 45 in the center.
[0079]
In this way, when displaying the diagnosis flow on the external terminal, based on past diagnosis cases, the route that is often used in the diagnosis flowchart is displayed larger and clearer, the route that is not frequently used is displayed smaller, Alternatively, it can be deleted, and a function for adding a new route can be provided.
[0080]
FIG. 20 is an explanatory diagram of an example in which a diagnosis case stored in the case database 45 of FIG. 5 is used on an external terminal. In the figure, on the case search screen, by pressing the details button corresponding to the breakdown contents and main repair contents, the flow of ideal or typical repair response that was performed in the past is displayed, and diagnosis by the service person is performed. It is used effectively.
[0081]
【The invention's effect】
As described above in detail, according to the present invention, the setting data of the vending machine, the history data of the operation control state, etc. are displayed on the mobile terminal, for example, so that the setting data can be changed by the serviceman and the history data can be used. This makes it easier to diagnose failures and greatly reduces the burden on service personnel. Set Can.
[0082]
Also, by bringing back the failure / repair record data collected by the mobile terminal etc. to the management center etc., it becomes possible to use it effectively for development of failure diagnosis software.
[0083]
In addition, it is possible to display the failure diagnosis flow on the terminal device and use the results of determination by the service person for the determination steps on the displayed flow as the diagnosis history, contributing to the improvement of the practicality of the vending machine management system. There is a lot to do.
[Brief description of the drawings]
FIG. 1 is a block diagram showing the principle configuration of the present invention.
FIG. 2 is a block diagram showing a configuration of a vending machine in the present embodiment.
FIG. 3 is an explanatory diagram of a data collection method in a vending machine management system.
FIG. 4 is an explanatory diagram of a failure diagnosis method in the vending machine management system.
FIG. 5 is an explanatory diagram of a diagnostic flow management method in the vending machine management system.
FIG. 6 is a first example of a flowchart of data collection processing by an additional CPU.
FIG. 7 is a second example of a flowchart of data collection processing by the additional CPU.
FIG. 8 is a third example of a flowchart of data collection processing by the additional CPU.
FIG. 9 is a fourth example of a flowchart of data collection processing by the additional CPU.
FIG. 10 is a first example of a flowchart of data acquisition processing by an external terminal.
FIG. 11 is a second example of a flowchart of data acquisition processing by an external terminal.
FIG. 12 is a flowchart of collected data restoration processing;
FIG. 13 is an example of a setting data display result on the screen of the external terminal.
FIG. 14 is a first display example of operation control state history data of a vending machine.
FIG. 15 is a second display example of operation control state history data of a vending machine.
FIG. 16 is a third display example of operation control state history data of a vending machine.
FIG. 17 is an explanatory diagram of failure diagnosis by a data mining method.
FIG. 18 is an explanatory diagram of update and development of failure diagnosis logic.
FIG. 19 is an explanatory diagram of an example of failure diagnosis by an external terminal.
FIG. 20 is an explanatory diagram of an example in which a diagnosis example is used on an external terminal.
[Explanation of symbols]
1,8 Vending machine
2 History data storage means
3 Data output means
4 First central processing unit
5 Second central processing unit
9 External terminal
10 interface
11 Master CPU
12 Additional CPU
13,14 memory
15 Power box
16 Coin Mech
17 Bill Validator
18 Slave box
19 Thermistor
20 Compressor, heater, solenoid valve
21 Bendmek
22 Communication server
23 Network
27 Personal Digital Assistance (PDA)
28 Sales Office PC (PC)
29 DB server
30 database

Claims

History data storage means for storing history data of operation control status of the vending machine and / or setting data;
Data output means for outputting the stored data to an external terminal in a wired or wireless manner;
A first central processing unit for controlling the operation of the vending machine;
Monitoring means for monitoring the operating state of the first central processing unit;
The storage of the history data and / or setting data in the history data storage means, the output of the stored data to the external terminal by the data output means, and the operating state of the first central processing unit by the monitoring means A vending machine comprising a second central processing unit for controlling monitoring .

The vending machine is
The first central processing unit further comprises setting data storage means for storing setting data of the vending machine,
When the data stored in the setting data storage means is deleted, the second central processing unit controls the storage of the setting data stored in the history data storage means in the setting data storage means. The vending machine according to claim 1.

2. The vending machine according to claim 1, wherein the history data storage means further stores a combination of a plurality of setting data that interfere with each other.

2. The vending machine according to claim 1, wherein the history data storage means stores history data for the setting data.

The vending machine is
Software storage means for storing software used in the external terminal;
2. The vending machine according to claim 1, further comprising software download means for downloading the stored software to an external terminal by wire or wirelessly.

The vending machine is
Diagnostic logic storage means for storing fault diagnosis logic of the vending machine;
The failure diagnosis means for performing a failure diagnosis by applying the diagnosis logic stored in the diagnosis logic storage means to the history data stored in the history data storage means. vending machine.

In the terminal device for fault diagnosis of vending machines,
Display means for displaying a flow of fault diagnosis;
An input means for receiving a result of determination for the determination step on the displayed flow;
A vending machine failure diagnosis terminal device comprising storage means for storing a route traced on the flow as a diagnosis history.

In the terminal device,
Further comprising an extracting means for extracting a route having a high number of times traced on the stored diagnosis history;
8. The vending machine failure diagnosis terminal device according to claim 7 , wherein the display means displays the extracted route and another route using different display criteria on the flow.

In a program used by a vending machine comprising a second central processing unit in addition to the first central processing unit controlling the operation of the vending machine,
A procedure for storing history data of operation control status of the vending machine and / or setting data in a memory;
A procedure for outputting the stored data to an external terminal in a wired or wireless manner ;
A program for causing the second central processing unit to execute a procedure for monitoring an operating state of the first central processing unit .