JP2004070964A - デバイスドライバ制御共通化方法 - Google Patents

デバイスドライバ制御共通化方法 Download PDF

Info

Publication number
JP2004070964A
JP2004070964A JP2003289785A JP2003289785A JP2004070964A JP 2004070964 A JP2004070964 A JP 2004070964A JP 2003289785 A JP2003289785 A JP 2003289785A JP 2003289785 A JP2003289785 A JP 2003289785A JP 2004070964 A JP2004070964 A JP 2004070964A
Authority
JP
Japan
Prior art keywords
device driver
driver
layer
function
application
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.)
Pending
Application number
JP2003289785A
Other languages
English (en)
Inventor
Hyong-Kyun Lee
李　亨均
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2004070964A publication Critical patent/JP2004070964A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23265—Select device driver for actuator, sensor

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

【課題】通信システムに使用する上位アプリケーション階層と下位デバイスドライバ階層との間に中間層としてデバイス独立アクセス(ＤＩＡ)階層を位置させて相互インタフェースを提供し、上位アプリケーション階層と下位デバイスドライバ階層を独立的に共通化して使用可能にする方法を提供する。
【解決手段】本発明のデバイスドライバ制御共通化方法は、ＤＩＡ階層をアプリケーション階層とデバイスドライバ階層との間に位置させ、上位アプリケーション階層及びデバイスドライバ階層にＤＩＡ階層の標準化規則を適用させる第１過程と、ＤＩＡ階層の標準化規則を通じてアプリケーション階層及びデバイスドライバ階層はＤＩＡ階層がデバイスドライバ階層及び上位アプリケーション階層に相互にアクセスする第２過程と、からなることを特徴とする。　　
【選択図】図４

Description

　本発明は通信システムに関し、特に、ハードウェアチップレベルのデバイスドライバ制御を共通化するための方法に関するものである。
　一般に、上位アプリケーション(higher-order application)及び下位デバイスドライバ(lower-order device driver)製品は対話形成チャンネル(communication channel)が構築されないで開発されている現状があり、最近では多くのデバイスドライバがベンダー(vendor)から提供されている。これは、上位アプリケーションと下位デバイスドライバ製品間におけるコミュニケーションの不足が深刻化していることを意味する。従来、ＡＰＩ(Application Program Interface)は上位アプリケーションと下位デバイスドライバ個々特有のそれぞれの標準に基づいて作成されている。したがって、上位アプリケーション及び下位デバイスドライバはそれぞれの標準に合わせて作ることができる。
　デバイスドライバが上位アプリケーションの要求を満たすことができない場合、上位アプリケーションに影響を及ぼすコード(code)や構造(structure)を変更しなければならないといった問題がある。この場合、上位アプリケーションと下位デバイスドライバを検証する必要がある。
　同一アプリケーションに関して下位の同一機能を有するデバイスＡがデバイスＢに変更され、あるいは２つのアプリケーションが同一デバイスドライバを使用する場合に特定部分が変更されると、上位アプリケーション及びデバイスドライバに対する検証を行わなければならない。このような検証要求は製品開発のために多くの時間を費やすことになるので、その製品開発に悪影響を与え、競争力を低下させるという問題をもたらしている。
　したがって、本発明の目的は、通信システムで相互インタフェースを確立すべく上位アプリケーション階層と下位デバイスドライバ階層との間に中間階層としてデバイス独立アクセス(Device Independent Access：ＤＩＡ)階層を配置することにより上位アプリケーション階層と下位デバイスドライバ階層を独立的に及び共通化して使用可能な方法を提供することにある。
　また、本発明の他の目的は、通信システムにおける下位デバイスドライバ階層を独立的に及び共通化して使用可能な方法を提供することにある。
　さらに、本発明の他の目的は、通信システムにおける上位アプリケーション階層を独立的に及び共通化して使用可能な方法を提供することにある。
　このような課題を解決するために本発明のデバイスドライバ制御共通化方法は、 デバイス独立アクセス階層をアプリケーション階層とデバイスドライバ階層との間に位置させ、アプリケーション階層及びデバイスドライバ階層にデバイス独立アクセス階層の標準化規則を適用させる第１過程と、前記デバイス独立アクセス階層の標準化規則を通じてアプリケーション階層及びデバイスドライバ階層がデバイスドライバ階層及び上位アプリケーション階層に相互アクセスする第２過程とからなることを特徴とする。
　この方法において、第２過程は、アプリケーション階層が該当デバイスドライバに対する標準化共通フォーマットに基づく制御コマンドをデバイス独立アクセス階層に伝送し、及び、デバイス独立アクセス階層が、制御コマンドをローカルフォーマットに基づく他の制御コマンドに変換し、該変換した制御コマンドをデバイスドライバに伝達する段階と、デバイスドライバがローカルフォーマットに基づく変換した制御コマンドの応答をデバイス独立アクセス階層に伝送し、及び、デバイス独立アクセス階層が、デバイスドライバからの応答を標準化共通フォーマットに基づく応答に変換し、該標準化共通フォーマットに基づく応答をアプリケーション階層に伝達する段階と、からなるとよい。
　また、本発明では、デバイスドライバ制御共通化方法において、デバイス独立アクセス階層をアプリケーション階層とデバイスドライバ階層との間に位置させる過程と、ファンクションブロックのファンクションのうち、該当デバイスドライバで使用可能なファンクションをファンクションテーブルに定義する過程と、デバイスが初期化される場合、デバイス独立アクセス階層が、デバイスに対する標準化データフォーマットに基づくデバイスハンドラ識別子を生成し、該生成したデバイスハンドラ識別子を上位のアプリケーション階層に伝達する過程と、該上位アプリケーション階層がデバイスハンドラ識別子を用いて所定デバイスを呼び出し、デバイス独立アクセス階層がデバイスハンドラ識別子を用いてファンクションテーブルから該当デバイスドライバのファンクションを識別する過程と、からなることを特徴とするデバイスドライバ制御共通化方法も提供する。
　この方法で、デバイスハンドラ識別子はDCB handlerId[x1.x2.x3]で表現され、x1,x2,x3が符号なし整数であり、x1がデバイス識別子を意味するレベル１の値で、x2が該当デバイスの論理又は物理グループ番号を意味するレベル２の値で、x3が該当デバイス又はグループのチャンネル番号を意味するチャンネルの値であると好ましい。
　x1,x2,x3の値が“０”であれば、該当レベル又はチャンネルが存在しないことを意味し、デバイスが初期化される場合にx1の値が“１”から順次に増加するとなおよい。
　さらに、本発明では、デバイスドライバ制御共通化方法において、デバイス独立アクセス階層をアプリケーション階層とデバイスドライバ階層との間に位置させる過程と、アプリケーション階層によってデバイス初期化が制御される場合、デバイス独立アクセス階層が、デバイスのレベル１初期化、レベル２初期化、チャンネル初期化を実行し、デバイスに対する標準化データフォーマットに基づくデバイスハンドラ識別子を生成する過程と、デバイス独立アクセス階層がデバイスハンドラ識別子に対応する標準化規則を実行するためのエレメントを含むデバイス制御ブロックを動的に割り当てる過程と、デバイス独立アクセス階層がアプリケーション階層にデバイスハンドラ識別子を提供する過程と、アプリケーション階層がデバイスハンドラ識別子を用いてデバイス独立アクセス階層を通じて所定デバイスを呼び出す過程と、からなることを特徴とするデバイスドライバ制御共通化方法も提供する。
　この方法でデバイス制御ブロックのエレメントは、標準化固有値を有しコマンドファンクションポインタがマッピングされているコマンド識別子を含むコマンド制御テーブルの位置を知らせるポインタ*pControlTable、該当ファンクションの存在有無及び位置を識別するためにデバイスドライバ制御テーブルの位置を知らせるポインタ*pDDCB、次のレベルを指示するポインタ*pAnchorを少なくとも含むとよい。
　デバイス制御ブロックのエレメントは、デバイス初期化時に与えられる初期化プロファイルの位置を知らせるポインタ*pHandler、デバイスの初期化時に使用されるファンクションのあるファンクションポインタ*fpIntiDevice、チャンネルをオープンするときに使用されるファンクションのあるファンクションポインタ*fpOpenChannel、チャンネルをクローズするときに使用されるファンクションのあるファンクションポインタ*fpCloseChannel、オープンチャンネルのデータを読み出すときに使用されるファンクションポインタ*fpRead、オープンチャンネルのデータを書き込むときに使用されるファンクションポインタ*fpWrite、デバイスのリセット時のファンクションポインタ*fpReset、標準化固有値を有しコマンドファンクションポインタがマッピングされているコマンド識別子を含むコマンド制御テーブルの位置を知らせるポインタ*pControlTable、該当ファンクションの存在有無及び位置を識別するためにデバイスドライバ制御テーブルの位置を知らせるポインタ*pDDCB、イベントテーブルの位置を知らせるポインタ*pEventTable、次のレベルを指示するポインタ*pAnchorで構成されるとなおよい。
　デバイスのレベル１初期化は、x1,x2,x3が符号なし整数でありDCB handlerId[x1.x2.x3]として表現されるデバイスハンドラ識別子にレベル１初期化の順序に基づくデバイスにそれぞれ対応するデバイス識別子x1値を固有値として与えることによって行われると好ましい。
　デバイスのレベル２初期化は、レベル１初期化後に遂行され、x1,x2,x3が符号なし整数でありDCB handlerId[x1.x2.x3]で表現されるデバイスハンドラ識別子に、デバイスにそれぞれ対応する論理又は物理グループの個数を参照してアンカーを割り当て、この割り当てられたアンカーのぞれぞれに対するグループ値x2を固有値として与えることによって行われるとよい。
　デバイスのレベル３初期化は、x1,x2,x3が符号なし整数でありDCB handlerId[x1.x2.x3]で表現されるデバイスハンドラ識別子に、チャンネルオープン順序に基づくデバイス及びデバイス内グループが所有するチャンネルのそれぞれに対してチャンネル値x3を与えることによって行われるとなおよい。
　さらにまた、本発明では、アプリケーションが標準化共通フォーマットに基づくＬＯＳ状態情報をデバイス独立アクセス階層に要求する過程と、アプリケーションからの要求を第１デバイスローカルフォーマットに変換し、第１デバイスドライバがＬＯＳ状態情報を前記デバイス独立アクセス階層に提供することを要求する過程と、第１デバイスローカルフォーマットに基づくＬＯＳ状態情報に対する要求に応答する過程と、デバイス独立アクセス階層が標準化共通フォーマットに基づくＬＯＳ状態情報のためにアプリケーションに応答する過程と、を含むことを特徴とするデバイスドライバ制御共通化方法をも提供する。
　この方法でアプリケーションからの要求を変換する過程は、第１デバイスが第２デバイスに変換されて第１デバイスドライバが第２デバイスドライバに変更される場合、要求を第２デバイスローカルフォーマットに変換する過程と、第２デバイスドライバがＬＯＳ状態情報を第２デバイスローカルフォーマットに基づくデバイス独立アクセス階層に提供することを要求する過程と、をさらに含むとよい。
　デバイスドライバに提供される制御コマンドを変更せずに、アプリケーションを、第２アプリケーションに変更することを収容するデバイスドライバに提供する標準化共通フォーマットに基づく制御コマンドに変換する過程をさらに含むとなお好ましい。
　デバイス独立アクセス階層がデバイスドライバ制御ブロックからマテリアルを読み出し、所定ファンクションを用いて第１デバイスドライバ及び第２デバイスドライバにアクセスすることにより、アプリケーションと第１デバイスドライバ及び第２デバイスドライバ間に相互インタフェースを提供する過程をさらに含むとなおよい。
　デバイス独立アクセス階層が標準化データフォーマットに基づく各装置に対応するデバイスハンドラ識別子を用いるようにするとよい。さらにまた、該当デバイスを初期化する間、デバイス独立アクセス階層からアプリケーションにデバイスハンドラ識別子を提供する過程と、アプリケーションが、デバイスハンドラ識別子を貯蔵し、該当デバイスハンドラ識別子を用いて該当デバイスを呼び出す過程と、をさらに含んでもよい。
　デバイス独立アクセス階層が、ドライバハンドラ識別子に従って特定のデバイスドライバが呼び出されたかを決定し、その結果に基づいて特定のドライバハンドラを呼び出す過程をさらに含むようにしてもよい。
　この方法では、デバイス独立アクセス階層が標準化共通フォーマットを遂行するために特定のポインタ及びファンクションポインタを使用するとよい。
　アプリケーションが使用するファンクションブロックのファンクションを呼び出す場合、デバイス独立アクセス階層が、ファンクションテーブルから該当ファンクションの存在を確認し、デバイスドライバがデバイスハンドラ識別子を用いてアプリケーションにアクセスすることを収容するデバイスドライバの初期化を知らせるためにデバイスハンドラ識別子を使用するようにしても好ましい。
　第１デバイスドライバが第２デバイスドライバに変更される場合、デバイスのためのデバイスハンドラＩＤ値を変更しないようにするとなおよい。
　第１デバイスドライバが第２デバイスドライバに変更される場合、デバイス独立アクセス階層の制御下でポインタのアドレスを変更するとなお好ましい。
　本発明によれば、通信システムで上位アプリケーション階層とデバイスドライバ階層との間にＤＩＡ階層を配置するようにしたので、上位アプリケーション階層及び下位デバイスドライバ階層は相互に直接アクセスすることができるようになる。すなわち、ＤＩＡの標準化規則(rule)を通じて、上位アプリケーション階層は下位デバイスドライバ階層にアクセスすることができ、下位デバイスドライバ階層は上位アプリケーション階層にアクセスすることができるようになる。また、ＤＩＡの標準化規則を上位アプリケーション及び下位デバイスドライバに適用すればよいだけなので、その製品開発に要求される時間を短縮するだけでなく開発コストの節減、開発の信頼性を一層向上させる効果がある。
　以下、本発明の望ましい一実施形態を添付の図面を参照して詳細に説明する。図面の説明において、同一の構成要素に対しては可能な限り同一の参照符号及び参照番号を使用して説明する。また、本発明の要旨を不明にする恐れのある公知機能及び構成についてはその詳細な説明を省略する。
　図１は共通のアプリケーションに関して下位の同一機能を有するデバイスＡがデバイスＢに変更される場合を示しており、図２は２つのアプリケーションが同一デバイスドライバを使用する場合を示している。
　図１に示したように、上位アプリケーション２として共通アプリケーション２に関するデバイスＡがデバイスＢに変更された場合、下位デバイスＡドライバ４も下位デバイスＢドライバ６に変更される。すると、デバイスドライバ使用者は自分のデバイスドライバを趣向通りに構成できる。その場合、ＡＰＩはデバイスＡとデバイスＢに対して異なる特性を有するようになる。従って、上位アプリケーション２も変更されたデバイス及びデバイスドライバに合わせて変更されなければならない。このようにデバイスドライバが変更された場合、変更された下位デバイスドライバに関連した全てのＡＰＩが新たに検証されなければならない。言い換えると、変更された下位デバイスドライバに基づいてＡＰＩが正常動作するかどうかを検証する必要がある。さらに、変更された下位デバイスドライバに関連する全ての上位アプリケーションが他に影響を及ぼすかどうかもチェックされるべきである。
　次に、図２に示したように、上位アプリケーションＡ１０、Ｂ１２が共通のデバイスドライバ１４を使用する。デバイスドライバ１４は同一の機能をするデバイスドライバであるが、上位アプリケーションＡ１０、Ｂ１２はデバイスドライバから得たいフォーマットが相互に異なる。例えば、アプリケーションＡ１０ではデバイスドライバ１４から提供される２つのフォーマットＡ-１、Ａ-２を必要とし、アプリケーションＢ１２ではデバイスドライバ１４から提供される３つのフォーマットＢ-１、Ｂ-２、Ｂ-３を必要とする場合などである。これは、アプリケーション相互間におけるフォーマットの取り決め(agreement)が一致していないために発生する。従って、デバイスドライバ１４は上位階層アプリケーションＡ１０、Ｂ１２の変更要求のたびに新たにフォーマットを変更しなければならず、また、ＡＰＩも変更あるいは追加しなければならない。上位アプリケーションの要求に対して下位デバイスドライバが希望のフォーマットを支援できない状況になると、上位アプリケーション全体に影響を及ぼすコードや構造を修正しなければならないといった問題を引き起こす。この場合、上位アプリケーションはもちろん既存の検証が終わったデバイスドライバもさらに検証が必要となる。
　図３は、本発明の一実施形態によるデバイスドライバ制御共通化のための概念構成図である。図３に示したように、本発明の一実施形態では通信システムでＤＩＡ階層２２を上位アプリケーション２０とデバイスドライバ２４、２６との間に位置させる。上位アプリケーション２０はＤＩＡ階層２２の標準化規則を通じてデバイスドライバ２４、２６にアクセスする。同様にデバイスドライバ２４、２６はＤＩＡ階層２２の標準化規則を通じて上位アプリケーション２０にアクセスする。図４を参照してより詳細に説明すれば、次の通りである。
　図４は、本発明の一実施形態によるデバイスドライバ制御共通化のためのアクセス概念図である。図４に示したように、上位アプリケーション２０が標準化共通フォーマットコマンドに基づく、例えば、ＬＯＳ(loss of state)状態情報をＤＩＡ階層２２に要求すると、ＤＩＡ階層２２はこの要求をデバイスＡローカルフォーマットに変換してデバイスＡドライバ２４にＬＯＳ状態情報を要求する。これに応じて、デバイスＡドライバ２４はデバイスＡローカルフォーマットのＬＯＳ状態情報をＤＩＡ階層に提供する。ＤＩＡ階層２２はデバイスＡローカルフォーマットのＬＯＳ状態情報を標準化共通フォーマットに変換して上位アプリケーション２０に提供する。一方、デバイスＡがデバイスＢに変更されると、デバイスＡドライバ２４もデバイスＢドライバ２６に変更される。上位アプリケーション２０はデバイス変更にかかわらず標準化共通フォーマットコマンドに基づく、例えば、ＬＯＳ状態情報をＤＩＡ階層２２に要求する。ＤＩＡ階層２２はこの要求をデバイスＢローカルフォーマットに変換してデバイスＢドライバ２６にＬＯＳ状態情報を要求する。これに応じて、デバイスＢドライバ２６はデバイスＢローカルフォーマットのＬＯＳ状態情報をＤＩＡ階層に提供する。ＤＩＡ階層２２はデバイスＢローカルフォーマットのＬＯＳ状態情報を標準化共通フォーマットに変換して上位アプリケーション２０に提供する。このように、上位アプリケーション２０と下位デバイスドライバ２４、２６との間に位置するＤＩＡ階層２２が標準化規則に基づいて相互インタフェースを提供する。これによりアプリケーション変更やデバイス変更による上位アプリケーション又はデバイスドライバの検証が不要になる。
　上位アプリケーション２０と下位デバイスドライバ２４、２６との間に標準化規則に基づく相互インタフェースを提供するために、本発明の一実施形態によるＤＩＡ階層２２はデバイスドライバ制御ブロック(Device Driver Control Block:ＤＤＣＢ)からマテリアル(material)を読み出し標準化規則により定義された機能を用いて下位デバイスドライバにアクセスする。ＤＤＣＢはデバイスドライバをそれぞれ共通化するために定義され、該当機能の存在有無及び位置に関する情報を提供するブロックである。
　本発明の一実施形態では、ＩＴＵ/ＲＦＣ(International Telecommunications Union/Request ForComments)などの国際機構で既定義され及び標準化されたファンクションブロック(function block)の全てのファンクションのうち該当デバイスドライバに使用可能なファンクションのみがファンクションテーブルに定義される。また、本発明の一実施形態では、ＩＴＵ(International Telecommunications Union)、ＩＥＴＦ(Internet Engineering Task Force)、ＥＴＳＩ(European Telecommunications Standardization Institute)、ＡＴＭフォーラム(Asynchronous Transfer Mode forum)、ＡＤＳＬフォーラム(Asymmetrical Digital Subscriber Line forum)などの国際標準化機構により制定され標準化文書に定義された全てのファンクションブロックを使用しうる。さらに、本発明の一実施形態では、国際標準化機構により定義された全てのファンクションブロックのうち該当デバイスドライバに使用可能なファンクションのみがファンクションテーブルに再定義される。本発明の一実施形態で使用されるファンクションテーブルは標準化されたコマンド制御テーブル(command control table)としてメモリ領域に貯蔵される。　
　本発明の一実施形態では、ＤＩＡ階層２２は上位アプリケーションの開発者がデバイスを容易に制御する標準化データフォーマットに基づくデバイスハンドラ識別子（identifier：ＩＤ）を使用する。デバイスハンドラＩＤは本発明の一実施形態に従う標準化データフォーマットを持つデバイスのそれぞれに対する固有識別子である。ＤＩＡ階層２２はデバイスハンドラＩＤを該当デバイスの初期化中に上位アプリケーション２０に提供する。上位アプリケーション２０は該当デバイスのデバイスハンドラＩＤを貯蔵しておき、該当デバイスの呼び出しが必要な場合にデバイスハンドラＩＤを用いて該当デバイスを呼び出す。これに応じて、ＤＩＡ階層２２はデバイスハンドラＩＤに基づきどのデバイスドライバを呼び出すかを決定し、この決定に従ってデバイスドライバを呼び出す。　　
　ＤＩＡ階層２２によって上位アプリケーション２０に提供される標準化固有識別子であるデバイスハンドラＩＤ及び標準化コマンド制御テーブルについて、図５〜図８を参照してより詳細に説明する。また、本発明の一実施形態で言及している該当デバイスイベントテーブル(device event table)、該当デバイスモジュールのプロファイル(profile)についても図５〜図８を参照してより詳細に説明する。
　図５は、アプリケーション使用者がデバイス初期化のためＤＩＡ階層２２のＡＰＩDia_InitDeviceを呼び出した後におけるＤＣＢ(Device Control Block)の接続構造を示している。図６はレベル１初期化段階での最終ＤＣＢを示している。図７は該当するレベル２の４つのポートを備えるＨＤＬＣ(High-level Data Link Control)デバイスが初期化された場合のＤＣＢ接続構造を示している。図８はチャンネルが初期化された場合のＤＣＢ接続構造を示している。
　まず、デバイスハンドラＩＤを詳細に説明すれば、下記の通りである。
　ＤＩＡ階層２２により生成される該当デバイスのデバイスハンドラＩＤは、例えば、図５に示したようにDCB handlerId[1.0.0]３０のような一例で表現される。このデバイスハンドラＩＤはレベル１、レベル２、チャンネルに関する３つの符号なし整数(unsigned integer)の構造で構成され、固有値をシステム内に有する。デバイスハンドラＩＤは符号なし整数x1.x2.x3で構成されている。デバイスハンドラＩＤはDCB handlerId[x1.x2.x3]で表現され、x1はデバイスＩＤを意味するレベル１の値で、x2は該当デバイスが持っている論理あるいは物理グループ番号を意味するレベル２の値で、x3は該当デバイスあるいはグループが持っているチャンネル番号を意味するチャンネルの値である。x1,x2,x3の値が“０”であれば、該当レベル又はチャンネルが存在しないことを意味する。デバイスが初期化されると、図６〜図８に示す一例のように、整数値ｘが“１”から順次に増加する。ここでレベル１の値、すなわちx1＝“０”のハンドラは存在しない。これは、レベル１の値が初期化されていないことを意味する。
　図５に示したようにレベル１の値が初期化されると、本発明の一実施形態による標準化規則に基づきデバイスにより呼び出されるエレメントを含むＤＣＢ３２が動的に割り当てられる。このエレメントはＤＩＡ階層２２で標準化規則を実行するための多様なポインタ(pointer)及びファンクションポインタで構成されている。レベル１の値が初期化された場合、ＤＣＢ３２のエレメントは、*pHandler, *fpIntiDevice, *fpOpenChannel, *fpCloseChannel, *fpRead, *fpWrite, *fpReset, *pControlTable, *pDDCB, *pEventTable, *pAnchorを含む。*pHandlerはデバイス初期化時に与えられる初期化プロファイルの位置を知らせるポインタで、*fpIntiDeviceはデバイス初期化時に使用されるファンクションのあるファンクションポインタである。*fpOpenChannelはチャンネルをオープン(open)するときに使用されるファンクションのあるファンクションポインタで、*fpCloseChannelはチャンネルをクローズ(close)するときに使用されるファンクションのあるファンクションポインタである。*fpReadはオープンチャンネルのデータを読み出すときに使用されるファンクションポインタで、*fpWriteはオープンチャンネルのデータを書き込むときに使用されるファンクションポインタである。*fpResetはデバイスリセット時に使用されるファンクションポインタである。*pControlTableはコマンド制御テーブル３４の位置を知らせるポインタである。*pDDCBはデバイスドライバ制御テーブル(device driver control table)３６の位置を知らせるポインタである。*pEventTableはイベントテーブル３８の位置を知らせるポインタである。*pAnchorは次のレベルを指示するポインタである。
　全てのデバイスが初期化された後、ＤＩＡ階層２２は生成したデバイスハンドラＩＤを上位アプリケーション２０に提供する。上位アプリケーション２０は該当デバイスを初期化し、与えられたデバイスハンドラＩＤのみを貯蔵する。デバイスハンドラが呼び出されると、ＤＩＡ階層２２はこれを受信してどのデバイスのドライバを呼び出すかどうかを決定し、この決定に従ってデバイスドライバを呼び出すようになる。
　次に、ファンクションテーブルの標準化コマンド制御テーブルについて説明する。
　標準化コマンド制御テーブルは該当機能群別にＩＴＵ、ＩＥＴＦ、ＥＴＳＩ、ＡＴＭフォーラム、ＡＤＳＬフォーラムなどの国際標準化機構により制定された標準化文書の該当ファンクションブロックに関連するエレメント及び該当ブロックを使用する。該当分野に追加要求があるときはいつでも標準化コマンド制御テーブルに追加が可能である。本発明の発明者は一例として超高速通信に関連する情報についてテーブルを作成した。この作成したテーブルは該当メモリ領域に貯蔵される。さらに、必要であれば、他の機能を任意に追加して直ちに反映できることに留意する。　
　図５に示したように、標準化コマンド制御テーブル３４は該当ＤＣＢの*pControlTableポインタにより指示されるメモリ領域に位置している。標準化コマンド制御テーブル３４のコマンドＩＤ(commandID)は標準化されて固有値として定義されている。コマンドＩＤには該当コマンドファンクションのファンクションポインタ*fpCommandFnがマッピングされている。
　下記の表１は本発明の一実施形態による標準化コマンド制御テーブル３４の構造体(structure)である。
Figure 2004070964
　表１に示す‘DIA_COMMAND_ID_SDH_E'のような標準化コマンド‘typedef enum(enumulate)'が、‘DIA_COMMAND_ID_PDH_E'、‘DIA_COMMAND_ID_ATM_E'など各分野別に存在する。様々なコマンドファンクションを標準化コマンド制御テーブル３４に任意に追加できる。この標準化コマンド制御テーブル(Control Table)３４を通じて上位アプリケーション使用者はいつでも該当デバイスドライバを呼び出し可能である。デバイスドライバが変更されても該当標準化コマンドは標準化コマンド制御テーブル３４に同一に残る。実際の該当デバイスドライバが該当コマンドを実行する場合、ファンクションポインタのみが変更される。ファンクションポインタはデバイス初期化時にデバイスドライバによりＤＩＡ階層２２に提供される。コマンドはアプリケーション使用者によりＡＰＩ‘Dia_Control'を通じて呼び出される。実際に、上位アプリケーション使用者がＡＰＩ‘Dia_Control'を通じて特定制御コマンドを呼び出す場合、ＤＩＡ階層２２下にあるデバイスドライバのみが変更されるようになり、上位アプリケーション２０の使用者は同一コマンドを同一フォームで呼び出す。
　次に、図５を参照して本発明の一実施形態によるデバイスドライバ制御テーブル３６について説明する。図５において、デバイスドライバ制御テーブル３６は*pDDCBポインタにより指示されるテーブルであり、InitLevel1、InitLevel2、OpenChannel、CloseChannel、制御テーブル、イベントテーブルなどの位置を指示するファンクションポインタ*fp、すなわち、*fpInitLevel1、*fpInitLevel2、*fpOpenChannel、*fpCloseChannel、*fpControlTable(図示せず)、*fpEventTable(図示せず)などを含む。また、デバイスに固有な初期化ファンクション数、ポート数及びチャンネル数を示す情報(図示せず)を含んでいる。デバイスドライバ制御テーブル３６は、デバイスドライバそれぞれを共通化するために定義され、該当ファンクションの存在有無及び位置に関する情報を知らせるためのＤＤＣＢに対応させられる。デバイスドライバ制御テーブル３６は、*fpInitLevel1、*fpInitLevel2、*fpOpenChannel、*fpCloseChannel、*fpControlTable(図示せず)、*fpEventTable(図示せず)などを含む。また、デバイスに固有な初期化ファンクション数、ポート数、及びチャンネル数を示す情報(図示せず)を含んでいる。デバイスが初期化される場合、ＤＤＣＢとなるデバイスドライバ制御 テーブル３６は*pDDCBにより検出される。*fpInitLevel1、*fpInitLevel2、*fpOpenChannel、*fpCloseChannel、*fpControlTable(図示せず)、*fpEventTable(図示せず)などのマテリアルは割り当てられたＤＣＢ３２に情報として書き込まれる。
　次に、本発明の一実施形態によるイベントテーブルについて説明する。
　図５に示したイベントテーブル３８は該当ＤＣＢの*pEventTableポインタにより指示される位置にある構造体として必要時にのみ生成される。イベントテーブルを使用しないときにはヌル(Null)として指示される。イベントテーブル３８はイベントＩＤ“EventId”とイベントリスト構造体ポインタ“*pEventList”を含んでいる。それぞれのイベントリストは図９に示したように、リンクリスト(linked list)構造となっている。これに応じて、一つのイベントを数個所に通知(notification)することができ、及び、コールバックファンクション(call-back function)“Call-back Fn”を呼び出すことができる。初期イベントテーブル３８には“EventId”のみが存在し、“*pEventList”は最初に“Nullとして指示される。上位アプリケーション２０の使用者が該当イベントを使用する場合、その使用者はＡＰＩ“Dia_Register”を用いて、“*pEventList”にイベントリスト構造体のポインタを接続することにより、そのイベントを登録使用することができる。
　下記の表２は、本発明の一実施形態によるイベントテーブル３８の構造体(structure)の一例を示す構成図である。
Figure 2004070964
　次に、本発明の一実施形態によるデバイスモジュールのプロファイルについて説明する。
　図５に示した該当ＤＣＢ３２のファンクションポインタ*fpInitDeviceが実行される場合に必要な入力引数(input argument)は構造体ポインタ(structure pointer)のフォーム(form)を備えることが可能である。特別な場合、該当デバイスの構造体が定義されるが、通常の場合にはレベル１の値の初期化時における基本アドレス(base address)、レベル２に対応するグループＩＤ、チャンネル初期化時におけるチャンネルＩＤを含む共通構造体が使用される。
　下記表３は本発明の一実施形態によるデバイスモジュールのプロファイル共通構造体の一例を示す構成図である。
Figure 2004070964
　以下、本発明の一実施形態による動作を詳細に説明する。
　上位アプリケーション２０が使用されるファンクションブロックのファンクションを呼び出す場合、ＤＩＡ階層２２は該当ファンクションテーブルの存在有無及び位置を指示する情報を備えるＤＤＣＢ(Device Driver Control Block)を用いて該当デバイスドライバのファンクションテーブルから該当ファンクションの存在有無を識別する。該当ファンクションテーブルが存在すれば該当ファンクションを呼び出す。ファンクションを呼び出すために、ＤＩＡ階層２２は該当デバイスの初期化時にデバイスハンドラＩＤを上位アプリケーション２０に知らせ、上位アプリケーションはそのデバイスハンドラＩＤを使用して下位デバイスドライバにアクセスするようになる。
　まず、本発明の一実施形態によるデバイス初期化時の動作を説明すれば、下記の通りである。
　上位アプリケーション２０の使用者がデバイス初期化のためにＡＰＩDia_InitDeviceを呼び出すと、ＤＩＡ階層２２は該当ファンクションテーブルの位置を指示する情報を備えるＤＤＣＢ(Device Driver Control Block)を通じて上位アプリケーション２０により使用されるファンクションブロック(例えば、制御テーブル、イベントテーブルなど)のそれぞれに対するポインタを含んでいるＤＣＢ３２を動的に割り当てる。
　ＡＰＩDia_InitDeviceが呼び出された後、ＤＣＢの接続を図５〜図８を参照して詳細に説明する。また、この基本的な流れに応じた、データベース構造の追加も述べる。
　 （１）レベル１初期化
　初期化されるデバイスはレベル１又はレベル２、チャンネルを有する。レベル１が初期化される場合、該当デバイスの最上位ブロックになるＤＣＢ３２が動的に割り当てられ、その後、該当デバイスのレベル２がレベル１に関するＤＣＢ３２のアンカー(anchor)(アンカーポインタ*pAnchorにより指示される)を通じて参照されるようにする。各カードに使用されるデバイスの個数は既知の値なので、グロバール変数(global variable)として図５に示したデバイスＩＤ(device Id)及びＤＣＢ３２を示すポインタ*pDCBを有する最上位データベース４０が定義されたと仮定する。
　レベル１の初期化時のフォームは図５に示した通りである。そして、図６にレベル１初期化段階での最終ＤＣＢを示す。図５のようなＤＣＢ３２を生成するたびに、ＤＩＡ階層２２は、図６に示すように、該当ＤＣＢごとに固有なデバイスハンドラＩＤ値DCB　HandlerId[x1.x2.x3]を上位アプリケーション２０にリターンする。すなわち、ＤＩＡ階層２２ではデバイスのレベル１の初期化順序にしたがってx1値を“１”から順次に増加させつつデバイスハンドラＩＤ値DCB HandlerId[x1.x2.x3]を与える。図６の一例を参照すれば、ＨＤＬＣ(High level Data Link Control)のデバイスハンドラＩＤ値はＤＣＢ HandlerId[1.0.0]にリターンされ、ＬＡＮ(Local Area Network)のデバイスハンドラＩＤ値はＤＣＢHandlerId[2.0.0]にリターンされ、ＳＥＲＩＡＬのデバイスハンドラＩＤ値はＤＣＢ HandlerId[3.0.0]にリターンされ、ＵＴＯＰＩＡ(Universal Test & Operations Physical layer Interface for ATM)のデバイスハンドラＩＤ値はＤＣＢ HandlerId[4.0.0]にリターンされる。
　上位アプリケーション２０はリターンされるデバイスハンドラＩＤ値ＤＣＢ HandlerId[x1.x2.x3]を管理しなければならない。上位アプリケーション２０の使用者はリターンされるデバイスハンドラＩＤ値DCB HandlerId[x1.x2.x3]を用いて該当ファンクションのデバイスファンクション呼(device function call)が可能になる。また、デバイス初期化順序にしたがってデバイスに該当するデバイスハンドラＩＤが与えられるので、上位アプリケーション２０の使用者はリターンされるデバイスハンドラＩＤがどのデバイスに該当するかどうか識別すべきである。例えば、３つのＨＤＬＣ１、ＨＤＬＣ２、ＨＤＬＣ３のデバイスがある場合、ＨＤＬＣ３が先に初期化されると、ＨＤＬＣ３デバイスのx1値が“１”となる。
　(２) レベル２初期化
　ＤＩＡ階層２２はレベル１初期化後にレベル２の初期化を実行する。このとき、使用される情報はＤＤＣＢ(デバイスに固有な初期化ファンクション(initialization function)、及び、ポート数やチャンネル数に関する情報を有する)に関するレベル２での許容個数(例えば、ポート数)である。例えば、該当デバイスのポート数を参照してレベル２の初期化を実行できるようにアンカーが割り当てられる。そして、ＤＩＡ階層２２はレベル２に必要なＤＣＢブロックを参照可能なようにレベル１のアンカーに生成されたＤＣＢ３２のアドレスを指定する。
　図７は、レベル２に該当する４つのポートを備えるＨＤＬＣデバイスが初期化されたときの図である。同図を参照すれば、４つのポートにそれぞれ対応して割り当てられるアンカーAnchor1、Anchor2、Anchor3、Anchor4はデバイスハンドラＩＤ値がそれぞれDCB HandlerId[1.1.0]、DCB HandlerId[1.2.0]、DCB HandlerId[1.3.0]、DCB HandlerId[1.4.0]にリターンされる。例えば、４つのポートがポート０、ポート１、ポート２、ポート３からなっていれば、ポート０がアンカーAnchor1に、ポート１がアンカーAnchor2に、ポート２がアンカーAnchor3に、ポート３がアンカーAnchor4に割り当てられ、デバイスハンドラＩＤ値がそれぞれDCB HandlerId[1.1.0]、DCB　HandlerId[1.2.0]、DCB HandlerId[1.3.0]、DCB　HandlerId[1.4.0]として与えられる。
　(３) チャンネル初期化
　チャンネルに関するＤＣＢは必要なとき時にのみ生成されるようにする。レベル２にかかわりなくチャンネルのみある場合は図８に示すようにアンカーAnchor0にＤＣＢを接続する。
　図８に示したチャンネル初期化のＤＣＢ接続構造は図７と類似にチャンネル数と同一のアンカーが割り当てられ、このアンカーがＤＣＢに接続される。このとき、デバイスハンドラＩＤ値がリターンされる。アンカーAnchor1に対応するポートにチャンネル１、チャンネル２、チャンネル３、チャンネル４の４つのチャンネルが結びつけられる。そのうちチャンネル３をまずオープンすれば、初期化順序にしたがってこのオープンされたチャンネル３に対しDCB HandlerId[2.1.1]値がリターンされる。上位アプリケーション２０の使用者は上記（１）で言及したようにデバイスの初期化順序にしたがってデバイスに該当するデバイスハンドラＩＤが与えられるので、該当チャンネルとそれに対応するデバイスハンドラＩＤ値のマッピングを管理すべきである。
　デバイスを初期化した後、上位アプリケーション２０は標準化された識別子であるデバイスハンドラＩＤ値DCB HandlerId[x1.x2.x3]を用いてファンクションブロックのファンクションを呼び出す。それに応じて、ＤＩＡ階層２２では該当ファンクションテーブルの位置を指示するＤＤＣＢを用いて該当デバイスドライバのファンクションテーブルから該当ファンクションの存在有無を識別する。該当ファンクションが存在すれば、このファンクションが呼び出される。
　図１０は、本発明の一実施形態によるデバイスドライバが変更(置換)された場合を説明するための図である。
　同図を参照すれば、本発明の一実施形態によるＤＩＡ階層２２によりデバイスドライバＡがデバイスドライバＢに変更されても、デバイスＨＤＬＣに対するデバイスハンドラＩＤ値DCB handlerId[1.0.0]は決して変更されない。変更されるのは、デバイス初期化時にＤＩＡ階層２２の制御下で下位デバイスドライバ及びＤＣＢ３２のポインタ(アドレス)だけが新たなデバイスを指示する場合である。これに応じて、上位アプリケーション２０は下位デバイスドライバＡが下位デバイスドライバＢに変更されても決して変更されることなく同一機能を実行することができる。
　図１１〜図１４は上位アプリケーション又は下位デバイスが変更される場合における従来技術と本発明の一実施形態によ動作の比較を示した図である。
　図１１及び図１３は、上位アプリケーション(プログラム)が変更された場合を一例として示したものである。図１１は従来技術による上位アプリケーション(プログラム)が変更された場合を、図１３は本発明の一実施形態による上位アプリケーション(プログラム)が変更された場合をそれぞれ示す。
　まず、図１１を参照すれば、従来技術において上位アプリケーションＡが上位アプリケーションＢに変更されると、上位アプリケーションのみが変更されるだけではなく、これに該当する下位デバイスドライバも同様に変更されなければならない。その理由は、上位アプリケーションＡ、Ｂに関する構造及び使用するＡＰＩが異なるので、下位デバイスドライバは要求されるＡＰＩのフォームを変更して提供しなければならないからである。したがって、追加、削除、修正の動作を従来の下位デバイスドライバに適用しなければならず、それによりこの変更部分に対して検証作業を新たに実行することになる。もちろん、これを利用する上位アプリケーションＢに対する検証作業も共に行われるべきである。
　図１３に示すように本発明の一実施形態では、図１１に基づいて説明した従来技術の欠点を補完するために、上位アプリケーション階層と下位デバイスドライバ階層との間にＤＩＡ階層２２を位置させる。上位アプリケーション階層と下位デバイスドライバ階層との間にＤＩＡ階層２２を位置させると、上位アプリケーションＡがＢに変更されても、上位アプリケーションＡ、ＢはＤＩＡ標準化規則に従う同一の制御コマンドControl A、Control B、Control Cを使用することができる。上位アプリケーションはデバイスドライバを直接制御するのではなく、デバイスに含まれ、ＤＩＡ階層２２が使用する制御コマンドを通じて間接的にデバイスドライバを制御するようになる。図１３を一例として説明すれば、上位アプリケーションＡ、Ｂが使用する標準化共通フォーマットに基づく制御コマンドControl A、Control B、Control CはＤＩＡ階層２２によりデバイス１で使用する制御コマンドControl A-1、Control B-1、Control C-1に個別に変換される。この変換された制御コマンドControl A-1、Control B-1、Control C-1はデバイス１ドライバに提供される。したがって、上位アプリケーションは、その変更があっても特に下位デバイスドライバに左右されない。
　図１２及び図１４は、上位アプリケーションは変更されずに、同一の機能を有する下位デバイスが変更され、それぞれのデバイスドライバが多数個存在する場合を示している。図１２は従来技術における下位デバイスが変更された場合を、図１４は本発明の一実施形態による下位デバイスが変更された場合をそれぞれ示す。
　まず、図１２を参照すれば、従来技術では上位アプリケーションはそのままで、下位デバイスドライバが変更されると、下位デバイスドライバのＡＰＩが変更される。この下位デバイスドライバのＡＰＩを使用するために、上位アプリケーションが変更される。すなわち、上位アプリケーションの一部や他の部分が同様に追加、削除、あるいは修正されなければならない。また、変更された下位デバイスドライバだけでなく上位アプリケーションも検証されなければならない。
　しかし、図１４に示すように本発明の一実施形態によってＤＩＡ階層２２を上位アプリケーション階層と下位デバイスドライバ階層との間に位置させるようにすれば、上位アプリケーション階層を変更することなく、下位デバイスドライバのみをＤＩＡ階層２２に基づいて変更することで、全ての作業が終わる。従って、下位デバイスドライバの検証のみが必要とされる。図１４を一例として説明すれば、上位アプリケーションＡが使用する標準化共通フォーマットに基づく制御コマンドControl A、Control B、Control CはＤＩＡ階層２２によりデバイス１が持っている制御コマンドControl A-1、Control B-1、Control C-1に個別に変換される。この変換された制御コマンドControl A-1、Control B-1、Control C-1がデバイス１ドライバに提供される。ここで、下位デバイスドライバがデバイス１ドライバからデバイス２ドライバに変更されると、下位デバイス２ドライバがデバイス２で使用される制御コマンドがControl A-2、Control B-2、Control C-2であることを上位階層のＤＩＡ階層２２に知らせる。その後、ＤＩＡ階層２２は上位アプリケーションＡが使用する標準化共通フォーマットに基づく制御コマンドControl A、Control B、Control Cをデバイス２が持っている制御コマンドControl A-2、Control B-2、Control C-2に個別に変換する。
　上述した本発明の説明では具体的一実施形態に基づいて説明したが、多様な変形が本発明の特許請求の範囲を外れずに実現可能である。したがって、本発明の範囲は上述した一実施形態により定められるのではなく、特許請求の範囲とこれに均等なものにより定めなければならない。
同一のアプリケーションで下位の同一機能をするデバイスがＡからＢに変更される場合を示す図。 同一のデバイスドライバを２つのアプリケーションが使用する場合を示す図。 本発明の一実施形態によるデバイスドライバ制御共通化のための概念図。 本発明の一実施形態によるデバイスドライバ制御共通化のためのアクセス概念図。 デバイスの初期化のためのＡＰＩDia_InitDevicが呼び出された後のＤＣＢの接続構造を説明するための図。 レベル１の初期化段階で最終ＤＣＢを示す図。 レベル２に該当するポートが４つであるＨＤＬＣデバイスが初期化されたときのＤＣＢの接続構造を説明するための図。 チャンネルが初期化されたときのＤＣＢの接続構造を説明するための図。 イベントテーブルの構造を説明するための図。 本発明の一実施形態によるデバイスドライバが変更された場合を示す図。 従来技術による上位アプリケーション(プログラム)が変更された場合を説明するための図。 従来技術による下位デバイスが変更された場合を説明するための図。 本発明の一実施形態による上位アプリケーション(プログラム)が変更された場合を説明するための図。 本発明の一実施形態による下位デバイスが変更された場合を説明するための図。
符号の説明
２０，２１　上位アプリケーション
２２　ＤＩＡ階層
２４，２６，５０，５２　下位デバイスドライバ
３０　DCB handlerId[1.0.0]
３２　ＤＣＢ
３４　コマンド制御テーブル
３６　デバイスドライバ制御テーブル
３８　イベントテーブル
４０　最上位データベース

Claims (22)

  1. 　デバイスドライバ制御共通化方法において、
    　デバイス独立アクセス階層をアプリケーション階層とデバイスドライバ階層との間に位置させ、前記アプリケーション階層及びデバイスドライバ階層に前記デバイス独立アクセス階層の標準化規則を適用させる第１過程と、
    　前記デバイス独立アクセス階層の標準化規則を通じて前記アプリケーション階層及びデバイスドライバ階層が前記デバイスドライバ階層及びアプリケーション階層に相互にアクセスする第２過程と、からなることを特徴とするデバイスドライバ制御共通化方法。
  2. 　前記第２過程は、
    　前記アプリケーション階層が該当デバイスドライバに対する標準化共通フォーマットに基づく制御コマンドを前記デバイス独立アクセス階層に伝送し、及び、前記デバイス独立アクセス階層が、前記制御コマンドをローカルフォーマットに基づく他の制御コマンドに変換し、該変換した制御コマンドを前記デバイスドライバに伝達する段階と、
    　前記デバイスドライバがローカルフォーマットに基づく変換した制御コマンドの応答を前記デバイス独立アクセス階層に伝送し、及び、前記デバイス独立アクセス階層が、前記デバイスドライバからの応答を標準化共通フォーマットに基づく応答に変換し、該標準化共通フォーマットに基づく応答を前記アプリケーション階層に伝達する段階と、からなる請求項１記載のデバイスドライバ制御共通化方法。
  3. 　デバイスドライバ制御共通化方法において、
    　デバイス独立アクセス階層をアプリケーション階層とデバイスドライバ階層との間に位置させる過程と、
    　ファンクションブロックのファンクションのうち、該当デバイスドライバで使用可能なファンクションをファンクションテーブルに定義する過程と、
    　デバイスが初期化される場合、前記デバイス独立アクセス階層が、前記デバイスに対する標準化データフォーマットに基づくデバイスハンドラ識別子を生成し、該生成したデバイスハンドラ識別子を上位のアプリケーション階層に伝達する過程と、
    　該上位アプリケーション階層が前記デバイスハンドラ識別子を用いて所定デバイスを呼び出し、前記デバイス独立アクセス階層が前記デバイスハンドラ識別子を用いてファンクションテーブルから該当デバイスドライバのファンクションを識別する過程と、からなることを特徴とするデバイスドライバ制御共通化方法。
  4. 　前記デバイスハンドラ識別子はDCB handlerId[x1.x2.x3]で表現され、x1,x2,x3が符号なし整数であり、x1がデバイス識別子を意味するレベル１の値で、x2が該当デバイスの論理又は物理グループ番号を意味するレベル２の値で、x3が該当デバイス又はグループのチャンネル番号を意味するチャンネルの値である請求項３記載のデバイスドライバ制御共通化方法。
  5. 　前記x1,x2,x3の値が“０”であれば、該当レベル又はチャンネルが存在しないことを意味し、デバイスが初期化される場合にx1の値が“１”から順次に増加する請求項４記載のデバイスドライバ制御共通化方法。
  6. 　デバイスドライバ制御共通化方法において、
    　デバイス独立アクセス階層をアプリケーション階層とデバイスドライバ階層との間に位置させる過程と、
    　前記アプリケーション階層によってデバイス初期化が制御される場合、前記デバイス独立アクセス階層が、前記デバイスのレベル１初期化、レベル２初期化、チャンネル初期化を実行し、前記デバイスに対する標準化データフォーマットに基づくデバイスハンドラ識別子を生成する過程と、
    　前記デバイス独立アクセス階層が前記デバイスハンドラ識別子に対応する標準化規則を実行するためのエレメントを含むデバイス制御ブロックを動的に割り当てる過程と、
    　前記デバイス独立アクセス階層が前記アプリケーション階層に前記デバイスハンドラ識別子を提供する過程と、
    　前記アプリケーション階層が前記デバイスハンドラ識別子を用いて前記デバイス独立アクセス階層を通じて所定デバイスを呼び出す過程と、からなることを特徴とするデバイスドライバ制御共通化方法。　
  7. 　前記デバイス制御ブロックのエレメントは、標準化固有値を有しコマンドファンクションポインタがマッピングされているコマンド識別子を含むコマンド制御テーブルの位置を知らせるポインタ*pControlTable、該当ファンクションの存在有無及び位置を識別するためにデバイスドライバ制御テーブルの位置を知らせるポインタ*pDDCB、次のレベルを指示するポインタ*pAnchorを少なくとも含む請求項６記載のデバイスドライバ制御共通化方法。
  8. 　前記デバイス制御ブロックのエレメントは、デバイス初期化時に与えられる初期化プロファイルの位置を知らせるポインタ*pHandler、デバイスの初期化時に使用されるファンクションのあるファンクションポインタ*fpIntiDevice、チャンネルをオープンするときに使用されるファンクションのあるファンクションポインタ*fpOpenChannel、チャンネルをクローズするときに使用されるファンクションのあるファンクションポインタ*fpCloseChannel、オープンチャンネルのデータを読み出すときに使用されるファンクションポインタ*fpRead、オープンチャンネルのデータを書き込むときに使用されるファンクションポインタ*fpWrite、デバイスのリセット時のファンクションポインタ*fpReset、標準化固有値を有しコマンドファンクションポインタがマッピングされているコマンド識別子を含むコマンド制御テーブルの位置を知らせるポインタ*pControlTable、該当ファンクションの存在有無及び位置を識別するためにデバイスドライバ制御テーブルの位置を知らせるポインタ*pDDCB、イベントテーブルの位置を知らせるポインタ*pEventTable、次のレベルを指示するポインタ*pAnchorで構成される請求項６記載のデバイスドライバ制御共通化方法。
  9. 　前記デバイスのレベル１初期化は、x1,x2,x3が符号なし整数でありDCB handlerId[x1.x2.x3]として表現されるデバイスハンドラ識別子にレベル１初期化の順序に基づくデバイスにそれぞれ対応するデバイス識別子x1値を固有値として与えることによって行われる請求項６記載のデバイスドライバ制御共通化方法。
  10. 　前記デバイスのレベル２初期化は、前記レベル１初期化後に遂行され、x1,x2,x3が符号なし整数でありDCB handlerId[x1.x2.x3]で表現されるデバイスハンドラ識別子に、デバイスにそれぞれ対応する論理又は物理グループの個数を参照してアンカーを割り当て、この割り当てられたアンカーのぞれぞれに対するグループ値x2を固有値として与えることによって行われる請求項９記載のドライバ制御共通化方法。
  11. 　前記デバイスのレベル３初期化は、x1,x2,x3が符号なし整数でありDCB handlerId[x1.x2.x3]で表現されるデバイスハンドラ識別子に、チャンネルオープン順序に基づく前記デバイス及び前記デバイス内グループが所有するチャンネルのそれぞれに対してチャンネル値x3を与えることによって行われる請求項１０記載のデバイスドライバ制御共通化方法。
  12. 　アプリケーションが標準化共通フォーマットに基づくＬＯＳ状態情報をデバイス独立アクセス階層に要求する過程と、
    　前記アプリケーションからの要求を第１デバイスローカルフォーマットに変換し、第１デバイスドライバがＬＯＳ状態情報を前記デバイス独立アクセス階層に提供することを要求する過程と、
    　第１デバイスローカルフォーマットに基づくＬＯＳ状態情報に対する要求に応答する過程と、
    　前記デバイス独立アクセス階層が標準化共通フォーマットに基づくＬＯＳ状態情報のために前記アプリケーションに応答する過程と、を含むことを特徴とするデバイスドライバ制御共通化方法。
  13. 　前記アプリケーションからの要求を変換する過程は、
    　第１デバイスが第２デバイスに変換されて前記第１デバイスドライバが第２デバイスドライバに変更される場合、前記要求を第２デバイスローカルフォーマットに変換する過程と、
    　第２デバイスドライバがＬＯＳ状態情報を前記第２デバイスローカルフォーマットに基づく前記デバイス独立アクセス階層に提供することを要求する過程と、をさらに含む請求項１２記載のデバイスドライバ制御共通化方法。
  14. 　デバイスドライバに提供される制御コマンドを変更せずに、前記アプリケーションを、第２アプリケーションに変更することを収容するデバイスドライバに提供する標準化共通フォーマットに基づく制御コマンドに変換する過程をさらに含む請求項１３記載のデバイスドライバ制御共通化方法。
  15. 　デバイス独立アクセス階層がデバイスドライバ制御ブロックからマテリアルを読み出し、所定ファンクションを用いて第１デバイスドライバ及び第２デバイスドライバにアクセスすることにより、前記アプリケーションと前記第１デバイスドライバ及び第２デバイスドライバ間に相互インタフェースを提供する過程をさらに含む請求項１４記載のデバイスドライバ制御共通化方法。
  16. 　前記デバイス独立アクセス階層が標準化データフォーマットに基づく各装置に対応するデバイスハンドラ識別子を用いる請求項１５記載のデバイスドライバ制御共通化方法。
  17. 　該当デバイスを初期化する間、前記デバイス独立アクセス階層から前記アプリケーションに前記デバイスハンドラ識別子を提供する過程と、
    　前記アプリケーションが、デバイスハンドラ識別子を貯蔵し、該当デバイスハンドラ識別子を用いて該当デバイスを呼び出す過程と、をさらに含む請求項１６記載のデバイスドライバ制御共通化方法。
  18. 　前記デバイス独立アクセス階層が、前記ドライバハンドラ識別子に従って特定のデバイスドライバが呼び出されたかを決定し、その結果に基づいて特定のドライバハンドラを呼び出す過程をさらに含む請求項１７記載のデバイスドライバ制御共通化方法。
  19. 　デバイス独立アクセス階層が標準化共通フォーマットを遂行するために特定のポインタ及びファンクションポインタを使用する請求項１８記載のデバイスドライバ制御共通化方法。
  20. 　前記アプリケーションが使用するファンクションブロックのファンクションを呼び出す場合、前記デバイス独立アクセス階層が、ファンクションテーブルから該当ファンクションの存在を確認し、デバイスドライバがデバイスハンドラ識別子を用いて前記アプリケーションにアクセスすることを収容するデバイスドライバの初期化を知らせるためにデバイスハンドラ識別子を使用する請求項１９記載のデバイスドライバ制御共通化方法。
  21. 　前記第１デバイスドライバが前記第２デバイスドライバに変更される場合、デバイスのためのデバイスハンドラＩＤ値を変更しない請求項２０記載のデバイスドライバ制御共通化方法。
  22. 　前記第１デバイスドライバが前記第２デバイスドライバに変更される場合、前記デバイス独立アクセス階層の制御下でポインタのアドレスを変更する請求項２１記載のデバイスドライバ制御共通化方法。
JP2003289785A 2002-08-08 2003-08-08 デバイスドライバ制御共通化方法 Pending JP2004070964A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR10-2002-0046757A KR100464349B1 (ko) 2002-08-08 2002-08-08 디바이스 드라이버 제어 공통화 방법

Publications (1)

Publication Number Publication Date
JP2004070964A true JP2004070964A (ja) 2004-03-04

Family

ID=31492828

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003289785A Pending JP2004070964A (ja) 2002-08-08 2003-08-08 デバイスドライバ制御共通化方法

Country Status (5)

Country Link
US (1) US7437737B2 (ja)
JP (1) JP2004070964A (ja)
KR (1) KR100464349B1 (ja)
CN (1) CN1241113C (ja)
CA (1) CA2434869A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005103918A1 (ja) * 2004-04-21 2005-11-03 Ntt Docomo, Inc. データ処理装置およびデータ処理方法
JP2007141161A (ja) * 2005-11-22 2007-06-07 Fuji Xerox Co Ltd 変換プログラム、変換装置、およびデバイスドライバ
JP2010277293A (ja) * 2009-05-28 2010-12-09 Seiko Epson Corp コントローラーの制御方法およびコントローラー
JP2013210820A (ja) * 2012-03-30 2013-10-10 Hitachi Information & Telecommunication Engineering Ltd 組み込みシステム及びプログラム
US10372461B2 (en) 2014-09-19 2019-08-06 Alab Inc. Device driver registration device and device driver registration method using same
US11573913B2 (en) 2014-09-19 2023-02-07 Alab Inc. Device proxy and control method

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8126993B2 (en) * 2006-07-18 2012-02-28 Nvidia Corporation System, method, and computer program product for communicating sub-device state information
US20120284702A1 (en) * 2011-05-02 2012-11-08 Microsoft Corporation Binding applications to device capabilities

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02195462A (ja) 1989-01-24 1990-08-02 Matsushita Electric Ind Co Ltd 情報処理端末器
US5815682A (en) 1994-12-13 1998-09-29 Microsoft Corporation Device independent modem interface
US5802365A (en) * 1995-05-05 1998-09-01 Apple Computer, Inc. Dynamic device matching using driver candidate lists
JPH1011384A (ja) 1996-06-24 1998-01-16 Sumitomo Metal Ind Ltd 入出力標準化装置
KR100209360B1 (ko) * 1996-11-30 1999-07-15 이계철 지능형 디바이스 드라이버를 제공하는 광대역 종합정보통신망 정합장치
US6311228B1 (en) * 1997-08-06 2001-10-30 Microsoft Corporation Method and architecture for simplified communications with HID devices
US5963726A (en) * 1998-03-20 1999-10-05 National Instruments Corporation Instrumentation system and method including an improved driver software architecture
US6282586B1 (en) 1998-10-28 2001-08-28 3Com Corporation Method in an operating system, a method and system for supporting multiple hardware devices from a single communications port
JP4057201B2 (ja) * 1999-09-16 2008-03-05 富士通株式会社 異種計算機間高速データ交換方式およびエクステント抽出・変換プログラム記録媒体
US6505258B1 (en) * 2000-02-29 2003-01-07 Compaq Information Technologies Group, L.P. Comprehensive interface between bios and device drivers to signal events
US6938261B2 (en) * 2000-05-12 2005-08-30 Microsoft Corporation System and method employing script-based device drivers
US20020170039A1 (en) * 2001-02-22 2002-11-14 Kovacevic Branko D. System for operating system and platform independent digital stream handling and method thereof
EP1253750A1 (en) * 2001-04-24 2002-10-30 Deutsche Thomson-Brandt Gmbh Method for the control of network devices connected via a bus system
US6952830B2 (en) * 2001-08-16 2005-10-04 Occam Networks, Inc. System and method to uniformly access devices
US6993772B2 (en) * 2001-09-18 2006-01-31 The Mathworks, Inc. Common communication system for control instruments
KR20030065911A (ko) * 2002-02-01 2003-08-09 삼성전자주식회사 임베디드 시스템에서 사용자 어플리케이션과 디바이스드라이버간의 독립성을 보장하는 인터페이스 방법

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005103918A1 (ja) * 2004-04-21 2005-11-03 Ntt Docomo, Inc. データ処理装置およびデータ処理方法
JP2005309783A (ja) * 2004-04-21 2005-11-04 Ntt Docomo Inc データ処理装置およびデータ処理方法
KR100878714B1 (ko) 2004-04-21 2009-01-14 가부시키가이샤 엔티티 도코모 데이터 처리 장치 및 데이터 처리 방법
US8161499B2 (en) 2004-04-21 2012-04-17 Ntt Docomo, Inc. Data processing device and data processing method
JP2007141161A (ja) * 2005-11-22 2007-06-07 Fuji Xerox Co Ltd 変換プログラム、変換装置、およびデバイスドライバ
JP2010277293A (ja) * 2009-05-28 2010-12-09 Seiko Epson Corp コントローラーの制御方法およびコントローラー
JP2013210820A (ja) * 2012-03-30 2013-10-10 Hitachi Information & Telecommunication Engineering Ltd 組み込みシステム及びプログラム
US10372461B2 (en) 2014-09-19 2019-08-06 Alab Inc. Device driver registration device and device driver registration method using same
US11573913B2 (en) 2014-09-19 2023-02-07 Alab Inc. Device proxy and control method

Also Published As

Publication number Publication date
CN1241113C (zh) 2006-02-08
KR20040013703A (ko) 2004-02-14
US7437737B2 (en) 2008-10-14
CA2434869A1 (en) 2004-02-08
US20040030415A1 (en) 2004-02-12
KR100464349B1 (ko) 2005-01-03
CN1484139A (zh) 2004-03-24

Similar Documents

Publication Publication Date Title
US7203696B2 (en) Dynamic registry partitioning
JP3891612B2 (ja) ダイナミック機能置換を有するデータ構造
US7051101B1 (en) Methods and apparatus for controlling devices within storage network
US9733951B2 (en) Creation and use of virtual device drivers on a serial bus
US6122732A (en) System management interrupt for a desktop management interface/system management basic input output system interface function
US8104026B2 (en) Compiler register allocation and compilation
JPH06187259A (ja) Ｏｓ／２仮想装置ドライバを利用したｌａｎへのデータ転送
CN109614165A (zh) 一种com组件的多版本并行运行方法和装置
WO2021196597A1 (zh) 业务插件加载实现方法、装置和终端设备
JP2009059349A (ja) 共用型ジャバｊａｒファイル
US6748459B1 (en) Method and apparatus for address mapping
US5627998A (en) System and method for mapping calls to functions in a first driver level library to a session-based instrumentation control driver level system
JP2004070964A (ja) デバイスドライバ制御共通化方法
JPH0348959A (ja) メモリ素子及び周辺素子の選択装置
CN101136780A (zh) 获取用户命令信息的方法、系统及用户命令注册的装置
US7020723B2 (en) Method of allowing multiple, hardware embedded configurations to be recognized by an operating system
Gill et al. ORB middleware evolution for networked embedded systems
CN113918268A (zh) 一种多租户管理方法及装置
US7346896B2 (en) Slowing network connection for application optimization
US7103686B1 (en) Method and apparatus for device discovery
US7181737B2 (en) Method and apparatus for deployment of high integrity software using static procedure return addresses
US6636964B1 (en) Method and apparatus for loading an object-oriented operating system by providing an initial execution environment and migrating to a core execution environment thereafter
US7519719B2 (en) Automatic creation of protocol dependent control path for instrument application
US20030135708A1 (en) System, method and computer program product for mapping system memory in a multiple node information handling system
US11886838B2 (en) Space- and time-efficient enumerations

Legal Events

Date Code Title Description
RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20040712

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20040803

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20060202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060307

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060606

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061205

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070305

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20071225

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080324

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20080610

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20090501