Designing an Event Scheme

Scope it to one kind of thing#

The first decision is what the scheme is, and the failure mode is making it too broad.

One scheme per kind of event, per piece of equipment that needs its own:

Line 1
+-- Production Run      runs, with product and operator
+-- Stoppage            downtime, with reason and category
+-- Changeover          transitions, with from-product and to-product

The tempting alternative is one Line 1 Events scheme with a Type attribute distinguishing runs from stoppages from changeovers. Resist it. Separate schemes give you:

• Triggers that describe one thing and can be reasoned about
• Attribute sets that are all relevant, rather than mostly blank
• Event-aggregated measures that mean something without filtering
• Analysis that does not begin by separating out what you merged

Put each scheme in the folder for the equipment it describes, so the events and the measures they contextualise are found together.

The scheme settings#

Backfill#

Backfill sets the date from which Infohub builds events. Left unset, events begin from when the scheme starts running.

Set it when the source data already contains history you want as events — a historian holding two years of machine states, or an MES table of past production orders. Infohub will work through the history and create the events.

Refresh Offset#

Refresh Offset controls how far back the scheme re-examines source data on each pass.

It exists because plant data arrives late. A historian may log a state change a little after it happened; an MES record may be completed retrospectively; a manually confirmed production order may be entered the next morning. A scheme that only ever looks at the newest data will miss all of it.

The trade-off is direct: a larger offset catches more late data and costs more work per pass.

Practical guidance:

• Start at something comfortably larger than the worst lateness you actually observe.
• For manually confirmed events, that may be a day or more.
• For pure tag-driven events on a healthy historian, minutes to an hour is usually enough.
• If events appear and then need correcting, the offset is too small.

Indexing#

The Index settings give events automatic sequential numbers — batch numbers, run numbers, order numbers — and control when the numbering restarts.

So an index interval of Yearly with an initial of 1 numbers events 1, 2, 3… through the year and restarts at 1 in January. A Daily interval numbers within each day.

This is genuinely useful for batch and run identification, and it is worth deciding before the scheme runs. Changing the numbering scheme after events exist does not renumber history, so you end up with two conventions in one series.

Archive Age and Purge Age#

Events accumulate. Archive Age moves older events out of the active working set; Purge Age removes them.

Decide these against your actual reporting horizon:

• If people compare against last year, purge age must exceed a year comfortably.
• If quality traceability requires seven years, that is the constraint, and it may be a regulatory one.
• If a scheme is genuinely operational — machine states for a live utilisation dashboard — a shorter retention is reasonable and keeps the model fast.

Design sequence#

A workable order, and the reason for it.

1. Decide what one event is. Write the sentence: "a Stoppage starts when the line stops running and ends when it runs again". If you cannot write that sentence unambiguously, the scheme is not yet defined.

2. Find the trigger source. What in the data marks the start and the end? A state tag, a query against an MES table, a calendar. If nothing in the data marks it, the event will have to be manually entered — which is legitimate but changes the design.

3. Decide the attributes. What do you need to know about each event, and where does each value come from — the source, a calculation, or a person? See Event Attributes and Enumerations.

4. Decide the enumerations. Anything categorical needs a defined list, or analysis will drown in spelling variants.

5. Set the scheme settings above.

6. Run it forward first. Let it create events from now, with no backfill, and look at them. Are the boundaries where you expect? Are attributes populated? Are there duplicates or events that never close?

7. Then backfill, in a bounded range, and check again.

8. Then build the event-aggregated measures and charts.

Steps 6 and 7 in that order matter. Building the analysis before confirming the events are right means debugging two things at once.

Verifying a scheme#

Before relying on it, check against reality:

• Count. Does the number of events per day match what the plant says happened?
• Boundaries. Pick three events and compare their start and end times against the source data or an operator's account.
• Open events. Are there events with no end that should have closed? That is a trigger problem.
• Duplicates. Two events for one real occurrence is also a trigger problem.
• Attribute completeness. What proportion of events have their attributes populated? A reason attribute filled in 40% of the time produces a Pareto chart dominated by "unspecified".
• Total duration. For state-based schemes, do the durations across a day add up to roughly the day? If they add to much more, events are overlapping; much less, and gaps are being missed.

Common design mistakes#

See also#

• Event Triggers
• Refresh Triggers
• Event Lifecycle Operations
• Time Slices and Event-Sliced Measures