Amazon Echo:

e-feature-skills-3__CB533166530_

Plays all your music from Amazon Music, Spotify, Pandora, iHeartRadio, TuneIn, and more using just your voice

Fills the room with immersive, 360º omni-directional audio

Allows hands-free convenience with voice-control

Hears you from across the room with far-field voice recognition, even while music is playing

Answers questions, reads the news, reports traffic and weather, reads audiobooks from Audible, gives info on local businesses, provides sports scores and schedules, and more using the Alexa Voice Service

Controls lights, fans, switches, thermostats, garage doors, sprinklers, locks, and more with compatible connected devices from WeMo, Philips Hue, Samsung SmartThings, Nest, ecobee, and others

Always getting smarter and adding new features, plus thousands of skills like Uber, Domino’s, and more.

Order Online:

http://amzn.to/2n17PK9

 

VIDEO:

LAYBAGS

faq-about-contact-banner

ULTIMATE AIR LOUNGER: Whozzu has created the ultimate inflatable sofa bed couch by using ripstop nylon parachute fabric that is tear resistant & heavy duty. The quality of our product is so high that it would be a crime not to protect them with our MONEY BACK GUARANTEE!

LIGHTWEIGHT & EASY TO CARRY: Our inflatable couch bed only weighs 1.2kg and easily folds into the free carrier bag. The effortless design makes your trips out at the pool, beach and camping easy.

LOUNGE ANYWHERE: Whozzu has been working hard to create an air lounger that will easily inflate using just you and the wind that is also waterproof and floats, it’s great for both adults and kids!

EFFORTLESS DESIGN: Our inflatable sofa includes two pockets to hold your belongings as well as a drink holder & an anchor. SO WHAT DOES THIS MEAN? It means that we have created a superior inflatable sofa bag so you can enjoy your time outdoors without any worries!

Order Online:

http://amzn.to/2opFBcg

 

VIDEO:

AIR BAR

airbar_fb_share

Plug and Touch – Simply attach the AirBar with the included magnets to the bottom of your screen and plug in the USB cord

Compatibility – AirBar works with most notebooks running Windows10 with 15.6″ screen size

Touch Using Any Object – Touch with a finger, glove, paintbrush, stylus and more

Designed for Windows 10 Laptops

Gestures: Tap, Swipe, Pinch, Zoom, and Rotate

Order Online:

http://amzn.to/2nNS8oy

 

VIDEO:

 

 Diet sensor

diet_heroDietSensor is the most comprehensive nutritional app in the world. DietSensor is a powerful food-tracking tool designed to help control diabetes, reduce weight and improve fitness. DietSensor includes the CES award winning DietSensor App, SCiO molecular food scanner from Consumer Physics and the DietSensor digital scale. Digital scale and SCiO food scanner can be purchased at DietSensor.com/shop-2. Dietsensor offers diabetes, weight loss and fitness communities a powerful food tracking tool to meet their daily goals, and help them stay balanced and on track.

Order it!!

https://www.dietsensor.com/early-bird-subscription/

 

SESAME SMART LOCK:allcolors

Leave your keys behind: Lock/unlock your door using the App. Better yet, open Sesame with a knock.

Share access: Allow guests in. Control who has access and when.

Log records: Receive a notification whenever your door opens or closes.

Installs in seconds: Simply tape Sesame to your door with a single strip of 3M Command tape (supplied) without removing or swapping anything. No tools required. Sesame works with just any single cylinder deadbolt in the US/Canada thanks to five-patented mechanisms.

Long battery life: Sesame lasts about 500 days on lithium batteries (supplied).

Order Online:

http://amzn.to/2nL7Hvy

 

Video:

Autosar Compendium, Part 1: Application & RTE  :

This book is very useful especially who are working in autosar technology!!

I strongly recommend this book, to go through the autosar material.

Pros:First book on autosar technology with the good content.

FOR USA(Amazon.com):

We have a lots of books for automotive technology in the market, but for autosar beginners there are no books till now as far as I know. Recently, this book available in amazon website, the other parts are going to be release soon. Hope this book will be useful.

For Indians(Amazon.in):

(more…)

How does a car work?

tesla_01_car

When you’re riding in a car, you may not necessarily think about what’s making it go, aside from the grown-up in the driver’s seat. But in truth, cars get their power and their ability to move from their very special construction and from energy-filled substances that fuel them.

If you’ve ever been to the gas station, then you probably already know that cars need gasoline, or petroleum, to run. The car’s engine runs on a mixture of gasoline and air. Just like a hot fire gives off energy when it burns, so does the gasoline! The spark that gets the whole thing going comes from the car’s battery, which gets powered when the driver turns the key in the ignition.
Once the whole thing is going, the energy the car gets from the gas it burns moves the car forward! A special part of the car called the “transmission” passes all the energy from the engine to the wheels. The driver then uses the wheel to steer and guide the car in the direction in needs to go, and uses the car’s brakes to slow the car down when at a stoplight or when arriving at the destination!

The Transmission

Controls the power contained in the crankshaft before it goes to the wheels and allows a driver to control the speed/power of a car by providing different speed/power ratios known as gears.So first gear gives plenty of power but little speed whereas fifth gear provides little power but plenty of speed.The crankshaft only connects to the transmission when the car is in gear and the clutch is engaged. If you press down on the clutch the crankshaft disconnects from the transmission.The transmission is connected to the output shaft, which is connected to the axles, which are connected to the wheels. When the transmission rotates the output shaft this turns the axles, which in turn rotate the wheels.

Car Gears - Transmission
 How a Motor Engine Works
 The more you understand about your car, the more capacities you will have to keep it running the correct way and to know where the trouble spots could be if it is not running as efficiently as you would like.  If you want to ensure that your car keeps going the right way, one of the first things you want to understand is the motor and how it connects to everything in your vehicle.  This will allow you to make adjustments needed and to have better knowledge of the vehicle that you have.

engine-inline-4

The motor of a car is like the heart of your vehicle.  It is the one thing that connects everything together and ensures that your car continues to move.  It’s main purpose is to transfer the gasoline that moves into the engine area and then to move it back out so that your vehicle as fuel to run on.  The motor is what will propel the gasoline into the various areas of the car, pushing it into the motion that keeps everything running effectively.

Even further than this, everything that is connected to the engine also allows it to keep running at it’s best.  The first of these is the set of spark plugs that moves into the engine.  When the engine pushes up, it will hit the spark plugs.  When this happens, it will cause the spark plugs to ignite and will turn on the engine.  When this happens, the gasoline is then able to push up through the cylinder of the engine and releases into an exhaust pipe.  This is the cycle that the motor will follow in order to release the energy to move.

In order to keep the motor engine completely functioning, there are other components that also allow the engine to continue to run smoothly.  The first of these is the connecting rod, which is used as a support area as the piston rotates and releases the gas.  The second is the crankshaft, which is used in order to keep the piston turning so that it can release the necessary gasoline at the right time.  The last of these is the sump, which will collect the oil and lubricate the engine piston and other parts of the motor as they are turning, allowing for a smoother ride.

Take a close look of Internal combustion system: 4StrokeEngine_Ortho_3D_Small

1. Intake stroke – intake valve opens and the piston moves down allowing the fuel-air mix to enter the open space.

2. Compression stroke– the piston moves upwards. This compresses the fuel-air mix by forcing it into a smaller space. Compression makes the fuel-air mix explode with greater force.

3. Power cycle – spark from a spark plug ignites the fuel-air mix. The explosion forces the piston down the cylinder.

4. Exhaust cycle – the exhaust valve opens and the piston moves back to the top of the cylinder which forces the exhaust fumes out.

Reference Book:

Continue reading “How does a car work?”

CAN Calibration Protocol (CCP)

What is Calibration?

Calibration is a process of optimizing or tuning a control algorithm to get the desired response from the system.  A calibration tool is a combination of a hardware interface and a software application that enables the engineer to access the calibration variables in an ECU and change them.  Typical control algorithm components that need calibration are look-up tables, gains, and constants.

A powertrain control algorithm may have hundreds of calibrate-able parameters.  The more parameters that are used, the more difficult the task of finding an optimal calibration.  The calibration tool helps the engineer arrive at an acceptable calibration parameter set.  All of the calibrate-able parameters are grouped into a special section of ECU memory called the calibration memory.  Calibration tools give the user access to this memory to allow.

A basic calibration system consists of an ECU interface, a link to the host PC, and a PC application.   A more capable system will add a vehicle network link as well as analog data acquisition modules.  The ECU interface is typically a CAN interface when a CAN-based calibration method is used, or a Read-Only-Memory (ROM) emulator when a direct memory access method is used.  The link back to the host PC can be CAN, USB, Ethernet, or other method.  The PC application is typically a MS-Windows® application.  Figure 1 shows a typical calibration system.

What is CCP?

The CCP (CAN Calibration Protocol) is, just as the name indicates, a protocol for calibration of and data acquisition from electronic control units (ECU). The protocol is defined by ASAM (Association for standardisation of Automation and Measuring Systems), earlier known as ASAP (Arbeitskreis zur Standardisierung von Applikationssystemen). This is an international organization consisting of a number of significant vehicle manufacturers i.e. Audi, BMW, VW etc. Until now different technical solutions have been used for developing, calibration, production and service of ECU hardware and software. The aim with CCP is to create a common tool for all stages of ECU developing and which is compatible with different kinds of hardware and software.

The ASAM group defines a lot of standards. The CCP and XCP standards are found in subsection AE (Automotive Electronics) and are grouped into something called AE MCD 1. The current version of the CCP specification is 2.1, released in February, 1999.

The CAN Calibration Protocol is basically used as a monitor program. Similar to many earlier serial RS232-type monitors and bootstrap loaders that provide basic read and write memory capabilities, CCP provides the same functionality using a standard protocol rather than a company-specific proprietary protocol. However, when a high-speed CAN bus is used, CCP, unlike some previous 9600 baud UART-based monitors, provides the ability to access data at such a fast rate that it is possible to run an application at the same time.

Developers now have a significant advantage over the earlier monitoring methods.

In the dialog used by CCP and most monitor programs it is the tool or PC that is the Master that sends commands into the ECU. The ECU does not send information without the Master (Tool) initiating commands. A CCP-compliant tool can read data from the ECU and can write data into the ECU with the appropriate CCP messages.

With CCP, the software developer can read:

• RAM

• PORTS

• ROM

• FLASH

With CCP, the software developer can write to:

• RAM

• PORTS

• FLASH

However, this is only CAN Calibration Protocol’s minimum capability. CCP includes several additional monitor commands, and provides several new features including automatic data acquisition processing based on events or periodic updating, flash programming and data security. Since there is no requirement to use all its features, CCP is a scalable protocol.

 CCP users have access to online measurement data and can calibrate modules, so software development can occur not only in a lab environment but also during an in-vehicle test.

Continue reading “CAN Calibration Protocol (CCP)”

UDS – General vehicle diagnostics

UDS is defined (Unified Diagnostic Services) in the standards ISO 14229 contains (the bus system-independent part) and ISO 15765-3 (CAN describes the specific implementation). Unlike OBD writes the UDS standards applicable to the general vehicle diagnostic no CAN identifier and no CAN baud rates. Here, then, any vehicle manufacturer is able to decide freely. be called The Standard, however, define how the SIDs and PIDs (hot at UDS Sub-level parameters). Unlike the OBD content of the messages in UDS is not defined in practice. That is, everyone can vehicle manufacturers specify how it defines data, under what parameters on the responsibility, as it codes etc.

The message structure of the UDS diagnostic services consistent with the structure of OBD: The first byte is the SID. Then a detail of the service follows the so-called sub-level identifiers (essentially corresponds to the PID in OBD).

At UDS, there is the possibility to give positive response to messages. For this, the diagnostic tester must be in the request, the top bit set of sub-level identifiers to 1. Negative responses on the other hand must always be sent. This absence of positive response messages is useful for example, to reduce the bus load in flashing.

There are a large number of UDS diagnostic services. The following two tables show an extract of it here. In the tables for comparison, the respective services for the predecessor of UDS, KWP 2000 are shown.

Auszug der Diagnosedienste von UDS und KWP 2000 (Teil 1)

Auszug der Diagnosedienste von UDS und KWP 2000 (Teil 2)

Extract the diagnostic services of UDS and KWP 2000

UDS is defined (Unified Diagnostic Services) in the standards ISO 14229 contains (the bus system-independent part) and ISO 15765-3 (CAN describes the specific implementation). Unlike OBD writes the UDS standards applicable to the general vehicle diagnostic no CAN identifier and no CAN baud rates. Here, then, any vehicle manufacturer is able to decide freely. be called The Standard, however, define how the SIDs and PIDs (hot at UDS Sub-level parameters). Unlike the OBD content of the messages in UDS is not defined in practice. That is, everyone can vehicle manufacturers specify how it defines data, under what parameters on the responsibility, as it codes etc.

Continue reading “UDS – General vehicle diagnostics”

KWP2000 and UDS Difference

What are the difference between KWP2000 & UDS?

1. Event triggering and periodic transmission are applicable only in UDS.

2. Positive response supression  for tester present is not present in KWP2000.

3. Transfer of measurement values,  only two-byte identifers are available in UDS. In KWP2000 one byte record Local Identifer and Two Byte  Common Identifer

4. Error memory management.

Differences between KWP 2000 and UDS

The classic diagnostic communication with KWP protocols has favored a symmetrical number of requests and responses. In contrast, UDS provides event-driven and periodic services, for which the number of requests and responses can differ greatly. The KWP 2000 principles to transfer measurement values and to manage the ECU´s error memory were re-engineered for the UDS standard.

Transfer of measurement values

For the transfer of measurement values, only the two-byte dataIdentifiers are available with UDS. KWP 2000 specifies a one-byte recordLocalIdentifier and two-byte commonIdentifier.

To increase data transmission efficiency, several measurement values can be requested with one UDS service request, and there are two different response types. The specified data identifiers are more comprehensive (see ISO 14229-1 annex C.1). Examples include:

 • $F100 … $F19F: for example, KWP 2000 identifier, calibration data, and ODX file identifier

 • $F2xx: Periodic data identifier

$F3xx: Dynamically defined data identifier

$F4xx … $F8xx: OBD according to ISO 15031-5

When measured values or bigger memory areas have to be transmitted via memory addressing,the addressAndLengthFormatIdentifier of the UDS standard provides more capable addressing.

TheblockSequenceCounter constructs a more efficient data transfer, because a complete reset of the process in case of an error is not necessary.

 Error memory management

KWP 2000 contains four services for the management of the error memory. These are $14 (clearDiagnosticInformation), $18 (readDTCByStatus), $17 (readStatusOfDTC), and $12 (readFreezeFrameData).

In contrast, the UDS standard specifies only two services for the error memory management: $14 (clearDiagnosticInformation) and $19 (readDTCInformation). But due to the fact that there are 21 different sub-functions for the service request $19 (readDTCInformation), the abilities of these services are enhanced widely. The UDS standard contains approximately 60 pages of specifications for error memory management.

Documents:

 Presentation_Debrecen_En_2008_03_27

                             K-Line                                                                   CAN

  • Reserved for diagnostic communication                     Diagnostic & continuous communication between ECUs
  • Longer data packets can be transmitted                    A CAN frame is max. 8 bytes: encapsulation of request required
  • Configurable communication speed                            Fixed speed: because of the continuous bus configuration
  • Arbitration must be implemented by SW (UART)       Bus arbitration, CAN-frame structure is handled by HW
  • Additional wire + HW Component (Layer1)              Wire + required HW component already exists

  • Additional SW Driver for Layer 2                          SW Drivers already exist, only sw of diagnostic communication must be implemented

Continue reading “KWP2000 and UDS Difference”

CAN Basics

The Controller Area Network (CAN) protocol incorporates a powerful means of seamlessly preventing data corruption during message collision. This arbitration process and its relationship to the electrical layer variables are explained. Techniques to force message collision and test arbitration are demonstrated with strategies to leverage arbitration as a quantitative benchmark in safety-critical systems. The benchmark is then applied to several example systems and results provided for comparison.

Introduction

The ability of a Controller Area Network to manage message collision provides a unique proving ground for protocol compliance in any application. A means of determining a benchmark for a system’s performance by measuring a network’s ability to execute proper arbitration is developed in this example. It is demonstrated that while a CAN bus appears to be functioning normally, many arbitration errors may be unnoticed by system operators.

CAN Implementations:
In CAN there are two main Hardware Implementations, they are Basic CAN and Full CAN.

Basic CAN: Basic CAN has only one Message buffer for Receive and Transmit messages. The received message is accepted or ignored after acceptance filtering.  The decision to process a message or to ignore it is also achieved by acceptance filtering. This acceptance filtering of the node is done by software in Basic CAN. To reduce the software load at the nodes, there is a possibility to ignore some messages by ignoring specific identifiers. This is realized by bit mask for the message identifiers.

Full CAN: In Full CAN, there are 8 to 16 memory buffers for every transmitted or received message. Here the acceptance filtering is done by hardware and not by the software. Every buffer can be configured to accept messages with specific ID’s.
Since the acceptance filtering is done by hardware, the software load is greatly reduced. With different buffers for different messages ensures more time for the processing of the received messages and the transmitted message can be handled according to the priority levels. Configuring each buffer for every message ensures also the data consistency in Full CAN.

Arbitration Basics

Since any CAN node may begin to transmit when the bus is free, two or more nodes may begin to transmit simultaneously. Arbitration is the process by which these nodes battle for control of the bus. Proper arbitration is critical to CAN performance because this is the mechanism that guarantees that message collisions do not reduce bandwidth or cause messages to be lost. Each data or remote frame begins with an identifier, which assigns the priority and content of the message. As the identifier is broadcast, each transmitting node compares the value received on the bus to the value being broadcast. The higher priority message during a collision has a dominant bit earlier in the identifier. Therefore, if a transmitting node senses a dominant bit on the bus in place of the recessive bit it transmitted, it interprets this as another message with higher priority transmitting simultaneously. This node suspends transmission before the next bit and automatically retransmits when the bus is idle. The result of proper arbitration is that a high-priority message transmitted without interruption is followed immediately by a low-priority message, unless of course, another high-priority message attempts to broadcast immediately following the same message. Since no messages are lost or corrupted in the collision, data and bandwidth are not compromised.

Electrical-Layer Variables (bit timing requirements)

Each CAN bit is divided into four segments (see Figure 1). The first segment, the synchronization segment (SYNC_SEG), is the time that a recessive-to-dominant or dominant-to-recessive transition is expected to occur. The second segment, the propagation time segment (PROP_SEG), is designed to compensate for the physical delay times of the network as shown in Figure 2, and should be twice the sum of the propagation delay of the bus, the input comparator delay, and the output driver delay. The third and fourth segments, both phase buffer segments (PHASE_SEG1 & PHASE_SEG2), are used for resynchronization. The bit value is sampled immediately following PHASE_SEG1.The bit rate may be changed by either changing the oscillator frequency, which is usually restricted by the processor requirements, or by specifying the length of the bit segments in “time quantum” and the prescaler value. The prescaler value is multiplied by the minimum time quantum, which is the reciprocal of the system clock frequency, 1/f sys , to determine the length of a working time quantum. Bit time may then be calculated as the sum of each bit segment, and the bit rate may be calculated as the reciprocal of this sum. 

Each node must perform a hard synchronization upon every recessive-to-dominant edge after a bus idle or received start of frame. Hard synchronization is a restarting of the internal bit timing to force the edge into the SYNC_SEG, where edges are expected to occur. Resynchronization is performed on all other recessive-to-dominant edges of other received bits by lengthening or shortening the PHASE_SEG1 or PHASE_SEG2 by one to four time quanta as specified by the resynchronization jump width. If the difference between the edge causing resynchronization and the SYNC_SEG exceeds the resynchronization jump width, the effective result is the same as a hard synchronization.

 CAN Network Errors

CAN protocol specifies five different types of network errors. A transmitting node detects a bit error when it monitors a bit value different than it is transmitting; the reaction to this condition varies with the nature of the error. A stuff error occurs when the bit-stuffing rule is violated – a bit of opposite value must be inserted immediately following any series of five consecutive bits of the same value in a message. A cyclic redundancy check (CRC) error occurs when a receiving node receives a different CRC sequence than anticipated. (Note that all nodes independently calculate the CRC sequence from the data field). A form error occurs when a field contains an illegal bit value. Finally, an acknowledgement (ACK) error occurs when the transmitter does not monitor a dominant bit in the ACK slot to signify that the message had been received properly by another node as shown in Figure 2. When a node detects a bus error, it transmits an error frame consisting of six dominant bits followed by eight recessive bits. Multiple nodes transmitting an error frame will not cause a problem because the first recessive bits will be overwritten. The result will remain six dominant bits followed by eight recessive bits, and cause the bus to be safely reset before normal communications recommence.

The CAN protocol provides a means of fault confinement by requiring each node to maintain separate receive and transmit error counters. Either counter will be incremented by 1 or 8, depending on the type of error and conditions surrounding the error. The receive error counter is incremented for errors during message reception, and the transmit error counter is incremented for errors during message transmission (for further details, see reference 1). When either of these counters exceed 127, the node is declared “error-passive,” which limits the node from sending any further dominant error frames. When the transmitted error count exceeds 255, the node is declared “bus-off,” which restricts the node from sending any further transmissions. The receive and transmit error counters are also decremented by 1 each time a message is received or transmitted without error, respectively. This allows a node to return from error-passive mode to error-active mode (normal transmission mode) when both counters are less than 128. The node may also return to error-active mode from bus-off mode after having received 128 occurrences of 11 consecutive recessive bits. Overall, a network maintains constant transmit and receive error counters if it averages eight properly transmitted or received messages for each error that occurs during transmission or reception, respectively.

Controller Area Network (CAN) started life in 1983 at Robert Bosch GmbH as a serial data bus standard for the interconnection of microcontrollers in vehicles. Although originally designed specifically for automotive applications, it is now also used in other applications. The protocol was officially released in 1986, and the first CAN controller chips, produced by Intel and Phillips, were available commercially in 1987. The CAN 2.0 specification was published by Bosch in 1991. The data link and physical layers of CAN for data rates of up to 125 kbps (described as “low-speed serial data communication” were defined in part two of the original ISO standard published in 1994 (ISO 11519). Part 1 of a later ISO standard published in 2003 (ISO 11898) covers the data link and physical layers of CAN, but for data rates of up to 1 Mbps. There are also a number of other related standards. The higher layer protocols used with CAN depend on the application. A number of microcontrollers (for example, Microchip Technology’s PIC Microcontrollers) now have CAN support built-in.

A modern car will typically have in the order of fifty (and sometimes a lot more) electronic control units (ECUs) controlling various automotive sub-systems. The largest microprocessor unit in a car is usually the engine control unit (also, confusingly, commonly abbreviated to ECU). Other microprocessors control elements ranging from the transmission system and braking system, right down to cosmetic elements such in-car audio systems, and driving mirror adjustment. Some of these subsystems operate independently, but others need to communicate with each other and process and respond to data received from sensors. The CAN bus in a vehicle control system will typically connect the engine control unit with the transmission control system, for example. It is also highly suited to use as a fieldbus in general automation environments, and has become widely used for such applications, in part because of the low cost, small size and availability of many CAN controllers and processors. In automotive systems, they are an ideal alternative to expensive, cumbersome and unreliable wiring looms and connectors.

A CAN network interconnects control devices, sensors and actuators (collectively referred to here as nodes). Every node attached to a CAN bus can send and receive data, but not at the same time. A message consists primarily of an identifier that identifies the type and sender of the message, and up to eight bytes of actual data. The physical medium in a CAN network is a differential two-wire bus (usually either unshielded or shielded twisted pair), and the signaling scheme used is Non-Return to Zero (NRZ) with bit stuffing. Because CAN is essentially a broadcast network, messages will be received by all nodes. The messages do not reach the devices directly, but via each node?s host-processor and CAN Controller. These elements sit between the node itself and the data bus. Any node may transmit a message providing the bus is free. If two or more nodes transmit at the same time, the system of arbitration is simply to give priority based on message ID number. The message with the higher priority ID will overwrite all other messages, and any nodes responsible for the lower priority messages will back off and wait before retransmitting.

Each node will have a host-processor that interprets incoming messages and determines when it needs to send outgoing messages, sensors, actuators and control devices, which can be connected to the host-processor as required, and a CAN Controller which is implemented in hardware and has a synchronous clock. The CAN controller buffers incoming messages until they can be retrieved by the host-processor, generating an interrupt to let the host processor know that a message is waiting. The CAN Controller is also the buffer for outgoing messages, which it receives from the host-processor and then transmits via the bus. A transceiver handles message processing, and is usually integrated into the CAN Controller. The data rates possible are dependent on the length of the bus. Data rates of up to 1 Mbps are possible at network lengths below 40 metres. Decreasing the data rate to 125 kbps would allow a network length of up to 500 metres.

Transmission of messages in a CAN is based on the producer-consumer (broadcast) principle. A message transmitted by one node (the producer) is received by all other nodes (the consumers). Messages do not have a destination address, but a Message ID. Messages in the standard format have an 11-bit Message ID, enabling 2,048 different messages to be defined for any one system – more than sufficient for most applications. For applications that require a larger number of messages, an extended message format with a 29-bit Message ID may be used, allowing over five hundred million different messages to be defined. Only certain messages will apply to each node on the network, so a node receiving a message must apply acceptance filtering (usually implemented in hardware, and based on the Message ID). If the message received by a node is relevant to it, it will be processed, otherwise it will be ignored. CAN networks may be expanded without modification to existing hardware or software if the devices to be added are purely receivers, and if they only require messages that are already generated by the network.

Arbitration in CAN networks

The standard form of arbitration in a CAN network is Carrier Sense Multiple Access/Bitwise Arbitration (CSMA/BA). If two or more nodes start transmitting at the same time, arbitration is based on the priority level of the message ID, and allows the message whose ID has the highest priority to be delivered immediately, without delay. This makes CAN ideal for real-time, priority-based systems. Each node, when it starts to transmit its Message ID, will monitor the bus state and compare each bit received from the bus with the bit transmitted. If a dominant bit (0) is received when a recessive bit (1) has been transmitted, the node stops transmitting because another node has established priority. The concept is illustrated by the diagram below.

Bitwise arbitration in CAN networksBitwise arbitration in CAN networks

Arbitration is performed as the identifier field is transmitted, and is non-destructive. Each node transmits its 11-bit Message ID, starting with the highest-order bit (bit 10). Binary zero (0) is a dominant bit, and binary one (1) is a recessive bit. Because a dominant bit will overwrite a recessive bit on the bus, the state of the bus will always reflect the state of the message ID with the highest priority (i.e. the lowest number). As soon as a node sees a bit comparison that is unfavourable to itself, it will cease to participate in the arbitration process and wait until the bus is free again before attempting to retransmit its message. The message with the highest priority will thus continue to be transmitted without delay, and unimpeded. In the above illustration, Node 2 transmits bit 5 as a recessive bit (1), while the bus level read is dominant (0), so Node 2 will back off. Similarly, Node 1 will back off after transmitting bit 2 as a recessive bit, whereas the bus level remains dominant. Node 3 is then free to complete transmission of its message.

The Message ID for each system element is assigned by the system designer, and the arbitration method used ensures that the highest-priority messages will always be transmitted ahead of another message, should simultaneous transmissions occur. The bus is thus allocated on the basis of need. The only limiting factor is therefore the capacity of the bus itself. Outstanding transmission requests are dealt with in their order of priority, with minimum delay and maximum utilisation of the available bus capacity. In any system, some parameters will change more rapidly than others. In a motor vehicle, for example, the rpm of the engine will change far more rapidly than the temperature of the engine coolant. The more rapidly changing parameters are probably going to need more frequent monitoring, and for this reason will probably be given a higher priority.

CAN Frame Format

The general format of a CAN message frame is shown below.

The CAN message frame format Data is transmitted using Message Frames. The standard CAN protocol (version 2.0A), also known as Base Frame Format, uses an 11-bit Message ID. The extended CAN protocol (version 2.0B), also now known as Extended Frame Format, supports both 11-bit and 29-bit Message IDs. Most version 2.0A controllers are tolerant of extended format messages, but essentially ignore them. Version 2.0B controllers can send and receive messages in both formats.

The start of a message frame is signaled by a dominant start-of-frame bit, followed by the 11-bit Message ID and the Remote Transmission Request (RTR) bit, which is only set if the message is a data request frame (as opposed to a data frame). It should probably be noted here that, although nodes on a CAN network generally send data without being polled, a node may request the transmission of a specific message by another node in the system. The first two bits (r0 and r1) of the 6-bit control field specify the transmission format (i.e. standard or extended), while the last four bits form the Data Length Code (DLC), which indicates the number of bytes of data transmitted. The data field can contain from zero to eight bytes of data, and is followed by the 16-bit CRC field, containing a 15-bit cyclic redundancy check code which is used by the receiving node to detect errors, and a recessive delimiter bit.

The ACKnowledge field has two bits. The first is the ACK Slot which is transmitted as a recessive bit, but will be overwritten with a dominant bit by any node that successfully receives the transmitted message. The second bit is a recessive delimiter bit. The end-of-frame field consists of seven recessive bits, and signals that error-free transmission of the message has been completed. The end-of-frame field is followed by the intermission field consisting of three recessive bits, after which the bus may be considered to be free for use. Idle time on the bus may be of any length, including zero.

At a data rate of 1 Mbps, it is possible to send in the order of ten thousand standard format messages per second over a CAN network, assuming an average data length of four bytes. The number of messages that could be sent would come down to around seven thousand if all the messages contained the full eight bytes of data allowed. One of the major benefits of CAN is that, if several controllers require the same data from the same device, only one sensor is required rather than each controller being connected to a separate sensor. As mentioned previously, the data rate that can be achieved is dependent on the length of the bus, since the bit time interval is adjusted upwards to compensate for any increase in the time required for signals to propagate along the bus, which is proportional to the length of the bus. Bus length and bit rate are thus inversely proportional.

Message frame format

Message frame for standard format (CAN Specification 2.0A)
Message frame for standard format (CAN Specification 2.0A)

The CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier (ID). In the standard format the length of the ID is 11 bits and in the extended format the length is 29 bits. The message frame for transmitting messages on the bus comprises seven main fields.

A message in the standard format begins with the start bit “start of frame”, this is followed by the “arbitration field”, which contains the identifier and the “RTR” (remote transmission request) bit, which indicates whether it is a data frame or a request frame without any data bytes (remote frame). The “control field” contains the IDE (identifier extension) bit, which indicates either standard format or extended format, a bit reserved for future extensions and – in the last 4 bits – a count of the data bytes in the data field. The “data field” ranges from 0 to 8 bytes in length and is followed by the “CRC field”, which is used as a frame security check for detecting bit errors. The “ACK field” comprises the ACK slot (1 bit) and the ACK delimiter (1 recessive bit). The bit in the ACK slot is sent as a recessive bit and is overwritten as a dominant bit by those receivers which have at this time received the data correctly (positive acknowledgement). Correct messages are acknowledged by the receivers regardless of the result of the acceptance test. The end of the message is indicated by “end of frame”. “Intermission” is the minimum number of bit periods separating consecutive messages. If there is no following bus access by any station, the bus remains idle (“bus idle”).

Standard Data Frame


The CAN standard data frame is shown in Figure 2-1. As with all other frames, the frame begins with a Start- Of-Frame (SOF) bit, which is of the dominant state and allows hard synchronization of all nodes. The SOF is followed by the arbitration field, consisting of 12 bits: the 11-bit identifier and the Remote Transmission Request (RTR) bit. The RTR bit is used to distinguish a data frame (RTR bit dominant) from a remote frame (RTR bit recessive). Following the arbitration field is the control field, consisting of six bits. The first bit of this field is the Identifier Extension (IDE) bit, which must be dominant to specify a standard frame. The following bit, Reserved Bit Zero (RB0), is reserved and is defined as a dominant
bit by the CAN protocol. The remaining four bits of the control field are the Data Length Code (DLC), which specifies the number of bytes of data (0 – 8 bytes) contained in the message. After the control field is the data field, which contains any data bytes that are being sent, and is of the length
defined by the DLC (0 – 8 bytes). The Cyclic Redundancy Check (CRC) field follows the data field and is used to detect transmission errors. The
CRC field consists of a 15-bit CRC sequence, followed by the recessive CRC Delimiter bit. The final field is the two-bit Acknowledge (ACK) field.
During the ACK Slot bit, the transmitting node sends out a recessive bit. Any node that has received an error-free frame acknowledges the correct reception of the frame by sending back a dominant bit (regardless of whether the node is configured to accept that specific message or not). The recessive acknowledge delimiter completes the acknowledge field and may not be overwritten by a dominant bit. 

Extended Data Frame

In the extended CAN data frame, shown in Figure 2-2, the SOF bit is followed by the arbitration field, which consists of 32 bits. The first 11 bits are the Most Significant bits (MSb) (Base-lD) of the 29-bit identifier. These 11 bits are followed by the Substitute Remote Request (SRR) bit, which is defined to be recessive. The SRR bit is followed by the lDE bit, which is recessive to denote an extended CAN frame. It should be noted that if arbitration remains unresolved after transmission of the first 11 bits of the identifier, and one of the nodes involved in the arbitration is
sending a standard CAN frame (11-bit identifier), the standard CAN frame will win arbitration due to the assertion of a dominant lDE bit. Also, the SRR bit in an extended CAN frame must be recessive to allow the assertion of a dominant RTR bit by a node that is sending a standard CAN remote frame. The SRR and lDE bits are followed by the remaining 18 bits of the identifier (Extended lD) and the remote transmission request bit.
To enable standard and extended frames to be sent across a shared network, the 29-bit extended message identifier is split into 11-bit (most significant) and 18-bit (least significant) sections. This split ensures that the lDE bit can remain at the same bit position in both the
standard and extended frames. Following the arbitration field is the six-bit control field. The first two bits of this field are reserved and must be
dominant. The remaining four bits of the control field are the DLC, which specifies the number of data bytes contained in the message.
The remaining portion of the frame (data field, CRC field, acknowledge field, end-of-frame and intermission) is constructed in the same way as a standard data frame

Remote Data Frame

Normally, data transmission is performed on an autonomous basis by the data source node (e.g., a sensor sending out a data frame). It is possible,
however, for a destination node to request data from the source. To accomplish this, the destination node sends a remote frame with an identifier that matches the identifier of the required data frame. The appropriate data source node will then send a data frame in response to the remote frame request. There are two differences between a remote frame (shown in Figure 2-3) and a data frame. First, the RTR bit is at the recessive state and, second, there is no data field. In the event of a data frame and a remote frame with the same identifier being transmitted at the
same time, the data frame wins arbitration due to the dominant RTR bit following the identifier. In this way, the node that transmitted the remote frame receives the desired data immediately. 

An error frame is generated by any node that detects a bus error. An error frame, shown in Figure 2-4, consists of two fields: an error flag field followed by an error delimiter field. There are two types of error flag fields. The type of error flag field sent depends upon the error status of the node that detects and generates the error flag field.

2.4.1 ACTIVE ERRORS
If an error-active node detects a bus error, the node interrupts transmission of the current message by generating an active error flag. The active error flag is composed of six consecutive dominant bits. This bit sequence actively violates the bit-stuffing rule. All other stations recognize the resulting bit-stuffing error and, in turn, generate error frames themselves, called error echo flags.

The error flag field, therefore, consists of between six and twelve consecutive dominant bits (generated by one or more nodes). The error delimiter field (eight recessive bits) completes the error frame. Upon completion of the error frame, bus activity returns to normal and the interrupted node attempts to resend the aborted message.

2.4.2 PASSIVE ERRORS
If an error-passive node detects a bus error, the node transmits an error-passive flag followed by the error delimiter field. The error-passive flag consists of six consecutive recessive bits. The error frame for an errorpassive node consists of 14 recessive bits. From this it
follows that, unless the bus error is detected by an erroractive node or the transmitting node, the message will continue transmission because the error-passive flag does not interfere with the bus.

If the transmitting node generates an error-passive flag, it will cause other nodes to generate error frames due to the resulting bit-stuffing violation. After transmission of an error frame, an error-passive node must wait for six consecutive recessive bits on the bus before
attempting to rejoin bus communications. The error delimiter consists of eight recessive bits and allows the bus nodes to restart bus communications cleanly after an error has occurred.

Overload Frame,Interframe Space 
An overload frame, shown in Figure 2-5, has the same format as an active error frame. An overload frame, however, can only be generated during an interframe space. In this way, an overload frame can be differentiated from an error frame (an error frame is sent during the transmission of a message). The overload frame consists of two fields: an overload flag followed by an overload delimiter. The overload flag consists of six dominant bits followed by overload flags generated by other nodes (and, as for an active error flag, giving a maximum of twelve dominant bits). The overload delimiter consists of eight recessive bits. An overload frame can be generated by a node as a result of two conditions:
1. The node detects a dominant bit during the interframe space, an illegal condition. Exception: The dominant bit is detected during the third bit of IFS. In this case, the receivers will interpret this as a SOF.

2. Due to internal conditions, the node is not yet able to begin reception of the next message. A node may generate a maximum of two sequential overload frames to delay the start of the next message.CAN BUS MESSAGE FRAMES – Interframe SpaceThe interframe space separates a preceding frame (of any type) from a subsequent data or remote frame. The interframe space is composed of at least three recessive bits called the Intermission. This allows nodes time for internal processing before the start of the next message frame. After the intermission, the bus line remains in the recessive state (bus idle) until the next transmission starts.

Detecting and signalling errors

Unlike other bus systems, the CAN protocol does not use acknowledgement messages but instead signals any errors that occur.

Cyclic Redundancy Check (CRC)

The CRC safeguards the information in the frame by adding redundant check bits at the transmission end. At the receiver end these bits are re-computed and tested against the received bits. If they do not agree there has been a CRC error.

Frame check

This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated “format errors”.

 ACK errors

As mentioned above, frames received are acknowledged by all recipients through positive acknowledgement. If no acknowledgement is received by the transmitter of the message (ACK error) this may imply that there is a transmission error which has been detected only by the recipients, that the ACK field has been corrupted or that there are no receivers.

The CAN protocol also implements two mechanisms for error detection at the bit level:

Monitoring

The ability of the transmitter to detect errors is based on the monitoring of bus signals: each node which transmits also observes the bus level and thus detects differences between the bit sent and the bit received. This permits reliable detection of all global errors and errors local to the transmitter.

Bit stuffing

The coding of the individual bits is tested at bit level. The bit representation used by CAN is NRZ (non-return-to-zero) coding, which guarantees maximum efficiency in bit coding. The synchronization edges are generated by means of bit stuffing, i.e. after five consecutive equal bits the sender inserts into the bit stream a stuff bit with the complementary value, which is removed by the receivers. The code check is limited to checking adherence to the stuffing rule.

 If one or more errors are discovered by at least one station (any station) using the above mechanisms, the current transmission is aborted by sending an “error flag”. This prevents other stations accepting the message and thus ensures the consistency of data throughout in the network.

After transmission of an erroneous message has been aborted, the sender automatically re-attempts transmission (automatic repeat request). There may again be competition for bus allocation. As a rule, retransmission will be begun within 23 bit periods after error detection; in special cases the system recovery time is 31 bit periods.

However effective and efficient the described method may be, in the event of a defective station it might lead to all messages (including correct ones) being aborted, thus blocking the bus system if no measures for self-monitoring were taken. The CAN protocol therefore provides a mechanism for distinguishing sporadic errors from permanent errors and localizing station failures (fault confinement).

This is done by statistical assessment of station error situations with the aim of recognizing a station’s own defects and possibly entering an operating mode where the rest of the CAN network is not negatively affected. This may go as far as the station switching itself off to prevent messages erroneously recognized as incorrect from being aborted.

Extended format CAN messages

The SAE “Truck and Bus” subcommittee standardized signals and messages as well as data transmission protocols for various data rates. It became apparent that standardization of this kind is easier to implement when a longer identification field is available.

To support these efforts, the CAN protocol was extended by the introduction of a 29-bit identifier. This identifier is made up of the existing 11-bit identifier (base ID) and an 18-bit extension (ID extension). Thus the CAN protocol allows the use of two message formats:

  • StandardCAN ( Version 2.0A ) und
  • ExtendedCAN ( Version 2.0B )

As the two formats have to coexist on one bus it is laid down which message has higher priority on the bus in the case of bus access collisions with differing formats and the same base identifier:

! the message in standard always has priority over the message in extended format.

 Message frame standard format (CAN specification 2.0A)

CAN controllers which support the messages in extended format can also send and receive messages in standard format. When CAN controllers which only cover the standard format (Version 2.0A) are used on one network, then only messages in standard format can be transmitted on the entire network. Messages in extended format would be misunderstood. However there are CAN controllers which only support standard format but recognize messages in extended format and ignore them (Version 2.0B passive).

The distinction between standard format and extended format is made using the IDE bit (Identifier Extension Bit) which is transmitted as dominant in the case of a frame in standard format. For frames in extended format it is recessive.

The RTR bit is transmitted dominant or recessive depending on whether data are being transmitted or whether a specific message is being requested from a station. In place of the RTR bit in standard format the SRR (substitute remote request) bit is transmitted for frames with extended ID. The SRR bit is always transmitted as recessive, to ensure that in the case of arbitration the standard frame always has priority bus allocation over an extended frame when both messages have the same base identifier.

Message frame for extended format (CAN specification 2.0B)

Unlike the standard format, in the extended format the IDE bit is followed by the 18-bit ID extension, the RTR bit and a reserved bit (r1).

All the following fields are identical with standard format. Conformity between the two formats is ensured by the fact that the CAN controllers which support the extended format can also communicate in standard format.

Error detection and management

Nodes that transmit messages on a CAN network will monitor the bus level to detect transmission errors, which will be globally effective. In addition, nodes receiving messages will monitor them to ensure that they have the correct format throughout, as well as recalculating the CRC to detect any transmission errors that have not previously been detected (i.e. locally effective errors). The CAN protocol also has a mechanism for detecting and shutting down defective network nodes, ensuring that they cannot continually disrupt message transmission.

When errors are detected, either by the transmitting node or a receiving node, the node that detects the error signals an error condition to all other nodes on the network by transmitting an error message frame containing a series of six consecutive bits of the dominant polarity. This triggers an error, because the bit-stuffing used by the signalling scheme means that messages should never have more than five consecutive bits with the same polarity (when bit-stuffing is employed, the transmitter inserts a bit of opposite polarity after five consecutive bits of the same polarity. The additional bits are subsequently removed by the receiver, a process known as de-stuffing). All network nodes will detect the error message and discard the offending message (or parts thereof, if the whole message has not yet been received). If the transmitting node generates or receives an error message, it will immediately thereafter attempt to retransmit the message

CAN gateway

A CAN/CAN gateway incorporates two CAN controller with a microcontroller. CAN messages are received by a CAN controller, processed by the microcontroller and then sent by the opposite CAN controller. Processed means that messages may be filtered, remapped to different CAN identifiers or that the data content of the messages may be altered. Also different baud rates may be used on both sides.

A CAN/CAN gateway connects two CAN systems and controls the message exchange by applying rules and functions on these messages. This distinguishes the gateway from the repeater, which acts more or less like a piece of cable. This extended functionality leads to higher costs in respect to a CAN repeater.

The main issue while using a CAN/CAN gateway is the latency time for a received message to be sent out on the other side. For an idle network this time is the propagation delay of the gateway. But as soon as there is busload this time gets undetermined. This has two reasons. Even if there is only busload on the receiving side, the propagation delay increases, because the microcontroller has to spend more and more time in the CAN receive interrupt routine and a message to be sent out has to wait for the processor to have time for doing so. If there is busload on both sides, the CAN controller has to wait for an idle bus to get access to it. This time increases with the busload and depends also on the CAN identifier used due to their priority. Therefor the CAN system integrator has to take extra care on the busload, if a gateway is going to be used.

From the application point of view the implications of this issue get obvious while e.g. looking on the SYNC message of the CANopen protocol. This message is used to synchronize actions on different CANopen nodes to the moment they receive the message. If the SYNC message is delayed by an arbitrary period of time, system behavior tends to get unpredictable. Filtering, also by using the acceptance filter of the CAN controller will help, but cannot reduce the effect completely.

Due to the fact that the CAN/CAN gateway acts on messages, error frames will not be distributed from one side to the other. Furthermore CAN/CAN gateways can have the full extend of bus length on both sides for a given baud rate and the full count of modules.

The motivation to use a CAN/CAN gateway is given, if two CAN systems should be connected, but the message flow has to be controlled. In this case the system integrator benefits from the versatile functionality offered by this devices. While e. g. developing a new electronic control unit (ECU) for an automotive application, the system designer may use a CAN/CAN gateway to shift identifiers or to modify data contents of specific messages and is able by this means to combine old and new units.

A CAN/CAN gateway which routes the CAN messages over a media like an optical fiber (CG-FL, EtherCAN FX) or Ethernet (EtherCAN CI) using a protocol like TCP or UDP is called a CAN/CAN router. They extend the concept of a gateway to a larger physical expansion, but preserve the attributes of a gateway. This devices are able to realize point to point connections of CAN systems over distances up to 40km with low latencies and enable sophisticated CAN applications.

CAN Repeater

Image: The basic functioning scheme of a CAN Repeater
Basic functioning scheme of a CAN repeater

A CAN repeater incorporates two CAN transceiver with a glue logic. It propagates a CAN signal from one side to the other and vice versa. Therefor an ideal CAN repeater acts like a piece of cable, it is transparent for the CAN signal. Due to the propagation delay of the two CAN transceiver and the glue logic an equivalent length can be given for a specific CAN repeater. It is about 40m for a repeater without galvanic decoupling and about 60m for a device with galvanic decoupling.

The maximum length of a CAN system for a given baud rate cannot be extended by the use of a CAN repeater. But a CAN repeater allows to implement topologies different than a simple line. Stub lines or star topologies can be realized by using CAN repeaters.

If a CAN network is divided into two segments by a CAN repeater both of them must be terminated correctly with two 120R resistors at its ends. Both segments are physically independent, but form a single CAN network from the logical point of view. This means that the maximum length of a stub line is only determined by the maximum distance between two end points of the network. A CAN line, which has a stub somewhere in the middle, has three endpoints “A”, “B” and “C”. The maximum of the three distances “AB”, “AC” and “BC” is essential for determining the maximum baud rate in this specific system. It has to be noted that the equivalent cable length of the CAN repeater has to be taken into concern. For an example on this topic visit our article: CAN Repeater example

A CAN repeater can be used to regenerate the CAN signal for very long CAN lines or it can help to increase the maximum count of nodes in a CAN system. Due to the fact that a CAN repeater is transparent for the CAN signal error frames are also propagated. But a repeater may offer the functionality to disconnect a segement, which is locked to a permanent dominant state. This can help to increase the system reliability. Most of our repeaters include this feature.

Our CAN repeaters are offered with a parameter called inhibit time. It is important to choose the correct value for this parameter that the repeater will work as expected in a dedicated system. We recommend to set it to 10-20% of the bit time. More details on this subject can be found here: CAN inhibit time

The most important motivation to use a CAN repeater is to implement a network topology which is not a line. This approach can help to decrease the overall length of a CAN system. If a galvanic decoupling between two parts of a CAN network is needed, it can be realized by a galvanic decoupled CAN repeater.

A CAN repeater gives the opportunity to offer a solution to network problems, which otherwise could only be solved by higher costs or as worst case by having to use something different than CAN.

CAN & Flexray differences:[youtube   http://www.youtube.com/watch?v=sw3ADKPo1Uo&feature=player_detailpage]

Create a free website or blog at WordPress.com.

Up ↑