How to Convert Neural Network Weights to PLC Structured Text for Anomaly Detection

Converting neural network weights to PLC Structured Text means exporting a trained model’s weights and biases, rewriting them as IEC 61131-3 arrays, and executing the feedforward math deterministically inside the PLC scan. The engineering objective is not “AI in controls” as a slogan, but bounded, testable inference without edge-network dependency.

Neural networks do not become industrially useful merely because they classify data well in Python. They become useful when their execution path is predictable enough for a control system that lives and dies by scan time, watchdog limits, and failure behavior.

For high-speed anomaly detection, sending process data to an external edge PC can introduce latency, jitter, and another failure point between signal and action. That architecture can be acceptable for advisory analytics. It is less suitable when the model output is tied to a permissive, trip, or interlock. OT has little patience for elegant architectures that fail inelegantly.

A bounded alternative is to export a lightweight trained model—typically a shallow multilayer perceptron—into IEC 61131-3 Structured Text and run the inference directly in the controller.

Ampergon Vallis Metric: In an internal OLLA Lab simulation, a 3-layer MLP using a 16x16 floating-point hidden-layer matrix added 1.2 ms to simulated scan execution during repeated inference tests. Methodology: n=25 simulation runs of the same feedforward task, baseline comparator = identical logic state without matrix execution, time window = one March 2026 validation session. This supports the claim that small neural inference blocks can be tested for deterministic feasibility in a PLC-style environment. It does not prove suitability for every controller, every scan budget, or any safety function.

Running inference inside the PLC removes network transport from the critical execution path. That is the central engineering reason.

An edge PC can be adequate for non-critical monitoring, historian-side analytics, or maintenance dashboards. It is a different proposition when the model output must participate in a deterministic control decision. If the network link drops, the inference path drops with it. The problem is not that edge computing is wrong; the problem is that control logic is less forgiving than analytics architecture.

The distinction is simple:

• Edge inference is typically asynchronous, network-dependent, and scheduled outside the PLC scan.
• PLC-resident inference is deterministic only if execution time, memory use, and fault behavior are bounded inside the controller task.

For anomaly detection tied to a motor permissive, valve inhibit, or sequence hold, deterministic locality matters. A result that arrives late is often functionally equivalent to no result at all.

What standards context matters here?

Functional safety standards do not endorse casual timing assumptions. IEC 61508 is concerned with predictable behavior, validated execution, and known failure response, not with whether a model looked impressive in a notebook.

That requires a careful boundary:

• Embedding a neural network in Structured Text does not make it a safety function by default.
• It can support deterministic process monitoring logic if its execution is validated, bounded, and segregated appropriately.
• If the output influences safety-related action, the burden of verification rises sharply. “It worked in simulation” is not a safety case.

A popular misconception is that putting AI inside the PLC automatically makes it more industrial. It only makes it closer to the scan cycle. The hard part is still proof.

Only small, feedforward models are practical in most PLC contexts. That is the useful boundary.

The most common candidate is a shallow multi-layer perceptron (MLP) trained offline in MATLAB, Python, or a similar environment, then exported as static weights and biases. This works because inference for a fixed MLP is just arithmetic:

• matrix multiplication
• bias addition
• activation function evaluation
• thresholding or classification logic

That arithmetic is tedious but deterministic.

The models most likely to fit are:

• Single hidden-layer or shallow MLPs
• Small input vectors
• Limited hidden node counts
• Simple activation functions, such as ReLU or bounded linear approximations

The models least likely to fit cleanly are:

• recurrent networks
• large convolutional models
• transformer architectures
• anything requiring dynamic memory behavior, unsupported libraries, or substantial floating-point throughput

This is not a statement about AI capability in general. It is a statement about controller economics and scan discipline.

The conversion process is straightforward in concept and unforgiving in detail. Most failures are not mathematical. They are indexing, scaling, datatype, or task-time failures.

### Step 1: Train a lightweight model offline

Train the model in MATLAB, Python, or another ML environment using historical process data or labeled event data.

Good candidates for PLC deployment usually have:

• normalized numeric inputs
• limited feature count
• stable operating envelopes
• clear anomaly labels or threshold logic
• an inference path that can be explained and bounded

If the model needs a desktop GPU to run comfortably, it usually does not belong in a standard controller task.

### Step 2: Export weights and biases

Extract the trained parameters from the model:

• input-to-hidden weight matrix
• hidden-layer bias vector
• hidden-to-output weight matrix
• output-layer bias vector

Typical export formats include:

• CSV
• JSON
• MATLAB arrays
• Python NumPy arrays written to text

At this stage, preserve:

• array dimensions
• row/column ordering
• numeric precision
• input normalization constants
• output threshold values

A surprising number of deployment issues are really just transposed matrices.

### Step 3: Convert the parameters into IEC 61131-3 compliant arrays

Rewrite the model parameters as Structured Text arrays using controller-supported datatypes, typically `REAL` or `LREAL` depending on platform capability and scan budget.

Example shape mapping:

• `W1[HiddenNodes, InputNodes]`
• `B1[HiddenNodes]`
• `W2[OutputNodes, HiddenNodes]`
• `B2[OutputNodes]`

Also define:

• input vector arrays
• intermediate node-sum arrays
• activation output arrays
• final inference output arrays

Datatype choice matters. `LREAL` may improve numerical fidelity, but it can also increase execution cost depending on controller architecture.

### Step 4: Recreate the feedforward pass in Structured Text

Implement the model as explicit arithmetic:

1. initialize each node sum with its bias
2. accumulate weighted input products
3. apply the activation function
4. pass the activated outputs to the next layer
5. compare final output to a threshold or classification rule

This is where the model becomes a deterministic arithmetic block.

### Step 5: Recreate preprocessing and output logic

A model trained on normalized inputs must receive normalized inputs in the PLC. Otherwise, the inference is mathematically correct and operationally wrong.

You must implement:

• scaling
• offset correction
• clamping if required
• missing-signal handling
• output thresholding
• fault-state behavior if the inference block receives invalid data

A model without its preprocessing path is not deployed. It is merely copied.

Matrix multiplication in Structured Text is usually implemented with nested `FOR` loops and explicit accumulation into node-sum arrays. The objective is correctness, determinism, and scan-time visibility.

Example: hidden-layer weighted sum

Language: Structured Text

// Hidden layer weighted sum FOR i := 0 TO HiddenNodes - 1 DO NodeSum[i] := Bias1[i]; FOR j := 0 TO InputNodes - 1 DO NodeSum[i] := NodeSum[i] + (InputArray[j] * Weight1[i, j]); END_FOR; END_FOR;

This code performs the dot product between the input vector and each hidden-layer neuron’s weight row, then adds the corresponding bias.

Implementation checks that matter:

• confirm whether your PLC uses zero-based or one-based array conventions
• keep array dimensions explicit
• initialize sums before accumulation
• avoid hidden type conversion
• test worst-case execution time, not just nominal execution time

A loop that works once is a demo. A loop that works at task rate under noisy inputs is engineering.

How do you calculate the output layer?

The output layer is the same pattern applied to the hidden-layer activations.

Language: Structured Text

// Output layer weighted sum FOR i := 0 TO OutputNodes - 1 DO OutputSum[i] := Bias2[i]; FOR j := 0 TO HiddenNodes - 1 DO OutputSum[i] := OutputSum[i] + (HiddenOutput[j] * Weight2[i, j]); END_FOR; END_FOR;

For a single anomaly score, `OutputNodes` may be `1`, with the final score compared against a threshold.

ReLU is one of the easier activation functions to translate because it is piecewise linear. In Structured Text, it becomes a simple conditional.

Language: Structured Text

// ReLU activation FOR i := 0 TO HiddenNodes - 1 DO IF NodeSum[i] < 0.0 THEN HiddenOutput[i] := 0.0; ELSE HiddenOutput[i] := NodeSum[i]; END_IF; END_FOR;

This preserves the basic ReLU rule:

• if input < 0, output = 0
• else output = input

That simplicity is useful in PLCs because it avoids more expensive nonlinear functions.

What other activation approaches are practical?

Practical options depend on controller capability, but common approaches include:

- ReLU: simplest for direct implementation - Linear activation: useful for regression-style outputs - Piecewise approximation: sometimes used when a smooth nonlinear function is needed but native math support is limited

Less practical options in many PLCs include:

• exact sigmoid or tanh calculations using expensive exponentials
• dynamic activation schemes requiring unsupported libraries
• architectures that depend on runtime graph behavior

In control work, bounded behavior often beats elegant but untestable behavior.

Anomaly detection becomes operationally meaningful only when the output is tied to a defined control action. “The model produced 0.83” is not yet an engineering result.

A usable implementation needs:

• a defined anomaly score
• a threshold or classification rule
• a debounce or persistence rule if noise is expected
• a clear control response

For example:

- set `AnomalyDetected := TRUE` - drop `MotorRunPermissive := FALSE`

• if anomaly score > threshold for 500 ms
• latch an alarm
• require operator or supervisory reset depending on philosophy

That logic must be documented in control terms, not ML terms.

Operational definition of anomaly detection

In this article, anomaly detection means:

> reading a bounded set of process inputs, executing a deterministic feedforward inference block inside the PLC task, comparing the resulting score to a defined threshold, and changing a control-state variable such as a permissive, alarm, or sequence hold when the threshold condition is met.

That definition is intentionally narrow. It is observable, testable, and suitable for validation.

The principal risks are scan overrun, numerical mismatch, and false confidence.

1. Scan-time and watchdog risk

Matrix arithmetic consumes task time. If the inference block is too large or poorly structured, it can trigger watchdog faults or degrade control responsiveness.

Risk factors include:

• large matrices
• frequent execution in fast tasks
• heavy floating-point use
• repeated normalization and scaling inside the same cycle
• unnecessary recomputation

Mitigations include:

• reducing model size
• moving inference to a slower periodic task where appropriate
• precomputing constants
• using bounded execution tests
• validating worst-case scan impact before deployment

2. Datatype and precision mismatch

A model trained in `float64` and deployed in `REAL` may behave differently at thresholds. That difference may be small numerically and large operationally.

Check:

• numeric range
• scaling consistency
• threshold sensitivity
• controller-specific floating-point behavior

3. Indexing and matrix orientation errors

A transposed matrix, shifted index, or wrong bias mapping can produce outputs that look plausible while being completely wrong.

This is why deterministic validation matters. Arithmetic errors are often polite enough to compile.

4. Invalid-input behavior

A missing sensor, stale value, saturated transmitter, or bad analog scaling can corrupt inference.

Define:

• what happens on bad quality
• whether the block inhibits itself
• whether the output fails safe, fails neutral, or alarms only
• whether the result is ignored during maintenance or startup states

5. Misuse in safety contexts

A neural inference block should not be described as safety-rated merely because it is inside a PLC. If it influences a safety-related function, the design, verification, and lifecycle obligations become substantially more demanding.

OLLA Lab is useful here as a bounded validation environment for high-risk commissioning tasks. It is not a shortcut around controller testing, and it is not a substitute for site acceptance. It is where you rehearse the failure modes before hardware and process time become expensive.

In this use case, OLLA Lab can support engineers by providing:

• a browser-based logic environment for building and reviewing control logic
• simulation mode for running, stopping, and observing behavior without physical hardware
• variable and I/O visibility for tracing intermediate values
• realistic scenario-based testing against simulated equipment behavior
• digital twin-style validation workflows where logic can be compared against expected machine response

For this article’s workflow, the practical value is clear:

• write the inference logic
• bind inputs to simulated process variables
• inject disturbances or abnormal conditions
• observe output state changes
• check whether the control response matches the intended philosophy

That is what Simulation-Ready should mean in operational terms: an engineer who can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

What does digital twin validation mean here?

In this bounded context, digital twin validation means testing control logic against a realistic simulated equipment model so that the engineer can compare:

• ladder or Structured Text state
• I/O state
• process response
• abnormal condition handling
• resulting control action

It does not mean the simulated model is automatically a perfect replica of site behavior. It means the logic can be rehearsed against representative machine or process dynamics before field deployment.

A practical workflow is to treat the neural network as one block inside a larger control narrative rather than as a novelty object.

A representative validation sequence would be:

1. Build the inference block Implement the exported weights, biases, normalization, and threshold logic in Structured Text or an equivalent supported control logic workflow.
2. Bind the inputs to simulated process signals Map the model inputs to variables such as vibration, motor current, temperature rise, pressure fluctuation, or flow instability.
3. Define the expected normal state Confirm the model output remains below threshold during healthy operation.
4. Inject an abnormal condition Introduce a disturbance such as oscillatory vibration, sensor spike, drift, or unstable load behavior.
5. Observe the inference output and control response Verify that the anomaly score crosses threshold only when intended, and that the permissive, alarm, or sequence state changes correctly.
6. Measure the logic burden Review whether the added arithmetic creates unacceptable execution cost or unstable behavior.

That sequence matters because anomaly detection is only useful when tied to process consequence. A score without an action path is just a number.

A screenshot gallery is weak evidence. A compact validation record is more useful to reviewers, instructors, and employers because it shows reasoning, not just interface familiarity.

Use this structure:

1. System Description Describe the equipment, process objective, relevant inputs, and where the anomaly detection block sits in the control philosophy.
2. Operational definition of correct behavior State exactly what the logic must do under normal and abnormal conditions, including thresholds, timing, and expected output states.
3. Logic and simulated equipment state Show the implemented logic and the corresponding simulated machine or process behavior during the test.
4. The injected fault case Document the disturbance introduced, such as sensor noise, drift, oscillation, or abnormal load.
5. The revision made Record what changed after the first test—threshold adjustment, debounce logic, scaling correction, task placement, or matrix optimization.
6. Lessons learned Summarize what the test revealed about deployability, false positives, scan burden, or control philosophy.

That body of evidence is much closer to commissioning judgment than a polished screenshot.

Deployment should be gated by bounded verification, not enthusiasm.

Use a pre-deployment checklist:

• Model size is appropriate for the controller and task rate
• Input scaling matches training conditions
• Weights and biases are mapped correctly
• Activation logic is implemented exactly as intended
• Threshold behavior is documented
• Bad-input handling is defined
• Worst-case execution time is tested
• Control response to anomaly is verified
• Fallback behavior is defined if the inference block is invalid
• Site-specific commissioning tests are planned

If the model cannot survive this checklist, it is not ready for the PLC. It may still be useful elsewhere.

This approach solves a specific OT problem: how to execute a small trained model deterministically inside a PLC-style control environment without relying on external inference infrastructure.

It can help with:

• low-latency anomaly scoring
• bounded local inference
• reduction of network dependency in control decisions
• validation of model arithmetic against realistic process behavior

It does not solve:

• safety certification by implication
• model governance by itself
• plant-specific commissioning by simulation alone
• suitability of large or complex neural architectures for standard PLC hardware

That boundary is worth keeping clean.

Converting neural network weights to PLC Structured Text is technically viable when the model is small, the arithmetic path is explicit, and the execution burden is validated against controller constraints. The point is not to make PLCs imitate Python environments. The point is to place a bounded inference function where deterministic response matters most.

The engineering sequence is clear:

• train offline
• export weights and biases
• rewrite them as IEC 61131-3 arrays
• implement feedforward math and activation logic
• validate scan impact and fault behavior
• test the control consequence against realistic simulated process conditions

This is where OLLA Lab becomes operationally useful. It provides a place to rehearse matrix-heavy logic, observe I/O and variable behavior, inject abnormal conditions, and harden the design before live commissioning. That is a credible use of simulation: not replacing field proof, but making field proof less reckless.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety overview - NIST AI Risk Management Framework (AI RMF 1.0) - Digital twin review (IFAC-PapersOnLine) - Industrial AI in Industry 4.0 (Manufacturing Letters)