Search code examples
cembeddedreal-timedefinitiondeterministic

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

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".

Solution

  • 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.