Integrated lithium battery energy storage solutions
API & SYSTEM INTEGRATION | API & System Integration

Through clear interface boundaries,
connect devices, sites, and business systems

Build system-integration capability contract-first: define northbound and southbound boundaries, unify telemetry, event, command, and acknowledgement semantics, so every system interaction is identifiable, verifiable, auditable, and evolvable.

The goal of integration is not that the interface can be called, but that data, commands, responsibilities and failures are clearly bound.
Total interfaces 156
Mapped fields 1,248
Command channels 36
Integration objects 28
Critical interface status 100%
Northbound applications and business systems
GRID Grid / dispatch Utility / Grid
EMS Client EMS Customer EMS
CMMS Equipment management CMMS
ERP Enterprise resource plan ERP
DATA Data Lake / Cloud Platform Data Lake / Cloud
SVC Service platform Service Platform
Southbound devices and site systems
BMS BMS Battery management system
PCS PCS Power Conversion System
MTR Measurements Meters
WX Weather stations Weather Station
SCADA Site SCADA Site SCADA
IO Support equipment Auxiliary / IO

01 Integration landscape and accountability boundaries System of record and ownership

BMS
PCS
Meters
Weather
Site SCADA
TIANCHU BESS
Integrating Border
Utility / Grid
Customer EMS
CMMS
ERP
Data Lake
Service Platform
Telemetry/ Status Events / File Commands Confirm / Results

02 Protocol and interface layer Supported integration mode

Southbound protocol stack Southbound

Modbus TCP / RTU Field equipment acquisition and control
IEC 61850 MMS / Electricity automation
IEC 60870-5-104 Remote / Schedule
CAN / RS485 Device Internal / Secondary bus
SNTP / NTP Time Sync

Northbound interface patterns Northbound

REST API Query / Control / Configuration
Real-time streaming MQTT / Kafka
Message queue AMQP / Kafka
File exchange SFTP / HTTPS
Modbus TCP / RTU: For industrial on-site objects such as PCS, metering and assistive equipment, support is provided for controlled rotation and memory mapping.

03 Interface compacts Interface Contact

Category Interface Item Object Field / Schema Units Time Quality Orientation Refresh / Trigger Owner Authority
Telemetry/ Status EMS.DC.Volt BESS-01 / Rack-12 dc_voltage V ISO8601 / UTC GOOD North real time 1s TIANCHU —
PCS.AC.Power BESS-01 / PCS-01 ac_active_power kW ISO8601 / UTC GOOD North real time 1s TIANCHU —
Meter.Import.Energy BESS-01 / Meter-01 import_energy kWh ISO8601 / UTC GOOD North 15 min TIANCHU —
Event / File / Master Data Alarm.Event BESS-01 event_alarm — ISO8601 / UTC — North Event Trigger TIANCHU —
Device.Master BESS-01 device_master — ISO8601 / UTC — Double Batch Customer Customer System
Command PCS.ActivePower.Set BESS-01 / PCS-01 set_active_power kW ISO8601 / UTC — North-South Command Trigger Customer Customer EMS
BMS.ChargeLimit.Set BESS-01 / Rack-04 charge_limit % ISO8601 / UTC — North-South Command Trigger Customer Customer EMS
Confirmation / Results Cmd.Ack BESS-01 cmd_ack — ISO8601 / UTC GOOD North Operation Trigger TIANCHU —
Cmd.Result BESS-01 cmd_result — ISO8601 / UTC GOOD North Operation completed TIANCHU —
DC Voltage Telemetry: Direct-flow bus voltage is real-time telemetry, with a single time stamp and Quality, not allowed to be written directly to consumers north.

04 Exchange modes Choose by business semantics—not every datum uses the same transport

POLL Polled read 1s-60s cycle collects, suitable for continuous Telemetry.
EVT Status / event notification Change drivers, for alarms and events.
MSG Message-based commands Step forward, must take AK.
FILE Batch / historical files SFTP / HTTPS, with version and verification.
MASTER Master data / configuration Low frequency changes require approval and version.

05 Mapping and transformation workbench Traceable links from source to target

Source tag Source Tag
PCS.AC.Power
unit: kW
Local TZ
Canonical object model Canonical Model
asset: PCS-01
metric: active_power
category: power
Standardization Normalization
unit: kW
TZ: UTC
scale: 1
Validation rules Validation
required
range check
timestamp check
Target schema Target Schema
EMS.PowerPoint
ISO8601
quality=GOOD

06 Version and compatibility management Evolvable · traceable

Interface/ Protocol Current Version Backward compatibility Abandoned plan Impact on consumers Migration Window Status
Telemetry API(REST) v2.3.1 Compatible v2.0+ Old v1 is disabled at 2024-12-31 Customer EMS 2024-06 → 2024-11 Running
Event Streaming(Kafka) v1.5.0 Compatible v1.3+ — Alert / Data Platform — Running
Command API(REST) v2.1.0 Compatible v1.9+ 2025-03-31 Part old client 2024-10 → 2025-02 Planning
File Interface(SFTP) v1.2.0 Compatible v1.1+ — Internal services Ongoing Running
IEC 104 Profile v1.0.2 Compatible v1.0+ — SCADA System — Running
Principle of compatibility: Breaking Change must upgrade Major Version, preserve the migration period, impact assessment, consumer lists and roll-back programmes;

07 Secure command handshake Safety first · controlled failure

1 Request Command Request
2 Authentication Auth Reference
3 Target / scope validation Target Validation
4 Equipment readiness check Ready Check
5 Execute Release Execute
6 Acknowledgement Acknowledgement
7 Measured outcome Measured Outcome
Timeout: 30 s
Replay: Ban
♪ And so on ♪ Command ID
Failed: Hold safe state

08 Sandbox and test assurance

CONF Conformance testing Schema / Contractor Consistency
CON Contract testing Producer / Consumer Certification
NEG Negative testing Invalid / Overstepped / Missing Fields
LOAD Performance and Pressure Conjunctive / Peak Swallow
CLK Time and Order Clock deviation / sequence verification
SITE Site interconnect verification E2E Site Test

09 Integration issue closed-loop case Unit/ Time Zone Inconsistencies

• Discovery of problems EMS needs PCS power.
Request
Data source confirmation Southbound label confirmed.
PCS.AC.Power
3 Reason analysis Source is W, local time.
W / Local TZ
Map correction Unit and time harmonization.
kW / UTC
5. Return verification Reimplement Contractor Test.
100% PASS
• Software release Releases a new map version.
Mapping v2.2.1

10 Documentation and deliverables Auditable. Reusable.

ICD Interface specification Interface Spec
DICT Data Dictionary Data Dictionary
CMD Command Matrix Command Matrix
MAP Map File Mapping File
TEST Test report Test Report
COMP Compatible Matrix Compatibility
REL Issuance of notes Release Notes
CASE Support cases Support Case

11 Liability boundary Who's responsible for what?

TECH Interface technical boundary Protocol, Schema, Mapping
OWN Data ownership Course of Truth
SEC Security and authority IAM, Roles and Certificates
RUN Operational responsibilities Who can give a control order?
CHG Change ownership Version, migration, rollback
AUD Evidence and audit Logs, tests and deliverables
Core principles: One system connection must be clear at the same time. Technical boundary, data responsibility, command authority, security control, failure, version strategy and acceptance evidence(b) “Network has been reached” does not in itself mean that the System Information has been completed.