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)
- I should point out that a decentralized system will generally be less stable than a well-maintained centralized one, given the haphazard nature of inter-region communications using chat relays. HTTP communications are not possible without an off-grid server (barring a cheap workaround by exchanging URLs through chat, but this defeats the purpose). A system like this would only be much use in yards and other complex interlocks, which most of SLRR isn't. Ultimately the system is rendered useless by two inherent flaws with SLRR:
- Most of the system is a single-track mainline with very few sidings, most of which are incapable of handling more than one or two cars. Handling traffic in both directions would be difficult enough with a centralized system; without one it is nearly impossible.
- There isn't a system already in place. SLRR rolling stock generally either uses the script from the VRC freebie engine or an in-house system that will probably never be updated as the creator stopped playing many moons ago. If a system like this were to be implemented it would require compliance by all users and compatibility with all rolling stock to operate safely and effectively - as this is SL, this is not possible. Detecting incompatible cars and compensating for them is also prohibitively difficult, especially in a decentralized system.
- I would gladly help coordinate a command-and-control system for SLRR but unfortunately it is nearly impossible without a complete overhaul of the network and prohibition of current vehicles without compatibility fixes. Ultimately, it would basically necessitate an entirely new system, and would probably be best as a commercial, privatized one to ensure standards enforcement. The current state of SLRR is much like the Linux situation - there are many different versions which run off of the same specifications, but updating those specifications would be extremely difficult and would take many years to reach significant acceptance.
- Nelson Jenkins 17:22, 28 October 2012 (PDT)
Is there still some maintenance done on the SLRR tracks? i noticed several issues on the public, semi public and private sections, namely phantom center rails, center rails that are too low to provide proper physical contact, and center rails that are turned backward. I've started working on physical locomotives and i have to say that a lot of the sim crossing areas are problematic (track switches or sharp turns/grade changes right before/after a crossing usually derail physical trains)
One way to deal with red signals would be to accompany them ( and this should be in switches set against you too ) with a block signal, such as the line end signal. if you can't pass, end of line signal appears basically.
Kyrah Abattoir 17:01, 8 April 2014 (PDT)