Failing at Avionics Software Development

Software has become essential in airborne systems given its capability of adding functionality and value without adding weight to the aircraft. Due to the huge demand for new aircraft functionalities, airborne software complexity and volume have constantly increased over recent years with no signs of stopping. In line with the increase in software complexity, appropriate diligence is required for airborne software development and verification. Lives are at stake and the criticality of airborne software means that the industry is incredibly picky when it comes to test rigor. Detecting and fixing software defects in early development stages reduces any undesirable side effects which could impact aircraft safety.

If you’re not familiar with DO-178C, it’s a regulation standard comprising a set of guidelines which ensures that the critical software used in airborne systems complies with airworthiness requirements. It includes 71 objectives spread across ten categories of airborne software development processes. Failures and flaws can happen across any of these processes or objectives and testing plays an important role in preventing them.

Although everyone hopes that prevention should be enough to prove software perfection, in reality this isn’t always the case – one must always assume that software defects are, indeed, in there somewhere. This is why DO-178C makes defect assessment mandatory and recommends the implementation of well-designed tests which ensure defects are uncovered and corrected at the earliest opportunity. If this sounds like a big deal, it’s because it is.

Here are the top ways to fail at software testing:

• Not testing software over its service life. This may mean you need to spend more time on actual testing than on development, though many engineers fail to recognise this. How do we fix this? Stepping up test automation, by enabling continuous and regression testing, is the best way to achieve more effective testing while at the same time requiring less engineering effort.
• Using only unit testing.This seems to be the go-to solution for many engineers when discussing requirements and structural coverage. Unit testing checks a single component of an application to see if it’s doing its job. This ultimately means that unit testing has a very narrow scope and you run the risk of uncovering fewer problems which could be spotted far earlier in the process and in a much more efficient way through static analysis or code inspection.
• Ignoring the need for expert “white box” skills for DAL C and above. In other words, the tester must be as capable as or even better than the engineer who wrote the software in the first place. This kind of testing and structural coverage assessment demands expert coding skills and independence. Now, we know that independence is more expensive, but it’s also able to produce more robust verification – which is what we need ensure the required software quality!
• Designing sloppy tests. One of your top priorities should be to design robust integration tests which can achieve the highest level of structural coverage through functional requirements-based testing.
• Writing test code without as much care as the flight code. Convincing yourself that tests won’t fly and that you don’t need to bother with all the complicated coding standards is a recipe for failure when it comes to avionics software. Fixing this issue is simple: put in the same effort into testing code as you do when writing airborne code and watch your software evolve more smoothly than ever before!

Smart companies make testing a part of the entire development process. Each line of code, module or component must be tested, isolated and integrated and any possible behaviour needs to be predictable and easily demonstrated through testing. As we all know, the consequences can be dire if a company takes shortcuts when it comes to testing robustness.

Did you know there are even more ways to fail at airborne software development than those outlined here? Crazy, right? Take a look at our free white paper to find out what else you’re missing.