特許 7529560 故障診断装置、故障診断システム、及び故障診断プログラム

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

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

(11)【特許番号】

(24)【登録日】2024-07-29

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

(54)【発明の名称】故障診断装置、故障診断システム、及び故障診断プログラム

(51)【国際特許分類】

   G05B 23/02 20060101AFI20240730BHJP

   H01M 8/00 20160101ALI20240730BHJP

   H01M 8/04664 20160101ALI20240730BHJP

   H01M 8/04992 20160101ALI20240730BHJP

   H01M 8/04 20160101ALI20240730BHJP

【ＦＩ】

G05B23/02 302Y

H01M8/00 Z

H01M8/04664

H01M8/04992

H01M8/04 Z

【請求項の数】 12

(21)【出願番号】P 2020217846

(22)【出願日】2020-12-25

(65)【公開番号】P2022102849

(43)【公開日】2022-07-07

【審査請求日】2023-05-26

(73)【特許権者】

【識別番号】000220262

【氏名又は名称】東京瓦斯株式会社

(74)【代理人】

【識別番号】110001519

【氏名又は名称】弁理士法人太陽国際特許事務所

(72)【発明者】

【氏名】香田 淳也

(72)【発明者】

【氏名】木村 駿介

(72)【発明者】

【氏名】高須 俊樹

【審査官】田中 友章

(56)【参考文献】

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

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

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

【文献】国際公開第２０１８／１５９１６９（ＷＯ，Ａ１）

【文献】国際公開第２０１８／２３０６４５（ＷＯ，Ａ１）

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

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

Ｇ０５Ｂ ２３／０２

Ｈ０１Ｍ ８／００

Ｈ０１Ｍ ８／０４６６４

Ｈ０１Ｍ ８／０４９９２

Ｈ０１Ｍ ８／０４

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

【請求項1】

燃料電池コージェネレーションシステムが動作の異常を検知した場合に、前記燃料電池コージェネレーションシステムから、前記異常に対応する、前記燃料電池コージェネレーションシステムの動作履歴に関する動作履歴データを取得する取得部と、
過去に得られた動作履歴データ群を、前記燃料電池コージェネレーションシステムの機能部に対応付けて機械学習又は多変量解析することにより生成され、かつ、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を判定する故障診断モデルに対して、前記取得部により取得された動作履歴データ又は当該動作履歴データを加工して得られるデータを入力し、前記故障診断モデルから出力される判定結果を用いて、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を推定する推定部と、
前記故障診断モデルが予め定められた条件を満たす場合に、前記故障診断モデルを再学習することにより新たな故障診断モデルを生成する学習部と、
を備え、
前記予め定められた条件は、前記故障診断モデルの性能が一定水準に到達しないという条件、前記故障診断モデルの性能が時系列的に劣化するという条件、前記故障診断モデルによって故障診断を行ったデータの数が一定値を超えるという条件、及び、前記故障診断モデルによって故障診断を行った期間が一定期間を超えるという条件の少なくとも１つを含む
故障診断装置。

【請求項2】

前記予め定められた条件は、前記故障診断モデルの性能が一定水準に到達しないという条件であり、
前記学習部は、前記故障診断モデルの性能が一定水準に到達しない場合に、故障診断に用いた過去の動作履歴データ群を学習用データとして新たな故障診断モデルを生成し、前記新たな故障診断モデルの汎化性能が一定水準以上である場合に、前記故障診断モデルを、前記新たな故障診断モデルに更新する
請求項１に記載の故障診断装置。

【請求項3】

前記学習部は、前記新たな故障診断モデルの汎化性能が一定水準未満である場合に、前記故障診断モデル及び前記新たな故障診断モデルを破棄する
請求項２に記載の故障診断装置。

【請求項4】

前記予め定められた条件は、前記故障診断モデルの性能が時系列的に劣化するという条件であり、
前記学習部は、前記故障診断モデルの性能が時系列的に劣化した場合に、故障診断に用いた直近の動作履歴データ群を学習用データとして新たな故障診断モデルを生成し、前記新たな故障診断モデルの汎化性能が一定水準以上である場合に、前記故障診断モデルを、前記新たな故障診断モデルに更新する
請求項１に記載の故障診断装置。

【請求項5】

前記学習部は、前記新たな故障診断モデルの汎化性能が一定水準未満である場合に、前記直近の動作履歴データ群に対して重み付けを行い、前記重み付けを行った直近の動作履歴データ群を学習用データとして第２の新たな故障診断モデルを生成し、前記第２の新たな故障診断モデルの汎化性能が一定水準以上である場合に、前記故障診断モデルを、前記第２の新たな故障診断モデルに更新する
請求項４に記載の故障診断装置。

【請求項6】

前記学習部は、前記第２の新たな故障診断モデルの汎化性能が一定水準未満である場合に、前記故障診断モデル、前記新たな故障診断モデル、及び前記第２の新たな故障診断モデルを破棄する
請求項５に記載の故障診断装置。

【請求項7】

前記予め定められた条件は、前記故障診断モデルによって故障診断を行ったデータの数が一定値を超えるという条件であり、
前記学習部は、前記故障診断モデルによって故障診断を行ったデータの数が一定値を超えた場合に、故障診断に用いた過去の動作履歴データ群を学習用データとして新たな故障診断モデルを生成し、前記新たな故障診断モデルの汎化性能が前記故障診断モデルの汎化性能よりも高い場合に、前記故障診断モデルを、前記新たな故障診断モデルに更新する
請求項１に記載の故障診断装置。

【請求項8】

前記予め定められた条件は、前記故障診断モデルによって故障診断を行った期間が一定期間を超えるという条件であり、
前記学習部は、前記故障診断モデルによって故障診断を行った期間が一定期間を超えた場合に、故障診断に用いた過去の動作履歴データ群を学習用データとして新たな故障診断モデルを生成し、前記新たな故障診断モデルの汎化性能が前記故障診断モデルの汎化性能よりも高い場合に、前記故障診断モデルを、前記新たな故障診断モデルに更新する
請求項１に記載の故障診断装置。

【請求項9】

前記学習部は、前記新たな故障診断モデルの汎化性能が前記故障診断モデルの汎化性能以下である場合に、前記新たな故障診断モデルを破棄する
請求項７又は請求項８に記載の故障診断装置。

【請求項10】

前記故障診断モデルの性能又は汎化性能を表す指標には、故障判定時の適合率及び故障検出の再現率の少なくとも一方が用いられる
請求項２～請求項９の何れか１項に記載の故障診断装置。

【請求項11】

燃料電池コージェネレーションシステムと、
前記燃料電池コージェネレーションシステムと接続された故障診断装置と、
を備え、
前記燃料電池コージェネレーションシステムは、
自システムの動作の異常を検知した場合に、前記故障診断装置に対して、前記異常に対応する、自システムの動作履歴に関する動作履歴データを送信し、
前記故障診断装置は、
前記燃料電池コージェネレーションシステムから送信された前記動作履歴データを取得する取得部と、
過去に得られた動作履歴データ群を、前記燃料電池コージェネレーションシステムの機能部に対応付けて機械学習又は多変量解析することにより生成され、かつ、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を判定する故障診断モデルに対して、前記取得部により取得された動作履歴データ又は当該動作履歴データを加工して得られるデータを入力し、前記故障診断モデルから出力される判定結果を用いて、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を推定する推定部と、
前記故障診断モデルが予め定められた条件を満たす場合に、前記故障診断モデルを再学習することにより新たな故障診断モデルを生成する学習部と、
を備え、
前記予め定められた条件は、前記故障診断モデルの性能が一定水準に到達しないという条件、前記故障診断モデルの性能が時系列的に劣化するという条件、前記故障診断モデルによって故障診断を行ったデータの数が一定値を超えるという条件、及び、前記故障診断モデルによって故障診断を行った期間が一定期間を超えるという条件の少なくとも１つを含む
故障診断システム。

【請求項12】

コンピュータを、請求項１～請求項１０の何れか１項に記載の故障診断装置が備える各部として機能させるための故障診断プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、故障診断装置、故障診断システム、及び故障診断プログラムに関し、詳しくは、燃料電池コージェネレーションシステムの故障を診断する故障診断装置、故障診断システム、及び故障診断プログラムに関する。

【背景技術】

【0002】

従来の設備機器故障診断システムには、運転データ取得手段で取得された運転データに欠損がある場合、その欠損データ部分を欠損データ補完手段で補完された補完データを用いて補完した上で、故障診断手段を用いて故障診断ルールに従って解析を行うものがある（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

上記特許文献１に記載された技術によれば、診断に必要なデータに欠損があった場合でも、既存の故障診断ルールを変更することなくそのまま適用して診断を行うことができる。しかしながら、上記特許文献１に記載された技術は、空気調和機等の設備機器を対象としたもので、燃料電池システムを対象としたものではない。

【0005】

燃料電池システムのメンテナンスにおいて、運転データから故障部品を特定する故障診断システムを使用する場合、部品の形状変更、制御変更等の要因で、当初作成した故障診断モデルの性能が劣化する場合がある。また、該当部品の故障発生数が少ない場合、モデル作成時に十分に性能を検証できない場合もある。このため、故障診断モデルの性能をモニタリングしつつ、必要に応じてモデルの更新を行い、モデル性能を一定水準以上に維持することが望まれている。ここでいう一定水準とは、例えば、燃料電池コージェネレーションシステムの性能を十分に担保できる水準を意味する。但し、担保できる水準は、１つでも故障部品を見逃したらシステムの性能を担保できていないというものではなく、メンテナンス運用に支障が出ない程度であればよい。

【0006】

本発明は、上記事情に鑑みてなされたものであって、燃料電池コージェネレーションシステムの故障診断に用いる故障診断モデルの性能を一定水準以上に維持することができる故障診断装置、故障診断システム、及び故障診断プログラムを提供することを目的とする。

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

【0007】

上記目的を達成するために、本発明の一態様に係る故障診断装置は、燃料電池コージェネレーションシステムが動作の異常を検知した場合に、前記燃料電池コージェネレーションシステムから、前記異常に対応する、前記燃料電池コージェネレーションシステムの動作履歴に関する動作履歴データを取得する取得部と、過去に得られた動作履歴データ群を、前記燃料電池コージェネレーションシステムの機能部に対応付けて機械学習又は多変量解析することにより生成され、かつ、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を判定する故障診断モデルに対して、前記取得部により取得された動作履歴データ又は当該動作履歴データを加工して得られるデータを入力し、前記故障診断モデルから出力される判定結果を用いて、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を推定する推定部と、前記故障診断モデルが予め定められた条件を満たす場合に、前記故障診断モデルを再学習することにより新たな故障診断モデルを生成する学習部と、を備えている。

【0008】

また、本発明の一態様に係る故障診断システムは、燃料電池コージェネレーションシステムと、前記燃料電池コージェネレーションシステムと接続された故障診断装置と、を備え、前記燃料電池コージェネレーションシステムは、自システムの動作の異常を検知した場合に、前記故障診断装置に対して、前記異常に対応する、自システムの動作履歴に関する動作履歴データを送信し、前記故障診断装置は、前記燃料電池コージェネレーションシステムから送信された前記動作履歴データを取得する取得部と、過去に得られた動作履歴データ群を、前記燃料電池コージェネレーションシステムの機能部に対応付けて機械学習又は多変量解析することにより生成され、かつ、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を判定する故障診断モデルに対して、前記取得部により取得された動作履歴データ又は当該動作履歴データを加工して得られるデータを入力し、前記故障診断モデルから出力される判定結果を用いて、前記燃料電池コージェネレーションシステムの機能部毎に故障の有無を推定する推定部と、前記故障診断モデルが予め定められた条件を満たす場合に、前記故障診断モデルを再学習することにより新たな故障診断モデルを生成する学習部と、を備えている。

【0009】

また、本発明の一態様に係る故障診断プログラムは、コンピュータを、上記故障診断装置が備える各部として機能させる。

【発明の効果】

【0010】

以上詳述したように、本発明によれば、燃料電池コージェネレーションシステムの故障診断に用いる故障診断モデルの性能を一定水準以上に維持することができる。

【図面の簡単な説明】

【0011】

【図1】第１の実施形態に係る故障診断システムの構成の一例を示す図である。

【図2】第１の実施形態に係るＣＧＳの構成の一例を示すブロック図である。

【図3】第１の実施形態に係る制御プログラムによる処理の流れの一例を示すフローチャートである。

【図4】第１の実施形態に係る故障診断装置の電気的な構成の一例を示すブロック図である。

【図5】第１の実施形態に係る故障診断装置の機能的な構成の一例を示すブロック図である。

【図6】第１の実施形態に係る故障診断プログラムによる処理の流れの一例を示すフローチャートである。

【図7】第１の実施形態に係る故障診断プログラムによる学習処理の流れの一例を示すフローチャートである。

【図8】第１の実施形態に係る故障診断プログラムによるモデル更新処理の流れの一例を示すフローチャートである。

【図9】実施形態に係る適合率及び再現率の説明に供する図である。

【図10】実施形態に係るＰＲＡＵＣ法の概念を説明するための図である。

【図11】第２の実施形態に係る故障診断プログラムによるモデル更新処理の流れの一例を示すフローチャートである。

【図12】第３の実施形態に係る故障診断プログラムによるモデル更新処理の流れの一例を示すフローチャートである。

【図13】第４の実施形態に係る故障診断プログラムによるモデル更新処理の流れの一例を示すフローチャートである。

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

【0012】

以下、図面を参照して、本発明を実施するための形態の一例について詳細に説明する。

【0013】

[第１の実施形態]
図１は、第１の実施形態に係る故障診断システム１００の構成の一例を示す図である。

【0014】

図１に示すように、本実施形態に係る故障診断システム１００は、燃料電池コージェネレーションシステム（以下、単に「ＣＧＳ」という。）４０と、故障診断装置１０と、メンテナンス用端末７０と、を備えている。故障診断システム１００は、ＣＧＳ４０の故障を診断するためのシステムとして構成される。

【0015】

ＣＧＳ４０は、例えば、エネファーム（登録商標）であり、ユーザ宅３０に設置されている。故障診断装置１０は、ＣＧＳ４０の故障を診断するための装置であり、ＣＧＳ４０とネットワークＮを介して接続されている。故障診断装置１０には、例えば、サーバコンピュータ、パーソナルコンピュータ（ＰＣ）等の汎用的なコンピュータ装置が適用される。ネットワークＮには、例えば、ＬＡＮ(Local Area Network)、ＷＡＮ（Wide Area Network）、インターネット等のネットワークが適用される。

【0016】

メンテナンス用端末７０は、ＣＧＳ４０のメンテナンス作業を行う作業担当者６０が所有する端末である。メンテナンス用端末７０は、ネットワークＮを介して故障診断装置１０と接続されている。メンテナンス用端末７０には、例えば、携帯可能なタブレット端末、スマートフォン、ノート型ＰＣ等が適用される。

【0017】

本実施形態に係る故障診断装置１０は、ＣＧＳ４０が動作の異常（以下、「エラー」という。）を検知した場合に、故障診断モデルに対して、エラー検知時の動作履歴データを入力して故障診断を行う。

【0018】

具体的には、図１において、ＣＧＳ４０は、エラーを検知した場合に、エラーを発報する。このとき、ＣＧＳ４０は、自動的に故障診断装置１０に対して、自システムの動作履歴データを送信する。動作履歴データとは、例えば、エラー検知時、エラー検知前数秒間（例えば、１０秒以下）、及び、エラー検知後数秒間（例えば、１０秒以下）の少なくとも１つの動作履歴に関するデータである。動作履歴データは、例えば、各種センサの検出値、補機類（例えば、弁、ポンプ等）の動作状態を表すデータ、エラーコード等が含まれる。

【0019】

故障診断装置１０は、記憶部に、ＣＧＳ４０が備える複数の機能部の各々について故障診断モデルを予め格納している。故障診断モデルは、ＣＧＳ４０の機能部毎に故障を診断するための数理モデルである。機能部は、少なくとも１つの部品（例えば、ポンプ、弁、配管、タンク等）を含んでいる。ＣＧＳ４０の故障診断モデルは、過去に得られた動作履歴データ群を、機能部に対応付けて機械学習することにより生成されるモデルである。機械学習には、一例として、ランダムフォレスト、ニューラルネットワーク、サポートベクターマシン等が挙げられる。なお、故障診断モデルには多変量解析を適用してもよい。多変量解析には、一例として、ロジスティック回帰等が挙げられる。故障診断モデルには、例えば、機能部毎に故障の有無を判定する２クラス分類あるいは多クラス分類が用いられる。故障診断装置１０は、ＣＧＳ４０から取得した動作履歴データをそのまま、あるいは、故障診断モデルに入力可能なデータに加工し、加工したデータを故障診断モデルの各々に入力する。故障診断モデルの各々は、機能部毎に、例えば、「故障有り（故障）」又は「故障なし（健全）」を出力する。具体的に、データが示す指標値が閾値以上の場合に「故障有り」を出力し、データが示す指標値が閾値未満の場合に「故障なし」を出力する。故障診断装置１０は、故障診断モデルの各々から出力される判定結果を用いて、機能部毎に故障の有無を推定し、推定により得られた故障診断の診断結果を保持する。

【0020】

作業担当者（メンテナンス員）６０は、メンテナンス用端末７０から故障診断装置１０にアクセスし、診断結果が示す故障個所を確認する。そして、作業担当者６０は、故障診断装置１０から得られる診断結果に基づいて、現場にて部品交換作業等を実施する。

【0021】

図２は、第１の実施形態に係るＣＧＳ４０の構成の一例を示すブロック図である。

【0022】

図２に示すように、本実施形態に係るＣＧＳ４０は、大きく分けて、制御装置４１と、ＣＧＳ本体部４９と、を備えている。制御装置４１は、ＣＧＳ本体部４９と一体的に構成されてもよいし、ＣＧＳ本体部４９とは別体で構成されてもよい。

【0023】

制御装置４１は、ＣＧＳ４０のコントローラとして機能する。制御装置４１は、ＣＰＵ（Central Processing Unit）４２と、ＲＯＭ（Read Only Memory）４３と、ＲＡＭ（Random Access Memory）４４と、入出力インターフェース（Ｉ／Ｏ）４５と、記憶部４６と、通信部４７と、機器インターフェース（以下、「機器Ｉ／Ｆ」という。）４８と、を備えている。

【0024】

ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４４、及びＩ／Ｏ４５は、バスを介して各々接続されている。Ｉ／Ｏ４５には、記憶部４６と、通信部４７と、機器Ｉ／Ｆ４８と、を含む各機能部が接続されている。これらの各機能部は、Ｉ／Ｏ４５を介して、ＣＰＵ４２と相互に通信可能とされる。

【0025】

記憶部４６としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等が用いられる。記憶部４６には、ＣＧＳ本体部４９の動作を制御するための制御プログラム４６Ａが記憶される。なお、この制御プログラム４６Ａは、ＲＯＭ４３に記憶されていてもよい。

【0026】

制御プログラム４６Ａは、例えば、制御装置４１に予めインストールされていてもよい。制御プログラム４６Ａは、不揮発性の記憶媒体に記憶して、又はネットワークＮを介して配布して、制御装置４１に適宜インストールすることで実現してもよい。なお、不揮発性の記憶媒体の例としては、ＣＤ-ＲＯＭ（Compact Disc Read Only Memory）、光磁気ディスク、ＨＤＤ、ＤＶＤ-ＲＯＭ（Digital Versatile Disc Read Only Memory）、フラッシュメモリ、メモリカード等が想定される。

【0027】

通信部４７は、インターネット、ＬＡＮ、ＷＡＮ等のネットワークＮに接続されており、外部の故障診断装置１０との間でネットワークＮを介して通信が可能とされる。

【0028】

機器Ｉ／Ｆ４８には、ＣＧＳ本体部４９が接続されている。すなわち、ＣＧＳ本体部４９に含まれる各種電装部品は、機器Ｉ／Ｆ４８を介して、ＣＰＵ４２と通信可能に接続される。

【0029】

ＣＧＳ本体部４９は、公知の構成である。具体的に、ＣＧＳ本体部４９は、燃料電池ユニット５０を備える。燃料電池ユニット５０には、燃料電池モジュール５１、燃料電池モジュール５１に接続されたガス経路５２、改質水経路５３、及び空気経路５４が設けられている。ＣＧＳ本体部４９は、上述したように、複数の機能部を備える。この機能部は、少なくとも１つの部品を含んでいる。この機能部は、例えば、ガス経路５２を構成する複数の部品、改質水経路５３を構成する複数の部品、又は、空気経路５４を構成する複数の部品としてもよい。この機能部は、ＣＧＳ本体部４９を構成する個々の部品としてもよい。この部品には、例えば、ポンプ、弁、配管、タンク等が含まれる。

【0030】

燃料電池モジュール５１は、燃料電池スタック５１Ａ及び改質器５１Ｂを備える。改質器５１Ｂは、炭化水素原料を含むガス（例えば、都市ガス）を改質する。燃料電池スタック５１Ａは、電解質層、燃料極、及び空気極を有する複数の燃料電池セルが積層されている。燃料電池スタック５１Ａは、改質器５１Ｂにより都市ガスから改質された改質ガス中の水素と、空気中の酸素とを反応させて電気及び水を発生させるように構成されている。燃料電池ユニット５０は、改質ガス及び空気の供給量を調整するための弁及びポンプ等の補機類と、燃料電池スタック５１Ａによる発電で発生した熱を伝熱媒体（例えば、水等）との間で熱交換するための熱交換器と、を備えている。

【0031】

ＣＧＳ本体部４９は、貯湯タンクを備える。ＣＧＳ本体部４９では、貯湯タンクに給水されると、貯湯タンクから燃料電池ユニット５０の熱交換器に水が供給され、この熱交換器で水が燃料電池スタック５１Ａの熱で加熱される。熱交換器で水が加熱されると、水が湯となる。この湯は、貯湯タンクに供給され、この貯湯タンクに貯められる。貯湯タンクは、燃料電池ユニット５０との間で水及び湯を行き来させるための弁及びポンプや、貯湯タンクに貯めた湯を排湯させるための弁及びポンプ等の補機類を備える。

【0032】

また、ガス経路５２は、都市ガスが流れる経路である。ガス経路５２には、都市ガスの供給量を調整するための弁及びポンプ等の補機類が含まれる。改質水経路５３は、改質水が流れる経路である。改質水経路５３には、改質水の供給量を調整するための弁及びポンプ等の補機類が含まれる。空気経路５４は、空気が流れる経路である。空気経路５４には、空気の供給量を調整するための弁及びポンプ等の補機類が含まれる。

【0033】

制御装置４１は、ＣＧＳ本体部４９に備えられた補機類を制御するコントローラである。制御装置４１は、ＣＧＳ本体部４９に対して、補機類を制御するための制御信号をそれぞれ出力する。また、ＣＧＳ本体部４９は、制御装置４１に対して、ＣＧＳ本体部４９の運転状況を表す運転データを出力する。この運転データには、特徴量として、補機類の動作状態を表すデータ（例えば、電圧値、電流値等）、ＣＧＳ本体部４９に設けられた各種センサの検出値等が含まれる。具体的に、補機類の動作状態を表すデータとは、例えば、ポンプの場合にはポンプの操作量を表すデータであり、弁の場合には弁の開閉状態を表すデータである。また、各種センサの検出値とは、例えば、配管の場合には都市ガス、改質水、及び空気のそれぞれの流量を表す値であり、タンクの場合には水位を表す値である。

【0034】

制御装置４１は、ＣＧＳ本体部４９から取得した時系列の運転データを記憶部４６に記憶する。制御装置４１は、ＣＧＳ本体部４９から取得した運転データに基づいて、ＣＧＳ本体部４９のエラーを検知する機能を有する。なお、エラーの検知は、例えば、運転データから得られる特徴量と対応する閾値との比較により行われる。

【0035】

ここで、図３を参照して、本実施形態に係る制御装置４１によるエラー発報処理について具体的に説明する。なお、このエラー発報処理は、制御装置４１が備える制御プログラム４６Ａによって実行される。

【0036】

図３は、第１の実施形態に係る制御プログラム４６Ａによる処理の流れの一例を示すフローチャートである。

【0037】

まず、ＣＰＵ４２により記憶部４６に記憶されている制御プログラム４６Ａが起動され、以下に示す各ステップが実行される。

【0038】

図３のステップＳ１０１では、ＣＰＵ４２が、ＣＧＳ本体部４９から時系列で取得した運転データを記憶部４６に記憶すると共に、取得した運転データに基づいて、エラーの発生を示す異常値を検知したか否かを判定する。異常値を検知したと判定した場合（肯定判定の場合）、ステップＳ１０２に移行し、異常値を検知しないと判定した場合（否定判定の場合）、ステップＳ１０１で待機となる。

【0039】

ステップＳ１０２では、ＣＰＵ４２が、記憶部４６に記憶した時系列の運転データの中から、エラー検知時、エラー検知前数秒間（例えば、１０秒以下）、及び、エラー検知後数秒間（例えば、１０秒以下）の少なくとも１つの運転データを動作履歴データとして抽出し、抽出した動作履歴データを記憶部４６に保持する。この動作履歴データには、上述したように、例えば、各種センサの検出値、補機類の動作状態を表すデータ、エラーコード等が含まれる。記憶部４６に保持した動作履歴データを「データ１」と称する。

【0040】

ステップＳ１０３では、ＣＰＵ４２が、ステップＳ１０２でのデータ１の保持をもってエラーを確定する。

【0041】

ステップＳ１０４では、ＣＰＵ４２が、通信部４７を介して、ステップＳ１０２で保持したデータ１を故障診断装置１０に送信し、本制御プログラム４６Ａによる一連の処理を終了する。

【0042】

図４は、第１の実施形態に係る故障診断装置１０の電気的な構成の一例を示すブロック図である。

【0043】

図４に示すように、本実施形態に係る故障診断装置１０は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、Ｉ／Ｏ１４と、記憶部１５と、表示部１６と、操作部１７と、通信部１８と、を備えている。

【0044】

ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、及びＩ／Ｏ１４は、バスを介して各々接続されている。Ｉ／Ｏ１４には、記憶部１５と、表示部１６と、操作部１７と、通信部１８と、を含む各機能部が接続されている。これらの各機能部は、Ｉ／Ｏ１４を介して、ＣＰＵ１１と相互に通信可能とされる。

【0045】

記憶部１５としては、例えば、ＨＤＤ、ＳＳＤ、フラッシュメモリ等が用いられる。記憶部１５には、ＣＧＳ４０の故障を診断するための故障診断プログラム１５Ａが記憶される。なお、この故障診断プログラム１５Ａは、ＲＯＭ１２に記憶されていてもよい。

【0046】

故障診断プログラム１５Ａは、例えば、故障診断装置１０に予めインストールされていてもよい。故障診断プログラム１５Ａは、不揮発性の記憶媒体に記憶して、又はネットワークＮを介して配布して、故障診断装置１０に適宜インストールすることで実現してもよい。なお、不揮発性の記憶媒体の例としては、ＣＤ-ＲＯＭ、光磁気ディスク、ＨＤＤ、ＤＶＤ-ＲＯＭ、フラッシュメモリ、メモリカード等が想定される。

【0047】

表示部１６には、例えば、液晶ディスプレイ（ＬＣＤ:Liquid Crystal Display）、有機ＥＬ（Electro Luminescence）ディスプレイ等が用いられる。表示部１６は、タッチパネルを一体的に有していてもよい。操作部１７には、例えば、キーボード、マウス等の操作入力用のデバイスが設けられている。表示部１６及び操作部１７は、故障診断装置１０のユーザから各種の指示を受け付ける。表示部１６は、ユーザから受け付けた指示に応じて実行された処理の結果や、処理に対する通知等の各種の情報を表示する。

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

また、適合率及び再現率の両方を用いてもよい。具体的には、一例として、図１０に示すＰＲＡＵＣ（Precision Recall Area Under Curve）法を適用して、故障診断モデル１５Ｂの性能を評価してもよい。

【0097】

図１０は、本実施形態に係るＰＲＡＵＣ法の概念を説明するための図である。

【0098】

図１０において、縦軸は故障判定時の適合率（Precision）を示し、横軸は故障検出の再現率（Recall）を示す。故障診断モデル１５Ｂの故障／健全を判定する閾値を変化させたときの再現率及び適合率をプロットし、ＰＲ曲線を作成する。ＰＲ曲線の下に位置する領域の面積をＡＵＣ（Area Under Curve）という。ＰＲＡＵＣ法では、面積ＡＵＣが０以上１以下の範囲で大きいほど、モデルの性能が高いとされる。つまり、面積ＡＵＣが１のときのＰＲ曲線が理想的なＰＲ曲線とされる。例えば、いずれかの動作点（閾値）における適合率又は再現率が、事前に設定したメンテナンス運用上要求される設定値以上である場合には、故障診断モデル１５Ｂの性能が一定水準に到達していると判定される。なお、適合率の設定値と、再現率の設定値とは異なるものとする。

【0099】

図８に戻り、ステップＳ１３６では、ＣＰＵ１１が、故障診断モデル１５Ｂを再学習し、新たな故障診断モデルを生成する。再学習に用いる学習用データは、故障診断モデル１５Ｂによる故障診断に用いられた過去の動作履歴データ及びその正解データのセットである。

【0100】

ステップＳ１３７では、ＣＰＵ１１が、ステップＳ１３６で生成した新たな故障診断モデルの汎化性能が過去データに対して一定水準以上であるか否かを判定する。新たな故障診断モデルの汎化性能が過去データに対して一定水準以上であると判定した場合（肯定判定の場合）、ステップＳ１３８に移行し、新たな故障診断モデルの汎化性能が過去データに対して一定水準未満であると判定した場合（否定判定の場合）、ステップＳ１３９に移行する。

【0101】

ステップＳ１３８では、ＣＰＵ１１が、故障診断モデル１５Ｂを、ステップＳ１３６で生成した新たな故障診断モデルに更新、つまり、新モデルを採用、配置（デプロイ）し、本故障診断プログラム１５Ａによる一連の処理を終了する。

【0102】

一方、ステップＳ１３９では、ＣＰＵ１１が、現故障診断モデルである故障診断モデル１５Ｂを破棄する。

【0103】

ステップＳ１４０では、ＣＰＵ１１が、ステップＳ１３６で生成した新たな故障診断モデルを破棄する。

【0104】

ステップＳ１４１では、ＣＰＵ１１が、対象部品に対して一定水準を満たす故障診断モデルが存在しないため、対象部品を故障診断システムの対象外に設定し、本故障診断プログラム１５Ａによる一連の処理を終了する。

【0105】

なお、本実施形態では、故障診断装置１０を外部のサーバ装置として実現した場合について説明したが、これに限定されない。故障診断装置１０はＣＧＳ４０の制御装置４１として実現してもよい。

【0106】

このように本実施形態によれば、燃料電池コージェネレーションシステムの故障診断に用いる故障診断モデルの性能が一定水準に到達しない場合に、故障診断モデルが再学習され更新可能とされる。このため、故障診断モデルの性能を一定水準以上に維持することができる。

【0107】

[第２の実施形態]
第２の実施形態では、故障診断モデルの性能が時系列的に劣化した場合に、故障診断モデルを再学習する形態について説明する。

【0108】

なお、第２の実施形態に係る故障診断装置は、上記第１の実施形態に係る故障診断装置１０と同一の構成要素を有しているため、上述の図５を参照して説明する。

【0109】

本実施形態では、予め定められた条件として、故障診断モデル１５Ｂの性能が時系列的に劣化するという条件が適用される。通常、燃料電池システムは、同一機種であってもハード・制御のランニングチェンジを行うことが多く、時間の経過によって故障診断モデルの汎化性能を失いやすい機器であるといえる。

【0110】

学習部１１Ｃは、故障診断モデル１５Ｂの性能が時系列的に劣化した場合に、故障診断に用いた直近の動作履歴データ群を学習用データとして新たな故障診断モデルを生成する。なお、直近データとは、例えば、直近の一定データ数、一定期間のデータ、又は、性能劣化の起点(性能低下の傾きが一定以上)以降のデータのいずれかのデータとされる。そして、学習部１１Ｃは、新たな故障診断モデルの汎化性能が一定水準以上である場合に、故障診断モデル１５Ｂを、新たな故障診断モデルに更新する。なお、直近データ数が学習・検証に対して十分に確保できているときは、直近データのみで再学習、汎化性能評価を実施しても良い。

【0111】

また、学習部１１Ｃは、新たな故障診断モデルの汎化性能が一定水準未満である場合に、直近の動作履歴データ群に対して重み付けを行い、重み付けを行った直近の動作履歴データ群を学習用データとして第２の新たな故障診断モデルを生成する。そして、学習部１１Ｃは、第２の新たな故障診断モデルの汎化性能が一定水準以上である場合に、故障診断モデル１５Ｂを、第２の新たな故障診断モデルに更新する。なお、重み付けの具体的な方法として、例えば、時系列的にデータ１、２、３、・・・、Ｎ（直近）で並べ、データ番号を重みとして利用する方法Ａ及び方法Ｂが考えられる。例えば、適合率が評価対象の場合、従来方法では、適合率＝故障判定で実際に故障していた数／故障判定数、但し、各データの重みは１、となる。これに対して、方法Ａでは、下記のようになる。

【0112】

適合率＝Σ｛（故障判定で実際に故障×データ番号ｎ）／（故障判定×データ番号ｎ）｝、但し、重みは比例増加である。「故障判定で実際に故障」及び「故障判定」は０又は１のデータである。

【0113】

また、方法Ｂでは、下記のようになる。

【0114】

適合率＝Σ｛（係数Ｃ（ｎ）×故障判定で実際に故障×データ番号ｎ）／（係数Ｃ（ｎ）×故障判定×データ番号ｎ）｝、但し、係数Ｃ（ｎ）は直近データの重みを比例以外で調整するための係数である。係数Ｃ（ｎ）はデータ番号ｎの関数で、連続関数あるいは不連続関数（ステップ関数等）のどちらでもよい。「故障判定で実際に故障」及び「故障判定」は０又は１のデータである。

【0115】

また、学習部１１Ｃは、第２の新たな故障診断モデルの汎化性能が一定水準未満である場合に、故障診断モデル１５Ｂ、新たな故障診断モデル、及び第２の新たな故障診断モデルを破棄する。

【0116】

つまり、本実施形態では、故障診断モデル１５Ｂの性能(例えば、適合率、再現率等)を時系列（例えば、時間－データ数）でモニタリングし、一定のデータ数あるいは一定の期間において、顕著な性能劣化が認められる場合は、再学習を実行する。なお、本実施形態では、時系列的な性能劣化が再学習の要因であるため、再学習時のテストデータ(モデルの性能評価に使用)は直近データで行うことが望ましい。また、再学習を行っても性能が出ない場合には、直近データに重み付けを行うことで、直近データにより適合したモデリングを行うことができる。重み付けを行っても性能が満たない場合には、誤った故障診断を防ぐために、故障診断モデル１５Ｂ及び新たな故障診断モデルを破棄し、対象部品を故障診断システムの対象外とする。

【0117】

次に、図１１を参照して、第２の実施形態に係る故障診断装置１０によるモデル更新処理について具体的に説明する。

【0118】

図１１は、第２の実施形態に係る故障診断プログラム１５Ａによるモデル更新処理の流れの一例を示すフローチャートである。

【0119】

まず、ＣＰＵ１１により記憶部１５に記憶されている故障診断プログラム１５Ａが起動され、以下に示す各ステップが実行される。本実施形態では、故障診断モデル１５Ｂの性能が時系列的に劣化した場合に、故障診断モデル１５Ｂを再学習する。

【0120】

図１１のステップＳ１５１では、ＣＰＵ１１が、任意の部品に対する故障診断モデル１５Ｂ（現故障診断モデル）の診断結果（例えば、故障又は健全）を取得し、取得した診断結果をメンテナンス用端末７０に送信する。そして、メンテナンス用端末７０を所有する作業担当者６０は、診断結果が故障である場合、現場にて対象部品の故障診断作業を行い、対象部品が故障であるか健全であるかの確認を行う。そして、作業担当者６０は、メンテナンス用端末７０を介して、対象部品の故障又は健全の確認結果を入力する。

【0121】

ステップＳ１５２では、ＣＰＵ１１が、作業担当者６０から、メンテナンス用端末７０を介して、対象部品の故障又は健全の確認結果の入力を受け付ける。

【0122】

ステップＳ１５３では、ＣＰＵ１１が、対象部品の故障診断に用いた動作履歴データ及び対象部品の確認結果をセットにして、記憶部１５に記憶する。

【0123】

ステップＳ１５４では、ＣＰＵ１１が、ステップＳ１５３で記憶部１５に記憶した動作履歴データ及び確認結果を用いて、故障診断モデル１５Ｂの性能を更新する。

【0124】

ステップＳ１５５では、ＣＰＵ１１が、ステップＳ１５４で性能を更新した故障診断モデル１５Ｂの性能が時系列的に劣化したか否かを判定する。故障診断モデル１５Ｂの性能が時系列的に劣化したと判定した場合（肯定判定の場合）、ステップＳ１５６に移行し、故障診断モデル１５Ｂの性能が時系列的に劣化していないと判定した場合（否定判定の場合）、ステップＳ１５１に戻り処理を繰り返す。

【0125】

ステップＳ１５６では、ＣＰＵ１１が、故障診断モデル１５Ｂを再学習し、新たな故障診断モデルを生成する。再学習に用いる学習用データは、故障診断モデル１５Ｂによる故障診断に用いられた直近の動作履歴データ及びその正解データのセットである。

【0126】

ステップＳ１５７では、ＣＰＵ１１が、ステップＳ１５６で生成した新たな故障診断モデルの汎化性能が直近データに対して一定水準以上であるか否かを判定する。新たな故障診断モデルの汎化性能が直近データに対して一定水準以上であると判定した場合（肯定判定の場合）、ステップＳ１５８に移行し、新たな故障診断モデルの汎化性能が直近データに対して一定水準未満であると判定した場合（否定判定の場合）、ステップＳ１５９に移行する。

【0127】

ステップＳ１５８では、ＣＰＵ１１が、故障診断モデル１５Ｂを、ステップＳ１５６で生成した新たな故障診断モデルに更新、つまり、新モデルを採用、配置（デプロイ）し、本故障診断プログラム１５Ａによる一連の処理を終了する。

【0128】

一方、ステップＳ１５９では、ＣＰＵ１１が、再学習時のテストデータである直近データに重み付けを行う。

【0129】

ステップＳ１６０では、ＣＰＵ１１が、ステップＳ１５９で重み付けした直近データで故障診断モデル１５Ｂを再学習し、第２の新たな故障診断モデルを生成する。

【0130】

ステップＳ１６１では、ＣＰＵ１１が、ステップＳ１６０で生成した第２の新たな故障診断モデルの汎化性能が重み付け直近データに対して一定水準以上であるか否かを判定する。第２の新たな故障診断モデルの汎化性能が重み付け直近データに対して一定水準以上であると判定した場合（肯定判定の場合）、ステップＳ１５８に移行し、第２の新たな故障診断モデルの汎化性能が重み付け直近データに対して一定水準未満であると判定した場合（否定判定の場合）、ステップＳ１６２に移行する。

【0131】

ステップＳ１６２では、ＣＰＵ１１が、現故障診断モデルである故障診断モデル１５Ｂを破棄する。

【0132】

ステップＳ１６３では、ＣＰＵ１１が、ステップＳ１５６で生成した新たな故障診断モデル及びステップＳ１６０で生成した第２の新たな故障診断モデルを破棄する。

【0133】

ステップＳ１６４では、ＣＰＵ１１が、対象部品に対して一定水準を満たす故障診断モデルが存在しないため、対象部品を故障診断システムの対象外に設定し、本故障診断プログラム１５Ａによる一連の処理を終了する。

【0134】

なお、本実施形態では、故障診断装置１０を外部のサーバ装置として実現した場合について説明したが、これに限定されない。故障診断装置１０はＣＧＳ４０の制御装置４１として実現してもよい。

【0135】

このように本実施形態によれば、燃料電池コージェネレーションシステムの故障診断に用いる故障診断モデルの性能が時系列的に劣化した場合に、故障診断モデルが再学習され更新可能とされる。このため、故障診断モデルの性能を一定水準以上に維持することができる。

【0136】

[第３の実施形態]
第３の実施形態では、故障診断モデルによって故障診断を行ったデータ数が一定値を超えた場合に、故障診断モデルを再学習する形態について説明する。

【0137】

なお、第３の実施形態に係る故障診断装置は、上記第１の実施形態に係る故障診断装置１０と同一の構成要素を有しているため、上述の図５を参照して説明する。

【0138】

本実施形態では、予め定められた条件として、故障診断モデル１５Ｂによって故障診断を行ったデータの数が一定値を超えるという条件が適用される。

【0139】

学習部１１Ｃは、故障診断モデル１５Ｂによって故障診断を行ったデータの数が一定値を超えた場合に、故障診断に用いた過去の動作履歴データ群を学習用データとして新たな故障診断モデルを生成する。そして、学習部１１Ｃは、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能よりも高い場合に、故障診断モデル１５Ｂを、新たな故障診断モデルに更新する。

【0140】

また、学習部１１Ｃは、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能以下である場合に、新たな故障診断モデルを破棄する。

【0141】

本実施形態では、基本的な処理は、上記第１の実施形態で説明した処理（図８参照）と同じだが、上記第１、第２の実施形態で説明した少なくとも１つの処理と同時に実装する場合、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂ（現故障診断モデル）の汎化性能以下のときは新たな故障診断モデルを破棄し、故障診断モデル１５Ｂをそのまま使用し続ける。従って、対象部品が故障診断システムの対象外になることはない。一方、上記第１、第２の実施形態と同時に実装しない場合、故障診断モデル１５Ｂと新たな故障診断モデルの両方の汎化性能が一定水準未満になる可能性がある。このため、基準となる汎化性能との比較処理、及び性能未達時における両方の故障診断モデルの破棄処理が追加される。

【0142】

次に、図１２を参照して、第３の実施形態に係る故障診断装置１０によるモデル更新処理について具体的に説明する。

【0143】

図１２は、第３の実施形態に係る故障診断プログラム１５Ａによるモデル更新処理の流れの一例を示すフローチャートである。

【0144】

まず、ＣＰＵ１１により記憶部１５に記憶されている故障診断プログラム１５Ａが起動され、以下に示す各ステップが実行される。本実施形態では、故障診断モデル１５Ｂの性能が一定水準に到達しない場合に、故障診断モデル１５Ｂを再学習する。

【0145】

図１２のステップＳ１７１では、ＣＰＵ１１が、任意の部品に対する故障診断モデル１５Ｂ（現故障診断モデル）の診断結果（例えば、故障又は健全）を取得し、取得した診断結果をメンテナンス用端末７０に送信する。そして、メンテナンス用端末７０を所有する作業担当者６０は、診断結果が故障である場合、現場にて対象部品の故障診断作業を行い、対象部品が故障であるか健全であるかの確認を行う。そして、作業担当者６０は、メンテナンス用端末７０を介して、対象部品の故障又は健全の確認結果を入力する。

【0146】

ステップＳ１７２では、ＣＰＵ１１が、作業担当者６０から、メンテナンス用端末７０を介して、対象部品の故障又は健全の確認結果の入力を受け付ける。

【0147】

ステップＳ１７３では、ＣＰＵ１１が、対象部品の故障診断に用いた動作履歴データ及び対象部品の確認結果をセットにして、記憶部１５に記憶する。

【0148】

ステップＳ１７４では、ＣＰＵ１１が、ステップＳ１７３で記憶部１５に記憶した動作履歴データ及び確認結果を用いて、故障診断モデル１５Ｂの性能を更新する。

【0149】

ステップＳ１７５では、ＣＰＵ１１が、データ数のカウンタをインクリメントする。

【0150】

ステップＳ１７６では、ＣＰＵ１１が、ステップＳ１７５でインクリメントしたカウンタの値がｎより大きいか否かを判定する。カウンタの値がｎより大きいと判定した場合（肯定判定の場合）、ステップＳ１７７に移行し、カウンタの値がｎ以下と判定した場合（否定判定の場合）、ステップＳ１７１に戻り処理を繰り返す。

【0151】

ステップＳ１７７では、ＣＰＵ１１が、故障診断モデル１５Ｂを再学習し、新たな故障診断モデルを生成する。再学習に用いる学習用データは、故障診断モデル１５Ｂによる故障診断に用いられた過去の動作履歴データ及びその正解データのセットである。

【0152】

ステップＳ１７８では、ＣＰＵ１１が、ステップＳ１７７で生成した新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能よりも高いか否かを判定する。新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能よりも高いと判定した場合（肯定判定の場合）、ステップＳ１７９に移行し、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能以下であると判定した場合（否定判定の場合）、ステップＳ１８０に移行する。

【0153】

ステップＳ１７９では、ＣＰＵ１１が、故障診断モデル１５Ｂを、ステップＳ１７７で生成した新たな故障診断モデルに更新、つまり、新モデルを採用、配置（デプロイ）し、ステップＳ１８１に移行する。

【0154】

一方、ステップＳ１８０では、ＣＰＵ１１が、ステップＳ１７７で生成した新たな故障診断モデルを破棄し、ステップＳ１８１に移行する。なお、現故障診断モデル及び新故障診断モデルの両方が一定水準未満の場合、両方のモデルを破棄して、故障診断システムの対象外としてもよい。

【0155】

ステップＳ１８１では、ＣＰＵ１１が、カウンタを初期化し、本故障診断プログラム１５Ａによる一連の処理を終了する。

【0156】

なお、本実施形態では、故障診断装置１０を外部のサーバ装置として実現した場合について説明したが、これに限定されない。故障診断装置１０はＣＧＳ４０の制御装置４１として実現してもよい。

【0157】

このように本実施形態によれば、燃料電池コージェネレーションシステムの故障診断に用いる故障診断モデルによって故障診断を行ったデータの数が一定値を超えた場合に、故障診断モデルが再学習され更新可能とされる。このため、故障診断モデルの性能を一定水準以上に維持することができる。

【0158】

[第４の実施形態]
第４の実施形態では、故障診断モデルによって故障診断を行った期間が一定期間を超えた場合に、故障診断モデルを再学習する形態について説明する。

【0159】

なお、第４の実施形態に係る故障診断装置は、上記第１の実施形態に係る故障診断装置１０と同一の構成要素を有しているため、上述の図５を参照して説明する。

【0160】

本実施形態では、予め定められた条件として、故障診断モデル１５Ｂによって故障診断を行った期間が一定期間を超えるという条件が適用される。

【0161】

学習部１１Ｃは、故障診断モデル１５Ｂによって故障診断を行った期間が一定期間を超えた場合に、故障診断に用いた過去の動作履歴データ群を学習用データとして新たな故障診断モデルを生成する。そして、学習部１１Ｃは、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能よりも高い場合に、故障診断モデル１５Ｂを、新たな故障診断モデルに更新する。

【0162】

また、学習部１１Ｃは、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能以下である場合に、新たな故障診断モデルを破棄する。

【0163】

本実施形態では、基本的な処理は、上記第１の実施形態で説明した処理（図８参照）と同じだが、上記第１、第２の実施形態で説明した少なくとも１つの処理と同時に実装する場合、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂ（現故障診断モデル）の汎化性能以下のときは新たな故障診断モデルを破棄し、故障診断モデル１５Ｂをそのまま使用し続ける。従って、対象部品が故障診断システムの対象外になることはない。一方、上記第１、第２の実施形態と同時に実装しない場合、故障診断モデル１５Ｂと新たな故障診断モデルの両方の汎化性能が一定水準未満になる可能性がある。このため、基準となる汎化性能との比較処理、及び性能未達時における両方の故障診断モデルの破棄処理が追加される。

【0164】

次に、図１３を参照して、第４の実施形態に係る故障診断装置１０によるモデル更新処理について具体的に説明する。

【0165】

図１３は、第４の実施形態に係る故障診断プログラム１５Ａによるモデル更新処理の流れの一例を示すフローチャートである。

【0166】

まず、ＣＰＵ１１により記憶部１５に記憶されている故障診断プログラム１５Ａが起動され、以下に示す各ステップが実行される。本実施形態では、故障診断モデル１５Ｂの性能が一定水準に到達しない場合に、故障診断モデル１５Ｂを再学習する。

【0167】

図１３のステップＳ１９１では、ＣＰＵ１１が、任意の部品に対する故障診断モデル１５Ｂ（現故障診断モデル）の診断結果（例えば、故障又は健全）を取得し、取得した診断結果をメンテナンス用端末７０に送信する。そして、メンテナンス用端末７０を所有する作業担当者６０は、診断結果が故障である場合、現場にて対象部品の故障診断作業を行い、対象部品が故障であるか健全であるかの確認を行う。そして、作業担当者６０は、メンテナンス用端末７０を介して、対象部品の故障又は健全の確認結果を入力する。

【0168】

ステップＳ１９２では、ＣＰＵ１１が、作業担当者６０から、メンテナンス用端末７０を介して、対象部品の故障又は健全の確認結果の入力を受け付ける。

【0169】

ステップＳ１９３では、ＣＰＵ１１が、対象部品の故障診断に用いた動作履歴データ及び対象部品の確認結果をセットにして、記憶部１５に記憶する。

【0170】

ステップＳ１９４では、ＣＰＵ１１が、ステップＳ１９３で記憶部１５に記憶した動作履歴データ及び確認結果を用いて、故障診断モデル１５Ｂの性能を更新する。

【0171】

ステップＳ１９５では、ＣＰＵ１１が、ステップＳ１９４で性能を更新した故障診断モデル１５Ｂの適用期間がｍより長いか否かを判定する。適用期間がｍより長いと判定した場合（肯定判定の場合）、ステップＳ１９６に移行し、適用期間がｍ以下と判定した場合（否定判定の場合）、ステップＳ１９１に戻り処理を繰り返す。

【0172】

ステップＳ１９６では、ＣＰＵ１１が、故障診断モデル１５Ｂを再学習し、新たな故障診断モデルを生成する。再学習に用いる学習用データは、故障診断モデル１５Ｂによる故障診断に用いられた過去の動作履歴データ及びその正解データのセットである。

【0173】

ステップＳ１９７では、ＣＰＵ１１が、ステップＳ１９６で生成した新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能よりも高いか否かを判定する。新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能よりも高いと判定した場合（肯定判定の場合）、ステップＳ１９８に移行し、新たな故障診断モデルの汎化性能が故障診断モデル１５Ｂの汎化性能以下であると判定した場合（否定判定の場合）、ステップＳ１９９に移行する。

【0174】

ステップＳ１９８では、ＣＰＵ１１が、故障診断モデル１５Ｂを、ステップＳ１９６で生成した新たな故障診断モデルに更新、つまり、新モデルを採用、配置（デプロイ）し、本故障診断プログラム１５Ａによる一連の処理を終了する。

【0175】

一方、ステップＳ１９９では、ＣＰＵ１１が、ステップＳ１９６で生成した新たな故障診断モデルを破棄し、本故障診断プログラム１５Ａによる一連の処理を終了する。なお、現故障診断モデル及び新故障診断モデルの両方が一定水準未満の場合、両方のモデルを破棄して、故障診断システムの対象外としてもよい。

【0176】

なお、本実施形態では、故障診断装置１０を外部のサーバ装置として実現した場合について説明したが、これに限定されない。故障診断装置１０はＣＧＳ４０の制御装置４１として実現してもよい。

【0177】

このように本実施形態によれば、燃料電池コージェネレーションシステムの故障診断に用いる故障診断モデルによって故障診断を行った期間が一定期間を超えた場合に、故障診断モデルが再学習され更新可能とされる。このため、故障診断モデルの性能を一定水準以上に維持することができる。

【0178】

以上、上記各実施形態として、故障診断装置及び故障診断システムを例示して説明したが、各実施形態は、故障診断装置が備える各部の機能をコンピュータに実行させるためのプログラムの形態としてもよい。各実施形態は、このプログラムを記憶したコンピュータが読み取り可能な記憶媒体の形態としてもよい。

【0179】

その他、上記各実施形態で説明した故障診断装置及び故障診断システムの構成は、一例であり、主旨を逸脱しない範囲内において状況に応じて変更してもよい。

【0180】

また、上記各実施形態で説明したプログラムの処理の流れも、一例であり、主旨を逸脱しない範囲内において不要なステップを削除したり、新たなステップを追加したり、処理順序を入れ替えたりしてもよい。

【0181】

また、上記各実施形態では、プログラムを実行することにより、各実施形態に係る処理がコンピュータを利用してソフトウェア構成により実現される場合について説明したが、これに限らない。各実施形態は、例えば、ハードウェア構成や、ハードウェア構成とソフトウェア構成との組み合わせによって実現してもよい。

【符号の説明】

【0182】

１０ 故障診断装置
１１、４２ ＣＰＵ
１１Ａ 取得部
１１Ｂ 推定部
１１Ｃ 学習部
１１Ｄ 第１出力部
１１Ｅ 第２出力部
１２、４３ ＲＯＭ
１３、４４ ＲＡＭ
１４、４５ Ｉ／Ｏ
１５、４６ 記憶部
１５Ａ 故障診断プログラム
１５Ｂ 故障診断モデル
１６ 表示部
１７ 操作部
１８、４７ 通信部
３０ ユーザ宅
４０ ＣＧＳ
４１ 制御装置
４６Ａ 制御プログラム
４８ 機器Ｉ／Ｆ
４９ ＣＧＳ本体部
５０ 燃料電池ユニット
５１ 燃料電池モジュール
５１Ａ 燃料電池スタック
５１Ｂ 改質器
５２ ガス経路
５３ 改質水経路
５４ 空気経路
６０ 作業担当者
７０ メンテナンス用端末
１００ 故障診断システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】