for 1722
This content delves into the considerations and potential impacts related to CAN XL encapsulation, handling oversized CAN XL frames, compatibility with 1722 formats CAN and CAN FD, diagnosis information, recent proposals, and the existing format for CAN and CAN FD. It also discusses proposals for VERSION 2 CONTROL FORMATS and relevant protocol fields for CAN XL.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
CAN XL ACF Message Type for 1722 Ulrich Stech, Felix Fellhauer Robert Bosch GmbH 4/13/2021 1
What to Consider Work items and potential areas of impact to 1722-2016: What changes are required to allow for CAN XL encapsulation? How to deal with oversized CAN XL frames? (in CAN XL, payload size of up to 2048 Byte is possible) Consider compatibility to 1722 formats CAN and CAN FD? (possible to have a single format generic for all CAN versions?) Diagnosis information? 2
Recent proposals considering proposals for VERSION 2 CONTROL FORMATS [1] already proposed: extend the can_bus_id to 11 bit (the lower 5 bit are in the same location) rtr (remote transmission request) & eff (extended frame format) are not moved 3
Existing Format for CAN and CAN FD (P1722b) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ACF AVPDU Header acf_msg_type acf_msg_length pad mtv rtr eff can_bus_id message_timestamp brs fdf esi can_identifier (29 bit) can_msg_payload (0 8 Byte Data field) additional messages Reference: IEEE 1722, 10.4.3 CAN/CAN FD Message / IEEE 1722, 10.4.4 Abbreviated CAN/CAN FD Message two variants exist 1. CAN/CAN FD Message 2. Abbreviated CAN/CAN FD Message (w/o timestamp) includes extended can_bus_id to 11 bit (lower 5 bit in same location) rtr (remote transmission request) & eff (extended frame format) are legacy compatible no reserved bits left to add multiplexed functionality for CAN XL -> new format required 4
CAN XL, native PDU Arbitration Field priorityidentifier priorityidentifier Arbitration Field Control Field Data Field Data Field CRC Field FCRC ACK Field EOF EOF Control Field DLC DLC CRC Field FCRC Bit 30 ACK Field DAS DAS XLFF XLFF ADS ADS SDT SDT SBC PCRC VCID VCID AF AF Byte(0) Byte(0) Byte(DLC) Byte(DLC) FCP ACK ACK SBC SBC 2 PCRC Bit 11 FCP FCP 2 Bit 7 Bit 1 Bit 7 Bit 1 SBC 1 SBC 0 SBC 1 SBC 2 SBC 0 FCP 3 FCP 1 FCP 0 FCP 3 FCP 2 FCP 1 FCP 0 resXL resXL ACK ACK XL ACK ACK Bit 10 Bit 12 Bit 31 Bit 31 XL Frame Format Frame Format Bit 10 Bit 12 Bit 11 Bit 31 Bit 31 Bit 30 ID 28 ID 27 ID 19 ID 18 ID 28 ID 27 ID 19 ID 18 ... ... ... ... DAH DAH AH2 AH1 AH2 AH1 AL1 Dlm AL1 Dlm Slot Slot RRS ADH RRS ADH SOF SOF SEC SEC Bit 7 Bit 0 Bit 6 Bit 7 Bit 6 Bit 1 Bit 0 Bit 9 Bit 1 Bit 0 Bit 1 Bit 0 Bit 0 Bit 7 Bit 1 Bit 0 Bit 7 Bit 6 Bit 1 Bit 0 Bit 1 Bit 0 DH1 DH2 Bit 7 Bit 0 Bit 6 Bit 7 Bit 6 Bit 1 Bit 0 Bit 9 Bit 1 Bit 0 Bit 1 Bit 0 Bit 0 Bit 7 Bit 1 Bit 0 Bit 7 Bit 6 Bit 1 Bit 0 Bit 1 Bit 0 DH1 DH2 FDF FDF XLF XLF DL1 DL1 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... IDE IDE Bit Time Bit Time Arbitration Phase Nominal bit time XL Data Phase XL Data bit time Arbitration Phase Arbitration Phase Nominal bit time SBC Arbitration Mode XL Data Phase XL Data bit time DAS Arbitration Phase Nominal bit time Nominal bit time Arbitration Field Control Field DLC Data Field CRC Field FCRC ACK Field EOF XLFF priorityidentifier ADS Transceiver Mode with mode switch SDT PCRC VCID AF Byte(0) Byte(DLC) FCP ACK Transceiver Mode with mode switch without mode switch without mode switch Bit 7 Bit 1 SBC 1 SBC 2 SBC 0 FCP 3 FCP 2 FCP 1 FCP 0 resXL ACK ACK XL Frame Format Bit 10 Arbitration Mode Bit 12 Bit 11 Bit 31 Bit 31 Bit 30 Data RX Mode or Data TX Mode Arbitration Mode Arbitration Mode Data RX Mode or Data TX Mode Arbitration Mode Arbitration Mode ID 28 ID 27 ID 19 ID 18 ... ... DAH AH2 AH1 AL1 Dlm Slot RRS ADH SOF SEC Bit 7 Bit 0 Bit 6 Bit 7 Bit 6 Bit 1 Bit 0 Bit 9 Bit 1 Bit 0 Bit 1 Bit 0 Bit 0 Bit 7 Bit 1 Bit 0 Bit 7 Bit 6 Bit 1 Bit 0 Bit 1 Bit 0 DH1 DH2 Considerations for encapsulation: data field size up to 2048 byte Priority ID: identifier used for arbitration on CAN bus RRS bit: to not carrying information, but to be considered for arbitration SDT: SDU type, describes content of data field (comparable to ether-type) SEC: simple extended content, indicates simple- or extended header VCID: 8 bit, Virtual CAN Identifier AF: acceptance field CiA currently discussion L2 fragmentation approaches could be aligned but it might happen that even though CAN XL L2 segmentation does not have a segment counter, it is relevant for 1722 tunnel as there frames can be lost it shall be checked, whether CAN XL L2 Fragmentation is relying on Priority ID FDF XLF DL1 ... ... ... ... ... ... ... ... ... IDE Bit Time Arbitration Phase Nominal bit time XL Data Phase XL Data bit time Arbitration Phase Nominal bit time Transceiver Mode with mode switch without mode switch Arbitration Mode Data RX Mode or Data TX Mode Arbitration Mode Arbitration Mode 5
CAN XL Proposal, Opt. A w/o Segmentation 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ACF AVPDU Header acf_msg_type acf_msg_length pad mtv rsv can_bus_id message_timestamp vcid sdt rsv rrs sec priority_id acceptance field can_msg_payload vcid: sdt: rrs: sec: priority_id: 11 bit, wide identifier used for arbitration on CAN bus (comparable to legacy base identifier) acc.-field: 32 bit, allows to filter frames on ingress 8 bit, Virtual CAN Identifier 8 bit, Service Data Unit Type 1 bit, RRS bit legacy leftover from CAN(FD), no functional assignment for CAN XL, can be chosen freely 1 bit, simple extended content indicates simple- or extended header 6
CAN XL Proposal, Opt. B w/ Segmentation 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ACF AVPDU Header acf_msg_type acf_msg_length pad mtv rsv can_bus_id message_timestamp vcid sdt rsv rrs sec priority_id acceptance field sequence_num rsv fragment_offset can_msg_payload leaves room for CiA frag. adaption sequence_num: 1 octet, field indicates the sequence of ACF AVTPDUs in a stream fragment_offset: 11 bit, -> allows to chunk max. CAN XL payload size of 2048 bit (max.) into Ethernet compatible size (dependent on CIA, approach/size could be aligned with final spec for CAN XL L2 Fragmentation) Note: CAN XL specific L2 fragmentation mechanism has not to be considered (tunneling is transparent) 7
Discussion Diagnosis Are there specific requirements w.r.t diagnosis / error signaling e.g. [2]? General Purpose Control (GPC) message type, could be used for proprietary encapsulation of diagnosis information 8
References [1]: 1722B PROPOSAL FOR ENHANCED CONTROL FORMATS V3, D. Pannell, April 22 2020 [2]: CAN ERROR-HA NDLI N G OVER IEEE1722B, Turner, September 15 2020 9
