特許 7473576 警報器

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

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

(11)【特許番号】

(24)【登録日】2024-04-15

(45)【発行日】2024-04-23

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

(51)【国際特許分類】

   G08B 29/12 20060101AFI20240416BHJP

   G08B 21/00 20060101ALI20240416BHJP

   G08B 23/00 20060101ALI20240416BHJP

【ＦＩ】

G08B29/12

G08B21/00 Z

G08B23/00 530Z

【請求項の数】 8

(21)【出願番号】P 2022047195

(22)【出願日】2022-03-23

(65)【公開番号】P2023141062

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

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

【早期審査対象出願】

【前置審査】

(73)【特許権者】

【識別番号】000190301

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

(74)【代理人】

【識別番号】110001896

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

(72)【発明者】

【氏名】齋藤 和也

【審査官】山中 実

(56)【参考文献】

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

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

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

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

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

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

Ｇ０８Ｂ ２９／１２

Ｇ０８Ｂ ２１／００

Ｇ０８Ｂ ２３／００

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

【請求項1】

内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の通信を制御する通信部と、
を備え、
前記ソフトウェアは、前記制御部に関する命令及び前記通信部に関する命令を含んでいて、前記警報器の使用開始後に前記通信部を介したアップデートが可能なように内蔵されており、
前記制御部は、前記警報器の電源投入時に、前記報知機能及び前記通信に関する点検動作を行うように構成されており、
前記制御部は、前記アップデートの終了後に、前記アップデートの内容に応じて、前記点検動作に含まれる点検の一部又は全部を行うように構成され、且つ、前記アップデートが前記通信に関するアップデートであるときは、前記アップデートの終了後に前記点検動作に含まれる点検の全部を含む点検動作を行わないように構成されている、警報器。

【請求項2】

内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、
外部機器との間の通信を制御する通信部と、
を備え、
前記ソフトウェアは、前記警報器の使用開始後に前記通信部を介したアップデートが可能なように内蔵されており、
前記制御部は、前記警報器の電源投入時に、前記報知機能に関する点検動作を行うように構成されており、
前記報知機能に関する点検動作には、前記報知機能に関する点検及び前記通信に関わる点検が含まれており、
前記制御部は、前記アップデートが前記報知機能に関するアップデートであるときは、前記アップデートの終了後に前記報知機能に関する点検を含む点検動作を行い、前記アップデートが前記通信に関するアップデートであるときは、前記アップデートの終了後に前記通信に関わる点検を含む点検動作を行わないように構成されている、警報器。

【請求項3】

前記アップデートが前記通信に関するアップデートか否かを示す情報を記憶する記憶手段をさらに備え、
前記制御部は、前記通信に関わる点検を含む点検動作を行うか否かを前記情報に基づいて判断するように構成されている、請求項２記載の警報器。

【請求項4】

前記制御部は、前記アップデートが前記報知機能に関するアップデートであるときは、前記アップデートの終了後に前記報知機能に関する点検を含む点検動作を行うように構成されている、請求項１記載の警報器。

【請求項5】

前記制御部は、前記通信部によって受信される前記アップデートに関する情報に含まれる識別符号に基づいて、前記アップデートが前記通信に関するアップデートか否かを判断するように構成されている、請求項１～４のいずれか１項に記載の警報器。

【請求項6】

前記制御部は、前記アップデート前の前記ソフトウェアと前記アップデート後の前記ソフトウェアとを比較して、前記アップデートが前記通信に関するアップデートか否かを判断するように構成されている、請求項１～４のいずれか１項に記載の警報器。

【請求項7】

前記制御部は、さらに、
前記電源投入時に前記警報器のリセット動作を行い、
前記リセット動作を前記アップデートの終了後に行うか否かの判断を前記アップデートの内容に応じて行い、
前記判断の結果に応じて前記アップデートの終了後に前記リセット動作の一部又は全部を行う
ように構成されている、請求項１～６のいずれか１項に記載の警報器。

【請求項8】

前記制御部は、前記アップデートが前記通信に関するアップデートであるときは、前記アップデートの終了後に前記リセット動作の一部又は全部を行うように構成されている、請求項７記載の警報器。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【特許文献】

【0004】

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

【発明の概要】

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

【0005】

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

【0006】

そのため、通信機能を有する警報器は、例えば法規の変更や技術の伸展に追随すべく、また、警報器に対する新たな脅威から警報器の機能を保護すべく、警報器の使用開始後においても制御方式や制御仕様を適宜更新することが求められる。そして、適切に制御方式などが更新されない場合は、例えば法規の改正に対応できず、警報器自体が動作可能であるにも関わらずその警報器を実質的に使用できなくなくなったり、通信のセキュリティを脅かす悪意のある技術の脅威に警報器が晒されたりすることにもなり得る。しかしながら、警報器の特性上、制御方式などの更新時に本質的機能である報知機能が機能しない期間が必要以上にあるのは好ましくない。

【0007】

本発明は、上記問題に鑑みてなされたもので、本質的機能を無暗に停止することなく制御方式などを適切に更新することができる警報器を提供することを目的とする。

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

【0008】

本発明の警報器は、内蔵するソフトウェアに含まれる命令に従って動作する警報器であって、前記警報器は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する制御部と、外部機器との間の通信を制御する通信部と、を備え、前記ソフトウェアは、前記警報器の使用開始後に前記通信部を介したアップデートが可能なように内蔵されており、前記制御部は、前記警報器の電源投入時に、前記報知機能に関する点検動作を行うように構成されており、前記制御部は、前記アップデートが前記通信に関するアップデートであるときは、前記アップデートの終了後に前記点検動作を行わないように構成されている、警報器。

【0009】

本発明の警報器は、前記アップデートが前記通信に関するアップデートか否かを示す情報を記憶する記憶手段をさらに備えていてもよく、前記制御部は、前記点検動作を行うか否かを前記情報に基づいて判断するように構成されていてもよい。

【0010】

前記制御部は、前記アップデートが前記報知機能に関するアップデートであるときは、前記アップデートの終了後に前記点検動作を行うように構成されていてもよい。

【0011】

前記制御部は、前記通信部によって受信される前記アップデートに関する情報に含まれる識別符号に基づいて、前記アップデートが前記通信に関するアップデートか否かを判断するように構成されていてもよい。

【0012】

前記制御部は、前記アップデート前の前記ソフトウェアと前記アップデート後の前記ソフトウェアとを比較して、前記アップデートが前記通信に関するアップデートか否かを判断するように構成されていてもよい。

【0013】

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

【発明の効果】

【0014】

本発明によれば、警報器の報知機能に影響を与えないようにしながら、本質的機能を無暗に停止することなく制御方式などを適切に更新することができる警報器を提供することができる。

【図面の簡単な説明】

【0015】

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

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

【図3A】本発明の一実施形態の警報器における動作の一例を示すフローチャートである。

【図3B】本発明の一実施形態の警報器における動作の他の例を示すフローチャートである。

【図4】本発明の一実施形態の警報器における動作のさらに他の例を示すフローチャートである。

【図5】本発明の一実施形態の警報器に送られるアップデート後のソフトウェアを含むデータフレームの一例を示す模式図である。

【図6A】本発明の一実施形態の警報器におけるアップデート種別の判断方法の一例を示す模式図である。

【図6B】本発明の一実施形態の警報器におけるアップデート種別の判断方法の他の例を示す模式図である。

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

【図8】本発明の一実施形態の警報器における動作のさらに他の例を示すフローチャートである。

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

そして、本実施形態の警報器１００では、ソフトウェアＳＷのアップデートの実行に伴ってそのアップデート後に行う動作を、例えば電源投入時の初期動作と同じ内容で行うのではなく、現に実行されたアップデートの後に行う動作として相応しい内容、例えば過剰でない内容で行うように、制御部１０及び／又は通信部２０が構成されている。そのため、警報器１００の本質的機能を無暗に停止することなく、ソフトウェアＳＷに含まれる一連の命令で規定される制御方式などを適宜に更新することができる。この実施形態の警報器の構成及び作用が、以下に詳細に説明される。

【0024】

＜制御部の構成＞
図１の例において制御部１０は、検知部１２と、報知部１３と、前述した処理装置１及びその周辺回路（図示せず）と、を備えている。処理装置１は、前述したように制御部１０と通信部２０との間で共有されている。

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

＜通信部の構成＞
通信部２０は、前述した制御部１０との間で共有する処理装置１及びその周辺回路（図示せず）と、送受信部２２とを備えている。通信部２０が無線によって外部機器Ｅとの間で信号の送受信を行う場合には、送受信部２２はアンテナ２２ａを備え得る。

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

本実施形態では、通信部２０は、前述したように、外部機器Ｅとの間で無線によって信号の送受信を行ってもよい。従って、ソフトウェアＳＷのアップデートは、外部機器Ｅと通信部２０との無線通信に基づいて行われてもよく、その場合、外部機器Ｅからアップデート後のソフトウェアＳＷが供給される。すなわち、ソフトウェアＳＷのアップデートは、所謂「ＯＴＡ（Over-The-Air）アップデート」であってもよく、前述したようにソフトウェアＳＷがファームウェアである場合は、「ファームウェアＯＴＡ」であってもよい。その場合、通信ケーブルのような物理的な回線を警報器１００と外部機器Ｅとの間に設けることなく、例えば、遠隔地からでもソフトウェアＳＷをアップデートすることができる。従って、例えば改定後の法規に従った周囲環境の監視及び警報の発報や、改定後の通信規格に沿ったセキュリティレベルの高い通信を、容易に警報器１００に行わせることができる。

【0040】

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

【0041】

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

【0042】

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

【0043】

＜ソフトウェアのアップデート後の動作＞
図３Ａには、ソフトウェアＳＷ（図１参照）のアップデートＰ３を含む、本実施形態の警報器１００における電源投入からの基本的な動作の一例を示すフローチャートが示されている。図３Ａに示されるように、本実施形態の警報器１００では、例えば電源スイッチＳ（図１参照）のオン操作や、電源プラグ（図示せず）のコンセントへの挿入によって警報器１００の内部回路に電力が供給されると（ステップＳ１）、制御部１０（図１参照）による点検（初期点検）Ｐ０が実行される（ステップＳ２）。

【0044】

点検Ｐ０では、警報器１００における周囲環境の監視から監視結果の報知に至る報知機能に関わるハードウェアの点検、さらに、外部機器Ｅ（図１参照）との通信に関わるハードウェアの点検が実施される。例えば、制御部１０では、処理装置１（図１参照）が、検知部１２や報知部１３（図１参照）に点検用の信号を送信し、検知部１２や報知部１３から適切な応答があるか否かを判断し、報知部１３などを動作させることによってその判断結果をユーザーなどに知らせる。このように本実施形態の警報器１００では、制御部１０は、警報器１００の電源投入時に、警報器１００の報知機能に関する点検動作を行うように構成されている。

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

１００、１０１ 警報器
１ 処理装置（半導体装置）
１１ 記憶手段
１ａ 第１処理装置
１ｂ 記憶手段
１０ 制御部
１２ 検知部
１３ 報知部
２ａ 第２処理装置
２ｂ 記憶手段
２ｃ 計時手段
２０ 通信部
２１ 計時手段
２２ 送受信部
４ 記憶領域
５ 識別符号
Ｅ 外部機器
Ｐ０、Ｐ４ 点検
Ｐ１、Ｐ２ リセット動作
Ｐ３ アップデート
ＳＷ、ＳＷ１、ＳＷ２ ソフトウェア
ＳＷＢ アップデート前のソフトウェア
ＳＷＡ アップデート後のソフトウェア

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】