How an EMS Publishes Site Data to SCADA over Modbus TCP

Why does an EMS need a Modbus server?

A battery storage site has consumers above the EMS: a plant SCADA that supervises the whole facility, a historian that stores years of data, a building management system, or a utility or aggregator gateway that needs the site’s state. Each could poll every device on site, but that multiplies connections to hardware that often allows only one or two masters at a time, and it leaves each consumer to compute site totals for itself. The EMS already has the totals, the mode, the setpoints it is issuing, and the alarms it has seen.

The Modbus server publishes those as a Modbus TCP server. Its page shows a status pill and a strip of the settings in force, the register map in the middle, and a tracked registers rail with a live activity log down the right. The server is off on a newly commissioned site; nothing is published until it is enabled and given a register map.

Which two settings cause most integration failures?

The protocol settings must match what the client expects, and a mismatch does not fail loudly. Byte order sets both the byte order within a 16 bit register and the word order within a 32 bit value, with four choices: ABCD, which is big endian, DCBA, BADC, and CDAB. Address base sets which addressing convention the map uses: the Modicon convention numbers holding registers from 40001, while most modern clients count from zero. Get either wrong and the client reads plausible looking numbers that are not the site’s values.

Agree both in writing before commissioning the link, and record them in the project documents alongside the register map. Eight function codes can be exposed or withheld individually: reading coils, discrete inputs, holding registers, and input registers, and writing single and multiple coils and registers. A code you clear returns an exception response rather than silently failing, which is the behavior a SCADA integrator can diagnose.

What goes in the register map?

The register map defines what the server publishes, and until it has entries the server has nothing to serve. Each register has a unique name, a function code group, an address stored exactly as typed, a data type of unsigned or signed 16 or 32 bit integer, 32 bit float, or boolean, an optional per register byte order override, a scale multiplier, and an optional category for the heatmap view. The map is shown two ways: a heatmap that lays registers out by address and shades them by read and write activity, which makes it obvious which parts of the map a client is actually using, and a table.

A map is more often imported than typed. Rather than adding fifty registers one at a time, the whole map is replaced in one operation from a preset shipped with the product, a CSV file, or pasted rows. The generic EMS preset publishes site level points for SCADA and historian use, aggregated active and reactive power, energy import and export, mode and state, dispatch setpoints, and a small alarm bitset, and is meant to be trimmed or extended to match the site. Replacing the map replaces every register, including any added by hand, so the existing map is exported first. Adding a single register takes effect immediately; the server reloads the map without dropping connections.

• Track the handful of registers the integration actually depends on, the site power, the state of charge, the mode word. The tracked rail then shows their live values on the same page, which turns commissioning a SCADA link into a two screen job rather than a phone call.
• Publish only what the consumer needs. Every extra register is information disclosed and a value someone may come to depend on.

How is the server secured?

The Modbus protocol has no authentication and no encryption. Any client that can reach the port and address the right unit identifier can read the map and, unless prevented, write to it. The server is protected at the network layer and with the controls on its own page. The access list decides which clients the server accepts, by IP address or CIDR range, with allow and block rules each labeled with the system it covers and a count of the connections it has matched. A recent clients rail lists the addresses that have connected, been rejected, or attempted something else, which is how the real addresses of client systems are discovered before rules are written.

Two settings work with the list. Read only mode rejects every write function code regardless of the per code settings, so a server that cannot be written to cannot be used to command the plant. Allowlist required rejects any connection whose address matches no allow rule. With it off, adding allow rules restricts nothing; enabling the list and requiring the allow list are two separate actions, and both are needed before the access list is a control rather than an annotation.

1. Put the server on a segregated network: the SCADA or historian VLAN, never a network reachable from the internet.
2. Turn on read only mode unless writes are genuinely required. Most integrations only read.
3. Withhold the function codes you do not need. If the integration reads holding registers, clear the four write codes as well.
4. Enable the access list and turn on allowlist required, with one allow rule per client system.
5. Publish only what the consumer needs. Trim the map to the points the integration is contracted to receive.
6. Bind to one interface where you can, so the listener is not present on other networks.
7. Keep the idle timeout and the connection cap. They limit what a misbehaving or abandoned client can consume.
8. Review the activity log after commissioning. Rejected connections after go live are worth investigating.

What does the site network have to allow?

Only two inbound paths ever need to reach the appliance. Everyone who signs in reaches the operator interface and its API over HTTPS from the office or control room network; it is the only inbound path that carries content. Where a site has one, the SCADA, historian, or third party master reaches the Modbus port from that master’s address only. Outbound, none of the optional functions are required for the plant to run, and each has an offline alternative: license activation falls back to a signed offline file, software updates to local media, audit forwarding to a local spool collected from the appliance, and utility DER polling to schedules entered locally.

From the appliance to the plant, the EMS must reach every device it polls on that device’s Modbus TCP port, commonly 502 but device dependent, and no other master may already be holding the device’s connection slots. Serial devices are reached over RS485 from the appliance’s serial interface and need no network path. A site declared offline blocks every outbound destination at source, which is a stronger statement than a firewall rule because the software stops asking.