The validity of the safety case models must be revised every time there is a change in the system specification. However, currently, such validity revision is done manually, implying a considerable amount of effort and costs. Given the frequent changes to architectural structures of flexible systems, there is a need to automate validity checks for safety cases. To this end, we introduce checkable safety case models with the scope of supporting safety engineers in maintaining valid safety case models given changes in other system models. Checkable safety case models are a special type of safety case model that is integrated with system models, which are amenable to automated checks.

To this end, we extend the SPES\_XT modeling framework with a new system view, that is, the safety case view. The safety case models are to be integrated with the other system models corresponding to different viewpoints (e.g., requirements viewpoint, logical viewpoint). The safety case model is to be modeled alongside the system development and will be maintained to ensure consistency with other system models during the entire system lifecycle.

To support safety engineers in modeling checkable safety cases, we propose a set of checkable safety case patterns. Similar to design patterns, safety case patterns are templates for re-occurring safety fragments that can be reused in different safety cases [Kelly and McDermid 2010]. These templates entail placeholders for systemspecific information which are to be filled when the pattern is used in a certain safety case. We extend the concept of safety case patterns with checkable safety case patterns. Checkable safety case patterns come with a set of automated checks that may be performed on the safety case fragment obtained after the instantiation of the pattern. Among other things, the safety case of a system must entail an argument about the satisfaction of safety properties by the system

architecture. As reference architectures are blueprints to be used for modeling system architectures, for each such reference architecture we provide a pattern for arguing about the fact that the reference architecture satisfies certain safety properties. When the architecture of a certain system uses a certain reference architecture as a blueprint, the corresponding safety case checkable pattern can be used to model the safety argumentation for the constructed system architecture.

#### **3.4.1 Checkable Safety Case Models – A Definition**

To support safety engineers in the cumbersome, time-consuming process of keeping safety case models consistent with system models (e.g., system architecture models), we propose checkable safety cases.

*Extension of the SPES\_XT modeling framework*

*Modeling checkable safety case fragments for reference architectures*

*Safety case models on which automated checks can be executed* The validity of checkable safety case models is checked by the automatic execution of sanity checks, based on explicit specification of semantics of safety case elements, and the integration of the safety case model with system models and automated verification approaches [Cârlan et al. 2019], see Figure 3-8.

*Fig. 3-8: Safety argumentation based on contract-based verification*

Given a change in a system model that is traced from the safety case model, consistency checks between the safety case model and the system models are automatically executed. These consistency checks assess whether the argumentation is still valid considering the changes in the system model that the argumentation applies to. Then, the safety engineer must update the safety argument in accordance with the changes, while also generating the evidence required. Given that system models are amenable to automated checks, the results of such checks can be used as evidence in safety cases. Therefore, we integrate safety case models with such automated verification approaches, thus enabling 1) automatic detection of stale evidence, and 2) automatic integration of new verification results as evidence, while assessing the impact of the new evidence on the confidence in the overall argumentation.

*Checkable safety cases entail checkable and non-checkable argumentation fragments*

Checkable safety case models entail both checkable and noncheckable argumentation fragments that are connected with each other. On the one hand, non-checkable argumentation fragments entail regular safety case elements, as defined by the Goal Structuring Notation (GSN) — a standardized graphical notation for describing safety cases and currently the most frequently used language for modeling safety cases [GSN 2018]. On the other hand, checkable safety case fragments entail a set of interconnected specialized safety case elements. Specialized safety case elements extend GSN, with each specialized element representing a reoccurring claim in safety cases, thus having certain semantics. Specialized safety case elements reference certain types of system model elements or entail metadata regarding certain verification approaches. They may be connected to each other only via specialized connections, which extend the connections specified in GSN. In contrast to GSN-based connection types that ensure the correct construction of arguments from a semantic point of view, specialized connections enable intrinsic checks on safety case models, which ensure the construction of semantically correct arguments.

#### **3.4.2 Checkable Safety Case Patterns**

To support safety engineers in modeling checkable safety cases, we propose an exemplary set of checkable safety case patterns.

While the argumentation structure of checkable safety case patterns is based on state-of-the-art patterns, the connected elements the structure contains are specializations of regular safety case elements. The specialized safety case elements have variable declarations, which are placeholders for a reference to a certain type of system element or verification information. The variables are to be instantiated with specific references when the pattern is used to model the safety case of a certain system. The relationships among specialized safety case elements are described via dedicated connections, thus enabling intrinsic consistency checks, which prohibit pattern misuse — a specialized safety case element may be connected only to certain types of other specialized safety case elements.

A checkable safety case pattern is specified as presented in the following [Kelly and McDermid 2010]. We extend the specification of regular safety case patterns with information specific to checkable safety case patterns:

*Checkable safety case patterns enhance stateof-the-art patterns to enable automated checks*

The following documentation information is specific to checkable safety case patterns:

#### **3.4.3 An Example of Checkable Safety Case Patterns**

*Arguing about the satisfaction of a certain safety property by an architecture*  In Figure 3-9, we present part of the checkable safety case fragment concerning the satisfaction of a certain safety property by a system architecture built in a contract-based manner. The system architecture entails assume-guarantee (A/G) contracts that formalize safety properties. The properties are satisfied if: 1) the contracts of the architecture model are correctly refined by the contracts of the components within the architecture model (claim expressed as *Refinement Check* specialized goals); 2) the contracts of the architecture components are satisfied (claim expressed as *Compatibility Check* specialized goals); and 3) each architecture component correctly implements its contracts (claim expressed as *Implementation Check* specialized goals). Each claim in the argument is a specialized safety case element, with a certain meaning and with certain references to system model elements. Given specialized connections between specialized elements, intrinsic consistency checks are enabled. For example, elements of the type *CBD Strategy* may be supported only by goals of the type *Compatibility Check*, *Refinement Check,* and *Implementation Check*, ensuring the validity of the argument structure. The *CBD Strategy* references a certain component in the system architecture that will implement the safety contract. Consequently, to ensure the validity of the argumentation, we check whether the sub-goals of the type *Implementation Check* supporting *CBD Strategy* reference only children of the component referenced by the strategy. The validity of claims of the type *Implementation Check* is checked via an automated verification tool able to check architecture models annotated with contracts — a model checker. In the example presented in Figure 3-9 the model checker used is NuSMV [Cimatti et al. 2002].

*Fig. 3-9: GSN-based safety case fragment*

In Figure 3-9 a GSN-based safety case fragment is shown arguing about the verification via NuSMV model checker of the system architecture model against system safety properties specified as contracts. Due to space constraints, the figure displays only part of the argumentation, namely the argumentation legs regarding the correct implementation of the subcomponents of the architecture.

In conclusion, we propose the creation of checkable safety case patterns that argue about the implementation of safety properties by a system architecture which may also be based on a certain reference architecture. Given the specialized safety case elements contained in the pattern and their integration with system models and verification tools, the validity of the argumentation fragment resulting from the pattern instantiation is automatically checked if there is a change in the corresponding system architecture model. These automated checks are especially needed if there are frequent changes.

#### **3.5 Conclusion**

In this chapter, we presented a general method for designing reference architectures and deriving system architectures for CESs and their CSGs in order to support reuse of system architectures. In addition, the method can be used to design a CSG and the interfaces of collaborating CESs within this CSG. In a next step, the architectures of the CES can be refined based on the reference architecture. This enables the integration of CESs of different organizations within one CSG. As an application example, we provided a short overview of the reference architecture for adaptable and flexible factories, detailed by a CES implementing an operator assistance system. The technical reference architecture for this CES shows the reuse potential for various operator assistance systems and provides a promising basis for future systems.

In order to consider non-functional requirements in the system architecture, we also introduced checkable safety case models. These checkable safety cases support maintenance of the validity of safety case models and keep them consistent with system architecture. This method may be used for the construction of the safety argumentation system architectures based on reference architectures.

In addition to the methods presented, we also developed prototypical tools which support and facilitate the application of the methods. The methods and reference architectures presented in this chapter have been applied successfully but should nevertheless be applied to other CESs and their CSGs to prove their benefits. Future research may extend them beyond their current scope, for example, by involving artificial intelligence as design support as well as considering artificially intelligent CESs and CSGs in particular.

#### **3.6 Literature**

Geneva, s.l., New York, http://ieeexplore.ieee.org/servlet/opac?punumber= 6129465; accessed on 04/04/2020.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Alexander Hayward, Helmut Schmidt University Hamburg Marian Daun, University of Duisburg-Essen Ana Petrovska, Technical University of Munich Wolfgang Böhm, Technical University of Munich Lisa Krajinski, University of Duisburg-Essen Alexander Fay, Helmut Schmidt University Hamburg

## Function Modeling for Collaborative Embedded Systems

*The evolution from traditional embedded systems to dynamically interacting, collaborative embedded systems increases the complexity and the number of requirements involved in the model-based development process. In this chapter, we present the new aspects that need to be considered when modeling functions for collaborative embedded systems and collaborative system groups, such as the relationship between functions of a single system and functions resulting from the interplay of multiple systems. These different aspects are represented by a formal, domain-independent metamodel. To aid understanding, we also apply the metamodel to two different use cases.*

#### **4.1 Introduction**

In modern development methodologies for complex systems, the modeling of functions represents a historically grown and proven way of dealing with large quantities of requirements that need to be taken into account. A function can be used to describe the purpose of a system at different levels of detail.

The SPES2020 and SPES\_XT projects (cf. [Pohl et al. 2012, Pohl et al. 2016]) have already developed a comprehensive set of sciencebased methods for modeling and analyzing functions of embedded systems, with a special focus on consistency and semantic coherence as part of a comprehensive methodological framework. The methods are based on the assumption that the embedded systems under development are to be integrated into a static context that is well known at the time of development. *The SPES projects*

*Goal fulfillment via collaboration*

*CES and CSG*

*Outline*

The additional assumption considered in CrESt—that individual systems no longer achieve the goals1 associated with them alone, but rather by collaboration with other systems—results in a range of new challenges for which the existing SPES modeling framework is no longer sufficient and needs to be extended.

A collaborative embedded system (CES), collaborating with other CESs that may be instances of different system types, should be able to achieve goals that 1) the CES could not achieve alone, or 2) could be achieved more easily or better by combining their functions with other CESs. For collaboration, the participating CESs form a common group, referred to as a collaborative system group (CSG). Since a CSG constitutes itself dynamically at runtime and its members, goals, and functions can change, methods for mastering the complexity are particularly necessary for modeling functions at CSG level.

In this chapter, we describe the new aspects that have to be considered when modeling functions for both CESs as well as the resulting CSG. To describe these aspects systematically, we use a metamodel. With regard to the derivation of this metamodel, Section 4.2 describes the requirements and aspects on which it is based. In Section 4.3, we provide further background information. We then present the metamodel on a domain-independent level in Section 4.4 and evaluate it in Section 4.5. To enable a better understanding of the metamodel, we apply it to two use cases in Section 4.6, and this is

1 See Chapter 2 for a detailed discussion

followed by related work in Section 4.7 and the conclusion in Section 4.8.

#### **4.2 Methodological Approach**

Model-based continuous function-centered engineering processes are already established in engineering practice [Daun et al. 2019a]. To support function-centered development, this chapter proposes a function metamodel. In order to achieve the goal of defining a uniform modeling methodology for functions, we have applied the following research methodology. To ensure applicability to a variety of domains and in various contexts, first, we have gathered requirements from academia and industry, using common requirements elicitation techniques such as interviews, workshops, and in-depth discussions. In addition, we have investigated engineering methods of different domains to foster function-centered engineering. As a result, we have derived a set of seven high-level requirements. For details of the requirements elicitation phase and the results, please refer to [Ludewig et al. 2018]. The following is a brief outline of the major requirements:

#### **Requirements 4-1***: Requirements for the function metamodel*

*Deriving requirements*

*Metamodel development*

We subsequently developed a metamodel iteratively to satisfy these requirements. We conducted workshops with the stakeholders to negotiate and re-iterate the metamodel as long as necessary to achieve a final, agreed version that fits all purposes for functional modeling and analysis of CESs.

The following is an example of the analysis of the individual methods investigated and the resulting rationale for the relevance of the method for the function metamodel. For demonstration purposes, we use a method for modeling the goals of CESs and CSGs.

**Example 4-2**: Functional aspects of the goal modeling method

*Method name:* GoalBasedSystemGroupEngineering

*Metamodel extension required:* Consider the relationship between goals and functions.

*Reason:* This method focusses on the definition of goals for the individual CESs as well as for the CSG. In the relationship between the CSG goals and the CES goals, it must be ensured that every CSG goal can be operationalized. Therefore, goals are refined into tasks, which represent abstract definitions of functions to be implemented.

#### **4.3 Background**

Our work builds on results from the SPES projects that provide a framework that enables seamless model-based engineering of embedded systems (cf. [Pohl et al. 2016]). The SPES modeling framework includes a *functional viewpoint* for specifying the system's functionality. The system's functionality is elicited from the requirements in a preceding requirements viewpoint. Our metamodel builds on this background work.

To a large extent, the SPES modeling framework is based on a formal theory called FOCUS, which provides models and formalisms for specifications and the development of distributed interactive and dynamic systems. FOCUS establishes a formal semantics that serves as a common ground for also giving means to functional behavior. In FOCUS (cf. [Broy and Stølen 2012], and [Broy 2014]), a system's interface is determined by the system's boundary. The *syntactic interface* describes the set of input and output channels and the message types that these channels transport across the system's boundary. The system's functionality is described by the *interface behavior,* which can be observed at the system's boundary and which is defined by the history of streams of messages across the input and output channels. The histories of the streams of messages across the input and output channels capture the system's interface behavior. Accordingly, the interface behavior models system functionality that can be observed.

#### **4.4 Metamodel for Functions of CESs and CSGs**

The metamodel for functions is given in Figure 4-3, which shows the aspects to be considered when modeling functions of CESs and CSGs. Based on the requirements, we have identified five major aspects that need to be considered when modeling functions for CESs and CSGs. These aspects are detailed in the subsections below:

 First, a differentiation between individual collaborating systems, not collaborating systems, and collaborative system groups is necessary. The CESs can partake in a CSG to fulfill their purposes as well as to contribute to the goals of the CSG. Whether a function belongs to either a CES or the CSG influences whether that function exists on its own or only in the collaborative interplay.

*SPES modeling framework*

*FOCUS theory*

*Five major aspects*

#### **4.4.1 Systems, CESs, and CSGs**

In this section, we introduce the relationship between a system and the collaboration of systems. Therefore, we start—as in traditional system analysis—by separating a *system* and its c*ontext*. For a system, we must distinguish whether it is a *not collaborating system*, a *collaborating system,* or a *CSG*, always viewed at a certain point in time.

A not collaborating system does not collaborate with other systems in a given CSG at a current time *t*. We can distinguish between *CESs* and *non-CESs*. While a non-CES cannot collaborate in a CSG at any time2, a CES can become a collaborating system for a CSG at a later point in time during the runtime of the system. A collaborating system is part of a CSG, which consists of multiple collaborating systems. Within a CSG, the CESs work together, provide their functions to each other, and share information to promote common CSG goals.

*Collaborating and not collaborating systems*

*Belonging to a certain CSG depends on time*

2 Note: CESs and non-CESs are always related to a specific type of CSG: a system can be collaborating with respect to a given type of CSG and a non-CES for another type of CSG.

*Fig. 4-3: Metamodel for functions of CESs and CSGs [Hayward et al. 2020]*

Every system (i.e., each CES, each CSG, each non-CES) has a *functional architecture* that contains all the functions of the system and describes how the functions interact with each other to achieve *goals*. This means that each individual CES consists of a functional architecture (cf. [Pohl et al. 2016]) which is therefore part of the larger functional architecture of the CSG. *Functional architecture*

#### **4.4.2 Functions**

Systems can be described on different levels of detail by their *functions* [VDI 2221]. Functions describe the behavior of a system through the interrelation between input and output variables [VDI 2222]. A function has a *syntactic interface*, through which it can take up information, material, or energy, transform it and output it again. Depending on the domain, the understanding of the term function can vary slightly in detail but this definition is valid at this general level [Eisenbart et al. 2012]. *Functions have interfaces*

*Functional decomposition*

In the classical design methodology according to [Pahl et al. 2013] as well as in today's model-based system development [Vogelsang 2015], [Meissner et al. 2014], functions are derived from requirements lists and models during an early design phase to capture the required functionality of the CES. Since specific solution principles can be derived only to a very limited extent based on these abstract functions, the functions are further decomposed into sub-functions, which can also be further subdivided, thus forming a hierarchy. These sub-functions again have interfaces through which they are connected. The functional hierarchy is called *functional architecture*. The functions and the resulting functional architecture can be used to describe what a system should be able to do. Additionally, the *interface behavior* can be used to describe which states, state transitions, and functional dependencies functions have [Eisenbart et. al. 2012].

*Functions and collaboration*

A CES no longer performs certain functions alone; it performs them in collaboration with other CESs. For this purpose, the CESs form a CSG and thereby provide their functions (*CES function*) to each other to achieve a common goal. The CSG can be considered as a system on its own again with components and functions (*CSG function*). These functions of the CSG are realized by CES functions and result from the interplay between the collaborating systems. While the functions of individual CESs can be modeled and realized during design time, the functions of the CSG are only constituted through collaboration between several CESs at runtime. By modeling CSG functions, we can indicate the specific contributions involved that CESs have to provide to achieve common goals of the CSG.

In addition to these two specializations of the function concept, the metamodel further distinguishes between *system function* and *collaboration function*. A system function contains the individual contribution of a CES within the collaboration. In a broader sense, a system function also includes other internal functions of the CES that contribute, albeit indirectly, to the fulfillment of goals. Collaboration functions, on the other hand, comprise a set of functions that are assumed to be available in all CESs participating in the CSG to enable collaboration in general and independently of the specific form and goal of the CSG. These collaboration functions include functions for the perception of and communication with other CESs, the negotiation of goals, the comparison of required and existing functions, or the adaptation of the CESs' behavior to meet the conditions of the CSG.

#### **4.4.3 Goal Contribution and Fulfillment**

Systems have *goals* associated with them. A goal is thus defined as a condition or situation the system wants to achieve or a behavior the system wants to exhibit. This holds for an individual CES as well as for a CSG. As mentioned in the previous sections, the fulfillment of these goals is always realized through functions and their implementation with the help of algorithms. This explicit manifestation of the stakeholder goals enables systems to fulfill the goals planned at the time of development during operation. We have to consider several situations according to system goals. *Goals*

The goals of the CESs concerned may differ from each other and from the goals of the CSGand may even be conflicting goals. In the case of (partly) different or contradictory goals, and in order to form a functioning CSG, the following must be negotiated: different goals between CESs collaborating in the CSG, differences between CES and CSG goals, and the way each CES contributes to the achievement of the CSG goals. Finally, the individual goals must be adopted in order to reach a consistent goal system within the CSG and its collaborating systems. As a consequence, it must be possible for the CESs to change their goals according to the results of the negotiations. In this sense, goals are considered dynamic at runtime. *Negotiating goals*

We differentiate between goals that will never be changed (*hard goals*) and goals that may be changed (s*oft goals*)in order for a CES to *Hard goals and soft goals*

*System function and collaboration function* actively contribute to the CSG goal system3 in a consistent manner. To this end, we have extended the function metamodel from SPES to match these additional requirements.

#### **4.4.4 Roles**

*Roles enable assignment of responsibilities*

Another concept that supports modeling and implementation of CSGs is that of *roles*. Within a CSG, different functions are needed to achieve the CSG goals. Roles can be used to define, within the CSG, which collaborating system is responsible for which CES functions and thus for which goals. CESs assume roles when they join the CSG. A single CES can potentially assume one or more roles within a CSGat the same time. The roles allow the definition of the necessary CES functions and thus the necessary behavior of the individual collaborating systems [Weiß et al. 2019, Regnat et al. 2019].

*Potential roles and current role*

A CES that has assumed a certain role within the CSG (*current role*) is responsible for the role-related functions. If a CES leaves a CSG (e.g., intentionally or due to an error), but the functions associated with its role must still be provided, it may be necessary for another CES, which has the necessary functions, to change its current role. This *role change* is only possible if the functions of this subsequent CES allow (*potential role*), it to assume the role from the leaving CES. These processes are only possible if the CESs involved in the CSG have a common understanding of the roles to be assumed.

#### **4.4.5 Context and Adaptivity**

A system is separated from its context and other systems by its *system boundary.* The system boundary defines whether an object belongs to the system or is outside of it. However, because of the dynamicity of the CSG, the boundary, the behavior, and the structure of the CSG may change over time. Consequently, we had to extend the metamodel to cope with such situations — namely, a potential CES that is outside the CSG at a given point in time may enter the CSG and therefore become part of the CSG structure (i.e., will be inside the CSG boundary). *System boundary*

*Context*

The *context* of the system describes the environmental surrounding that is not part of the system. The surrounding includes

3 Note: The terms hard goal and soft goal are used differently here as compared to goal modeling literature: hard goals are not subject to negotiation and are in a sense "static," while soft goals may be dynamically negotiated and changed in order to cooperate in a CSG.

persons, groups, organizations, processes, events, documents, functions of other systems, etc. In other words, the context is a perceivable part of the environment that consists of all the objects relevant to the system. Context is everything that is relevant to a system but remains external to its range of action [Lalanda et al. 2013]. Separating the system and its context means distinguishing between changeable and unchangeable variables [Pohl 2010]. Consequently, the context consists of all objects relevant to the system but outside the system's boundary.

Modern systems, such as CESs and CSGs, operate in a changing, uncertain, and dynamic context. In addition to the dynamicity of the context in which the systems operate, the structure of the system itself is also dynamic. Consequently, as briefly explained earlier in this section and in Section 4.4.1, the structure and the behavior of the system fluctuate over time — namely, a CES that is not collaborating at time *x* might become a collaborating system at a definite time *t + x* in the future by joining a specific CSG; and vice versa, a collaborating system of a CSG might, over time, leave the group. This directly impacts and changes the boundary of a system, which is no longer static, changes at runtime, and goes beyond what was defined during the system's design.

Consequently, the systems must be able to adapt in order to deal with the dynamicity and the runtime changes that might originate externally from the context in which the system operates, as well as internally from the system itself. We refer to these uncertainties and changes that trigger the adaptivity as *trigger events*. What we distinguish as internal or external events depends specifically on whether the system under consideration is a CES or a CSG. From the point of view of an entire CSG, internal trigger events could refer to, for example, the changes in CESs that collaborate, as role changes. In contrast, an external trigger event could be a CES from the context requesting to join and share its functionality with the CSG. However, from the view of an individual CES, the changing of a role, which is an internal trigger from the perspective of the CSG, can be considered an external trigger for the CES. In contrast, an example of internal triggers for the CESs are sensor uncertainties, such as sensor ambiguity, sensor imprecision, or even complete sensor failure, which could potentially lead the complete CES to a non-deterministic or faulty behavior.

In a nutshell, the general idea behind adaptivity is the ability to change the system's observable behavior, structure, and realization [Broy 2017], [Krupitzer et al. 2015], [Giese et al 2013] as a response

*Context and system boundaries change*

*Trigger events*

*Adaptivity*

to the internal and external events in order for the systems to continue meeting their functional specifications while preserving the performance (or another quality objective) — despite all the changes that the system may encounter during runtime [Petrovska and Pretschner 2019].

The adaptivity is enabled by the *adaptation logic*, which is a necessary precondition for a system to adapt to these changing situations. If the adaptation is triggered manually by an external user or administrator (a human assumes the role of an adaptation logic), then this is referred to as a system reconfiguration. In contrast, if the adaptation is triggered and executed by the system itself, in an automated manner, without any user interaction, then we call it selfadaptation [Petrovska et al. 2020]. Specifically, in our metamodel, we consider the adaptation logic to be a collaboration function which adapts the functions and the behavior of the CESs and the CSG through the collaboration of the systems. *Adaptation logic*

#### **4.5 Evaluation of the Metamodel**

In this section, we will briefly outline how the proposed function metamodel fulfills the requirements from Section 4.2. Further evaluation is subsequently given in Section 4.6 by showing the applicability of the proposed function metamodel.

#### **4.5.1 Abstraction**

#### **Requirements 4-4***: Req.1*

It must be possible to model functions on different abstraction layers. Composition and decomposition of functions must consider the relationship between single functions of CESs and overall functions on the CSG layer. On the highest layer of abstraction, a function can be understood as the emerging result of individual contributing functions. On the lowest abstraction layer, it must be possible to model an atomic function and its contribution to the overall function.

This requirement is fulfilled because a *function* is composed of other functions, thereby allowing the description of functionality at different levels of granularity. Furthermore, the separation between *CSG function* and *CES function* introduces another abstraction layer, as a function belongs either primarily to the overall CSG or to an individual CES. However, in both cases, the functions must be implemented in a CES, as the CSG relies on the CESs for any kind of resource. In addition, the distinction between *collaboration function* and *system function* also indicates different levels of granularity to describe functional properties.

#### **4.5.2 Relationships between Functions**

#### **Requirements 4-5***: Req.2*

It must be possible to model which overall function of a CSG an individual function of a CES can contribute to and how it can do so. For this purpose, the modeling process must consider whether different inputs and outputs of functions can be connected with those of other functions with regard to compatibility.

The aforementioned differentiation between *CSG function* and *CES function* allows us to define which CSG function *is realized by* which CES functions, and which CES function *realizes* which CSG functions.

#### **4.5.3 Openness and Dynamicity**

#### **Requirements 4-6***: Req.3*

Due to characteristics of openness and dynamicity, functions—as well as their connections to each other—may vary or change over time. These possible changes in individual functions may affect the overall function. Therefore, the possible inputs and outputs of functions—on different abstraction layers—that vary over time must be considered in the modeling process.

To address this requirement, the *adaptation logic* reacts to t*rigger events*in the *context* and *adapts*the *behavior* of a *function*. A change in an individual function also affects other functions of the CES or the CSG (see Sections 4.5.1 and 4.5.2). In particular, the composition of the *functional architecture* of any kind of *system* may be changed.

#### **4.5.4 Goal Contributions**

#### **Requirements 4-7***: Req.4*

Functions transform input into output to achieve a goal or meet a requirement. It must be possible to model the relationship between a goal (or a requirement) and its possible solution provided by a function. This modeling must consider priorities of goals and functions as well as conflicts between them. This modeling must also include dependencies between different functions.

A *goal* is defined as either a *hard goal* or a *soft goal*; each can be decomposed and be related to each other. Each *goal is implemented by* at least one *system function*, while any *function* can contribute to any goal. In addition, a *collaboration function* may *change* a *soft goal*.

#### **4.5.5 Relationships Between Functions and Systems**

#### **Requirements 4-8***: Req.5*

In case of a failure or of an error in individual functions, compensation strategies are necessary. Possible functional errors or failures must be considered in modeling to make them detectable. Therefore, relationships between the function model and other system models must be considered.

As mentioned earlier, *functions* and *systems* can be directly related by means of the *functional architecture*. Furthermore, the metamodel differentiates between the *CSG* and *CSG functions***,** and between *CESs* and *CES functions*.

#### **4.5.6 Input/Output Compatibility**

#### **Requirements 4-9***: Req.6*

Since different CSG functions are realized by different systems, potentially from different manufacturers, modeling approaches must ensure that inputs and outputs of different functions are compatible and suitable/consistent with each other.

Each *function* is defined by its *behavior* and its *interface*. This allows us to check the compatibility of functions. Furthermore, as outlined above, sophisticated relationships between functions, systems, CES functions, and CSG functions can be defined.

#### **4.5.7 Runtime Restructuring**

#### **Requirements 4-10***: Req.7*

CESs must provide the functionality to allow the CSG to be restructured at runtime. This leads to functions being related to different states. These states must represent, for example, when a function is accessible and when the transformation from input to output is not available.

The *adaptation logic* allows restructuring functions and functional architectures by *adapting* the *behavior* of individual functions (see Req.3). This leads to different states of a function being associated with different situations and compositions of the CSG. Furthermore, the concept of *roles* allows restructuring of the CSG by means of the assignment of roles involved. Therefore, individual CESs conduct *role changes*, which influence the function and thereby again restructure the overall functional architecture.

#### **4.6 Application of the Metamodel**

In this section, we demonstrate the applicability of the metamodel using examples from the two use cases of the adaptable and flexible factory and autonomous transport robots.

#### **4.6.1 Example from the Adaptable and Flexible Factory**

For the adaptable and flexible factory, let us consider the scenario of order-driven production. In this scenario, there are several heterogeneous modules within a factory. These modules are equipped with different functions and can contribute to the production of products. Exemplary functions are drilling, milling, or even turning of materials. In addition, assembly operations can be used to assemble different workpieces or to execute optical quality checks. Depending on the product to be manufactured for a customer, different functions, and thus contributions from different modules are required. Those modules that can contribute to the production form a CSG in which they provide their functions to each other in order to achieve the overall goal of fulfilling the production order. At the end of the production, the modules leave the CSG again.

Both centralized and decentralized coordination paradigms are conceivable for this CSG. In the case of centralized coordination, there is a single module that, as coordinator, decides after receiving a *Centralized and decentralized coordination*

production order which module is supposed to contribute to the production with which functions. In the case of decentralized coordination, the modules autonomously negotiate their possible contributions to the fulfillment of the order. Other mixed forms of centralized and decentralized coordination are also possible.

Regardless of the process of forming the CSG, the modules can be considered as CESs in accordance with the metamodel before the production starts and thus before the CSG is formed. By forming a CSG, these CESs become collaborating systems and, depending on their functional properties, assume one (or even several) roles in the CSG. Roles to be filled in the factory are, for example, material processing, assembly, transport, quality inspection and, in the case of centralized coordination, the coordinator. The required product can only be manufactured once all the roles required for an order have been assigned to the modules forming the CSG.

*Modules assume roles*

A module can only assume a role if it has the necessary functions. When all necessary roles have been assigned to modules, the CSG functions that are required to fulfill the CSG goals can be executed. An exemplary CSG function in the factory is the manufacturing of the product. The CSG function for manufacturing the product can only be executed, and thus the goal of fulfilling the customer order achieved, through the individual CES functions of the modules. Further exemplary CSG functions are the definition of the production sequence and the calculation of the production time. These CSG functions can also only be realized by aggregating the CES functions of the modules.

*Separation between system function and collaboration function*

The metamodel also shows a separation between system function and collaboration function. The system function represents the individual contribution of a CES to a CSG. A system function of a factory module can be drilling, milling, transport, or assembly, for example.

The collaboration functions enable the modules to communicate with each other, to exchange information about production orders, and to coordinate their contributions in the CSG. To coordinate the contribution of a module, the requirements of the products to be manufactured resulting from the orders must be compared with the available functions of the modules. In other words, a check is required to determine whether the functions of the modules are suitable to contribute to the production of the order. Such matching is also part of the collaboration functions.

In a centrally organized factory, the task of matching the requirements of the order with available functions is the responsibility of the coordinator. In this scenario, each module that should be involved in possible production orders must inform the coordinator of its available system functions and provide appropriate descriptions of the scope of these functions.

In a decentralized factory, where the modules coordinate with each other without a central coordinator, each module must be able to check whether it can contribute to the production and must be able to communicate the result of this check to the other modules. The other modules must be able to understand this contribution and compare it with their contributions. This is the prerequisite for determining whether the contributions delivered in total (the resulting CSG functions) are sufficient to produce the product.

Receiving a new order within the factory can be seen as a trigger event from the context, which means that the modules have to adapt their behavior. The execution of this adaptation is enabled by the adaptation logic in the metamodel. A single module can adapt its behavior by using the adaptation logic. Such an adaptation can, for example, be that a module changes its current configuration and thus its executable functions. Depending on the specific module, this reconfiguration can be done automatically by the module itself or partially automated with the support of a worker in the factory.

#### **4.6.2 Modeling of Goals for Transport Robots**

Another example which helps to improve the understanding of the elements of the metamodel is based on the use case of transport robots. This example looks at several transport robots (i.e., CESs) within a factory, with each robot being responsible for transporting different materials (i.e., an overall CSG). In order to receive different materials as input for various products, the individual transport robots connect to modules and conveyor belts, which allows the transport robots to take part in multiple production processes at once. The main purpose (i.e., the system goals) of the transport robots consists of executing the production logistics and ensuring punctual delivery and pick-up of materials between production process sites, for which the transport robots provide several functions.

In order to optimize the transport of goods within the factory from a logistical point of view, individual transport robots must negotiate possible orders and distribute them jointly. To enable this negotiation and to coordinate further behavior, the transport robots must

*The coordinator matches requirements and functions*

*Self-check contribution possibilities*

*Autonomous transport robots operate in a factory*

*Negotiate orders and coordinate behavior*

collaborate. Therefore, several collaborative transport robots (CTR) form a collaborative transport robot fleet (CTRF). In the context of the metamodel, individual CTRs can be considered as CESs and the CTFR as the CSG.

By forming a CTRF, a CTR starts communicating to share information within the CTRF. This allows the CTRF to manage the operations of the CTRs. While a non-collaborative robot would typically optimize its own routes and transportations, the CTRF allows optimized utilization over all the CTRs. For more information on the close interaction between CTRs and the CTRF, refer to [Brings et al. 2019]. *Forming a collaborative transport robot fleet*

> In order to further illustrate the different goals of the CTRs and the CTRF, some of them are shown as an example in Figure 4-11. This figure models relationships between various goals and related tasks (i.e., specific functions to be implemented) and dependencies between the CTRs and a CTRF (i.e., the relationship between the functions of the CESs and the functions of the CSG). The modeling was performed using an extension of the goal-oriented requirement language (GRL) (cf. [Daun et al. 2019b], [Brings et al. 2020]). The goals that CTRs and CTRFs pursue are represented by curved boxes and they can be fulfilled by executing all connecting tasks, which are represented by hexagonal boxes.

*Fig. 4-11: Goal model collaborative transport robot fleet*

*Goals of transport robots*  Figure 4-11 shows an excerpt of the goal model for the CTRF. When applying GRL, these tasks can be divided into further tasks to allow a more detailed specification. In terms of the metamodel, these tasks can be considered as functions. The individual tasks of the CTR presented here correspond to system functions in the metamodel. The functions for communication between the CTRs within the CTRF that are not shown here correspond to the collaboration functions.

The CTR pursues the goal to *optimize their current goods transportation*. The goal can be fulfilled when the CTR performs the different tasks shown. The CTRF pursues the goal to *optimize the goods transportation* of all participating CTRs. As these goals are interdependent, they are linked in the goal model by a bidirectional dependency (shown by the two *D*s on the connecting line). The task *optimal order acceptance decision* has some positive influence on the goal *optimal current resource usage* and is therefore displayed as a contribution arrow marked with the plus icon. While this refers mainly to the goal part of the metamodel, the relation to functions is made clear as the tasks define what functions need to be implemented to fulfill which goals.

#### **4.7 Related Work**

A comparative literature review was conducted by [Erden et al. 2008] to investigate different function modeling approaches and their similarities and differences. For example, functional model ontologies [Chandrasekaran and Josephson 2000], [Umeda et al. 1996], [Umeda et al. 1995], and [Yoshioka et al. 2004] aim at developing frameworks and languages for modeling the functionality of a system from the different viewpoints [Erden et al. 2008]. None of the proposed functional model ontologies consider the modeling of functions of complex CESs and CSGs, including the ramifications of the contexts in which these systems operate.

In [Chandrasekaran and Josephson 2000], the authors define two function viewpoints: "environment-centric viewpoint" and "devicecentric viewpoint." These viewpoints correspond to the collaboration and system functions proposed in our work respectively. In the first viewpoint, the function is related to the external effects that an object or a system has on its environment. In contrast, in the second viewpoint, functions are related to the internal features and parameters of the system. In our metamodel, to a certain extent we subsume both the viewpoints proposed in [Chandrasekaran and *GRL goal modeling*

*Differentiate between goals and tasks*

Josephson 2000]: 1) considering systems' functions that have effects on their environments, specifically in our case the context as the relevant part of the environment; 2) as well as the other systems involved in a collaboration, including their internal system parameters, states, and behaviors. Furthermore, [Gero 1990] has developed a function–behavior–structure model. In his model, he considered a function as an intermediate step between the behavior of the system and the user's goal.

A few frameworks have been proposed in literature to define a well-formed functional behavior of the system systematically. FOCUS (cf. [Broy and Stølen 2012], and [Broy 2014]), previously explained in Section 4.3, is an instance of such a formal framework that provides models and formalisms for specifications and development of distributed interactive and dynamic systems. In our contribution, according to FOCUS, we define the behavior of a function as a stream of messages across its input and output channels, which through its interfaces, take up information, material, or energy, and transform it before outputting it.

To the best of our knowledge, there has been no previous work on modeling functions for CESs from multi-dimensional aspects as proposed in our metamodel, including the dynamicity of the contexts of the system, role and goal modeling, and complex properties of these systems such as collaboration and adaptivity. The domainindependent metamodel proposed in this paper closes this gap.

#### **4.8 Conclusion**

The new challenges in the model-based development of embedded systems arising from collaboration make it necessary to adapt and extend existing modeling languages. In this chapter, we showed the aspects to be considered in the modeling of functions for CESs and CSGs in a metamodel. We then evaluated this metamodel and illustrated it using two examples from the use cases of the adaptable and flexible factory and autonomous transport robots. Based on the metamodel, specific extensions of modeling languages can be executed. Depending on domain-specific requirements, methods for the application of these extended modeling languages can be developed. The use case examples presented in this chapter will be used as a basis for further research.

#### **4.9 Literature**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Malin Gandor, OFFIS e.V. Nicolas Jäckel, FEV Europe GmbH Lorenz Käser, PikeTec GmbH Alexander Schlie, TU Braunschweig Ingo Stierand, OFFIS e.V. Axel Terfloth, itemis AG Steffen Toborg, PikeTec GmbH Louis Wachtmeister, RWTH Aachen University Anna Wißdorf, PikeTec GmbH

5

## Architectures for Dynamically Coupled Systems

*Dynamically coupled collaborative embedded systems operate in groups that form, change, and dissolve—often frequently—during their lifetime. Furthermore, the context in which collaborative systems operate is a dynamic one: systems in the context may appear, change their visible behavior, and disappear again. Ensuring safe operation of such collaborative systems is of key importance, while their dynamic nature poses challenges that do not occur in "classical" system design. This starts with the elicitation of the operational context against which the system will be designed—requiring capture of its dynamic nature—and affects all other design phases as well. Novel development methods are required, enabling engineers to deal with the challenges raised by dynamicity in a manageable way. This chapter presents methods that have been developed to support engineers in this task. The methods cover different viewpoints and abstraction levels of the development process, starting at the requirements viewpoint, and glance at the functional and technical design, as well as verification methods for the type of systems envisioned.*

#### **5.1 Introduction**

Dynamically coupled collaborative embedded systems (CESs) have to function safely in collaborative system groups (CSGs) that form, change, and dissolve during the lifetime of the CESs. The members of a vehicle platoon, for example, typically change frequently. CESs and the corresponding CSGs must therefore be able to deal with internal dynamics as well as those of the operational context. Here, dynamics refers to a specific notion of the term that subsumes the following aspects:

*Structure*: the elements of the CES or CSG under consideration and their interaction and dependencies. For example, elements of the context can become part of the system group and emerge from it by leaving the group.

*Function/behavior*: the services offered by the CES or CSG, and the dependencies to the services in its context.

The above-mentioned aspects are indeed closely related. Systems form system groups in order to achieve overarching goals (as defined in Chapter 2). Vehicles, for example, may join a platoon in order to optimize space usage and traffic flow, which changes the internal system structure of the platoon. A car that drives in a platoon requires functions—such as certain coordination functions—that are different to those needed to drive independently. The functional aspect also concerns the visible behavior of the context, which may also dynamically change. CESs and CSGs must be able to change their behavior accordingly. In some application domains, such as in the traffic example, this aspect subsumes the perceived "intention" of other traffic participants.

*Challenges addressed*

This chapter focusses on three challenges that arise from dynamicity for the development of collaborative embedded systems. First, systems are typically designed against a context that impacts the definition of requirements, for example, the temperature range in which the system must be able to work. Defining such specifications becomes a complex task for dynamically coupled systems. The complexity results not only from the context dynamics, with changing context structures and behavior, but also from the system itself, which may dynamically become part of a larger system (group) and leave it again. At the end of this progression, we are faced with the problem of designing systems against open contexts that cannot be fully anticipated at design time.

Dynamicity also raises the challenge of managing design complexity. Starting with the functional design, how can we develop a functional architecture that reflects the dynamicity of the system context as well as the structure and behavior of potential CSGs in which the CES is intended to work? Dynamicity calls for novel architectural patterns, enabling engineers to deal with this kind of complexity. Finally, such architectures should also support validation and verification tasks — for example, by enabling compositional reasoning. As the class of systems considered is that of safety-critical systems, corresponding analysis methods that support engineers in assessing important safety properties should be applicable in a scalable way.

This chapter presents methods that support engineers in designing dynamically coupled systems. The chapter is structured along the established design framework developed in the SPES projects [Pohl et al. 2012], [Pohl et al. 2016], as depicted in Figure 5- 1. Section 5.2 introduces a contract-based modelling method for the specification of the behavior of collaborative system groups, covering collaboration and interface aspects of CSGs and their expected behavior. Section 5.3 elaborates on the functional design. The approach enables the modelling of refined function architectures with operation modes that reflect the dynamicity of context and system. Section 5.4 presents a novel approach for incrementally constructing system architectures that can function in dynamic contexts. Finally, Section 5.5 presents an analysis method for the safety aspect of collaborative systems at the logical design level. The analysis method allows assessment of the impact on safety of failures of the communication medium. The methods are exemplified in the context of the "Vehicle Platooning" and "Autonomous Transportation Robots" uses cases (cf. Chapter 1).

*Fig. 5-1: Method overview*

*Chapter structure*

#### **5.2 Specification Modeling of the Behavior of Collaborative System Groups**

This chapter introduces a modelling approach for a formal contractbased specification of collaborative open systems.

CSGs are formed by the CESs involved. While a CSG as a whole exposes behavior, follows its goals, and interacts with the environment, its behavior is actually implemented by the systems that make up the CSG. This implies that each system must be implemented correctly with respect to the required group behavior. To decide whether a CES fulfills its obligations in a collaborative system group, we choose the concept of contracts. Contracts, as presented in this approach, define the rights and obligations of the individual collaborative systems based on protocol state machines for peer-topeer communication and formal scenario specifications of the group behavior. We want these contracts to be formal so that they can be used during CES operation but also already support automatic verification and simulation from a requirements perspective. This also implies that the modeling approach defines execution semantics so that specifications are executable.

*Collaboration specification metamodel*

The modelling approach covers different aspects that are relevant for specifying CSGs and the collaborative behavior of the CESs involved. The key concepts enable the scenario-based definition of collaboration structure and behavior. The metamodel in Figure 5-2 shows the main modelling concepts and their relationships, which are discussed in the following.

 These consist of textual, grammar-based languages and the graphical notation of  statecharts. The concrete tools used are YAKINDU statecharts and slang (system language) [Yakindu 2019], together with Franca IDL [Franca 2019]. Independently of this concrete choice of modeling languages and tools, the underlying concepts can also be adapted to standard system modeling languages, such as SysML, or by proprietary modeling approaches. The concepts are exemplified by the "Collaborative Adaptive Cruise Control (CACC)" car platooning use case (see Chapter 1).

The core approach for modeling collaboration within a CSG is based on formal specifications of scenarios. Scenarios constitute a natural way of specifying inter-object, or in our scope, inter-system behavior [Harel and Marelly 2003]. A CSG consists of a set of CESs and a set of relationships between these systems. This is specified by *collaboration scenario types*. The specification of such a type is illustrated by Figure 5-3. The example shows a platoon of three vehicles that form a CSG. Each CES involved is represented by a *system instance* of *system type PlatoonMember*. The direct communication relationships between the CESs are specified as *system connections*.

*Fig. 5-3: Example CSG structure*

For this type of collaboration scenario structure, a specification defines a set of behaviors. In contrast to other scenario specifications, such as use case descriptions or standard sequence charts, CSG specifications following this approach must be executable and thus require a high degree of formalism. To support this, two types of behavior models are used: *scenario operations* and *scenario statecharts*. A *scenario operation* is a simple procedural model for specifying dynamic processes within a CSG. Figure 5-4 gives an example of a CSG reconfiguration within the vehicle platoon that adds and integrates vehicles.

*Collaboration scenario specification*

```
@scenario op joinToSingleLead() {
 // first place a car into the scenario
 midVehicle.location = Coordinate.new(0, 0)
 midVehicle.velocity = 50
 assert notConnected( midVehicle.asFollower )
 // let the time proceed without creating a platoon
 time.proceed( minutes(5) )
 assert notConnected( midVehicle.asFollower )
 assert ( midVehicle.location.X == 50*60*5 )
 // place second car 200 meters in front of first car
 leadVehicle = PlatoonMember.new
 leadVehicle.location = Coordinate.new(midVehicle.location.X + 200, 0)
 leadVehicle.velocity = 40
 // as soon as the first car comes close to the second car
 // the platoon will be established
 time.proceedUntil( leadVehicle.location.X - midVehicle.location.X < 100 )
 assert ( midVehicle.asFollower == leadVehicle.asLeader )
 // after some time the platoon is cruising with the second car
 // velocity and constant distance.
 time.proceed( seconds(20) )
 assert (midVehicle.velocity == leadVehicle.velocity )
 assert (leadVehicle.location.X - midVehicle.location.X == 55 )
}
```
*Fig. 5-4: Reconfiguration example for platoon creation*

CSG reconfigurations apply changes to the coupling of CESs and are thus a way to capture the dynamics. Basically, all modifications such as adding, removing, connecting, and configuring CES instances can be described. Moreover, time is an explicit concept that can be used to control temporal aspects of the scenario. Finally, assertions check the proper execution of a scenario.

*Scenario statecharts*(introduced in [Marron et al. 2018]) adapt the concepts of scenario-based modeling (SBM). SBM is an approach that was first presented in the form of the graphical formalism of *life sequence charts (LSC)* [Damm and Harel 2001], [Harel and Marelly 2003]. Scenario-based statecharts extend the formalism of statecharts [Harel 1987] with SBM concepts. A *scenario statechart (SSC)* (see Figure 5-2) describes a scenario that covers a single behavioral aspect of the system group. Different scenario statecharts can be combined to obtain a behavioral description of the system group. The synchronization between these scenarios is based on events. In each state, an SSC can *request* or *block* events. All events that are *requested* by at least one scenario and are not *blocked* by at least one other scenario are called *enabled*. One or more enabled events can be selected and activated by a central event selection mechanism. All  scenarios that requested or waited for such an event will be notified and can proceed to the next scenario state.

*Fig. 5-5: Emergency stop and obstacle detection scenarios*

Figure 5-5 illustrates two example scenarios, each defined using a simple *scenario state chart*. The first specifies an emergency stop based on an obstacle. The second specifies the obstacle detection. Both refer to the platooning CSG but are not directly dependent on each other.

All properties of a CES that are relevant for the CSG specification are specified by a *system type*. As an example, *PlatoonMember* (Figure 5-6) reacts to incoming events and defines a set of system properties such as *velocity* and *frontDistance*. It also defines direct collaboration relationships to other vehicles using *system ports*. The system port *asLeader* provides a *CACControl* interface and *asFollower* requires it.

*CACControl* is a *system interface* that defines the elements that can be used in the interaction (or communication) between two systems. This concept adapts the well-known concepts of interface and protocol specifications, as the modeling approach assumes that communication protocols will form the basis for inter-CES communication.

*System type specification*

*System interface specification*

*Fig. 5-6: System type and system interface example*

*System interface contracts*

*System interfaces* define the elements that exist in the interface and are used by the interaction of CESs. The proven concept of protocol state machines (PSMs) [Franca 2019] allows specification of the dynamic behavior of *system interfaces* and can be used to ensure that the communication peers involved interact in the proper order.

*CSG contracts validation*

The behavioral part of a CSG *collaboration specification* is made up of all *scenario operations*, *scenario statecharts, and PSMs*. The scenario-based modeling approach is inherently incremental, which involves incremental specification, development, and integration of dynamically coupled CSGs and CESs. Additionally, all behavior models are inherently executable. All models described can be jointly executed within a simulation without any further behavioral model. This already serves as a basis for analysis methods that check the properties and consistency of the specification itself. Moreover, if the specification models of the CSG are executed together with the behavioral models of the CESs (e.g., using co-simulation), then conformity and consistency of the CESs with the CSG specification can be checked automatically. This allows a complete specification of the collaborative behavior of a CSG for all known aspects in a dynamic context, which is a precondition for the verification of the CES behavior within a CSG. Comparable to PSMs that define an interaction contract for single interaction relations, the collaboration scenarios defined by a CSG specification form the *collaboration contract* for all CESs involved.

#### **5.3 Modeling CES Functional Architectures**

The functional architecture of a CES establishes the link between the requirements viewpoint and the system design (cf. Figure 5-1). A functional architecture "integrates the system requirements in a structured, implementation independent system specification" [Pohl et al, 2012]. It should therefore reflect all aspects discussed in Section 5.2, including dynamicity. The basic idea of the modelling approach presented in this section is to explicate relevant system states in the functional architecture model in order to enable consistency to be established between the functional model and the dynamic aspects of the CSG specification — that is, the functional design of the individual CESs realizes the dynamic aspects specified in the requirements viewpoint.

*Functional architecture metamodel*

*Fig. 5-7: CrESt functional architecture metamodel — excerpt*

The approach conforms to the metamodel defined with the SPES modelling framework [Pohl et al. 2012], which has been extended in CrESt in order to reflect the need to design (dynamic) collaborative systems as well (cf. Chapter 4). An excerpt of this metamodel is depicted in Figure 5-7. It reveals the relationship between the concepts discussed in Section 5.2 (bold boxes) and the functional elements. The specified system behavior, for example, will be allocated to the *behavior* of a function. The collaborative behavior specification (cf. Figure 5-5) is allocated to *collaboration functions* of the CESs, while the collaboration structure and their relationships determine the way in which *CSG functions* are *realized* by *CES functions*. The figure also shows the relationship of the *functional architecture* to the *goals* a CES or CSG is aiming for.

#### *Functional architectures for dynamic systems*

Modelling functional architectures of dynamic systems requires paying particular attention to the relationships between system functions and goals. As introduced in the Chapter 2 collaboration functions determine the goals a CES (or CSG) is following at a particular point in time. The goals in turn are *implemented* by the system functions of the individual CESs. Dynamic changes in the CES (and CSG) are reflected by changes in the *collaboration functions*, and in turn in the *system functions*. The dynamic interplay between goals and functions requires changes to happen in an orchestrated way. The individual system functions must switch their internal behavior consistently in order to be able to contribute to the changing goals. The proposed modelling approach allows the specification of such functional dynamics in terms of state diagrams, where engineers can explicate the dynamicity of functional behavior and the interaction between functions to coordinate changes. The approach then enables analysis of whether dynamic changes actually happen in a consistent way with respect to the scenarios specified.

#### **5.3.1 Scenario**

*System scenario example*

The approach is exemplified by the "Autonomous Transport Robots" use case (cf. Chapter 1). Figure 5-8 shows a simple scenario with a single production machine and two transport robots, which represent the CSG being designed. Each robot is a CES in this CSG. The goal of the CSG is to transport goods between machines as well as storage locations, following some optimization objectives (cf. Chapter 9). Transport requests from the machines are distributed among the individual robots.

The scenario specification in Figure 5-8 is similar to the one introduced in Section 5.2 but applied to a different use case. The scenario consists of a simple sequence of snapshots that represent a particular state of the system and its context. Both robots initially do not perform transport tasks. This is indicated by a *wait* state assigned to the robots. In the second step of the scenario, the machine issues a *request* for a transport *task*, such as the delivery of a required resource, or the pickup of goods produced by the machine. This state is depicted on the right-hand side of the figure. The third step in the scenario specification would be that one of the robots (here *robot2*) takes over responsibility for the task.

This type of scenario typically also consists of a specification of the interaction between the individual objects, such as sequence charts defining messages that are communicated, causing a scenario to transition from one snapshot to another. In our scenario, this is exemplified by single events. In Figure 5-8, the events are written in boldface. For example, the scenario transitions from the first to the second snapshot as a result of the occurrence of a *newTask* event.

*Fig. 5-8: Autonomous transport robots use case — example scenario*

The scenario actually exhibits the dynamic nature in the context of the CSG "Transport Robots." Although a transport task is not a physical entity, it corresponds to a transported product as a physical object that appears in the context of the transport robots. Products and other relevant dynamic aspects, such as temporary roadblocks and the addition of robots to the fleet, have been omitted to keep the discussion simple.

#### **5.3.2 Modelling**

The modelling approach as depicted in Figure 5-9 is consistent with [Vogelsang 2015] and employs the concepts for a structured mapping of the collaboration specification to the functional architecture. The top part shows the functional architecture of a transport robot, consisting of the functions *Planning & Control*, *Bidding,* and *Dynamic Control*. The key element of the mapping is shown in the angled boxes. They represent the system states and object relations derived from the specification, which are relevant for the individual functions. The *Bidding* function realizes the collaboration among all robots by

negotiating which robot takes over a transport task, and therefore decides about the *hasToFulfill* relationship of a task. The *Dynamic Control* function is responsible for navigating the robot safely through the factory, and thus realizes states such as *wait* and *movesTowards*.

The bottom part of Figure 5-9 shows the realization of the functions in the logical architecture. It has been modelled in terms of a SysML Internal Block Diagram, which has been chosen as the implementation language. The *Planning & Control* function maintains the "global" state of the transport robot. Figure 5-9 also shows how the interactions between the individual functions are realized, modelled by events that are transmitted between the interfaces along the connections. For example, an incoming *newTask* event to the

*Fig. 5-9: Robot top-level functional architecture (top), and its realization in the logical viewpoint*

*Planning & Control* function causes a request to the *Bidding* function, which will eventually come back with the result of the respective bidding process. This in turn causes the *Planning & Control* function to request state changes of the *Dynamic Control* function in order to perform the required operations.

*Fig. 5-10: Planning & control — state-machine diagram*

Typically, a large number of scenarios are specified for reasonably complex systems and contexts. Moreover, the individual functions will be further decomposed along the modelling process. Supporting engineers in ensuring that the architecture designed adheres to the requirements specified in the scenarios is of crucial importance in order to avoid design errors. Figure 5-10 shows how this can be achieved with the proposed modelling approach by explicating internal state changes of the individual functions in terms of SysML state machine diagrams. While state machines are defined mainly to model behavior, they also provide a natural way to specify dynamicity in functional architectures and the interaction between functions in order to coordinate state changes throughout the CES architecture.

However, relating individual states with the system states specified in the scenarios, would require a great deal of effort and becomes highly complex— for example, if only combinations of states of different functions match particular scenario states. A more convenient and suitable way is to identify interaction points, or more precisely, transitions, in the state machines, with corresponding state changes in the scenarios. This is shown in Figure 5-10. The angled boxes denote the events (and in turn state transitions) that are associated with establishing object relationships in the scenario specification.

As SysML state machines provide a large number of features, a small subset of them have been selected and some design rules have been defined to make the approach effectively applicable. More details about this can be found in [CrESt 2019].

#### **5.3.3 Analysis**

*Consistency analysis*

The section concludes with a brief overview of an automated analysis that can be applied in order to check the consistency of the functional architecture modelled with a scenario specification. To this end, both the scenario specification and the functional architecture, including the state machine diagrams, are automatically translated into a target automaton model (in our case RTana2 [Stierand et al. 2016]). The translation has to identify state changes by events as explained above. In the current implementation, this is achieved by name matching. The analysis is basically a refinement check that fails if the architecture model cannot "follow" the scenario specification, that is, where either expected events do not occur (e.g., a *hasToFulfill* event of one robot), or events occur unexpectedly (*hasToFulfill* events from multiple robots). Note that consistency analysis has been developed in the context of all SPES projects, such as with the AutoFOCUS tool [Pohl et al. 2012, Section 5.5]. We now apply this important analysis step to dynamic systems.

#### **5.4 Extraction of Dynamic Architectures**

Reference architectures can be used to define common structures in software product lines for CES engineering. Therefore, they determine the static and dynamic compositions of the underlying software architecture. Reference architectures can either be defined from scratch or extracted from a set of system architectures for specific contexts expected for the CSG. Extraction enables identification of existing features through successively establishing a reference architecture by analyzing system architectures. The extraction process captures the commonalities and variations of the architectures analyzed. For that reason, the reference architecture forms the basis for the development of further products and can be successively extended by the extraction process.

The methods we present for extracting reference architectures from a set of architecture models is semi-automated. Logical system architectures for a static context are developed upfront and extrinsic matches (common parts in each architecture) with the current reference architecture are identified automatically in a second step. All components of static system architectures that do not match extrinsically in the reference architecture are automatically assigned to the reference architecture. To minimize the number of false assignments, this assignment is then reviewed by a domain engineer  manually. The remaining extrinsic matches are further analyzed to identify differences. For this purpose, fully automated variant and similarity analyses are performed during the extraction process.

We begin this section by introducing general principles of software product line engineering and continue with an explanation of how new domain artifacts can be derived from the bases of multiple application artifacts. As these techniques rely strongly on the establishment of reference architectures, this section concludes by introducing the Family Mining [Wille et al. 2014] approach, which provides mechanisms for establishing reference architectures based on a set of architectures that already exist.

#### **5.4.1 Methods**

To extract dynamic system architectures from existing system architectures, this section is structured as follows. First, we introduce reference architectures, which describe the common structures of product lines. Second, we use the concept of software product lines, for which we present a product-driven approach. Finally, we discuss the extraction with the Family Mining approach in the context of employed methods, that is, the Static Connectivity Matrix Analysis (SCMA) [Schlie et al. 2018] and the Reverse Signal Propagation Analysis (RSPA) [Schlie et al. 2017], which are both explained in detail below. Clone-and-own [Riva and Rosso 2003] is a straightforward reuse strategy that describes the copying and subsequent modification of an existing system to create a new system variant.

With regard to software architectures, this straightforward reuse strategy leads to a vast quantity of redundant and similar artifacts. Moreover, a later transition towards structured reuse, such as with software product lines, inevitably requires the comparison of all existing variants prior to the actual migration. The development of dynamic open systems from scratch adds a new level of complexity to the system as it involves designing new functionality at the same time. Thus, a step-by-step development based on a specific context of the CSG by reusing a common reference architecture is promising. In this process, the common parts of the system are reused in the reference architecture of the system, while new parts represent the dynamic part of the system.

SCMA [Schlie et al. 2018], [Schlie et al. 2019] is a procedure that enables the evaluation of multiple MATLAB/Simulink model variants simultaneously. The transformation of models into a matrix form reduces the complexity of the models and allows large-scale systems  *Static Connectivity Matrix Analysis (SCMA)* to be compared with each other in their entirety. Moreover, SCMA identifies all similar structures between the system portfolio under comparison, even with model parts being completely relocated during clone-and-own.

During development, model-based systems are subject to frequent modifications. Manual identification of all modifications performed is typically not feasible, especially for large-scale systems. However, precise identification and subsequent validation of the modifications is essential for the overall evolution. RSPA is a procedure that identifies and clusters variations within evolving MATLAB/Simulink models.

With each cluster representing a clearly delimitable—i.e., separate—variation point between models, model engineers can not only specifically focus on single variations, but by using their domain knowledge, they can relate and verify them.

One of the main challenges in the development of dynamic architectures is capturing changes in the system's context and subsequently adapting the system to adjust to these changes. Thus, the resulting architecture must allow a dynamic reconfiguration in response to a changing context of the CSG. To this end, dynamic software components of the architecture may only be relevant for a set of contexts, and therefore, multiple alternative implementations of a component may exist.

Software product line engineering (SPLE) deals with similar challenges. In SPLE, software components or software modules are flexibly configured to different application scenarios. Different binding times, that is, the times of selecting and deriving the concrete software variant of these modules are possible — for example, configuration time, compilation time, initialization time, or runtime. Dynamic open system architectures can be seen as software with a binding time at runtime. Consequently, development mechanisms of SPLE can be applied to the development of flexible system architectures.

#### **5.4.2 Software Product Line Engineering**

A software product line (SPL) enables software developers to tailor their software products to individual customer needs [Clements et al. 2001], [Apel et al. 2013]. To this end, an SPL captures the commonalities and variabilities of a given set of software systems and derives concrete software products by means of a variant deviation mechanism. This mechanism takes a collection of desired software

*Reverse Signal Propagation Analysis (RSPA)*

*Family Mining*

*Software product line engineering (SPLE)*

functionalities, called a *configuration*, as an input and automatically derives a software variant from the SPL.

As for reference architectures, there are extractive methods for SPLE as well as proactive approaches that aim to establish an SPL from scratch. Reactive SPLE [Apel et al. 2013] aims to combine the strengths of both approaches. The aim of this process is to handle the fact that products might be added to the SPL in later phases of the product life cycle, or that specific software variants are altered after their derivation, which often occurs in practical applications. To achieve this aim, the reactive SPLE as displayed in Figure 5-11 starts with an initial SPL, which consists only of a basic set of products that is created from scratch, and later uses extractive mechanisms to evolve the SPL and incorporate changes to the requirements and product variants — that is, that existing products may be altered, or new products may be included [Apel et al. 2013].

#### **5.4.3 Product-Driven Software Product Line Engineering**

Product-driven software product line engineering is a form of reactive SPLE that focuses on the step-by-step establishment and development of a software platform based on established artifacts considering new requirements arising from application engineering. Using an extractive approach, new domain artifacts can be derived from the basis of multiple application artifacts. The process for developing a new software component variant using the product-driven SPLE

*Fig. 5-11: Reactive product line engineering (based on [Pohl et al. 2005])*

*Fig. 5-12: Product-driven software product line engineering*

approach is illustrated in Figure 5-12 as an activity diagram (AD) and consists of the following steps:

semantic aspects of the extrinsic matches to identify commonalities and differences between the software components.

#### **5.4.4 Family Mining — A Method for Extracting Reference Architectures from Model Variants**

To extract variability relations between existing block-based model variants, such as MATLAB/Simulink models or SysML statecharts (cf. [Alalfi et al. 2014], [Font et al. 2015], [Martínez et al. 2014], [Nejati et al. 2007], [Rubin and Chechik 2012], [Rubin and Chechik 2013a], [Rubin and Chechik 2013b], [Ryssel et al. 2010], [Ryssel et al. 2012] ), the Family Mining approach was developed [Wille et al. 2014]. The approach provides a generic algorithm that is not only applicable to different block-based modelling languages, but also enables customization by providing user-adjustable metrics [Wille et al. 2016], [Wille et al. 2018]. *Coarse-grained analysis*

To present the workflow of this Family Mining approach, Figure 5- 13(a) depicts the steps required to compare input systems, locate the

*Fig. 5-13: Workflow of the custom-tailored Family Mining approach for identifying variability relationships between block-based model variants*

most similar elements to match them with one another, and to derive a 150% model starting from a set of imported input models.

*Fine-grained analysis*

Moreover, Figure 5-13(b)illustrates how the approach can be used to capture the systems' underlying architecture by assessing all input models (i.e., the entire portfolio) at once [Schlie et al. 2018]. Hence, the structural components (here MATLAB/Simulink *subsystems*) of the input systems, along with their hierarchical relationships, are assessed and related to derive the overall architecture of the input portfolio and to simultaneously capture redundant model parts (cf. *ACC* in Figure 5-13(b)). Subsequently, the workflow shown in Figure 5-13(a) can be applied in a fine-grained fashion to only those components warranting such analysis, for instance to locate variation points at a fine level of detail [Schlie et al. 2017] and to derive a final 150% model [Schlie et al. 2019]. Such a 150% model (cf. Figure 5- 13(c) for an excerpt) contains all possible model elements with annotations to indicate where variants' respective elements originated from and variation points between them. To extract such variability information and represent it in a centralized form, meaning the 150% model, the workflow evaluates block-based model variants in three sequentially processed phases (cf. compare, match, and merge in Figure 5-13(a)).

*Compare*

In the first phase, called the compare phase, the identification of model relationships is the primary goal of interest. For this purpose, the imported model instances are compared with each other. The workflow allows for variants to be compared at different levels of  granularity and using different techniques. First, systems can be compared iteratively, selecting a base model (e.g., the smallest model) and processing the remaining n-1 models iteratively, each further model variant then serving as a comparison model for the current comparison phase. In this phase, the structure of the block-based input models with their nodes (e.g., functional blocks for MATLAB/Simulink systems) and their directed edges (e.g., signals used to relay data between nodes) is exploited. To compare the nodes of the input model, the proposed workflow starts with the start nodes of the models (e.g., input blocks that introduce data) and traverses nodes following the direction of data flow and, at all times, compares nodes based on the user-adjustable similarity metric. This metric calculates a similarity value in the interval [0. .1], with 1.0 indicating 100% similarity. This similarity value is stored in a comparison element, along with the elements being compared and their possible relationship within analyzed models under comparison. Next, the traversal algorithm follows the outgoing edges of the node and compares them until no further compared nodes can be found. Another technique offered by the workflow, SCMA [Schlie et al. 2018], abstracts from the models' inherent graph structure and describes the models in a matrix form, representing only salient system information, as described below. With models being structured in a hierarchical fashion, with each hierarchical element denoted as a subsystem in MATLAB/Simulink, each subsystem is transformed into matrix form separately. As a result, the overall complexity of such model-based systems is reduced drastically, allowing for the comparison of multiple systems at once, rather than in an incremental fashion. This allows system parts that warrant a fine-grained analysis to be identified. Hence, such fine-grained analysis can be employed only when warranted, omitting unnecessary comparisons.

A more fine-grained comparison procedure, RSPA [Schlie et al. 2017], compares block-based systems by assessing changes between individual signals that always connect two blocks and grouping affected blocks into delimitable variation points. In contrast to SCMA, RSPA compares exactly two models, and can therefore be integrated within the iterative comparison of an entire system portfolio. Like SCMA, RSPA identifies areas within models where variations exist, allowing for a precise targeting of such parts in the context of the overall workflow.

In the second phase of the workflow, the matching phase, the elements that are the most similar are matched with one another and are assigned with their specific relationship (i.e., their variability),  *Match*

*Similarity*

based on their similarity value. Multiple possible matching partners may exist for a distinct element (e.g., a block from one model being compared with multiple blocks from a different model). Such ambiguities are identified and resolved during matching. Here, the matching algorithm analyzes the comparison elements from the "compare" phase and checks whether other comparison elements that comprise one of the contained model elements exist. In this case, the matching element with the highest similarity value is chosen. If both compared elements have the same similarity value, these comparison elements are sorted to the end of the list and the algorithm tries to solve the conflict by matching other comparison elements first. If the conflict remains, a *decision wizard* is called to identify the desired match by executing additional user-specified logic or by requesting direct feedback from the user.

In contrast, SCMA explicitly utilizes comparison results from multiple input models to determine similarities across system boundaries and across respective locations therein. Relating similar comparison elements from multiple models to one another, while exploiting the hierarchy of compared elements, allows information about the model portfolio being analyzed to be retrieved. Moreover, redundant or highly similar functionality, which may reside at different locations within systems, can be identified. Such redundancies can then be processed separately prior to the final phase, the transformation of compared artifacts and their relationships within a centralized form.

*Merge*

In the third and final phase, called the "merge" phase, the merge algorithm creates a 150% model to store the variability relationships identified. To this end, the algorithm extends a copy of the base model by merging all matched components into this model. Based on the similarity values from the "compare" phase, the algorithm determines the explicit variability by categorizing the elements into mandatory parts (i.e., common parts of all models), optional parts (i.e., common parts of some models), and alternative parts (i.e., mutually exclusive parts between models). During this process, all model elements that were not previously part of the base model are copied to the 150% model.

This 150% model generated enables domain experts to analyze the variability identified in detail. Moreover, it may serve as a basis for the comparison of the next remaining comparison model. The proposed algorithm thus iteratively compares and merges all input models into a single 150% model that stores the variability information for the model family analyzed.

#### **5.4.5 Summary**

In summary, SPLE enables software engineers to capture commonalities and variabilities of a given set of software systems and to derive concrete software products by means of a variant derivation mechanism during CES engineering. To combine the strengths of creating SPLEs from scratch with the advantages of extractive SPLE, the reactive product-driven SPLE approach describes a step-by-step establishment and development of a software platform based on established artifacts. The Family Mining approach starts with input models, which are first subject to a coarse-grained analysis, denoted SCMA. In the SCMA, similar parts that warrant further analysis are identified, while identical (meaning redundant) parts within models are eliminated. By omitting unnecessary comparisons, the Family Mining approach then directs subsequent analysis procedures to those similar parts. Specifically, we employ a fine-grained comparison metric to capture the variability of individual model elements at finegrain level (e.g., varying labels or different internal properties). Comparison results of the fine-grained analysis are combined with information from the coarse-grained analysis to derive one holistic 150% model.

#### **5.5 Functional Safety Analysis (Online)**

A common way to ensure the correct functional behavior of an existing system is systematic testing against requirements. This testing usually occurs with a model or setup of the system that is already running instead of an architectural model. Therefore, we call this testing online analysis with regard to functional safety. If the system under test (SUT) is a CSG, there are further safety-relevant requirements regarding the collaboration. These cannot be properly tested with just a single CES as the SUT.

As described in Section 5.2, the entire idea of collaboration between different CESs is highly dependent on communication. If the communication is faulty, no collaboration is possible. A single CES should still be able to react when faced with faulty communication. Therefore, the recognition of faulty communication is an important situation that must be tested.

For this purpose, we have developed a method to inject communication errors into a CSG as the SUT. This allows faulty communication to be simulated deterministically to test and verify various kinds of error-detection mechanisms.

For evaluation purposes, we implemented this method with AUTOSAR components as an example. The result is a prototypical test environment that connects multiple AUTOSAR components. This environment enables us to intercept the communication between components and manipulate the data exchanged.

#### **5.5.1 Functional Testing**

Software development for embedded systems typically starts with the specification of the desired behavior. Such specifications often contain expectations of output signals considering certain input signals. For example, "If the distance to the car in front falls below 100 m then the brake must be applied" could be a basic specification of an emergency brake system. The scenario statecharts introduced in Section 5.2 can also serve as a specification of the behavior. The software is implemented based on such specifications.

To test an implementation, the software must be stimulated with input signals and the output signals must be recorded. The device that stimulates the inputs and records the outputs is called the test driver. The tracking and evaluation of those signals against functional requirements is called functional testing. A schematic representation of this basic procedure for software testing can be seen in Figure 5-14.

*Fig. 5-14: Software simulation — schematic representation*

Test solutions connect a test driver with the CES or CSG to be tested to set the inputs and record the outputs.

*Fig. 5-15: Communication within a CSG*

Basic approaches for functional testing consider a single embedded system communicating with the environment but not connected to other systems. To test the software of a CES within a CSG, the communication with other systems must be considered. Communication with other systems basically adds new inputs and outputs to the test setup. If, for example, another CES in a collaborative adaptive cruise control sends some information about a traffic jam ahead, this information must be forwarded to the other participants.

Another consideration is to view an entire system group as a single system to be tested. In this case, the communication between several single systems must also be simulated and recorded, just like the communication of a single CES with the environment. Each individual CES communicates with the environment on its own and each CES communicates with other CESs. A schematic representation of this communication of an entire CSG can be seen in Figure 5-15. In our approach, we considered CSGs with a static configuration, which means changes in the reconfiguration such as the addition or removal of CESs are not considered here.

#### **5.5.2 Communication Errors**

The collaboration between several CESs adds new challenges to the testing process. An important aspect is to ensure that each individual system is capable of dealing with communication errors. Before we start discussing ways of simulating communication errors, let us introduce two kinds of errors.

In further references, these different kinds of errors will be called detected and undetected errors. If communication errors are detected by the system itself, these errors are called detected errors. In embedded software, detected errors can often be considered as another kind of an "exceptional" input signal. Information such as "communication error occurred" can be considered as "normal" information. Processing that information in a simulation environment is equal to using information like "distance to the car in front." Typical examples of detected errors are error flags, DTCs (diagnostic trouble codes), and similar data that explicitly signals some malfunction or

*Fig. 5-16: Communication flow with included test solution*

irregular system behavior. If the detected errors are considered to be a kind of input signal, they can obviously be tested by additionally stimulating those "error detected" flags and recording the behavior in the same way.

On the other hand, undetected communication errors are just the reception or the transmission of incorrect values. To simulate undetected errors during functional safety analysis, the test solution must replace or manipulate the values sent from one CES to another with the desired false values. Following this approach, fault detection mechanisms such as timeout detection of cyclic messages or plausibility checks of input signals can be tested in CSG testing. If the tested system is given incorrect inputs, the behavior of a plausibility check can be verified. By creating the possibility to modify the communication between several collaborative embedded systems, undetected faults can be injected. This approach is called fault injection. It is illustrated in Figure 5-16.

In this figure, instead of sending the information directly from CES 1 to CES 2, the information is sent to the test solution and then forwarded to CES 2. During the modeling of those tests, an additional flag to override certain signal values before forwarding them to CES 2 can be added as part of the test modeling. If this flag is set from the test case modelled, an additionally modeled faulty value can be transferred to CES 2 instead of the actual value from CES 1. The behavior of CES 2, having received the "faulty" value, can still be recorded and evaluated if it fits the specification.

#### **5.6 Conclusion**

The development of dynamically coupled collaborative systems poses new challenges for engineers. The methods presented in this chapter support CES engineers in tackling these challenges. They have been selected in order to cover the different design phases and to show that the challenges require continuous consideration of the various aspects along the design process, such as requirements elicitation (including the collaboration of individual CESs in a CSG), functional design that ensures consistency with these requirements, and logical architectures that enable the systems to handle dynamicity, as well as approaches for testing CSG designs.

Some important aspects have been omitted. For example, the design flow introduced in Figure 5-1 shows some "conceptual" flows, which would involve additional methods for the design of intermediate models and analysis results. The aspect of traceability, which would be needed to support engineers in continuously assessing those intermediate design models for adherence to the system requirements, is not discussed either.

#### **5.7 Literature**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Jan Christoph Wehrstedt, Siemens AG Jennifer Brings, University of Duisburg-Essen Birte Caesar, Helmut Schmidt University Hamburg Marian Daun, University of Duisburg-Essen Linda Feeken, OFFIS e.V Constantin Hildebrandt, Helmut Schmidt University Hamburg Wolfram Klein, Siemens AG Vincent Malik, Siemens AG Boris Wirtz, OFFIS e.V. Stefanie Wolf, Siemens AG

## 6

## Modeling and Analyzing Context-Sensitive Changes during Runtime

*For collaborative embedded systems, it is essential to consider not only the behavior of each system and the interaction between systems, but also the interaction of systems with their often dynamic and unknown context.*

*In this chapter, we present a solution approach based on process building blocks describing both the modelling approach as well as the model execution approach—for engineering and operation to achieve the goal of developing systems that deal with dynamics in their open context at runtime by re-using the models from the engineering phase.*

**6.1 Introduction and Motivation**

*CESs operate in open dynamic contexts*  Software-intensive embedded systems differ from classic systems in that they interact with their operational context through sensors and actuators [Daun et al. 2016]. The same holds for collaborative embedded systems (CESs) and collaborative (embedded) system groups (CSGs), as their behavior and functions are strongly influenced by changes in the systems' contexts. For example, dynamic traffic conditions—such as pedestrian behavior (which is very difficult to predict), construction work, or other unexpected traffic participants—are major challenges to be met by a platoon of autonomous cars. Similar challenges arise for adaptable and flexible factories in the case of producing individualized products or new variants of the product mix. If the system acts autonomously, a decision has to be taken very quickly on how to react to changes during runtime. This also concerns the operator who has to decide how to deal with the system due to changes.

*CESs must be able to cope with context changes during operation*

Therefore, methods for coping with these changes during operation must be developed, and this requires the development of suitable methods and models that can be used during operation. These methods must be developed and validated during the engineering phase, which requires the reuse or rather the migration of models from the engineering phase towards runtime.

#### **6.2 Solution Concept**

To achieve the goal of developing systems that can handle the dynamics of their open context and to reuse the models from engineering in order to deal with these changes during operation, we present a novel solution approach as described in Figure 6-1; the notation will be explained later in this section.

*Fig. 6-1: Process steps for developing models for CESs interacting with their context and their execution during operation*

*Modeling the system and the context*  Initially, we develop a modeling approach for both the system and the context: as ontologies are a suitable technology for enabling semantic interoperability, they allow the creation of information models that link machine-readable meaning to information, thus enabling CESs to mutually understand the shared information. This allows the system and context models to be reused for different applications and also guarantees a certain completeness of the information.

Based on that, we provide insights into a scenario analysis approach that identifies, depicts, and analyzes certain contextual situations based on a graphical modeling notation. In this approach, spatial/context constraints are captured as invariants, which change over time. We then present different approaches for model creation, using the example of modeling the capabilities of collaborative embedded systems. Subsequently, in Section 6-4, we describe how to develop decision methods based on these models and runtime information. This leads to the models generated being integrated into executable models that can be used for system analysis. We explain this general approach with different examples: a capabilities check of a system group to fulfill requirements given in a context situation and the seamless integration of simulation for validation of dynamic system behavior.

Some of the methods presented can be broken down into a set of sub-methods with certain interdependencies and specific types of artifacts (see Figure 6-2). To show the relationships between such sub-methods (e.g., how to combine them), to clearly assign them to the design phase or to the runtime of a CES/CSG, and to classify their degree of formalization and automation, we choose the following notation:

*Fig. 6-2: CrESt process building block (PBB) notation*

#### **6.3 Ontology and Modeling**

The development and operation of CESs that can cope with a frequently changing environment has become a major field of research. Of particular interest is a CES's ability to operate in open contexts, that is, situations where context objects (e.g., other CESs) *CESs operate in open contexts*

*CrESt process building block notation*

*Contributions*

enter or leave the CES's context at runtime [Schlingloff et al. 2016]. As CESs are usually embedded in a network of CESs (i.e., a CSG), an individual CES must be able to process and communicate complex information from/to changing communication partners during its life cycle in order to provide its functionality.

*Ontologies as a solution concept*

*Ontologies must be derived systematically*

This addresses the development of the models as well as the modeling approach itself. Ontologies are becoming the appropriate means for these systematic approaches. In the following section, we therefore address a modeling approach for the system and context to develop models that can cope with online decisions.

#### **6.3.1 Ontology Building**

Ontologies provide a suitable technology for formalizing different aspects of a CES and could potentially be the provider of data, information, and knowledge for different software functionalities [Sabou et al. 2019]. In the case of a CES in the manufacturing domain, an ontology can be used to formalize manufacturing-related capabilities (see Sections 6.3.2 and 6.4.2), features relevant for reconfiguration of a manufacturing system (see Section 6.3.3), or serve as input information for a simulation of the manufacturing system (see Section 6.4.1). The development of an ontology is a nontrivial task that requires high efforts from different stakeholders. Therefore, an efficient ontology building procedure is crucial in order to have a positive cost-benefit trade-off. The latter is the goal of the method described below, which is summarized by Figure 6-3.

*Ontologies define terminologies*

*A three-step approach to ontology building*

An ontology may take a variety of forms, but it will of necessity include a vocabulary of concepts and some specification of their meaning, including definitions and an indication of how concepts are interrelated. In general, the above-mentioned concepts and relationships (including attributes) form what is referred to as the terminology box (TBox), while the axioms (e.g., individuals of the ontology) form the assertional box (ABox) that follows the definitions of the TBox [Hildebrandt et al. 2018].

The method consists of three PBBs. The first PBB focuses on the elicitation of requirements for the ontology under development and the documentation of these requirements. The elicitation of ontological requirements, as presented in [Hildebrandt et al. 2018a], begins with a set of project requirements. During the documentation of the requirements of a CES, requirement models (e.g., sequence charts) of the CES that uses the ontology are annotated with ontological requirements. Ontological requirements are stated as competency questions. These are an informal notion of a query that should be answered by the ontology in a certain way, for example, "Which processes can be performed by machine X and what sensor measures which data?".

The second PBB is concerned with building the TBox of the ontology under development, which is described in detail in

*Fig. 6-3: Process building block for the ontology building method*

[Hildebrandt et al.2020]. This PBB begins with a search for information resources that provide the relevant terms and relationships in order to build the ontology under development. Potentially suitable information resources are industry standards (e.g., ISO or IEEE standards [VDI 2005] for the process description or [IEC 2016] for properties and features), scientific publications, or project reports. Standards are preferred due to the high maturity of the concepts and relationships used as well as their potentially wide dissemination. When the proposed method is applied, heavyweight ontologies are created which formalize the knowledge of a domain (e.g., process description) in a reusable manner and can therefore be used as ontology design patterns. As presented in [Hildebrandt et al. 2020] several ontology design patterns have already been published. In an ontology building project, these ontology design patterns are combined to obtain the ontology under development.

After having built the TBox of the ontology, we can begin with building the ABox of the ontology, which is sometimes referred to as the knowledge graph. The ABox contains all the relevant real-world facts (e.g., features or properties of a manufacturing process "Milling" *Building the ABox*

that was or will be performed) that should be contained in the answers to the competency questions stated at the beginning. In order to create the ABox, we use the ontology design tool we developed, which automatically transforms engineering artifacts (e.g., 3D CAD, AutomationML [Lüder et al. 2017]) into the ABox via an extract, transform, load pipeline. If there are no engineering artifacts available, we use a semi-automatic approach that relies on ontology design patterns again, see [Hildebrandt 2020a].

The final result is an ontology that describes facts about a CES that can be shared with other CESs. An application of an ontology in the domain of CESs is shown in Section 6.3.3, 6.3.3, 6.4.1, and 6.4.2 respectively.

#### **6.3.2 Capability Modeling**

*Capabilities of technical systems*

*Capability models formalize CES and CSG capabilities*

*Approach for creating capability models*  The capability of a technical system describes whether and with what quality the system is able to perform a specific task or fulfill a specific goal, while the task or the goal may vary with the context the system is operating in. The quality of the activity that is performed by the system depends on the context (i.e., on current requirements or boundary conditions), as well as on the immanent properties of the system (cf. [Reschka 2016], [Weiß et al. 2019]).

Capability models are used to formalize and document the capabilities of a CES or CSG. They are usually defined at design time of a CES or CSG or even prior to that, but they are predominantly used for runtime evaluations (e.g., a manufacturability check of a product based on the capabilities of available production systems).

Figure 6-4 gives an overview of the creation of capability models, distinguishing between the metamodel level, the domain capability model, the potential extension of the domain model based on projectspecific boundary conditions, and the integration of the projectspecific capabilities into the system model.

In the following, we explain the four sub-methods of the capability modeling approach, shown in Figure 6-4, in more detail.

*Capability metamodel creation:* The capability metamodel defines the structure of a capability model and its abstract syntax (cf. [Sprinkle et al. 2010]). It is neutral to any domain or application case. The metamodel is created based on a specification that may be derived from the requirements that various domains have with

*Fig. 6-4: Method for creating capability models*

respect to capability descriptions. We present a basic version of such a metamodel for capabilities in Figure 6-5.

*Fig. 6-5: Metamodel for capabilities*

In this metamodel, a capability is characterized by metadata such as a name and an ID, as well as by properties and pre- or postconditions (e.g., a required condition of a workpiece before applying a production capability in the discrete manufacturing domain). In addition, capabilities may relate to each other or may in turn be composed of capabilities. Such characteristics of a capability can be standardized for a certain domain by developing domain capability models.

*Domain capability model*

*Domain capability model creation:* The capability model for a certain domain is created by identifying the capabilities of a domain based on its defined scope and by considering existing ontologies as well as expert knowledge and industry standards. These domain capabilities are the input for a domain capability model that is independent from any specific system manufacturer. In addition, the domain capability model should be extendable in order to enable project-specific modifications (e.g., for niche or special applications or in case of technical innovations). To give an example, a model for manufacturing capabilities that applies to adaptable and flexible factories in the discrete manufacturing domain can be created. A domain capability model for discrete manufacturing must cover a defined structure and uniform nomenclature, as well as a means of describing manufacturable product features and typical restrictions and boundary conditions of the production systems. Moreover, potential interdependencies between capabilities—for example, with regard to production process chains and assembly sequences—must be taken into account (cf. [Wolf et al. 2020]). Example 1-1 shows an exemplary capability description in the discrete manufacturing domain:

*Project-specific capability model*

*Project-specific capability model creation:* For niche or special applications, or in the case of technical innovations, extensions to the existing domain capability model may be necessary. When a projectspecific capability model is created, the domain capability model is used as a basis. The system under development, for which the capabilities need to be modeled, provides the input for the extension of the domain capability model. The result of this method is a projectspecific capability model applicable to CESs and CSGs.

*Integration into system model*

*Integration of capabilities into the system model:* Finally, within a specific project, the capabilities of each CES and/or CSG must be described and interlinked with the system model. In this step, capabilities are assigned to the system and its sub-systems while taking the system-specific constraints on these capabilities into account. Example 6-7 shows the capability "drilling" of an exemplary machine with specific values. Please note that the generic capabilities modeled in the domain capability model can be instantiated not only for a specific production setup (i.e., distinct machines), but also for specific products to be produced to allow manufacturability checks during the operation phase of a factory (see Section 6.4.2 "Capability Matching" for further details). With regard to a manufacturing system, the properties of a capability may have a range of possible values (cf. Example 6-7), whereas in the case of a product to be produced, properties may have just a single value (e.g., diameter *d* = 10 mm).

As the capabilities of a system may be subject to variability, care must be taken to ensure that a differentiation between current and theoretical capabilities is possible. This is especially relevant if a system performs a reconfiguration or re-parameterization, as this usually implies changes in the capabilities of the system (see Section 6.3.3. The artifact that is finally generated is the system model, with capabilities and variability, which forms the basis for runtime evaluations.

Capability models can be implemented as ontologies (e.g., using the methodology in Section 6.3.1) or as feature models (cf. Section 6.3.3 and [Wolf et al. 2020]).

#### **6.3.3 Variability Modeling for Context-Sensitive Reconfiguration**

As stated in Section 6.3.2, certain CESs can be reconfigured during runtime, which means that the capabilities provided in a certain state can differ from the capabilities in a future state. This ability to change between different states is called reconfiguration. As CESs interact in an open and dynamic environment, a context-sensitive reconfiguration is desirable. Therefore, the goal of the engineering *Capabilities are subject to variability*

*Reconfiguration during runtime extends the available capability*

method variability modeling for context-sensitive reconfiguration is to support the creation of context-sensitive variability models (CSVM) for runtime usage. Context-sensitive variability models are dedicated models that represent different configurations a system can take. According to [Mauro et al. 2016], the problem space of a contextsensitive variability model consists of three parts: a feature model, a context model, and cross-tree constraints. Accordingly, the engineering method must include a separate creation phase for each part.

Figure 6-8 shows the overview of the engineering method, as well as the runtime usage. The first step is the creation of a feature model

*Fig. 6-8: Procedural overview variability modeling for context-sensitive reconfiguration*

in which all common and variable parts of a system are captured [Kang et al. 1990]. To identify and extract this information, the system model, which is composed of different engineering artifacts, must be analyzed. For a manufacturing system, this system model could be a 3D-CAD drawing in the form of a step file or control code according to IEC 61131. In the second step, a variability context model is generated that contains all relevant context information for triggering the reconfiguration of a system. For this purpose, the system's context must be analyzed. Accordingly, a concept is developed that is illustrated for the manufacturing domain and helps to identify the relevant information for reconfiguration — for example, other CESs providing certain capability such as handling or a certain product requirement such as a drilling hole diameter. For this purpose, different approaches, for example, [Marks et al. 2018], are analyzed and combined. Subsequently, to conclude the third step of the engineering procedure, the context model must be integrated with the feature model by formulating cross-tree constraints.

Cross-tree constraints are used to describe the dependencies between components that are required, for example, to provide a certain capability or to specify that a certain capability can only be provided in a certain configuration. These logical formulas are phrased as described in [Kang et al. 1990]. Once the third step of the engineering procedure has been completed, the problem space of the contextsensitive variability model is defined. The solution space is then used to enable the system to provide a self-description of its current configuration, including a description of the capabilities available. Therefore, the fourth step of the engineering method is the SPARQL query creation. SPARQL [SPARQL 2020] is a query language that builds upon the W3C standard Web Ontology Language [OWL 2020] and can be used to create, update, or query ontologies.

To create the SPARQL statements, the terminology box (TBox) that comprises the terms and relationships for describing a real-world phenomenon in an abstract manner must be considered [Asunción et al. 2004]. In the case of reconfiguration of modular manufacturing systems, the TBox describes how each system has to be characterized to be able to collaborate with other modules of the manufacturing system — for example, the module type package in the process industry [Ladiges et al. 2018], referred to in Figure 6-8 as "Heavyweight System Ontology," which is created following the ontology building method of Section 6.3.1. Thus, each reconfiguration requires an update of the system description such that it is always aligned with the current configuration of the manufacturing system. The SPARQL statements created are used to create and alter the assertional box (ABox), which contains the axioms (i.e., individuals of the ontology) [Baader et al. 2003] that represent the system description. The SPARQL statements are separated into snippets and related to features of the feature model. Only those features are represented in the system description that are selected in the current configuration. A detailed description can be found in [Caesar et al. 2019]. Once the fourth step is complete, the problem and solution space of the context-sensitive variability model is defined and can be used for reconfiguration during runtime, see Figure 6-8. Details of the variability binding algorithm can be found in Chapter 18.

#### **6.3.4 Scenario-Based Modeling**

During requirement elicitation, use case descriptions are a wellestablished means of gaining insight into the system to be designed. However, use case descriptions and requirement models (as needed in Section 6.3.1 for ontology building) are often informal and lack a concise semantics, meaning that it is difficult to reuse them later on in the development process. If scenarios are expressed using a specification language that is intuitive and lightweight but still concise *Scenarios can be described by use case models*

*Traffic sequence charts visualize traffic scenarios*

*Spatial views are used as base constraints*

and with a formal background, integration in the overall process (and even scenario-based development) becomes much easier.

In traffic-related applications (such as the implementation of maneuvers of a platoon of vehicles on a highway), it is especially important to express spatial properties and constraints. Traffic Sequence Charts (TSCs) are a visual formalism that allows intuitive and concise specification of traffic scenarios based on a formal semantics [Damm et al. 2018]. TSCs are based on acyclic graphs of chart nodes. Chart nodes capture constraints over a time interval and can be combined into a chart using sequence, choice, or parallel composition. In a chart, the constrained time intervals are seamless — that is, there is no time gap within a sequence of two nodes. Chart nodes include simple invariants (constraints that hold throughout the complete constrained interval), conditions (constraints holding at least once), and complex nodes specifying communication/event patterns or containing complete charts.

Spatial views describe spatial constraints between objects, represented by symbols in a topological view. Spatial views can be used as base constraints for invariant and condition nodes. TSCs are interpreted with respect to a modular world model that defines object classes, interfaces, and (if necessary) behaviors. World model modules are exchangeable, as long as appropriate interfaces are provided.

*Fig. 6-9: TSC excerpt of an overtaking maneuver*

*Fig. 6-10: Vehicle group symbol abbreviation*