Architectural properties are amongst the defining features of systems of systems (SoS) -including distribution of the constituent parts, their autonomy, long lifecycles and unsynchronized evolution. In addition, SoS engineers need to consider the integration of legacy constituent parts, reason about the emergent behaviour of the SoS, determine the level of centralised control, and support resilience and fault tolerance. These are all features which can be tackled at least partially through architectural patterns. In this article, we present three example patterns previously identified in SoS. Patterns like these can also be used as a mechanism for transferring lessons learned in one SoS application domain into another domain. For each pattern presented, we highlight features that address the challenges posed by SoS. Finally, we detail ongoing efforts with the INCOSE Systems of Systems and Patterns Working Groups to prioritise future work in this area.

Abstract. Systems of systems (SoSs) are characterised by a challenging combination of continuous evolution, emergent behaviour and distributed, autonomous and independent constituents. The development of SoSs that can tolerate faults and harmful events is hampered by these and other complexities. Currently there is little in the way of methods or tools to help SoS developers to design fault-tolerant SoSs. In this paper we present a structured approach for capturing requirements for a fault-tolerant SoS and a fault modelling architectural framework (FMAF) that supports disciplined and reusable development of fault-tolerant architectures. We also provide a traceable mapping of the fault-tolerant requirements into SoS architectural designs. Finally we apply our techniques to a real-world SoS case study.

No abstract

No abstract

Systems of systems (SoSs) are vulnerable to faults, for example arising as a result of the distribution and independence of their constituent systems. Our previous work has presented an initial framework for reasoning about faults and fault-tolerant design within an SoS at the architectural level, using a simple example of a single failure. In this paper we present a motivating example of an SoS within which failures of constituent systems (CSs) may lead to a degraded or partial service for the SoS. We discuss a possible extension to our earlier framework to allow an architectural engineer to reason about the fault tolerance of an SoS where CSs contribute negatively or positively towards a goal or an SoS-level failure, and where multiple SoS faults may interact to affect SoS service quality.

Abstract-This paper presents an initial report on modelling patterns and architectures for system of systems (SoSs) and their constituent systems (CSs). Fundamental architectural principles for systems and SoSs and relevant work published so far are discussed and summarised. We introduce an initial set of five architectural patterns suitable for SoS design, illustrating each pattern with an SoS example and identifying how it meet some basic SoS aims. Finally, we summarise our plans for developing these ideas in the future.

Studies of resilience highlight the tension between actions that allow a firm -and a systemto be robust and those that allows it to be flexible. Studies suggest that an entrepreneurial firm will prioritize flexibility, given resource constraints. However, what occurs when a number of firms are embedded in a common socio-technical system and an extreme event affects them collectively? This paper tests whether existing theory about resilience predicts the responses of entrepreneurs in such a system, with reference to an extreme event in the Bitcoin sociotechnical system: the much-publicized bankruptcy of Mt.Gox, a key player. It relies on indepth interviews with 8 entrepreneurs in Europe, triangulated with other data. We find that robustness is the dominant strategy for those interviewed. This is partly because the firms rely on pooled resources supplied by the collective, and partly because robustness builds trust, giving the firms a competitive advantage.

No abstract