An existing industrial machine is AI-ready when selected machine signals can be collected reliably, given clear operational meaning, stored with enough history, and supplied to an analysis workflow that people can review. It does not require putting an AI model inside the PLC or allowing software to control the machine.
For many retrofits, the practical goal is simpler: make machine data trustworthy enough that an operator, maintenance technician, production planner, or service engineer can ask a useful question and receive a grounded explanation or recommended next check.
What does “AI-ready” mean for an existing machine?
There is no single AI-ready switch. A useful retrofit has four connected layers:
- Signal access: the project can read the required states, counts, measurements, and events without disrupting machine control.
- Operational context: each value has a stable name, unit, timestamp, source, and meaning.
- Usable history: run periods, stops, products, workcenters, quality events, and other relevant records can be compared over time.
- A controlled decision workflow: AI output is tied to available data, its limitations are visible, and a qualified person decides what happens next.
A machine can satisfy those conditions even if it is old, has no native cloud connection, and was never designed for AI. Conversely, a new connected machine is not automatically AI-ready if its tags are poorly defined or its production records cannot be trusted.
The 2026 NIST roadmap for AI and machine learning in smart manufacturing identifies industrial data management, heterogeneous system integration, explainability, and reliable operation as important adoption challenges. Those are architecture and process questions, not just model questions.
NIST research on automating asset knowledge with MTConnect describes the long-standing difficulty of integrating closed, proprietary factory equipment and the value of continuously collected machine-status data. The lesson is broader than one protocol: useful analysis begins with a dependable observation path.
Start with one operational question
Do not begin by copying every PLC tag into a database. Begin with a question that has an owner and a possible action.
Examples include:
- What caused the most recorded downtime this week?
- Which workcenter has the largest recurring stop category?
- Why did OEE change between two comparable periods?
- Is scrap increasing for a particular product and machine combination?
- Which recent indicators should maintenance review before the next planned stop?
The question determines the required data. Downtime analysis may need state transitions, timestamps, workcenter identity, and reason codes. OEE additionally needs agreed definitions for planned production time, run time, ideal rate, total count, and good count. Maintenance investigation may require failure classifications or condition measurements that a basic production data set does not contain.
This is also where the team should define what the AI may do. “Summarize recorded losses and suggest checks” is a bounded decision-support task. “Diagnose every failure” or “optimize the machine automatically” is not a credible first retrofit scope.
Build a small, explicit machine-data contract
AI cannot repair an unclear data definition. Before connecting an assistant or analysis service, document the smallest data contract that supports the chosen question.
| Data element | Definition to record | Common problem |
|---|---|---|
| Machine or workcenter ID | Stable identity used across PLC, MES, reports, and service records | The same asset has different names in different systems |
| Machine state | Exact meaning of running, stopped, waiting, faulted, or unavailable | A single bit is treated as complete production truth |
| Timestamp | Source clock, timezone, and event time | PLC, edge device, and server clocks disagree |
| Counts | Total, good, bad, reset behavior, and counter unit | Counter resets appear as negative production |
| Product or order | Product identity and when a change becomes effective | Events cannot be compared with the correct production context |
| Stop reason | Automatic signal, operator reason, and classification rules | Unknown stops are silently assigned a guessed cause |
| Target or ideal rate | Approved value, unit, and product applicability | An outdated rate distorts performance and OEE |
| Measurement | Engineering unit, valid range, sample method, and freshness | A stale value looks like a current measurement |
The ISO 22400-1 framework provides an industry-neutral basis for defining and using manufacturing-operations KPIs. Its relevance to an AI project is straightforward: a model cannot interpret a KPI consistently when the underlying terms and construction rules change from one machine or shift to another.
Record data ownership as well. Someone should be responsible for approving tag meaning, production rules, stop classifications, and later changes. Without that ownership, a technically successful connection can still produce misleading analysis.
Add an observation path without changing the control boundary
The safest retrofit separates observation and decision support from machine control. The PLC continues to execute interlocks, sequences, motion, and safety-related logic. An industrial edge computer reads the selected data required by local applications and analysis.
The exact connection depends on the machine. It may use an available industrial protocol, a supported controller interface, an existing historian, or carefully added signals. Confirm electrical isolation, controller loading, network policy, permissions, and recovery behavior for the specific installation. Use read-only access where the workflow does not require writes.
An edge layer is useful because collection, local applications, and data normalization can run near the equipment. NIST’s Fog Computing Conceptual Model describes distributed computing as a response to the scale, heterogeneity, and latency challenges of sending all IoT activity directly to centralized cloud systems.
That does not mean every AI model must run locally. It means the architecture can decide deliberately what remains on site, what leaves the site, and what should happen when an external service is unavailable.
Preserve context, missing data, and uncertainty
A clean dashboard is not proof that the data is complete. Keep the information needed to judge each record:
- when the value was observed;
- which device and tag supplied it;
- whether communication was healthy;
- whether a value was manual or automatic;
- which product, work order, or shift was active;
- whether a stop reason was confirmed, inferred, or unknown;
- whether the selected period contains gaps.
Do not replace unknown values with convenient defaults merely to make a report look complete. Missing reason codes, stale measurements, or inconsistent counter rules should become visible data-quality notes. Those notes help a reviewer distinguish a real operational pattern from a collection problem.
History should match the question. A live value can show what the machine is doing now, but it cannot explain a weekly downtime pattern by itself. Store events and production context in a form that allows comparable periods to be reconstructed.
Keep AI output inside a human-review workflow
Generative AI can produce a fluent answer even when context is incomplete. Treat its response as a structured interpretation of supplied data, not as measurement evidence or proof of root cause.
NIST organizes the AI Risk Management Framework Core around govern, map, measure, and manage. For an industrial retrofit, that suggests practical controls:
- define the supported task and unacceptable uses;
- document which data is supplied and where it goes;
- test answers against known production periods;
- show assumptions and missing data;
- record who reviews recommendations;
- monitor performance as data definitions and operations change;
- provide a way to stop using the AI workflow without stopping the machine.
The NIST Generative AI Profile also emphasizes that risk management depends on the particular use case and should continue across the AI lifecycle. A successful demonstration is therefore the start of validation, not the end.
Run a one-machine pilot
A focused pilot is more useful than a broad “AI transformation” project.
- Choose one machine and one operational question.
- Identify the person who will use the answer.
- Select only the signals and records required for that question.
- Verify each tag, unit, timestamp, counter rule, and state definition.
- Compare the digital history with actual machine and operator records.
- Generate AI-assisted explanations from a known period.
- Ask the responsible operator, engineer, or technician to challenge the output.
- Record incorrect conclusions, missing context, and collection failures.
- Decide whether the workflow saves investigation time or improves consistency.
- Expand only after the data contract and review process are stable.
Useful success criteria are specific: fewer unexplained stops in the record, faster preparation for a maintenance review, or consistent use of the same OEE definitions. “The machine now uses AI” is not a measurable operating result.
How does Orenda support the retrofit?
Orenda Box sits near the machine, reads configured PLC and machine data, and runs local tools such as Orenda MES, Orenda SCADA, PLC setup, diagnostics, and approved remote-support applications. The PLC remains the machine-control authority.
When an administrator configures OpenAI access, AI assistance inside Orenda MES can answer questions grounded in recent run, downtime, OEE, and workcenter context. Report and analytics views can produce structured insights, recommended checks, and data-quality notes from their active scope. Advanced cross-module analysis requires MES Pro.
This AI assistance is optional and requires outbound connectivity. Relevant operational context is sent to the configured OpenAI service. It does not rewrite PLC logic, issue machine-control commands, prove root cause, or replace operational approval.
The practical path is therefore not to make an old machine autonomous. It is to give the machine’s selected data a dependable route into local operational software, add enough meaning and history for useful analysis, and keep each recommendation accountable to the people who understand the equipment.
