Tooling in support of cross-departmental integrated-ECU development

DENSO carries out integrated-ECU development using a cross-departmental team spanning various DENSO departments as well as personnel from other companies. However, it seems that the type of specifications design used for integrated ECUs depends on which types of mobility products are going to be made. Is that correct?

Takao Mori: That’s right. Unless we have a goal in mind—creating a feature that enables external control of the vehicle, for example—it’s not possible to plan and develop an integrated ECU. This is one of the big challenges of integrated-ECU development.

In other words, integrated-ECU development is linked with mobility-product planning and development process as a whole?

Mori: With integrated ECUs, it’s very important to determine from the initial development stages which domains will be brought together and handled by the ECU, and to define interfaces between these domains accurately. At DENSO, we work in close coordination with our original equipment manufacturer (OEM partner; in this case, the manufacturer of the completed vehicle) who is also our customer, proposing specifications as we proceed with development.

I imagine it takes many personnel to develop integrated ECUs. How do you achieve agile development with so many people involved?

Arihiro Matsumoto: In agile development, it’s standard to use teams of 10 people or less, with the product owner setting requirements and a scrum master managing overall progress. The development cycle entails a loop in which coding is carried out for two to three weeks, and then specifications are redefined based on feedback.

With our current integrated-ECU project, however, a lot of project members are involved, including personnel at the OEM. Therefore, we are using a type of framework called “SAFe” (Scaled Agile Framework) to enable agile development on a larger scale. With SAFe, each team works to deliver results in short periods, and once every three months all team members come together and collaborate for two straight days on development operations. This collaboration includes not only engineering team members, but also management and other associates from throughout the Company. The whole organization comes together within this agile development framework, which not only promotes efficient development workflows but also cements an agile development mindset among everyone.

Are engineers from standard-type ECU development operations involved in the development of integrated ECUs as well? And if so, is this an entirely new type of development approach for them?

Matsumoto: Regarding mobility-system architecture, existing architecture is never replaced or altered radically all at once. Therefore, we have the same departments involved in past ECU development continue to serve in their existing capacities. This means standard-ECU engineers continue to create and adjust software, then pass it along to the department in charge of integrated ECUs.

Based on this type of approach, we utilize software as another means of overcoming challenges encountered in large-scale agile development involving multiple departments and companies. The cross-departmental development team uses “Next Design,” which is software created by DENSO CREATE to make development more efficient.

What kind of tool is Next Design?

Mori: It is a type of software design management tool. One of the purposes of introducing Next Design is to manage interfaces between software elements, which change frequently, and to inform engineers when any change occurs.

During integrated-ECU development, software interface specifications are determined in the early phase by the various departments and organizations involved, and then multiple elements will be developed in parallel. As long as each organization adheres to the same interface specifications, things work smoothly when all software elements are brought together for integration.

However, there are times when interface specifications must be altered and added to quickly react to the changing trends and needs of the market. Even the OS service interface specifications must be able to evolve and change rather than staying rigidly set. There are thousands of service interfaces to be accounted for, and as new additions and changes are made to these, applications may no longer function if they use interfaces according to old specifications. That’s why it’s important for developers in charge of the OS, apps and so forth to stay in sync with one another as they make changes.

In other words, Next Design is a utility used for regularly synchronizing and keeping interface specifications up to date?

Mori: Yes, and it can be used for various other things, too. Next Design was originally created as a modeling tool. Modeling is used to visualize concepts and their relationships.

A lot of people associate the idea of modeling with languages like Unified Modeling Language (UML) and Systems Modeling Language (SysML); however, Next Design is a meta-modeling tool that allows the user to choose their own concept structure and notation. For example, the user could choose shapes such as square boxes and arrows freely to visualize an organizational structure. By adopting this approach, it’s possible to carry out modeling in more flexible ways for integrated-ECU development. No other tool makes this easier than Next Design.

Furthermore, Next Design is unique in that it can be used like a database, which enables effective sharing of specifications among multiple departments and organizations having complex relationships such as the one I’ve been discussing.

That seems much more efficient than just writing out specifications in Word and sharing them.

Mori: Exactly. And another way to boost efficiency is Next Design extensions. Next Design extensions let users build their own automation features. C#-coded plugins can be integrated right into Next Design, and by using extensions for interface management it’s possible to automate adjustments and verification in response to interface changes that occur during integrated-ECU development.

Based on what you’ve both told me, this approach is very different from standard embedded-software development in the mobility field.

Matsumoto: Vehicle-use integrated ECUs are ECUs just like any other, and require the same embedded-software development technologies and know-how, which is an area in which DENSO excels.

But our OEM customer requires more than just products. We always think about what types of value our products are creating as well as which development tools we will use. We must also take into consideration the development process itself. There are always things which the standard-type process assignment approach cannot fully address. In order to respond flexibly to the changing demands of customers and the market, we will need to utilize cross-organizational structures on an even wider scale in the future.

Will the demands placed on engineers change as well?

Matsumoto: With the development process, it’s common to separately assign the processes of design, implementation and evaluation in order to boost efficiency. With advanced development for integrated ECUs, however, we have to prioritize not only efficiency, but the cultivation of human resources as well.

By assigning work to each associate in a way that involves them in the entire process, from design through to implementation and evaluation, we can cultivate human resources capable of being leaders in all areas and contributing to product development. This HR-focused approach is important in other advanced development operations as well.

With products like integrated ECUs in particular, people who are capable of understanding the architecture as a whole and making adjustments in each domain will be highly valuable.

It seems that integrated-ECU development is becoming like smartphone and computer development.

Matsumoto: In terms of hardware, integrated ECUs use ARM multi-core CPUs, NAND flash memory, Ethernet ports and so forth, making them more hardware-rich than standard ECUs.

On the software side, integrated ECUs use an OS, a file system and cloud connectivity, and feature expandability through the addition and deletion of apps. These aspects make them similar to a smartphone or other such device, just without the display screen.

Integrated ECU development differs, however. In the mobility field, safety margins, costs and other factors are considered very differently than in the standard IT field. With IT products, it is common to pack in as much CPU power and memory as possible, but with mobility products, safety and security are our top priorities. This means high-performance CPUs cannot be used in integrated ECUs due to noise and heat generation, power consumption levels, and cost restrictions. We must pursue development with limited resources.

Regarding the technology, which aspects of integrated-ECU development do you find to be the most interesting?

Matsumoto: For automobiles, top priority is put on safety and security, so you run into major limitations in regard to usage methods, information utilization and so forth. This is likely to remain a characteristic of the field in the future as well. At the same time, the meaning of “vehicle” is currently being redefined based on the wider concept of “mobility,” so many new technologies will be incorporated in future.

These products transport people through real-life and physical spaces, and so their scale of usage is far wider than those of smartphones, cloud computing and the like. This makes it a really interesting field to work in.

What types of human resources are needed in the integrated-ECU development field?

Matsumoto: In a broad sense, engineers who have deep knowledge and experience with software. They will be required to have a wide range of knowledge, and this won’t be limited to embedded-software development alone as was the case with development in the past.

We are looking for engineers experienced in everything from networking, cloud computing and security to OSs and middleware. Moreover, we’re working to set up operating environments that will facilitate effective development by engineers experienced in app development.

Mori: We need engineers who have experience with developing tools like Next Design, and with planning and setting up software development kits (SDKs) and development environments. In the software development world, people often use the phrase “dev[elopment] environments as code,” which refers to the modern trend of accelerating the growth of the software development environment by using software. Here at DENSO, we hope to work with people who can help us create and bring in new technologies and approaches in the development field.