Professional Articles

Darüber hinaus mussten die Unternehmen für den Marktzugang Komplettlösungen liefern. Neue Entwicklungen zielen auf die Modularisierung der funktionalen Architektur und auf die Digitalisierung im infrastrukturellen Bereich, was den Aufbau dieser HW/SW-Systeme aus Commercial-Off-The-Shelf (COTS) Komponenten verschiedener Hersteller ermöglicht. Darüber hinaus soll eine Flexibilisierung der Systeme, eine Kostenreduktion durch eine Erhöhung der Lieferantenvielfalt für COTS-Komponenten und eine Verkürzung der Entwicklungszyklen erreicht werden. Die Herausforderung besteht darin, die Modularisierung innerhalb der Prozesse zur Systementwicklung, Systemintegration und Systemzertifizierung umsetzen zu können, um die angestrebten Vorteile zu realisieren. Darüber hinaus erhalten die Anbieter von COTS-Komponenten dann auch Zugang zum Bahnsteuerungsmarkt, für den für die Jahre 2017 bis 2019 ein Wachstum zwischen 13 und 14 Mrd. € prognostiziert wird [WRM14].

Das vorliegende Papier evaluiert diese Modularisierung und deren Herausforderungen im Rahmen der Umsetzung eines Demonstrators, der als Proof-of-Concept-Studie dient und kontinuierlich weiterentwickelt wird. Die folgenden Rahmenbedingungen werden für mögliche Problemlösungsansätze in Bezug auf die Umsetzung dieser Studie gesetzt:

• Es wird angestrebt, modellbasierte Ansätze einzusetzen und die vorhandenen COTS-Komponenten für den Softwareentwicklungsprozess zu nutzen. Dies ermöglicht eine frühzeitige formale Verifikation in Bezug auf die Erfüllbarkeit von Systemanforderungen, indem inkrementelle modellbasierte Simulationen des Gesamtsystems durchgeführt werden können.
• Für den Zertifizierungsprozess ist der Einsatz von semi-formalen Methoden zu evaluieren, die die bestehende Zertifizierung im Vergleich zu Normen über die COTS-Komponenten mit den Anforderungen in der Spezifikation des Gesamtsystems korrelieren und die notwendige Zertifizierung des Gesamtsystems auf die ermittelte Differenz reduzieren [MIL16].
• Die sicherheitsrelevanten Normen EN-5012x sind entsprechend der Domäne [EN126, EN128, EN129, EN159] zu bewerten und in der Studie zu berücksichtigen. 

Abbildung 1: Schematischer Aufbau des Eisenbahndemonstrators

Die geplante Grundstruktur des Demonstrators umfasst drei Module, die sich jeweils aus verschiedenen Komponenten zusammensetzen. Der schematische Aufbau ist in Abb. 1 zu sehen und sieht wie folgt aus:

• Das Schienenmodul umfasst den kompletten physischen Aufbau einer Modelleisenbahn mit Fahrzeugen, Schienennetz und Ortsangaben (Balisen). Die Modellzüge selbst sind mit angepasster Hard- und Software ausgestattet, die mit dem Zugsicherungssystem kommuniziert. Sowohl das Schienennetz als auch die Fahrzeuge sind über ein IP-basiertes Netz mit den anderen Modulen verbunden. Es ist geplant, die Modelleisenbahn zu einem späteren Zeitpunkt durch ein Simulationsmodell zu ersetzen, um komplexere Szenarien abdecken zu können.
• Das Safe-PC-Modul vereint separat die Fahrwegberechnung als abstrakte Integrierte Elektronische Leitstelle (IECC) und die ETCS-Kernkomponente "Geschwindigkeits- und Abstandsüberwachung" (SDM) der einzelnen Fahrzeuge.
• Das Panel-PC-Modul dient der ETCS-kompatiblen Visualisierung der Zugsicherungsinformationen, wie sie für den Führerstand vorgesehen ist.
• Als Hardware (HW)-Plattformen für Safe- und Panel-PCs sind für den Bahnleitmarkt verfügbare Multicore-Systeme vorgesehen. 

In den folgenden Abschnitten werden der derzeitige Stand und die bei der Umsetzung des Demonstrators gewonnenen Erkenntnisse beschrieben. Abschnitt 2 zeigt das Integrationskonzept und die einzelnen Komponenten mit ihren Entwicklungsschritten. In Abschnitt 3 wird der aktuelle Stand der Umsetzung festgehalten. Abschnitt 4 befasst sich mit der Zertifizierbarkeit der einzelnen Komponenten und Abschnitt 5 schließt mit einer Zusammenfassung und dem Ausblick auf die nächsten Iterationen ab.

Konzept des Zugbeeinflussungssystems

Das geplante Konzept für das Zugsicherungssystem des Demonstrators sieht die Verwendung von COTS und einen reduzierten Eigenanteil an der Entwicklungsarbeit für die Komponenten vor. Die Ausgangsbasis für die Integration der Module aus Abb. 1 ist wie folgt: 

• Die HW-Plattformen für Safe- und Panel-PCs sind die bewährten COTS-Komponenten VX3035 und TRACe HMID104 der Firma KONTRON, die für den Bahnmarkt konzipiert wurden und über Multicore-Prozessoren verfügen.
• Als Betriebssystem für die Safe-PC- und Panel-PC-Module wird der PikeOS Hypervisor von SYSGO als COTS-Komponente mit den verfügbaren Erweiterungen eingesetzt. Bei beiden PC-Modulen bezieht sich die erste Erweiterung auf den Certifiable IP Stack (CIP), um die IP-basierte Netzwerkkommunikation (ETH/IP) zu gewährleisten. Zusätzlich wird auf dem Panel-PC-Modul die CoreAVI-Komponente zur OpenGL-basierten Darstellung des ETCS Human-Machine Interface (HMI) eingesetzt.
• Damit die für eine Demonstration benötigten ETCS-Komponenten implementiert werden können, wurde für das HMI und die Kernelkomponente SDM auf plattformunabhängige SCADE-Modelle aus dem openETCS-Projekt [ETC16] zurückgegriffen. Dieser Schritt der Integration von Komponenten über die SCADE-Suite entspricht somit dem modellbasierten Ansatz. Die SCADE-Suite ermöglicht die direkte Generierung von Quellcode aus dem SCADE-Modell für PikeOS.
• Für die Integration der funktionalen SW-Komponenten auf dem PikeOS-Separationskern für den Safe-PC und Panel-PC wird durch entsprechende Integrationsprojekte eine initiale Ressourcen- und Zeitpartitionierung gemäß den notwendigen Sicherheitsanforderungen vorgenommen, so dass die funktionalen Komponenten störungsfrei arbeiten können.

Das Bahnmodul ermöglicht die vollständige physikalische Simulation mehrerer Fahrzeuge auf dem balisenbestückten Modellbahnnetz. Sowohl die Fahrzeuge als auch das Schienennetz sind über das IP-basierte Netzwerk mit dem Safe-PC verbunden. Die Fahrzeuge melden ihre aktuellen Positionen an das Zugsicherungssystem auf dem Safe-PC und erhalten die daraus resultierenden Freigaben oder Bremseingriffe. 

Abbildung 2: PikeOS-Zeitpartitionierung für Komponentenpartitionen auf dem Safe-PC-Modul

Auf dem Safe-PC Modul befindet sich für jedes Fahrzeug im Gleismodul eine SDM-Komponente, die im Zusammenspiel mit der IECC-Komponente die Bremskurven auswertet und kritische Bremseingriffe erzeugt. Die IECC-Komponente verarbeitet die empfangenen Streckendaten des Gleismoduls. Dies ermöglicht eine interaktive Auswahl des Fahrwegs durch die Umschaltung der Weichen relativ zur Laufzeit. Auf diese Weise können dynamische Bedingungen zur Geschwindigkeitsbegrenzung oder Kollisionsvermeidung geschaffen werden. Sowohl die IECC- als auch die openETCS-Komponenten werden direkt aus den entsprechenden SCADE-Modellen generiert. 

Auf dem safe-PC Modul ist ein Netzwerkadapter vorhanden. Damit werden die ein- und ausgehenden Netzwerkpakete über eine entsprechende Partition (NETMUX) nach dem Multiplex-Verfahren auf die Modellkomponenten verteilt. Diese NETMUX-Komponente ist die einzige Eigenentwicklung mit einem geringen Komplexitätsgrad. Die Trennung erfolgt über Netzwerkports und für die interne Kommunikation werden die vertrauenswürdigen Shared-Memory (SM)-Mechanismen von PikeOS genutzt.

Abbildung 3: PikeOS-Zeitpartitionierung für Komponentenpartitionen auf dem Panel-PC-Modul

Zusätzlich zu den Fahrzeugen des Schienenmoduls kommuniziert der safe-PC die aktuellen Daten an das jeweilige openETCS-HMI auf einem Panel-PC. Dieses wird als OpenGL-kompatible Software direkt aus dem entsprechenden SCADE-Anzeigemodell der openETCS-Bibliothek generiert. Für die OpenGL-kompatible Anbindung wird eine zusätzliche CoreAVI-Treiberkomponente von Core Avionics & Industrial Inc. verwendet. Die Ausgabe erfolgt somit über das Panel-PC-Modul, wie es im Führerstand eines Schienenfahrzeugs vorhanden ist. 

Neben der Ressourcenpartitionierung der einzelnen Komponenten der jeweiligen Module in Abb. 1 findet auch eine zeitliche Partitionierung für diese Komponenten statt, wie in Abb. 2 und Abb. 3 dargestellt.

Umsetzungsstand des Demonstrators

Im Rahmen des schematischen Aufbaus des Demonstrators, wie er in Abb. 1 dargestellt ist, konnten in den letzten Iterationen das Bahnmodul und das safe-PC-Modul in Form eines Prototyps realisiert werden. Die Umsetzung des Panel-PC-Moduls ist für die nächste Iteration vorgesehen. Dieser Prototyp wurde von der SYSGO GmbH auf der Embedded World 2016 ausgestellt und die korrekte Funktionalität der vernetzten ETCS-Komponenten demonstriert. Für die HW-Plattform A wurde ein VX3035 (3HE VPX SBC mit Intel Core i7 Prozessor) von KONTRON zur Verfügung gestellt.

Der Demonstrator erhebt den Anspruch, die dargestellten Aspekte realistisch zu simulieren. Die formalen Modellkomponenten des openETCS-Kernels werden unverändert übernommen. Zum Zwecke der Anpassung an den Demonstrator werden die Komponenten von angepassten Übersetzungsmodulen umgeben. Die Details zur Implementierung und zum Zusammenspiel der ETCS-Komponenten sind wie folgt:  

• Das Modell-Schienenfahrzeug vereint maßstabsgetreue Antriebssteuerung, Odometrie und Balisenleser. Die Antriebssteuerung befindet sich auf den jeweiligen Fahrzeugen des Schienenmoduls und simuliert das Fahrverhalten unabhängig von der Zugsicherung im Maßstab 1:160, einschließlich der Auswertung der Standortbalisen innerhalb des Streckenabschnitts zur Synchronisation der Odometrie. Diese Balisen arbeiten mittels Infrarot-Übertragung (IrDA). Die Integration der Fahrzeugsteuerung in die Modelleisenbahn erfolgte durch eine Hardware-Erweiterung auf Basis eines Atmel XMega32E5 Mikrocontrollers (MCU). Eine vollständige Integration der komplexen ETCS-Komponente zur Bremskurvenüberwachung unter Berücksichtigung von Steigungen, nichtlinearem Bremsverhalten und aufeinanderfolgenden Bremspunkten am Modellfahrzeug ist derzeit nicht möglich und für den Demonstrator nicht vorgesehen. Das Konzept sieht daher das Konzept des anwendungsgerechten Safe-PC-Moduls vor. Die Realisierbarkeit solcher Konzepte kann durch diesen Schritt der getrennten Integration auf internetvernetzten Systemen teilweise evaluiert werden.
• Eine besondere Komponente ist die Fahrwegberechnung (IECC), die in Form eines formalen SCADE-Modells auf dem Safe-PC-Modul implementiert ist. Der dynamische Linienplan des Modells wird über das Netzwerk von der Weichensteuerung des Bahnmoduls eingelesen und der notwendige und maximale Fahrweg für jedes Fahrzeug berechnet. Dazu werden verschiedene ETCS-Komponenten auf der Strecken- und Fahrzeugseite zusammengeführt. Die Fahrwegberechnung innerhalb der IECC-Komponente erfüllt somit auch die ETCS-Kernfunktion der Positionsmeldung und des Gleisatlasses.
• Weiterhin wurde auf die Integration des ETCS-Modus zugunsten einer vereinfachten Darstellung verzichtet. Nach dem Verbindungsaufbau zwischen den Geräten schaltet das Fahrzeug sofort in den Full-Supervision-Modus (FS) um. Da die Position auf der Modellbahntafel dem Fahrzeug erst beim Überfahren einer Ortsbalance bekannt ist, wird im FS ein virtueller On-Site-Modus (OS) generiert, in dem der Fahrweg auf 1000 m bei einer Geschwindigkeit von 50 km/h begrenzt ist.

Durch die gesicherte Trennung mittels PikeOS können sowohl die SDM-Komponenten aller drei Modellfahrzeuge als auch die zentrale IECC-Komponente separat und störungsfrei auf einer Plattform integriert werden. Zusammenfassend ist es mit der Implementierung von Rail-PC- und Safe-PC-Modulen gelungen, die ausgewählten Komponenten des openETCS-Kerns mit der physikalischen Demonstration zu verbinden. 

Zertifizierbarkeit des Zugbeeinflussungssystems

Die Anforderungen an die funktionale Sicherheit von Bahnsystemausrüstungen sind in den nationalen und europäischen Vorschriften, nicht zuletzt in der CENELEC-Normenreihe EN 501XX, wie folgt beschrieben: 

• EN 50126 befasst sich mit den Aspekten der Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit und Sicherheit (RAMS) der gesamten Infrastruktur sowie der einzelnen Teilsysteme.
• EN 50128 beschreibt den Prozess und die technischen Anforderungen für die Entwicklung von Software für programmierbare elektronische Systeme [EN128].
• Für sicherheitsbezogene elektronische Systeme der Signaltechnik ist EN 50129 anzuwenden [EN129].
• EN 50159 muss für sicherheitsrelevante Kommunikation in Übertragungssystemen angewendet werden [EN159]. 

Abbildung 4: Schematische Übersicht zum Zweck der Implementierung, Verifizierung und Validierung

Nach Abschluss der Prototypphase soll ein strategisches Konzept zur vereinfachten Zertifizierbarkeit unter Berücksichtigung dieser Normen und der vorhandenen Zertifizierungs-, Test- und Modellartefakte der COTS-Komponenten evaluiert werden. Konkretes Ziel ist es, die entstehenden Kosten und den Aufwand für ein zertifizierbares Gesamtsystem reduzieren zu können. Dabei wird sich die Methodik an den Ansätzen des EURO-MILS-Projektes [MIL16] orientieren, das sich auf den Security-Bereich konzentriert. Die Sicherheitsanforderungen an das Gesamtsystem werden mit den bestehenden Zertifizierungsartefakten der COTS-Komponenten für den Demonstrator abgeglichen. In einem semi-formalen Review-Prozess werden die ausstehenden Anforderungen identifiziert und das ermittelte Sicherheitsanforderungs-Delta stellt dann die minimierte Ausgangsbasis für die Zertifizierung des Gesamtsystems dar. Auf diese Weise soll der Aufwand für den Integrator des Gesamtsystems gemäß dem Verifikations- und Validierungsmodell auf die im oberen Teil von Abb. 4 dargestellte Vorgehensweise reduziert werden.

PikeOS Hypervisor-Komponente

Das zugrundeliegende Betriebssystem, repräsentiert durch die PikeOS Hypervisor Komponente, übernimmt eine zentrale Rolle für die Realisierung von Sicherheitsfunktionen in Software gemäß EN 50128. 

Abbildung 5: PikeOS Software Architektur

Das Grundprinzip dieses Separationskerns ist, dass die Partitionierung der Hardwareplattform manipulationssicher und statisch ist [WIK01]. Außerdem ist seine Trusted Code Base (TCB) klein genug, um mit vertretbarem Aufwand verifizierbar zu sein. PikeOS von SYSGO ist eine spezielle Implementierung eines Separationskerns und bietet Partitionierung auf Basis eines Mikrokerns, wie in Abb. 5 dargestellt. PikeOS vereint somit ein Echtzeitbetriebssystem und einen Hypervisor in einem Produkt. Auf den Partitionen können einerseits Betriebssysteme wie Linux oder Android laufen, während andererseits ein Container für Laufzeitsysteme wie POSIX®, AUTOSAR, ARINC 653 zur Verfügung steht. Darüber hinaus ermöglicht PikeOS über die zeitliche Partitionierung die Sicherstellung einer Worst-Case Execution Time (WCET) gemäß EN 50128 [MOE01]. Ein geeignetes Konzept auf der Basis des Separationskerns kann die Zertifizierung drastisch vereinfachen. In der Bahnindustrie nutzen sowohl Zugsteuerungssysteme als auch softwarebasierte Leitstellensysteme bereits das Separationskonzept, um softwarebasierte SIL4-Sicherheit auf ihren jeweiligen Hardwareplattformen zu gewährleisten. In diesem Fall gewährleistet ein Separationskernel eine rückwirkungsfreie Trennung, so dass Anwendungen mit gemischten Kritikalitätsstufen auf einer Hardwareplattform konsolidiert werden können. Sicherheitsfunktionen, Kommunikationsdienste und Komfortfunktionen können so gleichzeitig auf der Hardware bereitgestellt werden, wodurch Größe, Gewicht und Stromverbrauch (SWAP) optimiert werden.

Der Entwicklungsprozess für PikeOS entspricht in vollem Umfang den Anforderungen der EN 50128, d.h. es liegen vollständige Prozessdokumente und Artefakte vor. Gemäß Abschnitt 7 der EN 50128:2011 kann ein Betriebssystem als generische Software betrachtet werden, auf deren Basis durch einfache Bereitstellung anwendungsspezifischer Daten und Algorithmen eine Vielzahl von Installationen erstellt werden kann. Generische Software kann als einzelne Komponente unabhängig vom System zertifiziert werden. PikeOS verfügt bereits über Zertifizierungen nach SIL4 für verschiedene Prozessorarchitekturen und Multicore-Systeme. Gleichzeitig erfüllt PikeOS bereits die notwendigen Voraussetzungen für den Prozess der inkrementellen Zertifizierung, wie er für modulare Systeme im Bereich der Avionik vorgesehen ist, so dass bestehende Zertifizierungsartefakte unter festgelegten Bedingungen wiederverwendet werden können, wenn das bestehende System modifiziert oder um weitere Module erweitert wird.

Hardware-Plattform-Komponente

Die Gefahren, die von der Hardware ausgehen, bestehen im Ausfall der entsprechenden Komponenten und den damit verbundenen Fehlfunktionen. Zur Analyse der gefährlichen Ausfallarten empfiehlt sich ein Top-Down-Verfahren, wie die Fehlerbaumanalyse, oder alternativ ein Bottom-Up-Verfahren, wie die Fehlermöglichkeits- und Einflussanalyse (FMEA) [EN129], wobei eine Identifikation der zu erwartenden Ausfallarten aller Hardwarekomponenten gefordert wird. Bei integrierten Schaltkreisen mit System-on-Chip (SoC) sind die Fehlertypen aufgrund der Komplexität nur schwer im Voraus zu bestimmen oder sie sind aufgrund der Programmierung der Hardware stark von der jeweiligen Anwendung abhängig. Die Norm schlägt in Anhang C3 vor, dass eine Begründung geliefert wird, dass dieser Fehlertyp aufgrund der Softwarearchitektur nicht plausibel auftreten kann. Ist dies nicht möglich, kann der Fehlertyp alternativ extern detektiert werden und innerhalb einer geforderten Zeit ein sicherer Zustand eingenommen werden. Aufgrund der Komplexität der hier verwendeten Intel Core i7 basierten VX3035 Hardware berücksichtigt das Sicherheitskonzept für die SIL 4 Zertifizierung eine externe Erkennung des Hardwareausfalls. Die Überwachung der fehlerfreien Funktion der Hardware kann durch verschiedene Built-In Tests (BIT) sichergestellt werden, die sich in folgende Kategorien unterteilen lassen:

• Power-On BIT (PBIT): Diese Tests werden entweder von der Firmware oder während der Boot-Phase des Betriebssystems durchgeführt. Da eine Zertifizierung des BIOS-Codes zu teuer ist, wird als PBIT eine vordefinierte Registerkonfiguration getestet, die von einem korrekt arbeitenden BIOS erreicht werden muss. Weicht die Registerkonfiguration nach dem Booten von den Vorgaben ab (aufgrund defekter oder nicht vorhandener Hardware), geht das System nicht in Betrieb.  
• Continuous BIT (CBIT): Tests, die zur Laufzeit ausgeführt werden, sind abhängig von den verwendeten Peripheriegeräten und der Anwendung. Da das korrekte Funktionieren dieses Tests sicherheitsrelevant ist, unterliegt der CBIT-Code der SIL 4 Zertifizierung. RAM-Fehler werden durch den Einsatz von ECC-RAM erkannt.

Der sichere Zustand, der im Fehlerfall eingenommen werden muss, ist ebenfalls anwendungsabhängig und soll an dieser Stelle nicht weiter betrachtet werden. Der Vollständigkeit halber sei erwähnt, dass für das SIL 4 Systemsicherheitskonzept eine redundante Architektur, wie z.B. Triple Modular Redundancy (TMR), notwendig ist.  

Projektspezifische Software-Komponenten

Der Lebenszyklus von nach EN 5012x entwickelten Systemen sieht verschiedene Phasen vor, die durch den in Abb. 4 dargestellten Verifikations- und Validierungszyklus beschrieben werden. Im openETCS-Projekt wurden formale Methoden für die Systemanalyse, Architekturmodellierung, funktionale Modellierung und Verhaltensmodellierung eingesetzt [OE16].

Die System Requirements Specification (SRS) ist für ETCS verfügbar und kann daher direkt als Eingangsdokument für die ETCS-spezifischen Komponenten verwendet werden. Das Dokument muss in ein entsprechendes Format (ReqIF) konvertiert werden, um die geforderte Traceability herstellen zu können. Im Projekt openETCS wurde zu diesem Zweck das Werkzeug Subset-2-ReqIF entwickelt, das strukturierte Dokumente in formale Anforderungsdateien klassifiziert. Diese werden zum Import in entsprechende Werkzeuge wie ProR/ReqIF, ReqCycle und Ansys SCADE LifeCycle verwendet. Aus der SRS wird zunächst die Systemstruktur entwickelt (z.B. Papyrus, Ansys SCADE System), um dann sukzessive die einzelnen Komponenten auf Basis der Spezifikation zu modellieren (Ansys SCADE Suite). Um bereits in einem frühen Stadium Tests generieren und automatisieren zu können, stehen Werkzeuge wie SCADE Test zur Verfügung, die bereits auf der Entwicklungs-PC-Plattform integrierte Tests ausführen können [HAS16].

Wurde ein SCADE-Modell mittels Model Check, Formal Verification und Timing&Stack Verifier verifiziert, wird durch den Qualified Code Generator (KCG) ein verifizierter C-Code generiert. Dieser Code ist ein ANSI C-Code ohne Abhängigkeiten von Hardware oder speziellen Bibliotheken. Um die Ein- und Ausgänge des Modells mit den Quellen und Senken bestimmter Hardware zu verbinden und dem Modell ein bestimmtes Timing zu geben, muss nun entsprechender Abstraktionscode erstellt werden. Der Umfang dieses Plattformcodes sollte minimal sein, da er verifiziert werden muss und nur unter bestimmten Bedingungen wiederverwendet werden kann. Die Kombination aus generiertem C-Code und Plattformcode muss am Ende in eine Zielbinärdatei übersetzt werden. An dieser Stelle wird deutlich, dass die Verwendung eines zertifizierten Betriebssystems erhebliche Vorteile bietet. Selbst wenn die zugrundeliegende Hardware geändert wird, kann der Plattformcode zwischen der PikeOS-API und dem SCADE-Modell beibehalten werden. Der Hauptaufwand für die Integration vollwertiger, zertifizierbarer ETCS-Komponenten in den Demonstrator reduziert sich auf die Auswahl der entsprechenden Werkzeuge. Die vorhandenen Modelle können für Tests in der Frühphase verwendet werden. 

Dokumente und Artefakte gemäß EN 50128, die für die Zertifizierung des (Teil-)Systems herangezogen werden können, existieren auch für die Softwarekomponenten Certifiable IP Stack und CoreAVI OpenGL ES.

Zusammenfassung und Ausblick

Nach Abschluss der ersten Iteration zur Realisierung des Zugbeeinflussungsdemonstrators auf Basis vorhandener COTS-Komponenten ist klar, dass die getroffenen Annahmen in Bezug auf reduzierte Kosten für die Systemintegration und für eine mögliche Zertifizierung gerechtfertigt sind. Es wurden ca. 4 Mannmonate investiert, um den jetzigen Stand des Demonstrators zu erreichen und anschließend konnten die ETCS-Komponenten auf dem Safe-PC-Modul über das Netzwerk vollständig mit der physikalischen Simulation des Bahnmoduls verbunden werden. Der nächste Integrationsschritt wird den Prototypen und das Panel-PC-Modul vervollständigen und damit finalisieren. Anschließend erfolgt die Ausarbeitung und Evaluierung des vorgestellten Zertifizierungsverfahrens.

Authoren

Dr.Eng. Frank Golatowski and Thorsten Schulz M.Sc.Eng.
frank.golatowski@uni-rostock.de
thorsten.schulz@uni-rostock.de
Institute for Applied Microelectronics and Data Technology
Rostock University

Mehmet Oezer M.Sc.Eng. and Philipp Gorski M.Sc.Eng.
philipp.gorski@sysgo.com
SYSGO GmbH
 

Verweise

[WRM14] Roland Berger Strategy Consultants, World Rail Market Study forecast 2014 to 2019, 2014, Commissioned by UNIFE The European Rail Industry, ISBN: 978-3-7771-0468-3

[MIL16] EURO-MILS, 2016, Publications & Deliverables, [ONLINE] Available at: https://euromils-project.technikon.com/, [Accessed 28 June 2016]

[EN126] DIN EN 50126:2000-03, Railway applications - The specification and demonstration of reliability, availability, maintainability and safety (RAMS)

[EN128] DIN EN 50128:2012-03, Railway applications - Communications, signalling and processing systems software for railway control and monitoring systems)

[EN129] DIN EN 50129:2003-12, Railway applications - Communications, signalling and processing systems - Safety related electronic systems for signalling

[EN159] DIN EN 50159:2011-04, Railway applications - Communications, signalling and processing systems - Safety related communication in transmission systems)

[ETC16] openETCS Consortium. 2016. openETCS. [ONLINE] Available at: openetcs.org. [Accessed 29 June 2016]

[HAS08] Hase, Klaus-Rüdiger; openETCS: Speed Up Migration & Reduce Total Cost; www.uic.org/cdrom/2009/01_ERTMS-platform/docs/5-steering-meetings/05-18nov08/Proceedings/item5-openETCS-hase.pdf

[HAS16] Hase, Klaus-Rüdiger; openETCS: Model-based, Agile and Open Source; www.schienenfahrzeugtagung.at/download/PDF2016/MiV07_Hase.pdf

[OE16] Mahlmann, Peter et. al; openETCS: Development and Implementation of the 'Open Proof' Concept [..] (concluding report); github.com/openETCS/Dissemination/blob/master/Schlussbericht/openETCS_Schlussbericht.pdf

[MOE01] Özer, Mehmet; White Paper: PikeOS Safe Real-Time Scheduling; https://www.sysgo.com/whitepapers

[WIK01], Wikipedia: Multiple Independent Levels of Security en.wikipedia.org/wiki/Multiple_Independent_Levels_of_Security