Continual Learning at the Edge: An Agnostic IIoT Architecture

AI summary

Overview

Research area: Edge computing and continual (incremental/lifelong) learning applied to Industrial Internet of Things (IIoT) and smart manufacturing quality control.

Technical level: Intermediate. The architecture is described in modular, tool-level terms (Docker, MLflow, MinIO, PostgreSQL, OPC-UA) and the learning model is named and characterized, but the paper does not present full algorithmic detail for TRIL3, XuILVQ, or DNDF.

Scope: The paper proposes a model-agnostic four-module edge architecture for continual learning on non-stationary industrial data streams and validates it in a simulated deployment on a Raspberry Pi 4B using real data from a cheese manufacturing plant.

What This Paper Is About

Traditional centralized cloud and offline machine learning pipelines struggle with industrial settings where data arrives continuously, non-stationarily, and at high frequency, because retraining from scratch is costly and transmitting all raw data introduces latency. The authors address this by designing an edge-side architecture that lets a model update incrementally from incoming production data, reducing catastrophic forgetting, and they test it on a real use case: real-time prediction of cheese hardness at the Quescrem cheese factory so defects can be caught before laboratory analysis.

Key Contributions

1. An agnostic edge computing architecture for IIoT. A four-module design (Data Management, MLflow Predict, Continual Learning model, Optimizer) that is not tied to a specific data type, edge device, or industrial process, and can therefore be reused across manufacturing scenarios.

2. A continual learning workflow with human-in-the-loop retraining. New labeled samples are produced by having a human supply the label for samples the deployed model encounters, and these are used to retrain the model incrementally rather than retraining from scratch.

3. An optimizer module for corrective action. When a negative prediction occurs (output class "1", indicating a defect or abnormal deviation), a grid search over a bounded range of input covariates finds the combination of values that maximizes the probability of good final quality.

4. Real-world validation on a cheese production line. The architecture was implemented with the final software tools and edge device, and tested using real factory data from Quescrem, an SME in northern Spain selected through the AI-REDGIO 5.0 project.

Main Findings

• Learning model choice: The continual learning model used was TRIL3, a framework for tabular data classification that addresses catastrophic forgetting. It combines XuILVQ, an incremental generative model producing synthetic data representative of past tasks (so old samples do not need to be stored), with Deep Neural Decision Forest (DNDF), a modified classification algorithm that runs incrementally.

• Edge device: The deployment target was a Raspberry Pi 4B with a Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC at 1.8GHz and 4GB of SDRAM on an ARM64 architecture, chosen for its balance of computing power, energy efficiency, and affordability.

• Training and evaluation data: The model was trained on a labeled dataset of 317 samples collected from the cheese manufacturing production process, and evaluated using a set of 50 production processes.

• Alarm confusion matrix: Defective process with alarm activated: 17; defective process with alarm not activated: 7; correct process with alarm activated: 4; correct process with alarm not activated: 22.

• Alarm precision when triggered: 80.95% of the times alarms were triggered, the product was indeed defective.

• Alarm precision when not triggered: 75.86% of the times no alarm was triggered, the product was satisfactory.

• Deployment status: The system could not be implemented directly in the cheese manufacturing plant at this stage of the project; it was implemented as a simulation of the final scenario using the final software tools, the edge device, and real data provided by the factory.

• Operational behavior: When predictions stay within a satisfactory range, the system runs normally; when there is a significant number of adverse predictions, the optimizer module is invoked.

Methodology in Plain English

The authors first defined a generic architecture split into four modules, deployed as separate Docker containers:

• Data Management collects real-time sensor data, preprocesses it, generates samples, and sends them for prediction. If enough negative predictions accumulate, it calls the Optimizer.
• MLflow Predict runs a server that receives samples and returns predictions using the currently deployed model; MLflow tracks metrics such as F1 and Accuracy and the parameters of each run. When a newer model exists, the container is stopped and relaunched with the new model.
• Continual Learning model trains and evaluates the model, registers it in MLflow, and deploys the prediction container. It can be warmed up from a file of previously collected data rather than starting from scratch, and then retrained online as needed. It also has its own endpoint for prediction so the whole system can run with no cloud component at all.
• Optimizer receives the sample that produced a negative prediction and runs a grid search over the input covariates to find values that would produce the best model output.

The validation setup also uses Harbor to host the four Docker images, MinIO as a cloud object store for models and other artifacts, and a PostgreSQL cloud database for metrics and parameters. Sensors communicate via OPC-UA, the standard industrial automation protocol; because data did not arrive directly from an OPC-UA server, the arrival of data at the OPC-UA client was simulated with a stream of the reserved prediction data.

For the use case, the continuous manufacturing process has six consecutive stages: mixing, pre-concentration, fermentation, concentration, addition, and packaging. Operators can actively make changes during the penultimate stage (addition). The dataset includes static data from the first three phases (average values) and dynamic data from the fifth phase that arrives periodically; quality predictions are required during that fifth stage. Variables collected by sensors across the six phases include temperature, pressure, pH, hardness, fat ratio, protein ratio, lactose, flow rate, viscosity, and frequency. Data are of two types: laboratory-analyzed samples with one record per production batch, and sensor samples arriving at high frequency (two samples per minute). In the optimizer, the values of five additive process variables are varied over a bounded range of possible values.

Why This Matters

Impact on research: The work argues that a limited amount of prior work explores continual learning at the edge, and that existing edge deployment studies often omit machine learning models altogether. By making the architecture model-agnostic, it separates the deployment and lifecycle scaffolding from the choice of learning algorithm, which lets practitioners swap models as requirements evolve.

Real-world applications:

• Real-time quality control in food manufacturing, demonstrated here as hardness prediction and waste reduction in cheese production.
• Defect detection in production lines where faults must be caught before the final laboratory check.
• Fault diagnosis in industrial equipment fed by non-stationary sensor streams.
• General Industry 4.0 / Industry 5.0 small and medium enterprise deployments where low-cost edge hardware and limited cloud connectivity are the norm.

Industry relevance: The paper targets manufacturing SMEs and positions AI-at-the-Edge as part of the Industry 5.0 transition. It emphasizes reduced latency, lower bandwidth consumption, improved privacy through local processing, and real-time response as the practical benefits, and it notes the cost reductions implied by not continuously retraining models from scratch.

Future Directions

• Full deployment in the manufacturing environment. The authors state they are currently working on deploying the system in the real plant rather than in simulation.
• Gathering more data to improve the model. Ongoing data collection is planned to strengthen model performance.
• Optimizing model handling. Instead of always using the latest trained model, the roadmap calls for smarter model management.
• User interface development. A UI is planned to make interacting with the system easier.
• Scaling to multiple production lines. The next step is to manage and monitor several production lines simultaneously.

Target Audience

Researchers and practitioners working on edge AI, continual learning, and IIoT for manufacturing, particularly those interested in deploying incremental learning on constrained devices. It is also useful for industrial engineers and SME technology decision-makers evaluating Industry 4.0/5.0 quality control retrofits, and for readers looking for an architecture-level (rather than algorithm-level) treatment of catastrophic forgetting mitigation in production settings.

Authors’ abstract

The exponential growth of Internet-connected devices has presented challenges to traditional centralized computing systems due to latency and bandwidth limitations. Edge computing has evolved to address these difficulties by bringing computations closer to the data source. Additionally, traditional machine learning algorithms are not suitable for edge-computing systems, where data usually arrives in a dynamic and continual way. However, incremental learning offers a good solution for these settings. We introduce a new approach that applies the incremental learning philosophy within an edge-computing scenario for the industrial sector with a specific purpose: real time quality control in a manufacturing system. Applying continual learning we reduce the impact of catastrophic forgetting and provide an efficient and effective solution.