Hierarchical Dynamic Load Management

1. Hierarchial DLM

Efficient load distribution and control are critical when managing power across multiple Distributed Load Management (DLM) systems, particularly when several systems rely on a limited power supply. The need arises to coordinate these systems while maintaining safety and optimizing performance.

As power demand grows, such as when multiple Charging Stations or other devices such as DC chargers are added, it becomes harder to share power safely and avoid overloading the system.

The Hierarchical Dynamic Load Management (Hierarchical DLM) helps by enabling a central Charge Controller to oversee several DLM systems, each with its own Master Charge Controller. It gathers information about power use, applies limits, and adjusts power sharing in real time. This ensures power is distributed safely and efficiently, starting from the main power source down to individual DLM systems.

1.1. Hardware parts

The Hierarchical DLM system consists of several components, each with a specific role:

Chargers Chargers are elements that consume current and can also vary their current consumption to comply with the coordinator requests. In a “pure” setup each charger is also a participant. In a “hybrid” setup, only “masters” are participants- “slaves” are not because they do not directly communicate with the coordinator.

External loads External loads consume current but cannot be controlled. The DLM system must adjust the charger to compensate for the loads. When external loads are present, there must be corresponding external meters to be able to estimate their contribution to the network.

External meters External (i.e. standalone) meters are set up to measure the external loads. There are two types of connections:

in-line The meter is on the line itself and measures all current passing through.

branch The meter only measures the external load.

1.2. Creating the constraint file

The constraint configuration file defines the setup for a Hierarchical DLM system. It controls power distribution, monitors current limits, and manages the load across multiple Charging Stations and electrical lines.

Naming Scheme Objects in the DLM system (electrical lines, meters and participants) should have a name that is unique within each category. Names have the same restrictions as domain names:

• Between 1 and 63 characters.
• Can contain only alphanumeric characters and dashes (no spaces).
• Cannot start nor end with a dash.

The main components of this file are:

1. ID
2. Lines
3. Groups
4. Meters

1. ID The id is an optional field that serves as an identifier for the configuration file. It's used to validate that the daemons have loaded the correct file by matching it with the Constraints Id property in status messages.

2. Lines The lines section defines the different electrical lines and their maximum current ratings across three phases (L1, L2, L3). Each line can be described with its CurrentLimit and Parent property.

• Root Line: The root line (e.g., main) represents the connection to the utility grid and is the central bus for the entire system.
• Child Lines: Other lines like line1, line2, etc., branch out from the root and inherit properties from their parent unless explicitly defined.

For example:

   "lines": {
       "main": {
           "CurrentLimit": {
               "L1": 40,
               "L2": 40,
               "L3": 40
           }
       },
       "line1": {
           "CurrentLimit": {
               "L1": 32,
               "L2": 32,
               "L3": 32
           },
           "Parent": "main"
       },
       "line2": {
           "CurrentLimit": {
               "L1": 20,
               "L2": 20,
               "L3": 20
           },
           "Parent": "main"
       },
       "line3": {
           "CurrentLimit": {
               "L1": 20,
               "L2": 20,
               "L3": 20
           },
           "Parent": "main"
       }
   },

line1 has a parent line called main and a specific CurrentLimit.

Handling External Loads:

In-line Loads: Use the ExternalLoadCurrent property for any line with external loads connected directly. For example:

{
 "$comment": "Branch load example",
 "lines": {
     "main": {
         "CurrentLimit": { "L1": 20, "L2": 20, "L3": 20 },
         "ExternalLoadCurrent": { "L1": 20, "L2": 20, "L3": 20 },
     }
 },
 "groups": {
     "test": {
         "Elements": ["c1", "c2", "c3", "c4"],
         "Parent": "main"
     }
 },
 "meters": {
     "a1": {
         "Model": "EEM-MB371",
         "Parent": "main",
         "Interface": {
             "Type": "modbus-tcp",
             "IPAddress": "192.168.1.53",
             "TCPPort": 1505
         }
     }
 }
}

Branch Loads: Create a virtual line without chargers that contain ExternalLoadCurrent to manage these loads separately. For example:

{
 "$comment": "Branch load example",
 "lines": {
     "main": {
         "CurrentLimit": { "L1": 20, "L2": 20, "L3": 20 }
     },
     "main-h1": {
         "CurrentLimit": { "L1": 20, "L2": 20, "L3": 20 },
         "ExternalLoadCurrent": { "L1": 20, "L2": 20, "L3": 20 },
         "Parent": "main"
     }
 },
 "groups": {
     "test": {
         "Elements": ["c1", "c2", "c3", "c4"],
         "Parent": "main"
     }
 },
 "meters": {
     "a1": {
         "Model": "EEM-MB371",
         "Parent": "main-h1",
         "Interface": {
             "Type": "modbus-tcp",
             "IPAddress": "192.168.1.53",
             "TCPPort": 1505
         }
     }
 }
}

3. Groups The groups section defines participants (e.g., Charging Stations) that are connected to each line. Instead of specifying each participant individually, they are grouped together based on shared properties.

For example:

   "groups": {
       "deck-1": {
           "Elements": ["F1A", "F1B", "F1C"],
           "Parent": "line1"
       },
       "deck-2": {
           "Elements": ["F2A", "F2B", "F2C"],
           "Parent": "line2"
       },
       "deck-3": {
           "Elements": ["F3A", "F3B", "F3C"],
           "Parent": "line3"
       }
   },

4. Meters The meters section defines any external Modbus TCP meters that monitor the system's load.

Key Properties:

• Model: Specifies the meter model.
• Parent: Identifies the line that the meter is connected to.
• Interface: Provides the communication method with fields like Type (e.g., modbus-tcp), IPAddress, and optional TCPPort and SlaveID.

For example:

    "meters": {
       "Main": {
           "Model": "EEM-MB371",
           "Parent": "main",
           "Interface": {
               "Type": "modbus-tcp",
               "IPAddress": "10.1.2.3"
           }
       },
       "parkingLotLight": {
           "Model": "EEM-MB371",
           "Parent": "line3",
           "Interface": {
               "Type": "modbus-tcp",
               "IPAddress": "10.2.3.4"
           }
       }
   }
}

This defines a meter monitoring the main line.

info

There can be used more than one meter. For a list of compatible meters click here.

Final Setup

{
   "$schema": "./constraints.schema.json",
   "lines": {
       "main": {
           "CurrentLimit": {
               "L1": 40,
               "L2": 40,
               "L3": 40
           }
       },
       "line1": {
           "CurrentLimit": {
               "L1": 32,
               "L2": 32,
               "L3": 32
           },
           "Parent": "main"
       },
       "line2": {
           "CurrentLimit": {
               "L1": 20,
               "L2": 20,
               "L3": 20
           },
           "Parent": "main"
       },
       "line3": {
           "CurrentLimit": {
               "L1": 20,
               "L2": 20,
               "L3": 20
           },
           "Parent": "main"
       }
   },
   "groups": {
       "deck-1": {
           "Elements": ["F1A", "F1B", "F1C", "F1D", "F1E"],
           "Parent": "line1"
       },
       "deck-2": {
           "Elements": ["F2A", "F2B", "F2C"],
           "Parent": "line2"
       },
       "deck-3": {
           "Elements": ["F3A", "F3B", "F3C"],
           "Parent": "line3"
       }
   },
   "meters": {
       "Main": {
           "Model": "EEM-MB371",
           "Parent": "main",
           "Interface": {
               "Type": "modbus-tcp",
               "IPAddress": "10.1.2.3"
           }
       },
       "parkingLotLight": {
           "Model": "EEM-MB371",
           "Parent": "line3",
           "Interface": {
               "Type": "modbus-tcp",
               "IPAddress": "10.2.3.4"
           }
       }
   }
}

1.3. Settings

1.3.1. Enabling Hierarchial DLM

Location in Config UI	Parameter	Value	Info
LOAD MANAGEMENT > Hierarchical Dynamic Load Management	Hierarchical Dynamic Load Management - DLM Coordinator	Enabled (with local MQTT broker)	Exactly one controller in the hierarchical DLM network must be selected to run the MQTT broker along with the DLM coordinator
		Enabled (with remote MQTT broker)	All controllers in the hierarchical DLM network must be set to "Enabled (with remote MQTT broker)." For this, you need to specify the IP address or hostname of the controller hosting the MQTT broker (refer to the "Enabled (with local MQTT broker)" setting mentioned earlier).

1.3.2. General Settings

Location in Config UI	Parameter	Value	Info
LOAD MANAGEMENT > Hierarchical Dynamic Load Management	TCP port of the MQTT broker	8883	The TCP port has to be the same for all participating controllers of the hierarchical DLM network. The default setting is set to 8883.
	Unique address of the DLM master used in the hierarchical DLM		Each participating controller of the hierarchical DLM network has to have a unique address corresponding to the entries from the constraints.
	DLM master fallback current		If a DLM master loses connection to the MQTT broker or DLM coordinator, a fallback current can be set. This serves as the maximum current for managing its connected DLM slaves across three phases (L1, L2, L3), ensuring continued load regulation and preventing overloads during the disconnection.

1.3.3. Uploading the constraint file

Location in Config UI	Parameter	Value	Info
LOAD MANAGEMENT > Hierarchical Dynamic Load Management	Publish constraints for DLM coordinator	On	Under Constraints used for hierarchical DLM place the json file.

2. Deep dive into the constraint file

Lets dive into the example constraint file we introduced above:

tip

Hover over the elements in the diagram to see the constraints.json equivalent.

Here's a visual representation of the constraint file:

• The diagram is simplified to focus on the hierarchical DLM aspect
• It is assumed that all Charge Controllers and Meters are connected to the same network

{
   "$schema": "./constraints.schema.json",
   "lines": {
       "main": {
           "CurrentLimit": {
               "L1": 40,
               "L2": 40,
               "L3": 40
           }
       },
       "line1": {
           "CurrentLimit": {
               "L1": 32,
               "L2": 32,
               "L3": 32
           },
           "Parent": "main"
       },
       "line2": {
           "CurrentLimit": {
               "L1": 20,
               "L2": 20,
               "L3": 20
           },
           "Parent": "main"
       },
       "line3": {
           "CurrentLimit": {
               "L1": 20,
               "L2": 20,
               "L3": 20
           },
           "Parent": "main"
       }
   },
   "groups": {
       "deck-1": {
           "Elements": ["F1A", "F1B", "F1C", "F1D", "F1E"],
           "Parent": "line1"
       },
       "deck-2": {
           "Elements": ["F2A", "F2B", "F2C"],
           "Parent": "line2"
       },
       "deck-3": {
           "Elements": ["F3A", "F3B", "F3C"],
           "Parent": "line3"
       }
   },
   "meters": {
       "Main": {
           "Model": "EEM-MB371",
           "Parent": "main",
           "Interface": {
               "Type": "modbus-tcp",
               "IPAddress": "10.1.2.3"
           }
       },
       "parkingLotLight": {
           "Model": "EEM-MB371",
           "Parent": "line3",
           "Interface": {
               "Type": "modbus-tcp",
               "IPAddress": "10.2.3.4"
           }
       }
   }
}

Let's break down the elements and their attributes:

Element Type	Name	Parameter/Attribute	Value	Info
Line	main	CurrentLimit	L 1 L 2 L 3 40A 40A 40A	Main supply line. Parent node of all other lines.
	line1	CurrentLimit	L 1 L 2 L 3 32A 32A 32A	Sub-line of main, feeds deck-1.
	line2	CurrentLimit	L 1 L 2 L 3 20A 20A 20A	Sub-line of main, feeds deck-2.
	line3	CurrentLimit	L 1 L 2 L 3 20A 20A 20A	Sub-line of main, feeds deck-3.
Group	deck-1	Elements	F1A, F1B, F1C, F1D, F1E	Charging Station group on deck 1. Parent is line1.
	deck-2	Elements	F2A, F2B, F2C	Charging Station group on deck 2. Parent is line2.
	deck-3	Elements	F3A, F3B, F3C	Charging Station group on deck 3. Parent is line3.
Charging Station	F1A	Role	HDLM Master, DLM Master (deck-1)	Controls full hierarchy and all deck-1 Charging Stations.
	F1B			Charging Station under deck-1, managed by F1A.
	F1C
	F1D
	F1E
	F2A	Role	DLM Master (deck-2)	Manages F2B, F2C under deck-2.
	F2B	–	–	Charging Station under deck-2, managed by F2A.
	F2C	–	–	Charging Station under deck-2, managed by F2A.
	F3A	Role	DLM Master (deck-3)	Manages F3B, F3C under deck-3.
	F3B	–	–	Charging Station under deck-3, managed by F3A.
	F3C	–	–	Charging Station under deck-3, managed by F3A.
Meter	Main	Model	EEM-MB371	Main energy meter, connected to main.
		Interface.Type	modbus-tcp	Communication protocol.
		Interface.IPAddress	10.1.2.3	IP address of the main meter.
	parkingLotLight	Model	EEM-MB371	Secondary meter for line3 (e.g. parking lot lighting or separate metering).
		Interface.Type	modbus-tcp	Communication protocol.
		Interface.IPAddress	10.2.3.4	IP address of this meter.