Embedded Product Development for EV Charging

Most EVSE projects stall not at the schematic but at integration: the power stage, the pilot firmware, the energy meter, the OCPP cloud, and the enclosure are each built by a different vendor and nobody owns the seam where they meet. We develop the whole charge point as one product, so the contactor sequencing, the CP/PP state machine, the metering tariff, the OCPP backend, and the IP-rated mechanics are designed together and walk into certification as a single accountable system.

Challenges specific to EV Charging

• Subsystem vendors don't own the integration seam

  The power-board house, the firmware shop, and the cloud team each pass type-test in isolation, but the assembled EVSE fails because nobody validated contactor-to-pilot-to-OCPP behavior end to end under a real charge session.

• OCPP backend rejects the charger in roaming networks

  A homegrown OCPP 1.6J implementation drops StatusNotification ordering or mishandles RemoteStartTransaction, so the unit works on the bench but is refused certification by Hubject or the operator's CPMS during interoperability testing.

• Energy metering isn't billing-grade

  Sessions are billed off a non-certified current sensor, so the kWh figure has no MID/Eichrecht traceability and the operator cannot legally invoice drivers or settle roaming charges across the network.

• Enclosure passes the lab but not the curb

  An IP54 rating proven on a clean sample fails after a winter of driven rain and road salt because cable-gland sealing, condensation drainage, and gasket compression were never designed for a pole-mounted outdoor unit.

• Certification is discovered, not designed

  IEC 61851, EMC, and safety requirements are treated as a final gate, so the team finds at type-test that the contactor weld-detect, RCD coordination, or surge front-end has to be redesigned, blowing the launch by months.

• Firmware and power stage fight over fault handling

  The control firmware and the power hardware disagree on who opens the contactor on an over-temperature or insulation fault, so faults are handled twice, or not at all, leaving a hazard or nuisance trips that strand drivers.

How GizanTech solves them

1. Single-owner subsystem integration. 1. We own the full EVSE build and write an interface contract between power stage, CP/PP firmware, metering, and OCPP, validating the assembled unit through scripted end-to-end charge sessions (plug-in, authorize, energize, meter, stop, fault) before anything reaches a certification lab.
2. Certified OCPP connectivity stack. 2. We implement OCPP 1.6J and 2.0.1 against the Open Charge Alliance test tool, getting StatusNotification, transaction, and smart-charging messaging right, and run interoperability against the target CPMS and roaming hub so the charger is accepted, not just bench-functional.
3. Billing-grade energy metering. 3. We integrate an MID-approved / Eichrecht-capable energy meter module with a tamper-evident data path, signing session kWh so the operator has legally invoiceable, roaming-settleable energy records rather than uncertified sensor estimates.
4. Pilot and power-stage fault arbitration. 4. We define one fault authority: the CP/PP firmware drives the IEC 61851 state machine and the contactor, with hardware interlocks for over-temperature, insulation, and RCD/RDC-DD events, so every fault has exactly one owner that opens the contactor safely.
5. Outdoor enclosure and ingress design. 5. We design the enclosure to a real IP54/IP65 target: gasket compression budget, cable-gland sealing, condensation drainage, and thermal venting validated for pole and wall mount, so the rating holds after field weather, not just on a lab sample.
6. Certification-led product plan. 6. We build IEC 61851, IEC 61000 EMC, and safety requirements into the architecture from day one, run pre-compliance scans in-house, and hand the lab a type-test-ready unit with a traceable requirements-to-test matrix to compress the certification timeline.