Not long ago we showed how cooking and avionics project development have a lot in common. In keeping with culinary concepts, I wanted to take a look at the “the pudding” of Aerospace engineering, i.e. where the proof is. I’m talking, of course, about the implementation phase of the DO-178C project lifecycle.

First, a quick note: I was surprised to learn that the saying, “The proof is in the pudding” is actually a recent twist on the original phrase, “The proof of the pudding is in the eating” (and I was more surprised to learn that ‘pudding’ referred to the innards of a sausage). The idiom refers to having to actually try a final product to know if it’s “good” or not. So, it certainly makes sense to consider “the pudding” of avionics software development projects to be the implementation in the DO-178C project lifecycle.

It goes without saying that implementation of your code is an important step in your DO-178C project. There are numerous complexities and considerations to take into account when establishing the standards and processes of your implementation. Hopefully, those are defined in your Plan for Software Aspects of Certification (PSAC). Here, we’ll discuss the options you have in implementation and how those options can affect your project, its verification, and its time-to-completion.

First, always remember your implementation decisions can make verification good—smooth, easy, cost-effective—or not so good. As verification takes much more effort than implementation, it’s important to carefully consider each decision throughout implementation in DO-178C projects. That way, you’ll reduce your verification effort in the overall project.

So, here are a few things to consider:

• Choice of programming language(s) – if you’re using any commercial tools for verification that need to analyze your source code (for example to apply instrumentation for structural coverage analysis), you should ensure that those tools support the language(s) you’re using.
• Choice of coding standard(s) – DO-178C compliance requires that you define coding standards during your planning and follow them during your implementation. The standard(s) that you use can affect the ease of your verification:
  • Generally, the fewer and simpler the code constructs you use, the less effort you’ll need to verify your software.
  • Some language constructs may not be supported by some commercial verification tools you intend to use, which may cause your project further costs or delay. If you evaluate verification tools, it’s worth ensuring that they can analyze sample code written with the coding standard you plan to use.
  • Some coding standards require generated code to be written in a way that can cause development of untestable code, such as a standard requiring that default cases are included in every switch function. At higher DALs, you’ll need to review this code even if you can’t test it, which can incur extra effort. The cost of changing any of the items above grows larger the further you are through a DO-178C project, so you should ideally consider them before your DO-178C Planning.
  • DO-178C states that your coding standard should include code complexity restrictions. Limiting code complexity in general makes it easier to verify the code, while limiting the use of specific language features may be necessary for your source code to be compatible with the verification techniques and tools that you intend to use. If you are working at DAL A, you may need to take care to structure your low-level requirements so that your corresponding source code does not need an excessive number of conditions per decision. This will reduce the effort needed to achieve and maintain full MC/DC of your source code later.
• Choice of hardware platform and operating system – your choice of hardware platform and operating system can have huge effects on the timing behavior and predictability of the final software, especially if you are using multicore processors. Some platforms and operating systems may have in-built features that make your verification easier – it’s worth evaluating a range of options early and considering downstream effects on verification. For example, using hardware with on-chip tracing capabilities can make worst-case execution time analysis much easier than if only offchip tracing capabilities are available.
• Choice of compiler and compiler options – the compiler and compiler options you use can affect how easy it is to verify your code. Your compiler and compiler options can especially affect the efficiency of your structural coverage analysis. Structural coverage analysis can be performed either by analyzing execution of source code or object code constructs. If object code is analyzed, additional verification may be needed to map the object code coverage to the source code. Compilers can optimize the code, making it require more effort to do this mapping. For DAL A software, it is also necessary to verify any additional code that is introduced by the compiler. In both cases, the more compiler optimizations you allow to occur, the more effort you’ll need to verify your code.
• Use of emerging technologies – if your implementation uses emerging technologies such as using GPU devices rather than CPU devices for computation, using multicore systems, or data-driven computation, your verification may be more challenging and time-consuming. While verification methodologies are well established for “standard” implementations, this is not the case for implementations using emerging technologies, and verification tool support is less available.

No matter what you decide for your implementation, the key thing to remember is that the cost of changing any of the items above grows exponentially the further you are through a DO-178C project. Ideally, you should consider all of these items before your DO-178C Planning, and your implementation in DO-178C projects will run smooth and fast, making your overall project more cost-effective and more likely to succeed.

To learn more about planning, implementation and verification of DO-178C projects, visit ConsuNova.com and check out our white papers on DO-178C and our training packages to help make your avionics projects run smoother.