The ever-increasing dependency on software within automotive development, together with the growing complexity of that software, puts more pressure on software development processes than ever before. These days, it takes over 100 million lines of code to build a single passenger car. When we reach Level 5 of the Society of Automotive Engineers’ future vision – the point at which cars will be completely autonomous – the volume and complexity of code will reach even greater heights.
The advent of driverless and other next generation vehicles will increase reliance on software code, but even ‘standard’ vehicles now incorporate a variety of software systems, often connected to the IoT and requiring regular updates.
That is why open architectures have become so important in recent years, helping to standardise and future-proof software elements as much as possible to help manage growing complexity, enable software teams to collaborate better and ensure compliance, all without sacrificing time-to-market.Plus, coding standards and guidelines are needed to ensure that software components are reliable, secure, easy to maintain, and above all, safe.
MISRA and AUTOSAR
C and C++ are the dominant programming languages in the automotive world. MISRA C, MISRA C++ and the AUTOSAR C++ Coding Guidelines are the main coding standards. MISRA is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies. Formed in the late 90s, it promotes best practice in the development of safety-related electronic systems for road vehicles. Its coding standards are also used in other industries where safety, quality and reliability are a priority, including rail, aerospace, telecom, medical devices and defence. Today, MISRA has been accepted worldwide for developing safety-critical software in C and C++.
MISRA may be the longer-established and most widely used of the two, but the increasing use of modern C++ is rapidly increasing adoption of the AUTOSAR guidelines. AUTOSAR is a partnership between over 180 companies involved in the automotive industry, with the aim to standardise open architectures for automotive software and embedded systems development. AUTOSAR is expected by many to be the de facto platform for future automotive design.
AUTOSAR’s adaptive platform addresses the needs of connected vehicles and more autonomous driving. It is designed for technologies such as high-powered 32- and 64-bit microprocessors with external memory, parallel processing and high bandwidth communications. The AUTOSAR C++ Coding Guidelines have been created to support the development of adaptive platform components using modern C++. Such components must comply with the stringent functional safety requirements of ISO 26262.
ISO 26262 is the international standard for the functional safety of automotive electrical and electronic (E/E) systems. The standard covers the entire production lifecycle.
One of its core principles is to analyse risk early in the development process, establish the appropriate safety requirements, and fulfil those requirements during development.
Within the standard, Part 6 specifically addresses software development, placing requirements on the initiation of software development; software architectural design and software unit design and implementation. It specifies the development methods that must be applied in order to achieve compliance for a specific Automotive Safety Integrity Level (ASIL).
Use of an accepted coding standard such as MISRA or AUTOSAR greatly eases the task of ensuring software complies with ISO 26262.
Adhering to coding standards
What both MISRA and AUTOSAR have in common is that they give developers a framework within which they can develop ‘safe’ software. However, they do not do the work for the developer and developing safe, secure systems in C++ is a challenge not to be under-estimated. While it is a programming language that gives developers more scope for innovation, C++’s inherent flexibility means careful decision making (for instance, around how to handle dynamic memory). In other words, C++ simplifies programming of complex systems, but it asks more of developers.
Coding standards help, but it can still be a challenge for even the most experienced developer: dealing with areas of ambiguity or interpretation requires considerable experience and expertise. Selecting the right tools and techniques has an important role to play. Going back to basics and applying good code ‘housekeeping’ is an excellent starting point. Often referred to as ‘clean code’, this is about making sure that code is easily readable by everyone involved, so that it becomes easier to understand, errors easier to identify and decisions over changes easier to make. ‘Clean code’ can be as straightforward as just standardising and simplifying code naming conventions.
Continuous code inspection
Another good practice is to ensure that every line of code is thoroughly inspected throughout the development process, to ensure it is safe, secure and reliable. To avoid this being a manual process, developers increasingly use automated tools, such as static code analysers to verify code. As a result, any issues – such as deviation from a coding standard, excess complexity, or a hard-to-spot dataflow bug – can be detected early in the process. That approach also reduces the subsequent load on the testing processes that would traditionally take place later in the development process. It is representative towards the ‘shift left’ trend, where developers take on some of the work that would previously been carried out by testers or quality assurance engineers. Continuous testing and quality assurance thereby become part of the entire software lifecycle, rather than tasks that happen further down the line.
Establishing a transparent ‘single source of truth’ where every version of every digital asset associated with an automotive design project also supports better adherence to compliance requirements. This provides both a real-time and historic view of who did what, when, where and how. In the automotive world, this can include information relating to both software and hardware, such as documentation, code and other design artefacts, across both in-house and external contributors.
In automotive software development, there are typically many types of tool, file, platform and different teams contributing to a project, so it is essential that the single-source-of-truth supports this disparity. The need to provide an immutable change record, plus the ability to scale to accommodate large repositories.
Many automotive development teams are finding that they need a high-performance version control system that can scale to support the increasing size of their code base while also properly supporting other types of binary assets. They also need their static code analysis tool to integrate with this system so they can manage coding standard violations as their code evolves.
Finally, as the technology, tools and processes that underpin automotive development continue to mature, or new ones are introduced, it is important to keep reviewing the situation and to remain open to fresh ideas. In this fast-paced market, one thing of which we can be sure of is change.
| It takes over a 100 million lines of code to build a single passenger car |
Automotive design continues to be one of the most exciting, fast-paced and evolving markets of all, underpinned by software innovation. Understanding the role of software coding standards such as AUTOSAR and MISRA, then applying the right techniques and tools to ensure that they are adhered to, will help pave the way for a safer, more standardised future for the industry.
Author details Richard Bellairs is a Product Marketing Manager with Perforce |
