KaizenFlow AI Certified Engineer

Module 01 · 26 min · 2 fig.

Connecting the plant

Every number KaizenFlow produces traces back to a raw tag on a machine. This module covers how to stream that data over OPC-UA, MQTT, and MTConnect, and how to prove the feed is trustworthy before anyone builds an OEE tile on top of it.

Three protocols, three jobs

OPC-UA is the workhorse for PLC and SCADA data: browse the server's address space, subscribe to nodes, and let the server push changes on a deadband rather than polling. MQTT (often Sparkplug B) is pub/sub over a broker — lightweight, good for sensors and edge gateways, but you own topic structure and birth/death certificates. MTConnect is the read-only, XML-over-HTTP standard native to CNC and machine tools, where you pull a stream of samples and events from the agent.

Pick by what the asset actually speaks, not by preference. A CNC cell gives you MTConnect for free; forcing an OPC-UA wrapper adds a failure point. KaizenFlow's connector library (43+) sits on top of these to normalize MES/SCADA/ERP into the same tag model.

OPC-UA: subscriptions + deadband, browse the namespace, prefer over polling
MQTT/Sparkplug B: pub/sub, watch birth/death certs and QoS
MTConnect: pull samples/events from the agent, read-only by design

FIG. 1.A THE READ-ONLY DATA PATH KF·CE-01

Three protocols carry raw tags up into one normalized model — pick each by what the asset actually speaks. The whole stack sits beside the control path: it reads the plant, it never writes back.

Validate before you trust

A connected feed is not a valid feed. Confirm units and scaling (a counter in dozens vs. each will silently 12x your throughput), timestamp source (device clock vs. ingest time — clock skew destroys downtime attribution), and update cadence against the tag's real change rate. Then watch for stale tags: a value that never changes during a running shift is usually a dead subscription, not a stable machine.

Cross-check one tag against ground truth — a shift's good-count tag against the operator's tally, a state tag against what the andon shows. If those agree, you have a feed worth modeling on.

FIG. 1.B THE PRE-TRUST CHECKLIST KF·CE-01

Five checks stand between "connected" and "valid." Each catches a failure that looks exactly like normal data — an each-count ingested as dozens reads as a healthy feed running 12× too fast.

Key takeaway

A connection is not a validation: prove units, timestamps, and counts against ground truth before any tile depends on the tag.

Module quiz · question 1 of 3

You bring a packaging line online over OPC-UA. The good-count tile reads roughly 12× the line's rated capacity — physically impossible. The subscription is live and updating.

Q1What do you check first?

Module quiz · question 2 of 3

Q2A new cell arrives full of CNC machine tools. Which protocol do they speak natively — and what's its defining property?

Module quiz · question 3 of 3

Mid-shift, the filler is visibly cycling, but its state tag has reported the same value for 90 straight minutes — through two changeovers your operators confirm happened.

Q3What does a tag that never changes during a running shift usually mean?

Module 02 · 26 min · 2 fig.

Modeling assets and losses

OEE only means something when the asset hierarchy, OEE definitions, and loss taxonomy match how the plant actually runs. This module is about modeling so a number on the dashboard means what the plant floor means by it.

Hierarchy and the OEE definition

Model the asset hierarchy to the constraint: site → area → line → cell/station, with the bottleneck station identified, because line OEE is governed by it. Each level rolls up, but you measure and act at the station.

Then pin the OEE definition explicitly. Availability = run time / planned production time — which forces a decision on what counts as planned (are changeovers, breaks, and unscheduled time in or out?). Performance = (ideal cycle time × total count) / run time, so the ideal cycle time per part must be real, not aspirational. Quality = good count / total count. Ambiguity in any term is the most common reason two stakeholders 'disagree' about OEE when the math is identical.

FIG. 2.A MODEL TO THE CONSTRAINT KF·CE-02

Site → area → line → station: every level rolls up, but line OEE is governed by the bottleneck. Line 2 can never beat the capper's 63 for long — measure at every station, act at the constraint.

Loss taxonomy that maps to the Six Big Losses

Reason codes are the vocabulary of every later recommendation, so structure them to the Six Big Losses: breakdowns and setup/changeover (availability); minor stops and reduced speed (performance); startup rejects and production rejects (quality). Keep the list short enough that operators log honestly and granular enough that the AI can rank actions.

Avoid two failure modes: a giant catch-all 'Other' bucket that swallows the signal, and over-splitting into codes nobody can tell apart in the moment. Map each code to exactly one loss category so TEEP and OEE attribution stay clean.

Availability losses: breakdowns, setup/changeover
Performance losses: minor/idling stops, reduced speed
Quality losses: startup/yield rejects, production defects

FIG. 2.B SIX BIG LOSSES, THREE OEE TERMS KF·CE-02

Every reason code maps to exactly one loss, and every loss lands in exactly one OEE term. A code that could land in two places is a code operators will log two different ways.

Key takeaway

Define every OEE term and map every reason code to one of the Six Big Losses — otherwise the dashboard is precise about the wrong thing.

Module quiz · question 1 of 3

Maintenance says the line's availability is fine; the plant manager says it's terrible. Both pull the same KaizenFlow tile, and the underlying numbers are identical.

Q1Where do you look first?

Module quiz · question 2 of 3

Q2An operator logs "running at reduced speed" and "minor stop — jam cleared in 40 seconds." Which OEE term do both entries hit?

Module quiz · question 3 of 3

A line's performance reads 104% most shifts. You find the ideal cycle time was entered from a decade-old spec — slower than the machine has actually run since a drive upgrade.

Q3Why is performance over 100% a modeling defect, not good news?

Module 03 · 24 min · 2 fig.

Tuning the intelligence

Baselines, thresholds, and confidence settings decide whether KaizenFlow's recommendations are signal or noise. This module is about tuning them so the next-best action and alerts earn the operator's trust.

Baselines and thresholds

A baseline is the expected behavior an anomaly is measured against — and it must be contextual. Use the same product, same shift pattern, and same asset state; a baseline built across mixed SKUs will flag every changeover as an anomaly. Refresh baselines after a deliberate process change so the model doesn't keep comparing to a world that no longer exists.

Thresholds set the trip point. Set them against process variation, not round numbers: a tight threshold on a noisy tag generates alert fatigue, and a loose one misses real drift. Where you can, use rate-of-change and dwell (must persist N cycles) instead of a single-sample crossing to cut false trips.

FIG. 3.A DWELL BEATS THE SINGLE SAMPLE KF·CE-03

A single-sample rule would have tripped on the cycle-5 spike and cried wolf. Dwell — persist three cycles over the line — ignores the spike and still catches the real drift with room to act.

Worked example — setting one threshold

A capper torque tag reads a mean of 50 with a standard deviation of 2 on the current SKU. Someone proposes a threshold of 52 — a nice round number. That sits one σ out, so healthy noise alone crosses it on roughly one cycle in six: dozens of false trips a shift, guaranteed.

threshold = μ + 3σ = 50 + 3 × 2 = 56 trip rule = 3 consecutive cycles over

At 56 with a three-cycle dwell, random noise almost never trips — but a real drift walks through 56, stays there, and fires with margin left before the reject limit. Rebuild μ and σ per SKU and after every deliberate process change: the threshold is contextual because the baseline is.

Confidence and the trust loop

Confidence governs what surfaces. Raising the confidence threshold reduces false positives but lets some real events through; lowering it catches more but risks crying wolf. Early in a deployment, bias toward fewer, high-confidence alerts — one ignored alert teaches operators to ignore all of them.

Close the loop with feedback. When an operator marks a recommendation as useful or a false alarm, that label should retune the relevant threshold or baseline. Track precision over time: the metric that matters is the share of surfaced actions that were worth acting on.

FIG. 3.B WHAT THE OPERATOR ACTUALLY SEES KF·CE-03

Early in a deployment, fewer high-confidence alerts beat total coverage — one ignored alert teaches operators to ignore all of them. Precision, the share of surfaced actions worth acting on, is the number to track.

Key takeaway

Tune for trust first: contextual baselines plus high-confidence alerts beat a flood of technically-correct noise nobody acts on.

Module quiz · question 1 of 3

Three days into a deployment, one station's anomaly alert fires dozens of times a shift, and operators have started dismissing all of them unread. Spot-checks show most fire during changeover transitions, not faults.

Q1What do you fix first?

Module quiz · question 2 of 3

Q2Why does a dwell rule — the reading must persist over the line for N consecutive cycles — beat a single-sample crossing on a noisy tag?

Module quiz · question 3 of 3

After a planned drive upgrade, line speed rose 10%. The next morning, anomaly alerts flag the new cycle time on every run — the process is stable, just faster.

Q3What's the right move?

Module 04 · 24 min · 2 fig.

Failure forecasting in practice

Failure forecasting turns history into lead time. This module covers configuring and reading the predictive models — MTBF, Weibull, and failure-mode clustering — and matching the model to the asset class.

MTBF, Weibull, and reading the shape

MTBF (mean time between failures) is a single summary number — useful for spares planning and rough comparison, but it hides whether failures are random or wear-driven. Weibull analysis recovers that shape through its β (beta) parameter: β < 1 means early-life/infant-mortality failures (often install or commissioning issues), β ≈ 1 means random failures (MTBF-style, where preventive replacement doesn't help), and β > 1 means wear-out (where time-based maintenance pays off).

Reading β is the skill: it tells you whether a fixed maintenance interval is even the right strategy for that asset, or whether you should chase the install defect instead.

FIG. 4.A ONE CURVE, THREE REGIMES KF·CE-04

The Weibull β names where on the bathtub an asset lives. β < 1: chase the install defect. β ≈ 1: fixed intervals don't help. β > 1: time-based maintenance pays — and the forecast tells you when.

Worked example — same MTBF, opposite strategies

A gearbox logged 4 failures across 8,000 run hours. The summary number is easy:

MTBF = run hours ÷ failures = 8,000 ÷ 4 = 2,000 h

Now look at the spacing. Intervals of 1,900, 2,100, 1,950, and 2,050 hours are tightly clustered — a Weibull fit lands β well above 1, and a planned replacement around 1,800 hours beats almost every failure.

The same 2,000-hour MTBF from intervals of 300, 3,700, 900, and 3,100 hours is β ≈ 1 — random — and no fixed interval helps; you'd be swapping good parts while failures arrive on their own schedule. MTBF gave you the average. β gave you the strategy.

Clustering and matching model to asset class

Failure-mode clustering groups similar failure signatures so a recurring fault gets one root cause instead of fifty one-off tickets. It needs enough labeled history to be meaningful — on a new line, treat early clusters as hypotheses, not verdicts.

Match the model to the asset class. Wear components (bearings, belts, tooling) suit Weibull with β > 1 and time/condition-based intervals. Electronics and random-failure assets are better served by MTBF and condition monitoring than by calendar replacement. Don't impose one global policy across mixed asset classes — that's how you over-maintain stable assets and under-maintain wear-out ones.

FIG. 4.B WHERE TIME-BASED MAINTENANCE PAYS KF·CE-04

Bearings, belts, and tooling climb like this — replace on time or condition and you buy the flat part of the curve again. Electronics at β ≈ 1 have no climb to beat: calendar swaps just spend money and add induced-failure risk.

Key takeaway

The Weibull β tells you the failure regime — early-life, random, or wear-out — and that regime, not a calendar, should pick the maintenance strategy.

Module quiz · question 1 of 3

A control board on a packaging cell keeps failing. Maintenance proposes a fixed 90-day preventive replacement. The Weibull fit on its failure history shows β ≈ 1.

Q1What do you tell them?

Module quiz · question 2 of 3

Q2A bearing population fits Weibull with β = 2.6. What does that tell you about maintenance strategy?

Module quiz · question 3 of 3

Gearboxes on a new line keep failing in their first 200 hours — right after installation or rebuild. A Weibull fit gives β = 0.6. The team wants to double PM frequency.

Q3Why will more PM make this worse, and what should you chase instead?

Module 05 · 22 min · 2 fig.

Integrating the closed loop

A finding that doesn't reach a work order changes nothing. This module covers wiring KaizenFlow into CMMS/MES workflows and verifying the closed loop end to end — including the finance check that makes a saving real.

Wiring the loop into CMMS/MES

The closed loop is: detect (anomaly/forecast) → recommend (next-best action) → act (work order in the CMMS) → execute (technician + MES context) → verify (did OEE recover and did finance confirm the saving). Your job is to make each handoff machine-readable, not a copy-paste.

Integrate by mapping fields deliberately: KaizenFlow's asset ID to the CMMS asset, the reason code/failure mode to the work-order type, severity to priority. Decide the trigger policy — auto-create a work order above a confidence/severity threshold, queue for review below it. Pass identifiers back so the work order links to the originating finding; without that link you can't verify outcomes later.

Map asset ID, reason code → WO type, severity → priority
Set an auto-create vs. review threshold by confidence/severity
Return WO and finding IDs both ways so outcomes are traceable

FIG. 5.A THE CLOSED LOOP, WIRED KF·CE-05

Detect → recommend → act → verify, with the technician executing in MES context inside "act." Each handoff is a field mapping, not a copy-paste — and the dashed return is the part most integrations skip.

Verifying end to end

Verification has two halves. Operationally: after the action, confirm the targeted loss actually dropped — availability recovered, that reason code's frequency fell — not just that the ticket closed. A closed work order with no OEE change is an unverified fix.

Financially: the verified-savings ledger only credits a saving when the operational gain is confirmed and finance validates the dollars. Build the loop so the finding, the work order, the OEE delta, and the finance sign-off all reference the same ID. That traceability is what makes the savings finance-grade rather than a claim — and it's what lets you tune the trigger thresholds based on which findings actually paid off.

FIG. 5.B CLOSED TICKET VS CLOSED LOOP KF·CE-05

Operational: the targeted loss actually dropped. Financial: finance validates the dollars. Only when both halves reference the same finding ID does the saving move from claim to ledger.

Key takeaway

The loop isn't closed when the work order closes — it's closed when the loss measurably drops and finance signs off on the saving, all tied to one traceable ID.

Module quiz · question 1 of 3

KaizenFlow auto-created a work order from a high-confidence forecast. The technician closed it as complete — but the station's downtime for the targeted reason code is unchanged three shifts later.

Q1What is this, and what do you do?

Module quiz · question 2 of 3

Q2When you wire KaizenFlow into the CMMS, what must travel in both directions for outcomes to be traceable later?

Module quiz · question 3 of 3

To "never miss anything," a plant sets every finding — any confidence, any severity — to auto-create a CMMS work order. Two weeks in, technicians triage a wall of low-value tickets by ignoring most of them.

Q3What's the right trigger policy?

Course complete.

You’ve worked all 5 modules. Sit the free practice exam to see if you’re ready for the real assessment — same format, instant grading, keyed back to the modules.

Take the practice exam → Get certified

KaizenFlow AI Certified Engineer — Course

Connecting the plant

Three protocols, three jobs

Validate before you trust

Modeling assets and losses

Hierarchy and the OEE definition

Loss taxonomy that maps to the Six Big Losses

Tuning the intelligence

Baselines and thresholds

Confidence and the trust loop

Failure forecasting in practice

MTBF, Weibull, and reading the shape

Clustering and matching model to asset class

Integrating the closed loop

Wiring the loop into CMMS/MES

Verifying end to end

Course complete.