Hi Folks,
Couple of weeks ago, I asked a question about the networking and security in Vehicle networking. Colleagues answered my question thankfully, but after some digging in the subject deeply, I found it something new to me and now I would like to share a sum of what I had read these last days.
In automotive engineering, a vehicle bus is a specialized internal communications network that interconnects components inside a vehicle (e.g., automobile, bus, train, industrial or agricultural vehicle, ship, or aircraft). ... Protocols include Controller Area Network (CAN), Local Interconnect Network (LIN) and others. We will focus on CAN FD protocol in this post.
Today's vehicles include a complex symbiosis of intelligent electronic systems and integrated mechanical structures. Today, electronic components and systems account for over 20% of the cost of a high-end passenger car, and this percentage figure is increasing rapidly. Electronic systems now provide the technology to enable the manufacturer to deliver new features and to meet the mandatory regulation requirements in a cost-effective manner. Vehicle electronic systems are now commonplace and are growing in terms of both quantity and complexity. In this paper, we will provide an insight into the In Vehicle Network Systems, Overview and the emerging Vehicle Networking Standards.
CAN FD “CAN Flexible date-rate”
The idea behind the CAN FD protocol is to increase the cycle-rate between network arbitration and the acknowledgment field of a CAN frame. Since at this stage only one node is able to send on the network the maximum data rate only depends on the internal delay time of the CAN transceiver and the data signal (about 5 ns/m). In this way, it is possible to realize data-rates up to 15 Mbit/s with network lengths up to 40 m.
In CAN FD, the frame/message ID uses the 29-bits format used in the Extended ID version of classic CAN (Standard ID is 11 bits long). The message payload size has been increased to 64 bytes of data in each CAN-frame / message, compared to only 8-bytes in the classic CAN frame.
The CAN FD frame is backwards compatible and quite similar to the Classical CAN frame. A new feature is the bit BRS (bit-rate-switch) in the arbitration field, which is used to recognize the higher data rate. There is also the ESI (error state indicator) which is related to the control panel and displays the error-mode. In order to verify the data-field length the bit FDF (FD format) was defined as well as a three-bit wide stuff bit counter. The sender counts the number of stuff bit and transmits the result as gray-coded 3-bit-value. The recipient also counts the incoming stuff bit and compares their values. The transmission reliability is increased by a parity bit attached to the sequence and by a fixed stuff bit in the CRC field. The RTR bit, however, is being ignored, since the CAN FD protocol does not support any remote frames. With correction of the error detection mechanism of the CAN FD standard (ISO 11989-1/2015) such as adding the stuff bit counter the protocol reaches a Hamming distance of six. It is possible to distinguish up to five arbitrarily distributed bit errors leading to an automatic-repeated message. This makes the protocol an interesting option for safety-related areas.
Why CAN FD?
The CAN protocol has been around since 1986 and it's popular: Practically any machine that moves utilizes CAN today - whether it's cars, trucks, boats, planes or robots. But with the rise of modern technology, the "Classical" CAN protocol (official term used in ISO 11898-1:2015) is pressured: A rise in vehicle functionality is driving an explosion in data Networks are increasingly limited by the 1-Mbit/s bandwidth to cope, OEMs create complex & costly workarounds Specifically, Classical CAN struggles with substantial overhead (>50%) as each CAN data frame can only contain 8 data bytes. Further, the network speed is limited to 1 Mbit/s, restricting the implementation of data-producing features. CAN FD resolves these issues - making it future-proof.
How does CAN FD work?
During arbitration, a "bit time" provides sufficient delay between each bit to allow every node on the network to react. To be certain that every node is reached within the bit time, a CAN network running at 1 Mbit/s needs to have a maximum length of 40 meters (in practice 25 meters). Speeding up the arbitration process would reduce the maximum length to unsuitable levels. On the other hand, after arbitration there's an "empty highway" - enabling high speed during the data transmission (when there is just one node driving the bus-lines). Before the ACK slot - when multiple nodes acknowledge the correct reception of the data frame - the speed needs to be reduced to the nominal bit-rate.
In short, it is necessary to find a way to only increase the speed during the data transmission.
Solution: The CAN FD frame The CAN FD protocol introduces an adjusted CAN data frame to enable the extra data bytes and flexible bit-rates. Below we compare an 11-bit Classical CAN frame vs. an 11-bit CAN FD frame (29-bit is also supported):
In conclusion, CAN FD with high bit-rate will increase real-time performance, because the higher bit-rate makes the CAN-frames shorter in time, reducing latency in the communication. By sending more data in each frame it is possible to increase the data throughput, but this will lower the Realtime performance if not combined with the use of higher bit-rate. In many cases, long CAN frames with 64 bytes will be used during programming, which is normally done when a system is on pause and there are no real time controls running. Even without real-time demand, it is still of interest to use the higher bit-rate to increase data throughput and by that, reduce the download time.
I know the subject is much more complex than been wrote above, but I hope this been informative to you.
