Mux-mode

This page describes CANmod.router mux-mode in detail. When using software tools supporting mux-mode, knowing details regarding the implementation of mux-mode is not required. Find tools supporting mux-mode on csselectronics.com.

This page can be used to gain a better understanding of how mux-mode works and how to develop custom tools to support mux-mode.

In mux-mode, traffic from/to the secondary CAN-buses (S1-S4) is routed through the primary CAN-bus (P) using two tunnels: the output-tunnel and the input-tunnel. The CANmod.router configuration defines a set of message IDs assigned to the tunnels.

A user (CAN-bus node) connected to the primary bus can communicate with the secondary buses through the tunnels as if directly connected to each bus.

Note

While the secondary buses support CAN-FD, it is not required that the primary bus supports CAN-FD.

Note

The primary bus carries the sum of traffic from all secondary interfaces. If possible, it is recommended to configure the primary bus to use CAN-FD with a high data-bit rate to increase the bandwidth.

Output-tunnel

The output-tunnel transfers data from the secondary buses (e.g. received messages, transmission acknowledgments, and error frame events) to the primary bus. Below figure illustrates how traffic is received on the secondary buses, muxed by the CANmod.router, transmitted through the output-tunnel on the primary bus, received by a user CAN-bus node, and demuxed by the user software tool (dashed lines). Once demuxed by the user, the original traffic on S1-S4 is restored.

../../../../_images/mux_mode_flow_rl.gif

The output-tunnel. Data from the secondary buses (S1-S4) is routed through the primary bus (P) (on ID 0x10). The dashed lines represent demuxing by the user software tool.

Input-tunnel

The intput-tunnel transfers data from the primary bus to the secondary buses (e.g. transmission requests). Below figure illustrates how traffic is generated and muxed by the user software tool (dashed lines), transmitted through the input-tunnel on the primary bus, received and demuxed by the CANmod.router, and placed on the secondary buses.

../../../../_images/mux_mode_flow_lr.gif

The intput-tunnel. Data to the secondary buses (S1-S4) is routed through the primary bus (P) (on ID 0x11). The dashed lines represent demuxing in the user software tool.

Multiplexing

This section describes in detail how traffic is multiplexed such that it can be transmitted through the tunnels (using a fixed set of message IDs on a single bus) and restored at the other side.

Below figure illustrates the multiplexing stack. Each layer of the stack is explained in detail below.

../../../../_images/router_mux_stack.svg

Multiplexing stack. The dashed part of the stack is implemented by the user software tool.

Packaging

Bus traffic is packaged such that it can be transferred as message payloads and restored by the receiver. Below table lists how the different frame types are packaged.

CB: Classical-Base, CE: Classical-Extended, FB`: FD-Base, FE: FD-Extended, ER: Error

Byte

0

1

2

3

4

Bit

7-5

4

3

2-0

7

6

5

4

3

2

1

0

7-0

7-0

7-0

CB

ch

xtd(0)

fd(0)

dlc

tx

rtr

0

0

id

-

CE

ch

xtd(1)

fd(0)

dlc

tx

rtr

id

FB

ch

xtd(0)

fd(1)

dlc

tx

brs

0

0

id

-

FE

ch

xtd(1)

fd(1)

dlc

tx

brs

id

ER

ch

0

0

1

1

1

error-type

-

  • ch: Channel index

    • 0 = S1

    • 1 = S2

    • 2 = S3

    • 3 = S4

  • xtd: Extended ID frame

  • fd: FD frame

  • dlc: DLC

  • tx: Transmission acknowledgement

  • rtr: Remote transmission request

  • brs: Bit-rate-switch

  • ID: Identifier

  • error-type:

    • 0: BIT

    • 1: ACK

    • 2: Form

    • 3: Stuff

    • 4: CRC

    • 5: DLC (must always be in range 0-8 for CB and CE frames)

    • 6: Bus-off recovery[1]

    • 255: Other

To optimize throughput on the primary bus, several frames can be appended in one payload (up to 512 bytes).

Note

The ESI flag is ignored in packaging of CAN-FD messages.

Transport

The packaged payload (containing one or more of the original frames) can be larger than what can be carried by a single message frame. By using a transport layer, it becomes possible to transport big payloads across multiple frames. The CANmod.router transport layer uses a subset of the frames defined by ISO 15765-2 (commonly referred to as ISO-TP). The ISO-TP addressing modes used are Normal-11-bit and Normal-29-bit.

The transport layer frames types are listed in below table.

Byte

0 (7-4)

0 (3-0)

1

Single frame standard (SF)

0b0000

DL

-

Single frame FD (SF)

0b0000

0b0000

DL

First frame (FF)

0b0001

DL

Consecutive frame (CF)

0b0010

SN

-

  • DL: Data length

  • SN: Sequence number (consecutive with wraparound)

Payloads are transmitted using single-frames when possible. Payloads exceeding a single-frame are transmitted using a first-frame followed by one or more consecutive frames. Data payloads are optimized by always using the shortest possible DLC. For DLC 9 to 15, unavoidable padding uses byte value 0xCC.

Examples

Below examples assume that the primary bus is set up to use standard CAN (not CAN-FD).

Note

It is possible to route CAN-FD traffic on the primary port using standard CAN.

Example 1: Traffic from the secondary interfaces packaged by the CANmod.router.

The following four message frames are received by the CANmod.router on the secondary interfaces:

#

ch

xtd

fd

dlc

tx

rtr

brs

id

payload

1

S1

0

0

1

0

0

0

0x7F1

0x01

2

S2

1

0

2

0

0

0

0x1FFFFFF2

0x0102

3

S3

0

1

3

0

0

0

0x7F3

0x010203

4

S4

1

1

4

0

0

0

0x1FFFFFF4

0x01020304

The four frames are packaged as described in Packaging:

  • 1: 0087F101

  • 2: 311FFFFFF20102

  • 3: 4987F3010203

  • 4: 7A1FFFFFF301020304

Concatenated, the payload becomes: 0087F101311FFFFFF201024987F30102037A1FFFFFF301020304 (26 bytes).

The payload now enters the transport layer as described in Transport. As the primary CAN-bus is configured to standard CAN (not FD), it is not possible to store the entire payload (26 bytes) in one frame. The transport layer splits the payload into multiple frames using a first-frame followed by one or more consecutive-frames as demonstrated below.

The payload is split into one first-frame followed by 3 consecutive frames.

#

ch

xtd

fd

dlc

tx

rtr

brs

id

payload

FF

P

0

0

8

0

0

0

0x10

0x101A0087F101311F

CF1

P

0

0

8

0

0

0

0x10

0x21FFFFF201024987

CF2

P

0

0

8

0

0

0

0x10

0x22F30102037A1FFF

CF3

P

0

0

7

0

0

0

0x10

0x23FFF301020304

When the four above frames are received by the user, the original traffic from the secondary interfaces can be restored.

Example 2: A transmission request (for a secondary bus) is transmitted by the user using the primary bus.

The user wants to transmit the following message on bus S1:

#

ch

xtd

fd

dlc

rtr

brs

id

payload

1

S1

0

0

1

0

0

0x7F1

0x01

The frame is packaged as described in Packaging:

  • 1: 00C7F101

Note

Note that the tx flag is set.

The payload now enters the transport layer as described in Transport. As the payload is only four bytes, it can fit into a single frame (even when CAN-FD is not used). The single-frame, to be transmitted on the primary bus, becomes:

#

ch

xtd

fd

dlc

rtr

brs

id

payload

SF

P

0

0

5

0

0

0x11

0x0400C7F101

By transmitting above message on the primary bus, the user instructs the CANmod.router to transmit the original message on bus S1.

Note

If configured to do so, the CANmod.router will respond with a transmission acknowledgement once the message has been successfully placed on the secondary bus.