The 3D Experience: Avionics Software Design, Development and Data Coupling

Not every profession has to use three dimensions. Artists, musicians, writers, and tax attorneys alike usually only need to consider two planes of existence in their professional lives, though no one’s sure in what dimension augmented reality fits, yet. But aerospace engineers and avionics professionals have a unique relationship with all dimensions. Dealing with all planes all the time (pun absolutely intended) is no small feat, and it’s especially important (and ironic) when working within a platform that only uses two dimensions: Avionics Software Design. So, for this article, we’re going to cover a different, non-spatial “3D;” let’s talk about the design, development and use of data coupling for Avionics software.

Before you begin development, you need your plans and requirements complete (we talked about the importance of planning and requirements setup a few articles ago). Once your planning stage is complete and your reqs have been established, agreed to and recorded, then you can begin the first of the “3D” software project experience, design.

Avionics Software Design

Design in DO-178C is the combination of architecture and low-level requirements. As you’re designing the architecture of your software, it’s important to define low-level requirements in order to form a system capable of meeting the high-level requirements you’ve already set. Always remember to follow the design standards identified and written in your Plan for Software Aspects of Certification (PSAC) and record your observations and evidence. You’ll present those findings through the SQA Integral process, a topic we always focus on in our training courses, as no matter the governing body, your certification authority is likely to check this evidence during future SOIs. Related, as you work through the design phase, items that should have low-level requirements but for which these requirements do not trace to high-level requirements, are often discovered.

The “hidden gems,” known as derived requirements, include requirements for things such as reusable libraries, scheduling behavior, or the numerical accuracy of the software. When considering bi-directional traceability, you must provide information to show where derived requirements come from. This could be a reference to the design process or a design standard, for example. Recording this information makes it easy to show that your software design is the product of a repeatable process. Also, this type of traceability is also important for change impact analysis, as these decisions often affect more than one software component. And that leads us to the next D, Development, or more precisely, architecture development.

Software architecture defines the components that software will have, including the functionality that each component will achieve, and the relationships between components, specifically data flows and control flows. Your architectural decisions can have a significant impact on your project life cycle, not only for implementation but also for verification, particularly considering data coupling and control coupling. Decisions you make in your software architecture will impact the verification effort needed for DO-178C compliance. As verification requires much more effort than implementation, we always recommend considering the impact your decisions will have and choose a strategy to reduce total effort.

Data Coupling

The third D of the avionics software 3D experience is part of the bigger process: the efficiency of data coupling and control coupling coverage analysis during your verification is an important consideration for any software project, especially those adhering to DO-178C. A couple things to consider e this analysis easier, you may want to:

  • Limit the number of data and control couples in your design.
  • Clearly define how each of the data and control couples in your design should operate, including specifying mode information.

One way in which your design decisions impact verification is in the data coupling and control coupling of the interfaces that you plan to include in your implementation. To comply with DO-178C guidance at DALs C and above, you need to verify that you have exercised the data coupling and control coupling interfaces in the implementation, and your design decisions will affect the ease of this verification.

As you need to verify that you have tested coverage of every data and control couple in your software for DO-178C compliance, your verification will be much easier if you include fewer coupled components in your design rather than more. The way that you define the couplings in your design will also impact the ease of your verification. To make verification of the data and control coupling in your system efficient, you may want to put extra effort into defining the data and control coupling interfaces thoroughly in your design by including information that will make it easier to verify the

coverage later. Sensible items to include in such definitions include:

  • Specifying data flow between components with detail such as Boolean and enumerated signals, numerical ranges and precisions, rates of change, update rates and fault flags.
  • Describing components in terms of modes. If two components only interact in a certain way when one or both are in a particular mode, it makes sense to add that mode information to the component definition(s). Mode information helps to reduce complexity by limiting the number of interactions you need to consider. Specifying the control flow in terms of when and how control passes into and out of each component, including error cases and exceptions.
  • Where software components interact with hardware, specifying data and control interactions in the same way as for software-software interactions. Simply put, the more information that your interface definitions include, the easier your verification will be.

Design, development and data coupling are key all key components of avionics software projects that involve numerous steps and details. Though each step in every DO-178C guided software project demands careful consideration and the strictest of diligence, remembering the “three Ds” is a sure way to help you achieve success. A good way to think about your software project: even though you’re working in a 2D medium, make sure your avionics software architecture and implementation utilizes the “3D experience” to ensure your project is completed on-time and as effectively as possible.