The 5 Key Ingredients to Get Your Avionics Software Code Implementation Cooking

Cooking and avionics are incredibly similar. At their cores, they’re both made of meticulous processes that involve numerous steps and require numerous elements to be prepared and altered in just the right way, all in the hopes of creating an exceptional end-result experienced by numerous people. So, in this article, we’re covering an important section of the avionics software project recipe: implementation.

When the “base” parts of your software dish—requirements and design—are ready, the next step is to get your code implemented in your product. While this particular step isn’t as complex or time-consuming as the entirety of your project, specifically the compliance process, it’s no less a crucial element in getting your entire software “dish” ready to serve. Also, as in every step throughout your avionics software project, you’ll need to ensure that your code implementation follows the processes and standards established in your DO-178C PSAC. Don’t forget you’ll also record observations and provide evidence of your PSAC adherence through the SQA Integral process, as your certification authority is likely to request evidence demonstrating that you have done so in any remaining/future Stage of Involvement (SOI) reviews.

The decisions you make on how to implement your product can have major effects on your verification later. These can make your verification much easier or much more difficult, resulting respectively in your “final dish” ready to serve on-time or with major, disappointing delays. Because the verification step takes much more effort than implementation, it’s important to get your ingredients just right for when you’re ready to cook and. Here are the top 5 ingredients to consider in your avionics software code implementation:

1. 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.

2. 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. Your implementation decisions can affect the efficiency of your verification. To keep your verification efficient, you should consider the impact that your choices (including programming language(s), coding standard(s) and choice of hardware platform and operating system) will have on your verification.

3. Choice of hardware platform:

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 off-chip tracing capabilities are available.

4. 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 (see Source code vs. object code structural coverage analysis on page 51). 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 that you allow to occur, the more effort you’ll need to verify your code.

5. 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. The cost of changing any of the items above becomes increasingly large the further you are through a DO-178C project, so you should ideally consider them before your DO-178C Planning.

Carefully considering the “what, how and where” of those key ingredients in your code implementation will help this step be most successful. That is, you’ll make things more efficient and mitigate the many risks that can come during verification. Of course, remember that this is one section in the whole process, but we cover all those steps as well in our software cooking classes. Ultimately, when aerospace professionals boil down implementation to simply following steps in the avionics software project recipe, your chances of creating a masterpiece increase exponentially.

Leave a Reply