How to Simulate EMI and Filter Analog Noise in PLC Logic Using OLLA Lab

Electromagnetic interference in industrial control systems cannot be solved by hardware practices alone. Engineers must also validate software filtering, alarm debounce, and control stability against noisy analog inputs. OLLA Lab provides a bounded simulation environment where users can inject noise into analog tags and verify that PLC logic remains stable before live commissioning.

EMI is not a rare edge case in industrial automation. It is a normal condition of electrically busy plants, especially where VFDs, switching loads, mixed-voltage cable routing, and imperfect grounding coexist.

The practical mistake is to treat analog noise as an electrical problem only. Physical mitigation is the first line of defense, but the PLC still receives the final corrupted value at the terminal, and that value still drives alarms, HMIs, and PID blocks. Software has to finish the job.

Ampergon Vallis Metric: During baseline testing in OLLA Lab, injecting a continuous ±2% high-frequency noise waveform into an unfiltered process variable caused a standard PID output to fluctuate by up to 14.8% under otherwise steady-state conditions. Methodology: n=12 simulation runs on a stable analog level-control task, baseline comparator = same logic with no injected noise, time window = 10-minute observation period per run. This internal benchmark supports one narrow point: modest analog noise can produce visible actuator chatter in unfiltered control logic. It does not establish a universal field rate, device-specific failure threshold, or standard performance limit.

Operationally, simulation-ready means an engineer can prove, observe, diagnose, and harden control logic against realistic signal behavior before it reaches a live process. Syntax is useful. Deployability is the test.

EMI in PLC analog signals is caused by unwanted electrical energy coupling into the measurement path and distorting the value seen by the input module. In practice, that distortion often appears as rapid spikes, oscillation, or unstable drift superimposed on a legitimate signal.

Common industrial sources include:

- Variable Frequency Drives (VFDs): High-frequency switching generates conducted and radiated noise. - Improper cable routing: Analog pairs run near 480 VAC feeders, motor leads, or contactor bundles invite coupling. - Ground loops: Multiple ground reference paths create circulating currents and measurement instability. - Relay and contactor switching: Inductive collapse produces transient spikes. - Unshielded or poorly terminated signal cabling: Shielding only works when applied correctly. - Panel layout issues: Tight bundling of low-level analog conductors with high-energy circuits increases susceptibility.

A 4–20 mA loop is inherently more noise-resistant than many voltage signals, which is one reason industry still relies on it heavily. But “more resistant” is not the same as “immune.” Once the analog input card converts the disturbed current into a digital value, the PLC logic has no memory of where the noise came from. It only sees a number that moves when it should not.

ISA guidance on signal quality and industrial measurement practice consistently supports the same hierarchy: start with sound wiring, grounding, shielding, and segregation, then apply software treatment for residual noise where required. That sequence matters. Filtering is not a substitute for bad installation.

EMI degrades trust before it causes a trip. Operators usually see the problem first as a flickering process variable, a nuisance alarm, or a valve that refuses to sit still.

The main effects are straightforward:

- HMI flicker: The displayed PV jumps rapidly enough to look unstable even when the process is physically steady. - False alarm activation: Short-duration spikes can cross alarm thresholds and trigger nuisance events. - Alarm chatter: Repeated threshold crossings create alarm floods or unstable alarm states. - Actuator hunting: Noisy PVs drive unnecessary output movement, especially in tightly tuned loops. - Misleading trends: Historical data becomes harder to interpret because noise masks actual process behavior. - Reduced operator confidence: Once the screen lies often enough, operators stop trusting it.

The HMI consequence is often underestimated. HMI interference is the visual manifestation of EMI: a displayed value flickers rapidly enough to obscure real process deviation and erode operator confidence. If the PV looks unstable all day, a real deviation arrives with less credibility than it deserves.

Unfiltered noise is especially dangerous when it reaches:

• High-High or Low-Low alarms with no time qualification
• PID derivative action, which amplifies high-frequency variation
• Valve or VFD output logic with low deadband
• Batch or sequence permissives that depend on stable analog thresholds

This is why defensive programming around analog signals is not optional in serious commissioning work. A clean rung on a clean screen proves very little.

You can use OLLA Lab to inject a controlled noise waveform into an analog tag and then validate whether your PLC logic remains stable under disturbance. That is the operational meaning of simulation-ready practice in this context: deliberately degrade signal quality in a safe environment, then prove the logic can tolerate it.

Within the product’s bounded role, OLLA Lab is useful here because it combines ladder logic, simulation, variable visibility, and digital twin-style behavior in one environment. It does not replace field commissioning, but it gives engineers a place to rehearse one of its more expensive lessons.

Step-by-step method

3. Open the Variables Panel and identify: 7. Observe the raw value versus the process behavior: 9. Repeat the same disturbance and compare:

• the raw analog input tag,
• the filtered tag if one exists,
• the alarm threshold tags,
• the PID PV and output tags if a loop is present.
• Does the displayed PV flicker?
• Does the alarm chatter?
• Does the output oscillate?
• raw tag,
• filtered tag,
• alarm state,
• output stability,
• simulated equipment response.

1. Create or open a project with an analog process variable such as tank level, pressure, flow, or temperature.
2. Bind the analog tag to a simulated process element in the scenario.
3. Run the simulation with a clean baseline signal first.
4. Enable the Signal Generator or equivalent analog stimulus control in the scenario tools.
5. Inject a high-frequency noise waveform onto the raw analog tag.
6. Add a software filter in the PLC logic.
7. Tune the filter until the signal is stable enough for control use without introducing unacceptable lag.

That workflow matters because it forces comparison, not assumption. A filter that removes noise but delays a fast process too much is not a win. It is just a quieter mistake.

What to capture as engineering evidence

If you want to demonstrate competence, build a compact body of evidence rather than a folder of screenshots. Use this structure:

State what acceptable behavior means in measurable terms: stable PV, no nuisance alarm, no output chatter, acceptable response time.

1. System Description Define the process, the analog signal type, the control objective, and the simulated equipment involved.
2. Operational definition of “correct”
3. Ladder logic and simulated equipment state Show the relevant ladder or math logic and the corresponding equipment behavior in simulation.
4. The injected fault case Document the noise waveform, amplitude, frequency character, and where it was applied.
5. The revision made Specify the filter, debounce, deadband, or tuning change implemented.
6. Lessons learned Explain what improved, what tradeoff appeared, and what still requires field verification.

That is the difference between evidence and decoration.

Image alt text: Screenshot of the OLLA Lab Variables Panel showing a signal generator injecting a high-frequency noise waveform into a raw tank level analog tag while the built-in trend view compares raw and filtered values.

The best software filter depends on process speed, memory constraints, alarm criticality, and how much lag the control strategy can tolerate. There is no universal best filter. There is only the least damaging tradeoff for the task.

Three techniques are common, defensible, and practical in PLC environments.

The Moving Average Filter (FIFO)

A moving average filter smooths noise by averaging the most recent N samples. It is simple, effective, and often the first tool used on slow analog variables.

Definition: The filtered value is the arithmetic mean of the last N input samples.

Best for:

• Tank level
• Slow temperature loops
• Utility measurements with low rate-of-change
• HMI stabilization where some lag is acceptable

Strengths:

• Easy to understand and validate
• Good attenuation of random high-frequency noise
• Useful for trend readability and alarm stability

Limitations:

• Introduces lag proportional to window size
• Requires storage for sample history
• Can blunt legitimate fast process changes

If you average too aggressively, the signal becomes calm and wrong.

The First-Order Lag Filter (Low-Pass)

A first-order lag filter attenuates rapid changes while retaining a compact implementation. In PLC work, it is often preferable when you need smoothing without maintaining a full sample array.

Definition: A first-order lag filter computes each new filtered value from the current raw input and the previous filtered value:

Y_n = αX_n + (1-α)Y_{n-1}

Where:

• X_n = current raw input
• Y_n = current filtered output
• Y_{n-1} = previous filtered output
• α = smoothing factor between 0 and 1

Best for:

• General analog conditioning
• Faster loops where a long moving average is too slow
• PLCs where memory economy matters
• Preconditioning PVs before alarm or PID evaluation

Strengths:

• Lightweight implementation
• Tunable smoothing behavior
• Common and mathematically transparent

Limitations:

• Still introduces lag
• Poor parameter selection can either under-filter or over-dampen
• Must be validated against actual process dynamics

This is often the most practical default in control logic because it is compact, stable, and easy to tune in simulation before field deployment.

The Alarm Debouncing Method (TON)

Alarm debounce is not a noise filter in the signal-processing sense, but it is an essential protective layer against nuisance trips. It qualifies the duration of an abnormal condition before declaring it real.

Definition: The alarm condition must remain true continuously for a preset time before the alarm bit is allowed to energize.

Best for:

• High/Low analog alarms
• Discrete fault confirmation
• Threshold crossings vulnerable to short spikes
• Preventing nuisance alarms from transient EMI

Strengths:

• Very effective against brief interference spikes
• Easy to explain to operators and maintainers
• Minimal computational complexity

Limitations:

• Does not clean the underlying signal
• Can delay legitimate alarm annunciation
• Must be chosen carefully for safety and process risk

For many systems, the correct answer is not one technique but a stack:

• moderate analog filtering,
• sensible deadband,
• and time-qualified alarming.

That combination is usually more robust than trying to solve everything with one oversized filter.

A first-order lag filter can be implemented in Structured Text or with equivalent math instructions in ladder logic. The objective is simple: produce a filtered analog value that is stable enough for alarming and control but responsive enough for the process.

Structured Text example

First-Order Lag Filter

RawPV = noisy analog input FiltPV = filtered analog value Alpha = smoothing factor, 0.0 to 1.0

IF FirstScan THEN FiltPV := RawPV; END_IF;

FiltPV := (Alpha RawPV) + ((1.0 - Alpha) FiltPV);

Practical implementation notes

• Initialize the filtered value on first scan to avoid a startup bump.
• Choose alpha conservatively.
• Lower alpha = more smoothing, more lag
• Higher alpha = less smoothing, faster response
• Trend raw and filtered values together during testing.
• Verify alarm timing after filtering. A stable signal can still trip too quickly if the threshold logic is naive.
• Validate PID behavior with the filtered PV, especially if derivative action is enabled.

Under IEC 61131-3, these math operations are ordinary controller functions. The standard gives you the language structure; it does not save you from poor tuning.

You should validate analog robustness by proving that the logic behaves acceptably under both clean and disturbed conditions. A single successful clean run is not validation. It is a rehearsal with the hard parts removed.

A practical validation sequence looks like this:

• Baseline the clean process
• Confirm normal PV behavior
• Record alarm state and output stability
• Inject controlled noise
• Apply repeatable disturbance to the raw analog tag
• Observe HMI, alarms, and control output
• Implement filtering and debounce
• Add one change at a time where possible
• Retest under identical disturbance
• Compare raw versus filtered response
• Check whether nuisance alarms disappear
• Confirm output movement is reduced
• Check process responsiveness
• Ensure the filter does not mask real deviations
• Document the acceptance criteria
• Maximum allowable PV fluctuation
• Maximum output chatter
• Alarm persistence requirements
• Acceptable response lag

If a digital twin or realistic machine model is available, compare the ladder state to the simulated equipment state during disturbance. That comparison is where OLLA Lab becomes operationally useful. It lets you test not only whether the math works, but whether the machine behavior still makes sense when the signal degrades.

That is the distinction worth keeping: draft logic versus validated behavior.

This approach is consistent with established control and automation practice, though standards do not prescribe one universal filter for every analog problem.

Relevant anchors include:

• IEC 61131-3 for PLC programming languages and implementation structure
• ISA guidance and recommended practice on instrumentation, signal integrity, alarm behavior, and control performance
• IEC 61508 for the broader principle that systematic behavior in control systems must be justified, verified, and bounded by risk context
• exida publications and functional safety guidance for the importance of nuisance trip reduction, signal treatment discipline, and validation in safety-adjacent logic
• Process control literature on low-pass filtering, derivative sensitivity, and noise attenuation in feedback systems

A necessary qualification: software filtering inside a standard PLC program is not, by itself, a functional safety claim. It may improve robustness and reduce nuisance behavior, but safety functions require their own architecture, verification, and compliance framework.

EMI in analog PLC signals is a physical certainty, not a theoretical nuisance. The engineering response must be layered: proper wiring and grounding first, then software filtering, alarm qualification, and control validation.

OLLA Lab is credibly useful here because it provides a bounded environment to inject noise, observe instability, revise logic, and compare raw versus filtered behavior against simulated equipment state. That makes it a rehearsal space for a real commissioning task: hardening control logic before the plant supplies its own unpleasant demonstration.

The point is not to make the trend line pretty. The point is to make the control decision trustworthy.

- IEC 61000 electromagnetic compatibility standards (overview) - IEC 61131-3 — PLC programming languages - IEC 61508 Functional Safety overview - ISA overview of industrial automation standards - Åström & Murray, *Feedback Systems* (Princeton University Press)