As electronic feature content increases—from safety and performance systems to advanced telematics—carmakers face a continuing challenge to make all the connections while containing the costs.

Saving wiring would not seem to be a promising area of opportunity with the proliferation of data busses. One or perhaps a twisted pair of wires already will cover many functions, and the weight savings from reduced wiring would seem to be an accomplished fact. However, there still is much that can be done, both in terms of assignment of control functions and routing and sizing of the wires to reduce the physical requirements.

Steffan Nass, applications engineer at Vector, an international software developer specializing in CAN, spoke on the topic at an electronics session during the recent SAE 2014 World Congress.

Higher-speed CAN buses

Higher-speed data buses have been a recent method of choice for increasing functionality, with the low-speed 33.3-kbs CAN bus out of the automotive picture and the medium-speed interior CAN bus upgraded from 83.3 to 125 kbs. And even those steps have proven to be inadequate. Chrysler added a second 125-kbs CAN bus, the Audio-Telematics (A-T), to its electronic architecture, and a second gateway to communicate with the interior CAN bus. That change permitted Chrysler to not only move the Hands-Free Module from the 83.3 kbs interior bus to the new 125 kbs A-T, but also to take some load off the new 125-kbs interior bus.

Other Chrysler steps have included use of LINS (local interconnect networks), which are low-cost buses that may operate at under 20 kbs for simple, low-speed switch inputs.

However, the cost issue won't be solved with an "add another bus and gateway" approach. A data bus costs money, Vector's Nass noted. A high-speed bus costs more than a low- or medium-speed one, and it adds wiring, modules, and bandwidth needs to the vehicle architecture. At present, only about 30% of the available bandwidth is in use at any one time on the Chrysler system, to enhance message flow, but extra capacity doesn't last long.

Restraining the cost of an electronic architecture as functionality is added is an ongoing priority. As has been generally recognized, until there's a robust wireless system available, selecting the right wires for the circuit load, designing efficient routing, and optimizing use and location of splices and modules are still necessary. However, the possibilities are so numerous that it can't be done manually on a trial-and-error basis, a team of researchers at the University of California, working with General Motors, told another SAE Congress session.

Current wiring models limited

They said that existing cost models for wiring harness architectures that are being used are ad-hoc Excel-based and are limited in their ability to allow exploration of possibilities. As a result, they added, it becomes a largely manual operation based on designers' experience, and that doesn't necessarily lead to optimum results because it often involves trial and error for wire sizing and manual layout of splices. A harness manufacturer can provide some expert help in these areas, but the architecture itself is the carmaker's area, based on the feature content to be offered.

The University of California/GM approach, which involves manual operation but within the framework of specific algorithms, is to solve three problems to pick a good architecture. Given a feature, find a low-cost architecture to implement it. Then given the architecture, develop a minimum-cost circuit for it (general problem that provides locations for splices). And from the circuit, evaluate minimum-cost routing paths (both routing and wire size, usually involving the shortest route). Although these steps involve work with the algorithms, they do result in routing choices.

This course creates a basic graph of the circuit, then a breakout of the possible wiring lines that could connect the harnesses. It proceeds to a second-level graph in which all routing choices to connect a pair of parts are laid out, and the shortest, if otherwise appropriate, can be selected.

Evaluate software, location

Another area for improvement is to look at all the software functions. Perhaps bandwidth can be saved by changing the timing on parameters—perhaps from every 10 ms to 100 ms, Vector's Nass suggested.

Or a function can be moved from one module or data bus to another that has spare capacity, he added.

One common system for routing body functions has been the use of zoned control units, typically at the front, rear, and under-dash. However, Nass said, there may be better results from adding functionality to other modules and merging them. Chrysler's PowerNet is an example, with the under-dash body computer handling the functions of the FCM (front control module) and CCN (cabin compartment node), eliminating the FCM.

It also may be possible to shorten wiring and/or consolidate by relocating software components. "The opportunities aren't always easy to identify," admitted Nass. But they often are there for discovery, he noted. This is particularly true when the module is on a data bus, such as an electronic parking brake, which requires no sensor, and/or if the message flow is in just one direction, such as from a sensor.

Going from CAN to Flexray, which is an ultra-high-speed networking system, is an available option. It supports data transfer rates up to 10 mb/s. The protocol first was put into use in 2006 on the BMW X5 to support an ultra-fast suspension control system, and since has gone into a few other premium makes, including other models from BMW, Audi, Mercedes-Benz, Rolls-Royce, and Bentley. However, Flexray is more costly and requires a different controller and approach to wiring, according to Nass. An Ethernet system for some applications that require a lot of bandwidth is a more likely future choice, he said.