Ontology-Based Customisation Management System for Driver-Vehicle Interfaces: A Preventive Approach to Incident Reduction and Legal Accountability in Highly Automated Vehicles

Abstract

This study presents the development of an ontology-based customisation management system (Onto-CMS) for driver–vehicle interfaces (DVIs) in highly automated vehicles (HAVs). The objective of the proposed system is to enhance safety, minimise the probability of accidents and address legal liability concerns. The study highlights the importance of DVIs in automated vehicles and the need for safe and adaptable options for human drivers, while also considering the legal implications associated with the development of these interfaces. The research identifies the shortcomings of existing systems and proposes the Onto-CMS as a more effective alternative solution. The proposed system facilitates additional personalisation tasks and demonstrates higher performance compared to systems lacking ontological structuring. Indeed, the Onto-CMS allows dynamic adaptation to individual preferences while maintaining the integrity of standardised safety elements. It is distinguished by its ability to adjust to diverse contexts, such as those involving impaired drivers, without compromising critical safety standards. The onto-CMS reduces the need for recurrent revisions and improves operational productivity and overall usability. The results show that the Onto-CMS improves the configuration of DVIs by providing customised, scalable and context-aware alternatives. The study provides a basis for further research that could extend the system’s capabilities to cover a wider range of driver characteristics and requirements.

1. Introduction

In the next few years, the number of highly automated vehicles (HAVs) on the roads is set to increase dramatically. These vehicles will use the latest technology, including radar, LiDAR, GPS, sensors, digital cameras and driver control systems. All these components will integrate with the Internet of Things (IoT), enabling vehicles to communicate with their surroundings. This is a significant step in modern travel. It introduces new levels of autonomy and fundamentally changes people’s involvement in travel [1]. As HMIs serve as their main point of interaction, it is crucial for the vehicles’ interfaces to consistently offer precise and understandable information in various driving scenarios. The assurance of reliability is fundamental for drivers to maintain road safety standards and respond effectively to changing driving conditions. It remains imperative to ensure driver awareness to build confidence in the performance and reliability of these advanced systems [2].

Despite significant advances in the field of autonomous vehicles categorised as SAE Levels 3 and 4 according to the SAE J3016 standard [3], these vehicles still face numerous obstacles that limit their progress and deployment. These challenges include ensuring uniform behaviour among road users to reduce errors, misunderstandings and accidents; addressing safety concerns; understanding how people will behave while driving; and understanding how complicated the systems are [4]. The main challenge is the design and functionality of driver–vehicle interfaces (DVIs), which facilitate communication between drivers and the DVIs. DVIs will send the driver information about the vehicle and other systems and allow the driver to give feedback. Pitale and Bhumgara [5] said that user interfaces are important in ensuring seamless and efficient interaction between users and complex systems. As fully autonomous systems are still not a consolidated reality, interfaces must be clear and intuitive. This point is also highlighted by Cui et al. [6], who stress the importance of adapting interfaces to the specific needs of autonomous vehicle drivers. One of the main concerns is the accuracy of both technical and human language: any misunderstanding in the system’s messages could lead to serious consequences, such as accidents or malfunctions. For this reason, the development of well-designed and easily understandable interfaces is a priority in the evolution of these systems. Cui et al. [6] note that current designs tend to address an “average driver”, neglecting individual preferences and needs (see also [7] about the personalisation of interfaces).

Standardisation plays a crucial role in reducing the risk of accidents because it ensures consistency in systems, promoting security, usability and compliance with shared rules, avoiding errors and malfunctions. For instance, ISO and IEEE offer thorough guidelines in various situations. Standards like ISO 9241 [8], SAE J3016 [3], and ISO 26262 [9] set specific and practical guidelines for creating interfaces that are safe, intuitive, and reliable. However, Cunningham and Regan [10] express caution regarding the potential risks of these standards overstepping. They have highlighted that there is a danger of compromising the overall user experience if these requirements are pushed too far. Finding the right balance between personalisation and standardisation is therefore central to improving the safety and effectiveness of automated driving systems and their correct use in real-life situations.

These challenges are further complicated by individual differences among drivers, who vary in experience, skill level and confidence in using automated systems. The design of DVIs must therefore consider a wide range of users, while ensuring safe and intuitive operation. This balance raises additional legal and liability issues, as communication errors between the vehicle and the driver can lead to accidents, opening questions about liability [11].

Our approach consists of developing an ontology-driven adaptive system for DVIs that leverages a driver profile ontology to improve safety in interactions between humans and vehicles. The Onto-CMS allows dynamic adaptation to individual preferences while preserving the integrity of standardised safety elements. Therefore, the main contribution of our work consists of reducing the likelihood of accidents and addressing liability issues.

The Onto-CMS focuses on personalising the interfaces of vehicles for a driver, making driving more intuitive while adhering to standardised safety features. The system monitors driver behaviour in real-time and adjusts interface elements, ranging from design features to alerts, to match individual preferences.

Meanwhile, the system ensures that critical functions, such as emergency interface elements, remain operational and unaltered, thereby prioritising safety. For instance, the system is designed to prevent any modifications that could potentially compromise essential safety features. This is achieved through a rigorous examination of user inputs, ensuring no compromise of the system’s critical functionality.

The other key component of the Onto-CMS is the ontology of the driver’s profile, which acts as an extended data repository, holding the behavioural tendencies and needs associated with each driver. This information enables real-time adjustments, even in high-pressure or emergency situations. Therefore, the Onto-CMS integrates personalisation with safety, offering a friendly and trustworthy interface.

The development of this system is, thus far, informed by three key questions.

• How could an ontology of driver profiles be used to personalise interfaces without compromising the issues of safety and consistency?
• What aspects of the driver profile ontology must be globally standardised to ensure safety, while allowing flexibility for non-essential customisation?
• How would customised interfaces enhance performance and response times of drivers in life-critical situations?

The paper is organised as follows. Section 2 introduces the subject of HAVs and DVIs. Section 3 presents a review of the existing literature of current trends, methodologies and gaps in the field and discusses the challenges of creating safe and efficient interactions for all stakeholders. Section 4 outlines the methodology employed, focusing on the architecture of the Onto-CMS and its modular workflow (Section 4.1). It also details the development of the driver profile ontology (Section 4.2), the creation of a knowledge graph (KG) based on this ontology (Section 4.3), and the integration of the system with driver preferences to deliver real-time customisation (Section 4.4). Section 4.5 describes the implementation phase and focuses on the practical application of the Onto-CMS for driver preference management. Section 5 presents the results obtained, evaluating the effectiveness of the Onto-CMS in improving driver experience, interface design and safety. Finally, Section 6 discusses the implications of these results.

2. Background

This section presents an analysis of some of the concepts emerging from this research, including HAVs (Section 2.1) and DVIs (Section 2.2).

2.1. Highly Automated Vehicles

The main difference between conventional vehicles and HAVs is that the latter will integrate Intelligent Transport Systems (ITSs), which will enhance surface transport safety and efficiency through advanced technologies. These systems include environmental sensors and V2V and V2I communications. ITSs use data collection and the analysis of real-time information on road conditions, traffic and vehicle status to optimise route planning and improve responses to unforeseen scenarios [12,13,14]. Singapore has already implemented advanced ITSs that efficiently manage traffic flow and reduce accidents, thus demonstrating the full potential of these systems [15].

The Society of Automotive Engineers (SAE) framework provides a widely accepted taxonomy of advanced driver assistance systems (ADAS) [3], as summarised in

Table 1. Taxonomy of HAV automation levels according to SAE.

Level	Description
0	No Driving Automation
1	Driver Assistance
2	Partial Driving Automation
3	Conditional Driving Automation
4	High Driving Automation
5	Full Driving Automation

.

This paper focuses on Levels 3 and 4 of automation due to their distinct requirements for driver involvement.

Level 3 requires the vehicle to take control in certain situations, like driving on highways or in slow-moving traffic, while the driver must stay alert and ready to take over if needed. At this level, the DVI must provide clear, timely information to help the driver react quickly when needed [16]. On the other hand, Level 4 autonomy allows the vehicle to operate independently in certain areas or under certain conditions, such as in an urban environment with speed limits. In these scenarios, the driver’s involvement is no longer required [3]. The focus of the DVI is to provide updates on the vehicle’s status and operating parameters, ensuring intuitive interactions without compromising the driver’s role.

As HAVs continue to progress towards higher levels of autonomy, regulatory frameworks need to adapt to ensure their safe integration into the road network. In the EU, amendments to Regulation (EU) No 2018/858 established the legal basis for the approval of HAVs of SAE Level 3 and 4 in low-volume production from November 2022 [17]. Germany has enacted two major amendments to its Road Traffic Act (StVG): the 2017 amendment allowing for Level 3 automation and the 2021 amendment allowing for Level 4 automation outside of testing phases [18]. These laws address technical standards, operator roles, data management, and owner liability. Similarly, the UK’s Automated Vehicles Act 2024 has laid the foundation for the widespread use of automated vehicles from 2026 by outlining the initial requirements for the use of vehicles [19].

The continuous evolution of HAVs requires robust communication with their environment, which can be achieved through ad hoc networks such as the Internet of Vehicles (IoV). This enables vehicles to adapt to unexpected events in real-time, such as sudden braking by a preceding vehicle [20]. However, the effectiveness of these systems depends not only on the level of intelligence of the HAVs, but also on the reliability of the IoV. HAVs are designed to handle a wide range of situations. However, a poorly designed IoV may hinder drivers’ ability to interpret signals and make quick decisions, increasing the likelihood of accidents. Wang et al. [21] note that unreliable human–computer interaction systems can undermine safety by distracting drivers, exposing vehicles to cyber threats and decreasing user confidence. Distracted driving remains a leading cause of crashes, with the National Highway Traffic Safety Administration (NHTSA) predicting that distracted driving will lead to 3308 deaths and approximately 290,000 injuries in 2022 [22]. DVIs can also contribute to this issue because if these interfaces are not clear and intuitive they can force drivers to shift their attention away from the road to understand information, creating a distraction. Therefore, to reduce accidents, DVIs must be designed to communicate effectively and intuitively, presenting dynamic data from HAVs in a format that is easy for the driver to understand.

2.2. Driver–Vehicle Interfaces

DVIs are a particular type of Human–Machine Interface (HMI) that integrates hardware and software to enable efficient human–machine interaction.

This study focuses specifically on internal vehicle interfaces, excluding external interfaces that handle communication between the vehicle and other road users, such as pedestrians, cyclists and other motorists [23,24,25,26].

In-vehicle interfaces provide information and facilitate interaction with passengers inside the vehicle, using visual, tactile, or auditory cues. Campbell et al. [27] note that visual interfaces, such as dashboard or windscreen displays, provide vehicle status and driving information. Auditory interfaces rely on sounds or acoustic signals, such as beeps or warnings, to attract the driver’s attention, especially in critical situations. In contrast, haptic interfaces use physical feedback, such as vibrations in the steering wheel or seat, to communicate warnings without taking the driver’s eyes off the road. The NHTSA outlines these interface classifications in its “2016 Human Factors Design Guidance for Driver-Vehicle Interfaces” report [27], which also discusses general guidelines for interface design. For example, the report examines visual displays that convey safety messages, and focuses on certain aspects of these interfaces such as display placement, use of colour, readability of text, etc. The NHTSA’s goal is to ensure that interfaces are clear and unambiguous, avoiding driver distraction.

In 2018, the US government agency developed specific guidelines for designing automated vehicle interfaces, particularly for Levels 2 and 3 of automation [28]. These recommendations aim to describe principles that clearly convey the change of control from the driver to the automation, while ensuring that the driver develops a consistent mental model. Guidelines on best practises for designing driver-friendly messages are given through consideration of the most appropriate integration of sensory modalities: visual, auditory, and tactile. It focuses on the usability and clarity of these messages, synchronising signals and information with the driver’s needs. The design of interior interfaces must therefore be carefully considered to avoid misunderstandings or errors.

This need has developed a tendency to create customisable interfaces. However, customised interfaces risk fostering overconfidence in drivers who could be induced to reduce their attention while driving. Such overconfidence, combined with potential interface errors, could trigger inappropriate actions in the driver due to inaccurate information received from the interface itself. A key case is Sz Hua Huang et al. vs. Tesla Inc. (2018), which is currently under review by the Santa Clara County Superior Court in California. The case examines Tesla’s responsibility for a fatal accident on 23 March 2018 in which Walter Huang, an Apple engineer, was killed while driving his Tesla Model 101 on Route 101 in Mountain View, California. The lawsuit alleges that Tesla’s Autopilot misunderstood road signs and failed to detect a concrete barrier, causing the car to speed toward the barrier instead of slowing down. Huang’s family filed a lawsuit, citing product liability, failure to warn and misleading advertising claims. It also charged the state of California with inaction, alleging it had failed to install a guardrail that would have mitigated the damage caused by the crash. The NTSB confirmed Tesla’s Autopilot was engaged during the accident and failed to detect Huang’s hands on the wheel. The system also struggled to read the lane markings and was unable to detect the concrete median barrier. As a result, instead of braking, the system accelerated toward the barrier. The investigation also looked at Tesla’s warning systems, which are designed to alert drivers when their hands are off the steering wheel for an extended period, and hand-held monitoring systems on the steering wheel. The NTSB report concluded that these systems were not adequate to prompt timely driver intervention [29], confirming the need for more standardised and improved safety measures in these vehicles.

The Huang incident may be an example of the challenges of balancing customisation and standardisation in DVIs. In this case, it appears that an imbalance may have existed between the two elements in question. The customisation of the interface seems to have encouraged an over-reliance on the autopilot, which resulted in driver distraction while driving. The design flaws included the inability to distinguish lane markings and the inability to activate automatic braking, which exacerbated the problem.

3. Literature Review

This literature review examines the current state of research on user interface personalisation in HAVs. With the growing adoption of HAVs, there is a trend towards offering customisable interfaces to meet the individual preferences of drivers. However, this personalisation raises concerns regarding safety, regulatory compliance, and liability in the event of malfunctions. The review is divided into two subsections concerning the personalisation of user interfaces in HAVs (Section 3.1) and the liability and safety standards for HAVs (Section 3.2).

3.1. Personalisation of the User Interface in HAVs

The aim of this section is to analyse existing literature on the personalisation of the user interface in HAVs. There is a development towards making adaptable interfaces for individual preferences. In this context, it is essential to ensure a balance between personalisation and standardisation to guarantee safety, facilitate usability and comply with regulatory requirements.

Scott-Sharon et al. [30] indicate that although personalisation has the capacity to improve user experience and foster brand loyalty, there are also potential risks involved. These include the possibility of over-collecting data and creating designs that align with a narrow demographic’s preferences. In response to these challenges, classification systems have been established that delineate various levels and forms of personalisation. These systems identify standardised attributes that are necessary for maintaining consistency and safety while allowing for adjustments that enhance the user experience. Trende et al. [31] further developed this concept, adding a graphical front-end that enabled users to adjust driving style based on their judgement of the conditions to further enhance comfort and acceptance of the HAVs, but, again, also raised system complexity and user adaptability issues. Similarly, Zhao et al. [32] applied Personalised Adaptive Speed Control-P-ACC, which uses inverse reinforcement learning to adapt speed control to align with user preference for comfort and a reduced need for intervention. They also emphasised the need to maintain intuitiveness and system reliability across a wide range of users. Ren and Jiang [33] further advanced personalisation with an intelligent interface for autonomous cars, integrating KGs and AI algorithms. Their system combines ontology-like components with a semantic network that enables complex and context-aware personalisation. This constitutes a significant advance in the ability to adapt to complex scenarios and diverse user behaviour, moving away from simple preference-based systems. Similarly, in advanced driver-assistance systems, Hasenjäger et al. [34] proposed real-time adaptation to driver preferences and behaviour with respect to the functionality of a system. Their modular system, which includes functional blocks such as HMIs, dynamically interacts and continuously adapts to individual driver characteristics and environmental factors. Although this modular approach represents a promising solution, it also presents new challenges in terms of usability, as highlighted by Jameson et al. [35]. The researchers assume that the personalisation of user interfaces in autonomous vehicles is accompanied by many issues, such as user education, problems with response time and system predictability and understandability. One of the most central issues in the development of intuitive systems is finding a good balance between users’ preferences and the system’s capabilities.

Recent progress in advanced large language models (LLMs) create major possibilities for improving the interfaces of an autonomous vehicle. The Talk2Drive framework, proposed by Cui et al. [6], uses GPT-4 for translating natural language instructions into concrete actions with considerations of user-preferred weights on safety, efficiency and comfort. This system truly embodies the potential of AI in smoothing the interaction between users and vehicles through the understanding of complex human intentions. Also, Mao et al. [36] designed the “Agent-Driver” system that exploits advanced language models as cognitive agents for better decision-making in autonomous vehicles. By integrating tools and cognitive memory, this system helps the vehicle make more informed decisions. The next innovations focus on how LLMs allow a more natural and intuitive interaction between the driver and the vehicle, adding another dimension to personalisation. Yang et al. [37] showed that models such as GPT-4 improve the recognition of autonomous driving commands, allowing for easier and clearer communication between passengers and the vehicle. This capability helps to reduce cognitive load by improving the vehicle’s ability to understand and respond appropriately to natural language commands. Similarly, Azarafza et al. [38] carried out an analysis of the use of LLMs for hybrid agility in the context of autonomous driving, with a particular focus on challenging weather conditions. The simulations in CARLA demonstrate that the AI-based personalisation approach has higher performance outcomes compared to human performance in certain scenarios. Additionally, Wang et al. [21] presented DriveMLM, a framework that unifies the decision-making process and employs a multimodal language model to enhance the interpretation of sensory data and driving rules. In the same line of thought, Kong et al. [39] proposed a safety framework where LLMs are adopted to strengthen data-protection mechanisms and ensure regulatory provisions are satisfied to overcome the shortcomings of the existing safety systems. These inventions highlight the growing role of LLMs in improving the functionality and safety of HAV systems.

Although these emerging technologies have the potential to be transformative, significant challenges remain in terms of effectively implementing custom interface systems in real-world applications. Most work focuses on specific aspects, such as user interaction or real-time adaptation, without discussing how these components can be integrated into a coherent and reliable system. This omission hinders the creation of truly adaptive interfaces that would consider parameters such as user behaviour, the contextual parameters of the system, and environmental impact. While there are clear benefits to customisation, there are also risks associated with it, particularly in relation to privacy and data collection. A considerable number of studies are focused on enhancing user comfort. However, they offer limited guidance on achieving an optimal balance between personalisation and data protection. It can be reasonably argued that achieving this equilibrium is of the highest importance to maintain user confidence in autonomous driving systems. Furthermore, there is currently no consensus on the standards for personalisation. While some scholars argue that the standardisation of certain elements is crucial to guarantee security and consistency, the lack of such standardisation may lead to inconsistent user experiences and potential security vulnerabilities.

This paper, therefore, tries to fill the existing gaps by offering a comprehensive understanding of personalisation in the interfaces of autonomous vehicles. This paper aims to propose a more holistic and detailed framework that can harmonise personalisation, standardisation and safety. The approach is, hence, expected to improve users’ experiences and foster growing confidence in the autonomous driving systems.

3.2. Liability and Safety Standards for Highly Automated Vehicles

Safety standards are essential to ensure the reliability, predictability and proper functioning of advanced technologies such as HAVs. However, the absence of a clear and unified regulatory framework creates confusion, slows the adoption of these technologies and increases the risk of accidents related to poorly designed systems. The lack of robust standards also complicates the evaluation of safety measures and the determination of liability in the event of system failures.

Nassif et al. [40] highlight that current standards for HAV safety are inadequate, creating a constraint that prevents the transition from innovation to public acceptance. Their detailed analysis identifies several limitations, such as imprecise prescriptions for the control of user–system interactions, inadequate definitions of the operational design domains (ODDs), insufficient prescriptions on safety testing criteria and challenges brought about by machine learning, like algorithmic bias and flawed training data. Moreover, researchers put in evidence another relevant issue consisting of the lack of the standards uniformity. These limitations mean manufacturers face a fragile regulatory environment and have an increased risk of litigation. Such regulatory uncertainty reduces both the safety of HAVs and public confidence in them. For example, a driver preference management system must ensure that personalised interfaces are safe and adequately tested in all operational contexts. Failure to do so could lead to failures, which could result in the manufacturer being held liable. The manufacturer could be held liable for not ensuring that the interface customisation meets the minimum safety requirements.

In particular, the lack of comprehensive and reliable safety test methods leaves several critical elements of HAV performance untested. To address such shortcomings, Buiten [41] recommends regulatory and certification standards that would provide greater clarity and transparency. These standards would also help detect product failures using objective criteria, as well as cost–benefit and risk–utility analyses to encourage responsible HAV development. A robust regulatory framework would establish better clarity and predictability regarding legal determinations related to HAVs, reducing uncertainty about compliance assessments and, hence, nurturing more confidence in autonomous vehicles. Without a unified approach, fragmented safety practises and regulatory ambiguities will persist, hindering innovation in the autonomous vehicle industry. For example, the lack of testing and certification standards to evaluate customisations does not allow HAVs to demonstrate compliance with legal requirements. This gap creates uncertainty around liability attribution in the event of accidents, as no objective criteria exist to assess whether the preference management system was adequate or not.

Furthermore, determining liability in the event of accidents involving autonomous vehicles is a complex issue [42]. Aadhisha and Yashoda Sai Sri [43] note that in cases of sensor failure or system malfunction, or operational occurrences, it can be very difficult to determine who is liable. In all of these, a number of actors are involved, including designers, manufacturers, regulators and road managers. This division of liability makes it important for legal frameworks to clearly define who is responsible between a human and a machine, with full regard to public safety. Monot-Fouletier [44] declares such complexity gives reason to call for urgent legislation that should clearly define how responsibility should be attributed in the case of accidents involving driverless vehicles. For instance, if the preference management system makes errors in customisation, for example, by omitting a warning about the need to take manual control of the vehicle, a possible accident could complicate liability distribution between the system manufacturer, the driver and the vehicle manufacturer.

Another area where the lack of clear guidelines is evident is in the design of DVIs. These interfaces are critical in allowing interactions between the user and the system to be both safe and efficient. Poorly designed DVIs may increase the risk of safety because they obscure the driver’s ability to either understand warnings or react promptly. An illustrative example is the potential liability of manufacturers in the event of an accident caused by an inadequately designed interface. In these cases, the fault could lie in the interface design itself, which can lead to confusion or driver error. Wu et al. [45] show how poorly designed interfaces, particularly about the layout of elements, can impair driver performance and increase the risk of accidents. Studies in this area have revealed significant differences in reaction times, lane departures and other key safety parameters, highlighting the crucial role that interface design plays in influencing driver behaviour. A system that customises an interface by changing some of its features, such as text size, without considering any limitations on the driver’s visibility, could be the cause of an accident. In this case, the manufacturer could be held liable for violating safety rules related to the user interface.

Botero Arcila [46] puts in evidence how, in the EU, the Product Liability Directive (PLD) [47] and the Artificial Intelligence Regulation (AI Act) [48] highlight that an automated driving system must ensure not only technical safety but also a user-centred design which facilitates effective supervision. If a driver fails to respond promptly to a warning due to a poorly designed interface, the manufacturer may be held responsible for failing to meet public safety expectations. However, if the DVI design complies with European standards, it will be necessary to demonstrate that the design choices did not meet minimum transparency or auditability requirements before liability can be attributed to the manufacturer [46]. On the other hand, driver liability comes into play only when the driver has given informed consent and fully understands the risks associated with automated driving.

As Pattinson et al. [49] point out, if information regarding risks and liability is inadequately conveyed through unclear or inappropriate digital interfaces, the driver’s consent may be invalidated, raising questions about their own responsibility. If the driver accepts the risk of certain customisations whose effects are not fully understandable, this entails liability on the part of the manufacturer, who could be held guilty of lack of transparency by not having provided the driver with all the necessary information. In this case, the driver’s informed consent could be invalidated through violation of the principle of transparency.

Finally, it is unrealistic to consider liability as something separate between the manufacturer and the driver, as both parties usually share part of the burden. This is particularly true when a technical fault is compounded by human error. Widen and Koopman [50] argue that a lucid and crystalline legal framework can help deal more appropriately with the concept of shared responsibility. For example, if the personalised interface does not clearly signal the need for immediate manual intervention, debates on contributory negligence could arise. The confusion resulting from the lack of notification may lead to a complex attribution of responsibility between driver and manufacturer. Researchers propose a conceptual framework that specifies when a human driver could be held responsible due to contributory negligence in relation to an automated system. Their approach differentiates the operating mode of the vehicle into three separate modes: test, autonomous, and supervised, with criteria for liability shifting between the human operator and the automated system in various circumstances. This framework endeavours to explain when a party should be compelled to bear liability under specific conditions to ensure fairness and consistency within legal outcomes.

4. Materials and Methods

The system manages the driver’s preferences through a centralised structure, ensuring safe and consistent customisations. It uses an ontology to store profiles and adjust settings to enhance the driving experience without compromising safety.

A prototype of the Onto-CMS has been developed as an ontology-based personalisation management system to give drivers the ability of personalising their experience. The system addresses these personal preferences through a centralised framework, ensuring coherence and security in the customisations. The management system utilises driver preferences to determine whether those modifications can be implemented. This is achieved by querying an ontology that stores driver profiles and provides information about the accessibility of specific settings. If the settings are alterable, the approved changes will be transmitted to the pertinent vehicle components, such as the ECUs, for implementation into the vehicle components.

We proposed a system that closely resembles the approaches used to create information services in various fields, such as managing documents in the physical tax domain [51,52,53,54], managing critical safety systems such as those in automotive domain [20,55] or overseeing underground pipeline systems [56].

We developed the Onto-CMS using the steps described in

Table 2. Development steps and corresponding modules for Onto-CMS.

No	Step	Goals	Techniques
1 (Section 4.1)	Architecture Design	Develop a blueprint for the system architecture and general workflow.	Create UML diagrams.
2 (Section 4.2)	Creation of Driver Profiles Ontology	Construct an ontology that encapsulates driver preferences.	Utilise ChatGPT-4o [57] for initial ontology design. Validate manually against scientific literature and standards. Incorporate standard elements classified as non-modifiable.
3 (Section 4.3)	Developing KG using Driver Profiles Ontology	Define realistic data by creating ten user profile in accordance with the ontology concepts.	Extract classes and properties from the ontology. Identify relationships, subclasses and data properties using RDFLib version 7.1.1 [58]. Create ten user profiles based on the ontology concepts. Extract the concepts for realistic data, store the data in the JSON format, and map user preferences to the ontology concepts. Map data to align user profiles with ontology data to ensure they reflect the ontology characteristics. Connect user preferences to ontology properties. Validate data using SPARQL queries to ensure integrity and consistency with the ontology structure.
4 (Section 4.4)	Driver–Onto-CMS integration	Integrate the driver profile ontology with the KG to manage and retrieve driver preferences and update settings based on user inputs.	Load the OWL ontology and user profile data into RDFLib graphs. Define and execute SPARQL queries to retrieve and validate driver preferences from the KG and update settings. Implement logic to allow or disallow changes based on preference type.
5 (Section 4.5)	Management of Driver Preferences with Onto-CMS	Demonstrate that the Onto-CMS effectively manages driver preferences.	Conduct one use case in normal and two use cases in critical conditions. Perform integration use cases of drivers with the Onto-CMS.

.

4.1. 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 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.
  The driver selects their preferences via the DVI, specifying which settings they want to adjust.
• Phase 2: DVI queries the Onto-CMS to check modifiability.
  The DVI then queries the Onto-CMS to determine which preferences can be modified. It communicates with the driver profile ontology to check the modifiability of the requested preferences. The ontology defines the structure and rules governing driver preferences (e.g., which settings can be modified based on the driver’s profile) and sets any restrictions (for example, novice drivers may have limited ability to modify ADAS settings).
• Phase 3: KG real-time data check.
  At the same time, the Onto-CMS queries the KG, which stores real-time data regarding the driver, such as their driving experience, preferences and restrictions. The Onto-CMS and KG work together to evaluate if requested changes are feasible and comply with the driver’s unique profile.
• Phase 4: Modifiability: Allowed or not.
  Once both the ontology and the KG confirm that specific preferences can be modified, the system proceeds.
  If YES, the changes are permitted. The DVI sends the updates to the CAN-BUS, ensuring the KG is updated synchronously with all modifications. The CAN-BUS then transmits these updates to the Domain Gateway, which routes them to the appropriate ECUs (Propulsion, Safety, Comfort and ADAS).
  If NO, the requested modification is denied. The DVI knows that some preferences cannot be modified by the Onto-CMS, and it notifies the driver that this modification is not possible. This allows the driver to always know when changes are rejected by the modifiability tests performed by the ontology and the KG. In this case, the DVI does not send any messages to the ECUs, only a notification to the driver.
• Phase 5: ECUs update preferences.
  After the ECUs update their settings based on the driver’s preferences, it sends feedback to the DVI. This feedback includes confirmation of the successful update or details about any errors that occurred. The system only sends changes to the ECUs if the modifiability check is authorised, ensuring that unauthorised or potentially dangerous modifications do not take place.
• Phase 6: Feedback to the driver.
  Once the ECUs implement the changes to the driver’s preferences, the Onto-CMS performs the following functions: (i) it updates the KG to record the latest preferences, ensuring the KG reflects the current state of the system, and (ii) it sends feedback to the driver to notify them that their preferences have been updated.

4.2. Development of Driver Profile Ontology

The creation of the DVI ontology included standardised and customisable elements according to driver profiles in a structured process, as follows:

• Defining the scope: The first phase was to clarify the objectives and scope of the ontology. We identified which DVI elements could be standardised or customised, considering driver profiles such as driving preferences, style and adjustable vehicle settings. To define whether certain DVI elements could be standardised or customised, we followed the following method. We categorised DVI elements, grouping them into functional categories (such as security, accessibility, usability). These categories were linked to applicable standards or regulations, such as ISO (e.g., 9241 [8], 21434, GDPR, etc.). Finally, the elements that were taken from the standards were classified into three groups: non-customisable, because they must remain static for security or compliance reasons; customisable, because they can vary without compromising security or compliance; and conditionally customisable, because they can vary within limits specified by the standards. The process of defining the boundaries of the ontology was essential for ensuring that only the most relevant details and information are captured, thereby facilitating the provision of personalised support.
• Building the ontology: The second stage of the process was to develop the ontology within the defined scope. The process included the following elements: (i) The creation of a guide or table outlining the structure of the ontology framework. The guide enumerates the necessary classes, properties and relationships for the proper representation of driver preferences and vehicle elements that are customisable within the ontology. (ii) The utilisation of tools such as ChatGPT-4 for the construction of the ontology. This phase identified key entities such as driver profiles, customisable DVI elements and vehicle constraints. The way in which these entities interact was also defined, i.e., how a driver profile influences certain interface elements under certain conditions. Properties such as seat position and climate control settings were assigned to the entities.
• Enriching the ontology: When the preliminary model was ready, we enriched the ontology by adding more concepts about driving profiles and both standardised and customisable DVI elements. New classes, properties and subclasses were added to the ChatGPT design model to create a more complex and contextual model. Additionally, we reviewed the existing literature and incorporated relevant standards to further enhance the ontology.

Figure 3 represents a segment of the driver profile ontology used for the two use cases in critical conditions discussed in Section 4.5. The image illustrates the classes, subclasses, object properties and properties.

Figure 4 shows the properties specific to the Driver Profile and Figure 5 illustrates the properties specific to the EmergencyPedalIcon, detailing how each relates within the ontology’s structure.

Table 3. Summary of phases in driver profile ontology development for DVIs.

No	Phase	Description
1	Define purpose and scope of ontology	Identify which aspects of the DVIs can be standardised or tailored and develop boundaries where appropriate.
2	Ontology development	Develop the ontology by focusing on two main parts: (i) providing a guide or table that reflects the classes, properties and relationships of the ontology, and (ii) using tools such as ChatGPT-4o to assist in drafting ontology concepts.
3	Enhancing ontology	Enrich the ontology by integrating new concepts based on standardised DVI elements, informed by the literature review and industry standards.

summarises the development phases of the driver profile ontology.

4.3. Developing a Knowledge Graph Using the Driver Profile Ontology

The integration of the ontology into a KG involved key steps, including the creation of ten realistic user data profiles and mapping these data into the Resource Description Framework (RDF) format.

• Creating realistic user profiles. We created ten user profiles using RDFLib version 7.1.1., a Python library for working with RDF, to perform the conversion. First, it extracted the main classes from the ontology, then the subclasses to build a hierarchy of the ontology’s entities. The hierarchy showed the main categories and types in the ontology, which was useful for analysis. We then extracted object properties and data properties. Once the classes and properties are defined, we could create realistic instances based on user profiles, vehicle capabilities and adaptation conditions. We started by identifying key classes and properties from the ontology that represented different driver characteristics. We identified different types of drivers and the driving behaviours and modes they use. We included comfort settings that each driver type would prefer. Commercial drivers may prefer a higher seat position and a cooler cabin temperature, while older drivers may adjust their settings based on the driving environment. Furthermore, multimedia preferences were also included, for example, music genres providing variability and realism. In addition, most profiles were cross-platform, so they worked on iOS and Android. Regarding data security and privacy, we included features like data encryption and biometric authentication, particularly for commercial drivers.

Table 4. User profiles with driving preferences and settings.

User Profile	Type	Mode	Behaviour	Comfort	Media	Platform	Security
1. Mary	Comm. Dr.	Highway	Assertive	Seat: High; Climate: Cool	Jazz	iOS; Android	Encryption
2. Anne	Exp. Dr.	Urban	Defensive	Seat: Std; Climate: Warm	Rock	iOS	Biometric
3. Luc	Nov. Dr.	Rural	Anxious	Seat: Low; Climate: Mild	Pop	Android	Data Prot.
4. Giuly	Exp. Dr.	Off-Road	Aggressive	Seat: Adj.; Climate: Cool	Country	iOS; Android	High Sec.
5. Marc	Nov. Dr.	Urban	Defensive	Seat: Std; Climate: Neutral	Electronic	Android	Encrypted
6. Sophie	Comm. Dr.	Highway	Assertive	Seat: High; Climate: Cool	Classical	iOS	Compliance
7. Robert	Exp. Dr.	Urban	Risky	Seat: Low; Climate: Warm	Hip-Hop	Android	Alerts
8. Jasmine	Nov. Dr.	Rural	Anxious	Seat: Std; Climate: Mild	Alt.	iOS; Android	Logging
9. Frederik	Exp. Dr.	Highway	Defensive	Seat: Adj.; Climate: Warm	80s Hits	iOS; Android	Integrity
10. Klaus	Comm. Dr.	Urban	Assertive	Seat: High; Climate: Cool	Chillout	Android	Mitigation

LEGEND: Type: Comm. Dr. = commercial driver; Exp. Dr. = experienced driver; Nov. Dr. = novice driver. Mode: Highway = highway driving; Urban = urban driving; Rural = rural driving; Off-Road = off-road driving. Behaviour: Assertive = confident driving; Defensive = cautious driving; Aggressive = bold driving; Anxious = nervous driving; Risky = risk-prone driving. Comfort: Seat: High = high position; Std = standard; Low = low position; Adj. = adjustable. Climate: Cool = cool; Warm = warm; Mild = moderate; Neutral = neutral temperature. Media: Preferred genre: Jazz, Rock, Pop, Country, Classical, Hip-Hop, Electronic, Alt. (Alternative), 80s Hits, Chillout. Platform: iOS; Android = preferred operating system(s). Security: Encryption = data encryption; Biometric = biometric authentication; Data Prot. = data protection; High Sec. = high security; Compliance = standards compliance; Alerts = security alerts; Logging = activity logging; Integrity = data integrity; Mitigation = risk mitigation.

summarises the results of this instantiation, detailing the configurations of different driver profiles and showcasing their unique preferences and attributes.

• Mapping information into RDF: After generating the instances, we mapped the information into the RDF format. This step organised the information into a semantic graph, where each user profile and its characteristics were represented as entities connected by well-defined relationships. This approach allowed the data to be interoperable with other systems and ontologies, facilitating information sharing. Complex queries are supported by SPARQL, enabling deep data analysis.

In our project, the user profile dataset was relatively small and well-structured, so there was no need for real-time data flow management. We decided to use RDFlib for the conversion process, which allowed us to manually transform these data into RDF triples. During this process, we programmatically defined resources (using URIs), properties and values to populate the graph. Because the data were already well-organised, we did not need extensive preprocessing before the conversion. Using the generated data (Table 5), we created an RDF graph. Each user received a unique URI, which served to represent their preferences, driving habits, and security features. For every user profile, we included attributes such as driver type, driving mode, driving behaviour, comfort preferences, multimedia choices and security measures. These attributes were encoded as RDF triples to provide a detailed and semantic representation of the data. The following code snippet (Listing 1) demonstrates how driver profiles were semantically encoded in RDF.

Listing 1. Semantic representation of some driver profiles in RDF format.

@prefix ocms: <http://cui.unige.ch/ocms#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ocms:Mary a ocms:UserProfile ;

ocms:hasType ocms:CommercialDriver ;

ocms:hasMode ocms:Highway ;

ocms:hasDrivingBehavior ocms:Assertive ;

ocms:hasComfortSettings "Seat: High, Climate: Cool" ;

ocms:hasMultimediaPreferences "Jazz" ;

ocms:hasPlatform "iOS, Android" ;

ocms:hasSecurity ocms:Encryption .

ocms:Anne a ocms:UserProfile ;

ocms:hasType ocms:ExperiencedDriver ;

ocms:hasMode ocms:Urban ;

ocms:hasDrivingBehavior ocms:Defensive ;

ocms:hasComfortSettings "Seat: Standard, Climate: Warm" ;

ocms:hasMultimediaPreferences "Rock" ;

ocms:hasPlatform "iOS" ;

ocms:hasSecurity ocms:Biometric .

ocms:Luc a ocms:UserProfile ;

ocms:hasType ocms:NoviceDriver ;

ocms:hasMode ocms:Rural ;

ocms:hasDrivingBehavior ocms:Anxious ;

ocms:hasComfortSettings "Seat: Low, Climate: Mild" ;

ocms:hasMultimediaPreferences "Pop" ;

ocms:hasPlatform "Android" ;

ocms:hasSecurity ocms:DataProtection .

ocms:Giuly a ocms:UserProfile ;

ocms:hasType ocms:ExperiencedDriver ;

ocms:hasMode ocms:OffRoad ;

ocms:hasDrivingBehavior ocms:Aggressive ;

ocms:hasComfortSettings "Seat: Adjustable, Climate: Cool" ;

ocms:hasMultimediaPreferences "Country" ;

ocms:hasPlatform "iOS, Android" ;

ocms:hasSecurity ocms:HighSecurity .

"""

Table 5 summarises the phases in developing a KG through the driver profile ontology.

Table 5. Summary of phases in developing a KG using driver profile ontology.

No	Phase	Description
1	Creating realistic user profiles	Realistic user profiles are created by specifying attributes and preferences for each profile, including comfort settings and multimedia preferences, represented in JSON for compatibility and clarity.
2	Mapping information into RDF	User profiles are mapped to data extracted during the ontology definition phase. This process ensures that user characteristics are accurately aligned with ontology properties, enabling seamless integration and data analysis.

Table 5. Summary of phases in developing a KG using driver profile ontology.

No	Phase	Description
1	Creating realistic user profiles	Realistic user profiles are created by specifying attributes and preferences for each profile, including comfort settings and multimedia preferences, represented in JSON for compatibility and clarity.
2	Mapping information into RDF	User profiles are mapped to data extracted during the ontology definition phase. This process ensures that user characteristics are accurately aligned with ontology properties, enabling seamless integration and data analysis.

4.4. Driver Preference Management System Integration

In this phase, the driver profile ontology was integrated with the KG to manage, validate and update driver preferences based on user inputs. The system retrieves detailed information about the preferences, determines which settings can be adjusted, and updates the KG accordingly.

• We developed a Python script that loads the driver profile ontology and KG, queries driver preferences and updates comfort settings for a specific driver. The following SPARQL query (Listing 2) retrieves detailed information about the preferences of a specific driver, Anne. This query gathers various attributes associated with her driving profile, such as driving type, behaviour and comfort settings (see results in Figure 6)

Listing 2. SPARQL query to retrieve Anne’s driver preferences.

SELECT ?drType ?drBehavior ?comfSettings

WHERE {

ocms:Anne ocms:hasType ?drType .

ocms:Anne ocms:hasDrivingBehavior ?drBehavior .

ocms:Anne ocms:hasComfortSettings ?comfSettings .

}

• When preferences need to be updated, the system identifies which specific settings can be modified. Preferences like driving mode and comfort settings are adjustable, while others remain fixed. When Anne requests an update, the DVIs send the user request to the Onto-CMS, which verifies which preferences can be altered. The following SPARQL query (Listing 3) forwards Anne’s current preferences to the Onto-CMS for validation (see the corresponding results in Figure 7).

Listing 3. SPARQL query to forward Anne’s preferences to Onto-CMS.

PREFIX ocms: <http://cui.unige.ch/ocms#>

SELECT ?preference ?modifiability

WHERE {

{

ocms:Anne ocms:hasSafetySettings ?safety .

?safety ocms:modifiable ?modifiability .

BIND("Emergency Pedal Icon" AS ?preference)

}

UNION

{

ocms:Anne ocms:hasDrivingMode ?mode .

?mode ocms:modifiable ?modifiability .

BIND("Driving Mode" AS ?preference)

}

UNION

{

ocms:Anne ocms:hasComfortSettings ?comfort .

?comfort ocms:modifiable ?modifiability .

BIND("Comfort Settings" AS ?preference)

}

UNION

{

ocms:Anne ocms:hasMultimediaPreferences ?multimedia .

?multimedia ocms:modifiable ?modifiability .

BIND("Multimedia Preferences" AS ?preference)

}

}

• If a preference can be changed, the system replaces the old value with the new one to ensure the KG reflects the latest choices. The following SPARQL query (Listing 4) demonstrates how Anne’s driving mode is updated (see the corresponding results in Figure 8).

Listing 4. SPARQL query to update Anne’s preferences.

PREFIX ocms: <http://cui.unige.ch/ocms#>

DELETE {

ocms:Anne ocms:hasDrivingMode ?oldDrivingMode .

ocms:Anne ocms:hasComfortSettings ?oldComfortSettings .

ocms:Anne ocms:hasMultimediaPreferences ?oldMultimediaPreferences .

}

INSERT {

ocms:Anne ocms:hasDrivingMode ocms:HighwayDriving .

ocms:Anne ocms:hasComfortSettings "Seat: Adjustable, Climate: Cool" .

ocms:Anne ocms:hasMultimediaPreferences "Jazz" .

}

WHERE {

ocms:Anne ocms:hasDrivingMode ?oldDrivingMode .

ocms:Anne ocms:hasComfortSettings ?oldComfortSettings .

ocms:Anne ocms:hasMultimediaPreferences ?oldMultimediaPreferences .

}

• At the conclusion of the process, Anne receives feedback through the DVI. If the change succeeds, the system displays: “Your preference has been updated”. If the modification is not permitted, she receives the message: “You cannot modify the emergency pedal icon”.

From Listing 4, it emerges that only three of Anne’s preferences were successfully updated. However, her request to remove the pedal settings was denied. This preference does not appear among the modifiable options because pedal settings are classified as non-modifiable. The icon cannot be removed, but other features can still be adjusted (see use cases in Section 4.5.1 and Section 4.5.2). Consequently, Anne was then notified that this adjustment was unsuccessful.

Table 6. Integration phases of driver preferences management.

No.	Phase	Description
1	Retrieve preferences	Query the KG to gather the current driver preferences and validate their modifiability status. This phase involves: (i) querying the KG to retrieve the driver’s current preferences and validate the modifiability of each preference using the driver profile ontology, and (ii) classifying preferences as modifiable, semi-modifiable or non-modifiable.
2	Update preferences	Verify the modifiability of each preference before updating. If a preference is modifiable, the old value is removed, the new value is inserted and the driver is informed of any changes or restrictions regarding non-modifiable preferences.

sums up the phases to develop the driver preference management system integration.

4.5. Management of Driver Preferences with Onto-CMS

This section demonstrates how driver preferences are effectively managed using the Onto-CMS. We considered a standard setup case and two on-road scenarios involving driver and traffic conditions.

• Standard Setup Case (Off-Road) (Section 4.4)

In this scenario, when Anne starts the HAV, the Onto-CMS automatically loads her saved interface settings. For new drivers, a setup tutorial guides the configuration of initial preferences, such as dashboard layout and audio alert settings. Some system-critical icons, like the brake indicator, are fixed to ensure safety. For example, if Anne tries to remove a fixed icon, the DVI queries the Onto-CMS (see Listing 3) to check its immutability. If the icon is deemed immutable, the system prohibits its removal, protecting the vehicle’s core functions.

While driving, the Onto-CMS monitors Anne’s manipulations with the interface. If she engages in unsafe behaviour, the system provides real-time feedback and certain features may be temporarily disabled to prioritise safety.

At the end of the trip, the system updates Anne’s profile with any new preferences, ensuring a consistent and personalised experience on future drives (see Listing 4).

• Two On-Road Cases with Specific Driver and Traffic Conditions (Section 4.5.1 and Section 4.5.2).

These scenarios show how the Onto-CMS acts as a “mediating tool” to balance the customisation and standardisation of interface elements. We present two use cases. The first use case assesses the Onto-CMS’s ability to enforce the immutability of a standardised safety element, such as the emergency pedal icon, preventing its removal from the display. Two variants of this use case were compared: (A) with Onto-CMS, and (B) without Onto-CMS, which employs a more basic system structure.

In this scenario, the Onto-CMS adjusts the emergency pedal icon for enhanced visibility and accessibility while adhering to safety standards. Anne cannot remove the fixed pedal icon, but she is allowed to modify some features of the icon, as long as she complies with the standardisation rules that require the icon to remain in place. This use case also presents two variants: (A) with Onto-CMS, and (B) without Onto-CMS.

These two variants allowed us to assess the added value of the Onto-CMS when compared with a simpler form of the setup.

4.5.1. Use Case No. 1: Managing Critical Customisations in the DVI to Prevent Accidents

Use-case: Anne is a 60-year-old driver with forty years of driving experience. She has hearing loss, and she has also had problems with her peripheral vision. However, Anne is also a very cautious driver. She drives a car that is equipped with an assisted driving system and a highly personalised, user-friendly interface. The notifications on the car’s dashboard appear as big, bright messages right in the middle of the screen, which are easier to see even with limited peripheral vision. In addition, the car is equipped with enhanced warning tones to accommodate her hearing loss, while a voice assistant provides loud notifications so that Anne does not miss any of the alerts. One day, Anne is driving in heavy traffic and approaches a busy intersection. The closer she gets to the junction, the more warnings the car’s assistance system sends out. At that moment, Anne notices a cyclist approaching the intersection from a side road, which demands her immediate attention. However, Anne had previously hidden or moved the emergency pedal icon out of view, which is a feature that should always be in view. This change prevented her from acting quickly, leading to the accident. Without a clear visual cue for the emergency pedal, Anne was unable to complete the necessary emergency action within the given time frame.

To provide more evidence of the effects of these changes, we carried out a driving simulation. As Algorithm 1 shows, Anne’s response time improves significantly when the warning system is effective, with the emergency pedal icon displayed continuously. However, once she hides or alters the emergency pedal icon, she fails to respond effectively, despite receiving both visual and auditory warnings. This scenario highlights the potential dangers of over-customisation and its impact on safety.

Algorithm 1 Output Simulation Use Case no. 1

1: Start Simulation

2: Initialise the Vehicle Assistance System

3: Cyclist Detection:

4: if Cyclist approaching at high speed from the side street then

5:    Set Cyclist Detected ← True

6: end if

7: Generate Warning:

8: if Cyclist Detected = True then

9:      Display visual warning: “Warning: Cyclist approaching at high speed!”

10:    Play audio warning: “Warning: Cyclist approaching at high speed!”

11: end if

12: Check Emergency Pedal Icon:

13: if Emergency pedal icon not customised then

14:     Display emergency pedal icon

15: else

16:     Set Icon Customised ← True

17: end if

18: Anne’s Reaction:

19: if Icon Customised = False then

20:      Anne sees the icon and reacts promptly by applying the brakes

21: else

22:     Anne cannot see the icon and is unable to react in time

23:     Reaction Delay

24: end if

25: Check Outcome:

26: if Anne reacts on time then

27:     Collision is avoided successfully

28: else

29:     Collision occurs due to delayed reaction

30: end if

31: End Simulation

Objective. This use case shows how the Onto-CMS can flexibly correct over-customisation, particularly in scenarios like Anne’s, by limiting the modification of critical safety features. The Onto-CMS can limit the customisation of safety-critical elements, such as the emergency pedal icon. It prevents the removal or complete deactivation of essential parts of the icon, ensuring that vital safety features always remain accessible and visible.

Use case variants. We present the same scenario in two different options: (A) A variant with the Onto-CMS, where the system dynamically adapted the vehicle interface to the driver’s needs while prioritising safety. Using the ontology, the CMS determined which elements of the interface could be modified, providing a safe and controlled adaptation; and (B) a variant without the Onto-CMS.

(A) 

Correcting over-customisation of the interface by implementing the Onto-CMS

The Onto-CMS mediates between customisation and standardisation. It defines which interface elements can be customised, and which must remain unchanged to maintain security and consistency. The system prioritises the driver’s safety over customisation. For instance, if the driver requests to hide the emergency button, the Onto-CMS intervenes by blocking this customisation and notifying the driver that the icon cannot be modified. Below is a demonstration of how the Onto-CMS operates:

• We focused on a segment of the driver profile ontology that includes classes and properties relevant to the specific case. These categories included DriverProfile, DriverType, DrivingBehaviour, ComfortSettings, SecuritySettings and ADASSettings, and the key properties hasType, hasDrivingBehaviour, hasComfortSettings, hasSecuritySettings, hasADASSettings, etc. (see Figure 3). Additionally, we defined properties to specify whether a setting was editable, semi-editable, or non-editable. For example, the emergency pedal icon might be a non-editable property (see Figure 4 and Figure 5).
• Then, we developed the KG. Based on

  Table 7. Summary of the elements of use case no. 1.

  Driver	Details
  Name	Anne
  Age	60 years
  Gender	Female
  Driving Experience	40 years
  Physical Needs	Hearing loss, difficulty in peripheral visual perception
  Driving Style	Cautiousness
  Vehicle	Details
  Vehicle	3L SAE and highly customised interface
  Dashboard	Layout with large, bright central notifications, amplified warning sounds, customisable emergency button
  Voice Assistant	Loud voice notifications to compensate for hearing loss
  Incident	Details
  Driving Circumstances	An urban area with heavy traffic, driving towards a crowded intersection.
  Result of the Accident	A cyclist approaches quickly, but the configuration of the interface focuses the driver’s attention on central information. The guidance system detects the cyclist and gives a visual warning to the driver, but the driver does not immediately perceive the warning.
  Cause of the Accident	– The loss of peripheral visual perception by the driver, who failed to notice objects moving at the edge of her field of vision, such as the cyclist. – The customisation of the interface led the driver to focus on central notifications, distracting her from what is happening around her. – The customisation of the interface made the emergency pedal icon, a crucial element in activating an emergency manoeuvre, invisible or unclear. This limited her ability to brake quickly when she finally noticed the cyclist.

  , we structured the case study data in JSON format.

The data represented in Listing 5 illustrates Anne’s characteristics and preferences, including ADAS settings, and clearly organises the information in JSON format.

Listing 5. JSON representation of Anne’s profile preferences.

{

"driverId": "driver_Anne",

"driverAge": 60,

"driverExperience": 40,

"hearingLoss": true,

"visualImpairment": true,

"drivingBehaviour": "Cautious",

"comfortSettings": {

"notificationType": "LargeNotifications",

"seatPosition": "Standard",

"notificationBrightness": "Bright",

"climatePreference": "Moderate"

},

"securitySettings": {

"hearingCompensation": "AmplifiedSound",

"visualCompensation": "BrightNotifications"

},

"adasSettings": {

"emergencyPedalIcon": "Visible",

"voiceAssistant": "Enabled",

"assistedDrivingSystem": "Enhanced",

"multiSensoryAlerts": "Enabled",

"peripheralAlertSystem": "Active"

},

"interfaceSettings": {

"focusArea": "CentralAndPeripheral",

"emergencyButton": "Customizable, Highly Visible",

"visualWarnings": "BrightFlashingPeripheral",

"auditoryWarnings": "LoudWithDirectionalCues" }

}

Then, we mapped the JSON data into RDF, associating each piece of data, such as the driver type, with the concepts defined in the ontology (Listing 6).

Listing 6. A portion of RDF representation of Anne’s driver profile.

@prefix ocms: <http://cui.unige.ch/ocms#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ocms:DriverProfileAnne a ocms:DriverProfile ;

ocms:hasADASSettings ocms:ADASSettingsAnne ;

ocms:hasComfortSettings ocms:ComfortSettingsAnne ;

ocms:hasDrivingBehaviour ocms:DrivingBehaviourCautious ;

ocms:hasSecuritySettings ocms:SecuritySettingsAnne ;

ocms:hasType ocms:DriverTypeExperienced .

ocms:EmergencyPedalIconAnne a ocms:EmergencyPedalIcon ;

ocms:modifiability "non-modifiable" .

ocms:hasADASSettings a rdf:Property ;

rdfs:domain ocms:DriverProfile ;

rdfs:range ocms:ADASSettings .

ocms:hasComfortSettings a rdf:Property ;

rdfs:domain ocms:DriverProfile ;

rdfs:range ocms:ComfortSettings .

ocms:hasDrivingBehaviour a rdf:Property ;

rdfs:domain ocms:DriverProfile ;

rdfs:range ocms:DrivingBehaviour .

ocms:hasSecuritySettings a rdf:Property ;

rdfs:domain ocms:DriverProfile ;

rdfs:range ocms:SecuritySettings .

ocms:hasType a rdf:Property ;

rdfs:domain ocms:DriverProfile ;

rdfs:range ocms:DriverType .

ocms:modifiability a rdf:Property ;

rdfs:domain ocms:EmergencyPedalIcon ;

rdfs:range rdfs:Literal .

ocms:ADASSettingsAnne a ocms:ADASSettings ;

ocms:assistedDrivingSystem "Enhanced" ;

ocms:emergencyPedalIcon "Visible" ;

ocms:multiSensoryAlerts "Enabled" ;

ocms:peripheralAlertSystem "Active" ;

ocms:voiceAssistant "Enabled" .

ocms:ComfortSettingsAnne a ocms:ComfortSettings ;

ocms:climatePreference "Moderate" ;

ocms:notificationBrightness "Bright" ;

ocms:notificationType "LargeNotifications" ;

ocms:seatPosition "Standard" .

ocms:SecuritySettingsAnne a ocms:SecuritySettings ;

ocms:hearingCompensation "AmplifiedSound" ;

ocms:visualCompensation "BrightNotifications" .

It is noted that the class EmergencyPedalIcon is non-modifiable.

• Finally, the Onto-CMS takes action. The DVI sends a SPARQL query (see Listing 7) to the Onto-CMS to check whether the emergency pedal icon is modifiable. If the icon’s modifiability is set to non-modifiable, the DVI blocks any changes.

Listing 7. Query to check if the emergency pedal icon is modifiable.

SELECT ?modifiability

WHERE {

?icon a ocms:EmergencyPedalIcon .

?icon ocms:modifiability ?modifiability .

• If the system sets the icon to non-modifiable, the Onto-CMS sends a message to the DVI informing that the modification is not allowed. The DVI then blocks the change and notifies the driver that the emergency pedal icon cannot be modified (see Listing 8).

Listing 8. Use case no. 1—notified message from DVI to Anne.

DVI: Modification not allowed. The emergency pedal icon is non-modifiable.

DVI to Driver: You cannot modify the emergency pedal icon.

The Onto-CMS ensured the immutability of a standardised element, such as the emergency pedal icon, preventing its removal from the display. This illustrates the adaptability of an Onto-CMS that adapts to the user’s preferences while also respecting the unmodifiable nature of standardised safety elements.

(B) 

Correcting over-customisation of DVI without implementing Onto-CMS

In this variant, the system itself controlled the driver’s ability to change the emergency pedal icon through the application’s code, without relying on the ontology via the centralised management system. Depending on certain criteria, such as the driver’s category or other settings, the system decides whether to allow the change. If the specified conditions are not met, the system blocks change. In this way, we have the following assumptions.

• The system defines Anne’s auditory and visual impairments using variables, such as has_hearing_loss and has_visual_impairment. The explicit setting of these values in the code defines them, rather than reading from the ontology. Each operator is annotated with a set of variables describing their physical state, which the system uses to infer their ability to interact with the system.
• Once the driver attributes have been set, the system checks that the emergency pedal icon can be modified. If Anne’s auditory or visual impairments are specified, the system sets the variable Emergency_pedal_icon_modifiable to False and informs Anne that it is not possible to change the icon. However, if Anne has no disabilities, the system sets the flag to True and changes to the icon are enabled. If Anne tries to change the icon, the system will only allow a change if Emergency_pedal_icon_modifiable is set to True. If it is set to False, the system blocks the modification and displays an error message.

This control resides within the application code itself. If Anne tries to remove the emergency pedal icon, the system will block the attempt, achieving the same immediate result as the ontology-based approach. Both systems effectively prevented modifications to the emergency pedal icon in the short term. However, the ontology-based system provided superior adaptability, flexibility, dynamic management and long-term maintainability, as detailed in Section 5. Therefore, the non-ontology-based system provided a static solution that prevented modifications to the emergency pedal icon by using fixed logic in the application. While this approach successfully prevented changes, it lacks the adaptability of the ontology-based system.

4.5.2. Use Case No. 2–Adjusting Emergency Pedal Icon for Enhanced Safety

Use case: Anne is a 60-year-old female with forty years of experience who drives cautiously and responsibly despite hearing loss and reduced peripheral vision. To overcome these difficulties, she is driving with the assistance of an ADAS using large, bright notifications and amplified audio alerts. To further improve her safety, she has customised the emergency pedal icon, increasing its size and contrast for better visibility. One afternoon, Anne came across a junction that was very busy. Her ADAS system warned her of an approaching cyclist from one of the side streets. A large and bright hazard icon appeared on the central screen as an amplified audio warning pierced through the background noise of traffic and caught the attention of Anne. A clear voice notification followed, emphasising the urgency and directing her attention to the obstacle.

Algorithm 2 highlights how standardisation influences the reaction times in two driving simulations. In Scenario 1, the customised emergency pedal icon’s high visibility allowed Anne to react quickly, apply the brakes in time, and avoid an accident. In Scenario 2, the default icon’s lower visibility delays her response, increasing the risk of a collision.

Algorithm 2 Output Simulation Use Case no 2

Start Simulation

2: Initialise the Vehicle Assistance System

Scenario 1: Anne modifies the emergency pedal icon (Large and High Contrast)

4: Modify Icon:

if Icon size = large & Contrast = high then

6:   Emergency Pedal Icon is highly visible: “Size = large, Contrast = high”

Cyclist Detection:

8:    if Cyclist approaching from side street then

Display visual warning: “Warning: Cyclist approaching from a side street!”

10:          Display emergency pedal icon (size: large, high contrast)

Action taken: Emergency brake activated!

12:    end if

end if

14: Scenario 2: Anne does not modify the emergency pedal icon (Default visibility)

Modify Icon:

16: if Icon size = default & Contrast = normal then

Emergency Pedal Icon is poorly visible: “Size = default, Contrast = normal”

18:    Cyclist Detection:

if Cyclist approaching from side street then

20:      Display visual warning: “Warning: Cyclist approaching from a side street!”

Display emergency pedal icon (size: default, normal contrast)

22:      Action delayed: Accident may occur.

end if

24: end if

End Simulation

Objective. This use case highlights how the Onto-CMS adaptively adjusts interface standardisation. While the emergency pedal icon is typically non-modifiable for safety reasons, the system recognised Anne’s specific needs and selectively enabled her to customise the icon, enhancing its visibility and accessibility.

Use-case variants. This scenario included two variations. In the first, (A), the Onto-CMS identified Anne’s visual and auditory requirements and dynamically allowed adjustments to critical elements like the emergency pedal icon, ensuring high visibility and quick response in emergencies. In the second, (B), the Onto-CMS was not in use, preventing such adaptations and potentially compromising Anne’s ability to respond effectively in critical situations.

(A) 

Correcting DVI Standardisation Through Onto-CMS Implementation

The Onto-CMS ensures compliance with safety-driven standardisation. However, it allows the driver to modify the features of the emergency pedal icon under specific conditions, such as visual impairments. When the Onto-CMS detects Anne’s sensory challenges, it enables her to customise the emergency pedal icon for enhanced visibility and usability.

Onto-CMS limits the freedom to make changes in the interests of safety, permitting modifications like adjusting size, contrast or visibility, but restricting changes that could compromise functionality or effectiveness, while the system restricts changes that may affect its functionality or effectiveness. The system checks each change to ensure that it meets safety standards. For example, if Anne tried to hide the icon completely, the Onto-CMS would reject such a change. This method makes the interface flexible but keeps all the necessary security features intact. The implementation of the Onto-CMS was as follows.

• In the ontology, properties and constraints regarding the modifiability of the icon have been defined, as well as specific axioms that determine when changes can be applied (see Figure 5). The properties are detailed in Table 8, which specifies which parts of the icon can be modified and provides the necessary conditions to ensure that any modifications are made in a secure manner. More constraints are added to each variable attribute, visibility, size and colour to ensure that each change meets the system’s safety requirements.

Table 8. Restrictions and permissible modifications for the emergency pedal icon.

Type of Restriction	Description of Restriction	Ontology Attribute
Icon visibility	The icon must always be visible and cannot be hidden.	Property “visibility” with value must_be_visible
Icon size	The icon’s size cannot be reduced below a minimum threshold and must remain large enough to ensure a quick reaction.	Property “size” with value adjustable_up_to_large
Icon colour	The icon’s colour must maintain sufficient contrast with the background to ensure visibility. Colour cannot be modified to reduce icon visibility.	Property “colour” with value contrast_increase_only
Icon simplification	The icon cannot be altered in a way that reduces its clarity or recognisability as an emergency element.	Property “modifiability” that prevents changes to icon’s fundamental shape
Modification validation	Each modification must be checked by the system to ensure it does not compromise safety. Unsafe modifications are rejected.	Property “modifiability” and automatic modification validation system

Table 8. Restrictions and permissible modifications for the emergency pedal icon.

Type of Restriction	Description of Restriction	Ontology Attribute
Icon visibility	The icon must always be visible and cannot be hidden.	Property “visibility” with value must_be_visible
Icon size	The icon’s size cannot be reduced below a minimum threshold and must remain large enough to ensure a quick reaction.	Property “size” with value adjustable_up_to_large
Icon colour	The icon’s colour must maintain sufficient contrast with the background to ensure visibility. Colour cannot be modified to reduce icon visibility.	Property “colour” with value contrast_increase_only
Icon simplification	The icon cannot be altered in a way that reduces its clarity or recognisability as an emergency element.	Property “modifiability” that prevents changes to icon’s fundamental shape
Modification validation	Each modification must be checked by the system to ensure it does not compromise safety. Unsafe modifications are rejected.	Property “modifiability” and automatic modification validation system

• The ontology provides a structured methodology for managing changes in a safety-critical environment, while ensuring the rigorous enforcement of safety restrictions. The content management system, developed based on the ontology, checks every requested change to the icon before granting approval. If Anne tries to hide the icon, the system immediately rejects the operation. If she tries to reduce the size of the icon below the limit of the safe size, the system does not allow this modification. Also, when she attempts to change the colour of the icon in some manner not permitted, the system does not allow the change. In this way, all modifications will remain within the bounds of the safety specifications that the icon remains visible and recognisable as a safety-critical feature.
• Then came the development of the KG. Starting from Table 9, the system organised data from the use case into a JSON format, which was then mapped to RDF to connect driver attributes with their corresponding ontology concepts.

Table 9. Summary of the elements of use case for Anne’s adaptive interface adjustment.

Driver	Details
Name	Anne
Age	60 years
Gender	Female
Driving Experience	40 years
Physical Needs	Hearing loss, difficulty in peripheral visual perception
Driving Style	Cautious
Vehicle	Details
Vehicle	Level 3 SAE autonomous vehicle with a highly customisable interface.
Dashboard	Layout with large, bright central notifications, warning sounds and an icon for the emergency pedal that can be changed.
Voice Assistant	Loud voice notifications to help people with hearing loss.
Scenario	Details
Driving Circumstances	Driving in a busy city with lots of traffic, approaching a crowded intersection.
Result of the Onto-CMS	A cyclist is rapidly approaching. The interface makes the emergency pedal icon easier to see, so Anne can react faster.
Key Factors in Incident Avoidance	The Onto-CMS allows Anne to modify the emergency pedal icon in response to her specific needs. Normally, configurations are restricted, but this makes the icon bigger and provides high contrast so it is more visible to Anne, who has poor peripheral vision. The loud warnings and big icon help Anne respond quickly.

Table 9. Summary of the elements of use case for Anne’s adaptive interface adjustment.

Driver	Details
Name	Anne
Age	60 years
Gender	Female
Driving Experience	40 years
Physical Needs	Hearing loss, difficulty in peripheral visual perception
Driving Style	Cautious
Vehicle	Details
Vehicle	Level 3 SAE autonomous vehicle with a highly customisable interface.
Dashboard	Layout with large, bright central notifications, warning sounds and an icon for the emergency pedal that can be changed.
Voice Assistant	Loud voice notifications to help people with hearing loss.
Scenario	Details
Driving Circumstances	Driving in a busy city with lots of traffic, approaching a crowded intersection.
Result of the Onto-CMS	A cyclist is rapidly approaching. The interface makes the emergency pedal icon easier to see, so Anne can react faster.
Key Factors in Incident Avoidance	The Onto-CMS allows Anne to modify the emergency pedal icon in response to her specific needs. Normally, configurations are restricted, but this makes the icon bigger and provides high contrast so it is more visible to Anne, who has poor peripheral vision. The loud warnings and big icon help Anne respond quickly.

• The Onto-CMS was activated. When Anne wants to change the emergency pedal icon, the DVI asks the Onto-CMS if it can do this. Listing 9 shows the query that checks if it is possible to change the icon.

Listing 9. Query to verify icon modifiability.

SELECT ?driver ?icon ?modifiability ?contrast ?size

WHERE {

?driver a ocms:DriverProfile .

OPTIONAL { ?driver ocms:hearingLoss true . }

OPTIONAL { ?driver ocms:visualImpairment true . }

?icon a ocms:EmergencyPedalIcon .

?icon ocms:modifiability ?modifiability .

?icon ocms:color ?contrast .

?icon ocms:size ?size .

FILTER (?modifiability = "modifiable_with_limits")

FILTER (?contrast = "contrast_increase_only")

FILTER (?size = "adjustable_up_to_large")

}

"""

This SPARQL query first examines Anne’s hearingLoss and visualImpairment properties to assess whether her sensory impairments justify modifying the emergency pedal icon. The query then selects an instance of EmergencyPedalIcon and retrieves the icon’s modifiability, colour (contrast), and size properties. The query applies filters to return results that meet the specific conditions; the icon should be modifiable within certain limits on contrast and size. The query result confirms the modifiability of the emergency pedal icon, ensuring any changes comply with safety guidelines.

The Onto-CMS identified Anne’s specific needs (visual and hearing impairments) and informed the DVI that the emergency pedal icon can be modified, but only with certain limitations. The DVI interpreted this information and communicated it clearly to Anne, allowing her to adjust the icon to improve visibility while staying within the defined constraints (Listing 10).

Listing 10. Output simulation use case no. 2.

DVI: Modification allowed within limits. Proceed with the requested changes.

DVI to Driver: You can modify the size and contrast of the emergency pedal icon.

The system permitted Anne to modify the emergency pedal icon, enabling her to utilise a visual interface that is adapted to her sensory difficulties. The typical restrictions placed on drivers without sensory impairments to prevent such changes were removed, allowing for personalised adjustments, such as increasing icon size or contrast. However, these changes were limited to prevent any compromise to safety through practises that would render the icon less visible or less clear in an emergency.

The Onto-CMS allowed Anne to adaptively modify the emergency pedal icon to enhance its visibility and accessibility while maintaining compliance with safety standards. The system ensured a balance between personalisation and standardisation. While respecting the standardised nature of the emergency pedal icon, it allowed Anne to modify certain characteristics of the icon, such as its size, colour, and contrast, to better suit her needs. However, it ensured that the icon could not be removed entirely. This meant the system adapted to the driver’s preferences and requirements, while still preserving the integrity of essential standardised elements, ensuring safety is maintained.

(B) 

Correcting the DVI standardisation without the Onto-CMS Implementation

In a system without Onto-CMS, the operation relies entirely on variables and specific controls embedded in the application code. Such a system might function for Anne in the following way:

• Anne’s sensory conditions, such as hearing loss and visual impairment, are represented by variables in the code, like has_hearing_loss and has_visual_impairment. Every operator has a separately defined set of variables to describe their physical status but, without any central framework, these settings are not only fragmented but also lack dynamic flexibility. For example, if Anne’s status were to change, because she lost some of her eyesight, the system would not automatically readjust. A developer would need to update each variable individually by hand.
• The system uses variables related to Anne to decide whether the changes to the emergency pedal icon are allowed. When Anne has sensory impairments, the variable Emergency_pedal_icon_modifiable is set to False. Hence, no change is allowed, and a message is displayed to Anne that the icon cannot be changed. In cases of no impairments, the system sets the variable to True, and changes are, thus, allowed. But, if Anne’s status changes, a programmer will have to manually change these settings.
• When Anne tries to change the icon, the system checks the parameter Emergency_pedal_icon_modifiable. If it is set to True, the system allows the modification; if False, it prevents the change and displays an error message. While this setup works in principle, it lacks flexibility. If Anne needs to increase the contrast in low-visibility conditions, for example, the system will not automatically adjust.
• In the short term, the system successfully prevents Anne from making unauthorised changes to the emergency pedal icon, producing a similar outcome to an ontology-based system. However, it uses static rules, so it cannot dynamically adjust to Anne’s changing needs, such as when she requires more contrast in poor visibility.

In conclusion, while both systems could prevent Anne from modifying the icon in real-time, the lack of ontology and centralised management limits this system’s ability to adapt over time. If Anne’s visual conditions worsen, the system would not adjust automatically since the values for contrast and icon size are fixed. Each change would require a programmer’s intervention to update the variables manually. This makes the system difficult to maintain and inflexible in the long run.

5. Results

We present the results of two case studies (Section 4.5.1 and Section 4.5.2), each applying different management approaches to assess the flexibility and effectiveness of the systems in allowing or preventing modifications to the emergency pedal icon by the driver, Anne. The two approaches tested our Onto-CMS and a system that does not rely on ontologies but uses fixed rules.

In the first case study (Section 4.5.1), the focus is on managing critical customisations to prevent accidents in the DVI. Onto-CMS ensures the immutability of a standardised element, such as the emergency pedal icon, preventing its removal from the display. The goal is that Anne should not be able to remove or change the emergency pedal icon, to have it always in view for safety reasons. Both systems reach this aim efficiently but following different approaches. Our system uses an ontological structure to manage driver characteristics and preferences, thus providing a solution that is both dynamic and adaptive. If Anne’s condition improves in the future, the system could automatically change without manual intervention. This system has flexibility in respect to changing relationships between the driver’s characteristics and modification restrictions. The non-ontology-based system, however, uses fixed logic in an application to prevent modifications. Although it would be able to prevent Anne from changing the icon, too, if Anne’s condition changes, it would need a manual update. That structure leads to slower response times, as it requires manual updates each time a change is needed. Therefore, Onto-CMS adapts to the user’s preferences while also respecting the unmodifiable nature of standardised safety elements.

The second case study (Section 4.5.2) deals with the adaptation of the emergency pedal icon to enhance safety features. This case study demonstrates how the Onto-CMS can adaptively adjust the standardisation level of the interface, allowing Anne to modify the icon itself to improve visibility and accessibility without compromising safety. This ontology-driven system, thus dynamic, supports modification and reacts to Anne’s needs. The system detects the sensory impairments listed in Anne’s profile and applies necessary restrictions to ensure that modifications do not compromise safety. The Onto-CMS allows Anne to enlarge the icon and adjust the contrast according to her requirements. Indeed, the ontology’s flexible structure allows the system to adjust dynamically to both temporary changes and evolving conditions in Anne’s needs.

Contrary to this, the conventional system cannot allow for the change immediately due to the rigid rules involved. Circumstances change, and the particular needs of Anne may also change due to her fluctuating abilities over time. This lack of dynamic adaptation limits the system from revising the emergency pedal icon in extreme situations.

Therefore, the ontology-based system has significant advantages in adaptability and responsiveness. It enables runtime adaptations depending on the driver’s needs and external conditions, whereas the other system remains static and requires updating manually.

6. Discussion

This section highlights the advantages of using a CMS based on ontologies in driving systems, especially when compared to a more rigid, rule-based approach.

The Onto-CMS allows for the clear and unambiguous representation of knowledge. It defines concepts, such as “standardisation” and “unmodifiable”, that are semantically and logically connected. This enables the system to make intelligent, rule-based inferences. Without an ontology, the system can only execute specific checks based on predefined logic. For example, if we enrich the initial case study by requiring that the pedal icon shall be changed either by administrator users or when in maintenance mode, then the lack of a proper structure will cause a rise in the complexity of maintaining the logic underneath.

Furthermore, the Onto-CMS enables interoperability among systems. The common ontology gives a standard structure for vehicles from different manufacturers. In this way, those vehicles can handle the diversity of systems efficiently. In the case of the emergency pedal icon, an ontology-based system can automatically block modifications, simplifying decision-making without needing to program every possible scenario. Without an ontology, each case would require a separate set of code, complicating maintenance due to the lack of a unified structure.

Scalability is another key advantage of the Onto-CMS. This system does not require a complete revision every time new elements are added, but it can be expanded to redefine the ontology, allowing the system to grow without a complete rebuild.

In addition, the Onto-CMS enables complex searches with query languages like SPARQL. For example, you might query the system using the “modifiability” of the emergency pedal icon and obtain a formal response following the norms established by the ontology.

Another important benefit of an ontology-driven system is that system updates become more efficient. Changes to the ontology automatically update the code in a uniform manner and make ongoing maintenance easier. Basically, ontologies provide a structured form for demonstrating compliance with industry standards, which is important, especially for industries like automotive, where even the slightest failure in safety standards can have severe consequences.

In the same context of standards compliance and vulnerability prevention, it is essential that the Onto-CMS addresses privacy and security concerns. Although the system has not yet been implemented, its design should incorporate advanced technologies to ensure the protection of sensitive driver data and compliance with applicable regulations, such as the GDPR. These solutions align with the goal of demonstrating the system’s reliability and security, as well as improving its effectiveness in managing confidential data.

During development, the Onto-CMS design included a dedicated security layer for RDF graphs that applies advanced privacy techniques directly within the data management phase. The plan is to incorporate privacy safeguards by leveraging the link-safety principles for RDF graphs presented by Delanaux et al. [59]. For the integration of privacy concepts into the Onto-CMS, leveraging link-safety principles for RDF graphs, it is essential to use a semantic approach that combines robust anonymisation techniques with sensitive data management. The first step is to integrate privacy concepts into the system’s ontology. This involves defining sensitive identifiers, such as driver ID or location data, and establishing specific criteria for data anonymisation. The ontology could, for example, be extended to include concepts such as “sameAs”, indicating links to external entities and defining semantic rules that flag potential privacy risks. This semantic approach helps identify vulnerabilities and allows the implementation of targeted protection policies. The Onto-CMS must then apply anonymisation operations via SPARQL queries. These queries will identify potentially risky links between driver data and external sources, enabling prompt action to either delete or generalise sensitive information. For example, removing directly identifiable data or replacing it with more generic categories is vital for protecting privacy. Anonymisation operations must not only remove sensitive data but also alter it in a way that prevents the identification of the driver from the disclosed information. Data generalisation and aggregation are key techniques in this process to reduce the risks associated with the association of sensitive information. In parallel, to ensure the effectiveness of anonymisation techniques, specific linking security algorithms must be applied. These algorithms should be designed to identify all RDF triples that might compromise privacy and modify or delete them where necessary. It is essential to implement policies that, regardless of the structure of the RDF graphs, prevent situations where sensitive data could be exposed or easily linked to external sources. Such algorithms and policies will help minimise the risk of re-identifying drivers and other users. Moreover, privacy management in the Onto-CMS must be dynamic and adaptable to different operational situations. For example, driver data may require varying levels of anonymisation depending on the context, such as in an emergency or during autonomous vehicle mode. It is vital that the system can adjust data processing in real-time, ensuring privacy is not compromised. In this sense, the continuous monitoring of data and ongoing operations is crucial. Tools must be implemented to monitor and detect potential privacy violations, ensuring that the handling of sensitive data remains compliant.

Finally, to ensure compliance with current regulations, such as the GDPR, the Onto-CMS must include processes to ensure the deletion or rectification of personal data when required. Furthermore, a transparent documentation system must track the anonymisation operations carried out, enabling accurate review and ensuring the traceability of changes. Implementing these processes not only safeguards sensitive data but also guarantees that the Onto-CMS remains compliant with privacy regulations, thereby enhancing overall security and trust in the system.

7. Conclusions and Future Work

This paper presents the development of an ontology-based customisation management system for DVIs in HAVs, aiming at enhancing safety and minimising accident hazards to ensure legal responsibility. Several key aspects of interests are focused on in this study, starting with the importance of DVIs for highly automated cars and the need for a system that can securely interact using adaptive personalisation.

The results indicate that the Onto-CMS allows for dynamic adaptation to individual preferences, preserving the integrity of standardised safety elements. It ensures that critical components, such as the emergency pedal icon, remain unchanged, while still offering flexibility for customisation based on the driver’s needs to improve safety. Our system enables more targeted and safer customisations that automatically adjust to changes in the driver’s condition, offering greater flexibility. In fact, if the drivers’ conditions were to change over time, the Onto-CMS would adapt without needing manual updates. This highlights how ontologies enable the smoother and more responsive management of preferences.

At the end of this research, we can address the questions raised in Section 1 as follows.

• How could an ontology of driver profiles be used to personalise interfaces without compromising the issues of safety and consistency?
  The Onto-CMS adapts to the driver’s preferences, maintaining interface changes based on personal characteristics. This makes it easier and safer to customise, while adapting to changes without manual intervention.
• What aspects of the driver profile ontology must be globally standardised to ensure safety, while allowing flexibility for non-essential customisation?
  The research highlights the importance of standardising critical safety parameters in a driving system to ensure safety and consistency across different vehicles and contexts. These parameters must remain consistent to avoid confusion or errors that could lead to accidents, especially in high-pressure or emergency situations. However, the Onto-CMS offers flexibility in non-critical areas, offering customisation for non-critical elements that do not compromise driver safety. These could include preferences such as the colour scheme of the interface, the size of certain icons or the layout of less essential controls. By giving the driver the ability to personalise these non-critical elements, the Onto-CMS ensures a more comfortable and user-friendly experience without compromising the overall safety of the system.
• How would customised interfaces enhance performance and response times of drivers in life-critical situations?
  The Onto-CMS improves driver performance during emergencies or high-stress situations. By dynamically adjusting the interface based on the driver’s profile, the Onto-CMS can improve the driver’s responsiveness at critical junctures. Thus, this could offer more appropriate support during stressful or emergency situations.

The Onto-CMS also has certain limitations. One of the main challenges lies in managing the broad spectrum of driver preferences, which can vary significantly from person to person due to factors such as age, physical conditions and driving experience. To address this challenge, the meticulous personalisation of variables is required, supported by sophisticated management tools that may be difficult to implement universally. Moreover, as the Onto-CMS relies on data collected from drivers to personalise experiences, managing sensitive information, such as preferences and characteristics, raises significant concerns related to privacy and data security. Special attention must also be given to the protection of information gathered by automated vehicles. Lastly, some drivers might be reluctant to adopt a highly customisable system, preferring simpler and more traditional interfaces, particularly if they lack familiarity with advanced technologies. Another critical challenge associated with the system’s implementation concerns scalability. The system must be able to handle an increasing volume of data as the network of vehicles grows, especially during expansion at an urban or national level. Without the effective management of scalability, the Onto-CMS could fail to respond in real-time to traffic requests or interactions between vehicles, potentially leading to delays or malfunctions that could jeopardise traffic safety. This requires implementing technologies that support seamless and sustainable growth while ensuring the reliability of the system. Additionally, the Onto-CMS must be designed to interact seamlessly with vehicles from various manufacturers. The primary challenge is to develop a system capable of accessing data, interacting and operating in a consistent and effective manner across all these vehicles, avoiding issues of incompatibility or malfunctions caused by differing protocols and architectures among manufacturers. Each vehicle manufacturer employs proprietary technologies and systems for monitoring driver preferences, managing on-board networks and controlling sensors. This limitation is closely linked to another critical issue: the fact that the Onto-CMS’s current ontology is not designed to represent and manage specific technical characteristics of vehicles, such as engine types, communication protocols or advanced functionalities. This shortfall prevents the Onto-CMS from tailoring its services to the unique features of individual vehicles.

In the future, the focus will be on expanding and improving the system, testing it with a larger number of driver profiles encompassing an even broader range of preferences and complex sensory conditions. This will enable an assessment of how the Onto-CMS can handle a greater variety of variables and scenarios in real-world conditions. The aim is to ensure that the system can adapt effectively to an increasing number of diverse conditions, providing more sophisticated customisation to meet individual driver needs while maintaining high safety standards.

Another key area for future development is improving the system’s adaptability in complex scenarios through the integration of artificial intelligence (AI). AI algorithms could enable the Onto-CMS to respond dynamically to unforeseen conditions, such as sudden environmental changes or variations in the driver’s physical state.

Finally, to fill the gap of a technical ontology and improve vehicle integration across various manufacturers, future work will focus on extending the ontology to manage vehicles’ technical features, including elements such as engine type, battery capacity, sensors, communication standards and integration with industry standards to simplify adaptation to different manufacturers.