Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

BaSyx / Documentation / Implementation / ControlComponentSimulation

This information is work in progress as part of the BaSys 4.2 project. This section is preliminary and subject to change during the project.

Overview | Interface | Implementation

Process Simulation within the Java-based Control Components SDK

With the Java-based SDK for control components, control components can be implemented as "virtual devices" (i.e. without a PLC) for real use as well as for simulation. First, we are looking at a typical configuration of a control component, in this case for the automated guided vehicle MiR100.


The executionMode specifies the initial execution mode of the control component on start-up. This can be either SIMULATE or AUTO. If disableExecutionModeChange is set to true, the inital execution mode cannot be changed. Helpful during virtual and real commissioning which involves simulation is the possibility to bypass the occupation automaton of the control component by setting disableOccupationCheck to true.

Due to the modular architecture of the framework, a simulation mode can be realized in 4 different ways, each with different simulation depths.

1. Dedicated control component implementation for simulation
By specifying a different implementationJavaClass, a different control component implementation, e.g. specifically for simulation purposes, is loaded. Since a control component implementation in the SDK only specifies the set of available operation modes, the same could also be achieved with the next alternative - however, in a less exclusive manner.
2. Dedicated operation modes for simulation
Inside a control component implementation, an different set of operation modes can be registered for different execution modes, e.g. AUTO and/or SIMULATE.
3. Mock-up service for simulation
The serviceImplementationJavaClass typically specifies a service implementation for interacting with the real device in the AUTO execution mode. When in simulation mode, calls to this service implementation are cut off. Instead, a service mock-up is created based on the underlying service interface that simulates calls to the service. This allows for rather shallow behavior simulation in an elegant manner with the possibility to also inject errors. Such a control component can typically be switched between AUTO and SIMULATE execution modes. This is currently our preferred way implementing control components that support both real interaction with a device and also process simulation capabilities.
4. Dedicated service implementation for simulation
By specifying a different serviceImplementationJavaClass, a different service implementation is loaded on start-up. Here, a service implementation that encapsulates e.g. a functional mock-up unit (FMU) for deep physical simulations could be supplied. The resulting control component only exists for simulation purposes. Thus, the initial executionMode must be set to SIMULATE. Also, disableServiceMock must be set to true in order to prevent the behavior described in the previous section.

Back to the top