(57)【特許請求の範囲】
【請求項１】
節電モードにおける通信ネットワークの駆動方法であって、
ネットワーク内での機器での活動および／または状態に基づいて、１つまたは複数のネットワークエレメント（１）ないし１つ／複数のネットワークエレメントに配属された１つ／複数の機器が節電モードに移行可能か否かを判断する中央ユニット（２）を、ネットワークエレメント（１）の節電状態のネットワークワイドのコーディネートに対して設けるステップと、
当該判断に基づき、目前に迫っている節電モードへの切換をネットワークエレメント／機器（１）に予告するステップと、
ローカル節電モード制御ユニット（３）が、節電モードへの切換に対する前記中央ユニット（２）による予告を受け取った場合に、該切換が実行可能か否かを検査するステップと、
前記ローカル節電モード制御ユニット（３）が、自身に割り当てられたネットワークエレメント／機器（１）が状態の切換に同意した場合に節電モードへの切換に対する予告を肯定的に確認応答し、自身に割り当てられたネットワークエレメント／機器（１）が状態の切換に同意しない場合には節電モードへの切換に対する予告を否定的に確認応答するステップと、
前記確認応答が否定的な場合にネットワークエレメント／機器（１）が、該ネットワークエレメント／機器内のどの部分がまだ活動を有しているかを応答において付加的に伝達するステップとを有する、
ことを特徴とする、節電モードにおける通信ネットワークの駆動方法。
【請求項２】
肯定的な確認応答後にネットワークエレメント／機器（１）は活動の新たな開始をもはや許可しない、請求項１記載の方法。
【請求項３】
ネットワーク内の全ネットワークエレメント／機器（１）の確認応答が肯定的である場合、前記中央ユニット（２）は節電モードに切り換わるように要求する、請求項１または２項記載の方法。
【請求項４】
前記中央ユニット（２）は特に供給源の状態がクリチカルであるという情報を受け取った場合に、予告の拒否が不可能であり、節電モードへの切換が行われなければならない予告を示す、請求項１から３までのいずれか１項記載の方法。
【請求項５】
前記予告の確認応答が戻ってこない場合、または特別に示された予告を受け取った場合、節電モードへの切換を所定の時間後に中央ユニット（２）ないしはローカル節電モード制御ユニット（３）によって行う、請求項１から４までのいずれか１項記載の方法。
【請求項６】
ローカル節電モード制御ユニット（３）は基本的に節電モードへの切換に対する予告の肯定的な確認応答を出力し、これによって中央ユニット（２）は、予告が全てのネットワークワークエレメント／機器（１）に達したか否かを検査し、場合によっては予告を繰り返すことができる、請求項１から５までのいずれか１項記載の方法。
【請求項７】
前記中央ユニット（２）はバスで、規格ＩＥＥＥ１３９４に相応して「等時性リソースマネージャー」の機能および／または「サイクル・マスタ」の機能も引き受ける、請求項１から６までのいずれか１項記載の方法。
【発明の詳細な説明】
【０００１】
従来技術
本発明は、節電モードにおける通信ネットワークの駆動方法から出発する。
【０００２】
ＩＥＥＥ規格１３９４ [１] から、シルアルバスシステムが公知である。このシルアルバスシステムでは、種々異なる端末機（ノード）が４−６芯ケーブルまたは光導波体を介して接続される。ここで少なくとも１つのノードは、これがネットワークに対する付加的管理機能を引き受けることができるように構成されている（バスマネージメント）。
【０００３】
上記の規格の他にバスに依存しない拡張形態もあり、ＨＡＶｉ（Home Audio Video interoperability）［２］として仕様化されている。このＨＡＶｉ仕様は、とりわけリソースマネージャーを使用した、機器の遠隔制御を記述しており、リソースマネージャーはリソース（機器）を要求に応じて占有し、これを再び開放する。
【０００４】
ＨＡＶｉ仕様には分散モデルも記載されている。この分散モデルでは、機器の制御がコントロールモジュール、いわゆる「デバイスコントロールモジュール（ＤＣＭ）」を介して行われる。このＤＣＭはソフトウエアエレメントとして、他の機器へコントロール機能を及ぼす機器上で実行される。ここでＤＣＭはそれぞれ所定の機器または機器クラスに対して専用のものである。
【０００５】
発明の利点
請求項１記載の方法によって、電流節約状態の効果的なネットワークワイドのコーディネートが実現される。これによってこの方法を、休止状態における少ない電流消費が重大な要求である車両内で使用することが可能である。
【０００６】
従属請求項にはこの方法の有利な実施形態が記載されている。
【０００７】
図面
本発明の実施例を図面に基づいて説明する。
【０００８】
図１はバスシステムのネットワーク構成を示す概略図である。
【０００９】
図２は節電モードの制御に対する機能ダイアグラムを示す概略図である。
【００１０】
実施例の説明
本発明をＩＥＥＥ規格１３９４［１］によるシリアルバスシステムに基づいて説明する。ここではＨＡＶｉ仕様［２］による拡張も基準にしている。本発明の本来の説明の前に、ＩＥＥＥ規格１３９４とＨＡＶｉ仕様を理解するために説明する。さらにいくつかの概念を説明する。
【００１１】
種々の端末機（ノード）が図１では４−６芯ケーブルまたは光導波体を介して接続されている。ここでノードは選択的にエンドピース（葉）１００またはリレーノード（枝）２００，３００として構成することができる。最上位のノードは根と称される。種々のノード形式を使用することにより、ネットワークの適切なトポロジーを構成することができる。ここで葉は情報パケットを受信し、そのパケットの目標アドレスが固有のものと一致していれば、これを処理する。枝は付加的に、これがポートに受信するすべてのパケットを他のすべてのポートに送信しなければならない。
【００１２】
ＩＥＥＥ１３９４では、ネットワークが自動コンフィギュレートされる。すなわちスイッチオン後、またはリセット後にすべてのノードは自分自身に関する選択された複数の情報をネットワークに送信する。この情報はすべてのノードにより受信される。ここで１つのノードは、これが付加的にネットワークに対する管理機能（バスマネージメント）を引き受けることができるように構成されている。このためにこのノードは他のノードのすべての情報を収集し、これを処理し、内部に適切に記憶する。複数のノードがバスマネージメント能力を有している場合は、競争方法が存在し、ここから１つのノードが勝利者となり、バスマネージメントを引き受ける。
【００１３】
ＩＥＥＥ１３９４についての仕様に記述された方法の他に、バスに依存しない拡張ＨＡＶｉも存在する。この拡張はＩＥＥＥ１３９４−ネットワークで使用するのに適する。とりわけ機器をネットワーク内の他の各ポイントから遠隔制御することがＨＡＶｉ仕様に記載されている。このために分散モデルが記述されており、このモデルでは機器の制御がコントロールモジュール、いわゆる「デバイスコントロールモジュール（ＤＣＭ）」を介して行われる。このＤＣＭはソフトウエアエレメントとして、他の機器に対してコントロール機能を及ぼそうとする機器上で実行される。ここでＤＣＭは所定の機器または機器クラスに対してそれぞれ専用のものである。ソフトウエアエレメントの別のグループは「機能コンポーネントモジュール」となり、これらのうちそれぞれ複数を階層的にＤＣＭの下に配置することができ、機器の専用機能のそれぞれ一部をコントロールする。
【００１４】
本発明と関連して使用されるＨＡＶｉ−コンポーネントを以下で説明する：ＨＡＶｉは、分散システムに対するモジュールのコンセプトに基づく。ここで個々のモジュールはネットワークエレメント、特にソフトウェアエレメントである。システム中の全ネットワークエレメントは統一的にアドレス指定される。ネットワークエレメントを殆どの場合に、中央に配置することも分散して配置することもできる。すなわち所定のソフトウェアエレメント（例えばストリームマネージャー）の１つのエンティティのみで実行されてもよいし、各機器内でこの種のエンティティが実行されてもよい。
【００１５】
ここで以下のネットワークエレメントがシステム内に設けられる：
ストリームマネージャー：ストリームマネージャーＳＭは、ソフトウェアエレメントおよび／または機器間の接続の形成および解除および管理に用いられる。このストリームマネージャーはレジストリのように分散システムとして構成される。ここで特別な命令が全てのＳＭの状態または１つの所定のＳＭの状態を得るのに用いられる。
【００１６】
イベントマネージャー：イベントマネージャーは、システム内の状態変化に関する知らせを通信参加者に運搬する。
【００１７】
レジストリ：レジストリは各ネットワーク内で使用可能な各ソフトウェアエレメントおよび使用可能な各機器に関する情報を含む。ここで個々のソフトウェアエレメントに関する情報は属性に記憶される。前に定義された属性に対して付加的に別の属性を加えることが可能である。レジストリの構成は分散システムである。すなわち各機器はレジストリ全体の一部分を含む。しかしこれを中央に保つこともできる。レジストリへのアクセスに対してこれは見えない。なぜならネットワーク内のレジストリの種々異なるエンティティは場合によっては要求された情報を自動に交換するからである。
【００１８】
リソースマネージャー：リソースマネージャーはリソース（機器、ソフトウェアエレメント）の占有および開放を実行し、計画されたプロセス（例えばビデオレコーダー撮影）を記憶する。
【００１９】
ＤＣＭマネージャー：ＤＣＭマネージャーは適切な機器のもとでのＤＣＭのインストールおよびアンインストールを担う。
【００２０】
デバイスコントロールモジュール：デバイスコントロールモジュールＤＣＭは、１つまたは複数のＦＣＭを１つの機器駆動部にまとめるソフトウエアエレメントである。
【００２１】
ファンクショナルコントロールモジュール：ファンクショナルコントロールモジュールＦＣＭは、機器（例えばＣＤ−トラックまたはＵＫＷ−チューナー）の機能ユニットを駆動制御するソフトウェアエレメントである。ここでＤＣＭは全ＤＣＭ共通の基本機能および機器専有のＦＣＭから構成される。
【００２２】
このようなモジュールまたは機器内で必要とされる各モジュールは、統一的なアプリケーションインターフェィスを構成する。このような統一的なインターフェィスによって、アプリケーションと様々な製造者の機器間での相互通用性が得られる（相互通用性  ＡＰＩ）。
【００２３】
本発明による方法は、ＨａＶｉ規格 [３] に基づくシステムのもとで使用される。そこに記述されたネットワークエレメントに、パワーマネージャーエレメント（以下でローカル節電モード制御ユニット３と称する）が加わる。ローカル節電モード制御ユニットは、パワー（節電）−モードのローカルな管理を担う。全ネットワーク内に存在する、パワーマネージャーのエンティティは、パワーマスターに対するシステムの初期化時に中央ユニット２として定められ、これによってネットワークエレメントの節電状態のネットワークワイドのコーディネートを担う。中央ユニット２は種々異なる情報（例えばバスの活動（Busaktivitaet）、バッテリ状態、点火  オン／オフ）に基づいて、ネットワーク内の１つまたは複数ないしは全ての機器の節電モードの変化に関して判断を下す。運転者が自分の自動車を離れた場合、点火部はスイッチオフされ、バスの活動はほぼ０である。中央ユニットはこのような基準を節電モードに変えるために評価する。このために中央ユニット２は相応のコマンドを、ネットワーク内の選択された（単一キャスト、マルチキャスト）または全（ブロードキャスト）機器／ネットワークエレメントに送出する。全ての機器が節電状態に移行されることを中央ユニット２が内部で判断した場合に、中央ユニットは通常駆動時にはまずはじめにネットワーク内の待機している状態変化に関する予告を送出する。このような予告を受け取った場合、ローカル節電モード制御ユニット３は、この切換を実行することができるか否か、またはまだ活動（ユーザーまたはリソース）が機器内に存在するか否かを検査する。機器が状態変化に同意した場合、この機器の節電モード制御ユニット３はこの予告を肯定的に確認応答（bestaetigt）する。機器が状態変化に同意しない場合、この機器の節電モード制御ユニットはこの予告を否定的に確認応答する。肯定的な確認応答後は、この機器が活動の新たな開始をもはや許可せず、さらなる経過が妨害されないのは特に有利である。確認応答が否定的な場合、この機器は応答において付加的に機器（ソフトウェアエレメント）内のどの部分がまだ活動を有しているかを伝達する。これによって、故障または誤って作動する機器の検出が可能である。
【００２４】
ネットワーク内の全機器の肯定的な確認応答後に、中央ユニット２は節電モードに切りかわることを要求する。このような呼び出しも機器内で節電モード制御ユニット３はまだ拒絶することができ、これによって状態変化は中断される。そうでない場合にこの機器は状態を指示されたように変える。
【００２５】
このような協力方法（kooperativen Verfahren）に対して付加的に、例外に対して非協力方法（unkooperatives Verfahren）がある。この非協力方法では中央ユニット２は「フォース（Force）」−コマンドを送出する。これは殊に予告の特別なマーク（Kennzeichung)による強制的な状態変化を意味する。このようなコマンドを受け取った場合、機器は拒否することはできず、少なくとも設定された時間後に状態変化が実行されるべきである。
【００２６】
図２に基づき以下で具体的な実施例を説明する。システム内に存在する機器の１つは、システムの初期化時に中央ユニット２（パワーマスタ）として選択される。
【００２７】
前述の方法を実行するために、以下の機能呼出しが使用される：
Ｓｔａｔｕｓ  ＧｅｔＰｏｗｅｒＭｏｄｅ（ＯＵＴ  ＰｏｗｅｒＭｏｄｅ）（１２）
Ｓｔａｔｕｓ  ＳｅｔＰｏｗｅｒＭｏｄｅ（
ＩＮ  ＰｏｗｅｒＭｏｄｅ  ｎｅｗＰｏｗｅｒＭｏｄｅ,
ＩＮ  ＲｅｑｕｅｓｔＭｏｄｅ  ｍｏｄｅ,
ＯＵＴ  ｓｅｑｕｅｎｃｅ＜ＳＥＩＤ＞ ｓｅｉｄＬｉｓｔ）
Ｓｔａｔｕｓ  ＣｈａｎｇｅＰｏｗｅｒＭｏｄｅ（
ＩＮ  ＲｅｑｕｅｓｔＭｏｄｅ  ｍｏｄｅ,
ＩＮ  ｂｏｏｌｅａｎ  ａｐｐｌｉｃａｔｉｏｎ,
ＯＵＴ  ｂｏｏｌｅａｎ  ｃｏｎｆｉｒｍｅｄ,
ＯＵＴ  ｗｓｔｒｉｎｇ＜５０＞ ｉｎｆｏ）
パワーマスタ（中央ユニット２）は、自身に存在する情報（例えばバスの負荷、点火キーの位置、中央ロック部の位置、内部空間センサ）に基づき、システム中の１つまたは複数の機器（場合によっては全ての機器も）がもはや必要とされておらず、節電モードに移行されるべきであるのを判断する。このためにパワーマスタは、システム内のローカルパワーマネージャー（節電モード制御ユニット３）で、どのモードにネットワークエレメント／機器１が存在するのかをＧｅｔＰｏｗｅｒＳｔａｔｅ１２、１３によって問い合わせする。
【００２８】
自身のパワーモードを切り換えるべきである機器のローカル節電モード制御ユニット３に、パワーマスタ２はＳｅｔＰｏｗｅｒＭｏｄｅ（モード＝ANNOUNCE）１４によって目前に迫っている切換を予告する。ローカルパワーマネージャー３は、自身のストリームマネージャー４（ＧｅｔＬｏｃａｌＣｏｎｎｅｃｔｉｏｎＭａｐ１５）およびレジストリ（ＧｅｔＥｌｅｍｅｎｔ１６、１７）によって、自身の機器内のリソースが占有されているか否か、およびどの自身の機器内のどのリソースが占有されているかを検査する。
【００２９】
リソースをまだ占有しているソフトウェア（ネットワーク）エレメント１には、ＣｈａｎｇｅＰｏｗｅｒＭｏｄｅ（モード＝ANNOUNCE１８）によって目前に迫っている、パワーモードの切換が通知される。自身の応答（１９）内でこのソフトウェアエレメントは、この切換が自身の見地から可能であるか否かを伝達する。協力方法では応答が否定的な場合、このようなソフトウェアエレメントの少なくとも１つは、自身に割り当てられているローカルパワーマネージャー３を介して、パワーマスタ２の問い合わせを拒否する。この場合にこの過程は中断される。
【００３０】
パワーマスタ２が予告に対して肯定的な応答を受け取った場合（２０）、パワーマスタは、モード＝ＳＥＴ２１を有する通知ＳｅｔＰｏｗｅｒＭｏｄｅを繰り返す。引き続き応動した機器は、通知２２を介して自身のパワーマネージャー３によって選択されたパワーモード２３に切りかわる。
【００３１】
以下で節電状態への非協力切換の例を示す：パワーマスタ２は、供給源の状態、特にバッテリの充電状態がクリチカルであるという情報を受け取り、システム中の全機器が即座に節電モードに切りかわるべきであると判断する。前述の例のような、予告の拒否による過程の遅延をできるだけ回避するために、パワーマスタ２は通知ＳｅｔＰｏｗｅｒＭｏｄｅ内でパラメータモードをＦＯＲＣＥにセットする。ローカルパワーマネージャー３は、自身の側でＣｈａｎｇｅＰｏｗｅｒＭｏｄｅにおいてモード＝ＦＯＲＣＥにセットする。これによって全ソフトウェア−エレメントは目下このシステムが減衰されていることを認識する。ＦＯＲＣＥ−モードにおいてはソフトウェアエレメントは予告を拒否せず、即座に減衰しなければならない。
【００３２】
パワーマスタ２による予告の確認応答が戻って来ない場合、または特別に示された予告（ＦＯＲＣＥ）を受け取った場合に節電モードへの切換は所定の時間後に、パワーマスタ２またはローカルパワーマネージャー３によって自動的に行われることも可能である。
【００３３】
パワーマスタがＩＥＥＥ１３９４−バスで等時性（Isochronous）リソースマネージャーおよびサイクル・マスタの機能も引き受けるのは特に有利である。
【００３４】
択一的に、パワーマネージャー３は「ＳＥＴ」および「ＦＯＲＣＥ」を有する呼出しでも、肯定的な受け取り証を送出することができる。これによってパワーマスタ２は、全機器にこれが達したか否かを検査し、場合によっては相応のコマンドを繰り返すことができる。
【００３５】
【外１】
0004732673.tif 000002
【図面の簡単な説明】
【図１】  バスシステムのネットワーク構成を示す概略図である。
【図２】  節電モードの制御に対する機能ダイアグラムを示す概略図である。
【図１】
0004732673.tif 000003
【図２】
0004732673.tif 000004