OSADL Project: Safety Critical Linux
Safety Critical Linux - Working Group Proposal by Nicholas Mc Guire
Next: Safety Case Up: Safety Critical Linux Working Previous: Introduction
Problem Statement
Basic requirements of safety systems in the automation world have traditionally rested strongly on a well defined software life-cycle - This almost by definition seems to contradict COTS and even more so one of its variants, OSS. Even though standards like CENELEC (IEC 50128) explicitly mention COTS components and implicitly subsume OSS as COTS, the guidance for its usage is low and generally very unspecific. Further standards have been in the position of needing to integrate often competing industrial practice to achieve wider acceptance, thus standards (again 50128 as example) explicitly allow violation of highly recommended practice if sufficiently argued. This potentially allows arguing away the entire standard and replacing it with "something else". Obviously this is not the goal of a standard and thus the question of how well OSS components actually are documented, standard compliant, systematically developed and tested, is essential. This leads to a few basic topics resulting directly from the general perception of OSS being "random chaotic development without a plan a direction and verification" (which is plain wrong).
- Documenting the SW Lifecycle practice of key components (notably the Linux kernel)
- Providing sufficiently consistent and complete documentation of the OSS components in use.
- A key issue thus is assessing what role existing software management structures of OSS projects can provide in the context of safety standards.
- Establishing of key documents needed for validation (i.e. requirement specification) and feeding these back into the community of mainstream developers
- Providing documentation of the tools available for validation and verification, including assessment of quality.
This list is incomplete - after all this is a discussion paper only. The main statement here simply is that one needs to adjust certain qualities of OSS to fit into the scheme mandated by rigorous standards and that there is little point in trying to criticize the standard or argue the documents away. One can argue away validation and testing procedures but not the documents.
Subsections
Next: Safety Case Up: Safety Critical Linux Working Previous: Introduction latex2html 2007-07-15
