Sometimes it seems that things change slowly in the world of functional safety.  If you look at many of the technical references in IEC 61508 you will find that most come from the 1980s and 1990s.  There is even one reference that dates back to 1950!  With the rate technology is moving, the relevance of such old documents often comes into question.  The topic of programming languages is one area where change is constant, and a good example of this is C++11.  This latest version of C++ is already several years old, but it is starting to become important for functional safety.  The C and C++ languages have long been known for their weaknesses due to being error prone and having too many ambiguities.  Of course these languages were not developed with functional safety in mind, and many of the initial authors of IEC 61508 felt that these languages should not be used in safety applications.  However, in the embedded world, these are still the languages of choice, and the standards allow the use of these languages if you define a language subset so that you can eliminate the more error prone parts of the language and use static analysis tools to ensure that you are adhering to the subset.    

So enter C++11.  The changes in this version of C++ are so significant that the creator of the language, Bjarne Stroustrup has remarked “Surprisingly, C++11 feels like a new language.”  From a functional safety point of view, the language has some features that help make the language less prone to error and therefore more suited for use in functional safety.  For example, the language introduces bounds checking functions to replace those that have led to security vulnerabilities.  Compile time assertions known as static_asserts have also been added.  In addition, the range of user-defined types that can be cleanly and safely expressed has grown with the addition of features such as initializer-lists, uniform initialization, template aliases, rvalue references, defaulted and deleted functions, and variadic templates.

So given C++11’s value in functional safety, a common question I am often asked is what do I have to do in order to use this language in a manner compliant with functional safety standards.  Because the language is still C++, we must still deal with the requirements from IEC 61508 that apply to this language.  This means that we must update our language subset to include the new features of C++11 that we feel are appropriate, and we need to update to static analysis tools to detect any excluded features of C++11.  A good starting point for this is the High Integrity C++ coding standard.  This coding standard was developed “for the production of high quality C++ code” and it has been updated to include many good rules relating to C++11.  If you have a good coding standard in place already, I would recommend using this standard to define additional rules based on the newly added C++11 features.  If you do not currently have a coding standard, you can use this one as a starting point, but you will need some additional requirements to fully meet the requirements from IEC 61508. 

In the automotive functional safety world, the predominant coding standard is the MISRA C and C++ guidelines.  These guidelines were written specifically with functional safety in mind.  Compliance with them satisfies the standards requirements and is typically required by the automotive OEMs as well.  However, MISRA C++:2008 has not been updated to include C++11 features yet.  So if you are living in the world of Functional Safety, and want to use C++11, my advice would be to start with the MISRA guidelines and then augment them with the High Integrity C++ coding standard.