Software product line engineering aims to systematically generate similar products or services within a given domain to reduce cost and time to market while increasing reuse. Various studies recognize the success of product line engineering in different domains. Software variability have increased over the years in many different domains such as mobile applications, cyber–physical systems or car control systems to just mention a few. However, software product line engineering is not as widely adopted as other software development technologies. In this paper, we present an empirical study conducted through a survey distributed to many software development companies. Our goal is to understand their need of software variability management and the level of knowledge the companies have regarding software product line engineering. The survey was answered by 127 participants from more than a hundred of different software development companies. Our study reveals that most of companies manage a catalog of similar products in a way or another, they mostly document the features of products using text or spreed sheet based documents and more than 66% of companies identify a base product from which they derive other similar products. We also found a correlation between the lack of Software Product Line (SPL) knowledge and the absence of reuse practices. Notably, this is the first study that explore software variability needs regardless of a company’s prior knowledge of SPL. The results encourages further research to understand the reason for the limited knowledge and application of software product line engineering practices, despite the growing demand of variability management.

IEC 61499 is a standard for developing distributed industrial control software. It supports the configurability of the control software as the application model is platform-independent and separated from the system model that defines the hardware configuration specification. Thus, it can be used to develop control software for highly configurable Cyber-Physical Production Systems (CPPS). To address their customers’ requirements, companies that build CPPSs over time develop many variants of such production systems, typically through clone-and-own reuse, which increases engineering and maintenance efforts. Managing the control software variability in CPPSs in a systematic manner would facilitate software reuse and reduce the cost of developing and maintaining these systems. However, the IEC 61499 standard itself offers only limited capabilities for managing variability, e.g., by utilizing a library of modular components or by following certain design patterns. In this paper, we propose an approach to systematically manage IEC 61499-based control software using a (textual) delta modeling approach. Delta modeling is a prominent concept in the Software Product Line (SPL) domain for expressing and maintaining software variability. We show how our delta modeling approach can express control software variability and provide a semi-automatic control software generator. We evaluate the usability of our approach by applying it to multiple case studies as well as by performing a user study, in which control software engineers used our delta modeling approach. Our evaluation results indicate potential benefits of our delta modeling approach to implement and maintain control software through software generation.

Cyber-Physical Production Systems (CPPSs) consist of deeply intertwined physical and software components. In the last decade, the number of mechatronic components (sensors, actuators, etc.) in a system is increasing enormously to enable more flexible, intelligent production with more support for customization. Mechatronic variability, like different variants of sensors or actuators in the system, directly affects the control software. The standardization of physical interfaces of mechatronic components has provided well-defined plug-and-play interaction. Conversely, software components in the CPPS domain still face the issue of standardizing functionality. Software adaptability often leads engineers to develop control software for new mechatronic variants by just copying and modifying existing software. This leads to multiple and completely separate instances of the control software and a high development and maintenance effort. The core functionality of the control software should be standardized and reused as much as possible to reduce the development effort and improve overall reliability. This paper discusses an approach to standardize core functionality of IEC 61499-based control software. Our design approach encapsulates the process core functionality and defines standard interfaces for interacting with mechatronic variant software components. We evaluate our design approach by comparing it to the traditional clone-and-own approach for an academic case study system, a capping station. Additionally, we assess the impact of adding a new variant in the control software and analyze what changes are needed to keep the same core functionality. When introducing new mechatronic variants in combination with standardized core functionality, our design approach reduces the overall control software variance and maintenance effort.

The rising complexity of modern production systems raises the need for evaluating the code quality also in control software engineering. Complexity metrics can help identifying code that is difficult to maintain and may benefit from a refactoring. Although complexity metrics have already been adapted to the domain-specific languages (DSLs) used for cyber-physical production systems (CPPSs), literature on whether developers benefit from using these metrics is limited. Also, the complexity perception of code by the domain experts remains to be investigated. The perceived difficulty of comprehending a program can vary among developers and also between different implementation variants of the same functionality. We therefore asked industrial experts, who have experience in the respective DSLs, to rate the complexity of semantically equivalent implementations to find out which metric best represents their complexity perception and whether there are differences between implementation variants. The examples used in the study were inspired, in parts, by an open source library for IEC 61131-3. We found that the Cognitive Complexity metric is a useful representation of the software complexity in the domain, as it best matched the domain experts’ perception of complexity. These metrics should therefore be supported by the analysis tools.

Modeling distributed control software facilitates reacting to changing hardware configurations due to the higher abstraction level. Well-designed modules of such systems may be arranged flexibly to perform production tasks, which need to be adapted during the life-cycle of the system. Although IEC 61499 supports modeling the relations between inputs and outputs of its software components as service sequence models, these models are not integrated with the rest of the development process. In this paper, we outline our vision of using the captured information on the interface behavior for development tasks of distributed control software modeled according to IEC 61499. The proposed research directions can contribute to the acceptance of modeling methods in the domain, as appropriate tool support can notably leverage the benefit of models.

Cyber-Physical Production Systems (CPPSs) are highly variable systems of systems comprised of software and hardware interacting with each other and the environment. The increasing integration of technologies and devices has brought an unprecedented level of automation and customization. At the same time, it has also increased the efforts to maintain highly complex and heterogeneous systems. Although engineering practices support the reuse of common components to ease the development and maintenance of the systems in different projects, the identification of common components is still manually performed, which is a time-consuming, error-prone task. In this paper, a novel approach identifying repeating patterns in CPPSs based on artificial intelligence techniques is presented. This approach allows finding exact and similar components to support the CPPS design. Furthermore, it enables the maintenance of common components by reusing predefined types thereby reducing development effort. We implemented and evaluated our approach in an industry case study on developing CPPS control software with IEC 61499.

automated Production Systems (aPS) represent a special type of mechatronic system characterized by a high complexity in hardware and software, lifetimes of up to several decades, and strong coupling of the involved disciplines, i.e., mechanics, electrics/electronics, and control software. Questionnaire studies have proven to be a valuable means of identifying obstacles in industrial software development that hinder the implementation of emerging technologies in the context of Industry 4.0 and, thus, the realization of Cyber-Physical Production Systems. However, the heterogeneity of different industrial sectors in terms of, e.g., the type of production processes or legal specifications, makes it difficult to compare the maturity of control software development across companies, even within the same industry. A software maturity benchmark for companies operating in similar industries is, however, a prerequisite for assessing a company’s strengths and weaknesses and thereby applying tailored solutions to improve the software and, thus, the competitiveness. This paper describes the results of a questionnaire study in two international companies operating in the same industrial sector. Specifically, location-, company-, and industry-specific maturity characteristics are analyzed and discussed, and it is concluded that the selected questionnaire is capable of identifying deviations and similarities in software maturity, even in an international environment, given that the companies are prefiltered based on the covered supply chain step. Hence, assuming a sufficiently large number of participants per industry, it enables a questionnaire-based industry comparison in future work, which was not possible until now.

A Service Level Agreement (SLA) regulates the provisioning of a service by defining a set of guarantees. Each guarantee sets a Service Level Objective (SLO) on some service metrics, and optionally a compensation that is applied when the SLO is unfulfilled or overfulfilled. Currently, there are software tools and research proposals that use the information about compensations to automate and optimise certain parts of the service management. However, they assume that compensations are well defined, which is too optimistic in some circumstances and can lead to undesirable situations. In this article we discuss about the notion of validity of guarantees with a compensation, which we refer to as compensable guarantees (CG). We describe an abstract model of CGs and we provide a technique that leverages constraint satisfaction problem solvers to automatically validate them. We also present a materialisation of the model of CGs in iAgree, a language to specify SLAs and a tooling support that implements our whole approach. An assessment over 319 CGs taken from 24 real-world SLAs suggests that the expressiveness and effectiveness of our proposal can pave the way for using CGs in a safer and more reliable way.