More in

DO-178 specification gets upgrade to take account of model based design

4 mins read

Software has developed a reputation for being inherently bug ridden and there's one place where the last thing you need is unpredictable software – in an aeroplane. Yet software written for aerospace applications is complex, with a liberal sprinkling of decision points that might make it work in ways completely unexpected by those who wrote it. No surprise, then, the authorities are keen to see software written and tested in such a way that safety is at the top of the requirements list.

One way to ensure software is as reliable as possible is to keep a close eye on the development process – and that's the goal of DO-178B, a certification process which is used by almost every company developing software for aerospace applications. In order to comply with one of the five categories, software developers need to produce a raft of documentation that shows their process – and therefore the software produced – meets the appropriate requirements. The problem is that the DO-178 set of standards is 30 years old and was last revised – with the introduction of DO-178B – in 1992. Time, as they say, has moved on. Mark Walker is senior engineer with The Mathworks UK. He said: "The approach hasn't changed since the B revision was issued. While the standard has been proven in use, what has changed is the way some teams go about achieving their objectives: techniques have moved on since 1992." But things are changing with the release at the end of 2011 of DO-178C, which retains the historical title of 'Software Considerations in Airborne Systems and Equipment Certification'. "This and its four supplements," Walker pointed out, "are all about how you work in the context of modern tools." The four supplements address: software tool qualification considerations; model based design; object oriented design; and formal methods of certification. One of the problems, Walker highlighted, was the fact that the term 'model' wasn't used in the B revision. "We learned how to interpret models within the context of the B revision," he said, "working out what was and what wasn't acceptable. The C revision clarifies things." When the B revision was published, specification documents were hand written. "B assumed you would write down what your software would do, but it wasn't clear about the point at which you could use models," Walker continued. "For example, you couldn't use simulation results from a model as evidence. But, because you weren't exercising the design, you could miss interactions between systems. Executable models are a good way of finding out whether things work and the simulation results will show whether you have the right answer." Because many of the software blocks in aerospace applications are complex, there is always the chance of them containing bugs. "You'll find that things don't work properly," Walker said. "Previously, the only way you had of finding those bugs was by someone reviewing the specification document or by running the code. When you have an executable specification in a model, that will tell you whether there are problems or not." Even though the standard has been upgraded, DO-178C still requires a specification document. "But now," Walker said, "the model is the specification and the specification document can be generated from the model." The change is seen by Walker as bringing more efficiency to the process. "With a document driven process, bugs tended to be discovered later on after a lot of engineering effort. With a model based approach, they are more likely to be found earlier and will, therefore, be cheaper to fix." Design and fix at a higher level He compared the move to the DO-178C revision with the transition from assembler to C. "You can design at a higher level language using C," he said. "Going to a model based process allows software to be designed and fixed at a higher level. Because complexity is increasing, it's getting harder to take software through to production without using a model based process," he contended. Two types of test are applied to the software model: statistical, where all the combinations are exercised; and satisfying requirements, asking whether the code satisfies higher level requirements for what it must do. He pointed out that, once you have a model, it can be used to design tests, which can then be used to exercise the resulting software. "It's all about getting statistical coverage," he said. "If a branch exists in the source code, it will also be in the model, so you can test the model for statistical coverage." However, it is important not to end up effectively chasing your own tail. "You shouldn't end up testing the model against itself," Walker warned. "The standard is still very clear about top down requirements and how each stage must be shown to satisfy those requirements." Models, by their very nature, describe elements of a system; but you can link them to build bigger models. "One important thing with high integrity systems is verifying they have been put together correctly," Walker concluded. Integrated modular avionics Aerospace developers are increasingly looking to use COTS software to implement systems on fewer and more centralised processing units, based on partitioned Integrated Modular Avionics (IMA) architectures. Not only does this approach cut development and deployment costs, it also brings benefits in space, weight and power consumption. Alex Wilson, senior business development manager for Wind River's aerospace and defence business, said: "In addition to consolidating multiple applications on one computing platform, IMA enables the reuse of applications, leading to lower recertification cost. It also allows for the easier upgrading of applications to add functionality through incremental certification and enables easier mid life upgrade of the hardware platform." In Wilson's view, while IMA brings significant advantages to the supply chain, the transition offers a serious challenge for systems integrators. "They have to bring components together – often from different vendors – on a single platform, ensure there are sufficient computing resources and that applications are not demanding more computer resources than allowable, while building in the necessary safety margins." Emerging software tools not only allow developers to simulate any target hardware – from one processor to complex electronic systems – they also allow final executable code to run in a simulated environment, enabling performance measurement and configuration testing. "Simulation tools replace paper analysis," said Wilson. "Simulation enables fast and easy impact evaluation on complete systems and can lead to a significant reduction in the risk of moving to a new technology. This is especially true as developers look to use multicore technology in safety critical applications. "No one is saying the integration of complex avionics electronic systems has suddenly become a simple matter," he concluded, "but there should be little doubt that simulation can make it considerably easier." * Meanwhile, Wind River has extended its safety critical systems product capabilities to support complete RTCA DO-178C certification evidence as a COTS solution, with the VxWorks rtos conforming to DO-178C Level A guidelines.