Coder Legion - Recent posts tagged control-system

Converged Networks - Divergent Failure Modes

Wed, 21 Jan 2026 12:37:51 +0000

The Promise and the Risk

In today's industrial world, the lines between IT and OT are becoming increasingly blurred. What was once a clear separation between the corporate office network and the plant floor is becoming increasingly blurred. Networks designed for very different purposes are now converging into a single ecosystem. While this convergence brings efficiency, real-time insights, and smarter operations, it also introduces a hidden danger: divergent failure modes.

Understanding Divergent Failure Modes

Converged networks combine systems with vastly different requirements. IT systems prioritize data integrity, confidentiality, and flexible connectivity. OT systems prioritize availability, deterministic behavior, and safety. When these worlds collide, failures that were once isolated can now interact in unpredictable ways. A routine software update or misconfiguration in IT can cascade into operational disruption on the plant floor. A single misrouted connection can compromise both system performance and safety.

The Visibility Challenge

One of the biggest problems is that IT teams often do not fully understand OT behavior, and OT engineers are rarely trained to recognize complex IT threats. When a failure occurs, diagnosing it becomes complicated. What looks like a software bug may be a network timing problem, and what appears to be a sensor failure could originate from an IT misconfiguration.

Security in Converged Environments

OT environments were traditionally isolated and resistant to many forms of cyberattack. Convergence exposes them to vulnerabilities that were once confined to IT. Malware or ransomware that once only affected office computers can now propagate to industrial control systems. The consequences are no longer limited to lost productivity - they can result in equipment damage, safety incidents, or even human harm.

A New Mindset for Leaders

Managing converged networks requires a shift in thinking. Leaders must break down silos between IT and OT, foster collaboration, and promote cross-training. Network design must include segmentation, monitoring, and fail-safe mechanisms tailored to both IT and OT requirements. Incident response plans must anticipate how failures in one domain can ripple into the other.

The Lesson

Convergence creates opportunity but also magnifies risk. The organizations that thrive will be those that understand their network's weakest points, anticipate how failures can interact, and build systems that are secure, resilient, and adaptive. Protecting industrial operations is not about choosing IT over OT. It is about understanding the unique demands of both and designing systems that prevent small problems from becoming catastrophic failures.

Conclusion
The age of converged networks is here. Technology alone cannot ensure safety and resilience. Leaders who identify hidden fault lines and take deliberate steps to address them will not only survive - they will set the standard for the future of industrial operations.

Tool Vendors vs Control Vendors: Two Very Different Threat Models

Thu, 15 Jan 2026 16:20:42 +0000

Why This Distinction Matters in OT

In operational technology environments, vendor roles are often misunderstood or oversimplified, particularly when security frameworks from IT are applied without adaptation. Tool vendors and control vendors may coexist within the same architecture, but they operate under fundamentally different threat models. Failing to recognize this difference leads to flawed risk assessments, misplaced trust, and security controls that protect visibility rather than safety. In OT, this distinction matters because the consequences extend beyond data loss and directly affect physical processes.

Control Vendors: When Compromise Equals Process Control

Control vendors are responsible for the systems that execute industrial logic and translate digital instructions into physical action. PLCs, DCS platforms, safety controllers, and engineering workstations sit at the core of industrial operations and directly influence how machinery behaves. When these systems are compromised, the attacker does not merely observe or interfere with communication; they gain the ability to alter the behavior of the process itself. This makes control vendors inherently high-risk, as any breach at this layer can result in unsafe operating conditions or physical damage.

The Control Vendor Threat Model

The threat model for control vendors must assume that integrity failures can have immediate and long-term physical consequences. Malicious or corrupted logic can execute in a way that appears normal to operators while gradually pushing the process toward instability. Because industrial environments are designed for consistency and long lifecycles, such compromises can remain undetected for extended periods. Recovery is rarely straightforward, often requiring shutdowns, extensive validation, and re-establishment of trust in both the system and the vendor.

Why Control Vendors Are High-Value Targets

Control vendors represent attractive targets for adversaries due to their broad deployment and long-term presence in critical infrastructure. A single vulnerability or compromised update can propagate across many facilities, sometimes globally. These systems are often trusted implicitly and updated infrequently, which increases the potential impact of supply chain attacks. The ability to influence control logic at scale makes control vendors far more consequential targets than many traditional IT suppliers.

Tool Vendors: Observers, Not Process Owners

Tool vendors operate in a supporting role, providing visibility, monitoring, and protective filtering around industrial systems. Firewalls, intrusion detection platforms, asset discovery tools, and analytics solutions help operators understand what is happening in the environment, but they do not execute control logic or directly manipulate physical equipment. Their value lies in detection and awareness rather than decision-making at the process level.

The Tool Vendor Threat Model

The threat model for tool vendors assumes that compromise results primarily in loss of visibility, inaccurate alerts, or data exposure. While these outcomes are serious and can delay response to real incidents, they do not immediately alter the behavior of the industrial process. Tools are expected to fail safely, meaning their removal or isolation should not stop production or create hazardous states. This difference allows tool vendors to operate with greater flexibility in patching and system changes.

The Critical Difference: Who Owns the “Last Action”

The defining distinction between control vendors and tool vendors lies in ownership of the final action before physical movement occurs. Control vendors determine how logic is executed and how actuators respond, placing them directly between software and physics. Tool vendors, by contrast, influence understanding and response but not execution. This separation fundamentally changes the impact of compromise and must be reflected in how risk is assessed and mitigated.

Why Applying IT Threat Models Breaks OT Security

Applying IT-centric threat models to OT environments often leads to overconfidence in monitoring and underinvestment in control-layer integrity. While tools can provide extensive telemetry and sophisticated detection, they cannot prevent malicious logic from executing if the control system itself is compromised. In OT, security cannot rely solely on observation; it must ensure that execution remains trustworthy.

Supply Chain Risk: A Tale of Two Vendors

Supply chain compromise highlights the stark contrast between these vendor types. When a tool vendor is compromised, organizations may experience reduced visibility or delayed detection, but operations can usually continue while the issue is addressed. When a control vendor is compromised, the integrity of the entire process is called into question. The resulting impact can include physical damage, extended outages, and lengthy investigations to determine whether systems can be trusted again.

The Hidden Problem: Control Vendors Often Don’t Act Like High-Risk Vendors

Despite their critical role, many control vendors have historically lagged in adopting security practices that reflect their risk profile. Security features such as cryptographic signing, secure boot, and robust vulnerability disclosure have often been slow to appear. This gap leaves operators compensating with external tools rather than addressing the root of the risk at the control layer.

What OT Professionals Must Do Differently

OT professionals must consciously separate how they evaluate control vendors and tool vendors. Risk assessments should prioritize components that execute logic and influence physical outcomes. While tools remain important, they should be treated as compensating controls rather than foundational security measures. Greater scrutiny and higher expectations must be placed on vendors whose products directly affect safety and process integrity.

The Future: Agentic AI Makes This Divide Even Sharper

As industrial systems begin to incorporate autonomous and AI-driven decision-making, the line between tool and control becomes even more critical. Once an AI system is permitted to adjust setpoints or execute actions without human approval, it effectively becomes part of the control layer. At that point, it inherits the same threat model and safety responsibilities as traditional control systems, regardless of how it is marketed.

Conclusion: Different Vendors, Different Consequences

Tool vendors and control vendors play distinct roles, and those roles carry very different consequences when things go wrong. Tools help operators see and understand the environment, but control systems decide how it behaves. In OT security, protecting visibility is not the same as protecting the process. True resilience comes from recognizing who owns the last action and ensuring that those systems are designed, secured, and governed accordingly.

(Demo Game) Progress Record & Soft Intro to PID Controller

Wed, 23 Jul 2025 12:39:17 +0000

Video Intro

As fate has it, this is the third time I am doing control system simulation stuff in real-time, after proportional control and vehicle control system.

This demo shows controlling spaceship maneuver using PID controller in 2D. The video walkthrough covers the basic rocket control. It also shows GUI features for setting up such a control system by defining operations on fuel and signals.

Online demo: https://youtu.be/Yqh1EL9nN4g

Understanding the Problem and PID Control

One example of cruise control in everyday life is cars maintaining a steady speed on a highway. Similar concept apply to rockets or spaceships. Unlike cars, which move along a single dimension (forward), rockets operate in a 2D (or even 3D) space where they must manage not just speed but also direction, orientation, and position. Designing a cruise control system for such a scenario introduces unique challenges that require more sophisticated control mechanisms.

At its core, cruise control for a rocket or spaceship means maintaining a desired velocity or position in space despite disturbances—such as gravitational pulls, drag (in simulations), or unexpected shifts in thrust. In space, this is far from straightforward. A rocket’s motion is governed by Newton’s laws, meaning it doesn’t naturally come to rest when the engines stop. Once a rocket starts moving, it will continue drifting in that direction unless an opposing force is applied. This creates the first major challenge: how to not only reach the desired speed and direction but also prevent overshooting or oscillating around the target.

The second complication is that rockets often need to control both linear motion (x and y position) and rotational motion (angle or orientation) simultaneously. In a simulation, this might mean trying to keep the rocket pointing straight up while also maintaining a stable position or velocity. Even a small error in orientation can cause the thrust to push the rocket off-course, requiring constant adjustments. This is where a PID controller comes in, as it continuously calculates how much correction is needed based on the current error, the rate of change, and past performance.

It's helpful to visualize the problem in 2D context - and reduces complexities in implementation and simulation. Imagine trying to land a rocket on a platform: you need to precisely control its horizontal and vertical speeds while keeping it upright. A simple “on-off” control (like firing thrusters only when the error is large) results in jerky, unstable behavior. PID smooths this process by blending proportional control (correcting based on error size), integral control (accounting for accumulated errors), and derivative control (damping rapid changes).

References

Cruise Control - Vehicle Proportional Control: https://youtu.be/Pt2TOeEhJ_w
Vehicle Cruise Control - Control System: https://youtu.be/A7JopQNLuAY

DevLog 20250722: (Special Project) Correct Physics Handling

Tue, 22 Jul 2025 23:45:02 +0000

Overview

This little project deals with very simple (2D) right body physics. I will not spoil all the fun - essentially we control a 2D rocket. It would be fun to visualize data processing in such a fashion on a node canvas - kind of matches our Divooka visual programming scheme.

The hypothesis is that at least for 2-dimensional cruise control, a simple PID should be able to do something useful, and it's with that gut I am set to experiment a bit to verify my idea.

I've done some experiments in July last year but ended up not going far due to technical challenges.

Challenge

The challenge was to get it working properly with physics setup. Per RigidBody2D doc:

So is it relative or global? Without being able to visualize the force, it's a bit hard to tell also whether to use a force, or to use impulse.

It's been a while and I almost gave up - never really have time to create our own physics engine. But Godot got a new physics kernel and I thought maybe give it a try.

Some Inspiration

I've been doing some analytics and talking with ChatGPT on a new airship design that puts the air vessel at the bottom of the ship instead of hanging overhead - that inspired me maybe there are two things with current setup that's not working:

After fixing a few API calls related to GraphEdit get_children() change. I was looking at the force application code once again:

func _physics_process(delta):
# Remark: We are not using to_global directly because of issues with viewport transform
var left_anchor = %LeftThrusterCenterOfAction.position
var right_anchor = %RightThrusterCenterOfAction.position

# Remark: applied force is RELATIVE to the body (aka. current object)
apply_force(Vector2(0, -1).rotated(rotation + _left_engine_angle_degrees / 180.0 * PI) * _left_engine_thrust, left_anchor)
apply_force(Vector2(0, -1).rotated(rotation + _right_engine_angle_degrees / 180.0 * PI) * _right_engine_thrust, right_anchor)

Again, it's really simple once we figure out what's the right way to do things.

References

Video and intro: YouTube