What is FERAL

FERAL is a platform designed for quickly creating simulation and virtual evaluation tools. It primarily connects simulators and models using various Models of Computation and Communication (MOCC).

As a simulation and virtual engineering platform, FERAL enables customized simulation solutions for tasks such as bus performance evaluation, system simulation, and virtual qualification. It operates as a library of components that are set up and linked through a simulation script, similar to SystemC.

Written in Java, FERAL minimizes low-level coding while leveraging a modern programming language that matches the performance of contemporary C++ compilers.

Virtual Engineering¶

Hardware-in-the-Loop (HiL) testing evaluates embedded systems by using a combination of real hardware and real-time simulations to mimic the system's environment. This setup allows testing with the actual hardware and software of the system under test (SuT).

FERAL enhances this process with Virtual HiL (vHiL) testing, which replaces real-world components with simulations. This approach allows earlier testing in the development cycle and can vary in accuracy. It helps in evaluating architectural decisions and performing basic integration tests early on, reducing the likelihood of defects later and lowering costs compared to physical HiL setups.

Figure 1 shows a typical vHiL setup, where the SuT includes simulated bus communication, electronic control units (ECUs), and a test bus simulation. Components not explicitly modeled in the virtual system but present in the real system are covered by the test bus simulation, with other simulated system instances connected via WiFi.

Image title — Figure 1. Example vHiL Environment

Figure 2 illustrates a component view on the vHiL environment from Figure 1. The SuT is simulated by a detailed system simulation that contains explicit simulation models for selected ECUs, as well as a simulated Controller Area Network (CAN) bus. A detailed network simulation connects one additional system, while a (regular) network simulation connect additional system simulations.

This illustrates a basic problem of vHiL and complex system and architecture simulations in general. Simulators are focused, and only represent a fraction of the real-world system. A communication simulator for example implements a simulation model for one network type, but does not provide simulation models for other aspects of the system.

FERAL was designed as a platform to enable the rapid development of tailored simulation solutions. It defines a core that supports the coupling of simulation models, as well as simulation models that enable the development of virtual system prototypes on different levels of abstraction.

Especially when designing smart ecosystems, systems that will participate with smart ecosystems, and open, and adaptive systems, existing HiL platforms will no longer be sufficient as development and testing platforms. The virtualization of these complex real-world systems is a major goal of FERAL.

Features¶

FERAL offers the following primary features:

Models of Computation and Communication¶

Simulators and simulation models conform to their Models of Computation and Communication. These control behavior and communication semantics. Common MOCCs for simulation include discrete time, discrete event, and continuous time semantics (cf. Figure 3).

Discrete time (DT) MOCCs split the execution into discrete time steps of constant or variable size. They support for example the implementation of discretized physics models and control algorithms. Input ports under control of a DT MOCC store one value that may change between time steps, but that is kept constant during time steps of a simulation. Output ports communicate simulation results at the end of a time step. The MOCC executes controlled components in any order. The duration of a time step dstep reflects the granularity of the simulation; shorter time steps yield higher accuracy, but also require more frequent calculations and more computation time. Larger time steps require less calculations but yield a higher discretization error.

Discrete event (DE) simulation models implement event based communication and the processing of simulation events. Events may occur at any time and are not bound to time steps. Their execution is ordered based on expiration times. This ensures that the simulation time in discrete simulation models continuously increases, but requires overhead for the necessary sorting of event. Simulation components receive events via their input ports. Discrete event simulation models are used for example for the simulation of software concepts, and for communication systems.

Continuous time (CT) simulation approximates the continuous behavior of real-world physics. Changes to individual elements have immediate impacts to dependent elements. For example, when a spring is extended, it immediately applies force to both ends. Resembling this behavior in a simulation is tricky, as necessary discretization of the simulation prior to solving yields a simulation error. Every CT simulation is controlled by a solver that evaluates one simulation component after another in discrete time steps. After simulating one component, it copies output values to the inputs of dependent components. Solvers control simulation errors by iterating the same simulation step until the simulation error falls below an acceptable threshold.

MOCC Coupling¶

FERAL was developed with the rationale of coupling individual and focused simulation models into a holistic simulation. The FERAL core therefore focuses on providing a framework for implementing and coupling Models of Computation and Communication (MOCC) that define how a simulation is executed and how it communicates. The MOCC coupling approach is derived from the Ptolemy approach [Eker03] that first did propagate the hierarchical coupling of MOCC to enable heterogeneous execution models.

The integration of heterogeneous execution models is the foundation of simulator coupling. Today, simulators focus on the simulation of one or very few aspects of a system. As systems are getting more complex, they interact in a more complex way with their environment. Software ecosystems for example consist of numerous systems that execute on hardware platforms, communicate with each other, and implement complex algorithms for interacting with physics and with each other. Simulation of such a complex system requires to cover all relevant aspects of the ecosystem. A single simulator is not able to do this. Therefore, simulator coupling becomes necessary for the development of simulation solutions that enable for example the virtual testing of implementations, the virtual prototyping of algorithms, and the virtual evaluation of architecture concepts.

Simulator coupling enables the integration of simulators, simulation models, and other implemented behavior into one semantically integrated simulation. This is necessary to overcome limitations of existing simulators that are specialized, and therefore focus on a limited number of effects only.

Figure 4 illustrates the simulator coupling that yields a virtual prototype for an antilock brake by wire function in automotive systems, showing the software components and their data dependencies. To create a simple virtual prototype of the system, all software components must be linked into a holistic simulation. The four illustrated software components were created either with Simulink, the C programming language, or are provided as FMU. They implement four functions of an antilock braking system (ABS): RunWSS implements the wheel slip sensor, RunBS the brake sensor, RunABS the ABS controller, and RunBA the brake actuator. These components are linked to an environment model that simulates the system's reactions and closes the loop. Evaluation of the functional system behavior requires the integrated execution of all these components, integrating their models of computation and communication (MOCC).

In detail, Figure 4 illustrates several executable components, either part of the system under test or the simulated environment (component Env). Each component is part of a domain that defines its MOCC. From a simulation viewpoint, all these components are executable components (runnables) that need to be executed according to their MOCC to provide meaningful results. A MOCC defines when a runnable is executed and how it communicates. The example uses Discrete Time and Discrete Event MOCCs to create simulation domains that control the execution of contained runnables. Discrete Time Domains split the execution of controlled runnables into discrete time steps, while Discrete Event Domains generate events for arrived messages and timers, controlling the runnables' execution according to these events.