# Interface Design for Responsible Remote Driving: A Study on Technological Mediation
## 2 Remote Driving and Urban Mobility  
As a preliminary step towards the discussion of interface design and responsible RD, let us first briefly introduce RD technologies and the motivations behind their current study and development. (For more detailed information about the developmental trajectory of RD technology, technical requirements, and implementation challenges, cf. [1, 2]). Remote driving--sometimes, teledriving--technologies are systems that enable human operators to exert different degrees of control on vehicle behavior at a distance. In a wider sense, the term applies to a variety of use contexts and vehicles, spanning from utility vehicles in industrial settings (e.g., mining, warehousing [3]) and ground/aerial/(sub)marine vehicles in military operations [4, 5] to emergency vehicles in search and rescue operations [6] and so on. In particular, RD is commonly used to refer to civil applications involving the control of road vehicles at a distance [1, 7]. For instance, current research is intensely exploring RD solutions to support car-sharing services in urban environments. Companies such as Vay, Halo, and Elmo (cf. Table 1) have been working to include RD in car-sharing business models, so to deliver cars directly to the customers' locations and taking back vehicle control after customer use, thus removing the nuisance of finding a parking spot and maximizing fleet use. The present research centers on this last use case. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Name** & **Website** & **Information** \\ \hline \multirow{8}{*}{Vay} & & Founded in 2018 in Berlin and now based also in Hamburg and \\  & & Las Vegas, is testing remote driving applications on various \\  & & vehicles and domains including private and public transport, \\ \cline{1-1}  & & car-sharing and logistics. It runs a Teiderifying Academy \\ \cline{1-1}  & & program to train ROs and has recently launched a RD \\ \cline{1-1}  & & car-sharing service in Las Vegas in which ROs deliver vehicles to users and take back control once the destination is reached. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Information on the RD companies mentioned. For further information on companies active in the RD domain, cf. [1, 2]. Even though different use contexts pose varying needs and technological requirements, some general features apply transversally to RD applications. As Figure 1 schematically shows, a typical architecture could be said to display at least the following key components [1,4,8]:  
1. A remote driving station with HMIs allowing ROs to issue control inputs to remotely operated vehicles and obtain informational feedback about vehicle surroundings, status, and driving tasks. 2. A wireless communication system, either pre-existent or ad hoc, ensuring that data are transmitted quickly and reliably between remote driving stations and remotely operated vehicles. 3. A remotely operated vehicle (or more) endowed with sensor technologies for gathering data to be sent to remote driving stations and actuators for executing control inputs issued by ROs. In addition to a variety of use contexts, RD also comes in different modes. Even though the definition provided by UNECE [9] focuses on \"the real-time execution of all dynamic driving tasks (DDTs) and/or fallback DDT (including braking, steering, acceleration, and transmission shifting in real-time), by a remote driver\", the literature on the topic admits of more forms, which are usually characterized by reference to the level of automation with which the vehicle is endowed. Indeed, RD is often considered first and foremost as a backup technology enabling driving automation, i.e., offering support when automated driving systems are unable to perform as expected [10,11]. With driving automation itself being a matter of degrees, as per the SAE J3016 Levels of Driving Automation [12], ROs' forms and degrees of involvement in the management of DDTs are bound to vary accordingly.