Skip to main content


Corporate InformationResearch & Development

Product variations are expanding as user needs increasingly diversify and markets further globalize, and the development front of embedded software is required to rapidly address this expansion. In this regard, the "software product lines" is drawing attention as a method of enhancing the development efficiency of embedded software. At Hitachi, expanded application of software product lines practices is promoted through coordinated efforts of researchers on the development front and corporate-wide activities by willing employees.

(Publication: January 26, 2016)

Responding to increasingly diversified user needs

When did research of the software product lines start?

SHIMABUKUROThe research started in the early 2000's, when car navigation systems and digital home electronic products became increasingly popular. What had previously been mere machines began to incorporate software for smarter operation. This raised the major issue of how to achieve development efficiency and reliability in the embedded software.
In particular, there have been larger variations of these products offered in recent years due to increasingly diversified needs. But you can never develop software for each product one by one from scratch.

The main theme in developing embedded software is how skillfully we can reuse necessary software assets. If you work on software that has large portions common to existing software and you only have to develop the portions that are specific to the product model, you can efficiently create a highly reliable new product. The software product lines (SPL) is a method to achieve this scheme.
At that time, research of the software product lines had already been under way in Europe and America. At Hitachi, we also started research for applying the method to product development in order to solve the issue of development efficiency and reliability of embedded software.

Now, Hitachi has practically applied SPL to a variety of business areas including engine control units for automobiles and clinical analyzes.

Is it true that in some cases the SPL method has achieved a significant reduction in software development costs?

KATOThat's right. It was performed for the network switches developed by Hitachi Metals, Ltd. They had a project to develop 6 different switches simultaneously in a year, and were pressed to reduce the development costs. In the conventional development method, you copy the source code of the base product and modify only the different portions. However, administration of development under this method is complicated because the different products have the same source code. This was a point that could be improved by applying the software product lines method. In doing so, I was in charge of technical support with regard to the software product lines practices.

By applying the software product lines method, they were able to reuse 90% of the software assets for the development of the minor versions of the products and 56% for the development of the major versions. This has led to a significant reduction in development costs.

Figure 1: An example of software asset reuse

The key to success is the cycle from planning to reflection

What type of method is the software product lines?

SHIMABUKUROIn a word, it is a method to systematically reuse necessary assets needed for developing software. The method defines the common portions that can be reused as "core assets," and comprises three activities centering on the core assets.
The first activity is called "domain engineering," in which core assets are developed. The second is "application engineering," in which individual products are developed utilizing the core assets. The third is "management" to administer the domain engineering and application engineering processes.
The core assets include development support tools, development processes, human resources, etc. as well as software components and frameworks.

KATOThe major feature of the method is reusing assets in a "planned" manner. When reusing assets without planning, which means simply copying the source code of the base product, attention is often paid only to the portions that differ from the original copied at the time. However, there tends to arise the problem that the software ends up being dislocated as a whole through repeated implementation of local modifications.

Under the software product lines method, the scopes of such factors as target periods and product lineups are first determined. Then the core assets needed for the development within the determined scopes are prepared, and the methods to reuse them are planned in advance. For developing individual products, as a rule, the core assets are left untouched and only the portions specific to the products are developed. In this manner, we can secure product reliability in an efficient manner by developing them in accordance with the plans.

Figure 2: Overview of the software product lines scheme

Do you sometimes find that things don't go as planned?

KATOIndeed we do. Of course, we prepare for that by analyzing problems that may occur given the present conditions and considering responses for portions that pose a higher risk of having to change the plans. Even so, as we proceed with development, we may be too busy to properly manage the core assets, which may result in a loss of product quality and thus form a vicious circle. For example, when developing multiple products in parallel, the source code of the core assets and that of the specific assets may be inaccurately distinguished or even confused.

If that happens, we look back when the development is over. We reflect on which assets were in fact highly reusable for all products, and provide feedback to the developers, encouraging them to properly manage the assets for common use.

You look back the source code? That is indeed thorough.

KATOYes, it is. We believe that part of managing is deliberately going through the cycle of planning and reflecting.

SHIMABUKUROOn the other hand, the cycle will not go smoothly if we only look at the implementation aspects of software such as source codes and architecture. To implement software, you must also consider the business strategy, operation processes and organizations as a package.

The core assets are to be reused for software that will be developed in the future. Thus, it is necessary to even investigate the company's business strategy itself, such as which business and which products the company will choose to survive in the future. In terms of software management, for example, you must consider establishing organizations to manage it and incorporating software management into the development process.

A "task force" enhances Hitachi's technological capabilities

Meaning that thinking and making proposals from a different viewpoint from engineers is important?

KATOExactly. However, the method will not be used unless it is accepted by engineers. So it is difficult to determine the degree of difference.
By the book, software product lines is a large-scale, well-planned method. Our job is to adjust it to the reality of the development front and propose customized plans for respective cases. In doing so, we make suggestions that a certain process could be improved or that the organization should be improved by changing this or that.

SHIMABUKUROIn order to successfully apply the software product lines practices on a practical level, there are some patterns for proceeding with the processes and certain know-how that is common to different cases. Such patterns and know-how should be collected and organized so that they can be used for subsequent cases. This leads to an increased number of successful cases, which will encourage more business sections to come forward in applying the software product lines method.

Do you have a system to create a virtuous cycle by which one successful case leads to another?


SHIMABUKUROAt Hitachi, there is a task force of willing people, and they endeavor to promote the software product lines practices through the task force framework. The task force has the mission of, through coordination of the entire Hitachi Group, working to generate base technologies that can be used across business segments and to disseminate the technologies throughout the Group. The task force activities may be tough for the members to do as they work on them in parallel with their own assignments in the sections they belong to. However, the task force is a group of motivated people aware of the issue.
The members may also invite young people who appear similarly aware, explaining the task force to them and encouraging them to consider it.

KATOI was also a member of the task force for about a year and worked to organize expertise, among other activities.

SHIMABUKUROThrough the task force, we introduce successful cases, such as the network switch in which Mr. Kato was involved, to other business units and group companies and receive comments and new perspectives. In fact, the network switch case served as a catalyst and application of the software product lines practices has already started in the development projects for products in completely different business areas.

So the software product lines practices are expanding into different business areas? What is the key to successfully expanding them?

SHIMABUKUROWe must make the software product lines practices understood by people who are capably positioned to control capital and organizations.
The software product lines method is something much like prior investment. Once the core assets are initially developed, it is easier to develop individual products. At certain points, or typically by the third or fourth development, the method reaches the break-even point and we can collect the amount equivalent to the prior investment. After that, we can expect to achieve further cost reduction and shorter development time.

Naturally, however, it is the manager-level people who determine whether or not the prior investment is made, so we need to convince them. To do this, we are introducing the cases collected by the task force to various sections and attempting to communicate with people about matters specific to their fields, such as the target business areas and the main points of development.
It is no easy job as we have to collect information in advance and use our intuition. However, it is also enjoyable for me to get involved in a variety of products rather than a single product.

Looking to the next decade

What reactions have you received both from inside and outside the company?

KATOAs for the network switch case, we were lucky to have an opportunity to present it at a Software Product Line Conference (SPLC) session. Inside the company, we're thankful for the task force as we often hear people say they heard about the case.
I find the situation much easier now for my research because my research activities have become known in this manner. Looking back, I believe what we have done will surely lead us to the next steps.

SHIMABUKUROBy getting involved in the development of a specific product, we were able to contribute to the relevant business area. We also had an opportunity to demonstrate the results at the academic circle. We gathered attention from inside and outside the company. These are resulting in an increased number of successful cases at Hitachi. I hope that this positive cycle will continue.

You mean you want to spread this technology further?

Photo: KATO Tadahisa

KATOThat's right. To do so, we will have to take the achievements with the network switches further as well as increase the number of other successful cases.

In fact, I had been away from the development front of the network switches for some time, but now have become involved in it again since this year. Several years had passed since we first applied the software product lines practices to the product, and people looked back the achievements to find that there was still room for improvement. That's why I was offered the job again.
To be frank, I am happy to have received feedback on the work I had been involved in in the past and to continue the work for a long time. In order to meet the expectations, I will take on new challenges while firmly looking back at past results.

SHIMABUKUROAs for me, I will leave the software product lines technology to Mr. Kato. It has long been one of my major research subjects, and I see a growing number of successful cases in which the technology is applied. But now, I hope to find new research themes that will become mainstays in the next decade.

People are currently talking about Industrie 4.0 and IoT (Internet of Things). As this suggests, we have to move into new areas. For example, how can we contribute to the industrial area by applying the technologies in the information area in which we have been involved? This may be a starting point in my search for new research subjects.


  • Publication: January 26, 2016
  • Professional affiliation and official position are at the time of publication.

Related links

  • Page top

Related contents

  • Page top