CAN Wire Protocol

CAN bus (ISO 11898-*) provides a very convenient transport medium for OpenLCB on a specific module or layout. This section defines a specific wire protocol for transporting OpenLCB™ over CAN bus.

Common OpenLCB messages need to be translated for transport via CAN 2.0B frames because of the limited CAN frame sizes and to take advantage of CAN interface features such as filtering on the header bits.

The adaptations include

• A 1-bit priority field has been added to provide a coarse high/low message priority

• NID values are translated to 12 bit forms. Those forms are dynamically allocated so as to remain unique.

• Remapping of MTI values to make limited filtering possible.

Note that these adaptions must be possible in standard CAN components, e.g. bridges and computer adapters must not require customization to operate with OpenLCB. This provides a stringent requirement on protocol design, in that OpenLCB CAN cannot require specific timing, deliberate creation of error cases or specific error handling.

Physical Layer

The physical layer of OpenLCB-CAN is 125kbps CAN over twisted pair wiring. The NMRA is attempting to define a common physical layer for use across multiple implementations, and that may in turn define the physical layer of OpenLCB-CAN.

For more information, see the separate Common CAN Platform document.

Link Layer

OpenLCB common messages are converted, to the extent possible, to single CAN frames via a one-to-one mapping.

The translations include:

• The NID Source ID (SID) is mapped to a shorter form, called a "NID Alias" (NIDa). The method for this mapping is defined such that devices on the CAN segment (e.g. gateways to other parts of the larger OpenLCB installation) can determine the full NID that corresponds to a particular alias.

  Because this alias is still unique on the specific CAN segment, it is used in the CAN header for arbitration.

• MTIs may have to be shortened, depending on bit allocations.

• When possible, Destination NIDs are also mapped to the shorter form. In some OpenLCB messages, this is not possible, in which case the full NID form is sent; a bit is provided to indicate which format is carried.

Design decisions:

• The CAN format has been allocated on nibble boundaries to make it easier to e.g. read dumps of packets. The header is considered to be right (LSB) aligned.

• A specific mapping from the common 16-bit MTI format to a shorter CAN format is documented in a separate worksheet (PDF version). The common form is 16 bits to have lots of space to grow at the high end, but it can be mapped into a 8 bit field for efficient CAN transfer.

• Nodes must handle full rate messages, specifically including messages not addressed to them. (The datagram and stream protocols provide ways for nodes to indicate whether or not they have sufficient buffering for the next transmission, triggering retries as needed) For long term reliability, a node must be able to completely process an entire CAN frame in the time it takes to receive the next one, which may be as little as 64 bit times, or about 500 microseconds.

• A 1-bit field priority field coarsely specifies the priority of the message in terms of CAN arbitration to be high (pri=0) or low (pri=1). By default, all messages are to be emitted with low priority selected. Receiving nodes must not check this bit.

  This field is intended for network infrastructure and server type nodes (Command Stations) that may from time to time experience high traffic loads and need the ability to pre-empt other nodes to forward messages from a busy segment or preempt the sending of responses to nodes over receiving new requests to prevent message buffer overflow. This field is separate from the static priority field in the MTI format specification.

• Designers may wish to use CAN hardware filtering, but it can't be assumed to be present. We assign a single bit to indicate “simple node protocol” messages to make simple filtering possible.

Header content and sizes (Nominal decisions shown, 29 bit header):

• Priority bit (Always sent as 1 now; at front to ensure it acts like a true priority; 0 for high priority, 1 for low; not checked by receivers)

• Frame Type (1 bit) OpenLCB message or CAN control message

• Variable Field (15 bits)

• Source NID alias (12 bits)

The order of these fields is chosen to get proper priority and access disambiguation via CAN's standard mechanisms.

The "Variable field" has different meanings depending on the "Frame Type" field. CAN control messages are identified with a Frame Type bit of 0, to ensure high priority.

Document no-seven-1-bits-in-top-11 limitation to ensure future selections don't violate it.

Throughput and Temporarily Deaf Nodes

OpenLCB requires that CAN-attached nodes be able to handle the full frame rate on the CAN bus. There is no guarantee that frames for a given node will arrive with non-zero time between then.

Some nodes are not always able to process frames. For example, the node may cease processing for a short time while writing non-volatile memory. Higher-level protocols, e.g. configuration write datagrams, have mechanisms built in to prevent overrun while writing configuration memory, but there could be multiple activities going on in parallel that will result in frames arriving while the node is not processing.

Short outages can be covered by CAN hardware buffering, so long as the node will eventually catch up even at full arrival rate. Outages long enough that frames are lost due to e.g. buffer overflow require node to broadcast that it's back up if hardware detected frame lost. This is because tehre could have been frames of some form that modified the OpenLCB node state, which are now lost (e.g. drop alias, CIM/RIM in absence, or even higher level events)

CAN-specific Control Messages and Interactions

These are identified by the Frame Type bit being 0. They are formatted as shown in the following table:

CANid assignment

The common message format uses full 48-bit node ID numbers to identify originating nodes and in some case destination nodes. CAN frames use 12-bit local "NID alias" for these to save space in the limited-size CAN payload.

The standard Verify Node ID Number interaction can be used to get the full 48-bit NID from a node for translation. At power up each node must obtain a alias that is locally unique. Gateways will also have to obtain unique aliases for remote nodes they are proxying on to the segment.

Proposed algorithm, in rough form:

• Compute a CANid from the NID using a standard algorithm.

• Send CAN frames claiming that CANid and carrying sequential parts of NID in the Variable Field section of the header.

• If error, step the algorithm in a standard way and repeat until success.

• Send a CAN frame announcing that the node has claimed an ID value.

Note that there is no requirement that this alias be consistent from one run to the next. More detail is on a separate page.

CAN-specific messages

Most CAN frames are one-to-one or many-to-one equivalents of common OpenLCB messages.

A few additional messages are used for CAN-specific purposes.

CIM

Check ID Message - used as part of the ID allocation.

RIM

Reserved ID Message - used as part of the ID allocation.

MR

Mapping Reset - indicates that the local alias in the source address field may no longer be associated with the same NID, and mapping tables should be reset.

Translation

A node must be able to convert traffic on the local CAN segment into the common message format using only locally available information. This may be needed e.g. by a gateway or monitoring program attached to the CAN segment.

All traffic on a CAN segment uses aliases for both Source ID (always) and Destination ID (when the full NID isn't known).

If/when a full NID is needed, it can be obtained by sending a "Verify Node ID Number (Addressed)" message with an appropriate Destination Node ID in local alias form. The reply will eventually come back with the Source ID in local alias form and carrying the full NID in the message content.

Aliases for nodes on the local segment are only valid until an "Initialization Complete" is seen from that alias. Initialization Complete indicates that a node has restarted, and may have another local alias.

Gateways maintain the mapping between remote node's NID and local alias. If they need to break that mapping, e.g. because they need to reuse the local alias due to resource limitations in the mapping tables, they must send a "Mapping Reset" message to force nodes to drop their alias information. "Mapping Reset" is a CAN-specific message limited to the segment, but all gateways on the segment must act on it.

Gateways may not be able ensure permanent validity for alias to remote NIDs. For example, if they have a limited routing table, they may need to reuse local alias. Before reusing them, they have to send a "Mapping Reset" frame to drop references to the old NID, followed by a "Initialization Complete" when the alias is allocated to a new NID.

Map Acquisition

In order to acquire the map between CANids and NIDs, a gateway needs to be able to send a CAN frame requiring "everybody reply with your NID". Much like Ethernet gateway mapping, this needs to return the NID of just the specific CAN-attached hardware, not all the NIDs that can be e.g. reached through a gateway, so it needs to be a segment-specific message defined only at the CAN level. It must not be a OpenLCB common message.

OpenLCB message format

OpenLCB common messages are carried in frames with a 1 in the Frame Type field. They contain message type information and/or address information in the 15-bit variable field, and zero to eight CAN data bytes.

For OpenLCB messages, the variable field is used in three forms:

• Unaddressed messages – messages that don't have a destination address put the low 12 bits of the MTI in the variable field

• Addressed messages – messages that have a specific destination address put it in the variable field, and carry the MTI in the payload. This allows filtering.

• Stream addressed messages – as a special case to improve efficiency of transfer, the streaming protocol uses 12 bits of the variable field to identify a particular stream transfer. This is not the same as a destination NodeID alias, but performs a similar function to allow filtering while also allowing multiple streams from a source.

The variable field is allocated:

Putting the destination alias in the header allows filtering on it with common CAN hardware. Putting the Stream ID in the header also allows filtering, and preserves the full 8-byte CAN payload for stream data.

The specific MTI values are being allocated in a separate worksheet (PDF version). In general, the MTI selection is done on the top 8 bits of the variable field. This is mapped to the low MTI byte in a standard format message.

Some MTIs have additional status bits defined as part of the 2^nd field. For example, there are two status bits associated with “Consumer Identified” which must be kept in the header since there is no room in the CAN data field. To simplify translation between formats, these are the low bits of the first byte after the MTI in a standard-form message.

Note that messages with Destinations IDs may occur in two forms: with an alias in the header and the MTI in the message; and with a full address in the data field and the MTI in the header.

CAN Controller Filters

This coding has been generated such that simple nodes can use three hardware filters to select only frames that are of interest to them.

Note that whether or not filters are used, nodes must be able to handle all combinations of sucessive frames that the full CAN rate. There is no guarantee that a node will have time for processing between frames that it must handle.

Site hosted by

This is SVN $Revision: 1473 $