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)

...and what if an actual human wants to use the line rather than "controlled" rolling stock? And, why is a VRC meeting being used to dictate such things, the so-called "Community meeting". I do not recall an announcement on the Second Life blog, forums or anywhere else for a community meeting. The community is more than the VRC, which remains a private group. The SLRR is a resource for all residents, not a private group. I see this arrogant disregard for residents outside of the VCR continues, which doesn't surprise me.Yevad Doobie 22:21, 12 June 2011 (PDT)

If an actual human wants to disregard the information that is provided to allow a pleasant and realistic journey, than that human can just do so. I would like to stress once more, that the "control" that we talk about here is not control of the train operator. What is discussed is the control of signals and other information sources. The VRC works to design a standardized and open information exchange system, that can be used by a human operator or by automated trains, but can just as well be ignored if the human operator wishes to do so.

The VRC is an open organisation that in no way claims rights over the SLRR nor prescribes or dictates anything to anybody. If you like to join you are welcome, if you don't want to be involved that is fine to. We will not restrict anybody in using the SLRR in the way they want but, we expect that same attitude from others. If you don't like to discuss ways to design a block control system, please don't do it, but stop cluttering the page with claims of restrictions of your rights that have no basis.

Vaughn Deluca 05:11, 17 December 2011 (PST)

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 destination
// string     MSG_DEST_REGIONNAME   =    3; index of destination region
// integer    MSG_DEST_STRUC_LOC    =    4; index of destination structure location
// integer    MSG_DEST_STRUCTURE    =    5; index of destination structure class
// integer    MSG_DEST_ELEMENT      =    6; index of sub-structure class
// integer    MSG_SENDER            =    7; index of global sender
// string     MSG_SENDER_REGIONNAME =    8; index of sender region
// integer    MSG_SENDER_STRUC_LOC  =    9; index of sender location
// integer    MSG_SENDER_STRUCTURE  =   10; index of sender structure class
// 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
// float      MSG_CONTENT_FLOAT     =   14; index of payload float
// string     MSG_CONTENT_STRING    =   15; index of payload string
// string     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.

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