[SystemSafety] Stupid Software Errors [was: Overflow......]

Mon May 4 17:41:57 CEST 2015

Dear Derek,

some performance figures about an Astrée analysis for a Level A avionics
application:
- code size > 700.000 lines of C code
- analysis duration: 6 hours
- hardware: Intel Core2Duo 2.66 GHz, 8GB RAM.
- result: 0 alarms
I.e. the absence of run-time errors was proven, including arithmetic
overflows.

Best regards,
  Daniel.
---
Dr.-Ing. Daniel Kaestner ----------------------------------------------
AbsInt Angewandte Informatik GmbH      Email: kaestner at AbsInt.com
Science Park 1                         Tel:   +49-681-3836028
66123 Saarbruecken                     Fax:   +49-681-3836020
GERMANY                                WWW:   http://www.AbsInt.com
----------------------------------------------------------------------
Geschaeftsfuehrung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbruecken, HRB 11234

> -----Ursprüngliche Nachricht-----
> Von: systemsafety-bounces at lists.techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] Im Auftrag
> von Derek M Jones
> Gesendet: Montag, 4. Mai 2015 15:42
> An: systemsafety at lists.techfak.uni-bielefeld.de
> Betreff: Re: [SystemSafety] Stupid Software Errors [was: Overflow......]
>
> Peter,
>
> > I don't buy Derek Jones's or Tom Ferrell's versions of the curate's
egg. I don't see why anyone
> > else should, either. Are they still going to be saying "well, it
depends, it's complicated" in
>
> Blustering in the face of reality is unbecoming.
>
> Very thorough static analysis requires:
>
>     o lots of memory.  I have written about how optimizing compilers
took
> off in the 1990s because developers finally had computers containing
> enough memory for high level optimization techniques to be used:
>
http://shape-of-code.coding-guidelines.com/2011/10/08/memory-capacity-and-
commercial-compiler-development/
> Static analysis requires even more memory.  Cloud providers now offer
> machines containing a quarter of a terrabyte of main memory; that
> should be enough.
>
>     o lots of cpu power.  Again the cloud now provides this, but some
> work is needed to figure out how to parallelize what to data are
> single threaded solutions.
>
>     o willingness to put up with lots of false positives.  These
> customers are easy to spot because the Unicorns they rid to work on
> are corralled in the car park.
>
>     o the commercial incentive to make it happen.  My experience is
> that most developers are more interested being able to change the
> colours on the user interface that what static analysis tools do.
> Which is why after initial development most commercial static
> analysis R&D goes on the IDE.
>
> So we are now in the position that the computational resource
> problem is solved.  I don't think the last two problems will be
> solved until we start sending developers and their managers to
> prison for delivering code containing faults that could have been
> detected.
>
>
> > another twenty years when stupid coding errors still make it through
into supposedly-dependable
> > software products?
> >
> > Look at go-to fail. That's critical code! How come critical code such
as that is not routinely
> > subject to static analysis?
> >
> > Look at the 787 generator code. A systematic loss of all generators is
surely a hazardous event.
> > That should make it 10^(-7). Oh, but I forgot. Even though correct
operation of SW contributes to
> > the 10^(-7), the reliability of the SW itself is not assessed. But
surely it gets to be at least
> > DAL B, since the result is a hazardous event? Oh, but I forgot
something else. A systematic
> > failure like that would be common cause, and the certification
requirements concern single
> > failures, not common cause failures. So that's all right then. Tom's
suggestion that it might have
> > been a design compromise is vitiated by the fact that the phenomenon
is subject to an
> > AIRWORTHINESS Directive by the FAA. (Is that sufficient emphasis?)
> >
> > If people had told me thirty years ago that we'd still be making the
same stupid mistakes in the
> > same ways, but this time in code more fundamental to the safe or
secure operation of everyday
> > engineered objects, I wouldn't have believed it.
> >
> > Maybe it's a social thing. Mostly, people actually writing the code
and inspecting it are in their
> > twenties and their bosses maybe at most in their early thirties. The
young people have never made
> > *this* mistake before - the previous lot had of course, but they're
all in management now. I'm
> > reminded of Philip Larkin's ode to rediscovery, Annus Mirabilis:
> >
> > Sexual intercourse began
> > In nineteen sixty-three
> > (Which was rather late for me)-
> > Between the end of the Chatterley ban
> > And the Beatles' first LP.
> >
> > The Ensuing Discussion.
> >
> > There was obviously discussion on the list of why we are making the
same old mistakes forty years
> > after it was known how to avoid them. Some discussants suggested it
might help to professionally
> > certify software engineers, a PE. Others referred to the
Knight-Leveson study a decade ago for the
> > ACM, in which inserting SE into the current PE scheme was not seen as
advantageous. UK discussants
> > pointed out that such certification exists in the UK, as a CEng
through the BCS or IET, and that
> > there had been some UK consideration of extra qualification for
critical-software engineering.
> >
> > Such qualification for system safety hasn't (yet) generally caught on
anywhere. SARS offer it in
> > the UK for example. It didn't catch on in the US. Over a decade ago,
the System Safety Society
> > introduced an option for system safety engineering into the PE exam.
They had to pay the NPSE or
> > NCEES (I forget which) lots of money per year to maintain the option -
and two people took it in
> > some number of years. So they dropped it. (I was at the board meeting
in Ottawa in 2004 when this
> > was decided.)
> >
> > The UK qualification regime hasn't stopped IT disasters in government
procurement. And it hasn't
> > stopped the kind of poor engineering which allows bank ATMs which use
supposedly
> > pseudo-one-time-pad nonce generation to be subject to replay attacks
(see a recent paper reciting
> > local experiments performed by Ross Anderson's group). I do note,
however, that the three examples
> > I mentioned above are all US examples. It's not ruled out that having
some degree of formal
> > professional training, as in the UK, encourages software engineers to
avoid repeating simple
> > mistakes whose prophylaxis has been well known for decades.
> >
> > Time was, when UK and US cars were not known for their reliability.
Kind of like SW,
> > relatively-inexpensive cars used to go wrong a lot. However, some very
expensive cars such as made
> > by Rolls-Royce/Bentley and Wolseley were reliable. So there was proof
of concept. Japanese
> > companies decided it was possible to produce reliable
relatively-inexpensive cars and make money,
> > and did it.
> >
> > There is proof of concept in SE, too. Unlike Rolls-Royce cars, it is
not prohibitively expensive.
> > Three out of my four examples involve run-time error. It is feasible
to produce SW
> > cost-effectively which is free from run-time error. Just like the
Japanese approach to cars, you
> > just have to decide to do it.
> >
> > How about the following? We design a document called A Programmer's
Pledge. It has thirty or so
> > numbered clauses:
> >
> > * I promise never to deliver SW which is subject to a data-range
roll-over phenomenon (especially
> > dates and times)
> >
> > * I promise never to deliver software which is subject to a numerical
overflow or underflow exception
> >
> > * I promise never to deliver software which reads data on which it
raises an "out of range" exception
> >
> > * ..... and so on
> >
> > A professional programmer signs it and files it with hisher
professional organisation. Quality
> > control issues in programs (such as the above phenomena) are routinely
subject to RCA of sorts.
> > When a programmer is responsible for a piece of code with such an
error in it, the company reports
> > it to the professional organisation and the programmer gets "points"
attached to the corresponding
> > clause in hisher Pledge. Like with driving (Germans say "points in
Flensburg" which is where the
> > office is. What is it in the UK? "Points in Cardiff"?). I bet lots of
organisations, from
> > companies hiring programmers to professional-insurance companies will
find uses for it.
> >
> > PBL
> >
> > Prof. Peter Bernard Ladkin, Faculty of Technology, University of
Bielefeld, 33594 Bielefeld, Germany
> > Je suis Charlie
> > Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de
> >
> >
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> >
> > iQEcBAEBCAAGBQJVRxS0AAoJEIZIHiXiz9k+Sv4H/3qSuiODGIZarIb0Rwj4PoOR
> > gi6zvdAb1ns2A8w0xXiBz6E8+iwik53ueVxhEDTINA4RXyoLTfFEVl9yunOR0qnU
> > 7ht92kguaSjuM3BGUGYzy8MpZMjc0jyNWRmyC3wh0y3X0NnjL+/GMiqYR+3zq5RX
> > ZEzJk89SboZiB1kyTqMM+IcKzbABmk1CSaAkQziGvdJFWklNM10prMIk/5MprGwV
> > EeePB1rGs13Z1LZi8GIqdz8PDc1FKSz5qRugQ8VZJbbJvgct9JJVfEtQx3uElGkt
> > a/E5fQ/+Gw8CARMhpktEr/wLdk7t3akJvNF5iLK5W7Mbb3h0kd7sCNLZ5d9OZyA=
> > =i/nm
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > The System Safety Mailing List
> > systemsafety at TechFak.Uni-Bielefeld.DE
> > .
> >
>
> --
> Derek M. Jones           Software analysis
> tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE