The industrial automation industry is highly risk adverse. In some systems, like safety, this mentality is justified without proper migration plans. In other areas, it's alarming, like choosing to run a system on hardware that has been out of support for 30+ years without adequate spare parts.

Operation/Shop floor technologies (OT) are treated like mechanical equipment, "When it fails, we'll swap it out for a new one." Well, this isn't a motor, it has programming, and it interfaces with I/O sensors and devices.

The main challenge is the lack of knowledge and skills in modern technologies among technical staff and decision makers in industrial organizations.

A an aside, in my early days I hopped on a 5-hour flight and drove 6 hours to replace a failed hard drive in a Windows NT machine used as an HMI. Then a year later, replaced it and all the other clients with a vSphere stack. The local resources, both internal and external, were too intimidated to touch it.

I'd be in favor of a "reset" in automation, it feels like fighting city hall.

What is the real solution for highly complex technology like IT, as end times are coming?

It's a critical issue. Resources are wasted, and soon we won't be able to waste as much as we did, as the abundance era is coming to an end. The desire and need for higher efficiency through highly complex technology is only to increase, as the population gets older and older.

I can easily see mandatory IT training (like the current mandatory army training in some countries) and states standardizing certain technologies to avoid fragmentation and thus freezing progress, for good reasons. Like forbidding any database to be used in production except 3 most complete ones or banning all web frameworks except React and Svelte (arbitrary). It's not that they won't want progress, but they won't be able to afford progress and the resulting skill fragmentation in the IT workers while people are hungry and money is ever tighter.

I agree with everything you said... but there are a lot of areas in control system engineering that would benefit from having really robust hardware designs coupled with guaranteed correctness that Rust/Ada provide, and then all of the upside of all of the advanced control programming that is relatively easy in a modern programming language.

Beckhoff & B&R Automation are part of the way there. They both have some really slick portfolios. IMO, on paper, these are the two most advanced control system companies (with large sales volume).

I feel like a lot of people miss the point on PLC stuff.

“Stale PLC programming languages” might be stale and in need of a rework, but “rewrite in rust” entirely missed the value proposition. Memory safety is important, sure, but these systems aren’t usually ever allocating memory or taking actions that aren’t deterministic. PLCs usually operate in strict realtime environments. Like each operation contains a known number of clock cycles, and is timed to match physical “stuff” moving in the real world. To rewrite in rust, you’d need a flavor of rust where you can deterministically know the timing of ops and calibrate the timing of each branch of any control paths.

That said, there is a market for softer realtime PLCs and companies like Rockwell sell Windows IoT hardware- but they still contain a strict-realtime companion controller. Arduino is now selling a mountable PLC that can be programmed using their tools, but even they support traditional PLC programming languages.

Yep... I programmed PLC's for periods of my career. I could write about this until my fingers fall off, but in short:

Rust and C code can also operate in strict real-time embedded environments provided some basic rules are followed like "no dynamic memory allocation". This done all the time.

If one follows hard real-time coding standards like Misra C or "JPL real-time C" (and these standards can also be applied to Rust, Zig, Ada, etc.) the code will run deterministically on a given target... just like PLC code running is not necessarily any more deterministic than C code (no dynamic allocation) running on an embedded processor. In fact, many PLC's today run a "PLC code execution" engine on top of a real-time operating system like QNX (which I think is mostly C code). Even in some older PLC's, it is still C firmware that's interpreting and running the PLC code.

PLC programming "languages" (ladder logic, FBD, CFC) were designed for their programming audience, who are not software engineers. It is difficult to represent complex logic and numerical code in these languages and that limits the sophistication of algorithms that can be implemented on these systems. For instance: try writing a model predictive control routine in ladder logic; I think it could be done but I'd lose my remaining hair doing it.

PLC Structured Text is very similar to Pascal and pretty capable, but folks generally don't write model predictive control algorithms in Structured Text either.

It is hard to orchestrate multiple PLC to run as a cohesive, deterministic unit. The interfaces between PLC often need to be kept simple and sometime this communication is less real-time. Things are a lot more advanced in cluster computing.

The limitations of current PLC architectures is already a pain point for complex control system, like large robotic manufacturing lines or optimal control of HVAC in large buildings)... and it's going to get worse as performance demands increase. Again, as mentioned above, I think Beckhoff and B&R are further along the evolutionary path than others in the industry.