Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 11 minutesWe gathered a group of industry experts here at Parasoft for a roundtable style discussion of what the future holds for MISRA C++ and what the expected impact and benefits will be from this new, merged standard.
The participants are:
Mirek: Although both of these standards have an automotive origin, it’s very common for us to see them being used in the compliance process with not only ISO 26262 for automotive, but also with IEC 61508, the industrial automation standard, and with medical devices and IEC 62304. So when we’re talking about MISRA and AUTOSAR, it’s not just for the automotive industry.
In terms of issues, based on my experience working with different customers across several industries, I would say that the hardest parts of compliance with a coding standard are:
Success definitely depends on the way the standard is introduced to the organization, and building the process for compliance is critical for the success of the adoption of any functional safety standard, these two included.
Andrey: I definitely agree. A common issue we see with using static analysis for MISRA C++ and AUTOSAR C++ rules is the number of violations reported. If you turn on all the rules, you will have a lot of violations, and I mean a lot, especially for a legacy code base.
So right now, I think the approach that most customers are taking is trying to find a middle ground. Not all of the rules are mandatory or required. So they need to develop a good process. For example, they run some checkers and do some analysis on the code and figure out what would be the subset of rules that is applicable to their development and documenting that subset. They understand they don’t need to be compliant with all the rules – they just need to have justification for why the rule wasn’t used, document it, and that is perfectly okay.
Once they understand the process, they run an analysis and even with a backlog of 1000s of warnings, these customers can draw a line in the sand and move forward with a backlog of issues, with an intention of getting back to them and fixing them at some point.
Michal: Yes — I think an additional reason for the struggle here is that, for companies that are trying to finally achieve compliance with a coding standard like MISRA, even though they start development of new code, they are looking at compliance towards the end of the development lifecycle, rather than trying to start at the beginning. Starting late is one of the biggest reasons why they might encounter a large number of violations in the first place.
Andrey: Many organizations are actually already using their own internal coding standard for C and C++ that has been developed internally and used for years. These companies have an internal document and policies that they follow, and they need to modernize to a standard like MISRA, but the corporate momentum is so large that it takes a long time to change.
The strategy for those organizations is to go through violations, looking at their own coding standard, and then mapping Parasoft static analysis checkers to their own coding standard while also examining where their own coding standard needs to be updated with respect to MISRA and updates to the C language.
With C++, the situation is actually worse currently because of the older coding standards. They don’t support new language constructs such as auto pointers and other things that the new modern C++ brings to the table, so the process is more time-consuming.
Mirek: I mentioned that we see AUTOSAR C++ and MISRA C++ being frequently used as part of the compliance process for functional safety standards like ISO 26262 and IEC 61508. Compliance with these functional safety standards requires a disciplined development process, which includes preparation of documentation. Customers need a way to formally prove that they are compliant with the functional safety standards, and also with a coding standard, which is a part of the compliance process for functional safety.
With MISRA C++ and AUTOSAR C++, Parasoft tools provide dedicated support for this formal side of the compliance process. Our reporting framework generates special documentation that conforms to the requirements defined in the MISRA Compliance:2016 “Achieving Compliance with MISRA Coding Guidelines”document. This ends up being very important. Customers that are trying to achieve compliance with the standard have this part of the compliance process automated by using Parasoft tools.
standards, is that the standards themselves also provide some categorization mechanisms for their rules, which greatly helps the organization bring in the standard. For MISRA C++ for example, there are different categories for the guidelines (mandatory, required, and advisory). Same for the AUTOSAR C++ set, and there is also some additional framework for categorizations. This mechanism can also be used to make the whole implementation process easier and basically help people do it in phases, starting from the most critical category and cleaning the code, and then going further.
Andrey: Organizations haven’t necessarily thought about it. The biggest request I get as a solution architect is something like, “Okay, Parasoft, we see that you have thousands of rules, and we have this large code base. Help us select the rules that help us find real bugs, actually find something interesting, something of value, something that is worth fixing.”
At that point, we take a step back to figure out what their specific goals are. But we often do see customers starting out more generally, because despite the need to comply with a coding standard, they don’t have the time to go through all the rules and analyze them. So that’s where the categorization and general prioritization comes in.
We can also ask team management whether or not they require a hardline approach to compliance, for example, following all of the required and mandatory rules. Most of the time, management will not draw that line, and instead leave the decision to their engineers, who are “smart enough” to figure out which rules are needed to be compliant. The expectation is that the development team will document their justification of why rules have been turned on or off.
So from that perspective, I haven’t seen people actually “enforcing.” It’s more of an educational approach. For example, when I explain that there are required and mandatory rules, and you can deviate from the rules (but you have to document as specified by the MISRA 2016 compliance document), this can actually be quite the eye-opener to a lot of people. From my experience, there is definitely a learning curve and a need for consulting in this space.
Mirek: I agree — we see a significant need here in not just the automotive industry but other safety-critical organizations as well, to get consulting services to more practically enforce the standard and prioritize actions around getting there. We have several partners that help serve our customers in this space, but the need is clearly there to get more education and enforcement.
Piotr: The main reason for merging the standards was simply to have a single standard for C++. Historically, MISRA C++ 2008 was based on C++ 2003, and MISRA C++ is almost 10 years old. AUTOSAR C++ was strongly based on MISRA C++ 2008 at the beginning, but then added a lot of new rules on top that are more relevant to modern C++, including features from C++11 and C++14. So, the main driving force for integrating both standards was to take what the AUTOSAR C++ group has done and transform it in the next MISRA C++ standard.
Michal: Yes, this is the plan. The annotations in the current version of AUTOSAR C++ reference future deltas to the coding guidelines that are to be driven by MISRA. So we can think about AUTOSAR C++, as Piotr said, as an updated version of the MISRA C++ standard, based on MISRA C++, with a number of rules literally taken from MISRA. Some of these rules were updated, and rules were added. So the plan is to take these updated rules and bring them back to MISRA C++.
Mirek: I think there’s great value in having one standard on the market. We’ve talked to many organizations who were reluctant to adopt a standard for compliance because they were not sure if there would be an update coming from MISRA and were thinking about adopting AUTOSAR C++ instead. So they were postponing this decision. So the merger clarifies the situation and the obvious benefit is there being only one standard on the market and basically, there is no doubt about which way to go – the new MISRA C++ standard becomes the primary choice for compliance.
Mirek: Definitely there will be an impact. For example, if an organization that relies on MISRA C++ 2008 wants to move to AUTOSAR C++, they have to deal with approximately 200 new rules (because in the current AUTOSAR C++ version 18.10, about 45% of rules were directly inherited from MISRA C++ 2008).
So if an organization is relying on MISRA C++ 2008, migrating to AUTOSAR C++ is a significant effort for them. But, there is also a huge value in doing it, because the delta between MISRA C++ 2008 and AUTOSAR C++ addresses the changes in the C++ language since 2003. So all the novelties in C++11 and C++14 are included in AUTOSAR C++. So yes, there is an impact, but there is also a lot of value to updating to the new standard.
Andrey: If a customer changes from MISRA C++ and they were already conforming to their established coding standard, and they change standards to say, AUTOSAR C++, the impact can also sometimes be more logistical.
These customers have already justified internally, documented, and suppressed warning, and potentially even gone through audits. For example, let’s say MISRA C++ rule 11.5 has been violated but the deviation was recorded and documented. That’s an example of a suppression, or in this case a deviation, and it requires reports and paperwork. Now, if I move to AUTOSAR C++, this rule from MISRA C++ may be the same rule under the hood, but the tool vendor is reporting this as AUTOSAR C++ rule 17.6. It’s a different name, but that’s the only difference – just the label. However, the static analysis tool is flagging this as an error again and disregards the suppression. The suppression was tagged with a different rule number and now they have a large number of violations.
Mirek: Well, primarily it is a functional safety standard, but safety and security are related. Both are about creating software that is free from constructs that lead to unpredictable behavior, which means that organizations that follow AUTOSAR C++ or MISRA C++ for functional safety are usually pretty well covered for security. Safety is about eliminating unpredictability from the program, and that of course also promotes security.
But security guidelines like CERT are more thorough and include more guidelines specifically related to security. Currently, what we see in many organizations, especially mature automotive ones, is that they pick their functional safety standard as their primary source and then enhance their ruleset by including additional selected guidelines from a security standard like CERT C++.
Mirek: I personally wouldn’t predict CERT being integrated or merged with MISRA or AUTOSAR anytime soon. Because security is broader in scope and less strict, in terms of language subset, there will always be a need for security-oriented standards, separate from safety standards.
So for example, in MISRA C++ 2008 you have a rule that prevents you from using dynamic memory allocation. You can’t use it if you want to be compliant with MISRA C++ 2008. However, for CERT C++ this is perfectly okay. You can use dynamic memory allocation and there are rules on how to do it in a secure way.
Piotr: Yes, and on the MISRA website, you can find official documents that provide information about the mapping between MISRA C 2012 and CERT C, for example, and these mappings show you clearly the difference of what’s missing. So developers have information about which guidelines to include from CERT C/C++ to include in their selection of rules. And there is a traceability mapping between AUTOSAR C++ and CERT C++, as well. I think around 50% of all CERT C++ guidelines have a similar rule in AUTOSAR C++ itself.
Mirek: Additionally, I think there is a regional aspect to the adoption of these standards. As we saw with adoption of MISRA over time, we are seeing a similar pattern now with CERT C and C++. For example, our customers in Japan are very quick to adopt the latest standards and they seem to be ahead of the rest of the world. Our Japanese customers were the first to request MISRA C 2012 support at least a year ahead of other regions, and right now we see a similar pattern with CERT C and C++, with more requests from the Japanese automotive market that want CERT C/C++ support.
Piotr: It’s important to remember that the AUTOSAR C++ guidelines are part of the AUTOSAR Adaptive Platform, so these two releases per year are the release cycle for the whole platform. If they want to keep the C++ guidelines in sync with the platform, then yes, this does need to be somehow managed long-term. But it’s not necessarily the case that many things will have changed with each release.
Mirek: As we have discussed already, there are issues with changing standards. With frequent changes in the standard you have all the problems that Andrey discussed related to logistics. When a guideline has changed, customers need to update their compliance framework because they will have all issues of re-reported violations that are now suddenly no longer suppressed. This is a significant challenge and costs serious money. If you have 50, 70, or 100 developers and you have a compliance process already introduced in your development process, but you have a business requirement that your product must be compliant with the latest edition of the standard, then you have this challenge.
If the standard is evolving quickly with significant changes in the standard, customers must address this somehow. Often this means extra hours taken from schedule and budget. It is a problem, but as Piotr said, I think that, in the long-term, the standard will stabilize and the changes between each release will not be that significant, as we have seen for example in transition between AUTOSARC++ version 17.32 and 18.10, for example.
Michal: Currently, the plan for the next release of MISRA C++ is to incorporate AUTOSAR C++ 14 and also cover C++ 17, the current version of the language. However, I cannot speak to how fast it will be evolving in the future or how these new versions would be released. Personally, I would expect that a new version of the standard will be created for each new version of the language, the basic idea being to update the standard when it’s mature enough. This should avoid the case we have had with AUTOSAR C++, which is based based on C++ 14, but still changes twice a year.
Michal: It’s hard to say, because in the case of AUTOSAR C++, the standardization started later than the release of C++14. The release of AUTSAR C++ wasn’t related to the release of the language version or when the language appeared.
AUTOSAR C++ was based on C++ 14 from the beginning. When AUTOSAR released the Adaptive Platform, they saw that there were no coding standards that covered C++14, so they decided to base the standard on MISRA C++ 2008 and update with new rules and support for C++14.
Piotr: Yes, I would say so.
Mirek: It’s important to point out that the new merged MISRA C++ standard will be updated beyond AUTOSAR C++. The new integrated standard has been declared to be updated to include all the innovations introduced in new versions of the C++ language, including C++17 and C++20. For many organizations, this was of paramount importance. Modern C++ features are important in systems using AI, for instance, that rely on modern architectures, modern platforms, and a modern library that are frequently developed in the latest editions of C++. So the declaration that the standard will follow the evolution of the language is very important.
“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.
Parasoft’s industry-leading automated software testing tools support the entire software development process, from when the developer writes the first line of code all the way through unit and functional testing, to performance and security testing, leveraging simulated test environments along the way.