--- title: "Nexus EMS System Integration Guide · Preliminary Integration Guide · Technical Note" revision: "0.5" publisher: AERL (Australian Energy Research Laboratories) url: https://www.aerl.com.au/docs/nexus-ems-system-integration-guide-preliminary pdf: https://www.aerl.com.au/documents/guides/AERL_Nexus_EMS_System_Integration_Guide_Preliminary_REV_0.5.pdf description: "Designing a site around Nexus EMS: where it sits, the design rules, what a device needs to offer, SCADA, and how an integration is commissioned. Preliminary." --- # Nexus EMS System Integration Guide · Preliminary Integration Guide · Technical Note *Rev 0.5. Markdown copy of the AERL document at https://www.aerl.com.au/docs/nexus-ems-system-integration-guide-preliminary; the PDF (https://www.aerl.com.au/documents/guides/AERL_Nexus_EMS_System_Integration_Guide_Preliminary_REV_0.5.pdf) is the controlled version.* Preliminary Integration Guide · Technical Note # Nexus EMS System Integration Guide Designing a Site Around Nexus EMS Nexus Lite · Nexus 4G · Nexus HMI ### 1. Purpose This guide is for the engineer designing a site around Nexus EMS. It explains where Nexus EMS sits in the system, the rules a design must follow, what a device needs to offer, and how an integration is scoped and commissioned. Supported devices are listed in the Nexus EMS Datasheet. Register tables are in the AERL Nexus Modbus TCP Communications Protocol. > **Preliminary** > > This is preliminary information. Functions and supported equipment are subject to change: confirm availability with AERL for your project before a design relies on it. ### 2. Where Nexus EMS Sits Nexus EMS is the site's controller. Every controllable device reports to it and takes its commands. SCADA and AERL Cloud sit above it and see the site through it. | Layer | What is there | |---|---| | Above | Site SCADA or a utility (Modbus TCP client of the gateway); AERL Cloud | | **Site controller** | **Nexus EMS on a Nexus Gateway or Nexus HMI** | | Device controllers | Generator controllers, inverters, battery management systems, solar charge controllers, meters, relay outputs | | Beside | A site PLC or relays, where the site has hardwired interlocks or fast load shedding | | Hardwired | Emergency stop, protection relays, breakers and their protection, generator synchronising | Two things stay outside Nexus EMS whatever the design: - **Each device keeps its own protection and its own fast control.** A generator controller protects its engine, synchronises and closes its breaker; a battery management system opens its contactor. Nexus EMS tells a device what to do through its controller, never around it. - **Safety circuits stay hardwired.** Nexus EMS is not a functional safety system. Nexus EMS decides about once a second, and acts through each device's communications, which may take longer. Design nothing that needs a faster response around it. In particular, generator minimum loading needs a margin and the generator's own reverse power protection, and an export limit required by the network operator must be the inverter's certified limit. ### 3. Design Rules #### One master per device Every device answers one master: the gateway. Nothing else may poll or command a device the gateway controls. SCADA reads the gateway, which republishes everything it acquires. A second Modbus master on a device is the most common cause of lost readings and failed commands at commissioning. #### One owner per decision Write this table before any wiring. | Decision | Owner | |---|---| | Battery charge and discharge limits | The battery | | Solar charge within the limits | Nexus EMS | | Generator start, stop and which generator leads | Nexus EMS | | Engine protection, synchronising, breaker | The generator controller | | Battery dispatch, export control, battery-level load shedding | Nexus EMS | | An export limit the network operator requires | The inverter's certified limit | | Hardwired interlocks, fast load shedding | The site PLC or protection relays | | Limits and run requests from outside | SCADA or the utility, through Nexus EMS | | Safety stop | The hardwired emergency stop circuit | Where a device has its own automatic behaviour that overlaps a Nexus EMS function (a generator controller's own auto start, an inverter's generator contact), choose one and disable the other. A decision with two owners is a fault waiting to happen. #### Fail-safe: charging stops, loads stay supplied If Nexus EMS loses control of a device (gateway power, a stopped controller, a lost link), the design intent is that battery charging stops and the loads stay supplied. That outcome is made by the design of the site, so design every device to match: - **Charge sources stop.** Solar charge controllers stop by themselves when they lose their charge master. Set each inverter to stop charging the battery from a generator or the grid when it loses communication with the gateway. - **Supply continues.** Set each inverter to keep supplying loads, and give generator start a path that does not depend on the gateway: a hardwired start from the inverter or a battery-voltage relay. > **Caution** > > The fail-safe depends on the device. An inverter stops charging the battery on loss of control only if it has a communication-loss setting, and not every inverter has one. Confirm it for each inverter model before the design is fixed. A device that cannot stop charging by itself when communication is lost needs a hardwired means to do so: tell AERL at the design stage. #### Dry run first Every function runs in dry-run mode before it is armed: it decides and logs, and sends nothing. Use it at factory and site acceptance to prove the logic before anything can act. ### 4. What a Device Needs to Offer A device is brought under Nexus EMS by a driver. The driver states what the device can do, from a fixed list, and functions use only that list. So a function proved on one brand works on the next. | Capability | Meaning | |---|---| | Battery limits | Publishes charge voltage, charge and discharge current limits and state of charge | | DC source current limit | Its DC output current can be capped | | Inverter charge and discharge limits | Its battery charge or discharge power can be limited | | Inverter package control | Start, stop and emergency stop as a unit | | Generator start and stop, and mode | Remote start and stop; auto and manual | | Meter | Power and energy at a point in the system | | Relay output | A contact Nexus EMS may switch | To be controlled well, a device's communications must offer a documented register or message map, a command path that reports acceptance, a way to read back the result, and stated limits on how often a setting may be written. ### 5. SCADA Above Nexus EMS The gateway serves the whole site on one Modbus TCP address, port 502: one unit ID per device, scaled 16 and 32-bit integers (no floating point), and a quality and an age for every value. The protocol document has the tables. A client must: 1. **Read quality with every value** and act on it only when the quality reads 7. A value reads 0 when it is not valid, so 0 is never evidence of a real zero. 2. **Use age, not poll time.** A read returns the gateway's latest value and never triggers a request to the equipment. 3. **Watch the session value** and discard cached values when it changes. **Commands and setpoints.** A client on the allow-list (the approved client addresses) may write package and generator commands, and setpoints: a solar ceiling, battery charge and discharge limits, a generator run request. Each setpoint carries a time-to-live, so a lost link releases it. They rank as operator commands: below the protections, above schedules and optimisers. A write that is refused is answered with a Modbus exception that says why (not permitted, not valid, refused by the device, not sent). Modbus TCP has no authentication. The allow-list is the control: keep the gateway and SCADA on a network segment with no route from outside the site. ### 6. Commissioning an Integration 1. **Agree the ownership table** (section 3) and the register schedule. 2. **Bench test.** AERL tests drivers and functions against a simulated site, then against the real device where one can be supplied. 3. **Factory acceptance.** Every read point checked end to end (value, scale, sign, quality); every command checked in dry run. 4. **Site acceptance, dry run.** Functions in dry run through at least one full cycle of the conditions they act on. Review the log together. 5. **Arm** , one function at a time, with the operators present. Test the loss of each link and of gateway power. 6. **Record** the armed functions, settings, allow-listed clients and software versions. ### 7. Integration Services For a device that is not on the supported list, a register map to a client's SCADA contract, or site rules, send AERL: - The site's single-line diagram and communications architecture - The make, model and firmware version of each device - Each device's communications manual - The client's SCADA or register contract, if there is one - The ownership table, as far as it is decided - Whether a device can be supplied or lent for bench testing AERL returns a scope: what is to be built, the acceptance tests and the price. Work is delivered as a Nexus software update to the site's gateway, dry run first. 1800 950 865 · support@aerl.com.au · aerl.com.au