Boost logo

Boost :

Subject: Re: [boost] Use of boost in safety critical work
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2014-12-09 17:32:03


El 09/12/2014 12:57, dgutson . escribió:
> On Fri, Dec 5, 2014 at 6:37 AM, 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.
>
> Hi Andrew, and everybody.
> This is a so fruitful thread, full of information.
> Question to Andrew: what about the STL then, do they classify as SOUP
> too? Or they have a verified implementation?

I've been working in Embedded and Safety critical systems for some
years, I would not definitely use Boost for safety critical systems, and
any Independent Safety Assessor would forbid that. In Safety Critical
systems you need evidences that every line has been developed according
to standard guidelines and procedures (e.g. IEC 61508, DO-178B) or that
you can detect nearly all the failures of the Sw you are using.

For high integrity systems, testing (around 100% MD-DC coverage) and
documentation would be prohibitive for projects like Boost. Some studies
estimate that every line of SIL3 SW code could costs around 100€/$. Not
to mention assembly level coverage required by DO-178B Level A.

In high integrity systems Boost and other 3rd party code could be used
to implement some non-safety related requirements provided they are
executed in separate processes protected (in time and space using the
MMU) by certified Operating Systems (I can mention Integrity, VxWorks,
QNX...) and provided risks and failures that Boost and other code could
introduce could be detected and mitigated by safety code (say, if Boost
code processes some protocol layers, the safety layer could implement
its own basic sequence/CRC failure detection techniques and can lead the
system to the safe state if something strange is detected).

For lower integrity systems, Boost could be used provided some safety
code that runs independently (e.g. in a different processor) can detect
and mitigate errors. But this is really hard to justify or implement
although not impossible. An example: you could implement a human-machine
interface display in Qt/Boost if the safety function is to show the
correct speed to the driver from a command received by a communication
bus. You could implement a parallel circuit in a FPGA or processor,
sniff the commands from the communication bus and do some image
recognition of the video memory or directly the screen using some image
reflexing technology, just to check that the number shown is the one
that was commanded in the protocol. And notify the driver if that0s not
the case so that it can stop the system. Every safety related device is
different and fulfills different safety functions that you must
carefully analyze.

> Regarding the others, sorry the spam, but I don't want to loose this
> opportunity: I'm pursuing the creation of a "C++ for embedded and
> real-time systems" Study Group within the Standard, so I'd like to
> invite interested people to join to the mailing list in order to
> participate in the discussions and in the proposals. For those
> interested, just email me privately. Maybe, we could broaden the
> group's scope to include safety critical systems too (just thinking).

Good idea. Where can we subscribe to the mailing list? It would be also
great if we could form a Boost group for embedded/realtime/safety
systems so that some libraries could be used/measured for embedded
systems (we could measure code bloat, etc.). That should include, IMHO
some alternatives for code executed without exception support.

Best,

Ion


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk