AK VRZ - NERZ eV

AK VRZ 

Verkehrsrechnerzentralen 

Technische Anforderungen 

Segment 7 - Steuerung (Ste) 

Ersteller: 

Autor: 

Dipl.-Ing. H.C. Kniß 

Dipl.-Inform. R. Schmitz 

Dipl.-Ing. C. Westermann 

Version: 

Stand 

Status: 

PID: 

Submodell: 

Dokument: 

VS-Einstufung: 

Projekt ID AG: 

Projekt ID AN: 

2.0 

08.10.2004 

akzeptiert 

SE-02.07.00.00.00-TAnf-2.0 

Systementwicklung 

SE-02.07.00.00.00-TAnf-2.0 [TAnf Ste].doc 

---- 


BAST.06.006 / BAST.07.007 

Kappich+Kniß Systemberatung Verkehr und Technik 

Im Auftrag der Bundesanstalt für Straßenwesen BASt




Allgemeines 

1 Allgemeines 

Verteilerliste 

Entfällt. Dokumentverteilung entsprechend aktuellem Projektverteiler. 

Versionsübersicht 

Nr. Datum Version Änderungsgrund Bearbeiter 

1 23.05.01 0.1 Ersterstellung Kniß 

Schmitz 

Westermann 

2 09.07.01 0.2 Einarbeitung Prüfvermerk von ptv Westermann 

3 11.07.01 1.0 Überführung in den Status "akzeptiert" Westermann 

4 28.05.04 1.1 Überarbeitung Westermann 

5 15.06.04 1.2 Überarbeitung Westermann 

6 21.06.04 2.0 Überführung in den Status "akzeptiert" Westermann 

7 09.09.04 2.0 Formulierungen geändert Weiß 

8 08.10.04 2.0 SW-Einheiten Nässestufen und Helligkeitssteuerung 

formell ergänzt 

Westermann 

Tabelle 1-1: Versionsübersicht 

Änderungsübersicht 

Nr. Version geändertes Beschreibung der Änderung 

Kapitel 

1 0.1 alle Ersterstellung 

2 0.2 5.1.2 Gesamtfunktion 

des Elements 

Klargestellt, dass Umleitungsempfehlungen von Netzbeeinflussungsanlagen 

in RDS/TMC-Meldungen umgesetzt werden 

müssen [1]. 

2 0.2 alle Schriftart für die Aufrufparameter geändert [2]. 

3 0.2 5.1.2.3 Generieren 

von 

Verkehrswarndienstmeldungen 

4 0.2 5.1.2.3.1 Erklärungskomponente 

für Verkehrswarndienstmeldungen 

5 0.2 5.1.2.4 Aufheben 

von 


Verdeutlicht, dass ein Ereignis dem nächsten stromabwärtsliegenden 

RDS-Knoten zugeordnet wird [3]. 

Ermittlung der Location-Codes detailliert. [6] 

Algorithmus für die Erklärungskomponente "Baustelle" zu 

den RDS/TMC-Meldungen ergänzt. [4] 

Aufhebung von Verkehrswarndienstmeldungen verdeutlicht. 

[5] 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 

Status: akzeptiert 

Seite 2 

von 24 Seiten 

Schutzvermerk DIN 34 beachten




Allgemeines 

Nr. Version geändertes 

Kapitel 

6 0.2 5.1.2 Gesamtfunktion 

des Elements 

5.2 Technische 

Anforderungen 

an 

die SW- 

Einheit 

"RDS/TMC 

Verwaltung" 

7 1.1 5.1 Technische 

Anforderungen 

an 

die SW- 

Einheit 

"RDS/TMC" 

ff. 

8 1.1 5.1.2.2 

Analyse der 

Verkehrssituation 

bzgl. 

Stau und 

Staugefahr 

9 1.1 5.1.2.3 Generieren 

von 


10 1.1 5.1.2.3.1 

Erklärungskomponente 

für Verkehrswarndienstmeldungen 

11 1.1 5.1.2.4 

Aufheben von 


Beschreibung der Änderung 

Neue SW-Einheit "Verwaltung RDS/TMC" eingefügt. 

Alle aufgeführten Aufrufparameter wurden gestrichen, da sie 

als online Parameter direkt im Betrieb änderbar sind. 

Als Aufrufparameter wurde "-konfiguration" ergänzt, über den 

der Bezug zu den Konfigurationsobjekten festgelegt wird, mit 

denen die Applikation arbeitet. 

Namen der Parameter an Anwenderforderungen angepasst. 

-dMax 

RDSDMax 

-dStoerfallAnfang RDSDStoerfallAnfang 

-dStoerfallEnde RDSDStoerfallEnde 

-mindestLaenge RDSDMindestLaenge 

-dMaxEinzelStoerfall 

RDSDMaxEinzelStoerfall 

Der Parameter lSIAusdehnung wird nicht speziell für das 

Verfahren der RDS/TMC Meldungserstellung benötigt. Die 

Ausdehnung einer Störung um einen lokalen Störfallindikator 

wird je Störfallindikator durch eine Ausdehnung vor und 

hinter dem Imdikator parametriert. 

Abbildung der Störfallsituation auf RDS-Ereignisse wird online 

parametrierbar ausgelegt (war konfigurierbar) 

Die Berücksichtigung von Baustellen als Erklärungskomponente 

von RDS-Meldungen ist parametrierbar. Parameter 

RDSBeruecksichtigeBaustellen, RDSBaustelleSBv 

und RDSBaustelleSBn ergänzt. 

Die Zeitspanne, in der neue Daten vorliegen müssen, damit 

die Meldung aufrecht erhalten bleibt, wird bei der Meldungserstellung 

nicht benötigt (Parameter RDSMaxOhneDaten). 

Eine Meldung wird z.B. automatisch aufgehoben, wenn zu 

einem MQ eine parametrierbare Zeit ( Übergang nach 

"Keine Aussage") keine Daten vorliegen. Wenn ein Stauobjekt 

nicht mehr vorhanden respektive gültig ist, wird das bei 

der Meldungserstellung direkt berücksichtigt, da der entsprechende 

Störfallindikator nicht mehr in die Überlagerung eingeht. 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 3 

von 24 Seiten 





Allgemeines 

Nr. Version geändertes Beschreibung der Änderung 

Kapitel 

12 1.1 5.1.3.2.1 Erforderliche Aufrufparameter überarbeitet. 

RDSTMC – 

Starter 

13 1.1 5.2.3.2.1 Erforderliche Aufrufparameter überarbeitet. 

RDSTMCVer 

waltung – 

Starter 

14 1.2 Alle Präfix 'RDS' durch Präfix 'TMC' ersetzt. 

15 1.2 5.1.2.2 

Analyse der 

Verkehrssituation 

bzgl. 

Stau und 

Staugefahr 

Bei den Stauobjekten wird der Verzögerungswert für den Zustandswechsel 

von "Stau" nach "keine Aussage" übernommen. 

Er tritt in Kraft, wenn zu einem Stauobjekt keine Daten 

mehr verfügbar sind, weil z.B. die Quelle nicht mehr vorhanden 

ist. 

16 2.0 5.1.2 

Gesamtfunktion 

des Elements 

„Die LMS überträgt an beide VRZ’en“ durch „Die LMS überträgt 

an die VRZ’en“ ersetzt. 

Für die von der SW-Einheit „LMS“ verteilten Meldungen, die 

von der Landesmeldestelle übernommen wurden, wurde der 

Aspekt „empfangen“ eingefügt. 

Tabelle 1-2: Änderungsübersicht 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 4 

von 24 Seiten 





Allgemeines 

Kurzbeschreibung 

In diesem Produkt werden technische Anforderungen an das Gesamtsystem, die Segmente 

sowie die SW-Einheiten/HW-Einheiten definiert. Zu diesen Elementen der Erzeugnisstruktur 

wird jeweils die Funktionalität dargestellt und es werden technische Anforderungen an die 

Schnittstellen, Qualitätsforderungen und technische Anforderungen an die Entwicklungs- und 

SWPÄ-Umgebung definiert. Technische Anforderungen, die keinem Element der Erzeugnisstruktur 

zugeordnet werden können, werden als allgemeine Anforderungen festgehalten. 

Die Technischen Anforderungen sind in 14 Teildokumente aufgeteilt. Neben den Technischen 

Anforderungen zum Gesamtsystem werden in jeweils separaten Dokumenten zu den einzelnen 

Segmenten die Technischen Anforderungen aufgeführt. Es ergibt sich somit folgende Struktur: 

Nr. Segment 

Kürzel PID 

0 Gesamtsystem SE-02.00.00.00.00-TAnf 

1 Datenverteiler DaV SE-02.01.00.00.00-TAnf 

2 Kommunikation mit externen Stellen KEx SE-02.02.00.00.00-TAnf 

3 Datenhaltung und Archiv DhA SE-02.03.00.00.00-TAnf 

4 Datenübernahme und Aufbereitung DUA SE-02.04.00.00.00-TAnf 

5 Intelligente Analyseverfahren IAV SE-02.05.00.00.00-TAnf 

6 Intelligente Bewertungsverfahren IBV SE-02.06.00.00.00-TAnf 

7 Steuerung Ste SE-02.07.00.00.00-TAnf 

8 Parametrierung und Konfiguration PuK SE-02.08.00.00.00-TAnf 

9 Protokolle und Auswertungen PuA SE-02.09.00.00.00-TAnf 

10 System Sys SE-02.10.00.00.00-TAnf 

11 Verwaltung VeW SE-02.11.00.00.00-TAnf 

12 SWPÄ-Tools PAT SE-02.12.00.00.00-TAnf 

13 Bedienung und Visualisierung BuV SE-02.13.00.00.00-TAnf 

Tabelle 1-3: Aufteilung der Technischen Anforderungen in Teildokumente 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 5 

von 24 Seiten 





Allgemeines 

Inhalt 

1 Allgemeines 2 

Verteilerliste 2 

Versionsübersicht 2 

Änderungsübersicht 2 

Kurzbeschreibung 5 

Inhalt 6 

Abkürzungen 8 

Definitionen 8 

Verzeichnis der Tabellen 8 

Verzeichnis der Abbildungen 8 

Referenzierte Dokumente 9 

2 Allgemeine Anforderungen 10 

3 Technische Anforderungen an das Gesamtsystem 10 

4 Technische Anforderungen an das Segment Steuerung 11 

4.1 Identifikation des Elements 11 

4.2 Gesamtfunktion des Elements 11 

4.3 Technische Anforderungen an die Schnittstellen 11 

4.3.1 Technische Anforderungen an die Nutzerschnittstelle 11 

4.3.2 Technische Anforderungen an andere Schnittstellen 11 

4.4 Qualitätsforderungen 11 

4.4.1 Kritikalität 11 

4.4.2 Technische Anforderungen der IT-Sicherheit 11 

4.4.3 Technische Anforderungen an sonstige Qualitätsmerkmale 11 

4.5 Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung 11 

5 Technische Anforderungen an SW-Einheiten/HW-Einheiten 12 

5.1 Technische Anforderungen an die SW-Einheit "RDS/TMC" 12 

5.1.1 Identifikation des Elements 12 

5.1.2 Gesamtfunktion des Elements 12 

5.1.2.1 Konfiguration 13 

5.1.2.2 Analyse der Verkehrssituation bzgl. Stau und Staugefahr 13 

5.1.2.3 Generieren von Verkehrswarndienstmeldungen 14 

5.1.2.3.1 Erklärungskomponente für Verkehrswarndienstmeldungen 16 

5.1.2.4 Aufheben von Verkehrswarndienstmeldungen 17 

5.1.2.5 Initialisierung nach Neustart der RDS/TMC Verkehrswarndienstmeldungserstellung 17 

5.1.3 Technische Anforderungen an die Schnittstellen 17 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 6 

von 24 Seiten 





Allgemeines 

5.1.3.1 Technische Anforderungen an die Nutzerschnittstelle 17 

5.1.3.2 Technische Anforderungen an andere Schnittstellen 17 

5.1.3.2.1 RDSTMC – Starter 17 

5.1.3.2.2 RDSTMC – Applikation 18 

5.1.3.2.2.1 Eingangsinformationen 18 

5.1.3.2.2.2 Ausgangsinformation 18 

5.1.4 Qualitätsforderungen 18 

5.1.4.1 Kritikalität 18 

5.1.4.2 Technische Anforderungen der IT-Sicherheit 18 

5.1.4.3 Technische Anforderungen an sonstige Qualitätsmerkmale 18 

5.1.5 Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung 19 

5.2 Technische Anforderungen an die SW-Einheit "RDS/TMC Verwaltung" 19 



5.2.2.1 Interaktion mit der Bedienung 19 

5.2.2.2 Abläufe 20 

5.2.2.2.1 Annahme einer Meldung unter dem Aspekt "generiert" 20 

5.2.2.2.2 Annahme einer Meldung unter dem Aspekt "bearbeitet" 20 


5.2.3.1 Technische Anforderungen an die Nutzerschnittstelle 21 

5.2.3.2 Technische Anforderungen an andere Schnittstellen 21 

5.2.3.2.1 RDSTMCVerwaltung – Starter 21 

5.2.3.2.2 RDSTMCVerwaltung – Applikation 22 

5.2.3.2.2.1 Eingangsinformationen 22 

5.2.3.2.2.2 Ausgangsinformation 22 


5.2.4.1 Kritikalität 22 

5.2.4.2 Technische Anforderungen der IT-Sicherheit 22 

5.2.4.3 Technische Anforderungen an sonstige Qualitätsmerkmale 22 

5.2.5 Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung 22 

5.3 Technische Anforderungen an die SW-Einheit "Nässestufen" 23 





5.4 Technische Anforderungen an die SW-Einheit "Helligkeitssteuerung" 23 





6 Anforderungsverzeichnis 24 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 7 

von 24 Seiten 





Allgemeines 

Abkürzungen 

siehe Dokument "Abkürzungen". 

Definitionen 

siehe Dokument "Glossar". 

Verzeichnis der Tabellen 

Tabelle 1-1: Versionsübersicht 2 

Tabelle 1-2: Änderungsübersicht 4 

Tabelle 1-3: Aufteilung der Technischen Anforderungen in Teildokumente 5 

Verzeichnis der Abbildungen 

Abbildung 5-1: Informationsfluss " RDS/TMC" 12 

Abbildung 5-2: Längenermittlung 15 

Abbildung 5-3: Baustellenermittlung 16 

Abbildung 5-4: Informationsfluss " RDS/TMC Verwaltung" 19 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 8 

von 24 Seiten 





Allgemeines 

Referenzierte Dokumente 

[Afo] Anwenderforderungen AK VRZ, Dokument "SE- 

02.00.00.00.00-Afo", aktueller Stand 

[SysArc] 

[TAnfGes] 

[TAnfDaV] 

[TAnfKEx] 

[TAnfDhA] 

[TAnfDUA] 

[TAnfIAV] 

[TAnfIBV] 

[TanfPuK] 

[TanfBuV] 

[DatK] 

Systemarchitektur AK VRZ, Dokument "SE-02.00.00.00.00- 

SysArc", aktueller Stand 

Technische Anforderungen an das Gesamtsystem AK VRZ, 

Dokument "SE-02.00.00.00.00-TAnf", aktueller Stand 

Technische Anforderungen an den Datenverteiler AK VRZ, 

Dokument "SE-02.01.00.00.00-TAnf", aktueller Stand 

Technische Anforderungen an die Kommunikation mit externen 

Stellen AK VRZ, Dokument "SE-02.02.00.00.00-TAnf", aktueller 

Stand 

Technische Anforderungen an die Datenhaltung und das Archiv 

AK VRZ, Dokument "SE-02.03.00.00.00-TAnf", aktueller 

Stand 

Technische Anforderungen an die Datenübernahme und Aufbereitung 


Stand 

Technische Anforderungen an die intelligenten Analyseverfahren 


Stand 

Technische Anforderungen an die intelligenten Bewertungsverfahren 


Stand 

Technische Anforderungen an die Parametrierung und Konfiguration 


Stand 

Technische Anforderungen an die Bedienung und Visualisierung 


Stand 

Datenkatalog AK VRZ, Dokument "SE-02.00.00.00.00-DatK", 

aktueller Stand 

[SSÜb] Schnittstellenübersicht AK VRZ, Dokument "SE- 

02.00.00.00.00-SSÜb", aktueller Stand 

[SSB] Schnittstellenbeschreibung AK VRZ, Dokument "SE- 

02.00.00.00.00-SSB", aktueller Stand 

[MARZ] 

[VMOD97] 

Merkblatt für die Ausstattung von Verkehrsrechnerzentralen 

und Unterzentralen, Ausgabe 1999. 

Der Bundesminister des Innern, Entwicklungsstandard für IT- 

Systeme des Bundes Vorgehensmodell, Juni 1997, KBSt, 

Koordinations- und Beratungsstelle der Bundesregierung für 

Informationstechnik in der Bundesverwaltung. 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 9 

von 24 Seiten 





Allgemeine Anforderungen 

2 Allgemeine Anforderungen 

Die technischen Anforderungen, die keinem Element der technischen Architektur gesondert zugeordnet 

werden können, sind in dem Dokument [TAnfGes] aufgeführt. 

3 Technische Anforderungen an das Gesamtsystem 

Die technischen Anforderungen an das Gesamtsystem sind in dem Dokument [TAnfGes] aufgeführt. 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 10 

von 24 Seiten 





Technische Anforderungen an das Segment Steuerung 

4 Technische Anforderungen an das Segment Steuerung 

4.1 Identifikation des Elements 

Nummer des Segments: 7 

Bezeichnung Segment: 

Steuerung 

4.2 Gesamtfunktion des Elements 

Das Segment "Steuerung" umfasst die Funktionen von Steuerungen verschiedener Anlagen. 

Dies sind zur Zeit die RDS/TMC-Verkehrswarndienstmeldungserstellung (SW-Einheit 

"RDS/TMC") und die Verwaltung von RDS/TMC-Verkehrswarndienstmeldungen (SW-Einheit 

"RDS/TMC Verwaltung"). Die im Rahmen von späteren Erweiterungen eventuell hinzukommenden 

SW-Einheiten für Steuerungsmodelle wie z.B. "Steuerung NBA", "Steuerung SBA", "Steuerung 

KBA", "Steuerung Helligkeit" etc. sollten dem Segment 7 "Steuerung" zugeordnet werden. 

4.3 Technische Anforderungen an die Schnittstellen 

4.3.1 Technische Anforderungen an die Nutzerschnittstelle 

Alle SW-Einheiten des Segments stellen im Sinne der Festlegungen der Systemarchitektur Applikationen 

dar und verfügen damit über mehrere benannte Aufrufparameter, mit denen sich das 

(Start-) Verhalten der Applikation in bestimmten Bereichen einstellen lässt. Neben den in 

[TAnfGes] aufgeführten Technischen Anforderungen an die Nutzerschnittstelle sind in diesem 

Segment keine weiteren allgemeinen Aufrufparameter vorgesehen. 

4.3.2 Technische Anforderungen an andere Schnittstellen 

Das Segment verfügt nur indirekt über die SW-Einheiten über eine systeminterne Schnittstelle 

zum Datenverteiler "Applikation-DAF" (entsprechend den Festlegungen in der [SysArc]). 

4.4 Qualitätsforderungen 

4.4.1 Kritikalität 

Entsprechend der projektspezifischen Kritikalitätsdefinitionen wird die Kritikalität dieses Segments 

als mittel eingestuft, da Fehlverhalten indirekt zur Weitergabe falscher Schaltungen oder 

falscher Verkehrsmeldungen an den Verkehrsteilnehmer führt oder zum Verlust größerer Datenmengen 

(>1 Minute) führen kann. 

4.4.2 Technische Anforderungen der IT-Sicherheit 

Es werden keine über die IT-Sicherheitsanforderungen der [Afo] hinausgehenden Anforderungen 

an das Segment gestellt. 

4.4.3 Technische Anforderungen an sonstige Qualitätsmerkmale 

Für dieses Segment gelten die allgemeinen Anforderungen an die Anwendersoftware, wie in 

der [Afo] Kapitel 6.7 "Qualitätsanforderungen" festgelegt. 

4.5 Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung 

Für dieses Segment gelten die allgemeinen Anforderungen an die Anwendersoftware, wie in 

der [Afo] Kapitel 7.1.1 "Anforderungen an die Systemsoftware" festgelegt. 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 11 

von 24 Seiten 





Technische Anforderungen an SW-Einheiten/HW-Einheiten 

5 Technische Anforderungen an SW-Einheiten/HW-Einheiten 

5.1 Technische Anforderungen an die SW-Einheit "RDS/TMC" 

5.1.1 Identifikation des Elements 

Nummer der SW-Einheit im Segment: 1 

Bezeichnung der SW-Einheit: 

RDS/TMC 

5.1.2 Gesamtfunktion des Elements 

Aufgabe der RDS/TMC-Meldungserstellung ist die Erstellung von aktuellen Verkehrsmeldungen 

aufgrund verschiedener Eingangsgrößen, die Aufschluss über die momentane Verkehrssituation 

geben. Die erstellten Meldungen müssen an die LMS weitergeleitet werden 1 . 

Die LMS überträgt ihrerseits spontan bei Änderungen die geänderten Verkehrsmeldungen an 

die VRZ’en. Auf den VRZ’en werden aus dem Gesamtbestand des von der LMS empfangenen 

Meldungsbestands, die jeweils relevanten Anteile ermittelt und übernommen 1 . 

Störfallindikatoren 

Informationen zu den 

Baustellen 

KEx 

Netzbeeinflussung 

Umleitungsempfehlungen 

Parameter 

Alert-C kodierte 

Meldungen 

RDS/TMC 

Meldungserstellung 

generiert 

RDS/TMC 

Verwaltung 

senden 

KEx 

LMS 

LMS 

generiert 

bearbeitet 

versendet 

empfangen 

BuV 

Abbildung 5-1: Informationsfluss " RDS/TMC" 

Abbildung 5-1 zeigt den Informationsfluss bei der Verkehrswarndienstmeldungsbehandlung. Die 

RDS/TMC-Meldungserstellung analysiert die Verkehrssituation anhand von Störfallindikatoren 

und stellt die erzeugten Meldungen im systeminternen Format unter dem Aspekt "generiert" zur 

Verfügung. Diese Meldungen können über den normalen Anmeldemechanismus von alle Applikationen 

über die Datenverteilerschnittstelle abonniert werden. Im wesentlichen werden die 

Meldungen unter dem Aspekt "generiert" von der Bedienung und Visualisierung, welche die 

Meldungen darstellt, eventuell bearbeitet (editiert oder quittiert), sowie von der SW-Einheit 

"RDS/TMC Verwaltung", welche die Meldungen nach einer parametrierbaren Zeitspanne auto- 

1 Die Weiterleitung von Verkehrswarndienstmeldungen der VRZ an die LMS sowie die Übernahme 

der relevanten Meldungen von der LMS wird in der SWE-Einheit "LMS" (siehe 

[TAnfKEx]) durchgeführt. 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 12 

von 24 Seiten 






matisch an die LMS weiterleitet (falls die Option automatische Weiterleitung gewählt wurde), 

übernommen. 

Die SW-Einheit "Verwaltung RDS/TMC" meldet sich auch auf die Meldungen unter dem Aspekt 

"bearbeitet" an. Sie prüft, ob eine Meldung an die Landesmeldestelle versendet werden soll und 

publiziert sie in diesem Fall unter dem Aspekt "senden" (s.a. Kapitel 5.2 "Technische Anforderungen 

an die SW-Einheit "RDS/TMC Verwaltung""). Auf diesen Aspekt meldet sich die SW- 

Einheit "LMS" (s.a. [TAnfKEx]) an, die die Meldung kodiert und an die LMS verschickt. Die von 

der SW-Einheit "LMS" versendeten Meldungen werden unter dem Aspekt "versendet" verteilt. 

Die von der Landesmeldestelle übernommen und ins systeminterne Format konvertierten Meldungen 

werden unter einem weiteren Aspekt von der SW-Einheit "LMS" unter dem Aspekt 

"empfangen" verteilt (s.a. [TAnfKEx]). 

Von Netzbeeinflussungsanlagen müssen die Informationen zu Umleitungsempfehlungen entgegengenommen 

und in RDS/TMC Meldungen umgesetzt werden. Die Auswahl welche Umleitungsempfehlungen 

über RDS/TMC veröffentlicht werden ist Aufgabe der NBA. 

Die SWE-Einheit RDS/TMC nimmt folgende Aufgaben wahr: 

1. Analyse der Verkehrssituation bzgl. Stau und Staugefahr 

2. Generierung und Aufhebung von Verkehrswarndienstmeldungen (systeminternes Format) 

Bevor auf die Aufgaben der Verkehrswarndienstmeldungserstellung eingegangen wird, soll im 

folgenden Unterpunkt die Konfiguration der SW-Einheit beschrieben werden. 

5.1.2.1 Konfiguration 

Über den Standardaufrufparameter -konfiguration = Name wird der Bezug zu den Konfigurationsobjekten 

festgelegt mit denen die Applikation arbeitet. Im Normalfall wird dieses Einstiegskonfigurationsobjekt 

eine VRZ oder eine UZ sein. Diesem Konfigurationsobjekt muss eine 

Menge von TMC-Abschnitten zugeordnet sein, für die Verkehrswarndienstmeldungen erstellt 

werden sollen. In der Konfiguration muss jedem TMC-Abschnitt mindestens ein geeigneter 

Messquerschnitt zuzuordnen sein. Außerdem muss in der Konfiguration eine Zuordnung zwischen 

TMC-Abschnitten und Location-Codes sowie die Zuordnung zwischen den Infrastrukturobjekten 

und den TMC-Abschnitten versorgt sein. 

5.1.2.2 Analyse der Verkehrssituation bzgl. Stau und Staugefahr 

Basis der Verkehrswarndienstmeldungen ist das Ergebnis der Analyse der Verkehrssituation 

bzgl. Stau und Staugefahr. Die Verkehrssituation wird anhand der Störfallindikatoren ausgewertet. 

Störfallindikatoren werden von verschiedenen Verfahren der Verkehrsflussermittlung erzeugt. 

Störfallindikatoren können lokale oder streckenbezogene Aussagen zur Verkehrssituation 

machen. Die angenommene Ausdehnung einer Störung, die durch einen lokalen Störfallindikator 

detektiert wurde, ist je Störfallindikator online parametrierbar. Bei dem entsprechenden 

Parameter ist die Ausdehnung vor und hinter den Störfallindikator einstellbar. 

Die in der RDS/TMC-Meldungserstellung zu berücksichtigenden Verfahren sind über einen online 

änderbaren Parameter (TMCSIVerfahren) einstellbar. 

Weiter ist über einen online änderbaren Parameter (TMCPlausibStauverlaufsanalyse) 

einstellbar, ob eine Plausibilisierung der Störfallindikatoren mit den Ergebnissen der Stauverlaufsanalyse 

erfolgen soll. In diesem Fall wird untersucht, ob ein Störfallindikator, der als Störfallsituation 

"Stau" detektiert hat, ein korrespondierendes Stauobjekt aufweist. D.h., es muss ein 

Stauobjekt geben, dessen räumliche Ausdehnung einen gemeinsamen Bereich mit der Ausdehnung 

des Störfallindikators hat. 

TSte-1 

Versorgung 

der Ausdehnung 

pro MQ 

TSte-2 

Plausibilisierung 

durch 

die Stauverlaufsanalyse 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 13 

von 24 Seiten 






Neben der Plausibilisierung durch die Stauobjekte kann über einen weiteren online änderbaren 

Parameter (TMCBeruecksichtigeStauverlaufsanalyse)angegeben werden, dass die 

Stauobjekte selbst bei der Meldungserstellung Berücksichtigung finden. In diesem Fall wird ein 

Stauobjekt als ein weiterer Störfallindikator betrachtet, der die räumliche Ausdehnung des 

Stauobjektes besitzt, die Störfallsituation "Stau" aufweist und eine übergebene Güte besitzt. 

Die Störfallindikatoren werden zeitlich geglättet, um zu verhindern, dass kurzzeitige Störungen 

oder Verbesserungen des Verkehrsflusses zu neuen oder geänderten Verkehrswarndienstmeldungen 

führen. Die Glättung erfolgt über online parametrierbare Verzögerungswerte 

(TMCVerzoegerungsmatrix), die eine Mindestzeitspanne für Verkehrssituationsänderungen 

vorgeben (s. [Afo] Kapitel 6.6.5.8.1.2.1 "Zeitliche Glättung der Störfallindikatoren"). 

Bei Einbeziehung der Stauobjekte für die Analyse der Verkehrssituation kann der Zustand auftreten, 

dass zu einem Stauobjekt Datensätze mit dem Inhalt "keine Daten" oder "keine Quelle" 

empfangen werden. In diesem Fall erfolgt ebenfalls eine zeitliche Glättung, um zu verhindern, 

dass kurzzeitige Störungen zu einer neuen oder geänderten Verkehrswarndienstmeldung führen. 

Dabei wird als Verzögerungswert die Zeitspanne für den Übergang der Verkehrssituation 

von "Stau (6)" nach "Keine Aussage (1)" aus der Verzögerungsmatrix übernommen 

(TMCVerzoegerungsmatrix). 

Es erfolgt eine Überlagerung der geglätteten Störfallindikatoren (s. [Afo] Kapitel 6.6.5.8.1.2.2 

"Überlagerung der Störfallindikatoren") anhand von online parametrierbaren Prioritäten 

(TMCPrioritaetenmatrix) der Störfallsituation in Abhängigkeit der ermittelten Güte. 

5.1.2.3 Generieren von Verkehrswarndienstmeldungen 

Nach der Überlagerung der geglätteten Störfallindikatoren erfolgt eine online parametrierbare 

Abbildung der Störfallsituationen auf TMC-Ereignisse (TMCAbbildungsmatrix) (s. [Afo] Kapitel 

6.6.5.8.1.2.3 "Abbildung der Störfallsituationen auf TMC-Ereignisse"). 

Im Längsabgleich wird versucht, TMC-Ereignisse gleichen Typs zusammenzufassen. Dazu wird 

ein maximaler Abstand zwischen zwei Störfallgrenzen parametriert (TMCDMax), der zu einer Zusammenfassung 

zweier benachbarter Störfälle zu einem Störfall führt. Zur Längenermittlung 

wird am Anfang (TMCDStoerfallAnfang)und am Ende (TMCDStoerfallEnde) der zusammengesetzten 

Störfälle ein online parametrierbarer Anteil addiert, der durch die Grenzen der 

Straßensegmente begrenzt ist (s. [Afo] Kapitel 6.6.5.8.1.2.4 "Längsabgleich und Längenbestimmung 

der TMC-Ereignisse"). Je Straßensegment respektive TMC-Abschnitt wird nur das 

schärfste TMC-Ereignis zur Verkehrslage (Stau, stockender Verkehr, dichter Verkehr) verfolgt, 

wobei eine online parametrierbare Mindestlänge des Ereignisses (TMCDMindestLaenge) vorausgesetzt 

ist. 

Bei der Längenermittlung sind zwei Sonderbehandlungen vorzusehen: 

• Wenn die Störfallausdehnung in einem TMC-Abschnitt eine maximale Länge überschreitet 

(Parameter TMCDMaxEinzelStoerfall z.B. 6 km) und diese Länge nur aufgrund eines 

einzelnen lokalen Störfallindikators ermittelt wurde, wird der Meldung keine Länge des Ereignisses 

zugeordnet. 

• Wenn in einem TMC-Abschnitt zwei oder mehrere Störfallindikatoren aufgrund einer Überschreitung 

des maximaler Abstand zwischen zwei Störfallgrenzen (Parameter TMCDMax) 

nicht zu ein Störfall zusammengeführt werden konnten, wird statt der Summe der Einzelausdehnungen 

keine Längenangabe bei der Meldung angegeben (Parameter 

TMCNichtAddieren). Im unten aufgeführten Beispiel würde als Länge für den TMC- 

Abschnitt im Normalfall L1+L2 ermittelt. Wenn als Parameter TMCNichtAddieren als "ja" 

angegeben wurde, wird in diesem Fall hier keine Länge ermittelt. 

TSte-3 

Berücksichtigung 

der 

Stauobjekte 

TSte-4 

Keine Längenzuordnung 

Option 1 

TSte-5 

Keine Längenzuordnung 

Option 2 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 14 

von 24 Seiten 






Fahrtrichtung 

MQ(i-2) 

MQ(i-1) 

K(j-1) 

K(j) 

RDS-Abbildung 

S 

> DMax 

S 

Längsabgleich 

S 

S 

L1 

L2 

S(j-1) 

Abbildung 5-2: Längenermittlung 

Aufeinanderfolgende TMC-Abschnitte einer Route (eine Route wird durch aufeinanderfolgende 

TMC-Locations gebildet, die eine direkte Folge von Vorgänger-/ und Nachfolger Beziehungen 

bilden), für die dasselbe Ereignis ermittelt wurde, werden zu einem Ereignis zusammengefasst. 

Das zusammengefasste Ereignis wird dann dem nächsten stromabwärtsliegenden TMC-Knoten 

zugeordnet; eine ggf. bestehende Meldung für einen Abschnitt, der Teil der Zusammenfassung 

ist, wird gelöscht bzw. wenn es sich um eine Meldung für den in Fahrtrichtung letzten Abschnitt 

handelt, überschrieben. 

Die ermittelte Länge des Ereignisses wird auf die im TMC-Ereigniskatalog enthaltenen Längen 

sowie die durch die Mehrsequenzmeldung verfügbaren Längenangaben abgebildet. Hierbei bildet 

immer die Mitte zwischen zwei Kilometerangaben die Grenze für die Einstufung. Dabei gehört 

jeweils die obere Intervallgrenze zum Intervall (z.B. 1km wird abgebildet wenn gilt: 0,5 km < 

Wert





Die detaillierte Beschreibung der systeminternen Meldungen erfolgt im Datenkatalog (s. [DatK]) 

und in der Schnittstellenbeschreibung (s. [SSB]). 

Sobald für aufeinanderfolgende TMC-Abschnitte wieder unterschiedliche Ereignisse vorliegen, 

muss die Zusammenfassung aufgehoben werden. Zu diesem Zweck wird die bisher bestehende 

Meldung gekürzt (die Anzahl der betroffenen Abschnitte wird entsprechend verkleinert) und 

für die aus der zusammengefassten Meldung herausgelösten Abschnitte werden ggf. neue einzelne 

Meldungen erzeugt. 

5.1.2.3.1 Erklärungskomponente für Verkehrswarndienstmeldungen 

Als Erklärungskomponente zu den RDS/TMC Meldungen kann zu dem TMC-Ereignis geprüft 

werden, ob als Ursache eine bekannte Baustelle in Frage kommt (Parameter 

TMCBeruecksichtigeBaustellen). Dazu wird für jede zu erzeugende RDS/TMC-Meldung 

kontrolliert, ob sich innerhalb eines Suchbereichs der Beginn einer dem System bekannten 

Baustelle befindet. Wenn dies der Fall ist, wird die Baustelle bei der Generierung der Verkehrswarndienstmeldung 

berücksichtigt, d.h. aus der Ereignisliste wird bei der Meldung zur Verkehrslage 

z.B. "Baustelle, 2 km Stau" gewählt. 

Der Suchbereich wird nach folgenden Kriterien bestimmt (s.a. Abbildung 5-3: Baustellenermittlung): 

• Ausgangspunkt des Suchbereichs ist die Wurzel des TMC-Ereignisses nach dem Längsabgleich. 

• Der Suchbereich wird stromabwärts um den Anteil sbv erweitert, wobei sbv eine parametrierbare 

Ausdehnung in Metern darstellt (Parameter TMCBaustelleSBv). Die Erweiterung 

wird durch Autobahnkreuze oder Dreiecke beschränkt; d.h. eventuelle Baustellen hinter einem 

Autobahnkreuz oder Dreieck werden nicht als Erklärungskomponente bei der Meldungserstellung 

berücksichtigt. 

• Analog wird der Suchbereich stromaufwärts um den Anteil sbn erweitert, wobei sbn eine parametrierbare 

Ausdehnung in Metern darstellt (Parameter TMCBaustelleSBn). 

Fahrtrichtung 

TSte-7 

Erklärungskomponente 

Baustelle 

MQ(i-2) 

MQ(i-1) 

MQ(i) MQ(i+1) MQ(i+2) 

K(j-1) 

K(j) 

K(j+1) 

K(j+2) 

RDS/TMC-Meldung 

Staulänge l 

Stau 

Stauwurzel 

Suchbereich 

sbn 

sbv 

Szenario 1 

Szenario 2 

Baustelle 1 

Baustelle 2 

Szenario 3 

Baustelle 3 

Szenario 4 

Baustelle 4 

Szenario 5 

Baustelle 5 

Szenario 6 

Baustelle 6 

Abbildung 5-3: Baustellenermittlung 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 16 

von 24 Seiten 






Im obigen Beispiel (Abbildung 5-3: Baustellenermittlung) ist für eine ermittelte Staumeldung der 

Suchbereich dargestellt. Weiter sind für 6 verschiedene Szenarien Baustellen in der Abbildung 

angegeben. Für Szenario 1, 2 und 6 würde bei der RDS/TMC-Verkehrswarndienstmeldungserstellung 

die eingezeichnete Baustelle nicht als Erklärungskomponente berücksichtigt, da die 

Baustellen außerhalb des Suchbereichs liegen. Baustelle 3 würde ebenenfalls nicht als Erklärungskomponente 

eingehen da der Beginn dieser Baustelle nicht im Suchbereich liegt. Für 

Szenario 4 und 5 würde die Baustelle als Erklärungskomponente bei der RDS/TMC-Verkehrswarndienstmeldungserstellung 

berücksichtigt. 

In der systeminternen Meldung wird die Baustelle, die als Erklärungskomponente der Verkehrswarndienstmeldung 

verwendet wurde, angegeben. Für den Fall, dass mehrere Baustellen 

als Erklärungskomponente für die Meldung in Frage kommen, wird die Baustelle angegeben, 

deren Beginn am nächsten an der Ereigniswurzel liegt. 

5.1.2.4 Aufheben von Verkehrswarndienstmeldungen 

Eine automatische Aufhebung von Meldungen erfolgt, wenn wieder freier Verkehr erkannt wurde, 

allerdings erst nach Ablauf der Verzögerungszeit. Auch wenn der Zustand „Keine Aussage“ 

über eine parametrierbare Zeit anliegt, führt dies zur Aufhebung der Meldung. 

5.1.2.5 Initialisierung nach Neustart der RDS/TMC Verkehrswarndienstmeldungserstellung 

Beim Neustart der Funktion RDS / TMC Meldungserstellung werden die zuletzt ermittelten Meldungen 

(Aspekt "generiert") eingelesen. Hieraus muss für jeden Abschnitt ermittelt werden, ob 

eine Meldung geändert oder ob zu der Meldung eine Aufhebung generiert werden muss. 

5.1.3 Technische Anforderungen an die Schnittstellen 

5.1.3.1 Technische Anforderungen an die Nutzerschnittstelle 

Die RDS/TMC-Verkehrswarndienstmeldungserstellung hat keine eigene Nutzerschnittstelle. Die 

Nutzerschnittstelle für die Darstellung der Meldungen und Unterstützung der Erstellung zusätzlicher 

Meldungen, sowie der Verwaltung und Freigabe aller Meldungen durch den Operator wird 

durch [TanfBuV] abgedeckt. 

5.1.3.2 Technische Anforderungen an andere Schnittstellen 

Die SW-Einheit besitzt drei Schnittstellen (entsprechend den Festlegungen in der [SysArc]). 

• Datenverteiler Applikationsfunktionen – Applikation 

(Schnittstelle zur SW-Einheit "Datenverteiler-Applikationsfunktionen" siehe Segment 

[TAnfDaV]) 

• RDSTMC – Starter 

(Aufrufschnittstelle der Applikation) 

• RDSTMC – Applikation 

(logische Schnittstelle zu anderen Applikationen) 

5.1.3.2.1 RDSTMC – Starter 

Die SW-Einheit stellt im Sinne der Festlegungen der Systemarchitektur eine Applikation dar und 

verfügt damit über mehrere benannte Aufrufparameter, mit denen sich das (Start-) Verhalten 

der Applikation in bestimmten Bereichen einstellen lässt. Neben den in Kapitel 4.3.1 

"Technische Anforderungen an die Nutzerschnittstelle" aufgeführten Aufrufparameter sind folgende 

Parameter zu unterstützen: 

TSte-8 

Schnittstelle 

RDSTMC - 

Starter 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 17 

von 24 Seiten 






-lms=konfigurationsobjekt 

Über diesen Parameter wird die pid oder id der Landesmeldestelle 

festgelegt, für die Verkehrswarndienstmeldungen erzeugt 

werden. 

-netz=konfigurationsobjekt 

Über diesen Parameter wird das Netz spezifiziert, für das die 

RDS/TMC Meldungserstellung die Analyse der Verkehrssituation 

bzgl. Stau und Staugefahr durchführen soll. 

5.1.3.2.2 RDSTMC – Applikation 

Logische Schnittstelle, die unter Nutzung der Datenverteilerschnittstelle realisiert ist und durch 

die Beschreibung der ausgetauschten Daten und eventuell notwendiger Abläufe beim Datenaustausch 

spezifiziert wird. 

5.1.3.2.2.1 Eingangsinformationen 

Eingangsinformationen sind die Störfallindikatoren aus den zu betrachtenden Verfahren zur 

Störfallerkennung und die von der Stauverlaufsanalyse erzeugten Stauobjekte (falls diese bei 

der Meldungserstellung berücksichtigt werden sollen). Weitere Eingangsinformationen sind die 

zur Zeit vorliegenden Baustellen, die als Erklärungskomponente der Meldungen benötigt werden. 

Neben den dynamisch veränderlichen Informationen sind als konfigurierende Eingangsdaten 

die Menge der zu berücksichtigenden Konfigurationsobjekte erforderlich sowie die notwendigen 

Parameter zur Meldungserstellung (Glättungsparameter, Prioritäten der Störfallsituation in Abhängigkeit 

der ermittelten Güte, Abbildung der Störfallsituationen auf TMC-Ereignisse). 

Die detaillierte Auflistung der Attributgruppen, die als Eingangsdaten verarbeitet werden, ist in 

der Schnittstellenbeschreibung ([SSB]) aufgeführt. 

5.1.3.2.2.2 Ausgangsinformation 

Als Ausgangsdaten liefert die SW-Einheit die automatisch generierten Verkehrswarndienstmeldungen 

(und deren Aufhebung) im systeminternen Format. Die Alert-C Kodierung 

und der Versand zur Landesmeldestelle erfolgt in der SW-Einheit "LMS" (s. [TAnfKEx]). 

Die Auflistung der Attributgruppen, die diese SW-Einheit liefert, ist in der Schnittstellenbeschreibung 

([SSB]) aufgeführt. 

5.1.4 Qualitätsforderungen 

TSte-9 

Schnittstelle 

RDSTMC - 

Applikation 

5.1.4.1 Kritikalität 

Es gelten die Anforderungen des Segments gemäß Kapitel 4.4.1 "Kritikalität". 

5.1.4.2 Technische Anforderungen der IT-Sicherheit 

Es gelten die Anforderungen des Segments gemäß Kapitel 4.4.2 "Technische Anforderungen 

der IT-Sicherheit". 

5.1.4.3 Technische Anforderungen an sonstige Qualitätsmerkmale 

Es gelten die Anforderungen des Segments gemäß 4.4.3 "Technische Anforderungen an sonstige 

Qualitätsmerkmale". 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 18 

von 24 Seiten 






5.1.5 Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung 

Es gelten die Anforderungen des Segments gemäß Kapitel 4.5 "Technische Anforderungen an 

die Entwicklungs- und SWPÄ-Umgebung". 

5.2 Technische Anforderungen an die SW-Einheit "RDS/TMC Verwaltung" 




RDS/TMC Verwaltung 


Die RDS/TMC Verwaltung nimmt die von der VRZ (RDS/TMC Meldungserstellung) bzw. von 

Bedienern (BuV) für den Verkehrswarndienst generierten Verkehrsmeldungen im systeminternen 

Format über die Datenverteiler-Schnittstelle entgegen. Sie verwaltet, ob und wann die entgegengenommene 

Meldung unter dem Aspekt "senden" publiziert und damit über die SW- 

Einheit LMS (s.a. [TAnfKEx]) an die Landesmeldestelle versendet wird. 

Parameter 

Alert-C kodierte 

Meldungen 

RDS/TMC 

Meldungserstellung 

generiert 

RDS/TMC 

Verwaltung 

senden 

KEx 

LMS 

LMS 

generiert 

bearbeitet 

versendet 

empfangen 

BuV 

Abbildung 5-4: Informationsfluss " RDS/TMC Verwaltung" 

Die SW-Einheit RDS/TMC Verwaltung nimmt folgende Aufgaben wahr: 

• Entgegennahme von neuen, aktualisierten und aufgehobenen Meldungen, die in der VRZ 

automatisch generiert oder von Bedienern eingegeben wurden, über die Datenverteiler- 

Schnittstelle. 

• Löschen der entsprechenden Konfigurationsobjekte bei Aufhebungsmeldungen und Aktualisierung 

der entsprechenden Konfigurationsmengen. 

• Verwaltung der Verkehrswarndienstmeldungen hinsichtlich der Weitergabe an die Landesmeldestelle 

über die SW-Einheit "LMS" aufgrund von Interaktionen der Bedienung (s.u.) 

5.2.2.1 Interaktion mit der Bedienung 

Um den Bedienern des Systems eine Einflussnahme beim Versenden von automatisch generierten 

Meldungen zu geben, werden diese Meldungen verzögert (parametrierbare Zeiten für die 

Weiterleitung von Verkehrswarndienstmeldungen und die Weiterleitung von Aufhebungen) an 

die SW-Einheit "LMS" und damit an die Landesmeldestelle weitergegeben. Über die Bedienung 

kann gesteuert werden, ob eine Meldung sofort, gar nicht oder mit verändertem Inhalt versendet 

TSte-10 

Zeitverzögerung 

zur Beeinflussung 

durch Bediener 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 19 

von 24 Seiten 






werden soll. Außerdem können über die Bedienung auch neue zu versendende Meldungen 

(und Aufhebungen) erzeugt werden. 

Zu den Konfigurationsobjekten für die neuen Verkehrswarndienstmeldungen werden folgende 

Informationen benötigt: 

Meldungsquelle 

• Automatik 

Die Meldung wurde automatisch erzeugt. Aspekt "generiert" 

• Manuell 

Die Meldung wurde durch einen Benutzer eingegeben. Aspekt "bearbeitet" 

Meldungstatus 

quittiert 

editiert 

verworfen 

Die automatisch erzeugte Meldung wurde quittiert, d.h. ein Bediener hat die 

Meldung bestätigt und damit veranlasst, dass diese sofort ohne Beachtung einer 

eventuellen Zeitverzögerung verschickt wird. 

Die Meldung wurde durch einen Bediener editiert. Editierte Meldungen werden 

sofort verschickt. Eventuelle Aktualisierungen der Meldung durch die Automatik 

werden ignoriert; d.h. sie werden nicht weitergeleitet. 

Die Meldung wurde durch einen Bediener verworfen. Eventuelle Aktualisierungen 

der Meldung durch die Automatik werden ignoriert; d.h. sie werden 

nicht weitergeleitet. 

5.2.2.2 Abläufe 

Wenn die Meldung bereits unter dem Aspekt "senden" verteilt wurde, wird eine 

Aufhebung zu der Meldung generiert. 

Wenn innerhalb der parametrierten Zeitverzögerung bei der automatischen Meldungserstellung 

eine Aktualisierung eintrifft, wird die Weiterleitung der vorherigen Meldung unterdrückt (d.h. die 

Verkehrswarndienstmeldung wird nicht unter dem Aspekt "senden" publiziert). Die aktuell vorliegende 

Meldung wird wieder der Zeitverzögerung unterworfen. Falls noch keine Meldung zu 

dem entsprechenden Konfigurationsobjekt weitergeleitet wurde und als Aktualisierung zu dieser 

Meldung eine Aufhebung vorliegt werden beide Meldungen unterdrückt. 

5.2.2.2.1 Annahme einer Meldung unter dem Aspekt "generiert" 

Wenn zu dem entsprechenden Konfigurationsobjekt bereits ein Timer vorliegt, wird der Timer 

wieder mit der parametrierten Zeitverzögerung initialisiert und die bisherige Meldung durch die 

aktuelle Meldung ersetzt. Falls noch kein Timer zu dem entsprechenden Konfigurationsobjekt 

vorliegt wird ein neuer Timer angelegt und mit der parametrierten Zeitverzögerung initialisiert. 

Nach Ablauf des Timers wird die aktuelle automatisch erzeugte Meldung unter dem Aspekt 

"senden" verteilt, falls zu dem entsprechenden Konfigurationsobjekt keine Meldung unter dem 

Aspekt "bearbeitet" vorliegt, die als Status "editiert" oder "verworfen" hat. Wenn es sich bei der 

Meldung um eine Aufhebung handelt, wird das entsprechende Konfigurationsobjekt nach dem 

Versand der Meldung gelöscht. 

5.2.2.2.2 Annahme einer Meldung unter dem Aspekt "bearbeitet" 

An dieser Stelle muss unterschieden werden, ob die Quelle der Meldung die automatische Meldungserzeugung 

oder eine manuelle Vorgabe ist. 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 20 

von 24 Seiten 






Meldungsquelle "Automatik" 

Wenn der Status der Meldung "quittiert" ist, wird die zu dem entsprechenden Konfigurationsobjekt 

vorliegende aktuelle Meldung sofort unter dem Aspekt "senden" verteilt. 

Wenn der Status der Meldung "editiert" ist, wird die Meldung sofort unter dem Aspekt "senden" 

verteilt. 

Wenn der Status der Meldung "verworfen" ist, werden für den Fall, dass zu diesem Konfigurationsobjekt 

noch keine Meldung unter dem Aspekt "senden" verteilt wurde, alle nachfolgend automatisch 

generierten Meldungen unterdrückt, d.h. nicht unter dem Aspekt "senden" verteilt. 

Falls bereits eine Meldung verteilt wurde, wird zu dieser Meldung eine Aufhebung verteilt. 

Meldungsquelle "Manuell" 

Alle manuell erstellten Meldungen werden sofort unter dem Aspekt "senden" verteilt. Als Meldungsstatus 

ist in Zusammenhang mit den manuell erstellten Meldungen neben der neu erstellten 

Meldung der Status "editiert" und "verworfen" möglich. Wenn als Status "verworfen" gesetzt 

ist, wird zu dem entsprechenden Konfigurationsobjekt eine Aufhebung erzeugt und das entsprechende 

Konfigurationsobjekt gelöscht. 


5.2.3.1 Technische Anforderungen an die Nutzerschnittstelle 

Die Verwaltung der RDS/TMC-Verkehrswarndienstmeldungen hat keine eigene Nutzerschnittstelle. 

5.2.3.2 Technische Anforderungen an andere Schnittstellen 

Die SW-Einheit besitzt folgende Schnittstellen (entsprechend den Festlegungen in der 

[SysArc]). 

• Datenverteiler Applikationsfunktionen – Applikation 

(Schnittstelle zur SW-Einheit "Datenverteiler-Applikationsfunktionen" siehe Segment 

[TAnfDaV]) 

• RDSTMCVerwaltung – Starter 

(Aufrufschnittstelle der Applikation) 

• RDSTMCVerwaltung – Applikation 

(logische Schnittstelle zu anderen Applikationen) 

5.2.3.2.1 RDSTMCVerwaltung – Starter 

Die SW-Einheit stellt im Sinne der Festlegungen der Systemarchitektur eine Applikation dar und 

verfügt damit über mehrere benannte Aufrufparameter, mit denen sich das (Start-) Verhalten 

der Applikation in bestimmten Bereichen einstellen lässt. Neben den in Kapitel 4.3.1 

"Technische Anforderungen an die Nutzerschnittstelle" aufgeführten Aufrufparameter sind folgende 

Parameter zu unterstützen: 

-lms=konfigurationsobjekt 

Über diesen Parameter wird die pid oder id der Landesmeldestelle 

festgelegt, für die Verkehrswarndienstmeldungen erzeugt 

werden. 

TSte-11 

Schnittstelle 

RDSTMC- 

Verwaltung - 

Starter 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 21 

von 24 Seiten 






5.2.3.2.2 RDSTMCVerwaltung – Applikation 

Logische Schnittstelle, die unter Nutzung der Datenverteilerschnittstelle realisiert ist und durch 

die Beschreibung der ausgetauschten Daten und eventuell notwendiger Abläufe beim Datenaustausch 

spezifiziert wird. 

5.2.3.2.2.1 Eingangsinformationen 

Eingangsinformationen sind die von der VRZ (RDS/TMC Meldungserstellung) bzw. von Bedienern 

(BuV) für den Verkehrswarndienst generierten Verkehrsmeldungen im systeminternen 

Format. 

Neben den Meldungen sind als konfigurierende Eingangsdaten die Mengen der zu berücksichtigenden 

Konfigurationsobjekte sowie als Parameter die Verzögerungszeiten für automatisch 

erzeugten Verkehrswarndienstmeldungen und deren Aufhebungen erforderlich. 

Die detaillierte Auflistung der Attributgruppen, die als Eingangsdaten verarbeitet werden, ist in 

der Schnittstellenbeschreibung ([SSB]) aufgeführt. 

5.2.3.2.2.2 Ausgangsinformation 

Als Ausgangsdaten liefert die SW-Einheit Verkehrswarndienstmeldungen (und deren Aufhebung) 

im systeminternen Format unter dem Aspekt "senden". Die Alert-C Kodierung und der 

Versand zur Landesmeldestelle erfolgt in der SW-Einheit "LMS" (s. [TAnfKEx]). 

Die Auflistung der Attributgruppen, die diese SW-Einheit liefert, ist in der Schnittstellenbeschreibung 

([SSB]) aufgeführt. 


TSte-12 

Schnittstelle 

RDSTMC- 

Verwaltung - 

Applikation 

5.2.4.1 Kritikalität 

Es gelten die Anforderungen des Segments gemäß Kapitel 4.4.1 "Kritikalität". 

5.2.4.2 Technische Anforderungen der IT-Sicherheit 

Es gelten die Anforderungen des Segments gemäß Kapitel 4.4.2 "Technische Anforderungen 

der IT-Sicherheit". 

5.2.4.3 Technische Anforderungen an sonstige Qualitätsmerkmale 

Es gelten die Anforderungen des Segments gemäß 4.4.3 "Technische Anforderungen an sonstige 

Qualitätsmerkmale". 

5.2.5 Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung 

Es gelten die Anforderungen des Segments gemäß Kapitel 4.5 "Technische Anforderungen an 

die Entwicklungs- und SWPÄ-Umgebung". 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 22 

von 24 Seiten 






5.3 Technische Anforderungen an die SW-Einheit "Nässestufen" 




Nässestufen 


Zu ergänzen. 


Zu ergänzen. 


Zu ergänzen. 

5.4 Technische Anforderungen an die SW-Einheit "Helligkeitssteuerung" 




Helligkeitssteuerung 


Zu ergänzen. 


Zu ergänzen. 


Zu ergänzen. 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 23 

von 24 Seiten 





Anforderungsverzeichnis 

6 Anforderungsverzeichnis 

TSte-1 Versorgung der Ausdehnung pro MQ....................................................................................................................13 

TSte-2 Plausibilisierung durch die Stauverlaufsanalyse ...................................................................................................13 

TSte-3 Berücksichtigung der Stauobjekte .........................................................................................................................14 

TSte-4 Keine Längenzuordnung Option 1.........................................................................................................................14 

TSte-5 Keine Längenzuordnung Option 2.........................................................................................................................14 

TSte-6 Anlegen von Konfigurationsobjekten .....................................................................................................................15 

TSte-7 Erklärungskomponente Baustelle..........................................................................................................................16 

TSte-8 Schnittstelle RDSTMC - Starter .............................................................................................................................17 

TSte-9 Schnittstelle RDSTMC - Applikation ......................................................................................................................18 

TSte-10 Zeitverzögerung zur Beeinflussung durch Bediener............................................................................................19 

TSte-11 Schnittstelle RDSTMCVerwaltung - Starter.........................................................................................................21 

TSte-12 Schnittstelle RDSTMCVerwaltung - Applikation ..................................................................................................22 

Stand: 08.10.2004 

SE-02.07.00.00.00-TAnf 


Version: 2.0 


Seite 24 

von 24 Seiten

AK VRZ - NERZ eV

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?