Processor-in-the-Loop
As a separately licensed feature, PLECS offers support for Processor-in-the-Loop (PIL) simulations, allowing the execution of control code on external hardware tied into the virtual world of a PLECS model.
At the PLECS level, the PIL functionality consists of a specialized PIL block that can be found in the Processor-in-the-loop library, as well as the Target Manager, accessible from the Window menu. Also included with the PIL library are high-fidelity peripheral models of MCUs used for the control of power conversion systems.
On the embedded side, a PIL Framework library is provided to facilitate the integration of PIL functionality into your project.
Motivation
When developing embedded control algorithms, it is quite common to be testing such code, or portions thereof, by executing it inside a circuit simulator. Using PLECS, this can be easily achieved by means of a C-Script or DLL block. This approach is referred to as Software-in-the-loop (SIL). A SIL simulation compiles the embedded source code for the native environment of the simulation tool (e.g. Win64) and executes the algorithms within the simulation environment.
The PIL approach, on the other hand, executes the control algorithms on the real embedded hardware. Instead of reading the actual sensors of the power converter, values calculated by the simulation tool are used as inputs to the embedded algorithm. Similarly, outputs of the control algorithms executing on the processor are fed back into the simulation to drive the virtual environment. Note that SIL and PIL testing are also relevant when the embedded code is automatically generated from the simulation model.
One of the major advantages of PIL over SIL is that during PIL testing, actual compiled code is executed on the real MCU. This allows the detection of platform-specific software defects such as overflow conditions and casting errors. Furthermore, while PIL testing does not execute the control algorithms in true real-time, the control tasks do execute at the normal rate between two simulation steps. Therefore, PIL simulation can be used to detect and analyze potential problems related to the multi-threaded execution of control algorithms, including jitter and resource corruption. PIL testing can also provide useful metrics about processor utilization.
How PIL Works
At the most basic level, a PIL simulation can be summarized as follows:
Principle of a PIL simulation
- Input variables on the target, such as current and voltage measurements, are overridden with values provided by the PLECS simulation.
- The control algorithms are executed for one control period.
- Output variables on the target, such as PWM peripheral register values, are read and fed back into the simulation.
We refer to variables on the target which are overridden by PLECS as Override Probes. Variables read by PLECS are called Read Probes.
While Override Probes are set and Read Probes are read the dispatching of the embedded control algorithms must be stopped. The controls must remain halted while PLECS is updating the simulated model. In other words, the control algorithm operates in a stepped mode during a PIL simulation. However, as mentioned above, when the control algorithms are executing, their behavior is identical to a true real-time operation. We therefore call this mode of operation pseudo real-time.
Let us further examine the pseudo real-time operation in the context of an embedded application utilizing nested control loops where fast high-priority tasks (such as current control) interrupt slower lower-priority tasks (such as voltage control). An example of such a configuration with two control tasks is illustrated in the figure below. With every hardware interrupt (bold vertical bar), the lower priority task is interrupted and the main interrupt service routine is executed. In addition, the lower priority task is periodically triggered using a software interrupt. Once both control tasks have completed, the system continues with the background task where lowest priority operations are processed. The timing in this figure corresponds to true real-time operation.
Nested Control Tasks
The next figure illustrates the timing of the same controller during a PIL simulation, with the stop and go symbols indicating when the dispatching of the control tasks is halted and resumed.
Pseudo real-time operation
After the hardware interrupt is received, the system stops the control dispatching and enters a communication loop where the values of the Override Probes and Read Probes can be exchanged with the PLECS model. Once a new step request is received from the simulation, the task dispatching is restarted and the control tasks execute freely during the duration of one interrupt period. This pseudo real-time operation allows the user to analyze the control system in a simulation environment in a fashion that is behaviorally identical to a true real-time operation. Note that only the dispatching of the control tasks is stopped. The target itself is never halted as communication with PLECS must be maintained.
PIL Modes
The concept of using Override Probes and Read Probes allows tying actual control code executing on a real MCU into a PLECS simulation without the need to specifically recompile it for PIL.
You can think of Override Probes and Read Probes as the equivalent of test points which can be left in the embedded software as long as desired. Software modules with such test points can be tied into a PIL simulation at any time.
Often, Override Probes and Read Probes are configured to access the registers of MCU peripherals, such as analog-to-digital converters (ADCs) and pulse-width modulation (PWM) modules. Additionally, specific software modules, e.g. a filter block, can be equipped with Override Probes and Read Probes. This allows unit-testing the module in a PIL simulation isolated from the rest of the embedded code.
To permit safe and controlled transitions between real-time execution of the control code, driving an actual plant, and pseudo real-time execution, in conjunction with a simulated plant, the following two PIL modes are distinguished:
- Normal Operation - Regular target operation in which PIL simulations are inhibited.
- Ready for PIL - Target is ready for a PIL simulation, which corresponds to a safe state with the power-stage disabled.
The transition between the two modes can either be controlled by the embedded application, for example based on a set of digital inputs, or from PLECS using the Target Manager.
Configuring PLECS for PIL
Once an embedded application is equipped with the PIL framework, and appropriate Override Probes and Read Probes are defined, it is ready for PIL simulations with PLECS.
PLECS uses the concept of Target Configurations to define global high-level settings that can be accessed by any PLECS model. At the circuit level, the PIL block is utilized to define lower level configurations such as the selection of Override Probes and Read Probes used during simulation.
This is explained in further detail in the following sections.
Target Manager
The high-level configurations are made in the Target Manager, which is accessible in PLECS by means of the corresponding item in the Window menu. The target manager allows defining and configuring targets for PIL simulation, by associating them with a symbol file and specifying the communication parameters. Target configurations are stored globally at the PLECS level and are not saved in *.plecs or Simulink files. An example target configuration is shown in the figure below.
Target Manager
The left hand side of the dialog window shows a list of targets that are currently configured. To add a new target configuration, click the button marked + below the list. To remove the currently selected target, click the button marked -. You can reorder the targets by clicking and dragging an entry up and down in the list.
The right hand side of the dialog window shows the parameter settings of the currently selected target. Each target configuration must have a unique Name.
The target configuration specifies the Symbol file and the communication link settings.
The symbol file is the binary file (also called "object file") corresponding to the code executing on the target. PLECS will obtain most settings for PIL simulations, as well as the list of Override Probes and Read Probes and their attributes, from the symbol file.
Communication Links
A number of links are supported for communicating with the target. The desired link can be selected in the Device type combo box. For communication links that allow detecting connected devices, pressing the Scan button will populate the Device name combo box with the names of all available devices.
Serial Device
The Serial device selection corresponds to conventional physical or virtual serial communication ports. On a Windows machine, such ports are labeled COMn, where n is the number of the port.
FTDI Device
If the serial adapter is based on an FTDI chip, the low-level FTDI driver can be used directly by selecting the FTD2XX option. This device type offers improved communication speed over the virtual communication port (VCP) associated with the FTDI adapter.
TCP/IP Socket
The communication can also be routed over a TCP/IP socket by selecting the TCP Socket device type.
TCP/IP Communication
In this case the Device name corresponds to the IP address (or URL) and port number, separated by a colon (:).
TCP/IP Bridge
The TCP Bridge device type provides a generic interface for utilizing custom communication links. This option permits communication over an external application which serves as a "bridge" between a serial TCP/IP socket and a custom link/protocol.
Target Properties
By pressing the Properties button, target information can be displayed as shown in the figure below.
Target Properties
In addition to reading and displaying information from the symbol file, PLECS will also query the target for its identity and check the value against the one stored in the symbol file. This verifies the device settings and ensures that the correct binary file has been selected. Further, the user can request for a target mode change to configure the embedded code to run in Normal Operation mode or in Ready for PIL mode.
PIL Block
The PIL block ties a processor into a PLECS simulation by making Override Probes and Read Probes, configured on the target, available as input and output ports, respectively.
PIL Block
A PIL block is associated with a target defined in the target manager, which is selected from the Target combo box. The Configure… button provides a convenient shortcut to the target manager for configuring existing and new targets.
PIL Block General Tab
The execution of the PIL block can be triggered at a fixed Discrete-Periodic rate by configuring the Sample time to a positive value. As with other PLECS components, an Inherited sample time can be selected by setting the parameter to -1 or [-1 0].
A trigger port can be enabled using the External trigger combo box. This is useful if the control interrupt source is part of the PLECS circuit, such as an ADC or PWM peripheral model.
Typically, an Inherited sample time is used in combination with a trigger port. If a Discrete-Periodic rate is specified, the trigger port will be sampled at the specified rate.
Similar to the DLL block, the Output delay setting permits delaying the output of each simulation step to approximate processor calculation time.
Note Make sure the value for the Output delay does not exceed the sample time of the block, or the outputs will never be updated.
A delay of 0 is a valid setting, but it will create direct-feedthrough between inputs and outputs.
PIL Block Inputs Tab
The PIL block extracts the names of Override Probes and Read Probes from the symbol file selected in the target configuration and presents lists for selection as input and output signals, as shown in the figure above.
The number of inputs and outputs of a PIL block is configurable with the Number of inputs and Number of outputs settings. To associate Override Probes or Read Probes with a given input or output, select an input/output from the combo box on the right half of the dialog. Then drag the desired Override Probes or Read Probes from the left into the area below or add them by selecting them and clicking the > button. To remove an Override Probe or Read Probe, select it and either press the Delete key or < button.
Note It is possible to multiplex several Override/Read Probe signals into one input/output. The sequence can be reordered by dragging the signals up and down the list.
Starting with PLECS 3.7, the PIL block allows setting initial conditions for Override Probes.
Also new with PLECS 3.7 is the Calibrations tab, which permits modifying embedded code settings such as regulator gains and filter coefficients.
PIL Block Calibrations Tab
Calibrations can be set in the Value column. If no entry is provided, the embedded code will use the default value as indicated in the Default column.