Overview

The Storage feature in Switch enhances your existing capabilities by allowing you to integrate storage profiles into your savings analyses. This feature empowers you to create comprehensive savings analyses that account for storage systems, providing a more accurate and holistic view of potential savings. You can now seamlessly generate and include storage profiles in your analyses, utilizing advanced dispatch strategies to optimize performance and savings.

🚧
The storage feature cannot be used with private tariffs. Please ensure you are using public tariffs when creating storage profiles. You can observe the privacy field on the Tariff object to confirm the status of the specific MTID you are working with.

Key Features

While this is a relatively new release, we have included the pieces for later development in the table below.

	Supported	Later development
Dispatch logic	Optimal dispatch, Fixed Schedule, Charge from Surplus	Hardware integration
Tariff coverage	Open to all Arcadia tariffs* Increasing demand tiers	Optimal battery plans for consumption tiers, descending demand tiers, and complex ratchets when using the `optimize`dispatch strategy
Operating modes	Cost minimization, Self-consumption	Emission reduction, resiliency
Asset support	Solar + storage, standalone storage, Multiple solar profiles	EVs
Grid services	Export	Demand Response and Wholesale Market Prices
Calculation horizon	Support for lifetime SAs with storage	Next-day operational dispatch
Consumption curve	Typicals (generalized region-specific load curves), Intelligent baseline (site-specific load curves) Synthetic intervals (beta)**	Interval meter data, provided by Arc

*Arcadia makes approximations for certain kinds of tier charges and complex ratchets. For tariffs with these features, the schedules generated by the optimal dispatch logic will produce feasible, though not necessarily optimal, battery dispatch schedules.

**Arcadia’s Synthetic Intervals service estimates 15-minute usage curves based on site-specific characteristics, even when only an address is known. By leveraging NREL’s ComStock database, it provides accurate proxy curves that support energy analyses for greenfield projects, sites without published interval data, and other scenarios where real interval data is inaccessible or too costly. Available via API or UI, we equip users with metrics that empower them to quickly assess a site's DER development potential. For more information please see: Search for Synthetic Intervals.

Integration with Switch

Storage in Switch is designed to seamlessly integrate with the existing Switch platform, adding two critical functionalities:

Storage Profile Creation: You can create storage profiles by inputting battery (storage system) specifications into the /rest/v1/profiles/storage endpoint, along with consumption and solar production profiles, to generate a tailored dispatch strategy.
Inclusion in Savings Analysis: You can incorporate these storage profiles into your savings analyses, producing results that reflect the impact of storage systems and their associated dispatch strategies on your overall savings.

This new feature ensures that you can leverage advanced storage capabilities to enhance your energy savings analyses, providing a comprehensive tool for maximizing efficiency and savings.

Solution Diagram

Resource URI

POST /rest/v1/profiles/storage

Try this out on the Add Storage Profile Endpoint.

Note: PUT requests are not allowed.

Making a request to this endpoint will simulate the battery storage system and generate three new “post-storage” profiles that adjust the base consumption and solar profiles to account for the battery’s energy timeshifting. These “post-storage” profiles are then used to perform a Savings Analysis.

These three new profiles are:

Post-storage grid imports to site: The grid-to-site kWh series, excluding additional kWh imported to directly charge the battery.
Post-storage grid exports from Solar: The solar-to-grid export kWh series, after any self-consumption and battery charging.
Grid imports and exports to and from the Battery: This profile includes two data series representing net grid imports and net grid exports that are directly attributable to battery grid charging and battery exports.

These “post-storage” profiles can be identified with a “-usage”, “-solar”, or “-storage” suffix (respectively) on their providerProfileId field.

Together, these encapsulate the net imports and exports measured at the meter after the battery system is operational. Importantly, these profiles capture only the system’s interaction with the grid, meaning the transactions are associated with a tariff rate. Other Behind The Meter power flows (such as battery-to-site) are not stored in these profiles as they cannot be priced against a tariff rate, users who wish to persist these schedules must store them within their application.

How does the storage model use the Switch Usage Profile?

The storage model requires the ELECTRICITY Profile to be an hourly consumption time series. Many Switch users, however, create ELECTRICITY Profiles using monthly statements rather than interval data. To account for this, when the Storage Profile is passed an ELECTRICITY Profile without a full 8760 array, it will automatically transform the available Reading Data into a time series that can be passed to the storage model (see Intelligent Baselining for more information). This means that your monthly solar production will be converted into a flat, hourly profile. We strongly recommend always using hourly solar profiles for accurate results.
If you prefer to use your own intervals, the Storage Profile will only ensure they are appropriately dated for a future time horizon.

What dispatch options does the storage model support?
SinS supports passing a dispatchStrategy option on storage profile creation, which controls how the battery charges and discharges. dispatchStrategy supports three sub-options:

{ "dispatchStrategy": { "optimize": true } }: create a storage profile with an optimized dispatch schedule to maximize savings for the given tariff (also passed as a parameter). This dispatch strategy is appropriate for granular TOU tariffs and hardware controls that support hourly schedules. For tariffs with tiers or demand charges, the schedules generated by the optimal dispatch logic will produce feasible, though not necessarily optimal, battery plans.
{ "dispatchStrategy": { "chargeOnSurplus": true } }: create a storage profile where the battery charges on surplus solar whenever generation exceeds consumption, and discharges to meet unmet site demand otherwise. For this strategy, the storage system does not charge from, or export to, the grid. This dispatch option is designed to support grid-independent installations.
{ "dispatchStrategy":{ "fixedSchedule": {"chargeTous":[], "dischargeTous": []}}: create a storage profile where the battery charges and discharges on a fixed schedule. To specify this schedule, pass in arrays of time-of-use objects (all fields are allowed, but only a subset is required — see the example below). These examples can be taken directly from tariff JSON to facilitate charging off-peak and discharging on-peak. The battery will attempt to charge as much as possible during charge periods and discharge as much as possible during discharge periods. When there is not enough generation to cover both site consumption and battery charging, we apply the following prioritization:
1. When the battery can charge from the grid { "allowGridToBattery": true } we prioritize charging the battery from solar and send surplus generation to the site.
2. When the battery can only charge from solar { "allowBatteryToGrid": false } we prioritize powering the home, and only charge the battery from surplus generation.

Note: Switch will default to the optimized dispatch strategy if the field is not included in the request.

Input parameter notes:

"serviceType": "ELECTRICITY" - There is no new service type for the Storage profile. Instead, we use ELECTRICITY, same as a Usage Profile.
The endpoint supports using either or both accountId and providerAccountId – consistent with Usage and Solar Profile.
For looking up solar and consumption profiles, the endpoint supports using either or both profileId and providerProfileId — consistent with Usage and Solar Profile.
All inputs under ‘Storage’ are optional - defaults are displayed below.
Although all inputs under the storage object are optional if a mainTariffId is not passed we will use the primary tariff on the Account. Depending on the Account configuration, this may be a pre-solar tariff. We recommend always specifying the desired solar tariff in a Storage Profile.
The storage model supports one or more solar profiles, allowing users to upload multiple arrays per project, each under a different profile. This implementation assumes a single inverter such that when more than one solar profile is passed to the storage endpoint, the service will sum up all generation per time step.
When passing a solar profile users have the option of scaling the production using the dataFactor parameter (see example call below). This input field acts as a scalar, multiplying each of the solar curve’s readings by the given value. For example, “dataFactor”: 4 will result in a 400% increase in each of the solar profile’s intervals.
Top-level providerProfileId – used as a prefix to the IDs of the three new profiles created by the call. We will append the type of profile (usage/solar/storage) to each so that it’s easier to track what profiles go together for a Savings Analysis. For example, if you set the parameter as "providerProfileId": "sins-example-jun23-poststorage", then the three new profiles will have the following providerProfileId’s:
- "sins-example-jun23-poststorage-usage"
- "sins-example-jun23-poststorage-solar"
- "sins-example-jun23-poststorage-storage"
profileName - used as a prefix for the names of the three new profiles created by the call. For example, if you set the request parameter as "profileName": "Fav Customer", then the three new profiles will have the following profileNames:
- "Fav Customer - Post-storage grid imports to site"
- "Fav Customer - Post-storage grid exports from solar"
- "Fav Customer - Grid imports and exports to and from battery"
There are four power flow parameters that allow users to customize the model to the site installation. By default, all powerflows are enabled (true).
- allowGridToBattery
- allowBatteryToGrid
- allowSolarToGrid
- allowSolarToBattery
Battery hardware specifications are captured in the storage object (see example requests below for available fields).
fromDateTime should match the value used in the usage and solar profiles. Please be sure to pass the timezone in your request. This timestamp should be the same as was used for the electricity Profile, Solar Profile, and Savings Analysis.
exportLimitKwhAc restricts exported to the grid per time step in kWh AC. Leave unspecified for unlimited exports, or set to 0 to forbid them.
batteryMinSoc ("0.1"): This is the minimum state of charge for the battery, expressed as a fraction of the total capacity. In this case, the minimum SoC is 10% of the battery's full capacity.
batteryMaxSoc ("1.0"): This is the maximum state of charge for the battery, expressed as a fraction of the total capacity. Here, the maximum SoC is 100% of the battery's full capacity.
batteryInitialSoc ("0.5"): This is the initial state of charge of the battery when it starts operating, expressed as a fraction of the total capacity. In this case, the battery starts at 50% of its full capacity.
Arcadia’s storage model supports two options for passing in battery power ratings - the rate at which a battery can charge and discharge. Note that users should pass one of these options, not both.:
- batteryNameplatePower - for batteries that have the same charge and discharge rate limits. This is the default option used by the system.
- A combination of batteryNameplateChargePowerKwDc AND batteryNameplateDischargePowerKwDc - for batteries that have different charge and discharge rate limits.

Response notes

The response from this call will automatically create three new profiles within the account, each with the same providerProfileId prefix and source.requestId to indicate they are part of the same set. If no providerProfileId is sent in the initial request, then the request ID will be included in their default providerProfileId and profileName.
The original power flows returned by the Storage Model can be found under the storageOptimizationResponse field. Please note that we do not store BTM power flows under the new optimized profiles. To use these outputs you must store them on your end.

Let's break down the most important components of the response:

Bold indicates a nested object holding other parameters, the contents are summarized in the description.

Usage Profile Response:

usageProfile Object	Description
profileId	System-generated identifier for the new optimized usage profile
providerProfileId	The new identifier for the optimized usage profile. This will be your original `providerProfileId` with `-usage` appended to the end.
profileName	The new name for the optimized usage profile. This will be your original `profileName` with `- Post-storage grid imports` to site appended to the end.
accountId	Account ID associated with the usage profile
source	Object containing the source of the information. In this case, it would be Spark Storage Optimization since that's what generated the profile information.
readingDataSummaries	Includes the start date time, end date time, and total count of the readings on the profile.
baselineMeasures	estimated numbers when baselining is performed to generate the usage curve. null when not applicable

Solar Profile Response:

solarProfile Object	Description
profileId	System-generated identifier for the new optimized solar profile
providerProfileId	The new identifier for the optimized solar profile. This will be your original `providerProfileId` with `-solar` appended to the end.
profileName	The new name for the optimized solar profile. This will be your original `profileName` with `- Post-storage grid exports from solar` to site appended to the end.
accountId	Account ID associated with the solar profile
source	Object containing the source of the information. In this case, it would be Spark Storage Optimization since that's what generated the profile information.
readingDataSummaries	Includes the start date time, end date time, and total count of the readings on the profile.
baselineMeasures	estimated numbers when baselining is performed to generate the usage curve. null when not applicable

Storage Profile Response:

storageProfile Object	Description
profileId	System-generated identifier for the new optimized storage profile
providerProfileId	The new identifier for the optimized storage profile. This will be your original `providerProfileId` with `-storage` appended to the end.
profileName	The new name for the optimized storage profile. This will be your original `profileName` with `- Grid imports and exports to and from battery` to site appended to the end.
accountId	Account ID associated with the storage profile
serviceTypes	Types of services included (e.g., ELECTRICITY)
source	Object containing the source of the information. In this case, it would be Spark Storage Optimization since that's what generated the profile information.
readingDataSummaries	Includes the start date time, end date time, and total count of the readings on the profile.
baselineMeasures	estimated numbers when baselining is performed to generate the usage curve. null when not applicable
storageOptimizationRequest	Includes all of the information passed in the call to the storage endpoint, populating the defaults for any fields that were not passed in.

Storage Optimization Response: The storage optimization response will return several dataSeries containing hourly intervals for the year (8,760 readings) that represent the different flows of energy.

storageOptimizationResponse Object Contents	Description
grid_to_site_kwh_ac	The electricity drawn from the grid to meet the energy needs of the site when local generation or storage is insufficient.
grid_to_battery_kwh_ac	The energy drawn from the grid and stored in the battery, typically used to ensure that there is a reserve of electricity available when needed, such as during periods of high demand or low renewable energy generation.
solar_to_battery_kwh_dc	The energy produced by the solar panels that is stored in the battery for later use, rather than being used immediately on-site or fed into the grid.
solar_to_site_kwh_ac	The energy produced by the solar panels that is used immediately on-site to meet the site's energy needs.
solar_to_grid_kwh_ac	The surplus energy generated by the solar panels that is not used on-site and is instead fed back into the grid.
solar_curtailed_kwh_dc	The kilowatt-hours (kWh), that were generated but not used or stored, and therefore wasted. This situation typically occurs when the generation capacity exceeds the consumption and storage capacity, leading to excess energy that cannot be utilized.
battery_to_site_kwh_ac	The energy supplied by the battery to meet the site's energy demands.
battery_to_grid_kwh_ac	The energy discharged from the battery and sent back to the grid, which can occur when there is excess stored energy that the site does not need.
battery_soc	Percentage representing how much energy the battery currently holds compared to its total capacity.
net_load_kwh_ac	The total electricity demand after accounting for any energy contributions from onsite generation or storage systems.
from_date_time	Start date and time of the optimization response