Real time operating systems: black box or open source?

Most of the software that most of us use most of the time is obtained as a binary executable. The program may be run and does what it does, but the user has no knowledge of its inner workings and no opportunity to modify its functionality. And all of this is fine. For example, I am writing this posting on my PC using a Windows program. Later, I will probably review it on my iPad using the corresponding app. The two programs are probably written in different languages by different teams. Do I care? Nope. The important thing to me is the data [my text] and what the software does with it.

In the world of embedded software, things are a bit different …

The difference is not with programs that are run on a PC – compilers, debuggers etc. These are also normally provided as binary executables and used in much the same way as other application software. Of course, there are open source options, but a large proportion of users will never dirty their hands on the source code. The different approach applies to software IP [intellectual property] – code which is to be incorporated into a design. The best example of such IP is a real time operating system [RTOS].

Broadly speaking, RTOS products are either supplied as a linkable binary of some form [which is a “black box” – the user has no visibility of its internal function] or come in source code form [which may be perused and/or modified at will]. There is an intermediate option, where the code comes as source, but it is “scrambled” to render it unreadable to humans [i.e. effectively rendering it a black box, but with easier compile-time configurability].

Many developers feel strongly that having source code is essential and may cite some clear advantages:

• Having the source is a good aid to understanding what the RTOS API calls do and how they do it, and how the scheduler works.
• As tech support maybe be needed urgently, having the source code means less reliance on others parties [like the RTOS vendor].
• There is the opportunity to customize the RTOS to the specific needs of the project.

This all sounds logical, but I would counter that having the source code can have some downsides:

• Habitual access to the source code may discourage using the supplied manuals, which are likely to be a much richer source of information.
• Understanding the internal workings of an RTOS is a specialist skill. Can you afford to support such expertise?
• Is there a strong reason why treating the RTOS as a black box is bad? Assuming it does what the manual/specification says, why do you need to know more? Hardware developers commonly us integrated circuits without any information on their internal functions.
• Although it is superficially attractive to be able to customize an RTOS for specific purposes, it is a dangerous path. The result can be multiple versions of the OS, which are undocumented. When a new OS version comes available, it is a big challenge to re-apply the customizations.

Of course, you can select a product, where source code is normally provided, like Nucleus RTOS, and lock the source away for “emergencies” …

If you would like further, more detailed guidance on selecting an RTOS, you may find this white paper or this archived Web seminar helpful.