FBSS Signalling

Overview

The Fixed Block Signalling System (FBSS) is the core signalling framework in Railux 6 Ultra. It divides the railway into discrete blocks, each monitored by a signal. Trains are only permitted to enter a block if it is clear, ensuring safety and efficient traffic flow. All signals and logic are centrally managed for reliability and scalability.

---

How FBSS Works

• Track is split into blocks: Each block is protected by a signal.

• Signal aspects (Red, Yellow, Green, etc.): Indicate the status of the block ahead to train drivers and automated systems.

• Multi-directional & multi-block linking: Each signal can reference its next and one or more previous blocks, supporting complex track layouts such as junctions or merges.

• Centralised control: All logic and state updates are handled by a main script (FBSS_Main) for consistency across the network.

---

Folder Structure (Typical)

RailuxFBSS_Signalling/
│
├── A202/
│   └── API/
│       ├── AlwaysYellow
│       ├── CurrentSignal
│       ├── DebounceDuration
│       ├── NextBlock
│       ├── PreviousBlock
│       ├── PreviousBlock (additional for multi-block support)
│
├── Lights/
├── Sensors/
└── FBSS_Main

---

API Reference (Per Signal/Block)

Each block or signal has an API folder containing the following objects:

Name	Type	Description
AlwaysYellow	BoolValue	If true, this signal always shows yellow (used for cautionary or approach signals).
CurrentSignal	StringValue	The current aspect (e.g., Red, Yellow, Green). Used by scripts and signal lights.
DebounceDuration	Number	The minimum time (seconds) before this signal can change again (prevents rapid toggling).
NextBlock	Object	Reference to the next block (the block this signal protects).
PreviousBlock(s)	Object(s)	Reference(s) to one or more previous blocks feeding into this block (for junctions, merges).

Note:

• Multiple PreviousBlock objects are permitted for complex track layouts.

• Scripts should iterate through all PreviousBlock entries to determine occupancy or status for this signal.

---

Example: Multi-Previous Block Support

For a signal at a junction where two tracks merge, you might have:

API/
├── AlwaysYellow
├── CurrentSignal
├── DebounceDuration
├── NextBlock
├── PreviousBlock (for Track 1)
├── PreviousBlock (for Track 2)

Scripts should check both PreviousBlock references to determine if either incoming track is occupied before clearing the signal.

---

Signal Aspects (Typical Values)

Signal Name	Value	Meaning
Red	Red	Stop
Yellow	Yellow	Caution
Green	Green	Proceed

---

Typical Usage

• Place a folder for each signal/block under RailuxFBSS_Signalling (e.g., A202, A203).

• Configure each signal’s API folder as above.

• The main script (FBSS_Main) will read and update each signal’s state based on block occupancy and the state of neighbouring blocks.

---

Example API Setup for a Block

A202/
└── API/
    ├── AlwaysYellow       -- BoolValue
    ├── CurrentSignal      -- IntValue
    ├── DebounceDuration   -- NumberValue
    ├── NextBlock          -- ObjectValue (points to next block)
    ├── PreviousBlock      -- ObjectValue (points to previous block 1)
    ├── PreviousBlock      -- ObjectValue (points to previous block 2, if junction)

---

Scripting Notes

• Iterate over all PreviousBlock values when determining if a block is clear, especially at junctions or merges.

• DebounceDuration should be tuned to prevent rapid aspect changes in busy areas.

• AlwaysYellow can be used for approach or distant signals as required by route design.

---

Best Practices

• Use unique names for each block/signal folder (e.g., A202, A203).

• Clearly link NextBlock and all relevant PreviousBlock references for every signal.

• Test complex junctions to ensure all possible routes are correctly protected.