JP2007085604A - 資源供給システムおよびそのプログラム - Google Patents

Abstract

【課題】遠隔制御手段が操作不能になった場合に確実に資源供給手段に伝達し運転状態を変更する。
【解決手段】温水や温風などの資源を供給する資源供給手段と、資源供給手段を操作する遠隔制御手段１と、資源供給手段と遠隔制御手段１との間の制御情報を通信する通信手段とを備え、遠隔制御手段１は、通信手段との通信を制御する通信処理手段１ａｅと、遠隔制御を実行できない事態が発生した場合にそれを検出する異常検出手段１ａｊとを備え、前記異常検出手段１ａｊは異常を検出した場合に通信処理手段１ａｅの通信手段への通信を遮断する。
【選択図】図４

Description

本発明は温水や電力、ガス、水などの資源を機器に供給する資源供給システムおよびそのプログラムに関し、特に資源供給システムを操作する遠隔操作手段の異常発生時における資源供給システムの動作に関連するものである。

従来の資源供給システムについて説明する。従来の資源供給システムのひとつである給湯機では、例えば下記特許文献１では以下のようになっていた。

この従来例では、図１０に示すように、資源供給手段として給湯機能を持つ器具３４を用い、（ａ）に示す第１の無線リモコン３１と（ｂ）に示す第２の無線リモコン３２と通信ユニット３３で構成されている。

通信ユニット３３は図１０（ｃ）に示すように器具３４に取り付け、器具本体内で器具３４の動作を制御したり、今までに使用されたことのある温度やその温度それぞれの使用回数を記憶・カウントする本体制御部３５と接続されている。また第１の無線リモコン３１と第２の無線リモコン３２にはそれぞれ器具３４への指示信号を入力操作する操作部３６，３７、器具の設定状態、運転状態および操作内容の表示を行う報知部３８，３９を備えている。

通信ユニット３３から第１の無線リモコン３１、第２の無線リモコン３２に向けて通信が行われた場合、その通信に対する応答がない時、通信ユニット３３はリトライ機能を有し一定回数の通信リトライを行うが、その一定回数の間に無線リモコンからの応答がない場合、通信ユニット３３のＩＣは第１の無線リモコン３１、第２の無線リモコン３２が通信不能と判断する。

そしてこの時、器具３４の給湯設定温度を、通信ユニット３３のＩＣは本体制御部３５へあらかじめプログラムされた条件の温度への変更信号を出力し、これを受け取った本体制御部３５はプログラムされた条件の温度を本体制御部３５内メモリーより引き出し、給湯設定温度を変更するよう器具３４をコントロールする。

この構成により、無線リモコンのすべてが通信エラーとなった場合、給湯設定温度を、記憶された任意の温度に変更し運転継続することができ、使用者の使用性の向上が図ることができる。
特開平９−１５９２６８号公報

しかしながら、前記従来の構成では、１台の無線リモコンが、通信は可能な状態であるが、給湯設定温度を変更することができないような状態になった場合には、通信が可能であるために、すべてのリモコンが通信不能と判断した場合に用いるあらかじめプログラムされた条件の温度に変更されることがない。

従来、無線リモコンなどの簡単な装置では、制御手段としてワンチップマイコンを使用しシングルタスクで動作させていたため、ソフトウェアが動作不能になった場合には、リモコンのすべての制御が停止し、給湯温度操作が不可となる場合には同時に通信も不可となることが普通であった。

しかし、ＬＩＮＵＸ（登録商標）等のマルチタスクＯＳを用い複数の機能をマルチタスクで動作させるシステムを用いた場合では、給湯操作機能と、無線通信機能を別々のタスクで動作する構成とすると、給湯操作機能が動作不能となっても無線通信機能は機能する場合があり、給湯温度の操作はできないが通信はできる状態が容易に起りうる。

また、給湯操作機能が動作不能かつ無線通信機能が動作する場合であっても、異常発生の状態によっては、正しく通信することができない場合も発生する。

例えば、給湯操作機能が動作不能になった場合に「操作不能」を給湯機に通信する構成を取った場合であっても、通信手段が、給湯機からの通信に対し応答を返信することは可能だが、異常発生を検出したタスクから操作不能の情報を受け取ることができない場合には、「操作不能」を送信できない。

このような場合には、給湯操作機能の動作不能の状態を給湯機へ伝達できず、そのため給湯操作機能のみ動作不能となった場合にあらかじめ記憶された給湯温度に変更し運転を継続させることができないという課題があった。

本発明は、前記従来の課題を解決するもので、資源供給手段を制御する遠隔制御手段の操作機能が使用不可となった場合であっても確実に設定状態をあらかじめ設定された状態へ変更できる資源供給システムおよびそのプログラムを提供することを目的とする。

温水や温風などの資源を供給する資源供給手段と、前記資源供給手段を操作する遠隔制御手段と、前記資源供給手段と前記遠隔制御手段との間の制御情報を通信する通信手段とを備え、前記資源供給手段は、前記通信手段による前記遠隔制御手段との通信の異常を検出する通信異常検出手段と、通信異常を検出した場合に供給する資源の状態を変更する状態変更手段とを備え、前記遠隔制御手段は、前記通信手段との通信を処理する通信処理手段と、遠隔制御を実行できない事態が発生した場合にそれを検出する制御異常検出手段とを備え、前記制御異常検出手段は異常を検出した場合に前記通信処理手段の通信手段への通信を遮断し、前記資源供給手段の前記通信異常検出手段が遮断された通信によって発生する通信異常を検出し、前記状態変更手段により供給する資源の状態を変更するものである。

本発明の資源供給手段およびそのプログラムは、遠隔制御手段が資源供給手段の遠隔制御を実行できない場合でも、通信手段への通信を遮断し、資源供給手段が通信異常検出手段により通信異常を検出して状態変更手段により供給する資源の状態を変更することによって、遠隔制御手段が通信不可の場合に資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第１の発明は、温水や温風などの資源を供給する資源供給手段と、前記資源供給手段を操作する遠隔制御手段と、前記資源供給手段と前記遠隔制御手段との間の制御情報を通信する通信手段とを備え、前記資源供給手段は、前記通信手段による前記遠隔制御手段との通信の異常を検出する通信異常検出手段と、通信異常を検出した場合に供給する資源の状態を変更する状態変更手段とを備え、前記遠隔制御手段は、前記通信手段との通信を処理する通信処理手段と、遠隔制御を実行できない事態が発生した場合にそれを検出する制御異常検出手段とを備え、前記制御異常検出手段は異常を検出した場合に前記通信処理手段の通信手段への通信を遮断し、前記資源供給手段の前記通信異常検出手段が遮断された通
信によって発生する通信異常を検出し、前記状態変更手段により供給する資源の状態を変更する。

これによって、遠隔制御手段が資源供給手段の遠隔制御を実行できない場合でも、通信手段への通信を遮断し、資源供給手段が通信異常検出手段により通信異常を検出して状態変更手段により供給する資源の状態を変更することによって、万一、遠隔制御手段が通信不可となっても資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第２の発明は、遠隔制御手段は操作手段を備え、異常検出手段は前記操作手段の異常を検出することにより、操作手段が操作不可となり、遠隔制御手段から資源供給手段を操作できない状態になった場合でも供給する資源の状態を変更することが可能で、万一、操作手段が操作不可となっても資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第３の発明は、遠隔制御手段は通信制御手段を備え、異常検出手段は前記通信制御手段の異常を検出することにより、通信制御手段が処理不可となり遠隔制御手段の操作を資源供給手段に送信できない場合でも供給する資源の状態を変更することが可能で、万一、通信制御手段が処理不可となっても資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第４の発明は、遠隔制御手段は表示手段を備え、異常検出手段は前記表示手段の異常を検出することにより、表示手段が処理不可となり遠隔制御手段の状態を使用者が判別不能になった場合でも、供給する資源の状態を変更することが可能で、万一、表示手段が処理不可となっても資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第５の発明は、異常検出手段は異常を検出した場合に通信処理手段に対し通信手段への送受信を停止させることにより、資源供給手段が通信手段を通じて遠隔操作手段へ通信電文を送信しても遠隔操作手段から反応がなく、また、遠隔制御手段からの電文も受信しないので、資源供給手段に対し遠隔制御手段が存在しないと確実に判断させることができ、資源供給手段が供給する資源の状態を変更することができるので、確実に資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第６の発明は、異常検出手段は異常を検出した場合に通信処理手段に対し通信手段の受信に対する返信を停止させることにより、資源供給手段が通信手段を通じて遠隔操作手段へ通信電文を送信しても遠隔操作手段から反応がないので、資源供給手段に対し遠隔制御手段が存在しないと確実に判断させることができ、資源供給手段が供給する資源の状態を変更することができるので、確実に資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第７の発明は、異常処理手段は異常を検出した場合に通信処理手段を削除することにより、資源供給手段が通信手段を通じて遠隔操作手段へ通信電文を送信しても遠隔操作手段から反応がなく、また、遠隔制御手段からの電文も受信しないので、資源供給手段に対し遠隔制御手段が存在しないと確実に判断させることができ、資源供給手段が供給する資源の状態を変更することができるので、確実に資源供給手段が供給する資源の状態を所定の状態へ変更することができる。

第８の発明は、特に、第１〜７のいずれか１つの発明の資源供給システムの機能の少なくとも一部をコンピュータに実現させるためのプログラム。そして、プログラムであるの
で電気・情報機器、コンピュータ、サーバ等のハードリソースを協働させて本発明の資源供給システムの少なくとも一部を容易に実現することができる。また記録媒体に記録したり通信回線を用いてプログラムを配信したりすることでプログラムの配布やインストール作業が簡単にできる。

以下、本発明の実施の形態について図面を用いて説明する。なお、この実施の形態によって本発明が限定されるものではない。

（実施の形態１）
本発明の実施の形態１の資源供給システムを図面とともに説明する。

実施の形態１の資源供給システムはガス給湯システムに用いた例を示す。

図１は本発明の実施の形態１の資源供給システムの全体ブロック図、図２は遠隔制御手段である台所リモコンの詳細ブロック図、図３は台所リモコンの外観図、図４は台所リモコン制御手段のソフトウェア構成図、図５は浴室リモコンの詳細ブロック図、図６は熱源機の詳細ブロック図、図７は台所リモコンの給湯操作画面図、図８は台所リモコンの給湯操作画面図、図９は台所リモコンの監視プロセスのプロセス監視フローチャート遠隔制御手段である。

図１に示すように本実施の形態の資源供給システムは、遠隔制御手段である台所リモコン１、浴室リモコン２、資源供給手段である熱源機３から構成される。

台所リモコン１と浴室リモコン２と熱源機３との間は通信手段である熱源機制御通信手段１１により接続されて台所リモコン１及び浴室リモコン２から熱源機３の操作を行なうとともに、台所リモコン１及び浴室リモコン２に熱源機３の運転状況のモニター表示を行なえるようにしている。また、熱源機３から定期的に電文を送信し、熱源機３の状態を台所リモコン１、浴室リモコン２へ通知し、万一異なっていた場合には熱源機３の状態に合わせるとともに、台所リモコン１、浴室リモコン２と正常に通信できることにより両者が存在しているかどうか確認している。

上記のうち、台所リモコン１は図２のように、台所リモコン１を制御する台所リモコン制御手段１ａ、台所リモコン１を操作する台所リモコン操作手段１ｂ、熱源機３の動作状況など必要な情報を表示する台所リモコン表示手段１ｃ、あらかじめ登録されたデータや台所リモコン１から受信したデータを記憶する台所リモコン記憶手段１ｄ、浴室リモコン２や熱源機３と通信して熱源機を制御するための通信を行なう台所リモコン熱源機通信手段１ｅとからなる。

なお、台所リモコン操作手段１ｂには図３のように、給湯運転を開始または停止操作する給湯運転ボタン１ｂａ、ふろ自動の開始または停止を操作するふろ自動ボタン１ｂｂと、および、表示手段１ｃの画面表面に配置された透明なタッチパネル１ｂｃとからなる。図中破線の範囲をタッチすると、タッチパネル１ｂｃはタッチされた座標情報を出力し、透過して表示される画面の表示と合わせて任意にスイッチを配置することが可能となっている。

次に、台所リモコン制御手段１ａのソフトウェア構成について説明する。図４に本実施の形態の台所リモコンのソフトウェア構成図を示す。これらのソフトウェアは台所リモコン制御手段１ａで動作している。

これらはマルチタスクＯＳであるＬｉｎｕｘ（登録商標）ＯＳ１ａａを用いて動作し、
ＯＳ１ａａの上部下部で様々なプロセスを動作させている。

まず、ＯＳ１ａａの下部で動作するドライバ類は、台所リモコン操作手段１ｂによる操作を受け付けるための操作ドライバ１ａｂ、台所リモコン表示手段１ｃに表示するための表示ドライバ１ａｃ、台所リモコン記憶手段１ｄとのデータを入出力するメモリドライバ１ａｄ、台所リモコン熱源機通信手段１ｅとの通信を行なう通信処理手段である通信ドライバ１ａｅとからなる。

次に、ＯＳ１ａａ上で動作するミドルプロセスとしては、操作ドライバ１ａｂからの入力によりメモリドライバ１ａｄから表示手段１ｃへ表示するためのデータを呼び出し、表示ドライバ１ａｃへの出力して表示手段１ｃに表示させることにより画面とタッチパネル１ｂｃ等の操作手段１ｂによる操作を制御する操作手段であるＧＵＩミドルプロセス１ａｆ、通信ドライバ１ａｅとＯＳ１ａａを通じて送受信し浴室リモコン２や熱源機３との熱源機制御通信１１を実行する通信制御手段である通信管理ミドルプロセス１ａｇとからなる。

また、ミドルプロセスの上位のアプリケーションは給湯温度の上下操作を行なったり、表示手段１ｃへの給湯温度表示画面の表示を行なう操作手段である給湯操作プロセス１ａｈ、ふろ温度やふろ湯量の操作や表示手段１ｃへのふろ設定画面の表示を行なうふろ操作プロセス１ａｉとかならなり、これらは操作手段１ｂの操作情報や表示手段１ｃへ表示させる表示情報をＧＵＩミドルプロセス１ａｆと送受信し、また、操作された結果を熱源機へ送信したり、浴室リモコン２や熱源機３で変更された状態を受信するために通信管理ミドルプロセス１ａｇとを相互に通信している。

さらに、通信管理ミドルプロセス１ａｇと給湯操作プロセス１ａｈとを監視し、異常を検出した場合に通信ドライバ１ａｅの機能を停止させる異常検出手段である監視プロセス１ａｊが存在する。台所リモコン１では、台所リモコン制御手段１ａにおいてこれらの各プロセスが動作し、台所リモコン１の制御全般を行なっている。

また、浴室リモコン２は図５のように、浴室リモコン２を制御する浴室リモコン制御手段２ａ、浴室リモコン２を操作する浴室リモコン操作手段２ｂ、熱源機３の動作状況など必要な情報を表示する浴室リモコン表示手段２ｃ、あらかじめ登録されたデーターや台所リモコン１から受信したデータを記憶する浴室リモコン記憶手段２ｄ、熱源機制御通信手段１１を通じて台所リモコン１や熱源機３と通信して熱源機の制御を行なうための通信を行なう浴室リモコン熱源機通信手段２ｅとからなる。浴室リモコン制御手段２ａは台所リモコン１とは異なり、ＯＳを用いずシングルタスクで動作する。

また、熱源機３は図６のように、熱源機３を制御する熱源機制御手段３ａ、熱源機制御通信手段１１を通じて台所リモコン１および浴室リモコン２と通信して操作情報の受信や運転状況の送信を行なう熱源機リモコン通信手段３ｂ、熱源機制御手段３ａの指示により温水を生成する熱交換器３ｃ、熱交換器の温水の流量を検出する流量センサ３ｄ、熱交換器３ｃの燃焼の有無を検出する燃焼センサ３ｅ、ふろの湯量を検出するふろ湯量センサ３ｆ、ふろの湯温を検出するふろ湯温センサ３ｇ、給湯温水配管に接続しカランやシャワーなどに温水を給湯する給湯温水供給手段３ｉ、ふろ温水配管に接続しふろの湯沸しや追い炊きを行うふろ温水供給手段３ｊとからなる。

なお、熱源機制御手段３ａは、熱源機リモコン通信手段３ｂの出力から、台所リモコン１および浴室リモコン２と正しく通信しているかどうかを監視し、通信異常が発生した場合に検出する通信異常検出手段３ａ１と、通信異常検出手段の出力により、台所リモコン１および浴室リモコン２共に通信異常となっている場合に、給湯温度を変更する状態変更
手段３ａ２を備えている。

以上の構成による動作作用を示す。

熱源機設置住宅の住人が台所で温水を利用する場合、まず図３の台所リモコン操作手段１ｂの給湯運転ボタン１ｂａを押すと、給湯機３が運転を開始させる。運転ボタン１ｂａを押して給湯運転ＯＮさせる指示は、まず、給湯運転ボタン１ｂａが操作されたことを操作手段１ｂが操作ドライバ１ａｂへ通知し、操作ドライバ１ａｂがＯＳ１ａａを経てＧＵＩミドルプロセスへ通知し、さらに、ＧＵＩミドルプロセスが、給湯操作プロセス１ａｈへ通知する。

給湯操作プロセス１ａｈは、給湯運転ボタンが操作された情報を受信すると、現在の運転状態が給湯運転ＯＦＦであれば給湯運転ＯＮに変更し、表示手段１ｃに表示すると共に、通信管理ミドルプロセス１ａｇへ通知する。

通信管理ミドルプロセス１ａｇは、受信した給湯運転開始の情報を給湯機への通信電文に構成し、通信電文をＯＳ１ａａを通じて通信ドライバ１ａｅへ送信する。

通信ドライバ１ａｅは通信電文を熱源機通信手段１ｅに送り、熱源機制御通信手段１１により熱源機３へ送信し、熱源機３は熱源機リモコン通信手段３ｂにより受信した給湯運転ＯＮ指示の電文により熱源機制御手段３ａが熱源機の給湯運転をＯＮにする。

給湯運転ＯＮの状態で、台所の給湯温水のカラン（図示せず）を開くと熱源機の給湯温水供給手段３ｉが動作し上水道から供給された水が熱交換器３ｃを流れ、流量センサ３ｄが熱交換器の給湯温水路の水流を検出して熱交換器を点火し燃焼による給湯用温水の生成を開始する。

熱交換器３ｃで生成された給湯温水は住宅内の給湯温水配管を経て台所のカランから流出する。カランを閉じると流量センサ３ｄが水流の停止を検出し、熱交換器３ｃを消火し給湯温水の生成を停止する。なお、給湯運転ＯＦＦの状態では、カランを開いても熱交換器を点火せず温水ではなく上水道をそのまま供給する。

次に、台所リモコンから給湯温度を変更する場合について示す。図７に台所リモコン１の給湯温度を変更する場合に表示手段１ｃに表示される給湯温度設定画面１ｃａを示す。

図中の表示は、給湯温度表示１ｃａａ、給湯温度表示を示すカランマーク１ｃａｂ、給湯温度減少ボタン１ｃａｃ、給湯温度増加ボタン１ｃａｄ、ふろ温度表示１ｃａｅ、ふろ温度表示を示すふろマーク１ｃａｆ、ふろの設定画面を呼び出すふろ設定ボタン１ｃａｇである。給湯温度減少ボタン１ｃａｃ、給湯温度増加ボタン１ｃａｄ、ふろ設定ボタン１ｃａｇは、タッチパネル１ｄｃと連動しており、タッチパネル１ｄｃが操作されると操作ドライバ１ａｂに対しＯＮ情報と操作された座標の情報とが入力され、ＬｉｎｕｘＯＳ１ａａを通じてＧＵＩミドルプロセス１ａｆに入力される。

ＧＵＩミドルプロセス１ａｆでは得られた座標から、現在画面に表示されている３つのボタンのうちどのボタン押されたかを判定し、操作された情報を必要なプロセスに通知している。給湯温度減少増加ボタン１ｃａｂ、給湯温度増加ボタン１ｃａｃがタッチされた場合には、ＧＵＩミドルプロセス１ａｆは給湯操作プロセス１ａｈへ通知し、ふろ設定ボタン１ｃａｇがタッチされた場合には、ふろ操作プロセス１ａｉへ通知している。

この熱源機では、給湯温度の設定を３２度℃、３５℃、３８℃、３９℃、４０℃、４１
℃、４２℃、４３℃、４４℃、４５℃、４６℃、４７℃、６０℃、７５℃の１４段階に設定可能としており、給湯温度減少ボタン１ｃａｃを押して離すと１段階温度が下がり、給湯温度増加ボタン１ｃａｄを押して離すと１段階温度が上昇する。

この画面で設定された温度は通信管理ミドルプロセス１ａｇへ通知され、通信管理ミドルプロセス１ａｇでは受信した給湯温度の情報を給湯機への通信電文に構成し、通信電文をＯＳ１ａａを通じて通信ドライバ１ａｅへ送信する。通信ドライバ１ａｅは通信電文を熱源機通信手段１ｅに送り、熱源機制御通信手段１１により熱源機３へ送信し、熱源機３は熱源機リモコン通信手段３ｂにより受信した給湯温度変更の電文により熱源機制御手段３ａが熱源機の給湯温度を設定する。

一方、ふろを沸かす場合では、図３に示す台所リモコン操作手段１ｂのふろ自動ボタン１ｂｂを押すと、ふろ自動運転を開始する。ふろ自動ボタン１ｂｂを押してふろ自動運転を開始させる指示は次のようにして伝達される。

まず、ふろ自動ボタン１ｂｂが操作されたことを、操作手段１ｂが操作ドライバ１ａｂへ通知し、操作ドライバ１ａｂがＯＳ１ａａを経てＧＵＩミドルプロセス１ａｆへ通知し、さらに、ＧＵＩミドルプロセス１ａｆが、ふろ操作プロセス１ａｉへ通知する。

ふろ操作プロセス１ａｉはふろ自動ボタン１ｂｂが操作された情報を受けて、現在ふろ自動中でなければふろ自動を開始することを決定し、ふろ自動が開始されたことを表示手段１ｃに表示すると共に、通信管理ミドルプロセス１ａｇへ通知し、通信管理ミドルプロセス１ａｇは、受信したふろ自動開始の情報を給湯機への通信電文に構成し、通信電文をＯＳ１ａａを通じて通信ドライバ１ａｅへ送信する。

通信ドライバ１ａｅは通信電文を熱源機通信手段１ｅに送り、熱源機制御通信手段１１により熱源機３へ送信し、熱源機３は熱源機リモコン通信手段３ｂにより受信したふろ自動開始指示の電文により熱源機制御手段３ａが熱源機のふろ自動運転を開始する。

ふろ自動では、ふろ湯量センサ３ｆが検出したふろの残り湯の状況に応じて水量が設定水量に足りない場合は給湯温水供給手段３ｉからふろ温水配管へ温水を供給しながらあらかじめ設定された水量のお湯を張り、ふろ温水供給手段３ｊにより温水を循環させてふろ湯温をあらかじめ設定された温度に調整し、ふろ湯量センサ３ｆがあらかじめ設定された水量と湯温に到達したことを検出するとお湯張りが完了して保温へ移行する。

保温では、ふろ湯温センサ３ｇにより湯温の低下を検出するとふろにたまっているお湯をふろ温水配管からふろ温水供給手段３ｊを通じて熱交換器３ｃへ導いて循環させ湯温を上げる追い炊きを行ない、設定された湯温に戻ると追い炊きを停止する、という動作を繰り返し、あらかじめ設定された保温時間の間、この動作を継続する。

このような熱源機３の動作内容は熱源機制御通信手段１１により熱源機３から台所リモコン１および浴室リモコン２へ送信され、台所リモコン１と浴室リモコン２では台所リモコン熱源機通信手段１ｅ、浴室リモコン熱源機通信手段２ｅが受信したデータに基づき、熱源機３の運転状況に応じた表示を台所リモコン表示手段１ｃ、浴室リモコン表示手段２ｃに行なう。

カランから出湯するお湯の温度、ふろ自動で用いるお湯張り水量、温度はあらかじめ台所リモコン１または浴室リモコン２の各リモコン操作手段により入力されて熱源機３へ送信され、熱源機記憶手段３ｌにより設定値を記憶する。浴室リモコン２または台所リモコン１で設定されるたびに熱源機３に送信され、新しい設定値が送信されるたびに設定値を
入れ替える。

次に、台所リモコンからふろ自動で実現する、ふろ温度、ふろ湯量の設定を変更する場合について示す。

図８に台所リモコン１のふろ温度、ふろ湯量を変更する場合に表示手段１ｃに表示されるふろ設定画面１ｃｂを示す。この画面は図７のふろ設定ボタン１ｃａｇを操作することにより、ＧＵＩミドルプロセス１ａｆがふろ操作プロセス１ａｉに通知し、ふろ操作プロセス１ａｉが、ふろ設定画面１ｃｂを表示させるようにＧＵＩミドルプロセス１ａｆに通知し、ＧＵＩミドルプロセス１ａｆはＬｉｎｕｘＯＳ１ａａと表示ドライバ１ａｃを通じて表示手段１ｃにふろ設定画面１ｃｂを表示させる。

図中の表示は、水位表示１ｃｂａ、水位表示を示す水位ラベル１ｃｂｂ、水位減少ボタン１ｃｂｃ、水位増加ボタン１ｃｂｄ、ふろ温度表示１ｃｂｅ、ふろ温度表示を示す温度ラベル１ｃａｆ、ふろ温度減少ボタン１ｃｂｇ、ふろ温度増加ボタン１ｃｂｈ、給湯温度設定画面１ｃａへ戻るための戻るボタン１ｃｂｉである。

ふろ水位減少ボタン１ｃｂｃ、ふろ水位増加ボタン１ｃｂｄ、ふろ温度減少ボタン１ｃｂｇ、ふろ水位増加ボタン１ｃｂｈ、戻るボタン１ｃｂｉは、タッチパネル１ｄｃと連動しており、タッチパネル１ｄｃが操作されると操作ドライバ１ａｂに対しＯＮ情報と操作された座標の情報とが入力され、ＯＳ１ａａを通じてＧＵＩミドルプロセス１ａｆに入力される。ＧＵＩミドルプロセス１ａｆでは得られた座標から、現在画面に表示されている５つのボタンのうちどのボタン押されたかを判定し、操作された情報を必要なプロセスに通知している。

ふろ水位減少増加ボタン１ｃａｂ、ふろ水位増加ボタン１ｃａｃ、ふろ温度減少増加ボタン１ｃａｇ、ふろ温度増加ボタン１ｃａｈがタッチされた場合には、ＧＵＩミドルプロセス１ａｆはふろ操作プロセス１ａｉへ通知し、戻るボタン１ｃｂｉがタッチされた場合には、給湯操作プロセス１ａｈへ通知している。

この熱源機では、ふろ水位を１から１０の１０段階、ふろ温度の設定を３８℃から４８℃まで１℃間隔で設定可能としており、それぞれ、ふろ水位温度減少ボタン１ｃｂｃまたはふろ温度減少ボタン１ｃｂｇを押して離すと１段階ふろ水位、またはふろ温度が下がり、ふろ水位増加ボタン１ａｂｄ、またはふろ温度増加ボタン１ｃｂｈを押して離すと１段階ふろ水位またはふろ温度が上昇する。この画面で設定された水位または温度はふろ操作プロセス１ａｉから通信管理ミドルプロセス１ａｇへ通知され、通信管理ミドルプロセス１ａｇでは受信したふろ水位またはふろ温度の情報を熱源機への通信電文に構成し、通信電文をＯＳ１ａａを通じて通信ドライバ１ａｅへ送信する。

通信ドライバ１ａｅは通信電文を熱源機通信手段１ｅに送り、熱源機制御通信手段１１により熱源機３へ送信し、熱源機３は熱源機リモコン通信手段３ｂにより受信したふろ水位またはふろ温度変更の電文により熱源機制御手段３ａが熱源機のふろ水位、またはふろ温度の設定を変更する。

なお、戻るボタン１ｃｂｉが押された場合には、ＧＵＩミドルプロセス１ａｆは給湯操作プロセス１ａｈに通知し、給湯操作プロセス１ａｈは、給湯操作画面１ｃａを表示させるようにＧＵＩミドルプロセス１ａｈに通知し、ＧＵＩミドルプロセス１ａｈはＯＳ１ａａと表示ドライバ１ａｃを通じて表示手段１ｃに給湯操作画面１ｃａを表示させる。

一方、熱源機３は、台所リモコン１や浴室リモコン２に対し、熱源機の状態を間違いな
く反映させること、および、すべてのリモコンとの通信が正常に行なわれていることを確認するために、定期的に熱源機から各リモコンに対して電文を送信している。

本実施の形態の資源供給システムでは、１分に１回電文を送信し、台所リモコン、浴室リモコンは正しく受信できた場合には、熱源機に対し返信するようにしている。もし、台所リモコンとふろ温度や給湯温度などの状態が異なっている場合には、台所リモコンは熱源機の状態に変更する。

また、熱源機からの定期的な電文受信に対して、台所リモコン１、または浴室リモコン２からの返信がない場合には、熱源機は、返信のないリモコンに対して電文を再送し、一定回数再送しても返信がない場合に、そのリモコンが切断されたと判定する。

熱源機は、通信異常検出手段３ａ１がすべてのリモコンが切断されたと判断した場合、状態変更手段３ａ２が、給湯運転をＯＦＦにするようにしている。これは、すべてのリモコンが切断された場合、給湯温度を操作することができなくなるためであり、このような異常な状況になった場合に供給する資源の状態を変更して給湯運転をＯＦＦしカランを開いても温水が出ないようにすることができる。

なお、給湯運転ＯＦＦはいずれかのリモコンとの通信が復帰するまで継続し、その間、リモコンから運転ＯＮの操作をしても運転ＯＦＦのままである。

本実施の形態の台所リモコン１は上記の通り、マルチタスクＯＳを使用しているために、必要な操作を必要なプロセスにのみ通知し、それぞれのプロセスが独立に動作して操作を実現するようにしている。そのため、プログラム上のバグ等でいずれかのプロセスが停止してしまった場合でも、そのプロセス以外のプロセスは正常動作する。

従って、例えば、給湯操作プロセス１ａｈが停止してしまった場合であっても、通信管理ミドルプロセス１ａｇは正常に動作する。

本実施の形態の資源供給システムでは、熱源機３からの定期的な電文に対する返信は、通信ドライバ１ａｅが実行しており、たとえ給湯操作プロセス１ａｈが異常となり、給湯温度を変更できなくなった場合であっても、熱源機３からの定期的な通信に対して正常に返信するために、熱源機３は異常を検出できない。この状態でふろリモコン２に異常が発生し、通信不可となって切断されてしまうと、熱源機３は、台所リモコン１が正常と認識しているために自動的に運転を切にすることができず、給湯温度を変更できない状態が継続してしまう。

これは、通信管理ミドルプロセス１ａｇが異常となった場合も、操作結果を熱源機３へ送信して反映させることができないため、同じ状況となってしまう。

本実施の形態の台所リモコン１では、この問題を解決するために、ＯＳ１ａａ上で動作する監視プロセス１ａｊを設け、ＧＵＩミドルプロセス１ａｆ、給湯操作プロセス１ａｈと通信管理ミドルプロセス１ａｇとを監視し、異常が発生した場合に通信ドライバ１ａｅを機能停止させる。監視プロセス１ａｊの異常監視は、ＧＵＩミドルプロセス１ａｆ、給湯操作プロセス１ａｈ、および通信管理ミドルプロセス１ａｇの３つのプロセスに対し、それぞれ定期的に通信を行ない、それに対して受信したプロセスが返信を返すかどうかで確認している。

図９に監視プロセスの異常監視のフローチャートを示す。異常監視が開始（２０ａ）されると、まず、指定されたプロセスに対し電文を送信（２０ｂ）し、一定時間内に返信が
あるかどうかを確認する（２０ｃ）。一定時間内に返信を受信すれば正常として指定プロセスbusy回数クリア（２０ｄ）を行なうが、一定時間内に返信がない場合には、返信なし回数をカウント（２０ｅ）し、カウント値が既定値以下であれば、再度指定プロセスへ電文送信（２０ｂ）を行なう。

カウント値が既定値以上であればbusyとし、busy回数カウントを行ない（２０ｇ）、busy回数を既定値と比較する（２０ｈ）。busy回数が既定値以上であれば、指定プロセスが異常と判定（２０ｉ）して処理終了し、既定値以下であればそのまま処理を終了する。

図９で指定プロセスは、ＧＵＩミドルプロセス１ａｇ、給湯操作プロセス１ａｈと通信管理ミドルプロセス１ａｋであり、それぞれ別々に再送、busy回数をカウントする。監視プロセス１ａｊは図９に示す処理を１０分間隔で前記３つのプロセスに対して監視処理を行ない、３回連続して返信がなければbusyとしてbusy回数をカウントし、３回連続してbusyとなりbusy回数カウントが３になった時点で、当該プロセスが異常と判定する。

また、busy後に返信があればbusy回数カウントをクリアし、異常が長時間継続している時にのみ異常と判定している。これにより、一時的な異常により異常と検出しないようにできる。なお、返信なし回数カウントはこの処理を開始する前にクリアされている。

上記により監視プロセス１ａｊが異常を検出した場合、監視プロセス１ａｊは通信ドライバ１ａｅに対し通信機能ＯＦＦの通知を送信し、通信ドライバ１ａｅは熱源機から受信した電文への返信を行なわないようにする。

通信ドライバ１ａｅは通常であれば、熱源機３から受信した電文にあらかじめ決められた返信電文を熱源機３へ送信し、熱源機３はこの返信電文を受信して台所リモコンが存在することを認識する。

一方で、通信ドライバ１ａｅは、監視プロセス１ａｊからの通信機能ＯＦＦの通知を受信すると熱源機３から受信した電文への返信を行なわないようにするようにしている。

これによって、熱源機３からの定期的な通信に対し、返信を送ることがなくなるので、熱源機３は通信異常検出手段３ａ１によって台所リモコンが通信異常と判断し切断された状態であることを認識することができる。

以上のような構成により、ＧＵＩミドルプロセス１ａｇに異常が発生し画面とタッチパネル、ハードボタン等の操作ができなくなった場合、給湯機能プロセス１ａｈに異常が発生し台所リモコン１が給湯機能を操作できなくなった場合、または、通信管理ミドルプロセス１ａｇに異常が発生し給湯操作内容を熱源機３へ送信でない場合に、通信ドライバ１ａｅを通信機能ＯＦＦとし熱源機３からの定期的な電文送信に返信しないようにできる。従って、熱源機３が台所リモコン１と通信不可であり接続されてないと判断することができ、同時に浴室リモコン２も通信不可となり切断された状態であれば、熱源機３では通信異常検出手段３ａ１が台所リモコン１と浴室リモコン２の両方が通信異常であることを検出し、状態変更手段３ａ２が状態変更して給湯運転をＯＦＦすることになり、カランから温水を出さないようにすることができ、確実に状態を変更することができる。

なお、上記実施の形態の資源供給システムでは、ＧＵＩミドルプロセス１ａｇ、給湯機能プロセス１ａｈと通信管理ミドルプロセス１ａｇについて監視を行なっているが、これに加え、表示ドライバ１ａｃに付いて監視を行なってもよい。表示ドライバ１ａｃが異常となった場合には、表示手段１ｃへ画面表示ができないので、現在の状態がわからない。従って、使用者が給湯温度を知らずにお湯を使ってしまうことを防止するために有効であ
る。

また、上記実施の形態の資源供給システムでは、熱源機は、すべてのリモコンと通信不可となり、切断されてしまったと判断した場合に給湯運転をＯＦＦにするが、状態変更として例えば３５℃といったあらかじめ決められた温度に強制的に変更する構成でもよい。

また、上記実施の形態の資源供給システムでは、通信ドライバ１ａｅが通信機能ＯＦＦの通知を受けると熱源機３から受信した電文への返信を行なわないようにしているが、台所リモコン１から熱源機３への送信を拒否することはしていない。これは、給湯操作プロセス等の異常が発生すると基本的に電文の熱源機への送信が行われないため拒否する必要がないためである。

ただし、どのような異常が発生するかはわからず、電文を送信しつづけてしまうような異常が発生する場合も考えられるため、これを考慮し、送受信ともに行なわない構成としてもよい。

また、上記実施の形態の資源供給システムでは、通信ドライバ１ａｅが通信機能ＯＦＦの通知を受けると熱源機から受信した電文への返信を行なわないようにしているが、監視プロセス１ａｊを異常検出後も継続的に動作させ監視プロセス１ａｊが正常に復帰したことを検出した場合に、通信ドライバ１ａｅの通信機能をＯＮにして再度通信可能とする構成でもよい。この場合、busy回数を３回とせず１回で異常確定とし、監視プロセスの異常監視の検出レベルを低下させて、少しの異常でも異常として検出する構成も可能となる。

逆に、監視プロセス１ａｊが異常と判定した場合に、通信ドライバ１ａｅ単独、もしくは通信ドライバ１ａｅと通信管理ミドルプロセス１ａｈの両方を削除する構成としてもよい。監視プロセス１ａｊが検出する異常は、通常ではありえない内容であるので、これによってより確実に熱源機３への通信を遮断することができる。

また、本実施の形態の資源供給システムは、ガス給湯システムの台所リモコンを例として表記しているが、家庭内、事務所内等で電気、温水、ガス、水などを供給するシステムにおいて端末機器を遠隔操作できるシステムであればいかなる用途であっても適用できる。

上記実施の形態に述べた資源供給システムにより、温水に限らず、電力、ガス、水力などの資源を端末機器に供給し利用するシステムにおいて、情報端末から端末機器を操作するための操作手段を構成することができ、使いやすい資源供給システムを提供できる。

なお、本実施の形態で説明した手段は、ＣＰＵ（またはマイコン）、ＲＡＭ、ＲＯＭ、記憶・記録装置、Ｉ／Ｏなどを備えた電気・情報機器、コンピュータ、サーバー等のハードリソースを協働させるプログラムの形態で実施してもよい。プログラムの形態であれば、磁気メディアや光メディアなどの記録媒体に記録したりインターネットなどの通信回線を用いて配信することで新しい機能の配布・更新やそのインストール作業が簡単にできる。

以上のように本発明にかかる資源供給システムおよびそのプログラムは、資源供給手段を制御する遠隔制御手段の操作機能が使用不可となった場合であっても確実に資源供給手段の状態を変更できる。また、温水を用いた給湯暖房システムに限らず、電力、ガス、水力、石油燃料などの資源を端末機器に供給し利用するシステムにおいても利用可能である。

本発明の実施の形態１における資源供給システムの概要ブロック図 同システムの台所リモコン（遠隔制御手段）の詳細ブロック図 同システムの台所リモコン（遠隔制御手段）の外観図 同システムの台所リモコン（遠隔制御手段）の制御手段のプロセス構成図 同システムの浴室リモコンの詳細ブロック図 同システムの熱源機の詳細ブロック図 同システムの台所リモコン（遠隔制御手段）の給湯操作画面図 同システムの台所リモコン（遠隔制御手段）のふろ操作画面図 同システムの台所リモコン（遠隔制御手段）の監視プロセスのプロセス監視フローチャート 従来の暖房給湯システムのフローチャート

符号の説明

１ 台所リモコン（遠隔制御手段）
１ａｅ 通信ドライバ（通信処理手段）
１ａｆ ＧＵＩミドルプロセス（操作手段）
１ａｇ 通信管理ミドルプロセス（通信制御手段）
１ａｈ 給湯操作プロセス（操作手段）
１ａｊ 監視プロセス（異常検出手段）
１ｃ 台所リモコン表示手段（表示手段）
３ 熱源機（資源供給手段）
３ａ１ 通信異常検出手段
３ａ２ 状態変更手段
１１ 熱源機制御通信手段（通信手段）

Claims (8)

1. 温水や温風などの資源を供給する資源供給手段と、前記資源供給手段を操作する遠隔制御手段と、前記資源供給手段と前記遠隔制御手段との間の制御情報を通信する通信手段とを備え、
   前記資源供給手段は、前記通信手段による前記遠隔制御手段との通信の異常を検出する通信異常検出手段と、通信異常を検出した場合に供給する資源の状態を変更する状態変更手段とを備え、
   前記遠隔制御手段は、前記通信手段との通信を処理する通信処理手段と、遠隔制御を実行できない事態が発生した場合にそれを検出する制御異常検出手段とを備え、前記制御異常検出手段は異常を検出した場合に前記通信処理手段の通信手段への通信を遮断し、
   前記資源供給手段の前記通信異常検出手段が遮断された通信によって発生する通信異常を検出し、前記状態変更手段により供給する資源の状態を変更する資源供給システム。
2. 遠隔制御手段は操作手段を備え、異常検出手段は前記操作手段の異常を検出して通信を遮断する請求項１に記載の資源供給システム。
3. 遠隔制御手段は通信制御手段を備え、異常検出手段は前記通信制御手段の異常を検出して通信を遮断する請求項１に記載の資源供給システム。
4. 遠隔制御手段は表示手段を備え、異常検出手段は前記表示手段の異常を検出して通信を遮断する請求項１に記載の資源供給システム。
5. 異常検出手段は異常を検出した場合に通信処理手段に対し通信手段への送受信を停止させる請求項１ないし４のいずれか１項に記載の資源供給システム。
6. 異常検出手段は異常を検出した場合に通信処理手段に対し通信手段の受信に対する返信を停止させる請求項１ないし４のいずれか１項に記載の資源供給システム。
7. 異常処理手段は異常を検出した場合に通信処理手段を削除する請求項１ないし５のいずれか１項に記載の資源供給システム。
8. 請求項１〜７のいずれか１項記載の資源供給システムの少なくとも一部をコンピュータに実現させるためのプログラム。