Bohemia Market Blog

The Next Black Swan: What a Mega-Volcano Does to Your Solar Farm

ceo@bohemiamarket.com (Petr Roupec) — Mon, 23 Mar 2026 08:28:47 GMT

You don’t notice fragility when the system works.

Solar plants look reliable, Predictable, Modelled, Financed, Optimized.
They perform beautifully — as long as the world behaves.

But reliability built on assumptions is not reliability.
It is a story we tell ourselves until reality interrupts.

History does not fail gradually. It fails in jumps. In 536 AD, the sun didn’t disappear. It simply became weaker. That was enough to:

- Harvests collapsed.
- Temperatures dropped.
- Entire systems — not just crops,
but economies and societies — began to unravel.

No warning. No smooth curve. No adjustment period. Just a shift.

Then again in 1815. Tambora.

A single eruption — and the following year had no summer.

This is how real risk behaves.
- Not linear.
- Not predictable.
- Not included in your model.

What would happen to your solar plant if the sky went dim for a year?

Not because of clouds. Not because of dust. Because a volcano on the other side of the planet blew so hard it changed the atmosphere.

This already happened.

In 536 AD, the sun faded. Not disappeared completely — but weakened, muted, as if the whole world had been placed behind dirty glass. Chroniclers wrote that it shone like the moon. Summer failed. Crops collapsed. Snow fell in places where it should not have existed. Famine came next. Whole societies were pushed to the edge.

Then came Tambora in 1815. The following year became known as The Year Without a Summer. Europe was already wounded from war, and then the sky itself turned against it. Fields failed. Food prices exploded. In North America, farmers watched growing seasons shrink into absurdity. What had always been dependable suddenly was not.

Now bring that forward into the modern world.

A utility-scale solar plant looks robust when the sky behaves. Rows of glass. Megawatts of installed confidence. Forecasts, P50 models, yield curves, financing assumptions, O&M plans. Everything optimized.

Then ash starts falling.

Not lava. Not dramatic Hollywood scenes. Fine ash. The kind that settles quietly onto PV modules and turns expensive generation assets into grey plates that no longer see light properly. Near the eruption zone, output can fall brutally. And unless rain helps, the plant does not magically recover. Somebody has to clean it, inspect it, and restore it.

But the more interesting part comes after the ash.

The real planetary effect is in the upper atmosphere. Sulfur dioxide rises into the stratosphere and becomes a veil of sulfate aerosols. Direct sunlight weakens. The beam becomes softer, more scattered. The world does not go black — it goes diffused.

And that is where lazy thinking fails.

Because the impact is not simply “less sun = dead solar.” It is more complicated. Direct radiation drops sharply, but diffuse light increases. Some systems suffer more than others. Bifacial designs may behave differently. Tracking assumptions change. Local contamination and global atmospheric effects become two separate risk categories.

So the real lesson is not that solar suddenly becomes useless.

The real lesson is that single-source confidence is fragile.

A volcanic winter does not ask whether your model was bankable. It does not care that your plant was optimized for clear-sky yield. It simply reminds you that resilience and optimization are not the same thing.

That is why this is bigger than solar.

A serious grid should never depend on one weather pattern, one technology, one fuel logic, or one planning assumption. When history throws ash into the sky, resilience comes from diversity: wind, hydro, geothermal, storage, thermal backup, islanding capability, black-start logic, and operational discipline.

Mega-volcanoes did not just ruin harvests. They destabilized economies, accelerated migration, and broke political systems.

The modern version of that story starts with infrastructure.

And the uncomfortable question is simple:

Are volcanic scenarios in your resilience planning — or are you still designing only for normal weather?

The Next Black Swan Isn't on Anyone's Checklist. It Never Was.

ceo@bohemiamarket.com (Petr Roupec) — Sun, 22 Mar 2026 07:13:55 GMT

The Next Black Swan Isn't on Anyone's Checklist. It Never Was.

Six months ago I wrote about Black Swans and why your AI platform won't save you when reality breaks the forecast.

This week, reality broke the forecast.

Precision strikes across the Middle East are not just a geopolitical event. For critical infrastructure operators, they are a live stress test — one that nobody ran in their simulation environment.

What is actually being destroyed?

- Not just physical assets. The entire assumption stack.
- Fiber links to centralized cloud platforms — gone.
- Satellite uplinks — jammed or degraded.
- Regional data centers — offline or at risk.
- Always-on connectivity to your SCADA cloud dashboard — non-existent.

If your AI lives in the cloud and your edge is dumb, you already know the answer. Your plant is blind.

And this isn't theory. Power generation facilities in conflict-adjacent zones are running right now. Some with full situational awareness. Some with none. The difference isn't budget or dashboard sophistication. It's a design philosophy.

"Optimization makes you fragile. The most robust systems are those that sacrifice efficiency for redundancy." — Nassim Nicholas Taleb

Every vendor selling you a cloud-native AI platform for energy management should be asked one question right now:

What does your platform do when the WAN link drops, the satellite is degraded, and the regional cloud node is offline? If the answer involves the word "reconnect" — you have your answer.

The plants that are still seeing their process values, still running their predictive models, still logging to their historian right now — are the ones built edge-first.

- Local intelligence.
- Local storage.
- Local context.
- Zero dependency on a hyperscaler 3,000 km away.

This is exactly what Beyond Purdue is about.

Not theoretical resilience. The ability to answer, in plain language, what happened in my plant in the last 24 hours — even when the world outside is on fire. The Middle East situation is not a Black Swan anymore. It is now on the checklist. The next one won't be. Build accordingly.

Stop Calling Proven Control Systems Obsolete

ceo@bohemiamarket.com (Petr Roupec) — Sat, 21 Mar 2026 10:20:02 GMT

A Beyond Purdue perspective

Beyond Purdue starts with a simple observation. Control systems do not suddenly lose value when they cross an arbitrary age line. Siemens S5, T2000, and similar platforms were engineered for long service, stable behavior, and clear separation of functions. They still run plants safely every day. The problem is not age. The problem is the belief that progress only comes from replacement.

The Purdue Model taught generations to think in layers and boundaries. That thinking still matters. What went wrong later was the habit of flattening everything into a new stack. In practice, most failures I see are not caused by old control logic. They are caused by broken continuity. Documentation disappears. Engineers change. Decisions get made without understanding what already works. No control system becomes unsafe just because it passed a birthday. What happens instead is that people stop understanding it.

This is exactly why we introduced OMLEX – Operation and Maintenance Life Extension years ago. OMLEX is not about adding megawatts. The real point is simpler and often ignored. Replacing a control system, even at the cost of millions, will not add a single megawatt either. OMLEX exists as an answer to unnecessary upgrades. It focuses on keeping proven systems running safely and predictably through proper maintenance, continuity, and understanding of what is already installed.

Recent projects show how this works in practice. We upgraded tariff metering and data paths without touching the core control logic. New measurement devices, independent data channels, and secure transfer mechanisms were added around the existing system. Control stayed where it belongs. Billing, reporting, and external access were separated. The plant gained better data quality and clearer responsibility. The original system stayed in place and did what it has always done well.

This is Beyond Purdue in real life. Do not flatten everything into one modern platform. Add depth instead. Add independent layers where they make sense. Add secure, one-way data paths. Add clear ownership of data flows. Keep the control system focused on control. Extend visibility and accountability without disturbing proven logic.

The missing piece is almost always people. On-the-job training is often the most valuable upgrade a plant can make. Not generic classroom sessions. Real work on real systems. Setting up a CP1430. Understanding how SINEC and NCM were meant to be used. Seeing why decisions taken thirty years ago still make technical sense today. Once engineers touch the system properly, fear disappears. The system becomes predictable again.

We have done this in many power stations. Short refreshment courses combined with site support. Step by step. No pressure to replace. No sales agenda. Just restoring competence. The result is usually immediate. Better decisions. Lower operational risk. Longer asset life.

Beyond Purdue is not nostalgia. OMLEX is not resistance to change. Both are about stewardship. A plant that has run reliably for decades contains embedded knowledge that cannot be recreated by migration alone. Replacing it without understanding it first is not modernization. It is amputation. Real modernization builds around proven systems, not over them.

So when someone tells you your control system is obsolete, ask a different question. Is the system failing, or did the knowledge fade away? If you are still running proven platforms and feel pressure to replace them because of age, there is another path. Add depth. Add separation. Add training. Keep control where it belongs. That is the OMLEX mindset. That is Beyond Purdue, as practiced at Bohemia Market.

Stop Calling your proven DCS System Obsolete – think again!

ceo@bohemiamarket.com (Petr Roupec) — Fri, 20 Mar 2026 12:13:44 GMT

Cybersecurity: Why isolation of proven system work

Is the replacement and upgrade of the system only solution how to treat information security risks? Why would you replace stable and proven system with “something” new which require constant patching, constant upgrades with build-in obsolescense with new set of errors, vulnerabilities which in uneconomical and costly. According to the ISO 27k, not all risks require new systems or constant patching. One accepted and strategic method of treatment is risk avoidance — and that’s exactly what we do. By isolating the control systems from external exposure, using proven methods such as data diodes and physical segmentation, we remove the attack surface entirely. This approach is compliant, stable, and doesn’t introduce new vulnerabilities — unlike forced upgrades, which often create more cybersecurity issues than they solve. Even your money moves through systems still (year 2026) running on COBOL and Windows XP — because isolation works better than unnecessary change.

ISO 27k – 4.5.4 Treating information security risks

So let’s analyze what standard such as ISO 27k are saying

Risks can be accepted if, for example, it is assessed that the risk is low or that the cost of treatment is not cost-effective for the organization. Such decisions should be recorded.

This is exactly what the upgrades are doing – they are very, very costly without bringing anything of value to the organization.

a) applying appropriate controls to reduce the risks;

Here we apply network monitoring to detect im-possible intrusion with latest tools on the market,

Implement proper controls such as backup, test and restore procedures to avoid risks such as lengthy recovery of failed equipment
Education and Knowledge recovery to know how to
Documentation update to have up-to-date information about the asset

c) avoiding risks by not allowing actions that would cause the risks to occur;

By isolating the control systems from external exposure, using proven methods such as data diodes and physical segmentation, the attack surface is entirely removed. This approach is compliant, stable, and doesn’t introduce new vulnerabilities — unlike forced upgrades, which often create more cybersecurity issues than they solve.

To keep control systems practically useable data needs to be available so data diode is a practical solution to transfer data from the system while adding zero vulnerabilities – thus isolation of control system is total.

Does upgrade solve cybersecurity risks?

The answer is nor at all!

Upgrade to new system introduce whole new set of the risks not existing in your current control system such as:

Planned obsolesce every few years
Vicious cycle of endless upgrades due to endless OS updates
Whole range on unknown new vulnerabilities
Huge dependency on OEM due to lack of knowledge
Unknown licensing structure for the future (see vmware)
Cloud dependency introduces single point of failure
Lost control over important asset such a logic diagrams
Lost control over process data as these goes to cloud and literally owned by the OEM

There is no need to follow nonsense OEM roadmaps – there is no need to compete on price – there is a need to find rational and economically sustainable way, shifting clients away from forced CAPEX cycles toward a more predictable OPEX model aligned with operational continuity.

Firewall. Remote Access. CVE 10. Stop Calling It Cybersecurity.

ceo@bohemiamarket.com (Petr Roupec) — Fri, 20 Mar 2026 11:14:43 GMT

Are you investing in OMLEX, or CAPEX driven by fear?

There has been a lot of talk that extending the life of existing control systems is a bad idea. That you must upgrade because of cybersecurity.

Let’s be honest. It’s not about cybersecurity. It’s about CAPEX.

OMLEX means Operation and Maintenance Life Extension. Keeping proven systems running, under control, with full ownership and understanding.
You are told your system is obsolete, risky, and must be replaced. But what are you actually getting? New software, new vulnerabilities, new dependencies, and another upgrade cycle in a few years.

1. On IEC 62443 Certification - OEM Evergreen Story

OEM keeps pushing for upgrades ... is new better? Think again!

Even within modernization and refurbishment projects, including recent T3000 / Omnivise deployments, it is not evident that all the listed IEC 62443 certifications are fully met across the board.

This raises a fundamental question:

Are we using certification as a meaningful assurance mechanism — or as a filtering tool without fully understanding what risk it actually covers?

Mapped IEC 62443 functional requirements into auditable operational controls
Translated these into a plant-specific risk profile
Or aligned them systematically with other frameworks such as ISO 27000

2. Moving from Compliance to Risk-Based Thinking

I believe we need to shift the discussion from:

→ “Do we have the certificate?”

to:

→ “Do we understand and control our risks?”

ISO 27000 provides a useful foundation here, particularly in how it defines risk treatment strategies, including:

reducing risk
accepting risk
transferring risk
and importantly, avoiding risk

The last point is often overlooked, but highly relevant for OT.

Avoiding risk means:

not allowing conditions under which the risk can occur

In practical terms for control systems, this translates directly into:

isolation
segmentation
controlled exposure

This is not theoretical — it is a recognized and valid approach within the standard itself, and aligns with the direction we should be taking.

3. Architectural Approach vs Tool-Based Security

A large portion of the questions raised relate to technologies:

SIEM
NGFW
Anti-malware
vulnerability scanners
etc.

These are valid in IT environments, but in OT we must be cautious.

Adding layers of tools often introduces:

additional complexity
new dependencies (patching, signatures, updates)
new failure modes
and in some cases, new attack surfaces

The alternative approach — which we have seen in practice — is to focus on architecture first:

strict separation of control systems
elimination of unnecessary connectivity
unidirectional data transfer where required (data diode concept)
controlled and auditable interfaces only

In simple terms:

If the system is not reachable, it is significantly harder to compromise.

4. On Virtualization and Residual Risk

The concern regarding virtualization is understood, especially based on previous experiences.

However, the key difference in the approach being proposed is:

virtualization is used as a preservation mechanism, not transformation
control logic and automation layers remain untouched
HMI environments are retained in a controlled and isolated context
the overall system behavior remains deterministic

This is fundamentally different from full system upgrades, where:

the entire platform changes
new vulnerabilities are introduced
and long-term dependency on OEM lifecycle increases

5. On Upgrades as a Cybersecurity Measure

We should also challenge one assumption:

Upgrading the system does not inherently improve cybersecurity.

In fact, experience across multiple plants shows that upgrades often:

introduce new vulnerabilities
create dependency on continuous patching cycles
and lead to repeated obsolescence cycles

Even current platforms are bound by hardware lifecycle constraints:

S7-300 is already discontinued
spare parts availability is limited to defined timeframes
costs increase while availability decreases

So the real question becomes:

Are we reducing risk — or simply shifting it while increasing cost and dependency?

6. Business Continuity as the Primary Objective

From a Gx perspective, our priority is clear:

Business Continuity.

Not compliance on paper, but:

systems that continue operating
systems that can be maintained and repaired
systems that do not introduce unnecessary operational risk

This is where the concept of isolation-based cybersecurity becomes relevant:

reduced attack surface
predictable system behavior
minimal external dependency
controlled data flows

7. On OEM Interaction and Practical Reality

A concern was raised regarding OEM involvement.

The proposed approach does not interfere with:

control logic
engineering tools
or automation layer operation

OEM support can still be engaged where required.

However, we should be realistic:

The biggest long-term risk is not lack of OEM involvement, but over-dependence on OEM-driven lifecycle and upgrade cycles.

8. Practical Way Forward

I suggest the following direction:

Define an Company-specific OT cybersecurity model, based on:
Focus on:
Evaluate solutions based on:

—not only on certification status.

The Next Black Swan Won’t Be on Anyone’s Checklist

ceo@bohemiamarket.com (Petr Roupec) — Wed, 18 Mar 2026 09:47:12 GMT

Why Trust, Context, and Meaning Form the

Cornerstone of Resilient Operations

The flood in Abu Dhabi was a Black Swan — once. Now everyone’s digging drains, installing water sensors, and putting “flood” on the risk register.

Just like they’ve done with cyberattacks.
And system faults.
And random hardware failures.

But what about the next Black Swan?

The real kind. The one that’s not in your SOP, doesn’t log to your historian, and doesn’t show up in your digital twin dashboard until it’s too late.

This is where most “AI for energy” strategies fail.

The Problem with AI Platforms in the Real World

Everyone wants AI-powered platforms today. Energy. Water. Industry. Cities.
Billions go into centralized dashboards, unified data lakes, and top-down optimization.

Nassim Taleb
“Optimization makes you fragile. The most robust systems are those that sacrifice efficiency for redundancy.”

If your AI lives in the cloud, and your edge is dumb, what happens when the link breaks?
Or when the sensor lies?
Or when the event simply wasn’t part of the model’s training?

That’s not theory — that’s the real world.

A Different Approach: Meaning-Driven Predictive Maintenance

We’re building something different. Not just AI, but interpretable intelligence at the edge — grounded in the physical reality of the plant.

Here’s what makes it work:

“Meaning Tags” that embed context into every signal: what it is, where it comes from, and what it affects — all in human-readable form
Correlation engines that connect control system logs with operator notes, manuals, weather conditions, and equipment datasheets
Knowledge containers — modules tailored to specific assets that actually understand what a trip, stall, or vibration means for that turbine
CEM evolution — built on what we’ve deployed already, not theoretical prototypes
Edge-first design — because power plants don’t run in the cloud

This isn’t just about prediction. It’s about contextual awareness.
The ability to ask, in real language:
“What happened in my plant in the last 24 hours?”
And get an answer that makes sense.

Resilience Over Optimization

Preventive maintenance replaces parts too early.
Reactive maintenance replaces them too late.
Our approach uses 20 years of operational data — from real power plants — to understand what really matters, and when.

It’s not just statistics. It’s structure.
And that structure comes from putting meaning first.

Because you can’t prepare for Black Swans by optimizing harder.
You prepare by making your systems explainable, interpretable, and built to survive what wasn’t expected.

The Question

The question isn’t whether your platform can deliver a forecast.
It’s whether it will still work when the world breaks the forecast.

https://www.linkedin.com/pulse/next-black-swan-wont-anyones-checklist-petr-roupec-9h6de

Purdue Was Great — 30 Years Ago. It’s Time to Move On

ceo@bohemiamarket.com (Petr Roupec) — Wed, 18 Mar 2026 09:30:28 GMT

Introducing the ‘Beyond Purdue’ Newsletter for Modern ICS Professionals

If you’ve worked in industrial control systems anytime in the last 30 years, you’ve heard of the Purdue Model.

Created in the 1990s at Purdue University, this layered architecture gave structure to the chaos of industrial environments. It separated physical processes from business systems. It helped define where operations ended and enterprise began.

For its time, it was groundbreaking. But here’s the problem: We’re still using it.

And in 2025, it’s holding us back.

Who Beyond Purdue Is For

This newsletter is built for professionals across all layers of industrial operations who are tired of legacy thinking and ready to modernize securely,

CEOs who want real alternatives to the big OEMs — without losing control or compliance,
CTOs and CISOs struggling to secure outdated systems in a world that demands cloud, VPN, and compliance,
CFOs who need trustworthy data to generate accurate financial reports and invoices
Maintenance teams who need reliable insights and secure remote access for contractors and service partners,
DCS Engineers fighting to keep critical systems stable without being forced into unrealistic patch cycles by IT,
Anyone responsible for keeping control systems operational, safe, and future-proof.

The Limitations of Purdue Model Are Real

The Purdue Model was built in a world that looked very different:

Cybersecurity wasn’t a threat — because connection speeds were in bits per second
Cloud didn’t exist — the biggest storage device was a floppy disk
Air gaps were standard — and USB wasn’t even invented yet
Data stayed where it was born — transferring it was nearly impossible

Fast forward to today, and we’re operating in a completely different reality:

We stream data across continents
We run predictive analytics in AWS
We ensure security with one-way diodes, not firewalls
And we don’t just need “segmentation”—we need resilience, context, and control

The model didn’t age badly—it just wasn’t built for this.

What Comes Next: Beyond Purdue

That’s why I’m launching Beyond Purdue — a new kind of newsletter, focused on real transformation in the world of ICS and DCS.

Not buzzwords. Not theory. Just what actually works.

Secure architectures for OT/IT data transfer
Real case studies from power stations, refineries, and solar plants
Fresh thinking on business continuity in critical infrastructure
Commentary on the death of the air gap — and what replaces it
Lessons from 25+ years of working hands-on in this space

We don’t need to destroy the Purdue model. We need to evolve beyond it.

10 x price increase in six months – Broken Supply Chain

ceo@bohemiamarket.com (Petr Roupec) — Wed, 04 Feb 2026 08:48:59 GMT

Business spiral of death

We have seen it all – after many experiments, countless hours and sleepless nights and setup hassles you find right combination of the software(s) which fulfils all contradictory requirements.

The following report analyzes the trajectories of Docker and VMware through “Business Spiral of Death” framework. It validates your strategic decision to pivot away from these platforms, detailing the specific historical inflection points where “greed” replaced value.

Business Spiral of Death

The concept of the Business Spiral of Death—where companies shift from serving users to abusing them, and finally to cannibalizing their own ecosystems—is precisely what occurred with Docker and is currently accelerating with VMware.

Business spiral of death

For a business like yours, which built products on these foundations for 10–20 years, the sudden shift to aggressive extraction models (subscriptions, forced bundles, and retroactive licensing changes) is not just a pricing annoyance; it is a breach of the architectural contract. You were not “leaving” a partner; you were evicted by their new business models. Your decision to change your product concept “mid-flight” was likely the only way to survive the “Extraction” phase described below.

The Framework: Anatomy of the Spiral of Death

Based on your insights and the “enshittification” lifecycle, we can map the demise of these platforms into three distinct phases:

Case Study 1: Docker – The Betrayal of the Builder

Docker’s story is particularly painful because it was built on the trust of open-source developers. Its “demise” is not financial bankruptcy, but moral bankruptcy—the loss of its soul and the community’s trust.

Phase 1: The Golden Era (2013–2019)

Docker started as a revolution. It took the complex concept of Linux containers (LXC) and made it accessible to everyone. “It works on my machine” became a solved problem. The company prioritized adoption over revenue, creating a massive, loyal ecosystem. You, like millions of others, trusted this layer as a neutral, reliable commodity.

Phase 2: The Pivot to “Greed” (2019–2021)

The cracks appeared when Docker split. In November 2019, it sold its Enterprise business to Mirantis to focus purely on “developer tools.” This sounded benign, but it signalled that developers were no longer the partners; they were the product.

The turning point was August 31, 2021. Docker announced that Docker Desktop, the default tool for millions, would no longer be free for companies with more than 250 employees or $10M in revenue. While reasonable on paper, the implementation was aggressive. It introduced a “compliance tax” on IT departments, forcing businesses to audit every laptop.

Phase 3: The Spiral of Death (2022–Present)

Once the subscription gate was open, the aggressive extraction began.

Pull Rate Limits (Nov 2020): Docker Hub began throttling anonymous downloads (100 pulls/6 hours). This broke thousands of CI/CD pipelines overnight. You weren’t paying for value; you were paying to stop your build server from crashing.
Image Retention (Aug 2020): They threatened to delete inactive images from free accounts. For software vendors with legacy versions (like your 10-year-old customer installs), this was a direct threat to business continuity.
The “Free Team” Debacle (March 2023): In a chaotic move, Docker emailed maintainers of “Free Team” organizations (often open-source projects) saying their accounts would be deleted within 30 days unless they paid $420/year. The backlash was so severe they walked it back, but the message was clear: Your data is our hostage.

The Result: Developers fled to alternatives like Podman, Rancher Desktop, and OrbStack. Docker is now viewed not as a standard, but as a “tax collector” in the development chain.

Case Study 2: VMware – The Extraction of the Enterprise

If Docker was a betrayal of developers, VMware (under Broadcom) is a hostile takeover of the enterprise IT budget. This serves as the “second line of thought” you requested—a mature example of the Spiral’s final stage.

The Broadcom Shock (Nov 2023)

Immediately after closing the $61B acquisition in November 2023, Broadcom executed the “Spiral” playbook with brutal efficiency:

Killed Perpetual Licenses (Dec 2023): You can no longer “own” your infrastructure. You must rent it forever.
Forced Bundling (2024): They killed individual products (like vSphere Enterprise Plus) and forced customers into massive bundles like VMware Cloud Foundation (VCF). Reports confirm price increases of 300% to 1,050% for customers who were forced to buy software they didn’t need.
Divestiture of “Non-Core” (2024): They sold off the End-User Computing (EUC) division (now Omnissa) and Carbon Black. If your business relied on VMware Horizon for VDI, you were effectively sold to a private equity firm, creating massive uncertainty.

The “Cease and Desist” Era: By 2025, Broadcom began sending legal threats to customers who applied security patches to perpetual licenses without an active (and now much more expensive) support contract. This is the definition of the Spiral’s end state: Suing your own customers to extract value.

Synthesis: Why You Were Right to Pivot

Your decision to change your product mid-flight was a survival reflex triggered by these signals. Staying would have subjected your business to:

Unpredictable COGS (Cost of Goods Sold): Both Docker and VMware demonstrated they would change pricing models overnight (e.g., Docker’s 28% Team price hike, VMware’s 10x bundle hike). You cannot offer 10-year support to your customers if your underlying costs can explode 10x in 6 months.
Broken Trust Chain: When Docker threatens to delete images or VMware threatens legal action for patching, they become liabilities. Your customers rely on you, but you relied on them. They broke that chain.
The “Zombie” Phase: As per your article, these companies are now in the phase where they “claw back all value for themselves.” Innovation has stopped (evidenced by VMware extending release cycles to 3 years to cope with backlash).

Conclusion: You did not leave these products; they left you. By pivoting, you inoculated your business against their “Death Spiral,” ensuring you wouldn’t be the one explaining to your 20-year customers why their software license now costs more than their hardware.

Powerplant Tariff Meters Upgrade

ceo@bohemiamarket.com (Petr Roupec) — Fri, 30 Jan 2026 09:51:54 GMT

After the generator, the second most important part of the power station is the tariff metering system, because it converts produced energy into money, allowing the plant to invoice and get paid.

Once the turbine has burned the gas and the generator has produced electricity, everything that follows depends on correct metering. If the produced energy is not measured correctly, it cannot be settled correctly. If it cannot be settled correctly, it cannot be invoiced. At that point, all effort invested in operating the plant does not result in revenue.

In many power stations, tariff meters installed in the 1990s and early 2000s are still in operation. At the time of installation, they fulfilled their role. Today, they are difficult to calibrate, hard to maintain, and often no longer supported by the manufacturer. Spare parts are unavailable, and replacement becomes necessary.

Replacing tariff meters introduces a new challenge. Modern meters use different protocols, different addressing, and different communication methods. They do not match what existing control systems were originally designed to accept. Direct integration would require changes to the existing DCS or SCADA system, which is usually not acceptable.

At the same time, most of the primary equipment can remain unchanged. Current transformers and voltage transformers are still suitable and continue to provide correct signals. The issue is not the measurement itself, but how the data is communicated.

To bridge this gap, a gateway is introduced between the new meters and the existing control system. On one side, it communicates with the meters using their native protocols. On the other side, it presents the data in exactly the same way as expected by the existing DCS or SCADA system. From the control system point of view, nothing changes. No logic is modified and no engineering intervention is required.

Once the data is available in the gateway, it can also be used for reporting. In addition to feeding the control system, the same data can be prepared for reporting purposes and used directly by operators and commercial teams. Reporting outputs can be generated at the required interval, whether minute-based, six-minute-based, or according to other contractual requirements, and opened directly in standard office tools.

Physical integration is just as important as data integration. Existing wiring from current and voltage transformers is reused. The same signals are split and connected to the new meters. No changes to CT, VT, or field wiring are required.

Because tariff meters are part of the revenue chain, physical sealing is mandatory. The design must ensure that no manipulation is possible, either by direct access to the meter or through communication interfaces. All revenue-related components remain protected by physical seals.

The gateway hardware must be industrial-grade and designed to fit into existing cabinets. It must operate reliably in a power plant environment and be compact enough to be installed without requiring cabinet modifications. Standard industrial computers are used, built from off-the-shelf components. There is no vendor lock-in. Media converters and related components are standard industrial devices.

And of course you can’t change all the meter and the same time. Therefore the product has to be Future proof – New additional metres, and even some other equipment might be a added by simply configuring excel spreadsheet

Cybersecurity requirements are addressed by design. The gateway operates with strict firewall rules. Interfaces are closed by default. Isolation is enforced. Any connection toward the IT environment is controlled and unidirectional

This approach allows tariff metering systems to be modernized without changing the existing DCS or SCADA system, without disturbing revenue-critical wiring, and without putting the profitability of the plant at risk.

Statistics & Probabilities – Mistakes to Avoid

ceo@bohemiamarket.com (Petr Roupec) — Tue, 27 Jan 2026 15:03:52 GMT

This comment is based on “Nassim Taleb” book “The Black Swan” which must read for everyone working with data, statistics and digital twins.

Creating information where is none

Author of the book argues that one of the most useless comments he hears is that some solutions can come from “Robust Statistics.” He (Nassim Taleb) wonders how using these techniques can create information where there is none.

Asymptotic – Idealized situation

What most students of mathematical statistics do (and all products from OEM’s) is assume a structure similar to the close structure games, typically with a priori known probability.

Kurtosis

Kurtosis is how fat the tails of probability curves are, that is, how much rare events play a role. For example, if one event represents 90 percent of 40 years of observations it is usually filtered out as an outlier, so all data set is invalid.

If you miss that one single number, you miss whole thing.

This proves that everything relying on “standard deviation”, “variance”, “least square deviation,” etc. is bogus.

This statistical perspective comes from years of working with real operational data and from learning—sometimes the hard way—how easily numbers can create confidence without understanding. Experience has shown that reality tends to be less impressed by models and abstractions than their creators expect. If you prefer fewer surprises, Nassim Taleb’s books are an efficient way to save time, money, and misplaced certainty.