A Proprietary System Locked Out of the Open Charging Network
The company sold EV charging stations paired with a centralized energy management controller. The stations themselves were non-networked. The controller handled scheduling, load balancing, and communication with a proprietary cloud dashboard. It worked, but it was a closed system.
That closedness was becoming a liability. Charge Station Management Systems from third party networks could not talk to the hardware. Utility rebate programs and state incentives increasingly required OCPP compliance as a condition of eligibility. Customers were asking for interoperability, and the company had no answer beyond a vague promise to look into it.
The core question was whether the existing hardware could be made OCPP compliant at all, or whether the path forward required a wholesale redesign. The energy management controller ran on a PIC32MX microcontroller, a capable but resource constrained chip with no memory management unit and no ability to run Linux. Most open source OCPP implementations assumed a server class machine. The firmware was written in C and used SNMP for communication. Nobody on the team had tried to wedge a second protocol stack into that environment before.
Evaluating the Path and Mapping the Roadmap
Sequoia Applied Technologies is a Santa Clara software engineering firm that builds embedded systems, IoT platforms, and cloud infrastructure for cleantech, life sciences, and enterprise software companies. This engagement was a feasibility study and roadmap, not a full implementation. The goal was to determine what OCPP compliance would require and whether the existing platform could support it.
The first task was understanding the OCPP standard itself. The specification runs over 400 pages and defines a sprawling set of functional blocks, use cases, and messages. Not all of it is mandatory. The standard distinguishes between basic functionality, covering 32 use cases across 8 functional blocks, and the minimum device model, which specifies what must be implemented to create a working OCPP system. Neither of these officially constitutes certification, but together they provide a defensible basis for a compliance claim.
The second task was mapping the existing architecture to OCPP topologies. The standard supports 6 topologies. Topology 4, where non-OCPP charging stations connect to a CSMS through an OCPP compliant local controller, fit the existing product structure exactly. The energy management controller would become that local controller. The charging stations would remain unchanged. The controller would speak OCPP upstream to third party networks while continuing to use the proprietary protocol downstream to the stations.
The third task was the gnarliest: evaluating whether the PIC32MX platform could actually host an OCPP stack. Most open source OCPP libraries are written in Java, Python, or Scala. These are non starters on a microcontroller with no operating system and limited memory. The team searched for C language implementations targeting the charging station side of the protocol rather than the server side. The plan was to find a suitable library, trim non mandatory sections to fit the memory footprint, and integrate it alongside the existing SNMP stack.
Dual Protocol Stack on a Microcontroller
The architecture that emerged from the feasibility study placed two protocol stacks on the energy management controller: the existing proprietary stack for backward compatibility with installed systems, and the new OCPP stack for interoperability with third party networks. Both would share the TCP/IP network interface. The proprietary stack was slated for migration from SNMP to AWS IoT with MQTT, which aligned with separate dashboard modernization work Sequoia was doing for the same client.
The energy management controller ran on a Microchip PIC32MX processor, a 32 bit MIPS core without a full memory management unit. The platform could not run Linux. Available memory was constrained and not fully documented, so one deliverable of the feasibility study was to establish the actual resource headroom after setting up the development environment.
Existing firmware was written in C. The feasibility study evaluated FreeRTOS adoption to provide task scheduling and timing services needed by the OCPP stack. Development setup required the ICD3 in circuit debugger, correct compiler and optimization settings, CAN message testing hardware, and the latest firmware source from the existing team.
Most open source OCPP libraries target the server side and are written in high level languages. The feasibility study searched for C language implementations of the charging station side, evaluated partial implementations and sample code, and prepared a trimming plan to remove non mandatory functionality. If no suitable library existed, porting from Java was identified as a fallback.
The architecture mapped to OCPP Topology 4, where non-OCPP charging stations connect to a CSMS via an OCPP compliant local controller. Topology 6, which adds parallel control by a separate energy management system, was identified as an optional extension given the controller's existing load balancing role.
The feasibility study also flagged additional data acquisition requirements. OCPP messaging depends on charge session events like StartOfCharge and EVDisconnect, metering data, and driver authorization. The existing non-networked charging stations did not surface this data to the controller. Completing the OCPP integration would require either hardware modifications to the stations or workarounds at the controller level.
A Phased Roadmap to Compliance and Incentive Eligibility
Sequoia delivered a phased roadmap covering four stages: development environment setup, FreeRTOS feasibility assessment, OCPP stack evaluation and selection, and lab validation using a simulated CAN environment. The roadmap acknowledged the dependencies between the OCPP work and the parallel AWS IoT migration, noting that solving the development setup challenges once would benefit both efforts.
The roadmap positioned the company to make a defensible OCPP compliance claim based on the minimum device model and basic functionality defined in the standard. It identified the OCA test suite as the validation mechanism and flagged interoperability testing with third party CSMS platforms as the final gate before any public compliance claim. The outcome opened the door to national charging networks, utility rebate programs, and state incentive eligibility that had previously been out of reach.
For companies in similar situations, the broader lesson is that OCPP compliance does not necessarily require replacing existing hardware. The standard's topology options accommodate a range of architectures, and a local controller approach can preserve installed base while adding interoperability. The hard part is fitting the protocol stack onto resource constrained firmware, which demands careful library selection, ruthless trimming, and hands on validation rather than assumptions about what open source code can do out of the box.
Common Questions About OCPP Compliance and EV Charging Firmware
What is OCPP and why does it matter for EV charging infrastructure?
OCPP is the Open Charge Point Protocol, a communication standard maintained by the Open Charge Alliance that defines how charging stations talk to Charge Station Management Systems. It matters because OCPP compliance unlocks interoperability with third party networks and is often a prerequisite for state, federal, and utility incentive programs. Without it, charging station owners are locked into proprietary ecosystems and may be ineligible for rebates.
Can you add OCPP compliance to existing EV charging hardware without replacing it?
In many cases, yes. The OCPP standard supports multiple topologies, including Topology 4 where non-OCPP charging stations connect to a CSMS through an OCPP compliant local controller. This is the path Sequoia evaluated for this engagement. The existing charging stations remained unchanged while the energy management controller received firmware modifications to support the OCPP protocol stack alongside the existing proprietary protocol.
What are the challenges of implementing OCPP on a resource constrained microcontroller?
Most open source OCPP libraries are written for server class systems running Linux, in languages like Java, Python, or Scala. A microcontroller like the PIC32MX lacks a full memory management unit and cannot run Linux. That rules out most off the shelf stacks. The implementation requires either finding or porting a C language OCPP client, trimming non mandatory sections to fit the memory footprint, and validating that the remaining functionality meets the minimum device model defined in the standard.
What does OCPP certification actually require?
At the time of this engagement, an official OCPP certification program was still being developed by the Open Charge Alliance. The standard defines a minimum device model and a set of basic functionality covering 32 use cases across 8 functional blocks, but explicitly states that implementing these does not guarantee certification. The practical path to a compliance claim involves implementing the minimum device model, testing against the OCA test suite, and validating interoperability with third party CSMS platforms.
What did Sequoia deliver for this OCPP compliance engagement?
Sequoia delivered a phased roadmap covering development environment setup, FreeRTOS feasibility assessment, open source OCPP stack evaluation and selection, and lab validation using a simulated CAN environment. The roadmap addressed the dual protocol stack requirement, memory and resource constraints of the PIC32MX platform, and the additional data acquisition capabilities needed to support OCPP messaging such as charge session events and metering data.
What kind of companies does Sequoia Applied Technologies work with on embedded firmware?
Sequoia Applied Technologies is a Santa Clara, California software engineering firm that works with product companies across cleantech, IoT, life sciences, and enterprise software. Embedded engagements include firmware development for microcontrollers and SoCs, protocol stack integration, FreeRTOS and bare metal implementations, and hardware bring up. The firm has delivered similar work for distributed energy storage systems, industrial IoT, and medical devices.