For the first I would like to mention that I'm newbie in real-time systems programming That's why I'm not sure if my questions are correct. Sorry for that But I need some help

Question in short: How to implement hard real-time software to be sure it meets hard deadlines? It is necessary to use some QNX features? Or it is just enough to write it for linux, port to QNX and it will be real-time by default?

Full question: We have implemented some complex cross-platform multiprocess software with inter-process communcation for Linux, Windows, Android and QNX. Programming language is C++, we use Boost and planty of other libs. Our software does it's job well and quickly but it is still prototype. For production purposes we need to do it real-time Some of our features have to be real-time and very robust because they are very important and safety of people that use our software may depend on them. They work pretty quickly - up to hundreds of milliseconds. But I'm not sure that our system is really real-time because of this fact (am I right?).

So there is a main question: how to modify our software to be real-time? I've googled a lot but I still have no idea how to do it.

Some additional information about our platforms: Linux and Windows we currently use only for testing purposes. Android - we still haven't decided whether we need it. QNX - is our target OS for production. I guess that answer for my next question is "NO" :) But is it possible at all to implenet cross-platform real-time software (for real-time OSes (RTOS) as well as for general purpose OSes (GPOS) )?

Possibly we need to make our efforts to implement all real-time features only for QNX? But I still don't understand how to do it. Could somebody shed a light on this question?

  • 55
    If your project is safety-critical, you really need someone who understands real-time systems on your payroll. – Blrfl Jan 5 '17 at 10:48
  • 18
    Real-time system is how precise is your code in terms of execution time, not whether it is fast or slow. – Pagotti Jan 5 '17 at 10:55
  • 22
    My feeling is that you don't modify an existing software to become real-time, you design and write from scratch a new software, taking into account explicit real-time constraints. And your question is too broad: what exactly is your software doing? On what precise kind of real-time system, for what concrete sort of embedded system (what purpose: inflight infotainment in commercial aircraft is not the same as nuclear reactor control)? You need to edit your question to be much more concrete, precise and motivate it. – Basile Starynkevitch Jan 5 '17 at 12:14
  • 24
    Reread @Blrfl's comment. And then reread it again, and again, and again until you hire a person with the proper experience. Or ensure that your liability insurance is paid-up. Because if you're creating safety-critical software with real-time requirements and don't have that experience, you are being criminally negligent. – kdgregory Jan 5 '17 at 13:05
  • 4
    You asked: "is it possible at all to implement cross-platform real-time software (for real-time OSes (RTOS) as well as for general purpose OSes (GPOS) )?" My guess is No, otherwise the RTOSes would not exist. "Cross Platform" is pretty similar to "Holy Grail". – user251748 Jan 5 '17 at 14:55

Fast does not mean real-time and real-time does not mean fast.

Real-time means that the date when outcome is delivered is as important as its value. In other words, if the outcome has a correct value but is delivered too early or too late, then the overall result is wrong.

For instance, think of a video player. If video frames are not displayed at the right rate, users won't be satisfied. Worse if image and sound are not in sync.

This example shows that some real-time applications can be implemented on current general purpose OSes.

But there is a distinction between hard real-time and soft real-time with respect to the consequences of a deadline miss: in soft real-time systems, this is just an annoyance or a degraded service (think of freezed images during several seconds in the video player example), whereas it is a (potentially catastrophic) failure in hard-real-time system, such as in a nuclear power plant.

| improve this answer | |
  • Mr. mouviciel, Thanks for answering my question We need some features to be hard real-time another can be soft real-time I don't understand how to write software to guarantee deadlines? Could You shed a light on this question please? – user172825 Jan 5 '17 at 11:03
  • 7
    @user172825 - Answers to this question cover shelves of libraries. Starting points may be googling "real-time programming", related wikipedia article or tutorials of RTOSes such as QNX or RTEMS. – mouviciel Jan 5 '17 at 12:04
  • It was the most complicated question to me. I found a lot of large books regarding this topic. But I hoped it is possible to explain it in couple of sentences. :) – user172825 Jan 5 '17 at 13:26
  • 5
    "There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton OK, and real-time. There, one sentence explains why it can't be explained in two sentences. We now return you to your regularly scheduled programming. – user251748 Jan 5 '17 at 14:41
  • 1
    I find calling "hard real-time" "deterministic time" usually helps get the point across to people. – whatsisname Jan 5 '17 at 16:40

As @mouviciel already said, real-time and fast are really two independent properties, even though many real-time deadlines imply that a relatively fast response is needed.

When writing real-time software, the most important property next to a correct response is that you can accurately predict how fast the response will be given. For hard real-time features, you must even be able to guarantee that the deadline will be met under all possible conditions short of a complete power failure.

Typical sources of unpredictability can be found in

  • Dynamic memory allocation and garbage collection
  • (Higher priority) interrupts
  • The scheduler in the OS
  • Dynamic creation and destruction of objects
  • Large amounts of conditionally-executed code

I am not saying that you must avoid those areas (as you most likely can't), but you must be aware how they can affect the ease with which you can predict that you will meet the real-time deadlines for the relevant features.

| improve this answer | |
  • 4
    In the conditionally executed code be careful of amortized algorithms, where most of the time the operation is cheap but can occasionally turn into a much more expensive operation, for example when a vector add when needs to realloc. – ratchet freak Jan 5 '17 at 11:59
  • 2
    In some cases, you may need to do WCET analysis, predicting execution time to the millisecond – Basile Starynkevitch Jan 5 '17 at 12:17
  • 3
    @user172825: Profiling can help, but much of it comes down to experience and knowing the language and libraries really well. – Bart van Ingen Schenau Jan 5 '17 at 12:24
  • 3
    Profiling may not be good enough if you have hard real-time requirements. If run time is not fully deterministic, then profiling it may give you the impression that it will always complete by the deadline, when in fact it only meets the deadline 99 times out of 100. If you have a hard real-time requirement, it needs to meet it 100 times out of 100. – James_pic Jan 5 '17 at 16:37
  • 2
    @user172825 Real-time is for software what brain surgery is for medicine - you need a lot of experience and skill to pull it off correctly and you have to be really, really sure of what you are doing. Those projects are better made under supervision of a skilled professional of the area. They are not something you can throw to a regular developer and say "make this thing work as a real time system". – T. Sar Jan 6 '17 at 11:16

I suppose the two-sentence explanation of realtime is that a realtime system is designed to understand and control the worst-case response time from inputs changing to outputs changing.

That requires an analysis that covers the whole system. Let's say you have a trivial system that consists of a USB keyboard and a brake servo. What responsiveness can you achieve with this system? You might have to consider:

  • input polling frequency, and how long this takes
  • input interrupt latency
  • operating system context switch time once you have an input event
  • operating system prioritization of tasks
  • avoiding use of dynamic allocation or virtual memory in the program, to avoid unpredictable response delay or OOM events
  • avoiding use of garbage collection
  • avoiding use of O(n) or worse algorithms with high or unpredictable N (does loading a very large playlist into your car's entertainment system slow down its braking response?)
  • consider disk or network latency (e.g. use of CAN bus in cars)
  • output control latency

In this kind of environment there's also usually special consideration for reliability, such as the MISRA C standards.

| improve this answer | |
  • Is it also true that being realtime includes consideration of whether an operation is deterministic, possibly recursive, or even computable at all in some cases? – user251748 Jan 5 '17 at 15:18
  • Yes, all of those would be "unbounded". Recursive algorithms can be allowed provided their stack usage has an upper bound imposed on it. – pjc50 Jan 5 '17 at 15:27
  • 5
    avoiding use of garbage collection - This should be avoiding use of non-deterministic memory management. Garbage collection can be done in real-time and manual memory management is not necessarily deterministic (see the typical malloc implementation for C). – 8bittree Jan 5 '17 at 16:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.