サービス指向型のコンポーネントの複数のモジュールの間のインターアクションを制御するための方法およびサービス指向型のコンポーネント

专利摘要:
本発明は、サービス指向型のコンポーネント（ＳＯＫ）のモジュール、例えば、通信モジュール（ＫＯＭ-ＭＯＤ）、制御モジュール（ＬＣ-ＭＯＤ）、デバイス・インタフェース・モジュール（ＧＩ-ＭＯＤ）の間のインターアクションを制御するための方法に関する。種々のおよび競合的なプロセスの最中に複数のモジュールの間のインターアクションを簡素化するためには、モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）の間のインターアクションが、イベントベースで行なわれ、モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）は、これらのモジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）の、イベントベースの接続および同期化のための、そのためのイベント・ルーター・スケジューラを提供するためのイベント・ルーター・スケジューラ・モジュール(ＥＡＳ-ＭＯＤ）を介して、接続されていることが提案される。
公开号:JP2011513822A
申请号:JP2010548132
申请日:2009-02-27
公开日:2011-04-28
发明作者:コロンボ、アルマンド・バルター；メンデス、ジョアオ・マルコ
申请人:シュナイダー・エレクトリック・オートメイション・ゲーエムベーハー；
IPC主号:G06F9-54

专利说明:

[0001] 本発明は、サービス指向型のコンポーネントのモジュール、例えば、通信モジュール、制御モジュール、デバイス・インタフェース・モジュールの間のインターアクションを制御するための方法、オートメーション・デバイスのようなサービス指向型のコンポーネントならびにソフトウェア・コンポーネントに関する。]
背景技術

[0002] 生産およびオートメーション・システムは、当然ながら異質であり、自らのタスクに従って、種々のコンポーネントからなる。従って、これらのシステムの仕様が、伝統的な、中央制御型のアプローチから離れて、分散型の、対応のアプローチに発展し、自然の所与条件および実際のシステムのレイアウトに適合されることが、予測できる。]
[0003] 従って、１セットの協調型のユニットとして協働する、分散型の、自律的な、知的な、耐エラー性の、再利用可能な製造ユニットを有することは、見込みがある。各々のユニットは、局所的のみならず、大域の製造目標を得るために、製造現場における物理的な機械制御レベルから、工場管理システムのより高いレベルへと、他の各々のユニットと動的に相互作用することが可能である。システムのこのような新世代は、知的製造システム（ＩＭＳ；Intelligent Manufacturing Systems）と呼ばれる。]
[0004] ＩＭＳより後の多数のコンセプトを使用可能な原理に適合させるための、増大する解決策のうちの１つが、サービス指向型のアーキテクチャ（ＳＯＡ）である。ＳＯＡのコンセプトは、数年で、大きな重要性を得て、疑いもなく、多くの技術分野で大きな影響を有する。サービス指向型のアーキテクチャは、自律的なおよび相互運用可能なシステムを構成するための一連のアーキテクチャ定理である。この仮定は、ＩＭＳの挑戦のうちの１つ、すなわち複数の自律的なシステムの間の相互運用性の提供を明らかにする。]
[0005] ＩＭＳの原理に従ってサービス指向型のコンセプトを製造現場でのオートメーションおよび生産「ビジネスシステム」へ適合させることは、サービス指向型のオートメーション・コンポーネントから「新たな」コミュニティを作り出す。システムにおける各々のパーシティパントが、サービス指向のコンポーネントと呼ばれ、幾つかの拡張では、コンポーネントが自動的な制御ユニット有するとき、サービス指向型のオートメーション・コンポーネントと呼ばれる。コンポーネントは、種々のタスク、例えば生産、搬送またはモニタリングを有し、自律的に作動されることができる。サービスが実際のガイダンスを引き受けるので、これらのコンポーネントは、サービスを要求し、および、逆に、サービスの要求を、コミュニティの他のパーシティパントによって支援する特性を有するほうがよい。サービス自体は、場合によっては共に用いられる資源および動作の、その提供の形態であり、実生活でのサービスに非常に類似している。]
[0006] 分散型のオートメーションの場合に、および特に生産システムの領域では、システムの一連の機器および追加のコンポーネントを、所定の状況では、「生物」のコミュニティと比較されることができる。任意の或るコンポーネントを詳しく観察すれば、内部のメカトロニクス組織を、機能的な器官と比較することができる。かような器官は、かような要求を叶えることができる「活動」特性を提供する特殊なタスクを担っている。中心的な問題は、これらの機能的なモジュールまたは「器官」が如何に統合および制御され、複数のモジュールの間でイベントを交換し、従って、複雑なかつ効果的な構造を形成することが如何に可能であるかである。]
[0007] サービス指向型のシステムは、インターアクションを必要とする異質の「生命体」のための環境を指定するためのアプローチである。サービス・ビジネスシステムは、ビジネスの世界のおよび電子取引の分野で知られている。しかし、工業的なオートメーションおよび生産システム（特に、このシステムに関連した分散型のデバイス）の分野では、有望な見込みを有する比較的新しい研究分野である。重要な出発点は、ＥＵ研究プロジェクトＳＩＲＥＮＡであった。このプロジェクトの目標は、埋設された実時間ネットワークアプリケーションのためのサービス・インフラストラクチャを開発することであった。サービス・フレームワークのインプリメンテーションは、「Device Profile forward Services（ＤＰＷＳ）」仕様と一致して開発された。その目的は、資源に依存する埋設された複数のデバイスの間での通信を可能にするためである。]
[0008] このシステムの重要な点は、制御手段が設けられていること、および制御の粒度および分散が如何に影響を受けるかである。通常のプログラミング可能な論理コントローラ(ＰＬＣ；Programmable Logic Controller)の導入以来、ＰＬＣの集中的な使用に関する制限を克服する目標をもって、研究および開発における著しい進歩がなされた。この目的のために、マルチ・エージェント・システム、ホロニック・システムおよび最近ではサービス指向型のシステムの分野からの提案が提出された。]
[0009] デバイスおよび制御ソフトウェアのためのアーキテクチャは、同様に、研究の視野の中にあって、通常はICE 61131-3言語と、分散型の制御およびオートメーションのためのIEC61499機能ブロックと、他の制御技術、例えばペトリ・ネットを用いる。サービス指向型のデバイスのためには、制御方法は、部分的には、如何なる制御アプローチに対して開かれており、しかしながら、同様に、サービス指向の特定の要求を考慮するほうがよい。]
[0010] 種々の機能性を提供することによって、個々のサービス指向型の制御デバイスは、種々の動作の準備ができているほうがよい。従って、制御デバイスは、特別に適合された内部フレーム構造または、以下にフレームワークと呼ばれるプログラミング構造を必要とする。このプログラミング構造は、種々のおよび競合的なプロセスを処理することができる。]
[0011] このことを前提として、明細書の最初の部分に記載のタイプの方法ならびにサービス指向型のコンポーネントおよびソフトウェア・コンポーネントを、複数のモジュールの間のインターアクションが、異なったおよび競合的なプロセスの場合に簡素化されるように、改善する課題が、本発明の基礎になっている。]
[0012] 課題は、本発明によれば、複数のモジュール間のインターアクションが、イベントベースで行なわれ、複数のモジュールの間のイベントベースのインターアクションおよびモジュールの同期化を、イベント・ルーター・スケジューラ・モジュール（Event-Router-Scheduler）を介して制御することによって、解決される。]
[0013] サービス指向型のコンポーネント、デバイスおよび支援型のアプリケーションにおいて機能モジュールのイベントベースの接続および同期化のためには、イベント・ルーター・スケジューラ・モジュールが用いられる。]
[0014] このモジュールは、例えば分散型のオートメーション・デバイスを支援するモジュール式のサービス指向型のコンポーネントに統合されることができ、１つのコンポーネントを形成する複数の機能モジュールの間の通信のためのフレームワークを提供することができる。アプリケーションは、特に、製造現場のためのオートメーション・デバイスおよび支援型のソフトウェア・アプリケーションに関する。]
[0015] サービス指向型のコンポーネントは、中央のイベント・ルーター・スケジューラと、必要なサービス指向型の通信モジュールとを含む種々の機能的なモジュールからなるモジュール式の構造である。通信モジュールは、他のコンポーネントとの通信を可能にする可能性を有する。コンポーネントがマルチ・スレディング可能な環境でありかつデータ保護を必要とするので、これらのタスクのために、個々のモジュールにインターアクション環境を供するメカニズムがあらねばならない。]
[0016] 本発明によって、オートメーション制御コンポーネントモジュールの通信が複数のイベントの場合にのみなされることが、達成される。このことは、これらのイベントの実時間同期化およびデータ転記を制御するために、役立つ。かくして、各々のモジュールは、独立しているが、相補形である。アプローチは、開発者をして、各々のモジュールを独立的にプログラミングし、受信された情報を如何に処理すべきかを容易に知ることを可能にする。]
[0017] 制御コンポーネントが、非同期的に動作しかつ種々のプロセスおよび／またはスレッドを用いることができる複数のモジュールから形成されるとき、すべてのモジュールを互いに接続し、かつデータ並行性（data concurrency）を維持するためには、特別なモジュールが必要とされる。この目的のために、パズルの「心臓部」は、イベント・ルーター・スケジューラ・モジュール（Event-Router-Scheduler）である。このイベント・ルーター・スケジューラ・モジュールは、以下の主な特徴を用いる。]
[0018] このモジュールは、各々のモジュールの間のイベントの伝送を可能にする。このことは、複雑なインターアクションメカニズムをして、簡単な基本機能を用いることを可能にする；
統合された機能的なモジュールのための共通のイベント・ルーター・スケジューラ・メカニズム；
高いイベント容量が生じる際の、イベントのための優先的なバッファ；
スレッド管理およびデータ保護手段；
・種々のタイプのモジュールを接続するための、一般的なインタフェース。]
[0019] 実時間アプリケーションは、日々一層複雑になる。特に、機械制御のアプリケーションが、電子コンポーネントの処理のために、作られる。その目的は、パソコンのようなスーパーバイザ・コンピュータに情報を送るため、他の制御手段と通信するため、等々。情報の全体的な流れの処理は、非常に複雑であり得る。更に、工業オートメーションでは、エラー、長時間の開発、または頻繁な再プログラミングを回避することが意図される。]
[0020] アプリケーションによって、以下の特徴が得られる。すなわち、
-イベント・ルーター・スケジューラ（Event-Router-Scheduler）は、イベント制御型の内部アーキテクチャフレームを用いる。アーキテクチャフレームによって、互いに接続された機能モジュールのための、情報の流れが、制御される。]
[0021] -従来の技術よりも簡単な、機能的なモジュール定義またはモジュール分離、および、中央のイベント・ルーター・スケジューラ（Event-Router-Scheduler）の使用によるコンポーネントへの統合、
-各々のモジュールを別々にプログラミングすることができる。このことは、モジュールを除去し、交換し、アップグレードし、新たなモジュールを追加し、あるいは、情報が如何に送られかつ読み取られるかをただチェックすることが可能であることを意味する。]
[0022] -あらゆる目的のための、個々に製造された機能的なモジュールの支援。]
[0023] イベント・ルーター・スケジューラ（Event-Router-Scheduler）を、モジュール式のおよび機能的なアーキテクチャに基づく如何なるソフトウェア・コンポーネントにおいても、用いかつ統合することができる。アプリケーションの領域を以下のように指摘する。]
[0024] ・サービス指向型のデバイスのための機能的な構造、
・サービス指向型のデバイスへのアクセスをオートメ化し、このコンセプトを含む内部アーキテクチャを有する開発ツール、
・環境シミュレーションのための、仮想のソフトウェアの開発、
・他のコンポーネントから情報を集めるツールおよびコンポーネントのモニタリング、
・ソフトウェア・エージェントおよびマルチ・エージェントシステムの開発の支援。]
[0025] 本発明は、従って、サービス指向型のオートメーション・システムの部分としてのコンポーネントの機能的なおよび再利用可能なモジュールの開発のための生体構造に似た構造に係わる。中心的な視点は、モジュールの内部構造および特にメカニズムに向けられている。このメカニズムは、複数の機能的なモジュールを結びつけ、イベント・ルーター・スケジューラと呼ばれる。イベント・ルーター・スケジューラは、動的な情報の流れを維持するためのインパルスの、異なった器官からのおよび該器官への搬送または処理に関して、生物の神経系と比較されることができる。知的挙動が達成されるのは、これらの神経が「頭脳」に接続されるときである。この頭脳は、「ワークフロー」に基づいて「定位制御」プロセスを提供し、同様に、自律的である。その目的は、予測されないイベント、文書化されない状況または内部での目標設定に対処するためである。コンポーネントがサービス指向型の環境へ統合されて、他のコンポーネントとの通信は、サービスの利用および要求によって達成されることが可能である。その目的は、局所的なおよび大域の目標設定を達成するためである。]
[0026] 本発明の複数の他の詳細、利点および特徴は、複数の請求項と、これらの請求項から読み取れる、単独および／または組合せで生じる複数の特徴とからのみならず、図面から見て取れる複数の好ましい実施の形態の以下の記述からも明らかである。]
図面の簡単な説明

[0027] サービス指向型のオートメーションおよび生産システムのサービス指向型のオートメーション・コンポーネントの略図を示す。
サービス指向型のコンポーネントのモジュール式の構造の略図を示す。
イベント・ルーター・スケジューラを有するサービス指向型のコンポーネントの構成の略図を示す。
イベント・ルーター・スケジューラを介しての、任意の或るモジュールによる、イベント・メッセージの送信の種々のタイプを示す。
「遮断された」モジュールまたは「開いている」モジュールの場合の、イベントの読取の略図を示す。
「遮断された」モジュールまたは「開いている」モジュールの場合の、イベントの読取の略図を示す。
機械的なアームのサービス指向型のコンポーネントおよびアームの機能の略図を示す。]
実施例

[0028] 図１は、サービス指向型のコンポーネントＳＯＫと、これらのコンポーネントの、製造現場ＦＳのオートメ化および生産環境への統合との略図を示す。図示したコンポーネントＳＯＫは、物理的なコンベアＦを表わし、搬送機能（タスク：輸送）を引き受ける。外界との通信は、サービス（サービス指向）によってなされる。サービスは、必要な場合にサービスを要求し、または利用することができる。ＩＴ環境への統合は、同様に、サービス指向によって達成される。任意の或るコンポーネントは、機能（タスク）のセット（タスク：搬送、モニタリング等）を含む。これらの機能を、複数のコンポーネントによって利用されるサービスとして用いることができる。] 図１
[0029] 複数のコンポーネントの間のインターアクションは、２ウェイ原理に基づいて、サービスの要求およびサービスの提供の目的でなされる。生産およびオートメ化では、異種コンポーネントが、相互利点を得るためにおよび大域の目標設定を達成するために、協働することが期待される。このことは、「共生」とも呼ばれ、異なった生物学的種（タイプ）の間のインターアクションに類似している。しかしながら、最後には、大域の目標を考慮する必要がある。]
[0030] 幾つかの状況では、サービス指向型のコンポーネントを、ソフトウェア・エージェントと見なしてもよい。]
[0031] 更に、マルチ・エージェント・システムは、特に重要である。何故ならば、これらのシステムは、協調的なエージェントコミュニティの着想を生み出すからである。エージェントコミュニティでは、システムの各々は、システムの環境を介して、またはシステムによって表わされるシステムを介して、自律動作を引き受けることができる。他方では、およびエージェントコンセプトとは反対に、サービス指向の本当の目的は、サービスの提供の特徴およびシステム内のコンポーネントによるサービスへの要求の必要性に集中している。システムの、実際のアーキテクチャ、環境および目標設定は、ユーザに対してオープンしており、従って、システムは、要求を満たすために、異なった戦略に適合されることができる。]
[0032] 複数のコンポーネントの開発を簡略化する、複数のコンポーネントの内部構造の仕様書は、まだ開いたままである。しかし、サービス指向型のコンポーネントが、異なっておりかつ時には競合する動作を実行することができるので、再利用および容易な開発に有利なように、機能的なおよび独立的な構造を用いることは、有益であり得る。]
[0033] 各々のサービス指向型のコンポーネントＳＯＡを、別々にかつ異なってインプリメントすることができる。只１つの要求は、コンポーネントが、自らの機能をサービスＳとして提供し、コンポーネントが通信プロトコルおよび手順に従わねばならないことである。これらのコンポーネントを、簡単なしかし機能的な方法で構造化し、かつ開発することができるように、生体構造に類似している「フレームワーク」が提案される。]
[0034] 図２は、コンポーネントＳＯＫの概略的構造を、解剖学的形態で示す。このコンポーネントは、複数の「器官」（機能的なモジュール）を有する。これらの器官は、図２に示すように、個々のタスクに関与している。すなわち、論理コントローラＬＣ-ＭＯＤ、決定・例外ハンドラＥＡＨ-ＭＯＤ、通信Ｋ-ＭＯＤ、デバイス・インタフェースＧＩ-ＭＯＤ、イベント・ルーター・スケジューラ（Event-Router-Scheduler）ＥＡＳ-ＭＯＤ。これらのモジュールは、自らの要求に従って、制御コンポーネントＳＯＫに含まれており、種々に技術を用いて、可能な限りインプリメントされる。種々の機能性が、統合（イベント・ルーター・スケジューラのタスク）のための「フレームワーク」によって尊重される規則を とき、種々の機能性のための他のモジュールＭＯＤを開発しかつ統合することは、同様に可能である。] 図２
[0035] イベント・ルーター・スケジューラＥＡＳおよび通信モジュールＫＯＭ-ＭＯＤは、カーネルモジュールである。その目的は、サービス指向型のコンポーネントＳＯＫを、提案された生体構造に基づいて開発するためである。カーネルモジュールは、一方では、コンポーネントの主要なフレームワーク（イベントベースのインタモジュールインターアクションおよび統合）に、および他のコンポーネントとの外部通信（サービス指向型のインタ・コンポーネント通信）に関与している。他のモジュールＭＯＤを、コンポーネントの要求に基づいて、構造に追加することができる。]
[0036] より正確に言えば、通信モジュールＫＯＭ-ＭＯＤは、必要な機能を利用する。その目的は、対応のコンポーネントのサービスを提供し、かつ他のコンポーネントのサービスを要求するためである。他の機能は、取り分け、発見（Discovery）およびネゴシエーション（Negotiation）機構を含む。コンポーネントの残りのモジュールは、イベント・ルーター・スケジューラ・モジュールＥＡＳ-ＭＯＤによって提供されるインパルス（イベント）によるこれらの機能へのアクセスのために、通信モジュールＫＯＭ-ＭＯＤを用いてもよい。例としては、コンベアベルトは、サービス「移動」を提供することができる。その目的は、論理コントローラ・モジュールＬＣ-ＭＯＤによって制御されかつデバイス・インタフェース・モジュールＧＩ-ＭＯＤによって呼び出される、パレットの動きを、引き起こすためである。サービス「移動」は、他のコンポーネントによって利用されることができるが、コンポーネント自体は、同様に、外部のサービスが必要とされるときは、該サービスを呼び出すことができる。（例えば、他のコンベアベルトと接続するために、コンポーネントは、他方のコンベアベルトのサービス「移動」を呼び出す）。]
[0037] サービス指向型の通信モジュールをインプレメントするために適切な技術的解決策は、Ｗｅｂ技術のおよび特にＷｅｂサービスの使用である。基本的には、Ｗｅｂサービス技術は、全く簡単であり、標準インターネット・プロトコルを使用する複数のサービス・プロセスの間でＸＭＬ(Extended Markup Language）文書を用いるために、開発された。この単純性は、Ｗｅｂ技術をして、相互運用性のより高い目標に達することを可能にし、同時に、複雑な分散型のアプリケーションを実現化するために、他の技術を付け加えることが必要であることを意味する。Ｗｅｂサービスをデバイス・レベルに適合させるために、プロファイルが指定された。このプロファイルは、「Device Profile for Web-Service(DPWS)」として知られている。]
[0038] 追加のモジュールＭＯＤは、図２に簡潔に記述されている。目標は、制御可能性を有する任意の物理的機器のための「エージェント」であるサービス指向型のオートメーション・デバイスＳＯＫを提供するために、追加のモジュールを含めることである。例えば、図２に示す、結果として生じるコンポーネントＳＯＫは、複数の性質、例えば、物理的デバイスによる制御およびアクセス、予期せぬかつ文書化されていない状況における決定能力、および同様に、他のコンポーネントとのサービス指向型の通信の可能性を提供することによって、コンベアベルトＦのスマート・コントローラを表わす。他の例は、ＰＬＣに似た、サービス指向型のコントローラである。このコントローラは、（例えば、ＩＥＣ６１１３１−３言語で）制御モデルを解釈することができ、他のコンポーネントに、該コンポーネントによって提供されたサービスを呼び出すことにより、必要な命令を出す。この場合、デバイス・インタフェース・モジュールは不要である。何故ならば、モジュールは、デバイスに直接指示しないからである。] 図２
[0039] 最後に、図２に示した「生体構造」の「神経系」は、イベント・ルーター・スケジューラＥＡＳ（Event-Router-Scheduler）によって管理される。イベント・ルーター・スケジューラを、如何に詳細に説明する。] 図２
[0040] サービス指向の図示したアスペクトのうちの複数をインプリメントするコンポーネントおよびデバイスは、必要な要求を満たすべく、種々の機能モジュール（器官）を処理するために、均一の生体構造を必要とする。他の諸問題、場合によっては、データの不整合性および競合的プロセスまたはスレッドは、非同期的に作動されるモジュールから生じることがある。この目的のために、「インパルス」を種々のモジュールに導き、従って、これらのモジュールの間の同期化されたインターアクションを可能にするために、インパルス（イベント）の伝達および制御の特徴を提供するメカニズムが提案される。このコンポーネントの心臓部は、イベント・ルーター・スケジューラ（Event-Router-Scheduler）ＥＡＳ-ＭＯＤである。]
[0041] ＥＡＳ-ＭＯＤは、以下の目標を満たす。]
[0042] ・複数のモジュールのインターアクションおよび統合のための共通のイベント・ルーター／制御メカニズム、
・モジュールを形成しかつ導くために複数の透過的な機能を提供すること、
・ＥＡＳ-ＭＯＤは、従来のＰＣのためにおよび埋設されたシステムのために開発されたソフトウェア・アプリケーションにとって適切である、
・特に、クリティカルな状況および「対象となる」実時間アプリケーションにおいて、高い性能、
・性能と、可搬性と、特徴との間の均等化という目標を有する、例えばＣ言語の使用、
・データの並行性の安全操作および管理、
・モジュールのデザインのための開発者による容易な使用およびイベントが如何に実行されるのか。]
[0043] ＥＡＳ-ＭＯＤの機能は、複数のパラメータの中に、人間を含む生物の神経系と比較可能である。]
[0044] サービス指向型のコンポーネントＳＯＫの場合、「環境」は、特定のモジュール、例えば、通信モジュールおよびデバイス・インタフェース・モジュールによって記録されかつ操作される。個々のモジュールのおよびモジュールの統合のインパルス（イベント）の自然な平衡は、イベント・ルーター・スケジューラ・モジュールＥＡＳ-ＭＯＤによって達成される。]
[0045] イベント・ルーター・スケジューラ・モジュールＥＡＳは、実時間で操作されかつ同一のアプリケーションのモジュールＳＭ、ＧＩＭ、ＫＭのためのイベント・ハンドラである（図３を参照）。これは、簡単なパズルの中心のピースのようである。パズルのピースは、同一のプログラムの、異なったソフトウェア・モジュールである。複数のモジュールの通信を他の動作中にオンザフライで処理することは、大抵意図される。このことは、各々のモジュールがイベントを送り、他のすべてのモジュールからイベントを受け取ることができ、ＬＣ-ＭＯＤ、ＧＩ-ＭＯＤ、ＫＯＭ-ＭＯＤ等の同期化、情報の損失、データ転記に気にかけることのないことを意味する。] 図３
[0046] コンポーネントＫが、対応のデバイスＳＯＫ、ＳＯＧまたはソフトウェア・アプリケーションにインプリメントされるのは、複数の必要なモジュールが互いに接続された後である。図３では、コンポーネントＫは、２つの必要なモジュール、すなわち、イベント・ルーター・スケジューラ・モジュール（ＥＡＳ）および通信モジュールＫＯＭ-ＭＯＤからなるが、１つのデバイス・インタフェース・モジュールからなる。このデバイス・インタフェース・モジュールＧＩ-ＭＯＤは、対応のモジュールのＩ／Ｏからの情報を読み取り、またはＩ／Ｏへの情報を書き込むことを可能にする。] 図３
[0047] 主な特徴は、複数の機能的なモジュールの間の、イベントベースのインターアクションの提供、およびイベントの適切なシーケンス制御である（図４に示したイベントの制御およびシーケンスを参照せよ）。実際的観点からは、コンポーネントの、複数の自らの機能モジュールの間での内部インパルス（イベント）が、イベント・ルーター・スケジューラによって内部で管理される。イベント・ルーター・スケジューラは、すべてのモジュールの間の同期的なおよび非同期的なイベント呼び出しを可能にする。このことは、実時間アプリケーションにとって非常に重要である。更に、イベント・ルーター・スケジューラは、より複雑な手順を、例えば、他のイベントおよび時間制御型のイベントによって生成されるイベント、を実現するための複数の追加のプロセスを提供する。最も簡単な形態では、送信モジュールが、只１つのイベントを、特定のターゲット（他のモジュール）に送り、イベント・ルーター・スケジューラは、このイベントをそのターゲットへ送る。同様に、図４に示すように、複数のイベント、例えば、「イベントは要求を期待する」と、１つのイベントの、複数のターゲットモジュールへの「マルチキャスト」（グループコール）とを送信しおよび処理するための他の選択も存在する。イベントとは、種々のあり得る状況を認識するために、モジュールを必要とする、あらゆる情報を有する構造なのである。要求された動作および対応のパラメータに関連する標準情報に追加して、この構造は、情報を提供するための応答を要求し、またはエラー・メッセージ・レシーバを有し、あるいは、イベント・レシーバは、応答があるか否かをチェックすることができる。同様に、任意の或るイベントが、エラーの故に、一度より多く送られることが認識可能である。] 図４
[0048] イベント・ルーター・スケジューラは、リストを、複数のモジュールの間で複数のイベントを伝送しかつ分類するための手段として用いる。それ故に、処理を待っているイベントの数は、使用可能な記憶装置によってのみ制限されている。イベント・ルーター・スケジューラは、記憶装置の分割を避けるために幾つかの技術を用いる。何故ならば、データの生成および消去は、モジュールにおいて非常にしばしば用いられる機能だからである。イベントの数が時に非常に多い幾つかの場合には、イベント・ルーター・スケジューラは、イベントに異なった優先順位を与える可能性を提供する。所定のモジュールに送られた任意の或るイベントを、常に、このモジュールの、すべての待っているイベントが通過する。これらのイベントは、送られたイベントの優先順位よりも低い優先順位を有する。]
[0049] システムは、同期的のみならず非同期的な操作を実行することができる。非同期的な操作は、スレッドによって管理される。同期的な操作は、レシーバに対して、「フリーズ」(frozen)か、または「ノンフリーズ」（non frozen）でもよい。例えば、イベントの読取の最中に、操作は、「フリーズ・モジュール」であっても、なくてもよい。「フリーズ・モード」の場合には、モジュールは、このモジュールのための新たなイベントが到着するまで、フリーズしている。続いて、モジュールは、図５ａに示すように、通常の手順を続ける。このことは、ＣＰＵの非常に僅かな資源容量を有する手順である。このことは、特に、埋設されたデバイスのために適切である。しかしながら、このことは、実時間マルチタスキング・モジュールにために役立たない。何故ならば、このタイプのモジュールは「フリーズ」されることが意図されないからである。他方では、「ノンフリーズの」イベント読取装置は、常に、１つのイベントを受信する。しかしながら、このイベントは、無効なイベントであってもよい。無効なイベントとは、モジュールが他のタスクで作動を続けることができるように、該モジュールのためにイベントが存在しないことを意味する。有効なイベントであれば、モジュールはこれらのタスクを続けるほうがよい。このことは、図５ｂに示されている。] 図５ａ 図５ｂ
[0050] 非同期的なイベント起動は、同様に可能である。この場合、コールバック（call back）が、この操作タイプを実行するために、用いられる。何故ならば、このタイプが呼び出されるときには、このタイプが発生しなければならないからである。しかしながら、イベントは、データ保護のために直接には起動されない。イベントが発生するほうがよいのは、モジュールがＭＵＴＥＸ(Mutual Exclusion＝相互排除)を起動するときのみである。その目的は、可能な場合にはモジュールのデータを変更するコールバック（call back）を可能にするためである。各々のモジュールは、この場合のためのＭＵＴＥＸを有する。]
[0051] 図４に示す残りのブロックは、イベントの制御（スケジューリング）および手順（ルーティング）の、隣接するタスクを、特に、自己のモジュールのおよび他のモジュールの管理を担う。ハードウェアおよび／またはソフトウェアの抽象化は、システム・アーキテクチャの機能透明性を可能にする。機能透明性へは、すべてのモジュールがアクセスされることができる。イベント・ルーター・スケジューラ・モジュールおよび他のモジュールは、多機能のおよび競合的な環境にあるので、ＥＡＳの特殊なブロックＴＤＫは、簡単なスレッド操作およびデータ保護を実行する。このブロックは、スレッディングおよびデータの整合性ブロックＴＤＫと呼ばれる。] 図４
[0052] 最後に、ブロック「イベントベースのモジュールのためのテンプレート／インタフェース」Ｔ／Ｉは、機能モジュールの生成のための基礎を用い、機能モジュールを、イベント・ルーター・スケジューラに接続する。各々のモジュールは、別々にプログラミングされることが可能である。このことは、モジュールを除去、交換、拡大または新たなモジュールを追加することが可能であることを意味する。このことによって、ＥＡＳを用いるプログラムが、非常に柔軟になる。モジュールＩＤは、モジュールの識別であり、各々のモジュールにとって曖昧でない。他のモジュールは、この変数を知らなくてはならない。その目的は、イベントを特定のモジュールに送るためである。このモジュールは、所定の器官に達するために神経によって担われるコードと比較可能である。しかしながら、モジュールを、「コントローラ」または「ユーザ・インタフェース」のようなそのタイプに基づいて探すことも、同様に可能である。何故ならば、この経路は、開発者にとって一層実用的である。その目的は、多くの情報を有しないモジュールを得るためである。]
[0053] 図６は、機械的なアームのサービス指向型のコンポーネントおよびアームの作動モードを例示する。フレームワークによって提供された、コンポーネントの開発および作動のための機能が、示されている。フレームワークは、ＥＡＳおよび３つのモジュール、論理コントローラＬＣ-ＭＯＤ、デバイス・インタフェースＧＩ-ＭＯＤならびに通信モジュールＫＯＭ-ＭＯＤからなる。] 図６
[0054] 本発明によって、サービス指向型のオートメーション・システムを開発するための、フレーム構造またはプログラミング構造（フレームワーク）が提供され、フレーム構造またはプログラミング構造は、コンポーネントを形成する種々の機能的なモジュールの間でイベントを伝達するためのメカニズムのために特に適切である。]
[0055] このような「生物学的に示唆された」モジュール式の構造の適合は、曖昧でなくかつ独立的な機能を有するモジュールのデザインおよび開発を可能にする。しかしながら、モジュールは、互いに補完的である。その目的は、複雑な、知的なおよび「社会的な」コンポーネントの形成を可能にするためである。結果として生じるコンポーネント構造体は、短縮された開発時間と、システムへの統合の際の少ない労力とによって特徴づけられる。]
[0056] 要約すれば、オートメーションおよび生産システムが、ビジネスシステムの着想を適用する自律的なおよび協調的なコンポーネントへ開発されることが確言されねばならない。このシステムの只１つの構成要素が種々のおよび競合的な動作を担い、従って、種々の要求を調整する特別に適合された分析が必要である。本発明は、サービス指向型のオートメーション・コンポーネントの機能的な再利用可能なモジュールの開発のための解剖学的構造を開示する。中心的な注意点は、内部構造およびメカニズムにある。このメカニズムは、複数のモジュールを互いに接続し、イベント・ルーター・スケジューラと呼ばれる。]
[0057] 結果として生じるソフトウェア・オートメーション・コンポーネントは、ユーザ固有で、特殊化した機能的なモジュールの組込みおよび管理に基づき、種々のアプリケーションに基づいて設計され、サービス指向型のオートメーションおよび生産環境の中で作動する可能性を供する。]

权利要求:

請求項1
サービス指向型のコンポーネント（ＳＯＫ）のモジュールの通信モジュール（ＫＯＭ-ＭＯＤ）、制御モジュール（ＬＣ-ＭＯＤ）、デバイス・インタフェース・モジュール（ＧＩ-ＭＯＤ）の間のインターアクションを制御するための方法において、前記モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）の間のインターアクションが、イベントベースで行なわれ、前記モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）は、これらのモジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）の、イベントベースの接続および同期化のための、そのためのイベント・ルーター・スケジューラを提供するためのイベント・ルーター・スケジューラ・モジュール(ＥＡＳ-ＭＯＤ）を介して、接続されていることを特徴とする方法。
請求項2
前記イベントベースのインターアクションを、前記モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）の間の同期化とは別におよび情報損失およびデータ転記とは別に行なうことを特徴とする請求項１に記載の方法。
請求項3
前記モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）を互いに接続し、続いて、前記サービス指向型のコンポーネント（ＳＯＫ）、例えばオートメーション・デバイスまたはソフトウェアに用いることを特徴とする請求項１または２に記載の方法。
請求項4
イベント・メッセージを、その優先順位に従って、記憶装置に一時記憶することを特徴とする請求項１ないし３のいずれか１項に記載の方法。
請求項5
モジュール式の構造を有し、少なくとも１つのサービス指向型の通信モジュール（ＫＯＭ-ＭＯＤ）、制御モジュール（ＬＣ-ＭＯＤ）およびデバイス・インタフェース・モジュール（ＧＩ-ＭＯＤ）を具備する、サービス指向型のハードウェアおよび／またはソフトウェア・コンポーネント（ＳＯＫ）、例えばオートメーション・デバイスまたはソフトウェア・アプリケーションにおいて、前記サービス指向型のコンポーネント（ＳＯＫ）は、イベント・ルーター・スケジューラ・モジュール(ＥＡＳ-ＭＯＤ）を有し、このイベント・ルーター・スケジューラ・モジュールは、前記モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）の、イベントベースの接続および同期化のための、そのためのイベント・ルーター・スケジューラを提供するためのフレームワークを有することを特徴とするサービス指向型のコンポーネント。
請求項6
前記サービス指向型のコンポーネント（ＳＯＫ）は、マルチ・スレッディング機能を有することを特徴とする請求項５に記載のサービス指向型のコンポーネント。
請求項7
前記モジュール（ＫＯＭ-ＭＯＤ；ＬＣ-ＭＯＤ；ＧＩ-ＭＯＤ）は、同一のプログラムのソフトウェア・モジュールであることを特徴とする請求項５または６に記載のサービス指向型のコンポーネント。
請求項8
前記サービス指向型のコンポーネント（ＳＯＫ）は、優先順位を有するイベント・メッセージのための、優先順位ベースの記憶装置を有することを特徴とする請求項５ないし７のいずれか１項に記載のサービス指向型のコンポーネント。
請求項9
コンピュータ・プログラムを有するソフトウェア・コンポーネントであって、このコンピュータ・プログラムは、前記ソフトウェア・コンポーネントがオートメーション・デバイスの中で実行されるとき、請求項１ないし８のいずれか１項に記載の方法を実行するための、そのためのソフトウェア手段を有する。