[SystemSafety] Collected stopgap measures

[Matthew Squair]

The value of a ‘chain of custody’ approach is twofold. To demonstrate that the software does what the system requires it to do, and that it does nothing else. The looser that chain gets the more likely it is that a requirement will be missed (somewhere) or a misinterpretation will not be picked up. 

Doing it in a stepwise fashion is important from a practical point of view if your ability to verify on a representative target system or in the actual environment is limited. For example landing on Mars for real is not a good place to be formally demonstrating the squat software function won’t accidentally turn the engines off (as happened to the MPL). 

If you’re interested in seeking it out I think it was Parnas who wrote a paper on ‘how to fake a rational design process’ which addresses your comments about the difference between aspiration and messy reality. 

Matthew Squair

MIEAust, CPEng
Mob: +61 488770655
Email; Mattsquair at gmail.com
Web: http://criticaluncertainties.com

> On 16 Nov 2018, at 5:05 pm, Paul Sherwood <paul.sherwood at codethink.co.uk> wrote:
> 
>> On 2018-11-15 18:57, Matthew Squair wrote:
>> A version of this argument is the great debate about the need for what
>> are called Low level Requirements for the higher assurance levels in
>> DO-178.
> 
> I enjoy debate as much as the next person, but mainly I'm trying to get to actual engineering.
> 
>> You start with high level software requirements (the software
>> specification) and for greater assurance you add in low level
>> requirements (the software design document).
> 
> If that's the chosen management method, fine.
> 
>> One answer as to why we need specifications is not that they're needed
>> to develop a software product but because we need to demonstrate to a
>> third party that we have been duly diligent.
> 
> Agreed.
> 
> Any reasonable diligence on software shows that pre-specifying/architecting is a minority sport. The drill-downs I've done personally lead me to conclude that in many of the cases where folks claim that they applied this approach, the evidence doesn't stack up. Often the documents are retrofitted.
> 
> I'm not suggesting that folks who insist here that they get spec, and arch, and software, right first time (in that order) are lying. However I do think they are in a small minority.
> 
>> To do that defensibly we
>> need to provide objective evidence and that evidence has traditionally
>> been in the form of documentation.
> 
> Yup - if someone claims 'safety' or 'security' they need (documented) evidence of what they are safe/secure against, and how that safety/security is (supposed to be) achieved.
> 
> I just think that this documentation can be (and often is) created while (or after) the software part of the system is created. I'm not alone, since many safety folks seem happy to bless the idea of software as 'safety element out of context'.
> 
>> So no you don’t ‘necessarily’ need
>> a software specification to develop a software product but to convince
>> a regulator that you haven’t broken the chain of custody from system
>> specification to source code* you’ll need to bring evidence. And as we
>> know strong claims demand strong evidence.
> 
> This is new to me... what's the value of "chain of custody from system specification to source code"?
> Are you saying that the system spec has to lead to the existence of source code somehow?
> 
>> Conversely if the only
>> person I really have to convince that my sprint is good is the team
>> lead, well the burden of proof is going to be much lower*. Not so
>> strong claims require less evidence as a corollary.
> 
> That's not the kind of situation we are considering, I thought?
> 
> Let's keep focusing on 'system safety'... I remain hopeful that I could (as duty-holder) put my signature on (say) a Linux-based system, with appropriate documentation about the losees/hazards/risks, and the expected/demanded behaviours for the Linux kernel in context.
> 
> This hope is inspired in part by the knowledge that others have already deployed Linux-based software in safety-critical systems, and in part by my perception of the futility of starting from scratch to re-implement Linux-equivalent functionality and performance by constructing new software from scratch, to a new architecture and based a new set of requirements.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181116/da7196ae/attachment.html>