• No results found

Future developments in vehicle power distribution and network systems

6.4.2 Current technology

The most widely adopted vehicle network technology was developed by Bosch and is known as CAN (controller area network). This technology has established itself as the standard for vehicle manufacturers. However, it should be noted that there are a number of other network technologies available and under development.

CAN

The basic principle of the CAN bus is that individual modules (electronic control units or ECUs) are connected in parallel to the bus system. Each point of connection to the bus is known as a node and all of the connected nodes have equal priority. This means that all messages on the bus are available to all of the ECUs (i.e. nodes) at the same time. This is known as a multi-master system. The advantage of this method is that failure of one node does not impair bus-system access for the other connected nodes and this increases the overall reliability of the system. In addition, the system is designed with a high degree of inbuilt safety with respect to error checking and handling of transmitted data.

Figure 6.25 shows a typical system incorporating multiple networks. A basic system overview and operation are discussed below.

The basic principle is shown in Figure 6.26. Each control unit is connected to the bus, in parallel, by transceiver modules. The transceiver is a transmitter and receiver amplifier. It converts serial data into electrical signals on the bus (and vice versa). For clarity, a single CAN line is shown, but generally the signal is transmitted over a differential line as this provides superior electrical interference rejection.

The information is transmitted as electronic messages and each control unit can send and receive them via

the transceiver. A typical message would be a physical value, for example engine speed. This is converted into a binary number and then transmitted electrically as a serial bit stream on the CAN data bus as 1s and 0s (see Figure 6.27). All the other control units on the bus receive this data and can convert the bit stream back into a message ready for processing by the ECU.

Between the transceiver and ECU, the CAN module controls the data transfer process for the CAN messages to and from the ECU. It is divided into two sections – send and receive. The CAN module transmits data to the ECU via mailboxes (i.e. memory locations) which have read/write access to and from the ECU processor.

The CAN data bus can be in one of two states representing 1 or 0. The transceiver is connected to the bus line via an open collector as shown in Figure 6.28.

This results in two possible states on the bus line:

● transistor ‘open circuit’: high state via resistor, bus level high (logic 1)

● transistor ‘closed circuit’: low state, resistor shorted,

bus level low (logic 0).

These are known as recessive and dominant states. Consider three transceivers connected on a bus line (see Figure 6.29). It is clear that if any switch is closed, the bus line becomes status 0/status 1; if all switches are open, the bus line becomes status 1. Also, if the bus is in state 1 any node can overwrite this state to 0. This shows how the multi-master or broadcast system works, but there are some things to consider with this method:

● What if two control units send at the same time?

● What about fault handling?

In order to understand it more clearly, we will consider the send and receive process in more detail.

Data transmission

The following example looks at the transmission of engine ECU data to the dash panel insert (see Figure 6.31):

● First the engine ECU gets the required data value.

This value is stored in the ECU microprocessor memory ready for transmission.

● This data is then passed to the transmit mailbox of

the CAN module. An electronic ‘flag’ is then raised to indicate that data is ready for transmission.

● The data is converted into a message in the correct format for transmission according to the CAN protocol (see Figure 6.30). The main components of this protocol included in the message are:

– identifier: states what the message data is – message content: actual data value – checksum: method or error protection – acknowledge: message acknowledgement. In addition:

– other: start and end of frame messages, control message (size of data field).

● CAN module checks that the bus is active and if necessary waits until it is free. When the bus is free, the data is transmitted by the transceiver.

Figure 6.25 Bus system incorporating multiple networks

136 Power distribution Fundamentals of Motor Vehicle Technology: Book 3

Figure 6.26 Information exchange of a message on the CAN bus

Figure 6.27 Electrical signal transmission in chronological sequence

Figure 6.29 Connection of three transceivers to bus line (principle), transceiver C active

Figure 6.30 CAN message format

Figure 6.31 CAN bus – data transmission

138 Power distribution Fundamentals of Motor Vehicle Technology: Book 3

Figure 6.32 CAN bus – data receive

Data receive

All nodes on the CAN bus receive the transmitted data at their transceivers (see Figure 6.32). First the data is checked for errors and usability. This helps to detect local faults but still allows high data throughput on the bus. Using the checksum part of the protocol (CRC (cyclic redundancy check)) transmission faults can be detected. If no errors are found, an acknowledgement is sent to the transmitter confirming reception of the data intact. The message is then processed in the CAN module and a decision is made as to whether that message is relevant to that control unit (or node). If it is relevant, the message is placed in the receive mailbox, otherwise it is discarded. When the receive flag is raised, the ECU microprocessor knows new information has arrived. This data is then copied into the input memory of the microprocessor ready for use. Data exchange is repeated cyclically according to the cycle time setting.

Error handling

If several control units transmit data at once, there could be collision on the bus. This is avoided by using bus arbitration with the following strategy. Every node starts its transmission by sending an identifier and all the nodes monitor the bus traffic. The identifier sets the priority of the message and the message with the highest priority is assigned first access to the bus without delay. Transceivers respond to failure to gain bus access by automatically switching into receive mode; they then repeat the transmission attempt as soon as the bus is free.

The CAN protocol has an extensive error management system capable of detecting transmission errors with a high degree of certainty. Any node detecting an error can inform the other nodes via transmission of an error frame and the message can then be rejected by all nodes. Following this, an automatic retransmission is executed and these are monitored. If these become frequent, a control unit can be automatically switched off to prevent bus traffic being impaired.

LIN

This is an acronym for local interconnect network, which is a technology that has been proposed and developed by a consortium of manufacturers including Audi, Daimler-Chrysler, Volkswagen and Volvo. It is a low-cost alternative to CAN where high bandwidth is not required (for example comfort and convenience functions like window lift, central locking etc.). The main difference between LIN and CAN is that bus access in a LIN network is controlled by a master node so that no arbitration or data collision management in the slave nodes is required. Note that LIN is implemented as a sub-bus and as such fully integrates with a vehicle CAN network (see Figure 6.33). LIN is a complementary bus system and is not designed as a replacement for CAN. Its main application is where the throughput capability and versatility of CAN is not required.

LIN bus is generally implemented as a single-wire serial communications protocol using simple UART (universal asynchronous receiver transmitter) hardware (which is available on most microcontrollers as standard).

LIN network CAN bus

LIN sub bus LIN nodes Gateway Figure 6.33 LIN Roof: Rain sensor Light sensor Light control Sunroof Door: Mirror Central ECU Mirror switch Window lift Seat control switch Door lock Climate: Small motors Control panel Steering wheel: Cruise control Wiper Turning light

Optional: climate control Radio

Telephone

Seat:

Seat position motors Occupancy sensor Control panel

Engine:

Sensors Small motors

Figure 6.34 Typical applications for LIN

A particular feature is the self-synchronisation in the slave nodes without crystal or ceramic oscillators. These two factors together significantly reduce the cost of the electronic hardware needed for interfacing to the bus.

The specification of the line driver and receiver follows the ISO 9141 single-wire standard (with some enhancements). The maximum transmission speed is limited to 20 Kbps due to the requirements for electromagnetic compatibility (EMC) and clock synchronisation. A node in a LIN network does not make use of any information about the system configuration, except for identification of the master node. Nodes can be added to the LIN network without requiring hardware or software changes in other slave nodes. The size of a LIN network is typically less than 12 nodes (though not restricted to this), resulting from the fact that only 64 identifiers are available and also the relatively low transmission speed.

The typical applications for LIN are shown in Figure 6.34.