A²LAB

Platform overview

A²LAB covers every system needed for AX transformation, from data infrastructure through to AI autonomous control. Each system is modular, so you can take only what your manufacturing environment needs.

Data infrastructure, AI deployment, field validation and ongoing maintenance all run on one platform. The point is to cut the integration cost and data loss that come from bolting a different product onto each stage.

Agent collaboration

Rather than a single AI model analyzing one problem, A²LAB is an AI orchestration platform in which agents responsible for production, operations, equipment and energy collaborate to reach a solution.

That matters most when a situation has causes in several places at once — equipment faults, energy imbalance, production delays. When a problem arises, a supervisor agent manages the overall situation while each specialist agent analyzes real-time data to find the cause. Virtual simulation then weighs the impact on plant-wide operation before an action plan is produced and carried out.

A² — no-code AI analytics and visualization

When every piece of manufacturing analysis has to pass through a development team, checking a single question that came up on the floor can take weeks. By then the question has usually gone away.

The A² module is a no-code AI analytics tool that an analyst configures much as they would phrase a question. Preprocessing, outlier handling and similar repetitive work can be set up intuitively without code, so non-specialists can build AI models.

It visualizes patterns hidden in data and offers insight from a range of perspectives, supporting prediction-led decision-making and collaborative dashboards. It connects to varied data sources, preprocesses and transforms data, and collects and processes it in real time, so data integration and predictive analysis together improve real-time operating plans.

V² — AI machine vision defect inspection

The hardest cases in vision inspection are the defects that are difficult to define as defects at all. A small change in lighting or angle and a rule-based camera either misses them or rejects good parts.

The V² module collects and analyzes imagery and process data from the shop floor in real time, detecting fine defects such as scratches and contamination automatically through deep learning.

Quality prediction and process optimization — XGBoost and genetic algorithms predict quality and derive optimal process conditions automatically.

Anomaly detection — Models trained on images of normal parts detect subtle anomalies, which is particularly useful where defect samples are scarce.

Multimodal sensor data is fused to predict quality quantitatively, and lightweight models on edge devices allow high-speed inspection and optimal condition derivation without interrupting the process.

MLOps — model operations and automatic retraining

Building a model and running one are different jobs. Environments, directory structures and coding styles differ between developers, so reproducing a result is hard; source, model files and runtime environments end up scattered across personal machines and assorted repositories, so handover stalls when staff change. Having someone decide by hand whether retraining is due and whether a model is fit to deploy adds to the load.

The MLOps module covers that stretch.

Reproducibility — Model files, code, data, runtime environment and workflow are versioned together per commit. Recall the same conditions and you get the same model.

Development environments — Specify CPU, memory and storage in the browser to spin up a container environment immediately, then connect through a web terminal. Standard directory structures and code templates come with it.

Automatic retraining — When data drift is detected, retraining runs against the data lake API. Alert, retrain and validate form a closed loop.

Five gates — Data quality, drift resolution, performance, overfitting and reproducibility are adjudicated automatically, and a model that falls short is blocked from deployment outright. The point is to make it structurally impossible for an unverified model to reach the floor.

Federated learning — For organizations with several sites where the data cannot be centralized. Each site trains on its local data and sends only the resulting model to the host, which aggregates them round by round into a shared model. The data itself never leaves the site.

Pair it with B²LAB to keep the path from data collection through training and operation unbroken.

Path to production

1. Registration — Code is written in a container environment and self-checked with a validation command covering data, preprocessing and training results, then code, training data and runtime environment are registered as a commit to create a version. A version tag puts it in the registry, which later retraining refers back to.
2. Drift detection — Statistical methods such as PSI, the KS test and JS divergence check periodically for distribution shift in inputs and predictions, alongside accuracy trend as a measure of performance decay.
3. Retraining and deployment — Crossing the threshold raises an alert and triggers retraining automatically. The latest training data is pulled through the B²LAB API, the model is retrained, the five gates are adjudicated, and a model that passes all of them is promoted to serving once the responsible developer confirms it. Nothing ships unattended.
4. Federated learning operations — A project and its participating sites are registered with either an immediate or a recurring retraining trigger, and the models each site trains are aggregated round by round.

Adoption requirements

Deployment and resources — A dedicated customer cloud (VPC) or on-premise, with air-gapped sites served on-premise. Container development environments are allocated by CPU, memory and storage; GPUs are not allocated by default and are agreed separately where needed. A network path to the data lake (B²LAB) and the drift detection system is required.

Data readiness — Model code, training datasets and runtime configuration need to follow the standard directory structure (data / src / models / configs / outputs). For retraining and drift detection, training data and current operational data must be queryable through the B²LAB API; without that, automatic retraining will not work properly. Federated learning additionally requires local training data with the same schema at each site.

Integration — The B²LAB API connection is mandatory, for training dataset queries and drift monitoring data. A REST API connection to the model serving system carries out deployment and rollback and exposes model metadata. Federated learning needs a communication path between the host and the site nodes. Authentication defaults to single sign-on through the data lake platform.

Permissions — Split between model developers (development environment and commits), MLOps operators (retraining and deployment approval) and platform administrators (federated learning projects and site configuration). Even a model that clears all five gates needs the responsible developer’s final approval before promotion to serving. Deployment history and the reason for each retraining are kept in the audit log.

Current status

The MLOps module is built and awaiting formal performance certification. It was delivered as 50 development items at roughly 339 man-days.

Indicators such as the number of blocked deployments, model development-to-deployment lead time and retrain-to-deploy automation rate are tracked as performance measures, but no figures are published before certification. They will appear here once the assessment is complete.

Explainable AI (XAI)

A²LAB applies explainable AI (XAI). Users can follow the reasoning behind any action the system proposes.

A system that only hands over results rarely earns trust on the floor. Operators and managers need the reasoning alongside it before they will act on the recommendation.

Certification

A²LAB BI holds GS Certification Grade 1.