SPAN’s Response to CEC Docket #24-FDAS-04:

RFI - Flexible Demand Appliance Standards for Electric Vehicle Supply Equipment

Span.IO, Inc. (“SPAN”) appreciates the opportunity to provide feedback to the California Energy Commission on Docket #24-FDAS-04. This is in response to the request for information published on October 18, 2024. SPAN is excited by the opportunity for in-home devices to support flexible energy demand and we envision a number of behind the meter assets coming together in synchrony to best enable grid-edge intelligence, realize the future opportunity for residential decarbonisation, and deliver the optimal homeowner experience.

SPAN is a manufacturer of smart panels, smart energy accessories, and connected energy management software solutions for single and multifamily homes. SPAN’s flagship product, the SPANⓇ Panel, is a direct replacement of the traditional electrical panel, but one that adds onboard intelligence (i.e. internet connectivity, machine learning-based algorithms, and enhanced safety measures) as well as monitoring and controls to each available circuit. SPAN also manufactures an EV charger called SPAN Drive. SPAN Drive is a Level 2 EVSE that, when paired with a SPAN Panel, can adjust the maximum EV charge rate in real time to track a dynamic signal (e.g. available excess solar) or to respond to total home energy usage. SPAN’s products come with a control system called SPAN PowerUp™. SPAN PowerUp™ is a UL-916 Energy Management System that intelligently manages SPAN Drive and third party appliances to control energy and real-time power consumption according to customer preferences. PowerUp is a technology alternative to traditional distribution system upgrades and also provides ongoing demand flexibility.

SPAN recently submitted comments in Docket #24-FDAS-03 on Low-Voltage Thermostats¹, and those comments include our proposed principles and requirements for the entire Flexible Demand Appliance Standards (FDAS) system architecture, many of which are applicable to an EVSE FDAS. In lieu of repeating that content here, we will reference specific sections from those comments.

We are focusing our comments on this EVSE RFI on residential EVSEs, although the principles underlying our proposed residential EVSE requirements (primarily, open protocols supporting both local and cloud-based control) apply to public and fleet EVSEs as well.

Recommendations

In addition to our responses to specific questions, we would like to highlight three higher-level recommendations. These recommendations underlie all of our responses to specific questions.

Recommendation 1 : The CEC should broaden the scope of its EVSE FDAS efforts to include requirements to support V2X capabilities for EVSEs.

The RFI questions focus on control and management of the EVSE-Electric Vehicle (EV) charging process in order to minimize stress and investment impacts on the distribution grid, and to enable customers to meet their EV charging needs at the lowest possible cost. These are crucial components of the flexible-demand system.

However, EVs are rapidly evolving from pure loads to distributed energy resources capable of providing power to a home during a grid outage (V2H) or exporting power to the grid (V2G), collectively known as V2X. In order to support the transition of the EV from a load to a potential power source, EVSE support for bidirectional power usage/sourcing from EVs is a requirement. This functionality places new and additional requirements on the EVSE, and SPAN suggests that the CEC investigate these V2X requirements and consider including them in any EVSE FDAS rulemaking.

Recommendation 2: The CEC should prioritize customer choice and interoperability in an EVSE FDAS.

California is a leader in EV adoption, and the new and additional loads required for EV charging are challenging and stressing the grid, and, unfortunately, support for flexible-demand management and control by current EVSEs is limited or non-existent. The rules that the CEC develops today will shape the industry structure for the foreseeable future. The CEC should adopt rules that create a customer-centric industry structure and that enables market competition among providers of hardware, applications, and services.

Our view is that the CEC can achieve this objective by focusing on two themes in any future FDAS:

• Customer choice. A customer should be able to use the EVSE of their choosing to charge their EV. An auto OEM should not be allowed to limit customer choice (and innovations and standards) through proprietary, vertically-integrated, non-interoperable EV-EVSE hardware (or software) implementations. Further, a customer should be able to delegate control of their EVSE to an in-home application, or to a third party (including a utility). As we discuss below, the key to this customer choice is an open communications standard that supports local and/or cloud control that applies to all EVSE units.
• Interoperability. A customer should be able to use their preferred application or service to control any EVSE unit. Interoperability (or cross-controlability) will allow a customer to switch EVSEs or EVSE control applications/services in order to achieve their charging needs and select solutions with the features they value the most.

If the CEC adopts an EVSE FDAS that incorporates customer choice and interoperability, we believe Californians would see clear benefits. First, there would be market competition to build the best EVSE control systems and services for customers. Second, more customers would be able to connect their EVSE units to load control programs or services.

This is not how the market is structured today. Although many residential EVSEs can (and do) connect to the home’s local area network (LAN or home WiFi), in most cases the only use for this network connection is to enable the EVSE to connect to the EVSE manufacturer’s cloud, and the only way for the customer to control and manage the EVSE is via a smartphone application offered by the manufacturer. The consumer is provided no ability to connect and control the EVSE to another application or system, either locally (within the home), or to another cloud-based application.

Some ways that current residential EVSEs fail to support customer choice and flexible-demand control include:

• Many residential EVSE units do not enable dynamic and real-time control over the maximum power the EVSE can provide to the EV, a critical requirement for flexible-demand support.
• Most residential EVSE units do not provide an open protocol/API to control and manage the EVSE.
• Residential EVSE units that provide a control protocol/API often require that control to occur via connection to the EVSE manufacturer’s cloud, and do not support local control within the home, at the cost of lower reliability, additional cost to the consumer, and adding both privacy and security risks to EVSE control.

Recommendation 3: Deliver customer benefits by adopting open standards enforced via regulation.

In order to enable the innovation and rapid-development of flexible-demand EVSEs, it is crucial for the CEC to mandate that residential EVSEs support open (and ideally standard) control APIs/protocols. SPAN would support the CEC issuing such a regulatory requirement.

Key components of an EVSE FDAS

The CEC can meet the recommendations described above by adopting an EVSE FDAS that includes a handful of core components. SPAN recommends that any EVSE FDAS include the following four components.

Component 1: An EVSE FDAS should support, but not require, aggregators.

Virtually all existing demand response programs are implemented through ‘aggregators’, variously known as demand response providers, automation service providers, or virtual power plants. We recognize that aggregators can play an important role in orchestrating demand flexibility programs, and propose that an EVSE FDAS fully support the aggregator role. But, the EVSE FDAS should in no way require an aggregator, so that utility customers can subscribe, connect, and participate in demand flexibility programs directly and individually, by configuring their EVSE to communicate directly with flexible-demand servers. (A flexible-demand-server is a publicly available resource that contains the information necessary to trigger flexible demand events, such as Time of Use (TOU) rates or demand response events. The flexible-demand-server may be hosted either by the Load-Serving Entity (LSE) or the CEC.) Ultimately, it should be the customer’s choice to participate in demand flexibility programs via an aggregator, or via direct connection to the LSE or CEC price-server. Any EVSE FDAS should support both implementation models, LSE-to-Customer, and LSE-to-Aggregator-to-Customer.

While aggregators and cloud-based services can provide numerous benefits, it is important to realize that there are ‘costs’ and downsides to their use, including:

• Reliability and Availability: Flexible-demand appliances need to operate reliably in the event of grid and/or Internet outages (and Internet outages are more likely during grid outages). With the proliferation of energy storage devices (e.g. battery energy storage systems (BESSs), V2H-EVSEs/EVs) many utility customers’ homes will continue to operate during grid-interruptions, and power and energy control will be even more important when operating under battery power. If power and energy management are cloud-based, they are less likely to be available at these critical times.
• Cost: Cloud applications incur substantial costs for cloud-hosting, staff to operate, monitor, and maintain the service, etc. Someone has to pay these costs, almost certainly the utility-customer, either indirectly (the aggregator takes a percentage of the savings or incentives provided by the LSE), directly via a service subscription fee, or indirectly via the sale of the customer’s usage data to other parties.
• Privacy and Security: Utility-customer usage data (both real-time,and historic) may have significant privacy implications, especially as usage data becomes more granular and specific (e.g., which appliance, in which room, at what time). Some utility customers may not want their flexible-demand appliances sending this data to a cloud-application.

Component 2: An EVSE FDAS should support local control.

The ability to control flexible-demand appliances locally, via the home’s LAN, is an important requirement that an EVSE FDAS should support. Considerations include:

• Cost: Local control incurs none of the additional costs required by cloud-based solutions.
• Privacy: FDAS state/status has significant privacy implications and some customers may choose to keep this information within the home.
• Reliability: Local communication and control will be more reliable during Internet interruptions and grid outages, especially if the home has energy storage via a BESS and/or V2H-EVSE.
• Unified management: A customer may possess multiple flexible-demand appliances, and chooses to manage and control them in a unified holistic manner, via a Home Energy Management System (HEMS).
• Dynamic Power Control: The NEC-705.13 & UL-3141 Power Control Systems (PCS/EMS) standards enable support of large loads within the home, without costly service upgrades. PCS systems can be more effective and provide a better customer experience when flexible-demand loads can be incorporated into the power management process, which requires low-latency local communication.

Component 3: An EVSE FDAS should require open protocols.

Flexible-Demand EVSEs should be required to support freely-available, openly-specified protocols for:

• Device-Control.
• Communication with a Flexible-Demand-Server (AKA Price-Server), for reception of dynamic prices, demand response requests, and grid management events.
• If V2X-capabile, communication and coordination with the Microgrid Interconnect Device.

Component 4: An EVSE FDAS should require the Flexible-Demand-Server be user-configurable.

Flexible-Demand EVSE units will need to connect to a “Flexible-Demand-Server” in order to receive dynamic prices, demand response requests, and grid management events, and the Flexible-Demand-Server must be configurable by the utility customer. EVSE manufacturers are free to configure a default server for their products, but the consumer must be provided a straightforward (and ideally automatable) procedure to configure the server address (URL) to whatever they choose.

Appendix 4 of our Low-Voltage Thermostat RFI comments includes further discussion of how flexible-demand appliances and DERs should communicate and interoperate with a Flexible-Demand-Server.

Finally, please see Appendix 1 in these comments for proposed technical requirements about communications and control standards.

SPAN’s responses to the questions in the October 18, 2024, Request for Information

1. Please provide information to assist the CEC in determining whether the scope of devices in Table 1 meets the needs of FDAS or if the CEC needs to consider revisions to the scope.

Table 1: Examples of In and Out-of-Scope Electric Vehicle Supply Equipment

Potential In-Scope Devices	Potential Out-of-Scope Devices
▪Level 1 Electric Vehicle Supply Equipment ▪Level 2 Electric Vehicle Supply Equipment ▪DC-output Electric Vehicle Supply Equipment ▪Wireless Electric Vehicle Supply Equipment ▪Medium voltage AC input supply Electric Vehicle Supply Equipment ▪Power electronic components inside the Vehicle	▪Pantograph Electric Vehicle Supply Equipment ▪Equipment with an automated connection system

Source: California Energy Commission

We recommend that the CEC consider technology that is required for V2X capabilities as an in-scope device for this FDAS. Specifically, the CEC should add Microgrid Interconnect Devices to the FDAS, because V2X creates additional electric-code requirements on the home that a MID is critical to addressing.

A utility customer with equipment capable of supplying power during a grid outage and/or capable of exporting power to the grid is required to install a device that isolates and disconnects the premise from the grid, called the Microgrid Interconnect Device² (MID). EVSEs supporting V2X will require an MID, and the EVSE and MID must interoperate and work together in order to meet NEC requirements. Utility customers may well have more than one MID-requiring DER, for example, two V2X–EVSEs, a BESS, rooftop photovoltaic (PV, ie. solar)), and a portable generator for emergencies. Each of these MID-requiring DERs will require a MID, and more than one MID per customer would be both infeasible and expensive. This leads to the realization that the MID must be a distinct component, capable of interoperation and control of any number of DERs within the home. In order to foster consumer choice, these separate components may be sourced from different manufacturers, in order to enable this, open (and ideally standard) protocols for MID - DER communication and control is required. SPAN recommends the CEC include the requirement for open MID-DER interoperability in an EVSE FDAS.

2. What is the current landscape of options for charging schedules that prioritize the driver experience, emissions reductions, financial savings, and/or other factors? Please provide information or data on customer receptiveness to various charging schedules, such as charge immediately, charge by departure, etc. and the entity who possesses such information.

Charge schedules are application layer solutions, and the optimal schedules will vary depending upon specific user needs and their local context. It is important to enable continued competition and innovation among charge schedules by mandating open (and ideally, standard) protocols for EV charging control.

Many compelling applications like V2X and charging with excess solar benefit from (or require) low-latency, high-reliability local control. Mandating that open/standard protocols for EV control be accessible over local networks will unlock innovation.

SPAN is actively expanding its suite of charge schedules to suit various user needs and local contexts. As an example, SPAN Drive supports the following charging modes: charge now, charge on schedule, and charge with solar. Each of these modes is used by a large group of SPAN Drive customers to help them achieve their charging goals.

• Charge now: SPAN Drive charges at the maximum rate mutually agreed upon by the EV and EVSE until the EV reaches its charging target or capacity.

• Charge on schedule: SPAN Drive implements the “Charge now” mode, but only during scheduled times. Customers select a start and end hour for charging to apply to week and weekend days.

• Charge with solar: SPAN Drive adjusts the maximum charge rate to match the amount of excess onsite solar generation that would otherwise be exported to the grid. This approach charges the car with low cost, low carbon electricity without increasing the cost or carbon footprint associated with other appliances in the home. In addition, the homeowner can pair this mode with “Charge on schedule” to ensure their car receives a minimum amount of charge overnight given uncertain solar availability. Importantly, charge with solar requires dynamic and real time adjustment of maximum charge rate via a feedback control loop, a requirement we believe is critical for effective EVSE management. We discuss this in greater detail in our response to #6 below.

3. Please comment on the various EVs or EVSE consumer charging preferences such as charge immediately or “charge by departure”, where the EV is charged to a specified percentage with a set time to be ready.

a. How does using charge strategy balance factors as battery life, price, etc.?
b. What consumer data is available that provides customer charging habits such as: demographics and population percentages that prefer to charge at home, at work, or in public shared spaces? What times of day?
c. What charger types are typically used?
d. How do charging patterns change as EV owners gain experience with their vehicle?
e. What percentage of battery capacity is typically charged per session?
f. How is this behavior expected to change as ownership of EVs expands beyond the early adopters?

SPAN does not have a response to this question at this time.

4. When will DC charging equipment be available for residential installation? What are the expected use cases, penetration, price range and power level of DC equipment used in the residential sector? Would certain DC chargers installed at private residences require a Battery Energy Storage System to manage peak load?

SPAN does not have a response to this question at this time.

5. What software and hardware capabilities could enable public EVSEs to relieve/eliminate grid congestion at the Distribution (referring to Transmission and Distribution, T\&D, for the grid) level? What control strategies are available to the grid operator and/or load aggregator to shift and/or curtail demand from EVSEs at the Distribution level to maintain grid reliability?

SPAN does not have a response to this question at this time.

6. Similarly, what software and hardware capabilities are best suited to enable residential EVSEs to relieve grid congestion at the Distribution level? What control strategies can be deployed by the grid operator and/or load aggregator to shift and/or curtail demand from residential EVSEs at the Distribution level support grid reliability?

The required capabilities to shift energy and/or curtail power for EVSEs include:

• Control of starting and stopping an EV charging session.
• Dynamic and real-time control over the maximum power provided to the EV by the EVSE (kW) over the full range of the EVSE’s power capabilities (0% to 100% of maximum output).
• Knowledge of the EV’s current state-of-charge (SOC), and total charge capacity (in kWh).
• Knowledge of the (instantaneous) power available to the EVSE for the charging session (kW).

These capabilities should be supported via a local open network protocol/API, to enable the customer to choose where and how to manage/control EVSE charging. Some customers may choose to manage their EVSE via a Home Energy Management System, or to configure and enroll the EVSE directly to a cloud-based service, offered by the grid operator or a load aggregator.

Dynamic and real-time control requires knowledge of the instantaneous power available. For service upgrade avoidance, power available is the difference between the incoming service rating and the power draw at the service entry. For SPAN Drive’s charge with solar feature, power available is the difference between solar generation and home consumption. Some EVSEs leverage hardwired connections from the EVSE to field-installed current transformers that measure these critical power flows. This approach is expensive and unnecessary when this meter data is available elsewhere in the home. A local open network protocol would enable software/network integrations to send the meter data required by the EVSE over the existing home LAN with low latency, enabling stable and effective feedback control.

Protocols supporting these capabilities are addressed in our response to question #13 below.

7. What hardware and software are needed on the EV’s Onboard Charging System to enable load shifting? What percentage of EVs currently receive grid signals (e.g., electricity prices, GHG emissions and California Independent System Operator Flex Alerts) to schedule load shifting, demand response, and/or bi-directional charging? What percentage of EVs require the EVSE to receive grid signals to schedule load shifting, demand response, and/or bi-directional charging? What are the most common methods for communicating signals to EVSEs and EVs (e.g. Ethernet, Wi-Fi, Cellular, AM/FM broadcast)?

SPAN does not have a response to this question at this time.

8. (Focused on EV manufacturers) Is the EV telematics system used to receive grid signals (e.g., electricity prices, GHG emissions, and California Independent System Operator Flex Alerts) and schedule charging in response to those grid signals? If so, what is the monthly cost charged to the customer for these capabilities?

SPAN does not have a response to this question at this time.

9. How can medium-duty and heavy-duty (MDHD) EVs and their EVSE fit into the CEC’s goal of load shifting to avoid GHG emissions?

SPAN does not have a response to this question at this time.

10. Should the scope of this regulation include load shifting criteria for EVs such as forklifts, boats, and other off-road vehicles? Do off-road vehicles typically have a defined use-cycle that fits the need for load shifting? If so, which types of off-road vehicles? Please provide off-road EV counts, types of EVSE for off-road EVs, and charging strategies for off-road EVs.

SPAN does not have a response to this question at this time.

11. There are currently some buses that use wireless charging to top off batteries at bus stops. What are other applicable uses for wireless charging, and is wireless charging planned in your product roadmap? If so, when is wireless charging expected to be more widely available?

SPAN does not have a response to this question at this time.

12. What are the charging practices for commercial fleets? Bus fleets? Overnight depot level charging? What power levels? How is the charging of the fleet managed? Manually rotated? Management software?

SPAN does not have a response to this question at this time.

13. Which communication protocols or components of existing communication protocols are used to enable load shifting capabilities for EVs and EVSE? What is the implementation status of these communication protocols? Are industry-wide standard communications and control protocols currently in use or planned? Are there remaining gaps to enabling load shifting capabilities?

SPAN’s response to this question is focused on residential EVSEs.

In order to enable load shifting and/or demand response of EVs and EVSEs, both the following are required:

• Demand response protocol: an open (and ideally standard) protocol to connect to a flexible-demand server, for communication of dynamic pricing data, demand response requests, and grid management events to customers.
• Device control protocol: an open (and ideally standard) protocol on the EVSE to enable applications to control EV charging (as detailed in our response to question #6 above).

Residential EVSEs SHOULD support an open demand response protocol, which is capable of communicating with a local or cloud-based price-server of the customer’s choice. Residential EVSEs MUST support an open device control protocol over the home LAN, which is capable of communicating with a local EVSE management application of the customer’s choice.

Existing and emerging protocols meet some, but not all, of these requirements today. For example, consider these three leading protocols:

• OpenADR3 is an open standard protocol that satisfies the requirement of the demand response protocol detailed above. OpenADR v3.1.0 (in process) provides additional capabilities to support “push” notifications by the price-server directly to customers in a manner that interoperates with existing customer Internet modems and firewalls. Incorporating/integrating an OpenADR3 “client” (VEN) into a residential EVSE is both technically and commercially feasible.
• Matter is an open standard device-control-protocol that is rapidly evolving its energy device types, and its capabilities for energy management. The recently announced Matter 1.4 EVSE capabilities do not currently meet all the requirements detailed in our response to question #6, but it seems possible that future versions of Matter may provide all required capabilities. An EVSE FDAS would provide important guidance and motivation to initiatives like Matter to fill these gaps and support the full EVSE device-control requirements.
• Open Charge Point Protocol (OCPP) 2.1 is an open standard EVSE device-control-protocol primarily focused on public/commercial EVSEs, and may evolve to support the requirements for residential EVSEs, particularly if smaller, subset/application-specific profiles were supported.

14. Does data exist on the effect of bidirectional charging on EV battery life? How is battery capacity affected by the frequency and level of bidirectional charging (for example, power level, total energy discharge, and so on)? Does this affect the warranties or insurance of the EV owner? If so, can the loss in value, if any, be quantified over the life of the battery?

SPAN does not have a response to this question at this time.

15. Can a load shift program work with EVSEs/EVs responding to generic signals, or must signals be tailored for each EVSE/EV?

SPAN is focused on open, public, IP network protocols. In these comments, we propose that such protocols should exist for EVSE device control, EVSE communications with the MID, and the flexible demand server. The open protocols for these uses are both sufficient and necessary for flexible demand control of EVSE.

The CEC should discourage proprietary, device-specific signals. Such signals are not required, and would hold back innovation and customer choice.

16. What data or information is needed from the EV and/or EVSE to enable load shift while ensuring driver mobility and range needs are not compromised (for example, kWh needed by the vehicle)? How could this data or information be communicated across all vehicle and supply equipment models, regardless of the manufacturers’ involvement?

In addition to the required capabilities to shift energy and/or curtail power for EVSEs detailed above in our response to question #6, EV/EVSE applications, services, and programs typically require knowledge of the customer’s preferences, needs, and schedule.

Example scenarios might include:

• Customer configures preferences for charging power usage (PV-only, price limits, GHG-impact limits, etc)
• Customer configures required range (SOC) needed by what (departure) time.

SPAN recommends that an EVSE FDAS focus on EVSE technical requirements and capabilities, in order to provide an open and competitive environment that enables EVSE application developers to innovate.

17. What is the energy consumption impact from adding flexible demand capability to existing EVSE?

SPAN does not have a response to this question at this time.

18. Please discuss strategies for EVSE to best utilize the CEC’s Market Informed Demand Automation Server (MIDAS) which provides access to utilities’ time- varying rates, GHG emission signals, and California Independent System Operator (California ISO) Flex Alerts? More detail can be found here: Market Informed Demand Automation Server (MIDAS) (ca.gov).

The current CEC MIDAS server is an innovative prototype/proof-of-concept of a Flexible-demand server, and offers an open, but not standard, protocol.

SPAN recommends that CEC FDAS initiatives define the requirements for the flexible-demand server and its demand response protocol, and subsequently decide between additional MIDAS development to support these requirements, or encouraging grid operators and energy system software and service providers to develop and deploy price-servers, or both.

19. What are the cybersecurity challenges and needs associated with communicating signals from the grid, or a third-party, to accomplish supplying energy to electric vehicles?

SPAN does not have a response to this question at this time.

20. Are there any considerations to ensure equity when developing a load shifting strategy for supplying energy to electric vehicles? For example, are there concerns that flexible demand will be disproportionately accessible based on income level?

SPAN does not have a response to this question at this time.

Appendix 1: Proposed requirements for an EVSE FDAS

We propose that any future EVSE FDAS should incorporate the following requirements in order to deliver the greatest possible customer benefits:

• The EVSE MUST provide an Ethernet network interface, and optionally, MAY provide a Wi-Fi network interface
• The EVSE MUST support a freely-available, openly-specified, IP-network-based protocol for device control, including these capabilities:
  • Control of/over starting and stopping an EV charging session
  • Dynamic control over the maximum power provided to the EV for this charging session (kW)
  • Knowledge of the EVs current state-of-charge (SOC) (in %), and total charge capacity (in kWh)
  • Knowledge of the (instantaneous) power available to the EVSE for the charging session (kW)
• The V2X-EVSE MUST support an openly specified IP-network protocol for communication and coordination with a Microgrid Interconnect Device (MID)
• The EVSE SHOULD support a freely-available, openly-specified IP-network-based protocol for connection to a flexible-demand server, to enable reception of dynamic prices, demand response requests, and grid management events
• The server address/URL of these protocols (if any) MUST be user-configurable
• The protocols MUST support both local and aggregator use-cases, and MUST NOT require an aggregator
• The CEC’s protocol requirements MUST be functional, and performance-based, not limited to a fixed, static version of a particular standard. Technological progress and innovation will occur at a much faster pace than the regulatory process, and defining performance-based capabilities for FDAS will achieve the CEC’s goals in the most effective manner possible.

Our use of requirement key words in bold is consistent with “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels”.