Sara Dersten

Effect Analysis of the Introduction of AUTOSAR: A Systematic Literature Review

Many complex software-intensive systems have a long life time, and undergo substantial evolution. These evolutions are either additions of functionality or system refactoring, i.e., updating the architecture to improve quality attributes without changing functionality. However, the return of investment for such a system refactoring is not easily measured due to a lack of understanding of its effects. In order to improve our understanding of these effects, we have conducted a systematic literature review of the reported effects of one such refactoring: the introduction of AUTOSAR, an open automotive software architecture standard. The effects include both benefits, like lower complexity and more efficient system development, and costs, like performance risks. We have investigated how the effects depend on different elements in AUTOSAR, and how the reports correspond to the stated objectives of the standard. It is also discussed to what extent these effects can be generalized to other types of refactoring.

An empirical study of refactoring decisions in embedded software and systems

This paper describes an empirical study of decision-making when changing the architecture in embedded systems. A refactoring of the system architecture often gives effects on both system properties ...

Analysis of the Business Effects of Software Architecture Refactoring in an Automotive Development Organization

This paper presents an exploratory study of an automotive manufacturer, which develops embedded software for over 150 products and has adopted a company-wide software product-line approach. The company is facing the introduction of a new software architecture in all products in near time. This architecture introduces new paradigms more explicitly, such as explicit software components and signal-based communication, newer technologies, and adheres to new standards. Concretely, the architecture consists of common infrastructure and other generic components. Such a fundamental and drastic technology change can be expected to have far-reaching consequences, both of technical and non-technical nature. In this study we systematically investigate the introduction of the new software architecture, by mapping individual elements of the architectural change to system properties and company functions. The study implies that the whole organization is affected, and the new architecture also influences the cooperation with suppliers.

Analysis of the information needs of an autonomous hauler in a quarry site

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.

Defining a method for identifying architectural candidates as part of engineering a system architecture

Engineering system architectures for complex systems involves the tasks of analyzing architectural drivers, identifying architectural concerns, identifying valid architecture candidates, and evaluation of alternatives. One problem to overcome when architecting a system is the identification of valid of architectural candidates. We have developed a step-wise method for performing system architecture analysis and tested it on a sub-system in a project developing a drive system for heavy automotive applications. In this paper we present the complete method of nine steps for engineering an architecture and we elaborate in detail on the procedure to identify architectural candidates based on previously identified architectural drivers. We present a diagram depicting the proposed information model, its concepts and their relationships. In addition, the expectations on such a method as expressed by practitioners have been elicited, and we elaborate on the validity by examining how well the method indicate fulfillment. Our conclusion is that the proposed method does not fail to deliver on any of the needs and this gives an indication of usefulness. When identifying architectural candidates it is important to use proper criteria in the process. Our conclusion is that the practitioners should focus on candidates that affect the system at hand (within system boundaries), and on the candidates that address the architecturally significant system use. This is reflected in our method where we prescribe evaluation of the design candidates by validating that they solve only the right problem and by ensuring that they address the system at hand.

An analysis of a layered system architecture for autonomous construction vehicles

It has been suggested in the literature to organize software in autonomous vehicles as hierarchical layers where each layer makes its own decisions based on its own world model. This paper presents two alternative designs for autonomous construction vehicles based on the layered framework 4D/RCS. As a first step, the typical use cases for these vehicles were defined. Then one use case for a hauler was traversed through the two alternatives to see how they supported safety, flexibility and the use of a product platform. We found that the coordination between bucket control and motion control must be done at a low level in the hierarchy and that the relationship between the vehicle actuators and the built-in autonomous system is important for how the software is organized.