Model-based product line engineering applies the reuse practices from product line engineering with graphical modeling for the specification of software intensive systems. Variability is usually described in separate variability models, while the implementation of the variable systems is specified in system models that use modeling languages such as SysML. Most of the SysML modeling tools with variability support, implement the annotation-based modeling approach. Annotated product line models tend to be error-prone since the modeler implicitly describes every possible variant in a single system model. To identifying variability-related inconsistencies, in this paper, we firstly define restrictions on the use of SysML for annotative modeling in order to avoid situations where resulting instances of the annotated model may contain ambiguous model constructs. Secondly, inter-feature constraints are extracted from the annotated model, based on relations between elements that are annotated with features. By analyzing the constraints, we can identify if the combined variability- and system model can result in incorrect or ambiguous instances. The evaluation of our prototype implementation shows the potential of our approach by identifying inconsistencies in the product line model of our industrial partner which went undetected through several iterations of the model. 

Many organizations developing software-intensive systems face challenges with high product complexity and large numbers of variants. In order to effectively maintain and develop these product variants, Product-Line Engineering methods are often considered, while Model-based Systems Engineering practices are commonly utilized to tackle product complexity. In this paper, we report on an industrial case study concerning the ongoing adoption of Product Line Engineering in the Model-based Systems Engineering environment at Volvo Construction Equipment (Volvo CE) in Sweden. In the study, we identify and define a Product Line Engineering process that is aligned with Model-based Systems Engineering activities at the engines control department of Volvo CE. Furthermore, we discuss the implications of the migration from the current development process to a Model-based Product Line Engineering-oriented process. This process, and its implications, are derived by conducting and analyzing interviews with Volvo CE employees, inspecting artifacts and documents, and by means of participant observation. Based on the results of a first system model iteration, we were able to document how Model-based Systems Engineering and variability modeling will affect development activities, work products and stakeholders of the work products.

Product Line Engineering is an approach to reuse assets of complex systems by taking advantage of commonalities between product families. Reuse within complex systems usually means reuse of artifacts from different engineering domains such as mechanical, electronics and software engineering. Model-based systems engineering is becoming a standard for systems engineering and collaboration within different domains. This paper presents an exploratory case study on initial efforts of adopting Product Line Engineering practices within the model-based systems engineering process at Volvo Construction Equipment (Volvo CE), Sweden. We have used SysML to create overloaded models of the engine systems at Volvo CE. The variability within the engine systems was captured by using the Orthogonal Variability Modeling language. The case study has shown us that overloaded SysML models tend to become complex even on small scale systems, which in turn makes scalability of the approach a major challenge. For successful reuse and to, possibly, tackle scalability, it is necessary to have a database of reusable assets from which product variants can be derived.

Autonomous and intelligent construction equipment is an emergent area of research, which shares many characteristics with on-road autonomous vehicles, but also have fundamental differences. Construction vehicles usually perform repetitive tasks in confined sites, such as quarries, and cooperate with other vehicles to complete common missions. A quarry can be viewed as a system-of-systems and the vehicles are individual systems within the site system. Therefore it is important to analyze the site system, i.e. included vehicles, surrounding systems, and system context, before the introduction of autonomous vehicles. It is necessary to map the needed infrastructure, and the needed input information from on-board sensors and off-board information suppliers, before designing the vehicle electronics system. This paper describes how we identified sensory and input signal needs for an autonomous articulated hauler in a scenario at a quarry site. Different architectural alternatives are evaluated and a set-up for a quarry site is suggested.

A Quarry and Aggregate production site consist of sequential production processes and activities to process and produce the output products. Compared to a fixed manufacturing plant, the quarry processes involve mobile machines such as wheel loaders, trucks and articulated haulers and a highly dynamic road infrastructure. Today, the mobile machines are generally not synchronized or controlled towards the overall throughput of the site in real time. This indicates a general improvement potential in increased productivity at quarry sites, but also unsolved challenges for the same reason. Assuming a wireless control system that controls speed and throughput of the different processes and activities, there would be a fuel reduction potential in controlling the mobile machines. This optimization requires models of machine fuel consumption for different applications, velocities and travel times. The main contribution of this paper is the presentation of fuel measurements based on different speeds, site application characteristics and travel times for hauling operation. The fuel measures reveal important aspects regarding how different velocities impact fuel consumption. The results of fuel measurements show a potential in fuel savings of up to 42% and a typical improvement of 20-30% depending on machine speeds, travel times, application and site characteristics. Based on this, some of the applications and challenges in wirelessly controlling machines are discussed.

Context: Today, software and embedded systems act as enablers for developing new functionality in traditional industries such as the automotive, process automation, and manufacturing automation domains. This differs from 25–30 years ago when these systems where based on electronics and electro-mechanical solutions. The architecture of the embedded system and of the software is important to ensure the qualities of these applications. However, the effort of designing and evolving the architecture is in practice often neglected during system development, whilst development efforts are centered on implementing new functionality. Objective: We present problems and success factors that are central to the architectural development of software intensive systems in the domain of automotive and automation products as judged by practitioners. Method: The method consisted of three steps. First, we used semi-structured interviews to collect data in an exploratory manner. As a second step, a survey based on problems extracted from the interview data was used to investigate the occurrence of these problems at a wider range of organizations. In order to identify and suggest how to mitigate the problems that were considered important, we finally performed root cause analysis workshops, and from these a number of success factors were elicited. Results: A total of 21 problems have been identified based on the interview data, and these are related to the technical, organizational, project, and agreement processes. Based on the survey results, the following four problems were selected for a root cause analysis: (1) there is a lack of process for architecture development, (2) there is a lack of method or model to evaluate the business value when choosing the architecture, (3) there is a lack of clear long-term architectural strategy, and (4) processes and methods are less valued than knowledge and competence of individuals. Conclusion: In conclusion, the following identified success factors are crucial components to be successful in developing software intensive systems: (1) define an architectural strategy, (2) implement a process for architectural work, (3) ensure authority for architects, (4) clarify the business impact of the architecture, and (5) optimize on the project portfolio level instead of optimizing each project.