RTOS design and embedded system development

Real-time operating systems are either a solved problem or a backwater of engineering design. Threads, semaphores, mutexes, some basic I/O, priority scheduling all of this has been more or less standardized in the  POSIX 1003.13 smaller profiles (51,52) for many years. The basic programming model has not changed in years. Even FSM’s original RTOS and QNX, the two most unusual RTOS’s, are pretty similar from a programming point of view except for the split between real-time and non-real-time in our old product.  My suspicion is that the programming model provided by these RTOS designs can be replaced by something better mostly because I think synchronization is a painful and error prone exercise that only gets worse as systems become more complicated. On the other hand, although many of our customers really loved it, and I think it was a huge advantage, the split mode approach in the old RTLinux* was a difficult learning experience for a lot of people.

Consider a simple design:

  1. Task A: collect data from an Analog/Digital converter, sampling at rate 1/t seconds and filling a small buffer (1/t)*n seconds.
  2. Task B:  Aggregate A data and produce 3 streams of processed data that are functions of the input data and some settings.
  3. Task C:  produce control data from the processed data at an output rate of 1/t2 seconds
  4. Task D: provide a secure internet port which will process requests to interrogate data, to setup data push at some rate maximum 1/t3 pushes per second and update the settings with worst case delay from arrival of input packet to reset of 1/t4 seconds.
  5. Task E: operate a touch screen display that has some of the same functionality as task D

That seems like it should be straightforward, but it’s not: it’s a one year project that has a 70% chance of failing. Making sure shared data is efficiently and correctly shared, validating that the scheduling and timing is ok, and optimizing for hardware limits and power are all hard.  And that seems wrong because there is nothing in such a project that has not been done thousands of times before.  As the electric power industry stumbles into modern software based control,  the slow development times and poor reliability of products developed under this model is a serious problem.

* NOTE: RTLinux is a trademark of WindRiver Systems.

[note: edited to remove garbage characters]