Can safety-critical software be flexible?

Safety-critical software systems follow rigorous software processes to ensure safety to human life. These rigorous processes have a tendency to limit how safety-critical software is written. In addition, automation tools and manual processes are used to inspect every path of execution flow of safety-critical software to ensure predictable behavior. As a result of these rigorous processes, safety-critical software is more expensive to develop and maintain. On the other hand, the primary goal of software stability is to separate the enduring technology portions of software from easily changeable domain portions of the software. By doing so, the software becomes more flexible and can evolve with less effort and cost. Enduring business themes (EBT) is the most written about software technique for developing stable software. The EBT technique is object-oriented and promotes use of interpreters, compilers, and rules engines, which replace readable code with translation of human readable input. In contrast, guidelines for the development of safety-critical software do not fully address the use of object-oriented languages, and lace a strong emphasis on code inspection to clearly identify all paths of execution as deterministic. Thus, software stability approaches appear to be at conflict with the rigorous practices required in safety-critical software systems. Can safety-critical software development embrace software stability concepts to allow the software to be easier to change and adapt? We think the safety-critical software can be made flexible; we show you how in this paper.