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

Boise

A real-time computer implies a hard time constraint, not one that's sufficient to meet only 90% of the time. Is the time constraint a hard one or not? That determines which kind of system you need. – Tarttan

I would say it depends on the expected volume for you platform. It's a million times easier and faster to keep with your existing linux code and just buy a very fast processor than trying to port to an RTOS and live without things like address space protection. But if product is very high volume, then cost of the CPU is more of a consideration. – Hedge

@Hedge - the problem there is even with the fastest processor there is no guarantee that a constraint will be met. As I understand things, a system with a uC that has a RTC and a high clock rate will(could) be bottlenecked by the OS. – Boise

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.

Scientist

+1 for the hard/soft distinction. Another good example for hard real-time systems are the avionic/flight-control systems on aircraft, where it is crucial that deadlines are met. – Justinajustine

+1, An interesting point, I like the definition adjustment. We do have SOME "hard realtime" constraints in the system. Motor control for our EEV (electronic expansion values) for example, but not all "hard" requirements... perhaps a split architecture is a better idea using two "lessor" processors one with RTOS for the motor control. Is your take on HW requirements simply a RTC (to feed the RTOS) and sufficient computing power? – Boise

Essentially yes, a high-resolution clock is the key to real-time hardware. It's the job of the RTOS to schedule in such a way that ensures deadlines are met for given computing power. Technically, if the requirements are loose enough, a high-resolution clock isn't even necessary, with the RTOS handling scheduling. – Justinajustine

Split architecture is often a good idea. Most RTOS should support this: write the hard realtime stuff in C with RTC / realtime scheduling, write the rest of the system in a soft-realtime style with Java or whatever other stack is convenient for you. This means you won't need to worry about using non-deterministic algorithms on the soft realtime side. – Scientist

Eeww - motor control. I would always reach for an embedded uC for this and manage/monitor from the 'desktop' OS. Apart from your real-time requirements, motor/solenoid/whatever controllers are connected to external wiring, often installed by a 3rd-party contractors, and later subject to err.. 'unintentional high energy injection' by other contractors working on other jobs. It's much easier/cheaper to replace the charred, carbonized remains of a cheap, embedded board than install a new desktop, restore from backups, (if they've done any), and recommission the system. – Disremember

@Justinajustine - good example. The avionics in the cabin do not try to control the engines directly, the real-time stuff is done by a dedicated controller on each engine. – Disremember

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.

Smaragd

shouldn't a real time system be, or have the capability to be, deterministic by definition? – Boise

No, determinism is not a requirement. Consider a system where if interrupt A arrives before interrupt B the system response can be calculated in 50ms, but if interrupt B arrives before interrupt A it takes 150 ms to calculate the system response. Then if the interrupt arrival times are random, the system response time is random, but bounded, and the system is still real time. – Smaragd

if something bad will happen you're in trouble, no matter what OS you have. Even a RTOS will get in trouble if it is run out of borders by means of too many tasks, poorly written code etc. Thus, it doesn't matter all that much whether soft-, hard, or even non-realtime; guaranteed 50ms can be obtained on windows easely without much effort, But you may not be able to do backups or play ego-shooters. However, would you do these things on an RTOS? – Eurythermal

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.

Nicker

+1 Interesting idea, I haven't used a RT Linux before... how does the RT scheduler feed into the non-real time scheduler, is it just seen as "higher priority"? – Boise

The idle task in the RT Linux is the linux (non-RT) operating system. So eventually, when there is no real-time task running in RT-Linux, the linux gets chances to run and it executes normally. – Nicker

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.

Cantatrice

Answer 5

RTOS or real-time operating system is designed for embedded applications. In a multitasking system, which handles critical applications operating systems must be 1.deterministic in memory allocation, 2.should allow CPU time to different threads, task, process, 3.kernel must be non-preemptive which means context switch must happen only after the end of task execution. etc SO normal windows or Linux cannot be used. example of RTOS in an embedded system: satellites, formula 1 cars, CAR navigation system.

Embedded System: System which is designed to perform a single or few dedicated functions. The system with RTOS: also can be an embedded system but naturally RTOS will be used in the real-time system which will need to perform many functions. Real-time System: System which can provide the output in a definite/predicted amount of time. this does not mean the real-time systems are faster. Difference between both : 1.normal Embedded systems are not Real-Time System 2. Systems with RTOS are real-time systems.

Kacykaczer