OER000001403-1.pdf

The "Collaborative Embedded Systems" (CrESt) project, funded by the German Federal Ministry of Education and Research (BMBF)1, is the successor to the two SPES projects. First of all, we would like to thank the project partners and their employees, who contributed with great dedication to the development of the project results.

Introduction

Vehicle Platooning

In the simplest scenario, PFV2 should join the rear of the pack - in other words, behind FV1. Assessment of the quality of the platoon regulation concept, particularly in terms of safety and reliability.

Fig. 1-1: SysML use case diagram “Platoon Membership”

Adaptable and Flexible Factory

Finally, the mapping of the process to modules and the topological layout of the process in the factory must be flexible. The MES assigns each specific step of the production process to an individual production module and adjusts the flow between the production lines accordingly.

Fig. 1-2: Process sequences “Quadrocopter” – order of assembly

Autonomous Transport Robots

Here we think of transport robots as individuals with goals, foresight and an awareness of the other robots in the fleet. A more advanced option would allow path planning based on traffic conditions and the assumed paths of the other robots.

Fig. 1-4: Central and decentralized fleet management

Introduction

Background

This applies in particular to the presence and disappearance of elements in the operational context as well as the adaptation of the system interface at runtime. At the same time, this transition leads to a jump in the complexity of the systems in question.

Collaborating Embedded Systems

Collaborative and Collaborating Systems
Goals of System Networks
Coordination in System Networks
Dynamics in System Networks
Functions

If there are conflicts – for example, between the general goals of the CSG and the individual goals of the participating CES – they must be resolved. Coordinated execution of CES system functions creates behavior that realizes CSG function.

Fig. 2-2: Goals, functions and architectures in collaborative system groups

Problem Dimensions of Collaborative Embedded Systems Systems

Challenges Related to Collaboration

CESs should be designed in such a way that they can function in conceptually conceived types of CSG. To this end, these systems must be able to make their system functions available to the CSG and - also in terms of quality - communicate them with other CESs at runtime.

Challenges Related to Dynamics

Finally, the CSG must be able to select available alternative system functions according to defined criteria. In particular, they must be able to detect changes in their operational context and CSG and adapt their interfaces accordingly.

Application in the Domains “Cooperative Vehicle Automation” and “Industry 4.0” Automation” and “Industry 4.0”

Challenges in the Application Domain “Cooperative Vehicle Automation”

The entry of Auto E into the peloton may lead to adjustments of the community goals (soft goals) of the peloton. With the entry of car E into the peloton, the context changes for the peloton as well as for car E and the preceding vehicles of the peloton.

Challenges in the Application Domain “Industry 4.0”

In order to realize the cooperation of modules for the joint production of a product, many challenges must be faced. Information on the sequence of module functions to be performed is determined based on the production order.

Fig. 2-6: Overview of collaboration in order-driven production

Concepts and Methods for the Development of Collaborative Embedded Systems Collaborative Embedded Systems

Enhancements Regarding SPES2020 and SPES_XT

Collaboration

Based on these extensions of the modeling framework, specific methods have been developed to achieve collaborative goals. For example, it is important to share information about the specific capabilities of individual CES members.

Dynamics

With the approaches developed in CrESt, community goals can now be negotiated dynamically at runtime. For this purpose, the quantification of the uncertainty regarding the output of data-driven components (eg the recognition of a traffic sign) is enabled at runtime.

Conclusion

Literature

Plattform Industrie 4.0 2017a] Plattform Industrie 4.0: Application scenario in practice: Made-to-order controlled production of a customized bicycle handlebar. Hönninger (ed.): Advanced Model-Based Engineering of Embedded Systems: Extensions to the SPES2020 Methodology, Springer, Heidelberg/New York, 2016.

Appendix

Cooperative systems are characterized by their interaction with other systems in cooperative system groups in order to achieve a common goal. In order to enable knowledge preservation and reuse for designing system architectures for flexible collaborative systems and system groups, we present a method for designing reference architectures for systems and system groups.

Introduction

Designing Reference Architectures

Method for Designing Reference Architectures

Further requirements are then derived for the reference architecture based on the decisions made above. Once the reference architecture is created, we can use it to derive system architectures for future systems.

Application Example: Reference Architecture for Adaptable and Flexible Factories

Since only one requirement has changed, we still want to use the reference architecture for this factory. We also used the reference architecture for a factory model demonstrator to derive a specific logic system architecture and define a technical architecture on top.

Fig. 3-3: Refinement of CSG for adaptable and flexible factories

Simulation-Based Operator Assistance
Design Decisions
Technical Reference Architecture
Workflow of Services and Data Flow
Application Example for an Adaptable and Flexible Factory

Therefore, we want to present a technical reference architecture that can support the development of such assistance systems. The concept of a reference architecture for an operator assistance CES will be outlined in the following.

Fig. 3-4: General technical architecture for an operator assistance system

Checkable Safety Cases for Architecture Design

Checkable Safety Case Models – A Definition

Verifiable security case models include verifiable and unverifiable argumentative fragments that are interconnected. On the other hand, verifiable security case fragments include a set of interconnected specialized security case elements.

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

Checkable Safety Case Patterns

Specialized security case elements refer to certain types of system model elements or contain metadata related to certain authentication approaches. Automated checks: the checks that can be performed on the security case fragments produced after the instantiation of the pattern.

An Example of Checkable Safety Case Patterns

Figure 3-9 shows a snippet of a GSN-based security case that argues system architecture model checking with NuSMV model checking against system security properties defined as contracts. Given the specialized elements of the security case contained in the pattern and their integration with system models and verification tools, the validity of the argumentation fragment resulting from the instantiation of the pattern is automatically checked if there is a change in the corresponding system architecture model.

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

Conclusion

Due to space constraints, the figure shows only part of the argumentation, namely the argumentation legs regarding the proper implementation of the sub-components of the architecture. In conclusion, we propose to create verifiable safety case patterns that argue about the implementation of safety features by a system architecture that can also be based on a certain reference architecture.

Literature

The images or other third-party material in this chapter are included in the chapter's Creative Commons license, unless otherwise indicated in a credit line for the material. The evolution from traditional embedded systems to dynamically interacting, collaborative embedded systems increases the complexity and number of requirements involved in the model-based development process.

Introduction

Methodological Approach

Requirements for the function metamodel

Background

A syntactic interface describes a set of input and output channels and the types of messages these channels carry across a system boundary. Histories of message flows through input and output channels capture the behavior of the system interface.

Metamodel for Functions of CESs and CSGs

Systems, CESs, and CSGs
Functions
Goal Contribution and Fulfillment
Roles
Context and Adaptivity

Pohl et al. 2016]) which is therefore part of the larger functional architecture of the CSG. The system context describes the surrounding environment that is not part of the system.

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

Evaluation of the Metamodel

Abstraction

If the adaptation is manually activated by an external user or administrator (a human takes the role of an adaptation logician), then this is referred to as a system reconfiguration. In contrast, if adaptation is triggered and executed by the system itself, in an automated manner, without any user interaction, then we call it self-adaptation [Petrovska et al.

Req.1

Relationships between Functions

Req.2

Openness and Dynamicity

Req.3

Goal Contributions

Req.4

Relationships Between Functions and Systems

Req.5

Input/Output Compatibility

Req.6

Runtime Restructuring

Req.7

Application of the Metamodel

Example from the Adaptable and Flexible Factory
Modeling of Goals for Transport Robots

In the context of the metamodel, individual RPKs can be considered as CESs and CTFRs as CSGs. The individual CTR tasks presented here correspond to system functions in the metamodel.

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

Related Work

In his model, he considered a function as an intermediate step between system behavior and user intent. Several frameworks have been proposed in the literature to systematically define a well-formed functional behavior of the system.

Conclusion

Josephson 2000]: 1) considering the functions of systems that affect their environments, especially in our case the context as a relevant part of the environment; 2) as well as other systems involved in the collaboration, including their internal system parameters, states and behavior. To our knowledge, there has been no previous work on modeling functions for CES from multidimensional perspectives as proposed in our metamodel, including the dynamism of system contexts, role and goal modeling, and the complex properties of these systems. such as collaboration and flexibility.

Literature

If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulations or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. Dynamically linked collaborative embedded systems operate in groups that form, change, and dissolve—often frequently—during their lifetime.

Introduction

The analysis method makes it possible to assess the impact on the safety of failures of the communication medium. The methods are illustrated in the context of "Vehicle Platooning" and "Autonomous Transportation Robots".

Specification Modeling of the Behavior of Collaborative System Groups Collaborative System Groups

Additionally, time is an explicit concept that can be used to control the temporal aspects of a scenario. The proven concept of Protocol State Machines (PSMs) [Franca 2019] allows the dynamic behavior of system interfaces to be specified and can be used to ensure that the involved communication peers interact in the correct order.

Modeling CES Functional Architectures

Scenario
Modelling
Analysis

The lower part of Figure 5-9 shows the realization of the functions in the logical architecture. The analysis is essentially a refinement check that fails if the architecture model cannot "follow" the scenario specification, that is, where either the expected events do not occur (eg, a bot's hasToFulfill event), or the events occur unexpectedly (hasToFulfill event from multiple bots).

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

Extraction of Dynamic Architectures

Methods
Software Product Line Engineering
Product-Driven Software Product Line Engineering Product-driven software product line engineering is a form of reactive
Family Mining — A Method for Extracting Reference Architectures from Model Variants
Summary

The check whether the functionality fulfilled by the software component variant is also fulfilled by a software component of the reference architecture is performed in the activity "Comparison with reference architecture". The activity "Comparison with extrinsic similarities" analyzes the similarity of the components based on structural and.

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

Functional Safety Analysis (Online)

Functional Testing
Communication Errors

If the system under test is given incorrect data, the behavior of a reliability check can be verified. By creating the ability to modify communication between several cooperating integrated systems, undetected errors can be injected.

Fig. 5-14: Software simulation — schematic representation

Conclusion

In this figure, instead of sending information directly from CES 1 to CES 2, the information is sent to the test solution and then forwarded to CES 2. If this flag is set from the modeled test case, an additional modeled error value can be passed to CES 2 instead of the actual value from CES 1.

Literature

When modeling these tests, an additional flag can be added to bypass some signal values before passing them to CES 2 as part of the test modeling. 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 form. , as long as you give proper credit to the original author(s) and source, provide a link to the Creative Commons license, and indicate if changes have been made.

Introduction and Motivation

Solution Concept

Then, in Section 6-4, we describe how to develop decision methods based on these models and runtime information. This allows the generated models to be integrated into executable models that can be used for system analysis.

Ontology and Modeling

Ontology Building
Capability Modeling
Variability Modeling for Context-Sensitive Reconfiguration
Scenario-Based Modeling

The evolving system for which capabilities are to be modeled provides input for expanding the domain capability model. This is especially important if a system performs a reconfiguration or re-parameterization, as this usually implies changes in system capabilities (see section 6.3.3.

Fig. 6-4: Method for creating capability models

Model Integration and Execution

Model Generation for Simulation Models
Capability Matching

Therefore, 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. For further information on the views presented and the principles of the matching method, refer to [Daun et al.

Fig. 6-12: Knowledge graph for factory simulationLayout

Conclusion

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

Literature

Because collaborative embedded systems operate autonomously in highly dynamic contexts, they must be able to handle uncertainties that may arise during operation. The methods also enable graphical and formal modeling of uncertainties and their influence on system behavior (e.g. during dynamic traffic scenarios).

Uncertainty in Collaborative Embedded Systems

Conceptual Ontology for Handling Uncertainty
Different Kinds of Uncertainty

Below we take a closer look at these challenges to illustrate different types of uncertainty that can arise during the operation of CESs. Data-related uncertainty: This type of uncertainty is caused by limitations in the results of data-driven components (DDCs).

Fig. 7-1: Core ontology for describing uncertainty

Modeling Uncertainty

Orthogonal Uncertainty Modeling
Modeling Uncertainty in Traffic Scenarios

Uncertainty can be caused by epistemic concerns related to the representation of the information exchanged and processed by CESs (see Section 7.3.1). Rationale This element describes the root cause of the uncertainty - that is, the source that originally introduces uncertainty.

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

Analyzing Uncertainty

Identifying Epistemic Uncertainties
Assessing Data-Driven Uncertainties

Increase DownhillRecuperation', the SUC may understand the first two elements, but not the last, as it is not an electric vehicle. StateOfCharge,” the SUC may understand the first element, but not the second and third, as these are concepts specific to an electric vehicle.

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

Conclusion

Finally, uncertainty wrappers can simplify data-driven model security evaluations by providing not only statistically defensible uncertainty estimates at a required confidence level, but also by promising more comprehensible estimates from domain and security experts. , as they decouple uncertainty analysis from the "black box". as most data-driven models are still considered.

Literature

Collaborative embedded systems, however, are designed to integrate and collaborate with other systems dynamically at runtime. In the next chapter, we introduce new techniques to meet this challenge and describe a security certification concept tailored specifically for collaborative embedded systems.

Introduction and Motivation

Nevertheless, we consider it essential to do 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 manner. The remainder of this chapter is structured as follows: Section 8.2 provides a brief overview of the proposed safety certification process.

Overview of the Proposed Safety Certification Concept Concept

This information can, for example, come from a human integrator that controls the CESs (adaptive factory) or can be generated by a machine, for example from on-board computers (vehicle platooning). This can be done on a contract basis by providing and requiring guarantees for exchanged services.

Assuring Runtime Safety Based on Modular Safety Cases

For each failure mode in the product recipe, a measure of the detectability (Det) by scheduled quality measures is also given. 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).

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

Design and Runtime Contracts