GMX-RGP (GeminiX-based ERTMS RBC Generic Product) is a SIL4-capable SW Generic Product, developed by NEAT, implementing the functionalities of the ERTMS Radio Block Centre (RBC). GMX-RGP is compliant with the European ERTMS/ETCS specifications Baseline 3 and with CENELEC standard requirements for SIL4 products.

The RBC is the ERTMS/ETCS trackside subsystem which controls the distancing of railway traffic, on the basis of the information provided by the interlocking on yard objects and routes, and of the messages sent via radio by the supervised trains.

The RBC Generic Product (i.e. the GMX-RGP product) implements the ERTMS functions defined in the applicable Subsets. The Generic Product, together with a set of RBC Adapters implementing the features of a specific context (e.g. the Italian railways), makes up an RBC Generic Application. The RBC Specific Application realizes the application for a specific site by adding the configuration data for both GP and GA.

Figure shows the high-level organization of an RBC based on GMX-RGP, in terms of Generic Product, Generic Application and Specific Application.

Figure also shows a sample set of interfaces of the RBC with external systems, represented by the ETCS trains, the neighbouring RBCs, the KMC, a VMMI, the CBIs supervising the RBC area and/or the yard Object Controllers, a Juridical Record Unit, a system for Diagnostic and Maintenance, a redounded RBC.

ETCS trains, neighbouring RBCs and KMC will be interfaced directly by GMX-RGP; for all the other external systems the interaction will be handled by the RBC Generic Application.

The GMX-RGP overall functionalities are:

• Management of line topography
• Handling of Radio Connections with trains
• Handling of Communication Sessions with trains
• Acquisition of train data
• Communication of National Values to trains
• Handling of Train Positions
• Start of Mission / End of Mission
• ERTMS/ETCS Level Transitions
• Temporary Speed Restrictions
• Handling of Level Crossings
• Handling of Movement Authorities (assignment to trains, extension, revocation)
• Emergency messages to trains
• Text messages to trains
• Shunting authorizations
• Handling of Train Trip
• “Track Ahead Free” procedure
• Handling of Reversing Areas
• Handling of Track Conditions
• Handling of RBC-RBC handover

PVS is a Safe and Secure Communication SIL4 Protocol, based on SS098.

PVS is a RFI Standard, NEAT has been authorized by RFI (Italian Infrastructure Manager) to distribute the protocol both in Italy and in foreign countries.

NEAT has certified SIL4 a SW PVS library implementation according CENELEC EN 50128 norm.

Main features of the PVS library:

• – Compliant with PVS rev F specification
• – Written in ANSI C, compliant with MISRA-C:2012 guidelines
• – Self-contained: not using any external library, or the C standard library
• – No system calls and no access to the hardware
• – Test Environment able to execute SW Requirement and SW Module Test Specifications
• – Documentation package

The PVS communication library is separated in two high-level software components:

• – The SFM, implementing the Safety Functional Module
• – The CFM, implementing the Communication Functional Module

Each high-level component can be accessed by the user application through a public API.

The public API is designed against user input errors, and tested accordingly

The CFM and SFM are totally independent of each other, and can be used by separated user Applications

OBVC (On Board Vital Computer) is a generic computer system based on the NEAT GeminiX Platform, and designed to manage safety critical functionalities for the railway on-board applications. The OBVC can manage the supervision of the train’s movements against all the inputs received from the trackside equipment, on-board odometer, the driver and other stored information.

The OBVC can assert outputs to the driver through the DMI, to other train systems and functions through the Train Interface Unit (TIU) and transmits information back to the trackside if provided. OBVC is composed of different subsystems with different levels of safety.

OBVC is composed of different subsystems with different levels of safety, each with its own power supply. Safety Computing Subsystem (SCS) run the safety tasks, elaborates the safety packets and directly manages the vital inputs/outputs. The Non Vital Computing Subsystem (NVCS) manages non-safety tasks: transport layers of the protocols, non-vital I/O and maintenance routines.

Safety Computer System (SCS)

• – GeminiX 2.0–compliant
• – SoC based architecture
• – Hardware diversity
• – Up to 2x PROFIBUS interfaces
• – Up to 8x RS232/422/485 ports
• – Up to 10 I/O boards selectable within: Vital Inputs, Vital Outputs, Wheel sensor acquisition, Doppler radar acquisitio

Non Vital Computer System (NVCS)

• – X86 ComEx module with Linux
• – 2x MVB
• – 2x CAN, 4x RS232/422/485, 1x GPS
• – Integrated 8 port ethernet switch
• – Up to 7x I/O boards selectable within: Digital Inputs, Digital Outputs, Analog Inputs

SCS can be composed by a single Safety Computing Unit (SCU) or by two SCUs, which can possibly run different User Applications. OBVC can also be doubled for redundancy.

Figure shows an example of OBVC configuration, where the SCS includes two Safety Computing Units.

An overview of OBVC software is shown in the following figure .

From SW point of view the OBVC contains:

• • – GeminiX-OS
  • – OBVC-SW
  • – Linux
  • – User Application

For an overview on GeminiX-OS see www.geminix.it

OBVC-SW is the software layer which implements a framework able to execute one SIL4 User Application SW.

OBVC-SW will be released in the framework of the OBVC project while the (user) Application SW will be developed by the end user so it is out of the scope of OBVC project.

The GeminiX-OS API allows the Safety Related part of User Application SW (running on SCS) to access all needed functions and resources implemented by OBVC-SW part on SCS.

The BSP NVCS API implemented by OBVC-SW part on NVCS allows the Non-Safety Related part of User Application to communicate with the Safety Related part, using the Blackboard paradigm.

The GMX-RS is the NEAT’s Geminix Reference System for the GMX HW developing platform and it is the perfect ready-to use demonstrator where user is immediately enabled to exploit and experience all the Geminix full capabilities. GMX-RS is a desktop form-factor platform offering to the user a complete computer able to manage safety related operation (“A” and “B” nodes operating in 2oo2 paradigm, running GeminiX OS) and communication tasks (“C” node, running Linux); moreover a set of standard Ethernet, UART, HDMI and USB interfaces allow the user accessing all the resources of the GMX-RS.

The GMX-RS is basically composed by

•  – The Safe CPU, where the two computing nodes “A” and “B” execute the safety related tasks
•  – The Communication CPU, executing non safety related task
•  – The Power Supply Unit
•  – The backplane, providing all the user interfaces: 8x 10/100/1000 Ethernet, RS232/422/485 interfaces, Debug Uart over USB Port, main power port.
•  – The Carrier, gathering the interconnection of the above mentioned items

On the front panel also configurable activity LEDS, a Maintenance Ethernet port,  3xUSB 2.0 and 1 HDMI port, are available.

GMX-RS is available in two version, namely HE (High End) and LE (Low End), still maintaining same form factor and interfaces, thus exploiting the capability of GMX-LE and GMX-HE concepts; GMX-RS product tree is shown below.

GMX-LE represents one of the GeminiX implementations, available within the GMX-RS versions, specifically designed for Low End application, typically where medium computing performance, low power consumption, low size and low price shall be targeted, such as Object Controller, small Interlock, PVS to Custom Protocol Gateway. GMX-LE computing nodes are implemented making use of state of the art System on Chip (SoC) technologies; this implementation is, also, capable to withstand to harsh environmental condition, such as close-to-rails installations in railways application.

GMX-LE makes intensive use of GeminiX well consolidated and tested reference designs, thus tailoring all the functions required by the specific design. GMX-LE also supports redundancy at diverse levels, in order to largely increase availability; specifically, redundancy is supported at power supply level, at computing level and at user interface level.

Safety computing nodes “A” and “B”, running GeminiX OS, are implemented with Arm SoC CPUs in Hardware Diversity, namely: Zynq 7020 by AMD and Cyclone V SoC by Intel, embedded on a single board computer, (GMX-SoC-G), where the GMX Core functions are implemented in VHDL; 4 ethernet ports are also available from each safe node, for local communication with the “C” computer and also for redundancy management to a second GMX-LE-RS; also a set of local resources are available, such as temperature monitoring, power supply cross monitoring, NVRAM (EEPROM, FRAM). In addition a “service” connector expands the user interfaces to allow, for instance, boot from SD CARD, JTAG accesses, standalone Debug console.

• – GeminiX 2.0–compliant
• – SoC based architecture
• – CPU-A Xilinx Zynq XC7Z020-1CLG484I
• – DRAM-A : 2 x MT41K256M8DA +ECC – 512MB + ECC up to 1600 MHz
• – Embedded peripherals Gbit Ethernet, SPI, I2C
• – CPUB Altera Cyclone V 5CSEBA5U23
• – DRAM-B : 2 x IS43TR16256AL +ECC – 1GB + ECC up to 1600 MHz
• – Embedded peripherals Gbit Ethernet, SPI, I2C
• – Hardware diversity
• – 4x ETH 100BASE T (two per CORE)
• – Parallel bus expansion port for custom I/O mapping
• – –40 ÷ +71 °C Operating
• – –40 ÷ +85 °C Storage
• – Compliant to IS402, EN50155, EN 50121
• – Standard 3U minimum form factor 100 x 160 mm (customizable on request)
• – Carrier with x86 communication processor available

GMX-HE specifically designed for High End application represents one of the GeminiX implementations, available within the GMX-RS versions, specifically designed for High End applications, where high computing performances are required, such as large Interlock or RBC systems; GMX-HE implementation generally makes use of server class CPUs, consequently, the considerably high power consumption, coming from the adopted CPU, requires a proper installation environment, with proper countermeasures against the excessive heat generated.

GMX-HE makes intensive use of GeminiX well consolidated and tested reference designs, thus tailoring all the functions required by the specific design. GMX-HE also supports redundancy at diverse levels, in order to largely increase availability; specifically, redundancy is supported at power supply level, at computing level and at user interface level.

Safety computing nodes “A” and “B”, running GeminiX OS are implemented with Server class CPUs in Hardware Diversity, namely Ryzen CPU by AMD and Xeon CPU by Intel, as COTS boards available from diverse suppliers, mounted over the GMX-x86-G board, working as a carrier for the Com express CPU and embedding the FPGA where GMX Cores functions are implemented in VHDL; 4 ethernet ports are also available from each safe node, for local communication with the “C” computer and also for redundancy management to a second GMX-HE-RS; also  a set of local resources are available, such as temperature monitoring, power supply cross monitoring, NVRAM (EEPROM, FRAM). In addition a “service” connector expands the user interfaces to allow, for instance JTAG accesses, standalone Debug console.

Main features:

• – GeminiX 2.0–compliant
• – x86 based architecture
• – CPU-A any type 6 ComEx module (e.g.: AMD based COMe-CVR6 by Kontron)
• – DRAM-A : ComEx dependant (e.g.: 8 GByte DDR4 memory down up to 24Gbyte with SODIMM expansion)
• – Embedded peripherals Gbit Ethernet, SPI, I2C
• – CPUB any type 6 ComEx module (e.g.: INTEL based CPU-161-18-07 by Eurotech )
• – DRAM-B : (e.g.: 8 GByte DDR4 memory down up to 24Gbyte with SODIMM expansion)
• – Embedded peripherals Gbit Ethernet, SPI, I2C
• – Hardware diversity
• – CPU-C for communication functions
• – any type 6 ComEx module (e.g.: AMD based COMe-CVR6 by Kontron)
• – DRAM-C : ComEx dependant (e.g.: 8 GByte DDR4 memory down up to 24Gbyte with SODIMM expansion)
• – 8x ETH 1000BASE T
• – 0 ÷ +55 °C Operating
• – –40 ÷ +85 °C Storage
• – Compliant to IS402, EN50155, EN 50121
• – Standard 5U form factor 188.9 x 220 mm (customizable on request)

GRIO allows a GeminiX-based central unit to safely command remote inputs and outputs on the field, achieving SIL4 standard.
The system is composed by 5 computing units, controlled via network with safe communication protocols (e.g. PVS)

GRIO-RD is composed by:

•  – Virtual Platform
•  – GRIO-OS and Protocols
•  – Reference Design Hardware
•  – Modular IO

VIRTUAL PLATFORM:
The GRIO Platform architecture relies on a quad diverse electronic structure based on the composite fail-safety paradigm.
Safe Nodes are independent and electrically insulated from each other, so they cannot communicate directly.
An additional Node is used to manage synchronization, internal and external communication channels and diagnostic data collection.
Each safety-related function is accomplished by joining the contributions coming from four independent Nodes.
Such functions include asserting an output to the field, reading an input from the field, sending and receiving safety packet on a communication data network.

GRIO-OS And Protocols
GRIO safety related software implements a real-time execution environment that include functions for hardware management, vital data encoding/decoding, diagnostic information collection and custom I/O software execution. This operating system has been developed from scratch to handle the five nodes architecture.
Non-safety-related part of GRIO is composed by the bootloader and the operating system of Node E, where software for safe communication is executed.

Reference Design Hardware
– Node E (non safe): SOM Atmel CortexA5 based on ARM architecture, 500mhz CPU and a Posix operating system
– Nodes ABCD (safe): developped in diversity
— NXP Cortex M4 microcontroller, 180mHz
— Atmel Cortex M7 microcontroller, 120mHz
In addition, the system requires:
– Bus couplers for isolation
– 2 EEPROM for each of the safety nodes
– hardware for UART, I2C, SPI and GPIO interfaces

ModularIO
Actual implementations propose 2 configurations:
– 4 inputs, 2 outputs
– 12 inputs, 6 outputs
The number of inputs and outputs is modular to allow easy scalability.
ADC and CPLD on the I/O boards developed in diversity:
– ADC: – Maxim MAX11328
– Texas Instruments ADS7953
– CPLD: – Altera 10M02SCU169I7G
– Microsemi A3P125-1FGG144I

Communication “C” computer (GMX-CPU-C) is a custom board providing mechanical and electrical support for the “A” & “B” safe CPUs and the “C” node; GMX-CPU-C aims to fulfill the application specific interfaces, including further expansion slots in standard format (i.e.: mini Sata, mini PCIe, etc..), where COTS expansion board can be plugged, in order to meet as close as possible all customer requirements.

Basically the GMX-CPU-C board can be redesigned and tailored in order to modify form factor, number and type of interface.

The “C” computer makes use of COTS x86 industrial PC in COM Express form factor plugged over the GMX-CPU-C; a large number of COM Express boards can be used, depending on market availability, target price, requested performance, and microarchitecture; for instance x86 Intel Xeon class processors can be used, rather than Atom.

Hence, “A”, “B” and “C” nodes are internally interconnected with a local Network, handling Boot, data logging and safety packet transmission. Furthermore “C” computer offers up to 9x 10/100/1000 Ethernet, 5x RS232/422/485 serial interfaces; moreover the CPU “C” also provides native HDMI and USB interfaces, allowing the user to connect Monitor and Keyboard

The KMC-Subset137 Library implements the protocol described in “ERTMS/ECTS; On-line Key Management FFFIS” UNISIG SUBSET-137 ver1.0.0.

It covers the on-line distribution of cryptographic keys among the Key Management Centres authoritative in their respective domains. It also deals with the exchange between a Key Management Centre and its own domain KMAC entities.

The library provides a simple C language application programming interface (API) to access and parse UNISIG SUBSET-137 messages and is licensed under both open source and commercial versions.

RaSTA is a Safe and Secure Communication SIL4 Protocol

Main features:

• – Compliant; RaSTA DIN VDE V 0831-200 specification
• – Written in ANSI C, compliant with MISRA-C:2012 guidelines
• – Safety and Retransmission Layer Self-contained: not using any external library
• – Safety and Retransmission Layer does not require access to the hardware
• – Test Environment able to execute SW Requirement and SW Module Test Specifications
• – Documentation package

The RaSTA communication library is separated in two high-level software components:

• – The Safety and Retransmission Layer
• – The Redundancy Layer

Each high-level component can be accessed by the user application through a public API. The public API is designed against user input errors, and tested accordingly.

Both modules are totally independent from each other, and can be used by separated user Applications