JP2021515948A - プロセス異常を修復するための方法 - Google Patents

Abstract

実行中のプロセスインスタンスを監視し、これらのプロセスインスタンスにおけるプロセス異常を修復するための方法であって、（ａ）監視ステップにおいて、センサは、センサ定義を使用して、センサ定義に記述されたプロセス異常に関してプロセスプロトコルを監視し、センサ定義に記述されたプロセス異常を有する、１つのプロセスインスタンスまたは複数のプロセスインスタンスを含むプロセスを検出し、（ｂ）修正ステップにおいて、監視ステップにおいて検出されたプロセスインスタンスに対して、プロセス異常は、このプロセスインスタンスのランタイム中に修復される、方法、が提供される。【選択図】図８

Description

本発明は、実行中のプロセスインスタンスを監視し、これらのプロセスインスタンスのプロセス異常を修復するための方法に関する。

実際のプロセスを分析するために方法を使用する企業がますます増えている。分析すべきプロセスは、コンピュータシステム内で、コンピュータシステムを用いて、またはコンピュータシステムの外部で実行できる。コンピュータシステムの外部で実行されるプロセスは、技術プロセス、例えば、組立プロセス、生産プロセスなどであり得る。

実行中のプロセスは、特定のプロセスのプロセスインスタンスと称する。この場合、プロセスインスタンスは、複数のプロセスステップを含んでもよい。それぞれのプロセスステップは、通常、コンピュータシステムに記憶されるデータを生成する。例えば、注文プロセスのどのプロセスステップを誰がいつ実行したかをコンピュータシステムに記憶できる。例えば、組立プロセスの場合、車両の組立時に、どのパラメータ（例えば、ねじを締める際のトルク）を用いてどの組立ステップをいつ実行したかを記憶でき、これに関するデータは、例えば、測定値エンコーダによって提供できる。

これらの記憶されたデータから、プロセスの分析に関連する情報を抽出できる。

これらの分析は、それぞれのプロセスの弱点に関する情報を提供できる、すでに実行されたプロセスインスタンスの後方参照分析または遡及分析である。ただし、不具合のあるプロセスインスタンスを制御するためにプロセスインスタンスに事前に介入できず、これは、不具合のあるプロセスインスタンスは、すでに実行されており、したがって、個々のプロセスインスタンスの不具合は、そのプロセスインスタンスの実行後に初めて検出できるためである。したがって、例えば、車両の組立プロセスでは、組立プロセスの完了後に初めて、この車両の組立が所定の組立時間を超えたことを確認できる。従来技術からの既知の方法を用いて、すでに実行されたプロセスインスタンスの分析に基づいて、将来実行されることとなるプロセスインスタンスを改善することがおそらく可能である。しかし、実行中のプロセスインスタンスにおいて、プロセスの改善にもかかわらず発生するおそれのある不具合または異常を認識できないか、または全く修復できていない。

したがって、本発明の課題は、プロセスインスタンスの実行中に不具合または異常を認識し、かつ修復することを可能にする解決策を提供することである。

本課題は、本発明によれば、独立請求項に記載の方法によって解決される。本発明の有利な実施形態および発展形態は、従属請求項に明記されている。

したがって、実行中のプロセスインスタンスを監視し、これらのプロセスインスタンスにおけるプロセス異常を修復するための方法が提供され、それぞれのプロセスインスタンスは、いくつかのプロセスステップを含み、プロセスデータは、すでに実行されたプロセスステップについて少なくとも１つのプロセスプロトコルに記憶され、プロセスデータは、それぞれのプロセスステップについて、少なくとも
−プロセスステップの識別子と、
−プロセスステップをプロセスインスタンスに一意的に割り当て可能である識別子と、
−プロセスインスタンス内のプロセスステップの順序と、
を含み、プロセス異常は、少なくとも１つのセンサ定義により記述され、プロセス異常には、プロセス異常を修復するための一般的アクションの集合が割り当てられており、
（ａ）監視ステップにおいて、センサは、センサ定義を使用して、センサ定義に記述されたプロセス異常に関してプロセスプロトコルを監視し、センサ定義に記述されたプロセス異常を有する、１つのプロセスインスタンスまたは複数のプロセスインスタンスを含むプロセスを検出し、
（ｂ）修正ステップにおいて、監視ステップにおいて検出されたプロセスインスタンスに対して、プロセス異常は、このプロセスインスタンスのランタイム中に修復され、
−プロセス異常に割り当てられた一般的アクションの集合から少なくとも１つの一般的アクションが選択され、
−選択された一般的アクションに基づいて、検出されたプロセスインスタンスに固有のプロセス介入インスタンスが生成され、
−プロセス介入インスタンスは、検出されたプロセスインスタンスのプロセス異常を修復するために実行される。

プロセス異常は、実行中のプロセスインスタンスにおける不具合である。しかし、プロセス異常は、所与の設定値からのプロセスインスタンスの逸脱である可能性もあり、例えば、ねじを締め付けるトルクが設定トルクを超えているが、最大許容トルクをまだ下回っている場合、逸脱は、必ずしも不具合であるとは限らない。

本発明による方法を用いて、実行中のプロセスインスタンスに積極的に介入できる。したがって、例えば、センサが監視ステップにおいて異常（例えば、低温殺菌温度の超過）を検出した場合、具体的な技術プロセス（例えば、低温殺菌プロセス）に介入できる。プロセスに介入することで、異常を修復できる（例えば、低温殺菌装置を用いて、供給される熱エネルギーを低減できる）。

本発明の一実施形態では、それぞれのプロセスステップについて、プロセスデータは、プロセスステップの実行中またはプロセスステップの終了時にプロセスプロトコルに記憶される。

センサ定義は、データおよび／または指示を含んでもよく、データおよび／または指示を用いて監視ステップにおいて、所定の選択基準を満たすプロセスインスタンスおよび／またはプロセスが、プロセスプロトコルから選択される。

選択基準は、
−少なくとも１つの静的または動的パラメータ、
−少なくとも１つの所定のパターン、および／または
−パターン認識を使用して決定可能な少なくとも１つのパラメータ
であり、選択基準からの逸脱または非逸脱の場合に選択基準が満たされており、選択基準からの逸脱または非逸脱は、プロセス異常を示唆する。

プロセスインスタンスは、複数のサブプロセスインスタンスを有し、サブプロセスインスタンスのプロセスステップは、異なるソースシステムにおいて実行でき、サブプロセスインスタンスのすでに実行されたプロセスステップについて、プロセスデータは、少なくとも１つのプロセスプロトコルにマージされる。

したがって、一方では、サブシステムインスタンスが異なるシステムで実行される場合（例えば、組立プロセスのサブプロセスが第１の組立機械により実行され、この組立プロセスの別のサブプロセスが第２の組立機械により実行される場合）であっても、プロセスデータは、中央プロセスプロトコルに記憶される。

本発明の一実施形態では、センサ定義は、監視ステップがどの時点で実行されるかに関する情報を含んでもよい。したがって、必要に応じて、実行中のプロセスインスタンスのリアルタイム監視もまた可能である。

監視ステップの前に、プロセスプロトコルが所定のフィルタ基準に従ってフィルタリングされ、フィルタリングされたプロセスプロトコルが監視ステップの基礎である場合に、有利であり得る。これにより、必要に応じて、プロセスプロトコルでチェックすべきエントリ数を減らすことができ、これは、プロセスプロトコルに非常に大量のデータ（例えば、数億のプロセスステップに関するプロセスデータ）がある場合に、特に有利である。したがって、処理速度を向上させることができる。

本発明の一実施形態では、プロセスプロトコルに記憶されたプロセスデータは、それぞれのプロセスインスタンスおよび／またはそれぞれのプロセスステップを記述するさらなる補助データにリンク可能であってもよく、プロセス介入インスタンスが生成された場合、プロセスデータは、補助データと共にパラメータ化される。これにより、（異常について修復されるべき）それぞれのプロセスインスタンスに適合したプロセス介入インスタンスを生成し、プロセスプロトコルに記憶されていないデータに関してセンサ定義を拡張することが可能である。

プロセス介入インスタンスは、いくつかの非侵襲的アクションおよび／またはいくつかの侵襲的アクションを有することができ、
−非侵襲的アクションは、それぞれのプロセスインスタンスが実行されるソースシステムの外部で実行され、
−侵襲的アクションは、それぞれのプロセスインスタンスが実行されるソースシステムで実行される。

侵襲的アクションを用いて、それぞれのプロセスインスタンスのシーケンスは、ソースシステムにおいて変更かつ／または制御できる。

非侵襲的アクションおよび／または侵襲的アクションは、それぞれのソースシステムに対して実行可能な命令に変換できる。

プロセス異常に割り当てられた一般的アクションの集合からの少なくとも１つの一般的アクションの選択は、一般的アクションの集合に含まれるいくつかのアクションまたはアクションの組み合わせに対してシミュレーションが実行され、シミュレーションにおいて、プロセスインスタンスに適用されたどのアクションまたはアクションの組み合わせが所定の結果を最も良好にもたらすのかを判定し、このアクションまたはアクションの組み合わせが選択される。したがって、潜在的に可能となる複数のアクションに対して、「最適な」アクションまたはアクションの組み合わせを選択できる。したがって、アクションまたはアクションの組み合わせを実行中のプロセスインスタンスで「テストする」必要がなくなる可能性がある。

フィルタ基準は、プロセスプロトコルの少なくとも１つの属性およびこの属性が想定できる特性によって形成でき、特性は、ユーザに割り当てられており、ユーザへの属性の特性の割り当てを介して、フィルタリングされたプロセスプロトコルにおいて発生するプロセス異常も同様にこのユーザにも割り当てられている。

プロセスプロトコルが、コンピュータシステムのメインメモリに記憶される場合、好ましくは、プロセスインスタンスの連続するプロセスステップが、隣接するメモリセルに記憶されるように記憶される場合に、特に有利である。これにより、プロセスプロトコルは、連続ストリームとしてメモリから、すなわちメモリセルごとに読み出すことができる。したがって、パフォーマンスに悪影響を与える（例えば、プロセスインスタンスの連続するプロセスステップ間の参照をマップするための）複雑なアドレッシングまたはアドレッシングプロセスを回避できる。それに加えて、プロセスインスタンスによって占有されているメモリセルの数が既知である場合、メモリセルをブロック単位で読み出すこともできまる。

監視ステップは、異常検出エンジンによって実行でき、修正ステップは、異常修正エンジンによって実行でき、
−異常検出エンジンは、センサの実行を制御し、センサの実行は、センサ定義において指定された時点に従ってトリガされ、
−異常検出エンジンは、センサによって検出されたプロセスインスタンスに関する情報を異常修正エンジンに転送する。

異常検出エンジンおよび異常修正エンジンは、コンピュータシステムにおいて実行できる。

本発明の詳細および特徴ならびに本発明の具体的な実施形態は、図面と併せて以下の説明から明らかとなる。

異常検出エンジンのブロック図である。 異常修正エンジンのブロック図である。 ルーティングエンジンのブロック図である。 プロセス介入エンジンのブロック図である。 通知エンジンのブロック図である。 本発明のシステム全体のブロック図である。 実行中のプロセスインスタンスの具体例である。 基本的な本発明の方法を具体的に説明するためのブロック図である。 プロセスプロトコル、異常検出エンジンおよび異常修正エンジンからなるネットワークである。

本発明により、プロセスインスタンスの実行を監視し、プロセスインスタンスの実行中にプロセスインスタンスに介入して、このプロセスインスタンスにおける不具合または異常を修復することが初めて可能となる。この意味で、実行中のプロセスは、このプロセスのプロセスインスタンスとも称する。

不具合または異常の修復は、本発明によれば、検出された不具合または異常に応じてプロセスインスタンスの実行中に生成されるプロセス介入インスタンスを実行することによって行われる。そのようなプロセス介入インスタンスを用いて、例えば、プロセスインスタンスのその後のシーケンスに影響を与えることができるか、または制御できる。

例えば、注文プロセスが実行されるソースシステムでは、注文した商品が配送される前にサプライヤの請求書が到着した場合、支払い停止を指示できる。別の例によれば、最後に実装されたコンポーネントが原因で最大実装時間を超過するおそれがある場合、進行中の実装プロセスにおいて、これから実装されることとなるコンポーネントの実装順序を変更するように、回路基板用の実装機械に指示できる。

したがって、プロセス介入インスタンスは、対応するプロセスインスタンスを変更するか、または制御するように構成された、１つ以上の指示を含む。注文プロセスの上記の例では、この指示は、例えば、ＳＡＰ（登録商標）トランザクションであってもよく、それにより、ＳＡＰ（登録商標）システムにおいて注文プロセスが実行されるときに支払い停止が指示される。実装機械の例では、指示は、実装機械に実装順序の適切な変更を行わせる、実装機械によって解釈可能な命令であってもよい。

本発明によれば、任意の種類のプロセスインスタンスを監視でき、実行中に異常または不具合を修復できる。特に、
−コンピュータシステムにおいてのみ実行されるプロセスインスタンス（例えば、注文プロセスのインスタンスまたは支払いプロセスのインスタンス）、
−技術的装置によってのみ実行されるプロセスインスタンス（例えば、１つ以上の組立機械によって実行される組立プロセス、または塗装ロボットによって実行される塗装プロセス）、および
−コンピュータシステムにおいて部分的に実行され、かつ技術装置によって部分的に実行されるプロセスインスタンス（例えば、コンピュータシステムにおいて実行される注文プロセスおよび生産機械によって実行される生産プロセスを含む、ジャストインタイム生産プロセス）を、
監視し、実行中に異常または不具合を修復できる。

プロセスインスタンスは、通常、複数のプロセスステップを含む。したがって、注文プロセスのインスタンスは、製品の入手可能性を検証するためのステップ、特定の数量の製品を注文するためのステップ、および注文確認を受信するためのステップを含んでもよい。塗装機械によって実行される塗装プロセスのインスタンスは、塗料保管庫に特定の塗料を要求するためのステップ、物体に塗料を塗布するためのステップ、およびクリアコートを塗布するためのステップを含んでもよい。

実行中のプロセスインスタンスのうちのすでに実行されたプロセスステップについて、プロセスデータは、プロセスプロトコルに記憶される。プロセスプロトコルに記憶されることとなるプロセスデータに加えて、プロセスステップの実行時に、プロセスプロトコルに記憶する必要のない追加のデータが副次的に生じるか、または生成される可能性がある。プロセスデータおよびこの追加データは、それら全体でソースデータと称する。ソースデータをソースシステム（例えば、注文プロセスが実行されるコンピュータシステムまたは組立装置に割り当てられた記憶装置）に記憶し、ソースシステムからプロセスデータを抽出し、その抽出されたプロセスデータをプロセスプロトコルに記憶することが有利な場合がある。

この場合、プロセスデータがリアルタイムで、すなわち、対応するプロセスステップが実行された直後にプロセスプロトコルに記憶されることが有利である。これにより、プロセスインスタンスのリアルタイム監視（またはほぼリアルタイム監視）もまた可能になり、同様にして、これは、リアルタイムでのプロセスインスタンスの介入または制御を可能にする。これは、プロセスインスタンスのプロセスステップが短い時間間隔で実行される場合（例えば、数秒以内に多数のコンポーネントが回路基板に実装される実装プロセスにおいて）、特に重要である。

プロセスプロトコルは、少なくとも、どのプロセスステップがどのオブジェクト（例えば、注文、生産品、ロジスティクスプロセス、組立プロセス）でいつ行われたのかについての情報を含む、すなわち、それぞれのプロセスステップについて、少なくとも、
−プロセスステップの識別子と、
−プロセスステップをプロセスインスタンスに一意的に割り当て可能である識別子と、
−プロセスインスタンス内のプロセスステップの順序と、を含む。

プロセスインスタンス内のプロセスステップの順序は、例えば、連続する一意の番号またはタイムスタンプ（例えば、プロセスステップの実行時点）によって指定できる。順序を指定する他の手法も、例えば、プロセスステップが、その後続のプロセスステップを参照することによって可能である。

さらにプロセスプロトコルによって、オブジェクトまたはプロセスインスタンスに関するマスターデータ情報、例えば、注文の数量および価格、商品の生産タイプ、ロジスティクスプロセスの輸送ルート、または低温殺菌プロセスの最大継続時間および最高温度を提供できる。このマスターデータ情報は、プロセスプロトコルに記憶するか、またはプロセスステップの識別子もしくはプロセスインスタンスの識別子を使用して参照できる。このマスターデータ情報はまた、補助データとも称する。

プロセスインスタンスは、複数のサブプロセスインスタンスを有することができ、サブプロセスインスタンスのプロセスステップは、異なるソースシステムにおいて実行できる。例えば、調達プロセス（＝プロセスインスタンス）は、注文プロセス（＝第１のサブプロセスインスタンス）および支払いプロセス（＝第２のサブプロセスインスタンス）を含むことができ、注文プロセスは、注文システムにおいて実行され、支払いプロセスは、会計システムにおいて実行される。生産プロセス（＝プロセスインスタンス）では、部品の研削（＝第１のサブプロセスインスタンス）は、研削盤で実行でき、部品の塗装（＝第２のサブプロセスインスタンス）は、塗装ロボットによって実行できる。

サブプロセスインスタンスの実行されたプロセスステップのプロセスデータは、別個のプロセスプロトコルに記憶できる。ただし、サブプロセスインスタンスのプロセスデータが共通のプロセスプロトコルに記憶されているか、またはマージされている場合に有利である。

具体的なプロセスインスタンスのプロセスステップはまた、以下ではプロセスパスとも称する。したがって、プロセスプロトコルは、複数のプロセスパスを有する。

コンピュータシステムにおいて実行されるプロセスインスタンスの場合、プロセスデータは、一般にこのコンピュータシステムによって提供される。プロセスインスタンスが実行されるコンピュータシステムはまた、ソースシステムとも称する。技術設備、例えば、生産機械によって実行されるプロセスインスタンスの場合、プロセスデータは、通常、それぞれの技術設備によって、例えば、測定値エンコーダによって（例えば、ねじ締めプロセスのトルクセンサおよび回転角センサによって）提供される。技術設備は、この場合もまたソースシステムと称する。したがって、ソースシステムは、プロセスインスタンスを実行するあらゆるシステムである。プロセスインスタンスが複数のソースシステムによって（例えば、第１のサブプロセスインスタンスがソースシステムＡによって、また第２のサブプロセスインスタンスがソースシステムＢによって）実行される場合、これらのソースシステムは、全体でソースシステムと称する。

以下では、「プロセス異常」という用語もまた使用される。プロセス異常とは、実行中のプロセスインスタンスにおいて発生する不具合であるか、または、所望しない結果をもたらすか、もしくは所定の目標プロセスから逸脱するプロセスインスタンスのシーケンスである。

プロセスプロトコルが、コンピュータシステムのメインメモリに記憶されている場合、好ましくは、プロセスインスタンスの連続するプロセスステップが、隣接するメモリセルに記憶されるように記憶されている場合に、有利である。したがって、プロセスステップは、連続するストリームとして、かつ正しい順序でメインメモリから読み出すことができる。したがって、手間のかかるソートを省略してもよい。

図１は、実行中のプロセスインスタンスを監視するためのサブ方法、およびプロセス異常を発見または検出するためのメカニズムを具体的に説明するための異常検出エンジンのブロック図を示す。

異常検出エンジンの基礎は、異常検出エンジン用にデータ入力を同時に形成するプロセスプロトコルである。異常検出エンジンは、プロセスプロトコルを監視し、プロセスプロトコルに記憶されているすべてのまたは選択されたプロセスインスタンスにおける異常を検出するように適合されている。

プロセスプロトコル内で、またはそのプロセスプロトコル内のプロセスインスタンスに対して検出されることとなる異常は、１つ以上のセンサ定義によって特徴付けられる。監視ステップでは、異常検出エンジンのセンサは、センサ定義を使用して、センサ定義に記述されたプロセス異常に関してプロセスプロトコルを監視する。同時に、センサは、プロセス定義、またはセンサ定義に記述されたプロセス異常を有する、１つのプロセスインスタンスまたは複数のプロセスインスタンスを含むプロセスを検出する。

センサ定義は、ビジネスプロセスにおける異常／問題だけでなく、技術プロセスにおける異常／問題にもまた適用できる。ビジネスプロセスの範囲内の例示的な状況は、購入プロセス、販売プロセス、請求プロセス、ＩＴサービス管理、ウェブ分析、またはマスターデータ管理である。技術プロセスの例には、ロジスティクスプロセス、生産プロセス、または組立プロセスが挙げられる。

本発明による異常検出エンジンを用いて監視し、かつ検出できる異常の様々な分類の例を以下に記載するが、異常のさらに別の分類もまた可能である。

−分類 時間超過：時間超過は、アクティビティＡの発生後、所与の期間以内にアクティビティＢが開始しないか、または実行されないことを特徴とする、すなわち、２つのアクティビティ間またはプロセスインスタンスのプロセスステップ間で所与の期間を超えている。

例：
−生産プロセスを実行するために、原材料を注文する必要がある。原材料は、所与の期間内に発注されないため、生産プロセスにリンクされた顧客の注文を顧客の希望期日に提供することはできない。
−牛乳の低温殺菌における規定の加熱継続時間を超えている。

−分類 時間不足：時間不足は、プロセスインスタンスの２つのプロセスステップ間の最小時間差を下回る場合に発生する。

例：
−サプライヤの危険物配送が指定された納期の前に行われ、危険物倉庫の保管量超過の原因となる。
−焼入れプロセスにおいて鉄鋼を硬化させるために必要な最小冷却時間が遵守されていない。

−分類 無許可プロセスパターン：無許可プロセスパターンは、例えば、プロセスインスタンスのプロセスステップの無許可の時系列順、またはプロセスインスタンスの複数のプロセスステップのプロセスパラメータの無許可の組み合わせを特徴とする。

例：
−注文した商品を受け取る前に、サプライヤの請求書を受け取る。
−機械の機械制御による組立の組立順序が遵守されていない。

−分類 責任の違反：例えば、プロセスインスタンスの２つの異なるプロセスステップが同一人物によって（または同一のオブジェクト／機械の技術プロセスにおいて）無許可で実行された場合、責任の違反が生じる。

例：
−サプライヤの請求書の承認およびその請求書の支払いが同一人物によって行われるため、四つ目原則に違反する。
−車両組立時の初期組立およびホイールベースの点検が同一の測定装置で実行される。

前述の異常の分類およびその分類に属する例は、個々のプロセスインスタンスまたは個々のプロセスパスにおける異常の検出に関連する。

プロセスインスタンス固有の異常の検知に加えて、本発明による方法はまた、プロセスインスタンスにわたって波及する異常の監視および検出も可能にする。このようにして、プロセス（＝このプロセスのインスタンス）全体について、プロセスが正常な状態か、または異常な状態かを判定できる。例えば、以下のタイプの異常を監視し、かつ検出できる。

−「累積」タイプの異常：「累積」タイプの異常は、複数のプロセスインスタンスにわたる特定のプロセスステップの発生の、時間に関して異常な累積を指す。この場合、「異常な」という属性は、静的に事前指定された参照値または過去に由来する動的に決定された値のいずれかを指してもよい。

例：
−顧客の注文のキャンセル率が、異常に大幅に増加している。
−生産プロセスにおける不良品発生率が統計的に有意に増加している。

−「リードタイム」タイプの異常：リードタイムの異常は、複数のプロセスインスタンスにわたる２つのプロセスステップ間のリードタイムの異常な時間的推移を表す。本発明による方法を用いて、静的基準値または過去のリードタイム値に由来する動的に決定された基準値からの有意な逸脱を決定できる。

例：
−承認プロセス（例えば、注文の作成から承認までの間の期間）が、複数のプロセスインスタンスにわたって突然異常に長い時間がかかる。
−生産システム内の製品の滞留時間が異常に長い値を呈する。

センサ定義は、データおよび／または指示を含み、データおよび／または指示を用いて監視ステップにおいて、所定の選択基準を満たすプロセスインスタンスおよび／またはプロセスが、プロセスプロトコルから選択される。所定の選択基準の例は、異常の分類または異常のタイプに関して上述した例である。

分類「時間超過」に関して上述した牛乳の低温殺菌時の加熱継続時間の例では、センサ定義の指示または選択基準は、「加熱ステップの加熱継続時間が８分よりも長いプロセス‘牛乳の低温殺菌’のすべてのプロセスインスタンスを見出すこと」という表現であってもよい。加熱継続時間は、タイマによって記録され、プロセスプロトコルに記憶するために提供される。プロセス「牛乳の低温殺菌」のプロセスインスタンスに対してプロセスステップ「加熱ステップ」が実行されるとすぐに、このプロセスステップについて、対応するエントリがプロセスプロトコルに作成される。加熱継続時間は、プロセスプロトコルに直接記憶できる。あるいは、このプロセスステップに対する加熱継続時間は、プロセスプロトコルから参照される外部テーブルに記憶できる。プロセスプロトコルに対応するエントリを作成した直後、このセンサ定義に従ってプロセスプロトコルを監視する異常検出エンジンのセンサは、この異常を検出し、この異常を修復するために、検出した異常を（以下でより詳細に説明する）異常修正エンジンに転送できる。

あるいは、牛乳の低温殺菌の加熱継続時間の直前で述べた例では、センサ定義の指示または選択基準は、以下のような表現であり得る。「加熱の開始から８分を超えて経過したプロセス‘牛乳の低温殺菌’のすべてのプロセスインスタンスを見出すこと」。加熱の開始は、プロセスプロトコルにおいて、例えば、タイムスタンプによって提示できる。したがってこの場合、加熱継続時間自体は、プロセスプロトコルに記憶されない。むしろ、それぞれのセンサは、加熱の開始から所与の加熱継続時間（この場合は８分）をすでに超過したかどうかを、（例えば、５秒ごとに）継続的に点検する。

この代替的センサ定義は、第１のセンサ定義に比べて、加熱ステップの実行中でも所与の加熱継続時間の超過を検出または認識できるという大きな利点がある（一方、第１のセンサ定義では、加熱ステップの終了後に初めて、所与の加熱継続時間の超過を検出できる）。それにより、異常修正エンジンは、対応するプロセス介入インスタンスを使用して進行中の加熱ステップにさらに介入でき、例えば、低温殺菌装置に加熱ステップをすぐに終了させる命令を提供できる。

本発明によれば、プロセスインスタンスおよびプロセス全体に関する上述した異常の分類およびタイプは、センサ定義に記述できる、すなわち、データおよび／または指示または選択基準を用いてセンサ定義において定義できる。

この場合、以下で説明する３種類のセンサ定義を提供できる。

−静的に決定されたパラメータを上回る／下回ることによる異常に対するセンサ定義（静的センサ）：プロセスインスタンス依存の異常の上記の例は、所与のパラメータ（時間間隔、プロセスアクティビティの設定順序など）が遵守されず、したがって、対応するプロセスインスタンスが異常を有することを、センサ定義において考慮に入れることができる。

−パターン認識を使用する異常に対するセンサ定義：プロセスインスタンス全体に波及する異常に関する上記の種類の「累積」および「リードタイム」の異常は、本発明によってサポートされるパターン認識の例を表す。過去の基準期間に基づいて、プロセスのプロセスインスタンスから典型的なパターンが抽出され、観察期間におけるこれらのパターンからの逸脱は、プロセス異常として認識できる。

例：
−異常検出エンジンのセンサは、調達プロセス（例えば、注文価格または注文数量の手動変更）の範囲における手動介入の割合を継続的にスキャンする。現在の週（＝観察期間）に、参照期間（例えば、前年）のレベルおよび割合の変動から大幅に逸脱している特徴が生じた場合、プロセス異常が検出され、このプロセス異常は、異常修正エンジンによって修復できる。
−生産プロセスでは、特定の製品は、特定の仕様に従って製造される。センサは、過去の生産量と比較して、観察期間中に生産量が突然著しく低下していることを検出する。異常修正エンジンは、生産プロセスに介入して、生産量を所望のレベルに戻すことができる。

−パターン認識を使用して動的に決定されるパラメータを上回る／下回ることによる異常に対するセンサ定義：上述の静的センサに加えて、本発明によれば、パターン認識プロセスを使用して異常を明確に区別するためのパラメータを動的に決定することが可能である。パラメータモデルを指定した後、この場合、パラメータの較正は、パターンに基づいて参照期間において行われる。そのように決定されたパラメータは、静的センサの場合と同様に、異常を検出するための基礎として考慮できる。

センサ定義またはセンサについての詳細な例を以下に記載する。

異常検出エンジンのセンサがプロセスプロトコルにおいて米国およびドイツからの未着の配送を検出できる、例示的なセンサ定義について考察する。

この例では、プロセスステップの少なくとも１つの識別子、プロセスステップをプロセスインスタンスに一意的に割り当てることができる識別子、およびプロセスインスタンス内のプロセスステップの順序（＝プロセスプロトコルの最小属性）を有するプロセスプロトコルは、センサが米国およびドイツからの未着の配送を検出することが可能となるための補助データにより補強されている。したがって、プロセスプロトコルは、プロセスプロトコルの最小属性および必要な補助データを含む。

この場合、前述のプロセスプロトコルの最小属性に加えて、補助データもまたセンサ定義の定義部に入力される。この例に関連するすべての構成要素を以下に示す。

１．プロセスプロトコルの最小属性、すなわち、プロセスインスタンスへの対応する割当を持つプロセスステップおよびそのプロセスステップの実行時点は、この場合、表「プロセスステップ」に記憶される。

「ＩＤ」の列は、プロセスインスタンスを示し、「プロセスステップ」の列は、プロセスインスタンス内のプロセスステップを示し、「エントリ時点」の列は、それぞれのプロセスステップが実行された日付を示す。これに加えて、「エントリ時点」の列によって、プロセスインスタンス内のプロセスステップの順序が決定されている。

２．注文の識別子（ＩＤ＝注文番号）およびそれぞれのサプライヤの識別子からなる（例えば、データベースにおいて表「注文」に記憶できる）すべての注文のリスト。この例によれば、センサ定義に対して必須ではないその他の属性、例えば、通貨および注文値を提供してもよい。

３．サプライヤに関する情報。この情報は、米国およびドイツからの未着の配送を限定するために必要であり、多くのソースシステムにおいて中央マスターデータテーブルの形式（この場合は表「サプライヤ」）で提供されている。この表は、サプライヤの少なくとも１つの識別子およびそれぞれのサプライヤに割り当てられた国を含む。この例によればセンサ定義に対して必須ではないその他の属性、例えば、サプライヤの電話番号を提供してもよい。

異常検出エンジンのセンサがプロセスプロトコルにおいて米国およびドイツからの未着の配送を検出できる、可能性があるセンサ定義の例は、（疑似コードによれば）以下のようになる。
ＦＩＬＴＥＲ
プロセスは、‘注文確認の受領’に等しい
かつ、プロセスは、‘商品の受領’と等しくない
かつ、プロセスは、‘リマインダを送信’と等しくない
かつ、“サプライヤ”．“国” ＩＮ（‘米国’，‘ドイツ’）
かつ、ＤＡＹＳ＿ＢＥＴＷＥＥＮ
（
ＰＵ＿ＭＡＸ（“注文”，“プロセスステップ”．“エントリ時点”，
“プロセスステップ”．“プロセスステップ”＝‘納期の確認’，ＴＯＤＡＹ（））
）＞＝７

フィルタ条件（ＦＩＬＴＥＲ）は、指定された基準についてプロセスプロトコル全体を検査し、基準に違反していることにより異常を有する注文を正確に返す。

「プロセスは、〜に等しい」という３つの式は、データベースを、サプライヤの注文確認がすでに受領されているが、商品がまだ受信されておらず、リマインダが送信されていない注文に限定する。すなわち、プロセスプロトコルは、（商品が受領されていないという意味で）未処理注文に低減される。

供給元に対する条件（“サプライヤ”．“国” ＩＮ（‘米国’，‘ドイツ’））により確実に、所望の用途に応じてドイツおよびアメリカの供給元のみが考慮される。一般に、この場合、プロセスプロトコルの任意の属性を使用できる。

最後に、条件「ＤＡＹＳ＿ＢＥＴＷＥＥＮ．．．」は、（この場合には時間超過に対して）異常条件を指定する。検討時点と最後に確認された納期との間が少なくとも７日であるとすぐに、配送が遅延していると見なされ、したがって、異常が表示される。

関数ＰＵ＿ＭＡＸは、注文書に対して将来の最も遅い日付を正確に決定するために提供されている。

上記のセンサ定義を有する異常検出エンジンのセンサが、プロセスプロトコルの上記の例に適用される場合には、検討時点２０１８年２月１２日（例えば、センサの実行時点）に、注文１０８２９３８２（１９日の遅延）および１０１８２７３１（７日の遅延）に対して異常が生じている。それに対して、注文２０１７３６２１が異常を示していないのは、とりわけ、商品がすでに受領されており、したがって、「プロセスは、‘商品の受領’と等しくない」という条件が満たされていないためである。

センサ自体は、所与の固定した時点、例えば、２日ごとまたは毎週月曜日および水曜日に実行できる。あるいは、センサの実行は、表「プロセスステップ」に入力することによってトリガできる、すなわち、この表に新しいエントリが追加されるとすぐに、センサが実行される。プロセスプロトコルにエントリを追加することによってセンサをトリガすることは、リアルタイムまたはほぼリアルタイムで異常を検出する必要がある場合に有利であり得、リアルタイムで検出された異常もまた修復できる。

センサ定義には、任意のプロセスステップおよびプロセス属性を含むことができ、これらに対する任意の算術演算を異常検出のために実行できる。注文プロセスの例は、上記のように記載されている。対応するセンサ定義はまた、技術プロセス（例えば、生産プロセス）に対しても決定できる。センサ定義のための選択肢は、最終的にはプロセスプロトコルに記憶されたデータによってのみ制限されている。

したがって、例えば、センサ定義は、部品を塗装ロボットで塗装する自動車産業における塗装プロセスのために定義できる。塗装プロセスの後、測定器は、塗布された塗装厚さを測定し、対応するプロセスインスタンス（＝塗装プロセス）に対するこの測定値をプロセスプロトコルに記憶できる。異常検出エンジンの対応するセンサは、このプロセスプロトコルを監視し、部品に塗布された塗装層が薄すぎる場合に検出できる。次いで、異常検出エンジンは、検出されたプロセスインスタンスに関する情報を、以下に説明する異常修正エンジンに提供でき、次いで、異常修正エンジンは、対応して適合されたプロセス介入インスタンスを生成できる。プロセス介入インスタンスを用いて、異常修正エンジンは、対応する部品にさらに別の塗装層を塗布するように塗装ロボットに指示できる。このセンサに対して可能なセンサ定義は、（疑似コードによれば）以下のように表現してもよい。
ＦＩＬＴＥＲ
プロセスは、“塗装プロセス完了”に等しい
かつ、プロセスは、“部品が塗装室を出た”に等しくない
かつ、“部品”．“塗装厚さ”＜１．５ｍｍ

このセンサ定義によるセンサは、塗装プロセスが完了しており、塗装厚さが１．５ｍｍ未満であり、かつ、対応する部品が塗装室をまだ出ていない、すべてのプロセスインスタンス（塗装プロセス）を返す。次いで、異常修正エンジンは、部品をもう一度塗装するように塗装ロボットに指示できる。

上記のセンサ定義において、第２の条件が
かつ、プロセスは、「部品が塗装室を出た」に等しい
に置き換えられた場合には、異常修正エンジンは、部品をもう一度塗装するために、運搬装置（例えば、倉庫ロボット）に部品を塗装室に運搬させてもよい。

上記のセンサ定義およびプロセスプロトコルに基づくセンサを使用する異常検出は、複数の技術的利点をもたらし、その一部を以下に挙げる。

−ソースシステムの潜在的に複数の構成要素（プロセスプロトコルおよび補助データの最小属性）をマージすることにより、プロセスインスタンス内のプロセスステップの順序に加えて、プロセスステップ間の依存関係もまたさらに考慮できるセンサを提供することが可能となる。この依存関係は、その上、複数のプロセスおよびプロセスタイプにまで及ぶ可能性がある。すなわち、センサは、異なるプロセスのプロセスインスタンスに属しているか、または全く同一のプロセスの異なるプロセスインスタンスに属しているプロセスステップ間の依存関係を考慮できる。したがって、例えば、企業における生産プロセス、ロジスティクスプロセス、および販売プロセスをリンクでき、それによって、センサは、複数のプロセスインスタンスにわたる異常を検出できる。例：生産プロセスにおける異常（例えば、生産プロセスにおける時間超過）は、以前に実際に予約された運送業者が利用できないことを伴って合現れてもよく、これは、確認された納期での顧客への供給に影響を与える可能性がある。包括的なセンサを定義することにより、起こりそうな予定の遅延は、生産が中断した時点ですでに認識できる。

−複数のシステムランドスケープを考慮に入れることができる。特異な異常検出システムは、単一システムであるため、システムランドスケープ内（例えば、特定のシステム内、例えば、ＳＡＰ（登録商標）システム内または生産施設内で実行されるプロセスまたはプロセスインスタンスの場合）の逸脱を検出することのみが可能である。プロセスプロトコルを使用して、異なるシステムで実行されるプロセスまたはプロセスインスタンスは、マージでき、したがって、センサによって監視できる。例：注文プロセスおよび生産プロセスは、特定の製品に対して時間的に順番に実行され、併せて調達プロセスを形成する。ＳＡＰシステムにおいて実行される注文プロセスのプロセスデータおよび生産機械によって実行される生産プロセスのプロセスデータは、共通のプロセスプロトコルに記憶される。したがって、注文プロセスおよび生産プロセスは、異なるシステムで実行されるが、センサは、調達プロセス全体を監視し、調達プロセス全体の異常を検出できる。

−本発明のさらに別の技術的利点は、３種類のセンサ定義（静的パラメトリックモデル、パターン認識、動的パラメータ化モデル）に由来して生じる。特に、センサ定義は、パターン認識および動的パラメータ化モデルを使用して、手動では実行できない、すなわち、本発明によるコンピュータ実装方法の支援下でのみ可能である自動異常検出を可能にする。

−さらに、様々なセンサを統合的信号に集約でき、それによって、上位センサは、根本的なプロセスの弱点を検出するために提供できる。したがって、個々のセンサからの異種の単一信号を並列に記録し、同時に評価できる。

上位センサはまた、メタセンサとも称する。メタセンサは、既存のセンサを入力として使用するため、メタセンサは、既存のセンサを監視するセンサと見なすことができる。これにより、例えば、複数のセンサにわたって特定の異常の累積を検出することが可能になり、これは、以下の例に基づいてより詳細に説明される。

異常検出エンジンにおいて、特定の異常に関してプロセスプロトコルを監視し、これらの異常を検出する様々な個別のセンサが定義されている。例えば、
−サプライヤによる注文書において注文価格の上昇を検出するセンサ、
−サプライヤによる注文書において納期の延期を検出するセンサ、および
−顧客による顧客からの委託において照会があった配送数量の増加を検出するセンサ。

これらの３つのセンサは、例えば、属性「材料番号」を共通とする、すなわち、対応する異常が検出された場合、センサは、対応するプロセスインスタンスの材料番号を含むデータを提供できる。例えばこの場合、例えば、材料番号に関して「累積」タイプの異常を検出するメタセンサを提供できる。この例で提供されるメタセンサは、この場合、例えば、現在の週に（この場合は材料番号で示される）特定の材料に対する個々のセンサにわたって累積があることを検出できる。この累積は、この材料の不足が起こることを示唆している可能性がある。

メタセンサもまた実行かつ制御する異常検出エンジンは、この場合、異常修正エンジンに検出された累積に関する情報を提供できる。それに続いて、異常修正エンジンは、対応するプロセス介入インスタンスを生成でき、このプロセス介入インスタンスを用いて、例えば、追加の材料を代替サプライヤにおいて注文することなどによって、商品管理システムにこの材料の在庫をアクティブかつ自動的に構築させる。

このような累積が、コンピュータシステムを使用してのみ認識できるのは、一方では、特定の累積をもたらす可能性のあるすべての様々な異常を多数のセンサが検出でき、他方では、特定の累積にそれぞれ異なる量的影響を及ぼす可能性がある非常に多数のプロセスインスタンスをそれぞれのセンサが検出できるためである。

上記のセンサおよびセンサ定義を用いて、プロセスインスタンスにおける異常をプロセスインスタンスの実行中に検出できる。センサを実行する異常検出エンジンは、検出されたプロセスインスタンスまたは検出されたプロセスインスタンスに関する情報を、検出されたプロセスインスタンスにおける異常を解消するように適合されている異常修正エンジンに転送する。この場合、検出されたそれぞれのプロセスインスタンスの実行中に異常が解消されるため、プロセスインスタンスに積極的に介入し、例えば、プロセスインスタンスのその後のシーケンスが制御される。さらに、異常検出エンジンは、センサがプロセスインスタンスを検出したことに基づいて、異常修正エンジンにセンサ定義（またはセンサ）を転送する。

図２は、実行中のプロセスインスタンスを修正するためのサブメソッドを具体的に説明するための異常修正エンジンのブロック図を示す。この場合、「修正」とは、プロセスインスタンスの異常が修復されるか、または解消されることを意味する。この場合、異常検出エンジンおよび異常修正エンジンは、通信ネットワークに接続された様々なシステム上で実行できる。

したがって、異常修正エンジンは、可能なあらゆるセンサ定義または可能なあらゆるセンサに一般的アクションの集合が割り当てられるように構成される。センサに割り当てられた一般的アクションは、このセンサによって検出されたプロセスインスタンスを「修正」するために使用できる。

異常修正エンジンが、それぞれのセンサ定義とともに、またはそれぞれのセンサとともに、異常検出エンジンからプロセスインスタンスを受信した後、少なくとも１つの一般的アクションは、一般的アクションの集合から選択される。センサに割り当てられた一般的アクションの集合にいくつかの一般的アクションが割り当てられている場合、以下で詳細に説明するように、一般的アクションの選択は、例えば、それぞれのプロセスインスタンスの１つ以上の属性値に基づいて、または最適なアクションが決定されるシミュレーションに基づいて行うことができる。

一般的アクションはそれぞれ、異常なプロセスインスタンスを修正できる特定のアクションを定義し、一般的アクションの定義は、ソースシステムから独立している。例えば、ＳＡＰ（登録商標）システムにおいて実行されるプロセスインスタンスまたはＳａｌｅｓｆｏｒｃｅ（登録商標）システムで実行されるプロセスインスタンスにおける対応する異常を修復できる、一般的アクション「リマインダの生成」が定義されている。

選択された一般的アクションに基づいて、検出されたそれぞれのプロセスインスタンスに対して固有のプロセス介入インスタンスが生成される。プロセス介入インスタンスは、一般的アクションとは異なり、ソースシステムに依存している。上記の例では、ＳＡＰ（登録商標）システムおよびＳａｌｅｓｆｏｒｃｅ（登録商標）システムに対して、一般的アクション「リマインダの生成」に対してそれぞれ異なるプロセス介入インスタンスが生成されるであろう。

同様にして、プロセス介入インスタンス自体は、具体的に検出されたプロセスインスタンスにおける異常を修復できるように適合される。この適合は、例えば、プロセス介入インスタンスのパラメータを介して行うことができ、それぞれのプロセスインスタンスの属性値、例えば、プロセスインスタンスの一意の識別子をプロセス介入インスタンスに転送できる。他の種類のそのような適合も同様に可能である。

次いで、プロセス介入インスタンスは、ソースシステム（検出されたプロセスインスタンスが実行されるシステム）によって実行可能な命令に変換される。次いで、これらの命令は、異常修正エンジンから対応するソースシステムに転送され、そのソースシステムにおいて実行される。

本発明の一実施形態では、プロセス介入インスタンスは、複数のアクティビティを含むことができる。これらのアクティビティは、同様にソースシステムによって実行可能な命令に変換され、次いで、異常修正エンジンから対応するソースシステムに転送され、そのソースシステムにおいて実行される。この実施形態は、検出されたプロセスインスタンスの異常を修復する場合、
−例えば、相互に独立した複数のアクティビティをソースシステムにおいて実行する必要がある場合、または
−様々なソースシステムにおいて複数のアクティビティを実行する必要がある場合に、特に有利である。例えば、塗装ロボットによる塗料の塗布が薄すぎると、確約した納期が遅延するおそれがある。この異常を修復するための一般的アクションは、「塗装ステップを繰り返す」であってもよい。この一般的アクションに基づいて、第１のアクティビティおよび第２のアクティビティを含むプロセス介入インスタンスが生成される。第１のアクティビティを用いて、塗装ロボットに追加の塗装層を塗布するように指示できる。第２のアクティビティを用いて、ＥＲＰシステムに、新しい納期を顧客に通知させることができる。両方のアクティビティに対して、異常修正エンジンは、対応する命令を生成し、それらの命令を塗装ロボットまたはＥＲＰシステムに転送する。

本発明によれば、２種類のプロセス介入インスタンスまたはアクティビティが提供される。すなわち、
−非侵襲的アクティビティまたはプロセス介入インスタンス、および
−侵襲的アクティビティまたはプロセス介入インスタンスである。

非侵襲的アクティビティまたはプロセス介入インスタンスは、影響を受けるソースシステムの外部で実行されるアクティビティを指す。本発明によれば、この場合、プロセスプロトコルからの任意の情報を使用できる。

例えば、危険物保管量超過（異常分類の時間不足に関する上記の例を参照）の場合、保管量超過の原因となっている品目の製品グループまたは供給メーカーを特定し、かつ視覚化できる。

プロセスプロトコルからの情報の静的な視覚化に加えて、異常修正エンジンはまた、動的な情報計算もサポートする。したがって、例えば、危険物倉庫に対して、顧客への既存の分割納品を利用して、どの容量がいつ空くのか、かつそれによりさらなる介入なしにいつ保管量超過が終了するのかを自動的に計算できる。

非侵襲的アクティビティのさらに別の例は、プロセスプロトコルに基づいてプロセスインスタンスのプロセス全体を視覚化し、かつ評価できるプロセス分析を呼び出すことである。例えば、プロセスインジケータなどの追加情報を計算し、かつ表示できる。この目的のために、異常修正エンジンは、検出された異常をプロセスプロトコルに関連付けられたプロセス分析にリンクできるため、検出された異常に対して、根本的なプロセスの分析を直接実行できるアクティビティを実行できる。分析に必要な情報は、プロセスプロトコル（プロセスプロトコルの最小データおよび補助データ）に含まれており、プロセスプロトコルの最小データおよび補助データは、対応して互いにリンクされている。その結果、プロセスプロトコルは、特定のプロセスインスタンスまたは特定のプロセスのプロセスインスタンスに関して容易な手法でフィルタリングできるため、これらのプロセスインスタンスに割り当てられたデータのみが分析にまた含まれる。これにより、検出された異常を簡単に検証できるようになる。

一方、侵襲的アクティビティまたはプロセス介入インスタンスは、影響を受けるソースシステム内で実行されるアクティビティに関連しているため、異常を修復するか、または実行中のプロセスインスタンスにおいて積極的に改善するために、ソースシステムにおける変更をトリガする。

侵襲的アクティビティは、
−コンピュータシステムにおいてのみ実行されるか、
−技術的装置（例えば、組立機械）によってのみ実行されるか、または
−一部はコンピュータシステムにおいて実行され、一部は技術的装置を介して実行される、
命令を含むことができ、それぞれの異常を修復する。

注文商品を受け取る前にサプライヤからの請求書を受け取ったことによる不正なプロセスパターンの上記の例では、異常修正エンジンによって生成されたプロセス介入インスタンスは、侵襲的アクティビティを含むことができ、その侵襲的アクティビティを用いて、支払い停止は、ソースシステム（例えば、注文プロセスが実行されるＥＲＰシステム）内の対応する注文に対して設定される。その結果、異常修正エンジンは、プロセスインスタンスのシーケンスにおいて対応するプロセス介入インスタンスに介入する。

機械を組み立てる場合の誤った組立順序の上記の例では、異常修正エンジンは、侵襲的アクティビティを伴うプロセス介入インスタンスを生成でき、侵襲的アクティビティは、組立機械に、これから組み立てられることとなる部品の組立順序を変更させる。

生産プロセスにおける時間超過の上記の例では、第１の侵襲的アクティビティを使用して、時間通りに完了するために機械によって実行される後続の生産ステップの加速をトリガできる。追加的にまたは代替的に、第２の侵襲的アクティビティを使用して、ＥＲＰシステムに、配送の遅延について貨物輸送業者および顧客に通知させることができる。同時に、これは、命令を部分的にコンピュータシステムにおいて実行でき、部分的に技術デバイスによって実行できることについての例である。

危険物倉庫の保管量超過が発生した場合、異常修正エンジンは、プロセス介入インスタンスを生成でき、このプロセス介入インスタンスを用いて、追加の容量を作成するために、倉庫在庫の自動再割当または保管された危険物の早期引渡しをトリガできる。

本発明によれば、３種類のプロセス介入インスタンスを生成できる。
−静的に生成されたプロセス介入インスタンスは、異常に割り当てられたプロセスプロトコルから静的に取得された情報の再現に制限できる。これには、例えば、配送の遅延が発生した場合のサプライヤ番号および参照ドキュメント番号、プロセスコンプライアンス違反の場合に作業中の人物、または低温殺菌プロセスの時間超過の継続時間など、異常の属性の表示が含まれる。
−動的に生成されたプロセス介入インスタンスの場合、プロセスプロトコルを上回る、異常のメタ情報およびソースシステムのメタ情報が含まれる。この結果は、例えば、プロセスプロトコルに関連付けられたプロセス分析との異常のリンク、またはソースシステムにおいて実行可能なアクティビティ（＝侵襲的アクティビティ）の生成である。
−第３の種類によれば、プロセス介入インスタンスを生成するために、シミュレーションを使用して、一般的アクションの集合から最適なアクションが決定される。例えば、可能性があるすべての一般的アクションに対して、アクションがプロセスインスタンスに適用された場合にプロセスインスタンスのリードタイムがどのように変化するかを決定でき、それぞれのアクションは、決定されたリードタイムが設定リードタイムに最も近いプロセス介入インスタンスを生成するために選択できる。

異常検出エンジンのセンサが米国およびドイツからの未着の配送を検出する上記の例に関係して、望ましいアクションは、影響を受けるサプライヤに適切にリマインドすることであってもよい。これが動的に生成された侵襲的なアクションについての例であるのは、一方では、異常の属性がプロセス介入インスタンスの生成に含まれ、他方では、プロセス介入インスタンスの直接実行（実行可能命令の形式）が行われ、それによりソースシステムにおける変更がもたらされるためである。この場合、「動的」とは、例えば、関連するサプライヤに適切にリマインドするために、サプライヤ番号がプロセス介入インスタンスの生成に含まれることを意味する。「侵襲的」とは、リマインダがソースシステムにおいて直接生成されることを意味する。

上記のプロセス介入インスタンスおよびその生成は、複数の技術的利点をもたらす。その一部を以下に示す。
−一般的アクションは、システム内の任意のモジュールおよび異なるソースシステムに対して均一に定義できる。プロセス介入インスタンスが実行される場合に初めて、ソースシステム固有の命令を生成する必要があり、この命令はまた、本発明の一実施形態では、異常修正エンジンがソースシステムに生成のために必要な情報を提供する場合、ソースシステム自体によって生成することもできる。特に、異常を修復するために複数のシステムにおいて同時に侵襲的な介入を必要とする異常は、全体的なプロセスを積極的に制御するために必要な前提条件である。
−さらなる利点は、プロセスプロトコルに関連付けられたプロセス分析との異常の説明されたリンクを提示する。これにより、異常を適切に調査し、異常のプロセスフローを詳細に理解し、最適なアクションの選択肢を選択する、効率的な方法が提供される。
−さらなる重要な技術的利点は、シミュレーションを使用して最適なアクションを決定することである。このようにして、例えば、製造工程における組立順序の様々な配置の影響、または危険物在庫の増加を、計画納期を調整してシミュレーションし、最適な選択肢を選択できる。ただし、実行中のプロセスインスタンスにおいて手動で「試行」することは不可能である。

本発明のさらなる態様によれば、効果的なプロセス制御のために、責任がある作業中の製造加工業者へのプロセス介入インスタンスの割当を提供できる。本発明のこの態様について、ルーティングエンジンのブロック図を示す図３を参照してより詳細に説明する。ルーティングエンジンのタスクは、特定のユーザに対してプロセスプロトコルを、そのプロセスプロトコルにおいて発生するすべての異常が、そのユーザによって処理されるプロセスインスタンスと一致するように既に制限していることである。

ルーティングエンジンの受信パラメータは、プロセスプロトコル、（プロセスプロトコルの属性であってもよい）割当属性、および特定のユーザに割り当てられる割当属性の特性（値）である。

例：
−注文プロセスにおける購入品目に対して、ソースシステムの材料マスタを介して購入された材料に割り当てられている特定の購入者は、権限がある。この場合、割当属性は、材料番号であり、購入者に割り当てられた割当属性の値は、個々の購入品目の材料番号である。

受信パラメータに基づいて、ルーティングエンジンは、特定のユーザに対して、割当属性のすべての特徴およびユーザに割り当てられた特徴に関してプロセスプロトコルを比較し、ユーザに割り当てられた割当属性の特徴に関して一致するプロセスプロトコルのそれぞれの部分を返す。結果は、異常検出エンジンによって監視できるフィルタリングされたプロセスプロトコルである（図４もまた参照）。

ルーティングエンジンの技術的な利点は、プロセスプロトコルがユーザに関連するプロセス異常に自動的に制限されることである。プロセスプロトコル内の通常は非常に多数の個々のプロセスインスタンス（数百万）を考慮すると、手動割当は不可能である。

さらに、プロセスプロトコルの属性に加えて、異常の属性もまた割当に含むことができ得る。ルーティングエンジンを使用するプロセスインスタンスの個々のユーザへの割当は、実際に異常検出エンジンが、異常があるプロセスインスタンスを検出し、異常修正エンジンがプロセス介入インスタンスを生成するが、プロセス介入インスタンスの実行がユーザによって確認される必要がある場合に有利である。ユーザの介入が不要な場合では、ユーザへの割当もまた省略できる。

上記の生産プロセスの時間超過の例によれば、製造加工業者の割当は、最初に生産契約における対応する割当を介して行われるべきである。プロセスインスタンスに改善がなく、完了がさらに遅れる場合、プロセスインスタンスをプラントマネージャに割り当てる別の属性を介して、割当を行うべきである。本発明によれば、プロセスインスタンスがプロセス介入インスタンスを使用して介入された後でもまた、プロセスインスタンスは、異常検出エンジンによって引き続き監視されることがもたらされている。したがって、異常検出エンジンは、製造加工業者によって確認されたプロセス介入インスタンスの後に時間超過が引き続き存在するかどうかを確定できる。

さらに、上記で概要を示したプロセス異常の増大がルーティングエンジン内に原則として記憶されている場合に有利であり得る。

本発明の一実施形態では、プロセス介入インスタンスを生成するための可能な一般的アクションの集合を、それぞれの増大段階に応じて設定することが有利であり得る。例えば、一般的アクション「機械の電源を切る」は、対応するプロセス介入インスタンスを生成するために工場管理者のみが利用でき、通常の従業員は利用できない。

ルーティングエンジンのさらなる重要な利点は、異常検出エンジンによる監視のためのプロセスプロトコルを大幅に削減できることである。したがって、非常に多数のプロセスインスタンス（通常は数百万）の場合に特に、プロセスプロトコルの効率的な監視を保証できる。

図４はプロセス介入エンジンのブロック図を示し、特定のセンサに対する異常検出エンジン、異常修正エンジンおよびルーティングエンジンの関係は、このブロック図に由来する。

特定のプロセス異常を特定するためのセンサの構成は、プロセスプロトコル、異常の基準（センサ定義）、この異常についてプロセスプロトコルを定期的に確認する時間間隔、割当ルール、および異常修復のために可能なアクションの確定された集合を含む。

センサ構成に基づいて最初に、ユーザについてフィルタリングされたプロセスプロトコルの（任意選択の）計算は、割当ルールに基づいて行われる。次いで、必要に応じてフィルタリングされたこのプロセスプロトコルは、異常検出エンジンで使用できるようになる。異常検出エンジンは、フィルタリングされたプロセスプロトコルを監視し、その監視から、センサ定義に対応する、すなわち、センサ定義に従って異常を有するそれぞれのプロセスインスタンスを決定する。決定または検出されたプロセスインスタンスに対して、さらなるステップでは、プロセス介入インスタンスが生成され、それぞれのソースシステムにおいて実行される。

本発明のさらなる態様によれば、通知エンジンを提供でき、その通知エンジンを用いて、発生したプロセス異常（＝異常を有するプロセスインスタンス）に関してユーザに通知できる。通知エンジンのブロック図は、図５に示されている。

図４に示すプロセス介入エンジンとは異なり、通知エンジンは、単一のセンサに関係するのではなく、様々なセンサにわたって特定のユーザに割り当てられているすべての異常を含む。したがって、ユーザに通知するための開始点は、ユーザに割り当てられたすべてのプロセス介入インスタンスの集合である（図５でプロセス介入ストアとして指定）。この集合は、センサの頻度（センサ間隔）に応じてセンサ構成において継続的に更新され、新しく出現する異常は、経時的に収集される。

プロセス介入ストアに加えて、プロセス介入レジスタは、通知において重要な役割を果たす。過去の通知時にユーザに既に割り当てられていた異常は、プロセス介入レジスタに記録されるか、または登録される。

新しい異常、すなわち、最後の通知以降に発生した異常の集合は、プロセス介入ストアをプロセス介入レジスタと比較することによって決定される。それに加えて、プロセス介入レジスタにまだ含まれていないプロセス介入インスタンスは、プロセス介入インスタンスの状況が継続的に検証される。この場合、その状況は、異常の有効性を含んでもよい。次の通知の前に新しい異常が修復された場合、この異常をプロセス介入ストアから削除して元に戻すことができるか、または無効としてマークできる。あるいは、プロセス介入レジスタに転送すべきそれぞれの異常について、この異常がまだ存在するかどうかを検証できる。この検証は、異常検出エンジンを使用して実行できる。対応する通知の比較および送信は、通知間隔において規定された時間（例えば、月曜日から金曜日まで毎日１１時および１５時）に行われる。ユーザは、まだプロセス介入レジスタの構成要素ではなく、通知の時点でまだ存在する、バンドルされた異常を含む通知を受け取る。

異常検出エンジンのセンサによる検証のための間隔を分離して通知を送信することによって、プロセス介入インスタンスの適時性をユーザ通知とは独立して制御できる。すべてのセンサにわたる異常をバンドルすることによって、ユーザは、集中的な方法で通知を受けることができる。異常の状態を考慮することにより、権限のある製造加工業者には、実際に存在する異常に関してのみ確実に通知される。

図６は、本発明のシステム全体のブロック図を示す。

異常修正エンジンと通知エンジンとの相互作用によって、異常が認識され、この目的のために、異常を修復するためのプロセス介入インスタンスが生成され、通知が送信されることで、異常の修正が促進される。

図７は、実行中の具体的なプロセスインスタンスに基づく、ソースシステム、プロセスプロトコル、異常検出エンジンおよび異常修正エンジンの相互作用を示す。この例では、プロセスインスタンスは、２つのサブプロセスインスタンスＰ１およびＰ２を含む。

サブプロセスインスタンスＰ１は、この場合すでに４つのステップ、すなわち、「オファーを作成」、「納期を確認」、「生産を委託」、および「運送業者に通知」が実行された販売プロセスである。サブプロセスインスタンスＰ１は、ＥＲＰシステムにおいて実行された。

サブプロセスインスタンスＰ２は、特定の既成部品が顧客の要求に従って塗装される生産プロセスである。サブプロセスインスタンスＰ２では、すでに３つのステップ、すなわち、「部品の要求」（例えば、部品倉庫から）、「部品の塗装」（塗装後に部品を乾燥する）、および「塗装厚さの測定」が実行された。サブプロセスインスタンスＰ２は、塗装厚さを測定するための適切なセンサを有する塗装ロボットによって実行された。

サブプロセスインスタンスＰ１およびＰ２（ステップＳ１およびＳ２）において実行される２つのステップについて、対応するエントリは、プロセスプロトコルにおいて生成される。図７では、簡単にするために、それぞれのプロセスステップの実行時点および識別子のみが示されている。サブプロセスインスタンスＰ２のステップ「塗装厚さを測定」では、測定された塗装厚さもさらにプロセスプロトコルに記憶される。プロセスプロトコルにおけるエントリは、有利には、対応するステップが実行された直後に生成される。

異常検出エンジンのセンサは、継続的に（例えば、２分ごとに）プロセスプロトコルを監視する。図７に示す例によれば、センサ定義は、センサがプロセスプロトコルを監視し、測定された塗料厚さが３ｍｍ未満であるプロセスインスタンス内でステップ「塗料厚さ測定」が実行されたかどうかを判定することを提供する。

この例では、ステップ「塗料厚さを測定」において、１．５ｍｍの塗装厚さが測定された。３ｍｍ未満の塗装厚さは、本発明の文脈においてプロセス異常を表す。最小塗装厚さ３ｍｍの値は、この場合は固定して与えられている。ただし、その値はまた、例えば、注文顧客の要件から動的に指定してもよい。

センサが上記のプロセス異常を検出したため、本発明によれば、このプロセス異常を修復することが提供される。この目的のために、異常検出エンジンは、どのプロセスインスタンスにおいて、どの異常が発生したかを異常修正エンジンに通知する。図７による例では、異常検出エンジンは、プロセスプロトコルにおいて指定されたプロセスインスタンスが薄すぎる塗装厚さを測定したことを、異常修正エンジンに通知する。

この固有のプロセス異常に対して、異常修正エンジンは、このプロセス異常を修復できる一般的アクションの集合（図７には図示せず）から、それぞれの一般的アクションを選択する。本例では、これらのアクションは、一般的アクション「納期を延期」および「再塗装」である。したがってこの場合、一般的アクション「納期を延期」が必要となるのは、部品を再塗装することによって、運送業者に引き渡すための部品の提供が遅延するためである。

異常修正エンジンは、選択された一般的アクションからプロセス介入インスタンスを生成する。プロセス介入インスタンス「納期を延期」は、異常修正エンジンから、第１のサブプロセスインスタンスＰ１が実行されたＥＲＰシステムに転送される（ステップＳ３）。プロセス介入インスタンス「再塗装」は、異常修正エンジンから、第２のサブプロセスインスタンスＰ２が実行された生産システムのシステム（例えば、塗装ロボット）に転送される（ステップＳ４）。一般的アクションからプロセス介入インスタンスを生成する場合、プロセス介入インスタンスは、いくつかのパラメータを使用して適合され、パラメータの値は、確実に事前指定されていてもよいか、または、例えば、現在のプロセスインスタンスに応じて設定されてもよい。したがって、一般的アクション「納期を延期」は、納期を延期するために、異なるプロセスの異なるプロセスインスタンスに対して使用できる。本例では、異常修正エンジンは、部品の塗装および乾燥のための継続時間ならびに塗装ロボットの可用性から、部品の可用性の遅延を計算でき、この遅延（例えば、３６時間）は、プロセス介入インスタンス「納期を延期」のパラメータとして転送できる。

異常修正エンジンは、パラメータ化されたプロセス介入インスタンスをそれぞれのソースシステムに直接転送できる。次いで、ソースシステムは、それぞれのプロセス介入インスタンスを、それぞれのソースシステムで実行可能な命令に変換できる。

しかしながら、代替的かつ有利には、異常修正エンジンが、プロセス介入インスタンスからそれぞれのソースシステムによって実行可能な対応する命令を生成し、次いで、これらの命令をそれぞれのソースシステムに転送することが提供されている。これには、プロセス介入インスタンスから実行可能な命令を生成するために、ソースシステムを適合させる必要がないという利点がある。したがって、プロセス介入インスタンスからの命令の作成は、異常修正エンジンによって集中的に実行できる。異常修正エンジンは、命令が利用可能とされるべきそれぞれのソースシステムに応じて、対応する命令を生成する。

次いで、プロセス介入インスタンスまたは関連する命令は、それぞれのソースシステムによって実行される。次いで、（実行された命令に従って）対応するステップについて、エントリを同様にしてプロセスプロトコル（図７に図示せず）において生成でき、このエントリを同様にして異常検出エンジンのセンサによって監視できる。したがって、再塗装に対して、エントリ「２０１８年４月１９日１２時００分 部品を再塗装」、「２０１８年４月１９日１２時３０分 乾燥プロセス開始」、「２０１８年４月１９日１２時４３分 乾燥プロセス終了」、「２０１８年４月１９日１２時３２分 塗装厚さを測定 塗装厚さ３．０５ｍｍ」をプロセスプロトコルにおいて生成してもよい。塗装厚さが３ｍｍを超えているため、プロセスプロトコルを監視するセンサのセンサ定義に従って異常が修復されたと見なされる。

図７は、実行中の具体的なプロセスインスタンスに基づく、ソースシステム、プロセスプロトコル、異常検出エンジンおよび異常修正エンジンの相互作用を示す。この例では、プロセスインスタンスは、２つのサブプロセスインスタンスＰ１およびＰ２を含む。

サブプロセスインスタンスＰ１は、この場合すでに４つのステップ、すなわち、「オファーを作成」、「納期を確認」、「生産を委託」、および「運送業者に通知」が実行された販売プロセスである。サブプロセスインスタンスＰ１は、ＥＲＰシステムにおいて実行された。

サブプロセスインスタンスＰ２は、特定の既成部品が顧客の要求に従って塗装される生産プロセスである。サブプロセスインスタンスＰ２では、すでに３つのステップ、すなわち、「部品の要求」（例えば、部品倉庫から）、「部品の塗装」（塗装後に部品を乾燥する）、および「塗装厚さを測定」が実行された。サブプロセスインスタンスＰ２は、塗装厚さを測定するための適切なセンサを有する塗装ロボットによって実行された。

サブプロセスインスタンスＰ１およびＰ２（ステップＳ１およびＳ２）において実行される２つのステップについて、対応するエントリは、プロセスプロトコルにおいて生成される。図７では、簡単にするために、それぞれのプロセスステップの実行時点および識別子のみが示されている。サブプロセスインスタンスＰ２のステップ「塗装厚さを測定」では、測定された塗装厚さもさらにプロセスプロトコルに記憶される。プロセスプロトコルにおけるエントリは、有利には、対応するステップが実行された直後に生成される。

異常検出エンジンのセンサは、継続的に（例えば、２分ごとに）プロセスプロトコルを監視する。図７に示す例によれば、センサ定義は、センサがプロセスプロトコルを監視し、測定された塗料厚さが３ｍｍ未満であるプロセスインスタンス内でステップ「塗料厚さを測定」が実行されたかどうかを判定することを提供する。

この例では、ステップ「塗料厚さを測定」において、１．５ｍｍの塗装厚さが測定された。３ｍｍ未満の塗装厚さは、本発明の文脈においてプロセス異常を表す。最小塗装厚さ３ｍｍの値は、この場合は固定して与えられている。ただし、その値はまた、例えば、注文顧客の要件から動的に指定してもよい。

センサが上記のプロセス異常を検出したため、本発明によれば、このプロセス異常を修復することが提供される。この目的のために、異常検出エンジンは、どのプロセスインスタンスにおいて、どの異常が発生したかを異常修正エンジンに通知する。図７による例では、異常検出エンジンは、プロセスプロトコルにおいて指定されたプロセスインスタンスが薄すぎる塗装厚さを測定したことを、異常修正エンジンに通知する。

この固有のプロセス異常に対して、異常修正エンジンは、このプロセス異常を修復できる一般的アクションの集合（図７には図示せず）から、それぞれの一般的アクションを選択する。本例では、これらのアクションは、一般的アクション「納期を延期」および「再塗装」である。したがってこの場合、一般的アクション「納期を延期」が必要となるのは、部品を再塗装することによって、運送業者に引き渡すための部品の提供が遅延するためである。

異常修正エンジンは、選択された一般的アクションからプロセス介入インスタンスを生成する。プロセス介入インスタンス「納期を延期」は、異常修正エンジンから、第１のサブプロセスインスタンスＰ１が実行されたＥＲＰシステムに転送される（ステップＳ３）。プロセス介入インスタンス「再塗装」は、異常修正エンジンから、第２のサブプロセスインスタンスＰ２が実行された生産システムのシステム（例えば、塗装ロボット）に転送される（ステップＳ４）。一般的アクションからプロセス介入インスタンスを生成する場合、プロセス介入インスタンスは、いくつかのパラメータを使用して適合され、パラメータの値は、確実に事前指定されていてもよいか、または、例えば、現在のプロセスインスタンスに応じて設定されてもよい。したがって、一般的アクション「納期を延期」は、納期を延期するために、異なるプロセスの異なるプロセスインスタンスに対して使用できる。本例では、異常修正エンジンは、部品の塗装および乾燥のための継続時間ならびに塗装ロボットの可用性から、部品の可用性の遅延を計算でき、この遅延（例えば、３６時間）は、プロセス介入インスタンス「納期を延期」のパラメータとして転送できる。

異常修正エンジンは、パラメータ化されたプロセス介入インスタンスをそれぞれのソースシステムに直接転送できる。次いで、ソースシステムは、それぞれのプロセス介入インスタンスを、それぞれのソースシステムで実行可能な命令に変換できる。

しかしながら、代替的かつ有利には、異常修正エンジンが、プロセス介入インスタンスからそれぞれのソースシステムによって実行可能な対応する命令を生成し、次いで、これらの命令をそれぞれのソースシステムに転送することが提供されている。これには、プロセス介入インスタンスから実行可能な命令を生成するために、ソースシステムを適合させる必要がないという利点がある。したがって、プロセス介入インスタンスからの命令の作成は、異常修正エンジンによって集中的に実行できる。異常修正エンジンは、命令が利用可能とされるべきそれぞれのソースシステムに応じて、対応する命令を生成する。

次いで、プロセス介入インスタンスまたは関連する命令は、それぞれのソースシステムによって実行される。次いで、（実行された命令に従って）対応するステップについて、エントリを同様にしてプロセスプロトコル（図７に図示せず）において生成でき、このエントリを同様にして異常検出エンジンのセンサによって監視できる。したがって、再塗装に対して、エントリ「２０１８年４月１９日１２時００分 部品を再塗装」、「２０１８年４月１９日１２時３０分 乾燥プロセス開始」、「２０１８年４月１９日１２時４３分 乾燥プロセス終了」、「２０１８年４月１９日１２時３２分 塗装厚さを測定 塗装厚さ３．０５ｍｍ」をプロセスプロトコルにおいて生成してもよい。塗装厚さが３ｍｍを超えているため、プロセスプロトコルを監視するセンサのセンサ定義に従って異常が修復されたと見なされる。

最後に、図８を参照すると、本発明による方法の基本的なステップが要約されている。

機械は、例えば、生産プロセスの複数のステップを実行する。機械はまた、コンピュータシステムであってもよく、コンピュータシステムにおいて、またはコンピュータシステムを用いて、プロセス（例えば、ＥＲＰシステムにおける注文プロセス）が実行される。機械によって実行されるプロセス（＝プロセスインスタンス）は、複数のプロセスステップを含むことができる。それぞれのプロセスステップは、プロセスプロトコルにプロセスデータＰＤとして記憶されるデータを生成する。機械の場合、このデータは、例えば、センサデータまたは操作パラメータを含むことができる。プロセスデータは、これらのデータに加えて、プロセスインスタンスの少なくとも１つの識別子およびプロセスステップの識別子、ならびにプロセスインスタンスのプロセスステップの順序を決定する情報（例えば、タイムスタンプ）を含む。それぞれのプロセスステップは、実行中または実行直後にプロセスデータを記憶する。

プロセスプロトコルは、通信ネットワークを介して機械に接続されているコンピュータシステムのデータベースに記憶できる。データベースがコンピュータシステムのメインメモリに記憶されている場合に有利である。

異常検出エンジンは、継続的に（または特定の時間間隔で）プロセスプロトコルを監視し、１つ以上のセンサ定義に基づいて、プロセスプロトコルにおいて不具合があるかまたは異常があるプロセスインスタンスＰＩを決定する、１つのセンサ（または複数のセンサ）を制御する。プロセスデータがそれぞれのプロセスステップの実行中または実行直後にプロセスプロトコルに記憶されることによって、不具合があるかまたは異常があるプロセスインスタンスは、それぞれのプロセスインスタンスの実行中にすでに、すなわち、それぞれのプロセスインスタンスの実行が完了する前に検出できる。さらに加えて、１つのセンサ（または複数のセンサ）がプロセスプロトコルを照会する時間間隔に応じて、不具合があるかまたは異常があるプロセスインスタンスの検出は、リアルタイムで可能であり、次いで、これは、それぞれのプロセスインスタンスにおける介入をリアルタイムで可能にし、不具合を修復するか、または異常を解消する。

異常検出エンジンは、検出されたプロセスインスタンスＰＩを異常修正エンジンに転送する。検出されたプロセスインスタンスＰＩのデータに加えて、異常検出エンジンは、それぞれのプロセスインスタンスをより詳細に説明するさらに別のデータ（補助データ）を異常修正エンジンに転送できる。例えば、このデータは、機械によって加工されたワークピースがどの顧客向けであるかに関する情報を含んでもよい。異常検出エンジンは、この補助データを他のデータベースから照会でき、異常修正エンジンで利用できるようにする。

本発明の代替実施形態では、これらの補助データはまた、異常修正エンジンによって、例えば、他のデータベースから照会することもできる。これは、特に、非常に大きなプロセスプロトコル（例えば、数億のプロセスステップ）を可能な限りリアルタイムで監視する必要がある場合に、異常検出エンジンの負荷を軽減するために有利である。

上述のように、異常修正エンジンは、異常検出エンジンによって転送されたプロセスインスタンスに対して、プロセス介入インスタンスを生成する。これらのプロセス介入インスタンスは、プロセス介入インスタンスを用いて、実行中のそれぞれのプロセスインスタンスを制御できるように形成されている。図８に示す例では、異常修正エンジンは、それぞれのプロセス介入インスタンスに対して１つの命令または複数の命令を生成し、それらの命令を実行のために、図８に示す例では機械であるそれぞれのソースシステム（＝プロセスインスタンスが実行される）に転送する。命令がそれぞれのソースシステムにおいて直接実行できるように、命令がそれぞれのソースシステムに適合している場合に有利である。図８に示す例では、機械に、例えば、検出された不具合を修復できる、または検出された異常を解消できる、特定の処理ステップを実行させることができる。

異常検出エンジンおよび異常修正エンジンは、同一のコンピュータシステム上で実行できる。あるいは、異常検出エンジンおよび異常修正エンジンは、通信ネットワークを介して接続された別個のコンピュータシステム上で実行されてもよい。

本発明の一実施形態では、様々なソースシステムのプロセスデータが記憶される複数のプロセスプロトコルが存在してもよい。さらに、（それぞれ複数のセンサを制御できる）複数の異常検出エンジンを提供して、異なるプロセスプロトコルを監視できるか、またはプロセスプロトコルを一緒に監視できる。さらに、それぞれ特定のプロセス異常の修復のために適合されている複数の異常修正エンジンを提供できる。検出されたプロセス異常に応じて、異常検出エンジンは、検出されたそれぞれのプロセスインスタンスを対応する異常修正エンジンに転送するように適合させることができる。したがって、プロセスプロトコル、異常検出エンジンおよび異常修正エンジンからなるネットワークを提供でき、図９に例として示すように、それぞれのノードは、固有のタスクを解決するように形成されている。

Claims (15)

1. 実行中のプロセスインスタンスを監視し、これらのプロセスインスタンスにおけるプロセス異常を修復するためのコンピュータ実装方法であって、それぞれのプロセスインスタンスが、いくつかのプロセスステップを含み、プロセスデータが、すでに実行された前記プロセスステップについて少なくとも１つのプロセスプロトコルに記憶され、前記プロセスデータが、それぞれのプロセスステップについて、少なくとも
   −前記プロセスステップの識別子と、
   −前記プロセスステップをプロセスインスタンスに一意的に割り当て可能な識別子と、
   −前記プロセスインスタンス内の前記プロセスステップの順序と、を含み、プロセス異常が、少なくとも１つのセンサ定義により記述され、前記プロセス異常には、前記プロセス異常を修復するための一般的アクションの集合が割り当てられており、
   （ａ）監視ステップにおいて、センサが、前記センサ定義を使用して、前記センサ定義に記述された前記プロセス異常に関して前記プロセスプロトコルを監視し、前記センサ定義に記述された前記プロセス異常を有する、１つのプロセスインスタンスまたは複数のプロセスインスタンスを含むプロセスを検出し、
   （ｂ）修正ステップにおいて、前記監視ステップにおいて検出されたプロセスインスタンスに対して、前記プロセス異常が、このプロセスインスタンスのランタイム中に修復され、
   −前記プロセス異常に割り当てられた前記一般的アクションの集合から少なくとも１つの一般的アクションが選択され、
   −前記選択された一般的アクションに基づいて、前記検出されたプロセスに固有のプロセス介入インスタンスが生成され、
   −前記プロセス介入インスタンスが、前記検出されたプロセスインスタンスの前記プロセス異常を修復するために実行される、コンピュータ実装方法。
2. 前記それぞれのプロセスステップについて、前記プロセスデータが、前記プロセスステップの実行中または前記プロセスステップの終了時に前記プロセスプロトコルに記憶される、請求項１に記載の方法。
3. 前記センサ定義が、データおよび／または指示を含み、前記データおよび／または前記指示を用いて前記監視ステップにおいて、所定の選択基準を満たすプロセスインスタンスおよび／またはプロセスが、前記プロセスプロトコルから選択される、請求項１に記載の方法。
4. 前記選択基準が、
   −少なくとも１つの静的パラメータもしくは動的パラメータ、
   −少なくとも１つの所定のパターン、および／または
   −パターン認識を使用して決定可能な少なくとも１つのパラメータ
   であり、前記選択基準からの逸脱または非逸脱の場合に前記選択基準が満たされており、前記選択基準からの逸脱または非逸脱が、プロセス異常を示唆する、請求項１〜３に記載の方法。
5. 前記プロセスインスタンスが、複数のサブプロセスインスタンスを有し、前記サブプロセスインスタンスの前記プロセスステップが、異なるソースシステムにおいて実行でき、前記サブプロセスインスタンスの前記すでに実行されたプロセスステップについて、前記プロセスデータが、前記少なくとも１つのプロセスプロトコルにマージされる、請求項１に記載の方法。
6. 前記センサ定義が、前記監視ステップがどの時点で実行されるかに関する情報を含む、請求項１に記載の方法。
7. 前記監視ステップの前に、前記プロセスプロトコルが、所定のフィルタ基準に従ってフィルタリングされ、前記フィルタリングされたプロセスプロトコルが、前記監視ステップの基礎である、請求項１に記載の方法。
8. 前記プロセスプロトコルに記憶された前記プロセスデータが、前記それぞれのプロセスインスタンスおよび／または前記それぞれのプロセスステップを記述するさらなる補助データとリンク可能であり、前記プロセス介入インスタンスが生成された場合、前記プロセスデータが、前記補助データと共にパラメータ化される、請求項１に記載の方法。
9. 前記プロセス介入インスタンスが、いくつかの非侵襲的アクションおよび／またはいくつかの侵襲的アクションを有し、
   −前記非侵襲的アクションが、前記それぞれのプロセスインスタンスが実行されるソースシステムの外部で実行され、
   −前記侵襲的アクションが、前記それぞれのプロセスインスタンスが実行されるソースシステムにおいて実行される、請求項１〜８に記載の方法。
10. 前記侵襲的アクションを用いて、前記それぞれのプロセスインスタンスのシーケンスが、前記ソースシステムにおいて変更および／または制御される、請求項１〜９に記載の方法。
11. 前記非侵襲的アクションおよび／または前記侵襲的アクションが、前記それぞれのソースシステムに対して実行可能な命令に変換される、請求項９に記載の方法。
12. 前記プロセス異常に割り当てられた前記一般的アクションの集合からの前記少なくとも１つの一般的アクションの前記選択は、前記一般的アクションの集合に含まれる前記いくつかのアクションまたはアクションの組み合わせに対してシミュレーションが実行され、前記シミュレーションにおいて、前記プロセスインスタンスに適用されたどのアクションまたはアクションの組み合わせが所定の結果を最も良好にもたらすのかを判定し、このアクションまたはアクションの組み合わせが選択されるように行われる、請求項１に記載の方法。
13. 前記フィルタ基準が、前記プロセスプロトコルの少なくとも１つの属性およびこの属性が想定できる特性によって形成され、前記特性が、ユーザに割り当てられており、前記属性の前記特性の前記ユーザへの前記割当を介して、前記フィルタリングされたプロセスプロトコルにおいて発生する前記プロセス異常も同様にこのユーザに割り当てられている、請求項７に記載の方法。
14. 前記プロセスプロトコルが、好ましくは、プロセスインスタンスの連続するプロセスステップが隣接するメモリセルに記憶されるように、コンピュータシステムのメインメモリに記憶される、請求項１に記載の方法。
15. 前記監視ステップが、異常検出エンジンによって実行され、前記修正ステップが、異常修正エンジンによって実行され、
    −異常検出エンジンが、センサの実行を制御し、センサの実行が、センサ定義において指定された時点に従ってトリガされ、
    −前記異常検出エンジンが、前記センサによって検出された前記プロセスインスタンスに関する情報を前記異常修正エンジンに転送する、請求項６に記載の方法。

Images