Engineering

How will zonal architecture impact automotive troubleshooting?



A zonal power distribution network for cars offers many benefits, but how it affects finding problems is unclear.

In the few years, I’ve been seeing a lot of stories about zonal architecture, the next stage in the evolution of providing power to the many dispersed automotive-electronics functions. This architecture is increasingly being designed into cars for many solid technical reasons.

What is a zonal architecture? I won’t do a deep dive into details, as it has been discussed in detail in EDN and elsewhere. In short, it divides the car’s power distribution network (PDN) along geographic zones, each with a regional power controller, and all supplied by a central power controller and the car batteries. Each of these regional controllers provides power to the local regulators of individual modules in the car – cars now typically have over a hundred of these, permeating and managing every nook and cranny.

On the face of it, zonal makes a lot of sense with respect to weight, cabling complexity, power-systems management, and many other critical factors. This is especially the case as the siting and number of zones can be adjusted to fit the vehicle arrangement (Figure 1).


Figure 1 A zonal architecture assigns a controller (power manager) to different physical areas of the car, and the number and placement of these zones is flexible. (Image source: EV Engineering Online)

It is a radical departure from its predecessor, usually called a domain or centralized architecture (Figure 2). In that classic arrangement which has been used for decades, power distribution is not determined by the physical or spatial location of loads in the car, but rather the function of the module(s) being supported. For example, the four power windows might have a single power unit for all four windows (and maybe the trunk release) with DC rail cabling running to all these locations.


Figure 2 In the widely used domain architecture, controllers are assigned to cover one or more related functions (left); in the zonal approach, the controller division is by physical location the vehicle. (Image source: EETimes Asia)

The domain architecture was the second stage in this evolution. It was the successor to tried-and-true distributed power, which is conceptually the simplest and made a lot of sense in cars when there were relatively few electrical loads.

Distributed power is clear: each load, such as the radio, lights, starter motor, or dashboard, has a direct connection to the battery (regulators were largely non-existent) with a simple on/off switch for that loop (there might be an intermediate relay for higher-current loads). Each loop and load was physically and electrically separate and independent of all the others.

This arrangement made it easy to add loads or disconnect them. Even better, when the car was off – meaning the physical key was out of the ignition – there was zero vampire drain. The only drain on the battery was its self-drain of around a few percent per month.

Why I’m intrigued by the zonal architecture

I’ve been especially interested in the promised benefits of zonal control since I have had a run of electrical problems in my basic ICE 2019 Subaru Outback with 60,000 miles. This car predates zonal distribution, and even uses tangible buttons (networked, of course) for most functions such as A/C; the touch screen is only for secondary functions such as radio, map, and housekeeping (you can drive the car without problem even if that screen blanks out.)

I’ve had these three problems, directly or indirectly related to “vampire drain”:

  1. First, the car’s 3G transponder, formally called a Telematics Data Communication Module (TDCM or DCM), kept trying to connect to that service, thus killing the battery. The problem is that 3G is being “sunsetted”, so nearby towers were going dark, and it was trying to link up with a non-existent service (or what if it was in an underground garage?). It kept trying and trying, killing the battery since I didn’t start the car for a few days. The dealer replaced the module free of charge for this known but kept-quiet design flaw.
  2. Then, a module that controls power flow to other modules when the car is nominally off malfunctioned and allowed too much vampire current to flow. Again, the module was replaced at no cost to me, but not until I had to jump-start the car.
  3. Finally, the door-lock module malfunctioned, and I could only get into the car using the mechanical key that comes with the electronic key fob. While that would be a major annoyance, the added problem was that in this fault mode, the module continued to drain excessive power, again killing the battery.

Yet in all the talk about the zonal architecture, I have seen barely any mention of how it impacts electrical-system troubleshooting. Will it make it easier, harder, or very difficult?

Speaking as a car owner – not as a designer or manufacturer – that’s an important issue.  As cars get more complicated electrically with mandated features, enhanced drive-train control (where ICE, EV, or hybrid), ADAS functions, and more “smarts”, dealing with something that is no longer working can be an impressive challenge leading to quick, easy, and incorrect answers.

How so? When I brought my car to the dealer for each of the three problems with the symptom “dead battery,” the service tech checked the charging system, saw that was good, and so assumed it had to be a bad battery (each time replaced under warranty). Yet the real problems were those load modules drawing vampire current for various reasons.

What’s my user-side concern?

I’m not at all saying that the zonal architecture is a bad thing or a step backwards. I am only observing the extent to which its proponents – all very credible people – have focused almost entirely on its design/build impact and not discussed any in-the-field troubleshooting considerations.

I’ve been burned before by this scenario, and so I get a little worried when proponents of a new architecture or technology talk almost exclusively about its virtues but ignore discussion of any drawbacks. As engineers, we know that nearly every design decision involves pros and cons with respect to overall performance, weight, efficiency, manufacturability, and cost, and these have to be weighed against each other. Nearly every advance also has some downside ranging from trivial to a somewhat bigger deal.

This happened with USB-C and USB-PD (Power Delivery): whatever your requirements within its large power-range “envelope”, USB-C in conjunction with USB-PD is posited as the “universal” solution. Yet experience has shown that such broad, all-encompassing solutions can get a little too clever for themselves, as they try to accommodate so many use cases and scenarios. There are so many power-interconnect arrangements and possibilities, with so many variations, that many cannot be anticipated, tested, or validated despite a detailed standard. USB-C and USB-PD embed the opposite of the engineer’s top rule: keep it simple.

I expressed my concerns about USB-C and USB-PD in a recent EDN blog and received some supporting comments (USB-C and Power Delivery: Too much of a good thing?). As further confirmation, my colleague, EDN’s Associate and Contributing Editor Brian Dipert – who has much more hands-on experience in power interconnects and related – expressed similar concerns along with evidence (USB-C’s lingering incompatibilities and other complexities, part 1: Direct-connect complications and USB-C’s lingering incompatibilities and complexities, part 2: Splitter issues).

My question is simple: what’s the impact of the zonal architecture on troubleshooting? Will service technicians be further confused by its intricacies? Alternatively, is there evidence showing it will actually ease the troubleshooting problem, given the huge number of loads that the vehicle power subsystem must support along with their interconnection via various in-car networks?

I’m not an anti-advances person, but I do sometimes long wistfully for the early days of cars (and other products) when each load was on its own circuit from the battery, and you could troubleshoot most electrical problems with a schematic diagram and multimeter to read voltages, currents, and resistances. There’s a lot to be said for this type of directness and simplicity, that’s for sure, even though I know it’s not coming back.

Do you have any insight or thoughts about zonal architecture and eventual need for troubleshooting?

References:

—Bill Schweber is a degreed senior EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features. Prior to becoming an author and editor, he spent his entire hands-on career on the analog side by working on power supplies, sensors and signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing, and he also developed significant mechanical-engineering insight while designing control electronics for large materials-testing systems.

Related Content

The post How will zonal architecture impact automotive troubleshooting? appeared first on EDN.



Source link