RE: [sc] sc: languages

Date view Thread view Subject view Author view Attachment view

Date: Wed 12 Jun 2002 - 11:01:01 BST

> From: Peter B. Ladkin [mailto:ladkin(at)]
> Sent: 11 June 2002 12:09


> Thesis: It is not only a good idea, but imperative, that 
> development tools that demonstrably avoid well-known
> and generic vulnerabilities be used to build 
> safety critical systems.

"Good idea" - I would agree with without reservation.
"imperative" - depends on what you mean by it;
OED (adj) 1 => Urgent; Obligatory

So if you mean "urgent", that may possibly be the case if there is
wide-scale non-use of such tools.  If you mean "obligatory" then I would
disagree.  I disagree because this is making the use of a technique
obligatory and I believe that the only thing that should be obligatory is
the need to demonstrably meet safety requirements (given that the context of
this discussion is safety).  A safety argument must stand by its logic and
strength of argument.  Using some tools (such as the ones described) may
make the safety case simpler in some respects - but this does not invalidate
the alternatives.

I also believe that simply using a tool or technique does not assure safety,
nor does it assure you that your safety-case will be easier.  An example of
that is SPARK - which has come a long way over the years that I have worked
with it.  Originally SPARK was touted as an Ada sub-set with annotations
that if used would improve safety by allowing you to reason more robustly
about your programs.  Some early experiences revealed that depending on your
software design, it is quite possible to end up with SPARK programs where it
is not easy to make worthwhile analyses of a program.  Praxis Critical
Systems have now addressed this with the INFORMED design method for SPARK.

Other tools also exist, for example Polyspace Verifier - which use different
techniques to analyse programs.

These all seem to suggest that simply mandating a technique is not the right
way of doing things.  I might agree that using Ada is better than using C,
using SPARK is better still, following the INFORMED design method is better
still.  But I would not say that precludes an adequate safety-case being
built around a C program.

> If one's safety case must include lots of documentation
> showing that one's code does not suffer from problems
> enabled by weak data typing and inadequate exception 
> handling, I consider that a waste of resources that
> could be more profitably focused on other aspects of
> the safety of the system.

A company must provide an adequate safety case.  If resources are not
required to do 'lots of documentation' they will be used more profitably on
another programme, not gold plating the safety case of this one. ;-)

> Antithesis: It is not practical. There are two aspects to 
> this response, as I understand it. First, that few people 
> want to do it. Second, that some circumstances preclude it
> generically.
<snip the first issue>

> I refute the second issue without argument.

OED refute (v) 2 => rebut by argument

For someone who is normally very insistent on correctness of language, and
very methodical with arguments I find this a very uncharacteristic

Perhaps there is a problem with the formulation of the antithesis:
  "Some circumstances preclude it generically"

It is sometimes the case that in the overall safety-case the consequences of
using a specific tool (to address a specific area of risk) would be
detrimental; or, as Pete Fenelon is suggesting, precludes an engineering

Again making the use of a tool/technique obligatory seems to fly in the face
of good sense.  But the adoption of such tools/techniques still remains, in
general, a good idea.

Stuart Palin
(usual disclaimers that I am speaking on my own behalf, not my employer's)


This email and any attachments are confidential to the intended 
recipient and may also be privileged. If you are not the intended 
recipient please delete it from your system and notify the sender. 
You should not copy it or use it for any purpose nor disclose or 
distribute its contents to any other person.


Date view Thread view Subject view Author view Attachment view