# OBU for Accurate Navigation through Sensor Fusion in the Framework of the EMERGE Project
## 2 EMERGE Onboard System Architecture  
This section describes the proposed architecture for achieving the EMERGE On board Unit (OBU). The objective is to present and use a generic architecture: easy to understand and implement, with a scalable structure compatible with different hardware platforms and operating systems. In this sense, the challenge is to define a harmonious level of abstraction that guarantees the following functionalities.  
* Compatibility: taking advantage of existing components, both: HW and SW (COTS).
* Efficiency: exploiting the advantage of the HW architecture used.
* Performance: establishment of specific metrics in each context.
* Portability: to guarantee compatibility with Operating Systems and HW.
* Operation: real-time or post-processing execution capability.
* Scalability: add/delete components: Sensors, SW, algorithms.  
We highlight the proposal of five specified layers based on their functionality and interaction with the navigation system. Including a monitoring layer allows the evaluation of prototypes and different scenarios, the detection of anomalies and problems in the singular components of the system and the evaluation of performances.  
Figure 1 shows the diagram of the proposed architecture. Each of the layers to which each element belongs is identified by a different colour. The connections, paths and formats/encoding used by each element of the OBU are specified. Below, some details of the functional blocks are presented.  
* Sensor (layer 1): includes all sensors capable of providing helpful information in the navigation process, i.e., GNSS receivers, inertial sensors, RTK stations, augmentation services, onboard sensors, and external clocks.
* Parser; Conditioner (layer 2): handles decoding/parsing and filtering information from the sensor level. When communication with sensors (configuration signals, request) is needed, this block also implements the appropriate coding/decoding process.
* Controller (layer 3): controls the start-up, interruptions, restart, and the change of parameters process (in the case of a dynamic scenario). In addition, it manages the possible changes in information flows that may occur between the Core layer and the Sensor layer.
* Core (layer 4): The system's centre contains all the navigation and information management algorithms. In this application, the Sensor Fusion algorithm and the Integrity SW components are located in this layer.
* Monitoring (layer 5): This layer monitors the system's performance in the navigation process and HW resources. It also introduces remote accessibility functionalities and possibly warning signals and notifications.  
The proposed blocks or components in each layer are intended to provide the required functionalities of the OBU. The first element to guarantee is connectivity (\"always connected\"). The OBU COMM and CRYPTO ENGINE blocks are external subsystems ensuring remote communication and IP-based services access. The system uses the connection to receive information from the Augmentation GNSS (AGNSS) systems and exchange information with traffic control elements: control centres, other vehicles, or early alert systems. The system proposes solutions based on loosely coupled integration between the inertial sensor measurements and the previously corrected GNSS navigation solutions. The modules involved in the navigation process are dedicated to decoding the information coming from the sensors, managing the information flows and synchronisation. The main objective is to integrate or fuse all useful navigation information to achieve higher levels of accuracy and integrity.