Showing posts with label control. Show all posts
Showing posts with label control. Show all posts

Wednesday, June 10, 2026

Choosing the Right CPU: Desktop vs. Industrial vs. Safety-Critical

We live in an era where a standard desktop processor has 24 cores and clock speeds past 5.5 GHz. Yet, if you walk into an automotive assembly line, you will see computers (PLCs) with processors running 100x slower, and being 10x more expensive than their desktop counterparts.

Why? Because in the world of computing, power is defined entirely by the problem you are trying to solve. We have to look past raw processing speed and examine three distinct operational philosophies: Throughput, Determinism, and Functional Safety.

1. The Desktop CPU

Desktop processors are designed to handle an unpredictable, highly dynamic workload. At any given moment, a desktop CPU might be asked to render a 3D video, compile a massive codebase, manage dozens of browser tabs, or decode high-definition audio.

To excel at this, desktop CPUs use general purpose operating systems like Windows or Linux, which rely on throughput-oriented schedulers. The OS slices up time and distributes it among running applications, trying to give everything a fair share. To squeeze out every drop of performance, the silicon itself relies on microarchitectural optimizations:

  • Out-of-Order Execution: The CPU dynamically rearranges the order of instructions to keep its execution pipelines full.
  • Speculative Execution & Branch Prediction: The processor literally guesses which path a piece of code will take before it even runs, executing the instructions ahead of time to hide latency.
  • Multi-Tiered Caches (L1/L2/L3): Large memory pools sit on the die to prevent the CPU from constantly waiting on slower system RAM.

However, this architecture is inherently non-deterministic. If a background cloud-sync app suddenly demands resources, or if a branch predictor guesses wrong, a task might take 50 milliseconds longer to execute on cycle two than it did on cycle one. In the consumer world, a dropped frame in a video game is an annoyance; in a physical system, a 50ms delay can be catastrophic.

2. The Industrial PLC CPU

Step inside a factory running a high-end programmable logic controller (PLC), like the Siemens SIMATIC S7-1500. Clock speeds range from tens to hundreds of megahertz, and memory is measured in megabytes rather than gigabytes. Yet, these processors are built for a completely opposing goal: Absolute Determinism.

An industrial CPU runs a Real-Time Operating System (RTOS). Instead of a fair share schedule, the RTOS uses strict, unyielding, priority-based cyclic execution. A PLC operates on a continuous loop:

  1. Read Inputs: Snapshot the state of every physical sensor.
  2. Execute Logic: Run the user control code sequentially.
  3. Write Outputs: Instantly update physical actuators, valves, and motors.

To guarantee that this cycle takes exactly the same amount of time down to the microsecond, industrial CPUs strip away the unpredictable optimization layers of desktop chips. There is no speculative execution, no out-of-order execution, and no virtual memory paging. Every task has a strict time budget monitored by a dedicated hardware watchdog timer. If a 1ms motion control loop fails to complete in exactly 1ms, the RTOS catches it, alerts the system, and can trigger a controlled shutdown.

Industrial CPUs are also physically engineered to survive decades in harsh environments. They are decoupled from fragile cooling fans, insulated against severe electromagnetic interference (EMI), and rated to maintain their precise timing clock cycles across extreme temperature swings (e.g., -25°C to +60°C).

3. The Safety-Critical CPU

While an industrial CPU guarantees when a command will execute, a safety-critical processor guarantees the mathematical integrity of the execution itself. Found in drive-by-wire automotive systems, avionics units complying with aerospace standards (like DO-254/DO-178C), or high-speed medical equipment, these processors are certified to standards like ISO 26262 (ASIL-D) or IEC 61508 (SIL-3).

The defining feature of a commercial safety-critical processor (such as the Texas Instruments Hercules™ or Infineon AURIX™ lines) is hardware level redundancy. Instead of using multiple cores to run different applications simultaneously, a safety-critical CPU pairs identical cores into a Dual-Core Lockstep (DCLS) configuration:

  • The Master and the Checker: Two physical hardware cores execute the exact same instruction stream, line-by-line, cycle-by-cycle.
  • Temporal Separation: To ensure that a localized physical event (like a voltage spike or a cosmic ray flipping a bit in memory) doesn't corrupt both cores simultaneously, the second core runs delayed by a micro-interval (typically 2 to 3 clock cycles).
  • Hardware Comparators: Independent hardware logic monitors the internal state and outputs of both cores. If a divergence of even a single bit is detected between the Master and the Checker, the comparator immediately strips power from the actuators or switches the system to a pre-defined, hardware-enforced "safe state."

In this realm, the code is heavily audited, features like Built-In Self-Tests (BIST) continuously sweep memory for corruption, and every single gate on the silicon must be mathematically traceable back to a design requirement.

Music: Ali Baba ve 7 Cüceler (arka jenerik)

Monday, March 23, 2026

PID Theory

PID control trades optimality for simplicity, it's sub-optimal but good enough for most real systems without needing a mathematical model of the system. For example, for a lunar lander, bang-bang control achieves faster landing but you need the model the physics. You find the control parameters with simulations and tests. General form of PID control force terms:


What would be the simplest controller for a mass to stay at a specific height from the surface of a planet with only gravity acting and no atmosphere?

Without an atmosphere, your system is:


If you use only a Proportional (P) controller, your control force is:


This effectively turns your mass into a pure spring in a vacuum. It will oscillate up and down forever, centered around the target height, because there is no way to remove the kinetic energy (no damping). To stay at a specific height, you need to "electronically" create the friction/damping that the atmosphere is missing:

The P-term (Kp) provides the "restoring force" to push the mass toward the target height. The D-term (Kd) acts as artificial friction. It resists the velocity of the mass, allowing it to slow down as it approaches the target and eventually stop. The Gravity Bias (mg): Technically, to hover perfectly with a PD controller, you need to "cancel out" the constant pull of gravity so the controller only has to worry about the displacement error. Here is a P vs PD comparison using python script:

The double integrator has two poles at the origin (s=0, 0). Without a zero to "pull" them into the Left Half Plane (LHP), the poles have nowhere to go but up and down the imaginary axis as you increase K_p. By PD controller placing a zero on the LHP, you are creating a "target" in the stable region. As you increase the gain, the two poles at the origin are "pulled" off the imaginary axis and toward the LHP zero:

While an Integral (I) term is usually used to eliminate steady-state error (the "droop" caused by gravity), in a vacuum with a double integrator, adding an "I" term without a very strong "D" term is dangerous. It introduces more phase lag, which often leads to the instability shown in the original infographic you shared. In the frequency domain, an integrator introduces a 90° phase lag. A double integrator (1/s^2) already has a 180° phase lag. Adding an integral term pushes the total phase lag toward 270°.

In control systems, if your feedback is delayed by 180° or more, your "correction" starts acting in the same direction as the error. Instead of pulling the mass back to the target, the controller begins pushing it away, leading to the "Unstable" root locus you saw in the original infographic.

Integral windup is another problem where your mass (plant) is stuck (perhaps a mechanical limit or a saturated actuator), the error remains constant because the mass isn't moving, and the integral term keeps summing that error over time. The "I" value grows (winds up) to a massive number. When the mass finally breaks free, the controller has a "memory" of a huge error that no longer exists. It applies a massive, unnecessary force, causing the mass to overshoot violently or even crash into the hardware. You can mitigate windup by stopping the integrator from growing once the actuator reaches its maximum output or by only turning the "I" term on when the mass is very close to the target height.

Thursday, March 12, 2026

Digital vs Analog Simulation

While a purely digital simulation (Model-in-the-Loop) is great for testing logic, an analog simulation (Hardware-in-the-Loop) tests the electrical reality of your system. In a digital simulation, you use values like pressure directly from your atmosphere model. In reality, that pressure goes through a sensor which outputs voltage/current. Your electronics have to read that analog signal and convert it to digital before feeding it to your controller.

A real controller output has to drive a load. Analog simulation ensures the controller's transistors don't overheat or drop voltage when trying to move a high-pressure valve.

Your internal  Analog-to-Digital Converter (ADC) might add extra error. For example, your atmosphere model says 101.325kPa, but your ADC might convert it to 101.328 kPa due to its internal tolerance. Analog simulation reveals whether your control algorithm is robust enough to handle that 0.003 kPa error without oscillating. It also verifies that your controller’s ADC is actually calibrated correctly. The signal chain:

You cannot "short a wire to ground" in a purely digital simulation and see the smoke. With hardware like NI PXI Fault Insertion Units, you can physically short an analog input to a 24V rail. This allows you to verify that your hardware's protection diodes work and that your software enters a "Safe State" immediately.

Tuesday, May 27, 2025

Fuzzy Logic and Quake III Bots

Fuzzy logic is often used in decision-making systems where a detailed mathematical model of the system is unavailable or impractical. Instead of relying on equations, fuzzy logic encodes expert intuition into human-readable rules. These rules allow systems to make decisions based on approximate or linguistic input values, such as “low health” or “enemy nearby.”

For simple systems — say, with just one input and one output — fuzzy logic may be overkill. In those cases, a 1D interpolation (similar to proportional navigation) is often enough to generate smooth behavior transitions. But as systems grow more complex, fuzzy logic scales better than maintaining large interpolation grids or rigid condition trees.

While neural networks have become dominant in many domains, fuzzy logic still offers distinct advantages, especially in embedded or control-focused systems. Fuzzy logic requires structured human insight, while neural networks thrive on raw data and pattern discovery. For complex or poorly understood systems, writing fuzzy rules is impractical. Advantages of fuzzy logic over neural networks:

  1. Interpretability: Fuzzy rules are readable and understandable by developers and domain experts.
  2. Minimal training: Rules encode prior knowledge, reducing or eliminating the need for extensive data-driven training.
  3. Lightweight tuning: At most, fuzzy systems may require optimizing rule weights — a much simpler process than full network training.

One of the most interesting uses of fuzzy logic in gaming came from Quake III Arena. The bots in the game used fuzzy logic to evaluate possible behaviors — such as attack, search for health, search for a better weapon, retreat. Each action was assigned a desirability score based on fuzzy evaluations of current game state (e.g., health, distance to enemy, ammo). At each tick, the bot would choose the highest-scoring action.

To tune the bot parameters, the developers had bots play against each other and applied genetic algorithms to evolve the best-performing rule sets. Of course, they could not make the bots perfect because then a human player would never be able to win.