Ulrik Eklund

Hazard analysis in object oriented design of dependable systems

Mass produced products are becoming more and more complex, which forces the designers to model the functionality early in the design process. UML Use cases was found to be a useful method for this purpose at Volvo Cars and is currently used for modeling all functions implemented in the electrical network. When using Use cases in the design of complex safety critical systems, there is still an uncovered demand for early hazard analysis at a functional level. This work integrates a modified functional hazard assessment method and Use cases. The analysis generates valuable results used as design requirements and dependability analysis input. The methods results have exceeded our expectations. An example is included, showing how the method works.

Experience of introducing reference architectures in the development of automotive electronic systems

The requirements on increasing functionality, quality, and, customisation, while reducing cost has lead to the introduction of an architecture centred development process for electronic systems at Volvo Cars. This process enables better control of system integration and achieving non-functional requirements, such as reusability, understandability, etc. The result of the process is a reference architecture that includes strategies for implementing the balanced requirements, architectural views that provide means for reasoning about all the concerns of all stakeholders, and a top-level design of the architecturally significant parts. The reference architecture guides the design of several projects, and thus, cost is optimised accordingly. The main contribution of this paper is that we present experiences from introducing the architecture centred process. The main conclusions are that disseminating and maintaining the reference architecture actually require more resources than developing it. Furthermore, experience shows it is difficult to create an architecture that enables a lot of different variants that is also strategically useable in the long term.

Architecture for embedded open software ecosystems

Software is prevalent in embedded products and may be critical for the success of the products, but manufacturers may view software as a necessary evil rather than as a key strategic opportunity and business differentiator. One of the reasons for this can be extensive supplier and subcontractor relationships and the cost, effort or unpredictability of the deliverables from the subcontractors are experienced as a major problem. The paper proposes open software ecosystem as an alternative approach to develop software for embedded systems, and elaborates on the necessary quality attributes of an embedded platform underlying such an ecosystem. The paper then defines a reference architecture consisting of 17 key decisions together with four architectural patterns, and provides the rationale why they are essential for an open software ecosystem platform for embedded systems in general and automotive systems in particular. The reference architecture is validated through a prototypical platform implementation in an industrial setting, providing a deeper understanding of how the architecture could be realised in the automotive domain. Four potential existing platforms, all targeted at the embedded domain (Android, OKL4, AUTOSAR and Robocop), are evaluated against the identified quality attributes to see how they could serve as a basis for an open software ecosystem platform with the conclusion that while none of them is a perfect fit they all have fundamental mechanisms necessary for an open software ecosystem approach.

Eternal embedded software: towards innovation experiment systems

The paper discusses the concept of innovation experiment systems in the context of long-lived embedded systems. These systems need to evolve continuously to stay competitive and provide value to the customer and end-user, especially in domains where the pace of change is increasing. Innovation experiment systems provide a natural mechanism that allows an embedded system, its architecture and underlying platform to continuously evolve in response to changes in the user requirements and system context. It uses a rapid feedback loop to evaluate the benefits of small variations to users with the intent of continuous improvements. The paper explores the architectural implications as the ability to continuously evolve and conduct experiences in the deployed product context in a safe and controlled manner must be supported by the architecture of the embedded systems. Finally, the paper illustrates these concepts using a case study concerning an infotainment system in the automotive industry.

Applying Agile Development in Mass-Produced Embedded Systems

The paper presents a method to manage critical interactions to manage when introducing agile software development in mass-produced embedded systems. The method consists of a context model together with a set of measures, and is validated by empirical evidence from three cases.

Cusp and boundary layer observations by INTERBALL

Abstract Interball Tail Probe was launched on August 2, 1995 together with its subsatellite MAGION-4 into a highly elliptical orbit with apogee at 31 RE and inclination 63 degrees. During the course of one year all local times are visited. In this paper we will present initial results obtained from measurements in the cusp, mantle and eveningside plasma sheet in January, 1996. It is found that the cusp was well defined and persistent at altitudes of 4–10 RE. In one case both the main satellite and the subsatellite were in the cusp proper for two uninterrupted hours. We believe this to be the first ever multi-point satellite observation of the high-altitude cusp. The data indicate that the cusp was very stable with a wide entry area and that plasma entry took place at high latitudes rather than at the subsolar point. Pressure pulses, possibly due to Alfven waves were found. Sunward and antisunward moving plasma was measured simultaneously during a case of northward IMF but no convection was discovered. Plenty of plasma of cusp/magnetosheath type was also found mixed with plasma sheet plasma both equatorward of the cusp and in the eveningside plasma sheet.

Architecting automotive product lines: industrial practice

This paper presents an in-depth view of how architects work with maintaining product line architectures in the automotive industry. The study has been performed at two internationally well-known companies, one car manufacture and one commercial vehicle manufacture. The results are based on 12 interviews with architects performed at the two companies. The study shows what effect differences such as a strong line organization or a strong project organization has on the architecting process. It also shows what consequence technical choices and business strategy have on the architecting process. Despite the differences the results are surprisingly similar with respect to the process of managing architectural changes as well as the information the architects maintain and update, especially in the light that the companies have had no direct cooperation.

A reference architecture template for software-intensive embedded systems

The paper presents a document template for reference architectures for the domain of software-intensive embedded systems. The template addresses the somewhat conflicting needs when documenting a reference architecture of readability, overview, details, evolution and different background of the stakeholders. The first novel idea is the template prescribes two separate documents describing a reference architecture beside the product architecture documentation. The information in the two documents concern different stakeholders and evolve at different paces. The other novelty in describing reference architectures is to introduce a perspective of time, in the form of horizons, rather than focusing on a snapshot a release date. In addition, a case is presented giving an example of how a reference architecture was documented according to the template, how stakeholder needs were captured, and how the different types of information was identified or recovered from existing product architectures.

Stakeholder identification and quality attribute prioritization for a global Vehicle Control System

An industrial case study in stakeholder identification and quality attribute prioritization for a Vehicle Control System (VCS) is presented. The system stakeholders were identified and a list of quality attributes was developed. A team of co-located Ford Motor Company engineering liaisons identified and interviewed stakeholders from their home organizations. The interview results were processed quantitatively and the top quality attributes were identified. Lessons learned from the process are included.

Industrial Challenges of Scaling Agile in Mass-Produced Embedded Systems

When individual teams in mechatronic organizations attempt to adopt agile software practices, these practices tend to only affect modules or sub-systems. The short iterations on team level do not lead to short lead-times in launching new or updated products since the overall R&D approach on an organization level is still governed by an overall stage gate or single cycle V-model.