JP2004201497A - 保守システム - Google Patents

Abstract

【課題】 分散発電システムから給電を受ける受電装置を保守するためのシステムを提供する。
【解決手段】 分散発電システム１２は、給電線を介して各受電装置１３へ電力を供給し、その給電線を介して受電装置１３の動作状況を監視する。受電装置１３のメンテナンスが必要なとき、分散発電システム１２は、管理装置２０へメンテナンス情報を送信する。管理装置２０は、受電装置１３の製造業者、販売業者、修理業者の中から、メンテナンス情報をもとに最適な保守主体を選択して、メンテナンスの実行を依頼する。
【選択図】 図１

Description

この発明は、発電システムから給電を受ける受電装置の保守技術に関する。この発明は、とくに、分散型の発電システムと、それを利用した保守システムおよび保守方法に関する。

ＩＴやバイオなどの新技術が世界規模で展開される時代となったが、そうした状況にあっても、エネルギー産業は最大級の基幹産業であることに変わりはない。最近では、地球温暖化防止をはじめとする環境意識の浸透に伴い、いわゆる新エネルギーに対する期待が高まっている。新エネルギーは、環境性に加え、電力需要家に近接して分散型で生産できるため、送電損失面と電力供給のセキュリティ面でもメリットがある。また、新エネルギーの開発が新たな周辺産業を創出する副次的効果も期待できる。

新エネルギーに対する取り組みは、約３０年前の石油危機を契機として本格化し、現在では、太陽光発電などの再生可能エネルギー、廃棄物発電などのリサイクルエネルギー、燃料電池などの高効率エネルギー、およびクリーンエネルギーカーを代表とする新分野エネルギーなどのエネルギーが、それぞれ実用化に向けた開発の段階にある。

そうした中でも、燃料電池は業界でもっとも注目されるエネルギーのひとつである。燃料電池は、天然ガスやメタノールに水蒸気を混ぜて作った水素と、大気中から採取した酸素を化学反応させて電気と熱を同時に生成するもので、発電による副産物が水だけであり、低出力域でも高効率で、しかも発電が天候に影響されず安定的である。固体高分子型燃料電池は、住居用をはじめとする定置型、および車載型の両用途において次世代のひとつの標準電源と目されている。

現在、固体高分子型燃料電池を利用する発電システムは、試作から実用化の途上にある。燃料電池の普及はコストをいかに低減できるかに依存する。初期コストは開発側の課題ではあるが、運用上のコストまたはメリットは、燃料電池を用いるシステムのランニングコスト、寿命などにも依存する。

したがって燃料電池の普及には、単に燃料電池自体の技術的改良だけではなく、それを利用する環境をビジネスモデルとして構築する必要がある。燃料電池から給電を受ける家電装置をも含めたメンテナンス体制の整備など、より高い利便性の追及が求められる。

特に、家電装置のメンテナンスは、これまでユーザに委ねられてきた。このため、同じ製品を同様に使っていてもユーザの日常の手入れにばらつきがあり、製品の寿命に差が出ていた。故障した場合は、ユーザが機械の症状の説明を行うため、必ずしも的確な説明でなく、現状把握に時間と手間を要し、修理コストの増大につながった。また、ユーザは、まず修理先を探さねばならず、機器の故障に加え、心理的な負担が大きかった。
本発明はこうした背景からなされたものであり、その目的は、分散型の発電システムから給電される家電装置の保守に関するサービスの向上である。

本発明のある態様は、分散型の発電システム（以下単に分散発電システムという）に関する。このシステムは、発電装置を有し、前記発電装置からの給電を受ける受電装置が接続されており、前記受電装置の電力消費状況をもとに、前記受電装置に関するメンテナンス情報を生成する。「発電装置」は任意のものでよいが、発電能力に安定性が期待できる燃料電池はひとつの好適な例である。

このシステムは、前記受電装置が出力した動作情報を受信して、前記メンテナンス情報を生成してもよい。動作情報として、たとえば冷蔵庫の場合、庫内の温度、湿度などの情報を受信してもよい。また、受電装置が出力するエラーメッセージなどを受信してもよい。

このシステムは、前記受電装置の経時変化に対して必要になるメンテナンス情報を特定してもよい。予め受電装置の経時変化に関する情報を検出し、定期点検、消耗部品の交換、フィルタ等の清掃、装置自体の買い替えなどのメンテナンスが必要か否かを判断してもよい。

このシステムは、前記メンテナンス情報をもとに、前記受電装置の動作を制御する制御部を含んでもよい。制御部は、受電装置の性能を維持すべく、その制御パラメータの変更を指示してもよい。

制御部は、前記受電装置の異常を検知したときに、前記受電装置への給電を停止してもよい。これにより、たとえば、地震時に電気ストーブの動作を停止させ、事故を未然に防ぐことができる。給電の停止を実施するか否かを設定できるような構成であってもよい。

このシステムは、前記受電装置へ給電するための電線に信号を重畳させることにより前記受電装置と情報を送受信してもよい。これによれば、通信用の回線を別に設ける必要がないため、構成を簡素化することができ、システム導入時の手間を減らすことができる。また、一般に燃料電池の出力はノイズが少ないので、通信環境の面でも有利である。

このシステムは、前記メンテナンス情報をユーザへ提示する表示部を含んでもよい。冷暖房機のフィルタの清掃など、保守業者に依頼するまでもなくユーザ自身が実施できる程度のメンテナンスであれば、ユーザへ実行を指示してもよい。保守業者にメンテナンスを依頼する場合であっても、ユーザへその旨を提示することが望ましい。

このシステムは、ネットワークと通信する通信部をさらに含み、複数の分散発電システムを統括的に制御する管理装置へ、前記ネットワークを介して前記メンテナンス情報を送信してもよい。

本発明の別の態様は保守システムに関する。このシステムは、発電装置を有し当該発電装置に接続された受電装置へ給電する分散発電システムであって、前記受電装置の電力消費状況をもとに前記受電装置に関するメンテナンス情報を生成する分散発電システムに、ネットワークを介して接続された管理装置を含み、前記管理装置は、前記発電装置から給電を受ける受電装置に関するメンテナンス情報を前記分散発電システムから取得し、そのメンテナンスを担当する主体へ通知する。

本発明のさらに別の態様も保守システムに関する。このシステムは、発電装置を有し当該発電装置に接続された受電装置へ給電する分散発電システムであって、前記受電装置の電力消費状況をもとに前記受電装置に関するメンテナンス情報を生成する分散発電システムと、前記分散発電システムにネットワークを介して接続され、前記受電装置のメンテナンスを管理する管理主体と、前記受電装置の保守を担当する保守主体とを含み、前記管理主体は、前記分散発電システムから前記受電装置に関するメンテナンス情報を取得し、そのメンテナンス情報を前記保守主体へ通知する。

本発明のさらに別の態様も保守システムに関する。このシステムは、発電装置を有し当該発電装置に接続された受電装置へ給電する分散発電システムであって、前記受電装置の電力消費状況をもとに前記受電装置に関するメンテナンス情報を生成する分散発電システムと、前記分散発電システムにネットワークを介して接続され、前記受電装置のメンテナンスを管理する管理主体と、前記受電装置の保守を担当する保守主体とを含み、前記管理主体は、前記受電装置の稼動状況に関する情報を前記分散発電システムから取得し、その情報に基づいて必要なメンテナンス情報を生成し、そのメンテナンス情報を前記保守主体へ通知する。

保守主体は、前記受電装置の製造主体、販売主体、および修理主体の少なくとも１つを含み、管理主体は、それらの中から前記メンテナンス情報を通知する保守主体をユーザの利便性の面から選択してもよい。たとえば、保守主体の料金、迅速さ、サービス性、担当地域などを考慮して通知する保守主体を選択してもよい。

保守主体は、前記メンテナンス情報をもとに、ユーザへ前記受電装置に関する保守情報または広告情報を提供してもよい。たとえば、受電装置の製造主体が、受電装置に施すべきメンテナンス作業をユーザへ提示してもよい。また、受電装置の寿命が来たと判断されたときに、ユーザへその製品の広告情報を提供してもよい。

本発明のさらに別の態様は保守方法に関する。この方法は、発電装置を有する分散発電システムから給電を受ける受電装置の稼動状況を監視し、その受電装置のメンテナンスの要否を判定し、メンテナンスが必要と判定されたときその内容に応じて適切な保守主体を選択し、その保守主体に保守の依頼通知を発する。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、分散型の発電システムから給電される家電装置に対して、利便性の高い保守技術を提供することができる。

図１は、実施の形態に係る保守システム１０の全体構成を示す。同図は一般的な電子ネットワークを示し、送電のためのネットワークを示すものではない。保守システム１０において、ユーザの住宅やビルに設けられた複数の分散発電システム１２は、それぞれインターネット１６に接続されている。分散発電システム１２は、安定かつ高効率の発電を期待できる燃料電池システムを備え、テレビジョン受像機１３ａ、ラジオ受信機１３ｂ、エアーコンディショナー１３ｃなどの受電装置１３へ給電線を介して電力を供給する。これらの受電装置１３のメンテナンスを管理する管理装置２０、受電装置１３の製造業者の端末２６、販売業者の端末２７、および修理業者の端末２８も、それぞれインターネット１６に接続されている。製造業者、販売業者、および修理業者は、部品および装置本体の販売、交換、点検、故障時の問い合わせなど、何らかの形で受電装置の保守に関わる。

保守システム１０において、分散発電システム１２または管理装置２０が各受電装置１３の稼動状況を逐次取得し、その状態を診断する。本実施形態では、分散発電システム１２が受電装置１３を監視する例について説明する。分散発電システム１２は、受電装置１３の電力消費状況や、受電装置１３が出力した動作情報を取得し、メンテナンスが必要であると判断したときに、受電装置１３を直接制御するか、または、管理装置２０へメンテナンスを依頼する。管理装置２０は、メンテナンスの内容や、保守主体の特性、担当地域などを考慮して適切な保守主体をひとつ乃至複数選択し、メンテナンス情報として通知する。

このようなビジネスモデルにより、受電装置１３の故障を未然に防ぎ、また、故障が発生した場合であっても迅速に対応することができる。この点は、ユーザにとって大きなメリットとなる。さらに、製造業者、販売業者、修理業者などの保守主体にとっても、次のようなメリットがある。まず、受電装置１３のメンテナンス情報を随時取得することで、保守内容をさらに明確に、かつ早く把握できるため、保守作業の効率化を図ることができる。また、管理主体にメンテナンス依頼の受付を代行してもらうので、営業コストの低減、および顧客の確保にもつながる。さらに、受電装置１３の使用状況を把握することができるので、ユーザの買い替え時に新製品の広告を提供するなど、効果的なマーケティングに利用することもできる。このように、本実施形態のビジネスモデルの構築には大きな意義がある。

図２は、分散発電システム１２の構成を示す。燃料電池システム３０は、天然ガスやメタノールなどと上水から生成した水蒸気を反応させて水素を得る改質器３４と、その水素と酸素を反応させて水と直流電圧を得る燃料電池３６と、その電圧を交流に変換するインバータ３８と、それらを制御する制御部３２を備える。制御部３２は、また、受電装置１３の稼動状況を監視し、そのメンテナンス情報を生成する。

インバータ３８が出力した交流電圧は、給電線を介して受電装置１３へ供給される。受電装置１３と制御部３２は、給電線に信号を重畳させることにより互いに情報を送受信する。

通信部５６は、制御部３２が生成した受電装置１３のメンテナンス情報を、インターネット１６を介して管理装置２０へ伝達する。このとき、メンテナンス情報に加えて、受電装置１３の稼動状況を示す情報を管理装置２０へ伝達してもよい。表示装置４０は、メンテナンス情報をユーザへ提示する。

図３は制御部３２の構成を示す。制御部３２の機能は、ハードウエア的には、マイクロコンピュータ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的には受電装置制御プログラムなどによって実現されるが、ここではそれらの連携による機能のみをブロックで示している。したがって、これらの機能ブロックがハードウエアとソフトウエアのいろいろな組合せで実現できることは当業者には理解されるところである。

診断テーブル７４は、受電装置１３の動作状況を示す情報と、そのときの受電装置１３の状態を示す診断ＩＤとを対応づけて格納する。図４はその構成例であり、受電機器種別欄２００、消費電力欄２０２、エラーコード欄２０４、および診断ＩＤ欄２０６が設けられている。診断に必要な情報の種類は、受電装置１３の種類によっても異なるので、これ以外にも適宜必要な欄を設ければよい。一例として、受電機器種別が「冷蔵庫」の場合、消費電力が「高」の状態であれば、エラーコードの如何に関わらず診断ＩＤ「０００１」の状態にあることが記録されている。

メンテナンス情報テーブル７６は、診断ＩＤと、そのときに必要なメンテナンスの情報とを対応づけて格納する。図５はその構成例であり、診断ＩＤ欄２２０、通知先欄２２２、および通知内容欄２２４が設けられている。一例として、診断ＩＤが「０００１」であるとき、「冷蔵庫」に対して「電源オフ」を指示することが記録されている。

メンテナンス履歴データベース７８は、受電装置１３に対して実施されたメンテナンスの履歴を格納する。図６はその構成例であり、受電機器種別欄２４０、使用開始日欄２４２、およびメンテナンス履歴欄２４４が設けられている。メンテナンス履歴欄２４４は、メンテナンスが行われるごとに追加され、それぞれが実施日欄２４６および内容欄２４８を有する。一例として、受電機器種別「冷蔵庫」の使用開始日は「２００１年４月２０日」、第１回目のメンテナンスの実施日は「２００１年５月１日」、その内容は「初期点検」であることが記録されている。

動作状況取得部６０は、給電線を介して各受電装置１３の動作状況を逐次取得する。動作状況は、受電装置１３の電力消費状況、制御パラメータ、エラーメッセージなどであってもよい。取得する情報の種類、内容、頻度は、保守を行うのに十分な程度であればよく、受電装置１３の種類に応じて設計されてもよい。受電装置１３が情報を出力する機能を有している場合には、それらの情報を逐次取得して状態を把握してもよい。そうでない場合には、電力消費状況から受電装置１３の状態を推測してもよい。動作状況取得部６０が取得した情報は、必要に応じて図示しないデータベースに格納されてもよい。

診断部６２は、動作状況取得部６０にて取得された情報に基づいて、診断テーブル７４を参照し、各受電装置１３の状態を診断する。メンテナンス情報生成部６４は、診断部６２の診断結果に基づいて、必要なメンテナンス情報を生成する。このとき、必要なメンテナンスの度合いに応じてメンテナンス情報の通知先を決定する。たとえば、フィルタの清掃などの軽度なメンテナンスの場合には表示装置４０を介してユーザへ通知し、受電装置１３の制御パラメータの変更のみで対処できる場合には受電装置１３を直接制御し、部品の交換など人手が必要な場合には管理装置２０へ通知する。適切なメンテナンス経路を選択することで、作業の高速化、効率化を図る。生成されたメンテナンス情報はメンテナンス履歴データベース７８へ格納され、次回以降のメンテナンスの参考にされる。

受電装置１３へ制御パラメータの変更を指示する場合は、指示部６６が受電装置１３へ指示を出す。指示部６６は、受電装置１３の動作状況がより良好になるようにプリセットされたパラメータテーブルを有していてもよい。

管理装置２０へ保守を依頼する場合は、通知部６８が生成されたメンテナンス情報を管理装置２０へ通知する。通知部６８は、ＴＣＰ／ＩＰなどの通信プロトコルによりメンテナンス情報を通知してもよいし、電子メールなどにより通知してもよい。メンテナンスが必要な部品を特定できている場合にはその部品名を通知し、特定できていない場合にはメンテナンスが必要な旨のみを通知してもよい。このように数段階の通知レベルを設けておくことで、保守会社はメンテナンスに必要な時間や人材を予測してスケジュールをたてることができる。また、交換すべき部品を予め用意したり、原因が特定されていない場合は技術力の高い担当者を派遣したりするなど、保守会社のサービス性を向上させることができる。

メンテナンス情報生成部６４は、メンテナンス履歴データベース７８を参照して、その受電装置１３の経時変化に関する情報を読み出し、必要なメンテナンス情報を特定してもよい。たとえば、冷暖房機について、使用開始日から１年経過しており、かつメンテナンス履歴にフィルタの交換が記録されていない場合には、フィルタを交換するよう指示する旨のメンテナンス情報を生成してもよい。これにより、耐用期限を過ぎた部品を使用することによる故障や出力低下を未然に防ぐことができる。装置自体の買い替えを提案してもよい。

メンテナンス情報生成部６４は、受電装置１３の異常を検知したときに、受電装置１３への給電を停止してもよい。これにより、異常事態に起因する事故などの発生を未然に防ぐことができる。

情報取得部７０は、管理装置２０、製造業者端末２６、販売業者端末２７、および修理業者端末２８から送信された情報を取得する。この情報は、受電装置１３の保守に関する情報、たとえば、清掃方法などであってもよい。また、受電装置１３に関する広告情報であってもよい。表示部７２は、メンテナンス情報生成部６４が生成したメンテナンス情報や、情報取得部７０が取得した各種情報を、表示装置４０へ表示する。

図７は、管理装置２０の構成の一例を示す。この構成もマイクロコンピュータをはじめとするハードウエアおよびソフトウエアの組合せで実現される。通信部８０は、インターネット１６を介して他の装置と通信する。

業者データベース８８は、受電装置１３の保守主体である製造業者、販売業者、および修理業者の情報を格納する。図８はその構成例であり、業者ＩＤ欄２６０、業者種別欄２６２、業者名欄２６４、料金欄２６６、サービス欄２６８、規模欄２７０、および担当地域欄２７２が設けられている。本実施形態では、各業者の保守に必要な料金の高低、保守サービスの良し悪し、規模の大小を５段階評価で格納している。一例として、業者ＩＤ「０００１」の業者の情報として、業者種別「製造業」、業者名「Ａ社」、料金ランク「４」、サービスランク「２」、規模ランク「５」、担当地域「Ｚ市」が記録されている。

メンテナンス情報取得部８２は、管理装置２０から各受電装置１３のメンテナンス情報を取得する。通知先選択部８４は、業者データベース８８を参照してメンテナンス情報を通知すべき業者を選択する。このとき、料金、サービス、規模、担当地域などの観点からユーザの利便性を検討し、最適な業者を選択する。ユーザの希望する条件を予め受け付け、図示しないユーザデータベースに格納しておいてもよい。たとえば、料金が安いことを重視するユーザに対して、地域内で料金の最も安い業者を選択してもよい。通知部８６は、選択された業者にメンテナンス情報を通知する。なお、ユーザに選択の余地を残し、好ましい２、３の業者までの絞り込みに留めても良い。

図９は、修理業者端末２８の構成の一例を示す。この構成もマイクロコンピュータをはじめとするハードウエアおよびソフトウエアの組合せで実現される。通信部９０はインターネット１６を介して他の装置と通信する。

メンテナンス情報取得部９２は、管理装置２０から各受電装置１３のメンテナンス情報を取得する。スケジュール管理部９４は、メンテナンス情報に基づいて、保守担当者のスケジュールや最適ルートを算出する。スケジュール管理部９４は、メンテナンスの内容やユーザ宅の住所などをもとに、各担当者に担当を割り振る。メンテナンス情報が、故障の原因が特定されていない通知レベルであったときは、技術力の高い技術者にメンテナンスを担当させてもよい。スケジュール管理部９４は、さらに、メンテナンス情報の通知レベルや内容に基づいて、メンテナンスに必要な所要時間を見積もり担当者のスケジュールをたてる。そして、所要時間およびユーザ宅の住所をもとに、その日の担当者の点検ルートを算出し、各担当者へ通知する。このとき、必要な部品や機材を担当者に通知してもよい。これにより、メンテナンス作業の効率を高めることができる。なお、ユーザの住所などの情報は、図示しないユーザデータベースに格納しておいてもよい。

スケジュール管理部９４は、ユーザへメンテナンスを希望する日時を問い合わせてもよい。そして、ユーザの希望日時に基づいて担当者のスケジュールを調整してもよい。これにより、ユーザの不在時に担当者が訪問する事態を減らし、作業効率をさらに向上させることができる。

在庫管理部９６は、メンテナンス情報をもとに、必要な部品の数を算出する。そして、部品の在庫数を格納した在庫データベース１００を確認し、部品が不足した場合にはその部品の発注を指示する。部品の発注は、販売業者の端末２７または製造業者の端末２６へオンラインにて行ってもよいし、オフラインにて行ってもよい。

メンテナンス結果通知部９８は、担当者が行ったメンテナンス作業の内容と、受電装置１３の状況とを、管理装置２０および分散発電システム１２へ通知する。

図１０は、製造業者端末２６の構成の一例を示す。この構成もマイクロコンピュータをはじめとするハードウエアおよびソフトウエアの組合せで実現される。通信部１０８はインターネット１６を介して他の装置と通信する。

メンテナンス情報取得部１１０は、管理装置２０から各受電装置１３のメンテナンス情報を取得する。情報通知部１１２は、メンテナンス情報をもとに、適切なヘルプ情報をヘルプデータベース１１４から読み出して、分散発電システム１２へ通知する。また、受電装置１３の種類に応じた広告情報を広告データベース１１６から読み出して分散発電システム１２へ通知する。これにより、受電装置１３の使用状況に応じて、的確なヘルプ情報および広告情報を提供することができる。

販売業者端末２７は、その業者の業務範囲に応じて、図９に示した修理業者端末２８の構成および図１０に示した製造業者端末２６の構成を適宜組み合わせて構成される。製造業者端末２６についても、その業者が保守サービスを行っている場合には、図９に示した修理業者端末２８の構成をさらに有していてもよい。修理業者端末２８についても同様である。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下そうした例をいくつか述べる。

管理会社１８と各業者端末の間は専用回線で接続されてもよい。その設計は両者間の通信に要求されるセキュリティの度合いにもよる。

ユーザの家庭内で家電装置がネットワークで接続され、ホームサーバを介してインターネットに接続されるような構成であってもよい。このとき、電力線を利用してネットワークが構築されてもよい。分散発電システム１２がホームサーバとして機能してもよい。

本実施形態では診断およびメンテナンス情報の生成機能を各分散発電システム１２に設けたが、これらの機能を管理装置２０に設け、管理装置２０にて一元管理してもよい。これにより、診断ソフトのバージョンアップなどの保守が容易になる。

分散発電システム１２は燃料電池システム３０によって発電したが、当然これは他の発電装置であってよい。例えば太陽電池システムでも一般には電力消費のピークである真夏の昼間に発電能力が高くなるため利用可能である。分散発電システム１２を広い範囲に分散させれば、天候の影響を小さくすることも可能である。また、当然ながら、分散発電システム１２としていろいろなタイプの発電装置が混在してもよい。

実施の形態に係る保守システムの構成図である。 実施の形態に係る分散発電システムの構成図である。 分散発電システム内の制御部の構成図である。 分散発電システム内の診断テーブルの構成図である。 分散発電システム内のメンテナンス情報テーブルの構成図である。 分散発電システム内のメンテナンス履歴データベースの構成図である。 実施の形態に係る管理装置の構成図である。 管理装置内の業者データベースの構成図である。 修理業者端末の構成図である。 製造業者端末の構成図である。

符号の説明

１０ 保守システム、 １２ 分散発電システム、 １３ 受電装置、 ２０ 管理装置、 ２６ 製造業者端末、 ２７ 販売業者端末、 ２８ 修理業者端末、 ３０ 燃料電池システム、 ３２ 制御部。

Claims (5)

1. 発電装置を有し当該発電装置に接続された受電装置へ給電する分散発電システムであって、前記受電装置の電力消費状況をもとに前記受電装置に関するメンテナンス情報を生成する分散発電システムに、ネットワークを介して接続された管理装置を含み、
   前記管理装置は、前記発電装置から給電を受ける受電装置に関するメンテナンス情報を前記分散発電システムから取得し、そのメンテナンスを担当する主体へ通知することを特徴とする保守システム。
2. 発電装置を有し当該発電装置に接続された受電装置へ給電する分散発電システムであって、前記受電装置の電力消費状況をもとに前記受電装置に関するメンテナンス情報を生成する分散発電システムと、
   前記分散発電システムにネットワークを介して接続され、前記受電装置のメンテナンスを管理する管理主体と、
   前記受電装置の保守を担当する保守主体とを含み、
   前記管理主体は、前記分散発電システムから前記受電装置に関するメンテナンス情報を取得し、そのメンテナンス情報を前記保守主体へ通知することを特徴とする保守システム。
3. 発電装置を有し当該発電装置に接続された受電装置へ給電する分散発電システムであって、前記受電装置の電力消費状況をもとに前記受電装置に関するメンテナンス情報を生成する分散発電システムと、
   前記分散発電システムにネットワークを介して接続され、前記受電装置のメンテナンスを管理する管理主体と、
   前記受電装置の保守を担当する保守主体とを含み、
   前記管理主体は、前記受電装置の稼動状況に関する情報を前記分散発電システムから取得し、その情報に基づいて必要なメンテナンス情報を生成し、そのメンテナンス情報を前記保守主体へ通知することを特徴とする保守システム。
4. 前記保守主体は、前記受電装置の製造主体、販売主体、および修理主体の少なくとも１つを含み、
   前記管理主体は、それらの中から前記メンテナンス情報を通知する保守主体をユーザの利便性の面から選択することを特徴とする請求項２または３に記載の保守システム。
5. 前記保守主体は、前記メンテナンス情報をもとに、ユーザへ前記受電装置に関する保守情報または広告情報を提供することを特徴とする請求項２から４のいずれかに記載の保守システム。

Images