Human–Vehicle Integration in the Code of Practice for Automated Driving

Abstract

The advancement of SAE Level 3 automated driving systems requires best practices to guide the development process. In the past, the Code of Practice for the Design and Evaluation of ADAS served this role for SAE Level 1 and 2 systems. The challenges of Level 3 automation make it necessary to create a new Code of Practice for automated driving (CoP-AD) as part of the public-funded European project L3Pilot. It provides the developer with a comprehensive guideline on how to design and test automated driving functions, with a focus on highway driving and parking. A variety of areas such as Functional Safety, Cybersecurity, Ethics, and finally the Human–Vehicle Integration are part of it. This paper focuses on the latter, the Human Factors aspects addressed in the CoP-AD. The process of gathering the topics for this category is outlined in the body of the paper. Thorough literature reviews and workshops were part of it. A summary is given on the draft content of the CoP-AD Human–Vehicle Integration topics. This includes general Human Factors related guidelines as well as Mode Awareness, Trust, and Misuse. Driver Monitoring is highlighted as well, together with the topic of Controllability and the execution of Customer Clinics. Furthermore, the Training and Variability of Users is included. Finally, the application of the CoP-AD in the development process for Human-Vehicle Integration is illustrated.

1. Introduction

The European research project L3Pilot focuses on different activities with regard to automated driving. Split into seven subprojects, the main objective of the L3Pilot subproject 2 is to define a Code of Best Practice for Automated Driving (CoP-AD). The CoP-AD shall provide comprehensive guidelines for supporting the automotive industry and relevant stakeholders in the development of the automated driving technology. Thus, the CoP is meant to provide best practice guidance that can be used by designers and engineers throughout the lifecycle of automated driving systems. The guidelines are derived from knowledge gained in the industry as well as best practices collected on this topic.

Previously, for systems up to and including SAE level 2 [1], the Code of Practice for advanced driver assistance systems, derived from the Response project [2], served as a guideline for the development of such functions. With the advent of SAE level 3 systems and above, its application is no longer appropriate. Nonetheless, the existing code of practice was analyzed in order to apply the lessons learnt and to make use of the aspects, which remain appropriate for SAE level 3.

In order to define the scope of the document, a framework for the Code of Practice for Automated Driving was defined at the beginning of this project. It serves as a baseline for the work to be done for creating the CoP-AD. In the second section of this paper, the development process is outlined, culminating in the definition of the topics to be addressed, which were classified into four different categories. It also includes the applicable development phases and furthermore, the geographical regions, operational design domains, and SAE levels affected. The template on how to phrase and execute the questions that will form the checklist of aspects to consider when developing an Automated Driving Function (ADF) is also outlined and explained.

The third section shows the draft content of the Human–Vehicle Integration (HVI) category. This is one of the four main categories in the CoP-AD. It focuses on the topics related to the interaction between the vehicle and the user. This ranges across a broad area covering human factors, user experience, usability, and cognitive ergonomics. The section is divided into the areas of Guidelines for HVI, Mode Awareness, Trust and Misuse, Driver Monitoring, Controllability and Customer Clinics, and finally Driver Training and Variability of Users. The topics are explained, and examples are given on how to apply them as part of the CoP-AD.

In the final section, some general conclusions have been drawn, and further conclusions are highlighted with a focus on the HVI category. This paper is based on the L3Pilot deliverable D2.2 [3], which is a draft of the CoP-AD used to gather feedback from external partners outside of the L3Pilot consortium.

2. Development Process

At the beginning of the L3Pilot project, a survey was distributed to all L3Pilot partners in order to collect the requirements of all key stakeholders for the CoP-AD. This includes experts from both industry and research institutes. The relevant topics to be covered in best practices were derived using this feedback. The topics collected as part of the survey were selected based on predefined criteria during a subsequent workshop. The criteria for inclusion of a topic are listed in

Table 1. Criteria for inclusion of topics into the Code of Practice for automated driving (CoP-AD).

The topic or process poses a common challenge in the development process that requires cooperation.

A wrongly applied approach for the topic or process would lead to serious consequences (e.g., malfunctions in certain traffic situations leading to non-release of the function).

A frequent misapplication of an approach for a topic or process is highly likely.

The topic/process has already been identified as relevant by others.

The topic or process can be described in a general way that does not lead to unreasonable limitations in the development process (company independent).

And the optional criteria: the topic or process is of relevance for L3Pilot prototype vehicles and can be evaluated in this project.

.

With regard to the actual process of applying the CoP-AD, the decision was made to use the existing Code of Practice for Advanced Driver Assistance Systems as a baseline. Figure 1 shows the selected development phases for the CoP-AD. Compared to the Code of Practice for Advanced Driver Assistance Systems, the number of phases was reduced from six to four during the actual development. The second and fourth phase originally consisted of two separate stages, but these were condensed into the Concept Selection Phase and the Validation and Verification Phase for greater simplicity. An additional phase for the time post start of production was added to cover the entire lifecycle of the ADF. The conceptual stage consists of the Definition Phase and Concept Selection Phase, while the Design Phase and the Validation and Verification Phase constitute the series development stage. During the Definition Phase, the basic requirements are defined and based on this, the best concept is chosen in the Concept Selection Phase. The Design Phase requires the detailed design of the system. Then, it is validated and verified in the final phase before the start of production. Post start of production, further data can be gathered and improvements can be applied. This process is not necessarily linear; iterative improvements with repetitions of important steps might be possible. The process has been designed to remain abstract on purpose, so that the CoP-AD can be applied to the many different development processes in place in the industry at various companies.

In order to clearly summarize the topics that were collected, a number of categories were defined to cluster them.

Table 2. Categories and topics. HMI: Human–Machine Interface, ODD: Operational Design Domain.

Category	Topics
Overall Guidelines and Recommendations	Minimal Risk Manoeuver Documentation Existing Standards
ODD Vehicle Level	Requirements Scenarios and Limitations Performance Criteria and Customer Expectations Architecture Testing (incl. Simulation)
ODD Traffic System and Behavioral Design	Automated Driving Risks and Coverage of Interaction with Mixed Traffic V2X Interaction Traffic Simulation Ethics and Other Traffic-Related Aspects
Safeguarding Automation	Functional Safety Cybersecurity Implementation of Updates Safety of the Intended Functionality (SOTIF) Data Recording, Privacy and Protection
Human-Vehicle Integration	Guidelines for HMI Mode Awareness, Trust, and Misuse Driver Monitoring Controllability and Customer Clinics Driver Training and Variability of Users

shows the categories finally chosen with the pertaining topics. They are based on extensive expert discussions, clustering all the available topics in a meaningful way. The last row on Human–Vehicle Integration is the key focus of this paper.

The first category is quite generic and focusses on overall guidelines and recommendations, such as a minimal risk manoeuver. The Operational Design Domain (ODD) on the Vehicle Level offers a description of the function and scenarios at the level of the vehicle. The category ODD on the Traffic System Level, including Behavioral Design, offers a description of the function on the level of the overall environment and a description of the behavior of other road users. Safeguarding Automation is about how to ensure a safe operation of the function, primarily the functional safety, but also the cybersecurity and data privacy aspects. Human–Vehicle Integration is the interaction between the driver and the vehicle’s displays and control elements.

The topics within each of the categories were distributed along the development process phases in a workshop. In order to better address the topics derived from previously held expert sessions, a thorough literature review was done to back up the topics with research results and existing best practices. Based on this, the questions for the CoP-AD checklist were phrased. These questions underwent a rigorous iterative improvement process, improving overall quality and reducing the overall number of available questions to the most important ones. This enabled the deliverable D2.2 [3] to be written, which is a draft used to gather feedback from external partners outside the L3Pilot consortium. This will culminate in the deliverable D2.3, the final CoP-AD, to be presented in 2021.

In order to apply the CoP-AD appropriately, a template was defined for all questions; this can be seen in

Table 3. Template for questions.

Question X-Y-Z	Relevant Phase(s)	DF	CO	DS	VV	PS
Main question ( ) Yes/( ) No		Sub-Question 1 Sub-Question 2 Sub-Question 3

. The reference number for each question can be found in the top left cell of the table, and the development phases associated with the question have been marked in the top right. In the body of the table, the main question is on the left, supported where applicable by sub-questions on the right. Only the main question needs to be answered directly with yes or no. Ideally, independent evaluators (e.g., individuals from other departments or external sources such as research institutes) who have formal training or experience in the subject matter of the topics are also involved in the application of the CoP-AD. For example, for the Human–Vehicle Integration topic, the evaluator should have experience in human factors, usability engineering, or cognitive ergonomics.

Following the CoP means that all of the questions should be answered positively, or, that the issue raised by the items has been solved in another way. The sub-questions serve as an elaboration. The main question is phrased in a way that an answer with yes always means that the question has been addressed sufficiently. However, even in case a no is given as an answer, this may still be appropriate, as there might be good reasons why something could not be done or answered, or is simply not applicable in a given case, as long as the underlying problem is solved and documented. For some of the items, accepted pass/fail criteria are available (such as the number of participants that need to pass a controllability confirmation test), others are relying on norms (e.g., legibility of displays) or expert assessments if these kinds of thresholds are not available. In a further step, the questions may be transferred to an Excel file or another software tool for easy application and editing.

The CoP-AD was scoped to cover motorway and parking scenarios for SAE level 3 and level 4 functions. Although only EU markets are currently in scope, it is assumed that the CoP-AD may also be applied to non-EU regions, as well as urban or rural traffic scenarios, and even driverless robot taxis. This needs to be investigated in further research.

In the third section of this paper, the HVI category is explained in detail. This also includes examples of the questions asked.

3. Draft Content Human–Vehicle Integration

The HVI category comprises all factors related to the interaction between the vehicle and the user. This ranges across a broad area covering human factors, user experience, usability, and cognitive ergonomics. The introduction of automated driving systems that allow fallback-ready users to disengage from driving and engage in non-driving-related tasks introduces a range of potential human factors problems that must be considered in the development process. First, the transitions from automated driving to manual driving must be supported so that users are capable of taking over the driving task in a safe way in case of system limits and malfunctions. Furthermore, the possibility of different automated driving modes being available within the same vehicle, each requiring different levels of responsibility from the user, creates the need to communicate the active driving mode unambiguously. Thus, the design of the Human–Machine Interface (HMI) is a central element in the design process to ensure proper mode awareness and controllable transitions to manual driving. Secondly, the “availability” of the driver to react to requests to intervene needs to be ensured, which is mainly a function of non-driving-related tasks carried out during the automated ride. Thus, the design of the ADF should be made with foreseeable non-driving-related tasks that might likely be carried out by users during the automated ride. Thirdly, whether the ADF will be used in accordance with the intended usage, or whether users will misuse it (possibly because of over trust in the ADF) will depend on the training and information users receive.

Display and control concepts, i.e., the HMI, must be developed in a way that they are easily and safely operated by the user of an ADF. The HVI is about the harmonious interaction between the user and the vehicle in a broader sense, whereas the HMI is more specifically about the hardware and software interface between them. In order to streamline the various aspects related to HVI, this category is divided into five different topics. The first topic covers the general guidelines on how to design the HMI. This includes the acceptance of the ADF, as well as the usability and the user experience-related aspects. The Mode Awareness, Trust, and Misuse topic is primarily about the driver’s awareness of the ADF’s current driving mode. This also relates to the users’ trust in the ADF and their potential for misuse. Driver monitoring is about assessing the user’s state when operating an ADF, which is a topic closely related to the users’ mental models and their workload. An important aspect of this is the impact of non-driving-related tasks (in the following referred to as secondary tasks) carried out while driving with a highly automated function. The Controllability and Customer Clinics topic refers to the question of an ADF’s controllability from the user’s perspective on the one hand and how to conduct a study with participants to test the controllability and other properties of the ADF on the other. Driver Training and Variability of Users is the final topic. It covers the area of user training required for an ADF. Furthermore, it also relates to the variability of users to be taken into account. Together, these topics, comprising 39 main questions, form a comprehensive overview on the overall category of HVI. All the main questions from this and all other categories are available in [3].

3.1. Guidelines for Human–Machine Interface

Guidelines for the ADF’s HMI are prominently addressed as a topic in the CoP-AD. Following appropriate guidelines is key to producing a well-executed user experience and usability, which in turn will create a much higher level of underlying safety in the ADF [4]. On a generic level, this topic is about using HMI design guidelines to define, assess, and validate an HMI concept. They should be followed during the whole development process of the HMI for an ADF. There are various HMI guidelines available (e.g., [5,6]), and the guidelines used during the ADF development should be selected carefully to ensure they are suitable for the SAE level 3 systems. Guidelines adapted to HMIs for conditionally automated vehicles were presented by Naujoks et al. [7] and validated in empirical studies [8,9]. The HMI should be standardized where possible following industry standards that are consistent with the user’s mental models [10,11]. This will minimize the time required to familiarize oneself with the HMI, therefore improving the experience of first-time users. Still, guidelines may differ for certain demographics, as different groups of people may prefer different communication methods such as symbols or color coding.

Table 4. Example question Human–Vehicle Integration (HVI) guidelines. ADF: Automated Driving Function.

Question 4-1-2	Relevant Phase(s)		CO
Are unintentional activations and deactivations of the ADF prevented? ( ) Yes/( ) No

shows an example question from the Guidelines for HMI topic. The question aims to determine whether unintentional activations and deactivations of the ADF are prevented or not. Unintentional deactivation of an ADF by the user is an event that needs to be avoided. The driver may be focusing on a secondary task and will not be ready to take over control of the driving task if necessary. The HMI concept should be designed so that it is not possible for the driver to inadvertently initiate a transfer of control. At the same time, it is important to prevent unintentional activations of the ADF. Unexpected longitudinal or lateral input from the ADF may have a detrimental effect on the user’s trust in the ADF.

Furthermore, the visual interface shall be designed to be easy to read and interpret [12]. This item focuses on the importance of having a clear strategy for the visual HMI. Guidelines and standards need to be followed to ensure that the visual feedback is easy and intuitive to understand. Icons can be designed to be interpreted quickly if standard symbols and colors are used where possible. Where icons cannot be used, text messages shall be applied. However, it is important that the text can be understood in short glances, so that the driver is not forced to remove the eyes from the road for extended periods of time [6,13,14]. Finally, it is important to cluster relevant HMI elements in similar locations so that the driver can intuitively understand where an HMI should appear [5,14,15].

The HMI shall be designed to portray the urgency of the message to be conveyed [11,12,16]. During the use of an ADF, the user may be subject to many types of HMI feedback with various levels of urgency. It is important that the driver understands which HMI elements are of high priority and are conveying urgent feedback to the driver [17]. Equally, it is important that the driver understands that other messages are provided primarily for informational purposes and therefore do not require immediate action. Assessing the user acceptance is also a key point. Customer clinics, heuristic expert assessments, and various other user trials can be carried out to gain both subjective and objective data on user acceptance.

3.2. Mode Awareness, Trust, and Misuse

This topic addresses the correct understanding of the role shared between the driver and the ADF, concerning the active mode, as well as the correct usage of and the trust in the ADF.

An example question is given in

Table 5. Example question Mode Awareness, Trust, and Misuse.

Question 4-2-9	Relevant Phase(s)		CO	DS	VV
Is the communication to the driver, of the driver’s responsibilities in each defined automated driving mode(s) investigated and confirmed? ( ) Yes/( ) No		Is a method implemented to clearly inform the user of their responsibilities and of vehicle capabilities and possibly of the result of not acting within these capabilities? Is the communication to the user, of the ADF’s capabilities in each defined automated driving mode(s) investigated and confirmed? Is there clear information in the user’s manual, about the ADF’s boundaries, and has this been confirmed? Is additional training material to communicate the ADF’s boundaries and the user’s responsibilities considered? Is a process defined on how the user will be informed about any new potential functionality of the ADF based on software updates?

. This is about ensuring the drivers fully understand their responsibilities and the function’s capabilities during each of the defined ADF modes. They may be informed by several means, such as in-product advertisements and written explanations in the owner’s manual [18]. Drivers may get explicit information from the in-vehicle HMI, before, during, and after activation of the ADF itself. They may of course also learn by experience [19]. Additionally, a simple and intuitive HMI can improve the driver’s situational awareness and help them to take the correct actions when necessary.

All possible automated driving modes shall be explicitly defined in terms of how the driver should acknowledge them. The goal of this item is to ensure that the possible ADF modes are clearly defined from a user’s perspective. It is important that a user is aware of the possible automated driving modes of the ADF to avoid any misunderstanding.

It is key to know whether the HMI modalities to communicate the relevant active (automated) driving modes are described. This item focuses on how the active automated driving modes are communicated to both the driver and the other road users, in terms of modalities (visual, auditory, haptic, etc.).

All reasonably foreseeable mistakes and misuse cases of the ADF in relation to the HMI shall be described. The purpose of this question is to ensure that possible driver mistakes, failures and misuses have been addressed in the best possible way, in order to be able to define countermeasures for them [2,20].

Communicating the automated driving modes to the driver in an appropriate and clear way shall be investigated and confirmed. For an ADF, a clear communication of the mode is crucial. This question focuses on the HMI to communicate the ADF modes, the consideration of a permanent display of the modes, how to communicate the mode changes, and how well these HMI elements are recognized by both the driver and other road users. A test procedure to assess whether basic mode indicators are capable of informing the driver about relevant modes and transitions has been proposed by Naujoks et al. [21]. Additional information regarding this topic is provided by JAMA [22], Albers et al. [23], and Schömig et al. [24].

A multimodal HMI to improve driver alertness and minimize the time to get back in the loop should be investigated. However, it should also be ensured that the HMI is no more intrusive than necessary. Therefore, it is necessary to find a balance between the effectiveness of the HMI and the level of annoyance that it may cause the users [25]. Speech is another possibility to communicate a take-over request. The impact of the HMI on relevant driver indicators such as eyes-on-road time should be investigated [26].

Information shall be provided to the driver about an ADF-initiated minimum risk manoeuver [27]. A minimum risk manoeuver typically happens if the driver fails to appropriately take over the controls, or if the function does not have enough time to make a proper take-over request (for example, due to a sudden unexpected situation). This item aims to consider how to inform the driver in the event that the function has initiated the minimum risk manoeuver in order to provide the driver with the necessary information, such as what is going on, why, and what action the driver should take.

The communication to the driver, of the driver’s responsibilities in each defined automated driving mode should be investigated and confirmed. It shall be considered how and to what extent the operational design domain information will be displayed to the driver. The driver awareness of automated driving modes shall be investigated as well.

Driver expectations regarding the ADF’s features need to be considered. It is crucial to confirm whether user expectations are met. This is a broad subject that would need to be narrowed down to precise specifications, and this question is there to make sure that this process will be considered. For example, in terms of HVI, the balance between the amount of information and its conciseness or simplicity should be investigated.

The driver’s trust in the ADF is an important aspect to consider [28]. It is necessary that the users trust the function, in order for them to feel comfortable using it. On the other hand, it is necessary to avoid over-trust, as this may lead to unintended misuse of the function [29]. Again, a good balance should be targeted in order to ensure the correct amount of trust. The appropriate usage of the ADF should be assessed and confirmed, encouraging the intended use and preventing misuse.

Long-term effects of the ADF on the users shall be investigated. Typically, the main risks of long-term effects are skill degradation and building over-trust in the function [30]. The impact of the HMI on driver workload and other aspects over long journeys shall be investigated as well.

3.3. Driver Monitoring

This topic addresses the correct application of driver monitoring, specifically the identification and classification of the driver’s status and the recognition of the actions made inside the vehicle. Monitoring a driver’s attention is a crucial topic, especially when discussing automated driving [31]. Since driving is a complex phenomenon, involving the performance of various tasks (including simultaneous quick and accurate decision making), fatigue, workload, and distraction drastically increase human response time, which may result in an inability to drive correctly or to respond properly to a take-over request [32].

Table 6. Example question on Driver Monitoring.

Question 4-3-1	Relevant Phase(s)	DF
Are all relevant secondary tasks considered? ( ) Yes/( ) No		Are plausible secondary tasks possible today and in the near future taken into account? Which secondary tasks are legal, and in what timeframe will they become legal? Which metrics shall be measured via a driver monitoring function? Are the metrics appropriate for the automated driving function defined? Which apps/secondary tasks can be integrated into the vehicle HMI?

shows an example item for this topic. The question is assessing whether all relevant secondary tasks are considered when defining the driver monitoring requirements. This item addresses which secondary tasks are allowed during automated driving. The idea is to consider what is currently available and what will become available in the future. In addition, one sub-question focuses on metrics that shall be taken into account when a driver monitoring function is present within the vehicle. Moreover, the possibility to add additional apps or secondary tasks to the HMI in the future shall be considered as well.

A further important question is whether the HMI is connected with the driver monitoring function. It is essential to provide crucial information on driver’s state directly to the driver, as an impairment may compromise the safety of the situation. Thus, unsafe driver states such as drowsiness need to be communicated effectively [33].

Furthermore, it should be taken into account whether it is possible to mirror the user’s devices on the HMI [34,35]. If it is legally allowed, then it is important to consider how to prompt the driver to take back control of the vehicle while their device is being mirrored. For example, this could be done by overlaying a take-over request on the user’s device. This way, the driver can be taken back into the control loop in an effective manner. Device-pairing offers further benefits; for instance, the larger in-vehicle screens may be used as opposed to the relatively small smartphone screens. Due to the use of dedicated controls and displays, driver distraction is also minimized. The impact of typical secondary tasks on take-over time and quality should be identified as well. It is useful to measure the impact of secondary tasks on the take-over request.

After the start of production, data may be gathered to assess the types of secondary tasks, the amount of time users spend doing them, and their impact on driving behavior, traffic safety, etc. This is related to measuring the long-term effects of secondary tasks on driver behavior.

3.4. Controllability and Customer Clinics

SAE level 3 automated driving will still require the driver to take over the driving task in case of system failures and malfunctions. Thus, it has to be ensured that drivers are able to control transitions to manual or assisted driving and avoid safety critical consequences. Driver-initiated transitions should also be considered from this perspective. This topic is one of the key elements in the existing Code of Practice for Advanced Driver Assistance Systems [2].

Table 7. Example question for Controllability and Customer Clinics.

Question 4-4-7	Relevant Phase(s)				VV
Are the testing environments for controllability confirmation tests suitable? ( ) Yes/( ) No		Are the venues for the customer clinics adequate (laboratory, test track, etc.)? Are adequate precautions taken for real world testing, especially with naive participants?

shows an example question for this topic. It is about the suitability of testing environments for controllability. In the verification phase, controllability assessments should be carried out in suitable test environments, ranging from laboratory to test tracks, etc. When these controllability assessments are carried out on test tracks or on public roads, precautions regarding the safety of participants and other road users should be taken.

During the definition phase, it shall be ensured that user needs regarding controllability are taken into account. For example, the design of the HMI should consider the transition from automated driving to lower levels of automation with respect to function failures and system limits as well as driver-initiated transitions. Relevant and applicable guidelines for the design of the HMI should be considered in the design phase in order to ensure that they are in line with generally accepted standards and best practices in view of the targeted user population [7,36,37].

Limitations of the human driver should be taken into account. Careful consideration of the driver’s sensory and motor limitations (e.g., inability to move freely) need to be applied. The concept selection should thus consider topics such as color-blindness, general vision, sensory-motor, and hearing impairments.

The development should also account for a clear and understandable description of the ADF and its limits. Most importantly, if the driver is informed about function limits, that will trigger requests to intervene [38]. These should be described in the user manual and other available multimedia-based information, together with a description of the expected reaction. It also comprises the selection of a transition-of-control concept. Furthermore, it shall be tested if the vehicle is controllable in the case of a malfunction or by overruling or switching off the function.

The behavior of the ADF should not lead to uncontrollable situations from the perspective of other road users. The design should also consider the limitations and perception of other traffic participants that are not equipped with an ADF. The automated vehicle’s behavior shall be designed in a way that it is controllable for these traffic participants and does not exceed the motion ranges of drivers who are driving manually in non-emergency situations.

Even in the early design phase, a preliminary assessment of the controllability can be carried out, which is normally based on expert assessments. A suitable prototype should be used that allows for an assessment of function limits and failures, but also normal driver-initiated transitions [39,40]. The final controllability verification can be based on different evaluation methods such as expert assessments, controllability verification tests, or customer clinics [40].

A suitable post-production evaluation strategy should be implemented that assesses the impact of the ADF on possible negative behavioral adaptations such as skill degradation and misuse. This way, the ADF is adequately evaluated from a human factors perspective after the start of production.

3.5. Driver Training and Variability of Users

This topic covers the training required for ADF users and the variability of these users, which needs to be considered. The training aspect is about the issue of providing users with the appropriate knowledge and skills to operate an ADF. As there is a huge variability of users, different age groups, gender, cultural backgrounds, and different levels of previous experience need to be considered. Both topics are combined here, as they share various aspects.

Table 8. Example question Driver Training and Variability of Users.

Question 4-5-2	Relevant Phase(s)		CO	DS
Is the information that the user needs to operate the ADF available to create a training course? ( ) Yes/( ) No		Is there a training course needed for test drivers? Is there a driver training course for ordinary users planned? Is a process to train users of an ADF established? Are the possible training methods for the user defined (e.g., dealer training, online material for home training, material in car, manual, use of virtual reality, digital assistants, etc.)?

shows an example question for this topic, asking if the information that the user needs to operate the ADF is available to create a training course. Creating the user training for the ADF requires a specification of the ADF’s operation to serve as a baseline. Due to the complexity of ADFs generally, a user training course may be required or at least recommended. Ideally, this is unnecessary due to a well-executed intuitive system design. The training methods shall be defined in more detail to produce a course that could use one of many of the following mediums: a training course provided by the dealer, user manuals integrated within the vehicle, online material for home training, or the use of digital assistants. A reasonable combination of training methods shall be considered taking individual learning preferences into account [20,41,42].

There may be huge differences between user groups. The questions in the CoP-AD target the difference between countries and geographical regions. Infrastructural differences with regard to roads and traffic control functions as well as driver behavior in general have a huge impact on the design of ADFs and so these differences need to be handled appropriately. An ADF designed for only a specific country or geographical region without taking into account the local infrastructure and the requirements of their user groups must be avoided. Another factor to be taken into account are elderly drivers. Due to their degrading physical abilities, driving becomes more cumbersome. Therefore, during the definition of ADFs, the physical impairments of elderly drivers should be addressed. There is also a significant variability in users’ physical dimensions and anthropometry. Size and strength differences between genders can play a role, and so the ADF shall be designed to be operated by a variety of different users, including those with non-age-related disabilities.

There shall also be a representative test sample for user studies. Depending on the exact user study to be conducted, this may range from age, gender, and socio-cultural background to test candidates with previous experience with ADFs or technology in general. The test participants in a sample should be selected accordingly.

A solid mix of customer education and information shall be made available to the users post start of production. Developers need to ensure that there is enough information available for the users of an ADF to properly operate it. There should be sufficient training material available inside the vehicle to provide users with the required knowledge to operate the ADF safely on the road. To reduce the likelihood of people over-estimating the possibilities offered by the ADF, the marketing shall support user information and training with realistic information regarding its abilities.

4. Conclusions

The introductory part gave an overview on the development process applied to finalize the draft of the CoP-AD. This comprises all the different main categories such as the ODD Vehicle Level, the ODD Traffic System and Behavioral Design as well as Safeguarding Automation. The draft results of the CoP-AD presented here with a focus on the HVI category offer the first insight on how the interaction between the driver of the vehicle and the automated driving system shall be part of a standardized development process. Whereas the first category focuses on available guidelines in general, the other topics concentrate more specifically on topics of interest for designing an appropriate interaction between the driver and the vehicle equipped with an automated driving system. Mode awareness, including the aspects of trust and misuse is a cornerstone on how to make people aware of the automated system’s abilities, improving trust and at the same time preventing misuse. Driver monitoring plays a major role when taking into account the state of the driver and its importance for a safe operation of the automated driving function. Controllability and customer clinics actually focus on two distinct but interrelated topics. Ensuring the controllability of a system is key, especially in case of minimum risk manoeuvers. This shall be tested in user studies, which in turn serve as a primary method to test many of the guidelines and assumptions mentioned in this text. Driver training again emphasizes the importance of giving drivers the education they need, and in a medium that they can consume and learn from most effectively. In addition, the variability of users is taken into account, including the cultural and infrastructural differences between different cultures and geographical regions.

It must be emphasized that the proposed CoP-AD is based on current best practices, research, and applicable norms. Many of the published studies have been conducted using driving simulators or proving grounds; however, as automated vehicles have not been deployed, final proof that the proposed CoP-AD will be able to eliminate all possible design issues is not yet possible. The current publication is meant to stimulate the ongoing discussion in the technical and scientific community to further improve and converge current research and evaluation practice. It should also be noted that the current paper lays out a draft version of the CoP-AD that will be further refined based on available feedback. This does not only include the HVI, but also the other categories mentioned in this paper. The final CoP-AD needs to be available in an easy-to-use way, preferably as some kind of software application, either Excel-based or standalone. During the development process of an ADF, the questions presented here as examples, and those being part of the final document will guide the engineers from the concept phase up to the time post start of production.

The scope of this document is currently on highway driving and parking, primarily on SAE Level 3 and to a certain extent on SAE Level 4, for the European regions. Further work is required to see if it may be applied to other regions outside of the EU as well. Of particular interest are the USA and China. Automated driving systems that operate within the city or in rural areas shall also be applicable to the CoP-AD. Otherwise, future iterations will have to be adapted to be also applicable to other areas. This is also true for applications regarding robot taxis, reaching from geo-fenced SAE Level 4 up to SAE Level 5 systems. Until then, the CoP-AD will serve as an important guideline for the development of automated driving functions.