Monitoring and reports¶
Digital Twin → Parameters → Health has three views of the same information.
| Tab | Answers |
|---|---|
| Overview | How is every monitored parameter behaving? |
| Excursions | What exactly went wrong, when, and why? |
| Capability | Is this parameter statistically capable of holding its specification? |
On the parameter's own page¶
Every monitored parameter also shows its own recent health directly on its Parameter health tab — Digital Twin → Parameters → (the parameter) → Parameter health — above the setup form. A segmented bar covers the last 7 days, coloured by state, with the same time-in-range, excursions, and not-reporting figures as the fleet table below, scoped to just this one parameter.
Use this as the quick "is this one specifically OK" check while you're already looking at the parameter. Use the Overview tab below when you need to compare across every monitored parameter at once.
Not configured yet?
If health hasn't been set up for the parameter, this area shows a prompt instead — the setup form is right below it. See Setting up Parameter Health.
Overview¶
Every health-monitored parameter, worst first.
The ordering is deliberate: parameters needing acknowledgement come first, then by criticality, then by current state, then by how little time they spent in range. A Critical Control Point that is merely unhealthy ranks above a Minor parameter that is critical — because the point of criticality is to say which parameters matter more.
The summary cards¶
| Card | Meaning |
|---|---|
| Monitored | How many parameters have health configured |
| Deviating now | Currently unhealthy or critical |
| CCPs deviating | Of those, how many are critical control points |
| Needs acknowledgement | Open issues nobody has taken responsibility for |
| Average time in range | Mean compliance across all monitored parameters |
The table¶
| Column | Meaning |
|---|---|
| Time in range | Percentage of measured time the parameter was healthy |
| Excursions | How many times it left its healthy range |
| Not reporting | How long its edge device was unreachable |
| Open issues | Currently open, with a warning marker if any are unacknowledged |
Click any row to open that parameter's own page.
Time in range excludes time when nothing was measured
If a parameter was offline for a day, that day is left out of the percentage rather than counted as a failure — a network outage isn't a quality problem. Always read "Time in range" alongside "Not reporting." A parameter showing 100% with four hours of missing data is a connectivity problem, not a clean parameter.
A dash is not zero
— means nothing was measured at all in the window. 0% would mean it was in range none of the time. They're very different, so Enture never shows one when it means the other. Rows with very little data behind them are marked little data.
Filtering¶
Search by parameter or machine name, filter by state, and change the window between 7, 30 and 90 days.
Excursions¶
Every deviation on record — the view a quality investigation or an audit actually opens.
Filters¶
| Filter | Use |
|---|---|
| Criticality | Narrow to critical control points |
| Reason | Show only excursions of a particular cause — for example only Genuine Deviation, hiding planned maintenance and cleaning |
| Acknowledgement | Work through what still needs a reason recorded |
| From / To | Restrict to a date range |
The Reason filter is the one that makes this an audit tool rather than a log. Because every acknowledgement records a cause, "show me only the genuine deviations last quarter" is a filter rather than an afternoon of reading notes.
Excursions by cause¶
Above the table, a breakdown of how many excursions fall into each cause and how long they lasted on average. It always reflects the same filters as the table below it.
The table¶
Each row is one excursion: the parameter, the state it reached, when it opened, how long it lasted, the reading that caused it, the batch in production at the time, and the reason recorded when it was acknowledged.
Excursions still in progress are marked ongoing — their duration is still counting up. Where a reading went further out of range after the excursion opened, the worst value is shown as peak.
Unacknowledged rows have an Acknowledge button. See Acknowledging issues.
Export¶
Export CSV downloads the filtered register as a spreadsheet, with dates in YYYY-MM-DD HH:MM:SS format and one row per excursion including the reason and remarks. This is the file to attach to an audit response.
Capability¶
Choose a parameter from the dropdown. What you see depends on how it's configured.
For a numeric range — Cp and Cpk¶
One row per day.
| Column | Meaning |
|---|---|
| Cp | How much of the specification width the parameter's spread actually uses. Ignores centring |
| Cpk | The same, but accounting for how far off-centre it is |
| Mean / Std dev | The day's average and spread |
| Time in range | That day's compliance |
| Samples | How much data is behind the figures |
Cpk is the one most quality standards ask for. As a rule of thumb, 1.33 or above is generally considered capable, 1.0 to 1.33 is marginal, and below 1.0 means the process cannot reliably hold its own specification. Enture colours the column accordingly.
A high Cp with a low Cpk is a specific and useful signal: the parameter is tight but drifting — it has plenty of margin and is simply not centred.
Cp is blank for a one-sided specification
Cp describes spread against the full specification width, so it needs both limits. Cpk still works with one.
Check the Samples column
A capability figure from a handful of samples isn't meaningful. Rows with little data behind them are marked, and a parameter that has barely reported will show low sample counts — treat those figures as indicative only.
Capability appears the day after monitoring starts
These figures are calculated overnight, so a parameter configured today will show its first capability row tomorrow.
For value rules — where the time went¶
Capability indices don't apply to a parameter that reports states rather than measurements — there's no average of RUNNING and FAULT. Instead you get a breakdown of how long the parameter spent in each state, and how many times it entered it.
This is usually the more actionable view: "the filler was in JAM for 47 minutes across 12 separate entries yesterday" is something you can act on.
Unmatched time means your rules are incomplete
If some of the time is shown against values no rule covers, Enture flags it with a percentage. That's a configuration gap, not a plant problem — go back to the parameter's Health tab and use the discovered values list to add the missing rules.