Choosing an RTOS: Level C, D & E applications matter too

The nature of the standards is such that achievement of certification for a system gets progressively more difficult as each more demanding software level is encountered. Commercial common sense therefore dictates that the safety related requirements associated with each system should be as achievable as possible, such that the outcome of the system safety assessment minimises the software level required.

A quick scan of DO-178C Table A-7 (Verification of Verification Process Results) emphasises the point. The extra demands on Level A systems from this table alone in the form of MC/DC coverage, Data and Control Coupling, and Verification of Code untraceable to Source Code, represents a very considerable overhead.

Level A systems are necessary but relatively few and so for the most part, these things don’t matter. Do they?

Reliability in lower software level systems

Much as they yield impressively reliable systems, the whole point of minimising DO-178C software levels is that they can rarely be justified unless they are obligatory. However, all commercially developed software is critical one way or another. For example, even an in-flight entertainment system needs to work reliably if the vendor’s future in business is to be assured. It therefore follows that reliability is a requirement for all parts of any system, whether developed in house or sourced externally, because any failure will reflect on that vendor.

Consider a real time operating system. Some RTOSes, such as LynxOS-178 (Figure 1), are designed specifically for use in highly critical systems up to software level A and can be supplied with artefacts to provide evidence of compliance.

Figure 1 - Specialist RTOSes such as LynxOS-178 are of very high quality, but are designed for the specific needs of high software level applications

Even so, the code involved in any certifiable system generally has to be subject to scrutiny in the context of that system. Consideration of the Ariane 5 failure on June 4, 1996, can help explain why.

Ariane 5’s difficulties were the result of an integer overflow which occurred in software proven to be reliable in Ariane 4. The code at fault formed part of the Inertial Reference System (SRI), but because it was now exposed to different physical conditions – acceleration, mass and the like – its previous use counted for nothing.

That puts the award of FAA Reusable Software Component (RSC) status into context, because it suggests that despite these potential pitfalls, the FAA is satisfied that that if instructions are followed then the software component will ALWAYS behave as expected. For alternative software components without RSC acceptance, the FAA will require justification in each and every case.

In short, the FAA is satisfied that if used as the designers intended, an RSC RTOS will always behave as expected. Whatever the software level, in an ideal world surely everyone would seek that level of assurance as the foundation for their project.

Commercial & functional considerations

Unfortunately, back in the real world, such proven software comes at a premium. Vendors often help to address that by offering certification artefacts as an option. If there is a requirement for an RTOS which has been rigorously proven to work but there is no requirement for documentation of that proof, then opting to forgo the artefacts can represent a significant saving.

But there are other considerations aside from cost. RTOS designed for highly critical applications are likely to have specific features for their purpose such as a minimisation of code base to ensure economy of certification, and adherence to ARINC 653 (a software specification for space and time partitioning). In short, they may be high quality but they are not necessarily ideal for a more general purpose, especially considering that many less critical applications are likely to need both richer functionality and access to third party COTS products in order to be developed cost effectively.

Figure 2 - A more general purpose RTOS such as LynxOS 7 need not be encumbered by the demands of high software level certification, but can benefit from the same high quality approach to its development

However, the professional capabilities required to develop an RTOS certifiable to DO-178C level A, particularly with FAA RSC acceptance, should not be underestimated. Such a level of achievement demands a mind-set, approach and a set of defined processes which are not simply abandoned when an RTOS development team turns its attentions to more general purpose RTOS such as LynxOS 7 (Figure 2). In many ways, such an RTOS represents the best of both worlds because the quality remains assured, and yet the functionality is not encumbered by the understandably cautious requirements of higher certification levels.

By comparison with open source code of unknown provenance, that represents a sound engineering case and a sensible commercial compromise for any cost/benefit analysis where it is imperative that a system should work reliably, whether it is safety critical or not.