<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Jessie Wei</title>
    <description>The latest articles on DEV Community by Jessie Wei (@jessieiot).</description>
    <link>https://dev.to/jessieiot</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3831198%2Fe612ae9c-1e25-481f-b76c-1019340b384c.png</url>
      <title>DEV Community: Jessie Wei</title>
      <link>https://dev.to/jessieiot</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/jessieiot"/>
    <language>en</language>
    <item>
      <title>The "Crypto-Agility" Crisis: Overcoming the Physical Limits of Legacy EV Chargers</title>
      <dc:creator>Jessie Wei</dc:creator>
      <pubDate>Thu, 28 May 2026 23:22:15 +0000</pubDate>
      <link>https://dev.to/jessieiot/the-crypto-agility-crisis-overcoming-the-physical-limits-of-legacy-ev-chargers-17ja</link>
      <guid>https://dev.to/jessieiot/the-crypto-agility-crisis-overcoming-the-physical-limits-of-legacy-ev-chargers-17ja</guid>
      <description>&lt;p&gt;With the rapid expansion of EV infrastructure, a massive technical debt has emerged: millions of legacy charging stations are operating on early Open Charge Point Protocol (OCPP 1.5 or 1.6J) versions. They primarily run on Security Profile 0 or 1, meaning all critical data (RFID tags, billing meters, remote commands) is transmitted over standard WebSocket (ws://) in plain text.&lt;br&gt;
Recent regulations, such as the UK’s Smart Charge Points Regulations and the EU’s RED (EN18031), now strictly mandate encrypted communications (mTLS, or OCPP Security Profile 3). The obvious software engineering answer would be an Over-The-Air (OTA) firmware update. But out in the field, we hit a hard physical wall.&lt;br&gt;
The Hardware Wall: Why OTA Fails on Cortex-M3/M4&lt;br&gt;
Early EV chargers were built with highly resource-constrained embedded microcontrollers (MCUs) to control costs. Upgrading from plain text to Profile 3 (mTLS) isn't just a configuration flip; it triggers a severe "Crypto-Agility" crisis.&lt;br&gt;
The RAM Bottleneck: Traditional non-secure mode requires &amp;lt; 10 KB of RAM for the TCP/IP stack. However, modern TLS 1.2/1.3 protocol stacks (even optimized ones like mbedTLS or WolfSSL) require 50-100 KB of heap memory to cache the certificate chain and encryption context during the handshake. On an MCU with only a few hundred KB of RAM, enabling TLS starves the core charging logic, leading to memory overflows and watchdog resets.&lt;br&gt;
CPU Overhead: The TLS handshake involves computationally intensive asymmetric encryption (RSA or ECC). On these low-power MCUs, a handshake can take several seconds. If the network drops (common in 4G IoT), frequent reconnections peg the CPU, delaying real-time charging control tasks and triggering watchdog timeouts.&lt;br&gt;
Flash limitations: Profile 3 requires mTLS, meaning the device needs a secure enclave to store private keys and enough Flash space to dynamically update Root CA lists. Legacy file systems simply do not have this capacity.&lt;br&gt;
The Architectural Fix: Transparent Edge Proxy&lt;br&gt;
Faced with the "rip and replace" economics (which costs up to $210,000+ for a DC Fast Charger site including civil works and power upgrades), we explored alternative architectures. A "Cloud-to-Cloud" proxy doesn't solve the first-mile interception risk on the local LAN or ISP.&lt;br&gt;
The solution we engineered is a hardware-based transparent edge proxy gateway. It acts as a "security coprocessor" deployed inside the charger's cabinet.&lt;br&gt;
Bi-directional Protocol Conversion: The gateway runs a high-performance embedded Linux environment. Southbound, it simulates a local CSMS, accepting the legacy Profile 1 (ws://) connection over the internal LAN. Northbound, it acts as the true OCPP client, initiating a Profile 3 (wss://) mTLS tunnel to the cloud. The dumb terminal thinks it's talking to an insecure server, while the cloud sees a fully compliant mTLS client.&lt;br&gt;
Decoupling Certificate Management: Legacy chargers don't support the ACME protocol for certificate rotation. The gateway intercepts SignCertificate.req and InstallCertificate.req commands from the cloud. It generates the CSR, manages private keys, and updates Root CAs on behalf of the legacy charger, making the entire certificate lifecycle transparent to the old hardware.&lt;br&gt;
Beyond TLS: Logic Injection for Legacy Gear&lt;br&gt;
By placing compute at the edge, we unlocked unexpected capabilities. Older OCPP 1.6J chargers cannot handle complex Smart Charging profiles. By acting as a Local Controller, the gateway can ingest complex Time-of-Use (TOU) or OCPP 2.0.1 load-balancing policies from the cloud, parse them, and inject simple rate-limiting commands (SetChargingProfile) that the legacy 1.6J MCU can understand.&lt;br&gt;
Additionally, because the edge proxy implements EN18031 standards, it can run a local Intrusion Detection System (IDS) to block LAN-based DoS attacks, preventing malicious traffic from exhausting the fragile legacy MCU.&lt;br&gt;
By offloading cryptography and complex logic to an edge proxy, we can bridge the gap between insufficient embedded hardware and modern security regulations, preventing millions of functional chargers from becoming premature e-waste.&lt;/p&gt;

</description>
      <category>architecture</category>
      <category>cybersecurity</category>
    </item>
    <item>
      <title>Upgrading legacy OCPP 1.6J chargers to mTLS: How are you handling the MCU memory constraints?</title>
      <dc:creator>Jessie Wei</dc:creator>
      <pubDate>Fri, 22 May 2026 11:56:38 +0000</pubDate>
      <link>https://dev.to/jessieiot/upgrading-legacy-ocpp-16j-chargers-to-mtls-how-are-you-handling-the-mcu-memory-constraints-5ce4</link>
      <guid>https://dev.to/jessieiot/upgrading-legacy-ocpp-16j-chargers-to-mtls-how-are-you-handling-the-mcu-memory-constraints-5ce4</guid>
      <description>&lt;p&gt;Has anyone else hit a brick wall trying to get older EV chargers to support OCPP Security Profile 3?&lt;br&gt;
We were looking at modernizing a batch of existing stations running on early Cortex-M3 and M4 microcontrollers. The initial thought was to just push an OTA firmware update to enable mTLS to meet newer cybersecurity regulations. But the physics of these old boards just don't add up.&lt;br&gt;
When you try to run modern TLS 1.2 or 1.3 stacks like mbedTLS, it demands something like 50 to 100 KB of heap memory just to cache the certificate chain and manage the encryption context during the handshake. For these older MCUs, that instantly causes memory overflows. Even when we tried to strip it down, the asymmetric encryption computation took so long that it triggered watchdog timeouts and rebooted the chargers.&lt;br&gt;
Since doing a full "rip and replace" of the hardware is way out of budget, I've been reading up on edge security proxy gateways. The concept is deploying an embedded Linux device locally on the charger's LAN. It essentially does a transparent bi-directional protocol conversion: taking the legacy unencrypted ws:// connection locally and wrapping it into a highly secure wss:// mTLS tunnel to the cloud.&lt;br&gt;
The technical part that caught my eye is how it handles certificate lifecycles. Legacy chargers obviously don't support the ACME protocol. But apparently, this Linux proxy can intercept the SignCertificate.req commands coming from the cloud CSMS, generate the CSR locally, and update the root certificates without the legacy hardware even knowing it's happening.&lt;br&gt;
Has anyone actually deployed a hardware-based OCPP proxy like this in the field? I'm curious if intercepting these payloads introduces any noticeable latency when authorizing a charge.&lt;/p&gt;

</description>
      <category>cybersecurity</category>
      <category>discuss</category>
      <category>iot</category>
      <category>performance</category>
    </item>
    <item>
      <title>Breaking Through the Reliability Bottleneck of EV Charging Networks: How Dual-Channel Edge Gateways Reshape OCPP Communication Architecture</title>
      <dc:creator>Jessie Wei</dc:creator>
      <pubDate>Thu, 07 May 2026 09:49:04 +0000</pubDate>
      <link>https://dev.to/jessieiot/breaking-through-the-reliability-bottleneck-of-ev-charging-networks-how-dual-channel-edge-gateways-4fp3</link>
      <guid>https://dev.to/jessieiot/breaking-through-the-reliability-bottleneck-of-ev-charging-networks-how-dual-channel-edge-gateways-4fp3</guid>
      <description>&lt;p&gt;I. Data Congestion and Privacy Deadlocks under Single-Channel Architecture&lt;/p&gt;

&lt;p&gt;Why does the charge failure rate of public high-power Direct Current Fast Charging (DCFC) networks remain persistently high, even hovering between 14% and 19%? An in-depth analysis reveals that the core factor causing the unreliability of charging networks is often not merely hardware manufacturing defects, but rather systemic contradictions deeply rooted in the communication architecture of the charging infrastructure network.&lt;/p&gt;

&lt;p&gt;In the traditional single-channel Open Charge Point Protocol (OCPP) deployment model, all business logic, equipment telemetry, hardware diagnostics, and transaction billing data are forcibly packaged and transmitted to the Charge Station Management System (CSMS) via a single WebSocket channel. As equipment becomes increasingly complex, severe data granularity and privacy conflicts have erupted between Charge Point Operators (CPOs) and Operations and Maintenance (O&amp;amp;M) service providers:&lt;/p&gt;

&lt;p&gt;Channel Congestion Leading to Transaction Loss: To perform AI-based predictive maintenance, O&amp;amp;M platforms need to continuously extract physical-layer sensor data (such as voltage fluctuations, temperature curves, etc.) at the second or even millisecond level. When massive amounts of high-frequency telemetry data instantly saturate the WebSocket bandwidth, it easily blocks the user's charging Authorize messages, triggering authentication timeouts and internal protection mechanisms, which directly leads to charging startup failures and revenue loss for CPOs.&lt;/p&gt;

&lt;p&gt;Multiparty Collaboration Barriers and Privacy Compliance Risks: Because all diagnostic data is uploaded to the CSMS alongside transaction data, third-party O&amp;amp;M providers must obtain access to the CPO's core platform to access this data. This not only crosses the CPO's commercial red lines but is also highly prone to violating the data minimization principle of the European Union's General Data Protection Regulation (GDPR), leading to the exposure of EV owners' sensitive Personally Identifiable Information (PII) and even introducing severe cybersecurity hacking risks. This creates "data silos," forcing O&amp;amp;M teams to adopt an inefficient, "reactive" blind troubleshooting model.&lt;/p&gt;

&lt;p&gt;"The traditional single-channel OCPP architecture forcibly conflates core commercial billing data with high-frequency physical telemetry data, which is the structural root cause of charging network channel congestion, order loss, and sensitive privacy leaks."&lt;/p&gt;

&lt;p&gt;II. The Direct Benefits of Dual-Channel Gateways: Predictive Maintenance and Full-Dimensional Compliance&lt;/p&gt;

&lt;p&gt;How can Charge Point Operators (CPOs) implement predictive maintenance for EV charging networks and meet stringent global regulatory compliance requirements without exposing consumer privacy (PII) and core business systems? The "Dual-Channel Intelligent Gateway" architecture proposed by WISEWISH TECHNOLOGY offers a highly cost-effective solution.&lt;/p&gt;

&lt;p&gt;By decoupling data at the network edge, this solution brings immediate financial and compliance benefits to CPOs and asset owners:&lt;/p&gt;

&lt;p&gt;Significantly Reducing OpEx and Shortening MTTR: Relying on a fully desensitized health channel, O&amp;amp;M platforms can utilize AI models to capture "weak signals" such as voltage ripples and minute contactor voltage drops, accurately predicting component lifespans before catastrophic failures occur. This data-driven predictive maintenance can reduce redundant, blind on-site diagnostic visits by over 70%, helping CPOs directly save approximately 30% or more in overall Operational Expenditure (OpEx).&lt;/p&gt;

&lt;p&gt;Achieving "Autonomous Driving" in Transnational Compliance: Facing the dual pressures of the 97% uptime required by the US NEVI program and the European AFIR regulation mandating the provision of high-frequency dynamic data to National Access Points (NAPs), intelligent gateways can automatically extract operational status at edge nodes. It locally converts this status into government-standard datasets and pushes it directly to dedicated regulatory APIs, achieving system-level automated compliance.&lt;/p&gt;

&lt;p&gt;Zero-Trust Architecture Isolating Compliance Risks: Perfectly aligning with the EU NIS2 Directive and the Cyber Resilience Act (CRA), this architecture firmly restricts the risk of a compromised third-party supply chain exclusively to the O&amp;amp;M data domain, thoroughly circumventing GDPR violation risks. It eliminates transaction timeouts caused by data queuing, ensures assets remain in optimal operating condition throughout their lifecycle, and maximizes the Return on Investment (ROI).&lt;/p&gt;

&lt;p&gt;"Implementing predictive maintenance through edge decoupling can reduce blind on-site diagnostic visits by over 70% and significantly shorten Mean Time To Recovery (MTTR), thereby directly saving CPOs approximately 30% in overall operational expenditures."&lt;/p&gt;

&lt;p&gt;III. Technical Pathway of the Dual-Channel Intelligent Gateway&lt;/p&gt;

&lt;p&gt;How can we physically and logically separate the core business billing channel from the highly concurrent equipment health diagnostic channel at the network edge? WISEWISH TECHNOLOGY's "Dual-Channel Intelligent Gateway," based on the rich "Device Model" and Local Controller definitions in the OCPP 2.0.1 specification, provides an industrial-grade edge proxy architecture.&lt;/p&gt;

&lt;p&gt;The specific technical implementation of the gateway includes the following core components:&lt;/p&gt;

&lt;p&gt;Edge Proxy Termination and Deep Packet Inspection (DPI):&lt;br&gt;
The secure WebSocket connection initiated by the charging station is directly "terminated" at the edge gateway. The gateway's edge computing engine performs high-speed Deep Packet Inspection (DPI) on every OCPP 2.0.1 payload to identify specific ComponentName and Variable tags, subsequently "bifurcating" the traffic into two independent uplinks.&lt;/p&gt;

&lt;p&gt;Constructing Isolated Dual Data Channels:&lt;/p&gt;

&lt;p&gt;OCPP Value Channel (Business Lifeline): Routes extremely time-sensitive core functional blocks, including authentication, billing, and load balancing, to the traditional left-side WSS channel directly connected to the CPO's CSMS. This ensures the lowest Round-Trip Time (RTT) and the highest QoS priority.&lt;/p&gt;

&lt;p&gt;MQTT Health Channel (Physical Diagnostics): Strips high-frequency physical health features (data generated by diagnostic modules) from the business layer and dynamically translates them into an MQTT publish/subscribe model specifically designed for IoT, pushing them to third-party O&amp;amp;M platforms. This achieves physical network Micro-Segmentation, allowing O&amp;amp;M parties to simply anonymously subscribe to relevant topics without needing access to the CSMS.&lt;/p&gt;

&lt;p&gt;Data Dimensionality Reduction Empowered by Edge Computing:&lt;br&gt;
For high-frequency telemetry data, the gateway implements dead-band filtering and a Report-by-Exception mechanism at the edge, while introducing compression algorithms such as Swinging Door Trending (SDT). This effectively filters out redundant background data, reporting only feature values like Total Harmonic Distortion (THD), thereby reducing cloud bandwidth requirements and storage pressure by up to 98%.&lt;/p&gt;

&lt;p&gt;Highest Level of Security Configuration:&lt;br&gt;
The gateway compulsorily enforces the stringent Security Profile 3 (strong authentication based on mutual TLS certificates) of OCPP 2.0.1 in both directions. Simultaneously, it acts as an application-layer intelligent firewall, intercepting unauthorized commands and completely defending against Man-in-the-Middle (MitM) attacks and malicious payload tampering.&lt;/p&gt;

&lt;p&gt;"Deploying a dual-channel intelligent gateway at the edge dynamically bifurcates the OCPP data stream into a WSS value channel and a lightweight MQTT health channel via Deep Packet Inspection (DPI). This not only thoroughly resolves communication concurrency congestion but also achieves a zero-trust physical micro-segmentation between commercial billing and physical diagnostics."&lt;/p&gt;

&lt;p&gt;Author's Note: This article is based on professional research in the fields of Industrial Internet of Things (IIoT) connection architecture and Electric Vehicle (EV) infrastructure security upgrades, aiming to provide practical guidance on high-information-density, compliant, and secure edge gateway communication topologies for global high-power charging networks.&lt;/p&gt;

</description>
      <category>architecture</category>
      <category>iot</category>
      <category>networking</category>
      <category>systemdesign</category>
    </item>
    <item>
      <title>How to Upgrade "Dumb" Legacy EV Chargers to OCPP 2.0.1 (Without Ripping Them Out)</title>
      <dc:creator>Jessie Wei</dc:creator>
      <pubDate>Tue, 21 Apr 2026 09:25:00 +0000</pubDate>
      <link>https://dev.to/jessieiot/how-to-upgrade-dumb-legacy-ev-chargers-to-ocpp-201-without-ripping-them-out-56p9</link>
      <guid>https://dev.to/jessieiot/how-to-upgrade-dumb-legacy-ev-chargers-to-ocpp-201-without-ripping-them-out-56p9</guid>
      <description>&lt;p&gt;The global EV charging network is growing up. We are officially transitioning from the "wild west" era of massive, blind deployment into a phase of highly refined operations and smart grid integration. The simple land grab is over; today’s game is all about software management, system integration, and squeezing the ultimate utilization out of your hardware.&lt;/p&gt;

&lt;p&gt;But here is the massive architectural headache facing Charge Point Operators (CPOs) right now: What do you do with the massive inventory of legacy chargers already in the field?&lt;/p&gt;

&lt;p&gt;Most of these older units have incredibly weak compute power and zero "crypto-agility." They simply can't handle modern security protocols or complex smart charging logic.&lt;/p&gt;

&lt;p&gt;Our engineering team tackled this head-on. The result? An OCPP Security Proxy Gateway. It’s not just a security patch; it’s a foundational piece of middleware that bridges the gap between aging hardware and modern, intelligent network platforms.&lt;/p&gt;

&lt;p&gt;Here is a look at how this architectural approach solves the legacy hardware problem:&lt;/p&gt;

&lt;p&gt;🚫 Beating the "Rip &amp;amp; Replace" Trap (and CAPEX nightmare)&lt;br&gt;
When new cybersecurity regulations hit, the default industry panic is often to just rip out the old hardware and replace it. That is a massive waste of capital.&lt;/p&gt;

&lt;p&gt;By taking a retrofitting approach with a proxy gateway, you bypass the hardware replacement entirely.&lt;/p&gt;

&lt;p&gt;The Math: It saves over 90% in costs per unit compared to replacement.&lt;/p&gt;

&lt;p&gt;The Deployment: It’s a 20-minute, plug-and-play installation.&lt;/p&gt;

&lt;p&gt;The Compliance: It instantly elevates legacy hardware to pass stringent cybersecurity frameworks, including UK OPSS and EU RED/EN18031.&lt;/p&gt;

&lt;p&gt;🔄 Translating OCPP 2.0.1 on the Fly (The Integration Bridge)&lt;br&gt;
The gateway goes beyond simple encryption—it acts as a dedicated "Local Controller" at the edge.&lt;/p&gt;

&lt;p&gt;Legacy chargers only understand simple commands. Modern platforms want to push advanced OCPP 2.0.1 complex load balancing strategies. Through underlying logic injection and protocol conversion, the gateway translates these advanced 2.0.1 payloads into standard OCPP 1.6J commands that legacy hardware can actually execute. It essentially gives "dumb terminals" the brains to participate in modern smart-charging ecosystems.&lt;/p&gt;

&lt;p&gt;🛠️ Decoupled Diagnostics &amp;amp; "Dashcam" Observability&lt;br&gt;
In the IoT world, if you can't observe it, you can't fix it. We implemented an industry-first "Dual-Channel" smart O&amp;amp;M architecture.&lt;/p&gt;

&lt;p&gt;This separates the core business logic (charging transactions) from the diagnostic telemetry, allowing them to run entirely independently. We paired this with an "automatic anomaly capture" feature—think of it like a dashcam for your charger's data stream. When something goes wrong, the gateway remotely reconstructs the fault scene.&lt;/p&gt;

&lt;p&gt;The result? It slashes troubleshooting time by 60% and practically eliminates the expensive, old-school model of "rolling a truck and sending a tech just to see what's broken."&lt;/p&gt;

&lt;p&gt;The Takeaway&lt;br&gt;
The future of EV charging networks will be won by those who build a solid, scalable digital foundation. Achieving high-quality, refined operations doesn't necessarily mean throwing away your legacy assets—it means giving them the integration layer they need to talk to modern software.&lt;/p&gt;

</description>
      <category>evcharging</category>
      <category>iot</category>
      <category>ocpp</category>
      <category>edgecomputing</category>
    </item>
  </channel>
</rss>
