Welche Parameter gebraucht werden hängt ganz vom Komplexitätsgrad ab. Ich weiss natürlich nicht ob gewisse Parameter, oder mehrere statt einen, sich stärker auf die Performance auswirken oder nicht.
Zumindestes für die Umsetzung welche ich im Kopf habe, würden mehrere True/False Werte ausreichen. Nachfolgendes Beispiel ist für die Typ L Signale. Dies sollte aber analog für Typ N und vermutlich die meisten anderen Signalsysteme anwendbar sein.
Im UI-Menü hätte man die verschiedenen Signalbegriffe aufgelistet. Daneben bräuchte es ein Auswahlmenü, um die Wegpunkte den Signalbegriffen zuzuordnen. Intern würden dann die ganzen Abfragen gemacht. In meinem Beispiel, zumindest wenn dies möglich wäre, würde jeder Wegpunkt schlussendlich einen True/False Wert haben. Diese werden dann genutzt, um das korrekte Signalbild anzuzeigen.
Die Abfrage basiert darauf, ob ein Wegpunkt im Pfad ist oder nicht. Aufgrund dieser Unterscheidung im Pfad, könnte man das Signalbild unterscheiden. Da die Pfade vermutlich bloss eine begrenzte Distanz voraus berechnet werden, können damit Vorsignale wohl nur in Relation zum nächsten Signal aufgebaut werden (insofern sie nahe genug beieinander stehen).
Dort wo ein Signal ist (rote Punkte: WP1 im ersten Beispiel, WP1 und WP2 im zweiten Beispiel), wäre genauso eine direkte Referenz auf das Signal möglich.
Selbstverständlich könnten Zusatzanzeigen wie kurze fahrt, besetztes Gleis, genauso integriert werden. Die Limitierung hierfür liegt vermutlich darin, dass ein definierter Pfad immer diese Zusatzanzeige haben würde. Eine Abfrage ob im folgenden Bahnsteigbereich ein Zug das Gleis besetzt, sollte nicht möglich sein, weil gerade keine Abfrage für eine Fahrt in diesen Block stattfindet.
Ich bin der Meinung, dass man es so einfach wie möglich halten sollte, gerade weil die gesamte Verarbeitung periodisch durchgeführt werden muss und so die Performance belastet.