In automotive systems, software and hardware developed in closer collaboration can help OEMs and Tier-1s achieve safer and more efficient end user experiences.

Automotive systems have become progressively more advanced. Cars have more sensors, detailed maps, cloud connectivity, over-the-air updates, and media streaming (including video and dashcam recording). This has all led to increased data handling and storage. On top of that, more end-user features like advanced IVIs have made their way into the connected vehicle. Taken together, these factors have made modern automotive systems extremely complex, while also putting increased pressure on several hardware components – like the flash memory of the vehicle.

As automotive systems continue to develop in complexity and sophistication, what does this mean for their development trends over the next 2-5 years? How is software and hardware compatibility going to be shaping up? Will current processes and hardware-to-software communication chains be able to keep up?

There are a lot of questions to consider when looking at the near future of the automotive systems landscape. While many trends are worth talking about, three in particular have caught our eye:

1 – Original equipment manufacturers (OEMs) are seeking more ownership in developing software for the systems and user interface

2 – The flash memory demands of the connected car require a deep understanding

3 – Strong communication between hardware & software teams is increasingly important

Let’s look at each of those trends in more detail, and what they might mean for the future of the connected vehicle.

1)    OEMs are seeking more ownership in developing software for the systems and user interface

ECU consolidation in automotive systems has been occurring at an increasing rate. Here, more and more functionality is going onto high performance computing platforms. This involves various advanced operating systems, but also hypervisors with multiple virtual machines running on them. These changes further add to the growing complexity of software in the vehicle.

But now we are also seeing a trend of some OEMs directly taking more ownership in creating the car software themselves. Though that software is occasionally referred to as an “operating system,” it is not an operating system in the typical sense – it is not replacing something like Linux in the vehicle. Rather, what is being developed is the user interface of the car (and the associated infrastructure). This includes the car system’s look and feel from the end user’s perspective – often referred to as the user experience (UX). At their core, these user interfaces are still powered by traditional operating systems like Linux or Android. But it’s the user interface, the infotainment features, and all the added services, that are being tweaked and customized by OEMs.

That is what some OEMs would like to have more control over: the car interface and infotainment features. And it is a desire that makes sense: with OEMs taking more software development ownership, their vision is to more significantly separate the software development from that of the hardware. This approach takes a page from current Android and iOS smart phone development, and it means that ideally the software of the vehicle can be developed completely independently from the underlying hardware. This would also allow the hardware of the system to be switched around without having to touch a single line of code.

This trend of increased ownership has promise for more efficiency and new innovations in processes and value chains within the industry, due to common interfaces potentially allowing a given application to be ported from generation-to-generation of devices.

2)    The flash memory demands of the connected car require a deep understanding

Connected vehicles of today have unique, intensive flash memory needs. As demands for sophisticated features and safety in the vehicle increase, more pressure is put on the lifetime and performance of the flash memory. This leads to increasingly complex embedded systems – as well as a growing importance in having a detailed understanding of the flash memory needs of the vehicle.

In a car, reliability and lifetime are critical requirements. And they are impacted by the vehicle’s hardware. While, for example, a typical smartphone may have an expected lifetime of 3-5 years (within a comparatively relaxed consumer environment), an automotive system’s expected lifetime of 10-15 years can be significantly impacted by the chosen hardware.

Flash memory is one example of that kind of hardware. For a safe car ride and the best system performance, we have increasingly seen that flash memory characteristics have to be considered with the needs of the system. It simply may not be enough to design the interfaces and software features based only on the needs of the software. The memory of the vehicle and the associated requirements must also be evaluated in detail. Those include the flash memory specifications, the different types needed, and their limitations – it’s a huge list. If these requirements are not understood, unfortunate flash memory problems (as seen in even well-known OEMs within recent years) could be on the horizon.

Understanding how to closely integrate the flash memory and software of the vehicle is therefore important if the goal is maximum system performance, memory lifetime, and reliability.

HANDPICKED RELATED CONTENT

Want to know more about how flash memory issues can affect an automotive system, and how to mitigate those issues? Download our whitepaper, Challenges of tomorrow’s data storage integrity in automotive and IOT projects.

3)    Strong communication between hardware & software teams is increasingly important

Another noteworthy trend is the growing need for close cooperation and communication between hardware and software teams during automotive systems development.

While flash memory is just one aspect of automotive systems performance and reliability, it is an important one. To ensure that an automotive system’s flash memory requirements are understood and taken into full consideration on the software side, effective communication channels on the development level should be in place for each OEM. That means having an established communication system, team, or committee that oversees the software architecture development, with an eye towards pointing out risks to the hardware specialists. This approach would significantly help to reduce the likelihood of a software and hardware mismatch – and that translates to savings in cost and development time.

A wise choice may be to avoid any situations where a software application is developed without a clear understanding of the specific characteristics of the vehicle hardware. Such as, for example, simply dropping an application into a pre-installed operating system with no other real communication occurring between development teams. A lack of strong communication, guidelines, and perhaps governance can easily result in mistakes which rapidly wear out the flash memory. It will also affect performance and the user experience, as large amounts of data logging traffic (from many sensors, DVR recording etc.) may cause insufficient bandwidth over time for ensuring optimal system performance.

However, building – let alone enforcing – the right communications channels and guidelines is no easy task. It takes time, resources, and coordination.

One of the first steps in tackling that challenge is ensuring awareness of this communication need across development teams. Organizations should therefore consider a commitment to outlining, building, and maintaining clear communication channels between stakeholders and development teams. That can be done by educating stakeholders on the importance of close cooperation between software and hardware teams, as well as identifying actionable ways to improve communication workflows. Doing so can help reduce the risk of software and hardware mismatches in the vehicle, leading to a better end user driving experience.

Solving automotive flash memory challenges with the right tools and guidance

While the trends mentioned in the sections above hold opportunities for automotive OEMS, they also open the door to potential challenges in flash memory needs and cross-functional communication. Identifying and solving those kinds of challenges is not easy, and it’s why Tuxera offers automotive storage software expertise specifically to help in these areas.

Tuxera embedded flash storage testing provides OEMs with a comprehensive understanding of their automotive flash memory situation and needs. Our experts have decades of know-how in field testing the flash in the vehicle, helping OEMs build a more detailed picture of the characteristics and limits of their unique automotive storage stack. With the help of our consultation, stakeholders in automotive projects can learn about the appropriate strategies for mitigating flash memory risks, saving time, reducing costs, as well as optimizing and improving system performance.

Quality-assured embedded file systems can also be a great help. Tuxera Reliance™ Velocity and Tuxera Reliance Edge™ are optimized for improving performance and extending flash memory lifetime in the vehicle. These file systems help preserve critical data on the automotive system, while reducing flash memory wear by up to 63% and increase flash memory lifetime by up to 3.2 times.

Ultimately, an ideal solution is a mix of strong communication between hardware and software development units, supported by the best file systems and flash storage testing, with consulting and support throughout.

Final thoughts

As automotive systems become more advanced, several interesting trends are emerging.

One of those trends includes greater ownership in software features and interface development from OEMs. At the same time, the growing need for a detailed understanding of the flash memory means that creating software features for the vehicle is no simple task. In fact, it can lead to issues in automotive system lifetime and performance if not tackled correctly.

Navigating those two trends leads us to a third trend – namely, that well-planned communication guidelines and channels should be in place to ensure that software and hardware stacks are developed optimally and in close cooperation with stakeholders. As those guidelines and channels are developed, Android and iOS mobile phones are increasingly acting as blueprints for separating the hardware and software. It is, however, wise to remember that even within mobile phone communities, operating system updates can often lead to problematic consequences: broken functions that worked in the past, reduced battery lifetime, and so on. This demonstrates how strong collaboration during the development process is still necessary, despite hardware and software separation.

Why are these trends that we’ve looked at important? Failing to consider the challenges and opportunities within the trends discussed could lead to mismatches between the software and hardware, hurting the flash memory lifetime of the vehicle. In the worst case, that can mean disastrous reliability, lifetime, and performance issues. Let’s avoid that by setting our sights on creating effective communication processes – as well as the right file systems, flash memory solutions, and storage support.