Reusability -A key factor in Product-line Development

Abstract: The Product-line approach has been shown to be a beneficial process for software development. It offers great paybacks on investment, in reduced time-to-market, development costs and maintenance costs. Here, the utilization and development of reusable components are key factors. To overcome reuse-related problems, component frameworks can be included in the product-line. In this report the product-line is further discussed. Then the industrial component model, Koala, developed for the product-line approach, is presented. The report starts with an overview of component based software development and the software lifecycle

Towards a guideline for refactoring of embedded systems

The electronics in automotive systems give great possibilities. It has contributed to environmental improvements through reduced emissions and reduced fuel consumption, safety, driver assistance, and quality through better diagnostic capabilities. Automotive systems are today distributed embedded systems that consist of several nodes that communicate with each other. The increasing possibilities have led to a situation where functions that used to be stand-alone, are today dependent on several inter-connected systems which all contribute to the desired functionality. This has increased the costs and the complexity to deal with the systems. The automotive industry is adopting a new open software architecture, called AUTOSAR, that is intended to reduce the complexity. AUTOSAR also gives possibilities for coping with large product ranges and for component sharing. The introduction of AUTOSAR is an example of an architecture change without modifying the external functionality. We have chosen to call such changes system refactoring. However, if the introduction of AUTOSAR is not successfully performed, there are risks for delayed development projects, which are costly for the automotive companies. Unfortunately, existing engineering standards and literature focus mostly on new product development and less on system re-factoring, and this gap needs to be filled. The goal of this research is to provide guidelines for refactoring, which provides support throughout the complete process of system architects in efforts to refactor the system. This thesis identifies the characteristics of refactoring processes. This is done by empirical studies of the drivers behind refactoring, the effects we can expect from refactoring, and the process activities and characteristics. The result can be used to create guidelines for improving the work of refactoring

An empirical study of refactoring decisions in embedded software and systems

AbstractThis 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 and functions in the company organization, and there is a lack of efficient analysis methods for decision support in the system architecture process. This study investigates the information needed to make a decision about a system refactoring. Scenario-based interviews have been conducted with managers and system architects from companies developing embedded systems. The results show that the companies investigate similar issues regardless of their industry sector. The most wanted information prior to a decision is also presented

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

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