RAJ REDDY. PRINCIPAL PRODUCT MANAGER, ECARX

Software is responsible for many delayed product launches, costing vehicle manufacturers dearly in time, money and customer confidence. Getting it right first time requires faster, more robust development and testing processes.

When Benjamin Franklin proclaimed in 1736 that ‘an ounce of prevention is worth a pound of cure’, he was talking about the risk posed to a city by fire. Were he still alive today, he’d probably see his warning just as apt to the risk posed to vehicle programme timing by software development – especially within ever-more sophisticated digital cockpits which offer increased amounts of functionality developed under tighter timescales than before.

Perhaps, he would add, that faster, more robust development and testing processes, and more – and earlier – user testing would help to prevent the type of firefighting that OEMs and their suppliers have to do if the problems they discover present a risk of a costly delay in product launch, or customer dissatisfaction once the vehicle is on sale.

Infotainment screens blacking out is a common occurrence with early development mules but when it happens to customer cars the result can be more than just inconvenience: this one issue alone has resulted in multi-million-dollar class-action lawsuits. As well as undermining consumer confidence before the vehicle even reaches the showroom, delaying a product launch can cost orders of magnitude more, and software problems have been cited as the reason for several high-profile launch delays in the past few years.

Of course, the development challenges are massive. Digital cockpits have to offer the new features and functions that consumers want but must also keep them simple and intuitive and offer a great user experience – while also minimising driver distraction, meeting stringent ISO26262 functional safety requirements, increasingly demanding data security and cybersecurity regulations worldwide, and achieving certification for third-party operating systems such as Android. And as more features are added, computing power goes up, and so hardware complexity is also increasing – and all within more compressed timescales.

Because of the growing time-to-market pressures, we’ve adapted our development strategies and engineering methodologies. We’ve always used Agile development for software, but we now have modular architectures for both hardware and software components which also saves time and is a big value-add because we can use re-use and adapt certain elements from previous programmes: this plays a big role. In the past, we did a lot of manual testing but now this is quickly being replaced by automated testing, and this is really improving the whole process.

Continuous integration & continuous development, or CICD, is another process that’s also been put in place: if we’re developing a new feature today, there will be nightly builds and we integrate these immediately, so the testers can test the following day – it’s a truly iterative process. We can also leverage our global R&D network to make it even more effective: the next nightly build that we will do in the UK or Sweden is immediately tested by our colleagues in China, so we have faster feedback that way.

While CICD is not new in itself, we’re using it in a way that’s user-friendly to both the development engineers and the test engineers – we’ve streamlined the process to ensure that it runs more efficiently and effectively. And we’ve customised the tools extensively so that they’re optimised for our processes, which saves us quite a lot of time as four hours a day on the nightly builds, as just one example. And because we use Agile throughout the entire company, the whole team as well as the Product Owners know when the next planned updates to features are coming.

The supply chain

Even ECARX is asked to develop the full digital cockpit system itself, which we have the full capability to do, we still work with a large number of different suppliers, whether it’s those with our own supply chain, or the suppliers working in other vehicle domains, such as chassis or ADAS, that we work with.The interoperability between all the features has to be perfect, and the testing and validation work to ensure that is achieved takes time.

Of course, every supplier will say ‘yes, we’re done and we’re happy’ but in the end, when we’re integrating everything within the digital cockpit, we may still find issues. And then there are changes to requirements – which is common – where the OEM says ‘Now we want the feature to work like this, even though the software might already be 90 per cent complete, which eats into the timing and places extra pressure on the testing. And OEMs always want everything as soon as possible, and it’s them driving the Tier Ones to be faster.

Usually, we start developing three years before start-of-production, so we have plenty of time to address any issues. But it’s a challenge to add new ADAS systems, for instance, halfway through development because it impacts the whole supply chain. OEMs try to avoid big changes like these but there are cases where this happens, usually because one of their competitors has just launched a similar feature already.

When problems occur, another advantage we have is product ownership which is end-to-end: having a vertical responsibility really helps because it means that you can’t just ignore the problems which may be happening elsewhere in the stack. Audio functions for example: if you press the volume button but it doesn’t work or is slow to respond, it’s easy to blame the HMI because it’s the first layer you see, but the problem may be found deeper within the system, and our cross-functional teams will quickly work on finding the root cause, not by passing the problem along for someone else to resolve.

The road to software-defined vehicles

As the industry moves towards the era of the software-defined vehicle, many OEMs are building up a lot of in-house software capability to help them manage the increasing complexity, and to give them a lot more control over the development process in general. Because we’re a relatively young company and a relatively small global team, we think we have an advantage over some of our competitors because we can adapt to these changes more quickly, and we also have a very customer-centric approach to understanding the OEMs’ requirements, and tailor our products and services accordingly. And we have a lot of expertise with Google Automotive Services, which helps us to innovate even faster, aided by the know-how and resources of the entire Geely Group.

Our insight into the China market is also invaluable in understanding what the digital cockpit of the software-defined vehicle will look like: we know, for example, that in China, many passengers start gaming as soon as they get in the car. In other markets – Europe for instance – we don’t see that as much. So, China opens up new opportunities for providing understanding of what an immersive user experience will need to provide. The Unreal gaming engine in our ECARX Makalu digital cockpit computing platform is the first step towards that.

Software-defined vehicles will also rely on central computing to cope with the complexity and sheer amount of data they’ll need to store, process, and transmit. Over-the-air updates will be much larger than today as well, and maintenance of this software is something that we must be very mindful of. It also remains to be seen if those computing platforms will have to serve all the different operating systems that are in use currently, and how the processing power will be allocated among the many different domains, while meeting the performance requirements of each and doing so robustly, and in an energy efficient manner.

It’s a steep learning curve, and one that the whole industry is on. Nobody can underestimate the technical challenges this will present, but there are some simple measures that we could all work on now, learning from past mistakes, that will really help to make a difference. It all boils down to stronger collaboration between the different teams in every company in the supply chain, and between all the different suppliers, and between suppliers and OEMs. Because today, all too often, people are working in their own bubble, and only get to the integration phases much later on, and that’s when you discover the real problems.

As suppliers, we can do testing at module level and system level but most of the vehicle level testing is done by the OEM – if there was a way for all the suppliers to be involved in this, we’d all understand the problems much sooner and could address them much sooner. But we don’t yet have a system where all the suppliers are in one room, and this remains one of the challenges.

And most of the time, customer trials don’t happen until very late in the programme, when prototypes are more readily available. But when this happens only a few months prior to launch – or the intended launch – it doesn’t give us much time to implement the user feedback and adapt features. Which means a lot of firefighting. Hopefully, by working more closely together, we can prevent a lot of those late changes from happening in the future.