## 4 On-Board Unit Implementation
### Software Architecture
**Global Positioning System (GPS):** An external GPS receiver is used to acquire the geographical coordinates of the vehicle (i.e., latitude, longitude, and altitude) and then forwards these information to the CAM, DENM, and JSON/MQTT Client modules. Figure 6: Software architecture of the OBU including the core modules of ETSI C-ITS stack, and other components to support UDP/HTTP and MQTT communications. **OBD2-CAN:** The OBD2-CAN module implements the connectivity to the in-vehicle sensors and actuators network either through an OBD or a CAN interface, as described in Section 4.3. Hence, the OBD2-CAN module is configured at run-time based on the availability of either OBD2 or CAN interface. The module retrieves the speed and acceleration of the vehicle and subsequently feeds these data into the CAM and DENM Services. If the module is configured to the CAN bus, then it can retrieve the detected events by on-board smart sensors for collision avoidance. Upon the detection of a road hazard, the OBD2-CAN module notifies the DENM service to trigger the transmission of a DENM. **DENM Service:** The DENM module is responsible for encoding and decoding DENM messages. The DENMs are event-triggered and can be generated upon the detection of road hazards as well as emulated though the Web Interface. The module fills the fields of DENM message, including geographical coordinates of the hazard and other in-vehicle sensory information provided by GPS and OBD2-CAN modules, respectively, as defined by the ETSI ITS specification [27]. The DENM message is passed to the V2X Message Manager to add the GeoNetworking and BTP headers. Upon reception of DENMs from the backend service, the DENM module extracts the GeoNetworking and BTP headers, decodes the fields of the DENM message, and forwards the relevant information of the event (type, position) to the LDM module. **CAM Service:** The CAM module is responsible for encoding and decoding CAM messages. The CAMs are generated periodically and included vehicle's dynamic parameters, attributes, location information, etc. The position of the vehicle is provided by the GPS module and the speed is provided by the OBD2-CAN module. The module fills the fields of CAM message at the facilities layer, as defined by the ETSI ITS specification [26], and passes it to the V2X Message Manager module where the GeoNetworking and BTP headers are added. The module also receives CAMs from the V2X Message Manager that are transmitted by other vehicles, extracts the relevant data, and forwards these data to the LDM module. **V2X Message Manager:** The V2X Message Manager module implements UDP-based communication interface between CAM and DENM modules and the backend service. The module inserts ETSI ITS compliant GeoNetworking and BTP headers into ASN.1 encoded CAM/DENM messages, encapsulates these messages into UDP packets, and then sends them in unicast to a UDP server allocated in the backend. Upon reception of UDP packets from the backend, the module decapsulates CAM and DENM messages, extracts the GeoNetworking and BTP headers, and forwards CAMs and DENMs to the respective CAM and DENM modules. **JSON and MQTT Client:** These two modules operate in concert upon selection of the MQTT-based communication mode. This, in turn, provides the seamless interoperability to establish connectivity with backend services, such as centralised traffic management systems or other vehicular services deployed outside of the edge cloud infrastructure, which are accessible through the public Internet. Importantly, these services may not be offered within the ACCA service, but operating as third-party services, e.g., a regional or a countrywide traffic management systems. The MQTT client implementation leverages the JSON encoding functionality to encode CAM and DENM messages and exchange with the interested parties over the MQTT protocol. We employ a direct translation of ASN.1 formatted CAM and DENM objects into JSON encoded messages.