D4R::Application

GMX-RGP (GeminiX-based ERTMS RBC Generic Product) is an EN 50128 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.

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

The 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 are interfaced directly by GMX-RGP; for all the other external systems the interaction are handled by the RBC Generic Application.

The GMX-RGP overall functionalities are:

•  – Management of railway network 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

GMX-RGP is integrated in the D4R simulation environment (see the figure below)

PVS is a Safe and Secure Communication SIL4 Protocol, designed by RFI, with the purpose of standardising vital communication between railway systems of different suppliers.
The PVS protocol is based on UNISIG Subset-098 and Subset-037. It is a cyclic and asynchronous protocol, compliant to CENELEC EN 50159, usable on open and closed networks, with the possibility of cryptographic level with two encryption algorithms applied in succession: AES + AES-CMAC.

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 PVS library Generic Product according CENELEC EN 50126/50128/50129/50657 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

GMX-OBVC-RD (On Board Vital Computer Reference Design) is a generic computer system reference design based on the NEAT’s GMX-LE-RD – GeminiX Low End Reference Design (SoC based)  and designed to manage safety critical functionalities for the railway on-board applications. The GMX-OBVC-RD 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 (a reference design for all the Input/Output of an EVC is also available).

The GMX-OBVC-RD 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.

GMX-OBVC-RD 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
• – GMX LE-RD, GeminiX Low End Reference Design (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 acquisition

Non Vital Computer System (NVCS)

• – GMX-CPU-C – GeminiX Communication Computer
• – 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, hence it is out of the scope of OBVC Reference Design.

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 GeminiX-OS provided blackboard paradigm.

The GMX-RS , NEAT’s GeminiX Reference System,  is the perfect ready-to use demonstrator of a GeminiX HW where the user can immediately 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) as well as to perform communication tasks via the “C” node running Linux. Moreover, the GMX-RS is equipped with set of standard Ethernet, UART, HDMI and USB interfaces to give full access to the user.

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 several 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 the same form factor and interfaces, thus exploiting the capability of GMX-LE and GMX-HE concepts; The 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 GeminiX 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; 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.

The GMX-LE main features are:

• – GeminiX 2.0–compliant
• – SoC based architecture
• – CPU-A Xilinx Zynq XC7Z020-1CLG484I up to 800MHz
• – DRAM-A : 2 x MT41K256M8DA +ECC – 512MB + ECC up to 1200MHz
• – Embedded peripherals Gbit Ethernet, SPI, I2C
• – CPUB Altera Cyclone V 5CSEBA5U23 up to 800MHz
• – DRAM-B : 2 x IS43TR16256AL +ECC – 1GB + ECC up to 1600 MHz
• – Embedded peripherals Gbit Ethernet, SPI, I2C
• – Hardware diversity
• – 4x ETH 1000BASE 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 generated excessive heat.

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.

The GMX-HE main features are:

• – GeminiX 2.0–compliant
• – x86 based architecture
• – CPU-A any type 6 ComEx module (e.g.: AMD based COMe-CVR6 by Kontron up to 3.2GHz)
• – DRAM-A : ComEx dependant (up to DDR4 16GByte memory down + DDR4 32 Gbyte SO-DIMM)
• – Embedded peripherals Gbit Ethernet, SPI, I2C
• – CPUB any type 6 ComEx module (e.g.: INTEL based CPU-161-18-07 by Eurotech up to 1.6GHz)
• – DRAM-B : (up to DDR4 8GByte memory down + DDR4 16 Gbyte SO-DIMM)
• – 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 up to 3.2GHz)
• – DRAM-C : ComEx dependant (up to DDR4 16GByte memory down + DDR4 32 Gbyte SO-DIMM)
• – 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, 300MHz
In addition, the system requires:
– Bus couplers for insulation
– 2 Non Volatile Memories 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.

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