Decentral Electrics


UPDATED: A diagram added to show current distribution.

One of the motivations for LINbus, both in general and in this case, is low-cost cabling reduction: To reduce the amount and length of cables throughout the vehicle. This has other benefits including simpler, smaller wiring looms that are easier to fit and to make.

And to maintain! I wouldn’t consider it if I didn’t think it’d make life easier.

Production cars however, largely fail to realize the full potential of cabling reduction because they still have centralised electrics, often with a fuse panel in one part of the car for all the lights, motors, heaters, etc. etc. Which of course means that those devices are all wired back to the one location

The MkV Golf has 3 fuse panels with the one at the end of the dash carrying 44 fuses. Keep in mind that each fuse needs 2 wires. One coming from the supply, via e.g. a switch or relay and the other going to the powered device. Are you getting the picture?

Continue reading

Flapping About


LINbus nodes for the flaps; the door and tailgate nodes have now been outlined.

Unravelling the logic embedded in the mirror selection and adjustment switch has been interesting. Knowing that it’s possible to unravel doesn’t make it easier.

This leaves just one node to be sketched out. And to increase the tension, I’m not saying what it is until it’s done!

Two into Three


The front body nodes, previous left and right, have become three; left, centre and right. The center node has been introduced to minimise cabling to the heavy current loads of the wiper motor and engine management, ignition and fuel injection systems.

LINbus architecture is being revised with reference to the 2.0 standard; though not necessarily in compliance with the standard. Nodes may be logically split into functional groups, increasing the number of logical units but not physical nodes. i.e. a node may have more than one slave task (and address), but only one connection.

Logical separation allows for a cleaner functional architecture without increasing the amount of hardware, satisfying the cable reduction objective.

The increase in nodes and the increased likelihood of traffic collisions, which reduce the quality of real-time response, leads to the decision to configure the vehicle network as two clusters (admittedly, without even checking the bandwidth). The master node will gateway between the clusters, acting as master in both clusters, running a master task for each LINbus.

Rear Body and Immobilizer Hooks


I/O etc. defined for the chassis node which owns the devices fixed at the back of the car. That means most tail lamps, the luggage compartment light and its switch, the fuel filler flap latch, the fuel pumps and the fuel level sensor.

Immobilizer hooks have been hinted for steering column, left-front and rear body nodes. Establishing trust between master and slave nodes is worth investigating as it would preclude an “evil master” being hooked onto the LINbus instead of the real master, injecting commands to bypass the immobilizer.  Here’s what I’m thinking: Continue reading

Building the Matrix


First steps in establishing the network object matrix of the vehicle network. This is about half-way through the detailed draft design of the network. Door, tailgate and rear-body and instrument proxy nodes are still to be defined.

Every node “owns” the devices that it connects to the vehicle network, along with the associated device states and the node’s internal management parameters.

This provides a rich set of status and diagnostic information that can be selectively used by other nodes in the vehicle network. All the exported information can be queried when trouble-shooting.

Managing Thermal Management


The thermal management node’s functions and I/O have been outlined.

There aren’t a lot of inputs and even fewer outputs, but it is very important that the node works or expensive stuff will break. So there are some fail-safes and redundancy in sensing.

Performance and energy-saving tweaks galore!