Virtual Architecture Development and Simulated Evaluation of Software Concepts

The approach with its corresponding simulation and virtual validation framework FERAL (Framework for fast Evaluation on Requirements and Architecture Level) is a solution for virtual architecture development and simulated evaluation of software concepts. FERAL allows the design of virtual prototypes, which replace real prototypes by means of simulation and evaluate the impact of new architecture concepts in a cost-efficient manner. The solution enables simulation-based validation and the systematic assessment of design decisions at an early stage by coupling simulation models and simulators, existing code, and virtual hardware platforms.

Method Purpose Short description of the method's purpose and main benefits

Method description A detailed description of the method

With cyber-physical systems – communicating embedded systems that can autonomously adapt to their environment and learn new tasks – the challenges for system developers are growing because the CPS must evolve during runtime. This leads to completely new challenges regarding the architecture of these systems. As there is a lack of experience, the only way to evaluate new architecture concepts is the development of real prototypes. To select the best concepts, however, a great number of prototypes have to be realized. This causes very high costs and long development cycles.

The simulation and virtual validation framework FERAL (Framework for fast Evaluation on Requirements and Architecture Level) is a solution for virtual architecture development and simulated evaluation of software concepts. FERAL allows the design of virtual prototypes, which replace real prototypes by means of simulation and evaluate the impact of new architecture concepts in a cost-efficient manner. The solution enables simulation-based validation and the systematic assessment of design decisions at an early stage by coupling simulation models and simulators, existing code, and virtual hardware platforms.

Simulation may be based purely on models; this is called Model-in-the-Loop (MiL) simulation. For that purpose, FERAL supports e.g. UML state machines, activity diagrams, and coupling with other simulators such as Matlab Simulink. FERAL supports this step by providing virtual hardware platforms, i.e., processor and network models to which the software components can be deployed in a virtual Hardware-in-the Loop (vHiL) simulation. All these simulations (MiL and vHiL) serve to detect defects in early development phases, which allows reducing the number of expensive Hardware-in-the-Loop-(HiL) simulations and integration tests. FERAL is very suitable for the creation of complex, holistic test scenarios with inputs coming from different levels. It can, for example, process information from Simulink, Amalthea models, source code, architectural specifications, etc. With this technology, the planned contribution is twofold. One the one hand, IESE aims to use FERAL and support the generation of complex test scenarios for dedicated quality properties such as robustness and performance. On the other hand, by driving this simulation, it is possible to execute generated tests and follow the propagation of data of interest through the system

Method Strengths A listof the strengths of the method

Enables early verification of the appropriateness of design decisions by providing executable simulation scenarios
Provides technical solutions for coupling heterogeneous system parts (i.e. different implementation formats and maturity levels) and communication protocols
Reuses and connects existing simulation tools

Method Limitations The limitations of the method

Initial abstraction level-dependent efforts for creating simulation scenarios and simulation components
Trade-off between accuracy and effort for finding an appropriate simulation model quality

Method References Bibliography references to papers about the method.

[VAD1] T. Kuhn, T. Forster, T. Braun, R. Gotzhein: Feral - framework for simulator coupling on requirements and architecture level. ACM/IEEE MEMOCODE, pp. 11–22 (2013)
[VAD2] P. O. Antonino, J. Jahic, B. Kallweit, A. Morgenstern, and T. Kuhn: Bridging the Gap between Architecture Specifications and Simulation Models. IEEE International Conference on Software Architecture Companion, Seattle, WA, USA, pp. 77-80 (2018), DOI: 10.1109/ICSA-C.2018.00029.
[VAD3] A. Bachorek, F. Schulte-Langforth, A. Witton, T. Kuhn, P. Oliveira Antonino: Towards a Virtual Continuous Integration Platform for Advanced Driving Assistance Systems. IEEE International Conference on Software Architecture Companion, pp. 61-64 (2019), DOI: 10.1109/ICSA-C.2019.00018
[VAD4] T. Kuhn, P. O. Antonino, A. Bachorek: A Simulator Coupling Architecture for the Creation of Digital Twins. IEEE International Conference on Software Architecture Companion, pp. 326-339 (2020), DOI: 10.1007/978-3-030-59155-7_25

Method Dimensions

Evaluation Environment Type Type of environment where the method is applied. It can be more than one type of environment. (Dimension 1)

Evaluation Type Type of evaluation performed with that method. If a method is hybrid, more than one type can be selected. (Dimension 2)

Type of Component Under Evaluation Type of components that can be evaluated with that method. It can be more than one type. (Dimension 3)

Evaluation Stage The evaluation stage where the method is used. (Dimension 5)

Purpose of the Component Under Evaluation The type of purpose that can be evaluated by a method. It can be more than one type. (Dimension 6)

Type of Requirement Under Evaluation The type of requirements that a method is able to evaluate. It can be more than one type. (Dimension 7)

Evaluation Performance Indicator The type of evaluation criteria or KPI that a method is able to improve. It can be more than one type. (Dimension 8)

Relations

Related Methods A method could be related to other methods.

Tools A method can use zero or more tools.

Part Method A method (when it is a combination: Combination of method artefact that is a specialization of a V&V Method) could be composed of a set of V&V Methods.

Test Case or Verification and Validation activity Test Case or V&V activity performed in a Use Case. We will link to the method to the test cases where the method is used.

Standards A method can be linked with standards.

Context

Workflow

Contents

There are currently no items in this folder.