Turn on availability tracking

Availability (MA · OA · OSF) is computed from what the shifts record in the diary: from when to when the plant ran in which operating mode. Three things must be in place at the same time — if any one is missing, the metric does not appear, or only the breakdown by operating mode shows. This article walks through all three and explains what to watch so the number can be trusted.

Before you start

• Permission: turning on the diary element needs layout:manage (the Diary elements tab); applying the recipe needs analytics:manage — analytics:view is not enough, because the recipe sets what the metrics mean.
• The Analytics module must be on for your organisation. Your organisation does not switch it on itself: it is enabled on the provider (OPEREX) side — ask there if it is off.

The operating-mode timeline is off by default

The built-in “Operating-mode timeline” diary element starts switched off on every plant. That is deliberate: start recording only where you want to measure availability. It is switched on per plant.

Steps

1. Switch on the “Operating-mode timeline” diary element on the Diary elements tab, for every plant you want to measure: one click moves it from the list on the right (switched off) to the active ones. From then on the diary shows the “Operating-mode timeline” section.
2. Apply the “Availability” recipe under Analytics “Settings ▾” → “Recipes”. The recipe card’s “What it needs” list shows whether the operating-mode timeline is there (“Available” / “Missing”). Before you press “Apply”, the preview shows row by row how the recipe pairs its categories with your operating modes — whatever it made no suggestion for stays unclassified. The confirmation reads: “Recipe applied; the retroactive computation has started.”
3. Record the operating modes in the diary. A shift adds a period with “Record operating mode” (“Operating mode”, “From”, “To”). “To” may stay empty: “Leave empty to keep it open — the next shift closes it.” The next shift sees it in its diary as “Open period from an earlier shift” and carries it on with “Close” or “Close and continue with a new mode”.
4. Classify what the recipe could not. An operating mode without a category shows up under the metric as unclassified downtime — how to classify it is in Classify operating modes.

The recipe is only a starting point

The recipe creates the classification categories for the whole organisation — which metric an operating mode reduces can be rewritten to match your own rules. A row you edited is not overwritten by a recipe update (“Left untouched (you edited it)”).

If it worked

The Overview availability tile (“On-stream factor (OSF)”) shows a number, with “Mechanical availability (MA)”, “Operational availability (OA)” and “Runtime (theoretical maximum)” below it. The line under the number also says how much data it came from: “on data covering {pct}% of the period”. If there is unclassified time, the metric shows as a band: “{best} – {worst} (depending on unclassified time)”.

Common problems

What you see	Why	What to do
“No classification yet — apply the „Availability” recipe and the metrics appear retroactively.”	The recipe is not applied — only the “Breakdown by operating mode” shows, no MA/OA/OSF.	Apply the recipe (step 2).
On the recipe card the operating-mode timeline shows “Missing” (for an applied recipe: “Pending — the source diary element is missing”).	The “Operating-mode timeline” diary element is not switched on on any plant.	Switch it on on the Diary elements tab (step 1).
“No operating period was recorded for this scope in this period.”	The element is on, but nobody recorded an operating mode for this period / plant.	Record them in the diary (step 3).
“{dur} of unclassified downtime ({modes}) — the metric may drop by this much.”	An operating mode has no category.	Classify it in the classification queue (step 4).
“Contains an open period — the number is a lower bound.”	A period has no end yet (the next shift closes it).	Not an error; the number becomes final once it is closed.
“Data-quality signal: two operating modes are recorded at the same time for {dur}…”	Two periods overlap on the timeline.	Correct the time of one of them in the diary.

Worth knowing

• Unrecorded time does NOT count as downtime. The denominator of OSF (and of MA, OA) is the full length of the period, and only recorded time classified as downtime reduces it. A hole in the timeline therefore skews the metric upwards. Example: a 30-day month is 720 hours. If you recorded 600 hours, 40 of which were unplanned downtime, OSF = (720 − 40) / 720 = 94.4%, with 83% data coverage. Had the plant actually stood still during the missing 120 hours, the real value would be (720 − 160) / 720 = 77.8%. That is why the complete timeline matters.
• Data coverage shows exactly this. The “Data coverage” tile and the line under the number state what share of the period the recorded timeline covers: “The missing part is not zero downtime — it is missing data.” In the Timeline view the hole is marked “Missing data”.
• Unclassified time has a lower bound; unrecorded time does not. The “{best} – {worst}” band only accounts for recorded but unclassified time; the system knows nothing about unrecorded time — only data coverage shows it.
• Today only Analytics flags the hole; the shift leader gets no warning about it in the diary — so check data coverage regularly (for example in the morning meeting).

Related

Classify operating modesWhat the recipe could not classify: the daily routine.

Operations analytics overviewWhat the module is for, and how the diary becomes a metric.

Edit diary elementsSwitch elements on and off per plant.