JP7473703B1

JP7473703B1 - 警報器

Info

Publication number: JP7473703B1
Application number: JP2023042246A
Authority: JP
Inventors: 和也齋藤
Original assignee: New Cosmos Electric Co Ltd
Current assignee: New Cosmos Electric Co Ltd
Priority date: 2023-03-16
Filing date: 2023-03-16
Publication date: 2024-04-23
Anticipated expiration: 2043-03-16
Also published as: JP2024131784A

Abstract

【課題】警報器の報知機能への影響を抑制しながら、通信制御技術の向上に追随した通信を継続させて警報を広範に届けることができる警報器を提供する。【解決手段】実施形態の警報器１００は、内蔵するソフトウェアＳＷ１、ＳＷ２に含まれる命令に従って動作する警報器である。警報器１００は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部１０と、外部機器Ｅとの間の交信を制御する通信部２０と、を備え、ソフトウェアＳＷ２は、警報器１００の使用開始後にアップデートが可能なように内蔵されており、制御部１０は、周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを外部機器Ｅに報せる通知を行うように構成されており、制御部１０は、アップデートのうちの通信部２０に関する第１アップデートの実行中に周囲環境の異常を検知すると、警報発報中であることを外部機器Ｅに報せる通知を行わずに警報を発する。【選択図】図１

Description

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

従来、工場や住宅における火災やガス漏れなどを検知して警報を発する警報器には、温度や、各種のガスの存在などを検知するセンサなどの感知手段と、その検知結果に基づいて異常の有無を判断するマイコンなどの制御手段と、制御手段の判断結果に基づいて光や音声などを警報として発する報知手段などが備えられている。このような警報器には、近年、外部との間で情報を送受信するための通信手段がさらに備えられ、外部機器、例えば、他の警報器と連携して動作したり、インターネット上のサーバーなどと情報交換をしたりしながら周囲環境を監視することも行われている。

例えば、特許文献１には、複数の警報器が無線通信で警報情報を共有することにより連動して警報を発する警報システムにおいて、親局としての動作と子局としての動作とを切り替えられる無線式警報器が開示されている。

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

上記のように警報器がその外部の機器と通信回線で接続されると、例えば、ガス漏れなどの検知時に、警報器自身が音や光などで警報を発するだけでなく、外部の機器を通じて、遠隔地にいるユーザーやその関係者にもガス漏れなどの異常の発生を速やかに報せることができる。一方、このような情報通信の分野では、その利用範囲の拡大や送受されるデータ量の膨張に伴って、通信プロトコルや、それに基づく通信制御プログラムにおいて常にバージョンアップが重ねられている。また、そのように通信によって送受される情報を標的として、通信回線を介したハッキングやネットワーク上での盗聴などといった、通信のセキュリティを脅かす悪意のある技術が、日々新たに生み出され、また変異を続けている。このような通信のセキュリティを阻害する新種の技術への耐性を備える面からも、通信制御プログラムの継続的なバージョンアップが行われている。そのため、通信機能を有する警報器には、このように進化を続ける通信制御技術に絶えず追随することが求められ、さもなければ、例えば、通信のセキュリティを脅かす悪意のある技術の脅威に晒されることとなり得る。しかしながら、警報器の特性上、通信制御プログラムのバージョンアップの際に、警報器の本質的機能である報知機能が機能しない期間があるのは好ましくない。

本発明は、上記問題に鑑みてなされたもので、警報器の報知機能への影響を抑制しながら、通信制御技術の向上に追随した通信を継続させて警報を広範に届けることができる警報器を提供することを目的とする。

本発明の警報器は、内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、外部機器との間の交信を制御する通信部と、を備え、前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、前記制御部は、前記アップデートのうちの前記通信部に関する第１アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発する。

前記制御部は、前記第１アップデートの開始時に、前記通知を行わないモードに移ることを前記外部機器に報せるように構成されていてもよい。

前記制御部は、前記第１アップデートを実行している期間と実行していない期間との間で、前記周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されていてもよい。

前記制御部は、前記周囲環境の異常の検知時にメッセージを発するように構成されており、前記制御部は、前記第１アップデートを実行している期間と実行していない期間との間で、前記メッセージを発する態様を異ならせるように構成されていてもよい。

前記周囲環境の異常の検知に応じて発せられた警報が、外部からの停止操作によって停止可能であり、前記制御部は、前記第１アップデートを実行している期間と実行していない期間との間で、前記停止操作による警報停止の容易性を異ならせるように構成されていてもよい。

前記警報器は、前記アップデートの種類に応じて、前記警報器に対して行われる所定の指示操作に基づいて前記アップデートを実行するか、前記外部機器からの信号の受信に基づいて前記アップデートを実行するように構成されていてもよい。

前記制御部は、前記周囲環境の異常の検知前に開始された前記第１アップデートが警報発報中に終了すると、前記通知を行うように構成されていてもよい。

前記制御部は、前記第１アップデートの実行中に前記周囲環境の異常の検知によって発した警報が前記第１アップデートの終了前に停止されたときは、前記第１アップデートの終了後に、前記第１アップデートの実行中に警報を発したことを前記外部機器に報せるように構成されていてもよい。

本発明によれば、警報器の報知機能への影響を抑制しながら、通信制御技術の向上に追随した通信を継続させて警報を広範に届けることができる。

本発明の一実施形態の警報器の一例の概略を示すブロック図である。一実施形態の警報器の記憶領域の構成及び記憶内容の一例を示す模式図である。一実施形態の警報器の動作の一例を示すフローチャートである。一実施形態の警報器におけるアップデートの要求方法の例を示す模式図である。一実施形態の警報器におけるアップデートの優先度と電池残量に応じた実行の判断との対応の一例を示す図である。一実施形態の警報器と外部機器との間のデータ伝送単位のデータ構造例を示す図である。一実施形態の警報器の変形例の概略を示すブロック図である。

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

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

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

制御部１０は第１処理装置１ａを含んでいる。第１処理装置１ａは、周囲環境を監視して監視結果に基づく報知を行う報知機能の制御を担う半導体装置によって構成されている。第１処理装置１ａは記憶手段１ｂを有している。通信部２０は第２処理装置２ａを含んでいる。第２処理装置２ａは、警報器１０１と外部機器Ｅとの間の通信の制御を担う半導体装置によって構成されている。第２処理装置２ａは、記憶手段２ｂ及び計時手段２ｃを有している。制御部１０と通信部２０とは、互いに相手方との間で信号の送受が可能なように接続されている。

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

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

本実施形態の警報器１００は、ソフトウェアＳＷ１、ＳＷ２を内蔵していて、ソフトウェアＳＷ１、ＳＷ２に含まれる命令に従って動作する。図１の例において、ソフトウェアＳＷ１は、第１処理装置１ａが有する記憶手段１ｂに格納されている。ソフトウェアＳＷ２は、第２処理装置２ａが有する記憶手段２ｂに格納されている。従って、具体的には第１処理装置１ａ乃至は制御部１０が、ソフトウェアＳＷ１に含まれる命令に従って動作して、警報器１００の報知機能を制御する。そして、第２処理装置２ａ乃至は通信部２０が、ソフトウェアＳＷ２に含まれる命令に従って動作して、警報器１００の通信機能を制御する。なお、本実施形態において警報器１００は、第１及び第２の処理装置１ａ、２ａが実行するソフトウェアＳＷ１、ＳＷ２を格納するＲＯＭなどの記憶手段（図示せず）を、第１及び第２の処理装置１ａ、２ａとは別に備えていてもよい。

本実施形態の警報器１００では、少なくともソフトウェアＳＷ２は、警報器１００の使用開始後に、要求に応じたソフトウェアＳＷ２のアップデートが可能なように内蔵されている。警報器１００では、ソフトウェアＳＷ１も、警報器１００の使用開始後にアップデートが可能なように内蔵されていてもよい、以下では、ソフトウェアＳＷ２だけでなく、ソフトウェアＳＷ１のアップデートも可能なものとして、本実施形態の警報器が説明される。警報器１００が従う命令を含むソフトウェアＳＷ１、ＳＷ２のアップデートが警報器１００の使用開始後にも可能なので、例えば、適合すべき法規の変更や、外部機器Ｅとの通信に用いる通信規格の変更などに応じて、各ソフトウェアをアップデートして、警報器１００を適切に動作させることができる。すなわち、適法な警報動作、及び／又は、通信制御技術の向上に追随した通信を継続させることができる

また、本実施形態の警報器１００において制御部１０は、周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを外部機器Ｅに報せる通知を行うように構成されている。そのため、警報器１００の周囲だけでなく、警報を広範に届けることができる。例えば、遠方のユーザーや、その関係者にも警報器１００の周囲が特定の異常な環境にあることを報せることができる。従って、異常状態の解消に向けた迅速な措置を促すことができ、損害の発生や被害の拡大を防止できることがある。

さらに、本実施形態では、制御部１０及び通信部２０それぞれがソフトウェアＳＷ１、ＳＷ２を第１処理装置１ａ、第２処理装置２ａそれぞれに内蔵しているので、ソフトウェアＳＷ１のアップデート時には、通信部２０は外部機器Ｅとの通信などが可能な状態を維持することができる。また、ソフトウェアＳＷ２のアップデート時には、制御部１０は報知機能を維持することができる。一方、ソフトウェアＳＷ２のアップデート中は、外部機器Ｅとの交信が不能になることがある。そのため、警報器１００において制御部１０は、警報器１００に内蔵されるソフトウェアのアップデートのうちの通信部２０に関するアップデートの実行中に周囲環境の異常を検知すると、警報発報についての外部機器Ｅへの通知は行なわずに警報を発するように構成されている。すなわち、図１の例では、ソフトウェアＳＷ２のアップデートの実行中に周囲環境の異常が検知されると、外部機器Ｅへの警報発報の通知は行われずに、警報器１００自らが放出する例えば音声や光による警報が発せられる。なお「通信部２０に関するアップデート」は、以下では「第１アップデート」とも称される。

従って、外部機器Ｅに警報の発報は知らされないものの、少なくとも警報器１００の近傍のユーザーには、通信部２０に関するソフトウェアＳＷ２のアップデート中であっても、異常状態の発生を報せることができる。換言すると、警報器１００の近傍のユーザーまで、異常の発生が知らされない危険な状態に置くことなくソフトウェアＳＷ２のアップデートを継続させることができる。すなわち、警報器１００の報知機能への影響を少なくしながら、通信部２０に関する必要なアップデートを完遂させることによって、引き続き、通信制御技術の向上に追随した通信を行うことができる。

このように、本実施形態の警報器は、警報の発報時に外部機器に警報の発報を通知するモードと、そのような通知をしないモードとの少なくとも二つの動作モードを有している。警報器１００の動作モードは、例えば、通信部２０に関するアップデートの実行中か否かによってこの二つのモードの間で遷移する。なお、本明細書において「警報器１００（又は、制御部１０、通信部２０、若しくはこれら以外の各構成要素）が特定の動作又は処理を行うように（又は行わないように）構成される」は、警報器１００などにその特定の動作又は処理を行わせる（又は行わせない）命令が、警報器１００などの動作や処理を記述するプログラムに、すなわちソフトウェアＳＷ１、ＳＷ２に含まれていることを含んでいる。

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

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

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

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

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

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

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

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

図１の例において第２処理装置２ａが備える記憶手段２ｂは、第２処理装置２ａで実行される処理に必要な任意の情報を記憶する。記憶手段２ｂは、第２処理装置２ａに組み込まれた、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、フラッシュメモリ、及び各種のレジスタなどのメモリ空間であり得る。例えば、記憶手段２ｂを構成し得るＥＰＲＯＭに、ソフトウェアＳＷ２が格納されていてもよい。

図１の例において第２処理装置２ａが備える計時手段２ｃは、例えば、特定の時点からの経過時間をカウントする。計時手段２ｃは、例えば第２処理装置２ａを構成するマイコンなどの半導体装置に構成されたカウンタやタイマであり得る。計時手段２ｃは、例えば、通信部２０が行う前述した「定期通信」において、最後に警報器１００の状態が送られてからの経過時間をカウントしてもよい。

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

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

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

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

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

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

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

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

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

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

なお、第１処理装置１ａにおいてソフトウェアＳＷ１のアップデートが行われる場合も、ソフトウェアＳＷ２について図２で説明されたような方法で、警報器１００の報知機能を維持しながら、アップデート後のソフトウェアＳＷ１を記憶手段１ｂ（図１参照）内に格納し得ることがある。

また、図２の例のような記憶領域４内の特定の記憶領域へのアップデート後のソフトウェアＳＷ２の書き込みや、アップデート後のソフトウェアＳＷ２への切り替えは、一例において、第２処理装置２ａのハードウェアを管理するオペレーティングシステム（ＯＳ）によって制御される。その場合、ソフトウェアＳＷ２は、このＯＳ上で動作するアプリケーションプログラムであってもよい。そして、アップデート前のソフトウェアＳＷ２の実行中に、アップデート後のソフトウェアＳＷが記憶領域４内の空き領域に書き込まれ、ソフトウェアＳＷ２が実行されていない間に、アップデート後のソフトウェアＳＷ２に切り替えられてもよい。第１処理装置１ａのソフトウェアＳＷ１についても、同様にＯＳの制御の下でアップデートが行われてもよい。

＜アップデートの処理フロー＞
図３を参照して、本実施形態の警報器における通信部に関するソフトウェアのアップデート（第１アップデート）に関する処理が説明される。図３には、一例として、図１の警報器１００における、ソフトウェアＳＷ２のアップデートを含む動作を示すフローチャートが示されている。なお、図３の例は、通信部２０において前述した「定期通信」が行われる例である。図３を主に参照する以下の説明では、相反する説明がない限り、「ソフトウェア」は、通信部２０が従う制御プログラムを含む「ソフトウェアＳＷ２」を意味し、「アップデート」は、通信部２０に関するアップデートある「第１アップデート」を意味する。

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

一方、アップデートが要求及び実行されていない状況での周囲環境の監視中に異常の発生が検知されると（ステップＳ４で“Ｙ”）、異常の種類や程度に応じて制御部１０によって選択された所定の態様（第１態様）で警報が発せられる（ステップＳ５）。加えて、警報が発せられていることが通信部２０によって外部機器Ｅに通知される（ステップＳ６）。

ステップＳ５で発せられる警報の態様である第１態様は、報知部１３（図１参照）がＬＥＤなどの発光素子を含んでいる場合、所定の第１輝度及び第１色度の光を連続的に発することや、そのような所定の輝度及び色度の光を断続的に発する（すなわち点滅させる）ことであり得る。また、報知部１３がスピーカーやブザーなどの鳴動素子を含んでいる場合、所定の第１音量で所定の第１音調の音が発せられてもよい。報知部１３が発する音は例えばビープ音であってもよく、人工的に作られた音声であってもよい。例えば、ステップＳ５において第１態様で発せられる音声は、「ガス漏れ（又は火事）です。外部の○〇に通知しています」などのメッセージであり得る。このように、制御部１０は、周囲環境の異常の検知時にメッセージを発するように構成されていてもよい。メッセージの発話によって、より明確且つ具体的にユーザーなどに異常状態の発生を報せることや、異常状態への対処方法を教授することが可能なことがある。

警報の発報及び外部機器への通知後、ユーザーによって警報の停止操作が行われず、しかも異常状態が解消されない（ステップＳ７で“Ｎ”）間、警報の発報が継続される（ループＬ１）。そして、警報の停止操作が行われるか、異常状態が解消すると（ステップＳ７で“Ｙ”）、警報が停止される（ステップＳ８）。ステップＳ８において、警報の停止が通信部２０によって外部機器Ｅに通知されてもよい。警報の停止後、ステップＳ２１で所定時間の経過の有無が判断され、前述したステップＳ２１以降の処理が実行される。

本実施形態の警報器１００では、図３の例のステップＳ７のように、周囲環境の異常の検知に応じて発せられた警報が、警報器１００の外部からの停止操作によって停止可能であってもよい。偶発的且つ瞬間的な環境の変動による拙速な警報や誤報などの場合に、速やかに警報器１００の周囲を平穏な平常時の状態に落ち着かせることができる。

発報中の警報を停止させ得る停止操作は、例えば、被操作部５（図１参照）への直接的な手動操作であってもよく、警報器１００の近傍又は遠方からの警報停止を指示する信号の送信であってもよい。警報停止を指示する信号は、例えば、外部機器Ｅへのユーザーの操作に基づいて外部機器Ｅから警報器１００に送られてもよい。警報停止のための被操作部５への手動操作は、被操作部５が前述したように各種のスイッチである場合、所定の第１時間以上の時間、又は、所定の第１時間以上、所定の第２時間（＞第１時間）以下の時間だけ、被操作部５を継続的に操作することであってもよい。

一方、ステップＳ３でソフトウェアのアップデートが要求されていると（ステップＳ３で“Ｙ”）、図３の例では、アップデートの開始が外部機器Ｅに通知され（ステップＳ１１）、アップデートが開始される（ステップＳ１２）。すなわち、制御部１０は、第１アップデートの開始時に、外部機器Ｅへの警報の発報の通知を行わないモードに移ることを、通信部２０を介して外部機器Ｅに報せるように構成されている。従って、遠方のユーザーなどに、警報が発せられても通知されない状況にいることを了知させることができる。なお、ソフトウェアのアップデートの要求は、後述するように、警報器１００のユーザーによる被操作部５に対する手動操作や、外部機器Ｅからのアップデートを指示する信号の送信によって行われ得る。

アップデートの開始後、周囲環境の監視において異常が生じなければ（ステップＳ１３で“Ｎ”）、アップデートが終了しない（ステップＳ１７で“Ｎ”）間、ループＬ２でステップＳ１３に戻って、周囲環境の監視とアップデートの実行が継続される。そして、アップデート中に異常が生じると（ステップＳ１３で“Ｙ”）、警報が発せられる（ステップＳ１４）。しかし、アップデート非実行中の異常発生時にステップＳ６で行われるような外部機器Ｅへの通知は行われない。

図３の例においてステップＳ１４での警報は、アップデート非実行中であるステップＳ５での発報態様である前述した第１態様とは異なる第２態様で発せられる。アップデート非実行中の警報と異なる態様で警報を発することで、外部機器Ｅに警報の発報が通知されていないことを、警報器１００の近傍のユーザーに了知させることができる。このように制御部１０は、第１アップデートを実行している期間と実行していない期間との間で、周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されていてもよい。なお、警報器１００は、第１アップデート中の警報発報中に被操作部５（図１参照）に何らかの操作がされた場合に、第１アップデート実行中であることを音声又は光などで示すように構成されていてもよい。

ステップＳ１４において発する警報の態様である第２態様は、第１態様について前述した第１輝度と異なる第２輝度、及び／又は、前述した第１色度と異なる第２色度の光を連続的に発することや、そのような所定の輝度及び色度の光を点滅させることであり得る。例えば、第２輝度は第１輝度よりも高く、第２色度は第１色度よりも彩度に関して高くてもよい。第１態様において光が連続的に発せられる場合、第２態様において点滅する光が発せられてもよく、第１態様において点滅する光が発せられる場合は、第２態様において第１態様における点滅よりも短い周期で点滅する光が発せられてもよい。また、警報として音が発せられる場合は、例えば第２態様において、第１態様に関して前述した第１音量よりも大きな第２音量及び／又は前述した第１音調よりも可聴範囲の中心に近い音調の音が発せられてもよい。或いは、第２態様において第１態様よりも短い周期で断続的に音が発せられてもよい。

上記とは逆に、第２態様において、第１態様よりも長い点滅周期で光が発せられてもよく、第２態様において第１態様よりも長い周期で断続的に音が発せられてもよい。消費電力低減の観点で好ましいことがある。このように、警報器１００は、より消費電力の少ない態様である第２態様で、第１アップデート中の警報の発報を行ってもよい。

さらに、第２態様の警報としてメッセージが発せられる場合は、第１態様で発せられるメッセージと異なるメッセージが発せられてもよい。例えば、ステップＳ１４において第２態様で発せられるメッセージは、「ガス漏れ（又は火事）です。外部の○〇には通知されていないのでご注意ください」などであり得る。このように、制御部１０は、第１アップデートを実行している期間と実行していない期間との間で、メッセージを発する態様を異ならせるように構成されていてもよい。警報器１００の近傍のユーザーなどに、外部に警報の発報が知らされていないことを、より明確に伝えることができる。

警報の発報後、ユーザーによって警報の停止操作が行われるか、異常状態が解消すると（ステップＳ１５で“Ｙ”）、警報が停止される（ステップＳ１６）。しかし、アップデートが終了しない（ステップＳ１７で“Ｎ”）間は、ループＬ２でステップＳ１３に戻って、周囲環境の監視とアップデートの実行が継続される。

アップデート実行中のステップＳ１５で制御部１０に警報の停止操作として受け容れられる操作は、アップデートの非実行中であるステップＳ７で警報の停止操作として受け容れられる操作と異なっていてもよい。アップデートの実行中の警報の停止に必要な操作をアップデートの非実行中に許容される操作と異ならせることで、外部に警報発報が通知されていないことを、警報器１００の近傍のユーザーに了知させることができる。以下の説明において、アップデート実行中のステップＳ１５で警報の停止操作として受け容れられる操作は、図３のステップＳ１５に記載の通り「特定停止操作」とも称される。

例えば、特定停止操作は、被操作部５（図１参照）への直接的な手動操作だけに限定され、すなわち、ネットワークＮや通信事業者の基地局Ｂ（後に参照する図４参照）を介して外部機器Ｅから送られる警報停止を指示する信号は無効にされてもよい。こうすることで、警報の停止を、警報器１００の周囲の状況を把握し得る警報器１００の近傍のユーザーなどに限定することができる。また、警報の発報が通知されていない遠方のユーザーの誤操作などによる不適切な警報の停止を回避することができる。

特定停止操作は、アップデート非実行中に警報停止操作として許容される被操作部５への操作時間よりも長時間にわたる被操作部５への操作や、限られた時間中の複数回の操作であってもよい。また、警報器１００は、複数の被操作部５を備えていてもよく、その場合、特定停止操作は、複数の被操作部５に対する同時操作であってもよい。

このように本実施形態の警報器１００において制御部１０は、第１アップデートを実行している期間と実行していない期間との間で、警報の停止操作による警報停止の容易性を異ならせるように構成されていてもよい。一例として、第１アップデートの実行中は、第１アップデートを実行していないときよりも、警報停止の難易度が高められてもよい。或いは、アップデートの実行中に発せられる警報は、警報器１００への電力供給の停止を除いて停止不可であってもよい。そうすることで、警報器１００の近傍のユーザーに、警報の発報が外部に通知されていないことをより強く印象付け得ることがある。なお、このように警報器１００への電力供給の停止を除いて警報の停止が不可な場合、警報時に発せられるメッセージが、警報の停止が不可であることを伝えるメッセージに変更されてもよい。

ステップＳ１６での警報の停止後に、又はアップデート実行中に異常が生じないまま（ステップＳ１３で“Ｎ”）、アップデートが終了した場合（ステップＳ１７で“Ｙ”）、図３の例では、外部機器Ｅへの通知が行われる（ステップＳ１８）。ステップＳ１８での外部機器への通知では、アップデート実行中に警報の発報が無かった場合には、例えばアップデートの終了だけが通知される。

一方、アップデート実行中に警報の発報があった場合（ステップＳ１６からステップＳ１７に至った場合）には、アップデート終了後のステップＳ１８において、アップデートの終了の通知と共に、又はアップデートの終了の通知の代わりに、アップデート中に警報の発報があったことが外部機器Ｅに通知されてもよい。

このように本実施形態の警報器において制御部１０は、第１アップデートの実行中に発した警報が第１アップデートの終了前に停止されたときは、第１アップデートの終了後に、第１アップデートの実行中に警報を発したことを外部機器Ｅに報せるように構成されていてもよい。外部機器Ｅ側のユーザーや管理者に、警報器１００の周囲の現況を確認するよう促し得ることがある。ステップＳ１８での外部機器Ｅへの通知後、ステップＳ２１で所定時間の経過の有無が判断され、前述したステップＳ２１以降の処理が実行される。

ステップＳ１４での警報の停止後、特定停止操作が行われず、しかも異常が解消しない場合は（ステップＳ１５で“Ｎ”）、アップデートが終了しない限り（ステップＳ１９で“Ｎ”）、ループＬ３でステップＳ１５に戻って、警報の発報とアップデートの実行とが継続される。一方、アップデートが終了すると（ステップＳ１９で“Ｙ”）、処理がステップＳ６に移って、警報の発報中であることが外部機器Ｅに通知され、その後、前述したようにステップＳ７以降の処理が実行される。

このように、本実施形態の警報器１００において制御部１０は、周囲環境の異常の検知前に開始された第１アップデートが警報発報中に終了すると、警報発報中であることを外部機器Ｅに報せる通知を行うように構成されていてもよい。外部機器Ｅとの交信が可能になり次第、速やかに、警報器１００の周囲環境が異常な状態にあることを外部機器Ｅに報せることができる。

＜アップデートの要求態様＞
本実施形態の警報器１００において、ソフトウェアＳＷ１、ＳＷ２（図１参照）のような各ソフトウェアのアップデートの要求には、任意の方法が適用される。図４には、アップデートの要求の幾つかの例として、家屋の室内に設置された警報器１００へのアップデートの要求方法が模式的に示されている。アップデートの要求は、例えば、前述したように被操作部５に触れるような直接的な所定の操作Ｍ１によって行われる。また、警報器１００の付属リモコンのような専用端末や、アプリケーションプログラムによって専用端末化されたスマートフォンなどの各種の汎用携帯端末から近距離通信によってアップデートが要求されてもよい（以下では、専用端末と専用端末化された汎用携帯端末は「専用端末類」と総称され、図４には符号「Ｐｎ」を添えて示されている）。また、外部機器Ｅや、遠方のスマートフォンなどの端末Ｐｒから、ネットワークＮや通信事業者の基地局Ｂを介して送られる信号によってアップデートが要求されてもよい。その場合、外部機器Ｅからのアップデート用の更新データの送信そのものでアップデートが要求されてもよい。

しかし、警報器１００に用意されたアップデートの要求方法の全てが有効であることが、必ずしも好ましくない場合もある。例えば、アップデートの要求者が警報器１００の周囲環境を把握可能な状況にいると考えられる要求方法による要求は受け付けられるが、それ以外の要求方法による要求は受け付けられない方が好ましいこともある。例えば、警報が発報されるほどの状況ではないが、その状況に近付いている状況にあるにも拘わらず、その状況を認識し得ない要求者からの例えばソフトウェアＳＷ１のアップデートの要求を受け入れるのは、適正な警報発報の妨げになる場合もあるからである。

そのため、本実施形態では、アップデートの要求方法が、要求されるアップデートの種類ごとに、予め特定の方法に決められていてもよい。例えば、アップデートの「種類」のうち「第１種」のアップデートの要求は多くの方法（例えば用意された要求方法の全て）で可能である一方、「第１種」以外の「第２種」のアップデートは、警報器１００に実際に受け付けられる要求方法が制限されてもよい。例えば、第２種のアップデートの要求は、図４に示される被操作部５に触れるような直接的な所定の操作Ｍ１や、警報器１００の近傍の専用端末類Ｐｎからの近距離通信による要求などに制限されてもよい。すなわちその場合には、外部機器Ｅや遠方の端末Ｐｒからの、ネットワークＮや基地局Ｂなどを経由した信号によるアップデートの要求は受け付けられない。一方、第１種のアップデートについては、第２種のアップデートの要求が受け付けられる方法に加えて、外部機器Ｅや遠方の端末Ｐｒからの、ネットワークＮや基地局Ｂなどを経由した信号によるものでも受け付けられてもよい。或いは、第１種のアップデートは、外部機器Ｅや遠方の端末Ｐｒからの信号による要求に限定され、被操作部５に触れるような直接的な所定の操作Ｍ１や、警報器１００の近傍の専用端末類Ｐｎからの近距離通信による要求が受け付けられなくてもよい。

このように本実施形態の警報器は、要求されるアップデートの種類に応じて、警報器に対して行われる所定の指示操作に基づいてアップデートを実行するか、外部機器からの信号の受信に基づいてアップデートを実行するように構成されていてもよい。そのようにアップデートの種類に応じて、警報器１００が受け付ける要求方法を区別することによって、例えば、必要性の高いアップデートの適宜の実行を担保しつつ、アップデートによる警報器１００の警報発報機能の低下リスクを軽減し得ることがある。また、アップデートの要求元として適した要求元からのアップデートの要求に絞って、要求されたアップデートを実行することができる。

上記の「警報器に対して行われる所定の指示操作」は、前述した被操作部５に触れるような直接的な所定の操作Ｍ１や、警報器１００の近傍の専用端末類Ｐｎへのアップデートを指示する操作であり得る。

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

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

ここで上記のアップデートの「種類」は、一例として、アップデートの重要性や緊急性の程度を意味し得る。例えば、重要性や緊急性の高いアップデートが第１種のアップデートに含まれ、「第１種」以外のアップデートが第２種のアップデートに含まれてもよい。

また、アップデートの「種類」は、アップデートの対象となる警報器１００の機能によって区分されてもよい。例えば、警報器１００の報知機能に関するアップデート（又は制御部１０に関するアップデート）が第１種のアップデート及び第２種のアップデートの一方に含まれ、通信部２０に関するアップデート（第１アップデート）が、その他方に含まれてもよい。一例として、制御部１０に関するアップデートの要求は「警報器に対して行われる所定の指示操作」に基づいて実行されてもよい。報知機能を制御する制御部１０に関するアップデートの実行を、警報器１００の周囲環境を把握し得る警報器１００の近傍のユーザーによる要求に基づいて実行することができる。また、通信部２０に関するアップデート（第１アップデート）は「外部機器からの信号の受信」に基づいて実行されてもよい。外部機器Ｅにおいて、通信制御方式の変更があった場合において、その外部機器Ｅからの要求に基づいて、通信に関するアップデートを実行することができる。

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

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

＜アップデートの制限＞
本実施形態の警報器１００は、前述した要求方法自体が受け容れ可能な要求方法であっても、要求されるアップデートを現に実行するか否かを、上記に例示されるようなアップデートの内容に基づいて判断するように構成されていてもよい。例えば、周囲環境が警報を発する状況に近付いている場合には、警報発報に至っても外部機器Ｅに通知されない状態となるアップデートを開始しないことが好ましいことがある。従って、例えば警報器１００が警報を発報すべき状態よりも異常度が低い状態に対応する閾値（予備閾値）をさらに有していてもよい。加えて、アップデートの具体的な内容ごとにアップデート実行の優先度が設定されてよい。そして、検知対象であるガスの濃度や温度などの検出値が予備閾値を超えると、例えば通信セキュリティの確保に関する仕様の変更や致命的なバグの修正といった優先度の高い内容のアップデートだけが実行されてもよい。その他のアップデートは、検知対象の検出値が予備閾値以下の場合に実行されてもよい。

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

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

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

電池の残量に基づいてアップデートの実行を判断するように構成される場合、本実施形態の警報器１００は、さらに、前述したようなアップデートの内容にも応じて、要求されるアップデートを実行するか否かを判断するように構成されてもよい。この場合も、アップデートの具体的な内容ごとにアップデート実行の優先度が設定され得る。例えば、所定の閾値を超える電池残量が保持されている場合に、要求されるアップデートが、その内容の如何を問わず実行されるのではなく、例えば、通信セキュリティの確保に関する仕様の変更や致命的なバグの修正といった優先度の高い内容のアップデートだけが実行されてもよい。そして、その他のアップデートは、さらに多くの電池残量が保持されている場合に実行されてもよい。

従って、実施形態の警報器１００は、アップデートを実行するか否かの判断基準となる複数の電池残量の閾値を有していてもよい。そして、アップデート要求時の電池残量と各閾値との大小関係及び現に要求されるアップデートの優先度に応じて、要求されるアップデートを実行するか否かが判断されてもよい。例えば、アップデート要求時の電池残量が特定の閾値の範囲内にある場合、一定以上の優先度を有するアップデートが実行され、優先度の低いアップデートが保留又は却下されてもよい。

図５には、アップデートの優先度及び電池残量に応じたアップデートの実行の判断の一例が示されている。図５に示される表の各列（縦方向）には、電池残量ｅと三つの閾値Ｔ１～Ｔ３（Ｔ１＜Ｔ２＜Ｔ３）との大小関係が示されている。そして各行には、第１優先から第３優先（優先度高：第１優先＞第２優先＞第３優先：優先度低）それぞれを有するアップデートが実行されるか否かが「Ｙ」（実行）又は「Ｎ」（非実行）で示されている。例えば、電池残量ｅが、最も小さい閾値Ｔ１以下である場合は、電池の延命が優先されていずれのアップデートも実行されない。しかし、電池残量ｅが閾値Ｔ１よりも大きく閾値Ｔ２以下であれば第１優先アップデートが実行され、電池残量ｅが閾値Ｔ２よりも大きく閾値Ｔ３以下であると、さらに第２優先アップデートも実行される。そして、電池残量ｅが閾値Ｔ３よりも大きければ、全てのアップデートが実行される。なお、警報器１００は、特定の優先度のアップデートが実行されない場合、その特定の優先度より低い優先度のアップデート要求を受け付けないように構成されていてもよい。

優先度の高いアップデートは、例えば、前述した、通信セキュリティの確保に関する仕様の変更や、報知機能や通信を高度に損なわせる致命的なバグの修正の他、警報発報基準の変更、セキュリティスタックのバージョンアップなどであり得る。電池寿命を延ばして、警報器１００をセンサの保証期間満了まで稼働させるという観点では、消費電力低減のためのアップデートも高い優先度を有し得る。一方、優先度の低いアップデートとしては、報知態様の変更、自主点検項目の変更や定期通信の頻度の変更などが例示される。しかし、如何なるアップデートが高い又は低い優先度を有するかは、警報器１００の設置環境や警報器１００の仕様などに応じて任意に決定され得る。

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

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

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

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

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

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

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

＜一実施形態の警報器の変形例＞
図７には、一実施形態の警報器の変形例である警報器１０１の主要な構成要素がブロック図で示されている。図７において、図１の例の警報器１００の構成要素と同様の構成要素については、図１に付された符号と同じ符号が付されるか省略され、その構成要素に関する繰り返しとなる説明は省略される。警報器１０１は、図１の警報器１００の第１処理装置１ａの機能と第２処理装置２ａの機能とを併せ持つ単一の処理装置１を備えている点で、図１に示される警報器１００と異なっている。すなわち、警報器１０１は、報知機能の制御及び通信の制御の両方を担う処理装置１を備えている。しかし、処理装置１の内部が、制御部１０を担う部分（第１処理部１α）と通信部２０を担う部分（第２処理部１β）とに区分されている。

警報器１０１の処理装置１では、図７に示される記憶手段１ｂ、記憶手段２ｂ、及び計時手段２ｃのように処理装置１を構成するＣＰＵやメモリなどの各ハードウェア資源が、報知機能を担う第１処理部１α及び通信機能を担う第２処理部１βのいずれかに割り当てられている。図７に示される記憶手段１ｂ、記憶手段２ｂ、及び計時手段２ｃは、それぞれ、図１の例の記憶手段１ｂ、記憶手段２ｂ、及び計時手段２ｃと同様の機能を有している。そして、図７の例において、記憶手段１ｂは第１処理部１αに属し、記憶手段２ｂ及び計時手段２ｃは、第２処理部１βに属している。図１の警報器１００と同様に、記憶手段１ｂには、報知機能に関する命令を含むソフトウェアＳＷ１が内蔵されており、記憶手段２ｂには、通信機能に関する命令を含むソフトウェアＳＷ２が内蔵されている。

警報器１０１の処理装置１では、メモリなどの各ハードウェア資源単位で、第１処理部１α又は第２処理部１βに割り当てられるのではなく、ハードウェア資源それぞれの内部が、報知機能を担う部分と通信機能を担う部分とに仕切られていてもよい。例えば、各記憶手段の記憶領域が、ソフトウェアＳＷ１のような報知機能に関する情報を記憶する領域と、ソフトウェアＳＷ２のような通信機能に関する情報を記憶する領域とに仕切られていてもよい。また、各記憶手段内の各種のレジスタ領域が、報知機能に関わる情報の記憶領域と通信機能に関わる情報の記憶領域とに分けられていてもよい。また、処理装置１を構成する複数の入出力ポートが、報知機能を担うポートと通信機能を担うポートとに分けられていてもよい。

なお、図７の例において処理装置１は、さらに報知機能及び通信機能以外の機能を担っていてもよく、また、報知機能及び通信機能それぞれの機能がさらに細分化されていてもよい。すなわち処理装置１は、３つ以上の機能を有していてもよく、それぞれに割り当てられた機能を担う三つ以上の部分に区分されていてもよい。そして処理装置１内のメモリなどの各ハードウェア資源が、３つ以上の部分のいずれか１以上に割り当てられてもよく、各資源の内部が、３つ以上の機能のいずれか担う部分毎に仕切られていてもよい。

さらに、警報器１０１において処理装置１は、ＣＰＵに複数のコアを有するマルチコアタイプのマイコンであってもよく、複数のコアの一つが報知機能に宛てがわれ、他の一つが通信機能に宛てがわれてもよい。そのようにして、処理装置１の内部が、制御部１０を担う部分と通信部２０を担う部分とに区分されていてもよい。

図７の警報器１０１は、このように、図１の警報器１００と違って、報知機能及び通信機能の両方を制御する処理装置１を備えているが、その内部が制御部１０を担う部分と通信部２０を担う部分とに区分されている。そのため、警報器１０１においても、ソフトウェアＳＷ１のアップデートは通信機能に影響し難く、ソフトウェアＳＷ２のアップデートは報知機能に影響し難いと考えられる。例えば、前述したように、ソフトウェアＳＷ１のアップデート時には、通信部２０は通信などが可能な状態を維持することができる。また、ソフトウェアＳＷ２のアップデート時には、制御部１０は報知機能を維持することができる。そして、警報器１０１では、制御部１０及び通信部２０のいずれも処理装置１で主に構成されているので、制御部１０と通信部２０とを跨ぐような処理が高速に行われると考えられる。

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

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

１００、１０１警報器
１処理装置
１α 第１処理部
１β 第２処理部
１ａ第１処理装置
１ｂ記憶手段
１０制御部
２ａ第２処理装置
２ｂ記憶手段
２０通信部
５被操作部
Ｅ外部機器
ＳＷ１、ＳＷ２ソフトウェア

Claims

内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記通信部によって無線で前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第１アップデートの実行中に前記周囲環境の異常を検知すると、無線による前記通知を行わずに警報を発する、警報器。
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第１アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記制御部は、前記第１アップデートを実行している期間と実行していない期間との間で、前記周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されている、警報器。
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第１アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記制御部は、前記周囲環境の異常の検知時にメッセージを発するように構成されており、
前記制御部は、前記第１アップデートを実行している期間と実行していない期間との間で、前記メッセージを発する態様を異ならせるように構成されている、警報器。
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、
前記アップデートのうちの前記通信部に関する第１アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、且つ、
前記第１アップデートの開始時に、前記第１のアップデートを開始することを前記外部機器に知らせるように構成されている、警報器。
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第１アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記周囲環境の異常の検知に応じて発せられた警報が、外部からの停止操作によって停止可能であり、
前記第１アップデートを実行している期間と実行していない期間との間で、前記停止操作として受け容れられる操作が異なっている、警報器。
前記警報器は、前記アップデートの種類に応じて、前記警報器に対して直接又は前記警報器の近傍で行われる手動による所定の指示操作に基づいて前記アップデートを実行するか、前記外部機器からの信号の受信に基づいて前記アップデートを実行するように構成されている、請求項１～５のいずれか１項に記載の警報器。
前記制御部は、前記周囲環境の異常の検知前に開始された前記第１アップデートが警報発報中に終了すると、前記通知を行うように構成されている、請求項１～５のいずれか１項に記載の警報器。
前記制御部は、前記第１アップデートの実行中に前記周囲環境の異常の検知によって発した警報が前記第１アップデートの終了前に停止されたときは、前記第１アップデートの終了後に、前記第１アップデートの実行中に警報を発したことを前記外部機器に報せるように構成されている、請求項１～５のいずれか１項に記載の警報器。