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

El 09/12/2014 12:57, dgutson . escribió:

On Fri, Dec 5, 2014 at 6:37 AM, Andrew Marlow 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