Frequently Asked Questions AUTOSAR C++14 Coding Guidelines General Q: What is AUTOSAR? A: AUTOSAR (AUTomotive Open System ARchitecture) is a partnership of over 180 automotive manufacturers, automotive suppliers, tool vendors and semiconductor vendors, AUTOSAR s core members include: BMW, Bosch, Continental, Daimler, Ford, GM, PSA, Toyota and Volkswagen. Its aims to standardize and future-proof basic software elements, interfaces and bus systems, to help vehicle manufacturers manage growing system complexity while keeping costs down. It develops standardized open software architectures for automotive Electronic Control Units (ECUs). Q: What are the AUTOSAR C++14 coding guidelines? A: Coding guidelines are a set of best practice rules for the use of a programming language. They help prevent bugs and ensure that software behaves as intended. They help ensure that systems operate safely, securely and reliably. The AUTOSAR Guidelines specify 342 coding rules for modern C++. 154 of these are adopted directly from the widely adopted MISRA C++ standard. 131 are based on rules identified in other well-known coding standards, such as PRQA s High Integrity C++. 57 are based on research or other resources. The Guidelines permit some of the language features prohibited by some previous standards. Examples include: Dynamic memory, exceptions, templates, inheritance and virtual functions. There are rules to ensure that these language features are used only in a safe manner. Q: Why are the AUTOSAR coding guidelines needed? A: There have been a number of changes since the introduction of C++03 which has reduced the relevance of the MISRA standard for the AUTOSAR project: 1. Evolution of C++ 2. Compiler improvements 3. Improvements to testing, verification and analysis tools 4. Creation of the ISO 26262 Vehicle Functional Safety Standard 5. Assimilation of a broader base of safety and security expertise into additional standards such as: High Integrity C++ (PRQA) Joint Strike Fighter Air Vehicle C++ (Lockheed Martin) CERT C++ (Carnegie Mellon) C++ Core Guidelines (Bjarne Stroustrup and Herb Sutter) AUTOSAR designed the Guidelines to be used as an extension to the existing MISRA C++ standard. It specifies new rules and updates to MISRA rules as well as stating which MISRA rules are obsolete. 1 PROGRAMMING RESEARCH LTD. 18
Q: Which other standards does AUTOSAR refer to? A: Appendix A of the AUTOSAR Coding Guidelines document gives details about the traceability of the guidelines to five widely adopted C++ coding standards: MISRA C++, High Integrity C++ 4.0, JSF, SEI CERT C++ and the C++ Core Guidelines. For each rule of these standards it is established how it relates to the AUTOSAR Guidelines. A rule can be categorized as: 1. Identical (only for MISRA C++): the rule text, rationale, exceptions, code example are identical. Only the rule classification can be different. There can be also an additional note with clarifications. 2. Small differences: the content of the rule is included by AUTOSAR Guidelines rules with minor differences. 3. Significant differences: the content of the rule is included by AUTOSAR Guidelines with significant differences. 4. Rejected: the rule in the referred document is rejected by AUTOSAR Guidelines. 5. Not yet analyzed: at the time of release of the Guidelines, the review of all standards was incomplete, so a number of rules is still to be analyzed. Below chart gives a summary of the comparison. C P P C G 160 44 1 81 C E R T 36 24 29 62 J S F 105 47 53 H I C P P 101 11 M C P P 146 35 26 1 - Identical 2 - Small differences: 3 - Significant differences 4 - Rejected 5 - Not yet analyzed Because the Guidelines are based on MISRA C++, it could be expected that this is where the largest overlap can be seen. The second largest overlap is with High Integrity C++ followed by JSF, C++ Core Guidelines and finally SEI CERT C++. It must be noted, however, that CERT C++ has the largest portion of rules that still need to be analyzed which may change its position relative to the other standards. In the following sections, we will discuss the comparison in more detail for each standard and also how the AUTOSAR Guidelines relate to ISO 26262. Q: As the AUTOSAR coding guidelines have been released with the Adaptive Platform, do I need to use this platform in order to apply the coding standard? A: No. The APIs within the Adaptive Platform are defined in C++, suggesting that AUTOSAR views C++ as the language of choice for new Adaptive Platform components. However, the AUTOSAR guidelines can be applied to any type of embedded system. 2 PROGRAMMING RESEARCH LTD. 18
Q: How do I ensure my code complies with AUTOSAR guidelines? A: PRQA s QA C++, with the AUTOSAR Compliance Module is the only static analysis solution that is optimized for AUTOSAR-compliant software development. For medium to large development teams the solution may be further enhanced with PRQA s code quality management control center, QA Verify. This guarantees that all team members consistently apply the coding guidelines in addition to tracking and reporting code quality for the duration of the project. Q: Would you recommend that we stop using MISRA C and move towards AUTOSAR and MISRA C++14? A: The simplicity of the C language has its advantages and disadvantages. It is an advantage that nothing is hidden. However, a disadvantage might be that a large amount of boiler plate code is required when higher level features are required. Simply compiling C code with a C++ compiler may find gotchas with using C, such as non-const string literals, implicit casts, jump-over initializations, and more recently removed features such as trigraphs. Possibly more important is the distinction that a violation of shall in C means undefined behavior whilst, in C++ it means that the program is ill-formed. There are quite a few MISRA C rules that are unnecessary in a C++ coding standard, as it is a requirement that C++ compilers generate the appropriate errors. A common concern with using C++ is the implicit behavior added silently by the compiler. With the correct resources and education, including a judicious tool choice, what the compiler provides for free, and why, will become understood. An educated choice can then be made regarding the use of the feature. It s worth noting that, with the amount of use and testing of a commercial compiler it s far less likely to find a problem in its implementation of a vtable compared to a home grown hand written lookup table of function pointers. Q: It is often said that C++ is not suitable for use in projects such as AUTOSAR, is this not still the case? A: There is nothing inherent in C++ that, for the same use of language, makes it less efficient or less safe than C. Furthermore, it will often be the case that a compiler can optimize C++ constructs more efficiently than their C equivalent. For example, a compiler could determine the dynamic type of an object and bypass the virtual function mechanism completely. 'Templates allow for compile time polymorphism, which may actually result in less code being generated because the choice of algorithm is made at compile time and not at runtime. Regarding memory leaks, the RAII (Resource Acquisition Is Initialization) pattern is an automatic mechanism that ensures zero leaks, and it does not have a C equivalent. Q: Does AUTOSAR have a coding standard for the C language? A: There is no official C coding standard published by AUTOSAR. MISRA C is the predominant standard used for C projects. Q: How do the C++ guidelines "from Stroustrup and Sutter" relate to the AUTOSAR guidelines? A: The C++ Core Guidelines are a referenced source of rules in the Guidelines. Similar to HIC++, the requirements of the audience using the Guidelines and the C++ Core Guidelines are slightly different. AUTOSAR is targeting safety related. It therefore includes rules that would be too restrictive in other 3 PROGRAMMING RESEARCH LTD. 18
domains. Both HIC++ and the Core Guidelines are intended to be used by any programmer in any domain. Q: Why did AUTOSAR create a new standard instead of simply an update to MISRA C++? A: Work is taking place on a MISRA C++ standard. The overlap between AUTOSAR and MISRA C++ is significant, and we expect that a new, updated MISRA C++ standard will embrace the work of AUTOSAR. Q: Does AUTOSAR include rules for cybersecurity? A: Today there are no security rules. However, we believe that there are plans to include such rules in the future. Q: Does AUTOSAR also advise on the allowed libraries? E.g. Boost? A: Rule A17-0-2 clarifies that the guidelines equally apply to 3rd party library source code. A safe approach is to assume that a 3rd party library is treated in the same way as code directly related to the project. Q: What do you think about using sanitizers? A: Every tool that can improve the quality and safety of source code should be used if available. C++ Specific Q: Why are "new/delete" and "dynamic_cast" forbidden in the AUTOSAR coding standards? May one use _implicit_ new/delete? A: Explicit calls to new and delete are forbidden. However, implicit use, for example through std::string or std::vector, are allowed, which will guarantee that the lifetime of the memory is managed correctly. The guidelines include an advisory rule against the use of dynamic_cast, the main reason being that dynamic_cast relies on a significant amount of implementation-defined behavior. However, there is also an argument that the language provides better alternatives, for example virtual functions, which should be used instead. Q: Why is 'wchar' forbidden? A: Unlike 'wchar_t', the 'char16_t' and 'char32_t' types, the char16_t and char32_t types added in C++ 11 have well-defined semantics and sizes. AUTOSAR recommends using these instead of wchar_t. Q: Does AUTOSAR include basic coding parts related to the style usage (indention, brace placement, etc.)? A: No. Rules in the referenced standards were not included if they referred to style only. Despite this, there are some rules, such as requirements on filename extensions, which may be considered stylistic. Some of the existing naming rules are being reviewed and are likely to be relaxed in a future version as coding style is seen to be outside of the scope of the coding guidelines. 4 PROGRAMMING RESEARCH LTD. 18
Q: Can you provide more detail on exactly what AUTOSAR is saying about the use of dynamic memory? A: The rules forbidding direct calls to new/delete help ensure correct lifetime management of memory resources. However, they will not cover resource exhaustion. Rule A18-5-5, is a partially-automated rule which requires that memory allocation functions have deterministic behavior and do not run out of memory. Depending on the safety level of a project, it may well be that memory allocation should be banned, or at least constrained to startup only, with adequate analysis performed to ensure that resource exhaustion can never happen. ISO 26262 Q: Can you use the AUTOSAR guidelines to comply to ISO 26262? A: ISO 26262 is a Functional Safety standard for Road vehicles. The standard is derived from the Functional Safety standard IEC 61508 titled Functional safety of electrical/electronic/ programmable electronic safety-related systems. It covers all aspects of system development, and is not a coding standard. Part 6 exclusively covers software. It does not prescribe the use of any specific programming language, but specifies compliance tables with recommendations for the use of certain methods in software development for each automotive safety integrity level (ASIL). In the current release of the Guidelines, in section 3.2 it states that traceability to ISO 26262 is not provided. It states that this is a limitation that will be addressed in future versions of the document. At first sight there are some obvious inconsistencies between ISO 26262 and AUTOSAR. For example, ISO26262 compliance table 8, method 1a highly recommends one function exit point, where the Guidelines allow more. There is a rationale given on section 6.15 Exception Handling: the Rule A15-0-1 prohibits the usage of exceptions for normal control flow of software - they are allowed only for errors where a function failed to perform its assigned task. Moreover, AUTOSAR C++ Coding Guidelines does not force developers to strictly follow single-point of exit approach as it does not necessarily make the code more readable or easier to maintain. The short answer is that AUTOSAR can help you to comply with ISO26262, but in itself it will not be enough. ISO 26262 is about the entire system design - much more than simply how you write code. When it comes to your code you will need to supply a rationale for any apparent deviation from the ISO 26262 recommended methods. About PRQA: AUTOSAR invited PRQA to help ensure the safety and security of the code written by implementers of AUTOSAR software, and join the working group to develop the Guidelines for the use of the C++14 language in critical and safety-related systems. As the exclusive static analysis development partner in AUTOSAR we have contributed our expertise in the C++ programming language and best-practice software development gained over the last 30 years. www.prqa.com 5 PROGRAMMING RESEARCH LTD. 18