## 4 On-Board Unit Implementation
### Software Architecture  
The software architecture of the experimental OBU shows in Figure 6. As depicted in the figure, the software architecture consists of decoupled modules that communicate with each other using the asynchronous ZeroMQ messaging library. In what follows, we describe the core functionalities of the OBU software modules. **Web Interface:** This module provides the GUI that operates as the HMI of the OBU, facilitating the interaction between the driver and the OBU. Through the Web Interface controllers, the driver is able to: (i) select the V2X protocol to communicate with the backend service (UDP/HTTP or MQTT); (ii) initiate the registration and authentication process with the backend service; (iii) configure the subscription parameters to an ROI; (iv) initiate a new subscription to an ROI or a sequence of periodic subscriptions; and, (v) emulate the detection of a road hazard by triggering the transmission of a DENM towards the backend service. In addition, the Web Interface shows the position of the vehicle on a map based on OpenStreetMap, including the locations of road hazards and  
Figure 5: Overview of DS7 vehicle’s embedded system. other vehicles. Furthermore, the Web Interface displays warning messages when the OBU receives DENMs about roadside incidents. **HTTP Server:** The HTTP server module acts as a middleware between the GUI and the rest of the modules of the OBU. The HTTP server implements a lightweight RESTful web service that translates the GUI-triggered REST commands into ZeroMQ compatible format and then forwards them to the target module. As can be seen in Figure 6, the HTTP server interacts with: (i) the Registration and Authentication module, (ii) the Subscription module, (iii) the DENM module, to trigger the transmission of a new DENM associated to an emulated road hazard, and (iv) the LDM module, to query the positions of the vehicle, road hazards, and other vehicles. **Registration and Authentication:** This module leverages HTTP(S) in order to register and authenticate the OBU in the backend service. This module is only used when the OBU operates in UDP and HTTP communication mode. The module implements an HTTP(S) client to generate REST commands that contain the credentials of the vehicle. In response, the backend service sends an authentication JSON Web Token (JWT), which is stored on the OBU for subsequent requests, and it is used to verify the authenticity of the OBU by the backend. Section 3.2 describes the process of registration and authentication. **Subscription to ROI:** This module configures the subscription parameters to an ROI through the Web Interface, and generates requests over HTTP POST. Upon change of an ROI, a new subscription is triggered towards the backend services or when the current subscription expires. The subscription parameters are the geographical coordinates and the area of the ROI within a certain radius, the reporting mode of the hazardous events occurred in the ROI, the type and freshness of the events based on time, and the duration of the subscription. Two approaches are employed by the backend to disseminate information to the vehicles. One approach is the request-response system where a vehicle can query at a time a specific event or all the events that occurred in the ROI. Alternatively vehicles can opt for an uninterrupted connectivity with the backend over a period of time to retrieve information as they occur in the ROI. **Local Dynamic Map (LDM):** This implements the connectivity to an SQL database, which stores the relevant information extracted from incoming CAM and DENM messages. In addition, the information of CAM and DENM are purged from the database once a pre-defined validity period is expired. The validity period of the information is defined based on the vehicular application requirements.