CAN XL ACF Message Type for 1722 Ulrich

What to Consider Work items and potential areas of impact to 1722 -2016: •

Recent proposals • considering proposals for “VERSION 2 CONTROL FORMATS” [1] • already proposed:

Existing Format for CAN and CAN FD (P 1722 b) 0 1 2 3

CAN XL, native PDU Considerations for encapsulation: • data field size up to 2048

CAN XL Proposal, Opt. A w/o Segmentation 0 1 2 3 4 5 6

CAN XL Proposal, Opt. B w/ Segmentation 0 1 2 3 4 5 6

Discussion Diagnosis • Are there specific requirements w. r. t diagnosis / error signaling

References • [1]: 1722 B – PROPOSAL FOR ENHANCED CONTROL FORMATS – V 3,

Slides: 9

Download presentation

CAN XL ACF Message Type for 1722 Ulrich Stech, Felix Fellhauer Robert Bosch Gmb. H 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 (P 1722 b) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 mtv rtr eff 21 22 23 24 25 26 27 28 29 30 31 ACF AVPDU Header acf_msg_type acf_msg_length pad 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 no reserved bits left to add multiplexed 2. Abbreviated CAN/CAN FD Message (w/o timestamp) functionality for CAN XL • includes extended can_bus_id to 11 bit (lower 5 bit in same location) -> new format required • rtr (remote transmission request) & eff (extended frame format) are legacy 4 compatible

CAN XL, native PDU 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 • Ci. A currently discussion L 2 fragmentation – approaches could be aligned • but it might happen that even though CAN XL L 2 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 L 2 Fragmentation is relying on Priority ID 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 rrs sec priority_id message_timestamp vcid sdt rsv acceptance field can_msg_payload • • • vcid: sdt: rrs: sec: priority_id: acc. -field: 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 11 bit, wide identifier used for arbitration on CAN bus (comparable to legacy base identifier) 6 32 bit, allows to filter frames on ingress

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 rrs sec priority_id message_timestamp vcid sdt rsv acceptance field sequence_num rsv can_msg_payload fragment_offset leaves room for Ci. A 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 L 2 Fragmentation) 7 Note: CAN XL specific L 2 fragmentation mechanism has not to be considered (tunneling is transparent)

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]: 1722 B – PROPOSAL FOR ENHANCED CONTROL FORMATS – V 3, D. Pannell, April 22 2020 • [2]: CAN ERROR-HA NDLI N G OVER IEEE 1722 B, Turner, September 15 2020 9