Is there a difference between a real time system and one that is just deterministic?

Question

At work we're discussing the design of a new platform and one of the upper management types said it needed to run our current code base (C on Linux) but be real time because it needed to respond in less than a second to various inputs. I pointed out that:

1. That point doesn't mean it needs to be "real time" just that it needs a faster clock and more streamlining in its interrupt handling
2. One of the key points to consider is the OS that's being used. They wanted to stick with embedded Linux, I pointed out we need an RTOS. Using Linux will prevent "real time" because of the kernel/user space memory split thus I/O is done via files and sockets which introduce a delay
3. What we really need to determine is if it needs to be deterministic (needs to respond to input in <200ms 90% of the time for example).

Really in my mind if point 3 is true, then it needs to be a real time system, and then point 2 is the biggest consideration.

I felt confident answering, but then I was thinking 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'm missing between a "real time" system and one that is just "deterministic"? And besides a RTC and a RTOS, am I missing anything major that is required to execute a true real time system?

Look forward to some great responses!

EDIT:

Got some good responses so far, looks like there's a little curiosity about my system and requirements so I'll add a few notes for those who are interested:

1. My company sells units in the 10s of thousands, so I don't want to go over kill on the price
2. Typically we sell a main processor board and an independent display. There's also an attached network of other CAN devices.
3. The board (currently) runs the devices and also acts as a webserver sending basic XML docs to the display for end users

The requirements come in here where management wants the display to be updated "quickly" (<1s), however the true constraints IMO come from the devices that can be attached over CAN. These devices are frequently motor controlled devices with requirements including "must respond in less than 200ms".

Answer 1

You need to distinguish between:

• Hard realtime: there is an absolute limit on response time that must not be breached (counts as a failure) - e.g. this is appropriate for example when you are controlling robotic motors or medical devices where failure to meet a deadline could be catastrophic
• Soft realtime: there is a requirement to respond quickly most of the time (perhaps 99.99%+), but it is acceptable for the time limit to be occasionally breached providing the response on average is very fast. e.g. this is appropriate when performing realtime animation in a computer game - missing a deadline might cause a skipped frame but won't fundamentally ruin the gaming experience

Soft realtime is readily achievable in most systems as long as you have adequate hardware and pay sufficient attention to identifying and optimising the bottlenecks. With some tuning, it's even possible to achieve in systems that have non-deterministic pauses (e.g. the garbage collection in Java).

Hard realtime requires dedicated OS support (to guarantee scheduling) and deterministic algorithms (so that once scheduled, a task is guaranteed to complete within the deadline). Getting this right is hard and requires careful design over the entire hardware/software stack.

It is important to note that most business apps don't require either: in particular I think that targeting a <1sec response time is far away from what most people would consider a "realtime" requirement. Having said that, if a response time is explicitly specified in the requirements then you can regard it as soft realtime with a fairly loose deadline.

Answer 2

From the definition of the real-time tag:

A task is real-time when the timeliness of the activities' completion is a functional requirement and correctness condition, rather than merely a performance metric. A real-time system is one where some (though perhaps not all) of the tasks are real-time tasks.

In other words, if something bad will happen if your system responds too slowly to meet a deadline, the system needs to be real-time and you will need a RTOS.

A real-time system does not need to be deterministic: if the response time randomly varies between 50ms and 150ms but the response time never exceeds 150ms then the system is non-deterministic but it is still real-time.

Answer 3

Maybe you could try to use RTLinux or RTAI if you have sufficient time to experiment with. With this, you can keep the non realtime applications on the linux, but the realtime applications will be moved to the RTOS part. In that case, you will(might) achieve <1second response time.

The advantages are -

• Large amount of code can be re-used
• You can manually partition realtime and non-realtime tasks and try to achieve the response <1s as you desire.
• I think migration time will not be very high, since most of the code will be in linux

Just on a sidenote be careful about the hardware drivers that you might need to run on the realtime part.

The following architecture of RTLinux might help you to understand how this can be possible.

Answer 4

It sounds like you're on the right track with the RTOS. Different RTOSs prioritize different things either robustness or speed or something. You will need to figure out if you need a hard or soft RTOS and based on what you need, how your scheduler is going to be driven. One thing is for sure, there is a serious difference betweeen using a regular OS and a RTOS.

Note: perhaps for the truest real time system you will need hard event based resolution so that you can guarantee that your processes will execute when you expect them too.