Multi-protocol gateway for DERMS

Demonstration of a communications test environment for a DERMS gateway, by making use of: generic DER components, communication protocols, and their client/server implementations.


The distributed energy resource management system (DERMS) relies on gateway devices to pass multi-protocol messages between two types of remote networks: system operators (SCADA, DMS, microgrid controllers, etc) and one or more distributed energy resources (DERs). The remotely operated DER interfaces with the communication infrastructure via a remote terminal unit (RTU). Usually multiple protocols are used, since there are a multitude of equipment vendors and applications. The gateway devices must provide multi-protocol support for an efficient system integration. This application note 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. The example model does not implement an actual gateway device. Instead, the gateway is represented as a “black box” abstraction that provides data exchange between the SCADA client and the RTU. A TCP client is implemented in HIL SCADA and can send and read TCP messages to/from the DERMS. Additionally, the DERMS communicates with the RTUs, which are located in Schematic Editor and included in the generic UI components. As the best solution for implementation and testing communication protocols, generic components are used.

Figure 1: TCP and RTU communication through gateway

Model description

The model consists of a PV Power Plant (Generic) and a Battery ESS (Generic) to make a small microgrid connected to the Grid. These components are part of the Microgrid Toolbox. Additionally, a constant impendance load is included in the model.

Figure 2: Multiprotocol gateway example

You can modify UI blocks depending on your needs. In this example, these components are represented as Remote Terminal Units and are named depending on the communication protocol they use: RTU (Modbus SunSpec) and RTU (CAN Bus).

Figure 3: RTU Modbus SunSpec

Figure 4: RTU CAN Bus

On the mask of each UI block you can choose between two ways of control:
  • Model control, which allows for control by signal processing.
  • Communication, which allows for control over its communication protocol.

Figure 5: User Interface properties

If you choose control via communication, you must set the appropriate IP address with the RTU Modbus SunSpec component, since the CAN Bus is implemented as a loopback.


This model comes with a pre-built SCADA panel. It offers the most essential user interface elements (widgets) to monitor and interact with the simulation at runtime, allowing you to further customize it according to your needs.

Before simulation it is necessary to set the same Modbus IP address that you used in Schematic Editor in the SCADA Panel Model Intitalization file.

The SCADA panel consists of three groups of widgets:
  • Control room
  • Multiprotocol gateway
  • On-site measurements

Figure 6: SCADA panel

The control room is the part from where the TCP request is sent to the gateway. The gateway receives the TCP requests and sends them to the RTU meter which is represented in the On-site measurements group in this example. From On-site measurements, a RTU response is sent to the gateway, which forwards the TCP response to the control room.

Figure 7: Communication between the Control room and the RTU (Modbus Sunspec)

Figure 8: Communication between Control room and RTU(CAN Bus)

The Modbus SunSpec client implementation is done through the SCADA API during Panel Initialization, while the CAN bus client implementation is done by using CAN loopback. As mentioned in the introduction, the gateway device is an abstraction, hence there is no CAN/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.

Figure 9: Modbus client implementation

As is already mentioned, you can choose your model control mode and control these microgrid units via signal processing as shown in Figure 10.

Figure 10: Model control via signal processing

Figure 11: Battery control via signal processing

Table 1. Minimum requirements
Typhoon HIL files

examples\models\communication protocols\ generic microgrid with multi-protocol gateway

multiprotocol microgrid example.tse,

Minimum hardware requirements
No. of HIL devices 1
HIL device model HIL602+ or HIL404
Device configuration 1

Test Automation

We don’t have a test automation for this example yet. Let us know if you wish to contribute and we will gladly have you signed on the application note!


[1] Jovana Marković