Microgrid operation involves thousands of decisions across electrical limits, battery state, load demand, protection and market conditions. An AI-assisted energy management architecture can explain these decisions and prepare operational options without replacing the systems responsible for safe execution.
The architecture places analysis and decision support above a deterministic supervisory EMS. Customer applications can be designed around auditable site models and scoped requests, while actual power-system commands remain within the authorized EMS and protection stack.
Dashboards, asset reports, maintenance review and human approval workflows.
Contextual explanation, scenario comparison, tariff analysis, forecast inputs and dispatch recommendations.
Identity · site permissions · validated operating limits · operator approval · audit evidence
Supervisory state machines, operating modes, setpoints, hard interlocks and fail-safe behavior.
PCS, BMS, meters, relays, breakers, loads, generation and storage.
The AI layer does not issue direct Modbus commands, reset protection devices, or override equipment limits. Protective relays retain independent trip authority. This separation is an architectural requirement, not a claim that any particular customer gateway is available for general use.
Energize Solutions Inc. develops its Microgrid Intelligence Engine for commercial energy systems. Enterprise clients can engage on a project-specific, paid integration model in which secure, privately provisioned APIs connect approved site data and analytics applications. The service scope, access permissions and operating responsibilities are established for each installation.
01 / ENGINEERING FOUNDATION
Energy-specific analytics are organized around BESS state, load, tariffs, equipment limits, alarms and actual EMS operating records. This gives an operator a technical basis for evaluating recommendations.
02 / COMMERCIAL DELIVERY
A customer's own application or operations platform can be connected through a scoped integration agreement. Data access, isolation, identity and commercial terms are defined for the participating site rather than through an open public API service.
03 / PRACTICAL OUTCOMES
Potential project workflows include dispatch scenario analysis, revenue-gap review, battery health interpretation, event explanation and documented operator decision support, subject to the agreed integration scope.
04 / PROTECTED OPERATIONS
Advisory calculations do not override electrical protections, permitted device operating limits or supervisory authorization. Site commissioning and integration validation remain necessary before any operational use.
Integration terms and delivery scope are confirmed through direct enterprise engagement. Technical reference descriptions are not a guarantee that every analytics module is available or commissioned at every customer site.
01 / SITE OPERATIONS
Connect timestamped dispatch decisions with site load, meter data, alarms, breaker positions and operating constraints. Traceable evidence is more useful than an answer without its source.
02 / VALUE ANALYSIS
Compare the expected tariff or market value of a feasible schedule against metered results. Separate demand peaks, battery derating, availability, forecast error and export limits before attributing a financial difference.
03 / DISPATCH OPTIONS
Rank candidate charging and discharging windows against energy capacity, PCS power limits, state-of-charge reserve, site demand and utility interconnection rules. A proposed plan still requires deterministic validation.
04 / HEALTH AND FAULTS
Interpret battery alarms, temperature trends and constraint changes alongside manufacturer-defined limits. A diagnostic explanation must never silently acknowledge faults or remove a protective lockout.
A scalable software service needs a consistent view of the site without treating every installation as interchangeable. The following entities form a practical integration design reference. They describe the information an implementation would need; they are not live API endpoints or a published customer SDK.
| Domain | Information | Reason it matters |
|---|---|---|
| Site & permissions | Site identity, tariff territory, roles, allowed actions | Prevents an advisory workflow from crossing customer or operator boundaries. |
| Assets | PCS limits, BMS operating envelope, meter location, relay and breaker states | Establishes what can physically and safely happen. |
| Measurements | Timestamp, unit, quality flag, source device, point of common coupling | Makes explanations traceable and permits detection of stale telemetry. |
| Operating strategy | Mode, reserve target, dispatch objective, export constraints | Provides the context needed to evaluate candidate schedules. |
| Events & outcomes | Alarm, trip, requested action, authorization, actual response | Supports auditability and root-cause analysis. |
An optimization result can estimate energy movements, expected savings and operating risk. It cannot prove a site will follow the plan until interlocks, data quality, control permissions and real physical constraints have been verified.
Customer-facing integrations require per-site authorization, authenticated back-end access, bounded usage, audit records and explicit operational responsibility. Client-side exposure of model credentials is not an acceptable integration design.
Actual service availability and deployment conditions depend on project-specific engineering and approved integration testing. Architecture descriptions and reference scenarios should not be treated as a customer-access entitlement.