Frequently Asked Question
Press "Ctrl + F" to find the keyword of your interest.
If you wish to have a direct link access to the video timestamps, please follow these instructions.
Found this video helpful? Why not take the whole HIL Specialist course? A Certificate is waiting for you for free at HIL Academy.
Would you or your organization benefit from having these videos narrated in your native language? Contact us and let us know if you wish to contribute.
TRANSCRIPT
Hello everyone. In this lesson we will learn how to implement a communications
test environment for a distributed energy resource management system gateway.
We will do this by using the Multi-protocol gateway example in the Examples Explorer.
This example comprises both a CAN bus and a Modbus SunSpec protocol implementation within a single
HIL device. It is an example of what a complete microgrid system model might look like in the
Typhoon HIL toolchain, with both the power stage and communication layers modeled simultaneously.
Modbus Sunspec is an application-layer communications protocol designed to achieve
interoperability between Distributed Energy Resource components and smart
grid applications, based on the Modbus standard. Information in SunSpec is defined through a set of
Information Models representing functionality implemented by devices or plants. SunSpec
Alliance Interoperability Specifications describe how these information models,
data exchange formats, and communication protocols are used in distributed energy resource systems.
Let s open the model now.In general, distributed energy resource management
systems, or DERMS, rely on gateway devices to pass multi-protocol messages between two types of
remote networks: system operators, such as SCADA, Data Management Systems, or microgrid controllers;
and one or more distributed energy resources, or DERs. The remotely operated DER interfaces
with the communication infrastructure via a remote terminal unit, or RTU.
Usually, multiple protocols are used in microgrid setups, since there are
a multitude of different equipment vendors and applications. That s why gateway devices must
provide multi-protocol support for efficient system integration and interoperability.
This example model shows you how to model a communications test environment for a DERMS
gateway, by making use of generic DER components, communication protocols,
and their client/server implementations. It is important to mention that this example model
does not implement an actual gateway device. Instead, the gateway is represented as a black
box abstraction that manages data exchange between the SCADA client and the Remote Terminal Units.
A Modbus TCP client is implemented in HIL SCADA and can send and read messages to and from the
DERMS. Additionally, the DERMS communicates with the RTUs, which are in the Schematic
Editor model and included in the generic User Interface components. Generic components are
used here to represent the Microgrid model and as the best solution for implementation
and testing of communication protocols.Now let s look at the model and detailed
explanation about how this example is implemented.
The model consists of a PV Power Plant (Generic) and a Battery ESS (Generic) component to simulate
a small microgrid connected to a Three Phase Grid and a constant impedance load, representing the
grid demand. For more information on generic DER components, and how you can use them yourself,
please check back to the dedicated lessons and the license notice in the HIL Fundamentals course.
In this example, the User Interface components are represented as Remote
Terminal Units and are named depending on the communication protocol they use:
Remote Terminal Unit Modbus SunSpec and Remote Terminal Unit CAN Bus.
Let s take a Look Under the Mask of each of these components to see how we can
implement each communication protocol so that it connects to the model.
For RTU Modbus SunSpec, we can see the Modbus SunSpec Device component present there.
All the measurements from the model that we want to read in the remote
SCADA are connected to the left side of the component, and the variables that we want
to control from the SCADA are connected to the right side of the component.
Let s open the Modbus SunSpec component to check how we configure it.
As you can see, the configuration is similar to the standard Modbus Server,
that s because the SunSpec Modbus Device component in Typhoon HIL Schematic Editor
is implemented in a similar way to the Modbus components we covered in earlier lessons.
The network configuration remains the same as in the Modbus Server.
The main difference is in the Register Configuration. Registers of the Common
model are automatically created and are predefined in the Common model tab. Here
it is possible to specify the Manufacturer, Model, and Serial number of the SunSpec device.
After switching to the Standard Models tab, you can specify what Standard Models the server will
support. Clicking the Add Standard Model button, a list of all Standard Models will
be presented where a specific model can be selected. Each selected model appears as a
separate tab. As you can see here, we have added Immediate Controls and Inverter tabs.
The immediate controls function block includes the following: connect and disconnect from the grid,
adjust maximum generation level up and down, adjust power factor and adjust fixed VAR delivery.
It is possible to select which variables we want to include from the predefined variables and
control them from the model via signal processing inputs and outputs by selecting them like here.
From this block we select the variables we want to control from the Modbus client directly
to the PV plant. This will include output terminals to the Modbus Sunspec component.
The Inverter Three Phase function block includes
measurements and commands related to the PV inverter such as Voltage,
Current, Power, Frequency, and Temperature measurement and controls.
For this example, we want to select from the Inverter model the variables: AC Power,
Line Frequency, AC apparent power, and AC reactive power. With this setup we can read those variables
from the PV plant, in the model, in the Modbus Client remote SCADA. Also, this will add input
terminals to the Sunspec device that can be connected to the signal processing measurements.
The order of the models can be easily changed by dragging and dropping a model tab to the desired
position like shown here. The register addresses will be automatically updated.
The Vendor Models tab is the same as Standard Models tab with the difference that after
clicking the Add Vendor Model button, a browser window will be presented where any vendor model,
with an ID between 65000 and 65535, can be imported.
After the register map is configured, on OK button,
validation of the initial values will occur and if the validation passes, a configuration is
created and written in the configuration property of Modbus Device component.
Here in the component mask we can also see all the input and output terminals that
were configured for this example.Now let s go to the RTU CAN Bus,
which is connected to the Battery storage system.Under the mask of the RTU CAN Bus, we can see a
loopback of CAN controllers implemented using 2 sets of CAN Send and CAN Receive components.
All variables parsed to the first CAN controller are sent back to the second CAN controller,
which then sends them back to the model. The main idea here is to exercise the CAN
communication in the same device in order to check data integrity. In order for that
to work it is important to physically connect the CAN1 and CAN2 controller via a loopback.
Coming back to the root of the model, the component settings of each UI block let you choose
between two ways of control: Model control, which allows for control by signal processing and SCADA
inputs, or communication, which allows for control over the implemented communication protocol.
In the case of the Modbus Sunspec component, we can also setup the network from here.
Before we compile, we should mention that this model can be executed only on HIL404
and supported HIL 6-series devices, since HIL402 doesn t have the CAN bus hardware capability.
Now, let s compile the model and go to the SCADA panel.
The Modbus SunSpec client implementation is done through SCADA API during Panel Initialization.
This means that before running the simulation we need to set the same Modbus IP address
that we used in Schematic Editor in the SCADA Panel Model Initialization file.
By doing this, we can connect the Modbus Client SCADA API to the Modbus Server in the HIL device.
To recall, this procedure was covered in the previous lesson on Modbus Client SCADA API.
Let s do this now.
The SCADA panel consists of three groups of widgets: the Control room,
the Multiprotocol gateway, and On-site measurements.
The control room is the part where the Modbus Client TCP requests are sent to the gateway.
The gateway receives the requests and sends them to the RTU meter, which is represented
in the On-site measurements group in this example here. From On-site measurements,
an RTU response is sent to the gateway, which forwards the TCP response to the control room.
As mentioned in the introduction, the gateway device is an abstraction,
hence there is no CAN or ethernet converter modeled for the client-side.
The client-server CAN bus messaging is realized via a direct physical loopback
between two CAN controllers on the HIL device. In this example the CAN bus is connected to the
battery storage system, which can represent Battery Management System communication.
Let s interact with the model and see how we can control our plant using this remote approach.
It is important to first verify the IP address of the Modbus Client at the panel initialization,
here you can see how to change this.After we click to run the simulation,
if all the communications are properly working, you will see the animation that
represents the information flow from the SCADA to the On-site measurements and vice-versa.
Now it is possible to control directly the PV plant and the battery. The PV plant is
controlled via Modbus requests and the Battery via CAN bus messages (from the loopback connection).
You can turn on and off the battery inverter, enable or disable the PV inverter,
and connect or disconnect the grid and the load.It is also possible to choose if you want to
command the plant directly from SCADA inputs or from the communication protocols implemented.
Also, if you double click the Control room widget, you can see all the measurements
performed by the Modbus Client for the PV plant on the right side, and the measurements for
the battery by the CAN bus at the left side.Getting back to the SCADA root panel, you can
access the Battery ESS interface and the PV plant interface directly and check the measurements that
are read on site, they should be the same as the ones read remotely in the Control Room widget.
With this, we ve covered the basic features of the multi-protocol gateway example.
For more information on other use cases of this multi-protocol gateway application, check out the
Application Note in the Materials tab.
Thank you for watching!
