How each metric is calculated

The definition behind every number on every screen, and what each one leaves out.

Every metric comes from two streams: the running and stopped states a sensor reports, and the detection events that count parts. This page defines each number once, and every other page links here.

The number the interface labels OEE is availability, not OEE. IoTFlows is renaming that label to Uptime, and this page uses Uptime throughout.

Uptime

Uptime is availability: the share of the window a machine spent running.

uptime = running time ÷ (running time + stopped time)

The sensor decides running and stopped, the same state that colors the shift status bar. For example, a machine that ran 6 h 30 min of a 9 h shift and was stopped 2 h 30 min reads 72% uptime. Time the sensor did not report is left out of both terms, see Unknown time.

The same percentage carries two labels: Uptime on a machine card and machine page, Utilization on the Assets KPI row and the Advanced Report. The Uptime KPI tile on the Assets page is different: that one is total running hours, as 71:15h. See Read the fleet KPIs.

The two factors IoTFlows computes, uptime and the parts gauge, against the three of textbook OEE. Quality is not measured and nothing multiplies them together.A diagram in three columns under the heading Textbook OEE: Availability times Performance times Quality. Under Availability, a box reads Uptime, running divided by running plus stopped, with the input labeled: running and stopped states from the sensor. Under Performance, a box reads Parts gauge, parts made divided by parts possible at the ideal cycle time, with the input labeled: detection events, and the ideal cycle time in the Parts List. Under Quality, a dashed box reads Not measured, no good-versus-scrap factor. A note across the bottom reads: nothing multiplies these together. There is no combined OEE figure; read each number on its own.

There is no combined OEE figure and no quality factor in the product. IoTFlows shows availability as uptime and performance as the parts gauge, separately, and has no good-versus-scrap term. Comparing an IoTFlows uptime of 85% to an OEE of 60% from another system is comparing one factor to a product of three.

Downtime

Downtime is the time the sensor reported the machine stopped. Every minute is running or stopped unless the sensor was silent.

Downtime is the same total with or without a reason on it. A classified stop carries a downtime category, an unclassified stop does not, and both count in full. Classification changes what the Downtimes report can say about the time, not how much there is, see Classify a downtime event.

A stop's red or orange on the status bar is a duration threshold and has no effect on the number, see Set status colors and downtime thresholds.

Unknown time

Unknown time is any interval where the sensor was powered off or had lost its connection. It is absence of data, not a machine state, and it counts toward neither uptime nor downtime.

For example, a SenseAi unplugged over a weekend produces 48 unknown hours, not 48 hours of downtime. On the shift status bar the stretch is gray, and the card keeps the last state the cloud recorded, so an offline machine can still read stopped. Gray on the bar is what separates a dead link from a stopped machine, see Troubleshoot a device that is offline.

On the Advanced Report, turn on Exclude Unknown when you want to be certain the report's Total Utilization follows this definition, see Choose what the number includes.

The None severity

None is a downtime severity for categories whose stops are nobody's loss. Its purpose is legally required breaks: a mandated one-hour lunch is a stop on the sensor, but it should not count against the plant.

A None-severity stop is downtime by default. With Exclude None on, it leaves both uptime and downtime, the same way unknown time does. For example, a department that takes the mandated hour reads 82% uptime with the switch off and 93% with it on, because the hour leaves the denominator too. Which categories carry None is set in Set severity.

How a shift's clock divides: uptime, classified downtime, unclassified downtime, a None break and unknown time. This is the figure behind most questions of the form why does this not add up.A horizontal bar representing one shift from 8am to 5pm, divided into segments. Most of the bar is running. A short classified stop labeled Tool change sits around 9:30, a short unclassified stop around 10:30, a one-hour break labeled Lunch, severity None, from 12 to 1, and a stretch labeled Sensor offline, Unknown, from about 2:20 to 3. A key beneath assigns each kind of segment to a bucket: running counts as uptime; a classified stop and an unclassified stop both count as downtime; the None break counts as downtime, or as neither with Exclude None on; sensor offline counts as neither. A note reads: uptime percentage is running divided by running plus stopped. Minutes in neither bucket are why the percentages do not add up to the length of the shift.

What is excluded from uptime and downtime

Leave Unknown and None in when you are asking where the shift went, because a number without them no longer adds up to the shift. Exclude them when you are comparing machines or holding someone to a number.

Performance

Performance is the parts gauge: actual output against what the machine could have produced at its ideal cycle time in the same running time.

performance = parts made ÷ (running time ÷ ideal cycle time)

The ideal cycle time is entered per operation in the Parts List, see Set cycle times and filters. The gauge is green when the percentage meets the machine's goal and red when it does not, see Set uptime goals.

Watch uptime to find machines that are stopped, and the parts gauge to find machines that are running slowly. A machine can sit at 95% uptime and still miss its goal, because uptime does not know how fast the machine was going. For example, a press running all shift at 40 strokes a minute against an ideal of 60 shows a green uptime ring and a red parts gauge.

You do not need the parts gauge to tell whether a machine is stopped. It earns its place once an operation with an ideal cycle time is assigned to the machine.

FPY

FPY, first pass yield, compares a step's good count with the count of the step before it in a cascading group.

fpy = this step's good count ÷ previous step's good count, capped at 100%

Where a step produced less than the step before it, the difference is the loss from the first step through to this one. For example, if OP10 made 1,200 parts and OP20 made 1,080, OP20 reads 90% FPY and a loss of 120. It is a multi-operation measure, which is why it appears only on cascading group cards, see Group machines into cascades. It reads green from 95% and amber from 80%.

A group can instead measure each step against its own cycle-time baseline, with no reference step. The group page says when to use which.

Cycle time

Three cycle-time figures appear in the product, from three places.

A red cycle time means the machine is producing more slowly than its goal allows, not that it is stopped. For example, a machining center with a 90 s ideal cycle that is turning parts every 2 min reads a red Cycle time and a green Uptime, and both are correct.

Production metrics

Hourly production is parts counted per clock hour, drawn as bars on the machine card against a per-hour goal derived from the ideal cycle time and the machine's goal, see Set cycle times and filters.

Machines producing on the Assets page KPI row counts machines whose sensor reports running at this moment, out of the filtered fleet. It is the one KPI on the row with no window.

Any selected window, including one spanning several shifts, is calculated across the whole window, not as an average of per-shift figures. For example, a machine at 90% on a long day shift and 50% on a short night shift reads 80% for the two together, because the day shift contributed more minutes.

Which minutes fall in the window is itself a question for a shift that crosses midnight. On a report, such a shift is divided at midnight and its later hours are counted on the next day, unless Shift islands is on. The live views never divide it. So the same night shift has two defensible denominators, see Where the overnight hours land.

Where each metric appears

See also

• Troubleshoot wrong utilization or OEE
• Build a utilization report
• Set cycle times and filters
• Group machines into cascades
• Set uptime goals