[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