特許 7399309 障害予兆検出システム、障害予兆検出方法、及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2023-12-07

(45)【発行日】2023-12-15

(54)【発明の名称】障害予兆検出システム、障害予兆検出方法、及びプログラム

(51)【国際特許分類】

   H04Q 9/00 20060101AFI20231208BHJP

   G06F 11/30 20060101ALI20231208BHJP

【ＦＩ】

H04Q9/00 311K

G06F11/30 158

G06F11/30 140D

【請求項の数】 14

(21)【出願番号】P 2022555042

(86)(22)【出願日】2020-10-07

(86)【国際出願番号】 JP2020038061

(87)【国際公開番号】W WO2022074777

(87)【国際公開日】2022-04-14

【審査請求日】2022-11-18

(73)【特許権者】

【識別番号】000006013

【氏名又は名称】三菱電機株式会社

(74)【代理人】

【識別番号】100095407

【弁理士】

【氏名又は名称】木村 満

(74)【代理人】

【識別番号】100131152

【弁理士】

【氏名又は名称】八島 耕司

(74)【代理人】

【識別番号】100147924

【弁理士】

【氏名又は名称】美恵 英樹

(74)【代理人】

【識別番号】100148149

【弁理士】

【氏名又は名称】渡邉 幸男

(74)【代理人】

【識別番号】100181618

【弁理士】

【氏名又は名称】宮脇 良平

(74)【代理人】

【識別番号】100174388

【弁理士】

【氏名又は名称】龍竹 史朗

(72)【発明者】

【氏名】中村 達希

(72)【発明者】

【氏名】古賀 陽一郎

【審査官】前田 健人

(56)【参考文献】

【文献】韓国公開特許第１０－２０１６－０１４６３８９（ＫＲ，Ａ）

【文献】米国特許出願公開第２０１８／０２１１５１８（ＵＳ，Ａ１）

【文献】中国特許出願公開第１１０８９２２０６（ＣＮ，Ａ）

【文献】米国特許出願公開第２０２０／０１５９２０３（ＵＳ，Ａ１）

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

Ｈ０４Ｑ ９／００

Ｇ０６Ｆ １１／３０

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

【請求項1】

複数のＩｏＴデバイスを備えた施設で構成されるフィールド拠点での利用者の満足度を示すサービスレベルの障害発生の予兆を検出する障害予兆検出システムであって、
各ＩｏＴデバイスのフィールドデータを収集して格納する第１格納部と、
前記施設の利用者が感じるサービスレベルの障害の報告に基づいて、前記フィールドデータの特徴データを求める特徴抽出部と、
前記障害発生時の前記フィールドデータの特徴データと利用者が感じるサービスレベルの障害内容とを関連付けた障害情報を蓄積する第２格納部と、
前記第１格納部に格納されているフィールドデータを監視し、前記第２格納部に蓄積されている特徴データに合致する特徴データを検出したときに、その特徴データに関連付けられたサービスレベルの障害が発生する予兆を検出したことを出力する障害予兆検出部と、
を備えた障害予兆検出システム。

【請求項2】

前記特徴抽出部は、前記施設の利用者が感じるサービスレベルの障害の報告に基づいて、前記第１格納部に格納された前記フィールドデータから前記サービスレベルの障害が発生したときのフィールドデータを特定し、そのフィールドデータの変動を特徴として特定し、特徴を示す特徴データを抽出することで前記フィールドデータの特徴データを求める、請求項１に記載の障害予兆検出システム。

【請求項3】

前記フィールドデータの特徴は、前記特定したフィールドデータにおける時間上あるいは空間上の変動パターンである、請求項２に記載の障害予兆検出システム。

【請求項4】

前記ＩｏＴデバイスは、マイクロフォンから収集した利用者の音声をテキスト化して、前記フィールドデータを生成する、請求項１から３のいずれか１項に記載の障害予兆検出システム。

【請求項5】

前記フィールド拠点とは別箇所に、前記フィールド拠点とネットワークを介して接続されるセンター拠点を設置しており、
前記センター拠点内に、前記第１格納部、前記特徴抽出部、前記第２格納部、及び前記障害予兆検出部を備えている、請求項１から４のいずれか１項に記載の障害予兆検出システム。

【請求項6】

利用者から送られてきた障害に関する報告の内容に、障害のレベル、障害の分類、障害の原因の少なくとも１つを含む障害情報を付加して、前記第２格納部に登録する手段を備える、請求項１から５のいずれか１項に記載の障害予兆検出システム。

【請求項7】

前記障害予兆検出部は、前記第１格納部に格納されたフィールドデータを監視し、基準を超える変動を検出した場合は、障害発生の予兆を検出したことを出力する、請求項１から６のいずれか１項に記載の障害予兆検出システム。

【請求項8】

前記障害予兆検出部は、あるフィールド拠点で報告された障害の内容と、その報告の時間帯に検出したフィールドデータの特徴データを、別のフィールド拠点に適用して、同様の特徴データが得られるフィールドデータの有無を判別し、障害予兆がないかを確認する、請求項１から７のいずれか１項に記載の障害予兆検出システム。

【請求項9】

前記障害予兆検出部は、報告があった際のフィールドデータの特徴データと現在のフィールドデータの特徴データとの類似度を求め、類似度に基づいて、発生する可能性が高まっている障害をリアルタイムに報知する、請求項１から８のいずれか１項に記載の障害予兆検出システム。

【請求項10】

前記障害予兆検出部は、報告があった際のフィールドデータの特徴データと現在のフィールドデータの特徴データとの類似度を求め、類似度に基づいて、発生する可能性が高まっている障害を発生の可能性の順にリストアップして報知する、請求項１から９のいずれか１項に記載の障害予兆検出システム。

【請求項11】

前記障害予兆検出部は、発生する可能性が高まっている障害をリストアップする際、予め登録された障害のレベル或いは障害の分類或いは障害の原因の観点から、リストする障害或いは項目をソートあるいは分類する、請求項１０に記載の障害予兆検出システム。

【請求項12】

前記フィールド拠点とは別箇所に設置され、前記フィールド拠点とネットワークを介して接続されるセンター拠点はデータ収集部を備えており、
前記データ収集部は、複数の前記フィールド拠点からフィールドデータを収集することに加えて、外部データソースから外部データを収集する、請求項５から１０のいずれか１項に記載の障害予兆検出システム。

【請求項13】

複数のＩｏＴデバイスを備えた施設で構成されるフィールド拠点での利用者の満足度を示すサービスレベルの障害発生の予兆を検出する障害予兆検出方法であって、
各ＩｏＴデバイスからフィールドデータを収集して格納し、
前記施設の利用者が感じるサービスレベルの障害の報告に基づいて、前記フィールドデータの特徴データを求め、
前記障害発生時の前記フィールドデータの特徴データと利用者が感じるサービスレベルの障害内容とを関連付けた障害情報を蓄積し、
格納されているフィールドデータを監視し、蓄積されている特徴データに合致する特徴データを検出したときに、その特徴データに関連付けられたサービスレベルの障害が発生する予兆を検出したことを出力する、
障害予兆検出方法。

【請求項14】

複数のＩｏＴデバイスを備えた施設で構成されるフィールド拠点での利用者の満足度を示すサービスレベルの障害発生の予兆を検出するコンピュータに、
各ＩｏＴデバイスからフィールドデータを収集して格納する処理、
前記施設の利用者が感じるサービスレベルの障害の報告に基づいて、前記フィールドデータの特徴データを求める処理、
前記障害発生時の前記フィールドデータの特徴データと利用者が感じるサービスレベルの障害内容とを関連付けた障害情報を蓄積する処理、
格納されているフィールドデータを監視し、蓄積されている特徴データに合致する特徴データを検出したときに、その特徴データに関連付けられたサービスレベルの障害が発生する予兆を検出したことを出力する処理、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、障害予兆検出システム、障害予兆検出方法、及びプログラムに関する。

【背景技術】

【0002】

店舗、工場等の施設に、空調装置、照明装置、各種センサ等の多数のＩｏＴデバイスを設置し、これらのＩｏＴデバイスで収集したデータを用いて、利用者が快適に過ごせるように複数の装置を制御するサービスが存在する。

【0003】

この種のサービスにおいて、サービスレベルの障害が発生することがある。サービスレベルの障害とは、利用者が、施設を利用する際に、不快に感じ、不満を感じ、或いは、不便であると感じる等、施設を利用することに関して何らかの不足を感じることを言う。具体例として、次のようなものがサービスレベルの障害と見做される。利用者が、ｉ）自分のいるところが暑い、寒い、或いは、空気が淀んでいる、と感じること、ｉｉ）周囲がやかましくて集中できないと感じること、ｉｉｉ）エレベータを待っているのにいつまでも来ないと感じること、ｉｖ）照明が当たらずに薄暗いと感じること。サービスレベルの障害が発生することにより、施設の管理者に問い合わせ、苦情等が発生する可能性がある。

【0004】

こうしたサービスレベルの障害の発生を抑えるためには、障害発生の予兆を検出し、その原因と対策方法を特定し、障害が発生する前に対策を実施することが望ましい。

【0005】

上述した検出技術に関連して、特許文献１には、利用者が製品の不具合を通知したときに、原因と解決手段とを特定するシステムが提案されている。このシステムは、製品の不具合を知らせるスイッチを有し、利用者によるスイッチの押下を契機として、その直前の動作ログデータと既知の不具合原因のデータベースとを比較し、原因と対処内容を利用者に提示する。

【先行技術文献】

【特許文献】

【0006】

【文献】特開２０２０－１４０３５号公報

【発明の概要】

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

【0007】

特許文献１に開示されているシステムは、システム及び施設の利用者とシステムのオペレータとが同一である場合を想定している。このため、利用者とオペレータとが異なる施設に適用することは困難である。

【0008】

また、特許文献１に開示されたシステムは、製品の不具合の原因と対処内容を特定して、表示するシステムであり、サービスレベルの障害に関するものではない。製品が正常であっても、サービスレベルの障害は発生しうる。従って、特許文献１に開示されたシステムは、サービスレベルの障害の発生を防げない。

【0009】

さらに、引用文献１に開示されたシステムは、製品に障害が発生したことを利用者が認識してスイッチを操作することを契機として、原因と対策を特定して表示する。即ち、引用文献１に開示されたシステムは、障害が発生してから機能するシステムであり、障害発生の予兆を検出することはできない。

【0010】

本開示は、上記実情に鑑みてなされたものであり、サービスレベルの障害の発生の予兆の検出を可能とすることを目的とする。

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

【0011】

本開示に係る障害予兆検出システムは、複数のＩｏＴデバイスを備えた施設で構成されるフィールド拠点での利用者の満足度を示すサービスレベルの障害発生の予兆を検出する。障害予兆検出システムは、各ＩｏＴデバイスのフィールドデータを収集して格納する第１格納部と、施設の利用者が感じるサービスレベルの障害の報告に基づいて、フィールドデータの特徴データを求める特徴抽出部と、障害発生時のフィールドデータの特徴データと利用者が感じるサービスレベルの障害内容とを関連付けた障害情報を蓄積する第２格納部と、第１格納部に格納されているフィールドデータを監視し、第２格納部に蓄積されている特徴データに一致又は類似する、即ち、合致する特徴データを検出したときに、その特徴データに関連付けられたサービスレベルの障害が発生する予兆を検出したことを出力する障害予兆検出部と、を備える。

【発明の効果】

【0012】

この障害予兆検出システムによると、障害予兆検出部が、第１の格納部に格納されているフィールドデータと、同一又は類似の特徴を有するフィールドデータを第２格納部に検出したときに、障害が発生する予兆を検出したことを出力する。これにより、サービスレベルの障害の発生の予兆の検出が可能となる。

【図面の簡単な説明】

【0013】

【図1】本開示の実施の形態に係る障害予兆検出システムの概略構成を示す図

【図2】図１に示すフィールド拠点の構成を示すブロック図

【図3】図１に示すフィールドデータのフォーマットを示す図

【図4】（ａ）は、図１に示す障害予兆検出システムにおいて、エアコン、温度センサ等のＩｏＴデバイスが生成した温度データを含むフィールドデータの例を示す図、（ｂ）は、図１に示す障害予兆検出システムにおいて、音声解析機能を有するＩｏＴデバイスが生成した会話情報を含むフィールドデータの例を示す図

【図5】図１に示す障害情報ＤＢに蓄積される障害情報の構成を例示する図

【図6】図１に示すセンター拠点のハードウエア構成の一例を示す図

【図7】実施の形態に係る障害予兆検出システムのユースケースを示す図

【図8】図１に示すセンター拠点に障害の発生が報告された際の手順の一例を示す図

【図9】（ａ）は、図１に示す障害予兆検出システムにおいて、問い合わせ受付部が登録する障害情報の例を示す図、（ｂ）は、図１に示す障害予兆検出システムにおいて、障害管理部が登録する障害の分析例を示す図

【図10】報告された障害を分析し、処置する際の手順の一例を示す図

【図11】障害予兆検出部により障害の予兆を検出する際の手順の一例を示す図

【図12】施設の運用者が、障害予兆検出部が提示した障害兆候に対して事前対応する際の手順の一例を示す図

【図13】運用者が障害兆候を確認し、分析する際の表示部の画面構成の一例を示す図

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

【0014】

以下、本開示の実施の形態にかかる障害予兆検出システムと障害予兆検出方法を図面を参照して説明する。なお、以下の説明において、同様の構成要素については同一の符号を付す。

【0015】

本実施の形態にかかる障害予兆検出システムは、施設のサービスレベルの障害の発生の予兆を、その施設に設置されている複数のＩｏＴデバイスから収集したフィールドデータを用いて検出する。障害予兆検出システムは、予兆を検出すると、その原因と対策方向を施設の管理者に報知する。なお、ＩｏＴデバイスとは、インターネットに接続されている機器、装置、システム、センサなどのデバイスを言う。また、施設のサービスレベルとは、施設における、全体的なサービスの段階あるいは施設の利用者の満足度を意味する。さらに、サービスレベルの障害とは、利用者が不快、不満、不便、不安、不足、不都合などの否定的印象を感じる事態をいう。具体例を示すと、サービルレベルの障害が発生しているとは、利用者が、ｉ）自分がいるところだけ暑い、寒い、或いは、空気が淀んでいる、と感じ、ｉｉ）周囲がやかましくて集中できないと感じ、ｉｉｉ）エレベータを待っているのにいつまでも来ないと感じ、ｉｖ）照明が当たらずに薄暗いと感じる、等の事態が発生することを意味する。

【0016】

（障害予兆検出システム１００全体の構成）
図１は、本実施の形態に係る障害予兆検出システム１００の概略構成を示す。
障害予兆検出システム１００は、ＩｏＴデバイスを運用及び管理するシステムの一種である。障害予兆検出システム１００は、一つ又は複数のフィールド拠点１０１と、単一のセンター拠点１０２と、外部データソース１０３と、を備える。なお、図１では、フィールド拠点１０１を１つのみ図示している。

【0017】

（フィールド拠点１０１の構成）
フィールド拠点１０１は、典型的には、家屋、ビル、工場、商業施設、運動施設等の施設と、この施設に設置された複数のＩｏＴデバイス９を備えている。これらＩｏＴデバイス９は、組み込まれたセンサなどの計測機器を介してフィールドデータを生成する機能を有する。複数のＩｏＴデバイス９が協働して、全体として、施設の利用者４２が快適に過ごすためのサービスを提供する。この全体的なサービスの段階あるいは利用者４２の満足度が前述のサービスレベルである。サービスレベルを低下させるような障害、すなわち、利用者４２が不快、不満、不便、不安、不足、不都合などの否定的印象を感じるという事態が、サービスレベルの障害に相当する。

【0018】

施設内には、ＩｏＴデバイス９に加え、ＩｏＴデバイス９が生成するフィールドデータを、通信ネットワーク（以下、ネットワーク）３０を介してセンター拠点１０２のデータ収集部７に送信するモニタリング装置１０が設置されている。

【0019】

ＩｏＴデバイス９は、例えば、照明装置、エレベータ装置、エアコン装置（以下、単にエアコン）、監視カメラ装置、温度センサ、湿度センサ、騒音センサ、マイクロフォン等を含む。これら複数のＩｏＴデバイス９の集合体は、施設内の環境を制御するＩｏＴ制御システム１１を構成している。

【0020】

各ＩｏＴデバイス９は、図２に示すように、フィールドデータを生成し、モニタリング装置１０へ送信するためのフィールドネットワーク通信機能又はエリアネットワーク通信機能を備えている。フィールドネットワーク通信機能の実体は、Ｅｔｈｅｒｎｅｔ、ＣＡＮ（Controller Area Network)、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、ＢＬＥ（Bluetooth Low Energy）、ＺｉｇＢｅｅ等の様々な通信機能により実現される。

【0021】

具体例で説明すると、図２に例示するように、照明装置９ａは、フィールドデータとして、例えば、光源に流れる電流の大きさを示す電流データ、光源への印加電圧を示す電圧データ、予め定められた位置の照度を示す照度データ等を出力する。また、エレベータ９ｂは、フィールドデータとして、例えば、運転状況を示す運転データ、かごの速度を示す速度データ、かごの振動の大きさを示す振動データ、駆動モータに流れる電流の大きさを示す電流データ、駆動モータに印加される電圧の大きさを示す電圧データ等を出力する。なお、各ＩｏＴデバイス９がどのようなフィールドデータを出力するかは、任意である。
なお、どのようなＩｏＴデバイス９をどのような場所に設置するかは、任意である。

【0022】

各フィールドデータは、図３に例示するように、日時、フィールド拠点ＩＤ、デバイスＩＤ、換算値、単位、値の意味付け、等のデータ項目を有する。

【0023】

「日時」は、そのデータが生成された日時であり、典型的にはタイムスタンプである。「フィールド拠点ＩＤ」は、ＩｏＴデバイス９が設置されているフィールド拠点１０１の一意な識別子である。
「デバイスＩＤ」は、このフィールドデータを生成したＩｏＴデバイス９の一意な識別子である。「デバイスＩＤ」は、そのＩＤを調査することでＩｏＴデバイス９の種類、例えば、エアコン、照明、監視カメラ等の別、形式名、製造番号が分かるように作成される。
「換算値」は、センサが計測したアナログ値をデジタル変換した後に、同データを特定の単位に換算した数値であり、例えば、電流の場合は単位「アンペア」に換算した値、電圧の場合は単位「ボルト」に換算した値、温度の場合は単位「摂氏」に換算した値、音量の場合は単位「デシベル」に換算した値である。
「単位」は、換算値の単位であり、アンペア「Ａ」、ボルト「Ｖ」、摂氏「℃」、デシベル「ｄＢ」等である。
「値の意味付け」は、そのデータが持つ性質を、設置場所、計測方法などを組み合わせて表現する。なお、フィールドデータは、ＩｏＴデバイス９の施設内の設置場所、設置年月日、管理担当部署等の他の項目を含んでもよい。

【0024】

フィールドデータの具体例を図４（ａ）、（ｂ）に示す。
図４（ａ）に示すフィールドデータは、エアコン、温度センサ等のＩｏＴデバイス９が生成した温度データの一例である。また、図４（ｂ）に示すフィールドデータは、音声解析機能を持つデバイスが生成した会話データの一例である。これらフィールドデータは、Ｗｅｂ ＡＰＩを介したデータの送受信で広く使用されるＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式で記述している。ただし、形式は任意である。本実施の形態では、ＸＭＬ形式などの機械的な解析が容易な形式であってもよい。

【0025】

図４（ａ）に示すフィールドデータの４行目の”ｄｅｖｉｃｅ＿ｉｄ”において、ＤＶＥはＤｅｖｉｃｅ（デバイス）の略称、ＡＣはＡｉｒ Ｃｏｎｄｉｔｉｏｎｅｒ（エアコン）の略称、ＺＲ２３２Ｃはエアコンの形式名、００１４６２はエアコンの製造番号である。

【0026】

また、図４（ｂ）に示すフィールドデータの”ｄｅｖｉｃｅ＿ｉｄ”において、ＶＲはＶｏｉｃｅ Ｒｅｃｏｇｎｉｔｉｏｎの略称、ＶＲ０１Ｒは音声認識デバイスの形式名、０００２２は音声認識デバイスの製造番号である。また、”ｖａｌｕｅ”の”なんかこの辺り蒸し暑いよね”は、音声を認識して得られたテキストデータである。

【0027】

図４（ａ）、（ｂ）では、データをハイフンで繋げてデバイスＩＤとしているが、この形式に縛られるものではない。デバイスＩＤの形式は任意である。例えば、ＵＵＩＤ（Universally Unique Identifier）ｖ５を用いて、デバイスの種類、形式名、製造番号をハッシュ化する方法が考えられる。

【0028】

図１及び図２に示すＩｏＴデバイス９は、稼働中、連続的、定期的、或いは繰り返して、各種データを取得し内部メモリに記憶及び蓄積する。ＩｏＴデバイス９は、蓄積しているデータに基づいて、予め定められた周期でフィールドデータを生成し、モニタリング装置１０に送信する。典型的には、各ＩｏＴデバイス９が、フィールドデータを生成及び送信する頻度は、１台あたり１日１回である。フィールドデータの生成と送信の頻度は、より少ない頻度あるいは、より大きい頻度のいずれにも変更できる。

【0029】

モニタリング装置１０は、例えば、エッジサーバと呼ばれるサーバ装置から構成される。図２に示すように、モニタリング装置１０は、ＩｏＴデバイス９からフィールドデータを受信するためのフィールドネットワーク通信機能１０ａと、受信したフィールドデータをセンター拠点１０２に送信するためのインターネット通信機能１０ｂを備える。インターネット通信機能は、Ｅｔｈｅｒｎｅｔ、光ファイバ、携帯回線網（３Ｇ／４Ｇ／５Ｇ）等、様々な通信規格に準拠した通信装置により実現される。本実施の形態では、モニタリング装置１０は、インターネット、ＶＰＮ（仮想プライベートネットワーク）等のネットワーク３０によりセンター拠点１０２に接続されている。

【0030】

フィールド拠点１０１の管理者４１及び利用者４２は、自己の通信端末３７、３８を用いて、インターネット等の通信ネットワーク（以下、ネットワーク）３２を介して、センター拠点１０２の問い合わせ受け付け部８に情報を送信可能である。管理者４１及び利用者４２は、通信端末３７、３８を用いて、問い合わせ受け付け部８に、サービスレベルの障害の内容を、テキスト、音声等で登録できる。

【0031】

（センター拠点１０２の構成）
図１に示すセンター拠点１０２は、サービスレベルの障害の発生の予兆を検出する障害予兆検出部１と、フィールドデータを格納するフィールドデータデータベース（以下、ＤＢ）２と、過去に実際に発生した障害の特徴データと障害情報の組みを蓄積する障害情報ＤＢ３と、データを表示する表示部４と、障害の発生の予兆を検出する障害検出部５と、障害情報ＤＢ３を管理する障害管理部６と、フィールド拠点１０１及び外部データソース１０３からデータを収集するデータ収集部７と、フィールド拠点１０１から問い合わせを受け付ける問い合わせ受け付け部８と、を備える。

【0032】

フィールドデータＤＢ２は、フィールド拠点１０１から送信されてきたフィールドデータを種類毎に時系列で記録及び格納する。フィールドデータＤＢ２は、第１格納部の一例である。

【0033】

障害検出部５は、管理者４１又は利用者４２からのサービスレベルの障害に関する問い合わせの内容に基づいて、フィールドデータＤＢ２に格納されたフィールドデータを照会して、障害が発生したときのフィールドデータを特定し、そのフィールドデータの変動を特徴として特定し、特徴を示す特徴データを抽出する。なお、変動とは、例えば、固定又は可変の基準値からの変動、前回取得したフィールドデータの値からの変動、移動平均値からの変動等の、予め設定された変動を意味する。また、変動は、変動の符号付きの値でも絶対値でもよく、さらに、変動の方向、変動の傾向などでもよい。また、時間軸上或いは空間上の変動パターンなどでもよい。障害検出部５は、フィールドデータと抽出した特徴データとを互いに対応付けて組にして、障害情報ＤＢ３に登録する。障害検出部５は、特徴抽出部の一例である。

【0034】

障害情報ＤＢ３は、障害検出部５が特定した障害発生時のフィールドデータと特徴データと利用者４２が感じた障害内容等を含む障害情報を蓄積する。
障害情報は、図５に例示するように、障害番号、日時、フィールド拠点ＩＤ、障害の内容、障害のレベル、障害の分類、障害の原因、障害の処置、のデータ項目を含む。障害情報は、他データ項目を含んでも良い。なお、前述のように、障害情報は、問い合わせを受けたとき、換言すると、障害が発生時のフィールドデータとその特徴データと対応付けられている。障害情報ＤＢ３は、第２格納部の一例である。

【0035】

「障害番号」は、障害情報を一意に識別するための英数字記号等を含む識別子であり、問い合わせ受け付け部８により自動的に採番される。
「日時」はその障害情報が問い合わせ受け付け部８に登録された日時であり、典型的にはＩＳＯ ８６０１形式に従う。
「フィールド拠点ＩＤ」は、報告が行われたフィールド拠点１０１の一意な識別子であり、フィールドデータのフィールド拠点ＩＤと同じものである。
「障害の内容」は、障害の発生状況及び内容についての、自然言語で記述された文書である。例えば、管理者４１或いは利用者４２が通信端末３７，３８が入力したテキスト列、或いは、管理者４１或いは利用者４２の音声を音声認識して得られたテキスト列である。
「障害のレベル」は、障害の緊急性の程度を幾つかの段階で表現したもので、障害の内容に応じて割り振る。「障害のレベル」は、選択式であり、選択肢は適時、追加、変更、削除できる。
「障害の分類」は、騒音、蒸し暑さ、光量、待ち時間など障害の種類を、障害の内容に応じて割り振る。「障害の分類」は、選択式であり、選択肢は適時、追加、変更、削除できる。
「障害の原因」は、障害が発生した要因を表記したものであり、障害の調査後に登録される、自然言語で記述された文書である。
「障害の処置」は、障害を解決するために実施した対策を、障害の処置後に登録される、自然言語で記述された文書である。

【0036】

「障害番号」は、問い合わせ受け付け部８により自動的に採番される。「日時」、「フィールド拠点ＩＤ」、「障害の内容」については、利用者４２、管理者４１，運用者４３のいずれが登録してもよい。「障害のレベル」、「障害の分類」、「障害の原因」、「障害の処置」、は、運用者により、登録される。ただし、これらに限定されるものではない。

【0037】

障害情報のうち、「障害番号」、「日時」、「フィールド拠点ＩＤ」、及び「障害の内容」は、管理者４１の通信端末３７又は利用者４２の通信端末３８から障害の発生が報知されたときに、問い合わせ受け付け部８により登録される。一方、「障害のレベル」、「障害の分類」、「障害の原因」、「障害の処置」は、センター拠点１０２の運用者４３により障害管理部６により登録される。なお、必要に応じて、運用者４３が障害管理部６を介してデータ間の対応付けを調整してもよい。
また、図５に示す、情報の「形式」は一例であり、限定されるものではない。

【0038】

図１に示す障害予兆検出部１は、フィールドデータＤＢ２に格納されたフィールドデータと障害情報ＤＢ３に蓄積された特徴データとから障害発生の予兆を検出する。より具体的に説明すると、障害予兆検出部１は、フィールドデータＤＢ２に格納されたフィールドデータの変動を検出して、フィールドデータの特徴を求める。障害予兆検出部１は、求めた特徴が、障害情報ＤＢ３に蓄積されている特徴データが示す特徴、即ち、実際に障害が報告された時間帯におけるフィールドデータの特徴のいずれかに一致する或いは類似する（以下、まとめて合致と呼ぶ）か否かを基準に基づいて判別する。障害予兆検出部１は、合致する１又は複数の特徴を特定すると、特定した特徴に対応付けられているフィールドデータと障害情報を障害情報ＤＢ３から抽出し、例えば、類似度が高い順に、順位、類似度、障害情報、フィールドデータとを、例えば、リスト化する。具体的に説明すると、障害予兆検出部１は、フィールドデータＤＢ２に格納されたフィールドデータの変動を検出して、フィールドデータの特徴データを求める。障害予兆検出部１は、求めた特徴データと、障害情報ＤＢ３に蓄積されている複数の特徴データそれぞれとの類似度を類似度計算を行って求める。障害予兆検出部１は、類似度が基準より高い特徴データを特定し、特定した特徴データに対応付けられている障害情報とフィールドデータを抽出し、例えば、類似度が高い順にリスト化する。なお、類似度が基準よりも高い特售データが存在しないことは、障害発生の予兆がないことを意味する。また、基準以上の類似度を有する特徴データが複数特定された場合に、予め定められた数の特徴データに絞り込むようにしてもよい。

【0039】

表示部４は、液晶表示装置、エレクトロルミネッセンス表示装置から構成され、障害予兆検出部１に接続され、障害予兆検出部１が抽出した１又は複数の障害情報を予兆として運用者４３に通知する。具体的には、表示部４は、障害予兆検出部１が生成したリストを表示して、予兆を報知する。また、表示部４は、運用者４３の操作に従って、選択された障害情報の詳細、関連する特徴データ、フィールドデータ群等を、例えば、図１３に例示するように表示する。

【0040】

障害管理部６は、運用者４３の操作に従って、障害情報のうちの障害のレベル、障害の分類、障害の原因、障害の処置等の情報を障害情報ＤＢ３に登録する。また、障害管理部６は、運用者４３の操作に従って、登録されている障害情報を編集する。障害管理部６は、運用者４３による障害情報ＤＢ３へのその他の処理を実行してもよい。

【0041】

データ収集部７は、フィールド拠点１０１に設置されたモニタリング装置１０から送信されて来るフィールドデータを受信する。また、データ収集部７は、外部データソース１０３から外部データを収集する。データ収集部７は、受信したフィールドデータ及び収集した外部データを、フィールドデータＤＢ２に格納する。

【0042】

データ収集部７は、典型的には常駐型のデーモンプログラムにより実現される。このデーモンプログラムは、フィールド拠点１０１のモニタリング装置１０が送信してくるフィールドデータを受信するための通信ＡＰＩを備えている。ＡＰＩ（Application program interface）は、一つの機能に特化したプログラムで共有化が可能なもの、または、ソフトウェアの機能を共有する仕組みである。データ収集部７は、収集したフィールドデータをフィールドデータＤＢ２に登録する。

【0043】

障害検出部５、障害管理部６、データ収集部７は、ＷＥＢアプリケーションが実現されており、使用者はブラウザを用いて各部を操作できる。

【0044】

問い合わせ受け付け部８は、利用者４２が施設内で感じたサービスレベルの障害についての問い合わせ、あるいは利用者４２又は管理者４１からの施設の動作不良の問い合わせ、クレーム、連絡等を受け付ける。問い合わせ受け付け部８は、問い合わせに応答し、障害番号を採番し、障害情報ＤＢ３に障害情報として格納する。問い合わせ受け付け部８は、利用者４２又は管理者４１が通信端末３８，３７から送信してきたテキストを障害の内容を示す情報として障害情報ＤＢ３に登録する。問い合わせ受け付け部８は、音声認識機能を備えてもよい。この場合、問い合わせ受け付け部８は、利用者４２又は管理者４１の音声をテキストに変換して、障害の内容を示す情報として障害情報ＤＢ３に登録できる。

【0045】

外部データソース１０３は、施設外のデータソースである。例えば、外部データは、施設周辺の天気予報の情報から取得された天気、気温、湿度といった気象情報、交通情報等を含む。例えば、商業施設では、天気が雨で外気の湿度が高い状態であれば室内の湿度を下げることでユーザ満足度を高めることが可能となる。

【0046】

外部データソース１０３に蓄積される外部データは、管理の対象の施設の種類、地域によって異なり、例えば、寒い地域では積雪量などの情報が蓄積される。ここで、寒い地域では雪、雪雲等の影響で電波が届きにくくなり、データの送受信ができなくなる場合がある。この状況で、積雪によって対象施設である工場に張り巡らせたネットワークで断線が発生した際、工場内のＦＡ機器の状態だけからその原因にたどり着くことは困難となる。この場合に、外部データとして、積雪量に関するデータを取得することにより、断線の原因を把握することが可能となる。

【0047】

さらに、監視対象のフィールド拠点１０１でこれまでに発生した障害と原因によっては、より多くのデータソースを監視することが望ましい場合がある。例えば、クラウドサービスの障害情報を外部データソース１０３にさらに蓄積させることにより、障害の原因がクラウドサービスにあるのか積雪にあるのか、自社が提供しているサービスにあるのかを切り分けることができるようになる。このため、利用者４２からの問い合わせに対するより正確で迅速な対応が可能となる。

【0048】

センター拠点１０２は、データ収集部７と、フィールド拠点１０１のモニタリング装置１０との間に、フィールド拠点１０１からフィールドデータを受信するためのゲートウェイであるデバイスゲートウェイ３３を備える。

【0049】

デバイスゲートウェイ３３は、典型的にはネットワーク３０経由で送られてくる暗号化された通信パケットを受け付ける。デバイスゲートウェイ３３は、受信した通信パケットの暗号を解除した後、平文の通信パケットをデータ収集部７に提供する。

【0050】

さらに、センター拠点１０２は、問い合わせ受け付け部８と、フィールド拠点１０１の管理者４１が使用する通信端末３７及び利用者４２が使用する通信端末３８との間に、アプリケーションゲートウェイ３４を備える。アプリケーションゲートウェイ３４は、通信端末３７，３８と通信する。通信端末３７，３８は、例えば、コンピュータ、スマートホン、タブレット端末などから構成される。

【0051】

問い合わせ受け付け部８は、アプリケーションゲートウェイ３４を介して、サービスレベルの障害に関する問い合わせ或いは苦情を含む情報を受信する。

【0052】

アプリケーションゲートウェイ３４は、典型的にはネットワーク３２を経由して通信端末３７，３８から送られてくる暗号化された通信パケットを受け付け、同通信パケットの暗号化を解除した後、平文の通信パケットを問い合わせ受け付け部８に提供する。

【0053】

上記構成を有するセンター拠点１０２は、ハードウエア的には、例えば、図６に示すように、プロセッサ５１、記憶部５２、表示部５３、入力部５４、通信部５５、補助記憶部５６を備えるコンピュータから構成される。
プロセッサ５１は、記憶部５２に記憶された動作プログラムを実行する。
記憶部５２は、ＲＯＭ（Read Only Memory），ＲＡＭ（Random Access Memory）等を備え、プロセッサ５１が実行するプログラム、実行に必要な固定データ等を記憶する。また、記憶部５２は、プロセッサ５１のワークエリアとして機能する。

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

１ 障害予兆検出部、２ フィールドデータＤＢ、３ 障害情報ＤＢ、４ 表示部、５ 障害検出部、６ 障害管理部、７ データ収集部、８ 問い合わせ受け付け部、９ ＩｏＴデバイス、９ａ 照明装置、１０ モニタリング装置、１０ａ フィールドネットワーク通信機能、１０ｂ インターネット通信機能、３０、３２ 通信ネットワーク、３３ デバイスゲートウェイ、３４ アプリケーションゲートウェイ、３７、３８ 通信端末、４１ 管理者、４２ 利用者、４３ 運用者、５１ プロセッサ、５２ 記憶部、５３ 表示部、５４ 入力部、５５ 通信部、５６ 補助記憶部、１００ 障害予兆検出システム、１０１ フィールド拠点、１０２ センター拠点、１０３ 外部データソース。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】