Use of boost in safety critical work

older
Re: [boost] [asio] Is Boost.Asio...

Andrew Marlow

5 Dec 2014 5 Dec '14

9:37 a.m.

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

Show replies by date

Rob Stewart

5 Dec 5 Dec

10:07 a.m.

On December 5, 2014 4:37:53 AM EST, Andrew Marlow wrote:

...

Hello fellow boosters,

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?

I can only suggest that Boost.Units should be of significant value in such a domain, but I have no experience with safety critical development. Come to think of it, correct memory management would seem critical, so Boost smart pointers would also be valuable. Beyond that, I couldn't say. ___ Rob (Sent from my portable computation engine)

Rogerio dos Santos

12:33 p.m.

I agree with Rob. Boost smart pointers might be really valuable on such kind of development, since memory management might be critical. Another Boost libraries that might be interesting on such applications are Statechart and Meta State Machine (MSM), since on critical safety applications you might work with finite state machines that always goes to a safe and known state. In other hand, you might have a hard time convincing them to use boost since PDS (Previously Developed Software) as it may be developed independently of any specific application and not developed in house, are not necessarily compliant with the requirements they should fulfill. Even if you are able to prove that a specific boost library might fulfill all the safety requirements, you will have to stick with an specific version since the library in use might not guarantee the requirements with new updates. However, this does not means that you cannot use the boost concepts ideas and develop in-house subsets of the boost libraries that fulfills all security requirements requirements applied. On Fri Dec 05 2014 at 4:09:47 AM Rob Stewart wrote:

...

On December 5, 2014 4:37:53 AM EST, Andrew Marlow wrote:

...
Hello fellow boosters,

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?

I can only suggest that Boost.Units should be of significant value in such a domain, but I have no experience with safety critical development. Come to think of it, correct memory management would seem critical, so Boost smart pointers would also be valuable. Beyond that, I couldn't say.

___ Rob

(Sent from my portable computation engine)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Niall Douglas

12:41 p.m.

On 5 Dec 2014 at 9:37, Andrew Marlow wrote:

...

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?

I will caveat everything I am about to say in that it's been over a decade since I last worked in safety critical, and my knowledge on developments since is incomplete. Safety critical C or C++ usually means no dynamic memory allocation nor exception throwing, which poses obvious problems for any STL type design including the STL. You can use custom STL allocators which indirect to fixed sized and thread local pools, but it's a pain, and all it requires is an accidental slip in use of ::operator new by code you can't modify and it's game over. Most C++, including any STL, also assumes you can always throw exceptions. You also have an enormous problem with lack of *verified* C++ libraries as in ones formally verified as being correct which is an enormously expensive undertaking. Well, lack is the wrong word, there are plenty, it's more they very much lack in features. I am unaware of any complete C++ 98 verified STL for example. Maybe things have improved. All that said, there are many SIL4 verified C++ solutions currently powering nuclear reactors, trains, cars and so on. C++ is surprisingly popular given it would be my last recommendation for a SIL4 implementation language, but there you go. I helped out in QNX getting their BB10 derived version recertified for SIL3, and you'd be surprised at how much "modern" C++ ends up in safety critical applications. BTW, if your neonatal unit is running a SIL verified RTOS as I would assume it must, it will heavily constrain your toolset anyway probably to something not hugely capable of running Boost. Finally, for a neonatal ventilator you will find that only a tiny part needs to be 99.999999% reliable. The part which does the UI may only require 99.9% for example. That latter part should run on a separate CPU, and be verified as safe to watchdog reboot without affecting the safety critical part. You can use Boost, or Java, or whatever in the 99.9% reliable bit, and I'd also strongly consider an easier to program OS like Linux. I would strongly recommend in the strongest possible terms against using C++ or C or any unverified RTOS in the 99.999999% reliable bit, there are better languages (ADA et al) for that part which are easier to write to reach a verified and proven formal correctness. And good luck with the project. It is worth doing at least one actually safety critical project at least once in your career. You never program the same again after. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Robert Ramey

5:12 p.m.

Andrew Marlow-2 wrote

...

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?

In my limited exposure to the "safety critical" world, a big part of the job is verifying/demonstrating/documenting that each safety requirement is fulfilled by some specific piece of code. Since Boost is distributed as source code, the issues related to verifying and documenting the fulfillment of safety requirements would be EXACTLY the same for code writing in house. So SOUP wouldn't apply unless all in house written code is also considered SOUP. That's the way the system is supposed to work. I very seriously doubt that it actually works that way. I'm sure all the paperwork "proving" that all safety requirements can be traced to specific code is filed, but I doubt that the work is really rigorously done. For example, I've never seen any of these companies apply these verification/certification policies to C library source code. Actually the often will use the C libraries pre-built from the vendor so they haven't actually verified that this code even matches the library source! In many places this is used to justify a policy of "we make everything from scratch so we can verify it". This is similar to other policies such as "we make everything from scratch so no one can sue us". Or "we make everything from scratch because we have hard real-time requirements". Or whatever. So it boils down with, is one going to start with something like Boost code or code from scratch" Since some/many Boost libraries aren't really readable they wouldn't likely be suitable candidates for inclusion in such a project - while other ones would. In general, Boost code will be more likely to be correct than home brew code. If necessary, the verification/certification would be applied to the Boost code. That would satisfy all the safety certification requirements. As far as I know, no user had every contacted any author of any boost library to participate in such a certification. Actually, I don't think anyone who uses Boost (or the standard library for that matter) actually even runs the test suite which is delivered with the library. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Use-of-boost-in-safety-critical-work-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.

Vladimir Batov

8 Dec 8 Dec

12:08 a.m.

Quite a few people have already replied on this un-orthodox topic, so I am not sure if my reply will add any value (likely not). Still, I've been in rail and airline-related industries too long to remember and ultimately I second what Robert says below. Safety-critical is different from, say, embedded and it's mostly about the process and verification, etc. So, SOUP or no-SOUP any code will have to go through some verification/approval process... which is not always fun. That said, once an external library has come through that hurdle of initial acceptance -- non-SOUP certification so to speak, it does get better somewhat. Ultimately from my experience it boils down to your convictions in the value of particular s/w and your standing within the project. BTW, Boost's been absolutely essential in my work and IMO no serious project can survive without it. On 12/06/2014 04:12 AM, Robert Ramey wrote:

...

...
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? In my limited exposure to the "safety critical" world, a big part of

Andrew Marlow-2 wrote the job is verifying/demonstrating/documenting that each safety requirement is fulfilled by some specific piece of code.

Since Boost is distributed as source code, the issues related to verifying and documenting the fulfillment of safety requirements would be EXACTLY the same for code writing in house. So SOUP wouldn't apply unless all in house written code is also considered SOUP.

That's the way the system is supposed to work. I very seriously doubt that it actually works that way. I'm sure all the paperwork "proving" that all safety requirements can be traced to specific code is filed, but I doubt that the work is really rigorously done. For example, I've never seen any of these companies apply these verification/certification policies to C library source code. Actually the often will use the C libraries pre-built from the vendor so they haven't actually verified that this code even matches the library source!

In many places this is used to justify a policy of "we make everything from scratch so we can verify it". This is similar to other policies such as "we make everything from scratch so no one can sue us". Or "we make everything from scratch because we have hard real-time requirements". Or whatever.

So it boils down with, is one going to start with something like Boost code or code from scratch"

Since some/many Boost libraries aren't really readable they wouldn't likely be suitable candidates for inclusion in such a project - while other ones would. In general, Boost code will be more likely to be correct than home brew code. If necessary, the verification/certification would be applied to the Boost code. That would satisfy all the safety certification requirements. As far as I know, no user had every contacted any author of any boost library to participate in such a certification. Actually, I don't think anyone who uses Boost (or the standard library for that matter) actually even runs the test suite which is delivered with the library.

Robert Ramey

-- View this message in context: http://boost.2283326.n4.nabble.com/Use-of-boost-in-safety-critical-work-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Paul A. Bristow

6 Dec 6 Dec

11:12 a.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrew Marlow Sent: 05 December 2014 09:38 To: boost Subject: [boost] Use of boost in safety critical work

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 think this is plain wrong. Boost Libraries are all 1 Peer reviewed. 2 Documented. 3 What you see is what you get - all the source code and tests and examples are provided for you to do your own code review. 4 Provided with tests, often extensive. 5 Tested continuously on a variety of platforms. 6 In widespread use - bugs get found, reported and fixed (often quickly). 7 Community support.

...

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?

Nearly all Boost libraries assume use of exceptions, so are unsuited to applications that forbid exceptions, usually to meet hard real-time requirements. (However as others have noted, it is usually only tiny parts of systems like fighter planes and incubators that need to eschew exceptions - nearly all the rest must use exceptions to achieve any sort of quality and function in reporting and displays etc). Of course, you will need to test your own complete systems, but you can use Boost code with confidence. Enjoy! Paul PS If you buy software from other vendors, and look closely, you may find that you get a bit of Boost anyway!

Stephen Kelly

1:19 p.m.

Paul A. Bristow wrote:

...

...
It stands for Software of Unknown Pedigree. They classify boost as SOUP.

I think this is plain wrong.

If they have not investigated the pedigree of Boost, then of course it is SOUP to them. I don't see how that could possibly be wrong.

...

Boost Libraries are all

1 Peer reviewed.

The initial submission is peer reviewed. After that there is no pre-commit review requirement (I said "requirement") in Boost. The submitter/maintainer then owns all decisions related to the library. Many boost libraries have no maintainer or no active maintainer, and upkeep struggles to actually get done. Am I wrong?

...

2...7

I doubt any of that matters. I found this an interesting read this week: https://esrlabs.com/blog/estl-for-embedded-developers/ Thanks, Steve.

Edward Diener

1:46 p.m.

On 12/6/2014 8:19 AM, Stephen Kelly wrote:

...

Paul A. Bristow wrote:

...
...
It stands for Software of Unknown Pedigree. They classify boost as SOUP.

I think this is plain wrong.

If they have not investigated the pedigree of Boost, then of course it is SOUP to them. I don't see how that could possibly be wrong.

You nicely cut off Paul's further comments.

...

...
Boost Libraries are all

1 Peer reviewed.

The initial submission is peer reviewed. After that there is no pre-commit review requirement (I said "requirement") in Boost. The submitter/maintainer then owns all decisions related to the library.

Would you like all decisions for a library made by a consensus of all commenters ?

...

Many boost libraries have no maintainer or no active maintainer, and upkeep struggles to actually get done. Am I wrong?

Yes, I believe you are wrong. 1) A few libraries have no active maintainer. 2) A maintenance group of people has been formed, to which anyone may join, for libraries which have no active maintainer. 3) Occasionally upkeep struggles to get done, but Boost is pretty responsive in general IMO.

...

...
2...7

I doubt any of that matters.

Matters for what ?

...

I found this an interesting read this week:

https://esrlabs.com/blog/estl-for-embedded-developers/

Interesting but "safety critical work" does not necessarily mean embedded programming. My last consulting job was for a company essentially doing "safety critical work" ( they were periodically inspected/checked by the FDA ). They felt that Microsoft's MFC and VC++ standard libraries were "safe" but I could not convince them that using Boost libraries were "safe". They were upset when they found bug reports against some Boost libraries, but evidently were not at all upset when I conversely pointed out bug reports against MFC and the VC++ compiler.

Stephen Kelly

2:06 p.m.

Edward Diener wrote:

...

...
...
Boost Libraries are all

1 Peer reviewed.

The initial submission is peer reviewed. After that there is no pre-commit review requirement (I said "requirement") in Boost. The submitter/maintainer then owns all decisions related to the library.

Would you like all decisions for a library made by a consensus of all commenters ?

I think the initial peer review and the maintainer ownership to form a kind of interesting tension, and maybe something worth thinking about.

...

...
Many boost libraries have no maintainer or no active maintainer, and upkeep struggles to actually get done. Am I wrong?

Yes, I believe you are wrong.

1) A few libraries have no active maintainer. 2) A maintenance group of people has been formed, to which anyone may join, for libraries which have no active maintainer.

Yes, the archives of the list can be read here: http://news.gmane.org/gmane.comp.lib.boost.maint

...

...
...
2...7

I doubt any of that matters.

Matters for what ?

I doubt any of it matters to the company not currently using Boost. I doubt any of the points would change their perspective/decision. Thanks, Steve.

gast128

2:25 p.m.

Edward Diener writes:

...

On 12/6/2014 8:19 AM, Stephen Kelly wrote:

...
Paul A. Bristow wrote:

...
...
It stands for Software of Unknown Pedigree. They classify boost as SOUP.

I think this is plain wrong.

If they have not investigated the pedigree of Boost, then of course it is SOUP to them. I don't see how that could possibly be wrong.

You nicely cut off Paul's further comments.

...
...
Boost Libraries are all

1 Peer reviewed.

The initial submission is peer reviewed. After that there is no pre-commit review requirement (I said "requirement") in Boost. The submitter/maintainer then owns all decisions related to the library.

Would you like all decisions for a library made by a consensus of all commenters ?

...
Many boost libraries have no maintainer or no active maintainer, and upkeep struggles to actually get done. Am I wrong?

Yes, I believe you are wrong.

1) A few libraries have no active maintainer. 2) A maintenance group of people has been formed, to which anyone may join, for libraries which have no active maintainer. 3) Occasionally upkeep struggles to get done, but Boost is pretty responsive in general IMO.

...
...
2...7

I doubt any of that matters.

Matters for what ?

...
I found this an interesting read this week:

https://esrlabs.com/blog/estl-for-embedded-developers/

Interesting but "safety critical work" does not necessarily mean embedded programming.

My last consulting job was for a company essentially doing "safety critical work" ( they were periodically inspected/checked by the FDA ). They felt that Microsoft's MFC and VC++ standard libraries were "safe" but I could not convince them that using Boost libraries were "safe". They were upset when they found bug reports against some Boost libraries, but evidently were not at all upset when I conversely pointed out bug reports against MFC and the VC++ compiler.

We use Boost for 11 years now in our products and have gained some experience with Boost: - almost every release something gets broken. Often I post that on the mailing list but not many responses lately. I understand that testing many compilers and platforms is hard especially when the c++ language is shifting as well (e.g. circular_buffer support for move on vs2010), but perhaps Boost can adopt a model like Ubuntu does with its LTS? - some libraries seems to be orphaned (e.g. interval) which can be fatal if you depend on it. I myself feel not capable of taking over some library. - source code is available but some of them are very hard to understand. Part of this is due to the support of broken compilers, but there is also use of non obvious template or preprocessor magic. Also there is no consistent code style. This may seem a little bit harsh, but I really appreciate Boost. It has lots of fantastic and handy libraries. I cannot comment on the safety critical level. If your employer expects that every self written code or dependent code can be maintained maybe above information can help you guide in the direction to take.

Stephen Kelly

2:55 p.m.

gast128 wrote:

...

- source code is available but some of them are very hard to understand. Part of this is due to the support of broken compilers, but there is also use of non obvious template or preprocessor magic. Also there is no consistent code style.

Yes, I'd like to see more removal of ancient compiler support. We've discussed that a bit, for exactly the reason that it's easier to reason about and maintain the code: http://thread.gmane.org/gmane.comp.lib.boost.devel/244685/focus=244758 http://thread.gmane.org/gmane.comp.lib.boost.devel/244685/focus=244867 and I managed to update some stuff, but consensus wasn't fully reached http://thread.gmane.org/gmane.comp.lib.boost.devel/244876/focus=244948 and I think Daniel reverted some of my changes. And ultimately, in Boost, compiler support is an individual library maintainers decision. http://thread.gmane.org/gmane.comp.lib.boost.devel/243094/focus=243206 It's unfortunate I think. Thanks, Steve.

Mathias Gaunard

10 Dec 10 Dec

2:58 p.m.

On 06/12/14 15:25, gast128 wrote:

...

- source code is available but some of them are very hard to understand. Part of this is due to the support of broken compilers, but there is also use of non obvious template or preprocessor magic.

Is usage of template and preprocessor techniques that problematic? Sure, it's possibly a programming paradigm you're not used to, but it shouldn't prevent taking over the code once you've learned or practiced with them. I think there is too much mystification about Boost doing "magic", it's just normal C++ code, that any seasoned C++ programmer should be able to understand once he has taken the time to do so.

Stuart Dootson

4:09 p.m.

On 10 December 2014 at 14:58, Mathias Gaunard wrote:

...

On 06/12/14 15:25, gast128 wrote:

- source code is available but some of them are very hard to understand.

...
Part of this is due to the support of broken compilers, but there is also use of non obvious template or preprocessor magic.

Is usage of template and preprocessor techniques that problematic? Sure, it's possibly a programming paradigm you're not used to, but it shouldn't prevent taking over the code once you've learned or practiced with them.

I think there is too much mystification about Boost doing "magic", it's just normal C++ code, that any seasoned C++ programmer should be able to understand once he has taken the time to do so.

It's not just Boost - I've found a good deal of resistance to any 'non-obvious' code in safety-critical projects (I tried to get some code into a project that included template metaprogramming to optimise communications operations - I didn't succeed), which I can kind of understand. Without good documentation, it's not easy to pick up and, in addition, as all verification has to be performed by someone other than the person writing the code, the burden of understanding the code is required of several people, not all of whom are necessarily experienced C++ programmers (or C++ programmers at all, for that matter). Stuart

gast128

4:55 p.m.

...

Is usage of template and preprocessor techniques that problematic? Sure, it's possibly a programming paradigm you're not used to, but it shouldn't prevent taking over the code once you've learned or practiced with them.

I think there is too much mystification about Boost doing "magic", it's just normal C++ code, that any seasoned C++ programmer should be able to understand once he has taken the time to do so.

If my day time job would be a library writer or compiler builder I would deal with c++ only. However I work as an application programmer and c++ competes with many other focus points. There are some non obvious rules concerning templates which will slam in your face from time to time. Especially during Boost upgrades or compiler upgrades these things happen. For example we ran into this case when upgraded to vs2008. 'VC++2005 Compiler Error: Incorrect semantic accepted to overcome C3200' Boost uses many of this trickery. Have you ever wondered how Boost.Bind is implemented? I had to do this reverse engineering years ago when a popular Boost.Bind construct didn't work in our situation and I was wondering if it was my fault. Anyway may be you are more talented in this respect than I am. Edit: I get Gmanes 'You have lines longer than 80 characters. Fix that.'

Mathias Gaunard

11 Dec 11 Dec

2:22 p.m.

On 10/12/14 17:55, gast128 wrote:

...

Boost uses many of this trickery.

In my experience, it's not so much trickery as normal usage of the language constructs as defined by the standard. Visual Studio is riddled with strange bugs which make perfectly simple code randomly cease to function under certain situations, even with the latest 2012 or 2013 versions. If you ignore the workarounds, it's not that tricky.

Niall Douglas

6 Dec 6 Dec

2:29 p.m.

On 6 Dec 2014 at 8:46, Edward Diener wrote:

...

My last consulting job was for a company essentially doing "safety critical work" ( they were periodically inspected/checked by the FDA ). They felt that Microsoft's MFC and VC++ standard libraries were "safe" but I could not convince them that using Boost libraries were "safe". They were upset when they found bug reports against some Boost libraries, but evidently were not at all upset when I conversely pointed out bug reports against MFC and the VC++ compiler.

"Safe" in this context means there is someone to sue. It has a huge effect on insurance premiums if there is no one to sue, you can't securitise and package off the risk you see because of counterparty risk. Also, "safety critical" isn't some nebulous adjective. It's rigorously defined in an IEC standard. And put simply, it means you cannot put software which has not been verified by someone recognised by insurers into a safety critical system. That perversely enough can mean that stonking pieces of known crap closed source software can be allowed in, while almost all open source is almost always excluded because its review processes aren't recognised by insurance. There are occasional exceptions, for example SQLite3 someone paid for a full SIL verification and analysis, so it gets in. Its unit test suite really is the gold standard for computer software, it's *amazing*. And compared to SQLite3's testing, we here in Boost are in the stone age - but then we are nothing like as well financed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Andrew Marlow

2:31 p.m.

Thank you all for your comments so far. On 6 December 2014 at 13:46, Edward Diener wrote:

...

My last consulting job was for a company essentially doing "safety critical work" ( they were periodically inspected/checked by the FDA ). They felt that Microsoft's MFC and VC++ standard libraries were "safe" but I could not convince them that using Boost libraries were "safe". They were upset when they found bug reports against some Boost libraries, but evidently were not at all upset when I conversely pointed out bug reports against MFC and the VC++ compiler.

This is what I suspect the company attitude will be in my particular case. I am not really interested to hear stories about well established, widely used and respected boost is. I already know that. As far as I am concerned boost is the next best thing to it coming from the std library and in many cases boost work has gone on to become part of the std. However, company attitudes differ. In my case the company hasn't even heard of boost so it is definately SOUP as far as they are concerned. So I was wondering how widespread this phenomenon is in safety critical circles and how seasoned boost-aware developers deal with it. As someone else has already said, boost code is not very readable which casts doubt on being able to use it to simulate having developed the code in-house from scratch. So what do people do instead? -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk

Paul A. Bristow

4:08 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrew Marlow Sent: 06 December 2014 14:31 To: boost Subject: Re: [boost] Use of boost in safety critical work

Thank you all for your comments so far.

On 6 December 2014 at 13:46, Edward Diener wrote:

...
My last consulting job was for a company essentially doing "safety critical work" ( they were periodically inspected/checked by the FDA ). They felt that Microsoft's MFC and VC++ standard libraries were "safe" but I could not convince them that using Boost libraries were "safe". They were upset when they found bug reports against some Boost libraries, but evidently were not at all upset when I conversely pointed out bug reports against MFC and the VC++ compiler.

This is what I suspect the company attitude will be in my particular case. I am not really interested to hear stories about well established, widely used and respected boost is. I already know that. As far as I am concerned boost is the next best thing to it coming from the std library and in many cases boost work has gone on to become part of the std. However, company attitudes differ. In my case the company hasn't even heard of boost so it is definately SOUP as far as they are concerned. So I was wondering how widespread this phenomenon is in safety critical circles and how seasoned boost-aware developers deal with it. As someone else has already said, boost code is not very readable which casts doubt on being able to use it to simulate having developed the code in-house from scratch. So what do people do instead?

Your company has the "nobody ever got fired for buying IBM" syndrome. If they have not even *heard* of Boost, *they* are of Unknown Pedigree? Ultimately, much of meeting regulators (and insurers) requirements comes down to code review and, above all, testing. You can see the source code (though obfuscated by the requirement to cover compiler 'features') and you can see what tests are carried out. This is usually more than you can *see* with code from, say, Microsoft. Which is why I said "What You See Is What You Get". You can, of course, also be much assured by the prospect suing Microsoft for the many deficiencies in their code ;-) That C++ and Boost is being used in car embedded systems should give you some reassurance, but in the end it is the software engineers who carry the can. After all, the tools are all a way of producing assembler/machine code. Enjoy! Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Oliver Kowalke

4:27 p.m.

...

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'.

if it is safety critical than you should consider SPARK 2014-12-06 17:08 GMT+01:00 Paul A. Bristow :

...

...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrew Marlow Sent: 06 December 2014 14:31 To: boost Subject: Re: [boost] Use of boost in safety critical work

Thank you all for your comments so far.

On 6 December 2014 at 13:46, Edward Diener wrote:

...
My last consulting job was for a company essentially doing "safety critical work" ( they were periodically inspected/checked by the FDA ). They felt that Microsoft's MFC and VC++ standard libraries were "safe" but I could not convince them that using Boost libraries were "safe". They were upset when they found bug reports against some Boost libraries, but evidently were not at all upset when I conversely pointed out bug reports against MFC and the VC++ compiler.

This is what I suspect the company attitude will be in my particular case. I am not really interested to hear stories about well established, widely used and respected boost is. I already know that. As far as I am concerned boost is the next best thing to it coming from the std library and in many cases boost work has gone on to become part of the std. However, company attitudes differ. In my case the company hasn't even heard of boost so it is definately SOUP as far as they are concerned. So I was wondering how widespread this phenomenon is in safety critical circles and how seasoned boost-aware developers deal with it. As someone else has already said, boost code is not very readable which casts doubt on being able to use it to simulate having developed the code in-house from scratch. So what do people do instead?

Your company has the "nobody ever got fired for buying IBM" syndrome. If they have not even *heard* of Boost, *they* are of Unknown Pedigree?

Ultimately, much of meeting regulators (and insurers) requirements comes down to code review and, above all, testing.

You can see the source code (though obfuscated by the requirement to cover compiler 'features') and you can see what tests are carried out. This is usually more than you can *see* with code from, say, Microsoft. Which is why I said "What You See Is What You Get".

You can, of course, also be much assured by the prospect suing Microsoft for the many deficiencies in their code ;-)

That C++ and Boost is being used in car embedded systems should give you some reassurance, but in the end it is the software engineers who carry the can. After all, the tools are all a way of producing assembler/machine code.

Enjoy!

Paul

--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Christopher Kormanyos

4:40 p.m.

>> 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 think this is plain wrong.
This is an interesting topic.
I am a guy who uses Boost, writes Boost, and worksintensely on safety-critical embedded systems --- justnot at the same time.
My advice is you familiarize yourself with the culture atthe potential job. Questions to ask are things such as:
* Does the software require adherence to quality standardssuch as SPICE?
* Do the products (and subsequently the software development)require adherence to safety standards such as ISO 26262?
* Will the software development be audited regardingits quality.
* Do you need to have traceability from source code totest case?

* Is C++ even allowed?
* Will the development use dynamic memory allocation?
* Will the development use exception handling?
* What size of project are you talking about?
* Will an underlying OS be running such as embedded
*nix, or will you be programming "on-the-metal".
Answering some of these questions should providea basis for deciding to use non-certified softwaresuch as Boost.
Sometimes all it takes is a list documenting the useof non-certified freeware in order to defend its usein an audit-type situation. Testing, traceability andtest coverage subsequently validate the tool in theproduct.

Cheers, Chris.

     On Saturday, December 6, 2014 12:12 PM, Paul A. Bristow  wrote:

> -----Original Message-----
> From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrew Marlow
> Sent: 05 December 2014 09:38
> To: boost
> Subject: [boost] Use of boost in safety critical work
> 
> 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 think this is plain wrong.

Boost Libraries are all

1  Peer reviewed.

2  Documented.

3  What you see is what you get - all the source code and tests and examples are
provided for you to do your own code review.  

4  Provided with tests, often extensive.

5  Tested continuously on a variety of platforms.

6  In widespread use - bugs get found, reported and fixed (often quickly).

7  Community support.

 > 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?

Nearly all Boost libraries assume use of exceptions, so are unsuited to
applications that forbid exceptions, usually to meet hard real-time
requirements.

(However as others have noted, it is usually only tiny parts of systems like
fighter planes and incubators that need to eschew exceptions - nearly all the
rest must use exceptions to achieve any sort of quality and function in
reporting and displays etc).

Of course, you will need to test your own complete systems, but you can use
Boost code with confidence.

Enjoy!

Paul

PS If you buy software from other vendors, and look closely, you may find that
you get a bit of Boost anyway!

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Mathias Gaunard

8 Dec 8 Dec

12:35 p.m.

On 06/12/14 12:12, Paul A. Bristow wrote:

...

Nearly all Boost libraries assume use of exceptions, so are unsuited to applications that forbid exceptions, usually to meet hard real-time requirements.

That's not true. Most people have done the required work to make their libraries work correctly without exceptions. It's simple, all you have to do is use BOOST_THROW_EXCEPTION instead of throw. Then you can globally disable exceptions and define your own function that gets called instead. Of course this is a bit limited, as you cannot easily do proper error management, but most of the time it is good enough.

Stuart Dootson

9:37 a.m.

On 5 December 2014 at 09:37, 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.

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

dgutson .

9 Dec 9 Dec

11:57 a.m.

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? 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). Daniel.

...

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

-- Who’s got the sweetest disposition? One guess, that’s who? Who’d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck?

Andrew Marlow

12:06 p.m.

On 9 December 2014 at 11:57, dgutson . wrote:

...

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.

Indeed. Many thanks to all those who have contributed so far.

...

Question to Andrew: what about the STL then, do they classify as SOUP too? Or they have a verified implementation?

The STL is suspect and they do classify it as SOUP. They do not have a verified implementation, they use the one that comes with Visual Studio 2008. Since it is viewed with suspicion only certain parts of it are used.

...

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.

Will do. Thanks for the heads up.

...

Maybe, we could broaden the group's scope to include safety critical systems too (just thinking).

Daniel.

-- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk

Christopher Kormanyos

9:21 p.m.

...

...
...
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.

...

Indeed. Many thanks to all those who have contributed so far.

...

...
Question to Andrew: what about the STL then, do they classify as SOUP too? Or they have a verified implementation?

...

The STL is suspect and they do classify it as SOUP. They do not have a verified implementation, they use the one that comes with Visual Studio 2008. Since it is viewed with suspicion only certain parts of it are used.

Hi Andrew and everyone, Another option you might consider regarding the STL is to write yourown small subset of the STL. If you go this way, you must dilligentlyattempt to adhere to standards. Try as best as possible to verifywhat you write with rigorous testing. When writing non-certified subsets of the STL for microcontrollers,I concentrate on those parts of the STL that reliably avoid dynamicmemory allocation and exceptions. It is amazing how far you canget with: * parts of <algorithm>* <array>, but with exceptions not implemented for range-check * <cstddef> * <cstdint>* * <iterator>* <limits> * <numeric>* a subset of <tuple>, but without allocators and implemented withlimited parameter count, not variadic templates.* parts of <utility>* parts of * if you really get crazy, <chrono>, <ratio>, and * and probably a few I forgot You might find inspiration from Chapter 16 in my book below. Real-Time C++ - Efficient Object-Oriented and Template Microcontroller Programming You might also take a look at my (non-certified!) extremely-partial subsetof the STL below. It was originally written for GCC and Atmel(R) AVR(R)8-bit microcontrollers. But I also have used it (or variations of it) withother compilers such as IAR systems, Wind River and others.Look in the directory "impl" for coding details. https://github.com/ckormanyos/real-time-cpp/tree/master/ref_app/src/util/STL Cheers, Chris On Tuesday, December 9, 2014 1:06 PM, Andrew Marlow wrote: On 9 December 2014 at 11:57, dgutson . wrote:

...

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.

Indeed. Many thanks to all those who have contributed so far.

...

Question to Andrew: what about the STL then, do they classify as SOUP too? Or they have a verified implementation?

...

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.

Will do. Thanks for the heads up.

...

Maybe, we could broaden the group's scope to include safety critical systems too (just thinking).

Daniel.

-- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ion Gaztañaga

10:32 p.m.

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

3622

Age (days ago)

3628

Last active (days ago)

List overview

Download

26 comments

16 participants

participants (16)

Andrew Marlow
Christopher Kormanyos
dgutson .
Edward Diener
gast128
Ion Gaztañaga
Mathias Gaunard
Niall Douglas
Oliver Kowalke
Paul A. Bristow
Rob Stewart
Robert Ramey
Rogerio dos Santos
Stephen Kelly
Stuart Dootson
Vladimir Batov