
Sign up to save your podcasts
Or


You know the feeling.
You’re low on range. The map says there’s a charger around the corner. You pull up — relief. And then… black screen. Or “out of order.” Or worse: it looks fine, but nothing happens.
That moment — that tiny spike of anxiety — is the real enemy of EV adoption.
In this episode of Coordinated with Fredrik, we go deep into the engineering side of that problem. Not surface-level EV talk. Not market hype. We unpack the actual backend architecture required to build a charging network that doesn’t break — and more importantly, one that scales.
This was a special deep dive made for David and the team at Sourceful Energy. The mission:
How do you build a truly robust charging network using OCPP — but do it in a modern, open-source, event-driven way that fits a NATS-based architecture?
Why OCPP 2.0.1 Is the Only Serious Choice Today
We trace the evolution of OCPP from the early SOAP-based days (heavy XML over fragile 2G connections) to the WebSocket revolution of 1.6 — and then to the modern architecture of 2.0.1.
Here’s the punchline:
* 1.6 works, but it’s messy and vendor-fragmented.
* 2.0.1 is structured, hierarchical, and event-driven.
* It has native certificate handling.
* It supports granular device modeling.
* It enables accurate transaction handling.
* It’s built for ISO 15118 and plug-and-charge.
* And it cleanly prepares you for OCPP 2.1 and bidirectional charging (V2X).
If you’re building from scratch in 2026, there’s no serious argument for staying on legacy 1.6 unless hardware forces your hand.
The Architecture Question: Don’t Build a CSMS From Scratch
The temptation is obvious: “We’re engineers. Let’s build it ourselves.”
That’s a trap.
Implementing the full OCPP spec — properly — is a multi-year effort. Edge cases, retries, timeouts, certificate handling, WebSocket state management… it’s a black hole.
Instead, we explore the open-source landscape:
* The old monolithic Java servers.
* Client-side firmware stacks.
* And finally: a modern, modular TypeScript-based backend designed for 1.6 and 2.0.1 side by side.
The key architectural insight:
Use a modular OCPP engine as the edge gateway.Inject a custom NATS adapter.Publish clean, validated events into your own internal event-driven system.
Let OCPP parsing and compliance live at the edge.Let your business logic live in your own microservices.
That separation is everything.
NATS + OCPP 2.0.1 = Clean Topic Hierarchies
OCPP 2.0.1’s hierarchical device model maps beautifully to NATS subject structures.
Instead of a generic firehose of messages, you can structure topics like:
ocpp.v2.station-42.evse1.connector.temperature
Now your billing service only subscribes to transaction events.Your analytics service subscribes to metering data.Your ops dashboard listens to error codes.
Fully decoupled. Clean. Scalable.
This is how you avoid turning your backend into a spaghetti monolith.
Reliability Is Not a Feature — It’s the Product
Up to 25% of public chargers can be non-functional at any given time. That’s not a UX issue. That’s a systemic architectural failure.
A huge reason: vague error reporting.
If your charger only reports “Other error,” your operations team has no choice but to roll a truck. That’s expensive. And slow.
In the episode, we talk about:
* Mandating standardized granular error codes.
* Using compliance tools to verify hardware implementations.
* Making reliability a contractual requirement in procurement.
Because here’s the uncomfortable truth:
The world’s best backend can’t fix bad firmware.
Architecture and hardware procurement strategy must align.
The Bigger Play: From Charger to Grid Asset
We close the episode with something bigger.
OCPP 2.1 introduced proper bidirectional charging (V2X). That means EVs stop being passive loads and start becoming active grid assets.
If your backend is:
* Event-driven
* Granular
* Secure
* High-throughput
You’re not just running a charging network.
You’re laying the foundation for a virtual power plant.
And that only works if the software pipes are designed correctly from day one.
If you’re building infrastructure — not just apps — this episode is for you.
This wasn’t about theory. It was about architecture decisions that determine whether your network becomes resilient, scalable, and future-proof — or collapses under its own complexity.
Thanks for tuning in to Coordinated with Fredrik.
More deep dives coming.
By Fredrik AhlgrenYou know the feeling.
You’re low on range. The map says there’s a charger around the corner. You pull up — relief. And then… black screen. Or “out of order.” Or worse: it looks fine, but nothing happens.
That moment — that tiny spike of anxiety — is the real enemy of EV adoption.
In this episode of Coordinated with Fredrik, we go deep into the engineering side of that problem. Not surface-level EV talk. Not market hype. We unpack the actual backend architecture required to build a charging network that doesn’t break — and more importantly, one that scales.
This was a special deep dive made for David and the team at Sourceful Energy. The mission:
How do you build a truly robust charging network using OCPP — but do it in a modern, open-source, event-driven way that fits a NATS-based architecture?
Why OCPP 2.0.1 Is the Only Serious Choice Today
We trace the evolution of OCPP from the early SOAP-based days (heavy XML over fragile 2G connections) to the WebSocket revolution of 1.6 — and then to the modern architecture of 2.0.1.
Here’s the punchline:
* 1.6 works, but it’s messy and vendor-fragmented.
* 2.0.1 is structured, hierarchical, and event-driven.
* It has native certificate handling.
* It supports granular device modeling.
* It enables accurate transaction handling.
* It’s built for ISO 15118 and plug-and-charge.
* And it cleanly prepares you for OCPP 2.1 and bidirectional charging (V2X).
If you’re building from scratch in 2026, there’s no serious argument for staying on legacy 1.6 unless hardware forces your hand.
The Architecture Question: Don’t Build a CSMS From Scratch
The temptation is obvious: “We’re engineers. Let’s build it ourselves.”
That’s a trap.
Implementing the full OCPP spec — properly — is a multi-year effort. Edge cases, retries, timeouts, certificate handling, WebSocket state management… it’s a black hole.
Instead, we explore the open-source landscape:
* The old monolithic Java servers.
* Client-side firmware stacks.
* And finally: a modern, modular TypeScript-based backend designed for 1.6 and 2.0.1 side by side.
The key architectural insight:
Use a modular OCPP engine as the edge gateway.Inject a custom NATS adapter.Publish clean, validated events into your own internal event-driven system.
Let OCPP parsing and compliance live at the edge.Let your business logic live in your own microservices.
That separation is everything.
NATS + OCPP 2.0.1 = Clean Topic Hierarchies
OCPP 2.0.1’s hierarchical device model maps beautifully to NATS subject structures.
Instead of a generic firehose of messages, you can structure topics like:
ocpp.v2.station-42.evse1.connector.temperature
Now your billing service only subscribes to transaction events.Your analytics service subscribes to metering data.Your ops dashboard listens to error codes.
Fully decoupled. Clean. Scalable.
This is how you avoid turning your backend into a spaghetti monolith.
Reliability Is Not a Feature — It’s the Product
Up to 25% of public chargers can be non-functional at any given time. That’s not a UX issue. That’s a systemic architectural failure.
A huge reason: vague error reporting.
If your charger only reports “Other error,” your operations team has no choice but to roll a truck. That’s expensive. And slow.
In the episode, we talk about:
* Mandating standardized granular error codes.
* Using compliance tools to verify hardware implementations.
* Making reliability a contractual requirement in procurement.
Because here’s the uncomfortable truth:
The world’s best backend can’t fix bad firmware.
Architecture and hardware procurement strategy must align.
The Bigger Play: From Charger to Grid Asset
We close the episode with something bigger.
OCPP 2.1 introduced proper bidirectional charging (V2X). That means EVs stop being passive loads and start becoming active grid assets.
If your backend is:
* Event-driven
* Granular
* Secure
* High-throughput
You’re not just running a charging network.
You’re laying the foundation for a virtual power plant.
And that only works if the software pipes are designed correctly from day one.
If you’re building infrastructure — not just apps — this episode is for you.
This wasn’t about theory. It was about architecture decisions that determine whether your network becomes resilient, scalable, and future-proof — or collapses under its own complexity.
Thanks for tuning in to Coordinated with Fredrik.
More deep dives coming.