Method for Generating a Diverse Set of Requirements for Safety-critical Systems

AbstractAutomatic digital safety-critical systems are often architected with redundant hardware in order to combat the effects of a single failure that could prevent the system from performing its safety function. Additionally, diverse hardware and software are typically employed to guard against any potential common-cause failures that would likewise cause an inability of the system to carry out its safety function. An all digital (processor or programmable logic-based) implementation usually requires the development of two digital systems by two separate software (and frequently hardware) teams which operate in parallel to provide the safety function. Strict rules are applied to the development process to ensure that the separate teams do not share information or influence each other's designs. Even though this technique provides a means to develop a diverse set of digital safety-critical equipment, the system design still begins with a single set of requirements. Therefore, it is conceivable that the two design teams may create solutions that contain identical design elements. Any flaws or vulnerabilities in the common elements would then be shared between the two designs making the system vulnerable to common-cause failures thus defeating the benefit of utilizing diverse design teams.A method is proposed herein to address this limitation. This method entails the classification of the individual requirements of the source specification according to a detailed hierarchical taxonomy and the subsequent altering of the classified requirements. The taxonomy is structured so that the leaf-level classifiers are mutually exclusive or uncorrelated and the classified requirements are altered to be more stringent. The original and constrained requirements are allocated to two specifications documents in such a way that for certain requirements, the original version appears in the specification for one design team and the constrained version appears in the specification for the other. By using this process, sufficient requirements diversity results increasing the likelihood the two separate development teams will achieve a greater degree of design and implementation diversity than two teams using the same set of requirements. This increased product diversity should ultimately result in fewer latent common-cause faults residing in the two diverse systems. Furthermore, the degree of diversity achieved is expected to be greater when requirements diversity is employed, as compared to a traditional approach in which diversity is achieved by chance