How to Build Together a Safe and Efficient AD & ADAS Central Computing Solution

Autonomous and even partially automated driving face much more challenges than what was anticipated at times, this is not breaking news neither new. Today, there are still many obstacles between a fully working prototype and a ready-to-ship solution for the mass market: road infrastructure, reliability, safety, acceptance, human behavior, legislation…

That said, progress is constantly made, sometimes with breakthroughs, while other times with small incremental improvements as attested today with the multitude of fully automated ride sharing fleets and shuttles operating in dozens of cities as well as the increasing number of car models equipped with L2+ and L3 automated driving assistance systems.

How to accelerate that progress? History shows that collaboration and cross-fertilization of ideas fuels inventions, discoveries, and innovation.

Let’s then explore a couple of implementation challenges engineers are facing and how collaborating together would help:

Properly detect and sense the surroundings:

Using multiple sensors helps in mitigating risks like missing to detect or wrongfully identifying an object. Even better: combining sensors with different technologies can also compensate for weaknesses during certain operating conditions: low light, bad weather, obstructed sensor, etc. (for further reading, check: Why Do We Need Radar?).

Image

Such an approach makes sense and more than one ADAS technology pioneer reverted back from dependence on a single sensor technology to today integrating different sensor technologies (i.e. video camera and radar, video camera and LiDAR, etc.). But addressing a challenge creates another: an issue impacting simultaneously two of these sensors is a “common fault”, basically their processing has to be independent and reliably redundant. How to make sure no “common fault” impacts what was supposed to be a redundant + independent sensor?

Correctly process all that data and make the correct decision:

The easiest answer is to simply use different computing systems simultaneously and have enough redundancies. Such an approach works during early development phases with a generous budget, or in specific applications where a fallback is impossible with a relatively low number of produced units like aerospace applications for example. But in a mass-production context, as in automotive, such an approach is obviously counter-productive and even incompatible with the E/E trend of centralized processing:

Image

A similar challenge is faced when different software (SW) processing that are meant to be redundant and complementary interfere with one another resulting in system failure or misbehavior (i.e. one SW task corrupting another’s task data stored in memory, a SW task monopolizing a resource needed by another more critical task, etc.).

To tackle these challenges, as well as any potential common fault, freedom from interference mechanisms are needed. But what should not interfere with what? What should be used with what? To answer such questions, one needs to follow closely the implementation and determine these “rules”.

Ok, but how would it be possible to have a system that safeguards these rules and be already available for developers? We could try to anticipate as much as possible, but logically we achieve better by collaborating closely and making sure these constraints we just called “rules” become a requirement for the system from its specification phase.

With its automotive SoC experience spanning multiple generations, Renesas was able to build on years of collaboration and developed on-chip mechanisms that ensure software tasks with different safety levels to operate in parallel on the SoC without interfering with each other, thereby bolstering functional safety for ASIL D control. First presented at the International Solid-State Circuits Conference 2021, they continue to be upgraded R-Car generation after R-Car generation as today with R-Car gen4 and the recently unveiled R-Car gen5.

Operating efficiency:

Unlike when experimenting on a powerful PC, an automotive central computing solution needs to be efficient and operate in harsh conditions for as long as the vehicle is being used: this means for example that it needs to dissipate generated heat successfully without an overcomplicated colling mechanism (life would be much easier if we can afford a data center’s pinpoint climate control in every car), and this directly depends on consuming power as less as possible.

Renesas has a proven track record in providing the most efficient solutions on the market, whether:

• in processing: 16 TOPS/Watt (that’s tera operation per second) in worst operating conditions
• or in overall chip power consumption: front camera used in achieving 5* NCAP within less than a handful of Watts, also in worst case conditions.

But that’s the easy part! Real efficiency is achieved when the chip design considers the use case and how it would be implemented on the chip. Thanks to our open platform and ecosystem, we at Renesas continuously improve, deepen, and sometimes correct our understanding of how AD and ADAS implementation is done thanks to our constant collaboration with leading OEMs, Tier 1s and Tier 2s. Why is that helpful? Here are a few examples:

• Understanding the use cases allows Renesas to propose the best suited safety mechanisms instead of simply implementing everything redundantly.
• Understanding the different algorithms to be implemented (=used on R-Car) allows us to identify the best suited processing units in terms of implementation, performance, and efficiency and offer them within R-Car
• Further, identifying and distinguishing the commonly used algorithms and functions allows us to develop hard-wired processing units that are uniquely addressed to them, this provides the best performance + efficiency for functions constantly used and frees the general-purpose CPUs for other tasks. Video IPs in R-Car V3H and V4H are an embodiment of that.
• Looking from a different angle, such deep dives allow also to quantify the potential usage, this allows us to estimate the data bandwidth required and properly dimension the communication buses, internal memories, compression mechanisms and external memory interfaces: there are a lot of chips out there which boast good processing power but that are choked with a bottleneck here and there.

Image

Collaboration cannot work in a one-way direction: that’s why the feedback from Renesas on these algorithms could be very useful for R-Car users, here are some examples:

• Understand which processing unit(s) is(are) best suited for a given case.
• Point out where a different approach or change in implementation can be very advantageous and where there could be a potential tradeoff. A recurring example is switching some processing from floating point to integers: in a prototype this might not seem important but optimizing implementation where precision loss is small or manageable could result in a much simpler, smaller, cheaper solution and a handful of Watts saved.
• Introducing new solutions or ideas, like “free” operations that could be made thanks to available functionalities in the system while the data is “available there and now”. This improves unloads data bandwidth because otherwise these operations could require to later go fetch the same data again.

Progress does not only introduce challenges! Our collaboration can today start much earlier thanks to Renesas’ virtual software development environment: R-Car users can now start designing and testing software earlier than before where that could only start once silicon was available. Their feedback and Renesas’ guidance discussed above now start from day 1.

Should we stop here and call it a success? Clearly no! Progress has no limits and by working together we ensure to constantly update our understanding of how autonomous systems of tomorrow would be and anticipate that by providing state-of-the-art processing solutions that would bring them successfully to the mass market.