Beyond Purdue No. 008 / Logic as an asset, Architecture
Goodbye Layers, Welcome Channels: Why Logics and Functional Diagrams Must Be Treated as Real Assets
Let me share two real-world stories with you. They reveal the very risks we face when control logics, configurations, and software environments are treated as afterthoughts — instead of core...

Let me share two real-world stories with you. They reveal the very risks we face when control logics, configurations, and software environments are treated as afterthoughts — instead of core industrial assets.
Story 1: Locked Out by EPC Design
At a major industrial facility, we encountered a troubling case: the plant relied on Siemens S7-200 PLCs — intended for the Chinese market — with no meaningful OEM support or documentation. The logic was password-locked and entirely inaccessible. Not even the plant engineers could retrieve or inspect the control logic that runs the facility.
This wasn’t just a documentation issue. It meant that the plant had no way to diagnose problems, perform updates, or migrate systems without relying on vendor black boxes — not even to build sound business continuity and contingency plans. It took extensive reverse-engineering to regain visibility and control.
Story 2: A 50 EUR Controller, A 5 GB Nightmare
Siemens LOGO! controllers are praised for their simplicity. But when we tried to configure one recently, we were met with a bloated 5+ GB installer, unsupported software environments, and outdated websites. On macOS, it was practically unusable without resorting to emulation or dubious downloads.
A €50 programmable controller turned into hours of wasted time and serious cybersecurity concerns — all because of a poorly supported software ecosystem. Something that should’ve taken minutes became a multi-hour risk.
Both stories share one root problem: lack of independence, lack of transparency, and growing OEM control over what should be user-owned infrastructure.

A Dangerous Illusion of Simplicity
Then there’s the other side of the equation: the software environments running on HMIs and systems for data processing, visualisation, and archiving. These operating systems are often so bent—so customised and outdated—that even a basic update becomes impossible. You touch one thing, and five others break.
What started as a way to simplify operations becomes the very thing that blocks upgrades. A bottleneck. A security hole. A growing operational risk.
The Purdue Model Is Done. It’s Time for a New View.
This is where many still cling to the old Purdue model, layering their networks and hoping it holds. But reality doesn’t respect neat architecture diagrams. Real plants are messier. Dependencies flow in every direction. Boundaries get crossed every day—usually without anyone realising.
At Bohemia Market, we say goodbye to layers and welcome channels.
In our “Beyond Purdue” series, we explain exactly why the layered model isn’t enough anymore—and how channels offer a better, more reliable way to define what should and should not be connected. It’s about creating trusted pathways, not trusting arbitrary borders.
Bonus Story – A Blackout That Could’ve Been Prevented
Any control system connected to the grid must be physically and logically isolated. And yet, we keep connecting more of them—without demanding architectural security from the start. (We'll return to the growing risk of mixing safety logic with control platforms in an upcoming article — because the trend of embedding ESD and Fire & Gas logic into editable, networked environments deserves its own deep dive.)
During the recent blackout in Spain and Portugal, we saw what can happen when critical infrastructure relies on unstructured and remote-controlled logic.
Many solar plants and grid-connected systems depend on parameter updates from Chinese servers — even after commissioning. This leaves system behavior open to change, without visibility or approval from the owner or grid operator.
Once a safety or control system is approved, its logic should be locked. Firmware must be fixed. Any device participating in grid stability or protection is connected to the grid must be isolated—not dependent on cloud APIs or external servers.
Architecture matters. Isolation matters. Control should never depend on remote updates.
(We’ve warned before: 100 GW of rooftop solar is already straining Europe's infrastructure — and more failures will follow unless this changes.)
What Needs to Change
The logics and parameters inside your PLCs and DCS systems are not just software — they are the operational brain of your plant. They deserve the same protection, governance, and ownership as your most valuable physical assets.
As we saw in the industrial plant case above, the client had no visibility or access to the control logic — a situation that should never happen. These systems must be designed for maintainability and long-term independence from the OEM.
This kind of vendor lock-in must be avoided — especially as OEMs now increasingly shift toward Software-as-a-Service (SaaS) models, where logic lives in the cloud, and users pay per tag, per device, or per month. This path leads to total dependence — and total loss of control.
This was echoed in our second example above — a LOGO! controller that should have been easy to configure, but ended up demanding over 5 GB of downloads, unsupported software, and compatibility workarounds just to function. What should’ve been a five-minute job became a cybersecurity concern and a major productivity loss.
These examples show why independence matters — not just physical independence, but operational independence. You must:
- Detach the HMI from the PLC/DCS logic
- Use modern protocols like OPC UA inside a Multi-Channel Architecture
- Treat logic documentation as sacred
- Avoid cloud-only configuration schemes from OEMs
That’s why at Bohemia Market, we’re building platforms like SecureDCS and SafeRTU — to give you full control of your logic, your data, and your infrastructure.
Your control system should work for you. Not for the vendor.
If you can't see your logics, track your versions, or back up your configurations—you're not in control of your plant. You're just hoping nothing goes wrong.
That’s not good enough.
At Bohemia Market, we approach logics and software environments with the same care and attention as physical equipment. We help you bring visibility, control, and security to what’s actually running your plant.
So if you’re still relying on invisible code, undocumented diagrams, or “magic” from your OEM, it’s time to take back control.
If you want to know how you can do that for your control systems, message me and get on a call with me (no obligations on your part).
If you want to find out where your systems might be vulnerable or misconfigured, take our free ICS Security Assessment Quiz here: https://quizzes.bohemiamarket.com/securedatatransfer


