CAN - FERAL Features

CAN FERAL Architecture

This section describes the architecture of CAN network implementation in FERAL. The CAN network simulation model makes use of the FERAL common networking module, also referred to as COMNET, which defines a basic infrastructure for simulating networks and offers foundation classes for building a network infrastructure in Java. Components of COMNET provides basic infrastructures that can be utilized by specific network simulation models. Following sections provide a high-level and low-level explanation of COMNET architecture and how CAN network utilizes the COMNET module.

High-Level Architecture

According to the COMNET architecture depicted in Figure 1, the composition of a Network typically includes a Topology, which in turn comprises Application Interfaces, Network Devices, and Medium. External FERAL applications, created as FERAL Workers, establish connections to the Network through the Application interfaces. These interfaces serve as entry points to the network and are interconnected with the Network Device. When a worker transmits an event, the Application Interface converts each event received into a Logic Frame. This logic frame contains both the data to be transmitted and the network address. The Application Interface then forwards the Logic Frame to the Network Device, where it is internally transformed into a Network-Specific Frame corresponding to the CAN Network configuration type (e.g., CAN Standard, CAN FD, or CAN XL) for transmission via the Medium to the recipient's network device.

Upon receiving a Network-Specific Frame from the Medium, the Network Device converts this frame back into a Logic Frame and forwards it to the recipient's Application Interface.

Figure 1: CAN FERAL High-Level Architecture

Low-Level Architecture

Figure 2 depicts the low level architecture of CAN FERAL simulation model. This architecture shows the connection between network components via links and ports. From the diagram, it can be seen that Network Devices further comprises into Network Coder, Controller and Queue. In the following sections, components of the networks are described.

Figure 2: CAN FERAL High-Level Architecture

Application Interface

The ApplicationInterface defines the interaction point between applications and the network simulation. It defines the amount of information that need to be communicated. Typically, value-based interfaces are used, e.g. they will expect to receive instances of ValueEvent<>. They provide communication endpoints that hide all network-specific properties, e.g. the CAN ID, MAC Address, or encoded frame size from the application. Applications therefore only need to provide the payload data that they want to transmit via the network as the payload of the ValueEvent<>. When data is transferred from a FERAL application, the Application Interface receives new ValueEvents through the FERAL ports, which specifically includes network-specific information such as network address or payload size. These properties are defined at network creation type as properties of each individual FERAL port that the ApplicationInterface offers to the application side. The network-specific information is added by a NetworkCoder inside the ApplicationInterface which transforms the ValueEvent<> into a LogicFrame<ValueEvent<>>. When data is transferred to a FERAL application using the Application Interface, the network-specific information is removed from the message and utilized to determine the FERAL Port to which the value message should be directed.

The application interface enables functional communication between applications over a simulated network. Since all network-specific data is stored in the Tx and Rx ports, the applications do not need to know what kind of network they are utilizing. This provides a clear separation between applications and network simulation and is perfectly suited for implementing communication layers that require this separation.

Network Coder

Within the Network Device, the Network Coder is responsible for the conversion of Logic Frames into network-specific frames and vice versa. Specifically, in the context of CAN, it constructs the CAN frame according to the message type (CAN, CAN FD, or CAN XL). When the network device receives a Logic Frame from the Application Interface, it directs it to the Network Coder. Conversely, upon receiving a network-specific frame from the Medium, Network coder converts it into a Logic Frame and transmits the frame to the Application Interface.

Queue

Every network device maintains a Queue of frames, where all the incoming frames are queued and subsequently popped for processing. This queue incorporates ports connected to both the coder and controller. The coder component adds network-specific frames received from the Application Interface to the queue, while the controller component adds network-specific frames received from the medium. This arrangement facilitates the systematic processing of frames within the Network Device, ensuring efficient handling of incoming data.

Controller

Every Network Device features a Controller tasked with transmitting messages in the sequence they are retrieved from the queue. Specifically in the CAN implementation, this controller is a frame-based CAN controller linked to a frame-based CAN Medium. It manages incoming frames and introduces necessary delays based on factors such as payload size and adherence to the CAN standard. This ensures that messages are transmitted according to the specified order and with appropriate timing considerations within the CAN network.

Medium

The Medium is instantiated only once per network and defines the common functionality of a simulated network, e.g. the simulation of the physical layer.

Ports and Links

Several applications may connect to the same network interface that can transmit and receive value events to and from the ApplicationInterface instance. Communication between the ApplicationInterface and the Device interface is via the application port of the device interface. It expects messages of type Logic Frame. Communication between the medium port and the medium implementation is specific to the network simulation model. The application interface defines transmit (Tx) and receive (Rx) ports. Tx ports receive value messages from applications and create, based on the port properties, a Logic Frame that encapsulates the payload data from the value message for the simulated network. Rx ports process Logic Frame that are received by the interface and forward them to receiving applications based on the port properties. Every input and output port defines the following properties:

• Simulated size of the transmitted payload: This enables the transmission of high-level payload objects, e.g. Java Objects without converting them to a network-specific encoding. The simulated size is used for all transmissions and may be changed at runtime.
• Network address: The address is specific to the network and defines the network-specific handling of the frame that is generated from the data transmitted from a Tx port, or the data received by a Rx port. For CAN bus networks, the address defines the CAN ID of a frame, whether it is a basic or extended frame, and whether it is a data frame or an RTR frame. Transmit ports create transmitted logic network frames based on this information, receive ports decide whether a received CAN bus frame is to be received and therefore forwarded to an application.
• Port name: The port name identifies the port, as every application interface may define multiple ports to communicate with applications.

FERAL Raw Interface

The Raw Interface enables more control regarding the created network frames for applications. It is implemented by class RawInterface. It expects input messages of type RawMessage. It does not accept other value messages. Raw messages carry a byte array as payload that contains the payload for the created LogicFrame message. Received LogicFrame messages from the network must carry byte arrays as well to be processable by the RawInterface. Figure 3 illustrates the network simulation stack with the RawInterface class.

Figure 3: Network Simulation Stack With Raw Interface

The raw interface needs network specific information to construct the logic frame. This information must be part of the payload of the RawMessage. Therefore, the following common byte pattern is defined for all raw messages:

Figure 4: Structure For All Raw Messages

A raw frame is split into a generic part that defines common information for all raw frames, and into a protocol specific message format that depends on the type of network frame. The common message format fields are defined as following:

Position	Size	Type	Name	Description
0-3	4	int32	InterfaceID	The interface ID enables the selection of an interface. Normally, only one interface per endpoint is supported, and the interface ID is therefore 1.
4-7	4	int32	BusID	The bus ID defines the bus type and the bus specific format that is used for the frame.
8	1	int8	ChannelID	The channel ID enables the selection of a channel foe network configurations that support multiple channels.
9	1	int8	Direction	May be used to indicate the direction of a message (TX/RX).
10	1	int8	Version	Defines the version of the used message format.

Note : BusID field is removed from FCAPI v2 and this table and the following references should be adjusted accordingly

Protocol-Specific Fields

Following provides the protocol specific fields for raw transimission of a frame.

Bus ID Values in FERAL

Following are the network systems that are supported to be simulated by FERAL alongside their Bus ID.

Bus ID	Bus Type
1	CAN (without FD support)
2	FlexRay
3	Ethernet
4	CAN (with CANFD support)
5	LIN

CAN Standard (Bus ID 1)

This protocol is kept for compatibility reasons. New simulation settings should use the CAN-FD protocol, which supports both regular CAN bus simulations and CAN-FD.

Position	Size	Type	Name	Description
11	1	int8	FrameType	Indicates whether the frame is a CAN standard frame (0) or a CAN extended frame (1).
12	4	int32	CanID	This field holds the CAN bus ID of the message.
16	1	int8	DLC	Number of payload bytes of the CAN frame (0-8).
17	1	int8	RTR	Indicates whether the frame is a regular data frame (0) or a remote transmit request (RTR) frame.
18	#DLC	[int8]	Data	This field holds the amount of data bytes that were specified in the DLC field.

CAN-FD (Bus ID 4)

This protocol supports the raw frame interaction with CAN and CAN-FD networks.

Position	Size	Type	Name	Description
11	1	int8	FrameType	Indicates whether the frame is a CAN standard frame (0) or a CAN extended frame (1).
12	1	int8	FD_CAN	Indicates whether the frame is a regular CAN frame (0) or a CAN-FD frame (1).
13	1	int8	BRS	Shall the bitrate/bus frequency for payload be increased?
14	4	int32	CanID	This field holds the CAN bus ID of the message.
18	1	int8	DLC	Number of payload bytes of the CAN frame (0-8 for regular CAN frames, or 0-64 for FD frames).
19	1	int8	RTR	Indicates whether the frame is a regular data frame (0) or a remote transmit request (RTR) frame
20	#DLC	[int8]	Data	This field holds the amount of data bytes that were specified in the DLC field.

CAN-XL (Bus ID 6)

This protocol supports the raw frame interaction with CAN-XL networks.

Position	Size	Type	Name	Description
11	2	int16	PID	The priority ID of the CAN frame
13	2	int16	DLC	Data Length Code. This refers to the length of bytes of the data payload contained within the frame. For CAN XL frames, this is an 11-bit field allowing unsigned integer values of 0-2047. The actual data payload length is DLC+1, meaning that the minimum data payload length is 1 byte and the maximum is 2048 bytes
15	#DLC+1	[int8]	Data	The actual payload

Configurable CAN Network Parameters in FERAL

Arbitration Bit Rate

It refers to the speed at which data is transmitted on the CAN bus. Bit Rate in CAN is typically measured in bits per second (bps) or kilobits per second (kbps). It determines how quickly data can be transmitted between different nodes (devices) on the CAN bus. The Bit Rate directly impacts the amount of data that can be sent within a given period, influencing the overall performance and efficiency of the communication system.

To configure the desired bit rate, method setBitRate() can be utilized on the Network instance. This method allows to specify the desired bit rate for the network communication.

public class CANScenarioConfig {
    // Set arbitration bit rate - 100kBit
    network.setBitRate(100_000);
}

When calling the setBitRate() method on the Network instance in FERAL, desired bit rate need to be passed as a parameter in bits per second. The default bit rate in FERAL CAN is set at 100 kbit/s. Therefore, if the bit rate need to be changed, the new value must be specified in bits per second as an argument to the setBitRate() method.

Data Bit Rate

This specifically refers to the speed at which the actual payload data is transmitted on the CAN bus, excluding overhead bits. It represents the rate at which the raw data is transferred between nodes.

To configure the desired data bit rate, the method setDataBitRate() can be utilized on the Network instance. This method allows to specify the desired data bit rate for the network communication.

public class CANScenarioConfig {
    // - Set data bit rate - 8 MBit
    network.setDataBitRate(8000000);
}

When calling the setDataBitRate() method on the Network instance in FERAL, the desired data bit need to be passed as a parameter rate in bits per second. The default data bit rate in FERAL CAN is set at 8 Mbit/s. Therefore, if the bit rate need to be changed, the new value must be specified in bits per second as an argument to the setDataBitRate() method.

Note: If the data bit rate isn't configured, it's presumed equal to the arbitration bit rate.

Bit Stuffing Mode

"Bit Stuffing" is a mechanism to ensure proper synchronization and error detection during data transmission. Bit stuffing comes into play within the Data field of a CAN frame. The purpose of bit stuffing is to avoid long sequences of identical bits (more than five bits of the same value) within the data field, which could potentially cause synchronization issues or misinterpretation by the receiving nodes.

To configure the desired bit stuffing mode, the method setBitStuffingMode() can be utilized on the Network instance. This method allows to specify the desired bit-stuffing mode for the network communication.

public class CANScenarioConfig {
    network.setBitStuffingMode(CANNetworkParameters.BitStuffingMode.NONE);
}

When calling the setBitStuffingMode() method on the Network instance in FERAL, following three possible modes can be chosen:

1. None: In this mode, no bit stuffing is performed, so the total number of stuff bits in the CAN Message is zero.
2. Accurate: Stuff Bits for the CAN message are calculated as per the standard. After every 5 identical bits, the opposite bit is stuffed in the data to avoid long sequences of identical bits.
3. WorstCase: This case considers the worst-case scenario and calculates worst-case bit stuffing for both header and payload.

                       `No of Stuffed Bits = ((headerBits - 10) + payloadBits - 1) / 4)`
   

Note: The default mode is set to WorstCase.

Therefore, if bit stuffing mode need to be changed, one of the available modes can be specified as an argument to the setBitStuffingMode() method.

Log Transmissions

FERAL supports log transmissions to log the start and end of message transmissions. To enable or disable logging of transmissions, the method setLogTransmissions() can be utilized on the Network instance. This method allows to control whether transmission events are logged or not.

public class CANScenarioConfig {
     network.setLogTransmissions(true);
}

Note: By default, logging of transmissions is disabled.

Lost Arbitration Logging

This feature enables to logs CAN frames that lost arbitration.

To enable or disable logging of lost arbitration events, the method setLostArbitrationLogged() can be utilized on the Network's Config instance. This method allows to control whether lost arbitration events are logged or not.

public class CANScenarioConfig {
     network.getConfig().setLostArbitrationLogged(true);
}

Note: By default, this feature is disabled.

Starting Time

This feature can be used to set the starting time of the network simulation. By default, the simulation starts at 0.0.

To configure the starting time for the network simulation, the method setStartingTime() can be utilized on the Network's Config instance. This method allows to specify the desired starting time for the simulation.

public class CANScenarioConfig {
     network.getConfig().setStartingTime(SimulationTime.S(1));
}

Message Type

In a FERAL can simulation, a CAN frame type can be specified as Standard CAN, CAN FD, or CAN XL.

This can be configured by calling the addTxMessageType() or addRxMessageType() methods on the Application Interface instance.

• CAN Standard: Following is a CAN Standard frame with CAN ID 63

public class CANScenarioConfig {
    network.getTopology().getApplicationInterface(0).addTxMessageType("63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("63", "app1", 2);
}

• CAN Standard (Remote): Following is a CAN Standard (Remote) frame with CAN ID 63. To specify this type, add “r:” before the network address.

public class CANScenarioConfig {
     network.getTopology().getApplicationInterface(0).addTxMessageType("r:63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("r:63", "app1", 2);
}

• CAN Standard (Extended): Following is a CAN Standard frame with CAN ID 63. To specify this type, add “e:” before the network address.

public class CANScenarioConfig {
    network.getTopology().getApplicationInterface(0).addTxMessageType("e:63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("e:63", "app1", 2);
}

• CAN Standard (Extended and Remote): Following is a CAN Standard (Extended and Remote) with CAN ID 63. To specify this type, add “re:” before the network address.

public class CANScenarioConfig {
    network.getTopology().getApplicationInterface(0).addTxMessageType("re:63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("re:63", "app1", 2);
}

• CAN FD: Following is a CAN FD frame with CAN ID 63. To specify this type, add “fd:” before the network address.

public class CANScenarioConfig {
    network.getTopology().getApplicationInterface(0).addTxMessageType("fd:63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("fd:63", "app1", 2);
}

• CAN FD (Extended): Following is a CAN FD (Extended) frame with CAN ID 63. To specify this type, add “fde:” before the network address.

public class CANScenarioConfig {
    network.getTopology().getApplicationInterface(0).addTxMessageType("fde:63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("fde:63", "app1", 2);
}

• CAN XL: Following is a CAN XL frame with CAN ID 63. To specify this type, add “xl:” before the network address.

public class CANScenarioConfig {
    network.getTopology().getApplicationInterface(0).addTxMessageType("xl:63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("xl:63", "app1", 2);
}

Duplicate Frame Dropping

public class CANDuplicateFrameDroppingScenario {

    // Create Scenario
    Scenario testScenario = new SimulationScenario();

    Director director = new DiscreteEventMOCC(testScenario);

    // - Create CAN senders
    canSender1 = new SenderEventWorker(director, -1L, SimulationDuration.MS(10).getRawTimeNS());
    canSender2 = new SenderEventWorker(director, -1L, SimulationDuration.MS(10).getRawTimeNS());
    canSender3 = new SenderEventWorker(director, -1L, SimulationDuration.MS(10).getRawTimeNS());
    canSender4 = new SenderEventWorker(director, -1L, SimulationDuration.MS(10).getRawTimeNS());

    // - Create a CAN receiver
    ReceiverEventWorker canReceiver = new ReceiverEventWorker(director, expectedEventSequence);

    // Create CAN Network with 2 nodes, senders connected to the same can interface
    network = new DefaultCANNetwork(director, 2);
    // - Setup network speed - 100kBit
    network.setBitRate(100_000);
    network.setBitStuffingMode(CANNetworkParameters.BitStuffingMode.NONE);
    // - Setup communication interfaces, workers communicate via message type "63", payload size of two bytes
    network.getTopology().getApplicationInterface(0).addTxMessageType("63", "app1", 1);
    network.getTopology().getApplicationInterface(1).addRxMessageType("63", "app1", 1);

    // - Setup links from/to network
    new Link(canSender1.getOutputPort("comm"), network.getTopology().getApplicationInterface(0).getInputPort("app1"));
    new Link(canSender2.getOutputPort("comm"), network.getTopology().getApplicationInterface(0).getInputPort("app1"));
    new Link(canSender3.getOutputPort("comm"), network.getTopology().getApplicationInterface(0).getInputPort("app1"));
    new Link(canSender4.getOutputPort("comm"), network.getTopology().getApplicationInterface(0).getInputPort("app1"));

    new Link(network.getTopology().getApplicationInterface(1).getOutputPort("app1"), canReceiver.getInputPort("comm"));

}

In this instance, the concept of dropping duplicate frames within the previously described simulation setup has been explained. The setup involves four sender applications and a single receiver, transmitting data through a CAN network equipped with two application interfaces. All the sender applications are linked to Application Interface 0, while the receiver is connected to Interface 1.

• Case 1: Dropping the duplicate frames

public class CANScenarioConfig {
    canSender1.setMessagePayload(0L);
    canSender2.setMessagePayload(1L);
    canSender3.setMessagePayload(2L);
    canSender4.setMessagePayload(3L);

    // - Configuration to DISABLE the drop of duplicated frames (duplicated = same network address)
    network.getTopology().getNetworkDevice(0).getQueue()).setDuplicatedFramesShallBeDropped(true);

    // Expected reference behavior
    // CAN Sender 4 will overwrite frames of all other CAN senders, therefore we expect:
    expectedEventSequence.setExpectedEventSequence(List.of(
    10520000L, 3L,
    20520000L, 4L,
    30520000L, 5L,
    40520000L, 6L,
    50520000L, 7L
    ));
}

Here the duplicate frames refer to instances where different data values are sent with the same network address. In the described example, all four senders transmit distinct data over the same interface. If duplicate frames are dropped, only the data sent by sender number 4 will be received by the receiver. Consequently, the expected event sequence will only consist of the incremented data payload sent by sender number 4.

• Case 2: Duplicate Frames are not dropped

public class CANScenarioConfig {
    canSender1.setMessagePayload(1L);
    canSender2.setMessagePayload(2L);
    canSender3.setMessagePayload(3L);
    canSender4.setMessagePayload(4L);

    // - Configuration to DISABLE the drop of duplicated frames (duplicated = same network address)
    network.getTopology().getNetworkDevice(0).getQueue()).setDuplicatedFramesShallBeDropped(false);

    // Expected reference behavior
    // Can Sender 1 message be received before Sender 2 since it is added beforehand to the domain, so as for the
    // rest of the incoming messages

    expectedEventSequence.setExpectedEventSequence(List.of(
    10520000L, 1L,
    11070000L, 2L,
    11620000L, 3L,
    12170000L, 4L,

    20520000L, 2L,
    21070000L, 3L,
    21620000L, 4L,
    22170000L, 5L,

    30520000L, 3L,
    31070000L, 4L,
    31620000L, 5L,
    32170000L, 6L,

    40520000L, 4L,
    41070000L, 5L,
    41620000L, 6L,
    42170000L, 7L,

    50520000L, 5L,
    51070000L, 6L,
    51620000L, 7L,
    52170000L, 8L,
    ));
}

In this scenario, the CAN network is configured to permit duplicate frames. Consequently, the expected events include data payloads from all four senders, as each sender is allowed to transmit its unique data payload despite sharing the same network address.