> ERICI's plan to run Linux under a real-time hypervisor...
Why plan? It's working right now, alongside QSOE/N. Resources nicely partitioned: graphics controller and UFS storage for Linux; NVMe, Ethernet UART for QSOE. Please see the demonstration video.
As I said, it's been working since the 01990s. Barabanov's original research on what would become RT-Linux and Yodaiken's paper about it were 01996. L⁴Linux was 01997. Heck, MERT was 01975. And, I'm sorry, but I'm not going to watch your demonstration video.
Excuse me, but what Barabanov, Yodaiken and all the stuff you mentioned have to do with the subject?
Have you noticed that Linux on the diagram is a general-purpose OS, used for non-critical tasks? Or, refusing to watch the video, you refuse also to see what's actually depicted on the page?
> it's been working since the 01990s
What's been working since the "01990s"? What hypervisor in 1990s drove real-time OSes on industrial computers alongside general-purpose OSes, providing full resource isolation?
What "that approach"? In the scope of the initiative, we are talking about full isolation of operating systems (which is possible with the hypervisor). I still don't understand why are you offering me to read about L4 and RT-Linux.
(QSOE/L does use seL4 as one of its possible kernels. But I guess you also haven't noticed this, because, perhaps, you don't care.)
The approach you were asking about: using a hypervisor to drive real-time OSes on industrial computers alongside general-purpose OSes, providing full resource isolation. I was answering your question as to which hypervisor was used. Sorry that wasn't clear.
You do have valid points with the "better to avoid mixed criticality when possible" and "isolate the most latency sensitive compontents on dedicated hardware".
I work in embedded software and I have some insight on why the reality often looks very different from this:
Software "cost" works differently. In a startup environment, you can spread the fixed costs for software development on thousands of installs (or even more). Automation software is very different, and solutions are often bespoke; even if you're building and selling machines, the numbers will be much lower than for consumer stuff.
This means that fixed costs for software development matter much more, and that hard developer productivity (as in: how many factories can your PLC programmers automate per year) is much more important. Vendoring dependencies is much more costly, splitting your codebase over multiple subsystems is less desirable (=> overhead for general development, update, configuration management, redundant subcomponents, slower iteration), heterogenous systems are very undesirable (because specialized employees are more expensive to manage and less flexible).
This is why much of the industry is so willing to shell out for "overpriced" PLC controllers (when freely programmable MCUs can be had for cents), proprietary frameworks and what you might perceive as obsolete garbage tooling for HMI/cloud integration: All those things help to build solutions that are "good enough" with less programmers, less training, less specialization and thus, crucially, less software-fixed-costs (that you wouldn't be able to recoup).
One other thing: software being formally correct vs. reliable/robust is much more orthogonal in practice than you might assume, and industry typically cares more about the latter. My perspective is that formalizing/certifying software is (overly) concerned with eliminating lower risk holdouts (think: proving latency bounds on memory allocation or somesuch), while "robustifying" software looks at "actual highest risk" parts first (sanity checking requirements/specifications, avoiding pitfalls for users when configuring/operating your system, fixing false positives).
That makes a lot of sense, and I greatly appreciate you sharing your experience. It helps me to understand why the industrial automation world looks the way it does.