Ensuring software quality in ADAS

The benefits of ADAS may be undermined by cyber attacks, if the software that they depend on contains weaknesses and errors that can lead to performance issues, malfunctions, or vulnerabilities. The majority of issues that lead to software vulnerabilities occur during development, which is why it is essential to ensure that the creation of software involved in ADAS is as safe, secure and reliable as possible.

Already commonplace in many passenger and commercial vehicles, ADAS provides a human-machine interface for early warning and automated systems, including automatic braking systems (ABS) and adaptive cruise control (ACC). Other ADAS components and features are available as add-ons, including automatic parking, blind-spot monitors and collision avoidance monitors.

To ensure that ADAS can operate safely and reliably, they must be developed in accordance with appropriate functional safety and security standards, which require coding standards to be enforced. Together, these two types of standards give developers essential guidance during the software development process, helping them to ensure compliance and the creation of a high quality product.

The role of coding standards

Achieving compliance with functional safety and security standards can be challenging. ADAS and other automated driving functions are primarily software driven. Therefore, the software compliance requirements of these standards are particularly important.

Most functional and safety standards suggest the use of coding standards to enforce good programming practices. A well-documented and enforceable coding standard is an essential element of coding. Coding standards encourage developers to follow a uniform set of rules determined by the requirements of the project and organisation rather than by their individual preferences.

Coding standards are necessary, as programming languages - such as C and C++ - contain features that can result in critical or unspecified behaviour. This can greatly increase the risk in all systems, but particularly in ADAS where there is a high level of innovation.

In ADAS, it is especially important to consider ‘what might happen’ and therefore defensive implementation techniques should be used. For example, considering the possibility of tainted data.

Most coding standards are based on years of experience and extensive understanding of the language, so that the resulting guidelines will highlight areas of concern and educate developers.

Both security and safety functional standards recommend the use of static analysis tools to enforce coding standards and most coding standards specify that these tools should be used to prove compliance.

Applying coding standards - particularly if it is supported by the use of a static analyser - will enable developers to produce software that is compliant, safe and secure.

Key standards for ADAS development

The automotive industry has always been at the forefront of mandating the use of coding standards. Some of the best known are developed by MISRA, which provides software coding guidelines for the development of safety critical systems written in C and C++. Originally created for the automotive industry, MISRA C and MISRA C++ are now widely used across other safety critical industries. In addition, MISRA C has also been extended for use in the security field.

However, as MISRA C++ has not been updated for several years, AUTOSAR C++14 was introduced to address the requirements of more modern C++ development environments, including ADAS and autonomous vehicles. It encompasses the best guidelines from existing C++ coding standards, which were based on older versions of C++ and provides additional rules for C++14. AUTOSAR C++14 has now been passed over to MISRA and will form the basis of a new MISRA C++ standard for C++17.

It is essential that ADAS development follows the processes required for the functional safety standard, ISO 26262. This applies to electric and electronic systems in vehicles - including ADAS components. The standard covers the lifecycle of automotive equipment and systems, with specific steps for each phase.

Integral to ISO 26262 are Automotive Safety Integrity Levels (ASILs) that measure the level of risk within equipment and components. The more complexity involved, the greater the risk of failure. Therefore, with the volume of ADAS growing, ASILs will play an even more important role in the future of automotive design.

Security, and particularly cyber security, is essential for ADAS. CERT C, C++ and Java are coding standards focused on secure coding. The guidelines that identify software security vulnerabilities are developed on a wiki and coordinated by the CERT division of the Software Institute at Carnegie Mellon University. The standard is less restrictive than those that concentrate more on safety but will still result in secure and robust systems. CERT’s coding standards are being widely adopted in all industry sectors including automotive and, due to the security focus, are particularly relevant for systems like ADAS.

SOTIF (ISO 21448) is a functional security standard that complements ISO 26262 and is important for ADAS development. It covers malfunctions not resulting from system failure and those from technical shortcomings caused by the original design. The standard provides guidance on the design, verification and validation measure to achieve ‘safety of the intended functionality’ (SOTIF).

An example of this may be measuring design requirements for sensor performance, which is highly relevant to ADAS. SOTIF applies where proper situational awareness is critical to safety, particularly emergency intervention systems such as emergency braking. However, SOTIF only covers faults that are not covered by other standards and is not intended for existing functions, such as dynamic stability control (DSC) systems or airbags.

In the future, it is expected that ADAS development will have to comply with ISO/IEC 21434. Currently under development and expected to be published sometime in 2021, ISO/IEC 21434 – ‘Road vehicles - cyber security engineering’ - focuses on cyber security risks of electronic systems within road vehicles. It aims to ensure that cyber security considerations play a central role throughout a vehicle’s lifecycle from design to decommissioning. With a comprehensive approach to implement safeguards across the supply chain, the standard will apply to all electronic systems, components, software and external connectivity.

ISO/IEC SO 21434 is needed because with greater connectivity within vehicles, including many ADAS components and systems, the potential for cyber attacks increases. Current safety critical functional safety standards are not sufficient on their own to cover these risks. When the requirement to comply with ISO/IEC 21434 is introduced, automotive manufacturers and suppliers will need to encourage a cyber security culture with everything designed with security considerations right from the start. They will also need to demonstrate due diligence in the implementation of cyber security engineering, including in their supply chain.

Best practice for ADAS development

While functional safety and security standards as well as coding guidelines provide a framework to produce a safe and secure system, their successful implementation depends on several factors.

There should be a disciplined development process in place. Often both the functional and coding standards will be specified, but - if possible - the teams involved in the development should be involved in the selection process of supporting tools as well. This encourages developers to buy-in to the enforcement of the standards rather than resisting.

In addition, developers should be trained in the programming language(s), the coding guidelines and the tools being used to ensure that they have the necessary understanding to produce high quality, safe and secure code.

The use and implementation of tools should be encouraged over manual processes. For example, a static analysis tool can detect thousands of defects very quickly and accurately, but it cannot determine the intended purpose of the software. Therefore, by first using a static analyser, developers can spend their valuable time reviewing the functionality of the software to determine if it meets the requirements rather than inspecting code for violations of the coding standard or the style guide.

Static code analysis can be performed both on the desktop before the developer ‘commits’ it to the version control system, and as part of Continuous Integration (CI) to where the whole project is reviewed. This means that static code analysers fit well into environments that are led by DevOps, an approach that is increasingly being used in electronics markets.

As the number of ADAS components and lines of code in each component in vehicles continues to increase, the overall complexity keeps escalating. For any organisations involved in the creation of future-facing automotive software, now is a good time to review - and if necessary - update strategies for functionality safety and security.