Anforderungen an Dienst und Bedienung (REQ-SVC)

Umgesetzt in crates/railit-runtime, apps/railitd und apps/railit.

Anmeldung, Rollen, TLS und Auditprotokoll: siehe sicherheit.md.

ID	Anforderung	Gefährdung	Nachweis
REQ-SVC-001	railitd startet nur, wenn Plan und Netz zusammengehören (gleiche Elemente in gleicher Reihenfolge).	H-004	check_correspondence; Startprüfung in railitd
REQ-SVC-002	Bedienung und Betriebsführung stellen nur Anforderungen an den Kern. Stellbefehle an Feldelemente erzeugt ausschließlich der Kern.	H-003, H-006	Architektur: API und Engine besitzen keinen Weg zu Command außer über Interlocking::step
REQ-SVC-003	Mit Benutzerdatei oder Zugangstoken verlangt die API eine Anmeldung für alle Pfade außer /v1/health (siehe REQ-SEC-001).	H-006	operate_station_over_api, roles_areas_and_audit_with_tokens
REQ-SVC-004	Jede Anforderung erhält eine eindeutige Antwort des Kerns (angenommen oder abgelehnt mit Grund).	H-006	operate_station_over_api, Szenarien
REQ-SVC-005	Geheime Schlüssel werden nur für den Eigentümer lesbar angelegt und nie überschrieben.	H-008	keygen_compile_verify_info
REQ-SVC-006	Hilfshandlungen über die API verlangen eine Bedienernummer: mit Benutzerverwaltung die des angemeldeten Benutzers, sonst den Kopf X-Railit-Operator. Die Antwort enthält das Ereignis der Hilfshandlung (angefordert, ausgeführt, verfallen).	H-006	aux_operation_and_journal, mutual_tls_identifies_users_by_certificate
REQ-SVC-007	Ein Netz mit Stellbereichen läuft mit einem Kern je Bereich; jeder Bereich hat seinen signierten Plan, der zu seinem Teilnetz passen muss, und sein eigenes Journal. Grenzmeldungen werden im folgenden Zyklus zugestellt; Namen werden über alle Bereiche aufgelöst, Grenzen als Bereich>Nachbar adressiert.	H-004, H-012	network_with_areas_over_api, every_area_journal_replays, Szenarien 13–15
REQ-SVC-008	Die gRPC-Schnittstelle railit.v1 liegt auf dem Port der REST-API, hinter derselben Anmeldung, und nutzt dieselbe Dienstschicht: gleiche Rechte, gleiches Auditprotokoll, gleiche Antworten. Ablehnungen des Kerns sind Antworten, keine Fehler.	H-006	interlocking_over_grpc, gRPC über mTLS in mutual_tls_identifies_users_by_certificate
REQ-SVC-009	Der Dienst liefert Metriken für den Betrieb im Prometheus-Textformat (GET /v1/metrics, Anmeldung wie /v1/state): Zyklen und Rechenzeit je Zyklus (Histogramm, Überschreitungen der Zykluszeit), Anforderungen nach Ergebnis, Meldungen, Hilfshandlungen, sicherer Zustand, Kanäle, Fahrstraßen, Journal und Anbindung der Knoten. Metriken haben keine Rückwirkung auf den Betrieb.	H-015, H-016	operate_station_over_api, safe_computer_nodes_over_api, histogram_is_cumulative_and_consistent
REQ-SVC-010	Rückschau: Mit --journal beantwortet der Dienst Fragen an seine eigenen Journale (GET /v1/journal, /v1/journal/state?at_ms=, /v1/journal/events?from_ms=&to_ms=, je Stellbereich mit area). Zustand und Ereignisse werden ab dem letzten Zustandsabzug rekonstruiert und gegen das Journal geprüft (REQ-JRN-008); die Rückschau ist reine Anzeige ohne Verbindung zum laufenden Betrieb.	H-011, H-016	aux_operation_and_journal
REQ-SVC-011	Bereitschaftsrechner: Der Hauptrechner liefert sein Journal als fortlaufenden Strom (GET /v1/journal/stream?area=&offset=). railitd --standby URL liest ihn je Stellbereich mit, prüft und rechnet jede Zeile nach (REQ-JRN-009) und zeigt den so gewonnenen Zustand über dieselbe API und denselben Bedienplatz an, deutlich als Bereitschaftsrechner gekennzeichnet. Jede Bedienung wird abgewiesen (503); bricht die Verbindung ab, setzt er an der letzten Position fort, passt das Journal nicht mehr, liest er von vorn; /v1/health nennt Rolle, Verbindung und Stand. Die Übernahme des Betriebs regeln REQ-SVC-012 bis REQ-SVC-014.	H-011, H-015, H-016	standby_follows_the_primary, area_names_are_encoded, E2E bedienplatz.test.ts (Bereitschaftsrechner)
REQ-SVC-012	Ausgabe erst nach Quittung und Übernahme: Mit Ausgabesperre gibt die Runtime Stellbefehle, Grenzmeldungen und ETCS-Fahrerlaubnisse eines Zyklus erst frei, wenn der Bereitschaftsrechner die Journalzeilen dieses Zyklus in allen Bereichen mit Zyklus und Hash quittiert hat. Bleiben Quittungen länger als die Frist aus, gibt sie alles frei und arbeitet ohne Sperre weiter; sie sperrt wieder, sobald der Bereitschaftsrechner aufgeholt hat. Gedeckt ist der Bereitschaftsrechner nur, solange die Sperre besteht und alles Freigegebene quittiert ist; dann sichert die Runtime zu, die Sperre noch eine bestimmte Zeit zu halten. Nur innerhalb dieser Zusage übernimmt der Bereitschaftsrechner den Betrieb mit dem mitgelesenen Zustand (REQ-IXL-025); das Journal des übernehmenden Rechners beginnt mit der Übernahme und spielt ab.	H-001, H-003, H-010, H-015, H-017	outputs_wait_for_all_areas, lapse_releases_everything_and_rearms_after_catching_up, area_without_journal_lapses, takeover_in_beispielstadt_is_safe, takeover_in_nordbahn_is_safe, stale_takeover_without_gate_opens_the_crossing_before_a_train, gate_covers_only_a_current_standby
REQ-SVC-013	Umschalter: Der Feldrechner lässt immer nur ein zugelassenes Stellwerk stellen, das führende; PDUs anderer Stellwerke verwirft er, ihre Verbindungen kommen nicht zustande, ihre Befehle wirken nicht – auch wenn nur die Verbindung zu einer einzelnen Objektsteuerung fehlt. Führend wird ein Stellwerk erst mit einem echten Verbindungsaufbau, und erst wenn alle Verbindungen des bisherigen seit der Umschaltzeit abgebaut sind (dann ist die Rückfallebene wirksam). Ein zurückkehrender früherer Hauptrechner wird nicht mehr gehört. Bei Netzen mit Stellbereichen gilt das je Bereich: Jeder Bereich hat eigene Objektsteuerungen und einen eigenen Umschalter (REQ-COM-010).	H-001, H-003, H-015, H-017	second_interlocking_is_rejected_while_the_leader_lives, standby_leads_after_the_leader_is_lost, switch_per_area
REQ-SVC-014	Übernahme im Dienst: Der Bereitschaftsrechner quittiert jeden geprüften Stand (POST /v1/journal/ack, nur mit dem Recht „Journal quittieren“, Rolle bereitschaft); der Hauptrechner arbeitet mit --standby-gate-ms mit Ausgabesperre und antwortet mit seiner Zusage. Mit --takeover-after-ms versucht der Bereitschaftsrechner, am Feldrechner zu führen, sobald der Strom des Hauptrechners so lange schweigt; meldet dieser sich vorher wieder, liest er weiter mit. Führt er, übernimmt er mit dem mitgelesenen Zustand, wenn die letzte Zusage zu diesem Zeitpunkt noch galt (abzüglich eines Sicherheitsabstands), sonst beginnt er wie nach einem Neustart. Danach rechnet er mit eigenem Journal (beginnend mit der Übernahme) und eigener Ausgabesperre, /v1/health nennt Rolle, Abschnitt und Zusage, der Bedienplatz gibt die Bedienung frei und meldet die Übernahme.	H-001, H-003, H-015, H-016, H-017	standby_takes_over_with_the_followed_state, standby_restarts_without_a_promise, roleOf, takeoverText