Failures
The count of units that didn't meet quality standards.
There are many P-KPIs that the platform could report to the dashboard for a given station. Depending on the type of station, a specific subset of P-KPIs might be more appropriate. If your station is reporting test data by using SDK functions that track the unit in and out of the station with a corresponding result, you might want to review the nuances how failures are counted.
Failure Counts
Failures represent the count of units that did not meet the specific test criteria at the station.
Failure calculations are based on the result parameter sent when a unit is tracked out of the station. Refer to the result parameter for the
track_unit_out() method in the SDK for more details.
This means that if a unit was re-processed at the station, duplicate (retry) runs can influence the count for the type of failure you are viewing: Final Failure Count or Total Failure Count. Please see below for more details.
Total Failures
The Total Failure count represents the number of unique units that have failed at least once within a given station, station group, or line.
This measure captures all instances where a unit resulted is a fail, regardless of whether it later passed.
- Identify all occurrences of the unit at the specific station or station group.
- Count the unit if any occurrence reports a
failorfailedresult. - Duplicates are ignored in counting — each unique unit is counted once even if it failed multiple times.
This is useful for understanding how many distinct units experience quality issues during the process
Final Failures
The Final Failure Count represents the number of unique units had a failure as its last known occurrence at a given station, station group, or line. In other words, these are the units that have not yet successfully passed through that point in the process.
- Identify the last occurrence of the unit at the specific station or station group.
- Evaluate the associated reported result:
- A
failorfailedresult means the unit currently remains in a failed state. - If a previously failing unit has a final
passorpassedresult, it means that the unit was re-processed and fixed and will not be included in this count.
- A
This is particularly valuable for identifying current bottlenecks or active quality issues that still need attention.
Examples
Example 1: Simple
In this example, we'll compute failures for one station with a simple product flow. We'll explore how flows with different retry policies will affect the numbers.
Unit Flow:
| Time | Unit ID | Result | Station occurrence |
|---|---|---|---|
| 01:23:00 | Unit 1 | Pass | 1st |
| 01:24:00 | Unit 2 | Fail | 1st |
| 01:25:00 | Unit 2 | Pass | 2nd |
| 01:26:00 | Unit 3 | Fail | 1st |
| 01:27:00 | Unit 3 | Fail | 2nd |
| 01:28:00 | Unit 4 | Pass | 1st |
- Total Failures: Units 2 and 3 both failed at least once, even though Unit 2 eventually passed.
- Final Failures: Only Unit 3’s last result was a failure.
Example 2: Complex
In this example, we’ll compute failure counts at both the station and group level. Stations A and B are duplicate stations in the same station group, meaning they process units in parallel.
Station Group 1:
- Station A:
| Time | Unit ID | Result | Station occurrence | Group occurrence |
|---|---|---|---|---|
| 01:23:00 | Unit 1 | Pass | 1st | 1st |
| 01:24:00 | Unit 2 | Fail | 1st | 1st |
| 01:25:00 | Unit 2 | Pass | 2nd | 2nd |
| 01:26:00 | Unit 3 | Fail | 1st | 1st |
| 01:27:00 | Unit 4 | Fail | 1st | 1st |
| 01:28:00 | Unit 4 | Fail | 2nd | 2nd |
| 01:29:00 | Unit 5 | Fail | 1st | 1st |
| 01:30:00 | Unit 5 | Fail | 2nd | 2nd |
| 01:31:00 | Unit 6 | Fail | 1st | 1st |
| 01:32:00 | Unit 6 | Pass | 2nd | 3rd |
| 01:33:00 | Unit 7 | Fail | 1st | 1st |
| 01:34:00 | Unit 7 | Fail | 2nd | 3rd |
- Station B:
| Time | Unit ID | Result | Station occurrence | Group occurrence |
|---|---|---|---|---|
| 01:26:30 | Unit 3 | Pass | 1st | 2nd |
| 01:28:30 | Unit 4 | Fail | 1st | 3rd |
| 01:30:30 | Unit 5 | Pass | 1st | 3rd |
| 01:31:30 | Unit 6 | Fail | 1st | 2nd |
| 01:33:30 | Unit 7 | Pass | 1st | 2nd |
| 01:36:00 | Unit 8 | Pass | 1st | 1st |
| 01:37:00 | Unit 9 | Pass | 1st | 1st |
| 01:38:00 | Unit 10 | Pass | 1st | 1st |
Outcome
Group 1 consists of Station A and Station B.
Total Failures: Out of 10 units, 6 units failed at least once.
Final Failures: Out of 10 units, 2 units failed on their last occurrence.
- Unit 4 flowed: Station A [Fail] -> Station A [Fail] -> Station B [Fail].
- Unit 7 flowed: Station A [Fail] -> Station B [Pass] -> Station A [Fail].
Note: Unit 6 is not included in the final failure count because it passed in its last occurrence at Station A.
- Unit 6 flowed: Station A [Fail] -> Station B [Fail] -> Station A [Pass].
Let's look at the failure counts at the individual station level:
- Station A:
- Total Failures: Out of 7 units, 6 failed at least once at this station.
- Final Failures: Out of 7 units, 4 units failed on their last occurrence at this station.
- Station B:
- Total Failures: Out of 8 units, 2 failed at least once at this station.
- Final Failures: Out of 8 units, 2 units failed on their last occurrence at this station.
By tracking the results of each unit’s pass and fail events at each station, you can monitor Total Failure Count and Last Failure Count to identify where failures occur most frequently and which units remain unresolved. This enables data-driven quality improvement at every level of your production process.