Building robust industrial machine learning (ML) models requires incorporating domain knowledge in feature selection. This ensures building meaningful ML models that fit the context of the industrial process that consists of complex networks of thousands of elements interconnected by flows of material, energy, and information. Despite the various automatic feature selection methods, they are still outperformed by the manual feature selection that embeds the industrial domain knowledge. This paper proposes an industrial feature selection method that (1) automatically captures domain knowledge from topology models holding information on the industrial plant and (2) identifies the relevant process signals (i.e., features) to a specified process element (i.e., to which an ML model is being built). We performed an empirical case study on an industrial use case to evaluate the effectiveness and efficiency of the proposed method in comparison to existing ones from literature.

An industrial process consists of a complex network of thousands of elements interconnected by the flow of material, energy, and information. Each of these elements can be attached to several sensors producing different process signals. Building robust industrial machine learning (ML) models requires handling this multi-dimensional process data while incorporating the process domain knowledge in the feature selection activity. Despite the variety of methods that automate this feature selection task, in industrial practice, they are outperformed with the manual feature selection by domain experts as embedding the industrial domain knowledge. In this paper, we introduce a feature selection method for industrial ML that (1) automatically captures domain knowledge from process topology models that hold information on the plant process and (2) uses it to identify the relevant features (i.e., process signals) to a specified process element to which an ML model is being built. We performed an empirical case study on two industrial use cases to evaluate the effectiveness and efficiency of the proposed method in comparison to existing ones from the literature. In the first use case, our method improved the ML model performance with accuracy of 95% and recall of 91%, compared to a baseline model that achieved 70% and 5% respectively. It also decreased the training time by 81% with a simpler model. In the second use case, our method competed equally with the other methods with regards to model performance, however, it outperformed them in decreasing the training time by 64% with a simpler model.

Transforming a clone-and-own (i.e., new product variants are created by copying and modifying existing artifacts) code structure and development process to a Software Product Line Engineering (PLE) approach is a tedious and error-prone task. Holistic tool support for such a process is highly desirable, especially to lower efforts and to speed up the transformation. Unfortunately, such a holistic toolchain for reverse engineering of variability, supporting variant-centric and platform-centric extraction approaches is not available. In this paper, we present a toolchain covering the first steps for moving a clone-and-own product development to a PLE approach. We validate the first prototype of the toolchain on a case study consisting of industrial firmware for smart motor controllers and we show that even this early prototype reduces time and effort for moving to a configurable platform approach in the sense of PLE.

Engineering software amounts to implementing and evolving features. While some engineering approaches advocate the explicit use of features, developers usually do not record feature locations in software artifacts. However, when evolving or maintaining features - especially in long-living or variant-rich software with many developers - the knowledge about features and their locations quickly fades and needs to be recovered. While automated or semi-automated feature-location techniques have been proposed, their accuracy is usually too low to be useful in practice. We propose a semi-automated, machine-learning-assisted feature-traceability technique that allows developers to continuously record feature-traceability information while being supported by recommendations about missed locations. We show the accuracy of our proposed technique in a preliminary evaluation, simulating the engineering of an open-source web application that evolved in different, cloned variants.

Software interoperability property plays a vital role in enabling interoperation in todayfis system-of-systems, cyber-physical systems, ecosystems, etc. Despite the critical role of interoperability analysis in enabling a successful and meaningful software interoperation, it is still facing challenges that impede performing it effectively and efficiently. We performed an online survey of software engineers with software integration experiences to identify the main difficulties of performing interoperability analysis. The results confirm that the state of available practical support and current input artifacts used during the analysis are significantly perceived as important difficulties. Respondents claim a lack of guidelines and best practices for applying interoperability analysis and claim insufficiency of shared information about interoperable software units. This indicates the need for providing directive and rigorous guidelines for practitioners to follow and to enrich the content of shared documents about interoperable software units.

Successfully integrating a software system with an existing other software system requires, beyond technical mismatches, identifying and resolving conceptual mismatches that might result in worthless integration and costly rework. Often, not all relevant architectural information about the system to integrate with is publicly available, as it is hidden in internal architectural documents and not exposed in the public API documentation. Thus, we propose a framework of conceptual interoperability information and a formalization of it. Based on this framework, a system's architect can semi-automatically extract interoperability-relevant parts from his architecture and lower-level design documentation and publish it in a standardized and formalized way. The goal is to keep the additional effort for providing the interoperability-relevant information as low as possible and to encourage architects to provide it proactively. Thus, we extract from UML diagrams and textual documentation information that is relevant for conceptual interoperability. Companies that aim at interoperation of their systems with others, e.g. Companies initiating an ecosystem, should be highly motivated to provide such interoperability information in order to grow their business impact by more successful interoperations. In a more advanced level, also the architect, who is integrating his system with a provided one, could extract interoperability-related information about his existing system and we envision to automatically match the pieces of both sides and identify conceptual mismatches.