Re: [boost] Use of boost in safety critical work

Subject: Re: [boost] Use of boost in safety critical work
From: Stuart Dootson (stuart.dootson_at_[hidden])
Date: 2014-12-08 04:37:06

On 5 December 2014 at 09:37, Andrew Marlow <marlow.agents_at_[hidden]> wrote:

> Hello fellow boosters,
>
> I am currently considering a job which involves embedded safety critical.
> It is for a neonatal ventilator so the safety critical aspect really is
> critical rather than just 'jolly important'. The company says the
> development will be in C++ but they have not even heard of boost, let alone
> use it. They introduced me to a new acronym, well new to me anyway: SOUP.
> It stands for Software of Unknown Pedigree. They classify boost as SOUP.
>
> I have used boost before in embedded work but I have never done safety
> critical work before so I don't know how widely boost is used there. Can
> anyone who *has* worked on safety critical stuff comment please?
>
> --
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

Andrew - I've worked in safety-critical embedded development within the
aerospace domain (working to DO-178B, Level A), and we used the 'SOUP'
concept for all code that wasn't written by ourselves (including the parts
of the C/C++ runtime that we used). All that meant really was that we would
construct a specification for the functions we were using, derived from
whatever requirements applied to that part of the code, and then would
perform verification (code review, unit test with a target of 100% MC/DC
coverage) as if we had written the code in-house. By doing this, we were
looking to generate confidence in that code in the same way that we would
generate confidence in our own code.

Boost wasn't used on our project (and neither were dynamically assigned
memory, exceptions, unbounded loops or several other C++ features - even
virtual functions were still a bit of a thorny subject (especially for
verification) back then). The only parts of the STL we used were some
algorithms and function binders, together with a class that was equivalent
to what is now std::array.

The majority of the projects I worked on, however, used SPARK, which I have
to say *is* a better match for that domain than C++, much as I prefer C++
to Ada...

Stuart Dootson