Let us start with the premise that companies want their safety-critical real-time software systems to be deterministic.
This is not necessarily a given: in my experience, it is not necessarily a priority whether the software systems were deterministic or not. When there are lives at stake, it should be an obligation, not a choice. Legislation is in place in developed countries to enforce obligation, but unfortunately that does not always lead to best practice being employed.
Deterministic means that for a given sequence of input data, the output data will always be the same, i.e. it’s predictable. Such systems are very easy to test and often have a reputation for robustness.
Safety-critical systems are those that can harm human beings. Aviation, automotive, medical, railway etc. Compare with a washing machine or infotainment.
Real-time systems have a known, short response time.
Typically, such systems employ hardware interrupts and use event-driven methodology to provide quick responses.
But I assert that the increase in embedded system computing over the last 2 decades has made this technique unnecessary for all but the hardest of real-time systems.
In the 1980s, a real-time flight seat booking would take a couple of minutes. That was regarded as real-time by the industry, these can be called soft real-time systems.
Measuring the behaviour of a nuclear explosion - now that is a hard real-time system! Even interrupts are unlikely to be fast enough to handle those inputs before the sensors melt.
For many systems employing modern embedded processors, their performance and hardware assistance is such that employing a simple solution using polling instead of acting on interrupts more easily provides a deterministic solution.
For instance, I was assisting a company to produce an aircraft landing gear system that used ARINC 429 and CAN bus. Both devices contained hardware buffers, so acting on interrupt whenever a message was received or needed sending was unnecessary. It was sufficient to poll the input devices and place any messages in a queue. The messages were decoded and state data was updated. It was also sufficient to emit outputs after their timers had expired whenever those processes were resumed. This solution was very simple, very easy to test and robust. That translated directly into a low cost solution with low maintenance.
I can cite other examples.
These are modern soft real-time solutions: they behave like hard real-time solutions, but avoid the use of interrupts and the associated methodology. They are easier to test and less expensive to build and maintain than expected.
Providing deterministic safety-critical real-time software systems with today’s processors is actually very simple: just remove the real-time part of the solution.