特許 7506213 警報器及び警報システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-06-17

(45)【発行日】2024-06-25

(54)【発明の名称】警報器及び警報システム

(51)【国際特許分類】

   G08B 23/00 20060101AFI20240618BHJP

   G08B 17/00 20060101ALI20240618BHJP

   G08B 21/16 20060101ALI20240618BHJP

   G08B 29/18 20060101ALI20240618BHJP

【ＦＩ】

G08B23/00 530B

G08B17/00 C

G08B21/16

G08B29/18 Z

【請求項の数】 7

(21)【出願番号】P 2023042229

(22)【出願日】2023-03-16

【審査請求日】2023-03-17

【早期審査対象出願】

(73)【特許権者】

【識別番号】000190301

【氏名又は名称】新コスモス電機株式会社

(74)【代理人】

【識別番号】110001896

【氏名又は名称】弁理士法人朝日奈特許事務所

(72)【発明者】

【氏名】齋藤 和也

【審査官】瀬戸 康平

(56)【参考文献】

【文献】特開２０２２－１８６８０６（ＪＰ，Ａ）

【文献】特開２０１９－１７４８６９（ＪＰ，Ａ）

【文献】特開２０１３－１１４４９９（ＪＰ，Ａ）

【文献】特開２０２１－１３２３０３（ＪＰ，Ａ）

【文献】特開２０２０－０３５１７５（ＪＰ，Ａ）

【文献】特開２０１５－０７９４６８（ＪＰ，Ａ）

【文献】欧州特許出願公開第０２９３７８４３（ＥＰ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／６５

Ｇ０８Ｂ １７／００－３１／００

(57)【特許請求の範囲】

【請求項1】

電池の電力で稼働して、周囲環境の監視結果に基づく報知、及び外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って行う電池式の警報器であって、
前記ソフトウェアは、前記警報器の使用開始後に要求に応じたアップデートが可能なように内蔵されており、
前記警報器は、ユーザーによる操作が可能なように設けられていて所定の動作の実行を指示する操作を受ける被操作部を備え、
要求される前記アップデートの実行を、前記電池の残量に基づいて行うように構成されており、
要求されるアップデートの種類に応じて、前記警報器に対して直接又は前記警報器の近傍で行われる所定の手動操作でのみ前記アップデートの要求が可能であるか、前記警報器に対して直接又は前記警報器の近傍で行われる所定の手動操作及び前記所定の手動操作以外に前記警報器の外部の機器から送られる信号のいずれでも前記アップデートの要求が可能であり、
前記所定の手動操作は、前記被操作部に対する直接的な手動操作、又は前記警報器の近傍からの近距離無線通信を介した操作である警報器。

【請求項2】

前記被操作部は、前記アップデート以外の所定の動作の実行を指示する第１操作を受け付け、
前記所定の手動操作は、前記被操作部に対して行われる、前記第１操作以外の操作である、請求項１記載の警報器。

【請求項3】

前記アップデートには、前記アップデートの内容に応じて優先度が付されており、
要求される前記アップデートの実行を、前記電池の残量及び前記優先度に基づいて行うように構成されていて、前記電池の残量の多少に応じて、特定の優先度以上の優先度を有するアップデートだけが実行される、請求項１記載の警報器。

【請求項4】

前記電池の残量について複数の閾値を有していて、前記電池の残量が第１の閾値以下であると全てのアップデートが実行されず、前記電池の残量が前記第１の閾値よりも大きい第２の閾値より大きいと全てのアップデートが実行される、請求項１記載の警報器。

【請求項5】

前記警報器は、前記監視結果に基づく警報の発報中には前記アップデートを実行しないように構成されている、請求項１記載の警報器。

【請求項6】

請求項１～５のいずれか１項に記載の警報器と、
前記警報器との間で通信による情報交換を行う制御装置と、を備え、
前記警報器は前記電池の残量に関する情報を前記制御装置に送信し、
前記制御装置が、前記警報器から送られる前記情報に基づいて、要求される前記アップデートの実行を判断する、警報システム。

【請求項7】

前記警報器は、前記制御装置から送られる更新データを用いて前記アップデートを実行するように構成されており、
前記制御装置は、前記電池の残量が所定の閾値以下のときには、前記更新データを前記警報器に送らないように構成されている、請求項６記載の警報システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、周囲環境を監視する警報器及び警報システムに関する。

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１９－１７９３２９号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

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

【0006】

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

【0007】

一方、ソフトウェアのアップデートは、警報器に、通常の監視状態で消費する電力以上の電力を消費させることがある。そのため、電池の電力で稼働する電池式の警報器では、ソフトウェアのアップデートが電池残量の低下を促進させることがある。そして、電池残量が一定程度を超えて低下すると、周囲環境の監視やその監視結果による警報の発報などの警報器の本質的機能が果たされなくなる。そのような状態に至ることは、周囲環境が異常な状態にあることをユーザーに報せるという警報器の特性上、至って好ましくない。特に電池交換を想定されていない電池交換不能な警報器では、警報器本体の交換が必要となるため、ユーザーを長期に渡って監視されていない環境下に置くことにもなるため極めて好ましくない。しかし、電池切れを防ぐために単に電池の容量を増やしたのでは、警報器のサイズやコストを増大させることになり得る。

【0008】

本発明は、上記問題に鑑みてなされたもので、電池式の警報器に新たな制御方式を適宜取り入れることができ、しかも、電池の残量低下による警報器の機能の停止を抑制することができる警報器及び警報システムを提供することを目的とする。

【課題を解決するための手段】

【0009】

本発明の警報器は、電池の電力で稼働して、周囲環境の監視結果に基づく報知、及び外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って行う電池式の警報器であって、前記ソフトウェアは、前記警報器の使用開始後に要求に応じたアップデートが可能なように内蔵されており、要求される前記アップデートの実行を、前記電池の残量に基づいて行うように構成されている。

【0010】

本発明の警報器は、前記アップデートの実行を、前記電池の残量及び要求されるアップデートの内容に基づいて行うように構成されていてもよい。

【0011】

要求されるアップデートの種類に応じて、前記警報器に対して直接又は前記警報器の近傍で行われる所定の手動操作でのみ前記アップデートの要求が可能であるか、前記警報器に対して直接又は前記警報器の近傍で行われる所定の手動操作及び前記手動操作以外に前記警報器の外部の機器から送られる信号のいずれでも前記アップデートの要求が可能であってもよい。

【0012】

前記警報器は、ユーザーによる操作が可能なように設けられていて前記アップデート以外の所定の動作の実行を指示する第１操作を受ける被操作部をさらに備え、前記所定の手動操作は、前記被操作部に対する前記第１操作以外の操作であってもよい。

【0013】

前記警報器は、前記監視結果に基づく警報の発報中には前記アップデートを実行しないように構成されていてもよい。

【0014】

本発明の警報システムは、上記いずれか１つの警報器と、前記警報器との間で通信による情報交換を行う制御装置と、を備え、前記警報器は前記電池の残量に関する情報を前記制御装置に送信し、前記制御装置が、前記警報器から送られる前記情報に基づいて、要求される前記アップデートの実行を判断する。

【0015】

上記警報システムにおいて、前記警報器は、前記制御装置から送られる更新データを用いて前記アップデートを実行するように構成されており、前記制御装置は、前記電池の残量が所定の閾値以下のときには、前記更新データを前記警報器に送らないように構成されていてもよい。

【発明の効果】

【0016】

本発明によれば、電池式の警報器に新たな制御方式を適宜取り入れることができ、しかも、電池の残量低下による警報器の機能の停止を抑制し得ることがある。

【図面の簡単な説明】

【0017】

【図1】本発明の一実施形態の警報器の一例の概略を示すブロック図である。

【図2】一実施形態の警報器におけるアップデートの要求方法の例を示す模式図である。

【図3】一実施形態の警報器におけるアップデートの優先度と電池残量に応じた実行の判断との対応の一例を示す図である。

【図4】一実施形態の警報器の動作の一例を示すフローチャートである。

【図5】一実施形態の警報器の記憶領域の構成及び記憶内容の一例を示す模式図である。

【図6】本発明の一実施形態の警報器の他の例の概略を示すブロック図である。

【図7】一実施形態の警報器の動作の他の例を示すフローチャートである。

【図8】一実施形態の警報器の変形例の概略を示すブロック図である。

【図9】一実施形態の警報器と外部機器との間のデータ伝送単位のデータ構造例を示す図である。

【図10】本発明の一実施形態の警報システムの一例を示すブロック図である。

【発明を実施するための形態】

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

電源部３は、制御部１０及び通信部２０を含む、警報器１００の内部の各構成要素に電力を供給する。本実施形態の警報器１００では、電源部３は、例えば乾電池やバッテリのような、放電による電気エネルギーを放出する電池３０の直流電力を警報器１００内の各構成要素に供給する。すなわち、電源部３は、主に電池３０によって構成され得る。電池３０の電力で、周囲環境の監視、監視結果に基づく報知、及び外部機器Ｅとの交信が行われる。すなわち、本実施形態の警報器１００は、電池３０の電力で稼働する電池式の警報器である。電源部３を構成する電池３０は充電可能なバッテリなどの二次電池であってもよいが、電池３０が、各種の乾電池やリチウム一次電池のような充電不能な一次電池である場合、本実施形態の警報器が、より有意に作用することがある。なお、警報器１００の非稼働時には、電池３０が警報器１００の内部にセットされていないこともあり得る。しかし、警報器１００の稼働時には、例えば乾電池などの電池３０が電源部３にセットされる。

【0023】

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

【0024】

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

【0025】

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

【0026】

一方、本実施形態の警報器１００は、要求されるソフトウェアＳＷのアップデートの実行を、電池３０の残量に基づいて行うように構成されている。図１の警報器１００では、警報器１００自身が、要求されるソフトウェアＳＷのアップデートを要求通り実行するか否かを、電池３０の残量に応じて判断している。例えば電池３０の残量が所定の閾値以下であると、警報器１００のユーザーや外部機器Ｅなどからアップデートの要求があっても、アップデートは実行されない。そのため、アップデートによる電池残量のさらなる低下を防いで、警報器１００が電池３０の残量不足によって機能不全に陥ることを防ぐことができる。すなわち、周囲環境の監視から監視結果に基づく報知までの警報器１００の本質的機能が発揮される状態を、より長く維持させることができる。なお、本明細書において「警報器１００（又は、制御部１０、通信部２０、若しくはこれら以外の各構成要素）が特定の動作又は処理を行うように（又は行わないように）構成される」は、警報器１００などにその特定の動作又は処理を行わせる（又は行わせない）命令が、警報器１００などの動作や処理を記述するプログラムに、すなわちソフトウェアＳＷに含まれていることを含んでいる。

【0027】

要求されたアップデートが実行されない、電池残量に関する「所定の閾値」は、一例として、電池３０の端子間電圧で規定される。例えば、電池３０の使用開始時の電圧が３．０Ｖの場合、所定の閾値は、２．６Ｖ、又は２．２Ｖであり得る。後述のように複数の閾値が設けられる場合、電池３０の端子間電圧に関するより低い閾値が２．２Ｖであり、より高い閾値が２．６Ｖであってもよい。すなわち、ソフトウェアＳＷのアップデートの内容に応じて、電池３０の端子間電圧が２．６Ｖ以下であれば、要求に応じて一部のアップデートだけが実行され、端子間電圧が２．２Ｖ以下であれば、全てのアップデートが実行されなくてもよい。

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

図１の警報器１００は、さらに、電池３０の残量を測定する電池残量計測手段３１を備えている。電池残量計測手段３１は、電池３０の端子間電圧若しくはインピーダンスの測定や、電池３０からの流出電流の継続的な測定によって、電池３０の残量を把握する。電池残量計測手段３１は、一例として、電池残量計ＩＣなどと称される電子部品によって実現され得る。警報器１００が電池残量計測手段３１を備えているので、電池３０の残量が所定値以下の場合に、ソフトウェアＳＷのアップデートを実行せずに電池３０を延命させることができる。電池残量計測手段３１は、電源部３又は制御部１０内に取り込まれていてもよい。

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

このように本実施形態の警報器では、要求に応じて、適宜ソフトウェアＳＷのアップデートが行われ、先進的な制御方式の下で、及び／又は、改定された法規に従って、継続して本質的機能が発揮される。一方、前述したようにアップデートの実行は電力消費を増加させ得るので、本実施形態では、電池３０の残量不足による警報器の本質的機能の停止を回避すべく、電池３０の残量に応じて、アップデートを実行するか否かが判断される。なお、商用電源を利用する警報器では、停電を除いて供給電力不足の懸念は無いが、警報器１００の設置場所が制約されることがある。

【0047】

また警報器には、前述したように各種のセンサを備えているという警報器特有の事情がある。すなわち、警報器が備える各種のセンサの多くは、その性能を維持できる年月に限りがあり、例えば１０年などの、継続使用可能な寿命を個々に有している。従って、電源の供給能力に関わらずセンサの寿命が尽きれば、その警報器は交換を余儀なくされる。そのため、充電可能ではあるものの高価な二次電池よりも、リチウム一次電池、乾電池などの一次電池の方が、警報器の電源として適することがある。そして、一次電池が用いられる場合、センサの耐用期間中又は保証期間中、警報器を適切に稼働させ得る電力を電池が維持するように警報器が設計され、それを可能にする容量を有する電池が警報器に内蔵される。そのため警報器は、ユーザーの不要な電池の取り外しを防ぐべく、容易に電池を取り外せないように設計されることもある。

【0048】

これに対して電池残量低下後のアップデートの実行は、その設計コンセプトの成立を妨げてしまうおそれがある。すなわち、電池残量の低下時のアップデートによって、警報器の本質的機能が停止してしまったのでは、充電も電池交換もできないために警報器自体の交換まで周囲環境が監視されない状況にユーザーを晒してしまうおそれがある。そのような状況に陥るおそれがあるくらいなら、むしろ、アップデートを行わずに、僅かに旧式の通信規格や仕様によるものであっても本質的機能を維持させる方が好ましい。また、電池残量が低下している状況では、センサの保証期間の満了も近付いていると考えられる。従ってそのような状況では、電池の存命期間を短縮させかねないアップデートをその短縮後の短い期間の為に実行するよりも、センサの保証期間満了まで電池を延命させる方が好ましいこともある。本実施形態の背景には、このような警報器特有の事情も存在する。

【0049】

＜アップデートに対する電池残量以外の制限＞
本実施形態の警報器では、ソフトウェアＳＷのアップデートを実行するか否かが、電池３０の残量と共に、電池３０の残量以外の警報器の状況、並びに要求されるアップデートの種類や内容によって判断されてもよい。

【0050】

例えば、警報器１００は、周囲環境の監視結果に基づいて異常が検知されて警報器１００が警報の発報中であるときは、ソフトウェアＳＷのアップデートの要求があっても、アップデートを実行しないように構成されていてもよい。すなわち、警報器１００が警報の発報中ではなく、且つ、電池残量が所定値を超えている場合に、要求に応じてソフトウェアＳＷのアップデートが実行される。アップデートが実行されると、警報器１００の発報機能が影響を受けることがある。そのため、警報の発報中は、例え要求があってもアップデートを開始しないことが好ましいことがある。特に、図１の例のように、制御部１０と通信部２０とが処理装置１を共有している場合、例え通信部２０に関するアップデートであっても、警報の発報動作が影響を受ける可能性がある。そのため、警報の発報中には、アップデートを行なわないことが好ましい場合がある。

【0051】

要求されたアップデートが警報発報中のために実行されない場合、例えば、警報の停止（例えば、ユーザーによる警報停止操作や異常状態からの復帰など）を経て、アップデートが実行される。或いは、警報中のアップデートの要求は一旦キャンセルされ、警報停止後の再度のアップデートの要求を受けてからアップデートが実行されてもよい。

【0052】

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

【0053】

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

【0054】

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

【0055】

このように本実施形態では、要求されるアップデートの種類に応じて、警報器１００に対して直接又は警報器１００の近傍で行われる所定の手動操作でのみソフトウェアのアップデートの要求が可能であるか、そのような手動操作、及び手動操作以外に外部機器Ｅのような警報器１００の外部の機器から送られる信号のいずれでもアップデートの要求が可能であってもよい。そのようにアップデートの種類に応じて、警報器１００が受け付ける要求方法を区別することによって、例えば、必要性の高いアップデートの適宜の実行を担保しつつ、アップデートによる警報器１００の警報発報機能の低下リスクを軽減し得ることがある。

【0056】

上記の「警報器１００に対して直接又は警報器１００の近傍で行われる所定の手動操作」は、前述した被操作部５に触れるような直接的な所定の操作Ｍ１や、警報器１００の近傍の専用端末類Ｐｎへのアップデートを指示する手動操作であり得る。操作Ｍ１は、アップデートを要求すべく被操作部５に対して直接行われる手動操作、すなわち前述した「第１操作」以外の操作であり得る。一方、この「所定の手動操作」には、例えば外部機器Ｅ内の制御プログラムなどによるアップデートの要求信号の自動的な送信は当然含まれない。

【0057】

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

【0058】

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

【0059】

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

【0060】

また、アップデートの「種類」は、アップデートの対象となる警報器１００の機能を意味してもよい。例えば、警報器１００の報知機能に関するアップデートが第１種のアップデート及び第２種のアップデートの一方に含まれ、警報器１００の通信機能に関するアップデートが、その他方に含まれてもよい。すなわち、報知機能に関するアップデートと通信機能に関するアップデートのいずれが、上記の「所定の手動操作」に要求方法が限定されるアップデートであってもよく、より多くの要求方法による要求が受け付けられるアップデートであってもよい。個々のアップデートの内容によって、要求方法が制限されるべきか否かが異なり得るからである。

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

図４を参照して、アップデートの実行に関する上記の一連の制限を有する本実施形態の警報器における基本的な動作を説明する。図４は、電池残量に対する複数の閾値を有する本実施形態の警報器の動作の一例を示すフローチャートである。

【0068】

図４のステップＳ１において周囲環境の監視が開始されると、監視動作と並行して、警報器に備えられているいずれかのアップデートの要求方法によるアップデートの要求の有無がモニタされ、アップデートの要求がなければ（ステップＳ２で“Ｎ”）、監視動作が継続される。そしてアップデートの要求があると（ステップＳ２で“Ｙ”）、電池残量が閾値よりも大きいかどうかが判断される（ステップＳ３）。例えば、電池残量計測手段３１（図１参照）によって電池残量が測定され、その測定値と、警報器内の記憶手段１１（図１参照）内に記憶されている電池残量に関する閾値とが制御部１０の処理装置１（図１参照）によって比較される。図４は電池残量について複数の閾値を有する警報器の例なので、電池残量は各閾値と比較され、それぞれの比較結果が、例えば記憶手段１１などに記憶される。電池残量が、少なくとも、最も小さい閾値よりも大きいと（ステップＳ３で“Ｙ”）、アップデートの要求方法が、先に図２を参照して説明されたようなアップデートの種類に応じた適切な方法であったか否かが判断される（ステップＳ４）。要求方法が適切であると（ステップＳ４で“Ｙ”）、要求されたアップデートが実行すべき内容であるかどうかが判断される（ステップＳ５）。図４は電池残量に対する複数の閾値を有する警報器の例なので、図３を参照して説明されたように、ステップＳ３での比較結果に対して、要求されているアップデートの内容が実行すべき内容であるかどうかが、例えば、与えられた優先度を参照して判断される。要求されたアップデートが実行すべき内容であると（ステップＳ５で“Ｙ”）、警報発報中でなければ（ステップＳ６で“Ｙ”）、アップデートが実行される（ステップＳ７）。アップデートの実行後、ループＬ１で、制御がステップＳ２に戻って、周囲環境の監視の継続と共にアップデートの要求の有無がモニタされる。ステップＳ２～Ｓ６のいずれかでの判断が“Ｎ”の場合も、ループＬ１で制御がステップＳ２に戻される。

【0069】

なお、図４において、ステップＳ３、Ｓ４、及びＳ５の順序は相互に入れ替えられてもよい。しかしステップＳ３は、少なくともステップＳ５より先に行われる。なお、ステップＳ４～Ｓ６は、必ずしも実行されず、省略されてもよい。

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

＜一実施形態の警報器の他の例＞
図６には、一実施形態の警報器の他の例である警報器１０１の主要な構成要素がブロック図で示されている。警報器１０１は、制御部１０と通信部２０とが、図１の例の処理装置１のような処理装置を共有していない点で、図１に示される警報器１００と異なっている。図６において、図１の例の警報器１００の構成要素と同様の構成要素については、図１に付された符号と同じ符号が付されるか省略され、その構成要素に関する繰り返しとなる説明は省略される。

【0076】

警報器１０１では、制御部１０は第１処理装置１ａを含んでいる。第１処理装置１ａは、周囲環境を監視して監視結果に基づく報知を行う報知機能を制御する半導体装置によって構成されている。通信部２０は第２処理装置２ａを含んでいる。第２処理装置２ａは、警報器１０１と外部機器Ｅとの間の通信を制御する半導体装置によって構成されている。制御部１０と通信部２０とは、好ましくは互いに相手方との間で信号の送受が可能なように接続されている。警報器１０１において制御部１０は、周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを、通信部２０を介して外部機器Ｅに通知するように構成されている。従って、周囲環境が異常な状態にあることを警報器１０１の遠方にいるユーザーにも報せることができる。

【0077】

第１処理装置１ａ及び第２処理装置２ａは、マイコンやＡＳＩＣなどの半導体装置からなり、図１の例の処理装置１と同様に演算機能、比較機能、及び記憶機能などを有している。第１処理装置１ａは、周囲環境を監視する警報器１０１の報知機能を全体的に制御する。第２処理装置２ａは、送受信部２２で行われる外部機器Ｅとの交信に必要な動作を全体的に制御する。第２処理装置２ａは、特定の時間からの経過時間をカウントするカウンタなどで構成される計時手段２ｃを備えている。図６の例の通信部２０も、計時手段２ｃを用いて、図１の警報器１００について前述した「定期通信」を行ってもよい。定期通信のために経過時間をカウントする計時手段は第１処理装置１ａに備えられていてもよい。

【0078】

第１処理装置１ａは、記憶手段１ｂにソフトウェアＳＷ１を内蔵していてソフトウェアＳＷ１に含まれる命令に従って動作する。第２処理装置２ａは、第２処理装置２ａにソフトウェアＳＷ２を内蔵していてソフトウェアＳＷ２に含まれる命令に従って動作する。警報器１０１においても、ソフトウェアＳＷ１及びソフトウェアＳＷ２は、警報器１０１の使用開始後にアップデートが可能なように内蔵されており、図１の警報器１００について説明されたアップデートと同様の方法でアップデートされ得る。第１処理装置１ａ及び第２処理装置２ａを含む警報器１０１では、ソフトウェアＳＷ１のアップデートは、第２処理装置２ａが制御する通信機能に影響し難く、ソフトウェアＳＷ２のアップデートは、第１処理装置１ａが制御する報知機能に影響し難い。

【0079】

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

【0080】

従って、外部機器Ｅに警報の発報は知らされないものの、少なくとも警報器１０１の近傍のユーザーには、ソフトウェアＳＷ２のアップデート中であっても、異常状態の発生を報せることができる。換言すると、警報器１０１の近傍のユーザーまで、異常の発生が知らされない危険な状態に置くことなくソフトウェアＳＷ２のアップデートを適宜に行うことができる。

【0081】

また、警報器１０１は、このようにソフトウェアＳＷ２のアップデート中は警報発報中であることを外部機器Ｅに通知できないので、例えば制御部１０は、ソフトウェアＳＷ２のアップデートが始まる前に、警報発報の通知が不能になることを外部機器Ｅに通知するように構成されていてもよい。遠方のユーザーなどに、警報が発せられても通知されない状況にいることを了知させることができる。加えて、アップデートの終了後には、警報の発報が通知される通常の状況に復帰したことを報せるように制御部１０が構成されていてもよい。

【0082】

なお、ソフトウェアＳＷ１のアップデート時には、報知機能そのものが影響を受ける可能性がある。そのため、制御部１０は、ソフトウェアＳＷ１のアップデートの開始前に、周囲環境の監視から警報の発報までの一連の機能が停止状態となることを外部機器Ｅに通知し、その終了後には通常の報知機能が復旧したことを通知するように構成されていてもよい。

【0083】

或いは、警報器１０１では、警報器１０１の使用開始後のソフトウェアＳＷ１のアップデートができないように構成されていてもよい。すなわち、ソフトウェアＳＷ１のアップデートが、前述した「報知機能に関するアップデート」に該当し、ソフトウェアＳＷ２のアップデートが「通信機能に関するアップデート」に該当する。従って、警報器１０１では、ソフトウェアＳＷ２のアップデートが可能である一方、ソフトウェアＳＷ１のアップデートが不能なように構成されていてもよい。

【0084】

図７には、図６の例の警報器１０１における、ソフトウェアのアップデートを含む動作の一例を示すフローチャートが示されている。図７の例は、通信部２０において前述した「定期通信」が行われる例である。なお、図７に示される各ステップのうち、図４に示されるステップと同様の動作や処理を行うステップについては、図４と同じ符号（ステップＳ１～Ｓ３）が付され、繰り返しとなる説明は、適宜省略される。

【0085】

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

【0086】

図７の例においてステップＳ２でソフトウェアのアップデートが要求されていると（ステップＳ２で“Ｙ”）、図４を参照して説明された動作と同様に、電池残量が閾値よりも大きいかどうかが判断され（ステップＳ３）、さらにアップデートを実行すべきかどうかが判断される（ステップＳ４６）。ステップＳ４６では、図４のフローチャートにおいてステップＳ４～Ｓ６で示されている判断と同様の判断が行われる。ステップＳ３又はステップＳ４６での判断が否定的（ステップＳ３又はＳ４６で“Ｎ”）であり、異常状態Ａｂの発生もなければ、ステップＳ１７で所定時間の経過の有無が判断され、前述したステップＳ１７以降の処理が実行される。

【0087】

ステップＳ３及びステップＳ４６両方の判断が肯定的（ステップＳ３及びＳ４６で“Ｙ”）であると、図７の例では、先ずアップデートの開始が外部機器Ｅに通知される（ステップＳ１２）。ここで、要求されているアップデートが通信部２０に関するソフトウェアＳＷ２（図６参照）のアップデートであると、警報の発報が外部機器Ｅに知らされない状態となることが外部機器Ｅに通知される。また、要求されているアップデートが制御部１０に関するソフトウェアＳＷ１（図６参照）のアップデートであると、警報の発報自体ができない状態となることが、外部機器Ｅに通知される。その後、アップデートが開始され（ステップＳ１３）、異常状態Ａｂの発生がなければ、アップデートの終了（ステップＳ１５）後、ステップＳ１７で所定時間の経過の有無が判断され、前述したステップＳ１７以降の処理が実行される。

【0088】

一方、アップデートが実行されない場合に、又はアップデートを実行する場合のアップデートの開始（ステップＳ１３）後に、異常状態Ａｂが発生すると、いずれの場合も警報器１０１において警報が発せられる（ステップＳ１４）。そして、アップデート実行中でない場合だけ、外部機器Ｅに警報発報中であることが通知される（ステップＳ１６）。これに対してアップデート実行中は、警報発報だけが行われ、外部機器Ｅには、警報の発報が知らされない。なお、アップデート終了（ステップＳ１５）後に、アップデートの終了が外部機器Ｅに通知されてもよい。

【0089】

また、警報器１０１において制御部１０は、通信部２０に関するアップデートの実行中に発する警報と、何のアップデートも実行していないときに発する警報の発報態様を異ならせるように構成されていてもよい。そうすることで、外部機器Ｅに警報発報が通知されていないことを、警報器１０１の近傍のユーザーに報せることができる。例えば、警報発報時に発するメッセージが、アップデート実行中と非実行中とで変えられてもよい。さらに、制御部１０は、アップデート実行中と非実行中とで、発報した警報の停止に必要な操作を変えるように構成されていてもよい。こうすることでも、外部機器Ｅに警報発報が通知されていないことを、警報器１０１の近傍のユーザーに報せることができる。

【0090】

また、制御部１０は、警報の発報前に開始された通信部２０に関するソフトウェアＳＷ２のアップデートが警報発報中に終了すると、警報を発報中であることを外部機器Ｅに報せるように構成されていてもよい。さらに、制御部１０は、通信部２０に関するソフトウェアＳＷ２のアップデートの実行中に発した警報がそのアップデートの終了前に停止された場合、そのアップデートの終了後に、そのアップデート中に警報を発したことを外部機器Ｅに報せるように構成されていてもよい。

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

図８の警報器１０２は、このように、図１の警報器１００と同様に単一の処理装置１を備えているが、その内部が制御部１０を担う部分と通信部２０を担う部分とに区分されている。そのため、警報器１０２においても、図６の警報器１０１について述べたように、ソフトウェアＳＷ１のアップデートは通信機能に影響し難く、ソフトウェアＳＷ２のアップデートは報知機能に影響し難いと考えられる。しかも、制御部１０及び通信部２０のいずれも処理装置１で主に構成されているので、制御部１０と通信部２０とを跨ぐような処理が高速に行われると考えられる。

【0097】

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

【0098】

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

【0099】

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

【0100】

なお、警報器１００において、前述したように警報の発報が外部機器Ｅに通知される場合、その通知に対する応答信号にアップデート用の更新データが含められてもよい。この場合も、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器１００に供給することができる。また、警報器１００は、複数の応答信号に分割して送られる更新データの全てを受け取ると、自律的にソフトウェアのアップデートを開始してもよい。

【0101】

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

【0102】

＜一実施形態の警報システム＞
つぎに、本発明の一実施形態の警報システムについて説明する。図１０には、一実施形態の警報システムの一例である警報システム２００がブロック図で示されている。図１０に示されるように、警報システム２００は、警報器２１０と、警報器２１０との間で通信による情報交換を行う制御装置２２０と、を備えている。警報器２１０は、図１～図９を参照して説明された一実施形態の警報器（例えば警報器１００や警報器１０１）であり得る。制御装置２２０は、警報器２１０の動作を警報システム２００のユーザーの指示に従って、及び／又は制御装置２２０に内蔵された制御プログラムに従って、制御する。制御装置２２０は、さらに、警報器２１０での検知結果若しくは警報発報経過を収集して統計処理若しくは解析してもよい。制御装置２２０としては、警報器２１０を監視及び制御する上位装置として機能するサーバーのような情報処理装置が例示される。図１及び図６に示される外部機器Ｅのいずれかが警報システム２００の制御装置２２０であってもよい。制御装置２２０は、演算機能、比較機能、記憶機能などを有する処理装置２２１を含んでいる。処理装置２２１は、図１の警報器１００が含む処理装置１と同様に、例えば、マイコンやＡＳＩＣなどの半導体装置からなり、内蔵されたプログラムに従って動作し得る。

【0103】

図１０に示されるように、警報システム２００において警報器２１０は、電池３０の残量に関する情報Ｉｆを制御装置２２０に送信するように構成されている。警報器２１０は、電池残量計測手段３１（図１参照）によって測定された電池３０の残量そのものを、情報Ｉｆとして制御装置２２０に送信してもよく、電池残量の推定を可能にする任意の情報を制御装置２２０に送ってもよい。例えば、電池３０の端子電圧、又は、警報器２１０の稼働開始からの経過時間及び電池３０からの流出電流の測定データが、情報Ｉｆとして制御装置２２０に送られてもよい。また、警報発報の累積時間やソフトウェアのアップデートの累積時間が制御装置２２０に送られてもよい。制御装置２２０において、電池３０の端子電圧、電池３０からの流出電流の積算値、或いは、通常時、警報発報時、及びアップデート時それぞれの既知の単位時間消費電力とこれら各状況それぞれでの累積時間の積の合算値によって、電池残量の推定が可能なことがある。警報器２１０からは、このような電池残量に関する情報が、例えば、前述した定期通信によって定期的に、又は任意の適切な時期に随時に、制御装置２２０に送られる。

【0104】

そして、本実施形態の警報システム２００では、制御装置２２０が、警報器２１０から送られる電池残量に関する情報Ｉｆに基づいて、要求されるソフトウェアのアップデートの実行を判断する。従って、警報システム２００では、要求されるアップデートの実行を行うか否かの判断自体は、警報器２１０において行われなくてもよい。警報器２１０は、制御装置２２０での電池残量に基づく判断に従ってアップデートを実行する。例えば、電池残量が所定の閾値以下である場合、制御装置２２０は、要求されるアップデートを実行しないと判断する。制御装置２２０は、アップデートの実施に関する判断結果Ｒｄを警報器２１０へと送信する。警報器２１０では、制御装置２２０から送られる判断結果Ｒｄに従って、ソフトウェアのアップデートが実行されるか、又は、アップデートの要求が却下若しくはその実行が保留される。なお、アップデートの要求は、警報システム２００のユーザーによる警報器２１０又は制御装置２２０に対する直接的な操作で行われてもよく、制御装置２２０の制御プログラムに記述された所定の時期に行われてもよい。或いは、制御装置２２０のさらに上位の装置からの指示でアップデートが要求されてもよい。

【0105】

制御装置２２０では、電池残量に加えて、要求されるアップデートの内容に基づいて実行の判断が行われてもよい。すなわち、図３及び図４を参照して警報器１００において行われるものとして説明された、要求されるアップデートが実行すべき内容のものであるかどうかの判断が、制御装置２２０において行われてもよい。この場合において、警報器２１０への直接的な操作によってアップデートが要求される場合は、警報器２１０は、要求されているアップデートの内容に関する情報を制御装置２２０に送信する。制御装置２２０では、この情報に基づいて、要求されているアップデートが実行すべき内容のものか否かを判断することができる。

【0106】

警報システム２００では、図１などを参照して説明された一実施形態の警報器１００と同様に、警報器２１０は、制御装置２２０から送られる更新データを用いてアップデートを実行するように構成されていてもよい。その場合、制御装置２２０は、電池３０の残量が所定の閾値以下のときには、更新データを警報器２１０に送らないように構成されていてもよい。そうすることによって、警報器２１０と制御装置２２０との間の無用なデータの送受信を回避して、電力消費、特に警報器２１０での電力消費を削減できることがある。

【0107】

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

【0108】

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

【符号の説明】

【0109】

１００、１０１、１０２、２１０ 警報器
２００ 警報システム
１０ 制御部
１１ 記憶手段
２０ 通信部
２２０ 制御装置
３ 電源部
３０ 電池
３１ 電池残量計測手段
５ 被操作部
Ｅ 外部機器
Ｉｆ 電池の残量に関する情報
ＳＷ、ＳＷ１、ＳＷ２ ソフトウェア

【要約】

【課題】電池式の警報器の制御方式を適切に更新することができ、且つ、電池の残量低下による警報器の機能停止の抑制が可能な警報器及び警報システムを提供する。
【解決手段】実施形態の警報器１００は、電池３０の電力で稼働して、周囲環境の監視結果に基づく報知、及び外部機器との交信を、内蔵するソフトウェアＳＷに含まれる命令に従って行う電池式の警報器である。ソフトウェアＳＷは、警報器１００の使用開始後に要求に応じたアップデートが可能なように内蔵されており、警報器１００は、要求されるソフトウェアＳＷのアップデートの実行を、電池３０の残量に基づいて行うように構成されている。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】