Improving the efficiency of software integration testing is a critical challenge in the automotive industry, particularly as Electronic Control Unit (ECU) architectures become increasingly complex. This paper addresses the automation of integration test script generation by leveraging Large Language Models (LLMs) with Retrieval Augmented Generation (RAG). Specifically, we target the phase in which test engineers translate natural language test case specifications into executable scripts for integration test environments containing hardware debug interfaces. To bridge the knowledge gap between LLMs and domain-specific test tool APIs, we construct a task-oriented vector store that incorporates both API manuals and supplemental, workflow-centric information. By combining these with prompts containing code prefixes, our method enables LLMs to generate robust and correct integration test scripts. We evaluated our approach on typical test scenarios reflecting industry practices for multi-core ECUs. While the test cases used were not directly taken from a specific development project, they closely mirror those routinely employed across numerous automotive ECU development initiatives. The proposed method successfully generated executable scripts for all cases and reduced total test execution man-hours by 43% compared to a realistic baseline of manual execution. These results demonstrate the practical benefit of context-enriched LLMs in accelerating specialized software engineering tasks within the automotive domain, and it also identifies remaining challenges in extending automation to broader aspects such as test coverage, maintainability, and seamless process integration.

We report here an industrial application of the Product Line Engineering (PLE) for the development of electronic braking systems.

The paradigm of software product line (SPL) has already become popular not only in researchers but also in practitioners. However, that never means SPL is practiced in the real development. It is often observed that many companies hesitate to introduce SPL although they are bothered by numerous product variants of different/changing requirements or constraints and understand the importance of SPL.

If traceability links between requirements and source code are not clarified when conducting maintenance and enhancements for the same series of software products, engineers cannot immediately find the correction location in the source code for requirement changes. However, manually recovering links in a large group of products requires significant costs and some links may be overlooked. Here, we propose a semi-automatic method to recover traceability links between requirements and source code in the same series of large software products. In order to support differences in representation between requirements and source code, we recover links by using the configuration management log as an intermediary. We refine the links by classifying requirements and code elements in terms of whether they are common or specific to the products. As a result of applying our method to real products that have 60KLOC, we have recovered valid traceability links within a reasonable amount of time. Automatic parts have taken 13 minutes 36 seconds, and non-automatic parts have taken about 3 hours, with a recall of 76.2% and a precision of 94.1%. Moreover, we recovered some links that were unknown to engineers. By recovering traceability links, software reusability will be improved, and software product line introduction will be facilitated.

This paper reports introducing software product lines (SPLs) into multiple divisions at Hitachi. For any divisions developing software for product families that have many variations, an SPL is the key to improving quality, cost, and development efficiency. To introduce SPLs into multiple business divisions from small embedded systems to large power control systems, we organized an SPL project across organizations. Throughout the project, we have successfully introduced SPLs into multiple divisions and identified common and useful activities such as evaluating legacy systems, training domain experts, and sharing experiences with SPL experts. We also report the lessons learned from our experiences about SPL adoptions.

This paper describes a novel approach to detect variability in a software product line from its change history such that software changes are converted to vectors and a factor analysis is applied. To show the applicability of our approach, we conducted experimental applications using a software repository of automotive engine control software. As a result of the experiments, variability is detected from the change history of products.

For installing product line engineering in practice, strategies are needed that are composed of smaller steps where, on the one hand, each of them represents a well-defined move towards the ultimate goal of a well-functioning product line organization but, on the other hand, does not bear unmanageable risks. Hence product line approaches like Fraunhofer PuLSETM must define such steps, as well as provide a framework that supports their systematic combination into a tailored organizational strategy for installing product line engineering. This paper presents one step of such a strategy that focuses on the design activity. A well-known model-based design approach from the automotive domain is extended by the concept of variability and decision modeling. The resulting method has been prototyped and validated in a controlled environment. The measured results show that the method can be easily applied and leads to an effort distribution analogously to the typical product line curve.

Engine Control Systems (ECS) for automobiles have numerous variants for many manufactures and different markets. To improve development efficiency, exploiting ECS commonalities and predicting their variability are mandatory. The concept of software product line engineering meets the business background of ECS. However, we should carefully investigate the expected technical, economical, and organizational effects of introducing this strategy into existing products.This paper explains an approach for assessing the potential of merging existing embedded software into a product line approach. The definition of an economically useful product line approach requires two things: analyzing return on investment (ROI) expectations of a product line and understanding the effort required for building reusable assets. We did a clone analysis to provide the basis for effort estimation for merge potential assessment of existing variants. We also report on a case study with ECS. We package the lessons learned and open issues that arose during the case study.

The decision of an organization to introduce product line engineering depends on a sound and careful analysis of risks and return on investment. The latter is computed by an economic model, which relies on high quality input and must reflect the envisioned migration strategy sufficiently. To facilitate risk analysis, this paper applies Monte-Carlo simulation to an existing product line economic model. Additionally, the model is extended by the support of product line generations that is, considering the degeneration of product line infrastructures and taking reinvestment into an existing product line into account. The practical application of the model is demonstrated by an industrial case study