September’s ESE Magazine has an interesting article entitled “Systematic Reuse of Safety-Critical Components will usher new age of Embedded Software Development”.
The article notes that the FAA has been looking for ways to cope with the increasing amount of software that is needed in avionics applications and issued guidelines (FAA AC 20-148 Resuable Software Components) in December 2004 on reusable software acceptance.
These guidelines mean that, with certain restrictions, using software that is certified as reusable will require less effort on behalf of the software integrator to have their system certified by FAA - prior certification of the reusable software component will count to some extent towards future certification of the component in a wider software system.
The article raises interesting questions about precisely how much verification work has to be done on a reusable component for its initial certification and how much verification work should be done on a reusable software component when it is reused in a new context.
When first verifying a reusable component, more work will have to be done to verify it than a non-reusable component. This is partly because the component developers have to describe to the FAA the assumptions they have about how the component will be reused, but also because reusable components generally require more verification effort than non-resuable ones because they are typically configurable in some way whereas non-reusable software is not.
In terms of reusing a component another issue is managing exactly what is different about the software in its new context. As Frank McCormick, president of CSI says in an earlier article for Aviation Today “Executable code might change without disrupting the requirements and design data that led to the code. So a nontrivial body of upstream data might well remain stable.” It’s not just the software configuration that may change when a reusable component is reused and the FAA needs to understand exactly what has changed in its new context when a component is submitted to it for certification as part of a wider system.
It seems to me that a Software Product Line approach is exactly what’s needed here to maximize the benefits of systematic reuse while addressing the essential need to build safe systems.
Software Product Lines are built around core assets that have been built to be configurable in predefined ways. Defining how a component is planned to be reused is a key activity in Software Product Line development and (some) well-established techniques are available to support this. This should address the FAA’s requirement to understand the assumptions made by the component developer about how the component will be reused.
Furthermore, configuration of reusable assets is usually performed through tool support, so asset configuration parameters are well-known and completely captured in formal models, such as feature models. This changed configuration need not just be code but could also be requirements, documentation, test plans etc. In fact any artefact associated with the component can in principle be configurable. Having these formal models of the reusable asset should support the process of informing the FAA of exactly what is different about the component as it has been reused in its new context.
There are examples of Software Product Lines in the avionics domain but I wonder whether they’re taking advantage of this FAA Guidance. If anyone knows then please get in touch, also, if anyone is aware of similar standards in other safety-critical domains then we’d like to hear about those too.
