Artificial intelligence and machine learning (AI/ML) can support local analysis of engineering test data that cannot be sent to a cloud service. For aerospace and defence teams, oon-premisesAI/ML for test data raises practical questions: what can a model infer from existing measurements, what remains unseen, and how should its output be checked before it informs an engineering decision.
Run models on local servers, inside isolated or air-gapped networks, or on suitable test hardware. AI/ML can flag departures from learned behaviour, support condition monitoring, rank runs for review, and explore what-if cases with validated surrogate models. It cannot recover absent measurements, identify failure modes not represented in its data, or replace engineering judgement, test procedure , or certification evidence. Begin with one rig, a clear engineering question, a baseline, representative validation data, and a controlled update plan.
Where does on-premises AI/ML for test data actually run?
On-premises means the system processes and stores model data on infrastructure managed at the facility; it does not define every external connection.
On-premises analysis can run on a local server or workstation, inside an isolated or air-gapped network, or directly on test hardware through deployment. The right location depends on available compute, required response time, data paths, and how software and models can be moved and maintained.
For dedicated edge execution, analysis can run directly on air-gapped test hardware, such as an isolated programmable automation controller (PAC) or local edge industrial PC. Operating without external network access, these self-contained devices ingest high-speed sensor streams and run trained models locally to deliver real-time feedback and deterministic control actions without compromising security protocols.
An air-gapped environment is isolated from external networks; edge deployment places inference close to instruments, rigs, or controllers. A server centralises model management but must receive measurements. A controller analyses close to the test but has processor, memory, interface, and timing limits. Each location needs a defined model validation and update path.
What can on-premiseAI/ML do with test data?
On-premise AI/ML can flag anomalies across many channels, track equipment condition, build fast surrogate models of test rigs, stand in for components in hardware-in-the-loop (HIL) simulation, and rank large test campaigns for review.
Anomaly detection flags measurements that depart from learned or defined normal behaviour. Unsupervised learning uses data without fault labels; an autoencoder can learn healthy behaviour and flag differences. A helicopter engine autoencoder study explores this where failure labels are scarce. A flight data study highlights false positives, while a broad time series evaluation found no detector best across every dataset. Teams can build and validate such models without writing code in OpenMathAI, a no-code visual platform that keeps engineering data local and is part of VTEST’s on-premises AI/ML solutions.
Many blueprints exist in OpenMathAI for various applications and industries
Condition monitoring and predictive maintenance track patterns that may indicate changing equipment health. A Health and Usage Monitoring System (HUMS) combines sensor information with operating context. A NASA rotorcraft trial report described monitoring rotor, engine, drivetrain, and life-limited components, with one example involving a worn tail rotor pitch bearing. A Federal Aviation Administration (FAA) usage monitoring report identifies missing or inaccurate data and incorrect algorithms as error sources. Compare outputs with maintenance records and operating context before decisions.
Surrogate models and digital twins can support what-if studies. A surrogate model approximates a physical system or detailed simulation so engineers can evaluate cases more quickly. A review of surrogate models in aircraft analysis describes real-time and repeated aerodynamic studies.
HIL simulation connects real control hardware to simulated or emulated plant behaviour in a real-time loop. NASA’s HIL tutorial distinguishes simulated surrogates from real-time controller interaction with surrogate hardware. VTEST supplies PAC systems that can host these models; see our HIL and rapid control solutions.
A surrogate model built in OpenMath AI can be exported as an FMU (Functional Mock-Up Unit or Functional Mock-up Interface), and TwinSimulate then handles the step from model to controller: engineers assemble the model as a block diagram, generate code from it, and schedule it to run in real time, with traceability kept between the generated code and the diagram.
Reviewing large test campaigns is another possible task. A model can rank runs, channels, or time windows for human review. The FAA AI safety assurance roadmap notes unsupervised data mining as a possible aid to identifying failure precursors in test cases.
In automated test equipment (ATE), an anomaly score can help prioritise runs for engineering review alongside established pass or fail criteria. VTEST offers anomaly detection for ATE; see automated test equipment setups.
What can on-premise AI/ML not do?
AI/ML cannot make an incomplete record complete or reliably predict what it has never seen. Its output is useful only for a defined question, within the data and deployment conditions used to validate it.
A deviation is not necessarily a fault. A new operating state, a configuration change, a sensor artefact, or a genuine fault may all differ from a learned baseline. Engineers need a way to triage alerts and compare them with known events.
A model cannot repair missing measurement context. Unsynchronised channels, unknown units, incomplete calibration records, inconsistent channel names, clipping, or unrecorded test states limit what the model can infer.
A model does not cover every failure mode. If the training data omit a fault or operating region, the model has no basis for a reliable prediction there. Predictions beyond tested conditions should be treated as unknown, not as proof that a system is safe.
A disconnected site still needs controlled updates. Models, software libraries, and security patches do not update automatically. The NIST configuration management guide describes reviewing, testing, approving, and recording system changes. A joint government guide for operational technology discusses verified and authorised use of removable media in isolated environments.
A target controller has finite resources. Processor load, memory, operating system, interfaces, and timing budgets restrict which models can run. An ONNX or FMU export, or a server result, does not prove that the model is compatible with a particular controller or HIL configuration.
An equation discovery result is a candidate model, not proof of physical law; its interpretation depends on the selected terms, measured states, and whether the data excite the relevant behaviour. An opaque score is not a complete justification, and a team still needs to explain model scope, evidence, and the action path.
How should a test team start with on-premises AI/ML?
Start with one narrow question on one rig and define the decision the output should support before selecting a model. A measured baseline lets the team judge whether the model adds useful evidence.
Choose a question with a clear engineering consequence, such as which runs should receive a second review.
Agree on a baseline, such as existing threshold alarms or current manual review, and define the records against which a model will be compared.
Audit the data using the readiness checklist. Set aside representative runs for validation rather than testing only on records used to fit the model.
Select the execution location and check the actual processor, memory, interfaces, network path, and timing budget.
Define acceptance measures before deployment, including missed events, false alerts, interval behaviour, or another measure tied to the decision.
Document model versions, data transformations, approvals, update transfer, review, and rollback steps for the facility’s operating environment.
Review results with the engineers and operators who will use them, then decide whether the model should remain advisory or enter a controlled test process.
Teams considering a first use case can discuss their test requirements with VTEST.
FAQ: on-premises AI/ML for test data questions answered
Can anomaly detection work without labelled failure data?
Yes. An unsupervised model can learn a baseline from data considered normal and flag departures without labelled fault examples. It still needs records that represent the intended operating conditions.
What does conformal prediction tell me about an engineering result?
Conformal prediction adds a calibrated interval around a model’s prediction, so engineers see a range rather than a single number. The interval is calibrated on separate data and holds on average when future conditions resemble that data. It is most useful as a way to flag results that need closer review.
Can a machine learning model run on a real-time test controller?
Yes, when the model fits the controller’s processor, memory, interfaces, and timing budget. Models can be exported in formats such as ONNX or FMU for embedded and real-time hardware, but each model should be tested on its intended controller before use.
How are AI/ML models updated in an air-gapped test facility?
A disconnected facility needs a defined transfer and approval process for model files, dependencies, and security updates. The process can include integrity checks, authorised media, testing before release, change records, and a rollback route. The precise controls depend on the facility’s safety, security, and contractual requirements.
Does AI/ML replace threshold alarms in test monitoring?
No. Threshold alarms remain useful for explicit limits, while a model may identify patterns that a fixed threshold does not represent. Compare model alerts with existing alarms and engineering review before changing a test decision path.
What does ONNX and FMI / FMU mean?
Open Neural Network Exchange (ONNX) is an open format for exchanging model computation graphs; its ONNX intermediate representation specification requires implementations to support declared operators or reject the model. The FMI 3.0 standard defines the Functional Mock-up Interface (FMI), which standardises exchange of dynamic models packaged as Functional Mock-up Units (FMUs).