JP4581259B2 - 組込型電子機器ならびに組込電子機器および組込電子機器の管理方法 - Google Patents
組込型電子機器ならびに組込電子機器および組込電子機器の管理方法 Download PDFInfo
- Publication number
- JP4581259B2 JP4581259B2 JP2001029358A JP2001029358A JP4581259B2 JP 4581259 B2 JP4581259 B2 JP 4581259B2 JP 2001029358 A JP2001029358 A JP 2001029358A JP 2001029358 A JP2001029358 A JP 2001029358A JP 4581259 B2 JP4581259 B2 JP 4581259B2
- Authority
- JP
- Japan
- Prior art keywords
- embedded electronic
- electronic device
- snmp
- board
- value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、ネットワークに接続され、筐体内に装着された組込電子機器をＳＮＭＰ(Simple Network Management Protocol)を用いて管理する際に、被管理機器における構成の変化に柔軟に対応可能な組込型電子機器ならびに組込電子機器および組込電子機器の管理方法に関する。
【０００２】
【従来の技術】
現在、ＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)によるネットワークに接続された機器を管理するためのプロトコルとして、ＳＮＭＰ(Simple Network Management Protocol)が提供されている。ＳＮＭＰでは、システム管理者により起動されるネットワーク監視端末（ＳＮＭＰマネージャと称される）と、ＳＮＭＰが実装されるネットワーク上の機器（ＳＮＭＰエージェントと称される）との間のプロトコルが規定される。ＳＮＭＰでは、ＭＩＢ(Management Information Base)と称されるＳＮＭＰエージェントが持つ情報に、ＳＮＭＰマネージャがアクセスすることで、機器の状態の把握や機器に設定される定義情報の変更が可能とされる。ＳＮＭＰを用いることによって、複雑に構成されるネットワークの管理を、ＳＮＭＰマネージャから容易に行うことが可能とされる。
【０００３】
一方、ネットワーク環境の普及により、コンピュータといった情報機器のみならず、例えば放送局などで使用されるビデオ機器を、ＴＣＰ／ＩＰによるネットワーク接続により管理することが提案されている。このとき、ＳＮＭＰが実装されていないなど、ＳＮＭＰエージェント機能を有さない機器をＳＮＭＰにより管理するためには、ＳＮＭＰエージェント機能が実装されている機器をプロキシエージェントとして設ける必要がある。すなわち、プロキシエージェントによって、ＳＮＭＰエージェント機能を有さない機器とＳＮＭＰとの仲介を行い、当該機器のＳＮＭＰによる管理を可能とする。
【０００４】
図２１は、このプロキシエージェントによる一例のアーキテクチャを示す。ＳＮＭＰマネージャ３００により、独自の管理インターフェイスに対応した機器３２０がプロキシエージェント３１０を介して管理される。
【０００５】
例えばＳＮＭＰマネージャ３００から機器３２０に対してコマンドやデータ（以下、コマンドとする）などを送る場合、ＳＮＭＰマネージャ３００側の管理アプリケーション３０１で発行されたコマンドは、クライアント・スタブ３０２でプロトコル・スタック３０３によりプロトコル解釈されてＳＮＭＰに変換され、ＳＮＭＰマネージャ３００から送信される。このＳＮＭＰに変換されたコマンドは、プロキシ・エージェント３１０に受信され、プロトコル・スタック３１３およびサーバ・スタブ３１２を介してプロキシ・エージェント・アプリケーション３１１に供給される。
【０００６】
一方、機器３２０は、ＳＮＭＰとは異なるプロトコルを用いた独自の管理インターフェイス３２１により管理される。ＳＮＭＰマネージャ３００から送信されたＳＮＭＰは、プロキシ・エージェント・アプリケーション３１１において、クライアント・プロキシ・スタブ３１４によりプロトコル・スタック３１５を用いて機器３２０の独自の管理インターフェイス３２１が対応するプロトコルに変換される。このプロトコル変換されたコマンドが機器３２０に送信され、管理インターフェイス３２１に受信される。
【０００７】
このように、プロキシ・エージェント３１０によってＳＮＭＰマネージャ３００とＳＮＭＰ非対応の機器３２０の仲介をすることで、ＳＮＭＰマネージャ３００により機器３２０を管理することができる。
【０００８】
【発明が解決しようとする課題】
しかしこの場合、プロキシ・エージェント３１０は、管理される側の機器３２０（被プロキシ・エージェントとする）に関する全管理項目を把握している必要があるという問題点があった。
【０００９】
さらに、被プロキシ・エージェントが多種・複数存在する、ニーズに応じて管理項目の構成が変化する、新たな被プロキシ・エージェントが開発され管理項目が追加される、などの事態を想定すると、プロキシ・エージェント３１０におけるプロキシ・エージェント・アプリケーション３１１に対して、バージョンアップなどによる機能拡張を可能にするように対応する必要があるという問題点があった。
【００１０】
したがって、この発明の目的は、ＳＮＭＰを用いてＳＮＭＰに非対応の機器を管理する際に、機能の拡張が容易な組込型電子機器ならびに組込電子機器および組込電子機器の管理方法を提供することにある。
【００１１】
【課題を解決するための手段】
この発明は、上述した課題を解決するために、ＳＮＭＰが実装されプロキシ・エージェントの機能を持つシステム用ＣＰＵおよびメモリを有するシステム基板と、複数の組込電子機器をそれぞれ接続するための複数の組込手段と、ネットワークを介してＳＮＭＰマネージャとの通信を行う第１の通信手段と、ＳＮＭＰに基づくオブジェクトＩＤをＳＮＭＰとは異なるプロトコルに変換する変換手段と、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得する機器情報取得手段と、複数の組込電子機器に対してＳＮＭＰとは異なるプロトコルを用いて通信を行う第２の通信手段とを備え、機器情報取得手段は、所定の周期で複数の組込電子機器をスキャンし、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得し、メモリは、取得された複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、オブジェクトＩＤがＳＮＭＰマネージャから供給された際に、オブジェクトＩＤのうち、組込電子機器の種類を示す識別子を参照することにより、メモリに保持された配列から、問い合わせの対象となる組込電子機器を特定し、問い合わせの対象となる組込電子機器が組み込まれている場合に、オブジェクトＩＤを問い合わせの対象となる組込電子機器に渡すようにした組込型電子機器である。
【００１２】
また、この発明は、オブジェクト情報が格納されるオブジェクト情報格納手段を有し、
オブジェクト情報が、組込型電子機器を介してＳＮＭＰマネージャの管理対象となるオブジェクトを示すものである組込電子機器である。
【００１３】
また、この発明は、複数の組込電子機器をそれぞれ接続するための組み込みのステップと、ネットワークを介してＳＮＭＰマネージャとの通信を行う第１の通信のステップと、ＳＮＭＰに基づくオブジェクトＩＤをＳＮＭＰとは異なるプロトコルに変換する変換のステップと、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得する機器情報取得のステップと、複数の組込電子機器に対してＳＮＭＰとは異なるプロトコルを用いて通信を行う第２の通信のステップとを備え、ＳＮＭＰが実装されプロキシ・エージェントの機能を持つシステム用ＣＰＵおよびメモリを有するシステム基板を備えた組込型電子機器により、機器情報取得のステップにおいて、所定の周期で複数の組込電子機器をスキャンし、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得し、メモリは、取得された複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、オブジェクトＩＤがＳＮＭＰマネージャから供給された際に、オブジェクトＩＤのうち、組込電子機器の種類を示す識別子を参照することにより、メモリに保持された配列から、問い合わせの対象となる組込電子機器を特定し、問い合わせの対象となる組込電子機器が組み込まれている場合に、オブジェクトＩＤを問い合わせの対象となる組込電子機器に渡すようにした組込電子機器の管理方法である。
【００１４】
また、この発明は、組込型電子機器が有するＣＰＵおよび組込型電子機器に組み込まれる組込電子機器の種類に応じてグループ分けしたグループ識別子を配し、組込電子機器の種類を示すグループ識別子の値が、組込型電子機器が有するＣＰＵを示すグループ識別子の値よりも大であるとされたＭＩＢ構造を表すオブジェクトＩＤを用い、組込型電子機器に組み込まれる組込電子機器を、組込型電子機器を介してＳＮＭＰマネージャにより管理する組込電子機器の管理方法である。
【００１５】
上述したように、この発明は、機器情報取得手段が、所定の周期で複数の組込電子機器をスキャンし、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得し、メモリが、取得された複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、オブジェクトＩＤがＳＮＭＰマネージャから供給された際に、オブジェクトＩＤのうち、組込電子機器の種類を示す識別子を参照することにより、メモリに保持された配列から、問い合わせの対象となる組込電子機器を特定し、問い合わせの対象となる組込電子機器が組み込まれている場合に、オブジェクトＩＤを問い合わせの対象となる組込電子機器に渡すようにしているため、筐体内における組込電子機器の拡張が容易である。
【００１６】
また、この発明は、組込電子機器が、オブジェクト情報が格納されるオブジェクト情報格納手段を有し、オブジェクト情報が、組込型電子機器を介してＳＮＭＰマネージャの管理対象となるオブジェクトを示すものであるため、オブジェクトを管理する外部においてオブジェクト情報を持つ必要がない。
【００１７】
また、この発明は、組込型電子機器が有するＣＰＵおよび組込型電子機器に組み込まれる組込電子機器の種類に応じてグループ分けしたグループ識別子を配し、組込電子機器の種類を示すグループ識別子の値が、組込型電子機器が有するＣＰＵを示すグループ識別子の値よりも大であるとされたＭＩＢ構造を表すオブジェクトＩＤを用い、組込型電子機器に組み込まれる組込電子機器を、組込型電子機器を介してＳＮＭＰマネージャにより管理するようにしているため、組込型電子機器に組み込まれた組込電子機器をＭＩＢを用いて管理できる。
【００１８】
【発明の実施の形態】
以下、この発明の実施の一形態を、図面を参照しながら説明する。図１は、この発明を適用可能な一例のシステムを示す。ネットワーク１にＳＮＭＰマネージャ２とＳＮＭＰエージェント３とが接続される。これらＳＮＭＰマネージャ２とＳＮＭＰエージェント３との間では、ＳＮＭＰ標準のオペレーションやイベント通知がネットワーク１を介してやりとりされる。
【００１９】
この実施の一形態では、ＳＮＭＰエージェント３は、例えばＭＰＥＧ２(Moving Pictures Experts Group 2)方式に対応したビデオプロセッサ３である。後述するが、ビデオプロセッサ３は、内部に組み込まれた基板の機能に応じた処理を行う。図１の例では、ビデオプロセッサ３は、入力されたディジタルビデオ信号およびディジタルオーディオ信号を、所定にエンコードしてＭＰＥＧ２方式によるトランスポートストリームにして出力する機能を有する。また、ビデオプロセッサ３は、入力されたＭＰＥＧ２方式によるトランスポートストリームを所定にデコードし、例えば標準のディジタルビデオ信号およびディジタルオーディオ信号にして出力する機能を有する。
【００２０】
ビデオプロセッサ３において、バス２０にシステム基板１０が接続される。図示しないが、システム基板１０には、システム用ＣＰＵ(Central Processing Unit)、マルチプレクス用ＣＰＵおよび統計多重用ＣＰＵの３つのＣＰＵが搭載され、それぞれのＣＰＵによって所定の機能が実現される。また、バス２０に対して複数のスロット１１Ａ、１１Ｂ、１１Ｃ、１１Ｄおよび１１Ｅが接続される。
これらスロット１１Ａ、１１Ｂ、・・・に基板３０、３０、・・・を装着することで、その基板３０、３０、・・・がバス２０に所定に接続され、ビデオプロセッサ３においてその基板３０、３０、・・・の機能が有効になる。
【００２１】
なお、図１では、基板３０、３０、・・・を、説明のため基板３０Ａ、３０Ｂ、・・・とそれぞれ区別している。
【００２２】
図１の例では、スロット１１Ａ、１１Ｂおよび１１Ｅに、標準解像度ビデオ信号（ＳＤ）に対応したビデオエンコーダである基板３０Ａ（ＥＮＣ（１））、３０Ｂ（ＥＮＣ（２））および３０Ｄ（ＥＮＣ（３））が装着され、スロット１１Ｄにオーディオエンコーダである基板３０Ｃ（ＡＰＲ（１））が装着される。例えばシステム基板１０は、入出力インターフェイスの機能を有し、システム基板に入力された信号は、バス２０を介してこれら基板３０Ａ〜３０Ｄに供給される。なお、図１の例では、「φ」と記されたスロット１１Ｃには、基板３０が装着されていない。
【００２３】
上述したように、ビデオプロセッサ３は、スロット１１Ａ〜１１Ｅに装着される基板３０が有する機能に応じた処理を行うことができる。図２は、ビデオプロセッサ３に装着可能な基板３０の例を示す。各基板３０、３０、・・・には、その基板３０の種類に応じてそれぞれ識別番号が割り当てられる。基板ＯＰＭは、システム基板１０であり、システム基板１０にのせられたシステム用ＣＰＵ、マルチプレクス用ＣＰＵおよび統計多重用ＣＰＵに、識別番号１、２および３番がそれぞれ割り当てられる。システム基板１０には、このように、最小の識別番号から順に識別番号が割り当てられる。
【００２４】
一方、各基板３０、３０、・・・には、システム基板１０の識別番号の次の値から、基板３０の種類毎に識別番号が割り当てられる。基板ＩＰＭは、トランスポートストリームの入力部であり、識別番号が４番とされる。エンコーダである基板ＥＮＣは、識別番号が５番とされる。基板ＶＰＲは、高精細解像度ビデオ信号（ＨＤ）に対応したビデオエンコーダであり、識別番号が６番とされる。基板ＤＥＣは、ビデオデコーダであり、識別番号が７番とされる。オーディオエンコーダである基板ＡＰＲは、識別番号が８番とされる。
【００２５】
この例では、このように識別番号が８番までが予約されており、新たに開発された基板には、９番以降の識別番号が順次割り当てられることになる。
【００２６】
なお、上述ではビデオプロセッサ３にはスロットが５個、設けられ、基板が５枚装着可能として説明したが、これはこの例に限定されない。例えば、スロットは、筐体の大きさに応じて異なる数を設けることができる。なお、スロット１１Ａ、１１Ｂ、・・・は、基板３０の活電挿抜が可能とされており、ビデオプロセッサ３が稼働中でも、スロット１１Ａ、１１Ｂ、・・・の状況が変わり得る。すなわち、ビデオプロセッサ３の稼働中に、スロット１１Ａ、１１Ｂ、・・・に装着される基板３０が変更されることが有り得る。さらに、ビデオプロセッサ３は、用途に応じて必要な機能を有する基板３０を選択し、筐体内に複数種類および複数枚の基板３０を装着することが可能とされている。
【００２７】
図２で上述した各基板のうち、ＳＮＭＰが実装されている、すなわち、ＳＮＭＰによる送受信が可能で、且つ、ＡＮＳ．１コーデック機能（ＳＮＭＰのパケットのコーデック機能）を持つのは、システム基板１０（基板ＯＰＭ）上のシステム用ＣＰＵのみであり、また、外部との通信ポートを持つのもシステム用ＣＰＵのみである。したがって、システム基板１０がＳＮＭＰのプロキシ・エージェントとなる。実際には、システム基板１０におけるシステム用ＣＰＵがプロキシ・エージェントとしての機能を果たす。このシステム基板１０（基板ＯＰＭ）は、このビデオプロセッサ３の構成において必須である。
【００２８】
ＳＮＭＰマネージャ２によるビデオプロセッサ３の管理は、従来の技術の項で図２１を用いて説明した方法と同様にして行われる。すなわち、システム基板１０をプロキシ・エージェントとして、ＳＮＭＰマネージャ２とシステム基板１０との間でネットワーク１を介して通信が行われ、ＳＮＭＰによる標準的なオペレーションコマンドやイベント通知がやりとりされる。システム基板１０では、例えば、ＳＮＭＰマネージャ２からＳＮＭＰにより送られたオペレーションコマンドやイベント通知が、ビデオプロセッサ３独自のオペレーションコマンドやイベント通知に変換される。変換されたこれらコマンドや通知がバス２０を介して、スロット１１Ａ、１１Ｂ、・・・に装着された各基板３０、３０、・・・に供給される。また、各基板３０、３０、・・・から出力された、ビデオプロセッサ３独自のコマンドやイベント通知は、バス２０を介してシステム基板１０に供給され、ＳＮＭＰによるコマンドやイベント通知に変換される。変換されたコマンドやイベント通知は、ネットワーク１を介してＳＮＭＰマネージャ２に送られる。
【００２９】
この実施の一形態においては、ビデオプロセッサ３のスロット１１Ａ、１１Ｂ、・・・に装着される各基板３０、３０、・・・のオブジェクトは、各基板３０、３０、・・・側でそれぞれが持つ。こうすることで、プロキシ・エージェントであるシステム基板１０上のシステム用ＣＰＵは、スロット１１Ａ、１１Ｂ、・・・に装着される各基板３０、３０、・・・のオブジェクトそれぞれに特有のオブジェクトに関する情報から解放される。
【００３０】
なお、ここでオブジェクトは、ＭＩＢにおける項目を指す。例えば、上述したエンコーダである基板ＥＮＣでは、「ビットレート」、「サンプリングレート」、「入力信号の種類」などのエンコーダのパラメータに対するＳＮＭＰによるコマンドの一つ一つがオブジェクトとされる。すなわち、オブジェクトは、ＳＮＭＰマネージャ２による管理対象である。
【００３１】
図３は、ＭＩＢ一例の構成を示す。ＭＩＢは、世界的に標準化されており、ツリー構造を有している。この図３の例では、最上位がインターネット（ｉｎｔｅｒｎｅｔ（１））とされ、その下位にツリーが構成される。図示は省略するが、実際には、「ｉｎｔｅｒｎｅｔ（１）」も、さらに上位のツリー構造の一部である。「ｅｎｔｅｒｐｒｉｓｅ（１）」より上位がグローバルな階層である。「ｘｘｘ（ｎ）」より下位がベンダローカルな階層とされ、例えばｘｘｘ社の製品は、「ｘｘｘ（ｎ）」より下層に位置する。また、ｘｘｘ社の製品である上述のビデオプロセッサ３（図３における「ｙｙｙｙ（６００４）」）に装着される各基板３０、３０、・・・は、「ｙｙｙｙ（６００４）」より下層に位置する。
【００３２】
なお、ツリー構造の各枝において括弧「（）」内に記される値は、それぞれの階層においてＭＩＢオブジェクトを識別するための識別子である。このツリー構造の各枝は、上位から下位にかけて、各層の識別子と各層を互いに区別するための区切り識別子であるピリオド（．）とによって一意的に表現される。例えば、最下層の基板ＥＮＣ（７）は、「１．４．１．ｎ．６００４．７」として表される。実際には、より上位の階層からの識別子を用いて、「１．３．６．１．４．１．ｎ．６００４．７」と表現される。これは、オブジェクトＩＤと称される。
【００３３】
ビデオプロセッサ３に装着される基板３０、３０、・・・は、種類毎に識別子が割り当てられ、基板種類毎にオブジェクトグループが分かれている。図３では、オブジェクト「ＳＹＳ／ＯＰＭ（３）」以下に示される、括弧（）内の添え字が３以上のオブジェクトがこれに当たる。
【００３４】
新たな機能を持つ基板３０が開発された場合には、さらに異なる識別子が与えられ、図３に「？？？（１１）」、「？？？（１２）」として示されるように、オブジェクトを増やすことができる。このとき、基板３０側がオブジェクトを持っているので、プロキシ・エージェントに手を加えることなく、ＳＮＭＰマネージャ２が持つＭＩＢ定義ファイルを変更するだけで、オブジェクトを追加できる。これにより、追加された基板３０についてのＭＩＢ監視も可能となる。
【００３５】
なお、システム基板１０は、上述したように機能毎に３つのＣＰＵを持ち、識別子は、これら３つのＣＰＵにもそれぞれ割り当てられる。
【００３６】
また、図示しないが、各基板のそれぞれは、さらに下位にオブジェクトを持つことができる。例えば、各基板に対するＳＮＭＰマネージャ２による管理コマンドのそれぞれがオブジェクトとされる。各基板は、階層的にオブジェクトを持つことができる。下位のオブジェクトは、オブジェクトに対するポインタが記されるオブジェクトテーブルにより参照される。
【００３７】
図４は、ビデオプロセッサ３に装着される基板３０の一例の構成を概略的に示す。基板３０は、バス３１を有し、バス３１に対してＣＰＵ３２、ＲＯＭ(Read Only Memory)３３および通信インターフェイス３４が接続される。通信インターフェイス３４は、コネクタ３５に接続される。また、バス３１に、この基板３０の主要な機能を司る機能部３６が接続される。この基板３０が上述したエンコーダ基板ＥＮＣである場合には、外部から供給されたディジタルビデオ信号がこの機能部３６に入力され、所定にエンコード処理され、機能部３６から出力される。コネクタ３５がスロット１１Ａ、１１Ｂ、・・・に挿入されることで、基板３０とシステム基板１０とが電気的に結合される。例えば、システム基板１０に搭載される３つのＣＰＵから出力された指令がコネクタ３５から通信インターフェイス３４に供給され、バス３１を介してＣＰＵ３２に渡される。この指令に基づきＣＰＵ３２により機能部３６が制御され、機能部３６に入力された信号に対する所定の処理が行われる。
【００３８】
このような構成において、オブジェクトの情報は、例えばＲＯＭ３３に予め記憶される。ＲＯＭ３３に記憶された情報は、例えばシステム基板１０に搭載されたシステム用ＣＰＵからの指令に基づくＣＰＵ３２の制御により読み出され、通信部３４およびコネクタを介してシステム基板１０に渡される。
【００３９】
次に、システム基板１０側、すなわち、プロキシ・エージェント側での組み込み方法について説明する。システム基板１０においてプロキシ・エージェントの機能を持つシステム用ＣＰＵにより、バス２０に接続される全スロット１１Ａ、１１Ｂ、・・・をある一定の周期でスキャンし、基板３０の種類毎に何枚が装着されているかが調べられる。システム用ＣＰＵでは、例えば図示されないメモリを利用し、予め基板３０の種類数以上の配列が用意され、上述した図２に示される識別番号とその識別番号が示す基板３０の枚数とが対応付けられて保持される。
【００４０】
図５は、上述の図１に示されるビデオプロセッサ３における、識別番号の一例の配列の内容を示す。識別子が３、４および５は、システム基板１０上の３つのＣＰＵにそれぞれ対応し、枚数がそれぞれ１となっている。図１のビデオプロセッサ３では、３枚の基板ＥＮＣと１枚の基板ＡＰＲが装着されているので、対応する識別子７および１０は、それぞれ枚数が３および１となっている。その他の識別子を持つ基板３０は、装着されていないので枚数が０となっている。
【００４１】
ＳＮＭＰマネージャ２からの、ビデオプロセッサ３に装着された各基板への問い合わせは、上述したオブジェクトＩＤを用いてなされる。例えば基板ＥＮＣに対して問い合わせが行われる場合には、オブジェクトＩＤ｛１．３．６．１．４．１．ｎ．６００４．７．＊｝が用いられる。なお、基板の種類を示す識別子「７」の次の「＊」は、任意の長さの識別子が許されることを示す。また、オブジェクトＩＤの最後尾には、基板種類毎のさらに詳細な項目を示すインデックスを付すことができる。例えば同種の基板３０が複数枚装着されている場合に、インデックスを用いて区別することができる。
【００４２】
ＳＮＭＰマネージャ２から送信された問い合わせは、ビデオプロセッサ３に受信され、システム基板１０上のシステム用ＣＰＵに渡される。システム用ＣＰＵ（プロキシ・エージェント）では、渡された問い合わせに含まれるオブジェクトＩＤの特定の値が書かれている場所を見て、対象となる基板３０が判断される。
例えばこの例では、オブジェクトＩＤの「６００４．」の次に書かれている値（この例では「７」）が調べられる。そして、この値に基づき、上述の図５に示されるような配列が参照され、該当する基板３０が装着されているかどうかが判断される。該当する基板３０が装着されていると判断されれば、ＳＮＭＰマネージャ２から送信された問い合わせが、問い合わせに用いられるコマンドがＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔであるか、ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔであるかに応じた方法で、当該基板３０に渡される。
【００４３】
なお、ＳＮＭＰマネージャ２から送られてきた問い合わせは、ＳＮＭＰが用いられている。システム用ＣＰＵでは、上述のようにして問い合わせを基板３０に渡す際に、プロトコルを基板３０に対応した形式に変換する。
【００４４】
同種の基板３０が１台の筐体に複数枚装着されている場合に、ＳＮＭＰ上でそれら複数の同種基板を互いに区別する必要がある。上述したビデオプロセッサ３の例では、スロット１１Ａ、１１Ｂ、・・・のそれぞれに、スロット番号の小さい方から同種基板識別用のインデックスが付与される。
【００４５】
図６は、この場合のオブジェクトＩＤの一例の構造を示す。ＳＮＭＰマネージャ２から送られるオブジェクトＩＤは、例えば｛１．３．６．１．４．１．ｎ．６００４．ｘ．ｙ．ｙ．ｙ．ｙ．ｙ．ｚ｝と記述される。このうち、｛１．３．６．１．４．１．ｎ．６００４｝が当該装置であるビデオプロセッサ３を示す。
次の「ｘ」がビデオプロセッサ３に装着される基板３０の種別を示す基板別グループ番号である。この｛ｘ｝が上述の図２に示した基板種類識別番号に対応する。この｛ｘ｝と、次の｛ｙ．ｙ．ｙ．ｙ．ｙ｝で、完全なコマンド列が構成される。最後尾の｛ｚ｝が同種基板識別用のインデックスである。
【００４６】
このようなオブジェクトＩＤに基づくプロキシ・エージェント側の処理について説明する。処理は、実際には、システム基板１０上に搭載されるシステム用ＣＰＵにより実行される。ＳＮＭＰマネージャ２からシステム用ＣＰＵに対して、オブジェクトＩＤ｛１．３．６．１．４．１．ｎ．６００４．ｘ．＊｝というオブジェクトの参照要求が送信される。なお、最後尾の｛＊｝は、１または複数の任意の識別子を示す。このオブジェクトＩＤが受信されたプロキシ・エージェントにより、受信されたオブジェクトＩＤに基づき、基板種類識別子が｛ｘ｝に対応し、受信された要求の種類（ＧＥＴ／ＧＥＴＮ／ＳＥＴ）に応じて、インデックスが対応する基板に対して、受信されたオブジェクトＩＤが渡される。
【００４７】
受信されたオブジェクトＩＤが対応する基板３０に渡されると共に、スロット１１Ａ、１１Ｂ、・・・に装着されている当該基板３０と同一種類の基板枚数と、同種基板識別インデックスとが当該基板３０に渡される。各基板３０、３０、・・・側では、プロキシ・エージェントから渡されたこれらの情報に基づき、処理が行われる。
【００４８】
一方、プロキシ・エージェント側でも、システム用ＣＰＵにおいてオブジェクトテーブルが持たれており、オブジェクトテーブルの最後尾には、他の基板３０、３０、・・・宛のポインタを擁している。プロキシ・エージェントでは、このオブジェクトテーブルにおいて、ＳＮＭＰマネージャ２から送られてきたオブジェクトＩＤを見て、｛１．３．６．１．４．１．ｎ．６００４．ｘ｝のうち先頭から’６００４’までが一致し、且つ、送られてきたオブジェクトＩＤが｛１．３．６．１．４．１．ｎ．６００４．ｘ｝以上の長さを持つものについて、’ｘ’の値が確認される。
【００４９】
その結果、’ｘ’の値が、上述の図３における「ＭＵＸ（４）」以上の値であれば、そのオブジェクトＩＤは、上述のシステム用ＣＰＵが持つオブジェクトテーブルの最後尾に記される、他の基板３０宛のオブジェクトＩＤであると見なされる。このオブジェクトＩＤは、’ｘ’の値に対応する基板３０に渡される。このように構成することで、今後、基板３０の種類が増加しても、プロキシ・エージェントにおける動作変更の必要がない。
【００５０】
なお、この実施の一形態によるビデオプロセッサ３は、例えば、システム用ＣＰＵと他基板３０、３０、・・・との間の通信が最大１６種類の基板種類まで対応するように作られている。したがって、基板種類がこの範囲内であれば、新たに開発された基板３０をそのままビデオプロセッサ３に装着することで、装着された基板３０における被プロキシ機能が実現される。データを渡すスロット１１Ａ、１１Ｂ、・・・の識別には、「基板の種類」と「同種基板識別用のインデックス」とが用いられる。
【００５１】
上述したように、ＳＮＭＰマネージャ２から送信された問い合わせが、問い合わせに用いられるコマンドがＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔであるか、ＧＥＴＮｅｘｔ Ｒｅｑｕｅｓｔであるかにより、問い合わせを基板に渡す方法が異なる。ＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔの場合には、オブジェクトＩＤとインデックスとが特定されているのが前提であって、オブジェクトＩＤの最後尾にインデックスが書かれている。そのため、データは、該当する種類の中で指定された基板３０に、直接的に引き渡される。
【００５２】
図７は、ＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す。この場合、図６における同種基板識別インデックスを示す値’ｚ’がオブジェクトＩＤに含まれていることが前提の処理となる。したがって、システム用ＣＰＵにより、オブジェクトＩＤに含まれる、図６における値’ｘ’および’ｚ’に基づき、直接的に、操作対象とされる基板３０Ｂ（基板ＥＮＣ（２））にオブジェクトＩＤが渡される。この図７の例では、｛１．３．６．１．４．１．ｎ．６００４．７．ｙ．ｙ．ｙ．ｙ．ｙ．２｝という、コマンドおよびインデックスが含まれたオブジェクトＩＤが送られている。
【００５３】
一方、ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔの場合には、オブジェクトＩＤとインデックスとが不確定な状態で要求されることがある。この場合、図６における’ｙ．ｙ．ｙ．ｙ．ｙ’の一部または全部および’ｚ’の値が含まれない状態で、オブジェクトＩＤがＳＮＭＰマネージャ２から送られてくる可能性がある。そのため、’ｘ’の値のみに基づき、’ｘ’の値に該当する種類の基板３０が複数枚、筐体内に装着されている場合、それらのうちの、添え字（図１参照）が最も小さい基板３０に、オブジェクトＩＤが渡される。例えば、同種類の基板で、スロット１１Ａ、１１Ｂ、・・・のうち最もスロット番号が小さいスロットに挿入された基板に、オブジェクトＩＤが渡される。
【００５４】
図８は、ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す。この図８の例では、｛１．３．６．１．４．１．ｎ．６００４．７．＊｝という、コマンドおよびインデックスが含まれていないオブジェクトＩＤが送られている。
【００５５】
例えば、’ｘ’が、この例のようにエンコーダ基板ＥＮＣを表している場合、先ず「（）」内の添え字が最も小さい値の基板３０Ａ（ＥＮＣ（１））にオブジェクトＩＤが渡される。オブジェクトＩＤに基づき、基板３０Ａ（ＥＮＣ（１））側で値’ｚ’が調べられ、このオブジェクトＩＤが自分宛でないと判断されると、基板３０Ａ（ＥＮＣ（１））からシステム用ＣＰＵに、その旨示すメッセージ「ＮＡＣＫ」が送られる。この「ＮＡＣＫ」を受け取ったシステム用ＣＰＵでは、「（）」の添え字が次の値の同種基板、すなわち基板３０Ｂ（ＥＮＣ（２））にオブジェクトＩＤが渡される。基板３０Ｂ（ＥＮＣ（２））も該当する基板でないときには、添え字が次の値の同種の基板である基板３０Ｄ（ＥＮＣ（３））が調べられる。
【００５６】
また、ＳＮＭＰマネージャ２から送られてきたオブジェクトＩＤの値’ｘ’に基づき、該当する基板が存在しないと判断されれば、システム用ＣＰＵにより図５の配列が検索され、値が’ｘ’以上の基板があればその基板にオブジェクトＩＤが渡される。例えば、上述のように基板ＥＮＣ４１、４２および４４を調べて該当する基板が無い場合、’ｘ’値が’８’である基板３０Ｃ（ＡＰＲ（１））にオブジェクトＩＤが渡され、同様に該当する基板があるかどうかが探索される。
【００５７】
若し、最終的に、オブジェクトＩＤに該当する基板が無いとされた場合には、システム用ＣＰＵにより処理が引き取られる。
【００５８】
次に、システム用ＣＰＵによる他基板宛のＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎについて、より詳細に説明する。図９は、基板３０側のＭＩＢ情報の一例の構成を示す。このように、基板３０内では、ツリー構造でオブジェクトを持つことができる。オブジェクトテーブルは、ｔａｂｌｅ＃１、＃２、・・・で示されるように、ツリーの幹の部分を構成する。図９の例では、オブジェクトテーブルに対して、上位のオブジェクトテーブルから近い順に＃１、＃２、＃３、・・・と番号が付けられる。
【００５９】
また、ツリーの葉に相当する部分は、オブジェクトそのものを表す。それぞれのオブジェクトは、ツリー構造を反映するように、そのオブジェクトが属するオブジェクトテーブルに付された番号と、同一テーブルに属するオブジェクトを識別するための通し番号とからなる識別符号が付される。例えば、影が付されたオブジェクトは、「２−１−３」と識別符号が付され、オブジェクトテーブルｔａｂｌｅ＃２の下に属するｔａｂｌｅ＃１の、３番目のオブジェクトであることが分かる。
【００６０】
一方、システム用ＣＰＵと各基板３０、３０、・・・との間でなされるＧＥＴＮｅｘｔ Ｒｅｑｕｅｓｔによる通信のために、図１０に一例が示される、１バイトのＧＥＴＮ操作用のフィールドが用意される。これら第０〜第７ビットからなる１バイトで、ＧＥＴＮ操作用フィールドの値（８０Ｈ、８Ｈ、４Ｈ、２Ｈ、１Ｈおよび０）が定義される。値表記における「Ｈ」は、その数が１６進表記されていることを示す。
【００６１】
第０ビットが’１’であれば、ＧＥＴＮ操作用フィールドの値が’１Ｈ’とされ、オブジェクトを固定して次の同種のＣＰＵ（基板３０や機能ブロック）に処理が移されることが示される。すなわち、この場合には、同種のオブジェクトが異なるオブジェクトテーブル間で探されることになる。第１ビットが’１’であれば、ＧＥＴＮ操作用フィールドの値が’２Ｈ’とされ、次のオブジェクトに処理が移されることが示される。すなわち、この場合には、同一オブジェクトテーブル内で、ツリー構造を枝側から葉側へと辿ってオブジェクトが探される。第２ビットが’１’であれば、ＧＥＴＮ操作用フィールドの値が’４Ｈ’とされ、次のグループに処理が移されることが示される。この場合には、互いに対応する番号のオブジェクトテーブル、例えばｔａｂｌｅ＃１が全て検索の対象とされる。
【００６２】
第３ビットが’１’であれば、当該ＣＰＵ（基板３０や機能ブロック）からのデータが終了されたことが示される。また、システム用ＣＰＵへのＡＣＫ応答時には、第７ビットが’１’とされ、ＧＥＴＮ操作用フィールドの値が’８０Ｈ’とされる。なお、このＧＥＴＮ操作用フィールドの値が’０’であれば、システム用ＣＰＵから各基板３０、３０、・・・に対する最初のアクセスであることが示される。
【００６３】
ＳＮＭＰマネージャ２から送られてきたオブジェクトＩＤと、システム用ＣＰＵが保有している基板構成の配列（図５参照）が、装着されている基板３０、３０、・・・にそれぞれ渡される。基板３０側では、｛オブジェクトＩＤ，システム用ＣＰＵが持つその基板のインデックス，ＧＥＴＮ操作用のフィールド｝の３つの値を用いて、自分宛の要求かどうかが判断される。
【００６４】
図１１は、基板３０におけるオブジェクトＩＤの一例の判別方法を示すフローチャートである。なお、ＧＥＴＮ操作用フィールドの値が’０’であれば、システム用ＣＰＵにより最初にこのフローチャートによる処理が行われることが示される。最初のステップＳ１０では、システム用ＣＰＵから基板３０に対してオブジェクトＩＤが渡され、基板３０では、ＲＯＭ３３に記憶された情報に基づきオブジェクトが検索される。オブジェクトの検索方法については後述するが、このとき、上述したシステム用ＣＰＵが持つその基板のインデックス、ＧＥＴＮ操作用のフィールドも、オブジェクトＩＤと共に渡される。
【００６５】
次のステップＳ１１で、該当するオブジェクトＩＤがあるかどうかが判断される。若し、ステップＳ１１で、該当するオブジェクトＩＤが無いと判断されれば、処理はステップＳ２２に移行する。ステップＳ２２では、ＧＥＴＮ操作用フィールドが参照され、値が’１’以下であれば、値が’１’にセットされる。そして、処理はステップＳ１９に移行し、基板３０からシステム用ＣＰＵに応答される。
【００６６】
一方、ステップＳ１１で、該当するオブジェクトＩＤがあると判断されれば、処理はステップＳ１２に移行する。ステップＳ１２では、そのオブジェクトが葉であるかどうかが判断される。若し、葉ではないと判断されれば、当該オブジェクトは、オブジェクトテーブルであるので、処理はステップＳ１３に移行し、そのオブジェクトテーブル内での最初のオブジェクトが検索される。そして、処理はステップＳ１１に戻され、ステップＳ１３での検索結果に基づく判断がなされる。
【００６７】
一方、ステップＳ１２で、検索されたオブジェクトが葉であると判断されれば、処理はステップＳ１４に移行し、ＧＥＴＮ操作用フィールドの値が’１’以下であるかどうかが判断される。若し、’１’以下であると判断されれば、処理はステップＳ１５に移行し、オブジェクト内に任意の値のインデックス’ｐ’があるかどうかが判断される。
【００６８】
若し、ステップＳ１５でインデックス’ｐ’がオブジェクト内に見つかれば、ステップＳ１７で、その値’ｐ’とシステム用ＣＰＵから指定されたインデックス’ｑ’とが比較される。比較の結果、（’ｐ’＜’ｑ’）であれば、処理はステップＳ２２に移行し、ＧＥＴＮ操作用フィールドの値が’１’以下であれば’１’とされ、基板３０からシステム用ＣＰＵに対して応答される。
【００６９】
なお、ステップＳ１５でインデックス’ｐ’がオブジェクト内に見つからなかったときには、システム用ＣＰＵから指定されたインデックス’ｑ’に基づき’ｑ−１’がインデックス’ｐ’とされ、処理はステップＳ１７に移行する。
【００７０】
一方、ステップＳ１７で、値’ｐ’と’ｑ’との比較の結果、（’ｐ’≧’ｑ’）であれば、処理はステップＳ１８に移行し、オブジェクトＩＤが決定されると共に、インデックスに’ｑ’が採用される。そして、処理はステップＳ１９に移行し、基板３０からシステム用ＣＰＵに応答される。
【００７１】
また、上述のステップＳ１４において、ＧＥＴＮ操作用フィールドの値が’１’以下でないと判断された場合、処理はステップＳ２０に移行する。ステップＳ２０では、ＧＥＴＮ操作用フィールドの値に基づき、次のオブジェクトあるいは次のグループが検索される。検索結果は、次のステップＳ２１で判断される。次のオブジェクトあるいはグループに目的のオブジェクトが見つかった場合には、処理はステップＳ１８に移行し、オブジェクトＩＤが決定されると共に、インデックスとしてシステム用ＣＰＵから指定された’ｑ’が採用される。
【００７２】
一方、ステップＳ２１において、次のオブジェクトあるいはグループに目的のオブジェクトが見つからないと判断された場合には、処理はステップＳ２２に移行し、ＧＥＴＮ操作用フィールドが’１’以下であれば’１’にされてステップＳ１９でシステム用ＣＰＵに応答される。
【００７３】
なお、上述の図１１のフローチャートによる処理おいて、システム用ＣＰＵから最初にデータを渡された基板３０で該当するオブジェクトが見つかった場合、システム用ＣＰＵからＳＮＭＰマネージャ２に対して応答される。一方、該当するオブジェクトが見つからなかった場合には、基板３０側でＧＥＴＮ操作用フィールドの値が’１’とされ、基板３０からシステム用ＣＰＵに対して’ＮＡＣＫ’が返される。また、連続したＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎが既に参照された基板３０’に渡された場合にも、基板３０’においてＧＥＴＮ操作用フィールドの値が適当な値にされ、基板３０’からシステム用ＣＰＵに対して’ＮＡＣＫ’が返される。
【００７４】
また、ＳＮＭＰマネージャ２からシステム用ＣＰＵに送られたＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎは、必ず、システム基板１０のシステム用ＣＰＵ経由で、対応する種類の基板中で最もインデックスが小さい基板に渡される。例えば、上述のビデオプロセッサ３において、スロット１１Ａ、１１Ｂ・・・の順にインデックスが割り当てられるとすれば、同種の基板のうち最も小さいインデックス値が割り当てられるスロットに装着されている基板に、ＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎによる指示が渡される。
【００７５】
次に、図１２のフローチャートを用いて、上述した図１１のステップＳ１９で基板３０からの応答を受け取った、システム用ＣＰＵにおける処理について説明する。最初のステップＳ７０で、基板３０からの応答がシステム用ＣＰＵに受け取られる。そして、ステップＳ７１、Ｓ７２およびＳ７３において、ＧＥＴＮ操作用フィールドの値に基づき処理が分岐される。
【００７６】
ステップＳ７１では、ＧＥＴＮ操作用フィールドの値が’８０Ｈ’以上であるかどうかが判断される。若し、’８０Ｈ’以上であれば、処理はステップＳ８０に移行し、システム用ＣＰＵにおいて、ＧＥＴＮ操作用フィールドに対応したＳＮＭＰパケットが生成される。生成されたＳＮＭＰパケットは、次のステップＳ８７でシステム用ＣＰＵからＳＮＭＰマネージャ２に送信される。
【００７７】
ステップＳ７１で、ＧＥＴＮ操作用フィールドの値が’８０Ｈ’以上ではないと判断されれば、処理はステップＳ７２に移行する。ステップＳ７２では、ＧＥＴＮ操作用フィールドの値が’１Ｈ’乃至’４Ｈ’であるかどうかが判断される。若し、’１Ｈ’乃至’４Ｈ’であれば、処理はステップＳ８１に移行し、当該応答を渡した基板３０が同種基板のうち最後の基板であるかどうかが判断される。これは、例えば当該基板のインデックスと、システム用ＣＰＵが保持する基板構成配列（図５参照）における当該基板と同種類の基板枚数を比較することで、判断できる。
【００７８】
ステップＳ８１の判断において、若し、当該基板３０が同種類の基板のうち最後の基板であると判断されれば、処理はステップＳ８２に移行する。ステップＳ８２では、ＧＥＴＮ操作用フィールドが１ビット左にシフトされ、再び同一の基板３０にデータが渡される。そして、基板３０において、ビットが左にシフトされたＧＥＴＮ操作用フィールドに基づき、上述した図１１による処理がなされる。
【００７９】
一方、ステップＳ８１で当該基板３０が同種類の基板のうち最後の基板で無いと判断されれば、処理はステップＳ８３に移行する。ステップＳ８３では、インデックスが次の番号の同種基板に、システム用ＣＰＵが受け取ったデータをそのまま渡す。そして、基板３０において、渡されたデータに基づき、上述した図１１による処理がなされる。
【００８０】
ステップＳ７２でＧＥＴＮ操作用フィールドの値が’１Ｈ’乃至’４Ｈ’でないと判断されれば、処理はステップＳ７３に移行する。ステップＳ７３では、ＧＥＴＮ操作用フィールドの値が’８Ｈ’であるかどうかが判断される。若し、’８Ｈ’で無いとされれば、ステップＳ７４で、エラーが発生したと判断される。
【００８１】
ＧＥＴＮ操作用フィールドの値が’８Ｈ’であると判断されれば、処理はステップＳ８４に移行する。ステップＳ８４では、対象になっている基板種類以降の基板が装着されているかどうかが判断される。例えば、システム用ＣＰＵにおいて、上述の図５の基板構成配列が参照され、対象となっている基板種類のグループ番号より大きいグループ番号の基板が装着されているかどうかが判断される。
【００８２】
若し、対象になっている基板種類以降の基板が装着されていると判断されれば、処理はステップＳ８５に移行する。そして、ステップＳ８５で、システム用ＣＰＵにおいてＧＥＴＮ操作用フィールドがリセットされ値が’０’とされ、次の種類の基板にデータが渡される。
【００８３】
一方、ステップＳ８４で、対象になっている基板種類以降の基板が装着されていないと判断されれば、処理はステップＳ８６に移行する。ステップＳ８６では、システム用ＣＰＵ側で、ＭＩＢの最後であることを通知するパケットが生成される。そして、処理はステップＳ８７に移行し、そのパケットがＳＮＭＰマネージャ２に送信される。
【００８４】
次に、基板３０における被プロキシ・エージェント側での処理について説明する。基板３０は、上述した図９に一例が示されるようなＭＩＢ情報を有する。このＭＩＢ情報は、ＳＮＭＰによるＭＩＢ情報がこの基板３０独自の形式に変換されて、基板３０に保持される。ＭＩＢ情報は、例えばＲＯＭ３３に予め記憶され、基板３０に保持される。なお、同種類の基板であっても、バージョンなどの違いにより、新たなオブジェクトが追加される場合がある。図９においては、塗り潰されたオブジェクト２−１−３がそれに相当する。すなわち、同種類の他のバージョンの基板３０’には無いオブジェクト２−１−３が、この基板３０には存在している。
【００８５】
図１３は、システム用ＣＰＵから基板３０に渡される一例の情報を示す。データ名ｍｏｄｅは、ＳＮＭＰの問い合わせ方法であって、上述したＧＥＴ／ＧＥＴＮ／ＳＥＴの何れを用いてＳＮＭＰが問い合わせられたかが記される。データ名ｃｍｄ＿ｃｔｌは、ＳＮＭＰ時のコマンドコントロールフィールドであって、１バイトが設けられ、上述したＧＥＴＮ操作用フィールドが記される。
【００８６】
データ名ｂｏａｒｄ＿ｉｄｘは、同種基板の識別子である同種基板識別用インデックスが記され、データ名ｂｏａｒｄ＿ｍａｘは、同種基板が現在筐体内に装着されている枚数が記される。これらｂｏａｒｄ＿ｉｄｘおよびｂｏａｒｄ＿ｍａｘを用いることにより、システム用ＣＰＵから渡されたデータに対してどのような処理を行えばよいかを、基板３０側で独自に判断することができる。
【００８７】
データ名ｃｍｄ＿ｌｅｎは、オブジェクトＩＤのデータ長が記される。ｃｍｄは、実際のオブジェクトＩＤのデータ列が記される。
【００８８】
図１４、図１５、図１６および図１７を用いて、上述した、基板３０側でのオブジェクトの検索方法について説明する。図１４、図１５および図１６は、それぞれＧＥＴＮ操作用フィールドの値が’１Ｈ’以下、’２Ｈ’、’４Ｈ’または’８Ｈ’の場合のフローチャートである。また、図１７は、図１４に示すＧＥＴＮ操作用のフィールドの値が’１Ｈ’の場合の検索方法を説明するための、一例のＭＩＢ構造を示す。
【００８９】
なお、図１７に一例が示されるＭＩＢツリーにおいて、長方形はオブジェクトテーブルを示し、テーブルの下に、そのテーブルに対応するオブジェクトＩＤの、基板種類識別番号である’ｘ’以下の部分を記す。また、最も深い階層をｎ＝１として、一つ浅い階層に移動する毎に、ｎを１ずつ増加させる。最も深い位置のテーブルがある階層を１として、ＭＩＢツリーを根（ルート）の方に上がっていったときに、その基板のトップ（根元）の階層に対応する値をリミット値と呼ぶ。この図１７の例では、リミット値は、ｎ＝４である。
【００９０】
図１４は、ＧＥＴＮ操作用フィールドの値が’１Ｈ’以下の場合の、オブジェクトの一例の検索方法を示す。より深い階層から検索するために、先ず、オブジェクトテーブルｔａｂｌｅ＃ｎの検索基準として、ｎ＝１に設定される（ステップＳ３０）。図１７におけるテーブルＡ、Ｂが最初の検索対象とするために、このように設定する。次のステップＳ３１で、ｎが所定のリミット値以下であるかどうかが判断される。ｎがリミット値以下ではないと判断されれば、処理はステップＳ４０に移行し、当該基板３０内に該当するオブジェクトが無いとされ、一連の処理が終了される。
【００９１】
一方、ステップＳ３１で、ｎがリミット位置以下であると判断されれば、処理はステップＳ３２に移行する。ステップＳ３２では、ｔａｂｌｅ＃ｎが検索される。そして、ステップＳ３３で、検索されたｔａｂｌｅ＃ｎのオブジェクトＩＤがシステム用ＣＰＵから受け取ったオブジェクトＩＤに完全に含まれるかどうかが判断される。若し、検索されたｔａｂｌｅ＃ｎがこの条件を満たしていないと判断されれば、ステップＳ３４でｎを１つ増して、処理がステップＳ３１に戻される。
【００９２】
一方、ステップＳ３３で、ｔａｂｌｅ＃ｎが条件を満たしていると判断されれば、処理はステップＳ３５に移行する。システム用ＣＰＵから受け取ったオブジェクトＩＤの長さが上述したステップＳ３３で見つかったテーブルのオブジェクトＩＤよりも短いと判断されれば、処理はステップＳ３６に移行する。ステップＳ３６では、ｔａｂｌｅ＃ｎ内から、辞書式順序で以て最も小さなオブジェクトが取り出される。そして、次のステップＳ３７でオブジェクトが発見されたとされる。
【００９３】
一方、上述したステップＳ３５で、システム用ＣＰＵから受け取ったオブジェクトＩＤの長さが上述したステップＳ３３で見つかったテーブルのオブジェクトＩＤよりも長いと判断されれば、処理はステップＳ３９に移行する。この場合には、システム用ＣＰＵから受け取ったオブジェクトＩＤがｔａｂｌｅ＃ｎのオブジェクトＩＤよりもデータ長が長く、さらに細部までオブジェクトの指定がなされていることになるので、オブジェクトテーブルからオブジェクトを直接的に取り出すことができる。ステップＳ３９では、ｔａｂｌｅ＃１内から該当するオブジェクトが取り出され、処理がステップＳ３７に移行される。
【００９４】
上述の処理を、より具体的な例を用いて説明する。ここでは、システム用ＣＰＵから送られたオブジェクトＩＤが｛６００４．ｘ．５．１．ｙ｝（前半は省略する）であるものとして説明する。リミット値ｎは、ｎ＝４である。オブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝において、ｎ＝１に対応する値は’ｙ’、ｎ＝２に対応する値は’１’、ｎ＝３に対応する値は’５’となる。オブジェクトＩＤにおいて、ｎに応じて、それぞれの階層に対応する長さまで、テーブル検索時に一致している必要がある。上述したように、より深い階層から検索を行うために、ステップＳ３０によりｎ＝１に設定される。図１７におけるテーブルＡ、Ｂを最初の検索対象とするために、このように設定する。
【００９５】
ステップＳ３３により、ｎ＝１の階層では、オブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝が含むオブジェクトＩＤを持つテーブルが存在しなかったので、ステップＳ３４によりｎを１つ増やしてｎ＝２として、一つ上の階層について検索が試みられる。
【００９６】
検索の結果、ｎ＝２の階層において、テーブルＣ、ＤおよびＥにはオブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝が含むｎ＝２の階層までの長さのオブジェクトＩＤが存在しなかったので、続いてテーブルＦについてオブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝がテーブルのオブジェクトＩＤ｛６００４．ｘ．５．１｝を含むかどうかが調べられる。テーブルＦのオブジェクトＩＤは、｛ｘ．５．１｝であり、オブジェクトＩＤ｛６００４．ｘ．５．１｝に含まれることが分かる（ステップＳ３５）。処理はステップＳ３９に移行してテーブルＦからオブジェクトが取り出され、ステップＳ３７でオブジェクトが発見されたとされる。
【００９７】
図１５は、ＧＥＴＮ操作用フィールドの値が’２Ｈ’の場合の、オブジェクトの一例の検索方法を示す。ここでは、ｔａｂｌｅ＃１についてオブジェクトを検索する場合について説明する。先ず、最初のステップＳ５０で、ｔａｂｌｅ＃１のうち、オブジェクトＩＤがシステム用ＣＰＵから受け取ったオブジェクトＩＤに完全に含まれているオブジェクトテーブルが検索される。検索の結果に基づき、ステップＳ５１で、一致するテーブルが存在しないと判断されれば、処理はステップＳ５５に移行し、該当するオブジェクトが存在しないとされる。
【００９８】
一方、ステップＳ５１で、一致するテーブルが存在すると判断されれば、処理はステップＳ５２に移行し、ｔａｂｌｅ＃１から該当するオブジェクトが取り出される。そして、次のステップＳ５３で、このＭＩＢテーブル（図９参照）において、取り出された次のオブジェクトが葉であるかどうかが判断される。若し、葉であると判断されれば、その葉であるオブジェクトが求めるオブジェクトであるとして、オブジェクトが発見されたとされる（ステップＳ５４）。
【００９９】
一方、ステップＳ５３で、次のオブジェクトが葉ではないと判断されれば、現在検索中のテーブル内には該当するオブジェクトが無いので、処理はステップＳ５５に移行する。
【０１００】
図１６は、ＧＥＴＮ操作用フィールドの値が’４Ｈ’または’８Ｈ’の場合の、オブジェクトの一例の検索方法を示す。ここでは、ｔａｂｌｅ＃１についてオブジェクトを検索する場合について説明する。先ず、最初のステップＳ６０で、ｔａｂｌｅ＃１のうち、オブジェクトＩＤがシステム用ＣＰＵから受け取ったオブジェクトＩＤに完全に含まれているオブジェクトテーブルが検索される。検索の結果に基づき、ステップＳ６１で、一致するテーブルが存在しないと判断されれば、処理はステップＳ６５に移行し、該当するオブジェクトが存在しないとされる。
【０１０１】
一方、ステップＳ６１で、一致するｔａｂｌｅ＃１が存在すると判断されれば、処理はステップＳ６２に移行し、辞書式順序で、次のｔａｂｌｅ＃１が検索される。検索結果に基づき、次のステップＳ６３で、次のｔａｂｌｅ＃１が存在するかどうかが判断される。若し、次のｔａｂｌｅ＃１が存在すると判断されれば、処理は次のステップＳ６４に移行し、見つかったｔａｂｌｅ＃１内で最初のオブジェクトが該当オブジェクトとされる。
【０１０２】
一方、ステップＳ６３で、次のｔａｂｌｅ＃１が存在しないと判断されれば、処理はステップＳ６５に移行し、該当するオブジェクトが存在しないとされる。
【０１０３】
なお、ＧＥＴＮ操作用フィールドの値が’４Ｈ’の処理が終了したら、次にＧＥＴＮ操作用フィールドの値が’８Ｈ’の処理が行われ、図１６の処理が２回繰り返されることになる。これは、オブジェクトの検索ミスを防止するための処理であって、ＧＥＴＮ操作用フィールドの値が’８Ｈ’の場合の検索処理を行わなくても、正常に動作する。
【０１０４】
図１４、図１５および図１６を用いて上述したような方法でオブジェクトを検索することにより、同種基板で新たなオブジェクトが追加された基板と、新たな基板が追加されていない以前のバージョンの基板とが同一筐体内に共存する場合でも、オブジェクトの抜けが無く、ＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎを動作させることができる。
【０１０５】
なお、上述の動作を保証するためには、新規オブジェクトの追加および削除作業を正しく行う必要がある。例えば、新規オブジェクトの追加および削除作業を行う際の制限事項として、以下の３項目が設けられる。
(1)既存のオブジェクトのオブジェクトＩＤを変更してはならない。
(2)オブジェクトが不要になった、あるいは、オブジェクトが削除された場合は、当該オブジェクトのオブジェクトＩＤを欠番として残しておく。
(3)むやみに深い階層にオブジェクトを追加しない。
【０１０６】
図１８、図１９および図２０は、好ましくないオブジェクト追加および削除方法の例を示す。図１８は、上述した(1)の項目に対応し、オブジェクトを追加する際に既存のオブジェクトのオブジェクトＩＤを変更してしまった例である。図１８Ａに示される、ｔａｂｌｅ＃１の下にある既存のオブジェクト１−１、１−２および１−３を考える。この構成に対して、１−１の前にオブジェクトが挿入されると、図１８Ｂのようになり、既存のオブジェクト１−１、１−２および１−３がオブジェクト１−２、１−３および１−４にシフトされ、新たに挿入追加されたオブジェクトがオブジェクト１−１となっている。この場合には、オブジェクトＩＤによるオブジェクトの検索を行ったときに、正しいオブジェクトが検索されないおそれがある。
【０１０７】
図１９は、上述した(2)の項目に対応し、オブジェクトを削除した際に、既存のオブジェクトが繰り上げられた例である。図１９Ａに示される、ｔａｂｌｅ＃１の下にあるオブジェクト２−１、２−２および２−３を考える。この状態から、オブジェクト２−１が削除され、図１９Ｂに示されるように、既存のオブジェクト２−２および２−３がそれぞれオブジェクト２−１および２−２と、オブジェクトＩＤが繰り上がっている。この場合にも、上述と同様に、オブジェクトＩＤによるオブジェクトの検索を行ったときに、正しいオブジェクトが検索されないおそれがある。
【０１０８】
図２０は、上述した(3)の項目に対応し、非常に深い階層にオブジェクトが追加された例である。この場合には、オブジェクトの検索に非常に時間がかかってしまうおそれがある。例えば、オブジェクト３−２−１を検索するためには、ｔａｂｌｅ＃６、ｔａｂｌｅ＃５、ｔａｂｌｅ＃４、ｔａｂｌｅ＃３、ｔａｂｌｅ＃２およびｔａｂｌｅ＃１と、階層を辿らなくてはいけない。
【０１０９】
なお、上述した(1)、(2)および(3)の制限は、ＩＡＮＡ(Internet Assigned Numbers Authority)により定義されたものである。この制限に準じない方法でオブジェクトを追加あるいは削除した場合には、この発明により組み込まれたプロキシ・エージェントが正常に動作しない可能性がある。
【０１１０】
上述では、この発明がディジタルビデオおよびオーディオ信号を処理するエンコーダ・デコーダに適用されるように説明したが、これはこの例に限定されない。例えば、この発明は、パーソナルコンピュータといったコンピュータ装置のスロットに装着されて使用される、拡張カードにも適用することができる。この場合には、パーソナルコンピュータのスロットに装着された拡張カードを、ＭＩＢによって管理することができるようになる。
【０１１１】
【発明の効果】
以上説明したように、この発明は、ＳＮＭＰマネージャにプロキシ・エージェントを介して管理される各基板側がＭＩＢによる管理対象となるオブジェクトを持っているので、プロキシ・エージェント側で、各基板それぞれに特有のオブジェクトに関する情報から解放されるという効果がある。
【０１１２】
これにより、新たな基板が開発された場合でも、プロキシ・エージェントに手を加えることなく、ＳＮＭＰマネージャが持つＭＩＢ定義ファイルを変更するだけで、オブジェクトを追加することができる効果がある。
【図面の簡単な説明】
【図１】この発明を適用可能な一例のシステムを示すブロック図である。
【図２】ビデオプロセッサに装着可能な基板の例を示す略線図である。
【図３】ＭＩＢ一例の構成を示す略線図である。
【図４】ビデオプロセッサに装着される基板の一例の構成を概略的に示すブロック図である。
【図５】ビデオプロセッサにおける識別番号の一例の配列の内容を示す略線図である。
【図６】オブジェクトＩＤの一例の構造を示す略線図である。
【図７】ＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す略線図である。
【図８】ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す略線図である。
【図９】基板側のＭＩＢ情報オブジェクトの一例の構成を示す略線図である。
【図１０】ＧＥＴＮ操作用のフィールドの一例を示す略線図である。
【図１１】基板におけるオブジェクトＩＤの一例の判別方法を示すフローチャートである。
【図１２】基板からの応答を受け取ったシステム用ＣＰＵにおける一例の処理を示すフローチャートである。
【図１３】システム用ＣＰＵから基板に渡される一例の情報を示す略線図である。
【図１４】ＧＥＴＮ操作用フィールドの値が’１Ｈ’以下の場合のオブジェクトの一例の検索方法を示すフローチャートである。
【図１５】ＧＥＴＮ操作用フィールドの値が’２Ｈ’の場合のオブジェクトの一例の検索方法を示すフローチャートである。
【図１６】ＧＥＴＮ操作用フィールドの値が’４Ｈ’または’８Ｈ’の場合のオブジェクトの一例の検索方法を示すフローチャートである。
【図１７】ＧＥＴＮ操作用のフィールドの値が’１Ｈ’の場合の検索方法を説明するための、一例のＭＩＢ構造を示す略線図である。
【図１８】オブジェクトを追加する際に既存のオブジェクトのオブジェクトＩＤを変更してしまった例を示す略線図である。
【図１９】オブジェクトを削除した際に既存のオブジェクトが繰り上げられた例を示す略線図である。
【図２０】非常に深い階層にオブジェクトが追加された例を示す略線図である。
【図２１】プロキシエージェントによる一例のアーキテクチャを示すブロック図である。
【符号の説明】
２・・・ＳＮＭＰマネージャ、３・・・ＳＮＭＰエージェント、１０・・・プロキシ・エージェント、１１Ａ，１１Ｂ，１１Ｃ，１１Ｄ，１１Ｅ・・・スロット、３０，３０Ａ，３０Ｂ，３０Ｃ，３０Ｄ・・・基板、３２・・・ＣＰＵ、３３・・・ＲＯＭ、３４・・・通信インターフェイス、３５・・・コネクタ、３６・・・機能部
【発明の属する技術分野】
この発明は、ネットワークに接続され、筐体内に装着された組込電子機器をＳＮＭＰ(Simple Network Management Protocol)を用いて管理する際に、被管理機器における構成の変化に柔軟に対応可能な組込型電子機器ならびに組込電子機器および組込電子機器の管理方法に関する。
【０００２】
【従来の技術】
現在、ＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)によるネットワークに接続された機器を管理するためのプロトコルとして、ＳＮＭＰ(Simple Network Management Protocol)が提供されている。ＳＮＭＰでは、システム管理者により起動されるネットワーク監視端末（ＳＮＭＰマネージャと称される）と、ＳＮＭＰが実装されるネットワーク上の機器（ＳＮＭＰエージェントと称される）との間のプロトコルが規定される。ＳＮＭＰでは、ＭＩＢ(Management Information Base)と称されるＳＮＭＰエージェントが持つ情報に、ＳＮＭＰマネージャがアクセスすることで、機器の状態の把握や機器に設定される定義情報の変更が可能とされる。ＳＮＭＰを用いることによって、複雑に構成されるネットワークの管理を、ＳＮＭＰマネージャから容易に行うことが可能とされる。
【０００３】
一方、ネットワーク環境の普及により、コンピュータといった情報機器のみならず、例えば放送局などで使用されるビデオ機器を、ＴＣＰ／ＩＰによるネットワーク接続により管理することが提案されている。このとき、ＳＮＭＰが実装されていないなど、ＳＮＭＰエージェント機能を有さない機器をＳＮＭＰにより管理するためには、ＳＮＭＰエージェント機能が実装されている機器をプロキシエージェントとして設ける必要がある。すなわち、プロキシエージェントによって、ＳＮＭＰエージェント機能を有さない機器とＳＮＭＰとの仲介を行い、当該機器のＳＮＭＰによる管理を可能とする。
【０００４】
図２１は、このプロキシエージェントによる一例のアーキテクチャを示す。ＳＮＭＰマネージャ３００により、独自の管理インターフェイスに対応した機器３２０がプロキシエージェント３１０を介して管理される。
【０００５】
例えばＳＮＭＰマネージャ３００から機器３２０に対してコマンドやデータ（以下、コマンドとする）などを送る場合、ＳＮＭＰマネージャ３００側の管理アプリケーション３０１で発行されたコマンドは、クライアント・スタブ３０２でプロトコル・スタック３０３によりプロトコル解釈されてＳＮＭＰに変換され、ＳＮＭＰマネージャ３００から送信される。このＳＮＭＰに変換されたコマンドは、プロキシ・エージェント３１０に受信され、プロトコル・スタック３１３およびサーバ・スタブ３１２を介してプロキシ・エージェント・アプリケーション３１１に供給される。
【０００６】
一方、機器３２０は、ＳＮＭＰとは異なるプロトコルを用いた独自の管理インターフェイス３２１により管理される。ＳＮＭＰマネージャ３００から送信されたＳＮＭＰは、プロキシ・エージェント・アプリケーション３１１において、クライアント・プロキシ・スタブ３１４によりプロトコル・スタック３１５を用いて機器３２０の独自の管理インターフェイス３２１が対応するプロトコルに変換される。このプロトコル変換されたコマンドが機器３２０に送信され、管理インターフェイス３２１に受信される。
【０００７】
このように、プロキシ・エージェント３１０によってＳＮＭＰマネージャ３００とＳＮＭＰ非対応の機器３２０の仲介をすることで、ＳＮＭＰマネージャ３００により機器３２０を管理することができる。
【０００８】
【発明が解決しようとする課題】
しかしこの場合、プロキシ・エージェント３１０は、管理される側の機器３２０（被プロキシ・エージェントとする）に関する全管理項目を把握している必要があるという問題点があった。
【０００９】
さらに、被プロキシ・エージェントが多種・複数存在する、ニーズに応じて管理項目の構成が変化する、新たな被プロキシ・エージェントが開発され管理項目が追加される、などの事態を想定すると、プロキシ・エージェント３１０におけるプロキシ・エージェント・アプリケーション３１１に対して、バージョンアップなどによる機能拡張を可能にするように対応する必要があるという問題点があった。
【００１０】
したがって、この発明の目的は、ＳＮＭＰを用いてＳＮＭＰに非対応の機器を管理する際に、機能の拡張が容易な組込型電子機器ならびに組込電子機器および組込電子機器の管理方法を提供することにある。
【００１１】
【課題を解決するための手段】
この発明は、上述した課題を解決するために、ＳＮＭＰが実装されプロキシ・エージェントの機能を持つシステム用ＣＰＵおよびメモリを有するシステム基板と、複数の組込電子機器をそれぞれ接続するための複数の組込手段と、ネットワークを介してＳＮＭＰマネージャとの通信を行う第１の通信手段と、ＳＮＭＰに基づくオブジェクトＩＤをＳＮＭＰとは異なるプロトコルに変換する変換手段と、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得する機器情報取得手段と、複数の組込電子機器に対してＳＮＭＰとは異なるプロトコルを用いて通信を行う第２の通信手段とを備え、機器情報取得手段は、所定の周期で複数の組込電子機器をスキャンし、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得し、メモリは、取得された複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、オブジェクトＩＤがＳＮＭＰマネージャから供給された際に、オブジェクトＩＤのうち、組込電子機器の種類を示す識別子を参照することにより、メモリに保持された配列から、問い合わせの対象となる組込電子機器を特定し、問い合わせの対象となる組込電子機器が組み込まれている場合に、オブジェクトＩＤを問い合わせの対象となる組込電子機器に渡すようにした組込型電子機器である。
【００１２】
また、この発明は、オブジェクト情報が格納されるオブジェクト情報格納手段を有し、
オブジェクト情報が、組込型電子機器を介してＳＮＭＰマネージャの管理対象となるオブジェクトを示すものである組込電子機器である。
【００１３】
また、この発明は、複数の組込電子機器をそれぞれ接続するための組み込みのステップと、ネットワークを介してＳＮＭＰマネージャとの通信を行う第１の通信のステップと、ＳＮＭＰに基づくオブジェクトＩＤをＳＮＭＰとは異なるプロトコルに変換する変換のステップと、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得する機器情報取得のステップと、複数の組込電子機器に対してＳＮＭＰとは異なるプロトコルを用いて通信を行う第２の通信のステップとを備え、ＳＮＭＰが実装されプロキシ・エージェントの機能を持つシステム用ＣＰＵおよびメモリを有するシステム基板を備えた組込型電子機器により、機器情報取得のステップにおいて、所定の周期で複数の組込電子機器をスキャンし、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得し、メモリは、取得された複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、オブジェクトＩＤがＳＮＭＰマネージャから供給された際に、オブジェクトＩＤのうち、組込電子機器の種類を示す識別子を参照することにより、メモリに保持された配列から、問い合わせの対象となる組込電子機器を特定し、問い合わせの対象となる組込電子機器が組み込まれている場合に、オブジェクトＩＤを問い合わせの対象となる組込電子機器に渡すようにした組込電子機器の管理方法である。
【００１４】
また、この発明は、組込型電子機器が有するＣＰＵおよび組込型電子機器に組み込まれる組込電子機器の種類に応じてグループ分けしたグループ識別子を配し、組込電子機器の種類を示すグループ識別子の値が、組込型電子機器が有するＣＰＵを示すグループ識別子の値よりも大であるとされたＭＩＢ構造を表すオブジェクトＩＤを用い、組込型電子機器に組み込まれる組込電子機器を、組込型電子機器を介してＳＮＭＰマネージャにより管理する組込電子機器の管理方法である。
【００１５】
上述したように、この発明は、機器情報取得手段が、所定の周期で複数の組込電子機器をスキャンし、複数の組込手段により組み込まれた複数の組込電子機器の種類および該種類毎の数を取得し、メモリが、取得された複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、オブジェクトＩＤがＳＮＭＰマネージャから供給された際に、オブジェクトＩＤのうち、組込電子機器の種類を示す識別子を参照することにより、メモリに保持された配列から、問い合わせの対象となる組込電子機器を特定し、問い合わせの対象となる組込電子機器が組み込まれている場合に、オブジェクトＩＤを問い合わせの対象となる組込電子機器に渡すようにしているため、筐体内における組込電子機器の拡張が容易である。
【００１６】
また、この発明は、組込電子機器が、オブジェクト情報が格納されるオブジェクト情報格納手段を有し、オブジェクト情報が、組込型電子機器を介してＳＮＭＰマネージャの管理対象となるオブジェクトを示すものであるため、オブジェクトを管理する外部においてオブジェクト情報を持つ必要がない。
【００１７】
また、この発明は、組込型電子機器が有するＣＰＵおよび組込型電子機器に組み込まれる組込電子機器の種類に応じてグループ分けしたグループ識別子を配し、組込電子機器の種類を示すグループ識別子の値が、組込型電子機器が有するＣＰＵを示すグループ識別子の値よりも大であるとされたＭＩＢ構造を表すオブジェクトＩＤを用い、組込型電子機器に組み込まれる組込電子機器を、組込型電子機器を介してＳＮＭＰマネージャにより管理するようにしているため、組込型電子機器に組み込まれた組込電子機器をＭＩＢを用いて管理できる。
【００１８】
【発明の実施の形態】
以下、この発明の実施の一形態を、図面を参照しながら説明する。図１は、この発明を適用可能な一例のシステムを示す。ネットワーク１にＳＮＭＰマネージャ２とＳＮＭＰエージェント３とが接続される。これらＳＮＭＰマネージャ２とＳＮＭＰエージェント３との間では、ＳＮＭＰ標準のオペレーションやイベント通知がネットワーク１を介してやりとりされる。
【００１９】
この実施の一形態では、ＳＮＭＰエージェント３は、例えばＭＰＥＧ２(Moving Pictures Experts Group 2)方式に対応したビデオプロセッサ３である。後述するが、ビデオプロセッサ３は、内部に組み込まれた基板の機能に応じた処理を行う。図１の例では、ビデオプロセッサ３は、入力されたディジタルビデオ信号およびディジタルオーディオ信号を、所定にエンコードしてＭＰＥＧ２方式によるトランスポートストリームにして出力する機能を有する。また、ビデオプロセッサ３は、入力されたＭＰＥＧ２方式によるトランスポートストリームを所定にデコードし、例えば標準のディジタルビデオ信号およびディジタルオーディオ信号にして出力する機能を有する。
【００２０】
ビデオプロセッサ３において、バス２０にシステム基板１０が接続される。図示しないが、システム基板１０には、システム用ＣＰＵ(Central Processing Unit)、マルチプレクス用ＣＰＵおよび統計多重用ＣＰＵの３つのＣＰＵが搭載され、それぞれのＣＰＵによって所定の機能が実現される。また、バス２０に対して複数のスロット１１Ａ、１１Ｂ、１１Ｃ、１１Ｄおよび１１Ｅが接続される。
これらスロット１１Ａ、１１Ｂ、・・・に基板３０、３０、・・・を装着することで、その基板３０、３０、・・・がバス２０に所定に接続され、ビデオプロセッサ３においてその基板３０、３０、・・・の機能が有効になる。
【００２１】
なお、図１では、基板３０、３０、・・・を、説明のため基板３０Ａ、３０Ｂ、・・・とそれぞれ区別している。
【００２２】
図１の例では、スロット１１Ａ、１１Ｂおよび１１Ｅに、標準解像度ビデオ信号（ＳＤ）に対応したビデオエンコーダである基板３０Ａ（ＥＮＣ（１））、３０Ｂ（ＥＮＣ（２））および３０Ｄ（ＥＮＣ（３））が装着され、スロット１１Ｄにオーディオエンコーダである基板３０Ｃ（ＡＰＲ（１））が装着される。例えばシステム基板１０は、入出力インターフェイスの機能を有し、システム基板に入力された信号は、バス２０を介してこれら基板３０Ａ〜３０Ｄに供給される。なお、図１の例では、「φ」と記されたスロット１１Ｃには、基板３０が装着されていない。
【００２３】
上述したように、ビデオプロセッサ３は、スロット１１Ａ〜１１Ｅに装着される基板３０が有する機能に応じた処理を行うことができる。図２は、ビデオプロセッサ３に装着可能な基板３０の例を示す。各基板３０、３０、・・・には、その基板３０の種類に応じてそれぞれ識別番号が割り当てられる。基板ＯＰＭは、システム基板１０であり、システム基板１０にのせられたシステム用ＣＰＵ、マルチプレクス用ＣＰＵおよび統計多重用ＣＰＵに、識別番号１、２および３番がそれぞれ割り当てられる。システム基板１０には、このように、最小の識別番号から順に識別番号が割り当てられる。
【００２４】
一方、各基板３０、３０、・・・には、システム基板１０の識別番号の次の値から、基板３０の種類毎に識別番号が割り当てられる。基板ＩＰＭは、トランスポートストリームの入力部であり、識別番号が４番とされる。エンコーダである基板ＥＮＣは、識別番号が５番とされる。基板ＶＰＲは、高精細解像度ビデオ信号（ＨＤ）に対応したビデオエンコーダであり、識別番号が６番とされる。基板ＤＥＣは、ビデオデコーダであり、識別番号が７番とされる。オーディオエンコーダである基板ＡＰＲは、識別番号が８番とされる。
【００２５】
この例では、このように識別番号が８番までが予約されており、新たに開発された基板には、９番以降の識別番号が順次割り当てられることになる。
【００２６】
なお、上述ではビデオプロセッサ３にはスロットが５個、設けられ、基板が５枚装着可能として説明したが、これはこの例に限定されない。例えば、スロットは、筐体の大きさに応じて異なる数を設けることができる。なお、スロット１１Ａ、１１Ｂ、・・・は、基板３０の活電挿抜が可能とされており、ビデオプロセッサ３が稼働中でも、スロット１１Ａ、１１Ｂ、・・・の状況が変わり得る。すなわち、ビデオプロセッサ３の稼働中に、スロット１１Ａ、１１Ｂ、・・・に装着される基板３０が変更されることが有り得る。さらに、ビデオプロセッサ３は、用途に応じて必要な機能を有する基板３０を選択し、筐体内に複数種類および複数枚の基板３０を装着することが可能とされている。
【００２７】
図２で上述した各基板のうち、ＳＮＭＰが実装されている、すなわち、ＳＮＭＰによる送受信が可能で、且つ、ＡＮＳ．１コーデック機能（ＳＮＭＰのパケットのコーデック機能）を持つのは、システム基板１０（基板ＯＰＭ）上のシステム用ＣＰＵのみであり、また、外部との通信ポートを持つのもシステム用ＣＰＵのみである。したがって、システム基板１０がＳＮＭＰのプロキシ・エージェントとなる。実際には、システム基板１０におけるシステム用ＣＰＵがプロキシ・エージェントとしての機能を果たす。このシステム基板１０（基板ＯＰＭ）は、このビデオプロセッサ３の構成において必須である。
【００２８】
ＳＮＭＰマネージャ２によるビデオプロセッサ３の管理は、従来の技術の項で図２１を用いて説明した方法と同様にして行われる。すなわち、システム基板１０をプロキシ・エージェントとして、ＳＮＭＰマネージャ２とシステム基板１０との間でネットワーク１を介して通信が行われ、ＳＮＭＰによる標準的なオペレーションコマンドやイベント通知がやりとりされる。システム基板１０では、例えば、ＳＮＭＰマネージャ２からＳＮＭＰにより送られたオペレーションコマンドやイベント通知が、ビデオプロセッサ３独自のオペレーションコマンドやイベント通知に変換される。変換されたこれらコマンドや通知がバス２０を介して、スロット１１Ａ、１１Ｂ、・・・に装着された各基板３０、３０、・・・に供給される。また、各基板３０、３０、・・・から出力された、ビデオプロセッサ３独自のコマンドやイベント通知は、バス２０を介してシステム基板１０に供給され、ＳＮＭＰによるコマンドやイベント通知に変換される。変換されたコマンドやイベント通知は、ネットワーク１を介してＳＮＭＰマネージャ２に送られる。
【００２９】
この実施の一形態においては、ビデオプロセッサ３のスロット１１Ａ、１１Ｂ、・・・に装着される各基板３０、３０、・・・のオブジェクトは、各基板３０、３０、・・・側でそれぞれが持つ。こうすることで、プロキシ・エージェントであるシステム基板１０上のシステム用ＣＰＵは、スロット１１Ａ、１１Ｂ、・・・に装着される各基板３０、３０、・・・のオブジェクトそれぞれに特有のオブジェクトに関する情報から解放される。
【００３０】
なお、ここでオブジェクトは、ＭＩＢにおける項目を指す。例えば、上述したエンコーダである基板ＥＮＣでは、「ビットレート」、「サンプリングレート」、「入力信号の種類」などのエンコーダのパラメータに対するＳＮＭＰによるコマンドの一つ一つがオブジェクトとされる。すなわち、オブジェクトは、ＳＮＭＰマネージャ２による管理対象である。
【００３１】
図３は、ＭＩＢ一例の構成を示す。ＭＩＢは、世界的に標準化されており、ツリー構造を有している。この図３の例では、最上位がインターネット（ｉｎｔｅｒｎｅｔ（１））とされ、その下位にツリーが構成される。図示は省略するが、実際には、「ｉｎｔｅｒｎｅｔ（１）」も、さらに上位のツリー構造の一部である。「ｅｎｔｅｒｐｒｉｓｅ（１）」より上位がグローバルな階層である。「ｘｘｘ（ｎ）」より下位がベンダローカルな階層とされ、例えばｘｘｘ社の製品は、「ｘｘｘ（ｎ）」より下層に位置する。また、ｘｘｘ社の製品である上述のビデオプロセッサ３（図３における「ｙｙｙｙ（６００４）」）に装着される各基板３０、３０、・・・は、「ｙｙｙｙ（６００４）」より下層に位置する。
【００３２】
なお、ツリー構造の各枝において括弧「（）」内に記される値は、それぞれの階層においてＭＩＢオブジェクトを識別するための識別子である。このツリー構造の各枝は、上位から下位にかけて、各層の識別子と各層を互いに区別するための区切り識別子であるピリオド（．）とによって一意的に表現される。例えば、最下層の基板ＥＮＣ（７）は、「１．４．１．ｎ．６００４．７」として表される。実際には、より上位の階層からの識別子を用いて、「１．３．６．１．４．１．ｎ．６００４．７」と表現される。これは、オブジェクトＩＤと称される。
【００３３】
ビデオプロセッサ３に装着される基板３０、３０、・・・は、種類毎に識別子が割り当てられ、基板種類毎にオブジェクトグループが分かれている。図３では、オブジェクト「ＳＹＳ／ＯＰＭ（３）」以下に示される、括弧（）内の添え字が３以上のオブジェクトがこれに当たる。
【００３４】
新たな機能を持つ基板３０が開発された場合には、さらに異なる識別子が与えられ、図３に「？？？（１１）」、「？？？（１２）」として示されるように、オブジェクトを増やすことができる。このとき、基板３０側がオブジェクトを持っているので、プロキシ・エージェントに手を加えることなく、ＳＮＭＰマネージャ２が持つＭＩＢ定義ファイルを変更するだけで、オブジェクトを追加できる。これにより、追加された基板３０についてのＭＩＢ監視も可能となる。
【００３５】
なお、システム基板１０は、上述したように機能毎に３つのＣＰＵを持ち、識別子は、これら３つのＣＰＵにもそれぞれ割り当てられる。
【００３６】
また、図示しないが、各基板のそれぞれは、さらに下位にオブジェクトを持つことができる。例えば、各基板に対するＳＮＭＰマネージャ２による管理コマンドのそれぞれがオブジェクトとされる。各基板は、階層的にオブジェクトを持つことができる。下位のオブジェクトは、オブジェクトに対するポインタが記されるオブジェクトテーブルにより参照される。
【００３７】
図４は、ビデオプロセッサ３に装着される基板３０の一例の構成を概略的に示す。基板３０は、バス３１を有し、バス３１に対してＣＰＵ３２、ＲＯＭ(Read Only Memory)３３および通信インターフェイス３４が接続される。通信インターフェイス３４は、コネクタ３５に接続される。また、バス３１に、この基板３０の主要な機能を司る機能部３６が接続される。この基板３０が上述したエンコーダ基板ＥＮＣである場合には、外部から供給されたディジタルビデオ信号がこの機能部３６に入力され、所定にエンコード処理され、機能部３６から出力される。コネクタ３５がスロット１１Ａ、１１Ｂ、・・・に挿入されることで、基板３０とシステム基板１０とが電気的に結合される。例えば、システム基板１０に搭載される３つのＣＰＵから出力された指令がコネクタ３５から通信インターフェイス３４に供給され、バス３１を介してＣＰＵ３２に渡される。この指令に基づきＣＰＵ３２により機能部３６が制御され、機能部３６に入力された信号に対する所定の処理が行われる。
【００３８】
このような構成において、オブジェクトの情報は、例えばＲＯＭ３３に予め記憶される。ＲＯＭ３３に記憶された情報は、例えばシステム基板１０に搭載されたシステム用ＣＰＵからの指令に基づくＣＰＵ３２の制御により読み出され、通信部３４およびコネクタを介してシステム基板１０に渡される。
【００３９】
次に、システム基板１０側、すなわち、プロキシ・エージェント側での組み込み方法について説明する。システム基板１０においてプロキシ・エージェントの機能を持つシステム用ＣＰＵにより、バス２０に接続される全スロット１１Ａ、１１Ｂ、・・・をある一定の周期でスキャンし、基板３０の種類毎に何枚が装着されているかが調べられる。システム用ＣＰＵでは、例えば図示されないメモリを利用し、予め基板３０の種類数以上の配列が用意され、上述した図２に示される識別番号とその識別番号が示す基板３０の枚数とが対応付けられて保持される。
【００４０】
図５は、上述の図１に示されるビデオプロセッサ３における、識別番号の一例の配列の内容を示す。識別子が３、４および５は、システム基板１０上の３つのＣＰＵにそれぞれ対応し、枚数がそれぞれ１となっている。図１のビデオプロセッサ３では、３枚の基板ＥＮＣと１枚の基板ＡＰＲが装着されているので、対応する識別子７および１０は、それぞれ枚数が３および１となっている。その他の識別子を持つ基板３０は、装着されていないので枚数が０となっている。
【００４１】
ＳＮＭＰマネージャ２からの、ビデオプロセッサ３に装着された各基板への問い合わせは、上述したオブジェクトＩＤを用いてなされる。例えば基板ＥＮＣに対して問い合わせが行われる場合には、オブジェクトＩＤ｛１．３．６．１．４．１．ｎ．６００４．７．＊｝が用いられる。なお、基板の種類を示す識別子「７」の次の「＊」は、任意の長さの識別子が許されることを示す。また、オブジェクトＩＤの最後尾には、基板種類毎のさらに詳細な項目を示すインデックスを付すことができる。例えば同種の基板３０が複数枚装着されている場合に、インデックスを用いて区別することができる。
【００４２】
ＳＮＭＰマネージャ２から送信された問い合わせは、ビデオプロセッサ３に受信され、システム基板１０上のシステム用ＣＰＵに渡される。システム用ＣＰＵ（プロキシ・エージェント）では、渡された問い合わせに含まれるオブジェクトＩＤの特定の値が書かれている場所を見て、対象となる基板３０が判断される。
例えばこの例では、オブジェクトＩＤの「６００４．」の次に書かれている値（この例では「７」）が調べられる。そして、この値に基づき、上述の図５に示されるような配列が参照され、該当する基板３０が装着されているかどうかが判断される。該当する基板３０が装着されていると判断されれば、ＳＮＭＰマネージャ２から送信された問い合わせが、問い合わせに用いられるコマンドがＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔであるか、ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔであるかに応じた方法で、当該基板３０に渡される。
【００４３】
なお、ＳＮＭＰマネージャ２から送られてきた問い合わせは、ＳＮＭＰが用いられている。システム用ＣＰＵでは、上述のようにして問い合わせを基板３０に渡す際に、プロトコルを基板３０に対応した形式に変換する。
【００４４】
同種の基板３０が１台の筐体に複数枚装着されている場合に、ＳＮＭＰ上でそれら複数の同種基板を互いに区別する必要がある。上述したビデオプロセッサ３の例では、スロット１１Ａ、１１Ｂ、・・・のそれぞれに、スロット番号の小さい方から同種基板識別用のインデックスが付与される。
【００４５】
図６は、この場合のオブジェクトＩＤの一例の構造を示す。ＳＮＭＰマネージャ２から送られるオブジェクトＩＤは、例えば｛１．３．６．１．４．１．ｎ．６００４．ｘ．ｙ．ｙ．ｙ．ｙ．ｙ．ｚ｝と記述される。このうち、｛１．３．６．１．４．１．ｎ．６００４｝が当該装置であるビデオプロセッサ３を示す。
次の「ｘ」がビデオプロセッサ３に装着される基板３０の種別を示す基板別グループ番号である。この｛ｘ｝が上述の図２に示した基板種類識別番号に対応する。この｛ｘ｝と、次の｛ｙ．ｙ．ｙ．ｙ．ｙ｝で、完全なコマンド列が構成される。最後尾の｛ｚ｝が同種基板識別用のインデックスである。
【００４６】
このようなオブジェクトＩＤに基づくプロキシ・エージェント側の処理について説明する。処理は、実際には、システム基板１０上に搭載されるシステム用ＣＰＵにより実行される。ＳＮＭＰマネージャ２からシステム用ＣＰＵに対して、オブジェクトＩＤ｛１．３．６．１．４．１．ｎ．６００４．ｘ．＊｝というオブジェクトの参照要求が送信される。なお、最後尾の｛＊｝は、１または複数の任意の識別子を示す。このオブジェクトＩＤが受信されたプロキシ・エージェントにより、受信されたオブジェクトＩＤに基づき、基板種類識別子が｛ｘ｝に対応し、受信された要求の種類（ＧＥＴ／ＧＥＴＮ／ＳＥＴ）に応じて、インデックスが対応する基板に対して、受信されたオブジェクトＩＤが渡される。
【００４７】
受信されたオブジェクトＩＤが対応する基板３０に渡されると共に、スロット１１Ａ、１１Ｂ、・・・に装着されている当該基板３０と同一種類の基板枚数と、同種基板識別インデックスとが当該基板３０に渡される。各基板３０、３０、・・・側では、プロキシ・エージェントから渡されたこれらの情報に基づき、処理が行われる。
【００４８】
一方、プロキシ・エージェント側でも、システム用ＣＰＵにおいてオブジェクトテーブルが持たれており、オブジェクトテーブルの最後尾には、他の基板３０、３０、・・・宛のポインタを擁している。プロキシ・エージェントでは、このオブジェクトテーブルにおいて、ＳＮＭＰマネージャ２から送られてきたオブジェクトＩＤを見て、｛１．３．６．１．４．１．ｎ．６００４．ｘ｝のうち先頭から’６００４’までが一致し、且つ、送られてきたオブジェクトＩＤが｛１．３．６．１．４．１．ｎ．６００４．ｘ｝以上の長さを持つものについて、’ｘ’の値が確認される。
【００４９】
その結果、’ｘ’の値が、上述の図３における「ＭＵＸ（４）」以上の値であれば、そのオブジェクトＩＤは、上述のシステム用ＣＰＵが持つオブジェクトテーブルの最後尾に記される、他の基板３０宛のオブジェクトＩＤであると見なされる。このオブジェクトＩＤは、’ｘ’の値に対応する基板３０に渡される。このように構成することで、今後、基板３０の種類が増加しても、プロキシ・エージェントにおける動作変更の必要がない。
【００５０】
なお、この実施の一形態によるビデオプロセッサ３は、例えば、システム用ＣＰＵと他基板３０、３０、・・・との間の通信が最大１６種類の基板種類まで対応するように作られている。したがって、基板種類がこの範囲内であれば、新たに開発された基板３０をそのままビデオプロセッサ３に装着することで、装着された基板３０における被プロキシ機能が実現される。データを渡すスロット１１Ａ、１１Ｂ、・・・の識別には、「基板の種類」と「同種基板識別用のインデックス」とが用いられる。
【００５１】
上述したように、ＳＮＭＰマネージャ２から送信された問い合わせが、問い合わせに用いられるコマンドがＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔであるか、ＧＥＴＮｅｘｔ Ｒｅｑｕｅｓｔであるかにより、問い合わせを基板に渡す方法が異なる。ＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔの場合には、オブジェクトＩＤとインデックスとが特定されているのが前提であって、オブジェクトＩＤの最後尾にインデックスが書かれている。そのため、データは、該当する種類の中で指定された基板３０に、直接的に引き渡される。
【００５２】
図７は、ＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す。この場合、図６における同種基板識別インデックスを示す値’ｚ’がオブジェクトＩＤに含まれていることが前提の処理となる。したがって、システム用ＣＰＵにより、オブジェクトＩＤに含まれる、図６における値’ｘ’および’ｚ’に基づき、直接的に、操作対象とされる基板３０Ｂ（基板ＥＮＣ（２））にオブジェクトＩＤが渡される。この図７の例では、｛１．３．６．１．４．１．ｎ．６００４．７．ｙ．ｙ．ｙ．ｙ．ｙ．２｝という、コマンドおよびインデックスが含まれたオブジェクトＩＤが送られている。
【００５３】
一方、ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔの場合には、オブジェクトＩＤとインデックスとが不確定な状態で要求されることがある。この場合、図６における’ｙ．ｙ．ｙ．ｙ．ｙ’の一部または全部および’ｚ’の値が含まれない状態で、オブジェクトＩＤがＳＮＭＰマネージャ２から送られてくる可能性がある。そのため、’ｘ’の値のみに基づき、’ｘ’の値に該当する種類の基板３０が複数枚、筐体内に装着されている場合、それらのうちの、添え字（図１参照）が最も小さい基板３０に、オブジェクトＩＤが渡される。例えば、同種類の基板で、スロット１１Ａ、１１Ｂ、・・・のうち最もスロット番号が小さいスロットに挿入された基板に、オブジェクトＩＤが渡される。
【００５４】
図８は、ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す。この図８の例では、｛１．３．６．１．４．１．ｎ．６００４．７．＊｝という、コマンドおよびインデックスが含まれていないオブジェクトＩＤが送られている。
【００５５】
例えば、’ｘ’が、この例のようにエンコーダ基板ＥＮＣを表している場合、先ず「（）」内の添え字が最も小さい値の基板３０Ａ（ＥＮＣ（１））にオブジェクトＩＤが渡される。オブジェクトＩＤに基づき、基板３０Ａ（ＥＮＣ（１））側で値’ｚ’が調べられ、このオブジェクトＩＤが自分宛でないと判断されると、基板３０Ａ（ＥＮＣ（１））からシステム用ＣＰＵに、その旨示すメッセージ「ＮＡＣＫ」が送られる。この「ＮＡＣＫ」を受け取ったシステム用ＣＰＵでは、「（）」の添え字が次の値の同種基板、すなわち基板３０Ｂ（ＥＮＣ（２））にオブジェクトＩＤが渡される。基板３０Ｂ（ＥＮＣ（２））も該当する基板でないときには、添え字が次の値の同種の基板である基板３０Ｄ（ＥＮＣ（３））が調べられる。
【００５６】
また、ＳＮＭＰマネージャ２から送られてきたオブジェクトＩＤの値’ｘ’に基づき、該当する基板が存在しないと判断されれば、システム用ＣＰＵにより図５の配列が検索され、値が’ｘ’以上の基板があればその基板にオブジェクトＩＤが渡される。例えば、上述のように基板ＥＮＣ４１、４２および４４を調べて該当する基板が無い場合、’ｘ’値が’８’である基板３０Ｃ（ＡＰＲ（１））にオブジェクトＩＤが渡され、同様に該当する基板があるかどうかが探索される。
【００５７】
若し、最終的に、オブジェクトＩＤに該当する基板が無いとされた場合には、システム用ＣＰＵにより処理が引き取られる。
【００５８】
次に、システム用ＣＰＵによる他基板宛のＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎについて、より詳細に説明する。図９は、基板３０側のＭＩＢ情報の一例の構成を示す。このように、基板３０内では、ツリー構造でオブジェクトを持つことができる。オブジェクトテーブルは、ｔａｂｌｅ＃１、＃２、・・・で示されるように、ツリーの幹の部分を構成する。図９の例では、オブジェクトテーブルに対して、上位のオブジェクトテーブルから近い順に＃１、＃２、＃３、・・・と番号が付けられる。
【００５９】
また、ツリーの葉に相当する部分は、オブジェクトそのものを表す。それぞれのオブジェクトは、ツリー構造を反映するように、そのオブジェクトが属するオブジェクトテーブルに付された番号と、同一テーブルに属するオブジェクトを識別するための通し番号とからなる識別符号が付される。例えば、影が付されたオブジェクトは、「２−１−３」と識別符号が付され、オブジェクトテーブルｔａｂｌｅ＃２の下に属するｔａｂｌｅ＃１の、３番目のオブジェクトであることが分かる。
【００６０】
一方、システム用ＣＰＵと各基板３０、３０、・・・との間でなされるＧＥＴＮｅｘｔ Ｒｅｑｕｅｓｔによる通信のために、図１０に一例が示される、１バイトのＧＥＴＮ操作用のフィールドが用意される。これら第０〜第７ビットからなる１バイトで、ＧＥＴＮ操作用フィールドの値（８０Ｈ、８Ｈ、４Ｈ、２Ｈ、１Ｈおよび０）が定義される。値表記における「Ｈ」は、その数が１６進表記されていることを示す。
【００６１】
第０ビットが’１’であれば、ＧＥＴＮ操作用フィールドの値が’１Ｈ’とされ、オブジェクトを固定して次の同種のＣＰＵ（基板３０や機能ブロック）に処理が移されることが示される。すなわち、この場合には、同種のオブジェクトが異なるオブジェクトテーブル間で探されることになる。第１ビットが’１’であれば、ＧＥＴＮ操作用フィールドの値が’２Ｈ’とされ、次のオブジェクトに処理が移されることが示される。すなわち、この場合には、同一オブジェクトテーブル内で、ツリー構造を枝側から葉側へと辿ってオブジェクトが探される。第２ビットが’１’であれば、ＧＥＴＮ操作用フィールドの値が’４Ｈ’とされ、次のグループに処理が移されることが示される。この場合には、互いに対応する番号のオブジェクトテーブル、例えばｔａｂｌｅ＃１が全て検索の対象とされる。
【００６２】
第３ビットが’１’であれば、当該ＣＰＵ（基板３０や機能ブロック）からのデータが終了されたことが示される。また、システム用ＣＰＵへのＡＣＫ応答時には、第７ビットが’１’とされ、ＧＥＴＮ操作用フィールドの値が’８０Ｈ’とされる。なお、このＧＥＴＮ操作用フィールドの値が’０’であれば、システム用ＣＰＵから各基板３０、３０、・・・に対する最初のアクセスであることが示される。
【００６３】
ＳＮＭＰマネージャ２から送られてきたオブジェクトＩＤと、システム用ＣＰＵが保有している基板構成の配列（図５参照）が、装着されている基板３０、３０、・・・にそれぞれ渡される。基板３０側では、｛オブジェクトＩＤ，システム用ＣＰＵが持つその基板のインデックス，ＧＥＴＮ操作用のフィールド｝の３つの値を用いて、自分宛の要求かどうかが判断される。
【００６４】
図１１は、基板３０におけるオブジェクトＩＤの一例の判別方法を示すフローチャートである。なお、ＧＥＴＮ操作用フィールドの値が’０’であれば、システム用ＣＰＵにより最初にこのフローチャートによる処理が行われることが示される。最初のステップＳ１０では、システム用ＣＰＵから基板３０に対してオブジェクトＩＤが渡され、基板３０では、ＲＯＭ３３に記憶された情報に基づきオブジェクトが検索される。オブジェクトの検索方法については後述するが、このとき、上述したシステム用ＣＰＵが持つその基板のインデックス、ＧＥＴＮ操作用のフィールドも、オブジェクトＩＤと共に渡される。
【００６５】
次のステップＳ１１で、該当するオブジェクトＩＤがあるかどうかが判断される。若し、ステップＳ１１で、該当するオブジェクトＩＤが無いと判断されれば、処理はステップＳ２２に移行する。ステップＳ２２では、ＧＥＴＮ操作用フィールドが参照され、値が’１’以下であれば、値が’１’にセットされる。そして、処理はステップＳ１９に移行し、基板３０からシステム用ＣＰＵに応答される。
【００６６】
一方、ステップＳ１１で、該当するオブジェクトＩＤがあると判断されれば、処理はステップＳ１２に移行する。ステップＳ１２では、そのオブジェクトが葉であるかどうかが判断される。若し、葉ではないと判断されれば、当該オブジェクトは、オブジェクトテーブルであるので、処理はステップＳ１３に移行し、そのオブジェクトテーブル内での最初のオブジェクトが検索される。そして、処理はステップＳ１１に戻され、ステップＳ１３での検索結果に基づく判断がなされる。
【００６７】
一方、ステップＳ１２で、検索されたオブジェクトが葉であると判断されれば、処理はステップＳ１４に移行し、ＧＥＴＮ操作用フィールドの値が’１’以下であるかどうかが判断される。若し、’１’以下であると判断されれば、処理はステップＳ１５に移行し、オブジェクト内に任意の値のインデックス’ｐ’があるかどうかが判断される。
【００６８】
若し、ステップＳ１５でインデックス’ｐ’がオブジェクト内に見つかれば、ステップＳ１７で、その値’ｐ’とシステム用ＣＰＵから指定されたインデックス’ｑ’とが比較される。比較の結果、（’ｐ’＜’ｑ’）であれば、処理はステップＳ２２に移行し、ＧＥＴＮ操作用フィールドの値が’１’以下であれば’１’とされ、基板３０からシステム用ＣＰＵに対して応答される。
【００６９】
なお、ステップＳ１５でインデックス’ｐ’がオブジェクト内に見つからなかったときには、システム用ＣＰＵから指定されたインデックス’ｑ’に基づき’ｑ−１’がインデックス’ｐ’とされ、処理はステップＳ１７に移行する。
【００７０】
一方、ステップＳ１７で、値’ｐ’と’ｑ’との比較の結果、（’ｐ’≧’ｑ’）であれば、処理はステップＳ１８に移行し、オブジェクトＩＤが決定されると共に、インデックスに’ｑ’が採用される。そして、処理はステップＳ１９に移行し、基板３０からシステム用ＣＰＵに応答される。
【００７１】
また、上述のステップＳ１４において、ＧＥＴＮ操作用フィールドの値が’１’以下でないと判断された場合、処理はステップＳ２０に移行する。ステップＳ２０では、ＧＥＴＮ操作用フィールドの値に基づき、次のオブジェクトあるいは次のグループが検索される。検索結果は、次のステップＳ２１で判断される。次のオブジェクトあるいはグループに目的のオブジェクトが見つかった場合には、処理はステップＳ１８に移行し、オブジェクトＩＤが決定されると共に、インデックスとしてシステム用ＣＰＵから指定された’ｑ’が採用される。
【００７２】
一方、ステップＳ２１において、次のオブジェクトあるいはグループに目的のオブジェクトが見つからないと判断された場合には、処理はステップＳ２２に移行し、ＧＥＴＮ操作用フィールドが’１’以下であれば’１’にされてステップＳ１９でシステム用ＣＰＵに応答される。
【００７３】
なお、上述の図１１のフローチャートによる処理おいて、システム用ＣＰＵから最初にデータを渡された基板３０で該当するオブジェクトが見つかった場合、システム用ＣＰＵからＳＮＭＰマネージャ２に対して応答される。一方、該当するオブジェクトが見つからなかった場合には、基板３０側でＧＥＴＮ操作用フィールドの値が’１’とされ、基板３０からシステム用ＣＰＵに対して’ＮＡＣＫ’が返される。また、連続したＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎが既に参照された基板３０’に渡された場合にも、基板３０’においてＧＥＴＮ操作用フィールドの値が適当な値にされ、基板３０’からシステム用ＣＰＵに対して’ＮＡＣＫ’が返される。
【００７４】
また、ＳＮＭＰマネージャ２からシステム用ＣＰＵに送られたＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎは、必ず、システム基板１０のシステム用ＣＰＵ経由で、対応する種類の基板中で最もインデックスが小さい基板に渡される。例えば、上述のビデオプロセッサ３において、スロット１１Ａ、１１Ｂ・・・の順にインデックスが割り当てられるとすれば、同種の基板のうち最も小さいインデックス値が割り当てられるスロットに装着されている基板に、ＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎによる指示が渡される。
【００７５】
次に、図１２のフローチャートを用いて、上述した図１１のステップＳ１９で基板３０からの応答を受け取った、システム用ＣＰＵにおける処理について説明する。最初のステップＳ７０で、基板３０からの応答がシステム用ＣＰＵに受け取られる。そして、ステップＳ７１、Ｓ７２およびＳ７３において、ＧＥＴＮ操作用フィールドの値に基づき処理が分岐される。
【００７６】
ステップＳ７１では、ＧＥＴＮ操作用フィールドの値が’８０Ｈ’以上であるかどうかが判断される。若し、’８０Ｈ’以上であれば、処理はステップＳ８０に移行し、システム用ＣＰＵにおいて、ＧＥＴＮ操作用フィールドに対応したＳＮＭＰパケットが生成される。生成されたＳＮＭＰパケットは、次のステップＳ８７でシステム用ＣＰＵからＳＮＭＰマネージャ２に送信される。
【００７７】
ステップＳ７１で、ＧＥＴＮ操作用フィールドの値が’８０Ｈ’以上ではないと判断されれば、処理はステップＳ７２に移行する。ステップＳ７２では、ＧＥＴＮ操作用フィールドの値が’１Ｈ’乃至’４Ｈ’であるかどうかが判断される。若し、’１Ｈ’乃至’４Ｈ’であれば、処理はステップＳ８１に移行し、当該応答を渡した基板３０が同種基板のうち最後の基板であるかどうかが判断される。これは、例えば当該基板のインデックスと、システム用ＣＰＵが保持する基板構成配列（図５参照）における当該基板と同種類の基板枚数を比較することで、判断できる。
【００７８】
ステップＳ８１の判断において、若し、当該基板３０が同種類の基板のうち最後の基板であると判断されれば、処理はステップＳ８２に移行する。ステップＳ８２では、ＧＥＴＮ操作用フィールドが１ビット左にシフトされ、再び同一の基板３０にデータが渡される。そして、基板３０において、ビットが左にシフトされたＧＥＴＮ操作用フィールドに基づき、上述した図１１による処理がなされる。
【００７９】
一方、ステップＳ８１で当該基板３０が同種類の基板のうち最後の基板で無いと判断されれば、処理はステップＳ８３に移行する。ステップＳ８３では、インデックスが次の番号の同種基板に、システム用ＣＰＵが受け取ったデータをそのまま渡す。そして、基板３０において、渡されたデータに基づき、上述した図１１による処理がなされる。
【００８０】
ステップＳ７２でＧＥＴＮ操作用フィールドの値が’１Ｈ’乃至’４Ｈ’でないと判断されれば、処理はステップＳ７３に移行する。ステップＳ７３では、ＧＥＴＮ操作用フィールドの値が’８Ｈ’であるかどうかが判断される。若し、’８Ｈ’で無いとされれば、ステップＳ７４で、エラーが発生したと判断される。
【００８１】
ＧＥＴＮ操作用フィールドの値が’８Ｈ’であると判断されれば、処理はステップＳ８４に移行する。ステップＳ８４では、対象になっている基板種類以降の基板が装着されているかどうかが判断される。例えば、システム用ＣＰＵにおいて、上述の図５の基板構成配列が参照され、対象となっている基板種類のグループ番号より大きいグループ番号の基板が装着されているかどうかが判断される。
【００８２】
若し、対象になっている基板種類以降の基板が装着されていると判断されれば、処理はステップＳ８５に移行する。そして、ステップＳ８５で、システム用ＣＰＵにおいてＧＥＴＮ操作用フィールドがリセットされ値が’０’とされ、次の種類の基板にデータが渡される。
【００８３】
一方、ステップＳ８４で、対象になっている基板種類以降の基板が装着されていないと判断されれば、処理はステップＳ８６に移行する。ステップＳ８６では、システム用ＣＰＵ側で、ＭＩＢの最後であることを通知するパケットが生成される。そして、処理はステップＳ８７に移行し、そのパケットがＳＮＭＰマネージャ２に送信される。
【００８４】
次に、基板３０における被プロキシ・エージェント側での処理について説明する。基板３０は、上述した図９に一例が示されるようなＭＩＢ情報を有する。このＭＩＢ情報は、ＳＮＭＰによるＭＩＢ情報がこの基板３０独自の形式に変換されて、基板３０に保持される。ＭＩＢ情報は、例えばＲＯＭ３３に予め記憶され、基板３０に保持される。なお、同種類の基板であっても、バージョンなどの違いにより、新たなオブジェクトが追加される場合がある。図９においては、塗り潰されたオブジェクト２−１−３がそれに相当する。すなわち、同種類の他のバージョンの基板３０’には無いオブジェクト２−１−３が、この基板３０には存在している。
【００８５】
図１３は、システム用ＣＰＵから基板３０に渡される一例の情報を示す。データ名ｍｏｄｅは、ＳＮＭＰの問い合わせ方法であって、上述したＧＥＴ／ＧＥＴＮ／ＳＥＴの何れを用いてＳＮＭＰが問い合わせられたかが記される。データ名ｃｍｄ＿ｃｔｌは、ＳＮＭＰ時のコマンドコントロールフィールドであって、１バイトが設けられ、上述したＧＥＴＮ操作用フィールドが記される。
【００８６】
データ名ｂｏａｒｄ＿ｉｄｘは、同種基板の識別子である同種基板識別用インデックスが記され、データ名ｂｏａｒｄ＿ｍａｘは、同種基板が現在筐体内に装着されている枚数が記される。これらｂｏａｒｄ＿ｉｄｘおよびｂｏａｒｄ＿ｍａｘを用いることにより、システム用ＣＰＵから渡されたデータに対してどのような処理を行えばよいかを、基板３０側で独自に判断することができる。
【００８７】
データ名ｃｍｄ＿ｌｅｎは、オブジェクトＩＤのデータ長が記される。ｃｍｄは、実際のオブジェクトＩＤのデータ列が記される。
【００８８】
図１４、図１５、図１６および図１７を用いて、上述した、基板３０側でのオブジェクトの検索方法について説明する。図１４、図１５および図１６は、それぞれＧＥＴＮ操作用フィールドの値が’１Ｈ’以下、’２Ｈ’、’４Ｈ’または’８Ｈ’の場合のフローチャートである。また、図１７は、図１４に示すＧＥＴＮ操作用のフィールドの値が’１Ｈ’の場合の検索方法を説明するための、一例のＭＩＢ構造を示す。
【００８９】
なお、図１７に一例が示されるＭＩＢツリーにおいて、長方形はオブジェクトテーブルを示し、テーブルの下に、そのテーブルに対応するオブジェクトＩＤの、基板種類識別番号である’ｘ’以下の部分を記す。また、最も深い階層をｎ＝１として、一つ浅い階層に移動する毎に、ｎを１ずつ増加させる。最も深い位置のテーブルがある階層を１として、ＭＩＢツリーを根（ルート）の方に上がっていったときに、その基板のトップ（根元）の階層に対応する値をリミット値と呼ぶ。この図１７の例では、リミット値は、ｎ＝４である。
【００９０】
図１４は、ＧＥＴＮ操作用フィールドの値が’１Ｈ’以下の場合の、オブジェクトの一例の検索方法を示す。より深い階層から検索するために、先ず、オブジェクトテーブルｔａｂｌｅ＃ｎの検索基準として、ｎ＝１に設定される（ステップＳ３０）。図１７におけるテーブルＡ、Ｂが最初の検索対象とするために、このように設定する。次のステップＳ３１で、ｎが所定のリミット値以下であるかどうかが判断される。ｎがリミット値以下ではないと判断されれば、処理はステップＳ４０に移行し、当該基板３０内に該当するオブジェクトが無いとされ、一連の処理が終了される。
【００９１】
一方、ステップＳ３１で、ｎがリミット位置以下であると判断されれば、処理はステップＳ３２に移行する。ステップＳ３２では、ｔａｂｌｅ＃ｎが検索される。そして、ステップＳ３３で、検索されたｔａｂｌｅ＃ｎのオブジェクトＩＤがシステム用ＣＰＵから受け取ったオブジェクトＩＤに完全に含まれるかどうかが判断される。若し、検索されたｔａｂｌｅ＃ｎがこの条件を満たしていないと判断されれば、ステップＳ３４でｎを１つ増して、処理がステップＳ３１に戻される。
【００９２】
一方、ステップＳ３３で、ｔａｂｌｅ＃ｎが条件を満たしていると判断されれば、処理はステップＳ３５に移行する。システム用ＣＰＵから受け取ったオブジェクトＩＤの長さが上述したステップＳ３３で見つかったテーブルのオブジェクトＩＤよりも短いと判断されれば、処理はステップＳ３６に移行する。ステップＳ３６では、ｔａｂｌｅ＃ｎ内から、辞書式順序で以て最も小さなオブジェクトが取り出される。そして、次のステップＳ３７でオブジェクトが発見されたとされる。
【００９３】
一方、上述したステップＳ３５で、システム用ＣＰＵから受け取ったオブジェクトＩＤの長さが上述したステップＳ３３で見つかったテーブルのオブジェクトＩＤよりも長いと判断されれば、処理はステップＳ３９に移行する。この場合には、システム用ＣＰＵから受け取ったオブジェクトＩＤがｔａｂｌｅ＃ｎのオブジェクトＩＤよりもデータ長が長く、さらに細部までオブジェクトの指定がなされていることになるので、オブジェクトテーブルからオブジェクトを直接的に取り出すことができる。ステップＳ３９では、ｔａｂｌｅ＃１内から該当するオブジェクトが取り出され、処理がステップＳ３７に移行される。
【００９４】
上述の処理を、より具体的な例を用いて説明する。ここでは、システム用ＣＰＵから送られたオブジェクトＩＤが｛６００４．ｘ．５．１．ｙ｝（前半は省略する）であるものとして説明する。リミット値ｎは、ｎ＝４である。オブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝において、ｎ＝１に対応する値は’ｙ’、ｎ＝２に対応する値は’１’、ｎ＝３に対応する値は’５’となる。オブジェクトＩＤにおいて、ｎに応じて、それぞれの階層に対応する長さまで、テーブル検索時に一致している必要がある。上述したように、より深い階層から検索を行うために、ステップＳ３０によりｎ＝１に設定される。図１７におけるテーブルＡ、Ｂを最初の検索対象とするために、このように設定する。
【００９５】
ステップＳ３３により、ｎ＝１の階層では、オブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝が含むオブジェクトＩＤを持つテーブルが存在しなかったので、ステップＳ３４によりｎを１つ増やしてｎ＝２として、一つ上の階層について検索が試みられる。
【００９６】
検索の結果、ｎ＝２の階層において、テーブルＣ、ＤおよびＥにはオブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝が含むｎ＝２の階層までの長さのオブジェクトＩＤが存在しなかったので、続いてテーブルＦについてオブジェクトＩＤ｛６００４．ｘ．５．１．ｙ｝がテーブルのオブジェクトＩＤ｛６００４．ｘ．５．１｝を含むかどうかが調べられる。テーブルＦのオブジェクトＩＤは、｛ｘ．５．１｝であり、オブジェクトＩＤ｛６００４．ｘ．５．１｝に含まれることが分かる（ステップＳ３５）。処理はステップＳ３９に移行してテーブルＦからオブジェクトが取り出され、ステップＳ３７でオブジェクトが発見されたとされる。
【００９７】
図１５は、ＧＥＴＮ操作用フィールドの値が’２Ｈ’の場合の、オブジェクトの一例の検索方法を示す。ここでは、ｔａｂｌｅ＃１についてオブジェクトを検索する場合について説明する。先ず、最初のステップＳ５０で、ｔａｂｌｅ＃１のうち、オブジェクトＩＤがシステム用ＣＰＵから受け取ったオブジェクトＩＤに完全に含まれているオブジェクトテーブルが検索される。検索の結果に基づき、ステップＳ５１で、一致するテーブルが存在しないと判断されれば、処理はステップＳ５５に移行し、該当するオブジェクトが存在しないとされる。
【００９８】
一方、ステップＳ５１で、一致するテーブルが存在すると判断されれば、処理はステップＳ５２に移行し、ｔａｂｌｅ＃１から該当するオブジェクトが取り出される。そして、次のステップＳ５３で、このＭＩＢテーブル（図９参照）において、取り出された次のオブジェクトが葉であるかどうかが判断される。若し、葉であると判断されれば、その葉であるオブジェクトが求めるオブジェクトであるとして、オブジェクトが発見されたとされる（ステップＳ５４）。
【００９９】
一方、ステップＳ５３で、次のオブジェクトが葉ではないと判断されれば、現在検索中のテーブル内には該当するオブジェクトが無いので、処理はステップＳ５５に移行する。
【０１００】
図１６は、ＧＥＴＮ操作用フィールドの値が’４Ｈ’または’８Ｈ’の場合の、オブジェクトの一例の検索方法を示す。ここでは、ｔａｂｌｅ＃１についてオブジェクトを検索する場合について説明する。先ず、最初のステップＳ６０で、ｔａｂｌｅ＃１のうち、オブジェクトＩＤがシステム用ＣＰＵから受け取ったオブジェクトＩＤに完全に含まれているオブジェクトテーブルが検索される。検索の結果に基づき、ステップＳ６１で、一致するテーブルが存在しないと判断されれば、処理はステップＳ６５に移行し、該当するオブジェクトが存在しないとされる。
【０１０１】
一方、ステップＳ６１で、一致するｔａｂｌｅ＃１が存在すると判断されれば、処理はステップＳ６２に移行し、辞書式順序で、次のｔａｂｌｅ＃１が検索される。検索結果に基づき、次のステップＳ６３で、次のｔａｂｌｅ＃１が存在するかどうかが判断される。若し、次のｔａｂｌｅ＃１が存在すると判断されれば、処理は次のステップＳ６４に移行し、見つかったｔａｂｌｅ＃１内で最初のオブジェクトが該当オブジェクトとされる。
【０１０２】
一方、ステップＳ６３で、次のｔａｂｌｅ＃１が存在しないと判断されれば、処理はステップＳ６５に移行し、該当するオブジェクトが存在しないとされる。
【０１０３】
なお、ＧＥＴＮ操作用フィールドの値が’４Ｈ’の処理が終了したら、次にＧＥＴＮ操作用フィールドの値が’８Ｈ’の処理が行われ、図１６の処理が２回繰り返されることになる。これは、オブジェクトの検索ミスを防止するための処理であって、ＧＥＴＮ操作用フィールドの値が’８Ｈ’の場合の検索処理を行わなくても、正常に動作する。
【０１０４】
図１４、図１５および図１６を用いて上述したような方法でオブジェクトを検索することにより、同種基板で新たなオブジェクトが追加された基板と、新たな基板が追加されていない以前のバージョンの基板とが同一筐体内に共存する場合でも、オブジェクトの抜けが無く、ＧＥＴ Ｎｅｘｔ Ｏｐｅｒａｔｉｏｎを動作させることができる。
【０１０５】
なお、上述の動作を保証するためには、新規オブジェクトの追加および削除作業を正しく行う必要がある。例えば、新規オブジェクトの追加および削除作業を行う際の制限事項として、以下の３項目が設けられる。
(1)既存のオブジェクトのオブジェクトＩＤを変更してはならない。
(2)オブジェクトが不要になった、あるいは、オブジェクトが削除された場合は、当該オブジェクトのオブジェクトＩＤを欠番として残しておく。
(3)むやみに深い階層にオブジェクトを追加しない。
【０１０６】
図１８、図１９および図２０は、好ましくないオブジェクト追加および削除方法の例を示す。図１８は、上述した(1)の項目に対応し、オブジェクトを追加する際に既存のオブジェクトのオブジェクトＩＤを変更してしまった例である。図１８Ａに示される、ｔａｂｌｅ＃１の下にある既存のオブジェクト１−１、１−２および１−３を考える。この構成に対して、１−１の前にオブジェクトが挿入されると、図１８Ｂのようになり、既存のオブジェクト１−１、１−２および１−３がオブジェクト１−２、１−３および１−４にシフトされ、新たに挿入追加されたオブジェクトがオブジェクト１−１となっている。この場合には、オブジェクトＩＤによるオブジェクトの検索を行ったときに、正しいオブジェクトが検索されないおそれがある。
【０１０７】
図１９は、上述した(2)の項目に対応し、オブジェクトを削除した際に、既存のオブジェクトが繰り上げられた例である。図１９Ａに示される、ｔａｂｌｅ＃１の下にあるオブジェクト２−１、２−２および２−３を考える。この状態から、オブジェクト２−１が削除され、図１９Ｂに示されるように、既存のオブジェクト２−２および２−３がそれぞれオブジェクト２−１および２−２と、オブジェクトＩＤが繰り上がっている。この場合にも、上述と同様に、オブジェクトＩＤによるオブジェクトの検索を行ったときに、正しいオブジェクトが検索されないおそれがある。
【０１０８】
図２０は、上述した(3)の項目に対応し、非常に深い階層にオブジェクトが追加された例である。この場合には、オブジェクトの検索に非常に時間がかかってしまうおそれがある。例えば、オブジェクト３−２−１を検索するためには、ｔａｂｌｅ＃６、ｔａｂｌｅ＃５、ｔａｂｌｅ＃４、ｔａｂｌｅ＃３、ｔａｂｌｅ＃２およびｔａｂｌｅ＃１と、階層を辿らなくてはいけない。
【０１０９】
なお、上述した(1)、(2)および(3)の制限は、ＩＡＮＡ(Internet Assigned Numbers Authority)により定義されたものである。この制限に準じない方法でオブジェクトを追加あるいは削除した場合には、この発明により組み込まれたプロキシ・エージェントが正常に動作しない可能性がある。
【０１１０】
上述では、この発明がディジタルビデオおよびオーディオ信号を処理するエンコーダ・デコーダに適用されるように説明したが、これはこの例に限定されない。例えば、この発明は、パーソナルコンピュータといったコンピュータ装置のスロットに装着されて使用される、拡張カードにも適用することができる。この場合には、パーソナルコンピュータのスロットに装着された拡張カードを、ＭＩＢによって管理することができるようになる。
【０１１１】
【発明の効果】
以上説明したように、この発明は、ＳＮＭＰマネージャにプロキシ・エージェントを介して管理される各基板側がＭＩＢによる管理対象となるオブジェクトを持っているので、プロキシ・エージェント側で、各基板それぞれに特有のオブジェクトに関する情報から解放されるという効果がある。
【０１１２】
これにより、新たな基板が開発された場合でも、プロキシ・エージェントに手を加えることなく、ＳＮＭＰマネージャが持つＭＩＢ定義ファイルを変更するだけで、オブジェクトを追加することができる効果がある。
【図面の簡単な説明】
【図１】この発明を適用可能な一例のシステムを示すブロック図である。
【図２】ビデオプロセッサに装着可能な基板の例を示す略線図である。
【図３】ＭＩＢ一例の構成を示す略線図である。
【図４】ビデオプロセッサに装着される基板の一例の構成を概略的に示すブロック図である。
【図５】ビデオプロセッサにおける識別番号の一例の配列の内容を示す略線図である。
【図６】オブジェクトＩＤの一例の構造を示す略線図である。
【図７】ＧＥＴ／ＳＥＴ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す略線図である。
【図８】ＧＥＴ Ｎｅｘｔ Ｒｅｑｕｅｓｔの場合の一例のデータ遷移図を示す略線図である。
【図９】基板側のＭＩＢ情報オブジェクトの一例の構成を示す略線図である。
【図１０】ＧＥＴＮ操作用のフィールドの一例を示す略線図である。
【図１１】基板におけるオブジェクトＩＤの一例の判別方法を示すフローチャートである。
【図１２】基板からの応答を受け取ったシステム用ＣＰＵにおける一例の処理を示すフローチャートである。
【図１３】システム用ＣＰＵから基板に渡される一例の情報を示す略線図である。
【図１４】ＧＥＴＮ操作用フィールドの値が’１Ｈ’以下の場合のオブジェクトの一例の検索方法を示すフローチャートである。
【図１５】ＧＥＴＮ操作用フィールドの値が’２Ｈ’の場合のオブジェクトの一例の検索方法を示すフローチャートである。
【図１６】ＧＥＴＮ操作用フィールドの値が’４Ｈ’または’８Ｈ’の場合のオブジェクトの一例の検索方法を示すフローチャートである。
【図１７】ＧＥＴＮ操作用のフィールドの値が’１Ｈ’の場合の検索方法を説明するための、一例のＭＩＢ構造を示す略線図である。
【図１８】オブジェクトを追加する際に既存のオブジェクトのオブジェクトＩＤを変更してしまった例を示す略線図である。
【図１９】オブジェクトを削除した際に既存のオブジェクトが繰り上げられた例を示す略線図である。
【図２０】非常に深い階層にオブジェクトが追加された例を示す略線図である。
【図２１】プロキシエージェントによる一例のアーキテクチャを示すブロック図である。
【符号の説明】
２・・・ＳＮＭＰマネージャ、３・・・ＳＮＭＰエージェント、１０・・・プロキシ・エージェント、１１Ａ，１１Ｂ，１１Ｃ，１１Ｄ，１１Ｅ・・・スロット、３０，３０Ａ，３０Ｂ，３０Ｃ，３０Ｄ・・・基板、３２・・・ＣＰＵ、３３・・・ＲＯＭ、３４・・・通信インターフェイス、３５・・・コネクタ、３６・・・機能部
Claims (13)
- ＳＮＭＰが実装されプロキシ・エージェントの機能を持つシステム用ＣＰＵおよびメモリを有するシステム基板と、
複数の組込電子機器をそれぞれ接続するための複数の組込手段と、
ネットワークを介してＳＮＭＰマネージャとの通信を行う第１の通信手段と、
ＳＮＭＰに基づくオブジェクトＩＤをＳＮＭＰとは異なるプロトコルに変換する変換手段と、
上記複数の組込手段により組み込まれた上記複数の組込電子機器の種類および該種類毎の数を取得する機器情報取得手段と、
上記複数の組込電子機器に対して上記ＳＮＭＰとは異なるプロトコルを用いて通信を行う第２の通信手段と
を備え、
上記機器情報取得手段は、所定の周期で上記複数の組込電子機器をスキャンし、上記複数の組込手段により組み込まれた上記複数の組込電子機器の種類および該種類毎の数を取得し、
上記メモリは、上記取得された上記複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、
上記オブジェクトＩＤが上記ＳＮＭＰマネージャから供給された際に、上記オブジェクトＩＤのうち、上記組込電子機器の種類を示す識別子を参照することにより、上記メモリに保持された配列から、問い合わせの対象となる上記組込電子機器を特定し、
上記問い合わせの対象となる上記組込電子機器が組み込まれている場合に、上記オブジェクトＩＤを上記問い合わせの対象となる上記組込電子機器に渡すようにした組込型電子機器。 - 上記組込電子機器の種類を示す識別子は、上記システム基板に搭載されたＣＰＵおよび上記組込電子機器が有するＣＰＵをそれぞれ識別するものであり、
上記組込電子機器が有するＣＰＵを示す識別子の値が、上記システム基板に搭載されたＣＰＵを示す識別子の値よりも大である請求項１の組込型電子機器。 - オブジェクト情報が格納されるオブジェクト情報格納手段を有し、
上記オブジェクト情報が、組込型電子機器を介してＳＮＭＰマネージャの管理対象となるオブジェクトを示すものである組込電子機器。 - 上記オブジェクト情報に対するポインタが格納されたオブジェクトテーブルを有し、上記オブジェクトテーブルに基づき上記オブジェクト情報が組込型電子機器を介してＳＮＭＰマネージャに参照される請求項３に記載の組込電子機器。
- 複数の組込電子機器をそれぞれ接続するための組み込みのステップと、
ネットワークを介してＳＮＭＰマネージャとの通信を行う第１の通信のステップと、
ＳＮＭＰに基づくオブジェクトＩＤをＳＮＭＰとは異なるプロトコルに変換する変換のステップと、
上記複数の組込手段により組み込まれた上記複数の組込電子機器の種類および該種類毎の数を取得する機器情報取得のステップと、
上記複数の組込電子機器に対して上記ＳＮＭＰとは異なるプロトコルを用いて通信を行う第２の通信のステップと
を備え、
ＳＮＭＰが実装されプロキシ・エージェントの機能を持つシステム用ＣＰＵおよびメモリを有するシステム基板を備えた組込型電子機器により、
上記機器情報取得のステップにおいて、所定の周期で上記複数の組込電子機器をスキャンし、上記複数の組込手段により組み込まれた上記複数の組込電子機器の種類および該種類毎の数を取得し、
上記メモリは、上記取得された上記複数の組込電子機器の種類毎の数と各組込電子機器を識別するための識別子とを対応付けた配列として保持し、
上記オブジェクトＩＤが上記ＳＮＭＰマネージャから供給された際に、上記オブジェクトＩＤのうち、上記組込電子機器の種類を示す識別子を参照することにより、上記メモリに保持された配列から、問い合わせの対象となる上記組込電子機器を特定し、
上記問い合わせの対象となる上記組込電子機器が組み込まれている場合に、上記オブジェクトＩＤを上記問い合わせの対象となる上記組込電子機器に渡すようにした組込電子機器の管理方法。 - 組込型電子機器が有するＣＰＵおよび上記組込型電子機器に組み込まれる組込電子機器の種類に応じてグループ分けしたグループ識別子を配し、
上記組込電子機器の種類を示すグループ識別子の値が、上記組込型電子機器が有するＣＰＵを示すグループ識別子の値よりも大であるとされたＭＩＢ構造を表すオブジェクトＩＤを用い、
上記組込型電子機器に組み込まれる上記組込電子機器を、上記組込型電子機器を介してＳＮＭＰマネージャにより管理する組込電子機器の管理方法。 - 上記グループ識別子に対応するオブジェクト情報を上記組込電子機器側が持つようにした請求項６に記載の組込電子機器の管理方法。
- 上記組込電子機器が、複数のオブジェクトを有し、
上記複数のオブジェクトが、上記組込型電子機器を介してＳＮＭＰマネージャにより管理される請求項６に記載の組込電子機器の管理方法。 - 上記オブジェクトが、該オブジェクトに対するポインタが格納されたオブジェクトテーブルにより、組込型電子機器を介してＳＮＭＰマネージャに参照される請求項８に記載の組込電子機器の管理方法。
- 上記組込型電子機器と上記組込電子機器との間の通信が、
該組込電子機器からのデータが終わりであるかどうかを示す第１の値と、
次の種類の上記組込電子機器に処理を移すかどうかを指示する第２の値と、
該組込電子機器内の次の上記オブジェクトに処理を移すかどうかを指示する第３の値と、
上記オブジェクトを固定して該組込電子機器と同一種類の次の上記組込電子機器に処理を移すかどうかを指示する第４の値と
を含むフィールドを用いてなされる請求項９に記載の組込電子機器の管理方法。 - 上記フィールドの上記第２の値が上記組込電子機器内の次の上記オブジェクトに処理を移すことを示すときには、
上記オブジェクトテーブルを識別する識別子が互いに対応する上記オブジェクトテーブルのうち、上記組込型電子機器から送られた上記オブジェクトＩＤに完全に含まれる上記オブジェクトテーブルを検索し、
検索されたオブジェクトテーブル内で、上記オブジェクトテーブルを識別する識別子が対応する上記オブジェクトテーブルを辞書式順序でさらに検索し、
検索されたオブジェクトテーブル内の最初のオブジェクトを取り出すようにした請求項１０に記載の組込電子機器の管理方法。 - 上記フィールドの上記第３の値が上記組込電子機器内の次の上記オブジェクトに処理を移すことを示すときには、
上記オブジェクトテーブルを識別する識別子が互いに対応する上記オブジェクトテーブルのうち、上記組込型電子機器から送られた上記オブジェクトＩＤに完全に含まれる上記オブジェクトテーブルを検索し、
検索されたオブジェクトテーブル内の該当するオブジェクトのうち、上記ＭＩＢ構造の葉であるオブジェクトを取り出すようにした請求項１０に記載の組込電子機器の管理方法。 - 上記フィールドの上記第４の値が次の種類の上記組込電子機器に処理を移すことを示すときには、
上記組込電子機器が持つ上記オブジェクトテーブルのうち、上記組込型電子機器から送られた上記オブジェクトＩＤに完全に含まれる上記オブジェクトテーブルを検索し、
検索されたオブジェクトテーブルが上記組込電子機器の持つ最初のオブジェクトテーブルであって、且つ、該オブジェクトテーブルのオブジェクトＩＤが上記送られたオブジェクトＩＤと長さが異なれば、該オブジェクトテーブルから該当するオブジェクトを取り出し、
上記検索されたオブジェクトテーブルが上記組込電子機器の持つ最初のオブジェクトテーブルであって、且つ、該オブジェクトテーブルのオブジェクトＩＤが上記送られたオブジェクトＩＤと同一の長さであれば、該オブジェクトテーブル内から辞書式順序で最も小さなオブジェクトを取り出し、
上記検索されたオブジェクトテーブルが上記組込電子機器の持つ最初のオブジェクトテーブルでなければ、該オブジェクトテーブル内から辞書式順序で最も小さなオブジェクトを取り出すようにした請求項１０に記載の組込電子機器の管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001029358A JP4581259B2 (ja) | 2001-02-06 | 2001-02-06 | 組込型電子機器ならびに組込電子機器および組込電子機器の管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001029358A JP4581259B2 (ja) | 2001-02-06 | 2001-02-06 | 組込型電子機器ならびに組込電子機器および組込電子機器の管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002229875A JP2002229875A (ja) | 2002-08-16 |
| JP4581259B2 true JP4581259B2 (ja) | 2010-11-17 |
Family
ID=18893715
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001029358A Expired - Fee Related JP4581259B2 (ja) | 2001-02-06 | 2001-02-06 | 組込型電子機器ならびに組込電子機器および組込電子機器の管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4581259B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050094663A1 (en) * | 2003-11-05 | 2005-05-05 | Interdigital Technology Corporation | Method and system for providing intelligent remote access to wireless transmit/receive units |
| JP2008504765A (ja) * | 2004-06-30 | 2008-02-14 | シーメンス アクチエンゲゼルシヤフト | Ｐｏｎの光出力レベルを取得する方法および装置 |
| JP5862417B2 (ja) * | 2012-03-29 | 2016-02-16 | ブラザー工業株式会社 | 管理デバイス |
| JP2014026437A (ja) * | 2012-07-26 | 2014-02-06 | Nippon Telegr & Teleph Corp <Ntt> | 情報収集システム、サーバ装置および情報収集方法 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3017089B2 (ja) * | 1996-06-17 | 2000-03-06 | 日本電気株式会社 | ネットワーク管理装置および方法 |
| JPH10334013A (ja) * | 1997-06-04 | 1998-12-18 | Nippon Telegr & Teleph Corp <Ntt> | 分散型システムのための運用監視方法およびそのシステム |
| JP3744137B2 (ja) * | 1997-08-07 | 2006-02-08 | ブラザー工業株式会社 | ネットワークシステム、ネットワーク管理方法、インタフェース装置、インタフェース装置を動作させるためのプログラムが記録された記録媒体及び端末装置 |
| JPH11327936A (ja) * | 1998-05-11 | 1999-11-30 | Canon Inc | データベース管理方法及び装置とネットワーク管理方法及び装置 |
| JP3438772B2 (ja) * | 1999-03-17 | 2003-08-18 | 日本電気株式会社 | Ｓｎｍｐエージェントとして動作するように実装する方法を共通化するシステム |
-
2001
- 2001-02-06 JP JP2001029358A patent/JP4581259B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002229875A (ja) | 2002-08-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5055376B2 (ja) | Ｓａｓゾーン・グループ・パーミッション・テーブルのバージョン識別子 | |
| US7200548B2 (en) | System and method for modeling a network device's configuration | |
| US7817583B2 (en) | Method for verifying a storage area network configuration | |
| US8812137B2 (en) | Controlling sensor networks | |
| US6971090B1 (en) | Common Information Model (CIM) translation to and from Windows Management Interface (WMI) in client server environment | |
| US8312128B2 (en) | Identification of management information base object identifiers supported by a managed device | |
| EP1719289B1 (en) | Generating topology information identifying devices in a network topology | |
| US20090292707A1 (en) | Electronic apparatus and content data providing method | |
| CN113381870B (zh) | 报文处理方法和设备 | |
| US20080178202A1 (en) | Interface For Supporting an Element Management System | |
| CA2582380A1 (en) | Network management apparatus and method based on simple network management protocol | |
| US8589381B2 (en) | Resource management program, resource management process, and resource management apparatus | |
| KR100716167B1 (ko) | 네트워크 관리 시스템 및 방법 | |
| KR102226915B1 (ko) | 소프트웨어 정의 네트워크에서 플로우 룰 데이터베이스를 운영하는 방법, 장치 및 컴퓨터 프로그램 | |
| US8782186B2 (en) | Systems and methods for addressing managed elements | |
| EP1589691B1 (en) | Method, system and apparatus for managing computer identity | |
| CN1514576A (zh) | 通信装置 | |
| US20080301143A1 (en) | Automatic Update System and Method for Using a Meta Mib | |
| JP4581259B2 (ja) | 組込型電子機器ならびに組込電子機器および組込電子機器の管理方法 | |
| US7761520B2 (en) | Information management system, information management apparatus and computer-readable storage medium | |
| CN100337433C (zh) | 在网管系统中控制和管理电信设备的方法 | |
| KR100372386B1 (ko) | Ｓｎｍｐ인터페이스를 사용하여 ａｉｘ 유닉스 서버를관리하기 위한 방법 및 시스템 | |
| US20050076343A1 (en) | Persistent storage of network management data using object references | |
| US6981046B2 (en) | System for the efficient transmission of partial objects in distributed data bases | |
| US7734640B2 (en) | Resource discovery and enumeration in meta-data driven instrumentation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20071206 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090901 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100309 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100428 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100803 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100816 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130910 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |