You may be familiar with the brain teaser that starts, “As I was going to St. Ives, I met a man with seven wives.” As the poem continues, each wife has seven sacks, each sack has seven cats, etc. Eventually the question comes out, “How many were going to St. Ives?” The common misconception of this brain teaser is that to answer the question you must multiply all of the items together, resulting in a huge number.

Cimetrix has extensive experience in helping application developers integrate the Equipment Data Acquisition (EDA) / Interface A standards into their equipment control applications. Occasionally we encounter an equipment type that has a very large number of process modules and each process module has a very large number of exceptions. An exception in EDA Freeze II is represented by both an exception definition and an exception instance. What are the options for creating a model with a large number of exceptions?

Good

The most direct approach is to have one exception definition per exception instance as shown in the following EDA equipment model:However, with this approach, if each module has 5000 exceptions, 200 modules would result in 1 million exception instances with a corresponding 1 million exception definitions. The system resources required to deploy and maintain this model are very large.

Better

EDA allows multiple exception instances to refer to a single exception definition. The following model shows this approach:In this example, we can see that the process module has ten exception instances, but now there is only one set exception definition. Using this approach, if each module has 5000 exception instances, 200 modules would still result in 1 million exception instances, but we would now only have 200 exception definitions (one for each module). This is a significant reduction, but still quite large.

Best

The best approach for equipment with many process modules each with a large number of exceptions is to define only a few distinct exceptions per module, and then use a transient parameter (or data variable) to indicate the actual cause of the problem. The following model shows how this might look:The process module in the model above only has one exception. The transient parameter AlarmCode would contain the information about what caused the exception to be triggered. It is possible to have multiple exception parameters if additional information is necessary (sub error code, description, etc.)

The EDA standards reference four exception severity levels – Information, Warning, Error, and Fatal. If we create one exception definition for each of these severities and no more than four exception instances per module, we see that a model with 200 modules would have four exception definitions and an upper limit of 800 exception instances.

This approach to exception consolidation benefits equipment makers and factories alike by reducing model complexity and model size.

The answer to the brain teaser above is that only one person was going to St. Ives – me. You don’t have to spend a lot of time and effort trying to figure out how many people, cats, etc. were in the other party, because they were travelling in the opposite direction! Similarly, if you consolidate your exception handling in EDA, you don’t have to spend a lot of time and system resources trying to handle too many exceptions.