Design tradeoff

EV Charger Service Panel Design: Keep Secure Communication Outside the Local HMI

Published by Baoshengda ยท 2026-08-26

Three membrane HMI panels with network status indicators, local navigation keys, flex tails and connectors

An EV charger service panel should not own the security of vehicle, charger or energy-system communications. The system owner must keep authentication, authorization, protocol handling, credentials, backend access and charging control outside the membrane HMI quote. The panel drawing should instead define the local actions it can request, the states it can display, what remains visible when a network path is unavailable and how each key or indicator connects to the controller. SAE J2931/7, revised August 24, 2026, addresses security requirements across plug-in vehicles, charging equipment and connected energy systems. For a component buyer, the practical response is a clear responsibility boundary plus mounted sample evidence, not a claim that the keypad itself secures communication.

Why the August 24 SAE revision matters to the panel drawing

The SAE document covers digital communication among a plug-in electric vehicle, electric vehicle supply equipment and other connected entities such as utilities, energy-management systems and distributed-energy aggregators. It is a system-security document, not a membrane-switch specification. That distinction is precisely why it is useful during HMI design handoff.

When security, status display and physical control appear on one front panel, teams can easily treat them as one purchasing scope. They are not. A local key may request a login, service mode, retry or information screen, but the controller must decide whether the request is allowed. A green indicator may report an authenticated or connected state, but the lamp does not create that state. A panel supplier can build the input and indication path only after the buyer defines the state supplied by the system.

This allocation should be settled before artwork approval. Otherwise a legend such as CONNECTED, READY or AUTHORIZED can acquire different meanings across firmware, backend, service and purchasing teams. Changing that meaning after tooling or sample approval can alter legends, indicator windows, circuits, tail pins and the mounted acceptance test at the same time.

Split the front interface into five state groups

Do not begin with colors. Begin with the decisions the user or service technician must make. Assign a stable identifier to every key and indicator, then place it in one of five groups.

1. **Power and hardware availability:** whether the local control electronics are powered and able to report a state. This does not prove network access or authorization.

2. **Physical connection:** whether the cable, connector or vehicle-side condition detected by the charger meets the system's defined threshold. The panel only displays the controller output.

3. **Communication progress:** whether a communication attempt is starting, pending, successful, degraded or failed. Define timeout and retry display behavior rather than using one ambiguous NETWORK lamp.

4. **Authorization and charging permission:** whether the system has accepted the relevant credentials and permits the next controlled action. Keep the decision in the secure controller or connected system, not in a local contact closure.

5. **Service and local navigation:** page movement, information display, controlled acknowledgement and other non-safety technician actions. Each key remains a request subject to controller rules.

For every group, write the source of truth. If an indicator combines several conditions, document the precedence. A red communication lamp should not mask a separate enclosure-temperature or hardware fault that still needs a local service response.

Use a responsibility map before price comparison

A useful quotation table does more than name the visible feature. It identifies who defines the state, what the component supplier builds and what the mounted sample must prove.

Interface itemSystem owner must definePanel supplier can quote and inspectMounted acceptance evidence
Local navigation or service keyAllowed states, controller action, lockout and rejected-request behaviorLegend, key geometry, embossing or dome, circuit contact, tail conductor and connector pinCorrect controller input for valid and invalid states, plus visible feedback
Power indicatorExact monitored rail or controller state, on/off/blink logic and diagnostic meaningWindow, color target if specified, LED circuit within buyer-supplied limits and light-control constructionState meaning under normal startup, controlled shutdown and restart
Communication indicatorSource signal, connecting/connected/failed meanings, timeout and priorityArtwork, discrete window, specified LED circuit and assigned terminationVisible progress and failure sequence without implying authorization
Authorization or ready stateCredential handling, permission logic, backend or vehicle response and expiryLegend and indication path driven by the buyer's controller signalState appears only when the authorized controller output is present
Offline or degraded modeWhich functions remain available, prohibited or locally viewableSeparate state window or legend, local navigation contacts and circuit mappingNetwork-loss sequence shows the agreed local state and blocks prohibited requests
Tail and connectorController-side pin assignment, mating part, electrical limits and grounding approachConductor routing, tail outline, stiffener, exposed contacts or specified connector and outgoing inspectionCorrect orientation, strain relief, enclosure clearance and stable connection after service access

Keep connector views explicit. Name whether the pin diagram is viewed from the contact side, mating side or cable exit. A mirrored pin map can make a visually correct sample report the wrong state. The buyer should also supply voltage, current, polarity and drive details for each LED or backlight path rather than asking the panel supplier to infer them from color.

Prove local and offline behavior on the mounted sample

A loose component can pass dimensions, continuity and cosmetic inspection while the charger still presents confusing states after installation. Use a controlled bench fixture or authorized charger test mode to exercise a short state sequence without creating unsafe charging conditions.

Start with the unit unpowered and confirm that no powered-state legend is falsely visible. Apply the agreed local supply and verify the hardware-available state before enabling a network path. Present the controller outputs for communication pending, connected and failed states one at a time. Check that indicator positions, brightness distinction and legend masking remain understandable in the intended ambient light.

Next, remove or simulate loss of the approved communication path at the controller level. Verify which local information remains viewable, which requests are rejected and what visible feedback follows a rejected key press. Restore the path and confirm that the panel reports the controller's recovered state without retaining an obsolete lamp. If a power cycle is part of field service, repeat the sequence after a controlled restart.

Finish with the physical installation evidence: key actuation at center and practical off-center positions, window registration, adhesive perimeter, flat enclosure support, tail first-bend clearance, connector seating and service access. Record expected inputs and visible outputs before the test. A note that the panel "works" does not distinguish physical continuity from correct system behavior.

Keep cybersecurity and charging control outside the component quote

A membrane HMI supplier can manufacture and inspect the graphic overlay, fixed key zones, embossing, tactile stack, spacers, adhesive, printed circuit, flexible tail, connector, indicator windows and specified LED or backlight circuits. The supplier can test agreed dimensions, appearance, continuity, contact behavior, tail geometry and component-level lighting attributes.

The panel supplier cannot certify compliance with SAE communication-security requirements, provision or protect system credentials, validate the vehicle handshake, authorize a charging session, approve backend security, determine charging power, rewrite controller firmware or complete the charger risk assessment. Electrical safety, functional safety, cybersecurity architecture, network recovery and the final installed-system acceptance remain with the EVSE owner and its authorized hardware, software, security and compliance teams.

A local key labeled START, STOP, RESET or AUTHORIZE is not a safety-rated or security-enforcing control merely because of its legend. If a function needs a safety-rated device, secure element, protected credential path or independently validated controller, specify that system separately. The membrane panel may request or display the result, but it must not be used as evidence that the protected decision is correctly implemented.

What drawing, sample and RFQ package should the buyer send?

For an HMI panel solution with fixed keys and status indicators quotation, send a controlled package that keeps the physical component scope separate from the secure system scope:

If a requirement is still undecided, label it open rather than allowing a supplier to infer it. The quotation can then separate defined production scope from engineering questions, and sample approval can prove the local interface without overstating system security. When the boundary map, drawing and mounted test are ready, submit them through the Request Quote page for an engineering review.

Need help reviewing a structure?

Send your drawing, photos, application, and quantity. Baoshengda can help check the structure before sampling.

Send Drawing for Quote