Modulo automotriz de disparo y analisis en buses CAN y LIN para la serie DPO2000 y MSO2000. Incluye herramientas analiticas como visualizacion de buses como paquetes de informacion, decodificacion de paquetes, herramientas de busqueda y tablas de decodificacion con estampa de tiempo.

Entendiendo el Protocolo del Bus CAN

El CAN (Controller Area Network) fué desarrollado por Robert Bosch GmbH, en Alemania, a finales de los 1980s. La necesidad de controlar y comunicar dispositivos de control electrónicos (ECUs) en ambientes electricamente ruidosos fué la fuerza que motivó el desarrollo del CAN. En 1992, Mercedes-Benz se convirtó en el primer fabricante automotriz en emplear CAN en sus autos de alto desempeño. Ahora cada todos los fabricantes en el mundo emplean controladores y redes CAN en sistemas como controladores de motor de los limpia parabrisas, sensores de lluvia, bolsas de aire (airbags), seguros de puertas, controles de tiempo del motor, sistemas antibloqueo de frenos, controles de power train y ventanas eléctricas, por mencionar algunas de las aplicaciones. El protocolo CAN está expandiendose rapidamente a otras aplicaciones como control industrial, maritimo, medico y aeroespacial.
CAN es un protocolo de comunicacion serial de alta velocidad de dos cables, de tipo half-duplex. It is a layered protocol where the transmission and physical layers are of primary interest here. Because CAN is an asynchronous the bus can be utilized as a differential balanced line similar to RS-232 but allows multiple masters on the same network. Data rates range from 10 Kbps (<6km) to 1Mbps (<40m) with a tradeoff between speed and bus length, decreasing the bit rate allows for longer bus lengths. Typically CAN is used for system-to-system communication between nodes (transceivers and receivers) which communicate on the bus by messages similar to Ethernet.
There are a variety of CAN signals, as shown in the figure below. The transmitted data (Tx) and received data (Rx) signals are single-ended digital signals which are found at the inputs and outputs of devices such as CAN controllers and Electronic Control Units (ECUs). The messages transmitted between modules and products are carried on an inverted differential signal. The differential signal can be measured, or the individual signals (CAN_H and CAN_L) can be measured individually (if the signal-to-noise ratio is adequate). Because the signal amplitudes, polarities, and DC offsets vary between these different signals, you need to adjust your measurement setup and decoding method accordingly.



Identifiers, Arbitration and Frames
CAN data messages are transmitted from any node by identifier (ID) not by address or data. Before a node sends a message out to another node it checks if the bus is busy – two nodes on the same network are not allowed to send messages at the same time – a node can detect if it has lost arbitration and stops transmitting, letting the other node, with the higher priority transmit uninterrupted. A CAN message is created using frames. The frames of interest are: Data Frames, Standard (11 bit ID) and Extended (29 bit ID). Both Data Frames can hold 0 to 8 bytes of data and are used when a node wants to transmit data on the network. Remote Frames are used to request information and the node having the information should then respond by sending it on the network. Error Frames are used to signal an error and can be transmitted by any node. Overloaded Frames are used to provide extra delay between data and remote frames when a node is busy.


Bit stuffing
In CAN frames a bit of opposite polarity is inserted after five consecutive bits of the same polarity. This practice is called bit stuffing, and is due to the Non-Return-to-Zero (NRZ) coding. The “stuffed” data frames are un-stuffed by the receiver. Since bit stuffing is used, six consecutive bits of the same type (111111 or 000000) are considered an error. The bits in a CAN message are sent either high or low: high bits are recessive; low bits are dominant.

Understanding the LIN Bus
Local Interconnect Network (LIN) is one of the older low-speed serial standards for the automotive industry, developed by the LIN consortium in 1999 as a lower-cost alternative to the CAN bus for applications where CAN‟s cost, versatility, and speed were overkill. LIN applications typically include communications between intelligent sensors and actuators such as window controls, door locks, rain sensors, windshield wiper controls, and climate control, to name a few. However, due to its electrical noise tolerance, error-detection capabilities, and high speed data transfer, CAN is still used today for engine timing controls, anti-lock braking systems, power train controls and more.
The LIN bus is a low-cost, single-wire implementation based on the Enhanced ISO9141 standard. LIN networks have a single master and one or more slaves. LIN signals can be transmitted over distances up to 40 meters. All messages are initiated by the master with only one slave responding to each message, so collision detection and arbitration capabilities are not needed as they are in CAN. Communication is based on UART/SCI with data being sent in eight-bit bytes along with a start bit, stop bit and no parity. Data rates range from 1kb/s to 20kb/s. While this may sound slow, it is suitable for the intended applications and minimizes EMI.
LIN support is optional and is enabled by either the DPO4AUTO or DPO4AUTOMAX application module. This lab will walk you through the most significant of the capabilities of the product.

The LIN bus is always in one of two states: active or sleep. When it‟s active, all nodes on the bus are awake and listening for relevant bus commands. Nodes on the bus can be put to sleep by either the Master issuing a Sleep Frame or the bus going inactive for longer than a predetermined amount of time. The bus is then awakened by any node requesting a wake up or by the master node issuing a break field.
LIN frames consist of two main parts, the header and the response. The header is sent by the master while the response is sent by the slave. The LIN message frame looks like this:



Header Components:

• Sync Break – marks the beginning of the Message Frame. It activates and instructs all slave devices to listen to the remainder of the header.
• Sync Field – an alternating bit pattern which is used by the slave nodes for determination of the baud rate being used by the master node and synchronize themselves accordingly.
• Identifier Field –specifies which slave device is to take action. The ID Field contains four elements:
  • Message Identifier: identifies the sender, the receiver, the purpose, and data field length 6 Bit
  • 4 classes of 2/4/8 data bytes
  • 16 identifiers
  • 2 parity bits

Response Components:

• Data – the specified slave device responds with one to eight bytes of data
• Checksum – computed field used to detect errors in data transmission. The LIN standard has evolved through several versions that have used two different forms of checksums. Classic checksums are calculated only over the data bytes and are used in version 1.x LIN systems. Enhanced checksums are calculated over the data bytes and the identifier field and are used in version 2.x LIN systems.

The LIN bus transmits signals in three ways:

• Unconditional: The most typical LIN frame where the bus master sends the frame header in a scheduled frame slot and the designated slave node fills the frame with data.
• Event-triggered: Receives maximum information from slave nodes without overloading bus. Event Triggered Frames can be filled with data from multiple slave nodes.
• Sporadic: Sent only from master when a signal is updated in a slave node. Usually the master fills the data bytes of the frame and slave nodes receive information.