Integrated ECUs are the key in rapidly evolving mobility architecture

It’s my understanding that mobility products are equipped with large numbers of computer devices known as electronic control units (ECUs), which control a variety of vehicle functions, including air conditioning and driver assistance features. I’ve also heard that ECU architecture is undergoing some major changes. Could you explain some of those changes?

Arihiro Matsumoto: As an example, let’s look at smartphones. A smartphone uses one or more cameras, a display screen, communication features and other functions, each of which is controlled by its own chip. The central processing unit (CPU) is at the center of all of these, bringing together and providing overall control for disparate functions.

With modern-day mobility products, each vehicle has about 100 ECUs to provide control for individual domains, or independent automobile functions, but there is no central-control ECU to coordinate everything and control it in the same way that a smartphone’s CPU does. That’s why DENSO is developing an integrated ECU, which will provide this overall control function.

Why has it become necessary to develop an integrated ECU?

Matsumoto: Ultimately, we are doing this in order to bolster the value of mobility products. Vehicles are no longer simply a means of getting from point A to point B; rather, they have become important infrastructure elements for society as a whole. Therefore, demand has emerged for more user-oriented services using cloud networking technology, functions that work in collaboration with traffic control systems, and even more sophisticated future technologies such as automated driving. In order to realize these vehicle functions and services, each vehicle must exchange various information with operators and systems outside of the vehicle itself and coordinate the actions of individual ECUs.

For example, imagine you want to open your car’s window via a command issued through a cloud-connected mobility service. It’s not easy to issue intricate, frequent commands to the ECU that controls window movement, but ideally we want to be able to issue that command through the cloud service and then have the vehicle handle the specific response on its own. When giving instructions to a human being, you don’t give highly-detailed instructions such as “contract this specific muscle in your right arm, then extend this specific muscle ....” Rather, you just say, “lift up your right arm,” and the person performs that action in response.

By bringing together individual vehicle functions using an integrated ECU, the vehicle can respond better to incoming commands and so forth from the outside. This will make it feel like we, as the user, are functioning together in unison with the vehicle.

What types of new things will be possible with integrated ECUs?

Matsumoto: One advancement will be more sophisticated app-based services. This will mean safer vehicle control and data usage via apps both inside and outside of the vehicle, including third-party apps.

ECUs traditionally only control one assigned domain each; in the future, it will be possible to develop apps that take advantage of integrated ECUs, which can control multiple domains at once. In addition to enabling new functions via app installation, this will make possible over-the-air (OTA) control of vehicle systems themselves. In other words, we’ll be able to carry out updates wirelessly.

Another important role of integrated ECUs will be ensuring sufficient security to protect personal information and prevent information intercepts and tampering during advanced information processing operations.

I’ve always thought that security is not a major issue in the mobility field.

Matsumoto: In today’s mobility products, programs are rarely updated once the vehicle has been shipped out for sale. With OTA services, however, it will be possible to update the central vehicle system, add third-party apps, and make other changes and improvements. However, this creates a greater risk of malicious programs getting into the vehicle’s system.

What are some of DENSO’s strengths in the area of mobility-field security?

Matsumoto: We have built up a lot of experience and knowledge in the field of mobility. Vehicles generally use many ECUs, and for DENSO-outfitted vehicles we almost exclusively use ECUs we have developed in-house. We make ECUs for almost everything imaginable in the vehicle, from drive-system components such as the engine and brakes, to the air conditioning and even the doors. In addition, we’ve developed and refined a wide range of technologies related to cloud-network connectivity for car navigation systems and other vehicle components.

We always follow our company motto, “ensuring safety at all times,” and we have a lot of experience with active safety technologies as well as connected technologies. By combining and interlinking the electronics-field technologies which we know so well with IT technologies, we can create integrated ECUs that will be crucial for the next generation of mobility products.

Which types of security-related technologies will be used in next-generation mobility products?

Matsumoto: We can identify several types of potential security-risk scenarios in the mobility field. One of these is the risk of personal information leakage when uploading vehicle information to a cloud network. We have addressed this by preparing vehicle data servers that protect personal information through unified management of access permissions, user IDs and the like.

Also, because next-generation vehicles will be more frequently controlled by their users from outside locations, we are developing a management framework that issues control permissions to users who request them based on the user status, vehicle conditions and other such factors.

Because there are so many potential scenarios for network attacks, we are developing security systems that predict and prevent these, detect network infiltrations, and provide follow-up measures in the event of an attack. Furthermore, DENSO is also conducting R&D on blockchain-based technologies which can prevent data tampering.

In the future, will integrated ECUs take over all control functions from the current, individual-domain ECUs?

Matsumoto: Integrated ECUs will be used for some functions, but not all of them. Many standard-type ECUs utilize microcomputer scheduler-based (periodic execution system) software in order to guarantee real-time processing so that tasks are carried out within a certain time span—a preset time of 5 milliseconds, for example. Trying to integrate the functions of all such ECUs into a single integrated ECU is not realistic. In actuality, integrated ECUs will tie individual-ECU functions together using software.

Because the roles of integrated ECUs and standard ECUs differ so greatly, will the ECU development process change in the future?

Takao Mori: Yes, it will. The “waterfall model” has been applied thus far to ECU development, particularly when it comes to safety-related ECUs. This model is a rather rigid development approach focused on quality and safety in which development proceeds sequentially, moving from fixing specifications through to implementation and then to execution of verification and validation tests from the unit level to the system level for quality assurance.

Furthermore, with standard ECUs, it’s common for the original equipment manufacturer (OEM) who makes the completed vehicle to place an order with just a single supplier, who is responsible for creating everything including the hardware, software and applications. In other words, each supplier integrates their hardware, OS, and applications into an ECU through internal, intensive cooperation.

But the waterfall model doesn’t work for integrated ECUs?

Mori: It would be difficult. The big weakness of the waterfall model is its lack of adaptability, meaning that it’s difficult to flexibly adapt to specification changes during software development in response to market-driven demand. Therefore, complete reliance on the waterfall model is not suitable when developing integrated ECUs. That’s because, with integrated ECUs, we use adaptive software that is intended to change and evolve, and use an agile development process.

The intense cooperative approach has many advantages, such as allowing team members to collaborate to solve difficult technical issues. However, there are also some disadvantages, such as the fact that design shortcomings are corrected later in the process. This means that mutual changes that ought to be implemented in advance based on an overall understanding of the design are instead carried out later in the development process.

Moreover, rather than relying completely on the supplier to complete all components of an ECU, as was often done previously, the OEM and its supplier need to collaborate more by dividing up development operations for the hardware, OS and applications. In other words, the overall integrated-ECU architecture design must be completed during upstream development processes; based on this, the hardware, OS and applications will be developed simultaneously; and in the final stage, all of these will be integrated. This is the fundamental approach to integrated-ECU development.

How does DENSO plan to divide up development operations for integrated ECUs?

Matsumoto: For the OS, the OEM typically uses an OS developed by an OS vendor, and then modifies it as necessary. In the auto industry, an organization called AUTOSAR (AUTomotive Open System ARchitecture) has been created with the aim of establishing shared, common vehicle-installed software. In 2017, this group released the AUTOSAR Adaptive Platform, which is an adaptive software development platform, and more and more manufacturers have been using this platform to develop their OSs, hardware and applications.

With integrated ECUs, an AUTOSAR Adaptive Platform-based system-on-a-chip (SoC) OS is used, and various platform services can be called up via apps, including third-party apps. As a result, functions related to power sources, air conditioning and so forth that are traditionally handled by independent ECUs can be controlled instead by integrated-ECU applications.

This framework of using apps to trigger OS functions is similar to how a computer or smartphone works, isn’t it?

Matsumoto: I often liken it to the structure of an apartment building. Each person has an apartment unit of a size suited to their needs, and walls partition off these units. At the same time, facilities such as water and gas piping must be available to all residents for shared use.

Mori: Current software in mobility can be roughly classified into two major categories: software in mature fields and software in evolving fields.

The representative type of software in mature fields is control software related to drivers’ and passengers’ safety or lives, such as engine control. The specifications of safety-related software must be fixed in the early phase of development. In the development period of around two years, we can hardly change the specifications. That’s because there is high demand for reliability and real-time responses with this software type.

In contrast, the specifications of software in evolving fields, such as cloud-network coordination and other connected technologies, may be changed even if the release date is approaching, with just one year or six months left. We need to change the software specifications flexibly to follow market trends and customer demands. In some cases, we need to add new features even if memory and storage have been completely consumed.

In other words, the software “culture” is completely different between these two software types.

Mori: Going back to Mr. Matsumoto’s apartment building metaphor, various types of software are residing in the “building” as “tenants,” so apartment units have to be assigned and arranged accordingly. Some walls are very thick and sturdy, and can’t be altered or taken down easily, whereas other sections of the building are like share houses or dormitories where individual bedrooms are private but the kitchen and other such facilities are shared. The various software “tenants” have different “lifestyle” cultures in this way.

With integrated ECUs, we have to pursue development suited to both software in mature fields and software in evolving fields, as these will both live together within the same system. It is necessary to harmonize the design of integrated ECUs with the architecture of mobility as a whole in order to integrate different ECU functions and enable communication with outside systems. To this end, we must incorporate the software development cultures of both software types.

Ultimately, you will need to achieve agile software development that ensures safety and security, which are absolute requirements in the mobility field, while allocating development operations between the OEM and supplier. Won’t such large-scale, complex development operations require major changes to existing development frameworks?

Matsumoto: That’s right. In the past, DENSO has carried out ECU development on a department-by-department basis, but with integrated ECUs it will no longer be possible to have just one department complete ECU development using established methods. We must bring together various sections of the organization and pool our expertise. That’s why DENSO has already established a cross-departmental integrated-ECU development team, and its members will leverage the Company’s proprietary development tools to show the world what DENSO is capable of.

（Continued in Part 2）