JP7473704B1 - 警報器 - Google Patents

Abstract

【課題】適宜に新たな制御方式を取り入れることが可能な警報器を提供する。【解決手段】実施形態の警報器１００は、周囲環境を監視して監視結果に基づく報知、及び外部機器との交信を行う警報器である。警報器１００は、監視結果に基づく報知及び外部機器Ｅとの交信を、内蔵するソフトウェアＳＷに含まれる命令に従って制御する処理装置１を備え、ソフトウェアＳＷは、警報器１００の使用開始後に要求に応じてアップデートが可能なように内蔵されており、警報器１００に対して行われる所定の指示操作による要求に基づいてアップデートが可能である。【選択図】図１

Description

本発明は、周囲環境を監視する警報器に関する。

従来、工場や住宅における火災やガス漏れなどを検知して警報を発する警報器には、温度や、各種のガスの存在などを検知するセンサなどの感知手段と、その検知結果に基づいて異常の有無を判断するマイコンなどの制御手段と、制御手段の判断結果に基づいて光や音声などを警報として発する報知手段などが備えられている。このような警報器において制御手段のマイコンなどは、ＲＯＭなどの記憶手段に格納されたプログラムに従って感知手段や報知手段を制御して、周囲環境を監視すると共に異常検知時に警報を発するように構成されている。

例えば、特許文献１には、複数の警報器が無線通信で警報情報を共有することにより連動して警報を発する警報システムにおいて、制御回路が実行するプログラムを、第１記憶部に格納したプログラムと第２記憶部に格納したプログラムとの間で切り替えることによって、親局としての機能と子局としての機能とを切り替えることが開示されている。

特開２０１９－１７９３２９号公報

火災の発生やガスの存在などを検知して警報を発する警報器の分野では、警報器が使用される国や自治体が定める法規に適合するための要件、例えば感知性能に関する規定や、異常と判断すべき温度やガスの濃度の基準などが変更されることがある。また、前述の特許文献１のように警報器は外部機器と通信回線で接続して使用されることがある。そしてこのような警報器を含む、通信機能を有する機器が準拠する通信プロトコルにおいては、新たな通信技術の開発やインフラストラクチャーの発展に呼応して、及び／又は、日々出現する新手のハッキング技術に対抗すべく、絶えずバージョンアップが重ねられている。

そのため、警報器、特に通信機能を有する警報器には、例えば法規の変更や技術の伸展に追随すべく、また、警報器に対する新たな脅威から警報器の機能を保護すべく、警報器の使用開始後においても警報器の制御方式を記述したソフトウェアを適宜アップデートすることが求められる。そして、そのような制御用ソフトウェアが適宜アップデートされない場合は、例えば法規の改正に対応できず、警報器自体が動作可能であるにも関わらずその警報器を実質的に使用できなくなったり、通信のセキュリティを脅かす悪意のある技術の脅威に警報器が晒されたりすることにもなり得る。

一方、周囲環境が異常な状態にあることをユーザーに報せるという警報器の特性上、警報器の機能が影響を受けるような状況でのソフトウェアのアップデートの実行は望ましくないこともある。しかし、ユーザーの安全確保という警報器の本質的な提供価値が損なわれない状況であるにも拘わらずアップデートが不能であると、アップデート未了の警報器の使用が無暗に継続されることになり、上記のような法規変更に対応できないことや新たなセキュリティの脅威に晒されることとなって却って好ましくない。

本発明は、上記問題に鑑みてなされたもので、適宜に新たな制御方式を取り入れることが可能な警報器を提供することを目的とする。

本発明の警報器は、周囲環境を監視して監視結果に基づく報知、及び外部機器との交信を行う警報器であって、前記警報器は、前記報知及び前記外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って制御する処理装置を備え、前記ソフトウェアは、前記警報器の使用開始後に要求に応じてアップデートが可能なように内蔵されており、前記警報器に対して行われる所定の指示操作による要求に基づいて前記アップデートが可能である。

前記監視結果に基づく警報の発報中には、前記警報を停止させる所定の停止操作後の前記所定の指示操作による要求に基づいて前記アップデートが可能であってもよい。

前記処理装置は、前記警報の発報中には、前記所定の指示操作以外の方法で要求される前記アップデートの実行を保留するように構成されていてもよい。

前記処理装置は、前記警報の発報中に前記アップデートの実行を保留した後に所定の期間経過しても、前記所定の指示操作によって前記アップデートが要求されないときには、実行を保留されている前記アップデートの内容に応じて、前記所定の期間経過後に、実行を保留されている前記アップデートを実行するように構成されていてもよい。

前記処理装置は、前記警報の発報中に前記アップデートの実行を保留した後に所定の期間経過しても、前記所定の指示操作によって前記アップデートが要求されないときには、実行を保留されている前記アップデートが実行されていないことを前記外部機器に報せるように構成されていてもよい。

前記監視結果に基づく警報の発報中には、前記アップデートのうちの前記処理装置の所定の機能に関する第１アップデートが前記所定の指示操作による要求に基づいて可能であり、前記所定の機能以外の機能に関する第２アップデートが、前記外部機器から送られる信号に基づいて可能であってもよい。

本発明によれば、警報器に適宜に新たな制御方式を取り入れることができる。

本発明の一実施形態の警報器の一例の概略を示すブロック図である。 一実施形態の警報器の記憶領域の構成及び記憶内容の一例を示す模式図である。 一実施形態の警報器への指示操作の例を示す模式図である。 一実施形態の警報器の動作の一例を示すフローチャートである。 一実施形態の警報器における警報発報中のアップデート動作の一例を示すフローチャートである。 一実施形態の警報器と外部機器との間のデータ伝送単位のデータ構造例を示す図である。

以下、添付図面を参照しながら、本発明の一実施形態に係る警報器を説明する。但し、以下に説明される実施形態及び添付の図面は、本発明に係る警報器の一例を示しているに過ぎない。本発明に係る警報器の構成及び作用は、以下に説明される実施形態及び添付の図面に例示される構成及び作用に限定されない。

＜一実施形態の警報器の基本構成及び作用＞
図１には、本発明の一実施形態の警報器１００の主要な構成要素がブロック図で示されている。一実施形態の警報器１００は、例えば、住居や工場などに設置されたり、使用者に携帯されたりして、警報器１００の周囲の環境を監視して監視結果に基づく報知を行なう。すなわち警報器１００は、周囲の環境が特定の状態にある場合にはそれを検知して、例えば、警報を発したり、信号を送ったりして、周囲環境が特定の状態、例えば人体や物的資産に危害が及び得る異常な状態にあることを周囲の人や所定の機器に報せる。特定の状態としては、火災の発生、ガス漏れ、一酸化炭素の充満、煙の充満、過剰な温湿度、などが例示されるが、警報器１００が検知する特定の状態は、これらに限定されない。警報器１００は、さらに通信機能も有しており、外部機器Ｅとの交信を行う。

警報器１００は、図１に示されるように、制御部１０と、通信部２０と、制御部１０及び通信部２０が要する電力を供給する電源部３と、例えば警報器１００のユーザーなどに操作される被操作部５と、を備えている。制御部１０は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する。すなわち制御部１０は、警報器１００が有する本質的な機能である、周囲環境の監視から監視結果に基づく例えば警報の発報といった報知までの機能を制御する。通信部２０は、信号の送信及び受信のような警報器１００と外部機器Ｅとの間の交信を含む、警報器１００の通信機能を制御する。

警報器１００は、制御部１０及び通信部２０それぞれを構成する処理装置１を備えている。すなわち、図１の警報器１００において、制御部１０と通信部２０は処理装置１を共有している。図１の例において処理装置１は、記憶手段１１及び計時手段２１を備えている。処理装置１は、ソフトウェアＳＷを内蔵している。図１の例においてソフトウェアＳＷは、処理装置１が有する記憶手段１１に格納されている。処理装置１は、警報器１００による報知、及び外部機器Ｅとの交信を、ソフトウェアＳＷに含まれる命令に従って制御する。その制御の下で、周囲環境の監視、監視結果に基づく報知、及び外部機器Ｅとの交信が、警報器１００によって行われる。本実施形態において処理装置１は、制御部１０による報知機能の制御、及び通信部２０による外部機器Ｅとの間の通信の制御を具体的に担う半導体装置からなる。

通信部２０は、無線回線Ｃ１又は有線回線Ｃ２を介して外部機器Ｅとの間で直接送受信を行ってもよく、無線回線Ｃ１又は有線回線Ｃ２で接続された、例えばインターネットやローカルエリアネットワーク（ＬＡＮ）などのネットワークＮを介して外部機器Ｅとの間で送受信を行ってもよい。外部機器Ｅとしては、警報器１００以外の同種、又は検知対象の異なる警報器が例示される。外部機器Ｅは、警報器１００の動作を監視若しくは制御する、及び／又は、警報器１００での検知結果若しくは警報発報経過を収集して統計処理若しくは解析するサーバーのような情報処理装置であってもよい。しかし、外部機器Ｅはこれらに限定されない。

電源部３は、制御部１０及び通信部２０を含む、警報器１００の内部の各構成要素に電力を供給する。電源部３は、例えば、商用電源（図示せず）から供給される電力を各構成要素に供給する。その場合、電源部３は、例えば、商用電源から供給される交流電力を所望の電圧の直流電力に変換するインバータや、警報器１００内の構成要素に印加される電源電圧を安定化させる電圧レギュレータなどによって構成され得る。電源部３は、商用電源からの電力ではなく、例えば、リチウム一次電池、乾電池などの一次電池や、バッテリなどの二次電池からの直流電力を警報器１００内の各構成要素に供給してもよい。すなわち、警報器１００は、電池式の警報器であってもよく、特に再充電不能な一次電池の電力で駆動する警報器であってもよい。

本実施形態の警報器１００では、ソフトウェアＳＷは、警報器１００の使用開始後に、要求に応じたソフトウェアＳＷのアップデートが可能なように内蔵されている。警報器１００が従う命令を含むソフトウェアＳＷのアップデートが警報器１００の使用開始後にも可能なので、警報器１００の使用期間中に警報器１００に新たな制御方式を取り入れることができる。例えば、適合すべき法規の変更や、外部機器Ｅとの通信に用いる通信規格の変更などに応じて、ソフトウェアＳＷをアップデートして、警報器１００を適切に動作させることができる。

上記の通り警報器１００では、ソフトウェアＳＷに含まれる命令に従って、周囲環境の監視結果に基づく報知、及び外部機器Ｅとの交信が行われる。従って、ソフトウェアＳＷのアップデートは、報知機能に関するアップデートと通信機能に関するアップデートとの両方を含み得る。しかし、報知機能に関するアップデートは警報器１００の本質的機能のアップデートになるため、例えばアップデート用データの不備などによる万一の不具合を避けるべく、警報器１００において実施可能なソフトウェアＳＷのアップデートから報知機能に関するアップデートが除外されていてもよい。すなわち、ソフトウェアＳＷのアップデートは、報知機能に影響し難いと考えられる、通信機能に関するアップデートであってもよい。「通信機能に関するアップデート」及び「報知機能に関するアップデート」については、後に例示と共に詳述される。

そして、本実施形態の警報器１００では、警報器１００に対して行われる所定の指示操作による要求に基づいて、ソフトウェアＳＷのアップデートが可能である。すなわち、警報器１００への所定の操作に基づいて、ソフトウェアＳＷのアップデートが可能なように、処理装置１ないし警報器１００が構成されている。このように所定の指示操作によるアップデートが可能なので、例えば警報器１００のユーザーや警報器１００の維持管理業者などが意図するときに、アップデートを実行して警報器１００の適切な動作を維持させることができる。

なお、本明細書において「警報器１００（又は、制御部１０、通信部２０、処理装置１、若しくはこれら以外の各構成要素）が特定の動作又は処理を行うように（又は行わないように）構成される」は、警報器１００などにその特定の動作又は処理を行わせる（又は行わせない）命令が、警報器１００などの動作や処理を記述するプログラムに、すなわちソフトウェアＳＷに含まれていることを含んでいる。

ソフトウェアＳＷのアップデートを要求して現に警報器１００にそのアップデートを実行させることが可能な「所定の指示操作」は、例えば、被操作部５に対して行われる手動操作であり得る。また、「所定の指示操作」は、警報器１００の付属リモコンのような専用端末に対する手動操作、すなわち通信などを介した付属リモコンなどからの操作であり得る。或いは、「所定の指示操作」は、警報器１００にアップデートの実行を指示する外部機器Ｅからの操作であってもよい。この「所定の指示操作」は、後にさらに詳述される。

＜制御部の構成＞
本実施形態の警報器の構成及び作用が、以下にさらに詳細に説明される。図１の例において制御部１０は、検知部１２と、報知部１３と、前述した処理装置１及びその周辺回路（図示せず）と、を備えている。

検知部１２は、主に、警報器１００の周囲の監視対象領域の物理現象を監視して監視データを出力する各種のセンサから構成される。各種のセンサは、たとえば、一酸化炭素ガス（ＣＯ）、メタンガス（ＣＨ₄）又はプロパンガス（Ｃ₃Ｈ₈）を検知する各種ガスセンサ、サーミスタなどからなる温度センサ、湿度センサ、煙センサ、又は臭気センサなどであってよい。検知部１２は、これらセンサの１つ又は複数で構成され得る。例えば、各種のガスセンサによってガス漏れが検知される場合、警報器１００はガス警報器であり得、温度センサ及び煙センサなどによって火災の発生が検知される場合、警報器１００は火災警報器であり得る。

報知部１３は、例えば、発光ダイオード、ディスプレイ、ブザー及び／又はスピーカーなどの、警報器１００のユーザーなどへの報知手段により構成され、光の放射、鳴動、及び／又は音響を発することにより警報を発する。また、報知部１３は、警報を発する以外にも、警報器１００の状態や、警報を発するに至らない監視領域の環境に関する情報をユーザーなどに伝えるために動作してもよい。

処理装置１は、マイコンやＡＳＩＣなどの半導体装置からなり、ソフトウェアＳＷのような内蔵されたプログラムに従って動作する。処理装置１は、好ましくは、演算機能、比較機能、記憶機能などを有している。制御部１０において処理装置１は、検知部１２及び報知部１３の動作を含む、警報器１００の報知機能に関する動作を全体的に制御する。例えば処理装置１は、検知部１２から得られる検知データが示す、一酸化炭素やガスの濃度、周囲の温度、及び、煙の濃度などが、所定の閾値を超えているか否かを判断する、そして、温度や濃度などが閾値を超えている場合には、例えばその超過の程度に応じて決定した態様で報知部１３に報知を実行させる。

図１の例の処理装置１が備える記憶手段１１は、処理装置１での処理に必要な任意の情報を記憶する。記憶手段１１は、処理装置１に組み込まれた、ＲＯＭ、ＰＲＯＭ（プログラマブルＲＯＭ）、ＲＡＭ、フラッシュメモリ、及び各種のレジスタなどのメモリ空間であり得る。例えば、記憶手段１１を構成するＥＰＲＯＭ（イレーサブルＰＲＯＭ）に、ソフトウェアＳＷが格納されていてもよい。記憶手段１１には、ソフトウェアＳＷの他、例えば、警報発報の判断基準であって検知部１２の検知データと比較される閾値、この閾値と検知データとの比較結果に対応付けられた報知部１３での報知態様、及び、通信部２０の状態に関する情報、などが記憶される。

＜通信部の構成＞
通信部２０は、前述した制御部１０との間で共有する処理装置１及びその周辺回路（図示せず）と、送受信部２２とを備えている。送受信部２２は、無線通信又は有線通信によって外部機器Ｅとの間で信号を送受する。送受信部２２は、外部機器Ｅと警報器１００との間で電気信号を送受するように構成された、集積回路装置や個々の部品からなる電気回路などのハードウェア（例えば、ＡＳＩＣなどからなる通信制御ＩＣ又はモデムＩＣ、及びその周辺回路など）により構成される。送受信部２２によって、送受信信号の変換、増幅、変調／復調、並びに外部機器Ｅとの間のリンクの設定などが行われる。なお、送受信部２２は、処理装置１の一部によって構成されていてもよい。

通信部２０において処理装置１は、警報器１００の動作中に送受信部２２で行われる、警報器１００と外部機器Ｅとの間での交信に必要な動作を全体的に制御する。例えば、処理装置１は、警報器１００における周囲環境の監視結果に基づいて実行される報知に関する情報を外部機器Ｅに送る動作を制御してもよい。この「報知に関する情報」は、警報器１００において監視結果に基づいて実行される報知に関するものであれば、特に限定されない。例えば、「報知に関する情報」は、検知部１２で得られる逐次若しくは継続的な検知データ、周囲環境が特定の状態にあると判断する閾値（警報発報基準）、警報の発報履歴、及び、警報器１００の状態（例えば正常状態で通常の監視実行中、電池式の場合の電池残量若しくは電池切れ、故障中、及び、警報発報中など）、などであり得る。処理装置１は、さらに、上記「報知に関する情報」以外の情報を外部機器Ｅに送る動作を制御してもよく、警報器１００の制御に関する情報などの任意の情報を外部機器Ｅから受け取る動作を制御してもよい。

通信部２０は、通常の監視の実行中、電池残量、故障中、及び、警報発報中などの上記「警報器１００の状態」を所定の周期で外部機器Ｅに送る通信（定期通信）を行うように構成されていてもよい。定期通信を行うことによって、外部機器Ｅから適時に適切な制御を受け得ることがある。所定の周期は、警報器１００の検知対象や使用場所などによって適宜選択される。所定の周期は、例えば数分程度であってもよく、数時間、あるいは数日程度であってもよい。

図１の例において処理装置１は計時手段２１を含んでいる。計時手段２１は、例えば、特定の時点からの経過時間をカウントする。計時手段２１は、例えば処理装置１を構成するマイコンなどの半導体装置に構成されたカウンタやタイマであり得る。計時手段２１は、例えば、通信部２０が行う前述した「定期通信」において、最後に警報器１００の状態が送られてからの経過時間をカウントしてもよい。また、計時手段２１によって、後述するようなソフトウェアＳＷのアップデートの実行を待機する保留時間がカウントされてもよい。この場合、計時手段２１は、定期通信における経過時間をカウントするカウンタに加えて、アップデートの保留時間をカウントする保留時間カウンタを含み得る。

被操作部５は、例えば、警報器１００のユーザーや管理者などによる操作が可能なように警報器１００に設けられている。被操作部５に対して、種々の所定の動作の実行を警報器１００に指示する各種の手動操作が行われる。例えば、被操作部５に対して、ソフトウェアＳＷのアップデートを要求する、前述した「所定の指示操作」である手動操作が行われる。被操作部５に対して、ソフトウェアＳＷのアップデート以外の所定の動作を指示する操作が行われてもよい。被操作部５に対する操作による指示は、電気信号などによって処理装置１に伝えられ、処理装置１で、被操作部５への操作によって指示された動作が実行される。例えば、ソフトウェアＳＷのアップデートが要求されたなら、アップデートが実行され得る。

被操作部５としては、警報器１００に外部から視認及び接触可能に設けられた各種のスイッチが例示される。被操作部５として用いられるスイッチとしては、押し釦スイッチやトグルスイッチなどが例示されるが、これらに限定されない。また、被操作部５は、タッチパネルやキーパッドのような入力装置であってもよい。

被操作部５として用いられるスイッチは、操作中のみ押し込まれて、操作が終了すると自動復帰するタクタイルスイッチが好ましいことがある。被操作部５がタクタイルスイッチで構成されている場合、押し込まれる時間の長さの違いによって、２種類以上の動作がそれぞれ指示されてもよい。例えば、押し込まれる時間が２秒未満の押し込み操作は、警報器１００の自主点検の要求と認識され、２秒以上５秒未満の押し込み操作は、発報中の警報の停止指示と認識され、５秒以上の押し込み操作は、ソフトウェアＳＷのアップデートの要求と認識されてもよい。

＜ソフトウェアのアップデート＞
ソフトウェアＳＷは、記憶手段１１として備えられるＥＰＲＯＭ、好ましくは、ＥＥＰＲＯＭ（エレクトリカリー・イレーサブルＰＲＯＭ）やフラッシュメモリなどに格納されている。ＥＥＰＲＯＭ及びフラッシュメモリなどでは、例えば高電圧の印加などによって、既に記憶されている内容を書き換えることができる。例えばこのように、ＥＥＰＲＯＭやフラッシュメモリなどで構成される書き換え可能な記憶領域にソフトウェアＳＷを格納することによって、警報器１００の使用開始後であっても、ソフトウェアＳＷのアップデートの実行が可能となる。例えば、処理装置１が備えるＣＰＵ（図示せず）の制御の下で、記憶手段１１として備えられているフラッシュメモリなどの記憶内容が書き換えられ、その結果、ソフトウェアＳＷがアップデートされる。

ソフトウェアＳＷは、処理装置１が行う動作に関する命令が記述された制御プログラムなどのソフトウェアを含み得る。ソフトウェアＳＷは、処理装置１のメモリ（例えばＥＥＰＲＯＭやフラッシュメモリで構成される記憶手段１１）に書き込まれている、処理装置１に関するファームウェアであってもよい。警報器１００の使用開始後にもアップデート可能なソフトウェアＳＷが処理装置１に関するファームウェアであると、例えば、法規の変更や通信規格の改定などによって処理装置１による基本的な制御方式の変更が求められる場合でも、その変更に容易に対応することができる。

特に、警報器を含む各種機器間の通信において準拠される通信規格は、セキュリティ要件などに関して適宜改定されている。また通信規格は、新たに開発される通信技術を取り入れるべく改定されることもある。警報器１００には、アップデートが可能なようにソフトウェアＳＷが内蔵されているので、前述したように、適合すべき法規の変更や、外部機器Ｅとの通信に用いる通信規格の変更などに応じたアップデートの実行によって、制御方式などを適切に更新することができ、警報器１００を適切に動作させることができる。

前述したように外部機器Ｅとの間で無線での交信も可能な通信部２０を含む警報器１００では、ソフトウェアＳＷのアップデートは、外部機器Ｅと通信部２０との無線通信に基づいて行われてもよい。すなわち、ソフトウェアＳＷのアップデートは、所謂「ＯＴＡ（Over-The-Air）アップデート」であってもよく、前述したようにソフトウェアＳＷがファームウェアである場合は、「ファームウェアＯＴＡ」であってもよい。その場合、例えば、遠隔地からでもソフトウェアＳＷをアップデートすることができる。

なお、ソフトウェアＳＷのアップデートは、無線通信に依らずに行われてもよい。すなわち、アップデート後のソフトウェアＳＷは、警報器１００に接続された物理的な回線を通じて供給されてもよく、ＵＳＢメモリなどの記憶媒体を介して供給されてもよい。

＜ソフトウェアを格納する記憶領域の構成＞
図２には、処理装置１が有する記憶領域、例えば記憶手段１１（図１参照）としてソフトウェアＳＷを格納すべく備えられる、例えばＥＥＰＲＯＭやフラッシュメモリなどのメモリの記憶領域４の構成及び記憶内容の一例が模式的に示されている。図２の例において、Ａ－００００番地からＡ－ｎｎｎｎ番地までのアドレスに、命令１～命令ｎで構成されるソフトウェアＳＷが格納されている。一例として、ソフトウェアＳＷのアップデートが行われる際には、アップデート後のソフトウェアＳＷが含むべき一連の命令が、Ａ－００００番地から順に、アップデート後のソフトウェアＳＷのサイズに対応する任意の番地までの領域に上書きされる。

図２の例の記憶領域４は、Ａ－０００１番地からＡ－ＦＦＦＦ番地までの第１記憶領域Ａ１と共に、Ｂ－００００番地からＢ－ＦＦＦＦ番地までの第２記憶領域Ａ２を有している。従って、ソフトウェアＳＷのアップデートでは、アップデート後のソフトウェアＳＷが含むべき一連の命令が、第１記憶領域Ａ１に上書きされずに、第２記憶領域Ａ２に格納されてもよい。このようにアップデート後のソフトウェアＳＷが含むべき命令を格納することによって、処理装置１をアップデート前のソフトウェアＳＷに従って動作させながら、アップデート後のソフトウェアＳＷを、記憶手段１１として備えられるフラッシュメモリなどの記憶領域に書き込むことができる。そして、処理装置１によって次に実行されるべき命令が格納されている記憶手段１１のアドレスを保存するプログラムカウンタが、第２記憶領域Ａ２内の適切なアドレスに設定される。このようにして、短時間で、ソフトウェアＳＷのアップデートを行えることがある。

＜警報器１００に要求されるアップデートの内容＞
前述したように、本質的機能である報知機能に加えて通信機能を有する警報器１００において要求されるソフトウェアのアップデートには、少なくとも、報知機能に関するアップデート及び通信機能に関するアップデートが存在する。報知機能に関するアップデートは報知機能の制御に関わる内容を含み、通信機能に関するアップデートは通信の制御に関わる内容を含む。

一例として「報知機能に関するアップデート」は、検知部１２（図１参照）による周囲環境の監視動作、特定の状態にあることを報知すべきか否かの判断、如何なる態様で報知を行うかの判断、及び、報知部１３（図１参照）による音や光などによる報知動作、などの制御に関するアップデートであり得る。より具体的には、幾つかの例として、検知部１２の動作時期や感度の変更、特定の状態（異常状態）と判断する閾値（警報発報基準）の変更、特定の状態と判断される監視結果と報知態様との対応付けの変更、報知機能に関するプログラムのバグの修正、消費電力を低減する新たな制御手順への変更、及び、報知手段である光の強度や音声の音量若しくは発話内容の変更、などが含まれる。さらに、制御部１０による検知部１２及び報知部１３の自主点検項目、及び／又は、検知部１２を構成する各センサについて適宜行われる補正のアルゴリズムの変更なども「報知機能に関するアップデート」に含まれる。

「通信機能に関するアップデート」は、通信部２０（図１参照）によって制御される通信に関わるアップデートである。より具体的には、幾つかの例として、外部機器Ｅとの通信に適用する通信規格の改定に伴う、セキュリティ確保に関する仕様の変更や、通信リンクの設定及び開放の手順の変更、変調方式の変更、誤り検出時の再送回数の変更、通信部２０において構築されたセキュリティスタックのバージョンアップや、定期通信の頻度の変更、通信に関するプログラムのバグの修正、などが含まれ得る。

＜アップデートを要求する「所定の指示操作」＞
本実施形態の警報器１００は、特定の動作の実行指示として種々の操作を受け得るように構成されている。図３には、家屋の室内に設置された警報器１００を例に、警報器１００が受け得る指示操作の幾つかの例が模式的に示されている。警報器１００に対する指示操作は、例えば、被操作部５に触れるような、警報器１００に対して直接行われる手動操作Ｍ１（第１手動操作）を含み得る。警報器１００に対する指示操作は、さらに、警報器１００の付属リモコンのような専用端末や、アプリケーションプログラムによって専用端末化されたスマートフォンなどの各種の汎用携帯端末に対して警報器１００の近傍で行われる手動操作（以下では「第２手動操作」とも称する）を含み得る。第２手動操作によって、専用端末や専用端末化された汎用携帯端末から、近距離通信などによって、警報器１００に特定の動作を実行させる指示が送信される（以下では、専用端末と専用端末化された汎用携帯端末は「専用端末類」とも総称され、図３には符号「Ｐｎ」を添えて示されている）。

さらに、外部機器Ｅや、遠方のスマートフォンなどの端末Ｐｒから、ネットワークＮや通信事業者の基地局Ｂを介して、警報器１００に特定の動作を指示する信号が送られることもある。その場合、警報器１００に対する指示操作は、これら外部機器Ｅや端末Ｐｒにおける操作（以下では「リモート操作」とも称する）も含まれ得る。なお「リモート操作」には、警報器１００に特定の動作を指示する信号を送るように外部機器Ｅなどに指示する操作は元より、このような信号を警報器１００に送る命令を含む制御プログラムを外部機器Ｅなどが実行することも含まれる。

専用端末類Ｐｎへの第２手動操作による指示は、前述したように、例えば近距離通信によって警報器１００に伝えられる。この近距離通信としては、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ－Ｆｉ（登録商標）、又はＺｉｇＢｅｅ（登録商標）などの近距離無線通信、及び、ＩｒＤＡなどの光無線通信、さらに、ＬｏＲａＷＡＮ（登録商標）などのネットワークプロトコルを用いた警報器１００の近傍からの通信が例示されるが、専用端末類Ｐｎが用いる近距離通信はこれらに限定されない。しかし、「第２手動操作（専用端末類Ｐｎに対して警報器１００の近傍で行われる手動操作）」に基づくアップデートの要求信号は、アップデートの要求者に直接手動操作される専用端末類Ｐｎのような被操作主体から警報器１００に直接伝わる信号に限られる。すなわち、前述した「リモート操作」は、手動操作Ｍ１だけでなく「第２手動操作」にも含まれない。

なお、警報器１００の「近傍」は、警報器１００から数ｍ以内の範囲、及び／又は、警報器１００が視認可能な範囲内であり得る。このような範囲内にいるアップデートの要求者は、警報器１００の周囲の状況の認識が可能と考えられるからである。近距離通信が警報器１００と専用端末類Ｐｎとの通信に用いられる場合は、警報器１００の「近傍」は、さらに、上記の例のような各種の近距離無線通信や光無線通信における警報器１００からの通信圏内である。

前述した「所定の指示操作」、すなわち、警報器１００へのソフトウェアのアップデートの実行要求であって、現に警報器１００にアップデートを実行させることが可能な操作は、これら、手動操作Ｍ１、第２手動操作、及び、リモート操作のいずれか１以上であり得る。警報器１００のユーザーなどが、その意図に沿って警報器１００にアップデートを実行させることができる。しかし、後述するように、アップデートの実行によって警報器１００の本質的機能である報知機能が影響を受けることがある。そのため、警報器１００の近くにいて周囲の安全の確認が把握できたユーザーによってアップデートが要求されることが、基本的には望ましい。従って「所定の指示操作」は、好ましくは、そのような状況にあるユーザーが為し得る操作である手動操作Ｍ１、又は、手動操作Ｍ１及び第２手動操作であり得る。

また、アップデートの要求に必要な指示操作が、先に例示したようなアップデートの内容に応じて決められていてもよい。例えば、ソフトウェアのアップデートのうちの処理装置１（図１参照）の所定の機能に関するアップデート（第１アップデート）が、手動操作Ｍ１及び／又は第２手動操作に限定された「所定の指示操作」による要求に基づいて可能であってよい。

そして、その場合、処理装置１において第１アップデートが関わる機能以外の機能に関するアップデート（第２アップデート）が、「所定の指示操作」に含められていない前述の「リモート操作」に基づいて可能であってもよい。すなわち、第２アップデートは、ネットワークＮや基地局Ｂを介して外部機器Ｅや遠方の端末Ｐｒから送られる信号に基づいて可能であってもよい。この外部機器Ｅなどからの第２アップデートのために送られる信号は、外部機器Ｅなどの内部の制御プログラムなどによって自動的に送られる信号であってもよい。このように、本実施形態の警報器１００において処理装置１は、「所定の指示操作」によって要求される第１アップデートを実行し、「所定の指示操作」以外の指示操作によって要求される第２アップデートを実行するように構成されていてもよい。

第１アップデート及び第２アップデートは、それぞれ、警報器１００の任意の機能に関するアップデートであり得る。例えば第１アップデートが報知機能に関するアップデートであり、第２アップデートが通信機能に関するアップデートであってもよい。その場合、後述するように警報に影響を与えかねない報知機能に関するアップデートの実行を、警報器１００の周囲の状況を把握し得る警報器１００の近傍での操作に基づいて実行することができる。また、外部機器Ｅなどにおいて通信制御方式の変更があった場合に、その外部機器Ｅなどからの要求に基づいて、通信機能に関するアップデートを実行することができる。

或いは、重要なアップデートが外部機器Ｅからの信号に基づいて可能であってもよい。例えば、報知機能や通信を高度に損なわせる致命的なバグの修正、警報発報基準の変更、通信セキュリティの確保に関する仕様の変更、セキュリティスタックのバージョンアップなどに関する重要なアップデートが、外部機器Ｅからの信号に基づいて可能であってもよい。例えば、前述したように外部機器Ｅなどの制御プログラムの実行で自動的に送られる信号によって、人為的な漏れを防いで確実にアップデートを実行し得ることがある。特に、検知部１２（図１参照）での検知周期よりも短い時間で終了すると見込まれる重要なアップデートは、外部機器Ｅからの信号に基づいて可能であってもよい。そのような短い時間であれば警報器１００の周囲において大きな環境の変化は起こり難いので、警報器１００の周囲の状況を把握し得ない遠方での操作であっても、警報の発報に影響を与え難いからである。

その一方で、報知態様の変更、自主点検項目の変更や定期通信の頻度の変更などが、手動操作Ｍ１及び／又は第２手動操作に限定された「所定の指示操作」に基づいて可能であってもよい。しかし、これとは逆に、上記に例示の重要なアップデートが、手動操作Ｍ１及び／又は第２手動操作に限定された「所定の指示操作」に基づいて可能であってもよい。警報器１００の周囲の状況を把握し得る警報器１００の近傍での指示操作に基づくことによって、重要なアップデートを、警報発報の必要が無さそうな平穏な環境下で確実に実行し得ることがある。

＜アップデートの処理フロー＞
図４を参照して、本実施形態の警報器におけるソフトウェアのアップデートに関する処理が説明される。図４には、一例として、図１の警報器１００における、ソフトウェアＳＷのアップデートを含む動作を示すフローチャートが示されている。図４の例は、「所定の指示操作」によって要求されたアップデートが内容による区別なく実行される例であり、また、通信部２０において前述した「定期通信」が行われる例である。

図４のステップＳ０において周囲環境の監視が開始されると、計時手段２１（図１参照）を構成するカウンタなどがリセットされ（ステップＳ１）、時間のカウントが開始される。そして、監視動作と並行して、アップデートの要求の有無がモニタされ、所定の指示操作によるアップデートの要求がなければ（ステップＳ２で“Ｎ”）、計時手段２１のカウント値に基づいて直前の定期通信から所定の時間が経過したかどうかが判断される（ステップＳ３）。ステップＳ３において所定の時間が経過していない場合は（ステップＳ３で“Ｎ”）、計時手段２１の時間がカウントアップされ（ステップＳ４）、ステップＳ２に戻って周囲環境の監視及びアップデート要求の有無のモニタが継続される。ステップＳ３において所定の時間が経過している場合は（ステップＳ３で“Ｙ”）、定期通信として警報器１００の状態が外部機器Ｅ（図１参照）に送信される（ステップＳ５）。その後、計時手段２１のカウント値がリセットされ（ステップＳ６）、ステップＳ２に戻って周囲環境の監視などが継続される。

一方、周囲環境の監視中に所定の指示操作によってソフトウェアのアップデートが要求されると（ステップＳ２で“Ｙ”）、ソフトウェアのアップデートが実行される（ステップＳ８）。アップデートの実行によって、例えば新たな制御方式で警報器を動作させることができる。図４の例では、そのアップデートの実行に伴って警報器１００に必要となるリセット動作Ｒ１が実行される（ステップＳ９）。その後、アップデートの要求がない場合と同様の処理が行われる。

図４の例においてステップＳ９で行われるリセット動作Ｒ１としては、任意の内容が予め設定され得る。例えばリセット動作Ｒ１は、前述したプログラムカウンタを、例えば０番地にリセットしたり所定のアドレスに設定したりすることを含み得る。また、リセット動作Ｒ１は、処理装置１が備える各種のレジスタなどの一時的な記憶領域をクリアすることを含んでいてもよく、警報の発報履歴を消去することを含んでいてもよい。さらに、リセット動作Ｒ１は、外部機器Ｅとの通信履歴を消去したり、外部機器Ｅとの通信リンクを設定若しくは一旦解放後に再設定したりすることを含んでいてもよい。しかし、リセット動作Ｒ１は、これらに限定されない。

＜警報発報中の「所定の指示操作」＞
前述したように、警報器１００に対する種々の指示操作が、警報器１００にアップデートを実行させ得る「所定の指示操作」であり得る。しかし、警報器１００が警報を発している間は、警報器１００にアップデートを実行させることができる「所定の指示操作」が制限されるのが好ましいことがある。アップデートが実行されると、警報器１００の本質的機能である警報の発報が影響を受けることがあるからである。例えば、発報中の警報が、アップデートによって継続し得なくなることがある。また、図４の例のようにアップデートが実行されるとリセット動作Ｒ１が実行される場合、リセット動作Ｒ１によって警報が停止してしまうことも考えられる。特に、図１の例のように制御部１０と通信部２０とが処理装置１を共有している場合、例え通信部２０に関するアップデートであっても、発報中の警報が影響を受ける可能性がある。発報中の警報が影響を受けること、とりわけ警報が停止することは、警報器１００の周囲のユーザーを危険に晒すことになるため極めて好ましくない。

しかし、警報器１００が、本来警報を発するまでもない環境にありながら、検知対象の環境値の偶発的な上昇などによって警報を発してしまうことや、稀に誤報を発してしまうこともあり得る。そのような場合にまで、アップデートの実行を制限するのは、必要なアップデートの実行を無暗に遅らせることとなって却って好ましくない。そのため、例えば、警報器１００の周囲の状況を把握し得るユーザーなどの意志の下で警報の発報が停止された上で要求されるアップデートは、実行されることが好ましいとも考えられる。

このような観点から、警報発報中の本実施形態の警報器１００では、警報を停止させる所定の停止操作を経て行われる「所定の指示操作」による要求に基づくアップデートが実行可能であってよい。すなわち、処理装置１（図１参照）は、警報の発報中に警報の所定の停止操作の後に「所定の指示操作」によって要求されるアップデートを実行するように、構成されていてもよい。このように発せられている警報が停止された状況で警報器１００にアップデートを実行させ得る「所定の指示操作」は、好ましくは、警報器１００の周囲の状況を把握し得る、警報器１００の近傍のユーザーなどがなし得る操作に限られる。すなわち、警報の発報中における「所定の指示操作」は、例えば、前述した手動操作Ｍ１のような、又は、手動操作Ｍ１及び前述した第２手動操作のような、警報器１００に直接又はその近傍で行われる手動による指示操作に限定されてもよい。そして、処理装置１は、この限定された「所定の指示操作」以外の方法で、警報の発報中に要求されるアップデートの実行を保留するように、又は実行しないように、構成されてもよい。例えば、前述したリモート操作によって（又は、リモート操作若しくは第２手動操作によって）、警報の発報中に要求されたアップデートの実行は、保留されるか、又は実行されなくてもよい。

また、警報の発報中のアップデートの実行のために行われる、警報を停止させ得る所定の停止操作も、好ましくは、警報器１００の周囲の状況を把握し得る、警報器１００の近傍のユーザーなどがなし得る操作に限定される。すなわち、警報を停止させる所定の操作は、例えば、前述した手動操作Ｍ１に、及び／又は、前述した第２手動操作に限定され得る。警報停止のための被操作部５（図３参照）への手動操作Ｍ１は、被操作部５が前述したような各種のスイッチである場合、所定の第１時間以上の時間、又は、所定の第１時間以上、所定の第２時間（＞第１時間）以下の時間だけ、被操作部５を継続的に操作することであり得る。

＜アップデート保留時の動作＞
警報器１００が警報発報中に「所定の指示操作」以外の指示操作によって要求されたアップデートを直ちに実行しない（例えば一旦保留する）状況では、要求したアップデートが実行されていないことを要求者が気づかないことがある。或いは、アップデートが実行されていないことを要求者が気づいてはいるが、所定の指示操作で再度要求することを忘れていることもある。そのような場合に備えて、アップデートが実行されていないことを外部機器Ｅや遠方の端末Ｐｒ、或いは専用端末類Ｐｎなどに通知することが好ましい。

従って、本実施形態の警報器１００において処理装置１（図１参照）は、警報の発報中に要求されるアップデートの実行を保留した後に所定の期間経過しても、そのアップデートが所定の指示操作によって再度要求されないときには、アップデートの実行を保留していることを外部に報せるように構成されていてもよい。すなわち、処理装置１は、実行を保留しているアップデートが実行されていないことを、外部機器Ｅ、遠方の端末Ｐｒ、及び／又は、専用端末類Ｐｎに報せるように構成されていてもよい。そうすることで、アップデートの実行漏れを防ぎ得ることがある。

また、要求されたアップデートの内容次第では、要求されたアップデートが実行されていないことの通知と共に、又はそのような通知を省略して、実行保留中のアップデートを再度のアップデートの要求を待たずに実行することが好ましいこともある。従って、本実施形態の警報器１００において処理装置１は、警報の発報中にアップデートの実行を保留した後に所定の期間経過しても、そのアップデートが所定の指示操作によって要求されないときには、実行を保留されているアップデートの内容に応じて、その所定の期間経過後に、保留中のアップデートを実行するように構成されていてもよい。そうすることで、例えば重要性や緊急性の高いアップデートを確実に実行することができる。

要求されたアップデートが実行されていないことを通知する、及び／又は、保留中のアップデートを再度の要求を待たずに実行するまでの「所定の期間」は、例えば、１分以上の任意の時間であり得る。１分以上待機することによって、電力の無用な消費を回避し得ることがある。

アップデートの保留から「所定の期間」が経過したときに再度の要求を待たずに実行されるアップデート（以下、「自動実行アップデート」ともいう）の内容としては、任意の内容が選択され得る。まず、重要性や緊急性の高い内容のアップデートが自動実行アップデートであり得る。例えば、前述した、報知機能や通信を高度に損なわせる致命的なバグの修正、警報発報基準の変更、通信セキュリティの確保に関する仕様の変更、セキュリティスタックのバージョンアップなどに関するアップデートのような重要と目されるアップデートが、自動実行アップデートであり得る。

また、警報器１００の特定の機能に関するアップデートが自動実行アップデートであってもよい。前述したように警報器１００において要求されるソフトウェアのアップデートには、報知機能に関するアップデート及び通信機能に関するアップデートが存在し得る。このうち報知機能に関するアップデートが自動実行アップデートであってもよい。その場合、先に例示したような報知機能に関するアップデートの全てが自動実行アップデートであってもよい。そして、通信機能に関するアップデート全体が、自動実行アップデートでなくてもよい。或いは、通信機能に関するアップデートが自動実行アップデートであってもよく、その場合、先に例示したような通信機能に関するアップデートの全てが自動実行アップデートであってもよい。そして、報知機能に関するアップデート全体が自動実行アップデートでなくてもよい。しかし、如何なるアップデートが自動実行アップデートであるかは、警報器１００の設置環境や警報器１００の仕様などに応じて任意に決定され得る。

なお、警報発報中においても、前述した第１アップデートが、手動操作Ｍ１及び／又は第２手動操作に限定された「所定の指示操作」による要求に基づいて可能であり、前述した第２アップデートが、外部機器Ｅなどから送られる信号に基づいて可能であってもよい。

＜警報発報中のアップデートの処理フロー＞
図５には、図１の例の警報器１００における、警報発報中のソフトウェアのアップデートを含む動作の一例を示すフローチャートが示されている。図５の例は、警報の発報中に要求されたアップデートの実行が保留されて、再度のアップデート要求なく所定の期間が経過したときに、アップデートが非実行であることが通知されると共に、自動実行アップデートが実行される例である。なお、図５に示される各ステップのうち、図４に示されるステップと同様の動作や処理を行うステップについては、図４と同じ符号（ステップＳ８、Ｓ９）が付され、繰り返しとなる説明は、適宜省略される。

図５のステップＳ１０において周囲環境の異常が発生すると、警報が発せられ（ステップＳ１１）、前述した所定の停止操作によって警報が停止されない（ステップＳ１２で“Ｎ”）限り、警報の発報が継続される。そして警報が停止され（ステップＳ１２で“Ｙ”）、しかし、いずれの指示操作でもアップデートが要求されなければ（ステップＳ１３で“Ｎ”）、監視が継続される。一方、警報の停止後にアップデートが要求され（ステップＳ１３で“Ｙ”）、さらにその要求が所定の指示操作による要求である場合（ステップＳ１４で“Ｙ”）、要求されたアップデートが実行され（ステップＳ８）、さらにリセット動作Ｒ１が実行されて（ステップＳ９）、監視が継続される。

これに対して、警報の停止後にアップデートが要求されたものの、その要求が所定の指示操作によるものではない場合（ステップＳ１４で“Ｎ”）、要求されたアップデートは直ちに実行されない。その一方で、例えば処理装置１の計時手段２１（図１参照）に含まれ得る、前述した保留時間カウンタがリセットされたうえで、カウントが開始される（ステップＳ１５）。その後、所定の指示操作によるアップデートの要求があれば（ステップＳ１６で“Ｙ”）、アップデート及びリセット動作が実行され（ステップＳ８、Ｓ９）、監視動作が継続される。

保留時間のカウント開始後、所定の指示操作でのアップデートの要求が無く（ステップＳ１６で“Ｎ”）、保留後の時間が所定期間に達していない場合（ステップＳ１７で“Ｎ”）、保留時間カウンタがカウントアップされ（ステップＳ１８）、ステップＳ１６に戻ってアップデートの要求の有無がモニタされる。

そして、所定の指示操作でのアップデートの要求がないまま所定の期間が経過すると（ステップＳ１７で“Ｙ”）、例えば外部機器Ｅ（図１参照）などに、要求されたアップデートが実行されていないことが通知される（ステップＳ１９）。しかし、実行が保留されているアップデートが前述した「自動実行アップデート」ではない場合は（ステップＳ２０で“Ｎ”）、アップデートは行われずに監視が継続される。

これに対して、実行が保留されているアップデートが自動実行アップデートである場合（ステップＳ２０で“Ｙ”）、保留されているアップデート、すなわちステップＳ１３で要求が検出されたアップデートが、実行される（ステップＳ２１）。さらにリセット動作Ｒｘが実行されて（ステップＳ２２）、監視が継続される。なお、リセット動作Ｒｘは、所定の指示操作による要求を受けずに実行されたアップデート後に行われるリセット動作である。そのため、ステップＳ９で行われるリセット動作Ｒ１と異なる内容のリセット動作が行われてもよい。また、リセット動作Ｒｘの実行と共に、再度のアップデート要求を受けずにアップデートが実行されたことが、外部機器Ｅなどに通知されてもよい。

なお、図４及び図５の例では、アップデートの実行後に、リセット動作Ｒ１又はリセット動作Ｒｘが行われているが、本実施形態の警報器１００において、アップデートの実行後のリセット動作の実行は任意であり、リセット動作は行われなくてもよい。

ステップＳ２０での判断や、要求されるアップデートが前述した第１アップデート又は第２アップデートであるかの判断には、要求されているアップデートの内容の把握が必要になる。この内容は、例えば、アップデートの為に外部機器Ｅ（図１参照）などから供給される更新データに付加される識別符号を認識することによって、処理装置１（図１参照）で把握され得る。すなわち、外部機器Ｅなどの更新データの供給元にて、アップデートの内容が符号化されて識別符号として更新データと共に警報器１００に送られる。この識別符号をデコードすることによって、処理装置１においてアップデートの内容が把握される。或いは、警報器１００に供給されたアップデート後のソフトウェアが、先に図２を参照して説明されたように、アップデート前のソフトウェアの記憶領域と異なる記憶領域に保管されてもよい。そして、アップデート前後のソフトウェアを処理装置１の比較機能で比較することによって、アップデートの内容が把握されてもよい。

また、要求されるアップデートの内容は、アップデートのための更新データの送信に先立って、外部機器Ｅなどの更新データの供給元から警報器１００に送られてもよい。そして、警報器１００において、送られてきたアップデートの種類や内容に基づいて、アップデートを実行するか否かが判断される。警報器１００においてアップデートを実行しないと判断された場合は、例えば所定の待機時間を経て供給元から送られる更新データを警報器１００が受け取らないように構成されていてもよい。或いは、警報器１００での判断結果に応じて、警報器１００から更新データの供給元に、更新データの送信要求又は受領拒否通知が送られ、更新データの供給元は、送信要求を受領した場合だけ、更新データを送るように構成されていてもよい。このように更新データそのものの受信の前にアップデートの可否を判断することによって、実行できないアップデートのための通信による電力の浪費を回避し得ることがある。

＜電池残量によるアップデートの制限＞
前述したように警報器１００は、電池の電力で稼働する電池式の警報器であってもよい。アップデートの実行中は、アップデートが実行されていない時より多くの電力が消費されることがある。そのため、本実施形態の警報器が電池式の警報器である場合、要求されるソフトウェアのアップデートを実行するか否かを、電池の残量に基づいて判断するように構成されていてもよい。例えば電池の残量が所定の閾値以下であると、警報器１００のユーザーや外部機器Ｅなどからアップデートの要求があってもアップデートは実行されない。そうすることで、アップデートによる電池残量のさらなる低下を防いで、警報器１００が電池の残量不足によって機能不全に陥ることを防ぐことができる。すなわち、周囲環境の監視から監視結果に基づく報知までの警報器１００の本質的機能が発揮される状態を、より長く維持させることができる。

特に警報器には、前述したように検知部１２（図１参照）を構成する各種のセンサが備えられ、各種センサには固有の寿命を有するものが存在する。そのため、電池式の警報器は、センサの寿命が尽きるまでの間電池残量が維持されるように電気的に設計され、構造面や仕様面では電池の交換や再充電ができないように設計されることがある。従って、設計思想通りにセンサの寿命まで電池残量が維持されるように、ある程度電池残量が低下してからは、より多くの電力を警報器１００に消費させるアップデートの実行を控えることが好ましいことがある。

なお、このように電池残量によってアップデートの実行が判断される場合、警報器１００には、好ましくは、電池残量計ＩＣなどと称される電子部品のような電池残量計測手段（図示せず）が備えられる。

＜更新データの供給態様＞
図１に例示の警報器１００のような本実施形態の警報器は、前述したように、定期的に警報器１００の状態を外部機器Ｅに送信する定期通信を行うように構成されていてもよい。ここで、幾つかの通信規格では、送信側から送られる、通信パケットのようなデータの伝送単位ごとに、受信側から応答信号を返信するように規定されている。従って、アップデート後のソフトウェアが外部機器Ｅから供給される場合、そのアップデート用の更新データが、定期通信における外部機器Ｅからの応答信号に含めて送られてもよい。その場合、１度のアップデートに必要な更新データが複数の定期通信に渡って分割して送られてもよい。そして、ソフトウェアのアップデートが、そのように１回、又は複数回の定期通信を通じて送られる更新データを用いて実行されてもよい。そうすることで、アップデート用のデータを効率良く送受し得ることがある。

例えば、図６に示されるように、警報器１００から外部機器Ｅに警報器１００の状態などを送る際に準拠する通信規格では、通信パケットなどの伝送単位のデータ長が固定長として定められていることがある。そのような通信規格の下で警報器１００の状態が外部機器Ｅに送信される場合、例えば外部機器Ｅを示す宛先などの制御情報を含むヘッダＨ１と、ペイロードＰ１とで構成される固定長のパケットＰｓが送信される。ペイロードＰ１に実際の送信対象のデータである警報器１００の状態を示すデータが格納される。

パケットＰｓを受け取った外部機器Ｅは、特に警報器１００に送るデータが無くても、準拠する通信規格の規定に従って固定長のパケットＰａ（応答パケット）を警報器１００に送信する。単なる応答用のパケットＰａは、準拠する通信規格に従って、警報器１００を示す宛先を含むヘッダＨ２と、パケットＰａの固定長を満たすペイロードＰ２とで構成される。単なる応答用のパケットＰａの場合、ペイロードＰ２には、例えば“０”のみ又は“１”のみのヌル（無効）データが格納される。そこで、本実施形態の警報器１００においてソフトウェアのアップデートが予定されている場合には、このペイロードＰ２に更新データが格納されて警報器１００に送信される。このように通常の応答パケットでは有効活用されていないデータ格納領域を利用することで、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器１００に供給することができる。警報器１００は、複数の応答パケットに分割して送られる更新データの全てを受け取ると、自律的にソフトウェアのアップデートを開始してもよい。

なお、警報器１００では、警報を発するときに、その警報の発報が外部機器Ｅに通知されてもよい。その場合、その通知に対する応答信号にアップデート用の更新データが含められてもよい。この場合も、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器１００に供給することができる。

また、警報器１００は、分割して受け取る更新データを、アップデートの実行まで、警報器１００内の記憶手段１１（図１参照）などの記憶領域に保管してもよい。その場合、図２に示されるように、アップデート前のソフトウェアＳＷが格納されている領域（例えば第１記憶領域Ａ１）と異なる領域（例えば第２記憶領域Ａ２）に、順次受け取る更新データが格納されてもよい。そうすることで、警報器１００は、アップデート前のソフトウェアＳＷに従って動作しながら、すなわち報知機能を停止させることなく、随時送られてくる更新データを受け取ることができる。

なお、今回開示された実施形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施形態の説明ではなく特許請求の範囲によって示され、さらに特許請求の範囲と均等の意味及び範囲内でのすべての変更（変形例）が含まれる。

また、上記実施形態では、説明の便宜上、実施形態の警報器の処理動作を処理フローに沿って順番に処理を行うフロー駆動型のフローチャートを用いて説明したが、本発明はこれに限られない。本発明では、警報器の処理動作を、イベント単位で処理を実行するイベント駆動型（イベントドリブン型）の処理により行ってもよい。この場合、完全なイベント駆動型で行ってもよいし、イベント駆動及びフロー駆動を組み合わせて行ってもよい

１００ 警報器
１ 処理装置
１０ 制御部
１１ 記憶手段
２０ 通信部
２１ 計時手段
３ 電源部
５ 被操作部
Ｅ 外部機器
Ｐｎ 専用端末類
Ｐｒ 遠方の携帯端末
ＳＷ ソフトウェア

Claims (5)

1. 周囲環境を監視して監視結果に基づく報知、及び外部機器との交信を行う警報器であって、
   前記警報器は、前記報知及び前記外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って制御する処理装置を備え、
   前記ソフトウェアは、前記警報器の使用開始後に要求に応じてアップデートが可能なように内蔵されており、
   前記監視結果に基づく警報が発せられているときに前記警報器に対して行われる所定の指示操作による要求に基づいて前記アップデートが可能である、警報器。
2. 周囲環境を監視して監視結果に基づく報知、及び外部機器と前記周囲環境の監視結果に基づく報知に関する情報の交信を行う警報器であって、
   前記警報器は、前記報知及び前記外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って制御する処理装置を備え、
   前記ソフトウェアは、前記警報器の使用開始後に要求に応じてアップデートが可能なように内蔵されており、
   前記警報器に対して行われる所定の指示操作による要求に基づいて、前記外部機器から通信で供給される更新データに依る、前記報知に関する前記アップデートが可能である、警報器。
3. 周囲環境を監視して監視結果に基づく報知、及び外部機器との交信を行う警報器であって、
   前記警報器は、前記報知及び前記外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って制御する処理装置を備え、
   前記ソフトウェアは、前記警報器の使用開始後に要求に応じてアップデートが可能なように内蔵されており、
   前記警報器に対して行われる所定の指示操作による要求に基づいて、前記報知にかかる機能に関する前記アップデート及び通信機能に関する前記アップデートが可能であり、
   前記所定の指示操作は、
   所定の動作の実行を指示する操作を受けるように前記警報器に設けられている被操作部に対する直接的な手動操作、又は、
   前記警報器の近傍からの近距離無線通信を介した操作、又は、
   前記ソフトウェアのアップデートを指示する信号を前記警報器に送る制御を前記外部機器に指示する操作、
   である、警報器。
4. 前記監視結果に基づく警報の発報中には、前記警報を停止させる所定の停止操作後の前記所定の指示操作による要求に基づいて前記アップデートが可能である、請求項２又は３記載の警報器。
5. 周囲環境を監視して監視結果に基づく報知、及び外部機器との交信を行う警報器であって、
   前記警報器は、前記報知及び前記外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って制御する処理装置を備え、
   前記ソフトウェアは、前記警報器の使用開始後に要求に応じてアップデートが可能なように内蔵されており、
   前記警報器に対して行われる所定の指示操作による要求に基づいて、外部の通信ネットワーク又は通信事業者の基地局を介して前記警報器と交信を行う前記外部機器から通信で供給される更新データに依る、前記報知に関する前記アップデートが可能である、警報器。

Images