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

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