There’s been amazing growth of software use within automobiles in recent years, with cars quickly becoming super computers on wheels. There are now significantly more lines of code within a premium branded car than on a jet aircraft. The challenges facing engineers developing embedded software for automobiles are great, and cover a wide range of issues. In fact, the white paper Issues Facing Automotive Software Developers goes into this in detail.

One key challenge to look at is the type of automotive software in question. Automotive software is a broad term; there are many different types of software covering a wide range of functions, from Control and Infotainment Software, right through to Autonomous Driving Software. In the UK, fully autonomous driving will be phased in following a general strategy of “Hands Off, Eyes Off, Mind Off.” The result of all this software development is that driver and pedestrian protection has moved from impact survival, to active avoidance. Håkan Samuelsson, President and CEO of Volvo Cars, states that their vision is “that by 2020 no one should be killed or seriously injured in a new Volvo car.”

The greater the control the software has over the vehicle, the more safety critical it becomes; hence Automotive Safety Development Standards must be considered. The first port of call here is ISO 26262 ASIL D, an adaptation of the Functional Safety Standard IEC 61508 for Automotive Electric/ Electronic Systems. An interesting ISO 26262 requirement is the expectation that software runtime verification monitors will be used to detect, indicate and handle systematic faults within software rated ASIL C and D. This means that, despite the fact that all the software has been designed and verified following a robust and rigorous safety critical development life cycle, ISO 26262 still requires self-verification of the software.

On a modern connected car, there can be no safety without security. Car hacking and its associated risks can include remote access using the cars’ cellular network connection, close to the vehicle through the tire-pressure monitoring system, or connected to the vehicle via the on-board diagnostics software. The security threat is constantly evolving, with attacks growing in complexity as hackers learn and develop knowledge on how to exploit the software.

As is apparent, automotive software sits within a highly complex ecosystem. Therefore, to simplify integration standards, OSEK and AUTOSAR have come into play, standardizing software architectures and increasing the use of compatible software components. Now an established part of the automotive landscape, they increase engineering efficiency across the globe.

Andrew Longhurst is a Business Manager at Wittenstein. A skilled project leader with an extensive background in electrical, electronic, and software engineering, Andrew can deliver an in-depth understanding of the challenges facing embedded engineers within the safety critical sector. He holds a BEng in Electrical & Electronic Engineering and an MSc in Robotics & Automation.

eletter-09-14-2017 eletter-09-15-2017