[SystemSafety] Component Reliability and System Safety

Olwen Morgan olwen.morgan at btinternet.com
Sun Sep 16 17:23:09 CEST 2018


Les Chambers wrote (among other things) >

<snip>

>>>   It's a bad beginning to toss a standard at any development shop and 
expect them to follow it.

***That's been my experience. On one contract I did, the client's staff 
complained that I was, "anally obsessive" about code merely because I'm 
uber-pernickety about how I put it together. (Not a claim of 
professional virtue because I'm borderline for autistic spectrum 
disorder - you don't need it but it helps.)


<snip>


>>>  Another thing we should be doing is developing languages that support 
automated V&V. For example, embedding non-executable semantics: this is 
a method contract which must have properties: a, b, c (refer Steve 
Tockey's manuscript) , this code implements model X , this code 
implements pattern Y, this method implements SHA-x encryption, this 
method implements a remote procedure call that must have code segments 
of classes A, B and C ..

*** Yes - with you you all the way here. The use of pre-proven patterns 
or components can radically reduce verification complexity. In fact, I 
understand that simply caching already-used proofs for unaltered 
sections of code can effect something like a 10x speed-up when using 
SPARK Ada verification tools (Rod Chapman please correct me here if my 
memory is at fault).


<snip>

>>>  it's time we stopped passing the buck with useless placebo standards, 
got off our bellies and engaged with the real toil of automating the 
original sin out of software engineering.


***Yep - with you all the way here.

***It is IMO, particularly pernicious that contemporary programming 
languages - particularly C - lack standardised annotations that would 
support diverse forms of automated verification. Frama C and AbsInt go 
some way in that direction but they seem to have had no impact on the 
international standard for C. Indeed my own view of 
ISO-IEC/JTC1/SC22/WG14 is that it is dominated by a POSIX/Open-Source 
culture, unwilling, if not unable, to grasp what is required for using C 
in critical systems, and thereby utterly failing to address the needs of 
people developing such systems.

***The last time I had a run-in on this subject with the BSI C panel, it 
caused such a huge row that BSI (IMO belatedly but prudently) introduced 
a code of conduct for BSI panel members. Shortly after that I decided 
that international language standardisation had become so dysfunctional 
that I was not prepared to be involved with it any further.


regards,

Olwen


PS: Being nowadays of a somewhat Buddhist persuasion, I don't start from 
the notion of original sin. It's more a matter of acknowledging and 
trying to steer people away from dukkah (=suffering).




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180916/40a77069/attachment.html>


More information about the systemsafety mailing list