BESS Procurement in India: An EMS and Controls Checklist

A buyer’s checklist for specifying BESS controls, interfaces, tests, cybersecurity, data rights and lifecycle support without leaving critical scope ambiguous.

By Madhusudan Chakrapani · Battery Energy Storage · 15 minute read

BESS Procurement in India: An EMS and Controls Checklist

Procure an operating outcome, not a list of boxes

A BESS tender can name batteries, PCS, PPC, SCADA and EMS yet leave the project’s most important control questions unanswered. The buyer should begin with the contracted service and point of connection, then allocate functions, interfaces and acceptance evidence.

Before writing equipment clauses, use the BESS use-cases guide to define the operating outcome and the control comparison to assign system boundaries.

1. Define the service envelope

State the required MW, usable MWh, duration, response time, ramp rate, state-of-charge range, availability, efficiency measurement boundary and annual operating profile. Identify simultaneous and mutually exclusive services. If the project must preserve reserve energy, specify who calculates and enforces that reserve.

2. Create a responsibility and interface matrix

For every function, name the owner, input, output, update rate, protocol, quality flag, timeout, fallback and test. Include battery limits, PCS availability, PPC setpoints, revenue meters, SLDC or DISCOM telemetry, weather and market data, fire alarms, HVAC states and manual controls.

Avoid “standard protocol” without a point list and implementation profile. IEC 61850, Modbus, DNP3 and IEC 60870-5-104 describe communication methods; they do not by themselves define semantics, scaling or control ownership.

3. Specify EMS functions separately

The BESS EMS scope may include scheduling, forecasting inputs, dispatch optimisation, command arbitration, state-of-charge management, alarms, historian, reporting and market interfaces. Define which functions run locally and which run centrally, plus degraded operation when a link or service is unavailable.

For optimisation, require the objective, constraints, re-planning frequency, degradation treatment, override hierarchy and audit trail. Do not accept an unsupported promise to “maximise revenue.” See the dispatch optimisation guide.

4. Make acceptance measurable

Split factory acceptance, integration testing, site acceptance, performance testing and reliability demonstration. Each test needs prerequisites, input, expected result, tolerance, evidence and responsibility for defects. Include stale data, communications loss, clock drift, partial rack availability, conflicting commands, emergency stops and restart.

Capacity and efficiency tests must define initial state, auxiliary loads, measurement points, ambient conditions, rest periods and correction methods. Align these definitions with the commercial contract and warranty.

5. Cover cybersecurity and data rights

Specify network zoning, remote access, authentication, least privilege, event logs, vulnerability handling, backups, recovery, secure updates and support access. State who owns raw and derived data, retention duration, export format and access after contract termination. Avoid designs that make routine operations dependent on a supplier-only portal with no export path.

6. Procure the lifecycle

Clarify augmentation, software support, spare parts, response times, training, warranty exclusions, change control and end-of-life obligations. Require configuration backups and as-built documentation. The economic evaluation should include these costs; use the India BESS economics guide.

Bid evaluation questions

References