DELIVERABLES PUBLISHED BY THE PROJECT
D6.2 Data Management Plan
The Data Management Plan (DMP) describes the types of data that will be produced, collected and/or processed within the project and how this data will be handled during and after the project and in which way data will be preservedD4.2 GNSS+EGNOS unit prototype including data FDE for LOC-OB design and description document
This document describes the design of the developed prototype, its interfaces, its implemented data FDEs in the CLUG2 architectureD5.1 Site Demonstrator
This deliverable is the result of task 5.2
which objectives are to develop, implement, integrate and test a navigation
live demonstrator.
D4.1 CLUG LOC-OB functional architecture document
This document describes and justifies the proposed LOC-OB functional architecture(s), based on functions described in the other WP4.x, and experimented in WP5D5.2 Raw Data
This document outlines the technical framework and implementation of the raw data collection and processing pipeline developed in Work Package 5 (WP5). It includes detailed specifications for sensor configurations, data formats, interface definitions, and the structure of the data storage and exchange system. The data was collected using two test trains—Domino and Re450—operating in real-world railway environments across SwitzerlandD5.3 Analysis Report
This document presents the analysis that was conducted on the data output by the LOC-OB algorithm in post-processing using real sensor data collected in the field by the test train Domino from the SBB
DownloadD3.3 CLUG LOC-OB System FMEA
This document provides a functional safety analysis of the LOC-OB system, identifying how failures of an internal function leads to the failure of the LOC_OB system on its outputs. The safety analysis provided in this document continues the preliminary hazard analysis (see D3.2 deliverable) and complete the analysis made in D3.4 by a safety system functional analysis.D3.7 CLUG LOC-OB System Evaluation report
This document evaluates what has been produced during the project (WP2 + WP3 + WP4) to cover the RAMS objectives defined during T3.1 and to consider Safety and RAM results defined in T3.2 to T3.6.DownloadD6.4 Business case for LOC-OB
This document provides a cost-benefit-analysis that evaluates the economic feasibility of implementing GNSS-based onboard localisation technology (LOC-OB) as proposed in the CLUG 2.0 project. The aim is to assess the potential for LOC-OB to replace traditional localisation technology using Eurobalises and legacy odometry systems, and to provide recommendations for its adoption by infrastructure managers and railway undertakings.DownloadD6.6 Proposed LOC-OB requirement Gap Analysis
This document proposes a
review of the requirements defined in D2.4 considering the feedback of all the
work packages. It also provides a gap analysis on
the ERTMS documents identifying the modifications to be done with the
introduction of the LOC-OB into the ERTMS CCS-OB.
DownloadD6.5 Architecture Trade-off Analysis and Proposed Localisation On-Board System
This document adopts a qualitative approach to identify potential architecture options, trade factors and evaluation measures, which are organized into a Pugh matrix to facilitate a comprehensive trade-off analysis.
DownloadD3.4 LOC-OB External Interfaces Analysis
This document provides a high level external interfaces safety analysis completed by a safety functional system analysis of the LOC-OB system, identifying how the exchanged between the LOC-OB system and its environment and the internal functional blocks shall be designed to cover the safety requirements already identified in the previous works of the project. This analysis provides too, via an apportionment approach, indications on the selection of safety targets expected on the input measurement means to achieve the TFFR expected on the output functions.
DownloadD3.6 LOC-OB Preliminary System RAM analysis
Delivery D3.6 focuses on the RAM Analysis of the system architecture and the operational context of the LOC-OB system. The purpose of this preliminary RAM Analysis is to provide the overall documentary evidence of the reliability, maintainability, and availability performance level of the system architecture of the LOC-OB.DownloadD 3.5 System Functional Analysis
The objective of deliverable D3.5 is to analyse the System Functional failure to consolidate the Preliminary Hazards Analysis and CLUG RAMS Report of TLOBU solution A and validate the functional system specification and the architecture defined in WP2 and WP4. Fault Tree Analysis and Failure Mode Effect Analysis techniques are included in this taskDownloadD4.9 START OF MISSION PRELIMINARY DESIGN
D4.9 will focus on the feasibility of initialising the LOC-OB to the point where an initial safe trackedge_id/position/speed/acceleration can be provided, given CLUG 2.0 “single chain” architecture IMU + GNSS&SBAS + odometer + some rare balise + Track map. The influence the environment has on LOC-OB in a broad sense (train, geographical environment, operational) is discussed in this document.D4.8 TRACK SELECTIVITY DETERMINATION ALGORITHM DESIGN DOCUMENT
The deliverable D4.8 describes the different solutions and algorithms enabling to compute Track Selectivity as a detailed contribution of this part of the functional architecture. Two of them are deeply designed and prototypes developed to be experimented in WP5. The document aims at describing different ways and algorithms to design the function dedicated to determine in real time on which track id the train is under a certain probability of certitude versus time and distance after passing a switch node. It remains valid to detect track edge changes too.D4.7 CONFIDENCE INTERVALS COMPUTATION & INTEGRITY ALGORITHM DESIGN DOCUMENT
This
document describes the algorithm in charge of the integrity monitoring at the
output of the LOC-OB System as a detailed contribution of this part of the
functional architecture LOC-OB D4.1, in description of the Airbus prototype.
This algorithm prototype is going to be experimented in WP5.
D4.6 ALONG TRACK LOCALIZATION FUSION ALGORITHM DESIGN DOCUMENT
This document collects the algorithms designs produced in the scope
of WP4.6, as a detailed contribution of this part of the functional
architecture LOC-OB D4.1, in description of the Airbus prototype and experimented
in WP5.
D4.3 SAFE IMU SENSOR AND DATA FDE FOR LOC-OB DESCRIPTION DOCUMENT
This document briefly explains what an IMU is, what types of IMUs exist, which errors can be found in them and how can be minimized and which fault detection techniques could be employed.D3.2 LOC-OB Preliminary Hazard Analysis
This document provides a preliminary safety analysis of the LOC-OB system, identifying hazards, accessing the severity of the potential accidents and identifying safeguards for reducing the risks associated with the hazards.DownloadD3.1 LOC-OB System context analysis and RAMS Plan
This deliverable aims at defining and coordinating the
RAMS objectives and activities of CLUG 2.0 for the LOC-OB system.
DownloadD4.4 Speed sensor and data FDE for LOC-OB description document
This document briefly explains what a Speed Sensor is, which errors can be found in them, and which fault detection techniques could be employed. Furthermore, it provides a list of criteria for a preferable sensor selection.D4.5 EUROBALISE READER SENSOR AND DATA FDE FOR LOC-OB DESCRIPTION DOCUMENT
This document briefly explains what a “Balise Reader” is, which
errors can be found in them, and why no fault-detection techniques need to be
employed in a positioning system which uses data from the Balise Reader.
D4.10 ON BOARD DIGITAL MAP DEFINITION AND INTERFACES
The digital map interfaces with three LOC-OB functions: Initialisation
and Start of Mission, Track selectivity, and Along-track localisation. In
continuation of CLUG (1)’s initial digital map definition and interface, this CLUG 2.0 D4.10
document reflects a first definition and Interface Control Document (ICD) compatible
with the CLUG 2.0 WP4 prototyped algorithms and within SBB’s and SMO’s rail
context.
D2.4 LOC-OB System Requirements
The purpose of this deliverable is to define a set of requirements defining an onboard localisation equipment (a final product and not a demonstrator) derived from the information available in the D2.1, D2.2 and D2.3.DownloadD2.2. Start of Mission and Track Selectivity
The objective of this deliverable is to describe and analyse
the operational scenarios in order to derive constraints and recommendations
for the localisation on-board unit specifically for Start of Mission and Track
Selectivity. Therefore, operational scenarios are described from todays’
perspective with focus on localisation challenges during Start of Mission and
with regards to Track Selectivity. For this purpose, a set of operational
scenarios that are potentially challenging for the future localisation onboard
system is defined. The environmental conditions (e.g., tunnel) and operations
(e.g., standstill, acceleration) defined in CLUG (1) are referenced in the
operational scenarios.
DownloadD2.3 LOC-OB System Definition and Operational Context
This deliverable focuses on the system
architecture and the operational context of the LOC-OB component. The
complexity of the on-board CCS strongly influences design decisions for a
common architecture. CLUG promotes a modular approach that enables functional
isolation of all subsystems. A common communication bus allows the blocks to
exchange information. To provide the
operational context, the
proposed CLUG architecture is compared with the
existing ETCS solution and the proposals of preceding projects. A system under
consideration is then defined to identify the functional interfaces between the
LOC-OB component and its users and supporting systems.
DownloadD2.1 Operational Needs and System Capabilities of LOC-OB System
The main objective of this deliverable is to
analyse operational needs and operational context to derive the system
capabilities needed of a train on-board localisation system. It also targets to
specify a set of high-level user requirements for a localisation system that
fulfils the operational needs of its railway users. These high-level user
requirements are the basis for the system definition, design and evaluation.
Download
