Network Management – Part 1: GMLAN
Most vehicles employ some sort of network management. This is typically for the Low Speed or Body Network. The High Speed or Powertrain network will come alive when the key is in the start position. But if you need to send an unlock command using your key fob and this is done via a CAN Bus, then there will need to be a network management system to wakeup nodes and allow them to go back to sleep.
The problem is that there are sooooo many ways of accomplishing this task. There is GMLAN, OSEK, and many others. In general they may have nothing to do with each other, you will just have to learn them all! So here is a start:
GMLAN Network Management:
GM uses network management on their Single Wire or Low Speed network in order to wake up nodes that are in a low-current or sleep mode. There are essentially two events that must take place to communicate with a sleeping node.
First you must wake it up by sending a High Voltage Wake-Up. On single wire CAN the physical layer is typically an active high, 0-5V line. This means that if you were to watch normal traffic on an oscilloscope, you would see 0 Volts for low values and 5 Volts for high values; but when a node is sending a high voltage wake-up now the high values will be at 12 volts (rather Vbatt which may be as low as 9 Volts or as High as 16 Volts). Although it doesn’t matter what format this message is, it is typically the message with Arbitration ID 0x100 and has NO data. This lets the sleeping nodes know that they need to wake-up. An awake node may or may not be listening to command information just yet. Most nodes require another “Wake-Up” to send data to them.
Second you must send the Virtual Network Management Frame (VNMF). This message is designed to wake-up particular virtual networks or groups of nodes that are associated through common systems such as lighting control or entry systems (i.e. doors). So if I wanted to talk to door module to unlock the doors I would wake up the virtual network for doors. The problem is of course, I have no way of knowing the networks without a proprietary list which I don’t have. So instead of worrying about which virtual network to wake-up I will show you how to wake them ALL up. To wake up ALL virtual network it’s as simple as sending the following message: 0x621 01 FF FF FF FF 00 00 00.
So why does this work? ALL VNMFs have a range of 11 bit IDs (even on 29-bit networks). 0x620-0x63F are reserved IDs for VNMFs. So you can use ANY ID within that range and it will be interpreted as a VNMF by all nodes. The ID is the source node. In this case $621 is from the Body Control Module. The First byte of a VNMF is either 0x00 or 0x01. 0x01 means Initiate the following Virtual Network(s) (VN) and 0x00 means Continue the following VNs. The next three or four data bytes contain a bit encoded list of each VN where 1 means wake-up and 0 means nothing. So if you send 0xFF this is essentially saying wake-up to the eight VNs that are encoded in that byte.
This method is like using a blow horn to wake-up the nodes. Each node will hear it and wake-up. If you want to be more subtle and only wake-up the VN your are interested in, then you can go bit-by-bit and find your VN it should take too much time either as there may only be around 20 VNs at most on any particular vehicle.
A VN will stay awake for up to 3 seconds after the first message was called. So if you want to keep the network awake you must constantly send the Continue frame $621 00 FF FF FF FF 00 00 00.
To summaryize here is the VNMF format:
Format: ArbID, B1, B2, B3, B4, B5, B6, B7, B8
As Seen: $620-$63F, 01 or 00, XX, XX, XX, XX, 00, 00, 00 (Where XX = Some bit-encoded value where each bit represents a single VN).
oh and ALL VNMFs MUST BE 8 BYTES IN LEGTH!