OSADL Project: Safety Critical Linux
Safety Critical Linux - Working Group Proposal by Nicholas Mc Guire
Next: Related Technologies Up: Safety Case Previous: Safety Case
Modular Safety Case
Clearly one of the limitations of procedure based safety cases, and in general , system level safety cases (though 50128 is a bit inconsistent on this), is that they don't allow easy reuse of safety cases for components - discussion on reuse of software components over the past 30 years have sufficiently show that this has the potential to increase stability and reliability - this discussion has also started in the safety world, but with a not yet conclusive (or widely accepted) result, notably work on contract based safety arguments on top of safety notations like Goal Structure Notation (GSN) [18] seem promising. Preferable OSADL would work in the direction of improving the acceptance of modular safety cases as this would simplify certification substantially and enhance the ability of automation software development significantly - this is a goal that individual companies can hardly pursue, coordination of needs and a common cause representation in the public as well as at standard boards is needed.
To build modular safety cases a number of works propose the usage of GSN and have convincingly argued its advantages, notably reuse of safety cases, extensibility and improved maintainability. This is to a certain extent anticipating direction of standards development and might not fit perfectly but the preliminary assessment that safety case practice is shifting towards evidence based methodologies and modular safety cases is clear to us from the on-going discussions. In this context it also should be noted that there is a general trend towards evidence based safety cases (i.e. MOD 00-55 (procedural) was replaced fully by MOD 00-56 (evidence based)).
In the context of the Safety Critical Linux Working Group a generic safety platform (dubbed Safe Computing Platform (SCP)) is proposed that roughly would provide a product independent base layer to put safety applications on. This SCP would roughly be structured as follows:
- General Purpose OS (GPOS) - GNU/Linux
- POSIX (PSE 5X) Real-Time OS (RTOS) Threads support - (i.e. Preemptive-Kernel RTLinux/GPL, RTAI)
- Virtualization layer (virtual redundancy/diversity) - encapsulation of domain specific software components (generally non-standard).
The SCP should have the ability to run in different modes, corresponding to a different feature set available at run-time. The safety-case will be designed to allow reuse of safety arguments of these components in scenarios which constitute aggregation of these components to either form monitor (Virtualization layer only) , a minimal POSIX systems (Virtualization layer + POSIX PSE 51) and a full-featured system (Virtualization + RTOS + GPOS running concurrent). The essence of virtualization commes from 61508 permitting to integrate software components of different SIL levels provided the isolation can be argued. This not only is of interest for general OSS integration and composable systems, but also for legacy management and for long-term maintenance issues.
It should be noted that the SCP is a model for a safety case more than a specific implementation - but we feel that if no concrete context is provided for an initial target then the output of such a working group would be stuck in a level of generality that is of no utility to the end user. Adjustment, modification or replacement by alternatives could prove necessary as early as the initial kickoff meeting.
Next: Related Technologies Up: Safety Case Previous: Safety Case latex2html 2007-07-15
