「セント・アイヴスへ向かう途中、七人の妻を持つ男に出会った」という謎かけをご存知かもしれません。詩が続くにつれ、各妻が七つの袋を持ち、各袋に七匹の猫が入っているなど、次第に「セント・アイヴスへ向かったのは何人か？」という問いが提示されます。この謎かけのよくある誤解は、答えを出すために全ての要素を掛け合わせると、途方もない数字になるというものです。
Cimetrixは、アプリケーション開発者が機器制御アプリケーションに機器データ収集（EDA）/インターフェースA規格を統合する支援において豊富な経験を有しています。時折、非常に多くのプロセスモジュールを有する機器タイプに遭遇し、各プロセスモジュールには非常に多くの例外が存在します。EDA Freeze IIにおける例外は、例外定義と例外インスタンスの両方で表現されます。多数の例外を含むモデルを作成する選択肢にはどのようなものがあるでしょうか？
良い
最も直接的なアプローチは、以下のEDA機器モデルに示すように、例外インスタンスごとに1つの例外定義を用意することです：
ただし、このアプローチでは、各モジュールに5000件の例外が発生する場合、200モジュールでは100万件の例外インスタンスと、それに対応する100万件の例外定義が生成される。このモデルを展開・維持するために必要なシステムリソースは非常に膨大である。
より良い
EDAでは、複数の例外インスタンスが単一の例外定義を参照できます。以下のモデルはこのアプローチを示しています：
この例では、プロセスモジュールに10個の例外インスタンスがあるのに対し、例外定義は1セットしか設定されていないことがわかります。この手法を用いると、各モジュールに5000個の例外インスタンスが存在する場合、200個のモジュールでは依然として100万個の例外インスタンスが生成されますが、例外定義は200個（モジュールごとに1つ）のみとなります。これは大幅な削減ではありますが、依然として非常に大きな数です。
最高
多くのプロセスモジュールを持ち、各モジュールに多数の例外が存在する装置に対する最善のアプローチは、モジュールごとに少数の明確な例外のみを定義し、実際の問題原因を示すために一時パラメータ（またはデータ変数）を使用することである。以下のモデルはその具体例を示す：
上記のモデルにおけるプロセスモジュールには例外が1つだけ存在します。一時的なパラメータであるAlarmCodeには、例外が発生した原因に関する情報が含まれます。追加情報（サブエラーコード、説明など）が必要な場合は、複数の例外パラメータを設定することが可能です。
EDA標準は4つの例外重大度レベル（情報、警告、エラー、致命的）を参照している。各重大度レベルごとに1つの例外定義を作成し、モジュールあたり最大4つの例外インスタンスを想定すると、200モジュールからなるモデルでは4つの例外定義と最大800の例外インスタンスが生成される。
この例外統合のアプローチは、モデルの複雑さとサイズを削減することで、機器メーカーと工場の双方に利益をもたらす。
上記の頭の体操の答えは、セント・アイヴスへ向かっていたのはたった一人――私だけだったということです。もう一方のグループに何人の人間や猫などがいたかを考えるのに、多くの時間や労力を費やす必要はありません。なぜなら彼らは反対方向へ向かっていたからです！同様に、EDAで例外処理を統合すれば、あまりにも多くの例外を処理しようと、多くの時間やシステムリソースを費やす必要がなくなります。