Is there a difference between a real-time system and a deterministic one?

Question

At work, we are discussing the design of a new platform, and one of the top management types said that we need to run our current code base (C on Linux), but be in real time, because it needs to respond in less than a second to various inputs. I noted that:

• This point does not mean that it should be "in real time" only so that it needs a faster clock and more optimization in handling interrupts.
• One of the key points to consider is the OS used. They wanted to stick with embedded Linux, I pointed out that we need RTOS. Using Linux will prevent "real time" due to kernel / user memory tearing, so I / O is done through files and sockets that introduce a delay
• We need to determine whether this needs to be determined (we need to respond to input at <200ms 90% of the time, for example).

In fact, if point 3 is true, then it should be a real-time system, and point 2 is the biggest consideration.

I felt confident in the answer, but then I thought about it later ... What do others think? Am I on the right track here, or am I missing something?

Is there any difference that I miss between the "real time" and "deterministic" systems? And besides RTC and RTOS, am I missing something important that is required to run a real-time real-time system?

Look forward to some great answers!

EDIT:

Got some good answers so far, it seems like a little curiosity about my system and requirements, so I will add a few notes for those who are interested:

• My company sells units in ten thousand, so I don’t want to go for the kill for the price.
• Usually we sell the main processor board and independent display. A network of other CAN devices is also connected there.
• The board (currently) launches the devices and also acts as a web server sending the main XML documents to the display for end users.

The requirements are given here where management wants the display to be updated “fast” (<1s), however true IMO restrictions come from devices that can be connected via CAN. These devices are often engine-driven devices with requirements, including "must be responsive in less than 200 ms."

Answer 1

You need to distinguish between:

• Hard real-time mode : there is an absolute limit to the response time, which should not be violated (considered unsuccessful) - for example. this is suitable, for example, when you control robotic engines or medical devices where failure to meet deadlines can be disastrous.
• Soft real time : there is a requirement to respond quickly most of the time (maybe 99.99% +), but this is acceptable to limit the time that is interrupted from time to time, while the response is very fast on average. for example, this is appropriate when performing real-time animation in a computer game - the absence of a deadline can lead to a missed frame, but will not lead to a fundamental destruction of the gameplay.

Soft real time is easily available on most systems if you have enough equipment and pay enough attention to identify and optimize bottlenecks. With some configuration, it can even be achieved on systems that have non-deterministic pauses (for example, garbage collection in Java).

Hard real-time requires special OS support (to guarantee scheduling) and deterministic algorithms (so that after a scheduled execution the task is completed by the deadline). Obtaining this right is difficult and requires careful development throughout the hardware / software stack.

It’s important to note that for most business applications it is not required : in particular, I think that response time targeting <1sec is far from what most people consider “real”, a requirement. Having said that, if the response time is explicitly stated in the requirements, you can consider it soft in real time with a fairly free period.

Answer 2

From the definition of the real-time tag:

The task is performed in real time, when the timely completion of an activity is a functional requirement and a condition of correctness, and not just an indicator of productivity. A real-time system is one in which some (although perhaps not all) tasks are real-time tasks.

In other words, if something bad happens, if your system responds too slowly to meet the deadline, the system should be in real time and you will need RTOS.

A real-time system should not be deterministic: if the response time randomly varies from 50 ms to 150 ms, but the response time never exceeds 150 ms, then the system is not deterministic, but it is still in real time.

Answer 3

Perhaps you could try using RTLinux or RTAI if you have enough time to experiment. In doing so, you can store real-time applications on Linux, but realtime applications will be moved to the RTOS part. In this case, you will achieve a response time of less than 1 second.

Benefits -

• A large amount of code can be reused
• You can manually separate the tasks of real time and unreality and try to achieve the answer <1s according to your desire.
• I think the migration time will not be very high, since most of the code will be on linux

Just at the side level, be careful with the hardware drivers that you may need to run in real time.

The following RTLinux architecture can help you understand how this is possible.

Answer 4

It looks like you're on the right track with RTOS. Different RTOSs prioritize for various reasons: reliability, speed, or something else. You will need to find out if you need hard or soft RTOS and based on what you need, how your scheduler will be managed. One thing is certain, there is a serious difference between using a regular OS and RTOS.

Note. For a true real-time system, you might need tough event-based resolution so you can guarantee that your processes will run when you expect them too.