Controller Area Network (CAN) is a broadcast, differential serial bus standard, originally developed in the 1980s by Intel and Robert Bosch GmbH, for connecting electronic control units (ECUs). CAN was specifically designed to be robust in electromagnetically noisy environments and can utilize a differential balanced line like RS-485. It can be even more robust against noise if twisted pair wire is used. Although initially created for automotive purposes (as a vehicle bus), nowadays it is used in many embedded control applications (e.g., industrial) that may be subject to noise. Any official use of CAN requires a fee for the CAN Protocol License to be paid to Bosch who developed the protocol and hold patents. The CAN data link layer protocol is standardized in ISO (2003). This standard describes mainly the data link layer — composed of the Logical Link Control (LLC) sublayer and the Media Access Control (MAC) sublayer — and some aspects of the physical layer of the OSI Reference Model. All the other protocol layers are left to the network designer's choice.

Transmission method: half-duplex serial communication A communication method for switching between transmission and reception of one transmission line Network Topology: Bus Type - Multi-Master When the bus is free, you can start sending messages to all units that are connected to the bus Access control method: CSMA / NBA Continue communication with the priority station soon began to communicate. In CAN, every message is assigned a (at each time) unique, 11-bit number. This number determines the priority of the message. It also acts as an identifier, so that the target node that listens to the broadcast bus knows it to be the message it should receive. For CSMA / CD is temporarily suspended during the simultaneous Bit Rates: up to 1 Mbits/s possible at network lengths below 40m Decreasing the bit rate allows longer network distances (e.g. 125 kbits/s at 500 m). If the bus is free, any node may begin to transmit If two or more nodes begin sending messages at the same time, the message with the more dominant ID (which has more dominant bits) will overwrite other nodes' less dominant IDs eventually (after this arbitration on the ID) only the dominant message remains and is received by all nodes

 Host Processor Decides what received messages mean, and which messages it wants to transmit itself Sensors, actuators and control devices can be connected to the host-processor (if desired)  CAN Controller Receiving: CAN Controller stores received bits (one by one) from the bus until an entire message is available, that can then be fetched by the host processor (usually after the CAN Controller has triggered an interrupt) Sending: Host processor stores its transmit-messages into a CAN Controller, which transmits the bits serially onto the bus  Transceiver Receiving: Adapts signal levels from the bus to levels that the CAN Controller expects and has protective circuitry that protect the CAN Controller Sending: Converts the transmit-bit signal received from the CAN Controller into a signal that is sent onto the bus Possibly integrated into the CAN Controller

5

 'elasticity' to denote the capacity to withstand a change of configuration with the least possible amount of reprogramming in relation to the data transfer to be provided  The information received and processed somewhere in a distributed system must be created and transmitted to a station. - New information is to be added. - A different situation occurs

 Conventional addressing, 'source' address and 'destination' address, cannot provide a system with good structural elasticity.  For the CAN concept, addressing principle is based on the content of the message.  A message has to be transmitted to all the other stations  The selection processing is called 'acceptance filtering' at each station

 the message is labelled with an identifier ID(i)  address pointers AP(i)  all the messages are simultaneously received over all of the network  data consistency is guaranteed in distributed control systems

.The data receive flow chart of HMI CAN busScript to receive CAN BUS data

 succeeded in reducing costs significantly  restricted to smaller scale applications  performance/cost ratio  fully satisfies

 CAN Bus- Yu-Wei Huang  CAN Bus- Kobe University, Gold King macros  TSC Americas – IRD Platform – Ethernet and CAN Bus Interfaces by Philips