Re: So... What are the alternatives? Was: I don't use an RTOS because...

From: Jonathan Kirwan (jkirwan_at_easystreet.com)
Date: 01/16/05 

Date: Sat, 15 Jan 2005 23:58:20 GMT

On Sat, 15 Jan 2005 14:35:57 -0800, Tim Wescott <tim@wescottnospamdesign.com>
wrote:

>I don't -- but all the SQA folks and software developers who I know
>who've ever worked on really life-critical stuff (fly by wire and
>medical) tend to view RTOS's with deep suspicion bordering on paranoia.

One has to be that way. Operating systems are usually targeted at a broad
audience for obvious marketing reasons -- more sales potential. But this also
means that the base of code, the number of run-time conditional blocks of code
that may or may not expose themselves readily, and the unused features or hidden
features used in the O/S present their own unique challenges (and extra costs)
for a critical application.

In some cases, the requirements for testing every possible branch of code that
*may* be executed and validating it becomes "more difficult" when you don't have
the source code for the operating system and therefore cannot easily adduce
exactly what different sections of code there are which may need validation.
Also, an operating system almost always exposes vastly more interfaces than are
actually needed by an application and their very presence in the code base
presents unnecessary extra risk to be managed. That all this is made more vague
and abstract in appearance by buying an "operating system" that is assumed
"correct" doesn't help things -- it just makes it more likely that someone isn't
going to expose on top of the table something that should have been examined
more closely. Diffusion behind a proprietary software barrier doesn't make
things "safer." In cases where the source code is fully available for the
operating system, it usually means a tremendous amount of possible sources of
risk that need to be analyzed/assessed and then tested.

This is one reason why I developed my own, that is compile-time customizable to
include only the minimum code and data space required for specific features.
The resulting emitted code carries the least possible impact, given the desired
features, and allows both a very close fit to needs as well as a low impact to
risk assessment, validation and then documentation/monitoring. The minimum
necessary impact.

Like floating point libraries, operating systems are both powerful tools that
raise the required bar of mastery for the engineers involved and can present
unseen dangers to those of less experience and background. Careless use of
either, without a very clear and hard-won understanding of the detailed areas
where things need be more carefully weighed, is just asking for trouble.

On the other hand, thread semantics and pre-emption semantics, for example, can
both also present a very powerful tool for simplifying much of the application
design and helping it to be more robust and understandable and maintainable.

> Basically it is _much_ easier to fully analyze the timing and
>inter-element interactions of a system based on a task loop than one
>based on an RTOS.

There is that. But it's sometimes hard to do (without an O/S of some kind) for
complex systems where there is similar code salted all about to handle the "real
time" aspects in the middle of other functions or where subroutines which are
periodically called to "proceed for a short time" which need to save and restore
state and go back inside the nested if-conditions so that they continue where
they left off... analyzing that and making sure you test all the nested areas of
code can be as bad as having the O/S around.

Like many things, experience helps in judging when, and when not, to use an O/S
and what form it should take. It depends.

Jon

Quantcast