In the framework, the behavior of the collaboration function can be observed via the digital twin. Dynamic security builds confidence in the correspondence of the cooperation function with its abstract representation (Figure 10-5, phase 2).
Monitoring Collaborative Embedded Systems
The monitor can be an additional computational entity of the system or it can be part of every component in the system. A witness is an object that can be used in a formal argument for the correctness of the input-output pair.
Conclusion
236 Creating Trust in Collaborative Embedded Systems Intuitively, if the deadline extends beyond the end of the trace and φ is not satisfied until then, the truth value of ◇t φ reflects how much time is left to satisfy φ. That is, if the deadline extends beyond the end of the trace, then the truth value of □tφ reflects the "obligation" to obey φ for a long time; otherwise the truth value coincides with the classical meaning.
Literature
They can be used to express timing behavior as typically required for embedded systems. The images or other third-party materials in this chapter are included in the chapter's Creative Commons license, unless otherwise indicated in a credit line for the material.
Introduction
For some systems, it should be possible to perform a dynamic reconfiguration of their software architecture based on automata modes [Butting et al. In order to implement this correctly in the models, the company uses different versions of ADL - that is, versions of logical and technical views [Pohl et al.
MontiCore
Language embedding is the integration of selected productions from the client CFG into extensibility points of the host CFG. The resulting AST is the AST of the host CFG with a sub-AST of the client CFG embedded in selected nodes.
Language Components
For well-formedness control and code generation, MontiCore provides generic infrastructures that can be customized by adding well-formedness rules (context conditions) and FreeMarker templates [Forsythe 2013] that define code generation by processing ASTs using template control structures and target language text.
Language component
Language Component Composition
For the composition of language components, we generalize the concrete form of language composition and indicate that every composition of two language components is specified by a. In the context of language composition, we distinguish between intra-language and inter-language context conditions.
Language Product Lines
The variability of the language product line in terms of language features is modeled as a feature diagram, where language features are realized as language components. In addition, the binding configures the pairwise assemblies of language components that are common to all products of the language product line.
Conclusion
Literature
Baudry: Leveraging software production line engineering in the development of external DSLs: A systematic literature review. Embedded systems are increasingly equipped with open interfaces that enable communication and cooperation with other embedded systems and thus form Collaborative Embedded Systems (CES).
Introduction
- Motivation
- Benefits of Using Simulation
Regardless of the field, the use of simulation methods for evaluating the behavior of systems and system components has multiple benefits. As a seventh benefit, the use of simulation environments for testing embedded systems is particularly independent of external environmental influences and ensures that tests can be reproduced.
Challenges in Simulating Collaborative Embedded Systems
- Design Time Challenges
- Runtime Challenges
Also the other relevant aspects for the simulation scenario, such as the context or the dynamic behavior of the systems, must be covered. The exact structure of the CSG may not be available at design time and may be subject to dynamic changes.
Simulation Methods
Moreover, existing models should be combined to form an overall model of different aspects of the system and context. In the simulation phase, all signals of the function under test are recorded and stored in the register data.
Application
Combined with monitoring components, simulation can be used for runtime prediction of system behavior arising from runtime activation of system functions. When simulation platforms are implemented on CESs, the functional and timing interaction of a collaborative function with system functions and the functional and timing interactions between system functions can be predicted at runtime.
Conclusion
Building on the challenges and methods described in this chapter, simulation techniques have been developed that can be deployed at runtime.
Literature
The built-in models are often controlled by different tools that are specialized for specific simulation disciplines and must be executed jointly in a co-simulation. It motivates the need for co-simulation for CES development and describes a general tool architecture.
Introduction
Interaction of Different Simulations
In order to evaluate the behavior of the co-simulation participants, it is important that co-simulation results can be reproduced reliably. On the other hand, the importance and the quality of the test results can be limited for abstract models.
General Tool Architecture
To enable an instrument platform to support co-simulation, multiple instruments and models must be made interoperable. We have identified two standards as particularly relevant in the context of developing CESs and CSGs. These standards can be applied by instrument developers as a basis for setting up co-simulation features or in combination with existing proprietary solutions to extend instrument interoperability.
Implementing Interoperability for Co-Simulation
The co-simulation master controls the simulation course and is therefore responsible for the time synchronization between all involved co-simulation components. The first possibility is to use an external co-simulation master to set the timing.
Distributed Co-Simulation
First, DCP is specifically designed for the integration of real-time and non-real-time systems simultaneously. Thus, the specification provides a precise basis and guidance for the implementation of DCP on the master and slave side by tool developers.
Analysis of Simulation Results
Conclusion
Literature
In this sense, the behavior of collaborative embedded systems and collaborative system groups (CSGs) is part of a more complex behavior of digital ecosystems that form around the collaborative systems. One way to perform runtime virtual evaluation of such complex behavior is through the implementation of digital twins (DTs).
Introduction
Building Trust through Digital Twin Evaluation
- Demonstration
Other vehicles with the same objective (collaborative objective) can be members of the same platoon (assigned the role type. "Member"). By capturing system decomposition, our reference architecture forms the basis for creating a digital twin ecosystem.
Conclusion
When no flexibility of energy production is achieved, sanctions are applied in the form of closing the DER (risk associated with the strategic objective of providing a flexible amount of energy). The connection boxes must send their status at least once every 15 minutes (specification of the property of the "status broadcast frequency" property type in the contract of the "status broadcast" service).
Literature
The images or other third-party materials in this chapter are included in the chapter's Creative Commons license, . This chapter presents an approach for the online optimization of cooperative embedded systems (CESs) and cooperative system groups (CSGs).
Introduction
A Self-Optimization Approach for CESs
Specifically, in this phase the effect of the (optimal) configuration output of phase #2 is compared to the default configuration of the system. To perform the comparison, the two configurations are rolled into the system and values of the system output are collected.
Illustration on CrowdNav
Technically, the effect of experiments is compared by statistical testing (so far we have used t-tests) on relevant data sets of system outputs. The appeal value is generated based on travel overhead and random chance, so some of the.
Conclusion
Finally, CrowdNav finds itself in different situations depending on two context parameters that can be observed but not controlled: the number of regular (non-smart) cars and the number of smart cars. In this context, quickly finding a configuration of parameters that minimizes trip-overhead in a situation, while keeping the number of complaints in check, means understanding the effect a configuration has on both trip-overhead (the output we want to optimize for) and the complaint rate (the "bad events" metric).
Literature
Classical techniques for the formal modeling and analysis of distributed systems, however, are largely based on a static notion of systems and thus are often not suitable for the modeling and analysis of collaborative integrated systems. In this chapter, we propose an alternative approach that allows the verification of dynamically evolving systems, and we demonstrate it in terms of a working example: a simple version of an adaptable and flexible factory.
Introduction
Approach
To further support the development of interactive proofs, the approach comes with a framework to support the verification of dynamic architectures implemented in Isabelle [Marmsoler 2018b], [Marmsoler 2019c].
Example
- Specification
- Verification
If we use FACTum Studio to model our system, we can simply generate a model and corresponding verification conditions for the nuXmv model checker from the specification to automatically perform the verification. Again, if we use FACTum Studio for specifying the APML proof sketch, then we can automatically generate a corresponding proof for the interactive theorem prover Isabelle to check the reliability of the proof sketch.
Conclusion
Literature
Marmsoler: Model and verify dynamic architectures with FACTum Studio. eds) Formal aspects of component software. Schlingloff: Specification and Verification of Collaborative Transportation Robots, in 4th International Workshop on Emerging Ideas and Trends in Cyber-Physical Systems Engineering (EITEC), 2018.
Introduction
To address this challenge, artifact-based analysis automation allows system developers to model artifacts created during a project and automatically analyze their relationships and changes. We demonstrated the use of artifact-based analysis on the example of DOORS Next Generation (Doors NG) and Enterprise Architect (EA).
Foundations
CDs can be used in analysis to structure problem domain concepts, in addition to being used to represent a technical, structural view of a software system—that is, as a description of source code structures [Rumpe 2016]. In our approach, object diagrams are used to describe analysis data - that is, they reflect the current state of the project at a conceptual level.
Artifact-Based Analysis
OCL is a UML specification language that allows modeling additional constraints of other UML languages. For example, OCL can be used to specify invariants of class diagrams, conditions in sequence diagrams, and to specify pre- or post-conditions of methods.
Artifact
An important part of the overall approach is the identification of objects, tools, systems, etc. AM only defines types of elements and relationships and not specific cases; therefore, this model can remain unchanged throughout the life cycle of the process or project unless new types of elements or relationships are added or removed.
Artifact model
First, the types of objects, tools, and other elements of interest must be defined, as well as their relationships within a development process. It is the task of an architect, who is well informed about the whole process, to model these within an artifact model (AM).
Artifact data
If a new AM needs to be created or an existing AM needs to be modified, the AM core and parts of existing project-specific AMs must be reused. If all available artifact types are modeled, there is exactly one artifact type that is not contained in a container, which is the root of the file system.
Artifact reference
Artifact contribution
- Artifact Model for Systems Engineering Projects with Doors NG and Enterprise Architect
- Artifact Modeling of Doors NG and Enterprise Architect The creation of the artifact model for this example includes the
- Static Extractor for Doors NG and Enterprise Architect Exports
- Analysis of the Extracted Artifact Data
- Conclusion
- Literature
- Introduction
- Product Line Engineering
- Propagating Updates from Domain Engineering Level to Application Engineering Level
- The Challenge of Propagating Updates
- Artifact Evolution and Co-Changes
- Changes to the Variant Derivation Process
- Applicability and Limitations
- Implementation
- Propagating Changes from Application
A decisive advantage of the artifact models is that not all possible artifacts need to be modeled; the model can be limited to the artifacts relevant to the analysis. However, in the extracted artifact data, the part p1 assigned to the requirement r1 is the source of the referenced signal flow s1.
Engineering Level to Domain Engineering Level
The Challenge of Lifting Changes
Our goal is to lower the barrier to adopting changes to variants in . product line development by supporting the propagation of changes from a variant's working copy to the product line. We propose a process that detects changes in the working copy of a variant, then maps them to the relevant features and transfers them semi-automatically to the product line.
A Process for Lifting Changes
To this end, in the second step, we label the assets at the AE level with feature information. In the following, we focus on the second and third steps, which we present in more detail.
Deducing Feature Information
The availability of feature mapping at the AE level depends on the mutability mechanism and the versioning process. If feature information is part of the implementation artifacts at the AE level, then even assigning changes to features can be trivial, as application engineers can directly make changes to the scope of the corresponding feature.
Applicability and Limitations
An example of the latter is transitions between two states of an automaton that refer to their source and target states. Finally, the accuracy of the recommendations depends on the granularity of the underlying model, the maturity of the analysis and the different algorithms used.
Conclusion
Furthermore, domain engineers must still manually merge changes into product line artifacts, as recommendations only provide a general idea of which features particular changes can be applied to. Developers must integrate the change propagation process into the product line's development process and define how conflicts across variants should be resolved.
Literature
In: Proceedings of the Tenth International Workshop on Variability Modeling of Software-Intensive Systems, ACM, 2016, p 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, provided that the original author(s) and source are properly acknowledged, a link to the Creative Commons license is provided, and , whether changes have been made.
Introduction
Advanced Systems Engineering
Using development models for further evolution and during operation (from system model to digital twin). New types of cost structures, higher development costs relative to lower production costs due to often dramatically higher variability.
MBSE as an Essential Basis
An instance of the system model is managed, which is then consistently stored in this form in a central model repository ("single point of truth"). The level of formalization of the models defined in the system model determines the level of automation of analyzes and model generation.
The Integrated Approach of SPES and SPES_XT
Modeling the system at different levels of granularity defines the subject of discourse (scope) and is one. In addition to abstraction and granularity, robustness is an important feature of models in the SPES framework.
Methodological Extensions: From SPES to ASE
Extending the SPES framework to aspects such as dynamic networking and runtime system collaboration in the CrEST project; To this end, a number of additional interrelated themes were defined, as well as the models of existing perspectives were supplemented. Until now, the development of the SPES framework has focused exclusively on the product development process.
Conclusion
Integrating AI components into embedded systems leverages the significant potential of current and future AI technologies into embedded systems. Therefore, a central challenge for the integration of AI methods in embedded systems is the guarantee (verifiability) of the essential functionality and quality properties of the systems - and this despite the fact that the components of the system cannot be fully specified and are often non-deterministic or even dynamic due to adaptations of the systems at the time of execution that could not be predicted at the time of development.
Literature
Holger Fraunhofer Institut for åbne kommunikationssystemer FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Tyskland Schmalzing, David RWTH Aachen University Software Engineering Ahornstr.
Bertrandt GmbH
Expleo Germany GmbH
FEV Europe GmbH
Fraunhofer Institute for Open Communication Systems FOKUS
Fraunhofer Institute for Experimental Software Engineering (IESE)
Helmut Schmidt University Hamburg
Humboldt-Universität zu Berlin
INCHRON AG
InSystems Automation GmbH
Model Engineering Solutions GmbH
OFFIS e.V
PikeTec GmbH
Typical projects cover requirements, configuration and version management issues, as well as software architecture and design. As product line and version management is a relatively new field, ongoing research and development is an important part of a clean systems strategy.
Robert Bosch GmbH
Hence since 2006 pure-systems has also been actively involved in national and European research funding projects (SAFE, ESPA, feasiPLE, DIVa, VARIES, SPES XT, ReVAMP², INLIVE, CRESt) and has supported a number of research projects by providing resources (CESAR, AMPLE, VOBATESSOFT2, CRYSTALSFT2, CRYSTAL).
RWTH Aachen University
The MontiCore programs developed at the chair allow the agile and compositional development of modeling languages, as well as their use for analysis, synthesis and generative software development. Hardware-in-the-loop and real-time co-simulations play a key role in the development of test and validation methods for future vehicles, including powertrains as well as ADAS/AD systems of interacting and cooperating vehicles.
Siemens AG
In the field of automotive software engineering, the chair has a long history of research projects and industrial collaborations with major OEMs. In research centers located in many different countries, CT works closely with the R&D teams in the Siemens divisions.
Technical University of Kaiserslautern
The CT organization provides expertise in strategically important areas for securing the company's technological future and obtaining patent rights that protect the company's operations.
Technical University of Munich
Technische Universität Berlin – Daimler Center for Automotive Information Technology Innovations (DCAITI)
The DCAITI staff participates in academic life at the Technische Universität Berlin through teaching assignments and student support. The center encourages students to participate in its projects and gain first-hand experience in automotive electronics in the center's own garage.
Technische Universität Braunschweig
University of Duisburg-Essen, paluno – The Ruhr Institute for Software Technology
Në: Proceedings of the 17th International Conference on Generative Programming: Concepts and Experiences (GPCE), 2018, pp. In: Proceedings of the International Conference on Software Maintenance and Evolution (ICSME), Madrid, Spain, 2018, pp.
