JP2016510150A - イベント制御型機能を監視する方法およびイベント制御型機能を実行するための監視装置 - Google Patents

Abstract

ここに記載されているのは、イベント制御型機能を監視するための方法およびイベント制御型機能を実行するための監視装置である。本発明により、サービス指向アーキテクチャを有する自動化システムの資源消費量の新たなタイプのモニタリングが得られる。ここでは、このサービス指向アーキテクチャ内の部分機能毎に、資源需要量および処理性能に対するパラメタがそれぞれ個別が求められる。イベント制御型処理の際に部分機能毎に処理パラメタを個別に分析することにより、クリティカルな部分機能を確実に識別し、場合によっては調整することができる。

Description

本発明は、サービス指向アーキテクチャを有するシステムにおけるイベント制御型機能を監視する方法およびイベント制御型機能を実行するための監視装置に関する。

従来の技術
サービス指向アーキテクチャ（ＳＯＡ：service oriented architecture）は、企業ソフトウェアの分野から公知である。このアーキテクチャは、この分野において大規模かつ複雑なＩＴシステムを構造化するために使用される。サービス指向アーキテクチャの原理は自動化技術にも転用することができる。ここにおいてより複雑な自動化機能は、孤立した複数の部分機能または複数の処理ステップに分解することができる。例えば、１つのアクチュエータが１つまたは複数のセンサの信号に基づいて制御される一般的な制御ループは、複数の部分機能に分割することができる。

第１の部分機能は、例えば１つのセンサにおけるデータ検出とすることが可能である。つぎに別の１つの部分機能では、上記のセンサの生データを必要に応じて変換して較正することができる。別の１つの部分機能では、例えば、処理したセンサデータの平滑化または補間を行うことが可能である。つぎに別の１つの部分機能では、上記のように処理したデータに基づき、上記のシステムをどのように再調整するかを求めることができる。最後に別の部分機能として、前に求めた制御パラメタに基づいてアクチュエータの駆動制御が行われる。個々の部分機能が共通の１つのデータメモリを介して互いに接続される慣用のシステムとは異なり、サービス指向アーキテクチャでは、個々の部分機能間の通信接続が確定することにより、個々の部分機能が明示的に組み合わされる。これによって可能になるのは、前の部分機能によって新たなデータが準備されると直ちに、上記の個々の部分機能が、イベント制御されて、対応する装置上で実行されることである。例えば、国際公開第２００８／１３５４５９号には、サービス指向アーキテクチャに基づく、コラボレーティブ自動化システムが開示されている。

サービス指向アーキテクチャにおける部分機能のイベント制御型の実行とは異なり、従来使用されていた、慣用のシステムでは、個々の部分ステップは一般的にサイクリックに実行される。例えばＣＰＵ利用率、メモリ使用量、ネットワーク利用率または類似のもののような資源使用量を監視するための公知の方法は、サービス指向アーキテクチャにおける複数の部分機能をイベント制御型で実行するためにはあまり役に立たない。１つのサイクル内のすべての部分ステップの合計の平均実行時間が、要求される時間を下回る場合であっても、このことからは、それにもかかわらず、負荷ピークに起因して、個々の部分機能を実行する際に問題となる遅延が発生していることを推定することはできないのである。さらに個々の部分機能は、その実行時間特性について要求が異なり得る。例えば、監視すべきプロセスの慣性に応じて、１つの制御ループの反応時間に対する要求が異なり得るのである。このことから、１つの部分機能の最大応答時間について複数の異なる要求が生じる。したがってサイクリックな実行時に観察される平均実行時間のデータまたは平均過度率、サービス指向アーキテクチャにおける部分機能の要求を維持するためにあまり重要ではないのである。

したがってサービス指向アーキテクチャを有するシステムにおいて、イベント制御型機能を監視するための方法および装置に対する要求がなされているのである。

発明の開示
１つの様相によれば、本発明により、サービス指向アーキテクチャを有するシステムにおけるイベント制御型機能を監視するための方法が得られ、この方法は、イベント制御型機能に対する要求を検出するステップと、イベント制御型機能を実行するステップと、このイベント制御型機能の処理パラメタを求めるステップとを有する。

別の様相によれば、本発明により、イベント制御型機能を実行するための処理装置用の監視装置が得られ、この監視装置は、イベント制御型機能に対するイベントの発生を検出するように設計された検出装置と、上記の処理装置において検出したイベントに基づいてイベント制御型機能の実行を開始するように設計された実行装置と、イベント制御型機能の実行中に処理パラメタを求めるように設計されている、処理パラメタを求めるための装置とを有する。

本発明のアイデアは、サービス指向アーキテクチャを有するシステムにおける個々のイベント制御型機能を個別に監視し、この際にこの機能の処理を特徴付ける処理パラメタを求めることである。これにより、サービス指向アーキテクチャの個々の部分機能毎に、資源消費量を個別に求めることができる。

個々の部分機能毎に処理パラメタを個別に求めることの利点は、各部分機能の要求の偏差を特に迅速かつ高い信頼性で検出できることである。

例えば、部分機能の実行時間が、あらかじめ設定した最大値を上回る場合、このことは、直接検出することができ、これにしたがい、必要に応じて対抗手段を講じることができる。

別の利点は、個々の部分機能をそれぞれ個別に観察し、別の要求と比較することができる。これにより、場合によっては問題となる部分機能を迅速に検出することができる。

さらに、部分機能毎に個別に複数の要求を表せることは有利である。これにより、関連するパラメタに基づき、個々の部分機能を個別に評価して、必要に応じて調整することができる。

イベント制御型機能を監視する上記の方法の一実施形態によれば、上記の求めた処理パラメタには、イベント制御型機能を実行するための時間の長さ、イベント制御型機能を実行するための資源需要量、および／または、通信パラメタが含まれる。実行のための時間の長さを求めることにより、処理時間の超過を確実に検出することができる。個々の部分機能にわたって資源需要量を評価することにより、場合によっては、例えば部分機能用の記憶スペースのような供給資源を迅速に適合調整することができる。例えばデータスループットなどの通信パラメタを分析することにより、データ交換などの際の脆弱箇所を部分機能毎に個別に検出し、分析し、場合によって取り除くことができる。

別の実施形態によれば、上記の方法には、上記の求めた処理パラメタと、あらかじめ設定した要求パラメタとを比較するステップが含まれている。あらかじめ設定される要求パラメタを前もって設定することにより、サービス指向アーキテクチャを有するシステムの個々の部分機能が上回るべきでない閾値を簡単に定めることができる。これにより、実際に求めた処理パラメタと、あらかじめ設定した要求パラメタとを比較すれば、クリティカルな機能を簡単に検出することができ、これにしたがって適切な対向手段を講じることができる。

別の実施形態によれば、上記の方法には、求めた処理パラメタを分類するためのステップが含まれている。例えば、処理パラメタと、あらかじめ設定した要求パラメタとを比較することによって処理パラメタを分類することにより、また別の択一的な分類方法により、サービス指向アーキテクチャを有するシステムにおける動作状態を特に簡単に分析することができる。この分類に基づき、クリティカルな状態の特に簡単な分析および検出が可能になる。

別の実施形態において、上記の方法には、求めた処理パラメタを記憶するためのステップが含まれている。求めた処理パラメタを記憶することにより、システムの後の評価および分析にもこれらの処理パラメタを利用することができる。

別の実施形態において、上記の方法には、複数の資源を選択するためのステップが含まれており、これらの資源は、上記の求めた処理パラメタに基づいて選択される。求めた処理パラメタに基づいて個々のイベント制御型機能を実行するための資源を選択することにより、このシステムを所期のように制御することが可能になり、これによってすべてのイベント制御型機能は、あらかじめ設定した仕様内で実行することができる。

別の実施形態によれば、上記の方法には、求めた処理パラメタを視覚化するためのステップが含まれている。求めた処理パラメタを視覚化することにより、特に簡単かつ確実にユーザにシステムの動作状態を示すことができ、発生するクリティカルな諸状態を迅速に把握し、必要に応じて取り除くことができる。

別の実施形態において、本発明の方法には、求めた処理パラメタを伝送するためのステップが含まれている。前に求めた処理パラメタを伝送することにより、これらのパラメタを、離れた箇所において受信して評価することもできるため、上記のシステムは、離れた箇所からも監視することができる。これにより、場合によっては、ユーザが直接現場にいなくても、クリティカルな状態が発生した際に対抗手段を講じることができる。

別の実施形態において、上記の監視装置にはさらに、求めた処理パラメタを記憶するために設計された記憶装置が含まれている。

別の実施形態によれば、監視装置には、求めた処理パラメタを表示するように設計された表示装置が含まれている。

別の実施形態によれば、監視装置には、求めた処理パラメタを伝送するように設計された通信インタフェースが含まれている。

本発明にはさらに、本発明による監視装置を有する処理装置においてイベント制御型機能を実行するための、サービス指向アーキテクチャを有する自動化システムが含まれている。

本発明の実施形態の別の特徴および利点は、添付の図面に基づく以下の説明から得られる。

サービス指向アーキテクチャを有する自動化システムの概略図である。 本発明の一実施形態による監視装置を有するサービス指向アーキテクチャの一部分の概略図である。 本発明の一実施例に基づく、サービス指向アーキテクチャを有するシステムにおけるイベント制御型機能を監視するための方法のステップを示す図である。

図面に示した図は、部分的に複数の要素を縮めて示したものであり、これらの要素は、わかり易くするために必ずしても縮尺通りに描かれていない。同じ参照符号は一般的に同じタイプまたは同じ作用を有するコンポーネントを示す。

図１には、サービス指向アーキテクチャに基づく自動化システムの概略図が示されている。例えば、このような自動化システムは、制御ループを具現化するために使用することができる。ここでは１つまたは複数のセンサ１０により、例えば任意の測定値が検出される。これら測定値は、例えば、環境影響または機械のパラメタ（圧力、速度、電流、電圧など）とすることが可能である。

最も簡単なケースでは、センサ１０は、検出した測定値の生データを供給し、またはセンサデータに基づいて計算しすでに前処理した値も供給する。センサ１０が対応するデータを出力した後、これらのセンサデータは、別のインスタンスに、例えば処理装置２０に送信される。

複雑さに応じて個々の処理装置２０の代わりに複数のインスタンスを相前後して接続することができる。制御ループの場合、例えば、センサ１０によって出力される値は、必要に応じて変換および／または較正される。その後、場合によっては上記の測定値の別の処理を行うことができ、例えば上記の値が平滑化および／または補間される１つまたは複数の処理ステップが続き得るのである。場合によってこのように処理された上記の測定値は、つぎに別の部分機能において分析され、これにしたがい、必要な制御特性に対する種々の判断を求めることができる。このようにして求められる制御特性の出力は、続いてアクチュエータ３０に送信することができる。このアクチュエータ３０は、受信した値に基づき、例えば上記のプロセスにおける制御変数を調整する。

上で説明した例からわかるように、制御ループ内の複数の部分機能はそれぞれ、前置された部分機能の出力値をとりどころにしている。したがってサービス指向アーキテクチャでは、対応する要求がある場合には機能を可能なかぎりに近接した時間で実行すべきである。具体的にはイベント制御型機能を実行するためのこのような要求は一般的に、前置されたインスタンスがその出力を後続のインスタンスに送信することによってシグナリングされる。

図２には、本発明の一実施形態にしたがい、イベント制御型機能を実行するための処理装置の概略図が示されている。処理装置２１は、前置されたインスタンスから、機能を実行するための要求を受け取る。例えば、この要求は、処理装置２１の（図示しない）入力側メモリに任意のデータを送信することによって行うことができる。上で説明した例によれば、例えば、複数のセンサ１０は、それらのセンサデータを処理装置２１に送信することができる。監視装置２２は、その検出装置２２−１において、イベント制御型機能の実行に対する要求を検出する。例えば、これは、前置されたインスタンスからのデータの受信とすることが可能である。しかしながら前置されるインタスタンスが、例えば測定値またはこれに類するものの形態で明示的なデータを供給しない場合、初期化信号を送信することにより、イベント制御型機能を初期化することも可能である。

検出装置２２−１により、イベント制御型機能に対するイベントの到着が検出された後、実行装置２２−２により、処理装置２１において検出したイベントに基づき、イベント制御型機能の実行が開始される。別のイベント制御型機能をトリガするデータの到着時に、処理装置２１がすでに別の機能の実行に取り組ませられている場合、上記の新しいイベント制御型機能の実行をまず延期することも可能である。実行装置２２−２によって後の時点に、処理装置２１が前の処理を終了したことが検出される場合、実行装置２２−２はこれにしたがって処理装置２１をトリガして上記の新たな機能を実行することができる。

このために処理装置２１は、その入力側メモリから場合によって受信されるデータを読み出して処理する。場合によってはこのために、図示しないプログラム記憶装置から適当なコンピュータプログラムコードを読み出し、このプログラムコードに基づき、処理装置２１における処理が行うことができる。

処理装置におけるイベント制御型機能の実行中、この処理は、処理パラメタを求める装置２２−３によって監視される。この際に処理パラメタを求める装置２２−３は、今まさに処理している機能の実行を特徴付けるパラメタを求める。例えば、ここでは今まさに処理装置において処理中のイベント制御型機能を実行するための時間の長さを求めることができる。このために装置２２−３は、処理装置２１の初期化と、対応するイベント制御型機能が完全に終了した時点との間の時間の長さを求めなければならない。

付加的には、または選択的には処理パラメタを求める装置２２−３は、対応する機能を処理する間に、必要な資源需要量を、例えば必要メモリ量を求めることができる。さらに、例えば別のコンポーネントとの通信が必要な場合には、処理パラメタを求めるために必要なネットワーク資源を評価することもできる。さらに処理ユニット２１におけるイベント制御型機能の実行中に、別の複数の処理パラメタを求めることも可能である。

処理ユニット２１における機能の実行中に上記のようにして得られた処理パラメタは、引き続いて評価および分析に利用される。例えば、機能を実行するのに必要な上記の時間の長さを評価することができる。これにより、例えば、時間的にクリティカルな機能において、最長許容処理時間を上回ったことを直接検出することができる。求めた処理パラメタに基づいて部分機能毎に個別の評価および分析を行うことができる。さらに、択一的な評価の選択肢を設けることも可能である。例えば、連続して実行される一連の機能にわたって所定の判定基準が維持されることを尺度として用いることができる。場合によっては一連の同じイベント制御型機能に対して求めた処理パラメタの許容差を、上記の評価に対する好適な尺度とすることも可能である。例えば、処理パラメタによって求めた資源消費量が前の複数の機能の資源消費量から偏差している場合を検出し、これに基づき、例えば異常な偏差を推定することができる。

特に機能毎に、例えば、機能の実行中に維持しなければならない適切な要求パラメタを定めることができる。その後、上記のあらかじめ定めた要求パラメタを実行時に保つことができなかったことが、上記の求めた処理パラメタに基づいて確認される場合、これにしたがい、あらかじめ設定した要求パラメタを満たさない対応する部分機能を直接識別することができる。

例えば、このようなあらかじめ設定した要求パラメタは、１つの機能を実行するための最大の時間の長さとすることができるか、例えば最大記憶スペースのような最大許容資源需要量とすることができるか、またはデータ伝送のための最大帯域幅またはこれに類似するもとすることも可能である。別の要求パラメタ、付加的または択一的な要求パラメタも同様に可能である。

さらに、上記の求めた処理パラメタに基づき、また場合によっては上記のあらかじめ設定した要求パラメタにも基づいて、イベント制御型機能を対応して分類することも可能である。例えば、最も簡単なケースでは、上記のあらかじめ設定した要求パラメタが維持され機能と、あらかじめ設定した処理パラメタが維持されない機能とを区別することができる。しかしながら場合によっては、あらかじめ設定される要求パラメタの特にクリティカルな偏差と、なお許容可能な偏差とへの別の分類も可能である。

このようにして求めた処理パラメタ、および、場合によっては上記のあらかじめ設定した要求パラメタに基づく上記の分析、あるいは上記の分類は、続いて記憶装置２３に記憶することも可能である。例えば、上記の求めた処理パラメタを、例えば上記の実行のための時間の長さまたは類似のものを、実行されるイベント制御型機能毎にテーブルの形態で格納することができる。例えば、イベント制御型機能の異なるデータ用の異なる記憶領域における記憶、または処理パラメタの異なるタイプ毎の異なる記憶領域における記憶の、択一的な記憶タイプも可能である。

さらに、上記の求めた処理パラメタを通信インタフェース２５を介して伝送することも可能である。例えば、上記の求めた処理パラメタは、求めた後すぐに通信インタフェース２５を介して、後続の処理のために離れた箇所に伝送することができる。また付加的または択一的には、同様に通信インタフェース２５を介し、すでに前に記憶した処理パラメタを記憶装置２３から離れた箇所に伝送することも可能である。

さらに上記の求めた処理パラメタを表示装置２４に表示することも可能である。このような表示装置２４は、例えば、監視装置２２に直接接続することが可能であり、これによって処理パラメタを直接現場で処理装置に表示することができる。例えば表示装置２４は、例えばモニタ、ＴＦＴディスプレイのようなディスプレイまたは任意の別のタイプの表示装置とすることが可能である。表示装置２４はさらに、処理パラメタを前もって処理してユーザにとって適切な表示形態で表示装置２４上に表示する適切なデータ処理装置を含み得る。これにより、適切なユーザインタフェース上に特に明快でわかりやすくユーザにシステム状態を表示することができる。これにより、クリティカルな動作状態の場合にユーザはこれを迅速に把握して適切な対抗手段を講じることができる。ここでは求めた処理パラメタを表示する際の表示の色調整を行うことが可能である。これにより、ユーザは、異常な偏差およびクリティカルな動作状態を特に迅速に気づくことができる。さらにシステム状態および求めた処理パラメタの評価に応じて、音響的なシグナリングを行うことも考えられ、これによってユーザが迅速に特別なシステム状態に気が付くようにする。

ユーザによる手動の介入とは択一的に、クリティカルな動作上になった場合、上記の求めた処理パラメタに基づいて、システムの自動的な調整を行うことも可能である。例えば、複数の別のイベント制御型機能の実行に対し、複数の求めた処理パラメタに基づき、利用可能な資源を調整することできる。これにより、例えば、作業メモリのより大きな部分を準備し、別の複数のインスタンスからのまたは別の複数のインスタンスへのデータ伝送のための容量を調整し、場合によっては種々異なる機能に異なる優先度を設定し、あるいはマイクロプロセッサシステムのクロックレートを調整することが可能である。さらに求めた処理パラメタに基づいて資源を調整するための別のステップも同様に可能である。

図３には、一実施形態において本発明の基礎をなしているサービス指向アーキテクチャを有するシステムにおいてイベント制御型機能を監視するための方法１００の概略が示されている。まず最初にステップ１１０において、イベント制御型機能に対する要求を検出する。要求のこの検出は、例えば、前置されたインスタンスが、処理ユニット２１の入力側記憶装置に入力側データを格納し、および／または、要求信号を処理ユニット２１に送信することによって行われる。これによって処理ユニット２１が、要求される機能を実行する準備が整うと、ステップ１２０において対応する機能が開始される。これに対して対応する処理ユニット２１が、まだ別の機能に取り組んでいる場合、要求された機能の実行はまず延期される。択一的な実施形態では、特にクリティカルであるかまたは優先度の高い機能の要求時には、目下実行している機能を中断することもでき、続いて優先度の高いこの機能を直ぐに開始することができる。また機能の優先度設定のための別の選択肢も可能である。

要求されたイベント制御型機能を処理ユニット２１において処理する間、ステップ１３０では、イベント制御型機能の実行を特徴付ける１つまたは複数の処理パラメタが求められる。これらの処理パラメタは、例えば、実行のための時間の長さ、必要な資源需要量、または必要なデータ通信の帯域幅とすることが可能である。

上記のイベント制御型機能の求めた処理パラメタを評価するため、さらにステップ１４０において、上記の求めた処理パラメタと、あらかじめ設定した要求パラメタとを比較する。あらかじめ設定した要求パラメタは、例えば、すでに前もって確定して図示しない記憶装置に格納された値とすることが可能である。択一的には、都度実行すべき機能に対し、あらかじめ設定した要求パラメタを個別に準備することも可能である。

さらに、求めた処理パラメタの簡単かつ確実な評価を行うため、ステップ１５０において、求めた処理パラメタを分類することができる。例えばこのため、あらかじめ設定した要求パラメタを上回るかまたは下回るかによる簡単な分類を行うことができる。例えば、「正常」、「ややクリティカル」、「もはや許容不能」またはこれに類するものへの複数の下位グループへの別の分類も可能である。

上記の求めた処理パラメタに基づき、ステップ１７０ではさらに、例えば、通信帯域幅、利用可能な記憶装置、個々の機能の優先度設定、プロセッサクロックレートまたは類似のものなどの資源の選択を調整して、必要に応じ、要求パラメタを満たさない場合には最適化を行う。特に資源のこの調整は、例えば繰り返して行うことができる。

求めた処理パラメタを迅速かつ簡単に把握するため、ステップ１８０においてこれらの処理パラメタを視覚化することができる。例えば、このために処理パラメタのすぐ近くの表示装置２４に表示するかまたは離れた箇所の表示装置２４に表示することも可能である。利用可能な処理パラメタを前もって処理して加工することにより、求めた処理パラメタを、例えば適当なユーザインタフェースにおいて快適に表示することができる。これにより、特に新たなシステムを開発する際には、また制御動作中にも、個々の機能処理する際の技術的な状態がユーザによって迅速に検出され、その後、必要に応じて適当な対抗措置が講じられることが可能になる。

上記の処理パラメタが処理ユニット２１において直接評価されない場合、または少なくとも処理ユニット２１だけにおいて評価されない場合、別のステップ１９０において、上記の求めた処理パラメタを離れた箇所に伝送することもできる。この伝送は、例えば、慣用のネットワークインタフェースおよびケーブル接続されたネットワークを介して行うことができる。択一的にはＷＬＡＮ，Bluetooth（登録商標），移動無線またはこれに類するもののような無線伝送も可能である。これにより、遠くにいるユーザも適時にクリティカルな状態について情報を受け取ることができる。

機能毎に処理パラメタを別個に専用に求めることの他に、さらに複数の機能に対する処理パラメタをまとめて、さらに１つの共通の処理パラメタとすることも可能である。例えば、意味があるのであれば、複数の部分機能の個々の処理時間の長さをまとめて、複数の処理ステップに対してこのまとめた時間の長さを共通の１つの処理パラメタとすることができる。これにより、場合によっては、発生するデータ量を低減することができる。さらにこのようにしてまとめたデータは、一人のユーザが簡単に把握して分析することができ、この際には不必要な大きなデータ量によって無理を強いられることがない。

以上をまとめると、本発明は、サービス指向アーキテクチャを有する自動化システムの資源消費の新たなモニタリングに関している。ここでサービス指向アーキテクチャ内の部分機能毎に，資源受容量および処理性能に対するパラメタをそれぞれ個別に求める。したがってイベント制御型処理において部分関数毎に処理パラメタを個別に分析することにより、クリティカルな部分機能を確実に識別し、場合によって調整することができるのである。

Claims (13)

1. サービス指向アーキテクチャを有するシステムにおけるイベント制御型機能を監視する方法（１００）において、
   イベント制御型機能に対する要求を検出するステップ（１００）と、
   前記イベント制御型機能を実行するステップ（１２０）と、
   前記イベント制御型機能の処理パラメタを求めるステップ（１３０）とを有する、
   ことを特徴とする方法（１００）。
2. 前記処理パラメタには、前記イベント制御型機能を実行するための時間の長さ、前記イベント制御型機能を実行するための資源需要量、および／または、通信パラメタが含まれる、
   請求項１に記載の方法（１００）。
3. さらに、前記求めた処理パラメタと、あらかじめ設定した要求パラメタとを比較するステップ（１４０）を含む、
   請求項１または２に記載の方法（１００）。
4. さらに、前記求めた処理パラメタを分類するためのステップ（１５０）を含む、
   請求項１から３までのいずれか１項に記載の方法（１００）。
5. さらに、前記求めた処理パラメタを記憶するためのステップ（１６０）を含む、
   請求項１から４までのいずれか１項に記載の方法（１００）。
6. さらに、複数の資源を選択するためのステップ（１７０）が含まれており、当該資源は、前記求めた処理パラメタに基づいて選択される、
   請求項１から５までのいずれか１項に記載の方法（１００）。
7. さらに、前記求めた処理パラメタを視覚化するためのステップ（１８０）を含む、
   請求項１から６までのいずれか１項に記載の方法（１００）。
8. さらに、前記求めた処理パラメタを伝送するためのステップ（１９０）を含む、
   請求項１から７までのいずれか１項に記載の方法（１００）。
9. イベント制御型機能を実行するための処理装置（２１）用の監視装置において、
   当該監視装置は、
   イベント制御型機能に対するイベントの発生を検出するように設計された検出装置（２２−１）と、
   前記処理装置（２１）において検出した前記イベントに基づいて前記イベント制御型機能の実行を開始するように設計された実行装置（２２−２）と、
   前記イベント制御型機能の実行中に処理パラメタを求めるように設計されている、処理パラメタを求めるための装置（２２−３）とを有する、
   ことを特徴とする監視装置。
10. さらに、前記求めた処理パラメタを記憶するために設計された記憶装置（２３）を含む、
    請求項９に記載の監視装置。
11. さらに、前記求めた処理パラメタを表示するように設計された表示装置（２４）を含む、
    請求項９または１０に記載の監視装置。
12. さらに、前記求めた処理パラメタを伝送するように設計された通信インタフェース（２５）を含む、
    請求項９から１１までのいずれか１項に記載の監視装置。
13. 請求項９から１２に記載した監視装置を含む処理装置においてイベント制御型機能を実行するための、サービス指向アーキテクチャを有する自動化システム。

Images