EV charging · Solar · BESS
Industrial PCs for EV Charging & BESS: OCPP Gateways, Load Management and SCADA
Industrial computing hardware for charger OEMs, site-energy integrators and battery storage system builders.
Connecting a charge point to the cloud is only part of the job. A commercial EV charging site must also communicate with power meters, charger modules, battery storage, solar inverters and the operator’s software. The difficult part is keeping these systems coordinated when a network drops, a device reports a fault or the electrical environment becomes noisy.
BITECH designs fanless industrial PCs and customized I/O platforms for these edge-computing roles. Depending on the project, a local PC can host an OCPP client or local-controller application, collect Modbus/CAN data, run site-level energy management software and maintain diagnostic records.
The application software and OCPP interoperability must be integrated and validated by the system owner or software partner.
Send us the charger topology, communications map, software stack and cabinet environment. We will recommend a suitable hardware configuration and validation scope.
01 · System boundaries
What role does an industrial PC play in EV charging infrastructure?
An industrial PC is normally a supervisory or integration layer, not a substitute for the certified charging and electrical safety controllers. Keeping these responsibilities separate makes testing, maintenance and fault handling clearer.
| System layer | Primary responsibility | Typical implementation |
|---|---|---|
| Charging safety and power control | Contactors, protective interlocks, voltage/current control and required safe-state actions | Dedicated EVSE/power-controller hardware and safety mechanisms |
| Vehicle-to-charger communication | EV charging negotiation and, where implemented, ISO 15118 / Plug & Charge | Compatible EVSE communication controller and protocol stack |
| Local site computing | Device aggregation, diagnostics, energy optimization, local applications and potentially OCPP local-controller or charger-side software | BITECH industrial PC plus project software |
| Charge station management | Authorization, fleet/transaction management, reporting and remote operations | CSMS/cloud or on-premises platform |
02 · Where edge computing matters
Five deployment scenarios where edge computing matters
DC fast-charger cabinet integration
A DC charging cabinet may contain several power modules, a meter, thermal sensors, an EVSE controller and multiple service endpoints. A fanless industrial PC can consolidate non-safety telemetry and diagnostic services across Ethernet, RS-485 and CAN. The system integrator defines whether OCPP messages originate from the EVSE controller itself or from an integrated software application on the PC.
Design questionsHow many module buses? What is each CAN bitrate and frame format? Which meter registers are required? What is the restart sequence after loss of auxiliary power?
Multi-charger depot and commercial site load management
A logistics depot, residential complex or workplace charging site may have more connected charging capacity than its grid connection can supply simultaneously. A site edge controller can ingest meter measurements and charger status, then calculate charger power budgets according to a configured policy.
A robust design considers site import limits, phase loading, load-measurement freshness, charger capabilities, reservation priorities and a defined response when communications fail. The policy must be coordinated with the EVSE’s own protective functions and backend workflow.
Solar + BESS + EV charging coordination
At a solar-assisted charging site, local control software can use PV output, site load, battery state-of-charge and inverter limits to schedule charging within the approved operating envelope. Typical field connections include Modbus TCP/RTU to meters and inverters and CAN or Modbus interfaces to BMS/PCS equipment, subject to the vendor protocol documents.
An edge PC can calculate or relay dispatch requests; battery protection and inverter power limits remain enforced by the respective BMS/PCS and protection systems. V2G capabilities require additional vehicle, charger, protocol, interconnection and market compatibility; the IPC alone does not enable V2G.
BESS EMS / SCADA data aggregation
Battery energy storage containers and hybrid power plants often need local historian functions, alarms, protocol conversion and SCADA uplinks. An industrial PC is useful where an integrator needs Linux or Windows applications, more than one independent network, or a mix of serial and Ethernet connections.
Before selecting the PC, specify Modbus register maps, polling intervals, CAN protocols, clock synchronization, local retention, historian storage endurance and write permissions. If IEC 61850 or a utility-specific protocol is required, confirm the application stack and site compliance separately; an Ethernet port alone does not provide protocol compliance.
Unattended sites: diagnostics and recovery
Outdoor chargers and remote energy cabinets need serviceability as much as CPU performance. A local computer can collect timestamped events, link charger faults to field-meter readings, and retain evidence for technicians. With authorized management software, it may support controlled restarts and remote diagnostics without a truck visit for every software issue.
Useful diagnostic fieldsDevice/connector ID, software and firmware versions, last heartbeat, local time quality, communication status, mapped meter values, reset cause, watchdog activity and the last successful transaction or energy record.
03 · Reference design
Reference architecture: EV charging + solar + BESS edge gateway
Field Ethernet / Modbus TCP
CAN / Modbus (vendor-specific)
RS-485 / Modbus RTU
Separate service LAN
- Independent safety and power control
- Vehicle-side communication
- OCPP to CSMS directly or via an explicitly designed local architecture
04 · Protocol planning
OCPP 1.6J, 2.0.1 and 2.1: what should hardware teams plan for?
OCPP is an application-layer protocol between the charging station and the Charging Station Management System (CSMS). It is not a built-in feature of an industrial PC merely because the PC has Ethernet. The selected software must implement the required version, profiles and security behavior.
| Protocol | Practical integration focus | What the project must verify |
|---|---|---|
| OCPP 1.6J | Large installed base; charging sessions, status messages and optional smart charging; security enhancements available | Backend-specific interoperability, accepted security profile, local authorization and reconnect behavior |
| OCPP 2.0.1 | Richer device model, improved transaction handling, security and optional ISO 15118/smart charging functionality | CSMS compatibility, exact certified profiles, firmware management, device-model mappings and migration testing |
| OCPP 2.1 | Adds functions for ISO 15118-20, bidirectional charging and distributed energy resource integration | Real vendor support, required functional blocks and test coverage; do not equate protocol publication with deployment readiness |
For authoritative versions, test editions and certification profiles, see the Open Charge Alliance OCPP specification and OCPP testing update.
05 · Resilience
Offline-first charging: design the recovery path before the outage
Real deployments expose weaknesses that an online-only demo does not. The right fallback is project-specific, but a typical review should cover:
- Before outagePersist time, station/connector identifiers, approved operating limits and the minimum data needed for diagnostics or transaction recovery.
- When WAN disappearsKeep EVSE safety and site electrical limits locally enforced. Apply the defined offline authorization and charging policy; do not assume every charger may continue charging.
- During outageBuffer eligible meter and event records within an agreed retention and storage-endurance budget. Record ordering, timestamps and device reboot events.
- On reconnectionReconcile station and backend state, retry eligible records without unbounded duplicates, and handle transactions interrupted by reboot or connectivity loss.
- After recoveryAlert operators to data gaps, clock issues, meter-value mismatches and persistent device faults.
06 · Site power
Dynamic load management: local decisions, verified limits
Dynamic load management (DLM) is not just a dashboard chart. The controller must translate real electrical constraints into commands supported by the chargers.
Typical inputs
Site meter, per-phase capacity, other facility loads, active EVSE connections, charger power capability, PV generation, BESS operating limits and local policy.
Typical outputs
Site charging budgets, charger setpoints or charging profiles, event alarms and operator-facing explanations for throttling decisions. The applicable communication method may be OCPP smart charging, a supported local controller interface or a charger-vendor API.
Failure behavior
Define a conservative fallback if measurements become stale, a charger rejects a setpoint or two controllers disagree. The charging site’s upstream electrical protection and approved installation limits remain mandatory.
07 · Interfaces
Modbus, CAN, Ethernet and ISO 15118: do not confuse the layers
| Device or connection | Common interface or protocol | Engineering check |
|---|---|---|
| Electrical meters | Modbus RTU (RS-485) or Modbus TCP | Register definitions, scaling, units, update period, meter accuracy and clock |
| BESS PCS / solar inverter | Vendor Modbus TCP/RTU, sometimes other OT protocols | Register write authority, ramp limits, fallback behavior and firmware variation |
| BMS / charger power modules | CAN 2.0 / CAN FD or vendor-specific serial | Bitrate, termination, message IDs, isolated bus requirements and validated drivers |
| Charge station to CSMS | OCPP over secured transport according to implementation | Version, security profile, mapping, state sync and transaction recovery |
| Vehicle to compatible charger | ISO 15118 family over the EVSE’s dedicated communication subsystem | EVSE chipset, communication stack, PKI and vehicle interoperability |
| Local service and uplink | Ethernet, cellular router, VPN / secure remote management | Network separation, authentication, logs, provisioning and recovery |
08 · Fleet operations
Industrial cybersecurity and device lifecycle
With an always-connected charging or energy fleet, operations teams need to plan for more than a firewall checkbox:
- Separate field/control networks from Internet-facing administration and remote service where the architecture calls for it.
- Use supported TLS configurations, correct certificate issuance, rotation and revocation, and role-based remote access.
- Validate secure boot / TPM options only for product variants that actually support them; build signed-update and rollback behavior in the end-to-end software process.
- Record device identity, software version, configuration history, alarms and authorized remote changes.
- Model recovery from failed firmware updates and interrupted power during flash operations.
- Maintain approved hardware revisions, spare inventory and a documented PCN/EOL process rather than assuming a CPU swap never affects requalification.
Open Charge Alliance published an updated Security Operations Guide, Version 2 in September 2026, including guidance for local controllers, defense in depth and the separation of CPO and CSMS security responsibilities.
09 · Hardware evaluation
Recommended BITECH platforms for early hardware evaluation
Hardware selection depends on the actual fieldbus map and software requirements. These are possible starting platforms, not pre-certified, ready-to-deploy EV charging solutions.
Multi-network gateway
DC charger cabinet, multi-network EV charging site gateway
4 independent GbE ports, 6 COM, dual CAN, 9–36 V DC; optional isolation configurations
Check: CAN/serial mapping, isolated-port options, exact CPU/OS SKU and site temperature
View AX-134BT →
Compact x86
Compact x86 charging/SCADA edge controller
Compact modular fanless platform, CAN-capable field I/O, Ethernet and wide DC input
Check: CAN versus CAN FD availability and driver support for the ordered board revision
View AX-130BT →
Isolated ARM node
Isolated BESS/BMS communications gateway or Linux/ARM site node
RK3588J, 3 GbE, dual CAN, RS-485 and other isolated I/O; vendor lists 4,000 V isolation withstand
Check: Linux BSP, software compatibility, exact isolation test conditions and temperature derating
View AE-3588BT →
Need a lower-cost box for only a few Modbus meters? Or a specialized fieldbus, cellular or isolated-I/O arrangement? BITECH can review the carrier board and enclosure requirements before quoting OEM/ODM customization. High TOPS or a discrete GPU is generally not required for ordinary OCPP, Modbus aggregation or site load-management tasks.
For interface selection, also see Industrial PC Galvanic Isolation, CAN Bus Isolation Engineering and the Industrial PC Design Guide.
10 · Validation
Qualification checklist: prove the system in real failure conditions
A field-ready test plan should include the exact IPC SKU, power supply, enclosure, I/O wiring, software version and connected devices. Agree on pass/fail criteria with the system integrator.
| Test | What to verify |
|---|---|
| OCPP / CSMS interoperability | Required version and feature profiles, charger state, authorization, transaction and meter mappings |
| WAN interruption and recovery | Defined offline behavior, local data retention, reconnection, reconciliation and duplicate handling |
| Charger and gateway power cycles | Safe charger state, boot time, time synchronization, filesystem integrity and replay behavior |
| DLM failure scenarios | Stale meter data, incorrect scaling, unavailable chargers, setpoint rejection and fallback limits |
| BESS/PCS interface | Vendor registers and CAN frames, write permissions, limits, communication-loss response |
| Serial/CAN physical layer | Termination, grounding, isolation boundary, bus error rate and simultaneous-port stress |
| EMC and power disturbances | Applicable ESD/EFT/surge immunity, supply dips and equipment-level test scope |
| Cabinet thermal conditions | Sustained CPU/I/O/storage temperatures at site worst-case ambient and mounting orientation |
| Security and service | Provisioning, certificate rotation, update rollback, least privilege and audit logs |
| Lifecycle serviceability | Approved BOM, software image, spares, revision notices and field replacement process |
11 · Customization
OEM / ODM customization for charger and energy-system manufacturers
BITECH can assess projects that require different fieldbus counts, connector placement, isolation boundaries, 24 V cabinet integration, cellular expansion, a customer-controlled software image, DIN/wall mounting or enclosure adaptations. We recommend defining the interface map and failure model before freezing the carrier board.
For multi-year installations, BITECH can discuss controlled BOM, PCN, last-time-buy planning and successor-board compatibility. The actual availability term, notice period, NRE, MOQ and qualification scope should be confirmed in the project quotation.
What to include in your engineering RFQ
- ApplicationDC fast charger / AC site management / solar + BESS / BESS EMS / SCADA
- TopologyNumber of chargers, PCS/BMS devices, meters, LAN segments and remote sites
- InterfacesRS-485, RS-232, CAN/CAN FD, Ethernet, DIO, wireless, connector pinout and bus isolation requirements
- SoftwareLinux or Windows, OCPP software owner/version, CSMS provider, Modbus register list and fieldbus drivers
- EnvironmentSupply voltage, min/max cabinet temperature, grounding, surge exposure, mounting and service access
- Failure rulesSite power cap, WAN/PC outage policy, local retention period, restart expectations and safety boundaries
- ProgramForecast volumes, pilot quantity, region, compliance targets and expected product lifetime
Request an EV charging / BESS industrial PC configuration review →
12 · FAQ
Frequently asked questions
Can a BITECH industrial PC run OCPP 2.0.1 or OCPP 2.1?
It may host compatible customer- or partner-developed application software, subject to operating system, resources and driver support. OCPP is not automatically included with the hardware. The application must implement the required version and be tested with the target CSMS and EVSE architecture.
Is an industrial PC required inside every EV charger?
No. Many chargers have their own embedded controller and connect directly to a CSMS. An industrial PC becomes useful when a charger OEM or site integrator needs additional computing, multi-device aggregation, local EMS logic, service tools or extensive industrial I/O.
Can the PC replace the EVSE safety controller or BMS?
No. Dedicated, appropriately designed and approved safety and power-control functions must remain independent. The industrial PC is primarily an application, communications and supervisory component.
How does a charging site work if 4G/5G or the cloud is unavailable?
That depends on the charger, authorization policy and software architecture. A properly designed site may continue only those functions that can be executed safely and legitimately offline, retain eligible records and reconcile states after reconnection. All offline behavior must be explicitly specified and tested.
Does OCPP 2.1 mean every charger now supports vehicle-to-grid (V2G)?
No. OCPP 2.1 adds support for bidirectional and energy-resource use cases, but actual V2G also depends on a compatible EV, charger power electronics, ISO 15118-20 implementation, grid interconnection and the software/regulatory environment.
Can an IPC combine EV charging, solar and BESS energy management?
Yes, as a computing platform for an integrator’s EMS or gateway software, when the protocol interfaces and resources are compatible. PCS/BMS protective limits and site electrical protection must still operate independently.
Is isolated CAN or RS-485 mandatory for every site?
No. Specify isolation according to grounding domains, field cable lengths, common-mode voltage, noise exposure and applicable design standards. Request the exact port-level isolation ratings and system EMC test evidence before choosing the option.
Do we need a high-performance GPU for an EV charging gateway?
Usually not. Most OCPP, Modbus, logging and load-management workloads are better sized by I/O, storage endurance, software compatibility and reliability. A GPU or AI accelerator is relevant only for a defined additional workload, such as video analytics or thermal-image processing.