How do you put the "real-time" into a real-time operating system?
There are lots of products on the market claiming to be real-time operating systems. Wikipedia alone lists 149. But what does it mean to be a real-time operating system?
What is a real-time operating system or RTOS?
An RTOS is an operating system which must execute tasks within specified time constraints. We call this the "worst-case response time", which is different from worst-case execution time (WCET). For more details see our blog on the difference between execution times and response times.
How do we find the worst-case response time?
It depends on the scheduling approach that the RTOS uses. For example, fixed priority pre-emptive scheduling as used by the Automotive RTOS standard AUTOSAR OS (described in the ISO Standard 17356), and its predecessor OSEK OS allows schedulability analysis techniques, for example Rate-Monotonic Analysis (RMA) or Deadline Monotonic Analysis (DMA), to be applied. Using for example the RMA approach, the worst-case response time for a task can be computed by applying the following values to a formula:
- Period of all tasks/interrupts (i.e. how often they are executed);
- Worst case execution time of all tasks/interrupts;
- Priority of all tasks/interrupts;
Refinements to the basic analysis have also been proposed. These also include such details as:
- Blocking time for all tasks/interrupts;
- Deadlines for any tasks.
Further details of the analysis can be found at www.embedded.com.
Finding the worst-case execution time of the tasks and interrupts isn’t enough, of course. It’s also important to demonstrate that your RTOS has an upper bound for the execution time of any of its operations (including context switches and interrupt handlers). Performing DMA on your tasks isn’t enough if your RTOS has edge cases that introduces significant time spent handling task switches (for example).
Ask your RTOS vendor for good timing data on RTOS operations. RapiTime can help to determine the WCET of your tasks. If you have access to the source code of the RTOS, RapiTime can help there too.
White papers & webinars
Want to learn about common challenges and solutions in critical software verification? Our white papers and webinars may be just the thing:
- Multicore Timing Analysis for DO-178C
- Eight top code coverage questions in embedded avionics systems
- Seven Roadblocks to 100% structural coverage (and how to avoid them)
- Automating WCET Analysis for DO-178B & DO-178C
- Three steps to avoid software obsolescence in avionic systems
- CodeTEST® Replacement with RVS
- Multicore Timing Analysis for DO178 Projects Webinar
- Multicore for ISO 26262 Webinar