Dokumenten-Kontrollblatt · X1.0 15.5.2013 E. ImhofUrversion erstellt X1.01 25.6.2013 E. ImhofEinarbeitung von Review - Kommentaren in al- ... Das vorliegende Lastenheft gilt für

Geschäftseinheit I-ZBFSystemführerschaft ETCS System

Generisches Lastenheft Online Monitoring auf ETCS Fahrzeuge / © bei SBB Seite 2 / 2913_LH_OnlineMonitoringSystem_V1_2.doc V1.2 15.07.2013

Dokumenten-KontrollblattInhalt Lastenheft mit den Forderungen an ein zusätzliches System zur

ETCS-Fahrzeugausrüstung um streckenseitige Störungen anETCS-Komponenten (Balisen, LEU, Loop, usw) zu erkennen sowieGutmeldungen zu erzeugen und über einen Übertragungskanal anden Störmelderechner der Infrastruktur zu senden.

Ersteller Erich Imhof

Wordprozessor Microsoft Word 2010

Filename 13_LH_OnlineMonitoringSystem_V1_2.doc

Status des Dokuments In Bearbeitung / in Review / freigegeben

Verteiler BAV (Bundesamt für Verkehr)

Urheberrecht (Schutzvermerk ISO 16016)Das Urheberrecht für das durch das BAV veröffentlichte Dokument der Systemführerschaft ETCSCH ist so zu verstehen, dass die Weitergabe, die Vervielfältigung etc. ausdrücklich gestattet sind.

Änderungsnachweise

Version Datum Ersteller Änderungshinweise

X1.0 15.5.2013 E. Imhof Urversion erstellt

X1.01 25.6.2013 E. Imhof Einarbeitung von Review - Kommentaren in al-len Kapiteln

X1.02 26.6.2013 E. Imhof Kleine Anpassungen in Kapiteln 5.2, 5.5, 5.6und 5.7. Input aus Q – Review, Review BAVund Review Systemführer.

V1.1 1.7.2013 E. Imhof Erste Version erstellt

V1.2 15.7.2013 E. Imhof Korrekturen des BAV eingearbeitet.Änderungen in den Kapiteln 2, 4.4, 5.5, 5.7



Inhalt

1 Ziel 7

2 Randbedingungen 7

3 Systemanwendungsfälle (use cases) 7

3.1 Störungsmeldungen erstellen 7

3.2 Gutmeldungen erstellen 7

3.3 Meldungen temporär aufzeichnen 7

3.4 Online Monitoring System konfigurieren 7

4 Systemabgrenzung 8

4.1 Kontext für ETCS Level 1 8

4.2 Kontext für ETCS Level 2 9

4.3 Externe Systeme 10

4.4 Schnittstellen 11

5 Anforderungen 12

5.1 Erwartete Informationen von externen Systemen 12

5.2 Funktionale Anforderungen Störungsmeldungen 13

5.3 Funktionale Anforderungen Gutmeldungen 18

5.4 Anforderungen ans GSM/ GSM-R Interface und ans FZPF-Z Interface 19

5.5 Konfiguration des Algorithmus für Gutmeldungen 20

5.6 Verarbeitung von Störungs- und Gutmeldungen bei Verbindungsunterbruch 21

5.7 Allgemeine Anforderungen 22

6 Datenformat für Meldungen am FZPF-Z Interface 24

7 Telegrammaufbau STOEST 26

8 Telegrammaufbau SIGSTO 28



AbbildungenAbbildung 1 Kontext ETCS Level 1 8

Abbildung 2 Kontext ETCS Level 2 9

Abbildung 3 Paket 254 17



Abkürzungen

BAV Bundesamt für Verkehr

CRC Cyclic redundacy check. Definierte Checksummenberechnung nach CCITT

EOLM End Of Loop Marker

ERA European Railway Agency

ERTMS European Rail Traffic Management System

ETCS European Train Control System

FZ Fahrzeug

FZPF Fahrzeugplattform

FZPF-Z Fahrzeugplattform Zentralrechner

GSM-R Global System for Mobile Communications - Rail(way)

LEU Lineside Electronic Unit (Vereinfachter Signaladapter und Telegrammcodierer)

MiniLEU Mini Lineside Electronic Unit (Vereinfachter Signaladapter und Telegrammcodie-rer)

MTBF Mean Time Between Failures. Ein Mass für die Zuverlässigkeit eines Gerätes

OBU On Board Unit. ETCS Fahrzeugausrüstung

RBC Radio Block Center

SA Sicherungs – und Automationsanlage

SF Systemführer ETCS

SIGSTO Telegrammname für Signalstörung

SIL Safety Integrity Level

SMS Short Message Service

SRS System Requirement Specification

STD Standard

STOEST Telegrammname für Stoerungsmeldung

USB Universal Serial Bus

XML Extensible Markup Language

ZUB Klassisches CH-Zugsbeeinflussungsgerät, welches fahrzeugseitig installiert wird

ZUBE Zugbeeinflussung



Referenzen

[1] I-AT-ZBF Z43; Projektierungsregeln LEU, Eurobalisen und Euroloops für Zugbeeinflussung;SBB AG

[2] SRS SUBSET-026 Version 2.3.0d, d.h. SUBSET-026 Version 2.3.0 und SUBSET-108 Version1.2.0.

[3] SRS SUBSET-026 Version 3.3.0

[4] 08_PL1LS_SYS_RegelnL1LS_V13; Projektierungsregeln Level 1 LS, V1.3 08.11.2011; SBBAG

Anforderungstypen

Muss – Anforderung [M] Eine Muss – Anforderung ist erkennbar an der speziellen Be-zeichnung M.Die Anforderung muss zwingend umgesetzt werden. Sie ent-hält die Verben „muss“ oder „darf nicht“

Sollte – Anforderung [S] Eine Sollte – Anforderung ist erkennbar an der speziellen Be-zeichnung S.Die Anforderung muss nicht zwingend umgesetzt werden undentspricht einer Empfehlung. Sie enthält die Verben „kann“oder „sollte“.

Informations – Anforderung [I] Eine Informations – Anforderung ist erkennbar an der speziel-len Bezeichnung I.Sie stellt eine Information dar, die keinerlei Verbindlichkeit imSinne einer Anforderung aufweist.

Geschäftseinheit I-ZBFSystemführerschaft ETCSLastenheft Online Monitoring System


1 ZielMit dem vorliegenden Lastenheft sollen die notwendigen Anforderungen an die Fahrzeugausrüs-tung zur Überwachung der streckenseitigen ETCS Komponenten auf dem Normalspurnetz derSchweiz spezifiziert werden.

2 RandbedingungenDas vorliegende Lastenheft gilt für Fahrzeuge welche über eine ETCS Ausrüstung verfügen, un-abhängig davon ob noch nationale Zugbeeinflussungssysteme (ZUB, Signum, ETM) installiertsind:

3 Systemanwendungsfälle (use cases)

3.1 Störungsmeldungen erstellenDas Online Monitoring System erkennt Fehlermeldungen von Balisen, LEU und LEU-Interface so-wie vom EuroLoop via ETCS Fahrzeugausrüstung und stellt diese als Störungsmeldung einemortsfesten Auswertesystem zur Verfügung.

3.2 Gutmeldungen erstellenDas Online Monitoring System erkennt korrekte Meldungen von Balisen via ETCS Fahrzeugaus-rüstung und erstellt Gutmeldungen. Die Gutmeldungen sendet das Online Monitoring System mitHilfe eines Algorithmus mit statistischen Auswahlverfahren an ein ortsfestes Auswertesystem.Eine Gutmeldung sagt dabei nur aus, dass eine Balise fehlerfrei gelesen wurde. Inhalte der gele-senen Informationen werden hier nicht betrachtet.

3.3 Meldungen temporär aufzeichnenDas Online Monitoring System speichert Störungsmeldungen und Gutmeldungen temporär lokalab, falls der Übertragungskanal zum ortsfesten Auswertesystem ausgefallen sein sollte. Bei Wie-derherstellung des Übertragungskanals sendet das Online Monitoring System die temporären Auf-zeichnungen an das ortsfeste Auswertesystem. Dieser Anwendungsfall gilt für die Absetzung vonMeldungen via GSM/ GSM-R Interface. Bei Absetzung über das FZPF-Z Interface übernimmt dasFZPF-Z System diese Aufgabe.

3.4 Online Monitoring System konfigurierenDer Verantwortliche für die Streckenausrüstung konfiguriert am Online Monitoring System auf demFahrzeug die Einstellungen für das statistische Auswahlverfahren von Gutmeldungen.

Angaben zum resultierenden ProzessDer SF kann die Einstellungen für den zu verwendenden Algorithmus anpassen. Der Fahrzeughal-ter wird darüber rechtzeitig informiert und hat in einer geeigneten Frist diese Anpassung umzuset-zen.



4 Systemabgrenzung

4.1 Kontext für ETCS Level 1

Abbildung 1 Kontext ETCS Level 1

Online Monitoring System FZ

Ortsfestes Aus-

wertesystem

FZPF-Z

Festdaten-

balise

Transparentda-

tenbalise

EuroLoop

LEU

Optische Signalisierung,

Stellwerk

Konfigurationssys-

tem

STDInterface

GSM/ GSM-R Interface

FZPF-ZInterface

ETCS FZ Interface

ETCS FZ AusrüstungFahrzeugleit-

technik

Leittechnik Interface



4.2 Kontext für ETCS Level 2

Abbildung 2 Kontext ETCS Level 2

Online Monitoring System FZ

Ortsfestes Aus-

wertesystem

FZPF-Z

Festdaten-

balise

Konfigurationssys-

tem

ETCS FZ Ausrüstung

GSM/ GSM-RInterface

FZPF-ZInterface

ETCS FZ Interface

STDInterface

Fahrzeugleit-

technik

Leittechnik Interface



4.3 Externe Systeme

ETCS FZ Ausrüstung Fahrzeugseitige Ausrüstung zum Betrieb der Zugsbeeinflus-sung nach dem ETCS Standard. Die Einrichtung liefert demOnline Monitoring System verschiedenste Informationen.

Festdatenbalise, Transparent-datenbalise, EuroLoop, LEU,Signalisierung

Bestehende Infrastruktur auf dem Schienennetz

Ortsfestes Auswertesystem Einrichtung, welche die Störungsmeldungen und Gutmeldun-gen sammelt und eine Übersicht der Fehler auf der Strecken-einrichtung darstellen soll.

FZPF-Z Rechner auf dem Fahrzeug. Er sorgt für eine Schnittstelle zwi-schen Online Monitoring System und ortsfestem Auswertesys-tem.

Konfigurationssystem Ein externes System mit dem der Algorithmus der statistischenAuswahl der Gutmeldungen eingestellt werden kann.

Fahrzeugleittechnik System auf dem Fahrzeug, das Informationen zum Fahrzeug(Fahrzeugnummer, aktiver Führerstand, Fahrzeugtyp,…) zurVerfügung stellen kann.



4.4 Schnittstellen

ETCS FZ Interface Die ETCS Fahrzeugausrüstung stellt dem Online MonitoringSystem wichtige Informationen zur Verfügung:

· Informationen von und über Balisen· Informationen von Balisen betreffend Loop, LEU, Mi-

niLEU· Zeit, Datum· Zugnummern

GSM/ GSM-R Interface Interface zum ortsfesten Auswertesystem. Hier sollen Stö-rungs- und Gutmeldungen als SMS via GSM/ GSM-R Voiceabgesetzt werden.

FZPF-Z Interface Alternative drahtgebundene Schnittstelle zum FZPF – ZRechner. Hier können ebenfalls Störungs- und Gutmeldungenabgesetzt werden mittels Filetransfer. Die physikalische Ver-bindung ist nicht vorgegeben.

STD Interface Schnittstelle, welche eine Konfiguration des Algorithmus fürGutmeldungen ermöglicht.

Es handelt sich hier idealerweise um eine schon bestehendeSchnittstelle der Fahrzeugausrüstung zur Umwelt.

Leittechnik Interface Die Fahrzeugleittechnik kann dem Online Monitoring Systemwichtige Informationen zur Verfügung stellen

· Lok Baureihe· Fahrzeugnummer· Aktiver Führerstand



5 Anforderungen

5.1 Erwartete Informationen von externen SystemenDamit das Online Monitoring System seine Aufgabe erfüllen kann, müssen andere Systeme aufdem Fahrzeug bestimmte Daten und Informationen zur Verfügung stellen.

Nr. Anforderung Typ

5.1.1.1 Erwartete Informationen von der ETCS FZ AusrüstungDas Online Monitoring System muss von der ETCS Fahrzeugausrüstung diver-se Informationen zur Umsetzung der geforderten Funktionalität erhalten, insbe-sondere :

· Empfangene Baliseninformationen· M_ERROR· Zugnummer (NID_OPERATIONAL)· Uhrzeit / Datum der ETCS Fahrzeugausrüstung gemäss [2][3]

Referenzen[2][3] SRS Definition von Baliseninformationen

M

5.1.1.2 Erwartete Informationen von anderen SystemenEs muss im Rahmen des jeweiligen Projekts mit dem Besteller geklärt werden,ob die folgenden Informationen im Online Monitoring System implementiert (ein-stellbar mit Konfigurationssystem) oder von Drittsystemen (z.B. Fahrzeugleit-technik) bezogen werden.

· Lok Baureihe· Fahrzeugnummer· Variable "Aktiver Führerstand"

M



5.2 Funktionale Anforderungen StörungsmeldungenDie Anforderungen in diesem Kapitel beziehen sich auf Funktionalität, bzw. Informationen betref-fend Störungsmeldungen, die das GSM/ GSM-R Interface und das FZPF-Z Interface gegenüberden externen Systemen anbieten.

Nr. Anforderung Typ

5.2.1.1 Telegramm / Telegramme einer Balisengruppe mit inkonsistentem InhaltDas Online Monitoring System muss M_ERROR auf inkonsistente Balisengrup-pen prüfen.

Fall c) Variables in the balise group have invalid values

Referenz zu c) : Kapitel 3.16.2.4.1, 3.16.2.4.4, 3.16.2.5.1 [2][3]

Wenn das Online Monitoring System von der ETCS Fahrzeugausrüstung Infor-mationen betreffend einer Balise mit inkonsistentem (nicht plausiblem) Inhalterhält, muss es ein Telegramm STOEST zusammenstellen mit den unten ste-henden Inhalten:

Zeit: Uhrzeit, Datum der ETCS FZ AusrüstungBalisengruppen ID: 5-stellige Nummer gemäss Variable NID_BG (siehe [2][3]

Kapitel 7.5.1.85)Fehlernummer: 2-stellige Nummer, wobei die 10er Stelle eine "4" ist und

die 1er Stelle der Variable N_PIG +1 der betroffenen feh-lerhaften Balise entspricht.Bei einer 2er Balisengruppe sind also die Fehlernummern"41" und "42" möglich.

BemerkungDas Online Monitoring System kann nur STOEST Telegramme zusammenstel-len, wenn von einer Balisengruppe mindestens eine Balise korrekt gelesen wer-den konnte.

ReferenzenKapitel 7 Telegrammaufbau STOEST

M



5.2.1.2 Balise einer Balisengruppe fehlt oder ist fehlerhaftDas Online Monitoring System muss M_ERROR auf inkonsistente Balisengrup-pen prüfen.

a. A balise is missed inside the group

b. A balise is detected, but no telegram is decoded (wrong CRC)

Referenz zu a) und b): Kapitel 3.16.2.4.1, 3.16.2.4.4, 3.16.2.5.1 [2][3]

Wenn das Online Monitoring System von der ETCS Fahrzeugausrüstung eineBalisengruppe gelesen hat, muss das Online Monitoring System für jede fehlen-de oder fehlerhaft gelesene Balise der Gruppe eine Störungsmeldung absetzen:

Inhalt Telegramm STOESTZeit: Uhrzeit, Datum der ETCS FZ AusrüstungBalisengruppen ID: 5-stellige Nummer gemäss Variable NID_BG (siehe [2][3]

Kapitel 7.5.1.85)Fehlernummer: 2-stellige Nummer, wobei die 10er Stelle eine "5" ist und

die 1er Stelle der Variable N_PIG +1 fehlenden Baliseentspricht.Bei einer 2er Balisengruppe sind also die Fehlernummern"51" und "52" möglich

ReferenzenKapitel 7 Telegrammaufbau STOEST

M

5.2.1.3 Aktivierung FührerstandWenn das Online Monitoring System bei der ersten gelesenen Balisengruppenach dem Aufrüsten und nach dem Wenden des Fahrzeugs fehlende oder feh-lerhafte Balisen feststellt, dann darf das Online Monitoring System keine Stö-rungsmeldung zu dieser Balisengruppe absetzen.

M

5.2.1.4 LEU-StörungWenn das Online Monitoring System von der ETCS Fahrzeugausrüstung dieInformation M_MCOUNT mit Wert 128 erhält, muss das Online Monitoring Sys-tem ein Telegramm SIGSTO zusammenstellen und an die ortsfeste Auswer-teeinrichtung senden. Es darf dabei Paket 254 nicht auswerten (siehe [4]).

Inhalt Telegramm SIGSTOZeit: Uhrzeit, Datum der ETCS FZ AusrüstungBalisengruppen ID: 5-stellige Nummer gemäss Variable NID_BG (siehe [2][3]

Kapitel 7.5.1.85)Fehlernummer: 2-stellige Nummer mit dem Wert "34"

Referenzen[2][3], Kapitel 7.5.1.71Kapitel 8 Telegrammaufbau SIGSTO

M



5.2.1.5 Störung am Interface Signalabgriff – LEUWenn das Online Monitoring System von der ETCS Fahrzeugausrüstung dieInformation M_MCOUNT mit Wert 127 erhält, muss das Online Monitoring Sys-tem ein Telegramm SIGSTO zusammenstellen und an die ortsfeste Auswer-teeinrichtung senden. Es darf dabei Paket 254 nicht auswerten (siehe [4]).




M

5.2.1.6 Loop-StörungWenn das Online Monitoring System auf Grund der Inhalte des EOLM Pakete134 nach der mitgelieferten Distanz zum Loop über die mitgelieferte Länge desLoops keine Loopinformationen gelesen hat, muss das Online Monitoring Sys-tem ein Telegramm STOEST zusammenstellen und an die ortsfeste Auswer-teeinrichtung senden.




M



5.2.1.7 MiniLEU-StatusmeldungenWenn das Online Monitoring System von der ETCS Fahrzeugausrüstung dieInformation M_MCOUNT mit Werten von 129 bis 140 erhält, muss das OnlineMonitoring System ein Telegramm SIGSTO zusammenstellen und an die orts-feste Auswerteeinrichtung senden.


Kapitel 7.5.1.85)Fehlernummer: 2-stellige Nummer mit dem Wert "35" – "46"

Referenzen[2][3], Kapitel 7.5.1.71Kapitel 8 Telegrammaufbau SIGSTOZusammenhang M_MCOUNT zu Fehlernummer siehe Kapitel TelegrammaufbauSIGSTO

M



5.2.1.8 Empfang Paket 254Wenn das Online Monitoring System von der ETCS Fahrzeugausrüstung denInhalt eines Paket 254 ohne vorherigen Empfang eines M_MCOUNT Werteserhalten hat, dann muss das Online Monitoring System ein Telegramm SIGSTOzusammenstellen und an die ortsfeste Auswerteeinrichtung senden



Abbildung 3 Paket 254

ReferenzTelegrammaufbau STOEST

M

5.2.1.9 Störungsmeldungen im AuslandWenn das Online Monitoring System von der ETCS Fahrzeugausrüstung einPaket mit NID_C ausserhalb des Bereichs 448 – 454 erhält, dann darf das Onli-ne Monitoring System keine Störungsmeldung zu diesem Punkt absetzen.

Referenz[2][3], Kapitel 7.5.1.86

M

Start

M_MCOUNT ==127 bis 140 ?

Fehlernummer 33Bis 46 absetzenJA

Paket 254 ?

NEIN

Fehlernummer 34absetzenJA

Ende

NEIN



5.3 Funktionale Anforderungen GutmeldungenDie Anforderungen in diesem Kapitel beziehen sich auf Funktionalität, bzw. Informationen betref-fend Gutmeldungen, die das GSM/ GSM-R Interface und das FZPF-Z Interface gegenüber denexternen Systemen anbieten.

Nr. Anforderung Typ

5.3.1.1 Senden einer GutmeldungDas Online Monitoring System muss gemäss dem in 5.3.1.2 definierten Algorith-mus Gutmeldungen in Form eines Telegramms STOEST an das ortsfeste Aus-wertesystem senden.


Kapitel 7.5.1.85)Fehlernummer: 2-stellige Nummer mit dem Wert 98

ReferenzKapitel 7 Telegrammaufbau STOEST

M

5.3.1.2 Algorithmus für Gutmeldungen

Das Online Monitoring System muss die Gutmeldungen gemäss folgendem Algo-rithmus absetzen.

1. Nach einer abgesetzten Gutmeldung ermittelt das System durch die Wahl einerZufallszahl die Anzahl überfahrener Balisengruppen, bis erneut eine Gutmeldungabgesetzt wird.2. Es wird ein Bereich genommen, für den die Zufallszahl ermittelt wird: der Be-reich ist durch eine untere und eine obere Grenze definiert.3. Die Zufallszahl stellt sicher, dass der Abstand zwischen zwei abgesetztenGutmeldungen innerhalb des eingestellten Bereiches gleichverteilt ist.4. Die Zufallszahl innerhalb des Bereiches wird nach jeder gesendeten Gutmel-dung neu ermittelt.5. Nach Zustandsübergang der OBU vom Standby in einen Fahrmodus ist alsunterer Wert für den Zufalls-Bereich die Zahl 1 zu nehmen (also zum Beispiel beiBereich 25-30 dann 1-30 oder bei Bereich 90-100 dann 1 bis 100). Nachdem dieerste Gutmeldung gesendet wurde, wird dann wieder auf den definierten Bereich(25-30 oder 90-100) gewechselt.

M

5.3.1.3 Gutmeldungen im AuslandWenn das Online Monitoring System von der ETCS Fahrzeugausrüstung ein Pa-ket mit NID_C ausserhalb des Bereichs 448 – 454 erhält, dann darf das OnlineMonitoring System keine Gutmeldungen zu diesem Punkt absetzen.

Referenz[2][3], Kapitel 7.5.1.86

M



5.4 Anforderungen ans GSM/ GSM-R Interface und ans FZPF-Z Inter-face

Die Anforderungen in diesem Kapitel beziehen sich auf allgemeine Aspekte und nichtfunktionaleAnforderungen, die sich auf das GSM/ GSM-R Interface und das FZPF-Z Interface beziehen.

Nr. Anforderung Typ

5.4.1.1 Absetzen von Störungs– und GutmeldungenDas Online Monitoring System muss seine Meldungen entweder direkt über GSM/GSM-R oder via FZPF-Z Interface absetzen.

M

5.4.1.2 Datenformate am GSM/ GSM-R InterfaceDie Störungs – und Gutmeldungen müssen als SMS gemäss Anhang dieses Do-kuments gesendet werden.Der Aufbau der Störungs – und Gutmeldungen (STOEST und SIGSTO) ist ge-mäss Kapitel 7 und Kapitel 8 definiert

M

5.4.1.3 Datenformate am FZPF-Z InterfaceDie Störungs – und Gutmeldungen müssen als XML Datei gemäss Kapitel 6 ge-sendet werden.Der Aufbau der Störungs – und Gutmeldungen (STOEST und SIGSTO) ist ge-mäss Kapitel 7 und Kapitel 8 definiert

M

5.4.1.4 Filenamen XML Meldungen am FZPF-Z InterfaceDas Online Monitoring System muss die XML Meldungen an die FZPF-Z als Fileübermitteln. Die Dateiendung des Files ist *.xml. Der Filename muss folgendesFormat aufweisen:

ZUB_<Baureihe>_<Fahrzeugnummer>_<Führerstand>_<Datum>_<Zeit>_<Laufnummer>Baureihe: Baureihe der Lok, 4-stelliger ASCII StringFahrzeugnummer: 4-stelliger ASCII StringFührerstand: 1-stelliger ASCII Character ("1“ oder "2“) .Datum: 8-stelliger String: JJJJ,MM,TTZeit: 6-stelliger String: HH,MM,SSLaufnummer: 1 stelliger ASCII Character "0" …. "9"

BeispielRe460 mit Nummer 075 am 28.02.2010 um 23.27:30 mit Laufnummer 5 (Führer-stand für RE460 = 1 oder 2, im Beispiel hier 1):

Der Filename ist ZUB_0460_0075_1_20100228_232730_5.xml

M



5.5 Konfiguration des Algorithmus für GutmeldungenDie Anforderungen in diesem Kapitel beziehen sich auf Funktionalität, bzw. Informationen betref-fend Konfiguration des Algorithmus für Gutmeldungen

Nr. Anforderung Typ

5.5.1.1 Konfiguration des GutmeldealgorithmusDie Parameter des Gutmeldealgorithmus müssen in folgendem Wertebereich kon-figurierbar sein.

Untere Grenze : 1 - 200Obere Grenze : 1 - 200

M

5.5.1.2 Einstellung der GrenzwerteDas Online Monitoring System muss prüfen, dass der Wert der oberen Grenzeimmer gleich oder höher ist als der Wert der unteren Grenze.

M



5.6 Verarbeitung von Störungs- und Gutmeldungen bei Verbindungsun-terbruch

In diesem Kapitel sind alle Anforderungen gesammelt zu der Funktion der temporären lokalenSpeicherung von Störungs- und Gutmeldungen im Falle eines Verbindungsunterbruchs der Funk-verbindung auf der FZPF-Z oder am GSM/ GSM-R Interface.

Nr. Anforderung Typ

5.6.1.1 Lokale Aufzeichnung von Störungs- und Gutmeldungen bei Verbindungsun-terbruch am GSM/GSM-R InterfaceDer Übertragungskanal zum GSM/ GSM-R Interface muss einen Unterbruch derFunkverbindung feststellen können.Wenn der Übertragungskanal zum GSM/ GSM-R Interface einen Unterbruch derFunkverbindung feststellt, dann muss der Übertragungskanal alle sendebereitenStörungs- und Gutmeldungen lokal zwischenspeichern.

M

5.6.1.2 DatenmengeDer Übertragungskanal zum GSM/ GSM-R Interface muss 20 Störungs- bzwGutmeldungen zwischenspeichern können. Wenn die Speicherkapazität ausge-schöpft ist, darf der Übertragungskanal die ältesten Meldungen überschreiben.

BemerkungMit 20 Meldungen kann eine Funkausfall von minimal 1 Stunde überbrückt wer-den.

M

5.6.1.3 Senden von aufgezeichneten MeldungenDer Übertragungskanal zum GSM/ GSM-R Interface muss einen Wiederaufbauder Funkverbindung feststellen können.Wenn der Übertragungskanal zum GSM/ GSM-R Interface wieder eine Funkver-bindung hat, und wenn während des Unterbruchs Meldungen aufgezeichnet wur-den, dann muss der Übertragungskanal die aufgezeichneten Meldungen über dasGSM/ GSM-R Interface absetzen.

M

5.6.1.4 Verhalten des FZPF-Z Systems bei VerbindungsunterbrüchenDas FZPF-Z System muss auf seinem Funkübertragungskanal zur ortsfestenAuswerteeinrichtung dieselbe Funktionalität aufweisen wie der Übertragungskanalzum GSM/ GSM-R Interface

BemerkungDas ist eine Anforderung an die FZPF-Z

I



5.7 Allgemeine AnforderungenNr. Anforderung Typ

5.7.1.1 Kompatibilität Fahrzeug – StreckeDas Online Monitoring System muss seine spezifizierte Funktionalität erfüllenkönnen auf Strecken mit Balisen mit M_VERSION X = 1 und X = 2.

M

5.7.1.2 Dokumentation zum Online Monitoring SystemFür das Online Monitoring System muss eine ausreichende Dokumentation vorlie-gen. Diese besteht mindestens aus den nachfolgenden Inhalten:

· Systembeschreibung· Kompatibilitätsübersicht zu OBU Softwareversionen· Historie zu allen Softwareversionen (Release Notes)· Anleitung zum Konfigurieren des Online Monitoring Systems

I

5.7.1.3 Fahrzeug im ETCS Level 0, 1 oder 2Während das Fahrzeug im ETCS Level 0, 1 oder 2 fährt, muss das Online Monito-ring System alle Störungsmeldungen und alle Gutmeldungen an die ortsfesteAuswerteeinrichtung senden

BemerkungUnter ETCS Level 2 fallen keine Meldungen betreffend Loop, LEU und MiniLEUan.

M

5.7.1.4 Dauer der VerarbeitungDie Verarbeitungszeit des Online Monitoring Systems vom Lesen der Basisi nfor-mationen bis zum Senden der Störungs – und Gutmeldungen über FZPF-Z Inter-face bzw. GSM/ GSM-R Interface darf nicht länger als 5 s dauern

BemerkungVoraussetzung ist die Verfügbarkeit des GSM/ GSM-R oder FZPF-Z Interfaces.

M

5.7.1.5 VerarbeitungstaktDas Online Monitoring System muss in der Lage sein, Balisentelegramme von derETCS Fahrzeugausrüstung mit minimalem zeitlichen Abstand von 0.029 s zu le-sen und zu verarbeiten

BemerkungBei einer maximalen Geschwindigkeit von 250km/h und einem minimalen Balisen-abstand von 2m liegen Telegramme mit zeitlichem Abstand von 0.029s an [1].

M

5.7.1.6 Sicherheitsanforderungsstufe (SIL)Die technische Implementation des Online Monitoring Systems muss keinem SILentsprechen.

I



5.7.1.7 SystemverfügbarkeitDas Online Monitoring System muss eine Verfügbarkeit von 99.9 % aufweisenunter Annahme einer 100% Verfügbarkeit des Übertragungskanals am GSM/GSM-R Interface oder am FZPF-Z Interface.

BemerkungDie geforderte Verfügbarkeit kann mit den üblichen MTBF von elektronischen Sys-temen erreicht werden.

M

5.7.1.8 Identifikation der ortsfesten AuswerteeinrichtungDie ortsfeste Auswerteeinrichtung ist bei der SBB Infrastruktur installiert. DieFahrzeugbetreiber können die notwendigen Zugangsinformationen zur ortsfestenAuswerteeinrichtung von SBB Infrastruktur beziehen.

I

5.7.1.9 Zugangsdaten zur ortsfesten Auswerteeinrichtung auf dem FahrzeugDas Online Monitoring System muss eine Möglichkeit zur Verfügung stellen, umdie Zugangsdaten zur ortsfesten Auswerteeinrichtung (Telefonnummer, IP Adres-se) programmieren zu können.Dies kann fest programmiert werden, oder via Konfigurationssystem konfiguriertwerden.

M



6 Datenformat für Meldungen am FZPF-Z Interface6.1.1.1 Die Störungs – und Gutmeldungen, die über das FZPF-Z Interface gesendet werden, müssen dem

unter stehenden Datenformat entsprechen.

Es entspricht dem XML Datenformat. Unter dem Feld „stoedat“ ist die eigentliche Störungs – oder Gutmel-dung zu finden.

<?xml version="1.0" encoding="UTF-8"?><StoerGutMeldungVersion="01.00"Zugnummer="2710"Reihe="1511"Fahrzeugnummer="0013"Fuehrerstand="1"Zeitstempel="2012-01-24T09:55:17.3+01:00"stoedat="rNS08415432133"></StoerGutMeldung>

Zeilen-Aufbau XML-Format Wertebereich für Attribute oderBemerkungen

<?xml version="1.0" encoding="UTF-8"?> Mit UTF-8 sind auch Umlaute wie ö, äund ü erlaubt.

<StoerGutMeldung Start-Tag

Version=“01.00“ Version für zukünftige Datenstrukturan-passungen.

Zugnummer="2710" Zugnummer 8-stellig 0 bis 99‘999‘999Allfällige führende Ziffern ausserhalb der8 Stellen werden abgeschnitten. Führen-de Nullen auch.

Reihe="1511" oder "6511" Baureihe 4-stellig 0 bis 9999 z.B. 1511oder 6511511 = DOSTO RVFührende 1 oder 6 = Wagennummer fürdie Steuerwagen.Allfällige führende Ziffern ausserhalb der4 Stellen werden abgeschnitten. Führen-de Nullen werden dargestellt.

Fahrzeugnummer="0013" Fahrzeugnummer 4-stellig 0 bis 9999z.B. 0013Allfällige führende Ziffern ausserhalb der4 Stellen werden abgeschnitten. Führen-de Nullen werden dargestellt.

Fuehrerstand=“1“ 0 = unbekannt1 = Führerstand 1 aktiv



2 = Führerstand 2 aktiv

Zeitstempel=“2012-01-24T09:55:17.3+01:00“ Der Zeitstempel muss konform zu RFC3339 angegeben werden. Im Beispielerfolgt eine Zeitangabe in MEZ (Hinweis:Nach RFC 3339 können Zeitangaben inbeliebigen Zeitzonen, auch UTC, erfol-gen. Entscheidend für die folgende kor-rekte Auswertung ist die Angabe desZeitoffsetwertes nach RFC 3339.)Die Datenquelle ist die Systemzeit desRegistriergeräts.

stoedat="rNS08415432113"> oderstoedat="rNK170522333025">

Telegramm SIGSTO oder STOEST ge-mäss Kapitel 7 und Kapitel 8, aber ohneCR und ohne Datensicherung.

</StoerGutMeldung> End-Tag



7 Telegrammaufbau STOEST

7.1.1.1 Die Einhaltung des Formats ist eine MUSS Anforderung

Telegramm STOEST

Variable Byte Wertebereich Bedeutung

ASCII Hex

Aufrufadresse 1 ’r’ 72h

Datenkennung 1 2 ’N’ 4Eh

Datenkennung 2 3 ’K’ 4Bh

Stunde 4 ’0’ .. ’2’ 30h .. 32h

5 ’0’ .. ’9’ 30h .. 39h

Minute 6 ’0’ .. ’5’ 30h .. 35h

7 ’0’ .. ’9’ 30h .. 39h

ID der Balisen-gruppe (NID_BG)

8 ’0’ .. ’9’ 30h .. 39h 10^4 5-stellige numerischeZahl als ASCII9 ’0’ .. ’9’ 30h .. 39h 10^3

10 ’0’ .. ’9’ 30h .. 39h 10^2

11 ’0’ .. ’9’ 30h .. 39h 10^1

12 ’0’ .. ’9’ 30h .. 39h 10^0

GK-Kennung 13 ’0’ .. ’2’ 30h .. 32h

Fehlernummer 14 ’0’ .. ’9’ 30h .. 39h 10er Stelle einer 2-stelligennumerischen Zahl

15 ’0’ .. ’9’ 30h .. 39h 1er Stelle einer 2-stelligennumerischen Zahl

CR 16 CR 0Dh Endekennung

Datensicherung 17 00h .. 7Fh Paritätsbyte



Telegramm STOEST – Kodierung der Variable Fehlernummer

Störung Wertebereich(dez)

Bedeutung

Loopstörung 07 Der durch eine Balise angekündete Loopist innerhalb der angekündeten Distanznicht gelesen worden

Inkonsistente Balise inner-halb einer Balisengruppe

40 .. 48 Die Einerstelle enthält die Nummer(N_PIG + 1) der inkonsistenten Baliseinnerhalb der Gruppe. Bei 0 ist dieseNummer unbekannt. Siehe Hinweis 1.

Balise einer Balisengruppefehlt

50 .. 58 Die Einerstelle enthält die Nummer(N_PIG + 1) der fehlenden Balise inner-halb der Gruppe. Bei 0 ist diese Nummerunbekannt. Siehe Hinweis 1.

Gutmeldung: KorrekterEmpfang

98 Meldung eines einwandfrei empfangenenDatenpunktes.

Hinweis1: Es soll bei der Berechnung von N_PIG nur auf die Balisen-Nominalrichtung und nicht etwa auf die Fahrrich-tung des Fahrzeugs geachtet werden.



8 Telegrammaufbau SIGSTO

8.1.1.1 Die Einhaltung des Formats ist eine MUSS Anforderung

Telegramm SIGSTO

Variable Byte Wertebereich Bedeutung

ASCII Hex

Aufrufadresse 1 ’r’ 72h

Datenkennung 1 2 ’N’ 4Eh

Datenkennung 2 3 ’S’ 53h

Stunde 4 ’0’ .. ’2’ 30h .. 32h

5 ’0’ .. ’9’ 30h .. 39h

Minute 6 ’0’ .. ’5’ 30h .. 35h

7 ’0’ .. ’9’ 30h .. 39h

ID der Balisen-gruppe (NID_BG)

8 ’0’ .. ’9’ 30h .. 39h 10^4 5-stellige numerischeZahl9 ’0’ .. ’9’ 30h .. 39h 10^3

10 ’0’ .. ’9’ 30h .. 39h 10^2

11 ’0’ .. ’9’ 30h .. 39h 10^1

12 ’0’ .. ’9’ 30h .. 39h 10^0

Fehlernummer 13 ’0’ .. ’9’ 30h .. 39h 10er Stelle einer 2-stelligennumerischen Zahl

14 ’0’ .. ’9’ 30h .. 39h 1er Stelle einer 2-stelligennumerischen Zahl

CR 15 CR 0Dh Endekennung

Datensicherung 16 00h .. 7Fh Paritätsbyte



Telegramm SIGSTO – Kodierung der Variable Fehlernummer

Variable M_MCOUNT(dez)

Wert (dez) Bedeutung

Irrelevant 0 .. 31 Entspricht der Nummer des Signalcode im Stö-rungstelegramm (Variable Telegrammnummer)

32 Wird nicht verwendet

127 33 Eingangstörung LEU

128 34 Eingangsstörung Balise

129 35 Halt mit Batterie Low MiniLEU

130 36 Warnung mit Batterie Low MiniLEU

131 37 Fahrt mit Batterie Low MiniLEU

132 38 Unterspannung MiniLEU-Signaladapter

133 39 Unterbruch ZU/ZK-Abgriff MiniLEU

134 40 Kurzschluss ZU/ZK-Abgriff MiniLEU

135 41 undefinierter Zustand ZU/ZK-Abgriff MiniLEU

136 42 Sicherheitsabschaltung MiniLEU

137 43 Reserve

138 44 Reserve

139 45 Reserve

140 46 Reserve

Schumann & Partner AG - 1 / 6 - 13.03.2006

SBB AG ZuBe SMR Anforderungen GSM Anbindung

Datum: 13.03.2006 Ausgabe: V1.0.0.0 Verfasser: Paul Stehrenberger Verantwortlicher: Paul Stehrenberger Dateiname: 260010 Anforderungen.doc

Schumann & Partner AG Software - Entwicklung - Beratung

Brauerstrasse 31, 8004 Zürich

ZuBe SMR Anforderungen GSM Anbindung

Inhalt 1 Einleitung................................................................................................................................... 2 2 Definitionen ............................................................................................................................... 2 3 Anforderungsspezifikation ...................................................................................................... 2 3.1 Ausgangslage............................................................................................................................ 2 3.2 Neue Anforderungen ................................................................................................................ 2 3.2.1 Übertragung der Störungsmeldungen über GSM SMS .............................................................. 2 3.2.2 Sprachumschaltung des GUI ...................................................................................................... 2 3.2.3 GKS Stammdaten , zwei neue Felder......................................................................................... 2 3.3 Struktur der Short Message..................................................................................................... 3 3.3.1 Registrierdaten............................................................................................................................ 3 3.3.2 Streckenpunktstörung ................................................................................................................. 3 3.3.3 Signalcodestörung ...................................................................................................................... 3 3.3.4 Feldbeschreibung........................................................................................................................ 3 3.3.5 Beispieldaten ZUB-spezifischer Teil ........................................................................................... 3 3.3.6 Wertebereich der Störungscodes ............................................................................................... 4 3.4 Neuer Service GSR ................................................................................................................... 4 3.4.1 Schnittstelle zum GSM-Terminal ................................................................................................ 4 3.4.2 Funktionen .................................................................................................................................. 4 3.4.3 Schnittstelle zur ZuBe SMR DB .................................................................................................. 4 3.4.4 Koordination mit KRR.................................................................................................................. 5 3.4.5 State Machine ............................................................................................................................. 5 3.5 Anpassungen des Use Case (UC) Modell............................................................................... 5 3.6 Alle UC ....................................................................................................................................... 5 3.7 UC 1.1 Diverse Stammdaten erfassen .................................................................................... 5 3.8 UC 1.2 Adressen definieren und mutieren ............................................................................. 5 3.9 UC 1.8 Zuordnung GKS zu Station.......................................................................................... 5 3.10 UC 2.5 Server Betriebsart einstellen ....................................................................................... 5 3.11 UC 3.1 Primärmeldung verarbeiten ......................................................................................... 6 3.12 UC 3.6 Systemzustand überwachen ....................................................................................... 6 3.12.1 Empfangsüberwachung .............................................................................................................. 6 3.12.2 Überwachung der Empfangsfeldstärke....................................................................................... 6 3.12.3 Überwachung der Verbindung zum GSM-Terminal.................................................................... 6 3.12.4 Anzeige auf der Statusseite ........................................................................................................ 6



Ausgabe: V1.0.0.0

1 Einleitung Seit dem Jahr 2005 ist bei SBB AG der ZuBe SMR in Betrieb. Seine Leistungsmerkmale sind in einer Spezifikation und in den Benutzerhandbüchern beschrieben. Dieses Dokument beschreibt die Anforderungen, welche sich durch den Wechsel von der Übertragung der Störungsmeldungen via Zugfunk auf die Übertragung mittels SM über das GSM-Netz ergeben. Im Weiteren soll eine Umschaltung der graphischen Benutzeroberfläche in die beiden Landessprachen Französisch und Italienisch ermöglicht werden.

2 Definitionen Begriff Definition BLZ Betriebsleitzentrale GSM Global System for Mobile Communications GSR GSM Reader. Neuer Service für ZuBe SMR um SM vom GSM Terminal

empfangen zu können Short Message Kurznachricht beim GSM-Mobilfunk SM Short Message SMS Short Message Service. Bezeichnet den Telekommunikationsdienst zur

Übertragung von Kurznachrichten im GSM-Mobilfunk. ZuBe SMR Zugbeeinflussung Störmelderechner ZUB Zugsüberwachung

3 Anforderungsspezifikation

3.1 Ausgangslage Bisher erfolgt die Übertragung der ZUB-Störungsmeldungen via Zugfunk zum Kommunikationsrechner (KR) in der BLZ und von dort via Modemstrecke zum ZuBe SMR Server. SBB AG muss bis 2008 die Frequenzbereiche des Zugfunks aufgeben. Deshalb werden die Fahrzeuge neu mit GSM-Terminals ausgerüstet, über welche Betriebsmeldungen und Notrufe der Fahrzeuge in Form von SM an die zuständigen Empfänger übermittelt werden können. Je nach Quelle und Art der Mel-dung auf dem Fahrzeug, erfolgt die Übermittlung an eine andere Empfänger-Nummer. Auf diese Weise erhält der Server ZuBe SMR nur die Störungsmeldungen der Zugbeinflussungseinrichtungen. Während der Phase, in welcher die Fahrzeuge von Zugfunk auf GSM umgerüstet werden, übermitteln die noch nicht umgerüsteten Fahrzeuge die Meldungen weiterhin via Zugfunk und KR. Die umgerüsteten Fahrzeuge übertragen die Meldungen nur noch über GSM. In einer späteren Phase, wenn alle Fahrzeuge umgerüstet sind, entfällt die Übertragung der Störungs-meldungen via Zugfunk und Kommunikationsrechner (in der BLZ) und Modemstrecke zum ZuBe SMR Server.

3.2 Neue Anforderungen

3.2.1 Übertragung der Störungsmeldungen über GSM SMS Die Störungsmeldungen werden neu als Short Messages (SM) über GSM an den ZuBe SMR übertragen. Zu deren Empfang wird eine "Cellular Engine Siemens M20/M20 Terminal" an eine serielle Schnittstelle des ZuBe SMR Server angeschlossen.

3.2.2 Sprachumschaltung des GUI Die Benutzer von ZuBeSMR sollen die Anzeigen des GUI aus den Sprachen Deutsch, Französisch und Italienisch auswählen können.

3.2.3 GKS Stammdaten , zwei neue Felder Die GKS-Datenstruktur soll um folgende Felder erweitert werden: Nr. Feld Bezeichnung Beschreibung

1 NID_LC Ländercode Numerischer Ländercode, 3 Ziffern2 NID_GB Baugruppen Identifikation Nummer der Baugruppe, 5 Ziffern

Der Inhalt dieser Felder soll über das GUI manuell gepflegt werden können. Vorläufig stehen diese Felder in den Importdaten von ZUBTEL nicht zur Verfügung. Auch in der Störungsmeldung werden diese Felder nicht mitgeliefert.



Ausgabe: V1.0.0.0

3.3 Struktur der Short Message Quelle: Word Dokument "ZuB Störmeldung mit SMS.doc" von SBB AG

3.3.1 Registrierdaten !LOC1 CC=228 NC=06 LAC=00100 CI=10000 FZG= 11223 ZN= 654321 ID=Z / M0726270032 /END

3.3.2 Streckenpunktstörung !LOC1 CC=228 NC=06 LAC=00100 CI=10000 FZG= 11223 ZN= 654321 ID=Z / K205100243109 /END

3.3.3 Signalcodestörung !LOC1 CC=228 NC=06 LAC=00100 CI=10000 FZG= 11223 ZN= 654321 ID=Z / S12065877217 /END

Dabei bedeutet das Z bei ID, dass es sich um eine ZUB-Störmeldung-SMS handelt. Bitte auch die ge-naue Anzahl der Leerzeichen beachten. (In diesem Dokument wurde die Anzahl Leerzeichen gekürzt, damit die Meldung auf einer Zeile dargestellt werden kann.)

3.3.4 Feldbeschreibung Nr. Feld Beschreibung Beispiele

1 Start Ortungskopf !LOC ist fix 1 ist Versionsnummer

!LOC1

2 Mobile Country Code Land CC=228

3 Mobile Network Code Netzwerk NC=06

4 Location Area Code Ortsvorwahl LAC=00100

5 Cell Identificateion GSM-Zelle CI=10000

6 Fahrzeugnummer FZG= 11223

7 Zugnummer ZN= 654321

8

Ortungskopf, Gesamtlänge=71 Zei-

chen

Meldungsnummer Z bedeutet ZUB (Störungs-) Meldung

ID=Z /

9 Telegrammtyp M: Registrierdaten S: Signalcodestörung K. Streckenpunktstörung

K205100243109M0726270032 S12065877217

10 Zeit des Auftretens der Stö-rung

Immer vorhanden K205100243109M0726270032 S12065877217

11 GKS-Nummer Immer vorhanden K205100243109M0726270032 S12065877217

12 Nachbarschaftsbeziehung

Nur beim Typ K relevant. Entfällt bei Typen M und S.

K205100243109M0726270032 S12065877217

13

ZUB-Telegrammdaten

Meldungs. bzw. Störungsco-de

Eine oder zwei Stellen am Schluss.

K205100243109M0726270032 S12065877217

14 Ende Ende der Kurznachricht /END

3.3.5 Beispieldaten ZUB-spezifischer Teil 1234567890123 K144839801002 M1448398012 S14483980117 Zeit_Lok ZN GKS TG_Kennung Stoe_Code NB_Typ

1448 89176 39801 K 02 01448 89176 39801 M 2 3 1) 1448 89176 39801 S 17 3 1)

1) Wird beim Einlesen erzeugt



Ausgabe: V1.0.0.0

3.3.6 Wertebereich der Störungscodes Der Wertebereich der Störungscodes bleibt gleich. Auch bei den Spezialfällen Kategorie Störungscode Meldungstext K *3 *3 = 05 Mehr als 4 Langsamfahrstellen (nur für TSSA) K *4 *4 = 06 Teilüberwachung neue Signalisierung (nur für TSSA)K *5 *5 = 07 Defekte Schleife erkannt

ergibt sich keine Veränderung.

3.4 Neuer Service GSR Es ist ein neuer Service GSR zu implementieren, der über eine RS232- Schnittstelle zum GSM Terminal - die SM-Daten abholt und sie in der DB speichert (Buffer DB und Main DB) - den Betrieb des GSM-Terminals (Inbetriebnahme, Ausserbetriebnahme, Überwachung) sicher stellt - Sofern sinnvoll und vom Aufwand her vertretbar soll der GSR eine eigene Buffer DB erhalten

3.4.1 Schnittstelle zum GSM-Terminal 3.4.1.1 Protokoll Das Protokoll der seriellen Schnittstelle ist gemäss "siemens-m20-handbuch.pdf" Kapitel 5, besonders Kapitel 5.7 zu implementieren. Dabei handelt es sich um eine AT-Befehlsschnittstelle.

3.4.2 Funktionen 3.4.2.1 Inbetriebnahme GSM Terminal Die SIM-Karte wird ohne Passwort betrieben. Abschalten aller nicht benötigten Funktionen des Terminals (Modem, Sprachübertragung, Rufanzeige), sofern möglich. Nach der Inbetriebnahme soll sofort eine Überwachungs-SM gesendet werden, damit die korrekte Funk-tion möglichst rasch erkannt und angezeigt werden kann. 3.4.2.2 Ausserbetriebnahme GSM Terminal Eine Ausserbetriebnahme ist nicht vorgesehen. Das Terminal soll immer in Betrieb sein und SM puffern. 3.4.2.3 SM lesen 3.4.2.4 SM senden (Überwachungs- SM) 3.4.2.5 SM löschen (gelesene und gesendete) 3.4.2.6 Reaktion auf asynchrone Ereignisse Folgende Ereignisse treten aus der Sicht des ZuBe SMR in zufälliger zeitlicher Abfolge auf. - SMS Empfang - Statusmeldungen - Unterbruch der Verbindung - Wiederanlauf des GSM Terminals - Ungenügende Empfangsfeldstärke Falls sie asynchron (gesteuert durch das Ereignis) auf der RS232-Schnittstelle verfügbar sind, sind sie asynchron zu verarbeiten. Andernfalls sind sie durch Polling abzufragen. Der Zeitpunkt des Empfangs der letzten Nachricht wird auf der Statusseite gezeigt, 3.4.2.7 Überwachung der Empfangsbereitschaft - Die Empfangsfeldstärke wird periodisch überwacht. Wenn sie nicht genügt, wird dies als Störung

angezeigt, analog zum Verbindungsunterbruch zum KR. - Wenn nach n-1 Stunden keine SM empfangen wurde, Überwachungs-SM senden. Wenn für n Stun-

den keine SM eingetroffen ist, wird dies als Störung angezeigt, analog zum Verbindungsunterbruch zum KR.

3.4.2.8 Wiederanlauf GSR Starten der RS-232 Schnittstelle. Behandeln zwischenzeitlich empfangener SM.

3.4.3 Schnittstelle zur ZuBe SMR DB Die bestehenden Objekte sollten mit kleinen Änderungen übernommen werden können.



Ausgabe: V1.0.0.0

3.4.4 Koordination mit KRR Es ist sicherzustellen, dass keine Zugriffskonflikte auf die Primär- und Sekundärmeldungsobjekte in der DB auftreten können.

3.4.5 State Machine Folgende Zustände sind nach aussen sichtbar: Zustand Beschreibung RUN Normaler Betriebszustand. Verbindungsunterbruch Kein eigentlicher Zustandswechsel. Der Service bleibt Betriebsbe-

reit. Ungenügende Empfangsfeldstär-ke

Kein eigentlicher Zustandswechsel. Der Service bleibt Betriebsbe-reit.

3.5 Anpassungen des Use Case (UC) Modell Das UC Modell bleibt im Wesentlichen unverändert. Bei den folgenden UC ergeben sich Änderungen.

Use Case Beschreibung * Alle UC Alle GUI Texte mehrsprachig anzeigen. 1.1 Diverse Stammda-

ten erfassen Die Betriebsparameter für die GSM Anbindung werden in der Datenbank auf-genommen und müssen gepflegt werden können

1.2 Adressen definie-ren und mutieren

Die Sprache D/F/I kann für den Benutzer ausgewählt und gespeichert werden.

1.8 Zuordnung GKS zu Station

Dieser UC erhält eine neue Bedeutung "GKS Daten bearbeiten". Die Bearbei-tung der neuen Felder NID_LC und NID_GB.

2.5 Server Betriebsart einstellen

Die GSM Schnittstelle wird von einem neuen Prozess GSR bedient. Dieser muss von der Ablaufsteuerung in den jeweils erforderlichen Betriebszustand (Start, Stopp, Backup, ZUBTEL Import) gebracht werden können.

3.1 Primärmeldung verarbeiten

Es ist eine zusätzliche Schnittstelle, nämlich diejenige zum GSM Terminal zu implementieren, über welche die Störungsmeldungen abgeholt und in die Buf-fer DB eingetragen werden. Ab dem Eintrag in die Buffer DB werden die Mel-dungen gleich wie bisher verarbeitet.

3.6 Systemzustand überwachen

Die Betriebsbereitschaft des GSM Terminals muss überwacht werden. Bei Störungen muss der TLS oder der Betreuer ZuBe SMR alarmiert werden. Der Zustand muss auf der Seite "Systemzustand" sichtbar gemacht werden.

3.6 Alle UC Die Texte auf dem GUI können mehrsprachig angezeigt werden. Der Benutzer kann die Sprache auf der Startseite (wenn möglich vor dem Einloggen) selber wechseln. Die zuletzt gewählte Sprache bleibt für den Benutzer gespeichert.

3.7 UC 1.1 Diverse Stammdaten erfassen Die zusätzlichen Parameter werden im Verlauf des Projekts bestimmt und in der DB eingefügt. Das GUI "Systemparameter" erfährt keine Änderung.

3.8 UC 1.2 Adressen definieren und mutieren Pro Benutzer kann hinterlegt werden, in welcher Sprache (D, F oder I) diese Benutzer die Anzeigen des GUI wünscht.

3.9 UC 1.8 Zuordnung GKS zu Station Neben der manuellen Zuordnung der GKS zu Nachbarstationen können neu auf dem GUI die Felder. Nr. Feld Bezeichnung Beschreibung

1 NID_LC Ländercode Numerischer Ländercode, 3 Ziffern2 NID_GB Baugruppen Identifikation Nummer der Baugruppe, 5 Ziffern

Der UC erhält eine neue Überschrift "GKS bearbeiten".

3.10 UC 2.5 Server Betriebsart einstellen Die bisherigen Betriebsarten - Applikation gestoppt



Ausgabe: V1.0.0.0

- Applikation gestartet - DB Backup durchführen - ZUBTEL Daten einlesen bleiben unverändert bestehen. Der neue Service GSR ist durch die Ablaufsteuerung gleich zu behandeln wie KRR. Das bedeutet, dass auch im gestoppten Zustand des ZuBe SMR GSR in die Buffer DB schreibt. Die Ablaufsteuerung stoppt diesen Service nicht. Sollte dies nötig sein, erfolgt das Anhalten von GSR (gleich wie beim KRR) mittels der Service-Steuerung des Betriebssystems.

3.11 UC 3.1 Primärmeldung verarbeiten Der neue Service (GSR) holt SM-Daten über eine serielle Schnittstelle vom GSM Terminal ab. Parallel zum KRR schreibt der GSR in die Buffer DB und, falls die Main DB online ist, ebenfalls in diese. Da das Weiterschreiben der Daten von der Buffer DB in die Main DB vom KRR und vom GSR betrieben wird, ist sicherzustellen, dass hierbei keine Zugriffskonflikte auftreten.

3.12 UC 3.6 Systemzustand überwachen

3.12.1 Empfangsüberwachung Der Empfang der SM wird zeitlich überwacht. Mindestens alle n Stunden (Systemparameter in der DB) muss eine SM beim ZuBe SMR eintreffen. Ist seit n-1 Stunden keine SM mehr eingetroffen, sendet der ZuBe SMR Server eine Überwachungs- SM an die eigene Mobile-Nummer. Sind mehr als n Stunden vergangen, ohne dass eine SM eintrifft, geht der GSR in den Zustand "Timeout GSM Empfang" und sendet eine Störungsmeldung: "Timeout: Keine SMS-Nachricht empfangen seit 3.6.2006 11:30:21".

3.12.2 Überwachung der Empfangsfeldstärke Die Empfangsfeldstärke wird überwacht. Unterschreitet sie für eine bestimmte Zeitspanne (Systempara-meter) eine vorgegebene Schwelle (Systemparameter) wird dieser Zustand als Störung angezeigt und der Rechner sendet eine Störungsmeldung "Störung: Ungenügende Empfangsfeldstärke".

3.12.3 Überwachung der Verbindung zum GSM-Terminal Ist die Verbindung zum GSM-Terminal für eine bestimmte Zeitspanne (Systemparameter) unterbrochen, z.B. keine Antwort oder falscher Pegel der Hardware-Flusssteuerungssignale, wird dieser Zustand als Störung angezeigt und der Rechner sendet eine Störungsmeldung "Unterbruch: Keine Verbin-dung zum GSM-Terminal".

3.12.4 Anzeige auf der Statusseite Der GSR zeigt auf der Statusseite folgende Informationen: - Empfangsfeldstärke, - Letzter Empfangszeitpunkt, - Typ der zuletzt empfangenen Nachricht.

Documents

Dokumenten-Kontrollblatt · X1.0 15.5.2013 E. ImhofUrversion erstellt X1.01 25.6.2013 E. ImhofEinarbeitung von Review - Kommentaren in al- ... Das vorliegende Lastenheft gilt für