AIdataNewsGlobal AIApplications: How Edge AI Detects Industrial Faults at the Machine

This AIApplications guide is written for maintenance, operations, and product teams who need to understand how AI is used, not only where it is housed. For that reader, the most practical question is not where data could be stored, but where a fault signal must be interpreted. Edge AI places the inference step close to the asset, so a local device can react to sensor changes before everything is sent to a central network. The discussion below uses two examples of embedded edge AI analytics: DC arc fault detection and gearbox fault detection. Both use model-based analytics.

AI Application Checklist

The pattern becomes useful when the application has these features:

• There is a machine-local fault or anomaly signal, such as vibration, motor current, temperature, or arc behavior.
• A local action can matter, such as an alert, a shutdown, or a maintenance flag.
• Centralized bandwidth may be strained by high-frequency data.
• The device may need to keep working when network connectivity is limited.
• Sensitive readings may be safer kept in the local device.

Step-by-Step: Where AI Enters the Maintenance Workflow

1. Choose the local decision point. Decide whether the fault can be detected by an MCU, processor, or smart sensor next to the machine.
2. Collect the signal that represents the fault. The examples rely on time-domain data such as arc behavior or gearbox vibration.
3. Use model-based analytics. ML models can learn patterns and produce inferences for anomaly detection. Decision trees, support-vector machines, and random forests are common model types.
4. Run inference near the asset. Embedded hardware can maintain deterministic real-time operation, which makes sampling and control-loop timing predictable.
5. Act before raw data reaches the center. The machine can trigger an alert, start a shutdown, or raise a maintenance flag while only summary information travels upstream.

Why Local Inference Helps Industrial Operations

Compared with a centralized control system, local inference offers several practical application benefits:

• Scalability: A plant may have hundreds of machines. If inference sits in distributed nodes near each machine or system, expansion can be easier than routing every communication task through one central control system.
• Low latency: Fault detection and matching response can happen sooner. Because vibration signals, motor currents, and temperature are high-frequency data, continuous upload over a centralized industrial network can overload bandwidth and increase latency.
• Greater immunity to network outages: Local decision-making reduces dependence on the network for fault processing and on internet connectivity, so offline operation can last longer.
• Lower-bandwidth networks: Only high-level information is sent to the central network, so bandwidth and storage needs can be much lower.
• Enhanced privacy and security: Keeping sensitive information in the local device reduces the chance of data breaches and cyber threats.

Cloud Models, Edge Models, and Hardware Choices

When fault detection and inference are built on AI models, system robustness can improve greatly. Training can target high-accuracy inference over many fault conditions. These models can operate either in cloud servers or on edge devices.

Historically, cloud AI computing has been the more typical choice. Because larger models demand substantial computing capability, they are often confined to servers. Edge AI has achieved strong success as smaller, more efficient models appear and embedded MCUs and processors gain performance.

Edge AI hardware differs from cloud servers because it must operate continuously in harsh settings, including vibration and high temperatures. Choosing hardware can involve balancing speed, low-power capability, size, memory capacity, and computational performance. MCUs with AI support provide deterministic real-time operation, which makes sampling and control-loop timing predictable.

A further option is smart sensors that embed AI chips. Such devices can watch sensor data, run embedded AI algorithms, diagnose issues, and produce fault alerts.

Embedded AI is generally built on machine learning (ML). Such models learn patterns and produce inferences that enable accurate anomaly detection. Decision trees, support-vector machines, and random forests are common ML model types. Deep learning (DL) is a subset of machine learning that relies on artificial neural networks. DL can address complex patterns, but it needs more computational and memory resources.

Microchip Example: Local DC Arc Fault Detection

Power spikes, insulation degradation along the power transmission path, degradation in semiconductor devices or passive components used for power conversion, and load failures can produce arc faults. These faults create safety hazards for personnel and equipment. Different applications have distinct arc signatures, such as arcs from an electric-vehicle battery disconnect versus arcs from a solar inverter.

DC power transmission has expanded notably in recent years. Solar energy generation and EV charging stations illustrate DC power generation and load. In contrast with AC systems, DC arc faults lack zero-crossing, so they can be self-sustaining. Series DC arcs in solar panels, formed along a single conductor wire, may be difficult to detect because they produce only a small drop in overall current amid load fluctuations.

Microchip Technology Inc. uses the publicly available IEEE low-voltage DC arc datasets in its arc fault-detection reference design. A challenge for useful ML models of DC arcs is the scarcity of widely available datasets. Customer arc datasets are proprietary and are usually not shared by embedded controller manufacturers. Using the IEEE dataset provides one way to test the ML toolchain.

Microchip's dsPIC33 digital-signal controllers (DSCs) provide a digital-signal processing (DSP) engine and integrated high-performance peripherals such as analog-to-digital controllers (ADCs). They are suited to precision motor control, digital power conversion, and advanced sensing. Within that family, the dsPIC33A is Microchip's most advanced series. The DSC includes a 32-bit CPU capable of 200-MHz operation, a high-speed DSP engine for single-cycle multiply-accumulate instructions in numerical processing, and a double-precision floating-point unit for math operations.

High-speed peripherals include a 12-bit ADC capable of up to 40 mega samples per second (MS/s), 100-MHz gain-bandwidth op amps, 5-ns comparators, and 1-MS/s digital-to-analog converters. Where a general-purpose MCU uses multistep interrupt service routines (ISRs), the dsPIC33 uses a single-step ISR with context register switching to save critical context. This compresses a typical 20-instruction ISR to four to six instructions and enables low interrupt latency.

Together, the fast ISR response and 200-MHz operation reduce interrupt latency to less than 0.18 µs, versus 0.4 µs for a general-purpose MCU running at 120 MHz. That enables quicker response to time-critical tasks such as real-time arc fault detection and system shutdown.

Software development support is critical when deploying MCU hardware in real-time applications. Microchip's MPLAB ML development suite converts raw sensor data in both time and frequency domains into statistically meaningful features. Those features train and evaluate multiple algorithms to identify the best-performing model. The suite supports model training, validation, and optimization, and can generate a C API that runs on the MCU.

With the IEEE DC arc datasets, MPLAB ML trained a model in just 13 minutes. The decision-tree-based model generated for the dsPIC33A DSC was highly efficient: a size of only 1,142 bytes, utilizing 1,336 bytes of SRAM and 4,522 bytes of flash. It achieved a latency of 0.6584 ms with 100% accuracy on the DC arc dataset. By comparison, a rules-based series fault-inference approach achieved only 57% accuracy. A reference design based on the dsPIC33AK128MC102 DSC is available.

Figure 1: The arc-fault reference design from Microchip combines IEEE low-voltage DC arc datasets with MPLAB ML to produce a compact decision-tree model that reaches 100% accuracy. Source: Microchip Technology Inc.

Texas Instruments Inc. Example: Gearbox Fault Detection

A neural processing unit (NPU) is a specialized hardware accelerator tuned for neural-network computations. Although less flexible than a DSP engine, NPUs can deliver better speed/performance/power tradeoffs for DL models that need extensive matrix-multiplication operations, such as convolutional neural network (CNN)-based AI inference. Placing an NPU inside an MCU offloads computationally intensive tasks from the main CPU to the NPU, improving inference speed while reducing power consumption.

Texas Instruments Inc.'s MSPM0G5187 MCU includes a TinyEngine NPU integrated into a CPU based on a 32-bit Arm Cortex M0+ core. This NPU can perform 640–2,560 mega operations per second on pretrained CNN models. It has been shown to use 120× less energy per inference and have 90× lower latency than software-based AI.

CCStudio Edge AI Studio offers a graphical environment for model development, training, and compilation. Besides the pretrained models in the TI Model Zoo, developers can bring their own models or train models with custom data. Its neural-network compiler converts trained ML models into optimized C code for the specific hardware and enables seamless deployment to either the NPU or CPU.

TI has demonstrated edge AI analytics with the MSPM0G5187 MCU for gearbox fault detection. By monitoring vibration patterns through sensors and applying ML algorithms to detect anomalies, industrial systems such as gearboxes and motors can move toward predictive rather than reactive maintenance. 1D CNNs are highly effective for time-domain analysis of sensor data such as vibration patterns.

The vibration dataset used for the model was generated with the Gearbox Fault Diagnostics Simulator from SpectraQuest. It contains recordings from four sensors placed in four different directions, with the load varying from 0% to 90%. This open-source dataset covers both healthy and broken-tooth gearboxes. Eight trained models were created to run on the MCU using the vibration dataset. As Figure 2 illustrates, the optimized AI-based model reaches 99.9% accuracy versus traditional rules-based detection.

Figure 2: The TI gearbox fault detection example uses CCStudio Edge AI Studio and vibration-based ML, reaching 99.9% accuracy on an optimized model versus rules-based detection. Source: Texas Instruments Inc.

Application Comparison at a Glance

Aspect	Arc Fault Detection	Gearbox Fault Detection
Use case	Detect DC arc faults near the power path	Detect gearbox anomalies from vibration
Hardware example	dsPIC33A DSC; reference design dsPIC33AK128MC102	MSPM0G5187 MCU with TinyEngine NPU and Arm Cortex M0+
Model path	IEEE datasets, MPLAB ML, decision-tree-based model	SpectraQuest dataset, 1D CNN, CCStudio Edge AI Studio, TI Model Zoo
Reported outcome	100% accuracy on the DC arc dataset with 0.6584 ms latency	99.9% accuracy on the optimized model versus rules-based detection

Common Mistakes in Edge AI Maintenance Projects

• Assuming centralized analytics can always absorb vibration, motor current, and temperature streams without bandwidth or latency impact.
• Overlooking that DC arc faults can be self-sustaining and may only cause a small current drop amid load fluctuations.
• Choosing a model without checking memory, flash, SRAM, and power constraints.
• Relying only on proprietary customer datasets when public IEEE data can support toolchain testing.
• Treating edge AI as only cloud AI in a smaller box, while embedded hardware must operate continuously in harsh settings.
• Ignoring deterministic real-time operation, sampling timing, and control-loop timing.

Action Suggestions for Application Teams

• Start with one machine-level fault that has clear sensor data and a defined local action.
• Document whether AI will run on an MCU, processor, or smart sensor.
• Use model-based analytics rather than only fixed rules when fault signatures vary.
• Evaluate both model accuracy and implementation cost, including latency, memory, and power.
• For safety-critical faults, compare model results with rules-based approaches before deployment.
• Keep the central system informed with high-level outcomes, not every raw high-frequency sample.

For application teams, the value is not the edge itself, but the decision it enables near the machine. The two examples show how local AI can turn electrical and mechanical signals into faster fault awareness while keeping network traffic, privacy exposure, and real-time constraints under control.