Draft: Recommended approaches and rationale

docs/approaches.md

@@ -0,0 +1,115 @@
+# What approaches do we recommend?
+
+Our starting position in this working group is that Linux is **not viable as a
+safety-critical operating system in its own right**, for the simple reason that
+it has not been designed, implemented or verified with this purpose in mind.
+
+This means that _Enabling Linux in Safety Applications_ involves understanding
+the risks that using Linux entails, and then designing system architectures that
+can manage or mitigate those risks, with or without the involvement of Linux
+itself.
+
+But what are the reasons for adopting this starting position?
+
+## Why not argue that Linux is 'proven in use'?
+
+While Linux is used to run much of the Internet, provides the basis for the
+Android OS in millions of mobile phones and is used by 100% of the world's
+super-computers, it was not developed with functional safety in mind, and
+evidence of its use in other domains does not provide the kind of assurances
+that are expected for safety applications.
+
+Arguing that pre-existing software can be used in a specific safety application
+based on evidence of its use for substantially the same purpose in other
+products is described as a 'proven in use' argument.
+
+This approach is described in some safety standards. For example, ISO 26262 part
+8 section 14 notes that this approach may apply to "any product whose definition
+and conditions of use are identical to or have a very high degree of commonality
+with a product that is already released and in operation."
+
+However, the criteria for applying this type of argument have very strict
+requirements relating to failure rates from use of the element in comparable
+products for the same purpose, based on incident report data collected over long
+periods of time[^1].
+
+Even if there were such data available for Linux, we could not make an argument
+based on this unless we used the same version of the software, in the same kind
+of system for the same purpose.
+
+## Why not fork Linux and safety certify it?
+
+It is theoretically possible to make an argument for using Linux in a
+safety-critical role for a lower safety integrity level[^2] application, by
+subjecting a specific version of the software to appropriate engineering process
+measures e.g. defining requirements, documenting design, performing safety
+analysis, developing tests, etc.
+
+Provisions do exist in some safety standards[^3] for this approach to using
+pre-existing software as part of a safety-related system. However:
+
+- The time and effort involved in achieving this for Linux is always going to be
+  very large, because of the size of its codebase (more than 40 million lines of
+  code[^4]) and the very broad scope of its supported functionality, hardware
+  and configurations.
+- This means that such an approach would inevitably need to focus on a
+  tightly-constrained subset of supported functionalities and hardware, to
+  reduce the scope of the work required.
+- This would typically also require the removal of all extraneous or undesired
+  source code and configurations (and modification of the associated build files
+  and tests), to avoid having to analyse these and their associated risks, and
+  having to justify their inclusion in the software subset.
+- Any deficiencies identified by analysis of the chosen Linux version and subset
+  with safety implications would also need to be addressed, resulting in further
+  modifications to the customised codebase.
+- The results of such an approach would only apply for the specific version of
+  Linux analysed, for the specific use case(s) considered and for whatever
+  constrained set of functions and target hardware was selected.
+- As a consequence, any fixes, enhancements or new features added in the
+  upstream Linux could not be automatically applied to the customised codebase,
+  instead requiring detailed impact analysis to understand their potential risks
+  and relevance.
+- Maintaining such a codebase would be an ongoing commitment for the lifetime of
+  any products making use of the special Linux
+
+## Why not show that Linux is safe by testing it thoroughly?
+
+A common expectation is that safety can be achieved for software by simply doing
+enough testing. However, there are always two questions about this that are
+difficult to answer:
+
+**1. What needs to be tested, and why?**
+
+Testing is only one of the verification and validation measures described in
+safety standards. All such measures have a dependency on specified requirements
+for the software, the system(s) within which it is intended to operate, and the
+safety-related functions that the system(s) must provide.
+
+Safety requirements necessarily derive from the system context, as well as the
+intended purpose of the system and the risks associated with its use. A set of
+requirements for an operating system with  safety applications in mind might be
+possible, and might be easier to specify with a discrete set of functions.
+
+The most fundamental requirements for an OS in these contexts are measures or
+mechanisms to manage or detect interference between elements of the system, from
+spatial (memory) and temporal (scheduling) perspectives, and data communication
+between elements and with other systems.
+
+However, precisely what OS functionality needs testing for any given system can
+only be determined by reference to that system's safety requirements.
+
+**2. How much testing is enough?**
+
+TODO
+
+[^1]: For example, in ISO 26262, for the _lowest_ category of safety integrity
+      the _minimum_ evaluation period required is 12 million hours, and the
+      number of observable failures must be lower than than 10^7/h.
+[^2]: "In functional safety, safety integrity level (SIL) is defined as the
+      relative level of risk-reduction provided by a safety instrumented
+      function (SIF)"
+      [_Wikipedia_](https://en.wikipedia.org/wiki/Safety_integrity_level)
+[^3]: For example, the 'route 3S' compliance route described in clause 7.4.2.12
+      of IEC 61508:2010 part 3, or the approach described in ISO/PAS 8926:2024
+      with respect to the automotive safety standard ISO 26262.
+[^4]: Source: [_Command Linux_](https://commandlinux.com/statistics/linux-kernel-contributors-lines-of-code-statistics/)

mkdocs.yml

@@ -28,13 +28,16 @@ plugins:
 
 markdown_extensions:
   - attr_list
+  - footnotes
   - pymdownx.pathconverter:
       absolute: true
   - pymdownx.tilde
-
+  - pymdownx.caret
+  - pymdownx.mark
 nav:
   - ELISA: https://elisa.tech/
   - Directory: https://directory.elisa.tech/
   - OSEP:
     - Home: index.md
+    - Approaches: approaches.md
     - Document Evaluation: Criteria-Documentation-Evaluation.md