How would a Conductor 2 differ from the current version?

Requirements

• Simulator.
• Validation via tests.
• Visual feedback from internal tests, both real and simulated.

State:

• Define JMRI turnouts.
• Define JMRI block sensors.
• Define map graph.
• Define virtual blocks.
• Define routes.

A map graph describes how the blocks are connected, and which turnouts influence the graph. Virtual blocks are used when there's no corresponding sensor. It's a “dark” area where we have no information, except the trains have to logically be there.

Routes are described as going from block A to block B. It should be possible for the software to automatically compute the itinerary based on the map graph. This could be fixed (in the description), dynamic once, or dynamic at each reservation.

Contrary to what is done by JMRI and RocRail, no other information is attached to the blocks or routes, especially speed limitations.

Automation involves a sequence of routes, typically 2 for a back and forth travel, with some extra attributes. For automation, we want fixed routes. Moreover, automated routes need customization for specific engines and direction on a given block, namely speed changes, horn, bell, and lights.

Another approach is to place the engine customization separate from the automation route. One issue is that customization depends on the direction of the engine in the traveled route, e.g. up or down the summit. Due to the nature of the Randall layout, we can instead define a clockwise vs counterclockwise direction for each block and use that for customization.

A few interesting ideas to explore for v2:

• Start with the simulator.
• Decouple state visualization from the simulator. Output drivers that would be useful are both HTML/SVG (like v1) and a windowed Java (Swing or such).
• One of the things to simulate and deal with are flaky sensors. That’s something that v1 doesn’t deal with neatly, and even JMRI’s delayed off/on doesn’t help as much. This can be combined with prediction:
• If the system knows a train takes X seconds to go through a given block, the sensor for that block can be marked as potentially flaky and thus having it flicker can be ignored for the expected travel duration.
• Flakiness detection could be automated: e.g. a sensor that flips every X < 2 seconds is suspicious.
• We may not want the system to automatically mark sensors as flaky, instead flag them for manual review.
• Generally speaking the system as a whole needs an event log with normal / warning / error conditions, time and message.
• Explore a Gradle-like configuration DSL instead of ANTLR.
• Kotlin is another choice given how much I like Groovy…
• That implies trying and understanding Kotlin first…