Talk:Second Life Railroad/SLRR standards

If you feel that the information about the SLRR standards are not correct or the text needs correction then please feel free to start a discussion on this page

---

control system discussion

Original text: Control is the way the rail network as a whole works safely while sharing the rail resources among consists.
Currently (10-2009) there is no such system in place.

Problem description

If rolling stock of multiple operators is allowed on a track, traffic control will be necessary. The block section type of control system should work, using llSay on a negative channel, phantom alpha detectors on the track, and signals for realism.

A larger problem is what to do about traffic in the opposite direction. Block Section control could work with a passing siding for each section. Which leads to...

Another problem - switches. If the Guide rail is used, then it could be turned and moved to divert a train, or line and branch Guides could be alternated between phantom and nonphysical as determined by routing. If a flat or phantom guide rail is used, names can be switched to change which rail is active.

--Stryker J 14:53, 28 December 2009 (UTC)

SCADAD controll system

The Virtual Railway Consortium (VRC) is developing an open specification for a generalised control system (SCADAD, Supervisory Control, Data Acquisition & Distribution) for public transport in SL-like virtual worlds. Here an overview of the SCADAD protocol is presented. All comments and suggestions for improvement are welcome. Interested scripters are invited to contact Moundsa Mayo or Vaughn Deluca.

Currently two implementations are deployed inworld. Along the GSLR a (slightly older) version of the systems communication backbone is running over 7 sims, but no equipment is connected as yet. In the Huckelberry yard, communication between several switches and status maps are tested and the main development is taking place there. A new implementation is planned in Tuliptree.

--General design considerations and requirements

(1) The system must operate fully in-world, i.e. independent off external servers for communication.
(2) The system must be as much as possible distributed, i.e. the objects in the system should be able to function independent and autonomous (possibly at a reduced level of functionality). If one entity fails, the remaining entities use sensible defaults to keep up a reasonable level of functionality. This results in graceful degradation of the system when communication starts to fail.
(3)The system must be modular and as much as possible self-configuring to allow easy extension with new objects, and provide both efficient and user friendly operation.

-- System overview

At the highest level the system can be viewed as a set of objects that exchange protocol messages. Examples are switches, stations, control towers and message relays. The protocol makes no assumptions about the inner workings of the object. Any object that follows the protocol will be able to communicate. This will allow railway line operators that have developed their own communication systems to use the VRC protocol in addition to their own system and interface it with their local protocols and existing builds simply by dropping some scripts in the object.

The structure of the system is a "vertical" chain of command in which each object knows about nodes lower in the system, and knows the address of one parent object to which messages are forwarded that the object can not handle itself. The chain branches out at the bottom to structures like switches and automated rolling stock, and finally to elements of structures like signals and train detectors. In addition there are "horizontal" connections to allow inter-region communication.

Request messages can be injected at each level. Routing of messages to neighboring regions is done by region controllers that (currently) communicate to pairs of repeaters whispering over region boundaries, but HTTP connections are equally possible. The region controller uses a local routing table to determine in what direction a message that is not addressed to its own region should be forwarded.

These two main "dimensions" in the network (vertical within region, and horizontal between regions) are intersecting at the the region controllers (one per region) that function as routers for messages for objects not present in the region. In each region the region controller talks to one or more downstream control towers, typically managed by parcel owners. The lower parts of the system (switches, stations etc) are also owned and operated by the parcel owner. The region controllers together build a communication "backbone", a shared public network operated by the members of the VRC or equivalent organisation, at a best effort basis. Traveling rolling stock may contact the region controller to request information about the local infrastructure (switches, stations, etc., and in most cases will receive the address of a local tower for further communication.

The chosen design of addressable objects has the advantages that it can be fully in-world (requirement 1), that there is no central point of control, so the system will degrade gracefully (requirement 2) and individual units can be relatively easy added or changed (requirement 3). The drawback is more complexity of the system as a whole, compared to a system where each entity communicates directly with a central hub like an out-of-world server. The biggest advantage is however that the system fits well to the relative fluid nature of SL were parcel owners come and go. The general approach can be compared to the internet, that is not "owned" by anybody and allows every interested party to connect and exchange information using a standard protocol.

-- Message template

All messages that are passed to the different objects in the network have the same format: a set of 16 main fields that together define the message. All 16 fields are always present in each message. The fields can be individually read from the message using an index into the message. The destination region of the message is for instance stored in the string at position 3.

// =====================================================================            
// VRC SCADAD message template v4                                      
// =====================================================================                                                         
// Message template fields
//
// integer    MSG_INFO              =    0; index of message info
// integer    MSG_SEQUENCE          =    1; index of sequence number
// integer    MSG_DEST              =    2; index of global part destination
// integer    MSG_DEST_REGIONNAME   =    3; index of destination region
// integer    MSG_DEST_STRUCTURE    =    4; index of destination structure class
// integer    MSG_DEST_STRUC_LOC    =    5; index of destination structure location
// integer    MSG_DEST_ELEMENT      =    6; index of sub-structure class
// integer    MSG_SENDER            =    7; index of global part sender
// integer    MSG_SENDER_REGIONNAME =    8; index of sender region
// integer    MSG_SENDER_STRUCTURE  =    9; index of sender structure class
// integer    MSG_SENDER_STRUC_LOC  =    10; index of sender location
// integer    MSG_SENDER_ELEMENT    =    11; index of sender sub-structure class
// integer    MSG_COMMAND           =    12; index of command word
// integer    MSG_CONTENT_INT       =    13; index of payload integer
// integer    MSG_CONTENT_FLOAT     =    14; index of payload float
// integer    MSG_CONTENT_STRING    =    15; index of payload string
//integer     MSG_CONTENT_KEY       =    16; index of payload key

Most of the 16 main fields in the template are divided into subfields to make more efficient use of space. The message destination field (MSG_DEST) at position 2 for instance has subfields for "world", "organisation" and "service" constants.

-- Address logic

Communicating objects need a way to address each other. In the SCADAD system each node can send out requests and respond to requests. The destination and origin of a message are specified by building the unique address of the destination from information in the message. See examplem below: words in capitals are predefined constants, CONN_BRANCH indicates for instance the branch side from a Y switch.

Field                    Content                        Example values
----------------------------------------------------------------------
MSG_DEST		World, Organisation, Service    SL, VRC, VRC_TEST
MSG_DEST_REGIONNAME	RegionName                      Huckleberry
MSG_DEST_STRUCTURE	ObjectType                      STRUC_SWITCH
MSG_DEST_STRUC_LOC	x, y, z                         132,6,85
MSG_DEST_ELEMENT	Element, ElementID              ELEM_SIGNAL, CONN_BRANCH						

The full and unique name of this object (one of the signals of a switch) could be: SL.VRC.VRC_TEST.Huckleberry.Switch.132,6,85.Signal.Branch. In most cases the first 3 fields of the address (world, organisation, service) will be implied (i.e. used as default), and the last two will be only used by the switch itself. Therefore, to communicate with the switch described above the partial address Huckleberry.Switch.132,6,85 will be all that is needed for local communiciation.

Note that to control a switch, a request will be send containing the new position. The switch will acknowlege by sending its new position. The switch will take care of adjusting its own element, like signals lights in a consistent manner. Objects automatically determine their own address (Using configuration info from the description field or from a configuration notecard). Each object has a parent object, for forwarding messages that can't be handled by the object itself.

Update December 21, 2011:
Here is an example how the system can be used: In a rail yard, the signal hut (or control tower) can contain a map with all signals in the yard. When a switches is flipped by running trains, the switch sends a status message message to its parent structure (the tower), and the tower forwards this to the map(s) it controls that displays the new status. A human user can touch buttons or pull levers in the tower, and those objects will send messages to the switch they are associated with. The switch responds by changing position and sending a message back to the tower with the new state of the switch. The above described functionality is currently up and running in Huckleberry, but the scripts still need a lot of work. All volunteers are welcome.

Vaughn Deluca 12:35, 19 December 2011 (PST)