Image
Takeshi Fuse
Takeshi Fuse
Head of Function Unit, Business Development, Automotive Solution Business Unit

CASE (Connected, Autonomous, Shared/Service, and Electric) drives market growth of today’s automotive industry and defines the most important segments of automotive technology. In a recent post outlining Renesas' automotive business strategy, it explains that the value of vehicles will shift from hardware- to software-focused and the next generation of vehicles will be defined by software.

Please refer the recent blog which explains Renesas’ automotive business strategy.

Overview of Renesas Automotive Business Strategy | Renesas

The backbone of CASE is an evolution of the automotive E/E architecture, which includes networking changes, unique constellations of ECUs, and changes in the industry’s overall vehicle connectivity strategy. This blog explains Renesas’ view of the evolution of E/E architecture, as well as emerging market requirements, and our approach to managing these changes.

E/E Architecture Evolution and Trends

E/E architectures are broadly classified into “Distributed,” “Domain,” and “Zone” types, and are evolving rapidly in accordance with market innovation and demand. Currently, many automakers are adopting the domain architecture type, which can be individually optimized for each application. In the future, as market needs shift from hardware to a software-based approach, zone architectures will be adopted as a solution to enable information/resource aggregation and vehicle control integration between domains.

Image
E/E architecture evolution trend and challenge

The domain architecture is characterized by optimization through function allocation, whereas the zone architecture is characterized by optimization through physical ECU location. Therefore, automakers who currently adopt the domain architecture must eventually break up the functions and reallocate them to ECUs as part of a transition from domain to a zonal architecture.

It is easy to see that the transition requires significant efforts and resources from OEMs, even if it is on a single vehicle platform. The number of vehicle platforms varies by automakers, and each automaker decides which architecture to adopt based on a balance of development costs, technical challenges, and transition benefits. In most cases, each OEM has a long history of legacy solutions which must be carefully integrated into a new architecture and platform. On the other hand, some automakers, such as emerging EV providers, have few assets and can start their development using a zonal architecture. Therefore, there are many different E/E architectures depending on automakers.

E/E Architecture Innovation Driving Major Changes

Despite the fact that each OEM will take a different path to the E/E architecture evolution based on their capabilities and current architecture selection, there are several changes they all have in common:

1) Separation of hardware and software

First, let’s consider the historical approach to vehicle system development. Conventionally, a vehicle system was developed for an application-specific hardware platform and software (BSP, middleware, and

application software) that is optimized to run on the hardware. This is how most Tier-1s have operated for decades, which requires collaboration, and hardware and software elements have been inseparable. More recently, as safety and comfort functions such as ADAS and Cockpit are being added, they also accelerate the scale and complexity of software development. For these reasons, traditional development was complex and time consuming.

Also, as E/E architectures evolve from domain- to a zonal architecture, automakers are required to reallocate the functions controlled by software, thus portability of software across ECUs becomes important. This in turn requires separation of hardware and software – where hardware may take a long time to develop, produce, and test, and software can be quickly developed. Additionally, scalability must be considered as the high compute ECUs are designed to last the lifetime of the vehicle, and software should also be kept up to date via OTA updates. Moreover, as reallocation and consolidation of functions continue, there is a need to scale performance to compensate for over- or under-performance of devices that have been optimized in the past. All of these requirements further complicate the historical development approach.

2) Shorter vehicle development time

Now we will explain the E/E architecture evolution from a developer's point of view. In conventional automotive development, software development is done using actual hardware (semiconductor development board, “A-sample ECU,” etc.). In fact, this is so important that software development typically cannot start until physical hardware is available, which can delay the development schedule given limited HW resources. Although some development can be with older devices, in many cases, this is limited to development or testing of basic functions. As mentioned above, the scale of software development has increased in size and complexity recently, and there are concerns that this will further stress these development issues. Therefore, there is a need to shorten vehicle development cycles by developing and verifying software in advance, without the actual hardware.

Image
Big change by E/E architecture innovation

Renesas’ Initiatives

In response to the changes in E/E architecture and the overall market needs, Renesas is taking the following initiatives:

1) Scalability

Renesas offers a family of embedded processors covering the entire E/E architecture. This allows customers to select the optimal processor for their specific vehicle grades and applications. In addition, the processors are highly reusable in terms of software and IP, and can be reused across vehicle models, applications, and generations. This enables customers to reduce development cost and time-to-market.

Image
Scalability

2) Shift-left

The term “digital twin” refers to a technology that uses information from the physical world to create a digital version as if it were a “twin.” Using a digital twin, faster, more agile, and innovative development can be done in a virtual space before porting to the physical world. Renesas has applied this same technology to the semiconductor space and created an environment that operates the same way on a computer as on the actual device. This enables customers to start software development before the physical device is available, and to hire more developers regardless of the hardware availability which can be limited by geography or count, thereby contributing to a reduction in vehicle development time.

Renesas Launches Virtual Development Environment for Fast Automotive Application Software Development and Evaluation | Renesas

Image
Shift-left Digital Twin

Furthermore, Renesas offers an integrated development environment including various tools to address the challenges that customers will face in the future, allowing them to concentrate their resources on their focus areas of competition.

Image
Shift-left Integrated S/W development environment

In this way, Renesas supports next-generation technologies by providing digital solutions that meet the various needs and helping customers realize a safer, greener, and more convenient mobility society.

Share this news on

Log in or register to post comments

Share this news on