特許 7457168 半導体デバイスのモデリング方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-18

(45)【発行日】2024-03-27

(54)【発明の名称】半導体デバイスのモデリング方法及び装置

(51)【国際特許分類】

   G06F 30/10 20200101AFI20240319BHJP

【ＦＩ】

G06F30/10 200

【請求項の数】 10

(21)【出願番号】P 2022579028

(86)(22)【出願日】2021-07-06

(65)【公表番号】

(43)【公表日】2023-07-26

(86)【国際出願番号】 CN2021104679

(87)【国際公開番号】W WO2022012371

(87)【国際公開日】2022-01-20

【審査請求日】2022-12-27

(31)【優先権主張番号】202010683246.9

(32)【優先日】2020-07-15

(33)【優先権主張国・地域又は機関】CN

【早期審査対象出願】

(73)【特許権者】

【識別番号】510182294

【氏名又は名称】北京北方華創微電子装備有限公司

【氏名又は名称原語表記】ＢＥＩＪＩＮＧ ＮＡＵＲＡ ＭＩＣＲＯＥＬＥＣＴＲＯＮＩＣＳ ＥＱＵＩＰＭＥＮＴ ＣＯ．， ＬＴＤ．

【住所又は居所原語表記】ＮＯ．８ Ｗｅｎｃｈａｎｇ Ａｖｅｎｕｅ Ｂｅｉｊｉｎｇ Ｅｃｏｎｏｍｉｃ－Ｔｅｃｈｎｏｌｏｇｉｃａｌ Ｄｅｖｅｌｏｐｍｅｎｔ Ａｒｅａ， Ｂｅｉｊｉｎｇ １００１７６， Ｃｈｉｎａ

(74)【代理人】

【識別番号】110001771

【氏名又は名称】弁理士法人虎ノ門知的財産事務所

(72)【発明者】

【氏名】チャイ ジャジャ

【審査官】松浦 功

(56)【参考文献】

【文献】特開２００４－２７２９０９（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１２／００７８５８０（ＵＳ，Ａ１）

【文献】米国特許第０６９７８２５９（ＵＳ，Ｂ１）

【文献】中国特許出願公開第１１０１８８４５４（ＣＮ，Ａ）

【文献】中国特許出願公開第１１１０４５９９２（ＣＮ，Ａ）

【文献】中国特許出願公開第１０７７６６０４２（ＣＮ，Ａ）

【文献】中国特許出願公開第１０７９５７８６７（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ３０／００ －３０／３９８

Ｇｏｏｇｌｅ Ｓｃｈｏｌａｒ

(57)【特許請求の範囲】

【請求項1】

半導体デバイスのモデリング方法であって、
プロセッサが、追加指示操作に応答し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するステップであって、前記追加指示操作は前記デバイスモデルオブジェクトにおける追加対象モデルと前記デバイスモデルツリーにおける目標モデルを選択することに用いられるステップと、
前記ソースコントロールのタイプと前記目標コントロールのタイプに対応する検証モジュールを利用し、選択された追加対象モデルの情報と選択された目標モデルの情報を取得し、予め設定されたデバイスモデリングタイプ検証基準ライブラリに基づき、前記追加対象モデルの情報と前記目標モデルの情報を検証し、前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを決定するステップと、
前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを指示する検証結果を表示するステップと、を実行することを特徴とする半導体デバイスのモデリング方法。

【請求項2】

デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定する前記ステップは、
予め作成されたジェネリックに基づく関数を利用し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するステップを含み、
前記ジェネリックに基づく関数の仮パラメータは、前記ソースコントロールのソースコントロールオブジェクトを受信するための仮パラメータ、前記目標コントロールの目標コントロールオブジェクトを受信するための仮パラメータを含み、前記ジェネリックに基づく関数は、呼び出されたとき、リフレクションにより前記ソースコントロールオブジェクトのタイプと前記目標コントロールオブジェクトのタイプを決定し、これにより前記ソースコントロールのタイプと前記目標コントロールのタイプを決定することに用いられることを特徴とする請求項１に記載の方法。

【請求項3】

前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できると決定する場合、
前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップは、
前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるという検証結果を表示するステップを含み、
プロセッサが、前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップの後、ユーザの追加確認操作に応答し、前記追加対象モデルを前記目標モデルのサブノードとして前記デバイスモデルツリーに追加するステップをさらに実行することを特徴とする請求項１に記載の方法。

【請求項4】

前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できると決定する場合、
前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップは、
前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるという検証結果を表示するステップを含み、
プロセッサが、前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップの後、ユーザの追加放棄操作に応答し、前記追加対象モデルを前記デバイスモデルツリーに追加することを放棄するステップをさらに実行することを特徴とする請求項１に記載の方法。

【請求項5】

前記追加指示操作に応答するステップは、
ユーザが表された前記デバイスモデルオブジェクトにおける１つの前記追加対象モデルを表された前記モデルデバイスツリーに位置する１つの前記目標モデルの位置にドラッグすることに応答するステップを含むことを特徴とする請求項１～４のいずれか１項に記載の方法。

【請求項6】

前記ソースコントロールのタイプはＴｒｅｅＶｉｅｗタイプおよびＬｉｓｔＶｉｅｗタイプのうちの１つであり、前記目標コントロールのタイプはＴｒｅｅＶｉｅｗタイプおよびＬｉｓｔＶｉｅｗタイプのうちの１つであることを特徴とする請求項１～４のいずれか１項に記載の方法。

【請求項7】

前記デバイスモデリングタイプ検証基準ライブラリはデータ収集基準に基づくデバイスモデリングタイプ検証基準を含むことを特徴とする請求項１～４のいずれか１項に記載の方法。

【請求項8】

前記データ収集基準は複数のバージョンのデータ収集基準における現在採用されているバージョンのデータ収集基準であることを特徴とする請求項７に記載の方法。

【請求項9】

プロセッサが、前記データ収集基準の変更に応答し、前記デバイスモデリングタイプ検証基準ライブラリにおける前記データ収集基準に基づくデバイスモデリングタイプ検証基準を修正するステップをさらに実行することを特徴とする請求項８に記載の方法。

【請求項10】

半導体デバイスのモデリング装置であって、
追加指示操作に応答し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するように構成される決定ユニットであって、前記追加指示操作はデバイスモデルオブジェクトにおける追加対象モデルとデバイスモデルツリーにおける目標モデルを選択することに用いられる決定ユニットと、
前記ソースコントロールのタイプと前記目標コントロールのタイプに対応する検証モジュールを利用し、選択された追加対象モデルの情報と選択された目標モデルの情報を取得し、予め設定されたデバイスモデリングタイプ検証基準ライブラリに基づき、前記追加対象モデルの情報と前記目標モデルの情報を検証し、前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを決定するように構成される検証ユニットと、
前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを指示する検証結果を表示するように構成されるフィードバックユニットと、を含むことを特徴とする半導体デバイスのモデリング装置。

【発明の詳細な説明】

【技術分野】

【0001】

本願は半導体分野に関し、具体的には、半導体デバイスのモデリング方法及び装置に関する。

【背景技術】

【0002】

現在、デバイスモデリングを行うとき、デバイスモデリングアプリケーションのメインプログラムによって特定のタイプのコントロールを利用してデバイスモデルオブジェクトを表し、特定のタイプのコントロールを利用してデバイスモデルツリーを表す場合に、デバイスモデルオブジェクトにおける選択されたモデルがデバイスモデルツリーにおける選択されたモデルのサブノードとしてデバイスモデルツリーに追加できるか否かを検証する。検証に関連するコード、すなわちデバイスモデルオブジェクトにおける選択されたモデルがデバイスモデルツリーにおける選択されたモデルのサブノードとしてデバイスモデルツリーに追加できるか否かを検証するコードのすべてはメインプログラムに統合される。

【0003】

一方では、メインプログラムによって特定のタイプのコントロールを利用してデバイスモデルオブジェクトを表し、特定のタイプのコントロールを利用してデバイスモデルツリーを表す場合に検証する。他方では、デバイスモデリングを行うとき、デバイスモデリングの表示の上での需要に従って、デバイスモデルオブジェクトを表すコントロールタイプが変わり及び／又はデバイスモデルツリーを表すコントロールタイプが変わると、デバイスモデリングアプリケーションのメインプログラムにおける検証に関連するコードをすべて再作成する必要があり、デバイスモデリングの表示の上での需要に適応するため、コストが高くなる。

【発明の概要】

【発明が解決しようとする課題】

【0004】

関連技術に存在する問題を克服するために、本願は半導体デバイスのモデリング方法及び装置を提供する。

【課題を解決するための手段】

【0005】

本願の実施例の第１態様によれば、
追加指示操作に応答し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するステップであって、前記追加指示操作は前記デバイスモデルオブジェクトにおける追加対象モデルと前記デバイスモデルツリーにおける目標モデルを選択することに用いられるステップと、
前記ソースコントロールのタイプと前記目標コントロールのタイプに対応する検証モジュールを利用し、選択された追加対象モデルの情報と選択された目標モデルの情報を取得し、予め設定されたデバイスモデリングタイプ検証基準ライブラリに基づき、前記追加対象モデルの情報と前記目標モデルの情報を検証し、前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを決定するステップと、
前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを指示する検証結果を表示するステップと、を含む半導体デバイスのモデリング方法を提供する。

【0006】

いくつかの実施例では、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定する前記ステップは、
予め作成されたジェネリックに基づく関数を利用し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するステップを含み、
前記ジェネリックに基づく関数の仮パラメータは、前記ソースコントロールのソースコントロールオブジェクトを受信するための仮パラメータ、前記目標コントロールの目標コントロールオブジェクトを受信するための仮パラメータを含み、前記ジェネリックに基づく関数は、呼び出されたとき、リフレクションにより前記ソースコントロールオブジェクトのタイプと前記目標コントロールオブジェクトのタイプを決定し、これにより前記ソースコントロールのタイプと前記目標コントロールのタイプを決定することに用いられる。

【0007】

いくつかの実施例では、前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できると決定する場合、前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップは、
前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるという検証結果を表示するステップを含み、
前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップの後、前記方法は、
ユーザの追加確認操作に応答し、前記追加対象モデルを前記目標モデルのサブノードとして前記デバイスモデルツリーに追加するステップをさらに含む。

【0008】

いくつかの実施例では、前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できると決定する場合、前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップは、
前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるという検証結果を表示するステップを含み、
前記追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する前記ステップの後、前記方法は、
ユーザの追加放棄操作に応答し、前記追加対象モデルを前記デバイスモデルツリーに追加することを放棄するステップをさらに含む。

【0009】

いくつかの実施例では、前記追加指示操作に応答するステップは、
ユーザが表された前記デバイスモデルオブジェクトにおける１つの前記追加対象モデルを表された前記モデルデバイスツリーに位置する１つの前記目標モデルの位置にドラッグすることに応答するステップを含む。

【0010】

いくつかの実施例では、ソースコントロールのタイプはＴｒｅｅＶｉｅｗタイプおよびＬｉｓｔＶｉｅｗタイプのうちの１つであり、目標コントロールのタイプはＴｒｅｅＶｉｅｗタイプおよびＬｉｓｔＶｉｅｗタイプのうちの１つである。

【0011】

いくつかの実施例では、前記デバイスモデリングタイプ検証基準ライブラリはデータ収集基準に基づくデバイスモデリングタイプ検証基準を含む。

【0012】

いくつかの実施例では、前記データ収集基準は複数のバージョンのデータ収集基準における現在採用されているバージョンのデータ収集基準である。

【0013】

本願の実施例の第２態様によれば、
追加指示操作に応答し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するように構成される決定ユニットであって、前記追加指示操作はデバイスモデルオブジェクトにおける追加対象モデルとデバイスモデルツリーにおける目標モデルを選択することに用いられる決定ユニットと、
前記ソースコントロールのタイプと前記目標コントロールのタイプに対応する検証モジュールを利用し、選択された追加対象モデルの情報と選択された目標モデルの情報を取得し、予め設定されたデバイスモデリングタイプ検証基準ライブラリに基づき、前記追加対象モデルの情報と前記目標モデルの情報を検証し、前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを決定するように構成される検証ユニットと、
前記追加対象モデルが前記目標モデルのサブノードとして前記デバイスモデルツリーに存在できるか否かを指示する検証結果を表示するように構成されるフィードバックユニットと、を含む半導体デバイスのモデリング装置を提供する。

【発明の効果】

【0014】

本願の実施例に係る半導体デバイスのモデリング方法及び装置は、メインプログラムとは個別に実行する検証モジュールを利用して検証を完了することを実現する。デバイスモデルオブジェクトを表すためのいずれかのソースコントロールのタイプとデバイスモデルツリーを表すためのいずれかの目標コントロールのタイプに対して、対応する検証モジュールによってデバイスモデルオブジェクトにおける選択された追加対象モデルがデバイスモデルツリーにおける選択された目標モデルのサブノードとしてデバイスモデルツリーに追加されるか否かという検証を完了することができる。いずれかのタイプのコントロールを採用してデバイスモデルオブジェクトを表し、いずれかのタイプの目標コントロールを採用してデバイスモデルツリーを表す場合には、対応する検証モジュールを利用して検証することができる。

【0015】

一方、デバイスモデルオブジェクトを表すためのソースコントロールのタイプ及び／又はデバイスモデルツリーを表すための目標コントロールのタイプが変わる場合、対応する検証モジュールを採用して検証すればよく、メインプログラムに検証に関連するコードを含まず、メインプログラムにいかなる影響を与えず、デバイスモデリングの表示上での需要に適応するためにデバイスモデリングアプリケーションのメインプログラムにおける検証に関連するコードをすべて再作成するという問題を回避する。

【図面の簡単な説明】

【0016】

ここでの図面は明細書に組み込まれ且つ明細書の一部を構成し、本願に適合する実施例を示し、且つ明細書とともに本願の原理を説明するために用いられる。

【図1】本願の実施例に係るデバイスモデリング方法のフローチャートである。

【図2】半導体デバイスモデリング時のデバイスモデルオブジェクトとデバイスモデルツリーを表す効果の概略図である。

【図3】デバイスモデリングのプロセスの概略図である。

【図4】デバイスモデリングの原理の概略図である。

【図5】本願の実施例に係るデバイスモデリング装置の構造ブロック図である。

【発明を実施するための形態】

【0017】

以下、図面及び実施例を参照しつつ本願をさらに詳細に説明する。理解されるように、ここで説明された具体的な実施例は関連発明を解釈するために用いられ、該発明を限定するものではない。なお、説明の便宜上、図面には発明に関連する部分のみを示している。

【0018】

なお、矛盾しない限り、本願における実施例及び実施例における特徴は互いに組み合わせることができる。以下、図面及び実施例を参照しつつ本願を詳細に説明する。

【0019】

図１は本願の実施例に係る半導体デバイスのモデリング方法のフローチャートであり、該方法は、ステップ１０１～ステップ１０３を含む。

【0020】

ステップ１０１、追加指示操作に応答し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定する。

【0021】

デバイスモデルオブジェクトを表すためのソースコントロールは現在表されているデバイスモデルオブジェクトが使用しているコントロールであってもよい。デバイスモデルツリーを表すための目標コントロールは現在表されているデバイスモデルツリーが使用しているコントロールであってもよい。

【0022】

例えば、ソースコントロールのタイプはＬｉｓｔＶｉｅｗタイプであり、目標コントロールのタイプはＴｒｅｅＶｉｅｗタイプである。デバイスモデリングを行うとき、デバイスモデリングのインタフェースでは、ＬｉｓｔＶｉｅｗタイプの１つのソースコントロールによってデバイスモデルオブジェクトをユーザに表すことができ、ＴｒｅｅＶｉｅｗタイプの１つの目標コントロールによってデバイスモデルツリーをユーザに表すことができる。

【0023】

半導体デバイスモデリングを行うとき、デバイスモデリングアプリケーションにおけるメインプログラムによってソースコントロールを呼び出してデバイスモデルオブジェクトを表し、目標コントロールを呼び出してデバイスモデルツリーを表すことができる。

【0024】

本願では、半導体デバイスモデリングを行うとき、ユーザによって選択されたデバイスモデルオブジェクトに位置するモデルは追加対象モデルと呼ばれてもよい。

【0025】

デバイスモデリングを行うとき、ユーザによって選択されたデバイスモデルツリーに位置するモデルは目標モデルと呼ばれてもよい。

【0026】

ステップ１０１における上記追加指示操作はデバイスモデルオブジェクトにおける追加対象モデルとデバイスモデルツリーにおける目標モデルを選択することに用いられる。

【0027】

例えば、半導体デバイスモデリングを行うとき、追加指示操作に応答するステップは、
ユーザが表された前記デバイスモデルオブジェクトにおける１つの追加対象モデルを表されたモデルデバイスツリーに位置する１つの前記目標モデルの位置にドラッグすることに応答するステップを含んでもよい。

【0028】

いくつかの実施例では、上記追加指示操作は、まずクリック動作を１回行ってデバイスモデルオブジェクトにおける１つの追加対象モデルを選択し、さらにクリック動作を１回行ってモデルデバイスツリーにおける１つの目標モデルを選択し、その後、選択された追加対象モデルを選択された目標モデルの位置にドラッグすることであってもよい。又は、上記追加指示操作は１回だけクリックしてデバイスモデルオブジェクトにおける１つの追加対象モデルを選択し、次に選択された追加対象モデルを対応する目標モデルの位置にドラッグすることであってもよい。

【0029】

上記ドラッグ動作は、具体的には、ユーザが１つのソースコントロールによって表された情報における１つの情報項目を目標コントロールによって表された情報における１つの情報項目の位置にドラッグすることができ、該ドラッグ動作を完了した後、選択された追加対象モデルを選択された目標モデルの位置にドラッグするように実現することであってもよい。

【0030】

なお、上記追加指示操作はドラッグに限定されず、実際の応用では、他の任意の方法で表されたデバイスモデルオブジェクトにおける１つの追加対象モデルを表されたモデルデバイスツリーに位置する１つの目標モデルの位置に追加し、例えば、まずクリック動作を１回行ってデバイスモデルオブジェクトにおける１つの追加対象モデルを選択し、次に任意のジェスチャー又は動作で該追加対象モデルを表されたモデルデバイスツリーに位置する１つの目標モデルの位置に追加することもできる。

【0031】

デバイスモデリングを行うとき、デバイスモデリングアプリケーションにおけるメインプログラムによって追加指示操作を検出することができる。追加指示操作が検出されたと、デバイスモデリングアプリケーションにおけるコントロールタイプを決定するためのモジュールによって、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定することができる。デバイスモデリングアプリケーションにおけるメインプログラムはソースコントロールのタイプ、目標コントロールのタイプを考慮する必要がなく、また、選択された対応するモデルの情報を取得する必要がない。本願では、対応する検証モジュールによって選択された対応するモデルの情報を取得する。

【0032】

デバイスモデリングを行うとき、ユーザは追加指示操作を行うたびに、デバイスモデルオブジェクトにおける対応する追加対象モデル、デバイスモデルツリーにおける対応する目標モデルを選択することができる。

【0033】

本願では、デバイスモデリングアプリケーションの構成ファイルにソースコントロールのタイプと目標コントロールのタイプを記録することができる。

【0034】

デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定する必要がある場合、上記構成ファイルを読み取ることによりソースコントロールのタイプと目標コントロールのタイプを取得することができる。

【0035】

本願では、デバイスモデルオブジェクトはモデルを複数含む。

【0036】

デバイスモデルオブジェクトにおける各モデルはそれぞれ半導体デバイスに関連する１つのデータ構造に関連付けることができる。例えば、デバイスはロボットである場合、デバイスモデルオブジェクトにおける１つのモデルはロボットのロボットアームを記述した１つのデータ構造に関連付ける。デバイスモデルオブジェクトにおける別のモデルはロボットのあるタイプのパラメータを記憶するデータ構造に関連付ける。

【0037】

デバイスモデルツリーでは、ツリー構造によりデバイスモデルツリーにおける異なるモデル間の関連関係を明らかに示すことができる。異なるモデルはそれぞれ半導体デバイスに関連する１つのデータ構造に関連付けることができる。したがって、デバイスモデルツリーにより、半導体製造デバイスに関連するデータ構造間の関連関係を明らかに示すことができる。上記デバイスモデルツリーは最終的に工場の管理システムとデータ収集アプリケーションに提供され得る。データ収集アプリケーションはＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に従って、収集された半導体デバイスに関連するデータを対応するモデルに関連するデータ構造に記憶することができ、工場の管理システムのサーバはＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に従って、対応するモデルに関連するデータ構造から対応する半導体デバイスに関連するデータを読み取ることができる。

【0038】

デバイスモデルツリーでは、各モデルをそれぞれ１つのノードとする。

【0039】

デバイスモデルツリーにおける各モデルについては、少なくとも１つの親ノード及び／又は少なくとも１つのサブノードをいずれも有する。

【0040】

本願では、デバイスモデルオブジェクトにおける同一のモデルは対応する目標モデルのサブノードとしてデバイスモデルツリーに複数回追加することができる。

【0041】

デバイスモデルオブジェクトにおける１つのモデルについては、該モデルをデバイスモデルツリーに追加するたびに、いずれも該モデルのデバイスモデルツリーにおける名称を修正することができる。デバイスモデルツリーには、異なる位置にある、該モデルのタイプと同じで名称のみが異なるモデルが複数含まれていてもよい。

【0042】

図２を参照し、それは半導体デバイスモデリング時のデバイスモデルオブジェクトとデバイスモデルツリーを表す効果の概略図である。

【0043】

示されたデバイスモデルオブジェクトでは、サブノードはデバイスモデルオブジェクトにおけるモデル、例えば「Ｈｉｅｒａｒｃｈｙ」の各項目、「Ｐａｒａｍｅｔｅｒ」、「Ｅｖｅｎｔ」、「Ｅｘｃｅｐｔｉｏｎｓ」の各項目、「Ｓｔａｔｅ Ｍａｃｈｉｎｅｓ」の各項目などである。デバイスモデルツリーでは、従属関係に従ってデバイスモデルツリーにおける一部のモデルを表す。ユーザは、サブノードを有するモデルの左側の「＋」をクリックすることにより、該モデルのサブノードとしての各モデルをさらに表すことができる。

【0044】

いくつかの実施例では、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するステップは、予め作成されたジェネリックに基づく関数を利用し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するテップを含み、ジェネリックに基づく関数の仮パラメータは、ソースコントロールのソースコントロールオブジェクトを受信するための仮パラメータ、目標コントロールの目標コントロールオブジェクトを受信するための仮パラメータを含み、ジェネリックに基づく関数は、呼び出されたとき、リフレクションによりソースコントロールオブジェクトのタイプと目標コントロールオブジェクトのタイプを決定し、これによりソースコントロールのタイプと目標コントロールのタイプを決定することに用いられる。

【0045】

本願では、Ｃ＃言語を利用してデバイスモデリングアプリケーションを開発することができる。デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するとき、予め定義されたジェネリックに基づく関数を利用してソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定することができる。

【0046】

ジェネリックに基づく関数はジェネリックタイプの２つの仮パラメータを有し、ジェネリックタイプの２つの仮パラメータのタイプはいずれもＣ＃言語におけるジェネリックタイプに属するＴパラメータタイプであってもよい。

【0047】

デバイスオブジェクトを表すための各コントロールのタイプとデバイスモデルツリーを表すための各コントロールのタイプをいずれもＣ＃言語におけるＴパラメータタイプのベースクラスと定義することができる。これにより、ジェネリックに基づく関数のジェネリックタイプの２つの仮パラメータにおける１つの仮パラメータはソースコントロールのタイプを示すオブジェクトを受信することができるジェネリックタイプの仮パラメータとしてもよく、別の仮パラメータは目標コントロールのタイプを示すオブジェクトを受信することができるジェネリックタイプの仮パラメータとしてもよい。

【0048】

デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定する必要がある場合、メインプログラムによってソースコントロールコードの記憶位置と目標コントロールコードの記憶位置から、ソースコントロールのタイプを示すオブジェクト、目標コントロールのタイプを示すオブジェクトをそれぞれ取得し、ジェネリックに基づく関数を呼び出し、ソースコントロールのタイプを示すオブジェクト、目標コントロールのタイプを示すオブジェクトを実際のパラメータとして入力することができる。ソースコントロールのタイプを示すオブジェクトは実際のパラメータとして目標コントロールのタイプを示すオブジェクトを受信することができるジェネリックタイプの仮パラメータに伝送することができる。

【0049】

これにより、ジェネリックに基づく関数は、呼び出されたとき、ソースコントロールのタイプを示すオブジェクトに基づき、Ｃ＃言語のリフレクションメカニズムを介してソースコントロールのタイプを得ること、及び目標コントロールのタイプを示すオブジェクトに基づき、Ｃ＃言語のリフレクションメカニズムを介して目標コントロールのタイプを得ることに用いられる。

【0050】

ステップ１０２、ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュールを利用し、選択された追加対象モデルの情報と選択された目標モデルの情報を取得し、予め設定されたデバイスモデリングタイプ検証基準ライブラリに基づき、追加対象モデルの情報と目標モデルの情報を検証し、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定する。

【0051】

本願では、ソースコントロールのタイプと目標コントロールのタイプを決定した後、ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュールを利用し、選択された追加対象モデルの情報と選択された目標モデルの情報を取得することができる。

【0052】

ソースコントロールのタイプと目標コントロールのタイプは１つのコントロールタイプの組み合わせを構成するようにしてもよい。

【0053】

したがって、ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュールはソースコントロールのタイプと目標コントロールのタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールであってもよい。

【0054】

本願では、デバイスモデルオブジェクトを表せるソースコントロールのタイプはデバイスモデルオブジェクトの候補コントロールタイプと呼ばれてもよい。

【0055】

デバイスモデルツリーを表せる目標コントロールのタイプはデバイスモデルツリーの候補コントロールタイプと呼ばれてもよい。

【0056】

デバイスモデルオブジェクトの候補コントロールタイプ、デバイスモデルツリーの候補コントロールタイプを組み合わせることにより、複数のコントロールタイプの組み合わせを得ることができる。

【0057】

本願では、デバイスモデリングアプリケーションはメインプログラムとは個別に実行する検証モジュールを複数含んでもよい。

【0058】

各検証モジュールはそれぞれ１つのコントロールタイプの組み合わせに対応するようにしてもよい。

【0059】

これに対応して、各検証モジュールについては、該検証モジュールに対応するコントロールタイプの組み合わせにおける１つのコントロールタイプと別のコントロールタイプの両方に対応する。

【0060】

例えば、デバイスモデルオブジェクトのすべての候補コントロールタイプはＬｉｓｔＶｉｅｗタイプ、ＴｒｅｅＶｉｅｗタイプを含む。デバイスモデルツリーのすべての候補コントロールタイプはＬｉｓｔＶｉｅｗタイプ、ＴｒｅｅＶｉｅｗタイプを含む。

【0061】

デバイスモデルオブジェクトの候補コントロールタイプ、デバイスモデルツリーの候補コントロールタイプを組み合わせることにより、４つのコントロールタイプの組み合わせを得ることができる。１番目のコントロールタイプの組み合わせがＴｒｅｅＶｉｅｗタイプ、ＴｒｅｅＶｉｅｗタイプを含み、２番目のコントロールタイプの組み合わせがＬｉｓｔＶｉｅｗタイプ、ＴｒｅｅＶｉｅｗタイプを含み、３番目のコントロールタイプの組み合わせがＴｒｅｅＶｉｅｗタイプ、ＬｉｓｔＶｉｅｗタイプを含み、４番目のコントロールタイプの組み合わせがＬｉｓｔＶｉｅｗタイプ、ＬｉｓｔＶｉｅｗタイプを含むと仮定すると、

【0062】

これに対応して、デバイスモデリングアプリケーションは４つの検証モジュールを含み、各検証モジュールはそれぞれ１つのコントロールタイプの組み合わせに対応する。

【0063】

デバイスモデルオブジェクトを表すためのソースコントロールのタイプがＬｉｓｔＶｉｅｗタイプであり、デバイスモデルツリーを表すための目標コントロールのタイプがＴｒｅｅＶｉｅｗタイプであると仮定すると、ＬｉｓｔＶｉｅｗタイプとＴｒｅｅＶｉｅｗタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールによって選択された追加対象モデルの情報と選択された目標モデルの情報を取得する。

【0064】

デバイスモデルオブジェクトを表すためのソースコントロールについては、デバイスモデルオブジェクトにおける各モデル情報はそれぞれソースコントロールの１つのノードに対応する。

【0065】

デバイスモデルツリーを表すための目標コントロールについては、デバイスモデルツリーにおける各モデル情報はそれぞれ目標コントロールの１つのノードに対応する。

【0066】

デバイスモデリングを行うとき、デバイスモデルオブジェクトにおける１つの追加対象モデルが選択される場合、デバイスモデルオブジェクトを表すためのソースコントロールにとって、ソースコントロールにおける選択された追加対象モデル情報に対応する１つのノードが選択されたことを意味する。ソースコントロールの属性情報に現在選択されているノードの識別子が記録されている。ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュール、すなわち、ソースコントロールのタイプと目標コントロールのタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールによって、ソースコントロールの属性情報の記憶位置から現在選択されているノードの識別子を取得し、これにより選択された追加対象モデル情報に対応する該ノードが選択されたことを決定する。選択された追加対象モデル情報に対応する該ノードの属性情報は該追加対象モデルの情報を含み、該追加対象モデルの情報は他のモデルと区別可能な該追加対象モデルの一意の識別子であってもよい。これにより、選択された追加対象モデルの情報を最終的に取得することができる。

【0067】

デバイスモデリングを行うとき、デバイスモデルツリーにおける１つの目標モデル情報が選択される場合、デバイスモデルツリーを表すための目標コントロールにとって、目標コントロールにおける選択された目標モデル情報に対応する１つのノードが選択されたことを意味する。

【0068】

ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュール、すなわち、ソースコントロールのタイプと目標コントロールのタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールによって、目標コントロールの属性情報の記憶位置から現在選択されているノードの識別子を取得し、これにより選択された目標モデルに対応する該ノードが選択されたことを決定する。選択された目標モデルに対応する該ノードの属性情報は該目標モデルの情報を含み、該目標モデルの情報は他のモデルと区別可能な該目標モデルの一意の識別子であってもよい。これにより、選択された目標モデルの情報を最終的に取得することができる。

【0069】

例えば、デバイスモデルオブジェクトを表すためのソースコントロールのタイプはＬｉｓｔＶｉｅｗタイプであり、デバイスモデルツリーを表すための目標コントロールのタイプはＴｒｅｅＶｉｅｗタイプであり、ＬｉｓｔＶｉｅｗタイプとＴｒｅｅＶｉｅｗタイプに対応する検証モジュール、すなわちＬｉｓｔＶｉｅｗタイプとＴｒｅｅＶｉｅｗタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールを利用し、選択された追加対象モデル情報と選択された目標モデル情報を取得する。

【0070】

本願では、ソースコントロールのタイプが変わる場合及び／又は目標コントロールのタイプが変わる場合、メインプログラムのコードを変更する必要がない。

【0071】

例えば、デバイスモデルオブジェクトを表すためのソースコントロールのタイプはＬｉｓｔＶｉｅｗであり、デバイスモデルツリーを表すための目標コントロールのタイプはＴｒｅｅＶｉｅｗである。

【0072】

デバイスモデルオブジェクトを表すためのソースコントロールのタイプがＬｉｓｔＶｉｅｗからＴｒｅｅＶｉｅｗに変更し、デバイスモデルツリーを表すための目標コントロールのタイプが依然としてＴｒｅｅＶｉｅｗである場合、ＴｒｅｅＶｉｅｗタイプとＴｒｅｅＶｉｅｗタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールによって検証すればよいが、メインプログラムのコードを変更する必要がない。

【0073】

本願では、ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュールによって選択された追加対象モデル情報と選択された目標モデル情報を取得した後、ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュールによって予め設定されたデバイスモデリングタイプ検証基準ライブラリに基づき、追加対象モデルの情報と目標モデルの情報を検証し、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定する。

【0074】

デバイスモデリングタイプ検証基準ライブラリは、デバイスモデルオブジェクトにおける各モデルの情報、デバイスモデルオブジェクトにおける各モデルにそれぞれ対応するデバイスモデリングタイプ検証基準を含んでもよい。

【0075】

デバイスモデルオブジェクトにおける各モデルについては、該モデルの情報と該モデルに対応するデバイスモデリングタイプ検証基準はデバイスモデリングタイプ検証基準ライブラリに対応して記憶されている。

【0076】

デバイスモデルオブジェクトにおける各モデルについては、該モデルに対応するデバイスモデリングタイプ検証基準は、デバイスモデルツリーにおける該モデルの親ノードになり得るモデルのすべてのタイプを含んでもよい。

【0077】

追加対象モデルの情報と目標モデルの情報を検証し、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定するとき、まず追加対象モデルの情報に従って、デバイスモデリングタイプ検証基準ライブラリから追加対象モデルに対応するデバイスモデリングタイプ検証基準を検索することができる。次に、追加対象モデルに対応するデバイスモデリングタイプ検証基準からデバイスモデルツリーにおける、追加対象モデルの親ノードになり得るモデルのすべてのタイプをさらに取得する。最後に、デバイスモデルツリーにおける、該追加対象モデル情報の親ノードになり得るモデルのすべてのタイプが目標モデルの情報のタイプを含むか否かを決定することができる。デバイスモデルツリーにおける、該追加対象モデル情報の親ノードになり得るモデルのすべてのタイプが目標モデルの情報のタイプを含むと決定する場合、追加対象モデル情報が目標モデル情報のサブノードとしてデバイスモデルツリーに追加され得ると決定することができる。

【0078】

いくつかの実施例では、デバイスモデリングタイプ検証基準ライブラリはデータ収集基準に基づくデバイスモデリングタイプ検証基準を含む。

【0079】

本願では、データ収集基準はＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準であってもよい。

【0080】

デバイスモデルオブジェクトにおける各モデルについては、該モデルがどのようなタイプのモデルのサブノードとしてデバイスモデルツリーに存在できるかはＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に定義され得る。ＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に基づき、デバイスモデルオブジェクトにおける各モデルにそれぞれ対応するＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に基づくデバイスモデリングタイプ検証基準を予め確立し、デバイスモデリングタイプ検証基準ライブラリを得る。

【0081】

いくつかの実施例では、現在追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定するための、予め設定されたデバイスモデリングタイプ検証基準ライブラリについては、予め設定されたデバイスモデリングタイプ検証基準ライブラリにおける該デバイスモデリングタイプ検証基準が依拠するデータ収集基準は複数のバージョンのデータ収集基準における現在採用されているバージョンのデータ収集基準である。

【0082】

現在採用されているバージョンのデータ収集基準は複数のバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準における現在使用されているＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準であってもよい。

【0083】

例えば、１１０５バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準、０７１０バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準を予め定義し、現在のバージョンは０７１０バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準である。具体的には、現在どのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準を使用しているかは、データ収集アプリケーションと工場の半導体製造デバイスとのデータ伝送需要、工場管理システムのサーバと工場の半導体製造デバイスとのデータ伝送需要に応じて決定される。

【0084】

本願では、各バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に対し、それぞれ該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリを予め確立することができる。

【0085】

これに対応して、各バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準については、該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリにおけるデバイスモデリングタイプ検証基準は該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に基づくデバイスモデリングタイプ検証基準である。

【0086】

現在採用されているＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリを現在追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定するための、予め設定されたデバイスモデリングタイプ検証基準ライブラリとする。

【0087】

ステップ１０３、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示する。

【0088】

本願では、追加対象モデル情報が目標モデル情報のサブノードとしてデバイスモデルツリーに存在できると決定した後、検証結果をユーザに表示することができる。

【0089】

追加対象モデル情報が目標モデル情報のサブノードとしてデバイスモデルツリーに追加され得ると決定する場合、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果をユーザに表示する。例えば、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得ることを指示するラベルをユーザに表示する。

【0090】

追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得ないと決定する場合、追加対象モデルが目標モデル情報のサブノードとしてデバイスモデルツリーに追加され得ないことを指示する検証結果をユーザに表示する。例えば、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得ないことを指示するラベルをユーザに表示する。

【0091】

いくつかの実施例では、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できると決定する場合、追加対象モデル情報が目標モデル情報のサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示するステップは、追加対象モデル情報が目標モデル情報のサブノードとしてデバイスモデルツリーに存在できるという検証結果を表示するステップを含み、追加対象モデル情報が目標モデル情報のサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示するステップ後、ユーザの追加確認操作に応答し、追加対象モデルを目標モデルのサブノードとしてデバイスモデルツリーに追加するステップをさらに含む。

【0092】

検証結果が追加対象モデルが目標モデルのサブノードとすることができることを指示する場合、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得ることを指示する検証結果をユーザに表示した後、ユーザは追加対象モデルをデバイスモデルツリーに追加すると決定すると、ユーザは追加確認操作を行うことができる。ユーザの追加確認操作に応答し、追加対象モデルを目標モデルのサブノードとしてデバイスモデルツリーに追加できる。

【0093】

いくつかの実施例では、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できると決定する場合、該追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示するステップは、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるという検証結果を表示するステップを含み、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示するステップの後、ユーザの追加放棄操作に応答し、追加対象モデルをデバイスモデルツリーに追加することを放棄するステップをさらに含む。

【0094】

追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得ることを指示する検証結果をユーザに表示した後、ユーザは追加対象モデルをデバイスモデルツリーを追加することを放棄すると、ユーザは追加放棄操作を行うことができる。ユーザの追加放棄操作に応答し、該追加対象モデルを該デバイスモデルツリーに追加することを放棄することができる。

【0095】

いくつかの実施例では、データ収集基準の変更に応答し、デバイスモデリングタイプ検証基準ライブラリにおける該データ収集基準に基づくデバイスモデリングタイプ検証基準を修正する。

【0096】

本願では、いずれかのバージョンのデータ収集基準が変わっても、変わったデータ収集基準のデバイスモデリングタイプ検証基準ライブラリにおける、該データ収集基準に基づく対応するデバイスモデリングタイプ検証基準を修正し、対応する更新されたデバイスモデリングタイプ検証基準ライブラリを得ることができる。

【0097】

複数のバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準における現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準を例にし、デバイスモデリングオブジェクトにおける少なくとも１つのモデルについては、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準によって定義された、該モデルの親ノードになり得るタイプが変わる場合、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準の変更を引き起こす。

【0098】

現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準が変わる場合、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリにおける、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に基づく対応するデバイスモデリングタイプ検証基準、すなわち上記親ノードのタイプの変わった各モデルにそれぞれ対応するデバイスモデリングタイプ検証基準を修正し、更新された、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリを得ることができる。

【0099】

言い換えれば、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準、デバイスモデルオブジェクトにおける、その親ノードとすることができるモデルのタイプが変わったモデルについては、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリにおける、該モデルに対応するデバイスモデリングタイプ検証基準を修正し、更新された、現在採用されているバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリを得る。

【0100】

本願では、いずれかのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリはいずれもメインプログラムとは個別に実行し、また、いずれかのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリにおけるいずれかのデバイスモデリングタイプ検証基準はいずれもメインプログラムとは個別に実行する。

【0101】

いずれかのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準が変わっても、変わったバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリにおける、変わったバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に基づく対応するデバイスモデリングタイプ検証基準を対応して修正することができる。

【0102】

これにより、いずれかのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準については、該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリを、現在追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定するための、予め設定されたデバイスモデリングタイプ検証基準ライブラリとすると、該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準が変わった場合には、更新された、該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリを生成することができる。

【0103】

該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準が変わった後、更新された、該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリを、現在追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定するための、予め設定されたデバイスモデリングタイプ検証基準ライブラリとすることができ、これにより、後の検証プロセスに追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定する。

【0104】

いずれかのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準については、該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準デバイスのモデリングタイプ検証基準ライブラリを現在追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定するための、予め設定されたデバイスモデリングタイプ検証基準ライブラリとすると、該バージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準が変わった場合には、メインプログラムに検証プロセスに関連するコードを含まないため、メインプログラムのコードを修正する必要がなく、すなわちメインプログラムのコードを再作成する必要がなく、また、検証モジュールの検証プロセスに関連するコードを修正する必要がない。これにより、デバイスモデリングアプリケーションのメンテナンスを容易にし、また、デバイスモデリングのコードの実行効率を向上させ、ＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準の変更による大量のコード再作成を回避し、開発コストを節約し、且つメンテナンスのコストを低減させる。

【0105】

図３を参照し、それはデバイスモデリングのプロセスの概略図である。

【0106】

デバイスモデリングアプリケーションを起動する。

【0107】

モデルファイルを新規作成する。新規作成されたモデルファイルにはデバイスモデルオブジェクトが含まれている。

【0108】

デバイスモデルオブジェクトから追加対象モデル情報Ｍｏｄｅｌ Ｏｂｊｅｃｔ１を選択する。

【0109】

デバイスモデルツリーにおける対応するノードＰａｒｅｎｔ Ｎｏｄｅ１すなわち目標モデルにドラッグする。

【0110】

ソースコントロールのタイプと目標コントロールのタイプを取得する。

【0111】

タイプ検証プールには複数の検証モジュール、複数の異なるバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡのデバイスモデリングタイプ検証基準ライブラリが統合される。

【0112】

タイプ検証プールにおけるソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュールによって、現在のバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡに基づくデバイスモデリングタイプ検証基準に従って検証比較を行い、選択された追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得るか否かを決定し、フィードバック結果を得る。

【0113】

タイプ検証プールはフィードバック結果をメインプログラムにフィードバックする。

【0114】

フィードバック結果が追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得ることである場合、追加され得ることを指示するラベルを表す。Ｍｏｄｅｌ Ｏｂｊｅｃｔ１をＰａｒｅｎｔ Ｎｏｄｅ１のサブノードとしてデバイスモデルツリーに追加する。

【0115】

フィードバック結果が追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに追加され得ないことである場合、追加され得ないことを指示するラベルを表す。

【0116】

図４を参照し、それはデバイスモデリングの原理の概略図である。

【0117】

図４では、ソースコントロールのタイプがＴｒｅｅＶｉｅｗタイプであり且つ目標コントロールのタイプがＴｒｅｅＶｉｅｗタイプであり、ソースコントロールのタイプがＬｉｓｔＶｉｅｗタイプであり且つ目標コントロールのタイプがＴｒｅｅＶｉｅｗタイプであり、ソースコントロールのタイプがＴｒｅｅＶｉｅｗタイプであり且つ目標コントロールのタイプがＬｉｓｔＶｉｅｗタイプであるという３種の表示状況を示す。

【0118】

どの表示状況であっても、対応する検証モジュールを採用して検証すればよい。いずれかの検証モジュールはいずれもメインプログラムとは個別に実行する。

【0119】

デバイスモデルオブジェクトを表すためのソースコントロールのタイプがＬｉｓｔＶｉｅｗタイプであり、デバイスモデルツリーを表すための目標コントロールのタイプがＴｒｅｅＶｉｅｗタイプである場合、ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュール、すなわちＬｉｓｔＶｉｅｗタイプとＴｒｅｅＶｉｅｗタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールを利用する。

【0120】

また、ある表示状況から別の表示状況に変更する際に、メインプログラムのコードを修正する必要がない。

【0121】

例えば、デバイスモデルオブジェクトを表すためのソースコントロールのタイプはＬｉｓｔＶｉｅｗタイプであり、デバイスモデルツリーを表すための目標コントロールのタイプはＴｒｅｅＶｉｅｗタイプであり、デバイスモデルオブジェクトを表すためのソースコントロールのタイプがＬｉｓｔＶｉｅｗタイプからＴｒｅｅＶｉｅｗタイプに変更するとき、デバイスモデルツリーを表すための目標コントロールのタイプが依然としてＴｒｅｅＶｉｅｗタイプである場合、ＴｒｅｅＶｉｅｗタイプとＴｒｅｅＶｉｅｗタイプで構成されるコントロールタイプの組み合わせに対応する検証モジュールによって検証すればよく、メインプログラムのコードを変更する必要がない。

【0122】

いずれかのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準が変わっても、変わったバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準のデバイスモデリングタイプ検証基準ライブラリにおける、変わったバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準に基づくデバイスモデリングタイプ検証基準を対応して修正することができる。メインプログラムに検証コードを含まないため、いずれかのバージョンのＳＥＭＩ ＩｎｔｅｒｆａｃｅＡ基準が変わっても、メインプログラムのコードを修正する必要がなく、また、検証プロセスに関連するコードを修正する必要がない。

【0123】

図４では、ジェネリックに基づく関数はＶａｌｉｄａｔｉｏｎ（Ｔｙｐｅ、Ｔｙｐｅ）で示される。メインプログラムによってＶａｌｉｄａｔｉｏｎ（Ｔｙｐｅ、Ｔｙｐｅ）を呼び出して、ソースコントロールのタイプを示すオブジェクト、目標コントロールのタイプを示すオブジェクトを実際のパラメータとして入力することができる。Ｖａｌｉｄａｔｉｏｎ（Ｔｙｐｅ、Ｔｙｐｅ）は、呼び出されたとき、ソースコントロールのタイプを示すオブジェクトに基づき、Ｃ＃言語のリフレクションメカニズムによりソースコントロールのタイプを得ること、及び目標コントロールのタイプを示すオブジェクトに基づき、Ｃ＃言語のリフレクションメカニズムにより目標コントロールのタイプを得ることに用いられる。

【0124】

なお、上記ステップ１０１～１０３は、例示的に選択された追加対象モデルがデバイスモデルツリーにおける目標モデルのサブノードとするか否かを検証するプロセスに必要な操作を説明する。

【0125】

また、なお、半導体デバイスモデリングを行うとき、ユーザはデバイスモデルオブジェクトにおける１つのモデルを１つの目標モデルのサブノードとしてデバイスモデルツリーに追加しようとするたびに、上記ステップ１０１～１０３を実行することができる。

【0126】

図５を参照し、それは本願の実施例に係る半導体デバイスのモデリング装置の構造ブロック図を示す。半導体デバイスモデリングは、決定ユニット５０１と、検証ユニット５０２と、フィードバックユニット５０３とを含む。

【0127】

決定ユニット５０１は、追加指示操作に応答し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するように構成され、追加指示操作はデバイスモデルオブジェクトにおける追加対象モデルとデバイスモデルツリーにおける目標モデルを選択することに用いられる。

【0128】

検証ユニット５０２は、ソースコントロールのタイプと目標コントロールのタイプに対応する検証モジュールを利用し、選択された追加対象モデルの情報と選択された目標モデルの情報を取得し、予め設定されたデバイスモデリングタイプ検証基準ライブラリに基づき、追加対象モデルの情報と目標モデルの情報を検証し、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを決定するように構成される。

【0129】

フィードバックユニット５０３は、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果を表示するように構成される。

【0130】

いくつかの実施例では、決定ユニット５０１は、さらに、予め作成されたジェネリックに基づく関数を利用し、デバイスモデルオブジェクトを表すためのソースコントロールのタイプとデバイスモデルツリーを表すための目標コントロールのタイプを決定するように構成され、ジェネリックに基づく関数の仮パラメータは、ソースコントロールのソースコントロールオブジェクトを受信するための仮パラメータ、目標コントロールの目標コントロールオブジェクトを受信するための仮パラメータを含み、ジェネリックに基づく関数は、呼び出されたとき、リフレクションによりソースコントロールオブジェクトのタイプと目標コントロールオブジェクトのタイプを決定し、これによりソースコントロールのタイプと目標コントロールのタイプを決定することに用いられる。

【0131】

いくつかの実施例では、フィードバックユニット５０３は、さらに、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できると決定する場合、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるという検証結果を表示するように構成される。

【0132】

半導体デバイスのモデリング装置は、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果をフィードバックユニット５０３によって表示するステップの後、ユーザの追加確認操作に応答し、追加対象モデルを目標モデルのサブノードとしてデバイスモデルツリーに追加するように構成される追加ユニットをさらに含む。

【0133】

いくつかの実施例では、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できると決定する場合、フィードバックユニット５０３は、さらに、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるという検証結果を表示するように構成される。

【0134】

半導体デバイスのモデリング装置は、追加対象モデルが目標モデルのサブノードとしてデバイスモデルツリーに存在できるか否かを指示する検証結果をフィードバックユニット５０３によって表示するステップの後、ユーザの追加放棄操作に応答し、追加対象モデルをデバイスモデルツリーに追加することを放棄するように構成される追加放棄ユニットをさらに含む。

【0135】

いくつかの実施例では、追加指示操作は、選択された追加対象モデルを選択された目標モデルの位置にドラッグすることを含む。

【0136】

いくつかの実施例では、ソースコントロールのタイプはＴｒｅｅＶｉｅｗおよびＬｉｓｔＶｉｅｗのうちの１つであり、目標コントロールのタイプはＴｒｅｅＶｉｅｗおよびＬｉｓｔＶｉｅｗのうちの１つである。

【0137】

いくつかの実施例では、データ収集基準は複数のバージョンのデータ収集基準における現在採用されているバージョンのデータ収集基準である。

【0138】

いくつかの実施例では、半導体デバイスのモデリング装置は、データ収集基準の変更に応答し、デバイスモデリングタイプ検証基準ライブラリにおける該データ収集基準に基づくデバイスモデリングタイプ検証基準を修正するように構成される修正ユニットをさらに含む。

【0139】

本願は電子デバイスをさらに提供し、該電子デバイスは、１つ又は複数のプロセッサと、上記実施例で説明された操作を実行するための命令が含まれ得る１つ又は複数のプログラムを記憶するためのメモリを配置することができる。１つ又は複数のプログラムが１つ又は複数のプロセッサによって実行されると、１つ又は複数のプロセッサに上記実施例で説明された操作の命令を実行させる。

【0140】

本願はコンピュータ可読媒体をさらに提供し、該コンピュータ可読媒体は電子デバイスに含まれるものであってもよく、単独で存在しており、電子デバイスに組み込まれていないものであってもよい。上記コンピュータ可読媒体には、１つ又は複数のプログラムが電子デバイスによって実行されると、電子デバイスに上記実施例で説明された操作を実行させる１つ又は複数のプログラムが担持される。

【0141】

なお、本願に記載のコンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体、又は上記の２つの任意の組み合わせであってもよい。コンピュータ可読記憶媒体は、例えば、電気、磁気、光、電磁、赤外線、又は半導体のシステム、装置又はデバイス、又は任意以上の組み合わせを含んでもよいが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例としては、１つ又は複数の導線を有する電気的接続、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、又は上記の任意の適切な組み合わせを含んでもよいが、これらに限定されない。本願では、コンピュータ可読記憶媒体は、メッセージ実行システム、装置、又はデバイスによって使用されるか、又はそれらと組み合わせて使用されることができるプログラムを含むか又は記憶する任意の有形媒体であってもよい。一方、本願では、コンピュータ可読信号媒体は、コンピュータ可読プログラムコードを担持するベースバンド中に、又は搬送波の一部として伝播するデータ信号を含んでもよい。このように伝播するデータ信号は、電磁信号、光信号、又は上記の任意の適切な組み合わせを含むが、これらに限定されない多方面の形態を採用ことができる。コンピュータ可読信号媒体は、メッセージ実行システム、装置、又はデバイスによって使用され、又はそれらと組み合わせて使用されるプログラムを送信、伝播、又は伝送することができるコンピュータ可読記憶媒体以外の任意のコンピュータ可読媒体であってもよい。コンピュータ可読媒体に含まれるプログラムコードは、無線、電線、光ケーブル、ＲＦなど、又は上記の任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体で送信することができる。

【0142】

図面におけるフローチャート及びブロック図は、本願の様々な実施例のシステム、方法及びコンピュータプログラム製品の実現可能なシステムアーキテクチャ、機能及び操作を示す。この点で、フローチャート又はブロック図の各ブロックは、所定の論理機能を実現するための１つ又は複数の実行可能なメッセージを含むモジュール、プログラムセグメント、又はコードの一部を表すことができる。なお、代替としての実装の中には、ブロックに示された機能が図面に示された順序とは異なる順序で発生することもある。例えば、連続的に表される２つのブロックは、実際には基本的に並列に実行されてもよく、関連する機能に応じて逆の順序で実行されることもある。なお、ブロック図及び／又はフローチャートにおける各ブロック、及びブロック図及び／又はフローチャートにおけるブロックの組み合わせは、所定の機能又は操作を実行する専用のハードウェアに基づくシステムで実現することができ、又は専用のハードウェアとコンピュータメッセージの組み合わせで実現することができる。

【0143】

以上の説明は、本願の好適な実施例及び使用される技術的原理の説明にすぎない。当業者であれば理解されるように、本願に係る発明の範囲は、上記技術的特徴の特定の組み合わせにより形成された技術的実施例に限定されるものではなく、同時に述べた発明の構想から逸脱しない場合、上記技術的特徴又はその同等特徴の任意の組み合わせにより形成された他の技術的実施例を網羅する。例えば上記特徴は本願に開示された（限定されない）類似する機能を有する技術的特徴と相互に置換して技術的実施例が形成される。

【図1】

【図2】

【図3】

【図4】

【図5】