A Real-Time Operating System (RTOS) is often used in Embedded Systems to organize and simplify the scheduling and coordination of the “work” the processor performs. There are many types of RTOSes, varying dramatically in complexity, cost, features, etc. Although a complete list of the ways an RTOS can affect the Testing and Analysis of critical software is too large to discuss here, following are a few considerations …

Unit Tests

Structural Unit testing isn’t usually affected by an RTOS, since a relatively independent section of code is being examined. Be careful, however, if any data that the unit is processing is updated autonomously (for example, from an Interrupt Service Routine (ISR) or another task). If you’re using an In-Circuit Emulator (ICE) to execute the code you’re testing, be aware that hitting a breakpoint will usually disable all the interrupts in the system. This could be an issue if you were counting on timer values or other asynchronous data to be valid.

Functional / Stress Testing

Hopefully, you’ve considered the effects that your chosen RTOS has on your application long before final Functional Testing. Things like:

• How long (worst case) does it take to respond to an Interrupt?
• How long does it take to switch context from one task to another?
• How long does it take to process a message in a queue / mailbox / etc.?
• What is the resolution of the available timers … is this adequate for my task scheduling, event timing, etc.?
• What synchronization primitives (MUTEX, Semaphores, Event Signals, etc.) do I need to perform my scheduling and data-sharing properly?

These items don’t show up in a Functional Specification, but they can affect the performance of your system dramatically. A poorly chosen or poorly configured RTOS can cause:

• Missed hard-time deadlines
• Slow performance
• Missed events (e.g., missing key presses)
• Excessive Jitter in your output signals

Analysis

Analyzing your code is required to identify defects which Testing and Inspection can’t find. This is the area in which an RTOS’s effects are most visible.

Timing – If you must insure that hard real-time deadlines will always be met, you’ll need to fully understand the worst-case execution time of all the RTOS kernel calls your application makes. You’ll need to know the worst-case times for context switches, interrupt responses, and all the Inter-Process Communication (IPC) primitives you use.

How much time is required to access memory? If you’re using a virtual memory design with Demand Paging, perhaps you’d better lock down the memory used by the RTOS itself … otherwise you might incur a significant time penalty.

How long does the scheduler disable Interrupts? This will affect your Interrupt Latency ….

Re-entrancy tests – Which kernel calls are preemptible? Using non-preemptible calls in tasks (or ISRs) of differing priorities is a recipe for disaster – and a difficult problem to track down. You’ll need to make sure you prevent preemption around your use of these calls ….

Keep in mind that preventing preemption (by locking the scheduler or disabling interrupts) increases the blocking time for other tasks … make sure you account for this in your timing analysis. Likewise, you’ll need to know the (max) execution time of the non-preemptible sections of any kernel calls you use.

Stack Depth – As with any other 3rd-party code your application uses (like your compiler’s run-time library), you’ll need to know how much stack is used for each RTOS function your code uses. Make sure that number includes all the stack needed for any calls that RTOS function calls itself!

These are some of the ways that an RTOS can affect the Testing and Analysis of your code. Now … what other situations can you think of?