Joakim Froberg

This paper describes the Architecture Life Cycle Effect Analysis (ALCEA) method, a structured method for evaluating proposed new architectures for software-intensive systems. The method evaluates a proposed architecture by quantifying its effect on the performance of system life-cycle phases. The method is instantiated by identifying (i) the relevant life-cycle phases of the system under investigation and (ii) a set of evaluation functions that capture, in terms of basic factors, the effect of different architectural decisions on key life-cycle performance attributes, such as revenue, operating resources, and investments. The method results in a transparent cost and revenue structure, documented in a tabular form, based on quantifiable factors from the developing organization. The results of the method can be used directly as part of a business case, and their robustness can be estimated by sensitivity analysis. The ALCEA method is designed for system-level architectural analysis, covering both software and hardware aspects. In this paper, we introduce the ALCEA method and provide a detailed example of how to apply it in the evolution of embedded systems. Moreover, we share early experiences of using the method in large-scale industrial settings.

Automation of earth moving machinery enables improving existing production workflows in various applications like surface mines, material handling operations or material transporting. Such connected and collaborating autonomous machines can be seen as a system-of-systems. It is not yet clear how to consider safety during the development of such system-of-systems (SoS). One potentially useful approach to analyze the safety for complex systems is the System Theoretic Process Analysis (STPA). However, STPA is essentially suitable to static monolithic systems and lacks the ability to deal with emergent and dysfunctional behaviors in the case of SoS. These behaviors if not identified could potentially lead to hazards and it is important to provide mechanisms for SoS developers/integrators to capture such critical situations. In this paper, we present an approach for enriching STPA to provide the ability to check whether the distributed constituent systems of a SoS have a consistent perspective of the global state which is necessary to ensure safety. In other words, these checks must be capable at least to identify and highlight inconsistencies that can lead to critical situations. We describe the above approach by taking a specific case of state change related issues that could potentially be missed by STPA by looking at an industrial case. By applying Petri nets, we show that possible critical situations related to state changes are not identified by STPA. In this context we also propose a model-based extension to STPA and show how our new process could function in tandem with STPA.

The development of system‐of‐systems (SoS) requires a continuous interplay between design decisions on the SoS level and those on the level of its constituent systems (CS), which often preexist and need to be adapted as the SoS evolves. This involves not only preparing the CS to participate in a particular SoS, but also designing the CS architecture to make it easily adaptable to a future SoS context. The problem is in part addressed in an emerging SoS framework in the manufacturing domain called Industry 4.0. It focuses on connected and digitalized production with the ambition of increasing flexibility and efficiency. This paper investigates how Industry 4.0 standards can be used in an SoS context to make CS more flexible and adaptive, and evaluates their usefulness outside manufacturing. The study is based on a case from the construction domain, for which a generic SoS architecture is developed. Several extensions and adaptations of Industry 4.0 are suggested, including specifications of ontologies for missions and workflows.

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.