Simulation Framework “FERAL” for Virtual Engineering

Task

• Architecture analysis
• Response time analysis

Software lockstep on consumer processors (ARM)

• Simulates tasks, deployment, runtimes, scheduling
• Processing times and jitter per task
• Injected defects during calculation and on bus
• Evaluates network load, response times, behavior

Remote control of a hydraulic lift (anonymized application)

• Remote control of the safety function via smartphone or Wi-Fi
• Virtual evaluation of the system- and safety concept prior to implementation
• Gradual integration of models (specification) and C/C++ code (realization)

Prototype for system architecture

• High-level models similar to UML/SysML
• Executable and unambiguous
• Synchronizes different domains

Coordination among developers

• High-level & implementation interfaces
• Data flows in the system
• Main features

Refinement and integration

• Change impact analysis
• Change management support

Business case and requirements

• Charging time of vehicles
• Activation of participants
• Delivery times for packages

Application concepts

• Application architecture and application functions
• Main components and interfaces
• Inclusion of new services and new infrastructure

Virtual test bed for applications

• Evaluation and prediction of performance
• Based on variables and available services
• Early evaluation of new concepts

• The integration of software components and systems might lead to unexpected and undesired emergent behavior.
• FERAL enables virtual integration in order to evaluate emergent behavior. System-wide assurances guarantee the absence of non-conformant behavior. Integration is supported on different levels of abstraction, which include specifications and realizations.

Image sources: https://icons8.com/

• Shifting functions between control units changes the timing. This impacts the timing of other functions, the times at which data are supplied and used, as well as the network communication.
• FERAL evaluates whether a distributed algorithm is still stable. In a single environment or in all system configurations.

• Complex software systems consist of components that are developed independent of each other.
• Architects and developers assume the existence of interfaces and basic behavior.
• Informal descriptions lead to misunderstandings. Executable prototypes enable more precise descriptions, which support early and continuous testing of specifications and realizations.
• FERAL enables continuous conformance testing with component specifications, the simulation of Use Cases and interactions, as well as the mixing of high-level specifications with implementations.

• Software ecosystems must fulfill the requirements of numerous stakeholders.
• The virtual prototypes of FERAL describe the realization of stakeholder requirements. They are integrated with real entities, create virtual development and deployment environments, and enable early testing of concepts and what-if analyses.

Holistic simulation of the functional system behavior across tool boundaries

• Evaluation across abstraction levels – joint evaluation of high- and low-level system concepts
• Automated script-based testing and monitoring of the achieved test coverage
• System-wide assurances; automatic comparison between actual and expected behavior

Simulation of the deployment of functions on (multicore) ECUs (Electronic Control Units)

• Simulates the behavior after deployment (tasks, priorities, scheduling & interrupts, parallelization mechanisms)
• OSEK-/AUTOSAR-conformant scheduling strategies
• Virtual sensors and actuators communicate with the simulated environment
• Existing behavior models do not need to be changed to check the capacity of processor cores and the effects of communication delays by means of vHiL simulations

A functional network defines

• Functions
• Ports and information flows
• FERAL additionally defines the execution semantics

Challenge: The functional network is defined only in part

• Some functions are implemented
• Some functions have specified behavior
• Some functions only have names & ports

Iterative refinement of functions possible

• Interaction occurs in a message-based manner via ports and links
• Function blocks can get behavior assigned to them

Supported behavior models

• UML/SysML: sequences, state machines, activities
• Java & Groovy, as well as C/C++ code
• Simulink models

The execution of incompletely specified functional networks is supported

• Not specified functions realize situation-dependent default behavior
• For example, “Filter X should filter this signal” is possible even if the implementation of the function Filter X does not exist yet

A mixture of differently defined behavior components is possible

• As well as the integration of other existing tools

Eclipse-based expert tool

• Uses Groovy-based domain-specific language for configuration
• Xtext and graphical frontends are planned