Simulation

For testing and validation purposes, PMP provides the concept of simulated controllers. By using processing blocks, the motion platform also enables the simulation of plants. This allows for software verification without the need for physical controllers or plants.

Controller

Simulated controllers simulate the behavior of a physical controller. A simulated controller is created from an XML controller description.

After creation, interfacing with a simulated controller is identical to interfacing with a physical controller. Equivalent to physical controllers, simulated controllers keep running when the user’s system instance is destroyed. To destroy a simulated controller explicitly, use the destroy or dispose functionality.

Note

Simulated sub-controllers are automatically destroyed when their parent controller is destroyed.

To create a simulated controller the user must provide settings to configure the simulated controller as well as settings to configure the simulator framework as described in the following sections.

Controller related settings

The controller related settings are used to configure the controller to be simulated.

Controller XML description

The controller description contains all features supported by the controller to be simulated, e.g. what actuators are available, what signals and events are available, etc.

Serial number

The serial number is used to set the value returned by IController’s HardwareSerialNumber property.

C#

IController.HardwareSerialNumber

C++

IController::GetHardwareSerialNumber()

ID

The ID is used to set the value returned by IController’s Id property.

Note

The provided ID is ignored when the controller XML description indicates the controller does not support an ID.

C#

IController.Id

C++

IController::GetId()

Simulator related settings

The simulator related settings are used to configure the simulator framework and allow the user to make a trade-off between CPU load and sample accurateness.

Note

Simulated sub-controllers inherit their simulator settings from their parent top-controller.

Simulator service address

The simulator service address defines the IP address or hostname of the simulator service on which the simulator is created. The setting can be used to select between running the simulator locally or on a remote server. The default value is set to localhost.

Simulator client address

The client address defines which clients can discover the simulator. The client address can either be, a hostname (which is resolved to a network address), a specific network address, or 255.255.255.255 (default value), which specifies that there is no IP restriction on the computer on which a client must run to discover the simulator.

Example cases for the client address are:

• 255.255.255.255: A client running on a computer with an arbitrary IP address can discover the simulator.

• 127.0.0.1 (localhost): The simulator is only discoverable via the local loopback, i.e. the simulator can only be discovered by clients running on the same computer.

• x.y.z.w: The simulator can only be discovered by the client(s) running on a computer with IP-address x.y.z.w.

CPU utilization

The CPU utilization defines how the simulator process claims CPU time. The list of available CPU utilization modes and their behavior is given in the following table:

CPU utilization mode	Description
Greedy	The simulator uses busy-waiting to fill idle time between calculation cycles to prevent the underlying OS from suspending the simulator process. The result is that each real-time thread claims all available calculation time of the CPU core it is deployed on, i.e. the most real-time performance achievable.
Modest	The simulator releases the CPU core for the duration of the required idle time between calculation cycles, hence the underlying OS is able to suspend the simulator process. The result is a more modest CPU load compared to greedy utilization at the expense of real-time performance.

Note

The default value is set to Greedy.

Real-time threads

The number of real-time threads defines the maximum number of threads that the simulator process is allowed to create to simulate the real-time behavior of a top-controller. Typically this value is equal to 1, to limit the CPU time claimed by the simulator process, or, equal to the actual number of real-time cores utilized by the physical top-controller, to achieve the most realistic simulation.

Note

• The default value equals 1.

• When the specified number of real-time threads exceeds the number of CPU cores of the platform running the simulator service, the simulator process uses the number of available CPU cores as the upper limit.

Speed factor

The speed factor defines an additional method of throttling the CPU time claimed by the simulator process and allows the user to make a trade-off between CPU load and sample-accurateness. It increases or decreases the number of samples the simulated top-controller computes in a given period of time. A higher speed factor can therefore significantly reduce the amount of time required to execute a simulated move without the need to adjust the control parameters. The default value equals 1.0, i.e. a simulated top-controller attempts to compute samples at the same rate as the physical top-controller that is simulated.

Note

The speed factor can be configured to a wide range of values, however the obtainable performance depends on the platform running the simulator service, i.e. CPU processing power, memory bandwidth, etc.

Multiple versions (Windows OS only)

PMP supports installing multiple versions of the motion platform when using the Windows OS. The location of each installation is stored in the Windows registry based on its release version. When creating a simulated top-controller, the version of the client library is communicated to the simulator service. The simulator service uses this version to determine the location of the corresponding installation from the Windows registry.

Creating simulated top-controller on Windows sequence

See also

Create a simulator

A guide to create a simulated system via PMP API.

Create a simulator

A guide to create a simulated system via PMP tooling.

System description

System description XML.

Controller description

Controller description XML.

Top-controller bus creation

On hardware top-controllers, it is possible for some buses to be physically absent from a controller. In this case, it is possible to mark a bus as optional in the top-controller model. If an optional bus is not physically present on the controller during startup, that bus will not be created.

On the simulator, which buses are created depends on the method by which the top-controller is created.

• Using the CreateController methods on ISystem, all buses contained in the top-controller model are created.

  C#

  ISystem.CreateController()

  ISystem.CreateControllerFromFile()

  C++

  ISystem::CreateController()

  ISystem::CreateControllerFromFile()

• As part of the CreateControllers methods on ISystem. In this case the bus creation depends on which Bus elements are present in the system description. If a bus is not marked as optional in the top-controller model, it will always be created. If a bus is marked as optional in the top-controller model, that bus will be created if the system description contains a bus element with the same name.

  C#

  ISystem.CreateControllers()

  ISystem.CreateControllersFromFile()

  C++

  ISystem::CreateControllers()

  ISystem::CreateControllersFromFile()

Sub-controller bus assignment

Similarly to hardware sub-controllers simulated sub-controllers are connected to a specific bus. Depending on how the sub-controller is created the sub-controller is either connected to a user-specified bus or to a bus determined by the top-controller.

There are 3 methods to create a simulated sub-controller:

• Using the CreateController methods on IBus, the IBus instance specifies the bus the sub-controller is connected to.

  C#

  IBus.CreateController()

  IBus.CreateControllerFromFile()

  C++

  IBus::CreateController()

  IBus::CreateControllerFromFile()

• Using the CreateController methods on IController the controller will determine which bus to connect the created sub-controller to according to the strategy described in Bus selection strategy.

  Note

  These methods are only provided for backward compatibility and are not recommended for new designs.

  C#

  IController.CreateController()

  IController.CreateControllerFromFile()

  C++

  IController::CreateController()

  IController::CreateControllerFromFile()

• As part of the CreateControllers method on ISystem. In this case the bus selection depends on where the Controller node is placed in the system description. If a sub-controller is nested under a Bus node, the sub-controller is connected to the specified bus. If a sub-controller is nested under a Controller node, the controller selects the bus using the strategy described in Bus selection strategy.

  Note

  Nesting a sub-controller directly under a Controller node is only provided for backward compatibility and not recommended for new designs.

  C#

  ISystem.CreateControllers()

  ISystem.CreateControllersFromFile()

  C++

  ISystem::CreateControllers()

  ISystem::CreateControllersFromFile()

Bus selection strategy

When the user does not specify a bus for a created sub-controller, the controller determines the bus to connect the sub-controller to as follows:

1. First all single sub-controller buses (i.e. buses that only support a single sub-controller) are considered, ordered by their default name. As soon as an empty single sub-controller bus is encountered that bus is selected to create the sub-controller on.

2. Once all single sub-controller buses have a connected sub-controller, multi sub-controller buses (i.e. buses that support multiple sub-controllers) are used, ordered by their default name, until their maximum capacity is reached.

C#

INamed.DefaultName

C++

INamed::GetDefaultName()