Multicore Timing Analysis for DO-178C

The multicore revolution and DO-178C

Since its inception in the 1980’s, the guidance offered by DO-178 and its successors has served the avionics industry well. DO-178B, published in 1992, and more recently DO-178C (2011), have kept pace with changes in avionics hardware by ensuring that their guidelines remain generic and relevant regardless of software architecture, programming language, etc.

Since DO-178 was first published, the embedded computing world has seen many significant changes, for example Moore’s Law having driven advances such that the computing power of modern cellphones now exceeds that of the Apollo 11 lunar lander many times over. One of the most significant changes is the innovation and use of multicore processors. With a higher density of silicon, these systems offer increased performance per unit area, which is critical to meet the needs of modern avionics systems. Their use comes at a price, as unlike single core systems, they offer neither a deterministic environment nor predictable software execution times.

In response to the increased use of multicore processors, the Certification Authorities Software Team (CAST) published Position Paper CAST-32A named ‘Multi-core Processors’ (often referred to as just ‘CAST-32A’). This paper identifies topics that could impact the safety, performance and integrity of airborne software systems executing on multicore processors and provides objectives intended to guide the production of safe multicore avionics systems.

For example, and of particular relevance to this paper, objective MCP_Software_1 requires that evidence is produced to demonstrate that all hosted software components function correctly and have sufficient time to complete their execution when operating in their multicore environment. This white paper outlines the challenges in demonstrating this and presents a practical solution to do so, which is compliant with DO-178C and CAST-32A.

Many OEMs are concerned about the long-term component availability of single core processors. This has led some to adopt multicore processors but disable all but one core, as they can’t economically verify the system when all cores are enabled.

This isn’t a good long-term solution and doesn’t take advantage of the performance improvements offered by using multicore hardware to its full potential. The challenges of using multicore processors in the critical embedded domain should be tackled head on, and the potential of these processors embraced.