特許 7369318 警報器

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

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

(11)【特許番号】

(24)【登録日】2023-10-17

(45)【発行日】2023-10-25

(54)【発明の名称】警報器

(51)【国際特許分類】

   G08B 17/00 20060101AFI20231018BHJP

   G08B 25/10 20060101ALI20231018BHJP

【ＦＩ】

G08B17/00 C

G08B25/10 A

【請求項の数】 8

(21)【出願番号】P 2023042334

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

(65)【公開番号】P2023143806

(43)【公開日】2023-10-06

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

(31)【優先権主張番号】P 2022047190

(32)【優先日】2022-03-23

(33)【優先権主張国・地域又は機関】JP

【早期審査対象出願】

(73)【特許権者】

【識別番号】000190301

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

(74)【代理人】

【識別番号】110001896

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

(72)【発明者】

【氏名】齋藤 和也

【審査官】松原 徳久

(56)【参考文献】

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

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

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

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

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

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

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

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

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

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

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

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

Ｇ０６Ｆ８／００－８／３８

８／６０－８／７７

９／４４－９／４４５

９／４５１

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

Ｈ０４Ｂ７／２４－７／２６

Ｈ０４Ｌ５１／００－５１／５８

６７／００－６７／７５

Ｈ０４Ｍ３／００

３／１６－３／２０

３／３８－３／５８

７／００－７／１６

１１／００－１１／１０

Ｈ０４Ｗ４／００－９９／００

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

【請求項1】

周囲環境を監視して監視結果に基づく報知を行う警報器であって、
前記報知を行う報知機能を制御する半導体装置からなる第１処理装置と、
ソフトウェアを内蔵しており、前記報知に関する情報を外部機器に送る動作を制御する半導体装置からなる第２処理装置と、
を備え、
前記第２処理装置を含む通信部は、前記警報器の使用開始後に前記ソフトウェアのアップデートが可能なように構成されており、
前記第１処理装置は、開始された前記アップデートが正常に終了しない場合は、前記通信部にリセット動作の実行を指示するように構成されている、警報器。

【請求項2】

周囲環境の監視結果に基づいて報知を行う報知機能を制御する半導体装置からなる第１処理装置と、
ソフトウェアを内蔵しており、前記報知に関する情報を外部機器に送る動作を制御する半導体装置からなる第２処理装置と、
を備える警報器であって、
前記第２処理装置を含む通信部は、前記警報器の使用開始後に前記ソフトウェアのアップデートが可能なように構成されており、
前記第１処理装置は、開始された前記アップデートが正常に終了しない場合は、前記通信部にリセット動作の実行を指示するように構成されており、
前記アップデート中に警報を発すべき状態が検知されると、前記アップデートが中断されるか、前記アップデートと並行して警報が発せられるか、前記アップデートの完了が警報の発報よりも優先される、警報器。

【請求項3】

周囲環境の監視結果に基づいて報知を行う報知機能を制御する半導体装置からなる第１処理装置と、
ソフトウェアを内蔵しており、前記報知に関する情報を外部機器に送る動作を制御する半導体装置からなる第２処理装置と、
を備える警報器であって、
前記第１処理装置は、周囲環境を監視する検知部からの前記監視結果に基づいて異常の報知に至る動作を制御し、
前記第２処理装置を含む通信部は、前記警報器の使用開始後に前記ソフトウェアのアップデートが可能なように構成されており、
前記第１処理装置は、開始された前記アップデートが正常に終了しない場合は、前記通信部にリセット動作の実行を指示するように構成されている、警報器。

【請求項4】

前記通信部は、前記警報器の状態を所定の周期で外部機器に送る定期通信を行うように構成されており、
開始された前記アップデートが正常に終了しない場合は、前記リセット動作により前記定期通信が継続される、請求項１～３のいずれか１項に記載の警報器。

【請求項5】

前記通信部は、開始された前記アップデートが正常に終了した場合は、前記リセット動作と同じか前記リセット動作と異なるリセット動作を行うように構成されている、請求項１～３のいずれか１項に記載の警報器。

【請求項6】

前記通信部は、開始された前記アップデートが正常に終了しない場合は、前記リセット動作の後に、前記アップデートの開始前の前記ソフトウェアに従って動作する、請求項１～３のいずれか１項に記載の警報器。

【請求項7】

前記アップデートは、外部機器と前記通信部との無線通信に基づいて行われる、請求項１～３のいずれか１項に記載の警報器。

【請求項8】

前記ソフトウェアは、前記第２処理装置のメモリに書き込まれているファームウェアである、請求項１～３のいずれか１項に記載の警報器。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【特許文献】

【0004】

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

【発明の概要】

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

【0005】

ところで、近年、ＩｏＴ（Internet of Things）の概念の普及にも対応して、多くの機器がインターネットを始めとしたネットワークに接続され、あらゆる情報が通信によって送受されている。そのような、情報通信の利用範囲の拡大や送受されるデータ量の膨張に伴って、通信プロトコルや、それに基づく通信制御プログラムにおいて常にバージョンアップが重ねられている。一方、そのように質及び量の両面で膨張する、通信によって送受される情報を標的として、通信回線を介したハッキングやネットワーク上での盗聴などといった、通信のセキュリティを脅かす悪意のある技術が、日々新たに生み出され、また変異を続けている。このような通信のセキュリティを阻害する新種の技術への耐性を備える面からも、通信制御プログラムの継続的なバージョンアップが求められる。そして通信機能を有する警報器には、このように進化を続ける通信制御技術に絶えず追随することが求められ、さもなければ、例えば、通信のセキュリティを脅かす悪意のある技術の脅威に晒されることとなり得る。しかしながら、警報器の特性上、バージョンアップの際に、警報器の本質的機能である報知機能が機能しない期間があるのは好ましくない。

【0006】

本発明は、上記問題に鑑みてなされたもので、警報器の報知機能に影響を与えないように通信制御技術の向上に追随した通信を継続させることが可能な警報器を提供することを目的とする。

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

【0007】

本発明の警報器は、周囲環境を監視して監視結果に基づく報知を行う報知機能を制御する半導体装置からなる第１処理装置と、ソフトウェアを内蔵しており、前記報知に関する情報を外部機器に送る動作を制御する半導体装置からなる第２処理装置と、を備える警報器であって、前記第２処理装置を含む通信部は、前記警報器の使用開始後に前記ソフトウェアのアップデートが可能なように構成されており、前記第１処理装置は、開始された前記アップデートが正常に終了しない場合は、前記通信部にリセット動作の実行を指示するように構成されている。

【0008】

前記通信部は、前記警報器の状態を所定の周期で外部機器に送る定期通信を行うように構成されており、開始された前記アップデートが正常に終了しない場合は、前記リセット動作により前記定期通信が継続されてもよい。

【0009】

前記通信部は、開始された前記アップデートが正常に終了した場合は、前記リセット動作と同じか前記リセット動作と異なるリセット動作を行うように構成されていてもよい。

【0010】

前記通信部は、開始された前記アップデートが正常に終了しない場合は、前記リセット動作の後に、前記アップデートの開始前の前記ソフトウェアに従って動作してもよい。

【0011】

前記アップデートは、外部機器と前記通信部との無線通信に基づいて行われてもよい。

【0012】

前記ソフトウェアは、前記第２処理装置のメモリに書き込まれているファームウェアであってもよい。

【発明の効果】

【0013】

本発明によれば、警報器の報知機能に影響を与えないようにしながら、通信制御技術の向上に追随した通信を継続させることが可能な警報器を提供することができる。

【図面の簡単な説明】

【0014】

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

【図2A】本発明の一実施形態に係る警報部の概略を示すブロック図である。

【図2B】本発明の一実施形態に係る通信部の概略を示すブロック図である。

【図3】本発明の一実施形態の警報器の第２処理装置が有する記憶領域の構成及び記憶内容の一例を示す模式図である。

【図4】本発明の一実施形態の警報器におけるソフトウェアのアップデート時の基本動作の一例を示すフローチャートである。

【図5】本発明の一実施形態の警報器におけるソフトウェアのアップデート時の具体的な動作の一例を示すフローチャートである。

【図6】本発明の一実施形態の警報器におけるソフトウェアのアップデート時の具体的な動作の他の例を示すフローチャートである。

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

【0015】

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

【0016】

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

【0017】

本実施形態の警報器１００は、図１に示されるように、周囲環境の監視から、監視結果に基づく報知までの機能を含む報知機能を担う警報部１０と、警報器１００と外部機器Ｅとの間の信号の送信及び／又は受信を含む通信機能を担う通信部２０と、警報部１０及び通信部２０が要する電力を供給する電源部３と、を備えている。警報部１０と通信部２０とは、少なくとも警報部１０からの信号の送信、及び通信部２０でのその信号の受信が可能なように、好ましくは互いに相手方との間で信号の送受が可能なように、接続されている。

【0018】

警報部１０は、半導体装置からなる第１処理装置１を含んでいる。第１処理装置１は、周囲環境を監視して監視結果に基づく報知を行う報知機能を制御するように構成されている。通信部２０は、半導体装置からなる第２処理装置２を含んでいる。第２処理装置２はソフトウェアＳＷを内蔵している。第２処理装置２は、ソフトウェアＳＷが含むプログラムに記述された命令に従って動作する。通信部２０は、無線回線Ｃ１又は有線回線Ｃ２を介して外部機器Ｅとの間で直接送受信を行ってもよく、無線回線Ｃ１又は有線回線Ｃ２で接続された、例えばインターネットやローカルエリアネットワーク（ＬＡＮ）などのネットワークＮを介して外部機器Ｅとの間で信号の送受信を行ってもよい。外部機器Ｅとしては、警報器１００以外の同種、又は検知対象の異なる警報器、並びに、警報器１００の動作を監視若しくは制御する、及び／又は、警報器１００での検知結果若しくは警報発報経過を収集して統計処理若しくは解析するサーバーのような情報処理装置が例示される。しかし、外部機器Ｅはこれらに限定されない。

【0019】

電源部３は、警報部１０及び通信部２０を含む、警報器１００の内部の各構成要素に電力を供給する。電源部３は、例えば、商用電源（図示せず）から供給される電力を各構成要素に供給する。その場合、電源部３は、例えば、商用電源から供給される交流電力を所望の電圧の直流電力に変換するインバータや、警報器１００内の構成要素に印加される電源電圧を安定化させる電圧レギュレータなどによって構成され得る。電源部３は、商用電源からの電力ではなく、乾電池などの一次電池やバッテリなどの二次電池の直流電力を警報器１００内の各構成要素に供給してもよい。図１の例の警報器１００は、警報部１０及び通信部２０などへの電源部３からの電力の供給と停止とを切り替える電源スイッチＳを備えている。

【0020】

本実施形態において通信部２０では、第２処理装置２に内蔵されるソフトウェアＳＷのアップデートが、警報器１００の使用開始後に可能なように構成されている。そして警報器１００では、第２処理装置２が内蔵するソフトウェアＳＷについて開始されたアップデートが正常に終了しない場合は、第１処理装置１が通信部２０にリセット動作の実行を指示するように構成されている。第１処理装置１が通信部２０にリセット動作の実行を指示するので、ソフトウェアＳＷのアップデートが正常に終了しない場合でも、通信部２０による外部機器Ｅとの通信機能が維持される。この警報器１００の構成及び作用が、以下に詳細に説明される。

【0021】

＜警報部の構成＞
図２Ａには、警報部１０の内部構成の一例を概略的に示すブロック図が示されている。図２Ａの例において警報部１０は、前述した第１処理装置１を含む警報制御部１１と、検知部１２と、報知部１３と、を備えている。

【0022】

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

【0023】

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

【0024】

警報制御部１１は、主に第１処理装置１で構成され、例えば第１処理装置１と、その周辺部品（図示せず）とで構成される。第１処理装置１は、マイコンやＡＳＩＣなどの半導体装置からなり、内蔵されたプログラム、又は、警報部１０が備える、第１処理装置１の外部のＲＯＭなどの記憶装置（図示せず）に格納されたプログラムに従って動作する。第１処理装置１は、好ましくは、演算機能、比較機能、記憶機能などを有し、検知部１２及び報知部１３の動作を含む警報部１０の動作を全体的に制御する。すなわち、第１処理装置１は、周囲環境を監視する警報器１００の動作中に、検知部１２による周囲環境の監視から報知部１３による異常の報知に至る動作を全体的に制御する。

【0025】

図２Ａの例において第１処理装置１は、計時手段１ａ及び記憶手段１ｂを含んでいる。計時手段１ａは、例えば、特定の時点からの経過時間をカウントする。計時手段１ａは、例えば第１処理装置１を構成するマイコンなどの半導体装置内に構成されたカウンタやタイマであり得る。計時手段１ａは、後述するように、第２処理装置２が内蔵するソフトウェアＳＷのアップデート開始からの経過時間をカウントしてもよい。

【0026】

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

【0027】

警報部１０において第１処理装置１は、例えば、検知部１２による周囲環境の監視動作の開始や停止を制御する。また、第１処理装置１は、検知部１２から得られる検知データが示す、一酸化炭素やガスの濃度、周囲の温度、及び、煙の濃度などが、所定の閾値を超えているか否かを判断する。そして、温度や濃度などが閾値を超えている場合には、例えばその超過の程度に応じて報知の態様（音声の鳴動の仕方や発光の仕方など）を決定し、決定した方法で報知部１３に報知を実行させる。

【0028】

＜通信部の構成＞
図２Ｂには、通信部２０の内部構成の一例を概略的に示すブロック図が示されている。図２Ｂの例において通信部２０は、前述した第２処理装置２を含む通信制御部２１と、送受信部２２と、を備えている。通信部２０が無線によって外部機器Ｅとの間で信号の送受信を行う場合には、送受信部２２はアンテナ２２ａを備え得る。

【0029】

送受信部２２は、無線通信又は有線通信によって外部機器Ｅとの間で信号を送受する。送受信部２２は、外部機器Ｅと警報器１００との間で電気信号を送受するように構成された、集積回路装置や個々の部品からなる電気回路などのハードウェアにより構成される。送受信部２２は、外部機器Ｅとの通信に必要となる、信号の変換（アナログ／デジタル変換や信号のレベル変換など）、信号の増幅、信号の合成及び分解、信号の変調及び復調、外部機器Ｅとの間のリンクの設定、及び／又は誤り制御、などを行うように構成され得る。例えば、送受信部２２は、外部機器Ｅとの通信に必要な信号処理を行うように設計されたＡＳＩＣなどからなる通信制御ＩＣ、又はモデムＩＣ、及びその周辺回路で構成されていてもよい。送受信部２２は、通信制御部２１に組み込まれていてもよい。

【0030】

通信制御部２１は、主に第２処理装置２で構成され、例えば第２処理装置２と、その周辺部品（図示せず）とで構成される。第２処理装置２は、マイコンやＡＳＩＣなどの半導体装置からなり、第２処理装置２によって実行される命令を記述したプログラムなどを含む、内蔵されたソフトウェアＳＷに従って動作する。第２処理装置２は、好ましくは、演算機能や記憶機能、及び比較機能などを有し、警報器１００の動作中に送受信部２２で行われる、警報器１００と外部機器Ｅとの間での交信に必要な動作を全体的に制御する。

【0031】

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

【0032】

図２Ｂの例において第２処理装置２は計時手段２ａ及び記憶手段２ｂを含んでいる。計時手段２ａは、例えば、特定の時点からの経過時間をカウントする。また、計時手段２ａは、外部機器Ｅからタイムスタンプ情報（例えばパーソナルコンピュータやサーバーのエポックタイム）を受け取り、そこからの経過時間をカウントしてもよい。計時手段２ａは、例えば第２処理装置２を構成するマイコンなどの半導体装置に構成されたカウンタやタイマであり得る。計時手段２ａは、後述するように、第２処理装置２が所定の信号の送信を行ってからの経過時間をカウントしてもよい。

【0033】

記憶手段２ｂは、第２処理装置２で実行される処理に必要な任意の情報を記憶する。記憶手段２ｂは、第２処理装置２に組み込まれた、ＲＯＭ、ＰＲＯＭ（プログラマブルＲＯＭ）、ＲＡＭ、フラッシュメモリ、及び各種のレジスタなどのメモリ空間であり得る。例えば、記憶手段２ｂを構成し得るＥＰＲＯＭ（イレーサブルＰＲＯＭ）には、前述したソフトウェアＳＷなどの第２処理装置２の動作を記述したプログラムが格納されていてもよい。また、例えば、記憶手段２ｂを構成するレジスタには、後述するように、ソフトウェアのアップデートの開始時の時刻に関する情報が記憶されてもよい。

【0034】

通信部２０は、監視の実行中、電池切れ状態、故障中、及び、警報発報中などの上記「警報器１００の状態」を所定の周期で外部機器Ｅに送る通信（定期通信）を行うように構成されていてもよい。定期通信を行うことによって、外部機器Ｅから適時に適切な制御を受け得ることがある。また、定期通信を行うことによって、警報器１００の状態を、ネットワークを介して、外部機器Ｅであり得る監視用のサーバーなどが把握することができ、警報器１００が健全に動作していることを把握することができる。例えば所定の時間内に定期通信による受信があれば、警報器１００が正常動作していることがサーバーなどの側で把握されるし、受信される情報の中に故障や電池切れの情報があれば、警報器１００のユーザーや監視業者などが、その交換時期などを知ることができる。所定の周期は、警報器１００の検知対象や使用場所などによって適宜選択される。所定の周期は、例えば数分程度であってもよく、数時間、或いは数日程度であってもよい。

【0035】

＜ソフトウェアのアップデート＞
前述したように、通信部２０では、第２処理装置２に内蔵されるソフトウェアＳＷのアップデートが、警報器１００の使用開始後に可能なように構成されている。例えば、ソフトウェアＳＷは、第２処理装置２に記憶手段２ｂとして備えられるＥＰＲＯＭ、好ましくは、ＥＥＰＲＯＭ（エレクトリカリー・イレーサブルＰＲＯＭ）やフラッシュメモリなどに格納されている。ＥＥＰＲＯＭ及びフラッシュメモリなどのメモリでは、例えば電荷の蓄積や抜き取りが可能な高電圧の印加などの特定の電気的環境をメモリに与えることによって、既に記憶されている内容を書き換えることができる。

【0036】

例えばこのように、ＥＥＰＲＯＭやフラッシュメモリなどのメモリで構成される、第２処理装置２が備える書き換え可能な記憶領域にソフトウェアＳＷを格納することによって、警報器１００の使用開始後であっても、すなわち、警報器１００の工場出荷後であっても、ソフトウェアＳＷのアップデートの実行が可能となる。例えば、第２処理装置２が備えるＣＰＵ（図示せず）の制御の下で、記憶手段２ｂとして備えられているフラッシュメモリなどの記憶内容が書き換えられ、その結果、ソフトウェアＳＷがアップデートされる。このように、第２処理装置２が内蔵するソフトウェアＳＷのアップデートが警報器１００の使用開始後にも可能なので、例えば、通信先の外部機器Ｅの変更や、外部機器Ｅとの通信に用いる通信規格の変更などに応じて、ソフトウェアＳＷをアップデートして、第２処理装置２を適切に動作させることができる。

【0037】

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

【0038】

警報器を含む各種機器間の通信において準拠される通信規格は、例えば新たに出現するハッキング技術などに対抗すべく、セキュリティ要件などに関して適宜改定されている。また通信規格は、新たに開発される通信技術を取り入れるべく改定されることもある。例えば、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）が制定するＩＥＥＥ８０２．１において仕様が規定されているネットワーク規格であるＴＳＮ（Time-Sensitive Networking）では、２０２１年から遡る数年の間に幾度かの改定が行われている。第２処理装置２に関するソフトウェアＳＷのアップデートが可能でないと、これら通信規格の改定に準拠できず、警報器１００と外部機器Ｅとの間の通信が、ハッキングや盗聴などの脅威に晒されたり、警報器１００の使用が制限されたりすることも起こり得る。

【0039】

本実施形態の警報器１００では、第２処理装置２に内蔵されるソフトウェアＳＷのアップデートが可能なように、通信部２０が構成されている。そのため、適宜ソフトウェアＳＷの更新を行うことによって、通信制御技術の向上に追随すると共に、通信のセキュリティに対する脅威に晒され難い通信を継続させることができる。

【0040】

本実施形態では、通信部２０は、前述したように、外部機器Ｅとの間で無線によって信号の送受信を行ってもよい。従って、ソフトウェアＳＷのアップデートは、外部機器Ｅと通信部２０との無線通信に基づいて行われてもよく、その場合、外部機器Ｅからアップデート後のソフトウェアＳＷが供給される。すなわち、ソフトウェアＳＷのアップデートは、所謂「ＯＴＡ（Over-The-Air）アップデート」であってもよく、前述したようにソフトウェアＳＷがファームウェアである場合「ファームウェアＯＴＡ（ＦＷＯＴＡ）」であってもよい。その場合、通信ケーブルのような物理的な回線を警報器１００と外部機器Ｅとの間に設けることなく、例えば、遠隔地からでもソフトウェアＳＷをアップデートすることができる。従って、例えば改定後の通信規格に沿った通信、及び／又は、セキュリティの脅威に晒され難い通信を、容易に通信部２０に行わせることができる。例えばソフトウェアＳＷのアップデートに用いられる無線通信は、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ－Ｆｉ（登録商標）などの近距離無線通信であってもよい。従って、外部機器Ｅは、携帯電話やタブレット型コンピュータなどの携帯機器であってもよい。

【0041】

なお、ソフトウェアＳＷのアップデートは、無線通信に依らず、警報器１００に接続された物理的な回線を通じて行われてもよく、アップデート後のソフトウェアＳＷが格納された例えばＵＳＢメモリなどの記憶媒体を第２処理装置２と電気的に接続することによって行われてもよい。

【0042】

＜アップデート失敗時の制御＞
一方、警報器１００では、前述したように、警報器という特性上、通信部２０におけるソフトウェアＳＷのアップデートであっても、その間に、本質的機能である報知機能が機能しない期間があるのは好ましくない。報知機能は、警報部１０だけで完結する場合もあるが、周囲環境が警報を発するべき状況にあることを通信部２０によって外部機器Ｅに報せるように警報器１００が構成されていることもある。その場合は、通信部２０におけるソフトウェアのアップデートが成功裏に終了しないと、通信部２０による通信が適切に行われずに報知機能が機能しない期間が生じることがある。また、警報器１００が外部機器Ｅとの交信結果に基づいて警報部１０による監視動作や報知動作を行うように構成されている場合も、ソフトウェアＳＷのアップデートが正常に終了しないと、報知機能が機能しない期間が生じることがある。例えば、警報器１００と外部機器とが所定の周期で定期的に交信（例えば前述した「定期通信」）を行うことを前提に警報部１０の動作が継続するように構成されている場合に通信部２０におけるソフトウェアＳＷのアップデートが正常に終了しないと、定期通信が途絶えることがある。その結果、報知機能が機能しない期間が生じることがある。そして、このような報知機能が機能しない期間が生じ得ることは、国や地方自治体、又はその他の公的機関によって定められた警報器に関する検定に適合せず、警報器１００が適法に使用され得ないことも起こり得る。

【0043】

これに対して、本実施形態では、前述したように、通信部２０において開始されたソフトウェアＳＷのアップデートが正常に終了しない場合は、第１処理装置１が通信部２０にリセット動作の実行を指示するように構成されている。そのため、通信部２０では、ソフトウェアＳＷのアップデートが正常に終了しなくても、リセット動作の実行を経て、通信機能を維持させることができる。例えば前述した「定期通信」が、リセット動作の実行によって継続され得る。

【0044】

通信部２０は、開始されたソフトウェアＳＷのアップデートが正常に終了しない場合は、リセット動作の後に、当該アップデートの開始前のソフトウェアＳＷに従って動作してもよい。その場合、少なくともアップデートの開始前のソフトウェアＳＷに従った通信を、外部機器Ｅとの間で継続させることができる。アップデートが正常に終了しないときに、すなわちアップデートが一旦開始された後に、アップデートの開始前のソフトウェアＳＷに従う通信部２０の動作を可能にする方法は後述される。

【0045】

このように、本実施形態では、ソフトウェアＳＷのアップデートが正常に終了しない場合には第１処理装置１が通信部２０にリセット動作の実行を指示するので、通信部２０が関わる、警報部１０の報知機能が機能しない期間の発生を防ぐことができる。そして第１処理装置１は、第２処理装置２に内蔵されるソフトウェアＳＷのアップデートが正常に終了しない場合であっても、必ずしも、報知機能が機能しなくなるような第１処理装置１自身のリセット動作を実行しない。すなわち、第１処理装置１は、第１処理装置１自身が制御を担う報知機能を維持したまま、第２処理装置２へのリセット動作の指示が可能なように構成されている。従って、周囲環境が警報を発するべき状態にあることを、報知すべき人や機器に、絶えることなく報せることができる。また、警報器に対する検定に警報器１００を適合させ得ることがある。

【0046】

なお、アップデートが正常に終了しない場合には、第１処理装置１は、一例として、第１処理装置１が従うプログラムに記述された命令に従って、第２処理装置２にリセット動作の実行を指示する。すなわち、第１処理装置１が自動的にリセット動作の実行を第２処理装置２に指示するように構成されていてもよい。しかし、アップデートが正常に終了しない場合に外部からの手動操作を受けて、その操作に従って、第１処理装置１が第２処理装置２にリセット動作の実行を指示するように構成されていてもよい。この場合、警報器１００には、手動操作を受け付ける受付部（図示せず）が備えられる。受付部は、例えば、押しボタンスイッチのような被操作手段や、Bluetoothのような近距離無線通信の受信手段であり得る。アップデートが正常に終了しない場合、第１処理装置１は、例えば報知部１３（図２Ａ参照）を用いて、アップデートの不調をユーザーなどに報せる。そして、アップデートが正常に終了し得ないことを把握したユーザーによる、被操作手段に対する操作や、近距離無線での指示信号の送信などのような受付部への手動操作を受けて、第１処理装置１がリセット動作の実行を第２処理装置２に指示する。このような構成では、警報器１００の周囲の状況などからユーザーが適切と考えるタイミングで、第２処理装置２にリセット動作を実行させることができる。

【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】

１００ 警報器
１ 第１処理装置
１ａ 計時手段
１ｂ 記憶手段
１０ 警報部
１２ 検知部
１３ 報知部
２ 第２処理装置
２ａ 計時手段
２ｂ 記憶手段
２０ 通信部
２２ 送受信部
３ 電源部
４ 記憶領域
Ａ１ 第１記憶領域
Ａ２ 第２記憶領域
Ｅ 外部機器
Ｓ 電源スイッチ

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】