Edge AI in Production Maintenance: Two Reference Deployments and How to Evaluate Them

Where an inference model physically executes has quietly become one of the most consequential choices a reliability or operations team makes — more consequential, in many plants, than the choice of model itself. Route every vibration trace, current waveform, and temperature reading to a remote server and the fault loop inherits network latency, bandwidth ceilings, and connectivity risk. Put a compact model on the controller that already touches the sensor, and the alert is produced at the source. Two embedded reference deployments make that shift auditable: Microchip's dsPIC33A digital-signal controller applied to DC arc fault detection, and Texas Instruments Inc.'s MSPM0G5187 MCU applied to gearbox fault detection. Below they are treated not as component announcements but as application case studies — what the failure looks like, what the data situation is, what the toolchain costs, and what numbers a plant team can verify.

Why reliability teams push inference onto the asset

Centralized analytics still earns its place for reporting, fleet-wide trend analysis, and model training. But the operational trade-offs change quickly once execution moves to the machine. The comparison below maps those trade-offs exactly as the reference deployments describe them.

Operational dimension	Centralized analytics	Local inference at the device
Scaling across a large plant	Large plants with hundreds of machines can face heavy communications overhead that is harder to scale centrally	Expansion is easier because inference moves into distributed nodes near each machine or system
Fault response timing	Vibration signals, motor currents, and temperature are high-frequency data; sending them continuously over a centralized industrial network can overload bandwidth and increase latency	Fault detection and the matching response happen sooner, which is critical for robustness and reliability; continuous real-time monitoring reveals abnormal behavior quickly while preserving deterministic control-loop timings
Behavior when the network drops	Fault processing depends on the network and on internet connectivity	Local decision-making reduces that dependence, and offline operation can last longer
Bandwidth and storage	Raw sensor streams must be carried and retained centrally	Only high-level information is sent to the central network, so bandwidth and storage needs can be much lower
Sensitive operational data	Data leaves the cell for analysis	Keeping sensitive information in the local device reduces the chance of data breaches and cyber threats

What actually sits on the machine

Before comparing model types, it helps to be concrete about the application stack. An embedded monitoring system typically combines the following layers:

• Sensors, DC/DC converters, and other signal-conditioning circuits that turn a physical event into a usable signal
• A microcontroller (MCU) or processor that runs the inference alongside its control tasks
• Communication interfaces that carry summarized results upstream rather than raw streams
• An alternative form factor: smart sensors that embed AI chips. Such devices can watch sensor data, run embedded AI algorithms, diagnose issues, and produce fault alerts on their own

Cloud-trained, edge-run: how the split works in practice

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

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

The practical difference for an application team is the execution environment. In contrast with cloud servers, edge AI hardware must operate continuously in harsh settings, including vibration and high temperatures. Choosing hardware becomes a balance of 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 — the property most maintenance use cases actually depend on.

On the modeling side, embedded AI is generally built on machine learning (ML): such models learn patterns and produce inferences that enable accurate anomaly detection, with decision trees, support-vector machines, and random forests among the common model types. Deep learning (DL), the subset of machine learning that relies on artificial neural networks, can address complex patterns but needs more computational and memory resources.

Case 1 — DC arc fault detection on the Microchip dsPIC33A

The failure mode that hides inside load noise

Power spikes, insulation degradation along the power transmission path, degradation in semiconductor devices or passive components used for power conversion, and load failures can all produce arc faults, and these faults create safety hazards for personnel and equipment. Signatures are application-specific: arcs from an electric-vehicle battery disconnect do not resemble arcs from a solar inverter.

DC power transmission has expanded notably in recent years, with solar energy generation and EV charging stations illustrating 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. This is why a purely threshold-driven design tends to miss the event that matters most.

The constraint every arc project hits first: data

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. One way to test the ML toolchain is to use the publicly available IEEE low-voltage DC arc datasets, which Microchip Technology Inc. uses in its arc fault-detection reference design.

The silicon that closes the interrupt-timing gap

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), making them suited to precision motor control, digital power conversion, and advanced sensing. Within that family, the dsPIC33A is Microchip's most advanced series: 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.

The analogue and mixed-signal front end is part of the value proposition. 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. Interrupt behavior is the other half: 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.

Toolchain, footprint, and the measured result

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, and 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 pairs the IEEE low-voltage DC arc datasets with MPLAB ML to produce a compact decision-tree model that reaches 100% accuracy. Source: Microchip Technology Inc.

Case 2 — Gearbox fault detection on the TI MSPM0G5187

Why an NPU changes the power math

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 (TI'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, and has been shown to use 120× less energy per inference and have 90× lower latency than software-based AI.

The development flow an application team follows

TI's 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.

The dataset and the outcome

The demonstration targets a familiar maintenance problem. 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 SpectraQuest's Gearbox Fault Diagnostics Simulator. It contains recordings from four sensors placed in four different directions, with the load varying from 0% to 90%, and 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; the optimized AI-based model reaches 99.9% accuracy versus traditional rules-based detection.

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

The two deployments side by side

Evaluation dimension	Arc fault detection — Microchip dsPIC33A	Gearbox detection — TI MSPM0G5187
Business problem	Safety hazard plus shutdown of DC power paths where series arcs are nearly invisible in current	Shift from reactive to predictive maintenance on gearboxes and motors
Compute approach	DSP engine plus single-step ISR on a 32-bit CPU at 200-MHz	TinyEngine NPU inside a 32-bit Arm Cortex M0+ core
Model class used	Decision-tree-based model	1D CNN, deployed to the NPU or CPU
Training data	Publicly available IEEE low-voltage DC arc datasets	SpectraQuest's Gearbox Fault Diagnostics Simulator: four sensors, four directions, load 0% to 90%
Development toolchain	MPLAB ML, generating a C API for the MCU	CCStudio Edge AI Studio with the TI Model Zoo and a neural-network compiler
Reported footprint / throughput	1,142 bytes model, 1,336 bytes of SRAM, 4,522 bytes of flash; latency of 0.6584 ms	640–2,560 mega operations per second on pretrained CNN models
Accuracy versus the incumbent logic	100% on the DC arc dataset versus 57% for a rules-based series fault-inference approach	99.9% for the optimized AI-based model versus traditional rules-based detection
Energy and responsiveness angle	Interrupt latency of less than 0.18 µs versus 0.4 µs for a general-purpose MCU at 120 MHz	120× less energy per inference and 90× lower latency than software-based AI

Implementation path: from a bounded pilot to a line deployment

Both cases follow a sequence that a digital or maintenance-technology team can copy, regardless of which vendor's hardware is in the rack.

1. Name one fault class and its signature before choosing silicon. Different applications have distinct arc signatures, and a gearbox failure mode behaves nothing like a DC arc.
2. Secure data you are legally able to train on. When customer datasets are proprietary and not shared, a public set — the IEEE low-voltage DC arc datasets, or the open-source gearbox vibration recordings — is a legitimate way to exercise the toolchain first.
3. Match the accelerator to the model class: a DSP engine for signal-processing and single-cycle multiply-accumulate work, an NPU for CNN inference, or a smart sensor with an embedded AI chip if diagnosis is simple enough to live entirely inside the sensor.
4. Convert raw signals into statistically meaningful features in both time and frequency domains, then train and evaluate multiple algorithms rather than committing to one model type.
5. Treat memory as a hard gate. Record model size, SRAM, and flash against the target controller before the design review, not after.
6. Verify timing where it counts: interrupt latency, deterministic control-loop timings, and sampling predictability, not just average throughput.
7. Compile to the target — NPU or CPU — and run the AI path alongside the existing rules-based logic long enough to compare detection rates under real load conditions.
8. Decide what travels upstream. Send only high-level information to the central network, and size the network and storage accordingly.

Pre-commitment checklist

• Rated for continuous operation in harsh settings, including vibration and high temperatures
• Speed, low-power capability, size, memory capacity, and computational performance balanced against the measured model footprint
• Analogue front end adequate for the signal: ADC resolution and sampling rate, op-amp bandwidth, comparator speed, DAC rate
• ISR architecture that keeps interrupt latency inside the response window the fault requires
• Deterministic real-time operation so sampling and control-loop timing stay predictable
• Toolchain that supports training, validation, optimization, and generation of deployable C code
• Availability of pretrained models, or a documented path to bring your own model and custom data
• A public or in-house dataset covering both healthy and failed states across the operating load range
• A documented rules-based baseline to quantify the accuracy delta in your own plant

Common misconceptions to correct before the business case

• "A DC arc will show up as a clear current drop." Series DC arcs formed along a single conductor wire produce only a small drop in overall current amid load fluctuations, and because DC arc faults lack zero-crossing they can be self-sustaining.
• "Clock frequency alone decides responsiveness." Two devices at similar clock speeds can differ sharply in interrupt behavior: a typical 20-instruction ISR compresses to four to six instructions with single-step context switching, moving latency from 0.4 µs to less than 0.18 µs.
• "Rules-based inference is close enough." In the arc case the incumbent approach reached 57% against 100% for the trained model; in the gearbox case the optimized model reached 99.9% versus traditional rules-based detection.
• "Anomaly detection needs deep learning." The arc project was won by a decision-tree model occupying 1,142 bytes, while DL addresses complex patterns at the cost of more computational and memory resources.
• "An NPU replaces a DSP engine." The NPU is less flexible but delivers better speed/performance/power tradeoffs for matrix-multiplication-heavy CNN inference — they answer different application needs.
• "Edge means abandoning the cloud." Training can still target high-accuracy inference across many fault conditions; the architectural decision is where inference executes.

Risk boundaries

Three limits deserve to appear in the business case rather than in a footnote. First, data availability: useful ML models for DC arcs are constrained by the scarcity of widely available datasets, and public sets are a toolchain validator, not a substitute for your own installation's fault records. Second, signature variability: arcs from a battery disconnect and arcs from a solar inverter are not the same problem, so a model validated on one does not automatically transfer. Third, environment and resources: edge hardware runs continuously under vibration and high temperatures, and DL models demand more computational and memory headroom than the simpler model classes. The privacy argument also has a boundary — keeping sensitive information in the local device reduces breach exposure, but it relocates the protection problem rather than removing it.

FAQ

What counts as "edge AI" in a maintenance deployment?

An inference model executing on the controller or smart sensor that acquires the signal, rather than on a server. The embedded monitoring system still combines sensors, conditioning circuits, an MCU or processor, and communication interfaces; what changes is that measurements become decision-making inference close to the source.

How long does model development take, and what does the result cost in memory?

In the arc example, MPLAB ML trained a model in just 13 minutes using the IEEE DC arc datasets. The generated decision-tree model occupied only 1,142 bytes, utilizing 1,336 bytes of SRAM and 4,522 bytes of flash, and achieved a latency of 0.6584 ms with 100% accuracy on that dataset.

When should a team pick an NPU-based MCU over a DSC?

When the detection model is a CNN that needs extensive matrix-multiplication operations. The TinyEngine NPU in the MSPM0G5187 performs 640–2,560 mega operations per second on pretrained CNN models and shows 120× less energy per inference with 90× lower latency than software-based AI. A DSP engine remains the more flexible option for signal-processing work.

Which datasets can a team realistically start from?

Two open starting points appear in these deployments: the publicly available IEEE low-voltage DC arc datasets, and the gearbox vibration set generated with SpectraQuest's Gearbox Fault Diagnostics Simulator, which covers healthy and broken-tooth gearboxes across four sensors, four directions, and loads from 0% to 90%. Eight trained models were produced from that data.

Does local inference change what we send to the central network?

Yes — only high-level information goes upstream, so bandwidth and storage needs can be much lower, and the cell can continue operating when the network is unavailable.

Action recommendations

Start with the fault that is both expensive and under-instrumented, then run one vendor toolchain end to end against a public dataset so the effort is measured in minutes and bytes rather than assumptions. Record four numbers during that exercise — training time, model footprint, inference latency, and accuracy against your current rules-based logic — because those are the figures that determine whether a pilot can move to production hardware. Use them to decide between a DSP-based DSC, an NPU-equipped MCU, or a smart sensor, and only then design the rollout across a plant with hundreds of machines, where distributing inference to the assets is what keeps communications overhead from stalling expansion. The two deployments reviewed here offer a defensible benchmark: 100% versus 57% on arc detection, and 99.9% versus rules-based detection on gearbox fault diagnosis. A team that cannot reproduce a comparable delta on its own data has answered the feasibility question before any capital is committed.