[SystemSafety] The mindset for safety-critical systems design

[Olwen Morgan]

Traceability of code to requirements is not sufficient to ensure that 
principle 1 is actually upheld. In the example I gave, developers of the 
ventilator had convinced themselves that Windows was needed for 
documented technical reasons. There *was* traceability in the clerical 
sense. The problem was that nobody raised the issue of the arrant 
stupidity of using Windows when all of the required functions could be 
provided by a much simpler system based on a cyclic executive design.

On 19/09/18 00:25, clayton at veriloud.com wrote:
> Some quick comments…(I’m catching up too ;-)
>
>> On Sep 18, 2018, at 8:11 AM, Olwen Morgan 
>> <olwen.morgan at btinternet.com <mailto:olwen.morgan at btinternet.com>> wrote:
>>
>> 1. Whatever is not there cannot go wrong (so do not include any 
>> functions that you do not need).
>
> MISRA-C:2012 has “Directive” saying all code shall be traceable to 
> documented requirements with reference to DO-178C Section 6.4.4.3.d
>
> Also in MISRA-C:2012’s preamble it points to complexity thresholding 
> being one of the "Process activities expected by MISRA C”.
>
> In addition some specific rules address path complexity  (sort of), 
> e.g. no dead or unreachable code, though these are “undecidable” rules 
> not feasibly enforceable at the system level.
>
> I say "not feasibly enforceable at the system level”, keeping in mind 
> the old paper "The Infeasibility of Quantifying the Reliability of 
> Life-Critical Real-Time Software -  Butler, Finelli” which Philip 
> Koopman among others referred to in expert testimony not too long ago 
> ( https://bit.ly/1XgBA1j )
>
>
>
>
>

-- 
Olwen Morgan CITP, MBCS olwen.morgan at btinternet.com +44 (0) 7854 899667 
Carmarthenshire, Wales, UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180919/22ccaf3d/attachment.html>