Static Analysis & Coding Standards Compliance for Autonomous Driving Software

Writing code for complex functionality like autonomous driving requires large teams of talented individuals, who very often have their own views about how to ensure high quality code. But it isn’t so easy to build an efficient software development process that includes quality initiatives such as static analysis and coding standards compliance, that will enable the successful certification of the autonomous car.

Autonomous driving is a very competitive space, and developer velocity is a mantra. Whoever can first bring a certified product to market will have a significant advantage over the competition, and so it’s easy for developers to view static analysis and other quality initiatives as an obstacle. Especially because the field of autonomous driving is hungry for talent, organizations are hiring smart developers, even if they don’t have any background in safety. But developers that come from a background without a functional-safety culture are not aware of all of the quality processes that are required for safety-critical software development. This can make cultural buy-in a challenge.

Getting Internal Buy-In

Sometimes it feels like building internal consensus for quality-oriented practices requires a masters degree in Psychology, or the skills of a trained negotiator… In past projects, I’ve been responsible for introducing static analysis and AUTOSAR C++ 14 coding standards compliance as a sustainable process. Autonomous driving software is very innovative, and software components that are used for it are developed using modern C++. With that in mind, the AUTOSAR C++ 14 coding standard is the most appropriate standard for autonomous driving software because it supports modern C++ and was created for safety-oriented development.

To convince the unconvinced, I’ve given multiple presentations discussing multiple different aspects. But still, even with all these discussions and agreements, some developers resist analyzing all the code they create. Here are some of the main points I focus on to get the right processes in place:

• Certification – Autonomous car software must be approved and certified before going into mass production. This process looks different in different regions of the world, but all automotive organizations recognize ISO 26262 as the main functional-safety standard that simplifies approval and certification. Static analysis and coding standards compliance are required by ISO 26262, and lack of coding standards compliance for the source code will be a huge obstacle in the approval process. No serious business organization will allow for that risk.
• Better quality at a low cost – When you build high quality, compliant code from the beginning, testing as early as possible, it’s easier (i.e. faster) to fix issues, and you’ll avoid common pitfalls because developers will start adopting best practices from the beginning. The developers (even those who are new to the safety-critical culture) will learn and there will be fewer static analysis violations. It’s essential to test while code is being written, to create complex software at a rapid pace. Static analysis is one of the methods that fits very well into this picture, establishing an essential foundation for safety and security by eliminating classes of problems that may lead to unpredictable behavior. Giving developers a tool that will produce the results in a short feedback loop, with a low amount of false positives, increases the acceptance of this testing technology. And with time, developers do start to see it as a safety net, i.e. something that helps them to create reliable code. Not to mention that this is critical for Agile/DevOps because if you wait to do scanning just before release, you’ll be spending months fixing the code.
• Legal issues – Coding standards compliance is a shield for potential legal issues. With millions of cars on the roads, accidents are going to happen. Some of them will be traced to software errors, which are inevitable. Organizations have to be able to present that they have done everything that is practically possible to prevent safety hazards. Not having a documented coding standards compliance process will certainly be a problem in case of a software defect that contributed to a tragedy. So when discussing this aspect with developers, to strengthen the effect I like to include some real accidents that were caused by software defects, such as the infamous Toyota unintended acceleration.

Convincing the most resistant developers…

Autonomous driving technology is at a very early stage. A lot of the source code created is just a prototype to test new ideas. Some developers don’t want to “waste” time making it coding standard compliant — they just want to write something quickly and test it. A typical story I’ve heard is, “I just want to test this new algorithm, if it works I’ll rewrite the code to make it clean.” This sounds innocent enough, but the reality is that it’s just growing technical debt.

When we move from prototype to prototype, we usually take a lot of code with us, statistically it can be up to 80% of the code. So we can’t afford to prototype something with bad code and then fix it later, because from the very beginning, we’ve known that we won’t have time for that. So even if something is a prototype, the code must be compliant because the final product is going to contain a significant amount of code that was initially created as a prototype.

If instead of focusing on doing it now instead of doing it later, you can focus on doing it now to avoid spending an unknown amount of time at the end, developers start to see it as enhancing the process instead of introducing a slowdown. If you can efficiently fit the process into the developer’s workflow without slowing velocity or creativity, it becomes much easier to work with. It’s much easier to keep something tidy and clean as you go, than it is to clean up a huge mess, at the end. Building consistent, maintainable practices for writing compliant code will help you find less of a mess later.

That darn legacy code…

But even if you are able to successfully introduce a coding standard compliance process early on, there will inevitably already be some (significant) amount of code that was already created by the team, and some that was inherited. And while you are selecting the static analysis tool (Parasoft C/C++test) and picking the standard (AUTOSAR), in the meantime the team is creating a lot of code without any compliance policies! So it’s important to also create a policy for legacy code. Two great policies are:

• “Zero new violations” – in which you can’t finish creating new code until it is compliant
• “Clean as you go” – in which, if you touch the file, you have to clean it up

With these strategies, you can address legacy code, introduce new code, and continue to keep the place tidy.

Summary

To be successful in adopting static analysis and coding standards compliance processes across the development organization, you will benefit from doing the following:

1. Make sure everyone understands why you are doing it (without spending time on it, you cannot be certified and will not be able to succeed in the automotive market)
2. Address the cost of delayed releases if you don’t address quality as an ongoing effort, and show the team what happens when you leave it to the end
3. Make adoption as relevant and frictionless as possible. Be intentional as you implement your static analysis tool, making sure to select the right rules and checkers and have a workflow that integrates into the developers’ existing workflow.