## 2 Materials and Methods
### System of Structuring Scenarios
The shuttle waits due to the blocked lane (1a). The shuttle informs the remote operator that no further travel is possible due to an obstacle (1b). The remote operator is in bidirectional contact with the passengers and switches to the shuttle’s cameras to get an overall view (2). The remote operator finds out whether it is possible to bypass the obstacle. The remote operator sets a new trajectory, e.g., by setting waypoints, selecting a trajectory, or steers the AV manually around the obstacle, gives clearance, and permits the AV to continue (3). If this is the case, the shuttle can continue its journey. If a bypass cannot take place due to e.g., constructional conditions, then the remote operator contacts the police or another authority (4a). The passengers are proactively informed about the further procedure and possible delays (4b). The police or another authority drive to the shuttle and solve the blockade (5). such as remote operators: \"Actors may represent roles played by human users, external hardware, or other subjects\" [27] (p. 586). Following this definition, the following actors are used in the compilation of scenarios:  
* _Remote Operator, who may be both Remote Driver of Remote Assistant in SAE's [8] terminology,_
* _Highly Automated Vehicles_ at SAE Level 4,
* _Passengers,_
* _Infrastructure,_ e.g., crosswalks, traffic lights, or intelligent road-side infrastructures (including road-site units, i.e., sensors along the road that scan the traffic in their immediate surroundings and submit this information to a traffic management center, cf. [28]), and
* _Other Actors,_ e.g., emergency services, control center staff, and other road users. All of these five actors may be interacting with any other actor in a given scenario within a specific context that influences them. Figure 7 includes the most relevant actors and their interrelations. On the second-to-top level, scenarios are grouped into use cases. Here, a use case is defined as a functional description of a technical system and its behavior for a specific use. Use cases can comprise numerous different scenarios, but a scenario can only contain a certain number of scenes arranged in a certain order [14]. On the third-to-top level, scenarios are listed. In order to facilitate comparability, every scenario is structured in a chain of cause, event, and consequence, as Figure 7 represents. The sequence consists of the following elements: a cause that the event is attributed to, the central event, and the consequences that arise from it. A generic template is proposed that is used for every scenario:  
Due to <Cause>, <Event> takes place. This results in <Consequence>. The event and its consequence, in turn, lead to certain measures that are required to resolve the event. These required measures, however, are not part of the presented catalogue of scenarios. Adding them would be beyond the scope of this paper since its focus is on events in remote operation, their causes, and consequences. The required measures will be addressed in future publications. Figure 7: Most relevant actors interacting in the compiled scenarios on remote operation of highly automated vehicles. The remote operator, the highly automated vehicle, the passengers, and the infrastructure collaborate with each other to complete the driving task at SAE Level 4. Adapted with permission from Ref. [30]. 2022, DLR (CC BY-NC-ND 3.0). It is important to note that the scenario does not take place in ignorance of the concrete context in which it happens. Rather, all its stages are embedded in this context (see Figure 8). Additionally, the actors that interact throughout the scenario represent another level of analysis that accompanies the chain of cause, event, and consequence, and might also be involved in the measures required for resolving the event.