The combination of spatial, time, and communication constraints allows traffic scenarios to be defined intuitively. For example, the TSC excerpt in Figure 6-9 describes an overtaking maneuver: during the first invariant, car 1 is somewhere (within the box with dotted lines) behind car 2. During the second invariant, car 1 is still behind car 2, but somewhere in both lanes. In the third invariant, car 1 is somewhere next to car 2, etc.

An important aspect for a specification language for CSGs is to represent spatial patterns regardless of the concrete number of systems in the group. For example, a platoon driving on a highway lane can be considered as a sequence of vehicles on that lane connected by spatial and non-spatial relationships. In a TSC, this is expressed using the ellipsis notation; an example can be seen in the lower part of Figure 6-10. The individual vehicles are represented by car symbols parameterized with the position of the vehicle in the group, ranging from iRhs (head of the group) to iLhs (tail of the group). All vehicles drive in the same velocity range, and each adjacent pair of vehicles travels in bounded longitudinal and lateral distance.

Showing detailed information for many objects can quickly become overwhelming and leads to important information being overlooked and lost. Therefore, TSCs offer the possibility to define onthe-fly visual abstractions by introducing abbreviation symbols. These symbols abbreviate spatial patterns in full depth but can be customized to display the most important information only, therefore (in some sense) highlighting the relevant essence of the group in the current situation. For example, Figure 6-10 introduces an abbreviation symbol that is parameterized in a start and end vehicle index (thus allowing selection of subgroups) as well as traveling speed. The individual vehicles are represented by car symbols.

Figure 6-11 shows two invariants being valid for the same time interval. The upper invariant describes the inner structure of a platoon, the lower one its relationship to the context. As the picture describes normal operation, there must be no other vehicle in the *Spatial patterns*

#### *Abstractions help manage complexity*

*Fig. 6-11: Separation of concerns: platoon inner structure and context*

immediate neighborhood of the platoon (depicted by the small crossed out car in the upper left corner of the box with dotted lines).

*Patterns allow specification of complex situations*

The patterns introduced allow the specification of complex collaborative maneuvers, such as how a platoon can circumvent an obstacle. The integrated formalism of TSCs provides the possibility to analyze the specified maneuvers, for example, by means of consistency checks as presented in [Becker 2020].

#### **6.4 Model Integration and Execution**

*Operational behavior must be validated*

During operation, the behavior of the system or the CSG must be validated taking the context into consideration. This can be done using simulation models, for example. Because generating these models requires high effort, it is unavoidable to automatically generate and calibrate them based on data from the real system and the knowledge of the system and context behavior. This leads to an integration of simulation into the design and runtime phase.

#### **6.4.1 Model Generation for Simulation Models**

#### **Model Generation via Knowledge Graph**

*Coping with heterogeneous input data*

With heterogeneous input data for the system and context, the automated generation of an executable model requires knowledge of the given system and context structure as well as an efficient connection of input data. As the context and system information are usually stored in heterogeneous data sources and formats, a common data model, including context as well as system information, must be extracted and combined.

This variety of data can be managed using ontologies as described above, represented through the application of a knowledge graph (see Section 6.3.1). In order to gain a single source of data description, the data model of the system, as well as the context used in the knowledge graph, is linked to the original data sources and formats. Queries can then be used to filter the relevant data and their linkage for the generation of simulation models. The models are matched using defined interfaces. As output of the knowledge graph, both models are extracted by export functions using requests leading to an executable simulation model.

The following properties of the knowledge graph make this approach applicable as an interface for heterogenous input data in dynamic context: in order to avoid the high effort of the classical and often manual generation of models as described above, the knowledge graph approach requires no predefined data model, offers fast access to complex hierarchical structures, as well as semantic search and analysis.

#### **Application to a Real Production System**

During operation of a production system, there are several ways to operate the system depending on requirements regarding available resources, production orders, or production time and costs. Therefore, the future system behavior must be predicted and the best operation strategy identified based on the current state.

The generalized system and context data models in the knowledge graph are concretely filled with current context information such as production plans, resource availability, and product mix provided by the *context information* artifact [Rosen et al.2020]. In addition, the system model is represented by different engineering artifacts, such as operation strategies, the production machines and their capabilities (see Section 6.3.2), as well as the plant layout (see Figure 6-12).

Depending on the simulation task—for example, material flow analysis or 3D-kinematic analysis—the adapted data from the knowledge graph can be used to generate different types of simulation models for discrete or continuous production processes. For both aspects, the independent generation of the context and system model represented either as a process model or as operation strategies, including their coupling, is possible. Moreover, different *simulation*  *Ontologies help with managing the variety of data*

*Simulation can be used for different tasks*

*models* can be generated automatically by varying the parameters

*Fig. 6-12: Knowledge graph for factory simulation*

dependent on the operation strategy. A final assessment of the different simulation results is performed using selected KPIs (e.g., throughput, buffer utilization, productivity, costs, energy) in order to identify the "best" operation strategy.

For example, as described in Section 6.3.3 for different configurations, simulation models can be generated to select the best suitable reconfiguration or rather to provide the evaluation of different strategies to allow the operator to make a decision (see Chapter 3).

#### **6.4.2 Capability Matching**

Context dynamicity leads to rapid changes in the operational environment of a CES (cf. [Tenbergen et al. 2018]). To cope with these changes, CESs may dynamically recombine at runtime to form a CSG that aims to fulfill a certain, usually context-dependent, goal. Note that CESs and CSGs do not always share the same goals or aim to fulfill complementing goals [Daun et al. 2019]. Due to the dynamic formation, configurations can occur where individual participants aim to achieve conflicting goals [Brings 2020]. As the dynamic formation of CSGs at runtime can hardly be foreseen at design time, a method is needed to examine whether a system group configuration actually provides the capabilities that are required under certain contextual boundary conditions. Therefore, we developed a method, based on model matching techniques, that enables such examinations by applying the following step-by-step approach (cf. Figure 6-13):

*Capability matching procedure*

*Required capabilities may change due to context dynamicity*

> *(1) Derivation of required capabilities:* The first step is to determine which generic capabilities and especially which combinations of

capabilities meet the requirements imposed by the goal or task of the CSG (e.g., the fulfillment of a customer's production request in an adaptable and flexible factory). The domain capability model introduced in Section 6.3.2 can be used to describe these capabilities needed for a certain goal attainment.

Figure 6-13 shows the process building blocks for this method.

*Fig. 6-13: Process building blocks for capability matching*

In the following, we illustrate the application of this method for the adaptable and flexible factory use case. In this use case, the requirements for the capabilities of CESs arise from a production request for an individualized product. The factory is equipped with production systems represented by various CESs and we must examine whether they can form a suitable CSG for the fulfillment of the production request.

*Capability matching for the adaptable and flexible factory*

*Instantiation of generic capabilities from the domain capability model*

Figure 6-14 illustrates schematically how the generic capabilities of the domain (or project-specific) capability model (see Section 6.3.2) are instantiated for the product and the production systems, thus generating the required and provided capabilities that form the basis for the matching.

*Fig. 6-14: Schematic sketch showing the instantiation of generic capabilities*

For capability matching, a check determines whether the required capabilities, represented by the production view in Figure 6-14, match the capabilities provided by the resources of the factory as shown in the function view in Figure 6-14.

*Integration of production and function view*

Consequently, the integration of the production view and the function view allows us to examine whether a certain product can be produced by the adaptable and flexible factory. Figure 6-15 illustrates the combination of the production view and the function view.

The figure shows three machines—lathe, milling machine, and polishing machine—as well as their production functions (i.e., instantiated capabilities from the domain or project-specific capability model). In addition, two different production process sequence variants for manufacturing the product with the given production systems are shown. There are some common steps between these two production processes (e.g., at the beginning, the raw material is first turned with the lathe, then drilled and turned again). Other steps differ: for example, screw thread tapping is conducted either on the lathe (Example I) or on the milling machine (Example II). In both cases, different intermediate products are exchanged between the lathe and the milling machine. Depending on the choice made, the

*Fig. 6-15: Integration of production view and function view to check manufacturability*

process can differ in time and costs. Therefore, the time and costs for each step must be calculated so that the optimal solution can be found.

For further information on the views presented and the principles of the matching method, please refer to [Daun et al. 2019a].

#### **6.5 Conclusion**

This chapter illustrated a modeling approach for analyzing the behavior of CESs during operation by re-using models from the engineering phase. We illustrated this approach for selected examples, addressing the main line of this developing approach. To improve the quality and reduce the effort for each step, additional improvements are necessary that lead to reusable ontologies, standardization of concepts, and interfacing to allow integration of tools. This leads to possible extensions not described in this chapter.

Even if the model generation process can then be executed automatically, a lot of effort is still required to develop the underlying ontologies in advance. Therefore, the ABox and TBox necessary for building the ontologies based on existing and established engineering artifacts must also be developed. Using databases also reduces this effort as the manual mapping between the ABox, TBox, and the industrial application can be reused more easily [Hildebrandt 2020a].

In addition to further reduction of efforts for the modeling, automatic model validation is also a big benefit. This can be done using review models [Daun et al. 2020]. All these approaches are part of a vision to introduce model-based development approaches to nonexperts in engineering and operation and efficient model generation and execution during runtime.

#### **6.6 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.

7

Torsten Bandyszak, University of Duisburg-Essen Lisa Jöckel, Fraunhofer IESE Michael Kläs, Fraunhofer IESE Sebastian Törsleff, Helmut Schmidt University Hamburg Thorsten Weyer, University of Duisburg-Essen Boris Wirtz, OFFIS e.V.

## Handling Uncertainty in Collaborative Embedded Systems Engineering

*As collaborative embedded systems operate autonomously in highly dynamic contexts, they must be able to handle uncertainties that can occur during operation. On the one hand, they must be able to handle uncertainties due to the imprecision of sensors and the behavior of data-driven components for perceiving and interpreting the context to enable decisions to be made during operation. On the other hand, uncertainties can emerge from the collaboration in a collaborative group, related to the exchange of information (e.g., context knowledge) between collaborative systems. This chapter presents methods for modeling uncertainty early in development and analyzing uncertainty during both design and operation. These methods allow for the identification of epistemic uncertainties that can occur when various, potentially heterogeneous systems are required to collaborate. The methods also enable graphical and formal modeling of uncertainties and their impact on system behavior (e.g., in the course of dynamic traffic scenarios). Furthermore, this chapter investigates the quality of outputs issued by data-driven models used to equip collaborative embedded systems with uncertainty-resilient machine learning capability.*

#### **7.1 Uncertainty in Collaborative Embedded Systems**

Collaborative embedded systems (CESs) are often safety-critical, operate in dynamic contexts within a collaborative system group (CSG), and must be capable of reacting to unforeseen situations without human intervention. Uncertainty that can occur during operation should be considered systematically during engineering to enable CESs to cope with uncertainties autonomously. This section first introduces an ontology for understanding uncertainty in CESs. It then continues with an explanation of different kinds of uncertainty using the platooning example.

#### **7.1.1 Conceptual Ontology for Handling Uncertainty**

*Core concepts for describing uncertainty*

In order to lay the foundation for understanding uncertainty that can occur during the operation of CESs, we have developed a lightweight ontology. This ontology defines core concepts for describing the different facets of uncertainty. It thereby provides the basis for seamless consideration of uncertainty in the engineering and operation of CESs. However, the ontological concepts are generic enough to describe different kinds of uncertainties, as we will see in Section 7.1.2. The ontology focuses on uncertainty that occurs during runtime, which differs from design-time uncertainty (e.g., ambiguous requirements) [Ramirez et al. 2012]. Nevertheless, the ontology is used during the design of CESs. Figure 7–1 shows the ontology as a UML class diagram.

*Uncertainty related to information*

As can be seen in Figure 7–1, *uncertainty* is the central concept of our ontology. However, other concepts are necessary to fully account for uncertainty and its consequences. Uncertainties are always related to certain *information* (e.g., about the operational context in which a CES is operating) that stems from a specific *source* (e.g., a sensor or another CES). With regard to information, uncertainty means that it is not clear whether the information is valid as processed in a specific *scenario* during the operation of CESs. In that scenario, *information* is processed by an *agent* to make a decision or to perform some activity based on the information. Hence, an agent perceives the uncertainty related to specific information. In order to cope with uncertainty, it needs to be quantified to allow for automated uncertainty handling approaches to be applied — for example, using probabilistic or fuzzy approaches.

*Fig. 7-1: Core ontology for describing uncertainty*

In a *scenario*, *risks* may occur due to uncertainty. The term *risk* is used in a generic way here; it covers safety hazards but also, for example, economic risks. A risk can have a negative *impact*—for example, an accident—as well as a specific *likelihood* of occurrence. Uncertainty can be mitigated in two ways: 1) by mitigating the risk—that is, by reducing the likelihood or severity of an *impact*—or 2) by reducing the uncertainty that originally triggers the *risk*. Hence, the ontology includes the *risk mitigation* and the *uncertainty mitigation* concepts.

An uncertainty also always has at least one *cause* — that is, a reason why the uncertainty occurs. We can use the *type* concept to distinguish between different causes of uncertainty. We decided to relate the type of an uncertainty to its cause and not to the uncertainty itself, since categorizing uncertainties often relates to abstract sources of uncertainty, such as imprecision of sensors (cf., e.g., [Ramirez et al. 2012]), failures of communication networks, or insufficient trust in other agents (cf., e.g., [Yu et al. 2013]). Section 7.1.2 illustrates such types of uncertainty using the example of autonomous vehicles.

#### **7.1.2 Different Kinds of Uncertainty**

In this section, we consider the use case of "Cooperative Vehicle Automation," which enables vehicles to form platoons on highways in order to reduce fuel consumption and increase traffic throughput (cf. [Jia et al. 2016]). As explained in Chapter 1, there are specific *Relationship between uncertainty and risk*

*Cause and types of uncertainty*

*Uncertainty in "Cooperative Vehicle Automation"*

uncertainty-related challenges that emerge from this use case. In the following, we consider these challenges in more detail in order to illustrate different kinds of uncertainty that can occur during the operation of CESs. Specifically, we place particular emphasis on uncertainties rooted in the operational context of CESs, which is highly dynamic. The operational context comprises other CESs (e.g., other cars equipped with cooperative ACC (CACC) systems, which are engaged in or able to join a platoon) as well as non-collaborative context objects (e.g., pedestrians or vehicles steered manually).

*System under consideration and context objects*

An exemplary situation is depicted in Figure 7–2. It shows a platoon consisting of a certain number of vehicles (three of which are shown), as well as another non-collaborative vehicle driving ahead of the platoon leader (labeled "LV" in Figure 7–2). Furthermore, the car labeled "JV" attempts to join the platoon, which requires message exchange and coordination with the platoon leader. In the subsequent sections, we make use of this example to illustrate various concepts. Where applicable, we distinguish between the system under consideration (SUC) and its context objects (COs). For instance, in Figure 7–2, the platoon leader could be the SUC, whereas the messages it receives from other cars, as well as the other cars themselves and surrounding objects (e.g., road signs), are considered COs.

*Fig. 7-2: Uncertainty in the open and dynamic context of CESs*

There are three different sources of uncertainty under consideration:

1. *Perception-related uncertainty*: Due to the inherent imprecision of sensor devices, information representing the current context situation of a system may be invalid. CESs also share context information in order to jointly mitigate uncertainties. Each vehicle is equipped with sensory devices — such as a radar sensor or cameras for perceiving obstacles, other traffic participants, and

*Uncertainty relates to perception, data quality, and communication*  traffic signs. For example, an onboard camera sensor may be affected by dirt on the camera lens, resulting in uncertainty regarding the context information. Furthermore, the timing of events related to the context perception may cause uncertainties (e.g., caused by time delays in the transmission of sensor signals, see Section 7.2.2).

Since these uncertainties have different causes (cf. Section 7.1.1), uncertainty is a multi-faceted and cross-cutting concern that requires a multitude of methods and techniques to enable CESs to handle such uncertainty autonomously during operation. The following sections present different methods for modeling and analyzing uncertainty that are complementary in our comprehensive uncertainty handling framework. Each method aims at handling a specific kind of uncertainty listed above. Furthermore, the different methods target both the development time (e.g., modeling methods) as well as runtime methods (e.g., wrapper components enabling the quantification of a DDC's uncertainty).

#### **7.2 Modeling Uncertainty**

In the following, we present approaches for modeling uncertainty, including a language for modeling early uncertainty information and relating it to other artifacts and a domain-specific method for capturing behavioral uncertainty in traffic scenarios.

*Complementary methods for handling uncertainty*

#### **7.2.1 Orthogonal Uncertainty Modeling**

In the engineering of CESs, uncertainties that may occur during operation must be considered systematically. In the early stages of requirements engineering in particular, potential runtime uncertainties must be identifiedand documented so that stakeholders can analyze and consider them appropriately. The ultimate goal of considering such uncertainty during engineering is to design CESs that are able to safely handle uncertainties during operation.

*Orthogonality of uncertainty*

Depending on project-specific demands, various different artifact types are used in a complementary manner to model a CES under development and other relevant information, such as the operational context. Typical modeling perspectives used in requirements engineering distinguish structural, functional, and behavioral aspects of the CES and its context. Uncertainties are not limited to a single artifact but rather affect different aspects modeled in several artifacts. For example, perception-related uncertainty due to the failure of a sensor (see Section 7.1.2) is reflected in all three modeling perspectives: the interface between the CES and the sensor device where the uncertainty appears in the form of missing or corrupted data—is captured in structural models; sensor data is processed by CES functions modeled in the functional perspective; and finally, sensor failure may result in certain (mis-)behavior, where uncertainty can be detected, and uncertainty may affect the CES behavior.

*Difficulties in capturing uncertainty information*

Hence, uncertainty can be considered a cross-cutting concern, similar to variability (cf., e.g., [Bachmann et al. 2003], Chapter 18). Describing uncertainty by attaching uncertainty information to model elements across different artifacts (e.g., denoting sensor data as the information subject to uncertainty) has two essential drawbacks:

*Orthogonal uncertainty models*

In the following, we present a modeling technique [Bandyszak et al. 2018b], [Bandyszak et al. 2020] to support the systematic identification and documentation of runtime uncertainties during the entire engineering process. The core idea is to capture information that describes uncertainty (see Section 7.1.1) in a separate artifact and connect this information to other engineering artifacts (called "base artifacts") through trace links. These first-class uncertainty artifacts created using a dedicated graphical modeling language are called "*orthogonal uncertainty models*" (OUMs). OUMs provide a central artifact for analyzing uncertainties and how they affect and must be accounted for during engineering.

#### **Modeling Concepts and Notation**

OUMs employ a specific perspective on the operation of an SUC. The modeling concepts and the corresponding graphical notation are introduced in Table 7-3. As we can see, the core concepts for describing uncertainty are captured using UML-like stereotype notation and specific iconic representations to foster understanding of the uncertainty information modeled. The visual notation comprises node types and connector elements for modeling uncertainty relationships within the OUM, as well as establishing relationships to other artifacts.

In order to model uncertainty from the dedicated perspective of a CES during operation (i.e., the "agent" under consideration), we define some specialized extensions to the ontology defined in Section 7.1.1. While the actual information subject to uncertainty is captured in the base artifacts, the OUM uses the *observation point* concept to specify where uncertainty becomes visible. Furthermore, the cause of an uncertainty is subdivided into its *rationale* (i.e., the reason why uncertainty occurs) and *activation condition* elements. Rationales and activation conditions can be combined in a tree-like structure using conjunction/disjunction nodes to describe the cause of uncertainty.

The possible effects of an uncertainty (i.e., risks and impacts of uncertainty, see Section 7.1.1) are captured using *effect* links that point to base artifact elements — for example, system functions affected by uncertainty. In contrast, *uncertainty mitigations* are modeled in the base artifacts (e.g., specific functions that cope with uncertainty) and related to the uncertainty modeled in OUMs. The OUM also allows relationships between different uncertainties to be modeled, including causal and amplification relationships (see Table 7-3).

*Graphical modeling language*

*Modeling uncertainty observation and cause*

*Modeling uncertainty relationships*

*Tab. 7-3: OUM concepts and notation [Bandyszak et al. 2020]*

#### **Example**

Figure 7–3 shows an example OUM (middle part) as well as some exemplary base artifacts (upper and lower part). The latter include a structural context model, a functional model, and a behavioral model of the exemplary CACC system. To reduce complexity, only excerpts related to the joining maneuver are depicted. Moreover, a sequence diagram shows interactions between two vehicles—each equipped with a CACC—in the course of the joining maneuver.

*Fig. 7–4: Orthogonal uncertainty model example*

The exemplary OUM specifies two uncertainties. First, there can be uncertainty related to inconsistent context information. In this example, the context is perceived in the form of camera data processed by a DDC (cf. Section 7.3.2), as well as by context information communicated by other vehicles, because in the joining maneuver, the leader vehicle informs the joining vehicle about the gap to be taken. The uncertainty of inconsistent information occurs when the gap information obtained by the DDC (e.g., indicating an obstacle *Inconsistent information from different sources*

in the gap) differs from the information communicated by the platoon leader (e.g., gap is free). The rationale of this uncertainty could be a failure of the camera sensor or misbehavior of the DDC that interprets the camera data. A potential effect may be the inability to safely complete the joining maneuver. This uncertainty is described further in [Bandyszak et al. 2018a].

*Uncertainty in intervehicle communication*

Another uncertainty modeled in this exemplary OUM relates to uninterpretable messages from other vehicles. In Figure 7–4, this message exchange is illustrated in a sequence diagram. This uncertainty may be caused by technical communication failures of the V2V network, or inconsistent ontologies underlying the representation of the data that is exchanged (cf. Section 7.3.1). For example, during the join maneuver, goals (e.g., target destination and driving preferences) must be exchanged between the vehicle that requested to join a platoon and the platoon leader. However, when inconsistent ontologies are used to specify goals (e.g., considering different concepts for electric vehicles), the goals of the joining vehicle cannot be interpreted, which in turn affects the corresponding CACC function.

#### **7.2.2 Modeling Uncertainty in Traffic Scenarios**

When designing a CES, it is important to estimate the impact of uncertainties (as early as possible) in order to be able to make qualified design decisions. Therefore, semi-formal uncertainty modeling techniques (such as the OUM presented in Section 7.2.1), which are especially helpful for understanding uncertainty in early design phases, must be complemented with formal modeling approaches, which allow quantification of the possible influence on CSG behavior throughout the design process.

For this aim, uncertainties must be modeled mathematically—for example, as random variable or probabilistic distribution—and the effects of uncertainties on behavior must be identified and modeled, resulting in probabilistic CES/CSG behavior models. Probabilistic behavior models can be used as a base for mathematical analysis for example, by probabilistic model checking or stochastic analysis (e.g., by using repeated simulation).

*Assessing uncertainty impact according to defined criteria*

*Formal modeling of uncertainties*

> Within the mathematical analysis, the probabilistic behavior model is assessed with regard to an evaluation criterion within the context of a scenario. Typical evaluation criteria are risk or quality of service. Mathematical assessment of the impact of uncertainties can help to guide the design process in many areas, including:

Summarizing the above, for behavioral modeling of uncertainties, a behavior model is extended to a probabilistic or stochastic behavior model. For assessment, a scenario model and an evaluation criterion are also required. These model components are described in more detail in the following. We start with scenario modeling, which is necessary to describe the situation for which the assessment is performed.

#### **Modeling Traffic Scenarios for CSGs**

Modeling a traffic scenario with the participation of CSGs requires a specification language with the ability to express dynamically changing relationships (including spatial relationships) between a variable number of CESs involved in a CSG.

Traffic sequence charts (TSCs) [Damm et al. 2017], [Damm et al. 2018] are one such formalism that allow intuitive and concise graphical specification of dynamic constraints based on formal semantics. TSCs (which—with a different focus—are also described in Chapter 6) 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 TSC, 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) and conditions (constraints holding at least once), as well as complex nodes that specify communication/event patterns or contain 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.

For example, the TSC excerpt in Figure 7-5 describes a scenario in which the car with index n+1 joins a platoon consisting of the vehicles with index 1 (platoon head) to n (platoon tail) driving at speed v. The TSC consists of four chart nodes: the first chart node is an invariant *Scenario-based behavioral modeling*

*Traffic sequence charts (TSCs)*

*TSC example*

that contains a spatial view and describes the phase where the approaching car is still far away from the platoon (which is represented by an abstract symbol, see Chapter 6 for more detail). Phase 2 is described by two nodes holding in parallel: the spatial invariant expresses that the approaching car is closer to the platoon but has not yet reached the distance for initiating a join maneuver. During phase 2, the approaching car sends a join request to the last car of the platoon, which eventually answers granting the right to join. In phase 3, the approaching car actually joins the platoon, and then phase 4 is reached, in which the car is part of the platoon.

*Fig. 7–5: TSC excerpt describing a car joining a platoon*

TSCs are interpreted with respect to a modular world model, which defines object classes, interfaces, and behaviors. World model modules are exchangeable, as long as suitable interfaces are provided. Consequently, behavior modules can be specified using different specification languages (with suitable interfaces) — for example, hybrid automata or stochastic/probabilistic hybrid automata. This flexibility can be used for combining the same scenario specification with different CES implementation variants or CESs whose granularity has been refined during the development process.

#### **Behavioral Uncertainty Modeling**

As a first step for behavioral uncertainty description, the occurrences of uncertainties must be identified and modeled mathematically. For behavioral modeling, it is mostly runtime uncertainties—which influence the behavior of the model—that are relevant. These uncertainties can be separated into two classes, depending on the timing of interactions. *Discrete time uncertainties* deal with discrete events, such as sending and receiving messages, or sensors resulting in discrete signals (see Section 7.1.2). *Continuous time uncertainties* deal with continuous interactions, such as following a trajectory or sensors continuously reporting the location of objects (at least the start and end of object detection are discrete events). Both classes include uncertainties due to time delays and data distortion, but only discrete time events can be completely missed.

Discrete time event misses can be modeled mathematically by a random variable connected with a probability. Data distortions occur with a certain probability distribution. A discrete time delay can be modeled by a random variable with a probability distribution. Time delays for continuous uncertainties may involve time compaction or dilation and are a little more complicated, but can still be covered by a (more complex) probability distribution.

These mathematical uncertainty models can be embedded in hybrid automata behavior models, resulting in probabilistic hybrid automata incorporating uncertainty behavior.

#### **Risk Assessment**

The last missing building block describes the use of the probabilistic behavioral CES/CSG model involving uncertainty. There are two main analysis methods: *probabilistic model checking* [Katoen 2016] can compute the probability with which an evaluation criterion (such as a criticality or a quality of service measure) is reached. Probabilistic *World models*

*Considering uncertainty related to timing*

*Discrete time and continuous time uncertainties*

*Probabilistic and stochastic model checking*

model checking is mathematically more stable but is more applicable for small systems due to its complexity. *Stochastic model checking* [Kwiatkowska et al. 2007] (which is done by performing many simulation runs) is not as exact, but the performance is less challenging. During simulation, the probabilistic elements of the probabilistic behavior model must be instantiated according to the associated probability distribution. The resulting simulation runs are then assessed with respect to the evaluation criterion. Similar to probabilistic model checking, the results can be used as a quality measure for the behavior modeled.

#### **7.3 Analyzing Uncertainty**

In addition to modeling uncertainty semi-formally and formally, more specific analysis methods are necessary to fully account for the various kinds of uncertainty (see Section 7.1.2). Uncertainty analysis methods cover, among other things, guidance for identifying potential uncertainty sources as well as eliciting more specific information for (automatically) estimating uncertainty. In the following, we present a classification scheme that helps identify epistemic uncertainties, as well as an approach to provide situation-aware estimates of the uncertainty in an outcome of a DDC during operation of CESs.

#### **7.3.1 Identifying Epistemic Uncertainties**

This section presents a classification scheme that facilitates the identification and classification of epistemic uncertainties resulting from information exchange in CSGs (see Section 7.1.2). For this purpose, we first describe the different types of epistemic uncertainties that may occur in this context. We then present the epistemic uncertainty classification scheme for runtime information exchange (EURECA) and its application during requirements engineering. For an in-depth presentation of the approach, including formal modeling of knowledge and epistemic uncertainties (as well mitigation strategies, etc.), please refer to [Hildebrandt et al. 2019].

*Epistemic uncertainties in platooning*

In this section, we use an example in which the SUC is a platoon leading vehicle that runs on a combustion engine and the CO is an electric vehicle that wants to join the platoon (see Section 7.1.2). As epistemic uncertainties result only from a lack of understanding regarding a message the SUC *receives*, all examples concern messages sent from the CO to the SUC. As we show in the following, epistemic

uncertainties can appear at the type level and at the instance level. Uncertainty sources at the type level are rooted in the terminological knowledge utilized by CESs to specify messages. In simple terms, terminological knowledge is comparable to a vocabulary that includes the relationships between vocabulary items and is from here on referred to as the TBox [Krotzsch et al. 2014]. At each level—that is, type and instance level—four different classes of uncertainties can be distinguished. Figure 7–6 illustrates a subset of these classes (T1, T3, I1, and I2). As we can see, the set difference of the SUC TBox (upper ellipse at the top of Figure 7–6) and the CO TBox (lower ellipse)is not empty, resulting in various uncertainties. The uncertainty classes illustrated and additional classes are detailed in the following.

#### **Uncertainty Sources at the Type Level**

There are four classes of uncertainties that may occur at the type level. All of these uncertainties result from a mismatch between the TBox of the SUC and the CO used for specifying and interpreting the messages to be exchanged at runtime.

*Fig. 7–6: Epistemic uncertainties at type and instance level*

The first class of type-level uncertainties results from a *known difference in scope* (T1) between the TBox of the SUC and the CO. This uncertainty occurs whenever the CO sends the SUC a message that includes a TBox element that is not included in the SUC's TBox. The difference in scope is *known* insofar as the *unknown* TBox element has a *known* relationship to a *known* TBox element, which may allow for *Known difference in scope*

some kind of mitigation at runtime. For instance, if the message contains an element "MinimizeEnergyConsumption" with the relationship "hasSupportingGoal" connecting it to the element "IncreaseDownhillRecuperation," the SUC may understand the first two elements but not the last one since it is not an electric vehicle.

*Unknown difference in scope*

The second class occurs whenever there is an *unknown difference in scope* (T2). In this case, the message contains an *unknown* TBox element that has an *unknown* relationship to a *known* TBox element. This makes mitigation at runtime more challenging. For instance, if the message from the CO contains an element "DesiredStateAtDestination" with the relationship "hasStateOfCharge" to the element "StateOfCharge," the SUC may understand the first element but not the second and third as these are concepts specific to an electric vehicle.

The third class of type-level uncertainties results from a *distinct scope* (T3). In this case, the *unknown* TBox element has no attachment to the SUC's TBox whatsoever and mitigation is barely possible. For instance, a message from the CO containing the goal "ReachNextChargingStation" might not be understood by the SUC at all because it has no relationship to any known concept.

*Inconsistent ontological commitment*

*Distinct ontologies*

*scope*

Uncertainties of the fourth class occur whenever a message indicates an *inconsistent ontological commitment* (T4). For instance, if the CO informs the SUC about its consumption in the measurement unit kWh, whereas the SUC measures its consumption in liters, this may lead to uncertainty even if the SUC's TBox contains the elements kWh and consumption.

#### **Uncertainty Sources at the Instance Level**

While the previously described type-level uncertainties result from terminological differences, the following uncertainties pertain to the actual information contained in a message. The first class, *semantically inconsistent information* (I1), occurs when a message contains a value that violates the semantic definition of a relationship that it refers to. For example, the SUC is informed by the CO about its "MaximumPowerConsumption" with regard to the goal "MinimizeEnergyConsumption." Even if the SUC understands the former concept in a different context (such as its power outlet), this message will result in uncertainty as the SUC running a combustion engine would consider only "MaximumFuelConsumption" a valid concept in this context.

*Situationally incomplete information*

*Situationally incomplete information* (I2) as a source of uncertainty occurs whenever a message contains a set of statements that does not satisfy the requirements of the situation at hand. For instance, consider a CO that wants to join a platoon and the SUC as the platoon leader requires the information "MaximumFuelConsumption." However, if the CO provides only the "Destination" in its message, the SUC will perceive the message as incomplete.

The third class of instance-level uncertainties results from *situationally inconsistent information* (I3), which occurs whenever the content of a message is inconsistent with regard to the information expected by the SUC for the situation at hand. Consider a platoon where the vehicles regularly broadcast their range in kilometers. If the platoon now descends a steep road, the virtually constant braking might actually increase the reported range of the CO (the electric vehicle). The SUC, however, might expect a range decrease over time and thus considers the reported range to be *situationally inconsistent*.

The fourth class of instance-level uncertainties results from *missing type membership* (I4). This class of uncertainty occurs when a message contains an information item that lacks a type membership. For instance, the SUC might receive geographical coordinates from a CO but no information on what these coordinates refer to.

#### **EURECA**

In order to systematically analyze and capture the previously described uncertainties at the instance and type level, we developed an epistemic uncertainty classification scheme for runtime information exchange (EURECA). The two-dimensional scheme is depicted in Table 7-7.

*Tab. 7-7: EURECA applied to the platooning example*

The first column is populated with the SUC ontology that the uncertainties captured relate to. In our examples, we considered only the SUC's goal ontology, but other ontologies obviously might be subject to epistemic uncertainties as well. The second column lists the concrete ontology elements that are subject to epistemic uncertainty according to the analysis performed. A checkmark indicates which *Two-dimensional classification scheme*

*Situationally inconsistent information*

*Missing type membership*  specific epistemic uncertainty has been identified for an ontology element. Note that in our example, each ontology element is subject to exactly one type of epistemic uncertainty; however, the elements could also be subject to multiple types. Instead of checkmarks, we could also indicate the specified communication scenario in which an element is subject to uncertainty (cf. [Hildebrandt et al. 2019]). This approach is generally recommended due to improved traceability when new scenarios are added or scenarios are changed during subsequent requirements engineering iterations — for example, when an agile development approach is applied.

The epistemic uncertainty classes identified are rooted in an analysis of the underlying ontological foundations of knowledge exchange and are not the result of domain-specific considerations. Hence, while evaluation has been performed only for the automotive domain, we are confident that EURECA can also be applied to other domains — for example, distributed energy production and adaptive factories.

#### **7.3.2 Assessing Data-Driven Uncertainties**

Components with data-driven models [Solomatine and Ostfeld 2008], such as those obtained when applying AI and machine learning methods, are becoming increasingly important for complex softwareintensive systems. In particular, CESs intended to collaborate in an open context have to process various kinds of sensor inputs to recognize and interpret their situation in order to handle changes in their environment and interact with previously unknown agents. Unlike traditionally engineered components, which are developed by software engineers who define their functional behavior using code or models, the functional behavior of a DDC is learned automatically from gathered data through an algorithm.

*Assuring correct behavior of a DDC*

As a consequence, the functional behavior expected from a DDC can be specified only in part on its intended application domain, usually based on a number of example cases for which data was previously collected and augmented with additional information. Consequently, we cannot provide assurance that such a component will behave as intended in all cases [Kläs 2018], resulting in datarelated uncertainty (see Section 7.1.2).

*Example situation*

In our example, the current speed limits have to be considered when a vehicle wants to join an existing platoon (cf. Figure 7–2). One *information source* for current speed limits can be a DDC that provides traffic sign recognition (TSR) based on data of the camera sensor in the CESs of interest(as shown in Figure 7–3). At the latest since 2012, deep convolutional neural networks have proven their superior performance for this kind of task and can be considered as a state-ofthe-art approach for TSR [Krizhevsky et al. 2017]. Nevertheless, uncertainty remains inherent in the outcome of our TSR component since we cannot specify for all possible combinations of pixel values within an image what kind of traffic sign should be reported.

Because the use of DDCs is an important source of uncertainty in CESs, the uncertainty they introduce must be appropriately understood and managed not only during *design time* but also during *operation*. In the following, we first present a classification for the different sources of uncertainty relevant when applying a DDC, and then introduce "*uncertainty wrappers*" as a means of quantifying and analyzing the level of uncertainty for any specific situation at runtime.

#### **Three Types of Uncertainty Sources**

The sources of uncertainty in DDCs can be separated into three major *types*: uncertainties caused by limitations in terms of model fit, data quality, and scope compliance [Kläs and Vollmer 2018]. Whereas *model fit* focuses on the inherent uncertainty in data-driven models, *data quality* covers the additional uncertainty caused by their application to input data obtained in suboptimal conditions, and *scope compliance* covers situations where the model is probably applied outside the scope for which the model was trained and validated.

In our example, limitations in model fit may be caused by restrictions in the number of model parameters, input variables considered, and data points available to train the model. Limitations in data quality may be caused by weather conditions, such as rain, natural and artificial backlight, a dirty camera lens, and other factors that make it more difficult for the TSR component to reliably recognize the correct traffic sign on the given image. Finally, limitations in scope compliance occur when a model is used outside its target application scope (TAS). For example, if our TSR component was intended to be used for passenger cars in Germany, its application in a different country will make its outcomes questionable because the component was most likely built and validated only for German traffic signs.

#### **Managing Uncertainty during Operation**

The *uncertainty wrapper* approach was developed to better deal with uncertainty inherent in the outcomes of data-driven models during *Considering both design and runtime of DDCs*

*Examples for uncertainty sources*  operation. It supports this purpose by encapsulating the data-driven model to enrich the model outcomes with dependable and situationaware estimates of uncertainty. This allows the CES that processes these outcomes to make more informed and dependable decisions.

The approach is *holistic* in the sense that it addresses uncertainty caused by limitations in model fit, data quality, and scope compliance. Moreover, it is *generic* in the sense that it is model agnostic — that is, it states no requirements on the data-driven model it encapsulates. Specifically, it does not require that the existing model be adapted nor that the model provides specific kinds of outcomes.

The uncertainty wrapper approach consists of a selection of concepts that extend and refine the uncertainty ontology introduced in Section 8.1, equations that allow quantification and aggregation of uncertainties from different types of sources [Kläs and Sembach 2019], an architectural design proposal, and a tooling framework for building and validating uncertainty wrappers [Kläs and Jöckel 2020].

#### **Uncertainty Wrapper – Architecture and Application**

In the following, we introduce the most prominent elements of the uncertainty wrapper architecture and relate them. Moreover, we illustrate them on a simplified application example in the context of the previously introduced example case.

*Extension of DDC outcomes*

*Characteristics of uncertainty wrappers*

> The wrapper encapsulates the existing data-driven model and extends its *outcome* with *dependable uncertainty estimates* (Figure 7– 8).

*Fig. 7-8: Uncertainty wrapper architecture and example applications*

*Example for application*  In our example, the outcome of the model could be the information about whether the data-driven model has recognized a "speed limit 50" sign or not (cf. Figure 7–2). The uncertainty is then expressed by the likelihood that the outcome provided is not correct.

Besides the data processed by the data-driven model, the *datadriven model input* may contain further data that is used by the wrapper to assess the degree of uncertainty in the model outcome. For example, the GPS signal may be used to determine whether the vehicle is still in Germany, a task which is conducted by the *scope model*. The result is then provided as a scope factor evaluation result to the *scope compliance model,* which calculates the likelihood of scope incompliance considering the results for all scope factors.

Moreover, the rain sensor signal may be also used as an input. Based on this signal, the *quality model* determines the level of precipitation, which is anticipated to have an influence on the recognition performance of the data-driven model. Together with the results of other quality factors, the *quality impact model* then determines a situation-aware uncertainty estimate using a decision tree model as a white box approach.

Finally, the uncertainty information provided by the scope compliance and quality impact model are combined to give a dependable uncertainty estimate that considers the requested level of *confidence*.

In Figure 7–8, we illustrate this for three cases. In Case A, we get an extremely high uncertainty because the DDC is used in New York, which is outside the TAS. In Case B, we obtain low uncertainty since the component is used in its TAS under good quality conditions. In Case C, we would end up with a moderate uncertainty since the rain makes the recognition task more difficult.

#### **Uncertainty Wrappers – Limitations and Advantages**

In order to build an uncertainty wrapper, in addition to the existing data-driven model, we need data for a representative set of cases from the TAS, most preferably augmented with labels that indicate quality deficits. Alternatively, quality deficit augmentation frameworks such as the one presented in [Jöckel and Kläs 2019] may be applied.

In comparison to a more traditional approach, where uncertainty is estimated by the data-driven model itself, the use of uncertainty wrappers provides advantages in practice. Its uncertainty estimates are unbiased since it does not rely on data used during the training of the data-driven model. Moreover, the uncertainty assessment is broader because it considers more types of uncertainty sources, including the commonly neglected scope compliance, and also information that is relevant for uncertainty but not for the primary *Further data to assess scope compliance*

*Quality and quality impact model*

*Examples for application results*

*Unbiased and broader uncertainty assessment*  objective of the data-driven model. Finally, uncertainty wrappers can simplify safety assessments of data-driven models by not only providing statistically safeguarded uncertainty estimates at a requested confidence level, but also promising more comprehensible evaluations by domain and safety experts since they decouple the uncertainty analysis from the "black box" as which most data-driven models are still considered.

#### **7.4 Conclusion**

CESs operate in highly dynamic contexts and thus have to cope with uncertainties during operation. This uncertainty cannot be fully anticipated during design, since CESs are increasingly autonomous and adaptive, and CSGs may take various forms. Nevertheless, it is crucial to systematically consider potential runtime uncertainties during the engineering of CESs. This requires methods for identifying, modeling, and analyzing uncertainty to develop CESs capable of coping with uncertainty during operation autonomously.

*Uncertainty ontology*

This chapter approached the complex task of uncertainty handling during CES engineering by first conceptualizing uncertainty. To this end, we presented an uncertainty ontology that defines core concepts to describe uncertainty. Among other aspects, this ontology provides a means of describing and understanding causes of uncertainty and relating uncertainty to information gathered through certain sources (e.g., sensors) and processed by CESs.

*Versatile modeling and analysis methods*

Based on the ontology and a characterization of different kinds of uncertainty relevant for CESs and CSGs, we presented methods for modeling uncertainty, and for analyzing uncertainty and its effects during both design and operation. To model uncertainty graphically, especially during early phases, we presented a modeling language for specifying uncertainty in dedicated artifacts — that is, orthogonal uncertainty models. As a more formal approach, we presented a behavioral modeling approach based on traffic sequence charts for analyzing risks in dynamic traffic scenarios. As part of the analysis methods, we presented a classification scheme for identifying epistemic uncertainties in the information exchange among CESs. Furthermore, we presented an analysis method to support the safe operation of DDCs by equipping them with a wrapper that provides reliable information on situation-specific uncertainty.

#### **7.5 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.

David Santiago Velasco Moncada, Fraunhofer IESE Daniel Schneider, Fraunhofer IESE Ana Petrovska, Technical University of Munich Nishanth Laxman, Technical University of Kaiserslautern Felix Möhrle, Technical University of Kaiserslautern Stefan Rothbauer, Siemens AG Marc Zeller, Siemens AG Chee Hung Koo, Robert Bosch GmbH Samira Safdari, Expleo Germany

## Dynamic Safety Certification for Collaborative Embedded Systems at Runtime

*Traditionally, integration and quality assurance of embedded systems are done entirely at development time. Moreover, since such systems often perform safety-critical tasks and work in human environments, safety analyses are performed and safety argumentations devised to convince certification authorities of their safety and to certify the systems if necessary. Collaborative embedded systems, however, are designed to integrate and collaborate with other systems dynamically at runtime. A complete prediction and analysis of all relevant properties during the design phase is usually not possible, as many influencing factors are not yet known. This makes the application of traditional safety analysis and certification techniques impractical, as they usually require a complete specification of the system and its context in advance. In the following chapter, we introduce new techniques to meet this challenge and outline a safety certification concept specifically tailored to collaborative embedded systems.*

#### **8.1 Introduction and Motivation**

Embedded systems are presently evolving from stand-alone closed embedded systems towards open and collaborative embedded systems (CESs). In CESs, collaboration can take place on different scales—from small, predefined groups of systems to large, heterogenous collectives of systems at a global level—and there will be an evolution from smaller scales to larger scales of collaboration [Damm et al. 2019]. Collaboration between CESs means sharing information concerning context perception, reasoning, and actuation. It means acting in unison with each other to reach a suoperordinate goal or to render a higher level service that could not be achieved by single systems alone.

The potential in this is very significant. For many existing applications, it will become possible to improve important performance properties (e.g., speed or efficiency), decrease resource consumption (e.g., fuel consumption), and improve safety (e.g., in a platooning scenario) simultaneously. The implications for society and the economy are correspondingly huge, as the systems envisioned have the potential to completely transform and improve our societies and economies in a groundbreaking way.

There are, however, a number of challenges that must be tackled before this vast potential can be unlocked. Most importantly, established engineering approaches—and safety engineering approaches and standards in particular—focus on closed systems and cannot be applied to future CESs without further ado.

Traditional safety engineering approaches typically require a complete understanding and specification of the system (and its context) under consideration at design time. CESs, however, may be integrated with other CESs at runtime and thus form collaborative system groups (CSGs) dynamically. Some of these systems may not even be on the market during the design phase of others. Therefore, the goal of obtaining a full specification of all possible variations of CSGs is generally not feasible at design time, and new safety certification approaches are required.

CrESt set out to investigate corresponding solution ideas based on a range of complementary industrial use cases. A key premise of our proposed safety assurance approach is that the required information is only partially available at design time and must be completed at runtime. This assumption means that certain parts of the assessment process that traditionally take place at design time have to be postponed until runtime, when all variables can be resolved. This applies in particular to the final verdict as to whether the integrated CSG is safe or not. Nevertheless, we consider it essential to conduct as much preparatory work as possible during the design phase to ensure that the final assessment at runtime can be performed efficiently and in a largely automated way.

The remainder of this chapter is structured as follows: Section 8.2 gives a brief overview of the proposed safety certification process. Section 8.3 describes the integration of modular safety cases at runtime to obtain a coherent safety case for the systems group. Section 8.4 addresses the inner details of the modular contracts at different levels and how they can be standardized. Finally, Section 8.5 concludes this chapter with a summary.

#### **8.2 Overview of the Proposed Safety Certification Concept**

Our safety certification concept stipulates a two-stage process. The first step concerns the preparatory work at design time. Here, each CES is equipped with a modular safety case. In each modular safety case, the respective CES is conceived as a stand-alone system and an interface for the integration with other modular safety cases is defined. The main purpose of these modular safety cases is to provide safety arguments and evidence to enable better decision-making at runtime. To this end, modular safety cases include the working conditions of their respective CESs, such as requirements that are placed on the environment or other CESs. Furthermore, they specify guarantees that may or may not be given by the CES for its own services provided, depending on whether certain conditions are met or not. Hazard and risk analysis make it easier to understand potential hazards that may originate from a system. Context modeling and analysis allow identification of the uncertainties that may arise in a particular context, as well as shared resources that have to be coordinated between systems. Fault analysis investigates possible malfunctions and drives the definition of safety measures. Finally, all these aspects are then combined into a modular safety case for each system.

The second step in our safety certification concept concerns the integration of the modular safety cases at runtime with respect to the planned collaboration. For this purpose, information on how the CESs are organized among themselves and what types of dependencies emerge as a result is required. This information can, for example, originate from a human integrator who arranges the CESs (adaptable factory) or it can be generated by a machine — for example, from onboard computers (vehicle platooning). The resulting system architecture therefore reflects the interdependencies between the CESs, which are needed to integrate their modular safety cases. Finally, the integrated safety case is evaluated and used to assess the safety of the CSG as a whole.

To perform the second step, both semi-automated approaches with human intervention (cf. Section 8.3) and fully automated approaches (cf. Section 8.4) are feasible, depending on the context. In the case of a semi-automated approach, a human operator can be kept in the loop through manual selection of a suitable configuration, for example. In the case of full automation, the systems can negotiate their relevant properties on a peer-to-peer basis. This can be done on a contract basis by providing and demanding guarantees for services exchanged. At runtime, the safety of the collaboration is continuously monitored in a feedback loop. If the conditions for safe cooperation are no longer met, the systems must react accordingly — for example, by graceful degradation or termination of cooperation.

#### **8.3 Assuring Runtime Safety Based on Modular Safety Cases**

As already motivated, CESs must react to ongoing, constant changes in their open, dynamic context. However, for the systems to react at runtime, the CESs must first be aware of their relevant context [Petrovska and Grigoleit 2018] so that they can subsequently monitor and assess the type and impact of the context change. Additionally, in parallel, uncertainties resulting from these changes have to be handled effectively. To allow an efficient certification for the CSG at runtime, a dynamic risk assessment is performed. The systematic documentation of all relevant evidence enabled by modular safety cases helps safety engineers during the certification process.

In the context of an adaptable factory, major trends such as the growing individualization of products and volatility of product mixes lead to a situation where every product is produced differently and is routed according to the current production situation [Koren 1999], [Yilmaz 1987]. In this chapter, we demonstrate our methods using a small case study as a running example. Reconfigurable industrial CESs

(such as a robot arm and a tray as a storage unit) are used to assemble a small roll that consists of a roll body, an axle, and two metal discs as depicted in Figure 8-1.

*Fig. 8-1: Case study description for an adaptable factory*

#### **Modeling CESs and their Context**

In practice, CESs are typically developed either within one original equipment manufacturer or by different suppliers. Moreover, when CESs form collaborative system groups (CSGs), the CSGs can hardly be analyzed a priori as relevant context because they are typically not explicitly defined at design time. On the contrary, they are formed, at least to a certain extent, emergently at runtime, which is actually a key trait and strength of CESs and the open ecosystems they enable. A CSG fulfills a global goal that an individual CES cannot fulfill alone. Of course, as already motivated, the increased complexity of the functionality requires different verification, validation, and certification approaches.

One method for testing a CES for consistency and correctness is the use of executable models, referred to as monitors. A monitor observes the execution of a system and determines whether it meets the given requirements [Goodloe and Pike 2010]. The monitor can then register and log the violations found during the test. In particular, in CSGs, monitors may help in detecting specification violations when the requirements are described as goals. One of the main characteristics of these goals is that they are influenced by the orchestration of the different CESs. However, for the systems to react at runtime, the CESs must first be aware of their relevant context through the constitution of runtime models of the context where the CESs operate, so that they can subsequently monitor and assess the type and impact of context changes on the systems (this is explained further in Section 8.3.3).

#### **Modeling the Context**

Context awareness is generally accomplished through the creation of context models, which depict relevant aspects of the context for the CES. The context models are initially created at design time of the systems, and updated accordingly during runtime. However, in practice, there are differences in the context modeling concepts among different manufacturers and suppliers. This exacerbates the integration effort of different data models to integrate CESs, causing a "semantic heterogeneity" [Jirkovský et al. 2016]. The use of ontologies unfolds the potential to serve as a conceptual as well as a technological representation of such data models to cope with the semantic heterogeneity and enable semantic interoperability [Negri et al. 2016].

#### **Content Ontology**

We propose an ontology, shown in Figure 8-2, that integrates elements of two types of context: (1) classes and relationships of the interacting CESs, known as the operational context, and (2) sources of information with respect to the CESs, seen as the context of knowledge.

*Fig. 8-2: Context ontology*

The operational context models the interaction between a system under analysis and other systems in the environment, whereas the context of knowledge focuses on relevant knowledge sources that possess information about the system under analysis [Daun et al. 2016]. The aim of integrating these two types of context together is to gather relevant classes for constructing a context model that includes relevant information that can subsequently be used to check specification violations during runtime monitoring.

Our proposed ontology allows a distinction between the system under analysis and the parts of the context that may influence the system but that cannot be changed. The system under consideration/analysis is called the "context subject." The context, composed of context objects, is that part of the environment that is relevant to the context subject. To allow the distinction between parts of the context that are collaborative and context objects that do not collaborate, we name a context object "collaborative context object." This distinction permits the identification of the entities that interact with the context subject, their dependencies with the context subject, and dependencies among context objects.

From a functional perspective, collaborative context objects provide services or functions that are accessible to the context subject. In our ontology, context object function entities are used to document the dependencies and the exchange of data between the context subject and these context functions. From a behavioral perspective, to enrich the documentation of a context function, we use context object state and context state variable entities. These entities provide information about the different states, and their related variables, that define the behavior of a context function. Furthermore, these context states define the context object behavior of collaborative objects in the context.

In the context of knowledge, the ontology integrates entities that provide and/or constrain the collaborative objects in the context. In particular, we are interested in safety guarantees and hazards that provide information and constrain context objects and the context subject based on standard rules.

#### **Modeling Context in the Adaptable Factory**

The creation of a context model is a process that is executed at both design time and runtime. At design time, the functional, structural, and behavioral aspects of the operational context of the CESs are modeled into a generic context ontology. This generic ontology can then be refined to create a domain-specific ontology that captures all relevant information of the domain — in our case, the adaptable factory use case. Both ontologies are represented as OWL files. The resulting ontology enables CESs to store context-related information and draw conclusions from this information. The domain-specific ontology of the adaptable factory serves two purposes: the ontology (1) defines the input data, defining in particular where the data is located and what the relationships between different data are. For a mechatronic object, for instance, the ontology may specify where this CES is located (i.e., its position in the machine cell). This results in purpose (2), where the ontology can be used to find constraints in the data. A mechatronic object may specify, for instance, the maximum speed at which the CES moves.

At runtime, the CESs are identified and a CSG configuration is selected. This information is then replicated into the adaptable factory context ontology: for each CES identified, a new individual (i.e., the instance of an entity in the ontology) is created and all the relevant information is stored as data properties of the new individual. Finally, the information stored in the context ontology is queried to build a runtime context model. For implementation and evaluation purposes, the runtime context model is stored in an XML file.

#### **Runtime Uncertainty Handling**

The term "uncertainty" is used in different ways in different research fields. Uncertainty and its impact are being extensively explored by research communities in areas such as economics, software and systems engineering, robotics, artificial intelligence, etc. In the field of cyber-physical systems, there are multiple definitions for uncertainty, and the one provided by [Ramirez et al. 2012], serves as a rationale for our collaborative systems: "Uncertainty is a system state of incomplete or inconsistent knowledge such that it is not possible for the system to know which of two or more alternative states/configurations/values is true." As explained, CESs interact and integrate at runtime; the uncertainties that occur during runtime, more specifically the ones that might create safety-critical scenarios for CSGs, are of prime importance here.

Two types of uncertainties can be distinguished: epistemic uncertainties and aleatory uncertainties [Perez-Palacin and Mirandola 2014]. The epistemic type refers to the uncertainties that arise due to incomplete knowledge or data, and the aleatory type of uncertainty is the result of the randomness of certain events. Epistemic uncertainties can be handled effectively by collecting additional information, meaning that the uncertainty then ceases to exist. In contrast, aleatory uncertainties are relatively complicated because of their inherent randomness. The concept presented will help to address most of the epistemic types of uncertainties and few of the aleatory type. The main viewpoint of handling uncertainties explained in this section would be from that of safety assurance.

#### **Concept Overview**

The outline of the concept is to provide a quantified, well-reasoned, and well-defined mapping of the uncertainties identified to their corresponding mitigation steps. The CSG is constantly monitored at runtime for occurrences of uncertainty and, based on the definitions and parameters of these occurrences, runtime adaptations of configurations for CESs or any further specific measures defined in the mapping are undertaken to ensure safety.

#### **Development of a U-Map for the Adaptable Factory**

The solution approach is centered around the development of an uncertainty map (U-Map) artifact during design time. This artifact is used as the knowledge base at runtime for monitoring and executing mapped mitigation measures for uncertainty occurrences. The first step in the development of a U-Map is identifying the relevant uncertainty and its classification. This step is the most vital and also the most time-consuming. Here, all possible uncertainties are listed based on various classifications from research, the most recent and extensive being the one from [Cámara et al. 2015]. To aid the process of identifying uncertainties with respect to the information exchange between CESs from an ontological perspective, the classification provided by [Hildebrandt et al. 2019] is used. Both of these classifications are used as a checklist to identify possible uncertainties at runtime, specific to the use case. Once identified, concrete instances of uncertainty must be defined. In due process, uncertainties that can be resolved during the design of the CSG but have not been considered in general system development have to be updated. These instances have to be further iterated and quantified as monitor specifications so that they can be detected at runtime. Examples include ambiguity in sensor measurements, inconsistency in service descriptions, incompleteness in self-descriptions of CESs, or incompleteness in information exchange. The next step involves identifying all possible failures that might occur from these uncertainties that might put the system into a hazard state and might subsequently lead to an accident or harm. To aid this, standardized hazards and failures from [ISO 2010] are considered for the adaptable factory and from [ISO 2018] for vehicle platooning. Bayesian networks [Halpern 2017] and the Dempster-Shafer theory [Shafer 1976] based on probability theory are found to be effective for mapping the uncertainties identified to possible failures and hazards. As an outcome, we notice that each uncertainty can lead to multiple hazards and every hazard can be a result of one or more uncertainty occurrences. The next step involves mapping these hazards to their corresponding mitigation measures. For the use case of the adaptable factory, an intermittent step of rectification acts as an additional layer of safety assurance, which is feasible because of the semi-automated approach employed. The uncertainties that can be eliminated by rectification measures occur predominantly in information exchange between individual CESs. In certain cases, the system may still be in a hazardous state even after the uncertainty has been eliminated through rectification. To maintain safety, these hazards must be further mapped to appropriate mitigation measures. The mitigation measures can be either based on present industrial standards or they can be reconfiguration identified as degradation modes. In certain scenarios, these degradation modes alone are not sufficient and additional protective measures have to be taken.

*Fig. 8-3: Visualization of a U-Map*

In the end, an extensive set of identified uncertainties is mapped to an even bigger set of possible hazards, which in turn is mapped to a rather small set of degradation modes and protective measures. This U-Map makes implementation simple and does not have an exploded range of mitigation measures that have to be undertaken specifically to handle every uncertainty. However, creating such a map and ensuring its completeness to handle all possible uncertainties at runtime can be a complex task, which presently relies greatly upon the research communities' identified sources of uncertainty, which in themselves might not be complete. Furthermore, we consider subjective probability for uncertainty occurrence [Shafer 1976],

which in itself might be imprecise. A U-Map can be visualized as shown in Figure 8-3.

At runtime, with the help of this U-Map, the necessary rectification measures are taken by the safety engineers, thereby eliminating relevant uncertainties before safety approval. The degradation modes and additional protective measures serve as an input for further explanation of dynamic safety certification, in that they enable the appropriate configuration and safety measures to be chosen.

#### **Runtime Monitoring of CESs and their Context**

The generated runtime context model from Section 8.3.1 can be used to deliver relevant information that enables runtime analysis/monitoring.

With the information available from the context model explained in Section 8.3.1 and the specifications for uncertainty detection from the DTU map as explained in Section 8.3.2, monitors can be created to monitor the properties of interest in a given CES. The monitors and the specifications are created at design time; however, the monitors are executed during runtime. For example, it may be desirable to monitor the speed of a mechatronic object to determine whether the said speed obeys safety requirements. A common way to create a runtime monitor is to translate assertions about the state of a context element into rigorous specification formalisms [Bartocci et al. 2018], such as LTL formulas, to subsequently create instrumentation files with the monitor specifications. In our example, a domain expert can provide the assertion "It is always the case that CES1 moves at a speed of 2 mm/s" and this can be translated into the LTL formula ܩ)ܿ݁ݏ1. ݏ݁݁݀ ≥ 2 ;(this formula can be used to create the monitor specification [Bartocci et al. 2018] as instrumentation files1 that have to be integrated into the CES. The runtime monitor specification must be created during design time and the instrumentation files generated should be integrated during development. At runtime, these monitor specifications, including the specifications from the DTU map, will be represented in the form of modular safety cases. In the context of an adaptable factory, a centralized software that is responsible for task orchestration and system assessment can identify and compile the monitoring requirements dynamically to allow for the final approval by safety engineers in a semi-automated certification process.

<sup>1</sup> http://fsl.cs.illinois.edu/index.php/MOP

#### **Integrated Model-Based Risk Assessment**

Due to frequent changes in the products being manufactured, adjusting a factory quickly is a major challenge. This raises concerns with regard to dependability due to unknown configurations at runtime. Thus, apart from functional aspects (i.e., the check of whether a factory is able to manufacture a specific product), safety aspects as well as product quality assurance aspects must be addressed. In flexible production scenarios, a risk assessment must be conducted after each reconfiguration of the production system. Since this is a prerequisite for operating the factory in the new configuration, a manual approach can no longer effectively fulfil the objectives for assuring safety in highly flexible manufacturing scenarios. During production, every process step has the potential to influence the quality of the product in an undesirable way, for example depending on the precision of the equipment used, or random failures while executing the process step. This is captured in a Process Failure Mode and Effects Analysis (process FMEA) with the concept of failure modes of a process step as well as the respective severity. The process FMEA also defines measures for detecting and dealing with unwanted effects on product quality. Since both the factory's configuration and its products change constantly in adaptable factory scenarios, a process FMEA must be performed dynamically during operation.

In the context of industrial production systems, the safety standards ISO 13849 [ISO 2006] or IEC 62061 [IEC 2005] provide guidelines for keeping the residual risks in machine operation within tolerable limits. For every production system, a comprehensive risk assessment is required, which includes risk reduction measures if necessary (e.g., by introducing specific risk protective measures such as fences). The resulting safety documentation describes the assessment principles and the resulting measures that are implemented to minimize hazards. This documentation lays the foundation for the safe operation of a machine and it proves compliance with the Machinery Directive 2006/42/EC of the European Commission [European 2006].

In this section, we present an approach for the model-based assessment of flexible and reconfigurable manufacturing systems based on a meta-model. This integrated approach captures all information needed to conduct both risk assessment and process FMEA dynamically during the runtime of the manufacturing system in an automated way. The approach thus enables flexible manufacturing scenarios with frequent changes in the production system up to a lot size of one.

#### **Meta-model SQUADfps**

To address the aforementioned problem statement for a dynamic assessment at runtime, a meta-model called SQUADfps (machine Safety and product QUAlity assessment for a flexible proDuction system) is presented [Koo, Rothbauer et al. 2019]. This metamodel considers hazards and failure modes due to both safety and quality issues. Four categories are introduced within the SQUADfps metamodel: *process definition*, *abstract services*, *production equipment*, and *process implementation*. This depicts the modularity within an adaptable factory scenario. This integrated model-based approach allows information not only from each item of modular production equipment (i.e., CESs within CrESt) to be considered during the assessment, but also from the production context.

With the focus on quality assurance, an integrated CES that provides services for production (EquipmentService) steps brings along information about its possible failure modes (EquipmentFailureMode) at runtime. Equipment that provides quality measures (CoveredFailureMode) brings along the information about the effectiveness of the measures (e.g., detection) regarding specific failure modes (EquipmentFailureMode). The suitability of the planned production schedule—that is, the equipment's suitability to provide the required services—can be analyzed by conducting a model-based quality assessment process FMEA, taking the production recipe and the services required into account, as shown in Figure 8-4. For the risk assessment, possible hazards introduced into the overall production system during process implementation can be captured and checked against the available SafetyFunction to determine whether safety requirements are fulfilled.

The benefits of applying SQUADfps for the dynamic certification of CSGs in an adaptable factory are twofold: firstly, this metamodel allows risk-related information to be captured dynamically at runtime. Secondly, the risk information—be it hazards or failure modes along with the analysis of this information—provides input for the modular safety cases systematically. The process of conducting a dynamic safety certification is discussed in subsequent paragraphs.

*Fig. 8-4: Meta-model SQUADfps for a dynamic machine safety and product quality assessment at runtime [Koo, Rothbauer et al. 2019]*

Based on the case study described, we now present the results generated using SQUADfps to aid understanding.

#### **Case Study Example**

Table 8-5 shows the product recipe R = r1, …, r6 for producing a pulley wheel, specifying the required process steps. For each recipe step required, the relevant failure modes are listed and a measure of their severity (Sev) is given as they would impact the final product. This information can be added by the design team of the product, as they know exactly how each failure mode will impact the final product. For each failure mode in the product recipe, a measure of the detectability (Det) by scheduled quality measures is also given. For example, the failure mode Misplacement of the service Pick & place can be detected visually with high certainty (detection value is one) but the failure mode Crimping will likely go unnoticed as these can only be detected by stress tests that are not considered in this process instantiation.

Consider the first process instantiation P in Table 8-5, consisting of process steps p1, …, p6a. Process P is capable of producing the pulley wheel, as it provides all the services required and in the correct order. For each deployment of a required recipe step to a process step on a concrete item of equipment, the occurrence—the information regarding failure mode frequency (Occ)—can be added to the model. This information is provided by the vendor of the production equipment that provides production services and the operator will

possibly also update these values based on local production experience (e.g., environment conditions).

*Table 8-5: Case study process definition and two possible deployments of the Process P and P' (production schedules)*

Looking at the risk priority numbers (RPN), the chosen process deployment P for producing the product seems to come at a high risk of not reaching the required quality goals, which is indicated by the high value of the RPN. An alternate process instantiation using more reliable equipment and higher precision quality measures can be seen in Process P' in Table 8-1. The equipment Robot arm 2 has a lower probability of introducing the critical crimping failure mode (Occ value 2 for Robot arm 2 vs. Occ value 4 for Robot arm 1) and a highprecision laser scanner is used as a quality measure. As we can see, the concrete instantiation of the process on actual equipment influences the occurrence values for each failure mode of a production step as well as detection values. As a consequence, the risk measured—for example, using the product of occurrence and severity (RPN)—will differ and the highest values of RPN are lowered from 100 to 20.

Considering machine safety, the results generated using modelbased risk assessment for the various integrated CESs can be seen in Table 8-6 (for the production schedule P'). In this table, the combination of the risk parameters F (Frequency), S (Severity) and P (Possibility for avoidance) will determine the risk level (which is represented as the Performance Level PL used for safety analysis).

*Table 8-6: Exemplary results for the model-based risk assessment*

In the exemplary safety risk assessment shown, we can see that the integrated robot (CES) might cause a hazard ℎ<sup>ଵ</sup> shearing when the operator loads the material into the assembly cell. The runtime assessment system evaluates this risk as PL e (very high risk according to ISO 13849-1) based on different data from the context and allocates a possible existing safety function to ℎ<sup>ଵ</sup> . As the integrated safety-sensitive cover for the robot has a very high reliability (also PL e), it provides proof that the risk of ℎ<sup>ଵ</sup> can be mitigated during the interaction task. A similar analysis procedure is also performed for all relevant hazards to generate the foundation for the safety risk assessment.

This approach is of a qualitative nature, which in practice is very effective for prioritizing measures for the main problems. It can be extended to deliver quantitative measures of production risk. The approach aims to assist humans in finding an optimal solution for producing a product while considering both machine safety and product quality aspects.

#### **Dynamic Safety Certification**

The goal of a dynamic and runtime safety certification in the context of an adaptable factory allows an accelerated operational safety approval (i.e., certification) after system modifications are performed. With the dynamic safety certification method presented, automated capture and analysis of runtime data can be performed more efficiently. In the production domain, the human's role as the person responsible remains significant to guarantee system safety in accordance with the European Machinery Directive [European 2006]. Therefore, a human-in-the-loop assurance based on the concept of modular safety cases [Kelly 2007] is proposed for the adaptable factory use case.

The concept of using a modular safety case allows relevant requirements (i.e., safety goals) and analysis results (i.e., argument and evidence) to be documented in a systematic way for the required certification process. The initiation of these modular safety cases highlights the context-relevant requirements that must be fulfilled by the specific runtime system configuration—as already mentioned earlier—to deal with monitoring, uncertainty, and risk requirements. Dealing with all these requirements successfully and the completion of modular safety cases at runtime will contribute to the overall certification of the adapted CSG.

*Fig. 8-7: Dynamic safety certification for adaptable factory*

An interactive tool called AutoSafety [Koo, Vorderer et al. 2019] has been developed to help operators and safety engineers to assess and approve the adaptable assembly demonstrator at runtime (the dynamic safety certification process is shown in Figure 8-7). This semi-automated certification approach builds up the safety case of the CSG by integrating modular safety cases of the integrated modular systems while considering relevant runtime safety aspects (e.g., runtime measures) identified during reconfiguration. Moreover, AutoSafety will be able to highlight the status of each modular safety case individually with regard to whether they are successfully fulfilled based on runtime data. When automated analyses of certain runtime variables are conducted, the respective modular safety cases can be updated automatically. Humans can also perform updates to ensure the correctness, accuracy, and completeness of the results. For highly adaptable factory scenarios in the future, this dynamic runtime certification approach will be able to accelerate the safety approval procedure and minimize manual engineering efforts required for assessment and documentation.

#### **8.4 Design and Runtime Contracts**

This part of the chapter explains the use of contracts within the specification, development, and standardization of safety-critical collaborative systems. The concepts are illustrated in connection with the use case "Vehicle Platooning"

One of the biggest challenges with collaborative systems is to ensure that the systems behave safely — not only as individuals but also as an integrated system. At the same time, a collaborative system can only be successfully introduced into the market if its safety can be assured — for example, based on an adequate certification process. This could be achieved as part of the design time engineering or based on a combination of design time engineering and runtime assurance/certification measures. In the first case (i.e., safety assurance achieved during design time engineering), a traditional method of system development would be pursued, with the difference being that this would be done for the integrated system, which is an abstract construct. However, this requires that the CESs and CSGs are known to a sufficient extent — for example, by means of comprehensive standardization of system and service characteristics for a domain. The second case (i.e., safety assurance based on a combination of design time engineering and runtime assurance/certification measures) is ideal, given the natural dynamics of collaborative systems. To achieve this, we require a fully integrated and comprehensive solution (e.g., runtime certification, an infrastructure for communication, certain standardization — for example, with regard to interoperability, tracking, evaluation, enforcement, etc.). However, it is impossible to decide what this solution should look like for future systems, although we can make pragmatic assumptions as far as we require these aspects for our work. In this project, we have focused in particular on closing the gap between traditional design time certification and runtime certification. We have done this by introducing an approach for collaborative systems specification that relies heavily on contractbased design and engineers the exchange of guarantees and demands/assumptions during runtime. During the design phase, contracts allow the distribution of responsibilities of the participants to be defined, and during runtime, they allow safe behavior to be enforced.

#### **Design-Time Approach for Collaborative Systems**

One of the main drivers in the definition of our approach is the lack of understanding of how to establish a safe collaboration. Therefore, it is not our aim to find the best solution for a particular aspect. Instead, we are aiming for a more comprehensive solution that could help us to better understand the problem and thus distinguish and highlight the more important aspects when considering certification for safe behavior. For this reason, the approach defines the need to specify and certify the CSG itself. The goal is to make the CSG specification the standard that defines the minimum requirements for collaboration in a specific scenario (in our case, a vehicle platoon). System developers who want to participate in such collaboration must then comply with the specification and the associated domain regulations.

#### **Creating the CSG Specification**

To build a CSG specification systematically, we consider the following refinement steps.

**At the business/domain level**, the CSG designer must initially define the aim or subject matter of the collaboration. We believe that, given the nature of collaborative systems, service-oriented architectures (SOA) [Bell 2008] offer useful concepts for specifying this aspect. These include the specification of the functions and objectives of collaboration, roles, allowable system compositions, structural configurations, environmental constraints, and the definition of service contracts.

**At the functional level**, and by following a traditional top-down approach, the reference architecture that defines how functionality and responsibilities are distributed among roles is built. This includes defining the minimum requirements, the behavior, and functions of the roles and their dependencies, and setting the flexibility points. As mentioned above, runtime contracts could be used to enable such flexibility points. We consider ConSerts [Schneider 2013] to be a useful technique for realizing this concept since they are contracts that are specifically designed to be exchanged during runtime. ConSerts include concepts for defining the quality of the data to be exchanged, and they can be used to define the reactions to contract violations and discrepancies that will guide the change of behavior in the system.

**At the contract level**, the design decisions have been refined enough so that the CSG designer can define the final list of requirements in the form of verifiable contracts. This should be done in a more formal way to avoid misinterpretations by the CES developers.

#### **Safety-Relevant Activities**

In parallel to the design, the safety activities are performed:

**At the business/domain level,** the safety engineer should be able to perform the hazard and risk analysis for the CSG thanks to an initial list of system functions. This takes place at two levels:

**At the CSG level,** the consequences of the fail behavior of functions at CSG level must be investigated—for example, platoon deceleration. A lack in deceleration of a platoon can lead to a mass collision. This clearly has a higher severity than a single vehicle collision.

**At the role level,** the fail behavior of the subsystems in the collaboration, according to the initial function distribution among the roles, must be investigated with regard to its effect on the integrated system.

**At the functional level,** and given the specification of the safety goals and a first draft of the functional architecture, fault analysis can be performed in the form of a Component Fault Tree (CFT) [Domis and Trapp 2009]. This allows safety measures to be identified and the current design to be adapted to avoid or mitigate these failures. Safety measures are represented by safety requirements, which can be mapped directly to the collaboration roles. With a safety strategy in mind and the design that reflects it, it is then possible to create the functional safety concept for the CSG level.

**At the contract level,** and similar to the procedure for the architecture design, the safety requirements mentioned must be defined in terms of verifiable safety contracts.

#### **Contracts Concept**

As mentioned above, the CSG specification defines the functionality and behavior that the roles will take on in a collaboration. This is partly defined by functional and safety contracts. These contracts are considered as pure design-time contracts since they are exchanged and consumed only during the CSG-CES development time. On the other hand, ConSerts should be exchanged during runtime. In this approach, this means that ConSerts must also be developed and be standardized as part of the CSG specification so that they can also be successfully exchanged and consumed at runtime.

In the context of the vehicle platoon use case:

• Functional contracts were primarily defined based on the state machine of each role. They define the behavior relevant for collaboration in a particular state.

• Safety contracts define the reaction to failure situations. Therefore, they mainly refer to the transitions in the state machine that connect normal states and failed operational states (including degraded states).

• ConSerts were engineered as an additional function of the system in close relation to the service contracts defined in the context of the service-oriented architecture.

• Service contracts define the specific messages exchanged between leader and follower. Therefore, ConSerts were defined in the form of guarantees of the safety-relevant data being exchanged.

• ConSerts are consumed according to the reference architecture for three purposes: to support flexibility, to allow valid CSG compositions, and to drive change of states.

**Flexibility aspect**: If demands and guarantees are met, the collaboration is allowed. Flexibility is supported because demands define a range in which guarantees can satisfy them. If the guarantees remain within this acceptable range, collaboration is allowed.

**Valid compositions**: A valid composition means that a demand is satisfied by a specific guarantee. If this is not the case, the collaboration should theoretically be terminated. We consider the validation of demands vs guarantees in two ways:

**Contract violation**: A violation is deemed to have occurred when the vehicle with demands can prove on its own that the service provider is not acting in accordance with its guarantees.

**Contract discrepancy**: A discrepancy arises when a demand cannot be satisfied by any guarantee.

**Change of states**: A contract violation is engineered in the platoon scenario such that when it occurs, the vehicle that detects the violation will preventively transition into a degraded mode for a certain time and notify the system causing the problem. In the event of a contract discrepancy, the collaboration with the provider is terminated. This will finally lead to the division of the platoon into sub-platoons.

#### **Runtime Evaluation of Safety Contracts**

A full detailed runtime analysis and safety assurance of all collaboration scenarios, including all environmental conditions, is not possible for real systems. Functional and safety contracts provide the means to operate on an adequate abstraction that has been prepared by diligent development time engineering. The use of safety contracts of different CESs requires the development of an environment capable of composing and evaluating these contracts at runtime. In the vehicle platoon use case investigated, safety contracts are used to define the reaction to failure situations, and safety guarantees are expressed as a means for tolerating deviation from a nominal behavior.

#### **Simulative Approach for Validation of Safety Contracts**

In order to validate the safety contracts designed and evaluate the behavior of the overall system when failures occur, a simulative approach can be used. Simulations and model-based evaluation of safety contracts are used during the development phase to observe the system behavior and validate the expectation of the safety engineer at design time. In the simulation, various manipulations, such as data corruption, invalid data due to a hardware defect, and other possible failures can be injected into the system [Isermann 2017]. An executable model of the collaborative embedded system should be created first as a means of validating the required safety functionalities.

Safety contracts separate requirements into assumptions and guarantees, which help to decrease the complexity of verifying the implementation against its specifications. Using a formal approach such as failure detection and isolation (failure handling) to do this allows the process of contract evaluation to be automated.

#### **Case Study: Vehicle Platoon Example**

The aim of the vehicle platoon use case is due to maintaining a short inter-vehicle distance. This would be achieved by exploiting real-time knowledge of the driving behavior of each vehicle in the platoon through onboard sensors and wireless communication among platoon members. If a sensor or communication failure occurs, or the respective safety guarantees become worse due to context changes, then the real-time knowledge would not be reliable, which puts the platoon in an unsafe mode. Therefore, both failures and changes in safety guarantees must be detected and compensated to keep the system working under any circumstance. Using a graceful degradation concept would help the system to remain operational (with a degraded performance) in at least some such conditions. Note that the simulative approach used in the CrESt project is not executed in a fully realistic scenario due to effort limitations; instead, a highly simplified scenario has been used. The simulation model focuses on a platoon system that is already running, consisting of three vehicles running on one straight highway without any tunnels, curves, or inclines. In the simulation runs, one predefined safety contract is evaluated as an example. The results of the simulation are presented in Figure 8-8 and Figure 8-9. These figures show the system behavior in the event of a distance measurement sensor failure.

*Fig. 8-8: Example: Generation and handling of errors with Simulink*

*Fig. 8-9: Example of error injection simulation results in a longitudinal platooning model using Simulink*

As shown above, the failure injection block (in the left side) in Figure 8-8 is implemented as a MATLAB function in Simulink and is located before the sensor inputs into the controller block. It can generate invalid sensor values at a specified time with the desired repetition rate of the error. Moreover, the failure detection and degradation function validates the incoming data before it is passed on to the controller. Figure 8-9 shows the course of the platooning without applying error detection and degradation. Here, it becomes obvious that a sensor defect causes a deviation in the platooning distances because of the impacted controller performance. The third vehicle from Figure 8-8 is still following the previous vehicle because it is receiving correct speed data.

#### **8.5 Conclusion**

In this chapter, we presented a concept for safety certification of collaborative embedded systems. We highlighted the most distinct characteristics that distinguish them from classical systems. It is mainly their dynamicity that makes predicting their behavior difficult and therefore renders traditional safety certification techniques impractical. Based on these considerations, we presented new techniques and adaptations of existing techniques to enable a safety certification process that is specifically tailored to collaborative embedded systems.

We have outlined a two-step process. On the one hand, this process comprises the preliminary work during the design phase. All CESs are equipped with modular cases that contain an interface for integration with other safety cases. Since there are still many unknowns during the design phase, the second part of the safety certification process is performed at runtime, when all variables can be resolved. At runtime, the modular safety cases are integrated and evaluated according to the planned collaboration. Our concept comprises the monitoring of context changes at runtime and facilitates the handling of uncertainties. This enables a largely automated process that can be repeated efficiently during dynamic reconfigurations at runtime.

#### **8.6 Literature**

Symposium on Software Engineering for Adaptive and Self-Managing Systems, IEEE, 2015, pp. 146-156.

Flexible Production Systems. In: International Symposium on Model-Based Safety and Assessment, Springer, 2019, pp. 222–236.

**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.

Patricia Aluko Obe, University of Duisburg-Essen Jennifer Brings, University of Duisburg-Essen Marian Daun, University of Duisburg-Essen Linda Feeken, Offis e.V. Elham Mirzaei, InSystems Automation GmbH Martin Neumann, InSystems Automation GmbH Jochen Nickles, Siemens AG Simon Rösel, Model Engineering Solutions GmbH Markus Sauer, Siemens AG Holger Schlingloff, Fraunhofer FOKUS Ingo Stierand, Offis e.V. Jan-Stefan Zernickel, InSystems Automation GmbH

9

## Goal-Based Strategy Exploration

*When collaborative embedded systems(CESs) connect to form a group, this collaborative system group (CSG) can achieve goals that are beyond the reach of individual systems. The goals such a group can achieve depend on the constituent collaborative embedded systems. Consequently, the ability of a collaborative system group to adapt itself is driven by the capabilities of its collaborative embedded systems. This tight interconnection impedes the manual handling of adaptation strategies. Therefore, this chapter introduces a goal-based approach for strategy exploration that considers the peculiarities of collaborative system groups and collaborative embedded systems. The chapter sets out the model-based approach to adaptive system (group) design, incorporating the goals of collaborative system groups and individual systems, and outlines corresponding automated validation methods. We demonstrate the applicability of our approach for a case example of collaborative transport robots.*

#### **9.1 Introduction**

The development of collaborative embedded systems (CESs) faces challenges due to the high degree of complexity that results from the interplay of various CESs within a collaborative system group (CSG). CSGs are formed by CESs to achieve goals that individual CESs cannot achieve on their own. For example, collaborative autonomous transport robots (CESs) can form fleets (CSGs) to optimize the transportation of goods in a factory. In a CSG, it is not only the CESs that have goals; the CSG also has goals which in turn result from the goals of the CESs. However, the different goals may be partially contradictory. For example, an individual robot may be interested in conserving its battery life, while the fleet as a whole is interested in minimizing disruption in production. The decentralized organization and the dynamicity of such CSGs (for example, robots may join or leave the fleet during runtime) makes them highly complex and their development challenging. *Challenges*

*Goal-based strategy exploration*

> *Goals document objectives and rationales*

Therefore, we propose a goal-based approach for strategy exploration that considers the peculiarities of CSGs and CESs. In detail, we introduce a goal modeling approach tailored to the specification of goals for CESs and CSGs and show how strategies can be developed based on these goals and operationalized. We demonstrate the applicability of our approach for a case example from the industry automation domain. Specifically, we illustrate the impact that different strategies for a fleet of autonomous transport robots have on the fulfilment of goals by the individual robots.

#### **9.2 Goal Modeling for Collaborative System Groups**

Goal models are used—often in the early development phases—to document objectives that a system under development should achieve [van Lamsweerde 2001]. Goals typically document the rationales for more concrete and technical requirements, as well as design decisions [van Lamsweerde 2001], [Yu 1997]. For a recent overview of goal modeling, please refer to [Horkoff et al. 2017]. While several goal modeling languages have been proposed, we focus on the use of the Goal-oriented Requirement Language (GRL), which is part of the ITUstandardized User Requirements Notation [International Telecommunication Union 2012] and a good fit for CESs and CSGs (cf. [Daun et al. 2019], [Brings et al. 2020]).

GRL is based on the i\* framework [Yu 1997] but is less restrictive regarding the use of the notational elements (cf. [Horkoff et al. 2008]). GRL encompasses the use of actors to denote stakeholders that have some goals to be achieved by using a system under development that is, they may depend on other actors to achieve their goals. Most notably, in agent-oriented software engineering, actors are also used to model technical systems [Bresciani et al. 2004], as is the case here.

In GRL, the intentions of actors can be further specified by means of several types of intentional elements. Intentional elements are subdivided into (hard) goals, soft goals, tasks, resources, and beliefs, which are related via decompositions and contribution links. In the following, we illustrate how the use of goal modeling can foster the engineering of CSGs.

No reasonable system is supposed to behave absolutely arbitrarily. Each system has goals that it has to achieve. A CSG is formed through the cooperation of the CESs, therefore the goals of the CSG must be considered as early as during the design phase. The following distinction between goals is quite natural: we refer to *local goals* as goals of a CES and *global goals* as goals of a CSG. Global goals are goals that each CES of the CSG aims to achieve, while local goals are goals that represent the interests of individual CESs.

This allows us to separate goals of the CSG from goals of the CESs but also to denote relationships between both — for example, to identify where the CSG depends on the individual CESs in its goal fulfillment and vice versa. This is important information, as we will see later on that these dependencies drive design decisions and result in the definition of explicit strategies. Figure 9-1 shows an excerpt from the GRL goal model of an individual transport robot. The goal model emphasizes the transportation-related goals of the CESs. The goal model depicts the robots' responsibilities for route calculation, performing transport tasks, and bidding for transport tasks. For each robot, detailed sub-goals are derived that, for example, define how charging is to be handled and how robot breakdowns must be treated.

As we can see, the goal model specifies three important high-level goals (which are defined directly after the root node) regarding the safety of humans, conducting the transport, and the robustness of the robot. These goals are then refined until fine-grained tasks are reached, such as the tasks to determine obstacle positions and to communicate the obstacle's position. These goals identified for the individual robots are closely related to the overall goals of the CSG the fleet of robots—as each individual robot depends on the fleet of

*Goal-oriented Requirements Language Intentional elements Local goals and global goals CSG goals vs. CES goals Hierarchically structuring goals*

robots and vice versa. We investigated this issue in [Brings et al. 2019], [Brings et al. 2020] in more detail.

*Fig. 9-1: GRL goal model for the individual transport robots*

#### **9.3 Goal-Based Strategy Development**

Collaboration can enable embedded systems to achieve goals that cannot be achieved by a single system on its own. Having identified such goals (e.g., by using the approach from Section 9.2), one of the next engineering challenges is to develop behavior (or strategies) for the collaborating systems that will enable the goals to be achieved. In this section, we present concepts for going from identified goals towards behavior and we apply the concepts to an example in the use case of autonomous transport robots.

The goals of a CSG and of the individual CESs describe what the systems should achieve at runtime. In general, those goals are described in a way that is understandable for humans. There is no specification of the conditions under which the goals are achieved or how to identify goal fulfillment. For example, for a goal such as "the maintenance costs of the system group are minimized," at design time, there is no information about which maintenance costs are minimal but still realistic: maintenance costs of zero are desirable but this cannot be achieved in a dynamic system. Additionally, there is no specified point in time for checking whether this goal is fulfilled and, furthermore, it is not clear what measurements are needed to predict maintenance costs.

Key performance indicators (KPIs) are used to make goal fulfillment measurable: KPIs relate goals to observable system variables and measure the degree to which goals are fulfilled over time. Each goal is reflected by at least one KPI in order to enable assessment of the system behavior at each point in time with respect to the goals. We look at KPIs in more detail in Section 9.4.

We describe system behavior in terms of strategies: from a formal perspective, a strategy of a system is a function that maps the history of the system behavior and its context to a (new) valuation of the system variables. In other words, a strategy is an instruction for the system regarding how to behave in any situation it could face. When designing a collaborative embedded system, we aim for strategies that ensure the fulfillment of all goals "as well as possible," using KPIs to measure the degree of goal fulfillment.

Due to potential conflicts between goals and unpredictable context behavior, it is not always possible to find a strategy that fulfills all goals completely. Hence, we have to decide which strategy is the best match for the goals, even if there is no perfect solution. The definition of a quality measure for strategies supports this decision: a quality measure is a partial order relation on the set of all strategies for a

*Collaboration enables goal achievement*

*Starting with goals*

*Defining key performance indicators*

*Defining strategies*

*Conflicts*

system. In particular, a quality measure is a function that takes two strategies of a system and decides whether one of those strategies is better than the other one. Not all strategies are comparable, hence the quality measure is only a partial order. By deciding whether one strategy is better than another one, the quality measure resolves potential conflicts between goals — for example, by prioritizing the list of existing KPIs. The relationship between goals, KPIs, and quality measures is summarized in Figure 9-2.

*Fig. 9-2: Relationship between goals, KPIs, and quality measures of strategies*

In the following, we present a proof of concept example that illustrates the benefit of defining KPIs and quality measures based on goals for finding appropriate strategies.

In the use case of autonomous transport robots*,*  one of the key objectives is the transformation from a central fleet management to a decentral one. This requires a definition of how the robots distribute transport tasks among the fleet such that not only goals of individual robots, but also goals of the complete fleet, are fulfilled. In this example, we focus on the distribution of transport tasks and the global goal of having equal wear and tear among all robots of the fleet. This goal has industrial relevance, since it supports predictive maintenance and a reduction in maintenance costs for the robots since all robots can be maintained in a single appointment with a service team instead of needing a service team every time a robot reaches some given threshold for distance driven.

*Making goals measurable*

*Application to the autonomous transport*

*robots*

To make this goal measurable, we define a KPI for the difference between distances driven per robot. More precisely, we observe the difference between the robot with the least distance driven and the robot with the most distance driven. To keep the example simple, we omit additional KPIs that may also be relevant for the goal. We also focus on the decision on the distribution of transport jobs. Here, therefore, a strategy for a transport robot is determined completely by defining which transport tasks the robot takes over.

We define the quality measure for strategies as follows:

A strategy s is better than strategy u if the KPI "difference between the robot with the least distance driven and the robot with the most distance driven" after fulfilling a task is smaller (or equal) when applying s than when applying u.

We define three alternative strategies for task distribution among robots: *Alternative strategies*

Considering the quality measure introduced above, we can use examples to show that the first two strategies are not comparable. Furthermore, we can formally show that the third strategy is better than the first and the second one. This qualitative comparison can be complemented by a quantitative simulation-based comparison: we used a MATLAB model of the fleet of robots and generated 100 random topologies for the factory, each defined by the distances between relevant locations in the factory, such as machines, charging stations, and storage facilities. Each factory generated consists of 5 to 30 relevant locations. The distances between locations were chosen at between 5 and 50 meters. For each of those factory maps, we generated a list of 100 transport tasks between locations of the respective factory. Each of the three strategies for distributing the tasks among the fleet of robots was applied. The number of robots per fleet was chosen randomly as between 2 and 20. As the initial state of the fleet, each robot was randomly set to one of the locations, and an initial value for the distance already covered was chosen randomly as between 0 and 200 meters. After each task distribution, the difference between the minimum and maximum costs of the robots after fulfilling all tasks they took over was calculated according to the quality measure. The simulation showed the following results: *Comparing strategies*

1 In the simulation, we were able to verify that strategy 3 performs better than the two other strategies with regard to the quality measure defined above. Additionally, the  *Quality measures for*

*strategies*

simulation showed that strategy 1 and strategy 2 are not comparable.

2 As a quantitative result of the strategy comparison, we observed that the average differences between the maximum and minimum costs of robots of the same fleet is the smallest if the robots behave according to strategy 3: the mean cost difference between robots with strategy 3 is just 81% of the cost difference between robots with strategy 1, and just 88% of the cost difference between robots with strategy 2.

Figure 9-3 shows the evolution of the average difference between the highest and lowest costs of robots over the number of distributed transport tasks for the three strategies. The figure illustrates that strategy 3 performs the best with regard to minimization of cost differences. Strategy 1 has the least convincing performance.

*Fig. 9-3: Simulative comparison of cost differences for different strategies*

*Choosing strategies impacts fleet performance*

Our simulation shows that choosing the right strategy has a measurable impact on the performance of the fleet of robots. An explicit definition of a quality measure for strategies in the early design phase allows us to identify good strategies that had not been thought of before (here, Strategy 3, the best of the strategies considered, was introduced as a new strategy after the definition of the quality measure). Hence, considering strategies and quality  measures in the development of autonomous transport robots is a method that helps to improve the performance of the fleet significantly. In our evaluation, the fulfillment of the optimization goal "equal cost distribution among the fleet" has been improved by nearly 20%.

#### **9.4 Goal Operationalization (KPI Development)**

Developing a fleet of robots capable of performing transport jobs without central management necessitates good tracking of fleet/robot performance in fulfilling a set of goals.

The fleet of robots must fulfill multi-level goals. Some of the goals must be fulfilled absolutely, while others can be fulfilled in relation to other goals. This defines some kind of trade-off between these goals that have no conflicts with each other. In other words, the level of fulfillment of these goals must be measured and analyzed at runtime to evaluate the strategy performance that defines how and with which priority these goals must be accomplished.

In order to measure the fulfillment of the goals as well as determine how well the fleet/automated guided vehicle (AGV) is performing, we have to define KPIs. These KPIs serve as feedback data to the strategy components, which can lead to strategy adjustments to achieve better goal accomplishment if the present accomplishment is not good enough. In a multi-level goal system, it is helpful to categorize the KPIs. These categorizations are specific to a use case and would make it easier to define the trade-off between goals. In other words, this would give indications of the prioritization of such a goal, as well as of the definition of the interconnections between the goals and also the impact of not achieving them among each other. An example of KPI categorization for autonomous transport robots is as follows:

q Local/global KPI

q Historical/real-time KPI

#### **Definition 9-4***: Local KPIs*