## 4 Materials and Methods
### Onto-Customisation Management System Architecture and Modular Workflow  
Our system presents the architecture illustrated in Figure 1 which shows the structure of the main components and the interactions between the components, including the driver, DVI, driver profile ontology and vehicle ECUs via the CAN-BUS. The Onto-CMS was designed to manage driver preferences in HAVs, with the following structure:  
* **Driver**. At the heart of the system is the **Driver**, who interacts with the vehicle to set their preferences. * **User Interfaces System and DVIs**. Communication occurs via a **User Interfaces System**, consisting of **DVIs** which enable the driver to articulate preferences. These interfaces analyse user input and adjust vehicle settings accordingly. * **Customisation Management System (CMS)** The **CMS** monitors and evaluates the possibility of a change in driver preferences and controls and which settings are open to adaptation based on both the driver's input and vehicle's capabilities. * **Driver Profile Ontology**. A core component of the system is the **Driver Profile Ontology**, which serves as a knowledge base for vehicle attributes that can be adapted. Preferences are categorised into three classes: **customisable elements** (that the driver can change), **non-customisable elements** (which are fixed and cannot be changed) and **semi-customisable elements** (which can only be changed under certain conditions). In the ontology, these attributes are defined as properties or constraints, rather than as separate classes. * **Knowledge Graph (KG)** In addition to the driver profile ontology, the system incorporates a **KG** serving as a repository for real-time data. The ontology provides a logical structure and static constraints regarding what can be customised, while the **KG** contains dynamic information, such as the driver's current preferences, restrictions and the driving  
Figure 1: Architecture of Onto-CMS. environment. The **CMS** uses both the ontology and the **KG** to perform compatibility checks: it queries the driver profile ontology to determine whether the requested change is logically allowed and it queries the **KG** to retrieve specific real-time data (e.g., current vehicle state, saved preferences, active driver limitations). Once compatibility is confirmed with both, the **CMS** authorises the requested changes. The **KG** depends on the ontology as it relies on the rules and structure defined within the ontology to organise and update the data. * **ECUs Domains** The vehicle's functions are controlled by various **Electronic Control Units (ECUs)**. The **Propulsion ECU** controls the powertrain, including the engine and transmission; the **Safety ECU** controls safety-related functions such as braking and collision avoidance; the **Comfort ECU** controls comfort-related functions such as climate control and seat movement; and, finally, the **ADAS ECU** controls ADAS functions to further enhance safety and the driving experience. * **Controller Area Network (CAN-BUS)** These system components communicate over the **CAN-BUS**, a communication protocol that enables data exchange between microcontrollers and devices, eliminating the need for a central computing unit. The **Domain Gateway** acts as a bridge between the **CAN-BUS** and the various ECUs, routing preference updates to the corresponding units. After exploring the various components of the Onto-CMS architecture, Figure 2 represents the workflow which drives the system's processes. The workflow illustrates how user preferences are captured, validated and applied to ensure personalised interaction. Figure 2 illustrates each phase of the flow with a logical sequence that highlights the communication between the different components and the decisions taken along the process. The interaction begins when the driver sets their preferences through the DVI, indicating the settings they wish to change as follows:  
* **Phase 1: The driver sets preferences through the DVI.