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.
The key features of this proposal are:
The basic communicating unit is called a "Node". A node might be a single board, or a single program in a PC, or any other addressable item. A node may control any number of actual devices on a layout. Nodes exchange messages to control the layout.
Every node has a "Node ID number" (NID). The assignment of the NIDs assures they are globally unique.
For controlling the layout, OpenLCB defines how to transport several basic types of data between nodes:
Events - Fixed length identifiers that can propagate from multiple source nodes to multiple destination nodes. These are typically used to announce that something of interest has happened on the layouts so that controlled devices can respond.
Datagrams – Move up to 70 bytes efficiently from a source node to a specific target node.
Streams - An efficient way to move a large, variable number of bytes from one node to another.
There is also provision for interconnection of independent OpenLCB segments and filtering of messages to reduce traffic.
To do this, OpenLCB defines a global set of common message types and their content. OpenLCB specifies how the common message types are to be used for standard interactions and optional interactions. All OpenLCB nodes must be able to properly take part in standard interactions that are originated from outside the node.
The format of the common messages is separately specified for each of several wire protocols. The initial wire protocols are CAN and TCP/IP point-to-point; additional ones such as radio links are envisaged. OpenLCB wire protocols may define additional interactions and messages for specific transport-level uses on a particular type of connection, e.g. for housekeeping on the local connection. These interactions and messages are divided into standard forms, which all nodes must implement, and optional forms.
The OpenLCB as a whole consists of one or more OpenLCB segments interconnected with bridge devices that ensure all nodes are able to communicate equally with all other nodes on the OpenLCB. All OpenLCB nodes see all OpenLCB messages relevant to them.
There is no hierarchy of nodes or node aggregation or tree structures or segmentation that necessarily filters OpenLCB traffic. The OpenLCB is a flat structure where all nodes are equally accessible and addressable. At the same time, there is provision for gateways to acquire routing and filtering information so that messages can be efficiently delivered.
All OpenLCB nodes identify the messages they send with their unique Node ID number. Any OpenLCB message can be traced back to the originator using the Source Node ID.
An OpenLCB Node ID is unique, but too large to carry in a CAN header. Therefore OpenLCB dynamically creates a segment-unique "Node ID alias", which then provides the necessary uniqueness to the CAN Arbitration Header to ensure reliable collision avoidance. No other form of e.g. priority bits is required to assist with arbitration of messages to avoid possibly ambiguous or non-unique CAN Header bit patterns.
Where a point to point or directed OpenLCB message needs to be sent to a specific node the Destination ID field is placed in the CAN Data portion of the CAN Frame in the shorter "alias" form.
No central Network Manager is required, either globally or on a segment. Global network monitoring and diagnostics can be provided if desired.
CAN masks/filters can still be applied to identify frames directed to a node, along with the relevant globally-addressed messages.
Event data is placed in the CAN Data portion of the CAN Frame.
Stream data can transfer up to 8 bytes of data per CAN Frame and a single node can source as many streams as desired, but there can only be one stream on CAN at a time between a specific source and destination node.
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 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 $