Enexa
Simulation Overview
  • Input SummaryAll configuration parameters
  • Simulation AlgorithmsReactive vs Smart EMS explained
  • Result OverviewSide-by-side comparison
Configuration
  • Location SetupEquipment specs & constraints
  • FinancialsCosts, income & margins
  • Solar ProductionPV generation profile
  • Charging SessionsEV demand profile
  • Not ModeledKnown gaps & limitations
Reactive BMS
  • BMS AlgorithmHow the reactive BMS works
  • BMS ReactiveRule-based simulation results
SmartEMS
  • SmartEMS AlgorithmHow the 2-layer optimizer works
  • SmartEMS ConfigPlanner tuning parameters
  • SmartEMS ResultsOptimized simulation output
  • SmartEMS DispatchingGate logic & energy flow rules
Solution Overview
  • Solution OverviewArchitecture & responsibilities
  • Comm ArchitectureAPI integration patterns
  • Middleware APITelemetry & command schema
  • Onboarding & ConfigMaster data & config API
  • Exception HandlingFallbacks & failure scenarios
Prototype
  • Site MonitoringReal-time telemetry dashboard
  • Dispatch LogsCommand execution & verification
  • Impact DashboardSavings & value demonstration
  • What-If ScenariosScenario analysis & comparison

Solution Overview

This document provides a high-level overview of the integration between Enexa energy optimization and the Amperio Team IoT middleware. It is intended to:

  • Explain the solution approach and system architecture
  • Define operational modes for Amperio Team confirmation
  • Outline exception handling scope to enable effort planning
  • Present onboarding phases for timeline agreement

1. Solution Approach

What we are building and why

Business Objective

Optimize electricity procurement costs at EV charging sites with integrated battery storage through intelligent energy arbitrage:

Charging Battery

During cheap electricity price periods (night, high renewable generation)

Discharging Battery

During expensive periods (peaks) to serve EV demand from stored energy

Always Serve EVs

EV charging demand is never compromised - customer experience is priority

Phase 1: Procurement Control

The initial optimization focuses on State of Charge (SOC) management and price arbitrage. The system will schedule battery charging during low-price periods and discharge during high-price periods, reducing overall energy procurement costs.

System Architecture
Simplified integration with clear responsibility boundaries
Cloud

Enexa Platform

Enexa Responsibility

Energy optimization, master data management, and operator interface.

Asset Registry

Master data

Configuration

Central repository

Optimizer

SOC / Arbitrage

Dashboards

Monitoring

Dispatch Commands

REST API

Enexa calls Amperio API

for command dispatch

Telemetry Data
Middleware

Amperio Middleware

Amperio Team Responsibility

Centralized backend that handles communication with ADS-TEC ChargePost hardware. Exposes REST API for Enexa integration and translates commands to Modbus/TCP registers.

API Gateway

Enexa integration

Modbus/TCP

ChargePost control

Watchdog Mgmt

2-60s heartbeat

Modbus/TCP (internal)
Field

ADS-TEC ChargePost Hardware

Amperio Team

All-in-one ultrafast charging solution with integrated battery storage. Controlled via Modbus/TCP interface.

Grid Connection

Up to 87 kVA

2x Power Units

110 kW each (battery)

EV Charging

Up to 300 kW coupled

Modbus Interface

v2.6 / FW 1.10.2+

Integration API Surface
Complete set of APIs between Enexa and Amperio Middleware

API Ownership

Enexa hostsAmperio calls to fetch data or push telemetry
Amperio hostsEnexa calls to dispatch commands

Master Data APIs

Enexa hosts

Amperio calls these APIs to fetch asset registry

  • Asset Registry

    Sites, controllers, equipment inventory

  • Equipment Specifications

    Battery capacity, charger limits, meter IDs

  • Controller Mapping

    Which controller manages which assets

Configuration APIs

Enexa hosts

Amperio calls these APIs to fetch settings

  • Controller Settings

    Operating parameters, thresholds, timeouts

  • Safety Limits

    Min/max SOC, power limits, grid constraints

  • Firmware Versions

    Expected versions, update availability

Operational APIs (Commands)

Amperio hosts

Enexa calls these APIs to dispatch commands

  • Dispatch Commands

    Battery setpoints, EV limits, schedules

  • Mode Changes

    Switch operational modes, emergency stops

  • Schedule Updates

    Day-ahead and intraday optimization plans

Telemetry APIs

Enexa hosts

Amperio calls these APIs to push telemetry data

  • Real-time State

    Battery SOC, power, EV sessions, grid meter

  • Alerts & Faults

    Equipment faults, safety triggers, warnings

  • Controller Status

    Online/offline, firmware version, heartbeat

Onboarding APIs

Enexa hosts

Amperio calls these APIs during site setup and controller registration

Site Registration

Create site record, assign credentials

Controller Provisioning

Register controller, fetch initial config

Activation Confirmation

Controller confirms successful setup

Single Source of Truth: All configuration and firmware data is stored in Enexa. Amperio Middleware fetches the latest settings via API, ensuring consistency across all sites. Changes made in Enexa are automatically available to all controllers on their next sync.

2. Operational Modes

Proposed system behaviors - requires Amperio Team confirmation

The following operational modes are proposed by Enexa. Amperio Team should review and confirm these behaviors align with their operational requirements and middleware capabilities.

Normal Operation
Enexa optimization active (grid_mgmt_mode = 1)

Trigger: Active Modbus watchdog maintained

  • - Middleware writes watchdog_interval every 2-60s
  • - Enexa commands translated to Modbus registers
  • - Manual grid_mgmt_mode with per-unit P_grid control
  • - Telemetry polled from ChargePost registers
  • - Full price arbitrage optimization active
Fallback Mode
Watchdog expired (grid_mgmt_mode = 0)

Trigger: Watchdog timer expires (no write for 60s)

  • - ChargePost reverts to fallback config values
  • - Automatic grid_mgmt_mode enabled
  • - System uses P_grid_clearance_cfg as limit
  • - EV charging continues with battery assist
  • - Batteries recharge to soc_cp_max when available
Safe State
Critical failure (operation_mode = 0)

Trigger: E-stop, crash sensor, BMS fault

  • - station.status.errors registers indicate fault
  • - Battery contactors open (no charge/discharge)
  • - EV charging unavailable
  • - Alert via station.status.warnings bitlist
  • - Manual reset required via station.mgmt.operation_mode

3. Exception Handling Scope

Failure scenarios to be handled by each system

Important: Clear ownership of exception handling is critical for effort planning. The following outlines which system handles which failures. Full details in Exception Handling documentation.

Amperio Middleware Handles

Modbus/TCP Connectivity

ChargePost unreachable, reconnection, watchdog maintenance

Hardware Fault Detection

Monitor station.status.errors, charger.X.status.errors bitlists

Clearance Violation

Handle P_clearance_violation warnings (Bit 3 in station.status.warnings)

Telemetry Buffering

Store data during Enexa outage, flush on reconnection

Register Translation

Map REST API commands to correct Modbus holding registers

Enexa Platform Handles

Middleware API Unavailable

Retry logic, queue commands, alert operators

Telemetry Gaps

Missing data interpolation, stale data warnings

Optimization Failures

Fallback to safe schedules, conservative dispatch

Configuration Errors

Validation, rollback to known-good config

Alerting & Monitoring

Dashboard alerts, operator notifications

4. Onboarding & Configuration Phases

Deployment timeline - requires Amperio Team confirmation

The following phases and timelines are proposed. Amperio Team should confirm feasibility and adjust based on their development capacity.

1
API Integration Setup
Establish communication between Enexa and Amperio Middleware

Enexa

  • - Provide API specification for dispatch commands
  • - Set up sandbox environment
  • - Create API credentials and documentation

Amperio Team

  • - Implement API endpoints for receiving commands
  • - Implement telemetry push to Enexa
  • - Test connectivity with sandbox
2
Asset & Configuration Setup
Register sites and configure parameters in Enexa

Enexa

  • - Create site records in asset registry
  • - Configure battery, charger, grid parameters
  • - Set up optimization parameters
  • - Provide configuration API for Amperio

Amperio Team

  • - Provide site hardware specifications
  • - Implement config fetch from Enexa API
  • - Map Enexa config to internal parameters
3
Integration Testing
Validate end-to-end functionality

Enexa

  • - Send test dispatch commands
  • - Verify telemetry reception
  • - Test dashboard and monitoring

Amperio Team

  • - Execute commands on test site
  • - Verify fallback mode behavior
  • - Test exception scenarios
4
Production Go-Live
Deploy to production with monitoring

Enexa

  • - Enable production optimization
  • - Monitor system performance
  • - Provide operator dashboards

Amperio Team

  • - Switch to production endpoints
  • - Monitor site controller health
  • - Support initial operations
Major Work Items
Development responsibilities for each team

Enexa Team

  • Asset registry and master data management
  • Centralized configuration repository with API
  • Optimization engine (SOC planning, price arbitrage)
  • Dispatch command API (call Amperio middleware)
  • Telemetry ingestion and storage
  • Monitoring dashboards and alerting

Amperio Team

  • Middleware backend with API for Enexa integration
  • Internal MQTT routing to site controllers
  • Site controller software and hardware deployment
  • Telemetry collection and aggregation
  • Command execution on field equipment
  • Fallback mode and exception handling
Detailed Documentation
For technical implementation details, refer to these pages
Comm Architecture

API patterns, data flows, security

Middleware API

Telemetry schema, command schema, field definitions

Onboarding & Config

Configuration API, deployment phases, config schema

Exception Handling

Complete failure scenarios, fallback behaviors