OpenLCB Overview


OpenLCB defines a family of interoperating protocols for controlling model railroads. It is structured around some common concepts and separate implementations.

The OpenLCB will be capable of supporting Accessory Control, Advanced Locomotive Control and even Multimedia and Rich Text features on the higher bandwidth networks. This protocol proposal will focus on OpenLCB Accessory Control with emphasis on CAN 2.0B but allowance has to be made for simple Locomotive Control and implementation of the OpenLCB protocol on other network technologies like Ethernet, Internet and others.

This proposal is based on a series of use cases that extend from a beginning modeller connecting up two boards to a huge modular layout put together by several clubs. To achieve this range, and to allow for future technologies, OpenLCB is defined so that it can communicate over CAN segments, within computers, and on network links.

Key Features of This OpenLCB Protocol Proposal

The key features of this proposal are:

CAN Implementation

Design Considerations

Networking technologies come and go and new ones become dominant. Due consideration needs to be given to the possibility that the current popular networking technologies of CAN and Ethernet may be eclipsed in the future by emerging technologies like Wireless 802.15.4, FlexRay and others. The OpenLCB protocol design should ensure that OpenLCB will perform adequately on common CAN and Ethernet (including WiFi) networking technologies, but not at the expense of limiting its adaptation to other networking technologies, including ones not considered now.

A critical design consideration is to allow for the addition of newer technologies without having to discard the older technologies. OpenLCB must be able to seamlessly add new network segments without having to reconfigure the whole OpenLCB to accommodate the change. Node numbers, event IDs and similar things must be portable across the network so that topology changes are accommodated without requiring major reconfiguration.

A significant design consideration for the OpenLCB has to be ease of use for non-technical users and provision of Plug-N-Play type features including automatic discovery and user friendly configuration tools to assist with OpenLCB setup and configuration. Also OpenLCB needs to support gathering of network performance statistics to assist with performance tuning, identifying the cause(s) of faults and performance problems.

The OpenLCB must be able to start small and grow over time as layouts evolve.

OpenLCB Network Topology

OpenLCB is built on top of a reliable transport. This can be either point-to-point, or multipoint. “Reliable” transport delivers all messages between two nodes, without changes, deletions, duplications, additions or re-orderings. No assumptions are made about the order of communications between different nodes or node pairs. (The OpenLCB CAN format has been designed to allow for CAN network behavior, where low priority messages may be delivered behind higher priority messages)

A layout with a OpenLCB will require at least one OpenLCB network segment. This could be CAN, Wireless, Ethernet or WiFi, but is likely a combination of several technologies. A layout may have a lengthy CAN based OpenLCB segment with many nodes running around the entire layout and have a comparatively short Ethernet segment or backbone segment that provides a convenient connection to a single PC. It is likely that entry level OpenLCB compatible DCC Command Stations will just have a CAN OpenLCB interface and a USB PC interface. Medium level DCC Command Stations might add Ethernet and Wireless interfaces whereas top end DCC Command Stations may also add WiFi. It is also likely that manufacturers will provide various interface devices to bridge between each of the OpenLCB segment types like CAN to Ethernet, CAN to USB (for PC access), CAN to Wireless and Ethernet to Wireless (for wireless throttles). Bridges to WiFi are likely to be using consumer grade Ethernet to WiFi Access Points but some markets may opt for a WiFi interface in the DCC Command Station.

Each segment of a OpenLCB is by default transparently connected to all other segments. A single CAN cable would be a OpenLCB segment, as would two CAN cables connected by a repeater. An Ethernet link would also be a segment, as would TCP/IP network connections.

Two or more segments can be connected by bridge devices. Simple bridge devices do not filter any messages: all messages are forwarded to all other segments. More intelligent interconnection devices can reduce required bandwidth by filtering messsages that are not needed on the far side of the bridge; these are called gateways.

As an example, a CAN segment with a number of nodes can be connected via a CAN-USB or CAN-Ethernet bridge to a PC running several seprate control programs.

As another example, a CAN segment in a series of modules can be connected via a bridge to an Ethernet backbone, which in turn connects via several other bridges to separate CAN segments in other collections of modules. Several PCs can be connected via the Ethernet and interact with all the modules via the individual CAN segments.

Site hosted by

This is SVN $Revision: 1516 $