JP6025293B2 - 信号処理ネットワーク - Google Patents

Description

関連出願のクロスリファレンス
本願は、２００６年５月１９日付け出願の、目下係争中のアメリカ合衆国特許出願第６０／８０１，９５８号（名称「Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｎｅｔｗｏｒｋ」の優先権を主張するものである。この出願は本発明に参照として完全に組み込まれている。

技術分野
本発明は信号処理に関し、より詳細にはコントロールシステムにおける展開（ｄｅｐｌｏｙｍｅｎｔ）のための信号処理ネットワーク（ＳＰＮ）のための装置、方法およびシステムに関する。

背景技術情報
ＳＰＮに類似したコンセプトが、多くの形態で存在していることが知られている。ＩＰＭと呼ばれるアプリケーションを監視するプロセスが以前に、Ｓｉｅｍｅｎｓ社とＨｅｌｌｅｒ ＡＧ社との共同作業として開発されている。ＩＰＭは目下、Ｓｉｎｕｍｅｒｉｋ８４０Ｄ上で動作する製品である。ＩＰＭはＳｉｅｍｅｎｓ社が所有し、Ｈｅｌｌｅｒ社によって、その機械のオプショナルフィーチャとして販売されている。ＩＰＭは「信号補正連鎖：Signal Correction Chain」として知られているソフトウェアコンポーネントを有している。この信号補正連鎖は、プロセス監視に関する論議において本願に記載されるように、信号補正の役割を担う。ＳＰＮのように、信号補正連鎖は計算ブロックから成る。この計算ブロックは特定のタイプの方程式を実行する役割を担い、計算ブロックからのアウトプットは、別の計算ブロックの入力側へと伝送される。ＳＰＮとは異なり、ＩＰＭにおける信号補正は著しく制限されたトポロジーを有しており、各ブロックからの唯一の信号インプットと唯一の信号アウトプットしか許可しない。さらにこの信号補正は、これらのブロックをあらわすために使用されているデータフォーマットの結果として、ブロックがパラメータ化される方法において制限されている。さらに、信号補正のコンセプトは、サーボ機構またはシミュレーションの目的では使用されていない。

市販されている製品であるＳＩＭＵＬＩＮＫ^（Ｒ）は、Ｔｈｅ Ｍａｔｈｗｏｒｋ社によって販売されている。ＳＩＭＵＬＩＮＫ^（Ｒ）は大きく、かつパワフルなソフトウェアパッケージであり、これは基本的には、異なる方程式求解機であって、シミュレーションされる動的システムをあらわすためにブロックダイアグラムを使用する。ＳＩＭＵＬＩＮＫ^（Ｒ）ブロックは、ＳＰＵと類似しており、ここではこれらのブロックは１つまたは複数のアウトプットを有することができ、パラメータ化され、幾つかの特別の計算機能を担う。ブロックダイアグラム全体または「モデル」はデータフォーマットとしてあらわされる。通常のＳＩＭＵＬＩＮＫ^（Ｒ）は組み込まれていない環境で作動する。これは例えばＰＣプラットフォームまたはＵｎｉｘワークステーションである。しかし、Ｔｈｅ Ｍａｔｈｗｏｒｋ社は、ＳＩＭＵＬＩＮＫ^（Ｒ）の拡張を提供している。これはすなわち、ＲＥＡＬ ＴＩＭＥ ＷＯＲＫＳＨＯＰ^（Ｒ）として知られている製品である。ＲＥＡＬ ＴＩＭＥ ＷＯＲＫ ＳＨＯＰ^（Ｒ）は、ＳＩＭＵＬＩＮＫ^（Ｒ）モデルをコンパイルすることができ、特定の目標が定められたリアルタイムプラットフォーム上で動作するコードを実行することができる。ＳＩＭＵＬＩＮＫ^（Ｒ）と組み合わされたＲＥＡＬ ＴＩＭＥ ＷＯＲＫ ＳＨＯＰ^（Ｒ）とＳＰＮとの間の主な相違点は、ＲＥＡＬ ＴＩＭＥ ＷＯＲＫ ＳＨＯＰ^（Ｒ）は走行時間コードを生成し、コンパイルし、リンクさせ、ＳＰＮはデータを使用して、既に存在する、コンパイルされ、リンクされているコードを構築することである。他の相違点は、ＳＰＮがＸＭＬを使用し、その定義をあらわし、監視、故障検出、サーボコントロールおよびシミュレーションの目的のためにモーションコントローラに対して専用のインターフェースを提供することである。ＳＰＮの他の独自のアスペクトは、本願明細書に、詳細な説明において記載されている。

択一的な選択肢
信号処理ネットワークを柔軟に指定するための機構を提供する幾つかの択一的な方法が考察された。１つの選択肢は、ＳＰＮのより高いレベルの記述から、実行可能なコードを自動的に生成することである。高いレベルの記述は、モデリング環境を用いて実施される。これは例えば、ＳＩＭＵＬＩＮＫ^（Ｒ）、ＣＡＳＥツールまたはＸＭＬである。自動的に生成されたコードの１つの欠点は、このようなソフトウェアのユーザが、コードが自動的に生成されたことを知ると、快く思わない可能性がある、ということである。自動的に生成されたコードに対する他の考慮すべき問題は、ソフトウェアテストの領域内にある。すなわち、自動的に生成されたコードで環境を包括的な方法でどのようにテストするかである。

別の選択肢は開放されたアーキテクチャーインターフェースである。これによって、ソフトウェア開発者は、ロード可能な実行可能なコードとして、固定されたモデルを生成することができる。実行アルゴリズムは固定されているが、データによって、例えばＸＭＬとしてパラメータ化可能である。一般的な目的のＯＡインターフェースの利点は、ＣまたはＣ＋＋等のプログラミング言語によって高度に作成されたアルゴリズムを開発することが可能になる、ということである。このアルゴリズムはネットワーク内に、限定されているＳＰＵタイプのセットのインスタンスを組み合わせることによっては不可能である。このようなインターフェースの１つの欠点は、これが使用ケース（使用領域）を制限してしまう、ということである。プロセス監視のための使用ケースを例として取り上げると、信号補正および故障検出のための新たなアイディアは、新たなソースコードの開発を必要とする。これは、セットアップユーティリティを提供する製品とリアルタイム信号補正を提供する製品との間で、ソフトウェアリリースの調整を必要とする。サーボコントロールの場合には、セットアップエンジニアはしばしば、その機械の領域におけるリアルタイムソフトウェアを開発、構築および展開するのに必要とされるスキルまたはツールを有していないことがある。

発明の概要
本発明は、モーションコントロールシステム上での展開のための信号処理ネットワークを生成するための新しい装置、システムおよび方法である。例として挙げるシステムは１つまたは複数の信号処理ユニットを有する。これは、既存のコンパイルされた、リンクされたコードを用いてデータフォーマットであらわされる。各信号処理ユニットは多数の入力側と多数の出力側に適している。このシステムは、１つまたは複数の信号処理ユニット間でインプットおよびアウトプットをルーティングするために、１つまたは複数のシグナルフローコネクションを有することもできる。

本発明は以下の実施例を含む。１つの実施例では、インプットはモーションコントロールシステムの監視に関している。別の実施例では、インプットは故障検出システムに関する。別の実施例では、インプットはモーションコントロールシステムの操作に関している。さらに別の実施例では、インプットはモーションコントロールシステムのシミュレーションに関している。データフォーマットは、ＸＭＬまたは類似の言語である。このデータフォーマットは、信号処理トポロジーを指定するのに使用される。１つの実施例では、データフォーマットは、信号処理ネットワークによって使用されている方程式の処理のタイプおよび／または方程式のパラメータ化を指定する。

本発明の上述した対象またはフィーチャのいずれか１つまたは複数を満たさなければならないシステムまたは方法に本発明が限定されるものではないことに留意するのは重要なことである。本発明が、ここで述べられた実施例に限定されるものではないことに留意するのも重要である。本発明の範囲内で当業者による修正および置換が可能であり、これは以降の特許請求の範囲以外では限定されない。

図面の簡単な説明
以降の詳細な説明を、添付図面を参照しながら読むことによって、本発明の上述の特徴および他の特徴および利点はより良好に理解されるであろう。

図１は、本発明の実施例１００に従ったＳＰＮにおける使用のために定義されたクラス間の関係のクラス図である。

図２は、本発明の第１の実施例に従った、信号処理ネットワークのための方法のフローチャートである。

詳細な説明
本発明の実施形態は、モーションコントロールシステム上での展開のための信号処理ネットワーク（ＳＰＮ）を生成するための新しい装置、システムおよび方法を提供する。この信号処理ネットワークは、信号処理ユニット（ＳＰＵ’ｓ）と、あるＳＰＵの計算された結果を別のＳＰＵへルーティングするためのシグナルフローコネクション（ＣＮＣＴ）から成る。このネットワークは、リアルタイムイベントにおける、指定された計算を循環的に評価する。データフォーマットは、ネットワークトポロジー、処理方程式のタイプおよび方程式のパラメータ化を、新たな実行可能なコードを作成することを必要とせずに完全に指定する。計算ネットワークはデータフォーマット定義から、必要であるときにモーションコントロールシステムによって生成される。

信号処理ネットワーク（ＳＰＮ）によって、汎用目的の計算ネットワークのモーションコントロールシステム上への領域設置が可能になる。そのトポロジー、方程式およびパラメータ化はフォーマット（例えばＸＭＬファイル）によって完全に指定される。これは、要求されている信号処理方程式が既知でない場合に有利であり、新たな実行可能なコードの作成は、現場での展開に対する必要性のため、オプションではない。

プロセス監視
モーションコントロールシステムは内部の変数を含んでいる。これはドライブアクチュエータの位置、速度および力をあらわす。ドライブアクチュエータの例は電気モータおよび液圧式シリンダーを含む。モーションコントロールシステムは幾つかのタイプのプロセスと関連した機構の位置または速度を調整し、そのような場合に、信号（内部変数）は、プロセスによって生成された力に関する情報を含む。幾つかのプロセスの例は機械加工、研削、形成および射出形成である。この信号は、機械に関するプロセスおよび他のコンポーネントによって生じる幾つかのコンポーネントを含んでいる。機械に関する力は摩擦、慣性、重力、ひずみ／コンプライアンスの幾つかのあらわれおよび機械的な共振によるものである。内部コントロール変数に基づいてプロセスフォースの高い忠実度を得るために、機械による作用が検出され、プロセスによる作用と分けられなければならない。本発明において説明される信号処理ネットワークは、このために使用される。ＳＰＮは、プロセスに関する力と機械に関する力との間の妥協を区別することができる状況を検出するためにも使用される。モーションコントロールアクチュエータおよび駆動機械システムのダイナミック特性は異なる機械設計によって大きく異なるので、再構築可能な信号処理ネットワークのための一般的な機構が有利である。このようなネットワークからのアウトプットは、プロセスフォースのための見積もりである。この見積もりの妥当性の信用性における評価を示す補助的なアウトプットも可能である。ＳＰＮのこのアプリケーションは一般的に、「信号補正（signal correction）」と称されている。なぜならこれは、内部変数を補正し、プロセスフォースをあらわすその能力を改善するからである。信号補正からのアウトプットは、幾つかのプロセス監視タスクによって使用される信号である。プロセス監視タスクの幾つかの例は：
・プロセスが所定の操作領域から逸脱したことによるアラーム
・所定の領域内にプロセスを維持するための、コマンド変数を変えることによるプロセスコントロール、および
・プロセスエンジニアによる、より良い理解のためのプロセス測定

故障検出
可動部分を有する機械は様々に故障する恐れがある。幾つかの例はベアリング故障、ドライブトレーンコンポーネントのせん断故障、ベルト破損、結合スリップおよび機械の幾つかのパーツが環境または機械自体のパーツと衝突することである。これらの故障の全てはほぼ瞬間的に起こるイベントである。機械がモーションコントローラによってコントロールされる場合、監視特徴を伴うコントロール機能を促進することによって、瞬間的な故障を検出する機会が生じる。監視は、内部駆動変数または外部センサ（例えば加速度計）から得られた処理信号によって行われる。突発的な大変動による故障を瞬時に検出するのには、使用可能な信号のリアルタイム監視および適切な方程式、フィルター、変換、スレッショルドチェック等による信号の処理が必要であり、これによって、生じ得る故障モードに相応する署名が識別される。このような場合には、故障識別のための署名は、故障モードおよび機械の構造および機械のタイプに強く依存している。従って高いレベルの柔軟性がＳＰＮによって提供され、これはこのようなアプリケーションにとって非常に有利である。

逆に言えば、データの長期間の傾向に基づいて故障の漸次的な開始を予測することを試みるシステムは、リアルタイム環境における著名検出のために必要とされる処理の実施を必要としない。このようなケースでは、後で行われる後処理のためにデータベースへ生信号が集められる。故障に即時性がない場合には、長期間（非リアルタイム）にわたって得られるデータレコードの収集に用いられる信号処理のための種々のアルゴリズムをテストする機会が得られる。これはオフライン環境において展開されるので、このような場合にはＳＰＮは依然として有利である。ＳＰＮはオフラインで使用され、生の測定値が、機械コンポーネントの漸次的な退化を示す変数とより密接に関係するデータへ変換される。

オフライン展開およびオンライン展開は、故障検出ネットワークをインストールすることによって組み合わされる。ここでこの故障検出ネットワークは、高い感性を有しており、しばしば誤ったアラームを生成することが見込まれている。このような使用ケースでは、アラーム状態の結果は、まさにデータ収集バッファのストレージをトリガさせる。このバッファは、機械の通常作動中に定期的にアップデートされる。データ収集バッファは生信号の適切なセットを含む。データレコードにはその後、手動で、実際の故障かまたは誤ったアラームかのどちらかをあらわしているとして、フラグがセットされる。次に、全てのレコードがネットワークを設計することを目的にして、候補である信号処理ネットワークを通じて運ばれる。この信号処理ネットワークは、検出感度と誤ったアラームに対する免疫との間の折り合いを最適化する。

サーボコントロール
サーボコントロールは、機械の幾つかの可動部分の位置、速度および加速度を調整するために使用される方法に関する。サーボコントロールの主な機能は、外乱力を拒否し、コマンド軌道を追跡することである。外乱は、センサからの位置、速度および加速度に対する１つまたは複数の状態変数のフィードバック手段によって拒否される。センサ信号は、これらの測定に応じた、アクチュエータ（例えば電動部）へのコマンドの開発において使用される。軌跡追跡はフィードバックコントロールによっても行われる。しかし、フィードフォワードコントロールによるフィードバックコントロールの促進は、追跡能力を改善するための通常の手法である。フィードフォワードコントロールは、設定値軌跡にのみ基づいてアクチュエータコマンドを開発する。

市販されているコントローラは、速度コントロールおよび位置コントロールのための、制限された数の使用可能なコントローラトポロジーを有する。通常のトポロジーはカスケード接続されたコントロールであり、ここでは速度コントロールループは、位置コントロールループ内に入れ子状に納められている。このトポロジー内で、固定されたインプットおよびアウトプットを伴う種々の計算ブロックは、利得、フィルター、基準モデルおよびフィードフォワードコントローラのために設けられている。多くの機械に対して、制限された数の固定されたトポロジーおよびフィルタータイプによって提供される柔軟性は充分である。なぜなら機械は動的特性の特定の領域に適合しており、事前に構成されたトポロジーは効果的なコントロールを行う能力があるからである。このような場合には、セットアップエンジニアまたは技術者が、使用可能な展開能力を選択することによって、機械を「調整し」、最適化された数値のセットによってこれらのフィルターを構築する責任を有している。

ＳＰＮは、コントロール理論において有能なセットアップエンジニアがカスタマイズされたフィードバックおよび／またはフィードフォワードコントローラを設計することを可能にする。コントローラは独自のトポロジーを有しており、これはセットアップエンジニアの発明である。このトポロジーは、その動的特性が、標準のコントロールソフトウェアによって提供された事前に構築されたトポロジーの有限セットのうちの１つによって最適に補償されていない機械のために特別に設計される。構築可能な信号処理ネットワークによって、このエンジニアは、あらゆるソフトウェアの開発を必要とすることなく、コントローラを指定することができる。このようにして、最適化されたコントローラが、その設計が、測定に基づいたスポット上に開発された機械ダイナミック特性モデルに基づいている機械で開発される。本発明は、信号処理ネットワークのための定義データを生成するためにグラフィックソフトウェアツールを使用することを可能にする。このようなソフトウェアツールは、ＳＰＵをあらわすブロックを選択および配置するためにマウスを使用すること、およびブロック間の信号の流れをあらわす線をルーティングすることを含む。このＳＰＵブロックは、パラメータ変数の入力のために入力領域を提供する。ＳＰＮは、サーボコントロールアプリケーションに対して特別のＳＰＵタイプを提供する。これらのＳＰＵタイプによって、信号処理ネットワークは、コントロールシステムのフィードバックおよびフィードフォワード経路において位置、加速度およびトルク設定値をオフセットするおよび／または上書きすることができる。

シミュレーション
シミュレーションは、非リアルタイム環境におけるモーションコントロールまたはＣＮＣシステムに対する全ソフトウェアセットの実行に関連して、モーションコントロールプログラムに応答した、システムの事前テストの目的で使用される。例えば、ＣＮＣコントロールの場合には、シミュレーションによって、ＮＣプログラムが製作品で正しいゲオメトリーを形成することが検証される。幾つかのケースでは、シミュレーションの忠実度は、コントローラおよび駆動機械システムのダイナミック特性の影響を含むことによって改善される。これは、ＳＰＮが使用される場合においてである。１つの実施例では、ＳＰＮはそのインプットとして速度設定値を用いる。この速度設定値は位置コントローラから速度コントローラへルーティングされる。このネットワークの役割は、速度コントローラ、モータおよび機械のダイナミック特性をシミュレートすることである。この実施例では、ＳＰＮのアウトプットは、位置フィードバックセンサからのアウトプットの見積もりである。位置フィードバックの見積もられた値はその後、標準のコントロールシステムソフトウェアの内蔵された位置コントローラへルーティングされる。これによって、コントロール上に構築された通常の位置コントロールアルゴリズムは、このシミュレートされたフィードバックに手を加えることができる。信号処理ネットワークからの付加的なアウトプットは、機械加工された表面のゲオメトリーのモデリングにおいて使用された機械の動作点の位置に対する見積もりである。先行の実施例では信号処理ネットワークは、速度コントロール、電流コントロールおよび機械システムのダイナミック特性をシミュレートする。またこれによって本来の位置コントローラソフトウェアは、通常の機械上でのように作動することができる。他のシミュレーションシナリオも理解される。例えば、ＳＰＮはインプットとして位置コマンド軌跡を用い、位置コントローラのシミュレーションを含む。別の明示は、内蔵型速度コントロールからの目下の設定値を伴うＳＰＮを提供することであり、ＳＰＮの役割は、電流コントローラ、モータ、および駆動機械システムのダイナミック特性をシミュレートすることである。ここではＳＰＮアウトプットはモータ速度および直接的なエンコーダ位置である。

この明細書に記載されている多くのコンセプトは、Ｓｉｎｕｍｅｒｉｋ８４０Ｄ用のコンパイルサイクルの枠組みにおいて、Ｃ＋＋ソフトウェアによって実行される。ＳＰＮインプリメンテーションは、プロセス監視および故障検出アプリケーションのための基礎的な機能を提供する環境の一部である。

オブジェクト指向設計
上述のように、信号処理ネットワーク（ＳＰＮ）は、コネクションによってあらわされる、ＳＰＵ間の信号ルーティングを伴う複数の信号処理ユニット（ＳＰＵ’ｓ）から成る。これらのコンセプトの各々は、オブジェクト指向設計の原理を用いてあらわされる。これらのコンセプトをグラフィックにあらわすために、統一モデリング言語（Unified Modeling Language :UML）が使用される。ＵＭＬの記述は一般的な知識である。ＵＭＬクラス図を熟知していることが、この開示における図面を正確に理解するのに必要である。

図１を参照されたい。ＵＭＬクラス図が、ＳＰＮにおける使用のために定義されたクラス間の関係をあらわしている。このダイヤグラムは非常に多くの量の情報を含んでおり、コンセプトを組織化する１つの有利な方法を記述している。このダイヤグラムにおける各エレメントに対する記述および説明をここで行う。

ＳｐｕＮｅｔｗｏｒｋ
クラス図のハイレベル概要は、クラスＳｐｕＮｅｔｗｏｒｋの検査から始まる。ＳＰＵのネットワークの中心的なコンセプトは、クラスＳｐｕＮｅｔｗｏｒｋによってあらわされる。このダイヤグラムは、ＳｐｕＮｅｔｗｏｒｋのインスタンスがどのように、ＳｐｕＬｉｓｔにおけるクラスＳｐｕＢａｓｅの幾つかのオブジェクトおよび、ｃｎｃｔＬｉｓｔと称されるリスト内のクラスＣｏｎｎｅｃｔｉｏｎの幾つかのオブジェクトを含むかを示している。ＳｐｕＢａｓｅは純粋なバーチャルクラスであり、正確に、図の底部近辺に示されている、導出されたＳＰＵｘｘｘｘクラスのいずれかによってあらわされる。ＳｐｕＮｅｔｗｏｒｋは、ＳＰＵオブジェクトに対するリファレンスのリストｅｘｅｃＬｉｓｔも含む。これは実行リストをあらわす。計算が実行される順番は、このｅｘｅｃＬｉｓｔ内でＳＰＵが参照される順番である。ＳｐｕＮｅｔｗｏｒｋはｎｅｔｗｏｒｋＩｎｐｕｔおよびｎｅｔｏｗｏｒｋＯｕｔｐｕｔに対するリファレンスのアレイも含む。これらのリファレンスは特定の導出されたＳＰＵタイプに向かう。これは必要なインプットおよび提供されているアウトプットをあらわす。ｎｅｔｗｏｒｋＩｎｐｕｔのリストは、ＳｉｇｎａｌＤｉｓｐｅｎｓｅｒと称される基本的なソフトウェアのコンポーネントからサービスを要求するために使用される。ＳｐｕＮｅｔｗｏｒｋは、ネットワーク内のＳｐｕＩｎｐｕｔのインスタンスに基づいてＳｉｇｎａｌＤｉｓｐｅｎｓｅｒからの全ての必要な信号／軸の組み合わせを登録する。ＳｉｇｎａｌＤｉｓｐｅｎｓｅｒは、周期的な軸コントロールプロセスの間、その登録された１つ／複数の信号に対する値を検索および保護する。ｎｅｔｏｗｏｒｋＯｕｔｐｕｔリストはＳｐｕＮｅｔｗｏｒｋによって、潜在的なクライアントへネットワーク能力を報告するのに使用される。これは重要である。なぜなら、複数のネットワークはそれぞれ異なった役割を担っており、同時にコントロールに基づいてインスタンス化されるからである。プロセス監視の場合には、監視アルゴリズムは特定の軸／信号の組み合わせを、監視の基礎として要求する。

ＳｐｕＮｅｔｗｏｒｋはコントロールに基づいて時間的に重要でないバックグラウンドプロセスの間に構築される。ネットワークは、データフォーマットを構文解析することによって構築される。このフォーマットは、ＡＣＸとして知られているＸＭＬのバイナリー表示である。従って、これはＡＣＸＦｉｌｅからクラスを受け継ぐ。このクラスはイベントベース構文解析系（ｅｖｅｎｔ−ｂａｓｅｄ ｐａｒｓｅｒ）と称される。データ構文解析の詳細は後述する。ＳＰＵのインスタンスおよびコネクションは、データ構文解析の間に開発され、フラットリスト内に格納される。ＳＰＵＮｅｔｗｏｒｋのｂｉｎｄＮｅｔｗｏｒｋ（）方法は、定義データの全てのコンテンツが、エラー状態にぶつかることなく構文解析された後で、バックグラウンドプロセスから呼び出される。ｂｉｎｄＮｅｔｗｏｒｋ（）の１つの目的は、適切なＳＰＵオブジェクトにコネクションオブジェクトを取り付けること、およびコネクションオブジェクトを案内し、浮動少数点数に対する基準を定めることである。ここでこの浮動少数点数は、行先ＳＰＵへのインプットとして用いられるソースＳＰＵからの出力値として作動する。ＳＰＵオブジェクトは自身のアウトプットのために値メンバデータを含み、そのインプットとして用いられている他のＳＰＵからのアウトプットに向けるために、リファレンスメンバデータを含んでいる。ｂｉｎｄＮｅｔｗｏｒｋ（）の間に生じるエラー状態はバインドエラーを生じさせ、適切な診断情報が診断データストレージへ報告される。ｂｉｎｄＮｅｔｗｏｒｋ（）の間に生じる可能性のあるエラー状態の例は、疎接続、要求されているコネクションの無いＳＰＵインプットまたはアウトプット、１つのＳＰＵインプットコネクションに対する無効なマルチプルアタッチメント等である。バインドプロセスの間に、ＳＰＵＢａｓｅから導出されたクラスの各インスタンスはそのｂｉｎｄ（）方法を呼び出す。ｂｉｎｄ（）方法は各ＳＰＵオブジェクトに、インプットおよびアウトプットコネクションが、予期されているコネクションの数に相応して存在することを検証する機会を与える。各ＳＰＵＢａｓｅの導出されたオブジェクトは、方法であるｇｅｔｐＩｎｐｕｔ（）およびｇｅｔＯｕｔｐｕｔ（）を提供するためにも必要とされる。これらの方法はレファレンスを、別のＳＰＵインプットによって保持されている、あるＳＰＵアウトプットに配置（populate）するのに使用される。コネクションが案内されると、これらはもはやネットワークによって必要とされない。時間的に重要でない周期的なプロセスに対するデータフローは、ＳＰＵのインプットリファレンスをデレファレンスすることによって構築される。これはコネクションを案内することよりも、計算においてより効率的である。

機能ｂｕｉｌｄＥｘｅｃＬｉｓｔ（）は、ｂｉｎｄＮｅｔｗｏｒｋ（）に対する呼び出しが成功した後にバックグラウンドプロセスから呼び出される、ＳＰＵＮｅｔｗｏｒｋの別の方法である。ｂｕｉｌｄＥｘｅｃＬｉｓｔ（）方法はネットワークｓｐｕＬｉｓｔ内のインスタンスを、実行の優先順位で配列する。これは、各ＳＰＵに取り付けられている優先特性の評価および優先順位でのＳＰＵの格納によって行われ得る。同じ優先レベルを共有するＳＰＵが、ＳＰＵリスト内にあらわれた順番で実行リストに加えられる。択一的に、優先順位は、ネットワークアウトプットで始まり、ＳＰＵアウトプットからＳＰＵインプットへコネクションを逆に案内することによって、ブロック間の依存性を帰納的に定めることによって自動的に作成される。

周期的な時間的に重要なプロセスの間に、ＳＰＵＮｅｔｗｏｒｋのｅｘｅｃｕｔｅ（）方法に対する呼び出しを介してネットワークが実行される。この方法は単にｅｘｅｃＬｉｓｔ内を循環し、各ＳＰＵインスタンスのｅｘｅｃｕｔｅ（）方法を呼び出す。各ＳＰＵのｅｘｅｃｕｔｅ（）方法はその後、そのインプットをデレファレンスし、インプットの組み合わせに基づいて適切な方程式／ロジックを実行し、ＳＰＵのアウトプットに結果を組み込む。従ってこれは、インプット値に対するこのデータアイテムに依存する他のＳＰＵによって使用される。

ベースソフトウェアに対するインターフェース
ＳｐｕＮｅｔｗｏｒｋとモーションコントロールシステムの残りの部分との間のインターフェースはＳｉｇｎａｌＤｉｓｐｅｎｓｅｒ、ＳｐＣｏｎｔａｉｎｅｒＢａｓｅおよびＡＣＸＦｉｌｅから成る。ＳｐＣｏｎｔａｉｎｅｒＢａｓｅは純粋なバーチャルクラスであり、その役割は、信号処理オブジェクトに対する収容部として作動することである。ＳｐＣｏｎｔａｉｎｅｒＢａｓｅインターフェースは、監視／コントロールおよびシミュレーションアプリケーションに対する信号処理要求の実施に対する能力のセットをあらわす。ＳｐＣｏｎｔａｉｎｅｒオブジェクトは、インターフェース方法を実行する。ここでこのインターフェース方法は主に：ｒｅＳｃａｎＡｃｘＦｉｌｅｓ（）、ｃｈｅｃｋＦｏｒＳＰ（）およびｅｘｅｃｕｔｅ（）を含む。

ＳｐＣｏｎｔａｉｎｅｒの方法ｒｅＳｃａｎＡｃｘＦｉｌｅｓ（）はバッグラウンドプロセスから呼び出され、信号処理に関連付けられた全ての定義データの構文解析を命じる。この方法の結果は、ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅから派生した幾つかの信号処理オブジェクトの具体化（例示：instantiation）である。柔軟であるので、ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅから派生した主要なクラスはＳｐｕＮｅｔｗｏｒｋである。それにもかかわらず、そのトポロジーおよび方程式が専有の目的のために固定されている他のクラスを導き出すことも可能である。ここではパラメータ化のみが定義データにおいて指定される。柔軟性のために自動的に生成されたコードまたは幾つかの他のメカニズムを使用する付加的なクラスをＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅから導き出すことも可能である。ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅオブジェクトの生成への各試みの結果として、診断データアウトプットが得られる。これは試みの成功を記述し、構文解析の間に起こり得るあらゆる問題の診断に対する情報を提供する。ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅから導出されたオブジェクトのインスタンスは、ＳＰＣｏｎｔａｉｎｅｒのメンバデータとして存在する。ＳＰＣｏｎｔａｉｎｅｒによって実行される方法ｃｈｅｃｋＦｏｒＳＰ（）は、ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅから導出されたオブジェクトの全てのインスタンスのリストを、信号タイプ／タイプおよび機械軸の提出された要求に一致するもののために検索する。一致するものが見つかった場合、ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅのクライアントリストが増やされ、独自のキーが返還される。ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅのインスタンスが作成されると、これらはベースソフトウェアから中央サービスへのポインタを介した、提供されたアクセスとなる：ＳｉｇｎａｌＤｉｓｐｅｎｓｅｒ。ＳｉｇｎａｌＤｉｓｐｅｎｓｅｒは２つの目的を提供する：１．ベースシステムからの要求された信号を伴う信号処理部を提供する。２．信号処理の結果に対する収納場所を提供する。収納場所としての役割において、信号ディスペンサーはネットワークアウトプットを信号トレースに割り当てるためのインターフェース、シミュレーション目的のために目下の値を上書きする方法、およびサーボコントロール目的のためにコントロールアウトプットを上書きするまたは促進する方法を提供する。ＳＰＣｏｎｔａｉｎｅｒのｅｘｅｃｕｔｅ（）方法は周期的に、時間臨界的な優先順位の高い周期的なプロセスの間に、ベースシステムによって呼び出される。このコンテナはその後、その全ＳｉｇＰｒｏｃｅｓｓｏｒＢａｓｅオブジェクトのｅｘｅｃｕｔｅ（）方法を呼び出す。ベースシステムに対する最終的なインターフェースは、ＡｃｘＦｉｌｅからのＳＰＣｏｎｔａｉｎｅｒを受け継ぐことによって提供される。ＡｃｘＦｉｌｅクラスは、コントロールのファイルシステムからの選択されたデータレコードを開け、このデータの構文解析を始めるためのインターフェースを提供する。構文解析の間に、ｓｔｒａｔＴａｇ（）、ｅｎｄＴａｇ（）、ｈａｎｄｌｅＤａｔａ（）等のイベントは構文解析系によって引き起こされ、これらの各方法の実行は導出されたクラスにおいて、この情報によって何が行われるべきかを定める。データの構文解析の間に使用される幾つかのストラテジーおよびＡＣＸデータの組織化については以降で述べる。

ＳＰＵＢａｓｅ Ｉ コネクション
ＳＰＵネットワークにおける中心的なオブジェクトはＳＰＵＢａｓｅである。これは、純粋なバーチャル方法に加えて幾つかの非バーチャル方法を供給する純粋なバーチャルクラスである。このクラスのこれらのコンテンツの多くは、ＳＰＵＮｅｔｗｏｒｋのトピックスにおいて既に論議されている。ＳＰＵの各インスタンスは、ネットワークコンストラクションの間、ＳＰＵを識別する目的で独自のＩＤを含むことが必要とされる。ＩＤの独自性はデータの構文解析の間、強制される。ＳＰＵの各インスタンスは、ＳＰＵの幾つかのアウトプットに対してゼロを保持するための実際に値が付けられた数（アウトプット）のアレイを含んでいる。アレイのサイズは、ＳＰＵタイプに依存して変化する。ＳＰＵは、実際に値が付けられた数（インプット）のポインタのアレイも含んでいる。これは、最終的には、目下のＳＰＵへのインプットを提供する他のＳＰＵからのアウトプットに向かう。インプットアレイのサイズも、ＳＰＵタイプに依存して変化する。ＳＰＵは、パラメータオブジェクトのゼロまたはより多くのインスタンスも含んでいる。パラメータオブジェクトの数およびコンテンツはＳＰＵの具体的なタイプに依存する。パラメータオブジェクトはデータ構文解析の間に構築される。なぜなら、複数のパラメータの存在は定義（ＡＣＸ）データ内で衝突するからである。ＡＣＸデータで示されるパラメータのリストが空になると、具体的なＳＰＵのｉｎｔｅｒｐｒｅｔＰａｒａｍｓ（）方法が呼び出され、見つけられたパラメータが可変タイプ、パラメータの数、パラメータの用法、および値の範囲の項において予期されているものと適合するかがチェックされる。パラメータが予期されているものである場合、各具体的なＳＰＵに対するｉｎｔｅｒｐｒｅｔＰａｒａｍｓ（）がパラメータオブジェクトから、自身のメンバデータ内に、その方法ｂｉｎｄ（）およびｅｘｅｃｕｔｅ（）の実行の間の使用のために、値をコピーする。パラメータメンバデータ：「使用(usage)」は導出されたＳＰＵクラスにおけるその使用に関する各パラメータを列挙する。パラメータは可変タイプの値を含む：これは例えばｄｏｕｂｌｅ，ｉｎｔ，ｃｈａｒ等である。ＵＭＬクラス図は、ＳｐｕＢａｓｅとＳｐｕｎｅｔｗｏｒｋの間の受け継ぎ関係を示す。ここでＳｐｕＮｅｔｗｏｒｋはＳｐｕＢａｓｅの１つの種類である。ＳｐｕＢａｓｅインスタンスに対するこのような関係によって、全体的な入れ子状のＳｐｕＮｅｔｏｗｒｋが組み込まれ、そのインプットアウトプット特性を、単独の具体的なＳＰＵを扱うのと同じ方法で扱うことができる。ＳＰＵが含まれているネットワークのコンテキストにおいてこれは他の具体的なＳＰＵとして動作する。ネットワークであるＳｐｕＢａｓｅインスタンスのＩＤがそのネットワークのコンテキスト内で独自である場合には、サブネットワーク内に含まれているＳＰＵオブジェクトのＩＤは異なるコンテキストレベルでのＳＰＵオブジェクトに関して独自である必要がない。このようなメカニズムによって、限界の無い入れ子レベルが可能になる。このような配置の１つの利点は、特定のインプットアウトプット関係をあらわすサブネットワークが、より多くの基本的なＳＰＵから事前に構築されることである。ここでこれらのＳＰＵは、必要である場合にネットワーク内に含まれる。

ＳｐｕＢａｓｅもコネクションオブジェクトのリストを含む：これはｉｎｐｕｔｓＬｉｓｔおよびｏｕｔｓｐｕｔｓＬｉｓｔである。各コネクションオブジェクトはそのソースおよび行先に関する情報を有しており、データフローチャネルをあらわす。各コネクションは、ＳＰＵに対する独自の整数ＩＤを用いてそのソースＳＰＵを識別し、ソースアウトプットポートアウトポートを識別する。ここでこのソースアウトプットポートアウトポートは、参照されるＳＰＵからの使用可能なアウトプットを識別する。多数のアウトプットを有するＳＰＵの場合には、アウトプット数は特定の種類の情報にあてはまる。ＳＰＵの具体的なタイプのコンテキストにおいて、より直接的にアウトプットポートの役割を識別する調査部（enumerator）またはストリングとのコネクションが提供されることによって、このアウトプット数は間接的に言及される。各コネクションオブジェクトは行先ＳＰＵの独自のＩＤおよびインプットポートの数も含む：コネクションが取り付けられるべき行先ＳＰＵ上へのインポートである。アウトポートとともに、各ナンバリングされたインポートは特定の種類の信号を含む。ここでこの信号は具体的なＳＰＵによって独自に解釈される。インポートはストリングまたは列挙を用いて言及される。これはより明確に、コネクションが取り付けられるインプットの使用を識別する。ＳＰＵの構文解析およびコネクションは独立して行われる。ここでは定義データにおけるＳＰＵおよび／またはコネクションの相対的な発生は、ネットワークトポロジーまたはコネクションマッピングを定める構文解析系の能力には打撃を与えない。ネットワークにおける全てのオブジェクトの後：ＳＰＵおよびコネクションが具体化され、ＳｐｕＮｅｔｗｏｒｋのｂｉｎｄＮｅｔｗｏｒｋ（）方法の実行中にネットワークが構築される。第１のステップは、ＳＰＵのインプットおよびアウトプットに割り当てられたコネクションを見つけることである。この第１のステップの間に、ＳＰＵのメンバｏｕｔｐｕｔＬｉｓｔおよびｉｎｐｕｔＬｉｓｔが埋められる。同時にコネクションのｍｙＯｕｔｐｕｔおよびＳＰＵへのｍｙｉｎｐｕｔポインタが確立される。この段階で、コネクションのデータがＳＰＵ／ポート組み合わせへ分解されない場合には、エラー状態が生じ、ＳＰＵネットワークの構築が失敗する。例えば、２つの別個のコネクションが同じ行先ＳＰＵおよび「ｉｎｐｏｒｔ」を有している場合には、エラー状態が検出され、診断アウトプットデータ内に示される。逆に言えば、２つの別個のコネクションは、同じソースＳＰＵおよびアウトプットに適切に取り付けられ、これは単純に、ネットワーク内の分岐またはブランチを意味する。ＳＰＵとそのコネクションの間の関係が確立された後、ｂｉｎｄＮｅｔｗｏｒｋ（）内の第２のステップは各ＳＰＵのｂｉｎｄ（）方法を呼び出し、これによって、これは要求されたコネクションが存在するのかがチェックされ、他の情報を伴うコネクションが例えばパラメータから導出されることが検証される。この時点で、１つまたは複数の他のＳＰＵからのアウトプットへの１つのＳＰＵのインプットのリファレンスが、ソースＳＰＵのｇｅｔｐＯｕｔｐｕｔ（）方法が呼び出されることによって解決される。これは、行先ＳＰＵによって保持されている種々のコネクションを案内することによって行われる。このプロセスの終了時には、コネクションはその目的を提供し、ダイナミックメモリを維持するためにネットワークから削除される。

付加的に、各クラス：ＳＰＣｏｎｔａｉｎｅｒ、ＳＰＵＮｅｔｗｏｒｋ、Ｐａｒａｍｅｔｅｒ、ＳｐｕＢａｓｅおよびＣｏｎｎｅｃｔｉｏｎは全て、クラスＡｃｘＦｉｌｅから導出される。これは定義データ（ＡＣＸ）の構文解析に適合する。後述されるように、ＡＣＸデータは階層的に組織化され（ＸＭＬの典型）、定義フォーマット内のデータのロケーションのコンテキストは、その構文解析方法（例えばｓｔａｒｔＴａｇ（）、ｅｎｄＴａｇ（）等）がイベントベース構文解析系によって呼び出されたオブジェクトに直接的に関する。

データフォーマットおよび構文解析
信号処理ネットワークの定義は、そのフォーマットがＡＣＸとして知られているデータ定義で保存される。しかしＡＣＸは、Ｓｉｅｍｅｎｓ社によって提供されている所有権を主張できるバイナリフォーマットに限定されない。構造はＸＭＬに密接に関連している。ＸＭＬのように、ＡＣＸはコンテンツを区切るためにタグを用いる。コンテンツはシンプルまたは複合的である。シンプルなコンテンツの場合には、データタイプは属性として指定される。Ｓｉｅｍｅｎｓ社は、ＸＭＬからＡＣＸおよびＡＣＸからＸＭＬへの変換のために変換ツールを提供している。明確にするために、データのＸＭＬ表示は、データフォーマットおよび信号処理ネットワーク定義に対する構文解析に関する本論議の焦点である。

図１を参照すると、幾つかのクラスは純粋なバーチャルインターフェースからＡｃｘＦｉｌｅを受け継ぐ。これらのクラスは封じ込めヒエラルキーを形成し、最も外側のクラスから始まる以下のリストによって示される。含まれているオブジェクトの複数のインスタンスは、そのロケーションが、以下のスキーマに相応して可能であると指定されている間は可能である（同じレベルにあるクラスはあらゆる順番であらわれる）。

ＡＣＸデータの構文解析は、ベースソフトウェアがデータロケーションの標識（例えば名前が付けられたファイルにおいて）およびリファレンスを、ＡｃｘＦｉｌｅのインターフェースを実行するトップレベルオブジェクトへ通過することによって始まる。データが構文解析されると、ｓｔａｒｔ Ｔａｇ（）、ｅｎｄＴａｇ（）、ｈａｎｄｌｅＤａｔａ（）、ｈａｎｄｌｅＳｔｒｉｎｇＤａｔａ（）に対するイベントコールバックが、トップレベルオブジェクトに基づいて呼び出される。方法ｓｔａｒｔＴａｇ（）は、新たなタグと出会う度に呼び出され、タグネームの列挙が提供される。方法ｅｎｄＴａｇ（）は、新たなエンドタグと出会う度に呼び出され、これはタグネームに対する調査部を通過することもできる。方法ｈａｎｄｌｅＤａｔａ（）は、構文解析系がシンプルなコンテンツデータと出会う度に呼び出される。ＨａｎｄｌｅＤａｔａ（）はデータタイプに対する引き数および値を含んでいる合併引き数とともに呼び出される。データタイプがストリングである場合には、ｈａｎｄｌｅＳｔｒｉｎｇＤａｔａ（）が呼び出される。

信号処理ネットワークの場合には、トップレベルオブジェクトはＳＰＣｏｎｔａｉｎｅｒであってよい。この場合にはＳＰＣｏｎｔａｉｎｅｒは、これらのイベントの各々に応じて、何を行うのかを決める。構文解析の間、封じ込めヒエラルキー内のクラスの各タイプは、封じ込めヒエラルキーの瞬間的なコンテキストをあらわすスタックオブジェクトを維持することによって、構文解析コンテキストのトラックを保持する。オブジェクトスタックはおおよそ、ＸＭＬコンプレックスコンテンツにおいてコンテキストをあらわすタグのスタックに相応する。構文解析の間、ｓｔａｒｔＴａｇ（）、ｅｎｄＴａｇ（）およびｈａｎｄｌｅＤａｔａ（）のための方法がコンテキストスタックの頂上部でのオブジェクトのために呼び出される。ｓｔａｒｔＴａｇ（）方法の実施中、コンテキストスタックは潜在的に、スタックの頂上部にプッシュされる新たなオブジェクトを有している。ｅｎｄＴａｇ（）方法の実施中、コンテキストスタックは潜在的にスタックから外されるトップオブジェクトを有している。スキーマチェックは構文解析の間も実施され、ＸＭＬフォーマットの要求に応じて、スタートタグが予期されているように配置されていることが確実にされる。エラー状態が起こると、ｅｒｒｏｒＩｎｆｏオブジェクトが、診断アウトプットとして後に報告される情報によってアップデートされる。信号エラーが生じると、ＳＰＣｏｎｔａｉｎｅｒのコンテンツを構文解析する成功した試みが無視され、ＳＰＣｏｎｔａｉｎｅｒ内で起こったこの第１のエラー状態がｅｒｒｏｒｉｎｆｏ内に記入される。ＸＭＬコンテンツが新たなオブジェクトを具体化する必要を示すと、ダイナミックメモリ管理が用いられて、オブジェクトの要求されたインスタンスが構築される。オブジェクトが導出されたタイプのＳｐｕＢａｓｅである場合、ＳｐｕＦａｃｔｏｉｙオブジェクトが呼び出されて、ＳＰＵのインスタンスが構築される。そのタイプはＸＭＬのコンテンツに相応に指定されている。ＳｐｕＦａｃｔｏｒｙはポインタをタイプＳｐｕＢａｓｅのオブジェクトへ返還する。ここでこのポインタはＳｐｕＮｅｔｗｏｒｋのコンテキストスタックの頂上部にプッシュされ、ファイル構文解析のためのＳｐｕＮｅｔｗｏｒｋの方法の成功した呼出しが、ＳｐｕＢａｓｅの相応する方法へ再び向けられる。

ＳＰＵ導出タイプの部分的なリスト
図１を参照すると、低い部分はＳＰＵＢａｓｅから導出された幾つかのクラスを示している。これは具体的なＳＰＵの部分的なリストをあらわす。オブジェクト指向の設計によって、幾つかの使用可能なＳＰＵが最小限の努力で拡張される。新たなＳＰＵ導出クラスを作成するプロセスは、パターンクラスのコンテンツ内を、新たなＳＰＵタイプの目的に特有の要求で満たすことを必要とする。部分Ｂ内に概略が示された幾つかのアプリケーションのために開発された幾つかのＳＰＵタイプの部分的なリストがここに存在する。各ＳＰＵの実装の詳細は要求に応じて提供される。

ＳｐｕＩｎｐｕｔ
ＳｐｕＩｎｐｕｔ ＳＰＵはベースコントロールからの入力信号を示す。このブロックは信号タイプに対する具体化列挙および機械軸のインデックスによってパラメータ化される。この機械軸から信号が検索される。ＳＰＵは複数のゼロインプットと１つのアウトプットを有している。列挙される幾つかの信号タイプは例えば以下のものであるが、これに限定されない：
・位置設定値およびその誘導物
・モータでの位置実際値
・直接的な測定システムでの位置実際値
・速度ループへの速度設定値
・速度フィードフォワード
・トルクフィードフォワード
・電流コントロールへのトルク設定値
・電流実際値を形成するトルク
・モータ速度の実際値
・駆動パワー
・Ａ／Ｄ変換器からの値

ＳｐｕＭｏｎＯｕｔ
ＳｐｕＭｏｎＯｕｔ ＳＰＵはＳＰＵＮｅｔｗｏｒｋからのアウトプットノードをあらわす。このアウトプットノードの目的は、アプリケーションを監視することによって使用される信号を提供することである。１つの実施形態では、監視アプリケーションはより低い率の周期的なプロセスで作動し、このネットワークのアウトプットのコンテンツは監視タスクへ運ばれる。これはアウトプット信号を内部プロセスコミュニケーションバッファ内に配置することによって行われる。このバッファで、このより低い率のプロセスは、結果を検索し、使用することができる。ＳｐｕＭｏｎＯｕｔは１つのインプットを有しており、これは信号値とゼロアウトプットをあらわす。これは軸の数および信号タイプによってパラメータ化される。使用可能な信号タイプは、ＳＰＵＩｎｐｕｔのもとでリストアップされたそれと比較可能である。この場合には、信号コンテンツが、ＳＰＵＮｅｔｗｏｒｋによって実行される軸ダイナミック特性に対するモデルによって影響されることが予期される。

ＳｐｕＣｔｒｌＯｕｔ
ＳｐｕＣｔｒｌＯｕｔ ＳＰＵは、ＳＰＵＮｅｔｗｏｒｋが実行されるときに、軸／サーボコントロールに影響を与えるために使用される。ＳｐｕＣｔｒｌＯｕｔは１つのインプットを有しており、このインプットはシステム位置および／または速度コントローラにおけるコントロール信号へ、ＳｉｇｎａｌＤｉｓｐｅｎｓｅｒからのサービスによってルーティングされる。ＳｐｕＣｔｒｌＯｕｔは軸およびコントロール信号の列挙によってパラメータ化される。コントロール信号の幾つかの例を以下にリストアップする。
・位置コマンドオフセット
・位置コマンド
・速度フィードフォワード
・速度フィードフォワードオフセット
・速度コマンド
・速度コマンドオフセット
・トルクフィードフォワード
・トルクフィードフォワードオフセット
・速度コントローラ比例利得
・速度コントローラ積分時定数

ＳｐｕＳｉｍＯｕｔ
ＳｐｕＳｉｍＯｕｔ ＳＰＵは、コントローラのソフトウェアセットがモータ、および／または機械システム、または直接的なフィードバック装置無しで作動する環境におけるフィードバックをシミュレーションする目的で使用される。ＳｐｕＳｉｍＯｕｔは、ＳｐｕＣｔｒｌＯｕｔに非常に類似しており、システムに影響を及ぼすために、ＳｉｇｎａｌＤｉｓｐｅｎｓｅｒからのサービスを要求する。ＳｐｕＳｉｍＯｕｔは１つのインプットを有しており、アウトプットを有しておらず、軸の数およびフィードバックタイプの列挙によってパラメータ化される。フィードバックタイプの幾つかの例を以下にリストアップする。
・モータエンコーダでの位置実際値
・モータでの速度実際値
・直接的な測定システムでの位置実際値
・駆動内部トルクの設定値
・電流を生成する駆動内部トルク

ＳｐｕＳｉｇｇｅｎ
ＳｐｕＳｉｇｇｅｎ ＳＰＵはテストの目的で信号を生成することを可能にする。これは、動的な応答を測定する目的で、電気機械システムを刺激するためにも使用される。ＳｐｕＳｉｇｇｅｎは０または１の入力を取り、波形、振幅の値および周波数の値に対する調査部（ｅｎｕｍｅｒａｔｏｒ）によってパラメータ化される。ＳＰＵに加えられる入力が無い場合、この波形に対する周波数が、目下のパラメータに基づいて開発される。入力がある場合、周波数はこの入力から導出され、ネットワークにおける他の場所から発生する信号によって特定されるように、種々の周波数信号が可能になる。波形に対する幾つかの調査部値は、ＳＩＮＥ、ＳＡＷＴＯＯＴＨ、ＴＲＩＡＮＧＬＥ、ＳＱＵＡＲＥ、ＵＮＩＦＯＲＭ＿ＲＡＮＤＯＭ、ＮＯＲＭＡＬ＿ＲＡＮＤＯＭ等である。

ＳｐｕＭａｔｈ０
ＳｐｕＭａｔｈ０ ＳＰＵはその信号インプットに基づいて信号の数学的な演算を行う。ここでは数学的な演算はいかなるパラメータ化も必要としない（Ｍａｔｈ０は０個の数のパラメータに言及している）。ＳｐｕＭａｔｈ０ブロックは１つの具体化列挙パラメータを用い、実行する数学的演算のタイプを識別する。ゼロパラメータを用いた数学的演算の幾つかの例を以下にリストアップする。
・平方根
・サイン、コサイン、タンジェント、アークサイン
・ｌｏｇｅ、ｌｏｇ１０、ｅｘｐ
・１／ｘ
・導関数、積分
・絶対値

ＳｐｕＭａｔｈ１
ＳｐｕＭａｔｈ１ ＳＰＵはその信号インプットに基づいて信号の数学的な演算を行う。ここでは数学的な演算は１つの数値パラメータを必要とする。ＳｐｕＭａｔｈ１ブロックは具体化列挙パラメータを用い、演算タイプを識別し、数値パラメータを用い、演算をパラメータ化する。演算タイプの幾つかの例を以下にリストアップする。
・倍数的に増加する利得
・付加的なオフセット
・パワー：

・非線形デッドゾーン関数
・非線形飽和関数

ＳｐｕＳｕｍ
ＳｐｕＳｕｍ ＳＰＵは、全ての入力信号の値を加え、合計をアウトプットとして報告する。入力信号の数は制限されていない。オプショナルパラメータは、インポートを指定するために使用される。ここでは信号値は、加算よりも減算されるべきである。このブロックの実行は、リアルタイム計算要求を最小化させる。これは、バックグラウンド非時間臨界的プロセスとしてのブロックネットワークバインドプロセスの間、減算インプットから全ての加算インプットを集め、分離させることによって行われる。このようにして、加算および減算のみが、乗算またはif-then-elseロジック無しに周期的に実行される。

ＳｐｕＰｒｏｄｕｃｔ
ＳｐｕＰｒｏｄｕｃｔ ＳＰＵはインプットの可変数を有しており、単に、全てのインプットを乗算し、アウトプットの値を定める。

ＳｐｕＳｗｉｔｃｈ
ＳｐｕＳｗｉｔｃｈ ＳＰＵは多数のインプット信号から、アウトプット信号として、ＳＰＵを通過するべき１つの信号を選択するメカニズムを提供する。ＳｐｕＳｗｉｔｃｈへの第１のインプット上の信号はセレクターとして扱われる；その値は、どの残存インプット信号がＳＰＵのアウトプットへ通過するかを指示する。ＳｐｕＳｗｉｔｃｈへのインプットの数は可変である：だいたい２ないし制限されていな数のインプットが必要とされる。セレクターとして作動する第１のインプットは、インプット０として指定される。インプット０の値は整数へ切り捨てられる。これは、どの残存インプットが通過するかを示す。切り捨てられるインプット０の値が１より小さい場合、これはインプット１を通過し、この値がインプットの全体数よりも大きい場合、このスイッチは最も大きい数が付されたインプットを通過する。

ＳｐｕＴｄｅｌａｙ
ＳｐｕＴｄｅｌａｙは、幾つかの先行する時間からの入力信号を出力する。ここでは遅延の長さはパラメータとして指定される。ＳｐｕＴｄｅｌａｙは、周期的なインターバルの時間または数に関してパラメータ化される。このブロックは１つのインプット、１つのアウトプットおよび２つのパラメータを有している。第１のパラメータは第２のパラメータの単位を示す：これは秒または最小単位目盛（ticks）であり、この第２のパラメータは遅延の持続時間を指定する。この遅延は、メモリを割り当てることによって行われる。このメモリは、最新のインプットから最古のインプットまでのデータヒストリーを保持するのに充分な大きさのバッファのためのメモリである。ここでは最古のインプットは、遅延のために、サイクルの整数を加えたものである。インターバルの小数部を呼び出す遅延は容易であり、かつ良く知られている方法によって実行され、この方法は最古の測定および２番目に古い測定に基づいて、重み付けされた二点の平均化（a two point weighted average）を行う：
ｙ（ｋ）＝ｘ（ｋ−ｎｄ−１）＊ａ＋ｘ（ｋ−ｎｄ）（１−ａ）
ここでｙ（ｋ）は最新のアウトプットであり、ｘ（ｋ）は最新のインプットであり、ｘ（ｋ−ｍ）は遅延されたインプットであり、ｎｄは、周期単位における遅延時間の整数部分であり、ａは０と１の間の数であり、周期単位で表された遅延の少数部をあらわす。

ＳｐｕＴｒａｃｅ
ＳｐｕＴｒａｃｅ ＳＰＵは、ベースソフトウェアの信号追跡能力との相互作用のためのメカニズムを提供する。典型的にＳｐｕＴｒａｃｅブロックはネットワーク内のコネクションの分岐によって挿入される。これによって、内部ネットワーク信号の測定（状態変数）が、外部表示および分析のために収容される。ＳｐｕＴｒａｃｅは軸の数および追跡ＩＤによってパラメータ化される。１つのネットワーク内の複数のＳｐｕＴｒａｃｅおよび複数のネットワークにわたる複数のＳｐｕＴｒａｃｅは全て可能である。

ＳｐｕＤｆｉｌｔ
ＳｐｕＤｆｉｌｔ ＳＰＵは、一般的な目的の離散時間線形フィルタ能力を提供する。フィルターの異なった方程式は以下にあらわされており、ここではフィルターステップ時間は、フィルターが作動する周期的なリアルタイムプロセスの周期時間である。

ｙ（ｋ）＝ｂ０＊ｕ（ｋ）＋ｂ１＊ｕ（ｋ−１）＋・・・＋ｂｍ＊ｘ（ｋ−ｍ）＋−ａ１＊ｙ（ｋ−１）＋・・・＋−ａｎ＊ｙ（ｋ−ｎ）

定義データ内の「分子」（ｂ）および「分母」（ａ）パラメータのインスタンスとして係数をリストアップすることによって移動平均係数に対する値（ｂ）および自己回帰係数（ａ）が指定される。分子パラメータの発生数はｍを指定し、分母パラメータ発生数はｎを指定する。各係数のロケーションは、パラメータリスト内のそのロケーションから推定される。離散フィルターの実装によって、フィルター初回作動時の過渡現象が回避される。これは、全ての内部状態が安定するまでに部分的にフィルタリングされたインプットがアウトプットへ通過することによって行われる。内部状態は、次のことを想定して割り当てられた値である。すなわち、初期のインプット値（ｕ）が安定状態を推定するために、フィルター状態に対して、充分に長く続いたことを想定して割り当てられた値である。これらのアルゴリズムの詳細は後日、提供される。

ＳｐｕＤｆｉｌｔ ＳＰＵは一般的な目的のフィルタークラスを使用し、メモリ管理およびフィルターの作動時間方法の初期化を実施する。このクラスは、プロセス監視アプリケーションケースにおいて、監視タスクがフィルタリング能力を求める他の場所で使用される。

連続時間フィルター
フィルターを連続時間伝達関数としてあらわす付加的なＳＰＵクラスが使用可能である。これらはネットワークポータビリティが、コントロールセッティングにおける変化と一貫している、ネットワーク特性の能力に依存する状況において有効である。フィルターが作動するプロセスの周期時間が変化する場合には、特別に、フィルターの連続時間表示によって、一貫した特性が可能である。連続時間表示は、離散フィルターが以下のタイプのシーケンスの組み合わせによって表されることを必要とする：一次フィルター、二次フィルターおよび純粋な時間遅延。連続時間フィルターの組み合わせは、バックグラウンドプロセスにおいて離散時間等価物のインスタンス（すなわち、ＳｐｕＤｆｉｌｔによって使用されるフィルタークラス）に変換される。なぜならネットワークはデータ構文解析の間に構築されるからである。離散時間等価物は良く知られているマッピングプロシージャによって生成される。これは「Ｔｕｓｔｉｎ’ｓ Ｔｒａｐｅｚｏｉｄａｌ Ｉｎｔｅｇｒａｔｉｏｎ」、「Ｍａｔｃｈｅｄ Ｚｅｒｏ−Ｐｏｌｅ」および「Ｓｔｅｐ Ｉｎｖａｒｉａｎｃｅ」等である。ＰＴ２（二次ローパス）、ノッチ（帯域阻止）、ＤＴ２（二次ハイパス）等の特定のタイプのフィルターを構築するための高いレベルのＳＰＵは、連続時間フィルターブロックとして用いられるＳＰＵを提供することによっても得られる。ここでこれは、パラメータ化を通じて、所望のタイプをあらわすように構築される。

ＳｐｕＶａｒＩｎ
ＳｐｕＶａｒＩｎ ＳＰＵは、ベースシステムからの大域可変変数にネットワーク信号を割り当てるためのメカニズムを提供する。ＳｐｕＶａｒＩｎはインプットを有しておらず、１つのアウトプットと、データソースを識別するためのパラメータを有している。１つの実施例では、ＳｐｕＶａｒＩｎは３つのパラメータによってパラメータ化される：すなわち、大域可変変数のタイプ、行、列である。その値は、ＳＰＵの信号アウトプットとして通過すべきである。このような場合には、システムは整数または浮動小数点数等の種々のタイプの変数のアレイを提供し、ＳｐｕＶａｒＩｎのアウトプットは特定のアレイ内へのエントリの値である。このようなメカニズムは、作動時の信号処理ネットワークのリアルタイム調整を収容する。例えば、スイッチの選択インプットとしてのＳｐｕＶａｒＩｎのアウトプットのルーティングによって変数は、信号処理ネットワークのサブセクションをイネーブルまたはディスエーブルすることができる。ＳｐｕｒＰｒｏｄｕｃｔブロックへのＳｐｕＶａｒＩｎのアウトプットのルーティングは効果的に設定可能な利得を生じさせ、ＳｐｕｒＳｕｍブロックへのルーティングは設定可能なオフセットを生じさせる。１つの実施例では、ＳｐｕＶａｒＩｎによって参照される大域可変変数は、コントローラのモーションプログラム、ＰＬＣまたはＨＭＩコンポーネントによって修正される。

Ｓｐｕ Ｄｙｎｆｒｉｃｔ
ＳｐｕＤｙｎｆｒｉｃｔは、位置、速度および加速度インプットとしての非線形摩擦力の複合性質をモデリングするＳＰＵを提供する。使用されている摩擦モデルの詳細な説明は、別個の発明の開示の内容である。

ＳｐｕＣｏｍｐａｒｅ
ＳｐｕＣｏｍｐａｒｅは、その２つのインプットに基づいてロジカルな比較を実行する。これは第１のインプットの値を、第２のインプットの値と比較し、この比較が「正しい」と評価した場合にはａ１を出力し、この比較が「誤っている」と評価した場合にはａ０を出力する。１つのパラメータは比較演算のタイプを列挙する：すなわち、＞，＜，＞＝，＜＝，＝，！＝。

ＳｐｕＬｏｇｉｃ
ＳｐｕＬｏｇｉｃは、自身の複数の入力に基づいてブール演算を行う。演算のタイプは１つのパラメータによって指定される。ここでこのパラメータは、ＡＮＤ，ＯＲ，ＮＡＮＤ，ＮＯＲ，ＥＯＲを列挙する。ＳｐｕＬｏｇｉｃ ＳＰＵのアウトプットは、全てのインプットに基づいた論理的な演算の結果である。このようなブロックは、幾つかのＳｐｕＣｏｍｐａｒｅ評価からの結果に基づいて決定を下す際に有効である。ＳｐｕＬｏｇｉｃエレメントのアウトプットの幾つかの予期される有効なルーティングは、ＳｐｕＳｗｉｔｃｈのセレクターインプットまたはＳｐｕＳｕｐｐｒｅｓｓエレメントの状態インプットである。

ＳｐｕＳｕｐｐｒｅｓｓ
信号抑制は、次のことを示すメカニズムを意味する。すなわち、プロセス監視のためのネットワークアウトプットが抑制され、抑制状態の持続する間は、監視アルゴリズムがアラームを発しないように命令することを示すメカニズムを意味する。ＳｐｕＳｕｐｐｒｅｓｓエレメントは、抑制が望まれている状態が持続する間は、信号を乗算するストラテジーを使用する。信号抑制は、抑制状態が始められたときの値に、信号レベルを保持することによって実行される。抑制状態が終了すると、保持されていた信号は漸次、保持されていた値から、その瞬間の値に移動する。漸次の移動は、ローパスフィルターを用いて実行される。ここでこのローパスフィルターの時定数は、移動期間にわたって漸次減少する。このコンセプトは、幾年かの間に、スピンドルトルクを抑制する、およびスピンドル運転開始の間のパワー測定の特定の目的で、プロセス監視製品において開発され、使用されてきた。現在の実装においては、このコンセプトはＳｐｕＳｕｐｐｒｅｓｓエレメントによって一般化されている。ＳｐｕＳｕｐｐｒｅｓｓエレメントは２つのインプットを用いる：すなわち、０が通常の状態を示し、１が抑制状態を示す、抑制のための信号および論理的なインプットである。ＳｐｕＳｕｐｐｒｅｓｓの実行方法内では、有限状態機械は、ＳＰＵによって出力された値を管理する。必要であれば、この設計の詳細が入手可能である。

ＳＰＮの自動生成
そのモデル構造が事前に知られている、および／または固定されている機械特性／ダイナミック特性を記述する場合には、信号処理ネットワーク内でのＳＰＵの収集のクラスおよびトポロジーはこれらのモデルを基に作成される。プロセス監視の場合には、ＳＰＮはこのモデルの走行時間シミュレーションをあらわす。サーボコントロールの場合には、このモデルは、自動調整プロシージャにおける開始点として用いられる。このプロシージャのジョブはＳＰＵをパラメータ化する。

自動セットアップはプロセスである。ここではモデルのパラメータ化は、機械が刺激状態に反応すると、コントローラ状態変数の測定を分析することによって自動的に定められる。幾つかの場合では、刺激状態は事前に人為的に、システム内で意図的に作成される。別のケースでは、刺激状態は、機械によって実行される通常のプロセスの間に自然に発生する。いずれにせよ、刺激が「充分である」場合には、使用可能な信号の適切なセットからの測定値が、モデルの最適なパラメータ化を定めるために、システム識別の方法を用いて分析される。このステップが終了すると、モデル情報は直接的に、ＳＰＮを定める相応するＡＣＸデータフォーマットに変換される。ここでこのＳＰＮは、モデルのシミュレーションをあらわす（プロセス監視および特定の故障検出アプリケーションに対して）。サーボコントロールアプリケーションにおいては、軸をコントロールするためのＳＰＮトポロジーにおいてＳＰＵのパラメータ化を導出するためにモデルが使用される。いずれにせよ、ネットワークを定めるためのＡＣＸデータは自動的に生成され、コントローラ上に自動的に組み込まれる。特定のケースではＳＰＮのトポロジーは事前には固定されず、システム識別プロセスの間に生成されたモデルの指定に基づいて選択される。ＡＣＸファイルによってあらわされるトポロジーを視覚化するための設備も開発された。自動セットアッププロセスの詳細は、別個の開示部分として論議されるであろう。

図２を参照されたい。本発明の第１の実施例２００に従った例示的な方法は、既存の、コンパイルされ、リンクされたコードを用いてデータフォーマットを提供する。各信号処理ネットワークは、上述したように、１つまたは複数の信号処理ユニットを提供する（ブロック２０２）。データフォーマットはＸＭＬまたは他の適切な言語である。信号処理ユニットは、モーションコントロールシステムに専用インターフェースを提供する（ブロック２０４）。各信号処理ユニットに、複数のインプットおよび複数のアウトプットが提供される（ブロック２０６）。これらのインプットおよびアウトプットは、１つまたは複数の信号処理ユニットの間でルーティングされる（ブロック２０８）。このインプットおよびアウトプットは、モーションコントロールシステムの監視、モーションコントロールシステムの操作、故障検出システムの操作および／またはモーションコントロールシステムのシミュレーションに関する。

このシステムおよび方法は、配線によるモジュールまたはプログラミング可能なハードウェアを用いて実現される。このシステムおよび方法は、上述した実施例を実現するために種々のコンポーネントを使用するソフトウェア内に実装される。実施例内の開示されたアスペクトは、独立して、または他の実施例と組み合わせて使用される。さらに、上述のものは本発明の原理の例として示されただけであり、種々の修正が、本発明の範囲および思考を逸脱することなく当業者によって行われる。当業者は、本発明が、上述した実施例以外のものによって実行可能であることを理解するだろう。本願の実施例は、限定より、例解する目的のためのものであり、本発明は添付された特許請求の範囲によってのみ制限される。

本発明の実施例１００に従ったＳＰＮにおける使用のために定義されたクラス間の関係のクラス図 本発明の第１の実施例に従った、信号処理ネットワークのための方法のフローチャート

Claims (19)

1. モーションコントロールシステム上で展開された信号処理ネットワークを形成するためのシステムであって、
   前記信号処理ネットワークは、複数の信号処理ユニットと、１つまたは複数のシグナルフローコネクションと、を具え、
   前記複数の信号処理ユニットの各々は、信号処理ユニットクラスのそれぞれのインスタンスを具え、前記信号処理ユニットクラスは、現存するコンパイルかつリンクされたコードを具え、各信号処理ユニットは複数のインプットと複数のアウトプットを有し、前記信号処理ネットワークはデータを用い、前記現存するコンパイルかつリンクされたコードを、前記複数の信号処理ユニットの各々のために構成し、
   前記１つまたは複数のシグナルフローコネクションは、前記信号処理ユニットの少なくとも１つのソース信号処理ユニットのアウトプットを、前記信号処理ユニットの少なくとも１つの宛先信号処理ユニットのインプットに、前記データに基づいてルーティングし、
   前記複数の信号処理ユニットは、専用インターフェースを前記モーションコントロールシステムに提供し、
   各信号処理ユニットは、ネットワークコンストラクションの間、前記信号処理ユニットを識別するための独自のＩＤを含み、
   各シグナルフローコネクションは、前記ソース信号処理ユニットと前記宛先信号処理ユニットとの間のデータフローチャネルを表し、
   各コネクションは、前記宛先信号処理ユニットの前記独自のＩＤを含む、
   ことを特徴とするシステム。
2. 各信号処理ユニットの前記インプットおよびアウトプットは前記モーションコントロールシステムの監視に関している、
   請求項１記載のシステム。
3. 各信号処理ユニットの前記インプットおよびアウトプットは故障検出システムに関している、
   請求項１記載のシステム。
4. 各信号処理ユニットの前記インプットおよびアウトプットは前記モーションコントロールシステムの操作に関している、
   請求項１記載のシステム。
5. 各信号処理ユニットの前記インプットおよびアウトプットは前記モーションコントロールシステムのシミュレーションに関している、
   請求項１記載のシステム。
6. 前記データは拡張マークアップ言語（ＸＭＬ）を含むデータフォーマットである、
   請求項１記載のシステム。
7. 前記データは、信号処理トポロジーを指定する、
   請求項１記載のシステム。
8. 前記データは、前記信号処理ネットワークによって使用される処理方程式のタイプを指定する、
   請求項１記載のシステム。
9. 前記データは方程式のパラメータ化を指定する、
   請求項１記載のシステム。
10. 前記データはデータフォーマットであり、サードパーティフォーマットを前記データフォーマットへ変換するモジュールをさらに含んでいる、
    請求項１記載のシステム。
11. モーションコントロールシステム上で展開された信号処理ネットワークを形成するための方法であって、
    複数の信号処理ユニットを提供し、前記複数の信号処理ユニットの各々は、信号処理ユニットクラスのそれぞれのインスタンスを具え、前記信号処理ユニットクラスは、現存するコンパイルかつリンクされたコードを具え、前記信号処理ネットワークはデータを用い、前記現存するコンパイルかつリンクされたコードを、前記複数の信号処理ユニットの各々のために構成し、
    前記複数の信号処理ユニットによって、専用インターフェースを前記モーションコントロールシステムに提供し、
    各信号処理ユニットに複数のインプットと複数のアウトプットを提供し、
    前記信号処理ユニットの少なくとも１つのソース信号処理ユニットのアウトプットを、前記信号処理ユニットの少なくとも１つの宛先信号処理ユニットのインプットに、前記データに基づいて、１つまたは複数のシグナルフローコネクションを介してルーティングし、
    各信号処理ユニットは、ネットワークコンストラクションの間、前記信号処理ユニットを識別するための独自のＩＤを含み、
    各シグナルフローコネクションは、前記ソース信号処理ユニットと前記宛先信号処理ユニットとの間のデータフローチャネルを表し、
    各コネクションは、前記宛先信号処理ユニットの前記独自のＩＤを含む、
    ことを特徴とする方法。
12. 各信号処理ユニットの前記インプットおよびアウトプットは前記モーションコントロールシステムの監視に関している、
    請求項１１記載の方法。
13. 各信号処理ユニットの前記インプットおよびアウトプットは故障検出システムに関している、
    請求項１１記載の方法。
14. 各信号処理ユニットの前記インプットおよびアウトプットは前記モーションコントロールシステムの操作に関している、
    請求項１１記載の方法。
15. 各信号処理ユニットの前記インプットおよびアウトプットは前記モーションコントロールシステムのシミュレーションに関している、
    請求項１１記載の方法。
16. 前記データは拡張マークアップ言語（ＸＭＬ）を含むデータフォーマットである、
    請求項１１記載の方法。
17. 前記データは信号処理トポロジーを指定する、
    請求項１１記載の方法。
18. モーションコントロールシステムを監視およびコントロールするための信号処理ネットワークを形成するためのシステムであって、
    前記信号処理ネットワークは、データと、複数の信号処理ユニットと、１つまたは複数のシグナルフローコネクションと、を具え、
    前記データは、前記信号処理ネットワークによって使用されている処理方程式のタイプおよび方程式のパラメータ化を指定し、
    前記複数の信号処理ユニットの各々は、信号処理ユニットクラスのそれぞれのインスタンスを具え、前記信号処理ユニットクラスは、現存するコンパイルかつリンクされたコードを具え、各信号処理ユニットは複数のインプットと複数のアウトプットを有し、前記信号処理ネットワークはデータを用い、前記現存するコンパイルかつリンクされたコードを、前記複数の信号処理ユニットの各々のために構成し、
    前記１つまたは複数のシグナルフローコネクションは、前記信号処理ユニットの少なくとも１つのソース信号処理ユニットのアウトプットを、前記信号処理ユニットの少なくとも１つの宛先信号処理ユニットのインプットに、前記データに基づいてルーティングし、
    前記複数の信号処理ユニットは、専用インターフェースを前記モーションコントロールシステムに提供し、
    各信号処理ユニットは、ネットワークコンストラクションの間、前記信号処理ユニットを識別するための独自のＩＤを含み、
    各シグナルフローコネクションは、前記ソース信号処理ユニットと前記宛先信号処理ユニットとの間のデータフローチャネルを表し、
    各コネクションは、前記宛先信号処理ユニットの前記独自のＩＤを含む、
    ことを特徴とするシステム。
19. 前記データは、信号処理トポロジーを指定する、
    請求項１８記載のシステム。

Images