Architekturkonzept und Designaspekte einer...

Architekturkonzept und Designaspekte einer signaltechnisch nichtsicheren

Kommunikationsplattform für sicherheitsrelevante Bahnanwendungen

von Detlef Kendelbacher

Dissertation

zur Erlangung des Grades eines Doktors der Ingenieurwissenschaften

- Dr. Ing. -

Vorgelegt im Fachbereich 3 (Mathematik & Informatik) der Universität Bremen

im September 2003

Datum des Promotionskolloquiums: 28.01.2004 Gutachter: Prof. Dr. Jan Peleska (Universität Bremen) Prof. Dr. Ute Bormann (Universität Bremen)

2

3

zur Adaption des GSM/R-Systems an die ETCS-Zugsicherungskomponenten (OBU – On Board Unit im Fahrzeug; RBC – Radio Block Center auf der Streckenseite) verwendet.

1 Vorwort Die deutsche Bahn, wie auch viele andere Bahngesellschaften in Europa, stehen unter dem Druck, ihre Unternehmungen betriebswirtschaftlich zu optimieren. Zentrale Bedeutung kommt dabei einem integrierten Konzept zur effektiven und wirtschaftlichen Kommunikation der verschiedenen Bahndienste zu. Die europäischen Bahngesellschaften wollen für mobile Bahndienste das digitale Mobilfunksystem GSM/R (GSM-Railway), welches auf dem GSM-Standard basiert, einführen. Am Beispiel der Zugbeeinflussungssysteme im Regionalverkehr (RMV)- und Hochge-schwindigkeitsverkehr (HGV) sind in entsprechenden Forschungsprojekten (DIBMOF[1]; EIRENE[2]) technische Einsparungspotentiale aufgezeigt worden. Eine Schlüsselrolle spielt in diesen Systemansätzen die signaltechnisch sichere Kommunikation über offene Netze. Die notwendigen technischen Randbedingungen sind in europäischen Normen bzw. Normvor-schlägen (CENELEC[3]) und Standards (UNISIG[4]) festgelegt. Die bisher prototypisch realisierten Systeme sowohl für den HGV als auch für den RMV nutzen ausschließlich Dienste zur Übertragung von signaltechnisch sicheren Daten. Eine Diensteintegration, d.h. die gleichzeitige Übertragung von signaltechnisch sicheren und signal-technisch nichtsicheren Informationen, wird durch die standardisierten Protokollstacks zwar unter-stützt, bleibt aber späteren Produktphasen vorbehalten. Die konsequente Trennung von signaltechnisch sicheren und unterlagerten signaltechnisch nichtsicheren Funktionalitäten eröffnet neue Möglichkeiten in der Kommunikationsarchitektur von Bahnanwendungen. Die kostenintensive Entwicklung signaltechnisch sicherer Komponenten beschränkt sich auf die Realisierung der signaltechnisch sicheren Funktionalitäten in einer signaltechnisch sicheren Ablaufumgebung. Die Adaption der unterlagerten offenen Netze an die speziellen Belange der signaltechnisch sicheren Ablaufumgebung zur Übertragung sicherheitsrelevanter Informationen über ein signaltechnisch nichtsicheres Übertragungsmedium (grauer Kanal), stellt eine spezifische Problematik der oben erwähnten Systemansätze dar. Eine signaltechnisch nichtsichere Kommunikationsplattform als Vermittler zwischen Standard-lösungen aus der Kommunikationswelt und den speziellen Belangen der sicherheitsrelevanten Bahnanwendungen stellt eine notwendige und innovative Komponente zur Lösung des System-ansatzes der signaltechnisch sicheren Kommunikation über offene Netze dar. Die in dieser Arbeit vorgestellte signaltechnisch nichtsichere Kommunikationsplattform entstand im Rahmen der Systementwicklung Funkbasissystem (FBS) – Subsystem Kommunikation (FBS-K; Kommunikationsbasissystem – KBS) des Bereichs Transportation Systems der Siemens AG. Das Kommunikationsbasissystem fand im Forschungsprojekt DIBMOF als signaltechnisch nichtsicherer Kommunikationsrechner in Messsystemen zur GSM/R Nutzkanalanalyse (anwendungsbezogene Quality of Service Messungen) und in Präsentationssystemen Anwendung. Auf der FFB-Pilotstrecke Dissen-Brackwede (siehe [20]) wurde zur Demonstration des Funk Fahr Betriebes (FFB) im Rahmen der EXPO 2000 das Kommunikationsbasissystem in verschiedenen Ausprägungen zur Adaption des GSM/R-Systems an die Komponenten des FFB-Zugsicherungs-systems eingesetzt. Im ETCS 2000 System des Konsortiums AASSAA (ALCATEL und SIEMENS – siehe [21]) wird das Kommunikationsbasissystem in fahrzeug- und streckenseitiger Ausprägung

Die Zugsicherungssysteme nutzen das Kommunikationsbasissystem zum Austausch kryptografisch

4

Bahnanwendungen sind für die Systementwicklung relevant. Dem Aspekt der sehr langen

gesicherter Zugsicherungsinformationen (z.B. Fahrtfreigaben). Das Kommunikationsbasissystem nutzt das unterlagerte GSM/R System als Übertragungsmedium. Das im Kapitel 4 dieser Arbeit vorgestellte Architekturkonzept wurden im Rahmen der System-entwicklung des Kommunikationsbasissystems vom Autor entworfen. An der Umsetzung der im Kapitel 5 beschriebenen Komponenten sowie an der Entwicklung der Test- und Konformitäts-nachweisstrategie war der Autor maßgeblich beteiligt. Die Entwicklung des Kommunikationsbasissystems wurde durch Anwendung unterschiedlicher Entwurfsstrategien bewältigt: Nutzung klassischer Betriebsmittel und Entwurfsmethoden Die im OS-Kernel-Bereich ablaufenden Softwarekomponenten der Kommunikationsplattform sind als SVR4-STREAMS-Module realisiert worden. Zur Vereinfachung der Lade- und Konfigurations-prozeduren der für die Kommunikationsplattform entwickelten SVR4-STREAMS-Module wurde eine spezielle Bibliothek (siehe 5.2.1) entwickelt. Die in den Kommunikationstasks der Kommunikationsplattform ablaufenden Vermittlungsfunktio-nen sind durch ereignisgetriebene Callback-Funktionen realisiert worden. Die Filedeskriptor-bezogene Multiple-Wait-Ereignisverwaltung der Kommunikationsplattform wird durch eine speziell entwickelte Bibliothek (siehe 5.2.2) organisiert. Systemspezifische Erweiterungen abstrakter Betriebsmittel Die im Rahmen der Entwicklung des Kommunikationsbasissystems erstellte USER-STREAM-Ablaufumgebung (siehe 5.3.3) stellt eine Nachrichten- und Warteschlangen- orientierte Basis zur effektiven Realisierung von Kommunikationsprotokollen im USER-SPACE dar. Die Vermittlungs- und Protokolllogik des Kommunikationsbasissystems wird durch ereignisge-koppelte Zustandsautomaten organisiert. Es kamen unterschiedliche, den speziellen Randbe-dingungen angepasste, Automatenvarianten (siehe 5.3.1) als Bibliotheken zur Anwendung. Zur hierarchisch organisierten Parameterkodierung von Vermittlungsprimitiven wurden spezielle Bibliotheksfunktionen (siehe 5.3.2) entwickelt. Problemspezifische Lösungen Zur Kopplung an signaltechnisch sichere Rechner wurde ein an die spezifischen Bedürfnisse angepasstes Protokoll (siehe 4.7.2) entworfen und als USER-STREAM-Protokollstack realisiert. Bei Verwendung der Kommunikationsplattform als hoch verfügbarer Vermittlungsrechner (siehe 4.7.1) setzt das Redundanzmanagement auf spezielle Eigenschaften des Koppelprotokolls auf. Das Kapitel 3 „Einleitung: Besondere Anforderungen sicherheitsrelevanter Bahnanwendun-gen an unterlagerte nichtsichere Kommunikationsdienste“ beleuchtet die spezifische Proble-matik der gewachsenen heterogenen Struktur der Kommunikationsdienste sicherheitsrelevanter Bahnanwendungen am Beispiel der Deutschen Bahn. Es werden allgemeingültige Forderungen bezüglich Funktionalität und Eigenschaften wie Zuver-lässigkeit und Robustheit von Hardware und Software vorgestellt. Die Bedeutung betriebswirtschaftlicher Forderungen nach Integration von Standardlösungen für Standardfunktionen sowie die kostengünstige Integration nichtsicherer Zusatzdienste wird zukünf-tig weiter zunehmen. Forderungen nach Interoperabilität, Migration und Adaption vorhandener gewachsener Strukturen bei gleichzeitiger Erfüllung eines europaweit gültigen Standards für

Verwendung eingeführter Systeme mit den entsprechenden Lieferverpflichtungen wird Rechnung

5

funktionalität, sowie der prinzipielle Aufbau des Vermittlungskerns für verbindungsorientierte

getragen. Im zweiten Teil dieses Kapitels wird auf die Anforderungen eingegangen, die sich speziell durch die Verwendung einer einkanaligen signaltechnisch sicheren Datenübertragung über offene Netze ergeben. Stellvertretend für sicherheitsrelevante Bahnanwendungen wird auf den Funk Fahr Betrieb (FFB) mit seinen hohen Forderungen an die Skalierbarkeit (z.B. bezüglich Gruppensteuerung) eingegangen. Spezielle Eigenschaften der Kopplung einer signaltechnisch nichtsicheren Kommunikations-plattform als Bestandteil des „grauen“ Kanals an mehrkanalige redundante signaltechnisch sichere Rechner und die damit verbundenen Forderungen nach Rückwirkungsfreiheit auf signaltechnisch sichere Funktionen von Hardware (z.B. EMV) und Software (Protokolltechnik; Identifikation & Authentifikation) schließen das Anforderungskapitel ab. Das Kapitel 4 „Gatewayarchitektur der Kommunikationsplattform“ stellt eine Lösung vor, welche den im vorhergehenden Kapitel aufgeführten Forderungen prinzipiell gerecht wird. Im Einzelnen wird die weitestgehende Entkopplung der vom jeweils verwendeten Betriebssystem zur Verfügung gestellten Betriebsmittel über ein Schalenmodell vorgestellt, wodurch Forderungen nach Skalierbarkeit und langfristiger Wiederverwendbarkeit, auch über einen Wechsel des Betriebssystems bzw. der Hardware hinaus, in einem sehr hohen Maße abgedeckt werden. Es wird ein einheitliches schichtenförmiges Gatewaymodell mit verschiedenen Kommunikations-stacks beschrieben, welches der Forderung nach Integration in heterogenen Netzwerkumgebungen und Adaption von teilweise sehr unterschiedlichen Kommunikationsanforderungen verschiedener Bahnapplikationen gerecht wird. Die prinzipiellen Varianten der internen Kommunikationsarten innerhalb des Gatewaymodells werden vorgestellt. Im letzten Teil dieses Kapitels wird die Architektur der Kommunikationsplattform zur Realisierung von Rechner-Redundanz bzw. zur Verteilung der Vermittlungslast in Clustern von Vermittlungs-knoten beleuchtet. Das Kapitel 5 „Designaspekte“ stellt auf Basis der im vorhergehenden Kapitel getroffenen Architekturfestlegungen prinzipielle Designansätze für Kommunikationssoftware am Beispiel der realisierten signaltechnisch nichtsicheren Kommunikationsplattform dar, mit deren Hilfe die geforderten Basiseigenschaften realisiert werden können. Im ersten Teil des Kapitels wird der schichtenweise Aufbau der betriebssystemabhängigen Betriebs-mittel sowie eine betriebssystemunabhängige Ablaufumgebung vorgestellt. Es werden die Vorteile der ausgewählten Realisierung den Nachteilen gegenübergestellt. Am Beispiel der ISDN (S2M) – Kopplung der nichtsicheren Kommunikationsplattform für den FFB wird gezeigt, welche Kom-ponenten ungekapselt im Firmware/Kernelbereich ablaufen und welche Protokollschichten betriebssystemunabhängig realisiert werden konnten. Im zweiten Teil des Kapitels werden zwei Beispiele für Betriebssystem-unabhängige Abstraktionen von Betriebsmitteln vorgestellt. Die Betriebsmittel „Zustandsautomat“ und „ASN-Kodierung (Ab-stract Syntax Notation)“ werden dargelegt. Im dritten Teil des Kapitels wird der interne Nachrichtenaufbau der Kommunikationsplattform beleuchtet. Es wird die Nachrichtenstruktur des Streamsmodells als Träger von Protokollprimitiven sowie deren Parameterstrukturierung am Beispiel des TR-Interfaces vorgestellt. Der vierte Teil des Kapitels beschäftigt sich mit der Protokoll- und Vermittlungslogik der Kommunikationsplattform. Es wird der prinzipielle Aufbau einfacher Kommunikationsmodule als Träger von Protokollschichten ohne Vermittlungsfunktionalität und, darauf aufbauend, der prinzipielle Aufbau komplexer Kommunikationsmultiplexer mit statischer Vermittlungs-

Kommunikation dargestellt. Besondere Aspekte des Adressmanagements, wie beispielsweise die dynamische Nachführung von Adressverzeichnissen in mobilen Entitäten schließen diesen Teil ab. Im Kapitel 6 „Test/Validierung“ wird die Teststrategie zur Validierung der Kommunikations-plattform näher beleuchtet. Am Beispiel des in der Kommunikationsplattform realisierten EURORADIO – Protokollstacks nach UNISIG [4] wird beschrieben, welche Randbedingungen in der Architektur und Designphase beachtet werden sollten, um ein effektives Testen in der Integrationsphase zu ermöglichen. Im zweiten Teil dieses Kapitels werden wesentliche Aspekte des Testkonzepts der Kommunikationsplattform erläutert. Auf Basis des geforderten Lastmodells mit stochastischen Komponenten und den gegebenen Schnittstelleneigenschaften am Nutzerinterface werden geeignete Testszenarien definiert. Im dritten Teil dieses Kapitels wird die Testumgebung für die einfachen Vortests mit lokaler nichtsynchronisierter Steuerung sowie die komplexeren Tests, gesteuert durch ein Echtzeittestsystem, vorgestellt. Die Vorgehensweise bei der Auswertung der Tests wird im letzten Teil des Kapitels behandelt. Im Kapitel 7 „Zusammenfassung und Ausblick“ werden die möglichen Potentiale des in den vorangegangenen Kapiteln beschriebenen Konzeptes aufgezeigt. Es wird gezeigt, wie die diensteintegrierende Kommunikationsplattform eine applikationsunab-hängige Verwaltung beschränkter Netzressourcen unter den speziellen Randbedingungen der Bahnanwendungen bereitstellt. Auch die Unterstützung weiterer komplexer Netzeigenschaften (z.B. dynamische Bandbreitenanforderung wie im ATM) kann unabhängig und ohne spezielle Funktionalitäten in den einzelnen Bahnanwendungen erfolgen. Durch Nutzung dieser Technologie ist es möglich, Standarddienstzugänge (z.B. webserverbasierte Diagnose) für spezifische (proprietäre) Bahnanwendungen effektiv zu realisieren.

6

7

4.7 DIE GRUNDSTRUKTUR DER KOMMUNIKATIONSTASK............................................................................................. 56 4.7.1 Vermittlungscluster........................................................................................................................................ 59

2 Inhaltsverzeichnis

1 VORWORT.................................................................................................................................................................. 3

2 INHALTSVERZEICHNIS.......................................................................................................................................... 7

3 EINLEITUNG: BESONDERE ANFORDERUNGEN SICHERHEITSRELEVANTER BAHNANWENDUNGEN AN UNTERLAGERTE NICHTSICHERE KOMMUNIKATIONSDIENSTE .......... 11

3.1 ALLGEMEINE ANFORDERUNGEN............................................................................................................................ 11 3.1.1 Betriebszulassung .......................................................................................................................................... 11

3.1.1.1 Systemumgebung Streckeneinrichtung...................................................................................................................... 11 3.1.1.1.1 Umweltbedingungen .......................................................................................................................................... 12 3.1.1.1.2 Stromversorgung................................................................................................................................................ 13 3.1.1.1.3 EMV-Bedingungen............................................................................................................................................ 14

3.1.1.2 Systemumgebung Fahrzeugeinrichtung und dezentrale Streckeneinrichtung............................................................ 14 3.1.1.2.1 Umweltbedingungen .......................................................................................................................................... 14 3.1.1.2.2 Stromversorgung................................................................................................................................................ 17 3.1.1.2.3 EMV-Bedingungen............................................................................................................................................ 17

3.1.2 Organisatorische Randbedingungen ............................................................................................................. 18 3.1.3 Kommunikationsanforderungen des Funk Fahr Betriebes ............................................................................ 19

3.1.3.1 GSM/R ...................................................................................................................................................................... 19 3.1.3.2 Kommunikationsverhalten der FFB-Applikation ...................................................................................................... 22

3.1.3.2.1 Charakteristik der Kommunikation Zentrale - Fahrzeuge/Fahrwegelemente ..................................................... 25 3.1.3.2.2 Charakteristik der Kommunikation Fahrzeug - Fahrwegelemente ..................................................................... 25 3.1.3.2.3 Kommunikationslast zwischen Fahrzeug und Fahrwegelementen ..................................................................... 28

3.1.3.3 Lastmodell................................................................................................................................................................. 28 3.1.3.4 Performanzanforderungen ......................................................................................................................................... 29

3.2 ANFORDERUNGEN BEI VERWENDUNG EINER EINKANALIGEN SIGNALTECHNISCH SICHEREN DATENÜBERTRAGUNG ÜBER OFFENE NETZE ................................................................................................................................................... 34

3.2.1 EURORADIO Sicherungsverfahren .............................................................................................................. 35 3.3 ANFORDERUNGEN DURCH KOPPLUNG EINER SIGNALTECHNISCH NICHTSICHEREN KOMMUNIKATIONSPLATTFORM AN MEHRKANALIG REDUNDANTE SIGNALTECHNISCH SICHERE RECHNER .......................................................................... 36

3.3.1 Mehrkanalig redundante signaltechnisch sichere Rechner ........................................................................... 36 3.3.2 Struktur Koppelprotokoll ............................................................................................................................... 38

3.3.2.1 Linkebene.................................................................................................................................................................. 38 3.3.2.2 Virtuelle Linkebene................................................................................................................................................... 39 3.3.2.3 Redundante Kopplung............................................................................................................................................... 39

3.3.3 Rückwirkungsfreiheit bei einkanalig signaltechnisch sicherer Datenübertragung ....................................... 41 3.3.3.1 Bedrohung durch den grauen Kanal .......................................................................................................................... 41 3.3.3.2 Bedrohung durch Nichtverfügbarkeit der Kommunikation ....................................................................................... 42 3.3.3.3 Bedrohung durch physikalische Einflüsse................................................................................................................. 43

4 GATEWAYARCHITEKTUR DER KOMMUNIKATIONSPLATTFORM ....................................................... 45 4.1 LÖSUNGEN FÜR DEN KOMMUNIKATIONSENGPASS FAHRZEUG - FAHRWEGELEMENTE............................................ 45 4.2 KOMMUNIKATIONSBEZIEHUNGEN.......................................................................................................................... 46

4.2.1 Einzelelemente ............................................................................................................................................... 47 4.2.2 Zentrale Gruppensteuerung........................................................................................................................... 47 4.2.3 Dezentrale Gruppensteuerung....................................................................................................................... 48

4.3 BASISENTSCHEIDUNGEN ........................................................................................................................................ 49 4.4 DAS SCHALENMODELL DER BETRIEBSMITTEL ....................................................................................................... 50 4.5 DAS SCHICHTENMODELL DER KOMMUNIKATIONSSTACKS ..................................................................................... 52 4.6 VARIANTEN INTERNER KOMMUNIKATIONSBEZIEHUNGEN...................................................................................... 55

4.6.1 Verbindungsorientierte Kommunikation........................................................................................................ 55 4.6.2 Interprozesskommunikation ........................................................................................................................... 56 4.6.3 Verbindungslose Kommunikation .................................................................................................................. 56

4.7.2 Koppelprotokoll der Kommunikationsplattform ............................................................................................ 61

8

6.3.4 Testfall ......................................................................................................................................................... 1406.3.5 Testszenario ................................................................................................................................................. 141

4.7.2.1 Redundanz und Verteilung der Vermittlungslast ...................................................................................................... 63 4.7.2.2 Setupphase ................................................................................................................................................................ 63 4.7.2.3 Die VL-Protokollschicht ........................................................................................................................................... 66

4.7.2.3.1 Protokolldateneinheiten ..................................................................................................................................... 66 4.7.2.3.2 Funktionen ......................................................................................................................................................... 66 4.7.2.3.3 Struktur und Kodierung der VL-PDU´s............................................................................................................. 67 4.7.2.3.4 Zustände und Ereignisse .................................................................................................................................... 69 4.7.2.3.5 Timings VL-Schicht........................................................................................................................................... 71

4.7.2.4 Lastbalance................................................................................................................................................................ 77 5 DESIGNASPEKTE ................................................................................................................................................... 79

5.1 KAPSELUNG DES OS .............................................................................................................................................. 79 5.2 OS - ABHÄNGIGE BETRIEBSMITTEL........................................................................................................................ 80

5.2.1 KS-Modul....................................................................................................................................................... 80 5.2.2 Multiple-Wait-Ereignisverwaltung ................................................................................................................ 84 5.2.3 Zeitereignisverwaltung .................................................................................................................................. 87 5.2.4 Prozesssignalverwaltung ............................................................................................................................... 89 5.2.5 Vermeidung der Nebenläufigkeit in der Ereignisverwaltung......................................................................... 89

5.3 OS - UNABHÄNGIGE BETRIEBSMITTEL................................................................................................................... 91 5.3.1 Statemaschine ................................................................................................................................................ 91

5.3.1.1 Fest kodierte Automaten ........................................................................................................................................... 92 5.3.1.2 Zur Laufzeit kodierte Automaten .............................................................................................................................. 98

5.3.2 ASN – Primitiven – Parameterkodierung an externen Schnittstellen .......................................................... 103 5.3.3 USER-STREAM ........................................................................................................................................... 106

5.3.3.1 USER-STREAM Channel API................................................................................................................................ 108 5.3.3.2 Managementfunktionen........................................................................................................................................... 109 5.3.3.3 Nachrichtenaufbau .................................................................................................................................................. 113 5.3.3.4 Anwendungsbeispiel ............................................................................................................................................... 116 5.3.3.5 Vergleich USER STREAM – SVR4 Streams ......................................................................................................... 120

5.4 VERMITTLUNGSFUNKTIONALITÄTEN.................................................................................................................... 122 5.4.1 Einfache Kommunikationsmodule ............................................................................................................... 122 5.4.2 Kommunikationsmultiplexer mit statischer Vermittlungsfunktionalität....................................................... 123 5.4.3 Vermittlungskern für verbindungsorientierte Kommunikation .................................................................... 125 5.4.4 Adressmanagement ...................................................................................................................................... 126

6 TEST / VALIDIERUNG ......................................................................................................................................... 131 6.1 METHODEN DER VALIDIERUNG............................................................................................................................ 131

6.1.1 Funktions- und Black-Box-Tests.................................................................................................................. 131 6.1.1.1 Tests im Rahmen der Entwicklung FBS-K.............................................................................................................. 131 6.1.1.2 Tests im Rahmen der Verifikation FBS-K .............................................................................................................. 131 6.1.1.3 Tests im Rahmen der Integration und Validierung FBS-K ..................................................................................... 132 6.1.1.4 Grenzwertanalyse .................................................................................................................................................... 132

6.1.2 Leistungstests............................................................................................................................................... 132 6.1.2.1 Avalanche-/Belastungstests ..................................................................................................................................... 132 6.1.2.2 Antwortzeiten .......................................................................................................................................................... 132 6.1.2.3 Speichergrenzen ...................................................................................................................................................... 132

6.2 TESTMANAGEMENT ............................................................................................................................................. 133 6.2.1 Komponenten der Testumgebung ................................................................................................................ 133 6.2.2 Komponenten des Prüflings......................................................................................................................... 134 6.2.3 Varianten des Prüflings ............................................................................................................................... 134 6.2.4 Auswertekonzept .......................................................................................................................................... 134

6.3 GRUNDLAGEN...................................................................................................................................................... 136 6.3.1 Überblick ..................................................................................................................................................... 136 6.3.2 Testschritt .................................................................................................................................................... 137 6.3.3 Testkonfiguration......................................................................................................................................... 137

6.3.3.1 Aktivierungsscript ................................................................................................................................................... 139 6.3.3.2 Testzugangskonfiguration und Zugangslabel .......................................................................................................... 139

6.4 TESTSZENARIEN .................................................................................................................................................. 144 6.4.1 Testszenario 1/ CON_OK_A (Signalisierung) ............................................................................................. 144 6.4.2 Testszenario 2/ CON_OK_B (Signalisierung) ............................................................................................. 145 6.4.3 Testszenario 3/ CON_NOT_OK_B (Signalisierung).................................................................................... 146 6.4.4 Testszenario 4/ CON_NOT_OK_A (Signalisierung).................................................................................... 147 6.4.5 Testszenario 5/ CON_NOT_OK_N (Signalisierung) ................................................................................... 148 6.4.6 Testszenario 6/ CON_DATA (Datenphase) ................................................................................................. 149 6.4.7 Testszenario 7/ CON_ALL (gemischtes Szenario) ....................................................................................... 150

6.5 KOMPATIBILITÄTS- UND EINGESCHRÄNKTE KONFORMITÄTSNACHWEISSTRATEGIE.............................................. 150 6.5.1 Konfiguration des Prüflings ........................................................................................................................ 151 6.5.2 Randbedingungen ........................................................................................................................................ 153 6.5.3 Beaufschlagung mit Messszenarien ............................................................................................................. 154 6.5.4 Messpunkte im EURORADIO-Stack ............................................................................................................ 154 6.5.5 Realisierung der Messpunkte....................................................................................................................... 156 6.5.6 Statische Konformitätsanalyse..................................................................................................................... 158 6.5.7 Dynamische Konformitätsanalyse ............................................................................................................... 159 6.5.8 Ableitung von Prüfanforderungen ............................................................................................................... 159 6.5.9 Zustandsbezogene Konformitätskriterien .................................................................................................... 160

6.5.9.1 Struktur der gekoppelten Zustandsautomaten zur Überwachung der dynamischen Konformitätsregeln................. 160 6.5.9.2 Zustandsüberwachung Linkstatus HDLC................................................................................................................ 162

6.5.9.2.1 Zustandsübergangsmatrix ................................................................................................................................ 162 6.5.9.2.2 Transitionsbezogene Prüfaktivitäten ................................................................................................................ 163

6.5.9.3 Zustandsüberwachung sendeseitige Flusskontrolle ................................................................................................. 164 6.5.9.3.1 Zustandsübergangsmatrix ................................................................................................................................ 165 6.5.9.3.2 Transitionsbezogene Prüfaktivitäten ................................................................................................................ 165

6.5.9.4 Überwachung von Zeitkriterien............................................................................................................................... 166 7 ZUSAMMENFASSUNG UND AUSBLICK.......................................................................................................... 167

7.1 ZUSAMMENFASSUNG ........................................................................................................................................... 167 7.2 ZUSÄTZLICHE GATEWAYFUNKTIONALITÄTEN...................................................................................................... 168

7.2.1 Verteilung von Managementinformationen ................................................................................................. 168 7.2.1.1 Kommunikationsapplikation zum dynamischen Adressmanagement...................................................................... 169 7.2.1.2 Kommunikationsapplikation zum dynamischen Schlüsselmanagement.................................................................. 170

7.2.2 HTTP – basierte Ansteuerung...................................................................................................................... 171 7.3 ERWEITERUNG DER KONFORMITÄTSNACHWEISSTRATEGIE .................................................................................. 173

8 BEGRIFFE UND ABKÜRZUNGEN ..................................................................................................................... 175

9 NORMEN UND STANDARDS .............................................................................................................................. 181

10 LITERATURANGABEN...................................................................................................................................... 183

9

3 Einleitung: Besondere Anforderungen sicherheitsrelevanter

Bahnanwendungen an unterlagerte nichtsichere

Kommunikationsdienste

3.1 Allgemeine Anforderungen

3.1.1 Betriebszulassung

Um eine technische Komponente auf Fahrzeugen, in Streckeneinrichtungen oder im Stellwerk der DB AG betreiben zu können, wird eine allgemeine Betriebszulassung benötigt, auch wenn die zu betreibende Komponente keine signaltechnische Sicherheitsverantwortung trägt. Bei der Ent-wicklung der Software einer Komponente ohne Sicherheitsverantwortung sind entsprechend [EN 50128] folgende Minimalforderungen zu beachten:

• Übereinstimmung mit [EN ISO 9000-3] • Qualitätssicherungssystem • Konfigurationsmanagement

Die Betriebszulassung ist verbunden mit dem Nachweis der zufriedenstellenden Funktion und anderer Eigenschaften wie z.B. Verfügbarkeit, Umwelteigenschaften und Wartbarkeit der Komponente unter definierten äußeren Randbedingungen. Weiterhin muss gezeigt werden, dass eine ausreichende Rückwirkungsfreiheit (mechanisch, thermisch, elektro-magnetisch) auf andere Komponenten gewährleistet ist. Die Rückwirkungsfreiheit der Software von signaltechnisch nichtsicheren Komponenten (z.B. durch Kommunikationsprotokolle auf gemeinsamen Schnittstellen) auf Komponenten mit Sicherheitsverantwortung muss von den Komponenten mit Sicherheitsverantwortung gewährleistet werden (in Abweichung zur Luftfahrtnorm [RTCA DO 178B] ist die Rückwirkungsfreiheit der Software von signaltechnisch nichtsicheren Komponenten des Bahnbetriebes durch die Komponenten mit Sicherheitsverantwortung sicherzustellen und nachzuweisen). Dadurch wird verhindert, dass sich Fehler in den signaltechnisch sicheren Kompo-nenten ausbreiten. Andere europäische Bahngesellschaften haben ähnliche Zulassungsverfahren. Im Rahmen der europäischen Standardisierung wird angestrebt, eine gegenseitige Anerkennung der Betriebs-zulassung der verschiedenen Bahngesellschaften zu ermöglichen. Aus den in den nächsten Kapiteln beschriebenen Umgebungsanforderungen wird erkennbar, dass signaltechnisch nichtsichere Komponenten mit Standardlösungen aus der Industrieautomatisierung (z.B. Industrie PC) im Stellwerksbereich ohne größere Probleme eingesetzt werden können. Komponenten auf dem Fahrzeug unterliegen sehr harten Anforderungen speziell im Temperaturbereich und in der Schwingbeanspruchung. Diese Komponenten sind auch im signaltechnisch nichtsicheren Bereich in der Regel angepasste Spezialanfertigungen um eine ausreichend hohe Zuverlässigkeit und Verfügbarkeit garantieren zu können.

3.1.1.1 Systemumgebung Streckeneinrichtung

11

Die im FFB eingesetzte Streckenzentrale (siehe Abbildung 2) weist neben mehreren signaltechnisch sicheren Rechnern auch signaltechnisch nichtsichere Rechnerkomponenten für die Kommunikation

auf (siehe 3.1.3.2). Sie ist in der Regel in einem klimatisierten Bahngebäude (z.B. Stellwerks-

12

• hoher Luftdruck 106 kPa

gebäude) untergebracht. Für die FFB-Zentrale gelten folgende Umweltanforderungen:

3.1.1.1.1 Umweltbedingungen

Umgebungstemperatur der Baugruppen Durch die beim Betrieb auftretende Erwärmung dürfen die zulässigen Grenztemperaturen der Betriebsmittel nicht überschritten werden. Die Umweltbedingungen des Verschmutzungsgrades 1 [DIN VDE 0110] sollen eingehalten werden. Umgebungstemperatur Rechnerrahmen und Schrank Für den Schaltschrank muss eine Umgebungstemperatur (gemessen am Lufteintritt unterster Baugruppenträger) von + 5°C ... + 40°C festgelegt werden. Durch die beim Betrieb auftretende Erwärmung können die zulässigen Grenztemperaturen der Betriebsmittel nicht überschritten werden. Mit der oben angegebenen Umgebungstemperatur sollen die Anforderungen nach [EN 60721] (Gebäude innen für Umgebungstemperaturen +5°/+40°C) erfüllt werden. Luftfeuchte, Staubgehalt und schädliche Gase Temperatur in Grad Celsius relative Luftfeuchte in

% 5 15 – 85 22 5 – 85 28 5 – 85 40 5 – 50

Tabelle 1: Relative Luftfeuchte

Die Tabelle für die relative Luftfeuchte gilt für in einem Gebäude aufgestellte Rechner für eine Umgebungstemperatur von +5°C bis +40°C nach [EN 60721]. Eine höhere Luftfeuchte darf nach [Mü8004] bei niedrigen Temperaturen kurzzeitig auftreten. z.B. 90% bei +20°C. Sand 30 mg/m3 Staub (Schwebstoffgehalt) 0,2 mg/m3 Staub (Niederschlag) 1,5 mg/(m2 x h)

Tabelle 2: Staubgehalt nach [EN 60721]

Der Schadstoffgehalt in den Betriebsräumen soll die Werte in [EN 60721] nicht überschreiten. Höhenlage Auslegung nach [DIN VDE 804] und [EN 50123] für den ortsfesten Einsatz von -120 m bis 2000 m über NN, Druckausgleich mit der umgebenden Atmosphäre.

• niedriger Luftdruck 70 kPa

Fremderschütterung

13

ristik erforderlich.

Für stationäre Geräte können sinusförmige Schwingbelastungen nach [EN 60721] auftreten. Amplitude der Auslenkung 1,5 mm - Amplitude der Beschleunigung - 5 m/s2 Frequenzbereich 2 - 9 Hz 9 - 200 Hz

Tabelle 3: Sinusförmige Schwingbelastungen

Dieses gilt für Einsatzorte ohne ausgeprägten oder nur mit geringem Schwingungspegel. Schock-Antwort-Spektrum Typ L Spitzenbeschleunigung à Dauer

40 m/s2 22 ms

Tabelle 4: Stöße nach [EN 60721]

Dies gilt für Einsatzorte ohne ausgeprägte Stoßbeschleunigung und für Einsatzorte, an denen geringe Stoßbeschleunigungen auftreten. Falls die Belastungen zu Fremderschütterungen von der Komponente nicht erfüllt werden können, ist vom EBA eine Sondergenehmigung für die verwendete Rechnerkonfiguration erforderlich. Diese Sondergenehmigung ist vom Hersteller zu beantragen und zu begründen. Grenzwerte Innerhalb der zulässigen Grenzwerte wird die Zuverlässigkeit gewährleistet. Das kurzzeitige Erreichen der zugelassenen Grenzwerte soll nicht zur Einschränkung der Zuverlässigkeit der Anlagen führen. Nur ständiger oder langfristiger Betrieb an den Grenzwerten oder außerhalb der Grenzwerte darf zu Zuverlässigkeitsminderung führen. Um solche Zuverlässigkeitsminderungen zu vermeiden, sind zwischen Errichter und Betreiber Maßnahmen zur Verhinderung derartiger Betriebszustände zu vereinbaren. Schutzart Der Standardschrank ist nach der Schutzklasse IP20 entsprechend [DIN VDE 0470] auszulegen.

3.1.1.1.2 Stromversorgung

Für den Anschluss der Hauptstromversorgung an das Stromversorgungsnetz gelten grundsätzlich die einschlägigen Vorschriften von [DIN VDE 0100] und die technischen Anschlussbedingungen der örtlichen Stromversorgungsunternehmen. Außerdem sind die zutreffenden Arbeitsschutz- und Unfallverhütungsvorschriften zu beachten. Die Hauptstromversorgung muss so beschaffen sein, dass ein bestimmungsgemäßer (hier: hochverfügbarer) Betrieb der Anlage möglich ist. Aus diesem Grund muss eine unterbrechungsfreie Stromversorgung eingesetzt werden. Die Stromversorgung ist nach [DIN VDE 800], [DIN VDE 0831] auszulegen. Die Kommunikationsplattform ist für eine unterbrechungsfreie Stromversorgung von 230 V Wechselspannung auszulegen. Eine Versorgung mit weiteren Spannungen (z.B. Gleichspannung 60 V) ist auf Wunsch zu ermöglichen. Als Leitungsschutz ist eine träge Schmelzsicherung oder ein Sicherungsautomat mit C-Charakte-

3.1.1.1.3 EMV-Bedingungen

Zur Gewährleistung einer ausreichenden EMV werden die Normen [EN 50121] Teil 4, [EN50081-2] und [EN50082-2] berücksichtigt. Durch EMV-Prüfungen wird die Fähigkeit der Kommunikationsplattform nachgewiesen, zufriedenstellend in der Umgebung zu arbeiten und keine unzulässigen Beeinträchtigungen anderer Komponenten zu bewirken. Erdung Der Betreiber hat in den Gebäuden und Räumen für die Einrichtungen der Kommunikations-plattform ausreichend dimensionierte Anschlussmöglichkeiten (Erdpotentiale) vorzusehen. Die Bezugserde ist in den meisten Fällen die Gebäudeerde in Form der Haupterdsammelschiene. Das Gehäuse des Streckengerätes ist zu erden. Die Schirmung der Außenkabel ist an der Kabel-durchführung des Stellwerksgebäudeeinganges aufzulegen. Beim Einbau der Baugruppenträger in den Tragrahmen ist zu beachten, dass diese impedanzarm miteinander verbunden werden. Für Maßnahmen zum Personenschutz gilt die [DIN VDE 0100]. Isolationskoordination Isolationsstreckenbemessung sind nach [prEN 50124], [DIN VDE 0110], [DIN VDE 0831] und [DIN VDE 804] durchzuführen. Schirmung Die Erfüllung der Forderungen nach einer EMV-gerechten Elektroausrüstung soll im Wesentlichen durch das Gerätekonzept erreicht werden. Die Schirme von Signalkabeln sind so mit Masse zu verbinden, dass Störströme die interne Elektro-nik und das interne Bezugspotential nicht beeinflussen.

3.1.1.2 Systemumgebung Fahrzeugeinrichtung und dezentrale Streckeneinrichtung

Züge für den FFB erhalten eine fahrzeugtaugliche FFB-Rechnereinrichtung. Weiterhin werden die dezentralen Streckeneinrichtungen (Weichen, Bahnübergänge, Gleissperren – im Folgenden auch Fahrwegelemente genannt) mit einer FFB-Steuereinrichtung ausgerüstet. Die Anforderungen zur Systemumgebung der Fahrwegelemente sind mit den Anforderungen zur Systemumgebung auf Fahrzeugen abgedeckt. Beim Funk Fahr Betrieb werden in den Fahrwegelementen die gleichen Komponenten als Kommunikationsplattform wie in den Fahrzeugen verwendet. Aus diesem Grunde werden für die Systemumgebung der Fahrwegelemente die gleichen Anforderungen wie für die Systemumgebung der Fahrzeugeinrichtung angenommen.

3.1.1.2.1 Umweltbedingungen

Umgebungstemperatur der Baugruppen Die Anforderungen an die Betriebssicherheit der Baugruppen ergeben sich aus der [IEC 60571], [EN 50125] und der [EN 50155].

14

Temperaturbereich Bedingung Von –25°C bis +70°C Dauerbetrieb mit Einhaltung der gewährleisteten

Toleranzen Von –30°C bis -25°Cund von +70°C bis +85°C

Kurzzeitbetrieb (10 min) ohne Einhaltung der Toleranzen Abweichungen mit Wirkung zur sicheren Seite

Von –35°C bis -30°C Keine irreversiblen Schäden bei abgeschaltetem Gerät

Tabelle 5: Baugruppenumgebungstemperatur

Die genannten Temperaturen sind die Bauelemente-Grenztemperaturen in unmittelbarer Umgebung der Bauelemente. Durch die beim Betrieb auftretende Erwärmung sollen die zulässigen Grenztemperaturen der Betriebsmittel nicht überschritten werden. Umgebungstemperatur Rechnerrahmen Für den Rechner muss eine Umgebungstemperatur (Eintrittslufttemperatur unterster Baugruppen-träger) von -25 °C bis +55 °C festgelegt werden. Beim Einschalten des Rechners muss dieser Temperaturbereich eingehalten sein, d.h. die Umge-bungstemperatur muss in diesem Bereich liegen. Luftfeuchte Nach [EN 50155] und [EN 50125] gelten folgende Feuchtebeanspruchungen:

• Jahresmittel <=75% rel. Luftfeuchte • an 30 Tagen im Jahr andauernd = 95% rel. Luftfeuchte • an den übrigen Tagen gelegentlich = 85% rel. Luftfeuchte

Betriebsmäßig verursachte seltene und leichte Feuchtigkeitskondensationen dürfen nicht zu irgendwelchen Funktionsstörungen oder Ausfällen führen. Höhenlage Die signaltechnisch nichtsichere Kommunikationsplattform ist für eine Höhe von -120 m bis zu 2000 m über NN ausgelegt und erfüllt damit die Forderungen der [EN 50123]. Schockbeanspruchung Nach [EN 50125] bzw. [EN 50155] gelten folgende Schockbeanspruchungen. Die Geräte auf Fahrzeugen müssen den mechanischen Beanspruchungen an der Einbaustelle ohne Beeinträchtigung ihrer Funktion und ohne Änderung ihrer Betriebslage standhalten.

15

Richtung der Beanspruchung Scheitelwert der Amplitude / Dauer der Sinushalbwelle

Lage des Betriebsmittels Vertikal Quer Längs Einrichtungen direkt am Wagenkasten oder Unterflur montiert

30 m/s2 / 30 ms 30 m/s2 / 30 ms 50 m/s2 / 30 ms

Betriebsmittel und Bauelemente in Rahmen und Gehäusen am Wagenkasten oder Unterflur montiert

30 m/s2 / 30 ms 30 m/s2 / 30 ms 50 m/s2 / 30 ms

Tabelle 6: Stoßbeanspruchung für Betriebsmittel auf Bahnfahrzeugen nach [EN 50125]

Schwingbeanspruchung Für die Standfestigkeit gegen Schwingbeanspruchungen im und am Fahrzeugkasten müssen die Betriebsmittel der Signalanlagen nach [EN 50125] und [EN 50155] der unten aufgeführten Tabelle dimensioniert und geprüft werden [IEC 60068]. Lage des Betriebsmittels

Masse des Betriebs-mittels kg

Frequenz-bereich Hz

Übergangs-frequenz Hz

Auslenkungs-amplitude unterhalb der Übergangs-frequenz mm

Beschleunigungsamplitude oberhalb der Übergangs-frequenz m/s2

Einrichtungen direkt am Wagenkasten oder Unterflur montiert

>2000 <2000

1-35 5-100

8,2 7,1

0,75 1,5

2 3

Betriebsmittel und Bauelemente in Rahmen und Gehäusen am Wagenkasten oder Unterflur montiert

>30 3-30 0,3-3 <0,3

5-150

8,2 8,4 8,7 22,5

1,5 2,5 5 1,5

4 7 15 30

Tabelle 7: Schwingbeanspruchung für Betriebsmittel auf Bahnfahrzeugen nach [EN 50125]

Grenzwerte Das kurzzeitige Erreichen der zugelassenen Grenzwerte soll nicht zur Einschränkung der Zuverlässigkeit der Anlagen führen. Ständiger oder langfristiger Betrieb an den Grenzwerten oder außerhalb der Grenzwerte darf zu Zuverlässigkeitsminderungen führen. Um solche Zuverlässig-keitsminderungen zu vermeiden, sind zwischen Errichter und Betreiber Maßnahmen zur Verhinderung derartiger Betriebszustände zu vereinbaren. Schutzart

16

Der Standardschrank für die Kommunikationsplattform ist zum Einbau in die Fahrgast- oder

17

Bei Spannungen >100 V muss die Rückleitung über die Rückleitungssammelleitungen erfolgen.

Führerstandskabinen der Fahrzeuge bzw. den Maschinenraum vorgesehen. Er ist nach [DIN VDE 0470] in der Schutzklasse IP54 ausgelegt.

3.1.1.2.2 Stromversorgung

Batteriespannungen Die Stromversorgung ist nach [EN 50155] für die Fahrzeugbatteriespannungen von 24 V, 48 V, 72 V und 110 V ausgelegt. Abweichungen der Batteriespannung von der Nennspannung Nach [EN 50155] sind die Geräte bei Speisung aus einer Batterie für folgende Spannungsgrenzen der Nennspannung ausgelegt.

• untere Grenze 0,7fach • obere Grenze 1,25fach

Hierbei muss die Einhaltung der technischen Daten gewährleistet sein. Für 2 sec ist mit der 0,6fachen bis 1,4fachen Nennspannung zu rechnen. Dieses hat üblicherweise keinen Einfluss auf den Betrieb. Unter „worst case“-Bedingungen kann eine Sicherheitsabschaltung erfolgen. Die Schnittstelle für diese Eigenschaften bilden die Übergabeklemmen/-stecker im Einbauraum. Anschluss der Kommunikationsplattform an das Bordnetz Ein gemeinsamer Anschluss artfremder Verbraucher und der Kommunikationsplattform an lange Stichleitungen führt zu unerwünschten Beeinflussungen. Der Anschluss der Kommunikations-plattform an das Versorgungsnetz muss daher unmittelbar an der Batterie erfolgen und separat abgesichert werden. Als Leitungsschutz ist eine träge Schmelzsicherung oder ein Sicherungs-automat mit C-Charakteristik erforderlich.

3.1.1.2.3 EMV-Bedingungen

Die elektrische Ausrüstung des Fahrzeuges mit den Leistungsteilen, der empfindlichen Steuer-elektronik und den Bussystemen erfordert eine Ausführung der Anlage, die der EMV entspricht. Die Kommunikationsplattform muss die EMV-Prüfung nach den Normen [EN 50121] Teile 2 und 3, [EN 50081-2] und [EN50082-2] erfüllen. Es sind Vorkehrungen getroffen, dass die elektronischen Einrichtungen im Fahrzeug nicht gestört werden und das Fahrzeug wiederum nicht die zugelassenen Werte als aktiver Störsender über-schreitet. Erdung Die Erdung der Kommunikationsplattform erfolgt über die Fahrzeugmasse. Der Minuspol der Rechnerspannungen, die Gehäuse, der Schrank und die Rechneraufbauten sind an Fahrzeugmasse/-struktur gelegt. Nach [DIN VDE 0115-1] darf der Fahrzeugkörper bei Spannungen <100 V in den Stromkreis mit einbezogen werden.

Isolationskoordination Die Isolationsstreckenbemessungen sind nach [prEN 50124] durchzuführen. Bei der Isolations-streckenbemessung ist der Verschmutzungsgrad 2 anzusetzen. Schirmung, Potentialausgleich Die Schirme von Signalkabeln sind so mit Masse verbunden, dass Störströme die interne Elektronik und das interne Bezugspotential nicht beeinflussen. Das Verfahren, wie der Schirm kontaktiert wird, ist ausschlaggebend, ob er schirmtechnisch wirkt oder nicht.

3.1.2 Organisatorische Randbedingungen

Die im Eisenbahnbetrieb eingeführten technischen Systeme haben im Vergleich zu Lösungen in der industriellen Automatisierungstechnik sehr lange Produktlebenszyklen. (Die noch heute bei der Berliner S-Bahn verwendete Fahrsperre wurde schon vor dem 2.Weltkrieg verwendet. Sie ist seit dem konstruktiv nur unwesentlich verändert worden). Werden zur Realisierung von Systemen für den Eisenbahnbetrieb Komponenten aus dem „norma-len“ Markt (IPC, GSM-System) verwendet, so ist der Diskrepanz zwischen den Produkt-lebenszyklen der zugekauften Komponenten und den erwarteten Produktlebenszyklen der eisenbahntechnischen Systeme ausreichend Aufmerksamkeit zu widmen. Aus technischer Sicht, ist in der Architekturphase die Portabilität der zu erstellenden Software zu beachten. Eine weitere, erst in den letzten Jahren verstärkt auftretende Randbedingung, ist die Forderung nach einem interoperablen, offenen System für die Funkzugbeeinflussung. Verschiedene europäische Spezifikationsbemühungen (z.B. UNISIG) unterstreichen dieses Vorhaben. Nationale Bahngesell-schaften, welche Fördermittel der Europäischen Union für Neubau- und Modernisierungsvorhaben ihrer Zugbeeinflussungsanlagen in Anspruch nehmen möchten, dürfen diese Förderungen nur für die Umsetzung europäisch standardisierter Funkzugbeeinflussungssysteme verwenden. Projekte der DB AG verfolgen aus einem weiteren Grund intensive Standardisierungsbemühungen. Durch die Privatisierung der Nebenstrecken müssen viele kleinere Betreibergesellschaften mit eigenen Fahrzeugen das Streckennetz gemeinsam benutzen. Um den Wettbewerb zu fördern und einheitliche Rahmenbedingungen auf dem Streckennetz zu schaffen, fordert das EBA standardisierte offene Systeme zur Zugbeeinflussung. Aus diesen Gründen ist auch für das nationale FFB-System der europäisch standardisierte EURORADIO-Protokollstack als Kommunikationsbasis verbindlich. Die organisatorische Selbstständigkeit von Kommunikationsdienstleistern (z.B. ARCOR) innerhalb der DB AG führt zu einer betriebswirtschaftlichen Abrechnung der Kommunikationsaufwendungen über genutzte Kommunikationsressourcen. Es besteht aus wirtschaftlichen Gründen somit die Forderung, den Verbrauch an Kommunikationsressourcen für die einzelnen Bahndienste zu minimieren. Diese Forderung erhält ebenfalls aus Sicht des beschränkten Frequenzbandes für das GSM/R Netz der Bahn Nachdruck. Als Konsequenz dieser Situation ist eine Integration von verschiedenen Bahndiensten nicht nur im Kommunikationsnetz, sondern auch innerhalb von Kommunikationskanälen angestrebt. Dieses erfordert eine leistungsfähige Kommunikations-plattform zur Diensteintegration auf Funk- und Festnetzabschnitten, die die spezifischen Bedürf-nisse der Bahnapplikationen (z.B. Durchsatz und Delayanforderungen) ausreichend unterstützt.

18

3.1.3 Kommunikationsanforderungen des Funk Fahr Betriebes

3.1.3.1 GSM/R

Die folgende Abbildung stellt die prinzipielle Struktur eines GSM/R-Netzes dar.

BTS BTS

BTSBTS

BTS BTS

BTSBTS

BTSBTS

BTS BTS

BTS

BTS

BSC

BSC

BSC

BSC

TCE

GMSC

TCE

MSC

S2M

VLR

HLRAC

Applikation

VLR

EIR

mobileApplikation

MS

MT2

OMC

Abbildung 1: Übersichtsbild Netzstruktur GSM/R

Die Netzstruktur eines GSM/R Bahn-Netzes entspricht grundsätzlich dem Aufbau öffentlicher GSM-Netze. In den ersten FFB-Pilotanwendungen wurde die MSC (Mobile Service Switching Center) mit der streckenseitigen Kommunikationsplattform direkt gekoppelt, d.h. die MSC stellte mindestens einen Endteilnehmeranschluss (S2M) zur Verfügung. Im Folgenden werden die Funktionen der einzelnen Netzelemente der GSM/R-Infrastruktur über-blicksmäßig dargestellt: Base Transceiver Station (BTS)

• Sende- und Empfangseinheit für eine oder mehrere Zellen • Kodierung (Verschlüsselung) der auf der Funkschnittstelle übertragenen Informationen • Verbindung zur Mobilstation

Base Station Controller (BSC)

• Verwaltung von bis zu 50 BTS • Zuweisung von Funkkanälen • Inter – BSC – Handover – Steuerung • Relaisfunktion bezüglich Signalisierungsaustausch zwischen MS und MSC

19

Mobile Service Switching Center (MSC)

20

• Enthält Subscriber Identity Modul (SIM)

• Verbindungsaufbau (MOC – Mobile originating Call; MTC – Mobile terminated Call; MMC – Mobile to Mobile Call)

• Intra – MSC – Handover – Steuerung • Erfassen und Aktualisieren der Aufenthalte der Mobilteilnehmer • GMSC - Gatewayfunktion zu ISDN (Festnetzteilnehmer; andere Netze) • Interworking Unit (Nutzdatenstromadaption)

Transcoding Equipment (TCE)

• Datenratenadaptierung (Fullrate/Halfrate) Home Location Register (HLR)

• Datenbank für Teilnehmerdatenprofile • Berechtigungsprofile der zu verwalteten Teilnehmer • Aktueller MSC – Aufenthalt der verwalteten Teilnehmer

Visitor Location Register (VLR)

• Besucherdatenbank, die jedem MSC assoziiert ist • Temporäre Verwaltung aller Gastteilnehmer, die sich im Bereich dieser MSC aufhalten

(Kennung des jeweiligen Gastteilnehmers - IMSI; Aktueller Aufenthaltsort - Location Area Code;

Liste der Leistungen, die der Gastteilnehmer in Anspruch nehmen darf; Authentifizierungsdaten des Gastteilnehmers zur Nutzdatenverschlüsselung auf der Luftschnittstelle)

Equipment Identity Register (EIR)

• Datenbank, in der die Hardwarekennungen der Endgeräte abgelegt sind • Hardware Identifikation – International Mobil Equipment Identity – IMEI • Schwarze Liste (gesperrte Endgeräte)

Authentication Center (AC)

• Stellt die für die Authentifizierung und Verschlüsselung erforderlichen Informationen auf Anfrage eines VLR’s zur Verfügung

• Schutz der GSM-Netzes vor unbefugter Benutzung • Cloning-Schutz der Mobilteilnehmer (Schutz vor missbräuchlicher Nutzung von

Teilnehmerdatenprofilen) Operations and Maintenance Center (OMC)

• Überwachung aller Netzelemente • Einbringen neuer Softwareversionen (Upgrade)

Mobile Station (MS)

• Mobiles Endgerät inkl. MT2 – Anschluss (Nutzdateninterface)

Subscriber Identity Module (SIM) • PIN / PUK – Prüfung • Authentifizierung – Assoziiert das Teilnehmerverhältnis • SMS-Speicher

Die folgende Tabelle gibt einen Überblick über die verwendeten Frequenzbereiche von GSM-Systemen im GSM 900 Band:

Frequenzband System MS transmit / BTS receive (MHz)

MS receive / BTS transmit (MHz)

Anzahl verfügbarer FDMA – Trägerfrequenzpaare (Trägerfrequenz-abstand 200 kHz)

Gesamtzahl verfügbarer TDMA-Kanalpaare inklusive Signalisierungskanäle(8 Zeitschlitze pro Trägerfrequenz)

Standard GSM 900 890 - 915 935 - 960 124 992 Extended GSM 900 880 - 915 925 - 960 174 1392 GSM/R (delta zu Extended GSM 900)

876 - 880 921 - 925 19 152

Tabelle 8: Frequenzbereiche von GSM-Systemen

Entsprechend vorstehender Tabelle steht für das GSM/R-Sytem exklusiv nur eine sehr beschränkte Anzahl von FDMA-Trägerfrequenzpaaren zur Verfügung (siehe auch [24]). Der effektiven Nutzung dieser gegebenen Ressourcen kommt daher eine besondere Bedeutung zu. Die folgende Abbildung zeigt beispielhaft die Einbettung signaltechnisch sicherer und nichtsicherer Applikationen (Diensteintegration) mit Hilfe der Kommunikationsplattform (GW) unter Nutzung des GSM/R-Systems und unter Priorisierung des sicherheitsrelevanten Kommunikationsbedarfs.

21

GSM-R-Netz

Diagnose ATO ATP GW

Mobile

ATP

GW

Mobile

FwE (BÜ)

ATP

GW

Mobile

FwE (Weiche)

ATP

GW

Mobile

FwE (Weiche)

ATP GW

FFB-Zentrale n

ATO GW

Zentrale Dienste

Diagnose

GW

FFB-Zentrale n+1

ATP

Abbildung 2: Diensteintegration der Kommunikationsplattform unter Nutzung des GSM/R-Systems

Durch prioritätsgesteuerte Multiplexmechanismen in der Transportschicht des EURORADIO – Protokollstacks wird die durch den GSM/R-Nutzdatenkanal zur Verfügung gestellte Kommunika-tionsbandbreite optimal entsprechend den Bedürfnissen und Prioritäten der beteiligten Bahnapplikationen (ATP / ATO / Diagnose) aufgeteilt.

3.1.3.2 Kommunikationsverhalten der FFB-Applikation

Die Kommunikationsobjekte eines FFB-Systems sind Objekte, die über eine Kommunikations-plattform verfügen. Sie lassen sich wie folgt klassifizieren:

• FFB-Zentrale • Fahrzeuge • Fahrwegelemente

Fahrwegelemente, die über eine Kommunikationsplattform verfügen sind:

• Weichen • Bahnübergänge (BÜ) und höhengleiche Bahnsteigzugänge • Schlüsselsperren • Gruppen von Fahrwegelementen

22

23

Übertragung relativ kurzer Diagnoseereignismeldungen (z.B. Replikaausfall siehe 3.3.1) und zum

Die einzelnen Kommunikationsobjekte eines FFB-Systems bestehen je nach Ausprägung aus mindestens einer signaltechnisch sicheren bzw. nichtsicheren Bahnapplikation (siehe Abbildung 2). Die ATP-Applikation (Automatik Train Protection) ist in unterschiedlichen Ausprägungen in allen Kommunikationsobjekten mit Sicherheitsverantwortung vorhanden und muss in einer signaltechnisch sicheren Umgebung ablaufen (siehe 3.3.1). Die ATP-Applikation des Fahrzeuges enthält den Streckenatlas mit allen Informationen (z.B. zulässige Höchstgeschwindigkeit, Langsam-fahrstellen, Weichen, Bahnübergänge) über den Aufbau der befahrbaren Strecken. Entsprechend den ortsbezogenen Informationen des Streckenatlas und dem Aufenthaltsort des Fahrzeuges ermittelt die ATP-Applikation die momentan zulässige Höchstgeschwindigkeit unter Beachtung aller Schutzstrecken und Durchrutschwege (Sicherheitsabstände). Überschreitet die Ist-Geschwindigkeit des Fahrzeuges die momentan zulässige Höchstgeschwindigkeit wird von der ATP-Applikation die Zwangsbremse angesteuert. Die laut Streckenatlas zu befahrenden Fahrwegelemente werden unter Beachtung aller Schutzstrecken und Durchrutschwege von der ATP-Applikation des Zuges signaltechnisch sicher angesteuert. Die ATP-Applikation der FFB-Zentrale erteilt dem Fahrzeuggerät den Auftrag, einen bestimmten Streckenabschnitt zu durchfahren. Die ATP-Applikationen der Fahrwegelemente sind als eigenständige Systeme konzipiert (d.h. ein Stellwerk zur zentralen Ansteuerung von u.a. Weichen wird nicht benötigt – siehe auch [26] und [27]). Jeder Stellauftrag vom Fahrzeug oder ersatzweise von der FFB-Zentrale (bei Fahrzeugen ohne FFB-Ausrüstung) wird bestätigt oder abgelehnt. Die signaltechnisch sichere logische Verriegelung von Stellzuständen (Verhinderung der gleichzeitigen Ausführung konkurrierender Stellanweisungen) der Fahrwegelemente (Weiche: rechtsbelegt/linksbelegt/nicht belegt; BÜ: offen/geschlossen) wird von der ATP-Applikation des entsprechenden Fahrwegelements sichergestellt. Die ATP-Applikation des BÜ verfügt über einen signaltechnisch sicheren, richtungssensitiven Abschaltsensor der vom Zug überfahren wird. Mit Hilfe dieses Sensors ist es der BÜ-ATP-Applikation möglich, nach Durchfahrt des Zuges, den BÜ ohne Stellanweisung der ATP-Applikation des Fahrzeuges zu öffnen (siehe auch [25]). Die Kommunikation zwischen den ATP-Applikationen ist als einkanalig signaltechnisch sichere Datenübertragung realisiert (siehe 3.2 und 3.3.3). Die optionale ATO-Applikation (Automatik Train Operation) kann in unterschiedlichen Aus-prägungen in den Kommunikationsobjekten der Fahrzeuge vorhanden sein. Sind dispositorische Angaben (z.B. angepasster Fahrplan) von den ATO-Applikationen der Fahrzeuge zu berücksichti-gen, ist mindestens eine streckenseitige ATO-Applikation erforderlich. ATO-Applikationen haben keine Sicherheitsverantwortung. Die ATO-Applikation dient u.a. zur Entlastung des Triebfahr-zeugführers indem sie folgende regelungstechnische Aufgaben (oder Teile davon) übernimmt:

• Ansteuerung von Antrieb und Betriebsbremse unter Beachtung der Sollgeschwindigkeit • punktgenaues Halten am Bahnhof bzw. Haltepunkt • energieoptimales Fahren unter Beachtung des Streckenatlas und der momentanen

Fahrplansituation Die fahrzeugseitige Diagnoseapplikation mit Sicherheitsverantwortung (juridical recorder) kommuniziert nicht mit Systemen außerhalb des Fahrzeuges. Eine Schnittstelle zur Kommunika-tionsplattform ist nicht vorhanden. In Abbildung 2 sind neben ATP- und optionaler ATO-Applikation die für eine zentralisierte Fahrzeugdiagnose notwendigen Diagnoseapplikationen dargestellt. Der Kommunikationsbedarf der fahrzeugseitigen Diagnose besteht zum einen in der

anderen in der niederprioren Übertragung von Massendaten (z.B. Speicherabzug bei Replika-ausfall). Die Kommunikationsplattform (GW) in der Ausprägung als signaltechnisch nichtsicher Vorrechner (siehe Abbildung 20) stellt den angeschlossenen Bahnapplikationen unter Priorisierung des sicherheitsrelevanten Kommunikationsbedarfs Nutzdatenkanäle zur Verfügung. Schnittstellen der Kommunikationsplattform zum GSM/R-ISDN-Netz in den verschiedenen Komponenten sind:

• in der FFB-Zentrale ist die Kommunikationsplattform über eine S2M-Karte mit dem ISDN verbunden

• auf dem Fahrzeug ist die Kommunikationsplattform über ein oder zwei Mobiles mit dem GSM/R-Netz verbunden

• in den Fahrwegelementen ist die Kommunikationsplattform entweder über ein Mobile mit dem GSM/R-Netz oder über eine S0-Karte mit dem ISDN-Netz verbunden.

Die folgende Abbildung stellt die möglichen Kommunikationsbeziehungen im FFB-System (ohne optionale ATO und zentrale Dienste) dar:

FFB-Zentrale

Fahrzeuge Fahrwegelemente

2 1 3 4

5

6

Abbildung 3: Kommunikationsbeziehungen im FFB-System

Über die nummerierten Kommunikationsbeziehungen werden die folgenden Nachrichten der FFB-Anwendung ausgetauscht (siehe auch [28]):

1) Fahrweganforderung, Positionsmeldung (Abschnittsfreigabe), Fehlermeldung 2) Fahrwegzuweisung, Statusabfrage 3) Statusanfrage, Stellanweisung 4) Statusmeldung, Fehlermeldung 5) Stellanweisung, Statusabfrage 6) Statusmeldung, Quittungsmeldung, Fehlermeldung

Die Anzahl der Fahrwegelemente ist im FFB-System deutlich größer, als die Anzahl der Zentralen und Fahrzeuge. Sie bestimmen die FFB-Kommunikationsstruktur und die Anforderungen an die Kommunikationsplattform maßgeblich. Das FFB-System ist durch schnell wechselnde, kurze Kommunikationsbeziehungen zwischen verschiedenen Instanzen gekennzeichnet.

24

3.1.3.2.1 Charakteristik der Kommunikation Zentrale - Fahrzeuge/Fahrwegelemente

Im FFB-Regelbetrieb verwaltet die FFB-Zentrale Fahrzeugstandorte und Fahrwege, die von Fahr-zeugen angefordert werden. Zusätzlich sind Positionsmeldungen der Fahrzeuge entgegenzunehmen und zu verwalten. Im Fall nichtausgerüsteter Fahrzeuge hat die FFB-Zentrale zusätzlich die Auf-gabe, die variablen Streckenelemente (Weichen werden entsprechend den Anweisungen des Fahr-dienstleiters gestellt; BÜs werden von nichtausgerüsteten Fahrzeugen durch Befahren der Aus-schaltmittel geschlossen) für diese Fahrzeuge einzustellen.

Abbildung 4: Kommunikation der FFB-Zentrale mit Fahrzeugen und Fahrwegelementen

Aufgrund der Verwendung eines Streckenatlas auf den Fahrzeugen sind alle Kommunikationen der FFB-Zentrale mit Fahrzeugen vom Datenvolumen her gering. Die Gesamtdauer einer FFB-Kommunikation inklusive Verbindungsaufbau beträgt in diesem Fall typischerweise 20 bis 30 Sekunden. Die Gesamtzahl der gleichzeitigen Kommunikationsverbindungen zwischen Zentrale, Fahrzeugen und Fahrwegelementen ist im Regelbetrieb im wesentlichen durch die Anzahl der Fahrzeuge bestimmt, die sich gleichzeitig in Betrieb befinden. Zusätzlich kann der Fahrdienstleiter Statusabfragen und Einstellungen von Fahrwegelementen vornehmen. Mit Fahrwegelementen kommuniziert die FFB-Zentrale nur selten (bei Statusabfragen oder Störungen).

3.1.3.2.2 Charakteristik der Kommunikation Fahrzeug - Fahrwegelemente

Im FFB-Regelbetrieb erhält ein Fahrzeug einen Fahrweg von der Zentrale zugeteilt. Aufgabe des Fahrzeugs ist es dann unter anderem, die variablen Fahrwegelemente (z.B. BÜs, Weichen) zeitgerecht einzustellen. Dies geschieht unter Verwendung der auf dem Fahrzeug verfügbaren Streckenatlasdaten.

Abbildung 5: Kommunikation eines Fahrzeugs mit Fahrwegelementen

Aufgrund der Verwendung eines Streckenatlas auf den Fahrzeugen sind alle Kommunikationen des Fahrzeuges mit Fahrwegelementen vom Datenvolumen her gering. Die reine Übertragungszeit der Nutzdaten beträgt ca. 2-5 Sekunden und ist damit deutlich niedriger als die für den Verbindungsaufbau benötigte Zeit, die typischerweise bei ca. 20 Sekunden liegt. FFB-Strecken weisen oft eine relativ hohe Dichte von Fahrwegelementen auf; d.h. die FFB-Kommunikation wird maßgeblich durch die Kommunikationen zwischen Fahrzeugen und Fahrwegelementen bestimmt. Aufgrund der kurzen Anwendungstelegramme ergibt sich abhängig von der Fahrzeuggeschwindigkeit eine rasch wechselnde Folge von kurzen Kommunikationen. Dies

25

kann bei hohen Fahrzeuggeschwindigkeiten dazu führen, dass das Fahrzeug mit mehreren Fahrweg-elementen gleichzeitig kommunizieren muss. Die folgende Abbildung zeigt für verschiedene Geschwindigkeiten die maximal zur Verfügung stehende Kommunikationszeit für jedes Fahrwegelement als Funktion der Fahrwegelementdichte.

Kommunikationszeit pro Fahrwegelement als Funktion der Fahrwegelementdichte

0

10

20

30

40

50

60

70

80

1 2 3 4

Fahrwegelementdichte (1/km)

Abbildung 6: Zur Verfügung stehende Kommunikationszeit eines Fahrzeuges pro Fahrwegelement für unterschiedliche Fahrzeuggeschwindigkeiten v

Für drei Fahrwegelemente pro Kilometer beispielsweise stehen bei einer Fahrzeuggeschwindigkeit von 80 km/h maximal 15 Sekunden Kommunikationszeit pro Fahrwegelement zur Verfügung. Dies beinhaltet, wie aus der folgenden Abbildung ersichtlich:

• die Zeit für den Verbindungsaufbau (signaltechnisch nichtsicher – GSM/R-Datenlink, asynchrones HDLC der Linkebene des Euroradio Protokollstacks sowie das Transportprotokoll TP2 der Transportebene des Euroradio Protokollstacks[EURORADIO])

• die Authentifizierung inkl. Vereinbarung eines Session-Keys (signaltechnisch sicher – Euroradio Protokoll – Primitiven AU1, AU2, AU3 und AR)

• den Stellbefehl an das Element (Applikations PDU mit kryptologischem Sicherheitsanhang entsprechend Euroradio)

• die Rückmeldung vom Element (Applikations PDU mit kryptologischem Sicherheitsanhang entsprechend Euroradio)

v= 160 km/h

v= 80 km/h

v= 100 km/h

v= 50 km/h

26

• den Verbindungsabbau (geordneter Verbindungsabbau mit signaltechnisch nichtsicherer Übermittlung des Verbindungsabbaugrundes).

S t e l l b e f e h l

S afty layer

F a h rze u g(a b g e h e n d e r R u f)

A TP -A pplikation

K om m un ikations-plattfo rm (G W )

G S M R(M ob ile)

S icherhe itsve rantw ortung

S A _ C O N _ R E QT _ C O N _ R E Q( i n c l . A U 1 )

E urorad io

signa ltechnisch n ichtsicher

G S M R / IS DNZugsicherung

N _ C O N _ R E Q

F w E(a n k o m m e n d e r R u f)

G S M R(S2M )

E urorad io

K om m unikations-plattfo rm (G W )

S icherhe itsve rantw ortung

S afty layerA TP-A pplikation

Zugsicherung

N _ C O N _ I N D

N _ C O N _ R S P

N _ C O N _ C N F

T P 2 _ C R - T _ P D U

A u f b a u L i n k e b e n e E u r o r a d io p r o t o k o ll ( a s y n c r o n e s H D L C )

T _ C O N _ I N D( i n c l . A U 1 )

T _ C O N _ R S P( i n c l . A U 2 )

T P 2 _ C C - T _ P D U

T _ C O N _ C N F( i n c l . A U 2 )

A U 3 - S A _ P D U

S A _ C O N _ I N D

S A _ C O N _ R S P

A R - S A _ P D U

S A _ C O N _ C N F

R E Q - A T P _ P D U

A K N - A T P _ P D U

R ü c k m e l d u n g

A b b a u L i n k e b e n e E u r o r a d io p r o t o k o l l ( a s y n c r o n e s H D L C )

T P 2 _ D R - T _ P D U

T P 2 _ D C - T _ P D U

S A _ C O N _ R E L T _ C O N _ R E L( i n c l . R E A S O N )

T _ D I S C O N( i n c l . R E A S O N )

S A _ D I S C O N

T _ D I S C O N

S A _ D I S C O N

N _ C O N _ R E L

N _ D I S C O NN _ D I S C O N

S t e l l b e f e h l

R ü c k m e l d u n g

Abbildung 7: Beispiel der Kommunikationsaktivität zwischen Fahrzeug und Fahrwegelement

Es ist abhängig von der Dichte der Fahrwegelemente und der Zuggeschwindigkeit notwendig, mit mehreren Fahrwegelementen gleichzeitig vom Fahrzeug aus zu kommunizieren. Dies stellt eine wesentliche Forderung an das FFB-Kommunikationssystem dar.

27

3.1.3.2.3 Kommunikationslast zwischen Fahrzeug und Fahrwegelementen

28

Die realen Performance-Anforderungen zwischen Fahrzeugen und Fahrwegelementen liegen zwischen folgenden "best case" und "worst case" Szenarien. Das best case Szenario produziert minimale Kommunikationslast, charakterisiert durch:

• 1 Ruf pro Fahrwegelement (z.B. BÜs ohne Statusrückmeldung) • Positionsmeldungen nur in Bahnhöfen • zuweisbare Fahrwege nur von Bahnhof zu Bahnhof

Das worst case Szenario produziert maximale Kommunikationslast, charakterisiert durch:

• 2 Rufe pro Fahrwegelement (z.B. BÜs mit Statusrückmeldung) • Positionsmeldungen in Bahnhöfen und Haltepunkten • zuweisbare Fahrwege von Bahnhof/Haltepunkt zu Bahnhof/Haltepunkt

3.1.3.3 Lastmodell

Das Lastmodell für den Funk Fahr Betrieb erfordert eine hohe Skalierbarkeit der Kommunikations-plattform. Für die Kommunikationsplattform ist folgendes statische Lastmodell für den Funk Fahr Betrieb (unter Anwendung der Gatewayarchitektur – siehe 4) gefordert: Statisches Lastmodell FFB 1 FFB-Zentrale Fahrzeug FWE Anzahl physikalischer Links (GSM/R-ISDN)

20 ISDN 2 GSM/R 1 GSM/R

Anzahl logischer Verbindungen 12 7 4 Datenübertragung in Senderichtung Telegrammlänge: Telegramme je log. Kanal / Zeit:

25 Bytes 1 / 5 s

120 Bytes 1 / 5 s

25 Bytes 1 / 5 s

Datenübertragung in Empfangsrichtung Telegrammlänge: Telegramme je log. Kanal / Zeit:

240 Bytes 1 / 5 s

240 Bytes 1 / 5 s

25 Bytes 1 / 5 s

Tabelle 9: Statisches Lastmodell FFB

Erläuterungen: 1 Im Modell bestehen alle Verbindungen über die gesamte Zeit (maximale Anzahl). Die Datenübertragung erfolgt unsynchronisiert zwischen den Verbindungen. Über jede logische Verbindung wird periodisch innerhalb der vorgegebenen Zeit ein Telegramm der vorgegebenen Länge gesendet und empfangen. Dieses Lastmodell dient der Simulation und Überprüfung einer maximalen Datenlast.

Weiterhin gilt für die Kommunikationsplattform das folgende dynamische Lastmodell für den Funk Fahr Betrieb:

Dynamisches Lastmodell FFB 1 FFB-Zentrale, Fahrzeug, Fahrwegelemente

Änderung der aufgebauten Verbindungen / min 6 Anzahl der Telegramme je logischer Verbindung Typischerweise

1 Sendetelegramm 1 Empfangstelegramm

Variable Telegrammlänge in den Grenzen 1 – 240 Bytes

Tabelle 10: Dynamisches Lastmodell FFB

Erläuterungen: 1 Das dynamische Lastmodell ist durch eine permanente Änderung in den Verbindungsrelationen gekennzeichnet. Die Anzahl der Verbindungen wird periodisch von Null bis zum Maximum aufgebaut und nach erfolgter Datenübertragung wieder abgebaut. Die Reihenfolge und die Zuordnung von logischen Verbindungen zu physikalischen Links ist dabei variabel (zufällig). Unmittelbar nach Aufbau jeder logischen Verbindung erfolgt ein Datendialog, bestehend aus einem Sende- und einem Empfangstelegramm. Die Länge und der Inhalt der Telegramme werden zufällig gewählt, mit den Schwerpunkten 25 und 120 Bytes. Das dynamische Lastmodell dient der Simulation und Überprüfung der Verbindungsänderungen.

3.1.3.4 Performanzanforderungen

An der Kommunikationsschnittstelle der FFB-Applikation sind die Performanzanforderungen Ende zu Ende (unter Anwendung der Gatewayarchitektur – siehe 4) entsprechend folgender Tabel-len gefordert. Die Performanzanforderungen an die Kommunikationsplattform setzen voraus, dass das unterlagerte Übertragungsmedium GSM/R-ISDN die erforderliche Dienstgüte dauerhaft erbringt.

29

Verbindungsaufbaudauer FFB 1 Ende zu Ende (p=95%)

GSM/R-ISDN (komplett, end to end) 14,2 s GSM/R-ISDN-GSM/R (komplett, end to end) 26,2 s GSM/R-ISDN-GSM/R-LAN (komplett, end to end) 27,2 s GSM/R-GSM/R (komplett, end to end) 21,7 s GSM/R-GSM-LAN (komplett, end to end) 22,7 s ISDN-GSM/R (bestehende Verbindung zur Zentrale, Verlängerung des Links GSM/R-ISDN)

26,2 s

GSM/R-LAN (bestehende Verbindung zur Zentrale, Verlängerung des Links GSM/R-GSM/R )

15,7 s

GSM/R-LAN (bestehende Verbindung zur Zentrale, Verlängerung des Links GSM/R-ISDN-GSM/R)

20,2 s

Transferverzögerung FFB Ende zu Ende 2

1 Telegramm 120 Bytes, p = 95 %

GSM/R-ISDN 3 s GSM/R-ISDN-GSM/R 4 s GSM/R-ISDN-GSM/R-LAN 4 s GSM/R-GSM/R 3,5 s GSM/R-GSM/R-LAN 3,5 s Max. Anzahl Verbindungen 3 Physikalisch

ISDN-GSM/R Logisch

FFB-Zentrale 20 ISDN 12 FFB-Fahrzeug 2 GSM/R 7 FFB-Dezentrale 1 GSM/R 4

Tabelle 11: Performanzanforderungen FFB

Erläuterungen: 1 Die Verbindungsaufbaudauer umfasst die Bestandteile Aufbau Netzwerkverbindung(en), Initialisierung der Kommunikationsprotokolle Funk und Sicherung der Verbindung (I&A-Dialog). Sie beginnt mit der Anforderung der neuen Verbindung an der Applikationsschnittstelle und endet mit der Meldung über die bereitstehende gesicherte Verbindung an die anfordernde Applikation. 2 Die Transferverzögerung beginnt mit der Übergabe des Applikationstelegramms an die Komponente Sicherung auf Sendeseite und endet mit der Übergabe des Empfangstelegramms von der Komponente Sicherung auf der Empfangsseite.

3 Die max. Anzahl Verbindungen ist im statischen und dynamischen Lastmodell nachzuweisen. FFB-Zentrale und Fahrwegelemente können als Gateways eingesetzt werden.

Die in den obigen Tabellen genannten Werte für die Performanz der Kommunikationsplattform und des Protokollstacks im signaltechnisch sicheren Rechner wurden unter folgenden Annahmen hergeleitet:

30

31

D1 = Phys. Verbindungsaufbaudauer GSM/R - ISDN = 6 s D2 = Phys. Verbindungsaufbaudauer ISDN – ISDN = 1 s D3 = Phys. Verbindungsaufbaudauer GSM/R – GSM/R = 10 s K = durchschnittlicher Übertragungszeitanteil für Fehlerkorrektur = GSM-Störungswahrscheinlichkeit [5%] * durchschnittliche Zeitdauer zur Korrektur defekter HDLC-Frames [2 s] = 100 ms Ü1 = Übertragungsverzögerung GSM/R (Mobile to fix) 1 Byte = 300 ms Ü2 = Übertragungsverzögerung GSM/R (Mobile to Mobile) 1 Byte = 600 ms Ü3 = Übertragungsverzögerung ISDN 1 Byte = 50 ms Ü4 = Übertragungsverzögerung LAN = 50 ms L1 = Durchlaufzeit im 4,8 kBit/s Übertragungskanal für 25 Bytes Nutzdaten (= 50 Bytes HDLC Frames) ohne Multiplex = 100 ms L2 = Durchlaufzeit im 4,8 kBit/s Übertragungskanal für 25 Bytes Nutzdaten (= 50 Bytes HDLC Frames) mit Multiplex (vier logische Kanäle) = 400 ms L3 = Durchlaufzeit im 4,8 kBit/s Übertragungskanal für 120 Bytes Nutzdaten (=200 Bytes HDLC Frames) ohne Multiplex = 400 ms L4 = Durchlaufzeit im 4,8 kBit/s Übertragungskanal für 120 Bytes Nutzdaten (=200 Bytes HDLC Frames) mit Multiplex (vier logische Kanäle) = 1600 ms V1 = Verarbeitungsdauer Euroradio-Sicherungsprotokoll inklusive Krypto = 100 ms V2 = Verarbeitungsdauer Rechnerkopplung Kommunikationsplattform – signaltechnisch sicherer Rechner = 100 ms V3 = Verarbeitungsdauer Kommunikationsplattform = 50 ms R = Lastreserve für Kommunikationsplattform = 100 ms T = Anzahl der zu übertragenden Telegramme für Verbindungsaufbau (2 * Netz, 4 * Kommunikationsplattform, 4 * Euroradio Safty Layer) = 10

Die aufgeführten Werte wurden unter den obigen Annahmen nach den Formeln aus nachstehender Tabelle abgeleitet. Dabei ist zu berücksichtigen, dass die angegebenen Werte ohne Berück-sichtigung der FFB-Applikationssoftware auf dem signaltechnisch sicheren Rechner erstellt wurden.

Verbindungsaufbaudauer FFB Ende zu Ende GSM/R-ISDN (komplett, end to end) D1+T*(Ü1+Ü3+L1+K+2*V3)

+8*(V1+V2)+R = 14,2 s GSM/R-ISDN-GSM/R (komplett, end to end) 2*D1+T*(2*Ü1+2*Ü3+2*L1+2*K

+3*V3)+8*(V1+V2)+R = 26,2 s GSM/R-ISDN-GSM/R-LAN (komplett, end to end) 2*D1+T*(2*Ü1+2*Ü3+Ü4+2*L1

+2*K+4*V3)+8*(V1+V2)+R = 27,2 s

GSM/R-GSM/R (komplett, end to end) D3+T*(Ü2+L1+2*K+2*V3) +8*(V1+V2)+R = 21,7 s

GSM/R-GSM/R-LAN (komplett, end to end) D3+T*(Ü2+Ü4+L1+2*K+3*V3) +8*(V1+V2)+R = 22,7 s

ISDN-GSM/R (Verlängerung ex. Link GSM/R-ISDN) D1+2*T*(Ü1+Ü3+L2+K) +3*T*V3+8*(V1+V2)+R = 26,2 s

GSM/R-LAN (Verlängerung ex. Link GSM/R-GSM/R ) T*(Ü2+Ü4+L2+2*K+3*V3) +8*(V1+V2)+R = 15,7 s

GSM/R-LAN (Verlängerung ex. Link GSM/R-ISDN-GSM/R)

T*(2*Ü1+Ü4+2*L2+2*K+4*V3) +8*(V1+V2)+R = 20,2 s

Transferverzögerung FFB 120 Bytes GSM/R-ISDN Ü1+Ü3+L4+K

+2*(V1+V2+V3)+R = 2,65 s GSM/R-ISDN-GSM/R 2*(Ü1+Ü3+K)+3*V3+L3+L4

+2*(V1+V2)+R = 3,55 s GSM/R-ISDN-GSM/R-LAN 2*(Ü1+Ü3+K)+Ü4+4*V3+L3

+L4+2*(V1+V2)+R = 3,65 s GSM/R-GSM/R Ü2+2*K+L4+2*(V1+V2+V3)

+R = 3,0 s GSM/R-GSM/R-LAN Ü2+Ü4+2*K+L4+2*(V1+V2)

+3*V3+R = 3,1 s

Tabelle 12: Berechnungsgrundlagen Performanzanforderungen FFB

Aus den FFB-Anforderung an die Performanz der Kommunikation Ende zu Ende inklusive signal-technisch sicheren Protokollfunktionalitäten werden folgende test- und validierbare Anforderungen an die Kommunikationsplattform (ohne Sicherungsschicht) in einer Simulationsumgebung GSM/R-ISDN abgeleitet:

32

Verbindungsaufbaudauer Ende zu Ende Kommunikationsplattform

GSM/R-ISDN (komplett, end to end) D1+T*(Ü1+Ü3+L1+K+2*V3) +8*(V1+V2)+R = 10,15 s

GSM/R-ISDN-GSM/R (komplett, end to end) 2*D1+T*(2*Ü1+2*Ü3+2*L1+2*K+3*V3)+8*(V1+V2)+R = 19,15 s

GSM/R-ISDN-GSM/R-LAN (komplett, end to end) 2*D1+T*(2*Ü1+2*Ü3+Ü4+2*L1 +2*K+4*V3)+8*(V1+V2)+R = 19,75 s

GSM/R-GSM/R (komplett, end to end) D3+T*(Ü2+L1+2*K+2*V3) +8*(V1+V2)+R = 15,65 s

GSM/R-GSM/R-LAN (komplett, end to end) D3+T*(Ü2+Ü4+L1+2*K+3*V3) +8*(V1+V2)+R = 16,25 s

ISDN-GSM/R (Verlängerung ex. Link GSM/R-ISDN) D1+2*T*(Ü1+Ü3+L2+K) +3*T*V3+8*(V1+V2)+R = 16,75 s

GSM/R-LAN (Verlängerung ex Link GSM/R-GSM/R ) T*(Ü2+Ü4+L2+2*K+3*V3) +8*(V1+V2)+R = 8,05 s

GSM/R-LAN (Verlängerung ex Link GSM/R-ISDN-GSM/R)

T*(2*Ü1+Ü4+2*L2+2*K+4*V3) +8*(V1+V2)+R = 10,75 s

Transferverzögerung Kommunikationsplattform 120 Bytes GSM/R-ISDN Ü1+Ü3+L4+K

+2*(V1+V2+V3)+R = 2,3 s GSM/R-ISDN-GSM/R 2*(Ü1+Ü3+K)+3*V3+L3+L4

+2*(V1+V2)+R = 3,1 s GSM/R-ISDN-GSM/R-LAN 2*(Ü1+Ü3+K)+Ü4+4*V3+L3

+L4+2*(V1+V2)+R = 3,2 s GSM/R-GSM/R Ü2+2*K+L4+2*(V1+V2+V3)

+R = 2,55 s GSM/R-GSM/R-LAN Ü2+Ü4+2*K+L4+2*(V1+V2)

+3*V3+R = 2,65 s

Tabelle 13: test – und validierbare Performanzanforderungen Kommunikationsplattform

Randbedingungen und Änderungen gegenüber ursprünglichen FFB-Anforderungen:

K= durchschnittlicher Übertragungszeitanteil für Fehlerkorrektur = 0 ms Begründung: In der Simulationsumgebung treten Übertragungsfehler infolge der drahtgebundenen Übertragung nur sehr selten auf, so dass dieser Einfluss vernachlässigt werden kann. V1 = Verarbeitungsdauer Euroradio-Sicherungsprotokoll inklusive Kryptographie = 0 ms Begründung: Das Euroradio-Sicherungsprotokoll ist in der Testumgebung nicht enthalten. R = Lastreserve für Kommunikationsplattform = 50 ms

33

Begründung: Die gesamte Lastreserve von 100 ms wird aufgeteilt auf die signaltechnisch sichere und auf die Kommunikationsplattform, so dass für die Testdurchführung mit der Kommunikationsplattform nur 50 ms anzusetzen sind. T = Anzahl der zu übertragenden Telegramme für Verbindungsaufbau (2 * Netz, 4 * Kommunikationsplattform) = 6 Begründung: Die I&A-Telegramme des Euroradio Sicherungsprotokolls sind bei der Testdurchführung nicht relevant.

3.2 Anforderungen bei Verwendung einer einkanaligen signaltechnisch sicheren

Datenübertragung über offene Netze

Der EURORADIO Protokollstack (sichere und nichtsichere Protokolle) dient der sicheren ver-bindungsorientierten Übertragung von Daten zwischen mobilen (Fahrzeugen) und ortsfesten Einrichtungen (Fahrwegelemente, Streckenzentrale) bzw. zwischen ortsfesten Streckenelementen und Streckenzentralen über offene Netze (GSM/R, ISDN). Er besteht aus einem Sicherungs-protokoll, welches signaltechnisch sicher zu entwickeln ist und einem Kommunikationsprotokoll, das keine Sicherheitsverantwortung besitzt (siehe auch [30] und [31]). Gemäß [EN50159-2] ist das signaltechnisch nichtsicheren EURORADIO Protokoll der Kommuni-kationsplattform Teil des grauen Kanals. Die Funktionalitäten mit Sicherheitsverantwortung laufen in einer signaltechnisch sicheren Komponente ‚Sicherung’ auf einem sicheren Mehrrechnersystem (SIL 4) ab. Zwei Kommunikationspartner kommunizieren über verschiedene Protokolle mitein-ander: dem Kommunikationsprotokoll (PNONSAFE) und dem Sicherungsprotokoll (PSAFE) (siehe Abbildung 8). Beide Protokolle sind in [EURORADIO] standardisiert. Das Sicherungsprotokoll (PSAFE) verwendet den kryptographischen Mechanismus Message-Authentifikationscode (MAC) zur Nachrichten-Authentifizierung und ein Identifikationsdialog zur gegenseitigen Partnerinstanz-Authentifizierung. Es bietet entsprechend [EN50159-2] Architektur A1 Schutz gegen die Gefährdungen Manipulation, Verfälschung und Einfügung von Daten. Die kryptographischen Mechanismen werden durch ein Offline-Schlüsselmanagement unterstützt. Der Zugang (DSAFE) zur sicheren Ende-Zu-Ende-Übertragung für Dienstbenutzer (Beispiel: FFB Applikation) wird oberhalb der Komponente Sicherung bereitgestellt. Diese Schnittstelle bietet zusätzlich die Möglichkeit, hochpriore Notinformationen mit direkter Weiterleitung an das Sub-system Kommunikation (signaltechnisch nichtsichere Kommunikationsplattform) zu übermitteln. Diese Daten werden dann ohne Sicherung und an allen Warteschlangen vorbei direkt an den Kom-munikationspartner übertragen.

34

offenes Netz

grauer Kanal

SubsystemKommunikation(SIL 0)

SubsystemKommunikation(SIL 0)

KomponenteSicherung(SIL 4)

KomponenteSicherung(SIL 4)

Schnittstellezumgrauen Kanal

Schnittstellezumgrauen Kanal

signaltechnisch sichere Umgebung

Schnittstellezur sicherenApplikationl

Schnittstellezur sicherenApplikationl

DSAFE

PSAFE

PNONSAFE

DSAFE

Abbildung 8: prinzipielle Struktur einer einkanalig sicheren Datenübertragung über offene Netze

3.2.1 EURORADIO Sicherungsverfahren

Um die Risiken zu reduzieren, die mit den in [EN 50159-2] genannten Gefährdungen Einfügung, Verfälschung und Manipulation verbunden sind, werden nach [EURORADIO] folgende Sicherungsverfahren (siehe auch [17]) angewendet:

• Nachrichten-Authentifizierung • Partnerinstanz-Authentifizierung

Die eingesetzten Sicherungsverfahren basieren auf den in EURORADIO spezifizierten Sicherungsmechanismen Message Authentication Code (MAC) und Authentifikationsprotokoll. Die nachfolgende Tabelle beschreibt die Beziehungen zwischen den einzelnen Gefährdungen und den zu ihrer Abwehr eingesetzten Sicherungsverfahren:

35

eingesetzte Sicherungsverfahren Gefahr

36

gebauten, takt-, befehls- oder transaktionssynchron arbeitenden und identisch programmierten Rechnerkanälen (Replika) (siehe [13] Kap. 6.3). Um die Wahrscheinlichkeit eines gleichzeitigen

Nachrichten-Authentifizierung Partnerinstanz-Authentifizierung Einfügung X Verfälschung X Manipulation X X

Tabelle 14: Beziehungen zwischen Gefährdungen und Sicherungsverfahren

Die Sicherungsverfahren Nachrichten-Authentifizierung und Partnerinstanz-Authentifizierung ermöglichen nur ein Erkennen einer Einfügung von Nachrichten durch Dritte. Ist der kryptographische Schlüssel bekannt, so bieten diese Sicherungsverfahren keinen Schutz. Die Risiken, die mit den in [EN 50159-2] genannten Gefährdungen Wiederholung, Auslassung, Resequenzierung und Verzögerung verbunden sind, können mit den in EURORADIO festgelegten Sicherungsverfahren Nachrichten-Authentifikation und Partnerinstanz-Authentifikation nicht reduziert werden. Für die Reduzierung der mit diesen Gefährdungen verbundenen Risiken müssen die sender- und empfangsseitigen Anwendungen Sorge tragen (Anwendungsregel). Weiterhin kann in den folgenden Situationen das Risiko durch die Gefährdungen Manipulation, Einfügung und Verfälschung nicht reduziert werden:

• sicherheitskritische Situation:

- Manipulation auf der Basis eines gültigen Sitzungsschlüssels (z.B. bei Insider-Wissen)

- Einfügung von Nutzerdaten in den Nachrichtenstrom auf der Basis eines gültigen Sitzungsschlüssels

- Verfälschung von Nutzerdaten auf der Basis eines gültigen Sitzungsschlüssels - Übertragung sicherheitsrelevanter Daten als hochpriore Daten

• nicht sicherheitskritische Situationen:

- Unterbrechung der Netzverbindung - Übertragung nicht sicherheitsrelevanter Daten als hochpriore Daten, da die

Anwendungen hochpriore Daten nur zur Übertragung fahrteinschränkender Informationen (z.B. Nothalt) nutzen dürfen (Anwendungsregel)

3.3 Anforderungen durch Kopplung einer signaltechnisch nichtsicheren

Kommunikationsplattform an mehrkanalig redundante signaltechnisch sichere

Rechner

3.3.1 Mehrkanalig redundante signaltechnisch sichere Rechner

Der mehrkanalig redundante signaltechnisch sichere Rechner (n-modulare Redundanz in der Aus-prägung 2-von-3; siehe [10] Kap. 4.5.5.) besteht aus drei voneinander unabhängigen, identisch auf-

Auftretens von Mehrfachfehlern infolge einer kanalübergreifenden Störbeeinflussung (trotz getroffener EMV-Schutzmaßnahmen) zu senken, können die Replika leicht phasenverschoben betrieben werden (d.h. die Replikas befinden sich dann trotz gleichzeitig auftretender Stör-beeinflussung in unterschiedlichen Programmabarbeitungszuständen). Zur Realisierung eines signaltechnisch sicheren Systems muss die Wahrscheinlichkeit des gleichzeitigen Auftretens von Mehrfachfehlern als hinreichend klein angenommen werden können. Eingelesene Prozessdaten werden parallel verarbeitet. Weicht das Verarbeitungsergebnis einer Replika von den anderen beiden ab, wird diese Störung sofort offenbart und die gestörte Replika inaktiv geschaltet (einfacher Kanalausfall). Das Verarbeitungsergebnis der verbleibenden Replikas wird ausgegeben. Die verbleibenden aktiven Replikas arbeiten als 2-von-2 System ohne Redundanz weiter. Weicht zu einem späteren Zeitpunkt (bevor das System durch Wartungsaktivitäten wieder in den 2-von-3 Betriebsmode überführt wurde) das Verarbeitungsergebnis der verbleibenden Replikas voneinander ab, wird das System inaktiv geschaltet (weiterer Kanalausfall). Mit zusätzlichen, niederprior parallel ablaufenden Prüfprogrammen werden aktive Replikas ständig kontrolliert. Dieses Prinzip garantiert eine sehr kurze Fehleroffenbarungszeit von Rechnerkanalausfällen. Auch zunächst noch verdeckte Kanalausfälle offenbaren sich kurzfristig. Die folgende Abbildung zeigt die prinzipielle Struktur eines mehrkanalig redundanten signaltechnisch sicheren Rechners in 2-von-3-Konfiguration.

Replika AEingabe

Synchronisation

Rechnerkern

Vergleich

Ausgabe

&

Datenaustausch(A --> B)

Datenaustausch(A --> C)

(A -- B)Vergleich

(A -- C)

Replika BEingabe

Synchronisation

Rechnerkern

Vergleich

Datenaustausch(B --> C)

Datenaustausch(B --> A)

(B -- C)Vergleich

(B -- A)

Replika CEingabe

Synchronisation

Rechnerkern

Vergleich

Datenaustausch(C --> A)

Datenaustausch(C --> B)

(C -- A)Vergleich

(C -- B)

Ausgabe

&Ausgabe

&

Abbildung 9: prinzipielle Struktur eines mehrkanalig redundanten signaltechnisch sicheren Rechners

Die ATP-Applikationen (Automatik Train Protection) des FFB-Systems (siehe Abbildung 2) nutzen jeweils als signaltechnisch sichere Ablaufumgebung mehrkanalig redundante signaltechnisch sichere Rechner. Derartige Ablaufumgebungen sind ausreichend robust gegenüber Byzantinischen Fehlern (siehe [10] Kap. 4.5.7.), weil:

• die Komponenten zum Verteilen bzw. Vergleichen der Eingangsdaten und die Votinglogik zur Freigabe der Stellenergie in separater Hardware realisiert sind. Infolge der Separation von Eingabeverteilung, Rechnerkern und Votinglogik ist die Wahrscheinlichkeit des gleichzeitigen Auftretens von verdeckten Mehrfachfehlern auch innerhalb einer Replika ausreichend gering.

12

345

12

345

37

• jede Replika über alle Eingangsdaten (Prozessgrößen, wie z.B. Momentangeschwindigkeit) verfügt und unabhängig von den anderen Replika verarbeitet.

• ein Datenaustausch (außerhalb der Eingabeverteilers) zwischen den Replika ausschließlich zu Votingzwecken erfolgt.

• die Votinglogik die Stellenergie für Prozessausgaben des ATP-Zugsicherungssystems kontrolliert. Eine fehlerhafte Replika wird durch Mehrheitsentscheidung der Nachbarreplika geblockt (Entzug der Stellenergie und Überführung in den Diagnosemodus), d.h. nur wenn alle anderen nicht geblockten Replika eine fehlerhafte Replika detektieren, blockt die Votinglogik diese Replika (Eine Fehlentscheidung auf Grund der fehlerhaften Replika selbst wird vermieden).

• die ATP-Applikationen des FFB-Systems jeweils nur einen signaltechnisch sicheren Rechner pro zu überwachende Komponente (Fahrzeug, FwE, FFB-Zentrale) nutzen (d.h. alle Prozesseingaben und Prozessausgaben werden komponentenbezogen zentralisiert verarbeitet bzw. angesteuert).

3.3.2 Struktur Koppelprotokoll

Das Koppelprotokoll dient der Organisation von verbindungsorientierten Nutzdatenkanälen zwischen der signaltechnisch nichtsicheren Kommunikationsplattform und dem sicheren Mehrfachrechnersystem. Die Diensteschnittstelle des Koppelprotokollstacks und das Nutzkanal-verhalten (verbindungsorientiert, asynchron, hoch priore Daten unterstützend und Telegramm-integrität bewahrend) sind identisch zum EURORADIO-Protokollstack. Die Eigenschaften des Koppelprotokolls (siehe 3.5.2) entsprechen grundsätzlich einem Tunnelprotokoll (Protokoll orga-nisiert einen Kommunikationsabschnitt zwischen zwei festgelegten Kommunikationspartnern),d.h. die in der Verbindungsanforderungsprimitive enthaltene Adressierungsinformation wird im Koppel-stack unverändert übertragen (getunnelt). Diese Adressierungsinformation ist für den Vermittlungs-akt in der signaltechnisch nichtsicheren Kommunikationsplattform bestimmt. Das Koppelprotokoll ist als einfaches Tunnelprotokoll ausgelegt, um die Komplexität der Kom-munikationsprotokolle im sicheren Mehrrechnersystem zu minimieren (durch das Auslagern signaltechnisch nichtsicherer Kommunikationsprotokolle, z.B. signaltechnisch nichtsicherer Teil der EURORADIO-Protokollschichten entsprechend Abbildung 12, ist die Komplexität der Kommu-nikationsprotokolle im sicheren Mehrrechnersystem auf das Koppelprotokoll reduziert). Der Protokollstack des Koppelprotokolls gliedert sich in eine Linkebene (LK) und eine auf die Dienste der Linkebene aufsetzende virtuelle Linkebene (VL).

3.3.2.1 Linkebene

Die Diensteschnittstelle der Linkebene (LK) (siehe Abbildung 10) stellt einen verbindungs-orientierten, fehlerkorrigierten, hoch priore Daten unterstützenden und die Telegrammintegrität bewahrenden Kanal bereit (bei redundanter Kopplung existieren mehrere Kanäle der Linkebene - siehe Abbildung 11). Der Aufbau und die Überwachung dieses Kanals erfolgt selbständig durch die Linkebene und unabhängig vom Kommunikationsbedarf auf der Virtuellen Linkebene. Beim Zusammenbruch der Linkebene durch äußere Einflüsse (Abschalten eines Kommunikationspartners, Ausfall der physischen Verbindung) versucht die Linkebene periodisch, den Kanal zu reetablieren.

38

3.3.2.2 Virtuelle Linkebene

Die virtuelle Linkebene (VL) bildet die virtuellen Nutzkanäle an ihrer Diensteschnittstelle auf die unter ihr liegende Diensteschnittstelle der Linkebene ab. Das Verhalten der Diensteschnittstelle der virtuellen Linkebene entspricht grundsätzlich [X.214]. Dementsprechend wird bei der Signalisierung in kommende und gehende Rufe unterschieden. In der folgenden Abbildung wird das prinzipielle Verhalten des Koppelprotokolls in der Setup-Phase dargestellt.

virtuelleLinkebene (VL)

Linkebene (LK)

gehender Ruf

CON_REQ-PDU

CON_CNF-PDU

Invoker

CON_CNF-Primitive

Linkebene (LK)

kommender Ruf

CON_IND-Primitive

CON_RSP-Primitive

Responder

CON_RSP-PDU

CON_REQ-Primitive

CON_IND-PDU

virtuelleLinkebene (VL)

Abbildung 10: Koppelprotokoll in Setup-Phase eines virtuellen Nutzkanals

Infolge der asynchronen Eigenschaften der virtuellen Nutzkanäle ist es notwendig, deren Flusskontrollzustand zu synchronisieren. Im Koppelprotokoll erfolgt diese Synchronisierung durch Flusskontrollprimitiven (VL_XON, VL_XOFF). Die Abbildung der Virtuellen Linkebene (VL_Primitiven) auf die Diensteschnittstelle der Linkebene (VL-PDU) erfordert die Berücksichtigung (Aufschalten) des Flusskontrollzustandes der Linkebene auf die Flusskontrollzustände der virtuellen Linkebene, sowie das korrekte Auslösen bestehender Kanäle an der Diensteschnittstelle der virtuellen Linkebene beim Zusammenbruch der Linkebene.

3.3.2.3 Redundante Kopplung

Um eine vollständig redundante Kopplung zwischen einem 2-von-3 signaltechnisch sicheren Rechner und zwei (redundanten) signaltechnisch nichtsicheren Kommunikationsplattformen zu ermöglichen und dabei sowohl den einfachen Ausfall einer Replika des signaltechnisch sicheren Rechners als auch den Ausfall einer signaltechnisch nichtsicheren Kommunikationsplattform zu kompensieren, werden vier Kopplungsprotokoll-Linkbündel (LK) benötigt. Der auf jeder Replika

39

des signaltechnisch sicheren Rechners identisch ablaufende Programmcode erhält durch Spiegelung der Eingangsdaten die Daten aller vier Links (Interface LK). Durch das Koppelprinzip erscheinen die zwei signaltechnisch nichtsicheren Kommunikationsplattformen jeweils mit zwei Links in jeder Replika des signaltechnisch sicheren Rechners. Die prinzipielle Verschaltung der redundant gekoppelten Kommunikationspartner ist in der folgenden Abbildung dargestellt.

Replika A

signaltechnisch sichererRechner (2-von-3)

virtu

elle

Lin

kebe

ne (V

L)

LK 1

LK 2

LK 3

LK 4

Inte

rface

LK 2

Inte

rface

LK 1

Replika B

virtu

elle

Lin

kebe

ne (V

L)

LK 1

LK 2

LK 3

LK 4

Inte

rface

LK 4

Inte

rface

LK 3

Replika C

virtu

elle

Lin

kebe

ne (V

L)

LK 1

LK 2

LK 3

LK 4

signaltechnischnichtsichereKommunikations-plattform A

virtu

elle

Lin

kebe

ne (V

L)

LK 1

LK 3

Inte

rface

LK 3

Inte

rface

LK 1

signaltechnischnichtsichereKommunikations-plattform B

virtu

elle

Lin

kebe

ne (V

L)

LK 2

LK 4

Inte

rface

LK 4

Inte

rface

LK 2

Abbildung 11: Prinzip der redundanten Ankopplung an ein 2-von-3 System

Zur effektiven Verwaltung der virtuellen Links (VL) auf den vier Linkbündeln werden Managementfunktionalitäten benötigt. Diese Managementfunktionalitäten lassen sich auch zur

40

Realisierung von redundanten Vermittlungsclustern der signaltechnisch nichtsicheren Kommunika-tionsplattform verwenden (siehe 4.7.1).

3.3.3 Rückwirkungsfreiheit bei einkanalig signaltechnisch sicherer

Datenübertragung

Die signaltechnisch nichtsichere Kommunikationsplattform als Bestandteil des grauen Kanals trägt keine Sicherheitsverantwortung. Es besteht aber die Möglichkeit der indirekten Beeinflussung des signaltechnisch sicheren Gesamtsystems durch die signaltechnisch nichtsichere Kommunikations-plattform über deren Verfügbarkeit (MTBF). Die Rückwirkungsfreiheit der Schnittstelle im signaltechnisch sicheren Rechner zur Kommunika-tionsplattform ist eine weitere Voraussetzung für das signaltechnisch sichere Verhalten des Gesamt-systems. Im folgenden wird auf die prinzipiellen Bedrohungen und mögliche Schutzmaßnahmen eingegangen.

3.3.3.1 Bedrohung durch den grauen Kanal

Die Protokolle des graue Kanals PNONSAFE sowie das Koppelprotokoll PKOPPEL zwischen der signaltechnisch nichtsicheren Kommunikationsplattform als Bestandteil des grauen Kanals und dem signaltechnisch sicheren Rechner tragen keine Sicherheitsverantwortung. Der signaltechnisch sichere Rechner als Ablaufumgebung des eingesetzten Sicherungsprotokolls (PSAFE) trägt Sicherheitsverantwortung (SIL 4). In der folgenden Abbildung wird die prinzipielle Struktur der Protokollkomponenten und deren Protokollstacks dargestellt.

41

o ffen e s N e tz

g ra u e r K a n al

S u b sy s te mK o m m u n ik a tion(S IL 0 )

s ig n a lte chn isc h s ich e re U m g e b un g

S chnitts te l lezu r s ichere nA pplika tion l

D S A FE

P S A F E

P N O N S A FE

P K O P P EL

S T A C K N O N S A F E

S T A C K K O P P E L

S T A C K S A F E

S T A C K K O P P E LK om p one nteS ic he ru ng(S IL 4 )

S u b sy s te mK o m m u n ik a tion(S IL 0 )

S chn itts te l lezu r s ichere nA pplika tion l

D S A FE

P K O P P E L

S T A C K N O N S A F E

S T A C K K O P P E L

S T A C K S A F E

S T A C K K O P P E LK om p one nteS ic heru ng(S IL 4 )

Abbildung 12: prinzipielle Struktur der Protokollkomponenten und deren Protokollstacks

Der Protokollstack STACKKOPPEL des signaltechnisch sicheren Rechners trägt aus seiner Koppel-funktion heraus keine Sicherheitsverantwortung. Es müssen aber Schutzmaßnahmen zur Vermei-dung von unzulässigen Rückwirkungen auf die signaltechnisch sichere Umgebung getroffen wer-den. Derartige Schutzmaßnahmen sind für den Koppelprotokollstack in der signaltechnisch nicht-sicheren Kommunikationsplattform nicht erforderlich. Stochastische oder systematische Störangriffe des grauen Kanals (Bedrohung) werden durch das Ende zu Ende wirkende EURORADIO Sicherungsprotokoll (PSAFE) abgewehrt (siehe 3.2.1).

3.3.3.2 Bedrohung durch Nichtverfügbarkeit der Kommunikation

Eine ausgefallene Kommunikation blockiert das gesamte Zugbeeinflussungssystem, so dass der Eisenbahnverkehr nur noch über sicherungstechnische Rückfallebenen (d.h. Deaktivierung des EURORADIO-basierten Zugbeeinflussungssystems und Übergabe der Sicherheitsverantwortung an ein alternatives Zugsicherungssystem u.U. mit geringerem Sicherheitslevel) abgewickelt werden kann. Besonders dann, wenn keine gleichwertige Rückfallebene zum Zugsicherungssystem verfügbar ist und manuelle Mitwirkung erforderlich ist, besteht die Gefahr einer wesentlichen Verschlechterung der Gesamtsystemsicherheit. Deswegen hat die Verfügbarkeit der Kommunikation für die Systemsicherheit einen hohen Stellenwert und führt zu besonderen Anforderungen an die nichtsichere Kommunikationsplattform und die unterlagerten Kommunikationsnetze. Diese Anforderungen können durch folgende Maßnahmen erfüllt werden:

• Einsatz von geeigneter hochverfügbarer Hardware • Verwendung von bewährter, stabiler und robuster Basissoftware (Betriebssystem,

Treiber) und Entwicklungsumgebung • Auswahl geeigneter Testverfahren, Testumgebung und Testziele

42

• Anwendung eines bewährten Softwareentwicklungsprozesses • Implementierung von Redundanz

3.3.3.3 Bedrohung durch physikalische Einflüsse

Der Nachweis der zufriedenstellenden Funktion der Kommunikationsplattform (Verfügbarkeit, Zuverlässigkeit, Robustheit) unter definierten äußeren Randbedingungen und der zulässigen Rückwirkung (mechanisch, thermisch, elektro-magnetisch) auf andere Komponenten im Zugbeeinflussungssystem ist mit der Betriebszulassung erbracht (Betriebszulassung). Die Nachweisführung beinhaltet auch die Analyse der Bedrohungen durch EMV-Einflüsse an Hardwareschnittstellen des signaltechnisch sicheren Rechners. Die Kopplung zur signaltechnisch nichtsicheren Kommunikationsplattform erfordert eine oder mehrere Hardwareschnittstellen zum signaltechnisch sicheren Rechner. Es müssen Schutzmaßnahmen zur Vermeidung von unzulässigen Rückwirkungen auf die signaltechnisch sichere Umgebung getroffen werden (z.B. unverlierbare Isolation durch spezielle Schutzmaßnahmen, wie z.B. Schutzstreckenbemessung und Schirmungslagen, im Netzteil des signaltechnisch nichtsicheren Kommunikationsrechners). Eine redundante Kopplung stellt höhere Ansprüche an die Schutzmaßnahmen. Es müssen Maßnahmen zur Vermeidung von unzulässigen Wechselwirkungen zwischen den Replikas (des signaltechnisch sicheren Rechners) über die signaltechnisch nichtsichere Kommunikationsplattform getroffen werden (z.B. unverlierbare Isolation durch spezielle Optoelektronische Koppler an den Eingängen des signaltechnisch sicheren Rechners).

43

4 Gatewayarchitektur der Kommunikationsplattform

4.1 Lösungen für den Kommunikationsengpass Fahrzeug - Fahrwegelemente

Die Kommunikations-Charakteristik der FFB-Anwendung mit schnell wechselnden, kurzen Kommunikationsbeziehungen bei vergleichsweise langen Verbindungsaufbauzeiten führen unter bestimmten Konstellationen (hohe Dichte der Fahrwegelemente und gleichzeitig hohe Zugge-schwindigkeit) zu Performance-Problemen. Die Verwendung der Kommunikationsplattform löst diese Performance-Probleme durch folgende Konfigurationen: Dezentrale Gruppensteuerung Die Zusammenfassung von Streckenelementen zu Gruppen, die über eine Kommunikations-einrichtung angesprochen werden ist dann sinnvoll, wenn die Gruppenelemente räumlich benach-bart sind und ein geringer Verkabelungsaufwand anfällt. Der Verbindungsaufbau auf Netzebene ist nur einmal notwendig, um mit allen Fahrwegelementen der Gruppe zu kommunizieren. Zentrale Gruppensteuerung Multiplexing von Verbindungen und Weitervermittlung via Kommunikationsplattform in der FFB-Zentrale. Bei dieser Lösung werden in Fahrwegbereichen mit hoher Fahrwegelementdichte die Verbindungen vom Fahrzeug zu den Fahrwegelementen über den Umweg der Kommunikations-plattform in der FFB-Zentrale vermittelt (Gatewayfunktion). Die folgende Abbildung veranschaulicht den Mechanismus an einem Beispiel der zentralen Gruppensteuerung mit zwei Weichen und einem BÜ:

45

Fahrwegrechner GW

Element3ETCS-ID 3

Element2ETCS-ID 2

Element1ETCS -ID 1

Multiplexing

Zentrale

GWW2

GWW1

GWBÜ

Abbildung 13: Multiplexen von Verbindungen in die Zentrale und Weitervermittlung zu den Fahrwegelementen

Nachdem die erste Verbindungsanforderung vom Fahrzeug (adressiert über die entsprechende ETCS-ID) zu einem dieser drei Fahrwegelemente an die Kommunikationsplattform (GW-Gateway) der Zentrale übergeben wurde, baut die Kommunikationsplattform der Zentrale eine Verbindung zum eigentlichen Ziel der Verbindungsanforderung auf. Der Nutzdatenverkehr zwischen Fahrzeug und Fahrwegelement wird dementsprechend über die Kommunikationsplattform der Zentrale geführt. Jede weitere Verbindungsanforderung (logische Verbindung) vom Fahrzeug an ein anderes Fahrwegelement wird über dieselbe physikalische Verbindung vom Fahrzeug in die Zentrale „gemultiplext“ und von dort weiter an das gewünschte Fahrwegelement vermittelt (was den Aufbau weiterer Verbindungen von der Kommunikationsplattform der Zentrale zu den entsprechenden Fahrwegelementen zur Folge hat). Sichere Verbindungen bestehen dabei nur Ende-zu-Ende zwischen dem Fahrzeug und den Fahrwegelementen. Für die FFB-Anwendung ist das Multiplexen via Zentrale transparent; d.h. es ist nicht sichtbar, über welchen Weg die Verbindung vermittelt wird. Die Applikationstelegramme unterscheiden sich nicht von Telegrammen, die direkt (ohne den Umweg über die Zentrale) an ein Fahrwegelement vermittelt werden. Der entscheidende Vorteil dieser Lösung besteht darin, dass ein einziges Mobile auf dem Fahrzeug ausreicht, um gleichzeitig mit mehreren Fahrwegelementen kommunizieren zu können.

4.2 Kommunikationsbeziehungen

Die Kommunikationsbeziehungen des FFB-Systems lassen sich effektiv mit Kommunikations-gateways realisieren, mit deren Hilfe aus mehreren Fahrwegelementen Kommunikationsgruppen gebildet werden. Fahrwegelemente können einzeln oder in Gruppen angesteuert werden (Gruppensteuerung). Die Gruppensteuerung wird wahlweise zentral (bei größerer Entfernung der Gruppenelemente) oder dezentral (bei eng benachbarten Gruppenelementen) organisiert.

46

4.2.1 Einzelelemente

Im Fall einzelner Fahrwegelemente (keine Gruppe) erfolgt die Kommunikation zwischen Fahrzeug und Fahrwegelement direkt. Es erfolgen Rufe im FFB-Regelbetrieb ausschließlich zu den Fahrweg-elementen, aber nicht umgekehrt. Nur im Störungsfall erfolgen Rufe von den Fahrwegelementen zu einer zugehörigen FFB-Streckenzentrale. Es werden folgende Konfigurationen von Einzelelementen gefordert:

• Fahrzeuggerät mit wahlweise einem oder zwei Mobiles, 2x RS422 (ISO/IEC 2110) • Fahrwegelemente mit einem Mobile, • FFB-Zentrale über S2M an ISDN

In den Bildern ist die signaltechnisch nichtsichere Kommunikationsplattform bzw. dessen Kompo-nenten grau hinterlegt.

FFB-Zentrale

Kommunikations-plattform

S2M

Mobile

ISDN


Mobile

MSC

Fahrzeug

Fahrwegelement

Mobile

Fahrwegelement

Mobile

Fahrwegelement

Mobile

Fahrwegelement

GSM-R

GSM-R

GSM-RGSM-RGSM-RGSM-R





Abbildung 14: Einzelne Fahrwegelemente

4.2.2 Zentrale Gruppensteuerung

Bei der Konfiguration einzelner Fahrwegelemente zu kommunikationsbezogenen Gruppen erfolgt die Kommunikation zwischen Fahrzeug und Fahrwegelementen generell über ein oder mehrere Gateways (Kommunikationsplattformen). Bei der zentralen Gruppensteuerung gibt es ein einziges Gateway in der FFB-Zentrale. Rufe von Zügen an Fahrwegelemente der zentralen Gruppensteuerung werden über die FFB-Zentrale geleitet. Damit wird erreicht, dass ein Zug nacheinander mit mehreren Fahrwegelementen kommunizieren kann, ohne jedes Mal eine neue zeitaufwendige GSM/R Verbindung einzurichten. Die zeitkritischen Stellvorgänge dicht benachbarter Fahrwegelemente werden dadurch entkoppelt. Für die FFB-Anwendung bleibt der Kommunikationsweg transparent. Es werden folgende Konfigurationen gebildet:

• Fahrzeuggerät mit wahlweise einem oder zwei Mobiles

47

• Fahrwegelemente mit einem Mobile • FFB-Zentrale über S2M an ISDN, Gatewayfunktion ist in die Zentrale integriert

FFB-Zentrale

Kommunikationsplattform

S2M

Mobile

ISDN


MobileGateway

MSC

kommunikationsbezogene Gruppe

Fahrzeug

Fahrwegelement

Mobile

Fahrwegelement

Mobile

Fahrwegelement

Mobile

Fahrwegelement

GSM-R

GSM-RGSM-R

GSM-R

GSM-RGSM-R





Abbildung 15: Zentrale Gruppensteuerung

4.2.3 Dezentrale Gruppensteuerung

Bei der dezentralen Gruppensteuerung erfolgt die Kommunikation zwischen Fahrzeug und Fahrwegelementen über ein Gruppen-Gateway. Es erfolgen Rufe im FFB-Regelbetrieb ausschließlich zu den Fahrwegelementen (FwE) aber nicht umgekehrt. Nur im Störungsfall erfolgen Rufe von den FwE zu einer zugehörigen FFB-Zentrale. Die Fahrwegelemente der dezentralen Gruppensteuerung sind untereinander verbunden, z.B. mit LAN. Ein Fahrwegelement in der dezentralen Gruppe besitzt eine zusätzliche Gatewayfunktion und vermittelt die eintreffenden Rufe an die anderen Gruppenmitglieder. Neben der Einsparung von Verbindungsaufbauzeiten für zeitkritisch dicht liegende Fahrwegelemente liegt der Vorteil dieser Gruppensteuerung auch in der Einsparung von GSM/R Mobiles. Für die Anwendung bleibt der Kommunikationsweg transparent. Es werden folgende Konfigurationen gebildet:

• Fahrzeuggerät und wahlweise ein oder zwei Mobiles • Fahrwegelemente über LAN vernetzt • FFB-Zentrale über S2M an ISDN • Fahrwegelement mit zusätzlicher Gateway-Funktionalität in der

Kommunikationsplattform LAN vernetzt und mit Mobilezugang

48

FFB-Zentrale


S2M

Mobile

ISDN


Mobile

LAN LAN

Gruppe

Gateway

MSC

Fahrzeug

FahrwegelementFahrwegelement

LAN

Fahrwegelement

GSM-R

GSM-R

GSM-R




Abbildung 16: Dezentrale Gruppensteuerung mit LAN und Zugang über Mobile und Gateway

4.3 Basisentscheidungen

Die signaltechnisch nichtsichere Kommunikationsplattform verwendet in allen Realisierungs-varianten für den Funk Fahr Betrieb die gleichen Software- und Betriebssystemkomponenten. Als Hardwareplattform werden für die Strecken- und Fahrzeugseite unterschiedliche Industrie-PC Systeme verwendet, die die jeweiligen Rahmenbedingungen der Betriebszulassung erfüllen. Als Betriebssystem wird Unixware SVR 4.2 eingesetzt. Durch die starke Entkopplung der Kommunika-tionsplattform vom unterlagerten Betriebssystem sind prinzipiell auch andere Hardwarealternativen möglich. In der mobilen Kommunikationsplattform gibt es aufgrund der mechanischen Umwelteigenschaften keinen beschreibbaren Massenspeicher. System und Daten müssen zur Laufzeit im Hauptspeicher gehalten werden. Die Kommunikationsplattform besitzt eine Gatewaystruktur, deren Kern eine frei projektierbare Vermittlungseinrichtung darstellt, d.h. die Vermittlung erfolgt zwischen beliebig ladbaren Proto-kollstacks (deren Protokollschichten als ablauffähiger Code in der Kommunikationsplattform vorhanden sind), die in Abhängigkeit der angeschlossenen Kommunikationsmedien und der Applikationsforderungen benutzt werden. Durch die verwendete Gatewaystruktur ist die Ankopplung an eine heterogene Infrastruktur mit unterschiedlichen Diensteschnittstellen möglich. Somit sind die in UNISIG spezifizierten Sicherungsverfahren über die Standardanwendung GSM/R hinaus für andere Varianten des „grauen Kanals“ verwendbar. Eine Adaption vorhandener Kommunikationsstrukturen (z.B. Nachbarzen-tralenkopplung über [MAP3.0/ CIRNET]) ist prinzipiell möglich. Die Software des Kommunikationssystems wird funktional und schalenförmig gekapselt. Für Standardfunktionen werden Basisbibliotheken entwickelt, die einheitliche Zugriffsmechanismen,

49

Schnittstellen und Wiederverwendbarkeit sicherstellen. Dem SW-Entwickler können so konfigurierbare Standardbetriebsmittel auf hohem Abstraktionsniveau angeboten werden. Gleichzeitig wird die Abhängigkeit der Software vom unterlagerten Betriebssystem minimiert. Für die effiziente und performante Verarbeitung von Datenströmen wird der STREAMS-Mechanismus eingesetzt. Er bietet eine einheitliche und bewährte Ablaufumgebung im UNIX-Kernel und eine optimale Ankopplung an externe Schnittstellen (siehe [6] Kap. 17). Zusätzlich zum STREAMS-Mechanismus im UNIX-Kernel wird eine eigene Kommunikations-ablaufumgebung (STREAMS-Mechanismus im USER-SPACE siehe 5.3.3) genutzt. Mit dieser Erweiterung wird es möglich, Verarbeitungsketten aus einzelnen Funktionsmodulen im User-Bereich zu definieren und damit die Vorteile des STREAMS-Konzeptes auch für den User-Bereich zu erschließen.

4.4 Das Schalenmodell der Betriebsmittel

Um eine hohe Portabilität und Skalierbarkeit der Kommunikationsplattform zu ermöglichen, wird die Abhängigkeit von benötigten Betriebsmitteln durch eine schalenförmige Kapselung (Kommunikationsablaufumgebung) minimiert. Diese Ablaufumgebung entkoppelt die Kommunika-tionsfunktionalitäten (Kommunikationsprotokolle und Vermittlung von Kommunikationsverbindun-gen) von den Eigenschaften des verwendeten Betriebssystems und der Hardware.

Kommunikationsapplikation

U_STREAM

UTILS

HW

OS

BASE

US_S

PACE

User-Space

Kernel-Space

POSIX (Schnittstelle OS-Utils)

PC (Schnittstelle HW-OS)

KS_MODUL

Schnittstelle Ablaufumgebung Kommunikat

Abbildung 17: Schalenmodell der Betriebsmittel der Kommunikationsablaufumgebung

Die Softwarebasis bildet das Betriebssystem, das direkt auf der Hardware (z.B. PC-Architektur - TCP/IP over LAN, V24) aufsetzt und dem Anwender eine POSIX-Schnittstelle ([POSIX];[8] S.25, S.726) zur Verfügung stellt. Unterhalb der POSIX-API befindet sich der OS-KERNEL-Bereich, in welchem sich die (STREAMS)-Device-Treiber für die Hardware befinden. Oberhalb der POSIX-Schnittstelle beginnt der USER-Bereich, in welchem andere Programmierparadigmen als im OS-KERNEL-Bereich gelten.

50

Die Kommunikationsplattform ist sowohl im OS-KERNEL-Bereich, als auch im USER-Bereich

51

aus einzelnen STREAMS-Modulen. Die verwendeten USER-STREAM-Module (Protokollschich-ten) werden in der US-SPACE-Bibliothek bereitgestellt. Sie bestehen aus verschiedenen

angeordnet. Die Kommunikationsapplikationen befinden sich in der äußeren Schale und sind dadurch am stärksten von den Schnittstelleneigenschaften der darunter liegenden Schalen entkoppelt. Betriebsmittel einer bestimmten Schale nutzen nur Betriebsmittel dieser und darunter liegender Schalen. Die Betriebsmittel der Kommunikationsplattform sind entsprechend ihren funktionalen Wechselwirkungen untereinander und dem Betriebssystem gegenüber in Schalen angeordnet. Im OS-KERNEL-Bereich der Kommunikationsplattform befindet sich die SW-Bibliothek KS_MODUL (siehe 5.2.1). Diese Funktionalität ist im Schalenmodell der Betriebsmittel der Kommunikationsplattform unterhalb der POSIX-API angeordnet und daher stark abhängig vom verwendeten Betriebssystem. Falls ein SVR4 UNIX kompatibles Betriebssystem (siehe [6] Kap. 1.1.10.) verwendet wird, ermöglicht diese SW-Bibliothek über die OS-KERNEL-Schnittstelle DDI/DKI (siehe [6] Kap. 16.7 und [14] Kap. 5.11) das Einbringen von Device-Treibern in den OS-KERNEL-Bereich. Die UTILS-Bibliotheken befinden sich im Schalenmodell in der untersten Schicht des USER-Bereichs. Sie stellen eine Reihe von häufig benötigten Grundfunktionen, wie

• Verwaltung von Listen und Datenpuffern, • Verwaltung von Standardschnittstellen (SOCKET, TLI, TTY) inklusive

nichtblockierendes Lesen (MULTIPLE WAIT), • Ereignis- und Zustandsverwaltung, • Trace und DEBUG Unterstützung, • rechner- und plattformübergreifende asynchrone Interprozesskommunikation und • Zeitbasen

für Kommunikationsapplikationen bereit. Mit der Einführung von UTILS wird die Betriebssystemabhängigkeit der Kommunikationsplattform auf die Bereitstellung einer POSIX-Schnittstelle (siehe [6] Kap. 1.1.8.) reduziert. Durch die UTILS-Bibliothek wird die Portierbarkeit der Kommunikationsplattform auf neue Betriebssysteme stark erleichtert, indem der Portierungsaufwand größtenteils auf die Anpassung dieser Bibliothek beschränkt ist. Die BASE-Bibliothek hat eine Sonderstellung im Schalenmodell der Kommunikationsplattform, da sie sowohl auf Systemfunktionen des UNIX SVR4 OS-KERNEL (DDI/DKI siehe [14] Kap. 5.11.), als auch auf UTILS-Funktionen zugreift. Zweck dieser Bibliothek ist es, eine einheitliche Nutzerschnittstelle auf Basis minimaler Betriebsmittel, wie Listenverwaltung, Zustandsverwaltung, Speicherverwaltung und TRACE/DEBUG Unterstützung bereitzustellen. Software, die auf der BASE-Bibliothek aufsetzt, kann sowohl im OS-KERNEL-Bereich, als auch im USER-Bereich ohne Änderungen ablaufen. D.h., BASE bietet die volle Portabilität des Codes zwischen OS-KERNEL- und USER-Space. Für den auf BASE aufsetzenden Code ist es somit unerheblich, ob er im OS-KERNEL-Bereich oder im USER-Bereich läuft. Die Überlappung der Flächen von KS-Modul und BASE-Bibliothek bedeutet, dass ein Teil der Funktionen des KS-Moduls auf der Nutzerschnittstelle von BASE aufsetzt. Auf die Funktionen von UTILS greift die Betriebssystemerweiterung U_STREAM (siehe 5.3.3) zu, die als weitere SW-Schale der Kommunikationsplattform fungiert. U_STREAM bietet eine betriebssystemunabhängige STREAMS-Ablaufumgebung im USER-Bereich, analog zu STREAMS im OS-KERNEL-Bereich. Die Ablaufumgebung erlaubt die Konfiguration von STREAMS-Ketten

Konvertern, Multiplexern und Ports, die per Konfiguration miteinander verkettet werden und damit den USER-STREAM bilden. Die STREAMS-Module von US_SPACE erfordern die Bereitstellung der Ablaufumgebung U_STREAM. Die Basisbibliotheken UTILS und U_STREAM kapseln die betriebssystemabhängigen System-funktionen von den Kommunikationsplattform-Komponenten. Bei einer Portierung der Kommunikationsplattform auf andere Systeme müssen nur diese Basisbibliotheken sowie die im OS-KERNEL ablaufenden Protokolle portiert werden. Die äußere Schale der Softwarearchitektur wird durch die Kommunikationsapplikation(en) gebildet. Die Applikationen greifen auf die Dienste der USER-STREAM-Ketten (Protokollstacks) zurück. Die USER-STREAM-Ketten stellen für die Applikationen Treiber für die externe Kommunikation (z.B. zum GSM-Mobile) dar, während die Vermittlung zwischen den Nutzdatenkanälen und die Ermittlung und Konvertierung von Rufvektoren in den Applikationen stattfindet (Gatewaytechnologie). Die Applikationen triggern HW-Watchdogs (Ausbleiben des Triggerns mindestens einer Applikation führt zum HW-Reset und damit zum Booten des Systems), die die ordnungsgemäße Funktionalität des Systems überwachen.

4.5 Das Schichtenmodell der Kommunikationsstacks

Die in der Kommunikationsplattform ablaufenden Kommunikationsprotokolle sind entsprechend dem OSI-Schichten-Modell in einzelnen Layern (mit über Diensteschnittstellen definierten Wech-selwirkungen) umgesetzt. Die im USER-Bereich der Kommunikationsplattform ablaufenden Kommunikationsstacks unterliegen der in der folgenden Abbildung dargestellten logischen Struktur.

S c h ic h te n m o d e l l d e r K o m m u n ik a t io n s s ta c k s in d e r K o m m u n ik a t io n s p la tt f o rm

O S -K e rn e l

In p u t/O u tp u t ( fd )

M u lt ip le W a it C a llb a c k ( p o l l /s e le c t )B a s is S c h e d u le

In p u t ( re a d )

In te rp ro ze ss -K o m m u n ik a tio n

C a llb a ck(r c v )

O u tp u t (w r ite )

c ls v r -L ib

P o o l

M u x - P o o l

P o r t -P o o l

K o n v- P o o l

K o m m u n ika t io n s a p p l ik a tio n (V e rm it tlu n gs lo g ik )

S ta c ks

u s _c h a n n e lK o nfig u ra tio nO u tp u t

(s e n d )

U S E n g in e

Q u e u eV e r w a lt u n g

S e r v i ce -S ch e d u le

U se r S tre a m

K o m m u n ika tio n s ta sk(U S E R _ S P A C E )

in te rnF lo w - C n t l

u s- H e a d u s - H e a d u s- H e a d

u s- K o n v

u s- K o n v

u s - K o n v u s- K o n v

u s - M u ltip le x e r

Z e it b a s i s

C a llb a ck(t im e h a n d le r)

u s- K o n v

u s- K o n v

u s - K o n v

u s - K o n v

u s- P o r t u s - P o r t

K o n fig u r a tio n s d a te ie n

T r a c e d a te ie n

F ile sy s t e m

T im e jo b s

D e la y tre ib e r

T T Y T L I /S o ck e t

H a r d w a re tre ib e r

T C P / IP IS D N

C A P I

R S 2 3 2R S 4 2 2T im e r

Abbildung 18: Struktur Kommunikationsstacks der Kommunikationsablaufumgebung

52

Die im OS-KERNEL-Bereich dargestellten Strukturelemente werden von der Kommunikations-task ausschließlich über Filediskriptoren (Input/Output(fd)) angesprochen. In der Multiple Wait Callback Struktur sind für alle relevanten Filedeskriptoren Callback-Handler registriert. Steht an einem Filedeskriptor ein Ereignis zum Bearbeiten in der Kommunikationstask bereit, wird der entsprechend registrierte Callback-Handler aufgerufen. Der Callback-Handler als Funktion eines höheren Strukturelementes (z.B. us-Port, Zeitbasis oder Interprozesskommunikation) führt alle notwendigen Aktivitäten zur Bearbeitung des Filedeskriptorereignisses inklusive etwaiger (non-blocked) Read/Write-Operationen aus. Nach Abarbeitung aller an den Filedeskriptoren anstehenden Ereignissen wird der Basis Schedule aktiviert. Dieses Strukturelement aktiviert nacheinander alle registrierten sekundären rechenwilligen Scheduler. Beispielsweise ist die Verwaltung der Messagequeues der USER-STREAM Engine (siehe 5.3.3) als sekundärer Scheduler realisiert. Diese Verwaltung aktiviert nacheinander alle rechenwilligen USER-STREAM Messagequeue Service-routinen. Die Rechenwilligkeit von Serviceroutinen hängt von der Anwesenheit von Nachrichten und dem Flusskontrollzustand der jeweiligen Messagequeue ab. Danach geht die Kommunikations-task wieder in den Wartezustand bis zum Eintreffen neuer Filedeskriptor-Ereignisse. Ein laufender Callback-Handler kann nicht durch einen anderen Callback-Handler unterbrochen werden, d.h. zu einem Zeitpunkt läuft maximal ein Callback-Handler (siehe 5.2.2). Die Interprozesskommunikation (siehe 4.6.2) steht der Kommunikationsapplikation (Vermittlungslogik) und den Modulen des USER_STREAM zur Verfügung. Die Anbindung an die OS-KERNEL-abhängigen Betriebsmittel (TTY und TLI) erfolgt über die clsvr-Bibliothek. Die Zeitbasis (siehe 5.2.3) benötigt im OS-KERNEL einen Delaytreiber. Die Kommunikation zwischen Zeitbasis im USER-Space und Delaytreiber im OS-KERNEL-Space erfolgt über einen in der Multiple Wait Callback Struktur registrierten Filedeskriptor. Die Kommunikationsstacks des USER-Bereiches laufen in der USER-STREAM Umgebung (siehe 5.3.3) ab. Der Ablaufcode der Protokollayer ist in Pool-Strukturen organisiert. Entsprechend den Schnittstellenanforderungen der einzelnen Protokollayer werden Konverter (Konv-Pool) oder Multiplexer (Mux-Pool) verwendet. Kommunikationsschnittstellen zwischen dem USER_STREAM-Modell und dem Input/Output Bereich werden über Ports (Port-Pool) realisiert. Ein Port adaptiert den Message-orientierten Nachrichtenverkehr des User-Stream an den jeweiligen (proprietären) Datenverkehr der zu unterstützenden Fildeskriptor-basierten Schnittstelle. Über die us_channel Konfiguration (siehe 5.3.3.1) sind auf Basis der in den Pool-Strukturen hinterlegten Protokollfunktionalitäten Protokollstack-Profile hinterlegt. Die Kommunikations-applikationen können auf Basis dieser Protokollstack-Profile die benötigten Kommunikationsstacks instanziieren. Die USER-STREAM-Engine sorgt für den korrekten Ablauf der instanziirten Kommunikationsstacks entsprechend den Streams-Konventionen. Die folgende Abbildung zeigt den strukturellen Aufbau des Euroradio-Protokollstacks für ein FFB-Fahrzeuggerät als Beispiel (konfigurierte Instanz) für einen nach dem Schichtenmodell der Kommunikationsplattform (siehe Abbildung 18) umgesetzten Protokollstack.

53

Kommunikationstask

ER Protokolle

TR_T.70

TR _aH D LC

T R _ M D M X

Mobile Kopplung

T R _ M D C V

L K _ P O R T

c o m 1 c o m 2 c o m n + 1

TR-IF(MOD)

TRTR _M UX

Responder

TR-IF

Invoker

Gateway-Vermittlungslogik

TR _ CA LL_ TO TR _ CA LL_ TO

TR_T.70 TR_T.70

TR_aH D LC TR _aHD LC TR-IF

T R _ M D C V

L K _ P O R T

T R _ M D C V

L K _ P O R T

LK-IF

ASY-Treiber

OS-Kernel

M o b i le M o b i le M o b i le

Abbildung 19: EURORADIO-Protokollstack FFB-Fahrzeuggerät

Der EURORADIO-Protokollstack für ein FFB-Fahrzeuggerät stellt eine Kombination von Protokollschichten dar. Entsprechend dem Schichtenmodell der Kommunikationsstacks der Kommunikationsplattform (siehe Abbildung 18) laufen die in der Kommunikationstask realisierten Protokollschichten (ER-Protokolle, Mobile-Kopplung) und die Gateway-Vermittlungslogik (Kommunikationsapplikation) im USER-SPACE ab. Die Funktionalitäten der einzelnen Protokollschichten sind als ablauffähiger Programmcode in den Poolstrukturen der Kommunikationsplattform enthalten. Die Ausprägung der Protokollparameter der einzelnen Protokollschichten (z.B. Windowsize des asynchronen HDLC-Protokolls der Linkebene) sowie die Oberhalb/Unterhalb-Relationen der Protokollschichten im Stack sind in hierarchisch organisierten

Kommunikationsrechner Fahrzeug- Funkstack (V.25ter-Interface) -

54

us_channel-Konfigurationsfiles definiert. Der verwendete Protokollstack unterteilt sich in drei

55

Bereiche: Ankopplung des GSM/R Endgerätes: Das GSM/R Endgerät ist über eine serielle Schnittstelle an den Kommunikationsrechner angeschlossen. Die serielle Schnittstelle wird vom ASY-Treiber (com1 – com n) angesteuert. Der ASY-Treiber ist als STREAMS-Treiber realisiert und Bestandteil des Betriebssystems. Die Ablaufsteuerung des TR_MDMX organisiert die Aktivierung des Stacks zur Ansteuerung des GSM/R-Endgerätes über die serielle Schnittstelle. Das TR_MDCV-Modul, das während der Aktivierung des Stacks geladen wird, adaptiert die V25.ter Schnittstelle. Der aktivierte Stack wird unterhalb des TR_MDMX-Multiplexers gelinkt. Damit wird die Kommunikationsressource an den TR_MDMX-Multiplexer übergeben. Der TR_MDMX-Multiplexer stellt die Kommunikationsressourcen über das Interface TR_IF den darüber liegenden Protokollen zur Verfügung. In der Kanalabbauphase eines GSM/R Endgerätes wird der Stack, der das GSM/R Endgerät ansteuert, deaktiviert. EURORADIO Protokollkörper: Für den Ablauf des Transportprotokolls stellt der TRTR_MUX über ein internes Interface eine Ablaufumgebung zur Verfügung. Entsprechend der Konfiguration des TRTR_MUX wird die gewünschte Transportprotokollvariante (Euroradio TP2) geladen. Der Zugriff auf die Netzebene und die Stackkonfiguration wird ebenfalls über die TRTR_MUX-Konfiguration ausgewählt. Die Verwaltung der Netzbeziehungen wird durch den TRTR_MUX organisiert. Wird ein Transportkanal angefordert, etabliert der TRTR_MUX den benötigten Netzlink oder verwendet einen bereits bestehenden. Die TR-Interface konformen Module TR_aHDLC und TR_T70 repräsentieren die Link- und Netzschicht des EURORADIO-Stacks. Ankopplung an die Gateway-Vermittlungslogik (Vermittlungskern): Der Vermittlungskern (siehe 5.4.3) ist über einen TR-Interface konformen USER-STREAM-STACK mit dem TRTR_MUX verbunden. Das TR_CALL_TO-Modul erweitert einlaufende Ver-bindungsanforderungen mit zusätzlichen fest projektierten Vermittlungsinformationen für die Gateway-Vermittlungslogik (Festlegung des Protokollstacks für die Weitervermittlung).

4.6 Varianten interner Kommunikationsbeziehungen

4.6.1 Verbindungsorientierte Kommunikation

Die Vermittlungslogik der Kommunikationsapplikation für EURORADIO-Protokoll und Koppel-protokoll ist verbindungsorientiert. Das Verhalten der Diensteschnittstelle der Transportebene entspricht grundsätzlich [X.214]. Dementsprechend wird bei der Signalisierung in kommende und gehende Rufe unterschieden:

• Listener – Signalisierung einlaufender Rufe, • Responder – Annahme eingelaufener Rufe, • Invoker – Versenden abgehender Rufe, • Lokale Aktivitäten – Steuerprimitiven zur Selektion des Betriebsverhaltens.

Die lokalen Aktivitäten bestehen in der Aktivierung des Diensteproviders zur Festlegung seines Betriebsverhaltens (Listener, Responder oder Invoker) entsprechend übergebener Parameter (z.B. ETCS-Service).

4.6.2 Interprozesskommunikation

Die Interprozesskommunikation der Kommunikationsplattform ist auf Basis der Client-Server Technologie realisiert (siehe [7] Kap. 8.2.4, [8]). Durch die Netzdarstellung (Big Endian) von Parametern ist sie plattformübergreifend ausgelegt. Interne Datenkorrekturverfahren stellen minimale Forderungen an die Basiskommunikationsmittel (TLI/TCP oder TTY). Das Nutzer-interface (API) stellt eine asynchrone Kommunikation zur Verfügung. Für jeden Kommunikations-endpunkt sind zum ereignisorientierten Empfang „callback“ Empfangshandler vorzusehen. Es wird ein prozess- und plattformübergreifendes „Remote Call Verfahren“ bereitgestellt.

4.6.3 Verbindungslose Kommunikation

Die verbindungslose Kommunikation wird in der signaltechnisch nichtsicheren Kommunikations-plattform zum Austausch von Abbildungen des Vermittlungszustandes (d.h. Anzahl der gerade vermittelten Nutzdatenkanäle, sowie die Adressinformation der beiden Kommunikationspartner von bereits vermittelten Nutzdatenkanälen) zwischen redundanten Vermittlungskernen (siehe 5.4.3) verwendet (zyklisch und bei Änderung des Status der Nutzkanalverbindungen). Die verbindungs-lose Kommunikation (Broadcast) hat den Vorteil, alle Gatewayinstanzen (Gatewayinstanz: Ver-mittlungskern inklusive instanziierter Protokollstacks) eines Vermittlungsclusters gleichzeitig zu erreichen und die Gatewayinstanzen eines Vermittlungsclusters (siehe 4.7.1) nicht zu blockieren, falls eine Gatewayinstanz ausfällt.

4.7 Die Grundstruktur der Kommunikationstask

Die grundsätzliche Funktion einer Kommunikationstask, entsprechend der Kommunikations-ablaufumgebung (siehe Abbildung 18), besteht in der Vermittlung von verbindungsorientierten Datenkanälen, welche als kommende oder gehende Verbindungen auf unterschiedlichen, instanziierbaren Protokollstacks abgebildet sind. Einfacher Anwendungsfall – Vorrechner Ein einfacher Anwendungsfall der Kommunikationsplattform besteht in der Verwendung als signaltechnisch nichtsicherer Vorrechner (Kommunikationsgateway) eines signaltechnisch sicheren Applikationsrechners (z.B. FFB-Fahrzeuggerät). Die folgende Abbildung zeigt die gemäß Schichtenmodell (siehe Abbildung 18) in der Kommunikationstask ablaufenden Komponenten für die Vermittlung von Datenkanälen. Aufgabe der Kommunikationsplattform ist neben der Vermittlung von Datenkanälen und der EURORADIO-konformen Datenübertragung, die Ankopplung an den signaltechnisch sicheren Rechner und die Adaption an dessen eingeschränkte Kommunikationsmöglichkeiten.

56

User Stream

Kommunikationstask

EURORADIO-Protokollstack

Kopplungs-Protokollstack

Kommunikationsapplikation(Gateway-Vermittlungslogik)

Kommunikationsrechner

Kopplung zum signaltechnischsicheren Applikationsrechner

zum externenKommunikationsmedium

Abbildung 20: Kommunikationsplattform als signaltechnisch nichtsicherer Vorrechner

Komplexer Anwendungsfall – Vermittlungscluster Ein komplexer Anwendungsfall der Kommunikationsplattform besteht in der Verwendung von redundant gekoppelten Clusteranordnungen (siehe 4.7.1) mehrerer Kommunikationsgateways. Derartige Vermittlungscluster können als hoch verfügbare Netzübergänge genutzt werden, falls (z.B. in der FFB-Zentrale) neben dem GSM/R-Netz ein weiteres Kommunikationsmedium als Rückfallebene (z.B. öffentliches ISDN/GSM-Netz) zur Verfügung steht. Die folgende Abbildung zeigt die grundsätzliche Verschaltung zweier Kommunikationsplattformen zu einem redundanten Vermittlungscluster:

57

User Stream

Kommunikationstask




clusterinterne Kopplung



User Stream

User Stream

Kommunikationstask





User Stream


Abbildung 21: Kommunikationsplattform in prinzipieller Ausprägung als Vermittlungscluster

58

Zur clusterinternen Kommunikation zwischen den Kommunikationsgateways wird der redundante

59

Koppelprotokollstack (siehe 3.3.2) verwendet. Durch die Verwendung des Koppelprotokolls ist die clusterinterne Kommunikation tolerant gegenüber Ausfällen der intern verwendeten Kommunikationsmedien. Die clusterinterne Kommunikation ist für die externen Kommunikations-partner transparent. Die Vermittlung von kommenden und gehenden Nutzdatenkanälen abgebildet auf netzproviderabhängige Protokollstacks (z.B. EURORADIO) zur Kommunikation nach außen wird über diejenige Clusterkomponente realisiert, welche den Zugang zum entsprechenden externen Netz unterhält. Durch die Entkopplung der externen Kommunikationsmedien zum einen, und der Umsetzung der clusterinternen Kommunikation auf ein einheitliches Koppelprotokoll, lassen sich ausschließlich die gewünschten Nutzdatenkanäle über unterschiedliche Kommunikationsmedien und Provider-strukturen abbilden.

4.7.1 Vermittlungscluster

Um das Gesamtsystem tolerant gegenüber Ausfällen in der signaltechnisch nichtsicheren Kommunikationsplattform selbst, sowie Ausfällen der angeschlossenen Kommunikationsmedien (Netzwerk) zu gestalten, werden die Kommunikationsgateways in mehrere Ebenen von Vermittlungsclustern zusammengeschaltet. Ein Vermittlungscluster stellt einen logischen redundanten Anschluss an ein Netzwerk oder ein logischen Netzwerkverbund dar und enthält beliebig viele (redundante) Kommunikationsgateways und Netzzugänge (z.B. ISDN-Basiskanäle). Es ist in der Lage, Verbindungen zu einer Zielinstanz aufzubauen und zu verwalten. In Abhängigkeit von der Ausprägung eines Vermittlungsclusters und den verfügbaren Netzanschlüssen kann ein Vermittlungscluster alternative Verbindungen zu einer Zielinstanz aufbauen. Mit Hilfe einer durch Kopplung bewirkten speziellen Informations-übertragung können ausgefallene Komponenten eines Vermittlungsclusters erkannt und von der Vermittlung von Verbindungen suspendiert werden. Ein Vermittlungscluster kann auf Anforderung (eines externen Anwenders) Verbindungen zwischen verschiedenen externen Netzschnittstellen innerhalb und (bei Vorhandensein weiterer Vermittlungscluster auch) außerhalb des Vermittlungs-clusters vermitteln. Eine redundante Anordnung enthält mindestens ein Vermittlungscluster. Bei Bedarf können auch weitere Vermittlungscluster eingerichtet und verschaltet werden. In diesem Fall können auch alternative Verbindungen zwischen mehreren Vermittlungsclustern vermittelt werden. Die Anzahl der dafür benutzten Rechner ist skalierbar und hängt von den Anforderungen an Last und Verfügbarkeit, der Art und Anzahl der externen Netzschnittstellen und den Gegebenheiten der örtlichen Anlage ab. In nachfolgender Abbildung wird beispielhaft die Architektur und logische Kopplung zweier Vermittlungscluster mit jeweils drei Kommunikationsgateways auf der Basis von drei redundanten signaltechnisch nichtsicheren Kommunikationsplattformen dargestellt. Jeder Rechner enthält dabei je ein Gateway (Gateway-Vermittlungslogik) eines Vermittlungsclusters. Diese Anordnung ist funktionsfähig, solange mindestens ein Rechner mit mindestens 2 Netzanschlüssen (1 x kommend, 1 x gehend) in Betrieb ist. Der Ausfall von Netzanschlüssen, Kopplungsmedien und Gateway-rechnern kann toleriert werden. Die Ausfälle führen ggf. zum Kommunikationsabbruch bestehender Verbindungen und zu Einschränkungen im Hochlastbereich. Solange die Funktionsfähigkeit der Anlage besteht und freie Netzanschlüsse vorhanden sind, können jedoch neue Verbindungen eingerichtet werden.

EXTERNER ÜBERTRAGUNGS-PROTOKOLLSTACK 1

Gateway 1-1

Kommunikations-plattform 1

Vermittlungs-cluster 1

Gateway 2-1


KOPPELSTACKCLUSTEREXTERNEKOPPLUNGCLUSTER 2

KOPPELSTACKCLUSTERINTERNEKOPPLUNGCLUSTER 1


Gateway 1-2




Gateway 1-3



Vermittlungs-cluster 2



Gateway 2-1









Gateway 2-1








Gateway 2-2







Gateway 2-3





(CLUSTER 1, PLATTFORM 1) (CLUSTER 1, PLATTFORM 2) (CLUSTER 1, PLATTFORM 3)

(CLUSTER 2, PLATTFORM 1) (CLUSTER 2, PLATTFORM 2) (CLUSTER 2, PLATTFORM 3)

Abbildung 22: Redundante Kopplung zweier Vermittlungscluster mit jeweils drei Kommunikationsgateways

Die Gateways der Vermittlungscluster sind auf verschiedene Art miteinander gekoppelt: Kopplung der Gateways innerhalb eines Vermittlungsclusters Alle Gateways innerhalb eines Vermittlungsclusters sind derart gekoppelt, dass logische Verbin-dungen von einem Gateway des Vermittlungsclusters zu allen anderen Gateways desselben Vermittlungsclusters einschließlich zu sich selbst eingerichtet werden können. Kopplung der Gateways zwischen unterschiedlichen Vermittlungsclustern Jedes Gateway eines Vermittlungsclusters ist mit allen Gateways eines anderen Vermittlungs-clusters derart gekoppelt, dass logische Verbindungen von einem Gateway eines Vermittlungs-clusters zu allen Gateways eines anderen Vermittlungsclusters eingerichtet werden können. Die protokolltechnische Umsetzung der Kopplung erfolgt mittels Koppelstacks. Ein Koppelstack enthält dabei ein oder mehrere Übertragungsprotokolle. Jeder Gatewayrechner besitzt so viele

60

Koppelstacks, wie es Vermittlungscluster im Netzwerk gibt. Der erste Koppelstack dient der

61

Kommunikationsplattform besteht in der Bereitstellung von Linkbündeln zur Abbildung von

Kopplung der Gateways eines Vermittlungsclusters untereinander und der Kopplung eines Gateways zu sich selbst (clusterinterne Kopplung). Der zweite Koppelstack dient der Kopplung eines Gateways eines Vermittlungsclusters mit allen Gateways eines anderen Vermittlungsclusters (clusterexterne Kopplung). Werden mehr als zwei Vermittlungscluster miteinander verschaltet, dient jeder weitere Koppelstack der Kopplung eines Gateways eines Vermittlungsclusters mit den Gateways eines weiteren Vermittlungsclusters (clusterexterne Kopplung). Zwei gekoppelte Koppelstacks verwalten ein gemeinsames Kanalbündel (virtuelle Links), in welchem eine oder mehrere logische Verbindungen in beide Richtungen etabliert werden können. Je nach Anzahl der Kopplungen eines Koppelstacks zu einem oder mehreren Gateways verwaltet ein Koppelstack ein oder mehrere Kanalbündel. Die jeweilige Anzahl der Kanalbündel ergibt sich aus der Konfiguration der Gateways und Vermittlungscluster. Die Anzahl der Kanalbündel für die clusterinterne Kopplung eines Koppelstacks ist bestimmt durch die Anzahl der verwendeten Gateways eines Vermittlungsclusters. Die Anzahl der Kanalbündel eines Koppelstacks für die clusterexterne Kopplung zu einem anderen Vermittlungscluster ist bestimmt durch die Anzahl der verwendeten Gateways in dem angekoppelten Vermittlungscluster. Für die physikalische Verbindung von Kommunikationsgateways in verschiedenen Rechnern können sowohl Punkt-zu-Punkt Übertragungsmedien (z.B. serielle Leitung), als auch Bussysteme (z.B. LAN) verwendet werden. Die Übertragungsmedien zwischen den Rechnern der signaltechnisch nichtsicheren Kommunika-tionsplattformen sollten redundant ausgelegt werden, um gegen Ausfälle des Koppelmediums fehlertolerant zu sein. In Richtung des externen Netzwerkes oder Netzwerkverbundes arbeiten die Gatewayrechner mit dem jeweils notwendigen Übertragungsprotokoll der externen Kommunikationspartner. Für Zugsteuerungszwecke kann das z.B. der EURORADIO-Protokollstack sein. Durch das Gateway erfolgt eine vollständige protokolltechnische Entkopplung von externem Übertragungsprotokoll und dem Koppelprotokoll. Dadurch ist die Gatewayfunktion für den externen Kommunikationspartner transparent. Bei Bedarf können durch die Gateways auch verschiedene externe Übertagungsprotokolle parallel bedient werden. Weiterhin ist durch die Gatewaytechnologie auch eine protokolltechnische Umsetzung zwischen verschiedenen externen Übertragungsprotokollen möglich. Die Auswahl der externen Übertragungsprotokolle kann sowohl von den Anforderungen der angeschlossenen Applikationen, als auch von den verwendeten Übertragungsmedien abhängen. Durch die Benutzung verschiedener externer Protokolle und Netzwerke an einem Vermittlungscluster zur Repräsentanz eines externen logischen Netzwerkverbundes, ist neben fehlertoleranten Netzübergängen mit dem beschriebenen Verfahren ebenfalls die Möglichkeit gegeben, alternative Netzwerke als redundantes Gesamtsystem zur Verfügung zu stellen. Die Anzahl der erreichbaren externen Kommunikationspartner der redundant verschalteten Netzvermittlung ist von der Anzahl und Ausprägung der externen Netzanschlüsse abhängig und prinzipiell nicht begrenzt. Das Maß der Ausfallsicherheit einer derart redundant verschalteten Netzvermittlung hängt von Anzahl und Konfiguration der Netzanschlüsse, Gateways, Vermittlungscluster und Rechner ab und kann auf die Bedürfnisse einer konkreten Anlage zugeschnitten werden.

4.7.2 Koppelprotokoll der Kommunikationsplattform

Die grundsätzliche Funktion des clusterinternen und clusterexternen Koppelprotokolls der

verbindungsorientierten Nutzdatenkanälen, welche als kommende oder gehende Verbindungen zwischen den Kommunikationsgateways etabliert werden. Die Gesamtfunktionalität des Koppelprotokolls ist in Protokollschichten mit speziellen Aufgaben und Eigenschaften unterteilt. In folgender Abbildung ist die logische Struktur der Protokollschichten zur clusterinternen und clusterexternen Kopplung dargestellt:

Kommunikationstask

virtuelle Linkebene

Session

VL-P ro tokoll

Linkebene

L IN K -P ro to k o ll

L K _ P O R T

G atew ay L ink M ultip lexer (G L_M U X)

Responder

TR-IF

Invoker

Gateway - Vermittlungslogik

TR _C ALL_TO TR _C ALL_TO

LK-IF

LK-IF

Providerebene

Session

VL-P rotokoll


L K _ P O R T

Session

VL-P ro tokoll


L K _ P O R T

L IN K - B ü n d e l -Z u g a n g



VL-IF

OS-Kernel

Abbildung 23: Struktur der Protokollschichten zur clusterinternen und clusterexternen Kopplung

Entsprechend dem Schichtenmodell der Kommunikationsstacks der Kommunikationsplattform (siehe Abbildung 18) laufen die in der Kommunikationstask realisierten Protokollschichten (Linkebene, virtuelle Linkebene) und die Gateway-Vermittlungslogik im USER-SPACE ab. Die Providerebene besteht aus den im OS-Kernel-Bereich vorhandenen Treiber- und Protokoll-funktionalitäten (z.B. TCP). Mit der gewählten Aufteilung ist eine weitgehend flexible Anpassung an verschiedene Übertragungsmedien (Providerebene) und Ablaufumgebungen (Die Koppelprotokollschichten der

Kommunikationsrechner- clusterinterne Kopplung -

62

virtuellen Linkebene (VL) und Linkebene (LK) sind als USER-STREAM-Module realisiert) möglich. Durch Anpassungen der Koppelprotokolle der Linkebene sind bereits vorhandene Funktionen (z.B. Framing, Fehlerkorrektur) der Treiberschichten des jeweiligen Betriebssystems (z.B. TCP/IP over LAN) nutzbar. Das TR_CALL_TO-Modul erweitert einlaufende Verbindungsanforderungen mit zusätzlichen fest projektierten Vermittlungsinformationen für die Gateway-Vermittlungslogik (Festlegung des Proto-kollstacks für die Weitervermittlung). Der Gateway-Link-Multiplexer verwaltet die Kommunikationsressourcen mehrerer Linkbündel. Die Session-Protokollschicht dient der Bewertung einlaufender Verbindungsanforderungen hinsichtlich Balance der Vermittlungslast der einzelnen Kommunikationsgateways eines Vermittlungsclusters. Des weiteren ergänzt die Session-Protokollschicht einlaufende Verbindungsanforderungen mit zusätzlichen Vermittlungsinformationen (GSM/R-Telefonnummer und Service) aus dem Local Directory. Das VL-Protokoll (Virtual Link Protokoll) stellt einen verbindungsorientierten bidirektionalen Datendienst für die Verwendung innerhalb der Kopplung bereit. Durch das VL-Protokoll werden mehrere virtuelle Verbindungen (Kanalbündel) zur gleichen Zeit unterstützt. Das VL-Protokoll setzt eine bidirektionale, vollständige und folgerichtige Übertragung von an die unterlagerte Linkebene übergebenen Datagrammen voraus. Das LINK-Protokoll kompensiert die funktionalen Defizite der verwendeten Providerebene hin-sichtlich der Anforderungen der virtuellen Linkebene (z.B. Fehlerkorrektur). Verbindungsstörungen der Providerebene werden durch das LINK-Protokoll erkannt und führen zur zeitweiligen Suspen-dierung des Kanalbündels.

4.7.2.1 Redundanz und Verteilung der Vermittlungslast

Die in der Kopplung (Ankopplung an signaltechnisch sichere Rechner bzw. clusterinterne Kopplung von Kommunikationsgateways) der nichtsicheren Kommunikationsplattform verwendeten Protokollfunktionalitäten zum Redundanz- und Loadbalance-Management greifen nur in den Setupphasen einer Nutzdatenverbindung ein. Beim Ausfall einer Komponente, die die Nutzdatenverbindung führt, bricht die Verbindung zusammen. Der von der Applikation (Nutzer der Nutzdatenverbindung) infolge des Abbruchs der Nutzdatenverbindung neu angeforderte Kanal wird dann über alternative Kommunikationsressourcen (bei sicherer Verbindung mit neu abgeleitetem kryptographischen Sitzungsschlüssel) aufgebaut. Falls diese Eigenschaft vom Dienstenutzer nicht benötigt wird, kann ein für die Applikation verdeckter Wiederaufbau des durch Komponentenausfall verursachten Abbruchs der Nutzdatenverbindung durch eine zusätzliche Ende- zu Ende Protokollschicht erfolgen. Das Redundanzkonzept der signaltechnisch nichtsicheren Kommunikationsplattform ermöglicht die redundante Ankopplung an signaltechnisch sichere Rechner nach dem 2 von 3 oder nach dem 2 x 2 von 2 Prinzip (siehe 3.3.2.3).

4.7.2.2 Setupphase

Während der Verbindungsaufbauphase einer logischen Verbindung wird zu jedem erreichbaren Gateway im angewählten Vermittlungscluster je eine Ressource im jeweiligen Kanalbündel temporär belegt. Nach der Auswahl und Etablierung der logischen Verbindung werden die nicht mehr benötigten, temporär belegten Ressourcen freigegeben und stehen damit dem weiteren Vermittlungsprozess wieder zur Verfügung.

63

Logische Verbindungen werden auf Anforderung externer Instanzen im Kanalbündel eingerichtet und zwischen den Koppelstacks getunnelt (virtuelle Linkebene Koppelprotokoll). Die Anzahl der logischen Verbindungen hängt von der Art und Anzahl der externen Schnittstellen und den Verbindungsanforderungen externer Instanzen ab. Der Koppelstack enthält Funktionen, die eine Selektion eines geeigneten Gateways aus einem Vermittlungscluster ermöglichen. Dazu können spezielle Protokollprimitive eingeführt werden, welche über die logischen Verbindungen eines Koppelstacks an die erreichbaren Gateways über-tragen werden. Die Sequenz von Protokollprimitiven besteht aus drei Phasen:

• Nach Anforderung durch eine rufende Instanz sendet ein rufendes Gateway ein Aufruf-telegramm an alle über einen Koppelstack erreichbaren Gateways. Im Falle der Kopplung der Gateways eines Clusters untereinander erreicht das Aufruftelegramm (CON_REQ-CON_IND) auch das rufende Gateway, wo es in gleicher Weise wie bei den übrigen parallel redundanten Gateways verarbeitet wird.

• Die funktionsfähigen gerufenen Gateways prüfen die Möglichkeit der angeforderten

Verbindung und generieren ein Antworttelegramm (RDY_REQ-RDY_IND) an das rufende Gateway. Das Antworttelegramm kann außerdem einen individuell ermittelten Bewertungsparameter enthalten, anhand dessen eine Optimierung (z.B. Lastverteilung) durchgeführt werden kann. Der Bewertungsparameter wird entsprechend des momentanen Vermittlungszustandes des gerufenen Gateways, sowie des Abbildes des Vermittlungszustandes der Nachbargateways des Vermittlungsclusters (siehe 4.6.3) gebildet. Neben der Anzahl der gerade vermittelten Kanäle wird die Adressinformation des Kommunikationspartners der bereits vermittelten Kanäle berücksichtigt. Dadurch kann eine zu etablierende Nutzkanalverbindung in der 3. Phase auf einen bereits bestehenden Netzkanal des Vermittlungsclusters gemultiplext werden.

• Durch das rufende Gateway erfolgt anhand der übertragenen Informationen in den

Antworttelegrammen die Beurteilung, welche der angeschlossenen Gateways erreichbar sind. Enthalten die Antworttelegramme außerdem einen Bewertungsparameter, so kann durch das rufende Gateway außerdem bewertet werden, welche der möglichen Ver-bindungen am besten für die neue Verbindung geeignet ist. Mit dem Bewertungs-parameter kann z.B. eine Lastoptimierung zwischen den Gatewayrechnern erfolgen. Über die ausgewählte Verbindung wird daraufhin der Link zum Anwender eingerichtet, indem die Verbindung vom rufenden Gateway zum ausgewählten Gateway selektiert wird (RDY_RSP-RDY_CNF) und nach externer Rufbestätigung (CON_RSP-CON_CNF) für die Nutzdatenübertragung zur Verfügung steht. Alle anderen Ver-bindungsoptionen werden freigegeben.

Das Primitivenspiel zur Selektion eines Gateways ist beispielhaft für eine Konfiguration mit vier alternativer Linkbeziehungen in nachfolgender Abbildung dargestellt.

64

externer Ruf

Koppelstack (rufend)

externeRufbestätigung

AnforderungAlternative 1

AnzeigeBewertung 1

FreigabeAlternative 1

FreigabeanzeigeAlternative 1

UP DN

abgehende RufeUPDN

ankommender Rufe

Übertragung Anforderung an Gateway 1 Anforderungsanzeige

Alternative 1

BewertungAlternative 1

Übertragung Bewertung von Gateway 1

Übertragung Freigabean Gateway 1


externeRufanzeige

Übertragung Freigabequittungvon Gateway 1

BestätigungAlternative 2

externeRufbestätigung

Übertragung Verbindungs-bestätigung von Gateway 2

Koppelstacks (gerufen)

Übertragung Anforderung an Gateway 2



Übertragung Bewertungvon Gateway 2



Übertragung Belegungan Gateway 2



Anforderungsanzeige Alternative 2









AnzeigeBewertung 2

AnzeigeBewertung 3

AnzeigeBewertung 4

BelegungAlternative 2



BelegungsanzeigeAlternative 2







AnzeigeBestätigungAlternative 2

Abbildung 24: prinzipielles Protokolltiming bei redundantem Verbindungsaufbau

Die Nutzdatenverbindung wird über die Alternative 2 etabliert.

65

4.7.2.3 Die VL-Protokollschicht

66

den Protokollschicht verwaltet.

Im folgenden wird die VL-Protokollschicht der clusterinternen und clusterexternen Kopplung der Kommunikationsplattform dargestellt. Die VL-Protokollschicht stellt die virtuellen Linkbündel bereit (Tunnelprotokoll) und stellt damit die Kernfunktionen der Kopplung dar. Die mit der VL-Protokollschicht gekoppelten Kommunikationspartner verhalten sich bezüglich des Koppelprotokollstacks unterschiedlich. Der eine Kommunikationspartner betreibt die VL-Protokollschicht im User-Mode (Applikationsrechnerverhalten bezüglich VL-Protokoll), während der andere Kommunikationspartner im Gateway-Mode (Vorrechnerverhalten bezüglich VL-Protokoll) betrieben wird (siehe4.7.2.3.3). Die beiden Betriebsmodi der VL-Protokollschicht beziehen sich nur auf den Koppelprotokollstack, d.h. eine mit mehreren Koppelprotokollstacks ausgerüstete Kommunikationsplattform kann unterschiedliche Betriebsmodi verwenden, solange die gekoppelten Partnerinstanzen den entgegengesetzten (komplementären) Betriebsmode verwenden. Innerhalb eines Linkbündels (Koppelprotokollstack) verwenden beide Kommunikationspartner für alle virtuellen Links den gleichen (bezüglich des Kommunikationspartners aber entgegengesetzten) Betriebsmode.

4.7.2.3.1 Protokolldateneinheiten

Die folgende Tabelle beschreibt die Bedeutung der verwendeten PDUs der VL-Protokollschicht des redundanten Koppelprotokolls der Kommunikationsplattform. Bezeichnung der PDU (gehend/kommend)

Bedeutung

(VL_) CON_REQ-CON_IND Anzeige eines Verbindungsaufbauwunsches

(VL_) RDY_REQ-RDY_IND Bewertung des Verbindungsaufbauwunsches

(VL_) RDY_RSP-RDY_CNF Selektion/Bestätigung des Verbindungsaufbauwunsches

(VL_) CON_RSP-CON_CNF Bestätigung der Verbindung (VL_) CON_REL Aufforderung zum Auslösen (VL_) DISCON Anzeige Auslösen

Tabelle 15: PDUs der VL-Protokollschicht des redundanten Koppelprotokolls

4.7.2.3.2 Funktionen

Beim VL-Protocol wird immer ein Partner im Gateway- und der andere im User-Modus betrieben. Die Betriebsart wird durch Konfiguration festgelegt. Diese Festlegung ist infolge der Aufteilung des Adressraumes in gehende und kommende Kanaladressen notwendig. Wegen der getrennten Adressräume ist keine Kollisionsbehandlung von Verbindungsanforderungen und nur ein Minimum an Protokollinformationen je Kanal erforderlich. Die Kennzeichnung der Modi erfolgt mit GATEWAY (Gateway-Modus) und USER (User-Modus). Zwischen den beiden Nutzern des VL-Protokolls können auf einer Verbindung des LINK-Protokolls (LK) mindestens 127 virtuelle Verbindungen unterhalten werden. Die Kanal-Identifikatoren [Kanal-ID] der virtuellen Verbindungen werden von der darüber liegen-

Für die Anforderung oder Anzeige einer virtuellen Verbindung wird der Wertebereich 1 bis 254 verwendet. Andere Identifikatoren dürfen nicht genutzt werden. Wenn die empfangene PDU nicht eindeutig identifizierbar ist, d.h. keiner bestehenden virtuellen Verbindung zugeordnet werden kann, ist eine neue Verbindung zu etablieren, wenn es sich um eine PDU vom Typ VL_CON_IND/ VL_CON_REQ handelt und die [Kanal-ID] im Wertebereich 1 - 254 liegt, anderenfalls ist die PDU zu verwerfen und der physikalische Link (Linkebene/Providerebene) auszulösen. Alle VL-PDU´s werden zur Übertragung in Daten-PDU´s des LINK-Protokolls kodiert.

4.7.2.3.3 Struktur und Kodierung der VL-PDU´s

Jede VL-PDU enthält: Das VL-Präambel-Feld. Die VL-PDU kann, abhängig von der VL-Präambel folgende Felder enthalten:

• Ein Primitiventyp - Feld • Ein Kanal-ID-Feld • Null, ein oder mehrere ASN - kodierte(s) Parameter-Feld(er) • Null oder ein Daten-Feld.

1. Oktett 2. - n-tes Oktett VL-Präambel variabel

Tabelle 16: VL-PDU Aufbau

Daten-Felder und Primitiventyp- / Parameter-Felder schließen sich gegenseitig aus. Das VL-Präambel-Feld ist in jeder VL-PDU enthalten.

67

Kodierung Bedeutung

68

Der Inhalt des Datenfeldes ist nicht beschränkt und stellt die zu übertragende Nutzdateninformation

1 1 1 1 1 1 1 1 Primitive folgt

Kan

alric

htun

g K

anal

num

mer

hi

gh

Kan

alnu

mm

er

Kan

alnu

mm

er

Kan

alnu

mm

er

Kan

alnu

mm

er

Kan

alnu

mm

er

Kan

alnu

mm

er

low

0 X X X X X X X Daten in Kanal Nr. 0XXX XXXX, Gateway, kommend bezüglich Netzebene

1 X X X X X X X Daten in Kanal Nr. 1XXX XXXX, Gateway, gehend bezüglich Netzebene

0 X X X X X X X Daten in Kanal Nr. 1XXX XXXX, User, gehend bezüglich Netzebene

1 X X X X X X X Daten in Kanal Nr. 0XXX XXXX, User, kommend bezüglich Netzebene

Tabelle 17: VL-Präambel Aufbau

Das Kanal-ID-Feld, gefolgt vom Primitiventyp-Feld, folgt dem VL-Präambel-Feld, wenn das VL-Präambel-Feld mit 0xFF belegt ist (Signalisierungsinformation). Das Kanal-ID-Feld hat eine Länge von einem Oktett und stellt eine Referenz der VL-Signalisierungsprimitive auf den virtuellen Kanal dar. Die folgende Tabelle beschreibt die Kodierung des Primitiventyp-Feldes: Primitive Kodierung Bedeutung VL_CON_REQ 0000 0000 Verbindungsaufbauanforderung VL_CON_RSP 0000 0001 Verbindungsaufbauantwort VL_CON_REL 0000 0010 Verbindungsabbauanforderung VL_CON_IND 0000 0011 Verbindungsaufbauanzeige VL_CON_CNF 0000 0100 Verbindungsaufbaubestätigung VL_RDY_REQ 0000 0101 Redundanzkanalanforderung VL_ RDY _RSP 0000 0110 Redundanzkanalantwort VL_ RDY _IND 0000 0111 Redundanzkanalanzeige VL_ RDY _CNF 0000 1000 Redundanzkanalbestätigung VL_DISCON 0000 1001 Verbindungsabbaubestätigung VL_XON 0000 1010 Flusssteuerung aus VL_XOFF 0000 1011 Flusssteuerung ein

Tabelle 18: Kodierung Primitiventyp

Dem Primitiventyp-Feld kann ein ASN-kodiertes Parameter-Feld folgen, falls die übermittelte Signalisierungsprimitive zusätzliche Informationen enthält (z.B. Zieladresse bei VL_CON_REQ). Das Daten-Feld ist in der VL-PDU enthalten, wenn das VL-Präambel-Feld nicht mit 0xFF belegt ist.

dar. Die Referenzierung auf den virtuellen Kanal ist durch die sieben niederwertigsten Bit der VL-Präambel gegeben.

4.7.2.3.4 Zustände und Ereignisse

Zur Beschreibung der VL-Protokollschicht des redundanten Koppelprotokolls mittels Zustands-tabelle werden folgende Zustände eingeführt: Zustand Abkürzung Beschreibung ST_VL_IDLE sta_0 Keine Verbindung aufgebaut ST_VL_WACK_CREQ sta_1 Warten auf VL_RDY_IND/ VL_RDY_REQ ST_VL_ WCON_CREQ sta_2 Warten auf VL_CON_CNF/ VL_CON_RSP ST_VL_WACK_RIND sta_3 Warten auf VL_RDY_RSP/ VL_RDY_CNF ST_VL_WRES_CIND sta_4 Warten auf VLCONrsp ST_VL_DATA_XFER sta_5 Datenübertragung ST_VL_WCON_DREQ sta_6 Warten auf VL_DISCON ST_VL_DOWN sta_7 Endzustand

Tabelle 19: Zustände der VL-Protokollschicht des redundanten Koppelprotokolls

Neben den VL-PDU`s (Informationsaustausch zwischen beiden über die LINK-Protokollebene kommunizierenden VL-Protokollinstanzen) werden Schnittstellen-Primitiven (VLSDU-Informa-tionsaustausch zwischen VL-Protokollinstanz und VL-Protokoll-Nutzer) eingeführt. Bezogen auf den Zustandsautomaten der jeweiligen VL-Protokollinstanz wird jede PDU bzw. SDU als ankommendes bzw. abgehendes Ereignis entsprechend folgender Tabelle aufgefasst:

69

Ereignis Typ Richtung bezüglich VL-Protokollschicht

VL_CON_REQ VLPDU abgehend / ankommend VL_CON_RSP VLPDU abgehend / ankommend VL_CON_IND VLPDU abgehend / ankommend VL_CON_CNF VLPDU abgehend / ankommend VL_RDY_REQ VLPDU abgehend / ankommend VL_RDY_RSP VLPDU abgehend / ankommend VL_RDY_IND VLPDU abgehend / ankommend VL_RDY_CNF VLPDU abgehend / ankommend VL_CON_REL VLPDU abgehend / ankommend VL_DISCON VLPDU abgehend / ankommend M_DATA VLPDU abgehend / ankommend VL_XON VLPDU abgehend / ankommend VL_XOFF VLPDU abgehend / ankommend VLCONind VLSDU abgehend VLCONcnf VLSDU abgehend VLxon VLSDU abgehend / ankommend VLxoff VLSDU abgehend / ankommend VLdiscon VLSDU abgehend VLCONreq VLSDU ankommend VLCONrsp VLSDU ankommend VLCONrel VLSDU ankommend

Tabelle 20: Ereignisse der VL-Protokollschicht des redundanten Koppelprotokolls

Da die Datenfelder keine Primitivenkennung haben, sind sie in der Ereignistabelle als M_DATA aufgeführt. Die folgende Tabelle beschreibt die zulässigen ereignisabhängigen Zustandsübergänge der VL-Protokollschicht des redundanten Koppelprotokolls als Zustandsübergangsmatrix:

70

Ereignis Zustand ST_ VL_IDLE

sta_0 ST_VL_ WACK_CREQ sta_1

ST_VL_ WCON_CREQ sta_2

ST_VL_ WACK_RIND sta_3

ST_VL_ WRES_CIND sta_4

ST_VL_ DATA_XFER sta_5

ST_VL_ WCON_DREQ sta_6

ST_VL_ DOWN sta_7

VL_CON_REQ sta_3 VL_CON_IND sta_3 VL_CON_RSP sta_5 VL_CON_CNF sta_5 VL_RDY_IND sta_2 VL_RDY_CNF sta_4 VL_RDY_REQ sta_2 VL_RDY_RSP sta_4 VL_CON_REL sta_7 sta_7 sta_7 sta_7 sta_6 VL_DISCON sta_7 sta_7 sta_7 sta_7 sta_7 sta_7 sta_7 VL_XON sta_5 VL_XOFF sta_5 M_DATA sta_5 VLCONreq sta_1 VLCONrsp sta_5 VLCONrel sta_7 sta_6 sta_6 sta_7 sta_7 sta_6 VLxon sta_5 VLxoff sta_5

Tabelle 21: Zustandsübergänge der VL – Protokollschicht des redundanten Koppelprotokolls

4.7.2.3.5 Timings VL-Schicht

Verbindungsaufbau – User initiiert: Die Anforderung einer Verbindung erfolgt durch ein VL_CON_REQ. Durch die Primitive VL_RDY_IND wird dem Anfordernden ein Kanal angezeigt, der die Anforderung erfüllen könnte. Der Parameter "OPTIMIZE LEVEL" der Primitive VL_RDY_IND zeigt den Grad des Vermittlungsaufwandes für die Verbindung an. Mit der Primitive VL_RDY_RSP etabliert die anfordernde Seite den ausgewählten Kanal oder weist ihn mit VL_CON_REL zurück. Nach dem Empfang eines VL_CON_CNF ist der Verbindungsaufbau abgeschlossen (User initiiert). Verbindungsaufbau – Gateway initiiert: Die Anforderung einer Verbindung erfolgt durch ein VL_CON_IND. Durch die Primitive VL_RDY_REQ wird dem Anfordernden ein Kanal angezeigt, der die Anforderung erfüllen könnte. Der Parameter "OPTIMIZE LEVEL" der Primitive VL_RDY_REQ zeigt den Grad des Vermittlungsaufwandes für die Verbindung an. Mit der Primitive VL_RDY_CNF etabliert die anfordernde Seite den ausgewählten Kanal oder weist ihn mit VL_CON_REL zurück. Nach dem Empfang eines VL_CON_RSP ist der Verbindungsaufbau abgeschlossen (Gateway initiiert). Die VL_RDY_IND- und VL_RDY_CNF-Antwortzeit wird durch einen Timer überwacht.

71

U

[VL_CON_REQ]

[VL_RDY_IND]

[VL_RDY_RSP]

[VL_CON_CNF]

G U

[VL_CON_IND]

[VL_RDY_REQ]

[VL_RDY_CNF]

[VL_CON_RSP]

Abbildung 25: Verbindungsaufbau vollständig (links: User initiiert; rechts: Gateway initiiert)

G

[VL_CON_REQ]

U

[VL_DISCON]

U

[VL_CON_IND]

[VL_DISCON]

Abbildung 26: Verbindungsaufbau unvollständig – Rufrückweisung (links: User initiiert; rechts: Gateway initiiert)

72

G

[VL_CON_REQ]

[VL_CON_REL]

[VL_DISCON]

U

[VL_CON_IND]

[VL_CON_REL]

[VL_DISCON]

U

Abbildung 27: Verbindungsaufbau unvollständig – Rufrücknahme (links: User initiiert; rechts: Gateway initiiert)

G

[VL_CON_REQ]

[VL_RDY_IND]

[VL_CON_REL]

[VL_DISCON]

U U

[VL_CON_IND]

[VL_RDY_REQ]

[VL_CON_REL]

[VL_DISCON]

Abbildung 28: Verbindungsaufbau unvollständig – Rufrücknahme nach Kanalanzeige (links: User initiiert; rechts: Gateway initiiert)

73

G

[VL_CON_REQ]

[VL_RDY_IND][VL_DISCON]

U U

[VL_CON_IND]

[VL_RDY_REQ]

[VL_DISCON]

Abbildung 29: Verbindungsaufbau unvollständig – Rufrückweisung nach Kanalanzeige (links: User initiiert; rechts: Gateway initiiert)

[VL_CON_IND]

[VL_RDY_REQ]

[VL_RDY_CNF]

[VL_DISCON]

G

[VL_CON_REQ]

[VL_RDY_IND]

[VL_RDY_RSP]

U

[VL_DISCON]

U

Abbildung 30: Verbindungsaufbau unvollständig – Rufrückweisung nach Kanalauswahl (links: User initiiert; rechts: Gateway initiiert)

74

[VL_CON_IND]

[VL_RDY_REQ]

[VL_RDY_CNF]

[VL_DISCON]

G

[VL_CON_REQ]

[VL_RDY_IND]

[VL_RDY_RSP]

U

[VL_DISCON]

U

[VL_CON_REL] [VL_CON_REL]

Abbildung 31: Verbindungsaufbau unvollständig – Rufrücknahme nach Kanalauswahl (links: User initiiert; rechts: Gateway initiiert)

Nutzdatenübertragung: Daten-PDU's werden durch die Kanal-ID gekennzeichnet ( 0 < KANAL-ID < 255) und dadurch eindeutig einer virtuellen Verbindung zugeordnet. Hochpriore Daten (z.B. Notbremsinformation) sind wie normale Daten gekennzeichnet. Sie erhalten vom Nutzer der VL - Protokollschicht lokal (d.h. nicht in der VL-PDU kodiert) ein Attribut, das die höhere Priorität kennzeichnet. Dieses Attribut wird von der VL-Protokollschicht nicht ausgewertet, aber an den Diensterbringer zusammen mit den hochprioren Daten übergeben. Der Diensterbringer für die VL–Schicht (LINK-Protokoll) muss ein geeignetes Verfahren für die Übertragung der hochprioren Daten bereitstellen. Hochpriore Daten unterliegen keiner Flusssteuerung, d.h. sie werden immer (unabhängig vom Flußkontrollzustand der VL-Protokollschicht ) an den Dienst-erbringer übergeben. Flusssteuerung wird also nur bei der Übertragung von Daten-PDU's normaler Priorität verwendet. Wird eine VL-PDU vom Typ XON empfangen, dürfen Daten an den Absender der PDU gesendet werden. Wird eine VL-PDU vom Typ XOFF empfangen, ist das Senden von Daten auf dieser virtuellen Verbindung einzustellen. Innerhalb der Grenzen des Flusskontrollspeichers (Projektierungsparameter) werden aufgrund von Laufzeiten Datenpakete noch akzeptiert.

75

G

[M_DATA]

U U

[M_DATA]

[VL_XOFF] [VL_XOFF]

[VL_XON] [VL_XON]

M_DATA] [M_DATA]

Abbildung 32: Nutzdatenübertragung (links: User initiiert; rechts: Gateway initiiert)

Auslösen: Der Verbindungsabbau kann von jeder Entität, die an der virtuellen Verbindung teilnimmt, erfolgen. Eine Verbindungsabbauanforderung wird durch einen Timer überwacht. Die Protokolldateneinheiten zur Verbindungsabbauanforderung und Verbindungsabbaubestätigung können Nutzdaten (als Parameter) übertragen. Die vollständige Übertragung der Nutzdaten wird nicht garantiert. Eine Abbauanforderung VL_CON_REL ist mit einem VL_DISCON zu bestätigen. Die Überlagerung von Abbauanforderungen beider Kommunikationspartner ist zulässig.

GU

[VL_DISCON]

[VL_CON_REL]

U

[VL_CON_REL]

G

[VL_DISCON]

Abbildung 33: Verbindungsabbau (links: User initiiert; rechts: Gateway initiiert)

76

Bei nichtregulären Betriebsfällen (lokale Fehler) kann das Protokoll spontan ausgelöst werden.

GU

[VL_DISCON]

U G

[VL_DISCON]

Abbildung 34: Verbindungsabbau; lokaler Fehler (links: User initiiert; rechts: Gateway initiiert)

4.7.2.4 Lastbalance

Zur Bewertung eines Verbindungsaufbauwunsches benötigt die Kommunikationsplattform ein Verständnis aller im Vermittlungscluster momentan vorhandenen Nutzkanalverbindungen. Die einzelnen Kommunikationsplattformen eines Vermittlungsclusters tauschen dazu zyklisch und bei Änderung den Status der vermittelten Nutzkanalverbindungen aus (siehe 4.6.3). Eine einlaufende Anzeige eines Verbindungsaufbauwunsches (CON_REQ-CON_IND) wird entsprechend den existierenden Nutzkanalverbindungen (einschließlich der Nachbargateways eines Vermittlungsclusters) bewertet. In Abhängigkeit der Vermittlungslast und der Präsenz nutzbarer Netzverbindungen der Kommunikationsplattform wird ein Bewertungsparameter (Optimize-Level) ermittelt. Dieser Bewertungsparameter wird als Parameter der RDY_REQ-RDY_IND - PDU der rufenden Instanz übermittelt. Die rufende Instanz entscheidet entsprechend der eingelaufenen Be-wertungsparameter (Optimize-Level), welcher der angeforderten redundanten Kanäle zur Etablierung der Nutzdatenverbindung verwendet wird. Die restlichen angeforderten redundanten Kanäle werden wieder freigegeben (Auslösen). Durch dieses Verfahren wird die Vermittlungslast (Nutzdatenkanäle) auf die Gateway-Instanzen eines Vermittlungsclusters gleichmäßig verteilt. Das Verständnis der Gateway-Instanzen kann auch genutzt werden, um unterlagerte Netzprovider dynamisch an die Verhältnisse der Vermittlungslast anzupassen (Lastmonitor zur Anforderung von Netzbandbreiten z.B. bei ATM).

77

79

Die folgende Abbildung zeigt die Adaption eines Treiberinterfaces (S2M-Karte CAPI-Version) an einen „USER-STREAM Port“ der Ablaufumgebung (als konfigurierte Instanz entsprechend dem

5 Designaspekte

5.1 Kapselung des OS

Die folgende Tabelle gibt einen Überblick, über die in der Kommunikationsplattform in der untersten Schicht der Kommunikationstask (z.B. UTILS-Bibliotheken) bzw. als OS-Kernel-Erweiterung verwendeten betriebssystemabhängigen Betriebsmittel und Basisfunktionen, entsprechend dem Schalenmodell der Betriebsmittel der Kommunikationsablaufumgebung (siehe Abbildung 17). Betriebsmittel/Basisfunktion Bedeutung Speicherverwaltung Verwaltung und Überwachung des

dynamischen Speichers Trace- und Debugunterstützung Standardfunktionen zur Trace- und

Debugausgabe auf Konsole oder Tracefiles

KS-Modul Managementfunktionen zum einheitlichen Laden und Konfigurieren von in der Kommunikationsplattform verwendeten SVR4-Streams Modulen

Konfigurationsdatenverwaltung (ASCII-Parser)

Einheitliches Format der Konfigurationsdaten in den Konfigurationsdateien

Ereignisverwaltung (Multiple Wait) Abstraktion Multiple/Wait – Betriebsmittel (select/poll) Verwaltung Basisscheduler

Zeitereignisverwaltung Verwaltung Timerschnittstelle, Koordination von Zeitereignissen mit Multiple/Wait – I/O Ereignissen

Prozesssignalverwaltung Kapselung der Signale des Betriebssystems

I/O - Kapselung(TLI,TTY) Abstraktion von Schnittstellen bezüglich Konfigurations- und Adressparametern

Tabelle 22: betriebssystemabhängige Betriebsmittel und Basisfunktionen

Die Protokoll- und Vermittlungsfunktionalitäten der Kommunikationsplattform laufen in einer vom unterlagerten Betriebssystem weitgehend unabhängigen Ablaufumgebung „USER-STREAM“ (siehe 5.3.3) im USER-Space ab. Zur Umsetzung von komplexen Protokollschichten mit Multiplexfunktionalitäten werden „US_MULTIPLEXER“ (siehe 5.4.2) verwendet. „US_KONVERTER“ (siehe 5.4.1) bilden einfache Protokollschichten ab. Der Zugriff auf die im Betriebssystem vorhandenen Standard-Treiber und -Protokolle wird in der Ablaufumgebung mit Hilfe von „US_PORTS“ sichergestellt.

Schichtenmodell der Kommunikationsplattform; siehe Abbildung 18) zur Verwendung in der Streckenzentrale des Funk Fahr Betriebes.

OS-KERNEL

Kommunikationsapplikation (Vermittlungslogik)

Stacks

User Stream

Kommunikationstask

us-Head us-Head us-Head

us-Konv

us-Konv

us-Konv us-Konv

us-Multiplexer

us-Konv

us-Konv

us-Konv

us-Konv

S2M - Hardwaretreiber

CAPI - Interface

us-Port us-Port

CAPI-PortCAPI-CNTL

/dev/capi (fd)CAPI-Daemon

/dev/capi (fd)

Konfiguration

Firmware-Loader

Interface CNTL

S2M - Firmware - Interface

S2M-Firmware

Signalisierungsstack B - Kanal - Stack

Abbildung 35: Prinzipieller Aufbau der Adaption des S2M-Treiber für die Streckenzentrale des Funk Fahr Betriebes

Dem Vorteil der hohen Portabilität und leichten Adaptierbarkeit an vorhandene Treiber stehen moderate Performanzeinbußen und die Notwendigkeit der Präsenz von Kommunikationsbasis-bibliotheken gegenüber. Für die Anwendungen der Kommunikationsplattform im Funk Fahr Betrieb sind die genutzten Hardware- und Betriebssystemressourcen inklusive der Protokoll- und Vermittlungslogik kein begrenzender Faktor. Die verwendeten GSM/R-Netzlinks (Bearer Service 25) im Zusammenspiel mit den verwendeten EURORADIO-Protokollen begrenzen die Gesamt-performanz des Kommunikationssystems.

5.2 OS - abhängige Betriebsmittel

5.2.1 KS-Modul

Die Bibliothek zum einheitlichen Laden und Konfigurieren von in der Kommunikationsplattform verwendeten SVR4-Streams-Modulen stellt folgende Anforderungen an die zu verwaltenden Einheiten:

80

• Eine spezifische Funktion zum Parsen der modulspezifischen Konfigurationsparameter und

81

KS_MODUL: BLK_CHK

Generieren der modulspezifischen IOCTL-Konfigurationsnachrichten wird in der KS-Modul-bibliothek registriert.

• Die schreibseitige Empfangsroutine (wput) der SVR4-Streams-Module wertet die modul-spezifischen IOCTL-Konfigurationsinformationen aus. Von der KS-Modul-Bibliothek ver-waltete SVR4-Streams-Module müssen dementsprechend eine spezifische Funktion (im nach-folgenden C-Quellcode-Beispiel: stx_etx_putioc) enthalten, welche die schreibseitig empfange-nen M_IOCTL-Konfigurationsdaten auswertet.

Um das Laden und Konfigurieren der im OS-Kernel ablaufenden SVR4-Streams-Module der Kommunikationsplattform zu vereinfachen, stellt die KS-Modul-Bibliothek eine Management-funktion zur Verfügung. Die folgende Tabelle beschreibt die Managementfunktion der Bibliothek zum einheitlichen Laden und Konfigurieren von in der Kommunikationsplattform verwendeten SVR4-Streams-Modulen. Management Multiple-Wait-Ereignisverwaltung

Beschreibung

ksm_up Dieser Funktion wird ein Filedeskriptor und ein Konfigurationsstring übergeben. In diesem Konfigurationsstring sind die SVR4-Streams-Module, die geladen werden sollen und deren Konfigurationsdaten eingetragen. Auf den übergebenen Filedeskriptor (des geöffneten Streams) werden nacheinander die entsprechend der Konfiguration festgelegten SVR4-Streams-Module geladen (push) und über IOCTL-Messages mit Konfigurationsparametern versorgt.

Tabelle 23: Managementfunktionen zum Laden und Konfigurieren von SVR4-Streams Modulen

In der Reihenfolge der im Konfigurationsstring angegebenen Modulkennungen werden die Streamsmodule geladen und entsprechend den modulspezifischen Parametern im Konfigurations-string mit Konfigurationsdaten (M_IOCTL) versorgt, d.h. die vom Streamsmodul benötigten spezi-fischen Konfigurationsparameter werden nach dem Laden (push) des jeweiligen Moduls in den Stream mit Hilfe von in der KS-Modul-Bibliothek registrierten, modulspezifischen Funktionen (im USER SPACE ablaufend) als IOCTL - Rufe an das Modul gesendet. In der folgenden Beispielkonfiguration sind die Parameter für zwei zu ladende einfache Streamsmodule (STX_ETX-Quotingmodul und BLK_CHK-Prüfsummenmodul) angegeben. Die Streamsmodule selber sind mit dem Schlüsselword "KS_MODUL" gekennzeichnet. # STX_ETX-MODULE-CONFIGURATION STX: 0x02 ETX: 0x03 DLE: 0x10 # BLK_CHK-MODULE-CONFIGURATION BLK_CHK_MODE: CRC_32 KS_MODUL: STX_ETX

82

}

In dem folgenden C-Quellcode-Beispiel (USER SPACE) sind nach der Ausführung der Managementfunktion „ksm_up“ auf einem geöffneten Filedeskriptor eines seriellen Interfaces (z.B. „/dev/tty00“) die Streamsmodule entsprechend der Beispielkonfiguration „param_string“ geladen und konfiguriert: ... if (( fd = open( “/dev/tty00”, O_RDWR)) < 0) { printf(“open error!\n”); exit( ERROR); } ... if ( ksm_up( fd, param_string) == ERROR) { printf(“ksm_up error!\n”); exit( ERROR); } ... In dem folgenden C-Quellcode-Beispiel (OS-KERNEL) ist die PUT-Prozedur der Schreibwarte-schlange (wqueue) des STX_ETX-Quotingmoduls abgebildet. Die Funktion „stx_etx_putioc“ enthält die Behandlung der modulspezifischen Konfigurationsdaten. /**************************************************************** * * stx_etx_wput - Module write queue put procedure. * ****************************************************************/STATIC int stx_etx_wput( queue_t *q, mblk_t *mp) { switch ( mp->b_datap->db_type) { case M_DATA: if (putq( q,mp) == 0) { cmn_err(CE_WARN,"^stx_etx: putq out of blocks!"); freemsg( mp); return( ENXIO); } break; case M_IOCTL: return( stx_etx_putioc( q, mp)); break; default: putnext( q, mp); break; } return( OK);

/* * stx_etx parameter setzen */ int stx_etx_putioc( queue_t* q, mblk_t* mp) { struct iocblk *iocp; int i; iocp = ( struct iocblk *)mp->b_rptr; /* fremdes IOCTL */ if (((stx_etx_privat_t*)(q->q_ptr))->param != NULL) { putnext( q, mp); return( OK); } /* falsches IOCTL */ if ( (iocp->ioc_cmd != SET_STX_ETX_PARAM) || (iocp->ioc_count != sizeof( stx_etx_param_t)) || (mp->b_cont == NULL) || (((stx_etx_param_t*)mp->b_cont->b_rptr)->max_len < 0) || (((stx_etx_param_t*)mp->b_cont->b_rptr)->dummy < 0)) { mp->b_datap->db_type = M_IOCNAK; iocp->ioc_count = 0; qreply( q, mp); return( OK); } /* Speicher fuer Parameterstruktur holen */ if ((((stx_etx_privat_t*)q->q_ptr)->param = kmem_zalloc( sizeof(stx_etx_param_t), KM_NOSLEEP)) == NULL) { cmn_err(CE_WARN,"^stx_etx: stx_etx_putioc: out of memory!"); return( ENOMEM); } /* Parameter uebernehmen */ ((stx_etx_privat_t*)q->q_ptr)->param->STX = ((stx_etx_param_t*)mp->b_cont->b_rptr)->STX; ((stx_etx_privat_t*)q->q_ptr)->param->ETX = ((stx_etx_param_t*)mp->b_cont->b_rptr)->ETX; ((stx_etx_privat_t*)q->q_ptr)->param->DLE = ((stx_etx_param_t*)mp->b_cont->b_rptr)->DLE; /* ACK fuer ioctl */ mp->b_datap->db_type = M_IOCACK; iocp->ioc_count = 0; qreply( q, mp); /* q' s aktivieren */ enableok( q);

83

enableok( RD( q)); qenable( q);

qenable( RD( q)); #ifdef DEBUG cmn_err( CE_NOTE, "^Stream STX_ETX-Module ready"); #endif return( OK); }

5.2.2 Multiple-Wait-Ereignisverwaltung

Der gesamte über die Grenzen der Kommunikationstask hinwegführende Informationsaustausch erfolgt ausschließlich über Filedeskriptoren (Devices, Pseudodevices, Pipes, Files). Sowohl in schreibender als auch in lesender Richtung werden ausschließlich nichtblockierende Systemrufe verwendet. Befindet sich die Kommunikationsplattform (bezüglich der Kommunikationstask) in einem Zustand, in dem „momentan“ keine Informationen zu verarbeiten sind, so verharrt die Task auf einem blockierenden Multiple-Wait-Systemaufruf (poll/select). Die Koordination der einlaufenden Informationen, ihre Interpretation als Ereignis und Verteilung auf die zugehörigen Callback-Funktionen wird durch die Multiple-Wait-Ereignisverwaltung reali-siert. Die folgende Abbildung zeigt den prinzipiellen Aufbau der in der Kommunikationsplattform ver-wendeten Multiple-Wait-Ereignisverwaltung.

Basis Schedule

Multiple Wait Callback

fd_poll_data_list

pollfd_1fd_to_poll

revents

events

fd

pollfd_2revents

events

fd

pollfd_3revents

events

fd

pollfd_4revents

events

fd

pollfd_nrevents

events

fd

fd_poll_data_n

usr_arg

handle

revents

events

fd

fd_poll_data_4

usr_arg

handle

revents

events

fd

fd_poll_data_3

usr_arg

handle

revents

events

fdfd_poll_data_2

usr_arg

handle

revents

events

fdfd_poll_data_1

usr_arg

handle

revents

events

fd

fd_poll_schedule_n

usr_arghandle

fd_poll_schedule_3

usr_arghandle

fd_poll_schedule_2

usr_arghandle

fd_poll_schedule_1

usr_arghandle

Callback-Multiple-Wait-Ereignisverwaltung der Kommunikationsplattform

Abbildung 36: Struktur der Multiple-Wait-Ereignisverwaltung

84

Alle in der Multiple-Wait-Ereignisverwaltung registrierten Ereignisquellen sind in der Liste

85

Wait-Ereignisverwaltung der Kommunikationsplattform) aktiviert:

„fd_poll_data_list“ hinterlegt. Jedes Element dieser Liste enthält neben dem zu überwachenden Filedeskriptor eine Bytemaske (events) zur Selektion der gewünschten Ereignisarten des „poll“-Systemrufs und ein Bytefeld (revents) zur Anzeige der am Filedeskriptor anliegenden Ereignisse (z.B. POLLIN, POLLOUT, POLLERR, POLLNVAL). Vor Eintritt in den blockierenden Multiple-Wait-Systemaufruf wird aus der Liste der registrierten Ereignisquellen eine systemaufrufabhängige Verwaltungsstruktur aufgebaut bzw. aktualisiert. Bei Verwendung des „poll“-Systemaufrufs besteht diese Verwaltungsstruktur aus einem Array (fd_to_poll). Kehrt der blockierende Multiple-Wait-Systemaufruf einer wartenden Kommunikationstask infolge anliegender Ereignisse zurück, so wird die Verwaltungsstruktur des Systemaufrufs genutzt, um die Liste der registrierten Ereignisquellen zu aktualisieren. Anschließend werden nacheinnander alle Callback-Funktionen aufgerufen, deren Filedeskriptoren anliegende Ereignisse (revents) angezeigt haben. Es ist Aufgabe der Callback-Funktion, auf Basis der am Filedeskriptor anliegenden Ereig-nisse, mit Hilfe nichtblockierender Systemrufe (z.B. read/getmsg), die bereitstehenden Informa-tionen vom entsprechenden Fileskriptor abzuholen und in der Softwarekomonente (z.B. USER-STREAM-Port – siehe 5.3.3), welche die Callback-Funktion in der Multiple-Wait-Ereignisver-waltung registrierte, zu bearbeiten. Nach der Abarbeitung aller anliegenden Ereignisse, also vor Wiedereintritt in den blockierenden Multiple-Wait-Systemaufruf, werden alle in der Scheduleliste registrierten Callback-Funktionen solange wechselseitig aktiviert, bis die jeweils aktivierte Callback-Funktion durch Rückgabewert anzeigt, dass kein Bearbeitungsbedarf mehr vorliegt. Die folgende Tabelle beschreibt die grundsätzlichen Managementfunktionen der Multiple-Wait-Ereignisverwaltung der Kommunikationsplattform: Management Multiple-Wait-Ereignisverwaltung

Beschreibung

ins_fd_poll Ein Auftrag zur filedeskriptorbezogenen Ereignisverwaltung eines Callback-Handlers wird übergeben.

del_fd_poll Ein bestehender Auftrag zur filedeskriptorbezogenen Ereignisverwaltung wird zurückgenommen.

run_fd_poll Die Steuerung der Kommunikationstask wird an die Multiple-Wait-Ereignisverwaltung übergeben. (d.h. nach Abschluß der Initialisierungsphase werden sämtliche Aktivitäten der Kommunikationstask ausschließlich über Callback-Handler gesteuert)

fd_poll_ins_schedule Der übergebene Callback-Handler wird in die Scheduleverwaltung aufgenommen.

fd_poll_del_schedule Der übergebene Callback-Handler wird aus der Scheduleverwaltung entfernt.

Tabelle 24: Managementfunktionen zur Multiple-Wait-Ereignisverwaltung

In dem folgenden C-Quellcode-Beispiel (USER SPACE) wird nach der Ausführung der Manage-mentfunktion „ins_fd_poll“ der Callback-Handler „example_fd_poll_handler“ bei einlaufenden Er-eignissen am Filedeskriptor „example_fd“ durch die fd_poll-Bibliothek (Ausprägung der Multiple-

86

... polldata.fd = example_fd; polldata.events = POLLIN; polldata.handle = example_fd_poll_handler; polldata.usr_data = (void*)example_usr_data_ptr; /* register callback */ if ( ins_fd_poll( &polldata) == ERROR) { printf("ins_fd_poll error!\n"); exit( ERROR); } ... Das folgende C-Quellcode-Beispiel (USER SPACE) enthält den Callback-Handler „example_fd_poll_handler“: /************************************************************** * * example_fd_poll_handler – Example fd_poll-Callback * *************************************************************/ void example_fd_poll_handler( fd_poll_data_t *polldata_ptr) { if ( polldata_ptr == NULL) { printf("polldata_ptr error!\n"); exit( ERROR); } /* example_usr_data */ example_usr_data_ptr = ( example_usr_data_t*)( polldata_ptr->usr_data); /* special poll revents */ if (( polldata_ptr->revents & ( POLLERR | POLLHUP | POLLNVAL)) != 0) { printf( "example_fd_poll_handle:” "special poll revents[%d] at fd[%d]\n", polldata_ptr->revents, polldata_ptr->fd); /* special poll service */ ... } /* POLLIN revent */ if (( polldata_ptr->revents & ( POLLIN)) != 0) { printf( "example_fd_poll_handle: POLLIN at fd[%d]\n", polldata_ptr->fd);

/* POLLIN service */ ... } return; } Ein Callback-Handler kann für unterschiedliche Instanzen gleichzeitig genutzt werden. Der Bezug vom auftretenden Ereignis, infolge dessen der Callback-Handler aufgerufen wird und der zuständigen Verwaltungsinstanz (welche den Callback-Handler auf dem Filedeskriptor durch die fd_poll-Bibliothek registrierte) ist durch eine dem Nutzer der fd_poll-Bibliothek zur Verfügung gestellte „usr_arg“-Pointerreferenz gegeben.

5.2.3 Zeitereignisverwaltung

Die folgende Abbildung zeigt den prinzipiellen Aufbau der in der Kommunikationsplattform verwendeten Zeitereignisverwaltung.

Callback-Ereignissteuerung

Kommunikationstask

OS-KERNEL

fd -- time_base

non-blocked-write

Timebase-Ereignissteuerung

time_job_list

time_job_n

usr_arghandletime_out

time_job_2


time_job_1


time_job_control

delta-time-akndelta-time-req

time_base-callback_handle

select_actual_time_job

timebase-Treiber

Kernel- time_job_listtime_job_1

to_idtime_job_ref time_job_2

to_idtime_job_ref time_job_n

to_idtime_job_refStreams - Head

Kernel- time_job_control

untimeoutitimeout

Abbildung 37: Struktur der Zeitereignisverwaltung

Die Zeitereignisverwaltung der Kommunikationsplattform nutzt zur Registrierung von Verzögerungsaufträgen der Kommunikationstask die Liste „time_job_list. Durch diese Liste wird jedem laufenden Verzögerungsauftrag neben der Callback-Funktion eine eindeutige Referenz und

Timebase-Ereignissteuerung der Kommunikationsplattform

87

die restliche Verzögerungszeit zugeordnet. Der Listeneintrag zur restlichen Verzögerungszeit wird nur bei Verzögerungsaufträgen großer Zeitintervalle verwendet (z.B. größer eine Sekunde). • Verzögerungsaufträge großer Zeitintervalle

Um die Anzahl von Verzögerungsaufträgen im Treiber zu reduzieren, werden alle Verzögerungsaufträge großer Zeitintervalle über eine Zeitbasis abgebildet. Dazu startet die Zeitereignisverwaltung zyklisch einen Verzögerungsauftrag (kleines Zeitintervall) konstanter Länge. Alle hinterlegten Verzögerungsaufträge großer Zeitintervalle werden modulo einer konstanten Verzögerungszeit (z.B. 100 Millisekunden), repräsentiert durch den zyklischen Verzögerungsauftrag der Zeitereignisverwaltung selbst, dekrementiert.

• Verzögerungsaufträge kleiner Zeitintervalle

Verzögerungsaufträge kleiner Zeitintervalle werden über Austauschprimitiven an den Timebase-Treiber der Zeitereignisverwaltung übergeben. Jeder an den Timebase-Treiber übergebene Verzögerungsauftrag bleibt solange registriert, bis der Timebase-Treiber, auf Anforderung durch die Timebase-Ereignissteuerung, die Freigabe des Verzögerungsauftrages angezeigt hat. Der Timebase-Treiber bildet die Verzögerungsanforderungen auf die OS-KERNEL – spezifischen Systemrufe „itimeout“ bzw. „intimeout“ ab.

Die folgende Tabelle beschreibt die Austauschprimitiven zwischen der Timebase-Ereignissteuerung und dem Timebase-Treiber der Zeitereignisverwaltung der Kommunikationsplattform: Austauschprimitive Beschreibung TIME_JOB_REQ Die Kommunikationstask aktiviert im Timebase-Treiber einen

Verzögerungsauftrag. (Die Verzögerungszeit und eine eindeutige Referenz werden übergeben)

TIME_JOB_AKN Der Timebase-Treiber zeigt der Kommunikationstask den Ablauf eines Verzögerungsauftrages an. (Die eindeutige Referenz des Verzögerungsauftrages bleibt bis zum Löschauftrag belegt)

TIME_JOB_ERASE_REQ Die Kommunikationstask fordert den Treiber auf, die eindeutige Referenz eines (abgelaufenen oder noch nicht abgelaufenen) Verzögerungsauftrages freizugeben.

TIME_JOB_ERASE_AKN Der Timebase-Treiber zeigt der Kommunikationstask die geforderte Freigabe einer eindeutigen Referenz an.

Tabelle 25: Austauschprimitiven der Zeitereignisverwaltung

Die folgende Tabelle beschreibt die grundsätzlichen Managementfunktionen der Zeitereignis-verwaltung der Kommunikationsplattform:

88

Management Beschreibung Zeitereignisverwaltung activate_timebase Die Bibliothek zur Zeitereignisverwaltung wird aktiviert. deactivate_timebase Die Bibliothek zur Zeitereignisverwaltung wird deaktiviert. ins_time_job Ein Auftrag zur zeitverzögerten Ausführung einer Callback-

Funktion wird übergeben. del_time_job Ein noch nicht abgelaufener Auftrag zur zeitverzögerten

Ausführung wird zurückgenommen.

Tabelle 26: Managementfunktionen zur Zeitereignisverwaltung

5.2.4 Prozesssignalverwaltung

Die für die Kommunikationsapplikation relevanten Prozesssignale werden in der Initialisierungs-phase mit speziellen Signalhandlern versehen. Nach Eintreffen eines Prozesssignals (z.B. SIGTERM) wird der in der Initialisierungsphase registrierte Signalhändler aufgerufen. Der Signal-händler aktiviert in der Zeitereignisverwaltung einen Timejob mit einer Delay-Zeit von null. Die direkte Aktivität des Signalhändlers ist damit abgeschlossen. Die eigentlichen prozesssignalbedingten Aktivitäten werden vom Callback-Handler des aktivierten Timejobs der Zeitereignisverwaltung übernommen. Somit ist sichergestellt, dass normale Prozess-signale die Abarbeitung von Callback-Ereignishandlern nicht unterbrechen können.

5.2.5 Vermeidung der Nebenläufigkeit in der Ereignisverwaltung

Die Kapazität (Durchsatz) des GSM/R Kanals ist die begrenzende Größe des EORORADIO-basierten Kommunikationssystems der FFB-Anwendung. Die Rechenleistung der Gatewayrechner ist ausreichend, um die Protokollfunktionalitäten (EURORADIO und Koppelprotokoll) mit den notwendigen Echtzeiteigenschaften ablaufen zu lassen. Eine Multiprozessornutzung innerhalb einer Vermittlungstask wird dementsprechend nicht benötigt. Innerhalb des Kommunikationsframeworks (siehe 4.5) wird die Repräsentationsform einlaufender Informationen in den Multiple-Wait-Callback-Handlern (in Abbildung 38: get_info) in das USER STREAM Messagequeue Modell (siehe 5.3.3) überführt. Diese Überführung kostet wenig Rechenleistung und benötigt keine Priorisierung bzw. Nebenläufigkeit (parallele Nutzung von Ausführungsfäden). Der Informationsfluss durch die Kommunikationsstacks des USER STREAM wird mittels prioritätsbehafteter Nachrichten auf flusskontrollgesteuerten asynchronen Kommunikationskanälen organisiert. Bei Verlassen des USER STREAM Messagequeue Modells wird in den USER STREAM Ports die als USER STREAM Message vorliegende Information in die außerhalb benötigten Formate gewandelt. Diese Umwandlung kostet wenig Rechenleistung und benötigt keine Priorisierung bzw. Nebenläufigkeit. Zustandsbehaftete Protokolleigenschaften werden über ereignisgekoppelte Automaten (siehe 5.3.1) realisiert. Die Bearbeitung der einzelnen Transitionen erfolgt nichtblockierend und erfordert auf Grund der ausreichenden Rechenleistung keine Priorisierung bzw. Nebenläufigkeit. Die folgende Abbildung zeigt das Prinzip der nachrichten-orientierten Informationsverarbeitung der Vermittlungstask.

89

get_info(callback)

EventMsg

STM

US_MSG Queue

US_PORT

WR RD

WR RDWR RD

WR RD

put_q/putnextput/srv(callback)

put_info

EventMsg

STM

put_q/putnext put/srv(callback)

US_MODUL (MUX/KONV)

Abbildung 38: Nachrichtenorientierte Informationsverarbeitung der Vermittlungstask

Die Zuteilung der Verarbeitungsaktivitäten erfolgt durch den Scheduler der USER STREAM Ablaufumgebung entsprechend den Flusskontrollzuständen der Messagequeues oder indirekt durch die Flusskontrollautomaten-abhängige Speisung der Messagequeus der einzelnen Protokollschich-ten. Die Notwendigkeit der Organisation nebenläufiger Programmablaufaktivitäten innerhalb der Vermittlungstask wird durch die Anwendung der nachrichtenorientierten-Schedulingaktivitäten (prioritätsgesteuert und flusskontrollabhängig) des Kommunikationsframeworks (siehe 4.5) ver-mieden. Die Kombination von Multiple-Wait-Ereignissteuerung mit eingebetteter Zeitereignis-steuerung und Messagequeue - orientierter Ablaufumgebung macht die Verwendung von Betriebs-

90

mitteln zum Management paralleler Ausführungsfäden (Multithreading) in der Vermittlungstask der Kommuniukationsplattform überflüssig. Die Verwaltung der nebenläufigen Ausführungsfäden (z.B. gegenseitiger Ausschluss zur Vermeidung von Inkonsistenzen) würde die Komplexität des Kommunikationsframeworks unnötigerweise erheblich steigern.

5.3 OS - unabhängige Betriebsmittel

5.3.1 Statemaschine

Die folgende Abbildung zeigt beispielhaft das Modell der in der Kommunikationsplattform ver-wendeten Zustandsautomaten.

Abbildung 39: Beispiel eines Zustandsautomaten der Kommunikationsplattform

Die folgende Tabelle beschreibt die Elemente des allgemeinen Modells der in der Kommunikations-plattform verwendeten Zustandsautomaten.

EXAMPLE_ST_IDLE

EXAMPLE_ST_DOWN

EXAMPLE_EV_START

example_idle_activ_1_handleexample_idle_activ_2_handle

EXAMPLE_ST_ACTIV

EXAMPLE_EV_DEACTIVATE

EXAMPLE_EV_DOWN

example_active_idle_1_handleexample_active_idle_2_handle

EXAMPLE_EV_DEACTIVATE

example_idle_down_1_handleexample_idle_down_2_handle

example_activ_down_1_handleexample_activ_down_2_handle

91

Bezeichnung des Bedeutung Elements STATE Zustand des Automaten EVENT Ereignis (Anstoß für Zustandsübergang) ACTION Transition (Zustandsübergang) HANDLERLIST Liste mit auszuführenden Händlern (beim

Zustandsübergang) HANDLER Funktion, die beim Zustandsübergang ausgeführt

wird.

Tabelle 27: Elemente des Zustandsautomaten

Das allgemeine Modell der in der Kommunikationsplattform verwendeten Zustandsautomaten wird in zwei unterschiedlichen Ausprägungen (siehe 5.3.1.1 und 5.3.1.2), welche sich in der Art der Verwaltung der Zustandsübergangslogik unterscheiden, genutzt. Jede Instanz eines Zustandsautomaten der Kommunikationsplattform verwaltet die aktuelle Bearbeitungssituation (Actual Condition). Wird ein Ereignis an die Instanz eines Zustands-automaten übergeben, hängt die Reaktion der Automateninstanz von der aktuellen Bearbeitungs-situation ab. Ein übergebenes Ereignis wird als sekundäres Ereignis betrachtet, wenn die Abarbei-tung vorher übergebener Ereignisse noch nicht abgeschlossen ist. Sekundäre Ereignisse werden in der Reihenfolge ihres Eintreffens in der Automateninstanz zwischengespeichert (Eventcache). Befindet sich die Automateninstanz nicht im Zustand der Abarbeitung eines Ereignisses, so wird das übergebene Ereignis als primäres Ereignis behandelt. Ein primäres Ereignis wird sofort bearbeitet, indem die entsprechend des Ausgangszustandes (STATE) der Automateninstanz und des übergebenen Ereignisses hinterlegte Transition (ACTION) ausgeführt wird. Nach Bearbeitung der Transition aktualisiert die Automateninstanz ihren Zustand (STATE). Damit ist die Bearbeitung eines primären Ereignisses abgeschlossen. Anschließend wird, falls vorhanden, das älteste sekun-däre Ereignis aus dem Zwischenspeicher der Automateninstanz entfernt und als primäres Ereignis abgearbeitet. Transitionen der Zustandsautomaten der Kommunikationsplattform werden durch Handlerlisten (HANDLERLIST) repräsentiert.

5.3.1.1 Fest kodierte Automaten

Die folgende Abbildung zeigt den prinzipiellen strukturellen Aufbau der Zustandsübergangslogik eines fest kodierten Automaten.

92

F IX _S T M _S T A T E _TF IX _ S T M _T

IN T LA ST A C TIO NIN T S T AT EC H A R *ST A T E _ N A M E

IN T E VE N T

F IX _ S T M _ A C T IO N _T

IN T D E S T IN A T IO N _ ER R O R

C H A R *AC T IO N _N A M E

IN T EV E N T

IN T D E ST IN A TI O N _ O K

IN T (* F U N C )( ...)

C H A R *H A N D L E _ N A M E

F IX _ S T M _ H A N D L E _ T

IN T L AS T H A N D LE

IN T (*F U N C )(...)

C H A R *H A N D L E_ N A M E

F I X _S T M _H A N D L E _T

IN T ( *F U N C )(...)

C H AR *H AN D L E _ N AM E


IN T EV E N T

F IX _S T M _A C T IO N _T

IN T D E ST IN A TIO N _ E R R O R

C H AR *A C T IO N _ N AM E

IN T E V EN T

IN T D E ST IN AT IO N _ O K

IN T (*F U N C )( ...)

C H A R *H A N D LE _ N A M E

F I X _S T M _ H A N D L E _T

IN T L A S T H A N D L E

IN T (*F U N C )(.. .)



IN T (*F U N C )(...)

C H A R * H A N D L E _ N A M E


IN T E V EN T

F IX _ S T M _ A C T IO N _ T

IN T D ES T IN A T IO N _ E R R O R

C H A R *A C T IO N _ N A M E

IN T E VE N T

IN T D E S T IN A T IO N _ O K

IN T (*F U N C )(...)



IN T L A ST H AN D L E

IN T (*F U N C )(...)

C H A R *H A N D L E _N A M E


IN T (*F U N C )(...)



F IX _S T M _S T A T E _T

IN T LA ST A C T IO NIN T S T AT EC H A R *ST A T E_ N A M E

IN T E VE N T



C H A R *A C TI O N _ N A M E

IN T EV E N T

IN T D E ST IN A TIO N _ O K

IN T (* F U N C )( ...)


F I X _ S T M _ H A N D L E _ T


IN T (* FU N C )( ...)

C H AR *H A N D L E_ N A M E

F IX _S T M _H A N D L E _T

IN T ( *F U N C )(...)

C H A R *H AN D L E _N AM E


I N T EV E N T


IN T D E ST IN AT IO N _ E R R O R

C H AR *A C T IO N _ N AM E

IN T E V EN T

IN T D ES T IN AT IO N _ O K

IN T (*F U N C )( ...)



IN T L A S TH A N D L E

IN T (*F U N C )(...)



IN T (* F U N C )( ...)



IN T E V EN T


IN T D ES T IN A T IO N _ E R R O R

C H A R * AC T IO N _ N A M E

IN T E VE N T

IN T D E S T IN A T IO N _ O K

IN T (*F U N C )(...)

C H A R *H AN D L E _N AM E


IN T L AS T H AN D L E

IN T (*F U N C )(...)


F I X _ S T M _ H A N D L E _ T

IN T (* FU N C )( ...)


F IX _S T M _H A N D L E _T

F IX _S T M _S T A T E _T

IN T LA S TA C T IO NIN T S T A TEC H A R *S TA T E _ N A M E

IN T E V EN T



C H A R *AC T IO N _ N A M E

IN T EV E N T

IN T D E S TI N A T IO N _ O K

I N T (* F U N C )( ...)



IN T LAS T H A N D LE

IN T (* F U N C )( ...)


F I X _S T M _ H A N D L E _ T

IN T ( *F U N C )( ...)

C H AR *H AN D L E_ N AM E

F IX _ S T M _H A N D L E _ T

IN T E VE N T


IN T D E S TI N A T IO N _ E R R O R

C H AR *A C TIO N _ N A M E

IN T E V E N T

IN T D E ST IN AT IO N _ O K

IN T (*F U N C )( ...)




IN T (*FU N C )( ...)


F IX _ S T M _H A N D L E _T

IN T (*F U N C )( ...)

C H A R *H A N D L E _ N AM E


IN T E V E N T


IN T D ES T IN AT IO N _ E R R O R

C H A R * A C T IO N _ N A M E

IN T E VE N T

IN T D ES T IN A T IO N _ O K

IN T (*F U N C )( ...)

C H AR *H AN D L E_ N AM E

F IX _ S T M _H A N D L E _ T

IN T L A ST H AN D L E

I N T (*F U N C )(...)



IN T (*F U N C )(...)



C H A R *ST M _ N A M E IN T L A S TS T A T E

Abbildung 40: struktureller Aufbau der Zustandsübergangslogik eines fest kodierten Automaten

Alle Elemente der Zustandsübergangslogik sind in festen Arrays gespeichert. Die Längen der Arrays sind separat vermerkt. Neben der Zustandsübergangslogik, die für alle Instanzen des fest kodierten Automaten gemeinsam genutzt wird, benötigt eine Instanz eines fest kodierten Automaten einen Ereignisspeicher (Eventcache) und eine Struktur zum Vermerken der aktuellen Bearbeitungssituation (Actual Condition). Fest kodierte Automaten werden in der Kommunikationsplattform vorrangig im OS-Kernel-Bereich genutzt, um die benötigten Ressourcen (OS-Kernelspeicher und Speicherverwaltung des OS-Kernel) zu minimieren. Das folgende C-Quellcode-Beispiel enthält die Strukturdefinition der in der Kommunikations-plattform verwendeten Ausprägung (HCSTM-HardCoded STateMachine) eines fest kodierten Automaten (FIX_STM_T):

93

typedef struct hcstm_v { /*********************************/ /*** Core structure definition ***/ /*********************************/ const struct hcstm_core_v { char *name; int laststate; struct hcstm_state_v { char *name; int state; int lastaction; struct hcstm_action_v { char *name; int event; int destination_ok; int destination_error; int lasthandle; struct hcstm_handle_v { char *name; int (*func)(struct hcstm_v *,void *); } *handle; } *action; } *state; } *core; /*****************************************/ /* Current state record of this instance */ /*****************************************/ /*** Internal event cache ***/ struct hcstm_event_v { int event; void *argmt; struct hcstm_event_v *next; } *cache; struct hcstm_event_v *event; /* Current event */ struct hcstm_state_v *here; /* Current state entry */ unsigned flag; /* Internal flagbuffer */ unsigned tracelevel; char *tracelable; /*** Userdefined data and Error handle ***/ void *arg; int (*error)(struct hcstm_v *, void *); } hcstm_t; typedef const struct hcstm_core_v hcstm_core_t; typedef struct hcstm_state_v hcstm_state_t; typedef struct hcstm_action_v hcstm_action_t; typedef struct hcstm_handle_v hcstm_handle_t; typedef struct hcstm_event_v hcstm_event_t;

94

/************ Macros for core creation ***********************/ #define MAXACTION(X) (sizeof(X)/sizeof(hcstm_action_t)) #define MAXSTATE(X) (sizeof(X)/sizeof(hcstm_state_t)) #define MAXHANDLE(X) (sizeof(X)/sizeof(hcstm_handle_t)) #define LEER_HANDLE (char*)0,(int)0 #define EXEC(X) MAXHANDLE(X),X #define LEER 0,(hcstm_handle_t*)0 /********* User available functions for stm handling *********/ hcstm_t *hcstm_create( hcstm_core_t*, int (*)(hcstm_t*, void*), int , void*); int hcstm_put(hcstm_t *, int, void *); hcstm_t *hcstm_free(hcstm_t *);

95

EXEC( st_idle_ev_start_st_activ)},

In dem folgenden C-Quellcode-Beispiel (USER SPACE) wird die Konstruktion eines Zustands-automaten nach Abbildung 39 in der Variante eines fest kodierten Automaten dargestellt: /*************************************************************//* EXAMPLE_ST_IDLE - HANDLELIST */ /* * st_idle_ev_start_st_activ */ hcstm_handle_t st_idle_ev_start_st_activ[] = { {"example_idle_activ_1_handle", example_idle_activ_1_handle}, {"example_idle_activ_2_handle", example_idle_activ_2_handle} }; /* * st_idle_ev_deactivate_st_down */ hcstm_handle_t st_idle_ev_deactivate_st_down[] = { {"example_idle_down_1_handle", example_idle_down_1_handle}, {"example_idle_down_2_handle", example_idle_down_2_handle} }; /*************************************************************//* EXAMPLE_ST_IDLE - ACTION */ hcstm_action_t st_idle_action[] = { /* st_idle_ev_start_st_activ */ {"EXAMPLE_EV_START", EXAMPLE_EV_START, EXAMPLE_ST_ACTIV, EXAMPLE_ST_ACTIV,

/* st_idle_ev_deactivate_st_down */ {"EXAMPLE_EV_DEACTIVATE", EXAMPLE_EV_DEACTIVATE, EXAMPLE_ST_DOWN, EXAMPLE_ST_DOWN, EXEC( st_idle_ev_deactivate_st_down )} }; /*************************************************************//* EXAMPLE_ST_ACTIV - HANDLELIST */ /* * st_activ_ev_down_st_idle */ hcstm_handle_t st_activ_ev_down_st_activ[] = { {"example_activ_idle_1_handle", example_activ_idle_1_handle}, {"example_activ_idle_2_handle", example_activ_idle_2_handle} }; /* * st_activ_ev_deactivate_st_down */ hcstm_handle_t st_activ_ev_deactivate_st_down[] = { {"example_activ_down_1_handle", example_activ_down_1_handle}, {"example_activ_down_2_handle", example_activ_down_2_handle} }; /*************************************************************//* EXAMPLE_ST_ACTIV - ACTION */ hcstm_action_t st_activ_action[] = { /* st_activ_ev_down_st_idle */ {"EXAMPLE_EV_DOWN", EXAMPLE_EV_DOWN, EXAMPLE_ST_IDLE, EXAMPLE_ST_IDLE, EXEC( st_activ_ev_down_st_idle)}, /* st_activ_ev_deactivate_st_down */ {"EXAMPLE_EV_DEACTIVATE", EXAMPLE_EV_DEACTIVATE, EXAMPLE_ST_DOWN, EXAMPLE_ST_DOWN, EXEC( st_activ_ev_deactivate_st_down )} }; /*************************************************************//* EXAMPLE_ST_DOWN - ACTION */ hcstm_action_t st_down_action[] = { {LEER} };

96

/*************************************************************/

/* STATES */ hcstm_state_t example_states[] = { /* EXAMPLE_ST_IDLE */ { "EXAMPLE_ST_IDLE", EXAMPLE_ST_IDLE, MAXACTION( st_idle_action), st_idle_action}, /* EXAMPLE_ST_ACTIV */ { "EXAMPLE_ST_ACTIV", EXAMPLE_ST_ACTIV, MAXACTION( st_activ_action), st_activ_action}, /* EXAMPLE_ST_DOWN */ { "EXAMPLE_ST_DOWN", EXAMPLE_ST_DOWN, MAXACTION( st_down_action), st_down_action} }; /*************************************************************/hcstm_core_t example_core[] = { /* EXAMPLE_STM */ { "EXAMPLE_STM_LABEL", MAXSTATE( example_states), example_states} }; /*************************************************************/ /* * example_hcstm_create */ hcstm_t *example_hcstm_create() { hcstm_t *example_hcstm; /* stm erzeugen */ if (( example_hcstm = hcstm_create( example_core, example_unexpected_event_handle, EXAMPLE_ST_IDLE, example_usr_arg_ptr)) == NULL) { printf("example_hcstm_create: hcstm_create error!\n"); exit( ERROR); } return( example_hcstm); }

97

Die Verwendung der Managementfunktion des fest kodierten Automaten zur Ereignisübergabe zeigt das folgenden C-Quellcode-Beispiel (USER SPACE):

... if ( hcstm_put( example_hcstm, EXAMPLE_EV_START, ev_start_usr_arg_ptr) == ERROR) { printf("example: hcstm_put error!\n"); exit( ERROR); } ...

98

Automaten.

In Folge der Ereignisübergabe „EXAMPLE_EV_START“ im Zustand „EXAMPLE_ST_IDLE“ werden die Funktionen „example_idle_activ_1_handle“ und „example_idle_active_2_handle“ aufgerufen. Anschließend wird vom Automaten der Zustand „EXAMPLE_ST_ACTIV“ – als Zielzustand – eingenommen. Bricht eine der beiden Funktionen „example_idle_activ_1_handle“ und „example_idle_active_2_handle“ die Bearbeitung mit Fehlermeldung ab, so wird ebenfalls der Zustand „EXAMPLE_ST_ACTIV“ – als Fehlerzustand – eingenommen. Falls sich der Automat „example_hcstm“ bei Abarbeitung des Ereignisses „EXAMPLE_EV_START“ nicht im Zustand „EXAMPLE_ST_IDLE“ befindet, wird die Fehlerbehandlungsfunktion des Automaten „example_unexpected_event_handle“ ausgeführt.

5.3.1.2 Zur Laufzeit kodierte Automaten

Die Zustandsübergangslogik der zur Laufzeit kodierten Automaten ist in Listen hinterlegt. In der Initialisierungsphase der Instanz des zur Laufzeit kodierten Automaten werden die Zustände, die Zustandsübergänge und die Ausführungslisten registriert. Neben der Zustandsübergangslogik benötigt eine Instanz eines zur Laufzeit kodierten Automaten einen Ereignisspeicher (Eventcache), eine Struktur zum Vermerken gelöschter Zustände während der Bearbeitung von Ereignissen und eine weitere Struktur zum Vermerken der aktuellen Bearbeitungssituation (Actual Condition). In der Kommunikationsplattform werden zwei Modi für zur Laufzeit kodierte Automaten verwendet:

• Zur Laufzeit kodierte Automaten ohne Transitionsabbruch Alle Händler, der in einer Transition vermerkten Händlerliste, werden nacheinander ausgeführt. Die Händler haben keine Möglichkeit die Transition abzubrechen. Der Endzustand der Transition wird nach Abarbeitung aller Händler eingenommen.

• Zur Laufzeit kodierte Automaten mit Transitionsabbruch

Alle Händler, der in einer Transition vermerkten Händlerliste, werden im Normalfall nacheinander ausgeführt. Jeder Händler hat die Möglichkeit die Transition abzubrechen. Der Endzustand der Transition wird nur nach normaler Abarbeitung aller Händler eingenommen. Im Falle des Abbruchs durch einen Händler wird ein alternativer Zustand eingenommen.

Zur Laufzeit kodierte veränderliche Automaten Zur Laufzeit können aus diesen Automaten Zustände, inklusive der zugehörigen Transitionen, entfernt bzw. neue Zustände und Transitionen eingefügt werden (Automatenmutation). Die Ausführung des Entfernens von Zuständen wird, um Konsistenzprobleme zu vermeiden, verzögert, (Registrierung gelöschter Zustände) bis alle anstehenden (auch sekundären) Ereignisse abgearbeitet sind. Die folgende Abbildung zeigt den prinzipiellen strukturellen Aufbau eines zur Laufzeit kodierten

IN T S T A T E

C H A R * S T M _ N A M E

S T M _S T A T E _ T

S T M _ S T A N D A R D _T R A N S I T I O N _ L IS T

S T M _ E X T E N D E D _ T R A N S I T I O N _L IS T

C H A R *S T A T E _ N A M E IN T (* E R R O R _ F U N C )( . .. )

S T M _ E X T E N D E D _T R A N S IT IO N _ T

I N T E V E N T

I N T O K _S T A T E

IN T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _ L IS T

C H A R * T R A N S I T IO N _ N A M E

C H A R * E X T_ H A N D LE _ N A M E

IN T ( *S T M _E X T _ H A N D L E ) ( .. . )

S T M _ E X T E N D E T _H A N D LE _ T

S T M _ S T A N D A R D _ T R A N S IT IO N _ T

I N T E V E N T

I N T E N D _ S T A T E

S T M _ S T A N D A R D _H A N D L E _ L IS T

C H A R * T R A N S I T I O N _ N A M E


I N T (*S T M _ H A N D LE ) (. . .)

S T M _H A N D LE _ T

C H A R *E X T _H A N D L E _ N A M E

IN T ( *S T M _ E X T _H A N D LE ) ( .. . )

S T M _ E X T E N D E T _ H A N D L E _ T


I N T ( *S T M _ E X T_ H A N D L E ) ( . .. )

S T M _ E X T E N D E T _ H A N D LE _ T

S T M _E X T E N D E D _ T R A N S IT I O N _T

IN T E V E N T

IN T O K _ S T A T E

IN T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _L IS T

C H A R * T R A N S IT IO N _ N A M E


I N T (*S TM _ E X T_ H A N D L E ) ( . .. )

S T M _ E X T E N D E T _ H A N D L E _T


IN T ( *S T M _E X T _ H A N D L E ) (.. . )


C H A R *E X T _ H A N D L E _N A M E

I N T ( * S TM _ E X T_ H A N D L E )( . .. )

S TM _ E X T E N D E T_ H A N D L E _ T

S T M _ E X T E N D E D _ T R A N S I T I O N _ T

IN T E V E N T


I N T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _ L IS T

C H A R * T R A N S IT I O N _ N A M E


I N T ( * S T M _ E X T _ H A N D L E )( . . .)

S T M _ E X TE N D E T _ H A N D L E _ T

C H A R *E X T_ H A N D L E _ N A M E

I N T ( * S TM _ E X T_ H A N D L E ) ( . .. )

S TM _E X T E N D E T _ H A N D L E _ T


I N T ( *S T M _ E X T _ H A N D LE ) (. . .)

S T M _E X TE N D E T _ H A N D L E _ T

C H A R * H A N D LE _ N A M E

IN T ( *S T M _H A N D LE ) ( .. . )

S T M _ H A N D L E _T


IN T ( *S T M _H A N D LE ) ( . . . )

S T M _ H A N D L E _T

S T M _S T A N D A R D _ T R A N S I T I O N _ T

IN T E V E N T

IN T E N D _ S T A T E

S TM _ S T A N D A R D _ H A N D L E _ L IS T



I N T ( * S TM _ H A N D L E ) ( . .. )

S T M _ H A N D L E _ T


I N T (*S T M _ H A N D L E ) (. . .)

S T M _H A N D L E _ T


I N T ( * S T M _ H A N D L E ) ( . . .)


S T M _ S T A N D A R D _T R A N S I T I O N _ T

IN T E V E N T


S T M _ S TA N D A R D _ H A N D L E _L IS T

C H A R *T R A N S IT IO N _ N A M E


I N T ( *S T M _ H A N D L E ) ( .. . )

S TM _ H A N D L E _ T


I N T ( * S TM _ H A N D L E )( . .. )



I N T (* S TM _ H A N D L E )( . .. )


I N T S T A T E

S T M _ S T A T E _ T

S T M _ S T A N D A R D _ T R A N S IT IO N _L IS T

S T M _ E X T E N D E D _ T R A N S IT IO N _ L I S T

C H A R * S T A T E _ N A M E I N T (* E R R O R _F U N C )( ... )

S T M _E X T E N D E D _ T R A N S I T I O N _T

IN T E V E N T


IN T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _ L IS T


C H A R *E X T _ H A N D L E _N A ME

I N T ( * S TM _ E X T _ H A N D L E ) (. .. )


S T M _ S T A N D A R D _ T R A N S I T I O N _ T

I N T E V E N T


S T M _S T A N D A R D _ H A N D LE _ L IS T



IN T ( *S T M _ H A N D L E )( .. . )





C H A R *E X T _ H A N D L E _ N A M E

I N T ( * S TM _E X T _ H A N D L E ) ( . . .)

S T M _ E X TE N D E T _H A N D L E _ T


IN T E V E N T


I N T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _L IS T



I N T (* S T M _ E X T _H A N D LE ) ( . . .)

S T M _ E X TE N D E T _ H A N D L E _T


I N T ( * S TM _ E X T _ H A N D L E )( . .. )



I N T (*S T M _ E X T _ H A N D LE )( . . .)


S T M _ E X T E N D E D _T R A N S I T IO N _ T

I N T E V E N T

I N T O K _ S T A T E

I N T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _ L I S T


C H A R *E X T _ H A N D LE _ N A M E

IN T (*S T M _ E X T _ H A N D L E ) ( .. . )



I N T ( *S T M _E X T _ H A N D LE ) (. . .)

S T M _E X TE N D E T _ H A N D L E _ T


IN T ( *S T M _ E X T _ H A N D L E )( .. . )



I N T ( * S TM _ H A N D L E ) ( . .. )



I N T ( * S TM _ H A N D L E ) ( . .. )



I N T E V E N T


S T M _ S T A N D A R D _ H A N D L E _ L IS T

C H A R * T R A N S I T IO N _ N A M E


I N T ( *S T M _H A N D LE ) ( . . .)

S T M _ H A N D LE _ T


IN T (*S T M _ H A N D L E )( .. . )



IN T (*S T M _ H A N D LE ) (.. . )


S T M _ S T A N D A R D _ T R A N S IT IO N _T

IN T E V E N T

IN T E N D _S T A T E

S T M _ S T A N D A R D _H A N D L E _L I S T



I N T ( * S T M _ H A N D L E ) ( . . .)



IN T ( *S T M _ H A N D LE ) ( . . .)



IN T ( *S T M _ H A N D LE )( . . .)


I N T S T A T E

S T M _ S T A T E _ T

S T M _ S T A N D A R D _ T R A N S I T I O N _L IS T

S T M _ E X T E N D E D _ T R A N S IT IO N _ L I S T

C H A R * S T A T E _ N A M E I N T ( * E R R O R _ F U N C )( . .. )

S T M _E X T E N D E D _ T R A N S IT I O N _T

IN T E V E N T


IN T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D LE _ L IS T


C H A R *E X T_ H A N D L E _N A M E

I N T ( * S TM _ E X T_ H A N D L E ) (. .. )


S T M _ S T A N D A R D _ T R A N S I T I O N _ T

I N T E V E N T


S T M _ S T A N D A R D _ H A N D LE _ L IS T



IN T ( *S T M _ H A N D L E ) ( .. . )






I N T ( * S TM _ E X T _ H A N D L E ) ( . . .)



IN T E V E N T


I N T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _L IS T



I N T (* S T M _ E X T _H A N D LE ) ( . . .)

S T M _ E X TE N D E T _ H A N D L E _T

C H A R *E X T_ H A N D L E _N A M E

I N T ( * S TM _ E X T_ H A N D L E )( . .. )

S TM _ E X T E N D E T _ H A N D L E _ T


I N T (*S T M _ E X T _ H A N D LE ) ( . . .)


S T M _ E X T E N D E D _T R A N S I T IO N _ T

I N T E V E N T

I N T O K _ S T A T E

I N T E R R _ S T A T E S T M _ E X T E N D E D _ H A N D L E _ L I S T



IN T (*S T M _ E X T _ H A N D LE ) ( .. . )



I N T ( *S T M _ E X T _ H A N D LE ) (. . .)


C H A R * E XT _ H A N D LE _ N A M E

IN T ( *S T M _ E X T _ H A N D L E )( .. . )



I N T ( * S TM _ H A N D L E ) ( . .. )



I N T ( *S T M _ H A N D L E ) ( .. . )

S TM _ H A N D L E _T


I N T E V E N T


S T M _ S T A N D A R D _ H A N D L E _ L IS T



I N T ( *S T M _ H A N D LE ) ( . . .)



IN T (*S T M _ H A N D LE )( .. . )



IN T (*S T M _ H A N D LE ) (. . . )


S T M _ S T A N D A R D _ T R A N S IT IO N _T

IN T E V E N T


S T M _ S T A N D A R D _H A N D L E _L I S T

C H A R * T R A N S I T I O N _N A M E


I N T ( * S TM _ H A N D L E ) ( . .. )



IN T ( *S T M _ H A N D LE ) ( . . .)



I N T ( *S T M _ H A N D LE ) ( . . .)


E V E N T E V E N T E V E N T E V E N T E V E N T E V E N T

Abbildung 41: struktureller Aufbau eines zur Laufzeit kodierten Automaten

Die folgende Tabelle beschreibt die grundsätzlichen Managementfunktionen der zur Laufzeit kodierten Automaten der Kommunikationsplattform:

S T M _ S T A T E _ L I S T

S T M _ T

E V E N T C A C H E

99

Management Basisfunktion Beschreibung

100

*/

zur Laufzeit kodierter Automaten stm_create Erzeugt die Verwaltungsstruktur eines abstrakten Automaten

(Instanz). stm_up Definiert den Startzustand,

Aktiviert den Automaten. stm_down Deaktiviert den Automaten. stm_free Gibt die Verwaltungsstruktur des Automaten frei. stm_ins_state Fügt einen Zustand in einen Automaten ein. stm_del_state Entfernt einen Zustand inklusive zugehöriger Transitionen

(Automatenmutation). stm_ins_action Definiert einen Zustandsübergang ohne Möglichkeit des

Transitionsabbruchs. stm_ins_ext_action Definiert einen Zustandsübergang mit der Möglichkeit des

Transitionsabbruchs. stm_put_event Übergibt dem Automaten ein Ereignis. Falls sich der Automat in

der Abarbeitung einer Transition befindet, wird das Ereignis im „Event cache“ zwischengespeichert.

Tabelle 28: Managementfunktionen der zur Laufzeit kodierten Automaten

Das folgende C-Quellcode-Beispiel enthält die Strukturdefinition der in der Kommunikations-plattform verwendeten Ausprägung (stm) eines zur Laufzeit kodierten Automaten (STM_T): # define TRACE_MODE_ON 1 # define TRACE_MODE_OFF 0 # define STM_STATE_UNDEF -1 typedef enum { STM_MODE_NEW = 1, STM_MODE_LOAD, STM_MODE_RUN, STM_MODE_DOWN, STM_MODE_FREE } stm_mode_t; /* * Interne Steuerflags */ # define STM_WORK_FLAG 0x0001U # define STM_CONSIST 0x0002U # define STM_CTRL_MASK 0x0003U /* * Default Strings

# define STM_NOT_RUNNING "STM: is not running" # define STM_NO_NAME "STM: has no name" # define STM_EMPTY "STM: empty" # define STM_STATE_NO_NAME "STM: actual state has no name" # define STM_STATE_EMPTY "STM: state empty" # define STM_ACTION_NO_NAME "STM: action has no name" # define STM_ACTION_EMPTY "STM: action empty" /* * FEHLER ID's der stm Bibliothek */ typedef enum { STM_ERR_NO, STM_PARAM_ERROR, STM_NOT_ACTIVE, STM_EVENT_WORK_FLAG_OFF, STM_NOT_DEFINED_STATE, STM_FREE_BEFORE_STM_DOWN, STM_FREE_NO_HANDLE_LIST, STM_NOT_IN_RUN_MODE, STM_NO_ACTION_FOUND, STM_NO_PERMIT, STM_UNKNOWN, STM_ERR_UNKNOWN, STM_MAX_ERR_NUM } stm_errno_t; /* Struktur zum mehrfachen Einfuegen von Handlerlisten */ struct handle_list_v{ listelement_t *list; int count; }; /* * Definition von Handlerlisten fuer normale und ext Handlerlisten */ typedef struct handle_list_v handle_list_t; typedef struct handle_list_v ext_handle_list_t; /* Grundverwaltungsstruktur des Automaten */ typedef struct stm_v { stm_mode_t mode; /* Mode des Automaten */ unsigned int ctrl; /* interne Steuerflags */ int trace; /* Tracelevel Automaten*/ /* Zustandsverwaltungsstruktur des Automaten */ struct stm_state_v { int state_nr; void (*error_handle) (struct stm_v *, void *); void *error_usr_arg;

101

char *trace_label; void *usr_arg;

listelement_t *action_list; listelement_t *ext_action_list; } *state; /* Zustand des Automaten*/ listelement_t *del_queue; /* Liste fuer geloeschte States */ listelement_t *event_list; /* Event Eingangspuffer */ listelement_t *state_list; /* Liste aller States */ char *trace_label; /* stm Infostring */ void *usr_arg; /* stm User Argument */ struct stm_actual_cond_v{ /* Aktionsverwaltungsstruktur des Automaten */ struct stm_action_v { int event; struct stm_state_v *new_state; char *trace_label; void *usr_arg; handle_list_t *handle_list; } *action; struct stm_ext_action_v { int event; struct stm_state_v *OK_state; struct stm_state_v *ERR_state; char *trace_label; void *usr_arg; ext_handle_list_t *ext_handle_list; } *ext_action; /* Ereignisdatenstruktur des Automaten */ struct stm_event_v { int id; void *usr_arg; } *event; }*actual; } stm_t; /* Ereignisdatenstruktur des Automaten */ typedef struct stm_event_v stm_event_t; /* Zustandsverwaltungsstruktur des Automaten */ typedef struct stm_state_v stm_state_t; /* Aktionsverwaltungsstruktur des Automaten */ typedef struct stm_action_v stm_action_t; typedef struct stm_ext_action_v stm_ext_action_t; /* Haendlerverwaltungsstruktur des Automaten */ typedef struct stm_handle_v { void (*handle)(stm_t* stm, void* usr_arg); void *handle_usr_arg;

102

char *handle_trace_label; } stm_handle_t;

typedef struct stm_ext_handle_v { int (*ext_handle)(stm_t* stm, void* usr_arg); void *ext_handle_usr_arg; char *ext_handle_trace_label; } stm_ext_handle_t; /* Aktueller Arbeitszustand der Statemaschine */ typedef struct stm_actual_cond_v stm_actual_cond_t;

5.3.2 ASN – Primitiven – Parameterkodierung an externen Schnittstellen

Signalisierungsprimitiven an externen Schnittstellen der Kommunikationsplattform bestehen generell aus zwei logischen Informationseinheiten mit unterschiedlichen Darstellungsprinzipien (Primitivenkopf und Primitivenparameter). Der Kopf der Signalisierungsprimitive ist in feste Strukturen gegliedert. Der Aufbau der Struktur ist in seiner konkreten Form von der Ausprägung der jeweiligen Schnittstelle abhängig (z.B. Kanalreferenz und Typ der VL-Primitive des Koppelprotokolls – siehe 4.7.2.3.3). Der Vorrat an Primitiven und deren struktureller Aufbau (Kopf) ist mit der Definition der externen Schnittstelle abgeschlossen. Im Unterschied zur ASN.1 Kodierung / ILC-Verfahren (Identifier, Length, Content) (siehe [19]) wird zur Parameterdarstellung (z.B. der VL-Primitiven des Kopplungsprotokolls zwischen der Kommunikationsplattform und dem signaltechnisch sicheren Rechner – siehe 3.3.2.2) eine an den spezifischen Bedarf (eingeschränkte Möglichkeiten der signaltechnisch sicheren Ablaufumgebung und Programmierrichtlinien [Mü 8004]) orientierte, anwendungsspezifische ASN-Kodierung von hierarchisch organisierten Parameterlisten verwendet. Die ASN-Kodierung unterstützt die universelle und konkrete Repräsentation von Datenobjekten, deren Syntax abstrakt beschrieben wird. Sie ermöglicht, unabhängig von Rechnerarchitektur und Programmiersprache, den Austausch von Applikationsdatenstrukturen über Netzwerke. Jede ASN-kodierte Information der Kommunikationsplattform ist durch eine systemweit eindeutige Kennung (TAG) identifizierbar. Der dieser Kennung folgendende Längenindikator weist auf das Ende des eigentlichen Informationsfeldes. Diesem können weitere TAGs folgen, die wiederum selbst eine Kette von ASN-kodierten Informationen enthalten können (Möglichkeit der Kodierung hierarchisch strukturierter Informationen).

ASN_PARAMHead

KANAL_REF TYP TAG LEN VALUETAG LEN VALUE TAG LEN VALUE

prinzipieller Aufbau einer Signalisierungsprimitive mit ASN-kodierten Parametern

Abbildung 42: Signalisierungsprimitive mit ASN-kodierten Parametern

Im Schichtenmodell ermöglicht dieses Verfahren eine transparente Übertragung von Protokollinformationen, deren Inhalt und Bedeutung nur dem Absender und dem passenden Empfänger bekannt sein müssen. Gleichzeitig können „fremde“ Schichten eigene Informationen

103

ergänzen bzw. entfernen, ohne die Bedeutung und den inneren Aufbau aller übertragenen TAGs kennen zu müssen. Auf Grund der transparenten Übertragung von Protokollinformationen an den Schnittstellen ist es möglich, Systemkomponenten schrittweise auf neuere Releasestände umzurüsten, falls Abwärts-kompatibilität benötigt wird. Die folgende Tabelle beschreibt die grundsätzlichen ASN-Managementfunktionen: ASN Management Basisfunktion

Beschreibung

TAG lesen Entsprechend dem angegebenen TAG wird eine in der ASN-kodierten Struktur enthaltene Informationseinheit gelesen.

TAG schreiben Eine Informationseinheit wird unter dem angegebenen TAG in der ASN-kodierten Struktur gespeichert.

TAG entfernen Entsprechend dem angegebenen TAG wird eine in der ASN-kodierten Struktur enthaltene Informationseinheit gelöscht.

Tabelle 29: ASN-Managementfunktionen

Jede ASN Management Basisfunktion zeigt der aufrufenden Instanz ihre korrekte Ausführung an. Dadurch ist die Verwaltung mehrerer gleicher ASN-TAGs in einer ASN-kodierten Struktur möglich („TAG entfernen“ entfernt - wenn vorhanden - immer nur eine dem ASN-TAG entsprechende Informationseinheit ). Die folgende Abbildung zeigt beispielhaft die Traceausgabe (Nachricht bestehend aus zwei USER-STREAM-Nachrichtenblöcken – siehe Abbildung 46) einer vom signaltechnisch sichern Rechner an die Kommunikationsplattform übergebenen VL_CON_REQ-VL_CON_IND – PDU bestehend aus Primitivenkopf (siehe 4.7.2.3.1) und Primitivenparameter:

===================================================== #0000 FF 01 00 .. .. .. .. .. .. .. .. .. .. .. .. .. ----------------------------------------------------- #0000 02 00 00 13 02 07 00 04 01 01 01 01 02 06 00 02 #0010 11 01 02 09 00 01 01 02 01 00 08 02 07 00 04 01 #0020 01 02 00 02 02 00 01 11 02 03 00 20 00 01 02 03 #0030 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 #0040 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F .. .. .. .. =====================================================

Abbildung 43: Trace einer VL_CON_REQ-VL_CON_IND – PDU

Die logische Struktur der Traceausgaben aus Abbildung 43 ist in folgender Tabelle dargestellt:

104

105

PDU aus Abbildung 43 und der ASN-Kennung ASN_TAG_VL_CALLED ADDR liefert die ASN-kodierte Adressinformation des gerufenen Kommunikationspartners. Wird auf die ASN-kodierten

PDU-Information Bedeutung 0xFF VL - Präambel - Feld ( 0xFF-Signalisierungsinformation). 0x01 Nummer des virtuellen Kanals

Primitiven- kopf

0x00 Kodierung VL-Primitiventyp (VL_CON_REQ) 0x02 0x00 ASN-Kennung ASN_TAG_VL_CALLED ADDR 0x00 0x13 Länge der ASN-kodierten Adressinformation des

gerufenen Kommunikationspartners (19 Oktetts)

0x02 0x07 ASN-Kennung ASN_STAG_ETCS_ADDR 0x00 0x04 Länge der ETCS-Adresse des gerufenen

Kommunikationspartners (4 Oktetts)

0x01 0x01 0x01 0x01 ETCS-Adresse des gerufenen Kommunikationspartners

0x02 0x06 ASN-Kennung ASN_STAG_GSM_NR 0x00 0x02 Länge der GSM/R Telefonnummer des gerufenen

Kommunikationspartners (2 Oktetts bzw. 4 Halbbytes)

0x11 0x01 GSM/R Telefonnummer: 1101 (Testrufnummer)

0x02 0x09 ASN-Kennung ASN_STAG_N_QOS

0x00 0x01 Länge des netzbezogenen Quality of Service Class Deskriptors (N_QOS)

0x01 Deskriptor 1 (entspricht 4800 bit/s)

0x02 0x01 ASN-Kennung ASN_TAG_VL_CALLING ADDR

0x00 0x08 Länge der ASN-kodierten Adressinformation des rufenden Kommunikationspartners (8 Oktetts)

0x02 0x07 ASN-Kennung ASN_STAG_ETCS_ADDR

0x00 0x04 Länge der ETCS-Adresse des rufenden Kommunikationspartners (4 Oktetts)

0x01 0x01 0x02 0x00 ETCS-Adresse des rufenden Kommunikationspartners

0x02 0x02 ASN-Kennung ASN_TAG_VL_SERVICE

0x00 0x01 Länge des ASN-kodierten Serviceinformation / Applikationsidentifikation (1 Oktetts)

0x11 Applikationsidentifikation FFB-System

0x02 0x03 ASN-Kennung ASN_TAG_VL_USR_ARG

0x00 0x20 Länge der Nutzerinformation (der Sicherungsschicht) der VL_CON_REQ-PDU (32 Oktetts)

Primitiven-parameter

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F

Testpattern zur Simulation der AU1-Information der Sicherungsschicht (siehe Abbildung 7)

Tabelle 30: logische Struktur einer VL_CON_REQ-VL_CON_IND – PDU

Die ASN-Managementfunktion „TAG lesen“ angewendet auf die VL_CON_REQ-VL_CON_IND –

Adressinformation des gerufenen Kommunikationspartners in einem weiteren Schritt die ASN-

106

die einzelnen Konverter abwärts gereicht und durch den Port an das externe (Pseudo-) Gerät

Managementfunktion „TAG lesen“ mit der ASN-Kennung ASN_STAG_ETCS_ADDR ange-wendet, so wird die ETCS-Adresse des gerufenen Kommunikationspartners ermittelt.

5.3.3 USER-STREAM

STREAMS wurde von D. Rietchie 1983 als Mechanismus zur Verbindung zwischen einem Nutzerprozess und einem STREAMS-Treiber vorgestellt. Dieser Mechanismus basiert auf einer Vollduplex-Verbindung (dem „Datenstrom“) und mehreren „Verarbeitungseinheiten“, die sequentiell zur Verkörperung bestimmter Funktionalitäten in konfigurierbarer Reihenfolge und Anzahl angeordnet werden können. STREAMS besteht i.a. aus einer Reihe von Systemaufrufen, Systemkern-Betriebsmitteln und Systemkern-Routinen (siehe [6] Kap.17 und [9] Kap.10.5.4). Der in der Kommunikationsplattform verwendete USER-STREAM Mechanismus erlaubt es, den STREAMS-Ansatz auch im Nutzerbereich (Kommunikationstask) oberhalb der POSIX-API zu realisieren. Dadurch ist es möglich, die in der Kommunikationsplattform realisierte USER-STREAM-Ablaufumgebung auch auf POSIX-konformen Systemen ohne STREAMS-Unterstützung (z.B. LINUX – siehe [5], [12]) zu nutzen. USER-STREAMS:

• verwendet für STREAMS definierte Mechanismen, • definiert einheitliche Schnittstellen für die Aus- und Eingabe, • ermöglicht eine modulare, portable Entwicklung sowie eine einfache Integration von

Diensten, • liefert eine flexible, portable und wiederverwendbare Menge von Werkzeugen für die

Entwicklung von Kommunikationsdiensten, • erlaubt die einfache Erzeugung von Modulen, die Standarddienste anbieten, • ermöglicht die dynamische Einbindung von Modulen durch einen Nutzerprozess, • bietet flexible Konfigurationsmöglichkeiten für einen Datenstrom, • ermöglicht einem Nutzerprozess das Senden und Empfangen von USER-STREAMS-

Nachrichten (us_messages), • erlaubt das Puffern von Nachrichten in den Warteschlangen.

Datenstrom: Ein Datenstrom (US-Channel) ist ein bidirektional arbeitender Pfad für die Übertragung und Verarbeitung von Daten zwischen einem USER-STREAMS-Treiber und einem Nutzerprozess. Ein Datenstrom repräsentiert i.a. die Verknüpfung eines Datenstromkopfes, eines Treibers sowie kein, ein oder mehrere Module. Ein Datenstrom wird durch Öffnen eines USER-STREAMS-Ports und Einfügen von Konvertern erzeugt und durch Schließen des Datenstromkopfes abgebrochen. Der Datenstromkopf ist dabei dem Nutzerprozess am nächsten. Er verarbeitet alle Nutzerprozess-Aufrufe für den Datenstrom. Der USER-STREAMS-Port adaptiert ein Geräte- oder ein Software-Treiber (Pseudo-Gerätetreiber). Ein USER-STREAMS-Konverter repräsentiert Funktionen, die es erlauben, die Daten im Datenstrom zu bearbeiten. Ein Konverter kommuniziert mit seinen Nachbarn durch Übergabe von Nachrichten. In Schreibrichtung (stromabwärts) werden die Nachrichten ausgehend vom Datenstromkopf durch

ausgegeben. In der stromaufwärts gerichteten Leserichtung werden Nachrichten vom Gerätetreiber (adaptiert über den Port) durch die Konverter zum Nutzerprozess transportiert. Die Kommunikationsapplikation kann Nachrichten in den Datenstrom schreiben. Für den Empfang einer Nachricht ist durch die Kommunikationsapplikation eine Funktion bereitzustellen, die zum Empfangszeitpunkt ausgeführt wird. Der Ablaufcode von Modulen (Konverter/ Multiplexer und Ports) wird in entsprechenden Pools (Konverterpool, Portpool, Muxpool) verwaltet. Die Initialisierungsstruktur eines Moduls (Port, Konverter, Multiplexer) muss zur Benutzung durch USER-STREAMS in einem Modul-Pool hinterlegt werden. Dafür ist eine Modul-Kennung anzugeben. Beim Einfügen eines Moduls in einen Datenstrom muss ein Konfigurationsstring angegeben werden, der mindestens die Modul-Kennung enthalten muss. Über die Kennung wird das Modul im Pool selektiert. USER-STREAM Port: Der Port bildet aus Sicht der Kommunikationsapplikation das Ende des Datenstromes. Er kann ein Geräte- oder ein Software-Treiber (Pseudo-Gerätetreiber) adaptieren. Er bearbeitet die Daten nicht bzw. nur insofern, dass die USER-STREAM-Datenstrukturen an die Datenstrukturen angepasst werden, die das Gerät versteht. Datenstromkopf: Der Datenstromkopf bildet die Schnittstelle des instanziierten USER-STREAM-Protokollstacks zur Kommunikationsapplikation. Er beinhaltet einen Zeiger auf die Handlerfunktion der Kommunikationsapplikation, die bei empfangenen Nachrichten durch die interne put-Prozedur der Lesewarteschlange aufgerufen wird. Ein Zeiger auf Argumente der Kommunikationsapplikation kann beim Einrichten des Datenstromes im Datenstromkopf hinterlegt werden. USER-STREAM Konverter: Ein USER-STREAM-Konverter repräsentiert Funktionen, die es erlauben, die Daten im Datenstrom zu bearbeiten. Ein Konverter kommuniziert mit seinen Nachbarn durch Übergabe von Nachrichten. In einem Datenstrom können keine oder beliebig viele Module vorhanden sein. Ein Konverter wird mit push geöffnet, initialisiert und unterhalb des Datenstromkopfes in den Datenstrom eingefügt. Beim Abbau eines Datenstromes (close) werden seine Module geschlossen und die entsprechenden Datenstrukturen freigegeben. Jeder USER-STREAMS-Konverter besteht aus zwei Warteschlangen (Queues); jeweils eine in die Schreib- (stromabwärts) und Lese-Richtung (stromaufwärts). Beide Warteschlangen arbeiten unab-hängig voneinander. Sie besitzen generell unabhängige Verarbeitungsprozeduren und -daten. Jede Warteschlange kann direkt auf die benachbarte Warteschlange in Richtung des Datenflusses, sowie innerhalb des Moduls auf ihr Pendant zugreifen. In USER-STREAMS können Nachrichten in den Warteschlangen eines Konverters gepuffert werden (putq). USER-STREAM Multiplexer: Multiplexer stellen eine spezielle Form eines Ports (Treibers) dar. Ein Multiplexer ist in der Lage, Daten von n höheren Datenströmen an m tieferliegende Datenströme weiterzuleiten (und umge-kehrt).

107

In einem Datenstrom können keine oder beliebig viele Multiplexer vorhanden sein. Der obere Teil des Multiplexers verhält sich wie das Ende eines Datenstromes; der untere Teil wie der Kopf eines Datenstromes.

5.3.3.1 USER-STREAM Channel API

Die USER-STREAM-Channel-API erleichtert dem Anwender die Initialisierung und Zusammen-stellung eines Kommunikations-Channels (Datenstrom). Diese Funktionalität setzt auf den Basis-SVR4-Stream-Managementfunktionen auf. Durch funktionale Kapselung der normalen USER-Stream-Managementfunktionen wird die Instanziierung von Komplexen US-Channel Konfigurationen vereinfacht. Die zu instanziierenden Kommunikationsstacks sind über hierarchisch organisierte Konfigurationsfiles definiert. Zur Beschreibung von Kommunikations-Channels dienen Profiles, deren prinzipieller Aufbau im folgenden erläutert wird. Ein Profile besteht aus einem eindeutigen Bezeichner (PROFILEKENNUNG). Diese Profileken-nung wird durch ein eindeutiges Schlüsselwort (US_PROFILE) identifiziert. Anschließend folgen 0 bis n Konverterkonfigurationsdateien, welche durch das Schlüsselwort KONVERTER gekennzeichnet werden. Die Reihenfolge (Oberhalb- / Unterhalb – Relation) der Konverter werden im USER-Stream nachgebildet. Der letzte Eintrag im Profile ist eine Portkonfigurationsdatei (Verweis auf Port- oder Muliplexerzugang). Die folgende Abbildung stellt eine schematische Konfiguration eines US-Channels mit einem Port und 0...n Konvertern dar:

US_PORT

US_KONV

US_HEAD

0 ... n

US_PORT

US_KONV

US_HEAD

0 ... n

US_PORT

US_KONV

US_HEAD

0 ... n

Port PoolPort PoolPort PoolPort Pool

Port Pool List

Konv Pool

Konv Pool List

Konv PoolKonv Pool

Konv Pool

Abbildung 44: einfache US-Channel Konfiguration

Die folgende Abbildung stellt eine schematische Konfiguration eines US-Channels mit 0...n Konvertern, einem Multiplexer und mehreren hinzugelinkten US-Channels dar:

108

US_PORT

US_KONV

US_HEAD

0 ... n

US_PORT

US_KONV

US_HEAD

0 ... n

Port PoolPort PoolPort PoolMUX Pool

MUX Pool List

Konv Pool

Konv Pool List

Konv PoolKonv Pool

Konv Pool

US_MUX

US_KONV

US_HEAD

0 ... n

US_PORT

US_KONV

US_HEAD

0 ... n

US_PORT

US_KONV

US_HEAD

0 ... n

US_PORT

US_KONV

US_HEAD

0 ... n

Port PoolPort PoolPort PoolPort Pool

Port Pool List

Konv Pool

Konv Pool List

Konv PoolKonv PoolKonv Pool

Abbildung 45: US-Channel Konfiguration mit Multiplexer

5.3.3.2 Managementfunktionen

Die folgende Tabelle beschreibt die Basis-USER-STREAM-Managementfunktionen der Kom-munikationsapplikation:

109

Basis-USER-STREAM- Beschreibung Managementfunktion us_up Konstruktor der USER-STREAM Bibliothek – ruft die

Konstruktoren der Konverter, Multiplexer und Ports auf. Ohne mindestens einmaligen Aufruf des Konstruktor ist die USER-STREAM Bibliothek nicht aktiviert.

us_down Destruktor der USER-STREAM Bibliothek – ruft die Destruktoren der übergebenen Konverter und Ports auf. Anschließend werden die Datenstrukturen der USER-STREAM Bibliothek freigegeben.

us_open Generiert und öffnet den Kommunikationsport entsprechend übergebener Konfiguration. Der Aufruf von us_open schlägt dann fehl, wenn die USER-STREAM Bibliothek nicht aktiviert wurde

us_close Schließt den Kommunikationsport und evtl. im Stack vorhandene Konverter und gibt die mit us_open generierte Datenstrukturen frei. Der Aufruf von us_close schlägt dann fehl, wenn die USER-STREAM Bibliothek nicht aktiviert wurde

us_push Öffnet und initialisiert einen Konverter entsprechend übergebener Konfiguration und fügt diesen in die vorher erzeugte (durch us_open) USER-STREAM-Instanz ein. Der Aufruf von us_push schlägt dann fehl, wenn die USER-STREAM Bibliothek nicht aktiviert wurde

us_put Schreibt eine Message in die angegebenen USER-STREAM-Instanz. Der Aufruf von us_put schlägt dann fehl, wenn die USER-STREAM Bibliothek nicht aktiviert wurde

Tabelle 31: Basis-SVR4-Stream-Managementfunktionen

Die folgende Tabelle beschreibt die USER-STREAM-Message bezogenen Managementfunktionen: USER-STREAM-Message bezogenen Managementfunktion

Beschreibung

adjmsg Richtet die Bytes am Kopf oder am Ende der angegebenen Nachricht aus.

alloc_b Erzeugt einen Nachrichtenblock des Typs M_DATA, in dem der Datenpuffer mindestens die geforderte Anzahl Bytes enthält.

copyb Kopiert den Inhalt eines Nachrichtenblocks in einen neu erzeugten.copymsg Die Funktion verwendet copyb(), um die Nachrichtenblöcke einer

Nachricht in neu erzeugte Nachrichtenblöcke zu kopieren. Anschließend verkettet sie die neuen Nachrichtenblöcke, um eine neue Nachricht zu bilden.

110

USER-STREAM-Message Beschreibung bezogenen Managementfunktion adjmsg Richtet die Bytes am Kopf oder am Ende der angegebenen

Nachricht aus. alloc_b Erzeugt einen Nachrichtenblock des Typs M_DATA, in dem der

Datenpuffer mindestens die geforderte Anzahl Bytes enthält. copyb Kopiert den Inhalt eines Nachrichtenblocks in einen neu erzeugten.copymsg Die Funktion verwendet copyb(), um die Nachrichtenblöcke einer


dupb Die Funktion dupliziert den Nachrichtenblock-Deskriptor, indem dieser in einen neu erzeugten Nachrichtenblock-Deskriptor kopiert wird. Der neue Nachrichtenblock wird derart gebildet, dass der neue Nachrichtenblock-Deskriptor auf den selben Datenblock zeigt, wie der ursprüngliche Deskriptor. Der Verweiszähler im Datenblock-Deskriptor ( dblk_t) wird um den Wert 1 erhöht. dupb() kopiert nicht den Datenpuffer, nur der Nachrichtenblock-Deskriptor wird kopiert.

dumpmsg Die Funktion ruft dupb() auf, um die Nachricht zu duplizieren, indem sie alle einzelnen Nachrichtenblock-Deskriptoren kopiert, um dann die neue Nachricht zu bilden. dupmsg() kopiert keinen Datenpuffer, nur Nachrichtenblock-Deskriptoren werden kopiert.

freeb Die Funktion gibt den Nachrichtenblock-Deskriptor frei, und ebenso den entsprechenden Datenblock, wenn der Verweiszähler im Datenblock-Deskriptor gleich 1 ist. Wenn der Verweiszähler größer als 1 ist, dann gibt freeb() den Datenblock nicht frei, sondern vermindert deren Verweiszähler um 1.

freemsg Die Funktion verwendet freeb(), um alle Nachrichtenblöcke samt den zugehörigen Datenblöcken für die Nachricht freizugeben.

linkb Die Funktion fügt den Inhalt einer gegebenen Nachricht an eine andere gegebene Nachricht an.

msgdsize Die Funktion liefert die Anzahl der Datenbytes in der Nachricht. Nur Bytes in den Datenblöcken des Typs M_DATA werden in dieser Summe mitgezählt.

rmvb Die Funktion entfernt einen gegebenen Nachrichtenblock aus der Nachricht und stellt dann die Verkettung der in der Nachricht verbleibenden Nachrichtenblöcke wieder her. rmvb() gibt den entfernten Nachrichtenblock nicht frei.

unlinkb Die Funktion entfernt den ersten Nachrichtenblock und liefert einen Zeiger auf den Anfang der restlichen Nachricht.

111

USER-STREAM-Message Beschreibung

112

USER-Stream-Ablaufumgebung der Kommunikationsplattform:

bezogenen Managementfunktion adjmsg Richtet die Bytes am Kopf oder am Ende der angegebenen

Nachricht aus. alloc_b Erzeugt einen Nachrichtenblock des Typs M_DATA, in dem der

Datenpuffer mindestens die geforderte Anzahl Bytes enthält. copyb Kopiert den Inhalt eines Nachrichtenblocks in einen neu erzeugten.copymsg Die Funktion verwendet copyb(), um die Nachrichtenblöcke einer


linmsg Die Funktion erstellt einen neuen Nachrichtenblock ohne angehangene Nachrichtenblöcke aus der übergebenen Nachricht, die ( evtl.) aus mehreren Nachrichtenblöcken besteht.

Tabelle 32: USER-STREAM-Message bezogene Managementfunktionen

Die folgende Tabelle beschreibt die USER-STREAM-Messagequeue bezogenen Management-funktionen: USER-STREAM-Messagequeue bezogenen Managementfunktion

Beschreibung

alloc_queue Die Funktion alloziiert und initialisiert eine Messagequeue. free_queue Die Funktion gibt eine Messagequeue frei. canput Die Funktion überprüft die Möglichkeit des Schreibens auf eine

Messagequeue. enableok Die Warteschlangen-Steuerung einer Messagequeue wieder

erlauben. flushq Die Nachrichten einer Warteschlange löschen. getq Die Funktion holt die erste Nachricht aus einer Messagequeue. insq Die Funktion fügt eine Nachricht ab einer bestimmten Position in

die Warteschlange ein. noenable Die Warteschlangensteuerung einer Messagequeue wird

suspendiert. putbq Die Funktion fügt eine Nachricht an den Anfang einer

Warteschlange ein. putq Die Funktion fügt eine Nachricht an das Ende einer Warteschlange

ein. qenable Die Warteschlangensteuerung einer Messagequeue wird aktiviert. rmvq Die Funktion entfernt eine Nachricht aus einer Warteschlange.

Tabelle 33: USER-STREAM-Messagequeue bezogene Managementfunktionen

Die folgende Tabelle beschreibt die Managementfunktionen der US-Channel-Erweiterungen der

US-Channel- Beschreibung Managementfunktion us_create_channel Öffnet und initialisiert einen USER-Streamstack mit Multiplexern,

Port und Konvertern. Die Beschreibung des Stacks mit Channel Namen, Konvertern und Ports / Multiplexerzugängen befindet sich im Profile.Der angegebene Ereignishandler wird aufgerufen, wenn eine Message am Datenstromkopf empfangen worden ist.

us_destroy_channel Schließt und deinitialisiert einen USER-STREAM-Stack mit seinem Port und Konvertern. Der alloziierte Speicher wird freigegeben.

us_make_profile Generieren eines Profiles (interne Stackbeschreibungsstruktur) aus den hierarchisch organisierten Konfigurationsfiles.

us_free_profile Der alloziierte Speicher des USER-Stream Profile wird freigegeben.

Tabelle 34: US - Channel - Managementfunktionen

5.3.3.3 Nachrichtenaufbau

Der Aufbau einer Nachricht der USER-STREAM-Ablaufumgebung entspricht dem STREAMS-Modell. Alle Nachrichten in USER-STREAMS verwenden die folgenden zwei Datenstrukturen:

• Nachrichtenblock msgb • Datenblock datab

Ein Datenblock ist der (Nutzdaten-) Teil einer Nachricht. Ein Datenblock wird durch (mindestens) einen Nachrichtenblock referenziert. Nachrichtenblöcke können verkettet werden und dadurch eine aus mehreren Teilen bestehende Nachricht bilden. Zu einer Nachricht gehört mindestens ein Nachrichtenblock. Der Nachrichtenblock verwaltet das Lesen und Beschreiben des zugeordneten Datenpuffer-Blocks. Eine Nachricht kann aus mehreren Nachrichtenblöcken bestehen, wenn die Puffergröße begrenzt ist oder wenn die Nachricht im Ergebnis der Bearbeitung erweitert wird. Jedem Nachrichtenblock ist ein Datenblock zugeordnet. Ein Datenblock enthält:

• die Art des Nachrichtenblocks, • die Grenzen des Datenpuffer-Blocks und • eine Variable (Referenzenzähler) mit der Anzahl der Nachrichtenblöcke, die auf den

Datenblock verweisen. Der dem ersten Nachrichtenblock zugeordnete Datenblock bestimmt die Art der gesamten Nachricht. Mehrere Nachrichtenblöcke können auf den selben Datenblock zeigen, um Speicher zu sparen, bzw. ein unnötiges Kopieren zu vermeiden. Die folgende Abbildung zeigt den prinzipiellen Aufbau einer STREAMS – Nachricht.

113

Datenpuffer

Nachrichtenblock

Datenblock

Verw eis auf erstes Byte des

Verw eis auf letztes Byte des Puffers + 1

Referenzen-Zähler

Art des Nachrichtenblocks

Nachrichtenblock

Verw eis auf nächsten

Verw eis auf erstes nicht gelesenes

Verw eis auf erstes nicht geschriebenes Byte

Verw eis auf zugehörigen Datenblock

Nachrichtenpriorität

Abbildung 46: Struktur einer USER-STREAM Nachricht

Folgende Nachrichtentypen sind in der Kommunikationsplattform definiert:

• M_DATA – regular data • M_PROTO – protocol control • M_CTL – device specific control message • M_BREAK – line break • M_DELAY – delay • M_IOCTL – ioctl set/get params • M_IOCACK – acknowledge ioctl • M_IOCNAK – negative ioctl acknowledge • M_PCPROTO – priority proto message • M_STOP – stop transmission immediately • M_START – restart transmission after stop • M_HANGUP – line disconnect • M_ERROR – fatal error • M_PCCTL – priority control message

Die internen Diensteschnittstellen der Kommunikationsplattform verwenden folgenden grundsätzlichen Primitivenaufbau basierend auf M_PROTO bzw. M_CTL - Nachrichten:

114

• Transferinterface (TR)

M_PROTO TR-Head

CALL_REFTYP MODE

Abbildung 47: Primitivenaufbau des Transferinterfaces

Strukturelement Bedeutung TYP Type der TR-IF – Primitive. MODE Betriebsmodus der TR-IF – Primitive (bei ATTACH)

• SIGN (Listener) • RESP (Ruf annehmen) • INVO (Ruf absetzen).

CALL_REF Eindeutige Referenz zur Rufannahme.

Tabelle 35: Elemente der M_PROTO-Primitive des Transferinterfaces

Der Vermittlungskern (Transferkern) kommuniziert mit unterlagerten Kommunikationsstacks ausschließlich über das Transferinterface.

• Virtuelles Linkinterface (VL)

M_PROTO VL-Head

KANAL_REF TYP

M_CTL VL-Head

TYP

Abbildung 48: Primitivenaufbau des Virtuellen Linkinterfaces

Strukturelement Bedeutung TYP Type der VL-IF – (M_PROTO/M_CTL) – Primitive.KANAL_REF Eindeutige Referenz auf einen virtuellen Kanal.

Tabelle 36: Elemente der M_PROTO-Primitive des Virtuellen Linkinterfaces

Das virtuelle Linkinterface (VL) wird als Zugang zu den Linkbündeln (Kanalbündel) von Koppelstacks verwendet.

115

• Linkinterface (LK)

M_CTL LK-Head

TYP

Abbildung 49: Primitivenaufbau des Linkinterfaces

Strukturelement Bedeutung TYP Type der LK-IF – Primitive.

Tabelle 37: Elemente der M_CTL-Primitive des Linkinterfaces

Die Linkbündel von Koppelstacks setzen über das Linkinterface (LK) auf die unterlagerten Provider auf. Die Strukturierung der variablen Parameter, der in den internen Diensteschnittstellen auf M_PROTO-Nachrichten basierenden Primitiven, unterscheidet eine interne und eine externe Darstellung:

• Parameterstrukturierung ASCII (intern) Die Parameter werden als M_DATA – Nachricht mit dem M_PROTO – Primitivenkopf verkettet. Die Parameter sind als ASCII-Daten kodiert und entsprechen der Datendarstellung in den Konfigurationsdateien der Kommunikationsplattform.

• Parameterstrukturierung ASN (extern)

Die Parameter werden als M_DATA – Nachricht mit dem M_PROTO – Primitivenkopf verkettet. Die Parameter selbst sind ASN – kodiert (siehe 5.3.2).

5.3.3.4 Anwendungsbeispiel

Bei Tests im Rahmen der Entwicklung der Kommunikationsplattform (siehe 6.1.1.1) werden u.a. die untersten Protokollschichten (aHDLC und T.70) des EURORADIO-Protokollstacks über einem CAPI-Interface zur Ansteuerung der S2M-Schnittstelle (ISDN-GSM/R Anschluss der FFB-Zentrale – siehe Abbildung 14) entsprechend folgender Abbildung betrieben:

116

CAPI-Port

Konfigurationsdateien

aHDLC-Modul

TI_L2_ER-STACK

T.70-Modul

US-Profile

T.70-Modul

Konfiguration

aHDLC-ModulKonfiguration

CAPI-PortKonfiguration

T.70-ModulInstanz

aHDLC-ModulInstanz

CAPI-PortInstanz

TI_L2_ER-Stack

Kommunikationstask

Filesystem

Testapplikation

117

Abbildung 50: Testkonfiguration zweier Protokollschichten des EURORADIO-Protokollstacks

In der folgenden Beispielkonfiguration sind die Dateiverweise (relative Pfadangaben) der zu ladenden USER-STREAM-Module (T.70 over aHDLC) und, unter dem Schlüsselwort „PORT“, des zu nutzenden USER-STREAM-Ports angegeben. Der Name des USER-STREAM-Profiles ist mit dem Schlüsselwort "US_PROFILE" gekennzeichnet. # ti_l2_er_stack.conf US_PROFILE: TI_L2_STACK KONVERTER: ./konv/tr/t70/default.conf KONVERTER: ./konv/tr/hdlc/default.conf PORT: ./port/tr/capi/port/euroradio/standard/etsi/4800_8N1.port In den folgenden Beispielkonfigurationen sind die Parameter der zu testenden Protokollschichten (T.70 over aHDLC) enthalten: # ./konv/tr/t70/default.conf KONV_TYPE: US_T70 T70_SIZE: 25 T70_MORE: 0x8001 T70_LAST: 0x0001 T70_IFTYPE: TR-IF # ./konv/tr/hdlc/default.conf

KONV_TYPE: US_HDLC HDLC_IFTYPE: TR-IF HDLC.RETRIES: 10 HDLC.WINDOW: 8 HDLC.USESREJ: Y HDLC.T1: 1000 HDLC.T3: 30000 HDLC.INTRACE: 0x00 # 0x00 Tracemeldungen aus # 0x01 Ausnahmebehandlungen ein # 0x02 STM-Trace der Link-Stm ein # 0x04 STM-Trace der Sender-Stm ein # 0x08 STM-Trace der Empfaenger-Stm ein # 0x10 FRAME-Trace ein # 0x20 Ablauf-Trace ein # 0x40 "unsolicated DM" ein HDLC.TRACELEVEL: 0 # 00 TR-IF-Trace aus # 01 TR-IF-STM-Trace ein # 02 TR-IF-STM+TR-IF-FLOW-Trace ein

118

„test_appl_us_rcv“ bei einlaufenden Nachrichten am USER_STREAM-Head zur Übergabe an die Testapplikation durch die USER-STREAM-Ablaufumgebung aktiviert :

Wesentliche Parameter zur Konfiguration des CAPI-Ports zur Ansteuerung der S2M-Schnittstelle über ein CAPI-Interface sind in der folgenden Beispielkonfiguration dargestellt: # ./port/tr/capi/port/euroradio/standard/etsi/4800_8N1.port PORT_TYPE: TR_CAPI TR_CAPI_CIP_VALUE: 0x0002 TR_CAPI_BC_SOKTETT3: 0x88 TR_CAPI_BC_SOKTETT3_MASK: 0xff TR_CAPI_BC_SOKTETT4: 0x10_70_90 TR_CAPI_BC_SOKTETT4_MASK: 0x7f_7f_ff TR_CAPI_BC_SOKTETT5: 0x21_45_20_3b_ff TR_CAPI_BC_SOKTETT5_MASK: 0xff_7f_7f_7f_c0 TR_CAPI_LLC_SOKTETT3: 0x08_80 TR_CAPI_LLC_SOKTETT3_MASK: 0x7f_ff TR_CAPI_LLC_SOKTETT4: 0x10_70_90 TR_CAPI_LLC_SOKTETT4_MASK: 0x7f_7f_ff TR_CAPI_LLC_SOKTETT5: 0x21_45_20_3b_ff TR_CAPI_LLC_SOKTETT5_MASK: 0xff_7f_7f_7f_c0 ... In dem folgenden C-Quellcode-Beispiel (USER SPACE) erzeugt die Testapplikation mit Hilfe von Managementfunktionen der US-Channel-Erweiterungen der USER-Stream-Ablaufumgebung (siehe Tabelle 34) eine Instanz des zu testenden Protokollstacks entsprechend Abbildung 50. Nach der Ausführung der Managementfunktionen „us_create_channel“ wird die Callbackfunktion

119

/* Testapplikation M_DATA Service */

... /* us_profile entsprechend konfiguration erzeugen */ if (( example_us_profile = us_make_profile( “/config/ti”, “ti_l2_er_stack.conf”)) == NULL) { printf(“test_applikation: us_make_profile error!\n”); exit( ERROR); } /* Instanz des Protokollstacks erzeugen */ if (( example_us = us_create_channel( example_us_profile, test_appl_us_rcv, test_appl_usr_arg_ptr)) == NULL) { printf(“test_applikation: us_create_channel error!\n”); exit( ERROR); } ... In dem folgenden C-Quellcode-Beispiel (USER SPACE) sind Teile der Callbackfunktion der Testapplikation abgebildet: /************************************************************* * * test_appl_us_rcv – us rcv procedure. * *************************************************************/int test_appl_us _rcv( us_t *us, mblk_t *mp) { test_appl _t *test_appl_usr_arg_ptr; if ( mp == NULL) { printf(“test_appl_us _rcv: mp == NULL!\n”); exit( ERROR); } if ( us == NULL) { printf(“test_appl_us _rcv: us == NULL!\n”); freemsg( mp); exit( ERROR); } if ((test_appl_usr_arg_ptr = (test_appl _t*)us_get_us_usr_arg( us)) == NULL) { printf ("test_appl_us _rcv: us->usr_arg == NULL!\n"); freemsg( mp); exit( ERROR); } if ( mp->b_datap->db_type == M_DATA) {

... } if ( mp->b_datap->db_type != M_PROTO) { /* Testapplikation M_PROTO Service */ ... } ... return( OK); } Die Callbackfunktion kann für unterschiedliche Instanzen in der Testapplikation gleichzeitig genutzt werden. Der Bezug der eintreffenden Nachricht, infolge dessen die Callbackfunktion aufgerufen wird und der zuständigen Verwaltungsinstanz in der Testapplikation (welche die Nachrichten kanalbezogen analysiert) ist durch eine dem Nutzer der USER-STREAM-Ablaufumgebung zur Verfügung gestellte „usr_arg“-Pointerreferenz gegeben.

5.3.3.5 Vergleich USER STREAM – SVR4 Streams

Die SVR4 Streams Ablaufumgebung ist nur auf wenigen Betriebssystemplattformen verfügbar. Eine Wiederverwendung von Protokollmodulen auf andere Plattformen (z.B. Linux) ist aufwendig. In der SVR4 Streams Ablaufumgebung implementierte Protokollmodule laufen im Kernelbereich ab. Die eingeschränkte Verfügbarkeit von Betriebsmitteln im Kernelbereich (DDI/DKI) erzwingt eine Abspaltung von Funktionalitäten (welche komplexere Betriebsmittel - z.B. Zugriff auf Konfigurationsdaten - nutzen müssen) in einen im USER SPACE ablaufenden Daemonprozess. Die Folge dieser Abspaltung ist die zusätzliche Kommunikation zwischen Kernelmodul und Daemonprozess (siehe auch 5.2.1). Für die Umsetzung der Protokollfunktionalitäten in der USER STREAM Ablaufumgebung ist die Trennung in Daemon und Kernelmodul nicht notwendig (Bereitstellung aller im USER SPACE verfügbaren Betriebsmittel im USER STREAM). Durch diese Vereinfachung entfällt auch die zusätzliche Kommunikation zwischen Kernelmodul und Daemonprozess. Die folgende Abbildung zeigt die prinzipiellen Unterschiede beim Laden von Konfigurationsparametern.

120

K o m m u n ika tio n sta s k

O S -K E R N E L

fd - - S tream s D e v ic e

k s_ load

ioctl (Pa ram e te r M odu l 1 )

S tre am s - H ead

S tre am s P ro tok o lls tac k

S tre am s - M odu l 1

S tre am s T re ibe r

S tre am s - M o du l 2

S tre am s - M o du l 1S tre am s - M o du l n

F i le s ys te m

S tre am K on figu ra tion

K on figu ra tions pa ram e te r 1

K on figu ra tions pa ram e te r n

P a ra m e te r M odu l 1

ioctl (Pa ram e te r M odu l 2 )

ioctl (Pa ram e te r M odu l n )






P a ra m e te r M odu l n

K o m m u n ika tio n sta s k

O S -K E R N E L

fd - - S tream s D ev ic e

S tre am s - H ead

U S E R S T R E A M P ro toko llstack

U S E R S T R E A M - M o du l 1

S tre am s T re ibe r

S tre am s - M od u l 1

F i le s ys te m

S tre am K on figu ra tion

K on fig u ra tions pa ram e te r 1

K on fig u ra tions pa ram e te r n







P a ra m e te r M odu l n

U S E R S T R E A M - M odu l 2

U S E R S T R E A M - M o du l n

S tre am s - M o du l 1U S E R S T R E A M - P o rt

S tre am s - M od u l 1U S E R S T R E A M - H ead

Abbildung 51: Laden von Konfigurationsparametern

Im oberen Teil der Abbildung 51 ist das Laden von Konfigurationsparametern für SVR4-Streamsmodule dargestellt. Mit Hilfe eines im USER SPACE ablaufenden Daemonprozesses (Kommunikationstask), welcher auf die Konfigurationsdateien zugreift, werden die im Kernelbereich ablaufenden SVR4-Streamsmodule mit Konfigurationsparametern versorgt (z.B. über IOCTL-Aufrufe des Streams-Treibers). Durch die Anordnung der USER STREAM Module (Port, Konverter bzw. Multiplexer) im USER SPACE (siehe unteren Teil der Abbildung 51) ist der direkte Zugriff auf die in Konfigurations-dateien enthaltenen Konfigurationsparameter möglich.

K o n fig u ra t io n v o n S V R 4 S tre a m s M o d u le n

K o n fig u ra t io n v o n U S E R S T R E A M M o d u le n

121

Die geringfügigen Performanceeinbußen durch die Verlagerung der Protokollfunktionalität der Streamsmodule in den USER SPACE (z.B. Prozesswechselaktivitäten) sind für die bahntechnischen Anwendungen akzeptabel. EURORADIO Anwendungen haben keine harten Echtzeitanforderungen, da bereits das unterlagerte GSM/R nur weiche Echtzeitanforderungen erfüllen kann. Die Echtzeiteigenschaften der USER STREAM Ablaufumgebung hängen von dem unterlagerten POSIX-konformen Betriebssystem, insbesondere von dessen Prozessverwaltung, ab.

5.4 Vermittlungsfunktionalitäten

5.4.1 Einfache Kommunikationsmodule

Einfache Kommunikationsprotokolle ohne Multiplexfunktionalitäten werden in der Kommunika-tionsplattform durch Konvertermodule umgesetzt. Die folgende Abbildung zeigt die grundsätzliche Struktur eines Konvertermoduls.

oberes Interface

unteres Interface

Message

Event

STM(Signalisierung)

STM(Flow RCV)

w_srv(...)

Message

w_put(...)M_PROTO-Message

Event

r_srv(...)

Read QueueM_DATA-Message

Event

M_DATA

M_PROTO-Message

M_DATA-Message

Event

r_put(...)

Event

STM(Flow SND)

Write Queue

EV_DATA

EV_XON; EV_XOFF

EV_DATA

EV_XON; EV_XOFF

EV_CON_REQ;EV_CON_RSP;EV_CON_REL

M_DATA

EV_START; EV_DOWN

EV_START; EV_DOWN

EV_CON_IND;EV_CON_CNF;EV_DISCON

M_PROTO

M_PROTO M_PROTO

M_PROTO

(X_ON;X_OFF)

(X_ON;X_OFF)

Abbildung 52: Grundsätzliche Struktur eines Konvertermoduls (TR-IF)

Die folgende Tabelle beschreibt die grundsätzlichen Strukturelemente eines einfachen Konvertermoduls der signaltechnisch nichtsicheren Kommunikationsplattform:

USER STREAM Konverter

122

Strukturelement Beschreibung W_PUT Übergabefunktion in Schreibrichtung, wandelt Streamsmessages in

Ereignisse zur Bearbeitung in Automaten. W_SRV Durch Scheduler zu aktivierende Bearbeitungsroutine der

Nachrichtenwarteschlange in Schreibrichtung. W_QUEUE Nachrichtenwarteschlange in Schreibrichtung (stromabwärts) R_PUT Übergabefunktion in Leserichtung, wandelt Streamsmessages in

Ereignisse zur Bearbeitung in Automaten. R_SRV Durch Scheduler zu aktivierende Bearbeitungsroutine der

Nachrichtenwarteschlange in Leserichtung. R_QUEUE Nachrichtenwarteschlange in Leserichtung (stromaufwärts) STM – Signalisierung Zustandsautomat zur Verwaltung der Signalisierungsphase STM – Flow SND Zustandsautomat zur Verwaltung der sendeseitigen Flusskontrolle

(Beeinflussung oberes Interface) STM – Flow RCV Zustandsautomat zur Verwaltung der empfangsseitigen

Flusskontrolle (Beeinflussung unteres Interface)

Tabelle 38: Strukturelemente eines einfachen Konvertermoduls

5.4.2 Kommunikationsmultiplexer mit statischer Vermittlungsfunktionalität

Komplexere Kommunikationsprotokolle mit Multiplexfunktionalitäten werden in der Kommuni-kationsplattform durch Multiplexer umgesetzt. Die folgende Abbildung zeigt die grundsätzliche Struktur eines Multiplexers (n Transportkanäle auf einen Netzkanal).

123

oberes Interface 1

unteres Interface

Message

Event

STM(Netz-Signalisierung)

STM(Flow RCV)

w_srv(...)

Message


Event

r_srv(...)


Event

M_DATA

M_PROTO-Message

M_DATA-Message

Event

r_put(...)

Event

STM(Flow SND)

Write Queue

EV_DATA

EV_XON; EV_XOFF

EV_DATA

M_DATA

EV_START; EV_DOWN

EV_START; EV_DOWN


M_PROTO

M_PROTO

Event

STM(Transport-Signalisierung)

STM(Flow RCV)

STM(Flow SND)

EV_DATA

EV_XON; EV_XOFF

EV_DATA

EV_XON; EV_XOFF

EV_START; EV_DOWN

EV_START; EV_DOWN


Multiplexreferenz

M_PROTO(X_ON; X_OFF)

PDU - Analyse PDU - Generierung


EV_DOWN

EV_DOWN

Netz -Flußkontrolle

Signalisierung Daten Flußkontrolle Signalisierung Daten Flußkontrolle

oberes Interface n

Message


Event

r_srv(...)


Event M_DATAM_PROTO

Event

STM(Transport-Signalisierung)

STM(Flow RCV)

STM(Flow SND)

EV_DATA

EV_XON; EV_XOFF

EV_DATA

EV_XON; EV_XOFF

EV_START; EV_DOWN

EV_START; EV_DOWN



EV_DOWN

USER STREAM Multiplexer

Abbildung 53: Grundsätzliche Struktur eines Multiplexers (TR/TR-IF)

Die folgende Tabelle beschreibt die grundsätzlichen Strukturelemente eines Multiplexers der Kommunikationsplattform: Strukturelement Beschreibung W_PUT Übergabefunktion in Schreibrichtung, wandelt Streamsmessages in

Ereignisse zur Bearbeitung in Automaten der Transportebene um. W_SRV Durch Scheduler zu aktivierende Bearbeitungsroutine der

Nachrichtenwarteschlange in Schreibrichtung. W_QUEUE Nachrichtenwarteschlange in Schreibrichtung (Netzebene) R_PUT Übergabefunktion in Leserichtung, wandelt Streamsmessages in

Ereignisse zur Bearbeitung in Automaten um. R_SRV Durch Scheduler zu aktivierende Bearbeitungsroutine der

Nachrichtenwarteschlange in Leserichtung. R_QUEUE Nachrichtenwarteschlange in Leserichtung (Transportebene) Transport – STM – Signalisierung

Zustandsautomat zur Verwaltung der Signalisierungsphase der Transportebene

124

Strukturelement Beschreibung Transport – STM – Flow SND

Zustandsautomat zur Verwaltung der sendeseitigen Flusskontrolle der Transportebene (Beeinflussung oberes Interface)

Transport – STM – Flow RCV

Zustandsautomat zur Verwaltung der empfangsseitigen Flusskontrolle der Transportebene (Beeinflussung der Netzebene)

Netz – STM – Signalisierung Zustandsautomat zur Verwaltung der Signalisierungsphase der Netzebene

Netz – STM – Flow SND Zustandsautomat zur Verwaltung der sendeseitigen Flusskontrolle der Netzebene (Beeinflussung Transportebene)

Netz – STM – Flow RCV Zustandsautomat zur Verwaltung der empfangsseitigen Flusskontrolle der Netzebene (Beeinflussung unteres Interface)

PDU-Analyse Analyse der Protokoll Daten Einheiten zur Ereignissteuerung der Transportebene

PDU-Generierung Erzeugung von Protokoll Daten Einheiten entsprechend eintreffender Ereignisse

Netz-Flusskontrolle Beaufschlagung der Transportebenen Flusskontrollinstanzen mit dem Flusskontrollzustand der Netzebene

Tabelle 39: Strukturelemente eines Multiplexers

5.4.3 Vermittlungskern für verbindungsorientierte Kommunikation

Die Weitervermittlung der einlaufenden Rufe auf die angeforderten Kommunikationsressourcen zur Etablierung der abgehenden Rufe erfolgt in der Kommunikationsplattform durch den Vermittlungs-kern. Die folgende Abbildung zeigt die grundsätzliche Struktur des Vermittlungskerns für ver-bindungsorientierte Kommunikation (siehe 4.6.1).

Vermittlungs-kernSig-Bridge

Listening Service 1

Data-bridge 2

Data-bridge x1

Data-bridge 1

Invo

-Sta

ck

Invo

ker S

ervi

ce A

Invo

ker S

ervi

ce B

Invo

ker S

ervi

ce C

Resp-Stack

Resp-Stack

Resp-Stack

Sign-Stack

Sig-Bridge

Listening Service 2

Data-bridge 2

Data-bridge x2

Data-bridge 1

Invo

ker S

ervi

ce D

Invo

ker S

ervi

ce E

Invo

ker S

ervi

ce F

Resp-Stack

Resp-Stack

Resp-Stack

Sign-Stack

Sig-Bridge

Listening Service n

Data-bridge 2

Data-bridge x3

Data-bridge 1

Invo

ker S

ervi

ce G

Invo

ker S

ervi

ce H

Invo

ker S

ervi

ce I

Resp-Stack

Resp-Stack

Resp-Stack

Sign-Stack

Responder

Invoker

Invo

-Sta

ck

Invo

-Sta

ck

Invo

-Sta

ck

Invo

-Sta

ck

Invo

-Sta

ck

Invo

-Sta

ck

Invo

-Sta

ck

Invo

-Sta

ck

Abbildung 54: Prinzipieller Aufbau des Vermittlungskerns

Die Vermittlungsapplikation besteht aus dem eigentlichen Vermittlungskern, der den verbindungs-orientierten Kanalaufbau realisiert, und den Responder- und Invokerstacks. Eingehende Rufe werden von der Responderseite verarbeitet. Abgehende Rufe werden von der Invokerseite initiiert.

Kommunikationsrechner- Vermittlungsapplikation -

125

Der Vermittlungskern bedient die Responder und Invoker ausschließlich über das TR-Interface (Transfer-Interface). Die Responderseite zeigt eingehende Rufe über das im Signalisierungsmode aktivierte TR-Interface an. Die Annahme eingehender Rufe erfolgt ausschließlich im Respondermode des TR-Interfaces. Für jeden Transportservice, der vom Vermittlungskern bedient werden soll, wird ein entsprechender Signalisierungsstack instanziiert. Die Signalisierungsbridge erzeugt infolge eines über den Signalisierungsstack eingehenden Rufes eine für die Etablierung des Vermittlungswunsches verantwortliche Datenbridge. Eine Callreferenz als eindeutige Referenz des Rufes wird der Datenbridge übergeben. Die Datenbridge erzeugt eine Kopie des Signalisierungsstacks und betreibt den neuen Stack im Respondermode. Die im eingelaufenen Ruf enthaltene Callvektor-Information zur Weitervermittlung wird in der Datenbridge ausgewertet und führt zur Etablierung eines Invokerstacks entsprechend des im Callvektor enthaltenen Invokerprofiles. Die geforderte Verbindung wird über den Invokerstack durch einen abgehenden Ruf von der Datenbridge initiiert. Kann die durch den Callvektor geforderte Verbindung nicht etabliert werden, wird durch die Datenbridge versucht, einen alternativen Callvektor zu nutzen, um die geforderte Verbindung zu realisieren. Kann keine gehende Verbindung aufgebaut werden, wird von der Datenbridge der zugehörige kommende Ruf am Responder Stack abgewiesen. Ist der gehende Link vom Invokerstack etabliert, wird der eingegangene Ruf von der Datenbridge über den Responderstack als Link bestätigt. Der Datenverkehr (Traffic) zwischen kommendem und gehendem Link wird von der Datenbridge übertragen. Der Abbau der Verbindung wird von der für den Link zuständigen Datenbridge organisiert.

5.4.4 Adressmanagement

Die Kommunikationsapplikationen des Funk Fahr Betriebes adressieren ihren Kommunikations-partner mit Hilfe einer applikationsbezogenen ETCS-Adresse. Diese ETCS-Adresse besteht aus vier Oktetts. Das erste Oktett bestimmt den Typ des Kommunikationspartners (Fahrzeuggerät, Strecken-zentrale oder Fahrwegelement). Die letzten drei Oktetts entsprechen der ETCS-ID des Kommunika-tionspartners. Die ETCS-ID ist innerhalb eines Typs eindeutig. Die ETCS-Adresse ist im gesamten System eindeutig. Zusätzlich kann die Kommunikationsapplikation (beim Funk Fahr Betrieb nicht genutzt) neben der ETCS-Adresse des Kommunikationspartners auch die Netzadresse (GSM/R Nummer) des Kom-munikationspartners übergeben. In diesem Fall kann die Gatewayfunktionalität der Kommuni-kationsplattform sowie die Verwendung alternativer Netzadressen nicht genutzt werden. Die folgende Abbildung beschreibt die Adresskonvertierungsaktivitäten zur Qualifizierung einer eingelaufenen Verbindungsanforderung mit allen notwendigen Informationen zur Weitervermittlung im Vermittlungskern für verbindungsorientierte Kommunikation (siehe 5.4.3).

126

Local Directory Management

defaultETCS_ADDRpresent ?

N

J

ETCS_ADDRpresent ?

N

J

DISCONNECT

START

ETCS_ADDRunknown ?

N

J unknownETCS_ADDRpresent ?

N

J

DISCONNECT

ETCS_ADDR.routepresent ?

N

J Load Router - ETCS_ADDR

Netvectorcount = 0

ETCS_ADDR.Netvectorcountpresent ?

N

J Load ETCS_ADDR.Netvectorcount

Netvectorcount ++

Net QoS Parameter Management

GSM/R Nummerpresent ?

N

J

alternativeNetvectorpresent ?

N

J

ETCS_ADDRpresent ?

N

J

DISCONNECT

Load Net - QoSParameter

get nextNetvector

Net - QoSpresent ?

N

J

defaultNet - QoSpresent ?

N

J

DISCONNECT

Load defaultNet - QoS

END

Abbildung 55: Adresskonvertierungsaktivitäten zur Qualifizierung einer eingelaufenen Verbindungsanforderung

Die folgende Tabelle beschreibt die einzelnen Adresskonvertierungsaktivitäten zur Qualifizierung einer eingelaufenen Verbindungsanforderung der Kommunikationsplattform: Aktivität Beschreibung GSM/R Nummer present ? Es wird geprüft, ob in der Verbindungsanforderung eine

GSM/R – Telefonnummer des gewünschten Kommunikationspartners vorhanden ist.

127

Aktivität Beschreibung ETCS_ADDR present ? Es wird geprüft, ob in der Verbindungsanforderung die

ETCS_ADDR des gewünschten Kommunikationspartners vorhanden ist.

default ETCS_ADDR present ? Es wird geprüft, ob im Local Directory eine default ETCS_ADDR vorhanden ist.

ETCS_ADDR unknown ? Es wird geprüft, ob die in der Verbindungsanforderung enthaltene ETCS_ADDR des gewünschten Kommunikationspartners im Local Directory nicht vorhanden ist.

unknown ETCS_ADDR present ? Es wird geprüft, ob im Local Directory eine unknown ETCS_ADDR vorhanden ist.

ETCS_ADDR.route present ? Es wird geprüft, ob für die in der Verbindungsanforderung enthaltene ETCS_ADDR des gewünschten Komunikationspartners im Local Directory eine Router – ETCS_ADDR vorhanden ist (Gateway-Struktur).

Load Router – ETCS_ADDR Die Adresse des Routers für den nächsten Verbindungsabschnitt, entsprechend der in der Verbindungsanforderung enthaltenen ETCS_ADDR des gewünschten Kommunikationspartners, wird aus dem Local Directory geladen.

Netzvectorcount = 0 Mit dem ersten Eintrag der Netzadressinformation zur gewünschten ETCS_ADDR wird begonnen.

ETCS_ADDR.Netzvectorcount present ?

Es wird geprüft, ob der n. Eintrag der Netzadressinformation zur gewünschten ETCS_ADDR im Local Directory vorhanden ist.

Load ETCS_ADDR.Netzvectorcount

Die Verbindungsanforderung wird um den aktuellen Eintrag der Netzadressinformation erweitert.

Netzvectorcount ++ Der nächste Eintrag der Netzadressinformation zur gewünschten ETCS_ADDR ist zu bearbeiten.

Net – QoS present ? Es wird geprüft, ob im aktuellen Eintrag der Netzadressinformation ein Net – QoS Wert vorhanden ist.

default Net – QoS present? Es wird geprüft, ob ein default Net – QoS Wert vorhanden ist. Load default Net – QoS Der n. Eintrag der Netzadressinformation der

Verbindungsanforderung wird mit dem default Net – QoS Wert ergänzt.

Load Net – QoS Parameter Der n. Eintrag der Netzadressinformation der Verbindungsanforderung wird entsprechend dem Net – QoS Wert mit Net – QoS Parametern ergänzt.

alternative Netvector present ? Es wird geprüft, ob ein weiterer Eintrag mit Netzadressinformationen in der Verbindungsanforderung vorhanden ist.

128

Aktivität Beschreibung get next Netvector Der nächste Eintrag der Netzadressinformation in der

Verbindungsanforderung ist zu bearbeiten.

Tabelle 40: Adresskonvertierungsaktivitäten zur Qualifizierung einer eingelaufenen Verbindungsanforderung

Alle notwendigen Informationen zur Qualifizierung der Verbindungsanforderungen sind im Local Directory der Kommunikationsplattform für den Funk Fahr Betrieb fest projektiert. Für größere verteilte Systeme ist eine Beeinflussung dieser Datenbasis zur Laufzeit notwendig (siehe 7.2.1.1).

129

6 Test / Validierung Eine Ausprägung der signaltechnisch nichtsicheren Kommunikationsplattform für den Funk Fahr Betrieb ist der Kommunikationsteil des Funk Basis Systems (Subsystem Kommunikation / FBS-K) des Bereiches Transportation Systems der Siemens AG. Die in den folgenden Abschnitten beschriebenen Test- und Validierungsaktivitäten wurden im Rahmen der Systementwicklung des FBS-K für den Funk Fahr Betrieb in Zusammenarbeit mit der Verified Systems International GmbH durchgeführt.

6.1 Methoden der Validierung

6.1.1 Funktions- und Black-Box-Tests

6.1.1.1 Tests im Rahmen der Entwicklung FBS-K

In der Phase Entwicklung des FBS Subsystem Kommunikation werden die SW-Module der unteren Schichten der Kommunikationstask bzw. der OS-Kernel-Erweiterungen des FBS-K (siehe 5.2 und 5.3) im Rahmen der Modultests schrittweise integriert und mit Hilfe von einfachen Beispiel-applikationen auf der Entwicklungsplattform (PC) getestet und Aussagen zur prinzipiellen Funktion gewonnen. Nach Abschluss dieser Modultests steht die Ablaufumgebung der Kommunikations-plattform zur Verfügung. In der nächsten Phase der Entwicklung des FBS Subsystem Kommunikation werden die auf die Ablaufumgebung aufsetzenden SW-Komponenten (siehe 5.4 ) mit Hilfe einfacher Systemkon-figurationen (z.B. Teile eines Kommunikationsstacks) im Rahmen der Softwareintegrationstests schrittweise integriert und durch eine einfache Testapplikation (welche das Schnittstellenverhalten des Vermittlungskerns nachbildet – siehe 5.4.3) auf der Entwicklungsplattform (PC) getestet und Aussagen zur prinzipiellen Funktion gewonnen.

6.1.1.2 Tests im Rahmen der Verifikation FBS-K

In der Phase Teilintegration des FBS Subsystem Kommunikation werden einzelne SW-Komponenten des FBS-K schrittweise integriert und getestet und Aussagen zu Funktion, Schnittstellen und Leistungsfähigkeit gewonnen. Die Teilintegrationsschritte werden für den Euroradio-Stack, den Koppelstack und den Transferkern durchgeführt, deren Funktion damit verifiziert wird. Im letzen Schritt der Teilintegration wird bereits das gesamte FBS Subsystem Kommunikation auf der Entwicklungsplattform (PC) integriert und getestet. Die Verifikation der kundenseitig festgelegten Zugangsschnittstellen zum GSM/R Mobilfunkgerät und zum ISDN-Netz erfolgt ebenfalls im Rahmen der Teilintegration. Damit wird bereits durch die Teilintegration der Nachweis der Erfüllung der diesbezüglichen Anforderungen erbracht. Für die im Rahmen der Validierung durchzuführenden Tests werden die Schnittstellen zum GSM/R und ISDN anforderungsgemäß verwendet. Dadurch wird deren Verwendungsfähigkeit erneut geprüft und im Rahmen der Subsystemintegration validiert. Kundenanforderungen hinsichtlich der Eigenschaften der verwendeten Hardware des FBS Subsystems Kommunikation werden durch HW-Erprobungsberichte nachgewiesen.

131

6.1.1.3 Tests im Rahmen der Integration und Validierung FBS-K

Die Validierungstests erfolgen mit den vollständigen FBS-K Komponenten auf der Zielhardware und sind als symmetrische Black-Box-Tests konzipiert. Durch die Validierungstests werden die Requirements geprüft. Insbesondere wird das prinzipielle Zusammenwirken der Komponenten des FBS-K in allen benötigten Konfigurationen getestet. Gemäß [EN 50128], Tabelle A.7 sind Funktions- und Black-Box-Tests die empfohlene Methode für Software-Validierung der Sicherheitsstufe SIL 0.

6.1.1.4 Grenzwertanalyse

Mit den Testfällen der Validierungstests werden die Grenzwerte der an den Schnittstellen definierten Wertebereiche überprüft. Die Testfälle sollen dabei nicht nur den Grenzwert selbst testen, sondern auch Werte außerhalb der Grenzwerte prüfen. Die Grenzwertanalyse wird in [EN 50128], Tabelle A.14 als Methode für Funktions- und Black-Box-Tests empfohlen.

6.1.2 Leistungstests

Im Rahmen der Validierung sollen Aussagen über die Erfüllung der definierten Performance- und Lastanforderungen seitens des FBS-K gemacht werden. Dazu werden die nachfolgend aufgeführten Leistungstest im Rahmen der Validierungstests durchgeführt.

6.1.2.1 Avalanche-/Belastungstests

Im Rahmen der Validierungstests werden die Anforderungen an das FBS-K bezüglich des statischen und dynamischen Lastmodells geprüft. Zu testen ist das Systemverhalten bei maximaler Belastung beim Verbindungsaufbau und -abbau:

• Es bauen mehrere Kommunikationspartner quasi gleichzeitig sehr viele Verbindungen auf und ab.

Zu testen ist das Systemverhalten bei maximaler Belastung im laufenden Betrieb (d.h. bei mehreren bestehenden Verbindungen):

• Burst von maximaler Sendeleistung auf mehreren gleichzeitig bestehenden Verbindungen zu einem oder mehreren Empfängern zum Test des korrekten Empfangs.

6.1.2.2 Antwortzeiten

Im Rahmen der Validierungstests werden die Anforderungen an das FBS-K bezüglich der Performance geprüft. Dazu werden aus den definierten Performance-Anforderungen die An-forderungen an das FBS-K abgeleitet. Es wird dabei von den in den Anforderungen aufgeführten Annahmen bezüglich der Performanz der verschiedenen involvierten Komponenten ausgegangen. Während der Testsdurchführung werden die erreichten Antwortzeiten protokolliert. Diese Werte werden anschließend ausgewertet. Aufgrund dieser Auswertungen kann dann auf das Verhalten des FBS-K unter realen Bedingungen zuverlässig geschlussfolgert werden.

6.1.2.3 Speichergrenzen

132

Die Speichergrenzen sind durch die Systemressourcen der Zielplattform festgelegt.

Um sicherzustellen, dass die festgelegten Limits nie erreicht werden, wird die Speichernutzung des

133

UnixWare

FBS-K im Dauerbetrieb geprüft. Damit wird sichergestellt, dass keine memory leaks vorhanden sind.

6.2 Testmanagement

6.2.1 Komponenten der Testumgebung

Die Architektur der Testanlage ist in [18] ausführlich beschrieben. Die wesentlichen Komponenten sind die RT-Tester-Engine und der Testkoppelrechner.

• Die RT-Tester Engine (Test Engine, TE) steuert die jeweilige Testsuite in Bezug auf Testkonfiguration, Testdatenerzeugung, Protokollierung und On-the-fly bzw. Offline-Auswertung. Dies geschieht mit Hilfe des generischen Echtzeit-Testsystems RT-Tester, welches für FBS-K Tests unter dem Betriebssystem Linux (siehe [5], [12]) auf PC-Hardware instantiiert wird. Die verschiedenen zu prüfenden Testszenarios werden mit RT-Tester als Netzwerke Abstrakter Maschinen, d.h. kommunizierender Echtzeit-Zustandsmaschinen beschrieben, so dass die Testkonfiguration sowie das Verhalten von Sendern und Empfängern jeweils durch eigene Abstrakte Maschinen modelliert werden kann. Abstrakte Maschinen operieren mit logischen Events, die Testkonfigurationsbefehle, Verbindungsaktivitäten sowie das Senden und Empfangen von Daten in abstrakter, d.h. von der konkreten Schnittstelle unabhängiger Weise spezifizieren. Die Umsetzung zwischen abstrakten Events und konkreten Konfigurationsbefehlen bzw. Kommunikationstelegrammen wird von einer untergeordneten Softwareschicht auf der TE, dem Interface Module Layer durchgeführt.

• Der Testkoppelrechner (TK) bildet das Verbindungsstück zwischen dem Prüfling und

der RT-Tester Engine. Der TK simuliert für den Prüfling (FBS-K) das Verhalten der signaltechnisch nichtsicheren Applikation und stellt der Test-Engine die Testkonfigurationsschnittstelle zur Verfügung. Weiterhin realisiert der TK für die Test Engine eine Interfaceabstraktion: Die Allokation der Prüflings-Software auf konfigurationsabhängige Hardwarekomponenten bleibt hierdurch für die Test Engine transparent. Eine Zuordnung von logischen Kommunikationskanälen auf die konfigurationsabhängigen Schnittstellen des Prüflings wird vom TK vorgenommen.

TE und TK kommunizieren über Ethernet und TCP/IP unter Verwendung der Interface-Library des RT-Tester-Systems. Testumge-bung Nr.

Kurzbeschreibung HW, SW, Gerät

1 RT-Tester-Engine TE, Basis Standard PC/ Notebook mit SuSe Linux

2 RT-Tester-Engine, Software RT-Tester 3 Interface-Modul IFM-FBS IFM-FBS 4 Testkoppelrechner TK, Basis Standard PC mit

5 Testkoppelrechner TK, Software zur Kopplung: FRTA FBS Realtime Test Agent inkl. FRTA-RTT-Plug-In

6 ISDN-Vermittlungsstelle TELES 7 ISDN-Terminal-Adapter ISDN-TA

Tabelle 41: Komponenten der Testumgebung

6.2.2 Komponenten des Prüflings

Prüfling ist das FBS Subsystem Kommunikation. Die Softwarekomponenten des Prüflings sind in folgender Abbildung dargestellt.

Prüfling

Transferkern

Koppel- stack

Eurora-dio-Stack

Abbildung 56: Softwarekomponenten des Prüflings

Prüfling und Testkoppelrechner (TK) kommunizieren über V.24.

6.2.3 Varianten des Prüflings

Der Prüfling wird in folgenden Konfigurationen eingesetzt:

• Auf AT96 (Fahrzeugtauglicher Rechner) zur Darstellung von FFB-Fahrzeuggerät und FFB-Fahrwegelement (z.B. Weichenansteuerung).

• Auf IPC (Industrie PC) zur Darstellung der FFB-Zentrale

6.2.4 Auswertekonzept

FBS-K - Testläufe können in Bezug auf folgende Aspekte ausgewertet werden:

• Auswertung im Datenbereich: Datentelegramme werden unverfälscht kommuniziert

• Auswertung im Kausalbereich: Datentelegramme werden in der richtigen Reihenfolge und ohne Telegrammverlust kommuniziert

• Auswertung im Zeitbereich: Datentelegramme treffen im geforderten Zeitintervall ein.

134

• Statistische Auswertung: (1) Verteilung der Verbindungsaufbaudauer auf der Basis des

dynamischen Lastmodells (inkl. Multiplex von virtuellen Verbindungen) für jeden FBS-Basistyp (Fahrzeug, Fahrwegelement, Streckenzentrale) in Abhängigkeit der Verbindung (HAYES-HAYES, HAYES-S2M, S2M-S2M, S2M-HAYES) (2) Verteilung der Transferverzögerung auf der Basis des statischen und dynamischen Lastmodells für jeden FBS-Basistyp in Abhängigkeit der Verbindung.

Die Dokumentation der Auswertung enthält folgende Komponenten:

• Verweis auf die im vorliegenden Dokument festgelegten Testziele, erwarteten Resultate und Testendekriterien.

• Gesamtresultat: Testfall korrekt/mit Fehler(n) durchgeführt

• Verweise auf On-The-Fly Fehlermeldungen: Abweichungen vom spezifizierten

Zustandsmaschinen-Verhalten werden durch einen Verweis auf die entsprechende Stelle im Testprotokoll (PDF- bzw. HTML-Link) vermerkt.

• Verweise auf besondere Testereignisse: Optional können bestimmte Testsituationen

(z.B. das Prüfen einer bestimmten Anforderung, oder im Test erwartete zulässige Fehlersituationen wie Rufkollisionen, Fehler durch Einfluss der Übertragungsstrecke auf das FBS-Verhalten [QoS, fehlerhafte ISDN-TA]) durch Hilfsereignisse im Testprotokoll vermerkt und analog zu Fehlermeldungen mit einem Verweis vom Auswertungsdokument auf das Testprotokoll versehen werden.

• Statistische Auswertungen: Für Verteilungen von Kommunikationszeiten bzw.

Fehlern beim Verbindungsaufbau werden y-t-Diagramme als Plots ausgegeben.

• Requirements-Tracing Matrix: Eine Matrix mit Zuordnung der im Test geprüften bzw. noch nicht abgedeckten Anforderungen.

• Anhang Testprotokoll: Das detaillierte, alle Kommunikationsereignisse enthaltende

Testprotokoll bildet eine Anlage zum Testauswertungsdokument.

• Anhang Testspezifikationen: Die kommentierten CSP-Zustandsmaschinenspezifikationen mit detaillierter Beschreibung der erwarteten Resultate in Bezug auf Werte, Kommunikationsreihenfolge und Kommunikationszeitpunkte bilden einen weiteren Anhang zum Testauswertungsdokument.

• Anhang Testkonfiguration: Die Testkonfigurationsdateien, welche die verwendeten

Testzugangslabel sowie die im Test kooperierenden Abstrakten Maschinen spezifizieren, sind als weiterer Anhang dem Testauswertungsdokument beigefügt.

135

6.3 Grundlagen

6.3.1 Überblick

Die Validierungstests erfolgen mit den vollständigen FBS-K Komponenten auf der Zielhardware und sind als symmetrische Black-Box-Tests konzipiert. Die Komponenten der Testumgebung und des Prüflings werden dazu, wie in folgender Abbildung verdeutlicht, miteinander gekoppelt. Dabei sind hier beispielhaft zwei Prüflinge angegeben.

RTT Test Engine

Testkoppelrechner

Kop-pel- stack

FRTA

RTT-Plugin

IFM-FBS

TE

TK

Prüfling A

Transferkern

Kop-pel- stack

Euroradiostack

FBS-K

Prüfling B

Transferkern

Kop-pel- stack

Euroradiostack

FBS-KGrauer Kanal

Abbildung 57: Überblick Testaufbau

Die Anzahl der Prüflinge, deren Hardware-Konfiguration und die Verbindungsart, mit der die Prüflinge miteinander kommunizieren, variieren in den unterschiedlichen Validierungstests. In den folgenden Kapiteln werden alle erforderlichen Kriterien und Parameter für diese Variationen dargelegt.

136

6.3.2 Testschritt

Die Validierungstests werden in den folgenden zwei aufeinander aufbauenden Testschritten durchgeführt, um bei Abweichungen von den erwarteten Prüfergebnissen an den Prüflings-schnittstellen die Ursachen des abweichenden Verhaltens einzugrenzen (Basisfunktionen TP2 oder Vermittlungsfunktionen der Gruppensteuerung) und die Prüflingskonfigurationsvarianten im Testschritt 2 zu reduzieren: Nr. Testschritt Name Testschritt Bezeichnung Testschritt 1 Integration FBS-K mit TP2 (EURORADIO) i_tp (TP2) 2 Integration FBS-K mit Gruppensteuerung und

TP2 i_tp (GR/TP2)

Tabelle 42: Testschritte

Bei jedem Testschritt handelt es sich um einen Integrationsschritt und die zugehörige Prüfung des Entwicklungs-/Funktionsstands des Prüflings im Rahmen dieser Integration. In jedem Testschritt sind geeignete Testkonfigurationen des Prüflings erforderlich. Testschritt 1 wird mit zwei Testkonfigurationen (Prüflingskonfigurationen) durchgeführt. Für Testschritt 2 wird nur eine Testkonfiguration benötigt.

6.3.3 Testkonfiguration

Eine Testkonfiguration besteht aus einer individuell konfigurierten HW- und SW-Architektur. In jeder verwendeten Testkonfiguration sind mehrere FBS-K-Rechner über eine ISDN-Nebenstellen-anlage miteinander verbunden. Die folgende Abbildung stellt beispielhaft den Hardwareaufbau einer FFB-Testanlage dar:

137

FBS-K - Testanlage

2 HE

Industrie-PC B4 HE

Industrie-PC A

4 HE

TELS-PC4 HE

5 10 1 5 20 25 30 35 40 45 5 0 55 115 12 0 125 13 0 135 1 40 145 150 15 5 160 1 6560 65 70 7 5 80 85 90 95 10 0 1 05 110

Industrie-PC

4 HE

Umschalteinheit

Tastatur

2 HE

2 HE

2 HE

3 HE

5 HE

ISDN-TA

230VIN

230VOUTISDN-SoLANLANLANLANLAN

LAN HUBISDN-Router

Monitor

USV 230V

2 HE

ISDN-TAISDN-TA

ISDN-TA

S2M :-1100 -1200

S0 :-2040 -2041 -2050 -2051

IP: 192.168.100.225

IP: 192.168.100.226

IP: 192.168.100.228

IP: 192.168.100.220

IP: 192.168.100.221

IP: 192.168.100.222

S0: -2040B1: COM1S0: -2041B1: COM2

AT96-B1 AT96-B2

S0: -2050B2: COM1S0: -2051B2: COM2

Testkoppelrechner

S2M : -1100

S2M : -1200

COM 1

COM 1

COM 1COM 2COM 3COM 4

IP: 192.168.100.229

Schnittstellenkabel SUB-D 9 polBuchse/25 pol Stecker(PC-Modem)

Patchkabel (Cat. 5), 100 Ohm

BNC-Kabel RG58

Schnittstellenkabel SUB-D 9 pol Buchse/9 pol Buchse(PC-PC)

Patchkabel (Cat. 5), 100 Ohm(TELES S2M/BINTEC S2M)

Abbildung 58: Beispiel Testaufbau

Die Testumgebung hat über TR-Schnittstellen Zugang zur Testkonfiguration und steuert damit die Testdurchführung. In den Testschritten der Validierungstests (siehe 6.3.2 ) wird zusätzlich zur Testkonfiguration ein Hilfsrechner (TK) als Testmittel zur Ansteuerung der Testkonfiguration benötigt. Für die Kopplung Hilfsrechner-Prüflingsrechner wird eine serielle Kopplung über V.24 verwendet. Wesentliche Konfigurationsmerkmale sind durch die Verbindungsart gegeben. Zur Kennzeichnung dieser Merkmale werden die folgenden Abkürzungen eingeführt. Diese werden in den Bezeichnern für Testschritte und Testfälle (s.u.) verwendet.

VGA

C OM 1

K eyb.

C OM 2

LP T R S422*

L AN

C OM 3

V GA

C OM 1

K eyb .

C OM 2

LP T R S42 2*

LA N

C OM 3

138

Beschreibung Verbindungsart Konfigurationsmerkmal Point-to-Point pp Point-to-Multipoint pmp Gruppensteuerung, Verbindung über Gateway gr

Tabelle 43: Verbindungsart

Folgende Testkonfigurationen, werden in den Testschritten verwendet: Kurzbeschreibung der Testkonfiguration Testkonfigurationsname Testschritt 1, Point-to-Point 1_pp Testschritt 1, Point-to-Multipoint 1_pmp Testschritt 2, Gruppensteuerung 2_gr

Tabelle 44: Testkonfiguration

6.3.3.1 Aktivierungsscript

Zur Konfiguration der FBS-Software auf den unterschiedlichen Prüflingsrechnern und dem Testhilfsrechner werden spezielle Konfigurationseinstellungen für SW-Komponenten benötigt. Das Aktivierungsscript ist ein rechnerspezifisches ausführbares Shellscript, welches alle für den jeweiligen Test auf der entsprechenden Testhardware erforderlichen SW-Komponenten in der notwendigen Konfiguration aktiviert.

6.3.3.2 Testzugangskonfiguration und Zugangslabel

Für den Zugang des Testsystems zu einer Testkonfigurationen werden verschiedene Testzugangs-konfigurationen (TZK) benötigt. Mit Hilfe der Testzugangskonfigurationen wird der Zugang des Testsystems zu den FBS-K-Rechnern so konfiguriert, dass die für die Testdurchführung erforder-lichen Kommunikationsverbindungen auf Anforderung des Testsystems eingerichtet werden können (Kommunikationsstacks und Kommunikationsadressen). Für die Identifikation der Testzugangskonfigurationen wird ein Zugangslabel eingeführt. Das Zu-gangslabel ist generisch aufgebaut und beschreibt den Filename (inkl. Teilpfad) der Testzugangs-konfiguration. Das Zugangslabel beinhaltet folgende, durch „/“ getrennte Angaben: 1. Testzugangskonfiguration [tzk] 2. Auswahl Testschritt [i_tp] 3. Auswahl Verbindungsbeziehung [pp; pmp] 4. Auswahl Callrichtung [in; out] 5. Für incoming Calls: Auswahl Testinstanz mit Extension tzk [a.tzk; b.tzk; b1.tzk; b2.tzk] 6. Für outgoing Calls: Auswahl der Testinstanzen für Quelle und Ziel des Rufes mit Extension tzk

[a_b.tzk; a_b1.tzk; a_b2.tzk; b_a.tzk; b1_a.tzk; b2_a.tzk; b1_b2.tzk; b2_b1.tzk] 7. Nach der Angabe des Zieles kann bei Bedarf noch die Angabe der Netzzugangsvariante

(Telefon-Nr. zur Selektion B-Kanal oder ISDN-TA) erfolgen, Beispiel: a_b1_1. Damit kann festgelegt werden, welche Transportkanäle auf welchen Netzkanälen abzubilden sind.

Beispiel: tzk/ti_tp/pp/in/a.tzk

139

Dieser Dateiname verweist auf eine Testzugangskonfiguration, die im Testschritt 1 (Integration FBS-K mit TP2) für die Verbindungsbeziehung Point-to-Point (Prüfling B kommuniziert bidirektional mit Prüfling A) für eintreffende Rufe in Prüfling A verwendet wird.

6.3.4 Testfall

Ein Testfall beschreibt die in einer festgelegten Testkonfiguration durchzuführenden Prüfaktivitäten an den Prüflingsschnittstellen. Die Prüfaktivitäten werden dabei durch mehrere Szenarien an den Prüflingsschnittstellen definiert, die typische Schnittstellenfunktionen nachbilden (siehe auch 6.3.5). In jedem Testschritt wird mit jeder Testkonfiguration mindestens ein Testfall durchgeführt. Je nachdem, welche Variationen in der jeweiligen Testkonfiguration möglich sind, unterscheiden sich die Testfälle z.B. in der Anzahl der Verbindungspartner, den Verbindungsarten, der Anzahl der aufgebauten Verbindungen etc. Ein Testfall ist festgelegt durch:

• Die Testziele, • Die Testendekriterien, • die Testkonfiguration, in welcher der Testfall abläuft, • eine vom Testfall genutzte Auswahl von Testzugangslabeln der Testkonfiguration, • Parameter für die Durchführung der Testszenarien (siehe 6.3.5), • sowie formale CSP-Spezifikationen (siehe [15], [16]), die die konkrete

Testdurchführung und die dabei erwarteten Testergebnisse formal beschreiben. In die CSP-Spezifikationen gehen alle zuvor genannten Punkte ein.

In jedem Testfall werden alle Testszenarien aus Kapitel 6.3.5 mit den für den Testfall festgelegten Parametern ausgeführt. Dies ist in den CSP-Spezifikationen des Testfalls berücksichtigt. Um sowohl Funktionstests als auch Belastungstest abzudecken, wird jeder Testfall in zwei Modi ausgeführt: Funktionstest (Modus f) und Dauertests (Modus d). Modus f/Funktionstest: Jedes Szenario wird für die Dauer von ca. 15 Minuten ausgeführt. Falls Fehler auftreten, wird der Testfall nach Fehlerkorrektur wiederholt. Modus d/Dauertests: Dauertests werden nach erfolgreicher Durchführung der Funktionstest gestartet. Sie dienen dazu, insbesondere Stabilität und Speicherverbrauch des Prüflings unter Langzeitbelastung zu testen. Ein Dauertest besteht aus mehreren nacheinander abzuarbeitenden Szenarien über eine Gesamtzeitdauer von mindestens 24 h. Das System wird beim Wechsel zwischen verschiedenen Szenarien dabei nicht heruntergefahren. Auftretende Fehler werden protokolliert, führen aber nicht zum Testabbruch. Nach Fehlerkorrektur wird der Dauertest wiederholt. Als Fehler gelten: 1. Datenfehler (CRC-Fehler) 2. Fehlende Ereignisse 3. Falsche Reihenfolge von Ereignissen 4. Unerwartete Ereignisse (z.B. Fehlermeldungen) 5. Verletzung von Zeitschranken

140

6.3.5 Testszenario

Der Zugang der Testumgebung zu den Testkonfigurationen erfolgt in allen Fällen einheitlich über FBS-interne TR-Schnittstellen. Diese Schnittstellen stellen verbindungsorientierte Nutzdatenkanäle zur Verfügung. Die folgende Abbildung zeigt das Zustandsübergangsverhalten an der TR-Schnittstelle:

ST_TR_IDLE

ST_TR_INCOMING

ST_TR_CONNECTED

TR_DOWN

TR_CON_IND

ST_TR_OUTGOING

ST_TR_DISCON_PENDING

TR_CON_REQ

TR_CON_REL

TR_CON_REL

TR_CON_CNF

TR_CON_RSP

TR_CON_REL

TR_DOWN

TR_DOWN

TR_DOWN

Abbildung 59: Zustandsübergangsverhalten des Zugangs der Testumgebung (TR-Schnittstelle)

Zum Test des Prüflings über diese Schnittstellen werden sieben Testszenarien festgelegt. Fünf Testszenarien (siehe 6.4.1 bis 6.4.5) decken die Möglichkeiten der Verbindungssteuerung (Transitionen entsprechend Abbildung 59) inkl. einer Testdatensequenz (zur Prüfung des Nutzdatenkanals und der Verbindungsabbausynchronisierung der beiden über die Schnittstelle kommunzierenden Teilnehmer) ab. Ein Szenario (siehe 6.4.6) steuert den Test in der Datenübertra-gungsphase. Ein weiteres Szenario (gemischtes Szenario - siehe 6.4.7) ist eine Kombination der Testszenarien zur Verbindungssteuerung und Datenübertragung.

141

Die Funktionalität an der TR-Schnittstelle kann durch diese sieben Testszenarien ausreichend

142

TDB Wartetimer zwischen 2 Datenpaketen bei Prüfling B

getestet werden. Alle Testszenarien werden grundsätzlich in jedem Testfall, mit jeder Testkon-figuration und in jedem Testschritt durchgeführt. Das Verhalten bei gleichzeitiger Belastung mehrerer Netz- bzw. Transportressourcen wird durch parallele Ausführung von Szenarien realisiert. Die einzelnen Szenarien sind voneinander unab-hängig und verfügen über Timer, in denen stochastische Komponenten enthalten sind. Dadurch ergibt sich ein stochastisches Gesamtbelastungsmodell. Szenario Nummer

Bezeichnung Beschreibung

1 con_ok_a Verbindungsaufbau vollständig Abbau durch rufenden Teilnehmer

2 con_ok_b Verbindungsaufbau vollständig Abbau durch gerufenen Teilnehmer

3 con_not_ok_b Verbindungsaufbau unvollständig Abweisung durch gerufenen Teilnehmer

4 con_not_ok_a Verbindungsaufbau unvollständig Abweisung durch rufenden Teilnehmer

5 con_not_ok_n Verbindungsaufbau unvollständig Abweisung durch Netz

6 con_data Verbindungsaufbau vollständig Bidirektionale Datenübertragung

7 con_all Bidirektionale Datenübertragung. Nichtdeterministisch gesteuerter Verbindungsabbau durch einen der Kommunikationspartner in jeder Phase der Kommunikation. Dies entspricht der nichtdeterministischen Auswahl aus den Szenarien con_ok_a, con_ok_b, con_not_ok_a, con_not_ok_b und con_data. Unabhängig voneinander parallel pro TR-Interface. Neuauswahl nach jedem Durchlauf.

Tabelle 45: Testszenarien

In den Testszenarien werden Timer verwendet, die als Parameter ausgelegt sind. Für jeden Testfall müssen die Timer-Parameter der Testszenarien geeignet festgelegt werden. Timer Name

Beschreibung

TESTB Timer für Maximaldauer zum vollständigen Ablauf eines Verbindungsaufbauszenarios. Bei Signalisierungstests ist auch ein bidirektionaler Datenaustausch zur Überprüfung der Verbindung enthalten. Der Ablauf von TESTB stellt in allen Szenarien außer CON_ALL ein Fehlerereignis dar.

TW Wartetimer für Restart des Szenarios TREJ Wartetimer für Verbindungsabweisung oder -rücknahme TDA Wartetimer zwischen 2 Datenpaketen bei Prüfling A

Timer Beschreibung Name TCONREL Timer für Maximaldauer zwischen Verbindungsabbau-Anforderung und

Abbau der Verbindung TTEST Gesamttestdauer eines Szenarios. Das Szenario wird solange wiederholt, bis

TTEST abgelaufen ist. Bei Szenario con_data bestimmt TTEST die Dauer eines Szenariodurchlaufs.

Tabelle 46: Timer

Der Timer TESTB wird für jedes Szenario einzeln spezifiziert, diese Timer werden entsprechend TCON_OK_A ... TCON_ALL genannt. Auch der Wartetimer TW wird für jedes einzelne Szenario festgelegt. TREJ wird für Szenario con_not_ok_a und con_not_ok_b einzeln spezifiziert. Alle Wartetimer TX können bei wiederholter Durchführung von Testszenarien in ihrer Größe variiert werden. Dazu wird für einen Timer TX ein fester Anteil TX BASE definiert, der um einen zufälligen Anteil im Intervall 0 ... TX DELTA ergänzt wird. Die konkrete Definition der Abläufe in einzelnen Testszenarien erfolgt an Hand von Message Sequence Charts.

143

6.4 Testszenarien

6.4.1 Testszenario 1/ CON_OK_A (Signalisierung)

• Verbindungsaufbau (vollständig) • Verbindungsabbau durch rufenden Teilnehmer

TR_CON_REQ

TR_CON_IND

TR_CON_RSP

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

TR_CON_CNF

T estb

T w

TR_CON_REQ

TR_CON_REL

TR_DOWNTR_DOWN

Abbildung 60: Testszenario 1

144

6.4.2 Testszenario 2/ CON_OK_B (Signalisierung)

• Verbindungsaufbau (vollständig) • Abbau durch gerufenen Teilnehmer

TR_CON_REQ

TR_CON_IND

TR_CON_RSP

M_DATA

M_DATA

M_DATA

M_DATA

TR_CON_CNF

T estb

T w

TR_CON_REQ

TR_CON_REL

TR_DOWN TR_DOWN

M_DATA

M_DATA


145

6.4.3 Testszenario 3/ CON_NOT_OK_B (Signalisierung)

• Verbindungsaufbau (unvollständig) • Abweisung durch gerufenen Teilnehmer

TR_CON_REQ

TR_CON_IND

TR_CON_REL

TR_DOWN

T w

TR_CON_REQ

T rej


146

6.4.4 Testszenario 4/ CON_NOT_OK_A (Signalisierung)

• Verbindungsaufbau (unvollständig) • Rücknahme durch rufenden Teilnehmer

TR_CON_REQ

TR_CON_IND

TR_CON_REL

TR_DOWN

T w

TR_CON_REQ

T rej

TR_DOWN


147

6.4.5 Testszenario 5/ CON_NOT_OK_N (Signalisierung)

CON_NOT_OK_N entspricht CON_OK_A oder CON_OK_B jeweils mit Testb = ∞.

• Verbindungsaufbau (unvollständig) • Abbruch durch Netz

TR_CON_REQ

TR_DOWN

T w

TR_CON_REQ


148

6.4.6 Testszenario 6/ CON_DATA (Datenphase)

• Verbindungsaufbau (vollständig) • Bidirektionale Datenübertragung

TR_CON_REQ

TR_CON_IND

TR_CON_RSP

M_DATA

M_DATA

M_DATA

M_DATA

TR_CON_CNF

T estb

Tda Tdb

Tdb

Tdb

Tdb

Tda

Tda

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

M_DATA

Tdb


Der Datenaustausch erfolgt solange, bis TTEST abgelaufen ist. Danach führt nicht deterministisch gesteuert einer der beiden Verbindungspartner TR_CON_REL durch. Der Test ist beendet, wenn beiden Kommunikationspartnern TR_DOWN gemeldet wurde. Durch Wahl der Parameter für die Durchführung des Testszenarios (Wartetimer TDA bzw. TDB und Nachrichtengröße der zu

149

versendenden Testdaten) können die Eigenschaften des zu testenden Nutzkanals (z.B.

150

besteht in der Minimierung von Risiken der Inkompatibilität der Kommunikationsplattform mit anderen Realisierungen des EURORADIO-Protokollstacks gemäß UNISIG CLASS 1. Der

Durchsatz/Übertragungsbandbreite und Flusskontrollverhalten) berücksichtigt werden.

6.4.7 Testszenario 7/ CON_ALL (gemischtes Szenario)

Das Testszenario con_all entspricht im Wesentlichen dem Szenario con_data mit folgenden Unter-schieden: Nach dem Ablauf von TESTB führt der Invoker (A) TR_CON_REL durch. Der Ablauf von TESTB stellt in diesem Szenario kein Fehlerereignis dar. Der Responder (B) kann wahlweise auf TR_CON_IND mit TR_CON_REL oder TR_CON_RSP reagieren. TDA und TDB sind für das erste zu sendende Telegramm gleich null, d.h. nach TR_CON_RSP bzw. TR_CON_CNF wird sofort ein Telegramm gesendet bzw. mit TR_CON_REL reagiert. Sowohl Responder als auch Invoker können nach dem Ablauf von TDB bzw. TDA wahlweise ein Telegramm senden oder TR_CON_REL durchführen. Nach vollzogenem Verbindungsabbau wird das Szenario nach Ablauf von TW wiederholt, es sei denn TTEST ist zwischenzeitlich abgelaufen.

6.5 Kompatibilitäts- und eingeschränkte Konformitätsnachweisstrategie

UNISIG CLASS 1 definiert eine Vielzahl von Anforderungen an die EURORADIO-Protokoll-stacks. Der Nachweis der korrekten Realisierung der EURORADIO-Protokollstacks kann durch Testen nicht erfolgen, da:

• Die Kombination aller geforderten Protokollzustände und -optionen einen riesigen Zustandsraum bildet, der unter wirtschaftlichen Gesichtspunkten nicht abgedeckt werden kann.

• Die äußeren Bedingungen für die Beaufschlagung der Protokolle an den Schnittstellen

nicht eingegrenzt sind und deshalb der Zustandsraum nicht beschränkt wird. Dieses für komplexe Übertragungsprotokolle typische Nachweisproblem kann gelöst werden, indem ein Referenzprotokollstack und ein Set von Referenztestfällen geschaffen wird. Dadurch könnten neue Implementierungen auf Konformität überprüft werden. Diese Referenzlösungen existieren nicht für die signaltechnisch nichtsicheren Protokollstacks der UNISIG CLASS 1 Spezifikation. Eine Protokollspezifikation ohne Referenztestfälle kann zwar als Eingangsanforderung für die Entwicklung gelten und auch bei der Realisierung verfolgt werden. Problematisch ist aber deren Nachweis. Nach Abschluss der Entwicklung und Test der EURORADIO-Protokollstacks nach UNISIG CLASS 1 verbleibt ein erhebliches Risiko, so dass sich das System in bestimmten Situationen nicht UNISIG-konform verhält und nachgebessert werden muss. Dieses Risiko tritt dann auf, wenn innerhalb einer Anlage unterschiedliche UNISIG-Implementierungen kommunizieren sollen (z.B. ausländische ETCS-Fahrzeuge fahren auf dem Streckennetz der DB). Die Nachbesserungen sind aufwendig (Traceauswertungen), unplanmäßig und kostenintensiv, da bereits ausgelieferte Systeme geändert werden müssen. Das Ziel der Kompatibilitäts- und eingeschränkten Konformitätsnachweisstrategie (siehe auch [29])

Gesamtaufwand für die Minimierung der Risiken bezüglich Inkompatibilität soll in vertretbaren Grenzen gehalten werden. Eine Realisierung des EURORADIO-Protokollstacks besitzt bestimmte Eigenschaften, die sich in Aufbau und Struktur der PDU´s und/oder im Zustandsverhalten der Protokollschicht wiederspiegeln. Das Zustandsverhalten einer Protokollschicht beeinflusst ebenfalls den PDU-Inhalt, weil die PDU´s neben Daten auch Ereignisse für Zustandswechsel übertragen. Diese Eigenschaften können im PDU-Strom am Ausgang einer Protokollschicht geprüft werden. Alle relevanten UNISIG-Anforderungen können deswegen in Anforderungen an Aufbau/Struktur der PDU´s (=statische Anforderungen) und Anforderungen an die Zustandslogik (=dynamische Anforderungen) für jede Protokollschicht überführt werden. Die statischen Konformitätsanforderungen bestimmen, welcher PDU-Aufbau am Ausgang einer Protokollschicht prinzipiell zulässig ist. Diese PDU-Regeln werden im Analyse-Testsystem hinterlegt. Neben dem PDU-Format können auch bestimmte Inhalte der PDU´s auf Konformität geprüft werden. Die dynamischen Konformitätsanforderungen bestimmen, welche Zustandswechsel in Abhängigkeit welcher Ereignisse in einer Protokollschicht auftreten können. Das aus UNISIG abgeleitete Zustandsmodell wird ebenfalls im Analyse-Testsystem hinterlegt. Folgende Vorteile bestehen bei der Anwendung eines rein passiven Analyse-Testsystems bei konsequenter Trennung von Stimulation und Prüfung des SUT:

• geringere Komplexität des passiven Analyse-Testsystems (Orakels) gegenüber einem Referenzstack (lokale Zwischenzustände und Diensteschnittstellen eines aktiven Protokollstacks brauchen nicht realisiert zu werden)

• diversitärer Implementierungsansatz (das Analyse-Testsystem prüft entsprechend

abgeleiteter Regeln)

• Verwendung zur Analyse von Inkompatibilitätsproblemen auch im Feldeinsatz ("Konformitätsmonitoring" auch bei regulärem Nutzdatenverkehr).

6.5.1 Konfiguration des Prüflings

Die folgende Abbildung zeigt die benötigte SUT Konfiguration (nur ein Rechner mit emulierter Teststrecke).

151

Test-szenarien

Regelverstößedyn. Konf.TracesRegelverstöße

stat. Konf.Traces

Zustands-automat

PDU-Definition

AnalysierterProtokolllayer Analyse

statischeKonformität

AnalysedynamischeKonformität

Testsystem Stimulation

StimulationSchnittstellen KBS

SUT

Testsystem Analyse

Unisig-Requirements

eingeschränkte Konformitätsanforderungen

Meßpunkt

PDU Event

statische dyna-mische

Vereinfachtes KanalmodellGSM-R/ISDN

Abbildung 66: SUT Konfiguration

Für die Durchführung der eingeschränkten Konformitätsanalyse werden zwei EURORADIO-Stacks über ein Übertragungsmedium miteinander gekoppelt. Das Übertragungsmedium ersetzt das GSM/R-ISDN-Netz und stellt ein vereinfachtes Kanalmodell dar, in welchem das Zeitverhalten eines fehlerfreien GSM/R-ISDN-Kanals nachgebildet wird. Zusätzlich werden im Kanalmodell deterministische Fehlermuster erzeugt, die verschiedene Fehlerzustände im Netzkanal nachbilden und damit Fehlerreaktionen in den Protokollstacks aus-lösen. An den äußeren Schnittstellen (Kopplungsschnittstelle zum sicheren Rechner bzw. SA-Schnittstelle im sicheren Rechner) werden die EURORADIO-Stacks mit Testszenarien stimuliert, die das Regel-verhalten von FFB-Systemen nachbilden Die untere Dienstschnittstelle der auf Konformität zu untersuchenden Protokollschicht im SUT bil-det einen Messpunkt, an dem das Analyse-Meßsystem passiv den gesamten PDU-Verkehr abgreift und zur Analyse herausführt. Für den Betrieb der Kommunikationsplattform ist die Monitoring-Funktion transparent. Der herausgeführte PDU-Strom wird im Analyse-Testsystem on the fly ausgewertet. Dazu werden die PDU´s zunächst hinsichtlich ihres strukturellen Aufbaus auf Regelkonformität überprüft, indem sie mit den hinterlegten PDU-Definitionen verglichen werden. Für diese Auswertung sind keinerlei Informationen über Zustände in der Protokollschicht notwendig. Es erfolgt ausschließlich eine Formatanalyse. PDU´s, die Abweichungen von den hinterlegten Definitionen aufweisen, werden als Konformitätsverstoß registriert und abgespeichert. Zur Kontrolle wird ebenfalls der gesamte PDU-Strom als Trace abgelegt.

152

PDU´s, die regelkonform sind, werden anschließend auf enthaltene Informationen bezüglich Zustandswechsel untersucht. Wird ein Event erkannt, erfolgt eine Meldung an das Auswertemodul für dynamische Konformität. In diesem Modul wird analysiert, ob das Event im gegenwärtigen Zustand erlaubt ist und ob der Folgezustand dem Zustandsmodell entspricht. Die zugeordnete Zustandsmaschine im Auswertemodul wird bei gültigen Events entsprechend umgeschaltet. Fehlerhafte Events werden als Regelverstöße protokolliert. Alle Aktivitäten der Zustandslogik werden als Trace parallel abgelegt. Im Ergebnis der Testdurchführung liegen Protokolle für alle Konformitätsverletzungen hinsichtlich statischer und dynamischer Konformität vor. Außerdem stehen Traces für ggf. notwendige Auswer-tungen und Fehlersuche bereit. Folgende Vorteile ergeben sich bei Verwendung eines passiven Analysesystems zur Konformitäts-prüfung (kein aktiver Referenzstack):

• ein Referenzstack wird nicht benötigt,

• das Analysesystem kann auch während des Regelbetriebes verwendet werden (z.B. zur Analyse auch von sporadisch auftretenden Kompatibilitätsproblemen),

• die Komplexität eines passiven Analysesystems ist im Vergleich zum kompletten

Protokollstack geringer (die Verwaltung von lokalen Steuerprimitiven, Zwischenzuständen usw. fällt weg),

• das passive Analysesystem kann schichtenweise skalierbar verwendet werden (nur ein

Teil der Schichten des zu analysierenden Protokollstacks kann betrachtet werden),

• das passive Analysesystem kann funktional skalierbar verwendet werden (nur ein Teil des Regelwerkes der zu analysierenden Protokollschicht kann betrachtet werden),

• das Zeitverhalten der SUT-Protokollstacks wird nicht oder nur unwesentlich (Tracelast)

verändert. Durch den passiven Analyseansatz sind sporadisch auftretende Fehlerbilder nur beschränkt reprodu-zierbar. Bei entsprechend ausgelegten Trace- und Ereignisspeichergrößen des Analysesystems ist ein sporadisch aufgetretener Konformitätsverstoß und die Randbedingungen, die zu dem Fehlerbild führten, erkennbar. Auf Basis der durch das Analysesystem gewonnenen Tracedaten im zeitlichen Umfeld eines Konformitätsverstoßes, ist eine systematische Verifikation in komplexeren Simulationsumgebungen (bzgl. Netzproviderkanalverhalten und Nutzdatenverkehr der Applikation) möglich.

6.5.2 Randbedingungen

Der eingeschränkte Konformitätsnachweis beschränkt sich nur auf den Regelbetrieb der Kommunikationsplattform. Das heißt, der Nachweis der Konformität bei regelwidrigem Verhalten an den Dienstzugangsschnittstellen der Kommunikationsplattform, bei nicht protokollkonformer Gegenstelle und bei PDU-Verfälschung an den Dienstzugangsschnittstellen der Protokollschichten wird nicht betrachtet.

153

Der Nachweis der eingeschränkten Konformität beschränkt sich auf die Beaufschlagung der Kom-munikationsplattform mit Testdaten an den Dienstzugangsschnittstellen, sowie Monitoringaktivi-täten an definierten Messpunkten im Euroradiostack. Für die Stimulation der Dienstzugangsschnittstellen werden Szenarien definiert, die den Standard-abläufen bei der Nutzung der Kommunikationsplattform als Datenübertragungseinrichtung für FFB entsprechen. Die Szenarien sind über verschiedene Parameter an gewünschte Testfälle anpassbar. Darüber hinaus gibt es keine weiteren Stimulationen der Kommunikationsplattform. Der Netzprovider GSM/R-ISDN wird durch ein Kanalmodell nachgebildet, welches das Zeitverhalten eines Datenkanals simuliert. Die Monitoringaktivitäten beschränken sich auf insgesamt drei Messpunkte. An diesen Mess-punkten werden die Protokolle des EURORADIO-Sicherungs-Layers, des EURORADIO-Transport-Layers und des EURORADIO-Link-Layers analysiert. Die Analyse weiterer Protokolle oder Schnittstellen ist nicht vorgesehen. Das Testverfahren zur statischen und dynamischen Konformitätsanalyse besteht in der auto-matischen Analyse und Protokollierung von Abweichungen zum spezifizierten Protokollverhalten. Deshalb erfolgt der Nachweis aller Testrequirements eines Messpunktes indirekt durch fehlerfreien Durchlauf der messpunktbezogenen Testfälle. Ein Einzelnachweis der Testrequirements entfällt damit. Die Nachvollziehbarkeit ist durch Traces gegeben.

6.5.3 Beaufschlagung mit Messszenarien

Zum Nachweis der eingeschränkten Konformität wird die Kommunikationsplattform an seinen Dienstzugangsschnittstellen mit Testszenarien entsprechend der Validierungstests beaufschlagt. Die Stimulation des EURORADIO-Stacks erfolgt durch ein Echtzeit-Testsystem (siehe RTTDOC). Dieses kommuniziert über den Testagent (FRTA) mit der Kommunikationsplattform.

6.5.4 Messpunkte im EURORADIO-Stack

In den EURORADIO-Stack werden an verschiedenen Stellen Module „US_SNIFF“ eingefügt, die jeweils einen Messpunkt repräsentieren.

154

Funk-Stack

ER Protokolle

TR _T.70

TR _ aH D L C

Netzprovider TCP

TR _TR _M U X(TP2)

FRTA

TR _T.70 TR _T.70

TR _ aH D L C TR _ aH D L C

TR-IF

TR_TLI_PORTTR_TLI_PORT TR_TLI_PORT

US _SNIFF TR-IFUS _SNIFF US _SNIFF

US _SNIFF US _SNIFF US _SNIFF

US _SNIFF US _SNIFF US _SNIFF

Abbildung 67: Messpunkte im EURORADIO-Stack

Es sind Messpunkte an folgenden Layern des EURORADIO-Stacks für die eingeschränkte Konfor-mitätsanalyse vorgesehen:

• Messpunkt unterhalb des Linklayers (aHDLC); an diesem Messpunkt wird der bidirektionale Datenstrom von und zum HDLC-Protokoll abgegriffen. Er dient dem Nachweis des konformen Verhaltens des Linklayers.

• Messpunkt unterhalb des Transportprotokolls (TP2); an diesem Messpunkt wird der

bidirektionale Datenstrom von und zum TP2-Protokoll abgegriffen. Er dient dem Nachweis des konformen Verhaltens des Transportlayers.

• Messpunkt unterhalb des Sicherungsprotokolls (= oberhalb des Transportprotokolls); an

diesem Messpunkt wird der bidirektionale Datenstrom vom und zum Safetylayer abgegriffen. Er dient dem Nachweis des konformen Verhaltens des Sicherungsprotokolls.

Meßpunkte Konformitätnachweis

155

6.5.5 Realisierung der Messpunkte

Die EURORADIO-Protokolle der Kommunikationsplattform sind als USER-STREAM-Module realisiert. Für das Tracen des Datenstroms wird ein Sniffermodul („US_SNIFF“) verwendet, das im USER-STREAM als Tracepunkt an verschiedene Stellen eingefügt werden kann. „US_SNIFF“ erhält Konfigurationsmöglichkeiten zur Anpassung an die verschiedenen Protokollebenen und kann somit für verschiedene Tracepunkte im EURORADIO-Stack verwendet werden. Innerhalb der Kommunikationsplattform werden im EURORADIO-Stack mehrere Sniffermodule „US_SNIFF“ konfiguriert. Jede Instanz eines Sniffermoduls bildet eine logische Einheit mit jeweils einer Instanz zur Auswertung der statischen Konformität sowie einer Instanz zur Auswertung der dynamischen Konformität. Die Varianten der Auswertungsinstanzen werden passend zum Tracepunkt konfiguriert. Das Tracemodul verhält sich für den Nutzdatenstrom transparent.

T es tsyste m

U S _ S N IF F

P r o to k o l ls ta c k T R A C E -L o g

E R R O R - L o g

T R A C E -L o g

E R R O R - L o g

C S P - A u to m a tIF M

d yn am ische K onfo rm itä t

P D U E v e n t

S U T

F R T A

P r o v id e r

M o n i t o rD a te n

s ta t is c h e K o n fo rm itä t

Abbildung 68: Komponenten eines Messpunktes

Das „Sniffer-Modul“ ist als USER-STREAM-Konverter realisiert. Der strukturelle Aufbau ist in nachfolgender Abbildung dargestellt.

K o m p o n e n te n e in e s M e ß p u n k te s

156

SUT-Stack

Modul

UP

Down

r_put

putnext

r_put_monw_putputnext

w_put_m on

Mon

itor I

nter

face

R TTM on ito rP lug in

initup_mon_if

close

close_mon

open_mon

open

destructdown_mon_if

Struktur Modul "US_SNIFF"

Abbildung 69: Struktur SNIFFER-Modul

Zur Ankopplung verschiedener Monitorapplikationen wird eine interne Monitor-Plugin-API realisiert. Die folgende Tabelle beschreibt die einzelnen Funktionen der Registrierungsstruktur. Funktionsbezeichnung Beschreibung void us_sniff_up_mon_if(); Das Monitorplugin aktiviert entsprechend

hinterlegter Konfigurationsdaten (us_master_data) Basis-Monitorkanäle zu Monitor-IFM-Modulen.

void us_sniff_down_mon_if(); Das Monitorplugin deaktiviert die Basis-Monitorkanäle zu Monitor-IFM-Modulen.

void *us_sniff_open_mon_if( us_sniff_param_t *param);

Dem Monitorplugin wird das Belegen eines zu überwachenden Kanals (Messpunkt) angezeigt. Entsprechend eines Konfigurationslabels wird der Messpunkt auf den zuständigen Basis-Monitorkanal zugeordnet. Eine Referenz auf die Verwaltungsstruktur des Messpunktes wird der Funktion als Rückgabewert zur Verfügung gestellt.

157

void us_sniff_w_put_mon_if( Dem Monitorplugin wird neben der void *us_sniff_mon_ref, mblk_t *mp);

Verwaltungsstruktur des Messpunktes eine Kopie, einer den Messpunkt in Down-Stream-Richtung durchlaufenden Message, übergeben.

void us_sniff_r_put_mon_if( void *us_sniff_mon_ref, mblk_t *mp);

Dem Monitorplugin wird neben der Verwaltungsstruktur des Messpunktes eine Kopie, einer den Messpunkt in Up-Stream-Richtung durchlaufenden Message, übergeben.

void us_sniff_close_mon_if( void *us_sniff_mon_ref);

Dem Monitorplugin wird die Freigabe eines zu überwachenden Kanals (repräsentiert durch Referenz auf die Verwaltungsstruktur des Messpunktes) angezeigt.

Tabelle 47: Funktionen der Registrierungsstruktur

6.5.6 Statische Konformitätsanalyse

Zur Auswertung der statischen Konformität wird ein „IFM-Modul“ mit folgendem prinzipiellen Aufbau verwendet:

T es tsystem

C S P - A u to m a t 1M o n i to rD a te n

L A N (T C P )

S U T

S ta c k

M P

IF M

rttif

lib

rttif

lib

T R A C E -L o g

P D U - P a r s e r

P D U - L o g

E v e n t- G e n e r a t o r

C S P - A u to m a t 2

C S P - A u to m a t n

E R R O R - L o g

C S P -C h a n n e l

P D UE v e n ts

C h a n n e l-M a p p e r

IF M - A u s w e rtu n g s ta t is c h e K o n fo rm itä t

Abbildung 70: Struktur IFM

Das IFM-Modul hat folgende Komponenten und Funktionen: IFM Komponente Funktion Rttiflib Interface-Bibliothek zur Übertragung der Monitordaten vom

SUT(System unter Test) zum IFM über TCP/IP TRACE-Log Logdatei zum Protokollieren der unbehandelten Monitordaten PDU-Parser Diese SW-Komponente analysiert die Monitordaten entsprechend den

Anforderungen der statischen Konformität des Messpunktes. Die erkannten PDU-Informationen werden an die SW-Komponenete Event-Generator übergeben.

PDU-Log Die empfangenen PDU-Informationen (Protokoll Data Unit) werden in dieser Logdatei abgelegt.

158

ERROR-Log Regelverstöße entsprechend der statischen Konformität der Monitordaten werden in der ERROR-Logdatei aufgezeichnet.

Event-Generator Diese SW-Komponente wandelt die übergebenen PDU-Informationen in PDU-Events und übergibt sie dem Channel-Mapper.

Channel-Mapper In dieser SW-Komponente werden die PDU-Events den zuständigen CSP-Kanälen zugeordnet.

Tabelle 48: Komponenten und Funktionen des IFM

6.5.7 Dynamische Konformitätsanalyse

Die Regeln der dynamischen Konformität des Messpunktes werden über mehrere Ebenen gekoppelter CSP-Automaten abgebildet. Die Kopplung der Automaten untereinander und zum IFM erfolgt mit Hilfe von CSP-Channels.

Testsystem

CSP-Autom at 1

IFM

CSP-Autom at 2

CS P-Autom at n

CSP-C hannel

PDUEvents

Channel-M apper

CSP-ChannelCSP-Channel

CSP-Automat 1.1

CSP-C hannelCSP-C hannel

CSP-Automat 1 .2

CSP-Automat 2.1

CSP-Automat 2 .2

CSP-Automat n.1

CSP-Automat n .2

Basisebene virtuelle Ebene

Abbildung 71: Struktur der Bewertungslogik zur dynamischen Konformität

Jeder einzelne CSP-Automat überwacht zustandsbezogen die ihm übergebenen PDU-Ereignisse und leitet die PDU-Ereignisse in bestimmten Transitionen an andere CSP-Automaten weiter. Verstöße gegen die dynamische Konformität werden vom erfassenden CSP-Automat protokolliert.

6.5.8 Ableitung von Prüfanforderungen

Die Prüfanforderungen zur statischen und dynamischen Konformitätsanalyse werden in mehreren Schritten abgeleitet:

Auswertung dynamische Konformität

159

Analyse der Normentexte – Ableitung von Normenanforderungen: Es werden aus den zugrundeliegenden Normen Normenanforderungen abgeleitet. Dies geschieht indem die Kapitel/Abschnitte/Sätze stichwortartig beschrieben und mit einem Identifikator versehen werden. Anwendbare Anforderungen: Es werden die Normenanforderungen in Beziehung zueinander gesetzt. Dabei kann eine Normenanforderung eine andere deaktivieren, weiter spezifizieren oder überschreiben. Einzelne Normenanforderungen können auch identisch sein. Aus dem Ergebnis werden anwendbare Anforderungen (im Sinne der Konformitätsnachweisstrategie) definiert. Es werden auch die Normenanforderungen identifiziert, die nicht im Rahmen dieser Konformitätsnachweisstrategie prüfbar sind. Die anwendbaren Anforderungen bilden damit eine Teilmenge der Normenanforderungen, die sich aus deren Zusammenfassung und Konkretisierung ergibt. Zu jeder Normenanforderung, die nicht durch eine andere Normenanforderung gelöscht oder überschrieben wurde, wird die resultierende anwendbare Anforderung aufgeführt, in welche diese einfließt. Prüfanforderungen: Es werden aus den anwendbaren Anforderungen Prüfanforderungen (statische und dynamische Konformitätsregeln) abgeleitet. Um die notwendigen Prüfanforderungen lückenlos zu erfassen, kann ein an die FMEA (failure modes and effects analysis) angelehntes Verfahren verwendet werden (siehe [13] Kap. 3.3). Für jede anwendbare Anforderung werden die Fehler identifiziert, die zu einer Verletzung dieser anwendbaren Anforderungen führen. Für jeden Fehler werden die Möglichkeiten aufgeführt, wie sich der Fehler nach außen hin äußert. Diese werden Effekte genannt. Für jeden Effekt wird eine Prüfanforderung definiert, so dass dieser Effekt detektiert werden kann. Die Verletzung einer anwendbaren Anforderung kann sich auf mehrere Arten, d.h. durch die Verletzung verschiedener Prüfanforderungen, äußern. Umgekehrt kann sich auch die Verletzung verschiedener anwendbarer Anforderungen auf die gleiche Art äußern.

6.5.9 Zustandsbezogene Konformitätskriterien

Die Einhaltung der Regeln der dynamischen Konformität (siehe 6.5.7) wird unter anderem in Form von zustandsbezogenen Konformitätskriterien überwacht. Am Beispiel der Prüfstruktur zur Überwachung der dynamischen Konformitätsregeln am Messpunkt unterhalb des Linklayers (aHDLC) des EURORADIO-Protokollstacks wird eine Auswahl an zu-standsbezogenen Konformitätskriterien dargestellt.

6.5.9.1 Struktur der gekoppelten Zustandsautomaten zur Überwachung der dynamischen

Konformitätsregeln

Die folgende Abbildung stellt den prinzipiellen Aufbau der Prüfstruktur zur Überwachung der dynamischen Konformitätsregeln am Messpunkt unterhalb des Linklayers (aHDLC) des EURORADIO-Protokollstacks dar:

160

T es tsys tem

Z u s t a n d s k r i t e r ie n

dynam ische K on fo rm itä t

P D U E v e n tM o n i to rD a te n

s ta t is c h e K o n fo rm itä t

P D U -E v e n t G e n e ra to r

P D U -F ra m e P a rs e r

E R R O R -L o g

F r a m e E r r o r

S t a te E r r o rD u m p

D u m p c h a c h e

M o m e n ta n -z u s ta n d s a b b ild

P D U E v e n t. . .P D U E v e n t. . . . Counterkriterien

Z e itk r ite r ie n

V e rs to ß g e g e nK o n fo rm i tä t

T 1 * T 2 * T n *V 1 * V 2 * V n *

Ü b e rw a c h u n g L in k s ta tu s Ü b e rw a c h u n g F lu ß k o n t ro lleL in k S n d

T r a n s it io n s b e z o g e n e P r ü fa k t iv i tä te n

. . . .

K o m p o n e n te n z u r Ü b e rw a c h u n g d e r d y n a m is c h e n K o n fo rm itä ts re g e ln

Abbildung 72: Prüfstruktur zur Überwachung der dynamischen Konformitätsregeln

Aus der statischen Konformitätsanalyse des Messpunktes (siehe 6.5.6) werden ‚externe’ Ereignisse (PDU Events) generiert und der dynamischen Konformitätsanalyse zugeführt. Diese wirken auf den oder die jeweiligen für die Analyse des Ereignisses zuständigen Zustandsautomaten ein. Werden durch transitionsbezogene Prüfaktivitäten ‚interne’ Ereignisse generiert, wirken diese als interne Wechselwirkung auf den oder die jeweiligen für die Analyse des Ereignisses zuständigen Zustandsautomaten ein. Zeitkriterien werden durch retriggerbare Timer überwacht. Counterkriterien werden durch zusätzliche Zustandsvariablen repräsentiert. Wird durch die Prüfstruktur ein Verstoß gegen eine Konformitätsregel detektiert, wird die Über-wachung auf Konformität für die beteiligten HDLC-Instanzen abgebrochen (EXEPTION) und der Konformitätsverstoß protokolliert. Im Folgenden wird am Beispiel der Zustandsüberwachung des Linkstatus und der sendeseitigen Flusskontrolle das Prinzip für die Umsetzung der notwendigen Prüfbedingungen dargestellt. Die folgende Tabelle gibt einen Überblick der in den aufgeführten transitionsbezogenen Prüf-kriterien verwendeten Zustandsvariablen: Zustandsvariable Bedeutung n_snd Übertragungswiederholungen bezüglich unbestätigter SABM snd. n_rcv Übertragungswiederholungen bezüglich unbestätigter SABM rcv. UNA Ältester unbestätigter Frame. NXT Nächster zu sendender Frame. NR Quittungsnummer aus empfangenen I/S-Frame. NS Quittungsnummer des gesendeten I-Frame.

Tabelle 49: Zustandsvariablen der Prüfstruktur

Die folgende Tabelle gibt einen Überblick der Protokollüberwachungsparameter:

161

Protokollüberwachungs- Bedeutung parameter N2 zulässige Anzahl der Übertragungswiederholungen. T3* Timer 3 zzgl. Korrekturoffset (Bearbeitungszeit, Bitrepräsentanzzeit) k Windowsize

Tabelle 50: Protokollüberwachungsparameter der Prüfstruktur

6.5.9.2 Zustandsüberwachung Linkstatus HDLC

Die Zustandsüberwachung des Linkstatus HDLC ist durch folgende Zustände gekennzeichnet: Zustände Linkstatus HDLC

Bedeutung

CLSD Der Monitorkanal ist geschlossen. I Der Monitorkanal ist geöffnet. Es wurden noch keine PDU`s detektiert. CIPA Die HDLC-Instanz oberhalb des MP hat den Aufbau des HDLC-Links initiert. (aktiv) CIPP Die HDLC-Instanz oberhalb des MP hat die Aufforderung zum Aufbau des HDLC-Links

erhalten. (passiv) C Der HDLC-Link ist etabliert. (Datenübertragungsphase) DIPA Die HDLC-Instanz oberhalb des MP hat den Abbau des HDLC-Links initiert. (aktiv) DIPP Die HDLC-Instanz oberhalb des MP hat die Aufforderung zum Abbau des HDLC-Links

erhalten. (passiv) CONTNE Beide HDLC-Instanzen des HDLC-Links stehen in Konkurrenzsituation. DM Der HDLC-Link ist vollständig abgebaut.

Tabelle 51: Zustände der Linkstatusüberwachung

Folgende Ereignisse wirken auf die Zustandsüberwachung des Linkstatus HDLC ein: Ereignis Bedeutung open mon Der Monitorkanal wird geöffnet. close mon Der Monitorkanal wird geschlossen. SABME snd Die HDLC-Instanz oberhalb des MP sendet einen SABME-Frame. SABME rcv Die HDLC-Instanz oberhalb des MP empfängt einen SABME-Frame. UA snd Die HDLC-Instanz oberhalb des MP sendet einen UA-Frame. UA rcv Die HDLC-Instanz oberhalb des MP empfängt einen UA-Frame. DISC snd Die HDLC-Instanz oberhalb des MP sendet einen DISC-Frame. DISC rcv Die HDLC-Instanz oberhalb des MP empfängt einen DISC-Frame. DM snd Die HDLC-Instanz oberhalb des MP sendet einen DM-Frame. DM rcv Die HDLC-Instanz oberhalb des MP empfängt einen DM-Frame.

Tabelle 52: Ereignisse der Linkstatusüberwachung

6.5.9.2.1 Zustandsübergangsmatrix

Die folgende Tabelle definiert zulässige ereignisabhängige Zustandsübergänge der Linkstatusüber-wachung HDLC:

162

Zustandsübergänge Ausgangszustand Linkstatus HDLC CLSD I CIPA CIPP C DIPA DIPP CONTNE DM Folgezustand CLSD close mon close mon close mon close mon close mon close mon close mon close mon

I open mon DISC rcv

CIPA SABME snd SABME snd DM rcv

SABME snd SABME snd

CIPP SABME rcv SABME rcv SABME rcv SABME rcv SABME rcv SABME rcv SABME rcv

C UA rcv UA snd

DIPA DISC snd DISC snd DISC snd

DIPP DISC rcv DISC rcv DISC rcv DISC rcv

CONTNE SABME rcv DISC rcv

DISC rcv

DM UA snd DM snd

DM snd UA snd UA rcv DISC rcv DM snd

Tabelle 53: Zustandsübergänge der Linkstatusüberwachung

6.5.9.2.2 Transitionsbezogene Prüfaktivitäten

Folgende transitionsbezogenen Prüfaktivitäten werden bei Vorliegen der entsprechenden Voraus-setzung (Zustand des Linkstatus und einwirkendes Ereignis) zur Konformitätsprüfung ausgeführt: Voraussetzung CLSD Ereignis Open mon Prüfaktivität /* Rücksetzen aller Zustandsvariablen*/

n_snd = 0; n_rcv = 0;

Voraussetzung I | CIPA | C Ereignis SABM snd Prüfaktivität n_snd++;

IF (n_snd > N2) THEN EXEPTION; Voraussetzung I | CIPP | C | DIPP | CONTNE | DM Ereignis SABM rcv Prüfaktivität n_rcv++;

IF (n_rcv > N2) THEN EXEPTION; Voraussetzung CIPA Ereignis UA rcv Prüfaktivität n_snd = 0; Voraussetzung CIPP Ereignis UA snd Prüfaktivität n_rcv = 0; Voraussetzung I Ereignis SABME snd Prüfaktivität aktivate(T3*); Voraussetzung I Ereignis SABME rcv Prüfaktivität activate(T3*);

163

Voraussetzung CIPA

164

Ereignis UA rcv Prüfaktivität deactivate(T3*); Voraussetzung CIPP Ereignis UA snd Prüfaktivität deactivate(T3*); Voraussetzung C Ereignis DISC snd Prüfaktivität aktivate(T3*); Voraussetzung C Ereignis DISC rcv Prüfaktivität activate(T3*); Voraussetzung I|CIPA|CIPP|C|DIPA|DIPP|CONTNE|DM Ereignis close mon Prüfaktivität deactivate(T3*); Voraussetzung CIPA Ereignis UA rcv Prüfaktivität put(open snd);

put(open rcv); Voraussetzung CIPP Ereignis UA snd Prüfaktivität put(open snd);

put(open rcv); Voraussetzung C Ereignis close mon|SABME snd|SABME rcv|DISC snd|DISC rcv Prüfaktivität put(close snd);

put(close rcv);

6.5.9.3 Zustandsüberwachung sendeseitige Flusskontrolle

Die Zustandsüberwachung der sendeseitigen Flusskontrolle (sendeseitig bezüglich der HDLC-Instanz oberhalb des MP) ist durch folgende Zustände gekennzeichnet: Zustände sendeseitige Flußkontrolle HDLC

Bedeutung

SND_CLSD Die Prüfinstanz zur sendeseitigen Flusskontrolle ist deaktiviert. SND_READY Die sendeseitige Flusskontrolle ist sendebereit. SND_REJ Die sendeseitige Flusskontrolle befindet sich im Fehlerkorrekturmodus. SND_BUSY Die Windowsize der sendeseitigen Flusskontrolle ist ausgeschöpft.

Tabelle 54: Zustände der sendeseitigen Flusskontrolle

Folgende Ereignisse wirken auf die Zustandsüberwachung der sendeseitigen Flusskontrolle ein:

Ereignis Bedeutung

165

/* NS im Fenster ? – UNA <= NS <= NXT */

open snd Die Prüfinstanz zur sendeseitigen Flusskontrolle wird aktiviert. close snd Die Prüfinstanz zur sendeseitigen Flusskontrolle wird deaktiviert. I snd Die HDLC-Instanz oberhalb des MP sendet einen I-Frame. RNR rcv Die HDLC-Instanz oberhalb des MP empfängt einen RNR-Frame. SREJ rcv Die HDLC-Instanz oberhalb des MP empfängt einen SREJ-Frame. ACK rcv Die HDLC-Instanz oberhalb des MP empfängt eine NR aus I/S-Frame. FULL (intern) Generierung infolge Prüfbedingung (bei I-snd, wenn Windowsize erreicht ist). CONT (intern) Generierung infolge Prüfbedingung (bei ACK rcv, wenn ACK.NR im Sendefenster liegt).

Tabelle 55: Ereignisse der sendeseitigen Flusskontrolle

6.5.9.3.1 Zustandsübergangsmatrix

Die folgende Tabelle definiert die zulässigen ereignisabhängigen Zustandsübergänge der sende-seitigen Flusskontrollüberwachung bezüglich der HDLC-Instanz oberhalb des MP: Zustandsübergänge Ausgangszustand sendeseitige Flusskontrolle HDLC SND_CLSD SND_READY SND_REJ SND_BUSY Folgezustand SND_CLSD close snd close snd close snd

SND_READY open snd CONT ACK rcv I snd

CONT CONT

SND_REJ SREJ rcv FULL ACK rcv SREJ rcv I snd

SREJ rcv

SND_BUSY FULL RNR rcv

ACK rcv RNR rcv

Tabelle 56: Zustandsübergänge der sendeseitigen Flusskontrolle

6.5.9.3.2 Transitionsbezogene Prüfaktivitäten

Folgende transitionsbezogenen Prüfaktivitäten werden bei Vorliegen der entsprechenden Voraus-setzung (Zustand der sendeseitigen Flusskontrollüberwachung bezüglich der HDLC-Instanz ober-halb des MP und einwirkendes Ereignis) zur Konformitätsprüfung ausgeführt: Voraussetzung SND_CLSD Ereignis open snd Prüfaktivität /* Rücksetzen aller Zustandsvariablen*/

UNA = 0; NXT = 0;

Voraussetzung SND_READY|SND_REJ|SND_BUSY Ereignis I snd Prüfaktivität /* Fenster nachführen */

IF( NS == NXT) THEN { /* NXT Aktualisierung */ NXT = (NS+1)%128 ; };

IF( !(( NS – UNA) < ( NXT – UNA)) ) THEN EXEPTION; /* Flusskontolle pruefen */ IF( NXT == (( UNA+k)%128)) THEN { put(FULL); };

Voraussetzung SND_READY|SND_REJ|SND_BUSY Ereignis ACK rcv Prüfaktivität /* NR im Fenster ? – UNA <= NR <= NXT */

IF ( !(( NR – UNA) <= ( NXT – UNA))) THEN EXEPTION; /* UNA Aktualisierung – UNA < NR <= NXT */ IF ((( NR – UNA) < ( NXT – UNA)) || ( NR==NXT)) THEN { UNA = NR; put(CONT); };

6.5.9.4 Überwachung von Zeitkriterien

Innerhalb der dynamischen Konformitätsanalyse werden zeitlich instabile Protokollzustände durch Timer überwacht. Transitionsbezogene Prüfaktivitäten haben die Möglichkeit Überwachungstimer zu aktivieren, zu restarten oder zu deaktivieren. Bei der Festlegung der Überwachungszeiten sind neben den normspezifischen Festlegungen Aufschläge für die systembedingten Verzögerungszeiten (z.B. Bitrepräsentanzzeit auf seriellem Kanal, PDU-Verarbeitungszeit in den HDLC-Instanzen) zu berücksichtigen. Ein Ablauf eines Überwachungstimers ist als ein Verstoß gegen eine Konformitätsregel zu werten. Die Überwachung auf Konformität für die beteiligten HDLC-Instanzen wird auch in diesem Fall abgebrochen.

166

167

Analyse des Protokolldatenstromes des zu testenden Kommunikationsstacks beruht. Die Protokoll-konformität wird dabei messpunktbezogen hinsichtlich statischer Bedingungen (Wohlgeformtheit

7 Zusammenfassung und Ausblick

7.1 Zusammenfassung

In dieser Arbeit wird, orientiert an den Phasen der Systementwicklung (Anforderung – Architektur – Design – Test/Integration), der Entwurf einer Kommunikationsplattform für verteilte Bahn-anwendungen vorgestellt. Der Architekturentwurf der Kommunikationsplattform ist sowohl für die fahrzeugseitige, als auch für die streckenseitige Anwendung als signaltechnisch nichtsicheres Gateway geeignet. Die Koordination des Kommunikationsbedarfs der unterschiedlichen bahntechnischen Anwendungen über eine vorgeschaltete Gatewayinstanz stellt ein wesentliches Entwurfsmerkmal dar. Die konsequente Trennung von signaltechnisch nichtsicheren und sicheren Funktionalitäten und die weitestgehende Entkopplung von Kommunikationsfunktionalitäten aus den bahntechnischen Anwendungen, macht die Nutzung standardisierter Kommunikations-infrastrukturen (wie z.B. GSM/R) und Technologien aus dem Bereich der verteilten Kommunikation möglich. Durch diese Vorgehensweise werden die einzelnen Bahnanwendungen in ihrer Komplexität bezüglich der Übertragungsfunktionalität erheblich reduziert. Durch die Diensteintegration der vorgelagerten Gatewayfunktionalität kann die Ausnutzung der beschränkten Übertragungskapazität der vorhanden Kommunikationsinfrastruktur erheblich gesteigert werden. Die hohen Anforderungen an die Zuverlässigkeit des Gesamtsystems werden durch die Nutzung spezieller ausfalltoleranter Koppelprotokolle und die Verschaltung in redundanten Gatewayclustern erfüllt. Der Vorteil in der Verwendung spezieller Koppelprotokolle besteht in der Kom-plexitätsreduktion auf der signaltechnisch sicheren Seite (im Vergleich zu den EURORADIO-Protokollen). Zur Umsetzung von Vermittlungs- und Protokollfunktionalitäten der vorgeschalteten Gatewayinstanz wurde innerhalb der Kommunikationsplattform ein im USER SPACE ablaufendes Framework mit speziellen Betriebsmitteln entworfen:

• Kapselung von Multiple-Wait- und Zeit-Ereignissteuerung (siehe 5.2.2 und 5.2.3) • nachrichtenorientierte USER STREAM Ablaufumgebung (siehe 5.3.3) • interpretatives Zustandsautomatenmodell (siehe 5.3.1) • Funktionen zur Manipulation variabler Primitivenparameter (siehe 5.3.2).

Zur Validierung der Kommunikationsplattform (Anwendung in FFB-Sytemen) wurde folgende Hardware-in-the-Loop Teststrategie angewandt: Die Tests beruhen auf der Abwicklung von Kommunikationsszenarien, welche das Kommunikationsverhalten der FFB-Applikation nachbilden. Diese Szenarien werden von einer Testumgebung stimuliert und automatisiert geprüft. Neben der Prüfung der Korrektheit der ausgetauschten Daten und der Konsistenz der am Nutzerinterface des Prüflings empfangenen Protokollprimitiven, können auch die Transfers an den Übergängen zwischen den Protokollschichten beobachtet werden. Hierzu wurden die Protokollstacks mit Hilfsmodulen zur Realisierung von Messpunkten erweitert. Die Szenarien können durch Konfiguration hinsichtlich der Anzahl der Prüflinge und des Lastverhaltens (Anzahl virtueller Verbindungen, Dichte der Anforderungen zum Verbindungsaufbau, Menge der übertragenen Daten) modifiziert werden. Für den Nachweis der Konformität wurde ein Konzept entwickelt, welches auf der schichtenweisen

der Telegramme) und dynamischer Bedingungen (Korrektheit des implementierten Zustands-verhaltens) geprüft. Mit Hilfe der in dieser Arbeit vorgestellten Kommunikationsplattform können die beschriebenen systemtechnischen Gesamtanforderungen (siehe 2) abgedeckt werden. In den folgenden Abschnitten wird ein Ausblick über mögliche Erweiterungen der Gatewayfunktionalität zur Vereinfachung der Handhabung bei Einsatz in großen verteilten Anwendungen gegeben. Im Abschnitt 7.3 werden Erweiterungsmöglichkeiten der Konformitäts-nachweisstrategie dargestellt.

7.2 Zusätzliche Gatewayfunktionalitäten

7.2.1 Verteilung von Managementinformationen

Bei der Verwendung der Kommunikationsplattform in FFB-Systemen auf dem Streckennetz der Deutschen Bahn ergibt sich das Problem des Managements großer offener mobiler Kommuni-kationsstrukturen. Die folgende Abbildung zeigt einen Lösungsansatz zur Verteilung von Manage-ment-Informationen unter Nutzung der Kanalpriorität des EURORADIO-Protokollstacks, ohne die hochprioren Zugsicherungsapplikationen zu beeinflussen.

fester Kommunikationsteilnehmer 1


Managementinformationen

Nachbarteilnehmer


mobiler Kommunikationsteilnehmer






Nachbarteilnehmer



Nachbarteilnehmer



Nachbarteilnehmer



Nachbarteilnehmer



Nachbarteilnehmer



Nachbarteilnehmer





fester Kommunikationsteilnehmer 3 fester Kommunikationsteilnehmer 4 fester Kommunikationsteilnehmer 5





fester Kommunikationsteilnehmer 5fester Kommunikationsteilnehmer 4




















zentrale Informationsbasis









Abbildung 73: Verteilung von Managementinformationen auf mobile Kommunikationsteilnehmer

Sämtliche Managementinformationen des Gesamtsystems sind in der zentralen Informationsbasis streckenseitig hinterlegt. Jeder ortsfeste Kommunikationsteilnehmer hat Zugriff auf die zentrale Informationsbasis bzw. stellt einen Teil dieser (dann dezentral organisierten) Informationsbasis dar.

Prinzip zur Verteilung vonManagementinformationen

168

Jeder ortsfeste Kommunikationsteilnehmer stellt neben seinen Managementinformationen auch die Managementinformationen der ortsfesten Nachbarn an der Schnittstelle zu mobilen Kommuni-kationsteilnehmern zur Verfügung. Jeder noch nicht verbundene mobile Kommunikationsteilnehmer verfügt über fest vorgegebene, systemweit geltende Managementinformationen. Mit Hilfe dieser Informationen ist der mobile Kommunikationsteilnehmer in der Lage, die für seinen Aufenthaltsort notwendigen Management-informationen von der zentralen Informationsbasis über Hilfsverbindungen abzurufen. Auf Basis der Managementinformationen kann der mobile Teilnehmer den gewünschten ortsfesten Kommunikationspartner erreichen. Die Zugsicherungsapplikationen können daraufhin Daten aus-tauschen. Im allgemeinen sind die Zugsicherungsapplikationen so dimensioniert, dass durchschnitt-lich nur ein Teil der Nutzdatenkanalkapazität benötigt wird. Der Datenübertragungsbedarf stößt nur bei bestimmten betrieblichen Situationen an die Nutzdatenkanalkapazität (z.B. bei Fahrprofilup-date). Durch diese Auslastungscharakteristik der höherprioren Nutzdatenkanäle und die prioritätsge-steuerten Multiplexmechanismen des EURORADIO-Protokollstacks ist es möglich, niederpriore Managementinformationen quasi im Hintergrund zu übertragen. Somit wird erreicht, dass jeder mobile Kommunikationsteilnehmer über die Managementinfor-mationen seines ortsfesten Kommunikationspartners, sowie dessen Nachbarn verfügt. Beim Ver-bindungsaufbau zum Wechsel des ortsfesten Kommunikationspartners kann von vorliegenden Managementinformationen für die gewünschte Übertragungsstrecke ausgegangen werden. Eine Hilfsverbindung mit zentralen Informationsbasen wird nur in Ausnahmesituationen benötigt.

7.2.1.1 Kommunikationsapplikation zum dynamischen Adressmanagement

Eine Anwendung von im Hintergrund ladbaren Managementinformationen stellt das dynamische Adressmanagement als Kommunikationsapplikation der Kommunikationsplattform dar. Die folgende Abbildung zeigt die Informationsflüsse zwischen den Komponenten.

169

mobiler Kommunikationsteilnehmer (Kommunikationsplattform)

Kommunikationsgateway

KoppelstackAddressmanagement

Vermittlungskern(Transferkern)

EURORADIOProtokollstack

local directory

Kommunikationsapplikationdynamisches Adressmanagement(Updateprozess Informationsziel)

statische Adressmanagementinfo

dynamische Adressmanagementinfo

KoppelstackZugsicherung

zur Zugsicherungsapplikation

ortsfester Kommunikationsteilnehmer (Kommunikationsplattform)

Kommunikationsgateway

KoppelstackAddressmanagement

Vermittlungskern(Transferkern)

EURORADIOProtokollstack

Management-Informationsbasis

Kommunikationsapplikationdynamisches Adressmanagement(Updateprozess Informationquelle)

AdressmanagementinfoNachbarteilnehmer

AdressmanagementinfoKommunikationsplattform

KoppelstackZugsicherung

zur Zugsicherungsapplikation

zur zentralenInformationsbasis

zumNachbarteilnehmer

nied

erpr

iore

r Upd

atek

anal

höhe

rerp

riore

r Zug

sich

erun

gska

nal

Abbildung 74: Informationsflüsse zum dynamischen Adressmanagement

Das Local Directory stellt eine lokale Datenbasis zur Ermittlung von Netzadressvarianten des in der Applikations-ETCS-Adresse festgelegten Kommunikationsziels dar. In kleineren Systemen enthält das Local Directory eines mobilen Kommunikationsteilnehmers alle Netzadressvarianten aller möglicher Kommunikationsteilnehmer. Beim dynamischen Adressmanagement besteht der statische Teil nur aus einer kleinen statischen Datenbasis (Netzadressvarianten zur zentralen Informations-basis). Alle andern Netzadressvarianten werden über die Kommunikationsapplikation zum dyna-mischen Adressmanagement (Updateprozess) über niederpriore Nutzdatenkanäle von ortsfesten Kommunikationsteilnehmern nachgeladen. Die ortsfesten Kommunikationsteilnehmer realisieren ein Informationsabgleich mit den Nachbar-teilnehmern und der zentralen Informationsbasis.

7.2.1.2 Kommunikationsapplikation zum dynamischen Schlüsselmanagement

Signaltechnisch sichere Zugsteuerungsapplikationen, welche den EURORADIO-Protokollstack nutzen, verwenden zur Abwehr von systematischen Störangriffen symmetrische kryptographische Verfahren. Dadurch muss jeder Kommunikationsteilnehmer für alle Kommunikationspartner, mit denen der Kommunikationsteilnehmer Kommunikationsbeziehungen aufnehmen können muss,

dynamisches Adressmanagement

170

kryptographische Schlüssel lokal vorhalten. Die Anzahl der möglichen Kommunikations-beziehungen und damit die Anzahl der vorzuhaltenden kryptographischen Schlüssel wächst mit der Anzahl der Kommunikationsteilnehmer überproportional. Werden die kryptographischen Schlüssel mit Transferschlüsseln verschlüsselt, können diese Informationen als im Hintergrund ladbare Managementinformationen aufgefasst werden. Durch die zeitliche Entkopplung und ortsbezogene Selektion der dynamisch im Hintergrund ladbaren, kryptographischen Schlüsselinformation wird die Setupphase der signaltechnisch sicheren Applikation nicht verlängert.

7.2.2 HTTP – basierte Ansteuerung

Als MMI für Projektierungs- und Maintenanceaktivitäten wird bei der Kommunikationsplattform eine WEB-Browser basierte Lösung angewendet. Als Schnittstelle zur Ansteuerung der Projektierungsscripts wird das CGI-Interface eines HTTP-Servers verwendet. Die benötigten Projektierungsparameter werden über HTTP-Formulare abgefragt und als MIME-kodierte Para-meter an Perl-Scripts zur Parameter-Dekodierung übergeben. Alle erfolgten Projektierungsmani-pulationen werden in XML-codierten Datenstrukturen abgelegt (siehe auch [32]). Die eigentliche Projektierungsmanipulationen erfolgt über Shell-Scripts. Die Bereitstellung von Trace-Information, der upload-Prozess von Trace und Projektierungsinformationen sowie der download-Prozss von vorgefertigten Projektierungsinformationen wird ebenfalls über CGI-Scriptaufrufe gesteuert. Spezielle Clientfunktionen werden als JAVA-Applet (Beispielsweise JAVA-Telnet) zur Verfügung gestellt. Die nachfolgende Abbildung stellt den prinzipiellen Aufbau dar.

Clientsystem (Anwender)

automatischerzeugteHTML-Datei

HTTPD

Kommunikationsplattform

HTTP-Browser

HTML-DateimitFormular

WWW-Server

CGI-Interface

Perl-Script-Ebene

Shell-Script-Ebene

Local-Directory-Management

Betriebssystem-Management

Content-Parameter-Adaption

HTML-Dateimit

Telnet-Applikation Telnet-Server

TELNETD

LD-Script-Interface OS-Script-Interface

JAVA-TelnetApplet

Formular(Request)HTML

HTMLHTML

STDIN STDOUT

script.sh(param) script.sh(param)

script.pl

scrip

t.sh

HTM

L

scrip

t.sh

HTM

L

script.sh(param) STDOUT script.sh(param) STDOUT

TelnetTelnet

Abbildung 75: Struktur HTTP-basierte Ansteuerung

LD – Script – Interface

171

Die folgende Tabelle zeigt die prinzipiell notwendigen Funktionen zum Management der Local Directory Datenbasis (siehe 5.4.4). Script Parameter Beschreibung ld_set_route_entry ETCS_ADDR;

ROUTER_ETCS_ADDR

Im Local Directory wird ein Router-Eintrag zu einem bestimmten Kommunikationspartner vermerkt. Falls ein Router-Eintrag bereits vermerkt war, wird dieser überschrieben.

ld_set_telno_entry ETCS_ADDR; TELNO

Im Local Direktory wird ein Netzvektoreintrag zu einem gegebenen GSM/R Kommunikationspartner ergänzt.

ld_set_ip_entry ETCS_ADDR; CALL_IP

Im Local Direktory wird ein Netzvektoreintrag zu einem gegebenen LAN Kommunikationspartner ergänzt.

ld_erease_entry ETCS_ADDR Alle im Local Direktory vermerkten Netzvektoreinträge zu einem gegebenen Kommunikationspartner werden gelöscht.

Tabelle 57: Managementfunktionen Local Directory

OS – Script – Interface Die folgende Tabelle zeigt die prinzipiell notwendigen Funktionen zum Management der projektierbaren Basiseigenschaften des Betriebssystems der Kommunikationsplattform. Script Parameter Beschreibung os_set_root_fs_rw - Das Root – Filesystem des FBS-Rechners wird auf

READ/WRITE gesetzt und steht nach dem Booten beschreibbar zur Verfügung.

os_set_root_fs_ro - Das Root – Filesystem des FBS-Rechners wird auf READONLY gesetzt und ist nach dem Booten gegen Inkonsistenz geschützt.

os_reboot - Das System wird gebootet.

172

Script Parameter Beschreibung

173

• Stimulation des SUT entsprechend Regelverhalten von FFB-Applikationen

os_set_lan IF_Nr; Hostname; Host-IP-Adresse; Netmask (optional)

Es werden abhängig von der IF_Nr unterschiedliche Manipulationen ausgeführt. IF_Nr = 0: Der übergebene Hostname wird mit der Host-IP-Adresse in /etc/hosts vermerkt. Ein evtl. schon vorhandener Eintrag zum übergebenen Hostnamen wird überschrieben. IF_Nr = 1: Der übergebene Hostname wird mit der Host-IP-Adresse in /etc/hosts vermerkt. Ein evtl. schon vorhandener Eintrag zum übergebenen Hostnamen wird überschrieben. Es wird der übergebene Hostname als Nodename (/etc/nodename) des Systems verwendet. Das erste LAN-Interface erhält die übergebene Host-IP-Adresse, sowie, wenn übergeben, die Netzmaske. IF_Nr >1: Der übergebene Hostname wird mit der Host-IP-Adresse in /etc/hosts vermerkt. Ein evtl. schon vorhandener Eintrag zum übergebenen Hostnamen wird überschrieben. Das n. LAN-Interface erhält die übergebene Host-IP-Adresse, sowie, wenn übergeben, die Netzmaske.

os_set_lan_route_entry Host|Net; Destination; Gateway-IP-Adresse; Metric (optional)

Die übergebenen Informationen werden als Routeeintrag vermerkt.

os_reset_entrys - Das System wird bezüglich der Routeeinträge, LAN-IF – Parameter und Hosteinträge in den Auslieferungszustand zurückgesetzt.

os_get_param - Es werden die im System konfigurierten Einträge ausgegeben.

Tabelle 58: Managementfunktionen Systemprojektierung

7.3 Erweiterung der Konformitätsnachweisstrategie

Der im Rahmen der Systemvalidierung der Kommunikationsplattform durchgeführte Konformitätsnachweis entspricht der unter Abschnitt 6.5 vorgestellten Nachweisstrategie. Um die Komplexität gering zu halten, wurden die Testaktivitäten mit folgenden, von einander unabhängigen Komponenten, durchgeführt:

• Simulation des unterlagerten Kanalmodells entsprechend der zugesicherten QoS-Eigenschaften auf Basis deterministischer Fehlermuster

• Messpunktbezogene Analysesysteme (Konformitätsorakel). Die Unabhängigkeit der einzelnen Testsystemkomponenten, der pseudo-stochastische Charakter des simulierten Kanalmodells und die unsynchronisierte Simulation des Applikationsverhaltens setzten dem Grad der Testabdeckung und der Reproduzierbarkeit von Konformitätsverletzungen gewisse Grenzen. Durch die Koordination von Stimulation, Fehlersimulation und Konformitätsmonitor lässt sich die Durchführung von Konformitätsnachweisen gegenüber unkoordinierter (stochastischer) Betriebsweise optimieren. Eine Vereinfachung des abgeleiteten Regelwerkes und damit eine Verkleinerung des Analyse-Testsystems bietet die Möglichkeit der Integration in das SUT. Durch eine solche Integration kann die Kommunikationsplattform um eine Diagnosefunktionalität erweitert werden, welche ein adaptives Tracen der Kommunikationsaktivitäten ermöglicht. Ein solches Kommunikationssystem kann auch seltene und nur im Feldeinsatz auftretende Fehlerbilder als Tracedaten über lange Zeiträume erfassen. Der Transport von Applikationsdaten durch die Kommunikationsplattform macht ein adaptives Tracen von Applikationsdaten bzw. die Anwendung des Konformitätsnachweiskonzeptes auf Applikationsniveau möglich. Für einen umfassenden Konformitätsnachweis auf Applikationsniveau ist das koordinierte Monitoring weiterer, unterschiedlich ausgeprägter Schnittstellen (z.B. Ortung) notwendig.

174

175

8 Begriffe und Abkürzungen Begriff Erläuterung / Referenz Antwort (response)

Die Antwort ist ein Dienstelement, das vom Dienstbenutzer als Antwort auf ein vorhergehendes Anzeige-Dienstelement verwendet wird.

Anzeige (indication)

Die Anzeige ist ein Dienstelement, das vom Diensterbringer zum Aufruf einer Funktion beim Dienstbenutzer verwendet wird.

API Application Programmer Interface ATM Asynchronous Transfer Mode; http://www.atmforum.com ATO Automatik Train Operation

(signaltechnisch nichtsichere Zugsteuerungsapplikation) ATP Automatik Train Protection

(signaltechnisch sichere Zugsicherungsapplikation) Authentizität Authentizität ist die Eigenschaft einer Information, die zeigt, dass die

Information gültig ist und durch die angegebene Quelle erzeugt wurde. Bestätigung (confirm)

Die Bestätigung ist ein Dienstelement, das vom Diensterbringer als Antwort auf ein vorhergehendes Anforderungs-Dienstelement verwendet wird.

CENELEC Europäisches Komitee für Elektrotechnische Normung; http://www.cenelec.org

CBC-MAC CBC-MAC ist eine kryptographische Berechnungsfunktion, die als Eingangsdaten einen den miteinander kommunizierenden Komponenten bekannten geheimen Schlüssel K Initialisierungsvektor IV und einen beliebigen String der Nutzdaten X verwendet.

Datagrammdienst Low Level Dienst zur physikalischen Übertragung von Datenblöcken. Die Auswahl der jeweiligen konkreten Ausprägung des Datagrammdienstes sollte sich nach dem verwendeten Übertragungsmedium, den Hardwarekomponenten und den Eigenschaften des Betriebssystems richten. In Senderichtung an der Schnittstelle entgegen genommene Nachrichten, so genannte Datagramme erreichen den Empfänger auf der Gegenstelle entweder vollständig oder überhaupt nicht. Der Datagrammdienst enthält Komponenten, die beim Empfang eine Erkennung von Übertragungsfehlern ermöglichen. Während der Übertragung zerstörte Datagramme werden von diesem Dienst verworfen.

Datenelement Ein Datenelement ist eine Nachricht oder ein Teil einer Nachricht. Datenelemente werden zwischen Schichten oder zwischen Partnerinstanzen ausgetauscht.

DIBMOF DiensteIntegrierender BahnMobilFunk deutsches Forschungsprojekt in den Jahren 1989 –1996; BMBF(Bundesministerium für Bildung und Forschung) Fördernummer: 19 R 9404 A

Begriff Erläuterung / Referenz Dienst Ein Dienst ist eine Leistung, die der Diensterbringer der darüber liegenden

Schicht anbietet. (service)

Dienstbenutzer Ein Dienstbenutzer (service user) ist der Benutzer eines durch den Diensterbringer bereitgestellten Dienstes.

Dienstdaten-element

Ein Dienstdatenelement ist ein Datenelement, das über eine am Dienstzugangspunkt bereitgestellte Verbindung transportiert werden soll oder worden ist. (service data unit)

Dienstelement / Dienstprimitiv e

Ein Dienstelement ist eine abstrakte implementierungsunabhängige Interaktion zwischen Dienstbenutzer und Diensterbringer. (service primitive)

Diensterbringer Ein Diensterbringer stellt dem Nutzer einen oder mehrere Dienste bereit. (service provider)

EBA Eisenbahnbundesamt, verantwortlich für die Zulassung von bahntechnischen Systemen

EIRENE europäisches Forschungsprojekt in den Jahren 1997 – 1999; http://eirene.uic.asso.fr

Entität Eine Entität ist eine Komponente im System, die über eine eigene Anwender-Identität (i.a. ETCS-Adresse) verfügt, z. B. Streckenzentrale, Fahrzeuggerät, Feldelement.

Ereignis Ein Ereignis ist ein Geschehen, das in einem gegebenen Kontext eine Bedeutung hat, sich räumlich und zeitlich lokalisieren lässt und einen Zustandsübergang (Transition) veranlasst.

ETCS European Train Control System Europäisch standardisiertes Zugbeeinflussungssystem für den HGV. (siehe auch [22] und [23])

ETCS identifier Der ETCS Identifier (ETCS Identifikator) kennzeichnet zusammen mit ETCS type eineindeutig eine ETCS-Entität.

ETCS type Der ETCS type (ETCS-Typ) kennzeichnet den Typ einer ETCS-Entität. ETCS-Adresse Die ETCS-Adresse kennzeichnet eineindeutig eine ETCS-Entität.

Die ETCS-Adresse ist die Konkatenation von ETCS type und ETCS identifier.

Fehlerursache Abnormaler Zustand, der zu einem Fehler oder einer Fehlfunktion in einem System führen kann. Eine Fehlerursache kann zufällig oder systematisch sein. (fault)

Fehlfunktion Eine Fehlfunktion ist das vom spezifizierten Verhalten abweichende Verhalten des Systems. Eine Fehlfunktion ist die Folge einer Fehlerursache oder eines Fehlzustandes im System. (failure)

Fehlzustand Ein Fehlzustand ist die Abweichung vom beabsichtigten Entwurf, die zu unerwünschtem Systemverhalten oder Fehlfunktion/Ausfall führen kann. (error)

176

Begriff Erläuterung / Referenz

177

Die Datenbasis dient zur Adresskonvertierung im EURORADIO-Stack.

FFB Funkbasierter Fahrbetrieb; Zugbeeinflussungssystem für den RMV Diese Bahnapplikation verwendet neue Ansätze der Zugsicherung durch verteilte Intelligenzen und dezentrale Verriegelungslogik. Fahrzeuggeräte und Feldelemente (Bahnübergänge, Weichen und Schlüsselsperren) tauschen signaltechnisch sichere Informationen über den unterlagerten „grauen“ Kanal aus. Das klassische Stellwerk wird nicht benötigt. Die FFB-Zentrale wird nur zum Herunterladen von Fahrwegsinformationen verwendet. Durch die vielen Kommunikationspartner entsteht eine hohe Signalisierungslast. Diese Signalisierungslast ist vom GSM/R System mit vertretbarem Aufwand nur durch den Einsatz von applikationsbezogenen Gatewaystrukturen zu bewerkstelligen.

FMEA Fault Management and Effects Analyses GW Gateway (Anwendung der Kommunikationsplattform) Gefährdung Eine Gefährdung ist eine Bedingung, die zu einem Unfall führen kann. Grauer Kanal offenes Übertragungssystem;

Übertragungssystem, welches für verschiedene Telekommunikations- dienste genutzt wird, mit einer unbekannten Anzahl von Teilnehmern und mit variablen Eigenschaften (z.B. Weg der Daten, Zeitverhalten, Speicherverhalten). Die Eigenschaften des Übertragungssystems sind aus sicherungstechnischer Sicht nicht vorhersagbar, so dass mit einer Reihe von Bedrohungen für die Datenübertragung im Grauen Kanal gerechnet werden muss. Das Risiko von nichtautorisiertem Zugriff besteht. (siehe EN 50159-2)

HGV Hochgeschwindigkeitsverkehr Zugfernverkehr im Geschwindigkeitsbereich bis 500 km/h mit hoher Verkehrsdichte. Eine linienförmige Zugbeeinflussung, d.h. kontinuierliche Datenübertragung zwischen Zug und Strecke, ist zwingend erforderlich. Es bestehen hohe Anforderungen an Datendurchsatz und Transitdelay infolge potentieller Notwendigkeit der hochprioren Übertragung von Notin-formationen. Im allgemeinen verfügen die eingesetzten Systeme über keine Rückfallebene mit vergleichbarer Performance, was eine sehr hohe Verfügbarkeit voraussetzt.

Information Eine Information ist die Darstellung des Zustandes oder der Ereignisse eines Prozesses in der Form, wie es durch den Prozess verstanden wird.

Integrität Integrität ist die Eigenschaft einer Nachricht, die anzeigt, dass die Information komplett und unverändert ist.

Kanal Ein Kanal ist ein Weg zur Übertragung von Daten. Ein Kanal muss eindeutig identifizierbar sein.

Konfiguration Zusammenstellung von Protokollschichten zu Protokollstacks und Festlegung der Protokollparameterwerte (z.B. Windowsize des Link-protokolls)

Link Ein Link ist die physikalische Verbindung zwischen zwei Geräten. Local Directory Nichtflüchtige Datenbasis zur Zuordnung von Netzadressen (GSM/R

Telefonnummer und Service) zu gegebener (ETCS) Applikationsadresse.


178

provider) bereitgestellten Dienstes.


Schalenförmig strukturierte softwaretechnische Ablaufumgebung zur Umsetzung von ereignisbezogenen, zustandsbehafteten und gatewayorientierten Vermittlungsstrukturen auf Basis schichtenförmiger Protokollstacks.

Verbindung, logische

Eine logische Verbindung ermöglicht während einer Sitzung die Kommunikation zwischen 2 Nutzern; Sie benutzt dazu einen Kanal.

Manipulations-entdeckungscode (MDC)

MDC ist eine Funktion von der gesamten Nachricht, aber im Gegensatz zum MAC ist kein geheimer Schlüssel einbezogen worden. Mit der gesamten Nachricht sind auch implizite Daten der Nachricht gemeint, die nicht zum Übertragungssystem gesendet werden.

MS Mobile Station – Mobiles Endgerät inkl. MT2 – Anschluss (Nutzdateninterface)

Nachricht Eine Nachricht ist eine Information, die von einem Sender (Datenquelle) zu einem oder mehreren Empfängern (Datensenke, Datensenken) übertragen wird.

Nachricht, ausgelassene

Eine ausgelassene Nachricht ist eine Nachricht, die aus dem Nachrichtenstrom entfernt wurde.

Nachricht, authentische

Eine authentische Nachricht ist eine Nachricht, von deren Information bekannt ist, dass sie durch die angegebene Quelle erzeugt wurde.

Nachricht, eingefügte

Eine eingefügte Nachricht ist eine Nachricht, die zusätzlich in den Datenstrom eingefügt wurde.

Nachricht, gültige Nachricht, deren Form in jeder Hinsicht den spezifizierten Anforderungen des Nutzers entspricht.

Nachricht, manipulierte

Eine manipulierte Nachricht ist eine eingefügte Nachricht, bei der eine nichtauthentische Nachricht so entworfen wurde, dass sie authentisch erscheint.

Nachricht, resequenzierte

Eine resequenzierte Nachricht ist eine Nachricht, deren Platz in einem Nachrichtenstrom verändert wurde.

Nachricht, verfälschte

Eine verfälschte Nachricht ist eine Nachricht, bei der eine Datenver-fälschung vorliegt.

Nachricht, verzögerte

Eine verzögerte Nachricht ist eine Nachricht, die später als erwartet empfangen wird.

Nachricht, wiederholte

Eine wiederholte Nachricht ist eine Nachricht, die mehr als einmal empfangen wurde.

Nachrichten-Authentifizierung

Die Nachrichten-Authentifizierung ist ein Verfahren zur Beglaubigung der Herkunft und der Integrität von Nachrichten.

Nachrichten-authentifi-zierungscode (MAC)

MAC ist eine kryptographische Funktion von der gesamten Nachricht und eines geheimen oder öffentlichen Schlüssels. Mit der gesamten Nachricht sind auch implizite Daten der Nachricht gemeint, die nicht zum Übertragungssystem gesendet werden.

Netzwerkformat Netzwerkformat ist ein Format zur Speicherung von Werten mit einer Länge von mehr als ein Oktett (Byte). Dabei erhält das Oktett(Byte) mit der niederwertigsten Adresse den höchstwertigen Wert.

Nutzer Ein Nutzer ist der Benutzer eines durch den Diensterbringer (service


179

(interface control information)

OS-KERNEL UNIX-Betriebssystemkern, stellt POSIX-konforme Systemaufrufe zur Verfügung.

Partnerinstanz-Authentifizierung

Die Partnerinstanz-Authentifizierung ist ein Verfahren zum Nachweis, dass die Partnerinstanz bei einer Verbindung die geforderte ist.

Partnerinstanzen Partnerinstanzen sind Instanzen der selben Schicht. Projektierung Auswahl von vorkonfigurierten Kommunikationsstacks und

Zusammenstellung zu einer Vermittlungslogik (Gatewayinstanz). Protokoll Ein Protokoll gibt die Regeln für den Datenaustausch zwischen

Partnerinstanzen vor. PDU (Protokolldaten-element)

Ein Protokolldatenelement ist ein Datenelement, das zwischen den Partnerinstanzen einer Schicht zur Abwicklung von Protokollen ausgetauscht wird, wobei die Dienste der darunter liegenden Schichten genutzt werden. (protocol data unit)

Protokollnutz-datum

Ein Protokollnutzdatum ist der Teil des Protokolldatenelementes, der die Daten enthält, die im Rahmen des durch die Schicht zu erbringenden Dienstes zu transportieren sind. (user data)

Protokollsteuer-datum

Ein Protokollsteuerdatum ist der Teil des Protokolldatenelementes, der zur Koordinierung der Partnerinstanzen benötigt wird. (protocol control information)

RMV Regionalverkehr Zugverkehr im Geschwindigkeitsbereich von 0 bis 160 km/h mit geringer Verkehrsdichte. Moderate Forderungen an die Systemverfügbarkeit der Zugsicherungssysteme des RMV führen zu kostengünstigen und dezentralen Lösungen.

S2M 2 Mbit Primärmultiplexendteilnehmeranschluss; Primärratenanschluß ETSI: http://www.etsi.org Technische Richtlinien der Deutschen Telekom AG: 1TR237, " Spezifikation der Schnittstelle S2M zwischen Endeinrichtung und Netzabschluss beim Primärmultiplexanschluss im Euro-ISDN" Stand 11/1995

Schicht Eine Schicht ist die Gesamtheit der Teilsysteme der gleichen Stufe aller kommunizierenden Systeme im Bereich des Bezugsmodells. (layer)

Schnittstellen-datenelement

Ein Schnittstellendatenelement ist ein Datenelement, das zwischen den Instanzen zweier übereinander liegender Schichten ausgetauscht wird. (interface data unit)

Schnittstellen-nutzdatum

Ein Schnittstellennutzdatum ist der Teil des Schnittstellendatenelementes, der die Nutzdaten des Dienstbenutzers enthält, die über eine am Dienstzugangspunkt bereitgestellte Verbindung transportiert werden. (interface data)

Schnittstellen-steuerdatum

Ein Schnittstellensteuerdatum ist der Teil des Schnittstellendatenelemen-tes, der zur Koordinierung der durch einen Dienstzugangspunkt verbun-denen Instanzen benötigt wird.

Begriff Erläuterung / Referenz Sicherer Zustand Der sichere Zustand einer signaltechnisch sicheren Einrichtung ist eine

Abweichung von fehlerfreien Zustand als Resultat einer Sicherheits-reaktion, die zu einer reduzierten Funktionalität der signaltechnisch sicheren und möglicherweise nichtsicheren Funktionen führt.

Sicherheits-reaktion

eine Aktion, die vom Sicherheitsprozess als Antwort auf ein Ereignis (wie ein Ausfall eines Kommunikationssystems) ausgelöst wird. Diese führt zum sicheren Zustand der Einrichtung. sicherheits-relevant Ein System, ein Teilsystem oder eine Komponente ist sicherheitsrelevant, wenn es/sie Sicherheitsverantwortung trägt.

Sicherungsschicht Die Sicherungsschicht ist die Schicht, die Dienste zur Übertragung von zu sichernden Nutzernachrichten sowie zur Übertragung von hochprioren, nicht zu sichernden Nachrichten bereitstellt. (safety layer)

SIL 4 Safety Integrity Level 4 (höchste Sicherheitsanforderungsstufe) nach EN 50128

Socket API zum Netzwerkzugang – siehe [7], [8], [11] STREAMS Nachrichtenwarteschlangenbezogene Ablaufumgebung; siehe auch:

UNIX System V Release 4.0: Leitfaden für Programmierer: STREAMS Version 1.0, SIEMENS AG, 1992

TLI Transport Layer Interface – Transportdienstschnittstelle unter UNIX - siehe [7], [8], [11]

Treiber/ Device-Treiber

Softwarekomponente zur Adaption von Hardwarekomponenten an die Betriebsmittelschnittstellen des Betriebssystems (z.B. ASY-Treiber zur Adaption der V24 – Schnittstelle)

TTY Terminal device – Treiberzugang zum asynchronen seriellen Interface (z.B. com bei PC-Architektur)

UNISIG Zusammenschluss europäischer Signalbaufirmen mit dem Ziel der Erstellung von Vorschlägen für Standards und Vorschriften der Eisenbahnsignaltechnik im Rahmen der Europäischen Union; http://www.aeif.org

Verbindung Eine Verbindung ist die Kommunikationsbeziehung zwischen Partner-instanzen. (connection)

Tabelle 59: Begriffe und Referenzen

180

181

Nennspannungen bis 1000 V, 31.05.73, VDE [DIN VDE 0110] Isolationskoordination für elektrische Betriebsmittel in

9 Normen und Standards

Norm / Standard Erläuterung [EURORADIO] EURORADIO FIS, Subset-037, 2.0.0, 30-Mar-2000 [GSM05.05] 3GPP TS 05.05: "Digital cellular telecommunications system (Phase 2+)"

3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Radio transmission and reception (Release 1999)

[POSIX] Portable Open System Interface Unix; International Standard 9945-1

[EN50081-2] Elektromagnetische Verträglichkeit (EMV) Fachgrundnorm Störaussendung Teil 2: Industriebereich, 08/1993, CENELEC

[EN50082-2] Elektromagnetische Verträglichkeit (EMV) Fachgrundnorm Störfestigkeit Teil 2: Industriebereich, 03/1995, CENELEC

[EN 50121] Railway Applications: Electro-Magnetic Compatibility (EMC) Teil 1-4, 09/2000, CENELEC

[EN 50123] Bahnanwendungen – Ortsfeste Anlagen – Gleichstrom-Schalteinrichtungen, 31.05.95, CENELEC

[PrEN 50124] Railway Applications: Insulation Coordination, Teil 1: 04/1999, Teil 2: 04/1998, Pr, CENELEC

[EN 50125] Railway Applications: Environmental Conditions for Rolling Stock, 09/1999, CENELEC

[EN 50128] Bahnanwendungen – Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme - Software für Eisenbahnsteuerungs- und Überwachungssysteme; 2001-03-01 DIN EN 50128 * VDE 0831 Teil 128 / 01.11.2001/ Deutsche Fassung EN 50128:2001

[EN 50155] Railway Applications: Electronic Equipment Used on Rail Vehicles, 30.11.95, CENELEC

[EN 50159-2] bahnanwendungsbezogene Norm: Bahnanwendungen Teil 2: Sicherheitsrelevante Kommunikation in offenen Übertragungssystemen, 03/2001

[EN 60721] Klassifizierungen von Umweltbedingungen Teil 3, 31.07.93, CENELEC [EN ISO 9000-3] DIN EN ISO 9000-3 Normen zum Qualitätsmanagement und zur

Qualitätssicherung/QM-DarlegungTeil 3: Leitfaden für die Anwendung von ISO 9001 auf Entwicklung, Lieferung, Installierung und Wartung von Computer-Software, Zweisprachige Fassung, August 1998

[DIN VDE 800] Fernmeldetechnik; Übergangsfestlegungen für Errichtung und Betrieb der Anlagen, 31.03.93, VDE

[DIN VDE 804] Fernmeldetechnik; Zusatzfestlegungen für die Herstellung und Prüfung der Geräte, 31.05.89, VDE

[DIN VDE 0100] Bestimmungen für das Errichten von Starkstromanlagen mit

Norm / Standard Erläuterung Niederspannungsanlagen, 30.04.94, VDE

[DIN VDE 0115-1] Bahnen, Allgemeine Bau- und Schutzbedingungen, 30.06.82, VDE [DIN VDE 0470] Schutzarten durch Gehäuse (IP Code) (auch als IEC 60529 und EN

60529), 31.03.92, VDE [DIN VDE 0831] Elektrische Bahn-Signalanlagen, 31.08.90, VDE [ISO/IEC 2110] Information technology - Data communication - 25-pole DTE/DCE

interface connector and contact number assignments, 1989-12, International Electrotechnical Commission

[IEC 60571] Elektronische Einrichtungen zur Verwendung auf Schienenfahrzeugen, 07.90, IEC

[MAP3.0/ CIRNET] MAP/MMS – Protokoll verwendet in der Automatisierungstechnik (siehe IS0 9506) CIRNET – kryptologische Erweiterung auf Basis MAP3.0 zur einkanalig signaltechnisch sicheren Datenübertragung (z.B. Stellwerkskopplung) über geschlossene Netze (Leitungen der DB AG) (siehe Pflichtenheft der Übertragungsprozedur für die LAN-Kopplung ESTW-LZB; DB AG – GB Netz – Technik / Projekte – NGT 444 vom 24.02.94; Geprüft und genehmigt am 30.08.95: Eisenbahn – Bundesamt Außenstelle München GZ: 7011 SSR(LAN) )

[RTCA DO 178B] Software Considerations in Airborne Systems and Equipment Certification; http://www.rtca.org

[Mü 8004] Technische Anforderungen an Sicherungsanlagen der Elektronik, Eisenbahn-Bundesamt

[X.208] ITU-T rec. X.208; Specification of Abstract Syntax Notation One (ASN.1) T-REC-X.208-198811-W http://www.itu.int/

[X.209] ITU-T rec. X.209; Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1) T-REC-X.209-198811-W http://www.itu.int/

Tabelle 60: Normen und Standards

182

10 Literaturangaben Referenz Quellenangabe [1] DIBMOF

BMBF(Bundesministerium für Bildung und Forschung) Fördernummer: 19 R 9404 A

[2] EIRENE http://eirene.uic.asso.fr

[3] CENELEC http://www.cenelec.org

[4] UNISIG http://www.aeif.org

[5] D.P. Bovet, M. Cesati: Understanding the Linux kernel, 1st edition. O'Reilly & Associates, 2001

[6] U. Vahalia: Unix Internals - The New Frontiers, Prentice Hall 1996. [7] A. Tanenbaum: Modern Operating Systems, 2nd edition. Prentice Hall,

2001 [8] A. Tanenbaum: Moderne Betriebssysteme, Hanser 1995 [9] A. Tanenbaum, A. S. Woodhull: Operating Systems: Design and

Implementation, 2nd edition. Prentice Hall, 1997.

[10] A. Tanenbaum: Distributed Operating Systems, Prentice Hall 1995 [11] W.R. Stevens: Unix Network Programming, Prentice Hall 1990. [12] Alessandro Rubini: Linux Gerätetreiber, O’Reilly 1998 [13] N.Storey: Safety-Critical Computer Systems, Addison Wesley Longman

1996 [14] Berny Goodheart, James Cox: UNIX System V Release 4 –

Reise durch den Zaubergarten, Prentice Hall Verlag GmbH München, 1994. ISBN 3-930436-05-1

[15] Steve Schneider: An Operational Semantics for Timed CSP. Information and Computation, 116:193-213

[16] Michael Schronen: Methodology for the Development of Microprocessor-Based Safty-Critical Systems. Dissertation, Universität Bremen, Sep. 1998 Published in Gogolla et al. (Eds.): Monographs of the Bremen Institute of Safe Systems, Volume 8. Shaker Verlag, ISBN 3-8265-4521-4

[17] Claudia Eckert: IT-Sicherheit: Konzepte, Verfahren, Protokolle 2. überarbeitete und erweiterte Auflage, R. Oldenbourg Verlag, 2003 ISBN 3-486-27205-5

[18] Dokumentation RT-Tester (RTTDOC) http://www.verified.de

183

Referenz Quellenangabe

184

GSM-R-Verkehrsmodell für den FunkFahrBetrieb

[19] Abstract Syntax Notation One (ASN.1) Basic Encoding Rules (BER) ITU-T rec. X.208; ILC-Verfahren (Identifier, Length, Content): ITU Rec. X.209 http://www.itu.int/ITU-T/asn1/index.html

[20] Dirk Haselmeyer, Holm Hofestädt, Reinhard Kraftschik: SIMIS FFB - FunkFahrBetrieb zur EXPO 2000 SIGNAL + DRAHT 10/2000 http://www.eurailpress.com/archiv/

[21] Olaf Mense: European Train Control System – Von der UNISIG-Spezifikation zur Pilotanwendung SIGNAL + DRAHT 01+02/2003 http://www.eurailpress.com/archiv/

[22] A. Janhsen, K. Lemmer, M. Meyer zu Hörste, E. Schnieder: Migration strategy for different levels of the European Train Control system to existing railway environment World Congress on Railway Research, Florence, 1997, Volume C, pp 335 - 341.

[23] M. Meyer zu Hörste: Die formale Modellierung und Simulation von ERTMS / ETCS auf der Basis von Petrinetzen FORMS ' 98, Braunschweig, 1998.

[24] Hill, P.: Funkmessungen für den Aufbau des GSM-R-Netzes SIGNAL + DRAHT 10/2000 http://www.eurailpress.com/archiv/

[25] Referenzfallstudie Verkehrsleittechnik: funkbasierte Bahnübergangs-steuerung Dipl.-Inform. L. Jansen: TU Braunschweig http://www.iva.ing.tu-bs.de/forms/aktuell/workshops/2000/fallbeispiele/ funk_bahnubergang.pdf

[26] Anne E. Haxthausen and Jan Peleska: Formal Development and Verification of a Distributed Railway Control System. IEEE Transactions on Software Engineering Vol. 26, No. 8, pp. 687-701, 2000.

[27] Anne E. Haxthausen and Jan Peleska: Formal Methods for the Specification and Verification of Distributed Railway Control Systems: From Algebraic Specifications to Distributed Hybrid Real-Time Systems. In E. Schnieder (Ed.): Forms '99 - Formale Techniken für die Eisenbahnsicherung. Fortschritt-Berichte VDI, Reihe 12, Nr. 436, VDI-Verlag, Düsseldorf, pp. 263-271, 2000.

[28] Hillenbrand, W.; Hofestädt, H:

185

Referenz Quellenangabe SIGNAL + DRAHT 06/2001 http://www.eurailpress.com/archiv/

[29] Stein, F.; Kendelbacher, D.: EURORADIO – Kommunikationsbasissystem für ETCS SIGNAL + DRAHT 6/2002 (Teil 1) SIGNAL + DRAHT 7+8/2002 (Teil 2) http://www.eurailpress.com/archiv/

[30] Denecke, F.: EI S Public net – Das Elektronische Stellwerk mit Datenübertragung über „Öffentliche Netze“ DER EISENBAHNINGENIEUR 12 / 2002 S. 58 http://www.eurailpress.com/archiv/

[31] Roland Passern: Datenübertragung in elektronischen Stellwerken über öffentliche Netze SIGNAL + DRAHT 11/2002 http://www.eurailpress.com/archiv/

[32] Jens Eisen; Egbert Voigt: XML-basierte Prüfung der RBC-Streckenprojektierung SIGNAL + DRAHT 05/2003 http://www.eurailpress.com/archiv/

Tabelle 61: Literaturangaben

Architekturkonzept und Designaspekte einer...

Documents

Transcript of Architekturkonzept und Designaspekte einer...