Event Attributes and Enumerations

Attribute value types#

Each attribute holds one of two kinds of thing:

Choosing correctly between them decides whether your analysis works. More on that below.

Where values come from#

An attribute's retrieval type determines how it gets populated:

Retrieved from Segments#

The source is read across the event's own span rather than over a calendar interval. That is the useful part: the attribute describes this event, whatever length it happened to be.

So a production run's average line speed is the average over that run — not over the hour it started in, not over the shift. A batch's peak temperature is the peak during that batch.

This is the closest thing Infohub has to a signature capability for event analysis, and it is why "average rate per production run" is straightforward here and awkward in interval-based tools.

Calculated#

An expression evaluated for the event. Two forms are particularly useful.

Deriving from the event's own duration. The period in scope is the event, so its duration is available:

Period.Duration.TotalMinutes
Period.Duration.TotalHours

A changeover duration in minutes, a run length in hours, a downtime in minutes — all one expression, with no source needed.

Deriving from another attribute. Attributes can reference each other, so a computed attribute can build on a retrieved one — a yield from a good count and a total count, a rate from a quantity and the duration.

Keep these expressions numeric and unformatted. Formatting belongs to display, not to the value.

Manually entered#

A person supplies the value through a form. This is how downtime reasons, deviation explanations, and quality sign-offs get captured.

It is also the attribute type most likely to be left blank, which is the single biggest determinant of whether the resulting analysis is worth anything.

Enumerations#

An enumeration is a defined set of named options, held in the Toolbox and reusable across schemes. Options can carry colours, which then flow through to charts and timelines automatically.

Use one for anything categorical. This is not a stylistic preference.

Free text produces this, from four different people describing one thing:

Blockage
blockage
Blocked
blokage
Label blockage

Five categories, one cause, and a Pareto chart that ranks none of them meaningfully. No amount of downstream cleverness fixes it, because the information about which of them are the same thing was never captured.

An enumeration makes it one option, selected from a list, spelled once, in a known colour.

Designing an enumeration#

Keep the list short enough to choose from. Eight to fifteen options is workable. Forty means operators pick whichever appears first, and the data becomes noise.

Make the options mutually exclusive. If two options could both describe one event, different people will pick differently.

Include a genuine catch-all, named honestly — Other. Then watch it: if Other becomes the biggest category, the list is missing something real and needs revising.

Assign colours deliberately. Red for unplanned failures, amber for planned interventions, grey for idle. The colours reach timelines and charts, so a well-chosen palette makes a dashboard readable at a glance.

Version it thoughtfully. Adding an option is safe. Renaming one changes how history reads. Removing one orphans the events that used it. Decide the list properly rather than iterating on it against live data.

Enumeration groups#

Related enumerations can be combined into a group, which constrains valid combinations across several attributes.

The classic use is a two- or three-level reason hierarchy: a category, and within it a specific reason. A group ensures that selecting the Mechanical category offers only mechanical reasons, rather than allowing Mechanical with Operator break.

This is what makes a hierarchical Pareto possible — roll up to category for management, drill down to reason for the maintenance team — without relying on people to enter consistent combinations.

Set groups up when the reason list starts to exceed what a flat enumeration handles well. Ten reasons is fine flat; sixty needs a hierarchy.

Deciding an attribute set#

For each event scheme, ask what you would need to know to answer the questions people will ask.

A production run typically needs:

A stoppage typically needs:

Keep the set to what will actually be used. Every attribute is either a source to configure or a field a person must fill, and unused attributes make forms longer and completion rates worse.

Attributes on the interval grid#

Attribute values reach ordinary measures through the Event Value (Start) and Event Value (End) anchors on an event-aggregated measure, which pull a numeric attribute onto the interval grid so it can be charted, limited, and published like anything else.

Attributes also filter and group event-based charts and tables directly — the Pareto by reason, the timeline coloured by category, the table of runs by product. See Analysing Data by Event.

Diagnosing#

See also#

• Designing an Event Scheme
• Event Triggers
• Batch and Sequence Tracking
• Analysing Data by Event