Wandlermodul und Verfahren zum Umwandeln von Softwareprotokollformaten

Die Erfindung betrifft ein Wandlermodul, im Speziellen ein Wandlermodul und ein

Verfahren zum Umwandeln von unterschiedlichen Softwareprotokollformaten in ein

Protokoll-unabhängiges Nachrichtenformat (Protocol Independent Message Format: PIMF) und zum Umwandeln von dem Protokoll-unabhängigen Nachrichtenformat in die

unterschiedlichen Softwareprotokollformate.

In Maschinen oder Fahrzeugen werden Steuerungssysteme verwendet, um verschiedene Baugruppen über Subsysteme des Steuerungssystems anzusteuern. In Zügen wird insbesondere ein Zugsteuerungs- und Verwaltungssystem (Train Control and

Management System: TCMS) verwendet, um sämtliche Zug-Subsysteme zu steuern.

Beispielsweise werden damit ein Klimatisierungssystem, ein Türsteuerungssystem, ein Lichtsteuerungssystem, ein Passagier-Informationssystem, ein Notfall- Kommunikationssystem oder eine Bremsensteuerungseinheit angesteuert. Das TCMS spielt eine zentrale Rolle bei der Ansteuerung und Verwaltung der Subsysteme und ist deshalb auch ein sogenanntes "Gehirn des Zugs".

Eine Standardisierung von Schnittstellen zwischen dem TCMS und anderen Zug- Subsystemen wäre für Hersteller, Lieferanten und Nutzer wünschenswert, um einen größeren Bereich von übereinstimmenden Systemen in Betracht ziehen zu können und die Integrationskosten zu verringern. Jedoch sind die "Standard-Schnittstellen" in

Abhängigkeit von Kundenanforderungen sehr verschieden, was unterschiedliche

Protokolle (z.B. Multifunction Vehicle Bus (MVB), High-Ievel Data Link Control (HDLC), Common Industrial Protocol (CIP) oder Train Realtime Data Protocol (TRDP)) und unterschiedliche physikalische Schichten bedeutet.

Die der Erfindung zugrunde liegende Aufgabe ist es also, die obigen Probleme zu lösen, und eine Anbindung von Subsystemen in einem Netzwerk zu flexibilisieren. Die Aufgabe wird durch ein Wandlermodul gemäß Anspruch 1 , ein Subsystem gemäß Anspruch 7 und ein Verfahren gemäß Anspruch 10 gelöst. Weiterentwicklungen der Erfindung sind Gegenstand der abhängigen Ansprüche.

Durch einen Einsatz eines Wandlermoduls zum Umwandeln von unterschiedlichen

Softwareprotokollformaten in ein Protokoll-unabhängiges Nachrichtenformat, und zum Umwandeln des Protokoll-unabhängigen Nachrichtenformats in die unterschiedlichen Softwareprotokollformate ist es möglich, ein Protokoll-unabhängiges Nachrichtenformat zu verarbeiten, während mit Subsystemen über deren Protokoll kommuniziert wird. Dabei ist es möglich, die Verarbeitung von Daten in dem Protokoll-unabhängigen Nachrichtenformat unabhängig von der Art des durch das Subsystem verwendeten Protokolls durchzuführen, so dass, bei einem Austausch des Subsystems oder bei einer Integration eines

zusätzlichen Subsystems mit einem bisher unbekannten Protokoll, eine Software, die das Protokoll-unabhängige Nachrichtenformat verarbeitet, nicht angepasst werden muss.

Dadurch kann der Entwicklungsaufwand für die das Protokoll-unabhängige

Nachrichtenformat verarbeitende Software reduziert werden und sie kann einfacher validiert werden

In einer vorteilhaften Weiterentwicklung ist es möglich, dass das Wandlermodul Daten mehrerer Softwareprotokollformate, beispielsweise MVB, HDLC, CIP oder TRDP, parallel in das Protokoll-unabhängige Nachrichtenformat umwandelt, was bedeutet, dass es nicht erforderlich ist, zusätzliche Komponenten für diesen Zweck zu entwickeln und zu betreiben.

Durch eine vorteilhafte Ausbildung des Wandlermoduls, können Datenblöcke der

Softwareprotokollformate zuverlässig in Datenblöcke umgewandelter Bitdatenströme in dem Protokoll-unabhängigen Nachrichtenformat umgewandelt werden.

In einer vorteilhaften Weiterentwicklung ist das Wandlermodul ausgebildet, in einem Stapel des Softwareprotokollformats definierte Anweisungen, wie "Start" und oder "Stopp" und/oder "Konfiguration" und/oder "Zurücksetzen", die in jedem Protokollstapel definiert und implementiert sind, umzuwandeln, so dass diese Anweisungen einfach übertragen werden können.

Vorteilhafterweise kann das Wandlermodul mit einem Zugsteuerungs- und

Verwaltungssystem verbunden werden, um so Datenströme von Subsystemen eines Zugs in das Protokoll-unabhängige Nachrichtenformat umzuwandeln und somit die Daten der unterschiedlichen Subsysteme in dem Protokoll-unabhängigen Nachrichtenformat zu verarbeiten.

Wenn das Wandlermodul in einer weiteren vorteilhaften Ausführung ausgebildet ist, mit einer Funktionsapplikation verbunden zu sein, ist es möglich, dass in das Protokollunabhängige Nachrichtenformat umgewandelte Daten von unterschiedlichen

Subsystemen durch die Funktionsapplikation verarbeitet werden.

Durch das Vorsehen des Subsystems mit dem Wandlermodul kann das Subsystem vorteilhafterweise die Protokolle von anderen Subsystemen in entsprechende

Anweisungen für Funktionen verarbeiten.

In einer vorteilhaften Ausgestaltung des Subsystems ist es mit einem Steuerungsteil und einem Kommunikationsteil versehen, und das Steuerungsteil ist über das Wandlermodul mit dem Kommunikationsteil verbunden.

Durch diese funktionale Trennung ist es möglich, Daten in dem Protokoll-unabhängigen Nachrichtenformat in dem Steuerungsteil des Subsystems zu verarbeiten, was eine Entwicklung und Validierung der Software in dem Steuerungsteil vereinfacht, während das Kommunikationsteil des Subsystems mit den anderen Subsystemen über deren Protokoll kommuniziert.

Dabei ist es möglich, die Verarbeitung von Daten in dem Steuerungsteil unabhängig von dem durch das Subsystem verwendeten Protokoll durchzuführen, so dass bei einem Austausch des Subsystems eine Kernsoftware des Steuerungsteils nicht angepasst werden muss.

Durch das Vorsehen eines Zugsteuerungs- und Verwaltungssystems mit dem damit verbindbaren Wandlermodul können Anpassungen an unterschiedliche Subsysteme des Zugsteuerungs- und Verwaltungssystems einfach durchgeführt werden.

Mit einer Anwendung eines Verfahrens zum Umwandeln von Datenformaten ist es möglich, das Protokoll-unabhängige Nachrichtenformat zu verarbeiten, während mit den Subsystemen über deren Protokoll kommuniziert wird. Dabei ist es möglich, die

Verarbeitung von Daten in dem Protokoll-unabhängigen Nachrichtenformat unabhängig von der Art des durch das Subsystem verwendeten Protokolls durchzuführen. Bei einem Austausch des Subsystems muss daher eine das Protokoll-unabhängige

Nachrichtenformat verarbeitende Software nicht angepasst werden. Dadurch kann der Entwicklungsaufwand für die das Protokoll-unabhängigen Nachrichtenformat verarbeitende Software reduziert werden und sie kann einfacher validiert werden.

In einer vorteilhaften Weiterentwicklung des Verfahrens werden in einem Stapel des Protokollformats implementierte Anweisungen übertragen. Die Anweisungen sind beispielsweise "Start", "Stopp", "Konfiguration" und "Zurücksetzen". Dadurch kann die Verwaltung der Subsysteme vereinfacht werden.

Wenn in einer vorteilhaften Weiterentwicklung des Verfahrens die Datenblöcke der Softwareprotokollformate in das Protokoll-unabhängige Nachrichtenformat umgewandelt werden, kann ein in die Datenblöcke umgewandelter Bitdatenstrom zuverlässig in das Protokoll-unabhängigen Nachrichtenformat umgewandelt werden

Die Erfindung wird nun anhand eines Ausführungsbeispiels unter Bezugnahme auf die beigefügten Zeichnungen erläutert.

Insbesondere zeigen:

Fig. 1 eine schematische Ansicht eines Zugsteuerungs- und Verwaltungs- (TCMS)

Netzwerks; und

Fig. 2 ein Blockschaltbild eines TCMS-relevanten Teils eines Subsystems eines Zugs.

Fig. 1 zeigt eine schematische Ansicht eines Zugsteuerungs- und Verwaltungssystem- (TCMS-) Netzwerks 1 als ein Beispiel für ein Computernetzwerk. In dem TCMS-Netzwerk 1 sind mehrere Subsysteme enthalten. Als Subsysteme sind eine

Bremsenansteuerungseinheit (Brake Control Unit: BCU) 2, ein Klimatisierungssystem (Heating - Ventilation - Air Conditioning: HVAC) 3, ein Türsteuerungssystem 4 und ein Lichtsteuerungssystem 5 dargestellt. Weiterhin können auch beispielsweise ein

Passagierinformationssystem, ein Videoüberwachungssystem und ein Alarmsystem in dem TCMS-System enthalten sein.

Durch das TCMS-Netzwerk 1 sind die Subsysteme 2, 3, 4, 5 miteinander verbunden, wobei sie über eine jeweilige Datenschnittstelle über das TCMS-Netzwerk 1 miteinander kommunizieren. Dabei werden unterschiedliche Softwareprotokolle verwendet.

Beispielsweise werden die Protokolle Multifunction Vehicle Bus (MVB), High-Ievel Data Link control (HDLC), Common Industrial Protocol (CIP) oder Train Realtime Data Protocol (TRDP)) verwendet, und auch unterschiedliche physikalische Schichten (z.B. RS485 oder Ethernet) werden genutzt.

Fig. 2 zeigt ein Blockschaltbild eines TCMS-relevanten Teils eines der Subsysteme, nämlich der Bremsenansteuerungseinheit 2 eines Zugs. Die Bremsenansteuerungseinheit 2 ist nur exemplarisch dargestellt; alternativ können auch die anderen Subsysteme des Zugs einen identischen oder ähnlichen Aufbau aufweisen. In dem Blockschaltbild ist ein sogenanntes "Central Intelligent Device" (CID) als die Bremsenansteuerungseinheit 2 dargestellt. Alternativ können auch mehrere CIDs vorgesehen sein. Ferner ist auch ein sogenanntes "Local Application Device" (LAD) 6 gezeigt, wobei alternativ auch mehrere LADs 6 vorhanden sein können. Das CID bestimmt beispielsweise eine

Bremskraftverteilung, während die LADs 6 beispielsweise verschiedene Eingangs- und Ausgangssignale verwalten, Daten sammeln, mechanische Aktoren 7, beispielsweise Bremseinrichtungen, abstimmen und für ein Ausführen von einzelnen Anwendungen, beispielsweise von einem Radgleitschutz, zuständig sind.

Die Bremsenansteuerungseinheit 2 besteht aus einem Steuerungsteil 8 und einem

Kommunikationsteil 9, von denen jeder zumindest einen Prozessor aufweist. Alternativ sind keine separaten Prozessoren für den Steuerungsteil 8 und den Kommunikationsteil 9 vorgesehen, sondern ein sogenannter multicore-Prozessor kann beispielsweise verwendet werden, wobei mindestens ein Prozessorkern für die Kommunikation und mindestens ein Prozessorkern für die Steuerung zuständig ist. In einer weiteren Alternative ist auch ein Prozessor mit einem einzigen Kern möglich, wobei die Kommunikations- und

Steuerungsfunktionalitäten über Software-Komponenten getrennt sind. Der Steuerungsteil 8 ist hinsichtlich einer Level-2-Kommunikation überwiegend generisch, was eine

Unabhängigkeit von einem Protokoll, das in dem TCMS-Netzwerk verwendet wird, einschließt, und ist für eine Funktionalität des Subsystems, hier beispielhaft eine

Bremsenansteuerungsfunktionalität zuständig. Die Bremsenansteuerungseinheit 2 steuert die Aktoren 7 über eine erste sogenannte Kernsoftware 10 und das LAD 6. Der

Kommunikationsteil 9 ist für eine Kommunikation mit dem TCMS-Netzwerk 1 zuständig und kommuniziert damit über TCMS-Protokolle. Hier ist jeweils das Netzwerk- oder Bus- Protokoll CIP 14, MVB 15, TRDP 16 dargestellt, mit denen der Kommunikationsteil mit einer jeweiligen CIP-Netzwerkkomponente 17, MVB-Netzwerkkomponente 18 und TRDP- Netzwerkkomponente 19 kommuniziert. Alternativ ist es möglich, dass nicht sämtliche Arten der dargestellten TCMS-Software vorhanden sind, oder dass noch weitere Arten von TCMS-Software, beispielsweise HDLC, eingesetzt werden. Weiterhin ist es alternativ möglich, dass eine Netzwerkkomponente über unterschiedliche Protokolle kommuniziert. Ihrer Natur nach ist ein Teil der eingesetzten TCMS-spezifischen Software

protokollspezifisch. Die protokollspezifischen Teile sind mit dem Wandlermodul 20 verbunden, wobei das Wandlermodul 20 die verbundenen Protokolle 14, 15, 16 parallel verarbeiten kann. Ferner weist das Kommunikationsteil 9 eine protokollunabhängige zweite Kernsoftware 11 auf.

In dem Steuerungsteil 8 und in dem Kommunikationsteil 9 ist ein gemeinsames

Wandlermodul 20 aus einem steuerungsseitigen Teil 21 und einem TCMS-spezifischen Teil 22 vorgesehen, wobei das Wandlermodul 20 unterschiedliche

Softwareprotokollformate der Protokolle (14, 15, 16), die in dem TCMS- Netzwerk verwendet werden, in ein Protokoll-unabhängiges Nachrichtenformat und das Protokollunabhängige Nachrichtenformat in die unterschiedlichen Softwareprotokollformate umwandelt.

Auf der Seite des Steuerungsteils 8 sind eine protokollunabhängige

Bremsenansteuerungsapplikation als eine Funktionsapplikation 12 und eine

protokollspezifische Systemkonfiguration 13 enthalten, was eine Abhängigkeit von dem in dem TCMS-Netzwerk verwendeten Protokoll bedeutet. Die Funktionsapplikation 12 weist eine dazu geeignete Hardwarekomponente und eine entsprechende protokollunabhängige Softwarekomponente auf. Die Kernsoftware 10 des Steuerungsteils 8 ist ebenfalls nicht protokollabhängig.

Das Wandlermodul 20 abstrahiert die protokollspezifischen Nachrichten auf der Seite des Kommunikationsteils 9 und stellt damit eine Protokoll-unabhängige Schnittstelle zu einem generischen Teil der Software auf der Seite des Steuerungsteils 8 dar.

In dem Wandlermodul 20 ist das Protokoll-unabhängige Nachrichtenformat festgelegt, das durch jeden protokollspezifische Stapel verwendet werden soll. Dies bedeutet, dass ein TCMS-spezifischer Teil 22 des Wandlermoduls 20 seine Nachrichten in das Protokollunabhängige Nachrichtenformat umwandelt, was dann nach der Umwandlung zu der Funktionsansteuerungsapplikation 12 übertragen wird. Das Nachrichtenformat enthält alle notwendigen Informationen für den generischen Teil und die

Funktionsansteuerungsapplikation 12, wie beispielsweise einen Nachrichtentyp, eine Nachrichten-ID, eine Datenmenge und Daten. Das Wandlermodul 20 kann in der Bremsansteuerungseinheit 2 mehrere, auch unterschiedliche Protokolle parallel verarbeiten.

Durch das Wandlermodul 20 wird jeder Datenblock in das Protokoll-unabhängige

Nachrichtenformat umgewandelt. Auf diese Weise hat der generische Teil einer

Bremsenansteuerungssoftware lediglich einen Protokolltyp zu verarbeiten und zu übertragen.

Ferner kann das Wandlermodul 20 Anweisungen wie "Start", "Stopp", "Konfiguration" oder "Zurücksetzen" übertragen.

Im Betrieb werden Daten in einem Softwareprotokollformat 14, 15, 16 von dem TCMS- Netzwerk 1 über die Datenschnittstelle in den Kommunikationsteil 9 des Subsystems 2, 3, 4, 5 eingelesen. Diese Daten werden durch das Wandlermodul 20 in ein Protokollunabhängiges Nachrichtenformat umgewandelt, über die erste Kernsoftware 10 an die Funktionsansteuerungsapplikation 12 weitergegeben und mit Hilfe der

Systemkonfiguration verarbeitet. Ein Ergebnis der Verarbeitung wird über das LAD 6 an die mechanischen Aktoren 7 weitergegeben und Informationen über das Ergebnis der Verarbeitung werden in einem Protokoll-unabhängigen Nachrichtenformat an das

Wandlermodul 20 gegeben, durch das diese Daten in das jeweilige

Softwareprotokollformat 14, 15, 16 umgewandelt werden und über die Datenschnittstelle wiederum an das TCMS-Netzwerk 1 übergeben. Dort werden die Daten an eine

zuständige Netzwerkkomponente 17, 18, 19 übertragen.

Bei der Umwandlung werden die Datenblöcke der Softwareprotokollformate in das

Protokoll-unabhängige Nachrichtenformat übertragen.

Von dem Steuerungsteil 8 ausgegebene "Start"-, "Stopp"-, "Konfiguration"- oder

"Zurücksetzen'-Anweisungen werden dabei in eine in dem Softwareprotokollformat definierte Anweisung übertragen. BEZUGSZEICHENLISTE

1 TCMS-Netzwerk

2 Bremsenansteuerungseinheit (Brake Control Unit; BCU)

3 Klimatisierungssystem (Heating - Ventilation - Air Conditioning; HVAC)

4 Türsteuerungssystem

5 Lichtsteuerungssystem

6 Local Application Device (LAD)

7 mechanische Aktoren

8 Steuerungsteil

9 Kommunikationsteil

10 erste Kernsoftware

11 zweite Kernsoftware

12 Funktionsansteuerungsapplikation

13 Systemkonfiguration

14 CIP (Common Industrial Protocol)

15 MVB (Multifunction Vehicle Bus)

16 TRDP (Train Realtime Data Protocol)

17 CIP-Netzwerkkomponente

18 MVB-Netzwerkkomponente

19 TRDP-Netzwerkkomponente

20 Wandlermodul

21 steuerungsseitiger Wandlermodulteil

22 TCMS-spezifischer Wandlermodulteil