DO-178B, DO-178C and Worst-Case Execution Time

In the world of aerospace software engineering, development is guided by the objectives of DO-178B (or the more recent update, DO-178C). Behind this are a number of committees, and through their discussions they translate their intent into measurable objectives. Understanding this intent is a key part of successful aerospace software development.

What is the primary intent of DO-178B software development?

The primary intent of DO-178B software development is traceable compliance. A requirement is placed on the software and through a number of stages of commitment and analysis a software implementation is created that complies with that requirement. Along the way, additional potential errors arising from those commitments are assessed and mitigated. In this view, the software can be said to be "designed not to fail".

What does DO-178B say about worst-case execution time?

Delivering its output at the wrong time (usually, this means "too late") is one way in which software can fail to comply with the requirements. Ideally each output would have an associated delivery time with respect to the major cycle of the system, but in practice each task in the system has an assigned budget, or deadline, and as long as each output is produced before the deadline is reached, the outputs are guaranteed to be timely. In objective 6.3.4f, a number of reviews and analyses are listed to show accuracy and consistency, including that of execution time, and in 6.4.3a the object refers to the ability of requirements-based hardware/software integration testing to reveal problems with execution-time requirements.

How does this relate to worst-case execution time analysis?

Showing that an output will be produced before some deadline is reached is no easy task. Worst-case behaviour must be reliably reproduced, and reliably measured or calculated without undue pessimism. In many cases, software and hardware features are restricted and carefully designed to ensure that such measurements are feasible. Such restrictions, however, eventually buckle under the pressure of additional functionality to be squeezed into the embedded system. The expanding variety of application structures, hardware features and embedded operating systems means that the intent of airworthiness regulators becomes increasingly difficult to capture into measurable objectives.

A quick guide to the DO-178C update

Bearing in mind the difficulty of translating intent into measurable objectives, one might expect that DO-178C provides no additional guidance on worst-case execution time behaviour. However, the update does provide several clarifications that we have acted upon:

• 6.3.4f comes under "reviews and analyses" but refers to concepts such as worst-case execution timing, resource contention and interrupt conflicts that are difficult to assess in a modern application. In DO-178C, the entire section 6.3 is given additional text in its introduction to point out that there are items here that could be assessed through testing. Specific guidance has been added in 6.3.4f to indicate that the effects of compiler options, linker options and hardware features must be taken into account when examining worst-case execution time. Our own recommended workflow for execution time analysis includes examination of execution time distribution to help identify where to investigate the source code and object code.
• 11.20i - the new name for 11.20d - now explicitly mentions "timing margins including worst-case execution time". There should be some explanation in the corresponding section of the Software Accomplishment Summary to justify the particular worst-case execution time method chosen. Our stand-alone recommended workflow for execution time analysis can be referenced or incorporated here as needed.
• The accompanying document DO-248C (ED-94C) provides some additional guidance on problematic issues in determining worst-case execution time under FAQ#73. It indicates the preference for restrictions in the hardware and software architecture to improve the predictability of execution times and to simplify worst-case analysis. RapiTime's detailed execution time measurement and visualisation provides further insight into predictability of the execution times - either showing that the desired predictability is present, or revealing the specific parts of the code where the predictability is absent. This view of the software timing behaviour represents an excellent starting-point for further investigation.
• FAQ#73 also indicates that, while the software requirements data and software design description objectives have not changed, the requirements should include information on worst-case execution time (deadline or budget in the requirements, resource limitation information in the design description). The method for measuring the execution time should be presented within the design description. If RapiTime is used for worst-case optimisation or jitter reduction, those specific workflows should also be presented here. Our products ship with user guides that include details of these specific workflows, ideal for referencing from the design description.

I am presenting on test effectiveness for WCET tool qualification at Avionics Europe in 2013. Keep an eye out for more on this topic early in the New Year.