Co-located renewables and BESS only deliver full value when CAN networks are solid. Here’s how to fix data, IDs, and remote access to make assets future-ready.

Most utility-scale solar and wind projects built in 2025 have the same hidden dependency: a quiet little communication bus called CAN that either keeps everything humming—or quietly sabotages performance.
Here’s the thing about co-located renewables and battery energy storage systems (BESS): the business case looks brilliant on paper. Store excess solar at midday, discharge into the evening peak, bid into frequency regulation and ancillary services, and suddenly a project that barely pencilled out is throwing off solid returns.
But when those batteries, inverters, protection devices, and controllers can’t reliably talk to each other, all that value evaporates fast. Missed signals turn into curtailed energy, stuck assets, truck rolls, and safety headaches.
This post builds on insights from the “Inside CAN Networks: Solving Core Communication Challenges in Co-located Renewables and BESS” webinar with HMS Networks, and connects them to the wider green technology story: smarter, cleaner infrastructure driven by data and automation.
We’ll break down why CAN-based communication is fragile in large BESS, what goes wrong in the field, and how to design CAN networks that actually support your revenue model instead of fighting it.
Why CAN networks matter in co‑located renewables and BESS
Robust CAN communication is the difference between a controllable energy asset and an expensive metal box.
In co-located projects, BESS is no longer an optional add-on; it’s the core control element that makes a hybrid plant dispatchable. To do that, the BESS has to exchange real-time data with:
- PV or wind plant controllers
- Inverters and PCS
- Battery management systems (BMS)
- Fire detection and suppression systems
- Site SCADA and grid operator interfaces
Most of that device-level communication rides on Controller Area Network (CAN), especially in the 10MWh–500MWh range where modular racks and second-life batteries are common.
When the CAN network falters, you see:
- Random PCS trips and nuisance alarms
- State-of-charge (SoC) mismatches across racks
- Limited ability to respond to grid signals (AGC, FFR, FCR, etc.)
- Longer commissioning times and more site visits
From a green technology standpoint, that’s a big deal. Poor communication undermines the flexibility that makes renewables behave like reliable grid assets. If a battery can’t respond in milliseconds because its CAN bus is choking on traffic or errors, you lose the services that justify the investment.
The reality? Most companies underestimate how quickly CAN complexity explodes once you cross the 10MWh mark.
Core communication challenges in large BESS CAN networks
Large CAN networks in BESS run into the same fundamental issues over and over. If you’re planning or operating a hybrid renewable site, these are the problems you should assume you’ll face.
1. Data integrity in noisy, large-scale environments
For BESS above ~10MWh, you’re dealing with:
- Long cable runs
- Multiple cabinet levels
- High electromagnetic interference (EMI) from switching devices
- Temperature swings and humidity
All of that punishes CAN physical layers. The classic symptoms:
- Rising error counters on nodes
- Intermittent packet loss
- Devices dropping off the bus under high load
Once data integrity slips, SoC calculations drift, alarms misfire, and the energy management system (EMS) starts operating on stale or incorrect information.
Practical ways to keep CAN stable:
- Segment the network: Instead of one massive CAN bus across 50+ racks, split into logical segments with dedicated gateways. Shorter runs, fewer nodes per segment, easier troubleshooting.
- Use proper termination and shielding: It sounds basic, but incorrect 120Ω termination and poorly grounded shields still cause a huge share of field issues.
- Monitor bus health, not just device alarms: Use gateways or edge devices that can expose error frames, bus load, and node status to SCADA. If you can’t see the bus, you can’t fix it.
- Design for EMI from day one: Route CAN away from high-current cables, use twisted pair and shielded cable, and coordinate with electrical designers instead of treating comms as an afterthought.
2. Interoperability across multi-vendor, multi-life components
Co-located plants rarely come from a single vendor. You see:
- New LFP racks from Vendor A
- Second-life packs from EV OEM B
- Inverters from Vendor C
- PCS and controllers from yet another supplier
Each of those devices arrives with its own CAN profile, quirks, and expectations. Some follow CiA standards, some follow their own proprietary mapping, and some barely follow anything.
What typically goes wrong:
- Different byte orders and scaling for the same parameter
- Conflicting assumptions about heartbeat and timeout behavior
- Incompatible firmware revisions silently changing CAN messages
That kills install schedules and creates long-term maintainability problems.
What works better:
- Standardize on a plant-level “canonical” CAN model. Use a gateway or protocol converter as the translation layer, instead of forcing every vendor to integrate with everyone else.
- Lock down message catalogs in contracts. Treat CAN frames and object dictionaries as part of the spec, not a nice-to-have appendix.
- Plan for firmware drift. Assume that at some point, a vendor firmware update will change CAN behavior. Choose architectures that can adapt in the field (e.g., configurable gateways vs. hard-coded device mappings).
3. CAN ID conflicts and second‑life batteries
Second-life batteries are great for circular economy metrics and capex, but they create a special kind of headache: overlapping CAN identifiers.
If several identical modules all ship with the same default CAN IDs, dropping them onto a shared bus without coordination guarantees conflicts. Nodes start talking over each other, the bus saturates, and some devices “win” while others effectively disappear.
In real projects, that often shows up as:
- Racks that never report valid SoC
- Intermittent or inconsistent temperature readings
- Modules that only respond when others fail
How to eliminate CAN ID conflicts:
- Use address management at the gateway level. Let a gateway or master device remap IDs logically, instead of relying on manual DIP switch settings per rack.
- Implement a consistent ID scheme per site. Don’t reuse factory-default IDs; define a numbering policy that matches your topology (string-level, rack-level, module-level).
- Bake ID management into commissioning procedures. If your FAT/SAT checklists don’t include CAN ID verification, they should.
4. Limited remote access and expensive truck rolls
Modern green technology isn’t just about clean hardware; it’s about software-defined operation. Yet a surprising number of BESS sites are still effectively “air-gapped” when it comes to field diagnostics.
When a CAN network misbehaves and there’s no secure remote access, you burn days waiting for a tech to:
- Drive to site
- Plug in a laptop
- Capture bus traces
- Guess at the root cause
By that point, lost revenue from downtime often dwarfs the cost of a remote connectivity solution.
Why secure remote access changes the economics:
- VPN-based access lets engineers capture CAN traffic, tweak gateway configs, and push firmware updates without leaving their desk.
- OTA (over-the-air) updates keep gateways and edge devices aligned with evolving grid codes and market rules.
- Centralized fleet monitoring turns field data into continuous improvement, not just firefighting.
From a lead-generation perspective, this is where many operators start looking for partners. Once a site has suffered a few preventable outages, the business case for professional remote connectivity and CAN diagnostics is suddenly very clear.
Designing “future-ready” CAN communication for green energy assets
Future-ready in this context doesn’t mean buzzwords; it means a CAN and connectivity architecture that survives the next decade of:
- Capacity expansions
- Regulatory changes
- New markets (capacity, inertia, fast frequency response)
- Component replacements and technology refreshes
Here’s how I’d approach it if I were designing a co-located renewables + BESS project today.
Start with the data model, not the cable schedule
Too many projects wire devices first and ask “what data do we actually need?” later.
A better approach:
- Define the control use cases: frequency response, peak shaving, arbitrage, black start, etc.
- Map the data requirements for each: SoC granularity, response times, redundancy.
- From there, design the CAN message set and polling strategy. Only then decide how to wire it.
This keeps the network lean and focused. You’re not just shoving every possible register over CAN “just in case”.
Treat CAN gateways as strategic infrastructure
Gateways and protocol converters used to be seen as a necessary evil. In modern green technology projects, they’re strategic:
- They decouple vendor-specific CAN quirks from your plant logic.
- They expose diagnostics and bus statistics to SCADA and cloud systems.
- They give you a control point for security, rate limiting, and traffic shaping.
Investing in robust gateway architecture early generally saves far more than it costs in avoided custom integration and field debugging.
Bake cybersecurity into remote access from day one
Energy infrastructure is now a prime cyber target. That doesn’t mean you should ban remote access; it means you should do it properly.
Baseline practices that work well:
- VPN tunnels with strong authentication and role-based access
- Audit trails of who connected, when, and what changed
- Segmentation between OT networks and corporate IT
Done right, secure remote access makes a site safer, not riskier, because you reduce the pressure for ad-hoc workarounds like open ports, unmanaged 4G routers, and orphaned laptops.
How AI and data are reshaping CAN-based green infrastructure
This blog series looks at green technology through an AI lens, and CAN networks for BESS fit that story perfectly.
Most people think of AI in energy as fancy forecasting or bidding algorithms. That’s part of it. But none of that intelligence matters if the underlying data is garbage. Clean, structured, reliable data from CAN networks is what lets AI:
- Predict failures in battery modules before they cascade
- Optimize charge/discharge strategies using real-time cell health
- Detect anomalies that hint at cyber issues or hardware faults
A few practical examples I’m seeing gain traction:
- AI-assisted commissioning: tools that ingest CAN traces during site acceptance tests and automatically flag misconfigurations, timing issues, or ID conflicts.
- Predictive maintenance models: using years of CAN data (currents, temperatures, error codes) to recommend targeted replacements instead of calendar-based swaps.
- Adaptive control strategies: EMS platforms that adjust control loops in real-time as they learn how specific batteries and inverters behave across seasons.
The bottom line: if you want to benefit from AI in your green energy portfolio, you first need a communication layer that’s trustworthy. Fixing CAN is one of the highest-ROI steps you can take.
Where to go next if you’re wrestling with CAN in BESS
If your co-located renewables or BESS project is already showing CAN-related issues—unstable comms, weird SoC behavior, painful remote diagnostics—you’re not alone. Most operators only realise how critical the communication design is after the first major outage.
Priorities I’d set for the next 3–6 months:
- Audit your CAN architecture: segmentation, termination, device counts, and error rates.
- Document your message catalog: what’s on the bus today, how it’s scaled, and where the gaps are.
- Introduce proper remote access: secure VPN-based diagnostics with the ability to capture bus traffic.
- Plan for growth: if you doubled your MWh capacity, would the current CAN design survive?
For teams looking to make these changes quickly, partnering with specialists who live and breathe CAN, gateways, and BESS is usually the fastest path. The upside isn’t just technical elegance; it’s higher revenue, lower O&M, and assets that actually behave like the flexible, low-carbon resources your models promised.
Green technology isn’t only about new chemistries or bigger turbines. Often, the real step change comes from getting the “small” things right—like a robust, future-ready CAN network that lets your AI, your operators, and your assets pull in the same direction.