(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024131784
(43)【公開日】2024-09-30
(54)【発明の名称】警報器
(51)【国際特許分類】
G08B 25/00 20060101AFI20240920BHJP
【FI】
G08B25/00 510B
【審査請求】有
【請求項の数】8
【出願形態】OL
(21)【出願番号】P 2023042246
(22)【出願日】2023-03-16
(11)【特許番号】
(45)【特許公報発行日】2024-04-23
(71)【出願人】
【識別番号】000190301
【氏名又は名称】新コスモス電機株式会社
(74)【代理人】
【識別番号】110001896
【氏名又は名称】弁理士法人朝日奈特許事務所
(72)【発明者】
【氏名】齋藤 和也
【テーマコード(参考)】
5C087
【Fターム(参考)】
5C087AA14
5C087AA16
5C087AA35
5C087AA37
5C087AA38
5C087DD04
5C087DD07
5C087EE14
5C087FF04
5C087FF19
5C087GG07
5C087GG66
5C087GG70
(57)【要約】
【課題】警報器の報知機能への影響を抑制しながら、通信制御技術の向上に追随した通信を継続させて警報を広範に届けることができる警報器を提供する。
【解決手段】実施形態の警報器100は、内蔵するソフトウェアSW1、SW2に含まれる命令に従って動作する警報器である。警報器100は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部10と、外部機器Eとの間の交信を制御する通信部20と、を備え、ソフトウェアSW2は、警報器100の使用開始後にアップデートが可能なように内蔵されており、制御部10は、周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを外部機器Eに報せる通知を行うように構成されており、制御部10は、アップデートのうちの通信部20に関する第1アップデートの実行中に周囲環境の異常を検知すると、警報発報中であることを外部機器Eに報せる通知を行わずに警報を発する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発する、警報器。
【請求項2】
前記制御部は、前記第1アップデートの開始時に、前記通知を行わないモードに移ることを前記外部機器に報せるように構成されている、請求項1記載の警報器。
【請求項3】
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されている、請求項1又は2記載の警報器。
【請求項4】
前記制御部は、前記周囲環境の異常の検知時にメッセージを発するように構成されており、
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記メッセージを発する態様を異ならせるように構成されている、請求項3記載の警報器。
【請求項5】
前記周囲環境の異常の検知に応じて発せられた警報が、外部からの停止操作によって停止可能であり、
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記停止操作による警報停止の容易性を異ならせるように構成されている、請求項1又は2記載の警報器。
【請求項6】
前記警報器は、前記アップデートの種類に応じて、前記警報器に対して行われる所定の指示操作に基づいて前記アップデートを実行するか、前記外部機器からの信号の受信に基づいて前記アップデートを実行するように構成されている、請求項1又は2記載の警報器。
【請求項7】
前記制御部は、前記周囲環境の異常の検知前に開始された前記第1アップデートが警報発報中に終了すると、前記通知を行うように構成されている、請求項1又は2記載の警報器。
【請求項8】
前記制御部は、前記第1アップデートの実行中に前記周囲環境の異常の検知によって発した警報が前記第1アップデートの終了前に停止されたときは、前記第1アップデートの終了後に、前記第1アップデートの実行中に警報を発したことを前記外部機器に報せるように構成されている、請求項1又は2記載の警報器。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、周囲環境を監視する警報器に関する。
【背景技術】
【0002】
従来、工場や住宅における火災やガス漏れなどを検知して警報を発する警報器には、温度や、各種のガスの存在などを検知するセンサなどの感知手段と、その検知結果に基づいて異常の有無を判断するマイコンなどの制御手段と、制御手段の判断結果に基づいて光や音声などを警報として発する報知手段などが備えられている。このような警報器には、近年、外部との間で情報を送受信するための通信手段がさらに備えられ、外部機器、例えば、他の警報器と連携して動作したり、インターネット上のサーバーなどと情報交換をしたりしながら周囲環境を監視することも行われている。
【0003】
例えば、特許文献1には、複数の警報器が無線通信で警報情報を共有することにより連動して警報を発する警報システムにおいて、親局としての動作と子局としての動作とを切り替えられる無線式警報器が開示されている。
【先行技術文献】
【特許文献】
【0004】
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記のように警報器がその外部の機器と通信回線で接続されると、例えば、ガス漏れなどの検知時に、警報器自身が音や光などで警報を発するだけでなく、外部の機器を通じて、遠隔地にいるユーザーやその関係者にもガス漏れなどの異常の発生を速やかに報せることができる。一方、このような情報通信の分野では、その利用範囲の拡大や送受されるデータ量の膨張に伴って、通信プロトコルや、それに基づく通信制御プログラムにおいて常にバージョンアップが重ねられている。また、そのように通信によって送受される情報を標的として、通信回線を介したハッキングやネットワーク上での盗聴などといった、通信のセキュリティを脅かす悪意のある技術が、日々新たに生み出され、また変異を続けている。このような通信のセキュリティを阻害する新種の技術への耐性を備える面からも、通信制御プログラムの継続的なバージョンアップが行われている。そのため、通信機能を有する警報器には、このように進化を続ける通信制御技術に絶えず追随することが求められ、さもなければ、例えば、通信のセキュリティを脅かす悪意のある技術の脅威に晒されることとなり得る。しかしながら、警報器の特性上、通信制御プログラムのバージョンアップの際に、警報器の本質的機能である報知機能が機能しない期間があるのは好ましくない。
【0006】
本発明は、上記問題に鑑みてなされたもので、警報器の報知機能への影響を抑制しながら、通信制御技術の向上に追随した通信を継続させて警報を広範に届けることができる警報器を提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明の警報器は、内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、外部機器との間の交信を制御する通信部と、を備え、前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発する。
【0008】
前記制御部は、前記第1アップデートの開始時に、前記通知を行わないモードに移ることを前記外部機器に報せるように構成されていてもよい。
【0009】
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されていてもよい。
【0010】
前記制御部は、前記周囲環境の異常の検知時にメッセージを発するように構成されており、前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記メッセージを発する態様を異ならせるように構成されていてもよい。
【0011】
前記周囲環境の異常の検知に応じて発せられた警報が、外部からの停止操作によって停止可能であり、前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記停止操作による警報停止の容易性を異ならせるように構成されていてもよい。
【0012】
前記警報器は、前記アップデートの種類に応じて、前記警報器に対して行われる所定の指示操作に基づいて前記アップデートを実行するか、前記外部機器からの信号の受信に基づいて前記アップデートを実行するように構成されていてもよい。
【0013】
前記制御部は、前記周囲環境の異常の検知前に開始された前記第1アップデートが警報発報中に終了すると、前記通知を行うように構成されていてもよい。
【0014】
前記制御部は、前記第1アップデートの実行中に前記周囲環境の異常の検知によって発した警報が前記第1アップデートの終了前に停止されたときは、前記第1アップデートの終了後に、前記第1アップデートの実行中に警報を発したことを前記外部機器に報せるように構成されていてもよい。
【発明の効果】
【0015】
本発明によれば、警報器の報知機能への影響を抑制しながら、通信制御技術の向上に追随した通信を継続させて警報を広範に届けることができる。
【図面の簡単な説明】
【0016】
【
図1】本発明の一実施形態の警報器の一例の概略を示すブロック図である。
【
図2】一実施形態の警報器の記憶領域の構成及び記憶内容の一例を示す模式図である。
【
図3】一実施形態の警報器の動作の一例を示すフローチャートである。
【
図4】一実施形態の警報器におけるアップデートの要求方法の例を示す模式図である。
【
図5】一実施形態の警報器におけるアップデートの優先度と電池残量に応じた実行の判断との対応の一例を示す図である。
【
図6】一実施形態の警報器と外部機器との間のデータ伝送単位のデータ構造例を示す図である。
【
図7】一実施形態の警報器の変形例の概略を示すブロック図である。
【発明を実施するための形態】
【0017】
以下、添付図面を参照しながら、本発明の一実施形態に係る警報器を説明する。但し、以下に説明される実施形態及び添付の図面は、本発明に係る警報器の一例を示しているに過ぎない。本発明に係る警報器の構成及び作用は、以下に説明される実施形態及び添付の図面に例示される構成及び作用に限定されない。
【0018】
<一実施形態の警報器の基本構成及び作用>
図1には、本発明の一実施形態の警報器100の主要な構成要素がブロック図で示されている。一実施形態の警報器100は、例えば、住居や工場などに設置されたり、使用者に携帯されたりして、警報器100の周囲の環境を監視する。そして、警報器100は、周囲の環境が特定の状態にある場合にはそれを検知して、例えば、警報を発したり、信号を送ったりして、周囲環境が特定の状態、例えば人体や物的資産に危害が及び得る異常な状態にあることを周囲の人や所定の機器に報せる。特定の状態としては、火災の発生、ガス漏れ、一酸化炭素の充満、煙の充満、過剰な温湿度、などが例示されるが、警報器100が検知する特定の状態は、これらに限定されない。
【0019】
警報器100は、
図1に示されるように、制御部10と、通信部20と、制御部10及び通信部20が要する電力を供給する電源部3と、例えば警報器100のユーザーなどに操作される被操作部5と、を備えている。制御部10は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する。すなわち制御部10は、警報器100が有する本質的な機能である、周囲環境の監視から監視結果に基づく例えば警報の発報といった報知までの機能を制御する。通信部20は、信号の送信及び受信のような警報器100と外部機器Eとの間の交信を含む、警報器100の通信機能を制御する。
【0020】
制御部10は第1処理装置1aを含んでいる。第1処理装置1aは、周囲環境を監視して監視結果に基づく報知を行う報知機能の制御を担う半導体装置によって構成されている。第1処理装置1aは記憶手段1bを有している。通信部20は第2処理装置2aを含んでいる。第2処理装置2aは、警報器101と外部機器Eとの間の通信の制御を担う半導体装置によって構成されている。第2処理装置2aは、記憶手段2b及び計時手段2cを有している。制御部10と通信部20とは、互いに相手方との間で信号の送受が可能なように接続されている。
【0021】
通信部20は、無線回線C1又は有線回線C2を介して外部機器Eとの間で直接送受信を行ってもよく、無線回線C1又は有線回線C2で接続された、例えばインターネットやローカルエリアネットワーク(LAN)などのネットワークNを介して外部機器Eとの間で送受信を行ってもよい。外部機器Eとしては、警報器100以外の同種、又は検知対象の異なる警報器が例示される。外部機器Eは、警報器100の動作を監視若しくは制御する、及び/又は、警報器100での検知結果若しくは警報発報経過を収集して統計処理若しくは解析する、サーバーのような情報処理装置であってもよい。しかし、外部機器Eはこれらに限定されない。
【0022】
電源部3は、制御部10及び通信部20を含む、警報器100の内部の各構成要素に電力を供給する。電源部3は、例えば、商用電源(図示せず)から供給される電力を各構成要素に供給する。その場合、電源部3は、例えば、商用電源から供給される交流電力を所望の電圧の直流電力に変換するインバータや、警報器100内の構成要素に印加される電源電圧を安定化させる電圧レギュレータなどによって構成され得る。電源部3は、商用電源からの電力ではなく、例えば乾電池などの一次電池やバッテリなどの二次電池からの直流電力を警報器100内の各構成要素に供給してもよい。すなわち、警報器100は、電池式の警報器であってもよく、特に再充電不能な一次電池の電力で駆動する警報器であってもよい。
【0023】
本実施形態の警報器100は、ソフトウェアSW1、SW2を内蔵していて、ソフトウェアSW1、SW2に含まれる命令に従って動作する。
図1の例において、ソフトウェアSW1は、第1処理装置1aが有する記憶手段1bに格納されている。ソフトウェアSW2は、第2処理装置2aが有する記憶手段2bに格納されている。従って、具体的には第1処理装置1a乃至は制御部10が、ソフトウェアSW1に含まれる命令に従って動作して、警報器100の報知機能を制御する。そして、第2処理装置2a乃至は通信部20が、ソフトウェアSW2に含まれる命令に従って動作して、警報器100の通信機能を制御する。なお、本実施形態において警報器100は、第1及び第2の処理装置1a、2aが実行するソフトウェアSW1、SW2を格納するROMなどの記憶手段(図示せず)を、第1及び第2の処理装置1a、2aとは別に備えていてもよい。
【0024】
本実施形態の警報器100では、少なくともソフトウェアSW2は、警報器100の使用開始後に、要求に応じたソフトウェアSW2のアップデートが可能なように内蔵されている。警報器100では、ソフトウェアSW1も、警報器100の使用開始後にアップデートが可能なように内蔵されていてもよい、以下では、ソフトウェアSW2だけでなく、ソフトウェアSW1のアップデートも可能なものとして、本実施形態の警報器が説明される。警報器100が従う命令を含むソフトウェアSW1、SW2のアップデートが警報器100の使用開始後にも可能なので、例えば、適合すべき法規の変更や、外部機器Eとの通信に用いる通信規格の変更などに応じて、各ソフトウェアをアップデートして、警報器100を適切に動作させることができる。すなわち、適法な警報動作、及び/又は、通信制御技術の向上に追随した通信を継続させることができる
【0025】
また、本実施形態の警報器100において制御部10は、周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを外部機器Eに報せる通知を行うように構成されている。そのため、警報器100の周囲だけでなく、警報を広範に届けることができる。例えば、遠方のユーザーや、その関係者にも警報器100の周囲が特定の異常な環境にあることを報せることができる。従って、異常状態の解消に向けた迅速な措置を促すことができ、損害の発生や被害の拡大を防止できることがある。
【0026】
さらに、本実施形態では、制御部10及び通信部20それぞれがソフトウェアSW1、SW2を第1処理装置1a、第2処理装置2aそれぞれに内蔵しているので、ソフトウェアSW1のアップデート時には、通信部20は外部機器Eとの通信などが可能な状態を維持することができる。また、ソフトウェアSW2のアップデート時には、制御部10は報知機能を維持することができる。一方、ソフトウェアSW2のアップデート中は、外部機器Eとの交信が不能になることがある。そのため、警報器100において制御部10は、警報器100に内蔵されるソフトウェアのアップデートのうちの通信部20に関するアップデートの実行中に周囲環境の異常を検知すると、警報発報についての外部機器Eへの通知は行なわずに警報を発するように構成されている。すなわち、
図1の例では、ソフトウェアSW2のアップデートの実行中に周囲環境の異常が検知されると、外部機器Eへの警報発報の通知は行われずに、警報器100自らが放出する例えば音声や光による警報が発せられる。なお「通信部20に関するアップデート」は、以下では「第1アップデート」とも称される。
【0027】
従って、外部機器Eに警報の発報は知らされないものの、少なくとも警報器100の近傍のユーザーには、通信部20に関するソフトウェアSW2のアップデート中であっても、異常状態の発生を報せることができる。換言すると、警報器100の近傍のユーザーまで、異常の発生が知らされない危険な状態に置くことなくソフトウェアSW2のアップデートを継続させることができる。すなわち、警報器100の報知機能への影響を少なくしながら、通信部20に関する必要なアップデートを完遂させることによって、引き続き、通信制御技術の向上に追随した通信を行うことができる。
【0028】
このように、本実施形態の警報器は、警報の発報時に外部機器に警報の発報を通知するモードと、そのような通知をしないモードとの少なくとも二つの動作モードを有している。警報器100の動作モードは、例えば、通信部20に関するアップデートの実行中か否かによってこの二つのモードの間で遷移する。なお、本明細書において「警報器100(又は、制御部10、通信部20、若しくはこれら以外の各構成要素)が特定の動作又は処理を行うように(又は行わないように)構成される」は、警報器100などにその特定の動作又は処理を行わせる(又は行わせない)命令が、警報器100などの動作や処理を記述するプログラムに、すなわちソフトウェアSW1、SW2に含まれていることを含んでいる。
【0029】
<制御部の構成>
本実施形態の警報器の構成及び作用が、以下にさらに詳細に説明される。
図1の例において制御部10は、検知部12と、報知部13と、前述した第1処理装置1a及びその周辺回路(図示せず)と、を備えている。
【0030】
検知部12は、主に、警報器100の周囲の監視対象領域の物理現象を監視して監視データを出力する各種のセンサから構成される。各種のセンサは、たとえば、一酸化炭素ガス(CO)、メタンガス(CH4)又はプロパンガス(C3H8)を検知する各種ガスセンサ、サーミスタなどからなる温度センサ、湿度センサ、煙センサ、又は臭気センサなどであってよい。検知部12は、これらセンサの1つ又は複数で構成され得る。例えば、各種のガスセンサによってガス漏れが検知される場合、警報器100はガス警報器であり得、温度センサ及び煙センサなどによって火災の発生が検知される場合、警報器100は火災警報器であり得る。
【0031】
報知部13は、例えば、発光ダイオード、ディスプレイ、ブザー及び/又はスピーカーなどの、警報器100のユーザーなどへの報知手段により構成され、光の放射、鳴動、及び/又は音響を発することにより警報を発する。また、報知部13は、警報を発する以外にも、警報器100の状態や、警報を発するに至らない監視領域の環境に関する情報をユーザーなどに伝えるために動作してもよい。
【0032】
第1処理装置1aは、マイコンやASICなどの半導体装置からなり、ソフトウェアSW1のような内蔵されたプログラムに従って動作する。なお、警報器100が第1処理装置1aと別にROMなどの記憶装置(図示せず)を備える場合は、処理装置1は、この外部の記憶装置に格納されたプログラムに従って動作してもよい。第1処理装置1aは、好ましくは、演算機能、比較機能、記憶機能などを有している。第1処理装置1aは、検知部12及び報知部13の動作を含む、警報器100の報知機能に関する動作を全体的に制御する。例えば第1処理装置1aは、検知部12から得られる検知データが示す、一酸化炭素やガスの濃度、周囲の温度、及び、煙の濃度などが、所定の閾値を超えているか否かを判断する、そして、温度や濃度などが閾値を超えている場合には、例えばその超過の程度に応じて決定した態様で報知部13に報知を実行させる。
【0033】
図1の例の第1処理装置1aが備える記憶手段1bは、第1処理装置1aでの処理に必要な任意の情報を記憶する。記憶手段1bは、第1処理装置1aに組み込まれた、ROM、PROM(プログラマブルROM)、RAM、フラッシュメモリ、及び各種のレジスタなどのメモリ空間であり得る。例えば、記憶手段1bを構成し得るEPROM(イレーサブルPROM)に、ソフトウェアSW1が格納されていてもよい。記憶手段1bには、ソフトウェアSW1の他、例えば、警報発報の判断基準であって検知部12の検知データと比較される閾値、この閾値と検知データとの比較結果に対応付けられた報知部13での報知態様、及び、通信部20の状態に関する情報、などが記憶される。
【0034】
<通信部の構成>
図1の例において通信部20は、第2処理装置2a及びその周辺回路(図示せず)と、送受信部22とを備えている。送受信部22は、無線通信又は有線通信によって外部機器Eとの間で信号を送受する。送受信部22は、外部機器Eと警報器100との間で電気信号を送受するように構成された、集積回路装置や個々の部品からなる電気回路などのハードウェア(例えば、ASICなどからなる通信制御IC又はモデムIC、及びその周辺回路など)により構成される。送受信部22によって、送受信信号の変換、増幅、変調/復調、並びに外部機器Eとの間のリンクの設定などが行われる。なお、送受信部22は、第2処理装置2aの一部によって構成されていてもよい。
【0035】
第2処理装置2aは、マイコンやASICなどの半導体装置からなり、ソフトウェアSW2のような内蔵されたプログラムに従って動作する。第2処理装置2aは、警報器100の動作中に送受信部22で行われる、警報器100と外部機器Eとの間での交信に必要な動作を全体的に制御する。例えば、第2処理装置2aは、警報器100における周囲環境の監視結果に基づいて実行される報知に関する情報を外部機器Eに送る動作を制御してもよい。この「報知に関する情報」は、警報器100において監視結果に基づいて実行される報知に関するものであれば、特に限定されない。例えば、「報知に関する情報」は、検知部12で得られる逐次若しくは継続的な検知データ、周囲環境が特定の状態にあると判断する閾値(警報発報基準)、警報の発報履歴、及び、警報器100の状態(例えば正常状態で通常の監視実行中、電池式の場合の電池残量若しくは電池切れ、故障中、及び、警報発報中など)、などであり得る。第2処理装置2aは、さらに、上記「報知に関する情報」以外の情報を外部機器Eに送る動作を制御してもよく、警報器100の制御に関する情報などの任意の情報を外部機器Eから受け取る動作を制御してもよい。
【0036】
通信部20は、通常の監視の実行中、電池残量、故障中、及び、警報発報中などの上記「警報器100の状態」を所定の周期で外部機器Eに送る通信(定期通信)を行うように構成されていてもよい。定期通信を行うことによって、外部機器Eから適時に適切な制御を受け得ることがある。所定の周期は、警報器100の検知対象や使用場所などによって適宜選択される。所定の周期は、例えば数分程度であってもよく、数時間、あるいは数日程度であってもよい。
【0037】
図1の例において第2処理装置2aが備える記憶手段2bは、第2処理装置2aで実行される処理に必要な任意の情報を記憶する。記憶手段2bは、第2処理装置2aに組み込まれた、ROM、PROM、RAM、フラッシュメモリ、及び各種のレジスタなどのメモリ空間であり得る。例えば、記憶手段2bを構成し得るEPROMに、ソフトウェアSW2が格納されていてもよい。
【0038】
図1の例において第2処理装置2aが備える計時手段2cは、例えば、特定の時点からの経過時間をカウントする。計時手段2cは、例えば第2処理装置2aを構成するマイコンなどの半導体装置に構成されたカウンタやタイマであり得る。計時手段2cは、例えば、通信部20が行う前述した「定期通信」において、最後に警報器100の状態が送られてからの経過時間をカウントしてもよい。
【0039】
被操作部5は、例えば、警報器100のユーザーや管理者などによる操作が可能なように警報器100に設けられている。被操作部5に対して、種々の所定の動作の実行を警報器100に指示する各種の手動操作が行われる。例えば、被操作部5に対して、ソフトウェアSW1又はソフトウェアSW2のアップデートを要求する、手動操作による所定の指示操作が行われる。被操作部5に対して、各ソフトウェアのアップデート以外の所定の動作を指示する操作が行われてもよい。被操作部5に対する操作による指示は、電気信号などによって第1処理装置1a及び/又は第2処理装置2aに伝えられ、各処理装置で、被操作部5への操作によって指示された動作が実行される。例えば、ソフトウェアSW1又はソフトウェアSW2のアップデートが要求されたなら、該当するソフトウェアのアップデートが実行され得る。
【0040】
被操作部5としては、警報器100に外部から視認及び接触可能に設けられた各種のスイッチが例示される。被操作部5として用いられるスイッチとしては、押し釦スイッチやトグルスイッチなどが例示されるが、これらに限定されない。また、被操作部5は、タッチパネルやキーパッドのような入力装置であってもよい。
【0041】
被操作部5として用いられるスイッチは、操作中のみ押し込まれて、操作が終了すると自動復帰するタクタイルスイッチが好ましいことがある。被操作部5がタクタイルスイッチで構成されている場合、押し込まれる時間の長さの違いによって、2種類以上の動作がそれぞれ指示されてもよい。例えば、押し込まれる時間が2秒未満の押し込み操作は、警報器100の自主点検の要求と認識され、2秒以上5秒未満の押し込み操作は、発報中の警報の停止指示と認識され、5秒以上の押し込み操作は、ソフトウェアSW1及び/又はソフトウェアSW2のアップデートの要求と認識されてもよい。
【0042】
<ソフトウェアのアップデート>
アップデートが可能なソフトウェアSW2は、記憶手段2bとして備えられるEPROM、好ましくは、EEPROM(エレクトリカリー・イレーサブルPROM)やフラッシュメモリなどに格納されている。ソフトウェアSW1も、記憶手段1bとして備えられているEEPOMやフラッシュメモリに格納されていてもよい。EEPROM及びフラッシュメモリなどでは、例えば高電圧の印加などによって、既に記憶されている内容を書き換えることができる。例えばこのように、EEPROMやフラッシュメモリなどで構成される書き換え可能な記憶領域にソフトウェアSW1、SW2を格納することによって、警報器100の使用開始後であっても、ソフトウェアSW1、SW2のアップデートの実行が可能となる。例えば、第2処理装置2aが備えるCPU(図示せず)の制御の下で、記憶手段2bとして備えられているフラッシュメモリなどの記憶内容が書き換えられ、その結果、ソフトウェアSW2がアップデートされる。
【0043】
ソフトウェアSW1、SW2は、第1処理装置1a、第2処理装置2aそれぞれが行う動作に関する命令が記述された制御プログラムなどのソフトウェアを含み得る。ソフトウェアSW1、SW2は、それぞれ、第1処理装置1a又は第2処理装置2aのメモリ(例えばEEPROMやフラッシュメモリで構成される記憶手段1b又は記憶手段2b)に書き込まれている、各処理装置に関するファームウェアであってもよい。警報器100の使用開始後にもアップデート可能なソフトウェアSW1、SW2が各処理装置に関するファームウェアであると、例えば、法規の変更や通信規格の改定などによって各処理装置による基本的な制御方式の変更が求められる場合でも、その変更に容易に対応することができる。
【0044】
特に、警報器を含む各種機器間の通信において準拠される通信規格は、セキュリティ要件などに関して適宜改定されている。また通信規格は、新たに開発される通信技術を取り入れるべく改定されることもある。警報器100には、少なくともソフトウェアSW2が、アップデートが可能なように内蔵されているので、前述したように、適合すべき法規の変更や、外部機器Eとの通信に用いる通信規格の変更などに応じたアップデートの実行によって、例えば、警報器100と外部機器Eとの適式で信頼性の高い通信を継続させることができる。
【0045】
前述したように外部機器Eとの間で無線での交信も可能な通信部20を含む警報器100では、ソフトウェアSW1、SW2のアップデートは、外部機器Eと通信部20との無線通信に基づいて行われてもよい。すなわち、ソフトウェアSW1、SW2のアップデートは、所謂「OTA(Over-The-Air)アップデート」であってもよく、前述したようにソフトウェアSW1、SW2がファームウェアである場合は、「ファームウェアOTA」であってもよい。その場合、例えば、遠隔地からでもソフトウェアSW1、SW2をアップデートすることができる。
【0046】
なお、ソフトウェアSW1、SW2のアップデートは、無線通信に依らずに行われてもよい。すなわち、アップデート後のソフトウェアSW1、SW2は、警報器100に接続された物理的な回線を通じて供給されてもよく、USBメモリなどの記憶媒体を介して供給されてもよい。
【0047】
<ソフトウェアを格納する記憶領域の構成>
図2には、第2処理装置2aが有する記憶領域、例えば記憶手段2b(
図1参照)としてソフトウェアSW2を格納すべく備えられる、例えばEEPROMやフラッシュメモリなどのメモリの記憶領域4の構成及び記憶内容の一例が模式的に示されている。
図2の例において、A-0000番地からA-nnnn番地までのアドレスに、命令1~命令nで構成されるソフトウェアSW2が格納されている。一例として、ソフトウェアSW2のアップデートが行われる際には、アップデート後のソフトウェアSW2が含むべき一連の命令が、A-0000番地から順に、アップデート後のソフトウェアSW2のサイズに対応する任意の番地までの領域に上書きされる。
【0048】
図2の例の記憶領域4は、A-0001番地からA-FFFF番地までの第1記憶領域A1と共に、B-0000番地からB-FFFF番地までの第2記憶領域A2を有している。従って、ソフトウェアSW2のアップデートでは、アップデート後のソフトウェアSW2が含むべき一連の命令が、第1記憶領域A1に上書きされずに、第2記憶領域A2に格納されてもよい。このようにアップデート後のソフトウェアSW2が含むべき命令を格納することによって、第2処理装置2aをアップデート前のソフトウェアSW2に従って動作させながら、アップデート後のソフトウェアSW2を、記憶手段2bとして備えられるフラッシュメモリなどの記憶領域に書き込むことができる。そして、第2処理装置2aによって次に実行されるべき命令が格納されている記憶手段2bのアドレスを保存するプログラムカウンタが、第2記憶領域A2内の適切なアドレスに設定される。このようにして、短時間で、ソフトウェアSW2のアップデートを行えることがある。
【0049】
なお、第1処理装置1aにおいてソフトウェアSW1のアップデートが行われる場合も、ソフトウェアSW2について
図2で説明されたような方法で、警報器100の報知機能を維持しながら、アップデート後のソフトウェアSW1を記憶手段1b(
図1参照)内に格納し得ることがある。
【0050】
また、
図2の例のような記憶領域4内の特定の記憶領域へのアップデート後のソフトウェアSW2の書き込みや、アップデート後のソフトウェアSW2への切り替えは、一例において、第2処理装置2aのハードウェアを管理するオペレーティングシステム(OS)によって制御される。その場合、ソフトウェアSW2は、このOS上で動作するアプリケーションプログラムであってもよい。そして、アップデート前のソフトウェアSW2の実行中に、アップデート後のソフトウェアSWが記憶領域4内の空き領域に書き込まれ、ソフトウェアSW2が実行されていない間に、アップデート後のソフトウェアSW2に切り替えられてもよい。第1処理装置1aのソフトウェアSW1についても、同様にOSの制御の下でアップデートが行われてもよい。
【0051】
<アップデートの処理フロー>
図3を参照して、本実施形態の警報器における通信部に関するソフトウェアのアップデート(第1アップデート)に関する処理が説明される。
図3には、一例として、
図1の警報器100における、ソフトウェアSW2のアップデートを含む動作を示すフローチャートが示されている。なお、
図3の例は、通信部20において前述した「定期通信」が行われる例である。
図3を主に参照する以下の説明では、相反する説明がない限り、「ソフトウェア」は、通信部20が従う制御プログラムを含む「ソフトウェアSW2」を意味し、「アップデート」は、通信部20に関するアップデートある「第1アップデート」を意味する。
【0052】
図3のステップS1において周囲環境の監視が開始されると、計時手段2c(
図1参照)を構成するカウンタなどがリセットされ(ステップS2)、時間のカウントが開始される。そして、監視動作と並行して、アップデートの要求の有無がモニタされ、アップデートの要求がなく(ステップS3で“N”)、異常の発生もなければ(ステップS4で“N”)、計時手段2cのカウント値に基づいて直前の定期通信から所定の時間が経過したかどうかが判断される(ステップS21)。ステップS21において所定の時間が経過していない場合は(ステップS21で“N”)、計時手段2cの時間がカウントアップされ(ステップS22)、ステップS3に戻って周囲環境の監視及びアップデート要求の有無のモニタが継続される。ステップS21において所定の時間が経過している場合は(ステップS21で“Y”)、定期通信として警報器100の状態が外部機器E(
図1参照)に送信される(ステップS23)。その後、計時手段2cのカウント値がリセットされ(ステップS24)、ステップS3に戻って周囲環境の監視などが継続される。
【0053】
一方、アップデートが要求及び実行されていない状況での周囲環境の監視中に異常の発生が検知されると(ステップS4で“Y”)、異常の種類や程度に応じて制御部10によって選択された所定の態様(第1態様)で警報が発せられる(ステップS5)。加えて、警報が発せられていることが通信部20によって外部機器Eに通知される(ステップS6)。
【0054】
ステップS5で発せられる警報の態様である第1態様は、報知部13(
図1参照)がLEDなどの発光素子を含んでいる場合、所定の第1輝度及び第1色度の光を連続的に発することや、そのような所定の輝度及び色度の光を断続的に発する(すなわち点滅させる)ことであり得る。また、報知部13がスピーカーやブザーなどの鳴動素子を含んでいる場合、所定の第1音量で所定の第1音調の音が発せられてもよい。報知部13が発する音は例えばビープ音であってもよく、人工的に作られた音声であってもよい。例えば、ステップS5において第1態様で発せられる音声は、「ガス漏れ(又は火事)です。外部の○〇に通知しています」などのメッセージであり得る。このように、制御部10は、周囲環境の異常の検知時にメッセージを発するように構成されていてもよい。メッセージの発話によって、より明確且つ具体的にユーザーなどに異常状態の発生を報せることや、異常状態への対処方法を教授することが可能なことがある。
【0055】
警報の発報及び外部機器への通知後、ユーザーによって警報の停止操作が行われず、しかも異常状態が解消されない(ステップS7で“N”)間、警報の発報が継続される(ループL1)。そして、警報の停止操作が行われるか、異常状態が解消すると(ステップS7で“Y”)、警報が停止される(ステップS8)。ステップS8において、警報の停止が通信部20によって外部機器Eに通知されてもよい。警報の停止後、ステップS21で所定時間の経過の有無が判断され、前述したステップS21以降の処理が実行される。
【0056】
本実施形態の警報器100では、
図3の例のステップS7のように、周囲環境の異常の検知に応じて発せられた警報が、警報器100の外部からの停止操作によって停止可能であってもよい。偶発的且つ瞬間的な環境の変動による拙速な警報や誤報などの場合に、速やかに警報器100の周囲を平穏な平常時の状態に落ち着かせることができる。
【0057】
発報中の警報を停止させ得る停止操作は、例えば、被操作部5(
図1参照)への直接的な手動操作であってもよく、警報器100の近傍又は遠方からの警報停止を指示する信号の送信であってもよい。警報停止を指示する信号は、例えば、外部機器Eへのユーザーの操作に基づいて外部機器Eから警報器100に送られてもよい。警報停止のための被操作部5への手動操作は、被操作部5が前述したように各種のスイッチである場合、所定の第1時間以上の時間、又は、所定の第1時間以上、所定の第2時間(>第1時間)以下の時間だけ、被操作部5を継続的に操作することであってもよい。
【0058】
一方、ステップS3でソフトウェアのアップデートが要求されていると(ステップS3で“Y”)、
図3の例では、アップデートの開始が外部機器Eに通知され(ステップS11)、アップデートが開始される(ステップS12)。すなわち、制御部10は、第1アップデートの開始時に、外部機器Eへの警報の発報の通知を行わないモードに移ることを、通信部20を介して外部機器Eに報せるように構成されている。従って、遠方のユーザーなどに、警報が発せられても通知されない状況にいることを了知させることができる。なお、ソフトウェアのアップデートの要求は、後述するように、警報器100のユーザーによる被操作部5に対する手動操作や、外部機器Eからのアップデートを指示する信号の送信によって行われ得る。
【0059】
アップデートの開始後、周囲環境の監視において異常が生じなければ(ステップS13で“N”)、アップデートが終了しない(ステップS17で“N”)間、ループL2でステップS13に戻って、周囲環境の監視とアップデートの実行が継続される。そして、アップデート中に異常が生じると(ステップS13で“Y”)、警報が発せられる(ステップS14)。しかし、アップデート非実行中の異常発生時にステップS6で行われるような外部機器Eへの通知は行われない。
【0060】
図3の例においてステップS14での警報は、アップデート非実行中であるステップS5での発報態様である前述した第1態様とは異なる第2態様で発せられる。アップデート非実行中の警報と異なる態様で警報を発することで、外部機器Eに警報の発報が通知されていないことを、警報器100の近傍のユーザーに了知させることができる。このように制御部10は、第1アップデートを実行している期間と実行していない期間との間で、周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されていてもよい。なお、警報器100は、第1アップデート中の警報発報中に被操作部5(
図1参照)に何らかの操作がされた場合に、第1アップデート実行中であることを音声又は光などで示すように構成されていてもよい。
【0061】
ステップS14において発する警報の態様である第2態様は、第1態様について前述した第1輝度と異なる第2輝度、及び/又は、前述した第1色度と異なる第2色度の光を連続的に発することや、そのような所定の輝度及び色度の光を点滅させることであり得る。例えば、第2輝度は第1輝度よりも高く、第2色度は第1色度よりも彩度に関して高くてもよい。第1態様において光が連続的に発せられる場合、第2態様において点滅する光が発せられてもよく、第1態様において点滅する光が発せられる場合は、第2態様において第1態様における点滅よりも短い周期で点滅する光が発せられてもよい。また、警報として音が発せられる場合は、例えば第2態様において、第1態様に関して前述した第1音量よりも大きな第2音量及び/又は前述した第1音調よりも可聴範囲の中心に近い音調の音が発せられてもよい。或いは、第2態様において第1態様よりも短い周期で断続的に音が発せられてもよい。
【0062】
上記とは逆に、第2態様において、第1態様よりも長い点滅周期で光が発せられてもよく、第2態様において第1態様よりも長い周期で断続的に音が発せられてもよい。消費電力低減の観点で好ましいことがある。このように、警報器100は、より消費電力の少ない態様である第2態様で、第1アップデート中の警報の発報を行ってもよい。
【0063】
さらに、第2態様の警報としてメッセージが発せられる場合は、第1態様で発せられるメッセージと異なるメッセージが発せられてもよい。例えば、ステップS14において第2態様で発せられるメッセージは、「ガス漏れ(又は火事)です。外部の○〇には通知されていないのでご注意ください」などであり得る。このように、制御部10は、第1アップデートを実行している期間と実行していない期間との間で、メッセージを発する態様を異ならせるように構成されていてもよい。警報器100の近傍のユーザーなどに、外部に警報の発報が知らされていないことを、より明確に伝えることができる。
【0064】
警報の発報後、ユーザーによって警報の停止操作が行われるか、異常状態が解消すると(ステップS15で“Y”)、警報が停止される(ステップS16)。しかし、アップデートが終了しない(ステップS17で“N”)間は、ループL2でステップS13に戻って、周囲環境の監視とアップデートの実行が継続される。
【0065】
アップデート実行中のステップS15で制御部10に警報の停止操作として受け容れられる操作は、アップデートの非実行中であるステップS7で警報の停止操作として受け容れられる操作と異なっていてもよい。アップデートの実行中の警報の停止に必要な操作をアップデートの非実行中に許容される操作と異ならせることで、外部に警報発報が通知されていないことを、警報器100の近傍のユーザーに了知させることができる。以下の説明において、アップデート実行中のステップS15で警報の停止操作として受け容れられる操作は、
図3のステップS15に記載の通り「特定停止操作」とも称される。
【0066】
例えば、特定停止操作は、被操作部5(
図1参照)への直接的な手動操作だけに限定され、すなわち、ネットワークNや通信事業者の基地局B(後に参照する
図4参照)を介して外部機器Eから送られる警報停止を指示する信号は無効にされてもよい。こうすることで、警報の停止を、警報器100の周囲の状況を把握し得る警報器100の近傍のユーザーなどに限定することができる。また、警報の発報が通知されていない遠方のユーザーの誤操作などによる不適切な警報の停止を回避することができる。
【0067】
特定停止操作は、アップデート非実行中に警報停止操作として許容される被操作部5への操作時間よりも長時間にわたる被操作部5への操作や、限られた時間中の複数回の操作であってもよい。また、警報器100は、複数の被操作部5を備えていてもよく、その場合、特定停止操作は、複数の被操作部5に対する同時操作であってもよい。
【0068】
このように本実施形態の警報器100において制御部10は、第1アップデートを実行している期間と実行していない期間との間で、警報の停止操作による警報停止の容易性を異ならせるように構成されていてもよい。一例として、第1アップデートの実行中は、第1アップデートを実行していないときよりも、警報停止の難易度が高められてもよい。或いは、アップデートの実行中に発せられる警報は、警報器100への電力供給の停止を除いて停止不可であってもよい。そうすることで、警報器100の近傍のユーザーに、警報の発報が外部に通知されていないことをより強く印象付け得ることがある。なお、このように警報器100への電力供給の停止を除いて警報の停止が不可な場合、警報時に発せられるメッセージが、警報の停止が不可であることを伝えるメッセージに変更されてもよい。
【0069】
ステップS16での警報の停止後に、又はアップデート実行中に異常が生じないまま(ステップS13で“N”)、アップデートが終了した場合(ステップS17で“Y”)、
図3の例では、外部機器Eへの通知が行われる(ステップS18)。ステップS18での外部機器への通知では、アップデート実行中に警報の発報が無かった場合には、例えばアップデートの終了だけが通知される。
【0070】
一方、アップデート実行中に警報の発報があった場合(ステップS16からステップS17に至った場合)には、アップデート終了後のステップS18において、アップデートの終了の通知と共に、又はアップデートの終了の通知の代わりに、アップデート中に警報の発報があったことが外部機器Eに通知されてもよい。
【0071】
このように本実施形態の警報器において制御部10は、第1アップデートの実行中に発した警報が第1アップデートの終了前に停止されたときは、第1アップデートの終了後に、第1アップデートの実行中に警報を発したことを外部機器Eに報せるように構成されていてもよい。外部機器E側のユーザーや管理者に、警報器100の周囲の現況を確認するよう促し得ることがある。ステップS18での外部機器Eへの通知後、ステップS21で所定時間の経過の有無が判断され、前述したステップS21以降の処理が実行される。
【0072】
ステップS14での警報の停止後、特定停止操作が行われず、しかも異常が解消しない場合は(ステップS15で“N”)、アップデートが終了しない限り(ステップS19で“N”)、ループL3でステップS15に戻って、警報の発報とアップデートの実行とが継続される。一方、アップデートが終了すると(ステップS19で“Y”)、処理がステップS6に移って、警報の発報中であることが外部機器Eに通知され、その後、前述したようにステップS7以降の処理が実行される。
【0073】
このように、本実施形態の警報器100において制御部10は、周囲環境の異常の検知前に開始された第1アップデートが警報発報中に終了すると、警報発報中であることを外部機器Eに報せる通知を行うように構成されていてもよい。外部機器Eとの交信が可能になり次第、速やかに、警報器100の周囲環境が異常な状態にあることを外部機器Eに報せることができる。
【0074】
<アップデートの要求態様>
本実施形態の警報器100において、ソフトウェアSW1、SW2(
図1参照)のような各ソフトウェアのアップデートの要求には、任意の方法が適用される。
図4には、アップデートの要求の幾つかの例として、家屋の室内に設置された警報器100へのアップデートの要求方法が模式的に示されている。アップデートの要求は、例えば、前述したように被操作部5に触れるような直接的な所定の操作M1によって行われる。また、警報器100の付属リモコンのような専用端末や、アプリケーションプログラムによって専用端末化されたスマートフォンなどの各種の汎用携帯端末から近距離通信によってアップデートが要求されてもよい(以下では、専用端末と専用端末化された汎用携帯端末は「専用端末類」と総称され、
図4には符号「Pn」を添えて示されている)。また、外部機器Eや、遠方のスマートフォンなどの端末Prから、ネットワークNや通信事業者の基地局Bを介して送られる信号によってアップデートが要求されてもよい。その場合、外部機器Eからのアップデート用の更新データの送信そのものでアップデートが要求されてもよい。
【0075】
しかし、警報器100に用意されたアップデートの要求方法の全てが有効であることが、必ずしも好ましくない場合もある。例えば、アップデートの要求者が警報器100の周囲環境を把握可能な状況にいると考えられる要求方法による要求は受け付けられるが、それ以外の要求方法による要求は受け付けられない方が好ましいこともある。例えば、警報が発報されるほどの状況ではないが、その状況に近付いている状況にあるにも拘わらず、その状況を認識し得ない要求者からの例えばソフトウェアSW1のアップデートの要求を受け入れるのは、適正な警報発報の妨げになる場合もあるからである。
【0076】
そのため、本実施形態では、アップデートの要求方法が、要求されるアップデートの種類ごとに、予め特定の方法に決められていてもよい。例えば、アップデートの「種類」のうち「第1種」のアップデートの要求は多くの方法(例えば用意された要求方法の全て)で可能である一方、「第1種」以外の「第2種」のアップデートは、警報器100に実際に受け付けられる要求方法が制限されてもよい。例えば、第2種のアップデートの要求は、
図4に示される被操作部5に触れるような直接的な所定の操作M1や、警報器100の近傍の専用端末類Pnからの近距離通信による要求などに制限されてもよい。すなわちその場合には、外部機器Eや遠方の端末Prからの、ネットワークNや基地局Bなどを経由した信号によるアップデートの要求は受け付けられない。一方、第1種のアップデートについては、第2種のアップデートの要求が受け付けられる方法に加えて、外部機器Eや遠方の端末Prからの、ネットワークNや基地局Bなどを経由した信号によるものでも受け付けられてもよい。或いは、第1種のアップデートは、外部機器Eや遠方の端末Prからの信号による要求に限定され、被操作部5に触れるような直接的な所定の操作M1や、警報器100の近傍の専用端末類Pnからの近距離通信による要求が受け付けられなくてもよい。
【0077】
このように本実施形態の警報器は、要求されるアップデートの種類に応じて、警報器に対して行われる所定の指示操作に基づいてアップデートを実行するか、外部機器からの信号の受信に基づいてアップデートを実行するように構成されていてもよい。そのようにアップデートの種類に応じて、警報器100が受け付ける要求方法を区別することによって、例えば、必要性の高いアップデートの適宜の実行を担保しつつ、アップデートによる警報器100の警報発報機能の低下リスクを軽減し得ることがある。また、アップデートの要求元として適した要求元からのアップデートの要求に絞って、要求されたアップデートを実行することができる。
【0078】
上記の「警報器に対して行われる所定の指示操作」は、前述した被操作部5に触れるような直接的な所定の操作M1や、警報器100の近傍の専用端末類Pnへのアップデートを指示する操作であり得る。
【0079】
専用端末類Pnへの操作による指示は、前述したように、例えば近距離通信によって警報器100に伝えられる。この近距離通信としては、Bluetooth(登録商標)やWi-Fi(登録商標)、又はZigBee(登録商標)などの近距離無線通信、及び、IrDAなどの光無線通信、さらに、LoRaWAN(登録商標)などのネットワークプロトコルを用いる通信が例示されるが、専用端末類Pnが用いる近距離通信はこれらに限定されない。しかし、「警報器に対して行われる所定の指示操作」に基づくアップデートの要求信号は、アップデートの要求者に直接手動操作される専用端末類Pnのような被操作主体から警報器100に直接伝わる信号に限られる。すなわち、「所定の指示操作」には、警報器100に直接伝わらないアップデートの要求信号の送信を被操作主体に指示する操作は含まれない。従って、ネットワークN及び/又は基地局Bを介して警報器100に伝わるようなアップデートの要求信号の送信を端末Prや外部機器Eに指示する操作も「所定の指示操作」に含まれない。
【0080】
なお、警報器100の「近傍」は、警報器100から数m以内の範囲、及び/又は、警報器100が視認可能な範囲内であり得る。このような範囲内にいるアップデートの要求者は、警報器100の周囲の状況の認識が可能と考えられるからである。近距離通信が警報器100と専用端末類Pnとの通信に用いられる場合は、警報器100の「近傍」は、さらに、上記の例のような各種の近距離無線通信や光無線通信における警報器100からの通信圏内である。
【0081】
ここで上記のアップデートの「種類」は、一例として、アップデートの重要性や緊急性の程度を意味し得る。例えば、重要性や緊急性の高いアップデートが第1種のアップデートに含まれ、「第1種」以外のアップデートが第2種のアップデートに含まれてもよい。
【0082】
また、アップデートの「種類」は、アップデートの対象となる警報器100の機能によって区分されてもよい。例えば、警報器100の報知機能に関するアップデート(又は制御部10に関するアップデート)が第1種のアップデート及び第2種のアップデートの一方に含まれ、通信部20に関するアップデート(第1アップデート)が、その他方に含まれてもよい。一例として、制御部10に関するアップデートの要求は「警報器に対して行われる所定の指示操作」に基づいて実行されてもよい。報知機能を制御する制御部10に関するアップデートの実行を、警報器100の周囲環境を把握し得る警報器100の近傍のユーザーによる要求に基づいて実行することができる。また、通信部20に関するアップデート(第1アップデート)は「外部機器からの信号の受信」に基づいて実行されてもよい。外部機器Eにおいて、通信制御方式の変更があった場合において、その外部機器Eからの要求に基づいて、通信に関するアップデートを実行することができる。
【0083】
一例として「報知機能に関するアップデート」は、検知部12(
図1参照)による周囲環境の監視動作、特定の状態にあることを報知すべきか否かの判断、如何なる態様で報知を行うかの判断、及び、報知部13(
図1参照)による音や光などによる報知動作、などの制御に関するアップデートであり得る。より具体的には、幾つかの例として、検知部12の動作時期や感度の変更、特定の状態と判断する閾値(警報発報基準)の変更、特定の状態と判断される監視結果と報知態様との対応付けの変更、報知機能に関するプログラムのバグの修正、消費電力を低減する新たな制御手順への変更、及び、報知手段である光の強度や音声の音量若しくは発話内容の変更、などが含まれる。さらに、制御部10による検知部12及び報知部13の自主点検項目、及び/又は、検知部12を構成する各センサについて適宜行われる補正のアルゴリズムの変更なども「報知機能に関するアップデート」に含まれる。
【0084】
「通信部20に関するアップデート」は、通信部20によって制御される通信に関わるアップデートである。より具体的には、幾つかの例として、外部機器Eとの通信に適用する通信規格の改定に伴う、セキュリティ確保に関する仕様の変更や、通信リンクの設定及び開放の手順の変更、変調方式の変更、誤り検出時の再送回数の変更、通信部20において構築されたセキュリティスタックのバージョンアップや、定期通信の頻度の変更、通信に関するプログラムのバグの修正、などが含まれ得る。
【0085】
<アップデートの制限>
本実施形態の警報器100は、前述した要求方法自体が受け容れ可能な要求方法であっても、要求されるアップデートを現に実行するか否かを、上記に例示されるようなアップデートの内容に基づいて判断するように構成されていてもよい。例えば、周囲環境が警報を発する状況に近付いている場合には、警報発報に至っても外部機器Eに通知されない状態となるアップデートを開始しないことが好ましいことがある。従って、例えば警報器100が警報を発報すべき状態よりも異常度が低い状態に対応する閾値(予備閾値)をさらに有していてもよい。加えて、アップデートの具体的な内容ごとにアップデート実行の優先度が設定されてよい。そして、検知対象であるガスの濃度や温度などの検出値が予備閾値を超えると、例えば通信セキュリティの確保に関する仕様の変更や致命的なバグの修正といった優先度の高い内容のアップデートだけが実行されてもよい。その他のアップデートは、検知対象の検出値が予備閾値以下の場合に実行されてもよい。
【0086】
前述したように警報器100は、電池の電力で稼働する電池式の警報器であってもよい。アップデートの実行中は、アップデートが実行されていない時より多くの電力が消費されることがある。そのため、本実施形態の警報器が電池式の警報器である場合、要求されるソフトウェアのアップデートを実行するか否かを、電池の残量に基づいて判断するように構成されていてもよい。例えば電池の残量が所定の閾値以下であると、警報器100のユーザーや外部機器Eなどからアップデートの要求があってもアップデートは実行されない。そうすることで、アップデートによる電池残量のさらなる低下を防いで、警報器100が電池の残量不足によって機能不全に陥ることを防ぐことができる。すなわち、周囲環境の監視から監視結果に基づく報知までの警報器100の本質的機能が発揮される状態を、より長く維持させることができる。
【0087】
特に警報器には、前述したように検知部12(
図1参照)を構成する各種のセンサが備えられ、各種センサには固有の寿命を有するものが存在する。そのため、電池式の警報器は、センサの寿命が尽きるまでの間電池残量が維持されるように電気的に設計され、構造面や仕様面では電池の交換や再充電ができないように設計されることがある。従って、設計思想通りにセンサの寿命まで電池残量が維持されるように、ある程度電池残量が低下してからは、より多くの電力を警報器100に消費させるアップデートの実行を控えることが好ましいことがある。
【0088】
なお、このように電池残量によってアップデートの実行が判断される場合、警報器100には、好ましくは、電池残量計ICなどと称される電子部品のような電池残量計測手段(図示せず)が備えられる。
【0089】
電池の残量に基づいてアップデートの実行を判断するように構成される場合、本実施形態の警報器100は、さらに、前述したようなアップデートの内容にも応じて、要求されるアップデートを実行するか否かを判断するように構成されてもよい。この場合も、アップデートの具体的な内容ごとにアップデート実行の優先度が設定され得る。例えば、所定の閾値を超える電池残量が保持されている場合に、要求されるアップデートが、その内容の如何を問わず実行されるのではなく、例えば、通信セキュリティの確保に関する仕様の変更や致命的なバグの修正といった優先度の高い内容のアップデートだけが実行されてもよい。そして、その他のアップデートは、さらに多くの電池残量が保持されている場合に実行されてもよい。
【0090】
従って、実施形態の警報器100は、アップデートを実行するか否かの判断基準となる複数の電池残量の閾値を有していてもよい。そして、アップデート要求時の電池残量と各閾値との大小関係及び現に要求されるアップデートの優先度に応じて、要求されるアップデートを実行するか否かが判断されてもよい。例えば、アップデート要求時の電池残量が特定の閾値の範囲内にある場合、一定以上の優先度を有するアップデートが実行され、優先度の低いアップデートが保留又は却下されてもよい。
【0091】
図5には、アップデートの優先度及び電池残量に応じたアップデートの実行の判断の一例が示されている。
図5に示される表の各列(縦方向)には、電池残量eと三つの閾値T1~T3(T1<T2<T3)との大小関係が示されている。そして各行には、第1優先から第3優先(優先度高:第1優先>第2優先>第3優先:優先度低)それぞれを有するアップデートが実行されるか否かが「Y」(実行)又は「N」(非実行)で示されている。例えば、電池残量eが、最も小さい閾値T1以下である場合は、電池の延命が優先されていずれのアップデートも実行されない。しかし、電池残量eが閾値T1よりも大きく閾値T2以下であれば第1優先アップデートが実行され、電池残量eが閾値T2よりも大きく閾値T3以下であると、さらに第2優先アップデートも実行される。そして、電池残量eが閾値T3よりも大きければ、全てのアップデートが実行される。なお、警報器100は、特定の優先度のアップデートが実行されない場合、その特定の優先度より低い優先度のアップデート要求を受け付けないように構成されていてもよい。
【0092】
優先度の高いアップデートは、例えば、前述した、通信セキュリティの確保に関する仕様の変更や、報知機能や通信を高度に損なわせる致命的なバグの修正の他、警報発報基準の変更、セキュリティスタックのバージョンアップなどであり得る。電池寿命を延ばして、警報器100をセンサの保証期間満了まで稼働させるという観点では、消費電力低減のためのアップデートも高い優先度を有し得る。一方、優先度の低いアップデートとしては、報知態様の変更、自主点検項目の変更や定期通信の頻度の変更などが例示される。しかし、如何なるアップデートが高い又は低い優先度を有するかは、警報器100の設置環境や警報器100の仕様などに応じて任意に決定され得る。
【0093】
なお、アップデートの内容や種類は、例えば、アップデートの為に外部機器E(
図1参照)などから供給される更新データに付加される識別符号を認識することによって、第1処理装置1a又は第2処理装置2a(
図1参照)などで把握され得る。すなわち、外部機器Eなどの更新データの供給元にて、アップデートの種類や内容が符号化されて識別符号として更新データと共に警報器に送られる。この識別符号をデコードすることによって、各処理装置においてアップデートの内容や種類が把握される。或いは、警報器100に供給されたアップデート後のソフトウェアが、先に
図2を参照して説明されたように、アップデート前のソフトウェアの記憶領域と異なる記憶領域に保管されてもよい。そして、アップデート前後のソフトウェアを各処理装置の比較機能で比較することによって、アップデートの種類や内容が把握されてもよい。
【0094】
また、要求されるアップデートの種類や内容は、アップデートのための更新データの送信に先立って、外部機器Eなどの更新データの供給元から警報器100に送られてもよい。そして、警報器100において、送られてきたアップデートの種類や内容に基づいて、アップデートを実行するか否かが判断される。警報器100においてアップデートを実行しないと判断された場合は、例えば所定の待機時間を経て供給元から送られる更新データを警報器100が受け取らないように構成されていてもよい。或いは、警報器100での判断結果に応じて、警報器100から更新データの供給元に、更新データの送信要求又は受領拒否通知が送られ、更新データの供給元は、送信要求を受領した場合だけ、更新データを送るように構成されていてもよい。このように更新データそのものの受信の前にアップデートの可否を判断することによって、実行できないアップデートのための通信による電力の浪費を回避し得ることがある。
【0095】
<更新データの供給態様>
図1に例示の警報器100のような本実施形態の警報器は、前述したように、定期的に警報器100の状態を外部機器Eに送信する定期通信を行うように構成されていてもよい。ここで、幾つかの通信規格では、送信側から送られる、通信パケットのようなデータの伝送単位ごとに、受信側から応答信号を返信するように規定されている。従って、アップデート後のソフトウェアが外部機器Eから供給される場合、そのアップデート用の更新データが、定期通信における外部機器Eからの応答信号に含めて送られてもよい。その場合、1度のアップデートに必要な更新データが複数の定期通信に渡って分割して送られてもよい。そして、ソフトウェアのアップデートが、そのように1回、又は複数回の定期通信を通じて送られる更新データを用いて実行されてもよい。そうすることで、アップデート用のデータを効率良く送受し得ることがある。
【0096】
例えば、
図6に示されるように、警報器100から外部機器Eに警報器100の状態などを送る際に準拠する通信規格では、通信パケットなどの伝送単位のデータ長が固定長として定められていることがある。そのような通信規格の下で警報器100の状態が外部機器Eに送信される場合、例えば外部機器Eを示す宛先などの制御情報を含むヘッダH1と、ペイロードP1とで構成される固定長のパケットPsが送信される。ペイロードP1に実際の送信対象のデータである警報器100の状態を示すデータが格納される。
【0097】
パケットPsを受け取った外部機器Eは、特に警報器100に送るデータが無くても、準拠する通信規格の規定に従って固定長のパケットPa(応答パケット)を警報器100に送信する。単なる応答用のパケットPaは、準拠する通信規格に従って、警報器100を示す宛先を含むヘッダH2と、パケットPaの固定長を満たすペイロードP2とで構成される。単なる応答用のパケットPaの場合、ペイロードP2には、例えば“0”のみ又は“1”のみのヌル(無効)データが格納される。そこで、本実施形態の警報器100においてソフトウェアのアップデートが予定されている場合には、このペイロードP2に更新データが格納されて警報器100に送信される。このように通常の応答パケットでは有効活用されていないデータ格納領域を利用することで、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器100に供給することができる。警報器100は、複数の応答パケットに分割して送られる更新データの全てを受け取ると、自律的にソフトウェアのアップデートを開始してもよい。
【0098】
なお、警報器100では、前述したようにアップデート非実行中は、警報の発報が外部機器Eに通知される。従って、その通知に対する応答信号にアップデート用の更新データが含められてもよい。この場合も、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器100に供給することができる。
【0099】
また、警報器100は、分割して受け取る更新データを、アップデートの実行まで、警報器100内の記憶手段2b(
図1参照)などの記憶領域に保管してもよい。その場合、
図2に示されるように、アップデート前のソフトウェアSW2が格納されている領域(例えば第1記憶領域A1)と異なる領域(例えば第2記憶領域A2)に、順次受け取る更新データが格納されてもよい。そうすることで、警報器100は、アップデート前のソフトウェアSW2に従って動作しながら、随時送られてくる更新データを受け取ることができる。
【0100】
<一実施形態の警報器の変形例>
図7には、一実施形態の警報器の変形例である警報器101の主要な構成要素がブロック図で示されている。
図7において、
図1の例の警報器100の構成要素と同様の構成要素については、
図1に付された符号と同じ符号が付されるか省略され、その構成要素に関する繰り返しとなる説明は省略される。警報器101は、
図1の警報器100の第1処理装置1aの機能と第2処理装置2aの機能とを併せ持つ単一の処理装置1を備えている点で、
図1に示される警報器100と異なっている。すなわち、警報器101は、報知機能の制御及び通信の制御の両方を担う処理装置1を備えている。しかし、処理装置1の内部が、制御部10を担う部分(第1処理部1α)と通信部20を担う部分(第2処理部1β)とに区分されている。
【0101】
警報器101の処理装置1では、
図7に示される記憶手段1b、記憶手段2b、及び計時手段2cのように処理装置1を構成するCPUやメモリなどの各ハードウェア資源が、報知機能を担う第1処理部1α及び通信機能を担う第2処理部1βのいずれかに割り当てられている。
図7に示される記憶手段1b、記憶手段2b、及び計時手段2cは、それぞれ、
図1の例の記憶手段1b、記憶手段2b、及び計時手段2cと同様の機能を有している。そして、
図7の例において、記憶手段1bは第1処理部1αに属し、記憶手段2b及び計時手段2cは、第2処理部1βに属している。
図1の警報器100と同様に、記憶手段1bには、報知機能に関する命令を含むソフトウェアSW1が内蔵されており、記憶手段2bには、通信機能に関する命令を含むソフトウェアSW2が内蔵されている。
【0102】
警報器101の処理装置1では、メモリなどの各ハードウェア資源単位で、第1処理部1α又は第2処理部1βに割り当てられるのではなく、ハードウェア資源それぞれの内部が、報知機能を担う部分と通信機能を担う部分とに仕切られていてもよい。例えば、各記憶手段の記憶領域が、ソフトウェアSW1のような報知機能に関する情報を記憶する領域と、ソフトウェアSW2のような通信機能に関する情報を記憶する領域とに仕切られていてもよい。また、各記憶手段内の各種のレジスタ領域が、報知機能に関わる情報の記憶領域と通信機能に関わる情報の記憶領域とに分けられていてもよい。また、処理装置1を構成する複数の入出力ポートが、報知機能を担うポートと通信機能を担うポートとに分けられていてもよい。
【0103】
なお、
図7の例において処理装置1は、さらに報知機能及び通信機能以外の機能を担っていてもよく、また、報知機能及び通信機能それぞれの機能がさらに細分化されていてもよい。すなわち処理装置1は、3つ以上の機能を有していてもよく、それぞれに割り当てられた機能を担う三つ以上の部分に区分されていてもよい。そして処理装置1内のメモリなどの各ハードウェア資源が、3つ以上の部分のいずれか1以上に割り当てられてもよく、各資源の内部が、3つ以上の機能のいずれか担う部分毎に仕切られていてもよい。
【0104】
さらに、警報器101において処理装置1は、CPUに複数のコアを有するマルチコアタイプのマイコンであってもよく、複数のコアの一つが報知機能に宛てがわれ、他の一つが通信機能に宛てがわれてもよい。そのようにして、処理装置1の内部が、制御部10を担う部分と通信部20を担う部分とに区分されていてもよい。
【0105】
図7の警報器101は、このように、
図1の警報器100と違って、報知機能及び通信機能の両方を制御する処理装置1を備えているが、その内部が制御部10を担う部分と通信部20を担う部分とに区分されている。そのため、警報器101においても、ソフトウェアSW1のアップデートは通信機能に影響し難く、ソフトウェアSW2のアップデートは報知機能に影響し難いと考えられる。例えば、前述したように、ソフトウェアSW1のアップデート時には、通信部20は通信などが可能な状態を維持することができる。また、ソフトウェアSW2のアップデート時には、制御部10は報知機能を維持することができる。そして、警報器101では、制御部10及び通信部20のいずれも処理装置1で主に構成されているので、制御部10と通信部20とを跨ぐような処理が高速に行われると考えられる。
【0106】
なお、今回開示された実施形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施形態の説明ではなく特許請求の範囲によって示され、さらに特許請求の範囲と均等の意味及び範囲内でのすべての変更(変形例)が含まれる。
【0107】
また、上記実施形態では、説明の便宜上、実施形態の警報器の処理動作を処理フローに沿って順番に処理を行うフロー駆動型のフローチャートを用いて説明したが、本発明はこれに限られない。本発明では、警報器の処理動作を、イベント単位で処理を実行するイベント駆動型(イベントドリブン型)の処理により行ってもよい。この場合、完全なイベント駆動型で行ってもよいし、イベント駆動及びフロー駆動を組み合わせて行ってもよい
【符号の説明】
【0108】
100、101 警報器
1 処理装置
1α 第1処理部
1β 第2処理部
1a 第1処理装置
1b 記憶手段
10 制御部
2a 第2処理装置
2b 記憶手段
20 通信部
5 被操作部
E 外部機器
SW1、SW2 ソフトウェア
【手続補正書】
【提出日】2023-08-17
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発する、警報器。
【請求項2】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されている、警報器。
【請求項3】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記制御部は、前記周囲環境の異常の検知時にメッセージを発するように構成されており、
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記メッセージを発する態様を異ならせるように構成されている、警報器。
【請求項4】
前記制御部は、前記第1アップデートの開始時に、前記通知を行わないモードに移ることを前記外部機器に報せるように構成されている、請求項1~3のいずれか1項に記載の警報器。
【請求項5】
前記周囲環境の異常の検知に応じて発せられた警報が、外部からの停止操作によって停止可能であり、
前記第1アップデートを実行している期間と実行していない期間との間で、前記停止操作として受け容れられる操作が異なっている、請求項1~3のいずれか1項に記載の警報器。
【請求項6】
前記警報器は、前記アップデートの種類に応じて、前記警報器に対して直接又は前記警報器の近傍で行われる手動による所定の指示操作に基づいて前記アップデートを実行するか、前記外部機器からの信号の受信に基づいて前記アップデートを実行するように構成されている、請求項1~3のいずれか1項に記載の警報器。
【請求項7】
前記制御部は、前記周囲環境の異常の検知前に開始された前記第1アップデートが警報発報中に終了すると、前記通知を行うように構成されている、請求項1~3のいずれか1項に記載の警報器。
【請求項8】
前記制御部は、前記第1アップデートの実行中に前記周囲環境の異常の検知によって発した警報が前記第1アップデートの終了前に停止されたときは、前記第1アップデートの終了後に、前記第1アップデートの実行中に警報を発したことを前記外部機器に報せるように構成されている、請求項1~3のいずれか1項に記載の警報器。
【手続補正書】
【提出日】2024-01-10
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記通信部によって無線で前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、無線による前記通知を行わずに警報を発する、警報器。
【請求項2】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記周囲環境の異常の検知時に発する警報の発報態様を異ならせるように構成されている、警報器。
【請求項3】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記制御部は、前記周囲環境の異常の検知時にメッセージを発するように構成されており、
前記制御部は、前記第1アップデートを実行している期間と実行していない期間との間で、前記メッセージを発する態様を異ならせるように構成されている、警報器。
【請求項4】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、
前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、且つ、
前記第1アップデートの開始時に、前記第1のアップデートを開始することを前記外部機器に知らせるように構成されている、警報器。
【請求項5】
内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の交信を制御する通信部と、を備え、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御部は、前記周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを前記外部機器に報せる通知を行うように構成されており、
前記制御部は、前記アップデートのうちの前記通信部に関する第1アップデートの実行中に前記周囲環境の異常を検知すると、前記通知を行わずに警報を発し、
前記周囲環境の異常の検知に応じて発せられた警報が、外部からの停止操作によって停止可能であり、
前記第1アップデートを実行している期間と実行していない期間との間で、前記停止操作として受け容れられる操作が異なっている、警報器。
【請求項6】
前記警報器は、前記アップデートの種類に応じて、前記警報器に対して直接又は前記警報器の近傍で行われる手動による所定の指示操作に基づいて前記アップデートを実行するか、前記外部機器からの信号の受信に基づいて前記アップデートを実行するように構成されている、請求項1~5のいずれか1項に記載の警報器。
【請求項7】
前記制御部は、前記周囲環境の異常の検知前に開始された前記第1アップデートが警報発報中に終了すると、前記通知を行うように構成されている、請求項1~5のいずれか1項に記載の警報器。
【請求項8】
前記制御部は、前記第1アップデートの実行中に前記周囲環境の異常の検知によって発した警報が前記第1アップデートの終了前に停止されたときは、前記第1アップデートの終了後に、前記第1アップデートの実行中に警報を発したことを前記外部機器に報せるように構成されている、請求項1~5のいずれか1項に記載の警報器。