Sure, you can do it with a couple of analog electrical wires running from each valve and gauge to a central computer... You still have a computer and software (and a thick cable routing mess) and you only took some network protocol out of the attack surface (and you still need one to connect the workstations...)

You don't need to control everything centrally, you can compartmentalize your control (and also enforce limits)

Don't bring a thermal overrun detection to the central computer and have it shutdown a burner. Do this locally

I found the name for that concept: https://en.wikipedia.org/wiki/Subsumption_architecture - subsumption architecture puts some of the intelligence in the lower level systems. While the higher level controls can tell the lower level systems what it wants, it can't do things that the lower system determines is dangerous.

What difference does it make what kind of stack they're using?

A computer reading a bunch of serial lines can be a lot safer than one communicating with a bunch of nodes via TCP/IP. For starters, you're talking about a massive reduction in the amount of code needed.

I don't believe so: if that computer is reading a bunch of serial lines forgets to check the bounds of it's own buffer - then Houston's got a problem. That's all it takes.

At least we've got a set of verified, battle-tested, multi-platform TCP/IP stacks. More importantly, they have been built with generalisation in mind, meaning that a single implementation would encapsulate all of the use-cases.

But instead we've got those half-baked implementations of "oh my god, it takes me only a few hours to establish a radio link" protocols just increasing the attack surface.

You're speaking of a semi-technical solution to a problem that is directly caused by the race to the bottom in the manufacturing industry (they probably have installed that equipment a few decades ago, just before they fired the last of the employees).

> I don't believe so: if that computer is reading a bunch of serial lines forgets to check the bounds of it's own buffer - then Houston's got a problem. That's all it takes.

That's not even an argument. You can put a buffer overflow in anything. The key thing is this: the larger your code is, the more likely you are to have one. Using serial lines isn't going to make your code larger if you're just taking sensor readings or something. Far from it.

> At least we've got a set of verified, battle-tested, multi-platform TCP/IP stacks.

Think about this in terms of Linux or any other Unix or bigger RTOS, if that's most straightforward: in the kernel, there's much, much less code needed to make a UART appear as a device node than there is to make an entire TCP/IP stack and network PHY work. In the kernel it's all "battle-tested" code, none of it more so than the UART drivers. In terms of software quality, relying on the serial port and not using the TCP/IP stack means you're exposed to fewer potential errors simply because there's much, much less code being used.

(edit: the same basic idea applies if you're talking about something more sophisticated than a UART, like a CAN bus, which is still way less code than a TCP/IP stack)

> But instead we've got those half-baked implementations of "oh my god, it takes me only a few hours to establish a radio link" protocols just increasing the attack surface.

In terms of system engineering, you're exposed to fewer potential attack vectors if someone needs to plug into your system via a serial line versus accessing the system from anywhere you're connected to using the highly fragile resource of TCP/IP routing, but even connecting via a short-range radio link need not be much more complicated than that. Use a radio modem that connects via serial if you're using a real computer. Similarly, if it's a tiny embedded thing the radio is probably exposed via a serial interface.

Adding TCP/IP just adds code and attack vectors. That's fine if you truly need it...