JP5194435B2 - 電力供給システム、電力供給方法、電力供給プログラム及びサーバ - Google Patents

Description

本発明は、例えば、サーバとクライアントとの間で情報のやり取りをしながらサーバからクライアントへ電力を供給する電力供給システム、電力供給方法、電力供給プログラム及びサーバに関する。

先に、電源消費ブロックや電源供給ブロックに、電源バス接続ポートと、データバス接続ポートと、データバス接続ポートを伝送されるデータを受け取る手段と、受け取ったデータに基づいて電力の消費や電源の供給を制御する手段とを設けた電源システムが本発明者から提案されている(特許文献１参照)。これにより、複数の電源供給源と複数の電源消費者とを一つの共通のバスライン上に着脱可能とするものである。
特開２００１−３０６１９１号公報

上述した特許文献１に記載の技術では、バスシステムに接続されている各ブロックのオブジェクトがデータバスラインを介して相互に状態データ等のやり取りを行うが、通信の上位層と下位層を決めるレイヤーや各ブロックのオブジェクトのアドレス割当が定められていないため、信号同士の競合が発生する可能性があり、競合に勝った方のみが通信を行うこととなる。これにより、同じタイミングで電源供給の要求があった場合に同じ電圧の電源を別のブロックに供給することができないという不都合があった。

また、各ブロックのオブジェクトは、他のブロックのオブジェクトからの要求に基づいて状態データを生成して回答するが、状態データの生成は個々の要求に対して個別に行われるため、すべての供給可能な電源仕様を供給していないため電源供給を要求するブロックが適合可能な条件を探すことができないという不都合があった。

そこで、本発明は、同じタイミングで電源供給の要求があっても同じ電圧の電源を別のブロックにも供給することができ、電源供給を要求するブロックが適合可能な条件を探すことができるようにすべての供給可能な電源仕様を供給する電力供給システム、電力供給方法、電力供給プログラム及びサーバを提供することを目的とするものである。

上記課題を解決し、本発明の目的を達成するため、本発明の電力供給システムでは、サーバは、クライアントとの間の情報のやり取り及びクライアントとの間での電力の供給の同期を取り、クライアントとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、サーバのアドレスを含んだ同期パケットを情報スロットのタイミングで発信する機能を備え、同一のラインに他のサーバが接続された時には、同期を取っているサーバからの同期パケットの受信を他のサーバが検出することで、他のサーバは同期を取るサーバとはならないものである。

また、本発明の電力供給方法では、サーバは、クライアントとの間の情報のやり取り及びクライアントとの間での電力の供給の同期を取り、クライアントとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、サーバのアドレスを含んだ同期パケットを情報スロットのタイミングで発信し、同期を取っている他のサーバが接続されているのと同一のラインに接続された時には、他のサーバからの同期パケットの受信を検出することで、同期を取るサーバとはならないものである。

また、本発明の電力供給プログラムでは、サーバのコンピュータに対して、クライアントのコンピュータとの間の情報のやり取り及びクライアントのコンピュータとの間での電力の供給の同期を取り、クライアントのコンピュータとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、サーバのコンピュータのアドレスを含んだ同期パケットを情報スロットのタイミングで発信する機能と、同期を取っている他のサーバのコンピュータが接続されているのと同一のラインに接続された時には、他のサーバのコンピュータからの同期パケットの受信を検出することで、同期を取るサーバとはならない機能とを実行させるものである。
また、本発明のサーバでは、クライアントとの間の情報のやり取り及びクライアントとの間での電力の供給の同期を取り、クライアントとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、サーバのアドレスを含んだ同期パケットを情報スロットのタイミングで発信する機能と、同期を取っている他のサーバが接続されているのと同一のラインに接続された時には、他のサーバからの同期パケットの受信を検出することで、同期を取るサーバとはならない機能とを備えるものである。

本発明の電源給システム、電力供給方法、電力供給プログラム及びサーバによれば、以下の作用をする。
まず、電源供給源（電源サーバ）と電源受給者（クライアント）は電源バスのうちの少なくとも２本の電源及び情報線を共有し、サーバ、クライアント間でお互いの電源仕様に関する情報をあらかじめ交換し、このネゴシエーションが確立した時点で電源供給、受給を開始する。電源の供給と情報のやり取りは同一の電源バスを共有し、情報スロット及び電力スロットにより周波数帯域分割によって分離される。

サーバとクライアントは電源バスに接続されるが、電源仕様の異なる複数のサーバ、複数のクライアントが異なる電源仕様の電源を供給可能にバスラインに接続される。サーバとクライアントはネゴシエーションの結果、論理的に一対一に通信可能に接続されるがこの間の電源仕様が通信によりダイナミックに変更可能である。

サーバは電源バスに対して定期的に同期パケットを出力し、これによりクライアントがサーバの存在を知るとともにアドレス決定のきっかけとなる。サーバが電源バスのアドレス管理を行い、クライアントは電源バスに接続されるとアドレスをサーバより取得し、電源バスに接続されている限りこのアドレスが有効となる。複数のサーバが電源バスに接続されている時は、そのうち一つのサーバがアドレス管理、電力スロットの管理を行う。

本発明によれば、サーバは、クライアントとの間の情報のやり取り及びクライアントとの間での電力の供給の同期を取り、クライアントとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、サーバのアドレスを含んだ同期パケットを情報スロットのタイミングで発信するので、同じタイミングで電源供給の要求があっても同じ電圧の電源を別のクライアントにも供給することができる。

以下に、本発明の実施の形態について、適宜、図面を参照しながら詳細に説明する。
本発明の実施の形態は本発明者の先願である特許文献１（電源サーバ、電源クライアントおよび電源バスシステム）にネットワーク技術による通信の手順を応用し、実設計に際し、既存の技術や考え方が容易に応用できるようにしたものである。従って上記特許文献１との主たる相違点は、ネットワークプロトコルをベースとしたサーバ、クライアント間のネゴシエーション方式の採用、電源と情報を一対のバスラインで行うための周波数分割が中心となる。

まず、本発明の実施の形態の電力供給システムのハードウエア構成例について説明する。
図１に電源サーバのブロック図を示す。
図1において、電源サーバ１は大きく分けて３つの機能部分から構成される。AC/DC部２と記してある部分は、商用電源７を処理して後述するクライアント１１に供給可能な形式に変換する交流／直流変換部分である。電源サーバ１の形式としては電圧源、電流源型の違い、供給する電流としては直流、交流の違い、供給される電圧、電流に関しては安定化、非安定化の違い等が存在する。本システムでは、これらすべての電源の共存を可能であるが、ここでは最も一般的な電圧源型、直流電源で（さらに３０V程度以下の）比較的低電圧の電源を基本として説明していく。
また、このクライアント１１に供給されるAC/DC部２から出力される主供給電源となる部分は、DCの場合でも、ある一種類の電圧のみならす、可変電圧（クライアントとのネゴシエーションの結果電圧が決定される）でもかまわない。

AC/DC部２から出力される主供給電源と電源バス８の間には少なくとも一つのスイッチ（SW)６が挿入され、電源サーバ１の電力がいきなり電源バス８に出力されることの無いように電源供給が制御される。電源サーバ１はその電力仕様を内部情報としてコントローラ3のメモリに記憶している。また、この情報の記憶やクライアント１１との情報のやり取り、給電の開始や停止といった制御のためにコントローラ３を有している。このコントローラ３はマイクロプロセッサと周辺回路より構成される。このコントローラ３はメモリに記憶された制御プログラムにより電力供給の各種機能を実行するコンピュータである。

電源サーバ１とクライアント１１との間では共通の電源バス８を介して情報通信が実施されるが、この情報は電源の周波数帯域（DCならば直流、ACならば商用周波数および、例えば４００Hz程度の低周波）に対して混信がないように十分高い周波数の交流信号を用いて通信される。この通信信号を電源バス８に接続して通信を可能とするモデム４が設けられていて、代表的なものとしてはいわゆる電力線モデムの技術がそのまま流用可能である。

しかしながら、周波数による分離は容易（電源はDCないしは低周波交流なので）であるため、専用設計によるモデムも困難ではない。特に、電源バス８の場合、基本的にバスラインは商用電灯線とは分離されており、隣家との共通信号線となる確率は低く、従って情報の暗号化等も基本的には必要ない。つまり電力線モデムに組み込まれているような暗号化機能も不要であることが多く、簡単なモデム（本来の意味での変復調装置）で十分である。このモデム４による通信信号に関してはバスラインに常時接続される。また、図１でスイッチ（SW)６に直列接続されるのは、電力パケットと通信パケットを分離するためのフィルタ（L）５であり、定数等は通信パケットの変調周波数を勘案して決定される。

一方、クライアント１１の構成もサーバ１に非常によく似ている。
図２にクライアント１１のブロック図を示す。
図２において、電源サーバ１では商用電源７から電力を得るが、クライアント１１では電源バス８を介して電源サーバ１から受電した電力を負荷１８に供給するという構成が一番大きな違いである。クライアント１１は電源サーバ１からの電力仕様を内部情報としてコントローラ１3のメモリに記憶している。また、この情報の記憶や電源サーバ１との情報のやり取り、受電の開始や停止といった制御のためにコントローラ１３を有している。このコントローラ１３はマイクロプロセッサと周辺回路より構成される。このコントローラ１３はメモリに記憶された制御プログラムにより電力受電の各種機能を実行するコンピュータである。

また、受電電力は時間スロットに区切られた電力パケットであり、クライアント１１が複数存在する場合等、連続的にサーバ１から供給される訳にはいかない。したがって、通常は間欠的に供給される電力を蓄えておく蓄電手段が必要で、図２ではバッテリ１９と記されたものがこの蓄電手段であり、二次電池の場合を示した。この蓄電手段としては二次電池以外に電気二重層コンデンサ、大きな容量の電解コンデンサ等が使用可能である。

１８と記してあるものは、実際に供給される電力を消費する負荷である。図２ではクライアント１１のコントローラ１３がバッテリ１９の電圧のみを監視しながら、モデム１４から電源バス８を介してサーバ１と通信し、サーバ１からの電力供給の開始および停止を行う場合を示した。これに限らず、負荷１８からの電力消費情報を直接コントローラ１３に伝達し、サーバ１からの電力供給の開始および停止を制御することも当然可能である。
具体的には、サーバ１からの電力供給が開始されて、バッテリ１９に電圧が充電されるときは、充電系のスイッチ１６がオンとなり、放電系のスイッチ１７がオフとなる。また、サーバ１からの電力供給が停止されて、バッテリ１９の電圧が放電されるときは、充電系のスイッチ１６がオフとなり、放電系のスイッチ１７がオンとなる。

サーバ１から電源バス８のラインに出力されるものは電力パケットと情報パケットであるが、これは周波数分離をしている関係で基本的にお互い独立である。しかしながら電力パケットの投入タイミングや切断タイミングではシステムのキャパシタンス、インダクタンスによりノイズが発生しやすいので、この間は通信を避けた方が望ましい。また、電力パケットはエネルギー伝送という性格から、あまり細かく（時間的に）分割しても使用勝手がわるく、本実施の形態例では概略一秒を電力パケットの単位とした。

さらに電力パケットに関しては、これを受電するクライアント１１のコントローラ１３がスイッチ１６，１７を制御する都合上、電力パケットに同期し、かつ実際の電力パケットの前に最低限でもクライアント１１のアドレスがサーバ１では必要である。これらの状況を勘案し図３に示す電源バス上の電源パケット及び情報パケットのタイムスロットの形式とした。

図３において、電源サーバ１は自身の電源が投入されると、図３のような情報スロット３１及び電力スロット３２を発生し、これに基づいた同期パケットを情報スロット３１のタイミングで発信し続ける。なお、電源サーバ１にとっては電源バス８のバスラインのクライアント１１の接続の有無は不明であり、電源サーバ１に電源バス８のバスラインを接続しただけでは同期パケットのみの送信状態である。この状態でクライアント１１が電源バス８に接続されると、クライアント１１は情報スロット３１の電源サーバ１からの同期パケットを認識し、電源サーバ１に対して、レスポンスを返す。

情報スロット３１の電源サーバ１からの同期パケットには電源サーバ１のアドレスが含まれているので、電源サーバ１がレスポンスを受信した時点で、電源システムにおけるアドレスの確定は一応完了である。その後、電力スロット３２において情報スロット３１でアドレスの確定がされた３９で示す第１のクライアントに対して電力パケットの供給が行われる。同様に、情報スロット３３において４０で示す第２のクライアントが電源サーバ１からの同期パケットに含まれている電源サーバ１のアドレスにレスポンスを返し、電源サーバ１がレスポンスを受信して電源システムにおけるアドレスの確定が完了する。その後、電力スロット３４において情報スロット３３でアドレスの確定がされた４０で示す第２のクライアントに対して電力パケットの供給が行われる。

引き続いて、情報スロット３５において３９で示す第１のクライアントが電源サーバ１からの同期パケットに含まれている電源サーバ１のアドレスにレスポンスを返し、電源サーバ１がレスポンスを受信して電源システムにおけるアドレスの確定が完了する。その後、電力スロット３６において情報スロット３５でアドレスの確定がされた３９で示す第１のクライアントに対して電力パケットの供給が行われる。

同様に、情報スロット３７において４０で示す第２のクライアントが電源サーバ１からの同期パケットに含まれている電源サーバ１のアドレスにレスポンスを返し、電源サーバ１がレスポンスを受信して電源システムにおけるアドレスの確定が完了する。その後、電力スロット３８において情報スロット３７でアドレスの確定がされた４０で示す第２のクライアントに対して電力パケットの供給が行われる。

また、上述した例に限らず、ある情報スロットの情報のやり取りによりその電力スロットで電源サーバ１から電源供給を受けたクライアント１１が、それ以降の情報スロットの情報のやり取りによりその電力スロットで電源サーバ１と同様に他のクライアントに対して電源供給をするようにしてもよい。これにより、満充電状態のクライアントから未充電状態のクライアントに対して電源供給を行うことができる。

インターネットではIP（Internet Protocol）パケットが異なったネットワーク上（イーサネット（登録商標）やトークンリングその他）をルーティングされていくためDNS（domain name server）やアドレス自動割当のためのDHCP（Dynamic Host Configuration Protocol）など、さまざまなプロトコルが必要であるが、本システムでは一本のバスライン上と仮定しているため、アドレス（サーバやクライアントID)に関しては、あらかじめ一意に割り付けておけばよく、ネットワーク（バスライン）に参加した時にサーバ、クライアント間でアドレスの交換ができれば十分である。

次に、通信および制御プロトコル例について説明する。
ここでは、電源供給システムにおけるサーバ間、サーバ-クライアント間の通信プロトコルの概要について説明する。
まず、通信プロトコルの基本機能について説明する。
図４に本システムにおける同期パケット、情報パケット、電力パケットのやりとりの一例を示す。
上述した様に、本システムで利用するパケットは電力パケット４６、５０、５２と情報パケット４２、４３，４４、４５、４８，４９の２種類に大別することができる。図４において、電力パケット４６、５０、５２は、電源サーバ１からクライアント１１へ提供される電力エネルギーをパケット化したものである。情報パケット４２、４３，４４、４５、４８，４９は、電力パケット４６、５０、５２を送るために必要な情報交換を行うために利用されるパケットであり、用途によって異なるタイプがある。

本システムではシステム上に存在する電源サーバ１の一つが同期サーバとなる。同期サーバはシステム上に存在するすべてのノードが同一周期で動作できる様に、一定の時間間隔で同期パケット４１，４７，５１を転送する。もし同期サーバがなんらかの理由でシステムから離脱した場合、システム上に存在する別の電源サーバ１が同期サーバとなり、同期パケット４１，４７，５１を転送する。

例えば、現在の仕様では同期パケット４１，４７，５１の送信間隔は 1.1秒としている。この 1.1秒のタイムスロットのうち、0.1秒を情報スロット３１、３３，３５として定義し、1.0秒を電力スロット３２、３４，３６として定義する。本システムでは図３に示した情報スロット３１、３３，３５で電力パケット４６、５０、５２の転送に必要なネゴシエーションを行い、電力スロット３２、３４，３６で電源パケット４６、５０、５２を転送する。

すなわち、本システム上の全てのノード(同期サーバ自体も含む)は、ネットワーク上に流れる同期パケット４１，４７，５１を監視し、同期パケット４１，４７，５１の到着時刻を記録する。そして、同期パケット４１の到着時刻から0.1秒以内に安全に情報パケット４２、４３，４４、４５を送出できる余裕がシステムにある場合は、必要な情報パケット４２、４３，４４、４５を送出する。

もし、安全に情報パケット４２、４３，４４、４５を送出できる余裕がない場合は、次の情報スロット３３まで情報パケット４８，４９の転送を待機させる。次の情報スロット３３を利用したネゴシエーションは、次の電力スロット３４で確実にクライアント１１が期待する電力パケット５０を正しく供給するために行われる。電源サーバ１はクライアント１１や他の電源サーバとのネゴシエーションが終了するまで、電力パケット５０送出することはできない。

次に、上述した電力パケット４６、５０、５２と情報パケット４２、４３，４４、４５、４８，４９の基本パケットフォーマットについて説明する。
図５は、基本パケットフォーマットを示す図である。
本システムで利用するパケットはイーサネット(登録商標)の仕様に準拠したものを利用する。すなわち、図５において、パケットは６バイトの送信アドレスであるソースアドレス５５と６バイトの受信アドレスであるデスティネーションアドレス５４と２バイトのパケットタイプ５６を格納する14バイトのイーサネット(登録商標)ヘッダ５３を持ち、パケットの末尾に４バイトの CRC（Cyclic Redundancy Check）チェックサム５９を持つ。

本システムでは、すべてのノードがユニークな６バイトの MAC（Media Access Control）アドレスをソースアドレス５５又はデスティネーションアドレス５４として持つことを想定している。この MACアドレスを用いて全ての通信が行われる。パケット種別ですパケットタイプ５６は、パケットが電源供給システム用のものであることを示すために利用される。パケット種別に利用される値は、IEEE（Institute of Electrical and Electronic Engineers）で別の機能に規定されていない値であれば問題はない。現在の仕様では、http://standards.ieee.org/regauth/ethertype/eth.txtに規定されていない値である0x88f8を利用している。

また図５において、本システムで利用する全てのパケットは14バイトのイーサネット（登録商標）ヘッダ５３に続き、２バイトの電源パケットヘッダ５７を持つ。電源パケットヘッダ５７は、１バイトのバージョン番号と１バイトのパケットタイプフィールドから構成される。現在の仕様では、バージョン番号フィールドの値は常に0である。パケットタイプフィールドには、電源供給システム用パケットの電源パケット種別を示す値が格納される。現時点では、パケット種別に応じて図６、図７に示したパケット種別とその値が設定されている。

図６において、電源パケット種別６１が同期パケット７１のとき値６２は１であり、ニモ−ニック６３はSyncである。電源パケット種別６１がサーバリクエスト７２のとき値６２は２であり、ニモ−ニック６３はReqServerである。電源パケット種別６１がサーバリプライ７３のとき値６２は３であり、ニモ−ニック６３はRepServerである。電源パケット種別６１が時刻同期７４のとき値６２は４であり、ニモ−ニック６３はTimeSetである。

電源パケット種別６１が電源仕様数リクエスト７５のとき値６２は３２であり、ニモ−ニック６３はReqSvrProfileNumである。電源パケット種別６１が電源仕様数リプライ７６のとき値６２は３３であり、ニモ−ニック６３はRepSvrProfileNumである。電源パケット種別６１が電源仕様リクエスト７７のとき値６２は３４であり、ニモ−ニック６３はReqServerProfileである。電源パケット種別６１が電源仕様リプライ７８のとき値６２は３５であり、ニモ−ニック６３はRepServerProfileである。

電源パケット種別６１が電源仕様確定リクエスト７９のとき値６２は３６であり、ニモ−ニック６３はReqSvrProfileSetである。電源パケット種別６１が電源仕様確定リプライ８０のとき値６２は３７であり、ニモ−ニック６３はRepSvrProfileSetである。電源パケット種別６１が電源仕様新規作成りクエスト８１のとき値６２は３８であり、ニモ−ニック６３はReqSvrProfileMakeである。電源パケット種別６１が電源仕様新規作成リプライ８２のとき値６２は３９であり、ニモ−ニック６３はRepSvrProfileMakeである。

電源パケット種別６１がパケット数制御リクエスト８３のとき値６２は４０であり、ニモ−ニック６３はReqPacketNumである。電源パケット種別６１がパケット数制御リプライ８４のとき値６２は４１であり、ニモ−ニック６３はRepPacketNumである。電源パケット種別６１が送信開始時間設定リクエスト８５のとき値６２は４２であり、ニモ−ニック６３はReqPowerStである。電源パケット種別６１が送信開始時間設定リプライ８６のとき値６２は４３であり、ニモ−ニック６３はRepPowerStである。

電源パケット種別６１が電力パケット停止リクエスト８７のとき値６２は４４であり、ニモ−ニック６３はReqPowerSpである。電源パケット種別６１が電力パケット停止リプライ８８のとき値６２は４５であり、ニモ−ニック６３はRepPowerSpである。電源パケット種別６１がサーバプロファイル変更リクエスト８９のとき値６２は４６であり、ニモ−ニック６３はReqSvrProfileModである。電源パケット種別６１がサーバプロファイル変更リプライ９０のとき値６２は４７であり、ニモ−ニック６３はRepSvrProfileModである。

電源パケット種別６１がネゴシエーションキャンセル９１のとき値６２は４８であり、ニモ−ニック６３はCanselである。電源パケット種別６１が電力パケット数変更リクエスト９２のとき値６２は４９であり、ニモ−ニック６３はReqMorePacketNumである。電源パケット種別６１が電力パケット数変更リプライ９３のとき値６２は５０であり、ニモ−ニック６３はRepMorePacketNumである。電源パケット種別６１が電力パケット９４のとき値６２は１２９であり、ニモ−ニック６３はない。

このうち、同期パケット７１、サーバリクエスト７２、サーバリプライ７３は電源パケットヘッダ５７に続くペイロード５８を持たない。これら３つのパケットのフォーマットの相違は、電源パケットタイプフィールドの値のみである。それ以外のパケットのフォーマットについては、後述するアプリケーションインターフェース例で解説する。

次に、クライアント１１による電源サーバ１の検出について説明する。
電源供給システムに接続されたクライアント１１は、まず電源サーバ１の検出を行う必要がある。電源サーバ１の検出は、クライアント１１となるノードが、サーバリクエスト７２を電源バス８のネットワーク上に送信することで行われる。このサーバリクエスト７２の送信先アドレスは、ブロードキャストアドレスである 0xFFFFFFに設定され、ネットワークに接続されたすべてのノードがこのパケットを受信する。

パケットを受信したノードのうち、電源サーバ１の機能を持つノードは、サーバリプライ７３をサーバリクエスト７２を送信したクライアント１１のノードに対して返送する。サーバリプライ７３を受信したクライアント１１のノードは、サーバリプライ７３の送信先アドレスから、電源サーバ１のアドレスを取得することができる。

ネットワーク上に複数の電源サーバ１が存在する場合、クライアント１１のノードは複数のサーバリプライ７３を受信することになる。このような場合、クライアント１１は電源サーバ１のリストを作成し、任意の電源サーバ１を１つ選んで、電源供給のネゴシエーションを開始する。もし、ネゴシエーションが失敗に終った場合、クライアント１１のノードは電源サーバ１のリストを参照し、ネゴシエーションをしていない電源サーバ１を選び、再度ネゴシエーションを試みる。電源サーバ１の検出以降のネゴシエーションの詳細については、後述するアプリケーションインターフェース例において説明する。

次に、複数のクライアントへの同時電力供給について説明する。
１つの電力スロット３２で送信できる電力パケットは１つしかない。このため、電源サーバ１が複数のクライアント１１に対して同時に電力を供給する場合は、ラウンドロビン形式で各クライアント１１に公平に電力スロット３２を割り当てパケットを転送する。あるクライアント１１に特別なプライオリティを設定する場合は、電力スロット３２の割り当てに重み付けラウンドロビン方式を用いることで対応できる。

次に、具体的な実施の形態例としてのアプリケーションインターフェース（API）例について説明する。
ここまでで、電源サーバ１およびクライアント１１によるアドレス確定、通信ラインの確保、電源バス８への任意タイミングでの参加、離脱メカニズムが用意できたことになる。この状況により、電源サーバ１、クライアント１１は始めてお互いにネゴシエーション可能となるわけで以下、電源サーバ１、クライアント１１間での通信に使用するAPI群について説明する。これらAPIは今回の実施の形態例に最低限必要となるものを定義してあるので、必要に応じて追加あるいは変更されていくものである。

ネゴシエーションの方式に関しては種々考えられるが本実施の形態例では以下のような方式とした。
電源サーバ１は本電源バスシステムのプラットフォームの準備（つまりアドレス確定や管理等を含む）と新規メンバーの登録、抹消の責任を持つ。新規メンバーには追加電源サーバも含まれる。即ち、新規電源サーバが参加した場合でも、すでにコントロールを担当している電源サーバ１に管理を委ねる。しかし、管理中の電源サーバ１そのものが離脱した場合には、その中にいるどれかの電源サーバ１が新規プラットフォーム構築を行い、クライアント１１とのネゴシエーションを再実行する。従って、この場合サービスを受けられないクライアント１１も発生し得ることもある。

電源供給のためのネゴシエーションはクライアント１１がイニシャティブをとる。電源のサービスを受けるのはクライアント１１であるので、そのための交渉をクライアント１１が開始するのは合理的である。クライアント１１は（アドレスはすでに確定しているので）必要と考えたタイミングですべての電源サーバ１のプロファイルを要求し、自分でその内容を把握または記憶する。これは電源バス８のバスラインに参加した時点で実行するのが通常であるが、タイミングについて強制はしない。これに基づいて、必要な時点でクライアント１１は電源サーバ１に対して電力供給交渉を開始し、交渉がまとまったところで（まとまると、どのタイミングで供給が開始されるかもわかる）電源が供給開始される。もちろんこれに同期してクライアント１１も受電を開始する。

電源サーバ１から見ると、クライアント１１がいつ電源バス８から離脱するか分からない。すなわち、供給パケット数までネゴシエートするので、およその終了時間や、完全に終了したことを知ることができるが、これは通常終了である。従って、異常終了の管理は不可能である。従って、クライアント１１の存在管理や離脱処理（離脱したならば、そのクライアントアドレスの抹消、クライアント向けカスタム電源プロファイルの抹消等）は電源サーバ１の責任である。

クライアント１１も、電源サーバ１がいつ消滅（これは電源バス８が消滅と同じ）するか分からないので、これに対処する責任を持つ。
ここで、アプリケーションインターフェース（API）のファーマットについて説明する。信号パケットは可変長パケットでありフォーマットについては図５に示したとおりであるが、図６、図７に示したパケット種別による値である制御信号の意味をここで詳しく説明する。各制御信号はパケット上では単なる数値であるが、分かり難いのでここではすべてニモ−ニックとして解説する。

まず、サーバリクエスト７２、サーバリプライ７３について説明する。
クライアント１が電源バス８に接続されると、電源サーバ１の検出を行うためこのサーバリクエスト７２をブロードキャストする。電源サーバ１はこのクライアント１１に対してサーバリプライ７３を送信し、このサーバリプライ７３のアドレスを見ることでクライアント１１は電源サーバ１のアドレスを知る。このサーバリクエスト７２、サーバリプライ７３のパケットにはペイロードは無い。
サーバリクエスト７２のニモ−ニックとしてReqServer、サーバリプライ７３ のニモ−ニックとして RepServerを用いる。

次に、電源仕様数リクエスト７５、電源仕様数リプライ７６について説明する。
クライアント１１が電源サーバ１のアドレスを知ると、電源サーバ１の電源仕様を要求することができる。電源サーバ１には複数の電源仕様をサポートできるので、まずこの数を要求する。複数の電源サーバ１が電源バス８上に存在する場合も、クライアント１１はそのプロファイルを認識しておく。これを認識していれば必要な時に最適な電源サーバ１に要求が提出できる。

電源仕様数リクエスト７５のニモ−ニックとしてReqSvrProfileNum、電源仕様数リプライ７６のニモ−ニックとしてRepSvrProfileNum を用いる。
Num（number）にサポートしている電源プロファイル数が返される。またこの番号はそれぞれのプロファイルに対応する。numberの最大はカスタムプロファイルを含めて２５５であり、最低でも一つのデフォルトプロファイルを持つ。

次に、電源仕様リクエスト７７、電源仕様リプライ７８について説明する。
電源仕様の具体的内容問い合わせで、電源サーバ１がクライアント１１にパラメータとしてターゲットとなる電源仕様の仕様番号を送る。
電源仕様リクエスト７７のニモ−ニックとしてReqServerProfile numberを用い、この時はnumberに必要とする仕様番号を入れる（これは１から２５５）。
電源仕様リプライ７８のニモ−ニックとしてRepServerProfile ServerProfileItem1 ServerProfileValue1 .... SerVerProfileItemN ServerProfileValueNを用いる。
このプロファイルの仕様に可変のものを含む場合、デフォルトプロファイル以外を必要とする場合には、カスタムプロファイルを生成（派生）して使用する。

次に、電源仕様確定リクエスト７９、電源仕様確定リプライ８０について説明する。
クライアント１１が電源サーバ１に送るクライアント用仕様番号確定要求であり、自分の電源仕様（電源プロファイル）と比較した上で一番適当なものを選択する。これはクライアント１１の責任である。また、クライアント１１がカスタム電源プロファイルを保有している場合には、その番号を指定することでそのプロファイルに切り替え可能である。 電源サーバ１はカスタムプロファイル番号とクライアント１１のIDをバインドして記憶しているので、カスタムプロファイルを他のクライアント向けに使用することをしない。 また、クライアント１１は自分用カスタムサーバプロファイル番号しか保持しない。

電源仕様確定リクエスト７９のニモ−ニックとしてReqSvrProfileSet numberを用い、電源仕様確定リプライ８０のニモ−ニックとしてRepSvrProfileSet numberを用いる。
電源サーバ１は仕様番号の数値のエコーバックを返す。これにより特定のクライアント１１と（特定の）電源サーバ１間でどの電源プロファイルを仕様するかが確定する。ただし、電源プロファイルに可変項目を含んでいる場合には新規に電源プロファイルを生成することがありうる。

次に、電源仕様新規作成リクエスト８１、電源仕様新規作成リプライ８２について説明する。
クライアント１１が可変電源サーバプロファイルを選択した場合、電源の受電仕様の変更が有りうる。また受電仕様をダイナミックに変化させ常に最適に保つような場合には、このクライアント専用の電源プロファイルが必要となる。このような場合に用いる電源サーバ１の標準プロファイル以外の専用プロファイル生成依頼である。

従って、電源サーバ１の電源プロファイルが可変である場合のみ、これが適応可能である。また電源サーバ１が可変プロファイルをサポートしていても、可変プロファイルをクライアント１１に使用せよという事ではなく、電源サーバ１が用意する既製プロファイルが要求を満たすなら、クライアント１１はこれを使用してもかまわない。

電源仕様新規作成リクエスト８１のニモ−ニックとしてReqSvrProfileMake number ServerProfileItem1 ServerProfileValue1 ....ServerProfileItemN ServerProfileValueNを用い、電源仕様新規作成リプライ８２のニモ−ニックとしてこのまま合意可能な時にはRepSvrProfileMake numberを用い、合意不可能時あるいはエラー時にはRepSvrProfileMake 0 ServerProfileItem1 ServerProfileValue1 .... ServerProfileItemN ServerProfileValueN を用いる。

クライアント１１はnumber にゼロを返し、合意出来なかったアイテムを添付する。値に関してはサーバ電源プロファイル中のものを添付する（クライアント１１はこの値を知っているはずである）。クライアント１１がこれで合意できない場合、クライアント１１側で仕様変更をサポートしていれば、さらにネゴシエーションを続行する。

クライアント１１の仕様変更サポート有無に関しては、クライアント１１の実装依存であり、本実施の形態では規定しない。つまり、クライアント１１はあくまで電源サーバ１の規定する電源仕様内でしかネゴシエーションできない。これは供給側の資源以上のものは望めないので合理的であると同時に、供給側が柔軟であればそれだけクライアント１１に親切であり、クライアント側も柔軟ならばより電源サービスを受けやすくなる。

ネゴシエーションが成功すると、電源サーバ１は、この特定のクライアント１１に対して新規サーバプロファイル番号を生成し、クライアント１１に通知する。この新規サーバプロファイルは対応するクライアント１１が電源バス８上に存在する限り有効である。また、この新規プロファイルの派生元となったサーバプロファイル番号が電源サーバ１に保存されるが、既存で用意しているものからの直接の派生のみとする。

派生したものからの更なる派生、他のクライアント１１向けに生成したものからの派生はできない（後者に関しては、他のクライアント１１向けプロファイルはアクセス不能と規定してあるので、原理的にできない）。これは必要以上に複雑化するのを避けるためである。サーバプロファイル番号は、同様のプロファイルを必要とするときに、どのサーバプロファイルから派生したかを直ちに知るためのものである。

次に、パケット数制御リクエスト８３、パケット数制御リプライ８４について説明する。
クライアント１１は電源サーバ１に対して要求するパケット数を指定することができる。この指定なしに、クライアント１１から送電開始要求を受け取った時は、時間制限なしと判断する。パケットの一単位時間は既定であるので、電源サーバ１側では、最大供給時間が想定できる。

最大パケット数は16ビット−1とし、Hbyte, Lbyteともに0xffの場合は無限大と解釈する。即ち、無制限供給要求である。ただし、一本の電源バス８のラインに複数のクライアント１１が接続される場合には供給頻度が減少する。この状況に対応する責任はクライアント１１側にある。また、本システムの性格上、クライアント１１が電源バス８から強制的に切り離されることも、電源サーバ１が切り離されることも、常に発生しうる。このような状態も異常ではなく、これに対応するのもクライアント１１の正常動作の内である。

パケット数制御リクエスト８３のニモ−ニックとしてReqPacketNum Hbyte Lbyteを用い、パケット数制御リプライ８４のニモ−ニックとしてRepPacketNum Hbyte Lbyteを用いる。

次に、送信開始時間設定リクエスト８５、送信開始時間設定リプライ８６について説明する。
クライアント１１から電源サーバ１に対しては送電開始時間を指定する。しかし本システムの構成上、複数のクライアント１１が存在する時など正確な時間は保証できない。指定した時間以降のできるだけ早いタイミングで送電開始されるという努力目標である。しかし、これは例えば夜間の空いている時に給電を受ける等に利用できる。時間設定のパラメータがすべて０の時は出来るだけ早くという意味とする。クライアント１１はこの指定を省略することはできない。電源サーバ１が受け取ったデータがすでに過去の値となってしまっている場合には、最速給電と解釈する。

送信開始時間設定リクエスト８５のニモ−ニックとしてReqPowerSt year month day hour minuite secondを用い、送信開始時間設定リプライ８６のニモ−ニックとしてRepPowerSt year month day hour minuite secondを用いる。

次に、電力パケット数変更リクエスト９２、電力パケット数変更リプライ９３について説明する。
希望電力パケット数について、電源供給開始後にクライアント１１が電源サーバ１に対して追加変更を希望するとき用いる。
電力パケット数変更リクエスト９２のニモ−ニックとしてReqMorePacketNum ByteH ByteL を用い、電力パケット数変更リプライ９３のニモ−ニックとしてRepMorePacketNum ByteH ByteLを用いる。

ByteH, ByteLに示される値がクライアント１１の希望値と異なる時は、電源サーバ１はその数のパケットしか供給できないことを示し、これが最終判断である。ゼロならば供給延長ができないという意味である。クライアント１１はこの件に関してはさらなるネゴシエートはできない。しかし、パケット供給が完了後に通常の手続きでパケット供給要求を行うことができる。

次に、電力パケット停止リクエスト８７、電力パケット停止リプライ８８について説明する。
クライアント１１は希望電力パケット数に達せずとも、供給停止を電源サーバ１に提出可能である。クライアント１１にも主スイッチ１５があるので、それをオフすることでもほぼ同等のことが可能であるが、電源バス８を他のクライアント１１に空け渡すためにも、不要になった時はこの要求を提出することにしている。Hbyte、Lbyteは新規希望値であり、これがゼロまたは送電完了値よりも小さいときはできるだけ早く停止する。

電力パケット停止リクエスト８７のニモ−ニックとしてReqPowerSp Hbyte Lbyteを用い、電力パケット停止リプライ８８のニモ−ニックとしてRepPowerSp Hbyte Lbyte を用いる。

次に、時刻同期７４について説明する。
電源サーバ１は電源バス８のライン上のすべてのクライアント１１、およびコントロール権をもたない電源サーバに対して時刻合わせ信号を送る。
時刻同期７４のニモ−ニックとしてTimeSet year month day hour minuite second を用いる。

次に、サーバプロファイル変更リクエスト８９、サーバプロファイル変更リプライ９０について説明する。
クライアント１１は電源サーバ１がサポートしていれば、カスタムサーバプロファイルを生成できる。カスタムサーバプロファイルはその依頼元のクライアント１１専用で、内容を変更可能である。クライアント１１は内容変更には次のサーバプロファイル番号および対応するアイテム、データをつけて電源サーバ１に送る。

サーバプロファイル変更リクエスト８９のニモ−ニックとしてReqSvrProfileMod number ServerProfileItem1 ServerProfileValue1 ....ServerProfileItemN ServerProfileValueNを用い、サーバプロファイル変更リプライ９０のニモ−ニックとしてRepSvrProfileMod number ServerProfileItem1 ServerProfileValue1 .... ServerProfileItemN ServerProfileValueN を用いる。

電源サーバ１がプロファイルアイテムの一部に変更不可（クライアント１１の要求ミスその他）と判断した場合には対応するプロファイルアイテム値にゼロをつけて返す。この場合クライアント１１はプロファイルアイテムに新規値をつけて（つまり、クライアント１１が自分の仕様変更可能であったり、妥協可能である場合）再度要求するか、電源サーバ１の回答をそのまま了承するかのどちらかの対応とする。

次に、ネゴシエーションキャンセル９１について説明する。
電源サーバ１、クライアント１１間のネゴシエーションが合意に達しない時はどちらからでもキャンセル可能である。Cansel numberと指定しただけで他のパラメータ類がない時はこの番号のカスタムプロファイルそのもののキャンセルであり、もしクライアント１１が電源をさらに必要とするならば、すべて最初から行う。ただし、全く同じ条件ではネゴシエーションに達しないはずなので、クライアント１１側はキャンセルされた状況とキャンセルされた回数は記憶しておくべきである。

またServerProfileItem ServerProfileValueが特定されている場合にはその部分のみのキャンセルであり、それまでに設定されている値が有効である。この後どうするかはクライアント１１次第である。キャンセルは基本的にネゴシエーションが終了しない場合の早期終了手段であるので、ネゴシエーションがあまり長引かない実装を前提とする。ネゴシエーションの回数は実装依存であるがクライアント１１、電源サーバ１とも最大回数を設定できる。ただし最大回数を２５５回としておく。

ネゴシエーションキャンセル９１のニモ−ニックとしてCansel number ServerProfileItem1 ServerProfileValue1... ServerProfileItemN ServerProfileValueNを用いる。

次に、電源サーバ１およびクライアント１１のプロファイルについて説明する。
電源サーバ１、クライアント１１ともに電力状況を表すプロファイルを用意するが、その内容を以下に示す。以下、電源仕様の代表的なもののみを示す。これら仕様は構造体やクラスメンバーとして記述することが可能なので、その内容の増減に関しては柔軟に対応できる。このプロファイルは電源サーバ１１、クライアント１１の制御を司るコントローラ３，１３の内部に保存される。

次に、電力形式について説明する。
図８は、電源サーバ１の提供する電力形式を示す図である。図８中AC１０６とは商用周波数の交流とする。現状では以下の４種類をサポートしている。
図８において、プロファイルアイテム(Client/ServerProfileItemN)１０１のPowerTypeが非安定DC１０３のとき、プロファイルバリュー(Client/ServerProfileValueN)１０２はNonRegDCである。プロファイルアイテム(Client/ServerProfileItemN)１０１のPowerTypeが安定化DC固定電圧１０４のとき、プロファイルバリュー(Client/ServerProfileValueN)１０２はRegDCFixである。

プロファイルアイテム(Client/ServerProfileItemN)１０１のPowerTypeが安定化DC可変電圧１０５のとき、プロファイルバリュー(Client/ServerProfileValueN)１０２はRegDCVarである。プロファイルアイテム(Client/ServerProfileItemN)１０１のPowerTypeがAC１０６のとき、プロファイルバリュー(Client/ServerProfileValueN)１０２はNonRegACである。

また、最大電圧は、電源サーバ１がサポートする電圧または消費する電圧の最大値である。安定化出力の場合には設定誤差等を含む最大値となる。
最大電圧のニモ−ニックとしてMaxVolt xxを用いる。
最小電圧は、電源サーバ１がサポートする電圧または消費する電圧の最大値である。安定化出力の場合には設定誤差等を含む最小値となる。

最小電圧のニモ−ニックとしてMinVolt xxを用いる。
公称電圧は、電源サーバ１がサポートする電圧または消費する電圧の公称値である。
公称電圧のニモ−ニックとしてNomVolt xxを用いる。
次に、可変電圧幅は、安定化可変電圧をサポートするコントローラの可変電圧ステップを示す値である。可変電圧幅のニモ−ニックとしてStepVolt xxを用いる。

最大電流は、供給可能な最大電流値または消費最大電流値である。最大電流のニモ−ニックとしてMaxCurr xxを用いる。
平均電流は、クライアント１１が提示する平均電流値である。平均電流のニモ−ニックとしてAveCurr xxを用いる。
派生元プロファイル番号は、既定のプロファイルの場合numberは０である。また、派生は一回だけと規定するので、派生プロファイルのnumberは派生元の規定プロファイル番号（１−…）となる。派生元プロファイル番号のニモ−ニックとしてOrigProfile numberを用いる。

次に、ネゴシエーションの詳細について説明する。
以下に具体的なネゴシエーション例を示す。クライアント１１側、電源サーバ１側の初期設定は完了しているとする。図９は、具体的なネゴシエーション例を示す図である。
ここでは、電源サーバ１が複数（２ヶ）の固定プロファイルをもち、１ヶの固定プロファイルをもつクライアント１１がバスに接続された場合を示す。

図９において、まず、クライアント１１から電源サーバ１に対しての電源仕様数リクエストとして、１１１で示すReqSvrProfileNum 0を送ると、電源サーバ１からクライアント１１へ電源仕様数リプライとして、１１２で示すRepSvrProfileNum 2を返す。

そこで、クライアント１１から電源サーバ１に対して電源仕様１の内容リクエストとして、１１３で示すReqServerProfile 1を送ると、電源サーバ１からクライアント１１へ電源仕様１の内容リプライとして、１１４で示すReqServerProfile 1（PowerType RegDCFix、MaxVolt 55、MinVolt 45、NomVolt 50、MaxCurr 20、AveCurr 15）を返す。

また、クライアント１１から電源サーバ１に対して電源仕様２の内容リクエストとして、１１５で示すReqServerProfile 2を送ると、電源サーバ１からクライアント１１へ電源仕様２の内容リプライとして、１１６で示すRepServerProfile 2（PowerType RegDCFix、MaxVolt 125、MinVolt 115、NomVolt 120、MaxCurr 10、AveCurr 5）を返す。

クライアント１１は電源仕様１が満足すると判断したので、クライアント１１から電源サーバ１に対して自分に対しては電源仕様１を使用することを要求する電源仕様確定リクエストとして、１１７で示すReqSvrPrrofileSet1を送ると、電源サーバ１からクライアント１１へ電源仕様確定リプライとして、１１８で示すRepSvrPrrofileSet 1を返す。なお、クライアント１１の電源仕様自体は基本的に電源サーバ１に送る必要はない。

クライアント１１は、電源サーバ１に対して無制限に（電源パケット数を省略したので）かつ、ただちに電源供給を開始する電源供給開始リクエストとして、１１９で示すReqPowerSt 0 0 0 0 0 0を送ると、電源サーバ１からクライアント１１へ電源供給開始リプライとして、１２０で示すRepPowerSt（06、07、15、10、05、10）を返す。

これにより、電源サーバ１側は年、月、日、時、分、秒のスタート時間を明示する。クライアント１１はスロット時間に提示される電源サーバ１のアドレスを監視し自身の主スイッチ１６を制御する。クライアント１１は常に電源サーバ１のアドレスをモニターすることが可能で、自分当ての電力については、時間を気にせずに受電可能であるが、この時間を参考データとすることができる。

クライアント１１は、電源サーバ１に対して電源が不要になったので直ちに電源停止リクエストとして、１２１で示すReqPowerSp 0 0を送ると、電源サーバ１からクライアント１１へ電源停止リプライとして、１２２で示すRepPowerSp 0 0を返す。

これによりクライアント１１は、電力パケットで自分当てのアドレスを持つものは電源サーバ１から送電されなくなる。この後でクライアント１１が再度送電要求を実行する時は電源供給開始リクエストとしてReqPowerStを送ればいい。あるいは全く最初からネゴシエートしなおすことも可能である。

図１０、図１１は他のネゴシエーション例を示す図である。
ここでは、電源サーバ１が複数（２ヶ）の固定および可変プロファイルをもち、１ヶの可変プロファイルをもつクライアント１１が電源バス８に接続された場合を示す。電源サーバ１が電源供給を開始し、クライアント１１が途中でサーバプロファイルの変更をする。これによりクライアント１１の状況変化に応じて電源サーバ１がダイナミックに電源供給を変化させることが可能となる。

図１０において、まず、クライアント１１から電源サーバ１に対しての電源仕様数リクエストとして、１３１で示すReqSvrProfileNum 0を送ると、電源サーバ１からクライアント１１へ電源仕様数リプライとして、１３２で示すRepSvrProfileNum 2を返す。

そこで、クライアント１１から電源サーバ１に対して電源仕様１の内容リクエストとして、１３３で示すReqServerProfile 1を送ると、電源サーバ１からクライアント１１へ電源仕様１の内容リプライとして、１３４で示すReqServerProfile 1（PowerType RegDCFix、MaxVolt 55、MinVolt 45、NomVolt 50、MaxCurr 20）を返す。

また、クライアント１１から電源サーバ１に対して電源仕様２の内容リクエストとして、１３５で示すReqServerProfile 2を送ると、電源サーバ１からクライアント１１へ電源仕様２の内容リプライとして、１３６で示すRepServerProfile 2（PowerType RegDCVar、MaxVolt 125、MinVolt 45、StepVolt 1、MaxCurr 50、NomVolt 50）を返す。電源仕様２のプロファイルでは電圧可変であり、可変ステップは０．１Vである。

クライアント１１は電源仕様２を使用することが必要であると判断したので、クライアント１１から電源サーバ１に対して自分に対しては基本プロファイルとして電源仕様２を使用することを要求する電源仕様基本プロファイル確定リクエストとして、１３７で示すReqSvrPrrofileSet２を送ると、電源サーバ１からクライアント１１へ電源仕様基本プロファイル確定リプライとして、１３８で示すRepSvrPrrofileSet ２を返す。

この基本プロファイルとしての電源仕様２ではデフォルト電圧は５Vであるが、電源が可変であることから、この電圧以外を必要とする場合にはカスタムプロファイル生成の必要がある。
そこでクライアント１１は電源サーバ１に対して自分専用のプロファイルを作成する意思表明となるカスタムプロファイル生成リクエストとして、１３９で示すReqSvrPrrofileMake 0（NomVolt 70、MaxCurr 5、Ave 3、StepVolt 2）を送る。

つまりデフォルト電圧以外を要求、あるいは後から変更するかも知れないという事を意味する意思表明である。ここで変更要求は新規のServerProfileItem, ServerProfileValueを添付する。この場合、変更または追加部分のみ添付すればよい。なお、同一部分を送ることを禁止はしない。

電源サーバ１はクライアント１１へ上記クライアントプロファイルを満たすサーバプロファイルが提供できるので、１４０で示すようにRepSvrPrrofileMake3として単にこのクライアント用カスタムプロファイル番号（３）を付けて返答する。 クライアント１１は電源サーバ１に１４１で示す供給パケット数リクエストとしてReqPacketNum 0xff 0x00を連絡すると、電源サーバ１はクライアント１１へ１４２で示す供給パケット数リプライとしてRepPacketNum 0xff 0x00を返す。

クライアント１１は、電源サーバ１に１４３で示す供給開始時間リクエストとしてReqPowerSt 06 07 15 10 05 10を指定すると、電源サーバ１はクライアント１１へ１４４で示す供給開始時間リプライとしてRepPowerSt 06 07 15 10 05 10を返す。
電源供給開始後、クライアント１１は電源電圧を変更するネゴシエーションを開始する。クライアント１１は電源サーバ１に１４１で示すサーバプロファイル番号を３に変更するサーバプロファイル変更リクエストとして、１４５で示すReqSvrProfileMod 3（NomVolt 68）を送ると、電源サーバ１はクライアント１１へ１４６で示すサーバプロファイル変更リプライとしてRepSvrProfileMod 3（NomVolt 68）を返す。

クライアント１１はこのプロファイルを保持したまま、新規プロファイル生成依頼も可能である。この時は、現状をもとに新規派生することも、派生元となるプロファイルに設定し直して（SetServerProfile)から新しいプロファイルを生成することも可能である。ここでは現状プロファイルの中身を変更している。

ここで扱っている電源は電圧源タイプを基本としているので、変更するのは殆どの場合電圧だけとなる。電源サーバ１が電流リミット機能を有していて、それも可変ならば、電流リミット値を電源サーバ１側で変更することも可能である。また電流源タイプの電源サーバ１ならば、電流値を可変するのが基本となる。ただし電流源タイプの電源というのは通常は使用されない。

そして、電源サーバ１はすべてのパケット数を送り終えたのでこのまま終了する。ただし、電源サーバ１はこのクライアント１１が電源バス８上に存在する限りServerProfileの３番は保存しておく。以後同一クライアント１１については、ServerProfile は１，２，３の３種類あるように見えることになる。他のクライアント１１に関しては１，２のみとなる。これは３はカスタム仕様のためである。

次に、電源バス８のラインの変形例について説明する。
上述した実施の形態では、電力ラインと通信ラインが共通なものについて例を示したが、このラインが別であってももちろんかまわない。この場合にはディジタル信号を変調せずに送ることもでき、モデム４，１４を不要としシステムを簡単にすることができる。また通信ライン、電力ラインとしてイーサネット（登録商標）も使用可能であり、Power Over Etherとしての応用もできる。ただし電力を無線で送るのは未だ現実的ではなく、基本的に有線ラインの使用が前提である。なお、通信ラインを無線LAN（Local Area Network）とすることも可能である。

次に、課金について説明する。
上述した実施の形態例では、電源バス８のバスラインの使用は家庭やオフィス内を想定しているが、これを公共空間に応用する場合、ユーザに対して課金が可能である。電源プロファイル内部に課金情報を含めることにより電源サーバ１はクライアント１１との間で経済的内容を含めたネゴシエーションができる。即ち、電力（Wｈ）や電荷（A x sec)に応じた単価を用意しておいてこれについてもネゴシエーション（クライアント１１側が電源サーバ１側の提示料金に同意するか否か）を経てから電力供給ができる。

この時、電源サーバ１やクライアント１１のIDはIPV6（Internet Protocol Version 6）におけるIPアドレスのように、枯渇の心配がないIDを使用し、かつ料金請求元／対象のIDも含める拡張をおこなう。このための別プロトコルを定義するのが現実的である。またこれら決済は電子マネーが現実的である。
現在、公共の場での電源供給システムがほぼ皆無であるが、この一つの問題が課金にあると考えられ、このような点でも有利である。また電圧にしても低いDCを供給する方が現在の機器の状況によりマッチしている。例えば携帯電話や携帯音楽プレーヤの充電に１００V ACを供給しても現実的でない。

次に、電源サーバ１の混在について説明する。
電源の種類に関しては電圧源と電流源が存在するが、本実施の形態におけるバスシステム上に、これらの異なった性格を持つ電源が共存できる事に注意すべきである。電力に関しては、電源バス８は基本的にタイムシェアリングであり、直前の電力形態がどのようであるかの影響を受けない。

電力形態はその前に付加された情報パケットのみで規定される。現実的な応用では定電流タイプの電力バス８というのは使用されることが殆どないと考えられるが、混在を許容することで、電源サーバ１、クライアント１１のコネクタを完全に同形式のものとすることが可能である。また、クライアント１１の入力部分に図１２に示すようなフィルタ５及びブリッジダイオード１５１からなる全波整流回路を付加することで、DC,ACの混在、さらにDCの極性についても完全に対称なコネクタとすることもできる。

次に、電力のタイムシェアリング利用について説明する。
電力パケットのタイムシェアを例えば一日単位にすると、電源バス８のバスラインの有効利用がさらに高まる。本実施の形態に示すシステムでは、電源サーバ１同時に複数のクライアント１１に電源を提供しないのを原則としているので、例えばある機器には夜間に電力を供給するように電源サーバ１が調停することで多数のクライアント１１に対して平均的かつ効率よく電力供給できる。逆に、常時電源を要求するシステム（例えばイーサネット（登録商標）のハブとか）に関しては本システムには向かず、常にAC電源から電源を供給すべきである。このために、クライアント１１の電力プロファイルに希望時間帯を追加することで電源サーバ１が調停可能となる。

次に、電力の同時供給について説明する。
本システムは電力単位時間に供給されるクライアント１１は１個と規定してきた。しかし、これも拡張可能である。例えばクライアント１１の要求電力合計が電源サーバ１が供給可能電力内でクライアント１１の電圧条件（クライアント１１は電圧で電力供給されるものとして）が合致すれば複数同時供給が可能である。この時は各電力パケットの前に送られるクライアントアドレスを対応する複数のアドレスとするだけでいい。なお、ネゴシエーションは別途完了しているとする。

電力パケットのスロットが１秒程度であること、このスロット切り替えのガードタイムを用意することを考えれば、複数のアドレス送信時間は数個のクライアント１１までならば、全く無視できる。電源サーバ１の方に関しては、全く同一の電力プロファイルをもったものならば並列給電することが可能である。このような場合には、電源バス８のバスラインの電流容量が問題になることが考えられ、またバス用電線の仕様に関しては直接サーバの電力プロファイルに記載できないので、あらかじめ特定のクライアント１１間で電線のインピーダンスを測定しておく方法がある。

即ち電源サーバ１が特定のクライアント１１の入力電圧レベルの情報を要求し、クライアント１１もADコンバータをもっていて入力電圧測定可能であるとすると、電源サーバ１はその電圧と自分の送り出し電圧、電流を検出することで、そのクライアント１１までのDC抵抗が計算できる。これがすぐに電源バス８のバスラインの容量とはならない。これは、電源サーバ１、クライアント１１間が物理的に直近かもしれないためである。

これを電源サーバ１が電源バス８のバスラインに接続されているクライアント１１すべてに対して実施し、その最悪値を知れば、電源サーバ１がどのくらいの電流容量を必要とする電源バス８か計算できる。このような用途に対しても対応するプロトコルを用意することで拡張できる。またクライアント１１の検出電圧情報などもクライアントプロファイルを拡張するだけでいい。

次に、負電源の電源サーバ１の共存について説明する。
これまで、明示はないが、電源サーバ１はすべてDC正電源であるとして説明してきた。しかしながら、電源サーバ１およびクライアント１１のメインスイッチ６，１６としてAC対応のフォトMOS（Metal Oxide Semiconductor）スイッチ（メカニカルリレーでも効果は同じが動作時間その他で現実的ではない）を使用することで、正電源と負電源の電源サーバ１が混在できる。この場合、パワーMOSトランジスタ１個を使用したDC対応のMOSスイッチでは、並列にダイオードが入っているためAC動作ができない。

この場合クライアント１１に関しては図１２に示した全波整流回路を入力部分に用意するだけでいい。これは、電源バス８のバスラインを無極性とした時と同様で、クライアント１１から見た場合正電源、負電源の区別がそもそもつかないためである。

次に、電流制限について説明する。
電気二重層コンデンサの進歩にともない、バッテリ１９のような二次電池の代わりに使用可能な場合が増加している。従って、これをクライアント１１のローカルストレージに使用する電源システムは今後大きな期待が持てる。図１３にクライアントの電流制限回路例を示す。この時、電気二十層コンデンサとしてのスパーキャパシタ１５４に電圧をチャージするにあたり、多くの応用で、充電電流を制限する必要がある。

これはクライアント１１側で実行するのが簡単であり、クライアント１１側のメインスイッチ１６を半導体スイッチをメインスイッチ１５２とし（これ以外は現実には無いため）、ここに基準電圧Ｖｓを超えるまでのコンパレータ１５３の出力をゲート電流としてメインスイッチ１５２をオンとして、基準電圧Ｖｓになったときのコンパレータ１５３の不出力によりメインスイッチ１５２をオフとして定電流もしくは電流リミット特性をもたせることができる。このようにクライアントローカルで処理できる場合でもクライアントプロファイルにこの内容を書き込んでおくことで、電源サーバ１側が柔軟に対応可能となる。

最後に、プロトコルについて説明する。
上述した実施の形態例においては固有アドレスとしてMAC（Media Access Control）アドレス、プロトコルとしてイーサネット（登録商標）の方式に準拠したが、本システム内について意味を有する固有アドレスやプロトコルであれば応用可能で、これらに限定されるものではない。

電源サーバの構成を示すブロック図である。 クライアントの構成を示すブロック図である。 電源バス上の電源パケット及び情報パケットのタイムスロットを示す図である。 同期パケット、情報パケット、電力パケットの交換を示す図である。 基本パケットフォーマットを示す図である。 電源パケット種別とその値を示す図である。 電源パケット種別とその値を示す図である。 サーバーの提供する電力形式を示す図である。 ネゴシエーション例を示す図である。 他のネゴシエーション例を示す図である。 他のネゴシエーション例を示す図である。 クライアントの全波整流回路を示す図である。 クライアントの電流制限回路を示す図である。

符号の説明

１…電源サーバ、１１…クライアント、８…電源バス、３１、３３、３５…情報スロット、３２、３４、３６…電力スロット、４１、４７、５１…同期パケット、４２〜４５…情報パケット、４６、５０、５２…電力パケット

Claims (16)

1. 電源供給元となるサーバと、電源供給先となるクライアントと、前記サーバと前記クライアントとを接続するラインとを有し、前記サーバと前記クライアントとの間で情報のやり取りをしながら前記サーバから前記クライアントへ電力を供給する電力供給システムにおいて、
   前記サーバは、
   前記クライアントとの間の情報のやり取り及び前記クライアントとの間での電力の供給の同期を取り、前記クライアントとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、前記サーバのアドレスを含んだ同期パケットを前記情報スロットのタイミングで発信する機能を備え、
   同一の前記ラインに他のサーバが接続された時には、同期を取っている前記サーバからの前記同期パケットの受信を前記他のサーバが検出することで、前記他のサーバは同期を取るサーバとはならない
   電力供給システム。
2. 請求項１記載の電力供給システムにおいて、
   前記サーバは、
   前記電力スロットに先立って設けられる前記情報スロットにおいて、前記クライアントとの間で電力仕様に関する情報をネゴシエートする機能を備える
   電力供給システム。
3. 請求項１又は２記載の電力供給システムにおいて、
   同期を取っている前記サーバが前記ラインから離脱したときは前記他のサーバが同期を取るサーバとなる
   電力供給システム。
4. 請求項１又は２記載の電力供給システムにおいて、
   前記サーバは、
   前記情報スロットにおいて、前記クライアントからのサーバリクエストを受信することでサーバ及びクライアント間のアドレス確定を行うものであって、
   前記情報スロット及び電力スロットを、電源仕様の異なる電力を供給する各クライアント毎に発生させる
   電力供給システム。
5. 請求項１又は２記載の電力供給システムにおいて、
   前記サーバと前記クライアントとの間の情報のやり取り及び電力の供給は、前記ラインとして用いる電源バスの共通のバスライン上に重畳されて行われるもの、又はそれぞれ別のバスライン上で行われるものである
   電力供給システム。
6. 請求項１又は２記載の電力供給システムにおいて、
   前記クライアントが前記サーバとなって、他のクライアントに対して情報のやり取り及び電力の供給を行う
   電力供給システム。
7. 請求項１又は２記載の電力供給システムにおいて、
   前記クライアントからの要求により、前記サーバは前記クライアントに対して予め定められた固定値又は可変値の電力の供給を行う
   電力供給システム。
8. 電源供給元となるサーバと、電源供給先となるクライアントとがラインを介して接続され、前記サーバと前記クライアントとの間で情報のやり取りをしながら前記サーバから前記クライアントへ電力を供給する電力供給方法において、
   前記サーバは、
   前記クライアントとの間の情報のやり取り及び前記クライアントとの間での電力の供給の同期を取り、前記クライアントとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、前記サーバのアドレスを含んだ同期パケットを前記情報スロットのタイミングで発信し、
   同期を取っている他のサーバが接続されているのと同一の前記ラインに接続された時には、前記他のサーバからの前記同期パケットの受信を検出することで、同期を取るサーバとはならない
   電力供給方法。
9. 請求項８記載の電力供給方法において、
   前記サーバは、
   前記電力スロットに先立って設けられる前記情報スロットにおいて、前記クライアントとの間で電力仕様に関する情報をネゴシエートする
   電力供給方法。
10. 請求項８又は９記載の電力供給方法において、
    前記サーバは、同期を取っている前記他のサーバが前記ラインから離脱したときは同期を取るサーバとなる
    電力供給方法。
11. 電源供給元となるサーバと、電源供給先となるクライアントと、前記サーバと前記クライアントとを接続するラインとを有し、前記サーバと前記クライアントとの間で情報のやり取りをしながら前記サーバから前記クライアントへ電力を供給する電力供給システムにおける前記サーバ及び前記クライアントのコンピュータに対して所定の機能を実行させる電力供給プログラムにおいて、
    前記サーバのコンピュータに対して、
    前記クライアントのコンピュータとの間の情報のやり取り及び前記クライアントのコンピュータとの間での電力の供給の同期を取り、前記クライアントのコンピュータとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、前記サーバのコンピュータのアドレスを含んだ同期パケットを前記情報スロットのタイミングで発信する機能と、
    同期を取っている他のサーバのコンピュータが接続されているのと同一の前記ラインに接続された時には、前記他のサーバのコンピュータからの前記同期パケットの受信を検出することで、同期を取るサーバとはならない機能と、を実行させる
    電力供給プログラム。
12. 請求項１１記載の電力供給プログラムにおいて、
    前記サーバのコンピュータに対して、前記電力スロットに先立って設けられる前記情報スロットにおいて、前記クライアントのコンピュータとの間で電力仕様に関する情報をネゴシエートする機能を実行させる
    電力供給プログラム。
13. 請求項１１又は１２記載の電力供給プログラムにおいて、
    前記サーバのコンピュータに対して、同期を取っている前記他のサーバのコンピュータが前記ラインから離脱したときは同期を取るサーバとなる機能を実行させる
    電力供給プログラム。
14. 電源供給元となるサーバと、電源供給先となるクライアントと、前記サーバと前記クライアントとを接続するラインとを有し、前記サーバと前記クライアントとの間で情報のやり取りをしながら前記サーバから前記クライアントへ電力を供給する電力供給システムにおける前記サーバにおいて、
    前記クライアントとの間の情報のやり取り及び前記クライアントとの間での電力の供給の同期を取り、前記クライアントとの間でアドレス管理を行うために、情報のやり取りのための情報スロット及び電力の供給のための電力スロットを発生し、前記サーバのアドレスを含んだ同期パケットを前記情報スロットのタイミングで発信する機能と、
    同期を取っている他のサーバが接続されているのと同一の前記ラインに接続された時には、前記他のサーバからの前記同期パケットの受信を検出することで、同期を取るサーバとはならない機能と、を備える
    サーバ。
15. 請求項１４記載のサーバにおいて、
    前記電力スロットに先立って設けられる前記情報スロットにおいて、前記クライアントとの間で電力仕様に関する情報をネゴシエートする機能を備える
    サーバ。
16. 請求項１４又は１５記載のサーバにおいて、
    同期を取っている前記他のサーバが前記ラインから離脱したときは同期を取るサーバとなる機能を備える
    サーバ。

Images