[SystemSafety] Collected stopgap measures

[paul_e.bennett at topmail.co.uk]

On 02/11/2018 at 9:30 AM, "Paul Sherwood" <paul.sherwood at codethink.co.uk> wrote:
>
>I'm quite enjoying the discussion here, since clearly there are a 
>lot of 
>intelligent, opinionated folks in this community and a significant 
>depth 
>of experience in safety (which I personally lack).
>
>Interestingly this thread has drifted towards topics that we 
>started 
>exploring on the Trustable Software list a couple of years ago. 
>There we 
>concluded that trust can only be established with evidence, and 
>that 
>we'd prefer to see the evolution of the evidence, including the 
>identities of the folks who did the work - not just some end-of-
>project 
>snapshot with an acceptance certificate.
>
>For trust in general, our position (on the rather quieter 
>trustable-software list) is that we want to see evidence for all 
>of the 
>following:
>
>- functionality
>- reliability
>- reproducibility
>- provenance
>- safety
>- security
>- compliance
>
>We've made some progress on the first four of these, and I landed 
>here 
>as part of my journey to understand how best to cope with safety, 
>which 
>I now understand to be ** a system property **, not a software 
>property 
>(same goes for security).
>
>For the software only properties, it's obvious that we DO NOT need 
>documented requirements, or documented design. Software is often 
>(almost 
>always, these days, in agileworld?) successfully evolved and 
>consumed 
>without either of these.

Whatever the Agile folk may think, at some point the software they
develop is, in the end, a component of the system. The question I
will pose, therefore, is based on whether or not, by the timer of
integration with the rest, the software component comes with
sufficient evidence of its 'fitness for purpose', like any physical
component deployed in the system.

>For safety and security, as I understand it there's no way we 
>could make 
>any promises without defining what losses/hazards we aim to 
>address 
>(requirements) and then establishing a design (architecture) to 
>demonstrate how we intend to achieve our objective.

Developing dependable software should never be considered as
taking place alone. There should be a preference for using
multidisciplinary teams of people who work together on the
various components of the system.

>However, this documentation is often done after the fact 
>(retrofitting 
>documentation to existing systems/software), and it seems to me 
>that any 
>realistic process or checklist needs to accept that reality.

Back-tracking to add documentation should be seen as a red flag
in trusted systems development. Once incorporated into a sub-assembly
hardware components can become much more anonymous. Trying to
back- track to add documentation in such circumstances is way more
hard work than anyone should perform. Far better to make sure the
documentation pile grows as the system grows, with component
certificates of conformity being part of the evidential documentation.
For all components including the software.

Would you trust a mechanical safety device if it was presented with
a host of 'arm waving' assurances? I think not. We should be seeking,
and educating those who follow us, into how to do engineering properly.
That includes supplying the appropriately generated and relied upon
documentary evidence that can stand the test of being proper evidence
in a court of law, when subjected to intense legal scrutiny and cross
examination.


Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************