Advanced Driver Assistance Systems (ADAS) are a key area of innovation in automotive electronics, but their potential improvement and positive impact on safety can only be realized with the same level of rigor as other safety-critical software. As we’ve posted before, ISO 26262 defines the guidelines for designing and building safety functions in automobiles, which would include an ADAS system. Static analysis plays an important role in developing software to the standard.
Related:
- The challenges of developing advanced driver assistance systems
- GrammaTech CodeSonar compliance with ISO 26262
- ISO 26262 – A static analysis tools perspective
- MISRA and CodeSonar
In previous posts, we have discussed how static analysis fits well with safety-critical development, helping break through the “affordability wall” and improving risk reduction. This holds true for the relatively new field of ADAS and the emerging development rigor required as the technology plays a more critical role in automobiles. ISO 26262 (Road Vehicles – Functional Safety) defines the functional safety guidelines needed for ADAS (and other safety-critical automotive systems), including using software development automation and static analysis tools.
Certification and Static Analysis Tools
ISO 26262 specifies software unit design, implementation principles, and coding guidelines. Static analysis tools are particularly useful in enforcing coding standards such as MISRA C. Help with coding standards is useful but it’s just a small fraction of the capabilities of a product such as GrammaTech CodeSonar. ADAS devices need robustness, correctness, and consistency, which require design, coding, and testing rigor beyond the coding standards. Static analysis tools can find defects in the source code before and after it becomes part of the project. The tools can also detect bugs that are hard to find in testing and are expensive to debug and fix. In addition, avoiding complexity and increasing maintainability is difficult to manage manually, and tools such as GrammaTech’s CodeSurfer help immensely in management of the structure of the code.
Figure 1: Risk reduction required by a technical solution by ISO26262 versus each Automotive Safety Integrity Level (ASIL). Development automation has significant impact on risk reduction.
Tool Qualification
Software certifications require proof of implementation to the standard, which is often manually generated, but automation reduces the workload. Confidence is required in an automated tools’ results in order for them to be acceptable certification evidence. To address this, tools vendors can seek certifications for the products they sell as well. Recognizing this need, GrammaTech CodeSonar is independently certified for ISO 26262, IEC 61508, and EN 50128. This means that developers can use CodeSonar with confidence that the results produced are acceptable to approval bodies during certification. It’s just too risky to use unqualified tools, which will only result in further testing, documentation, and certification costs.
ADAS Development Acceleration and Risk Reduction
The additional rigor required for ADAS, risk management, and functional safety, defined in ISO 26262, is relatively new to automotive software development teams. Static analysis tools provide tangible productivity improvements to software teams seeking stringent software safety certification. Using a qualified tool as part of the software development process from early stages of development can have significant benefits:
- Enforcing coding standards for safety, security, and style. Automating code analysis during code development ensures quality in the development stream every day.
- Reducing manual effort in proving software robustness and behavior. Static analysis tools augment software testing by providing more assurance of software quality.
- Reducing number of defects throughout development. Code that works the first time is much cheaper to test and integrate than buggy code. Bugs removed from the code before testing (or even source configuration management) reduces costs and risk.
- Finding serious defects that elude testing. Software testing in ADAS is exhaustive and, depending on the level of concern (ASIL), require complete statement and or decision coverage. Despite this testing rigor, static analysis tools have found defects that were missed. These are the most worrisome types of defects – is it really worth the risk of letting these bugs go into a shipping product?
- Analyzing Legacy and Third Party Code. Use of third party code such as commercial off-the-shelf software (COTS) and open-source software is a fact of life in embedded software development. Static analysis tools can analyze third-party source and binaries to discover defects and security vulnerabilities in software that could be impossible to test otherwise (without including it and running it, an expensive option).
- Accelerating certification evidence. Documenting the results of software unit acceptance is critical to proving compliance to certification standards. Static analysis tools have rich reporting features to help support certification requirements.
CONCLUSION:
ADAS is growing in range and scope in automotive systems. The required software development is taking over in terms of costs and risk in these systems, and standards such as ISO 26262 require thorough risk management. ADAS software is complex and expensive to build; however, static analysis tools boost the quality assurance, robustness, and correctness required. Early adoption and use is key to reaping the most rewards.
