EMS Builder: No Energy Project Needs to Start from Scratch
Edge-EMS Builder is an intelligent orchestration platform deployed at energy sites. It turns device onboarding, data processing, strategy control, cloud-edge communication, and multidevice coordination into reusable capabilities, transforming EMS from a one-off delivery into a platform asset that can be continually replicated and upgraded.
Commercial and industrial energy storage, solar-plus-storage-and-charging, microgrids, and campus energy projects may all be called EMS, but their sites are rarely identical: device brands, point lists, electricity tariffs, and capacities change, and customers continually add new control rules.
Some projects connect PCS, BMS, meters, and PV inverters; others also connect charge points, diesel generators, air-conditioning loads, or a customer’s own cloud platform. Some customers prioritize tariff arbitrage, others grid export prevention or maximum demand, and others add requirements such as temporary capacity support for a distribution transformer area.
If every project requires new device integration, strategy code, and cloud interfaces, repetitive development and maintenance costs grow with delivery scale. Edge-EMS Builder addresses precisely this problem:
Edge-EMS Builder helps project teams organize devices, data, and control strategies in complex energy projects, moving EMS from rebuilding for every project to rapid configuration and replication on a platform.
The same data and control foundation supports different device combinations, control objectives, and project parameters.
Why EMS Builder is needed
Section titled “Why EMS Builder is needed”More devices should not mean rebuilding strategies from protocols
Section titled “More devices should not mean rebuilding strategies from protocols”A site may contain PCS, BMS, meters, PV inverters, charge points, diesel generators, air-conditioning loads, and third-party platforms. Strategies care about whether power at the grid connection point exceeds a limit or SOC permits further discharge, not which protocol supplied a register.
Edge-EMS Builder connects devices through CommBridge and unifies data identifiers so higher-level strategies work with business meaning. When a device model or protocol changes, adjusting point mappings usually allows the validated core logic to be reused.
Changing requirements need adaptable control logic
Section titled “Changing requirements need adaptable control logic”Electricity tariffs, capacity, operating periods, and control thresholds can all change. A project needing grid export prevention today may add demand control tomorrow, followed by coordination between storage and charge points.
Edge-EMS Builder separates business logic into data, calculations, conditions, and actions. Engineers can change parameters, expressions, or trigger schemes without rebuilding the entire application for every business change.
Replicated projects should turn experience into organizational assets
Section titled “Replicated projects should turn experience into organizational assets”Validated peak shaving and valley filling, charging load balancing, or multi-unit coordination logic should not remain confined to a single site. Edge-EMS Builder enables strategies to progress through:
Site validation → point and parameter abstraction → template creation → reuse in new projects → continuous iteration
As more projects are completed, the library of reusable strategies, point lists, and test cases grows. New projects increasingly involve selecting templates, mapping points, and tuning parameters instead of starting from a blank slate.
What EMS Builder is
Section titled “What EMS Builder is”Edge-EMS Builder typically runs on an edge gateway or industrial PC between field devices and cloud or business systems. It performs four main tasks:
| EMS Builder responsibility | Plain-language explanation | Project outcome |
|---|---|---|
| Unified connectivity | Connect devices from different brands and protocols to the same data system | PCS, BMS, meters, charge points, and other devices can be used consistently |
| Data processing | Turn raw points into states and metrics that strategies understand | Power, SOC, capacity, headroom, and alarm status participate directly in calculations |
| Strategy orchestration | Describe control rules using expressions and “conditions + actions” | Peak shaving and valley filling, grid export prevention, demand control, and other logic run automatically |
| System integration | Send site data and decisions to the cloud, frontends, or other nodes | Supports remote operations, centralized monitoring, strategy deployment, and multidevice coordination |
Edge-EMS Builder continuously runs acquisition → unified data pool → Lua strategy evaluation → output execution. Execution results return to the data pool, sustaining the closed loop.
What EMS Builder is not
Section titled “What EMS Builder is not”- Not merely dashboard monitoring software: it displays data and forms automated closed-loop control based on strategies.
- Not a fixed EMS with hard-coded strategies: the platform provides strategy-building capabilities; solution configuration determines the specific business rules.
- Not a safety controller replacing device protection: hardware interlocks, BMS/PCS protection, and site safety boundaries must remain independently effective.
- Not tied to a fixed frontend: organizations can build their own monitoring and control interfaces through standard WebSocket APIs.
In one sentence:
Edge-EMS Builder is not an EMS for a single scenario, but a foundation for continuously building many kinds of EMS.
Four changes EMS Builder brings
Section titled “Four changes EMS Builder brings”| Traditional project approach | With EMS Builder |
|---|---|
| Repeated integration and development for every project | Common capabilities reside in the platform; new projects focus on mapping and configuration |
| Control logic embedded in project code or firmware | Strategies combine data, expressions, trigger conditions, and actions |
| Devices run independently; coordination requires dedicated development | Shared data participates directly in cross-device calculations and decisions |
| Projects are difficult to evolve after launch | Supports cloud deployment, remote configuration, open APIs, and iterative strategy templates |
Logic reuse
Section titled “Logic reuse”Strategies reference dataKey consistently. When changing PCS, BMS, or meter models, adjusting data mappings and site parameters usually preserves the core decision flow.
Rapid validation
Section titled “Rapid validation”Edge-EMS Builder already provides acquisition, calculation, triggers, device writes, cloud-edge communication, and real-time frontend channels. Project teams can focus on strategies and business interfaces.
Reusable strategy assets
Section titled “Reusable strategy assets”Strategies validated on site can become templates documenting supported devices, required points, adjustable parameters, protective conditions, and test cases, building an organization’s own strategy library.
Open extensibility
Section titled “Open extensibility”MQTT, HTTP, WebSocket, and device-write channels connect external data, cloud platforms, business systems, and controllable devices. Reliable data sources, expressible rules, and compliant execution interfaces create opportunities for new automation loops.
AI-native: AI can assist from point lists to strategy deployment
Section titled “AI-native: AI can assist from point lists to strategy deployment”These capabilities point to the same conclusion: Edge-EMS Builder itself does not embed specific business logic. Data comes from acquisition configuration, rules from Lua scripts, and coordinated actions from trigger schemes; every configuration operation has a corresponding standard API. Configuring Edge-EMS Builder therefore need not involve clicking through pages. Other programs, including AI Agents, can do it.
This can change how Edge-EMS Builder is delivered:
- AI-assisted configuration: the accompanying Edge-EMS Builder Skills help with point-list conversion, data modeling, Lua and strategy orchestration, alarm configuration, and operations. Engineers describe requirements, review results, and validate on site.
- Open APIs: third-party Agents can query data and invoke configuration APIs within account permissions. Whether they execute control and how models are deployed depend on the actual integration design.
AI can participate in configuration and analysis. Engineering workflows determine execution scope, strategy review, and site acceptance.
For configuration workflows and installation, see AI-assisted configuration and Skills.
Where the same platform can be applied
Section titled “Where the same platform can be applied”
| Scenario | Typical requirements that can be implemented | Main coordination targets |
|---|---|---|
| Commercial and industrial energy storage | Time-scheduled charging/discharging, tariff arbitrage, peak shaving and valley filling, demand control, grid export prevention | PCS, BMS, grid connection meter |
| Solar-plus-storage | Self-consumption, PV utilization, grid export prevention, scheduled profile control | PV inverters, storage, grid connection point |
| Solar-storage-charging sites | Managed charging, charging load balancing, storage support for charging peaks | PV, storage, charge points, transformer |
| Microgrids | Solar-storage-diesel coordination, power balancing, grid-connected/islanded operating strategies | PV, storage, diesel generators, critical loads |
| Temporary distribution-area capacity support | Monitor transformer load and use storage to support capacity during peaks | Transformers, meters, storage |
| Multisite operations | Cloud data reporting, centralized monitoring, remote operations, batch strategy deployment | Multiple edge nodes and cloud platforms |
These scenarios combine the same underlying capabilities. See the generic configuration examples for Temporary capacity support and Charging load balancing.
How requirements become reusable strategies
Section titled “How requirements become reusable strategies”A project requirement typically follows this implementation path:
- Define the objective: for example, power at the grid connection point must not exceed 800 kW.
- Organize data: identify required points such as grid connection power, PCS power, SOC, and device status.
- Write calculations: calculate the capacity shortfall, available charging/discharging power, and protection boundaries.
- Configure triggers: define start and exit conditions, debounce behavior, and fallback behavior under abnormal conditions.
- Execute and validate: send power commands, record alarms and execution results, and test normal, boundary, and fault conditions.
- Abstract a template: parameterize site-specific points, capacities, and thresholds for reuse in later projects.
This turns project experience from hard-to-port code into a complete asset containing strategies, parameters, point mappings, and test conditions.
Performance-validated capabilities
Section titled “Performance-validated capabilities”In the 2026-07-29 test batch on AFE-E630 (4-core Arm Cortex-A55, 3.81 GB RAM; report v1.3), recommended scenario S3.5 used the following configured load and achieved these results:
| Metric | Tested configuration / result |
|---|---|
| Configured acquisition load | 5,000 points/second |
| Aggregations | 30 |
| Trigger tasks | 90/second; average throughput attainment 99.97% |
| MQTT tasks | 20/second; average throughput attainment 99.90% |
| Coordination tasks | 10/second |
| Trigger / MQTT P95 latency | 56 ms / 77 ms |
| Whole-device CPU average / P95 | 50.16% / 71.09% |
| Whole-device actual memory average / P95 | 40.49% / 41.41% |
These results demonstrate capacity under a defined hardware/software configuration and measurement methodology, not a capacity guarantee for every project. The test analyzed 2,000 valid short-term resource samples. For production, reserve approximately 20% engineering headroom below the tested load and retest with actual scripts, message sizes, and database volumes.
See AFE-E630 performance testing for the complete environment, statistical definitions, and limitations.
Who EMS Builder is for
Section titled “Who EMS Builder is for”- Equipment manufacturers and system integrators seeking less repetitive delivery and their own EMS products and strategy assets.
- Energy teams with in-house development capabilities seeking control over the evolution of strategies, frontends, and cloud platforms.
- EPC contractors and operators replicating projects rapidly seeking shorter site commissioning cycles through validated templates.
- Teams handling complex projects requiring special devices, coordination across energy sources, or deep integration with existing platforms.
Choose platform-based development, a standard solution, or joint customization according to team capabilities and delivery objectives. See Service models.
Find documentation by need
Section titled “Find documentation by need”| Need | Documentation |
|---|---|
| Build your first calculation loop | Quick start |
| Organize points, time schedules, and groups | Data model |
| Write control rules and alarm workflows | Trigger schemes, Alarm lifecycle |
| Expand similar devices and update templates | UDE and dynamic placeholders |
| View trends, export, and retain data continuously | Historical queries, Export, Periodic archiving |
| Manage capacity, configuration, and maintenance | Storage recommendations, Runtime configuration, Maintenance freeze |
| Track device execution results | Device control logs |
| Use an Agent to assist configuration | 23 EMS Builder Skills |