Your DCS Vendor is the Single Point of Failure

Just after noon on February 7, 1904, Baltimore firefighters responded to a warehouse fire on West German Street. Within hours it was clear the city could not contain it and calls for help went out across the region.

Crews arrived from Philadelphia, New York, Wilmington, Harrisburg, Chester, Altoona, Annapolis, and Washington, D.C. The Washington engines made it by train in under an hour.

Then they couldn’t do anything.

The hose couplings that the visiting firefighters carried did not fit Baltimore’s hydrants. Thread type and size varied between cities. Firefighters who had mobilized and traveled for hours stood and watched.

The engines were there. The water was there. The men were there. The threads didn’t match.

The fire burned for 30 hours and destroyed more than 1,500 buildings across 70 city blocks.

Protecting Incumbents

It is tempting to read that as a story about primitive engineering, an era before anyone thought to write things down. It isn’t. There were roughly 600 different hose coupling and hydrant variations in use across the United States at the time, and the differences in diameter and thread were understood to protect incumbent suppliers against competition.

That is the detail worth sitting with. The incompatibility was not an oversight. It was working exactly as designed. Every city that bought hydrants with a unique thread bought a permanent supplier relationship along with them, and the cost of that arrangement stayed invisible right up until the moment it had to be paid all at once.

The following year, a committee of the National Fire Protection Association set a standard diameter and thread count for hose couplings and hydrants. It is still called the Baltimore standard, and it is still the national standard today.

The story should end there, but it doesn’t.

It Happened Again, 87 Years Later

In 1991, the Oakland firestorm killed 25 people and burned more than 3,000 homes and apartments. Mutual aid came from as far as Bakersfield and across the Nevada line, and those crews had trouble connecting to Oakland’s hydrants. Oakland adopted the national standard afterward. Many jurisdictions still haven’t because changing the standard means replacing every threaded connection you own, at considerable expense.

Eighty-seven years apart, the same failure. Not because the standard didn’t exist, but because the cost of leaving a proprietary connection behind kept outrunning the perceived risk of keeping it.

Industrial automation has been making that same trade for over thirty years.

You Already Know How to Do This

Every control engineer reading this has spent a career hunting “single points of failure.”

You specify redundant controllers. You run dual networks on separate physical paths. You feed the cabinet from A and B power. You put critical trips on 2oo3 voting, so a single transmitter can’t shut down a unit or, worse, fail to. You mirror the historian. You keep spare I/O cards on the shelf, and you know which ones have a long lead time. During a FAT you pull a cable specifically to watch what happens.

The discipline is rigorous, it is well documented, and it works. Process plants have run for decades on it.

Then the same organization signs a thirty-year dependency on one vendor’s proprietary architecture, and that decision gets filed under procurement.

Nobody drew it on a P&ID. It never appeared in a FMEA. No one ran the failure case, because the failure doesn’t look like a failure. It looks like a purchase order.

What Counts as a Failure

The gap here is definitional, and it’s worth being precise about, because the engineering definition of a single point of failure is narrower than the business one.

An engineer looks for a component whose loss stops the process. That’s the right question for a transmitter. It is the wrong question for a supplier, because suppliers rarely stop. They do something more corrosive: they change the terms.

A more useful definition for anything with a thirty-year life is this. A single point of failure is any element whose removal, discontinuation, repricing, or strategic abandonment disrupts the business.

Run your architecture against that definition and a different list comes back:

• The controller family that goes to “mature” status, then “classic,” then unavailable.
• The engineering workstation that requires an operating system your IT organization stopped allowing on the network two years ago.
• The proprietary fieldbus with one source for every gateway, and no roadmap you’re allowed to see.
• The license renewal that arrives with a number attached that you have no way to negotiate.
• The support contract whose price rises on a schedule set entirely by the vendor you can’t replace.

None of those are outages. Every one of them is a disruption, and every one of them arrives on the supplier’s timetable rather than yours. The plant keeps running. The business absorbs the cost, usually as an unplanned capital project, and usually described internally as an upgrade rather than as what it is: a payment on a dependency that was created decades earlier and never made visible.

That’s the same invisible cost the cities of 1904 were carrying. It sat on no balance sheet until the day it came due all at once.

The Paradox of Buying Big

There is a rational-sounding answer to all of this, and it’s the one the industry has used for fifty years: buy from a vendor large enough that none of this can happen.

Select a supplier with a global installed base, tens of thousands of employees, presence in every region you operate in, and a name your board recognizes. A company that size will still be here in 2050. Its support organization will still answer the phone. The reasoning is sound. It explains why so much of the process industries’ control infrastructure is controlled by a handful of very large suppliers.

But look carefully at what that decision actually purchases, because it is not what you think.

Vendor size addresses one risk: the supplier ceasing to exist. That is a real risk, and a large vendor genuinely reduces it. What size does not address at all is the risk that the supplier remains perfectly healthy and simply makes decisions you have to live with.

• Discontinues a product family.
• Restructures a license model.
• Acquires a competitor and rationalizes overlapping lines.
• Decides that your industry is no longer strategic.
• Gets acquired itself.

Here is the paradox, and it’s the sentence to take into your next capital review:

Buying from a very large vendor reduces the perceived risk of supplier failure while a proprietary architecture increases the actual dependency on that supplier’s decisions.

Those two things get treated as one variable. They are not related. Company size tells you something about whether a supplier will exist. It tells you nothing about whether you will have any alternative if that supplier’s plans and yours diverge. Make no mistake about it, over thirty years, they will diverge.

Corporate longevity was never the thing that protected you. It just felt like it, which was enough, because for most of the industry’s history there was no other option.

There is now.

But before making that case, it’s worth looking at what happened to a company that sold nothing but reliability.

The Company That Sold Fault Tolerance

In 1974, a former Hewlett-Packard manager named James Treybig started a company on a single premise: computers that never stop.

Treybig had tried to interest HP in building a fault-tolerant machine for banks and was turned down, so he left and founded Tandem Computers on a $50,000 investment.

The business plan is the part worth quoting. Tandem set out to build systems proof against “single point failures” at only slightly more than the price of competing non-fault-tolerant machines. The reasoning being that if reliability costs too much, customers just work around downtime instead of buying it.

The engineering was radical for its time. No shared memory. No shared central components of any kind. Independent processors passing messages across a redundant fabric, mirrored disks, dual-connected controllers, power supplies wired so that losing one couldn’t take down a pair of anything.

That was the product. Not performance, not price. In essence, they bought the absence of anything that could stop the business. It sold to banks, payment processors, ATM networks, and stock exchanges: the places where downtime is not an inconvenience.

It worked. The first customer system shipped to Citibank in 1976, and sales doubled every year for Tandem’s first six years, rising from $56 million in 1979 to $312 million in 1982. Nobody bought a Tandem to save money.

The One Failure They Couldn’t Design Out

Then the thing Tandem had spent twenty years engineering out of the cabinet happened to the company itself.

Compaq acquired Tandem in 1997 and Digital Equipment Corporation the year after, then began publicly weighing whether the Tandem line's future was Intel or DEC's Alpha processor.

On June 25, 2001, it terminated Alpha entirely and handed the design teams and intellectual property to Intel. Its filing that day told NonStop customers what that meant: keep running MIPS until Itanium versions arrive in 2004. Compaq merged with HP in 2002. Itanium NonStop shipped in 2005. By then, Itanium itself was already faltering. By November 2013, HP had announced a move to x86.

Count the processor architectures: proprietary, MIPS, Itanium, x86. Every transition decided in a boardroom. Not one decided by a customer whose transaction system was running on top of it.

And the customers had nowhere to go.

Forrester's assessment of the x86 announcement is unusually direct about why: NonStop was far harder to engineer out of an organization than other platforms because there were few viable alternatives at any reasonable cost, so switching costs were high enough that HP could price at a premium, with little pressure to price as though it faced competition.

That is an industry analyst describing somebody else's product. The absence of an alternative was the pricing strategy.

Ironically, the Product Line Is Still Alive

Here is the part that seems to argue against everything above. You can still buy a NonStop system from HPE today. The line survived every one of those acquisitions.

Which sounds like a refutation, right up until you look at what’s inside one.

HPE’s own literature describes what you get. The current flagship is an x86-based system running Intel Xeon Gold processors, with a dual-fabric InfiniBand system interconnect. There is also a virtualized edition that runs the NonStop software stack in a VMware environment and can be deployed on infrastructure built from industry-standard servers, storage, and networking products from the customer’s choice of vendors.

The proprietary CPU is gone. The proprietary interconnect is gone. Standard database interfaces, a POSIX environment, standard servers, and in the virtualized case, servers HPE doesn’t even have to sell you.

A customer running NonStop in 2026 is running almost nothing that Tandem built.

The system survived because the platform underneath it converged, piece by piece, on open standards. That convergence was never announced as a strategy. It was the only path forward each time the proprietary layer beneath became unsustainable. Every migration was mandatory. Not one was scheduled by the end user.

The Company That Wrote a Standard and Sold the Alternative

Tandem is the optimistic version of this story. For the pessimistic one, look at the company Compaq bought a year later.

Digital Equipment Corporation was one of the most important technology companies that has ever existed. It also did something unusual. Beginning in 1979, DEC joined Intel and Xerox in a consortium to turn Ethernet from Xerox property into something anyone could build against. To avoid antitrust exposure, the three companies had to agree to place the results in the public domain for the purpose of creating a standard. In September 1980 they published the Ethernet “Blue Book” specification, which became the basis of IEEE 802.3.

DEC also built DECnet, its own proprietary networking stack, and sold it hard alongside its VAX line.

DEC no longer exists. Ethernet is in every plant on earth, including yours. The IEEE’s own history notes that it is increasingly chosen as the underlying transport for industrial automation. DECnet is in none of them.

The same company produced both an open standard and a proprietary alternative to it. Only one of them outlived the company, by more than forty years, and counting.

The most fault-tolerant computers ever built were sold by a company that could not itself tolerate a fault. The standard it helped create did.

The Industry That Made It a Purchasing Requirement

Ethernet survived because anyone could build against it. That was not a peculiarity of networking. In the same years, a neighboring industry was turning the same principle into a condition of doing business, and it is the industry with the most reason to fear obsolescence, since a part designed today may be gone in five years while the products built around it are expected to run for decades.

When IBM chose Intel’s 8086 for the original PC, it did not simply place an order. IBM’s purchasing organization pushed Intel for a domestic second source, on the grounds that production had to be guaranteed and depending on a single company for the processor was too much risk to accept. Intel already held agreements with Siemens and Fujitsu, but neither could build the 8086 or the 8088, so in 1982, Intel and AMD signed the agreement that made AMD a second source for both parts.

Two things there are worth carrying forward. The requirement came from the customer’s purchasing organization, not from engineering, and not from the supplier. And note what didn’t satisfy it: Intel held agreements with two of the largest electronics manufacturers in the world, and they didn’t count, because neither could actually build the part. A second source that exists on paper but cannot deliver is not a second source.

The discipline became standard practice and remains so: a qualified backup path established before a single part can stop production, identified by ranking a bill of materials for supply risk long before any shortage becomes urgent.

IBM wanted continuity. What it got was forty years of competition. Intel and AMD have spent four decades attacking each other on price and performance, and without competitive pressure from AMD, it is doubtful Intel would have delivered the products or the pricing on the timeline it did. The people who run second-source programs are blunt about that effect: competition pushes original suppliers to lower prices and prevents monopolistic pricing, and successful second sourcing delivers 5 to 15 percent cost savings even after the cost of qualifying the alternate.

Competition is not a happy side effect of interoperability. It is a mechanism that interoperability creates, and that proprietary architecture is specifically designed to prevent.

A proprietary control system has no competitor at the component level. Not because its supplier is uncompetitive, but because there is no interface at which a competitor could appear. The prices you pay for spares, licenses, and support are the prices a supplier sets when the answer to “what else could we do” is nothing.

Why You Can’t Buy Your Way Out

Here is the part that matters most for anyone who negotiates contracts.

Second sourcing was possible for IBM because of a published instruction set, standard sockets, defined pinouts, and common memory interfaces. AMD could build a part that dropped into the same socket and ran the same code because the interface was documented and available to build against.

Take the interface away and no contract term recreates it. You can write dual-source language into an agreement, demand a source code escrow, negotiate end-of-life notification periods, and secure price protection on spares. Those are all worth doing, and none of them produces a second source. They produce a slightly better relationship with the only supplier you have.

That’s the Siemens and Fujitsu problem again, one level up. An agreement that entitles you to something nobody else can build is a document, not an alternative.

Second sourcing is not a contract term. It is an architectural property. You either bought a system with published interfaces at the layers that matter, or you didn’t, and that decision was made years before anyone sat down to negotiate.

Every purchasing organization in electronics tracks second-source status as a formal attribute of a bill of materials. A part with no second source gets flagged, escalated, and designed around. Now ask how many elements of your control system would survive that review.

Which reframes what a standard actually is. It’s not a compliance exercise. Not a badge on a datasheet. It is the specific mechanism by which an alternative supplier becomes possible at all.

What an Open Standard Actually Changes

O-PAS exists to put published interfaces at the layers of a control system where proprietary interfaces currently sit.

That sounds modest. It isn’t, because of what those interfaces enable once they exist:

• Application portability. Control logic is decoupled from the hardware it runs on. Compute can be refreshed without re-engineering the strategy, which is the single most expensive part of any migration and the reason so many of them get deferred until they become capital projects.
• Independent lifecycles. I/O, compute, applications, and system management evolve on separate clocks. One element reaching obsolescence stops being a system-wide event.
• Incremental replacement. The practical difference between a maintenance decision and a shutdown.
• Multiple suppliers to the same interface. Which is the definition of a second source, and therefore the definition of bargaining power.

The shift is in what “longevity” even means. A proprietary architecture makes it a question about a company: will this vendor still support this product in 2050? An open architecture makes it a question about the system: can this keep operating and evolving as products and suppliers change?

The second question is answerable. The first one never was.

Open Beats Proprietary

Proprietary architectures win the first decade. Standards win every decade after that. In computing and in networking, there is no case where a closed interface outlasted the open one that replaced it.

Three mechanisms, all of them visible in the history above:

• Replaceability means no supplier’s exit is your outage.
• Competition exists only where an interface exists for a competitor to build against.
• Innovation reach matters because the best work in cybersecurity, edge computing, analytics, and orchestration does not originate inside the largest automation vendors.

An open architecture lets you adopt it without betting the plant’s lifecycle on the company that made it.

“But I Want One Throat to Choke”

This is the strongest argument against open automation, and it deserves a real answer.

The answer is that open does not mean the end user becomes the integrator. Someone still has to qualify a multi-vendor combination, validate it, and stand behind it. That role exists in every mature standards-based industry.

For example, that’s what a general contractor does in construction, what a tier-one supplier does in automotive. The work doesn’t disappear. It just stops being bundled with the architecture.

There’s a second-order benefit that’s easy to miss. Proprietary expertise is fragile: scarce, expensive, and worthless anywhere else. Standards-based expertise is portable across suppliers, across organizations, and across your own workforce’s careers. When the people who know your system retire, the pool of replacements is the industry rather than one vendor’s certified list.

So you still have one throat to choke. The difference is you can change whose it is.

What to Ask Instead

Depending on who you are, you’re going to have different questions you’ll need to ask. Questions like:

• Control engineers. Can I replace the compute without rewriting the control application? Are the interfaces published? Could two suppliers deliver this function?
• Procurement. Does every critical element have a second source? Where one doesn’t, what is my actual bargaining power at renewal?
• Plant management. Can this system evolve without a shutdown? Can more than one organization support it?
• Executives. Which operational dependencies have no alternative supplier, and what is the exposure if one of them changes course?

That last one is the version of the question a board should be asking, and it has nothing to do with how large the vendor is.

Every Industry Learns This the Same Way

None of this is unique to automation, and none of it is new.

Shipping containers are a standard box with standard corner fittings, which is why one moves from ship to rail car to truck anywhere in the world without anyone renegotiating anything.

Railroads settled on a common gauge and a common coupler, and any car became interchangeable with any railroad’s.

Airframes are built to published interfaces, so an airline can buy the same aircraft with engines from three different manufacturers, and keep all three honest for twenty-five years.

Semiconductors settled on sockets and instruction sets.

Fire departments settled on a thread.

In every case the pattern is identical. An industry ran on incompatible proprietary connections. The incompatibility served the suppliers. Someone eventually paid for it, usually badly and usually in public. A standard got written. The standard outlived the companies that fought it.

And in every case the objection at the time was the one being made about open automation right now: our application is different, our requirements are more demanding, our stakes are too high to trust an interface we don’t control.

The Threads Didn’t Match

Baltimore had everything it needed on February 7, 1904. Engines from eight cities. Crews who had traveled through the night. Water in the hydrants and men who knew how to use it.

What it did not have was a common connection because six hundred variations were good business for the companies selling hydrants, and nobody had ever priced what they cost the city.

Thirty hours. Fifteen hundred buildings. Seventy blocks.

Your plant is not going to burn down over a proprietary protocol. The failure mode is not that extreme. It’s an obsolescence notice. The renewal you have no basis to negotiate. The upgrade that arrives as a capital project because incremental was never possible.

You have engineered redundancy into every part of that plant, and the last dependency with no backup is the company that sold you the system. No amount of that company’s size, history, or global footprint changes it. Tandem’s customers learned that. So did DEC’s. Corporate longevity was never the thing protecting them.

You have to choose an architecture that is built to outlast its suppliers. That is what a standard is for. That’s what O-PAS is for.

Components will change. Suppliers will change. Technology will change. Support providers will change.

The standards will remain.

Photograph: firefighters and hose lines on Baltimore Street during the Great Baltimore Fire, February 1904. Library of Congress, Prints and Photographs Division, public domain.