AI Manufacturing

Principles and Suitability

AI in manufacturing covers a group of tasks, not a single system. Start with the question: visual inspection may need vision; tracking measurements may need suitable sensors or vision; forecasting needs time-based data. Ordinary rules or direct measurement instruments may suit some tasks better.

For general readers, AI use should begin with decisions people need to make and the data supporting them, rather than inserting models into every step. A use case is a task with a clear objective, such as collecting readings or assisting image review. More displayed information does not necessarily solve a problem. Identify who uses results, when, and what they do with incomplete answers. Keep the existing method as a comparison to determine whether added complexity is justified.

Engineers survey instruments, data channels, and operational technology boundaries before selecting an approach. Reading digital data directly differs from image inference, which introduces lighting and geometry uncertainty. Separate requirements for quality, freshness, and downstream decisions, with acceptance criteria approved by users. The term AI is not a substitute for quality evidence or confirmation that a system suits every manufacturing stage.

Scroll the diagram horizontally to inspect all details.

Illustrative Industrial Example

Design example: a factory needing pressure history might first investigate whether existing instruments can supply data. Only if that is unavailable should it assess image reading, rather than starting with a digital twin of the entire factory.

In this hypothetical situation, the requirement is to review values from a particular period. Existing data access may answer it without a camera. If the channel is inaccessible, dial reading becomes an option requiring checks on units, angles, and image quality. Image use does not eliminate instrument maintenance or calibration. Do not expand historical recording into automatic control without a separate assessment.

Engineers trial a small scope with reference answers and real users of the results. Compare direct data access, rules, and models against the task, including installation and maintenance time. Simulate missing data and incorrect outputs without commanding live machinery. Assign review ownership and criteria for stopping use. Expansion requires checking new sources and changed conditions rather than multiplying a single-point result into an assumed factory-wide benefit.

Study and Trial Workflow

Evaluation and Metric Definitions

Measure the selected task, such as reading error, missed defects, or forecast error. Separate these from business outcomes, which require a baseline and tracking total costs before conclusions can be drawn.

Technical scores describe specific answers. Business outcomes need an existing baseline and costs covering reviewers, storage, equipment, and maintenance. Reduced reading errors do not automatically imply less downtime, because decisions and other causes intervene. State what was actually measured and what remains a hypothesis. Do not invent savings percentages or real customer cases from a design example lacking operational evidence.

Engineers use tests matching scope, including units, timestamps, and result states. For image inspection, assess misses and false rejection; for forecasting, assess the prediction horizon. Do not combine scores from different tasks into one accuracy figure. Check changes to existing systems or data and the recovery plan. NIST AI and OT frameworks help structure risk management, not guarantee project success or product support for all manufacturing tasks.

Limitations and Failure Cases

A dashboard does not guarantee process improvement. AI cannot compensate for incorrectly calibrated instruments or quality criteria that have not been agreed.

Displaying data can support observation, but someone must interpret it and act. Without decision criteria, additional displayed values may not help. An inaccurate instrument can be read faithfully while still misrepresenting physical conditions. Evaluate the source measurement separately from the model. AI alone does not make machinery safe or demonstrate process quality when requirements and evidence remain incomplete.

Expanding across tasks increases dependencies and team workload; simpler methods may remain preferable for some work. Choose according to users and long-term resources, not technology names. This example is a framework for selecting use cases, not confirmation of current product capabilities or business outcomes. Control-system connections need responsible approval and risk assessment. Do not change live operation or disable protective systems to test an alleged AI advantage.

Practical Checklist

• Does the selected use case have data and actual users?
• Is there a non-AI method for comparison?
• Are OT connection boundaries and long-term maintenance plans defined?

References and Further Reading

• NIST — AI Risk Management Framework
• NIST SP 800-82 Rev. 3 — Guide to OT Security