AbstractIndividual collaborative embedded systems (CESs) in a collaborative system group (CSG) are typically provided by different manufacturers. Variability in such systems is pivotal for deploying a CES in different CSGs and environments. Changing requirements may entail the evolution of a CES. Such changed requirements can be manifold: individual variants of a CES are updated to fix bugs, or the manufacturer changes the entire CES product line to provide new capabilities. Both types of evolution, the variant evolution and the product line evolution, may be performed in parallel. However, neither type of evolution should lead to diverging states of CES variants and the CES product line, otherwise both would be incompatible, it would not be possible to update the CES variants, and it would not be possible to reuse bug fixes of an individual variant for the entire product line. To avoid this divergence, we present an approach for co-evolving variants and product lines, thus ensuring their consistency.

Making variability explicit in variable artifacts throughout the product lifecycle is difficult for variant modelers due to the different notations used to express variability. The tool integrations of the variant-management tool pure::variants address this problem, by providing a consistent method for denoting variability in frequentlyused development tools. However, differing technical extension mechanisms of the tools lead to inconsistencies between integrations and slow down the development process. To overcome these problems, we proposed a workflow for implementing new variant-management tool integrations based on real-life requirements and toolindependent use cases. The main idea is that integration developers can derive requirements for their specific integration, based on their knowledge about the supported extension mechanisms of the tool. To ensure continued consistency, the requirements document from which specific documents can be derived is continually updated while implementing new integrations. For evaluation, we tested for three exemplary tools whether it is technically feasible to apply the workflow, and argued based on plausibility and an interview with a pure::variants customer whether our goals are met. Although we identified issues for future work, we concluded that the workflow is technically feasible and fulfills our goals.

Cyber-Physical Systems (CPS) are usually developed by an incremental approach. A changing environment like demanding user requirements or legislation amendments lead often to multiple development paths in an evolving CPS. Hence, software variability plays an increasingly important role adapting the characteristics of such CPS to different contexts. This paper focuses on software variability realized through a Software Product Line (SPL) more specifically. Thereby, variability and evolution are usually managed in different tools. However with respect to software defects, a holistic handling of variability and evolution is necessary to ensure a reliable software defect removal. Particularly, detecting software defects in different evolution stages and derived variants is ordinary, but complex and error-prone. To close the gap between variability and evolution, this paper presents a systematic approach to combine both disciplines. In particular, we apply existing variant management techniques in combination with software configuration management methods to determine a software defect's origin and distribution in an evolving SPL. We apply our approach to a CPS from the automotive domain to show its industrial relevance and usefulness.

Im Rahmen des bereits abgeschlossenen BMBF-Projektes SPES 2020 wurden mit dem SPES 2020 Modeling Framework verschiedene integrierte Konzepte, Techniken und Methoden zum durchgängigen Engineering von softwareintensiven eingebetteten Systemen entwickelt. Die aus Sicht der Industrie äußerst relevante Fragestellung nach einer möglichst bruchfreien Unterstützung des durchgängigen Variantenmanagements und der Wiederverwendung wurde dabei bewusst nicht betrachtet. Im Rahmen des Nachfolgeprojektes SPES_XT soll nun der SPES 2020 Modeling Framework um die Unterstützung für ein durchgängiges Variantenmanagement und der Wiederverwendung erweitert werden. Im vorliegenden Beitrag werden hierzu die systematisch erarbeiteten Anforderungen der Branchen Automatisierungstechnik, Automotive und Avionik vorgestellt. Auf Grundlage der Anforderungen werden dann zentrale Forschungsfragestellungen skizziert.

Software product line (SPL) engineering provides an effective mechanism to implement variable software. However, using preprocessors to realise variability, which is typical in industry, is heavily criticised, because it often leads to obfuscated code. Using background colours to highlight code annotated with preprocessor statements to support comprehensibility has proved to be effective, however, scalability to large SPLs is questionable. The authors' aim is to implement and evaluate scalable usage of background colours for industrial-sized SPLs. They designed and implemented scalable concepts in a tool called FeatureCommander. To evaluate its effectiveness, the authors conducted a controlled experiment with a large real-world SPL with over 99 000 lines of code and 340 features. They used a within-subjects design with treatment colours and no colours. They compared correctness and response time of tasks for both treatments. For certain kinds of tasks, background colours improve program comprehension. Furthermore, the subjects generally favour background colours compared with no background colours. In addition, the subjects who worked with background colours had to use the search functions less frequently. The authors show that background colours can improve program comprehension in large SPLs. Based on these encouraging results, they continue their work on improving program comprehension in large SPLs.